Hochverfügbarkeits-Clustering
Virtualisierung mit Variationen
Die Konsolidierung mehrerer physischer Server mithilfe virtueller Maschinen stellt neue Anforderungen an das Thema Hochverfügbarkeit: Fällt der physische Server aus, sind auch alle darauf laufenden virtuellen Maschinen betroffen. Der Beitrag beschäftigt sich mit den unterschiedlichen Möglichkeiten der Kombination von Virtualisierung und Clustering und analysiert diese im Hinblick auf Hochverfügbarkeit.
Den Großteil der heute eingesetzten HA-Cluster (High Availability) bilden so genannte
Zwei-Knoten-Cluster: Damit beide Cluster-Knoten über den identischen Datenstand verfügen, liegen
diese Daten entweder auf einem gemeinsam genutzten Speichersystem oder sie werden permanent
zwischen den Cluster-Knoten repliziert.
Bisher beruhten HA-Cluster ausschließlich auf physischen Servern. Aufgrund der ständig
wachsenden Verbreitung von Virtualisierungstechniken steigt der Bedarf an
Hochverfügbarkeitslösungen auch in diesen Bereichen. Der Beitrag erläutert im Folgenden die
grundsätzlichen HA-Clustering-Möglichkeiten in virtuellen Umgebungen. Er geht dabei jeweils von
einem Aktiv-/passiv-Betrieb des Clusters aus. Welche der vorgestellten Varianten tatsächlich zur
Verwendung kommen können, hängt dabei von der jeweils eingesetzten Virtualisierungstechnik
beziehungsweise den entsprechenden Produkten ab.
Variante 1
Virtuelle Maschine - virtuelle Maschine, auf einem physischen Server: In diesem Szenario wird
ein HA-Cluster zwischen zwei oder mehreren virtuellen Maschinen auf einem einzelnen physischen
Server aufgebaut (Bild 1). Der Cluster-Manager läuft dabei jeweils in den virtuellen Maschinen. Der
physische Server dient lediglich als Basis für die virtuellen Maschinen.
Der Sinn dieses Aufbaus ist fragwürdig, da solche Cluster keinerlei Schutz gegen den Ausfall der
Serverhardware selbst bieten. Der physische Server ist somit ein SPOF (Single Point of Failure).
Damit verletzt dieses Konzept eines der wichtigsten Prinzipien im Hochverfügbarkeitsbereich, die
Eliminierung aller möglichen SPOFs. Zusätzlich gehen durch den Einsatz eines einzelnen physischen
Servers noch weitere Vorteile verloren, die ein HA-Cluster normalerweise bietet: beispielsweise die
fehlende Möglichkeit, an einem der Cluster-Knoten Wartungsarbeiten im laufenden Betrieb
durchzuführen. Aus diesen Gründen dürfte sich dieser Aufbau in der Praxis wohl hauptsächlich als
Testplattform für Hochverfügbarkeitslösungen, nicht jedoch für den produktiven Einsatz
anbieten.
Variante 2
Virtuelle Maschine - virtuelle Maschine, auf mehreren physischen Servern: Dieses Modell basiert auf einem HA-Cluster zwischen zwei oder mehreren virtuellen Maschinen, die jeweils auf unterschiedlichen physischen Servern laufen (Bild 2). Der SPOF eines einzelnen physischen Servers ist dadurch eliminiert. Wie bei der vorhergehenden Lösung läuft der Cluster-Manager direkt in der virtuellen Maschine.
Vorteile gegenüber klassischem Clustering ergeben sich vor allem im Bereich Backup und Recovery - Aufgaben die der Einsatz virtueller Maschinen generell vereinfacht. Die Administration sollte jedoch nicht das Betriebssystem des physischen Servers vergessen, das als Basis für die virtuelle Maschine dient. Auch bei diesem ist auf die laufende Sicherstellung der Systemsicherheit sowie die Einbeziehung in die Prozesse für Backup und Recovery zu achten.
Diese Lösung bietet noch einen weiteren sehr interessanten Vorteil: Sie ermöglicht die Ausführung mehrerer Instanzen von Applikationen, die einen solchen Betrieb im Rahmen einer Betriebssysteminstanz normalerweise nicht unterstützen. Dies lässt sich durch den Einsatz mehrerer virtueller Maschinen auf einem einzelnen physischen Server erreichen.
Variante 3
Physischer Server - virtuelle Maschine: Bei diesem Modell wird ein HA-Cluster zwischen einem
physischen Server (aktiver Knoten) und einer virtuellen Maschine (passiver Knoten) aufgebaut (Bild
3). Der Cluster-Manager läuft auf dem physischen Server direkt im Betriebssystem und auf der
Gegenseite in einer virtuellen Maschine.
Diese Variante bietet den Vorteil, dass die Administration mehrere Standby-Knoten
unterschiedlicher Cluster auf einer physischen Maschine zusammenfassen kann. Dadurch ergibt sich
ein erhebliches Einsparungspotenzial bei der normalerweise doppelten Hardware für den
Standby-Server eines Clusters. Abhängig von der Virtualisierungsmethode ist auch der Einsatz
unterschiedlichster Betriebssysteme in den virtuellen Maschinen auf dem Server möglich. Somit
könnte beispielsweise ein Standby-Server mit virtuellen Maschinen sowohl Teil eines Linux- als auch
eines Windows-Clusters sein.
Ein Nachteil dieses Aufbaus ist, dass im Fall eines Fail-/Switchovers mehrerer Cluster auf den
Standby-Server die Performance dieses Rechners eventuell nicht ausreicht. Dieses Risiko muss der
Anwender entweder bewusst in Kauf nehmen oder den Standby-Server entsprechend dimensionieren.
Ebenso nachteilig ist, dass die Prozesse für System-Updates und Backup/Recovery für die einzelnen
Cluster-Knoten jeweils sehr unterschiedlich sein können.
Variante 4
Virtuelle Maschine - physischer Server: Dieser Aufbau stellt das Gegenstück zum vorhergehenden
dar. Dabei wird der Cluster zwischen einer virtuellen Maschine (aktiver Knoten) und einem
physischen Server (passiver Knoten) aufgebaut (Bild 4). Der Cluster-Manager läuft auf der einen
Seite wieder in der virtuellen Maschine und auf der anderen Seite direkt im Betriebssystem des
physischen Servers.
Ein Beweggrund für den Aufbau einer solchen Lösung könnte sein, dass mehrere virtuelle Maschinen
auf einer sehr leistungsfähigen und redundanten Hardware laufen sollen. Als Standby-Server ließen
sich dann günstigere Maschinen mit weniger Hardwareredundanz einsetzen. Ob diese Kalkulation in
einem HA-Cluster allerdings sinnvoll ist, sollte ernsthaft hinterfragt werden.
Variante 5
Physischer Server - physischer Server, mit Fail-/Switchover der virtuellen Maschine: Beim
Einsatz dieses Szenarios wird ein Cluster ganz traditionell zwischen zwei oder mehreren physischen
Servern aufgebaut (Bild 5). Der Cluster-Manager läuft dabei direkt im Betriebssystem des physischen
Servers. Die Virtualisierungssoftware selbst ist als Ressource im Cluster konfiguriert. Die
eigentlichen Applikationen laufen nicht wie üblich direkt im Betriebssystem des physischen Servers,
sondern in einer oder mehreren virtuellen Maschinen. Bei einem Failover startet der Cluster-Manager
die Virtualisierungssoftware mit allen virtuellen Maschinen auf dem Standby-Knoten.
Dieser Aufbau bietet mehrere Vorteile. Einer davon ist die vereinfachte Cluster-Konfiguration.
Da der Cluster-Manager lediglich die Virtualisierungssoftware steuern muss, gestaltet sich die
Konfiguration sehr einfach und kompakt. Aufwändige und fehleranfällige Integrationen von
Applikationen in den Cluster bleiben somit erspart. Gerade das "Sharing" beziehungsweise die
Synchronisation der Anwendungskonfigurationen auf mehreren Cluster-Knoten entfällt dadurch
komplett.
Der Hauptvorteil dieser Variante liegt also in der Unabhängigkeit von Applikationen und
Cluster-Manager. Die Anwendungen lassen sich in der gleichen Art betreiben, wie dies auch in einer
einzelnen virtuellen Maschine oder auf einem einzelnen physischen Server der Fall wäre. Sie laufen
in virtuellen Maschinen, für die keinerlei Cluster-spezifische Anpassungen notwendig sind.
Ein weiterer Vorteil ist, dass sich mehrere virtuelle Maschinen ohne zusätzlichen Aufwand
hochverfügbar machen lassen. Diese Aufgabe ist mit einem einzigen Cluster erledigt. Somit ist es
nicht nötig, verschiedene einzelne Cluster zu betreiben, sondern es lassen sich mehrere virtuelle
Maschinen auf einem Cluster-System konsolidieren.
Nachteilig ist vor allem die Tatsache, dass der Fail-/Switchover-Vorgang länger als in einem
traditionellem Cluster dauern kann. Es reicht bei diesem Aufbau nicht aus, nur die Applikation
selbst zu starten. Vielmehr ist die komplette virtuelle Maschine neu zu starten, was entsprechend
länger dauern kann. Abhilfe hierfür kann zum Beispiel der Einsatz einer
Betriebssystemvirtualisierung schaffen. Dadurch lässt sich die Startdauer der virtuellen Maschine
stark reduzieren, und der Overhead im Vergleich zum Start der einzelnen Applikationen ist praktisch
vernachlässigbar.
Mögliche Einschränkungen
Die heute verbreiteten HA-Cluster-Produkte haben unterschiedliche Anforderungen an Server,
Netzwerk und Speichersysteme. Nicht alle Anforderungen lassen sich durch virtuelle Umgebungen
erfüllen. So ist beispielsweise beim Thema "Fencing" Vorsicht geboten. Diese Technik verhindert,
dass mehrere Cluster-Knoten gleichzeitig auf kritische Ressourcen (zum Beispiel nicht
Cluster-fähige Filesysteme) zugreifen.
Das Ziel lässt sich zum einen durch Node-Fencing erreichen. Dabei wird ein kompletter
Cluster-Knoten mithilfe von STONITH ("shoot the other node in the head") aus dem Verbund
ausgeschlossen. Dieses Verfahren eignet sich somit nicht für den Fall, dass mehrere virtuelle
Maschinen auf einer einzelnen physischen Hardware für unterschiedliche Cluster zum Einsatz kommen.
Dabei würden im Fall eines STONITH mehrere "virtuelle? Cluster-Knoten auf einmal vom Cluster
ausgeschlossen.
Die zweite Möglichkeit ist Ressource-Fencing. Letzteres garantiert einen exklusiven Zugriff auf
die kritische Ressource. In der Praxis ist diese Methode oft durch SCSI-2/SCSI-3-Reservierungen
implementiert. In Kombination mit der Virtualisierung muss die Administration darauf achten, dass
diese Reservierungen auch tatsächlich im virtuellen Umfeld funktionieren. Hier kann vor allem beim
Aufbau eines Clusters mit einem Cluster-Manager, der auf der einen Seite in einer virtuellen
Maschine und auf der Gegenseite direkt auf einem physischen Server läuft, zu Problemen kommen.
Zukunft
Die Kombination von Hochverfügbarkeit und Virtualisierung steht derzeit erst am Beginn der
Entwicklung. Bislang existieren in diesem Bereich kaum fertige Lösungen am Markt.
Eine spannende Entwicklung ist in diesem Umfeld auch die Möglichkeit der Echtzeitmigration, die
immer mehr Virtualisierungslösungen anbieten. Dabei wird eine virtuelle Maschine zu einem
bestimmten Zeitpunkt "eingefroren" und dann unter Erhalt des kompletten Speicherabbilds, aller
Prozesse und Netzwerkverbindungen auf einem anderen physischen Server wieder aktiviert. Im
Idealfall sollte dabei für den Client keinerlei Unterbrechung bemerkbar sein. Diese Funktion der
Echtzeitmigration von virtuellen Maschinen ist gerade für einen manuellen Switchover in einem
HA-Cluster interessant. Darüber hinaus wäre es überlegenswert, ob Echtzeitmigrationen auch im Fall
eines automatischen Failovers sinnvoll sein können.
Fazit
Als Resümee lässt sich sagen, dass Virtualisierung sehr viele neue Möglichkeiten zum Aufbau von
HA-Clustern bietet. Vielfach scheinen diese Möglichkeiten sehr verlockend, jedoch sollte der
Anwender diese auch kritisch hinterfragen. Gerade beim Einsatz von HA-Clustern muss die
bestmögliche Verfügbarkeit von Applikationen im Vordergrund stehen. Ein HA-Cluster sollte - als
eines der wichtigsten HA-Prinzipien überhaupt - möglichst einfach gehalten sein. Durch den Einsatz
einer Virtualisierung wächst das Risiko, dass man sich von dem Prinzip der Einfachheit sehr weit
entfernt. Gerade beim Aufbau eines Clusters von einer virtuellen Maschine zu einem physischen
Server ist dies problematisch. Der Anwender sollte auch bedenken, dass die Virtualisierung selbst
eine weitere Systemebene einzieht, die zusätzliches Potenzial für Fehler und Probleme bietet.
Lesen Sie mehr zum Thema
