QuickMigration e VMotion a confronto

Ultimamente in rete si dibatte con una certa assiduità sul confronto di funzionalità tra QuickMigration e VMWare LiveMotion.

Tutto è iniziato con un post di Mike DiPetrillo di VMWare in cui l'autore dimostra, con due video, che usando QuickMigration per migrare una macchina virtuale da un host Hyper-V ad un altro VM si perdono le connessioni TCP mentre questo non avviene con VMotion.

DiPetrillo mostra la cosa come se fosse una novità (tira l'acqua al suo mulino e la cosa ci sta visto l'azienda per cui lavora).

In realtà Microsoft ha sempre affermato (da quando è stato annunciato il posticipo di LiveMigration a una versione successiva di Hyper-V) che questo è il comportamento che ci si deve aspettare con QuickMigration;  che infatti si chiama Quick e non Live.

Io stesso quando tengo delle presentazioni dedicate ad Hyper-V dico esattamente come funziona la tecnologia e sostengo che è diversa da LiveMotion; guardate per esempio la sessione sulla virtualizzazione che ho tenuto durante il tour di lancio.

DiPetrillo confronta in realtà mele con arancie (o con pere se preferite) e tra poco torniamo su questo.

L'articolo di DiPetrillo viene ripreso da Alessandro Perilli in questo suo post.

E' mia opinione che Alessandro commetta, nel suo articolo, un errore di valutazione quando dice che VMotion e QuickMigration non sono tecnicamente comparabili (questo è vero: funzionano in modo completamente diverso), ma entrambe cercano di rispondere alla stessa necessità aziendale: Disaster Recovery.

Riporto testualmente la frase di Alessandro:

"Both approaches address the same business need, providing disaster recovery capabilities, in different ways, with different benefits and shortcomings."

L'errore sta nel fatto che mentre QuickMigration è anche una soluzione di disaster recovery, VMotion non lo è per nulla: per avere una soluzione di disaster recovery con la tecnologia VMWare dovete comprare HA.

Alessandro commette un altro piccolo errore (sia chiaro, non ho nulla di personale contro Alessandro, che stimo come ottimo professionista e che ho avuto il piacere e l'onore di affiancare sul palco durante la prima sessione tecnica dell'evento di lancio di Windows Server 2008 a Milano). Il secondo piccolo errore, dicevo, è che Alessandro sostiene che Microsoft non abbia ancora risposto all'articolo di DiPetrillo. Microsoft in realtà ha da tempo anticipato le conclusioni di DiPetrillo e quindi non deve dare un'ulteriore risposta: è ampiamente disponibile e documentata.

A questo punto credo che sia necessario chiarire alcune cose riguardo a QuickMigration.

QuickMigration si basa su una tecnologia Microsoft ampiamente consolidata, presente sul mercato da lungo tempo e ulteriormente migliorata in Windows Server 2008: Microsoft Cluster Service che ora si chiama Failover Cluster .

Failover Cluster Service è disponibile come componente standard (senza costi aggiuntivi) in Windows Server 2008 Enterprise e Datacenter.

QuickMigration consente lo spostamento di macchine virtuali tra i diversi nodi di un cluster (fino a 16 nodi) in cui sono installati Hyper-V e Failover Cluster Service.

