<< Torna agli Approfondimenti Tematici

1. Introduzione - Definizione di Network Virtualization e suoi obiettivi.

Nel corso degli anni VMware è arrivata ad un concetto di datacenter virtuale sempre più radicale. Partendo dalla virtualizzazione delle sole risorse computazionali (CPU e memoria) l'ha estesa nel tempo a tutte le componenti dell'infrastruttura IT, come lo storage e la rete. L'obiettivo è quello di disaccoppiare il più possibile i servizi forniti dalle caratteristiche specifiche dell'hardware di supporto affrancandosi dalle sue inevitabili rigidità, e di avvicinarsi così sempre più ad un modello di IT as a Service dove la flessibilità nel pooling di tutte le risorse, gestite integralmente attraverso il software, risulta essere massima. Questo modello a cui VMware punta ormai da tempo viene detto in sintesi SDDC (Software Defined Data Center).

Uno dei punti più delicati di questo processo è sicuramente la virtualizzazione della rete. Con ciò si intende la possibilità di trasferire nell'ambiente virtuale tutta l'intelligenza tipica di un'infrastruttura di rete, fino ad oggi essenzialmente realizzata in hardware. Questo processo di virtualizzazione tende a ridurre la rete fisica ad un puro backplane per il trasporto dei pacchetti e ad ottenere una gestione delle funzionalità di rete interamente guidata dal software con una conseguente capacità di riconfigurazione di tali funzionalità mai avuta prima.

