Ciao, mi chiamo Kostya Kramlikh e sono il principale sviluppatore della divisione Virtual Private Cloud in Yandex.Cloud. Mi occupo di reti virtuali e, come puoi immaginare, in questo articolo parlerò del funzionamento del Virtual Private Cloud (VPC) in generale e delle reti virtuali in particolare. Inoltre, scoprirai perché noi, sviluppatori del servizio, valorizziamo il feedback dei nostri utenti. Ma andiamo con ordine.
Che cos'è il VPC?
Oggi ci sono molteplici opzioni per l'implementazione dei servizi. Sono sicuro che qualcuno ancora tiene un server sotto la scrivania dell'amministratore, anche se spero che queste storie stiano diventando sempre meno comuni.
Attualmente, i servizi tendono a spostarsi verso i cloud pubblici, e qui entrano in gioco i VPC. Il VPC è una parte del cloud pubblico che collega le risorse utente, infrastrutturali, di piattaforma e altre in un'unica rete, indipendentemente da dove si trovino, sia nel nostro Cloud che al di fuori di esso. Inoltre, il VPC consente di non esporre queste risorse su Internet se non necessario; rimangono all'interno della tua rete isolata.
Come appare una rete virtuale dall'esterno
Con VPC ci riferiamo soprattutto a una rete overlay e a servizi di rete come VPNaaS, NATaas, LBaas, ecc. E tutto questo funziona su un'infrastruttura di rete resiliente, di cui abbiamo già parlato ottimo articolo qui su Habr.
Esploriamo la rete virtuale e la sua struttura più da vicino.
Consideriamo due zone di disponibilità. Offriamo una rete virtuale – ciò che abbiamo chiamato VPC. In effetti, definisce lo spazio di unicità dei tuoi indirizzi 'grigi'. All'interno di ogni rete virtuale gestisci completamente lo spazio degli indirizzi che puoi assegnare alle risorse di calcolo.
La rete è globale. Viene proiettata su ciascuna delle zone di disponibilità come entità chiamata Subnet. A ogni Subnet si assegna un CIDR di dimensione 16 o inferiore. In ogni zona di disponibilità possono esserci più di una di queste entità, con un routing sempre trasparente tra di esse. Ciò significa che tutte le tue risorse all'interno di una VPC possono "comunicare" tra loro, anche se si trovano in diverse zone di disponibilità. "Comunicare" senza uscire su Internet, attraverso i nostri canali interni, "credendo" di trovarsi all'interno di una rete privata.
Nello schema sopra è illustrata una situazione tipica: due VPC che si sovrappongono in alcuni indirizzi. Entrambe possono appartenerti. Ad esempio, una per lo sviluppo e l'altra per il testing. Potrebbero anche appartenere a diversi utenti – in questo caso non importa. In ogni VPC è inserita una macchina virtuale.
Complichiamo lo schema. È possibile configurare una macchina virtuale per essere connessa a più Subnet contemporaneamente. E non è un semplice caso, ma in diverse reti virtuali.
Per utilizzare le macchine su Internet, puoi farlo attraverso l'API o l'interfaccia utente. È necessario configurare la traslazione NAT del tuo indirizzo "grigio", interno, in un indirizzo "bianco" – pubblico. Non puoi scegliere l'indirizzo "bianco"; viene assegnato casualmente dal nostro pool di indirizzi. Una volta che smetti di utilizzare l'IP esterno, questo torna nel pool. Paghi solo per il tempo in cui utilizzi l'indirizzo "bianco".
C'è anche la possibilità di fornire accesso a Internet alla macchina tramite un'istanza NAT. Puoi instradare il traffico attraverso una tabella di routing statica. Abbiamo previsto questo caso, poiché sappiamo che può essere necessario per gli utenti. Pertanto, nel nostro catalogo di immagini, c'è un'immagine NAT configurata appositamente.
Anche quando esiste un'immagine NAT pronta, la configurazione può essere complessa. Abbiamo compreso che per alcuni utenti questa non è la soluzione più comoda, quindi alla fine abbiamo reso possibile attivare NAT per la sottorete desiderata con un solo clic. Questa funzione è attualmente in anteprima chiusa, testata con la partecipazione della comunità.
Come è strutturata internamente una rete virtuale
Come interagisce l'utente con la rete virtuale? La rete si affaccia verso l'esterno tramite la sua API. L'utente accede all'API e lavora con lo stato desiderato. Attraverso l'API, l'utente può vedere come tutto dovrebbe essere configurato, e visualizza lo stato attuale rispetto a quello desiderato. Questa è la visione dell'utente. E cosa succede all'interno?
Registriamo lo stato desiderato nel Yandex Database e procediamo a configurare diverse parti della nostra VPC. La rete overlay in Yandex.Cloud è costruita utilizzando componenti selezionati di OpenContrail, che recentemente ha preso il nome di Tungsten Fabric. I servizi di rete sono implementati su un'unica piattaforma, CloudGate. In CloudGate abbiamo utilizzato anche alcuni componenti open source: GoBGP per la gestione delle informazioni di controllo, e VPP per realizzare un router software che opera sopra DPDK per il data path.
Tungsten Fabric comunica con CloudGate tramite GoBGP. Racconta cosa succede nella rete overlay. CloudGate, a sua volta, collega le reti overlay tra loro e con Internet.
Ora diamo un'occhiata a come una rete virtuale affronta le sfide di scalabilità e disponibilità. Consideriamo un caso semplice. Abbiamo una zona di disponibilità in cui sono state create due VPC. Abbiamo implementato un'istanza di Tungsten Fabric, che gestisce decine di migliaia di reti. Le reti sono collegate a CloudGate. Come abbiamo già detto, CloudGate assicura la connettività tra di loro e con Internet.
Supponiamo di aggiungere una seconda zona di disponibilità. Questa deve poter guastarsi completamente indipendentemente dalla prima. Pertanto, nella seconda zona di disponibilità dobbiamo installare un'istanza separata di Tungsten Fabric. Sarà un sistema autonomo, che si occupa di overlay e sa poco o nulla del primo sistema. La visibilità della nostra rete virtuale globale è fornita dal nostro API VPC. Questa è la sua funzione.
VPC1 è progettato per la zona di disponibilità B, se nella zona di disponibilità B ci sono risorse collegate a VPC1. Se non ci sono risorse da VPC2 nella zona di disponibilità B, VPC2 non verrà materializzato in questa zona. Allo stesso modo, poiché le risorse di VPC3 esistono solo nella zona B, VPC3 non è presente nella zona A. È tutto semplice e logico.
Andiamo un po' più a fondo per vedere come è strutturato un host specifico in Y.Cloud. La cosa principale da notare è che tutti gli host sono costruiti allo stesso modo. Facciamo in modo che solo il minimo indispensabile di servizi funzioni sull'hardware, mentre tutti gli altri operano su macchine virtuali. Costruiamo servizi di livello superiore basati sui servizi infrastrutturali di base e utilizziamo il Cloud per risolvere alcune sfide ingegneristiche, ad esempio, nel contesto della Continuous Integration.
Se guardiamo a un host specifico, vediamo che nel sistema operativo dell'host girano tre componenti:
- Compute – la parte responsabile della distribuzione delle risorse di calcolo sull'host.
- VRouter – parte di Tungsten Fabric, che organizza l'overlay, cioè incapsula i pacchetti attraverso l'underlay.
- VDisk – è la porzione di virtualizzazione dello storage.
Inoltre, sono macchine virtuali in esecuzione i servizi: servizi infrastrutturali del Cloud, servizi di piattaforma e capacità dei clienti. Le capacità dei clienti e i servizi di piattaforma si muovono sempre nell'overlay attraverso il VRouter.
I servizi infrastrutturali possono integrarsi nell'overlay, ma in genere preferiscono operare nell'underlay. In questo contesto, si connettono tramite SR-IOV. In pratica, suddividiamo la scheda in schede di rete virtuali (funzioni virtuali) e le inseriamo nelle macchine virtuali infrastrutturali, per non compromettere le prestazioni. Ad esempio, il CloudGate è avviato come una di queste macchine virtuali infrastrutturali.
Ora che abbiamo descritto le sfide globali della rete virtuale e la struttura dei componenti di base del cloud, vediamo come le diverse parti della rete virtuale interagiscono tra loro.
Nella nostra sistema, identifichiamo tre strati:
- Config Plane – definisce lo stato desiderato del sistema. Questo è ciò che l'utente configura tramite l'API.
- Control Plane – garantisce la semantica definita dall'utente, cioè porta lo stato del Data Plane a ciò che è stato descritto dall'utente nel Config Plane.
- Data Plane – elabora direttamente i pacchetti dell'utente.
Come ho detto in precedenza, tutto inizia quando l'utente o un servizio interno della piattaforma accede all'API e descrive uno stato desiderato specifico.
Questo stato viene immediatamente registrato nel Yandex Database, restituisce tramite API l'ID dell'operazione asincrona e avvia la nostra macchina interna per fornire lo stato desiderato dall'utente. I task di configurazione vengono inviati al controller SDN e comunicano a Tungsten Fabric cosa fare nell'overlay. Ad esempio, prenotano porte, reti virtuali e simili.
Il Config Plane in Tungsten Fabric invia allo Control Plane lo stato richiesto. Attraverso di esso, il Config Plane comunica con gli host, informandoli su cosa verrà eseguito di lì a poco.
Vediamo ora come appare il sistema sugli host. In macchina virtuale c'è un certo adattatore di rete, collegato a VRouter. VRouter è il modulo centrale di Tungsten Fabric che analizza i pacchetti. Se per un certo pacchetto esiste già un flow, il modulo lo elabora. Se non c'è flusso, il modulo effettua un cosiddetto punting, inviando il pacchetto al processo in user mode. Il processo analizza il pacchetto e risponde a esso o comunica a VRouter come trattarlo. Dopo ciò, VRouter può elaborare il pacchetto.
Il traffico tra le macchine virtuali all'interno della stessa rete virtuale è trasparente e non passa attraverso CloudGate. I nodi su cui sono distribuite le macchine virtuali comunicano direttamente tra loro, tunnelizzando il traffico e instradandolo a vicenda attraverso l'underlay.
Il Control Plane comunica tra le zone di disponibilità via BGP, proprio come fa con un altro router. Esso informa su quali macchine sono attive in ogni area, permettendo così alle macchine virtuali di una zona di interagire direttamente con quelle di un'altra zona.
Inoltre, il Control Plane comunica con CloudGate. A tal proposito, informa su dove si trovano le macchine virtuali e i loro indirizzi. Questo consente di indirizzare il traffico esterno e il traffico dai bilanciatori verso di esse.
Il traffico in uscita dal VPC arriva a CloudGate, nel data path, dove viene rapidamente processato da VPP con i nostri plugin. Successivamente, il traffico viene inviato a altri VPC o all'esterno, verso i router di confine, che vengono configurati tramite il Control Plane di CloudGate.
Piani per il prossimo futuro
In sintesi, si può affermare che il VPC in Yandex.Cloud svolge due compiti fondamentali:
- Fornisce isolamento tra diversi clienti.
- Unisce risorse, infrastrutture, servizi di piattaforma, altre nuvole e on-premise in una rete unica.
Per affrontare bene queste sfide, è necessario garantire scalabilità e resilienza a livello di architettura interna, e questo è esattamente ciò che fa il VPC.
Gradualmente, il VPC si arricchisce di funzionalità, implementiamo nuove opportunità e ci impegniamo a migliorare l'esperienza degli utenti. Alcune idee vengono sollevate e finiscono nella lista delle priorità grazie ai membri della nostra comunità.
Attualmente abbiamo circa questo piano per il prossimo futuro:
- VPN come servizio.
- Istanze DNS private – immagini per una rapida configurazione di macchine virtuali con un server DNS preconfigurato.
- DNS come servizio.
- Bilanciatore di carico interno.
- Aggiunta di un indirizzo IP "bianco" senza ricreare la macchina virtuale.
Il bilanciatore e la possibilità di cambiare l'indirizzo IP per una macchina virtuale già creata si sono trovati in questo elenco su richiesta degli utenti. A essere sinceri, senza un feedback chiaro ci saremmo occupati di queste funzionalità un po' più tardi. Ora stiamo già lavorando sull'argomento degli indirizzi.
Inizialmente, un indirizzo IP 'bianco' poteva essere aggiunto solo alla creazione della macchina. Se l'utente dimenticava di farlo, la macchina virtuale doveva essere ricreata. Lo stesso vale per la necessità di rimuovere un IP pubblico. Presto sarà possibile attivare e disattivare un IP pubblico senza dover ricreare la macchina.
Non esitate a esprimere le vostre idee e a sostenere le proposte degli altri utenti. Ci aiutare a rendere il Cloud migliore e a ottenere importanti e utili funzionalità più rapidamente!
Fonte: habr.com
