# ISPConfig3 bei Cluster Setup (Interfaces, Ordner )



## rootfuchs (21. Aug. 2014)

Hallo,

ich habe eine Frage bezüglich der Konfiguration der Interfaces bei ISPConfig3
auf einem Servercluster. 

Ich habe mir aus diversen Howtos alles zusammen gesucht um einen Cluster mit ISPConfig auf einem Debian 7 zu bauen. Mit 3 Servern (1 Master, 2 Nodes) jeweils mit Maria-Galera und GlusterFS als Replikation der DB und der Ordner. 

Repliziert wird dabei die Datenbanken und die Ordner /var/vmail/ und /srv/www/

Alles soweit in Ordnung, nur kann ich mich an den beiden Nodes trotz angepassten sys_usern, mysql Usern und debian.conf Dateien nicht anmelden kann da die sys_user Tabellen leer sind.

Ich hab mir jetzt mal die config-Dateien des ISPC3-Interfaces angesehen.
Soweit ich das beurteilen kann, wäre es doch in dem beschriebenen Setup möglich einfach die config.inc.php des Masters auf die Nides zu verteilen,
damit könnte ich mich zwar auf allen Nodes ins Webinterface einloggen, käme aber immer auf der Master-DB heraus. Den Rest erledigt der Server Teil von ISPConfig3 und das dort eingetragene Mirroring.

1. Ist diese Annahme so korrekt?
2. Wäre es sogar denkbar die Datenbanken der ISP-Node-Installationen zu kicken? Oder benötige ich für den Server-Teil explizit separate Datenbanken?

VG


----------



## Till (21. Aug. 2014)

1) Ja, das ist korrekt und so muss es auch gemacht werden. das ist im ispconfig mirror Tutorial beschrieben. denn im Grunde genommen ist es imemr eine sternförmige Architektur, das Interface muss sich also egal auf welchem server es liegt immer mit der "ersten", also master DB verbinden während der server teil sich mit der lokalen DB verbindet um Redundanz zu erzeugen.

2) Der Server Teil braucht zwingend eigene Datenbanken, denn ein slave hat andere Daten als der Master und auch jeder Slave hat andere Daten als ein andere Slave selbst wenn beides mirror sind.


----------



## rootfuchs (21. Aug. 2014)

Wunderbar. Danke für die Antwort. 



> ...immer mit der "ersten", also master DB verbinden während der server teil  sich mit der lokalen DB verbindet um Redundanz zu erzeugen.


Ja ich hatte mich auch unklar ausgedrückt. Ich muss nicht gleich die ganze Datei austauschen, sondern nur den entsprechenen DB-Connect anpassen. Jede Node ja noch in Ihrer Interface-config den eigenen Nutzer für die Master-DB.

Ein paar Fragen hätte ich noch. Was wird denn bei der Einstellung 'Mirror' alles gespiegelt? Dazu vermisse ich im Handbuch leider ein paar angaben.

- Einstellungen von ISPC3 in den /etc/ Dateien?

- Datenbanken? - Wird also versucht einen weiteres Create auf den Nodes auszuführen? Das wäre ja nonsens aufgrund des Galera-Clusters. 

- Einstellungen für den DNS? - Ich wollte per DNS die User erst mal per round-robin verteilen. Als 'Loadbalancing' für arme sozusagen.


----------



## Till (21. Aug. 2014)

Mirroring bedeutet dass er exakt das was er auf einem server ausführt auch auf dem anderen server ausführt. Wenn Du also ein web anlegst, dann passiert dies auf dem master und dem mirror. Wenn Du z.B. bei Datenbanken alles in mysql spiegelst inkl. der mysql user DB, dann solltest Du auf den slave nodes das server datenbank plugin durch löschend es symlinks im plugins-enabled Verzeichnis deaktivieren. So kannst Du das was auf dem Mirror passiert etwas feiner steuern. Das selbe kann auch für Cronjobs sinn machen, den in den meisten fällen möchte mn ja nicht dass der cronjob mehrfach läuft.



> - Einstellungen für den DNS? - Ich wollte per DNS die User erst mal per round-robin verteilen. Als 'Loadbalancing' für arme sozusagen.