In questo articolo verranno descritti i concetti principali su cui si fonda la virtualizzazione della rete così come viene realizzata da VMware NSX, senza entrare nei dettagli delle implementazione dei singoli componenti, per i quali rimandiamo al corso ufficiale VMware (vedi alla fine dell'articolo).

2. Concetto di separazione tra Management Plane, Control Plane e Data Plane.

Il primo concetto importante è quello della separazione dei piani logici di gestione e funzionamento della rete. In un dispositivo hardware classico, quale uno switch, un router o un firewall questa separazione non ha senso e non esiste. La gestione di un tale dispositivo (management plane) è interamente fornita localmente dal suo sistema operativo, ed è totalmente indipendente da quella di tutti gli altri dispositivi. Lo stesso si può dire delle sue strutture di controllo (control plane), quali ad esempio le tabelle di inoltro di livello 2 o di livello 3, e delle funzionalità di smistamento del traffico vero e proprio che da queste derivano (data plane).

Nel processo di virtualizzazione di queste risorse tali piani logici possono subire un dislocamento in punti differenti dell'infrastruttura, dove più conviene, consentendone per esempio un controllo centralizzato. Ad esempio nelle funzionalità di switching o di routing le strutture di controllo possono essere in parte o in tutto centralizzate in alcuni elementi dell'infrastruttura virtuale mentre le funzionalità di inoltro del traffico possono essere completamente distribuite.

Per fissare maggiormente le idee, osservando la figura 1 che rappresenta i componenti funzionali di VMware NSX, distinguiamo tra gli altri i seguenti oggetti:

NSX Manager: è il primo componente che viene introdotto in un'infrastruttura vSphere gestita da un vCenter Server. Si tratta di una macchina virtuale il cui compito è quello di distribuire tutti gli altri componenti e di gestire gran parte delle configurazioni. E' strettamente relazionato al vCenter (l'amministrazione è interamente supportata dal vSphere Web Client) e costituisce il punto di collegamento con eventuali piattaforme di Cloud Management. Per tutti questi motivi la figura mette questo componente nel Management Plane.

NSX Controller Cluster: è un cluster di macchine virtuali installate da NSX Manager, si occupano della gestione di molte strutture dati che supportano i moduli di switching e routing integrati nell'hypervisor. La sua posizione logica è quella del Control Plane.

NSX Logical Router Control: questa macchina virtuale è responsabile della costruzione della tabella di routing (attraverso opportuni protocolli di routing definiti e configurati dall'amministratore) che attraverso il Controller Cluster viene poi comunicata e utilizzata dal modulo di routing distribuito dell'hypervisor. Anch'esso è ovviamente posizionato nel Control Plane.

NSX Virtual Switch: quest'oggetto non è altro che un Distributed Virtual Switch integrato dagli Hypervisor Kernel Modules, gli elementi fondamentali installati da NSX Manager su ciascun host per consentire le attività di switching, routing e firewalling distribuiti di cui parleremo più avanti. Questi moduli del kernel lavorano sul data plane, cioè eseguono l'instradamento dei pacchetti sulla base delle configurazioni imposte dal management plane e delle informazioni elaborate dai componenti del control plane appena descritti.

NSX Edge Gateway: questo componente è una virtual machine che fa eccezione nello schema generale che stiamo descrivendo. Fornisce vari servizi (quali routing, firewall, load-balancing) ma tutti di carattere centralizzato, cioè in essa quantomeno convivono il control plane e il data plane secondo uno schema di funzionamento più "classico".

3. VXLAN e Logical Switching.

Un ruolo essenziale per il disaccoppiamento tra la rete fisica di trasporto e la rete virtuale è giocato dal concetto di VXLAN, acronimo di Virtual eXtensible Local Area Network. L'idea è quella di realizzare un dominio L2 nel virtuale il cui traffico possa essere trasportato da una generica rete L3 presente nel fisico. Fatto questo sarà poi possibile comporre i vari domini L2 (vedi sezione successiva) e costruire nel virtuale una qualsivoglia rete L3 con una logica, e con un insieme di possibili servizi, del tutto indipendente dall'architettura di rete fisica sottostante. Quest'ultima rimane nell'infrastruttura globale con il solo ruolo di backbone di trasporto del traffico da un punto all'altro del datacenter, e fuori da esso, quando necessario.

La tecnica per ottenere questo disaccoppiamento è semplicemente un tunneling. Se due macchine virtuali vogliono comunicare stando sullo stesso dominio L2 virtuale ma su due host fisici differenti (supposti su due segmenti IP separati della rete fisica L3) abbiamo due punti di vista dello stesso problema di trasporto. Il punto di vista delle virtual machines (ambiente virtuale) è quello della dinamica di trasporto in L2: stesso segmento IP, nessun gateway necessario, uso del protocollo ARP per la risoluzione del destinatario finale, consegna diretta dei pacchetti; il punto di vista degli host (ambiente fisico) è quello della dinamica di trasporto in L3: segmenti IP differenti, uso del gateway e uso del protocollo ARP per la sua risoluzione, consegna indiretta dei pacchetti attraverso tabelle di routing. Due logiche differenti che possono lavorare insieme utilizzando un doppio impacchettamento: il pacchetto originale in uscita dalla virtual machine con le intestazioni utili per il trasporto in L2 viene incapsulato all'uscita dall'host con ulteriori intestazioni utili questa volta al trasporto in L3. Ovviamente come sempre succede in questi casi a parlare sono quattro interfacce (a due a due), le interfacce delle virtual machine mittente e destinataria, e le interfacce di tunneling, cioè quelle utilizzate dagli host per incapsulare e decapsulare i pacchetti originali (denominate VTEP, VXLAN Tunnel End Point).

In figura 2 sono schematizzati i passaggi di funzionamento della VXLAN, intesa come dominio L2 (unico segmento IP) sovrapposto ad una rete L3 (insieme qualunque di segmenti IP, la nuvola Transport Network al centro della figura).

Ovviamente questa discussione (e l'illustrazione riportata) si ferma al solo concetto generale tralasciando una serie di importanti dettagli in merito ai meccanismi di delivery.

Nella terminologia corrente una VXLAN equivale ad un Logical Switch (nel fisico l'accesso ad una rete L2 viene appunto garantita da uno switch).

4. Distributed Logical Routing.

Una volta data la possibilità di far lavorare su una rete fisica L3 di host comunque strutturata uno o più domini L2 di macchine virtuali comunque dislocate il passo successivo è quello di connettere tali domini attraverso servizi di instradamento IP. Prima di entrare nel merito è interessante chiedersi effettivamente quanti domini L2 possono lavorare sopra una stessa rete fisica di host poichè questo ci dà la misura della scalabilità della tecnologia. E' abbastanza ovvio che questo dipende dalla capacità di veicolare nei tunnel tra gli host contemporaneamente e indipendentemente più reti distinte, mantenendole sempre individuabili. Per far questo viene introdotto un identificativo (VNI, VXLAN Network Identifier) all'interno dell'intestazione che incapsula il traffico per il trasporto nella rete fisica che individua e tiene separate le VXLAN nel tunnel esattamente come il VLAN ID nel tag IEEE 802.1Q individua e tiene separate le VLAN in un trunk. Il documento RFC 7348 ("Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", August 2014) stabilisce che il VNI sia un tag di 24 bit, ottenendo in tal modo la possibilità di trasportare fino a 2^24 (16777216) VXLAN.

L'implementazione di un meccanismo di routing tra domini L2 virtuali potrebbe essere facilmente implementata attraverso una macchina virtuale con interfacce sui vari segmenti che dovrà instradare. Una tale soluzione si rivela però sostanzialmente inefficiente in quanto genera dei percorsi di traffico nel datacenter non ottimizzati. Il problema è detto "hairpinning" ed è sinteticamente illustrato in figura 3.

In figura 3 si vede chiaramente che il percorso di un pacchetto che viene instradato da un mittente in un segmento verso un destinatario in un altro segmento può seguire un percorso inutilmente complicato (linea gialla) determinato dal fatto che tale pacchetto deve comunque raggiungere la macchina virtuale che esegue l'instradamento, indipendentemente dalle posizioni di mittente e destinatario. Il caso limite (quello di massima inefficienza) si ha quando mittente e destinatario sono addirittura dentro lo stesso host, in questo caso il traffico deve comunque uscire dall'host per poi rientrarvi dopo essere passato per il router.

La soluzione è l'introduzione nel datacenter di una funzionalità di routing distribuito. Ciò significa posizionare il Data Plane del routing direttamente su ciascun host. L'instradamento dei pacchetti su ciascun host determina il massimo contenimento possibile dei percorsi di traffico. In figura 4 si vede il netto vantaggio del routing distribuito rispetto alla soluzione centralizzata della figura precedente.

Il caso limite (quello di massima efficienza) si ha quando mittente e destinatario sono dentro lo stesso host perchè in tal caso si ottiene la comunicazione senza abbandonarlo.

Ovviamente come già detto ad essere distribuito è solo il Data Plane, cioè la funzionalità di forwarding dei pacchetti. Le funzioni di management sono garantite da NSX Manager e gestite tutte attraverso il vSphere Web Client, mentre il Control Plane è localizzato in una macchina virtuale specifica denominata Logical Router Control. Questa è responsabile della costruzione della routing table attraverso la gestione di rotte statiche o di protocolli di routing come OSPF.

Se il routing "orizzontale" (detto anche routing Est-Ovest), cioè quello tra i segmenti L2 virtuali del datacenter (le VXLAN, o Logical Switch), avviene in maniera distribuita attraverso il modulo del kernel specifico installato in ogni hypervisor, quello "verticale" (detto anche routing Nord-Sud), cioè quello che collega il datacenter all'esterno, viene invece garantito da una macchina virtuale specifica chiamata Edge Service Gateway, ed è dunque di tipo centralizzato. Il peering OSPF tra Logical Router Control e Edge Gateway, e tra Edge Gateway e router fisico esterno, garantisce l'instradamento completo che consente alle macchine virtuali del datacenter di uscire, come si può vedere dalle figure 3, 4 (linee rosse). Lo scenario logico complessivo viene mostrato nella figura 5.

5. Distributed Firewall.

La macchina virtuale Edge Gateway, già citata per i servizi di routing centralizzati, può essere utilizzata anche come firewall. Ovviamente anche in questo caso si tratta di un servizio centralizzato, con le medesime problematiche già descritte per il routing. Il classico problema dei limiti nella capacità di carico con conseguenze negative nelle performance che si possono presentare in un firewall fisico e che possono limitare la scalabilità dell'ambiente sono in questo scenario virtuale esattamente riprodotte. La soluzione quindi è anche in questo caso di distribuire la funzionalità di firewall, implementando lo screening del traffico a livello di hypervisor secondo regole che continuano ad essere gestite in maniera centralizzata.

La macchina virtuale NSX Manager raccoglie tutte le regole di firewall che l'amministratore implementa attraverso il vSphere Web Client e le comunica direttamente agli host del datacenter. Questi ultimi, attraverso il modulo del kernel dedicato a questo scopo e preventivamente installato sull'hypervisor da NSX Manager, sono i veri responsabili dell'applicazione delle regole di firewall con conseguente distribuzione del carico di elaborazione. Non è più una macchina singola ad ispezionare tutto il traffico dell'ambiente ma è l'intero datacenter a farlo, ovvero ciascun host si fa carico dell'analisi di tutto il traffico in ingresso e in uscita delle sue macchina virtuali.

Oltre alla distribuzione del carico di elaborazione si riesce ad ottenere un altro importante risultato, detto microsegmentazione. In sostanza questo modello di firewalling distribuito consente di applicare esattamente le stesse politiche di sicurezza sulle macchine virtuali, diversificandole per ciascuna di esse, indipendentemente da dove si trovino all'interno del datacenter. Se una regola di firewall stabilisce l'incomunicabilità tra due macchine virtuali questa agirà sempre, ovunque le due macchine si troveranno a girare, ad esempio anche se si vengono a trovare all'interno dello stesso dominio L2. Il concetto di isolamento di una rete diventa estremamente flessibile, una rete virtuale isolata può essere costituita da macchine virtuali distribuite in qualsiasi modo all'interno del datacenter, nello stesso host o in host separati, viceversa macchine virtuali facenti parte di distinte reti isolate possono tranquillamente essere ospitate nello stesso host. In poche parole le politiche di sicurezza non hanno più la necessità di essere strettamente legate alla tolopogia fisica della rete, ma ne vengono invece completamente affrancate (figura 6).

Anche nel firewalling come nel routing si può distinguere una protezione Est-Ovest, quella del traffico che rimane confinato all'interno del datacenter e su cui opera il firewall distribuito, e una protezione Nord-Sud, quella del traffico che fluisce da o verso l'esterno del datacenter attraverso l'uso di un Edge Service Gateway e/o di un router fisico (figura 7).

6. Alcuni sviluppi sul versante della scalabilità dell'infrastruttura.

Le ultime versione di VMware NSX, la 6.1 e la recente 6.2, hanno introdotto interessanti funzionalità di scalabilità. La versione 6.1 consente l'utilizzo del routing ECMP (Equal Cost Multi Path) con l'utilizzo fino a 8 Edge Gateway per il supporto di ampi flussi di traffico Nord-Sud, cioè da e verso l'esterno del datacenter. La versione 6.2 invece consente di gestire come un’unica unità ambienti costituiti da più vCenter. Più precisamente è possibile espandere l’ambito di lavoro di una VXLAN su host registrati in vCenter differenti.

7. Conclusioni.

Possiamo in estrema sintesi sottolineare due importanti punti di forza nel processo di virtualizzazione della rete attraverso l'uso del prodotto VMware NSX: