Select the search type
  • Site
  • Web
Search
Introduzione ad Hyper-V in Windows Server 2012

Autore: Daniele Scrivano - Data Pubblicazione: 15 Aprile 2012 - Data Aggiornamento: 08 Ottobre 2012

Con la distribuzione di Windows 8 Consumer Preview lato client, Microsoft ha contemporaneamente reso disponibile anche i bit di Windows Server 2012 Beta, contenente molte novità tra cui la terza generazione dell’hypervisor di Redmond, Hyper-V 3.0. A riprova che la versione uscita sia una Beta, e quindi con tutte le features che potranno essere nella RTM, è stata la pubblicazione del poster che descrive l’architettura di Hyper-V 3.0.

In questo articolo si andranno ad analizzare le novità di Hyper-V 3.0 prendendo spunto appunto da questo documento.

Il percorso di Microsoft, che ha portato alla nuova release dell’hypervisor di Redmond, ha coinvolto più di duecento clienti diretti che hanno suggerito e richiesto la maggior parte delle feature che andremo ad analizzare in questo articolo.

Il Team di sviluppo si è concentrato su quattro punti chiave:

Sicurezza – In Windows Server 2012, Hyper-V provvede a una nuova capacità di isolamento per tenere le macchine virtuali isolate anche quando risiedono sullo stesso server fisico. Ad esempio ora è possibile installare uno switch virtuale come il CISCO V1000 che emula in tutto e per tutto un apparato di rete fisico, abilitando così i partner Microsoft a sviluppare plug-ins per aumentare le capacità di networking e sicurezza. In questo modo si integrerà maggiormente l’infrastruttura virtuale nell’infrastruttura fisica.

Flessibilità – Un’infrastruttura flessibile, quando e dove se ne ha bisogno, è la chiave per gestire ed accedere ad una rete virtualizzata in maniera semplice. Con Hyper-V, si può scalare oltre le VLANs usando la virtualizzazione della rete e potendo allocare una macchina virtuale in qualsiasi nodo del cluster, indipendentemente dal suo indirizzo IP. Si possono migrare macchine virtuali e lo storage delle stesse anche al di fuori di un ambiente clusterizzato, oltre a automatizzare completi processi di gestione, riducendo il carico amministrativo.

Scalabilità – Hyper-V provvede al supporto fino a 320 processori logici e 4 TB di RAM per ogni host, supportando fino a 1024 Virtual CPU. Mentre per singola macchina virtuale supporta fino a 64 processori virtuali e fino a 1024 macchine virtuali su singolo host. Offre un nuovo formato di dischi virtuali che supporta dimensioni fino a 64 TB per singolo VHDX, e una resilienza aggiuntiva per abilitare la virtualizzazione di carichi di lavoro su larga scala. Altra nuove funzionalità includono la misurazione delle risorse e la traccia del consumo delle risorse fisiche, il supporto al Offloaded Data Transfer e il miglioramento del Quality of Service (QoS) per ridurre i requisiti minimi di banda di rete (includendo i requisiti per gli apparati di storage).

Alta Disponibilità – Avere la possibilità di scalare verso l’alto o migliorare le prestazioni non è sufficiente. Si ha la necessità di garantire la disponibilità delle macchine virtuali quando se ne ha bisogno. Hyper-V provvede a un’ampia varietà di opzioni di alta disponibilità (HA). Queste includono: un semplice supporto al backup incrementale, supporto fino a 4000 macchine virtuali in ambienti cluster, supporto a processi di Live Migration paralleli e la crittografia con BitLocker Drive Encryption. Si può anche usare Hyper-V Replica che permette di replicare le macchine virtuali in un altro sito e, in caso di fail, eseguirne il ripristino.

Nella tabella seguente si confrontano e riassumono alcune caratteristiche di Hyper-V 3.0 con la versione precedente e il competitor di punta del settore virtualizzazione:

Come si può notare dalla comparazione sopra riportata, il lavoro di sviluppo ha portato a quadruplicare nel peggiore dei casi i limiti di esecuzione di Hyper-V, avendo ormai caratteristiche paragonabili se non superiori alla versione di punta della concorrenza.