Lo spostamento di una macchina virtuale avviene salvando il contenuto della memoria della macchina virtuale su un disco clusterizzato (l'operazione è paragonabile all'ibernazione di un desktop/laptop), passando il controllo del disco ad un altro nodo del cluster e ripristinando la macchina virtuale sul nuovo nodo (operazione paragonabile al ripristino di un desktop/laptop da un'ibernazione). Perchè quest'operazione sia possibile anche i dischi virtuali (.VHD) e i file .XML di configurazione della macchina virtuale devono risiedere su dischi clusterizzati.

Durante il periodo in cui la macchina virtuale è in modalita "saved" (o ibernata se preferite) non c'è uno stack di rete attivo e questo è il motivo per cui si perdono le connessioni se il processo di spostamento dura più del timeout del protocollo di rete (e tipicamente ci si trova in queste condizioni). Ovviamente la perdita delle sessioni di rete è più o meno grave a seconda dell'applicazione in esecuzione e della qualità del codice di queste.

Tempi di spostamento di un VM tra due host con QuickMigration in funzione di RAM e volocità dello storage di rete

Questo, in breve, il funzionamento di QuickMigration e adesso consentitemi di illustrare quelli che secondo me sono vantaggi e svantaggi di questa tecnologia.

Lo svantaggio (rispetto alla soluzione della concorrenza) è la perdita delle sessioni di rete durante lo spostamento delle macchine virtuali. Questo comporta la necessità di pianificate delle finestre di downtime (comunque brevi) dei servizi nel caso si debbano spostare macchine virtuali da un nodo ad un altro di un cluster per fare manutenzione, per bilanciare i carichi ecc.

Il grande vantaggio di QuickMigration, secondo la mia modesta opinione, è che un'unica soluzione consente di:

• Spostare macchine virtuali quando necessario
  Lo spostamento può essere comandato manualmente da System Center Virtual Machine Manager v2, dalla console di amministazione del Failover Cluster Service, da linea di comando con script PowerShell.
  E' anche possibile automatizzare lo spostamento delle macchine virtuali usando System Center Operations Manager come sistema di controllo di SCVMM v2 o del servizio Failover Cluster.
  In questo caso (per i servizi che possono supportare senza problemi un downtime di pochi secondi) Operations Manager può intervenire con maggiore intelligenza rispetto alla soluzione di VMWare perché è in grado di controllare lo stato di funzionamento non solo del livello di virtualizzazione, ma anche delle singole applicazioni in esecuzione nelle macchine virtuali (application aware).
  Questo livello di controllo non è assolutamente possibile, ad oggi, con soluzioni VMWare.
• Implementare un Disaster Recovery
  In caso di problemi con un server fisico, la stessa tecnologia che consente di spostare le macchine virtuali a richiesta, permette di effettuare il failover delle stesse su un diverso nodo del cluster.
  Le macchine virtuali saranno ridistribuite automaticamente tra i diversi nodi del cluster e riavviate.
  Questo comportamento è del tutto analogo è quanto è possibile ottenere con HA di VMWare, ma senza l'onere di acquisto di un ulteriore prodotto.
  Con Failover Cluster e QuickMigration è possibile costruire soluzioni di disaster recovery anche geograficamente disperse, senza cambiare la tecnologia di base.

Un ultima nota di questo ormai lunghissimo post.

Anche Massimo Re Ferré (di IBM) ha fatto un post sul suo blog in cui confronta VMWare HA con il Failover Cluster di Microsoft. Il post è decisamente equilibrato e lo scopo è mettere in evidenza quello che, secondo Massimo, è un cambio di paradigma nell'uso delle tecnologia di alta disponibilità: lo spostamento dell'alta disponibilità dal livello del sistema operativo a quello dell'infrastruttura di virtualizzazione con un movimento nella direzione degli application appliance (questo è un concetto caro a Massimo e in cui crede molto).

Il post di Massimo è molto equilibrato e ben fatto (come al solito). L'unico appunto che mi sento di fare è che nella prima metà dell'articolo Massimo confronta VMWare HA con un cluster tra macchine virtuali basato su MSCS e il messaggio che sembra passare è che questa sia la configurazione consigliata/usata in un ambiente di virtualizzazione basato su tecnologia Microsoft, mentre solo con Hyper-V si possano implementare cluster di host di virtualizzazione. In realtà non è così e già oggi con Virtual Server 2005 R2 è possibile costruire cluster di host di virtualizzazione e clusterizzare le macchine virtuali come si fa con altri servizi. Quello che Windows Server 2008 e Hyper-V ci forniscono è una migliore integrazione tra le interfacce di gestione del Failover Cluster Service e Hyper-V.

Spero di non aver ulteriormente aumentato l'entropia.

Giorgio

Technorati Tags: Microsoft,Windows Server 2008,Virtualization,Hyper-V,Failover Cluster

Comments

• Anonymous
  January 01, 2003
  @Massimo è un piacere sentirti Massimo. Per fortuna molti nostri clienti considerano Virtual Server 2005 una tecnologia di virtualizzazione adatta alle loro necessità tecniche ed economiche :) Giorgio

• Anonymous
  January 01, 2003
  @thebitstreamer Concordo con te che la soluzione di Microsoft (immagino tu stia parlando di Hyper-V) sia ancora in RC0 :) e in fase di evoluzione, ma certo unita a SCVMM, SCOM è in grado di fornire una soluzione di virtualizzazione e alta disponibilità che è in grado di soddisfare le esigenze di molti nostri clienti e molte esigenze di tutti (permettimi il gioco di parole). Penso in particolare alla gestione completa dello stack virtualizzato (host di virtualizzazione, macchine virtuali, applicazioni nelle macchine virtuali) che consente di semplificare il management e prendere decisioni più smart. Rifaccio un esempio che mi è caro (non mio per altro): Con lo stack di gestione di VMWare non si è in grado di sapere cosa avviene nelle VM (cosa fanno le applicazioni) così se un VM inizia a consumare molte risorse HW la soluzione VMWare è la migrazione (per carità senza interruzione di servizio) su un altro host (magari in automatico?). Con lo stack Microsoft (in particolare SC Virtual MAchine Manager e SC Operations Manager) è possibile magari accorgersi che l'uso di risorse è dovuto ad un'applicazione WEB in loop e quindi eseguire il "recicle" dell'applicazione invece di migrare la VM... cos'è più smart? Giorgio

• Anonymous
  January 01, 2003
  Giorgio, accetto l'appunto. Diciamo che, in genere, tendo a non considerare l'esistenza di MS Virtual Server........ :-)   Comunque se un cliente/utente ritiene MSVS una tecnologia/architettura sufficientemente robusta per il proprio progetto di virtualizzazione quello che dici e' corretto... Massimo.

• Anonymous
  January 01, 2003
  @thebitstreamer Concordo completamente con te su questa cosa. Ciao, Giorgio

• Anonymous
  January 01, 2003
  Direi proprio di si. Oggi ne parlavo con il mio TAM (citandoti...) e credo che la strategia vincente sia proprio quella del management. Paradossalmente la virtualizzazione, nata per consolidare in pochi "ferri" tanti server, ha come effetto collaterale la server pollution (l'inquinamento da server ;-) in cui il numero di server guest si moltiplica e l'assenza di strumenti di management adeguate a gestirne il ciclo di vita rende tutto molto complicato.

• Anonymous
  January 01, 2003
  Al momento non posso che essere d'accordo con Massimo (ti saluto, con un whois sul dominio capisci tutto..) visto che la soluzione di Microsoft è ancora immatura (oltre che in Beta...) Qui trovate tutte le mie considerazione http://www.thebitstreamer.com/index.php/2008/04/16/virtualizzazione-ed-ha-la-prova-dei-fatti/#more-79