|
Attualmente
adottare soluzioni di virtualizzazione nelle aziende,
per affrontare diverse problematiche di gestione ed
utilizzo delle risorse, sta diventando sempre piu`
una pratica comune. Quale e` il motivo o i motivi
che spinge le aziende ad adottare tale politica?
I
motivi sono molteplici, andiamo ad elencarli.
Avere
una macchina dedicata, per ogni singolo servizio,
potrebbe diventare molto dispendioso, difatti, a meno
che il carico di un determinato servizio non sia eccessivo,
la soluzione standard e` quella di utilizzare una
singola macchina contenente piu` servizi (mail, web,
team dev, etc.), cosi` facendo si abbattono i costi
hardware, in quanto una singola macchina ben configurata
riesce a gestire un pool di servizi del genere. Il
problema di una soluzione simile e` di compromettere
la stabilita` e la sicurezza della macchina, e quindi
di tutti i servizi residenti. Per assurdo la macchina
puo` essere bersaglio di attacchi DoS oppure di tentativi
di intrusione, se un servizio e` vulnerabile, si rischia
la sicurezza di tutta la macchina, e con la conseguenza
che il ripristino e la “messa in sicurezza”
di un servizio genera un downtime di n servizi.
Quindi
adottare una soluzione di virtualizzazione ha come
pro il fatto che ogni servizio puo` girare su una
virtual machine separata, in questo modo in caso di
fault di un servizio per un motivo qualsiasi sopra
elencato, provochera` un downtime del singolo servizio,
senza intaccare gli altri sulle altre vm.
E`
chiaro che in caso di fault hardware, il problema
si presenta ugualmente, in quando e` la macchina host
che “si ferma”.
Un'altro
punto a favore dei sistemi di virtualizzazione e`
la possibilita` di rilocare un vm da un'host all'atro,
senza problemi di compabilita` o tempi di reinstallazione
e riconfigurazione. Per assurdo in caso di fault
hardware di un host, se si ha a dispozione, per esempio
in una unita` di backup, l'immagine delle vm attive
nei momenti precedenti al fault, e` possibile rilanciarle
su un'altro host in tempi brevissimi, di modo da arginare
il disservizio e diminuire drasticamente i tempi di
downtime.
Utilizzando
questa soluzione, si ha una diminuzione del costo
hardware, ma dobbiamo analizzare alcuni punti fondamentali
per capire bene che c'e` un limite, oltre il quale,
da risparmio, si passa ad un aumento di costo.Una
macchina media per poter ospitare un sistema di virtualizzazione
a carico standard, dato da un utilizzo di servizi
quali, mail server, web server, database server (a
basso carico), ha circa le seguenti caratteristiche
hardware:
-
Dual processor almeno 2,0 ghz .
-
4 GB di ram.
-
HD scsi in mirroring con controller hardware.
Una
macchina del genere puo` contenere all'incirca 4 immagini
vm (una per il server mail, una per il server web,
una per il database server ed una come backup). Ora
possiamo scegliere due tipi di virtualizzazione (full-image
e shared-image), solitamente si adotta un sistema
di tipo full-image (i classici VM-Ware OpenVZ e Xen),
in questo modo avremo 4 vm che si dividono in modo
equo, o a seconda del carico dei vari servizi, processore
e ram. Questo e` ottimo appunto in situazioni di basso
carico, ma in situazione di carico alto o carico critico,
l'host ospitante i vari servizi dovra` avere un'hardware
decisamente superiore rispetto a quello elencato,
e visto che stiamo parlando di una singola macchina,
questo fara` si che i costi si alzino drasticamente,
in quanto si deve andare su soluzioni particolari
e di fascia alta. Quindi dobbiamo dire che virtualizzare,
conviene in caso di carichi medio-bassi, altrimenti
si perde il vantaggio del risparmio dei costi.
Adesso
trattiamo i due tipi principali di virtualizzazione
maggiormente utilizzati e le tecnologie che li implementano.
Full-Image ed Shared-Image
Per
full-image si intende sitemi di virtualizzazione come
VM-Ware, OpenVZ e Xen (quest'ultimo non e` proprio
da considerarsi completamente Full-Image ma e` il
caso di fare un discorso separato), i vantagi sono:
Possibilita`
di suddivisione risorse (quota), di ram, cpu, disco,
network molto piu` semplice ed immediata rispetto
ai sistemi shared-image, quindi si ha un controllo
maggiore e piu` preciso sull'occupazione di ogni singola
vm.
La
rilocazione molto spesso consiste nello spostare un
singolo file, inoltre puo` essere rilocata anche accesa
poiche` e` possibilie “serializzare” lo
stato della vm, spostarla, e ricostruire tutto lo
stato runtime da un'altra parte, inoltre puo` essere
semplicemente clonata.
Alcuni
degli svantaggi che ha una soluzione di questo tipo
sono:
Le
full-image da fuori sono viste come scatole chiuse,
e vengono assimilate ad un singolo processo, ed il
master non ha visione di cosa succede, conseguenzialmente
l'amministrazione straordinaria e` pressoche` impossibile
ed e` altrettanto impossibile ottimizzare l'uso delle
risorse oltre un certo limite.
Inoltre
(gravissimo) ogni istanza di, supponiamo, 100 vm identiche,
spreca lo spazio ram necessario per l'immagine del
kernel (poichè ciascuna ha il suo), e la quota
disco per ciascuna installazione dell'OS che ci sta
sopra.
Per Shared-Image si intende sistemi di virtualizzazione
come Jail-BSD, e Solaris Containers (linux lasciamolo
da parte per ora), andiamo ad elencarne i vantaggi:
L'amministrazione ordinaria e straordinaria è
semplicissima poichè il master ha la visione
immediata di qualunque processo interno del vps, e
lo stato interno del vps, sebbene completamente isolato
dagli altri, costituiesce nel complesso parte dello
stato del master.
Rilocabilità: ci sono vantaggi e svantaggi.
Il vantaggio è che per spostare un sistema
di questo tipo basta "tar", lo svantaggio
è che rilocarlo significa rilocarlo "spento".
Questo e` un argomento che andrebbe espanso in quanto
ci sono varie soluzioni per affrontare il problema.
Vantaggissimo: molti sistemi ospiti dello stesso master
possono condividere medianti appropriati trucchismi
(tipo mount --bind su linux) le stesse directory di
sistema, riducendo a 1 l'ingombro di N installazioni
del sistema operativo ospitato dai guest. Non solo,
grazie a questo trucchismo si riduce a 1 anche l'ingombro
in RAM poichè tutti per i VPS che avviano i
medesimi binari, si sta caricando in RAM esattamente
lo *stesso* file, e il sistema operativo del master
è abbastanza furbo da gestire adeguatamente
la cosa, creando in RAM una sola istanza ("segmento
TXT").
Per
cui si arriva tranquillamente al paradosso che 100
sistemi VPS non impegnati (cioè come lo sono
la maggior parte del tempo nei casi comuni) impegnano
in RAM meno di 10MB mentre 100 sistemi VPS full-image
nelle stesse condizioni richiedono 20-30GB di RAM.
Un VPS, non e`: una chroot, un account shell,
una vm Microsoft. E` importante fare differenza in
quanto altrimenti si incorrono in grossolani errori
di concetto.
Un
ringraziamento particolare va a neta.
Blackm[s]
|
