ForumHA-Konzept
From RootForum Community » Wiki
Contents |
Rootserver:
Status: In Bearbeitung. Hochverfügbarkeit und horizontale Skalierung ein einfaches Konzept
Jeder der einen Webservice betreibt wird früher oder später vor dem Problem stehen, dass der Service auch 24*7 mit möglichst wenig Downtime verfügbar sein soll. Die wenigsten haben jedoch die Möglichkeit eine 24*7 Besetzung zu gewährleisten. Andere wiederum, leiden an einem rasanten Wachstum und stellen sich die Frage, wie Sie weiterhin performante Verfügbar sein können. Nachfolgende eine kurze Dokumentation, wie man mit relativ einfachen Mitteln eine annähernd Hochverfügbarkeit* und Lastverteilung bewerkstelligen kann.
- Siehe http://de.wikipedia.org/wiki/Hochverfügbarkeit darf man auch bei HA, sofern man es realistisch betrachtet im Umfeld von Rootsevern und den durch die Provider zugesicherte SLA, mehrere Tage pro Jahr down sein.
Man kann also getrost auf eine Heartbeat Lösung mit automatic Failover verzichten. Insbesondere wenn man im Falle eines Stromausfalles damit rechnen muss, dass alle Hosts davon betroffen sind. Das notwendige VLan für unser vorhaben bekommt man nur innerhalb eines Providernetzes. Eine Alternative, allerdings nur aus rein theoretischer Sicht, wäre dann ein VPN statt vLan. Praktisch unterliegt ein VPN zwischen 2 oder mehr Providernetzen zu hohen Schwankungen in punkto Durchsatz und Stabilität, sodass diese Lösung für unser Vorhaben nicht geeignet ist.
Einleitung / Erläuterung
Ich habe es mir einfach gemacht und eine Zeichnung mit einer sinnvollen max. Tiefe typischer Webanwendungen eingestellt. Horizontal kann dieses jedoch "beliebig" ausgeweitet werden.
- Soweit, wie es der Durchsatz des Netzwerkes / Interface des 1. Servers mit macht.
Auch zur Clusterip gibt es je nach Provider unterschiedliche Lösungen. So bietet z.B. die Strato AG neben einer Clusterip auch eine Loadbalancer IP. Letzteres kommt etwas teurer ist aber bei einer gute besuchten Webseite die beste Lösung um den Traffic gut zu verteilen zudem ermöglicht dieses schon einen guten Grundschutz für einen ausfallsfreien Betrieb ohne manuellen Eingriff. Wir erinnern uns jedoch daran, dass die wenigsten Provider eine Hochverfügbarkeit der Verfügbarkeitsklasse 4 oder besser anbieten. Entsprechend kann also im Falle eines Falles mehrere Tage Downtime trotzdem möglich sein. Die Details zur SLA entnehmt Ihr bitte eurem jeweiligen Vertrages bzw. den AGB. Vor diesem Hintergrund stellt sich die Frage, ob es der zusätzliche Preis wert ist.
Nachfolgend 3 Varianten beschrieben, welche im Dokument angesprochen werden.
Variante 1 reine Failover Betrieb
Hier befindet sich die Firewall, der Webserver und das Datenbanksystem auf einem System. D.H. in diesem Szenario sind lediglich 2 Servernodes beteiligt und werden im Bedarfsfall umgeschaltet. Das bedeutet auch, dass hier nur eine Node aktiv ist und die 2. Node Standby auf den Worstcase wartet um die Dienste zu übernehmen. Bei Firewall spreche ich von einer WAF. Web Application Firewall und nicht iptables. Da brauchen wir nicht, denn auf der Clusterip horchen nur die Dienste, die auch wirklich erreichbar sein sollen. Also http,https,imap,impas, pop3,pop3s, smtp und meinetwegen noch ftp. Und anichts anders über die Blusterip erreichbar ist, brauchts auch keine Firewall in form von IPtables dafür.
Variante 2 Load Balancing mit Firewall / Proxy
Sofern der bisherige Provider z.B. keine Balancer Ip anbietet, muss man sich selbst darum kümmern. Hier hilft mod_balance des Apache Webservers. Dies kann mit 3 - 4 Servern erreicht werden. (Bei 3 Servern ist das Risiko eines Ausfalles natürlich deutlich höher.) Die Aufgaben werden getrennt, so dass es z.B. einen aktiven Load Balancer mit Firewall und Proxy gibt, und die Anfragen im Round Robin verfahren an die dahinter liegenden Web / DB Server verteilen. Diese Lastverteilung reduziert das Ausfallrisiko um ein vielfaches. Aus kostengründen kann man bei weniger stark besuchten Webseiten die Firewall / das Loadbalancing auf Vserver bringen. Bei der Datenbank könnte man nun eine Master Master Replikation anstreben. Grundsätzlich bin ich kein Freund davon und bevorzuge eine Master Slave Replikation sowie den Zugriff nur auf eine phyische Datenbank. Im Falle eines Master Slav Replikation könnte man die Leselast verteilen. Man muss jedoch berücksichtigen, dass mit der Replikation etwas zeit verloren geht und somit auf dem Master aktueller Daten verfügbar sein könnten, als auf dem Slave. Auch wenn wir hierbei nur von millisekunden sprechen.
Variante 3 Getrennte Firewall, Web und DB Server Layer.
Hier trennen wir explizit zwischen Sicherheitseinrichtung, dem Application Layer und dem Persistenz Layer. Der grösste Vorteil daran ist wohl die einfache und breite Skalierbarkeit. Ist ein solches System aufgebaut, lässt sich die Anwendungschicht durch beliebige weitere Applicationserver horizontal skaliert werden. Zudem können die jeweiligen Dienste individuell konfiguriert und optimiert werden. Bei einem typischen Standalone Webserver muss man immer einen Kompromiss aus Datenbank, Webserver und Sicherheitseinrichtungen eingehen. So kann jeder Dienst für sich ganz individuell optimiert werden und Systemressourcen ideal eingesetzt werden.
Hochverfügbarkeit
Um eine Hochverfügbarkeit zu erreichen ist es zwingend notwendig, dass die Daten sowohl der Anwendungsdaten z.B. PHP Scripte, Java Container etc. auf allen betroffenen Systemen im identischen Stand verfügbar ist. Der Kunde soll letztendlich nichts an seinem Komfort einbüssen und sich nicht um die redundante Verteilung der Daten kümmern müssen. Zudem sollen ja auch keine Daten verloren gehen wie z.B. Emails.
Entsprechend muss für die Nutzdaten und ggf. Konfigurationen ein eigener Speicherbereich der Platten (Partition) bereit gestellt werden. Dieser sollte auf beiden Nodes identisch gross sein. Per DRBD syncen wir den Storage über das vlan und zwar nur über das vlan! Somit sind die Daten binär identisch. Der Initiale Sync kann allerdings mehrere Stunden dauern.
Für die reine Verteilung statischer Daten wie Bilder, PHP Scripte und Konfigurationen genügt eine Bandbreite von ca. 10 Mbit. Werden auch Sessiondaten und Emails repliziert sollte man min, auf 100Mbit oder mehr ausweichen. Auch für eine Mysql Master Slave Replikation sollte man auf eine Bandbreite von min. 100Mbit gehen. Wird der DB Storage direkt gesynct (über drbd und ocfs2), sollte man 1GBit anstreben. Um Inkonsistenzen zu vermeiden, ist ein Cluster Filesystem erforderlich. Dieser regelt ebenfalls über das Netzwerk Filehandles und Locks. Hierbei haben sich OCFS2 bzw. GFS etabliert. Die nachfolgende Konfigurationen bauen auf DRBD, OCFS2 auf.
Aus eigener Erfahrung machen ClusterFS gelegentlich Probleme speziell mit einigen Distributionen wie opensuse11.3 So kommt es leider immer wieder zu Zombi Prozessen und nicht mehr schliessenden Filehandles wenn man z.B. IMap User auf dem System hat und redundante Verbindungen zu einem Postfach bestehen. Diese lassen sich nur noch mit einem reboot oder in sehr schlimmen Fällen mit hard resets beseitigen. Die Load steigt zunehmend an, ohne wirkliche CPU Auslastung.
Aus diesem Grund würde ich aktuell nur die statischen Nutzdaten im Sync halten.
Wie wir der Grafik entnehmen wird eine Partition gesynct. Da wir ein ClusterFs einsetzen, kann auf beiden Nodes der Storage gemountet werden und z.B. Sicherungsarbeiten auf der Inaktiven Node durchgeführt werden. Dies entlastet den prod. Webserver immens.
Für den Fall eines Ausfalles, legen wir uns ein Stop und Startscript an. Das Startscript ruft lediglich alle notwendigen init. Scripte auf, um Webserver, Mailserver etc. zu stoppen bzw. zu starten. Zusätzlich wird der Switch der Clusterip beim Provider initiiert. Fast alle Provider bieten Scripte oder einfache Anleitungen an, um einen IP Switch auch per Komandozeile aus zu initiieren. (Da ich nicht alle Providerprodukte getestet habe, kann ich dies nicht generell bestätigen). Zur Datenbank kommen wir in einem späteren Kapitel.
Das wars im Prinzip auch schon. Lediglich der Switch muss nun durch ein Monitoringsystem angetriggert werden.
Lastverteilung
Die Lastverteilung läuft im wesentlichen einfache ab. Der Mailserver / die Mailserver lassen sich per MX Einträge in den DNS Einträgen spezifizieren. Ist einer dieser Hosts nicht erreichbar oder kann eine email nicht annehmen, wird diese an einen anderen verfügbaren Mailserver gesendet. Die Maildienste können "beliebig" auf den Systemen verteilt werden. Die Dienste müssen lediglich von extern erreichbar werden. Auch diesen Storage sollten wir syncen, damit der Endkunde immer auf alle Emails Zugriff hat. Ansonsten müssten wir uns um die Verteilung der Daten kümmern, was nicht ohne weiteres möglich ist.
Wie im Kapitel: Hochverfügbarkeit schon geschrieben, muss man in Verbindung mit Imap/ Dovecot und ocfs2 einige Tests durchführen und Vorsicht walten lassen. Es gibt vereinzelt Probleme, bei denen ich die Ursache nicht genau zuordnen kann sich allerdings ocfs2 und dovecot in Kombination stören.
Die Webserver / Appserver werden über das Load Balancing der Firewall (mod_blance) eingebunden. Hier kann, soweit es die Infrastruktur her gibt, beliebig viele Nodes einbinden. Die weitere Kommunikation verläuft dann ebenfalls übers vlan zur Datenbank. Für die Datenbank folgt ein eigenes Kapitel.
-- Es geht bald weiter.