Aggiornamento in sequenza del sistema operativo del cluster

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

L'aggiornamento in sequenza del sistema operativo del cluster consente a un amministratore di aggiornare il sistema operativo dei nodi del cluster Hyper-V o Scale-Out carichi di lavoro file server senza arrestarli. Usando questa funzionalità, è possibile evitare le sanzioni per il tempo di inattività previste dai contratti di servizio.

L'aggiornamento in sequenza del sistema operativo del cluster offre i vantaggi seguenti:

  • I cluster di failover che eseguono macchine virtuali Hyper-V e carichi di lavoro file server di scalabilità orizzontale possono essere aggiornati da una versione di Windows Server, a partire da Windows Server 2012 R2, a una versione più recente di Windows Server. Ad esempio, è possibile aggiornare Windows Server 2016 (in esecuzione in tutti i nodi del cluster) a Windows Server 2019 (in esecuzione in tutti i nodi del cluster) senza tempi di inattività.

  • Non richiede hardware aggiuntivo. Nei cluster di piccole dimensioni è possibile aggiungere temporaneamente nodi del cluster aggiuntivi per migliorare la disponibilità del cluster durante il processo di aggiornamento in sequenza del sistema operativo del cluster.

  • Non è necessario arrestare o riavviare il cluster.

  • Non è necessario un nuovo cluster. Il cluster esistente viene aggiornato. Vengono inoltre usati gli oggetti cluster esistenti archiviati in Active Directory.

  • Il processo di aggiornamento è reversibile fino al passaggio finale, quando tutti i nodi del cluster eseguono la versione più recente di Windows Server e il Update-ClusterFunctionalLevel cmdlet di PowerShell viene eseguito.

  • Il cluster può supportare le operazioni di applicazione di patch e manutenzione durante l'esecuzione in modalità sistema operativo misto.

  • Supporta l'automazione tramite PowerShell e WMI.

  • La proprietà pubblica cluster ClusterFunctionalLevel indica lo stato del cluster in Windows Server 2016 e nodi del cluster successivi. È possibile eseguire query su questa proprietà usando il cmdlet di PowerShell da un nodo del cluster appartenente a un cluster di failover:

    Get-Cluster | Select ClusterFunctionalLevel
    

    La tabella seguente mostra i valori e ogni livello funzionale corrispondente:

    Valore Livello funzionale
    8 Windows Server 2012 R2
    9 Windows Server 2016
    10 Windows Server 2019

Questa guida descrive le varie fasi del processo di aggiornamento in sequenza del sistema operativo del cluster, i passaggi di installazione, le limitazioni delle funzionalità e le domande frequenti ed è applicabile agli scenari di aggiornamento in sequenza del sistema operativo del cluster seguenti in Windows Server:

  • Cluster Hyper-V
  • Scale-Out cluster file server

Lo scenario seguente non è supportato:

  • Aggiornamento in sequenza del sistema operativo del cluster dei cluster guest usando il disco rigido virtuale (file con estensione vhdx) come risorsa di archiviazione condivisa.

L'aggiornamento in sequenza del sistema operativo del cluster è completamente supportato da System Center Virtual Machine Manager (SCVMM). Se si usa SCVMM, vedere Eseguire un aggiornamento in sequenza di un cluster host Hyper-V per Windows Server 2016 in VMM per indicazioni sull'aggiornamento dei cluster e sull'automazione dei passaggi descritti in questo documento.

Requisiti

Completare i requisiti seguenti prima di iniziare il processo di aggiornamento in sequenza del sistema operativo del cluster:

  • Iniziare con un cluster di failover che esegue Windows Server 2012 R2 o versione successiva. È possibile eseguire l'aggiornamento alla versione successiva, ad esempio da Windows Server 2016 a Windows Server 2019.
  • Verificare che i nodi Hyper-V dispongano di CPU che supportano Second-Level Tabella di indirizzamento (SLAT) usando uno dei metodi seguenti; - Esaminare l'oggetto Sei compatibile con SLAT? Articolo del suggerimento per WP8 SDK 01 che descrive due metodi per verificare se una CPU supporta i contratti di servizio: scaricare lo strumento Coreinfo v3.31 per determinare se una CPU supporta SLAT.

Stati di transizione del cluster durante l'aggiornamento in sequenza del sistema operativo del cluster

Questa sezione descrive i vari stati di transizione del cluster Windows Server da aggiornare alla versione successiva di Windows Server tramite l'aggiornamento in sequenza del sistema operativo del cluster.

Per mantenere in esecuzione i carichi di lavoro del cluster durante il processo di aggiornamento in sequenza del sistema operativo del cluster, spostare un carico di lavoro del cluster da un nodo che esegue una versione precedente di Windows Server a un nodo che esegue una versione più recente di Windows Server usando una modalità di compatibilità. Questa modalità di compatibilità rende i nodi che eseguono la versione più recente di Windows Server vengono visualizzati come se eseguano la stessa versione precedente di Windows Server. Ad esempio, quando si aggiorna un cluster Windows Server 2016 a Windows Server 2019, i nodi di Windows Server 2019 operano in una modalità di compatibilità Windows Server 2016 come misura temporanea. Una nuova modalità cluster concettuale, denominata modalità sistema operativo misto, consente l'esistenza di nodi di versioni diverse nello stesso cluster (vedere la figura 1).

Illustration showing the three stages of a cluster OS rolling upgrade: all nodes Windows Server 2012 R2, mixed-OS mode, and all nodes Windows Server 2016Figura 1: Transizioni di stato del sistema operativo del cluster

Un cluster Windows Server passa alla modalità sistema operativo misto quando un nodo che esegue una versione più recente di Windows Server viene aggiunto al cluster. Il processo è completamente reversibile a questo punto. I nodi di Windows Server più recenti possono essere rimossi dal cluster e dai nodi che eseguono la versione esistente di Windows Server possono essere aggiunti al cluster in questa modalità. Il processo non è reversibile dopo l'esecuzione del Update-ClusterFunctionalLevel cmdlet di PowerShell nel cluster. Affinché questo cmdlet abbia esito positivo, tutti i nodi devono eseguire la versione più recente di Windows Server e tutti i nodi devono essere online.

Stati di transizione di un cluster a quattro nodi durante l'esecuzione dell'aggiornamento del sistema operativo in sequenza

Questa sezione illustra e descrive le quattro diverse fasi di un cluster con archiviazione condivisa i cui nodi vengono aggiornati da Windows Server 2012 R2 a Windows Server 2016. Il processo è lo stesso per le versioni successive di Window Server.

"Fase 1" è lo stato iniziale. Si inizia con un cluster Windows Server 2012 R2.

Illustration showing the initial state: all nodes Windows Server 2012 R2Figura 2: Stato iniziale: Windows Server 2012 cluster di failover R2 (fase 1)

Nella fase 2 sono stati sospesi due nodi, svuotati, rimossi, riformattati e installati con Windows Server 2016.

Illustration showing the cluster in mixed-OS mode: out of the example 4-node cluster, two nodes are running Windows Server 2016, and two nodes are running Windows Server 2012 R2Figura 3: Stato intermedio: modalità sistema operativo misto: Windows Server 2012 R2 e Windows Server 2016 cluster di failover (fase 2)

Nella fase 3 tutti i nodi del cluster sono stati aggiornati a Windows Server 2016 e il cluster è pronto per l'aggiornamento con Update-ClusterFunctionalLevel il cmdlet di PowerShell.

Nota

In questa fase, il processo può essere completamente invertito e Windows Server 2012 nodi R2 possono essere aggiunti a questo cluster.

Illustration showing that the cluster has been fully upgraded to Windows Server 2016, and is ready for the Update-ClusterFunctionalLevel cmdlet to bring the cluster functional level up to Windows Server 2016Figura 4: Stato intermedio: tutti i nodi aggiornati a Windows Server 2016, pronti per Update-ClusterFunctionalLevel (fase 3)

