This post is also available in: Inglese

Reading Time: 10 minutes

Una delle novità del nuovo VMware vSphere 6.0 più “spoilerate” in assoluto (forse dopo solo i nuovi Virtual Volume) è stata quella relativa al nuovo vMotion in grado di superare i limiti imposti dal vCenter. Ora può funzionare anche tra diversi vCenter Server, diversi Datacenter e diversi virtual switch… ma persino tra diverse aree geografiche.

Oggettivamente vMotion è stata la prima grande novità introdotta VMware e, secondo me, quella che veramente ha permesso di implementare soluzioni di virtualizzazione di classe enterprise: poter spostare le VM tra diversi host senza fermarle permette di implementare poi soluzioni quali il bilanciamento dei carichi di lavoro, o anche le attività di manutenzione pianificate.

Come il primo vMotion è stato abilitante per la virtualizzazione, questo nuovo vMotion potrà essere veramente abilitante per il cloud, in particolare per implementare soluzioni di migrazione tra cloud, bilanciamento tra cloud e ovviamente soluzioni di cloud ibrido.

Bisogna però spegnere gli entusiami… non vuol dire che già da ora è possibile un vMotion verso, ad esempio, vCloud Air… ad oggi serve avere accesso ad entrambi i vCenter (quello sorgente e quello di destinazione) cosa che non è sicuramente possibile (o quanto meno non semplice) con servizi IaaS gestiti da terzi… ma in fondo questo è il primo passo che non esclude (anzi che sicuramente prepererà) questa possibilità per il futuro.

Inoltre servirà anche anche tutte le proprierà e le policy di una VM possano “seguirla” durante lo spostamento… ma da questo punto l’approccio di VMware a SDN (con NSX) e ad SDS sono sulla giusta strada per arrivare ad implementare la vision di VMware di un unico cloud.

Tornando a vMotion, già nella versione 5.x vi erano stati significativi miglioramenti:

  • v5.0: supporto Multi-NIC, supporto per una latenza maggiore (fino a 10ms) e la funzionalità di Stun During Page Send (SDPS) per permettere a vMotion di completare l’operazione.
  • v5.1: supporto per il vMotion tra host senza storage condiviso (disponibile tramite Web Client o CLI)
  • v5.5: miglioramenti vari, soprattutto nelle configurazioni in metro-cluster

Ora, con vSphere 6.0 sono possibili nuovi scenari di vMotion:

  • Cross vSwitch vMotion: permette di spostare le VM a caldo tra virtual switch diversi, ma all’interno di una struttura gestita dallo stesso identico vCenter Server. L’operazione è completamente trasparente al sistema operativo guest e sono supportati i passaggi tra diversi tipi di virtual switch (standard o distribuiti).
  • Cross vCenter vMotion: permette di spostare le VM a caldo tra diversi “confini”: vCenter Server, Datacenter, Folder, … Questa operazione ovviamente cambia simultaneamente le risorse di compute, storage, network e vCenter.
  • Long Distance vMotion: permette di spostare le VM a caldo tra diverse regioni o nazioni (esistono comunque dei limiti che commenteremo meglio dopo).

Notare che comunque in tutte queste operazioni le VM non vengono riconfigurate a livello di IP, quindi è necessario che esista una connettività di livello 2 comune tra sorgente e destinazione. Se facilmente realizzabile all’interno dello stesso datacenter, magari non è ovvia tra datacenter diversi o tra zone geograficamente separate… da questo punto di vista SDN ed in particolare le VXLAN e NSX sono decisamente utili per “virtualizzare” la rete.

Rimane poi inalterato il requisito di compatibilità di processore (che stranamente tutti i post che parlano del nuovo vMotion dimenticano, ma che comunque è riportato nel manuale, almeno nella versione beta): la VM deve trovarsi le stesse identiche istruzioni hardware della sorgente. Frequenza di clock, domensione della cache, numero di core fisici possono essere diversi. E ovviamente EVC può aiutare ad uniformare i processori, ma deve essere applicato all’inizio, prima di poter migrare le VM e la baseline deve essere identica (tecnicamente potrebbe funzionare se la baseline di destinazione fosse maggiore, ma bisognerà aspettare la versione finale per capirne gli effettivi requisiti).

