Durante il vForum 2014 di Milano dello scorso giovedì, si è svolto un interessante seminario su VMware NSX con molte informazioni e chiarimenti a riguardo di questo particolare prodotto (ma come capiremo è riduttivo classificarlo un “semplice” prodotto).

Il cuore dell’evento si è avuto con le sessioni di:

• Jeremy Van Doorn (Senior Manager, System Engineering, NSBU EMEA, VMware) con un’introduzione sui concetti di Software Defined Data Center e di come poi si applicano al mondo del networking
• Francesco Vigo (Network Virtualization Platform System Engineer, VMware) con invece un’introduzione alla Network Virtualization (NV), ai suoi concetti chiave, ma anche ai concetti relativi all’approccio di VMware alla NV, in particolare con NSX
• Max Ardica (Senior Technical Product Manager, NSBU, VMware) con una spiegazione tecnica, ma comprensibile, di NSX

Il seminario è stato un crescendo di informazioni, ma snocciolate con chiarezza e competenza da tutti e tre i relatori.

Inutile che dica quanto il prodotto sia interessante e quanto ci sarà da studiarci (tra l’altro entro fine anno dovrebbero esserci anche le prime certificazioni in un nuovo percorso orientato proprio alla NV).

Potrebbe essere invece interessante sintetizzare in pochi punti alcuni dei concetti fondamenti che sono emersi durante la giornata.

NSX vs. other solutions

In realtà non c’è mai stato un vero e proprio confronto con altre soluzioni, ma piuttosto un posizionamento e un inquadramento di massima: questa è una soluzione di tipo “Software” a differenza di altre soluzioni (nel networking) di tipo hardware.

Per quanto riguarda la compatibilità o meno con il vecchio vSphere Network & Security (ex vShield) il manager di NSX di fatto sostituisce il vShield Manager e pare sarà previsto un processo di migrazione dal vecchio al nuovo.

IP Network

La NV ha bisogno di una struttura di rete fisica (esattamente come la server virtualization ha bisogno di server fisici). L’aspetto interessante è che basta che sia una rete IP, ovviamente resiliente e ben progettata come banda e capacità, ma soprattutto che sia scalabile. Si è parlato più di una volta del modello Leaf/Spine (che meriterà sicuramente un post di approfondimento) che in effetti ben si sposa con il modello di rete di livello 3 (visto che non implementa un’unica rete di livello 2).

Sul perché non basarsi su una rete di livello 2 pare ovvio, ma forse non per tutti: oltre al grave limita di scalabilità di una rete a livello 2 (per il dominio di broadcast) c’è poi il problema di limitata estensione geografica. Una rete di livello 3 questi problemi non li ha e a quel punto ogni armadio potrebbe avere la sua classe di indirizzi IP.

Interessante quindi che l’unico requisito sostanziale sia una rete di livello 3 che supporti MTU da 1600 (unico vero e proprio vincolo). Il Multicast non è strettamente necessario (dato che pacchetti possono essere gestiti in unicast).

VXLAN strikes back

Ovviamente le reti virtuali devono essere incapsulate in quella fisica e… sorpresa sorpresa… il protocollo usato è VXLAN. Ogni host VMware ESXi avrà almeno un’interfaccia VTEP (che di fatto diventa un nuovo tipo di interfaccia VMkernel, come avviene per Virtual SAN con la relativa interfaccia) e diventerà il terminatore dei pacchetti VXLAN.

Ovviamente all’interno di un host non serve incapsulare i pacchetti: questi passeranno tra le VM secondo le regole stabilite.

Molto interessante anche come viene costruito il pacchetto VXLAN: al fine di rendere più fruibile i vari protocolli di link aggregation, viene utilizzata una porta UDP fittizia per i vari pacchetti per creare sufficiente “entropia” e quindi una distribuzione potenzialmente più equa dei link.

Hosts must be prepared

A differenza di quanto avviene con VSAN, non c’è nulla a bordo in ESXi (di default) per usare NSX: vanno installati dei VIB opportuni, ma è compito dell’interfaccia di gestione di NSX nel momento in cui lo si vuole abilitare su uno (o più) cluster VMware.

Tra l’altro nuovi host aggiunti al cluster in seguito, si troveranno questi pacchetti già installati ed attivati.

Distribuited… distribuited… distribuited…

Switching distribuito, routing distribuito… tutto distribuito (per ora no, visto che alcune funzioni di rete per ora sono centralizzate). Ma il concetto rimane e l’approccio scale-out si applica a puntino: magari un singolo host non avrà numeri impressionanti come capacità di filtraggio di pacchetti… ma più host in un cluster possono far crescere questo numero.

Per le funzioni di rete che oggi sono centralizzate (ad esempio load balancing) saranno previste interessanti evoluzioni nelle versioni successive.

Architecture & design first to all

Sarebbe inutile dirlo, ma è ovvio che una simile struttura richiede un progetto ben pensato e anche ben implementato.

Si è discusso dell’architettura (notare che i vari elementi possono essere implementati in macchine virtuali) ed in particolare del ruolo del NSX Manager (che di fatto si sostituisce al vShield o vCNS Manager) e dei NSX controller. La disponibilità per ora è progettata sui NSX controller (in logica di maggioranza, quindi almeno 3, oppure 5, 7, …) che comunque determinano la configurazione del data plane: in caso non siano disponibili, questo continua a funzionare così come è (ma ovviamente anche un vMotion di una VM richiederebbe una riconfigurazione della rete virtuale). Per ora NSX Manager non ha una sua ridondanza o una configurazione di alta disponibilità (a parte l’ovvio utilizzo di VMware HA), ma riguarda solo l’interfaccia di configurazione. Gli NSX Edge invece hanno una configurazione in HA di tipo attivo-standby (esattamente come avviene oggi in vCNS), ma vi saranno probabilmente interessanti novità in futuro.

NSX for all of us?

Inutile nasconderlo… finora NSX era per pochi (selezionati) eletti. Ma a breve dovrebbe entrare nei listini e soprattutto disponibile sia ai partner che in trial e tutto lo potranno finalmente provare.

Sarà una soluzione per tutti? Beh… dipenderà anche dal costo, ma è chiaro che nelle infrastrutture (medio) piccole non ha il minimo senso: si ottiene più flessibilità ma per contro più complessità (se rapportato su un’ambiente di piccola scala).

Ci sarà anche da vedere su quali edizioni di vSphere è supportato (nota che funziona sia sulla 5.5, ma, con alcune limitazioni, anche sulla 5.1 di vSphere): un requisito lato ESXi è la disponibilità dei distribuited virtual switch (DVS) cosa che effettivamente è solo per la Enterprise Plus. Bisognerà vedere se NSX includerà anche i DVS (come del resto succede con VSAN) o se vorrà proprio la Enterprise Plus.

Andrea Mauro

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.