Tere, minu nimi on Kostya Kramlih, ma olen Yandex.Cloudi Virtuaalse Iseseisva Kliendi (VPC) arendustiimi juhtiv arendaja. Tegelema virtuaalsete võrkudega ja, nagu võib arvata, räägin selles artiklis, kuidas Virtuaalne Iseseisev Kliendi (VPC) süsteem laiemalt ja virtuaalne võrk spetsiaalselt toimib. Lisaks saate teada, miks meie, teenuse arendajad, hindame tagasisidet meie kasutajatelt. Aga alustame algusest.
Mis on VPC?
Tänapäeval on teenuste üles seadmiseks palju erinevaid võimalusi. Olen kindel, et keegi hoiab endiselt serverit administraatori laua all, kuigi loodan, et selliseid lugusid on järjest vähem.
Praegu püüavad teenused kolida avalikesse pilvedesse ja seal nad puutuvad kokku VPC-ga. VPC on osa avalikust pilvest, mis ühendab omavahel kasutajate, infrastruktuuri, platvormide ja teiste ressurside jõu, ükskõik kus nad asuvad, meie pilves või selle väljaspool. Samal ajal võimaldab VPC mitte avaldada neid ressursse internetis, need jäävad teie isoleeritud võrgu piiridesse.
Kuidas näeb virtuaalne võrk välja väljastpoolt
VPC all mõtleme me eelkõige overlay-võrgule ja võrguteenustele, nagu VPNaaS, NATaas, LBaas jne. Ning kõik see töötab üle usaldusväärse võrginfrastruktuuri, mis on juba suurepärane artikkel siin, Habr's.
Vaadakem lähemalt virtuaalset võrku ja selle struktuuri.
Käsitleme kahte kättesaadavust. Pakume virtuaalset võrku – seda, mida oleme nimetanud VPC-ks. Tegelikult määratleb see teie "hallide" aadresside unikaalsuse ruumi. Igas virtuaalses võrgus haldate täielikult aadressiruumi, mida saate määrata arvutusressurssidele.
Võrk on globaalne. Samas projitseerib see end igasse kättesaadavuse tsooni substantsi nimega Subnet. Iga Subneti jaoks määrate te teatud CIDR-i, mille suurus on 16 või vähem. Igas kättesaadavuse tsoonis võib olla rohkem kui üks selline substants, olles samas alati läbipaistva suunamisega. See tähendab, et kõik teie ressursid ühes VPC-s saavad omavahel "suhelda", isegi kui nad asuvad erinevates kättesaadavuse tsoonides. "Suhelda" ilma internetti minemata, meie sisekanalite kaudu, arvates, et nad asuvad ühes privaatvõrgus.
Ülaltoodud skeemidel on kujutatud tüüpiline olukord: kaks VPC-d, mis kuskil kattuvad aadressidega. Mõlemad võivad kuuluda teile. Näiteks üks arenduseks, teine testimiseks. Võib olla ka lihtsalt erinevad kasutajad – sel juhul pole see oluline. Ja igasse VPC-sse on ühendatud üks virtuaalne masin.
Täitke skeemi. Saate teha nii, et üks virtuaalne masin on ühendatud mitme Subnetiga korraga. Ja mitte lihtsalt nii, vaid erinevates virtuaalsetes võrkudes.
Kui peate masinad internetti viima, saate seda teha API või UI kaudu. Selleks tuleb seadistada teie "hall", siseaadressi NAT-ülekanne "valgesse" – avalikku aadressi. Te ei saa valida "valget" aadressi, see määratakse juhuslikult meie aadresside hulgast. Kui te enam ei kasuta välist IP-d, naaseb see hulka. Te tasute ainult "valge" aadressi kasutamise aja eest.
Samuti on võimalik anda masinale interneti juurdepääs NAT-instrumendi kaudu. Instrumendi kaudu saab suunata liiklust staatilise marsruuditabeli kaudu. Oleme sellise võimaluse ette näinud, kuna see on mõnel kasutajal vajalik, ja me sellest teame. Seetõttu on meie pildikataloogis spetsiaalselt konfigureeritud NAT-pilt.
Kuid isegi kui NAT-pilt on valmis, võib seadistamine olla keeruline. Me mõistsime, et mõne kasutaja jaoks pole see kõige mugavam variant, seetõttu lõime lõpuks võimaluse NAT-i ühe klikiga aktiveerida vajalikus alamsüsteemis. See funktsioon on praegu veel suletud eelvaates, kus seda testitakse kogukonna liikmete abiga.
Kuidas virtuaalne võrk seestpoolt on üles ehitatud
Kuidas suudab kasutaja suhelda virtuaalse võrguga? Võrk vaatab väljapoole oma API kaudu. Kasutaja pöördub API poole ja töötab sihtseisundiga. Through API, the user sees what everything should look like and be configured, while also seeing the status of how much the actual state differs from the desired one. See on kasutaja pilt. Aga mis toimub seestpoolt?
Salvestame soovitud seisundi Yandex Database'i ja hakkame konfigureerima erinevaid osi meie VPC-st. Yandex.Cloudi overlay-võrk on üles ehitatud valitud komponentide OpenContraili põhjal, mis on hiljuti tuntud kui Tungsten Fabric. Võrguteenused on rakendatud ühel platvormil CloudGate. CloudGate'is kasutasime ka teatud hulga avatud lähtekoodiga komponente: GoBGP kontrollinfoks ja VPP programmipõhise ruuteri rakendamiseks, mis töötab DPDK peal andmete marsruudistamiseks.
Tungsten Fabric suhtleb CloudGate'iga GoBGP kaudu. Räägib, mis toimub overlay-võrgus. CloudGate omakorda seob overlay-võrgud omavahel ja internetiga.
Nüüd vaatame, kuidas virtuaalne võrk lahendab skaleerituse ja saadavuse probleeme. Vaatame lihtsat juhtumit. On üks saadavusala ja seal on loodud kaks VPC-d. Oleme paigaldanud ühe Tungsten Fabric'i instantsi, mis haldab mitukümmend tuhat võrguhüpet. Need võrgud on ühendatud CloudGate'iga. CloudGate, nagu juba mainitud, tagab nende omavahelise ühenduse ja internetiga.
Oletame, et lisandub teine saadavusala. See peab olema täiesti sõltumatu esimesest. Seega peame teises saadavusalas seadma üles eraldi Tungsten Fabric'i instantsi. See saab olema eraldi süsteem, mis tegeleb overlay'ga ja teab vähe esimesest süsteemist. Ja nähtavus, et meie virtuaalne võrk on globaalne, tuleneb meie VPC API-st. See on tema ülesanne.
VPC1 projitseeritakse saadavusala B, kui saadavusala B-s on ressursid, mis on ühendatud VPC1-ga. Kui ressursid VPC2-st ei asu saadavusala B-s, ei materialiseeri me VPC2 selles alas. Vastupidi, kuna ressursid VPC3-st eksisteerivad ainult alal B, ei ole VPC3-alal A. Kõik on lihtne ja loogiline.
Uurime veidi lähemalt, kuidas on konkreetne server korraldatud Y. Cloudis. Peamine, mida tahaksin märkida, on see, et kõik serverid on sarnased. Tagame, et ainult hädavajalikud teenused töötavad riistvaral, kõik teised toimivad virtuaalmasinatel. Loome kõrgema taseme teenuseid põhiteenuste põhjal ning kasutame Cloudi mõnede inseneriteenuste lahendamiseks, näiteks pidevas integreerimises.
Kui vaatame konkreetset serverit, näeme, et serveri operatsioonisüsteemis töötavad kolm koostisosad:
- Compute – osa, mis vastutab arvutusressursside jaotamise eest serveris.
- VRouter – osa Tungsten Fabricist, mis organiseerib overlay, st tunnelib pakette underlay kaudu.
- VDisk – need on virtualiseeritud andmesalvestuse osad.
Lisaks sellele on virtuaalmasinatel käivitatud teenused: Cloudi infrastruktuuri teenused, platvormiteenused ja kliendivõimsused. Kliendivõimsused ja platvormiteenused liiguvad alati ooverlay kaudu VRouteri kaudu.
Infrastruktuuri teenuseid saab ühendada overlay'ga, kuid peamiselt tahavad nad töötada just underlay's. Underlay'sse ühendatakse need SR-IOV abil. Tegelikult jagame kaardi virtuaalseteks võrgukaartideks (virtuaalsed funktsioonid) ja paneme need infrastruktuuri virtuaalmasinatesse, et mitte kaotada jõudlust. Näiteks on see sama CloudGate tuvastatud ühe sellise infrastruktuuri virtuaalmasina nime all.
Nüüd, kui oleme kirjeldanud virtuaalvõrgu globaalseid ülesandeid ja pilve põhikomponente, vaatame, kuidas erinevad virtuaalvõrgu osad omavahel suhtlevad.
Meie süsteemis eristame kolme kihti:
- Config Plane – määrab süsteemi soovitud oleku. See on see, mida kasutaja seadistab API kaudu.
- Control Plane – tagab kasutaja määratud semantika, viies Data Plane'i oleku selliseks, nagu see on kasutaja poolt Config Plane'is kirjeldatud.
- Data Plane – töötleb otseselt kasutaja pakette.
Kuidas ma juba eespool mainisin, kõik algab sellest, et kasutaja või sisemine platvormi teenus pöördub API poole ja kirjeldab kindlat soovitud olekut.
See olek kohe salvestatakse Yandex Database'i, tagastab API kaudu asünkroonse operatsiooni ID ja käivitab meie sisemise mehhanismi, et anda kasutaja soovitud olek. Konfiguratsioonitööd edastatakse SDN-kontrollerisse ja räägivad Tungsten Fabric'ile, mida tuleb overlay's teha. Näiteks reserveeritakse sadamad, virtuaalsed võrgued ja muud sarnased asjad.
Config Plane Tungsten Fabric'is edastab Control Plane'ile nõutud oleku. Selle kaudu suhtleb Config Plane ka hostidega, teavitades neid sellest, mis varsti nende peal käivitub.
Nüüd vaatame, kuidas süsteem hostides välja näeb. Seal virtuaalmasinas on mingi võrgukaart, mis on ühendatud VRouter'iga. VRouter on Tungsten Fabric'i põhikomponent, mis jälgib pakette. Kui mõne paketi jaoks on juba flow olemas, töötleb moodul seda. Kui flow't ei ole, teeb moodul nn punting'i, saatmise paketi kasutajaprotsessi. Protsess analüüsib paketti ja vastab sellele ise, nagu näiteks DHCP ja DNS, või ütleb VRouter'ile, mida sellega teha. Pärast seda saab VRouter paketti töödelda.
Edasi liiklev liiklus virtuaalmasinate vahel samas virtuaalses võrgustikus on läbipaistmatu; see ei suunata CloudGate'i. Hostid, millel virtuaalmasinad on välja arendatud, suhtlevad omavahel otse. Nad tunneliseerivad liiklust ja suunavad selle üksteisele läbi alampiiri.
Kontrollikava suhtleb omavahel saadetuste alade vahel BGP kaudu, nagu teise ruuteriga. Nad jagavad teavet selle kohta, millised masinad kus asuvad, et virtuaalmasinad ühes piirkonnas saaksid otse suhelda teiste virtuaalmasinatega.
Samuti suhtleb Kontrollikava CloudGate'iga. See edastab teavet, kus ja millised virtuaalmasinad on välja arendatud ning millised on nende aadressid. See võimaldab suunata neile välist liiklust ja liiklust tasakaalustajatelt.
Liiklus, mis väljub VPC-st, jõuab CloudGate'ile, andmeedastusrajale, kus VPP meie pluginatega kiiresti töötleb. Edasi liigub liiklus kas teistesse VPC-desse või väljaspoole, piiripussidesse, mis seadistatakse CloudGate'i Kontrollikava kaudu.
Kavad lähitulevikuks
Kokkuvõttes võib öelda, et VPC Yandex.Cloudis lahendab kaks olulist ülesannet:
- Tagab kliendi vahel isoleerimist.
- Kombineerib ressursse, infrastruktuuri, platvormiteenuseid, teisi pilvi ja kohapealseid lahendusi ühte võrku.
Need probleemid nõuavad head lahendust, mis tagab skaleeritavuse ja talitlushäirete taluvuse sisearhitektuuri tasandil, ja just seda VPC teebki.
Aja jooksul VPC arendab uusi funktsioone ning me rakendame uusi võimalusi, püüdes muuta kasutuse lihtsust paremaks. Mõned ideed jõuavad prioriteetide nimekirja tänu meie kogukonna liikmete ettepanekutele.
Praegu on meil selline nimekiri lähituleviku plaanidest:
- VPN kui teenus.
- Private DNS instantsi – pildid kiireks virtuaalmasinate seadistamiseks eelnevalt konfigureeritud DNS-serveriga.
- DNS kui teenus.
- Sisemine koormuse tasakaalustus.
- „Valge“ IP-aadressi lisamine ilma virtuaalmasina uuesti loomata.
Koormuse tasakaalustaja ja võimalus vahetada IP-aadressi juba loodud virtuaalmasina jaoks on kasutajate nõudmisel sellesse nimekirja jõudnud. Pean tunnistama, et ilma selge tagasisideta oleksime nende funktsioonide kallale asunud alles hiljem. Nüüd aga töötame juba aadresside ülesande kallal.
Algselt sai «valget» IP-aadressi lisada ainult masina loomisel. Kui kasutaja unustas seda teha, tuli virtuaalmasin uuesti luua. Sama kehtib ka, kui on vajalik eemaldada väline IP. Varsti saab avalikku IP-d sisse ja välja lülitada, ilma et masinat uuesti looma peaks.
Ärge kartke oma mõtteid ja toetada teiste kasutajate ettepanekuid. Aitate meil muuta Pilve paremaks ja saate olulisemaid ning kasulikumaid funktsioone kiiremini!
Allikas: habr.com
