![\"Come](\"\/wp-content\/uploads\/2020\/02\/62b3d222c1911fb28a345defdd81135c.jpeg\")
<\/p>\nCiao, mi chiamo Kostya Kramli\u0445, sono uno sviluppatore principale dell'unit\u00e0 Virtual Private Cloud in Yandex.Cloud. Mi occupo di rete virtuale e, come potete immaginare, in questo articolo parler\u00f2 della struttura del Virtual Private Cloud (VPC) in generale e della rete virtuale in particolare. Inoltre, scoprirete perch\u00e9 noi sviluppatori del servizio apprezziamo il feedback dai nostri utenti. Ma andiamo con ordine.<\/p>\n
<\/p>\n
<\/a><\/p>\n Oggi ci sono molte possibilit\u00e0 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.<\/p>\n Attualmente, i servizi cercano di migrare verso le nuvole pubbliche, e qui incontrano proprio il VPC. Il VPC \u00e8 una parte della nube pubblica che collega risorse utente, infrastrutture, piattaforme e altre potenzialit\u00e0 in un'unica entit\u00e0, ovunque si trovino, che sia nella nostra nuvola o al di fuori di essa. Inoltre, il VPC evita di esporre queste potenzialit\u00e0 a Internet, mantenendole all'interno della vostra rete isolata.<\/p>\n Con VPC ci riferiamo in primo luogo a una rete overlay e a servizi di rete, come VPNaaS, NATaas, LBaaS, ecc. E tutto ci\u00f2 funziona su un'infrastruttura di rete resiliente, di cui abbiamo gi\u00e0 parlato in ottimo articolo<\/a> qui su Habr.<\/p>\n Diamo un'occhiata pi\u00f9 da vicino alla rete virtuale e alla sua struttura.<\/p>\n Esaminiamo due zone di disponibilit\u00e0. Forniamo una rete virtuale \u2013 ci\u00f2 che abbiamo chiamato VPC. Essa definisce effettivamente lo spazio di unicit\u00e0 dei vostri indirizzi \"grigi\". All'interno di ogni rete virtuale gestite completamente lo spazio degli indirizzi che potete assegnare alle risorse computazionali.<\/p>\n La rete \u00e8 globale. Essa si proietta in ciascuna delle zone di disponibilit\u00e0 sotto forma di entit\u00e0 chiamata Subnet. Per ogni Subnet assegni un certo CIDR di dimensione 16 o inferiore. In ogni zona di disponibilit\u00e0 pu\u00f2 esserci pi\u00f9 di una di queste entit\u00e0, 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\u00e0. \"Comunicare\" senza uscire su Internet, attraverso i nostri canali interni, \"pensando\" di trovarsi all'interno di una stessa rete privata.<\/p>\n Nello schema sopra \u00e8 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 \u00e8 importante. In ciascuna VPC \u00e8 collegata una macchina virtuale.<\/p>\n Complichiamo lo schema. \u00c8 possibile collegare una macchina virtuale a pi\u00f9 Subnet contemporaneamente. E non solo, ma in diverse reti virtuali.<\/p>\n Tuttavia, se hai bisogno di esporre le macchine a Internet, puoi farlo tramite API o UI. Per questo \u00e8 necessario configurare la traduzione NAT del tuo indirizzo \"grigio\", interno, in un indirizzo \"bianco\" \u2013 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\".<\/p>\n C'\u00e8 anche la possibilit\u00e0 di fornire a una macchina l'accesso a Internet tramite un'istanza NAT. Si pu\u00f2 instradare il traffico attraverso una tabella di routing statica. Abbiamo previsto questo caso, poich\u00e9 a volte \u00e8 necessario per gli utenti, e ne siamo a conoscenza. Di conseguenza, nel nostro catalogo di immagini c'\u00e8 un'immagine NAT appositamente configurata.<\/p>\n Ma anche quando esiste un'immagine NAT pronta, la configurazione pu\u00f2 essere complessa. Ci siamo resi conto che per alcuni utenti questa non \u00e8 la soluzione pi\u00f9 comoda, quindi alla fine abbiamo implementato la possibilit\u00e0 di attivare NAT per la Subnet desiderata con un clic. Questa funzionalit\u00e0 \u00e8 ancora in anteprima chiusa, in fase di test con partecipanti della comunit\u00e0.<\/p>\n 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 \u00e8 la visione dell'utente. E cosa succede all'interno?<\/p>\n Registriamo lo stato desiderato in Yandex Database e procediamo a configurare le varie parti della nostra VPC. La rete overlay in Yandex.Cloud \u00e8 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 \u2013 per l'accesso alle informazioni di controllo, e VPP \u2013 per implementare un router software che opera su DPDK per il data path.<\/p>\n 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.<\/p>\n Ora vediamo come la rete virtuale affronta le sfide di scalabilit\u00e0 e disponibilit\u00e0. Consideriamo un caso semplice. C'\u00e8 una zona di disponibilit\u00e0 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\u00e0 detto, garantisce la loro connessione tra di loro e con Internet.<\/p>\n Supponiamo che venga aggiunta una seconda zona di disponibilit\u00e0. Essa deve poter rispondere in modo completamente indipendente dalla prima. Pertanto, nella seconda zona di disponibilit\u00e0 dobbiamo installare un'istanza separata di Tungsten Fabric. Sar\u00e0 un sistema distinto, dedicato all'overlay e poco informato sul primo sistema. L'idea che la nostra rete virtuale sia globale \u00e8, in effetti, creata dalla nostra API VPC. Questo \u00e8 il suo compito.<\/p>\n VPC1 si proietta nella zona di disponibilit\u00e0 B, se nella zona di disponibilit\u00e0 B ci sono risorse collegate a VPC1. Se non ci sono risorse di VPC2 nella zona di disponibilit\u00e0 B, non materializziamo VPC2 in questa zona. D'altra parte, poich\u00e9 le risorse di VPC3 esistono solo nella zona B, VPC3 non \u00e8 presente nella zona A. \u00c8 tutto semplice e logico.<\/p>\n Andiamo un po' pi\u00f9 a fondo e vediamo come \u00e8 strutturato un host specifico in Y.Cloud. La cosa principale da notare \u00e8 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<\/a>. 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.<\/p>\n Se guardiamo un host specifico, vedremo che nel sistema operativo dell'host sono in esecuzione tre componenti:<\/p>\n Inoltre, in macchine virtuali<\/a> 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.<\/p>\n 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 \u00e8 in esecuzione come una di queste macchine virtuali infrastrutturali.<\/p>\n 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.<\/p>\n Identifichiamo tre strati nel nostro sistema:<\/p>\n Come ho gi\u00e0 detto sopra, tutto inizia quando l'utente o un servizio di piattaforma interno accede all'API e descrive uno stato finale desiderato.<\/p>\n 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.<\/p>\n 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\u00e0 a breve.<\/p>\n Ora vediamo come appare il sistema sugli host. In macchina virtuale<\/a> c'\u00e8 un adattatore di rete collegato al VRouter. Il VRouter \u00e8 il modulo centrale di Tungsten Fabric che controlla i pacchetti. Se per un pacchetto esiste gi\u00e0 un flow, il modulo lo elabora. Se non c'\u00e8 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\u00f2 elaborare il pacchetto.<\/p>\n In seguito, il traffico tra le macchine virtuali all'interno di una rete virtuale \u00e8 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.<\/p>\n I Control Plane comunicano tra loro tra le zone di disponibilit\u00e0 tramite BGP, come se fossero altri router. Informano quali macchine sono attive in ciascuna posizione affinch\u00e9 le macchine virtuali in una zona possano interagire direttamente con le altre macchine virtuali.<\/p>\n 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.<\/p>\n 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.<\/p>\n Se riassumiamo tutto quanto detto sopra in poche frasi, possiamo dire che il VPC in Yandex.Cloud affronta due importanti compiti:<\/p>\n E per affrontare queste sfide in modo efficace, \u00e8 necessario garantire scalabilit\u00e0 e resilienza a livello di architettura interna, cosa che fa il VPC.<\/p>\n Gradualmente, il VPC acquisisce funzionalit\u00e0; stiamo implementando nuove capacit\u00e0 e cercando di migliorare l'usabilit\u00e0 per gli utenti. Alcune idee vengono enunciate e finiscono nella lista delle priorit\u00e0 grazie ai membri della nostra comunit\u00e0.<\/p>\n Attualmente abbiamo circa questa lista di piani per il prossimo futuro:<\/p>\n Il bilanciatore e la possibilit\u00e0 di cambiare l'indirizzo IP per una macchina virtuale gi\u00e0 creata sono stati inseriti in questo elenco su richiesta degli utenti. A dire il vero, senza un feedback esplicito, ci saremmo presi pi\u00f9 tempo per affrontare queste funzionalit\u00e0. Adesso stiamo gi\u00e0 lavorando sulla questione degli indirizzi.<\/p>\n 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\u00e0 possibile attivare e disattivare un IP pubblico senza ricreare la macchina.<\/p>\n Non esitare a esprimere le tue idee e a sostenere le proposte<\/a> degli altri utenti. Ci aiuti a rendere il Cloud migliore e a ottenere pi\u00f9 rapidamente funzionalit\u00e0 importanti e utili!<\/p>\nChe cos'\u00e8 il VPC?<\/h2>\n
Come appare una rete virtuale dall'esterno<\/h2>\n
![\"Come](\"\/wp-content\/uploads\/2020\/02\/073a0cbac0e733decd8a4e6ffd9570ff.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/b1b7a15912f9c7995663ab9943d473f1.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/73e872a4f6c3e19576db4e4980d62a45.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/cc4ab2c7553d63ef2636924df1575479.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/c2375fd6d0fb7b55ca55787adf505229.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/744ac3bdd2f388bab2597d6fe1519d76.jpeg\")
<\/p>\nCome \u00e8 strutturata una rete virtuale internamente<\/h2>\n
![\"Come](\"\/wp-content\/uploads\/2020\/02\/71cab3ae7f067f165a87e30c60559794.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/222d68fff4b9577f316c8642e846172e.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/4da02ba041dcd886eee212dd8998718c.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/4664bd03793ba394ceda1f8214fa2c16.jpeg\")
<\/p>\n\n
\n
![\"Come](\"\/wp-content\/uploads\/2020\/02\/644cddfa8bce83a501bf4788a21f9588.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/c2c6e443c93f8dedc6a63e4bd3fd7042.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/2139361a9e1837c7bc7f156e8bc36d38.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/1247f20fa2a12f093d7f1d2361d48a02.jpeg\")
<\/p>\n![\"Come](\"\/wp-content\/uploads\/2020\/02\/f70cd562220c7367e29597d8e8b62f81.jpeg\")
<\/p>\nPiani per il futuro prossimo<\/h2>\n
\n
\n