Helo, fy enw i yw Kostya Kramlikh, fi yw prif ddatblygwr yr adran Virtual Private Cloud yn Yandex.Cloud. Rwy'n rhwydwaithwr rhithwir, ac fel y gallech ddyfalu, yn yr erthygl hon byddaf yn siarad am y ddyfais Virtual Private Cloud (VPC) yn gyffredinol a'r rhwydwaith rhithwir yn benodol. A byddwch hefyd yn darganfod pam ein bod ni, datblygwyr y gwasanaeth, yn gwerthfawrogi adborth gan ein defnyddwyr. Ond pethau cyntaf yn gyntaf.
Beth yw VPC?
Y dyddiau hyn, mae amrywiaeth o opsiynau ar gyfer defnyddio gwasanaethau. Dwi'n siwr fod rhywun yn dal i gadw'r gweinydd o dan ddesg y gweinyddwr, er dwi'n gobeithio bod llai o straeon o'r fath.
Nawr mae gwasanaethau'n ceisio mynd i gymylau cyhoeddus, a dyma lle maen nhw'n gwrthdaro â VPCs. Mae VPC yn rhan o gwmwl cyhoeddus sy'n clymu defnyddwyr, seilwaith, platfform a galluoedd eraill gyda'i gilydd, ble bynnag y bônt, yn ein Cwmwl neu y tu allan iddo. Ar yr un pryd, mae VPC yn caniatáu ichi beidio â datgelu'r galluoedd hyn i'r Rhyngrwyd yn ddiangen, maent yn aros o fewn eich rhwydwaith ynysig.
Sut olwg sydd ar rwydwaith rhithwir o'r tu allan?
Wrth VPC, rydym yn bennaf yn golygu rhwydwaith troshaen a gwasanaethau rhwydwaith, megis VPNaaS, NATaas, LBaas, ac ati Ac mae hyn i gyd yn gweithio ar ben seilwaith rhwydwaith sy'n goddef namau, sydd eisoes wedi'i yma, ar Habré.
Gadewch i ni edrych yn agosach ar y rhwydwaith rhithwir a'i ddyfais.
Ystyriwch ddau barth argaeledd. Rydym yn darparu rhwydwaith rhithwir - yr hyn a alwn yn VPC. Mewn gwirionedd, mae'n diffinio gofod unigrywiaeth eich cyfeiriadau "llwyd". O fewn pob rhwydwaith rhithwir, mae gennych reolaeth lwyr dros y gofod o gyfeiriadau y gallwch eu neilltuo i gyfrifo adnoddau.
Mae'r rhwydwaith yn fyd-eang. Ar yr un pryd, caiff ei ragamcanu ar bob un o'r parthau argaeledd ar ffurf endid o'r enw Subnet. Ar gyfer pob Isrwyd, rydych chi'n aseinio CIDR o faint 16 neu lai. Gall fod mwy nag un endid o'r fath ym mhob parth argaeledd, ac mae llwybro tryloyw rhyngddynt bob amser. Mae hyn yn golygu y gall eich holl adnoddau o fewn yr un VPC "siarad" â'i gilydd, hyd yn oed os ydynt mewn Parthau Argaeledd gwahanol. "Cyfathrebu" heb fynediad i'r Rhyngrwyd, trwy ein sianeli mewnol, "meddwl" eu bod o fewn yr un rhwydwaith preifat.
Mae'r diagram uchod yn dangos sefyllfa nodweddiadol: dau VPC sy'n croestorri rhywle mewn cyfeiriadau. Gall y ddau fod yn eiddo i chi. Er enghraifft, un ar gyfer datblygu, y llall ar gyfer profi. Yn syml, efallai y bydd gwahanol ddefnyddwyr - yn yr achos hwn nid oes ots. Ac mae un peiriant rhithwir wedi'i blygio i bob VPC.
Gadewch i ni wneud y cynllun yn waeth. Gallwch ei wneud fel bod un peiriant rhithwir yn sownd mewn sawl Is-rwydwaith ar unwaith. Ac nid yn union fel hynny, ond mewn gwahanol rwydweithiau rhithwir.
Ar yr un pryd, os oes angen i chi ddatgelu peiriannau i'r Rhyngrwyd, gellir gwneud hyn trwy'r API neu'r UI. I wneud hyn, mae angen i chi ffurfweddu cyfieithiad NAT o'ch cyfeiriad mewnol “llwyd”, i “gwyn” - cyhoeddus. Ni allwch ddewis cyfeiriad "gwyn", caiff ei neilltuo ar hap o'n cronfa o gyfeiriadau. Cyn gynted ag y byddwch yn rhoi'r gorau i ddefnyddio'r IP allanol, caiff ei ddychwelyd i'r pwll. Dim ond am yr amser o ddefnyddio'r cyfeiriad "gwyn" y byddwch chi'n talu.
Mae hefyd yn bosibl rhoi mynediad i'r Rhyngrwyd i'r peiriant gan ddefnyddio enghraifft NAT. Gallwch gyfeirio traffig i enghraifft trwy fwrdd llwybro sefydlog. Rydym wedi darparu achos o'r fath, oherwydd weithiau mae ei angen ar ddefnyddwyr, ac rydym yn gwybod amdano. Yn unol â hynny, mae ein catalog delweddau yn cynnwys delwedd NAT sydd wedi'i ffurfweddu'n arbennig.
Ond hyd yn oed pan fydd delwedd NAT barod, gall gosod fod yn anodd. Roeddem yn deall nad dyma'r opsiwn mwyaf cyfleus i rai defnyddwyr, felly yn y diwedd fe wnaethom ni'n bosibl galluogi NAT ar gyfer yr Is-rwydwaith dymunol mewn un clic. Mae'r nodwedd hon yn dal i fod mewn mynediad rhagolwg caeedig, lle caiff ei brofi gyda chymorth aelodau'r gymuned.
Sut mae'r rhwydwaith rhithwir wedi'i drefnu o'r tu mewn
Sut mae'r defnyddiwr yn rhyngweithio â'r rhwydwaith rhithwir? Mae'r we yn edrych tuag allan gyda'i API. Daw'r defnyddiwr i'r API ac mae'n gweithio gyda'r cyflwr targed. Trwy'r API, mae'r defnyddiwr yn gweld sut y dylid trefnu a ffurfweddu popeth, tra ei fod yn gweld y statws, faint mae'r cyflwr gwirioneddol yn wahanol i'r un a ddymunir. Dyma lun o'r defnyddiwr. Beth sy'n digwydd tu fewn?
Rydym yn ysgrifennu'r cyflwr dymunol i Gronfa Ddata Yandex ac yn mynd i ffurfweddu gwahanol rannau o'n VPC. Mae'r rhwydwaith troshaenu yn Yandex.Cloud yn seiliedig ar gydrannau dethol o OpenContrail, a elwir yn Ffabrig Twngsten yn ddiweddar. Mae gwasanaethau rhwydwaith yn cael eu gweithredu ar un platfform CloudGate. Yn CloudGate, fe wnaethom hefyd ddefnyddio nifer o gydrannau ffynhonnell agored: GoBGP - i gael mynediad at wybodaeth reoli, yn ogystal â VPP - i weithredu llwybrydd meddalwedd sy'n rhedeg ar ben DPDK ar gyfer y llwybr data.
Mae Twngsten Fabric yn cyfathrebu â CloudGate trwy GoBGP. Yn dweud beth sy'n digwydd yn y rhwydwaith troshaen. Mae CloudGate, yn ei dro, yn cysylltu rhwydweithiau troshaen â'i gilydd a chyda'r Rhyngrwyd.
Nawr, gadewch i ni weld sut mae rhwydwaith rhithwir yn datrys problemau graddio ac argaeledd. Gadewch i ni ystyried achos syml. Mae un parth argaeledd a dau VPC yn cael eu creu ynddo. Fe wnaethom ddefnyddio un enghraifft Ffabrig Twngsten, ac mae'n tynnu sawl degau o filoedd o rwydweithiau. Mae rhwydweithiau'n cyfathrebu â CloudGate. Mae CloudGate, fel y dywedasom eisoes, yn sicrhau eu cysylltedd â'i gilydd a chyda'r Rhyngrwyd.
Gadewch i ni ddweud bod ail barth argaeledd yn cael ei ychwanegu. Dylai fethu yn hollol annibynnol ar y cyntaf. Felly, yn yr ail barth argaeledd, rhaid inni osod enghraifft Ffabrig Twngsten ar wahân. Bydd hon yn system ar wahân sy'n ymdrin â'r troshaen ac yn gwybod fawr ddim am y system gyntaf. Ac mae'r gwelededd bod ein rhwydwaith rhithwir yn fyd-eang, mewn gwirionedd, yn creu ein API VPC. Dyma ei orchwyl.
Mae VPC1 yn cael ei fapio i Barth Argaeledd B os oes adnoddau ym Mharth Argaeledd B sy'n cael eu gwthio i VPC1. Os nad oes adnoddau gan VPC2 ym mharth argaeledd B, ni fyddwn yn gwireddu VPC2 yn y parth hwn. Yn ei dro, gan fod adnoddau o VPC3 yn bodoli ym mharth B yn unig, nid yw VPC3 yn bodoli ym mharth A. Mae popeth yn syml ac yn rhesymegol.
Gadewch i ni fynd ychydig yn ddyfnach a gweld sut mae gwesteiwr penodol yn Y.Cloud yn gweithio. Y prif beth yr wyf am ei nodi yw bod yr holl westeion wedi'u trefnu yn yr un ffordd. Rydyn ni'n ei gwneud hi fel mai dim ond y lleiafswm angenrheidiol o wasanaethau sy'n rhedeg ar galedwedd, mae'r gweddill i gyd yn rhedeg ar beiriannau rhithwir. Rydym yn adeiladu gwasanaethau lefel uwch yn seiliedig ar wasanaethau seilwaith sylfaenol, a hefyd yn defnyddio'r Cwmwl i ddatrys rhai problemau peirianneg, er enghraifft, o fewn fframwaith Integreiddio Parhaus.
Os edrychwn ar westeiwr penodol, gallwn weld bod tair cydran yn rhedeg ar yr OS gwesteiwr:
- Cyfrifiadura - y rhan sy'n gyfrifol am ddosbarthu adnoddau cyfrifiadurol ar y gwesteiwr.
- Mae VRouter yn rhan o Twngsten Fabric sy'n trefnu troshaen, hynny yw, mae'n twnelu pecynnau trwy isgarth.
- Mae VDisks yn dalpiau o rithwiroli storio.
Yn ogystal, mae gwasanaethau'n cael eu lansio mewn peiriannau rhithwir: gwasanaethau seilwaith cwmwl, gwasanaethau platfform a gallu cwsmeriaid. Mae gallu cwsmeriaid a gwasanaethau platfform bob amser yn mynd i'r troshaen trwy VRouter.
Gall gwasanaethau seilwaith gadw at y troshaen, ond yn y bôn maen nhw eisiau gweithio yn yr isgarth. Maent yn sownd yn yr isgarth gyda chymorth SR-IOV. Mewn gwirionedd, rydym yn torri'r cerdyn yn gardiau rhwydwaith rhithwir (swyddogaethau rhithwir) ac yn eu gwthio i mewn i beiriannau rhithwir seilwaith er mwyn peidio â cholli perfformiad. Er enghraifft, mae'r un CloudGate yn cael ei lansio fel un o'r peiriannau rhithwir seilwaith hyn.
Nawr ein bod wedi disgrifio tasgau byd-eang y rhwydwaith rhithwir a strwythur cydrannau sylfaenol y cwmwl, gadewch i ni weld sut yn union y mae gwahanol rannau'r rhwydwaith rhithwir yn rhyngweithio â'i gilydd.
Rydym yn gwahaniaethu tair haen yn ein system:
- Config Plane - yn gosod cyflwr targed y system. Dyma beth mae'r defnyddiwr yn ei ffurfweddu trwy'r API.
- Control Plane - yn darparu semanteg a ddiffinnir gan y defnyddiwr, hynny yw, yn dod â chyflwr Data Plane i'r hyn a ddisgrifiwyd gan y defnyddiwr yn Config Plane.
- Data Plane - prosesu pecynnau'r defnyddiwr yn uniongyrchol.
Fel y dywedais uchod, mae'r cyfan yn dechrau gyda'r ffaith bod y defnyddiwr neu'r gwasanaeth platfform mewnol yn dod i'r API ac yn disgrifio cyflwr targed penodol.
Mae'r cyflwr hwn yn cael ei ysgrifennu ar unwaith i Gronfa Ddata Yandex, yn dychwelyd yr ID gweithrediad asyncronig trwy'r API, ac yn cychwyn ein peiriannau mewnol i ddychwelyd y cyflwr yr oedd y defnyddiwr ei eisiau. Mae tasgau ffurfweddu yn mynd at y rheolydd SDN ac yn dweud wrth Tungsten Fabric beth i'w wneud yn y troshaen. Er enghraifft, maent yn cadw porthladdoedd, rhwydweithiau rhithwir, ac ati.
Mae Config Plane mewn Ffabrig Twngsten yn anfon y cyflwr gofynnol i'r Awyren Reoli. Trwyddo, mae Config Plane yn cyfathrebu â'r gwesteiwyr, gan ddweud beth yn union fydd yn troi arnynt yn fuan.
Nawr, gadewch i ni weld sut mae'r system yn edrych ar y gwesteiwyr. Mae gan y peiriant rhithwir addasydd rhwydwaith wedi'i blygio i VRouter. Mae VRouter yn fodiwl Ffabrig Twngsten craidd sy'n edrych ar becynnau. Os oes llif eisoes ar gyfer rhyw becyn, mae'r modiwl yn ei brosesu. Os nad oes llif, mae'r modiwl yn gwneud yr hyn a elwir yn puntio, hynny yw, mae'n anfon pecyn i'r broses usermod. Mae'r broses yn dosrannu'r pecyn a naill ai'n ymateb iddo ei hun, fel DHCP a DNS, neu'n dweud wrth VRouter beth i'w wneud ag ef. Ar ôl hynny, gall VRouter brosesu'r pecyn.
Ymhellach, mae traffig rhwng peiriannau rhithwir o fewn yr un rhwydwaith rhithwir yn mynd yn dryloyw, nid yw'n cael ei gyfeirio at CloudGate. Mae'r gwesteiwyr y mae'r peiriannau rhithwir yn cael eu defnyddio arnynt yn cyfathrebu'n uniongyrchol â'i gilydd. Maent yn twnelu traffig ac yn ei anfon ymlaen am ei gilydd trwy'r isgarth.
Mae Awyrennau Rheoli yn cyfathrebu â'i gilydd rhwng parthau argaeledd trwy BGP, fel gyda llwybrydd arall. Maen nhw'n dweud pa beiriannau sydd i fyny ble fel bod VMs mewn un parth yn gallu cyfathrebu'n uniongyrchol â VMs eraill.
Ac mae Control Plane yn cyfathrebu â CloudGate. Yn yr un modd, mae'n adrodd ble a pha beiriannau rhithwir sy'n cael eu codi, pa gyfeiriadau sydd ganddynt. Mae hyn yn eich galluogi i gyfeirio traffig allanol a thraffig o falanswyr atynt.
Mae'r traffig sy'n gadael y VPC yn dod i CloudGate, i'r llwybr data, lle mae'r VPP gyda'n plugins yn cael ei gnoi'n gyflym. Yna caiff y traffig ei danio naill ai i VPCs eraill neu y tu allan, i lwybryddion ffin sy'n cael eu ffurfweddu trwy'r Plane Rheoli CloudGate ei hun.
Cynlluniau ar gyfer y dyfodol agos
Os byddwn yn crynhoi popeth a ddywedwyd uchod mewn ychydig frawddegau, gallwn ddweud bod VPC yn Yandex.Cloud yn datrys dwy dasg bwysig:
- Yn darparu arwahanrwydd rhwng gwahanol gleientiaid.
- Yn cyfuno adnoddau, seilwaith, gwasanaethau platfform, cymylau eraill ac ar y safle yn un rhwydwaith.
Ac er mwyn datrys y problemau hyn yn dda, mae angen i chi ddarparu scalability a goddefgarwch bai ar lefel y bensaernïaeth fewnol, y mae VPC yn ei wneud.
Yn raddol mae VPC yn caffael swyddogaethau, rydym yn gweithredu nodweddion newydd, rydym yn ceisio gwella rhywbeth o ran hwylustod defnyddwyr. Mae rhai syniadau yn cael eu lleisio ac yn mynd ar y rhestr flaenoriaeth diolch i aelodau ein cymuned.
Ar hyn o bryd mae gennym y rhestr ganlynol o gynlluniau ar gyfer y dyfodol agos:
- VPN fel gwasanaeth.
- Mae enghreifftiau DNS preifat yn ddelweddau ar gyfer sefydlu peiriannau rhithwir yn gyflym gyda gweinydd DNS wedi'i ffurfweddu ymlaen llaw.
- DNS fel gwasanaeth.
- Cydbwysedd llwyth mewnol.
- Ychwanegu cyfeiriad IP "gwyn" heb ail-greu'r peiriant rhithwir.
Roedd y balancer a'r gallu i newid y cyfeiriad IP ar gyfer peiriant rhithwir a grëwyd eisoes ar y rhestr hon ar gais defnyddwyr. A dweud y gwir, heb adborth penodol, byddem wedi ymgymryd â'r swyddogaethau hyn ychydig yn ddiweddarach. Ac felly rydym eisoes yn gweithio ar y broblem ynghylch cyfeiriadau.
I ddechrau, dim ond wrth greu peiriant y gellid ychwanegu cyfeiriad IP "gwyn". Pe bai'r defnyddiwr yn anghofio gwneud hyn, roedd yn rhaid ail-greu'r peiriant rhithwir. Yr un peth ac, os oes angen, tynnwch yr IP allanol. Cyn bo hir bydd modd troi’r IP cyhoeddus ymlaen ac i ffwrdd heb orfod ail-greu’r peiriant.
Teimlwch yn rhydd i fynegi eich defnyddwyr eraill. Rydych chi'n ein helpu i wella'r Cwmwl a chael nodweddion pwysig a defnyddiol yn gyflymach!
Ffynhonnell: hab.com