Vuol anche dire che non sarà mai possibile spostare (a caldo) tra piattaforme diverse e che comunque la baseline EVC andrebbe pianificata in partenza. C’è poi da considerare che VMware non supporta ESXi virtuali in un cluster EVC, il che potrebbe anche limitare scenari di “cluster VMware as a Service” con queste funzioni di migrazione.

Ovviamente poi vi sono anche altri requisiti aggiuntivi sia per gli host che per le VM, ma questi rimangono a grandi linee gli stessi delle versioni precedenti (per maggiori informazioni consultare la guida “vCenter and Host Management Guide”)

Interessante invece che nel documento attuale (che comunque è ancora in RC e quindi potrebbe essere una svista o, se confermato, un’importante novità), nella sezione di best practices for vMotion networking vi è il consiglio di utilizzare i jumbo frames per la rete di vMotion al fine di migliorarne le prestazioni (bisognerà vedere se poi veramente corrisponderanno prestazioni migliori, visto che finora non è proprio stato così).

Vi sono poi numerosi altri miglioramenti per quanto riguarda la flessibilità sulla rete del vMotion che ora supporta anche reti a livello 3 (ossia routabili) a differenza di quanto succedeva nella versione 5.x (e precedenti) dove la rete del vMotion doveva per forza essere L2.

Stesso dicasi per la rete NFC utilizzata però per il traffico di tipo migrazioni o copie a “freddo” come ad esempio nei backup.

Geo-vMotion

Non potevano mancare numerosi miglioramenti anche a livello delle VM, per aumentarle la mobilità. Ad esempio:

  • Possibile migrare le VM con grafica 3D abilitata, in particolare se il 3D renderer è impostato in automatico. Se invece è impostato in modalità Hardware allora la destinazione dovrà avere una scheda GPU hardware e non si potrà usare l’emulazione via CPU.
  • Possibile migrare le VM con dispositivi USB collegati. Va comunque abilitata.
  • Possibile migrare le VM di un Microsoft Cluster. In base alla compatibilità e supporto discusse nel post relativo alla disponibilità, queste VM devono avere un physical RDM e un sistema operativo Windows 2008, 2008 R2, 2012 o 2012 R2.

Ma torniamo alle novità più rilevanti del nuovo vMotion: la possibilità di spostarsi tra diversi vCenter Server e persino tra diverse aree geografiche.

Cross vCenter vMotion

Come scritto in precedenza, questa operazione permette ma migrazione di una VM a caldo tra risorse diverse di tipo compute, storage, network e management e può essere usata in contesto locale, metrotropolitano o persino geografico.

vSphere6-vMotion Le caratteristiche principali di questo tipo di vMotion tra due diversi vCenter Serve sono:

  • Viene mantenuto il VM UUID (ma non il MoRef o il BIOS UUID)
  • Viene mantenuto il MAC Address delle virtual NIC e (ovviamente) rimane univoco all’interno del vCenter. Notare che non vengono riutilizzati quando una VM viene spostata e quindi liberata da un vCenter.
  • Vengono mantenuti tutti i dati storici delle VM: eventi, alarmi, task history (ma non si parla però delle statistiche)
  • Vengono mantenute anche altre informazioni:
    • HA properties
    • DRS Affinity/Anti-Affinity Rules

Il secondo punto è decisamente interessante, ma presenta dubbi sul come evitare MAC Address duplicati… se ogni vCenter genera indirizzi di livello fisico autonomamente per la sua infrastruttura, come possiamo scongiurare l’ipotesi di trovarsi con MAC Address duplicati dopo un vMotion di questo tipo? La risposta viene dalla KB 1024025 (Virtual machine MAC address conflicts or have a duplicate MAC Address when creating a virtual machine): il modo più semplice è assicurarsi che i due vCenter Server abbiano un differente instance ID.

