Als ich zum ersten Mal einen 2-Knoten-Hyper-V 2012-Cluster einrichtete, erfolgte das Failover praktisch sofort. Ich hatte eine Sql Server 2012-VM (unter Win2012) mit 8 GB zugewiesenem RAM. Ich konnte den Knoten, auf dem er sich befand, neu starten, und er sprang zum anderen Knoten, ohne meine Sql-Verbindung zu verlieren.
Dann habe ich dem Cluster eine zweite VM hinzugefügt (Klon der ersten VM), ebenfalls mit 8 GB. Jetzt dauert das Failover ein paar Sekunden und meine SQL-Verbindung wird zurückgesetzt. Liegt es an der Menge an RAM, die verschoben werden muss? Wird es vom Netzwerk beeinflusst? Liegt es an der Geschwindigkeit der Quorum-Disk?
In meinem Fall sind beide Knoten an dasselbe DAS angeschlossen und die VM-Dateien befinden sich auf CSVs. Ich würde erwarten, dass die Festplatten kein Faktor sind, da nichts verschoben werden muss. Es sollte alles RAM sein, oder? Wenn also der RAM zunimmt, nimmt die Failover-Leistung ab?
Antwort1
Im Nachhinein betrachtet hätte ich es wohl wissen müssen. Die Antwort besteht aus zwei Teilen, denn meiner Meinung nach gibt es geplantes Failover und „echtes“/ungeplantes Failover – und geplantes Failover zählt nicht.
Geplantes Failover
Bei einem geplanten Failover entleert das Clustering-System den Knoten und startet ihn dann für Sie neu. Wenn Sie den Knoten also direkt über RDP oder „Stop Cluster Service“ in der GUI der Clustering-App neu starten, wird als Erstes die Live-Migration der VMs beendet. Da Sie die VMs wirklich nur live migrieren, hängt die dafür benötigte Zeit davon ab, was übertragen werden muss und von der Netzwerkverbindung. Wenn Sie eine 1-GB-Netzwerkkarte haben, wird es eine Weile dauern (~118 MB/s). Je mehr RAM Ihre VMs haben, destoBesser bedient sind Sie mit schnelleren Netzwerkkarten.
Echtes Failover
Ein ungeplantes/„echtes“ Failover findet statt, wenn Sie die Maschine vom Strom trennen. In diesem Fall startet das Clustersystem die VM automatisch auf einem anderen Knoten. Das Verhalten gegenüber der Außenwelt ist dasselbe, als ob Sie die VM neu gestartet hätten. Für die VM ist es dasselbe, als ob Sie sie „ausgeschaltet“ und dann erneut gestartet hätten. Bei einem „echten“ Failover geht es also immer darum, wie lange das Booten Ihrer VMs dauert.
Tangente
Das ist für mich konzeptionell eine Enttäuschung, weil ich das Gefühl habe, dass alle Clustering-Diskussionen im Internet darauf schließen lassen, dass ein („harter“) Knotenausfall durch das Clustering-System verborgen wird – es soll so sein, als ob die Dienste nie ausgefallen wären. Das liegt wahrscheinlich daran, dass alle Webseiten, die ich gelesen habe, ihr Cluster-Failover per Software getestet haben (geplantes Failover). Sie beweisen also lediglich, dass Live Migration wie angekündigt funktioniert (keine Ausfallzeit aus Sicht des Clients).
Mein Hauptfehler war, dass ich Failover selbst falsch verstanden habe. Neben dem Konzept eines Hot/Warm/Cold-Backup-Servers, bei dem ein automatisches Failover auf einem Hot-Server erfolgt, gibt es auch Hot/Warm/Cold-Failover. Wie bereits erwähntHier, Hot Failover erfolgt sofort, Warm Failover wird in Sekunden gemessen und Cold Failover in Minuten. Es war naiv von mir anzunehmen, dass alle automatischen Fehler „heiß“ sind. Ich schätze, ich habe eine Art Zauberei mit dem RAM erwartet, bei der der Cluster eine Kopie des RAM der VM auf einem anderen Knoten aktualisiert – so etwas wie das Senden von Transaktionsprotokollen mit SQL Server. Aber das würde einen Kommunikationskanal zwischen den Maschinen erfordern, der mindestens so schnell ist wie der RAM, um zu garantieren, dass es funktioniert.