V Opišal sem okvir za omrežno avtomatizacijo. Po mnenju nekaterih ljudi je že ta prvi pristop k problemu razjasnil nekatere zadeve. To me zelo veseli, saj je naš cilj v ciklu, da ne prekrijemo Ansible-a s Python skripti, temveč zgradimo sistem.
Ta okvir določa vrstni red, s katerim bomo obravnavali vprašanje.
In virtualizacija omrežja, ki je namenjena tej izdaji, se ne ujema najbolje s tematiko ADSM, kjer obravnavamo avtomatizacijo.
Toda poglejmo jo z druge perspektive.
Že dolgo časa se mnoge storitve zanašajo na isto omrežje. V primeru telekomunikacijskega operaterja to vključuje 2G, 3G, LTE, širokopasovni internet in B2B, na primer. V primeru podatkovnih centrov: povezanost za različne stranke, internet, blokovno shranjevanje, objektno shranjevanje.
In vse storitve zahtevajo izolacijo druga od druge. Tako so nastala overlay omrežja.
In vse storitve nočejo čakati, da jih nekdo nastavi ročno. Tako so nastali orkestratorji in SDN.
Prvi pristop k sistematični avtomatizaciji omrežja, natančneje njenega dela, je bil že dolgo vzpostavljen in uveljavljen na mnogih mestih: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
O tem se bomo danes pogovarjali.
Vsebina
- Razlogi
- Terminologija
- Podlaga — fizično omrežje
- Overlay — virtualno omrežje
- Overlay z ToR
- Overlay z gostitelja
- Na primeru Tungsten Fabric
- Komunikacija znotraj ene fizične naprave
- Komunikacija med VM-ji, ki so nameščeni na različnih fizičnih napravah
- Izhod v zunanji svet
- FAQ
- Zaključek
- Koristne poveznice
Razlogi
In ker smo že omenili to temo, je smiselno omeniti tudi predpogoje za virtualizacijo omrežja. Ta proces se je v resnici začel že davno.
Verjetno ste že slišali, da je omrežje vedno bilo najbolj inertni del vsakega sistema. In to je res v vseh pogledih. Omrežje je osnova, na katero se naslanja vse, in spremembe nanj so precej zapletene — storitve ne dopuščajo, da omrežje ne deluje. Pogosto lahko izločitev enega vozlišča ohromi velik del aplikacij in vpliva na veliko strank. Deloma zato se lahko omrežna ekipa upira kakršnim koli spremembam — ker sedaj nekako deluje (morda celo ne vemo kako), sedaj pa je potrebno nastaviti nekaj novega, pri čemer pa ni jasno, kako bo to vplivalo na omrežje.
Da bi se izbeglo čekanje da provajderi postave VLAN i da se bilo koji servisi ne moraju postavljati na svakom čvoru mreže, ljudi su smislili korišćenje overlay mreža — kojih ima raznovrsnih: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE itd.
Njihova privlačnost dolazi iz dve jednostavne stvari:
- Konfigurišu se samo krajnji čvorovi — transitne se ne diraju. Ovo značajno ubrzava proces i ponekad čak omogućava potpuno isključivanje odeljenja mrežne infrastrukture iz procesa uvođenja novih usluga.
- Opterećenje je skriveno duboko unutar zaglavlja — transitnim čvorovima nije potrebno ništa da zna o njemu, o adresiranju na hostovima, rutama overlay mreže. A to znači da je potrebno čuvati manje informacija u tabelama, pa je moguće koristiti jednostavnije/jeftinije uređaje.
U ovom ne sasvim potpunom izdanju ne planiram da razmatram sve moguće tehnologije, već ću opisati okvir rada overlay mreža u DC-u.
Cela serija će opisivati data centar koji se sastoji od redova identičnih oprema, u kojima je instalirana identična serverska oprema.
Na toj opremi se pokreću virtuelne mašine/kontejneri/serverless koji implementiraju servise.
Terminologija
U ciklusu serverom ću nazvati program koji implementira serversku stranu klijent-server komunikacije.
Fizičke mašine u rackovima nazivamo serverima ne biće.
Fizička mašina — x86 računar koji je instaliran u racku. Najčešće korišćen termin host. Tako ćemo je nazivati „mašina“ ili host.
Hipervizor — aplikacija pokrenuta na fizičkoj mašini koja emulira fizičke resurse, na kojima se pokreću virtuelne mašine. Ponekad se u literaturi i na mreži reč „hipervizor“ koristi kao sinonim za „host“.
Virtualni stroj — operativni sistem koji je pokrenut na fizičkoj mašini iznad hipervizora. Za nas u okviru ovog ciklusa nije toliko važno da li je to zaista virtuelna mašina ili samo kontejner. Zvaćemo to „VM«
Tenan — širok pojam koji ću u ovom članku definisati kao odvojenu uslugu ili odvojenog klijenta.
Višekorisničko ili multitenantovanje — korišćenje iste aplikacije od strane različitih klijenata/usluga. Pri tome se izolacija klijenata postiže zahvaljujući arhitekturi aplikacije, a ne pokrenutim odvojenim instancama.
ToR — Top of the Rack switch — switch mounted in a rack to which all physical machines are connected.
In addition to the ToR topology, different providers practice End of Row (EoR) or Middle of Row (although the latter is a neglectable rarity and I have not encountered the MoR abbreviation).
Underlay network or the underlying network or underlay — the physical network infrastructure: switches, routers, cables.
Overlay network or the overlay network — a virtual network of tunnels operating over the physical layer.
L3-fabric or IP-fabric — a remarkable invention of humanity that allows not repeating STP in interviews and not learning TRILL. A concept where the entire network up to the access level is exclusively L3, without VLANs and thus huge stretched broadcast domains. We will discuss where the term 'fabric' comes from in the next part.
SDN — Software Defined Network. Hardly needs an introduction. An approach to network management where changes in the network are made by a program rather than by a person. Usually implies moving the Control Plane beyond the end network devices to a controller.
NFV — Network Function Virtualization — virtualization of network devices, implying that some network functions can be run as virtual machines or containers to accelerate the deployment of new services, facilitate Service Chaining, and allow for easier horizontal scalability.
VNF — Virtual Network Function. A specific virtual device: router, switch, firewall, NAT, IPS/IDS, etc.
I am deliberately simplifying the description to a specific implementation to avoid confusing the reader too much. For a more thoughtful reading, I direct them to the section . Additionally, Roma Gorge, who criticizes this article for inaccuracies, promises to write a separate issue about server and network virtualization technologies, which will be more in-depth and detail-oriented.
Most networks today can clearly be divided into two parts:
Underlay — the physical network with a stable configuration.
Overlay — an abstraction over Underlay for isolating tenants.
This is true for both the DC case (which we will discuss in this article) and for ISPs (which we will not discuss, as it has already been covered in ). With enterprise networks, of course, the situation is somewhat different.
Image focusing on the network:
Underlay
Underlay je fizična mreža: strojni stikala in kabli. Naprave v underlay-u vedo, kako priti do fizičnih naprav.
Oprta je na standardne protokole in tehnologije. Ne nazadnje zato, ker strojne naprave do danes delujejo na lastniškem programski opremi, ki ne dopušča programiranja čipov ali izvajanja lastnih protokolov, zato je potrebna združljivost z drugimi ponudniki in standardizacija.
Nekdo kot Google si lahko privošči razvoj lastnih stikal in opustitev splošno sprejetih protokolov. Ampak LAN_DC ni Google.
Underlay se relativno redko spreminja, ker je njegova naloga osnovna IP-povezljivost med fizičnimi napravami. Underlay ne ve nič o storitvah, strankah, najemnikih, ki tečejo nad njim — le dostaviti mora paket od ene naprave do druge.
Underlay je lahko na primer takšen:
- IPv4+OSPF
- IPv6+ISIS+BGP+L3VPN
- L2+TRILL
- L2+STP
Underlay omrežje se nastavi na klasičen način: CLI/GUI/NETCONF.
Ročno, s skripti, z lastniškimi orodji.
Podrobneje bo underlay obravnavan v naslednjem članku v seriji.
Overlay
Overlay je virtualno omrežje tunelov, raztegnjeno nad Underlay-em, ki omogoča VM enega naročnika komunikacijo med seboj, pri čemer zagotavlja izolacijo od drugih naročnikov.
Podatki stranke so enkapsulirani v tunelirne naslove za prenos preko skupne mreže.
Tako lahko VM enega naročnika (enega servisa) komunicirajo med seboj preko Overlay-a, celo ne da bi slutili, katero pot paket pravzaprav potuje.
Overlay je lahko na primer takšen, kot sem že omenil zgoraj:
- GRE-tunel
- VXLAN
- EVPN
- L3VPN
- GENEVE
Overlay omrežje se običajno nastavi in vzdržuje preko centralnega krmilnika. Z njega se konfiguracija, Control Plane in Data Plane dostavljajo na naprave, ki skrbijo za usmerjanje in enkapsulacijo prometa strank. Malo to bomo razčlenili na primerih.
Ja, to je SDN v svoji čistejši obliki.
Obstajata dva principielno različna pristopa k organizaciji Overlay omrežja:
- Overlay z ToR
- Overlay z gostitelja
Overlay z ToR
Overlay se lahko začne na dostopnem stikalih (ToR), ki stoji v omari, kot se dogaja, na primer, v primeru VXLAN tovarne.
To je s časom preizkušen mehanizem v ISP omrežjih, vsa omrežna oprema ga podpira.
Vendar v tem primeru mora ToR stikalo znati ločiti različne storitve, ustrezno pa mora omrežni administrator do neke mere sodelovati z administratorji virtualnih strojev ter vnašati spremembe (tudi samodejno) v konfiguracijo naprav.
Tukaj bralca napotim na članek o našega starega prijatelja .
V tem so podrobno opisani pristopi k gradnji omrežja DC z EVPN VXLAN tovarno.
Za bolj popolno potopitev v realnost pa lahko preberete Cisckovo knjigo .
Opozarjam, da je VXLAN le metoda enkapsulacije, terminacija tunelov pa se lahko izvaja ne na ToR-u, temveč na gostitelju, kot se dogaja v primeru OpenStack-a, na primer.
Vendar pa je VXLAN tovarna, kjer overlay začne na ToR-u, eno izmed ustaljenih oblik oblikovanja overlay omrežja.
Overlay z gostitelja
Drugi pristop je začeti in terminirati tunele na končnih gostiteljih.
V tem primeru omrežje (Underlay) ostane kar se da preprosto in statično.
Gostitelj pa opravi vse potrebne enkapsulacije sam.
Za to bo nedvomno potrebno zagnati posebno aplikacijo na gostiteljih, vendar se to splača.
Prvič, zagon odjemalca na linux stroju je enostavnejši ali, recimo, — sploh mogoč — medtem ko bo verjetno na switchu treba še naprej uporabljati lastniške SDN rešitve, kar ubija idejo večvenderne rešitve.
Drugič, ToR stikalo lahko v tem primeru ostane kar se da preprosto, tako z vidika Control Plane kot tudi Data Plane. Resnično — s SDN krmilnikom mu potem ni treba komunicirati in shranjevati omrežij/ARP-jev vseh priključenih strank — dovolj je poznati IP naslov fizičnega stroja, kar znatno poenostavi tabele preklapljanja/rutiranja.
V seriji ADSN izbiram pristop overlay z gostitelja — naprej bomo govorili samo o njem in se ne bomo več vračali k VXLAN tovarni.
Najlažje bo obravnavati s primeri. In kot poskusni subjekt bomo vzeli OpenSource SDN platformo OpenContrail, danes znano kot .
Na koncu članka bom priložil nekaj razmišljanj o analogiji z OpenFlow in OpenvSwitch.
Na primeru Tungsten Fabric
Na vsakem fizičnem stroju je vRouter — virtualni usmerjevalnik, ki pozna omrežja, povezana z njim, in katerim strankam pripadajo — v bistvu — PE usmerjevalnik. Za vsako stranko ohranja izolirano tabelo usmerjanja (beri VRF). In v bistvu vRouter izvaja Overlay tunneling.
Malce podrobneje o vRouterju — na koncu članka.
Vsaka VM, nameščena na hipervizorju, se povezuje z vRouterjem te naprave preko .
TAP — Terminal Access Point — virtualni vmesnik v jedru linux, ki omogoča omrežno interakcijo.
Če je za vRouterjem več omrežij, se za vsakega od njih ustvari virtualni vmesnik, na katerega se dodeli IP-naslov — ta bo naslov privzetega prehoda.
Vsa omrežja ene stranke se postavijo v en VRF (eno tabelo), različna — v različne.
Tu bi dodal opombo, da ni vse tako preprosto, in bi rad radovednega bralca napotil na konec članka..
Da bi se vRouterji lahko med seboj povezovali, in s tem tudi VM, ki so za njimi, izmenjujejo informacije o usmerjanju preko SDN-kontrolerja..
Da bi se prebijali v zunanji svet, obstaja izhodna točka iz matrike — prehod virtualnega omrežja VNGW — Virtual Network GateWay (to je moj izraz.).
Zdaj si poglejmo primere komunikacij — in bo jasno.
Komunikacija znotraj ene fizične naprave
VM0 želi poslati paket na VM2. Predpostavimo zaenkrat, da gre za VM ene stranke.
Data Plane
- VM-0 ima privzeto pot do svojega vmesnika eth0. Paket se pošlje tja.
Ta vmesnik eth0 je dejansko virtualno povezan z virtualnim usmerjevalnikom vRouter preko TAP-vmesnika tap0. - vRouter analizira, na kateri vmesnik je prišel paket, torej kateremu klientu (VRF) pripada, in preveri naslov prejemnika s tabelo usmerjanja te stranke.
- Ko ugotovi, da je prejemnik na isti napravi za drugim priključkom, vRouter preprosto pošlje paket vanj brez dodatnih naslovov — za ta primer ima vRouter že ARP-vnos.
V tem primeru paket ne pride v fizično omrežje — usmerjen je bil znotraj vRouterja.
Control Plane
Hipervizor ob zagonu virtualne naprave sporoči:
- Njen lastni IP-naslov.
- Privzeta pot — preko IP-naslova vRouterja v tem omrežju.
vRouterju preko posebnega API-ja hipervizor sporoča:
- Kaj je treba ustvariti virtualni vmesnik.
- Katero virtualno omrežje (VN) naj ustvari.
- Na kateri VRF naj ga (VN) veže.
- Statični ARP zapis za to VM — za kakšen vmesnik se nahaja njen IP naslov in kateremu MAC naslovu je pritrjen.
In spet je dejanska procedura interakcije poenostavljena za razumevanje koncepta.
Tako vse VM enega strank na tem strežniku vRouter vidi kot neposredno priključene mreže in lahko samostojno usmerja med njimi.
VM0 in VM1 pa pripadata različnim strankam, zato sta v različnih tabelah vRouterja.
Ali se lahko neposredno pogovarjata, je odvisno od nastavitev vRouter in zasnove omrežja.
Na primer, če VM obeh strank uporabljata javne naslove, ali če se NAT izvaja na samem vRouterju, potem je mogoče vzpostaviti neposredno usmerjanje na vRouterju.
V nasprotnem primeru je mogoče prekrivanje naslovnih prostorov — potrebno je iti skozi NAT strežnik, da pridobimo javni naslov — to je podobno izhodu v zunanja omrežja, ki jih obravnavamo spodaj.
Komunikacija med VM-ji, ki so nameščeni na različnih fizičnih napravah
Data Plane
- Začetek je povsem enak: VM-0 pošlje paket z naslovnikom VM-7 (172.17.3.2) po svojem privzetem.
- vRouter ga prejme in tokrat vidi, da je naslovnik na drugem strežniku in dostopen preko tunela Tunnel0.
- Najprej doda MPLS oznako, ki identificira oddaljeni vmesnik, da lahko na drugi strani vRouter določi, kam naj pošlje ta paket, brez dodatnih preusmeritev.
- Tunel0 ima vir 10.0.0.2, prejemnik: 10.0.1.2.
vRouter doda GRE (ali UDP) naslove in nov IP k izvirnemu paketu. - V tabeli usmerjanja vRouterja obstaja privzeta pot preko naslova ToR1 10.0.0.1. Tja tudi pošlje.
- ToR1 kot udeleženec Underlay omrežja ve (na primer, preko OSPF), kako priti do 10.0.1.2 in pošlje paket po poti. Upoštevajte, da se tukaj vključuje ECMP. Na ilustraciji sta dva naslednja skoka, različni tokovi pa se bodo razdelili med njimi glede na hash. V primeru pravega okolja bi tukaj verjetno bilo 4 naslednjih skokov.
Pri tem ni potrebno vedeti, kaj se nahaja pod zunanjim IP naslovom. To pomeni, da je dejansko pod IP lahko sendvič iz IPv6 nad MPLS nad Ethernet nad MPLS nad GRE nad nad nad Grek.
- Zato na sprejemni strani vRouter odstrani GRE in po MPLS oznaki razume, v kateri vmesnik je treba ta paket poslati, ga razgrne in pošlje v prvotni obliki prejemniku.
Control Plane
Pri zagonu stroja se zgodi vse, kar je bilo opisano zgoraj.
In plus še naslednje:
- Za vsakogar klienta vRouter dodeli MPLS-oznake. To je servisna oznaka L3VPN, po kateri bodo klienti ločeni znotraj ene fizične naprave.
V resnici vRouter vedno dodeli MPLS-oznake - saj vnaprej ni znano, ali se bo naprava povezala samo z drugimi napravami za tem vRouterjem, kar verjetno ni niti blizu resnici.
- vRouter vzpostavi povezavo z SDN-nadzornikom preko protokola BGP (ali podobnega - v primeru TF je to XMPP 0_o).
- Skozi to sejo vRouter obvešča SDN-nadzornika o poteh do povezanih omrežij:
- Naslov omrežja
- Metoda inkapsulacije (MPLSoGRE, MPLSoUDP, VXLAN)
- MPLS-oznake klienta
- Svoj IP-naslov kot nexthop
- SDN-nadzornik prejme te poti od vseh povezanih vRouterjev in jih odraža drugim. To pomeni, da deluje kot Route Reflector.
Enako se dogaja tudi v obratni smeri.
Overlay se lahko spreminja celo vsako minuto. Tako nekako se dogaja v javnih oblakih, ko klienti redno zaženejo in ugasnejo svoje virtualne naprave.
Centralni nadzornik se ukvarja z vsemi težavami pri vzdrževanju konfiguracije in kontroli tabel preklapljanja/rutiranja na vRouterju.
Približno rečeno, nadzornik se poveže z vsemi vRouterji preko BGP (ali podobnega protokola) in preprosto prenaša informacije o poteh. BGP, na primer, že ima Address-Family za prenos metode inkapsulacije. ili .
Pri tem se na noben način ne spreminja konfiguracija Underlay-omrežja, ki je v resnici veliko težje avtomatizirati, zlomiti pa je lažje z nepremišljenim gibom.
Izhod v zunanji svet
Nekje se mora simulacija končati in iz virtualnega sveta je treba preiti v resničnost. In potreben je dostopni telefon.
Uvajata se dva pristopa:
- Namesti se strojni usmerjevalnik.
- Zažene se kakšen appliance, ki izvaja funkcije usmerjevalnika (da, res, poleg SDN smo se srečali tudi z VNF). Poimenujmo ga virtualni prehod.
Prednost drugega pristopa je poceni horizontalna razširljivost - če zmanjka zmogljivosti, zaženemo še eno virtualko s prehodom. Na vsaki fizični napravi, brez potrebe po iskanju prostih omar, enot, napajanja, nakupu same strojne opreme, njenem transportu, namestitvi, kabliranju, nastavitvi, nato pa še menjavi pokvarjenih komponent.
Slabosti virtualnog gateway-a su u tome što je fizički router nekoliko puta jači od višejezgrenog virtualnog uređaja, a njegov softver prilagođen njegovoj hardverskoj osnovi radi znatno stabilnije (ne). Teško je negirati i činjenicu da hardversko-softverski sklop jednostavno funkcioniše, zahtevajući samo podešavanja, dok je pokretanje i održavanje virtualnog gateway-a zadatak za iskusne inženjere.
Jednom nogom, gateway gleda u virtualnu mrežu Overlay, kao obična Virtualna Mašina, i može se povezati sa svim drugim VM. Pri tome može preuzimati mreže svih klijenata i, shodno tome, obavljati rutiranje među njima.
Drugom nogom, gateway gleda u glavnu mrežu i zna kako da se poveže s Internetom.
Data Plane
Dakle, proces izgleda ovako:
- VM-0, imajući podrazumevano sve u istom vRouter-u, šalje paket sa odredištem u spoljnem svetu (185.147.83.177) na interfejs eth0.
- vRouter prima ovaj paket i pravi lookup adrese odredišta u tabeli rutiranja – pronalazi podrazumevani put kroz gateway VNGW1 preko Tunnela 1.
Takođe vidi da je to GRE tunel sa SIP 10.0.0.2 i DIP 10.0.255.2, a još treba prvo da zakači MPLS oznaku ovog klijenta, koju očekuje VNGW1. - vRouter upakuje početni paket u MPLS, GRE i novi IP header i šalje na adresu ToR1 10.0.0.1 po defaultu.
- Podmreža dostavlja paket do gateway-a VNGW1.
- Gateway VNGW1 skida tunelske header-e GRE i MPLS, vidi adresu odredišta, konsultuje svoju tabelu rutiranja i shvata da je upućen ka Internetu – to znači kroz Full View ili Default. Po potrebi vrši NAT prevođenje.
- Od VNGW-a do border-a može biti obična IP mreža, što je malo verovatno.
Može biti klasična MPLS mreža (IGP+LDP/RSVP TE), može biti povratna fabrika sa BGP LU ili GRE tunel od VNGW do border-a preko IP mreže.
Kako god, VNGW1 vrši potrebne inkapsulacije i šalje originalni paket prema border-u.
Saobraćaj u suprotnom smeru prolazi iste korake obrnutim redosledom.
- Border šalje paket do VNGW1
- On ga skida, gleda adresu primaoca i vidi da je dostupan preko tunela Tunnel1 (MPLSoGRE ili MPLSoUDP).
- Shodno tome, postavlja MPLS oznaku, GRE/UDP header i novi IP i šalje na svoj ToR3 10.0.255.1.
Naslov odredišnog tunela je IP adresa vRouter-a iza kojeg se nalazi ciljana VM — 10.0.0.2. - Podmreža dostavlja paket potrebnom vRouter-u.
- Ciljani vRouter uklanja GRE/UDP, određuje interfejs putem MPLS oznake i šalje čisti IP paket na svoj TAP interfejs, povezan sa eth0 VM.
Control Plane
VNGW1 uspostavlja BGP susedstvo sa SDN kontrolerom, od kojeg dobija sve informacije o rutama kupaca: iza kojeg IP-a (vRouter-a) se nalazi koji kupac i kojom MPLS oznakom se identifikuje.
Slično, on sam SDN kontroleru javlja podrazumevanu rutu sa oznakom tog kupca, navodeći sebe kao nexthop. Onda ta podrazumevana ruta dolazi do vRouter-a.
Na VNGW obično dolazi do agregacije ruta ili NAT prevođenja.
I u drugu stranu u sesiju sa bordovima ili Route Reflector-ima on vraća upravo tu agregiranu rutu. A od njih dobija rutu po defaultu ili Full-View, ili nešto drugo.
U pogledu enkapsulacije i razmene saobraćaja, VNGW se ne razlikuje od vRouter-a.
Ako malo proširimo oblast, mogu se VNGW i vRouter-i dopuniti drugim mrežnim uređajima, kao što su vatrozidi, farme za čišćenje ili obogaćivanje saobraćaja, IPS i slično.
I uz pomoć sekvencijalnog kreiranja VRF i pravilnog najavljivanja ruta, može se naterati saobraćaj da se pruža onako kako želite, što se naziva Service Chaining.
Dakle, i ovde SDN kontroler igra ulogu Route Reflector-a između VNGW, vRouter-a i drugih mrežnih uređaja.
Ali, zapravo, kontroler takođe šalje informacije o ACL i PBR (Policy Based Routing), nateravajući pojedinačne tokove saobraćaja da se kreću suprotno od onoga što im ruta nalaže.
FAQ
Zašto stalno naglašavaš GRE/UDP?
Pa, u stvari, to je specifično za Tungsten Fabric — zapravo se može potpuno zanemariti.
Ali ako se gleda, sam TF, još kao OpenContrail, podržavao je obe enkapsulacije: MPLS in GRE i MPLS in UDP.
UDP je dobar jer se u Source Port-u u njegovom zaglavlju vrlo lako može kodirati hash funkcija od originalnih IP+Proto+Port, što će omogućiti balansiranje.
U slučaju GRE, nažalost, postoje samo spoljašnji IP i GRE zaglavlja, koja su identična za sav enkapsulirani saobraćaj i o balansiranju ne može biti reči — malo ko može zaviriti tako duboko unutar paketa.
Do nekaterih trenutkov so usmerjevalniki, čeprav so znali obvladati dinamične tuneline, le v MPLSoGRE, in šele nedavno so se naučili v MPLSoUDP. Zato moramo vedno dodati opombo o možnosti dveh različnih inkapsulacij.
Pošteno je poudariti, da TF povsem podpira tudi L2-povezljivost preko VXLAN.
Obljubil si, da boš delal vzporednice z OpenFlow.
Resnično se ponujajo. vSwitch v istem OpenStacku dela precej podobne stvari, uporablja VXLAN, ki ima, mimogrede, tudi UDP-zaglavje.
V podatkovni ravnini delujejo približno enako, bistveno pa se razlikujeta kontrolna ravnina. Tungsten Fabric uporablja XMPP za dostavo informacij o poteh na vRouter, medtem ko v OpenStacku deluje OpenFlow.
Ali lahko poveš kaj več o vRouterju?
Deljen je na dva dela: vRouter Agent in vRouter Forwarder.
Prvi se izvaja v User Space gostiteljskega operacijskega sistema in komunicira s SDN-nadzornikom ter izmenjuje informacije o poteh, VRF in ACL.
Drugi izvaja podatkovno ravnino — običajno v Kernel Space, lahko pa se izvaja tudi na SmartNIC-ih — omrežnih karticah s CPU in ločenim programabilnim čipom za preklapljanje, kar omogoča zmanjšanje obremenitve na CPU gostiteljske naprave ter hitrejšo in bolj predvidljivo omrežje.
Mogoče je tudi scenarij, ko je vRouter aplikacija DPDK v User Space.
vRouter Agent prenese nastavitve na vRouter Forwarder.
Kaj je Virtual Network?
Na začetku članka sem omenil VRF, kar pomeni, da je vsak najemnik vezan na svoj VRF. In če je za površinsko razumevanje delovanja ovijalne mreže tega dovolj, pa je že pri naslednji iteraciji potrebno narediti pojasnila.
Običajno v mehanizmih virtualizacije entiteta Virtual Network (to lahko šteješ kot lastno ime) ni neposredno povezana s strankami/najemniki/virtualnimi stroji — gre za povsem samostojno stvar. Ta Virtual Network se lahko poveže z enim najemnikom, drugim, dvema ali kamorkoli. Tako se na primer izvaja Service Chaining, ko je treba promet preusmeriti skozi določene vozlišča v pravilnem zaporedju, preprosto z ustvarjanjem in povezovanjem Virtual Network-ov v pravem zaporedju.
Zato ne obstaja neposredno razmerje med Virtual Network in najemnikom.
Zaključek
To je precej površinski opis delovanja virtualnega omrežja z overlayjem iz gostitelja in SDN krmilnikom. Ne glede na to, katero virtualizacijsko platformo danes izberete, bo delovala na podoben način, bodisi da gre za VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric ali Juniper Contrail. Razlikovale se bodo le vrste inkapsulacij in glav, protokoli dostave informacij do končnih omrežnih naprav, a princip programsko nastavljivega overlay omrežja, ki deluje nad relativno preprostim in statičnim underlay omrežjem, ostaja enak.
Lahko rečemo, da je področje ustvarjanja zasebnega oblaka danes zmagalo s SDN, ki temelji na overlay omrežju. Vendar to ne pomeni, da Openflow nima mesta v sodobnem svetu — uporablja se v OpenStacku in v VMWare NSX, kolikor vem, ga Google uporablja za nastavitev underlay omrežja.
Malce nižje sem navedel povezave na podrobnejše materiale, če želite temo raziskati bolj poglobljeno.
Kaj pa naš Underlay?
Na splošno nič. Celo pot se ni spreminjal. Vse, kar mora početi v primeru overlayja iz gostitelja, je posodabljati poti in ARP-je, ko se pojavljajo in izginjajo vRouter/VNGW in prenašati pakete med njimi.
Določimo seznam zahtev za Underlay omrežje.
- Mora biti sposoben v nek protokol usmerjanja, v našem primeru — BGP.
- Imeti široko pasovno širino, najbolje brez preopterečenja, da ne bi izgubljali paketov zaradi obremenitev.
- Podpora ECMP je nepogrešljiv del tovarne.
- Mora omogočiti QoS, vključno s čudnimi stvarmi, kot je ECN.
- Podpora NETCONF — priprava na prihodnost.
Delo samega Underlay omrežja sem posvetil tukaj zelo malo časa. To je zato, ker se bom kasneje v seriji osredotočil prav nanj, overlay pa bomo obravnavali le mimogrede.
Očitno močno omejujem vse nas, ko kot primer uporabljam omrežje DC, zgrajeno na tovarni Kloza s čistim IP usmerjanjem in overlayjem iz gostitelja.
Vendar sem prepričan, da je mogoče katerokoli omrežje z zasnovo opisati v formalnih izrazih in avtomatizirati. Preprosto si tukaj prizadevam razumeti pristope k avtomatizaciji, ne pa zmede vse, ko rešem težavo na splošno.
V okviru ADMS-a s Romanom Gorgem načrtujemo objaviti poseben izdaj o virtualizaciji računalniških virov in njenem povezovanju z virtualizacijo omrežja. Ostanite v stiku.
Koristne poveznice
- .
- . 6 ur o Yandex.Cloud, kjer se med drugim obravnava virtualno omrežje na TF.
- .
- . Tu se govori o celotnem DC omrežju, vključno s Underlay, Overlay, pristopi k multi-homing in upravljanju.
Hvala
- — nekdanjem voditelju podkasta linkmeup, sedaj strokovnjaku za oblačne platforme. Hvala za komentarje in popravke. Upamo, da bomo v prihodnosti videli tudi njegovo globlje delo o virtualizaciji.
- — mojemu kolegu in strokovnjaku za razvoj virtualnih omrežij. Hvala za komentarje in popravke.
- — mojemu kolegu in strokovnjaku na področju Tungsten Fabric. Hvala za komentarje in popravke.
- — ilustratorju linkmeup. Hvala za KDPV.
- Aleksandru Limonovu. Hvala za mem «automato».
Izvor: habr.com