Sensibili miglioramenti sono stati apportati in tutti i reparti della virtualizzazione, dal networking allo storage, passando per nuove features per la VDI (Virtual Desktop Infrastructure).

RemoteFX e Virtual Desktop Infrustructure (VDI)
Sono state aggiunte nuove funzionalità in RemoteFX per aumentare le prestazioni dell’esperienza utente soprattutto in caso di VDI. La tecnologia RemoteFX è stata introdotta già in Windows 7 SP1 e in Windows Server 2008R2 per sfruttare la potenza di calcolo delle GPU installate sugli host e quindi migliorando l’esperienza utente nell’uso di macchine virtuali in VDI piuttosto che in Remote Desktop.

In Windows Server 2012 si ha la possibilità di usare RemoteFX in due modalità:

- RemoteFX Hardware GPU: situazione classica in cui gli amministratori di sistema vanno a sfruttare la GPU fisicamente installata nell’host, per i virtual desktop. Molti virtual desktop possono condividere la stessa GPU senza avere cali di prestazioni.
- RemoteFX Software GPU: Con i virtual desktop Windows 8 client, si possono distribuire delle GPU a livello software, che non prevedono la presenza di una GPU fisicamente installata nell’host di virtualizzazione, aumentando allo stesso modo l’esperienza utente.

Entrambe le modalità rendono disponibile agli utenti le seguenti funzionalità:

- RemoteFX Adaptive Graphics: questa funzionalità permette l’uso di grafica avanzata e gli effeti Aero anche su reti con alta latenza e limitata larghezza di banda.
- RemoteFX per WAN: offre una serie di miglioramenti tecnici che migliorano l'esperienza dell'utente durante la connessione su reti WAN.
- RemoteFX multi-touch: consente agli utenti l’utilizzo delle nuove gesture touch in ambienti di desktop remoto.
- Reindirizzamento USB RemoteFX: sfruttata dagli utenti di remote desktop e VDI che connettono un dispositivo USB al client locale. Con Reindirizzamento USB RemoteFX, i device USB appaiono come risorse locali, integrandoli nel remote desktop, creando un'esperienza unificata per l'utente. Questa funzionalità supporta una vasta gamma di dispositivi USB: fotocamere, webcam, scanner joystick. E tutto ciò senza dover installare alcun driver sul server host.
- RemoteFX Media Remoting, una funzione progettata per garantire un'esperienza multimediale elevata, anche sulle reti che hanno problemi di banda o di latenza.

Oltre alle tecnologia di RemoteFX la VDI può ora supportare altre due interessanti caratteristiche

- Style-UI App Remote Desktop: poter utilizzare la nuova interfaccia offerta dalle applicazioni Style-UI, graficamente ricca e facile da usare per i client di desktop remoto e i dispositivi touch.
- Dischi di profilo utente: cvengono utilizzati per memorizzare le impostazioni del profilo utente in un ambiente Pool di virtualizzazione Virtual Desktop Infrastructure (VDI) o di sessione. Con questa funzionalità, le modifiche dello stato utente sono memorizzate su un disco virtuale separato dalla Gold Image. Tali modifiche sono quindi immediatamente disponibili per l'utente all'accesso successivo, indipendentemente dalla posizione dell'utente o del dispositivo.

Mobilità Macchine Virtuali
Le caratteristiche di flessibilità e scalabilità, oltre che di alta disponibilità, sono garantite dalle capacità di spostare le macchine virtuali all’interno e al difuori dell’infrastruttura virtuale. In Hyper-V 3.0 queste capacità si descrivono in quattro punti:

- Live Migration Senza Storage Condiviso
- Live Migration con Storage SMB (NFS, CIFS)
- Live Migration in Ambiente Cluster
- Storage Migration

Live Migration Senza Storage Condiviso
La Live Migration senza storage condiviso (conosciuta anche come Shared Nothing Live Migration) abilita a eseguire la migrazione di macchine virtuali e dei loro storage associati tra server che eseguono Hyper-V all’interno dello stesso dominio. Questo tipo di Live Migration utilizza solo connessioni di tipo Ethernet, figura 1.


Figura 1 - Shared Nothing Live Migration

