Tags: Hyper-V, Hochverfügbarkeit, Cluster
Hochverfügbarkeit ist in virtualisierten Umgebungen meist wichtiger als bei physikalischen Installationen. Auf einem Hypervisor laufen nämlich 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 unterbrechungsfrei 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 Betriebssystempartition. 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
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.
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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Marcel Küppers arbeitet seit über 25 Jahren in der IT, aktuell als Team Leader, zuvor als Consultant und Infrastructure Architect unter anderem für den japanischen Konzern JTEKT/TOYODA mit Verantwortung über die Europastandorte Krefeld und Paris. Darüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Lokationen des Konzerns mit und ist spezialisiert auf hochverfügbare virtualisierte Microsoft-Umgebungen plus Hybrid Cloud Solutions. Zertifizierungen: MS Specialist und MCTS für Hyper-V/SCVMM, MCSE, MCITP, MCSA. Zusätzlich zertifiziert für PRINCE2 Projektmanagementmethode.
// Kontakt: E-Mail, Twitter, LinkedIn //
Verwandte Beiträge
- VM Compute Resiliency: Toleranz bei temporären Ausfällen im Hyper-V-Cluster
- Windows Server 2016 Hyper-V Cluster: VMs in bestimmter Reihenfolge starten
- Scale-out File-Server für Hyper-V: Cluster und Storage Spaces einrichten
- Scale-out File-Server für Hyper-V: Features und Voraussetzungen
- Anleitung: Hyper-V-Cluster einrichten und VMs hochverfügbar machen
Weitere Links