В rhifyn blaenorol Disgrifiais y fframwaith awtomeiddio rhwydwaith. Yn ôl rhai pobl, mae hyd yn oed y dull cyntaf hwn o ymdrin â'r broblem eisoes wedi datrys rhai cwestiynau. Ac mae hyn yn fy ngwneud yn hapus iawn, oherwydd nid yw ein nod yn y cylch yw cwmpasu'r ansible gyda sgriptiau Python, ond i adeiladu system.

Mae'r un fframwaith yn gosod y drefn y byddwn yn ymdrin â'r cwestiwn.
Ac nid yw rhithwiroli rhwydwaith, y mae'r rhifyn hwn yn ymroddedig iddo, yn cyd-fynd yn arbennig â'r pwnc ADSM, lle rydym yn dadansoddi awtomeiddio.

Ond gadewch i ni edrych arno o ongl wahanol.

Mae llawer o wasanaethau wedi bod yn defnyddio'r un rhwydwaith ers amser maith. Yn achos gweithredwr telathrebu, mae hyn yn 2G, 3G, LTE, band eang a B2B, er enghraifft. Yn achos DC: cysylltedd ar gyfer gwahanol gleientiaid, Rhyngrwyd, storio blociau, storio gwrthrychau.

Ac mae angen ynysu pob gwasanaeth oddi wrth ei gilydd. Dyma sut yr ymddangosodd rhwydweithiau troshaen.

Ac nid yw pob gwasanaeth eisiau aros i berson eu ffurfweddu â llaw. Dyma sut yr ymddangosodd cerddorion a SDN.

Mae'r dull cyntaf o awtomeiddio'r rhwydwaith yn systematig, neu yn hytrach yn rhan ohono, wedi'i gymryd a'i weithredu ers amser maith mewn sawl man: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Dyna beth y byddwn yn delio ag ef heddiw.

Cynnwys

• Achosion
• Terminoleg
• Underlay - rhwydwaith ffisegol
• Troshaen - rhwydwaith rhithwir
  • Troshaen gyda ToR
  • Troshaen o'r gwesteiwr
  • Defnyddio Ffabrig Twngsten fel enghraifft
    • Cyfathrebu o fewn un peiriant corfforol
    • Cyfathrebu rhwng VMs sydd wedi'u lleoli ar wahanol beiriannau ffisegol
    • Gadael i'r byd y tu allan

• Cwestiynau Cyffredin
• Casgliad
• Dolenni defnyddiol

Achosion

A chan ein bod yn siarad am hyn, mae'n werth sôn am y rhagofynion ar gyfer rhithwiroli rhwydwaith. Mewn gwirionedd, ni ddechreuodd y broses hon ddoe.

Mae'n debyg eich bod wedi clywed fwy nag unwaith mai'r rhwydwaith fu'r rhan fwyaf anadweithiol o unrhyw system erioed. Ac y mae hyn yn wir ym mhob ystyr. Y rhwydwaith yw'r sail y mae popeth yn dibynnu arno, ac mae gwneud newidiadau arno yn eithaf anodd - nid yw gwasanaethau'n ei oddef pan fydd y rhwydwaith i lawr. Yn aml, gall dadgomisiynu un nod leihau cyfran fawr o geisiadau ac effeithio ar lawer o gwsmeriaid. Dyma'n rhannol pam y gall tîm y rhwydwaith wrthsefyll unrhyw newid - oherwydd nawr mae'n gweithio rywsut (efallai na fyddwn hyd yn oed yn gwybod sut), ond yma mae angen i chi ffurfweddu rhywbeth newydd, ac nid yw'n hysbys sut y bydd yn effeithio ar y rhwydwaith.

Er mwyn peidio ag aros i rwydweithiowyr fewnosod VLANs a pheidio â chofrestru unrhyw wasanaethau ar bob nod rhwydwaith, meddyliodd pobl am y syniad o ddefnyddio troshaenau - rhwydweithiau troshaen - y mae amrywiaeth fawr ohonynt: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, ac ati.

Mae eu hapêl yn gorwedd mewn dau beth syml:

• Dim ond nodau diwedd sydd wedi'u ffurfweddu - nid oes angen cyffwrdd â nodau tramwy. Mae hyn yn cyflymu'r broses yn sylweddol, ac weithiau'n caniatáu ichi eithrio'r adran seilwaith rhwydwaith yn llwyr o'r broses o gyflwyno gwasanaethau newydd.
• Mae'r llwyth wedi'i guddio'n ddwfn y tu mewn i'r penawdau - nid oes angen i nodau tramwy wybod dim amdano, am gyfeiriadau ar y gwesteiwyr, nac am lwybrau'r rhwydwaith troshaen. Mae hyn yn golygu bod angen i chi storio llai o wybodaeth mewn tablau, sy'n golygu defnyddio dyfais symlach/rhatach.

Yn y mater hwn nad yw'n gwbl gyflawn, nid wyf yn bwriadu dadansoddi'r holl dechnolegau posibl, ond yn hytrach yn disgrifio'r fframwaith ar gyfer gweithredu rhwydweithiau troshaenu mewn DCs.

Bydd y gyfres gyfan yn disgrifio canolfan ddata sy'n cynnwys rhesi o raciau union yr un fath lle mae'r un offer gweinydd wedi'i osod.

Mae'r offer hwn yn rhedeg peiriannau rhithwir / cynwysyddion / di-weinydd sy'n gweithredu gwasanaethau.

Terminoleg

Mewn dolen gweinydd Byddaf yn enwi rhaglen sy'n gweithredu ochr gweinydd cyfathrebu cleient-gweinydd.

Gelwir peiriannau ffisegol mewn raciau yn weinyddion dim byddwn yn.

Peiriant corfforol — x86 cyfrifiadur wedi'i osod mewn rac. Y term a ddefnyddir amlaf gwesteiwr. Dyna beth y byddwn yn ei alw "peiriant"Neu gwesteiwr.

Gorweledydd - cymhwysiad sy'n rhedeg ar beiriant ffisegol sy'n efelychu'r adnoddau ffisegol y mae Peiriannau Rhithwir yn rhedeg arnynt. Weithiau mewn llenyddiaeth a'r Rhyngrwyd defnyddir y gair "hypervisor" fel cyfystyr ar gyfer "gwesteiwr".

Peiriant rhithwir - system weithredu sy'n rhedeg ar beiriant corfforol ar ben hypervisor. I ni yn y cylch hwn, nid oes ots a yw'n beiriant rhithwir neu'n gynhwysydd yn unig. Gadewch i ni ei alw'n "VM«

Tenant yn gysyniad eang y byddaf yn ei ddiffinio yn yr erthygl hon fel gwasanaeth ar wahân neu gleient ar wahân.

Aml-denantiaeth neu aml-denantiaeth - defnydd o'r un cymhwysiad gan wahanol gleientiaid/gwasanaethau. Ar yr un pryd, sicrheir ynysu cleientiaid oddi wrth ei gilydd diolch i saernïaeth y cais, ac nid trwy achosion rhedeg ar wahân.

ToR — Switsh Top of the Rack - switsh wedi'i osod mewn rac y mae'r holl beiriannau ffisegol wedi'u cysylltu ag ef.

Yn ogystal â thopoleg ToR, mae darparwyr amrywiol yn ymarfer End of Row (EoR) neu Middle of Row (er bod yr olaf yn brin iawn ac nid wyf wedi gweld y talfyriad MoR).

Rhwydwaith Underlay neu seilwaith y rhwydwaith ffisegol yw'r rhwydwaith gwaelodol neu'r isgarped: switshis, llwybryddion, ceblau.

Rhwydwaith troshaen neu rwydwaith troshaen neu droshaen - rhwydwaith rhithwir o dwneli sy'n rhedeg ar ben yr un ffisegol.

Ffabrig L3 neu ffabrig IP - dyfais anhygoel o ddynolryw sy'n eich galluogi i osgoi ailadrodd STP a dysgu TRILL ar gyfer cyfweliadau. Cysyniad lle mae'r rhwydwaith cyfan hyd at y lefel mynediad yn L3 yn unig, heb VLANs ac, yn unol â hynny, parthau darlledu estynedig enfawr. Byddwn yn edrych i mewn i ble mae'r gair “ffatri” yn dod yn y rhan nesaf.

SDN - Rhwydwaith Diffiniedig Meddalwedd. Prin fod angen cyflwyniad. Dull o reoli rhwydwaith lle mae newidiadau i'r rhwydwaith yn cael eu gwneud nid gan berson, ond gan raglen. Fel arfer mae'n golygu symud yr Awyren Reoli y tu hwnt i'r dyfeisiau rhwydwaith terfynol i'r rheolydd.

NFV — Rhithwiroli Swyddogaethau Rhwydwaith - rhithwiroli dyfeisiau rhwydwaith, sy'n awgrymu y gellir rhedeg rhai swyddogaethau rhwydwaith ar ffurf peiriannau rhithwir neu gynwysyddion i gyflymu'r broses o weithredu gwasanaethau newydd, trefnu Cadwynu Gwasanaeth a scalability llorweddol symlach.

VNF - Swyddogaeth Rhwydwaith Rhithwir. Dyfais rithwir benodol: llwybrydd, switsh, wal dân, NAT, IPS / IDS, ac ati.

Yr wyf yn awr yn symleiddio’r disgrifiad yn fwriadol i weithrediad penodol, er mwyn peidio â drysu’r darllenydd yn ormodol. Am ddarlleniad mwy meddylgar, cyfeiriaf ef at yr adran cyfeiriadau. Yn ogystal, mae Roma Gorge, sy'n beirniadu'r erthygl hon am anghywirdebau, yn addo ysgrifennu rhifyn ar wahân am dechnolegau rhithwiroli gweinyddwyr a rhwydwaith, yn fwy manwl ac yn sylwgar i fanylion.

Gellir rhannu'r rhan fwyaf o rwydweithiau heddiw yn amlwg yn ddwy ran:

Is-haen - rhwydwaith ffisegol gyda chyfluniad sefydlog.
Overlay — tynnu dros Underlay ar gyfer tenantiaid sy'n ynysu.

Mae hyn yn wir yn achos DC (y byddwn yn ei ddadansoddi yn yr erthygl hon) ac ar gyfer ISP (na fyddwn yn ei ddadansoddi, oherwydd ei fod eisoes wedi bod yn SDSM). Gyda rhwydweithiau menter, wrth gwrs, mae'r sefyllfa ychydig yn wahanol.

Llun gyda ffocws ar y rhwydwaith:

Is-haen

Rhwydwaith ffisegol yw Underlay: switshis caledwedd a cheblau. Mae dyfeisiau yn y tanddaear yn gwybod sut i gyrraedd peiriannau ffisegol.

Mae'n dibynnu ar brotocolau a thechnolegau safonol. Yn anad dim oherwydd bod dyfeisiau caledwedd hyd heddiw yn gweithredu ar feddalwedd perchnogol nad yw'n caniatáu naill ai raglennu'r sglodyn na gweithredu ei brotocolau ei hun; yn unol â hynny, mae angen cydnawsedd â gwerthwyr eraill a safoni.

