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

    VM Compute Resiliency im Hyper-V-ClusterHyper-V-Cluster reagieren sen­sibel bei Aus­fällen von Kompo­nenten im Ver­bund. Folglich kommt es unmit­telbar zum Failover hochverfügbarer Maschinen. Doch dieses Ver­halten ist nicht immer ideal. Cluster unter Server 2016 lassen in solchen Situa­tionen andere Reaktionen zu.

    Kurze vorübergehende Ausfälle mit Beein­trächtigung der Intra-Cluster-Kommunikation (aka East-West) sind nicht immer proaktiv zu vermeiden. Ein Failover der virtuellen Maschinen ist dann zwar grundsätzlich erwünscht, weil ein Cluster schlussendlich genau dafür konfiguriert wurde. Manchmal kann ein Abwarten ohne Neustart vieler VMs aber die bessere Option sein.

    VMs trotz Ausfall eines Knotens online

    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.

    Failovercluster-Manager zeigt Knoten-Status Isoliert

    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.

    VMs zeigen nach Ausfall eines Knotens den Status 'Nicht überwacht'

    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.

    VM Compute Resiliency: Knoten unter Quarantäne

    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.

    VM Compute Resiliency: Konfiguration anzeigen mit PowerShell

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

    BeschreibungDefaultWertPowerShell
    ResiliencyDefault­Period
    Zeitfenster in Sek., in dem es VMs erlaubt ist, isoliert zu laufen.
    240 0: definiert ein Verhalten wie vor Windows Server 2016 (Get-Cluster).Resiliency­DefaultPeriod = <Wert>
    Granular pro hochverfügbarer VM:
    (Get-ClusterGroup "VM").Resiliencyy­Period = <Wert>
    ResiliencyLevel
    Bestimmt, wie unbekannte Ausfälle behandelt werden.
    2 1: IsolateOn­SpecialHeartbeat

    Nur bei bekannten Gründen wie Crash des Cluster-Dienstes oder asym­metrischer Verbindung die Nodes isolieren.
    2: AlwaysIsolate

    Knoten immer isolieren, bevor ein Failover der VMs nach definiertem Zeitfenster stattfindet.
    (Get-Cluster).Resiliency­Level = <Wert>

    VM Compute Resiliency: Werte für die Quarantäne von Knoten.

    BeschreibungDefaultWertPowerShell
    QuarantineDuration
    Dauer in Sek., während der ein Knoten in Quaran­täne verweilt.
    7200 0xFFFFFFFF: Knoten bleibt in Quaran­täne und wird dem Verbund nicht mehr zugefügt. (Get-Cluster).Quarantine­Duration = <Wert>
    Quarantine­Threshold
    Anzahl von Aus­fällen inner­halb einer Stunde bevor ein Knoten unter Quarantäne gestellt wird.
    3   (Get-Cluster).Quarantine­Threshold = <Wert>

    Keine Kommentare