Paralleles Upgrade für Clusterbetriebssystem

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016

Das parallele Upgrade für Clusterbetriebssysteme ermöglicht es einem Administrator, das Betriebssystem von Clusterknotens zu aktualisieren, ohne Hyper-V-Workloads oder Workloads des Dateiservers mit horizontaler Skalierung stoppen zu müssen. Mit diesem Feature können die Downtimesanktionen laut Vereinbarungen zum Servicelevel (Service Level Agreements, SLA) vermieden werden.

Das parallele Upgrade für Clusterbetriebssysteme bietet die folgenden Vorteile:

• Für Failovercluster, die Hyper-V-VM und Server mit horizontaler Skalierung ausführen, kann ein Upgrade von einer Version von Windows Server ab Windows Server 2012 R2 auf eine neuere Version von Windows Server vorgenommen werden. Sie können z. B. Windows Server 2016 (das auf allen Clusterknoten des Clusters ausgeführt wird) ohne Ausfallzeit auf Windows Server 2019 (das auf allen Knoten im Cluster ausgeführt wird) aktualisieren.

• Zusätzliche Hardware ist nicht erforderlich. In kleinen Clustern können Sie vorübergehend zusätzliche Clusterknoten hinzufügen, um die Verfügbarkeit des Clusters während des parallelen Upgrades für Clusterbetriebssysteme zu verbessern.

• Der Cluster muss nicht angehalten oder neu gestartet werden.

• Ein neuer Cluster ist nicht erforderlich. Der vorhandene Cluster wird aktualisiert. Zusätzlich werden vorhandene Clusterobjekte verwendet, die in Active Directory gespeichert sind.

• Das Upgrade lässt sich bis zum letzten Schritt rückgängig machen, bei dem alle Clusterknoten die neuere Version von Windows Server ausführen und das PowerShell-cmdlet Update-ClusterFunctionalLevel ausgeführt wird.

• Der Cluster unterstützt Patching- und Wartungsvorgänge, während er im gemischten OS-Modus ausgeführt wird.

• Die Automatisierung über PowerShell und WMI wird unterstützt.

• Die öffentliche Clustereigenschaft ClusterFunctionalLevel gibt den Status des Clusters auf Clusterknoten mit Windows Server 2016 und höher an. Diese Eigenschaft kann mit dem PowerShell-cmdlet von einem Clusterknoten abgefragt werden, der zu einem Failovercluster gehört:

  Get-Cluster | Select ClusterFunctionalLevel
  

  Die folgende Tabelle zeigt die Werte und die entsprechende Funktionsebene:

  Wert	Funktionsebene
  8	Windows Server 2012 R2
  9	Windows Server 2016
  10	Windows Server 2019

In dieser Anleitung werden die einzelnen Phasen des parallelen Upgrades für Clusterbetriebssysteme, die einzelnen Schritte der Installation und die Funktionsbeschränkungen beschrieben. Außerdem enthält sie häufig gestellte Fragen. Dieser Leitfaden gilt für die folgenden Szenarien des parallelen Upgrades für Clusterbetriebssysteme bei Windows Server:

• Hyper-V-Cluster
• Dateiserver-Cluster mit horizontaler Skalierung

Das folgende Szenario wird nicht unterstützt:

• Paralleles Upgrade für Clusterbetriebssysteme mit einer virtuellen Festplatte (.vhdx-Datei) als freigegebener Speicher.

Das parallele Upgrade für Clusterbetriebssysteme wird vom System Center Virtual Machine Manager (SCVMM) vollständig unterstützt. Wenn Sie SCVMM verwenden, finden Sie unter Ausführen eines parallelen Upgrades eines Hyper-V-Host-Clusters auf Windows Server 2016 in VMM eine Anleitung zum Upgrade der Cluster und zur Automatisierung der in diesem Dokument beschriebenen Schritte.

Requirements (Anforderungen)

Die folgenden Voraussetzungen müssen erfüllt sein, bevor Sie mit dem parallelen Upgrade für Clusterbetriebssysteme beginnen:

• Beginnen Sie mit einem Failovercluster, auf dem Windows Server 2012 R2 oder neuer ausgeführt wird. Sie können ein Upgrade auf die nächste Version durchführen, also z. B. von Windows Server 2016 auf Windows Server 2019.
• Überprüfen Sie mit einer der folgenden Methoden, ob die CPUs der Hyper-V-Knoten SLAT (Second-Level Addressing Table) unterstützen. – Lesen Sie den Artikel Are you SLAT Compatible? WP8 SDK Tip 01, in dem zwei Methoden erklärt werden, mit denen Sie prüfen können, ob eine CPU SLAT-fähig ist. – Laden Sie das Tool Coreinfo v3.31 herunter, um zu ermitteln, ob eine CPU SLAT unterstützt.

Cluster-Übergangsstatus beim parallelen Upgrade für Clusterbetriebssysteme

In diesem Abschnitt werden die einzelnen Übergangsstatus des Windows Server-Clusters beschrieben, der mit dem parallelen Upgrade für Clusterbetriebssysteme auf die nächste Version von Windows Server aktualisiert wird.

Damit die Cluster-Workloads auch während des parallelen Upgrades für Clusterbetriebssysteme ausgeführt werden, können Sie mit dem Kompatibilitätsmodus einen Cluster-Workload von einem Knoten mit einer älteren Version von Windows Server auf einen Knoten mit einer neueren Version von Windows Server verschieben. Dieser Kompatibilitätsmodus lässt die Knoten, auf denen die neuere Version von Windows Server ausgeführt wird, so erscheinen, als würden sie dieselbe ältere Version von Windows Server ausführen. Wenn Sie z. B. einen Windows Server 2016-Cluster auf Windows Server 2019 aktualisieren, laufen die Windows Server 2019-Knoten vorübergehend in einem Windows Server 2016-Kompatibilitätsmodus. Ein neuer konzeptioneller Clustermodus, der gemischte OS-Modus, macht es möglich, dass Knoten mit unterschiedlichen Versionen im selben Cluster vorhanden sein können (siehe Abbildung 1).

Abbildung 1: Übergangsstatus der Clusterbetriebssysteme

Ein Windows Server-Cluster wird in den gemischten OS-Modus versetzt, wenn ein Knoten mit einer neueren Version von Windows Server zum Cluster hinzugefügt wird. Zu diesem Zeitpunkt lässt sich der Vorgang noch vollständig rückgängig machen: Neuere Windows Server-Knoten können in diesem Modus aus dem Cluster entfernt und Knoten mit der vorhandenen Version von Windows Server zum Cluster hinzugefügt werden. Dieser Vorgang lässt sich nicht mehr rückgängig machen, sobald das PowerShell-cmdlet Update-ClusterFunctionalLevel auf dem Cluster ausgeführt wurde. Damit dieses cmdlet erfolgreich ausgeführt werden kann, müssen alle Knoten die neuere Version von Windows Server ausführen und online sein.

Übergangsstatus eines Clusters mit vier Knoten während eines parallelen Upgrades für Clusterbetriebssysteme

Dieser Abschnitt illustriert und beschreibt die vier verschiedenen Phasen eines Clusters mit freigegebenem Speicher, dessen Knoten von Windows Server 2012 R2 auf Windows Server 2016 aktualisiert werden. Der Prozess läuft bei späteren Versionen von Windows Server identisch ab.

„Phase 1“ ist der Anfangszustand: Wir beginnen mit einem Cluster mit Windows Server 2012 R2.

Abbildung 2: Anfangszustand: Failovercluster mit Windows Server 2012 R2 (Phase 1)

In „Phase 2“ wurden zwei Knoten angehalten, ausgeglichen, entfernt und neu formatiert. Auf ihnen wurde Windows Server 2016 installiert.

Abbildung 3: gemischter OS-Modus: Failovercluster mit Windows Server 2012 R2 und Windows Server 2016 (Phase 2)

In „Phase 3“ wurden alle Knoten im Cluster auf Windows Server 2016 aktualisiert, und der Cluster ist für das Upgrade mit dem PowerShell-cmdlet Update-ClusterFunctionalLevel bereit.

Hinweis

Zu diesem Zeitpunkt kann der Vorgang vollständig rückgängig gemacht werden und Windows Server 2012 R2-Knoten können zum Cluster hinzugefügt werden.

