Ciao, mi chiamo Kostya Kramliх, sono uno sviluppatore principale dell'unità Virtual Private Cloud in Yandex.Cloud. Mi occupo di rete virtuale e, come potete immaginare, in questo articolo parlerò della struttura del Virtual Private Cloud (VPC) in generale e della rete virtuale in particolare. Inoltre, scoprirete perché noi sviluppatori del servizio apprezziamo il feedback dai nostri utenti. Ma andiamo con ordine.
Che cos'è il VPC?
Oggi ci sono molte possibilità per mettere in piedi servizi. Sono sicuro che qualcuno tiene ancora un server sotto la scrivania dell'amministratore, anche se spero che queste storie diventino sempre meno comuni.
Attualmente, i servizi cercano di migrare verso le nuvole pubbliche, e qui incontrano proprio il VPC. Il VPC è una parte della nube pubblica che collega risorse utente, infrastrutture, piattaforme e altre potenzialità in un'unica entità, ovunque si trovino, che sia nella nostra nuvola o al di fuori di essa. Inoltre, il VPC evita di esporre queste potenzialità a Internet, mantenendole all'interno della vostra rete isolata.
Come appare una rete virtuale dall'esterno
Con VPC ci riferiamo in primo luogo a una rete overlay e a servizi di rete, come VPNaaS, NATaas, LBaaS, ecc. E tutto ciò funziona su un'infrastruttura di rete resiliente, di cui abbiamo già parlato in ottimo articolo qui su Habr.
Diamo un'occhiata più da vicino alla rete virtuale e alla sua struttura.
Esaminiamo due zone di disponibilità. Forniamo una rete virtuale – ciò che abbiamo chiamato VPC. Essa definisce effettivamente lo spazio di unicità dei vostri indirizzi "grigi". All'interno di ogni rete virtuale gestite completamente lo spazio degli indirizzi che potete assegnare alle risorse computazionali.
La rete è globale. Essa si proietta in ciascuna delle zone di disponibilità sotto forma di entità chiamata Subnet. Per ogni Subnet assegni un certo CIDR di dimensione 16 o inferiore. In ogni zona di disponibilità può esserci più di una di queste entità, e tra di esse esiste sempre un routing trasparente. Questo significa che tutte le tue risorse all'interno di una stessa VPC possono "comunicare" tra di loro, anche se si trovano in diverse zone di disponibilità. "Comunicare" senza uscire su Internet, attraverso i nostri canali interni, "pensando" di trovarsi all'interno di una stessa rete privata.
Nello schema sopra è mostrata una situazione tipica: due VPC che in qualche modo si sovrappongono negli indirizzi. Entrambe possono appartenerti. Ad esempio, una per lo sviluppo e l'altra per il test. Potrebbero anche esserci utenti diversi; in questo caso non è importante. In ciascuna VPC è collegata una macchina virtuale.
Complichiamo lo schema. È possibile collegare una macchina virtuale a più Subnet contemporaneamente. E non solo, ma in diverse reti virtuali.
Tuttavia, se hai bisogno di esporre le macchine a Internet, puoi farlo tramite API o UI. Per questo è necessario configurare la traduzione NAT del tuo indirizzo "grigio", interno, in un indirizzo "bianco" – pubblico. Non puoi scegliere il tuo indirizzo "bianco"; esso viene assegnato casualmente dal nostro pool di indirizzi. Non appena smetti di utilizzare l'IP esterno, esso torna nel pool. Paghi solamente per il tempo di utilizzo dell'indirizzo "bianco".
C'è anche la possibilità di fornire a una macchina l'accesso a Internet tramite un'istanza NAT. Si può instradare il traffico attraverso una tabella di routing statica. Abbiamo previsto questo caso, poiché a volte è necessario per gli utenti, e ne siamo a conoscenza. Di conseguenza, nel nostro catalogo di immagini c'è un'immagine NAT appositamente configurata.
Ma anche quando esiste un'immagine NAT pronta, la configurazione può essere complessa. Ci siamo resi conto che per alcuni utenti questa non è la soluzione più comoda, quindi alla fine abbiamo implementato la possibilità di attivare NAT per la Subnet desiderata con un clic. Questa funzionalità è ancora in anteprima chiusa, in fase di test con partecipanti della comunità.
Come è strutturata una rete virtuale internamente
Come interagisce l'utente con la rete virtuale? La rete guarda all'esterno attraverso la propria API. L'utente accede all'API e lavora sullo stato desiderato. Tramite l'API, l'utente vede come tutto dovrebbe essere organizzato e configurato, mentre osserva lo stato attuale e quanto questo differisca da quello desiderato. Questa è la visione dell'utente. E cosa succede all'interno?
Registriamo lo stato desiderato in Yandex Database e procediamo a configurare le varie parti della nostra VPC. La rete overlay in Yandex.Cloud è costruita su componenti selezionati di OpenContrail, recentemente rinominati Tungsten Fabric. I servizi di rete sono implementati su un'unica piattaforma, CloudGate. In CloudGate abbiamo anche utilizzato un certo numero di componenti open source: GoBGP – per l'accesso alle informazioni di controllo, e VPP – per implementare un router software che opera su DPDK per il data path.
Tungsten Fabric comunica con CloudGate tramite GoBGP. Informa su cosa sta succedendo nella rete overlay. CloudGate, a sua volta, collega le reti overlay tra loro e con Internet.
Ora vediamo come la rete virtuale affronta le sfide di scalabilità e disponibilità. Consideriamo un caso semplice. C'è una zona di disponibilità in cui sono state create due VPC. Abbiamo distribuito un'istanza di Tungsten Fabric, e essa gestisce decine di migliaia di reti. Le reti si collegano a CloudGate. CloudGate, come abbiamo già detto, garantisce la loro connessione tra di loro e con Internet.
Supponiamo che venga aggiunta una seconda zona di disponibilità. Essa deve poter rispondere in modo completamente indipendente dalla prima. Pertanto, nella seconda zona di disponibilità dobbiamo installare un'istanza separata di Tungsten Fabric. Sarà un sistema distinto, dedicato all'overlay e poco informato sul primo sistema. L'idea che la nostra rete virtuale sia globale è, in effetti, creata dalla nostra API VPC. Questo è il suo compito.
VPC1 si proietta nella zona di disponibilità B, se nella zona di disponibilità B ci sono risorse collegate a VPC1. Se non ci sono risorse di VPC2 nella zona di disponibilità B, non materializziamo VPC2 in questa zona. D'altra parte, 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 e vediamo come è strutturato un host specifico in Y.Cloud. La cosa principale da notare è che tutti gli host sono strutturati allo stesso modo. Facciamo in modo che solo il minimo necessario di servizi funzioni sull'hardware, tutti gli altri operano su macchine virtuali. Costruiamo servizi di livello superiore basati su servizi infrastrutturali di base e utilizziamo il Cloud per risolvere alcune sfide ingegneristiche, ad esempio nell'ambito del Continuous Integration.
Se guardiamo un host specifico, vedremo che nel sistema operativo dell'host sono in esecuzione tre componenti:
- Compute – la parte responsabile della distribuzione delle risorse di calcolo sull'host.
- VRouter – una parte di Tungsten Fabric che organizza l'overlay, cioè incapsula i pacchetti attraverso l'underlay.
- VDisk – sono frammenti di virtualizzazione dello storage.
Inoltre, in macchine virtuali sono in esecuzione servizi: servizi infrastrutturali del Cloud, servizi di piattaforma e potenza dei clienti. La potenza dei clienti e i servizi di piattaforma transitano sempre attraverso l'overlay tramite VRouter.
I servizi infrastrutturali possono inserirsi nell'overlay, ma vogliono principalmente operare nell'underlay. Nell'underlay si inseriscono tramite SR-IOV. Infatti, dividiamo la scheda in schede di rete virtuali (funzioni virtuali) e le facciamo passare nelle VM infrastrutturali per non perdere prestazioni. Ad esempio, il CloudGate stesso è in esecuzione 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.
Identifichiamo tre strati nel nostro sistema:
- Config Plane – definisce lo stato desiderato del sistema. Questo è ciò che l'utente configura tramite API.
- Control Plane – fornisce la semantica desiderata dall'utente, cioè porta lo stato del Data Plane allo stato descritto dall'utente nel Config Plane.
- Data Plane – elabora direttamente i pacchetti dell'utente.
Come ho già detto sopra, tutto inizia quando l'utente o un servizio di piattaforma interno accede all'API e descrive uno stato finale desiderato.
Questo stato viene immediatamente registrato nel Yandex Database, restituisce tramite API l'ID dell'operazione asincrona e avvia il nostro meccanismo interno per fornire lo stato desiderato dall'utente. I task di configurazione vengono inviati al controller SDN e informano Tungsten Fabric su cosa fare nell'overlay. Ad esempio, riservano porte, reti virtuali e simili.
Il Config Plane in Tungsten Fabric comunica al Control Plane lo stato richiesto. Attraverso di esso, il Config Plane interagisce con gli host, spiegando cosa eseguirà a breve.
Ora vediamo come appare il sistema sugli host. In macchina virtuale c'è un adattatore di rete collegato al VRouter. Il VRouter è il modulo centrale di Tungsten Fabric che controlla i pacchetti. Se per un pacchetto esiste già un flow, il modulo lo elabora. Se non c'è flow, il modulo esegue quello che viene chiamato punting, ovvero invia il pacchetto a un processo in user mode. Il processo analizza il pacchetto e risponde direttamente, come nel caso di DHCP e DNS, oppure comunica al VRouter cosa fare con esso. Successivamente, il VRouter può elaborare il pacchetto.
In seguito, il traffico tra le macchine virtuali all'interno di una rete virtuale è trasparente, non viene indirizzato verso il CloudGate. Gli host, su cui sono distribuite le macchine virtuali, comunicano direttamente tra loro. Tunnelizzano il traffico e lo inviano l'uno all'altro attraverso l'underlay.
I Control Plane comunicano tra loro tra le zone di disponibilità tramite BGP, come se fossero altri router. Informano quali macchine sono attive in ciascuna posizione affinché le macchine virtuali in una zona possano interagire direttamente con le altre macchine virtuali.
Inoltre, il Control Plane comunica con il CloudGate. Analogamente, informa su dove e quali macchine virtuali sono attive e quali sono i loro indirizzi. Questo consente di indirizzare il traffico esterno e quello proveniente dai bilanciatori.
Il traffico che esce dal VPC arriva al CloudGate, nel data path, dove viene rapidamente elaborato dal VPP con i nostri plugin. Successivamente, il traffico viene inviato a altri VPC o all'esterno, verso i router di confine, configurati tramite il Control Plane del CloudGate stesso.
Piani per il futuro prossimo
Se riassumiamo tutto quanto detto sopra in poche frasi, possiamo dire che il VPC in Yandex.Cloud affronta due importanti compiti:
- Garantisce isolamento tra diversi clienti.
- Unisce risorse, infrastrutture, servizi di piattaforma, altri cloud e on-premise in un'unica rete.
E per affrontare queste sfide in modo efficace, è necessario garantire scalabilità e resilienza a livello di architettura interna, cosa che fa il VPC.
Gradualmente, il VPC acquisisce funzionalità; stiamo implementando nuove capacità e cercando di migliorare l'usabilità per gli utenti. Alcune idee vengono enunciate e finiscono nella lista delle priorità grazie ai membri della nostra comunità.
Attualmente abbiamo circa questa lista di piani per il prossimo futuro:
- VPN come servizio.
- Istanze di DNS privato – 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 sono stati inseriti in questo elenco su richiesta degli utenti. A dire il vero, senza un feedback esplicito, ci saremmo presi più tempo per affrontare queste funzionalità. Adesso stiamo già lavorando sulla questione degli indirizzi.
Inizialmente, un indirizzo IP 'bianco' poteva essere aggiunto solo al momento della creazione della macchina. Se l'utente dimenticava di farlo, doveva ricreare la macchina virtuale. Lo stesso valeva se si desiderava rimuovere l'IP esterno. Presto sarà possibile attivare e disattivare un IP pubblico senza ricreare la macchina.
Non esitare a esprimere le tue idee e a sostenere le proposte degli altri utenti. Ci aiuti a rendere il Cloud migliore e a ottenere più rapidamente funzionalità importanti e utili!
Fonte: habr.com
