В prethodni broj Opisao sam okvir mrežne automatizacije. Prema nekim ljudima, i ovaj prvi pristup problemu je već riješio neka pitanja. I to me veoma raduje, jer naš cilj u ciklusu nije da prikrijemo Ansible sa Python skriptama, već da izgradimo sistem.

Isti okvir postavlja redosled kojim ćemo se baviti pitanjem.
A mrežna virtuelizacija, kojoj je ovo izdanje posvećeno, ne uklapa se posebno u ADSM temu, gde analiziramo automatizaciju.

Ali pogledajmo to iz drugog ugla.

Mnogi servisi već duže vrijeme koriste istu mrežu. U slučaju telekom operatera, to su 2G, 3G, LTE, širokopojasni i B2B, na primjer. U slučaju DC-a: povezivanje za različite klijente, Internet, blok memorija, skladištenje objekata.

A sve usluge zahtijevaju izolaciju jedna od druge. Ovako su se pojavile preklapajuće mreže.

I sve usluge ne žele da čekaju da ih osoba ručno konfiguriše. Tako su se pojavili orkestratori i SDN.

Prvi pristup sistematskoj automatizaciji mreže, odnosno njenog dijela, odavno je uzet i implementiran na mnogim mjestima: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

To je ono čime ćemo se danas baviti.

Sadržaj

• razloga
• Terminologija
• Podloga - fizička mreža
• Overlay - virtuelna mreža
  • Preklapanje sa ToR
  • Overlay od hosta
  • Korištenje volframove tkanine kao primjera
    • Komunikacija unutar jedne fizičke mašine
    • Komunikacija između VM-ova koji se nalaze na različitim fizičkim mašinama
    • Izlaz u vanjski svijet

• FAQ
• zaključak
• korisni linkovi

razloga

A pošto govorimo o ovome, vrijedi spomenuti preduvjete za virtuelizaciju mreže. Zapravo, ovaj proces nije počeo juče.

Vjerovatno ste više puta čuli da je mreža uvijek bila najinertniji dio svakog sistema. I to je tačno u svakom smislu. Mreža je osnova na kojoj sve počiva, a mijenjanje na njoj je prilično teško - servisi to ne tolerišu kada mreža ne radi. Često, prestanak rada jednog čvora može ukloniti veliki dio aplikacija i utjecati na mnoge kupce. To je dijelom razlog zašto se mrežni tim može oduprijeti svakoj promjeni - jer sada nekako funkcionira (možda ne znamo ni kako), ali ovdje trebate konfigurirati nešto novo, a nepoznato je kako će to utjecati na mrežu.

Kako ne bi čekali da mrežari ubace VLAN-ove i da ne registruju servise na svakom mrežnom čvoru, ljudi su došli na ideju da koriste preklapanja - overlay mreže - kojih ima mnogo: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, itd.

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

• Konfigurirani su samo krajnji čvorovi — tranzitni čvorovi se ne moraju dirati. To značajno ubrzava proces, a ponekad vam omogućava da u potpunosti isključite odjel mrežne infrastrukture iz procesa uvođenja novih usluga.
• Opterećenje je skriveno duboko unutar zaglavlja - tranzitni čvorovi ne moraju znati ništa o tome, o adresiranju na hostovima ili o rutama mreže preklapanja. To znači da trebate pohraniti manje informacija u tabele, što znači korištenje jednostavnijeg/jeftinijeg uređaja.

U ovom ne sasvim potpunom izdanju, ne planiram analizirati sve moguće tehnologije, već opisati okvir za rad preklapajućih mreža u DC-ovima.

Cijela serija će opisati data centar koji se sastoji od nizova identičnih rekova u kojima je instalirana ista serverska oprema.

Ova oprema pokreće virtuelne mašine/kontejnere/bez servera koji implementiraju usluge.

Terminologija

U petlji server Nazvat ću program koji implementira serversku stranu komunikacije klijent-server.

Fizičke mašine u stalcima nazivaju se serveri ne Mi ćemo.

Fizička mašina — x86 računar instaliran u stalak. Najčešći termin host. Tako ćemo to zvati"машина"ili host.

