What's new in Failover Clustering (Neues beim Failoverclustering)

  • Artikel

Gilt für Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI (Version 21H2 und 20H2)

In diesem Artikel werden die neuen und geänderten Funktionen beim Failoverclustering für Azure Stack HCI, Windows Server 2019 und Windows Server 2016 erläutert.

Neuerungen in Windows Server 2019 und Azure Stack HCI

  • Clustergruppen

    (Gilt nur für Windows Server 2019) Mithilfe von Clustersets können Sie die Anzahl der Server in einer einzigen SDDC-Lösung (Software-Defined Data Center) über die aktuellen Grenzwerte eines Clusters hinaus erhöhen. Dies wird erreicht, indem mehrere Cluster in einem Clusterset zusammengefasst werden, einer lose gekoppelten Gruppierung mehrerer Failovercluster: Computecluster, Speichercluster und hyperkonvergenter Cluster. Bei Clustersets können Sie Online-VMs zwischen Clustern innerhalb des Clustersets verschieben (Livemigration).

    Weitere Informationen finden Sie unter Clustersets.

  • Azure erkennende Cluster

    Failovercluster erkennen jetzt automatisch, wann sie auf virtuellen Azure-IaaS-Computern ausgeführt werden, und optimieren die Konfiguration, um ein proaktives Failover und die Protokollierung geplanter Azure-Wartungsereignisse bereitzustellen und so die höchstmögliche Verfügbarkeit zu erzielen. Die Bereitstellung wurde zudem insofern vereinfacht, als dass der Lastenausgleich nicht mehr mit dem Namen des verteilten Netzwerks für den Clusternamen konfiguriert werden muss.

  • Domänenübergreifende Clustermigration

    Failovercluster können jetzt dynamisch von einer Active Directory-Domäne zu einer anderen wechseln, wodurch die Domänenkonsolidierung vereinfacht wird und Cluster von Hardwarepartnern erstellt und später der Domäne des Kunden hinzugefügt werden können.

  • USB-Zeugen

    Sie können jetzt ein USB-Laufwerk, das an einen Netzwerkswitch angeschlossen ist, als Zeugen bei der Bestimmung des Quorums für einen Cluster verwenden. Dadurch wird der Dateifreigabezeuge auf die Unterstützung aller SMB2-kompatiblen Geräte erweitert.

  • Verbesserungen der Clusterinfrastruktur

    Der CSV-Cache ist jetzt standardmäßig aktiviert, um die Leistung von VMs zu steigern. MSDTC unterstützt jetzt freigegebene Clustervolumes, um die Bereitstellung von MSDTC-Workloads in direkten Speicherplätzen zu ermöglichen, z. B. mit SQL Server. Die Logik wurde verbessert, um partitionierte Knoten mit Selbstreparatur zu erkennen und Knoten zur Clustermitgliedschaft zurückzugeben. Die Erkennung und Selbstreparatur von Clusternetzwerkrouten wurde verbessert.

  • Clusterfähiges Aktualisieren unterstützt „Direkte Speicherplätze“

    Clusterfähiges Aktualisieren (Cluster Aware Updating, CAU) ist jetzt integriert und erkennt direkte Speicherplätze. Dabei wird überprüft und sichergestellt, dass die Datenneusynchronisierung auf den einzelnen Knoten abgeschlossen wird. Beim clusterfähigen Aktualisieren werden Updates überprüft, um nur bei Bedarf intelligent einen Neustart durchzuführen. Dies ermöglicht das Orchestrieren der Neustarts aller Server im Cluster zur geplanten Wartung.

  • Verbesserungen für Dateifreigabezeugen

    In den folgenden Szenarien haben wir die Verwendung eines Dateifreigabezeugen ermöglicht:

    • Fehlender oder schlechter Internetzugriff aufgrund eines Remotestandorts, wodurch die Verwendung eines Cloudzeugen verhindert wird.

    • Fehlende freigegebene Laufwerke für einen Datenträgerzeugen. Hierbei kann es sich um eine hyperkonvergente Konfiguration der direkten Speicherplätze, eine SQL Server-Always-On-Verfügbarkeitsgruppe (Availability Group, AG) oder eine * Exchange Database Availability Group (DAG) handeln. Keine dieser Optionen verwendet freigegebene Datenträger.

    • Keine Domänencontrollerverbindung, weil sich der Cluster hinter einer DMZ befindet.

    • Eine Arbeitsgruppe oder ein domänenübergreifender Cluster, für die bzw. den es kein Active Directory-Clusternamensobjekt (CNO) gibt. Weitere Informationen zu diesen Verbesserungen finden Sie im folgenden Beitrag unter Server- und Verwaltungsblogs: Failovercluster Dateifreigabezeuge und DFS.

      Wir blockieren jetzt auch explizit die Verwendung einer Freigabe von DFS-Namespaces als Standort. Das Hinzufügen eines Dateifreigabezeugen zu einer DFS-Freigabe kann Stabilitätsprobleme für Ihren Cluster verursachen, und diese Konfiguration wurde nie unterstützt. Wir haben Logik hinzugefügt, um zu erkennen, ob eine Freigabe DFS-Namespaces verwendet. Wenn DFS-Namespaces erkannt werden, blockiert der Failovercluster-Manager die Erstellung des Zeugen und zeigt eine Fehlermeldung an, dass dies nicht unterstützt wird.

  • Clusterhärtung

    Die clusterinterne Kommunikation über Server Message Block (SMB) für freigegebene Clustervolumes und direkte Speicherplätze nutzt jetzt Zertifikate, um die sicherste Plattform bereitzustellen. Dadurch können Failovercluster ohne Abhängigkeiten von NTLM arbeiten und Sicherheitsbaselines aktivieren.

  • Failovercluster verwendet keine NTLM-Authentifizierung mehr

    Failovercluster verwenden keine NTLM-Authentifizierung mehr. Stattdessen wird ausschließlich die Kerberos- und zertifikatbasierte Authentifizierung verwendet. Vom Benutzer oder von den Bereitstellungstools sind keine Änderungen erforderlich, um diese Sicherheitserweiterung zu nutzen. Außerdem können Failovercluster in Umgebungen bereitgestellt werden, in denen NTLM deaktiviert wurde.

