U u prethodnom izdanju opisao sam okvir za automaciju mreže. Prema povratnim informacijama, čak je i ovaj prvi pristup problemu razjasnio neka pitanja za neke ljude. I to me veoma raduje, jer je naša svrha u ovom ciklusu izgraditi sustav, a ne pretrpavati Ansible Python skriptama.

Ovaj okvir utvrđuje redoslijed kojim ćemo se baviti ovim pitanjem.
I virtualizacija mreže, kojoj je posvećeno ovo izdanje, ne uklapa se baš u temu ADSM-a, gdje razmatramo automatizaciju.

Ali hajde da je pogledamo iz druge perspektive.

Već dugo vremena mnoge usluge dijele istu mrežu. U slučaju telekomunikacijskog operatera to su 2G, 3G, LTE, širokopojasni i B2B, na primjer. U slučaju podatkovnih centara: povezanost za različite klijente, Internet, blok pohranu, objektno pohranu.

I sve usluge zahtijevaju izolaciju jedna od druge. Tako su se pojavile overlay mreže.

I sve usluge ne žele čekati dok ih ljudi postave ručno. Tako su se pojavili orkestratori i SDN.

Prvi pristup sustavnoj automaciji mreže, točnije njenog dijela, davno je poduzet i puno puta implementiran: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

S njim ćemo se danas detaljnije pozabaviti.

Sadržaj

Uzroci
Terminologija
Underlay — fizička mreža
Overlay — virtualna mreža
- Overlay s ToR-a
- Overlay s hosta
- Na primjeru Tungsten Fabric
  - Komunikacija unutar jedne fizičke mašine
  - Komunikacija između VMs smještenih na različitim fizičkim mašinama
  - Izlaz u vanjski svijet
FAQ
Zaključak
Koristitne veze

Uzroci

I budući da smo o tome razgovarali, valja spomenuti preduvjete za virtualizaciju mreže. U stvarnosti, ovaj proces nije započeo jučer.

Vjerojatno ste nebrojeno puta čuli da je mreža oduvijek bila naj inertniji dio bilo kojeg sustava. I to je istina u svim smislenim aspektima. Mreža je temelj na kojem se sve oslanja, a promjene na njoj su prilično teško izvesti — usluge ne podnose kada mreža ne radi. Često isključenje jednog čvora može srušiti veliki dio aplikacija i utjecati na mnoge klijente. Djelomično zbog toga, mrežni tim može se opirati bilo kakvim promjenama — jer sada to nekako funkcioniše (možda čak niti ne znamo kako), a sada treba postaviti nešto novo, a ne zna se kako će to utjecati na mrežu.

Kako ne bi čekali da mrežni tehničari uspostave VLAN i da ne bi svaki servis morali definirati na svakom čvorištu mreže, ljudima je palo na pamet koristiti overlay mreže - preklopne mreže - kojih ima mnogo vrsta: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE itd.

Njihova privlačnost leži u dvije jednostavne stvari:

Konfiguriraju se samo krajnji čvori, transitne se ne dira. To značajno ubrzava proces, a ponekad čak dopušta isključivanje odjela mrežne infrastrukture iz procesa uvođenja novih servisa.
Opterećenje je skriveno duboko unutar zaglavlja - transitni čvorovi ne moraju znati ništa o tome, o adresiranju na hostovima, rutama preklopne mreže. To znači da je potrebno pohraniti manje informacija u tablicama, stoga se može koristiti jednostavniji/jeftiniji uređaj.

U ovoj ne potpuno potpunoj epizodi ne ću razlagati sve moguće tehnologije, već ću opisati okvir rada preklopnih mreža u DC-u.

Cijela serija opisuje podatkovni centar koji se sastoji od redova identičnih ormara, u kojima je instalirana jednaka poslužiteljska oprema.

Na toj opremi pokreću se virtualne mašine/kontejneri/serverless, koji implementiraju servise.

Terminologija

U ciklusu serverom nazvat ću program koji implementira poslužiteljsku stranu klijent-poslužiteljske komunikacije.

Fizičke mašine u ormarima nazvat ćemo poslužiteljima ne što ćemo i raditi.

Fizička mašina je x86 računar ugrađen u ormar. Najčešće korišten termin host. Tako ćemo je nazvati "mašina" ili host.

Hypervisor - aplikacija pokrenuta na fizičkoj mašini koja emulira fizičke resurse na kojima se pokreću virtualne mašine. Ponekad u literaturi i mreži riječ "hipervizor" koristi se kao sinonim za "host".

Virtuelna mašina - operativni sustav pokrenut na fizičkoj mašini iznad hipervizora. Za nas, u okviru ovog ciklusa, nije toliko važno je li to zapravo virtuelna mašina ili samo kontejner. Nazvat ćemo to "VM«

Tenant je širok pojam koji ću u ovom članku definirati kao zaseban servis ili zasebnog klijenta.

Multitenantnost ili multi-iznajmljivanje - korištenje iste aplikacije od strane različitih klijenata/usluga. Pri tome se izolacija klijenata jedna od druge postiže zahvaljujući arhitekturi aplikacije, a ne zasebnim pokrenutim instancama.

ToR - Top of the Rack switch — prekidač postavljen u okviru na koji su spojeni svi fizički uređaji.

Osim ToR topologije, različiti pružatelji prakticiraju End of Row (EoR) ili Middle of Row (iako je potonje sarkastično rijetko i akronim MoR nisam sreo).

Underlay network ili podložna mreža ili anderlaj — fizička mrežna infrastruktura: prekidači, usmjerivači, kabeli.

Overlay network ili preklapajuća mreža ili overlej — virtualna mreža tunela koja djeluje iznad fizičke.

L3-fabrika ili IP-fabrika — nevjerojatno izum čovječanstva koje omogućava da na sastancima ne ponavljamo STP i ne učimo TRILL. Koncept u kojem je cijela mreža do razine pristupa isključivo L3, bez VLAN-ova i, shodno tome, ogromnih rasprostranjenih broadcast domena. Otkud ovdje riječ «fabrika», razjasnit ćemo u sljedećem dijelu.

SDN — Software Defined Network. Teško da treba predstavljanje. Pristup upravljanju mrežom u kojem se promjene u mreži ne obavljaju od strane čovjeka, već od strane programa. Obično znači premještanje Control Plane izvan krajnjih mrežnih uređaja na kontroler.

NFV — Network Function Virtualization — virtualizacija mrežnih uređaja, predviđajući da se dio funkcija mreže može pokretati u obliku virtualnih strojeva ili kontejnera radi brže implementacije novih usluga, organizacije Service Chaining i jednostavnijeg horizontalnog skaliranja.

VNF — Virtual Network Function. Konkretni virtualni uređaj: usmjerivač, prekidač, vatrozid, NAT, IPS/IDS itd.

Namjerno sada pojednostavljujem opis do konkretne implementacije da ne bih zbunio čitatelja. Za dublje čitanje uputit ću ga na odjeljak Linkovi. Osim toga, Roma Gorge, koji kritizira ovaj članak zbog netočnosti, obećava napisati poseban broj o tehnologijama virtualizacije servera i mreža, detaljniji i pažljiviji.

Većinu mreža danas možemo jasno podijeliti na dva dijela:

Underlay — fizička mreža sa stabilnom konfiguracijom.
Overlay — apstrakcija iznad Underlay za izolaciju zakupaca.

To vrijedi i za slučaj DC (koji ćemo razraditi u ovom članku), kao i za ISP (koji nećemo razrađivati, jer je već bilo u SDCM). Sa enterprise mrežama, naravno, situacija je donekle drugačija.

Slika s fokusom na mrežu:

Underlay

Underlay je fizička mreža: hardverski prekidači i kablovi. Uređaji u underlayu znaju kako doći do fizičkih mašina.

Oslanja se na standardne protokole i tehnologije. Ne u poslednjem redu zbog toga što hardverski uređaji i dalje rade na vlasničkom softveru, što ne omogućava programiranje čipa ni implementaciju svojih protokola, a samim tim je potrebna kompatibilnost s drugim dobavljačima i standardizacija.

Ali neko poput Googlea može priuštiti razvijanje vlastitih prekidača i odustajanje od uobičajenih protokola. No, LAN_DC nije Google.

Underlay se relativno retko menja, jer mu je zadatak osnovna IP povezanost između fizičkih mašina. Underlay ništa ne zna o uslugama, klijentima i tenantima koji se nalaze iznad njega — samo treba dostaviti paket s jedne mašine na drugu.
Underlay bi mogao biti, na primer, ovakav:

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

Underlay mreža se konfiguriše na klasičan način: CLI/GUI/NETCONF.

Ručnim putem, skriptama, vlasničkim alatima.

Detaljnije o underlayu će biti rečeno u sledećem članku ciklusa.

Overlay

Overlay je virtuelna mreža tunela, rastegnuta preko Underlay-a, koja omogućava VMs jednog klijenta da komuniciraju jedni s drugima, dok osigurava izolaciju od drugih klijenata.

Podaci klijenta se inkapsuliraju u tunelirajuće zaglavlja za prenos kroz zajedničku mrežu.

Tako VMs jednog klijenta (jedne usluge) mogu međusobno komunicirati putem Overlay-a, čak i ne sumnjajući koji stvarni put paket prolazi.

Overlay bi mogao biti, kao što sam već napomenuo ranije:

GRE-tunel
VXLAN
EVPN
L3VPN
GENEVE

Overlay mreža se obično konfiguriše i održava preko centralnog kontrolera. S njega se konfiguracija, Control Plane i Data Plane dostavljaju na uređaje koji se bave usmeravanjem i inkapsulacijom klijentskog saobraćaja. Malo donjem ćemo to analizirati na primerima.

Da, ovo je SDN u čistom obliku.

Postoje dva suštinski različita pristupa organizaciji Overlay mreže:

Overlay s ToR-a
Overlay s hosta

Overlay s ToR-a

Overlay može početi na pristupnom prekidaču (ToR) koji se nalazi u okviru, kao što je slučaj, na primer, u VXLAN fabrici.

To je vremenski provereni mehanizam na ISP mrežama i svi dobavljači mrežne opreme ga podržavaju.

Međutim, u ovom slučaju, ToR prekidač mora biti sposoban da razdvaja različite usluge, prema tome, mrežni administrator mora u određenoj meri sarađivati sa administratorima virtuelnih mašina i unositi izmene (čak i automatski) u konfiguraciju uređaja.

Ovde bih čitaoca uputio na članak o VxLAN na Habr-u našeg starog prijatelja @bormoglotx.
U ovoj prezentaciji sa ENOG-a detaljno su opisani pristupi izgradnji DC mreže sa EVPN VXLAN fabrikom.

A za potpunije uranjanje u stvarnost, može se pročitati ciskina knjiga A Modern, Open, and Scalable Fabric: VXLAN EVPN.

Primetiću da je VXLAN samo metoda enkapsulacije i da terminacija tunela može da se odvija ne na ToR-u, već na hostu, kao što je to slučaj sa OpenStack-om, na primer.
Međutim, VXLAN fabrika gde se overlay započinje na ToR-u jedan je od ustaljenih dizajna ovelayer mreže.

Overlay s hosta

Drugi pristup je započeti i terminirati tunele na krajnjim hostovima.
U tom slučaju, mreža (Underlay) ostaje maksimalno jednostavna i statična.
A host sam obavlja sve potrebne enkapsulacije.

Za to će, naravno, biti potrebno pokrenuti posebnu aplikaciju na hostovima, ali to se isplati.

Prvo, pokrenuti klijent na linux mašini je lakše ili, da kažemo, - uopšte moguće - dok će na prekidaču verovatno morati da se oslanjate na vlasnička SDN rešenja, što ubija ideju multi-vendor kompatibilnosti.

Drugo, ToR prekidač u ovom slučaju može ostati maksimalno jednostavan, kako s aspekta Control Plane-a, tako i Data Plane-a. Zaista, sa SDN kontrolerom mu tada nije potrebno da komunicira, i ne mora da čuva mreže/ARP-ove svih povezanih klijenata - dovoljno je znati IP adresu fizičke mašine, što značajno olakšava tabele preklapanja/ruting.

U seriji ADSM biram pristup overlay-a s hosta - dalje ćemo govoriti samo o njemu i vraćati se na VXLAN fabriku više nećemo.

Najlakše je razmotriti na primerima. I kao eksperiment uzeće OpenSource SDN platformu OpenContrail, za sada poznatu kao Tungsten Fabric.

Na kraju članka ću izneti neka razmišljanja na temu analogije sa OpenFlow i OpenvSwitch.

Na primjeru Tungsten Fabric

Na svakoj fizičkoj mašini postoji vRouter — virtualni usmjerivač koji je svjestan mreža povezanih na njega i kojem klijentima pripadaju — u suštini — PE-usmjerivač. Za svakog klijenta podržava izolirani tablicu usmjeravanja (čitaj VRF). A sam vRouter obavlja Overlay tuneliranje.

Malo detaljnije o vRouter-u — na kraju članka.

Svaka VM koja se nalazi na hipervizoru povezana je s vRouter-om te mašine preko TAP sučelja.

TAP — Terminal Access Point — virtualno sučelje u Linux jezgru koje omogućava mrežnu interakciju.

Ako se iza vRouter-a nalaze više mreža, za svaku od njih se stvara virtualno sučelje kojem se dodjeljuje IP adresa — ona će biti adresa zadnjeg domaćina.
Sve mreže jednog klijenta smještaju se u jedan VRF (jednu tablicu), različite — u različite.
Ovdje ću napraviti opasku da nije sve tako jednostavno i uputiti znatiželjnog čitatelja na kraj članka..

Da bi vRouter-i mogli komunicirati jedni s drugima, a samim tim i VMs koje se nalaze iza njih, razmjenjuju informacije o rutama preko SDN kontrolera.

Da bi se izašlo u vanjski svijet, postoji izlazna točka iz matrice — ulazna točka virtualne mreže VNGW — Virtual Network GateWay (moj termin).

Sada ćemo razmotriti primjere komunikacija — i bit će jasno.

Komunikacija unutar jedne fizičke mašine

VM0 želi poslati paket na VM2. Pretpostavimo za sada da su to VMs jednog klijenta.

Data Plane

VM-0 ima zadnju putanju na svom sučelju eth0. Paket se šalje prema njemu.
To sučelje eth0 zapravo je virtualno povezano s virtualnim usmjerivačem vRouter preko TAP sučelja tap0.
vRouter analizira na koje sučelje paket dolazi, odnosno kojem klijentu (VRF) pripada, provjerava adresu primatelja s tablicom usmjeravanja tog klijenta.
Otkrivši da se primatelj nalazi na istoj mašini, ali na drugom portu, vRouter jednostavno šalje paket u njega bez dodatnih zaglavlja — u tom slučaju vRouter već ima ARP unos.

Paket u ovom slučaju ne ulazi u fizičku mrežu — usmjerio se unutar vRouter-a.

Control Plane

Hipervizor pri pokretanju virtualne mašine javlja joj:

Njezinu vlastitu IP adresu.
Zadnja putanja — kroz IP adresu vRouter-a u toj mreži.

vRouter-u preko posebnog API-ja hipervizor javlja:

Što treba stvoriti virtualno sučelje.
Koju Virtualne Mreže (VN) treba stvoriti.
Na koji VRF ga (VN) povezati.
Statička ARP zapis za ovu VM — za kojim sučeljem se nalazi njezina IP adresa i kojem MAC adresi je povezana.

Ponovno, stvarni postupak interakcije pojednostavljen je u svrhu razumijevanja koncepta.

Na taj način sve VM-ove jednog klijenta na ovoj mašini vRouter vidi kao neposjećene povezane mreže i može samostalno rutirati između njih.

VM0 i VM1 pripadaju različitim klijentima, stoga se nalaze u različitim tablicama vRoutera.

Hoće li moći izravno komunicirati ovisi o postavkama vRoutera i dizajnu mreže.
Na primjer, ako VM-ovi obaju klijenata koriste javne adrese, ili NAT se događa na samom vRouteru, tada se može izvršiti i izravna ruta na vRouter.

U suprotnom postoji mogućnost prekoračenje adresnog prostora — potrebno je kroz NAT poslužitelj za dobivanje javne adrese — to nalikuje izlasku na vanjske mreže, o kojima će biti riječi u nastavku.

Komunikacija između VMs smještenih na različitim fizičkim mašinama

Data Plane

Početak je u potpunosti isti: VM-0 šalje paket s odredištem VM-7 (172.17.3.2) prema svom defaultu.
vRouter ga prima i ovaj put vidi da je odredište na drugoj mašini i dostupno je preko tunela Tunnel0.
Najprije dodaje MPLS oznaku, koja identificira udaljeno sučelje, kako bi vRouter na drugoj strani mogao odrediti kamo smjestiti taj paket bez dodatnih zaobilaznica.
Za Tunnel0 izvor je 10.0.0.2, a odredište: 10.0.1.2.
vRouter dodaje GRE (ili UDP) zaglavlja i novu IP adresu izvornom paketu.
U tablici ruta vRoutera postoji zadnja ruta kroz adresu ToR1 10.0.0.1. Tamo i šalje.
ToR1 kao sudionik Underlay mreže zna (primjerice, putem OSPF-a) kako doći do 10.0.1.2 i šalje paket putem rute. Imajte na umu da se ovdje uključuje ECMP. Na ilustraciji su dva next hopa, a različiti tokovi će se rasporediti u njih na temelju hashiranja. U slučaju stvarne fabrike, ovdje će vjerojatno biti 4 next hopa.
Prilikom toga ne mora znati što se nalazi ispod vanjskog IP zaglavlja. To jest, zapravo ispod IP-a može biti sendvič od IPv6 over MPLS over Ethernet over MPLS over GRE over over over Grčkog.
Prema tome, na prihvaćajućoj strani vRouter uklanja GRE i pomoću MPLS oznake shvaća kojem sučelju treba proslijediti ovaj paket, razdvaja ga i šalje u prvotnom obliku primatelju.

Control Plane

Prilikom pokretanja mašine događa se sve ono što je opisano iznad.

I osim toga, slijedeće:

Za svakog klijenta vRouter dodjeljuje MPLS oznaku. To je servisna oznaka L3VPN prema kojoj će se klijenti razdvajati unutar jedne fizičke mašine.
Zapravo, MPLS oznaka se vRouter-om dodjeljuje uvijek bezuvjetno — jer nije unaprijed poznato hoće li mašina komunicirati samo s drugim mašinama iza istog vRouter-a, a to vjerojatno i nije slučaj.
vRouter uspostavlja vezu sa SDN kontrolerom putem BGP protokola (ili sličnog — u slučaju TF to je XMPP 0_o).
Kroz ovu sesiju vRouter obavještava SDN kontroler o rutama do priključenih mreža:
- Adresa mreže
- Metoda enkapsulacije (MPLSoGRE, MPLSoUDP, VXLAN)
- MPLS oznaku klijenta
- Svoj IP adresu kao nexthop
SDN kontroler prima takve rute od svih priključenih vRouter-a i reflektira ih drugima. Drugim riječima, on djeluje kao Route Reflector.

Isto se događa i u obrnutom smjeru.

Overlay se može mijenjati čak svake minute. Otprilike tako to funkcionira u javnim oblacima, kada klijenti redovito pokreću i isključuju svoje virtualne mašine.

Središnji kontroler preuzima sve složenosti održavanja konfiguracije i kontrole tablica prebacivanja/rutiranja na vRouter-u.

Ako govorimo grubim jezikom, kontroler se povezuje sa svim vRouter-ima putem BGP (ili sličnog protokola) i jednostavno prenosi informacije o rutama. BGP, na primjer, već ima Address-Family za prenos metode enkapsulacije. MPLS-in-GRE ili MPLS-in-UDP.

Pri tome se nikako ne mijenja konfiguracija Underlay mreže, koju je usput, automatski na redove teže upravljati, a slomiti nepažljivim pokretom lakše.

Izlaz u vanjski svijet

Negdje simulacija mora prestati, i iz virtualnog svijeta treba izaći u stvarni. I potreban je taksifon gateway.

Primjenjuju se dva pristupa:

Postavlja se hardverski usmjerivač.
Pokreće se neki appliance koji implementira funkcije usmjerivača (da, da, nakon SDN-a susreli smo se i s VNF-om). Nazovimo ga virtualni gateway.

Prednost drugog pristupa leži u jeftinoj horizontalnoj skalabilnosti — nedostaje snage — pokrenuli smo još jednu virtualku sa gateway-em. Na svakoj fizičkoj mašini, bez potrebe za potragom za slobodnim ormarićima, jedinicama, napajanjem, kupovinom samo hardvera, transportom, instalacijom, povezivanjem, konfiguriranjem, a nakon toga još i zamjenom neispravnih komponenata.
Nedostaci virtualnog gatewaya su u tome što je fizički usmjerivač daleko moćniji od višekernog virtualnog servera, a njegov softver, prilagođen njegovoj hardverskoj osnovi, radi znatno stabilnije (ne). Teško je poreći i taj faktor da softversko-hardware rješenje jednostavno funkcionira, zahtijevajući samo podešavanje, dok je pokretanje i održavanje virtualnog gatewaya posao za iskusne inženjere.

Jednom nogom gateway gleda u virtualnu mrežu Overlay, kao obična Virtualna Mašina, i može komunicirati sa svim ostalim VM-ovima. U isto vrijeme, on može terminirati mreže svih klijenata i, samim tim, vršiti usmjeravanje između njih.

Drugom nogom gateway gleda u glavnu mrežu i zna kako se povezati s Internetom.

Data Plane

Dakle, proces izgleda ovako:

VM-0, s zadanim vRouterom, šalje paket s odredištem u vanjskom svijetu (185.147.83.177) na sučelje eth0.
vRouter prima ovaj paket i vrši lookup odredišne adrese u tablici usmjeravanja - pronalazi zadani put kroz gateway VNGW1 putem Tunnela 1.
Također vidi da je to GRE tunel s SIP 10.0.0.2 i DIP 10.0.255.2, a također treba prvo dodati MPLS oznaku ovog klijenta, koju očekuje VNGW1.
vRouter pakira izvorni paket u MPLS, GRE i novi IP zaglavlja i šalje ga na adresu ToR1 10.0.0.1 prema zadanim postavkama.
Podmreža dostavlja paket do gatewaya VNGW1.
Gateway VNGW1 uklanja tunelske zaglavlja GRE i MPLS, vidi odredišnu adresu, konzultira se sa svojom tablicom usmjeravanja i shvaća da je odredište Internet - dakle, putem Full View ili Default. Ako je potrebno, vrši NAT prevođenje.
Od VNGW do granice može postojati obična IP mreža, što je malo vjerojatno.
Može biti klasična MPLS mreža (IGP+LDP/Rsvp TE), može biti obrnuta fabrika s BGP LU ili GRE tunel od VNGW do granice putem IP mreže.
Bilo kako bilo, VNGW1 provodi potrebne inkapsulacije i šalje izvorni paket prema granici.

Protok u suprotnom smjeru prolazi iste korake u obrnutom redoslijedu.

Granica dostavlja paket do VNGW1.
On ga razdvaja, gleda na adresu primatelja i vidi da je dostupan putem tunela Tunnel1 (MPLSoGRE ili MPLSoUDP).
Shodno tome, dodaje MPLS oznaku, GRE/UDP zaglavlje i novi IP te šalje na svoj ToR3 10.0.255.1.
Odredišna adresa tunela je IP adresa vRoutera iza kojeg se nalazi ciljana VM — 10.0.0.2.
Podmreža isporučuje paket do potrebnog vRoutera.
Ciljani vRouter uklanja GRE/UDP, određuje sučelje prema MPLS oznaci i šalje čisti IP paket u svoj TAP interfejs, vezan za eth0 VM.

Control Plane

VNGW1 uspostavlja BGP susjedstvo s SDN kontrolerom, od kojeg dobiva sve informacije o rutama klijenata: koji klijent se nalazi iza kojeg IP adrese (vRoutera) i kojom MPLS oznakom se identificira.

Na sličan način, SDN kontroler obavještava o zadanoj ruti s oznakom tog klijenta, označavajući sebe kao nexthop. Zatim ta zadata ruta dolazi do vRoutera.

Na VNGW obično se događa agregacija ruta ili NAT prevođenje.

I u drugom smjeru, u sesiji s borderima ili Route Reflectorima, šalje upravo tu agregiranu rutu. Od njih prima zadanu rutu ili Full-View, ili nešto drugo.

Sa stanovišta enkapsulacije i razmjene prometa, VNGW se ne razlikuje od vRoutera.
Ako malo proširimo područje, VNGW i vRouterima možemo dodati i druga mrežna uređaja, poput vatrozida, farmi čišćenja ili obogaćivanja prometa, IPS i tako dalje.

A uz pomoć sekvencijalnog stvaranja VRF i ispravnog oglašavanja ruta, možete natjerati promet da kruži kako želite, što se naziva Service Chaining.

Dakle, i ovdje SDN kontroler djeluje kao Route Reflector između VNGW, vRoutera i drugih mrežnih uređaja.

No, zapravo, kontroler također prenosi informacije o ACL i PBR (Policy Based Routing), prisiljavajući pojedine tokove prometa da se ne kreću onako kako im ruta nalaže.

FAQ

Zašto stalno naglašavaš GRE/UDP?

Pa, zapravo, to se može smatrati specifičnim za Tungsten Fabric — može se uopće ne uzimati u obzir.

No, ako govorimo, tada je sam TF, dok je još bio OpenContrail, podržavao obje enkapsulacije: MPLS u GRE i MPLS u UDP.

UDP je dobar jer se u Source Port njegovog zaglavlja vrlo lako može kodirati hash funkcija od izvornih IP+Proto+Port, što omogućava balansiranje.

U slučaju GRE, nažalost, postoje samo vanjski IP i GRE zaglavlja koja su identična za sav enkapsulirani promet i ne govorimo o balansiranju — malo tko može tako duboko zaviriti unutar paketa.

Do nekog vremena, usmjerivači, čak i ako su mogli izgraditi dinamičke tunele, radili su to samo u MPLSoGRE, a tek nedavno su naučili raditi u MPLSoUDP. Stoga uvijek treba napomenuti mogućnost dva različita enkapsuliranja.

Za pravednost, treba napomenuti da TF podržava i L2 povezanost putem VXLAN-a.

Obećao si povući paralele s OpenFlow-om.
Zaista se same nameću. vSwitch u istom OpenStacku radi vrlo slične stvari, koristeći VXLAN, koji, usput, također ima UDP zaglavlje.

U Data Planeu rade otprilike istodobno, značajno se razlikujući u Control Planeu. Tungsten Fabric koristi XMPP za dostavu informacija o rutama vRouteru, dok OpenStack koristi OpenFlow.

Možeš li reći nešto više o vRouteru?
On se dijeli na dva dijela: vRouter Agent i vRouter Forwarder.

Prvi se pokreće u User Space host operativnog sustava i komunicira sa SDN kontrolerom, razmjenjujući informacije o rutama, VRF-ovima i ACL-ovima.

Drugi implementira Data Plane — obično u Kernel Spaceu, ali se može pokretati i na SmartNIC-ovima — mrežnim karticama s CPU-om i odvojenim programabilnim čipom za preklapanje, što omogućuje smanjenje opterećenja CPU-a host mašine, čineći mrežu bržom i predvidljivijom.

Moguće je i da je vRouter DPDK aplikacija u User Spaceu.

vRouter Agent prenosi postavke vRouter Forwarderu.

Što je Virtual Network?
Spomenuo sam na početku članka o VRF-u, da je svaki tenant povezan sa svojim VRF-om. Ako je za površinsko razumijevanje funkcioniranja overlay mreže to bilo dovoljno, sljedeća iteracija zahtijeva dodatna pojašnjenja.

Obično u mehanizmima virtualizacije, entitet Virtual Network (može se smatrati vlastitim imenom) unosi se odvojeno od klijenata/tenanta/virtuelnih mašina — to je potpuno samostalna stvar. Ova Virtual Network može se povezati u jedan tenant, drugi, dva, ili gdje god to želiš. Tako, na primjer, implementira se Service Chaining, kada je potrebno proći promet kroz određene čvorove u pravom redoslijedu, jednostavno stvarajući i povezujući Virtual Networke u pravilnom redu.

Stoga ne postoji izravna povezanost između Virtual Networka i tenanta.

Zaključak

Ovo je prilično površni opis rada virtualne mreže s overlayom s hosta i SDN kontrolerom. No, bez obzira koju platformu virtualizacije danas uzeli, radit će na sličan način, bilo da se radi o VMWareu, ACI-u, OpenStacku, CloudStacku, Tungsten Fabricu ili Juniper Contrailu. Razlikovat će se po vrstama enkapsulacije i zaglavlja, protokolima isporuke informacija na krajnje mrežne uređaje, ali princip softverski definiranih overlay mreža, koji djeluju iznad relativno jednostavne i statične underlay mreže, ostat će isti.
Može se reći da je u domeni stvaranja privatnog oblaka danas SDN temeljen na overlay mreži pobijedio. Ipak, to ne znači da OpenFlow nema mjesto u modernom svijetu — koristi se u OpenStacku i u istom VMWare NSX-u, koliko ja znam, Google ga koristi za konfiguraciju underlay mreže.

Ispod sam naveo linkove na detaljnije materijale ako želite dublje istražiti temu.

A što je s našom Underlay mrežom?

Uglavnom, ništa. Ona se tijekom cijelog vremena nije mijenjala. Sve što treba raditi u slučaju overlay-a s hosta je ažurirati rute i ARP-ove kako se vRouter/VNGW pojavljuju i nestaju te preusmjeravati pakete između njih.

Definirajmo listu zahtjeva za Underlay mrežu.

Biti sposoban za neki protokol usmjeravanja, u našem slučaju — BGP.
Imati široki propusnost, poželjno bez prekomjerne dodjele, kako bi se spriječilo gubljenje paketa uslijed zagušenja.
Podržavati ECMP — neizostavni dio fabrike.
Biti sposoban osigurati QoS, uključujući složene stvari poput ECN-a.
Podržavati NETCONF — priprema za budućnost.

Samoj funkciji Underlay mreže posvetio sam ovdje vrlo malo vremena. To je zato što ću se u nastavku serije usredotočiti upravo na nju, dok ćemo Overlay spominjati samo usput.

Očito, značajno ograničavam sve nas koristeći kao primjer mrežu podatkovnog centra izgrađenu na Cloze fabrici s čistim IP usmjeravanjem i overlayom s hosta.

Međutim, siguran sam da se svaka mreža s određenim dizajnom može opisati u formalnim terminima i automatizirati. Samo ovdje nastojim razjasniti pristupe automatizaciji, a ne zbuniti sve rješavajući problem u općem obliku.

U okviru ADSM-a, s Romanom Gorgom planiramo objaviti poseban broj o virtualizaciji računalnih resursa i njenoj interakciji s virtualizacijom mreže. Ostanite s nama.

Koristitne veze

Tungsten Fabric Arhitektura.
about:cloud. 6 sati o Yandex.Cloud, gdje se posebno raspravlja o virtualnoj mreži na TF.
Što je Open vSwitch?
Uvod u VxLAN.
RFC 7348. Virtual eXtensible Local Area Network (VXLAN): Okvir za overlay virtualiziranih slojeva 2 mreža preko slojeva 3 mreža.
Scaleway pristup VXLAN EVPN Fabric. Ovdje se raspravlja o cijeloj mreži DC-a, uključujući Underlay, Overlay, pristupe multi-homing-u i upravljanje.

Hvala

Romanu Gorgu — bivšem voditelju podcasta linkmeup, a sada stručnjaku za cloud platforme. Hvala za komentare i ispravke. Očekujemo u skoroj budućnosti njegov dublji članak o virtualizaciji.
Aleksandru Šalimovu — mom kolegi i stručnjaku za razvoj virtualnih mreža. Hvala za komentare i ispravke.
Valentinu Siničinu — mom kolegi i stručnjaku za Tungsten Fabric. Hvala za komentare i ispravke.
Artemu Černobaju — ilustratoru linkmeup. Hvala za KDPV.
Aleksandru Limonovu. Hvala za meme „automato”.

Izvor: habr.com