Aggiornamento in sequenza del sistema operativo del cluster

L'aggiornamento in sequenza del sistema operativo del cluster consente a un amministratore di aggiornare il sistema operativo dei carichi di lavoro Hyper-V o Scale-Out File Server dei nodi del cluster 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 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 cmdlet di PowerShell Update-ClusterFunctionalLevel 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 nei nodi del cluster Windows Server 2016 e versioni successive. È possibile eseguire query su questa proprietà usando il cmdlet di PowerShell da un nodo del cluster che appartiene 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 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 in Windows Server:

• Cluster Hyper-V
• Cluster del file server di scalabilità orizzontale

Il seguente scenario 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 a Windows Server 2016 in VMM per indicazioni sull'aggiornamento dei cluster e sull'automazione dei passaggi descritti in questo documento.

Requisiti

Prima di iniziare il processo di aggiornamento in sequenza del sistema operativo del cluster, completare i requisiti seguenti:

• 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 la tabella SLAT (Second-Level Addressing Table) usando uno dei metodi seguenti; - Verificare se si è compatibili con SLAT? Articolo di WP8 SDK Tip 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 cluster.

Per mantenere in esecuzione i carichi di lavoro del cluster durante il processo di aggiornamento in sequenza del sistema operativo del cluster, lo spostamento di 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 funziona 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 modalità di compatibilità di Windows Server 2016 come misura temporanea. Una nuova modalità cluster concettuale, denominata Modalità mixed-OS, consente l'esistenza di nodi di versioni diverse nello stesso cluster (vedere la figura 1).

Figura 1: Transizioni dello stato del sistema operativo del cluster

Un cluster Windows Server entra in 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 i 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 cmdlet di PowerShell Update-ClusterFunctionalLevel 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 Windows Server.

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

Figura 2: Stato iniziale: Cluster di failover di Windows Server 2012 R2 (fase 1)

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

Figura 3: Stato intermedio: modalità sistema operativo misto: Windows Server 2012 R2 e cluster di failover di Windows Server 2016 (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.

Figura 4: Stato intermedio: tutti i nodi aggiornati a Windows Server 2016, pronti per Update-ClusterFunctionalLevel (fase 3)

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

Figura 5: Stato finale: Cluster di failover di Windows Server 2016 (fase 4)

Processo Cluster OS Rolling Upgrade

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

Figura 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 possibilità di 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 di Windows Server dispongano del supporto della CPU per la tabella degli indirizzi di secondo livello (SLAT). Solo i computer che supportano 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 prendere in considerazione 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 cmdlet Get-ClusterNode (vedere Figura 7).

      Figura 7: Determinazione dello stato del nodo tramite il cmdlet Get-ClusterNode

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

      Figura 8: Uso del Get-CauRun cmdlet per determinare se cluster aware Aggiornamenti è in esecuzione nel cluster

      Figura 9: Disabilitazione del ruolo Aggiornamenti compatibile con cluster tramite il cmdlet Disable-CauClusterRole

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

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

      Figura 10: Svuotare i ruoli da un nodo usando Gestione cluster di failover

      Figura 11: Svuotare i ruoli da un nodo usando il cmdlet Suspend-ClusterNode

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

      Figura 12: Rimuovere un nodo dal cluster usando Remove-ClusterNode il cmdlet

   3. Riformattare l'unità di sistema ed eseguire l'opzione "installazione pulita del sistema operativo" di Windows Server 2016 nel nodo usando l'opzione Installazione personalizzata solo windows (avanzate) (vedere la figura 13) in setup.exe. Evitare di selezionare l'opzione Aggiorna: installa Windows e mantieni file, impostazioni e applicazioni perché l'aggiornamento in sequenza del sistema operativo del cluster non incoraggia l'aggiornamento sul posto.

      Figura 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 Amministratori.

   6. Usando l'interfaccia utente di Server Manager o il cmdlet Install-WindowsFeature 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 il cmdlet Install-WindowsFeature 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 potrebbero richiedere la configurazione del firewall.

   11. Per i carichi di lavoro Hyper-V, usare l'interfaccia utente di Hyper-V Manger 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.

       Figura 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.

       Figura 15: Aggiunta di un nodo al cluster tramite Gestione cluster di failover

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

       Figura 16: Aggiunta di un nodo al cluster tramite il cmdlet Add-ClusterNode

       Nota

       Quando il primo nodo di 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 aver aggiunto correttamente il nodo Windows Server 2016 al cluster, è possibile (facoltativamente) spostare alcuni dei carichi di lavoro del cluster nel nodo appena aggiunto per ribilanciare il carico di lavoro nel cluster come indicato di seguito:

       Figura 17: Spostamento di un carico di lavoro del cluster (ruolo macchina virtuale del cluster) con il cmdlet Move-ClusterVirtualMachineRole

       1. Usare Live Migration da Gestione cluster di failover per le macchine virtuali o il cmdlet Move-ClusterVirtualMachineRole (vedere 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 cmdlet Move-ClusterGroup 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 eventuali nodi di Windows Server 2012 R2 rimanenti, 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 non è possibile aggiungere nodi Windows Server 2012 R2 al cluster.
   • Fino a quando il cmdlet Update-ClusterFunctionalLevel non viene eseguito, il processo è completamente reversibile e i nodi Windows Server 2012 R2 possono essere aggiunti a questo cluster e i nodi di Windows Server 2016 possono essere rimossi.
   • Alcune operazioni del cluster, ad esempio lo svuotamento dei nodi, possono causare la isolamento di un nodo per un breve periodo di tempo. Questo comportamento può verificarsi quando l'operazione Update-ClusterFunctionalLevel non è stata eseguita.
   • Dopo l'esecuzione del cmdlet Update-ClusterFunctionalLevel, saranno disponibili nuove funzionalità.

   1. Usando l'interfaccia utente di Gestione cluster di failover o il cmdlet Get-ClusterGroup, 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 è disponibile Archiviazione visualizza uno stato Offline (vedere la figura 18).

      Figura 18: Verifica che tutti i gruppi di cluster (ruoli del cluster) siano in esecuzione usando il cmdlet Get-ClusterGroup

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

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

      Figura 19: Aggiornamento del livello funzionale di un cluster tramite PowerShell

   4. Dopo l'esecuzione del cmdlet Update-ClusterFunctionalLevel, 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 cmdlet Enable-CauClusterRole (vedere la figura 20).

      Figura 20: Abilitare il ruolo Aggiornamenti compatibile con cluster usando il cmdlet Enable-CauClusterRole

   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 al livello di funzionalità di Windows Server 2016, 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 aggiornare le macchine virtuali

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

      Figura 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 della macchina virtuale Hyper-V pianificando una breve finestra di manutenzione con gli utenti, eseguendo il backup, disattivando le macchine virtuali ed eseguendo il cmdlet Update-VMVersion (vedere figura 22). Questa operazione aggiornerà la versione della macchina virtuale e abiliterà 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 parametro -ComputerName può essere usato per aggiornare la versione della macchina virtuale in modalità remota. In questo esempio viene aggiornata la versione di configurazione di VM1 dalla versione 5.0 alla 7.0 per sfruttare molte nuove funzionalità 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.

      Figura 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-Archiviazione Pool: 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 di 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 strumenti di gestione o interfaccia utente rispetto alle versioni più recenti di Windows Server.
• È consigliabile che i clienti passino rapidamente attraverso il 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 di Windows Server più recente a nodi Windows Server di livello inferiore.

Domande frequenti

Quanto tempo può essere eseguito il cluster di failover 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 con tempi di inattività pari a zero in 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 convertire 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 cmdlet Update-ClusterFunctionalLevel mentre i nodi sono disattivati o sospesi? No. Tutti i nodi del cluster devono trovarsi nell'appartenenza attiva affinché il cluster Update-ClusterFunctionalLevel funzioni.

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 tempi di inattività zero per i cluster Hyper-V e file server con scalabilità orizzontale. La maggior parte degli altri carichi di lavoro comporta alcuni tempi di inattività (in genere un paio di minuti) quando esegue 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ì, è stato progettato l'aggiornamento in sequenza del sistema operativo del cluster per l'automazione 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 inferiore 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 una migliore capacità di carico di lavoro e failover durante il processo di aggiornamento in sequenza del sistema operativo del cluster.

Cosa accade se si rileva un problema nel cluster dopo la corretta esecuzione di Update-ClusterFunctionalLevel? Se è stato eseguito il backup del database del 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 anziché usare l'installazione pulita del sistema operativo riformattando l'unità di sistema? Non incoraggiamo l'uso dell'aggiornamento sul posto di Windows Server, ma sappiamo 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.