Neuigkeiten in Windows Server 2016

Paralleles Upgrade für Clusterbetriebssystem

Das parallele Upgrade für Clusterbetriebssysteme ermöglicht einem Administrator, das Betriebssystemupgrade der Clusterknotens von Windows Server 2012 R2 auf eine neuere Version durchzuführen, ohne die Hyper-V-Workloads oder die Workloads des Dateiservers mit horizontaler Skalierung zu unterbrechen. Mit diesem Feature können die Downtimesanktionen laut Vereinbarungen zum Servicelevel (Service Level Agreements, SLA) vermieden werden.

Welchen Nutzen bietet diese Änderung?

Das Upgrade eines Hyper-V-Clusters oder Clusters mit Dateiserver mit horizontaler Skalierung von Windows Server 2012 R2 auf Windows Server 2016 erfordert keine Ausfallzeit mehr. Der Cluster funktioniert weiterhin auf Windows Server 2012 R2-Ebene, bis Windows Server 2016 auf allen Knoten im Cluster ausgeführt wird. Die Clusterfunktionsebene wird mithilfe des Windows PowerShell-Cmdlets Update-ClusterFunctionalLevel auf Windows Server 2016 aktualisiert.

Warnung

  • Nachdem Sie die Clusterfunktionsebene aktualisiert haben, können Sie nicht mehr zur Windows Server 2012 R2-Clusterfunktionsebene zurückkehren.

  • Bis das Cmdlet Update-ClusterFunctionalLevel ausgeführt wird, ist der Prozess umkehrbar, und Windows Server 2012 R2-Knoten können hinzugefügt und Windows Server 2016-Knoten entfernt werden.

Worin bestehen die Unterschiede?

