Sveiki, mano vardas Kostya Kramlikh, esu pagrindinis „Yandex.Cloud“ virtualaus privataus debesies skyriaus kūrėjas. Esu virtualaus tinklo naudotojas ir, kaip jau galima spėti, šiame straipsnyje kalbėsiu apie Virtual Private Cloud (VPC) įrenginį apskritai ir konkrečiai apie virtualųjį tinklą. Taip pat sužinosite, kodėl mes, paslaugos kūrėjai, vertiname vartotojų atsiliepimus. Bet pirmiausia pirmiausia.
Kas yra VPC?
Šiais laikais yra įvairių paslaugų diegimo galimybių. Esu tikras, kad kažkas vis dar laiko serverį po administratoriaus stalu, nors tikiuosi, kad tokių istorijų bus mažiau.
Dabar paslaugos bando patekti į viešuosius debesis ir čia susiduria su VPC. VPC yra viešojo debesies dalis, kuri sujungia vartotoją, infrastruktūrą, platformą ir kitus pajėgumus, kad ir kur jie būtų, mūsų debesyje ar už jo ribų. Tuo pačiu VPC leidžia be reikalo nepaduoti šių pajėgumų internetui, jie lieka jūsų izoliuotame tinkle.
Kaip virtualus tinklas atrodo iš išorės?
Sakydami VPC visų pirma turime omenyje persidengiantį tinklą ir tinklo paslaugas, tokias kaip VPNaaS, NATaas, LBaas ir kt. Ir visa tai veikia gedimams atsparios tinklo infrastruktūros, kuri jau buvo sukurta, viršuje. čia, Habré.
Pažvelkime į virtualų tinklą ir jo įrenginį iš arčiau.
Apsvarstykite dvi prieinamumo zonas. Mes teikiame virtualų tinklą – tai, ką vadinome VPC. Tiesą sakant, tai apibrėžia jūsų „pilkųjų“ adresų unikalumo erdvę. Kiekviename virtualiame tinkle galite visiškai valdyti adresų, kuriuos galite priskirti skaičiavimo ištekliams, erdvę.
Tinklas yra pasaulinis. Tuo pačiu metu jis projektuojamas į kiekvieną pasiekiamumo zoną objekto, vadinamo potinkliu, forma. Kiekvienam potinkliui priskiriate 16 ar mažesnio dydžio CIDR. Kiekvienoje pasiekiamumo zonoje gali būti daugiau nei vienas toks objektas ir tarp jų visada yra skaidrus maršrutas. Tai reiškia, kad visi jūsų ištekliai tame pačiame VPC gali „kalbėtis“ vieni su kitais, net jei jie yra skirtingose pasiekiamumo zonose. „Bendrauti“ be prieigos prie interneto, per mūsų vidinius kanalus, „galvodami“, kad jie yra tame pačiame privačiame tinkle.
Aukščiau pateiktoje diagramoje parodyta tipiška situacija: du VPC, kurie susikerta kažkur adresuose. Abu gali būti jūsų. Pavyzdžiui, vienas skirtas kūrimui, kitas – testavimui. Tiesiog gali būti skirtingų vartotojų – šiuo atveju tai nesvarbu. Ir viena virtuali mašina yra prijungta prie kiekvieno VPC.
Pabloginkime schemą. Galite padaryti taip, kad viena virtuali mašina būtų įstrigusi keliuose potinkliuose vienu metu. Ir ne šiaip, o skirtinguose virtualiuose tinkluose.
Tuo pačiu metu, jei reikia prijungti mašinas prie interneto, tai galima padaryti per API arba vartotojo sąsają. Norėdami tai padaryti, turite sukonfigūruoti savo „pilko“ vidinio adreso NAT vertimą į „baltą“ - viešą. Negalite pasirinkti „balto“ adreso, jis yra priskirtas atsitiktinai iš mūsų adresų rinkinio. Kai tik nustojate naudoti išorinį IP, jis grąžinamas į baseiną. Mokate tik už „balto“ adreso naudojimo laiką.
Taip pat galima suteikti įrenginiui prieigą prie interneto naudojant NAT egzempliorių. Galite nukreipti srautą į egzempliorių naudodami statinę maršruto parinkimo lentelę. Pateikėme tokį atvejį, nes naudotojams kartais jo prireikia ir mes apie tai žinome. Atitinkamai, mūsų vaizdų kataloge yra specialiai sukonfigūruotas NAT vaizdas.
Tačiau net kai yra paruoštas NAT vaizdas, sąranka gali būti sudėtinga. Supratome, kad kai kuriems vartotojams tai nėra pats patogiausias pasirinkimas, todėl galiausiai leidome vienu paspaudimu įjungti NAT norimam potinkliui. Ši funkcija vis dar yra uždara peržiūros prieiga, kur ją išbando bendruomenės nariai.
Kaip virtualus tinklas yra išdėstytas iš vidaus
Kaip vartotojas sąveikauja su virtualiu tinklu? Internetas žiūri į išorę su savo API. Vartotojas ateina į API ir dirba su tiksline būsena. Per API vartotojas mato, kaip viskas turi būti sutvarkyta ir sukonfigūruota, o matoma būsena, kiek tikroji būsena skiriasi nuo norimos. Tai vartotojo nuotrauka. Kas vyksta viduje?
Įrašome norimą būseną į „Yandex“ duomenų bazę ir einame konfigūruoti skirtingas mūsų VPC dalis. Perdangos tinklas „Yandex.Cloud“ yra pagrįstas pasirinktais „OpenContrail“ komponentais, kurie neseniai buvo pavadinti „Tungsten Fabric“. Tinklo paslaugos yra įdiegtos vienoje „CloudGate“ platformoje. „CloudGate“ taip pat naudojome keletą atvirojo kodo komponentų: „GoBGP“ – pasiekti valdymo informaciją, taip pat VPP – įdiegti programinės įrangos maršruto parinktuvą, kuris duomenų kelyje veikia DPDK.
„Tungsten Fabric“ bendrauja su „CloudGate“ per GoBGP. Nurodo, kas vyksta perdangos tinkle. „CloudGate“, savo ruožtu, sujungia perdangos tinklus tarpusavyje ir su internetu.
Dabar pažiūrėkime, kaip virtualus tinklas išsprendžia mastelio ir prieinamumo problemas. Panagrinėkime paprastą atvejį. Yra viena prieinamumo zona ir joje sukuriami du VPC. Mes įdiegėme vieną „Tungsten Fabric“ egzempliorių ir jis ištraukia kelias dešimtis tūkstančių tinklų. Tinklai bendrauja su „CloudGate“. „CloudGate“, kaip jau minėjome, užtikrina jų ryšį tarpusavyje ir su internetu.
Tarkime, kad pridėta antroji pasiekiamumo zona. Jis turėtų sugesti visiškai nepriklausomai nuo pirmojo. Todėl antroje pasiekiamumo zonoje turime įdiegti atskirą „Tungsten Fabric“ egzempliorių. Tai bus atskira sistema, kuri nagrinėja perdangą ir mažai žino apie pirmąją sistemą. Ir matomumas, kad mūsų virtualus tinklas yra pasaulinis, iš tikrųjų sukuria mūsų VPC API. Tai jo užduotis.
VPC1 yra susietas su prieinamumo zona B, jei pasiekiamumo zonoje B yra išteklių, kurie perkeliami į VPC1. Jei pasiekiamumo zonoje B nėra resursų iš VPC2, VPC2 šioje zonoje neįgyvendinsime. Savo ruožtu, kadangi resursai iš VPC3 egzistuoja tik B zonoje, tai VPC3 neegzistuoja A zonoje. Viskas paprasta ir logiška.
Pažiūrėkime, kaip veikia konkretus Y.Cloud pagrindinis kompiuteris. Pagrindinis dalykas, į kurį noriu atkreipti dėmesį, yra tai, kad visi šeimininkai yra išdėstyti vienodai. Mes darome taip, kad tik būtinas minimumas paslaugų veiktų aparatinėje įrangoje, o visos likusios – virtualiose mašinose. Kuriame aukštesnio užsakymo paslaugas, pagrįstus pagrindinėmis infrastruktūros paslaugomis, taip pat naudojame debesį kai kurioms inžinerinėms problemoms spręsti, pavyzdžiui, pagal nuolatinę integraciją.
Jei pažvelgsime į konkretų pagrindinį kompiuterį, pamatysime, kad pagrindinio kompiuterio OS veikia trys komponentai:
- Compute – dalis, atsakinga už skaičiavimo išteklių paskirstymą pagrindiniame kompiuteryje.
- „VRouter“ yra „Tungsten Fabric“ dalis, kuri organizuoja perdangą, tai yra, ji tuneliuoja paketus per apatinį sluoksnį.
- VDiskiai yra saugyklos virtualizacijos dalys.
Be to, virtualiose mašinose pradedamos teikti paslaugos: debesų infrastruktūros paslaugos, platformos paslaugos ir klientų pajėgumai. Klientų pajėgumai ir platformos paslaugos visada patenka į perdangą per „VRouter“.
Infrastruktūros paslaugos gali prilipti prie perdangos, bet iš esmės jos nori dirbti su apatiniu sluoksniu. SR-IOV pagalba jie įklijuojami į paklotą. Tiesą sakant, mes supjaustome kortelę į virtualias tinklo plokštes (virtualias funkcijas) ir įstumiame jas į infrastruktūros virtualias mašinas, kad neprarastume našumo. Pavyzdžiui, ta pati „CloudGate“ paleidžiama kaip viena iš šių infrastruktūros virtualių mašinų.
Dabar, kai aprašėme globalias virtualaus tinklo užduotis ir pagrindinių debesies komponentų struktūrą, pažiūrėkime, kaip tiksliai sąveikauja skirtingos virtualaus tinklo dalys.
Savo sistemoje išskiriame tris sluoksnius:
- Config Plane – nustato tikslinę sistemos būseną. Tai yra tai, ką vartotojas sukonfigūruoja per API.
- Valdymo plokštuma – pateikia vartotojo apibrėžtą semantiką, ty duomenų plokštumos būseną perkelia į tą, kurią vartotojas aprašė konfigūravimo plokštumoje.
- Data Plane – tiesiogiai apdoroja vartotojo paketus.
Kaip jau sakiau aukščiau, viskas prasideda nuo to, kad vartotojo arba vidinės platformos paslauga ateina į API ir aprašo tam tikrą tikslinę būseną.
Ši būsena iš karto įrašoma į „Yandex“ duomenų bazę, per API grąžinamas asinchroninės operacijos ID ir paleidžiama mūsų vidinė mašina, kad būtų grąžinta vartotojo pageidaujama būsena. Konfigūravimo užduotys nukreipiamos į SDN valdiklį ir nurodo „Tungsten Fabric“, ką daryti perdangoje. Pavyzdžiui, jie rezervuoja prievadus, virtualius tinklus ir panašiai.
„Tungsten Fabric“ konfigūravimo plokštuma siunčia reikiamą būseną valdymo plokštumai. Per ją „Config Plane“ bendrauja su šeimininkais, pasakodama, kas būtent ant jų netrukus suksis.
Dabar pažiūrėkime, kaip sistema atrodo pagrindiniuose kompiuteriuose. Virtualioje mašinoje yra tinklo adapteris, prijungtas prie VRouter. „VRouter“ yra pagrindinis „Tungsten Fabric“ modulis, kuris žiūri į paketus. Jei kuriam nors paketui jau yra srautas, modulis jį apdoroja. Jei srauto nėra, modulis atlieka vadinamąjį punting, tai yra, siunčia paketą usermod procesui. Procesas analizuoja paketą ir pats į jį atsako, pvz., DHCP ir DNS, arba nurodo VRouter, ką su juo daryti. Po to VRouter gali apdoroti paketą.
Be to, srautas tarp virtualių mašinų tame pačiame virtualiame tinkle vyksta skaidriai, jis nėra nukreipiamas į „CloudGate“. Pagrindiniai kompiuteriai, kuriuose yra įdiegtos virtualios mašinos, tiesiogiai bendrauja tarpusavyje. Jie tuneliuoja eismą ir perduoda jį vienas kitam per paklotą.
Valdymo plokštumos bendrauja tarpusavyje tarp pasiekiamumo zonų per BGP, kaip ir su kitu maršrutizatoriumi. Jie nurodo, kurie įrenginiai kur yra, kad vienoje zonoje esantys VM galėtų tiesiogiai susisiekti su kitomis VM.
Ir „Control Plane“ bendrauja su „CloudGate“. Panašiai ji praneša, kur ir kokios virtualios mašinos iškeltos, kokius adresus jos turi. Tai leidžia nukreipti išorinį srautą ir srautą iš balansierių į juos.
Srautas, kuris palieka VPC, patenka į CloudGate, į duomenų kelią, kur VPP su mūsų įskiepiais greitai sukramtomas. Tada srautas nukreipiamas į kitus VPC arba išorę, į pasienio maršrutizatorius, kurie sukonfigūruojami per „CloudGate“ valdymo plokštumą.
Planai artimiausiai ateičiai
Jei viską, kas pasakyta, apibendrinsime keliais sakiniais, galime pasakyti, kad VPC „Yandex.Cloud“ išsprendžia dvi svarbias užduotis:
- Suteikia izoliaciją tarp skirtingų klientų.
- Sujungia išteklius, infrastruktūrą, platformos paslaugas, kitus debesis ir vietoje į vieną tinklą.
Ir norint gerai išspręsti šias problemas, reikia numatyti mastelį ir gedimų toleranciją vidinės architektūros lygiu, ką daro VPC.
Pamažu VPC įgauna funkcijas, diegiame naujas funkcijas, bandome kažką patobulinti vartotojo patogumo atžvilgiu. Kai kurios idėjos išsakomos ir patenka į prioritetų sąrašą mūsų bendruomenės narių dėka.
Šiuo metu turime tokį artimiausios ateities planų sąrašą:
- VPN kaip paslauga
- Privatūs DNS egzemplioriai yra vaizdai, skirti greitai nustatyti virtualias mašinas su iš anksto sukonfigūruotu DNS serveriu.
- DNS kaip paslauga.
- Vidinis apkrovos balansas.
- „Baltojo“ IP adreso pridėjimas nekuriant virtualios mašinos iš naujo.
Balansavimo priemonė ir galimybė pakeisti jau sukurtos virtualios mašinos IP adresą buvo įtrauktos į šį sąrašą vartotojų pageidavimu. Tiesą sakant, be aiškaus grįžtamojo ryšio šių funkcijų būtume perėmę šiek tiek vėliau. Taigi mes jau dirbame su adresų problema.
Iš pradžių „baltą“ IP adresą buvo galima pridėti tik kuriant mašiną. Jei vartotojas pamiršo tai padaryti, virtualią mašiną reikėjo sukurti iš naujo. Tas pats ir, jei reikia, pašalinkite išorinį IP. Netrukus bus galima įjungti ir išjungti viešąjį IP nekuriant įrenginio iš naujo.
Nedvejodami išreikškite savo kiti vartotojai. Padedate mums tobulinti debesį ir greičiau gauti svarbių bei naudingų funkcijų!
Šaltinis: www.habr.com