Ond gall rhywun fel Google fforddio datblygu eu switshis eu hunain a rhoi'r gorau i brotocolau a dderbynnir yn gyffredinol. Ond nid Google yw LAN_DC.

Anaml iawn y mae is-haen yn newid oherwydd ei swydd yw cysylltedd IP sylfaenol rhwng peiriannau ffisegol. Nid yw Underlay yn gwybod dim am y gwasanaethau, y cleientiaid, na'r tenantiaid sy'n rhedeg ar ei ben - dim ond o un peiriant i'r llall y mae angen iddo ddosbarthu'r pecyn.
Gallai isgarth fod fel hyn:

• IPv4 + OSPF
• IPv6+ISIS+BGP+L3VPN
• L2+TRILL
• L2+STP

Mae'r rhwydwaith Underlay wedi'i ffurfweddu yn y ffordd glasurol: CLI/GUI/NETCONF.

Gyda llaw, sgriptiau, cyfleustodau perchnogol.

Bydd yr erthygl nesaf yn y gyfres yn cael ei neilltuo i'r isgarth yn fwy manwl.

Overlay

Rhwydwaith rhithwir o dwneli wedi'u hymestyn ar ben Underlay yw Overlay, ac mae'n caniatáu i VMs o un cleient gyfathrebu â'i gilydd, tra'n darparu arwahanrwydd oddi wrth gleientiaid eraill.

Mae'r data cleient wedi'i grynhoi mewn rhai penawdau twnelu i'w trosglwyddo dros y rhwydwaith cyhoeddus.

Felly gall VMs un cleient (un gwasanaeth) gyfathrebu â'i gilydd trwy Overlay, heb hyd yn oed wybod pa lwybr y mae'r pecyn yn ei gymryd mewn gwirionedd.

Gallai troshaen fod, er enghraifft, fel y soniais uchod:

• twnnel GRE
• VXLAN
• EVPN
• L3VPN
• GENI

Mae rhwydwaith troshaen fel arfer yn cael ei ffurfweddu a'i gynnal trwy reolwr canolog. Oddi arno, mae'r cyfluniad, yr Awyren Reoli a'r Plane Data yn cael eu danfon i ddyfeisiau sy'n llwybro ac yn crynhoi traffig cleientiaid. Ychydig isod Gadewch i ni edrych ar hyn gydag enghreifftiau.

Ydy, dyma SDN yn ei ffurf buraf.

Mae dwy ffordd sylfaenol wahanol o drefnu rhwydwaith Troshaenu:

1. Troshaen gyda ToR
2. Troshaen o'r gwesteiwr

Troshaen gyda ToR

Gall troshaen ddechrau ar y switsh mynediad (ToR) yn sefyll yn y rac, fel sy'n digwydd, er enghraifft, yn achos ffabrig VXLAN.

Mae hwn yn fecanwaith prawf amser ar rwydweithiau ISP ac mae pob gwerthwr offer rhwydwaith yn ei gefnogi.

Fodd bynnag, yn yr achos hwn, rhaid i'r switsh ToR allu gwahanu'r gwasanaethau amrywiol, yn y drefn honno, a rhaid i weinyddwr y rhwydwaith, i raddau, gydweithredu â gweinyddwyr y peiriannau rhithwir a gwneud newidiadau (er yn awtomatig) i gyfluniad y dyfeisiau .

Yma cyfeiriaf y darllenydd at erthygl am VxLAN ar Habré ein hen gyfaill @bormoglotx.
Yn hyn cyflwyniadau gydag ENOG disgrifir yn fanwl ddulliau o adeiladu rhwydwaith DC gyda ffabrig EVPN VXLAN.

Ac ar gyfer trochi mwy cyflawn mewn gwirionedd, gallwch ddarllen llyfr Tsiska Ffabrig Modern, Agored a Graddadwy: VXLAN EVPN.

Sylwaf mai dim ond dull amgáu yw VXLAN a gall terfynu twneli ddigwydd nid ar ToR, ond ar y gwesteiwr, fel sy'n digwydd yn achos OpenStack, er enghraifft.

Fodd bynnag, mae ffabrig VXLAN, lle mae'r troshaen yn dechrau yn ToR, yn un o'r dyluniadau rhwydwaith troshaen sefydledig.

Troshaen o'r gwesteiwr

Dull arall yw cychwyn a therfynu twneli ar y gwesteiwyr terfynol.
Yn yr achos hwn, mae'r rhwydwaith (Underlay) yn parhau i fod mor syml a sefydlog â phosibl.
Ac mae'r gwesteiwr ei hun yn gwneud yr holl amgáu angenrheidiol.

Bydd hyn wrth gwrs yn gofyn am redeg cais arbennig ar y gwesteiwyr, ond mae'n werth chweil.

Yn gyntaf, mae rhedeg cleient ar beiriant Linux yn haws neu, gadewch i ni ddweud, hyd yn oed yn bosibl, tra ar switsh mae'n debyg y bydd yn rhaid i chi droi at atebion SDN perchnogol, sy'n lladd y syniad o aml-werthwr.

Yn ail, gellir gadael y switsh ToR yn yr achos hwn mor syml â phosibl, o safbwynt yr Awyren Reoli a'r Plane Data. Yn wir, yna nid oes angen iddo gyfathrebu â'r rheolwr SDN, ac nid oes angen iddo hefyd storio rhwydweithiau / ARPs yr holl gleientiaid cysylltiedig - mae'n ddigon gwybod cyfeiriad IP y peiriant corfforol, sy'n symleiddio'r newid yn fawr / byrddau llwybro.

Yn y gyfres ADSM, rwy'n dewis y dull troshaenu gan y gwesteiwr - yna dim ond sôn amdano y byddwn yn ei ddweud ac ni fyddwn yn dychwelyd i'r ffatri VXLAN.

Mae'n haws edrych ar enghreifftiau. Ac fel pwnc prawf byddwn yn cymryd y llwyfan SDN OpenSource OpenContrail, a elwir bellach yn Ffabrig Twngsten.

Ar ddiwedd yr erthygl byddaf yn rhoi rhai meddyliau ar y gyfatebiaeth ag OpenFlow ac OpenvSwitch.

Defnyddio Ffabrig Twngsten fel enghraifft

Mae gan bob peiriant corfforol vRouter - llwybrydd rhithwir sy'n gwybod am y rhwydweithiau sy'n gysylltiedig ag ef a pha gleientiaid y maent yn perthyn iddynt - llwybrydd AG yn ei hanfod. Ar gyfer pob cleient, mae'n cynnal tabl llwybro ynysig (darllenwch VRF). Ac mae vRouter yn gwneud twnelu Overlay mewn gwirionedd.

Mae ychydig mwy am vRouter ar ddiwedd yr erthygl.

Mae pob VM sydd wedi'i leoli ar yr hypervisor wedi'i gysylltu â vRouter y peiriant hwn trwy rhyngwyneb TAP.

TAP - Terminal Access Point - rhyngwyneb rhithwir yn y cnewyllyn Linux sy'n caniatáu rhyngweithio rhwydwaith.

Os oes sawl rhwydwaith y tu ôl i'r vRouter, yna mae rhyngwyneb rhithwir yn cael ei greu ar gyfer pob un ohonynt, y rhoddir cyfeiriad IP iddo - hwn fydd y cyfeiriad porth rhagosodedig.
Mae holl rwydweithiau un cleient yn cael eu gosod mewn un VRF (un bwrdd), rhai gwahanol - i mewn i rai gwahanol.
Fe wnaf ymwadiad yma nad yw popeth mor syml, a byddaf yn anfon y darllenydd chwilfrydig i ddiwedd yr erthygl.

Er mwyn i vRouters allu cyfathrebu â'i gilydd, ac yn unol â hynny y VMs sydd y tu ôl iddynt, maent yn cyfnewid gwybodaeth llwybro trwy Rheolydd SDN.

I fynd allan i'r byd y tu allan, mae man ymadael o'r matrics - porth rhwydwaith rhithwir VNGW - Porth Rhwydwaith Rhithwir (fy nhymor).

Nawr, gadewch i ni edrych ar enghreifftiau o gyfathrebu - a bydd eglurder.

Cyfathrebu o fewn un peiriant corfforol

Mae VM0 eisiau anfon pecyn i VM2. Gadewch i ni dybio am y tro mai VM cleient sengl yw hwn.

Awyren Data

1. Mae gan VM-0 lwybr rhagosodedig i'w ryngwyneb eth0. Anfonir y pecyn yno.
   Mae'r rhyngwyneb hwn eth0 mewn gwirionedd wedi'i gysylltu bron â'r llwybrydd rhithwir vRouter trwy'r rhyngwyneb TAP tap0.
2. Mae vRouter yn dadansoddi i ba ryngwyneb y daeth y pecyn, hynny yw, i ba gleient (VRF) y mae'n perthyn, ac yn gwirio cyfeiriad y derbynnydd gyda thabl llwybro'r cleient hwn.
3. Ar ôl canfod bod y derbynnydd ar yr un peiriant ar borthladd gwahanol, mae vRouter yn anfon y pecyn ato heb unrhyw benawdau ychwanegol - yn yr achos hwn, mae gan vRouter gofnod ARP eisoes.

Yn yr achos hwn, nid yw'r pecyn yn mynd i mewn i'r rhwydwaith ffisegol - mae'n cael ei gyfeirio y tu mewn i'r vRouter.

Plân Rheoli

Pan fydd y peiriant rhithwir yn cychwyn, mae'r hypervisor yn dweud wrtho:

• Ei chyfeiriad IP ei hun.
• Y llwybr rhagosodedig yw trwy gyfeiriad IP y vRouter ar y rhwydwaith hwn.

Mae'r hypervisor yn adrodd i vRouter trwy API arbennig:

• Yr hyn sydd ei angen arnoch i greu rhyngwyneb rhithwir.
• Pa fath o rwydwaith rhithwir y mae angen iddo (VM) ei greu?
• Pa VRF (VN) i'w rwymo iddo.
• Cofnod ARP statig ar gyfer y VM hwn - pa ryngwyneb sydd y tu ôl i'w gyfeiriad IP a pha gyfeiriad MAC y mae'n gysylltiedig ag ef.

Unwaith eto, mae'r weithdrefn ryngweithio wirioneddol yn cael ei symleiddio er mwyn deall y cysyniad.

Felly, mae vRouter yn gweld holl VMs un cleient ar beiriant penodol fel rhwydweithiau sydd wedi'u cysylltu'n uniongyrchol a gall lwybro rhyngddynt ei hun.

Ond mae VM0 a VM1 yn perthyn i wahanol gleientiaid ac, yn unol â hynny, mewn gwahanol dablau vRouter.

Mae p'un a allant gyfathrebu â'i gilydd yn uniongyrchol yn dibynnu ar y gosodiadau vRouter a dyluniad rhwydwaith.
Er enghraifft, os yw VMs y ddau gleient yn defnyddio cyfeiriadau cyhoeddus, neu os yw NAT yn digwydd ar y vRouter ei hun, yna gellir gwneud llwybr uniongyrchol i'r vRouter.

Yn y sefyllfa arall, mae'n bosibl croesi bylchau cyfeiriad - mae angen i chi fynd trwy weinydd NAT i gael cyfeiriad cyhoeddus - mae hyn yn debyg i gael mynediad at rwydweithiau allanol, a drafodir isod.

Cyfathrebu rhwng VMs sydd wedi'u lleoli ar wahanol beiriannau ffisegol

Awyren Data

1. Mae'r dechrau yn union yr un fath: mae VM-0 yn anfon pecyn gyda'r cyrchfan VM-7 (172.17.3.2) yn ei ragosodiad.
2. vRouter yn ei dderbyn a'r tro hwn yn gweld bod y gyrchfan ar beiriant gwahanol ac yn hygyrch trwy Twnnel0.
3. Yn gyntaf, mae'n hongian label MPLS sy'n nodi'r rhyngwyneb anghysbell, fel y gall vRouter ar y cefn benderfynu ble i osod y pecyn hwn heb edrychiadau ychwanegol.

   

4. Mae gan Twnnel0 ffynhonnell 10.0.0.2, cyrchfan: 10.0.1.2.
   vRouter yn ychwanegu penawdau GRE (neu CDU) ac IP newydd i'r pecyn gwreiddiol.
5. Mae gan dabl llwybro vRouter lwybr rhagosodedig trwy'r cyfeiriad ToR1 10.0.0.1. Dyna lle mae'n ei anfon.

   
   

6. Mae ToR1, fel aelod o rwydwaith Underlay, yn gwybod (er enghraifft, trwy OSPF) sut i gyrraedd 10.0.1.2 ac yn anfon y pecyn ar hyd y llwybr. Sylwch fod ECMP wedi'i alluogi yma. Mae dau hops nesaf yn y llun, a bydd gwahanol edafedd yn cael eu didoli i mewn iddynt trwy hash. Yn achos ffatri go iawn, mae'n fwy tebygol y bydd 4 hops nesaf.

   Ar yr un pryd, nid oes angen iddo wybod beth sydd o dan y pennawd IP allanol. Hynny yw, mewn gwirionedd, o dan IP gall fod brechdan o IPv6 dros MPLS dros Ethernet dros MPLS dros GRE drosodd dros Groeg.

7. Yn unol â hynny, ar yr ochr dderbyn, mae vRouter yn tynnu GRE ac, gan ddefnyddio'r tag MPLS, yn deall i ba ryngwyneb y dylid anfon y pecyn hwn, yn ei stripio a'i anfon yn ei ffurf wreiddiol at y derbynnydd.

Plân Rheoli

Pan ddechreuwch y car, mae'r un peth yn digwydd fel y disgrifir uchod.

Ac yn ogystal â'r canlynol:

• Ar gyfer pob cleient, mae vRouter yn dyrannu tag MPLS. Dyma'r label gwasanaeth L3VPN, lle bydd cleientiaid yn cael eu gwahanu o fewn yr un peiriant corfforol.
  

  Mewn gwirionedd, mae'r tag MPLS bob amser yn cael ei ddyrannu'n ddiamod gan y vRouter - wedi'r cyfan, nid yw'n hysbys ymlaen llaw y bydd y peiriant ond yn rhyngweithio â pheiriannau eraill y tu ôl i'r un vRouter ac nid yw hyn yn fwyaf tebygol hyd yn oed yn wir.

• vRouter yn sefydlu cysylltiad â'r rheolydd SDN gan ddefnyddio'r protocol BGP (neu debyg iddo - yn achos TF, dyma XMPP 0_o).
• Trwy'r sesiwn hon, mae vRouter yn adrodd am lwybrau i rwydweithiau cysylltiedig i'r rheolydd SDN:
  • Cyfeiriad rhwydwaith
  • Dull amgáu (MPLSoGRE, MPLSoUDP, VXLAN)
  • Tag cleient MPLS
  • Eich cyfeiriad IP fel nexthop

• Mae'r rheolydd SDN yn derbyn llwybrau o'r fath gan bob vRouters cysylltiedig ac yn eu hadlewyrchu i eraill. Hynny yw, mae'n gweithredu fel Adlewyrchydd Llwybr.

Mae'r un peth yn digwydd i'r cyfeiriad arall.

Gall troshaen newid o leiaf bob munud. Dyma'n fras beth sy'n digwydd mewn cymylau cyhoeddus, lle mae cleientiaid yn cychwyn ac yn cau eu peiriannau rhithwir yn rheolaidd.

Mae'r rheolwr canolog yn gofalu am yr holl gymhlethdod o gynnal y cyfluniad a monitro'r tablau newid / llwybro ar y vRouter.

Yn fras, mae'r rheolydd yn cyfathrebu â'r holl vRouters trwy BGP (neu brotocol tebyg) ac yn syml yn trosglwyddo gwybodaeth llwybro. Mae gan BGP, er enghraifft, eisoes Address-Family i gyfleu'r dull amgáu MPLS-yn-GRE neu MPLS-yn-CDU.

Ar yr un pryd, nid yw cyfluniad y rhwydwaith Underlay yn newid mewn unrhyw ffordd, sydd, gyda llaw, yn llawer anoddach i'w awtomeiddio, ac yn haws ei dorri gyda symudiad lletchwith.

Gadael i'r byd y tu allan

Rhywle mae'n rhaid i'r efelychiad ddod i ben, ac mae angen i chi adael y byd rhithwir i'r un go iawn. Ac mae angen porth ffôn talu arnoch chi.

Mae dau ddull yn cael eu hymarfer:

1. Mae llwybrydd caledwedd wedi'i osod.
2. Mae teclyn yn cael ei lansio sy'n gweithredu swyddogaethau llwybrydd (ie, yn dilyn SDN, daethom ar draws VNF hefyd). Gadewch i ni ei alw'n borth rhithwir.

Mantais yr ail ddull yw scalability llorweddol rhad - nid oes digon o bŵer - fe wnaethom lansio peiriant rhithwir arall gyda phorth. Ar unrhyw beiriant corfforol, heb orfod chwilio am raciau rhad ac am ddim, unedau, allbwn pŵer, prynwch y caledwedd ei hun, ei gludo, ei osod, ei newid, ei ffurfweddu, ac yna hefyd newid cydrannau diffygiol ynddo.

Anfanteision porth rhithwir yw bod uned o lwybrydd corfforol yn dal i fod yn orchmynion maint yn fwy pwerus na pheiriant rhithwir aml-graidd, ac mae ei feddalwedd, wedi'i deilwra i'w sylfaen caledwedd ei hun, yn gweithio'n llawer mwy sefydlog (dim). Mae hefyd yn anodd gwadu'r ffaith bod y cymhleth caledwedd a meddalwedd yn gweithio'n syml, sy'n gofyn am gyfluniad yn unig, tra bod lansio a chynnal porth rhithwir yn dasg i beirianwyr cryf.

Gydag un droed, mae'r porth yn edrych i mewn i'r rhwydwaith rhithwir Overlay, fel Peiriant Rhithwir rheolaidd, a gall ryngweithio â phob VM arall. Ar yr un pryd, gall derfynu rhwydweithiau'r holl gleientiaid ac, yn unol â hynny, cynnal llwybr rhyngddynt.

Gyda'i droed arall, mae'r porth yn edrych i mewn i'r rhwydwaith asgwrn cefn ac yn gwybod sut i fynd ar y Rhyngrwyd.

Awyren Data

Hynny yw, mae'r broses yn edrych fel hyn:

1. Mae VM-0, ar ôl methu â'r un vRouter, yn anfon pecyn gyda chyrchfan yn y byd y tu allan (185.147.83.177) i'r rhyngwyneb eth0.
2. Mae vRouter yn derbyn y pecyn hwn ac yn edrych i fyny'r cyfeiriad cyrchfan yn y tabl llwybro - yn dod o hyd i'r llwybr rhagosodedig trwy borth VNGW1 trwy Dwnnel 1.
   Mae hefyd yn gweld mai twnnel GRE yw hwn gyda SIP 10.0.0.2 a DIP 10.0.255.2, ac mae angen iddo hefyd atodi label MPLS y cleient hwn yn gyntaf, y mae VNGW1 yn ei ddisgwyl.
3. Mae vRouter yn pacio'r pecyn cychwynnol gyda MPLS, GRE a phenawdau IP newydd ac yn ei anfon i'r cyfeiriad ToR1 10.0.0.1 yn ddiofyn.
4. Mae'r rhwydwaith gwaelodol yn danfon y pecyn i'r porth VNGW1.
5. Mae porth VNGW1 yn dileu penawdau twnelu GRE ac MPLS, yn gweld y cyfeiriad cyrchfan, yn ymgynghori â'i fwrdd llwybro ac yn deall ei fod yn cael ei gyfeirio at y Rhyngrwyd - hynny yw, trwy Full View neu Default. Os oes angen, cyflawni cyfieithiad NAT.
6. Gallai fod rhwydwaith IP rheolaidd o VNGW i'r ffin, sy'n annhebygol.
   Efallai y bydd rhwydwaith MPLS clasurol (IGP + LDP / RSVP TE), efallai y bydd ffabrig cefn gyda BGP LU neu dwnnel GRE o VNGW i'r ffin trwy rwydwaith IP.
   Boed hynny ag y bo modd, mae VNGW1 yn perfformio'r amgaeadau angenrheidiol ac yn anfon y pecyn cychwynnol tuag at y ffin.

Mae traffig i'r cyfeiriad arall yn mynd trwy'r un camau yn y drefn arall.

1. Mae'r ffin yn gollwng y pecyn i VNGW1
2. Mae'n ei ddadwisgo, yn edrych ar gyfeiriad y derbynnydd ac yn gweld ei fod yn hygyrch trwy dwnnel Twnnel1 (MPLSoGRE neu MPLSoUDP).
3. Yn unol â hynny, mae'n atodi label MPLS, pennawd GRE / CDU ac IP newydd ac yn ei anfon at ei ToR3 10.0.255.1.
   Cyfeiriad cyrchfan y twnnel yw cyfeiriad IP y vRouter y mae'r VM targed wedi'i leoli y tu ôl iddo - 10.0.0.2.
4. Mae'r rhwydwaith gwaelodol yn danfon y pecyn i'r vRouter a ddymunir.
5. Mae'r vRouter targed yn darllen GRE / CDU, yn nodi'r rhyngwyneb gan ddefnyddio label MPLS ac yn anfon pecyn IP noeth i'w ryngwyneb TAP sy'n gysylltiedig ag eth0 y VM.

Plân Rheoli

Mae VNGW1 yn sefydlu cymdogaeth BGP gyda rheolydd SDN, y mae'n derbyn yr holl wybodaeth llwybro am gleientiaid ohono: pa gyfeiriad IP (vRouter) sydd y tu ôl i ba gleient, a pha label MPLS y mae'n cael ei nodi ganddo.

Yn yr un modd, mae ef ei hun yn hysbysu'r rheolwr SDN o'r llwybr rhagosodedig gyda label y cleient hwn, gan nodi ei hun fel y nexthop. Ac yna mae'r rhagosodiad hwn yn cyrraedd vRouters.

Ar VNGW, mae agregu llwybrau neu gyfieithu NAT fel arfer yn digwydd.

Ac i'r cyfeiriad arall, mae'n anfon y llwybr cyfanredol hwn yn union i'r sesiwn gyda ffiniau neu Adlewyrchwyr Llwybr. Ac oddi wrthynt mae'n derbyn y llwybr rhagosodedig neu Full-View, neu rywbeth arall.

O ran amgáu a chyfnewid traffig, nid yw VNGW yn wahanol i vRouter.
Os ydych chi'n ehangu'r cwmpas ychydig, yna gallwch chi ychwanegu dyfeisiau rhwydwaith eraill at VNGWs a vRouters, megis waliau tân, glanhau traffig neu ffermydd cyfoethogi, IPS, ac ati.

A chyda chymorth creu VRFs yn ddilyniannol a chyhoeddi llwybrau'n gywir, gallwch orfodi traffig i ddolennu'r ffordd rydych chi ei eisiau, a elwir yn Gadwyn Gwasanaeth.

Hynny yw, yma hefyd mae rheolydd SDN yn gweithredu fel Adlewyrchydd Llwybr rhwng VNGWs, vRouters a dyfeisiau rhwydwaith eraill.

Ond mewn gwirionedd, mae'r rheolydd hefyd yn rhyddhau gwybodaeth am ACL a PBR (Llwybrau ar Sail Polisi), gan achosi llif traffig unigol i fynd yn wahanol nag y mae'r llwybr yn dweud wrthynt am.

Cwestiynau Cyffredin

Pam ydych chi'n dal i wneud y sylw GRE/CDU?

Wel, yn gyffredinol, gellir dweud bod hyn yn benodol i Ffabrig Twngsten - nid oes rhaid i chi ei gymryd i ystyriaeth o gwbl.

Ond os byddwn yn ei gymryd, roedd TF ei hun, er ei fod yn dal i fod OpenContrail, yn cefnogi'r ddau amgapsiwleiddiad: MPLS yn GRE ac MPLS yn y CDU.

Mae CDU yn dda oherwydd yn y Porthladd Ffynhonnell mae'n hawdd iawn amgodio swyddogaeth hash o'r IP + Proto + Port gwreiddiol yn ei bennawd, a fydd yn caniatáu ichi wneud cydbwysedd.

Yn achos GRE, gwaetha'r modd, dim ond penawdau IP a GRE allanol sydd, sydd yr un peth ar gyfer yr holl draffig sydd wedi'i grynhoi ac nid oes sôn am gydbwyso - ychydig o bobl sy'n gallu edrych mor ddwfn y tu mewn i'r pecyn.

Hyd at beth amser, roedd llwybryddion, pe baent yn gwybod sut i ddefnyddio twneli deinamig, yn gwneud hynny yn MPLSoGRE yn unig, a dim ond yn ddiweddar iawn y gwnaethant ddysgu defnyddio MPLSoUDP. Felly, mae'n rhaid i ni bob amser wneud nodyn am y posibilrwydd o ddau grynhoad gwahanol.

Er tegwch, mae'n werth nodi bod TF yn cefnogi cysylltedd L2 yn llawn gan ddefnyddio VXLAN.

Fe wnaethoch chi addo llunio cyffelybiaethau ag OpenFlow.
Maen nhw wir yn gofyn amdano. Mae vSwitch yn yr un OpenStack yn gwneud pethau tebyg iawn, gan ddefnyddio VXLAN, sydd, gyda llaw, â phennawd CDU hefyd.

Yn yr Awyren Ddata maent yn gweithio tua'r un peth; mae'r Awyren Reoli yn gwahaniaethu'n sylweddol. Mae Twngsten Fabric yn defnyddio XMPP i gyflwyno gwybodaeth llwybro i vRouter, tra bod OpenStack yn rhedeg Openflow.

A allwch chi ddweud ychydig mwy wrthyf am vRouter?
Mae wedi'i rannu'n ddwy ran: vRouter Agent a vRouter Forwarder.

Mae'r un cyntaf yn rhedeg yn y Gofod Defnyddiwr yr OS gwesteiwr ac yn cyfathrebu â'r rheolwr SDN, gan gyfnewid gwybodaeth am lwybrau, VRFs ac ACLs.

Mae'r ail yn gweithredu Data Plane - fel arfer yn Kernel Space, ond gall hefyd redeg ar SmartNICs - cardiau rhwydwaith gyda CPU a sglodyn newid rhaglenadwy ar wahân, sy'n eich galluogi i dynnu'r llwyth o CPU y peiriant gwesteiwr, a gwneud y rhwydwaith yn gyflymach ac yn fwy rhagweladwy.

Senario posibl arall yw bod vRouter yn gymhwysiad DPK yn User Space.

vRouter Asiant yn anfon gosodiadau i vRouter Forwarder.

Beth yw Rhwydwaith Rhithwir?
Soniais ar ddechrau'r erthygl am VRF bod pob tenant yn gysylltiedig â'i VRF ei hun. Ac os oedd hyn yn ddigon ar gyfer dealltwriaeth arwynebol o weithrediad y rhwydwaith troshaen, yna ar yr iteriad nesaf mae angen gwneud eglurhad.

Yn nodweddiadol, mewn mecanweithiau rhithwiroli, cyflwynir yr endid Rhwydwaith Rhithwir (gallwch ystyried hwn yn enw iawn) ar wahân i gleientiaid / tenantiaid / peiriannau rhithwir - peth cwbl annibynnol. A gellir cysylltu'r Rhwydwaith Rhithwir hwn eisoes trwy ryngwynebau i un tenant, i un arall, i ddau, neu unrhyw le. Felly, er enghraifft, gweithredir Cadwynu Gwasanaeth pan fydd angen pasio traffig trwy nodau penodol yn y dilyniant gofynnol, yn syml trwy greu a chysylltu Rhwydweithiau Rhithwir yn y dilyniant cywir.

