ISPConfig3 bei Cluster Setup (Interfaces, Ordner )

rootfuchs

Member
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

Administrator
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

Member
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

Administrator
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

Member
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

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

rootfuchs

Member
Nope, ich hab interfec/lib/config.inc.php jeweils nur angepasst damit die Einträge unter
Code:
//** 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
Code:
//** 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

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

Till

Administrator
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

Member
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

Administrator
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

Member
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.
 
Zuletzt bearbeitet:

Till

Administrator
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

Member
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:
Code:
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. ^^
 

rootfuchs

Member
Prüfen ob der MySQL Server auf den Slaves läuft
Tun sie.

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.

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!


o_O Welch Hexerei ist das? :eek:
 
Zuletzt bearbeitet:

Till

Administrator
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

Member
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.
 
Zuletzt bearbeitet:

Werbung

Top