Usando quest’opzione, le machine virtuali continuano a essere accessibili mentre i dati vengono copiati sul server Hyper-V di destinazione, fino alla sincronizzazione dei dati in entrambi i server. Terminati poi gli ultimi task, Live Migration interrompe il canale sicuro di trasferimento dati e rende disponibile la VM migrata sul nuovo server di destinazione, eliminandola da quello di partenza.

Alcune importanti considerazioni:

- Se un guasto o un probema accade durante il processo di Live Migration Senza Storage Condiviso, la macchina virtuale rimane attiva e consistente sul server di partenza
- Questo processo può migrare macchine virtuali tra cluster e da un server al di fuori del cluster a un cluster
- Si può migrare VM tra storage di diverso tipo
- L’intero processo può essere attivato usando Windows Power Shell e quindi eseguirlo tramite script pianificato
- Non è una soluzione di alta disponibilità (HA), poiché manca l’oggetto base per questa peculiarità e cioè lo storage condiviso

Pensando agli scenari possibili ove utilizzare questa feature, eccone alcuni:

- Dove si ha un ambiente di test solitamente non in cluster perché a più basso costo, con “Shared Nothing Live Migration” è possibile trasferire una VM che abbia superato tutti i test nell’ambiente di produzione che solitamente è un cluster
- La necessità di trasportare un ambiente di produzione in un ambiente di laboratorio, senza passare ore a cercare di riprodurlo. Ovviamente le VM coinvolte non saranno disponibili in produzione fino alla successiva migrazione
- Sostituzione del server in ambienti molto piccoli, o dei server in ambienti cluster, si può migrare al nuovo hardware senza interruzione di servizio
- Migrare la VM di test dal pc con Windows 8 Client dello sviluppatore o sistemista all’ambiente di produzione

Live Migration con Storage SMB (NFS, CIFS)
Live Migration con Storage Condiviso Server Message Block (SMB) abilita a spostare macchine virtuali tra server che eseguono Hyper-V all’interno dello stesso dominio, figura 2, mentre i dati di storage rimangono sul file server. Sono supportate migrazioni in parallelo. Questo tipo di Live Migration non richiede alcuna configurazione di failover cluster.


Figura 2 - Live Migration con Storage SMB

Alcune precisazioni sulle funzionalità di questo metodo di migrazione:

- Durante il processo di migrazione i Virtual Hard Disk (VHD) risiedono sul File Server SMB 3.0. Il running state attuale della VM è migrato da un server all’altro. E’ importante notare che la connessione SMB dello storage è migrata, ma il VHD non si muove. Tempo quindi molto ridotto di trasferimento del controllo dell’oggetto tra host
- Si può inizializzare questo processo anche da Windows Power Shell con il cmdlet Move-VM

Gli scenari in cui utilizza questo metodo di migrazione live potrebbero essere:

- Il piccolo ambiente di produzione a cui si vogliono dare funzionalità di alta disponibilità a basso costo, dato che esiste uno storage condiviso che è il file server o NAS (che deve supportare SMB 3.0)
- Sempre la necessità di trasferire delle VM fra un ambiente di test a un ambiente di produzione e viceversa

Live Migration in Ambiente Cluster
E’ il primo metodo di migrazione Live (cioè a caldo) introdotto con Windows Server 2008R2 ed Hyper-V 2.0 e permette la migrazione a caldo delle machine virtuali fra i nodi di un cluster Hyper-V. E’ un processo che può essere gestito dall’amministratore di sistema oppure essere automatizzato come reazione ad un evento all’infrastruttura virtuale oppure in modo schedulato - figura 3.


Figura 3 - Live Migration in Ambiente Cluster

Possono essere selezionate più VM da migrare a caldo all’interno del cluster di failover, oppure creare una coda di Live Migration con diverse migrazioni di macchine virtuali. Ovviamente l’intero processo è avviabile da Windows PowerShell.

Storage Migration
La migrazione di storage abilita lo spostamento degli storage delle virtual machine (VHD) senza avere il down dei servizi. Questo permette nuovi scenari di servizio. Ad esempio si possono aggiungere hard disk fisici a un server singolo o ad un ambiente cluster e spostare le macchine virtuali al nuovo spazio storage mantenendo le VM attive in produzione, come mostra la figura 4.


