# [ISPConfig3] Recommended Cluster Setup



## mattula (4. Jan. 2012)

Hi Till,
ich mach jetzt mal ein eigenes Thema draus, da ich denke, dass es von allgemeinem Interesse und auch nicht unbedingt Distributions-spezifisch ist und beziehe mich dabei auf:
http://www.howtoforge.de/forum/27641-post7.html

Die Frage(n) nochmal zusammengefasst:

Welches waere das "Recommended ISPConfig3 Cluster Setup" fuer einen HA Cluster mit automatischem Failover?  

Ich setze voraus, dass zur Umsetzung alle Moeglichkeiten zu Verfuegung stehen. D.h. es steht wahlweise redundante Hardware, eine Enterprise vSphere Umgebung oder vergleichbares zur Verfuegung. Es stehen wahlweise NAS (in Form von NFS) oder SAN (Fibre Channel, iSCSI oder auch eine shared VM Disk) zur Verfuegung.
Ebenso ist der Fragesteller frei in der Wahl der Distribution und Software und ihrer Konfiguration (Mysql mit/ohne Replikation, Gluster-FS, ocfs2, rsync, Unison, Heartbeat. RH-Cluster Suite, Corosync, Pacemaker, ....).


Gruss,
Matthias


----------



## Till (4. Jan. 2012)

Das ist nicht so einfach zu beantworten, denn es gibt da ja 2 Ansätze.

1) Ein setup bei dem die Software auf dem Server nichts von der HA Fähigkeit "weiß" bzw. sie nicht dafür konfiguriert werden muss. Das wäre dann ein Setup mit z.B. vsphere oder einer anderen Virtualisierungslösung die den den HA-Teil außerhalb des Servers verwaltet indem Sie einfach die ganze Server Instanz im Falle eines Fehlers verschiebt. Das ist vermutlich die am einfachsten zu konfigurierende Lösung, aber wohl auch die teuerste. Ein weiteren Nachteil neben dem Preis sehe ich darin dass es halt nur ein failover ist, also Loadbalancing nicht beinhalten kann.

2) Ein anderes Setup ist es, wenn die Dienste in den Servern so konfiguriert werden, dass sie von 2 oder mehreren Servern Ressourcen gemeinsam nutzen. Dazu erstmal ein paar Ausführungen was auf allen Servern abgeglichen werden müsste:

- Konfigurationsdaten (z.B. User in /etc/passwd, /etc/shadow), die apache vhost Konfigurationsdateien etc. Der Ableich dieser Daten kann von ISPConfig selbst durchgeführt werden, denn im Mirror Modus führt erstellt jeder ISPConfig slave die identische Konfiguration auf jedem mirror node.

- Nutzdaten: Neben den Konfigurationsdateien gibt es noch die Nutzdaten, emails, php scripte etc. Diese Daten liegen in 2 Verzeichnissen: /var/vmail und /var/www. Die Inhalte dieser beiden Verzeichnisse müssen allen Servern des Clusters zur Verfügung stehen, dafür gibt es verschiedene Technologien wie DRBD, Glusterfs, gemeinsames NFS Laufwerk, SAN, unison, rsync etc. Die Erfahrungen die ich bisher mit Glusterfs gemacht habe sind recht gemischt, es funktioniert gut für /var/vmail aber bei /var/www kann die Leistung einbrechen, da glusterfs bei sehr vielen kleinen Dateien nicht so gut performt. Meine Erfahrung bezieht sich aber nicht auf die aktuellste Glusterfs Versionen, daher kann das inzwischen schon besser sein. Cluster dateisysteme benötigen eine hohe Netzwerk Bandbreite, daher ist es keine Option für langsamere Verbindungen mit nur ein paar Mbit, in dem Fall würde ich zu Unison raten und nur alle 5 oder 15 Minuten Syncen.

- Logdateien: Die Logdateien der Webseiten befinden sich in /var/log/ispconfig/httpd/. Dieses Verzeichnis sollte man je nach Setup mit syncen, wenn man auf aktuelle Logs auf beiden Servern angewiesen ist.

