Der Betrieb dedizierter Server ist grundsätzlich von einer ganzen Reihe von Problemen bedroht: Software kann abstürzen; Hardware kann kaputtgehen. Insbesondere um Hardwareprobleme anzugehen, sind bei heutigen Servern insbesondere die beweglichen Teile (die statistisch gesehen am häufigsten kaputtgehen) redundant ausgelegt, zuvorderst die Festplatten im Form eines RAID-Verbunds, ebenso sind in der Regel ein, zwei mehr Lüfter verbaut als unbedingt erforderlich. Luxuriösere Geräte warten vielleicht sogar noch mit redundanten Netzteilen auf.
Und trotzdem: Irgendwo ist Schluss. Eine defekte CPU (in einem Server, der mehrere CPUs hat) oder einen defekten RAM-Riegel verkraften in der Regel maximal Geräte der Enterprise-Klasse, und auch nur die wenigsten Server haben mehrere Netzwerkschnittstellen, die mit redundanten Kabeln am Uplink zum Internet hängen – und selbst wenn, so haben Server in aller Regel immer noch nur ein Mainboard, nur einen RAID-Controller …
An diesem Punkt gibt es dann nur noch eine Möglichkeit, um jede Komponente redundant zu haben: Ein zweites Gerät, das idealerweise identisch konfiguriert ist – und die entsprechende Software-Infrastruktur, damit diese Systeme sich gegenseitig austauschen, überwachen und selbstständig die Dienste des Gegenübers übernehmen, wenn jener nicht mehr reagiert, ganz egal ob das auf einen Hardware-Ausfall oder eine Kernel panic zurückzuführen ist.
Wir verstehen uns sowohl auf den Aufbau klassischer
Failover-Server,
bei denen Heartbeat im Fehlerfall
schrittweise IP-Adressen und Dienste übernimmt.
Allerdings ist ein solches Setup recht aufwendig zu warten:
Einerseits kommt es nur selten ohne einen Shared Storage aus,
andererseits ist von Fall zu Fall zwischen Dateien zu unterscheiden,
die im Fall von Konfigurationsänderungen manuell bzw. über selbst entwickelte Mechanismen synchron gehalten werden müssen.
Die Verbreitung von Virtualisierung liefert hier neue Ansätze:
Statt Heartbeat auf Basis einzelner Dienste laufen zu lassen,
wird das System, das hochverfügbar ausgelegt werden soll,
als virtueller Server realisiert, beispielsweise mittels Xen.
Die Virtualisierung ist hierbei nur Mittel zum Zweck:
Es geht nicht darum, eine Hardware auf mehrere Systeme aufzuteilen,
sondern vielmehr darum, ein System in eine Art Container
zu packen,
der sich – aus Sicht des Administrators – sehr viel einfacher replizieren lässt.
Dabei sind einerseits Aktiv/Passiv-Cluster möglich, bei denen
eine einzelne virtuelle Instanz sämtliche Systemressourcen erhält und
die zweite Hardware nur als Reserve für den Fall des Ausfalls mitläuft.
Eine bessere Ausnutzung von Ressourcen im Normalbetrieb erzielen Sie aber mit einem Aktiv/Aktiv-Cluster, bei denen zwei oder mehr virtuelle Instanzen konfiguriert werden, bei denen ein Teil auf der einen und ein Teil auf der anderen Hardware läuft – ein Prinzip, das durchaus leichte Ähnlichkeit mit unserem VServer-Cluster hat.
Hier läuft beispielsweise die virtuelle Instanz A auf der einen Hardware, die virtuelle Instanz B auf der anderen. Dabei werden aber beide Instanzen live gespiegelt, sprich: Alle Schreibzugriffe auf A werden gleichzeitig auch auf dem anderen Server durchgeführt und umgekehrt:
Im Fall eines Ausfalls einer der beiden Server wird die komplette Instanz mit auf der anderen Hardware gebootet – mit einer Downtime lediglich im Umfang eines Bootvorgangs:
Hierbei ist natürlich darauf zu achten (was aber allgemein für jeden
Aktiv/Aktiv-Cluster gilt), dass die Ressourcen einer Hardware auch wirklich
dafür ausreichen, um zumindest zeitweise beide virtuellen Instanzen auf einer Hardware
laufen zu lassen. Sobald das ausgefallene Gerät ggf. repariert und neu gestartet wurde,
kann die Instanz B wieder auf ihr eigentliches
Heimatsystem zurückziehen.
Auf diese Weise sind nebenbei auch Hardware-Upgrades mit minimaler Downtime möglich: Die Instanzen einer Hardware werden via Failover umgezogen, die Hardware wird ausgewechselt, alle Instanzen werden auf die neue Hardware umgezogen, die andere Hardware wird ausgewechselt, und zum Schluss werden alle Instanzen wieder auf die beiden Systeme verteilt.
Derartige Failover-Cluster konzipieren, installieren und betreiben wir gerne entsprechend Ihrer Anforderungen und freuen uns, wenn Sie diesbezüglich Kontakt mit uns aufnehmen. Preislich bewegen sich Hochverfügbarkeitscluster wenig überraschend im Bereich von zwei dedizierten Servern – verschaffen Sie sich mit unserem Angebotskalkulator also gerne schon einmal einen Eindruck.