Linux-Anwendungen ausfallsicher betreiben
Cluster auf Open-Source-Basis
Business-Applikationen, E-Commerce-Lösungen und Download-Portale müssen rund um die Uhr erreichbar sein. Denn mit jedem Systemausfall drohen finanzielle Einbußen und ein nur schwer zu beziffernder Imageschaden. Dabei lässt sich Hochverfügbarkeit für viele Anwendungen aus dem Linux-Umfeld wie Mysql-Datenbanken, NFS-Server oder Apache-Web-Server auch ohne erheblichen Kostenaufwand erreichen. Die Lösung bieten Cluster auf Open-Source-Basis.Vielen Unternehmen wird erst im Schadensfall bewusst, was ein Systemausfall wirklich kostet. Bei Installationen, die nicht redundant aufgebaut sind, kann ein kleiner Hardware- oder Softwaredefekt schnell zu mehrstündigen Ausfallzeiten führen. Professionelle Hosting-Anbieter gewährleisten meist einen Hardwareaustausch innerhalb von zwei Stunden, doch damit ist es selten getan. Cluster-Lösungen bieten zwar die gewünschte Hochverfügbarkeit, meist sind die dafür benötigten Softwarelizenzen jedoch recht teuer. Eine praxiserprobte und kostengünstige Alternative bieten jedoch Cluster auf der Basis der Open-Source-Lösungen DRBD (Distributed Replicated Block Device) und Pacemaker. Damit lassen sich Linux-basierende Anwendungen wie Mysql-Datenbanken, NFS-Server oder Apache-Web-Server ausfallsicher betreiben. Mithilfe von DRBD und Pacemaker lassen sich die Daten automatisch auf beiden Servern replizieren. Sollte es zu einem Hardwareausfall kommen, greift ein automatischer Failover-Mechanismus. Ohne manuellen Eingriff übernimmt dabei der funktionsfähige Server die ausgefallenen Dienste und Anwendungen und startet sie mit der gleichen Netzwerkkonfiguration. Je nach Auslastung des Systems sind alle Dienste und Anwendungen innerhalb von Sekunden oder wenigen Minuten wieder vollständig verfügbar. In der Regel besteht ein DRBD-Cluster aus zwei Servern, die idealerweise über mindestens drei freie Netzwerkwerk-Interfaces verfügen. Die Ausstattung der Server hinsichtlich CPU-Leistung, RAM und Speicherplatz sollte identisch und so ausgewählt sein, dass sich alle Anwendungen und Daten auch auf einem einzigen Server performant betreiben lassen. Dies ist wichtig, damit es im Ausfallszenario nicht zu einem Engpass der zur Verfügung stehenden Ressourcen kommt. Auf beiden Servern müssen die gleichen Linux-Betriebssysteme und Anwendungen installiert sein. Aktuell zu empfehlen sind Debian 6.06, Ubuntu 12.04 oder Centos 6.3., da dafür Updates verfügbar sind. Als weitere Software ist erforderlich: Pacemaker ist für die Verwaltung der Cluster-Ressourcen wie zum Beispiel der Datenbanken oder Dienste (NFS, Tomcat etc.) verantwortlich. DRBD sorgt für eine automatische Replikation aller neuen oder geänderten Daten. Corosync stellt die Kommunikationsschicht für Pacemaker dar. Corosync startet die Dienste des Cluster-Managers und gewährleistet die Übertragung des Cluster-Status zwischen den Cluster Nodes. Pacemaker, DRBD und Corosync lassen sich kostenlos über die Paketverwaltung aus den jeweiligen Respositories der Linux-Distributionen installieren. Hardwareseitig sind die Server per Crossover-Verkabelung direkt miteinander verbunden. Beide Server werden jeweils mit einer Netzwerkverbindung (Uplink) für die Außenanbindung ausgestattet. Eine jeweils redundante Crossover-Verkabelung und Außenanbindung empfiehlt sich, da so auf relativ kostengünstige Weise bei einem Kabeldefekt oder beim Ausfall einer Netzwerkkarte Redundanz gewährleistet ist. Um eine optimale Verfügbarkeit der replizierten Daten sicherzustellen, sollten die Daten nicht etwa auf einen externen Storage ausgelagert sein, sondern redundant auf den lokalen Festplatten der beiden Server residieren. Es empfiehlt sich, auf beiden Servern jeweils eine Partition für das Betriebssystem, die aktuelle Konfiguration sowie die Server-Dienste wie zum Beispiel Mysql-Dienst oder NFS-Server zu reservieren. Dabei ist auf einen identischen Aufbau beider Nodes zu achten. Lediglich die Netzkonfigurationen sind individuell. Eine weitere Partition, das so genannte DRBD-Volume, reserviert der Administrator für die Nutzdaten der Cluster-Dienste wie Content von Web-Servern, Datenbanken oder PHP-Skripte. Jeder Dienst, der auf dem DRBD-Cluster aktiv läuft, erhält eine eigene IP-Adresse, die so genannte Service-IP. DRBD repliziert automatisch alle Daten zwischen beiden Servern und hält sie damit synchron. Dabei arbeitet es mit einer blockweisen Replikation, indem es sich aktiv zwischen Dateisystem und Festplatte schaltet und die Änderung der Blöcke protokolliert sowie übermittelt. Dies erfolgt wesentlich performanter und garantiert einen schnelleren Datenaustausch als beispielsweise die Dateireplikation durch das Tool "rsync". Idealerweise empfehlt es sich, für die Betriebsdaten sowie das DRBD-Volume jeweils ein eigenes RAID-Volume vorzusehen. Wer Mysql als Cluster-Dienst konfigurieren will, sollte zudem das "datadir"-Verzeichnis so anpassen, dass die Daten auf das DRBD-Volume verweisen. Für die Verwendung von Apache als Cluster-Dienst müssen die "DocumentRoot"-Einträge ebenfalls auf die DRBD-Partition verweisen. Hardwareanforderungen und automatisches Failover Beide Nodes müssen so ausgelegt sein, dass sich beim Ausfall eines Servers alle Dienste auch auf einem einzigen Node betreiben lassen, da dann nur noch 50 Prozent der ursprünglichen Ressourcen zur Verfügung stehen. Performanceengpässen bei steigendem Speicher- und Bandbreitenbedarf sollte der Administrator mit folgenden Ansätzen begegnen: Zum einen lässt sich durch Aggregieren weiterer Gigabit-Links zu einem größeren Bonding innerhalb des Cluster-LANs mehr Bandbreite erzeugen. Zum anderen bietet eine Erhöhung der Zahl eingesetzter Festplatten in den jeweiligen DRBD-(RAID)-Volumes die Möglichkeit, die Lese- und Schreib-Performance zu steigern. Die Hochverfügbarkeit der Lösung garantiert ein automatischer Failover-Automatismus. Dieser wird ausgelöst, sobald Pacemaker innerhalb der laufenden Überwachung die Nichterreichbarkeit eines Servers oder einer Anwendung feststellt. In der Regel legt die Administration einen DRBD-Cluster als Aktiv-Passiv-System an. Somit versetzt Pacemaker lediglich das DRBD-Volume auf dem funktionsfähigen Cluster Node in die primäre Rolle und bindet dieses ein. Abschließend wird die Service-IP gesetzt und der eigentliche Cluster-Dienst gestartet. Ab diesem Zeitpunkt ist die Anwendung unter der gleichen IP-Adresse wieder verfügbar. Sinnvollerweise sollte sich ein Cluster über ein System-Monitoring mit automatischen Fehlermeldungen überwachen lassen. Vor- und Nachteile Im Gegensatz zu Lösungen, die auf Shared Storage basieren, bietet DRBD den Vorteil, die Daten lokal auf allen Cluster Nodes vorzuhalten. Beim Ausfall eines Nodes lässt sich der konfigurierte Cluster-Dienst daher ohne eine zusätzliche Storage-Komponente auf dem verbleibenden Node weiterbetreiben. Bei Wartungsarbeiten kann der Administrator die aktiven Dienste manuell auf den bis dahin passiven Node übertragen, ohne dass es zu einer Nichterreichbarkeit des Systems kommt. Einen Problemfall stellt das Szenario des so genannten "Split Brains" und die dadurch resultierende Asynchronität der Daten dar. Denn sollte es zu einer Unterbrechung des Cluster-LANs kommen, ergibt sich zwangsläufig ein ungewolltes und unkontrolliertes Master-Master-Verhalten der beiden Server, ohne dass eine vermittelnde Instanz die geschriebenen Daten überwachen beziehungsweise replizieren kann. Im DRBD-Cluster sollten zur Kommunikation im Cluster-LAN daher keine "Single Links" zum Einsatz kommen. Eine kostengünstige Empfehlung ist es, ein redundantes Cluster-LAN über Crossover-Verkabelung zu realisieren. Alternativ dazu lassen sich die Nodes über redundante Switches miteinander verbinden. Do it Yourself, Colocation oder gehostete Komplettlösung Grundsätzlich lässt sich eine Cluster-Umgebung von einem erfahrenen Systemadministrator auch selbst einrichten. Anleitungen dazu finden sich auf einschlägigen Portalen und den offiziellen Websites der Open-Source-Lösungen. Eine "Do it Yourself"-Lösung eignet sich vorzugsweise für den Aufbau von Testumgebungen, um das Funktionsprinzip oder Konfigurationen zu prüfen. Optional lassen sich DRBD-Cluster dabei auch mittels virtueller Umgebungen aufbauen. Dazu lässt sich jede Virtualisierungslösung wie zum Beispiel VMware, KVM, Xen etc. nutzen. Will ein Unternehmen einen DRBD-Cluster jedoch professionell betreiben, sollte dieser in eine leistungsfähige Infrastruktur eingebunden sein. Dazu gehören redundante Netzanbindungen, ausfallsichere Stromversorgung sowie eine Außenanbindung mit ausreichender Bandbreite. Außerdem sollte der Anwender den Kostenfaktor Traffic nicht unterschätzen, der bei vielen Hostern meist schon über eine Flatrate abgedeckt ist. Daher empfiehlt es sich, einen DRBD-Cluster in einem professionellen Rechenzentrum als Colocation oder Managed-Hosting-Lösung zu betreiben. Dienstleister wie beispielsweise Host Europe garantieren dann für den als Managed-Hosting-Lösung angebotenen DRBD-Cluster eine Verfügbarkeit von immerhin 99,995 Prozent.
Lesen Sie mehr zum Thema