Abbildung 4: Zwischenstatus: Alle Knoten wurden auf Windows Server 2016 aktualisiert und sind bereit für Update-ClusterFunctionalLevel (Phase 3)

Nach der Ausführung des cmdlets Update-ClusterFunctionalLevel befindet sich der Cluster in „Phase 4“, in der die neuen Windows Server 2016-Clusterfunktionen genutzt werden können.

Abbildung 5: endgültiger Status: Windows Server 2016-Failover-Cluster (Phase 4)

Prozess des parallelen Upgrades für Clusterbetriebssysteme

In diesem Bereich wird der Workflow für die Durchführung des parallelen Upgrades für Clusterbetriebssysteme beschrieben.

Abbildung 6: Prozess des parallelen Upgrades für Clusterbetriebssysteme

Das parallele Upgrade für Clusterbetriebssysteme umfasst die nachfolgenden Schritte für das Upgrade von Windows Server 2012 R2 auf Windows Server 2016. Der Prozess ist für spätere Versionen von Windows Server identisch.

1. So bereiten Sie den Cluster auf das Betriebssystemupgrade vor:

   1. Das parallele Upgrade für Clusterbetriebssysteme erfordert, dass ein Knoten nach dem anderen aus dem Cluster entfernt wird. Überprüfen Sie, ob der Cluster ausreichend Kapazitäten bietet, damit die Hochverfügbarkeits-SLA eingehalten werden, wenn einer der Clusterknoten beim Betriebssystemupgrade aus dem Cluster entfernt wird. Anders gesagt: Benötigen Sie die Fähigkeit, Workload-Failover auf einen anderen Knoten durchzuführen, wenn ein Knoten beim parallelen Upgrade für Clusterbetriebssysteme aus dem Cluster entfernt wird? Hat der Cluster die Kapazität, um die benötigten Workloads auszuführen, wenn ein Knoten beim parallelen Upgrade für Clusterbetriebssysteme aus dem Cluster entfernt wird?

   2. Überprüfen Sie bei Hyper-V-Workloads, ob alle Hyper-V-Hosts mit Windows Server CPU-Unterstützung für SLAT bieten. Nur SLAT-fähige Rechner können bei Windows Server 2016 und höher die Hyper-V-Rolle verwenden.

   3. Vergewissern Sie sich, dass die Sicherung von allen Workloads abgeschlossen ist. Möglicherweise sollten Sie auch den Cluster sichern. Halten Sie die Sicherungsvorgänge an, während Sie Knoten zum Cluster hinzufügen.

   4. Überprüfen Sie mit dem cmdlet Get-ClusterNode (siehe Abbildung 7), ob alle Clusterknoten online und erreichbar sind und laufen.

      Abbildung 7: Ermittlung des Knotenstatus mit dem cmdlet Get-ClusterNode

   5. Wenn Sie eine clusterfähige Aktualisierung (CAU) durchführen, können Sie über die Benutzeroberfläche des clusterfähigen Aktualisierens oder mit dem cmdlet Get-CauRun überprüfen, ob CAU gerade ausgeführt wird (siehe Abbildung 8). Beenden Sie CAU mit dem cmdlet Disable-CauClusterRole (siehe Abbildung 9), um zu verhindern, dass Knoten beim parallelen Upgrade für Clusterbetriebssysteme vom CAU angehalten und ausgeglichen werden.

      Abbildung 8: Nutzung des cmdlets Get-CauRun, um zu prüfen, ob CAU gerade auf dem Cluster ausgeführt wird

      Abbildung 9: Deaktivieren der CAU-Rolle mit dem cmdlet Disable-CauClusterRole

