Guida alle considerazioni di progettazione dell'infrastruttura di virtualizzazione

Articolo
10/16/2015

Destinatari della guida. Professionisti IT di organizzazioni medio-grandi responsabili della progettazione di un'infrastruttura di virtualizzazione in grado di supportare molte macchine virtuali. Nel resto di questo documento queste persone saranno denominate amministratori dell'infrastruttura. Le persone che amministrano le macchine virtuali ospitate nell'infrastruttura sono definite amministratori di macchine virtuali, ma non rientrano tra i destinatari di questo documento. È possibile che all'interno dell'organizzazione una persona sia responsabile di entrambi i ruoli.

Finalità della guida. È possibile usare questa guida per comprendere la modalità di progettazione di un'infrastruttura di virtualizzazione in grado di ospitare molte macchine virtuali nell'organizzazione. In questo documento la raccolta di server e hypervisor e l'hardware di archiviazione e di rete usato per ospitare le macchine virtuali in un'organizzazione rientrano nella definizione di infrastruttura di virtualizzazione. L'immagine seguente mostra un esempio di infrastruttura di virtualizzazione.

Infrastruttura di virtualizzazione

Figura 1:Esempio di infrastruttura di virtualizzazione

Nota: Ogni diagramma illustrato in questo documento è riportato in una scheda distinta del documento contenente i diagrammi per la Guida alle considerazioni di progettazione dell'infrastruttura di virtualizzazione, che è possibile scaricare facendo clic sul nome della figura nella didascalia di ogni tabella.

Anche se tutte le infrastrutture di virtualizzazione includono server per l'archiviazione e l'hosting di macchine virtuali, oltre alle reti di connessione, la progettazione dell'infrastruttura di virtualizzazione di ogni organizzazione sarà probabilmente diversa dall'esempio illustrato nella figura 1, a causa della diversità dei requisiti.

Questa guida illustra in dettaglio una serie di passaggi e attività che è possibile seguire per facilitare la progettazione di un'infrastruttura di virtualizzazione che soddisfi i requisiti specifici della propria organizzazione. In tutti i passaggi e tutte le attività vengono presentate le tecnologie pertinenti e le opzioni delle funzionalità disponibili per soddisfare i requisiti a livello di qualità funzionale e del servizio (ad esempio disponibilità, scalabilità, prestazioni, gestibilità e sicurezza).

Anche se questo documento può essere utile per progettare un'infrastruttura di virtualizzazione gestibile, non include opzioni e considerazioni sulla progettazione per la gestione e il funzionamento dell'infrastruttura di virtualizzazione con un prodotto come Microsoft System Center 2012 o System Center 2012 R2. Per altre informazioni, vedere System Center 2012 nella libreria TechNet.

Questa guida descrive la progettazione di un'infrastruttura di virtualizzazione con Windows Server 2012 R2 e Windows Server 2012 e hardware indipendente dal fornitore. Alcune funzionalità descritte in questo documento sono specifiche di Windows Server 2012 R2 e sono indicate chiaramente nel documento.

Presupposti: avere esperienza nella distribuzione di Hyper-V, macchine virtuali, reti virtuali, servizi file di Windows Server e Clustering di failover, oltre ad esperienza nella distribuzione di server fisici, risorse di archiviazione e apparecchiature di rete.

Risorse aggiuntive

Prima di progettare un'infrastruttura di virtualizzazione, potrebbero essere utili le informazioni disponibili nei documenti seguenti:

Entrambi i documenti forniscono concetti di base osservati in diverse progettazioni di infrastrutture di virtualizzazione, che possono servire come base per la progettazione di qualsiasi infrastruttura di virtualizzazione.

Commenti e suggerimenti: per fornire commenti e suggerimenti su questo documento, inviare un messaggio di posta elettronica all'indirizzo virtua@microsoft.com.

Panoramica delle considerazioni sulla progettazione

Nella parte restante di questo documento è disponibile un set di passaggi e attività che è possibile seguire per progettare un'infrastruttura di virtualizzazione che meglio soddisfi le proprie esigenze. I passaggi sono presentati in una sequenza ordinata. Le considerazioni sulla progettazione apprese in passaggi successivi potrebbero richiedere una modifica delle decisioni prese in passaggi precedenti, a causa di possibili conflitti. In tutto il documento si tenterà tuttavia di avvertire l'utente dei potenziali conflitti di progettazione.

Per ottenere la progettazione che meglio soddisfi le proprie esigenze, si dovranno eseguire i passaggi tutte le volte che sarà necessario per integrare tutte le considerazioni illustrate nel documento.

Passaggio 1. Determinare i requisiti a livello di risorse delle macchine virtuali

Passaggio 2: Pianificare la configurazione delle macchine virtuali

Passaggio 3: Pianificare i gruppi host di virtualizzazione dei server

Passaggio 4. Pianificare gli host di virtualizzazione dei server

Passaggio 5. Pianificare i concetti relativi all'architettura dell'infrastruttura di virtualizzazione

Passaggio 6. Pianificare le caratteristiche relative alla capacità iniziale

Passaggio 1. Determinare i requisiti a livello di risorse delle macchine virtuali

Il primo passaggio della progettazione di un'infrastruttura di virtualizzazione consiste nel determinare i requisiti delle macchine virtuali ospitate nell'infrastruttura. L'infrastruttura dovrà includere l'hardware necessario per soddisfare tali requisiti. I requisiti di risorse delle macchine virtuali sono stabiliti dai sistemi operativi e dalle applicazioni in esecuzione nelle macchine virtuali. Nel resto di questo documento la combinazione di sistema operativo e applicazioni in esecuzione in una macchina virtuale è definita carico di lavoro. Le attività in questo passaggio facilitano la definizione dei requisiti di risorse per i carichi di lavoro.

Suggerimento: invece di valutare i requisiti di risorse dei carichi di lavoro esistenti e progettare quindi un'infrastruttura di virtualizzazione in grado di supportare ogni carico di lavoro, è possibile scegliere di progettare un'infrastruttura di virtualizzazione che possa soddisfare le esigenze dei carichi di lavoro più comuni, valutando quindi separatamente i carichi di lavoro con esigenze specifiche.

Questi tipi di infrastrutture di virtualizzazione sono ad esempio offerti da provider di cloud pubblici, come Microsoft Azure (Azure). Per altre informazioni, vedere Dimensioni delle macchine virtuali e dei servizi cloud per Azure.

I provider di cloud pubblici offrono in genere una scelta di configurazioni di macchine virtuali in grado di soddisfare le esigenze della maggior parte dei carichi di lavoro. Se si sceglie di adottare questo approccio, è possibile andare direttamente al Passaggio 2: Pianificare la configurazione delle macchine virtuali di questo documento. Di seguito sono elencati altri vantaggi derivanti dall'uso di questo approccio:

Quando si decide di eseguire la migrazione di alcune macchine virtuali locali a un provider di cloud pubblico, se i tipi di configurazione di queste macchine virtuali sono simili a quelli del provider pubblico, la migrazione risulterà più facile rispetto ai casi in cui i tipi di configurazione sono diversi.
Potrebbe infatti essere più facile prevedere i requisiti relativi alla capacità e abilitare una funzionalità di provisioning self-service per l'infrastruttura di virtualizzazione. Questo significa che gli amministratori di macchine virtuali dell'organizzazione possono effettuare automaticamente il provisioning di nuove macchine virtuali senza coinvolgere gli amministratori dell'infrastruttura.

Attività 1: Determinare i requisiti a livello di risorse dei carichi di lavoro

Ogni carico di lavoro presenta i requisiti di risorse seguenti. È consigliabile rispondere innanzitutto alle domande elencate di seguito per ogni carico di lavoro.

Processore: qual è la velocità o l'architettura (Intel o AMD) del processore o il numero di processori richiesti?
Rete: qual è la larghezza di banda di rete, espressa in gigabit al secondo (Gbps), richiesta per il traffico in entrata e in uscita? Qual è la latenza di rete massima tollerata dal carico di lavoro per consentirne il corretto funzionamento?
Archiviazione: quanti gigabyte (GB) di spazio di archiviazione sono richiesti per i file dell'applicazione e del sistema operativo del carico di lavoro? Quanti GB di spazio di archiviazione sono richiesti per i dati del carico di lavoro? Quante operazioni di input/output al secondo (IOPS) sono richieste per l'archiviazione del carico di lavoro?
Memoria: qual è la quantità di memoria, espressa in gigabyte (GB), richiesta dal carico di lavoro? Il carico di lavoro è compatibile con NUMA?

Oltre a comprendere i requisiti di risorse precedenti, è anche importante determinare quanto segue:

Se i requisiti di risorse sono minimi o consigliati.
Qual è il requisito massimo e medio per ognuno dei requisiti hardware su base oraria, giornaliera, settimanale, mensile o annuale.
Numero di minuti di inattività mensile accettabili per il carico di lavoro e i relativi dati. Nel determinare questo valore, considerare quanto segue:
- Il carico di lavoro viene eseguito su una sola macchina virtuale oppure su una raccolta di macchine virtuali che agiscono come una sola, ad esempio una raccolta di server di rete con carico bilanciato che eseguono tutti lo stesso carico di lavoro? Se si usa una raccolta di server, è necessario specificare chiaramente se il tempo di inattività espresso si applica a ogni server o a tutti i server della raccolta oppure a livello di raccolta.
- Ore lavorative e non lavorative. Ad esempio, se nessuno userà il carico di lavoro tra le 21.00 e le 6.00, ma è di fondamentale importanza che sia disponibile il più possibile tra le 6.00 e le 21.00, con una quantità accettabile di tempo di inattività mensile solo di dieci minuti, sarà necessario specificare questo requisito.
Quantità accettabile di dati persi nel caso di un errore imprevisto dell'infrastruttura virtuale. Questo valore viene espresso in minuti, perché le strategie di replica dell'infrastruttura virtuale sono in genere basate sul tempo. Anche se l'assenza di perdita dei dati viene spesso espressa come requisito, si consideri che ottenerla comporta spesso un costo elevato e può anche causare una riduzione delle prestazioni.
Se i file del carico di lavoro e/o i relativi dati devono essere crittografati su disco e se tali dati devono essere crittografati tra le macchine virtuali e gli utenti finali.

Per determinare i requisiti di risorse precedenti, sono disponibili le opzioni elencate di seguito.

Opzione	Vantaggi	Svantaggi
Valutare e registrare manualmente l'utilizzo delle risorse.	Capacità di creare report per qualsiasi elemento scelto.	Può richiedere un notevole impegno manuale.
Per valutare e registrare automaticamente l'utilizzo delle risorse, usare Microsoft Assessment and Planning Toolkit.	Crea una varietà di report sull'utilizzo delle risorse. Non richiede l'installazione di un agente nel carico di lavoro.	I report possono fornire o meno tutti i dati richiesti.

Nota: se si sceglie di determinare manualmente i requisiti di risorse, è possibile scaricare i fogli di lavoro per la Guida alle considerazioni di progettazione dell'infrastruttura di virtualizzazione e immettere le informazioni nel foglio di lavoro Workload resource req. Questa guida fa riferimento a fogli di lavoro specifici inclusi in tale documento.

Attività 2: Definire le caratterizzazioni del carico di lavoro

È possibile definire un numero illimitato di caratterizzazioni del carico di lavoro nel proprio ambiente. Gli esempi seguenti sono stati scelti perché ognuno richiede una diversa configurazione di componenti dell'infrastruttura di virtualizzazione, che verrà descritta in maggiore dettaglio nei passaggi successivi.

Senza stato: scrivono informazioni non univoche sul relativo disco rigido, dopo il provisioning iniziale e l'assegnazione di nomi di computer e indirizzi di rete univoci. Possono tuttavia scrivere informazioni univoche in risorse di archiviazione distinte, come un database. I carichi di lavoro senza stato sono ideali per l'esecuzione in una infrastruttura di virtualizzazione, perché è possibile creare un'immagine "master" per la macchina virtuale. Questa immagine può essere facilmente copiata e avviata nell'infrastruttura di virtualizzazione per aggiungere scalabilità al carico di lavoro o per sostituire rapidamente una macchina virtuale non disponibile nel caso di errore di un host di virtualizzazione. Un esempio di carico di lavoro senza stato è un server Web che esegue un'applicazione Web front-end.
Con stato: scrivono informazioni univoche sul relativo disco rigido, dopo il provisioning iniziale e l'assegnazione di nomi di computer e indirizzi di rete univoci. Possono anche scrivere informazioni univoche in risorse di archiviazione separate, ad esempio un database. I carichi di lavoro con stato richiedono strategie di provisioning e scalabilità più complesse rispetto ai carichi di lavoro senza stato. Le strategie a disponibilità elevata per i carichi di lavoro con stato possono richiedere uno stato condiviso con altre macchine virtuali. Un esempio di carico di lavoro con stato è il motore di database di SQL Server.
Con stato condiviso: carichi di lavoro con stato che richiedono uno stato condiviso con altre macchine virtuali. Questi carichi di lavoro usano spesso la funzionalità Clustering di failover di Windows Server per ottenere la disponibilità elevata, che richiede l'accesso a risorse di archiviazione condivise. Un esempio di carico di lavoro con stato condiviso è Virtual Machine Manager di Microsoft System Center.
Altro: caratterizza i carichi di lavoro che non possono essere eseguiti affatto o non vengono eseguiti in modo ottimale in un'infrastruttura di virtualizzazione. Questi carichi di lavoro si distinguono per il fatto che richiedono:
- Accesso alle periferiche fisiche. Un esempio di tale applicazione è un carico di lavoro di telefonia che comunica con una scheda di rete telefonica in un host fisico.
- Requisiti di risorse molto più elevati rispetto alla maggior parte degli altri carichi di lavoro. Ne è un esempio un'applicazione in tempo reale che richiede una latenza inferiore a un millisecondo tra i livelli applicazione.
Queste applicazioni possono essere eseguite o meno nell'infrastruttura di virtualizzazione o richiedere hardware molto specifico o una configurazione non condivisa dalla maggior parte degli altri carichi di lavoro.

Nota: è possibile definire le caratterizzazioni dei carichi di lavoro nel foglio di lavoro Settings e quindi selezionare la caratterizzazione appropriata per ogni carico di lavoro nel foglio di lavoro Workload resource req.

Passaggio 2: Pianificare la configurazione delle macchine virtuali

In questo passaggio si definiranno i tipi di macchine virtuali necessari per soddisfare i requisiti di risorse e le caratterizzazioni dei carichi di lavoro definiti nel passaggio 1.

Attività 1: Definire la configurazione di calcolo

In questa attività si determinerà la quantità di memoria e i processori richiesti per ogni macchina virtuale.

Attività 1a: Definire il tipo di generazione delle macchine virtuali

Con Windows Server 2012 R2 sono state introdotte macchine virtuali di seconda generazione. Le macchine virtuali di seconda generazione supportano hardware e funzionalità di virtualizzazione non supportati nelle macchine virtuali di prima generazione. È importante prendere le decisioni giuste in funzione dei propri requisiti, perché dopo la creazione di una macchina virtuale non sarà più possibile modificarne il tipo.

Una macchina virtuale di seconda generazione offre le nuove funzionalità seguenti:

Avvio PXE tramite una scheda di rete standard
Avvio da un disco rigido virtuale SCSI
Avvio da un DVD virtuale SCSI
Avvio protetto (abilitato per impostazione predefinita)
Supporto del firmware UEFI

Le macchine virtuali di seconda generazione supportano i sistemi operativi guest seguenti:

Windows Server 2012 R2
Windows Server 2012
Versioni a 64 bit di Windows 8.1
Versioni a 64 bit di Windows 8
Versioni specifiche di Linux. Per un elenco di distribuzioni e versioni che supportano macchine virtuali di seconda generazione, vedere l'articolo relativo alle macchine virtuali Linux in Hyper-V.

La tabella seguente illustra i vantaggi e gli svantaggi delle macchine virtuali di prima e di seconda generazione.