das ist sicherlich die eifachste Lösung. alles andere würde ja bedeuten dass Du einen Lodbalancer, ob nun als software oder hardware, vor die Server packst.


----------



## rootfuchs (21. Aug. 2014)

> dann solltest Du auf den slave nodes das server datenbank plugin durch  löschend es symlinks im plugins-enabled Verzeichnis deaktivieren





> Das selbe kann auch für Cronjobs sinn machen, den in den meisten fällen möchte mn ja nicht dass der cronjob mehrfach läuft.


Danke für die Hinweise, werde ich auf jeden Fall machen.


----------



## rootfuchs (10. Okt. 2014)

Hallo um an den letzten Beitrag zum Thema anzukrüpfen. Es hat sich - mit dem oben beschriebenen Setup - ein Problem ergeben das ich nicht 
ganz nachvollziehen kann.

Wenn ich versuche mich über einen der Slave-Server auf die ispconfig Oberfläche einzuloggen, bekomme ich ein 'Benutzername oder Passwort ist falsch.'. 
Db-Connect zur Master-DB besteht allerdings. Benutzerdaten sind korrekt und funktionieren auch von Master-Server auf die Master-DB aus.
Hat jemand eine Idee woran es noch leigen könnte? Die Interface-Configs sind ja entsprechend angepasst. Der User für den Zugriff auf die Master-DB ist ebenfalls mit entsprechenden Rechten ausgestattet. Hat jemand noch eine Idee was es sein könnte?


----------



## Till (10. Okt. 2014)

Und Du hast auch die interfec/lib/config.inc.php vom master auf den slave kopiert, wie im Tutorial beschrieben?


----------



## rootfuchs (10. Okt. 2014)

Nope, ich hab interfec/lib/config.inc.php jeweils nur angepasst damit die Einträge unter

```
//** Database
```
auf die Master-DB zeigen und die entsprechenden Nutzer/Passwörter verwenden.
Wenn ich die Datei vom Master kopiere, haben die Slaves ja keine Einträge mehr unter

```
//** Database settings for the master DB. This setting is only used in multiserver setups
```
Ich entnehme mal Deiner Frage, dass ich das hätte tun sollen ^^ . Probiere ich gleich mal.
Und der dann fehlende Teil der master-DB hat keine Auswirkungen?


----------



## rootfuchs (10. Okt. 2014)

Ok ich hab mir ein Backup der Dateien gemacht und sie vom Master jeweils auf die Slaves kopiert. Ergebnis ist dasselbe. :-/


----------



## Till (10. Okt. 2014)

Du sprichst immer von dateien, es handelt sich nur um fenau eine Datei die unverändert kpiert werden muss. Wenn Du mehr als eine Datei geändert oder kopiert hast, dannw ar das zu viel. Verwechsel bitte nicht server und Interface Teil, die haben jeweils eigene Dateien und daher kannst und Musst Du auch die interface Datei des masters unverändert auf den slave kopieren.


----------



## rootfuchs (10. Okt. 2014)

Sorry mein Fehler ich rede nur in Mehrzahl da ich die Datei 'interface/lib/config.inc.php' ja auf zwei Server kopiere. 
Ich hab jewiels die 'interface/lib/config.inc.php' vom Master auf die beiden Slaves kopiert. Leider komme ich noch immer nicht bei den Slaves auf das Interface.


----------



## Till (10. Okt. 2014)

Dann muss es an Deinem abweichenden MySQL cluster setup liegen, denn in dem ursprünglichen cluster setup kannst Du Dich über localhost von beiden nodes in die master DB, die ja per mysql master/master Replikation auf beiden servern gespiegelt zugänglich ist, einloggen. Wenn das nicht geht oder die speigelung nicht läuft, dann geht auch der ispconfig login auf den slaves nicht da sich die lokale interface Instanz ja nicht authentifizieren und auf die DB zugreifen kann.


----------



## rootfuchs (10. Okt. 2014)

Hm ich hab jetzt einfach den Zugriff in der config.inc.php auf allen 3 Servern auf die Adresse des Master umgestellt und die Rechte entsprechend neu vergeben. Jetzt geht es von jedem Server aus. Keine Ahnung warum ISP3 auf den maria-galera-'Slave'-Nodes nicht auf localhost reagiert hat. Irgendwas engeht mir da gerade.

