Saluton, mia nomo estas Kostya Kramlikh, mi estas la ĉefa programisto de la Virtual Private Cloud-dividado en Yandex.Cloud. Mi estas virtuala retumanto, kaj kiel vi eble divenos, en ĉi tiu artikolo mi parolos pri la Virtuala Privata Nubo (VPC) aparato ĝenerale kaj la virtuala reto aparte. Kaj vi ankaŭ ekscios kial ni, la programistoj de la servo, taksas komentojn de niaj uzantoj. Sed unue aferojn.
Kio estas VPC?
Nuntempe, ekzistas diversaj ebloj por disfaldi servojn. Mi certas, ke iu ankoraŭ tenas la servilon sub la skribotablo de la administranto, kvankam mi esperas, ke estas malpli da tiaj rakontoj.
Nun servoj provas iri al publikaj nuboj, kaj ĉi tie ili kolizias kun VPCoj. VPC estas parto de publika nubo, kiu kunligas uzanton, infrastrukturon, platformon kaj aliajn kapablojn, kie ajn ili estas, en nia Nubo aŭ ekster ĝi. Samtempe, VPC permesas vin ne elmontri ĉi tiujn kapablojn al Interreto nenecese, ili restas ene de via izolita reto.
Kiel aspektas virtuala reto de ekstere?
Per VPC, ni ĉefe celas superkovrantan reton kaj retajn servojn, kiel VPNaaS, NATaas, LBaas, ktp. Kaj ĉio ĉi funkcias aldone al mistolerema reto-infrastrukturo, kiu jam estis ĉi tie, sur Habré.
Ni rigardu pli detale la virtualan reton kaj ĝian aparaton.
Konsideru du havebleczonojn. Ni provizas virtualan reton - kion ni nomis VPC. Fakte, ĝi difinas la spacon de unikeco de viaj "grizaj" adresoj. Ene de ĉiu virtuala reto, vi havas kompletan kontrolon de la spaco de adresoj, kiujn vi povas asigni al komputikaj rimedoj.
La reto estas tutmonda. En la sama tempo, ĝi estas projekciita sur ĉiu el la havebleczonoj en la formo de unuo nomita Subreto. Por ĉiu Subreto, vi atribuas CIDR de grandeco 16 aŭ malpli. Povas ekzisti pli ol unu tia ento en ĉiu havebleczono, kaj ĉiam estas travidebla vojigo inter ili. Ĉi tio signifas, ke ĉiuj viaj rimedoj ene de la sama VPC povas "paroli" unu kun la alia, eĉ se ili estas en malsamaj Disponeblaj Zonoj. "Komuniki" sen aliro al Interreto, per niaj internaj kanaloj, "pensante" ke ili estas ene de la sama privata reto.
La supra diagramo montras tipan situacion: du VPC-oj kiuj intersekcas ie en adresoj. Ambaŭ povas esti viaj. Ekzemple, unu por evoluo, la alia por testado. Povas simple esti malsamaj uzantoj - ĉi-kaze ne gravas. Kaj unu virtuala maŝino estas konektita al ĉiu VPC.
Ni plimalbonigu la skemon. Vi povas fari ĝin tiel, ke unu virtuala maŝino estas blokita en plurajn Subretojn samtempe. Kaj ne nur tiel, sed en malsamaj virtualaj retoj.
Samtempe, se vi bezonas elmontri maŝinojn al Interreto, ĉi tio povas esti farita per la API aŭ UI. Por fari tion, vi devas agordi NAT-tradukon de via "griza", interna adreso, al "blanka" - publika. Vi ne povas elekti "blankan" adreson, ĝi estas asignita hazarde el nia aro de adresoj. Tuj kiam vi ĉesas uzi la eksteran IP, ĝi estas resendita al la naĝejo. Vi pagas nur por la tempo de uzado de la "blanka" adreso.
Eblas ankaŭ doni la maŝinan aliron al la Interreto uzante NAT-instancon. Vi povas direkti trafikon al kazo per senmova vojtabelo. Ni disponigis tian kazon, ĉar uzantoj foje bezonas ĝin, kaj ni scias pri ĝi. Sekve, nia bildkatalogo enhavas speciale agorditan NAT-bildon.
Sed eĉ kiam estas preta NAT-bildo, aranĝo povas esti malfacila. Ni komprenis, ke por iuj uzantoj ĉi tio ne estas la plej oportuna opcio, do finfine ni ebligis ebligi NAT por la dezirata Subreto per unu klako. Ĉi tiu funkcio ankoraŭ estas en fermita antaŭrigarda aliro, kie ĝi estas provita kun la helpo de komunumanoj.
Kiel la virtuala reto estas aranĝita de interne
Kiel la uzanto interagas kun la virtuala reto? La retejo rigardas eksteren per sia API. La uzanto venas al la API kaj laboras kun la cela stato. Per la API, la uzanto vidas kiel ĉio devas esti aranĝita kaj agordita, dum li vidas la statuson, kiom la reala stato diferencas de la dezirata. Ĉi tio estas bildo de la uzanto. Kio okazas interne?
Ni skribas la deziratan staton al Yandex Database kaj iras por agordi malsamajn partojn de nia VPC. La superkovra reto en Yandex.Cloud baziĝas sur elektitaj komponantoj de OpenContrail, kiu lastatempe estis nomita Tungsten Fabric. Retaj servoj estas efektivigitaj sur ununura CloudGate-platformo. En CloudGate, ni ankaŭ uzis kelkajn malfermfontajn komponentojn: GoBGP - por aliri kontrolinformojn, same kiel VPP - por efektivigi programaran enkursigilon kiu funkcias super DPDK por la datumvojo.
Tungsten Fabric komunikas kun CloudGate per GoBGP. Rakontas kio okazas en la superkovra reto. CloudGate, siavice, ligas superkovrajn retojn unu kun la alia kaj kun la Interreto.
Nun ni vidu kiel virtuala reto solvas la problemojn de skalo kaj havebleco. Ni konsideru simplan kazon. Estas unu havebleca zono kaj du VPC-oj estas kreitaj en ĝi. Ni deplojis unu petskribon de Tungsten Fabric, kaj ĝi tiras plurajn dekojn da miloj da retoj. Retoj komunikas kun CloudGate. CloudGate, kiel ni jam diris, certigas ilian konekteblecon inter si kaj kun Interreto.
Ni diru, ke dua havebleca zono estas aldonita. Ĝi devus malsukcesi tute sendepende de la unua. Tial, en la dua havebleca zono, ni devas instali apartan petskribon de Tungsten Fabric. Ĉi tio estos aparta sistemo, kiu traktas la tegaĵon kaj scias malmulte pri la unua sistemo. Kaj la videbleco, ke nia virtuala reto estas tutmonda, fakte, kreas nian VPC-API. Jen lia tasko.
VPC1 estas mapita al Havebleco-Zono B se ekzistas resursoj en Havebleco-Zono B kiuj estas puŝitaj al VPC1. Se ne estas rimedoj de VPC2 en havebleca zono B, ni ne realigos VPC2 en ĉi tiu zono. Siavice, ĉar rimedoj de VPC3 ekzistas nur en zono B, VPC3 ne ekzistas en zono A. Ĉio estas simpla kaj logika.
Ni iru iom pli profunden kaj vidu kiel funkcias aparta gastiganto en Y.Cloud. La ĉefa afero, kiun mi volas noti, estas, ke ĉiuj gastigantoj estas aranĝitaj en la sama maniero. Ni faras tiel, ke nur la necesa minimumo da servoj funkcias per aparataro, la tuta resto funkcias per virtualaj maŝinoj. Ni konstruas pli alt-ordajn servojn bazitajn sur bazaj infrastrukturaj servoj, kaj ankaŭ uzas la Nubon por solvi iujn inĝenierajn problemojn, ekzemple, kadre de Daŭra Integriĝo.
Se ni rigardas specifan gastiganton, ni povas vidi, ke ekzistas tri komponentoj funkcianta sur la gastiga OS:
- Komputi - la parto respondeca por la distribuado de komputikresursoj sur la gastiganto.
- VRouter estas parto de Tungsten Fabric kiu organizas superkovron, tio estas, ĝi tunelas pakaĵetojn tra subtavolo.
- VDiskoj estas pecoj de stokadvirtualigo.
Krome, servoj estas lanĉitaj en virtualaj maŝinoj: Nubaj infrastrukturaj servoj, platformaj servoj kaj klientkapabloj. Klientkapabloj kaj platformservoj ĉiam iras al la tegaĵo per VRouter.
Infrastrukturaj servoj povas resti en la tegaĵo, sed esence ili volas labori en la submetaĵo. Ili estas fiksitaj en la submetaĵon kun la helpo de SR-IOV. Fakte, ni tranĉas la karton en virtualajn retajn kartojn (virtualajn funkciojn) kaj puŝas ilin en infrastrukturajn virtualajn maŝinojn por ne perdi rendimenton. Ekzemple, la sama CloudGate estas lanĉita kiel unu el ĉi tiuj infrastrukturaj virtualaj maŝinoj.
Nun kiam ni priskribis la tutmondajn taskojn de la virtuala reto kaj la strukturon de la bazaj komponantoj de la nubo, ni vidu kiel precize la malsamaj partoj de la virtuala reto interagas inter si.
Ni distingas tri tavolojn en nia sistemo:
- Config Plane - fiksas la celstato de la sistemo. Jen kion la uzanto agordas per la API.
- Control Plane - disponigas uzant-difinitan semantikon, t.e., alportas la Data Plane-ŝtaton al kio estis priskribita fare de la uzanto en Config Plane.
- Data Plane - rekte prilaboras la pakaĵetojn de la uzanto.
Kiel mi diris supre, ĉio komenciĝas per tio, ke la uzanto aŭ interna platforma servo venas al la API kaj priskribas certan celan staton.
Ĉi tiu stato tuj estas skribita al Yandex Database, resendas la nesinkronan operacian ID per la API, kaj lanĉas nian internan maŝinaron por redoni la staton, kiun la uzanto volis. Agordaj taskoj iras al la SDN-regilo kaj diru al Tungsten Fabric kion fari en la tegmento. Ekzemple, ili rezervas havenojn, virtualajn retojn kaj similajn.
Agordo-Aviadilo en Tungsteno-Ŝtofo sendas la postulatan staton al la Kontrolaviadilo. Per ĝi, Config Plane komunikas kun gastigantoj, dirante, kio precize turniĝos al ili baldaŭ.
Nun ni vidu kiel la sistemo aspektas sur la gastigantoj. La virtuala maŝino havas retan adaptilon konektitan al VRouter. VRouter estas kerna Tungsten Fabric-modulo kiu rigardas pakaĵojn. Se jam ekzistas fluo por iu pakaĵo, la modulo prilaboras ĝin. Se ne estas fluo, la modulo faras la tiel nomatan punting, tio estas, ĝi sendas pakaĵeton al la usermod-procezo. La procezo analizas la pakaĵon kaj aŭ respondas al ĝi mem, kiel DHCP kaj DNS, aŭ diras al VRouter kion fari kun ĝi. Post tio, VRouter povas prilabori la pakaĵon.
Plue, trafiko inter virtualaj maŝinoj ene de la sama virtuala reto iras travideble, ĝi ne estas direktita al CloudGate. La gastigantoj sur kiuj la virtualaj maŝinoj estas deplojitaj komunikas rekte unu kun la alia. Ili tunelas trafikon kaj plusendas ĝin unu por la alia tra la subtavolo.
Kontrolaviadiloj komunikas inter si inter havebleczonoj per BGP, kiel kun alia enkursigilo. Ili rakontas, kiuj maŝinoj estas supre kie por ke VMs en unu zono povas komuniki rekte kun aliaj VMs.
Kaj Control Plane komunikas kun CloudGate. Simile, ĝi raportas kie kaj kiuj virtualaj maŝinoj estas levitaj, kiajn adresojn ili havas. Ĉi tio ebligas al vi direkti eksteran trafikon kaj trafikon de ekvilibristoj al ili.
La trafiko, kiu forlasas la VPC, venas al CloudGate, al la datumvojo, kie la VPP kun niaj kromprogramoj estas rapide maĉita. Tiam la trafiko estas pafita aŭ al aliaj VPC-oj aŭ eksteren, al landlimaj enkursigiloj, kiuj estas agordita per la Kontrolaviadilo de CloudGate mem.
Planoj por la proksima estonteco
Se ni resumas ĉion supre dirite en kelkaj frazoj, ni povas diri, ke VPC en Yandex.Cloud solvas du gravajn taskojn:
- Provizas izolitecon inter malsamaj klientoj.
- Kombinas rimedojn, infrastrukturon, platformservojn, aliajn nubojn kaj surloke en ununuran reton.
Kaj por solvi ĉi tiujn problemojn bone, vi devas provizi skaleblon kaj misfunkciadon je la nivelo de la interna arkitekturo, kion faras VPC.
Iom post iom VPC akiras funkciojn, ni efektivigas novajn funkciojn, ni provas plibonigi ion koncerne uzantan oportunecon. Iuj ideoj estas voĉigitaj kaj eniras la prioritatan liston danke al la membroj de nia komunumo.
Ni nuntempe havas la jenan liston de planoj por la proksima estonteco:
- VPN kiel servo
- Privataj DNS-kazoj estas bildoj por rapide agordi virtualajn maŝinojn kun antaŭ-agordita DNS-servilo.
- DNS kiel servo.
- Interna ŝarĝobalancilo.
- Aldonante "blankan" IP-adreson sen rekrei la virtualan maŝinon.
La ekvilibristo kaj la kapablo ŝanĝi la IP-adreson por jam kreita virtuala maŝino estis en ĉi tiu listo laŭ peto de uzantoj. Por esti honesta, sen eksplicita reago, ni estus preninta sur ĉi tiujn funkciojn iom poste. Kaj do ni jam laboras pri la problemo pri adresoj.
Komence, "blanka" IP-adreso povus esti aldonita nur dum kreado de maŝino. Se la uzanto forgesis fari tion, la virtuala maŝino devis esti rekreita. La sama kaj, se necese, forigu la eksteran IP. Baldaŭ eblos ŝalti kaj malŝalti la publikan IP sen devi rekrei la maŝinon.
Bonvolu esprimi vian aliaj uzantoj. Vi helpas nin plibonigi la Nubon kaj akiri gravajn kaj utilajn funkciojn pli rapide!
fonto: www.habr.com