В prejšnja številka Opisal sem okvir za avtomatizacijo omrežja. Po mnenju nekaterih je že ta prvi pristop k problemu že rešil nekatera vprašanja. In to me zelo veseli, saj naš cilj v ciklu ni prekriti Ansible s skripti Python, ampak zgraditi sistem.

Isti okvir določa vrstni red, po katerem bomo obravnavali vprašanje.
In virtualizacija omrežja, ki ji je posvečena ta številka, ne sodi posebej v temo ADSM, kjer analiziramo avtomatizacijo.

A poglejmo z drugega zornega kota.

Številne storitve že dolgo uporabljajo isto omrežje. V primeru telekomunikacijskega operaterja je to na primer 2G, 3G, LTE, širokopasovni dostop in B2B. V primeru DC: povezljivost za različne odjemalce, internet, shranjevanje blokov, shranjevanje objektov.

In vse storitve zahtevajo izolacijo druga od druge. Tako so se pojavile prekrivne mreže.

In vse storitve ne želijo čakati, da jih oseba ročno konfigurira. Tako so se pojavili orkestratorji in SDN.

Prvi pristop k sistematični avtomatizaciji omrežja oziroma njegovega dela je že dolgo uveljavljen in implementiran marsikje: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

To je tisto, s čimer se bomo ukvarjali danes.

Vsebina

• Vzroki
• Terminologija
• Podloga - fizično omrežje
• Overlay - virtualno omrežje
  • Prekrivanje s ToR
  • Prekrivanje iz gostitelja
  • Uporaba volframove tkanine kot primera
    • Komunikacija znotraj enega fizičnega stroja
    • Komunikacija med VM-ji, ki se nahajajo na različnih fizičnih strojih
    • Izhod v zunanji svet

• FAQ
• Zaključek
• Uporabne povezave

Vzroki

In ker že govorimo o tem, je vredno omeniti predpogoje za virtualizacijo omrežja. Pravzaprav se ta proces ni začel včeraj.

Verjetno ste že večkrat slišali, da je bilo omrežje vedno najbolj inerten del katerega koli sistema. In to drži v vseh pogledih. Omrežje je osnova, na kateri vse sloni, spremembe na njem pa so precej težke – storitve ne prenesejo, ko omrežje ne deluje. Pogosto lahko razgradnja enega samega vozlišča odstrani velik del aplikacij in vpliva na številne stranke. To je deloma razlog, zakaj se omrežna ekipa morda upira kakršni koli spremembi - ker zdaj nekako deluje (morda niti ne vemo, kako), vendar morate tukaj konfigurirati nekaj novega in ni znano, kako bo to vplivalo na omrežje.

Da ne bi čakali, da omrežniki vstavijo VLAN-e in ne bi registrirali nobenih storitev na vsakem omrežnem vozlišču, so ljudje prišli na idejo o uporabi prekrivnih omrežij - prekrivnih omrežij - ki jih je zelo veliko: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE itd.

Njihova privlačnost je v dveh preprostih stvareh:

• Konfigurirana so samo končna vozlišča – tranzitnih vozlišč se ni treba dotikati. To bistveno pospeši proces, včasih pa vam omogoča, da oddelek za omrežno infrastrukturo popolnoma izključite iz procesa uvajanja novih storitev.
• Tovor je skrit globoko v glavah - tranzitnim vozliščem ni treba vedeti ničesar o njem, o naslavljanju na gostiteljih ali o poteh prekrivnega omrežja. To pomeni, da morate shraniti manj informacij v tabele, kar pomeni uporabo enostavnejše/cenejše naprave.

V tej ne povsem popolni številki ne nameravam analizirati vseh možnih tehnologij, ampak raje opišem okvir za delovanje prekrivnih omrežij v DC.

Celotna serija bo opisala podatkovni center, sestavljen iz vrst enakih regalov, v katerih je nameščena ista strežniška oprema.

Ta oprema poganja virtualne stroje/vsebnike/brez strežnika, ki izvajajo storitve.

Terminologija

V zanki strežnik Poimenoval bom program, ki izvaja strežniško stran komunikacije med odjemalcem in strežnikom.

Fizični stroji v omarah se imenujejo strežniki ne bomo.

Fizični stroj — računalnik x86, nameščen v omaro. Najpogosteje uporabljen izraz gostitelj. Tako ga bomo poimenovali"stroj"Or gostitelj.

Hipervizor — aplikacija, ki se izvaja na fizičnem stroju, ki posnema fizične vire, na katerih se izvajajo virtualni stroji. Včasih se v literaturi in na internetu beseda "hipervizor" uporablja kot sinonim za "gostitelja".

Navidezni stroj - operacijski sistem, ki teče na fizičnem stroju na vrhu hipervizorja. Za nas v tem ciklu je povsem vseeno, ali gre dejansko za navidezni stroj ali le za vsebnik. Pokličimo to "VM«

Najemnik je širok pojem, ki ga bom v tem članku opredelil kot ločeno storitev ali ločeno stranko.

Več najemno ali multitency - uporaba iste aplikacije s strani različnih strank/storitev. Hkrati je izolacija strank med seboj dosežena zahvaljujoč arhitekturi aplikacije in ne prek ločeno delujočih primerkov.

ToR — vrh stikala Rack - stikalo, nameščeno v omaro, na katerega so povezani vsi fizični stroji.

Poleg topologije ToR različni ponudniki izvajajo End of Row (EoR) ali Middle of Row (čeprav je slednje zaničevalna redkost in nisem videl okrajšave MoR).

Podložna mreža ali osnovno omrežje ali podlaga je fizična omrežna infrastruktura: stikala, usmerjevalniki, kabli.

Prekrivna mreža ali prekrivno omrežje ali prekrivanje - navidezno omrežje tunelov, ki teče na vrhu fizičnega.

L3 tkanina ali IP tkanina - neverjeten izum človeštva, ki vam omogoča, da se izognete ponavljanju STP in učenju TRILL za intervjuje. Koncept, v katerem je celotno omrežje do nivoja dostopa izključno L3, brez VLAN-ov in temu primerno ogromnih razširjenih oddajnih domen. V naslednjem delu bomo pogledali, od kod prihaja beseda "tovarna".

SDN - Programsko definirano omrežje. Komaj potrebuje uvod. Pristop k upravljanju omrežja, pri katerem spremembe v omrežju ne naredi oseba, ampak program. Običajno pomeni premik nadzorne ravnine preko končnih omrežnih naprav na krmilnik.

NFV — Virtualizacija omrežnih funkcij — virtualizacija omrežnih naprav, ki nakazuje, da se lahko nekatere omrežne funkcije izvajajo v obliki navideznih strojev ali vsebnikov, da se pospeši izvajanje novih storitev, organizira veriženje storitev in enostavnejša horizontalna razširljivost.

VNF - Funkcija navideznega omrežja. Določena virtualna naprava: usmerjevalnik, stikalo, požarni zid, NAT, IPS/IDS itd.

Opis zdaj namenoma poenostavljam na konkretno izvedbo, da ne bi bralca preveč zmedel. Za bolj premišljeno branje ga napotim v razdelek reference. Poleg tega Roma Gorge, ki ta članek kritizira zaradi netočnosti, obljublja, da bo napisal ločeno številko o tehnologijah za virtualizacijo strežnikov in omrežij, bolj poglobljeno in pozorno na podrobnosti.

Večino današnjih omrežij je mogoče jasno razdeliti na dva dela:

Podloga — fizično omrežje s stabilno konfiguracijo.
Prekrivanje — odvzem nad podlago za izolacijo najemnikov.

To velja tako za primer DC (ki ga bomo analizirali v tem članku) kot za ISP (ki ga ne bomo analizirali, ker je že bil SDSM). Pri podjetniških omrežjih je seveda situacija nekoliko drugačna.

Slika s poudarkom na omrežju:

Podloga

Podlaga je fizično omrežje: strojna stikala in kabli. Naprave v podzemlju vedo, kako doseči fizične stroje.

Zanaša se na standardne protokole in tehnologije. Nenazadnje tudi zato, ker strojne naprave še danes delujejo na lastniški programski opremi, ki ne omogoča niti programiranja čipa niti implementacije lastnih protokolov, zato je potrebna kompatibilnost z drugimi proizvajalci in standardizacija.

Toda nekdo, kot je Google, si lahko privošči razvoj lastnih stikal in opustitev splošno sprejetih protokolov. Vendar LAN_DC ni Google.

Podloga se razmeroma redko spreminja, ker je njena naloga osnovna IP povezljivost med fizičnimi stroji. Underlay ne ve ničesar o storitvah, odjemalcih ali najemnikih, ki tečejo na njem - le dostaviti mora paket z enega stroja na drugega.
Podloga je lahko taka:

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

Omrežje Underlay je konfigurirano na klasičen način: CLI/GUI/NETCONF.

Ročno, skripte, lastniški pripomočki.

Naslednji članek v seriji bo podrobneje posvečen podlogi.

Prekrivanje

Overlay je navidezno omrežje tunelov, raztegnjenih na vrhu Underlaya, omogoča VM-jem enega odjemalca, da komunicirajo med seboj, hkrati pa zagotavlja izolacijo od drugih odjemalcev.

Podatki odjemalca so enkapsulirani v nekaterih glavah tuneliranja za prenos po javnem omrežju.

Tako lahko navidezni računalniki enega odjemalca (ene storitve) komunicirajo drug z drugim prek prekrivanja, ne da bi sploh vedeli, po kateri poti paket dejansko gre.

Prekrivanje je lahko na primer tako, kot sem omenil zgoraj:

• tunel GRE
• VXLAN
• EVPN
• L3VPN
• ŽENEV

Prekrivno omrežje je običajno konfigurirano in vzdrževano prek centralnega krmilnika. Iz njega se konfiguracija, nadzorna ravnina in podatkovna ravnina dostavijo napravam, ki usmerjajo in enkapsulirajo promet odjemalcev. Malo Spodaj Poglejmo si to s primeri.

Da, to je SDN v najčistejši obliki.

Obstajata dva bistveno različna pristopa k organizaciji prekrivnega omrežja:

1. Prekrivanje s ToR
2. Prekrivanje iz gostitelja

Prekrivanje s ToR

Prekrivanje se lahko začne pri stikalu za dostop (ToR), ki stoji v omari, kot se na primer zgodi v primeru tkanine VXLAN.

To je časovno preizkušen mehanizem v omrežjih ISP in vsi prodajalci omrežne opreme ga podpirajo.

Vendar mora biti v tem primeru stikalo ToR sposobno ločiti različne storitve, skrbnik omrežja pa mora do določene mere sodelovati s skrbniki virtualnega stroja in spreminjati (čeprav samodejno) konfiguracijo naprav. .

Tukaj bom bralca napotil na članek o VxLAN na Habréju naš stari prijatelj @bormoglotx.
V tem predstavitve z ENOG podrobno so opisani pristopi k izgradnji omrežja DC s tkanino EVPN VXLAN.

In za popolnejšo potopitev v resničnost, lahko preberete Tsiskino knjigo Moderna, odprta in razširljiva struktura: VXLAN EVPN.

Ugotavljam, da je VXLAN le metoda enkapsulacije in da se prekinitev tunelov lahko zgodi ne na ToR, ampak na gostitelju, kot se na primer zgodi v primeru OpenStack.

Vendar je tkanina VXLAN, kjer se prekrivanje začne pri ToR, ena od uveljavljenih zasnov prekrivnega omrežja.

Prekrivanje iz gostitelja

Drug pristop je zagon in zaključek tunelov na končnih gostiteljih.
V tem primeru ostane mreža (podloga) čim bolj enostavna in statična.
In gostitelj sam opravi vso potrebno enkapsulacijo.

To bo seveda zahtevalo zagon posebne aplikacije na gostiteljih, vendar se splača.

Prvič, poganjanje odjemalca na računalniku z Linuxom je lažje ali, recimo, celo možno, medtem ko se boste na preklopu najverjetneje morali obrniti na lastniške rešitve SDN, kar ubija idejo o več ponudnikih.

Drugič, stikalo ToR v tem primeru lahko ostane čim bolj preprosto, tako z vidika nadzorne ravnine kot podatkovne ravnine. Dejansko mu potem ni treba komunicirati s krmilnikom SDN, prav tako pa mu ni treba shranjevati omrežij/ARP-jev vseh povezanih odjemalcev – dovolj je poznati naslov IP fizičnega stroja, kar močno poenostavi preklapljanje/ usmerjevalne tabele.

V seriji ADSM izberem pristop prekrivanja od gostitelja - potem govorimo samo o tem in se ne bomo vrnili v tovarno VXLAN.

Najlažje je pogledati primere. In kot testni subjekt bomo vzeli OpenSource SDN platformo OpenContrail, zdaj znano kot Tkanina iz volframa.

Na koncu članka bom podal nekaj misli o analogiji z OpenFlow in OpenvSwitch.

Uporaba volframove tkanine kot primera

Vsak fizični stroj ima vRouter - navidezni usmerjevalnik, ki ve, katera omrežja so z njim povezana in katerim odjemalcem pripadajo - v bistvu usmerjevalnik PE. Za vsako stranko vzdržuje izolirano usmerjevalno tabelo (beri VRF). In vRouter dejansko izvaja tuneliranje Overlay.

Nekaj ​​več o vRouterju je na koncu članka.

Vsak VM, ki se nahaja na hipervizorju, je povezan z vRouterjem tega računalnika prek vmesnik TAP.

TAP - Terminal Access Point - virtualni vmesnik v jedru linuxa, ki omogoča omrežno interakcijo.

Če je za vRouterjem več omrežij, se za vsako od njih ustvari virtualni vmesnik, ki mu je dodeljen naslov IP - to bo privzeti naslov prehoda.
Vsa omrežja enega odjemalca so postavljena v eno VRF (ena miza), različne - v različne.
Tukaj bom opozoril, da ni vse tako preprosto, in bom radovednega bralca poslal na konec članka.

Da lahko vRouterji komunicirajo med seboj in v skladu s tem z VM-ji, ki se nahajajo za njimi, si izmenjujejo podatke o usmerjanju prek Krmilnik SDN.

Za izhod v zunanji svet obstaja izhodna točka iz matrike - virtualni omrežni prehod VNGW - Virtual Network GateWay (moj izraz).

Zdaj pa poglejmo primere komunikacij - in jasno bo.

Komunikacija znotraj enega fizičnega stroja

VM0 želi poslati paket VM2. Zaenkrat predpostavimo, da je to en sam odjemalec VM.

Podatkovna ravnina

1. VM-0 ima privzeto pot do vmesnika eth0. Paket se pošlje tja.
   Ta vmesnik eth0 je pravzaprav virtualno povezan z virtualnim usmerjevalnikom vRouter prek vmesnika TAP tap0.
2. vRouter analizira, na kateri vmesnik je paket prišel, torej kateremu odjemalcu (VRF) pripada, in preveri naslov prejemnika z usmerjevalno tabelo tega odjemalca.
3. Ko zazna, da je prejemnik na istem računalniku na drugih vratih, mu vRouter preprosto pošlje paket brez dodatnih glav – v tem primeru ima vRouter že vnos ARP.

V tem primeru paket ne vstopi v fizično omrežje – usmerjen je znotraj vRouterja.

Nadzorna ravnina

Ko se virtualni stroj zažene, mu hipervizor sporoči:

• Njen naslov IP.
• Privzeta pot je prek naslova IP vRouterja v tem omrežju.

Hipervizor poroča vRouterju prek posebnega API-ja:

• Kaj potrebujete za ustvarjanje virtualnega vmesnika.
• Kakšno navidezno omrežje mora (VM) ustvariti?
• Na kateri VRF (VN) ga povezati.
• Statični vnos ARP za ta VM – kateri vmesnik je za njegovim naslovom IP in s katerim naslovom MAC je povezan.

Ponovno je dejanski postopek interakcije poenostavljen zaradi razumevanja koncepta.

Tako vRouter vidi vse VM enega odjemalca na danem računalniku kot neposredno povezana omrežja in lahko sam usmerja med njimi.

Toda VM0 in VM1 pripadata različnim odjemalcem in sta zato v različnih tabelah vRouter.

Ali lahko neposredno komunicirajo drug z drugim, je odvisno od nastavitev vRouterja in zasnove omrežja.
Na primer, če VM obeh odjemalcev uporabljata javne naslove ali se NAT pojavi na samem vRouterju, je mogoče izvesti neposredno usmerjanje na vRouter.

V nasprotni situaciji je mogoče prečkati naslovne prostore - za pridobitev javnega naslova morate iti skozi strežnik NAT - to je podobno dostopanju do zunanjih omrežij, ki so obravnavana spodaj.

Komunikacija med VM-ji, ki se nahajajo na različnih fizičnih strojih

Podatkovna ravnina

1. Začetek je popolnoma enak: VM-0 pošlje paket s privzetim ciljnim VM-7 (172.17.3.2).
2. vRouter ga prejme in tokrat vidi, da je cilj na drugem računalniku in je dostopen prek Tunnel0.
3. Najprej obesi oznako MPLS, ki identificira oddaljeni vmesnik, tako da lahko na hrbtni strani vRouter določi, kam naj postavi ta paket brez dodatnih iskanj.

   

4. Predor0 ima vir 10.0.0.2, cilj: 10.0.1.2.
   vRouter prvotnemu paketu doda glave GRE (ali UDP) in nov IP.
5. Usmerjevalna tabela vRouter ima privzeto pot prek naslova ToR1 10.0.0.1. Tja ga pošlje.

   
   

6. ToR1 kot član omrežja Underlay ve (na primer prek OSPF) kako priti do 10.0.1.2 in pošlje paket po poti. Upoštevajte, da je ECMP tukaj omogočen. Na sliki sta dva nexthopa in različne niti bodo razvrščene vanje po zgoščeni vrednosti. V primeru prave tovarne bodo bolj verjetno 4 nexthops.

   Hkrati mu ni treba vedeti, kaj je pod zunanjim naslovom IP. Dejansko lahko pod IP-jem obstaja sendvič IPv6 prek MPLS prek Etherneta prek MPLS prek GRE prek prek Grka.

7. Skladno s tem na sprejemni strani vRouter odstrani GRE in z uporabo oznake MPLS ugotovi, na kateri vmesnik je treba poslati ta paket, ga odstrani in v izvirni obliki pošlje prejemniku.

Nadzorna ravnina

Ko zaženete avto, se zgodi isto, kot je opisano zgoraj.

In plus naslednje:

• Vsakemu odjemalcu vRouter dodeli oznako MPLS. To je oznaka storitve L3VPN, po kateri bodo odjemalci ločeni znotraj istega fizičnega stroja.
  

  Pravzaprav vRouter vedno brezpogojno dodeli oznako MPLS - navsezadnje ni vnaprej znano, da bo stroj komuniciral le z drugimi stroji za istim vRouterjem in to najverjetneje niti ni res.

• vRouter vzpostavi povezavo s krmilnikom SDN s pomočjo protokola BGP (ali njemu podobnega - v primeru TF je to XMPP 0_o).
• Skozi to sejo vRouter sporoča krmilniku SDN poti do povezanih omrežij:
  • Omrežni naslov
  • Metoda enkapsulacije (MPLSoGRE, MPLSoUDP, VXLAN)
  • oznaka odjemalca MPLS
  • Vaš IP naslov kot nexthop

• Krmilnik SDN sprejema takšne poti od vseh povezanih vRouterjev in jih odraža drugim. To pomeni, da deluje kot reflektor poti.

Enako se zgodi v obratni smeri.

Prekrivanje se lahko spremeni vsaj vsako minuto. To se približno dogaja v javnih oblakih, kjer odjemalci redno zaganjajo in izklapljajo svoje virtualne stroje.

Centralni krmilnik skrbi za vso kompleksnost vzdrževanja konfiguracije in spremljanja preklopnih/usmerjevalnih tabel na vRouterju.

Grobo rečeno, krmilnik komunicira z vsemi vRouterji prek BGP (ali podobnega protokola) in preprosto prenaša informacije o usmerjanju. BGP, na primer, že ima Address-Family za posredovanje metode enkapsulacije MPLS-in-GRE ali MPLS-in-UDP.

Hkrati se konfiguracija omrežja Underlay ne spremeni na noben način, ki ga je, mimogrede, veliko težje avtomatizirati in ga je lažje zlomiti z nerodnim gibanjem.

Izhod v zunanji svet

Nekje se mora simulacija končati in iz virtualnega sveta morate zapustiti resničnega. In potrebujete prehod za telefonsko govorilnico.

Uporabljata se dva pristopa:

1. Nameščen je strojni usmerjevalnik.
2. Zažene se naprava, ki izvaja funkcije usmerjevalnika (ja, po SDN smo srečali tudi VNF). Recimo temu virtualni prehod.

Prednost drugega pristopa je poceni horizontalna razširljivost - ni dovolj moči - lansirali smo še en virtualni stroj s prehodom. Na katerem koli fizičnem stroju, ne da bi morali iskati prosta stojala, enote, izhodno moč, kupiti samo strojno opremo, jo prepeljati, namestiti, preklopiti, konfigurirati in nato tudi zamenjati okvarjene komponente v njej.

Slabosti navideznega prehoda so, da je enota fizičnega usmerjevalnika še vedno za rede velikosti močnejša od večjedrnega navideznega stroja, njegova programska oprema, prilagojena lastni strojni osnovi, pa deluje veliko bolj stabilno (ne). Prav tako je težko zanikati dejstvo, da kompleks strojne in programske opreme preprosto deluje, zahteva le konfiguracijo, medtem ko je zagon in vzdrževanje virtualnega prehoda naloga močnih inženirjev.

Z eno nogo prehod pogleda v navidezno omrežje Overlay, kot običajni navidezni stroj, in lahko komunicira z vsemi drugimi VM-ji. Hkrati lahko prekine omrežja vseh odjemalcev in v skladu s tem izvaja usmerjanje med njimi.

Z drugo nogo prehod gleda v hrbtenično omrežje in ve, kako priti na internet.

Podatkovna ravnina

Se pravi, postopek izgleda takole:

1. VM-0, ki je privzeto nastavljen na isti vRouter, pošlje paket s ciljem v zunanjem svetu (185.147.83.177) vmesniku eth0.
2. vRouter prejme ta paket in poišče ciljni naslov v usmerjevalni tabeli – poišče privzeto pot prek prehoda VNGW1 skozi tunel 1.
   Prav tako vidi, da je to tunel GRE s SIP 10.0.0.2 in DIP 10.0.255.2, prav tako mora najprej priložiti oznako MPLS tega odjemalca, kar pričakuje VNGW1.
3. vRouter zapakira začetni paket z MPLS, GRE in novimi glavami IP ter ga privzeto pošlje na naslov ToR1 10.0.0.1.
4. Osnovno omrežje dostavi paket do prehoda VNGW1.
5. Prehod VNGW1 odstrani glave tuneliranja GRE in MPLS, vidi ciljni naslov, se posvetuje s svojo usmerjevalno tabelo in razume, da je usmerjen v internet - to je prek celotnega pogleda ali privzetega. Po potrebi izvede prevod NAT.
6. Od VNGW do meje bi lahko obstajalo običajno omrežje IP, kar je malo verjetno.
   Lahko je klasično omrežje MPLS (IGP+LDP/RSVP TE), lahko je back fabric z BGP LU ali tunel GRE od VNGW do meje prek omrežja IP.
   Kakor koli že, VNGW1 izvede potrebne inkapsulacije in pošlje začetni paket proti meji.

Promet v nasprotni smeri gre skozi iste korake v nasprotnem vrstnem redu.

1. Meja spusti paket na VNGW1
2. Sleče ga, pogleda naslov prejemnika in vidi, da je dostopen skozi tunel Tunnel1 (MPLSoGRE ali MPLSoUDP).
3. V skladu s tem pripne oznako MPLS, glavo GRE/UDP in nov IP ter ga pošlje svojemu ToR3 10.0.255.1.
   Ciljni naslov tunela je naslov IP vRouterja, za katerim se nahaja ciljni VM – 10.0.0.2.
4. Osnovno omrežje dostavi paket do želenega vRouterja.
5. Ciljni vRouter bere GRE/UDP, identificira vmesnik z uporabo oznake MPLS in pošlje goli paket IP svojemu vmesniku TAP, ki je povezan z eth0 VM.

Nadzorna ravnina

VNGW1 vzpostavi sosesko BGP s krmilnikom SDN, od katerega prejme vse informacije o usmerjanju odjemalcev: kateri naslov IP (vRouter) je za katerim odjemalcem in po kateri oznaki MPLS je identificiran.

Podobno sam obvesti krmilnik SDN o privzeti poti z oznako tega odjemalca, pri čemer se označi kot nexthop. In potem ta privzeta vrednost pride do vRouters.

Na VNGW običajno pride do združevanja poti ali prevajanja NAT.

In v drugi smeri pošlje natanko to združeno pot v sejo z mejami ali odsevniki poti. In od njih prejme privzeto pot ali Full-View ali kaj drugega.

V smislu enkapsulacije in izmenjave prometa se VNGW ne razlikuje od vRouterja.
Če nekoliko razširite obseg, lahko VNGW in vRouterjem dodate druge omrežne naprave, kot so požarni zidovi, farme za čiščenje ali obogatitev prometa, IPS itd.

In s pomočjo zaporednega ustvarjanja VRF-jev in pravilnega oglaševanja poti lahko prisilite promet v zanko, kot želite, kar se imenuje Service Chaining.

To pomeni, da tudi tukaj krmilnik SDN deluje kot Route-Reflector med VNGW, vRouterji in drugimi omrežnimi napravami.

Toda v resnici krmilnik pušča tudi informacije o ACL in PBR (Policy Based Routing), zaradi česar posamezni prometni tokovi potekajo drugače, kot jim narekuje pot.

FAQ

Zakaj vedno dajete pripombo GRE/UDP?

No, na splošno lahko rečemo, da je to specifično za Tungsten Fabric - tega vam sploh ni treba upoštevati.

Toda če vzamemo, potem je sam TF, medtem ko je še vedno OpenContrail, podpiral obe enkapsulaciji: MPLS v GRE in MPLS v UDP.

UDP je dober, ker je v izvornih vratih zelo enostavno kodirati zgoščevalno funkcijo iz izvirnega IP+Proto+Port v njegovo glavo, kar vam bo omogočilo izravnavo.

V primeru GRE, žal, obstajajo le zunanji naslovi IP in GRE, ki so enaki za ves inkapsuliran promet in o uravnoteženju ni govora - malokdo lahko pogleda tako globoko v notranjost paketa.

Do nekaj časa so usmerjevalniki, če so znali uporabljati dinamične tunele, to počeli le v MPLSoGRE, šele pred kratkim pa so se naučili uporabljati MPLSoUDP. Zato moramo vedno upoštevati možnost dveh različnih enkapsulacij.

Po pravici povedano je treba omeniti, da TF v celoti podpira povezljivost L2 z uporabo VXLAN.

Obljubili ste, da boste potegnili vzporednice z OpenFlow.
Res prosijo za to. vSwitch v istem OpenStacku počne zelo podobne stvari z uporabo VXLAN, ki ima, mimogrede, tudi glavo UDP.

V Data Plane delujejo približno enako, Control Plane se bistveno razlikuje. Tungsten Fabric uporablja XMPP za dostavo informacij o usmerjanju vRouter, medtem ko OpenStack izvaja Openflow.

Mi lahko poveste kaj več o vRouterju?
Razdeljen je na dva dela: vRouter Agent in vRouter Forwarder.

Prvi se izvaja v uporabniškem prostoru gostiteljskega OS in komunicira s krmilnikom SDN ter izmenjuje informacije o poteh, VRF-jih in ACL-jih.

Drugi implementira Data Plane - običajno v Kernel Space, vendar lahko deluje tudi na SmartNIC - omrežnih karticah s CPE in ločenim programabilnim preklopnim čipom, ki vam omogoča, da odstranite obremenitev s CPE gostiteljskega računalnika in naredite omrežje hitrejše in več predvidljivo.

Drug možen scenarij je, da je vRouter aplikacija DPDK v uporabniškem prostoru.

vRouter Agent pošlje nastavitve vRouter Forwarder.

Kaj je navidezno omrežje?
Že na začetku članka o VRF sem omenil, da je vsak najemnik vezan na svoj VRF. In če je bilo to dovolj za površno razumevanje delovanja prekrivnega omrežja, potem je treba pri naslednji ponovitvi narediti pojasnila.

Običajno je v mehanizmih virtualizacije entiteta navideznega omrežja (to lahko menite za lastni samostalnik) uvedena ločeno od odjemalcev/najemnikov/virtualnih strojev – popolnoma neodvisna stvar. In to navidezno omrežje je že mogoče povezati prek vmesnikov z enim najemnikom, z drugim, z dvema ali kjer koli. Tako se na primer veriženje storitev izvaja, ko je treba promet prenesti skozi določena vozlišča v zahtevanem zaporedju, preprosto z ustvarjanjem in povezovanjem navideznih omrežij v pravilnem zaporedju.

