VM Storage Resiliency - Toleranz gegenüber Ausfällen von Speichersystemen

Bei kurzen Unter­brechungen der Intra-Cluster-Kommunikation werden VMs nicht sofort per Failover auf einem anderen Host neu gestartet, sondern sie bleiben eine gewisse Zeit online. Der neue Status Nicht überwacht signalisiert dann, dass diese Maschinen nicht mehr aktiv durch den Verbund überprüft werden. Der Knoten selbst erreicht den Status Isoliert.

Kurze Unterbrechungen der Storage-Verbindung

Durch den Einsatz von Software Defined Storage (SDS) wie Scale-out File-Server mit Storage Spaces oder demnächst Storage Spaces Direct spielen auch kurze Ausfälle eine größere Rolle. Oftmals kommt zertifizierte Standard-Hardware für diese Features zum Einsatz und flüchtige Unter­brechungen im Verbund sind daher möglich.

In einem Hyper-V Cluster, wo die virtuellen Maschinen und deren VHD(X) (Virtual Hard Disk) auf einem Cluster Shared Volume eines zentralen Storage abgelegt werden, sorgt die redundante Anbindung des Speichersystems für die nötige Stabilität. Wird aber diese Strecke durch eine auch nur temporäre Trennung gestört, dann sind virtuelle Maschinen samt Applikationen nicht mehr in der Lage, ihre Daten auf die virtuelle Platte zu schreiben oder von dort einzulesen. Das Resultat bei einem Cluster unter Windows Server 2012 R2 ist ein verzögerter Crash der VMs nach 60 Sekunden.

Verhalten eines 2016-Clusters gegenüber Fehlern

Elastischer mit erhöhter Resilienz stellt sich das Verhalten von virtuellen Maschinen eines Windows Server 2016 gegenüber diesen Unterbrechungen dar. Sobald diese erkannt werden und der I/0 nicht zur VHD(X) fließt, dann frieren VMs kurzerhand ein und gelangen in den Angehaltenen Zustand (Paused-Critical). Diese Reaktion ist per Default aktiviert und bei Blackouts begrüßenswert.

Kommt die Verbindung zum Speicher und der VHD(X) binnen 30 Minuten wieder zustande, dann nimmt die eingefrorene VM wieder Fahrt auf und wird fortgesetzt, andernfalls wird sie abgeschaltet. Nicht nur der Failovercluster-Manager zeigt die Zustände der VMs an, sondern auch der Hyper-V-Manager gibt entsprechende Status-Meldungen aus.

Wann kommt VM Storage Resiliency zum Einsatz?

VM Storage Resiliency kommt nicht bei VHD(X)-Volumes auf lokalen physischen Systemen ohne CSV zum Einsatz, vielmehr ist die Ablage auf einem CSV Voraussetzung. Zulässig sind virtuelle Maschinen der Generationen 1 und 2 mit VHD, VHD(X) und auch Shared VHD(X) werden berücksichtigt.

Bei SANs akzeptiert dieses Feature blockbasierte Speicher, die über Fibre Channel, iSCSI, FCoE oder Shared SAS angebunden sind. Microsoft unterstützt erwartungs­gemäß auch dateibasierte SMB-Freigaben wie jene auf einem Scale-out File-Server.

PowerShell für die Feinabstimmung

Das Feature lässt sich mit PowerShell auf die eigenen Bedürfnisse hin anpassen. Die Einstellungen können granular pro virtueller Maschine erfolgen. Wenn gewünscht, lässt sich auch generell ein Verhalten von Windows Server 2012 (R2) wiederherstellen.

Wie bereits eingangs erwähnt, ist Storage Resiliency standardmäßig aktiviert, und um es zu deaktivieren schalte ich es testweise im Labor mit folgendem Cmdlet ab:

Set-VM -Name HA-VM-01 -AutomaticCriticalErrorAction None

Mit den Schaltern Pause und None kann man das Pausieren von VMs aktivieren bzw. abschalten. Wie lange ein hochverfügbarer virtueller Computer im eingefrorenen Zustand verweilen darf, bis er letztendlich abgeschaltet wird, lässt sich mit diesem Aufruf festlegen:

Set-VM -Name HA-VM-01 -AutomaticCriticalErrorTimeout <Wert in Minuten>

Hier ist Out of the Box ein Wert von 30 Minuten definiert, welcher an die On-Premises Bedürfnisse angepasst werden kann.