Ciao, mi chiamo Kostya Kramlikh, sono lo sviluppatore principale della divisione Virtual Private Cloud in Yandex.Cloud. Sono un networker virtuale e, come puoi immaginare, in questo articolo parlerò del dispositivo Virtual Private Cloud (VPC) in generale e della rete virtuale in particolare. E scoprirai anche perché noi, gli sviluppatori del servizio, apprezziamo il feedback dei nostri utenti. Ma prima le cose principali.
Cos'è VPC?
Al giorno d'oggi, ci sono una varietà di opzioni per la distribuzione dei servizi. Sono sicuro che qualcuno tiene ancora il server sotto la scrivania dell'amministratore, anche se spero che ci siano meno storie del genere.
Ora i servizi stanno cercando di passare ai cloud pubblici, ed è qui che si scontrano con i VPC. Il VPC fa parte di un cloud pubblico che collega insieme utenti, infrastruttura, piattaforma e altre capacità, ovunque si trovino, all'interno o all'esterno del nostro cloud. Allo stesso tempo, VPC ti consente di non esporre inutilmente queste capacità a Internet, che rimangono all'interno della tua rete isolata.
Che aspetto ha una rete virtuale dall'esterno?
Per VPC intendiamo principalmente una rete overlay e servizi di rete, come VPNaaS, NATaas, LBaas, ecc. E tutto questo funziona su un'infrastruttura di rete tollerante ai guasti, che è già stata qui, su Habré.
Diamo un'occhiata più da vicino alla rete virtuale e al suo dispositivo.
Considera due zone di disponibilità. Forniamo una rete virtuale, quella che abbiamo chiamato VPC. Infatti, definisce lo spazio di unicità dei tuoi indirizzi "grigi". All'interno di ogni rete virtuale si ha il controllo completo sullo spazio di indirizzi che è possibile assegnare alle risorse di calcolo.
La rete è globale. Allo stesso tempo, viene proiettato su ciascuna delle zone di disponibilità sotto forma di un'entità chiamata Subnet. Per ogni sottorete, assegni un CIDR di dimensione 16 o inferiore. Può esistere più di un'entità di questo tipo in ogni zona di disponibilità e c'è sempre un instradamento trasparente tra di esse. Ciò significa che tutte le tue risorse all'interno dello stesso VPC possono "parlare" tra loro, anche se si trovano in diverse zone di disponibilità. "Comunicare" senza accesso a Internet, attraverso i nostri canali interni, "pensando" di trovarsi all'interno della stessa rete privata.
Il diagramma sopra mostra una situazione tipica: due VPC che si intersecano da qualche parte negli indirizzi. Entrambi possono essere tuoi. Ad esempio, uno per lo sviluppo, l'altro per i test. Potrebbero esserci semplicemente utenti diversi, in questo caso non importa. E una macchina virtuale è collegata a ogni VPC.
Peggioriamo lo schema. Puoi fare in modo che una macchina virtuale sia bloccata in più sottoreti contemporaneamente. E non solo così, ma in diverse reti virtuali.
Allo stesso tempo, se è necessario esporre le macchine a Internet, è possibile farlo tramite l'API o l'interfaccia utente. Per fare ciò, è necessario configurare la traduzione NAT del proprio indirizzo interno "grigio" in "bianco" - pubblico. Non puoi scegliere un indirizzo "bianco", viene assegnato in modo casuale dal nostro pool di indirizzi. Non appena smetti di utilizzare l'IP esterno, viene restituito al pool. Paghi solo per il tempo di utilizzo dell'indirizzo "bianco".
È anche possibile fornire alla macchina l'accesso a Internet utilizzando un'istanza NAT. Puoi instradare il traffico a un'istanza tramite una tabella di routing statica. Abbiamo fornito un caso del genere, perché a volte gli utenti ne hanno bisogno e lo sappiamo. Di conseguenza, il nostro catalogo di immagini contiene un'immagine NAT appositamente configurata.
Ma anche quando c'è un'immagine NAT pronta, l'installazione può essere complicata. Abbiamo capito che per alcuni utenti questa non è l'opzione più conveniente, quindi alla fine abbiamo reso possibile abilitare NAT per la sottorete desiderata con un clic. Questa funzione è ancora in accesso di anteprima chiuso, dove viene testata con l'aiuto dei membri della comunità.
Come è organizzata la rete virtuale dall'interno
In che modo l'utente interagisce con la rete virtuale? Il web guarda all'esterno con la sua API. L'utente arriva all'API e lavora con lo stato di destinazione. Attraverso l'API, l'utente vede come tutto dovrebbe essere organizzato e configurato, mentre vede lo stato, quanto lo stato attuale differisce da quello desiderato. Questa è una foto dell'utente. Cosa sta succedendo dentro?
Scriviamo lo stato desiderato nel database Yandex e andiamo a configurare diverse parti del nostro VPC. La rete di overlay in Yandex.Cloud si basa su componenti selezionati di OpenContrail, recentemente chiamato Tungsten Fabric. I servizi di rete sono implementati su un'unica piattaforma CloudGate. In CloudGate, abbiamo utilizzato anche una serie di componenti open source: GoBGP, per accedere alle informazioni di controllo, e VPP, per implementare un router software che gira su DPDK per il percorso dei dati.
Tungsten Fabric comunica con CloudGate tramite GoBGP. Racconta cosa sta succedendo nella rete di overlay. CloudGate, a sua volta, collega le reti sovrapposte tra loro e con Internet.
Vediamo ora come una rete virtuale risolve i problemi di scalabilità e disponibilità. Consideriamo un caso semplice. È presente una zona di disponibilità e in essa vengono creati due VPC. Abbiamo implementato un'istanza di Tungsten Fabric che esegue il pull di diverse decine di migliaia di reti. Le reti comunicano con CloudGate. CloudGate, come abbiamo già detto, garantisce la loro connettività tra loro e con Internet.
Supponiamo che venga aggiunta una seconda zona di disponibilità. Dovrebbe fallire completamente indipendentemente dal primo. Pertanto, nella seconda zona di disponibilità, dobbiamo installare un'istanza Tungsten Fabric separata. Questo sarà un sistema separato che si occupa dell'overlay e sa poco del primo sistema. E la visibilità che la nostra rete virtuale è globale, infatti, crea la nostra API VPC. Questo è il suo compito.
VPC1 viene mappato alla zona di disponibilità B se sono presenti risorse nella zona di disponibilità B che vengono inviate a VPC1. Se non ci sono risorse da VPC2 nella zona di disponibilità B, non materializzeremo VPC2 in questa zona. A sua volta, poiché le risorse di VPC3 esistono solo nella zona B, VPC3 non esiste nella zona A. Tutto è semplice e logico.
Andiamo un po' più a fondo e vediamo come funziona un particolare host in Y.Cloud. La cosa principale che voglio sottolineare è che tutti gli host sono disposti allo stesso modo. Facciamo in modo che solo il minimo necessario di servizi venga eseguito su hardware, tutto il resto venga eseguito su macchine virtuali. Costruiamo servizi di ordine superiore basati su servizi infrastrutturali di base e utilizziamo anche il Cloud per risolvere alcuni problemi di ingegneria, ad esempio, nell'ambito della Continuous Integration.
Se osserviamo un host specifico, possiamo vedere che ci sono tre componenti in esecuzione sul sistema operativo host:
- Compute - la parte responsabile della distribuzione delle risorse di calcolo sull'host.
- VRouter è una parte di Tungsten Fabric che organizza un overlay, ovvero esegue il tunneling dei pacchetti attraverso un underlay.
- I VDisk sono blocchi di virtualizzazione dello storage.
Inoltre, i servizi vengono lanciati nelle macchine virtuali: servizi di infrastruttura cloud, servizi di piattaforma e capacità del cliente. Le capacità dei clienti e i servizi della piattaforma vanno sempre all'overlay tramite VRouter.
I servizi infrastrutturali possono rimanere nell'overlay, ma fondamentalmente vogliono lavorare nell'underlay. Sono incastrati nel sottostrato con l'aiuto di SR-IOV. Infatti, tagliamo la scheda in schede di rete virtuali (funzioni virtuali) e le inseriamo nelle macchine virtuali dell'infrastruttura per non perdere le prestazioni. Ad esempio, lo stesso CloudGate viene avviato come una di queste macchine virtuali dell'infrastruttura.
Ora che abbiamo descritto le attività globali della rete virtuale e la struttura dei componenti di base del cloud, vediamo come interagiscono esattamente le diverse parti della rete virtuale.
Distinguiamo tre livelli nel nostro sistema:
- Piano di configurazione: imposta lo stato di destinazione del sistema. Questo è ciò che l'utente configura tramite l'API.
- Piano di controllo: fornisce una semantica definita dall'utente, ovvero porta lo stato del piano dati a quanto descritto dall'utente in Config Plane.
- Piano dati: elabora direttamente i pacchetti dell'utente.
Come ho detto sopra, tutto inizia con il fatto che l'utente o il servizio della piattaforma interna arriva all'API e descrive un certo stato di destinazione.
Questo stato viene immediatamente scritto nel database Yandex, restituisce l'ID dell'operazione asincrona tramite l'API e avvia il nostro meccanismo interno per restituire lo stato desiderato dall'utente. Le attività di configurazione passano al controller SDN e indicano a Tungsten Fabric cosa fare nell'overlay. Ad esempio, riservano porte, reti virtuali e simili.
Config Plane in Tungsten Fabric invia lo stato richiesto al Control Plane. Attraverso di esso, Config Plane comunica con gli host, dicendo cosa esattamente girerà su di loro presto.
Ora vediamo come appare il sistema sugli host. La macchina virtuale ha una scheda di rete collegata a VRouter. VRouter è un modulo principale di Tungsten Fabric che esamina i pacchetti. Se esiste già un flusso per qualche pacchetto, il modulo lo elabora. Se non c'è flusso, il modulo esegue il cosiddetto punting, ovvero invia un pacchetto al processo usermod. Il processo analizza il pacchetto e risponde ad esso stesso, come DHCP e DNS, o dice a VRouter cosa farne. Successivamente, VRouter può elaborare il pacchetto.
Inoltre, il traffico tra macchine virtuali all'interno della stessa rete virtuale passa in modo trasparente, non è diretto a CloudGate. Gli host su cui sono distribuite le macchine virtuali comunicano direttamente tra loro. Incanalano il traffico e lo inoltrano l'uno per l'altro attraverso il sottofondo.
I piani di controllo comunicano tra loro tra le zone di disponibilità tramite BGP, come con un altro router. Indicano quali macchine sono attive e dove, in modo che le VM in una zona possano comunicare direttamente con altre VM.
E Control Plane comunica con CloudGate. Allo stesso modo, segnala dove e quali macchine virtuali vengono attivate, quali indirizzi hanno. Ciò consente di indirizzare il traffico esterno e il traffico dai bilanciatori a loro.
Il traffico che lascia il VPC arriva a CloudGate, al percorso dati, dove il VPP con i nostri plugin viene rapidamente masticato. Quindi il traffico viene inviato ad altri VPC o all'esterno, ai router di confine configurati tramite il piano di controllo di CloudGate stesso.
Piani per il prossimo futuro
Se riassumiamo tutto quanto detto sopra in poche frasi, possiamo dire che VPC in Yandex.Cloud risolve due compiti importanti:
- Fornisce l'isolamento tra diversi client.
- Combina risorse, infrastruttura, servizi di piattaforma, altri cloud e on-premise in un'unica rete.
E per risolvere bene questi problemi, è necessario fornire scalabilità e tolleranza ai guasti a livello dell'architettura interna, cosa che fa VPC.
A poco a poco VPC acquisisce funzioni, implementiamo nuove funzionalità, cerchiamo di migliorare qualcosa in termini di comodità per l'utente. Alcune idee vengono espresse e vengono inserite nell'elenco delle priorità grazie ai membri della nostra comunità.
Al momento abbiamo il seguente elenco di piani per il prossimo futuro:
- VPN come servizio.
- Le istanze DNS private sono immagini per la configurazione rapida di macchine virtuali con un server DNS preconfigurato.
- DNS come servizio.
- Bilanciamento del 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 erano in questo elenco su richiesta degli utenti. Ad essere onesti, senza un feedback esplicito, avremmo assunto queste funzioni poco dopo. E quindi stiamo già lavorando al problema degli indirizzi.
Inizialmente, un indirizzo IP "bianco" poteva essere aggiunto solo durante la creazione di una macchina. Se l'utente si dimenticava di farlo, la macchina virtuale doveva essere ricreata. Lo stesso e, se necessario, rimuovere l'IP esterno. Presto sarà possibile attivare e disattivare l'IP pubblico senza dover ricreare la macchina.
Sentiti libero di esprimere il tuo altri utenti. Ci aiuti a migliorare il Cloud e a ottenere funzionalità importanti e utili più velocemente!
Fonte: habr.com