Sono piu che felice nel vedere che non ho fatto una analisi sbagliata, infatti da pochi mesi Red Hat ha scelto di puntare tutto in questo progetto comprando l’azienda Gluster.

L’obiettivo di Red Hat è quello di aggiungere già all’interessante offerta anche il supporto a un file system distribuito e parallelo.

Immaginamoci un’azienda con diversi server fisici usati per la virtualizzazione, per assurdo gli stessi server aggiungendo dei dischi ulteriori o sfruttandone gli esistenti possono diventare un sistema storage distribuito con possibilità di scalabilità e performance estensibili, si potrebbe perfino decidere di non usare più uno storage esterno. Ad ogni nodo di virtualizzazione che si aggiunge nel tempo si incrementa anche la dimensione il parallelismo e lo spare dello storage distributio.

Una tecnica che, se applicata con i metodi più appropiati, permetterebbe un risparmio notevole in spazio rack e di consumi di corrente, portando grossi benefici di performance e affidabilità.

Sono tecniche tutelate da brevetti ma che il mondo dell’open source vuole comunque implementare nei propri sistemi, ci sono già delle voci di possibili azioni da parte di Vmware ma non è quello di cui voglio parlare.

Kernel SamePage Merging, aka KSM (conosciuto prima come Kernel Shared Memory) è una tecnologia recentemente introdotta dal kernel 2.6.32

KSM kernel daemon, ksmd, periodicamente scansiona le aree della memoria in cerca di pagine identiche che possono essere riposizionate in una singola pagina protetta in scrittura, non tutta la memoria viene scansionata, l’area in questione deve essere specificata dal software (funziona quindi nell’userspace) attraverso l’utilizzo di funzioni specifiche (madvise)

Già ora per KVM (come non sempre è vero per Vmware) in alcuni test si parlano di situazioni del tipo “52 Windows Xp con 1GB di RAM emulati consumano 16GB di RAM“, presto spero di poter fare delle verifiche a riguardo.

KSM era stato sviluppato inizialmente per l’utilizzo con KVM, ma visto l’utilità di tale tecnologia ora è possibile usarla con ogni altro sistema di virutalizzazione in user space o anche in sistemi non virtualizzati, per esempio semplici applicazioni che utilizzano gli stessi processi o spazi di memoria che possono essere condivisi (piu Firefox aperti ad esempio) KSM daemon è controllato dal sysfs fs in /sys/kernel/mm/ksm/, la documentazione può essere trovata in Documentation/vm/ksm.txt del kernel

Per approfondire: http://www.kernel.org/doc/ols/2009/ols2009-pages-19-28.pdf

Mi hanno gi? rubato un nodo del fatidico cluster, comunque nel frattempo ho altro da fare.

Infatti dopo ave installato XenCenter e averci sbattuto un po la testa mi accorgo che il suo utilizzo ? osceno!

Forse ? per la poca maturit? del prodotto ma XenCenter non visualizza in modo corretto le risorse e non riesco nemmeno a creare un sotrage shared con NFS..

Mi ? successo pure che certi settaggi cambiavano solo chiudendo e riaprendo la GUI.

Allora mi sono deciso di seguire la via che nei sistemi unix di solito funziona sempre: il fatidico terminale con i suoi comandi!

Ho praticamente lanciato i comandi qui sotto, ed ho scoperto che con xe (o xe.exe per windows) posso fare proprio tutto e ripeto TUTTO!

Create an SR on the NFS share at the Pool level

1.

Open a host text console on any XenServer Host in the Pool.
2.

Create the Storage Repository on server:/path

xe sr-create content-type=user type=nfs name-label=<SR name> shared=true device-config-server=<server> device-config-serverpath=<path>

The device-config-server refers to the hostname of the NFS server and device-config-serverpath refers to the path on the server. Since shared is set to true, the shared storage will be automatically connected to every host in the Pool and any hosts that subsequently join will also be connected to the storage. The UUID of the created Storage Repository will be printed on the screen.
3.

Find the UUID of the Pool

xe pool-list

4.

Set the shared storage as the Pool-wide default

xe pool-param-set uuid=<UUID of the Pool> default-SR=<UUID of the Storage Repository>

Since the shared storage has been set as the Pool-wide default, all future VMs will have their disks created on shared storage by default.

In 5 minuti sono riuscito a fare quello che su un ora con la GUI non riuscivo neanche a concepire!

La certificazione di 3000 applicazioni conferma l’impegno e l’interesse del mercato della virtualizzazione in mano fino a pochi anni fa esclusivamente da VMWARE

Gli accordi intrapresi tra Microsoft e Red Hat porteranno sicuramente a dei driver paravirtualized per le VM Windows colmando cosi l’unica lacuna per il sistema operativo che gia offriva una soluzione di clustering e live migrazione deli sistemi operativi guest.

Infatti da pochissimi giorni CITRIX ha rilasciato la versione di XenServer completamente gratuita con funzionalità di live migration a costo 0!

Questa mossa costringerà i competitor a rilasciare nuove funzionalità free!

Come prima cosa sconsiglio a tutti di utilizzare il filesystem gfs2 è ancora instabile e non funziona bene sopratutto quando i carichi cominciano ad essere maggiori.

Parlando invece di virtualizzazione, la soluzione di Red Hat non è ancora pronta a mio avviso per la produzione di macchine virtuali per l’esercizio, sopratutto per quelle Windows.

Ci sono poche notizie riguardo la fornitura da parte di Red Hat dei corretti driver paravirtualize (PV), sembra sia prevista ma non c’è una data ben definita.

Senza driver PV le macchine virtuali Windows sono eseguite nella modalità "full virtualized" con scarse performance e con una stabilità scarsa. Infatti molte volte delle macchine virtuali Windows si sono "riavviate" senza un intervento umano.

L’inverso invece succede per le macchine ospite Linux, ho testato una distribuzione CentOs paravirtualized e ha funzionato benissimo per tutto il mese, molto stabile e ottime performance.

Le funzionalità di Live migration funziona molto bene anche con guest Windows senza i driver PV, ma qualche altra limitiazione nell’integrazione della cluster suite di RH con Xen a volte rende l’esecuzione delle VM instabile, in poche parole a volte le VM non vengno riavviate dopo un loro crash o i nodi del cluster decidono di migrare l’ospite su un nodo senza un nostro preciso comando.

Nel frattempo in questi giorni ho valutato una soluzione Citrix XenServer Enterprise su due nodi e ho notato delle strane differenze e limitazioni che Citrix ha imposto alla loro versione di Xen, la stabilità però esiste e la gestione dei nodi è ottima e molto semplice.

In conclusione Red Hat Virtualization non è ancora una realtà stabile, se non per virtualizzare dei sistemi Linux spendendo molto poco o praticamente nullla utilizzando CentOs.

Probabilmente con i nuovi fix di Red Hat e con la produzione dei driver PV Citrix e Vmware avranno sicuramente dei ottimi avversari, ma per il momento, almeno per il mio caso e il mio budget Citrix XenServer è l’unica soluzione professionale e affidabile oggi disponibile nel mercato.