VM Compute Resiliency: Toleranz bei temporären Ausfällen im Hyper-V-Cluster

Verschiedene Parameter in einem Hyper-V 2016 Cluster können genau dieses Verhalten beeinflussen und lassen den Verbund belastbarer (resilient) gegenüber solchen Ausfällen werden. Die angesprochenen Einstellungen sind über PowerShell erreichbar und modifizierbar.

Ein Beispiel für einen Ausfall wäre der Absturz des Cluster-Dienstes oder eine kurze Netzwerk­unterbrechung eines Knotens, sodass dieser nicht mehr mit dem Rest des Verbundes kommunizieren kann.

Virtuelle Maschinen eines Windows Server 2016 Clusters mit aktiver Resiliency (Default), abgelegt auf einem Scale-out File-Server (SoFS), würden dann trotzdem in einem bestimmten Zeitfenster online bleiben. Kommt der Knoten innerhalb einer vorgegebenen Frist wieder zurück, dann arbeitet der Verbund ohne jegliches Failover der VMs weiter.

Die Statuszustände im Hyper-V Cluster

Die Zustände eines Knotens im Hyper-V 2016 Cluster lauten dann Isoliert oder auch Unter Quarantäne, virtuelle Maschinen können die Bezeichnung Nicht überwacht tragen. Wie ein Knoten den Isoliert-Status (Isolated) erreicht, überprüfe ich in meinem Hyper-V-Labor bestehend aus zwei Knoten und drei v7.1 HA-Maschinen im ClusterFunctionalLevel 9.

Alle drei VMs laufen auf Knoten 2, und um einen Crash zu simulieren, beende ich den Cluster-Dienst hart auf diesem Knoten mit

Stop-Process -Name Clussvc

Ein Recovery des Services habe ich zuvor deaktiviert. Die VMs werden anschließend nicht live migriert, nicht per Quick Migration verschoben auch findet kein Failover statt, sondern der Knoten erreicht per Default den Status Isoliert und virtuelle Maschinen Nicht überwacht (Unmonitored). In diesem Zustand dürfen die virtuellen Maschinen 4 Minuten verweilen und bleiben bei Ablage auf einem SoFS dank der Unabhängigkeit von SMB-Freigaben weiter erreichbar. Der Scale-out File-Server als eigenständige Tier inkl. Cluster Shared Volumes (CSV) ist hier vom Cluster-Dienst Absturz des Hyper-V Clusters nicht betroffen.

Beim Einsatz eines block­basierten Speichers, der beispielsweise über FC, iSCSI, Shared SAS etc. direkt angebunden ist, werden sie dagegen erst einmal pausiert (Paused-Critical, VM Storage Resiliency), da im Beispiel des Cluster-Dienst Crash die Verbindung zum CSV verloren geht. Der Status wird auch über den Hyper-V-Manager ausgegeben. Kommt die Kommunikation mit dem Knoten innerhalb von 4 Minuten erneut zustande und er kann dem Verbund aktiv wieder beitreten, dann erreichen auch VMs wieder ihren Status Wird ausgeführt. Andernfalls erfolgt der Failover zum bestmöglichen Knoten.

Flapping Nodes bzw. generell Problemknoten, die mehrfach hintereinander innerhalb eines Zeitfensters den Isoliert-Status zeigen, werden für 2 Stunden in Quarantäne geschickt. Ein Schwellenwert, standardmäßig 3, bestimmt wie oft eine Node innerhalb einer Stunde ausfallen darf, bevor diese Maßnahme greift.

Die virtuellen Maschinen werden dann über die restlichen Knoten per Migration verteilt. Möchte man den Quarantäne-Knoten dem Verbund wieder manuell anschließen, kann dies mit Start-ClusterNode -ClearQuarantine bewerkstelligt werden.

Knoten-Isolation und Quarantäne über PowerShell beeinflussen

Das Verhalten für die VM Compute Resiliency lässt sich mit einigen PowerShell-Schaltern verändern. Ein

Get-Cluster | fl *

liefert bekanntlich erst einmal die grundlegenden Werte zur aktuellen Verbund­konfiguration.

Die folgenden Tabellen geben Aufschluss zu weiteren Konfigurations­werten und deren Auswirkung in Zusammenhang mit dem 2016er-Feature: