В numero precedente Ho descritto il framework di automazione della rete. Secondo alcuni anche questo primo approccio al problema ha già risolto alcuni interrogativi. E questo mi rende molto felice, perché il nostro obiettivo nel ciclo non è coprire Ansible con script Python, ma costruire un sistema.

Lo stesso quadro stabilisce l’ordine in cui affronteremo la questione.
E la virtualizzazione della rete, a cui è dedicato questo numero, non si adatta particolarmente all'argomento ADSM, in cui analizziamo l'automazione.

Ma guardiamo la cosa da una prospettiva diversa.

Molti servizi utilizzano la stessa rete da molto tempo. Nel caso di un operatore di telecomunicazioni si tratta ad esempio di 2G, 3G, LTE, banda larga e B2B. Nel caso di un DC: connettività per diversi client, Internet, block storage, object storage.

E tutti i servizi richiedono l’isolamento gli uni dagli altri. Ecco come sono apparse le reti sovrapposte.

E tutti i servizi non vogliono aspettare che una persona li configuri manualmente. Ecco come sono apparsi gli orchestratori e l'SDN.

Il primo approccio all’automazione sistematica della rete, o meglio di parte di essa, è stato adottato e implementato da tempo in molti luoghi: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Questo è ciò di cui ci occuperemo oggi.

contenuto

• motivi
• terminologia
• Sottofondo: rete fisica
• Sovrapposizione: rete virtuale
  • Sovrapposizione con ToR
  • Sovrapposizione dall'host
  • Utilizzando il tessuto di tungsteno come esempio
    • Comunicazione all'interno di un'unica macchina fisica
    • Comunicazione tra VM situate su macchine fisiche diverse
    • Uscita nel mondo esterno

• FAQ
• conclusione
• Link utili

motivi

E poiché stiamo parlando di questo, vale la pena menzionare i prerequisiti per la virtualizzazione della rete. In realtà, questo processo non è iniziato ieri.

Probabilmente hai sentito più di una volta 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 poggia tutto ed è piuttosto difficile apportare modifiche: i servizi non lo tollerano quando la rete non funziona. Spesso, la disattivazione di un singolo nodo può eliminare gran parte delle applicazioni e avere un impatto su molti clienti. Questo è in parte il motivo per cui il team della rete potrebbe opporsi a qualsiasi cambiamento, perché ora in qualche modo funziona (potremmo anche non sapere come), ma qui è necessario configurare qualcosa di nuovo e non si sa come influirà sulla rete.

Per non aspettare che i networker inseriscano le VLAN e per non registrare alcun servizio su ciascun nodo della rete, è venuta l'idea di utilizzare degli overlay - reti overlay - di cui esiste una grande varietà: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, ecc.

Il loro fascino risiede in due semplici cose:

• Sono configurati solo i nodi finali: non è necessario toccare i nodi di transito. Ciò accelera notevolmente il processo e talvolta consente di escludere completamente il dipartimento delle infrastrutture di rete dal processo di introduzione di nuovi servizi.
• Il carico è nascosto in profondità nelle intestazioni: i nodi di transito non hanno bisogno di sapere nulla al riguardo, sull'indirizzamento sugli host o sui percorsi della rete sovrapposta. Ciò significa che è necessario memorizzare meno informazioni nelle tabelle, il che significa utilizzare un dispositivo più semplice/economico.

In questo numero non del tutto completo, non intendo analizzare tutte le possibili tecnologie, ma piuttosto descrivere il quadro per il funzionamento delle reti overlay nei paesi in via di sviluppo.

L'intera serie descriverà un data center costituito da file di rack identici in cui è installata la stessa apparecchiatura server.

Questa apparecchiatura esegue macchine virtuali/container/serverless che implementano servizi.

terminologia

In bicicletta server Nominerò un programma che implementa il lato server della comunicazione client-server.

Le macchine fisiche nei rack sono chiamate server no noi.

Macchina fisica — Computer x86 installato in un rack. Il termine più utilizzato хост. Lo chiameremo così”macchina"o хост.

Hypervisor - un'applicazione in esecuzione su una macchina fisica che emula le risorse fisiche su cui funzionano le macchine virtuali. A volte nella letteratura e in Internet la parola “hypervisor” viene utilizzata come sinonimo di “host”.

Macchina virtuale - un sistema operativo in esecuzione su una macchina fisica su un hypervisor. Per noi in questo ciclo, non ha molta importanza se si tratta effettivamente di una macchina virtuale o semplicemente di un contenitore. Chiamiamolo "VM«

Inquilino è un concetto ampio che definirò in questo articolo come un servizio separato o un client separato.

Multi-locazione o multitenancy: l'utilizzo della stessa applicazione da parte di diversi client/servizi. Allo stesso tempo, l'isolamento dei client gli uni dagli altri viene ottenuto grazie all'architettura dell'applicazione e non tramite istanze eseguite separatamente.

ToR: interruttore nella parte superiore del rack - uno switch installato in un rack al quale sono collegate tutte le macchine fisiche.

Oltre alla topologia ToR, vari fornitori praticano End of Row (EoR) o Middle of Row (anche se quest'ultima è una rarità denigratoria e non ho visto l'abbreviazione MoR).

Rete sottostante oppure la rete sottostante o il sottofondo è l'infrastruttura di rete fisica: switch, router, cavi.

Rete sovrapposta o rete overlay o overlay: una rete virtuale di tunnel che si sovrappone a quella fisica.

Tessuto L3 o tessuto IP - una straordinaria invenzione dell'umanità che ti consente di evitare di ripetere STP e di imparare TRILL per le interviste. Un concetto in cui l'intera rete fino al livello di accesso è esclusivamente L3, senza VLAN e, di conseguenza, enormi domini di trasmissione estesi. Vedremo da dove deriva la parola “fabbrica” nella parte successiva.

SDN - Rete definita dal software. Non ha quasi bisogno di presentazioni. Un approccio alla gestione della rete in cui le modifiche alla rete non vengono apportate da una persona, ma da un programma. Di solito significa spostare il piano di controllo oltre i dispositivi finali della rete fino al controller.

NFV - Virtualizzazione delle funzioni di rete: virtualizzazione dei dispositivi di rete, suggerendo che alcune funzioni di rete possono essere eseguite sotto forma di macchine virtuali o contenitori per accelerare l'implementazione di nuovi servizi, organizzare il concatenamento dei servizi e una scalabilità orizzontale più semplice.

VNF - Funzione di rete virtuale. Dispositivo virtuale specifico: router, switch, firewall, NAT, IPS/IDS, ecc.

Ora sto deliberatamente semplificando la descrizione per un'implementazione specifica, in modo da non confondere troppo il lettore. Per una lettura più ponderata, lo rimando alla sezione riferimenti. Inoltre, Roma Gorge, che critica questo articolo per le inesattezze, promette di scrivere un numero a parte sulle tecnologie di virtualizzazione dei server e della rete, più approfondito e attento ai dettagli.

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

Sottofondo — una rete fisica con una configurazione stabile.
Copertura — astrazione su Underlay per isolare gli inquilini.

Ciò vale sia per il caso di DC (che analizzeremo in questo articolo) che per quello di ISP (che non analizzeremo, perché è già stato SDSM). Con le reti aziendali, ovviamente, la situazione è leggermente diversa.

Immagine con focus sulla rete:

Sottofondo

Underlay è una rete fisica: switch hardware e cavi. I dispositivi nel sottosuolo sanno come raggiungere le macchine fisiche.

Si basa su protocolli e tecnologie standard. Anche perché i dispositivi hardware ancora oggi funzionano con un software proprietario che non consente né la programmazione del chip né l'implementazione dei propri protocolli; di conseguenza sono necessarie compatibilità con altri fornitori e standardizzazione.

Ma qualcuno come Google può permettersi di sviluppare i propri cambiamenti e abbandonare i protocolli generalmente accettati. Ma LAN_DC non è Google.

L'underlay cambia relativamente raramente perché il suo compito è la connettività IP di base tra macchine fisiche. Underlay non sa nulla dei servizi, dei client o dei tenant in esecuzione su di esso: deve solo consegnare il pacchetto da una macchina all'altra.
Il sottofondo potrebbe essere così:

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

La rete Underlay è configurata nel modo classico: CLI/GUI/NETCONF.

Manualmente, script, utilità proprietarie.

Il prossimo articolo della serie sarà dedicato al sottofondo in modo più dettagliato.

Copertura

Overlay è una rete virtuale di tunnel estesa sopra Underlay, consente alle VM di un client di comunicare tra loro, fornendo allo stesso tempo l'isolamento dagli altri client.

I dati del client vengono incapsulati in alcune intestazioni di tunneling per la trasmissione sulla rete pubblica.

Pertanto le VM di un client (un servizio) possono comunicare tra loro tramite Overlay, senza nemmeno sapere quale percorso prende effettivamente il pacchetto.

L'overlay potrebbe essere, ad esempio, come ho menzionato sopra:

• tunnel GRE
• VXLAN
• VPN
• VPN L3
• GENEVE

Una rete sovrapposta viene generalmente configurata e gestita tramite un controller centrale. Da esso, la configurazione, il piano di controllo e il piano dati vengono consegnati ai dispositivi che instradano e incapsulano il traffico client. Un po sotto Diamo un'occhiata a questo con degli esempi.

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

Esistono due approcci fondamentalmente diversi per organizzare una rete Overlay:

1. Sovrapposizione con ToR
2. Sovrapposizione dall'host

Sovrapposizione con ToR

L'overlay può iniziare dallo switch di accesso (ToR) situato nel rack, come accade ad esempio nel caso di una struttura VXLAN.

Si tratta di un meccanismo collaudato nel tempo sulle reti ISP e supportato da tutti i fornitori di apparecchiature di rete.

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

Qui rimanderò il lettore ad un articolo su VxLAN su Habré il nostro vecchio amico @bormoglotx.
In questo presentazioni con ENOG vengono descritti in dettaglio gli approcci per costruire una rete DC con una struttura EVPN VXLAN.

E per un’immersione più completa nella realtà, potete leggere il libro di Tsiska Una struttura moderna, aperta e scalabile: VXLAN EVPN.

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

Tuttavia, la struttura VXLAN, in cui l'overlay inizia a ToR, è uno dei progetti di rete overlay consolidati.

Sovrapposizione dall'host

Un altro approccio consiste nell'avviare e terminare i tunnel sugli host finali.
In questo caso la rete (Underlay) rimane quanto più semplice e statica possibile.
E l'host stesso esegue tutto l'incapsulamento necessario.

Ciò richiederà ovviamente l'esecuzione di un'applicazione speciale sugli host, ma ne vale la pena.

Innanzitutto far girare un client su una macchina Linux è più semplice o, diciamo, addirittura possibile, mentre su uno switch molto probabilmente bisognerà ricorrere a soluzioni SDN proprietarie, il che uccide l’idea del multi-vendor.

In secondo luogo, il cambio ToR in questo caso può essere lasciato il più semplice possibile, sia dal punto di vista del Piano di Controllo che del Piano Dati. Infatti, non ha bisogno di comunicare con il controller SDN, e non ha nemmeno bisogno di memorizzare le reti/ARP di tutti i client collegati: è sufficiente conoscere l'indirizzo IP della macchina fisica, il che semplifica notevolmente la commutazione/ tabelle di instradamento.

Nella serie ADSM, scelgo l'approccio overlay dall'host, quindi ne parliamo solo e non torneremo alla fabbrica VXLAN.

È più semplice guardare gli esempi. E come soggetto di prova prenderemo la piattaforma SDN OpenSource OpenContrail, ora nota come Tessuto di tungsteno.

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

Utilizzando il tessuto di tungsteno come esempio

Ogni macchina fisica ha vRouter - un router virtuale che conosce le reti ad esso collegate e a quali client appartengono - essenzialmente un router PE. Per ogni client mantiene una tabella di routing isolata (leggi VRF). E vRouter esegue effettivamente il tunneling Overlay.

Maggiori informazioni su vRouter si trovano alla fine dell'articolo.

Ogni VM situata sull'hypervisor è connessa al vRouter di questa macchina tramite Interfaccia TAP.

TAP - Terminal Access Point: un'interfaccia virtuale nel kernel Linux che consente l'interazione di rete.

Se dietro il vRouter sono presenti più reti, per ciascuna di esse viene creata un'interfaccia virtuale a cui viene assegnato un indirizzo IP: sarà l'indirizzo del gateway predefinito.
Tutte le reti di un client sono inserite in una VRF (una tabella), diversi - in diversi.
Farò qui una dichiarazione di non responsabilità che non tutto è così semplice e invierò il lettore curioso alla fine dell'articolo.

Affinché i vRouter possano comunicare tra loro e, di conseguenza, le VM che si trovano dietro di loro, si scambiano informazioni di routing tramite Controllore SDN.

Per uscire nel mondo esterno, esiste un punto di uscita dalla matrice: un gateway di rete virtuale VNGW - Gateway di rete virtuale (il mio termine).

Ora diamo un'occhiata ad esempi di comunicazione e ci sarà chiarezza.

Comunicazione all'interno di un'unica macchina fisica

VM0 vuole inviare un pacchetto a VM2. Supponiamo per ora che si tratti di una VM client singola.

Piano dati

1. VM-0 ha un percorso predefinito verso la sua interfaccia eth0. Il pacco viene inviato lì.
   Questa interfaccia eth0 è in realtà connessa virtualmente al router virtuale vRouter tramite l'interfaccia TAP tap0.
2. vRouter analizza a quale interfaccia è arrivato il pacchetto, cioè a quale client (VRF) appartiene, e controlla l'indirizzo del destinatario con la tabella di routing di questo client.
3. Dopo aver rilevato che il destinatario sulla stessa macchina si trova su una porta diversa, vRouter gli invia semplicemente il pacchetto senza intestazioni aggiuntive: in questo caso vRouter ha già un record ARP.

In questo caso il pacchetto non entra nella rete fisica ma viene instradato all'interno del vRouter.

Piano di controllo

All'avvio della macchina virtuale, l'hypervisor le dice:

• Il suo indirizzo IP.
• Il percorso predefinito avviene attraverso l'indirizzo IP del vRouter su questa rete.

L'hypervisor riporta al vRouter tramite una speciale API:

• Cosa ti serve per creare un'interfaccia virtuale.
• Che tipo di rete virtuale deve creare (VM)?
• A quale VRF (VN) associarlo.
• Una voce ARP statica per questa VM: su quale interfaccia si trova il suo indirizzo IP e a quale indirizzo MAC è associato.

Ancora una volta, la procedura di interazione vera e propria è semplificata per facilitare la comprensione del concetto.

Pertanto, vRouter vede tutte le VM di un client su una determinata macchina come reti direttamente connesse e può instradarle da solo.

Ma VM0 e VM1 appartengono a client diversi e, di conseguenza, si trovano in tabelle vRouter diverse.

La possibilità di comunicare tra loro direttamente dipende dalle impostazioni del vRouter e dalla progettazione della rete.
Ad esempio, se le VM di entrambi i client utilizzano indirizzi pubblici o NAT si verifica sul vRouter stesso, è possibile eseguire l'instradamento diretto al vRouter.

Nella situazione opposta, è possibile attraversare spazi di indirizzi - è necessario passare attraverso un server NAT per ottenere un indirizzo pubblico - questo è simile all'accesso alle reti esterne, discusse di seguito.

Comunicazione tra VM situate su macchine fisiche diverse

Piano dati

1. L'inizio è esattamente lo stesso: VM-0 invia un pacchetto con la destinazione VM-7 (172.17.3.2) per impostazione predefinita.
2. vRouter lo riceve e questa volta vede che la destinazione si trova su una macchina diversa ed è accessibile tramite Tunnel0.
3. Innanzitutto, applica un'etichetta MPLS che identifica l'interfaccia remota, in modo che sul retro vRouter possa determinare dove posizionare questo pacchetto senza ulteriori ricerche.

   

4. Tunnel0 ha origine 10.0.0.2, destinazione: 10.0.1.2.
   vRouter aggiunge intestazioni GRE (o UDP) e un nuovo IP al pacchetto originale.
5. La tabella di routing del vRouter ha un percorso predefinito attraverso l'indirizzo ToR1 10.0.0.1. È lì che lo manda.

   
   

6. ToR1, in quanto membro della rete Underlay, sa (ad esempio tramite OSPF) come arrivare a 10.0.1.2 e invia il pacchetto lungo il percorso. Tieni presente che ECMP è abilitato qui. Nell'illustrazione sono presenti due nexthop e i diversi thread verranno ordinati in base all'hash. Nel caso di una fabbrica reale, ci saranno più probabilmente 4 nexthops.

   Allo stesso tempo, non ha bisogno di sapere cosa si trova sotto l'intestazione IP esterna. Cioè, in effetti, sotto IP può esserci un sandwich di IPv6 su MPLS su Ethernet su MPLS su GRE su su Greco.

7. Di conseguenza, dal lato ricevente, vRouter rimuove GRE e, utilizzando il tag MPLS, capisce a quale interfaccia deve essere inviato questo pacchetto, lo spoglia e lo invia nella sua forma originale al destinatario.

Piano di controllo

Quando si avvia l'auto, accade la stessa cosa descritta sopra.

E in più quanto segue:

• Per ogni client, vRouter alloca un tag MPLS. Questa è l'etichetta del servizio L3VPN, in base alla quale i client saranno separati all'interno della stessa macchina fisica.
  

  In effetti, il tag MPLS viene sempre assegnato incondizionatamente dal vRouter - dopotutto non è noto in anticipo che la macchina interagirà solo con altre macchine dietro lo stesso vRouter e molto probabilmente non è nemmeno vero.

• vRouter stabilisce una connessione con il controller SDN utilizzando il protocollo BGP (o simile - nel caso di TF, questo è XMPP 0_o).
• Attraverso questa sessione, vRouter segnala i percorsi alle reti connesse al controller SDN:
  • Indirizzo di rete
  • Metodo di incapsulamento (MPLSoGRE, MPLSoUDP, VXLAN)
  • Tag cliente MPLS
  • Il tuo indirizzo IP come nexthop

• Il controller SDN riceve tali percorsi da tutti i vRouter connessi e li riflette sugli altri. Cioè, agisce come un riflettore di percorso.

La stessa cosa accade nella direzione opposta.

La sovrapposizione può cambiare almeno ogni minuto. Questo è più o meno ciò che accade nei cloud pubblici, dove i client avviano e spengono regolarmente le proprie macchine virtuali.

Il controller centrale si occupa di tutta la complessità del mantenimento della configurazione e del monitoraggio delle tabelle di commutazione/routing sul vRouter.

In parole povere, il controller comunica con tutti i vRouter tramite BGP (o un protocollo simile) e trasmette semplicemente le informazioni di routing. BGP, ad esempio, dispone già di Address-Family per trasmettere il metodo di incapsulamento MPLS-in-GRE o MPLS-in-UDP.

Allo stesso tempo, la configurazione della rete Underlay non cambia in alcun modo, il che, tra l'altro, è molto più difficile da automatizzare ed è più facile da rompere con un movimento scomodo.

Uscita nel mondo esterno

Da qualche parte la simulazione deve finire e devi uscire dal mondo virtuale in quello reale. E ti serve un gateway per telefoni pubblici.

Vengono praticati due approcci:

1. È installato un router hardware.
2. Viene lanciata un'appliance che implementa le funzioni di un router (sì, dopo SDN abbiamo incontrato anche VNF). Chiamiamolo gateway virtuale.

Il vantaggio del secondo approccio è la scalabilità orizzontale economica: non c'è abbastanza potenza: abbiamo lanciato un'altra macchina virtuale con un gateway. Su qualsiasi macchina fisica, senza dover cercare rack, unità, potenza in uscita, acquistare l'hardware stesso, trasportarlo, installarlo, cambiarlo, configurarlo e quindi anche modificare i componenti difettosi.

Gli svantaggi di un gateway virtuale sono che l'unità di un router fisico è ancora molto più potente di una macchina virtuale multi-core e il suo software, adattato alla propria base hardware, funziona in modo molto più stabile (no). È anche difficile negare il fatto che il complesso hardware e software funzioni semplicemente, richiedendo solo la configurazione, mentre il lancio e la manutenzione di un gateway virtuale è un compito per ingegneri esperti.

Con un piede, il gateway esamina la rete virtuale Overlay, come una normale macchina virtuale, e può interagire con tutte le altre VM. Allo stesso tempo può terminare le reti di tutti i client e, di conseguenza, eseguire il routing tra di loro.

Con l'altro piede il gateway guarda nella rete dorsale e sa come accedere a Internet.

Piano dati

Cioè, il processo è simile al seguente:

1. VM-0, avendo utilizzato per impostazione predefinita lo stesso vRouter, invia un pacchetto con una destinazione nel mondo esterno (185.147.83.177) all'interfaccia eth0.
2. vRouter riceve questo pacchetto e cerca l'indirizzo di destinazione nella tabella di routing: trova il percorso predefinito attraverso il gateway VNGW1 attraverso il Tunnel 1.
   Vede anche che si tratta di un tunnel GRE con SIP 10.0.0.2 e DIP 10.0.255.2 e deve anche prima allegare l'etichetta MPLS di questo client, come si aspetta VNGW1.
3. vRouter impacchetta il pacchetto iniziale con MPLS, GRE e nuove intestazioni IP e lo invia a ToR1 10.0.0.1 per impostazione predefinita.
4. La rete sottostante consegna il pacchetto al gateway VNGW1.
5. Il gateway VNGW1 rimuove le intestazioni di tunneling GRE e MPLS, vede l'indirizzo di destinazione, consulta la sua tabella di routing e capisce che è indirizzato a Internet, ovvero tramite Visualizzazione completa o Predefinita. Se necessario, esegue la traduzione NAT.
6. Potrebbe esserci una rete IP regolare da VNGW al confine, il che è improbabile.
   Potrebbe esserci una classica rete MPLS (IGP+LDP/RSVP TE), potrebbe esserci un back fabric con BGP LU o un tunnel GRE da VNGW al confine tramite una rete IP.
   Comunque sia, VNGW1 esegue gli incapsulamenti necessari e invia il pacchetto iniziale verso il confine.

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

1. Il confine rilascia il pacchetto a VNGW1
2. Lo spoglia, guarda l'indirizzo del destinatario e vede che è raggiungibile attraverso il tunnel Tunnel1 (MPLSoGRE o MPLSoUDP).
3. Di conseguenza, allega un'etichetta MPLS, un'intestazione GRE/UDP e un nuovo IP e lo invia al suo ToR3 10.0.255.1.
   L'indirizzo di destinazione del tunnel è l'indirizzo IP del vRouter dietro il quale si trova la VM di destinazione - 10.0.0.2.
4. La rete sottostante consegna il pacchetto al vRouter desiderato.
5. Il vRouter di destinazione legge GRE/UDP, identifica l'interfaccia utilizzando l'etichetta MPLS e invia un pacchetto IP nudo alla sua interfaccia TAP associata a eth0 della VM.

Piano di controllo

VNGW1 stabilisce un quartiere BGP con un controller SDN, dal quale riceve tutte le informazioni di instradamento sui client: quale indirizzo IP (vRouter) si trova dietro quale client e con quale etichetta MPLS è identificato.

Allo stesso modo, lui stesso informa il controller SDN del percorso predefinito con l'etichetta di questo client, indicandosi come nexthop. E poi questa impostazione predefinita arriva a vRouters.

Su VNGW, di solito si verifica l'aggregazione del percorso o la traduzione NAT.

E nella direzione opposta, invia esattamente questo percorso aggregato alla sessione con bordi o Route Reflector. E da loro riceve il percorso predefinito o Full-View o qualcos'altro.

In termini di incapsulamento e scambio di traffico, VNGW non è diverso da vRouter.
Se si espande leggermente l'ambito, è possibile aggiungere altri dispositivi di rete a VNGW e vRouter, come firewall, farm di pulizia del traffico o di arricchimento, IPS e così via.

E con l'aiuto della creazione sequenziale di VRF e del corretto annuncio dei percorsi, puoi forzare il traffico a circolare nel modo desiderato, il che si chiama Service Chaining.

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

Ma in realtà il controller rilascia anche informazioni su ACL e PBR (Policy Based Routing), facendo sì che i singoli flussi di traffico vadano diversamente da quanto indicato dal percorso.

FAQ

Perché continui a fare l'osservazione GRE/UDP?

Bene, in generale, si può dire che questo sia specifico del tessuto in tungsteno: non devi tenerne affatto conto.

Ma se lo prendiamo, allora TF stesso, mentre era ancora OpenContrail, supportava entrambi gli incapsulamenti: MPLS in GRE e MPLS in UDP.

UDP è utile perché nella Source Port è molto semplice codificare una funzione hash dall'IP+Proto+Port originale nella sua intestazione, che ti consentirà di eseguire il bilanciamento.

Nel caso di GRE, ahimè, ci sono solo intestazioni IP esterne e GRE, che sono le stesse per tutto il traffico incapsulato e non si parla di bilanciamento: poche persone possono guardare così in profondità all'interno del pacchetto.

Fino a qualche tempo fa, i router, se sapevano come usare i tunnel dinamici, lo facevano solo in MPLSoGRE, e solo di recente hanno imparato a usare MPLSoUDP. Pertanto, dobbiamo sempre prendere nota della possibilità di due diversi incapsulamenti.

In tutta onestà, vale la pena notare che TF supporta completamente la connettività L2 utilizzando VXLAN.

Hai promesso di tracciare paralleli con OpenFlow.
Se lo stanno chiedendo davvero. vSwitch nello stesso OpenStack fa cose molto simili, usando VXLAN, che, tra l'altro, ha anche un'intestazione UDP.

Nel Piano Dati funzionano più o meno allo stesso modo; il Piano di Controllo differisce in modo significativo. Tungsten Fabric utilizza XMPP per fornire informazioni di routing a vRouter, mentre OpenStack esegue Openflow.

Puoi dirmi qualcosa in più su vRouter?
È diviso in due parti: vRouter Agent e vRouter Forwarder.

Il primo viene eseguito nello spazio utente del sistema operativo host e comunica con il controller SDN, scambiando informazioni su percorsi, VRF e ACL.

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

Un altro scenario possibile è che vRouter sia un'applicazione DPDK nello spazio utente.

vRouter Agent invia le impostazioni a vRouter Forwarder.

Cos'è una rete virtuale?
Ho accennato all'inizio dell'articolo sul VRF che ogni inquilino è legato al proprio VRF. E se questo bastasse per una comprensione superficiale del funzionamento della rete overlay, alla successiva iterazione sarà necessario fare dei chiarimenti.

Tipicamente, nei meccanismi di virtualizzazione, l'entità Rete Virtuale (che puoi considerare questo come un nome proprio) viene introdotta separatamente dai client/tenant/macchine virtuali, una cosa completamente indipendente. E questa rete virtuale può già essere connessa tramite interfacce a un tenant, a un altro, a due o ovunque. Quindi, ad esempio, il Service Chaining viene implementato quando il traffico deve essere fatto passare attraverso determinati nodi nella sequenza richiesta, semplicemente creando e collegando Reti Virtuali nella sequenza corretta.

Pertanto non esiste corrispondenza diretta tra Rete Virtuale e tenant.

conclusione

Questa è una descrizione molto superficiale del funzionamento di una rete virtuale con una sovrapposizione dell'host e un controller SDN. Ma qualunque sia la piattaforma di virtualizzazione che scegli oggi, funzionerà in modo simile, che si tratti di VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric o Juniper Contrail. Differiranno nei tipi di incapsulamenti e intestazioni, protocolli per fornire informazioni ai dispositivi di rete finali, ma il principio di una rete overlay configurabile tramite software che opera su una rete underlay relativamente semplice e statica rimarrà lo stesso.
Possiamo dire che oggi SDN basato su una rete overlay ha vinto il campo della creazione di un cloud privato. Tuttavia, ciò non significa che Openflow non abbia posto nel mondo moderno: è utilizzato in OpenStacke e nello stesso VMWare NSX, per quanto ne so, Google lo utilizza per configurare la rete sotterranea.

Di seguito ho fornito collegamenti a materiali più dettagliati se desideri studiare la questione più approfonditamente.

E che dire del nostro Underlay?

Ma in generale, niente. Non è cambiato del tutto. Tutto ciò che deve fare nel caso di una sovrapposizione dall'host è aggiornare i percorsi e gli ARP man mano che vRouter/VNGW appaiono e scompaiono e trasportano i pacchetti tra di loro.

Formuliamo un elenco di requisiti per la rete Underlay.

1. Essere in grado di utilizzare una sorta di protocollo di routing, nella nostra situazione: BGP.
2. Avere un'ampia larghezza di banda, preferibilmente senza oversubscription, in modo che i pacchetti non vadano persi a causa di sovraccarichi.
3. Il sostegno all’ECMP è parte integrante del tessuto.
4. Essere in grado di fornire QoS, comprese cose complicate come ECN.
5. Supportare NETCONF è una base per il futuro.

Ho dedicato pochissimo tempo qui al lavoro della stessa rete Underlay. Questo perché più avanti nella serie mi concentrerò su questo, e toccheremo Overlay solo di sfuggita.

Ovviamente, sto limitando severamente tutti noi utilizzando come esempio una rete DC costruita in una fabbrica Cloz con routing IP puro e un overlay dall'host.

Tuttavia, sono fiducioso che qualsiasi rete dotata di un design possa essere descritta in termini formali e automatizzata. È solo che il mio obiettivo qui è comprendere gli approcci all'automazione e non confondere tutti risolvendo il problema in forma generale.

Nell'ambito di ADSM, Roman Gorge e io intendiamo pubblicare un numero separato sulla virtualizzazione della potenza di calcolo e la sua interazione con la virtualizzazione della rete. Rimani in contatto.

Link utili

• Architettura del tessuto di tungsteno.
• riguardo a:nuvola. 6 ore su Yandex.Cloud, che copre anche la rete virtuale su TF.
• Cos'è Open vSwitch?
• Introduzione alla VxLAN.
• RFC 7348. Virtual eXtensible Local Area Network (VXLAN): un framework per sovrapporre reti virtualizzate di livello 2 su reti di livello 3.
  
• Approccio Scaleway al Fabric VXLAN EVPN. Parla dell'intera rete DC, inclusi Underlay, Overlay, approcci al multi-homing e gestione.

Grazie

• Gorga romana - ex conduttore del podcast linkmeup e ora esperto nel campo delle piattaforme cloud. Per commenti e modifiche. Bene, stiamo aspettando il suo articolo più approfondito sulla virtualizzazione nel prossimo futuro.
• Aleksandr Shalimov - il mio collega ed esperto nel campo dello sviluppo di reti virtuali. Per commenti e modifiche.
• Valentin Sinitsyn - il mio collega ed esperto nel campo del tessuto di tungsteno. Per commenti e modifiche.
• Artyom Chernobay - collegamento illustratore. Per KDPV.
• Aleksandr Limonov. Per il meme "automato".

Fonte: habr.com