Bună, mă numesc Kostya Kramlih, sunt dezvoltator principal în departamentul Virtual Private Cloud de la Yandex.Cloud. Mă ocup de rețeaua virtuală și, după cum vă puteți imagina, în acest articol voi vorbi despre cum este organizat Virtual Private Cloud (VPC) în general și despre rețeaua virtuală în special. De asemenea, veți afla de ce noi, dezvoltatorii serviciului, apreciem feedback-ul din partea utilizatorilor noștri. Dar să le luăm pe rând.
Ce este VPC?
În zilele noastre, există diverse opțiuni pentru desfășurarea serviciilor. Sunt sigur că cineva încă mai ține un server sub biroul administratorului, deși sper că astfel de povești devin din ce în ce mai rare.
În prezent, serviciile încearcă să migreze către облаки publice și tocmai aici se întâlnesc cu VPC. VPC este o parte a unui nor public care leagă resursele utilizatorilor, infrastructurii, platformelor și alte capacități într-un singur întreg, indiferent de locația lor, fie în norul nostru, fie în afara acestuia. În același timp, VPC permite ca aceste resurse să nu fie expuse pe internet fără necesitate, rămânând în interiorul rețelei dumneavoastră izolate.
Cum arată rețeaua virtuală din exterior
Prin VPC înțelegem în primul rând o rețea overlay și servicii de rețea, cum ar fi VPNaaS, NATaas, LBaas etc. Și toate acestea funcționează deasupra infrastructurii de rețea rezistente la erori, despre care am discutat un articol excelent aici, pe Habr.
Să examinăm mai îndeaproape rețeaua virtuală și structura sa.
Să luăm în considerare două zone de disponibilitate. Oferim o rețea virtuală – ceea ce am numit VPC. În realitate, aceasta definește spațiul unic al adreselor dumneavoastră „gri”. În cadrul fiecărei rețele virtuale, aveți control total asupra spațiului de adrese pe care îl puteți aloca resurselor de calcul.
Rețeaua este globală. Aceasta se projecțează asupra fiecărei zone de disponibilitate sub forma unei entități numite Subnet. Pentru fiecare Subnet, îi alocați un CIDR de 16 sau mai puțin. În fiecare zonă de disponibilitate poate exista mai mult de o astfel de entitate, având întotdeauna un routing transparent între ele. Asta înseamnă că toate resursele dvs. din interiorul unei VPC pot „comunica” între ele, chiar dacă se află în zone de disponibilitate diferite. „Comunicarea” se face fără a ieși pe internet, prin intermediul canalelor noastre interne, „crezând” că se află în interiorul unei rețele private.
În schema de mai sus este ilustrată o situație tipică: două VPC-uri care se intersectează pe adrese undeva. Ambele pot aparține dvs. De exemplu, una pentru dezvoltare, alta pentru testare. Pot exista pur și simplu utilizatori diferiți – în acest caz nu este important. Și în fiecare VPC este conectată câte o mașină virtuală.
Să complicăm schema. Se poate face astfel încât o mașină virtuală să fie conectată simultan la mai multe Subnet. Și nu oricum, ci în rețele virtuale diferite.
În plus, dacă trebuie să expuneți mașinile pe internet, acesta poate fi realizat prin API sau UI. Pentru aceasta, este necesară configurarea unei traduceri NAT a adresei dvs. „gri”, interne, într-o adresă „albă” – publică. Nu puteți alege adresa „albă”, aceasta este alocată aleatoriu din pool-ul nostru de adrese. Odată ce nu mai folosiți IP-ul extern, acesta revine în pool. Plătiți doar pentru timpul utilizării adresei „albe”.
Există, de asemenea, posibilitatea de a oferi unei mașini acces la internet prin intermediul unei instanțe NAT. Pe instanță se poate ruga traficul printr-un tabel de rutare static. Am prevăzut un astfel de caz, deoarece este necesar pentru unii utilizatori, și știm despre asta. Prin urmare, în catalogul nostru de imagini există o imagine NAT special configurată.
Dar chiar și atunci când există o imagine NAT gata preparată, configurarea poate fi complexă. Am înțeles că pentru unii utilizatori această opțiune nu este cea mai convenabilă, de aceea am creat în cele din urmă posibilitatea de activare a NAT pentru Subnet-ul dorit cu un singur clic. Această caracteristică este încă în acces preview restricționat, fiind testată cu ajutorul participanților din comunitate.
Cum este structurată o rețea virtuală din interior
Cum interacționează utilizatorul cu rețeaua virtuală? Rețeaua privește în exterior prin API-ul său. Utilizatorul accesează API-ul și lucrează cu starea dorită. Prin API, utilizatorul vede cum ar trebui să fie organizat și configurat totul, având în același timp o imagine de ansamblu a stării curente comparativ cu starea dorită. Aceasta este perspectiva utilizatorului. Și ce se întâmplă în interior?
Înregistrăm starea dorită în Yandex Database și mergem să configurăm diferitele părți ale VPC-ului nostru. Rețeaua overlay din Yandex.Cloud se bazează pe componentele selectate din OpenContrail, care recent a fost redenumită Tungsten Fabric. Serviciile de rețea sunt implementate pe o platformă unificată numită CloudGate. În CloudGate am utilizat și noi un număr de componente open source: GoBGP – pentru accesarea informațiilor de control, precum și VPP – pentru implementarea unui router software care funcționează pe DPDK pentru path-ul de date.
Tungsten Fabric comunică cu CloudGate prin GoBGP. Aceasta transmite ce se întâmplă în rețeaua overlay. CloudGate, la rândul său, leagă rețelele overlay între ele și cu internetul.
Acum să vedem cum rețeaua virtuală abordează problemele de scalabilitate și disponibilitate. Să considerăm un caz simplu. Avem o zonă de disponibilitate în care sunt create două VPC-uri. Am lansat un instanțiu de Tungsten Fabric, care poate gestiona câteva zeci de mii de rețele. Rețelele sunt conectate la CloudGate. CloudGate, așa cum am spus, asigură conectivitatea între ele și către internet.
Să presupunem că adăugăm o a doua zonă de disponibilitate. Aceasta trebuie să funcționeze complet independent de prima. Prin urmare, în a doua zonă de disponibilitate trebuie să instalăm un instanțiu separat de Tungsten Fabric. Aceasta va fi un sistem separat, care se ocupă de overlay și cunoaște foarte puțin despre prima sistem. Și vizibilitatea că rețeaua noastră virtuală este globală este de fapt creată de API-ul nostru VPC. Aceasta este sarcina sa.
VPC1 se proiectează în zona de disponibilitate B, dacă în zona de disponibilitate B există resurse care se conectează la VPC1. Dacă nu există resurse din VPC2 în zona de disponibilitate B, nu vom materializa VPC2 în această zonă. În schimb, deoarece resursele din VPC3 există doar în zona B, VPC3 nu va exista în zona A. Totul este simplu și logic.
Să mergem puțin mai în profunzime și să vedem cum este structurat un host specific în Я.Облаке. Principalul lucru de menționat este că toate hosturile sunt organizate la fel. Facem în așa fel încât doar minimul necesar de servicii să ruleze pe «hardware», iar toate celelalte să funcționeze pe virtuálne mašini. Construim servicii de nivel superior pe baza serviciilor infrastructurale de bază și utilizăm Cloud pentru a rezolva unele sarcini inginerești, de exemplu, în cadrul Continuous Integration.
Dacă ne uităm la un host specific, vom vedea că în sistemul de operare al hostului rulează trei componente:
- Compute – partea care se ocupă cu distribuția resurselor de calcul pe host.
- VRouter – partea Tungsten Fabric care organizează overlay-ul, adică tunelizează pachetele prin underlay.
- VDisk – aceste sunt fragmente de virtualizare a stocării.
În plus, în virtuálne mašini rulează servicii: servicii infrastructurale ale Cloud-ului, servicii de platformă și capacitățile clienților. Capacitățile clienților și serviciile de platformă trec întotdeauna prin overlay prin VRouter.
Serviciile infrastructurale pot fi integrate în overlay, dar în principal doresc să funcționeze în underlay. În underlay, se integrează cu ajutorul SR-IOV. De fapt, împărțim placa în carduri de rețea virtuale (funcții virtuale) și le inserăm în mașinile virtuale infrastructurale pentru a nu pierde performanța. De exemplu, acel CloudGate este lansat ca una dintre aceste mașini virtuale infrastructurale.
Acum, când am descris sarcinile globale ale rețelei virtuale și structura componentelor de bază ale cloud-ului, să vedem cum interacționează diferitele părți ale rețelei virtuale între ele.
Între noi, sunt trei straturi în sistemul nostru:
- Config Plane – stabilește starea țintă a sistemului. Acesta este ceea ce configurează utilizatorul prin API.
- Control Plane – asigură semantica specificată de utilizator, adică aduce starea Data Plane la ceea ce a fost descris de utilizator în Config Plane.
- Data Plane – procesează direct pachetele utilizatorului.
Așa cum am spus mai sus, totul începe cu faptul că utilizatorul sau un serviciu platformă internă ajunge la API și descrie o anumită stare țintă.
Această stare este imediat înregistrată în Yandex Database, returnează prin API ID-ul operațiunii asincrone și activează mașinăria noastră internă pentru a oferi starea dorită de utilizator. Sarcinile de configurare sunt trimise la SDN-controller și comunică lui Tungsten Fabric ce trebuie făcut în overlay. De exemplu, acestea rezervă porturi, rețele virtuale și așa mai departe.
Config Plane din Tungsten Fabric livrează starea solicitată Control Plane-ului. Prin intermediul acestuia, Config Plane comunică cu gazdele, explicându-le ce va rula pe ele în curând.
Acum să vedem cum arată sistemul pe gazde. În mașina virtuală există un anumit adaptor de rețea, conectat la VRouter. VRouter este modulul de bază al Tungsten Fabric, care analizează pachetele. Dacă pentru un anumit pachet există deja un flow, modulul acesta îl procesează. Dacă nu există flow, modulul face așa-numitul punting, adică trimite pachetul la procesul din modul utilizator. Procesul analizează pachetul și fie răspunde el însuși, cum ar fi în cazul DHCP și DNS, fie spune lui VRouter ce să facă cu acesta. După aceea, VRouter poate procesa pachetul.
Apoi, traficul dintre mașinile virtuale din cadrul unei rețele virtuale circulă transparent, el nu este direcționat către CloudGate. Gazdele pe care sunt desfășurate mașinile virtuale comunică direct între ele. Ele tuneliză traficul și îl transmit reciproc prin overlay.
Control Plane comunică între ele între zonele de disponibilitate prin BGP, ca și cum ar fi cu un alt router. Ele comunică ce mașini sunt unde ridicate, pentru ca mașinile virtuale dintr-o zonă să poată interacționa direct cu alte mașini virtuale.
De asemenea, Control Plane comunică cu CloudGate. De asemenea, informează unde și ce mașini virtuale sunt ridicate, care sunt adresele lor. Acest lucru permite direcționarea traficului extern și a traficului de la echilibratoarele de sarcină către ele.
Traficul care iese din VPC ajunge la CloudGate, în data path, unde este procesat rapid de VPP cu pluginurile noastre. Apoi, traficul este trimis fie către alte VPC-uri, fie în exterior, către routerele de frontieră, care sunt configurate prin Control Plane-ul CloudGate-ului.
Planuri pentru viitorul apropiat
Dacă generalizăm toate cele spuse mai sus în câteva propoziții, putem spune că VPC în Yandex.Cloud rezolvă două probleme importante:
- Asigură izolația între diferiți clienți.
- Unește resursele, infrastructura, serviciile platformei, alte clouduri și soluțiile on-premise într-o rețea unitară.
Pentru a rezolva aceste probleme într-un mod eficient, trebuie să asigurăm scalabilitate și reziliență la nivelul arhitecturii interne, ceea ce face VPC.
Treptat, VPC se îmbogățește cu funcții, implementăm noi caracteristici și încercăm să îmbunătățim aspectele legate de utilizator. Unele idei sunt exprimente și ajung în lista de priorități datorită participanților din comunitatea noastră.
Acum avem cam această listă de planuri pentru viitorul apropiat:
- VPN ca serviciu.
- Instanțe DNS private – imagini pentru configurarea rapidă a mașinilor virtuale cu servere DNS configurate dinainte.
- DNS ca serviciu.
- Încărcător intern de echilibrare.
- Adăugarea unei adrese IP „albe” fără a recrea mașina virtuală.
Încărcătorul de echilibrare și posibilitatea de a schimba adresa IP pentru o mașină virtuală deja creată s-au regăsit pe această listă la cererea utilizatorilor. Să fiu sincer, fără un feedback clar, ne-am ocupa de aceste funcții mai târziu. Însă acum deja lucrăm la problema adreselor.
Inițial, o adresă IP „albă” putea fi adăugată doar la crearea mașinii. Dacă utilizatorul uita să facă acest lucru, mașina virtuală trebuia recreată. La fel și în cazul în care era necesară eliminarea IP-ului extern. În curând, va fi posibil să activați și să dezactivați IP-ul public fără a recrea mașina.
Nu ezitați să exprimați ideile și să susțineți propunerile altor utilizatori. Ne ajutați să îmbunătățim Cloud-ul și să obțineți mai repede funcții importante și utile!
Sursa: habr.com