Dopo l'esecuzione del Update-ClusterFunctionalLevel cmdlet, il cluster entra nella fase 4, in cui è possibile usare nuove funzionalità del cluster Windows Server 2016.

Illustration showing that the cluster rolling OS upgrade has been successfully completed; all nodes have been upgraded to Windows Server 2016, and the cluster is running at the Windows Server 2016 cluster functional levelFigura 5: Stato finale: Windows Server 2016 cluster di failover (fase 4)

Processo di aggiornamento in sequenza del sistema operativo del cluster

Questa sezione descrive il flusso di lavoro per l'esecuzione dell'aggiornamento in sequenza del sistema operativo del cluster.

Illustration showing the workflow for upgrading a clusterFigura 6: Flusso di lavoro del processo di aggiornamento in sequenza del sistema operativo del cluster

L'aggiornamento in sequenza del sistema operativo del cluster include i passaggi seguenti per l'aggiornamento da Windows Server 2012 R2 a Windows Server 2016, ma il processo è lo stesso per le versioni successive di Window Server.

  1. Preparare il cluster per l'aggiornamento del sistema operativo come indicato di seguito:

    1. L'aggiornamento in sequenza del sistema operativo del cluster richiede la rimozione di un nodo alla volta dal cluster. Controllare se nel cluster è disponibile una capacità sufficiente per mantenere i contratti di servizio a disponibilità elevata quando uno dei nodi del cluster viene rimosso dal cluster per un aggiornamento del sistema operativo. In altre parole, è necessaria la funzionalità per eseguire il failover dei carichi di lavoro in un altro nodo quando un nodo viene rimosso dal cluster durante il processo di aggiornamento in sequenza del sistema operativo del cluster? Il cluster ha la capacità di eseguire i carichi di lavoro necessari quando un nodo viene rimosso dal cluster per l'aggiornamento in sequenza del sistema operativo del cluster?

    2. Per i carichi di lavoro Hyper-V, verificare che tutti gli host Hyper-V del server Windows dispongano del supporto della CPU per Second-Level Address Table (SLAT). Solo i computer con supporto per SLAT possono usare il ruolo Hyper-V in Windows Server 2016 e versioni successive.

    3. Verificare che tutti i backup del carico di lavoro siano stati completati e valutare la possibilità di eseguire il backup del cluster. Arrestare le operazioni di backup durante l'aggiunta di nodi al cluster.

    4. Verificare che tutti i nodi del cluster siano online /running/up usando il Get-ClusterNode cmdlet (vedere la figura 7).

      Screencap showing the results of running the Get-ClusterNode cmdletFigura 7: Determinazione dello stato del nodo tramite il cmdlet Get-ClusterNode

    5. Se si eseguono aggiornamenti compatibile con cluster, verificare se Aggiornamento compatibile con cluster è attualmente in esecuzione usando l'interfaccia utente di aggiornamento compatibile con cluster o il Get-CauRun cmdlet (vedere la figura 8). Arrestare aggiornamento compatibile con cluster usando il Disable-CauClusterRole cmdlet (vedere la figura 9) per impedire che i nodi vengano sospesi e svuotati da Aggiornamento compatibile con cluster durante il processo di aggiornamento in sequenza del sistema operativo del cluster.

      Screencap showing the output of the Get-CauRun cmdletFigura 8: Uso del Get-CauRun cmdlet per determinare se gli aggiornamenti con riconoscimento del cluster sono in esecuzione nel cluster

      Screencap showing the output of the Disable-CauClusterRole cmdletFigura 9: Disabilitazione del ruolo Aggiornamenti con riconoscimento del cluster tramite il Disable-CauClusterRole cmdlet

  2. Per ogni nodo del cluster, completare le operazioni seguenti:

    1. Usando l'interfaccia utente di Gestione cluster, selezionare un nodo e usare l'opzione Sospendi | Opzione di menu Svuota per svuotare il nodo (vedere la figura 10) o usare il Suspend-ClusterNode cmdlet (vedere la figura 11).

      Screencap showing how to drain roles with the Cluster Manager UIFigura 10: Svuotamento dei ruoli da un nodo tramite Gestione cluster di failover

      Screencap showing the output of the Suspend-ClusterNode cmdletFigura 11: Svuotare i ruoli da un nodo usando il Suspend-ClusterNode cmdlet

    2. Usando l'interfaccia utente di Gestione cluster, rimuovere il nodo sospeso dal cluster o usare il Remove-ClusterNode cmdlet .

      Screencap showing the output of the Remove-ClusterNode cmdletFigura 12: Rimuovere un nodo dal cluster usando Remove-ClusterNode il cmdlet

    3. Riformattare l'unità di sistema ed eseguire una "installazione pulita del sistema operativo" di Windows Server 2016 nel nodo usando l'opzione Custom: Install Windows only (advanced) installation (Vedere la figura 13) in setup.exe. Evitare di selezionare l'opzione Aggiorna: installare Windows e mantenere file, impostazioni e applicazioni perché l'aggiornamento in sequenza del sistema operativo del cluster non incoraggia l'aggiornamento sul posto.

      Screencap of the Windows Server 2016 installation wizard showing the custom install option selectedFigura 13: Opzioni di installazione disponibili per Windows Server 2016

    4. Aggiungere il nodo al dominio di Active Directory appropriato.

    5. Aggiungere gli utenti appropriati al gruppo Administrators.

    6. Usando l'interfaccia utente di Server Manager o Install-WindowsFeature cmdlet di PowerShell, installare tutti i ruoli del server necessari, ad esempio Hyper-V.

      Install-WindowsFeature -Name Hyper-V
      
    7. Usando l'interfaccia utente di Server Manager o Install-WindowsFeature cmdlet di PowerShell, installare la funzionalità Clustering di failover.

      Install-WindowsFeature -Name Failover-Clustering
      
    8. Installare eventuali funzionalità aggiuntive necessarie per i carichi di lavoro del cluster.

    9. Controllare le impostazioni di connettività di rete e archiviazione usando l'interfaccia utente di Gestione cluster di failover.

    10. Se viene usato Windows Firewall, verificare che le impostazioni del firewall siano corrette per il cluster. Ad esempio, i cluster abilitati per l'aggiornamento compatibile con cluster possono richiedere la configurazione del firewall.

    11. Per i carichi di lavoro Hyper-V, usare l'interfaccia utente di Gestione commutatori hyper-V per avviare la finestra di dialogo Gestione commutatori virtuali (vedere la figura 14).

      Verificare che il nome dei commutatori virtuali usati sia identico per tutti i nodi host Hyper-V nel cluster.

      Screencap showing the location of the Hyper-V Virtual Switch Manager dialogFigura 14: Gestione commutatori virtuali

    12. In un nodo Windows Server 2016 (non usare un nodo Windows Server 2012 R2), usare Gestione cluster di failover (vedere la figura 15) per connettersi al cluster.

      Screencap showing the select cluster dialogFigura 15: Aggiunta di un nodo al cluster tramite Gestione cluster di failover

    13. Usare l'interfaccia utente di Gestione cluster di failover o il Add-ClusterNode cmdlet (vedere la figura 16) per aggiungere il nodo al cluster.

      Screencap showing the output of the Add-ClusterNode cmdletFigura 16: Aggiunta di un nodo al cluster tramite Add-ClusterNode il cmdlet

      Nota

      Quando il primo nodo Windows Server 2016 viene aggiunto al cluster, il cluster passa alla modalità "Sistema operativo misto" e le risorse principali del cluster vengono spostate nel nodo Windows Server 2016. Un cluster in modalità "Sistema operativo misto" è un cluster completamente funzionale in cui i nuovi nodi vengono eseguiti in modalità di compatibilità con i nodi precedenti. La modalità "Mixed-OS" è una modalità transitoria per il cluster. Non è destinato a essere permanente e si prevede che i clienti aggiornino tutti i nodi del cluster entro quattro settimane.

    14. Dopo che il nodo Windows Server 2016 è stato aggiunto correttamente al cluster, è possibile (facoltativamente) spostare parte del carico di lavoro del cluster nel nodo appena aggiunto per ribilanciare il carico di lavoro nel cluster come indicato di seguito:

      Screencap showing the output of the Move-ClusterVirtualMachineRole cmdletFigura 17: Spostamento di un carico di lavoro del cluster (ruolo macchina virtuale del cluster) tramite Move-ClusterVirtualMachineRole il cmdlet

      1. Usare Live Migration da Gestione cluster di failover per le macchine virtuali o il Move-ClusterVirtualMachineRole cmdlet (vedere la figura 17) per eseguire una migrazione in tempo reale delle macchine virtuali.

        Move-ClusterVirtualMachineRole -Name VM1 -Node robhind-host3
        
      2. Usare Move from the Failover Cluster Manager (Sposta da Gestione cluster di failover) o il Move-ClusterGroup cmdlet per altri carichi di lavoro del cluster.

  3. Quando ogni nodo è stato aggiornato a Windows Server 2016 e aggiunto di nuovo al cluster o quando sono stati rimossi altri nodi Windows Server 2012 R2, eseguire le operazioni seguenti:

    Importante

    • Dopo aver aggiornato il livello di funzionalità del cluster, non è possibile tornare al livello funzionale Windows Server 2012 R2 e Windows Server 2012 nodi R2 non possono essere aggiunti al cluster.
    • Finché il Update-ClusterFunctionalLevel cmdlet non viene eseguito, il processo è completamente reversibile e Windows Server 2012 nodi R2 possono essere aggiunti a questo cluster e Windows Server 2016 nodi possono essere rimossi.
    • Dopo l'esecuzione del Update-ClusterFunctionalLevel cmdlet, saranno disponibili nuove funzionalità.
    1. Usando l'interfaccia utente di Gestione cluster di failover o il Get-ClusterGroup cmdlet , verificare che tutti i ruoli del cluster siano in esecuzione nel cluster come previsto. Nell'esempio seguente l'Archiviazione disponibile non viene usato, viene invece usato csv, quindi viene visualizzato lo stato Disponibile Archiviazione viene visualizzato uno stato Offline (vedere la figura 18).

      Screencap showing the output of the Get-ClusterGroup cmdletFigura 18: Verifica che tutti i gruppi di cluster (ruoli del cluster) siano in esecuzione usando il Get-ClusterGroup cmdlet

    2. Verificare che tutti i nodi del cluster siano online e in esecuzione usando il Get-ClusterNode cmdlet .

    3. Eseguire il Update-ClusterFunctionalLevel cmdlet : non devono essere restituiti errori (vedere la figura 19).

      Screencap showing the output of the Update-ClusterFunctionalLevel cmdletFigura 19: Aggiornamento del livello funzionale di un cluster tramite PowerShell

    4. Dopo l'esecuzione del Update-ClusterFunctionalLevel cmdlet, sono disponibili nuove funzionalità.

  4. Riprendere gli aggiornamenti e i backup normali del cluster:

    1. Se in precedenza si esegue Aggiornamento compatibile con cluster, riavviarlo usando l'interfaccia utente di Aggiornamento compatibile con cluster o usare il Enable-CauClusterRole cmdlet (vedere la figura 20).

      Screencap showing the output of the Enable-CauClusterRoleFigura 20: Abilitare il ruolo Aggiornamenti in grado di supportare il cluster usando il Enable-CauClusterRole cmdlet

    2. Riprendere le operazioni di backup.

  5. Abilitare e usare le funzionalità di Windows Server 2016 in Hyper-V Macchine virtuali.

    1. Dopo l'aggiornamento del cluster a Windows Server 2016 livello funzionale, molti carichi di lavoro come le macchine virtuali Hyper-V avranno nuove funzionalità. Per un elenco delle nuove funzionalità di Hyper-V. vedere Eseguire la migrazione e l'aggiornamento delle macchine virtuali

    2. In ogni nodo host Hyper-V del cluster usare il Get-VMHostSupportedVersion cmdlet per visualizzare le versioni di configurazione della macchina virtuale Hyper-V supportate dall'host.

      Screencap showing the output of the Get-VMHostSupportedVersion cmdletFigura 21: Visualizzazione delle versioni di configurazione della macchina virtuale Hyper-V supportate dall'host

    3. In ogni nodo host Hyper-V nel cluster è possibile aggiornare le versioni di configurazione delle macchine virtuali Hyper-V pianificando una breve finestra di manutenzione con gli utenti, eseguendo il backup, disattivando le macchine virtuali ed eseguendo il cmdlet (vedere la Update-VMVersion figura 22). In questo modo verrà aggiornata la versione della macchina virtuale e verranno abilitate le nuove funzionalità di Hyper-V, eliminando la necessità di aggiornamenti futuri del componente di integrazione Hyper-V. Questo cmdlet può essere eseguito dal nodo Hyper-V che ospita la macchina virtuale oppure il -ComputerName parametro può essere usato per aggiornare la versione della macchina virtuale in modalità remota. In questo esempio viene aggiornata la versione di configurazione di VM1 da 5.0 a 7.0 per sfruttare molte nuove funzionalità di Hyper-V associate a questa versione di configurazione della macchina virtuale, ad esempio checkpoint di produzione (backup coerenti con l'applicazione) e file di configurazione binario della macchina virtuale.

      Screencap showing the Update-VMVersion cmdlet in actionFigura 22: Aggiornamento di una versione di macchina virtuale tramite il cmdlet di PowerShell Update-VMVersion

  6. Archiviazione pool possono essere aggiornati usando il cmdlet di PowerShell Update-StoragePool. Si tratta di un'operazione online.

Anche se sono destinati a scenari di cloud privato, in particolare cluster hyper-V e file server con scalabilità orizzontale, che possono essere aggiornati senza tempi di inattività, il processo di aggiornamento in sequenza del sistema operativo del cluster può essere usato per qualsiasi ruolo del cluster.

Restrizioni/limitazioni

  • Questa funzionalità funziona solo per le versioni di Windows Server a partire da Windows Server 2012 R2. Questa funzionalità non può aggiornare versioni precedenti di Windows Server, ad esempio Windows Server 2008, Windows Server 2008 R2 o Windows Server 2012.
  • Ogni nodo Windows Server 2016 deve essere riformattato o solo nuova installazione. I tipi di installazione sul posto o di aggiornamento sono sconsigliati.
  • Per aggiungere i nuovi nodi al cluster, è necessario usare un nodo che esegue la versione più recente di Windows Server.
  • Quando si gestisce un cluster in modalità sistema operativo misto, eseguire sempre le attività di gestione da un nodo di livello superiore che esegue Windows Server 2016. I nodi Windows Server di livello inferiore non possono usare gli strumenti di interfaccia utente o di gestione rispetto alle versioni più recenti di Windows Server.
  • Si consiglia ai clienti di spostarsi rapidamente nel processo di aggiornamento del cluster perché alcune funzionalità del cluster non sono ottimizzate per la modalità sistema operativo misto.
  • Evitare di creare o ridimensionare l'archiviazione nei nodi Windows Server più recenti mentre il cluster è in esecuzione in modalità sistema operativo misto a causa di possibili incompatibilità durante il failover da un nodo Windows Server più recente a nodi Windows Server di livello inferiore.

Domande frequenti

Per quanto tempo il cluster di failover può essere eseguito in modalità sistema operativo misto? Invitiamo i clienti a completare l'aggiornamento entro quattro settimane. I cluster Hyper-V e File Server con scalabilità orizzontale sono stati aggiornati correttamente con tempi di inattività pari a meno di quattro ore totali.

Questa funzionalità verrà riconfermata a Windows Server 2012, Windows Server 2008 R2 o Windows Server 2008? Non sono previsti piani per trasferire questa funzionalità alle versioni precedenti. L'aggiornamento in sequenza del sistema operativo del cluster è la visione per l'aggiornamento dei cluster Windows Server.

I nodi che eseguono la versione precedente di Windows Server devono avere tutti gli aggiornamenti software installati prima di avviare il processo di aggiornamento in sequenza del sistema operativo del cluster? Sì, prima di avviare il processo di aggiornamento in sequenza del sistema operativo del cluster, verificare che tutti i nodi del cluster vengano aggiornati con gli aggiornamenti software più recenti.

È possibile eseguire il Update-ClusterFunctionalLevel cmdlet mentre i nodi sono disattivati o sospesi? No. Per il funzionamento del cmdlet, tutti i nodi del cluster devono trovarsi in e nell'appartenenza Update-ClusterFunctionalLevel attiva.

L'aggiornamento in sequenza del sistema operativo del cluster funziona per qualsiasi carico di lavoro del cluster? Funziona per SQL Server? Sì, l'aggiornamento in sequenza del sistema operativo del cluster funziona per qualsiasi carico di lavoro del cluster. Tuttavia, si tratta solo di un tempo di inattività zero per i cluster Hyper-V e file server con scalabilità orizzontale. La maggior parte degli altri carichi di lavoro comporta un tempo di inattività (in genere un paio di minuti) durante il failover e il failover è necessario almeno una volta durante il processo di aggiornamento in sequenza del sistema operativo del cluster.

È possibile automatizzare questo processo usando PowerShell? Sì, l'aggiornamento in sequenza del sistema operativo del cluster è stato progettato per essere automatizzato con PowerShell.

Per un cluster di grandi dimensioni con capacità di failover aggiuntiva, è possibile aggiornare più nodi contemporaneamente? Sì. Quando un nodo viene rimosso dal cluster per aggiornare il sistema operativo, il cluster avrà un nodo minore per il failover, quindi avrà una capacità di failover ridotta. Per i cluster di grandi dimensioni con capacità di carico di lavoro e failover sufficienti, è possibile aggiornare più nodi contemporaneamente. È possibile aggiungere temporaneamente nodi del cluster al cluster per fornire capacità di failover e carico di lavoro migliorate durante il processo di aggiornamento in sequenza del sistema operativo del cluster.

Cosa accade se si rileva un problema nel cluster dopo Update-ClusterFunctionalLevel l'esecuzione corretta? Se è stato eseguito il backup del database cluster con un backup dello stato del sistema prima di eseguire Update-ClusterFunctionalLevel, è necessario poter eseguire un ripristino autorevole in un nodo che esegue la versione precedente di Windows Server e ripristinare il database e la configurazione del cluster originale.

È possibile usare l'aggiornamento sul posto per ogni nodo invece di usare l'installazione clean-OS riformattando l'unità di sistema? Non è consigliabile usare l'aggiornamento sul posto di Windows Server, ma si è consapevoli che funziona in alcuni casi in cui vengono usati i driver predefiniti. Leggere attentamente tutti i messaggi di avviso visualizzati durante l'aggiornamento sul posto di un nodo del cluster.

Se si usa la replica Hyper-V per una macchina virtuale Hyper-V nel cluster Hyper-V, la replica rimarrà intatta durante e dopo il processo di aggiornamento in sequenza del sistema operativo del cluster? Sì, la replica Hyper-V rimane intatta durante e dopo il processo di aggiornamento in sequenza del sistema operativo del cluster.

È possibile usare System Center Virtual Machine Manager (SCVMM) per automatizzare il processo di aggiornamento in sequenza del sistema operativo del cluster? Sì, è possibile automatizzare il processo di aggiornamento in sequenza del sistema operativo del cluster usando VMM in System Center.