Das Upgrade eines Failoverclusters mit Hyper-V oder einem Dateiserver mit horizontaler Skalierung ist nun problemlos ohne Ausfallzeiten und ohne die Erstellung eines neuen Clusters mit Knoten unter dem Betriebssystem Windows Server 2016 möglich. Die Migration von Clustern zu Windows Server 2012 R2 beinhaltete das Offlineschalten des vorhandenen Clusters, das Neuinstallieren des neuen Betriebssystems für jeden Knoten sowie das erneute Onlineschalten des Clusters. Der alte Prozess war umständlich und erforderte Ausfallzeiten. Unter Windows Server 2016 muss der Cluster jedoch zu keinem Zeitpunkt offlinegeschaltet werden.

Die Clusterbetriebssysteme für das Upgrade in Phasen sind für jeden Knoten in einem Cluster wie folgt:

  • Der Knoten wird angehalten, und alle darauf ausgeführten VMs werden entladen.
  • Die VMs (oder andere Clusterworkloads) werden zu einem anderen Knoten im Cluster migriert.
  • Das vorhandene Betriebssystem wird entfernt, und es wird eine Neuinstallation des Windows Server 2016-Betriebssystems auf dem Knoten durchgeführt.
  • Der Knoten unter dem Windows Server 2016-Betriebssystem wird dem Cluster wieder hinzugefügt.
  • Zu diesem Zeitpunkt wird der Cluster im so genannten gemischten Modus ausgeführt, da die Clusterknoten entweder Windows Server 2012 R2 oder Windows Server 2016 ausführen.
  • Die Clusterfunktionsebene bleibt bei Windows Server 2012 R2. Auf dieser Funktionsebene sind neue Features in Windows Server 2016, die sich auf die Kompatibilität mit früheren Versionen des Betriebssystems auswirken, nicht verfügbar.
  • Schließlich wird für alle Knoten ein Upgrade auf Windows Server 2016 durchgeführt.
  • Die Clusterfunktionsebene wird anschließend mithilfe des Windows PowerShell-Cmdlets Update-ClusterFunctionalLevel auf Windows Server 2016 aktualisiert. Zu diesem Zeitpunkt können Sie die Features von Windows Server 2016 nutzen.

Weitere Informationen finden Sie unter Paralleles Upgrade für Clusterbetriebssysteme.

Speicherreplikat

Speicherreplikate sind ein neues Feature, das eine speicheragnostische, synchrone Replikation auf Blockebene zwischen Servern oder Clustern für die Notfallwiederherstellung ebenso ermöglicht wie das Strecken eines Failoverclusters zwischen Standorten. Die synchrone Replikation ermöglicht die Spiegelung von Daten an physischen Standorten mit ausfallsicheren Volumes, um auf Dateisystemebene sicherzustellen, dass kein Datenverlust auftritt. Die asynchrone Replikation ermöglicht die Standorterweiterung über regionale Bereiche hinaus mit der Möglichkeit von Datenverlusten.

Welchen Nutzen bietet diese Änderung?

Mithilfe von Speicherreplikaten ist Folgendes möglich:

  • Bereitstellen einer Notfallwiederherstellungslösung von einem einzigen Anbieter für geplante und ungeplante Ausfälle unternehmenskritischer Workloads.

  • Verwenden des SMB3-Transportprotokolls mit bewährter Zuverlässigkeit, Skalierbarkeit und Leistung.

  • Strecken von Windows-Failoverclustern über regionale Bereiche hinweg.

  • Einsatz von Microsoft-Software für die gesamte Speicher- und Clusterumgebung. Dazu zählen Hyper-V, Speicherreplikate, Speicherplätze, Cluster, Dateiserver mit horizontaler Skalierung, SMB3, Datendeduplizierung und ReFS/NTFS.

  • Aufgrund der folgenden Merkmale können Sie die Kosten und die Komplexität senken:

    • Hardwareagnostisches System, das keine spezifische Speicherkonfiguration wie DAS oder SAN benötigt.

    • Möglichkeit, allgemeine Speicher- und Netzwerktechnologien zu nutzen.

    • Problemlose grafische Verwaltung für einzelne Knoten und Cluster über den Failovercluster-Manager.

    • Umfangreiche Skriptoptionen über Windows PowerShell.

  • Weniger Downtime sowie höhere Zuverlässigkeit und Produktivität dank Windows.

  • Unterstützbarkeit, Leistungsmetriken und Diagnosefunktionen.

