Hyper-V, CSV, VSS, Speicher- und Backup-Voraussetzungen

Der Hyper-V-MVP Aidan Finn hat ein lesenswertes Whitepaper veröffentlicht, in dem er einige Hintergründe zum Storage-Management von Hyper-V im Detail erklärt. Sein Schwerpunkt liegt dabei auf CSV-Speichern (Cluster Shared Volumes) in Hyper-V-Clustern sowie deren Einbindung in die VSS-Technik (Volume Shadow Copy Services), die oft für die Datensicherung verwendet wird. Dabei lauern einige Fallen, die man bereits beim Design des Clusters und der Speicherlösung beachten sollte.

[Whitepaper – Planning Hyper-V CSV and Backup]
http://www.aidanfinn.com/?p=11491

Hier einige der wichtigsten Aussagen in Aidans Whitepaper in Kurzform.

Erst mit CSV erhält ein Virtualisierungs-Cluster seine Flexibilität. Nach wie vor beruht ein Windows-Cluster auf dem “Shared Nothing”-Prinzip, er ist also in jeder Hinsicht ein “Aktiv-/Passiv-System”. Die Neuerung eines CSV besteht nun darin, dass ein Speicher-Volume (eine so genannte “LUN” (Logical Unit Number) aus dem SAN) gleichzeitig von mehreren Clusterservern verwendet werden kann. Da das Dateisystem NTFS selbst nicht clusterfähig ist (gleichzeitiges Schreiben und Lesen von mehreren Servern auf demselben Volume würde die Konsistenz des Dateisystems zerstören), bringt CSV eine weitere Technik mit, den “CSV Coordinator Node”. Sie sorgt dafür, dass alle Schreibzugriffe auf denselben Datenbestand in koordinierter Form geschehen. Der CSV Coordinator läuft auf einem der Clusterknoten, den Windows automatisch auswählt. Dabei findet ein automatisches Failover auf einen anderen Clusterserver statt, falls der Coordinator nicht erreichbar sein sollte. Man kann die Funktion auch manuell auf einen anderen Knoten verschieben.

Durch CSV ist es nun also möglich, dass mehrere virtuelle Maschinen auf derselben LUN gespeichert sind, aber trotzdem von verschiedenen Clusterservern kontrolliert werden. Im Effekt benötigt man also weniger LUNs im SAN.

Wichtig: In Windows Server 2008 R2 sind CSVs ausschließlich für Hyper-V zugelassen! Erst in Windows Server “8” soll sich das ändern.

VSS sorgt für konsistente Shapshots auf der Storage-Ebene und ermöglicht so schnelle Backups. Die Speicher-Schnappschüsse sind mit dem Betriebssystem und einigen Applikationen abgestimmt und sorgen dafür, dass im Moment des Snapshots alle Speichervorgänge korrekt abgeschlossen sind. Dadurch können VSS-Snapshots (nicht zu verwechseln mit VM-Snapshots oder anderen ähnlichen Funktionen!) als Grundlage für eine Datensicherung dienen.

In einem CSV schaltet VSS den “Redirected Mode” ein! Dieser Umstand ist wenig bekannt. VSS und einige andere Operationen erfordern einen Low-Level-Zugriff auf das Speicher-Volume. Um dies zu gewährleisten, muss der CSV Coordinator vorübergehend die gesamte Kontrolle über die Speicherzugriffe übernehmen (im Normalbetrieb können die anderen Clusterknoten direkt lesen und schreiben). Hierfür nutzt er den “Redirected Mode”, wodurch alle Schreibzugriffe auf das betreffende CSV komplett über den CSV Coordinator laufen – und nicht mehr direkt über das SAN. Das bedeutet selbstverständlich eine deutliche Reduktion der Zugriffsgeschwindigkeit.

Erst wenn der Low-Level-Zugriff vollständig abgeschlossen ist, kann der CSV Coordinator den Redirected Mode verlassen und den Clusterknoten wieder den direkten SAN-Zugriff auf das CSV erlauben.

Es kann mehr als ein CSV geben. Es ist ein häufiges Missverständnis, dass es in einem Cluster nur ein CSV geben könne. Das ist aber nicht richtig. Tatsächlich sind mehrere CSV möglich, und das Gesamtdesign macht es oft sogar sinnvoll oder nötig, mit mehr als einem CSV zu arbeiten.

Je häufiger VSS auf einem CSV genutzt wird, desto häufiger ist der Redirected Mode in Betrieb. Dabei ist es egal, wie viele VMs auf einem CSV gerade per VSS gesichert werden – ein VSS-Snapshot für eine einzige VM sorgt dafür, dass das ganze CSV in den Redirected Mode wechselt. Häufige oder schlecht abgestimmte VSS-Backups auf VM-Ebene sorgen also dafür, dass die Speicherleistung für das gesamte CSV in größeren Zeitabschnitten reduziert ist.

Dynamische VHDs erfordern zur Vergrößerung den Redirected Mode. Auch das Vergrößern von dynamischen VHD-Dateien erfordert die Mitwirkung des CSV Coordinator und des Redirected Mode. Für die meisten Applikationen wird ohnehin vom Einsatz dynamischer VHDs abgeraten, doch in einem CSV-Cluster sollte man völlig darauf verzichten. Vorsicht: Der Hyper-V-Manager erzeugt standardmäßig für neue VMs dynamische VHDs, die man danach manuell konvertieren sollte.

Das CSV-Design muss auf die Backup- und Betriebsstrategie abgestimmt sein. Die obigen kurzen Hinweise deuten schon darauf hin, dass bei ungünstiger Planung das CSV oft in den langsamen Redirected Mode wechseln muss. Damit dies so selten wie möglich passiert, sollte bereits in der Planungsphase die Speicherplanung auf die Anforderungen der Datensicherung, des Gesamtbetriebs und der Möglichkeiten zur VSS-Anbindung angepasst werden. Hierzu gibt es keine “One sitze fits all”-Empfehlung, sondern der Vorgang erfordert genaue Analyse, insbesondere in größeren Umgebungen. Aidans Whitepaper gibt sehr gute und ausführliche Hinweise dazu.