Hallo, myn namme is Kostya Kramlikh, ik bin de haadûntwikkelder fan 'e Virtual Private Cloud-divyzje yn Yandex.Cloud. Ik bin in firtuele netwurker, en lykas jo miskien riede, sil ik yn dit artikel prate oer it Virtual Private Cloud (VPC) apparaat yn it algemien en it firtuele netwurk yn it bysûnder. En jo sille ek útfine wêrom't wy, de ûntwikkelders fan 'e tsjinst, feedback fan ús brûkers wurdearje. Mar earst dingen earst.
Wat is VPC?
Tsjintwurdich binne d'r in ferskaat oan opsjes foar it ynsetten fan tsjinsten. Ik bin der wis fan dat immen de tsjinner noch ûnder it buro fan de behearder hâldt, hoewol ik hoopje dat der minder sokke ferhalen binne.
No besykje tsjinsten te gean nei iepenbiere wolken, en dit is wêr't se botse mei VPC's. VPC is in diel fan in iepenbiere wolk dy't brûker, ynfrastruktuer, platfoarm en oare kapasiteiten byinoar bringt, wêr't se ek binne, yn ús Cloud of dêrbûten. Tagelyk lit VPC jo dizze kapasiteiten net unnedich bleatstelle oan it ynternet, se bliuwe binnen jo isolearre netwurk.
Hoe sjocht in firtuele netwurk fan bûten ôf?
Mei VPC bedoele wy yn it foarste plak in overlay netwurk en netwurk tsjinsten, lykas VPNaaS, NATaas, LBaas, ensfh En dit alles wurket boppe op in fout-tolerante netwurk ynfrastruktuer, dy't al west hat. hjir, op Habré.
Litte wy in tichterby besjen op it firtuele netwurk en har apparaat.
Tink oan twa beskikberenssônes. Wy leverje in firtuele netwurk - wat wy VPC neamden. Yn feite definiearret it de romte fan unykheid fan jo "grize" adressen. Binnen elk firtueel netwurk hawwe jo folsleine kontrôle oer de romte fan adressen dy't jo kinne tawize oan berekkeningsboarnen.
It netwurk is wrâldwiid. Tagelyk wurdt it projekteare op elk fan 'e beskikberensônes yn' e foarm fan in entiteit neamd Subnet. Foar elk subnet tawize jo in CIDR fan grutte 16 of minder. D'r kin mear as ien sa'n entiteit wêze yn elke beskikberensône, en d'r is altyd transparante rûte tusken har. Dit betsjut dat al jo boarnen binnen deselde VPC mei elkoar kinne "prate", sels as se yn ferskate beskikberensônes binne. "Kommunisearje" sûnder tagong ta it ynternet, fia ús ynterne kanalen, "tinkende" dat se binnen itselde privee netwurk binne.
It diagram hjirboppe lit in typyske situaasje sjen: twa VPC's dy't earne yn adressen krúst. Beide kinne jo wêze. Bygelyks, ien foar ûntwikkeling, de oare foar testen. D'r kinne gewoan ferskate brûkers wêze - yn dit gefal makket it net út. En ien firtuele masine is ynsletten yn elke VPC.
Litte wy it skema slimmer meitsje. Jo kinne it sa meitsje dat ien firtuele masine tagelyk yn ferskate subnets fêst sit. En net allinnich sa, mar yn ferskillende firtuele netwurken.
Tagelyk, as jo masines moatte bleatstelle oan it ynternet, kin dit dien wurde fia de API of UI. Om dit te dwaan, moatte jo de NAT-oersetting fan jo "griis", ynterne adres ynstelle nei "wyt" - iepenbier. Jo kinne gjin "wyt" adres kieze, it wurdt willekeurich tawiisd út ús pool fan adressen. Sadree't jo stopje mei it brûken fan it eksterne IP, wurdt it weromjûn nei it swimbad. Jo betelje allinich foar it gebrûk fan it "wyt" adres.
It is ek mooglik om de masine tagong te jaan ta it ynternet mei in NAT-eksimplaar. Jo kinne rûte ferkear nei in eksimplaar troch in statyske routing tabel. Wy hawwe sa'n gefal levere, om't brûkers it soms nedich hawwe, en wy witte derfan. Dêrtroch befettet ús ôfbyldingskatalogus in spesjaal konfigureare NAT-ôfbylding.
Mar sels as d'r in klear NAT-ôfbylding is, kin de opset lestich wêze. Wy begrepen dat dit foar guon brûkers net de meast handige opsje is, dus wy makken it úteinlik mooglik om NAT yn te skeakeljen foar it winske subnet yn ien klik. Dizze funksje is noch yn sletten preview tagong, wêr't it wurdt hifke mei help fan leden fan 'e mienskip.
Hoe't it firtuele netwurk fan binnen is regele
Hoe ynteraksje de brûker mei it firtuele netwurk? It web sjocht nei bûten mei syn API. De brûker komt nei de API en wurket mei de doelstatus. Troch de API sjocht de brûker hoe't alles regele en konfigurearre wurde moat, wylst hy de status sjocht, hoefolle de eigentlike steat ferskilt fan 'e winske. Dit is in foto fan de brûker. Wat bart der binnen?
Wy skriuwe de winske steat nei Yandex Database en gean nei konfiguraasje ferskillende dielen fan ús VPC. It overlay-netwurk yn Yandex.Cloud is basearre op selektearre komponinten fan OpenContrail, dy't koartlyn Tungsten Fabric neamd is. Netwurktsjinsten wurde ymplementearre op ien CloudGate-platfoarm. Yn CloudGate hawwe wy ek in oantal iepen boarne-komponinten brûkt: GoBGP - om tagong te krijen ta kontrôleynformaasje, lykas VPP - om in softwarerouter te ymplementearjen dy't boppe op DPDK rint foar it gegevenspaad.
Tungsten Fabric kommunisearret mei CloudGate fia GoBGP. Fertelt wat der bart yn it overlay netwurk. CloudGate ferbynt op syn beurt overlay-netwurken mei elkoar en mei it ynternet.
Litte wy no sjen hoe't in firtuele netwurk de problemen fan skaalfergrutting en beskikberens oplost. Litte wy in ienfâldige saak beskôgje. D'r is ien beskikberensône en der wurde twa VPC's yn makke. Wy ynset ien Tungsten Fabric eksimplaar, en it lûkt ferskate tsientûzenen netwurken. Netwurken kommunisearje mei CloudGate. CloudGate, lykas wy al sein hawwe, soarget foar har ferbining mei elkoar en mei it ynternet.
Litte wy sizze dat der in twadde beskikberensône tafoege wurdt. It moat folslein ûnôfhinklik fan 'e earste mislearje. Dêrom moatte wy yn 'e twadde beskikberensône in aparte Tungsten Fabric-eksimplaar ynstallearje. Dit sil in apart systeem wêze dat omgiet mei de overlay en net folle wit oer it earste systeem. En de sichtberens dat ús firtuele netwurk wrâldwiid is, makket yn feite ús VPC API. Dit is syn taak.
VPC1 wurdt yn kaart brocht oan Beskikberenssône B as d'r boarnen binne yn Beskikberenssône B dy't nei VPC1 wurde skood. As d'r gjin boarnen binne fan VPC2 yn beskikberensône B, sille wy VPC2 net materialisearje yn dizze sône. Yn beurt, sûnt middels út VPC3 bestean allinnich yn sône B, bestiet VPC3 net yn sône A. Alles is ienfâldich en logysk.
Litte wy in bytsje djipper gean en sjen hoe't in bepaalde host yn Y.Cloud wurket. It wichtichste ding dat ik wol opmerke is dat alle hosts op deselde manier binne regele. Wy meitsje it sa dat allinich it nedige minimum fan tsjinsten rint op hardware, de rest rint op firtuele masines. Wy bouwe tsjinsten fan hegere oarder basearre op basisynfrastruktuertsjinsten, en brûke ek de Cloud om guon technyske problemen op te lossen, bygelyks yn it ramt fan Continuous Integration.
As wy nei in spesifike host sjogge, kinne wy sjen dat d'r trije komponinten rinne op it host OS:
- Compute - it diel dat ferantwurdlik is foar de distribúsje fan komputerboarnen op 'e host.
- VRouter is in part fan Tungsten Fabric dat organisearret in overlay, dat is, it tunnels pakketten troch in underlay.
- VDisks binne brokken fan opslachvirtualisaasje.
Derneist wurde tsjinsten lansearre yn firtuele masines: Cloud-ynfrastruktuertsjinsten, platfoarmtsjinsten en klantkapasiteiten. Klantkapasiteiten en platfoarmtsjinsten geane altyd nei de overlay fia VRouter.
Ynfrastruktuertsjinsten kinne yn 'e overlay stekke, mar yn prinsipe wolle se yn' e underlay wurkje. Se wurde mei help fan SR-IOV yn 'e ûnderlaach stutsen. Yn feite, wy snije de kaart yn firtuele netwurk kaarten (firtuele funksjes) en triuwe se yn ynfrastruktuer firtuele masines om net te ferliezen prestaasjes. Bygelyks, deselde CloudGate wurdt lansearre as ien fan dizze ynfrastruktuer firtuele masines.
No't wy de globale taken fan it firtuele netwurk en de struktuer fan 'e basiskomponinten fan' e wolk hawwe beskreaun, litte wy sjen hoe't krekt de ferskate dielen fan it firtuele netwurk mei elkoar ynteraksje.
Wy ûnderskiede trije lagen yn ús systeem:
- Config Plane - stelt de doelstatus fan it systeem yn. Dit is wat de brûker konfigurearret fia de API.
- Control Plane - jout brûker-definiearre semantyk, dat is, bringt de Data Plane steat oan wat waard beskreaun troch de brûker yn Config Plane.
- Data Plane - ferwurket de pakketten fan 'e brûker direkt.
Lykas ik hjirboppe sei, begjint it allegear mei it feit dat de brûker as ynterne platfoarmtsjinst nei de API komt en in bepaalde doelstatus beskriuwt.
Dizze steat wurdt fuortendaliks skreaun nei Yandex Database, jout de asynchrone operaasje ID werom fia de API, en begjint ús ynterne masines om de steat werom te jaan dy't de brûker woe. Konfiguraasjetaken gean nei de SDN-controller en fertel Tungsten Fabric wat te dwaan yn 'e overlay. Se reservearje bygelyks havens, firtuele netwurken, en sa.
Config Plane yn Tungsten Fabric stjoert de fereaske steat nei it Control Plane. Troch it kommunisearret Config Plane mei de hosts, en fertelt wat krekt op har sil draaie.
Litte wy no sjen hoe't it systeem derút sjocht op 'e hosts. De firtuele masine hat in netwurkadapter ynstutsen yn VRouter. VRouter is in kearn Tungsten Fabric module dy't sjocht nei pakketten. As d'r al in stream is foar guon pakket, ferwurket de module it. As der gjin stream is, docht de module de saneamde punting, dat is, it stjoert in pakket nei it usermod-proses. It proses parseart it pakket en reagearret der sels op, lykas DHCP en DNS, of fertelt VRouter wat dermei te dwaan. Dêrnei kin VRouter it pakket ferwurkje.
Fierder giet ferkear tusken firtuele masines binnen itselde firtuele netwurk transparant, it is net rjochte op CloudGate. De hosts wêrop de firtuele masines wurde ynset kommunisearje direkt mei elkoar. Se tunnelferkear en stjoere it foar elkoar troch de ûndergrûn.
Control Planes kommunisearje mei elkoar tusken beskikberens sônes fia BGP, lykas mei in oare router. Se fertelle hokker masines binne omheech wêr sadat VM's yn ien sône kinne direkt kommunisearje mei oare VM's.
En Control Plane kommunisearret mei CloudGate. Op deselde manier rapportearret it wêr en hokker firtuele masines wurde opbrocht, hokker adressen se hawwe. Hjirmei kinne jo ekstern ferkear en ferkear fan balancers nei har rjochtsje.
It ferkear dat de VPC ferlit komt nei CloudGate, nei it gegevenspaad, wêr't de VPP mei ús plugins fluch opknapt wurdt. Dan wurdt it ferkear ûntslein of nei oare VPC's of bûten, nei grinsrouters dy't binne konfigureare fia it Control Plane fan CloudGate sels.
Plannen foar de heine takomst
As wy alles hjirboppe yn in pear sinnen gearfetsje, kinne wy sizze dat VPC yn Yandex.Cloud twa wichtige taken oplost:
- Biedt isolaasje tusken ferskate kliïnten.
- Kombinearret boarnen, ynfrastruktuer, platfoarmtsjinsten, oare wolken en on-premise yn ien netwurk.
En om dizze problemen goed op te lossen, moatte jo skaalberens en fouttolerânsje leverje op it nivo fan 'e ynterne arsjitektuer, wat VPC docht.
Stadichoan krijt VPC funksjes, wy implementearje nije funksjes, wy besykje wat te ferbetterjen yn termen fan brûkersgemak. Guon ideeën wurde útsprutsen en komme op 'e prioriteitslist troch de leden fan ús mienskip.
Wy hawwe op it stuit de folgjende list mei plannen foar de heine takomst:
- VPN as tsjinst.
- Privee DNS-eksimplaren binne ôfbyldings foar it fluch ynstellen fan firtuele masines mei in foarôf ynstelde DNS-tsjinner.
- DNS as in tsjinst.
- Ynterne load balancer.
- In "wyt" IP-adres tafoegje sûnder de firtuele masine opnij oan te meitsjen.
De balancer en de mooglikheid om it IP-adres te wikseljen foar in al makke firtuele masine wiene op dizze list op fersyk fan brûkers. Om earlik te wêzen, sûnder eksplisite feedback, soene wy dizze funksjes in bytsje letter oernommen hawwe. En sa wurkje wy al oan it probleem oer adressen.
Yn it earstoan koe in "wyt" IP-adres allinich tafoege wurde by it meitsjen fan in masine. As de brûker dit fergeat, moast de firtuele masine opnij oanmakke wurde. Itselde en, as it nedich is, fuortsmite de eksterne IP. It sil ynkoarten mooglik wêze om de iepenbiere IP oan en út te skeakeljen sûnder de masine opnij te meitsjen.
Fiel jo frij om jo út te drukken oare brûkers. Jo helpe ús om de Cloud better te meitsjen en wichtige en nuttige funksjes rapper te krijen!
Boarne: www.habr.com