Figura 4 - Storage Migration

Nuove Funzionalità Storage
Il fulcro dell’infrastruttura virtuale è la sezione storage. Lo storage ha il compito di garantire l’alta disponibilità delle VM, occuparsi delle copie di salvataggio, trasferire moli di dati durante le migrazioni a caldo ed essere scalabile verso l’alto in maniera esponenziale cercando di dare il minimo downtime ai servizi che supporta. Una buona infrastruttura virtuale parte proprio dalla configurazione dello storage e non, come molti pensano, dalla potenza di calcolo dei singoli host.

Hyper-V 3.0 introduce delle novità interessanti sia sul fronte delle performance, sia sul lato della scalabilità, e sono:

- Nuovo formato di VHD
- Utilizzo di server SMB 3.0
- Adattatori Virtuali Fiber Channel per le VM
- Offload Data Transfer (ODX)

Nuovo Formato di Dischi Virtuali (VHDX)
La terza generazione di Hyper-V introduce un nuovo formato dei vrtual hard disk (VHD), i file preposti a memorizzare i dati dei sistemi operativi guest. Il nuovo formato, chiamato VHDX, supporta dimensioni sino a 64TB. E’ supportato anche dalla versione client del sistema operativo Windows 8.

Utilizza un file di log per aggiornare la struttura dei metadata, che aggiunge la resilienza ai file VHDX in caso di mancanza di alimentazione improvvisa. Supporta blocchi di dimensioni più grandi, sia per dischi dinamici e differenziali, questo permette ai dischi di essere ottimizzati per le necessità dei workload virtualizzati. Infatti incrementa le prestazioni delle applicazioni specialmente su dischi fisici che hanno settori più grandi di 512 byte, supportando cluster di 4KB.

Inoltre è possibile archiviare dei custom metadata. Per esempio si possono memorizzare le versioni di sistema operativo e degli aggiornamenti che sono stati applicati. E’ interessante anche il fatto di poter gestire i file VHD e VHDX come parte dei dischi fisici del sistema operativo, quindi montarli, inizializzarli o riversarvi sopra le immagini di sistema operativo (WIM) in modo da fare boot.

Hyper-V è ora integrabile con gli storage ODX-capable permettendo un aumento di prestazioni degli host notevole, Infatti, grazie a questa tecnologia, le CPU e le schede di rete fisiche scaricano la gestione delle attività di replica e trasferimento dati all’hardware dello storage. Altra caratteristica per la scalabilità sono ora supportati dischi pass-trough (RAW) di dimensioni superiori a 256TB.

Utilizzo di Server SMB 3.0
Hyper-V può memorizzare i file delle macchine virtuali (file di configurazione, file VHD e snapshot) su un file server utilizzando Server Message Block (SMB) 3.0. Questa configurazione di storage è supportata sia in ambiente cluster sia su singoli host che eseguono Hyper-V, figura 5, dove l’archivio dei file viene usato come lo storage condiviso per il failover cluster.


Figura 5 - Storage File Server SMB 2.2

Utilizzare un dispositivo di memorizzazione con SMB 3.0 ha decisamente un costo inferiore ad una SAN, avendone però tutti i vantaggi di alta disponibilità, prestazioni e gestione. Per aumentare le prestazioni Hyper-V può sfruttare la funzionalità di accesso remoto diretto alla memoria (RDMA) delle schede di rete. Questo tipo di schede funzionano alla massima velocità con una minore latenza e un basso utilizzo di CPU. Per i carichi di lavoro di Hyper-V memorizzati su un file server permette di avere prestazioni comparabili ai dischi locali. Al momento solo i File Server basati su Windows Server 2012 supportano SMB 3.0.

Adattatori Virtuali Fibre Channel per le VM
La funzione di Hyper-V Fibre Channel virtuale per le VM, abilita le macchine virtuali ad accedere allo storage su Fibre Channel. Questo permette di virtualizzare carichi di lavoro che richiedono spazio disco su Fibre Channel, oltre a permettere di creare ambienti cluster con i sistemi operativi guest usando Fibre Channel.

Gli adattatori virtuali Fibre Channel usano la port virtualization per esporre le porte degli host bus adapter (HBA) nel sistema operativo guest. Questo abilita la macchina virtuale ad accedere in modo diretto e non filtrato alla storage area network (SAN) usando uno standard World Wide Name (WWN) associato ad essa. Possono essere attivati fino a quattro adattatori virtuali Fibre Channel per virtual machine.

Per riuscire a essere performanti, gli adattatori Virtual Fibre Channel utilizzano la tecnologia N_Port ID Virtualization (NPIV). Una porta NPIV viene creata sul server che esegue Hyper-V e viene associata all’adattatore Virtual Fibre Channel. Il World Wide Name (WWN) assegnato alla porta NPIV permette, quindi, a tutti gli I/O di essere ridiretti verso uno specifico adattatore virtuale Fibre Channel in una macchina virtuale.

Il supporto alla migrazione a caldo delle macchine virtuali con questa caratteristica attivata è garantito anche sui server che eseguono Hyper-V mantenendo viva la connettività del Fibre Channel (si veda Live Migration in Ambiente Cluster). Per supportare tutto questo, ogni adattatore Virtual Fibre Channel è configurato con due World Wide Names (WWN).

Hyper-V cambierà automaticamente tra il Set A e il Set B WWN durante una Live Migration, vedi figura 6, assicurando che tutte le unità logiche (LUN) siano disponibili al server di destinazione senza alcun disservizio durante l’operazione.


Figura 6 - Migrazione con Adattatori FC

Con gli adattatori Virtual Fibre Channel è supportato il Multipath I/O (MPIO) anche all’interno delle VM. Infatti, come detto, oltre a poter installare più schede HBA FC fisiche sul server che esegue Hyper-V, si possono attivare fino a quattro adattatori virtuali FC all’interno di ciascuna macchina virtuale. Hyper-V si occuperà di garantire il percorso valido più efficiente per raggiungere lo storage su FC.

Virtual Machine Replication
La nuova funzione Hyper-V Replica è una tecnologia asincrona di replicazione delle macchine virtuali, inclusa out-of-the-box in Windows Server 2012. E’ pensata per la business continuity ed il disaster recovery. Funziona con qualsiasi server con hardware certificato Windows Server 2012, tipologia di rete e modello di storage. Non è richiesto alcun tipo di storage condiviso. Hyper-V Replica permette di replicare singole o multiple macchine virtuali. Questa funzionalità è strettamente integrata con Hyper-V e Failover Cluastering. Si possono replicare VM da un computer che esegue Hyper-V in un sito primario (o server primario) ad un altro computer che esegue Hyper-V locato nel sito di replica (o server di replica). Il server di replica accetta il traffico di replica da uno o più server primari.

Prima che la replica delle macchine virtuali possa partire, una copia iniziale dei virtual hard disk (VHD) deve essere trasferita al server Replica. Questo processo di trasferimento iniziale è supportato da tre metodi diversi:

Utilizzo della replica attraverso la reteE’ possibile trasferire i VHD delle VM selezionate attraverso la rete sul server di Replica, immediatamente o in modo pianificato. Funziona anche attraverso Internet. I tempi sono dovuti alla dimensione dei dati ed alla larghezza di banda
Utilizzo di una copia di backup E’ possibile trasferire una copia di salvataggio dal sito di produzione al server Replica
Utilizzo di un supporto esternoE’ possibile trasferire una copia dei dischi virtuali su un’unità esterna e da li trasportarli nel server Replica

Dopo la copia iniziale dei VHD o VHDX, Hyper-V Replica spedisce i cambiamenti delle VM con frequenza pianificata, vedi figura 7.


Figura 7 - Hyper-V Replica

Questi cambiamenti sono tracciati in un file di log, che è compresso prima di essere spedito al server Replica. Sul server primario i file di log sono mantenuti con estensione .HRL e allocati nello stesso percorso dei VHD(x) replicati.

Il server Replica è configurato per accettare il traffico proveniente dalle macchine virtuali di uno o più server primari. E’ possibile scegliere due tipi di autenticazione: Kerberos o tramite certificati (HTTP o HTTPS). Si possono definire quali server primari possono replicare dati con il server Replica e si può scegliere qualunque tipo di storage per memorizzare le repliche delle macchine virtuali (SAN, NAS o Direct Attached Storage).

