Schlagwort-Archive: Hyper V

Hyper-V

Node Fairness – Lastenausgleich

★ von

Seit geraumer Zeit gibt es verstärkt die Nachfrage nach einem Pendant für System Center Virtual Machine Manager (SCVMM) Dynamic Optimization in Umgebungen ohne VMM. Mit Windows Server 2016 wird es für die dynamische Verteilung von virtuellen Maschinen ein Boardmittel geben: Node Fairness bzw. Virtual Machine Load Balancing.

Failover Cluster Node Fairness soll den Effekt verhindern, dass nach einer Wartung oder einem Neustart eines Servers und damit einhergehender Live Migration die VMs nicht mehr paritätisch auf allen Knoten eines Clusters verteilt sind. Bei einem 4-Knoten Cluster kommt es zum Beispiel nach dem Reboot eines Knoten dazu, dass dieser keine Ressourcen mehr bereitstellt und nur noch passiv am Cluster teilnimmt – hier wäre eine gleichmäßige Verteilung der Ressourcen wünschenswert und genau darum kümmert sich Node Fairness.

Metrik
Dabei wird die RAM- und CPU-Auslastung eines Knoten berechnet. Die Parameter für ein Overcommitment fließen entsprechend in die Bewertung für den automatischen Lastenausgleich ein. Entsprechend einer Priorität des Knotens mit der höchsten Last werden die VMs auf die weiteren Knoten im Cluster verteilt, deren Auslastung geringer ist.
Auf den Mechanismus kann man über die PowerShell Einfluss nehmen: Mit „AutoBalancerMode“ bestimmt man, ob und wann das Feature zum Einsatz kommen soll und „AutoBalancerLevel“ regelt den Schwellwert in drei Stufen, ab wann ein Host anfängt VMs zu verschieben.
Den Modus kann man ebenfalls über einen GUI-Dialog namens „Balancer“ in den Eigenschaften eines Clusters konfigurieren.

Siehe: » https://blogs.msdn.microsoft.com/(…)node-fairness-in-windows-server-2016

Scale-Out
Bei dem Scale-Out eines Hyper-V Clusters können Knoten in den Verbund aufgenommen werden, die danach -automatisiert dank Node Fairness- über Live Migration ohne Downtime mit VMs betankt werden. Auch das stellt ein mögliches Szenario unter Nutzung dieses neuen Windows Server 2016 Features dar.

Eine automatische Verteilung von virtuellen Maschinen basierend auf der Auslastung der an einem Cluster teilnehmenden Hyper-V Hosts bietet im Windows Server Umfeld einen echten Mehrwert: Der Cluster wird insgesamt besser ausgelastet und die Mechanismen dazu greifen im Hintergrund ohne Benutzerinteraktion ein.

Siehe » https://blogs.technet.microsoft.com/(…)whats-new-in-failover-clustering

Credits gehen an MVP Aidan Finn, der das Feature auf Uservoice angeregt hat:
» https://windowsserver.uservoice.com/(…)vm-placement-without-system-center

Windows Server Failover Cluster Node Fairness kann ab Windows Server 2016 TP5 getestet werden.

Stay tuned,
N.Own

Isolated & Quarantined Nodes

★ von

Es gibt zwei neue Failover Cluster States mit der Einführung von Windows Server 2016: Isolated und Quarantined.
Was ist ein Knoten, der isoliert oder unter Quarantäne in einem Cluster steht?
Zuerst ist anzumerken, dass es sich um zwei unterschiedliche States handelt, die eine fehlerhafte Intra-cluster Kommunikation widerspiegeln.

Der Zustand eines Knotens im isolierten Status sagt aus, dass der Knoten nicht mehr aktiv am Cluster teilnimmt. Das kann auftreten, wenn ein Knoten die übrigen Clusterknoten nicht mehr erreicht und zuvor eine oder mehrere VMs gehostet hat. Der Zustand wird in der Failover Cluster Console angezeigt und ist nun keine unbehandelte Ausnahme mehr.
Der Clusterdienst reagiert entsprechend und nimmt einen Knoten gegebenenfalls selbstständig in den Status „isolated“.
Es werden keine Ressourcengruppen mehr auf diesen Knoten verschoben, so dass der Knoten nicht mehr aktiv an einem Cluster teilnimmt.

Ein Knoten, der unter Quarantäne steht, kommt in diesen Status, wenn er z.B. drei mal innerhalb einer Stunde den Cluster unsauber verlassen hat. Es wird davon ausgegangen, dass der Knoten ein Hardware- oder sonstiges Problem hat, das ihn zwar teilweise funktional lässt, aber dennoch persistente Fehler zeigt.
Ein sogenannter „dirty node“ wird dadurch für 2 Stunden aus der Mitgliedschaft zu einem Cluster ausgeschlossen („quarantined“); die gehosteten VMs werden im laufenden Betrieb auf einen aktiven Knoten verschoben.
Dieser Status wird ebenfalls in der Console angezeigt und von einem Clusterdienst selbstständig erkannt und ausgelöst. Er kann als Folge des Zustands der Isolation eines Knotens auftreten.

Weiterhin gibt es einen neuen State, der den Ressourcentyp einer virtuellen Maschine (VM) betrifft: Unmonitored.
Dabei kann eine VM in den Unmonitored Status übergehen, wenn der Cluster den Zustand der VM auf Grund von Fehlern auf einem Knoten nicht mehr überwacht. Auch diesem Zustand wird Rechnung getragen und zur Anzeige in der Failover Cluster Console gebracht.
Dieser Status kann als Folge eines isolierten Knotens auftreten, auf dem die VM dann als „unmonitored“ markiert wird.