hipervizor - aplikacija koja radi na fizičkoj mašini koja emulira fizičke resurse na kojima virtuelne mašine rade. Ponekad se u literaturi i na internetu riječ “hipervizor” koristi kao sinonim za “host”.

Virtuelna mašina - operativni sistem koji radi na fizičkoj mašini na vrhu hipervizora. Za nas u ovom ciklusu nije bitno da li je to zapravo virtuelna mašina ili samo kontejner. nazovimo to "VM«

Stanar je širok koncept koji ću u ovom članku definirati kao zasebnu uslugu ili zasebnog klijenta.

Multi-tenancy ili multitenancy - korištenje iste aplikacije od strane različitih klijenata/usluga. Istovremeno, izolacija klijenata jednih od drugih postiže se zahvaljujući arhitekturi aplikacije, a ne kroz odvojeno pokrenute instance.

ToR — Prekidač na vrhu stalka - prekidač instaliran u stalak na koji su spojene sve fizičke mašine.

Pored ToR topologije, različiti provajderi praktikuju kraj reda (EoR) ili sredinu reda (iako je ovo drugo omalovažavajuća rijetkost i nisam vidio MoR skraćenicu).

Podložna mreža ili osnovna mreža ili podloga je fizička mrežna infrastruktura: prekidači, ruteri, kablovi.

Overlay mreža ili overlay network ili overlay - virtuelna mreža tunela koja se izvodi na vrhu fizičke.

L3 tkanina ili IP tkanina - nevjerovatan izum čovječanstva koji vam omogućava da izbjegnete ponavljanje STP-a i učenje TRILL-a za intervjue. Koncept u kojem je cijela mreža do nivoa pristupa isključivo L3, bez VLAN-a i, shodno tome, ogromnih proširenih broadcast domena. U narednom dijelu ćemo pogledati odakle dolazi riječ "fabrika".

SDN - Softverski definirana mreža. Jedva da treba uvod. Pristup upravljanju mrežom gdje promjene na mreži ne vrši osoba, već program. Obično znači premještanje kontrolne ravni izvan krajnjih mrežnih uređaja do kontrolera.

NFV — Virtuelizacija mrežnih funkcija — virtuelizacija mrežnih uređaja, što sugeriše da se neke mrežne funkcije mogu pokrenuti u obliku virtuelnih mašina ili kontejnera kako bi se ubrzala implementacija novih usluga, organizovali lančani servisi i jednostavnija horizontalna skalabilnost.

VNF - Funkcija virtuelne mreže. Određeni virtuelni uređaj: ruter, prekidač, firewall, NAT, IPS/IDS, itd.

Sada namjerno pojednostavljujem opis na konkretnu implementaciju, kako ne bih previše zbunio čitaoca. Za pažljivije čitanje, upućujem ga na odjeljak reference. Osim toga, Roma Gorge, koji kritikuje ovaj članak zbog netačnosti, obećava da će napisati zasebno izdanje o tehnologijama virtuelizacije servera i mreže, detaljnije i sa pažnjom prema detaljima.

Većina današnjih mreža može se jasno podijeliti na dva dijela:

Podloga — fizička mreža sa stabilnom konfiguracijom.
Overlay — apstrakcija preko podloge za izolaciju stanara.

Ovo važi i za slučaj DC (koji ćemo analizirati u ovom članku) i za ISP (koji nećemo analizirati, jer je već bio SDSM). Sa poslovnim mrežama, naravno, situacija je nešto drugačija.

Slika sa fokusom na mrežu:

Podloga

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

Oslanja se na standardne protokole i tehnologije. Ne samo zato što hardverski uređaji do danas rade na vlasničkom softveru koji ne dozvoljava ni programiranje čipa ni implementaciju vlastitih protokola; shodno tome, potrebna je kompatibilnost s drugim proizvođačima i standardizacija.

Ali neko poput Googlea može sebi priuštiti razvoj vlastitih prekidača i napuštanje općeprihvaćenih protokola. Ali LAN_DC nije Google.

Podloga se mijenja relativno rijetko jer je njen posao osnovno IP povezivanje između fizičkih mašina. Underlay ne zna ništa o uslugama, klijentima ili stanarima koji rade na njemu - samo treba da isporuči paket sa jedne mašine na drugu.
Podloga bi mogla biti ovakva:

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

Underlay mreža je konfigurisana na klasičan način: CLI/GUI/NETCONF.

Ručno, skripte, vlasnički uslužni programi.

Sljedeći članak u nizu bit će detaljnije posvećen podlozi.

Overlay

Overlay je virtuelna mreža tunela koja se proteže iznad Underlay-a, omogućava VM-ovima jednog klijenta da međusobno komuniciraju, istovremeno obezbeđujući izolaciju od drugih klijenata.

Podaci o klijentu su inkapsulirani u nekim zaglavljima tunela za prijenos preko javne mreže.

Dakle, VM jednog klijenta (jedne usluge) mogu međusobno komunicirati preko Overlay-a, a da čak i ne znaju kojom putanjom paket zapravo ide.

Preklapanje može biti, na primjer, kao što sam spomenuo gore:

• GRE tunel
• VXLAN
• EVPN
• L3VPN
• ŽENEVA

Preklapajuća mreža se obično konfiguriše i održava preko centralnog kontrolera. Iz njega se konfiguracija, kontrolna ravan i ravan podataka isporučuju uređajima koji rutiraju i inkapsuliraju klijentski promet. Malo dole Pogledajmo ovo na primjerima.

Da, ovo je SDN u svom najčistijem obliku.

Postoje dva fundamentalno različita pristupa organizaciji Overlay mreže:

1. Preklapanje sa ToR
2. Overlay od hosta

Preklapanje sa ToR

Overlay može početi od pristupnog prekidača (ToR) koji stoji u stalku, kao što se dešava, na primjer, u slučaju VXLAN tkanine.

Ovo je vremenski testiran 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 u mogućnosti da odvoji različite usluge, odnosno, i mrežni administrator mora u određenoj mjeri sarađivati ​​sa administratorima virtuelnih mašina i vršiti promene (iako automatski) u konfiguraciji uređaja. .

Ovdje ću uputiti čitatelja na članak o VxLAN na Habréu naš stari prijatelj @bormoglotx.
U ovom prezentacije sa ENOG-om detaljno su opisani pristupi izgradnji DC mreže sa EVPN VXLAN tkaninom.

A za potpunije uranjanje u stvarnost, možete pročitati Tsiskinu knjigu Moderna, otvorena i skalabilna tkanina: VXLAN EVPN.

Napominjem da je VXLAN samo metoda enkapsulacije i završetak tunela se može dogoditi ne na ToR-u, već na hostu, kao što se događa u slučaju OpenStack-a, na primjer.

Međutim, VXLAN tkanina, gdje preklapanje počinje na ToR, jedan je od uspostavljenih dizajna mreže preklapanja.

Overlay od hosta

Drugi pristup je pokretanje i završetak tunela na krajnjim hostovima.
U ovom slučaju, mreža (Underlay) ostaje što je moguće jednostavnija i statična.
I sam domaćin radi svu potrebnu enkapsulaciju.

Ovo će naravno zahtijevati pokretanje posebne aplikacije na hostovima, ali isplati se.

Prvo, pokretanje klijenta na Linux mašini je lakše ili, recimo, čak i moguće, dok ćete na prekidaču najvjerovatnije morati da se okrenete vlasničkim SDN rješenjima, što ubija ideju multi-vendora.

Drugo, prekidač ToR u ovom slučaju može se ostaviti što jednostavnijim, i sa stanovišta kontrolne ravni i nivoa podataka. Zaista, tada ne treba komunicirati sa SDN kontrolerom, a također ne treba pohranjivati ​​mreže/ARP-ove svih povezanih klijenata – dovoljno je znati IP adresu fizičke mašine, što uvelike pojednostavljuje prebacivanje/ tablice rutiranja.

U ADSM seriji biram pristup preklapanju sa hosta - tada samo razgovaramo o tome i nećemo se vraćati u VXLAN fabriku.

Najlakše je pogledati primjere. A kao ispitanik ćemo uzeti OpenSource SDN platformu OpenContrail, sada poznatu kao Tungsten Fabric.

