In versione precedente Ho descritto un framework per l'automazione della rete. Dai feedback di alcune persone, anche questo primo approccio al problema ha già chiarito alcune questioni. E questo mi rende molto felice, perché il nostro obiettivo nel ciclo non è coprire Ansible con script Python, ma costruire un sistema.

Questo stesso framework stabilisce l'ordine in cui ci occuperemo della questione.
E la virtualizzazione della rete, di cui questo episodio parla, non si adatta particolarmente al tema ADSM, dove trattiamo l'automazione.

Ma diamo un'occhiata a essa da un'altra prospettiva.

Da tempo molti servizi utilizzano una rete. Nel caso di un operatore di telecomunicazioni, si tratta di 2G, 3G, LTE, banda larga e B2B, per esempio. Nel caso del data center: connettività per diversi clienti, Internet, storage a blocchi, storage oggettuale.

E tutti i servizi richiedono isolamento reciproco. Così sono nate le reti overlay.

E tutti i servizi non vogliono aspettare che qualcuno li configuri manualmente. Così sono nati gli orchestratori e SDN.

Un primo approccio all'automazione sistematica della rete, o meglio, di una sua parte, è stato intrapreso tempo fa ed è stato implementato in molte situazioni: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

E oggi ci concentreremo proprio su di esso.

Contenuto

• Motivi
• Terminologia
• Underlay — rete fisica
• Overlay — rete virtuale
  • Overlay da ToR
  • Overlay da host
  • Per esempio Tungsten Fabric
    • Comunicazione all'interno di una stessa macchina fisica
    • Comunicazione tra VM dislocate su macchine fisiche diverse
    • Uscita verso il mondo esterno

• FAQ
• Conclusione
• Link utili

Motivi

E visto che ne stiamo parlando, è opportuno menzionare le premesse per la virtualizzazione della rete. In realtà, questo processo non è iniziato ieri.

Probabilmente avrete sentito più volte che la rete è sempre stata la parte più inerte di qualsiasi sistema. E questo è vero in tutti i sensi. La rete è la base su cui si poggia tutto, e apportare modifiche ad essa è piuttosto difficile: i servizi non tollerano quando la rete è inattiva. Spesso, dismettere un nodo può influenzare una grande parte delle applicazioni e colpire molti clienti. In parte per questo, il team di rete potrebbe opporsi a qualsiasi modifica, perché adesso funziona in un certo modo (potremmo anche non sapere come), e ora c'è da settare qualcosa di nuovo, e non si sa come influenzerà la rete.

Per non aspettare che i fornitori di rete creino il VLAN e non dover configurare ogni servizio su ciascun nodo della rete, le persone hanno inventato l'uso di overlay — reti sovrapposte — di cui esiste una grande varietà: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, ecc.

La loro attrattiva risiede in due semplici aspetti:

• Si configurano solo i nodi finali — non è necessario toccare i nodi di transito. Questo accelera notevolmente il processo e, talvolta, consente addirittura di escludere il reparto infrastruttura di rete dal processo di introduzione di nuovi servizi.
• Il carico è nascosto in profondità all'interno delle intestazioni — i nodi di transito non devono sapere nulla su di esso, sull'indirizzamento degli host, sui percorsi della rete sovrapposta. Ciò significa che è necessario memorizzare meno informazioni nelle tabelle, il che consente di utilizzare dispositivi più semplici/meno costosi.

In questa edizione non del tutto completa, non intendo analizzare tutte le tecnologie possibili, ma piuttosto descrivere il framework di funzionamento delle reti overlay nel data center.

L'intera serie descriverà un data center composto da file di rack identici, all'interno dei quali è installato lo stesso hardware server.

Su questo hardware vengono eseguite macchine virtuali/container/serverless che implementano i servizi.

Terminologia

Nel ciclo server chiamerò il programma che implementa il lato server della comunicazione client-server.

Le macchine fisiche nei rack verranno chiamate server non .

La macchina fisica è un computer x86 installato in un rack. Il termine più comunemente usato è host. La chiameremo quindi «macchina» o host.

Ipervisore è un'applicazione eseguita su una macchina fisica che emula le risorse fisiche su cui vengono eseguite le Macchine Virtuali. A volte nella letteratura e in rete il termine «ipervisore» viene usato come sinonimo di «host».

Macchina virtuale è un sistema operativo eseguito su una macchina fisica sopra l'ipervisore. Per noi, nel contesto di questo ciclo, non è così importante che si tratti realmente di una macchina virtuale o semplicemente di un container. La chiameremo «VM«

Tenant è un concetto ampio che io definirò in questo articolo come un servizio separato o un cliente separato.

Multitenancy o multi-tenant è l'utilizzo della stessa applicazione da parte di diversi clienti/servizi. In questo caso, l'isolamento dei clienti l'uno dall'altro è ottenuto grazie all'architettura dell'applicazione e non a istanze separate eseguite.

ToR — Top of the Rack switch — switch montato in rack al quale sono collegate tutte le macchine fisiche.

Oltre alla topologia ToR, diversi fornitori praticano EoR (End of Row) o MoR (Middle of Row), anche se quest'ultima è una rarità poco considerata.

Rete Underlay o rete sottostante — infrastruttura fisica della rete: switch, router, cavi.

Rete Overlay o rete sovrapposta — rete virtuale di tunnel che funziona sopra quella fisica.

L3-fabbrica o fabbrica IP — una straordinaria invenzione dell'umanità che consente di non ripetere STP e di non studiare TRILL durante le interviste. Una concezione in cui tutta la rete fino al livello di accesso è esclusivamente L3, senza VLAN e quindi con enormi domini di broadcast allungati. Spiegheremo il termine "fabbrica" nella parte successiva.

SDN — Software Defined Network. Difatti non ha bisogno di presentazioni. Un approccio alla gestione della rete in cui le modifiche vengono effettuate non da una persona, ma da un programma. Di solito significa spostare il Control Plane al di fuori degli apparati di rete finali verso un controller.

NFV — Network Function Virtualization — virtualizzazione degli apparati di rete, che prevede che alcune funzioni di rete possano essere eseguite come macchine virtuali o contenitori per accelerare l'implementazione di nuovi servizi, gestire il Service Chaining e semplificare la scalabilità orizzontale.

VNF — Funzione di Rete Virtuale. Un dispositivo virtuale specifico: router, switch, firewall, NAT, IPS/IDS, ecc.

Attualmente sto deliberatamente semplificando la descrizione a una realizzazione specifica per non confondere eccessivamente il lettore. Per una lettura più approfondita rimando alla sezione Link. Inoltre, Roma Gorge, che criticherà questo articolo per le imprecisioni, promette di scrivere un capitolo separato sulle tecnologie di virtualizzazione dei server e delle reti, più approfondito e attento ai dettagli.

La maggior parte delle reti oggi può essere chiaramente suddivisa in due parti:

Underlay — rete fisica con configurazione stabile.
Overlay — astrazione sopra l'Underlay per l'isolamento dei tenant.

Questo è vero sia per il caso del DC (Data Center) che analizzeremo in questo articolo, sia per gli ISP (che non discuteremo poiché già trattati in SDN). Con le reti enterprise, ovviamente, la situazione è un po' diversa.

Immagine con focus sulla rete:

Underlay

L'Underlay è una rete fisica: switch hardware e cavi. I dispositivi nell'underlay sanno come raggiungere le macchine fisiche.

Si basa su protocolli e tecnologie standard. Non da ultimo perché i dispositivi hardware funzionano ancora con software proprietario, che non consente né la programmazione del chip né l'implementazione dei propri protocolli, pertanto è necessaria la compatibilità con altri fornitori e la standardizzazione.

Ma qualcuno come Google può permettersi di sviluppare i propri switch e rinunciare ai protocolli comunemente accettati. Ma il LAN_DC non è Google.

L'Underlay cambia relativamente raramente, poiché il suo compito è fornire connettività IP di base tra le macchine fisiche. L'underlay non sa nulla dei servizi, clienti o tenant avviati sopra di esso: deve solo consegnare i pacchetti da una macchina all'altra.
L'Underlay può essere ad esempio così:

• IPv4+OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILL
• L2+STP

La rete Underlay è configurata nel modo tradizionale: CLI/GUIM/NETCONF.

Manualmente, tramite script, strumenti proprietari.

Un articolo del ciclo successivo sarà dedicato all'underlay in modo più dettagliato.

Overlay

L'Overlay è una rete virtuale di tunnel, tirata sopra l'Underlay, che consente alle VM di un cliente di comunicare tra loro, garantendo al contempo isolamento dagli altri clienti.

I dati del cliente vengono incapsulati in intestazioni di tunneling per la trasmissione attraverso la rete comune.

In questo modo, le VM di un cliente (di un servizio) possono comunicare tra loro attraverso l'Overlay, senza nemmeno sospettare quale sia effettivamente il percorso del pacchetto.

L'Overlay può essere ad esempio così, come ho già accennato sopra:

• Tunnel GRE
• VXLAN
• EVPN
• L3VPN
• GENEVE

La rete Overlay è solitamente configurata e gestita attraverso un controller centrale. Da questo, la configurazione, il Control Plane e il Data Plane vengono inviati ai dispositivi che si occupano del routing e dell'incapsulamento del traffico cliente. Un po' di seguito approfondiremo questo con esempi.

Sì, questo è SDN nella sua forma più pura.

Ci sono due approcci fondamentalmente diversi per l'organizzazione di una rete Overlay:

1. Overlay da ToR
2. Overlay da host

Overlay da ToR

L'Overlay può iniziare su uno switch di accesso (ToR), situato nell'armadio, come accade, ad esempio, nel caso di una fabbrica VXLAN.

Questo è un meccanismo collaudato nelle reti ISP e tutti i fornitori di apparecchiature di rete lo supportano.

Tuttavia, in questo caso, lo switch ToR deve essere in grado di separare i diversi servizi, di conseguenza, l'amministratore di rete deve collaborare in certa misura con gli amministratori delle macchine virtuali e apportare modifiche (anche se automaticamente) alla configurazione dei dispositivi.

Qui rimando il lettore all'articolo su VxLAN su Habr del nostro vecchio amico @bormoglotx.
In questo presentazione con ENOG dove vengono descritte dettagliatamente le tecniche per costruire una rete DC con un fabric EVPN VXLAN.

E per un'immersione più completa nella realtà, si può leggere il libro di Cisco A Modern, Open, and Scalable Fabric: VXLAN EVPN.

Osservo che VXLAN è solo un metodo di incapsulamento e la terminazione dei tunnel può avvenire non sul ToR, ma sull'host, come nel caso di OpenStack, ad esempio.

Tuttavia, un fabric VXLAN dove l'overlay inizia sul ToR è uno dei design consolidati delle reti overlay.

Overlay da host

Un altro approccio è iniziare e terminare i tunnel sugli host finali.
In questo caso, la rete (Underlay) rimane il più semplice e statica possibile.
E l'host stesso si occupa di tutte le necessarie incapsulazioni.

Per fare ciò, sarà senza dubbio necessario eseguire un'applicazione speciale sugli host, ma ne vale la pena.

Innanzitutto, avviare un client su una macchina Linux è più semplice o, diciamo, - del tutto possibile - mentre sullo switch, probabilmente, si dovrà comunque fare riferimento a soluzioni SDN proprietarie, il che uccide l'idea di multivendor.

In secondo luogo, lo switch ToR in questo caso può rimanere il più semplice possibile, sia dal punto di vista del Control Plane che del Data Plane. Infatti, con un controller SDN non deve comunicare e non è necessario mantenere le reti/ARP di tutti i client connessi - è sufficiente conoscere l'indirizzo IP della macchina fisica, il che semplifica notevolmente le tabelle di switching/routing.

Nella serie ADSM, scelgo l'approccio dell'overlay dall'host - da ora in avanti parleremo solo di questo e non torneremo più al fabric VXLAN.

La cosa più semplice è considerare degli esempi. E come caso di studio, prenderemo la piattaforma SDN OpenSource OpenContrail, ora conosciuta come Tungsten Fabric.

Alla fine dell'articolo, presenterò alcune riflessioni sull'analogia con OpenFlow e OpenvSwitch.

Per esempio Tungsten Fabric

Su ogni macchina fisica c'è vRouter — un router virtuale, che conosce le reti a cui è connesso e a quali clienti appartengono — in sostanza — un router PE. Per ogni cliente supporta una tabella di routing isolata (leggi VRF). E in realtà il vRouter esegue il tunneling di tipo Overlay.

Un po' più dettagli sul vRouter — alla fine dell'articolo.

Ogni VM, situata su un hypervisor, si connette al vRouter di questa macchina attraverso un'interfaccia TAP.

TAP — Terminal Access Point — un'interfaccia virtuale nel kernel Linux che permette l'interazione di rete.

Se ci sono più reti dietro il vRouter, viene creata un'interfaccia virtuale per ciascuna di esse, a cui viene assegnato un indirizzo IP — questo sarà l'indirizzo del gateway predefinito.
Tutte le reti di un cliente vengono collocate in un VRF (una tabella), quelle di clienti diversi — in tabelle separate.
Faccio qui una precisazione, che non è tutto così semplice, e rimando il lettore curioso alla fine dell'articolo..

Affinché i vRouter possano comunicare tra loro, e quindi anche le VM che si trovano dietro di essi, scambiano informazioni di routing attraverso un controller SDN..

Per uscire nel mondo esterno, esiste un punto di uscita dalla matrice — il gateway della rete virtuale VNGW — Virtual Network GateWay (il mio termine).

Ora consideriamo esempi di comunicazione — e sarà tutto chiaro.

Comunicazione all'interno di una stessa macchina fisica

La VM0 vuole inviare un pacchetto a VM2. Supponiamo per ora che queste siano VM dello stesso cliente.

Data Plane

1. La VM-0 ha una route predefinita sulla sua interfaccia eth0. Il pacchetto viene inviato lì.
   Questa interfaccia eth0 è in realtà collegata virtualmente al router virtuale vRouter tramite l'interfaccia TAP tap0.
2. Il vRouter analizza su quale interfaccia è arrivato il pacchetto, cioè a quale cliente (VRF) appartiene, confronta l'indirizzo del destinatario con la tabella di routing di quel cliente.
3. Scoprendo che il destinatario è sulla stessa macchina su un'altra porta, il vRouter inviato semplicemente il pacchetto senza ulteriori intestazioni — per questo caso il vRouter ha già una voce ARP.

In questo caso il pacchetto non entra nella rete fisica — è stato instradato all'interno del vRouter.

Control Plane

L'hypervisor, al momento dell'avvio della macchina virtuale, le comunica:

• Il proprio indirizzo IP.
• La route predefinita — attraverso l'indirizzo IP del vRouter in questa rete.

Al vRouter, attraverso un'API speciale, l'hypervisor comunica:

• Che deve essere creato un'interfaccia virtuale.
• Quale Virtual Network deve creare (la VM).
• A quale VRF legare il suo (VN).
• La registrazione ARP statica per questa VM indica quale interfaccia ha il suo indirizzo IP e a quale indirizzo MAC è associato.

Ancora una volta, la procedura reale di interazione è semplificata a favore della comprensione del concetto.

In questo modo, tutte le VM di un cliente su questa macchina vRouter vengono viste come reti direttamente collegate e possono instradare autonomamente tra di esse.

VM0 e VM1 appartengono a diversi clienti e, di conseguenza, si trovano in tabelle vRouter separate.

Se possono comunicare direttamente dipende dalle impostazioni del vRouter e dal design della rete.
Ad esempio, se le VM di entrambi i clienti utilizzano indirizzi pubblici, o se la NAT avviene sullo stesso vRouter, è possibile eseguire un instradamento diretto sul vRouter.

In una situazione diversa, può esserci un sovrapposizione degli spazi indirizzi: sarà necessario passare attraverso un server NAT per ottenere l'indirizzo pubblico, il che assomiglia a un'uscita verso reti esterne, di cui parleremo più avanti.

Comunicazione tra VM dislocate su macchine fisiche diverse

Data Plane

1. L'inizio è esattamente lo stesso: VM-0 invia un pacchetto a VM-7 (172.17.3.2) secondo il suo default.
2. Il vRouter lo riceve e questa volta vede che il destinatario si trova su un'altra macchina ed è accessibile tramite il tunnel Tunnel0.
3. Per prima cosa, applica un'etichetta MPLS che identifica l'interfaccia remota, in modo che sul lato opposto il vRouter possa determinare dove collocare questo pacchetto senza ulteriori complicazioni.

   

4. Per Tunnel0, la sorgente è 10.0.0.2 e il destinatario è 10.0.1.2.
   Il vRouter aggiunge intestazioni GRE (o UDP) e un nuovo IP al pacchetto sorgente.
5. Nella tabella di routing del vRouter esiste una rotta di default verso l'indirizzo ToR1 10.0.0.1. Il pacchetto viene inviato là.

   
   

6. ToR1, come partecipante della rete Underlay, sa (ad esempio tramite OSPF) come raggiungere 10.0.1.2 e invia il pacchetto lungo il percorso. Si noti che qui entra in gioco l'ECMP. Nella rappresentazione ci sono due next hop e i flussi diversi si distribuiscono in essi in base all'hash. In una vera fabbrica, ci sarebbero probabilmente 4 next hop.

   Inoltre, non è necessario sapere cosa si trova sotto l'intestazione IP esterna. In altre parole, sotto l'IP potrebbe trovarsi un sandwich di IPv6 over MPLS over Ethernet over MPLS over GRE over over over GRE.

7. Di conseguenza, sul lato ricevente, il vRouter rimuove il GRE e comprende, grazie all'etichetta MPLS, a quale interfaccia deve essere trasmesso questo pacchetto, lo decompone e lo invia nel formato originale al destinatario.

Control Plane

Quando la macchina viene avviata, avviene esattamente la stessa cosa che è stata descritta sopra.

E in aggiunta anche quanto segue:

• Per ogni cliente, vRouter assegna un'etichetta MPLS. Questa è un'etichetta di servizio L3VPN, sulla quale i clienti verranno separati all'interno di una singola macchina fisica.
  

  In realtà, l'etichetta MPLS viene sempre assegnata dal vRouter, poiché non è noto in anticipo che la macchina interagirà solo con altre macchine dietro lo stesso vRouter e molto probabilmente non è nemmeno così.

• Il vRouter stabilisce una connessione con il controller SDN attraverso il protocollo BGP (o un protocollo simile — nel caso di TF è XMPP 0_o).
• Attraverso questa sessione, il vRouter informa il controller SDN sulle rotte verso le reti connesse:
  • Indirizzo di rete
  • Metodo di incapsulamento (MPLSoGRE, MPLSoUDP, VXLAN)
  • Etichetta MPLS del cliente
  • Il proprio indirizzo IP come nexthop

• Il controller SDN riceve tali rotte da tutti i vRouter connessi e le riflette ad altri. Cioè agisce come Route Reflector.

Lo stesso processo avviene anche in direzione opposta.

L'Overlay può cambiare anche ogni minuto. Questo è all'incirca come avviene nei cloud pubblici, quando i clienti avviano e spengono regolarmente le loro macchine virtuali.

Il controller centrale si occupa di tutte le complicazioni nella manutenzione della configurazione e nel controllo delle tabelle di commutazione/routing sui vRouter.

Parlando in modo generico, il controller si connette a tutti i vRouter tramite BGP (o un protocollo simile) e semplicemente trasmette le informazioni sulle rotte. BGP, ad esempio, ha già un'Address-Family per l'invio del metodo di incapsulamento. MPLS-in-GRE o MPLS-in-UDP.

In questo modo non cambia in alcun modo la configurazione della rete Underlay, che, tra l'altro, è decisamente più difficile da automatizzare, mentre è più facile romperla con un movimento maldestro.

Uscita verso il mondo esterno

Da qualche parte la simulazione deve finire ed è necessario uscire dal mondo virtuale per entrare in quello reale. E serve un gateway telefonico.

Vengono praticati due approcci:

1. Si installa un router hardware.
2. Si avvia qualche appliance che realizza le funzioni di un router (sì, sì, dopo SDN ci siamo imbattuti anche in VNF). Chiamiamolo gateway virtuale.

Il vantaggio del secondo approccio è nella scalabilità orizzontale economica: se manca potenza, si avvia un'altra macchina virtuale con un gateway. Su qualsiasi macchina fisica, senza dover cercare rack, unità, alimentazione, acquistare l'hardware, trasportarlo, installarlo, cablarlo, configurarlo e poi anche sostituire i componenti difettosi.

Gli svantaggi del gateway virtuale sono che l'unità fisica del router è comunque molto più potente di una virtual machine multi-core, e il suo software, adattato alla sua infrastruttura hardware, funziona in modo significativamente più stabile (no). È difficile negare anche il fatto che il complesso software-hardware semplicemente funziona, richiedendo solo configurazioni, mentre l'avvio e la manutenzione del gateway virtuale è un compito per ingegneri esperti.

Con una gamba, il gateway guarda nella rete virtuale Overlay, come una normale Virtual Machine, e può interagire con tutte le altre VM. Inoltre, può terminare le reti di tutti i clienti e, di conseguenza, effettuare il routing tra di esse.

Con l'altra gamba, il gateway guarda già nella rete backbone e sa come uscire su Internet.

Data Plane

Quindi il processo appare così:

1. La VM-0, avendo il default tutto nello stesso vRouter, invia un pacchetto con destinatario nel mondo esterno (185.147.83.177) all'interfaccia eth0.
2. Il vRouter riceve questo pacchetto e fa un lookup dell'indirizzo di destinazione nella tabella di routing, trovando il percorso di default attraverso il gateway VNGW1 tramite il Tunnel 1.
   Vede anche che questo è un tunnel GRE con SIP 10.0.0.2 e DIP 10.0.255.2, e deve prima applicare il tag MPLS di questo cliente, che VNGW1 si aspetta.
3. Il vRouter impacchetta il pacchetto originale negli header MPLS, GRE e nuovo IP e lo invia all'indirizzo ToR1 10.0.0.1 per default.
4. La rete underlay consegna il pacchetto al gateway VNGW1.
5. Il gateway VNGW1 rimuove gli header di tunneling GRE e MPLS, vede l'indirizzo di destinazione, consulta la sua tabella di routing e comprende che è diretto su Internet, quindi attraverso Full View o Default. Se necessario, esegue la traduzione NAT.
6. Tra VNGW e il border potrebbe esserci una normale rete IP, il che è poco probabile.
   Potrebbe esserci una rete MPLS classica (IGP+LDP/RSVP TE), potrebbe esserci una fabbrica inversa con BGP LU o un tunnel GRE da VNGW al border attraverso una rete IP.
   In ogni caso, VNGW1 esegue le necessarie incapsulazioni e invia il pacchetto originale verso il border.

Il traffico nella direzione opposta segue gli stessi passaggi nell'ordine opposto.

1. Il border consegna il pacchetto a VNGW1
2. Questi lo disimballa, guarda l'indirizzo del destinatario e vede che è accessibile attraverso il tunnel Tunnel1 (MPLSoGRE o MPLSoUDP).
3. Di conseguenza, applica il tag MPLS, l'header GRE/UDP e un nuovo IP e invia al suo ToR3 10.0.255.1.
   L'indirizzo di destinazione del tunnel è l'indirizzo IP del vRouter, dietro cui si trova la VM target — 10.0.0.2.
4. La rete di sottopiano consegna il pacchetto al vRouter corretto.
5. Il vRouter di destinazione rimuove GRE/UDP, determina l'interfaccia tramite il tag MPLS e invia un pacchetto IP nudo alla sua interfaccia TAP, collegata a eth0 della VM.

Control Plane

VNGW1 stabilisce un'adiacenza BGP con il controller SDN, da cui riceve tutte le informazioni di routing sui clienti: con quale indirizzo IP (vRouter) si trova ciascun cliente e con quale tag MPLS è identificato.

Analogamente, comunica al controller SDN la rotta predefinita con il tag di questo cliente, indicando se stesso come nexthop. Successivamente, questa rotta predefinita arriva ai vRouter.

Su VNGW avviene solitamente l'aggregazione delle rotte o la traduzione NAT.

E nella direzione opposta, nella sessione con i border o i Route Reflector, restituisce proprio questa rotta aggregata. E da loro riceve la rotta predefinita o Full-View, o altro ancora.

In termini di incapsulamento e scambio di traffico, VNGW non si differenzia da un vRouter.
Se si amplia un po' l'ambito, si possono aggiungere a VNGW e vRouter anche altri dispositivi di rete, come firewall, farm di pulizia o arricchimento del traffico, IPS e così via.

E tramite la creazione sequenziale di VRF e l'annuncio corretto delle rotte, si può costringere il traffico a fare zigzag come si desidera, che viene chiamato Service Chaining.

Cioè, anche in questo caso il controller SDN funge da Route-Reflector tra VNGW, vRouter e altri dispositivi di rete.

Ma, in effetti, il controller trasmette anche informazioni su ACL e PBR (Policy Based Routing), costringendo flussi di traffico specifici a muoversi in modo diverso da quanto indicato dalla rotta.

FAQ

Perché fai sempre questa osservazione su GRE/UDP?

Beh, in realtà, si può dire che questo sia specifico per Tungsten Fabric — si può anche non prendere in considerazione.

Ma se lo consideriamo, il TF, pur essendo OpenContrail, supportava entrambe le incapsulazioni: MPLS in GRE e MPLS in UDP.

UDP è vantaggioso poiché nella porta sorgente nel suo intestazione è molto semplice codificare una funzione hash degli IP+Proto+Port iniziali, il che permetterà di effettuare un bilanciamento.

Nel caso di GRE, purtroppo, ci sono solo intestazioni esterne IP e GRE, che sono identiche per tutto il traffico incapsulato e il bilanciamento non è fattibile — pochi possono guardare così in profondità all'interno del pacchetto.

Fino a un certo punto, i router, sebbene sapessero gestire tunnel dinamici, lo facevano solo con MPLSoGRE e solo di recente hanno appreso a farlo con MPLSoUDP. Pertanto, è necessario fare sempre un'osservazione sulla possibilità di due diverse incapsulazioni.

A onor del vero, vale la pena notare che TF supporta perfettamente anche la connessione L2 tramite VXLAN.

Hai promesso di tracciare delle parallele con OpenFlow.
E in effetti si impongono. Il vSwitch nello stesso OpenStack fa cose molto simili, utilizzando VXLAN, che, tra l'altro, è dotato anche di intestazione UDP.

Nel Data Plane lavorano in modo abbastanza simile, mentre il Control Plane diverge notevolmente. Tungsten Fabric utilizza XMPP per la consegna delle informazioni sulle rotte al vRouter, mentre in OpenStack opera Openflow.

Potresti dirci qualcosa in più sul vRouter?
Esso è diviso in due parti: vRouter Agent e vRouter Forwarder.

Il primo si avvia nello User Space del sistema operativo host e comunica con il controller SDN, scambiando informazioni su rotte, VRF e ACL.

Il secondo implementa il Data Plane — solitamente nello Kernel Space, ma può essere eseguito anche su SmartNIC, schede di rete con CPU e un chip di commutazione programmabile separato, il che consente di alleggerire il carico dalla CPU della macchina host e rendere la rete più veloce e più prevedibile.

È possibile anche uno scenario in cui il vRouter è un'applicazione DPDK nello User Space.

Il vRouter Agent trasmette le impostazioni al vRouter Forwarder.

Che cos'è una Virtual Network?
Ho accennato all'inizio dell'articolo al VRF, specificando che ogni tenant è associato al proprio VRF. E se per una comprensione superficiale del funzionamento della rete overlay questo fosse sufficiente, già nella prossima iterazione è necessario fornire ulteriori dettagli.