Felly, fel y cyfryw, nid oes unrhyw ohebiaeth uniongyrchol rhwng y Rhwydwaith Rhithwir a'r tenant.

Casgliad

Mae hwn yn ddisgrifiad arwynebol iawn o weithrediad rhwydwaith rhithwir gyda throshaen o'r gwesteiwr a rheolydd SDN. Ond ni waeth pa lwyfan rhithwiroli a ddewiswch heddiw, bydd yn gweithio mewn ffordd debyg, boed yn VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric neu Juniper Contrail. Byddant yn wahanol o ran y mathau o amgáu a phenawdau, protocolau ar gyfer cyflwyno gwybodaeth i ddiwedd dyfeisiau rhwydwaith, ond bydd yr egwyddor o rwydwaith troshaen y gellir ei ffurfweddu gan feddalwedd sy'n gweithredu ar ben rhwydwaith isgarped cymharol syml a sefydlog yn aros yr un fath.
Gallwn ddweud bod SDN heddiw yn seiliedig ar rwydwaith troshaen wedi ennill y maes o greu cwmwl preifat. Fodd bynnag, nid yw hyn yn golygu nad oes gan Openflow le yn y byd modern - fe'i defnyddir yn OpenStacke ac yn yr un VMWare NSX, cyn belled ag y gwn, mae Google yn ei ddefnyddio i sefydlu'r rhwydwaith tanddaearol.

Isod rwyf wedi darparu dolenni i ddeunyddiau mwy manwl os ydych chi am astudio'r mater yn ddyfnach.

A beth am ein Underlay?

Ond yn gyffredinol, dim byd. Wnaeth e ddim newid yr holl ffordd. Y cyfan sydd angen iddo ei wneud yn achos troshaen gan y gwesteiwr yw llwybrau diweddaru ac ARPs wrth i vRouter / VNGW ymddangos a diflannu a chario pecynnau rhyngddynt.

Gadewch i ni lunio rhestr o ofynion ar gyfer y rhwydwaith Underlay.

1. Gallu defnyddio rhyw fath o brotocol llwybro, yn ein sefyllfa ni - BGP.
2. Bod â lled band eang, yn ddelfrydol heb ordanysgrifio, fel nad yw pecynnau'n cael eu colli oherwydd gorlwytho.
3. Mae cefnogi ECMP yn rhan annatod o'r ffabrig.
4. Gallu darparu QoS, gan gynnwys pethau dyrys fel ECN.
5. Mae cefnogi NETCONF yn sylfaen ar gyfer y dyfodol.

Ychydig iawn o amser a dreuliais yma i waith rhwydwaith Underlay ei hun. Mae hyn oherwydd yn ddiweddarach yn y gyfres byddaf yn canolbwyntio arno, a byddwn yn cyffwrdd yn unig ar Overlay wrth fynd heibio.

Yn amlwg, rwy'n cyfyngu'n ddifrifol ar bob un ohonom trwy ddefnyddio, fel enghraifft, rwydwaith DC a adeiladwyd mewn ffatri Cloz gyda llwybro IP pur a throshaen gan y gwesteiwr.

Fodd bynnag, yr wyf yn hyderus y gellir disgrifio unrhyw rwydwaith sydd â chynllun yn ffurfiol ac yn awtomataidd. Fy nod yma yw deall dulliau awtomeiddio, a pheidio â drysu pawb trwy ddatrys y broblem ar ffurf gyffredinol.

Fel rhan o ADSM, mae Roman Gorge a minnau'n bwriadu cyhoeddi rhifyn ar wahân ynghylch rhithwiroli pŵer cyfrifiadurol a'i ryngweithio â rhithwiroli rhwydwaith. Cadwch mewn cysylltiad.

Dolenni defnyddiol

• Archvitecture Ffabrig Twngsten.
• am: cwmwl. 6 awr am Yandex.Cloud, sydd hefyd yn cwmpasu'r rhwydwaith rhithwir ar TF.
• Beth yw Open vSwitch?
• Cyflwyniad i VxLAN.
• RFC 7348. Rhwydwaith Ardal Leol Rhithiol Estynadwy (VXLAN): Fframwaith ar gyfer Troshaenu Rhwydweithiau Haen 2 Rhithwir dros Rwydweithiau Haen 3.
  
• Agwedd graddfa tuag at Ffabrig EVPN VXLAN. Mae'n sôn am y rhwydwaith DC cyfan, gan gynnwys Underlay, Overlay, ymagweddau at aml-gartrefu a rheolaeth.

Diolch

• Gorga Rhufeinig - cyn westeiwr y podlediad linkmeup ac yn awr yn arbenigwr ym maes llwyfannau cwmwl. Am sylwadau a golygiadau. Wel, rydym yn aros am ei erthygl fanylach ar rithwiroli yn y dyfodol agos.
• Alexander Shalimov - fy nghydweithiwr ac arbenigwr ym maes datblygu rhwydwaith rhithwir. Am sylwadau a golygiadau.
• Valentin Sinitsyn - fy nghydweithiwr ac arbenigwr ym maes Ffabrig Twngsten. Am sylwadau a golygiadau.
• Artyom Chernobay — darlunydd linkmeup. Ar gyfer KDPV.
• Alexander Limonov. Ar gyfer y meme "awtomato".

Ffynhonnell: hab.com