2. Führen Sie für jeden Knoten im Cluster Folgendes durch:

   1. Wählen Sie in der Cluster-Manager-Benutzeroberfläche einen Knoten aus. Gleichen Sie ihn mit der Menüoption Anhalten | Ausgleichen (siehe Abbildung 10) oder mit dem cmdlet Suspend-ClusterNode (siehe Abbildung 11) aus.

      Abbildung 10: Ausgleichen von Rollen eines Knotens mit dem Failovercluster-Manager

      Abbildung 11: Ausgleichen von Rollen eines Knotens mit dem cmdlet Suspend-ClusterNode

   2. Entfernen Sie über die Cluster-Manager-Benutzeroberfläche den angehaltenen Knoten aus dem Cluster. Sie können dazu auch das cmdlet Remove-ClusterNode verwenden.

      Abbildung 12: Entfernen eines Knotens aus dem Cluster mit dem cmdlet Remove-ClusterNode

   3. Formatieren Sie das Systemlaufwerk, und führen Sie auf dem Knoten eine Neuinstallation von Windows Server 2016 mit der Installationsoption Benutzerdefiniert: nur Windows installieren (für fortgeschrittene Benutzer) der Installationsdatei setup.exe durch (siehe Abbildung 13). Vermeiden Sie es, die Option Upgrade: Windows installieren und Dateien, Einstellungen und Anwendungen behalten auszuwählen, da das parallele Upgrade für Clusterbetriebssysteme kein direktes Upgrade unterstützt.

      Abbildung 13: Verfügbare Installationsoptionen für Windows Server 2016

   4. Fügen Sie den Knoten zur richtigen Active Directory-Domäne hinzu.

   5. Fügen Sie die richtigen Benutzer zur Gruppe „Administratoren“ hinzu.

   6. Installieren Sie über die Server-Manager-Benutzeroberfläche oder mit dem PowerShell-cmdlet WindowsFeature alle benötigten Serverrollen, z. B. Hyper-V.

      Install-WindowsFeature -Name Hyper-V
      

   7. Installieren Sie über die Server-Manager-Benutzeroberfläche oder mit dem PowerShell-cmdlet WindowsFeature die Failoverclustering-Funktion.

      Install-WindowsFeature -Name Failover-Clustering
      

   8. Installieren Sie zusätzliche Funktionen, die Ihre Cluster-Workloads benötigen.

   9. Überprüfen Sie über die Failovercluster-Manager-Benutzeroberfläche die Einstellungen für die Netzwerk- und Speicherkonnektivität.

   10. Wenn Sie die Windows-Firewall verwenden, überprüfen Sie, ob die Firewalleinstellungen für den Cluster korrekt sind. Bei Clustern, für die das clusterfähige Aktualisieren aktiviert ist, ist möglicherweise eine Konfiguration der Firewall erforderlich.

   11. Starten Sie für Hyper-V-Workloads über die Hyper-V-Manager-Benutzeroberfläche das Dialogfeld „Virtueller Switch-Manager“ (siehe Abbildung 14).

       Überprüfen Sie, ob die verwendeten Namen der virtuellen Switches bei allen Hyper-V-Hostknoten im Cluster identisch sind.

       Abbildung 14: Virtueller Switch-Manager

   12. Für Windows Server 2016-Knoten (Knoten mit Windows Server 2012 R2 sollten Sie nicht verwenden) stellen Sie mit dem Failovercluster-Manager (siehe Abbildung 15) die Verbindung mit dem Cluster her.

       Abbildung 15: Hinzufügen eines Knotens zum Cluster mit dem Failovercluster-Manager

   13. Fügen Sie den Knoten entweder über die Failovercluster-Manager-Benutzeroberfläche oder mit dem cmdlet Add-ClusterNode (siehe Abbildung 16) zum Cluster hinzu.

       Abbildung 16: Hinzufügen eines Knotens zum Cluster mit dem cmdlet Add-ClusterNode

       Hinweis

       Wenn der erste Windows Server 2016-Knoten dem Cluster beitritt, wird der Cluster in den gemischten OS-Modus versetzt und die Hauptressourcen des Clusters werden auf den Windows Server 2016-Knoten verschoben. Ein Cluster im gemischten OS-Modus ist ein voll funktionsfähiger Cluster, dessen Knoten in einem Kompatibilitätsmodus mit den alten Knoten laufen. Der gemischte OS-Modus ist ein Übergangsmodus für den Cluster. Er ist nicht für die dauerhafte Nutzung ausgelegt, und es wird erwartet, dass Kunden alle Knoten ihres Clusters innerhalb von vier Wochen aktualisieren.

   14. Wenn Sie den Windows Server 2016-Knoten erfolgreich zum Cluster hinzugefügt haben, können Sie (optional) einen Teil des Cluster-Workloads zum neu hinzugefügten Knoten verschieben, um den Workload wieder gleichmäßig im Cluster zu verteilen. Gehen Sie dazu wie folgt vor:

       Abbildung 17: Verschieben eines Cluster-Workloads (Cluster-VM-Rolle) mit dem cmdlet Move-ClusterVirtualMachineRole

       1. Führen Sie die Livemigration der virtuellen Computer mit der Option Livemigration des Failovercluster-Managers oder mit dem cmdlet Move-ClusterVirtualMachineRole (siehe Abbildung 17) durch.

          Move-ClusterVirtualMachineRole -Name VM1 -Node robhind-host3
          

       2. Verwenden Sie die Option Verschieben des Failovercluster-Managers oder das cmdlet Move-ClusterGroup für andere Clusterworkloads.

