![\"Come](\"\/wp-content\/uploads\/2020\/02\/62b3d222c1911fb28a345defdd81135c.jpeg\")
<\/p>\nCiao, 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\u00f2 del funzionamento del Virtual Private Cloud (VPC) in generale e delle reti virtuali in particolare. Inoltre, scoprirai perch\u00e9 noi, sviluppatori del servizio, valorizziamo il feedback dei nostri utenti. Ma andiamo con ordine.<\/p>\n
<\/p>\n
<\/a><\/p>\n 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.<\/p>\n Attualmente, i servizi tendono a spostarsi verso i cloud pubblici, e qui entrano in gioco i VPC. Il VPC \u00e8 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.<\/p>\n 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\u00e0 parlato ottimo articolo<\/a> qui su Habr.<\/p>\n Esploriamo la rete virtuale e la sua struttura pi\u00f9 da vicino.<\/p>\n Consideriamo due zone di disponibilit\u00e0. Offriamo una rete virtuale \u2013 ci\u00f2 che abbiamo chiamato VPC. In effetti, definisce lo spazio di unicit\u00e0 dei tuoi indirizzi 'grigi'. All'interno di ogni rete virtuale gestisci completamente lo spazio degli indirizzi che puoi assegnare alle risorse di calcolo.<\/p>\n La rete \u00e8 globale. Viene proiettata su ciascuna delle zone di disponibilit\u00e0 come entit\u00e0 chiamata Subnet. A ogni Subnet si assegna un CIDR di dimensione 16 o inferiore. In ogni zona di disponibilit\u00e0 possono esserci pi\u00f9 di una di queste entit\u00e0, con un routing sempre trasparente tra di esse. Ci\u00f2 significa che tutte le tue risorse all'interno di una VPC possono \"comunicare\" tra loro, anche se si trovano in diverse zone di disponibilit\u00e0. \"Comunicare\" senza uscire su Internet, attraverso i nostri canali interni, \"credendo\" di trovarsi all'interno di una rete privata.<\/p>\n Nello schema sopra \u00e8 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 \u2013 in questo caso non importa. In ogni VPC \u00e8 inserita una macchina virtuale.<\/p>\n Complichiamo lo schema. \u00c8 possibile configurare una macchina virtuale per essere connessa a pi\u00f9 Subnet contemporaneamente. E non \u00e8 un semplice caso, ma in diverse reti virtuali.<\/p>\n Per utilizzare le macchine su Internet, puoi farlo attraverso l'API o l'interfaccia utente. \u00c8 necessario configurare la traslazione NAT del tuo indirizzo \"grigio\", interno, in un indirizzo \"bianco\" \u2013 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\".<\/p>\n C'\u00e8 anche la possibilit\u00e0 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\u00e9 sappiamo che pu\u00f2 essere necessario per gli utenti. Pertanto, nel nostro catalogo di immagini, c'\u00e8 un'immagine NAT configurata appositamente.<\/p>\n Anche quando esiste un'immagine NAT pronta, la configurazione pu\u00f2 essere complessa. Abbiamo compreso che per alcuni utenti questa non \u00e8 la soluzione pi\u00f9 comoda, quindi alla fine abbiamo reso possibile attivare NAT per la sottorete desiderata con un solo clic. Questa funzione \u00e8 attualmente in anteprima chiusa, testata con la partecipazione della comunit\u00e0.<\/p>\n 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\u00f2 vedere come tutto dovrebbe essere configurato, e visualizza lo stato attuale rispetto a quello desiderato. Questa \u00e8 la visione dell'utente. E cosa succede all'interno?<\/p>\n Registriamo lo stato desiderato nel Yandex Database e procediamo a configurare diverse parti della nostra VPC. La rete overlay in Yandex.Cloud \u00e8 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.<\/p>\n 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.<\/p>\n Ora diamo un'occhiata a come una rete virtuale affronta le sfide di scalabilit\u00e0 e disponibilit\u00e0. Consideriamo un caso semplice. Abbiamo una zona di disponibilit\u00e0 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\u00e0 detto, CloudGate assicura la connettivit\u00e0 tra di loro e con Internet.<\/p>\n Supponiamo di aggiungere una seconda zona di disponibilit\u00e0. Questa deve poter guastarsi completamente indipendentemente dalla prima. Pertanto, nella seconda zona di disponibilit\u00e0 dobbiamo installare un'istanza separata di Tungsten Fabric. Sar\u00e0 un sistema autonomo, che si occupa di overlay e sa poco o nulla del primo sistema. La visibilit\u00e0 della nostra rete virtuale globale \u00e8 fornita dal nostro API VPC. Questa \u00e8 la sua funzione.<\/p>\n VPC1 \u00e8 progettato per la zona di disponibilit\u00e0 B, se nella zona di disponibilit\u00e0 B ci sono risorse collegate a VPC1. Se non ci sono risorse da VPC2 nella zona di disponibilit\u00e0 B, VPC2 non verr\u00e0 materializzato in questa zona. Allo stesso modo, 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 per vedere come \u00e8 strutturato un host specifico in Y.Cloud. La cosa principale da notare \u00e8 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<\/a>. 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.<\/p>\n Se guardiamo a un host specifico, vediamo che nel sistema operativo dell'host girano tre componenti:<\/p>\n Inoltre, sono macchine virtuali<\/a> in esecuzione i servizi: servizi infrastrutturali del Cloud, servizi di piattaforma e capacit\u00e0 dei clienti. Le capacit\u00e0 dei clienti e i servizi di piattaforma si muovono sempre nell'overlay attraverso il VRouter.<\/p>\n 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 \u00e8 avviato 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 Nella nostra sistema, identifichiamo tre strati:<\/p>\n 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.<\/p>\n 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.<\/p>\n 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\u00e0 eseguito di l\u00ec a poco.<\/p>\n Vediamo ora come appare il sistema sugli host. In macchina virtuale<\/a> c'\u00e8 un certo adattatore di rete, collegato a VRouter. VRouter \u00e8 il modulo centrale di Tungsten Fabric che analizza i pacchetti. Se per un certo pacchetto esiste gi\u00e0 un flow, il modulo lo elabora. Se non c'\u00e8 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\u00f2, VRouter pu\u00f2 elaborare il pacchetto.<\/p>\n Il traffico tra le macchine virtuali all'interno della stessa rete virtuale \u00e8 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.<\/p>\n Il Control Plane comunica tra le zone di disponibilit\u00e0 via BGP, proprio come fa con un altro router. Esso informa su quali macchine sono attive in ogni area, permettendo cos\u00ec alle macchine virtuali di una zona di interagire direttamente con quelle di un'altra zona.<\/p>\n 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.<\/p>\n 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.<\/p>\n In sintesi, si pu\u00f2 affermare che il VPC in Yandex.Cloud svolge due compiti fondamentali:<\/p>\n Per affrontare bene queste sfide, \u00e8 necessario garantire scalabilit\u00e0 e resilienza a livello di architettura interna, e questo \u00e8 esattamente ci\u00f2 che fa il VPC.<\/p>\n Gradualmente, il VPC si arricchisce di funzionalit\u00e0, implementiamo nuove opportunit\u00e0 e ci impegniamo a migliorare l'esperienza degli utenti. Alcune idee vengono sollevate e finiscono nella lista delle priorit\u00e0 grazie ai membri della nostra comunit\u00e0.<\/p>\n Attualmente abbiamo circa questo piano per il prossimo futuro:<\/p>\n Il bilanciatore e la possibilit\u00e0 di cambiare l'indirizzo IP per una macchina virtuale gi\u00e0 creata si sono trovati in questo elenco su richiesta degli utenti. A essere sinceri, senza un feedback chiaro ci saremmo occupati di queste funzionalit\u00e0 un po' pi\u00f9 tardi. Ora stiamo gi\u00e0 lavorando sull'argomento degli indirizzi.<\/p>\n 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\u00e0 di rimuovere un IP pubblico. Presto sar\u00e0 possibile attivare e disattivare un IP pubblico senza dover ricreare la macchina.<\/p>\n Non esitate a esprimere le vostre idee e a sostenere le proposte<\/a> degli altri utenti. Ci aiutare a rendere il Cloud migliore e a ottenere importanti e utili funzionalit\u00e0 pi\u00f9 rapidamente!<\/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 internamente una rete virtuale<\/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 prossimo futuro<\/h2>\n
\n
\n