Gestione della capacità e disponibilità elevata in un ambiente virtuale (SharePoint Server 2010)

Articolo
01/11/2017

Ultima modifica dell'argomento: 2016-11-30

In questo articolo vengono fornite informazioni sulla gestione della capacità e sulla disponibilità elevata per un ambiente virtuale che ospita Microsoft SharePoint Server 2010. I due concetti sono trattati in modo unitario in quanto la capacità e il dimensionamento sono aspetti molto importanti nello sviluppo di un piano di virtualizzazione e dell'architettura di un ambiente virtuale e in quanto la gestione della capacità non è isolata dalla disponibilità elevata in un ambiente virtuale. Nel caso degli host di virtualizzazione, una capacità insufficiente può bloccare la disponibilità elevata a livello di farm e di host.

Come avviene per gli altri aspetti di un ambiente virtuale, quali il backup e il ripristino, la gestione della capacità e la disponibilità elevata devono operare nei due livelli di un ambiente virtuale, ossia le macchine virtuali utilizzate per SharePoint Server 2010 e i server fisici utilizzati per ospitare le macchine virtuali. Nel caso di ambienti ibridi, è inoltre necessario tenere conto dei server fisici della farm di Microsoft SharePoint Server.

Contenuto dell'articolo:

Panoramica della virtualizzazione

La virtualizzazione dei server, come implementata da tecnologia Hyper-V per Windows Server 2008 o da Microsoft Hyper-V Server 2008, è detta virtualizzazione basata su hardware, per distinguerla dalla virtualizzazione basata su software. L'hypervisor Hyper-V ha un canale di comunicazione e un'interazione più diretti con i componenti hardware dei server fisici rispetto alle tecnologie di virtualizzazione basate su software. In confronto a tali tecnologie, pertanto, può garantire prestazioni migliori. Per ulteriori informazioni sull'architettura di Hyper-V, vedere Introduzione a Hyper-V in Windows Server 2008 (https://go.microsoft.com/fwlink/?linkid=188006&clcid=0x410) e Monitoraggio delle prestazioni di Hyper-V (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=187746&clcid=0x410).

Sebbene un server fisico possa soddisfare i requisiti di Hyper-V, ogni server fisico è unico. Ogni produttore utilizza la propria implementazione di processori, tecnologia multicore, memoria, bus dati, dischi rigidi e schede di rete. La progettazione e l'implementazione dell'hardware varia inoltre da modello a modello, anche tra modelli dello stesso produttore. Per questo motivo, l'implementazione di SharePoint Server 2010 in un ambiente virtuale richiede test rigorosi.

I programmi e le applicazioni software manifestano la stessa eterogeneità di prestazioni presentata dall'hardware. Alcuni programmi fanno un utilizzo elevato della CPU, altri richiedono molta memoria e altri ancora hanno esigenze onerose per quanto riguarda il disco rigido. SharePoint Server ha le proprie esigenze di capacità, così come Internet Information Services (IIS) e SQL Server 2008. Anche questi aspetti richiedono test rigorosi.

La gestione della capacità richiede di prendere in considerazione il server di virtualizzazione, la soluzione di archiviazione, l'infrastruttura di rete, le tecnologie in esecuzione in un ambiente SharePoint Server e le caratteristiche abilitate per implementare la soluzione SharePoint Server.

Gestione della capacità

La gestione della capacità estende il concetto di pianificazione della capacità per descrivere un approccio ciclico, nel quale la capacità di una distribuzione di SharePoint Server 2010 viene continuamente monitorata e ottimizzata per adattarla a condizioni e requisiti in evoluzione. È possibile applicare questo approccio a tutte le farm di SharePoint Server, incluse quelle completamente o parzialmente virtualizzate. Per una panoramica della gestione della capacità, vedere Capacity management and sizing for SharePoint Server 2010. È possibile trovare altre risorse sulla gestione della capacità nel Centro risorse Gestione della capacità per SharePoint Server 2010 (https://go.microsoft.com/fwlink/?linkid=194748&clcid=0x410).

Capacità e dimensionamento dei server di virtualizzazione

Dopo avere predisposto il progetto della farm di SharePoint Server e le indicazioni di dimensionamento dei server della farm, è necessario progettare l'architettura dell'host di virtualizzazione fisico necessario per supportare la farm virtuale. Per ulteriori informazioni sulle architetture virtuali, vedere Pianificare architetture virtuali (SharePoint Server 2010).

È consigliabile utilizzare i principi applicabili della gestione della capacità di SharePoint Server 2010 come guida per l'ambiente virtuale. Le attività seguenti illustrano la natura iterativa della progettazione, del dimensionamento e della messa a punto di un'architettura virtuale e fisica, dalla pianificazione iniziale alla distribuzione in un ambiente di produzione.

Nota

Se la pianificazione e i test sono eseguiti in modo accurato, sarà necessario apportare modifiche all'architettura e alle configurazioni dei server solo in caso di un incremento significativo e imprevisto nell'utilizzo della farm, oppure in caso di aggiunta di nuove caratteristiche alla soluzione SharePoint Server.

Prima di iniziare la distribuzione della farm, creare un'architettura virtuale e fisica con il dimensionamento delle macchine virtuali e dei server di virtualizzazione. Nel caso di più di host di virtualizzazione, questa architettura deve includere la distribuzione delle macchine virtuali.
Durante la fase pilota della distribuzione, raccogliere dati sull'integrità e sulle prestazioni da utilizzare per stabilire benchmark per le macchine virtuali della farm e l'host di virtualizzazione.
Durante la fase del test di accettazione utenti della distribuzione, mettere a punto le configurazioni degli host di virtualizzazione e delle macchine virtuali in base ai dati di benchmark. Se necessario, modificare l'architettura fisica ridistribuendo le macchine virtuali sugli host di virtualizzazione.
Dopo la distribuzione, continuare a raccogliere dati di benchmark su integrità e prestazioni e affinare le configurazioni delle macchine virtuali e, se applicabile, dei computer fisici. Se necessario, correggere entrambe le architetture.

È essenziale avere la possibilità di analizzare i dati sulle prestazioni degli host di virtualizzazione e delle macchine virtuali e comprendere in che modo riflettono la capacità necessaria e gli effetti dell'applicazione sulla capacità. È inoltre necessario comprendere i limiti di prestazioni e capacità. Considerata l'interrelazione tra il livello virtuale e il livello fisico, qualsiasi fattore influenzi la capacità e le prestazioni delle macchine virtuali ha un effetto diretto sull'host o deve essere compensato tramite modifiche alla configurazione dell'host di virtualizzazione in modo da consentire prestazioni accettabili attraverso la farm.

In alcuni casi può essere necessario modificare l'architettura fisica aggiungendo host di virtualizzazione e modificando quindi la distribuzione delle macchine virtuali sull'architettura fisica.

Importante

Nei test di benchmark tra un computer fisico e una macchina virtuale, la velocità effettiva della macchina virtuale non può in genere eguagliare quella del computer fisico. Le prestazioni di una macchina virtuale sono sempre, con rare eccezioni, inferiori rispetto a quelle di un computer fisico. Il grado di differenza nelle prestazioni dipende dalle capacità dell'host di virtualizzazione, dalle applicazioni in esecuzione e dai benchmark scelti come indicatori di prestazioni primari.

È consigliabile leggere la pagina Domande frequenti sulle prestazioni di Hyper-V R2 (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=187745&clcid=0x410), che è costantemente aggiornato con informazioni sulle capacità e le prestazioni di Windows Server 2008 R2 e Windows Server 2008 con Service Pack 2 (SP2). Queste domande frequenti contengono risposte a domande comuni su Hyper-V, offrono indicazioni e includono collegamenti ad articoli dettagliati che è possibile utilizzare per sviluppare benchmark per l'host di virtualizzazione, le macchine virtuali e la rete di Windows.

Si suggerisce inoltre di leggere i post seguenti relativi ai contatori delle prestazioni di Hyper-V:

Creazione e affinamento delle architetture

Un'architettura completa è costituita dagli host di virtualizzazione, dalle macchine virtuali e dai computer fisici che compongono l'ambiente di SharePoint Server di cui si pianifica la distribuzione. Per ulteriori informazioni sulle architetture di virtualizzazione, vedere Pianificare architetture virtuali (SharePoint Server 2010).

Lo sviluppo e l'implementazione di un'architettura virtuale prevedono i passaggi seguenti:

Creare l'architettura virtuale e fisica. Creare un'architettura in grado di supportare gli obiettivi della farm di SharePoint Server 2010.
Analizzare le architetture. Individuare e procurarsi qualsiasi informazione mancante o in grado di migliorare la progettazione dell'ambiente che si pianifica di distribuire.
Affinare le architetture. Utilizzare le informazioni ottenute nel passaggio 2 per affinare l'architettura.
Continuare ad affinare le architetture e le configurazioni dei server durante il passaggio attraverso le varie fasi della distribuzione. Per ulteriori informazioni sulle fasi della distribuzione, vedere i modelli per la distribuzione dei prodotti SharePoint 2010 e per il processo di virtualizzazione dei prodotti SharePoint 2010, disponibili nell'articolo Diagrammi tecnici (SharePoint Server 2010).

Creare l'architettura

Creare un modello dell'architettura utilizzabile come strumento di valutazione e messa a punto delle configurazioni delle macchine virtuali e degli host di virtualizzazione. Utilizzare i criteri seguenti come guida per lo sviluppo del modello:

Determinare il numero di macchine virtuali necessarie e il ruolo di ognuna nella farm di SharePoint Server.
Specificare i requisiti di configurazione di ogni macchina virtuale (spazio su disco, memoria e numero di processori), in base ai requisiti di capacità di SharePoint Server.
Specificare i requisiti degli host di virtualizzazione (spazio su disco, memoria e numero di processori logici), in base ai requisiti delle macchine virtuali.
Determinare la distribuzione delle macchine virtuali sugli host di virtualizzazione, in base ai requisiti di elevata disponibilità della farm, entro i limiti definiti dalla quantità e capacità degli host di virtualizzazione.
Determinare i requisiti generali di rete e archiviazione.
Prevedere un margine di crescita negli host di virtualizzazione e nelle macchine virtuali (scalabilità verticale o scalabilità orizzontale).

Dopo la creazione di un modello di architettura, è necessario analizzare entrambe le architetture per convalidare la progettazione, nonché le configurazioni degli host di virtualizzazione e delle macchine virtuali.

Analizzare le architetture

L'analisi dell'architettura ha lo scopo fondamentale di determinare se è in grado di supportare la soluzione SharePoint Server 2010 che si desidera distribuire. È tuttavia ragionevole presupporre che la progettazione e le configurazioni dei server cambieranno nel corso del processo di distribuzione.

L'illustrazione seguente mostra un'architettura virtuale di esempio per una farm costituita da server Web front-end, server applicazioni e server database. Questa architettura è rappresentativa delle farm di piccole e medie dimensioni descritte in Architetture virtuali di esempio per farm di piccole e medie dimensioni e può essere utilizzata per mostrare gli elementi chiave da prendere in considerazione quando si analizzano i requisiti di capacità e disponibilità per una farm virtuale.

Importante

Le dimensioni indicate per i server di virtualizzazione e le macchine virtuali nell'illustrazione seguente non sono prescrittive.

Figura 1. Architettura preliminare

Topologia della farm di SharePoint Server 2010

Utilizzare i criteri indicati per creare un'architettura virtuale per analizzare l'architettura di esempio mostrata nell'illustrazione precedente. L'architettura nell'illustrazione è basata sul presupposto che tutti i server Web e i server applicazioni siano macchine virtuali. È indeterminato se i server database della farm siano computer fisici o macchine virtuali.

Analisi degli host di virtualizzazione

Le tabelle seguenti (HOST-1 e HOST-2) riportano un'analisi di ogni host di virtualizzazione in base a criteri di memoria, processori e scalabilità. L'analisi degli host è seguita da un'analisi della progettazione.

HOST-1

Criteri	Analisi
Memoria	Riservando 2 GB di RAM per il sistema operativo host e basandosi sui requisiti di RAM previsti, si può stimare una disponibilità rimanente di 2 GB di RAM per utilizzo futuro.
Processori	Il mapping tra processori logici e virtuali è di 8:10 (1:1,25). Ciò significa che nella CPU è presente una leggera oversubscription, che non costituisce tuttavia un problema in un ambiente di testing. Importante L'oversubscription della CPU in un server di virtualizzazione riduce le prestazioni complessive. La portata di questo effetto è determinata dal carico sostenuto dalle macchine virtuali. Come procedura consigliata, non eseguire l'oversubscription della CPU del server di virtualizzazione, se evitabile.
Scalabilità	In questo caso non è applicabile, in quanto la memoria è insufficiente. Il grado di oversubscription della CPU (anche con l'aggiunta di una macchina virtuale con due processori) avrebbe inoltre un effetto evidente sulle prestazioni.

HOST-2

Criteri	Analisi
Memoria	Riservando 2 GB di RAM per il sistema operativo host e basandosi sui requisiti di RAM previsti, si può stimare una disponibilità rimanente di 6 GB di RAM per utilizzo futuro.
Processori	Il mapping tra processori logici e virtuali è di 8:8 (1:1), corrispondente alle indicazioni sulle procedure consigliate.
Scalabilità	La memoria è sufficiente per consentire un aumento dell'allocazione alle macchine virtuali. La capacità è sufficiente per consentire l'aggiunta di una nuova macchina virtuale con due processori e 4 GB di RAM. Si ha in tal modo una leggera oversubscription della CPU dell'host di virtualizzazione (8:10) ma, come nel caso dell'HOST-1, ciò non costituisce un problema in un ambiente di testing.

Analisi della progettazione

L'architettura di esempio mostra in generale un grado di disponibilità elevato per i server della farm. Vi sono ad esempio tre server Web front-end distribuiti tra gli host HOST-1 e HOST-2 e anche i server database (in cluster o con mirroring) risiedono in host di virtualizzazione distinti o in server fisici separati. La disponibilità elevata a livello di host di virtualizzazione non costituisce parte dell'architettura e mancano informazioni pertinenti. È necessario acquisire le informazioni seguenti prima di poter aggiornare la progettazione:

Dimensioni del database

Le dimensioni del database del contenuto determinano le modalità di configurazione e distribuzione di tutti i server della farm.
Sottosistema di archiviazione

Nell'architettura di esempio non sono fornite, tra l'altro, informazioni sul numero di dischi necessari per ogni macchina virtuale, né sono presenti indicazioni sulla distribuzione e la capacità dei dischi. Queste informazioni sono molto importanti per determinare e configurare il sistema di archiviazione. L'architettura di esempio utilizza un archivio locale. È necessario determinare se questa soluzione è indicata per il proprio ambiente o se è preferibile utilizzare una configurazione disco pass-through verso un LUN in una SAN.
Requisiti di rete

È necessario determinare il numero di schede di rete e la velocità effettiva minima.
Configurazioni dei dischi rigidi virtuali

È inoltre necessario determinare le configurazioni dei dischi rigidi di Hyper-V che si desidera utilizzare (ad esempio, dimensioni fisse o pass-through). Per ulteriori informazioni, vedere Pianificare i dischi e l'archiviazione (https://go.microsoft.com/fwlink/?linkid=188007&clcid=0x410) e Prestazioni del disco rigido virtuale: Windows Server 2008 / Windows Server 2008 R2 / Windows 7 (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=186519&clcid=0x410).

Dopo avere completato l'analisi della progettazione, il passaggio successivo consiste nell'affinamento dell'architettura.

Affinare l'architettura

L'ambito dell'affinamento dell'architettura dipende dall'architettura iniziale, dai risultati dell'analisi e dal piano di implementazione. Utilizzando l'esempio qui descritto, vi sono scenari nei quali si può decidere di non apportare alcuna modifica. Ad esempio:

L'architettura preliminare è idonea per i test iniziali, i modelli di prova e una distribuzione pilota limitata.
Gli host di virtualizzazione hanno unicamente funzione di test e verranno sostituiti da host con capacità più elevata durante la fase del test di accettazione utenti.
La farm virtuale ha unicamente scopo di test e verrà chiusa al termine dei test. In alcuni casi l'ambiente può essere mantenuto e utilizzato in data successiva per il test degli aggiornamenti software.

L'illustrazione seguente mostra un'architettura aggiornata, più adatta a una farm di produzione.

Figura 2. Architettura aggiornata

Controllare un'architettura virtuale

Nell'architettura aggiornata, il presupposto principale è che si desidera mantenere otto server di virtualizzazione che forniscono servizi di base. Le modifiche nell'illustrazione precedente riflettono tale presupposto e includono le considerazioni seguenti:

Le dimensioni stimate del database del contenuto sono di 1 terabyte (TB).
L'obiettivo è di assicurare disponibilità elevata a tutti i server della farm e di ottenere le massime prestazioni in tutta l'infrastruttura.
I server database della farm sono server fisici che possono essere raggruppati in cluster o dei quali è possibile impostare il mirroring per supportare una disponibilità elevata. Ogni server ha 8 processori core, 16 GB di RAM e utilizza unità locali per ridurre la latenza.

Analisi degli host di virtualizzazione

Le tabelle seguenti (HOST-1 aggiornato e HOST-2 aggiornato) riportano un'analisi di ogni host di virtualizzazione in base a criteri di memoria, processori e scalabilità. L'analisi degli host è seguita da un'analisi della progettazione.

HOST-1 aggiornato

Criteri	Analisi
Memoria	Riservando 2 GB di RAM per il sistema operativo host e basandosi sui requisiti di RAM previsti, si può stimare una disponibilità rimanente di 2 GB di RAM per utilizzo futuro.
Processori	Il mapping tra processori logici e virtuali è di 8:10 (1:1,25), con una leggera oversubscription.
Scalabilità	È disponibile una quantità marginale di memoria per aumentare l'allocazione alle macchine virtuali. In base alla quantità di memoria e al rapporto tra processori logici e virtuali, l'host non ha capacità sufficienti a consentire l'aggiunta di un'ulteriore macchina virtuale.

HOST-2 aggiornato

Criteri	Analisi
Memoria	Riservando 2 GB di RAM per il sistema operativo host e basandosi sui requisiti di RAM previsti, si può stimare una disponibilità rimanente di 4 GB di RAM per utilizzo futuro.
Processori	Il mapping tra processori logici e virtuali è di 8:12 (1:1,50), con una oversubscription del 50 percento.
Scalabilità	È disponibile una quantità marginale di memoria per aumentare l'allocazione alle macchine virtuali. In base alla quantità di memoria e al rapporto tra processori logici e virtuali, l'host non ha capacità sufficienti a consentire l'aggiunta di un'ulteriore macchina virtuale.

Analisi della progettazione

Ogni macchina virtuale utilizza una configurazione a tre unità, dimensionata in base alle procedure consigliate per SharePoint Server. Queste unità sono in genere configurate come segue:
- Unità C (50 GB) per l'installazione di Windows
- Unità D (50 GB) per i file di SharePoint Server 2010
- Unità E (300 GB) per il contenuto Web e i file registro
Ogni server Web front-end è configurato con quattro processori virtuali (4xVP) e 8 GB di RAM. Questa è la configurazione minima consigliata per un ambiente di produzione.
Il numero di server Web front-end viene portato a quattro per supportare un clustering efficace e una disponibilità elevata. Questa configurazione a quattro server è particolarmente indicata per l'installazione di aggiornamenti software, perché vi saranno sempre due server disponibili durante l'installazione degli aggiornamenti.
I due server applicazioni (App-1, App-2) assicurano una disponibilità elevata. App-1 ospita Amministrazione centrale, il componente di ricerca per indicizzazione e l'indice passivo per il componente di query di ricerca. Il numero di processori e la quantità di memoria sono basati sulle dimensioni stimate del database del contenuto.

App-2 è un server di query di ricerca dedicato. Contiene inoltre una copia di Amministrazione centrale. Il numero di processori e la quantità di memoria sono basati sulle dimensioni stimate del database del contenuto.
Per garantire una disponibilità elevata, Amministrazione centrale è inoltre installata in un server Web front-end in un altro host.
I server database sono server fisici raggruppati in cluster o con mirroring per assicurare una disponibilità elevata. Questo spostamento su server fisici ha il vantaggio di incrementare la capacità degli host di virtualizzazione per i server virtuali della farm e di migliorare le prestazioni complessive dei database.

Nota

Come accennato in precedenza in questo articolo, la decisione di virtualizzare o meno i server database è una decisione complessa, che richiede una pianificazione e un testing approfonditi.
Per quanto riguarda la connessione di rete, entrambi gli host di virtualizzazione sono configurati con due schede di rete fisiche distinte da 1 gigabit. È consigliabile fare in modo che il traffico dati degli host di virtualizzazione e delle macchine virtuali sia mantenuto separato, per migliorare le prestazioni e assicurare una certa ridondanza delle schede di rete.
Ogni host di virtualizzazione utilizza una LAN virtuale (VLAN), che può offrire i vantaggi seguenti: separazione della rete, sicurezza migliorata e prestazioni più elevate.

L'architettura virtuale e fisica aggiornata è significativamente migliorata e potrebbe essere distribuita in un ambiente di produzione. È tuttavia importante notare che, con questa configurazione, le risorse disponibili per gli host di virtualizzazione non supportano la scalabilità della farm. Non sono inoltre in grado di supportare la migrazione di un server della farm da un host a un altro in caso di necessità.

Realisticamente, se si desidera distribuire la farm di esempio in produzione, è consigliabile prendere in considerazione gli aggiornamenti seguenti:

Incrementare la capacità degli host di virtualizzazione utilizzando un computer con 16 processori core e 48 o 64 gigabyte di RAM.
Aggiungere uno o più host di virtualizzazione.

Per conseguire il livello ottimale di disponibilità elevata, prendere in considerazione le opzioni aggiuntive illustrate nella sezione seguente.

Opzioni aggiuntive per il miglioramento dell'architettura

Nella sezione precedente erano suggerite opzioni per aggiornare il modello. Esistono naturalmente altre opzioni per ottenere migliori prestazioni e disponibilità elevata. Valide alternative sono costituite dall'implementazione della scalabilità orizzontale per l'ambiente degli host di virtualizzazione o della scalabilità verticale per gli host di virtualizzazione, sebbene il costo permanga un problema. La strategia di virtualizzazione dell'organizzazione aiuterà a definire l'approccio migliore.

Suggerimento

In termini di costo, è generalmente più conveniente acquistare un server con più capacità di quanta ne occorra nel breve termine, piuttosto che aggiornare un server per aumentarne la capacità. Ciò è particolarmente vero nel caso degli aggiornamenti della memoria, dove in genere è necessario gettare via i moduli di memoria esistenti e acquistare una serie completa di nuovi moduli per aggiornare la memoria.

È possibile ottenere miglioramenti delle prestazioni con le opzioni seguenti:

Distribuire o acquistare server con processori con supporto SLAT (Second-Level Address Translation). Nei processori Intel tale caratteristica è detta NPT (Nested Page Tables) ed è disponibile nei processori serie Nehalem 55xx. Per AMD, questa caratteristica è detta EPT (Enhanced Page Tables).
Distribuire o acquistare server che adottano il Core Parking della CPU, una funzionalità grazie alla quale Hyper-V utilizza, durante l'esecuzione, il numero minimo di processori core necessari a supportare il carico di lavoro richiesto..
Esaminare le possibilità offerte dalle tecnologie TCP Chimney Offload, Virtual Machine Queue (VMQ) e frame Jumbo. Queste funzionalità migliorano le prestazioni di rete e riducono l'utilizzo della CPU, aumentando in tal modo la capacità complessiva del sistema.
Prendere in considerazione l'implementazione del supporto dei frame Jumbo per velocizzare le prestazioni di rete durante il trasferimento di grandi quantità di dati. Sarà tuttavia necessario effettuare test approfonditi, poiché i frame Jumbo non funzionano in tutti gli ambienti.
Prendere in considerazione il teaming delle schede di rete. Questa funzionalità può migliorare le prestazioni di rete e implementare capacità di failover per le schede fisiche di rete.

Importante

Il teaming delle schede di rete è una soluzione di terze parti ed è supportata solo dal fornitore. Per ulteriori informazioni, vedere Criteri del Supporto tecnico Microsoft per il teaming delle schede di rete con Hyper-V (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=194749&clcid=0x410).

Per assicurare una disponibilità elevata per l'ambiente virtuale, prendere in considerazione l'implementazione del clustering di failover di Windows Server 2008 R2 e della Live Migration di Hyper-V, come segue:

L'ambito del clustering di failover può includere gli host di virtualizzazione e le macchine virtuali di ogni host. In caso di errore inatteso di un host di virtualizzazione, viene eseguito il failover automatico delle macchine virtuali su un altro host di virtualizzazione.
Live Migration è una soluzione per i tempi di inattività pianificati. È possibile eseguire la migrazione in un altro server di macchine virtuali in esecuzione (senza tempi di inattività), arrestare il server fisico ed eseguire la manutenzione. Al termine della manutenzione del server, utilizzare Live Migration per riportare le macchine virtuali nel server fisico originale.

Per ulteriori informazioni, vedere Hyper-V: Utilizzo di Hyper-V e del clustering di failover (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=187967&clcid=0x410) e Hyper-V: Utilizzare Live Migration con Volumi condivisi cluster in Windows Server 2008 R2 (https://go.microsoft.com/fwlink/?linkid=188009&clcid=0x410).