Virtualizzazione desktop: Prestare attenzione agli ambienti virtuali

  • Articolo

Wes Miller

La virtualizzazione si è evoluta da una semplice anomalia che richiedeva spiegazioni a una tecnologia produttiva di cui non è più possibile fare a meno. Può essere utilizzata per test di controllo di qualità, sviluppo, progettazione Web o formazione. Gli utenti più all'avanguardia possono impiegarla per distribuire un'infrastruttura virtuale, mentre aziende quali Amazon.com, Rackspace Inc. o altri fornitori vi ricorrono per la virtualizzazione "cloud".

Indipendente dall'impiego della virtualizzazione, un utilizzo prolungato di questa tecnologia lascia emergere alcune difficoltà a essa correlate, così come la manutenzione dei prodotti hardware fisici presenta alcuni dilemmi. Molti problemi sono diversi, altri sono simili.

Gestione degli hypervisor

In molti avranno sicuramente sentito parlare di "hypervisor", che negli ultimi tempi è divenuto un termine gettonatissimo nella virtualizzazione. Non si tratta tuttavia di un concetto nuovissimo: è infatti in circolazione da quando esistono le macchine virtuali. È stata IBM a coniare questo termine negli anni '70.

Un hypervisor è il software che offre un set di hardware virtualizzati ai guest in esecuzione "virtuale" in un sistema e astrae l'hardware fisico per i sistemi operativi guest. La confusione deriva dall'enorme successo degli "hypervisor di tipo 1" in esecuzione nella piattaforma x86 degli ultimi anni, tra cui Microsoft Hyper-V e VMware ESX Server. Gli hypervisor di uso comune (soprattutto per i sistemi client) sono noti come "hypervisor di tipo 2". Qual è la differenza?

  1. Un hypervisor di tipo 1 viene eseguito direttamente nell'hardware host e non richiede un "sistema operativo host". Microsoft Hyper-V e VMware ESX Server sono esempi tipici di un hypervisor di tipo 1.
  2. Un hypervisor di tipo 2 richiede invece un sistema operativo host. In genere un hypervisor di tipo 2 viene eseguito essenzialmente come applicazione in modalità utente nel rispettivo sistema operativo host. Microsoft Virtual PC e VMware Workstation sono esempi tipici di un hypervisor di tipo 2.

Spesso è opportuno utilizzare un hypervisor di tipo 1 per qualsiasi carico di lavoro "sempre attivo", ad esempio un'istanza di SQL virtualizzata o un file server. Come minimo, utilizzerà un numero inferiore di risorse rispetto al tipo 2, ma a seconda dell'host potrebbe richiedere un accesso utente per l'avvio, opzione tutt'altro che auspicabile per un sistema mission-critical. Un hypervisor di tipo 2, d'altro canto, ha più senso per le macchine virtuali "su richiesta". Questo tipo di ruolo include macchine virtuali impiegate ai fini di testing, compatibilità tra le applicazioni o accesso sicuro.

Quali risparmi è possibile conseguire con la virtualizzazione?

La risposta più ovvia: la virtualizzazione consente di risparmiare sull'hardware in termini economici, ma la faccenda non è così semplice. Di certo, se si dispone di due sistemi server in fattori di forma 1U montabili su rack e si caricano i due carichi di lavoro in un sistema 1U, è possibile conseguire un risparmio sui costi anticipati relativi all'hardware, ma c'è un problema: questi sistemi server funzioneranno senza problemi in due singoli server 1U, ognuno dei quali dispone di CPU dual core, 2 GB di RAM e un disco rigido SATA da 160 GB.

Ora, se collochiamo entrambi i sistemi in un solo server con la stessa configurazione hardware, sarà necessario dividere le risorse a metà. Per un hypervisor di tipo 2 è in genere necessario un numero maggiore di risorse.

Tenere quindi in considerazione i costi necessari relativi a CPU, RAM e HDD nel momento in cui si stabilisce la modalità di consolidamento dei carichi di lavoro da un ambiente fisico a un ambiente virtuale. Il consolidamento virtualizzato viene spesso definito "un insieme di sistemi impilati in verticale, anziché in orizzontale", in quanto si rimuovono da un OEM le dipendenze da n sistemi fisici. È inoltre necessario più di un sistema individuale rispetto a quanto accadeva prima della virtualizzazione. Viene dunque a crearsi un "rimbalzo" della gestione dei sistemi che molte organizzazioni tendono a trascurare nel progresso verso la virtualizzazione.