- MySQL Datenbanken: Zum Synchronisieren von den MySQL Datenbanken der Webseiten (es geht hier nicht um die dbispconfig oder mysql.mysql DB, denn die synct ISPConfig selbst) gibt es verschiedene Technologien. Wenn es sich um einen hot standby cluster handelt kann man z.B. die MySQL Verzeichnisse auf ein drbd Laufwerk packen oder glusterfs nehmen, da gibt es aber diverse Probleme wie im Tutorial beschrieben, so dass ich das bei neuen setups so nicht mehr machen würde. Es bleiben die Alternativen  MYSQL Master/Master Replikation und MySQL Cluster. Erfahrungswerte zu den beiden Optionen kann ich noch nicht geben, da ich das Setup mit Master/Master Replikation gerade aufbaue. Ich halte uch mysql Cluster für eine gute Lösung, müsste man aber mal testen. was auf jeden fall zu beachten ist ist dass man möglichste die Datenbanken mysql.mysql und dbispconfig von der Synchronisation ausnehmen sollte, damit sich mysql und ISPConfig dabei nicht in die Quere kommen.


----------



## mattula (4. Jan. 2012)

Zitat von Till:


> Das ist nicht so einfach zu beantworten, denn es gibt da ja 2 Ansätze.
> 1) Ein setup bei dem die Software auf dem Server nichts von der HA Fähigkeit "weiß" [...]


Ist mir klar, die Variante wollte ich hier  auch nicht eruieren. Ich habe Vsphere nur als Resource gemeint in meiner Aufzaehlung. Wir betreiben bspw. Active/Passive Linux-Heartbeat Cluster mit DRBD auf ESXi Servern mit Local Storage.

Alternativ waere auch ein Active/Active Linux Cluster in der Vsphere Umgebung mit Shared Storage denkbar. Als Blockdevice fuer ein Cluster FS koennet dann z.B. eine gemeinsame vmdk im Shared Storage zum Einsatz kommen. Warum nicht gleich NFS? Weil sich dort z.B. keine usrquota implementieren lassen (zumindest nicht so, dass sie sich in ISPconfig migrieren). Warum ueberhaupt Linux Cluster auf einer schon geclusterten Vsphere Umgebung? Ein paar Vorteile gibt es dabei schon: Ein Node kann in die Wartung genommen werden, bei Active/Active kann auch LB eingesetzt werden, ...)



Zitat von Till:


> 2) Ein anderes Setup ist es, wenn die Dienste in den Servern so konfiguriert werden, dass sie von 2 oder mehreren Servern Ressourcen gemeinsam nutzen.



Genau, das ist das Thema, was ich gerne vertiefen wuerde. Nicht unbedingt gleich in die Konfigurationsdetails hinein, sondern erstmal auf Ebene der Mechanismen, Moeglichkeiten, Vor- und Nachteile.

Was ich bislang versucht habe, war ISPConfig auf einem Active/Passive Heartbeat Cluster mit Shared Storage zu implementieren. Dabei habe ich lediglich eine ISPConfig Instanz konfiguriert und diese wiederum wie jede andere zu clusternde Anwendung auch betrachtet.
D.h. zur Synchronisation von nicht ganz zeitkritischen Konfig Dateien kommt csync2 zum Einsatz (minuetl. per Cron). Alles andere, was in Echtzeit synchron  und/oder nur auf dem aktiven Node aktiv sein soll liegt auf dem Shared Storage und wird per Symlink (drbdlinks) im jeweils aktiven Cluster Node an Ort und Stelle verlinkt. Als Shared Storage verwenden wir i.d.R. DRBD (active/passive) mit ext3, im speziellen Fall habe ich jedoch einen NFS Share genommen und diesen aber wie einen DRBD Share behandelt (mount/unmount als HB-Resource und entsprechende Verlinkung per drbdlinks) .

