Hier sind die Highlights von unserem 2019 Failover Cluster Kurs:

• Multi-NIC Cluster Network & Simplified SMB Multichannel
• 10 GBit und 100 GBit R-NIC (RDMA NIC) für iWARP (Internet Wide Area RDMA Protocol) / RoCEv2 (RDMA over Converged Ethernet)
• RoCEv2 benötigt QoS (Quality Of Service) und DCB (Data Center Bridging) mit PFC (Priority Flow Control) und ETS (Enhanced Transmission Selection)
• Storage Spaces Direct (S2D) over SMB 3.1.1
• Storage Replication (SR) over SMB 3.1.1
• SOFS (Scale-Out File Server) in Kombination mit Storage Spaces Direct (S2D) und R-NIC
• Hyper-V SET (Switch Embedded Teaming) mit R-NIC und SR-IOV
• Hyper-V Cluster Full & Server Core
• Hyper-V Node Fairness und VM Resiliency Workflow
• Azure Cloud Witness vs. File Share Witness
• Fault Domains und Site-awareness Failover Cluster
• PowerShell für Cluster, PowerShell Direct, PowerShell Workflow
• Troubleshooting: Cluster Performance History, Cluster Log, Cluster Active Dump, Live Dump
• Nutzung der Azure Log Analytics (Optional)
• Erweiterung: ClusterSet -Infrastructure SOFS, Root Namespace Referral SOFS, Logical Fault Domain und Availability Set
• Ausblick: Windows Server 2022 / Azure Stack HCI Failover Clustering

Damit ein Failover Cluster sein Quorum (Mehrheit) bekommt, sind mind. 3 Stimmen (Votes) notwendig. Der Cluster soll daher optimalerweise auf 3 Lokationen verteilt sein. Mit dem Feature „Cloud Witness“ kann man für sehr geringe Kosten eine weitere Clusterstimme (Vote) in der Azure Cloud anlegen. Die „On-Premises“ Clusternodes kommunizieren mit dem Cloud Witness über HTTPS, da eine Cloud Witness als „Blob Storage“ via URL erreicht werden kann. Auch ein File Share Witness (FSW) in der Azure Cloud kann ab 2012 R2 Cluster konfiguriert werden, dafür ist aber eine IPSec-Verbindung via Site-To-Site VPN-Gateways und eine Platzierung von einem Domain Controller in der Azure Site notwendig. Diese Lösung ist daher nicht unbedingt praktikabel.

Absolutes Highlight von 2016 und nun auch bei 2019 Clusters sind die Features Storage Spaces Direct (S2D) und Storage Replication (SR), die das Protokoll SMB 3.1.1 für den Transport der Blockdaten über den Software Storage Bus (SSB) nutzen. S2D kann teure SAN weitgehend ersetzen, wenn die dafür benötigte Netzwerkbandbreite und RDMA-Netzwerkkarten zur Verfügung stehen. Ab 2016 Cluster kann mit SR für traditionelle File Server Cluster über zwei Standorte verteilt werden (Stretch-Cluster). Erst mit 2019 Cluster kann mehere S2D über mehrere Standorte mit ClusterSet einsetzen. Storage Spaces Direct nutzt die lokalen HDDs, SSDs und RAM (SATA, SAS, NVMe, SCM) der Clusternodes, um daraus einen gemeinsamen Storage Pool zu bilden. Virtual Disks (Storage Spaces) können aus dem Storage Pool als RAID1, RAID5, RAID10, etc. heraus „geschnitten“ werden. Die Storage Spaces sind bei mindesten 2 Clusternodes hochverfügbar.

Ein weiteres Feature für Disaster Recovery ist Storage Replication (SR). Mit SR werden Platteninhalte in Block Mode von Server-To-Server oder Cluster-To-Cluster oder ein Mix davon von Quelle zum Ziel via den SSB synchron oder asynchron repliziert. Bei Ausfall der Quellplatte wird die Kopie automatisch bzw. manuell aktiviert. Somit ist es möglich eine hohe Datenverfügbarkeit in einer Umgebung, in welcher Storage Space Direct nicht möglich ist (zu hohe Latenzzeit), zu gewährleisten.

S2D und SR nutzen das erweiterte SMB 3.1.1 Protokoll, welches nun als Grundlage für viele Datentransporte und Anwendungen eingesetzt wird (Live Migration, CSV, Multi-Channel etc.). In Kombination mit 10 Gbit/s RDMA fähigen Netzwerkkarten und ab der Treiberversion NDIS 6.60 sorgt SMB 3.1.1 dafür, dass High Speed Networking möglich ist. Durch RDMA werden Applikationsdaten (User Mode), ohne im Betriebssystem (Kernel) zwischenzupuffern, direkt über das Netzwerk zur Zielapplikation transportiert. RDMA setzt ein „losless“ Netzwerk mit „hoher Bandbreite“ (High Bandwidth) und „niedrige Latenzzeit“ (Low Latency) voraus. Damit dies über das ETHERNET auch möglich ist, müssen sowohl das Betriebssystem, die Netzwerkkarten als auch die beteiligten Switche QoS-fähig (Quality of Service) und auch DCB-fähig (Data Center Bridging) sein. Mit QoS Policies kann man dem SMB Direct (RDMA = NetDirect) hohe Priorität (PFC = Priority Flow Control) und Bandbreite (ETS = Enhanced Transmission Selection) zuweisen. Der RDMA Durchsatz ist erheblich höher als ohne RDMA und liegt bei 10 Gbit-NIC über 1 bis 2 GByte/s. Daher ist ein RDMA fähiges 10 Gbit/s-Netzwerk in einer High Speed Serverumgebung für alle Arten des SMB Transports Pflicht! SMB Direct ist SMB over RDMA, Storage Spaces Direct ist Storage Spaces over RDMA. Es sieht im Moment so aus, dass iWARP (Internet Wide Area RDMA Protocol) sich gegenüber Infiniband und RoCEv2 durchsetzen wird. Wir setzen im Kurs bereits die neuesten 10 GBit R-NIC ein, die RoCEv2, QoS, DCB, DCBx und die Network Overlay Protokolle NVGRE und VXLAN unterstützen.

Der seit 2012 verfügbare Scale-Out File Server (SOFS) bekommt in 2016 und nochmal in 2019 Failover Cluster durch SMB 3.1.1 und Storage Spaces Direct noch mehr Gewicht. Er bildet das Herzstück des Microsoft SDS (Software Defined Storage) Konzepts in 2019 sogar SDDC (Software Defined Data Center). Anwendungen wie Hyper-V oder SQL können ihre VHDX bzw. Datenbanken via SMB Direct (SMB over RDMA) über das Ethernet auf einem hochverfügbaren SOFS mit „preiswerten“ lokalen Festplatten speichern. Die SAN Abhängigkeit enfällt. In Kombination mit SMB 3.1.1. Multichannel und RDMA wird File Service in eine noch nie da gewesene Performance katapultiert. Für den Zugriff auf einen „traditionellen“ File Server Cluster profitieren SMB 3.x Clients (Windows 8 und neuer) gegenüber „legacy“ SMB Clients (Windows 7 und älter) von der Funktionalität des SMB 3.x Transparent Failovers.

In einer Enterprise Umgebung soll ein Hyper-V Host bzw. Cluster von der Datenspeicherung getrennt sein. Ein „Converged“ (Compute) Hyper-V speichert seine VMs nicht lokal, sondern via SMB 3.1.1 auf einem Scale-Out File Server Cluster (SOFS), der auch als Speicherort für SQL 2016/2017 Server dienen kann. Für die Virtualisierung mit Hyper-V bringt ab 2016 einige Features mit, wie die sog. VM Start Order, welche durch die Festlegung der Abhängigkeit von anderen VMs definiert wird. VMs gleicher Funktionalität wie z.B. Domain Controller werden einem Cluster Group Set zugewiesen. Anwendungs-VMs in einem anderen Cluster Group Set können nur gestartet werden, wenn die DCs bereits gestartet sind. Mit 2019 wurden die Cluster Sets eingeführt, die Ressourcen in unterschiedlichen Clustern zusammenfassen können.

Ein ganz neues Fehlertoleranz-Konzept ab 2016 Cluster ist die sog. Fault Domain, welches bereits in Azure praktiziert wird. Ein Single-Point of Failure soll innerhalb eines Clusters dadurch unbedingt vermieden werden. Die Clusternodes sollen nicht alle in einer Site platziert werden, sie sollen auch nicht gemeinsam in einem Rack und Chassis aufgebaut werden. Die Top-Down Fault Domain Struktur besteht aus 4 Ebenen Site ➔ Rack ➔ Chassis ➔ Node, die für manche Features wie S2D und SR die Voraussetzung ist. Das bedeutet, dass ein Failover (Failover Affinity) vorzugsweise auf einen anderen Node in derselben Site (Fault Domain) vollzogen wird, wenn diese Site mind. 2 Nodes besitzt und als Fault Domain festgelegt wurde. Durch die Storage Affinity bevorzugt eine VM bei einem Ausfall des Hyper-V Hosts ein Clusternode in derselben Site. Site Fault Domain wird auch bei der Auswahl eines neuen CSV Coordinators angewandt. Neben SameSubnet und CrossSubnet bringt ab 2016 Cluster zusammen mit Site Fault Domain das Cross-Site Heartbeating. Man kann nun das Threshold für Heartbeats zwischen den Sites auf Clusterebene festlegen, das Vorrang vor SameSubnet und CrossSubnet hat, auch wenn die Site Fault Domains im selben IP-Subnet sein können » Site Fault Domain kann mit AD Site oder auch ohne arbeiten.