Hyper-V Replica esegue frequenti aggiornamenti dei cambiamenti delle macchine virtuali replicate, questo assicura che lo stato delle VM nel sito di replica sia il più prossimo a quello nel sito primario. Hyper-V Replica tiene traccia di molteplici punti di ripristino sul server. Questi sono usati per ripristinare una singola VM. I punti di ripristino sono creati ogni ora e possono contenere uno o più snapshot.

Se non sono configurati più punti di ripristino, il server Replica mantiene solo l’ultimo point-in-time di ripristino. Si può anche scegliere di utilizzare degli snapshot consistenti per applicazione in specifici intervalli, da un’ora fino a 15 ore, e per al massimo 12 snapshot per intervallo. Per eseguire tutto il processo di replica si utilizza il servizio Volume Shadow Copy (VSS).

Ovviamente utilizzando Hyper-V Replica si può eseguire anche l’operazione contraria, cioè il Failback delle macchine virtuali dal sito di Replica al sito Primario. Esistono tre opzioni principali per fare questo:

Failover Pianificato – E’ un’operazione che permette di eseguire il ripristino nel sito di produzione delle macchine virtuali in preciso momento schedulato. Con questo procedimento non ci sarà perdita di dati e dovrà essere pianificato nelle ore di chiusura dei servizi delle VM.
Test di Failover – E’ un processo che permette di testare le macchine virtuali replicate. Il Test di Failover non interrompe la replica dal sito primario al sito di replica. Al termine del processo esisterà una VM con nome “<NomeVM>-Test”.
Failover Unplanned – Nel caso di failure del sito primario, è possibile eseguire l’attivazione sul sito secondario delle macchine virtuali replicate. Si potrà scegliere fra l’ultima replica o il più recente punto di ripristino.

Gli scenari di utilizzo sono sicuramente interessanti:

- Eseguire il salvataggio per disaster recovery del sito di produzione
- Offrire il backup delle macchine virtuali al cliente finale su un sito remoto locato presso l’azienda di consulenza
- Avere un ambiente di laboratorio e sviluppo facilmente gestibile e sincronizzato con la versione ultima delle VM. A differenza della Live Migration (anche senza storage condiviso) si ha la possibilità di avere macchine virtuali di test, mantenendo i servizi in produzione

E tutto questo con il prodotto di scatola, senza dover acquisire licenze aggiuntive.

Networking
Nelle versioni precedenti di Hyper-V, il team di sviluppo si è concentrato sulle perfomance di rete e il pieno sfruttamento delle tecnologie fisiche degli adattatori di rete. In Hyper-V 3.0, oltre alle pure prestazioni sono state aggiunte opzioni di gestione e nuove funzionalità di configurazione molto interessanti. Qui di seguito se ne descrivono alcune:

Load Balancing e Failover
Fino a questo momento non era possibile utilizzare il NIC Teaming se non utilizzando driver di terze parti e con molti problemi d’implementazione e stabilità nelle precedenti versioni di Hyper-V.

In Hyper-V 3.0 il network adapter teaming (NIC Teaming), conosciuto anche come Load Balancing e Failover (LBFO), è pienamente supportato nativamente. Il NIC Teaming supporta l’aggregazione di banda e il failover del traffico, prevenendo perdite di connetività fisica. Inoltre, a differenza delle precedenti versioni, l’implementazione prevede l’uso di schede di rete multivendor, (situazioni miste con schede Intel insieme a Broadcom, oppure anche con schede Ethernet USB).

Sono supportate la modalità Switch-Indipendent e la Switch-Dipendent. Nel primo caso non è richiesto allo switch di partecipare al teaming. In questo modo è possibile collegare le diverse schede del teaming a diversi switch se necessario. Nel secondo caso lo switch è parte del teaming, e solitamente tutte le schede sono attestate sullo stesso switch.

