Hochverfügbarkeit in virtualisierten Umgebungen: Probleme und Technologien

Anbieter zum Thema

Vertiv GmbH

Heidelberg iT Management GmbH & Co. KG

XOPERO SOFTWARE S.A.

Fehlertoleranz

Daneben gibt es von den großen Herstellern von Virtualisierungssoftware auch Lösungen, die Fehlertoleranz bieten. Bei diesen Lösungen werden keine Komponenten überwacht, sondern virtuelle Maschinen von vornherein als Replikate voneinander aufgebaut, die auf unterschied-licher Hardware laufen. Fällt dann ein Host aus, lässt sich unterbrechungsfrei mit dem Replikat der virtuellen Maschine weiterarbeiten. Das Fault-Tolerance-Feature von VMware oder die Lösung everRun von Citrix sind Beispiele für solche fehlertoleranten Clusterungen. Allerdings reagiert eine solche Lösung nicht auf den Ausfall von Komponenten innerhalb eines Betriebssystems einer virtuellen Maschine – wenn ein Serverprozess abstürzt, dann stürzt er fehlertolerant ab. Also ist auch diese fehlertolerante Lösung für eine geschäftskritische Applikation nicht ausreichend.

Bei den Lösungen zur Failover-Clusterung sind zwei Ebenen der Granularität zu unterscheiden:

• 1. Die Überwachung der Clustersoftware kann zunächst auf der Ebene der virtuellen Maschine erfolgen. Dieses Prinzip wird z.B. von VMware HA und bei der Clusterung von virtuellen Maschinen des Hyper-V als Applikationen im Kontext vom Microsoft Server Failover Cluster von Windows 2008 angewandt. Die eingesetzte Clustersoftware muss mit der virtuellen Infrastruktur des jeweiligen Anbieters zusammenarbeiten, unabhängige Anbieter solcher Clustersoftware gibt es dementsprechend kaum (so hatte z.B. Symantec den Veritas Cluster Server auch in einer Version herausgebracht, die in der Service Console des ESX-Hosts von VMware lief; allerdings gibt es dieses Produkt nicht mehr für die aktuelle Version der vSphere, und ihm wird auch mit der angekündigten Aufkündigung des ESX mit Service Console die Basis entzogen). Bei diesem Ansatz wird die Verfügbarkeit von Services nicht explizit überprüft, sondern es wird – mehr oder weniger implizit – davon ausgegangen, dass die entsprechenden Services laufen, wenn die virtuelle Maschine läuft.
• 2. Die Überwachung kann genauso wie in der physischen Infrastruktur auf der Ebene des Betriebssystems der virtuellen Maschinen erfolgen. Es wird bei diesem Ansatz in die virtuelle Maschine eine Clustersoftware – z.B. der Veritas Cluster Server von Symantec, der Microsoft Server Failover Cluster oder die Clustersoftware eines beliebigen anderen Herstellers; in der Regel kündigen die Hersteller der Clustersoftware ihren Support nicht explizit auf, wenn die Software in virtuellen Maschinen betrieben wird, aber in der Regel ist der Support daran ge-knüpft, dass sich ein eventueller Fehler der Clustersoftware in einer nicht-virtualisierten Umge-bung reproduzieren lässt – installiert, die völlig ungeachtet der Tatsache, dass sie in einer vir-tuellen Maschine läuft, die konfigurierten Applikationen überwacht.

Dabei lassen sich wiederum drei verschiedene Herangehensweisen unterscheiden:

• 1. Cluster in a box: Bei dieser Form von Clusterung wird in zwei virtuelle Maschinen, die auf dem gleichen Host laufen, eine Clustersoftware installiert, und Dienste werden zwischen diesen beiden virtuellen Maschinen geclustert. Da diese Form von Clusterung keine Hochverfügbarkeit beim Ausfall von Hardware bietet, wird sie in der Regel nur zum Testen eingesetzt.
• 2. Cluster accross boxes: Wenn die beiden virtuellen Maschinen, zwischen denen durch OS-seitig installierte Software ein Cluster aufgebaut ist, auf zwei verschiedenen physischen Hosts laufen, spricht man von dieser Form der Clusterung. Diese ist voll produkionsfähig und bietet echte Hochverfügbarkeit. Als Shared Storage können IP basierende Storagetechniken zum Einsatz kommen, oder aber es werden auf Ebene der Hosts virtuelle Disks in einem Shared Storage der Hosts eingerichtet, die beiden virtuellen Maschinen zugeordnet werden.
• 3. Physical to virtual clustering: Bei dieser ebenfalls voll produktionsfähigen Version der Clusterung wird ein Cluster zwischen einem physischen und einem virtuellen System aufgebaut. Dabei fungiert die virtuelle Maschine in der Regel als Standby-System, das – sollte das physische System ausfallen – Services starten kann, allerdings in der Regel eine schlechtere Performance bietet als das physische System. Als Shared Storage bieten sich auch hier wieder auf IP basierende Storage-Techniken an, aber auch der Einsatz von LUNs ist unter Verwendung von Pass-Through-Mechansimen (z.B. VMwares Raw-Device-Mapping im Modus physischer Kompatibilität oder das Pass-Through-Device vom Hyper-V) in der virtuellen Infrastruktur möglich, die den Zugriff aus einer virtuellen Maschine heraus direkt auf ein LUN erlauben.

In der Praxis spielen vor allem zwei Clusterungsmechanismen eine Rolle, nämlich einerseits – für Dienste, die nicht business-critical sind – die Failover-Clusterung auf der Ebene der virtuellen Infrastruktur, für alle Dienste, die business-critical sind, eine Clusterung accross boxes. Neben den beschriebenen Clusterungsmechanismen bietet die virtuelle Infrastruktur durch die Möglichkeit der Live-Migration (z.B. vMotion bei VMware, Live-Migration beim Hyper-V) einer virtuellen Maschine noch einmal ein Plus an Verfügbarkeit – nämlich durch die Möglichkeit, virtuelle Maschinen von Hosts im laufenden Betrieb der virtuellen Maschinen wegzubringen, wenn die Hosts für Wartungszwecke abgeschaltet werden müssen. Auf diese Art und Weise kann die geplante Downtime von virtuellen Maschinen minimiert werden.

Fazit

Abschließend lässt sich sagen, dass das Problem der Hochverfügbarkeit von Diensten in einer virtualisierten Umgebung aufgrund des in der Regel hohen Konsolidierungsgrades der virtualisierten Infrastruktur verschärft gegenüber eine physischen Infrastruktur hervortritt. Die aus der physischen Infrastruktur bekannten Mechanismen der Failover-Clusterung können cum grano salis alle auch in virtualisierten Umgebungen eingesetzt werden. Zudem erleichtert die virtualisierte Umgebung den Aufbau von fehlertoleranten, synchronen Replikationslösungen. Schließlich kann durch die Möglichkeit der Live-Migration geplante Downtime deutlich minimiert werden. Es gibt also auch spezifische Antworten aus der virtualisierten Infrastruktur auf das Problem der Hochverfügbarkeit in der virtualisierten Infrastruktur.

*Dr. Christian Rabanus ist Senior Instructor & Consultant bei Fastlane

(ID:2047260)