Weitere Informationen finden Sie unter Speicherreplikate in Windows Server 2016.

Cloudzeuge

Der Cloudzeuge ist ein neuer Failovercluster-Quorumzeugen-Typ in Windows Server 2016, der Microsoft Azure als Vermittlungspunkt nutzt. Der Cloudzeuge erhält wie jeder andere Quorumzeuge ein Votum und kann an der Quorumberechnung teilnehmen. Sie können den Cloudzeugen als Quorumzeugen konfigurieren, indem Sie den Assistenten zum Konfigurieren eines Clusterquorums verwenden.

Welchen Nutzen bietet diese Änderung?

Der Einsatz eines Cloudzeugen als Failoverclusterquorum-Zeuge bietet die folgenden Vorteile:

  • Microsoft Azure wird genutzt, und die Notwendigkeit eines dritten separaten Rechenzentrums entfällt.

  • Die öffentlich verfügbare Standardinstanz von Microsoft Azure Blob Storage wird verwendet. Damit entfällt der zusätzliche Wartungsaufwand für VMs, die in einer öffentlichen Cloud gehostet werden.

  • Dasselbe Microsoft Azure Storage-Konto kann für mehrere Cluster verwendet werden (eine Blobdatei pro Cluster; eindeutige Cluster-ID, die als Blobdateiname verwendet wird).

  • Die laufenden Kosten für das Storage-Konto sind sehr niedrig (pro Blobdatei werden sehr geringe Datenmengen geschrieben, die Blobdatei wird nur einmal aktualisiert, wenn sich der Status der Clusterknoten ändert).

Weitere Informationen finden Sie unter Bereitstellen eines Cloudzeugen für einen Failovercluster.

Worin bestehen die Unterschiede?

Dies ist eine neue Funktion in Windows Server 2016.

Resilienz von VMs

Computeresilienz Windows Server 2016 bietet eine erhöhte VM-Computeresilienz, um Probleme bei der Kommunikation innerhalb des Clusters in Ihrem Computecluster wie folgt zu reduzieren:

  • Für VMs verfügbare Resilienzoptionen: Sie können jetzt VM-Resilienzoptionen konfigurieren, die das Verhalten der VMs bei vorübergehenden Fehlern definieren:

    • Resilienzebene: Hiermit können Sie definieren, wie die vorübergehenden Fehler behandelt werden.

    • Resilienzzeitraum: Hiermit können Sie definieren, wie lange alle VMs isoliert ausgeführt werden dürfen.

  • Quarantäne fehlerhafter Knoten: Fehlerhafte Knoten werden unter Quarantäne gestellt und dürfen nicht mehr in den Cluster aufgenommen werden. Dadurch wird verhindert, dass sich fluktuierende Knoten negativ auf andere Knoten und den gesamten Cluster auswirken.

Weitere Informationen zum Computeresilienzworkflow für VMs und zu Knotenquarantäneeinstellungen, die steuern, wie Ihr Knoten isoliert oder unter Quarantäne gestellt wird, finden Sie unter Computeresilienz für VMs unter Windows Server 2016.

Speicherresilienz Unter Windows Server 2016 sind VMs resilienter gegenüber vorübergehenden Speicherfehlern. Die verbesserte VM-Resilienz trägt dazu bei, die Sitzungszustände virtueller Mandantencomputer im Falle einer Speicherunterbrechung beizubehalten. Dies wird durch intelligente und schnelle Reaktionen virtueller Computer auf Speicherinfrastrukturprobleme erreicht.

Wenn eine VM die Verbindung mit dem zugrunde liegenden Speicher trennt, wird sie angehalten und wartet auf die Wiederherstellung des Speichers. Solange sie angehalten ist, behält die VM den Kontext der Anwendungen bei, die darin ausgeführt werden. Wenn die Verbindung der VM mit ihrem Speicher wiederhergestellt wird, kehrt die VM zum Ausführungszustand zurück. Infolgedessen bleibt der Sitzungsstatus des Mandantencomputers bei der Wiederherstellung erhalten.

Unter Windows Server 2016 ist die VM-Speicherresilienz auch für Gastcluster verfügbar und optimiert.

Diagnoseverbesserungen beim Failoverclustering