ISP3 ist ja im Grunde in PHP-Teil auch nichts anderes als jedes beliebige Webprojekt?!? Aber lokalhost geht nur auf dem Server auf dem ISP3 zuerst installiert wurde und den Webprojekten? Kommt mir seltsam vor .

Zumindest der Workaround funktioniert.  Vermutlich muss ich den Serverteil dann auch entsprechend anpassen.


----------



## Till (10. Okt. 2014)

> ISP3 ist ja im Grunde in PHP-Teil auch nichts anderes als jedes beliebige Webprojekt?!? Aber lokalhost geht nur auf dem Server auf dem ISP3 zuerst installiert wurde und den Webprojekten? Kommt mir seltsam vor .


Richtig. Das ispconfig Interface ist nix anderes als jedes beliebige PHP cms, läuft sogar in windows unter xampp  Der Server Teil ist auch nur ein PHP script, slo von der mysql Verbindung her das selbe, einfache mysqli connects über php.


----------



## rootfuchs (10. Okt. 2014)

> Vermutlich muss ich den Serverteil dann auch entsprechend anpassen.


Falschaussage von mir. Im Serverteil greift jeder Server auf seine eigene DB per localhost zu. Irgend eine Idee wie ich das testen kann?
Im Log steht nur folgendes:

```
08.10.2014-11:47 - WARNING - Unable to connect to local server.
```



> Richtig. Das ispconfig Interface ist nix anderes als jedes beliebige PHP cms, läuft sogar in windows unter xampp


Eben   Tja keine Ahnung. Die Passwörter waren definitiv gleich und die DB Rechte für den Nutzer ispconfig3 für alle ispconfig-Datenbanken (3 Stück) auf localhost gegeben. Laut Google verhält sich der maria-galera auch nicht anders was localhost betrifft.

Naja ich hoffe danach steht alles. Ich würde die Bash-Scripte zum Einrichten des Clusters/Standalone-Servers ganz gerne hier hochladen und ggf. ein HowTo dazu schreiben. Sofern ich mal mit dem gefrickel fertig werde. ^^


----------



## nowayback (10. Okt. 2014)

Zitat von saarworres:


> Code:
> 08.10.2014-11:47 - WARNING - Unable to connect to local server.


Prüfen ob der MySQL Server auf den Slaves läuft und auch auf und von localhost erreichbar ist (interface in my.cnf, iptables, etc). Dann prüfen ob die DB vom Master auf die Nodes repliziert wurde und ob die Benutzer angelegt sind.


----------



## rootfuchs (10. Okt. 2014)

Zitat von nowayback:


> Prüfen ob der MySQL Server auf den Slaves läuft


Tun sie.



Zitat von nowayback:


> prüfen ob die DB vom Master auf die Nodes repliziert wurde


Ist in dem Fall kein Kriterium, da das ganze Setup auf 3 Servern mit einem maria-galera-Cluster läuft. D.H. der ISP3 Master legt die Datenbanken an und die werden autom. auf den beiden anderen angelegt. Da müssen die ISP3-Slaves selbst nichts mehr tun. Im Gegenteil sind die Datenbank-Plugins auf dem beiden Slave-Servern deswegen aus, damit diese nicht versuchen, angelegte Datenbanken nochmal anzulegen.



Zitat von nowayback:


> ob die Benutzer angelegt sind.


Sind angelegt und die Verzeichnisse werden eben so gespiegelt.

Um die zugrunde liegende Struktur nochmal zu verdeutlichen:
Ich habe nach Installation des Clusters 3 isp-Datenbanken im Maria-Galera:

ispconfig_SRV1,  (Master)
ispconfig_SRV2,  (Slave)
ispconfig_SRV3  (Slave)
*Alle 3 ISP-Interfaces greifen laut Ihrer config.inc.php auf ispconfig_SRV1 zu.*
Alle ISP-Server greifen der jeweiligen Mascshine, auf Ihre jeweilige DB zu:

auf SRV1: ISP-Server auf ispconfig_SRV1,
auf SRV2: ISP-Server auf ispconfig_SRV2
etcpp...
Da alle 3 Interfaces derzeit auf eine Datenbank laufen, müsste ich ja wenn ich einen neuen FTP-User anlege zumindest sehen, ob die Server diesen entsprechend auf allen 3 Anlegen oder?  Nun kommt der Witz:
FTP-Benutzer die auf SRV1 über dessen Interface angelegt wurden, erscheinen im Interface auf SRV2 und SRV3 (_Korrektes Verhalten wie erwaret_)

Die FTP-Benutzer erscheinen aber in der Tabelle 'ftp_user' in der Datenbank ispconfig_SRV2! Und nur da!


  Welch Hexerei ist das?


----------



## Till (10. Okt. 2014)

> Die FTP-Benutzer erscheinen aber in der Tabelle 'ftp_user' in der Datenbank ispconfig_SRV2! Und nur da!


Dann muss mindestens eines der Interfaces darauf verbinden anstatt auf den master.


----------



## Till (10. Okt. 2014)

ispconfig funktioniert so: Alle neuen einträge werden vom interface in die master db geschrieben. Die slaves (server teil) verbinden sich einmal pro minute mit der master db, checken die sys_datalog tabelle auf neue einträge die sie betreffen und wenn es da was neues gibt, kopieren sie den Eintrag, fügen ihn in ihre lokale DB ein und führen die server events / plugins aus die an diesen event gebunden sind.


----------



## rootfuchs (10. Okt. 2014)

Ok soweit verstehe ich das. Aber ich habe ja auf beiden Slaves die Datenbank-Plugins deaktiviert.
Also entweder sollte dort gar nichts stehen weil das Plugin nicht da ist, oder das selbe wie in der ispconfig_SRV1.

Ich hab das gerade mal getestet. Die FTP-Zugänge funktonieren auf allen 3 Servern.
Und ich hab nochmal nachgeprüft:
Die Einträge sind wirklich nur in der ispconfig_SRV2 unter ftp_user zu finden.
Alle Interface-Configs der Server zeigen auf ispconfig_SRV1.

Wie kann denn das Interface etas in eine SLAVE Datenbank schreiben von der es nichts weis; aber nichts in seine eigene??
Ich teste gerade nochmal mit meinem Kollegen das Anlegen eines FTP-Users auf SRV1. Falls er sich geirrt hat und die Nutzer evtl auf dem Interface des SRV2 angelegt hat. Mom.


----------



## Till (10. Okt. 2014)

Die Datenbank Plugins dienen nur zum anlegen von neuen Kunden Datenbanken. Mit FTP usern haben die nichts zu tun und mit der datenreplikation auch nicht.



> Wie kann denn das Interface etas in eine SLAVE Datenbank schreiben von der es nichts weis?


Garnicht. Daher muss etwas an dem setup ganz im argen sein.


----------



## rootfuchs (10. Okt. 2014)

Ah ok, dann sind die Plugins raus aus der Betrachtung.

Ich hab wie gesagt gerade mal einen neuen FTP-User angelegt über das Interface auf SRV1.
Jetzt stehen alle FTP-User in der Datenbank ispconfig_SRV1. Zumindest nachvollziehbar. Dafür steht jetzt nichts mehr in den beiden andern Datenbanken ispconfig_SRV2 und ispconfig_SRV3. Till bitte sag mir das Ihr die Tabellen der Slaves kurz TRUNCATED bevor Ihr Sie neu einlest *hoff*

Nach 5 Min sind die beiden immer noch leer, daher stelle ich jetzt mal die ISP-Server-Configs auf SRV2 und SRV3 ebenfalls auf die Domain anstelle von localhost um. Geh ich richtig in der  Annahme, dass wenn es dann gehen sollte alle 3 Datenbanken die selben Inhalte haben müssten und der jeweilige Cronjob auch Rückwirkend noch die Änderungen übernehmen würde?


----------



## Till (10. Okt. 2014)

Wieso truncate? Der kopiert nur die Änderungen die neu im sys_datalog als serialisierte objekte stehen und die werden mit mysql replace into in die Datenbanken der slaves geschrieben.



