Hyper-V Failover-Cluster: Einsatzgebiete, aktiv/aktiv versus aktiv/passiv

    Automatischer Failover bei Ausfall eines HostHochverfügbarkeit ist in virtualisierten Umge­bun­gen meist wichtiger als bei physika­lischen Installa­tionen. Auf einem Hypervisor laufen näm­lich mehrere virtuelle Server und bei Ausfall eines Hosts zieht er sie mit in den Abgrund. Daher kann man Hyper-V-Server zu einem Failover-Cluster verbinden, um wichtige Applikationen unter­brechungs­frei zu betreiben.

    Angenommen, wir haben uns noch keine Gedanken zu Disaster Recovery oder Failover Clustering gemacht, wie könnte dann eine beispielhafte Ausgangslage aussehen? Diese bestünde dann etwa aus einem Hyper-V-Host, auf dem 4 VMs mit Server-Applikationen laufen. Darunter würde sich ein sekundärer virtueller DC (ein physikalischer existiert auch), ein dedizierter Fileserver für das Management, ein SQL Server mit Datenbanken für die ERP-Software und ein Printserver befinden.

    Beispiel-Szenario ohne Failover-Cluster

    Ein zweiter Hyper-V-Server arbeitet in dieser Beispielumgebung mit im Rack und hostet 4 weitere virtuelle Server. Sein Arbeitsspeicher ist ausgelastet und er kann keine weiteren virtuellen Maschinen mehr starten. Die VHDX-Dateien liegen auf einem lokalen Festplattenarray getrennt von der Betriebssystem­partition. Komplette VM-Backups werden regelmäßig um 23:00 Uhr auf einem NAS über 1Gbit-Ethernet gesichert.

    Wenn unter diesen Bedingungen um 09:00 morgens der erste Hyper-V-Host aufgrund eines Defekts am RAID-Controller ausfällt, dann könnte sich Folgendes abspielen:

    • 09:10 Erste Mitarbeiter melden, dass sie keine Angebote erstellen können
    • 09:20 Beim Administrator klingelt das Telefon: keine Drucke möglich, Lieferscheine können nicht erstellt werden
    • 09:30 Das Problem wurde erkannt und es wird eine Lösung gesucht
    • 10:05 Die Lösung ist gefunden: der RAID Controller muss getauscht werden
    • 10:10 Support-Call beim Hardwarehersteller und eskalieren des Falls
    • 10:20 Austausch des RAID Controllers ist veranlasst: SLA des Herstellers 4 Stunden
    • 10:30 Workarounds für Mitarbeiter erstellen, damit Sie produktiv bleiben, wenn überhaupt möglich
    • 13:00 Der Techniker des Herstellers kommt frühzeitig, der Controller gleicher Bauart wurde per Express Kurier zuvor abgeliefert.
    • 13:45 Einbau ist fertiggestellt, hoffen auf Zugriff zum Array
    • 14:00 Zugriff auf das Daten-Array scheitert, kein Zugriff auf die VHDX Dateien möglich
    • 14:30 Nach einigen Versuchen entschließt man sich zum Neuerstellen des RAID
    • 15:00 Beginn mit der Rücksicherung der VMs vom Abend des Vortages
    • 18:00 Die Rücksicherung der VHDX Laufwerke ist abgeschlossen
    • 18:30 Der Hyper-V Host hat wieder Zugriff auf das Array und die VMs starten
    • 19:00 Nacharbeiten werden abgeschlossen

    10 Stunden Ausfall des Warenwirtschaftsystems und 1 Stunde Datenverlust.

    Anhand des Beispiels bleibt nun zu entscheiden, ob ein Ausfall des Warenwirtschaftssystems für einen Tag kritisch für das Unternehmen oder immer noch tolerierbar ist. Eine höhere Verfügbarkeit auf Basis der Datenbankspiegelung von SQL Server könnte in Betracht gezogen werden, und wie bei vielen Dingen spielt das Budget eine große Rolle.

    Alternative Konfiguration mit Failover Cluster

    Mindestens zwei Server (Knoten) zusammen mit einem zentralen Speichersystem, welches über iSCSI, Fibre Channel, SMB 3.0 oder SAS angesprochen wird, können ein HA-Cluster (High Availability Cluster) bilden. Seit Windows Server 2012 werden bis zu 64 Knoten unterstützt und Failover-Cluster bleibt nicht mehr der Datacenter Edition vorbehalten, sondern ist auch eine Funktion der Standard-Version. Die virtuellen Maschinen werden auf dem zentralen Storage abgelegt.

    Der Failover-Cluster wird wahlweise als aktiv/aktiv oder aktiv/passiv betrieben. Fällt ein Knoten des Clusters aus, dann werden mit einer kurzen Unterbrechung die virtuellen Maschinen des ersten ausgefallenen Knotens auf dem Zweiten gestartet und sind sofort wieder einsatzbereit.

    Aktiv/Aktiv oder Aktiv/Passiv

    Ein aktiv/aktiv HA-Cluster (High Availability Cluster) besteht aus mindestens zwei Knoten, wobei jeder Knoten Dienste im Netzwerk zur Verfügung stellt. Im Fall von Hyper-V-Hosts würden z.B. auf einem Cluster-Knoten die VM mit dem Warenwirtschaftssystem, der Dateiablage sowie den Infrastrukturdiensten laufen und auf dem anderen der Mail-Server, das Virenschutzmanagement und redundante Infrastrukturdienste.

    Beispiel-Cluster mit 2 Knoten, links aktiv/aktiv und rechts aktiv/passiv.

    Bei Ausfall des ersten Knoten übernimmt der zweite die Last des ausgefallenen Servers und muss genug Reserven vorhalten, um alle Dienste ausführen zu können. Als Best Practice empfiehlt es sich daher, etwas Puffer bei der Auslastung einzuplanen und diese auf etwa 40 % pro Host zu begrenzen. Weitere Berechnungen werden bei mehr als zwei Knoten nötig.

    Bei Aktiv/Passiv-Clustern laufen alle Applikationen und Dienste auf einem aktiven Knoten und werden bei ungeplantem Failover komplett an den freien passiven Knoten übergeben. Die Passiv-Hardware läuft sozusagen im Standby Betrieb parallel mit. Eine weitere Variante ist die n+1 Konfiguration, d.h. alle Knoten (n) führen aktiv Dienste aus und ein Knoten (+1) bleibt mit 0 % Last passiv um im Fall eines Knotenausfalls die Dienste übernehmen zu können.

    Glossar

    Zum Schluss sollen noch einige wichtige Begriffe in Zusammenhang mit Failover-Cluster kurz erklärt werden:

    • Failover/Failback: Bei einem Failover übernimmt ein anderer Knoten automatisch die Dienste des ausgefallenen Servers (Knoten). Ein Failback würde die Dienste wieder auf den ursprünglichen Knoten verschieben.
    • Split Brain: Bei einer gestörten Kommunikation der Knoten untereinander und einer daraus resultierten isolierten Cluster-Umgebung spricht man von einer Split Brain Problematik. Die Knoten sind für sich intakt, doch das Cluster als Verbund ist nicht konsistent.
    • Quorum: Das "Quorum" besteht aus ggf. dynamischen stimmberechtigten Knoten plus Zeugendatenträger, Freigabe- oder Cloud-Zeugen. Es dient der Erhaltung von Cluster-Integrität und auch der Vermeidung einer Split Brain Problematik.
    • Heartbeat: Als "Heartbeat" bezeichnet man die Diagnose-Netzwerkverbindung zwischen den Cluster-Knoten zur Bestimmung des allgemeinen Zustandes der Knoten.
    • Cluster Shared Volume (CSV): Mit Windows Server 2008 R2 wurde CSV als Cluster-Dateisystem für Hyper-V eingeführt. Es erlaubt den gleichzeitigen Zugriff der Knoten auf einen gemeinsamen Speicher.

    Keine Kommentare