Guida alle considerazioni di progettazione dell'infrastruttura di virtualizzazione
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.
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:
Architettura di riferimento di base di Servizi cloud Microsoft - Modello di riferimento
Architettura di riferimento di base di Servizi cloud Microsoft - Principi, concetti e modelli
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. |
|
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 |
|
Nessun accesso alle nuove funzionalità delle macchine virtuali. |
Seconda generazione |
|
|
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 |
|
|
Memoria dinamica |
|
|
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. |
|
Gestione della larghezza di banda Hyper-V (QoS Hyper-V) |
|
|
SR-IOV |
|
|
|
|
|
Frame jumbo |
|
|
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:
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 |
|
|
Codifica VLAN |
|
|
|
|
|
|
Quando è abilitata, crea un impatto minimo sulle prestazioni. |
|
|
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.
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 le schede supportate sono al massimo 8. A una scheda di rete virtuale può essere assegnato un ID VLAN, a meno che sia configurata in modalità Trunk.
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)
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.
|
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:
Le macchine virtuali di seconda generazione non supportano i dispositivi IDE. |
SCSI virtuale |
|
Iniziatore iSCSI nella macchina virtuale |
|
Fibre Channel 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 |
|
|
|
|
|
Usato per l'archiviazione condivisa per cluster di macchine virtuali guest. |
|
Selezionare quindi il tipo di disco che si userà, scegliendo tra le opzioni elencate nella tabella seguente.
Tipo di disco |
Vantaggi |
Svantaggi |
---|---|---|
Fisso |
|
|
Dinamico |
Usa lo spazio su disco solo in base alle esigenze, anziché tutto lo spazio di cui è stato effettuato il provisioning. |
|
Differenze |
Se più dischi differenze usano lo stesso elemento padre, può usare meno spazio su disco. |
|
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 |
|
Cluster con carico bilanciato (tramite Bilanciamento carico di rete di Windows) |
|
Cluster con carico bilanciato (tramite bilanciamento del carico hardware) |
|
Con stato
Opzione |
Considerazioni |
---|---|
|
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 |
---|---|
|
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 |
|
Backup |
|
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:
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:
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.
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 |
|
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 |
|
|
I membri del gruppo host non appartengono a un cluster di failover |
|
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:
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 |
|
Limitata a due macchine virtuali. |
Datacenter |
|
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
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 |
|
Cluster e volumi condivisi cluster |
|
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) |
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 |
---|---|
|
|
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 |
---|---|
|
|
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 |
---|---|
|
|
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 |
---|---|
|
|
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 |
---|---|
|
|
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:
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. |
|
Reti fisiche separate |
La rete è fisicamente separata. |
|
Rete locale virtuale (VLAN) |
|
|
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 |
---|---|
|
|
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 |
---|---|
|
|
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 |
---|---|
|
|
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 |
---|---|
|
|
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 |
---|---|
|
|
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
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.
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 |
---|---|
Monitorare una macchina virtuale per individuare gli errori di rete e archiviazione non monitorati dal servizio Clustering di failover. |
|
|
|
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. |
|
|
|
|
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.
|
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.
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.
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: