PREMESSA: il 28-29 Settembre, come già annunciato nel post precedente pubblicato prima delle vacanze, io e il mio co-blogger Lorenzo Salvatore, terremo un seminario su Overlay Virtual networking nei Data Center. Il programma e un campione della documentazione sono disponibili nel post citato sopra. In questo post tratterò una parte, che poi sarà approfondita durante il seminario.
L’idea dell’Overlay Virtual Networking non è assolutamente nuova, ed è già nota da molti anni a chi si occupa di reti. Un esempio su tutti le L3VPN basate sul paradigma BGP/MPLS: queste sono delle Overlay Virtual Network (OVN) costruite sopra una rete underlay di tipo IP+MPLS. La novità degli ultimi anni è stata quella di applicare il concetto allo scenario dei Data Center, per evitare tutti i problemi legati all’utilizzo di tecnologie di Livello 2, che soffrono di vari problemi (es. scarsa scalabilità, broadcast storm, utilizzo non ottimale della banda disponibile, ecc.).
Il concetto di fondo su cui si basa il nuovo paradigma è anche questo ben noto: disaccoppiare il servizio dal trasporto. Oppure, se volete, utilizzare il ben noto paradigma su cui si basa tutta l’Internet: Smart Edge + Dumb Core (= Edge intelligente + Core stupido). A tal proposito, questo è quanto recita testualmente la RFC 3439 - Some Internet Architectural Guidelines and Philosophy, Dicembre 2002 (NOTA: per chi non la conoscesse, ne consigliamo vivamente la lettura, è uno dei must per ogni networker che si rispetti):
In short, the complexity of the Internet belongs at the edges, and the IP layer of the Internet should remain as simple as possible.
Ciò premesso, l’idea di fondo delle OVN è molto semplice: incapsulare le trame Ethernet generate dagli Host, in pacchetti IP (MAC-in-IP) e trasportare i pacchetti IP tramite una classica, semplice rete IP (la rete underlay, ossia una classica IP Fabric di quelle viste in alcuni post precedenti, vedi ad esempio questo !). In pratica, una OVN può essere vista come una nuova applicazione su una rete IP, analoga alle tante arci-note come HTTP, SMTP, DNS, Telnet, ecc. .
I vantaggi che ne derivano sono molteplici, tra cui i più importanti sono:
Un ruolo chiave nel funzionamento delle OVN è giocato dalle interfacce NVE (Network Virtualization Endpoint). Queste sono delle interfacce (logiche, non fisiche) tra il mondo virtuale (la OVN) e il mondo fisico (la rete underlay), che hanno fondamentalmente due compiti:
Dove sono collocate le interfacce NVE è una pura scelta progettuale. Vi sono due possibilità. La prima è che a svolgere il ruolo di interfaccia NVE sia una funzione (software) presente nell’Hypervisor, la seconda che a svolgere il ruolo di interfaccia NVE sia una funzione (hardware) presente negli switch fisici (tipicamente switch ToR, Top of Rack). Il mercato oggi mette a disposizione entrambe le soluzioni, anche se per la verità, la prima sarebbe preferibile poiché più vicina al paradigma smart edge + dumb core, tipico del mondo Internet. Nel seguito del post ipotizzerò che la funzione NVE sia integrata nell'Hypervisor.
Naturalmente, non è che il passaggio alle OVN ci consente di raggiungere il Nirvana, queste hanno bisogno di un aspetto chiave: un piano di controllo. L’esigenza di un piano di controllo si capirà presto. Prima però è necessario vedere un po’ meglio come funziona il trasporto MAC-in-IP.
NOTA: è interessante pensare alle OVN con una analogia: Skype. In fondo Skype è basato sullo stesso principio: spostare la complessità all’edge (i telefoni VoIP) e utilizzare un trasporto semplice e a buon mercato (l’Internet !).
TUNNELING (IP) DELLE TRAME ETHERNET (MAC-IN-IP)
Nelle OVN, le trame Ethernet generate dalle VM o BM, vengono incapsulate in pacchetti IP e quindi trasportate verso l’Hypervisor o macchina fisica di destinazione attraverso una banale semplice rete IP (la rete underlay). In pratica è un classico incapsulamento di un payload (la trama Ethernet) in un tunnel IP (*).
L’idea dell’Overlay Virtual Networking non è assolutamente nuova, ed è già nota da molti anni a chi si occupa di reti. Un esempio su tutti le L3VPN basate sul paradigma BGP/MPLS: queste sono delle Overlay Virtual Network (OVN) costruite sopra una rete underlay di tipo IP+MPLS. La novità degli ultimi anni è stata quella di applicare il concetto allo scenario dei Data Center, per evitare tutti i problemi legati all’utilizzo di tecnologie di Livello 2, che soffrono di vari problemi (es. scarsa scalabilità, broadcast storm, utilizzo non ottimale della banda disponibile, ecc.).
Il concetto di fondo su cui si basa il nuovo paradigma è anche questo ben noto: disaccoppiare il servizio dal trasporto. Oppure, se volete, utilizzare il ben noto paradigma su cui si basa tutta l’Internet: Smart Edge + Dumb Core (= Edge intelligente + Core stupido). A tal proposito, questo è quanto recita testualmente la RFC 3439 - Some Internet Architectural Guidelines and Philosophy, Dicembre 2002 (NOTA: per chi non la conoscesse, ne consigliamo vivamente la lettura, è uno dei must per ogni networker che si rispetti):
In short, the complexity of the Internet belongs at the edges, and the IP layer of the Internet should remain as simple as possible.
Ciò premesso, l’idea di fondo delle OVN è molto semplice: incapsulare le trame Ethernet generate dagli Host, in pacchetti IP (MAC-in-IP) e trasportare i pacchetti IP tramite una classica, semplice rete IP (la rete underlay, ossia una classica IP Fabric di quelle viste in alcuni post precedenti, vedi ad esempio questo !). In pratica, una OVN può essere vista come una nuova applicazione su una rete IP, analoga alle tante arci-note come HTTP, SMTP, DNS, Telnet, ecc. .
I vantaggi che ne derivano sono molteplici, tra cui i più importanti sono:
- La rete underlay è una rete IP (potrebbe anche essere una rete IP+MPLS !), quindi è possibile riutilizzare tutto il piano di controllo IP, ben noto e collaudato.
- Grazie all’utilizzo dei classici protocolli di routing IP, niente più spreco di banda, possibilità di percorsi end-to-end ottimi, ECMP (Equal Cost Load Balancing) nativo, forwarding loop ridotti al minimo, niente broadcast storm, ecc. .
- L’incapsulamento può prevedere un equivalente del VLAN tag di ampiezza maggiore.
Un ruolo chiave nel funzionamento delle OVN è giocato dalle interfacce NVE (Network Virtualization Endpoint). Queste sono delle interfacce (logiche, non fisiche) tra il mondo virtuale (la OVN) e il mondo fisico (la rete underlay), che hanno fondamentalmente due compiti:
- Incapsulare/decapsulare in pacchetti IP le trame Ethernet generate dalle VM.
- Multiplexing/demultiplexing di più OVN sulla medesima rete underlay.
Dove sono collocate le interfacce NVE è una pura scelta progettuale. Vi sono due possibilità. La prima è che a svolgere il ruolo di interfaccia NVE sia una funzione (software) presente nell’Hypervisor, la seconda che a svolgere il ruolo di interfaccia NVE sia una funzione (hardware) presente negli switch fisici (tipicamente switch ToR, Top of Rack). Il mercato oggi mette a disposizione entrambe le soluzioni, anche se per la verità, la prima sarebbe preferibile poiché più vicina al paradigma smart edge + dumb core, tipico del mondo Internet. Nel seguito del post ipotizzerò che la funzione NVE sia integrata nell'Hypervisor.
Naturalmente, non è che il passaggio alle OVN ci consente di raggiungere il Nirvana, queste hanno bisogno di un aspetto chiave: un piano di controllo. L’esigenza di un piano di controllo si capirà presto. Prima però è necessario vedere un po’ meglio come funziona il trasporto MAC-in-IP.
NOTA: è interessante pensare alle OVN con una analogia: Skype. In fondo Skype è basato sullo stesso principio: spostare la complessità all’edge (i telefoni VoIP) e utilizzare un trasporto semplice e a buon mercato (l’Internet !).
TUNNELING (IP) DELLE TRAME ETHERNET (MAC-IN-IP)
Nelle OVN, le trame Ethernet generate dalle VM o BM, vengono incapsulate in pacchetti IP e quindi trasportate verso l’Hypervisor o macchina fisica di destinazione attraverso una banale semplice rete IP (la rete underlay). In pratica è un classico incapsulamento di un payload (la trama Ethernet) in un tunnel IP (*).
Al di la della tipologia di tunnel IP utilizzato, due sono i punti fermi:
- Gli indirizzi IP end-point del tunnel IP sono gli indirizzi dei server dove risiedono gli Hypervisor ai due estremi.
- Oltre all’intestazione IP aggiuntiva, il tunnel IP deve contenere l’informazione che consente di delimitare la OVN, ossia un campo equivalente al VLAN tag, che consenta all’Hypervisor destinazione di conoscere a quale OVN appartiene la trama Ethernet.
Il campo che consente di delimitare la OVN dovrebbe essere sufficientemente grande da essere utilizzato in un ambiente dove i tenant (i Clienti) sono centinaia di migliaia, se non addirittura qualche milione.
Un aspetto chiave da affrontare è quello della scalabilità. Quando si ha che fare con dei tunnel, la prima preoccupazione che si ha è quella dell’elevato numero di tunnel necessari. Ad esempio, supponiamo di avere un Hypervisor con 50 VM, ciascuna appartenente a una diversa OVN, e che un Data Center abbia le 50 OVN ciascuna costituita da 50 VM, distribuite su 50 Hypervisor diversi. Il numero totale di tunnel IP necessari è quindi 50x50 = 2.500. In realtà però non è necessario configurare manualmente tutti questi tunnel (ossia, nell’esempio, 50 tunnel per Hypervisor). È sufficiente utilizzare un meccanismo simile ai tunnel mGRE (multipoint GRE), dove l’indirizzo IP sorgente del tunnel viene definito manualmente (e coincide con l’indirizzo IP della NIC del server dove risiede l’Hypervisor), mentre l’indirizzo IP destinazione viene determinato automaticamente dall’Hypervisor sulla base di una mappa MAC-to-NVE. Il punto chiave è la determinazione di questa mappa, ma questo è un aspetto che riguarda il piano di controllo.
(*) In realtà, una volta definito il tipo di tunnel, non è necessario trasportare all’interno di questo l’intera trama Ethernet, ma sarebbe sufficiente il trasporto diretto dei pacchetti IP. In altre parole, costruire un Data Center puramente Layer-3. Soluzioni del genere sono oggi disponibili (vedi ad esempio la modalità L3-only di Juniper OpenContrail), ma quasi tutti preferiscono ancora trasportare direttamente le trame Ethernet.
LA (STUPIDA) GUERRA DEGLI INCAPSULAMENTI
Come sovente accade, sono stati proposti più tipi di incapsulamento per i tunnel IP utilizzati nelle OVN. In realtà è una guerra stupida perché come avremo modo di dire, ciò che conta è il piano di controllo e non l’incapsulamento in se.
I vari tipi di incapsulamento differiscono per il tipo di protocollo di trasporto utilizzato e per la struttura dei campi che contengono l’identificativo della OVN (analogo del VLAN tag).
Sono 4 i tipi di incapsulamento che si contendono i favori dei vari attori del mercato:
- Virtual eXtensible LAN (VXLAN)
- Network Virtualization using GRE (NVGRE)
- GEneric NEtwork Virtualization Encapsulation (GENEVE)
- Stateless Transport Tunneling (STT)
Tra questi, quello che sta emergendo e che sta godendo di un consenso abbastanza unanime è l’incapsulamento VXLAN, che ho trattato diffusamente in vari post precedenti. Degli altri darò solo una breve descrizione.
INCAPSULAMENTO NVGRE
L’incapsulamento NVGRE utilizza un classico Tunnel GRE, con l’header GRE che assume il seguente formato:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| |1|0| Reserved0 | Ver | Protocol Type 0x6558 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Subnet ID (VSID) | FlowID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I bit 0, 2 e 3 indicano rispettivamente assenza di Checksum, presenza del campo Key e assenza di Sequence Number. Il campo più importante, contenuto nel campo Key dell’header GRE è il VSID (24 bit), che è utilizzato per identificare la OVN. Con 24 bit è possibile creare fino a 16.777.216 OVN, un numero enormemente più grande delle 4.096 (teoriche) consentite dai 12 bit del VLAN tag classico, e sicuramente sufficiente anche per le applicazioni cloud più complesse. Infine, il campo FlowID (8 bit) non ha un significato particolare, viene solo utilizzato per aumentare l’entropia dei flussi e quindi distribuirli meglio sulla rete underlay (in altre parole, consente un Load Balancing più efficiente).
INCAPSULAMENTO GENEVE
GENEVE è un tipo di incapsulamento introdotto di recente, il cui processo di standardizzazione IETF è ancora allo stato draft (draft-ietf-nvo3-geneve). È stato proposto da VMware e Intel e successivamente sponsorizzato anche da Microsoft e Red Hat. L’incapsulamento complessivo è molto simile a VXLAN. Entrambi utilizzano UDP come protocollo di trasporto. GENEVE utilizza la porta well-known 6081.
L’incapsulamento GENEVE ha il seguente formato (di lunghezza variabile):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| Opt Len |O|C| Rsvd. | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Anche qui, il campo più importante è il VNI (24 bit), che è utilizzato per identificare la OVN. Il campo Protocol Type indica il tipo di payload trasportato (che non necessariamente deve essere una trama Ethernet); i valori utilizzati sono i classici valori di EtherType utilizzati nelle trame Ethernet. Le trame Ethernet stesse sono identificate da un Protocol Type = 0x6558. Infine, è possibile aggiungere varie opzioni, al momento non specificate. Questo è un aspetto molto importante di GENEVE: la presenza di queste opzioni, identificate da un valore di Option Class registrato da IANA, fa si che venga incoraggiata l’innovazione; chiunque abbia opzioni interessanti, propone a IANA la registrazione delle relative Option Class e può renderle disponibili a chiunque.
INCAPSULAMENTO STT
L’ultimo (non in ordine di tempo) incapsulamento proposto è STT. STT è l’unico tipo di incapsulamento che utilizza una intestazione TCP-like (N.B. STT non utilizza TCP come protocollo di trasporto, ossia non è previsto nessun three-way-handshake, da qui lo stateless nel nome).
Questo ha una implicazione importante, consente di utilizzare il TCP Segmentation Offload (TSO), ossia la possibilità di delegare all’hardware della NIC, alcune funzioni computazionalmente complesse del TCP, tipicamente la segmentazione e riassemblaggio dei segmenti TCP (le eventuali ritrasmissioni sono comunque delegate al software). Il guadagno di prestazione che se ne ottiene è notevole, e può essere verificato facilmente simulando del traffico TCP con e senza la funzionalità TSO abilitata. L’incapsulamento STT è riconoscibile dalla porta TCP well-known 7471.
Per il formato dell’incapsulamento rimandiamo al draft IETF draft-davie-stt. Un aspetto che differenzia STT dagli altri tipi di incapsulamento citati è che il campo utilizzato per identificare la OVN (denominato Context ID nel draft IETF), è di ben 64 bit.
MA IL VERO PROBLEMA NON È IL TIPO DI INCAPSULAMENTO ...
Il vero problema delle OVN non è certamente il tipo di incapsulamento. Infatti, come detto sopra, a parte la differente struttura dei vari metodi proposti, concettualmente i vari tipi sono simili, tutti sono caratterizzati dagli indirizzi IP dei NVE e da un identificativo che consente di distinguere le varie OVN (VSID, VNI, Context ID).
Ad essere un po’ cinici, ogni vendor che ha proposto un tipo di incapsulamento ha cercato di tirare l’acqua al proprio mulino. Cisco ad esempio, che è stato lo sponsor principale di VXLAN, aveva già l’hardware pronto (l’header VXLAN è molto simile agli header OTV e LISP). Nicira, il principale (e unico al momento, ma attenzione che Nicira è stata assorbita da VMware) sponsor di STT ha focalizzato l’attenzione su ciò che loro ritengono essere il pezzo più pregiato del puzzle: le prestazioni dei server dove vengono create le VM.
L’aspetto chiave delle OVN è la determinazione delle mappe MAC-to-NVE. In altre parole, quando la funzione NVE in un vSwitch di un Hypervisor (o in uno switch fisico) riceve una trama Ethernet destinata ad un certo indirizzo MAC, dovrà avere l’informazione su quale NVE remota è localizzato l’Host (VM o server BM) a cui è indirizzata la trama.
Per determinare la mappa MAC-to-NVE è necessario un qualche meccanismo (piano di controllo) che consenta a ciascuna funzione NVE di apprendere dove sono localizzati gli Host. Quale che sia il tipo di incapsulamento utilizzato e la strategia utilizzata per la determinazione delle mappe MAC-to-NVE, un aspetto «classico» rimane sempre ed è sempre lo stesso: il MAC learning locale sul piano dati. Ad esempio, quando una VM deve comunicare con un’altra VM, supponiamo (ma non è indispensabile) della stessa OVN, invia un messaggio ARP request, che viene intercettato dallo vSwitch presente nell’Hypervisor, il quale al pari di un classico switch Ethernet, costruisce l’associazione <MAC; porta>. Identico discorso vale se invece di uno vSwitch, l’Hypervisor è di tipo legacy e quindi non ha uno vSwitch, ma è direttamente connesso a uno switch fisico.
CONCLUSIONI
Per riprendermi dalla pausa estiva e "ritornare sul pezzo" ho scelto un argomento leggero, ma di grande attualità. In questo blog ho trattato vari aspetti del protocollo VXLAN, che è quello che tra i vari tipi di incapsulamento proposti per le OVN, sta godendo del maggiore favore. In questo post ho invece illustrato alcune soluzioni alternative.
Vi è anche da dire che alcune soluzioni OVN, come ad esempio Juniper OpenContrail, consentono anche altri tipi di incapsulamento, basati su MPLS, come ad esempio MPLS-over-GRE (RFC 4023) e MPLS-over-UDP (RFC 7510), ma come detto nell'ultima sezione, il tipo di incapsulamento non è poi così importante, l'aspetto importante è il piano di controllo.
Per chi fosse interessato ad approfondire l'argomento delle Overlay Virtual Network, può partecipare al nostro seminario del 28-29 Settembre a Roma.
CONCLUSIONI
Per riprendermi dalla pausa estiva e "ritornare sul pezzo" ho scelto un argomento leggero, ma di grande attualità. In questo blog ho trattato vari aspetti del protocollo VXLAN, che è quello che tra i vari tipi di incapsulamento proposti per le OVN, sta godendo del maggiore favore. In questo post ho invece illustrato alcune soluzioni alternative.
Vi è anche da dire che alcune soluzioni OVN, come ad esempio Juniper OpenContrail, consentono anche altri tipi di incapsulamento, basati su MPLS, come ad esempio MPLS-over-GRE (RFC 4023) e MPLS-over-UDP (RFC 7510), ma come detto nell'ultima sezione, il tipo di incapsulamento non è poi così importante, l'aspetto importante è il piano di controllo.
Per chi fosse interessato ad approfondire l'argomento delle Overlay Virtual Network, può partecipare al nostro seminario del 28-29 Settembre a Roma.
Nessun commento:
Posta un commento