Hyper-V supporta il NIC Teaming all’interno delle macchine virtuali. Per avere la ridondanza, la singola VM dovrà essere configurata con più schede di rete, ognuna connessa ad un differente virtual switch (modalità Switch Indipendent). In questo modo la virtual machine avrà connettività anche se una sola scheda di rete fisica abbia un problema. A livello fisico Windos Server 2012 può installare nello stesso teaming fino a 32 adattatori di rete.

Hyper-V Virtual Switch
Un'altra delle novità del networking di Hyper-V 3.0 è l’estensibilità del Virtual Switch. In questo modo è possibile aggiungere nuove capacità al componente virtual switch, come la visualizzazione e la gestione del traffico sul server che esegue Hyper-V. Ad esempio il traffico fra macchine virtuali eseguite sullo stesso server.

Usando le estensioni del virtual switch, i partner Microsoft possono aggiungere i propri filtri, monitor e funzionalità di forwarding. Tutte l’estensioni si implementano utilizzando i filtri driver Network Driver Interface Specification (NDIS) o chiamate ai driver Windows Filtering Platform (WFP). Con i filtri NDIS si possono monitorare o modificare i pacchetti di rete in Windows, con WFP si creano firewall o funzionalità di intrusion detection.

Single Root I/O Virtualization
SR-IOV è uno standard che permette ai device PCI Express di condividersi fra più di una macchina virtuale abilitando un percorso diretto verso l’hardware per l’I/O, vedi figura 8. Hyper-V supporta questo standard per le schede di rete (altro collo di bottiglia dell’infrastruttura virtuale). Con questa opzione si riducono le latenze della rete e l’utilizzo di CPU e si aumenta la banda passante.


Figura 8 - Schema SR-IOV

Le schede di rete che hanno capacità di SR-IOV sono assegnate in maniera univoca alle VM, bypassando il virtual switch nella gestione del sistema operativo per spedire e ricevere dati. Le policy e i controlli rimangono ancora sotto la gestione del sistema operativo.

SR-IOV è pienamente compatibile con la migrazione a caldo, perché il networking software è disponibile per tutto il tempo. Durante la Live Migration, le funzioni virtuali sono temporaneamente rimosse. Questo permette la migrazione usando schede di rete di differenti vendor, o nella situazione in cui SR.IOV non si disponibile nella destinazione.

Per avere SR-IOV deve essere supportato dalla scheda di rete, dal firmware, dal chipset di sistema e dal driver.

QoS - Gestione della Larghezza di Banda
La nuova funzionalità QoS abilita la possibilità di convergere più tipi di traffici di rete attraverso un singolo adattatore di rete con un livello di servizio preciso per ogni tipo. E’ possibile configurare la banda tramite le impostazioni della VM o tramite Windows PowerShell cmdlet.

Si possono definire limiti di banda minimi e massimi. Importante dire è che la gestione del minimo della banda permette che ogni servizio di rete (come la console di gestione, lo storage, la Live Migration e il traffico delle VM) si allochi in una banda condivisa quando la rete è pesantemente utilizzata e contesa. Quando la banda è liberamente disponibile, ogni servizio di rete impegna la banda di cui necessita.

Ci sono due meccanismi per forzare la banda minima. Si può usare software QoS nel server che esegue Hyper-V, oppure utilizzare schede di rete certificate per Windows che supportino Data Center Bridge (DCB).

Scalabilità
Per quanto riguarda la scalabilità, già in Tabella 1, le caratteristiche di Hyper-V 3.0 sono evidenti. Vediamo di riassumerle qui:

- Hyper-V supporta processori fisici con funzionalità di Second Layer Translation della memoria (SLAT), per intenderci tutte le CPU serie iCore di Intel e AMD Opteron. Il supporto hardware alla SLAT era già presente in Hyper-V 2.0, Nella edizione client di Hyper-V presente in Windows 8, la SLAT è una caratteristica fondamentale senza la quale l’hypervisor non si avvia. 
- L’hardware può scalare fino a 320 processori logici (i core delle CPU odierne), 4 TB di RAM e 2048 CPU Virtuali per ogni singolo host.
- Ogni singola macchina virtuale può avere fino a 64 CPU virtuali e 1 TB di RAM
- Hyper-V supporta fino a 1024 VM su singolo server e 8000 VM in ambiente cluster, che può essere ora fino a 64 nodi

