В Aprašiau tinklo automatizavimo sistemą. Kai kurių žmonių teigimu, net šis pirmasis požiūris į problemą jau išsprendė kai kuriuos klausimus. Ir tai mane labai džiugina, nes mūsų tikslas cikle yra ne apdengti ansible Python scenarijais, o sukurti sistemą.
Ta pati sistema nustato tvarką, kuria spręsime klausimą.
O tinklo virtualizacija, kuriai skirtas šis numeris, nelabai tinka ADSM temai, kur analizuojame automatizavimą.
Tačiau pažvelkime į tai kitu kampu.
Daugelis paslaugų ilgą laiką naudoja tą patį tinklą. Pavyzdžiui, telekomunikacijų operatoriaus atveju tai yra 2G, 3G, LTE, plačiajuostis ryšys ir B2B. Nuolatinės srovės atveju: jungtis skirtingiems klientams, internetas, blokinė saugykla, objektų saugykla.
Ir visos paslaugos reikalauja izoliacijos viena nuo kitos. Taip atsirado perdangos tinklai.
Ir visos paslaugos nenori laukti, kol žmogus jas sukonfigūruos rankiniu būdu. Taip atsirado orkestrantai ir SDN.
Pirmasis požiūris į sistemingą tinklo, tiksliau jo dalies automatizavimą, jau seniai priimtas ir įdiegtas daugelyje vietų: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
Štai ką mes šiandien sprendžiame.
Turinys
- priežastys
- terminologija
- Apatinis sluoksnis – fizinis tinklas
- Perdanga – virtualus tinklas
- Perdanga su ToR
- Perdanga iš prieglobos
- Kaip pavyzdį naudojant volframo audinį
- Ryšys vienoje fizinėje mašinoje
- Ryšys tarp skirtinguose fiziniuose įrenginiuose esančių VM
- Išėjimas į išorinį pasaulį
- Dažnai užduodami klausimai
- išvada
- Naudingos nuorodos
priežastys
Ir kadangi mes apie tai kalbame, verta paminėti būtinas tinklo virtualizavimo sąlygas. Tiesą sakant, šis procesas prasidėjo ne vakar.
Tikriausiai ne kartą girdėjote, kad tinklas visada buvo pati inertiškiausia bet kurios sistemos dalis. Ir tai tiesa visomis prasmėmis. Tinklas yra pagrindas, ant kurio viskas remiasi, o atlikti pakeitimus jame yra gana sunku – paslaugos to netoleruoja, kai tinklas neveikia. Dažnai vieno mazgo eksploatavimo nutraukimas gali panaikinti didelę programų dalį ir paveikti daugelį klientų. Iš dalies dėl šios priežasties tinklo komanda gali priešintis bet kokiems pokyčiams, nes dabar tai kažkaip veikia (mes gal net nežinome kaip), bet čia reikia sukonfigūruoti ką nors naujo, ir nežinia, kaip tai paveiks tinklą.
Kad nelauktumėte, kol tinklo kūrėjai įterps VLAN ir neregistruos jokių paslaugų kiekviename tinklo mazge, žmonės sugalvojo naudoti perdangas - perdangos tinklus, kurių yra labai daug: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE ir kt.
Jų patrauklumas slypi dviem paprastais dalykais:
- Konfigūruojami tik galiniai mazgai – tranzito mazgų liesti nereikia. Tai žymiai pagreitina procesą ir kartais leidžia visiškai pašalinti tinklo infrastruktūros skyrių iš naujų paslaugų įvedimo proceso.
- Krovinys paslėptas giliai antraštėse – tranzito mazgams nereikia nieko žinoti apie tai, apie adresavimą pagrindiniuose kompiuteriuose ar perdangos tinklo maršrutus. Tai reiškia, kad lentelėse reikia kaupti mažiau informacijos, vadinasi, naudoti paprastesnį/pigesnį įrenginį.
Šiame ne visai pilname numeryje neplanuoju analizuoti visų galimų technologijų, o apibūdinti perdangos tinklų veikimo DC pagrindus.
Visoje serijoje bus aprašytas duomenų centras, susidedantis iš identiškų stelažų eilių, kuriuose įdiegta ta pati serverio įranga.
Ši įranga paleidžia virtualias mašinas / konteinerius / be serverio, kurie įgyvendina paslaugas.
terminologija
Kilpoje serveris Pavadinsiu programą, kuri įgyvendina kliento ir serverio komunikacijos serverio pusę.
Stelažuose esančios fizinės mašinos vadinamos serveriais ne mes.
Fizinė mašina — x86 kompiuteris, sumontuotas stove. Dažniausiai vartojamas terminas priimančioji. Taip mes tai pavadinsime"automobilisarba priimančioji.
hipervizorius - fiziniame kompiuteryje veikianti programa, kuri imituoja fizinius išteklius, kuriuose veikia virtualios mašinos. Kartais literatūroje ir internete žodis „hipervizorius“ vartojamas kaip „host“ sinonimas.
Virtuali mašina - operacinė sistema, veikianti fiziniame kompiuteryje, hipervizoriaus viršuje. Mums šiame cikle nelabai svarbu, ar tai iš tikrųjų virtuali mašina, ar tik konteineris. Pavadinkime tai "VM«
Nuomininkas yra plati sąvoka, kurią šiame straipsnyje apibrėžiu kaip atskirą paslaugą arba atskirą klientą.
Daugiabučiai nuomai arba daugiapakopė nuoma – skirtingų klientų/paslaugų naudojimasis ta pačia programa. Tuo pačiu metu klientai vienas nuo kito atskiriami dėl programos architektūros, o ne per atskirai veikiančius egzempliorius.
ToR – stovo viršaus jungiklis - jungiklis, sumontuotas stove, prie kurio prijungtos visos fizinės mašinos.
Be ToR topologijos, įvairūs tiekėjai praktikuoja End of Row (EoR) arba Middle of Row (nors pastaroji yra menkinanti retenybė ir aš nemačiau MoR santrumpos).
Pakloto tinklas arba pagrindinis tinklas arba apatinis sluoksnis yra fizinė tinklo infrastruktūra: komutatoriai, maršrutizatoriai, kabeliai.
Perdangos tinklas arba perdangos tinklas arba perdanga – virtualus tunelių tinklas, einantis virš fizinio.
L3 audinys arba IP audinys - nuostabus žmonijos išradimas, leidžiantis nekartoti STP ir mokytis TRILL pokalbiams. Koncepcija, kurioje visas tinklas iki prieigos lygio yra išskirtinai L3, be VLAN ir, atitinkamai, didžiulių išplėstinių transliavimo domenų. Kitoje dalyje panagrinėsime, iš kur kilęs žodis „gamykla“.
SDN - Programinės įrangos nustatytas tinklas. Įžangos vargu ar reikia. Tinklo valdymo metodas, kai tinklo pakeitimus atlieka ne žmogus, o programa. Paprastai tai reiškia valdymo plokštumos perkėlimą už galinių tinklo įrenginių į valdiklį.
NFV — Tinklo funkcijų virtualizavimas – tinklo įrenginių virtualizavimas, leidžiantis manyti, kad kai kurios tinklo funkcijos gali būti vykdomos virtualių mašinų arba konteinerių pavidalu, siekiant paspartinti naujų paslaugų įgyvendinimą, organizuoti paslaugų grandinę ir paprastesnį horizontalųjį mastelį.
VNF - Virtualaus tinklo funkcija. Konkretus virtualus įrenginys: maršrutizatorius, jungiklis, ugniasienė, NAT, IPS/IDS ir kt.
Dabar aš sąmoningai supaprastinu aprašymą iki konkretaus įgyvendinimo, kad per daug nesupainiočiau skaitytojo. Jei norite daugiau apgalvoto skaitymo, nukreipiu jį į skyrių . Be to, Roma Gorge, kritikuojantis šį straipsnį dėl netikslumų, žada parašyti atskirą numerį apie serverių ir tinklo virtualizacijos technologijas, gilesnę ir atidesnę detalėms.
Daugumą tinklų šiandien galima aiškiai suskirstyti į dvi dalis:
Paklotas — fizinis tinklas su stabilia konfigūracija.
Dangtis — abstrakcija per Paklotą nuomininkams izoliuoti.
Tai galioja tiek DC atveju (kurį analizuosime šiame straipsnyje), tiek IPT (kurio neanalizuosime, nes tai jau buvo ). Žinoma, su įmonių tinklais situacija yra kiek kitokia.
Nuotrauka su tinklu:
Paklotas
Apatinis sluoksnis yra fizinis tinklas: techninės įrangos jungikliai ir kabeliai. Įrenginiai po žeme žino, kaip pasiekti fizines mašinas.
Jis remiasi standartiniais protokolais ir technologijomis. Maža to, kad aparatūros įrenginiai iki šiol veikia su patentuota programine įranga, kuri neleidžia nei programuoti lusto, nei diegti savo protokolų, todėl reikalingas suderinamumas su kitais tiekėjais ir standartizavimas.
Tačiau kažkas, pavyzdžiui, „Google“, gali sau leisti kurti savo jungiklius ir atsisakyti visuotinai priimtų protokolų. Tačiau LAN_DC nėra „Google“.
Apatinis sluoksnis keičiasi palyginti retai, nes jo užduotis yra pagrindinis IP ryšys tarp fizinių mašinų. Underlay nieko nežino apie paslaugas, klientus ar nuomininkus, kurie veikia ant jo – tereikia pristatyti paketą iš vieno įrenginio į kitą.
Paklotas gali būti toks:
- IPv4+OSPF
- IPv6+ISIS+BGP+L3VPN
- L2+TRIL
- L2 + STP
Apatinis tinklas konfigūruojamas klasikiniu būdu: CLI/GUI/NETCONF.
Rankiniu būdu, scenarijai, patentuotos komunalinės paslaugos.
Kitas serijos straipsnis bus skirtas paklotui išsamiau.
Dangtis
Overlay yra virtualus tunelių tinklas, ištemptas ant Underlay, leidžiantis vieno kliento VM bendrauti tarpusavyje, tuo pačiu užtikrinant izoliaciją nuo kitų klientų.
Kliento duomenys yra įtraukti į kai kurias tunelių antraštes, kad būtų galima perduoti viešuoju tinklu.
Taigi vieno kliento (vienos paslaugos) VM gali bendrauti tarpusavyje per Overlay, net nežinodami, kokiu keliu iš tikrųjų eina paketas.
Pavyzdžiui, perdanga gali būti tokia, kaip minėjau aukščiau:
- GRE tunelis
- VXLAN
- EVPN
- L3VPN
- GENĖVĖ
Perdangos tinklas paprastai konfigūruojamas ir prižiūrimas per centrinį valdiklį. Iš jo konfigūracija, valdymo plokštuma ir duomenų plokštuma pristatomi į įrenginius, kurie nukreipia ir apjungia klientų srautą. Truputį Pažvelkime į tai su pavyzdžiais.
Taip, tai yra SDN gryniausia forma.
Yra du iš esmės skirtingi perdangos tinklo organizavimo būdai:
- Perdanga su ToR
- Perdanga iš prieglobos
Perdanga su ToR
Perdanga gali prasidėti nuo prieigos jungiklio (ToR), stovinčio stove, kaip atsitinka, pavyzdžiui, VXLAN audinio atveju.
Tai laiko patikrintas mechanizmas IPT tinkluose ir visi tinklo įrangos pardavėjai jį palaiko.
Tačiau šiuo atveju ToR jungiklis turi turėti galimybę atitinkamai atskirti įvairias paslaugas, o tinklo administratorius tam tikru mastu turi bendradarbiauti su virtualios mašinos administratoriais ir keisti (nors ir automatiškai) įrenginių konfigūraciją. .
Čia aš nukreipsiu skaitytoją į straipsnį apie mūsų senas draugas .
Šiame Nuolatinės srovės tinklo su EVPN VXLAN audiniu kūrimo būdai yra išsamiai aprašyti.
O norint labiau pasinerti į realybę, galite perskaityti Tsiskos knygą .
Atkreipiu dėmesį, kad VXLAN yra tik inkapsuliavimo metodas ir tunelių nutraukimas gali įvykti ne ToR, o pagrindiniame kompiuteryje, kaip, pavyzdžiui, atsitinka OpenStack atveju.
Tačiau VXLAN audinys, kai perdanga prasideda nuo ToR, yra vienas iš nustatytų perdangos tinklo projektų.
Perdanga iš prieglobos
Kitas būdas yra pradėti ir baigti tunelius galiniuose kompiuteriuose.
Šiuo atveju tinklas (Underlay) išlieka kuo paprastesnis ir statiškesnis.
O šeimininkas pats atlieka visą reikalingą inkapsuliavimą.
Tam, žinoma, reikės paleisti specialią programą pagrindiniuose kompiuteriuose, bet tai verta.
Pirma, paleisti klientą „Linux“ įrenginyje yra lengviau arba, tarkime, net įmanoma, o perjungus greičiausiai turėsite kreiptis į patentuotus SDN sprendimus, o tai užmuša kelių tiekėjų idėją.
Antra, ToR jungiklis šiuo atveju gali būti paliktas kuo paprastesnis tiek valdymo plokštumos, tiek duomenų plokštumos požiūriu. Išties, tada jam nereikia bendrauti su SDN valdikliu, taip pat nereikia saugoti visų prijungtų klientų tinklų/ARP – pakanka žinoti fizinės mašinos IP adresą, o tai labai supaprastina perjungimą/ maršruto lentelės.
ADSM serijoje renkuosi perdangos metodą iš šeimininko – tada tik apie tai kalbame ir į VXLAN gamyklą nebegrįšime.
Lengviausia žiūrėti į pavyzdžius. O kaip bandomąjį dalyką paimsime OpenSource SDN platformą OpenContrail, dabar žinomą kaip .
Straipsnio pabaigoje pateiksiu keletą minčių apie analogiją su OpenFlow ir OpenvSwitch.
Kaip pavyzdį naudojant volframo audinį
Kiekviena fizinė mašina turi vRouter - virtualus maršrutizatorius, kuris žino apie prie jo prijungtus tinklus ir kuriems klientams jie priklauso - iš esmės PE maršrutizatorius. Kiekvienam klientui ji palaiko izoliuotą maršruto parinkimo lentelę (skaitykite VRF). Ir „vRouter“ iš tikrųjų atlieka perdangos tuneliavimą.
Šiek tiek daugiau apie „vRouter“ rasite straipsnio pabaigoje.
Kiekviena VM, esanti hipervizoriuje, yra prijungta prie šio įrenginio vRouter per .
TAP - Terminalo prieigos taškas – virtuali sąsaja Linux branduolyje, leidžianti sąveikauti su tinklu.
Jei už vRouter yra keli tinklai, tai kiekvienam iš jų sukuriama virtuali sąsaja, kuriai priskiriamas IP adresas – tai bus numatytasis šliuzo adresas.
Visi vieno kliento tinklai dedami į vieną VRF (viena lentelė), skirtingi - į skirtingas.
Aš čia padarysiu atsakomybės atsisakymą, kad ne viskas taip paprasta, o smalsų skaitytoją nusiųsiu į straipsnio pabaigą.
Kad vRouteriai galėtų bendrauti tarpusavyje ir atitinkamai už jų esančios VM, jie keičiasi maršruto informacija per SDN valdiklis.
Norint patekti į išorinį pasaulį, yra išėjimo iš matricos taškas - virtualus tinklo šliuzas VNGW – virtualaus tinklo vartai (mano terminas).
Dabar pažiūrėkime į komunikacijų pavyzdžius – ir bus aiškumo.
Ryšys vienoje fizinėje mašinoje
VM0 nori siųsti paketą į VM2. Tarkime, kad tai yra vieno kliento VM.
Duomenų plokštuma
- VM-0 turi numatytąjį maršrutą į eth0 sąsają. Paketas siunčiamas ten.
Ši sąsaja eth0 iš tikrųjų yra virtualiai prijungta prie virtualaus maršrutizatoriaus vRouter per TAP sąsają tap0. - vRouter analizuoja, į kurią sąsają atėjo paketas, tai yra, kuriam klientui (VRF) jis priklauso, ir patikrina gavėjo adresą šio kliento maršruto parinkimo lentelėje.
- Aptikęs, kad gavėjas tame pačiame kompiuteryje yra kitame prievade, vRouter tiesiog siunčia paketą į jį be jokių papildomų antraščių – šiuo atveju vRouter jau turi ARP įrašą.
Tokiu atveju paketas nepatenka į fizinį tinklą – jis nukreipiamas vRouter viduje.
Valdymo plokštuma
Kai virtualioji mašina paleidžiama, hipervizorius praneša:
- Jos pačios IP adresas.
- Numatytasis maršrutas yra per vRouter IP adresą šiame tinkle.
Hipervizorius praneša „vRouter“ per specialią API:
- Ko reikia norint sukurti virtualią sąsają.
- Kokį virtualų tinklą jai (VM) reikia sukurti?
- Su kuriuo VRF (VN) jį susieti.
- Statinis šios VM ARP įrašas – kuri sąsaja yra už jos IP adreso ir su kuriuo MAC adresu ji susieta.
Vėlgi, tikroji sąveikos procedūra yra supaprastinta siekiant suprasti koncepciją.
Taigi „vRouter“ mato visas vieno kliento VM tam tikrame kompiuteryje kaip tiesiogiai prijungtus tinklus ir gali pats nukreipti tarp jų.
Tačiau VM0 ir VM1 priklauso skirtingiems klientams ir atitinkamai yra skirtingose vRouter lentelėse.
Ar jie gali bendrauti vienas su kitu, tiesiogiai priklauso nuo „vRouter“ nustatymų ir tinklo konstrukcijos.
Pavyzdžiui, jei abiejų klientų VM naudoja viešuosius adresus arba NAT yra pačiame vRouter, tada galima atlikti tiesioginį maršrutą į vRouter.
Priešingoje situacijoje galima kirsti adresų erdves – norint gauti viešąjį adresą reikia pereiti per NAT serverį – tai panašu į prieigą prie išorinių tinklų, kurie aptariami toliau.
Ryšys tarp skirtinguose fiziniuose įrenginiuose esančių VM
Duomenų plokštuma
- Pradžia lygiai tokia pati: VM-0 siunčia paketą su paskirties VM-7 (172.17.3.2) pagal numatytuosius nustatymus.
- vRouter jį gauna ir šį kartą mato, kad paskirties vieta yra kitame kompiuteryje ir pasiekiama per Tunnel0.
- Pirma, jis pakabina MPLS etiketę, identifikuojančią nuotolinę sąsają, kad kitoje pusėje vRouter galėtų nustatyti, kur įdėti šį paketą be papildomų peržiūrų.
- Tunnel0 šaltinis yra 10.0.0.2, paskirties vieta: 10.0.1.2.
vRouter prideda GRE (arba UDP) antraštes ir naują IP prie pradinio paketo. - „vRouter“ maršruto parinkimo lentelė turi numatytąjį maršrutą per ToR1 adresą 10.0.0.1. Ten jis ir siunčia.
- ToR1, kaip Underlay tinklo narys, žino (pavyzdžiui, per OSPF), kaip patekti į 10.0.1.2 ir siunčia paketą maršrutu. Atminkite, kad čia įjungtas ECMP. Iliustracijoje yra du „nexthops“, o skirtingos gijos bus surūšiuotos pagal maišą. Tikros gamyklos atveju labiau tikėtina, kad bus 4 „nexthops“.
Tuo pačiu metu jam nereikia žinoti, kas yra po išorine IP antrašte. Tai yra, iš tikrųjų, naudojant IP, gali būti IPv6 sumuštinis per MPLS per Ethernet per MPLS per GRE arba per graikų kalbą.
- Atitinkamai, gavimo pusėje „vRouter“ pašalina GRE ir, naudodamas MPLS žymą, supranta, į kurią sąsają šis paketas turi būti siunčiamas, pašalina jį ir išsiunčia gavėjui pradine forma.
Valdymo plokštuma
Užvedus automobilį atsitinka tas pats, kas aprašyta aukščiau.
Ir dar šie dalykai:
- Kiekvienam klientui „vRouter“ priskiria MPLS žymą. Tai yra L3VPN paslaugos etiketė, pagal kurią klientai bus atskirti tame pačiame fiziniame įrenginyje.
Tiesą sakant, MPLS žymą visada besąlygiškai paskiria vRouter – juk iš anksto nežinoma, kad mašina sąveikaus tik su kitomis mašinomis, esančiomis už to paties vRouter, ir tai greičiausiai net netiesa.
- vRouter užmezga ryšį su SDN valdikliu naudodamas BGP protokolą (arba panašų į jį – TF atveju tai yra XMPP 0_o).
- Šios sesijos metu „vRouter“ praneša apie maršrutus į prijungtus tinklus SDN valdikliui:
- Tinklo adresas
- Inkapsuliavimo metodas (MPLSoGRE, MPLSoUDP, VXLAN)
- MPLS kliento žyma
- Jūsų IP adresas kaip nexthop
- SDN valdiklis tokius maršrutus gauna iš visų prijungtų vRouter ir atspindi juos kitiems. Tai yra, jis veikia kaip maršruto atšvaitas.
Tas pats vyksta priešinga kryptimi.
Perdanga gali keistis bent kas minutę. Maždaug taip nutinka viešuosiuose debesyse, kur klientai reguliariai paleidžia ir išjungia savo virtualias mašinas.
Centrinis valdiklis rūpinasi visais sudėtingais konfigūracijos palaikymu ir „vRouter“ perjungimo / maršruto parinkimo lentelių stebėjimu.
Grubiai tariant, valdiklis bendrauja su visais vRouteriais per BGP (ar panašų protokolą) ir tiesiog perduoda maršruto informaciją. Pavyzdžiui, BGP jau turi Address-Family, kad perteiktų inkapsuliavimo metodą arba .
Tuo pačiu niekaip nesikeičia „Underlay“ tinklo konfigūracija, kurią, beje, daug sunkiau automatizuoti, o sulaužyti nepatogiu judesiu lengviau.
Išėjimas į išorinį pasaulį
Kažkur simuliacija turi baigtis, ir jūs turite išeiti iš virtualaus pasaulio į tikrąjį. Ir jums reikia taksofono vartų.
Praktikuojami du būdai:
- Įdiegtas aparatinės įrangos maršrutizatorius.
- Paleidžiamas tam tikras įrenginys, įgyvendinantis maršrutizatoriaus funkcijas (taip, SDN, susidūrėme ir su VNF). Pavadinkime tai virtualiais vartais.
Antrojo požiūrio privalumas yra pigus horizontalus mastelio keitimas – nėra pakankamai energijos – paleidome dar vieną virtualią mašiną su šliuzu. Bet kurioje fizinėje mašinoje nereikia ieškoti laisvų stelažų, blokų, galios, pirkti pačią techninę įrangą, ją transportuoti, įdiegti, perjungti, konfigūruoti, o tada keisti sugedusius komponentus.
Virtualių šliuzų trūkumai yra tai, kad fizinio maršruto parinktuvo blokas vis dar yra daug galingesnis nei kelių branduolių virtualioji mašina, o jo programinė įranga, pritaikyta prie savo aparatinės įrangos, veikia daug stabiliau (ne). Taip pat sunku paneigti faktą, kad techninės ir programinės įrangos kompleksas tiesiog veikia, tereikia konfigūruoti, o virtualių šliuzų paleidimas ir priežiūra yra stiprių inžinierių užduotis.
Viena koja šliuzas žiūri į Overlay virtualų tinklą, kaip įprasta virtualioji mašina, ir gali sąveikauti su visomis kitomis VM. Tuo pačiu metu jis gali nutraukti visų klientų tinklus ir atitinkamai atlikti maršrutą tarp jų.
Kita koja vartai žiūri į pagrindinį tinklą ir žino, kaip prisijungti prie interneto.
Duomenų plokštuma
Tai yra, procesas atrodo taip:
- VM-0, numatęs tą patį vRouter, siunčia paketą su paskirties vieta išoriniame pasaulyje (185.147.83.177) į eth0 sąsają.
- vRouter gauna šį paketą ir ieško paskirties adreso maršruto parinkimo lentelėje – suranda numatytąjį maršrutą per VNGW1 šliuzą per 1 tunelį.
Jis taip pat mato, kad tai yra GRE tunelis su SIP 10.0.0.2 ir DIP 10.0.255.2, taip pat pirmiausia turi pritvirtinti šio kliento MPLS etiketę, kurios VNGW1 tikisi. - vRouter supakuoja pradinį paketą su MPLS, GRE ir naujomis IP antraštėmis ir pagal numatytuosius nustatymus siunčia jį į ToR1 10.0.0.1.
- Pagrindinis tinklas pristato paketą į šliuzą VNGW1.
- VNGW1 šliuzas pašalina GRE ir MPLS tuneliavimo antraštes, mato paskirties adresą, peržiūri maršruto parinkimo lentelę ir supranta, kad jis nukreiptas į internetą, ty per visą vaizdą arba numatytąjį. Jei reikia, atlieka NAT vertimą.
- Gali būti įprastas IP tinklas nuo VNGW iki sienos, o tai mažai tikėtina.
Gali būti klasikinis MPLS tinklas (IGP+LDP/RSVP TE), gali būti užpakalinis audinys su BGP LU arba GRE tunelis nuo VNGW iki sienos per IP tinklą.
Kad ir kaip būtų, VNGW1 atlieka reikiamas inkapsuliacijas ir siunčia pradinį paketą link sienos.
Eismas priešinga kryptimi vyksta tais pačiais žingsniais priešinga tvarka.
- Sienelė numeta paketą į VNGW1
- Jis nurengia jį, žiūri į gavėjo adresą ir mato, kad jis pasiekiamas per tunelį1 (MPLSoGRE arba MPLSoUDP).
- Atitinkamai, jis prideda MPLS etiketę, GRE/UDP antraštę ir naują IP adresą bei siunčia jį į savo ToR3 10.0.255.1.
Tunelio paskirties adresas yra vRouter, už kurio yra tikslinė VM, IP adresas – 10.0.0.2. - Pagrindinis tinklas pristato paketą norimam vRouter.
- Tikslinis vRouter nuskaito GRE/UDP, identifikuoja sąsają naudodamas MPLS etiketę ir siunčia tuščią IP paketą į savo TAP sąsają, susietą su VM eth0.
Valdymo plokštuma
VNGW1 sukuria BGP kaimynystę su SDN valdikliu, iš kurio gauna visą maršruto informaciją apie klientus: už kurio kliento yra IP adresas (vRouter) ir pagal kurią MPLS etiketę jis identifikuojamas.
Panašiai jis pats informuoja SDN valdiklį apie numatytąjį maršrutą su šio kliento etikete, nurodydamas save kaip nexthop. Ir tada šis numatytasis nustatymas pasiekia vRouters.
VNGW paprastai vyksta maršrutų sujungimas arba NAT vertimas.
O kita kryptimi jis siunčia būtent šį apibendrintą maršrutą seansui su kraštinėmis arba maršruto atšvaitais. Ir iš jų jis gauna numatytąjį maršrutą arba visą vaizdą, ar dar ką nors.
Inkapsuliavimo ir srauto mainų prasme VNGW niekuo nesiskiria nuo „vRouter“.
Jei šiek tiek išplečiate taikymo sritį, prie VNGW ir vRouter galite pridėti kitus tinklo įrenginius, tokius kaip ugniasienės, eismo valymo ar sodrinimo fermos, IPS ir pan.
Naudodamiesi nuosekliu VRF kūrimu ir teisingu maršrutų paskelbimu, galite priversti eismą suktis taip, kaip norite, o tai vadinama paslaugų grandine.
Tai reiškia, kad SDN valdiklis čia taip pat veikia kaip maršruto atspindys tarp VNGW, vRouters ir kitų tinklo įrenginių.
Tačiau iš tikrųjų valdiklis taip pat išleidžia informaciją apie ACL ir PBR (politikomis pagrįstą maršrutą), todėl atskiri eismo srautai vyksta kitaip, nei nurodo maršrutas.
Dažnai užduodami klausimai
Kodėl nuolat kartojate GRE/UDP pastabas?
Na, apskritai galima sakyti, kad tai būdinga volframo audiniams – į tai visai nereikia atsižvelgti.
Bet jei paimsime tai, pati TF, dar būdama „OpenContrail“, palaikė abi inkapsuliacijas: MPLS GRE ir MPLS UDP.
UDP yra geras, nes Source Port labai paprasta jos antraštėje užkoduoti maišos funkciją iš originalaus IP+Proto+Port, kuri leis atlikti balansavimą.
GRE atveju, deja, yra tik išorinės IP ir GRE antraštės, kurios yra vienodos visam inkapsuliuotam srautui ir nėra kalbos apie balansavimą – mažai kas gali taip giliai pažvelgti į paketo vidų.
Iki kurio laiko maršrutizatoriai, jei mokėjo naudotis dinaminiais tuneliais, tai darė tik MPLSoGRE, o tik visai neseniai išmoko naudotis MPLSoUDP. Todėl visada turime atkreipti dėmesį į dviejų skirtingų inkapsuliacijų galimybę.
Tiesą sakant, verta paminėti, kad TF visiškai palaiko L2 ryšį naudojant VXLAN.
Žadėjote nubrėžti paraleles su „OpenFlow“.
Jie tikrai to prašo. „vSwitch“ tame pačiame „OpenStack“ daro labai panašius dalykus, naudodamas VXLAN, kuris, beje, taip pat turi UDP antraštę.
Duomenų plokštumoje jie veikia maždaug taip pat, valdymo plokštuma labai skiriasi. „Tungsten Fabric“ naudoja XMPP, kad pateiktų maršruto informaciją į „vRouter“, o „OpenStack“ paleidžia „Openflow“.
Ar galite man papasakoti šiek tiek daugiau apie „vRouter“?
Jis padalintas į dvi dalis: vRouter Agent ir vRouter Forwarder.
Pirmasis veikia pagrindinio kompiuterio OS vartotojo erdvėje ir bendrauja su SDN valdikliu, keisdamasis informacija apie maršrutus, VRF ir ACL.
Antrasis įgyvendina Data Plane – dažniausiai Kernel Space, bet gali veikti ir su SmartNIC – tinklo plokštėmis su centriniu procesoriumi ir atskiru programuojamu perjungimo lustu, kuris leidžia pašalinti apkrovą iš pagrindinio kompiuterio procesoriaus, o tinklas tampa greitesnis ir daugiau. nuspėjamas.
Kitas galimas scenarijus yra tas, kad „vRouter“ yra DPDK programa „User Space“.
„vRouter Agent“ siunčia nustatymus „vRouter Forwarder“.
Kas yra virtualus tinklas?
Straipsnio apie VRF pradžioje minėjau, kad kiekvienas nuomininkas yra susietas su savo VRF. Ir jei to pakako paviršutiniškam perdangos tinklo veikimo supratimui, tada kitoje iteracijoje būtina atlikti paaiškinimus.
Paprastai virtualizacijos mechanizmuose virtualaus tinklo subjektas (galite laikyti tai tinkamu daiktavardžiu) įvedamas atskirai nuo klientų / nuomininkų / virtualių mašinų - visiškai nepriklausomas dalykas. O šį Virtualųjį tinklą per sąsajas jau galima prijungti prie vieno nuomininko, prie kito, prie dviejų ar bet kur. Taigi, pavyzdžiui, „Service Chaining“ yra įdiegtas, kai srautą reikia perduoti per tam tikrus mazgus reikiama seka, tiesiog sukuriant ir sujungiant virtualius tinklus teisinga seka.
Todėl tarp virtualaus tinklo ir nuomininko nėra tiesioginio susirašinėjimo.
išvada
Tai labai paviršutiniškas virtualaus tinklo su perdanga iš pagrindinio kompiuterio ir SDN valdiklio veikimo aprašymas. Bet nesvarbu, kokią virtualizacijos platformą pasirinksite šiandien, ji veiks panašiai, ar tai būtų VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric ar Juniper Contrail. Jie skirsis inkapsuliavimo tipais ir antraštėmis, protokolais, skirtais informacijos pateikimui į galinius tinklo įrenginius, tačiau programine įranga konfigūruojamo perdangos tinklo, veikiančio palyginti paprasto ir statinio apatinio tinklo viršuje, principas išliks toks pat.
Galime pasakyti, kad šiandien SDN, pagrįstas perdangos tinklu, laimėjo privataus debesies kūrimo sritį. Tačiau tai nereiškia, kad Openflow neturi vietos šiuolaikiniame pasaulyje – jis naudojamas OpenStacke ir tame pačiame VMWare NSX, kiek žinau, Google jį naudoja požeminiam tinklui įrengti.
Žemiau pateikiau nuorodas į išsamesnę medžiagą, jei norite išsamiau išnagrinėti problemą.
O kaip su mūsų apatine danga?
Bet apskritai nieko. Jis nepasikeitė iki galo. Viskas, ką jam reikia padaryti perdangos iš pagrindinio kompiuterio atveju, yra atnaujinti maršrutus ir ARP, kai atsiranda ir išnyksta vRouter / VNGW ir perneša paketus tarp jų.
Suformuluokime Apatinio sluoksnio tinklo reikalavimų sąrašą.
- Mokėti naudotis kažkokiu maršruto parinkimo protokolu, mūsų situacijoje – BGP.
- Turėkite platų pralaidumą, pageidautina be prenumeratos, kad paketai nebūtų prarasti dėl perkrovų.
- Atraminis ECMP yra neatskiriama audinio dalis.
- Gebėti teikti QoS, įskaitant sudėtingus dalykus, tokius kaip ECN.
- NETCONF palaikymas yra ateities pagrindas.
Pačio „Underlay“ tinklo darbui čia skyriau labai mažai laiko. Taip yra todėl, kad vėliau serijoje aš sutelksiu dėmesį į tai, o perdangą paliesime tik prabėgomis.
Akivaizdu, kad aš labai riboju mus visus, kaip pavyzdį naudodamas nuolatinės srovės tinklą, pastatytą Cloz gamykloje su grynu IP maršruto parinkimu ir pagrindinio kompiuterio perdanga.
Tačiau esu įsitikinęs, kad bet koks tinklas, kurio dizainas gali būti apibūdintas formaliai ir automatizuotas. Tiesiog mano tikslas yra suprasti automatizavimo būdus, o ne suklaidinti visus sprendžiant problemą bendra forma.
Kaip ADSM dalis, Romanas Gorge'as ir aš planuojame išleisti atskirą numerį apie skaičiavimo galios virtualizavimą ir jos sąveiką su tinklo virtualizavimu. Palaikykite ryšį.
Naudingos nuorodos
- .
- . 6 valandos apie Yandex.Cloud, kuris taip pat apima virtualų tinklą TF.
- .
- . Jame kalbama apie visą nuolatinės srovės tinklą, įskaitant apatinį, perdangą, daugialypės terpės ir valdymo metodus.
Ačiū
- – buvęs „linkmeup“ podcast'o vedėjas, o dabar – debesų platformų srities ekspertas. Dėl komentarų ir redagavimo. Na, o artimiausiu metu laukiame jo išsamesnio straipsnio apie virtualizaciją.
- – mano kolega ir ekspertė virtualaus tinklo kūrimo srityje. Dėl komentarų ir redagavimo.
- - mano kolega ir volframo audinio ekspertas. Dėl komentarų ir redagavimo.
- — iliustratorius linkmeup. Dėl KDPV.
- Aleksandras Limonovas. „Automatiniam“ memui.
Šaltinis: www.habr.com