> Nach 5 Min sind die beiden immer noch leer, daher stelle ich jetzt mal die ISP-Server-Configs auf SRV2 und SRV3 ebenfalls auf die Domain anstelle von localhost um. Geh ich richtig in der Annahme, dass wenn es dann gehen sollte alle 3 Datenbanken die selben Inhalte haben müssten und er auch Rückwirkend noch die Änderungen übernehmen würde?


dann kann sich wohl der server teil nicht mit dem master verbinden. das kannst Du so debuggen: http://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/


----------



## rootfuchs (10. Okt. 2014)

Zitat von Till:


> Wieso truncate? Der kopiert nur die Änderungen die neu im sys_datalog als serialisierte objekte stehen und die werden mit mysql replace into in die Datenbanken der slaves geschrieben.


Naja ich hatte gehofft das mit dem INSERT in die Master-DB die Slave-Db Tabellen geleert würden und sie neu zu befüllen; ich also nur kurz warten muss  



Zitat von Till:


> as kannst Du so debuggen


Wunderbar danke.


----------



## Till (10. Okt. 2014)

> Naja ich hatte gehofft das mit dem INSERT in die Master-DB die Slave-Db Tabellen geleert würden und sie neu zu befüllen; ich also nur kurz warten muss


Wenn dem so wäre dann wäre es ja wohl sehr schlecht skalierbar


----------



## rootfuchs (10. Okt. 2014)

Zugegeben, aber es wäre soo praktisch gewesen, weil es dann an mir liegen würde ^^

Also die Server.sh funktioniert auf beiden Servern!

Es war eine Fehlannahme meinerseits davon aus zu gehen, dass die ispconfig-Datenbanken durch den Galera repliziert würden. Da ISP MyISAM als Tabellenformat nutzt, und Galera nur InnoDB repliziert, hat der damit gar nichts zu tun, sondern die Erwartung war falsch.
wenn ich die server.sh jeweils manuell starte, läuft alles nach Handbuch.

Die Frage ist also warum der cronjob dafür nicht das tut was er soll. Ich kommentiere den Cronjob jetzt auf einem der Server nochmal ein. Vllt. löst das das Problem ja schon wenn die Crontab man neu installiert wurde. Aber gerade eben war das Fehlerbild folgendermaßen:

SRV1 führt wie gewohnt Änderungen direkt in der Master-DB aus.
SRV2 mit deaktivierten Cronjob. Repliziert die Änderungen des Masters, sofern die server.sh manuell gestartet wird.
SRV3 mit aktivierten Cronjob. Tut auch nach 5 Minuten gar nichts. server.sh läuft aber Normal nach manuellem Start.

Immerhin.  Ich dachte schon ich hätte ein schwarzes Loch konstruiert und das sei mir aufgrund der Zeitverzerrung noch nicht aufgefallen. 

PS: Die Verwirrung bezüglich der Tabelleninhalte stammte auch daher, das Galera durchaus die CREATE Anweisungen der ispconfig-Datenbaneken repliziert. Nur eben nicht die Daten sobald Galera merkt das es sich um MyISMA Tabellen handelt. Daher sind auch alle 3 Datenbanken der Server erstmal überall sichtbar, zeigen aber nicht das Verhalten, das dadruch geweckt wird. Muss man sich auch erst mal merken.


----------



## Till (10. Okt. 2014)

srv2: Cronjob problem.
srv3: Schau mal nach ob für den im master (interface) ausgewählt ist dass er ein mirror von srv1 ist.

und das mit dem nicht replizieren in galera erklärt auch warum die interfaces nicht gingen. Du musst also die config so ändern dass sie sich auf die master db remote verbinden oder Du änderst den ispconfig tabellentyp überall zu innodb, ist aber ein wenig blöd mit updates da du dann ggf. die sql patch files checken müsstest und dort auch innodb setzen, bevor du das update installierst.


----------



## rootfuchs (10. Okt. 2014)

Zitat von Till:


> Schau mal nach ob für den im master (interface) ausgewählt ist dass er ein mirror von srv1 ist.


Ist gegeben. Du hast mich auch glaube ich missverstanden. Ich habe die Änderungen in der SRV1 gemacht und den Cronjob nach der Debugginganleitung *nur *auf dem SRV2 deaktiviert und die server.sh manuell gestartet. Der SRV3 habe ich erst einmal unangetastet weiter laufen lassen um zu sehen ob der cronjob dort irgendwann anspringt, was er nicht tat. 

Also ist es zumindest auf allen Slave-Servern ein Cronjob Problem. Ich hab den Cronjob auf dem SRV2 jetzt wieder einkommentiert und seitdem tut er seinen dienst wie erwünscht. Offenbar akzeptiert Debian 7 nach der Erstinstallation als Slave die Crontab nicht? Erst ein manuelles öffnen und speichern installiert die crontab wirklich.




Zitat von Till:


> und das mit dem nicht replizieren in galera erklärt auch warum die interfaces nicht gingen.


Jepp. Es ist halt maximal verwirrend die Datenbanken und Tabellen von überall zu sehen, aber nicht deren Inhalte. 



Zitat von Till:


> oder Du änderst den ispconfig tabellentyp überall zu innodb, ist aber ein wenig blöd mit updates


Ja weswegen ich genau das nicht tun werde 
Aber ich wollte das eh noch fragen.
Angemommen ich würde das tun - offenbar gehst Du ja davon aus, das dass keine Auswirkungen im laufenden Betrieb hätte - könnte ich doch theorethisch zumindest alle 3 Server auf einer dbispconfig laufen lassen. 3x standard Install auf einen MariaDB-Galera-Cluster als Datenbank
und jeweils die Configs der ISPC-Interfaces und der ISPC-Server anpassen. Theoretisch zumindest. Oder mach ich nen Denkfehler?


----------



## Till (10. Okt. 2014)

> Angemommen ich würde das tun - offenbar gehst Du ja davon aus, das dass keine Auswirkungen im laufenden Betrieb hätte - könnte ich doch theorethisch zumindest alle 3 Server auf einer dbispconfig laufen lassen. 3x standard Install auf einen MariaDB-Galera-Cluster als Datenbank
> und jeweils die Configs der ISPC-Interfaces und der ISPC-Server anpassen. Theoretisch zumindest. Oder mach ich nen Denkfehler?


Dann verlierst Du die Ausfallsicherheit da ja alles nur noch auf den master connected und Du verlierst die Skalierbarkeit da sich alle Dienste wie postfix etc. auf die DB connecten müssten und die wären dann auch down wenn Dein master ausfällt und es kann zu Problemen kommen dass Daten nicht atomar sind, also dass aus Sicht des slaves Daten "aus der Zukunft" in seiner DB stehen bevor er sie bearbeitet hat was alle möglichen negativen Seiteneffekte haben kann.


----------



## rootfuchs (16. Okt. 2014)

Hallo Till,

hat leider ein paar Tage gedauert bei mir. Danke nochmal für Deine Unterstützung. Ohne Deine Mithilfe hätte ich mir sicher noch ein paar Tage den Wolf gesucht ^^ 



Zitat von Till:


> Dann verlierst Du die Ausfallsicherheit da ja alles nur noch auf den master connected


Ich glaube in dem Fall nicht. 
Vorrausgesetzt ISP3 liefe auf InnoDB-Tabellen und würde repliziert, könnte jeder Server auf seine lokale Version der dbispconfig zugreifen und im Falle eines Ausfalles eines der Server, würden die restlichen einfach weiter machen. Galera ist ja eine multi Master Replikation. 

Aber die Killer sind eh nicht weit:

1.)
Wie Du schon gesagt hast:


Zitat von Till:


> es kann zu Problemen kommen dass Daten nicht atomar sind, also dass aus Sicht des slaves Daten "aus der Zukunft" in seiner DB stehen bevor er sie bearbeitet hat was alle möglichen negativen Seiteneffekte haben kann.


2.)
Hinzu kommt das Maria-Galera nur Transaktionen akzeptiert aber LOCKs der Tabellen ignoriert. Was dann zu einigen inkonsistenzen führen würde denke ich.

3.) Wie Du ja gesagt hast ist allein der Verlust der Updatefähigkeit schon ein K.O-Kriterium für solche experimente.


----------