Na kraju članka ću dati neka razmišljanja o analogiji sa OpenFlow i OpenvSwitch.

Korištenje volframove tkanine kao primjera

Svaka fizička mašina ima vRouter - virtuelni ruter koji zna za mreže povezane na njega i kojim klijentima pripadaju - u suštini PE ruter. Za svakog klijenta održava izolovanu tabelu rutiranja (čitaj VRF). A vRouter zapravo radi Overlay tuneliranje.

Nešto više o vRouteru je na kraju članka.

Svaki VM koji se nalazi na hipervizoru je povezan sa vRouterom ove mašine preko TAP interfejs.

TAP - Terminal Access Point - virtuelni interfejs u jezgru Linuxa koji omogućava mrežnu interakciju.

Ako iza vRoutera postoji nekoliko mreža, tada se za svaku od njih kreira virtuelni interfejs, kojem se dodeljuje IP adresa - to će biti podrazumevana adresa mrežnog prolaza.
Sve mreže jednog klijenta su smeštene u jednu VRF (jedan sto), različite - u različite.
Ovdje ću se odreći da nije sve tako jednostavno, a radoznalog čitatelja poslat ću do kraja članka.

Kako bi vRouteri mogli međusobno komunicirati, a shodno tome i VM-ovi koji se nalaze iza njih, razmjenjuju informacije o rutiranju putem SDN kontroler.

Da biste izašli u vanjski svijet, postoji izlazna tačka iz matrice - virtuelni mrežni gateway VNGW — Virtual Network GateWay (moj mandat).

Pogledajmo sada primjere komunikacije - i bit će jasno.

Komunikacija unutar jedne fizičke mašine

VM0 želi poslati paket VM2. Pretpostavimo za sada da je ovo VM jednog klijenta.

data plane

1. VM-0 ima zadanu rutu do svog eth0 interfejsa. Paket se šalje tamo.
   Ovaj interfejs eth0 je zapravo povezan virtuelno na virtuelni ruter vRouter preko TAP interfejsa tap0.
2. vRouter analizira na koje sučelje je paket došao, odnosno kojem klijentu (VRF) pripada i provjerava adresu primatelja s tablicom rutiranja ovog klijenta.
3. Nakon što je otkrio da je primalac na istoj mašini na drugom portu, vRouter jednostavno šalje paket na njega bez ikakvih dodatnih zaglavlja - u ovom slučaju, vRouter već ima ARP unos.

U ovom slučaju, paket ne ulazi u fizičku mrežu - usmjerava se unutar vRoutera.

Kontrolni plan

Kada se virtuelna mašina pokrene, hipervizor joj kaže:

• Njena vlastita IP adresa.
• Zadana ruta je preko IP adrese vRoutera na ovoj mreži.

Hipervizor izvještava vRouter preko posebnog API-ja:

• Šta vam je potrebno za kreiranje virtuelnog interfejsa.
• Kakvu virtuelnu mrežu (VM) treba da kreira?
• Za koji VRF (VN) ga vezati.
• Statički ARP unos za ovaj VM—na kom interfejsu se nalazi njegova IP adresa i za koju MAC adresu je vezan.

Opet, stvarna procedura interakcije je pojednostavljena radi razumijevanja koncepta.

Dakle, vRouter vidi sve VM-ove jednog klijenta na datom stroju kao direktno povezane mreže i može sam usmjeravati između njih.

Ali VM0 i VM1 pripadaju različitim klijentima i, shodno tome, nalaze se u različitim vRouter tabelama.

Da li mogu međusobno komunicirati direktno ovisi o postavkama vRoutera i dizajnu mreže.
Na primjer, ako VM oba klijenta koriste javne adrese ili se NAT javlja na samom vRouteru, tada se može izvršiti direktno usmjeravanje na vRouter.

U suprotnoj situaciji, moguće je ukrštati adresne prostore - potrebno je proći kroz NAT server da biste dobili javnu adresu - ovo je slično pristupu vanjskim mrežama, o kojima se govori u nastavku.

Komunikacija između VM-ova koji se nalaze na različitim fizičkim mašinama

data plane

1. Početak je potpuno isti: VM-0 šalje paket sa odredištem VM-7 (172.17.3.2) po defaultu.
2. vRouter ga prima i ovaj put vidi da je odredište na drugoj mašini i da je dostupno kroz Tunnel0.
3. Prvo, visi MPLS oznaku koja identifikuje udaljeni interfejs, tako da na poleđini vRouter može da odredi gde da postavi ovaj paket bez dodatnih pregleda.

   

4. Tunnel0 ima izvor 10.0.0.2, odredište: 10.0.1.2.
   vRouter dodaje GRE (ili UDP) zaglavlja i novu IP adresu originalnom paketu.
5. VRouter tabela usmjeravanja ima zadanu rutu kroz ToR1 adresu 10.0.0.1. Tamo ga šalje.

   
   

6. ToR1, kao član Underlay mreže, zna (na primjer, preko OSPF-a) kako doći do 10.0.1.2 i šalje paket duž rute. Imajte na umu da je ECMP ovdje omogućen. Na ilustraciji postoje dva nexthop-a, a različite niti će biti razvrstane u njih po hash-u. U slučaju prave fabrike, vjerovatnije će biti 4 nexthopsa.

   Istovremeno, on ne mora da zna šta se nalazi ispod eksternog IP zaglavlja. To jest, u stvari, pod IP-om može postojati sendvič IPv6 preko MPLS-a preko Etherneta preko MPLS-a preko GRE-a preko preko grčkog.

7. Shodno tome, na strani koja prima, vRouter uklanja GRE i, koristeći MPLS tag, razumije na koji interfejs treba poslati ovaj paket, uklanja ga i šalje u originalnom obliku primaocu.

Kontrolni plan

Kada upalite auto, dešava se ista stvar kao što je gore opisano.

I plus sljedeće:

• Za svakog klijenta, vRouter dodjeljuje MPLS oznaku. Ovo je oznaka usluge L3VPN, pomoću koje će klijenti biti razdvojeni unutar iste fizičke mašine.
  

  Zapravo, MPLS oznaku uvijek bezuslovno dodjeljuje vRouter – na kraju krajeva, nije unaprijed poznato da će mašina komunicirati samo sa drugim mašinama iza istog vRoutera, a to najvjerovatnije nije ni istina.

• vRouter uspostavlja vezu sa SDN kontrolerom koristeći BGP protokol (ili sličan njemu - u slučaju TF, ovo je XMPP 0_o).
• Kroz ovu sesiju, vRouter prijavljuje rute do povezanih mreža SDN kontroleru:
  • Mrežna adresa
  • Metoda enkapsulacije (MPLSoGRE, MPLSoUDP, VXLAN)
  • MPLS oznaka klijenta
  • Vaša IP adresa kao nexthop

• SDN kontroler prima takve rute od svih povezanih vRoutera i prikazuje ih drugima. To jest, djeluje kao reflektor rute.

Ista stvar se dešava u suprotnom smjeru.

Preklapanje se može promijeniti barem svake minute. To se otprilike događa u javnim oblacima, gdje klijenti redovno pokreću i gase svoje virtuelne mašine.

Centralni kontroler se brine za svu složenost održavanja konfiguracije i nadgledanja tabela prebacivanja/usmjeravanja na vRouteru.

Grubo govoreći, kontroler komunicira sa svim vRouterima preko BGP-a (ili sličnog protokola) i jednostavno prenosi informacije o rutiranju. BGP, na primjer, već ima Address-Family za prenošenje metode enkapsulacije MPLS-in-GRE ili MPLS-u-UDP.

U isto vrijeme, konfiguracija Underlay mreže se ni na koji način ne mijenja, koju je, inače, mnogo teže automatizirati, a lakše razbiti neugodnim pokretom.

Izlaz u vanjski svijet

Negdje simulacija mora završiti, a vi morate izaći iz virtuelnog svijeta u stvarni. I potreban vam je prolaz za govornicu.

Prakticiraju se dva pristupa:

1. Hardverski ruter je instaliran.
2. Pokrenut je uređaj koji implementira funkcije rutera (da, nakon SDN-a, naišli smo i na VNF). Nazovimo ga virtuelnim prolazom.

Prednost drugog pristupa je jeftina horizontalna skalabilnost - nema dovoljno energije - pokrenuli smo još jednu virtuelnu mašinu sa gateway-om. Na bilo kojoj fizičkoj mašini, bez potrebe da tražite slobodne police, jedinice, izlaznu snagu, kupite sam hardver, transportujte ga, instalirajte ga, prebacite ga, konfigurišite, a zatim i promenite neispravne komponente u njemu.

Nedostaci virtuelnog gateway-a su u tome što je jedinica fizičkog rutera i dalje za redove magnitude moćnija od virtuelne mašine sa više jezgara, a njen softver, prilagođen sopstvenoj hardverskoj bazi, radi mnogo stabilnije (ne). Također je teško poreći činjenicu da hardverski i softverski kompleks jednostavno funkcionira, zahtijeva samo konfiguraciju, dok je pokretanje i održavanje virtuelnog gateway-a zadatak jakih inženjera.

Jednom nogom, gateway gleda u Overlay virtuelnu mrežu, kao obična virtuelna mašina, i može da komunicira sa svim drugim VM-ovima. Istovremeno, može prekinuti mreže svih klijenata i, shodno tome, izvršiti rutiranje između njih.

Sa drugom nogom, gateway gleda u okosnu mrežu i zna kako doći na Internet.

data plane

Odnosno, proces izgleda ovako:

1. VM-0, pošto je podrazumevano postavio isti vRouter, šalje paket sa odredištem u spoljnom svetu (185.147.83.177) na eth0 interfejs.
2. vRouter prima ovaj paket i traži adresu odredišta u tabeli rutiranja - pronalazi podrazumevanu rutu kroz VNGW1 gateway kroz tunel 1.
   On također vidi da se radi o GRE tunelu sa SIP 10.0.0.2 i DIP 10.0.255.2, a također mora prvo priložiti MPLS oznaku ovog klijenta, što VNGW1 očekuje.
3. vRouter pakuje početni paket sa MPLS, GRE i novim IP zaglavljima i po defaultu ga šalje u ToR1 10.0.0.1.
4. Osnovna mreža isporučuje paket na gateway VNGW1.
5. VNGW1 gateway uklanja GRE i MPLS tunelska zaglavlja, vidi odredišnu adresu, konsultuje svoju tabelu rutiranja i razume da je usmeren na Internet - to jest, preko Full View ili Default. Ako je potrebno, vrši NAT prijevod.
6. Mogla bi postojati redovna IP mreža od VNGW do granice, što je malo vjerovatno.
   Može postojati klasična MPLS mreža (IGP+LDP/RSVP TE), može postojati back fabric sa BGP LU ili GRE tunel od VNGW do granice preko IP mreže.
   Kako god bilo, VNGW1 izvodi potrebne enkapsulacije i šalje početni paket prema granici.

Saobraćaj u suprotnom smjeru prolazi kroz iste korake suprotnim redoslijedom.

1. Granica ispušta paket na VNGW1
2. Svlači ga, gleda u adresu primaoca i vidi da je dostupan kroz tunel Tunnel1 (MPLSoGRE ili MPLSoUDP).
3. U skladu s tim, pričvršćuje MPLS oznaku, GRE/UDP zaglavlje i novi IP i šalje ga svom ToR3 10.0.255.1.
   Adresa odredišta tunela je IP adresa vRoutera iza kojeg se nalazi ciljna VM - 10.0.0.2.
4. Osnovna mreža isporučuje paket na željeni vRouter.
5. Ciljni vRouter čita GRE/UDP, identifikuje interfejs koristeći MPLS oznaku i šalje goli IP paket svom TAP interfejsu povezanom sa eth0 VM-a.

Kontrolni plan

VNGW1 uspostavlja BGP susjedstvo sa SDN kontrolerom, od kojeg prima sve informacije o rutiranju o klijentima: koja IP adresa (vRouter) se nalazi iza kojeg klijenta i po kojoj MPLS oznaci je identificiran.

Slično, on sam obavještava SDN kontroler o zadanoj ruti s oznakom ovog klijenta, označavajući sebe kao nexthop. A onda ova zadana vrijednost stiže na vRouters.

Na VNGW-u se obično javlja agregacija ruta ili NAT translacija.

A u drugom smjeru, šalje upravo ovu agregiranu rutu u sesiju s granicama ili reflektorima rute. I od njih prima zadanu rutu ili Full-View, ili nešto drugo.

U pogledu enkapsulacije i razmene saobraćaja, VNGW se ne razlikuje od vRoutera.
Ako malo proširite opseg, tada možete dodati druge mrežne uređaje VNGW-ovima i vRouterima, kao što su firewall, farme za čišćenje ili obogaćivanje prometa, IPS itd.

A uz pomoć sekvencijalnog kreiranja VRF-ova i ispravne najave ruta, možete natjerati promet da se vrti onako kako želite, što se zove Service Chaining.

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

Ali u stvari, kontroler također propušta informacije o ACL-u i PBR-u (usmjeravanje zasnovano na politici), uzrokujući da se pojedinačni prometni tokovi odvijaju drugačije nego što im ruta kaže.

FAQ

Zašto uvijek dajete primjedbu GRE/UDP?

Pa, općenito se može reći da je ovo specifično za Tungsten Fabric - ne morate to uopće uzeti u obzir.

Ali ako uzmemo to, onda je sam TF, dok je još uvijek OpenContrail, podržavao obje enkapsulacije: MPLS u GRE i MPLS u UDP.

UDP je dobar jer je u izvornom portu vrlo lako kodirati hash funkciju iz originalnog IP+Proto+Port u njegovom zaglavlju, što će vam omogućiti da izvršite balansiranje.

U slučaju GRE, nažalost, postoje samo eksterna IP i GRE zaglavlja, koja su ista za sav inkapsulirani promet i nema govora o balansiranju - malo ljudi može pogledati tako duboko u paket.

Do nekog vremena ruteri su, ako su mogli da koriste dinamičke tunele, to radili samo u MPLSoGRE, a tek nedavno su naučili da koriste MPLSoUDP. Stoga, uvijek moramo imati na umu mogućnost dvije različite inkapsulacije.

Iskreno rečeno, vrijedno je napomenuti da TF u potpunosti podržava L2 povezivanje pomoću VXLAN-a.

Obećali ste da ćete povući paralele sa OpenFlow-om.
Oni to zaista traže. vSwitch u istom OpenStack-u radi vrlo slične stvari, koristeći VXLAN, koji, inače, također ima UDP zaglavlje.

U podatkovnoj ravni oni rade približno isto; kontrolna ravan se značajno razlikuje. Tungsten Fabric koristi XMPP za isporuku informacija o rutiranju vRouteru, dok OpenStack pokreće Openflow.

Možete li mi reći nešto više o vRouteru?
Podijeljen je na dva dijela: vRouter Agent i vRouter Forwarder.

Prvi radi u korisničkom prostoru host OS-a i komunicira sa SDN kontrolerom, razmjenjujući informacije o rutama, VRF-ovima i ACL-ovima.

Drugi implementira Data Plane - obično u Kernel Space-u, ali može raditi i na SmartNIC-ima - mrežnim karticama sa CPU-om i zasebnim programabilnim komutacijskim čipom, koji vam omogućava da uklonite opterećenje sa CPU-a glavnog računala i učinite mrežu bržom i više predvidljivo.

Drugi mogući scenario je da je vRouter DPDK aplikacija u korisničkom prostoru.

vRouter Agent šalje postavke vRouter Forwarderu.

Šta je virtuelna mreža?
Spomenuo sam na početku članka o VRF-u da je svaki stanar vezan za svoj VRF. A ako je to bilo dovoljno za površno razumijevanje rada mreže preklapanja, onda je u sljedećoj iteraciji potrebno napraviti pojašnjenja.

Tipično, u mehanizmima virtuelizacije, entitet virtuelne mreže (možete ovo smatrati vlastitom imenicom) se uvodi odvojeno od klijenata/zakupaca/virtuelnih mašina - potpuno nezavisna stvar. A ova virtuelna mreža se već može povezati preko interfejsa na jednog stanara, na drugog, na dva ili bilo gde. Tako se, na primjer, Service Chaining implementira kada promet treba proći kroz određene čvorove u traženom nizu, jednostavnim kreiranjem i povezivanjem virtualnih mreža u ispravnom redoslijedu.

Stoga, kao takva, ne postoji direktna korespondencija između virtuelne mreže i zakupca.

zaključak

Ovo je vrlo površan opis rada virtuelne mreže sa preklapanjem od hosta i SDN kontrolera. Ali bez obzira koju platformu za virtuelizaciju danas odaberete, ona će raditi na sličan način, bilo da se radi o VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric ili Juniper Contrail. Oni će se razlikovati po tipovima enkapsulacija i zaglavlja, protokolima za isporuku informacija krajnjim mrežnim uređajima, ali princip softverski konfigurabilne mreže sa preklapanjem koja radi na relativno jednostavnoj i statičkoj podlozi ostat će isti.
Možemo reći da je danas SDN baziran na overlay mreži osvojio polje kreiranja privatnog oblaka. Međutim, to ne znači da Openflowu nije mjesto u modernom svijetu - koristi se u OpenStackeu iu istom VMWare NSX-u, koliko znam, Google ga koristi za postavljanje podzemne mreže.

U nastavku sam dao veze do detaljnijih materijala ako želite dublje proučiti problem.

A šta je sa našom podlogom?

Ali generalno, ništa. Nije se promenio do kraja. Sve što treba da uradi u slučaju preklapanja sa hosta je da ažurira rute i ARP-ove kako se vRouter/VNGW pojavljuju i nestaju i prenose pakete između njih.

Hajde da formulišemo listu zahteva za Underlay mrežu.

1. Moći koristiti neku vrstu protokola za rutiranje, u našoj situaciji - BGP.
2. Imati širok propusni opseg, po mogućnosti bez prekomjerne pretplate, tako da se paketi ne izgube zbog preopterećenja.
3. Podrška ECMP je sastavni dio tkanine.
4. Biti u mogućnosti pružiti QoS, uključujući lukave stvari kao što je ECN.
5. Podrška NETCONF-u je temelj za budućnost.

Ovdje sam posvetio vrlo malo vremena radu same Underlay mreže. To je zato što ću se kasnije u seriji fokusirati na to, a mi ćemo se samo usputno dotaknuti Overlay-a.

Očigledno, sve nas ozbiljno ograničavam koristeći kao primjer DC mrežu izgrađenu u Cloz fabrici sa čistim IP rutiranjem i preklapanjem sa hosta.

Međutim, uvjeren sam da se svaka mreža koja ima dizajn može opisati formalno i automatizirati. Samo što je moj cilj ovdje da razumijem pristupe automatizaciji, a ne da zbunim sve rješavanjem problema u općem obliku.

U sklopu ADSM-a, Roman Gorge i ja planiramo da objavimo zasebno izdanje o virtuelizaciji računarske snage i njenoj interakciji sa virtuelizacijom mreže. Ostati u kontaktu.

korisni linkovi

• Arhitektura volframove tkanine.
• about:cloud. 6 sati o Yandex.Cloudu, koji također pokriva virtuelnu mrežu na TF.
• Šta je Open vSwitch?
• Uvod u VxLAN.
• RFC 7348. Virtuelna proširiva lokalna mreža (VXLAN): Okvir za preklapanje virtuelizovanih mreža sloja 2 preko mreža sloja 3.
  
• Scaleway pristup VXLAN EVPN Fabric. Govori o cijeloj DC mreži, uključujući Underlay, Overlay, pristupe multi-homingu i upravljanju.

Hvala ti

• Roman Gorga - bivši voditelj linkmeup podcasta, a sada stručnjak za oblast cloud platformi. Za komentare i izmjene. Pa, čekamo njegov opširniji članak o virtualizaciji u bliskoj budućnosti.
• Alexander Shalimov - moj kolega i stručnjak u oblasti razvoja virtuelnih mreža. Za komentare i izmjene.
• Valentin Sinitsyn - moj kolega i stručnjak za oblast Tungsten Fabric. Za komentare i izmjene.
• Artyom Chernobay — linkmeup za ilustrator. Za KDPV.
• Aleksandar Limonov. Za "automatski" meme.

izvor: www.habr.com