Opzione	Vantaggi	Svantaggi
Prima generazione	Supporta tutti i sistemi operativi guest Hyper-V supportati. Fornisce la compatibilità con le macchine virtuali di Azure. Supporta le versioni precedenti di Hyper-V.	Nessun accesso alle nuove funzionalità delle macchine virtuali.
Seconda generazione	Supporta nuove funzionalità. Fornisce un leggero miglioramento nei tempi di avvio e di installazione guest. Usa dispositivi SCSI o una scheda di rete standard per avviare la macchina virtuale. Impedisce l'esecuzione di firmware, sistemi operativi o driver UEFI non autorizzati quando è abilitato l'avvio protetto.	Supporto limitato per sistemi operativi guest. Non compatibile con le macchine virtuali di Azure. Nessun supporto per RemoteFX. Nessun supporto per dischi floppy virtuali.

Importante: le macchine virtuali Linux di seconda generazione non supportano l'avvio protetto. Quando si crea una macchina virtuale e si prevede di installare Linux, è necessario disattivare l'avvio protetto nelle impostazioni della macchina virtuale.

Altre informazioni:

Panoramica delle macchine virtuali di seconda generazione

Attività 1b: Definire la memoria

È consigliabile pianificare le dimensioni della memoria della macchina virtuale, come avviene in genere per le applicazioni server in un computer fisico. Dovrebbe ragionevolmente gestire il carico previsto in ore normali e di punta. Una quantità di memoria insufficiente può aumentare significativamente i tempi di risposta e l'utilizzo di CPU o I/O.

Memoria statica o memoria dinamica

Memoria statica: è la quantità di memoria assegnata alla macchina virtuale. Viene sempre allocata all'avvio della macchina virtuale e non viene modificata durante l'esecuzione della macchina virtuale. Tutta la memoria viene assegnata alla macchina virtuale durante l'avvio e la quantità inutilizzata dalla macchina virtuale non è disponibile per le altre macchine virtuali. Se nell'host non è disponibile memoria sufficiente da allocare alla macchina virtuale al momento dell'avvio, la macchina virtuale non verrà avviata.

La memoria statica è appropriata per i carichi di lavoro a elevato utilizzo di memoria e per quelli con sistemi di gestione della memoria integrati, come SQL Server. Questi tipi di carichi di lavoro offrono prestazioni migliori con la memoria statica.

Nota: non esiste un'impostazione per abilitare la memoria statica. La memoria statica viene abilitata automaticamente quando non è abilitata l'impostazione Memoria dinamica.

Memoria dinamica: consente un uso migliore della memoria fisica in un sistema mediante il bilanciamento della memoria fisica totale tra più macchine virtuali, allocando una maggiore quantità di memoria alle macchine virtuali attive e rimuovendola da quelle meno usate. Questo approccio può comportare rapporti di consolidamento più elevati, specialmente in ambienti dinamici come nei server VDI (Virtual Desktop Infrastructure) o Web.

Quando si usa la memoria statica, se a una macchina virtuale vengono assegnati 10 GB di memoria ma ne usa solo 3 GB, i rimanenti 7 GB di memoria non saranno disponibili per l'uso da parte di altre macchine virtuali. Quando per una macchina virtuale è abilitata la memoria dinamica, verrà usata solo la quantità di memoria necessaria, ma non inferiore alla RAM minima configurata. In questo modo viene liberata più memoria per le altre macchine virtuali.

La tabella seguente illustra i vantaggi e gli svantaggi della memoria statica e della memoria dinamica.

Opzione	Vantaggi	Svantaggi
Memoria statica	Fornisce alle macchine virtuali la memoria configurata disponibile, in qualsiasi momento. Offre migliori prestazioni. Può essere usata con NUMA virtuale.	La memoria non usata da una macchina virtuale non può essere allocata a un'altra macchina virtuale. Le macchine virtuali non verranno avviate se la memoria disponibile è insufficiente.
Memoria dinamica	Fornisce una migliore densità di macchine virtuali nel caso di esecuzione di carichi di lavoro inattivi o a basso carico. Consente l'allocazione della memoria non in uso, in modo che possa essere usata da altre macchine virtuali.	È possibile che si verifichi l'oversubscription della memoria configurata. La gestione delle allocazioni di memoria richiede un sovraccarico aggiuntivo. Non è compatibile con NUMA virtuale. Non è compatibile con i carichi di lavoro che implementano propri sistemi di gestione della memoria.

Di seguito sono illustrate le impostazioni di configurazione della memoria:

RAM di avvio: specifica la memoria richiesta per avviare la macchina virtuale. Il valore deve essere sufficientemente alto da consentire l'avvio del sistema operativo guest, ma il più basso possibile per consentire l'uso ottimale della memoria e rapporti di consolidamento potenzialmente più elevati.
RAM minima: specifica la quantità minima di memoria che deve essere allocata alla macchina virtuale dopo l'avvio. È possibile impostare un valore minimo di 32 MB fino a un valore massimo pari a quello della RAM di avvio. Questa impostazione è disponibile solo quando è abilitata l'opzione Memoria dinamica.
RAM massima: specifica la quantità massima di memoria che può essere usata dalla macchina virtuale. È possibile impostare un valore minimo pari a quello della RAM di avvio fino a un massimo di 1 TB. Tuttavia, una macchina virtuale può usare solo la quantità massima di memoria supportata dal sistema operativo guest. Se ad esempio si specifica un valore di 64 GB per una macchina virtuale che esegue un sistema operativo guest che supporta un massimo di 32 GB, la macchina virtuale non potrà usare più di 32 GB. Questa impostazione è disponibile solo quando è abilitata l'opzione Memoria dinamica.
Peso memoria: consente a Hyper-V di determinare come distribuire la memoria tra le macchine virtuali se la memoria fisica disponibile nell'host non è sufficiente per fornire a ogni macchina virtuale la quantità di memoria richiesta. Le macchine virtuali con un peso di memoria superiore hanno la precedenza rispetto a quelle con pesi di memoria inferiori.

Note:

le funzionalità Memoria dinamica e NUMA virtuale non possono essere usate insieme. Una macchina virtuale con la memoria dinamica abilitata ha in effetti un solo nodo NUMA virtuale e nessuna topologia NUMA viene presentata alla macchina virtuale, indipendentemente dalle impostazioni di NUMA virtuale.
Quando si installa o si aggiorna il sistema operativo di una macchina virtuale, la quantità di memoria disponibile per la macchina virtuale durante il processo di installazione o aggiornamento è il valore specificato come RAM di avvio. Anche se è stata configurata la memoria dinamica per la macchina virtuale, questa userà solo la quantità di memoria configurata nell'impostazione RAM di avvio. Verificare che il valore di RAM di avvio soddisfi i requisiti di memoria minimi del sistema operativo durante le procedure di installazione o aggiornamento.
Il sistema operativo guest in esecuzione nella macchina virtuale deve supportare la memoria dinamica.
Applicazioni di database complesse, come SQL Server o Exchange Server, implementano propri sistemi di gestione della memoria. Per determinare se il carico di lavoro è compatibile con la memoria dinamica, consultare la relativa documentazione.

Altre informazioni:

Panoramica della memoria dinamica

Attività 1c: Definire il processore

Per configurare le macchine virtuali, è necessario definire le impostazioni di configurazione seguenti:

Determinare il numero di processori richiesti per ogni macchina virtuale. Spesso è lo stesso numero di processori richiesto per il carico di lavoro. Hyper-V supporta un massimo di 64 processori virtuali per ogni macchina virtuale.
Determinare il controllo delle risorse per ogni macchina virtuale. È possibile impostare limiti per assicurarsi che nessuna macchina virtuale possa monopolizzare le risorse del processore dell'host di virtualizzazione.
Definire una topologia NUMA. Per i carichi di lavoro ad alte prestazioni compatibili con NUMA è possibile specificare il numero massimo di processori, la quantità di memoria consentita in un singolo nodo NUMA virtuale e il numero massimo di nodi consentiti in un singolo socket del processore. Per altre informazioni, vedere Panoramica su NUMA virtuale Hyper-V.

Nota: NUMA virtuale e Memoria dinamica non possono essere usate contemporaneamente. Per decidere se usare la memoria dinamica o NUMA, rispondere alle domande elencate di seguito. Se la risposta a entrambe le domande è affermativa, abilitare NUMA virtuale e non abilitare la memoria dinamica.

Il carico di lavoro in esecuzione nella macchina virtuale è compatibile con NUMA?
La macchina virtuale utilizzerà più risorse, memoria o processori di quelli disponibili in un singolo nodo NUMA fisico?

Attività 1d: Definire i sistemi operativi supportati

È necessario verificare che il sistema operativo richiesto per il carico di lavoro sia supportato come sistema operativo guest. Considerare quanto segue:

Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 R2 and Windows 8.1
Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 and Windows 8
Per Linux: per informazioni sulle distribuzioni Linux supportate, vedere l'articolo relativo alle macchine virtuali Linux in Hyper-V.

Nota: Hyper-V include un pacchetto software per i sistemi operativi guest supportati che migliora le prestazioni e l'integrazione tra il computer fisico e la macchina virtuale. Questa raccolta di servizi e driver software è detta servizi di integrazione. Per prestazioni ottimali, è necessario che nelle macchine virtuali siano in esecuzione i servizi di integrazione più recenti.

Gestione licenze

È necessario verificare che i sistemi operativi guest dispongano della licenza corretta. Per informazioni sui requisiti specifici della licenza per l'esecuzione in un ambiente virtualizzato, vedere la documentazione del fornitore.

Attivazione automatica della macchina virtuale (AVMA) è una funzionalità introdotta in Windows Server 2012 R2. Con questa funzionalità, l'attivazione della macchina virtuale viene associata al server di virtualizzazione dotato di licenza e la macchina virtuale viene attivata all'avvio. In questo modo viene eliminata la necessità di immettere informazioni sulla licenza e di attivare ogni singola macchina virtuale.

L'attivazione automatica della macchina virtuale richiede che nell'host sia in esecuzione Windows Server 2012 R2 Datacenter e che il sistema operativo della macchina virtuale guest sia Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard o Windows Server 2012 R2 Essentials.

Nota: è necessario configurare l'attivazione automatica della macchina virtuale in ogni host distribuito nell'infrastruttura di virtualizzazione.

Altre informazioni:

Attivazione automatica delle macchine virtuali

Attività 1e: Definire la convenzione di denominazione delle macchine virtuali

È possibile che la strategia di denominazione dei computer esistente indichi la posizione fisica del computer o del server. Le macchine virtuali possono passare da un host all'altro, persino essere spostate da e in data center diversi, quindi è possibile che la strategia di denominazione esistente non sia più applicabile. Un aggiornamento alla convenzione di denominazione esistente, per indicare che il computer viene eseguito come macchina virtuale, può risultare utile per individuare la posizione in cui è in esecuzione la macchina virtuale.

Attività 2: Definire la configurazione della rete

Ogni macchina virtuale riceverà o invierà tipi di traffico di rete diversi. Ogni tipo di traffico di rete avrà requisiti di prestazioni, disponibilità e sicurezza diversi.

Le macchine virtuali di prima generazione possono avere un massimo di 12 schede di rete, 4 di tipo legacy e 8 virtuali. Le macchine virtuali di seconda generazione non supportano le schede di rete legacy, quindi il numero massimo di schede supportato è 8.

Attività 2a: Determinare i tipi di traffico di rete

Ogni macchina virtuale invierà e riceverà tipi di dati diversi, ad esempio:

Dati applicazione
Backup dei dati
Comunicazioni con computer client, server o servizi
Comunicazioni all'interno del cluster, se il carico di lavoro appartiene a un cluster di failover di macchine virtuali guest
Supporto tecnico
Archiviazione

Se esistono già reti dedicate a diversi tipi di traffico di rete, è possibile scegliere di usarle per questa attività. Se si definiscono nuove progettazioni di rete per supportare l'infrastruttura di virtualizzazione è possibile definire, per ogni macchina virtuale, quale tipo di traffico di rete sarà supportato.

Attività 2b: Definire le opzioni per le prestazioni del traffico di rete

Ogni tipo di traffico di rete presenta requisiti relativi a larghezza di banda massima e latenza minima. La tabella seguente illustra le strategie che è possibile usare per soddisfare i diversi requisiti per le prestazioni di rete.

Strategia	Vantaggi	Svantaggi
Separazione dei tipi di traffico per schede di rete fisiche diverse.	Separa il traffico in modo che non venga condiviso da altri tipi di traffico.	È necessario installare nell'host schede di rete fisiche distinte per ogni tipo di traffico di rete. È richiesto hardware aggiuntivo per ogni rete che richiede disponibilità elevata. Non è facilmente scalabile in presenza di un numero elevato di reti.
Gestione della larghezza di banda Hyper-V (QoS Hyper-V)	Fornisce QoS per il traffico di rete virtuale. Permette di imporre larghezze di banda minima e massima per un flusso di traffico identificato da un numero di porta del commutatore virtuale Hyper-V. Permette di configurare larghezze di banda minima e massima per ogni porta del commutatore virtuale Hyper-V tramite cmdlet di PowerShell o Strumentazione gestione Windows (WMI). Possono essere configurate più schede di rete virtuale in Hyper-V e può essere specificato il livello di QoS per ogni singola scheda di rete virtuale. Fornisce un supplemento ai criteri QoS per la rete fisica.	Non è possibile usare contemporaneamente QoS software e QoS hardware nella stessa scheda di rete. È necessario pianificare correttamente i criteri QoS per la rete e per Hyper-V, per evitare sovrapposizioni. Dopo avere impostato la modalità per la qualità del servizio per un commutatore virtuale, non sarà possibile modificarla. Non è possibile eseguire la migrazione di macchine virtuali a un host con un commutatore virtuale impostato per l'uso di una modalità QoS diversa. Se i valori assoluti configurati per una macchina virtuale non possono essere rispettati, la migrazione verrà bloccata.
SR-IOV	Fornisce la latenza di rete più bassa per una macchina virtuale. Fornisce l'I/O di rete più alto per una macchina virtuale. Riduce il sovraccarico della CPU richiesto per la rete virtuale.	Sono necessari un driver e una scheda di rete che supporta SR-IOV nell'host e in ogni macchina virtuale in cui è assegnata una funzione virtuale. Le schede di rete virtuale abilitate per SR-IOV non possono far parte del Gruppo NIC nell'host. Per la disponibilità elevata di rete è necessario installare due o più schede di rete SR-IOV nell'host e configurare Gruppo NIC nella macchina virtuale. SR-IOV deve essere usato solo da carichi di lavoro attendibili, perché il traffico ignora il commutatore Hyper-V e accede direttamente alla schede di rete fisica. La configurazione degli ACL delle porte del commutatore virtuale, QoS Hyper-V, RouterGuard e DHCPGuard, impedirà l'uso di SR-IOV. SR-IOV non è supportato per le macchine virtuali in esecuzione in Azure.
Receive-Side Scaling virtuale	Supporta Receive-Side Scaling virtuale, che consente alle macchine virtuali di distribuire il carico di elaborazione della rete su più processori virtuali (vCPU) per aumentare la velocità effettiva della rete nelle macchine virtuali. Offre la compatibilità con: Gruppo di schede di interfaccia di rete Migrazione in tempo reale NVGRE	Receive-Side Scaling virtuale richiede il supporto di Coda macchine virtuali nella scheda di rete fisica e la relativa abilitazione nell'host. Non è compatibile con una scheda di rete virtuale abilitata per SR-IOV. Nelle macchine virtuali deve essere in esecuzione Windows Server 2012 R2 o Windows 8.1. Disabilitata per impostazione predefinita se la scheda di Coda macchine virtuali è inferiore a 10 Gbps.
Frame jumbo	Consente il trasferimento di una maggiore quantità di dati con ogni transazione Ethernet, riducendo il numero di frame da trasmettere. Usata in genere per la comunicazione con le risorse di archiviazione, ma possono essere usati per qualsiasi tipo di comunicazione Riduce il sovraccarico per le macchine virtuali, le apparecchiature di rete e il server a cui vengono inviati i dati. Configurata per la comunicazione all'interno di un data center dove è possibile controllare le impostazioni dell'unità massima di trasmissione (MTU) in tutti gli hop.	Offre una probabilità leggermente inferiore di rilevamento errori. Ogni dispositivo di rete nel percorso deve supportare frame jumbo ed essere configurato con l'impostazione MTU uguale o maggiore. Usare il comando Ping per verificare le importazioni MTU end-to-end. Se un hop lungo il percorso non supporta frame jumbo o è configurato con un'impostazione MTU inferiore, i pacchetti verranno eliminati.

