Hyper-V im Failover-Cluster, Cluster Shared Volumes, das Backup und der Redirected Mode
In diesem Beitrag möchte ich näher auf das Thema Hyper-V im Failover-Clusterbetrieb und der Sicherung von hochverfügbaren VMs eingehen. In meinem Fall handelt es sich um vier Server, die als Cluster-Knoten zur Verfügung stehen. Auf diesen vier Knoten werden aktuell 21 VMs betrieben, alle liegen in einem “Freigegebenen Clustervolume” (CSV). Die Knoten sind jeweils mit sechs Netzwerkkarten bzw. Ports an unser Netzwerk angebunden, so wie in der folgenden Anleitung beschrieben: Netzwerkkonfiguration im Hyper-V Cluster. Als es nach der Einrichtung des Clusters an das Thema Backup der VMs ging, waren wir uns recht schnell einig, dass der System Center Data Protection Manager das Produkt unserer Wahl wird. Zum einen ist das Programm in der Lage Windows-VMs im laufenden Betrieb in einem Cluster zu sichern (das Windows Backup z.B. kann dies nicht), zum anderen schreibt der DPM nur die Änderungen seit der letzten Sicherung weg, so wird weniger Speicherplatz auf dem Backupserver benötigt, zum anderen können wir so unsere Backups länger aufbewahren.
Der Aufbau
Der Aufbau der Umgebung sieht grafisch wie folgt aus
In das Management-Netz wird nun ein weiterer Server mit dem DPM gestellt. Auf jeden der vier Hosts wird der DPM-Agent installiert, wenn man danach einen der Server in der DPM-Konsole hinzufügt werden automatisch alle weiteren Cluster-Knoten hinzugefügt (wenn man dies möchte). Nach dem Hinzufügen tauchen die vier Hosts nicht mehr einzeln, sondern als Cluster auf. Der DPM erkennt, dass es sich um ein Failover-Cluster handelt und behandelt dieses auch so.
Ohne die Installation weiterer Software sind wir nun in der Lage, Backups der VMs zu erstellen. Diese Backups werden allerdings vom DPM mit einer oder mehreren Fehlermeldungen begleitet
Warum ist dies so? Die von mir erstellte Schutzgruppe ist so konfiguriert, das täglich um 07.00 Uhr ein Backup der Gruppen-Mitglieder erstellt wird. Bei einem Backup-Vorgang müssen in meinem Fall 21 VMs gesichert werden.
Software vs. Hardware VSS Provider
Die Möglichkeit einer Live-Sicherung der VMs wird uns ermöglicht durch einen VSS-Snapshot (Volume Shadow Copy Service) der VM im Betrieb. Es gibt zwei Arten von Snapshot Providern:
Software VSS Provider
Dieser Provider ist im Windows enthalten. Bei Beginn eines Backups wird die Anbindung an das Storage-System umgeleitet, wir befinden uns im “Redirected Mode”. Dieser Modus wird genutzt, wenn ein Knoten keinen direkten Zugriff auf das CSV erhält. In diesem Fall wird der Zugriff auf das CSV ermöglicht, indem über einen anderen Knoten auf das CSV zugegriffen wird. Dies beugt einem Ausfall vor, allerdings verschlechtert sich hierdurch die Performance. Bei einem Backup wird die Anbindung an das CSV in den Redirected Mode geschaltet, wenn das Backup mit Hilfe des Software Providers erfolgt bleibt der Zugriff während des gesamten Backupzeitraums umgeleitet.
Der Zugriff der Hosts auf den Storage erfolgt im Normalzustand wie folgt:
Jeder Host ist (bestenfalls) redundant an den Storage angebunden. Diese Ansicht ändert sich, wenn wir uns im Redirected Mode befinden:
Man kann erkennen, dass der gesamte Traffic über den Coordinator Node läuft. Vorher hatten wir zwei x 1 GBit/s pro Knoten zur Verfügung, diese 8 GBit/s werden nun auf ein Viertel gedrosselt. Wenn sich in dem Cluster 16 Knoten befinden, die alle über einen einzigen Knoten kommunizieren, kann sich dies enorm (negativ) auf die Performance auswirken.
Hardware VSS Provider
Diese Art von Provider wird in der Regel von dem Storage-Hersteller zur Verfügung gestellt, man kann ihn wie einen Treiber für den Storage sehen. Bei der Erstellung eines Backups einer VM wird über den Hardware VSS Provider ein Snapshot auf dem Storage angestoßen, nach Erstellung des Snapshots werden die Daten vom DPM-Server abgeholt. Der Vorteil dieser Art von Provider ist der, dass der Zugriff auf das CSV nur während der Snapshot-Phase im umgeleiteten Modus ist. Nach diesem in der Regel recht kurzen Zeitraum wird der Zugriff wieder online geschaltet, in der Zeit wo die Daten vom Storage über den Host zum DPM-Server gesendet werden ist die Performance nicht durch eine Umleitung beeinträchtigt.
Ein interessanter Artikel mit weiteren Infos und mehr Hintergrund zum Thema “Redirected Mode” finden Sie hier: Ask the Core Team: Troubleshooting ‘Redirected Access’ on a Cluster Shared Volume (CSV)
Der Backup-Vorgang in Zeitlupe
Zur besseren Verständlichkeit hier beide Arten von Backup im Detail. Grundsätzlich gleich sind die vier Clusterknoten Hyperv4, Hyperv5, Hyperv6 und Hyperv7.
Software VSS Provider
Auf dem Data Protection Manager beginnt laut Zeitplan die Sicherung von vWinXPTest. Diese VM befindet sich aktuell auf Hyperv4. Besitzer des CSV ist Hyperv6.
Im DPM startet nun die Sicherung. Als erstes wechselt der Besitzer des Clustervolumes zu dem Besitzer der VM, danach beginnt die Erstellung des VSS-Snapshots. Man erkennt den Backup-Vorgang am Status des CSV.
Dieser Status bleibt nun so lange bestehen, bis das Backup beendet ist. Im Taskmanager auf Hyperv4 erkennt man, dass über das Management-Netzwerk die Daten in Richtung DPM geschickt werden und über die beiden iSCSI-Netzwerke vom SAN geholt werden.
Hardware VSS Provider
Auf dem Data Protection Manager beginnt laut Zeitplan die Sicherung von vWinXPTest. Diese VM befindet sich aktuell auf Hyperv4. Besitzer des CSV ist Hyperv6.
Im DPM startet nun die Sicherung. Als erstes wechselt der Besitzer des Clustervolumes zu dem Besitzer der VM, danach beginnt die Erstellung des VSS-Snapshots. Man erkennt den Backup-Vorgang am Status des CSV. Bis zu diesem Punkt ist die Sicherung gleich, zumindest sieht es für uns so aus. Im Hintergrund wird nun auf dem SAN ein Snapshot angestoßen. Während der Zeit des Snapshots befindet sich das CSV im Umgeleiteten Modus, im Failovercluster-Manager wird der Status angezeigt.
Nachdem der Snapshot auf der NetApp gemacht wurde, wechselt der Status des CSV in den folgenden Modus
Dies bleibt noch eine kurze Zeit so, danach wechselt der Status auf grün (online) und der Zugriff ist ohne eine Umleitung über den Coordinator Node möglich. Die Sicherung ist in diesem Fall allerdings noch nicht fertig, im Hintergrund werden noch fleißig Daten übertragen bzw. geprüft, welche Daten sich geändert haben. Dies ist im Taskmanager erkennbar.
Fazit
Beim Einsatz eines Failover-Cluster sollte man sehr genau darauf achten, dass das genutzte SAN einen Hardware VSS Provider mitbringt. Man verkürzt die Zeit, in der sich das Cluster im Redirected Mode befindet erheblich. Weiterhin wird die Dauer der Gesamtsicherung verkürzt. Ein Failover-Cluster sollte so wenig wie möglich im Redirected Mode betrieben werden, unterstützende Software seitens des SAN-Herstellers helfen hierbei.