3. Wenn alle Knoten auf Windows Server 2016 aktualisiert und wieder zum Cluster hinzugefügt wurden oder wenn alle verbleibenden Windows Server 2012 R2-Knoten entfernt wurden, machen Sie Folgendes:

   Wichtig

   • Wenn Sie die Funktionsebene des Clusters aktualisiert haben, können Sie nicht mehr zur Windows Server 2012 R2-Funktionsebene zurückkehren und keine Windows Server 2012 R2-Knoten mehr zum Cluster hinzufügen.
   • Bis zur Ausführung des cmdlets Update-ClusterFunctionalLevel lässt sich der Vorgang vollständig rückgängig machen, Sie können weiterhin Windows Server 2012 R2-Knoten zu diesem Cluster hinzufügen und Windows Server 2016-Knoten entfernen.
   • Einige Clustervorgänge, z. B. der Knotenausgleich, können dazu führen, dass ein Knoten für kurze Zeit isoliert wird. Dazu kann es kommen, wenn der Vorgang Update-ClusterFunctionalLevel noch nicht ausgeführt wurde.
   • Nach dem Ausführen des cmdlets Update-ClusterFunctionalLevel sind die neuen Funktionen verfügbar.

   1. Überprüfen Sie über die Failovercluster-Manager-Benutzeroberfläche oder mit dem cmdlet Get-ClusterGroup, ob alle Clusterrollen im Cluster wie erwartet ausgeführt werden. Im folgenden Beispiel wird der verfügbare Speicher nicht verwendet, stattdessen wird CSV verwendet. Dementsprechend wird für „Verfügbarer Speicher“ der Status Offline angezeigt (siehe Abbildung 18).

      Abbildung 18: Mit dem cmdlet Get-ClusterGroup überprüfen, dass alle Clustergruppen (Clusterrollen) laufen

   2. Überprüfen Sie mit dem cmdlet Get-ClusterNode, ob alle Clusterknoten online sind und ausgeführt werden.

   3. Führen Sie das cmdlet Update-ClusterFunctionalLevel aus. Es sollte keine Fehlermeldungen zurückgeben (siehe Abbildung 19).

      Abbildung 19: Aktualisieren der Funktionsebene eines Clusters über die PowerShell

   4. Nach dem Ausführen des cmdlets Update-ClusterFunctionalLevel sind die neuen Funktionen verfügbar.

4. Setzen Sie die normalen Clusterupdates und -sicherungen wieder fort:

   1. Wenn Sie zuvor CAU ausgeführt haben, starten Sie die Funktion über die CAU-Benutzeroberfläche oder mit dem cmdlet Enable-CauClusterRole (siehe Abbildung 20) neu.

      Abbildung 20: Aktivieren der CAU-Rolle mit dem cmdlet Enable-CauClusterRole

   2. Setzen Sie die Sicherungsvorgänge fort.