Dieses Setup kollidiert jedoch an einigen Stellen mit ISPConfig, oder zumindest erzeugt es Warn- bzw. Fehlermeldungen. Wobei es im End schon funktioniert hat (das Problem mit den Home Permissions hat sich ja als ISPConfig Bug herausgestellt). Stichworte zu den Fehlermeldungen: Symlinks auf /var/www werden vom ISPConfig angemeckert, Hardlinks vom Jailkit funktionieren nicht Cross-device, ...)

Und, wie du ja auch auffuehrst, ISPConfig bringt schon ein paar Mechanismen mit, die in meinem Setup einfach ignoriert wurden.

Also weiter ..



Zitat von Till:


> Dazu erstmal ein paar Ausführungen was auf allen Servern abgeglichen werden müsste:
> - Konfigurationsdaten (z.B. User in /etc/passwd, /etc/shadow), die apache vhost Konfigurationsdateien etc. Der Ableich dieser Daten kann von ISPConfig selbst durchgeführt werden, denn im Mirror Modus führt erstellt jeder ISPConfig slave die identische Konfiguration auf jedem mirror node.


Ja, das ist wahr. Die Liste muss halt klar definiert sein, da es hier auf jeden Fall Ueberschneidung mit Dateien gibt, die im Cluster auch synchronisiert werden muessen (passwd, hosts, resolv.conf, ...).




Zitat von Till:


> - Nutzdaten: [...] 2 Verzeichnissen: /var/vmail und /var/www. [...] dafür gibt es verschiedene Technologien wie DRBD, Glusterfs, gemeinsames NFS Laufwerk, SAN, unison, rsync etc. [...] Cluster dateisysteme benötigen eine hohe Netzwerk Bandbreite, [...] in dem Fall würde ich zu Unison raten und nur alle 5 oder 15 Minuten Syncen.


Mit Cluster FS an sich hab ich auch schon mehr oder weniger gute Erfahrung gemacht. Sie benoetigen nicht nur Netzwerkbandbreite, sondern auch einen performanten Storage untendrunter.
OCFS2 auf DRBD auf virtueller Hardware mit SATA Raid untendrunter macht z.B. keinen Spass, auch nicht wenn die Serverhardware von DELL und der Storage von Netapp komt.
OCFS2 hingegen auf FC Lun, die ihrerseits wiederum von einer Netapp mit SAS Platten kommt performt schon wesentlich besser. Der Benchmark Vergleich in dem Fall mit ext3 statt ocfs2 zeigt kaum signifikante Unterschiede auf. 
Na ja, und ext3 auf DRBD in virtueller Umgebung im actice/passive Setup ist in Ordnung, wenn Netzwerkanbindung und Storage untendrunter passen.

Ich bin auch grad am Ueberlegen, Unison fuer die Synchronisation einzusetzen. Wobei ich dann eventuell zusaetzlich iWatch zum Triggern von Unison nutzen wuerde, um eine Synchronisation immer dann anzustossen, wenn grad eine Aenderung geschehen ist. Sozusagen Fast-Echtzeitsynchronisation fuer Arme. ;-)



Zitat von Till:


> - Logdateien: Die Logdateien der Webseiten befinden sich in /var/log/ispconfig/httpd/. Dieses Verzeichnis sollte man je nach Setup mit syncen, wenn man auf aktuelle Logs auf beiden Servern angewiesen ist.


Hm, ... laesst ich das Logging nicht vielleicht ueber Remote Syslog loesen?
Einfach alles ueber Kreuz loggen?



Zitat von Till:


> - MySQL Datenbanken: Zum Synchronisieren von den MySQL Datenbanken der Webseiten (es geht hier nicht um die dbispconfig oder mysql.mysql DB, denn die synct ISPConfig selbst) gibt es verschiedene Technologien. Wenn es sich um einen hot standby cluster handelt kann man z.B. die MySQL Verzeichnisse auf ein drbd Laufwerk packen oder glusterfs nehmen, da gibt es aber diverse Probleme wie im Tutorial beschrieben, so dass ich das bei neuen setups so nicht mehr machen würde. Es bleiben die Alternativen  MYSQL Master/Master Replikation und MySQL Cluster.