Di solito, nei meccanismi di virtualizzazione, l'entità Virtual Network (puoi considerarlo un nome proprio) è introdotta separatamente dai clienti/tenant/macchine virtuali — un'entità del tutto autonoma. E questa Virtual Network può essere collegata tramite interfacce a un tenant, a un altro, a due, insomma, ovunque. Così, ad esempio, si realizza il Service Chaining, quando il traffico deve passare attraverso nodi specifici in una certa sequenza, semplicemente creando e associando correttamente le Virtual Network.

Pertanto, non c'è una corrispondenza diretta tra Virtual Network e tenant.

Conclusione

Questa è una descrizione piuttosto superficiale del funzionamento di una rete virtuale con overlay da host e controller SDN. Ma qualunque piattaforma di virtualizzazione si prenda oggi, funzionerà in modo simile, sia essa VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric o Juniper Contrail. Esse differiranno per i tipi di incapsulamenti e intestazioni, per i protocolli di consegna delle informazioni ai dispositivi di rete finali, ma il principio della rete overlay programmabile, che funziona sopra una rete underlay relativamente semplice e statica, rimarrà lo stesso.
Si può dire che nel campo della creazione di cloud privati oggi il SDN basato su rete overlay ha prevalso. Tuttavia, ciò non significa che Openflow non abbia un posto nel mondo moderno: è utilizzato in OpenStack e nel medesimo VMWare NSX, e quanto ne so, è utilizzato da Google per configurare la rete underlay.

Un po' più in basso ho fornito dei link a materiali più dettagliati, se si desidera approfondire l'argomento.

E che dire della nostra Underlay?

In realtà, nulla. Non è cambiata affatto. Tutto ciò che deve fare in caso di overlay da host è aggiornare le rotte e gli ARP man mano che appaiono e scompaiono vRouter/VNGW e gestire i pacchetti tra di essi.

Formuliamo un elenco di requisiti per la rete Underlay.

1. Essere in grado di gestire un qualche protocollo di routing, nella nostra situazione - BGP.
2. Avere una larga larghezza di banda, idealmente senza over-subscription, per evitare la perdita di pacchetti a causa di sovraccarichi.
3. Supportare ECMP - parte integrante della fabric.
4. Essere in grado di garantire QoS, comprese cose complicate come ECN.
5. Supportare NETCONF - un investimento per il futuro.

Ho dedicato pochissimo tempo al funzionamento stesso della rete Underlay. Questo perché nei prossimi articoli mi concentrerò proprio su di essa, mentre l'Overlay lo toccheremo solo di sfuggita.

È evidente che sto limitando molto tutti noi, usando come esempio una rete DC costruita su fabric Clos con routing IP puro e overlay da host.

Tuttavia, sono certo che qualsiasi rete con un design può essere descritta in termini formali e automatizzata. Sto semplicemente cercando di capire gli approcci all'automazione, non di confondere tutti risolvendo il problema in generale.

Nell'ambito dell'ADSM, io e Roman Gorge pianifichiamo di pubblicare un numero separato sulla virtualizzazione delle risorse computazionali e il suo interfacciamento con la virtualizzazione della rete. Rimanete in contatto.

Link utili

• Architettura di Tungsten Fabric.
• about:cloud. 6 ore su Yandex.Cloud, che tratta anche della rete virtuale su TF.
• Cos'è Open vSwitch?
• Introduzione a VxLAN.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): Un Framework per sovrapporre reti virtualizzate di livello 2 su reti di livello 3.
  
• Approccio di Scaleway a VXLAN EVPN Fabric. Qui si parla dell'intera rete del data center, inclusi Underlay, Overlay, approcci al multi-homing e gestione.

Grazie a

• Roman Gorgé — ex conduttore del podcast linkmeup, ora esperto nel campo delle piattaforme cloud. Grazie per i commenti e le correzioni. Aspettiamo anche un suo articolo più approfondito sulla virtualizzazione.
• Alexander Shalimov — mio collega ed esperto nello sviluppo di reti virtuali. Grazie per i commenti e le correzioni.
• Valentin Sinytsyn — mio collega ed esperto nel campo di Tungsten Fabric. Grazie per i commenti e le correzioni.
• Artem Chernoby — illustratore di linkmeup. Grazie per il KDPV.
• Alexander Limonov. Grazie per il meme 'automato'.

Fonte: habr.com