5. Aktivieren und verwenden Sie die Windows Server 2016-Funktionen auf virtuellen Hyper-V-Computern.

   1. Nachdem der Cluster auf die Windows Server 2016-Funktionsebene aktualisiert wurde, stehen für viele Workloads wie Hyper-V-VMs neue Funktionen zur Verfügung. Eine Liste der neuen Hyper-V-Funktionen finden Sie unter Migrieren und Aktualisieren virtueller Computer.

   2. Zeigen Sie auf jedem Hyper-V-Hostknoten im Cluster mit dem cmdlet Get-VMHostSupportedVersion die Hyper-V-VM-Konfigurationsversionen an, die vom Host unterstützt werden.

      Abbildung 21: Anzeigen der Hyper-V-VM-Konfigurationsversionen, die vom Host unterstützt werden

   3. Sie können auf jedem Hyper-V-Hostknoten im Cluster die Hyper-V-VM-Konfigurationsversionen aktualisieren. Planen Sie dazu mit den Benutzern ein kurzes Wartungsfenster ein, nehmen Sie eine Sicherung vor, schalten Sie alle virtuellen Computer ab, und führen Sie das cmdlet Update-VMVersion (siehe Abbildung 22) aus. Dieser Vorgang aktualisiert die Version des virtuellen Computers und aktiviert die neuen Hyper-V-Funktionen, wodurch zukünftige Hyper-V-Integrationskomponenten-Updates nicht mehr nötig sind. Sie können dieses cmdlet auf dem Hyper-V-Knoten ausführen, das die VM hostet, oder mit dem Parameter -ComputerName die VM-Version remote aktualisieren. In diesem Beispiel aktualisieren wir die Konfigurationsversion von VM1 von 5.0 auf 7.0, damit wir die vielen neuen Hyper-V-Funktionen dieser VM-Konfigurationsversion nutzen können. Dazu gehören beispielsweise Produktionsprüfpunkte (anwendungskonsistente Sicherungen) und eine binäre VM-Konfigurationsdatei.

      Abbildung 22: Aktualisieren der VM-Version mit dem PowerShell-cmdlet Update-VMVersion

6. Speicherpools können Sie mit dem PowerShell-cmdlet Update-StoragePool aktualisieren – dies ist ein Online-Vorgang.

Obwohl wir auf Private-Cloud-Szenarien, insbesondere auf Hyper-V- und Dateiserver-Cluster mit horizontaler Skalierung, ausgerichtet sind, die ohne Ausfallzeiten aktualisiert werden können, lässt sich das parallele Upgrade für Clusterbetriebssysteme bei allen Clusterrollen verwenden.

Einschränkungen

• Diese Funktion funktioniert nur bei Windows Server-Versionen ab Windows Server 2012 R2. Frühere Versionen von Windows Server wie Windows Server 2008, Windows Server 2008 R2 oder Windows Server 2012 können mit dieser Funktion nicht aktualisiert werden.
• Jeder Windows Server 2016-Knoten sollte nur neu formatiert/neu installiert werden. Von den Installationsarten Direkt und Upgrade wird abgeraten.
• Um die neuen Knoten zum Cluster hinzuzufügen, müssen Sie einen Knoten mit der neueren Version von Windows Server verwenden.
• Wenn Sie einen Cluster im gemischten OS-Modus verwalten, führen Sie die Verwaltungsaufgaben immer auf einem Knoten der höheren Ebene mit Windows Server 2016 aus. Auf Windows Server-Knoten der unteren Ebenen können Sie die Benutzeroberfläche und die Verwaltungstools nicht für neuere Version von Windows Server verwenden.
• Wir empfehlen Kunden, den Cluster-Upgradeprozess möglichst schnell abzuschließen, da manche Clusterfunktionen nicht für den gemischten OS-Modus optimiert sind.
• Wegen möglicher Inkompatibilitäten beim Failover von einem neueren Windows Server-Knoten auf Windows Server-Knoten der unteren Ebenen sollten Sie es vermeiden, auf neueren Windows Server-Knoten Speicher zu erstellen oder die Speichergröße zu ändern, solange der Cluster im gemischten OS-Modus ausgeführt wird.

Häufig gestellte Fragen

Wie lange kann der Failovercluster im gemischten OS-Modus ausgeführt werden? Wir empfehlen Kunden, das Upgrade innerhalb von vier Wochen abzuschließen. Wir haben die Hyper-V-Server-Cluster und die Dateiserver-Cluster mit horizontaler Skalierung erfolgreich ohne Ausfallzeit in nicht einmal vier Stunden aktualisiert.

Ist es geplant, diese Funktion auf Windows Server 2012, Windows Server 2008 R2 oder Windows Server 2008 zu übertragen? Wir haben nicht vor, diese Funktion auf die früheren Versionen zu übertragen. Das parallele Upgrade für Clusterbetriebssysteme ist unsere Vision für das Upgrade von Windows Server-Clustern.

Ist es erforderlich, dass auf den Knoten, die eine ältere Windows Server-Version ausführen, alle Softwareupdates installiert sind, bevor Sie das parallele Upgrade für Clusterbetriebssysteme starten? Ja. Bevor Sie das parallele Upgrade für Clusterbetriebssysteme starten, müssen Sie sicherstellen, dass auf allen Clusterknoten die neuesten Softwareupdates installiert sind.

Kann ich das cmdlet Update-ClusterFunctionalLevel ausführen, während die Knoten deaktiviert oder angehalten sind? Nein. Alle Clusterknoten müssen aktiviert und aktiv sein, damit das cmdlet Update-ClusterFunctionalLevel funktioniert.

Funktioniert das parallele Upgrade für Clusterbetriebssysteme bei allen Cluster-Workloads? Funktioniert es bei SQL Server? Ja, das parallele Upgrade für Clusterbetriebssysteme funktioniert bei allen Cluster-Workloads. Bei Hyper-V-Server-Clustern und Dateiserver-Clustern mit horizontaler Skalierung gab es jedoch gar keine Ausfallzeit. Bei den meisten anderen Workloads tritt beim Failover ein kurzer Ausfall auf (in der Regel wenige Minuten). Ein Failover ist beim parallelen Upgrade für Clusterbetriebssysteme mindestens einmal erforderlich.

Kann ich diesen Vorgang mit PowerShell automatisieren? Ja, wir haben das parallele Upgrade für Clusterbetriebssysteme so entwickelt, dass es mit der PowerShell automatisiert werden kann.

Kann ich bei großen Clustern mit zusätzlicher Failoverkapazität mehrere Knoten gleichzeitig aktualisieren? Ja. Wenn ein Knoten für die Aktualisierung des Betriebssystems aus dem Cluster entfernt wird, steht dem Cluster ein Knoten weniger für das Failover zur Verfügung – die Failoverkapazität des Clusters ist also reduziert. Bei großen Clustern mit ausreichend Workload- und Failoverkapazität können Sie mehrere Knoten gleichzeitig aktualisieren. Sie können vorübergehend Clusterknoten zum Cluster hinzufügen, um die Workload- und Failover-Kapazität während des parallelen Upgrades für Clusterbetriebssysteme zu verbessern.

Was soll ich tun, wenn ich nach der erfolgreichen Ausführung von Update-ClusterFunctionalLevel ein Problem in meinem Cluster feststelle? Wenn Sie vor der Ausführung von Update-ClusterFunctionalLevel die Clusterdatenbank mit einer Systemstatussicherung gesichert haben, sollten Sie auf einem Knoten mit der vorherigen Version von Windows Server eine autorisierende Wiederherstellung vornehmen können, die die ursprüngliche Clusterdatenbank und -konfiguration wiederherstellt.

Kann ich statt der Neuinstallation des Betriebssystems das direkte Upgrade für jeden Knoten durchführen, bevor ich das Systemlaufwerk neu formatiere? Das direkte Upgrade von Windows Server empfehlen wir nicht, aber uns ist bekannt, dass es in manchen Fällen funktioniert, wenn die Standardtreiber verwendet werden. Lesen Sie sich alle Warnhinweise sorgfältig durch, die während des direkten Upgrades eines Clusterknotens angezeigt werden.

Wenn ich die Hyper-V-Replikation für eine Hyper-V-VM auf meinem Hyper-V-Cluster verwende, bleibt die Replikation während des parallelen Upgrades für Clusterbetriebssysteme und anschließend intakt? Ja, das Hyper-V-Replikat bleibt während des parallelen Upgrades für Clusterbetriebssysteme und anschließend intakt.

Kann ich mit dem System Center Virtual Machine Manager (SCVMM) das parallele Upgrade für Clusterbetriebssysteme automatisieren? Ja, Sie können das parallele Upgrade für Clusterbetriebssysteme mit VMM im System Center automatisieren.