Zato kot taka ne obstaja neposredna korespondenca med virtualnim omrežjem in najemnikom.

Zaključek

To je zelo površen opis delovanja virtualnega omrežja s prekrivko iz gostitelja in krmilnika SDN. Toda ne glede na to, katero virtualizacijsko platformo izberete danes, bo delovala na podoben način, pa naj bo to VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric ali Juniper Contrail. Razlikovali se bodo po vrstah enkapsulacij in glav, protokolih za dostavo informacij končnim omrežnim napravam, vendar bo princip programsko nastavljivega prekrivnega omrežja, ki deluje na vrhu relativno preprostega in statičnega podložnega omrežja, ostal enak.
Lahko rečemo, da je danes SDN, ki temelji na prekrivnem omrežju, osvojil področje ustvarjanja zasebnega oblaka. Vendar to ne pomeni, da Openflow nima mesta v sodobnem svetu - uporablja se v OpenStacke in v istem VMWare NSX, kolikor vem, ga Google uporablja za postavitev podzemnega omrežja.

Spodaj sem navedel povezave do podrobnejših gradiv, če želite vprašanje preučiti globlje.

Kaj pa naša podloga?

Ampak na splošno nič. Ni se spremenil v celoti. Vse, kar mora storiti v primeru prekrivanja s strani gostitelja, je posodobitev poti in ARP-jev, ko se vRouter/VNGW pojavi in ​​izgine ter med seboj prenaša pakete.

Oblikujmo seznam zahtev za omrežje Underlay.

1. Biti sposoben uporabljati nekakšen usmerjevalni protokol, v našem primeru - BGP.
2. Imejte široko pasovno širino, po možnosti brez prevelike naročnine, da se paketi ne izgubijo zaradi preobremenitev.
3. Podpora ECMP je sestavni del tkanine.
4. Biti sposoben zagotoviti QoS, vključno s težavnimi stvarmi, kot je ECN.
5. Podpora NETCONF je temelj za prihodnost.

Tu sem zelo malo časa posvetil samemu delu mreže Underlay. To je zato, ker se bom pozneje v seriji osredotočil na to, prekrivanja pa se bomo dotaknili le mimogrede.

Očitno nas vse močno omejujem z uporabo omrežja DC, zgrajenega v tovarni Cloz, s čistim usmerjanjem IP in prekrivanjem gostitelja.

Vendar sem prepričan, da je vsako omrežje, ki ima zasnovo, mogoče opisati s formalnimi izrazi in avtomatizirati. Samo moj cilj je razumeti pristope k avtomatizaciji in ne zmešati vseh z reševanjem problema v splošni obliki.

Kot del ADSM nameravava z Romanom Gorgom objaviti ločeno številko o virtualizaciji računalniške moči in njeni interakciji z virtualizacijo omrežja. Ostati v stiku.

Uporabne povezave

• Arhitektura volframove tkanine.
• o: oblaku. 6 ur o Yandex.Cloudu, ki pokriva tudi virtualno omrežje na TF.
• Kaj je Open vSwitch?
• Uvod v VxLAN.
• RFC 7348. Navidezno razširljivo lokalno omrežje (VXLAN): ogrodje za prekrivanje virtualiziranih omrežij ravni 2 nad omrežji plasti 3.
  
• Scaleway pristop k VXLAN EVPN Fabric. Govori o celotnem DC omrežju, vključno z Underlay, Overlay, pristopi k multi-homingu in upravljanju.

Hvala vam

• Roman Gorga - nekdanji voditelj podcasta linkmeup in zdaj strokovnjak na področju oblačnih platform. Za komentarje in popravke. No, njegov bolj poglobljen članek o virtualizaciji čakamo v bližnji prihodnosti.
• Aleksander Šalimov - moj kolega in strokovnjak na področju razvoja virtualnih omrežij. Za komentarje in popravke.
• Valentin Sinicin - moj kolega in strokovnjak na področju Tungsten Fabric. Za komentarje in popravke.
• Artjom Černobaj — povezava ilustratorja. Za KDPV.
• Aleksander Limonov. Za meme "avtomat".

Vir: www.habr.com