PREMESSA: Questo post riflette le idee dell'autore e non vuole essere in alcun modo un veicolo di propaganda di quanto esposto. Per la scrittura di questo post e per i successivi sull'argomento, né io personalmente né la società di cui faccio parte abbiamo ricevuto alcunché da Juniper Networks.
Il concetto di Overlay Virtual Network (OVN), benché non nuovo (ricordatevi sempre della RFC 1925, sez. 11), è la nuova tendenza nella realizzazione di Data Center, soprattutto di grandi dimensioni. I nuovi standard come VXLAN ed EVPN, trattati ampiamente in questo blog, costituiscono rispettivamente il braccio (= piano dati) e la mente (= piano di controllo) delle OVN.
Il concetto di Overlay Virtual Network (OVN), benché non nuovo (ricordatevi sempre della RFC 1925, sez. 11), è la nuova tendenza nella realizzazione di Data Center, soprattutto di grandi dimensioni. I nuovi standard come VXLAN ed EVPN, trattati ampiamente in questo blog, costituiscono rispettivamente il braccio (= piano dati) e la mente (= piano di controllo) delle OVN.
Tra le molte implementazioni commerciali, tre sono quelle che si contendono i favori del mercato (tanto che qualcuno scherzosamente le chiama la Santissima Trinità dell'OVN): WMware NSX, Cisco ACI e Juniper Contrail.
Dei tre, solo Juniper Contrail è Open Source, infatti ufficialmente oggi si chiama Juniper OpenContrail (da qui in poi abbreviato solo in OpenContrail). Ma vi posso garantire per esperienza di un nostro studente, al quale era stato dato l'ingrato compito di installarlo, che metterlo in produzione senza assistenza Juniper (ovviamente pagata !), non si va da nessuna parte. Il nostro studente ha fortunatamente trovato un'anima buona che gli ha dettato tutte le righe di codice da cambiare per renderlo un minimo operativo. Alla fine c'è riuscito, ma un conto è fare delle prove di laboratorio, un conto è mettere questo software in produzione.
In questo post inizierò a trattare proprio OpenContrail, per tre motivi:
- OpenContrail non ha l'ambizione di "reinventare la ruota", ma è basato su concetti classici ben noti, come L3VPN, L2VPN (via EVPN), VXLAN. Concetti che mi sono familiari e che quindi mi hanno facilitato la comprensione (e avendo una certa età, con i neuroni vacillanti, non è un aspetto secondario).
- E' Open Source, e quindi testabile sul campo, anche se come ho detto sopra l'installazione è tutt'altro che banale. Ne sanno qualcosa il nostro studente, che comunque è riuscito nell'impresa.
- Supporta la modalità di funzionamento L3-only, dove la segmentazione del traffico e l'instradamento avviene solo a Livello 3, senza ausilio e bisogno alcuno di indirizzi MAC. In realtà di indirizzo MAC ve ne è uno (oltre a quelli delle vNIC delle macchine virtuali), ma farlocco (c'è solo per motivi pratici, purtroppo tutti i Sistemi Operativi in commercio utilizzano ancora l'incapsulamento Ethernet...) ! In ogni caso, per chi non può fare a meno del Livello 2, OpenContrail supporta anche la modalità mista L2-L3.
A COSA SERVE
OpenContrail è un sistema SDN-based di Overlay Virtual Networking basato su software Open Source, applicabile a vari scenari, con due di questi che possono essere considerati i driver principali:
- Cloud Networking: Cloud privati per Enterprise e ISP, Infrastructure as a Service (IaaS) e Virtual Private Cloud (VPC) per Cloud Service Provider. Tutti questi scenari richiedono una segmentazione dei Clienti (tenant). Più tenant di un Data Center condividono le stesse risorse fisiche (server fisici, reti di storage, apparati della Fabric) e a ciascuno di questi viene assegnato un pool di risorse logiche (Virtual Machine (VM), Virtual Storage, Virtual Network). Queste risorse logiche sono isolate ciascuna dall’altra, a meno di esigenze particolari (es. extranet), che possono essere gestite attraverso opportune policy. Le Overlay Virtual Network (OVN) possono anche essere interconnesse a L3VPN e/o L2VPN classiche, realizzate su reti IP+MPLS di un ISP.
- Network Function Virtualization (NFV): fornisce la realizzazione, gestione e orchestrazione di funzioni di rete come Firewall, Intrusion Detection o Prevention System (IDS/IPS), Deep Packet Inspection (DPI), Content Caching, Wide Area Network (WAN) optimization, ecc. in VM, piuttosto che su (costose) macchine con hardware dedicato. Il driver principale è in questo caso la consistente riduzione di CAPEX e OPEX, e il ridotto time to market.
OpenContrail, piuttosto che "reinventare la ruota", si ispira al classico modello BGP/MPLS su cui si basano molti servizi di successo come L3VPN (unicast, multicast), L2VPN (VPWS, VPLS, EVPN), trasporto di IPv6 (6PE, 6VPE), ecc. . E questo ha molti vantaggi:
- È un modello maturo e altamente scalabile.
- È ampiamente utilizzato da molto anni in grandi reti in produzione, soprattutto nelle reti ISP, ma anche in grandi reti Enterprise.
- È supportato da tutti i maggiori vendor di apparati e questo consente l’interlavoro di piattaforme di vendor diversi, senza dover ricorrere a gateway vari.
Sul piano dati, OpenContrail supporta vari tipi (standard) di incapsulamento, tutti supportati dai maggiori vendor di apparati tradizionali:
Per maggiori informazioni su OpenContrail è possibile consultare il sito ufficiale, dove è disponibile tutta la documentazione aggiornata e il codice per l'implementazione: http://www.opencontrail.org/.
ARCHITETTURA GENERALE
OpenContrail è costituito da due componenti fondamentali:
- Un Controller SDN, logicamente centralizzato ma fisicamente distribuito, a sua volta costituito da quattro sub-componenti (nodi): Configuration, Control, DB e Analytics.
- Un insieme di virtual Router (vRouter) che svolgono il compito di (software) forwarding per il traffico L2/L3, implementati negli hypervisor di server (virtualizzati) general purpose (anche detti server COTS, Commercial Off-The-Shelf).
Il controller SDN fornisce alle applicazioni delle (northbound) REST API (REpresentational State Transfer Application Programming Interface). Queste REST API sono utilizzate per l’integrazione con il sistema di orchestrazione, ad esempio per l’integrazione con OpenStack (vedi ultima sezione di questo post). Come sistema di orchestrazione, OpenContrail supporta anche il meno noto CloudStack. Le REST API possono anche essere utilizzate da altre applicazioni e/o dai sistemi OSS/BSS dell’operatore del Data Center. Infine, le REST API sono utilizzate per implementare una web-based GUI inclusa in OpenContrail.
OpenContrail fornisce tre interfacce:
- Un insieme di interfacce northbound (REST API) utilizzate per il colloquio con il sistema di Orchestrazione e le Applicazioni.
- Un insieme di interfacce southbound utilizzate per il colloquio con i vRouter o con elementi fisici di rete (es. gateway router e switch). Per il colloquio con i vRouter viene utilizzato il protocollo XMPP (eXtensible Messaging and Presence Protocol) (*); questo protocollo, seppur sintatticamente diverso, è semanticamente molto simile al BGP. Il piano di controllo tra i nodi OpenContrail e i router tradizionali è basato sul BGP standard (e Netconf per il management). E questo, come noto, è lo stesso piano di controllo utilizzato per i servizi BGP/MPLS L3VPN e L2VPN.
- Una interfaccia east-west utilizzata per il peering con altri controller. Come protocollo, l’interfaccia east-west supporta il BGP standard.
(*) XMPP, precedentemente noto come Jabber, è un insieme di protocolli aperti di presenza e di messaggistica istantanea, basato su XML. Il software basato su XMPP è diffuso su migliaia di server disseminati su Internet; secondo la XMPP Standards Foundation (precedentemente nota come Jabber Software Foundation), già nel 2003 era usato da circa dieci milioni di persone in tutto il mondo. È stato standardizzato in IETF nelle RFC 6120 e RFC 6121. Per le applicazioni utilizzate in OpenContrail, il formato dei messaggi XMPP è quello definito nel draft IETF draft-ietf-l3vpn-end-system - BGP-signaled end-system IP/VPNs, scaduto però nell'Aprile 2016 e al momento su un binario apparentemente morto.
COMPONENTI
L’architettura OpenContrail consiste di vari nodi. Si noti che come nodo si intende semplicemente del software che gira su un processore general purpose della famiglia x86. Ciascuno di questi può girare sulla stessa macchina fisica o su macchine fisiche diverse, oppure sulla stessa VM o su VM diverse. La figura seguente riporta i diversi nodi previsti dall’architettura OpenContrail (ad eccezione di uno).
In particolare, il Controller SDN è composto da quattro tipi di nodi:
In particolare, il Controller SDN è composto da quattro tipi di nodi:
- Configuration node: accettano e convertono le richieste dell’orchestratore per la creazione delle VM, traducono le richieste e assegnano le VM alle reti virtuali. In sintesi, convertono un modello ad alto livello in uno di basso livello che consenta l’interazione con gli elementi di rete.
- Control node: implementano un Piano di Controllo logicamente centralizzato, responsabile di mantenere lo stato della rete e di ottimizzarne il funzionamento.
- Analytics node: hanno il compito di collezionare, memorizzare ed elaborare in real-time dati provenienti dagli elementi di rete, astraendoli e presentandoli in una forma conveniente per le applicazioni di management.
- DB node: hanno il compito di memorizzare i dati provenienti dagli elementi di rete, post-elaborati dagli Analytics Node.
- Compute node: sono server (virtualizzati) general purpose che ospitano le VM. Su queste VM possono girare le applicazioni dei tenant o possono essere ospitati dei servizi di rete (es. bilanciatori virtuali, firewall virtuali). Ciascun Compute node ha un virtual Router (vRouter), che implementa il piano di forwarding e la parte locale di un piano di controllo distribuito.
- Gateway node: sono router o switch tradizionali, che consentono di interconnettere la rete virtuale di un tenant con una rete esterna (es. Internet, un altro Data Center, una L3VPN, un server non virtualizzato, ecc.).
- Service node (non riportato nella figura): sono elementi fisici che forniscono servizi di rete (es. Deep Packet Inspection (DPI), Intrusion Detection System (IDS), Intrusion Prevention System (IPS), WAN optimizer, Load Balancer). Tutti questi servizi potrebbero anche essere ospitati in VM separate (NFV, Network Function Virtualization), e utilizzati secondo una certa sequenza (service chaining).
COMPUTE NODE E vROUTER
La figura seguente riporta la struttura interna di un Compute Node e la sua interazione con il Control Node e con OpenStack (o eventualmente altro orchestratore come CloudStack).
La configurazione standard assume che l’Host OS sia Linux, con KVM o Xen come Hypervisor. In futuro potrebbero essere supportati altri OS e Hypervisor come VMware ESXi e Windows Hyper-V.
Ciascun Compute Node contiene un vRouter, a sua volta diviso in due blocchi logici: vRouter Agent e vRouter Forwarding Plane.
vRouter Agent: è un processo utente che gira all’interno di Linux. Implementa un piano di controllo locale semplificato, ed è responsabile delle seguenti funzioni:
vRouter Forwarding Plane: è un modulo software che gira all’interno del kernel di Linux. Implementa un piano di dati locale, ed è responsabile delle seguenti funzioni:
La configurazione standard assume che l’Host OS sia Linux, con KVM o Xen come Hypervisor. In futuro potrebbero essere supportati altri OS e Hypervisor come VMware ESXi e Windows Hyper-V.
Ciascun Compute Node contiene un vRouter, a sua volta diviso in due blocchi logici: vRouter Agent e vRouter Forwarding Plane.
vRouter Agent: è un processo utente che gira all’interno di Linux. Implementa un piano di controllo locale semplificato, ed è responsabile delle seguenti funzioni:
- „„Scambia le informazioni di stato del piano di controllo con i Control Node, utilizzando Il protocollo XMPP.
- Riceve dai Control Node, sempre via XMPP, configurazioni di basso livello come Routing Instance (VRF) e Forwarding Policy.
- „„Riporta agli Analytics Node presenti nei Controller SDN, informazioni sullo stato della rete (es. log, statistiche sul traffico, eventi vari, ecc.).
- „„Installa le informazioni per il forwarding dei pacchetti/trame/flussi nel piano dati.
- Scopre, in collaborazione con il Nova Agent di OpenStack, l’esistenza delle VM e gli attributi associati (es. appartenenza a una Virtual Network).
- Applica le Forwarding Policy al primo pacchetto di ciascun nuovo flusso e installa un flow entry nella flow table associata alla OVN, presente nel piano dati.
- „Svolge funzioni di proxy per messaggi DHCP, ARP, DNS, mDNS (multicast DNS) e altro in futuro.
vRouter Forwarding Plane: è un modulo software che gira all’interno del kernel di Linux. Implementa un piano di dati locale, ed è responsabile delle seguenti funzioni:
- „„Incapsula i pacchetti/trame inviati alla OVN „„e decapsula i pacchetti/trame ricevuti dalla OVN.
- „„Assegna i pacchetti/trame a una Routing Instance: pacchetti/trame ricevuti dalla OVN vengono assegnati sulla base di una etichetta MPLS (nel caso di incapsulamento MPLS-over-GRE o MPLS-over-UDP) o di un VNI (nel caso di incapsulamento VXLAN). Le interfacce (virtuali) locali delle VM sono associate alle Routing Instance.
- Esegue un lookup sulla tabella FIB associata alla Routing Instance e spedisce il pacchetto alla destinazione corretta (BGP Next-Hop o VTEP destinazione). Il lookup può essere basato su un indirizzo IP o su un indirizzo MAC, in funzione della modalità di funzionamento (L3 o L2-L3).
- (Opzionale) Applica delle Forwarding Policy utilizzando una Flow Table per implementare funzionalità di Firewalling, Load Balancing, statistiche, ecc. :
INTEGRAZIONE CON OPENSTACK
La figura seguente mostra l’integrazione tra OpenStack e OpenContrail, in particolare tra i moduli Nova e Neutron di OpenStack, e OpenContrail (NOTA: chi di voi non fosse familiare con OpenStack, può saltare in prima istanza questa sezione. A OpenStack sarà dedicato un intero prossimo post).
Il modulo Nova di Openstack istruisce il Nova Agent presente nel Compute Node per la creazione delle VM. Il Nova Agent comunica con il Neutron plug-in di OpenContrail, per recuperare gli attributi di rete della nuova VM, in particolare l’appartenenza alla OVN e il piano di indirizzamento IPv4/IPv6 da utilizzare per le VM, Default Gateway e DNS.
Una volta creata la VM e definita l’associazione VM↔OVN, il Nova Agent informa il vRouter agent, che configura la rete virtuale per la nuova VM.
Per capire meglio il ruolo dei moduli Nova e Neutron di OpenStack, e la loro interazione con OpenContrail, illustrerò con un esempio come viene realizzata una OVN. Supporrò che la OVN da realizzare, che battezzerò come "SSGRR", sia costituita da tre VM, e che la OVN sia completamente isolata da altre OVN presenti nel Data Center.
PASSO 1: creazione della OVN SSGRR
Supponiamo di partire da zero. Un dettaglio importante è che non è possibile attivare una VM senza prima aver creato la OVN SSGRR. Ciò significa che prima deve essere definita la OVN e la sua topologia, ossia di quante VM è costituita la OVN e le regole di interconnessione. Si noti che la creazione di una OVN non implica alcunché sui vari server virtualizzati, ma la OVN deve essere in qualche modo definita nel Control Node di OpenContrail, poiché nel momento in cui si attiverà una VM della OVN, il Control Node deve essere in grado di comunicare all'Hypervisor a quale OVN appartiene la VM.
PASSO 2: attivazione della prima VM
Una volta creata la OVN, è possibile attivare la prima VM. Il primo passo è creare una VM e connetterla alla OVN via OpenStack. Fatto questo, il modulo Nova di OpenStack, utilizzando un algoritmo interno basato sul carico dei vari server, sceglie in quale server attivare la VM, tipicamente un server meno utilizzato degli altri. In alternativa, vi è la possibilità di scegliere manualmente in quale server attivare la VM.
PASSO 3: comunicazione al Control Node di OpenContrail della mappa VM<-->OVN
OpenStack a questo punto comunica al Control Node di OpenContrail, attraverso il Neutron Plug-in, l'associazione VM<-->OVN. Questo passaggio è necessario poiché non appena la VM verrà istanziata dall'Hypervisor, il vRouter di OpenContrail, utilizzando un messaggio XMPP, chiederà al Control Node sia a quale OVN appartiene la VM, che altre informazioni come l'indirizzo IP della VM, l'indirizzo MAC della vNIC, gli indirizzi di Default Gateway e DNS, ecc. :
PASSI 4-5: creazione della seconda VM
Ripetendo la procedura descritta nei passi 2 e 3, viene attivata la seconda VM. Terminata la procedura, la OVN SGGR sarà costituita da due VM, che però al momento non possono comunicare tra loro.
PASSO 6: scambio delle informazioni di routing
Una volta istanziate le VM, i vRouter provvedono a comunicare al Control Node, via XMPP, le informazioni di routing necessarie che consentono di raggiungere la VM. Il Control Node provvede quindi a passare queste informazioni agli altri vRouter dove sono istanziate VM della stessa OVN SSGRR. Alla fine di questo processo, le VM saranno in grado di comunicare tra loro. I dettagli di tutta la procedura saranno visti in dettaglio in un prossimo post.
PASSI 7-8-9: creazione della terza VM
Si ripetono i passi 2, 3 e 6, alla fine dei quali, le tre VM saranno in grado di comunicare tra loro.
Si noti che la comunicazione tra VM avviene utilizzando la rete underlay, ossia la IP Fabric, utilizzando una delle modalità di incapsulamento sopra illustrate (MPLSoGRE, MPLSoUDP, VXLAN).
Il modulo Nova di Openstack istruisce il Nova Agent presente nel Compute Node per la creazione delle VM. Il Nova Agent comunica con il Neutron plug-in di OpenContrail, per recuperare gli attributi di rete della nuova VM, in particolare l’appartenenza alla OVN e il piano di indirizzamento IPv4/IPv6 da utilizzare per le VM, Default Gateway e DNS.
Una volta creata la VM e definita l’associazione VM↔OVN, il Nova Agent informa il vRouter agent, che configura la rete virtuale per la nuova VM.
Per capire meglio il ruolo dei moduli Nova e Neutron di OpenStack, e la loro interazione con OpenContrail, illustrerò con un esempio come viene realizzata una OVN. Supporrò che la OVN da realizzare, che battezzerò come "SSGRR", sia costituita da tre VM, e che la OVN sia completamente isolata da altre OVN presenti nel Data Center.
PASSO 1: creazione della OVN SSGRR
Supponiamo di partire da zero. Un dettaglio importante è che non è possibile attivare una VM senza prima aver creato la OVN SSGRR. Ciò significa che prima deve essere definita la OVN e la sua topologia, ossia di quante VM è costituita la OVN e le regole di interconnessione. Si noti che la creazione di una OVN non implica alcunché sui vari server virtualizzati, ma la OVN deve essere in qualche modo definita nel Control Node di OpenContrail, poiché nel momento in cui si attiverà una VM della OVN, il Control Node deve essere in grado di comunicare all'Hypervisor a quale OVN appartiene la VM.
PASSO 2: attivazione della prima VM
Una volta creata la OVN, è possibile attivare la prima VM. Il primo passo è creare una VM e connetterla alla OVN via OpenStack. Fatto questo, il modulo Nova di OpenStack, utilizzando un algoritmo interno basato sul carico dei vari server, sceglie in quale server attivare la VM, tipicamente un server meno utilizzato degli altri. In alternativa, vi è la possibilità di scegliere manualmente in quale server attivare la VM.
PASSO 3: comunicazione al Control Node di OpenContrail della mappa VM<-->OVN
OpenStack a questo punto comunica al Control Node di OpenContrail, attraverso il Neutron Plug-in, l'associazione VM<-->OVN. Questo passaggio è necessario poiché non appena la VM verrà istanziata dall'Hypervisor, il vRouter di OpenContrail, utilizzando un messaggio XMPP, chiederà al Control Node sia a quale OVN appartiene la VM, che altre informazioni come l'indirizzo IP della VM, l'indirizzo MAC della vNIC, gli indirizzi di Default Gateway e DNS, ecc. :
PASSI 4-5: creazione della seconda VM
Ripetendo la procedura descritta nei passi 2 e 3, viene attivata la seconda VM. Terminata la procedura, la OVN SGGR sarà costituita da due VM, che però al momento non possono comunicare tra loro.
PASSO 6: scambio delle informazioni di routing
Una volta istanziate le VM, i vRouter provvedono a comunicare al Control Node, via XMPP, le informazioni di routing necessarie che consentono di raggiungere la VM. Il Control Node provvede quindi a passare queste informazioni agli altri vRouter dove sono istanziate VM della stessa OVN SSGRR. Alla fine di questo processo, le VM saranno in grado di comunicare tra loro. I dettagli di tutta la procedura saranno visti in dettaglio in un prossimo post.
PASSI 7-8-9: creazione della terza VM
Si ripetono i passi 2, 3 e 6, alla fine dei quali, le tre VM saranno in grado di comunicare tra loro.
Si noti che la comunicazione tra VM avviene utilizzando la rete underlay, ossia la IP Fabric, utilizzando una delle modalità di incapsulamento sopra illustrate (MPLSoGRE, MPLSoUDP, VXLAN).
E con questo termino questa descrizione generale di OpenContrail. In due prossimi post illustrerò due Case Study, che chiariranno altri dettagli.
CONCLUSIONI
OpenContrail è un software open source che sostanzialmente sposta le funzionalità complesse di creazione di una Virtual Network ancor più ai bordi della rete. A tutti gli effetti, la componente vRouter può essere vista come un virtual PE, mentre una VM può essere vista come un CE. Il concetto di fondo su cui si basa OpenContrail è 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 (vRouter) intelligente + Core (Fabric) stupido), vedi la RFC 3439 - Some Internet Architectural Guidelines and Philosophy, Dicembre 2002 (NOTA: per chi non la conoscesse, ne consiglio vivamente la lettura, è uno dei MUST per ogni networker che si rispetti). La parte del controller è abbastanza nuova, ma non concettualmente, in fondo svolge tutte funzioni già ben note. Dedicherò a OpenContrail almeno altri due post, in realtà due Case Study, il primo riguardante la modalità L3-only, il secondo la modalità ibrida L2-L3. Infine un inciso personale, benché abbia forti dubbi sulle capacità di marketing di Juniper di spingere un simile prodotto, che a me personalmente piace molto, c'è da dire che OpenContrail è già in produzione presso alcuni dei maggiori ISP Europei.
Ciao Ammiraglio sei un grande , ottimo articolo
RispondiElimina