Elaborato Crispano Naomi N46000048

Transcript

Valutazione della tecnologia di virtualizzazione OpenVz
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Elaborato finale in Reti di Calcolatori
Valutazione della tecnologia di
virtualizzazione OpenVZ
Anno Accademico 2010/11
Candidato:
Naomi Crispano
matr. N46000048
I
Ai miei genitori.
Il loro appoggio mi ha portato dove sono.
II
Indice
Introduzione
4
Capitolo 1. La virtualizzazione: definizione e tipologie
7
1.1
1.2
1.3
1.4
1.5
1.5.1
Realizzazione del VMM
Virtualizzazione completa
Paravirtualizzazione
VMM di sistema e VMM ospitati
Virtualizzazione a livello di sistema operativo
Il concetto di Container
11
13
18
22
24
26
Capitolo 2. OpenVZ
2.1
2.2
2.2.1
2.2.2
2.2.3
28
Concetto di Virtual Environment
Kernel di OpenVZ
Virtualizzazione e isolamento
Gestore delle risorse
Checkpointing e migrazione live
29
29
30
31
32
Capitolo 3. Funzionalità di OpenVZ
3.1
3.1.1
3.1.2
3.1.3
3.2
3.2.1
3.2.2
3.2.3
3.3
3.3.1
3.3.2
33
Caratteristiche distintive di OpenVZ
Applicazioni
Networking
Template
Come funziona OpenVZ
I modelli
Le licenze
Considerazioni sull’Hardware
Utilizzo concreto della tecnologia OenVZ
Installazione di OpenVZ
Creazione di un Container
34
36
37
38
39
40
42
45
47
47
52
Bibliografia
55
Ringraziamenti
56
3
Introduzione
Prima di affrontare la tematica in oggetto di questa Tesi, intendo rispondere
innanzitutto a delle domande in modo da chiarire lo scenario in cui ci si sta
muovendo.
Cos'è una macchina virtuale?
In informatica il termine macchina virtuale (VM) indica un software che crea
un ambiente virtuale che emula il comportamento di una macchina fisica.
In origine, il termine virtual machine veniva usato per indicare la creazione di
una molteplicità di ambienti di esecuzione identici in un unico computer,
ciascuno con il proprio sistema operativo.
Figura 1 - Esempio di molteplicità di ambienti su un solo pc
4
In qualsiasi momento possiamo aprire una finestra e al suo interno viene avviato
quello che appare come un computer totalmente diverso e autonomo con un
sistema operativo diverso e programmi differenti. Lo scopo di questa tecnica era
quello di dividere tra più utenti l'uso di un singolo computer dando ad ognuno
l'impressione di esserne gli unici utilizzatori, oltre ad avere vantaggi che le
macchine reali non hanno (poniamo il caso di dover riavviare la macchina ad
esempio, con macchine virtuali questa operazione è più veloce anche perché c'è
la possibilità di scegliere quali componenti attivare e quali no).
Perché utilizzarle?
Ci sono dei casi in cui emulare altri sistemi operativi dal proprio sistema
operativo principale può portare notevoli vantaggi:
• per esempio quello della sicurezza. Quando si
naviga un eventuale virus verrebbe preso dal
sistema operativo virtuale e non da quello reale;
• per provare nuovi programmi potenzialmente
dannosi,
• per conoscere altri sistemi operativi diversi dal
Figura 2 - Sicurezza nel Web
nostro.
Questa soluzione che appare ideale aveva però due svantaggi:
era costosa e l'emulazione del secondo sistema operativo virtuale, rallentava
tutto. Questi svantaggi sono stati ormai superati per la diffusione dei nuovi
computer cui le risorse non mancano.
5
Che differenza c'è tra virtualizzazione e avere una partizione con un
nuovo sistema operativo? Dove si hanno maggiori vantaggi?
La virtualizzazione consente di avere uno o più sistemi operativi funzionanti
contemporaneamente all'interno del sistema operativo principale, a costo di una
lentezza (leggermente) maggiore, minori prestazioni grafiche, maggior utilizzo
di memoria.
Una partizione con un nuovo sistema operativo, è invece il modo di avere un
sistema operativo completamente nuovo e separato dall'attuale, che non risente
di alcuna limitazione, ma che non si può utilizzare in contemporanea con altri
sistemi operativi.
6
Capitolo 1
La virtualizzazione: definizione e tipologie
Il concetto di virtualizzazione è da tempo ampiamente utilizzato in vari settori della
computer science, dalla progettazione di sistemi software complessi (esempio,
sistemi operativi), ai linguaggi di programmazione, alle architetture dei
processori e alla trasmissione dei dati.
Da un punto di vista generale le tecnologie di virtualizzazione puntano a
disaccoppiare il funzionamento logico delle risorse hardware e software di un
sistema di elaborazione dalla loro realizzazione fisica, con l’obiettivo di
ottenere maggiore efficienza, affidabilità e sicurezza. Il disaccoppiamento è
ottenuto introducendo tra le due viste della risorsa, la logica e la fisica, un
livello di indirezione la cui realizzazione dipende dal tipo di virtualizzazione
che si intende adottare.
Un primo esempio di virtualizzazione coincide con il concetto di astrazione.
In questo caso l’obiettivo è semplificare l’uso di una risorsa nascondendo
alcuni aspetti di dettaglio relativi alla sua realizzazione. Si parla in questo caso
di risorsa virtuale (oggetto astratto) e il livello di indirezione introdotto è
costituito dalle operazioni (interfaccia) con le quali è possibile accedere alle
risorse. Questo concetto di virtualizzazione viene normalmente applicato nella
7
progettazione di sistemi di elaborazione complessi, che vengono organizzati
come un insieme di livelli di astrazione strutturati gerarchicamente. Al livello
più esterno le applicazioni dispongono di una macchina virtuale il cui set di
istruzioni è composto dalle istruzioni non privilegiate della macchina fisica e
da un insieme di nuove istruzioni rappresentate dalle funzioni fornite dal S.O.
(system call), mediante le quali è possibile accedere alle risorse del sistema in
modo semplice e sicuro.
Il sistema di elaborazione è visto come un insieme di macchine virtuali, una per
ogni processo attivo, che utilizzano tutte lo stesso livello di disaccoppiamento
dalla macchina fisica rappresentato dall’interfaccia fornita dal S.O. Esse
dipendono quindi dal S.O. di cui utilizzano le system call e dall’hardware sul
quale sono eseguite.
Un caso diverso di macchina virtuale si presenta quando il livello di
disaccoppiamento dalla macchina fisica è rappresentato dal codice generato da
un compilatore di un linguaggio del tipo HLL. Tale codice, chiamato codice
astratto, risulta completamente indipendente dal set di istruzioni della
macchina fisica e dalle system call del S.O. che in essa opera. Si parla in questo
caso di macchina virtuale a livello di linguaggio.
L’obiettivo di questa VM è permettere la portabilità dello stesso codice astratto
su molteplici piattaforme (hardware e S.O.) diverse. Ciascuna di queste
realizza una VM capace di caricare ed eseguire il codice astratto e un insieme
di librerie specifiche. Nella sua forma più semplice, la VM contiene un
interprete e, nei casi più sofisticati, un compilatore, che partendo dal codice
astratto genera codice per la macchina fisica sulla quale la VM è in esecuzione.
Un esempio ben noto di tale paradigma è la Java Virtual Machine (JVM).
Lo sforzo di implementare per le architetture più comuni una VM capace di
caricare ed eseguire il codice macchina astratto è ben ripagato dalla piena
portabilità del software attraverso le piattaforme.
8
Un diverso utilizzo del concetto di virtualizzazione, prevede l’introduzione di
un livello di indirezione, che si chiama Virtual Machine Monitor (VMM) o
hypervisor il cui compito è quello di trasformare la singola interfaccia di
macchina fisica in N interfacce virtuali. Ciascuna di queste interfacce
(macchine virtuali) è una replica della macchina fisica dotata quindi di tutte le
istruzioni del processore (sia privilegiate che non privilegiate) e delle risorse
del sistema (memoria, dispositivi di I/O). Su ogni macchina virtuale può essere
eseguito un sistema operativo. Compito del VMM è quindi consentire la
condivisione da parte di più macchine virtuali di una singola piattaforma
hardware. Esso si pone come mediatore unico nelle interazioni tra le macchine
virtuali e l’hardware sottostante, garantendo un forte isolamento tra loro e la
stabilità complessiva del sistema.
Un primo esempio di tale tipo di architettura è quello introdotto da IBM negli
anni ‘60 col sistema di elaborazione denominato originariamente CP/CMS e
successivamente VM/370. Il CP (Control Program) svolge le funzioni del
VMM, viene eseguito sulla macchina fisica ed ha il solo compito di creare più
interfacce della stessa, senza fornire alcun servizio all’utente. Ciascuna di
queste interfacce (macchine virtuali) è una replica del semplice hardware.
Il CMS (Conversational Monitor System) è il sistema operativo, interattivo e
monoutente, che gira su ogni macchina virtuale. L’idea architetturale delle
macchine virtuali, propria del nuovo sistema, consentiva ad ogni utente, tramite
il CP, di avere la propria macchina virtuale con la propria partizione sul disco e
di supportare lo sviluppo dei suoi programmi in tale macchina virtuale tramite
il CMS. Tutta l’architettura risultava più semplice da gestire rispetto ad un
tradizionale sistema time-sharing in quanto risultavano separate, e quindi
sviluppabili indipendentemente, le due parti di suddivisione dell’uso delle
risorse fisiche tra gli utenti e di mascheramento per l’utente delle peculiarità
dell’hardware. Inoltre, poiché ogni macchina virtuale era funzionalmente
9
identica all’hardware della macchina fisica, era possibile mettere in esecuzione
su di esse qualunque sistema operativo compatibile con l’hardware stesso e
diverse macchine virtuali potevano eseguire differenti sistemi operativi.
Un altro aspetto di interesse era l’elevata affidabilità del sistema dal momento
che la struttura del VMM consentiva l’esecuzione separata delle macchine
virtuali garantendo quindi che un errore in un sistema operativo non avesse
influenza sull’esecuzione degli altri S.O.
La diffusione in quegli anni di questo tipo di architettura portò anche alla
progettazione di architetture hardware pensate per consentire in modo
efficiente di soddisfare queste esigenze di virtualizzazione.
A partire dagli anni ‘70 si sono diffusi i moderni sistemi operativi multitasking
e contemporaneamente si è assistito ad un crollo nel costo dell’hardware. I
mainframe hanno progressivamente lasciato il posto ai minicomputer e ad un
paradigma del tipo “un server per ogni applicazione”, e così lo sviluppo dei
VMM si è interrotto al punto che le architetture non hanno più fornito
l’hardware necessario per implementarli in modo efficiente.
Si può ricordare che un caso particolare di virtualizzazione si presenta quando
si richiede l’esecuzione di programmi compilati per un certo insieme di
istruzioni su un sistema di elaborazione dotato di un diverso insieme di
istruzioni. Si parla in questo caso di emulazione. Il modo più diretto per
emulare è interpretare: un programma interprete legge, decodifica ed esegue
ogni singola istruzione utilizzando il nuovo set di istruzioni. È un metodo
molto generale e potente, ma produce un sovraccarico mediamente molto
elevato poiché possono essere necessarie decine di istruzioni dell’host per
interpretare una singola istruzione sorgente.
Una famosa implementazione, molto cara agli appassionati di giochi, è
MAME, una VM per host IA-32 in grado di caricare ed eseguire il codice
binario originale delle ROM dei videogiochi da bar degli anni ’80, emulando
10
l’hardware tipico di quelle architetture. Facendo leva
sull’enorme potenza di calcolo degli attuali PC rispetto ai
primordiali processori per videogiochi dell’epoca, la VM
può tranquillamente operare secondo il paradigma
dell’interpretazione
senza
compromettere
in
modo
significativo l’esperienza di gioco, almeno per i
videogiochi più vecchi che non facevano ancora un uso
Figura 3 - Marchio MAME
massiccio della grafica.
1.1 Realizzazione del VMM
Come si è visto nel paragrafo precedente, compito del VMM è consentire la
condivisione, da parte di più macchine virtuali, di una singola piattaforma
hardware. Il VMM espone ad ogni macchina virtuale un insieme di interfacce
hardware funzionalmente equivalenti a quelle di una macchina fisica e si pone
come mediatore unico nelle interazioni tra le macchine virtuali e l’hardware
sottostante, garantendo un forte isolamento tra esse e la stabilità complessiva
del sistema
Al di là dei modi diversi in cui si può progettare un VMM, esso deve
comunque soddisfare poche condizioni essenziali: fornire un ambiente per i
programmi sostanzialmente identico a quello della macchina reale; garantire
una
elevata
efficienza
nella
esecuzione
dei
programmi;
possedere
caratteristiche di elevata semplicità.
Il primo obiettivo richiede che qualsiasi programma eseguito all’interno di una
macchina virtuale generi lo stesso risultato che si otterrebbe se il programma
fosse eseguito direttamente sulla macchina reale. Le uniche differenze possono
11
essere legate alle dipendenze temporali imposte dalla presenza delle altre
macchine virtuali concorrenti e dalla disponibilità di risorse di sistema.
Il secondo obiettivo, l’efficienza, richiede che l’overhead imposto dalla
virtualizzazione sia comunque tale da offrire all’utente l’illusione di operare
sulla macchina reale. Per ottenerlo occorre che un sottoinsieme statisticamente
dominante delle istruzioni del processore virtuale siano eseguite direttamente,
senza la mediazione del VMM, sul processore reale. Questo approccio, noto
come esecuzione diretta, è centrale per potere realizzare efficacemente la
virtualizzazione. In pratica esso prevede che le istruzioni non privilegiate, che
sono la frazione più consistente di un instruction set, quelle da cui non può
derivare l’eventuale blocco del sistema, siano eseguite direttamente in
hardware senza coinvolgere in alcun modo il VMM. Quest’ultimo interviene
invece solo nell’esecuzione delle istruzioni privilegiate, minimizzando così il
sovraccarico.
Infine, il requisito della semplicità nella realizzazione è essenziale per garantire
la stabilità e la sicurezza dell’intero sistema, minimizzando l’occorrenza di
malfunzionamenti che comprometterebbero l’esistenza delle macchine virtuali.
In altre parole è necessario che il VMM, nonostante la disponibilità delle
istruzioni privilegiate per le macchine virtuali, resti sempre nel pieno controllo
delle risorse hardware e che non sia mai possibile ai programmi in esecuzione
negli ambienti virtuali accedere all’hardware in modo privilegiato scavalcando
il controllo del VMM.
Vi sono diversi modi per realizzare un VMM con queste proprietà; le
differenze fondamentali tra le implementazioni più diffuse si possono
ricondurre a due fattori discriminanti:
i principi che governano il dialogo tra la macchina virtuale ed il VMM, ed il
livello dove si intende collocare il VMM rispetto all’architettura del sistema di
elaborazione.
12
Rispetto alla prima scelta, che è la più importante in termini di metodo, si
distingue tra i paradigmi di virtualizzazione completa e paravirtualizzazione.
Rispetto alla seconda scelta, si distingue tra VMM posti direttamente sopra
l’hardware dell’elaboratore (VMM di sistema) che integrano un sistema
operativo “leggero” con le funzionalità di virtualizzazione e VMM che si
istallano invece come applicazioni dentro un sistema operativo preesistente
(VMM ospitati).
Normalmente viene indicato con il termine host la piattaforma di base sulla
quale si realizzano macchine virtuali, che comprende la macchina fisica,
l’eventuale sistema operativo e il VMM; si indica invece con il termine guest
tutto ciò (applicazioni e sistema operativo) che ha a che fare con la macchina
virtuale.
Quindi le tre principali tipologie di virtualizzazione sono:
• virtualizzazione completa;
• paravirtualizzazione;
• virtualizzazione a livello di sistema operativo.
1.2 Virtualizzazione completa
Il paradigma della virtualizzazione completa prevede che l’hardware virtuale
esposto dal VMM sia funzionalmente
identico a quello della sottostante
macchina fisica.
In questo modo è possibile installare
dentro le macchine virtuali sistemi
operativi standard, senza che abbiano
subito alcuna modifica specifica per
eseguire in ambiente virtuale.
Figura 4 - Esempio schermata durante l'utilizzo di
13
VMware
Questo
approccio
semplifica
notevolmente
la
creazione
e
gestione
dell’ambiente guest, ma rende un po’ più complesso il disegno del VMM;
inoltre vedremo che per una efficace implementazione è richiesta la
collaborazione dell’architettura della CPU. Negli approfondimenti che seguono
supponiamo, per semplicità, che il VMM sia installato direttamente
sull’hardware del calcolatore.
Un’architettura CPU in generale opera secondo livelli (ring) di protezione: per
semplicità consideriamo due soli livelli, supervisore ed utente, anche se molte
architetture implementano livelli intermedi usati ad esempio per l'I/O.
Il livello supervisore è riservato al software che deve accedere alle risorse del
sistema con il massimo privilegio (sistema operativo, driver), e in tale stato si
possono eseguire tutte le istruzioni proprie dell’architettura, tra cui anche le
istruzioni privilegiate che danno pieno accesso alle risorse hardware e ai
registri del sistema. Il livello utente è riservato al software meno privilegiato
(applicazioni), e in tale stato non è possibile accedere alle istruzioni privilegiate
della CPU. Se dallo stato utente si invocano istruzioni privilegiate si attiva il
meccanismo di protezione della CPU che non esegue l’istruzione in questione
ma notifica allo stato supervisore, mediante una eccezione (trap), la richiesta
ricevuta e gli passa il controllo. Normalmente, alcune delle componenti di un
sistema operativo (il kernel ed i driver) si aspettano di essere eseguite nello
stato supervisore, poiché devono controllare l’hardware. In un contesto di
virtualizzazione tuttavia, è solamente il VMM ad occupare lo stato supervisore,
mentre tutti i software guest che vi girano sopra (applicazioni, ma anche
sistemi operativi) sono spinti più in alto, nel livello utente, con i privilegi di
semplici applicazioni. Vi sono dunque due ordini di problemi nella gestione di
un sistema operativo guest che non si intende modificare ai fini della
virtualizzazione: esso è chiamato ad operare in uno stato che non gli è proprio,
poichè le chiamate di accesso alle risorse gli sono inibite (problema di ring
14
deprivileging), inoltre esso è schiacciato nello stato utente insieme alle
semplici applicazioni, con il problema di doversi proteggere da queste
(problema di ring compression). Il VMM deve dunque mascherare ai sistemi
operativi guest la natura dello stato in cui sono eseguiti, facendosi carico di
intercettare ogni richiesta di accesso privilegiato all’hardware ed emulandone il
comportamento.
Si tratta infatti di richieste che non possono essere eseguite direttamente, ma
non possono nemmeno essere ignorate pena il malfunzionamento o il blocco
del sistema guest, di cui si interromperebbe il normale flusso operazionale. Per
intercettare tali chiamate il VMM è aiutato in modo determinante dalle
funzionalità di protezione dell’architettura CPU: quando l’ambiente guest tenta
di eseguire un’istruzione privilegiata, la CPU notifica un’eccezione al VMM
(posto nello stato supervisore) e gli trasferisce il controllo.
Il VMM verifica la correttezza dell’operazione richiesta e provvede ad
emularne il comportamento atteso. Se per esempio, un guest tenta di eseguire
l’istruzione privilegiata che disabilita gli interrupt, il VMM riceve la notifica di
tale richiesta e ne emula il comportamento atteso, cioè sospende la consegna
degli interrupt solamente a quella macchina virtuale. Così facendo, la macchina
virtuale prosegue secondo il normale flusso operazionale che seguirebbe in un
ambiente reale ed il sistema rimane complessivamente stabile; se invece la
richiesta della macchina virtuale fosse eseguita sul processore, sarebbero
disabilitati tutti gli interrupt per tutti i sistemi e questo impedirebbe al VMM di
riguadagnare il controllo della CPU. Il meccanismo di notifica della CPU aiuta
a mantenere piuttosto semplice il disegno del VMM, che in modo trasparente è
chiamato ad intervenire solamente per mediare l’accesso alle risorse hardware,
di cui per altro mantiene sempre il controllo. La soluzione è anche efficiente in
quanto consente che tutte le istruzioni non privilegiate siano eseguite
15
direttamente dall’hardware, senza alcuna supervisione da parte del VMM che
non sarebbe di alcuna utilità ed introdurrebbe solo latenza.
Un’architettura CPU si dice “naturalmente virtualizzabile” se supporta l’invio
di notifica allo stato supervisore per ogni istruzione privilegiata eseguita dallo
stato utente. Un’architettura di questo tipo favorisce un disegno semplice del
VMM e supporta nativamente la tecnica dell’esecuzione diretta, fondamentale
per garantire prestazioni.
È necessario osservare tuttavia che non tutte le architetture sono naturalmente
virtualizzabili.
Alcune istruzioni privilegiate di questa architettura se eseguite nello spazio
utente non provocano un’interruzione da parte del meccanismo di protezione
della CPU ma vengono semplicemente ignorate e non consentono quindi un
trasparente intervento del VMM.
Inoltre, vi sono istruzioni non privilegiate, dunque consentite liberamente
anche nello spazio utente, che permettono di accedere in lettura ad alcuni
registri di sistema le cui informazioni andrebbero però mascherate ad una
macchina virtuale e la cui gestione dovrebbe essere riservata solo al VMM
(problema di ring aliasing). Vi è per esempio un registro (code segment
register) che segnala il livello di privilegio corrente e la cui lettura da parte di
un sistema operativo guest, che come tale è eseguito nello spazio utente, che
non gli sarebbe proprio, segnalerebbe al medesimo un’anomalia di
collocazione.
Questa assenza di supporto da parte dell’hardware impone al VMM di
implementare stratagemmi di varia natura per garantire il funzionamento della
virtualizzazione completa; i problemi possono essere risolti, ma al prezzo di un
aumento di complessità ed una riduzione delle prestazioni. Una soluzione
tipica prevede che il VMM scansioni il codice prima di passarlo in esecuzione
16
per impedire che blocchi contenenti queste istruzioni siano eseguiti
direttamente.
VMware, per esempio, implementa la tecnica della fast binary translation per
sostituire i blocchi contenenti simili istruzioni problematiche in blocchi
Figura 5 - Schema logico di un ambiente virtualizzato tramite VMware
equivalenti dal punto di vista funzionale e contenenti istruzioni per la notifica
di eccezioni che favoriscono l’intervento del VMM; tali blocchi equivalenti
sono passati poi in esecuzione diretta ed inoltre sono conservati in una cache
apposita per riusi futuri, risparmiando il costo di ulteriori traslazioni. Questo
processo di traslazione va applicato almeno all’intero kernel del guest OS, per
essere certi che tutte le istruzioni privilegiate che non notificano eccezioni
vengano intercettate e gestite.
Ciò che sinora è stato visto quindi è l'approccio “emulazione” alla
virtualizzazione: un software che simula in toto un computer fisico, su cui è
possibile installare un intero sistema operativo (e di conseguenza i software
desiderati funzionanti con quel sistema operativo).
L'approccio classico alla virtualizzazione consente (sempre con VMWare, per
esempio) di installare ed avviare su un unico computer fisico più macchine
virtuali (dotate ognuna di un proprio sistema operativo e dei propri software).
17
Questo approccio alla virtualizzazione è molto potente, ha forse un unico limite:
un software di virtualizzazione che utilizzi l'approccio dell'emulazione è
piuttosto esoso in termini di risorse hardware, per cui è possibile andare
incontro a problemi di sovraccarico e di scarsa densità.
Utilizzando l'approccio di emulazione si può in taluni casi non essere del tutto
soddisfatti delle prestazioni della macchina virtuale, a causa dell'elevata
richiesta di risorse di cui ha bisogno.
Volendo pensare in modo semplificato: su un unico computer fisico si ha
installato un sistema operativo e, sopra a questo, un programma che consente di
installare (condividendo le risorse hardware, e dunque memoria, CPU, accesso
ai dischi, ecc...) un altro sistema operativo. In pratica: su uno stesso PC girano
contestualmente due sistemi operativi che, chiaramente condividono e si
contendono le risorse.
Per ottimizzato che sia il software di virtualizzazione, con l'approccio
“emulazione” un certo sovraccarico si crea e le prestazioni ne possono risentire
(soprattutto in determinati contesti). Pensate quanto sia caricato un PC (o
server) fisico che contestualmente fa girare più macchine virtuali.
Ne
consegue
che
anche
la
densità
(numero
di
macchine
virtuali
contemporaneamente attive e funzionanti su una macchina fisica che utilizzi
un'infrastruttura di virtualizzazione) non potrà raggiungere valori soddisfacenti
in determinati contesti.
1.3 Paravirtualizzazione
Il paradigma della paravirtualizzazione prevede che l’hardware virtuale esposto
dal VMM sia funzionalmente simile, ma non identico, a quello della sottostante
macchina fisica. Piuttosto che emulare le periferiche hardware esistenti, il
VMM espone una semplice astrazione delle periferiche.
18
Nella paravirtualizzazione viene introdotto un layer (uno strato) software
leggero fra l'hardware e il sistema operativo delle macchine virtuali: tale layer
denominato “hypervisor”.
In particolare, l’interfaccia hardware virtuale che il VMM espone ai sistemi
guest è ridisegnata nella forma di una Applications Programming Interface
(Virtual Hardware API), che i sistemi guest devono sapere richiamare per
guadagnare l’accesso alle risorse.
Figura 6 - Schema logico di un ambiente virtualizzato tramite l'utilizzo delle API
Si richiede dunque che i sistemi operativi guest non siano più tenuti all’oscuro,
ma siano consapevoli di operare in un ambiente virtuale. Evidentemente questo
impone di modificarne il kernel ed i driver per renderli compatibili con le
proprietà del VMM utilizzato; ma, ed è la cosa più importante, non occorre
assolutamente modificare le applicazioni che girano sui sistemi operativi guest,
perchè l’interfaccia tra le applicazioni ed il sistema operativo non viene toccata
in alcun modo da questo approccio. Va dunque realizzato un porting dei
sistemi operativi esistenti, poiché gli attuali non sono scritti per dialogare con
una API di paravirtualizzazione ma solamente per gestire le interfacce
hardware standard. Questo è certamente un problema, soprattutto per vecchi
sistemi operativi di tipo legacy. Di riflesso però risulta enormemente
semplificata la struttura del VMM, poiché esso non deve più preoccuparsi di
19
individuare e catturare le operazioni privilegiate dei guest OS per poi emularle,
ma si avvale invece della loro diretta e consapevole collaborazione.
Viene così meno il vincolo di operare con architetture CPU naturalmente
virtualizzabili,
non
più
essenziale
per
il
funzionamento
della
paravirtualizzazione.
Il vantaggio maggiore di questo tipo di tecnica, rispetto alla precedente,
consiste proprio nella maggiore semplicità ed efficienza di esecuzione del
VMM. Inoltre, vi sono contesti in cui la cooperazione tra il VMM ed il sistema
guest è necessaria per raggiungere un risultato efficace: per esempio
nell’ambito della gestione della memoria, si osserva che il VMM, come i
tradizionali sistemi operativi, può fare uso della paginazione per spostare
pagine di memoria dalla memoria primaria al disco, con il consueto vantaggio
di potere allocare più memoria di quella strettamente disponibile.
Ciò è particolarmente importante nel contesto della virtualizzazione, con molti
sistemi e processi che insistono sulle stesse risorse sovra-allocate. Occorre
dunque un meccanismo efficiente che consenta al VMM di reclamare ed
ottenere in caso di necessità dalle diverse macchine virtuali le porzioni di
memoria meno utilizzate. È chiaro che il sistema operativo di ogni macchina
virtuale possiede informazioni relative a quali siano le pagine di memoria più
adatte ad essere spostate su disco, decisamente migliori di quelle del VMM.
Per esempio, un guest OS può notare che una pagina di memoria appartiene
ad un processo terminato e dunque tale pagina non sarà più acceduta.
Il VMM, operando al di fuori dei singoli guest OS, non può rendersi conto di
questo e dunque non sarebbe altrettanto efficiente nel decidere quali pagine di
memoria trasferire su disco per quella macchina.
20
Una strategia comunemente adoperata per risolvere questo problema è di tipo
“paravirtualizzante”:
su ogni macchina virtuale è in esecuzione un processo, a volte detto balloon
process (processo aerostato) che comunica con il VMM. Quando vi è necessità
di rastrellare memoria, il VMM chiede al balloon process di allocare più
memoria, cioè di “gonfiarsi”. Il guest OS, che meglio di tutti conosce l’utilizzo
della memoria nell’ambito della macchina virtuale, seleziona le pagine da
offrire al balloon process per soddisfarne la richiesta;
il balloon process comunica tali pagine al VMM che ne rientra in possesso. La
richiesta del balloon process provoca da parte del guest OS il trasferimento su
disco delle pagine probabilmente meno utilizzate dalla macchina virtuale, con
l’effetto netto di avere liberato memoria a favore del VMM, che provvede alla
riallocazione. Anche VMM che per il resto operano secondo il paradigma della
virtualizzazione completa, come lo stesso VMware, fanno largo uso di questi
meccanismi tipici della paravirtualizzazione, in specifico nella gestione della
memoria che , effettuata completamente dal di fuori, sarebbe altrimenti molto
complessa e poco efficiente. In particolare, VMware offre l’opzione di
installare dentro i sistemi guest un pacchetto di programmi (VMware Tools) in
cui sono presenti questa e altre “sonde” per migliorare lo scambio di dati tra
VMM e guest.
Nonostante la difficoltà di dovere realizzare il porting dei sistemi operativi
esistenti, la paravirtualizzazione sta catalizzando un’attenzione sempre
crescente. Il progetto attualmente più promettente di un VMM che opera
secondo tale paradigma è XEN, un VMM open source sviluppato
dall’Università di Cambridge. Nell’ambito del progetto è stato realizzato il
porting di Linux su XEN (XenoLinux), con un costo in termini di righe di
codice del Kernel modificato per dialogare con la API del Virtual Hardware
pari a circa 3000 righe, cioè circa 1,36% del totale.
21
Attualmente lo sviluppo di XEN è alla versione 3; tra le funzionalità più
rilevanti vi è il supporto per sistemi multiprocessore e per i più recenti kernel di
Linux. Sono supportati inoltre meccanismi di “live migration” di VM da un
host con XEN ad un altro: ciò permette di eseguire manutenzioni su di un
singolo calcolatore senza interrompere i servizi, oppure bilanciare il carico
complessivo tra i vari host con XEN di cui si dispone.
Inoltre le principali distribuzioni di Linux commerciali (Suse e RedHat)
offrono già i pacchetti precompilati per installare XEN, nonchè le immagini
della propria distribuzione modificate per la paravirtualizzazione.
Lo scotto da pagare, in sintesi, è che le macchine virtuali devono avere un
sistema operativo modificato, opportunamente adattato all'utilizzo in ambiente
di paravirtualizzazione ma, a parte questo, i sistemi di paravirtualizzazione
centrano l'obiettivo di aumentare le prestazioni (in termini di velocità) delle
macchine virtuali e parzialmente di abbassare la richiesta di risorse hardware da
parte delle macchine virtuali stesse: la richiesta di RAM è comunque
considerevole, e la più pesante conseguenza che ne deriva è una densità media
di macchine virtuali presenti e funzionanti sulla medesima macchina fisica.
1.4 VMM di sistema e VMM ospitati
Soffermiamoci su un’ultima distinzione rilevante che caratterizza i sistemi di
virtualizzazione:
il livello dove si intende collocare il VMM rispetto all’architettura del sistema
di elaborazione.
Abbiamo già accennato che si distingue in questo caso tra VMM posti
direttamente sopra l’hardware dell’elaboratore (VMM di sistema) e VMM che
si istallano invece come applicazioni dentro un sistema operativo preesistente
(VMM ospitati).
22
Figura 7 - Schema puramente indicativo di un VMM ospitato su di un sistema operativo
Nella prima opzione si integrano ad un sistema operativo “leggero” le
funzionalità di virtualizzazione, in un unico sistema che esegue direttamente
sopra l’hardware dell’elaboratore.
Un’implementazione così a basso livello offre migliori prestazioni, anche se
si rende necessario corredare il VMM di tutti i driver necessari per pilotare le
periferiche. In generale i prodotti implementati secondo questo modello
supportano un numero molto limitato di hardware certificato, rendendo meno
impegnativa la gestione delle periferiche altrimenti molto difficile vista
l’enorme varietà degli hardware nel mercato consumer.
La seconda opzione prevede invece l’installazione del VMM come
un’applicazione sopra un sistema operativo preesistente e non direttamente
sull’hardware del calcolatore. Con un certo livello di approssimazione per non
entrare troppo nei dettagli, si può dire che il VMM, anziché collocarsi sotto
tutti gli altri livelli software, opera nello spazio utente e accede all’hardware
attraverso le system call messe a disposizione dal sistema operativo su cui si
installa.
Le performance sono certamente inferiori, ma ci sono alcuni vantaggi
importanti: il VMM è più semplice da installare poiché è come
un’applicazione; inoltre potrà fare affidamento sul sistema operativo
sottostante, più fornito di driver per l’hardware più diffuso, per la gestione
23
delle periferiche; infine, potrà servirsi di vari altri servizi dell’host OS come lo
scheduling e la gestione delle risorse. È dunque una soluzione comoda che
sacrifica le performance. Spesso tale opzione è più che sufficiente per un utente
che abbia solo l’esigenza di avere contemporaneamente attivi sul proprio PC
diversi sistemi operativi per sviluppare o testare applicazioni.
1.5 Virtualizzazione a livello di sistema operativo
Un'altra tecnica di virtualizzazione consiste nell'utilizzare un sistema operativo
appositamente modificato, in funzione sulla macchine fisica, che abbia come
scopo quello di gestire (nella maniera più efficiente possibile) delle macchine
virtuali, intese come esecuzione di ambienti ( container ), che utilizzano tutti il
medesimo kernel (di un determinato sistema operativo).
Figura 8 - Schema logico di un ambiente virtualizzato tramite l'utilizzo dei containers
Con questa tecnologia si ottengono le migliori prestazioni in termini di
prestazioni delle macchine virtuali, di densità, di allocazione dinamica delle
risorse assegnate alle macchine virtuali stesse. D'altro canto (forse lo si è già
capito) lo scotto da pagare consiste nel non poter utilizzare macchine virtuali
(sulla stessa macchina fisica) che utilizzino kernel differenti (e quindi sistemi
operativi differenti) sulla stessa macchina fisica.
Per fare un esempio: non è possibile con la virtualizzazione a livello di sistema
24
operativo avere sulla stessa macchina fisica due macchine virtuali di cui una è
una macchina Linux e l'altra Windows. E' possibile avere più macchine virtuali
Linux basate su distribuzioni differenti di Linux, ovviamente a patto di
utilizzare per tutte il medesimo kernel (che è quello presente sulla macchina
fisica).
In pratica, invece di cercare di eseguire un intero sistema operativo guest, la
virtualizzazione tramite container isola degli ospiti, ma non cerca di
virtualizzare l'hardware; avremo dei contenitori (da qui il nome) per ogni
ambiente virtuale.
Con la virtualizzazione basata su container, l'installazione di un sistema
operativo guest non è così semplice come con i sistemi hypervisor: al momento
dell’istallazione dovrà essere creato un modello di contenitore.
Siccome un solo sistema operativo viene usato per eseguire tutti gli ambienti
virtuali, la virtualizzazione con l’utilizzo di container offre un livello di densità
molto più elevato. I container possono perfettamente ospitare il doppio o il
triplo di ambienti virtuali in più rispetto all'hypervisor. Ciò avviene perché una
grande parte del sovraccarico della macchina è rappresenta dal sistema
operativo che esegue. Questo è fantastico per eseguire una soluzione ad alta
densità in cui tutti gli ambienti virtuali sulla stessa macchina possono usare solo
un sistema operativo.
Inoltre, siccome c'è un solo sistema operativo da mantenere, un aggiornamento
coinvolge tutti gli ambienti virtuali presenti contemporaneamente su quella
macchina.
Dove 30 macchine virtuali richiederebbero 20 elaborazioni di gestione separate
su 3 o 4 server, gli stessi 30 ambienti virtuali richiederebbero solo
un'elaborazione di gestione. Questo fatto suppone un grande risparmio.
25
Un prodotto che utilizza questa tipologia di virtualizzazione è, ad esempio,
OpenVZ.
1.5.1 Il concetto di Container
Questa sezione vuole fornire una panoramica sul concetto di Container,
descrivere le tecniche utilizzate per ottenere l'isolamento.
Un contenitore fornisce l'immagine composta di un file system radice, un
(sicuro e condiviso) insieme di librerie di sistema ed eseguibili.
Ogni VM può essere avviato, spento e riavviato proprio come un normale
sistema operativo. Risorse come lo spazio su disco, le garanzie di CPU,
memoria, ecc, sono assegnate a ciascuna macchina virtuale al momento della
creazione, ma spesso possono essere variate dinamicamente in fase di
esecuzione. Per le applicazioni e l'utente di un sistema basato sui contenitori, il
VM appare proprio come un host separato.
La figura sottostante illustra schematicamente la progettazione.
Figura 9 - Progettazione VM tramite containers
Come mostrato nella figura, vi sono tre piattaforme di base. La piattaforma di
hosting consiste essenzialmente nella comune immagine del SO e un VM ospite
26
privilegiato. Questa è la VM che un amministratore di sistema utilizza per
gestire altre macchine virtuali. La piattaforma virtuale è la vista del sistema dal
punto di vista dei VM guest. A questo livello, c'è poca differenza tra un
contenitore e sistema basato su hypervisor. Tuttavia, si differenziano
fondamentalmente
le
tecniche
che
usano
per
implementare
l’isolamento tra VM e nel modo in cui mappare le macchine virtuali ai
controller delle risorse
Per i container l’approccio all’ isolamento coinvolge direttamente oggetti interni
del sistema operativo (PID, UID, IPC, e così via). Le tecniche di base per
utilizzare in modo sicuro questi oggetti riguardano:
• separazione degli spazi dei nomi (contesti), ovvero gli identificatori
globali (ad esempio gli ID di processo, IPC , ID utente, ecc) vivono in
spazi completamente diversi. Attraverso questa contestualizzazione gli
identificatori globali diventano identificatori globali per VM;
• controllo degli accessi (filtri), verifica se la macchina virtuale disponga
delle autorizzazioni appropriate per eccedere ad un determinato oggetto.
27
Capitolo 2
OpenVZ (Open VirtualiZation) è una tecnologia di virtualizzazione a livello di
Sistema Operativo basata su kernel Linux. OpenVZ alloca un server fisico su
cui ‘girano’ multiple istanze di sistemi operativi isolati, noti come containers,
Virtual Private Servers (VPS), o Virtual Environments (VE). Ogni container
si comporta esattamente come un server stand-alone; un container può essere
riavviato in modo indipendente dagli altri e avrà propri:
• utenti,
• indirizzi IP,
• memoria,
• processi,
• file,
• applicazioni,
• librerie di sistema,
• file di configurazione.
OpenVZ è basato su i Containers Virtuozzo, un software proprietario prodotto e
messo a disposizione dalla società Parallels.
OpenVZ si compone di un kernel personalizzato e da tool di livello utente.
28
2.1 Concetto di Virtual Environment
Virtual Environment (VE, conosciuto anche come VPS, container, partizione
ecc.) è un ambiente di esecuzione dei programmi isolato, che (dal punto di vista
dell’utente) appare come un server fisico separato.
Un VE ha un proprio set di processi di start, file system, utenti (incluso il root),
interfacce network con indirizzi IP, tabelle di routing, ecc.
Più VE possono co-esistere all’interno di un singolo server fisico. Differenti VE
possono ‘girare’ differenti distribuzioni di Linux, ma ciascuno VE opera sotto lo
stesso kernel.
2.2 Kernel di OpenVZ
In genere il kernel è il ‘cuore’ di un sistema operativo (nucleo) e fornisce tutte
le funzioni essenziali per il sistema, in particolare la gestione della memoria,
delle risorse del sistema e delle periferiche, assegnandole di volta in volta ai
processi in esecuzione.
Il kernel di OpenVZ è un kernel modificato di Linux che aggiunge le seguenti
funzionalità: virtualizzazione e isolamento dei diversi sottosistemi, gestore
delle risorse, e checkpointing.
• La virtualizzazione e isolamento abilita il funzionamento dei diversi
ambienti virtuali all’interno del singolo kernel;
• Il gestore delle risorse dei sottosistemi
limita (e in alcuni casi
garantisce) l’utilizzo delle risorse come ad esempio CPU, RAM, e spazio
sul disco ad ogni VE.
• Il checkpointing è un processo che ‘congela’ un VE, salvando
completamente il suo stato su un file disk, con la possibilità poi di
‘scongelare’ questo stato in futuro.
Le varie componenti sono descritte qui di seguito.
29
2.2.1 Virtualizzazione e isolamento
Ogni VE ha un suo insieme di risorse messe a disposizione dal kernel del
sistema operativo. All’interno del kernel, queste risorse vengono virtualizzate o
isolate.
Ogni VE ha poi un insieme di oggetti qui elencati:
• File – librerie di sistema, applicazioni, sistemi e procedure virtualizzate,
blocchi virtualizzati, ecc.
• Utenti e gruppi – ciascuna VE ha il proprio root utente, come per altri
utenti e gruppi.
• Albero dei processi – Un VE vede solo i proprio processi, che vengono
startati nell’init. I PID sono virtualizzati, così che il PID dell’init sarà
sempre 1 come deve essere.
• Network – Dispositivo di rete virtuale, che permette al VE di avere i
propri indirizzi IP, così come una serie di tabelle IP e le regole di routing.
• Dispositivi – Alcuni dispositivi sono virtualizzati. In aggiunta, nel caso in
cui fosse necessario, ad alcuni VE è consentito (in esclusivo) l’accesso ai
dispositivi reali come le interfacce network, porte seriali, partizione del
disco, ecc.
• Oggetti IPC– memoria condivisa, semafori, e messaggi.
30
2.2.2 Gestore delle risorse
Il gestore delle risorse ha un’importanza fondamentale per la virtualizzazione a
livello di sistema operativo, questo perchè c’è un insieme finito di risorse
all’interno del singolo kernel che devono essere condivise tra i diversi Virtual
Environments. Tutte queste risorse devono essere controllate in modo che i
molti ambienti virtuali coesistano su un singolo sistema, e non si influenzino a
vicenda.
Il gestore delle risorse di OpenVZ è costituito di tre componenti:
• Due livelli di quota del disco – L’amministratore del server OpenVZ
può settare le quote del disco per ciascun VE in termini di spazio sul
disco. Questo è il primo livello di quota.
Il secondo livello di quota del disco consente all'amministratore di VE
(VE root) di usare gli strumenti di quota standard di UNIX per settare lo
spazio sul disco per gli utenti e per i gruppi.
• “Equo” scheduler della CPU – Lo scheduler della CPU di OpenVZ ha
anch’esso due livelli.
Al primo livello si decide a chi tra i VE dare la slice di tempo, tenendo
conto delle priorità della CPU dei VE e le impostazioni dei limiti.
Al secondo livello, lo scheduler standard di Linux decide a quale
processo nel VE andrà la slice di tempo, usando il processo standard
delle priorità.
• Utente Beancounters – Si tratta di una serie di contatori, limiti e
garanzie (per ciascun VE). Vi è una serie di circa 20 parametri che
vengono scelti accuratamente per coprire tutti gli aspetti del
31
funzionamento dei VE, in modo tale che nessun singolo può abusare di
una qualsiasi risorsa che è limitata per l'intero computer, e quindi
danneggiare gli altri ambienti virtuali. Le risorse che vengono controllate
sono principalmente la memoria e vari oggetti nel kernel, tra i quali i
segmenti di memoria condivisi, buffer di rete, ecc
2.2.3 Checkpointing e migrazione live
Il checkpointing consente la migrazione “live” di un VE ad un altro server
fisico. Il VE è “congelato” e il suo stato è completamente salvato su di un file
disk. Questo file può essere trasferito su di un’atra macchina e il VE può essere
“scongelato” li. L'intero processo richiede pochi secondi, e dal punto di vista
del client non sembra un tempo di inattività, ma piuttosto un ritardo nella
elaborazione, dato che le connessioni di rete stabilite sono migrate.
32
Capitolo 3
Funzionalità di OpenVZ
Le funzionalità di base OpenVZ VPS sono:
• Partizionamento Dynamic Real-time - partizionare un server fisico in
decine di VPS, ciascuno con tutte le funzionalità di un server dedicato.
• Resource Management - Assegnazione e controllo dei parametri delle
risorse ai VPS e ri-allocazione delle risorse stesse in tempo reale.
• Gestione di massa - Consente di gestire una moltitudine di server fisici
e server privati virtuali in modo unificato.
OpenVZ fornisce una soluzione completa per l'hosting service provider
consentendo loro di avere centinaia di clienti con i loro singoli server virtuali
con funzionalità complete private (Virtual Private Server) che condividono un
singolo server fisico. Se si amministra un certo numero di server dedicati Linux
all'interno di un'azienda, ognuno dei quali gestisce un determinato servizio, è
possibile utilizzare OpenVZ per consolidare tutti questi server su un singolo
computer senza perdere informazioni preziose e senza compromettere le
prestazioni.
33
Come già ribadito in precedenza i Virtual Private Server si comportano proprio
come server stand-alone isolati, ovvero:
• Ogni VPS ha i suoi propri processi, utenti, file e fornisce pieno accesso
alla shell di root;
• Ogni VPS ha i suoi indirizzi IP, i numeri di porta, il filtraggio e regole di
routing;
• Ogni VPS può avere una propria configurazione del sistema e software
applicativo, così come le sue versioni di librerie di sistema. E 'possibile
installare software e personalizzare i pacchetti all'interno di un VPS in
modo indipendente da altri VPS o il sistema host.
Distribuzioni multiple di un pacchetto possono essere eseguite su una sola e
stessa macchina Linux.
In realtà, centinaia di server possono essere raggruppati in questo modo. Oltre
agli
evidenti
vantaggi
di
tale
consolidamento
(maggior
facilità
di
somministrazione e simili), ci sono altri vantaggi a cui forse non si è pensato,
per esempio, al taglio delle bollette di elettricità!
3.1 Caratteristiche distintive di OpenVZ
Il concetto di VPS fornito da OpenVZ è distinto dal concetto tradizionale di
macchina virtuale, questo perché i Virtual Private Server devono eseguire tutti
lo
stesso kernel di un medesino SO come sistema host (Linux su Linux,
Windows su Windows, ecc.).
Supponendo di utilizzare Linux 2.6, ogni contenitore è scalabile come il kernel
Linux 2.6, con i benefici che ne comporta, esempio: supporta fino a 64
processori e fino a 64 GB di RAM. Un unico contenitore può scalare fino a
34
raggiungere tutte le possibilità fisiche, vale a dire utilizzare tutte le CPU e tutto
lo spazio RAM.
Questa tecnologia di implementazione single-kernel consente di eseguire
Virtual Private Server, con un overhead (tempo medio di CPU necessario per
eseguire i moduli del kernel) limitato, e può essere trascurato in molti scenari.
Così, i VPS di OpenVZ offrono un ordine di grandezza maggiore in termini di
efficienza e gestibilità rispetto alle tecnologie di virtualizzazione tradizionali.
Per quanto riguarda le densità, OpenVZ è in grado di ospitare centinaia di
contenitori su un buon hardware (le principali limitazioni sono RAM e CPU).
Figura 10 - Grafico che mostra il tempo di risposta di un contenitore
Il grafico mostra la relazione del tempo di risposta del contenitore con un server
web Apache col variare del numero di contenitori. Le misurazioni sono state
effettuate su un macchina con 768 MB di RAM; ogni contenitore fa eseguire
l’insieme di processi: init, syslogd, crond, sshd e Apache ed è stato registrato il
primo tempo di risposta. Come il crescere del numero di contenitori, il tempo di
risposta diventa più elevato a causa della carenza di RAM e swap eccessivi. In
questo scenario è possibile eseguire fino a 120 contenitori con 768 MB di RAM.
35
Cresce in maniera lineare, per cui è possibile eseguire fino a circa 320
contenitori su server dotato di 2 GB di RAM.
Infine, per ciò che attiene alla gestione generale, un amministratore (cioè root)
di OpenVZ su un server fisico (conosciuto anche come un nodo hardware o
sistema host) può vedere tutti i processi in esecuzione e i file su tutti i
contenitori del sistema. Ciò rende possibile la gestione generale (mass
management). VMware o Xen sono utilizzati per il consolidamento del server:
per applicare un aggiornamento a 10 server virtuali è richiesto che una
amministratore acceda a ciascuna virtual machine ed esegua l’aggiornamento
mentre OpenVZ con un semplice script di shell è in grado di aggiornare tutti i
contenitori in una sola volta.
OpenVZ si rivela prezioso anche per le istituzioni educative che possono ora
fornire tutti gli studenti con un server Linux personale, che può essere gestito in
remoto. Società di sviluppo software possono utilizzare gli ambienti virtuali a
fini di prova e simili.
Così, OpenVZ può essere applicato in modo efficace in una vasta gamma di
settori: web hosting, lo sviluppo e test del software, formazione degli utenti, e
così via.
3.1.1 Applicazioni
Dal punto di vista delle applicazioni e utenti
dei Virtual Private Server,
ciascuno VPS è un sistema indipendente. Questa autonomia è assicurata da un
livello di virtualizzazione nel kernel del sistema operativo host. Si noti che solo
una parte infinitesimale delle risorse della CPU viene speso per la
virtualizzazione (circa 1-2%).
36
Le caratteristiche principali dello strato di virtualizzazione attuata da OpenVZ
sono le seguenti:
• Un VPS si presenta come un normale sistema operativo Linux. Ha
standard di script di avvio, i software dei fornitori possono essere eseguiti
all'interno VPS OpenVZ senza modifiche o specifici di adeguamento;
• Un utente può modificare qualsiasi file di configurazione e installazione
di software aggiuntivo;
• Virtual Private Server sono completamente isolati gli uni dagli altri
(file system, i processi, Inter Process Communication (IPC), le variabili
sysctl);
3.1.2 Networking
Lo strato di rete virtualizzato da OpenVZ è progettato per isolare i VPS uno
dall'altro e dalla rete fisica:
Ogni VPS ha un proprio indirizzo IP, indirizzi IP multipli per ogni VPS sono
consentiti;
La rete traffico di un VPS viene isolata dalle altre VPS: in altre parole, i Virtual
Private Server sono protetti l’uno dall'altro in modo che si renda impossibile lo
snooping del traffico;
Può essere usato Firewalling all'interno di un VPS (l'utente può creare regole
che limitano l'accesso ad alcuni servizi utilizzando lo strumento canonico
iptables all'interno delle VPS). E’ possibile quindi impostare le regole del
firewall dall'interno di una VPS;
Manipolazioni della tabella di routing sono autorizzate a beneficiare di
funzionalità avanzate di routing. Ad esempio, impostando diverse unità di
trasmissione massima (MTU) per diverse destinazioni, specificare gli indirizzi
di origini diverse per diverse destinazioni, e così via.
37
3.1.3 Template
Un modello operativo in OpenVZ è fondamentalmente un insieme di pacchetti
da una qualche distribuzione Linux utilizzata per compilare uno o più VPS. Con
OpenVZ, distribuzioni differenti possono coesistere sullo stesso hardware,
quindi più modelli di sistema operativo sono disponibili.
Un modello operativo è costituito da programmi di sistema, librerie e gli script
necessari per avviare e gestire il sistema (VPS), così come alcune applicazioni
di base e di utilità. Applicazioni come un compilatore e un server SQL di solito
non sono incluse in un modello di sistema operativo.
Resource Management controlla la quantità di risorse disponibili per Virtual
Private Server. Le risorse controllate includono parametri quali la potenza della
CPU, spazio su disco, una serie di parametri relativi alla memoria.
La gestione delle risorse OpenVZ consente:
• efficace condivisione delle risorse hardware disponibili nodo tra VPS;
• Garanzia di qualità-of-Service (QoS) in conformità con un Service Level
Agreement (SLA);
• fornire prestazioni e l'isolamento delle risorse e proteggere da attacchi;
• contemporaneamente assegnare e controllare le risorse per una serie di
Virtual Private Server, ecc
38
3.2 Come funziona OpenVZ
In questa sezione si cercherà di formare una idea più o meno precisa del modo
in cui il software OpenVZ funziona sul vostro computer.
Si prega di vedere la figura seguente:
Figura 11 - Architettura server con OpenVZ
Questa figura presuppone che si dispone di un numero di server fisici uniti in
una rete. In effetti, si può avere solo un server dedicato per utilizzare in modo
efficace OpenVZ per le esigenze della vostra rete. Se più di un server è basato
su OpenVZ, ciascuno dei server avrà una architettura simile. Nella terminologia
di OpenVZ, tali server sono chiamati nodi hardware (o HN, o solo Nodi),
perché
rappresentano
le
unità
hardware
all'interno
di
una
rete.
OpenVZ è installato su Fedora Core 3 o 4 o Red Hat Enterprise Linux 4
configurato in un certo modo. Tale configurazione personalizzata comprende la
creazione di una partizione /vz, che è la partizione di base per l'hosting di
Virtual Private. I problemi di configurazione e simili sono più facilmente risolti
durante l'installazione di Linux sul nodo hardware.
39
OpenVZ viene installato in modo tale che si è in grado di avviare il computer
sia con il supporto OpenVZ o senza di esso. Questo supporto è presentato come
"OpenVZ" nel boot loader e mostrato come “Layer OpenVZ” nella figura
sopra.
Tuttavia, a questo punto non si è ancora in grado di creare un Virtual Private
Server. Un VPS è funzionalmente identico a un server stand-alone isolato, ha i
suoi indirizzi IP, processi, file, gli utenti, i suoi file di configurazione, le proprie
applicazioni, librerie di sistema e così via. I Virtual Private Server condividono
lo stesso nodo hardware e lo stesso kernel del Sistema Operativo. Tuttavia, essi
sono isolati uno dall'altro. Un Virtual Private Server è una sorta di 'sandbox' per
i processi e gli utenti.
Ogni VPS può eseguire la propria versione di Linux. In questo caso si dice che
un VPS è basato su un template del SO. I template del sistema operativo sono
pacchetti spediti con OpenVZ. Prima di essere in grado di creare un Virtual
Private Server, è necessario installare il template corrispondente di SO in
OpenVZ. Questo messaggio viene visualizzato come ‘templates’ (modelli)
OpenVZ nello schema di cui sopra.
Dopo aver installato almeno un modello di sistema operativo, è possibile creare
un numero qualsiasi di VPS con l'aiuto di utility standard di OpenVZ,
configurare la propria rete e / o altre impostazioni, e lavorare con questi VPS
come con un server Linux completamente funzionale.
3.2.1 I modelli
Un modello è un blocco utile per la costruzione di un VPS. Un modello
operativo è un insieme di pacchetti necessari per far funzionare un VPS. I
modelli sono generalmente creati direttamente sul tuo nodo hardware, è
40
sufficiente disporre di strumenti di modello (vzpkg) e metadati di template.
I metadati di template sono informazioni su un modello specifico di sistema
operativo. Esso contiene:
• un elenco di pacchetti inclusi in questo modello (in forma di nomi di
pacchetti);
• di posizione (di rete) repository di pacchetti;
• distribuzione di specifici script eseguiti su varie fasi di installazione del
template;
• chiave pubblica GPG necessaria per controllare le firme dei pacchetti;
Tutte queste informazioni sono contenute in alcuni file installati nella cartella
/vz /template/osname/osrelease/config /directory. Ad esempio, i metadati per
il modello di Fedora Core 4 sono installati nella directory /vz/template/fedoracore/4/config/.
Insieme con i metadati , alcuni pacchetti specifici di OpenVZ sono di solito
installati in /vz/template/osname/OSVersion/vz-addons/directory.
I metadati forniscono informazioni sufficienti per creare un modello operativo.
Durante la creazione del modello operativo, i file del pacchetto necessari
vengono scaricati dal repository al nodo hardware e installato in un VPS
temporaneo, che viene poi compresso con gzip e salvato nella cache del
template.
La cache di modello viene utilizzata per creare velocemente i VPS. In sostanza,
tutto quello che serve per creare un VPS è scompattare il file. I file di modello
di cache sono memorizzati nella cartella /vz/template/cache/directory.
Qualsiasi file di cache diventa obsoleto con il tempo a causa dei nuovi
41
aggiornamenti che vengono rilasciati per la distribuzione data. Naturalmente, c'è
un modo per aggiornare rapidamente la cache dei template così come tutte le
VPS creati in precedenza con gli ultimi aggiornamenti.
Oltre a essere in grado di eseguire tutti i tipi di attività all'interno di un Virtual
Private Server inclusi i pacchetti rpm di costruzione e la loro installazione,
OpenVZ fornisce un modo semplice e molto più efficace di installare le
applicazioni necessarie sul VPS. Nello stesso modo con cui si installa un
modello operativo sul sistema OpenVZ in modo da creare un numero qualsiasi
di Virtual Private Server e condividere le fra loro le risorse, è possibile installare
le applicazioni in OpenVZ al fine di condividere i file dei pacchetti tra un
qualsiasi numero di VPS. È quindi possibile aggiungere queste applicazioni a
qualsiasi numero di Virtual Private Server.
E 'ovvio che nel caso si desideri installare un'applicazione su un solo VPS, non
c'è bisogno di lavorare con i modelli: si può anche lavorare all'interno delle VPS
corrispondenti.
3.2.2 Le licenze
Il software OpenVZ è costituito dal kernel OpenVZ e strumenti a livello utente,
che sono concessi per mezzo di due diverse licenze open source.
• Il kernel OpenVZ è basato sul kernel Linux, distribuito sotto i termini
della GPL, ed è sotto licenza GNU GPL versione 2. Il testo della licenza
è disponibile all'indirizzo http://openvz.org/documentation/licenses/gnugpl.
•
Gli strumenti a livello utente (vzctl, vzquota e vzpkg) sono rilasciati
sotto i termini della licenza QPL. Il testo della licenza è disponibile
all'indirizzo http://openvz.org/documentation/licenses/qpl.
42
vzctl e un programma di utilità per il controllo dei contenitori (creare,
distruggere,
avviare,
arrestare,
impostare
i
parametri
ecc).
vzquota è un programma di utilità per gestire le quote per i contenitori.
Molto usato mediante l’utilizzo di vzctl.
OpenVZ consente di configurare in modo flessibile le diverse impostazioni per
il sistema OpenVZ, in generale, così come per ogni Virtual Private Server. Tra
queste impostazioni ricordiamo quelle per il disco e le quota utente, i parametri
di rete, percorsi di file predefiniti ei file di configurazione, e altri.
OpenVZ memorizza le informazioni di configurazione in due tipi di file: il file
di configurazione globale /etc/sysconfig/vz e file di configurazione VPS
/etc/sysconfig/VZ-scripts/vpsid.conf.
Il file di configurazione globale, definisce i parametri globali e di default per il
funzionamento VPS, ad esempio, le impostazioni di registrazione, attivazione e
disattivazione delle quote disco per VPS, il file di configurazione di default e il
modello di SO sulla base dei quali viene creato un nuovo VPS, e così via.
D'altra parte, un file di configurazione VPS definisce i parametri per un dato
VPS, come quota del disco e limiti delle risorse assegnate, l'indirizzo IP e nome
host, e così via. In caso in cui parametro sia configurato sia nel file di
configurazione globale che in quello VPS, il file di configurazione VPS ha la
precedenza.
43
I file di configurazione vengono letti quando OpenVZ e/o VPS vengono avviati.
Tuttavia, le utility standard, per esempio, vzctl, permettono di modificare
numerose impostazioni di configurazione "on-the-fly", senza modificare i file
di configurazione corrispondenti o con la loro modifica (se si desidera che le
modifiche da applicare siano valide anche ai successivi avvii di OpenVZ /o
VPS).
Figura 12 - Control Panel di OpenVZ
44
3.2.3 Considerazioni sull’Hardware
La disponibilità di hardware in questo caso è ancora più importante rispetto ad
un normale server. Dal momento che ‘girano’ più server virtuali che forniscono
una serie di servizi critici, un'interruzione hardware potrebbe essere molto
costosa.
Al fine di aumentare la disponibilità hardware, ci sono dei suggerimenti da
seguire:
• Utilizzare l'archiviazione RAID per i VPS che eseguono attività critiche.
Anche il RAID 1 (mirroring)
potrebbe essere utilizzato come una
possibile soluzione.
Un RAID, acronimo di Redundant Array of Independent Disks, in
italiano insieme ridondante di dischi indipendenti, è un sistema
informatico che usa un gruppo di dischi rigidi per condividere o replicare
le informazioni. I benefici del RAID sono di aumentare l'integrità dei
dati, la tolleranza ai guasti e le prestazioni, rispetto all'uso di un disco
singolo.
Il sistema RAID 1 crea una copia esatta (mirror) di tutti i dati su due o
più dischi. È utile nei casi in cui la ridondanza è più importante che usare
tutti i dischi alla loro massima capacità: infatti il sistema può avere una
capacità massima pari a quella del disco più piccolo. In un sistema ideale,
formato da due dischi, l'affidabilità aumenta di un fattore due rispetto al
sistema a disco singolo, ma è possibile avere più di una copia dei dischi.
Poiché ogni disco può essere gestito autonomamente nel caso l'altro si
guasti, l'affidabilità aumenta linearmente al numero di dischi presenti.
RAID-1 aumenta anche le prestazioni in lettura, visto che molte
implementazioni possono leggere da un disco mentre l'altro è occupato.
45
• Non eseguire il software sul nodo hardware stesso. Creare speciali
Virtual Private Server in cui è possibile ospitare i servizi necessari come
BIND, FTPD, HTTPD, e così via. Sul nodo hardware in sé, è necessario
solo il demone SSH. Preferibilmente, dovrebbe accettare le connessioni
da un set predefinito di indirizzi IP unici.
BIND (Berkeley Internet Name Domain) è il server DNS più usato su
Internet, specialmente sui sistemi Unix e derivati, sui quali è lo standard
di fatto.
FTPD è il processo del server Internet File Transfer Protocol. Il server
usa il protocollo TCP e ascolta la porta specificata nelle specifiche del
servizio FTP.
L'acronimo HTTPD sta per Hyper Text Transfer Protocol Daemon
(ovvero web server).
SSH è un modo sicuro e crittato di stabilire connessioni a sistemi o server
remoti. Un server SSH accetta connessioni da client SSH e consente loro
di effettuare il login nel sistema come se fossero seduti di fronte ad esso.
Usando SSH, puoi eseguire programmi da riga di comando.
• Non creare utenti sul nodo hardware stesso. È possibile creare tutti gli
utenti di cui si hai bisogno in ogni Virtual Private Server.
Bisogna ricordare che compromettere il nodo hardware significa
compromettere tutte le Virtual Private Server pure.
46
3.3 Utilizzo concreto della tecnologia OpenVZ
Qui di seguito vengono mostrati alcuni esempi di utilizzo concreto di OpenVZ,
come ad esempio l’installazione del software e la creazione di un container.
3.3.1 Installazione di OpenVZ
Requisiti
Si presuppone si usi una distribuzione di recente rilascio come Fedora Core
(FC5 o superiore) o RHEL / CentOS 4. Attualmente, il kernel di OpenVZ cerca
di supportare lo stesso hardware compatibile con i kernel di Red Hat. Per un
completo elenco di compatibilità hardware è possibile consultare Hardware
Compatibility List di Virtuozzo.
Filesystem
Si raccomanda di utilizzare una partizione separata per la directory dei container
privati (di default /VZ/private / <veid>). Il motivo per cui si dovrebbe fare così
è perché se si desidera utilizzare la funzione per-container disk quota di
OpenVZ, non si è in grado di utilizzare le quote disco di Linux sulla stessa
partizione.
La gestione della quota dei container di OpenVZ è supportato solo su
filesystem ext2/ext3. Quindi conviene utilizzare uno di questi filesystem ( è
raccomandato ext3 in quanto garantisce una maggiore integrità dei dati e ha,
nella maggior parte dei casi, un velocità maggiore rispetto a ext2) se si vuol
adoperare il gestore delle quote incluso in OpenVZ.
Usare rpm o yum?
RPM ovverosia Red Hat Package Manager è stato uno dei primi, se non il
primo, gestore di pacchetti mai creati per Linux.
47
YUM è un programma per l'aggiornamento automatico di pacchetti rpm. Yum
controlla le dipendenze dei pacchetti e tutto il necessario per installare
correttamente programmi da varie repositories.
Nel caso in cui è disponibile l’utility yum sul sistema, è possibile utilizzarla in
modo efficace per installare e aggiornare i pacchetti di OpenVZ. Nel caso in cui
non si può usare yum, o non lo si desidera utilizzare, è possibile utilizzare i
pacchetti rpm.
Le istruzioni per rpm e yum sono fornite di seguito:
• pre-setup con yum
Se si desidera utilizzare yum, prima si dovrebbe configurare il repository
di OpenVZ.
Scaricare il file openvz.repo (http://download.openvz.org/openvz.repo) e
metterlo nel repositori locale /etc/yum.repos.d/. Questo può essere fatto
usando i seguenti comandi, come utente root:
#cd /etc/yum.repos.d
# wget http://download.openvz.org/openvz.repo
# rpm –import http://download.openvz.org/RPM-GPG-Key-OpenVZ
Nel caso in cui non è possibile riuscire ad eseguire il comando
cd/etc/yum.repos.d, significa che yum non è installato sul proprio
sistema, o la versione di yum è troppo vecchia. In tal caso, basta seguire
il metodo di installazione per rpm.
L’installazione del kernel
In primo luogo, è necessario scegliere quale “flavor” del kernel si desidera
installare.
48
• Usando yum
Eseguire il seguente comando
# yum install ovzkernel[-flavor]
Qui [-flavor] è facoltativo, e può essere -smp o -enterprise.
Questo problema è comunque risolto in versioni più recenti di yum.
• Usando i pacchetti rpm
Occorre scaricare il kernel binario RPM dalla sezione download del
kernel, si prega di sceglierne uno a seconda del proprio hardware.
Quindi, installare l’RPM del kernel che è stato scelto:
# rpm -ihv ovzkernel[-flavor]*.rpm
Qui [-flavor] è facoltativo, e può essere -smp o -enterprise.
Nota: rpm-U (U-dove l’acronimo di aggiornamento) non deve essere
usato, altrimenti tutti i kernel attualmente installato saranno disinstallati.
Configurare il bootloader
Sarà automaticamente configurato GRUB come boot loader (programma che
carica il kernel di un sistema operativo e ne permette l'avvio).
Configurazione
Assicurarsi che i seguenti passaggi vengono eseguiti prima di riavviare il kernel
OpenVZ.
• sysctl
Ci sono un certo numero di parametri del kernel che dovrebbe essere
impostati per far funzionare correttamente OpenVZ . Questi parametri
vengono memorizzati nel file /etc/sysctl.conf. Saranno cambiate delle
49
porzioni importanti del file.
Deve essere consentito l’inoltro dei
pacchetti
al
nodo
hardware
e
disabilitato il proxy arp:
#net.ipv4.ip_forward = 1
#net.ipv4.conf.default.proxy_arp = 0
Occorre abilitare la verifica del
mittente del percorso:
#net.ipv4.conf.all.rp_filter = 1
Figura 13 - Vista del file sysctl.conf
SELinux
Rappresenta un'architettura creata per aumentare la sicurezza del vostro sistema
e in questo caso deve essere disattivato. A tal fine, mettere la seguente riga nel
file /etc/sysconfig/selinux:
#SELINUX=disabled
Riavvio del kernel OpenVZ
Ora riavviare la macchina e scegliere “OpenVZ” nel menu del boot loader. Se il
kernel OpenVZ è stato avviato con successo, procedere alla installazione a
livello utente degli strumenti di OpenVZ.
Installare i tool
OpenVZ necessita dell’istallazione di alcuni strumenti a livello utente.
Questi sono:
• vzctl
Un programma di utilità per il controllo dei contenitori (creare,
distruggere, avviare, arrestare, impostare i parametri ecc)
50
• vzquota
Un programma di utilità per gestire le quote per i contenitori. Molto usato
mediante l’utilizzo di vzctl.
Usando yum
# yum install vzctl vzquota
Usando il formato rpm
Scaricare il binario RPM di questi servizi di pubblica utilità da
http://wiki.openvz.org/Download/utils. Installarli:
# rpm -Uhv vzctl*.rpm vzquota*.rpm
Quando tutti gli strumenti sono installati, avviare il sottosistema di OpenVZ.
Avviare OpenVZ
Come utente root, eseguire il seguente comando:
# /sbin/service vz start
In questo modo tutti i moduli necessari del kernel OpenVZ vengono caricati.
Questo script dovrebbe avviare anche tutti i contenitori contrassegnati per essere
auto-avviabili al boot della macchina (se ce ne sono già).
Durante
il
successivo
riavvio,
questo
script
deve
essere
eseguito
automaticamente.
Prossimi passi
OpenVZ è ora installato sulla macchina. Per caricare il kernel di OpenVZ di
default, modificare la linea in /boot/grub/grub.conf nel punto del kernel
OpenVZ. Ad esempio, se il kernel OpenVZ è il primo kernel menzionato nel
file, metterlo come default=0.
51
3.3.2 Creazione di un container
Innanzitutto
è
possibile
scaricare
dalla
pagina
http://wiki.openvz.org/Download/template/precreated il template già pronto di
Debian 5.0 (quello x86 per sistemi a 32 bit oppure x86_64 per la versione a 64
bit).
Collocare
l’archivio
scaricato,
senza
scompattarlo,
nella
cartella
/vz/template/cache del proprio computer.
Per creare un container (un vps) a partire dal modello scaricato, basta eseguire il
comando, avendo cura di mettere debian-5.0-x86_64 se si è scelto un template a
64 bit:
# /usr/sbin/vzctl create 101 –ostemplate debian-5.0-x86
Dopo qualche secondo viene creato un nuovo container, ma per poterlo usare
bisogna avviarlo:
# /usr/sbin/vzctl start 101
Per poter utilizzare una connessione di rete e quindi rendere il vps contattabile
almeno dalla LAN assegnare un indirizzo IP facente parte della rete (anche
mentre l’ambiente è in esecuzione):
# /usr/sbin/vzctl set 101 –ipadd 192.168.1.101
Per potersi collegare al vps basta
usare il comando:
# /usr/sbin/vzctl enter 101
Figura 14 - Utilizzo del comando vzctl start 101
52
Prima di tutto controllare che la rete sia effettivamente funzionante provando
con un ping ad un indirizzo della subnet.
Se il ping non mostra alcun pacchetto di risposta può essere necessario
disattivare l’interfaccia virtuale nel container creata già con un indirizzo non
adeguato alle caratteristiche della propria rete: col comando “ipconfig” vengono
mostrate l’interfaccia di loopback, l’interfaccia creata con l’IP personalizzato
(come spiegato precedentemente) e una scheda di rete con IP 10.1.1.1 che va
eliminata col comando:
vps:/# ifdown venet0:0
Ora è possibile fare un upgrade del sistema con le ultime patch di sicurezza:
vps:/# apt-get update
vps:/# apt-get upgrade
Può darsi che abbia problemi con la risoluzione dei nomi (cioè che sia in grado
di raggiungere l’esterno usando un indirizzo IP pubblico ma non sia capace di
risolvere ad esempio google.it), in questo caso vedere le regole usate per
iptables sul server fisico (disabilitarle temporaneamente).
Non c’è sinceramente molto da fare perché Apache è già installato all’interno
del container.
Se si vuole usare Apache per creare un VirtualHost si può adoperare questo
modello:
<VirtualHost *:80>
ServerAdmin [email protected]
ServerName www.adminsite.com
ServerAlias adminsite.com
53
DocumentRoot /var/www/adminsite
<Directory /var/www/adminsite>
Options FollowSymLinks -Indexes
AllowOverride All
</Directory>
ErrorLog /var/log/apache2/adminsite_error.log
CustomLog /var/log/apache2/adminsite_custom.log combined
</VirtualHost>
Se si preferisce sostituire Apache con un web server più leggero come lighttpd o
nginx si può disinstallare Apache con:
vps:/# /etc/init.d/apache2 stop
vps:/# apt-get remove apache2
54
Bibliografia
[1]
Boari, Balboni. “Tecniche di virtualizzazione. Teoria e pratica. “ Mondo
Digitale, Marzo 2007
[2]
Prof. Fabio Cantaro, “'Macchine virtuali”
[3]
Kirilli Klyshkin, “Virtualization in Linux”
[4]
Stephen Soltesz, Herbert P-otzl, Marc E. Fiuczynski,
Andy Bavier, Larry Peterson,
“Container-based Operating System Virtualization:
A Scalable, High-performance Alternative to Hypervisors”
[5]
OpenVZ.org
[6]
parallels.com
[7]
Valent Emulazione virtuale, http://www.valent-blog.eu/
[8]
HPL-2007-59 technical report
http://www.hpl.hp.com/techreports/2007/HPL-2007-591R1.html?
jumpid=reg_R1002_USEN
55
Ringraziamenti
Eccomi finalmente tagliare “IL TRAGUARDO”.
Termina un percorso intrapreso tre anni fa e che si è rivelato, in alcune
circostanze, molto difficile.
Tante volte avrei voluto lasciare ma guardando dove sono arrivata il mio
ringraziamento va a tutte quelle persone che mi sono state sempre vicino.
Un immenso grazie va ai miei genitori che mi hanno sempre incoraggiata e
spronata a dare il massimo, che hanno creduto nelle mie capacità e mi hanno
consolato nei momenti difficili.
Un ringraziamento speciale va anche ai miei amici di corso Raffaele, Pasquale,
Fabio, Vincenzo, Claudio e Davide; la loro amicizia ha riempito le mie giornate
universitarie ed è anche merito loro se oggi sono qui.
Sicuramente la soddisfazione più grande che questi anni di studio mi hanno
regalato è quella di aver firmato, in un momento in cui i giovani hanno mille
dubbi su cosa fare dopo aver conseguito la Laurea, un contratto di lavoro che mi
permette di mettere in pratica quello per cui mi sono tanta impegnata.
Grazie di Cuore
56
57

Elaborato Crispano Naomi N46000048

Transcript

Documenti analoghi

VMware Horizon view 5.3 Piattaforme Hardware e

Teoria Virtualizzazione

Gian Pietro Camisa

i rischi dei dati virtuali

Quando adottare un sistema di virtualizzazione in azienda

Ambienti Virtuali e Apprendimento

Scarica

Virtualizzazione e Sicurezza