ISPConfig Cluster über Public IP

[Brainfood]

Server1

; ### ### ### PLITC ### ### ###
; #
chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
pid = /stunnel4.pid

; #
sslVersion = SSLv3
; foreground = yes
; debug = 7

[repliserver]
; accept = XXX.XXX.XXX.XXX:3307
accept = 2a01:XXXX:XXXX:XXXX::XXXX:3307
connect = 127.0.0.1:3306
cert = /etc/stunnel/mysql.pem

[repliclient]
accept = 127.0.0.1:3307
; connect = XXX.XXX.XXX.XXX:3307
failover = rr
connect = 2a01:XXXX:XXXX:XXXX::XXXX:3307
connect = 2a01:XXXX:XXXX:XXXX::XXXX:3307
connect = 2a01:XXXX:XXXX:XXXX::XXXX:3307
connect = 2a01:XXXX:XXXX:XXXX::XXXX:3307
cert = /etc/stunnel/mysql.pem
client = yes

; #
; ### ### ### PLITC ### ### ###
; # EOF

bei Server2 umgekehrt

 

[Brainfood]

Wenn ich mich ins ISPConfig3 auf den Server 2 (Slave) einlogge steht in der Überwachung:

Daten vom: ????-??-?? ??:??
Derzeit stehen keine Protokolldaten zur Verfügung. Bitte später erneut überprüfen.

das ist normal im Cluster (Master/Slave Modus)?

Nein, das bedeutet dass sich der slave nicht mit dem Master verbinden kann um seine Status und Logdaten in die master DB zu schreiben.

 

[Brainfood]

so schauts in der syslog aus:

Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453493504]: repliserver accepted connection from 2a01:XXXX:XXXX:XXXX::XXXX:36524
Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453493504]: connect_blocking: connected 127.0.0.1:3306
Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453493504]: repliserver connected remote server from 127.0.0.1:50640
Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453423872]: repliclient accepted connection from 127.0.0.1:56533
Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453423872]: connect_blocking: connected 2a01:XXXX:XXXX:XXXX::XXXX:3307
Apr 23 23:07:11 server2 stunnel: LOG5[2699:140386453423872]: repliclient connected remote server from 2a01:XXXX:XXXX:XXXX::XXXX:55982
Apr 23 23:07:11 server2 mysqld: 130423 23:07:11 [Note] Slave I/O thread: connected to master 'slaveuser@127.0.0.1:3307',replication started in log 'mysql-bin.000012' at position 106

 

[Brainfood]

da der stunnel sync über ipv6 läuft kommt ab und an im syslog:

IPv6: sending pkt_too_big to self

ich teste mal:

ifconfig eth0 mtu 1496

 

[Till]

Wenn ich mich ins ISPConfig3 auf den Server 2 (Slave) einlogge steht in der Überwachung:



das ist normal im Cluster (Master/Slave Modus)?

Sorry, ich hatte meine Antwort aus Versehen in Deinen Post geschrieben. Hier nochmal richtig:

Nein, das bedeutet an sich dass sich der slave nicht mit dem Master verbinden kann um seine Status und Logdaten in die master DB zu schreiben. Die Verbindung slave zu master hat recht komplexe Rechte in der master db, vielleicht sthet dort irgendwo bei den table oder column Rechten noch der falsche hostname drin.

 

[Brainfood]

verstehe,

ISPConfig3-Master = ispconfig(1)@localhost + root@localhost -> dbispconfig(1)
ISPConfig3-Slave = ispconfig(2)@localhost + root@localhost -> dbispconfig(2)
ISPConfig3-Slave = ispcsrv3@remote_host -> dbispconfig(1)

und wenn ich auf dem Server2 statt dem ispcsrv3 User den ispconfig1@localhost nehme (Statt jetzt nach den Werten in der Datenbank zu suchen und dort herum zu wuseln?)?

 

[Brainfood]

moment habe ich gerade einen denkfehler?