Um Probleme mit Failoverclustern zu diagnostizieren, ist in Windows Server 2016 Folgendes enthalten:

Standortabhängige Failovercluster

Windows Server 2016 umfasst standortfähige Failovercluster, die Gruppenknoten in Stretched Clusters basierend auf ihrem physischen Standort aktivieren. Dass Cluster standortspezifisch sind, verbessert wesentliche Vorgänge während des Clusterlebenszyklus, z. B. Failoververhalten, Platzierungsrichtlinien, Heartbeat zwischen den Knoten und Quorumverhalten. Weitere Informationen finden Sie unter Standortspezifische Failovercluster unter Windows Server 2016.

Arbeitsgruppencluster und Cluster mit mehreren Domänen

Unter Windows Server 2012 R2 und früheren Versionen kann ein Cluster nur zwischen Mitgliedsknoten erstellt werden, die in dieselbe Domäne eingebunden sind. Windows Server 2016 beseitigt diese Hindernisse und führt die Möglichkeit zum Erstellen eines Failoverclusters ohne Active Directory-Abhängigkeiten ein. Sie können jetzt Failovercluster in den folgenden Konfigurationen erstellen:

  • Cluster mit einer einzigen Domäne. Cluster, bei denen alle Knoten in dieselbe Domäne eingebunden sind.

  • Cluster mit mehreren Domänen. Cluster mit Knoten, die verschiedenen Domänen angehören.

  • Arbeitsgruppencluster. Cluster mit Knoten, bei denen es sich um Mitgliedsserver/Arbeitsgruppen handelt (nicht in die Domäne eingebunden).

Weitere Informationen finden Sie unter Arbeitsgruppencluster und Cluster mit mehreren Domänen unter Windows Server 2016.

VM-Lastenausgleich

Der VM-Lastenausgleich ist ein neues Feature im Failoverclustering, das den nahtlosen Lastenausgleich virtueller Computer über die Knoten in einem Cluster erleichtert. Knoten mit übermäßiger Belastung werden basierend auf der Arbeitsspeicher- und CPU-Auslastung der VM auf dem Knoten identifiziert. VMs werden dann von einem übermäßig ausgelasteten Knoten auf Knoten mit verfügbarer Bandbreite (falls verfügbar) verschoben (Livemigration). Die Aggressivität des Ausgleichs kann optimiert werden, um eine optimale Clusterleistung und -auslastung zu gewährleisten. Der Lastenausgleich ist in Windows Server 2016 Technical Preview standardmäßig aktiviert. Der Lastenausgleich ist jedoch deaktiviert, wenn die dynamische SCVMM-Optimierung aktiviert ist.

VM-Startreihenfolge

Die VM-Startreihenfolge ist ein neues Feature beim Failoverclustering, das die Orchestrierung der Startreihenfolge für VMs (und alle Gruppen) in einem Cluster einführt. VMs können jetzt in Ebenen gruppiert werden, und zwischen den verschiedenen Ebenen lassen sich Abhängigkeiten für die Startreihenfolge erstellen. Dadurch wird sichergestellt, dass die wichtigsten VMs (z. B. Domänencontroller oder Hilfsprogramm-VMs) zuerst gestartet werden. VMs werden erst gestartet, wenn die VMs, von denen sie abhängig sind, ebenfalls gestartet werden.

Vereinfachte SMB Multichannel- und Multi-NIC-Clusternetzwerke

Failoverclusternetzwerke sind nicht mehr auf einen einzigen Netzwerkadapter pro Subnetz/Netzwerk beschränkt. Mit vereinfachten SMB Multichannel- und Multi-NIC-Clusternetzwerken erfolgt die Netzwerkkonfiguration automatisch, und jeder Netzwerkadapter im Subnetz kann für Cluster- und Workloaddatenverkehr verwendet werden. Mit dieser Verbesserung können Kunden den Netzwerkdurchsatz für Hyper-V, SQL Server-Failoverclusterinstanz und andere SMB-Workloads maximieren.

Weitere Informationen finden Sie unter Vereinfachte SMB Multichannel- und Multi-NIC-Clusternetzwerke.

Weitere Informationen