Das ist auch aktuell mein Hauptproblem. Vor Jahren habe ich mal Master/Slave Replikation mit Mysql verwendet und das war wenig erfreulich.
Stichworte: Autoincrement Konflikte, nicht stattfindende Variablenaufloesung und nochwas, was mir grad nicht einfaellt
Master/Master ist ja nichts viel anderes wie ein Master/Slave ueber Kreuz. Ok, das mit den Autoincrements soll wohl durch den Offset geloest sein, aber irgendwie hoert sich das fuer mich nachwievor frickelig an.



Zitat von Till:


> Ich halte auch mysql Cluster für eine gute Lösung, müsste man aber mal testen.


Mysql Cluster? Braucht es dafuer nicht mind. 3 Hosts/Instanzen?

Und was jetzt noch fehlt ist der Cluster/Resource-Manager, der am besten schon auf Dienstebene ueberwacht und entsprechend einen Schwenk macht. Natuerlich inkl. der IP.


Ich versuche mich mal an einer "Feature" Liste:

Ziel: ein moeglichst simpler und zuverlaessiger HA Cluster (nicht LB)

Relativ klar und einfach zu realisieren ist folgendes:


2 Server (virtuell oder physikalisch)
Idealerweise mind. 2 Netzwerkinterfaces. Physik. oder durch VLAN getrennt. Eines fuer Dienste, eines fuer Synchronisation.
ISPConfig Setup als Master / Mirror. Damit ist schonmal festgelegt, dass ein bestimmtes Set an Konfigdateien autom. auf beiden Nodes synchron ist. Ausserdem koennen somit die "mysql" und die "ispconfigdb" jeweils lokal laufen.
Synchronisation sonstiger Konfigdateien per Csync2 oder Unison.
Synchronisation von /var/www, /var/vmail per Unison. Hier ist zu ueberlegen eine quasi Echtzeitsynchronisation mit Hilfe von iWatch zu erreichen.
Offen ist noch:


Mysql Benutzerdatenbanken: Master/Master, Mysql Cluster oder Mysql auf Shared Storage
Cluster IP Umschaltung (*)
Dienste-Umschaltung oder Reload: Mind. ein reload der Dienste ist i.d.R. notwendig, wenn sich die Cluster IP(s) aendern (*)
Rollenwechsel ISPConfig Mirror / Master (**)
(*) Hier stehen die klassichen Varianten zur Auswahl: Heartbeat, Pacemaker, Redhat-Cluster-Suite (auch unter Debian verfuegbar)

(**) Das ISPConfig Master/Mirror Setup ist mir noch nicht ganz klar. Vor allem das Handling in dem Fall, wen ich den Mirror zum Master machen will und umgekehrt. Das muesset sich ja idealerweie auch ueber Scripte triggern lassen, damit es als Resource im Cluster automatisch mitschwenken kann.

Gruebel .... bei den ganzen offenen Fragen, ueberlege ich, ob es nicht doch 
sinnvoller ist, die ISPConfig Installation wie Eingangs erwaehnt einfach als Single Instanz zu begreifen und wie alle anderen Dienste (in dem Fall auch MYsql) auch zu clustern.

Das wuerde dann halt fast zwingend ein Shared FS erforderlich machen, zumindest fuer /var/lib/mysql. Koennte im Prinzip auch ein Cluster FS sein, welches immer nur auf einem Node gemountet wird (ist es dann perfomanter?) oder NFS oder halt doch wieder DRBD mit ext3.
Oder doch "nur" Mysql Master/Master Replikation (aber in dem Fall dann inkl. "mysql" und "ispconfigdb") !? 

Grosser Vorteil: 


Alle Dienste werden ueber den Resource Manger gesteuert. Failover und Failback, falls gewunscht, kann automatisch erfolgen.
Moderne Cluster Manger (pacemaker, rhcs, ..) koennen auf Prozessebene ueberwachen, auf Load reagieren, ...
Eine Umschaltung, vor allem auch eine ungewollte bewirkt i.d.R. keinen Datenverlust (wenn Aenderungen wahlweise sofort synchronisiert werden oder ein Shared Storage verwendet wird)
Nachteil:


Es ist ein Shared Storage erforderlich
und/oder Mysql muss als Master/Master repliziert werden
Gruss,
Matthias


----------



## Till (5. Jan. 2012)

> Hm, ... laesst ich das Logging nicht vielleicht ueber Remote Syslog loesen?
> Einfach alles ueber Kreuz loggen?


Das Logging geschieht zum einen über vlogger (access logs) und zum anderen direkt vom apache für die error.logs. Ob vlogger das kann bzw. ob man es unter umstänfen erweitern kann (ist ein perl script) müsste man mal sehen.

Unter Umständen könnte man auch einfach jeweils lokal loggen und dann die logs mergen bevor die Statistik erstellt wird.



> Mysql Cluster? Braucht es dafuer nicht mind. 3 Hosts/Instanzen?


Jein. Ich hab mir mal die Doku angesehen und man braucht zwar 3 Instanzen, die können aber theoretisch sogar alle auf dem selben host laufen. Man könnte also mit 2 Servern arbeiten und die management Instanz, die soweit ich gesehen habe nur zur Wartung genutzt wird, auf einen der beiden Server mit drauf packen.



> Cluster IP Umschaltung (*)


Zu den IP-Adressen hab ich noch eine IP Aliastabelle gplant, also in der Art: 

IP 1.1.1.1 ist IP 1.1.1.2 auf server 2 
IP 1.1.1.1 ist IP 1.1.1.3 auf server 3

Dann kannst Du auf die Umschaltung der IP verzichten und stattdessen einen Lodbalancer einsetzen, der die Verfügbarkeit aller Server des Clusters überwacht und die http requestst entsprecehnd umleitet. Für pop3, Imap gibt es das meines Wissens nach auch, wobei dort die IP egal ist. Beim apache geht das im Moment zwar auch schon mit * vhosts, aber wenn man ssl ohne sni braucht, geht kein Weg an der festen IP vorbei.



> Rollenwechsel ISPConfig Mirror / Master (**)


Das ist eine Sache die nicht ganz einfach sein wird, da der Mirror aus Sicherheitsgründen nicht alle Daten hat. Ich denke dass man hier abwägen muss, denn es ist ja nur die Erreichbarkeit des ISPConfig Interface vorübergehend eingeschränkt, es lassen sich also z.B. keine neuen Webs anlegen während die Seiten und Mail accounts etc. ja alle weiter laufen und somit die eigentliche Funktionalität des Servers nicht eingeschränkt ist.

Es lässt sich da aber auch etwas anderes mit ISPConfig zusammenbauen. ISPConfig besteht ja generell aus 2 getrennten Teilen, dem Interafce (Verzeichnis /usr/local/ispconfig/interface) und dem Server Teil (/usr/local/ispconfig/server). Das Interface ist prinzipiell eine normale PHP basierte Webseite und würde sogar auf einem Windows IIS Server mit PHP laufen, es benötigt lediglich eine Verbindung zu einer mySQL Datenbank des Masters. Wenn man jetzt also die MySQL Datenbank des Masters z.B. auf einen mySQL Cluster legen würde, könntest Du an siech beliebig viele ISPConfig interfaces auf diversen Servern betreiben, das Interface muss also selbst bim master nicht auf dem master liegen, sondern es muss lediglich in der config.inc.php die Login Daten zur Datenbank welche den master repräsentiert haben.

Zum Theme clusterng habe ich übrigens gestern noch was im stable SVN hochgeladen, die Linux Systemuser und Gruppen ID's der Webseiten lassen sich jetzt fest an die numerische ID des Webs binden (System > Server config > web), so dass sichergestellt ist dass alle User im Cluszer auch wirklich die gleiche ID bekommen, selbst wenn jemand mal auf einem Cluster node einen user manuell hinzufügt ohne dies auf den anderen Nodes auch zu machen. Das Ganze geht nach dem Schema (konfigurierbare) min. Userid + webid.


----------