ispcsrv3 "poll"t doch nur die Daten zum Server1 um sie per (Master) ISPConfig3 -> "Überwachung" darstellen zu können?

Nur wenn: /usr/local/ispconfig/server/lib/config.inc.php

//** Database settings for the master DB. This setting is only used in multiserver setups
$conf['dbmaster_type']            = 'mysql';
$conf['dbmaster_host']            = '';
$conf['dbmaster_database']        = 'dbispconfig';
$conf['dbmaster_user']            = '';
$conf['dbmaster_password']        = 'XXX';
$conf['dbmaster_new_link']         = false;
$conf['dbmaster_client_flags']     = 0;

garnicht erst auf dem Master-Server eingestellt ist, pollt dann auch der Server nicht die Logdaten zum Slave um sie dort anzeigen zu können ...

In einem ISPConfig3 Cluster möchte man natürlich auch vom Server2 (Slave) unteranderem die Überwachung vom Server1 (Master) sauber sehen können

 

[Till]

ispcsrv3 "poll"t doch nur die Daten zum Server1 um sie per (Master) ISPConfig3 -> "Überwachung" darstellen zu können?

Nein, nicht nur.

1) Er pollt die Daten um Konfigurationsänderungen durchzuführen.
2) er schreibt aber auch Daten in die master DB, dabei hat er aber sehr eingeschränkte Rechte so dass er nur auf wenige Tabellen schrebzugriff hat, so wenige wie unbedingt notwendig damit kein node Konfigurationsänderungen für einen anderen node ausführen könnte wenn mal einer gehackt würde.

 

[Brainfood]

Ich habe ja andere ISPConfig3 Multiserver-Installationen laufen, da ist die "Einschränkung" auf den Slaves genauso

Master -> ISPConfig Überwachung und Einstellungsübernahme an die Slaves geht
Slave1 (mit ISPConfig) -> keine Loganzeige
Slave2 (mit ISPConfig) -> keine Loganzeige
Slave3 (mit ISPConfig) -> keine Loganzeige
Slave4 (mit ISPConfig) -> keine Loganzeige

Ok Till, du sagtest es mir schon einmal an einer anderen Stelle: "Es mache kein Sinn ISPConfig Interface ebenfalls auf den Slaves zu installieren"

In einem Cluster sollte aber der Node A gleichberechtigt mit Node B sein.

Die ISPConfig3 Master & Slave (Cluster) Installation ist schon klar, macht es da Sinn den ispcsrv3 User ebenso mit in die Master config.inc.phps einzubinden?

 

[Till]

Master -> ISPConfig Überwachung und Einstellungsübernahme an die Slaves geht
Slave1 (mit ISPConfig) -> keine Loganzeige
Slave2 (mit ISPConfig) -> keine Loganzeige
Slave3 (mit ISPConfig) -> keine Loganzeige
Slave4 (mit ISPConfig) -> keine Loganzeige

Ich habe hier auch einen Cluster und der zeigt die Logs der slaves auf dem Master an. Vielleicht hast Du bei den Updates kein "reconfigure permissions in master database" gemacht?

Die ISPConfig3 Master & Slave (Cluster) Installation ist schon klar, macht es da Sinn den ispcsrv3 User ebenso mit in den Master config.inc.phps einzubinden?

Meines Erachtens nicht. Der Cluster mit Mirroring und 2 ispconfig Interfaces functioniert ja so:

Es gibt 2 unabhängige ispconfig datenbanken, dbispconfig1 und dbispconfig2 und zwar gibt es sie auf beiden servern da mysql master/master Replication. ISPConfig kümmert sich um das verschieben der daten von db1 zu db2, mysql kümmert sich darum dass db1 und auch db2 auf beiden servern zur verfügung stehen. Die Interfaces beider server verbinden sich mit db1. der server teil von server1 verbindet sich mit db1, der serverteil von server2 verbindet sich mit db2. das ist notwendig damit beide server ihr eigenes datalog haben.

 

