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, ...)
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 ..
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, ...).
- 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. ;-)
- 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?
- 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.
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
