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.

Aktuell sieht der Bereich “Aggregate” wie folgt aus:

Der Punkt “Volumes” zeigt die folgenden Volumes:

Jedes der Volumes enthält eine LUN, diese sehen wie folgt aus:

Wie man erkennen kann, ist csv1 und quorum1 online, die beiden mittleren LUNs sind offline und aktuell nicht verbunden.

Nachdem man sich per ssh auf die Managementkonsole der FAS6040 geschaltet hat, kann man die Migration eines Volume mit dem folgenden Befehl starten:

vol move start Quell-Volume Ziel-Aggregat

In meinem Fall beginne ich mit Vol1, einem offline geschalteten Volume.

Mit dem Befehl

vol move status –v

kann man sich den Verlauf der Migration anschauen. An dieser Stelle wird lange Zeit nichts angezeigt, die Größe der verschobenen Daten bleibt hier scheinbar die ganze Zeit bei 0 KB, obwohl im Hintergrund die Daten migriert und verschoben werden.

Nachdem die Migration erfolgreich beendet wurde, erscheinen die folgenden Meldungen:

Der Manager zeigt das folgende Bild:

Das ganze funktioniert auch mit online-Volumes:

Da es sich nur um 1GB handelt, wir dies natürlich sehr schnell übernommen. Nach der Übernahme sieht der Manager wie folgt aus:

Das Cluster und die Cluster-Knoten bekommen von der ganzen Sache nichts mit, das ganze passiert alles im Hintergrund. Cooles Feature :)

Hyper-V Server 2008 R2 – Bare Metal to Live Migration (Dauer: 48:34)

Video über die Einrichtung eines Hyper-V Server 2008 R2 Clusters