Verwandt, jedoch nicht gleichzusetzen mit Site Fault Domain ist die Möglichkeit, clusterweit eine Preferred Site für Dynamic Quorum zu definieren. Wenn das Netzwerk zwischen zwei Datacentern mit je 3 Nodes ausfällt, wird automatisch das Quorum so justiert, dass eine Preferred Site eine Stimme mehr als die andere Site hat.

Mit dem Feature Failover Cluster Node Fairness für Hyper-V kann über den Parameter AutoBalancerLevel (Low, Medium, High) auf Clusterebene festgelegt werden, wie aggressiv die automatische Lastverteilung der VMs auf Hyper-V Clusternode ist. Standardmäßig (=Low) werden VMs auf andere Clusternodes erst verschoben, wenn die CPU und Memory Nutzung 80% auf dem Hyper-V Host überschritten wurde.

Damit die Verwirrung perfekt ist, gibt es ab 2016 Failover Cluster das Feature Virtual Machine Compute Resiliency, mit dem das Verhalten von Hyper-V Hosts bei einem Fehler und somit auch die verbleibenden VMs gesteuert werden kann. Drei States (Stati) bestimmen den Zustand von VM und Host: Unmonitored State für die VM, Isolated und Quarantine State für den Hyper-V Host. Ein Host landet in der Quarantäne, wenn er z.B. dreimal innerhalb einer Stunde den Cluster unsauber (z.B. Heartbeat Threshold überschritten) verlässt. In diesem Fall werden seine VMs auf andere Clusternodes verschoben. Natürlich kann dies auch mit Fault Domains kombiniert werden!

Sie lernen im Kurs die Microsofts „patentierte“ Clustertechnologie mit Paxos und Quorum Set Replication Algorithmus für Distributed Systems kennen, die seit 2008 Cluster zum Einsatz kommt und erweitert wurde. Im Gegensatz zu „Single Quorum“ von Windows 2003 Cluster arbeitet ein Failover Cluster ab 2008 mit dem neuen Hybrid-Quorum nach dem Multimaster Prinzip. Selbst bei einer defekten Quorum-Disk arbeitet ein 2-Node Cluster stabil weiter. Das Quorum Modell wird mit Windows 2012 Failover Cluster um Dynamic Quorum erweitert. Dynamic Quorum sorgt dafür, dass ein ordentlich heruntergefahrener Clusternode DynamicWeight=0 bekommt, sodass die Quorum-Bildung sogar für kurze Zeit mit einem einzigen Clusternode auch ohne Forcequorum möglich ist. Ja, es ist sogar möglich, dass ein 2012 Failover Cluster mit weniger als 50% Stimmen immer noch arbeiten kann. Unabhängig von Dynamic Quorum kann man jedem Clusternode NodeWeight=0 zuweisen, wenn dessen Stimme nicht zur Quorum-Bildung beitragen soll. Der File Share Witness wird nun durch die neue Cloud Witness (2016) ergänzt, welche auch mit PowerShell konfiguriert werden kann.

Wir praktizieren im Kurs den neuen Hyper-V Cluster (Full undCore) mit dem SET (Switch Embedded Teaming), der aus bis zu 8 R-NIC gebildet werden kann. Als „Compute“ oder „Hyper-Converged“ Hyper-V Cluster werden die VMs mit CPU, Memory, Netzwerk und Speicher versorgt. Die Speicherung der VHDX und Konfigurationsdaten erfolgt über SMB 3.1.1 auf einem neuen 2019 Instrastructure SOFS (Scale-Out File Server), welcher mit je 2x 10 GBit per Node auch SMB Multichannel fähig ist. Als gemeinsamer Speicher wird S2D eingesetzt, wobei jeder Clusternode mehrere lokale Festplatten für den Storage Pool mitbringt.

Die Verwaltung eines 2019 Failover Clusters wird mehr und mehr mit PowerShell durchgeführt. Wenn Core Server eingesetzt werden, kann man nur noch mit der PowerShell verwalten. Ab dem PowerShell Modul 2016 gibt es viele Neuigkeiten, z.B. der Validationstest Test-Cluster kann u.a. die Storage Spaces Direct Funktionalität eines Clusters überprüfen. PowerShell Direct arbeitet mit Named Pipe (anstelle TCP/IP) und sorgt dafür, dass die Administration der VMs direkt vom Hyper-V Host aus auch ohne Netzwerk möglich ist.