I requisti e i limiti di questo tipo di vMotion sono:

  • vCenter 6.0 (o successivi) e ESXi Enterprise Plus (questa e la prossima funzione sono disponibili solo con la Enterprise Plus)
  • Almeno 250 Mbps di banda per ogni operazione di vMotion contemporanea
  • Stessa rete L2 per le VM
  • Stesso dominio SSO per i due vCenter Server se vi vuole eseguire l’operazione tramite Web Client, altrimenti sarà possibile eseguirla solo tramite API e CLI (vedere questo post).

Long-distance vMotion

In realtà non è altro che il caso precedente dove i due vCenter si trovano ad una “certa” distanza.

In questo caso è opportuno ribadire quali sono i requisiti di rete per ogni operazione di vMotion concorrente (questi dati sono riferiti alla versione RC, bisognerà poi vedere se saranno confermati nella versione finale):

  • Almeno 250Mbps di banda (dedicata per una questione più che altro di sicurezza) Più banda c’è prima viene eseguito il vMotion (che comunque dipende anche dalla dimensione della VM da migrare). Sarà da vedere se gli acceleratori di banda saranno o meno supportati (e se inizieranno ad esserci acceleratori specifici per il geo-vMotion).
  • Latenza massima, o meglio network round-trip time (RTT) massimo di 100 milliseconds.

Dei due numeri, quello che spegnerà subito gli entusiasmi (se confermato nella versione finale) è sicuramente quello remativo alla banda (soprattutto se lo pensiamo alla realtà italiana). In fondo il vincolo sulla latenza potrebbe essere quello minore, se si pensi che i RTT tipici sono spesso dentro questo valore. Ad esempio:

  • 73ms from New York to San Francisco (4100km)
  • 80ms from New York to Amsterdam (5900km)

Altri requisiti di rete sono:

  • Se il vMotion è cross vCenter, ovviamente i due vCenter devono raggiungersi almeno a livello 3
  • La rete delle VM deve essere invece una stessa rete di livello 2 (come già discusso in precedenza)
  • La rete del vMotion può anche essere di livello 3, tra reti logiche diverse e routabili e per ragioni di sicurezza dovrebbe essere dedicata o cifrata (il traffico del vMotion è ancora sostanzialmente in chiaro). Vi sono poi i requisiti di latenza e banda già spiegati in precedenza.

Interessanti i diversi casi d’uso di questa migrazione:

  • Permanent migrations: la più ovvia… migrare una VM per cambiarla di destinazione e poi lasciarla nella nuova destinazione.
  • (Planned) Disaster avoidance: i disastri di solito non sono prevedibili… ma un distacco di corrente o un uragano in avvicinamento potrebbero esserlo… Oppure un’attività pianificata di manutenzione datacenter. Sarà anche curioso vedere se versioni future di SRM potranno usare questa funzione per un planned failover.
  • Multi-site load balancing: distribuire le VM a livello geografico in base al carico… sicuramente interessante e non detto che prima o poi non salterà fuori una funzione di tipo geo-DRS.
  • Follow the sun: letteralmente “seguire il sole”… ossia seguire un particolare trend (magari temporale). Ad esempio un’azienda con diverse sedi nel mondo con orario di lavoro che porta le VM a spostarsi nel datacenter più vicino per avere una risposta più pronta. Oppure pensiamo a chi gestisce datacenter e voglia ottimizzarli, ad esempio usando il fresh air e facendo lavorare più VM nella notte o nelle stagioni più “fresche”).

Va comunque ribadito che questo tipo di vMotion richiede risorse e tempo (variabile in base alla banda disponibile e alla dimensione delle VM)… è una possibilità, sicuramente non da tutti, sia per i diversi requisiti (inclusa l’edizione Enterprise Plus), sia per la realtà di connettività geografica italiana, sia ancora per la poca cultura riguardo alla network virtualization (o comunque a configurazioni di rete come quelle richieste per le VM).

Diventa comunque un importante possibilità e innovativa funzione che più che essere vista come traguardo d’arrivo, va vista come nuovo punto di partenza dal quale iniziare a pensare e sviluppare nuovi tipi di soluzioni e servizi.

Vedere anche

Per maggiori informazioni vedere anche questi post (in inglese):

Share

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.