Quali sono i costi legati alla virtualizzazione?

Tanto, tanto tempo fa, un buon software di virtualizzazione comportava costi ingenti. Nel tempo il mercato si è surriscaldato e oggi è possibile acquistare diversi tipi di software per la virtualizzazione a un prezzo decisamente ridotto. La maggior parte delle funzionalità aziendali più importanti, tra cui il sistema operativo host o l'hypervisor, sono tuttavia ancora costose.

A seconda del carico di lavoro che si intende eseguire in una macchina virtuale, potrebbe essere necessario esaminare il failover. I guest possono a volte danneggiarsi e l'hardware host potrebbe smettere di funzionare. La virtualizzazione non rende l'hardware più affidabile: cambia semplicemente le carte in tavola. Per i sistemi mission-critical è comunque necessario sviluppare una strategia di backup del sistema operativo guest, indipendentemente dalla scelta di eseguire il backup del contenitore stesso della macchina virtuale (opzione vivamente consigliata) o solo il file system contenuto al suo interno.

Anche in caso di virtualizzazione di un gruppo esiguo di sistemi operativi guest ai fini di testing o sviluppo in un hypervisor di tipo 2, sarà comunque necessario allocare una quantità di RAM sufficiente a eseguire uno o più guest contemporaneamente (sulla base del sistema operativo host). Uno dei problemi più sottovalutati nella gestione della virtualizzazione riguarda l'utilizzo dello spazio sul disco.

Utilizzo la virtualizzazione da diverso tempo come banco di prova per la sicurezza. Non c'è niente di meglio che eseguire un potenziale exploit in una macchina virtuale, osservarne il funzionamento ed eseguire il rollback a una versione precedente utilizzando la funzionalità di snapshot o rollback dell'hypervisor, per poi testarlo una seconda volta. Ciò che colpisce di più nella possibilità di impilare in modo verticale queste modifiche di rollback è l'eventualità che lo spazio sul disco aumenti in modo estremamente rapido, arrivando a superare di gran lunga le dimensioni effettive del disco rigido all'interno del sistema operativo guest stesso.

Una delle macchine virtuali che utilizzo più spesso presenta un'immagine dei disco rigido da 50 GB: non mi ero accorto di quanto avessi superato il limite finché non ho avuto bisogno di spostarla (aveva sei snapshot VMware) e il disco superava i 125 GB.

 Ecco alcune procedure consigliate per ridurre l'impatto e i costi della virtualizzazione:

  • Se si utilizza un sistema operativo client Windows in un hypervisor di tipo 2 con la funzionalità di "rollback", è essenziale disabilitare Ripristino configurazione di sistema di Microsoft Windows. In caso contrario, le dimensioni del disco aumenteranno ogni volta che verrà effettuata una modifica di sistema.
  • Se si esegue il passaggio 1, non dimenticare di indicare il punto in cui si desidera creare il rollback.
  • Se si eseguono test di sicurezza o per il rilevamento di exploit, non affidarsi a Windows per eseguire il rollback a un punto precedente, ma utilizzare la funzionalità di rollback dell'hypervisor, che tende a subire minori danneggiamenti rispetto ai punti di ripristino.
  • Eseguire i sistemi operativi guest con la quantità minima di risorse necessaria.
  • Accertarsi di aver allocato una quantità di RAM sufficiente a evitare che i sistemi operativi client condividano ogni volta la RAM sul disco, rallentando l'host e tutti i guest.
  • Deframmentare i guest a livello interno e quindi a livello esterno (vedere più avanti la sezione relativa alla deframmentazione). Eseguire entrambe le operazioni con una certa regolarità.

Proliferazione di macchine virtuali

Come risulta evidente, la gestione delle macchine virtuali può in un attimo trasformarsi in un problema. La semplicità con cui è possibile duplicare una macchina virtuale può rappresentare un vantaggio notevole, ma al contempo creare enormi problemi nella gestione e nella protezione dei guest, nella capacità di tenere traccia delle licenze del sistema operativo con Windows (nelle versioni precedenti a Windows Vista, in quanto in quest'ultimo sistema la nuova gestione delle chiavi può risultare particolarmente utile) e in quella di mantenere protetti i segreti commerciali. È molto più semplice per un impiegato malintenzionato portarsi a casa una macchina virtuale con un'unità flash o un disco rigido USB rispetto a un intero sistema desktop.

La proliferazione delle macchine virtuali è un problema che riguarda essenzialmente gli esperti tecnici in grado di comprendere ogni singolo aspetto della virtualizzazione. In genere è predominante anche tra i guest client e non tra i guest server virtualizzati.

Gestione dei sistemi

Intere società hanno iniziato a concentrarsi sulla possibilità di garantire nuovamente il controllo sui sistemi virtualizzati. Sia Microsoft che VMware hanno di proposito trascurato il valore della virtualizzazione stessa per puntare l'attenzione sulla gestione dei sistemi. Si tratta di un dato importante, in quanto i sistemi non vengono eliminati, ma virtualizzati.

Molti prodotti per la gestione dei sistemi funzionano alla perfezione nelle macchine virtuali, ma alcune funzionalità più recenti consentono una gestione più intelligente dei sistemi virtualizzati, ad esempio tramite la riattivazione e l'aggiornamento di guest che altrimenti risulterebbero obsoleti. Nell'era degli exploit di tipo zero-day, si tratta di una questione critica. È opportuno evitare che una macchina virtuale inutilizzata divenga un elemento della botnet locale nella rete aziendale.

Un approccio mirato alla gestione dei sistemi deve tenere conto del fatto che esistono host e guest, garantirne un aggiornamento appropriato e fare in modo che i ruoli di ogni elemento siano ben chiari. Non è proprio il caso di ritrovarsi con una soluzione di gestione patch progettata in modo approssimativo per l'aggiornamento dell'hypervisor e magari essere costretti a demolirla per un riavvio insieme a quattro server guest mission-critical.

Sarà inoltre necessario adottare un approccio per il ripristino di questi sistemi come in passato. Solo perché un sistema è virtualizzato, non significa che non sia possibile perderlo a causa di un danneggiamento del Registro di sistema o dell'intera macchina virtuale. È sempre opportuno eseguire il backup come per i sistemi fisici.

Un'altra considerazione da non trascurare riguarda la presenza o meno della funzionalità di rollback nell'hypervisor. Si tratta di una questione da tenere presente in caso di gestione patch. È semplice aggiornare un guest di mercoledì dopo aver applicato una patch di martedì ed eseguire il rollback al punto del lunedì, per poi ritrovarsi sotto un attacco di tipo zero-day per cui in teoria si disponeva di un tipo di protezione. Un bel problema, dal momento che le tecnologie di questo tipo eseguono il rollback a un punto precedente rispetto alla presentazione del disco dall'hypervisor. In altre parole, verrà persa qualsiasi patch Windows e di applicazione, nonché qualsiasi firma antivirus.

Software di protezione

Oltre alla funzionalità di rollback, è necessario fornire ai guest virtualizzati lo stesso livello di protezione dei computer fisici, se non superiore. Le macchine virtuali sono soggette a minacce in ingresso in modo analogo ai computer fisici, né più o né meno.

La differenza risiede nel fatto che le macchine virtuali non critiche (ovvero quelle che non rimangono sempre attivate) presentano spesso una latenza relativa a patch e aggiornamenti antivirus e possono pertanto divenire un bersaglio più semplice e appetibile per gli exploit di tipo zero-day. In virtù di queste considerazioni è opportuno utilizzare una soluzione avanzata per la gestione dei sistemi in grado di ovviare a questi problemi e applicare patch anche ai sistemi virtuali.

Le minacce in uscita sono un'altra questione. Le macchine virtuali possono incoraggiare il furto di proprietà intellettuale. Si tratta di una questione essenziale da comprendere, in quanto le macchine virtuali in esecuzione in host non controllati possono creare una sorta di "via di fuga" per i dati. Il primo problema da considerare riguarda la semplicità con cui è possibile copiare l'ambiente virtuale, soprattutto in caso di requisiti di conformità che regolano l'accesso ai dati (come già illustrato in un articolo del 2008, https://technet.microsoft.com/magazine/2008.06.desktopfiles).

Secondo problema: come ho già spiegato in un articolo su RMS e IRM (https://technet.microsoft.com/magazine/2008.11.desktopfiles), questi controlli si affidano al sistema operativo per impedire operazioni di acquisizione dello schermo, stampa e così via. Tali controlli sono tuttavia eludibili nell'hypervisor: se infatti un contenuto protetto da RMS viene visualizzato in un sistema operativo guest, dal sistema host sarà comunque possibile stampare singole catture di schermata o creare un'acquisizione video dello schermo.

Seppur con alcune differenze dal punto di vista tecnico, questa situazione è piuttosto simile al cosiddetto "analog hole". Non conosco alcun modo per proteggere contenuti controllati da DRM da exploit di questo tipo. In effetti, anche se ci fosse, risulterebbe comunque impossibile difendersi da utenti provvisti di fotocamere o dispositivi di videoregistrazione in grado di eseguire lo stesso tipo di attacco.

Deframmentazione del disco

La deframmentazione del disco presenta diverse difficoltà nelle macchine virtuali per vari motivi:

  1. Esistono in genere due livelli di frammentazione: all'interno del contenitore stesso del disco virtualizzato (ovvero la frammentazione già presente nel disco), che chiamerò "frammentazione primaria", e la frammentazione del file contenente il disco virtualizzato tra i dischi del sistema operativo host, o "frammentazione secondaria".
  2. I prodotti di virtualizzazione con dischi di dimensioni minime in grado di crescere "su richiesta" possono determinare una frammentazione secondaria.
  3. La funzionalità di rollback rischia di aumentare in modo eccessivo le dimensioni del disco, ma anche della frammentazione secondaria, in quanto occuperà ulteriore spazio sul disco del sistema operativo host e ogni guest si troverà a competere con gli altri per conquistare i settori disponibili.
  4. In caso di dischi con crescita su richiesta, molti non sono in grado di ridursi al termine dell'attività. Se si allocano 40 GB, si utilizzano inizialmente solo 10 GB e quindi si necessita di un ulteriore spazio di 35 GB, il disco non ritornerà alla situazione iniziale, con il rischio di disporre di un nuovo file di grandi dimensioni che subirà una frammentazione secondaria.

Le dimensioni dei dischi virtuali, la velocità con cui possono variare, diminuire o aumentare e il fatto che siano soggetti a due tipi di frammentazione lasciano intendere che questa tecnologia necessita di un livello di attenzione superiore rispetto ai sistemi fisici.

Ecco un approccio per proteggere i file:

  1. Ridurre al minimo l'utilizzo della tecnologia di rollback, che determinerà altrimenti una crescita eccessiva dei file del disco. Questi file non potranno inoltre essere deframmentati nel guest, sebbene l'host sia in grado di deframmentare i file che comprendono il disco virtuale.
  2. Utilizzare un prodotto affidabile di deframmentazione del disco nei guest ed eseguirlo regolarmente.
  3. In caso di utilizzo della tecnologia di espansione del disco su richiesta:
    a. Utilizzare l'utilità Sysinternals sdelete.exe nel modo seguente: sdelete –c lettera_unità, in cui lettera_unità rappresenta il volume da azzerare. Nell'esempio sdelete –c C: verrà azzerato tutto lo spazio su disco inutilizzato dopo la deframmentazione.
    b. Utilizzare una tecnologia di riduzione del disco virtuale (se disponibile tramite il fornitore) per ridurre il contenitore del disco virtuale alle dimensioni minime
  4. Deframmentare i volumi del sistema operativo host contenente le macchine virtuali.

In molti sottovalutano la deframmentazione dei dischi. Il volume di posta che ho ricevuto dai miei lettori in riferimento al mio articolo sulla deframmentazione dei dischi nel 2007 (technet.microsoft.com/magazinebeta/2007.11.desktopfiles) dimostra che si tratta spesso di un argomento preso sotto gamba, ma che merita il massimo dell'attenzione, soprattutto nei sistemi virtualizzati.

Man mano che la virtualizzazione diviene sempre più importante e diffusa, è fin troppo facile concentrarsi essenzialmente sul concetto di "consolidamento", trascurando i costi e le complessità che ne derivano. In questo modo sarà invece possibile comprendere meglio l'entità di alcuni costi aggiuntivi se si desidera optare per una soluzione di virtualizzazione.

Wes Miller* è direttore della divisione Product Management in CoreTrace (CoreTrace.com) ad Austin, Texas. In precedenza ha lavorato per Winternals Software e come Program Manager in Microsoft. È possibile contattarlo all'indirizzo* technet@getwired.com.

Contenuto correlato