Bună, numele meu este Kostya Kramlikh, sunt dezvoltatorul principal al diviziei Virtual Private Cloud din Yandex.Cloud. Fac rețele virtuale și, după cum ați putea ghici, în acest articol voi vorbi despre dispozitivul Virtual Private Cloud (VPC) în general și despre rețeaua virtuală în special. Și veți afla, de asemenea, de ce noi, dezvoltatorii serviciului, prețuim feedback-ul utilizatorilor noștri. Dar mai întâi lucrurile.
Ce este VPC?
În prezent, există o varietate de opțiuni pentru implementarea serviciilor. Sunt sigur că cineva mai ține serverul sub biroul administratorului, deși sper să fie mai puține astfel de povești.
Acum serviciile încearcă să meargă în cloud-urile publice și aici se ciocnesc cu VPC-urile. VPC este o parte a unui cloud public care leagă utilizatorul, infrastructura, platforma și alte capacități împreună, oriunde s-ar afla, în Cloud-ul nostru sau în afara acestuia. În același timp, VPC vă permite să nu expuneți aceste capacități la Internet în mod inutil, ele rămânând în rețeaua dumneavoastră izolată.
Cum arată o rețea virtuală din exterior?
Prin VPC, înțelegem în primul rând o rețea suprapusă și servicii de rețea, cum ar fi VPNaaS, NATaas, LBaas etc. Și toate acestea funcționează pe lângă o infrastructură de rețea tolerantă la erori, care a fost deja aici, pe Habré.
Să aruncăm o privire mai atentă asupra rețelei virtuale și a dispozitivului acesteia.
Luați în considerare două zone de disponibilitate. Oferim o rețea virtuală - ceea ce am numit VPC. De fapt, definește spațiul de unicitate al adreselor tale „gri”. În cadrul fiecărei rețele virtuale, aveți control complet asupra spațiului de adrese pe care le puteți atribui resurselor de calcul.
Rețeaua este globală. În același timp, este proiectat pe fiecare dintre zonele de disponibilitate sub forma unei entități numite Subnet. Pentru fiecare subrețea, atribuiți un CIDR de dimensiunea 16 sau mai mică. Pot exista mai multe astfel de entități în fiecare zonă de disponibilitate și există întotdeauna o rutare transparentă între ele. Aceasta înseamnă că toate resursele tale din același VPC pot „vorbește” între ele, chiar dacă se află în zone de disponibilitate diferite. „Comunică” fără acces la Internet, prin canalele noastre interne, „gândindu-se” că se află în cadrul aceleiași rețele private.
Diagrama de mai sus arată o situație tipică: două VPC-uri care se intersectează undeva în adrese. Ambele pot fi ale tale. De exemplu, unul pentru dezvoltare, celălalt pentru testare. Pur și simplu pot exista diferiți utilizatori - în acest caz nu contează. Și o mașină virtuală este conectată la fiecare VPC.
Să înrăutățim schema. Puteți face astfel încât o mașină virtuală să fie blocată în mai multe subrețele simultan. Și nu doar așa, ci în diferite rețele virtuale.
În același timp, dacă trebuie să expuneți mașinile la Internet, acest lucru se poate face prin API sau UI. Pentru a face acest lucru, trebuie să configurați traducerea NAT a adresei interne „gri”, la „alb” - public. Nu puteți alege o adresă „albă”, aceasta este atribuită aleatoriu din grupul nostru de adrese. De îndată ce încetați să utilizați IP-ul extern, acesta este returnat în pool. Plătiți doar pentru timpul utilizării adresei „albe”.
De asemenea, este posibil să acordați mașinii acces la Internet folosind o instanță NAT. Puteți direcționa traficul către o instanță printr-un tabel de rutare static. Am oferit un astfel de caz, deoarece utilizatorii au nevoie de el uneori și știm despre el. În consecință, catalogul nostru de imagini conține o imagine NAT special configurată.
Dar chiar și atunci când există o imagine NAT pregătită, configurarea poate fi dificilă. Am înțeles că pentru unii utilizatori aceasta nu este cea mai convenabilă opțiune, așa că în cele din urmă am făcut posibilă activarea NAT pentru subrețeaua dorită cu un singur clic. Această caracteristică este încă în acces de previzualizare închis, unde este testată cu ajutorul membrilor comunității.
Cum este aranjată rețeaua virtuală din interior
Cum interacționează utilizatorul cu rețeaua virtuală? Web-ul arată spre exterior cu API-ul său. Utilizatorul ajunge la API și lucrează cu starea țintă. Prin intermediul API-ului, utilizatorul vede cum trebuie aranjat și configurat totul, în timp ce vede starea, cât de mult diferă starea reală de cea dorită. Aceasta este o poză a utilizatorului. Ce se întâmplă înăuntru?
Scriem starea dorită în baza de date Yandex și mergem la configurarea diferitelor părți ale VPC-ului nostru. Rețeaua de suprapunere din Yandex.Cloud se bazează pe componente selectate ale OpenContrail, care a fost numit recent Tungsten Fabric. Serviciile de rețea sunt implementate pe o singură platformă CloudGate. În CloudGate, am folosit și o serie de componente open source: GoBGP - pentru a accesa informațiile de control, precum și VPP - pentru a implementa un router software care rulează peste DPDK pentru calea datelor.
Tungsten Fabric comunică cu CloudGate prin GoBGP. Spune ce se întâmplă în rețeaua de suprapunere. CloudGate, la rândul său, conectează rețelele suprapuse între ele și cu Internetul.
Acum să vedem cum o rețea virtuală rezolvă problemele de scalare și disponibilitate. Să luăm în considerare un caz simplu. Există o zonă de disponibilitate și două VPC-uri sunt create în ea. Am implementat o instanță Tungsten Fabric și trage câteva zeci de mii de rețele. Rețelele comunică cu CloudGate. CloudGate, așa cum am spus deja, le asigură conectivitatea între ele și cu Internetul.
Să presupunem că este adăugată o a doua zonă de disponibilitate. Ar trebui să eșueze complet independent de primul. Prin urmare, în a doua zonă de disponibilitate, trebuie să instalăm o instanță separată Tungsten Fabric. Acesta va fi un sistem separat care se ocupă de suprapunere și știe puțin despre primul sistem. Și vizibilitatea că rețeaua noastră virtuală este globală, de fapt, creează API-ul nostru VPC. Aceasta este sarcina lui.
VPC1 este mapat la Zona de Disponibilitate B dacă există resurse în Zona de Disponibilitate B care sunt trimise către VPC1. Dacă nu există resurse din VPC2 în zona de disponibilitate B, nu vom materializa VPC2 în această zonă. La rândul său, întrucât resursele din VPC3 există doar în zona B, VPC3 nu există în zona A. Totul este simplu și logic.
Să mergem puțin mai adânc și să vedem cum funcționează o anumită gazdă în Y.Cloud. Principalul lucru pe care vreau să-l remarc este că toate gazdele sunt aranjate în același mod. Facem astfel încât doar minimul necesar de servicii să ruleze pe hardware, restul să ruleze pe mașini virtuale. Construim servicii de ordin superior bazate pe servicii de infrastructură de bază și, de asemenea, folosim Cloud-ul pentru a rezolva unele probleme de inginerie, de exemplu, în cadrul integrării continue.
Dacă ne uităm la o anumită gazdă, putem vedea că există trei componente care rulează pe sistemul de operare gazdă:
- Compute - partea responsabilă cu distribuirea resurselor de calcul pe gazdă.
- VRouter este o parte din Tungsten Fabric care organizează o suprapunere, adică tunelează pachetele printr-un strat de bază.
- VDisk-urile sunt bucăți de virtualizare a stocării.
În plus, serviciile sunt lansate în mașini virtuale: servicii de infrastructură cloud, servicii de platformă și capacități clienți. Capacitățile clienților și serviciile platformei merg întotdeauna la suprapunere prin VRouter.
Serviciile de infrastructură pot rămâne în suprapunere, dar practic doresc să lucreze în stratul de bază. Ele sunt înfipte în strat de bază cu ajutorul SR-IOV. De fapt, tăiem cardul în plăci de rețea virtuale (funcții virtuale) și le împingem în mașinile virtuale de infrastructură pentru a nu pierde performanța. De exemplu, același CloudGate este lansat ca una dintre aceste mașini virtuale de infrastructură.
Acum că am descris sarcinile globale ale rețelei virtuale și structura componentelor de bază ale cloud-ului, să vedem cum interacționează exact diferitele părți ale rețelei virtuale între ele.
Distingem trei straturi în sistemul nostru:
- Config Plane - setează starea țintă a sistemului. Acesta este ceea ce utilizatorul configurează prin intermediul API-ului.
- Control Plane - oferă semantică definită de utilizator, adică aduce starea Data Plane la ceea ce a fost descris de utilizator în Config Plane.
- Plan de date - procesează direct pachetele utilizatorului.
După cum am spus mai sus, totul începe cu faptul că utilizatorul sau serviciul platformei interne vine la API și descrie o anumită stare țintă.
Această stare este scrisă imediat în baza de date Yandex, returnează ID-ul operațiunii asincrone prin API și pornește mașina noastră internă pentru a returna starea dorită de utilizator. Sarcinile de configurare merg la controlerul SDN și îi spune Tungsten Fabric ce trebuie să facă în suprapunere. De exemplu, ei rezervă porturi, rețele virtuale și altele asemenea.
Config Plane în Tungsten Fabric trimite starea necesară la Control Plane. Prin intermediul acestuia, Config Plane comunică cu gazdele, spunând exact ce se va învârti asupra lor în curând.
Acum să vedem cum arată sistemul pe gazde. Mașina virtuală are un adaptor de rețea conectat la VRouter. VRouter este un modul de bază Tungsten Fabric care analizează pachetele. Dacă există deja un flux pentru un pachet, modulul îl procesează. Dacă nu există flux, modulul face așa-numitul punting, adică trimite un pachet către procesul usermod. Procesul analizează pachetul și fie răspunde la el însuși, cum ar fi DHCP și DNS, fie îi spune VRouter ce să facă cu el. După aceea, VRouter poate procesa pachetul.
În plus, traficul dintre mașinile virtuale din aceeași rețea virtuală decurge transparent, nu este direcționat către CloudGate. Gazdele pe care sunt implementate mașinile virtuale comunică direct între ele. Traficul în tunel și îl transmit unul pentru celălalt prin stratul de bază.
Planurile de control comunică între ele între zonele de disponibilitate prin BGP, ca și cu un alt router. Ei spun ce mașini sunt în funcțiune, astfel încât VM-urile dintr-o zonă să poată comunica direct cu alte VM.
Și Control Plane comunică cu CloudGate. În mod similar, raportează unde și ce mașini virtuale sunt ridicate, ce adrese au. Acest lucru vă permite să direcționați traficul extern și traficul de la echilibratori către aceștia.
Traficul care părăsește VPC-ul vine la CloudGate, la calea datelor, unde VPP-ul cu plugin-urile noastre este rapid stricat. Apoi, traficul este declanșat fie către alte VPC-uri, fie spre exterior, către routere de frontieră care sunt configurate prin Planul de control al CloudGate însuși.
Planuri pentru viitorul apropiat
Dacă rezumăm tot ce s-a spus mai sus în câteva propoziții, putem spune că VPC în Yandex.Cloud rezolvă două sarcini importante:
- Oferă izolare între diferiți clienți.
- Combină resurse, infrastructură, servicii de platformă, alte cloud-uri și on-premise într-o singură rețea.
Și pentru a rezolva bine aceste probleme, trebuie să oferiți scalabilitate și toleranță la erori la nivelul arhitecturii interne, ceea ce face VPC.
Treptat, VPC dobândește funcții, implementăm noi funcții, încercăm să îmbunătățim ceva în ceea ce privește confortul utilizatorului. Unele idei sunt exprimate și ajung pe lista de priorități datorită membrilor comunității noastre.
În prezent, avem următoarea listă de planuri pentru viitorul apropiat:
- VPN ca serviciu
- Instanțele DNS private sunt imagini pentru configurarea rapidă a mașinilor virtuale cu un server DNS preconfigurat.
- DNS ca serviciu.
- Echilibrator de sarcină intern.
- Adăugarea unei adrese IP „albe” fără a recrea mașina virtuală.
Echilibratorul și capacitatea de a schimba adresa IP pentru o mașină virtuală deja creată au fost pe această listă la cererea utilizatorilor. Sincer să fiu, fără feedback explicit, ne-am fi preluat aceste funcții puțin mai târziu. Și așa lucrăm deja la problema adreselor.
Inițial, o adresă IP „albă” putea fi adăugată doar la crearea unei mașini. Dacă utilizatorul a uitat să facă acest lucru, mașina virtuală trebuia recreată. Același și, dacă este necesar, eliminați IP-ul extern. În curând va fi posibil să porniți și să dezactivați IP-ul public fără a fi nevoie să recreați mașina.
Simțiți-vă liber să vă exprimați alți utilizatori. Ne ajutați să îmbunătățim Cloud-ul și să obținem funcții importante și utile mai rapid!
Sursa: www.habr.com