Hier der Microsoft Blog Artikel, mit dem die neuen Funktionen angekündigt werden:
» https://blogs.msdn.microsoft.com/(…)virtual-machine-compute-resiliency(…)

Es sind dort auch Parameter beschrieben, mit denen die Funktionen im Detail auf die eigene Umgebung angepasst werden können. Die Konfiguration kann per PowerShell durchgeführt werden und betrifft vor allem Schwell- und Timeout-Werte.

Die neuen, erweiterten Failover Cluster States von Windows Server 2016 helfen letztendlich die Stabilität des Clusters einzuschätzen und zu erhöhen, vormals unbehandelte Fehler werden auf diese Weise automatisch erkannt und angezeigt. Ebenso werden unsaubere Knoten automatisch für einen gewissen Zeitraum ausgeschlossen.
Das erhöht die Belastbarkeit eines Clusters und vermeidet unschöne Folgefehler, Microsoft spricht hier von „Virtual Machine Compute Resiliency“ – also von einer höheren Elastizität für vorübergehende Fehler eines Knotens.

Stay tuned,
N.Own

Rolling Upgrade is back

★ von

Ein Rolling Upgrade unter Nutzung gemischter Betriebssystemversionen im gleichen Cluster ist für Migrationszwecke sehr praktisch. So erlaubte Windows Server 2003 eine gemischte OS-Version unter den Knoten eines Clusters, was es einem ermöglichte Knoten mit Windows 2000 Server und Windows Server 2003 im gleichen Cluster zu betreiben.
Das Vorgehen war denkbar einfach: Failover aller Ressourcen auf einen Clusterknoten, pausieren des nun passiven Knoten und anschließende Aktualisierung der Windowsversion. Danach das Pausieren des passiven Knotens aufheben und Failover der Ressourcengruppen auf den vormals passiven Knoten, nun kann der vormals aktive Knoten pausiert und aktualisiert werden. Nach einer anschließenden Entfernung der Pausierung hat man das Upgrade seiner Clusterknoten erledigt.
Das Szenario ergibt natürlich nur Sinn, um den Cluster auf einfache Weise auf 2003 zu aktualisieren: Ein Betriebsszenario mit gemischten Knoten wird niemand ernsthaft für längere Zeit betreiben wollen.

Was ist der Vorteil des Ganzen? Nun, man vermeidet eine längere Downtime und spart sich Hardware und das ist bei einem Cluster meistens eine teure Angelegenheit, wenn man die LUNs auf der Shared Storage berücksichtigt.
Leider gab es die Möglichkeit ein „Cluster Operating System Rolling Upgrade“ zu nutzen bei Windows Server 2008 (R2) und Windows Server 2012 (R2) nicht mehr – die Komponenten erlagen einem starken Wandel bei der Architektur und haben das Szenario schlichtweg nicht mehr unterstützt.

Welche Versionen unterstützen ein Cluster OS Mixed Mode, um ein Rolling Upgrade zu realisieren?
Rolling Upgrade Matrix - © 2016 N.Own
Microsoft hat erkannt, dass das Feature für Kunden und IT-Dienstleister eine enorme Erleichterung bei einem Upgrade darstellt und wird das Feature mit Windows Server 2016 wieder einführen. Eine Migration von Windows Server 2012 R2 zu Windows Server 2016 wird also wieder weitestgehend unterbrechungsfrei möglich sein:

» https://technet.microsoft.com/en-us/library/dn850430.aspx

Mit der Wiedereinführung dieses Features wird eine Planung und Durchführung eines OS-Upgrade der an einem Cluster beteiligten Serverknoten wesentlich vereinfacht. Eine Migration von Windows Server 2012 R2 zu Windows Server 2016 erlaubt damit die Nutzung derselben Hardware.

Stay tuned,
N.Own

Netzwerkeinstellungen auf einem Cluster

★ von

„Best Practice“ Empfehlungen sind nicht immer passend zu jeder Lösung, die man aufbauen kann. Im Falle von Hyper-V gibt es recht klare Richtlinien bzgl. der Netzwerkkonfiguration auf einem Cluster, die man berücksichtigen sollte:

  • Trennung und Isolation der Netzwerke nach Einsatzzweck: Management, Live Migrations, Storage, Client Access, Backup etc.
  • Anpassung der Adapter und Bindungen (Network Binding Order)
  • Anpassung der Quality of Service Policy hinsichtlich der Prioritäten ab W2K12

Siehe folgenden Artikel für Hyper-V Cluster:
» http://technet.microsoft.com/library/dn550728.aspx

Bei Nutzung von Cluster Shared Volumes (CSV) sollte man die Metric überprüfen, i.d.R. wählt der Cluster das passende CSV Netzwerk selbst aus – eine Kontrolle kann nicht schaden:
» http://technet.microsoft.com/en-us/library/ff182335%28WS.10%29.aspx

Für Exchange 2013 sowie 2010 Verfügbarkeitsgruppen (Database Availability Groups – DAG) gibt es jeweils einen Artikel:
Exchange 2013: » http://technet.microsoft.com/(…)exchg.150%29.aspx#Dat
Exchange 2010: » http://technet.microsoft.com/(…)exchg.141%29.aspx#Dat

Grundlegende Empfehlungen, die für jeden Cluster gelten, sind hier zu finden:
TechNet Blog: » http://blogs.technet.com/(…)configuring-windows-failover-cluster-networks.aspx
MSDN Channel 9: » http://channel9.msdn.com/Events/TechEd/(…)

Die Empfehlungen des Herstellers sollte man mindestens prüfen und idealerweise entsprechend umsetzen, außer es gibt triftige Gründe gewisse Einstellungen anders zu wählen für den eigenen Anwendungsfall.

Stay tuned,
N.Own