Windows Server Virtualization - obiettivi di sviluppo
Questo post, come altri che seguiranno sullo stesso argomento, sono basati su documentazione originale del team di sviluppo di Windows Server Virtualization ed in particolare di Jeff Woolsey
Nella fase di progettazione di Windows Server Virtualization (code name Viridian), il team di sviluppo si è posto una serie di obbiettivi chiari e ben definiti. Descriverli con il rigore e la precisione tecnica adeguati richiederebbe molto spazio. Provo, quindi, a darne una visione concisa, adatta ad un blog.
SICUREZZA
Windows Server virtualization deve fornire un’elevata sicurezza dato che risiede al più basso livello, appena sopra l’hardware. Due principi base sono alla base della sicurezza isolamento e minimalismo. Analizziamoli un po’ più in dettaglio.
Isolamento
L’hypervisor deve isolare il proprio codice e i propri dati dall’osservazione e dalla modifica da parte di codice in esecuzione in qualsiasi partizione. In aggiunta l’hypervisor deve fornire mutuo isolamento tra le diverse partizioni consentendo a ciascuna l’esecuzione senza interferenza o osservazione da parte di codice in esecuzione nelle altre. Questo include:
- Isolamento dei dati – codice e dati nello spazio di indirizzamento di una partizione non devono essere accessibili alle altre partizioni (a meno di esplicita condivisione).
- Isolamento temporale – ad una partizione non deve essere possibile “rubare” tempo macchina ad un’altra partizione (per evitare DoS).
- Isolamento interno – l’hypervisor deve mantenere isolamento interno tra le partizioni (es. differenti pool di memoria per ogni partizione).
Minimalismo.
L’hypervisor è eseguito nel più privilegiato possibile dei modi e ha accesso a tutte le risorse della macchina. Minimizzare la quantità di codice che gira in questo contesto è fondamentale da un punto di vista della sicurezza (oltre che delle prestazioni) in quanto in questo modo si riduce la “superficie” esposta a possibili tentativi di attacco. La stretta aderenza al concetto di minimalismo è una delle chiavi di differenziazione dalle soluzioni di altri fornitori.
AFFIDABILITA'
È evidente che l’uso della virtualizzazione rende l’affidabilità dei sistemi più importante che mai. Lo stack di virtualizzazione e la partizione parent costituiscono un possibile “point of failure” per tutte le partizioni child (ossia: molti server virtuali sono “sostenuti” e funzionano grazie alla strato di virtualizzazione). È imperativo che i componenti di virtualizzazione siano il più affidabili e resistenti possibili ai crash e agli attacchi di sicurezza. Questo significa anche che il sistema operativo in esecuzione nella partizione parent deve essere il più leggero possibile e contenere la minor quantità possibile di codice di terze parti o non collegato alla virtualizzazione (ancora una volta il concetto di minimalismo).
Quando si esegue un workload per server fisico, la caduta di quest’ultimo, per un qualsiasi motivo (problemi HW o SW, installazione di patch, …) è un problema, ma ha effetto su un solo servizio (o un numero limitato di servizi).
In un ambiente virtualizzato dove su un unico server fisico sono in esecuzione per esempio 20 server virtuali, la caduta del server fisico ha un impatto su 20 diversi workload. Questo è uno dei motivi, come vedremo, per cui virtualizzazione e clustering viaggiano appaiati.
Per aumentare l’affidabilità del sistema sono stati seguiti un paio di concetti chiave:
Semplicità
Una serie di tecniche e decisioni di architetturali hanno consentito di rendere semplice la struttura dell’hypervisor.
Stratificazione
Un disegno a livelli sovrapposti è richiesto per ottenere alcune certificazioni di sicurezza (es. EAL-6/EAL-7, i livelli più elevati di certificazione previsti dai Common Criteria) e per garantire una migliore modularità e funzionalità. Windows hypervisor è stato costruito con un approccio a livelli sovrapposti.
Per comprendere meglio i vantaggi che un’architettura a livelli sovrapposti comporta, la si deve confrontare con l’architettura tradizionale degli hypervisor. Prendiamo in considerazione un hypervisor puramente teorico e non basato su alcun prodotto reale, ma utile per il confronto.
L’immagine precedente mostra una delle possibili implementazioni di un hypervisor.La cosa importante in questa architettura sono le linee che congiungono i diversi componenti. In un approccio tradizionale, come quello rappresentato, i dati fluiscono da un componente all’altro in una configurazione a matrice. Con questa architettura è molto difficile testare l’affidabilità di un componente che può dialogare con qualsiasi altro, in ogni dato istante.
Confrontiamo questo approccio con un’architettura a livelli sovrapposti come quella adottata in Windows Server Virtualization.
In un disegno di questo tipo i dati possono fluire orizzontalmente o verticalmente, ma non secondo una matrice dove ogni componente può interagire con qualsiasi altro: non ci sono possibili flussi circolari.
Se per esempio il Dispatch Manager (Dm) deve comunicare con il gestore dell’indirizzamento (Address manager – Am), il flusso di dati avverrà verso il basso attraverso il gestore delle hypercall (Hypercall handler – Hc), il gestore delle partizioni (Partition Manager – Pm)e il Synthetic Interrupt Controller (SynIC).
La cosa importante è che esiste un numero finito e di percorsi che portano da un componente ad un altro qualsiasi, verso l’alto o verso il basso. La lunghezza dei percorsi è deterministica e questo consente di imporre dei limiti temporali precisi ai percorsi di esecuzione dell’hypervisor.
Minimalismo
(concetto che ritorna) Per aumentare la semplicità dell’hypervisor è stato deciso di implementarlo come un micro-kernel: tutte le funzionalità che per motivi sicurezza o prestazioni non devono essere necessariamente nell’hypervisor sono state spostate nello stack di virtualizzazione in esecuzione dentro una partizione.
Su questo aspetto ci sono almeno due diverse scuole di pensiero. In VMware ESX3/VI3, il codice che emula l’hardware legacy gira nello stesso contesto dell’hypervisor. VMWare dice che in questo modo si guadagnano uno o due punti percentuiali nelle prestazioni.
Microsoft (e Xen che ha una visione molto simile), in Windows Server Virtualization, ha messo quasi tutto il codice di questo tipo nello stack di virtualizzazione, non nell’hypervisor. Poche risorse, strettamenete legate alle prestazioni sono implementate direttamente nell’hypervisor (per esempio l’APIC virtuale e certi interrupt hardware periodici sono due esempi di questo). Questa modalità di implementazione consente di ridurre la possibile superficie di attacco e rende l'architettura dell'hypervisor più robusta e affidabile.
SCALABILITA'
Tutti le tecnologie di virtualizzazione (Microsoft e no) presenti oggi sul mercato hanno dei limiti. In alcuni casi questi limiti sono più stringenti e in altri più ampi e consentono maggiore scalabilità, ma il punto è che le tecnologie di virtualizzaione hanno ancora un ampio spazio di evoluzione e maturazione.
Esempi di limiti delle attuali tecnologie sono :
Virtual Server
1. Memoria fisica supportata : 64 GB in VS2005 R2 - 256 GB in VS2005 R2 SP1 su Windows x64
2. Numero di VM in esecuzione contemporanea: 64 in VS2005 R2 – un numero maggiore in VS2005 R2 SP1 su Windows x64
3. Un solo processore per VM
4. 3.6 GB di RAM per VM
5. 4 schede di rete virtuali per VM
VMware ESX/VI3
1. Memoria fisica suportata : 64 GB perché ESX3/VI3 è un hypervisor a 32Bit
2. Il numero di macchine virtuali eseguite contemporaneamente è limitato a 128 core virtuali:
i. 128 VM a singolo core
ii. 64 VM dual core
iii. 32 VM a quattro core
3. Memoria virtuale per VM limitata a 16 GB. Questo significa poter avere al massimo 4 VM a 16 GB per server
4. 4 schede di rete virtuali per VM
5. Compatibilità hardware relativamente limitata
Il team di sviluppo di Windows Server Vitualization ha disegnato un’architettura di virtualizzazione che scala facilmente e non richiederà un ridisegno in pochi anni a causa della comparsa sul mercato di nuvo hardware con più core, più capacità di memoria o di rete.
Windows Server Virtualization non ha limiti di disegno o ha limiti molto, molto ampi.
Due soli dati a sostegno di queste affermazioni:
· Windows Server Virtualization può scalare fino a 2 terabyte di memoria fisica.
· Windows ServerVvirtualization non ha limiti sul numero di VM in esecuzione contemporanea. L’unico limite è posto dall’hardware su cui è eseguito.
Per oggi ci fermiamo qui.
Giorgio