[Brainfood]

"reconfigure permissions in master database" wurde gemacht, die Loganzeige auf dem Master ISPConfig3 funktioniert ja, nur eben auf dem Slave nicht (Überwachung von Server1) ... es geht mir nur um den Slave

Prinzip ist klar, deswegen speichern root@ und ispconfig(1/2)@ jeweils in die lokale ispconfig1 und ispconfig2 DB, User ispcsrv3 verteilt dann ja nur vom Slave zum Master ...

unabhängig von der MySQL Master/Master Replication, die sowieso eigentlich nur für den Sync von "Kunden"-Datenbanken gedacht ist, warum findet der "poll" nicht auch auf dem Master statt?

anders formuliert: warum kein ISPConfig3 Master/Master Cluster?

 

[Till]

"reconfigure permissions in master database" wurde gemacht, die Loganzeige auf dem Master ISPConfig3 funktioniert ja, nur eben auf dem Slave nicht (Überwachung von Server1) ... es geht mir nur um den Slave

Hast Du denn wie im mirror Tutorial beschrieben die interface config.inc.php Datei des slaves geändert? Das slave interface connected auf die master DB auf localhost, er muss also definitiv das gleiche anzeigen wie der master. Falls nicht dann geht die mysql master/master Replikation nicht.

anders formuliert: warum kein ISPConfig3 Master/Master Cluster?

Mögliche Datenkonflike und es ist in dieser Konfigurazion auch nicht notwendig da der Teil durch die mysql master/master Replikation angedeckt wird.

 

[Brainfood]

Ach Fuck, du meinst wohl:

On server 1:

... and execute this command:

scp -p /usr/local/ispconfig/interface/lib/config.inc.php root@192.168.0.106:/usr/local/ispconfig/interface/lib/config.inc.php

This command has to be excuted after each ISPConfig update again after you updated ISPConfig on the master and on the slave with the normal ISPConfig update command (ispconfig_update.sh).

hab ich wohl vergessen, die /server/lib/config.inc.php bleibt aber mit den lokalen (server2) daten?

 

[Till]

die /server/lib/config.inc.php bleibt aber mit den lokalen (server2) daten?

Ja, die server Datei bleibt so.

 

[Brainfood]

OK, funktioniert jetzt ... Asche auf mein Haupt.

 

[Brainfood]

Ach eine Sache noch, wie ist das mit der "billing" app, einfach auf server 1 und 2 installieren oder kreuzen sich die db Einträge dann?

 

[Till]

Die billing app einfach auf beiden Servern installieren. Da die interfaces ja die gleiche gespiegelte master DB nutzen, gibt es da keine Probleme.

 

[Brainfood]

ok nächste Sache, Datenverteilung:

- ich halte bis jetzt die Multiserverkisten mit rsync/ssh aller 10 min gleich
- unison?
- glusterfs?

Wie gut läuft GlusterFS über ein OpenVPN/IPSec?

Skalierung? Trafficverzehr? etc.

 

[Brainfood]

Zum Thema MySQL noch einmal:

mysqld: 130426 23:15:14 [Warning] Statement may not be safe to log in statement format. Statement: DELETE FROM invoice_message_template WHERE invoice_message_template_id = 1 LIMIT 1

 

[Till]

ok nächste Sache, Datenverteilung:

- ich halte bis jetzt die Multiserverkisten mit rsync/ssh aller 10 min gleich
- unison?
- glusterfs?

Wie gut läuft GlusterFS über ein OpenVPN/IPSec?

Skalierung? Trafficverzehr? etc.

Ich würde unison nehmen. Wir haben anfangs auf glusterfs gesetzt, wie es noch im lenny tutorial steht, aber glusterfs kommt nicht mit vielen kleinen dateien klar wie sie für webserver typisch sind und bricht dann komplett in der performance ein auf dateraten im kilobit bereich trotz 1gbit verbindung zwischen den servern.