Attività 2c: Definire le opzioni per la disponibilità del traffico di rete

Gruppo NIC, funzionalità nota anche come bilanciamento del carico e failover, consente di inserire più schede di rete in un gruppo ai fini dell'aggregazione della larghezza di banda e del failover del traffico. In questo modo viene mantenuta la connettività in caso di errore di un componente di rete. La configurazione di Gruppo NIC viene solitamente effettuata nell'host e, quando si crea il commutatore virtuale, questo viene associato al gruppo di schede di rete.

I commutatori di rete distribuiti determinano la modalità del Gruppo NIC. Le impostazioni predefinite di Windows Server 2012 R2 dovrebbero essere sufficienti per la maggior parte delle implementazioni.

Nota: SR-IOV non è compatibile con Gruppo NIC. Per altre informazioni su SR-IOV, vedere Attività 2b: Definire le opzioni per le prestazioni del traffico di rete.

Altre informazioni:

Panoramica di Gruppo NIC

Attività 2d: Definire le opzioni per la sicurezza del traffico di rete

Ogni tipo di traffico di rete può avere requisiti di sicurezza diversi che riguardano, ad esempio, isolamento e crittografia. La tabella seguente illustra le strategie che è possibile usare per soddisfare i diversi requisiti di sicurezza.

Strategia	Vantaggi	Svantaggi
Separazione in diverse schede di rete.	Separa il traffico da altro traffico di rete.	Non è facilmente scalabile. Più sono le reti, più saranno le schede di rete che è necessario installare e gestire nell'host.
IPsec con Offload attività IPsec	Supporta l'offload IPsec per la crittografia del traffico di rete da e verso macchine virtuali che usano Hyper-V. Crittografa il traffico durante l'attraversamento della rete.	La configurazione è complessa. Può rendere più difficili la risoluzione dei problemi perché il traffico da e verso gli host e le macchine virtuali non può essere aperto. Maggiore utilizzo del processore quando le schede di rete fisiche nell'host non supportano l'offload IPsec.
Codifica VLAN	Già usata da molte società. Compatibile con criteri QoS. Supporta VLAN private. Supporta la modalità Trunk VLAN per le macchine virtuali. Riduce il numero di schede fisiche da installare nell'host.	Limitata a 4094 VLAN. È richiesta la configurazione per commutatori, host e macchine virtuali. Eventuali modifiche non corrette alle impostazioni di configurazione della VLAN possono causare problemi di rete specifici del server o a livello di sistema.
Virtualizzazione rete Hyper-V	Fornisce il posizionamento flessibile del carico di lavoro, inclusi isolamento rete e riutilizzo di indirizzi IP senza VLAN. Consente di spostare più facilmente i carichi di lavoro nel cloud. Supporta la migrazione in tempo reale tra subnet senza dover inserire un nuovo indirizzo IP nel nuovo server. Abilita l'uso di soluzioni di rete multi-tenant. Offre una progettazione della rete più semplice e un uso migliore delle risorse di rete e del server. La rigidità delle VLAN, con la dipendenza del posizionamento delle macchine virtuali da un'infrastruttura di rete fisica, provoca di solito provisioning eccessivo e sottoutilizzo.	La gestione di Virtualizzazione rete Hyper-V richiede System Center 2012 R2, Virtual Machine Manager o una soluzione di gestione non Microsoft. Per consentire la comunicazione all'esterno della rete virtuale è necessario un gateway di Virtualizzazione rete Hyper-V.
DHCPGuard	Impedisce alla macchina virtuale di effettuare offerte DHCP sulla rete virtuale. Configurata in base alle singole schede di rete virtuali. Non impedisce alla macchina virtuale di ricevere un indirizzo da un server DHCP.	Quando è abilitata, crea un impatto minimo sulle prestazioni.
RouterGuard	Blocca i pacchetti seguenti: ICMPv4 Tipo 5 (messaggio di reindirizzamento) ICMPv4 Tipo 9 (annuncio router) ICMPv6 Tipo 134 (annuncio router) ICMPv6 Tipo 137 (messaggio di reindirizzamento) Configurata in base alle singole schede di rete virtuali.	Quando è abilitata, crea un impatto minimo sulle prestazioni.

Decisioni di progettazione: è possibile scaricare i fogli di lavoro per la Guida alle considerazioni di progettazione dell'infrastruttura di virtualizzazione e modificare i dati di esempio nel foglio di lavoro Virtual machine configs. per acquisire le decisioni prese per tutte le attività precedenti di questo passaggio. Per le decisioni di progettazione successive, questo documento fa riferimento a fogli di lavoro specifici di questa guida in cui è possibile immettere i propri dati.

Attività 2e: Definire le schede di rete virtuali

Avendo a disposizione informazioni sui tipi di traffico richiesti per le macchine virtuali, oltre che sulle strategie relative a prestazioni, disponibilità e sicurezza per il traffico, è possibile determinare quante schede di rete virtuali saranno necessarie per ogni macchina virtuale.

Una scheda di rete virtuale è connessa a un commutatore virtuale. Esistono tre tipi di commutatori virtuali:

Commutatore virtuale esterno
Commutatore virtuale interno
Commutatore virtuale privato

Il commutatore virtuale esterno permette alla macchina virtuale di accedere alla rete fisica tramite la scheda di rete associata al commutatore virtuale a cui è connessa. Una scheda di rete fisica nell'host può essere associata solamente a un singolo commutatore esterno.

Se si prevede di assegnare il traffico della macchina virtuale a VLAN diverse, è necessario installare nell'host una scheda di rete che supporti le VLAN e assegnarla al commutatore virtuale. È possibile impostare l'ID VLAN per la macchina virtuale nelle proprietà della macchina virtuale stessa. L'ID VLAN impostato nel commutatore virtuale è quello che verrà assegnato alla scheda di rete virtuale assegnata al sistema operativo host.

Nota: se una macchina virtuale richiede l'accesso a più reti di quante siano le schede disponibili, è possibile abilitare la modalità Trunk VLAN per una scheda di rete della macchina virtuale tramite il cmdlet di Windows PowerShell Set-VMNetworkAdapterVlan.

Attività 2f: Definire la strategia per gli indirizzi IP

È necessario determinare come verranno assegnati gli indirizzi IP alle macchine virtuali. In caso contrario, potranno verificarsi conflitti di indirizzi IP, con un possibile impatto negativo su altre macchine virtuali e altri dispositivi fisici nella rete.

Inoltre, i server DHCP non autorizzati possono causare danni all'infrastruttura di rete ed essere particolarmente difficili da rilevare quando il server viene eseguito come macchina virtuale. Per proteggere la rete dai server DHCP non autorizzati eseguiti in una macchina virtuale, abilitare DHCPGuard nelle impostazioni delle macchine virtuali. DHCPGuard protegge la rete da macchine virtuali dannose che si presentano come server DHCP per sferrare attacchi man-in-the-middle.

Altre informazioni:

Panoramica di Dynamic Host Configuration Protocol (DHCP)

DHCPGuard

Panoramica di Gestione indirizzi IP

Attività 3: Definire la configurazione dell'archiviazione

Per determinare la configurazione dell'archiviazione, è necessario definire i tipi di dati che verranno archiviati dalle macchine virtuali e il tipo di archiviazione necessario.

Attività 3a: Definire i tipi di dati

La tabella seguente elenca i tipi di dati che una macchina virtuale potrebbe dover archiviare e la posizione in cui un determinato tipo di dati viene solitamente archiviato.

Tipo di dati	Posizione di archiviazione per il tipo di dati
File del sistema operativo	In un file del disco rigido virtuale archiviato nell'host di virtualizzazione. Considerazioni sull'archiviazione per l'host di virtualizzazione sono illustrati in maggiore dettaglio nel passaggio 4: Pianificare gli host di virtualizzazione dei server.
File di paging di Windows	Archiviati spesso nella stessa posizione dei file del sistema operativo.
File di programma dell'applicazione	Archiviati spesso nella stessa posizione dei file del sistema operativo.
Dati di configurazione dell'applicazione	Archiviati spesso nella stessa posizione dei file del sistema operativo.
Dati applicazione	Archiviati spesso separatamente dai file dell'applicazione e del sistema operativo. Se ad esempio l'applicazione è un'applicazione di database, i file di database vengono spesso archiviati in una soluzione di archiviazione a disponibilità elevata, efficiente e basata sulla rete, che si trova in una posizione separata da quella in cui sono archiviati i file di programma del sistema operativo o dell'applicazione.
Volumi condivisi cluster e dischi di controllo (obbligatori per il clustering di macchine virtuali guest)	Archiviati spesso separatamente dai file dell'applicazione e del sistema operativo. L'archiviazione su volumi condivisi cluster è la posizione in cui le applicazioni in cluster archiviano i dati in modo che siano disponibili per tutti i nodi del cluster. Un disco di controllo è un disco dell'archiviazione cluster progettato per contenere una copia del database di configurazione del cluster. Un cluster di failover dispone di un disco di controllo solo se tale funzionalità è stata specificata durante la configurazione quorum.
File di dump di arresto anomalo del sistema	Archiviati spesso nella stessa posizione dei file del sistema operativo.

Attività 3b: Definire i tipi di archiviazione

La tabella seguente elenca i tipi di archiviazione che potrebbero essere usati per i tipi di dati definiti nel passaggio 2, attività 2a precedente.

Tipo di archiviazione	Considerazioni
Disco IDE virtuale	Macchine virtuali di prima generazione: 2 controller IDE, ognuno dei quali può supportare un massimo di 2 dispositivi IDE per un massimo di 4 dispositivi IDE. Il disco di avvio deve essere collegato a uno dei dispositivi IDE come disco rigido virtuale o come disco fisico. Le macchine virtuali di seconda generazione non supportano i dispositivi IDE.
SCSI virtuale	Sono supportati 4 controller SCSI virtuali con ogni controller che supporta un massimo di 64 dispositivi, per un totale di 256 dispositivi SCSI. Poiché le macchine virtuali di seconda generazione supportano solo un'unità SCSI, tali macchine virtuali supportano dischi di avvio SCSI.
Iniziatore iSCSI nella macchina virtuale	Sfrutta i vantaggi dell'archiviazione su SAN senza dover installare schede Fibre Channel nell'host. Non può essere usato per il disco di avvio. Usare criteri di rete QoS per assicurare la disponibilità di una larghezza di banda appropriata per l'archiviazione e altro traffico di rete. Non è compatibile con la replica Hyper-V. Quando si usa un back-end di archiviazione SAN, usare le opzioni di replica SAN ricevute dal fornitore della risorsa di archiviazione.
Fibre Channel virtuale	Richiede una o più schede bus host Fibre Channel (HBA) o schede di rete convergenti Fibre Channel over Ethernet (FCoE) in ogni host che ospiterà macchine virtuali con schede Fibre Channel virtuale. È necessario che i driver HBA e FCoE supportino Fibre Channel virtuale. SAN abilitata per NPIV. Richiede una configurazione aggiuntiva per supportare la migrazione in tempo reale. Per altre informazioni sulla migrazione in tempo reale e su Fibre Channel virtuale, vedere Panoramica di Fibre Channel virtuale Hyper-V. Non è compatibile con la replica Hyper-V. Quando si usa l'archiviazione SAN, usare le opzioni di replica SAN ricevute dal fornitore della risorsa di archiviazione. Una macchina virtuale può avere un massimo di quattro porte virtuali. Non è possibile usare LUN Fibre Channel virtuale come supporto di avvio per la macchina virtuale.
SMB 3.0	Accesso ai file archiviati nelle condivisioni Server Message Block (SMB) 3.0 dall'interno della macchina virtuale.

Attività 3c: Definire il tipo e il formato di disco rigido virtuale

Se per l'archiviazione si usa il tipo disco rigido virtuale, è necessario selezionare innanzitutto il formato VHD che si userà, scegliendo tra le opzioni elencate nella tabella seguente.

Formato del disco	Vantaggi	Svantaggi
VHD	Supportato da tutte le versioni di Hyper-V. Supportato nelle implementazioni locali e in Azure.	Capacità di archiviazione massima: 2040 GB. Disco rigido virtuale massimo supportato in Azure: 1 TB. Non supportato dalle macchine virtuali di seconda generazione.
VHDX	Capacità di archiviazione massima: 64 terabyte (TB). Protezione dal danneggiamento dei dati in caso di interruzione dell'alimentazione. Migliore allineamento del formato di disco rigido virtuale per assicurare risultati migliori sui dischi con settori di grandi dimensioni. Disco virtuale con settore logico di 4 KB che consente il miglioramento delle prestazioni quando viene usato da applicazioni e carichi di lavoro progettati per settori di 4 KB. Può essere usato come risorsa di archiviazione condivisa per le macchine virtuali che richiedono Clustering di failover.	Non è attualmente supportato dalle macchine virtuali in Azure. Non può essere usato con versioni di Hyper-V precedenti a Windows Server 2012.
VHDX condiviso	Usato per l'archiviazione condivisa per cluster di macchine virtuali guest.	Richiede Windows Server 2012 R2 nell'host che esegue Hyper-V. I sistemi operativi guest supportati per i cluster guest che usano un disco rigido virtuale condiviso includono Windows Server 2012 R2 e Windows Server 2012. Per supportare Windows Server 2012 come sistema operativo guest, è necessario installare i servizi di integrazione di Windows Server 2012 R2 nella macchina virtuale guest. Le funzionalità seguenti non sono compatibili con VHDX condiviso: Replica Hyper-V. Ridimensionamento del disco rigido virtuale durante l'esecuzione di una qualsiasi delle macchine virtuali configurate. Migrazione di archiviazione in tempo reale Backup del Servizio Copia Shadow del volume a livello di host. I backup a livello di Guest devono essere eseguiti con gli stessi metodi che si userebbero per un cluster eseguito in server fisici. Checkpoint della macchina virtuale. QoS di archiviazione.

Selezionare quindi il tipo di disco che si userà, scegliendo tra le opzioni elencate nella tabella seguente.

Tipo di disco	Vantaggi	Svantaggi
Fisso	Meno soggetto a problemi di frammentazione di altri tipi di disco. Sovraccarico della CPU inferiore rispetto ad altri tipi di disco. Dopo la creazione del file VHD, la quantità di spazio disponibile su disco presenta meno problemi di altri tipi di disco. Supportato nelle implementazioni locali e in Azure.	Un disco rigido virtuale creato richiede la disponibilità di tutto lo spazio, anche se la macchina virtuale non lo usa completamente. Il disco rigido virtuale non verrà creato se lo spazio di archiviazione disponibile è insufficiente. Lo spazio non usato nel disco rigido virtuale non può essere allocato ad altri dischi rigidi virtuali.
Dinamico	Usa lo spazio su disco solo in base alle esigenze, anziché tutto lo spazio di cui è stato effettuato il provisioning.	Non è attualmente supportato in Azure, anche se è possibile convertire dischi dinamici in dischi fissi. Quando si usano dischi rigidi virtuali dinamici, è importante monitorare lo spazio disponibile su disco. Se non è disponibile spazio su disco sufficiente per consentire l'espansione di un disco rigido virtuale dinamico, la macchina virtuale passerà a uno stato critico sospeso. Il file disco rigido virtuale può diventare frammentato. Sovraccarico della CPU per le operazioni di lettura e scrittura leggermente più elevato rispetto al tipo di disco fisso.
Differenze	Se più dischi differenze usano lo stesso elemento padre, può usare meno spazio su disco.	Non è attualmente supportato in Azure. Le modifiche apportate a un disco padre possono causare un'incoerenza dei dati nel disco figlio. Sovraccarico della CPU per le operazioni di lettura e scrittura leggermente più elevato per carichi di lavoro a elevato utilizzo di I/O.

Quando si sceglie un formato e un tipo di file del disco rigido virtuale, considerare quanto segue:

Quando si usa il formato VHDX, è possibile usare un disco dinamico perché offre garanzie di resilienza, oltre a ottimizzazioni dello spazio che derivano dall'allocazione di spazio solo quando è necessario.
È anche possibile usare un disco fisso, indipendentemente dal formato, quando l'archiviazione sul volume di hosting non viene monitorata attivamente. Ciò assicura la disponibilità di spazio su disco sufficiente quando il file VHD viene espanso in fase di esecuzione.
I checkpoint (precedentemente noti come snapshot) di una macchina virtuale creano un disco rigido virtuale differenze per archiviare le operazioni di scrittura sui dischi. La disponibilità solo di pochi checkpoint può aumentare l'utilizzo della CPU per le operazioni di I/O di archiviazione, ma potrebbe non influire significativamente sulle prestazioni (ad eccezione dei carichi di lavoro del server a elevato utilizzo di I/O).

La disponibilità di una catena di checkpoint estesa influisce tuttavia in modo significativo sulle prestazioni, poiché la lettura dai dischi rigidi virtuali può richiedere la verifica dei blocchi necessari in molti dischi differenze. È importante limitare le catene di checkpoint per assicurare buone prestazioni di I/O del disco.

Attività 3d: Definire il tipo di archiviazione da usare per ogni tipo di dati

Dopo aver definito i tipi di dati e di archiviazione che verranno archiviati dalle macchine virtuali, è possibile determinare il tipo di archiviazione e il formato e il tipo del disco virtuale che verrà usato per ogni tipo di dati.

Attività 4: Definire la strategia di disponibilità delle macchine virtuali

Anche se gli amministratori dell'infrastruttura sono responsabili della disponibilità dell'infrastruttura, gli amministratori di macchine virtuali sono, in ultima analisi, responsabili della disponibilità delle proprie macchine virtuali. Di conseguenza, l'amministratore di macchine virtuali deve conoscere le funzionalità dell'infrastruttura per progettare la strategia di disponibilità appropriata per le macchine virtuali.

Le tabelle seguenti analizzano tre strategie di disponibilità per le macchine virtuali che eseguono carichi di lavoro con le caratterizzazioni definite nel passaggio 1, attività 2 precedente. In genere, l'amministratore dell'infrastruttura informa anticipatamente gli amministratori di macchine virtuali quando sono programmate attività relative a tempi di inattività pianificati per l'infrastruttura, in modo da permettere agli amministratori di macchine virtuali di pianificare di conseguenza. Le tre strategie di disponibilità sono:

Senza stato
Con stato
Con stato condiviso

Senza stato