Non Uniform Memory Access e le Macchine Virtuali
NUMA è un architettura multiprocessore che raggruppa memoria e processori in un nodo di calcolo, vedi figura 9. Il tempo richiesto a un processore ad accedere alla memoria all’interno di un nodo è più rapido del tempo richiesto ad accedere alla memoria di tutti i nodi. Hyper-V supporta una topologia virtuale NUMA all’interno di una VM, abilitando le virtual machine multiprocessore a scalare efficaciemente.


Figura 9 - Schema NUMA

Il sistema operativo guest e le applicazioni acquisiscono molti vantaggi nell’ottimizazione delle prestazioni NUMA. Per default la virtual topology NUMA all’interno di una macchina virtuale coincide con la Numa topology nel server che esegue Hyper-V. Questo diminuisce molto i cicli machina in cui i processi all’interno delle VM devono attendere per accedere alla memoria delle stesse.

Cluster per HA
In Windows Server 2008 R2 e Hyper-V 2.0, la grande novità riguardante l’ambiente cluster era il nuovo file system CSVFS (Cluster Shared Volume File System) pensato per condividere lo stesso volume fra i diversi nodi del cluster, evitando il proliferare di una LUN per ogni VM, necessarie per eseguire le migrazioni delle singole macchine virtuali. In Windows Server 2012, il nuovo file system supporta ora i file server SMB 3.0, e i volumi CSVFS ora sono più semplici da salvare; inoltre è possibile utilizzare tale storage anche per le applicazioni SQL Server.

Nella versione 3.0 di Hyper-V sono state migliorate e aggiunte alcune feature per gli ambienti cluster. Oltre al solito wizard di validazione della configurazione cluster, il nuovo Failover Cluster Manager aggiunge il controllo di quali VM siano clusterizzabili e su quali nodi possono essere eseguite, supportando multiple live migration controllabili tramite un monitor che visualizza lo stato delle code delle migrazioni.

Con Failover Cluster Manager ora si possono selezionare più VM contemporaneamente per poter eseguire le stesse operazioni con pochi click (ad esempio il riavvio, il save state o lo spegnimento) e si possono gestire i servizi all’interno delle VM clusterizzate, in modo da riavviare il servizio o le VM in caso di fail.

In Windows Server 2012 è possibile assegnare delle priorità alle varie macchine virtuali (High, Medium, Low e NoStart). Tali priorità indicano quali macchine virtuali devono avere la precedenza nell’uso delle risorse del cluster e l’ordine di avvio automatico.

Altra funzione interessante che riguarda il servizio Failover Cluster, ma che è implementata nel ruolo di WSUS di Windows Server 2012, è la Cluster-Aware Updating (CAU) che permette di aggiornare i nodi del cluster senza alcun disservizio delle macchine virtuali. In modo automatico le VM vengono migrate per permettere l’aggiornamento ed il riavvio del singolo nodo, per poi passare all’host successivo. Questo sicuramente rende molto più semplice mantenere in sicurezza ed efficienza l’ambiente cluster.

Conclusioni
Molte delle funzioni descritte si ritrovano anche nella versione client di Windows 8, installando l’opzione Hyper-V, e non solo in Windows Server 2012. Questo porta a una nuova convergenza dei mondi client e server, rendendo ambienti di sviluppo trasportabili in produzione con un semplice click del mouse.

Grazie all’accoppiata Windows Server 2012 e Hyper-V 3,0 viene sdoganato il concetto di Cloud Privato anche nelle situazioni più semplici, permettendo una facile manutenzione e distribuzione dei servizi. 

Hyper-V 3.0 e Windows Server 2012 rendono l’infrastruttura virtuale un ambiente standard anche per la piccola e media impresa, che con minimi investimenti hardware e software può avvantaggiarsi delle funzioni di alta disponibilità, site recovery e performance di solito presenti nei grandi datacenter.

Link Utili
http://technet.microsoft.com/library/hh831769.aspx
http://technet.microsoft.com/evalcenter/hh670538.aspx
http://blogs.technet.com/b/windowsserver/archive/2012/04/19/smb-2-2-is-now-smb-3-0.aspx