Cluster Operating System Rolling Upgrade
Durch Cluster Operating System Rolling Upgrade ist es nun möglich das Betriebssystem eines Clusterknotens von Windows Server 2012 R2 auf Windows Server 2016 zu aktualisieren ohne den Knoten aus dem Cluster nehmen zu müssen. Auch vorhandene Hyper-V oder Scale-Out Fileserver Workloads müssen nicht beendet werden. Bei Migrationen von Clusterumgebungen auf Windows Server 2016 kann somit eine durchgängige Verfügbarkeit gewährleistet werden.

Robuste virtuelle Maschinen
Windows Server 2016 ermöglicht es robustere virtuelle Maschinen bereit zu stellen. Hierzu wurden mehrere neue Funktionalitäten für Hyper-V Cluster implementiert. Sollte eine Virtuelle Maschine temporär keinen Zugriff auf den zentralen Speicher haben wird die virtuelle Maschine pausiert. Der Kontext der Anwendungen in der VM bleibt erhalten bis der Zugriff auf das Storage System wieder möglich ist. Die virtuellen Maschinen sowie die darin laufenden Anwendungen können nach Wiederherstellen des Storage Zugriffs ohne Datenverlust fortgesetzt werden.

Sollte es auf einem der Clusterkonten zu technischen Problemen kommen kann dieser automatisch isoliert werden um Probleme durch unzuverlässig arbeitende Clusterknoten auszuschließen. Virtuelle Maschinen werden nicht auf solche isolierten Knoten platziert.

Cloud Witness (Cloud Zeuge)
In Cluster Szenarien ist in Abhängigkeit von der Konfiguration ein Zeuge erforderlich um im Fehlerfall eine korrekte Failover-Entscheidung treffen zu können. Disks und Fileshares können schon in vorherigen Windows Server Versionen als Zeugen konfiguriert werden. Neu in Windows Server 2016 ist die Option einen Cloud Zeugen auf Basis von Microsoft Azure konfigurieren zu können. Die Konfiguration erfolgt über den Failover Cluster Manager im Windows Server 2016.

Site-aware und Chassis-aware Failover Cluster
In Windows Server 2016 ist es möglich Clusterknoten in Anhängigkeit von ihrem physischen Standort zu gruppieren. Dabei ist eine Gruppierung auf Basis der geografischen Location möglich, aber auch Lösungen die mehrere Serverknoten in einem Chassis bündeln können berücksichtigt werden. Das Gruppieren der Clusterknoten hat Auswirkungen auf das Verhalten Falle eines Failovers und auf das Verhalten zur Verteilung der Workloads.

Workgroup und Multi-Domain Cluster
In Windows Server Versionen bis einschließlich Windows Server 2012 R2 konnten Cluster nur aus Servern gebildet werden die sich in einer gemeinsamen Active Directory Domäne befanden. Mit Multi-Domain Cluster und Workgroup Cluster gibt es zwei neue Konfigurationsoptionen in Windows Server 2016. Windows Server 2016 unterstützt somit drei Varianten der Clusterkonfiguration:

  • Single-Domain Cluster: Alle Knoten der Clusterkonfiguration sind Mitglied der gleichen Active Directory Domäne
  • Multi-Domain Cluster: Die Konten der Clusterkonfiguration befinden sich in unterschiedlichen Active Directory Domänen
  • Workgroup Cluster: Die Knoten der Clusterkonfiguration befinden sich in einer Arbeitsgruppe und sind nicht Mitglied einer Active Directory Domäne

Virtual Machine Load Balancing
Das automatische Load Balancing für virtuelle Maschinen in einem Hyper-V Cluster ist eine neue Funktionalität in Windows Server 2016. Die Auslastung der Cluster Knoten wird basierend auf der Auslastung des Speichers und der CPUs auf den Clusterknoten ermittelt. Virtuelle Maschinen werden automatisch und ohne Betriebsunterbrechung per Live Migration von überlasteten Clusterknoten auf weniger belastete Clusterknoten verschoben. Für das Virtual Machine Load Balancing wird kein System Center Virtual Machine Manager benötigt. Der System Center 2016 Virtual Machine Manager (SCVMM) bietet erweiterte Optionen zur automatischen Lastverteilung. Bei Einsatz des SCVMM wird Virtual Machine Load Balancing deaktiviert und die erweiterten SCVMM Optionen werden genutzt.

Virtual Machine Start Order
Über Virtual Machine Start Order kann für virtuelle Maschinen in einem Windows Server 2016 Cluster die Startreihenfolge festgelegt werden. Dazu werden virtuelle Maschinen in Ebenen zusammengefasst und für die einzelnen Ebenen wird eine Startreihenfolge definiert. Mittels Virtual Machine Start Order kann sichergestellt werden, dass wichtige virtuelle Maschinen wie z.B. Domain Controller vor den virtuellen Maschinen gestartet werden die auf den Domain Controller angewiesen sind.