Opzione	Considerazioni
Migrazione in tempo reale delle macchine virtuali a livello di host	Se è necessario disattivare un host per operazioni di manutenzione pianificata, è possibile eseguire la migrazione delle macchine virtuali in esecuzione a un host operativo, in modo da evitare tempi di inattività per le macchine virtuali. Per altre informazioni sulle considerazioni relative all'host, vedere il Attività 5: Definire la strategia di disponibilità degli host di virtualizzazione dei server di seguito. Se le macchine virtuali non vengono archiviate in una risorsa di archiviazione accessibile da entrambi gli host, è necessario spostare l'archiviazione delle macchine virtuali con una migrazione in tempo reale. In caso di errore imprevisto di un host, tutte le macchine virtuali in esecuzione nell'host vengono arrestate. È necessario avviare le macchine virtuali eseguendo lo stesso carico di lavoro in un altro host.
Cluster con carico bilanciato (tramite Bilanciamento carico di rete di Windows)	Richiede che l'amministratore delle macchine virtuali disponga di almeno due macchine virtuali che eseguono un carico di lavoro identico ospitato in host diversi. Bilanciamento carico di rete viene configurato nelle macchine virtuali dall'amministratore di macchine virtuali. Bilanciamento carico di rete richiede l'assegnazione di indirizzi IP statici alle schede di rete. L'assegnazione di indirizzi DHCP non è supportata. L'amministratore di macchine virtuali deve collaborare con l'amministratore dell'infrastruttura per ottenere gli indirizzi IP da usare per l'indirizzo IP virtuale di Bilanciamento carico di rete e per creare la voce DNS necessaria. Abilitare lo spoofing degli indirizzi MAC per la rete virtuale usata da Bilanciamento carico di rete nei guest. È possibile effettuare questa operazione nelle impostazioni della scheda di rete in ogni macchina virtuale che fa parte, come nodo, di un cluster di Bilanciamento carico di rete. È possibile creare cluster di Bilanciamento carico di rete, aggiungere nodi e aggiornare le configurazioni del cluster di Bilanciamento carico di rete senza riavviare le macchine virtuali. Tutte le macchine virtuali che fanno parte del cluster di Bilanciamento carico di rete devono trovarsi nella stessa subnet. Per garantire la disponibilità del carico di lavoro (anche in caso di errore dell'host), l'amministratore dell'infrastruttura di macchine virtuali deve assicurarsi che le macchine virtuali siano in esecuzione in host diversi.
Cluster con carico bilanciato (tramite bilanciamento del carico hardware)	Questa funzionalità deve essere fornita a livello di infrastruttura e gli amministratori dell'infrastruttura devono configurare cluster con carico bilanciato per le macchine virtuali che lo richiedono. In alternativa, possono consentire agli amministratori delle macchine virtuali di effettuarne la configurazione tramite il portale di gestione per il bilanciamento del carico hardware. Richiede che l'amministratore di macchine virtuali disponga di almeno due macchine virtuali che eseguono un carico di lavoro identico ospitato nell'infrastruttura. Per altre informazioni, vedere la documentazione relativa al prodotto del fornitore di hardware.

Con stato

Opzione	Considerazioni
Cluster Hyper-V	Richiede la configurazione di un cluster di failover. Richiede l'archiviazione condivisa tra tutti i nodi del cluster per i file CSV. Può essere un'archiviazione SAN o una condivisione file SMB 3.0. Quando il cluster rileva un problema con un host o Hyper-V rileva un problema con l'archiviazione o la rete di macchine virtuali, è possibile spostare la macchina virtuale in un altro host. La macchina virtuale rimane in esecuzione durante lo spostamento. Nel caso di errore irreversibile di un host, è possibile avviare le macchine virtuali eseguite su tale host in altri nodi del cluster. Le macchine virtuali critiche possono essere configurate per l'avvio automatico. In questo modo si limita il tempo di inattività in caso di errore irreversibile dell'host. Applicare patch agli host senza influire sulle macchine virtuali in esecuzione usando Aggiornamento compatibile con cluster. Configurare l'anti-affinità delle macchine virtuali per evitarne l'esecuzione nello stesso nodo. Se ad esempio si eseguono due server Web che forniscono servizi front-end per un'applicazione back-end, è opportuno non eseguire entrambi i server Web nello stesso nodo. È possibile attivare la modalità di manutenzione per un nodo e il servizio cluster di failover sposterà le macchine virtuali in esecuzione in un altro nodo del cluster. Quando nel nodo non vi saranno più macchine virtuali in esecuzione, si potrà eseguire la manutenzione necessaria. Il cluster di failover non sposterà macchine virtuali in un nodo in modalità di manutenzione. Prima di attivare la modalità di manutenzione per un nodo, assicurarsi che negli altri nodi del cluster Hyper-V sia disponibile una capacità sufficiente per eseguire le macchine virtuali esistenti e rispettare comunque i contratti di servizio con i clienti.

Cluster Hyper-V

Richiede la configurazione di un cluster di failover.
Richiede l'archiviazione condivisa tra tutti i nodi del cluster per i file CSV. Può essere un'archiviazione SAN o una condivisione file SMB 3.0.
Quando il cluster rileva un problema con un host o Hyper-V rileva un problema con l'archiviazione o la rete di macchine virtuali, è possibile spostare la macchina virtuale in un altro host. La macchina virtuale rimane in esecuzione durante lo spostamento.
Nel caso di errore irreversibile di un host, è possibile avviare le macchine virtuali eseguite su tale host in altri nodi del cluster. Le macchine virtuali critiche possono essere configurate per l'avvio automatico. In questo modo si limita il tempo di inattività in caso di errore irreversibile dell'host.
Applicare patch agli host senza influire sulle macchine virtuali in esecuzione usando Aggiornamento compatibile con cluster.
Configurare l'anti-affinità delle macchine virtuali per evitarne l'esecuzione nello stesso nodo. Se ad esempio si eseguono due server Web che forniscono servizi front-end per un'applicazione back-end, è opportuno non eseguire entrambi i server Web nello stesso nodo.
È possibile attivare la modalità di manutenzione per un nodo e il servizio cluster di failover sposterà le macchine virtuali in esecuzione in un altro nodo del cluster. Quando nel nodo non vi saranno più macchine virtuali in esecuzione, si potrà eseguire la manutenzione necessaria.

Il cluster di failover non sposterà macchine virtuali in un nodo in modalità di manutenzione. Prima di attivare la modalità di manutenzione per un nodo, assicurarsi che negli altri nodi del cluster Hyper-V sia disponibile una capacità sufficiente per eseguire le macchine virtuali esistenti e rispettare comunque i contratti di servizio con i clienti.

Con stato condiviso

Quando si eseguono carichi di lavoro compatibili con cluster, è possibile fornire un livello di disponibilità aggiuntivo abilitando il clustering guest della macchina virtuale. Il clustering guest supporta la disponibilità elevata per i carichi di lavoro all'interno della macchina virtuale. Il clustering guest fornisce la protezione al carico di lavoro in esecuzione nelle macchine virtuali, anche in caso di errore dell'host in cui è in esecuzione una macchina virtuale. Poiché il carico di lavoro è protetto tramite Clustering di failover, la macchina virtuale nell'altro nodo assumerà automaticamente il controllo.

Opzione	Considerazioni
Clustering guest delle macchine virtuali	Richiede l'archiviazione condivisa accessibile da due o più macchine virtuali contemporaneamente. I tipi di connessione supportati includono: iSCSI Fibre Channel virtuale VHDX condiviso Configurare l'anti-affinità delle macchine virtuali per evitare che vengano eseguite entrambe nello stesso nodo del cluster. Il clustering guest delle macchine virtuali non è supportato in Azure. Le funzionalità seguenti non sono compatibili con VHDX condiviso: Replica Hyper-V. Ridimensionamento del disco rigido virtuale durante l'esecuzione di una qualsiasi delle macchine virtuali configurate. Migrazione di archiviazione in tempo reale Backup del Servizio Copia Shadow del volume a livello di host. I backup a livello di Guest devono essere eseguiti con gli stessi metodi che si userebbero per un cluster eseguito in server fisici. Checkpoint della macchina virtuale. QoS di archiviazione.

Clustering guest delle macchine virtuali

Richiede l'archiviazione condivisa accessibile da due o più macchine virtuali contemporaneamente. I tipi di connessione supportati includono:
- iSCSI
- Fibre Channel virtuale
- VHDX condiviso
Configurare l'anti-affinità delle macchine virtuali per evitare che vengano eseguite entrambe nello stesso nodo del cluster.
Il clustering guest delle macchine virtuali non è supportato in Azure.
Le funzionalità seguenti non sono compatibili con VHDX condiviso:
- Replica Hyper-V.
- Ridimensionamento del disco rigido virtuale durante l'esecuzione di una qualsiasi delle macchine virtuali configurate.
- Migrazione di archiviazione in tempo reale
- Backup del Servizio Copia Shadow del volume a livello di host. I backup a livello di Guest devono essere eseguiti con gli stessi metodi che si userebbero per un cluster eseguito in server fisici.
- Checkpoint della macchina virtuale.
- QoS di archiviazione.

Altre informazioni:

Distribuire un cluster guest mediante un disco rigido virtuale condiviso

Utilizzo del clustering guest per la disponibilità elevata

Ripristino di emergenza

Se si verifica una situazione di emergenza, in quanto tempo è possibile fare in modo che i carichi di lavoro necessari ritornino operativi per fornire servizi ai client? In alcuni casi, può trattarsi solo di pochi minuti.

Per assicurare che possano essere replicati i dati più aggiornati con una perdita di dati accettabile dovuta ai ritardi, è necessario che venga eseguita la replica dei dati dai data center principali ai centri di ripristino di emergenza. L'esecuzione dei carichi di lavoro nelle macchine virtuali permette di replicare i dischi rigidi virtuali e i file di configurazione delle macchine virtuali dal sito primario a un sito di replica.

Nella tabella seguente vengono messe a confronto le opzioni per il ripristino di emergenza.

Opzione	Considerazioni
Replica Hyper-V	Economica e non richiede la duplicazione dell'hardware di archiviazione e host nei siti di ripristino di emergenza. Uso degli stessi strumenti di gestione per gestire la replica e le macchine virtuali. Intervalli di replica configurabili per soddisfare i requisiti relativi alla perdita di dati. Configurazione di indirizzi IP diversi da usare nel sito di replica. Impatto minimo sull'infrastruttura di rete. Non supportata per le macchine virtuali configurate con dischi fisici (detti anche dischi pass-through), archiviazione Fibre Channel virtuale o dischi rigidi virtuali condivisi. Evitare di usare la replica Hyper-V in sostituzione dell'archiviazione dei backup dei dati e del recupero dati. Se si configurano punti di ripristino aggiuntivi, saranno necessarie risorse di archiviazione aggiuntive nel sito di replica. La frequenza dell'intervallo di replica determinerà la quantità di perdita dei dati. Se si configura un intervallo di replica breve per una macchina virtuale soggetta a una grande quantità di modifiche, nel sito di replica saranno necessarie risorse di replica aggiuntive.
Backup	Eseguire il backup dell'intera macchina virtuale usando una soluzione di backup supportata in Hyper-V, ad esempio System Center Data Protection Manager. La perdita di dati sarà determinata da quanto tempo è trascorso dall'ultimo backup. Non è possibile eseguire il backup a livello di host per le macchine virtuali configurate con un file VHDX condiviso. Installare un agente di backup nella macchina virtuale ed eseguire il backup dei dati dall'interno della macchina virtuale.

Replica Hyper-V

Economica e non richiede la duplicazione dell'hardware di archiviazione e host nei siti di ripristino di emergenza.
Uso degli stessi strumenti di gestione per gestire la replica e le macchine virtuali.
Intervalli di replica configurabili per soddisfare i requisiti relativi alla perdita di dati.
Configurazione di indirizzi IP diversi da usare nel sito di replica.
Impatto minimo sull'infrastruttura di rete.
Non supportata per le macchine virtuali configurate con dischi fisici (detti anche dischi pass-through), archiviazione Fibre Channel virtuale o dischi rigidi virtuali condivisi.
Evitare di usare la replica Hyper-V in sostituzione dell'archiviazione dei backup dei dati e del recupero dati.
Se si configurano punti di ripristino aggiuntivi, saranno necessarie risorse di archiviazione aggiuntive nel sito di replica.
La frequenza dell'intervallo di replica determinerà la quantità di perdita dei dati.
Se si configura un intervallo di replica breve per una macchina virtuale soggetta a una grande quantità di modifiche, nel sito di replica saranno necessarie risorse di replica aggiuntive.

Backup

Eseguire il backup dell'intera macchina virtuale usando una soluzione di backup supportata in Hyper-V, ad esempio System Center Data Protection Manager.
La perdita di dati sarà determinata da quanto tempo è trascorso dall'ultimo backup.
Non è possibile eseguire il backup a livello di host per le macchine virtuali configurate con un file VHDX condiviso. Installare un agente di backup nella macchina virtuale ed eseguire il backup dei dati dall'interno della macchina virtuale.

Note:

Per gestire e automatizzare la replica a livello centrale quando è in esecuzione System Center 2012 R2 Virtual Machine Manager, è necessario usare Microsoft Azure Site Recovery.
Per replicare le macchine virtuali in Azure, usare Microsoft Azure Site Recovery. La replica di una macchina virtuale in Azure è attualmente in modalità di anteprima.

Altre informazioni:

Microsoft Azure Site Recovery

Importante:

Usare lo strumento Hyper-V Replica Capacity Planner per comprendere l'impatto della replica Hyper-V su infrastruttura di rete, utilizzo del processore nei server primario, di replica e di replica estesa, utilizzo della memoria nei server primario e di replica e sulle operazioni di input/output su disco nei server primario, di replica e di replica estesa basati sulle macchine virtuali esistenti.
È possibile che nel carico di lavoro sia integrata una soluzione di ripristino di emergenza, ad esempio Gruppi di disponibilità AlwaysOn in SQL Server. Per verificare se il carico di lavoro supporta la replica Hyper-V, vedere la relativa documentazione.

Altre informazioni:

Replica Hyper-V

System Center Data Protection Manager

Attività 5: Definire i tipi di macchine virtuali

Per supportare i carichi di lavoro nel proprio ambiente, è possibile creare macchine virtuali con requisiti di risorse univoci per soddisfare le esigenze di ogni carico di lavoro. In alternativa, è possibile adottare un approccio simile per i provider pubblici di servizi di hosting di macchine virtuali, detti anche Infrastructure-as-a-Service (IaaS).

Per una descrizione delle configurazioni di macchine virtuali offerte dai servizi di infrastruttura di Microsoft Azure, vedere Dimensioni delle macchine virtuali e dei servizi cloud per Azure. Al momento della redazione di questo documento, il servizio supporta 13 configurazioni di macchina virtuale, ognuna con diverse combinazioni di spazio per processore, memoria, archiviazione e IOP.

Decisioni di progettazione: le decisioni prese in tutte le attività di questo passaggio possono essere immesse nel foglio di lavoro Virtual machine configs.

Passaggio 3: Pianificare i gruppi host di virtualizzazione dei server

Prima di definire i singoli host dei server, è consigliabile definire i gruppi host. I gruppi host sono semplicemente una raccolta denominata di server che vengono raggruppati per soddisfare gli obiettivi comuni descritti nelle attività rimanenti di questo passaggio.

Attività 1: Definire le posizioni fisiche

È probabile che le risorse hardware siano raggruppate e gestite in base alla posizione fisica, quindi è opportuno definire innanzitutto le posizioni che conterranno le risorse dell'infrastruttura all'interno dell'organizzazione.

Attività 2: Definire i tipi di gruppi host

È possibile creare gruppi host per diversi motivi, ad esempio per ospitare carichi di lavoro con particolari:

Caratterizzazioni del carico di lavoro
Requisiti di risorse
Requisiti di qualità del servizio

L'immagine seguente illustra un'organizzazione che ha creato cinque gruppi host in due posizioni.

Gruppo host

Figura 2:Esempio di gruppi host

L'organizzazione ha creato i gruppi host per i motivi descritti nella tabella seguente.

Gruppo host	Motivi della creazione
Carico di lavoro con stato e senza stato	Le caratterizzazioni di questo carico di lavoro sono le più comuni in questa organizzazione, quindi questo tipo di gruppo host è presente in entrambe le posizioni. Questi carichi di lavoro presentano requisiti analoghi per prestazioni e livello di servizio.
Carichi di lavoro con stato e senza stato del reparto contabilità	Anche se la configurazione hardware dei server in questo gruppo host è la stessa di altri gruppi host di carichi di lavoro con stato e senza stato nel proprio ambiente, il reparto contabilità usa applicazioni con requisiti di sicurezza più elevati di altri reparti dell'organizzazione. Di conseguenza, è stato creato un gruppo host dedicato a questo reparto, in modo che possa essere protetto in modo diverso da altri gruppi host nell'infrastruttura.
Carichi di lavoro con stato condiviso	I carichi di lavoro ospitati da questo gruppo host richiedono l'archiviazione condivisa, perché si basano sulla funzionalità Clustering di failover di Windows Server per mantenere la disponibilità. Questi carichi di lavoro sono ospitati da un gruppo host dedicato, perché la configurazione di queste macchine virtuali è diversa dalle altre macchine virtuali dell'organizzazione.
Carichi di lavoro con stato a elevato utilizzo di I/O	Tutti gli host in questo gruppo host sono connessi a reti con velocità superiore rispetto agli host in altri gruppi host.

Anche se l'organizzazione avrebbe potuto includere più località con i gruppi host, ha scelto di mantenere tutti i membri di ogni gruppo host all'interno della stessa posizione per facilitare la gestione. Come si vede da questo esempio, è possibile creare gruppi host per vari motivi, che variano da un'organizzazione all'altra. Più tipi di gruppi host si creano nell'organizzazione, più sarà complessa la gestione dell'ambiente, aumentando in ultima analisi il costo per l'hosting delle macchine virtuali.

Suggerimento: una maggiore standardizzazione dell'hardware dei server all'interno di un gruppo host migliorerà la scalabilità e la gestione del gruppo host nel corso del tempo. Se si decide di voler standardizzare l'hardware all'interno di un gruppo host, è possibile aggiungere i dati di configurazione standardizzati al foglio di lavoro Host groups disponibile nei fogli di lavoro per la Guida alle considerazioni di progettazione dell'infrastruttura di virtualizzazione. Per altre informazioni sulle considerazioni relative all'hardware fisico, vedere il Passaggio 4. Pianificare gli host di virtualizzazione dei server.

Si consideri che attualmente la maggior parte dei provider di cloud pubblici che ospitano macchine virtuale offrono quanto indicato di seguito:

Ospitano solo macchine virtuali che non richiedono lo stato condiviso.
Spesso hanno un solo set di metriche per la qualità del servizio che forniscono a tutti i clienti.
Non dedicano hardware specifico a clienti specifici.

È consigliabile iniziare con un tipo di gruppo host che contiene hardware identico e aggiungere quindi altri tipi di gruppi host, perché il vantaggio di procedere in questo modo supera il costo.

Attività 3: Determinare se riunire in cluster i membri del gruppo host

In passato, Clustering di failover di Windows Server è stato usato solo per aumentare la disponibilità del server, ma è stato migliorato per fornire un maggior numero di funzionalità. Per decidere se riunire in cluster i membri del gruppo host, considerare le informazioni disponibili nella tabella seguente.

Opzione	Vantaggi	Svantaggi
I membri del gruppo host appartengono a un cluster di failover	In caso di errore di un host, le macchine virtuali ospitate vengono riavviate automaticamente nei nodi rimasti attivi. Le macchine virtuali possono essere spostate in un altro nodo del cluster, se il nodo in cui sono attualmente in esecuzione rileva un problema a livello di nodo o di macchina virtuale. Usare Aggiornamento compatibile con cluster per aggiornare facilmente i nodi del cluster, senza influire sulle macchine virtuali in esecuzione.	Gli host richiedono una configurazione specifica per essere membri del cluster. Gli host devono essere membri di un dominio di Active Directory. Per Clustering di failover sono richiesti altri requisiti di rete e archiviazione.
I membri del gruppo host non appartengono a un cluster di failover	Gli host non richiedono una configurazione cluster specifica. Gli host non devono essere membri di un dominio di Active Directory. Non sono richiesti altri requisiti di rete e archiviazione.	In caso di errore di un host, le macchine virtuali in esecuzione nell'host devono essere spostate manualmente, oppure usando una qualche forma di automazione, a un host attivo e riavviate.

Decisioni di progettazione: le decisioni prese in tutte le attività di questo passaggio possono essere immesse nel foglio di lavoro Settings.

Passaggio 4. Pianificare gli host di virtualizzazione dei server

In questo passaggio si definiranno i tipi di host necessari per ospitare le macchine virtuali che si prevede di eseguire nell'infrastruttura di virtualizzazione. È consigliabile limitare il numero di configurazioni host, in alcuni casi a una singola configurazione, per diminuire i costi di supporto e approvvigionamento. Inoltre, l'acquisto dell'apparecchiatura errata determinerà l'aumento dei costi di distribuzione.

Cloud Platform System

Microsoft offre la propria esperienza nell'esecuzione di alcuni dei più grandi data center e servizi cloud tramite un sistema convergente pre-integrato e completamente convalidato. Cloud Platform System (CPS) combina il comprovato stack di software Microsoft, che include Windows Server 2012 R2, System Center 2012 R2 e Windows Azure Pack, con hardware di rete, archiviazione e per server cloud di Dell. Come blocco predefinito scalabile per il cloud, Cloud Platform System accelera il time-to-value e consente di realizzare un'esperienza cloud coerente.

CPS offre un ambiente cloud multi-tenant self-service per macchine virtuali Platform-as-a-Service (PaaS), Windows e Linux e include pacchetti di distribuzione ottimizzati per applicazioni Microsoft, quali Exchange, SharePoint e SQL Server. L'integrazione predefinita riduce rischi e complessità, accelerando contemporaneamente il tempo di distribuzione da mesi a giorni. Il processo di supporto semplificato e l'automazione delle attività di routine dell'infrastruttura consentono inoltre di liberare le risorse IT che possono perciò concentrarsi sull'innovazione.

Per altre informazioni, visitare il sito Cloud Platform System.

Fast Track

Anziché progettare la propria configurazione hardware (e software), è possibile acquistare configurazioni hardware preconfigurate da vari partner hardware tramite il programma Microsoft Private Cloud Fast Track.

Il programma Fast Track è frutto della collaborazione tra Microsoft e i partner hardware per offrire soluzioni convalidate e preconfigurate che contribuiscono a ridurre la complessità e i rischi dell'implementazione di un'infrastruttura di virtualizzazione e degli strumenti per gestirla.

Il programma Fast Track offre ai clienti una gamma di soluzioni flessibili e varie possibilità di scelta tra diverse tecnologie di fornitori di hardware. Usa le funzionalità di base del sistema operativo Windows Server, la tecnologia Hyper-V e Microsoft System Center per fornire i blocchi predefiniti di un'infrastruttura di cloud privato offerta come servizio.

Altre informazioni:

Sito Microsoft Private Cloud Fast Track

Attività 1: Definire la configurazione di calcolo

In questa attività si determinerà la quantità di memoria, il numero di processori e la versione di Windows Server necessari per ogni host. Il numero di macchine virtuali da eseguire in un host verrà determinato dai componenti hardware illustrati in questa sezione.

Nota: per assicurarsi che la soluzione sia completamente supportata, tutti i componenti hardware acquistati devono avere il logo Certified for Windows Server per la versione di Windows Server in esecuzione.

Il logo Certified for Windows Server dimostra che un sistema server soddisfa i più elevati requisiti tecnici di Microsoft riguardanti sicurezza, affidabilità e gestibilità. Con altri dispositivi e driver certificati possono essere supportati i ruoli, le funzionalità e le interfacce per carichi di lavoro cloud e aziendali e per applicazioni aziendali critiche.

Per un elenco aggiornato di hardware Certified for Windows Server, vedere il Catalogo di Windows Server.

Attività 1a: Definire il processore

Hyper-V presenta i processori logici a ogni macchina virtuale attiva come uno o più processori virtuali. È possibile migliorare l'efficienza in fase di esecuzione usando processori che supportano le tecnologie SLAT (Second Level Address Translation), ad esempio Extended Page Table (EPT) o Nested Page Table (NPT). Hyper-V in Windows Server 2012 R2 supporta un massimo di 320 processori logici.

Considerazioni:

Per i carichi di lavoro che non richiedono notevoli risorse del processore è consigliabile configurare per l'uso di un processore virtuale. Monitorare l'uso del processore host nel corso del tempo per assicurarsi di avere allocato i processori necessari per garantire la massima efficacia.
Ai carichi di lavoro con utilizzo elevato di CPU è consigliabile assegnare due o più processori virtuali. A una macchina virtuale è possibile assegnare un massimo di 64 processori virtuali. Il numero di processori virtuali riconosciuto dalla macchina virtuale dipende dal sistema operativo guest. Windows Server 2008 con Service Pack 2 riconosce, ad esempio, solo quattro processori virtuali.

Altre informazioni:

Panoramica di Hyper-V

Ottimizzazione delle prestazioni per i server Hyper-V

Attività 1b: Definire la memoria

Il server fisico richiede memoria sufficiente per l'host e le macchine virtuali in esecuzione. L'host richiede memoria per eseguire in modo efficiente l'I/O per conto di macchine virtuali e operazioni, ad esempio il checkpoint di una macchina virtuale. Hyper-V assicura che sia disponibile memoria sufficiente per l'host e consente di assegnare la memoria rimanente alle macchine virtuali. Le macchine virtuali dovranno essere dimensionate in base alle esigenze del carico previsto per ogni macchina virtuale.

L'hypervisor virtualizza la memoria fisica guest per isolare le macchine virtuali tra di esse e per fornire uno spazio di memoria contiguo in base zero per ogni sistema operativo guest, come nei sistemi non virtualizzati. Per assicurarsi di ottenere prestazioni ottimali, usare hardware basato su SLAT per ridurre al minimo l'impatto della virtualizzazione di memoria sulle prestazioni.

Dimensionare la memoria della macchina virtuale come avviene in genere per le applicazioni server in un computer fisico. La quantità di memoria assegnata alla macchina virtuale deve consentire alla macchina virtuale di gestire il carico previsto in orari normali e di punta, perché una quantità di memoria insufficiente può aumentare notevolmente i tempi di risposta e l'utilizzo di CPU o I/O.

La memoria allocata a una macchina virtuale riduce la quantità di memoria disponibile per altre macchine virtuali. Se la memoria disponibile nell'host è insufficiente, la macchina virtuale non verrà avviata.

La memoria dinamica consente di ottenere valori di consolidamento più elevati, con maggiore affidabilità per le operazioni di riavvio. Ciò può comportare una riduzione dei costi, soprattutto in ambienti con molte macchine virtuali inattive o a basso carico, ad esempio gli ambienti VDI in pool. Le modifiche di configurazione della memoria dinamica in fase di esecuzione possono ridurre i tempi di inattività e fornire una maggiore flessibilità per rispondere alle modifiche dei requisiti.

Per altre informazioni sulla memoria dinamica, vedere Attività 1b: Definire la memoria, in cui viene illustrato come determinare la memoria per una macchina virtuale.

Altre informazioni:

Panoramica della memoria dinamica

Panoramica su NUMA virtuale Hyper-V

Attività 1c: Definire l'edizione del sistema operativo Windows Server

I set di funzionalità di Windows Server Standard e Windows Server Datacenter sono esattamente uguali. Windows Server Datacenter fornisce un numero illimitato di macchine virtuali. Windows Server Standard è limitato a due macchine virtuali.

In Windows Server 2012 R2 è stata aggiunta la funzionalità di attivazione automatica della macchina virtuale, che permette di installare macchine virtuali in un server Windows correttamente attivato senza dover gestire codici Product Key per ogni macchina virtuale, anche in ambienti non connessi.

Questa funzionalità richiede che nei sistemi operativi guest sia in esecuzione Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard o Windows Server 2012 R2 Essentials. Nella tabella seguente vengono messe a confronto le edizioni.

Edizione	Vantaggi	Svantaggi
Standard	Include tutte le funzionalità di Windows Server. Accettabile per gli ambienti non virtualizzati o poco virtualizzati.	Limitata a due macchine virtuali.
Datacenter	Include tutte le funzionalità di Windows Server. Supporta un numero illimitato di macchine virtuali. Accettabile per ambienti cloud privati altamente virtualizzati.	Più costosa.

Hyper-V può essere installato in un'opzione di installazione Server Core di Windows Server. Un'installazione Server Core riduce lo spazio su disco necessario, la potenziale superficie di attacco e soprattutto i requisiti di manutenzione. Un'installazione Server Core viene gestita tramite la riga di comando, Windows PowerShell o l'amministrazione remota.

È importante esaminare le condizioni di licenza del software che si prevede di usare.

Microsoft Hyper-V Server

Microsoft Hyper-V Server offre una soluzione di virtualizzazione affidabile e semplice che aiuta le organizzazioni a migliorare l'uso dei server e ridurre i costi. Questo prodotto autonomo include solo Windows Hypervisor, un modello di driver di Windows Server e componenti di virtualizzazione.

Hyper-V Server può essere introdotto negli ambienti IT esistenti dei clienti, sfruttandone il provisioning esistente, i processi di gestione e gli strumenti di supporto. Supporta lo stesso elenco di compatibilità hardware delle corrispondenti edizioni di Windows Server e si integra completamente con Microsoft System Center e le tecnologie Windows, ad esempio Windows Update, Active Directory e Clustering di failover.

Hyper-V Server può essere scaricato gratuitamente e la relativa installazione è già attivata. Per ogni sistema operativo in esecuzione in una macchina virtuale ospitata è comunque necessaria una licenza appropriata.

Altre informazioni:

Attivazione automatica delle macchine virtuali

Microsoft Hyper-V Server

Gestire Hyper-V Server in modalità remota

Attività 2: Definire la configurazione della rete

Nel passaggio 2, attività 2 precedente, sono state illustrate le considerazioni di progettazione per la rete della macchina virtuale. Ora verranno illustrate le considerazioni di rete per l'host. Esistono diversi tipi di traffico di rete che occorre considerare e pianificare quando si distribuisce Hyper-V. È consigliabile progettare la configurazione di rete tenendo presenti gli obiettivi seguenti:

Per garantire la QoS di rete.
Per fornire la ridondanza della rete.
Per isolare il traffico in reti definite.

Attività 2a: Definire i tipi di traffico di rete

Quando si distribuisce un cluster Hyper-V, è necessario pianificare i diversi tipi di traffico di rete. La tabella seguente riepiloga i tipi di traffico.

Tipo di traffico	Descrizione
Gestione	Fornisce la connettività tra il server che esegue Hyper-V e le funzionalità dell'infrastruttura di base. Usato per gestire il sistema operativo host Hyper-V e le macchine virtuali.
Cluster e volumi condivisi cluster	Usato per le comunicazioni del cluster tra nodi, ad esempio l'heartbeat del cluster e il reindirizzamento dei volumi condivisi cluster (CSV). Solo quando Hyper-V viene distribuito tramite Clustering di failover.
Migrazione in tempo reale	Usato per la migrazione in tempo reale e la migrazione in tempo reale senza condivisione delle macchine virtuali.
Archiviazione	Usato per il traffico SMB o iSCSI.
Replica	Usato per il traffico di replica delle macchine virtuali tramite la funzionalità di replica Hyper-V.
Traffico delle macchine virtuali (tenant)	Usato per la connettività delle macchine virtuali. In genere richiede la connettività di rete esterna per rispondere alle richieste dei client. Nota: per un elenco di tipi di traffico delle macchine virtuali, vedere il Passaggio 2: Pianificare la configurazione delle macchine virtuali.
Backup	Usato per eseguire il backup dei file del disco rigido virtuale.

Attività 2b: Definire le opzioni per le prestazioni del traffico di rete

Ogni tipo di traffico di rete avrà requisiti relativi a larghezza di banda minima e massima e latenza minima. Di seguito sono illustrate le strategie che è possibile usare per soddisfare i diversi requisiti delle prestazioni di rete.

QoS basata su criteri

Quando si distribuisce un cluster Hyper-V, sono necessari almeno sei modelli di traffico o reti. Ogni rete richiede ridondanza di rete. Per iniziare, considerare circa 12 schede di rete nell'host. È possibile installare più schede di rete quad, ma gli slot dell'host a un certo punto si esauriranno.

Le apparecchiature di rete diventano sempre più veloci. Non molto tempo fa, le schede di rete da 1 GB erano quanto di meglio si potesse scegliere. Le schede da 10 GB nei server stanno diventando più comuni e i prezzi per supportare le infrastrutture a 10 GB stanno diventando più accessibili.

L'installazione di due schede di rete da 10 GB raggruppate fornisce una larghezza di banda maggiore rispetto a due schede quad da 1 GB, richiede un minor numero di porte del commutatore e semplifica le esigenze di cablaggio. Convergendo più tipi di traffico di rete sulle schede di rete da 10 GB raggruppate, la QoS basata su criteri permette di gestire il traffico di rete in modo da soddisfare al meglio le esigenze dell'infrastruttura di virtualizzazione.

Con QoS basata su criteri è possibile specificare il controllo della larghezza di banda di rete, in base a tipo di applicazione, utenti e computer. I criteri QoS consentono di soddisfare i requisiti di servizio di un carico di lavoro o un'applicazione misurando la larghezza di banda, rilevando le mutevoli condizioni della rete (ad esempio congestione o disponibilità di larghezza di banda) e definendo la priorità (o limitazione) del traffico di rete.

Oltre alla possibilità di applicare la larghezza di banda massima, i criteri QoS di Windows Server 2012 R2 forniscono una nuova funzionalità di gestione della larghezza di banda: la larghezza di banda minima. A differenza della larghezza di banda massima, che è un limite, la larghezza di banda minima è un tetto minimo di larghezza di banda e assegna una determinata quantità di larghezza di banda a un tipo di traffico specifico. È possibile implementare contemporaneamente i limiti della larghezza di banda minimo e massimo.

Vantaggi	Svantaggi
Gestita da Criteri di gruppo. Facilmente applicabile alle VLAN per fornire impostazioni di larghezza di banda corrette quando più VLAN vengono eseguite nella scheda di rete o usano Gruppo NIC. QoS basata su criteri può essere applicata al traffico IPsec.	Non consente la gestione della larghezza di banda per il traffico che usa un commutatore virtuale. Gli host Hyper-V devono essere aggiunti a un dominio. Evitare di usare contemporaneamente criteri QoS basati su software e basati su hardware (DCB).

Altre informazioni:

Panoramica di QoS (Quality of Service)

Qualità del servizio (QoS) basata su criteri

Data Center Bridging

Data Center Bridging (DCB) fornisce l'allocazione della larghezza di banda a livello di hardware a un tipo specifico di traffico e migliora l'affidabilità del trasporto Ethernet usando il controllo di flusso basato sulla priorità. DCB è consigliato quando si usano FCoE e iSCSI.

Vantaggi	Svantaggi
Supporto per Microsoft iSCSI Supporto per FCoE	Sono necessari investimenti hardware, inclusi i seguenti: Schede Ethernet che supportano DCB. Commutatori hardware che supportano DCB. Complesso da distribuire e gestire. Non consente la gestione della larghezza di banda per il traffico del commutatore virtuale. Evitare di usare contemporaneamente criteri QoS basati su software e criteri DCB.

Altre informazioni:

Panoramica di Data Center Bridging (DCB)

SMB diretto

SMB diretto (SMB su Accesso diretto a memoria remota o RDMA) è un protocollo di archiviazione di Windows Server 2012 R2. Consente trasferimenti dei dati diretti da memoria a memoria tra il server e la risorsa di archiviazione. Richiede un utilizzo minimo della CPU e usa schede di rete standard che supportano RDMA. In questo modo vengono fornite risposte estremamente rapide alle richieste di rete e. di conseguenza, i tempi di risposta dell'archiviazione di file remota sono coerenti con l'archiviazione a blocchi collegata direttamente.

Vantaggi	Svantaggi
Velocità effettiva maggiore: sfrutta tutta la velocità effettiva delle reti ad alta velocità in cui le schede di rete coordinano il trasferimento di grandi quantità di dati alla velocità della linea. Bassa latenza: fornisce risposte estremamente rapide alle richieste di rete, facendo sembrare l'archiviazione di file remota come un'archiviazione a blocchi collegata direttamente. Basso utilizzo della CPU: usa meno cicli di CPU durante il trasferimento di dati in rete, liberando di conseguenza più cicli di CPU per le macchine virtuali. È possibile configurare la migrazione in tempo reale in modo che usi SMB diretto per eseguire migrazioni in tempo reale più veloci. Abilitato per impostazione predefinita nell'host. Il client SMB rileva automaticamente e usa più connessioni di rete se viene identificata una configurazione appropriata. Configurare la gestione della larghezza di banda SMB in modo da impostare limiti per migrazione in tempo reale, macchine virtuali e traffico di archiviazione predefinito. SMB multicanale non richiede schede supportate da RDMA.	Le schede di rete abilitate per RDMA non sono compatibili con Gruppo NIC. Richiede la distribuzione di due o più schede di rete RDMA in ogni host per fornire la disponibilità elevata. È attualmente limitato ai seguenti tipi di schede di rete: iWARP Infiniband RoCE RDMA con RoCE richiede DCB per il controllo di flusso.

Velocità effettiva maggiore: sfrutta tutta la velocità effettiva delle reti ad alta velocità in cui le schede di rete coordinano il trasferimento di grandi quantità di dati alla velocità della linea.
Bassa latenza: fornisce risposte estremamente rapide alle richieste di rete, facendo sembrare l'archiviazione di file remota come un'archiviazione a blocchi collegata direttamente.
Basso utilizzo della CPU: usa meno cicli di CPU durante il trasferimento di dati in rete, liberando di conseguenza più cicli di CPU per le macchine virtuali.
È possibile configurare la migrazione in tempo reale in modo che usi SMB diretto per eseguire migrazioni in tempo reale più veloci.
Abilitato per impostazione predefinita nell'host.
Il client SMB rileva automaticamente e usa più connessioni di rete se viene identificata una configurazione appropriata.
Configurare la gestione della larghezza di banda SMB in modo da impostare limiti per migrazione in tempo reale, macchine virtuali e traffico di archiviazione predefinito.
SMB multicanale non richiede schede supportate da RDMA.

Le schede di rete abilitate per RDMA non sono compatibili con Gruppo NIC.
Richiede la distribuzione di due o più schede di rete RDMA in ogni host per fornire la disponibilità elevata.
È attualmente limitato ai seguenti tipi di schede di rete:
- iWARP
- Infiniband
- RoCE
RDMA con RoCE richiede DCB per il controllo di flusso.

Receive Segment Coalescing

Receive segment coalescing (RSC) riduce l'utilizzo della CPU per l'elaborazione di rete in ingresso tramite l'offload delle attività dalla CPU a una scheda di rete che supporta RSC.

Vantaggi	Svantaggi
Migliora la scalabilità dei server riducendo l'overhead per l'elaborazione di una grande quantità di traffico di rete in entrata. Riduce al minimo i cicli di CPU impiegati per l'archiviazione di rete e le migrazioni in tempo reale.	Richiede una scheda di rete che supporta RSC. Non fornisce un miglioramento significativo per carichi di lavoro a elevato utilizzo di operazioni di invio. Non è compatibile con traffico crittografato IPsec. Si applica al traffico host. Per applicare RSC al traffico della macchina virtuale, questa deve eseguire Windows Server 2012 R2 ed essere configurata con una scheda di rete SR-IOV. Non è abilitato per impostazione predefinita nei server aggiornati a Windows Server 2012 R2.

Migliora la scalabilità dei server riducendo l'overhead per l'elaborazione di una grande quantità di traffico di rete in entrata.
Riduce al minimo i cicli di CPU impiegati per l'archiviazione di rete e le migrazioni in tempo reale.

Richiede una scheda di rete che supporta RSC.
Non fornisce un miglioramento significativo per carichi di lavoro a elevato utilizzo di operazioni di invio.
Non è compatibile con traffico crittografato IPsec.
Si applica al traffico host. Per applicare RSC al traffico della macchina virtuale, questa deve eseguire Windows Server 2012 R2 ed essere configurata con una scheda di rete SR-IOV.
Non è abilitato per impostazione predefinita nei server aggiornati a Windows Server 2012 R2.

Receive Side Scaling

Receive Side Scaling (RSS) consente alle schede di rete di distribuire il carico di elaborazione di rete in modalità kernel tra più core del processore nei computer multicore. Grazie alla distribuzione di tale elaborazione, è possibile supportare carichi di traffico di rete più elevati rispetto a quanto sarebbe possibile con l'uso di un singolo core. A questo scopo, RSS distribuisce il carico di elaborazione di rete tra molti processori e bilancia attivamente il carico del traffico terminato dal protocollo TCP (Transmission Control Protocol).

Vantaggi	Svantaggi
Distribuisce le interruzioni di monitoraggio su più processori, evitando che un singolo processore gestisca tutte le interruzioni di I/O, comuni nelle versioni precedenti di Windows Server. Funziona con Gruppo NIC. Funziona con il traffico UDP (User Datagram Protocol).	Richiede una scheda di rete che supporta RSS. Disabilitato se la scheda di rete virtuale è associata a un commutatore virtuale. Per le schede di rete associate a un commutatore virtuale viene usato VMQ anziché RSS.

SR-IOV

Hyper-V supporta dispositivi di rete che supportano SR-IOV e consente l'assegnazione diretta di una funzione virtuale SR-IOV di una schede di rete fisica a una macchina virtuale. In questo modo è possibile aumentare la velocità effettiva della rete, ridurre la latenza di rete e ridurre il sovraccarico della CPU host necessario per elaborare il traffico di rete.

Per altre informazioni su SR-IOV, vedere Attività 2b: Definire le opzioni per le prestazioni del traffico di rete precedente.

Attività 2c: Definire la strategia per la disponibilità elevata del traffico di rete e l'aggregazione della larghezza di banda

Gruppo NIC, una funzionalità nota anche come bilanciamento del carico e failover, consente di inserire più schede di rete in un gruppo ai fini dell'aggregazione della larghezza di banda e del failover del traffico. In questo modo è possibile mantenere la connettività in caso di errore di un componente di rete.

Questa funzionalità è disponibile presso i fornitori di schede di rete. Introdotta in Windows Server 2012, Gruppo NIC è inclusa come funzionalità nel sistema operativo Windows Server.

Gruppo NIC è compatibile con tutte le funzionalità di rete di Windows Server 2012 R2, con tre eccezioni:

SR-IOV
RDMA
Autenticazione 802.1X

Da un punto di vista della scalabilità, in Windows Server 2012 R2 è possibile aggiungere un minimo di 1 a un massimo di 32 schede di rete a un singolo gruppo. In un singolo host è possibile creare un numero illimitato di gruppi.

Altre informazioni:

Panoramica di Gruppo NIC

Microsoft Virtual Academy: Gruppo NIC in Windows Server 2012

Cmdlet per Gruppo NIC (NetLBFO) in Windows PowerShell

Distribuzione e gestione per Gruppo NIC (LBFO) in Windows Server 2012 R2

Data center convergente con archiviazione basata su file server

Attività 2d: Definire la strategia di isolamento e sicurezza del traffico di rete

Ogni tipo di traffico di rete può avere requisiti di sicurezza diversi per funzioni quali isolamento e crittografia. La tabella seguente elenca le strategie che è possibile usare per soddisfare i diversi requisiti di sicurezza.

Strategia	Vantaggi	Svantaggi
Crittografia (IPsec)	Il traffico viene protetto durante la trasmissione.	Impatto sulle prestazioni per crittografare e decrittografare il traffico. Complesso da configurare, gestire e risolvere i problemi. Modifiche non corrette della configurazione IPsec possono causare interruzioni della rete o la crittografia non corretta del traffico.
Reti fisiche separate	La rete è fisicamente separata.	Richiede l'installazione di schede di rete aggiuntive nell'host. Se la rete richiede la disponibilità elevata, per ognuna sono necessarie due o più schede di rete.
Rete locale virtuale (VLAN)	Isola il traffico usando un ID VLAN assegnato. Supporto per VLAN Trunking Protocol. Supporto per VLAN private. Già usata da molti clienti aziendali.	Limitata a 4094 VLAN e la maggior parte dei commutatori supporta solo 1000 VLAN. Richiede configurazione e gestione aggiuntive delle apparecchiature di rete. Le VLAN non possono essere estese a più subnet Ethernet, con conseguente limitazione del numero di nodi in un'unica VLAN e limitazione del posizionamento delle macchine virtuali in base alla posizione fisica.

Attività 2e: Definire le schede di rete virtuali

Conoscendo i tipi di traffico richiesti dagli host del server di virtualizzazione e le strategie relative a prestazioni, disponibilità e sicurezza per il traffico, è possibile determinare il numero di schede di rete fisiche necessarie per ogni host e i tipi di traffico di rete trasmessi su ogni scheda.

Attività 2f: Definire i commutatori virtuali

Per connettere una macchina virtuale a una rete, è necessario connettere la scheda di rete a un commutatore virtuale Hyper-V.

È possibile creare tre tipi di commutatori virtuali in Hyper-V:

Commutatore virtuale esterno

Usare un commutatore virtuale esterno per consentire alle macchine virtuali di accedere a una rete fisica per comunicare con client e server esterni. Questo tipo di commutatore virtuale consente anche alle macchine virtuali nello stesso host di comunicare tra di esse. Questo tipo di rete può essere disponibile anche per l'uso nel sistema operativo host, a seconda di come si configura la rete.

Importante: una scheda di rete fisica può essere associata solo a un commutatore virtuale alla volta.
Commutatore virtuale interno

Usare un commutatore virtuale interno per consentire la comunicazione tra le macchine virtuali nello stesso host e tra le macchine virtuali e il sistema operativo host. Questo tipo di commutatore virtuale viene comunemente usato per creare un ambiente di test in cui è necessario connettersi alle macchine virtuali dal sistema operativo host. Un commutatore virtuale interno non è associato a una scheda di rete fisica. Di conseguenza, una rete virtuale interna è isolata dal traffico di rete esterno.
Commutatore virtuale privato

Usare un commutatore virtuale privato per consentire la comunicazione solo tra le macchine virtuali nello stesso host. Un commutatore virtuale privato non è associato a una scheda di rete fisica. Un commutatore virtuale privato è isolato da tutto il traffico di rete esterno nel server di virtualizzazione e da qualsiasi traffico di rete tra il sistema operativo host e la rete esterna. Questo tipo di rete è utile quando è necessario creare un ambiente di rete isolato, ad esempio un dominio di test isolato.

Nota: i commutatori virtuali interni e privati non sfruttano le funzionalità di accelerazione hardware disponibili per una macchina virtuale connessa a un commutatore virtuale esterno.

Decisioni di progettazione: le decisioni prese in tutte le attività di questo passaggio possono essere immesse nei fogli di lavoro Virtualization hosts.

Suggerimento: i commutatori virtuali in host diversi che si connettono alla stessa rete devono avere lo stesso nome. In questo modo è più facile definire a quale commutatore virtuale deve essere connessa una macchina virtuale ed è più semplice spostare una macchina virtuale da un host all'altro. Il cmdlet di Windows PowerShell Move-VM non riuscirà se nell'host di destinazione non viene trovato lo stesso nome del commutatore virtuale.

Attività 3: Definire la configurazione dell'archiviazione

Oltre all'archiviazione necessaria per il sistema operativo host, ogni host richiede l'accesso alla risorsa di archiviazione in cui sono archiviati i file di configurazione delle macchine virtuali e dischi rigidi virtuali. Questa attività si baserà sull'archiviazione della macchina virtuale.

Attività 3a: Definire i tipi di dati

Di seguito sono riportati i tipi di dati di esempio che è opportuno considerare per i requisiti di archiviazione.

Tipo di dati	Posizione di archiviazione del tipo di dati
File del sistema operativo host	In genere in un disco rigido locale
File di paging dell'host e dump di arresto anomalo del sistema in Windows	In genere in un disco rigido locale
Stato condiviso del cluster di failover	Archiviazione di rete condivisa o volume condiviso cluster
File del disco rigido virtuale e file di configurazione della macchina virtuale	In genere nell'archiviazione di rete condivisa o nel volume condiviso cluster

La parte restante di questo passaggio si basa sulla risorsa di archiviazione richiesta per le macchine virtuali.

Attività 3b: Opzioni di archiviazione

Le opzioni seguenti sono disponibili per archiviare i file di configurazione delle macchine virtuali e i dischi rigidi virtuali.

Opzione 1: Direct-attached storage

Direct-attached storage si riferisce a un sistema di archiviazione collegato direttamente al server, anziché direttamente a una rete. Non è limitato solo all'archiviazione interna. Può anche usare una enclosure per dischi esterna che contiene unità disco rigido, tra cui enclosure JBOD (Just-a-Bunch-Of-Disks) ed enclosure connesse tramite SAS o un altro controller del disco.

Vantaggi	Svantaggi
Non richiede una rete di archiviazione. Operazioni I/O del disco veloci che non richiedono quindi la trasmissione in rete di richieste di archiviazione. Può essere un'archiviazione interna o una enclosure per dischi esterna, ad esempio JBOD. È possibile usare JBOD con la tecnologia Spazi di archiviazione per combinare tutti i dischi fisici in un pool di archiviazione e quindi creare uno o più dischi virtuali (detti Spazi di archiviazione) usando lo spazio disponibile nel pool. Le enclosure JBOD sono in genere più economiche e spesso più flessibili e facili da gestire delle enclosure RAID, perché usano il sistema operativo Windows o Windows Server per gestire l'archiviazione, invece di schede RAID dedicate.	Limitazione del numero di server che è possibile collegare alla enclosure per dischi esterna. Solo l'archiviazione condivisa esterna, ad esempio SAS condivisa con Spazi di archiviazione, fornisce il supporto per il clustering di failover.

Non richiede una rete di archiviazione.
Operazioni I/O del disco veloci che non richiedono quindi la trasmissione in rete di richieste di archiviazione.
Può essere un'archiviazione interna o una enclosure per dischi esterna, ad esempio JBOD.
È possibile usare JBOD con la tecnologia Spazi di archiviazione per combinare tutti i dischi fisici in un pool di archiviazione e quindi creare uno o più dischi virtuali (detti Spazi di archiviazione) usando lo spazio disponibile nel pool.
Le enclosure JBOD sono in genere più economiche e spesso più flessibili e facili da gestire delle enclosure RAID, perché usano il sistema operativo Windows o Windows Server per gestire l'archiviazione, invece di schede RAID dedicate.

Limitazione del numero di server che è possibile collegare alla enclosure per dischi esterna.
Solo l'archiviazione condivisa esterna, ad esempio SAS condivisa con Spazi di archiviazione, fornisce il supporto per il clustering di failover.

Opzione 2: Network-attached storage (NAS)

I dispositivi NAS connettono l'archiviazione a una rete, dove l'accesso avviene tramite condivisioni file. A differenza di Direct-attached storage, non sono collegati direttamente al computer.

I dispositivi NAS supportano connessioni Ethernet e in genere consentono all'amministratore di gestire lo spazio su disco, impostare quote disco, garantire la sicurezza e utilizzare le tecnologie checkpoint. I dispositivi NAS supportano più protocolli. Ad esempio, file system collegati alla rete, CIFS (Common Internet File System) e SMB (Server Message Block).

Vantaggi	Svantaggi
Più semplice da configurare dell'archiviazione SAN, richiede meno hardware di archiviazione dedicato. Plug and Play. Può usare una rete Ethernet esistente.	Il dispositivo NAS deve supportare SMB 3.0; CIFS non è supportato. Non è collegato direttamente ai server host che accedono all'archiviazione. Meno veloce di altre opzioni. Richiede in genere una rete dedicata per fornire prestazioni ottimali. Gestione e funzionalità limitate. Hyper-V supporta i dispositivi NAS che supportano SMB 3.0; SMB 2.0 e CIFS non sono supportati. Può supportare o meno RDMA.

Più semplice da configurare dell'archiviazione SAN, richiede meno hardware di archiviazione dedicato.
Plug and Play.
Può usare una rete Ethernet esistente.

Il dispositivo NAS deve supportare SMB 3.0; CIFS non è supportato.
Non è collegato direttamente ai server host che accedono all'archiviazione.
Meno veloce di altre opzioni.
Richiede in genere una rete dedicata per fornire prestazioni ottimali.
Gestione e funzionalità limitate.
Hyper-V supporta i dispositivi NAS che supportano SMB 3.0; SMB 2.0 e CIFS non sono supportati.
Può supportare o meno RDMA.

Opzione 3: Rete di archiviazione

Una rete di archiviazione (SAN) è una rete dedicata che consente di condividere l'archiviazione. Una rete SAN è costituita da un dispositivo di archiviazione, dall'infrastruttura di rete di interconnessione (commutatori, schede bus host e cavi) e server connessi alla rete. I dispositivi SAN forniscono l'accesso continuo e rapido a quantità elevate di dati. Il meccanismo di comunicazione e trasferimento dei dati per una distribuzione specifica è comunemente noto come infrastruttura di archiviazione.

Una rete SAN usa una rete separata e in genere non è accessibile da altri dispositivi tramite la rete locale. Una rete SAN può essere gestita tramite SMI-S (Storage Management Initiative Specification), SNMP (Simple Network Management Protocol) o un protocollo di gestione proprietario.

Una rete SAN non fornisce astrazione di file, solo operazioni a livello di blocco. I protocolli di rete SAN più comunemente usati sono iSCSI, Fiber Channel e Fiber Channel over Ethernet (FCoE). SMI-S o un protocollo di gestione proprietario può offrire funzionalità aggiuntive, come suddivisione in zone del disco, mapping del disco, mascheramento dei LUN e gestione degli errori.

Vantaggi	Svantaggi
La rete SAN usa una rete separata, pertanto l'impatto sulla rete dati è limitato. Fornisce l'accesso continuo e rapido a quantità elevate di dati. In genere fornisce funzionalità aggiuntive, come protezione dei dati e replica. Può essere condivisa tra più team. Supporta Fibre Channel virtuale per l'accesso diretto ai LUN. Supporta il clustering guest. Le macchine virtuali che richiedono l'accesso a volumi di dati maggiori di 64 TB possono usare Fibre Channel virtuale per l'accesso diretto ai LUN.	Costosa. Richiede competenze specializzate per distribuzione, gestione e manutenzione. È necessario installare schede di rete HBA o FCoE in ogni host. La migrazione di un cluster Hyper-V richiede una pianificazione aggiuntiva e tempi di inattività limitati. Per fornire la gestione della larghezza di banda per il traffico FCoE, sono necessari criteri QoS hardware che usano Data Center Bridging. Il traffico FCoE non è instradabile.

La rete SAN usa una rete separata, pertanto l'impatto sulla rete dati è limitato.
Fornisce l'accesso continuo e rapido a quantità elevate di dati.
In genere fornisce funzionalità aggiuntive, come protezione dei dati e replica.
Può essere condivisa tra più team.
Supporta Fibre Channel virtuale per l'accesso diretto ai LUN.
Supporta il clustering guest.
Le macchine virtuali che richiedono l'accesso a volumi di dati maggiori di 64 TB possono usare Fibre Channel virtuale per l'accesso diretto ai LUN.

Costosa.
Richiede competenze specializzate per distribuzione, gestione e manutenzione.
È necessario installare schede di rete HBA o FCoE in ogni host.
La migrazione di un cluster Hyper-V richiede una pianificazione aggiuntiva e tempi di inattività limitati.
Per fornire la gestione della larghezza di banda per il traffico FCoE, sono necessari criteri QoS hardware che usano Data Center Bridging.
Il traffico FCoE non è instradabile.

Opzione 4: Condivisioni file di Server Message Block 3.0

Hyper-V può archiviare file delle macchine virtuali, ad esempio file di configurazione, file di dischi rigidi virtuali e checkpoint, in condivisioni file che usano il protocollo Server Message Block (SMB) 3.0. Le condivisioni file sono in genere disponibili in un file server a scalabilità orizzontale per garantire la ridondanza. Quando si esegue un file server a scalabilità orizzontale, se un nodo è inattivo, le condivisioni file rimangono disponibili tramite gli altri nodi del file server a scalabilità orizzontale.

Vantaggi	Svantaggi
Possibilità di usare reti e protocolli esistenti. SMB multicanale offre un'aggregazione di larghezza di banda di rete e tolleranza di errore quando sono disponibili più percorsi tra il server che esegue Hyper-V e la condivisione file SMB 3.0. È possibile usare JBOD con la tecnologia Spazi di archiviazione per combinare tutti i dischi fisici in un pool di archiviazione e quindi creare uno o più dischi virtuali (detti Spazi di archiviazione) usando lo spazio disponibile nel pool. SMB multicanale può essere usato per le migrazioni di macchine virtuali. Più economico delle distribuzioni SAN. Configurazioni di archiviazione flessibili nel file server che esegue Windows Server. Servizi Hyper-V separati dai servizi di archiviazione, per consentire la scalabilità di ogni servizio in base alle esigenze. Offre flessibilità durante l'aggiornamento alla versione successiva se è in esecuzione un cluster Hyper-V. È possibile aggiornare i server che eseguono Hyper-V o file server a scalabilità orizzontale in qualsiasi ordine senza tempi di inattività. È necessaria una capacità sufficiente nel cluster per rimuovere uno o due nodi per eseguire l'aggiornamento. Il file server a scalabilità orizzontale fornisce il supporto per VHDX condiviso. La gestione della larghezza di banda SMB consente di impostare limiti per la migrazione in tempo reale, il disco rigido virtuale e il traffico di archiviazione predefinito. Supporta la crittografia del traffico SMB con un impatto minimo sulle prestazioni. Consente di risparmiare spazio su disco con Deduplicazione dati per le distribuzioni VDI. Non richiede competenze specializzate per distribuzione, gestione e manutenzione.	Le prestazioni di I/O non sono veloci come nelle distribuzioni SAN. Deduplicazione dati non è supportata per i file di macchine virtuali in esecuzione, fatta eccezione per le distribuzioni VDI.

Possibilità di usare reti e protocolli esistenti.
SMB multicanale offre un'aggregazione di larghezza di banda di rete e tolleranza di errore quando sono disponibili più percorsi tra il server che esegue Hyper-V e la condivisione file SMB 3.0.
È possibile usare JBOD con la tecnologia Spazi di archiviazione per combinare tutti i dischi fisici in un pool di archiviazione e quindi creare uno o più dischi virtuali (detti Spazi di archiviazione) usando lo spazio disponibile nel pool.
SMB multicanale può essere usato per le migrazioni di macchine virtuali.
Più economico delle distribuzioni SAN.
Configurazioni di archiviazione flessibili nel file server che esegue Windows Server.
Servizi Hyper-V separati dai servizi di archiviazione, per consentire la scalabilità di ogni servizio in base alle esigenze.
Offre flessibilità durante l'aggiornamento alla versione successiva se è in esecuzione un cluster Hyper-V. È possibile aggiornare i server che eseguono Hyper-V o file server a scalabilità orizzontale in qualsiasi ordine senza tempi di inattività. È necessaria una capacità sufficiente nel cluster per rimuovere uno o due nodi per eseguire l'aggiornamento.
Il file server a scalabilità orizzontale fornisce il supporto per VHDX condiviso.
La gestione della larghezza di banda SMB consente di impostare limiti per la migrazione in tempo reale, il disco rigido virtuale e il traffico di archiviazione predefinito.
Supporta la crittografia del traffico SMB con un impatto minimo sulle prestazioni.
Consente di risparmiare spazio su disco con Deduplicazione dati per le distribuzioni VDI.
Non richiede competenze specializzate per distribuzione, gestione e manutenzione.

Le prestazioni di I/O non sono veloci come nelle distribuzioni SAN.
Deduplicazione dati non è supportata per i file di macchine virtuali in esecuzione, fatta eccezione per le distribuzioni VDI.

SMB diretto

SMB diretto funziona nell'ambito delle condivisioni file SMB. SMB diretto richiede schede di rete e commutatori che supportano RDMA per fornire la massima velocità con accesso all'archiviazione a bassa latenza. Con SMB diretto i file server remoti sono simili a un'archiviazione locale e di tipo Direct-attached storage. Oltre ai vantaggi di SMB, SMB diretto presenta i seguenti vantaggi e svantaggi.

Vantaggi	Svantaggi
Funzioni alla massima velocità con bassa latenza e utilizzo di CPU minimo. Consente a un file server a scalabilità orizzontale di fornire prestazioni di archiviazione e resilienza simili a una rete SAN tradizionale, usando soluzioni di archiviazione Microsoft e un'economica archiviazione Direct-attached storage condivisa. Fornisce l'opzione più rapida per migrazioni in tempo reale e migrazioni di archiviazione.	Non supportato con Gruppo NIC. Per connessioni ridondanti alla risorsa di archiviazione, sono necessarie due o più schede di rete abilitate per RDMA.

Funzioni alla massima velocità con bassa latenza e utilizzo di CPU minimo.
Consente a un file server a scalabilità orizzontale di fornire prestazioni di archiviazione e resilienza simili a una rete SAN tradizionale, usando soluzioni di archiviazione Microsoft e un'economica archiviazione Direct-attached storage condivisa.
Fornisce l'opzione più rapida per migrazioni in tempo reale e migrazioni di archiviazione.

Non supportato con Gruppo NIC.
Per connessioni ridondanti alla risorsa di archiviazione, sono necessarie due o più schede di rete abilitate per RDMA.

File server a scalabilità orizzontale

Figura 3:File server a scalabilità orizzontale che usa una rete convergente con RDMA

Altre informazioni:

Offrire archiviazione conveniente per carichi di lavoro Hyper-V mediante Windows Server

Data center convergente con archiviazione basata su file server

Distribuire Hyper-V tramite SMB

Come ottenere oltre 1 milione di IOPS da VM Hyper-V in un cluster di file server a scalabilità orizzontale con Windows Server 2012 R2

Attività 3c: Definire i tipi di architettura dell'unità fisica

Il tipo di architettura dell'unità fisica scelto per l'archiviazione avrà un impatto sulle prestazioni della soluzione di archiviazione. Per altre informazioni sui tipi di dischi, vedere la sezione 7.1 del documento che illustra l'architettura della linea di prodotti IaaS.

Attività 3d: Definire il tipo di rete di archiviazione

I tipi di controller di archiviazione o della rete di archiviazione in uso sono determinati dall'opzione di archiviazione scelta per ogni gruppo host. Per altre informazioni, vedere Attività 3b: Opzioni di archiviazione.

Attività 3e: Determinare il tipo di archiviazione da usare per ogni tipo di dati

Conoscendo i tipi di dati, è possibile determinare l'opzione di archiviazione, il controller di archiviazione, il controller della rete di archiviazione e le architetture del disco fisico che meglio soddisfano i propri requisiti.

Decisioni di progettazione: le decisioni prese in questa attività possono essere immesse nel foglio di lavoro Virtualization hosts.

Altre informazioni:

Configurazioni di rete per Hyper-V su SMB in Windows Server 2012 e Windows Server 2012 R2

Riferimenti complementari e poster dell'architettura di componenti Hyper-V in Windows Server 2012

Panoramica delle tecnologie di archiviazione

Attività 4: Definire le unità di scala host di virtualizzazione dei server

L'acquisto di singoli server richiede approvvigionamento, installazione e configurazione per ogni server. Le unità di scala consentono di acquistare raccolte di server, che in genere includono hardware identico. Sono preconfigurate e permettono di aggiungere capacità al data center mediante l'aggiunta di unità di scala, anziché singoli server.

L'immagine seguente illustra un'unità di scala che potrebbe essere stata acquistata preconfigurata da molti fornitori di hardware. Include un rack, un gruppo di continuità (UPS), una coppia ridondante di commutatori di rete per i server contenuti nel rack e dieci server.

Unità di scala host

Figura 4:Esempio di unità di scala host del server di virtualizzazione

L'unità di scala viene fornita preconfigurata e già collegata al gruppo di continuità e ai commutatori di rete. L'unità deve semplicemente essere aggiunta a un data center, collegata all'alimentazione elettrica e connessa alla rete e all'archiviazione, quindi sarà pronta all'uso. Se i singoli componenti non sono stati acquistati come unità di scala, l'acquirente dovrebbe provvedere a montare su rack e collegare tutti i componenti.

Decisioni di progettazione: se si decide di usare unità di scala host di virtualizzazione del server, è possibile definire il relativo hardware tramite il foglio di lavoro Host scale units.

Suggerimento: è possibile acquistare unità di scala preconfigurate da numerosi partner hardware Microsoft tramite il programma Microsoft Private Cloud Fast Track.

Attività 5: Definire la strategia di disponibilità degli host di virtualizzazione dei server

Gli host del server di virtualizzazione possono diventare non disponibili per motivi pianificati (ad esempio manutenzione) o non pianificati. Di seguito sono elencate alcune strategie che è possibile usare in entrambi i casi.

Pianificata

Per spostare le macchine virtuali da un host all'altro, è possibile usare la funzionalità di migrazione in tempo reale. In questo caso non sono richiesti tempi di inattività delle macchine virtuali.

Non pianificata

Questo scenario dipende dai tipi di caratterizzazione del carico di lavoro ospitato dall'host.

Per carichi di lavoro con stato condiviso, usare Clustering di failover nelle macchine virtuali.
Per i carichi di lavoro con stato, eseguire come macchina virtuale a disponibilità elevata in un cluster Hyper-V.
Per carichi di lavoro senza stato, avviare nuove istanze manualmente o in modo automatizzato.

Se si usa Clustering di failover in Windows Server con Hyper-V, considerare la possibilità di usare le funzionalità elencate nella tabella seguente. Per altre informazioni su ogni funzionalità, fare clic sul collegamento ipertestuale.

Funzionalità	Considerazioni
Monitoraggio di applicazioni Hyper-V	Monitorare una macchina virtuale per individuare gli errori di rete e archiviazione non monitorati dal servizio Clustering di failover.
Impostazioni di priorità della macchina virtuale	Impostare la priorità della macchina virtuale in base al carico di lavoro. È possibile assegnare le seguenti impostazioni di priorità alle macchine virtuali a disponibilità elevata (dette anche macchine virtuali in cluster): Alta Media (predefinita) Bassa Nessun avvio automatico I ruoli del cluster con priorità più alta vengono avviati e inseriti nei nodi prima di quelli con priorità più bassa. Se viene assegnata una priorità per l'esclusione dell'avvio automatico, il ruolo non torna online automaticamente dopo un errore, mantenendo le risorse disponibili per l'avvio di altri ruoli.
Anti-affinità della macchina virtuale	Impostare l'anti-affinità per le macchine virtuali che non devono essere eseguite nello stesso nodo in un cluster Hyper-V. Questa impostazione può essere appropriata per le macchine virtuali che forniscono un servizio ridondante o che fanno parte di un cluster di macchine virtuali guest. Nota: le impostazioni di anti-affinità vengono configurate tramite Windows PowerShell.
Svuotamento automatico dei nodi	Il cluster svuota automaticamente un nodo, ovvero sposta i ruoli del cluster eseguiti nel nodo in un altro nodo, prima di attivare la modalità di manutenzione del nodo o apportarvi altre modifiche. I ruoli vengono ripristinati nel nodo originale dopo le operazioni di manutenzione. Gli amministratori possono svuotare un nodo con un'unica azione in Gestione cluster di failover o tramite il cmdlet Windows PowerShell, Suspend-ClusterNode. È possibile specificare il nodo di destinazione per i ruoli del cluster spostati. Aggiornamento compatibile con cluster usa lo svuotamento dei nodi nel processo automatico per applicare gli aggiornamenti software ai nodi del cluster.
Aggiornamento compatibile con cluster	Aggiornamento compatibile con cluster consente di aggiornare i nodi in un cluster senza conseguenze per le macchine virtuali in esecuzione nel cluster. Durante il processo di aggiornamento è necessario che un numero sufficiente di nodi del cluster rimanga disponibile per gestire il carico delle macchine virtuali in esecuzione.
Precedenza delle macchine virtuali in base alla priorità	Un altro motivo per impostare la priorità delle macchine virtuali è dovuto al fatto che il servizio cluster può portare offline una macchina virtuale con priorità inferiore quando una macchina virtuale ad alta priorità non dispone di sufficiente memoria e altre risorse per essere avviata. L'applicazione della precedenza inizia dalla macchina virtuale con priorità più bassa e continua con le macchine virtuali con priorità più alta. Le macchine virtuali interrotte verranno riavviate in seguito in ordine di priorità.

Nota: i cluster Hyper-V possono avere un massimo di 64 nodi e 8.000 macchine virtuali.

Passaggio 5. Pianificare i concetti relativi all'architettura dell'infrastruttura di virtualizzazione

Questo passaggio richiede la definizione dei concetti logici a cui verrà allineata l'architettura dell'infrastruttura.

Attività 1: Definire i domini di manutenzione

I domini di manutenzione sono raccolte logiche di server gestiti insieme. La manutenzione può includere aggiornamenti hardware o software oppure modifiche di configurazione. I domini di manutenzione includono in genere gruppi host di ogni tipo o all'interno di ogni percorso, anche se non è una condizione necessaria. Lo scopo è impedire che la manutenzione del server influisca negativamente sui carichi di lavoro degli utenti.

Nota: questo concetto si applica ai componenti di rete e di archiviazione fisici.

Attività 2: Definire i domini di errore fisici

I gruppi di host dei server di virtualizzazione generano spesso errori contemporaneamente a seguito dell'errore di un componente dell'infrastruttura condiviso, ad esempio un commutatore di rete o un gruppo di continuità (UPS). I domini di errore fisici facilitano il supporto della resilienza all'interno dell'infrastruttura di virtualizzazione. È importante comprendere l'impatto di un dominio di errore su ognuno dei gruppi host definiti per l'infrastruttura.

Nota: questo concetto si applica ai componenti di rete e di archiviazione fisici.

Si consideri l'esempio nella figura seguente, che sovrappone domini di errore fisici e di manutenzione a una raccolta di gruppi host all'interno di un data center.

Dominio di errore

Figura 5:Esempio di definizione di dominio di errore fisico e di manutenzione

In questo esempio ogni rack di server è definito come un dominio di errore fisico distinto e numerato. Infatti, ogni rack contiene un commutatore di rete nella parte superiore e un gruppo di continuità nella parte inferiore. Tutti i server all'interno del rack si basano su questi due componenti e l'eventuale errore di uno di essi causerà in effetti un errore in tutti i server del rack.

Poiché tutti i server all'interno di un rack sono anche membri di gruppi host univoci, questa progettazione significherebbe l'impossibilità di attenuare il problema in caso di errore di uno qualsiasi dei domini di errore fisici. Per attenuare i problemi, è possibile aggiungere domini di errore fisici per ogni tipo di gruppo host. In ambienti più piccoli, è possibile aggiungere commutatori e alimentatori ridondanti in ogni rack oppure usare Clustering di failover per gli host dei server di virtualizzazione nei domini di errore fisici.

Nella figura 5 ognuna delle caselle tratteggiate a colori definisce un dominio di manutenzione (sono etichettate MD da 1 a 5). Si noti come in ogni server del cluster con carico bilanciato delle macchine virtuali è ospitato in un host del server di virtualizzazione all'interno di un dominio di manutenzione e di un dominio di errore fisico separati.

Ciò consente all'amministratore dell'infrastruttura di disattivare tutti gli host del server di virtualizzazione all'interno di un dominio di manutenzione senza conseguenze significative per le applicazioni con più server distribuiti in domini di manutenzione. Significa anche che l'applicazione in esecuzione nel cluster con carico bilanciato non diventa completamente non disponibile in caso di errore di un dominio di errore fisico.

Decisioni di progettazione: le decisioni prese per le attività 1 e 2 possono essere immesse nel foglio di lavoro Settings.

Attività 3: Definire la capacità di riserva

Un errore di singoli server dell'infrastruttura è inevitabile. La progettazione dell'infrastruttura deve tenere conto dell'errore di singoli server, come avviene per gli errori di raccolte di server in domini di errore e di manutenzione. La figura seguente è identica alla figura 5, ma usa il colore rosso per identificare tre server con errore.

Server con errore

Figura 6:Server con errore

Nella figura 6 si sono verificati errori negli host di virtualizzazione server nei gruppi host, nei domini di manutenzione e nei domini di errore fisici seguenti.

Gruppo host	Dominio di errore fisico	Dominio di manutenzione
2	2	3
3	3	2
4	4	2

L'applicazione in esecuzione nel cluster con carico bilanciato è ancora disponibile, anche se si è verificato un errore nell'host del dominio di errore fisico 2, ma l'applicazione funzionerà a un terzo in meno della capacità.

Si consideri cosa accadrebbe in caso di errore anche nell'host di virtualizzazione server ospitato in una delle macchine virtuali nel dominio di errore fisico 3 o se il dominio di manutenzione 2 venisse disattivato per manutenzione. In questi casi, la capacità per l'applicazione diminuirebbe di 2/3

e potrebbe risultare non accettabile per l'infrastruttura di virtualizzazione. Per attenuare l'impatto dei server con errore, è possibile assicurarsi che ogni dominio di errore fisico e di manutenzione disponga di sufficiente capacità di riserva per evitare che tale capacità scenda sotto il livello accettabile definito.

Per altre informazioni sul calcolo della capacità di riserva, vedere la sezione relativa alla capacità di riserva nell'articolo sull'architettura di riferimento di base di Servizi cloud Microsoft - Principi, concetti e modelli.

Passaggio 6. Pianificare le caratteristiche relative alla capacità iniziale

Dopo aver completato tutte le attività in questo documento, sarà possibile determinare i costi iniziali per ospitare le macchine virtuali e l'archiviazione nell'infrastruttura, oltre ai livelli di qualità del servizio iniziali che l'infrastruttura è in grado di soddisfare. Non sarà comunque possibile completare queste operazioni, finché non si implementeranno gli strumenti di gestione dell'infrastruttura e le risorse umane descritti nella sezione Passaggi successivi di questo documento.

Attività 1: Definire la metrica iniziale dei contratti di servizio per l'archiviazione e le macchine virtuali

L'amministratore dell'infrastruttura definirà probabilmente un contratto di servizio che descrive in dettaglio la metrica di qualità del servizio che l'infrastruttura dovrà soddisfare. Gli amministratori di macchine virtuali dovranno esserne informati per pianificare la modalità d'uso dell'infrastruttura.

Come minimo, dovrà essere inclusa una metrica per la disponibilità, ma possono esserne include anche altre. Per un'idea di base sulla metrica del contratto di servizio dell'infrastruttura di virtualizzazione, è possibile esaminare quella offerta da provider di cloud pubblico, come Microsoft Azure. Per l'hosting delle macchine virtuali, tale contratto di servizio garantisce che quando un cliente distribuisce due o più istanze di una macchina virtuale che esegue lo stesso carico di lavoro e distribuisce tali istanze in domini di errore e di aggiornamento diversi (detti "domini manutenzione" in questo documento), almeno una di queste macchine virtuali sarà disponibile per il 99,95% del tempo.

Per una descrizione completa del contratto di servizio di Azure, vedere Contratti di servizio. Idealmente, la propria infrastruttura di virtualizzazione sarà pari o superiore a quella dei provider di cloud pubblico.

Attività 2: Definire i costi iniziali per ospitare archiviazione e macchine virtuali

Dopo aver progettato l'infrastruttura, sarà anche possibile calcolare quanto segue:

Costi per hardware, spazio, energia e raffreddamento dell'infrastruttura.
Capacità di hosting dell'infrastruttura.

Queste informazioni, combinate con altri costi, ad esempio il costo degli strumenti di gestione dell'infrastruttura e delle risorse umane, consentirà di determinare i costi finali per ospitare macchine virtuali e archiviazione.

Per un'idea dei costi di base per le macchine virtuali e l'archiviazione, è possibile esaminare i costi di hosting di provider di cloud pubblico, come Microsoft Azure. Per altre informazioni, vedere Macchine virtuali - Prezzi.

Anche se non sempre, in genere si noterà che i costi di hosting sono superiori a quelli dei provider pubblici, perché la propria infrastruttura sarà più piccola di quelle provider pubblici di grandi dimensioni, che possono ottenere sconti per volume su hardware, spazio del data center ed energia.

Passaggi successivi

Dopo aver completato tutte le attività di questo documento, si avrà una progettazione di infrastruttura che soddisfa i requisiti dell'organizzazione. Si avrà anche una definizione iniziale delle caratteristiche del servizio, inclusi i costi e la metrica del livello di servizio. Non sarà possibile determinare la metrica e i costi del livello di servizio finali, finché non si determineranno i costi delle risorse umane, nonché dei processi e degli strumenti di gestione che verranno usati per l'infrastruttura.

Microsoft System Center 2012 offre un set completo di funzionalità che consentono di effettuare il provisioning, monitorare e gestire l'infrastruttura di virtualizzazione. Per altre informazioni su come usare System Center per la gestione dell'infrastruttura, vedere le risorse seguenti:

Raccolta di documentazioni tecniche di System Center

Guida all'architettura di gestione dell'infrastruttura