В prethodni broj Opisao sam okvir za automatizaciju mreže. Prema nekim ljudima, već je ovaj prvi pristup problemu riješio neka pitanja. I to me jako veseli, jer naš cilj u ciklusu nije prekriti Ansible s Python skriptama, već izgraditi sustav.

Isti okvir postavlja redoslijed kojim ćemo se baviti pitanjem.
A virtualizacija mreže, kojoj je posvećen ovaj broj, ne uklapa se posebno u ADSM temu, gdje analiziramo automatizaciju.

No, pogledajmo to iz drugog kuta.

Mnoge usluge već dugo koriste istu mrežu. U slučaju telekom operatera, to je na primjer 2G, 3G, LTE, širokopojasni pristup i B2B. U slučaju DC-a: povezanost za različite klijente, Internet, blok pohrana, pohrana objekata.

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

I sve usluge ne žele čekati da ih osoba ručno konfigurira. Tako su se pojavili orkestratori i SDN.

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

Time ćemo se danas baviti.

sadržaj

• Uzroci
• terminologija
• Podloga - fizička mreža
• Overlay - virtualna mreža
  • Prekrivanje s ToR
  • Prekrivanje s hosta
  • Na primjeru tkanine od volframa
    • Komunikacija unutar jednog fizičkog stroja
    • Komunikacija između VM-ova koji se nalaze na različitim fizičkim strojevima
    • Izlaz u vanjski svijet

• FAQ
• Zaključak
• korisni linkovi

Uzroci

A kad već govorimo o ovome, vrijedi spomenuti preduvjete za virtualizaciju mreže. Zapravo, ovaj proces nije počeo jučer.

Vjerojatno ste više puta čuli da je mreža uvijek bila najinertniji dio svakog sustava. I to je istina u svakom smislu. Mreža je temelj na kojem sve počiva, a promjene na njoj su prilično teške - servisi ne toleriraju kada mreža ne radi. Često prestanak rada jednog čvora može srušiti velik dio aplikacija i utjecati na mnoge korisnike. To je djelomično razlog zašto se mrežni tim može opirati svakoj promjeni - jer sada nekako funkcionira (možda ni ne znamo kako), ali ovdje morate konfigurirati nešto novo, a nepoznato je kako će to utjecati na mrežu.

Kako ne bi čekali da umrežari umetnu VLAN-ove i ne bi registrirali nikakve usluge na svakom mrežnom čvoru, ljudi su došli na ideju korištenja overlay-a - overlay mreža - 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—tranzitne čvorove ne treba dirati. To značajno ubrzava proces, a ponekad vam omogućuje da potpuno 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 njemu, o adresiranju na hostovima ili o rutama prekrivene mreže. To znači da trebate pohraniti manje informacija u tablice, što znači koristiti jednostavniji/jeftiniji uređaj.

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

Cijela serija opisat će podatkovni centar koji se sastoji od nizova identičnih regala u kojima je instalirana ista poslužiteljska oprema.

Ova oprema pokreće virtualne strojeve/kontejnere/bez poslužitelja koji implementiraju usluge.

terminologija

U petlji poslužitelja Imenovat ću program koji implementira poslužiteljsku stranu komunikacije klijent-poslužitelj.

Fizički strojevi u policama nazivaju se poslužitelji ne hoćemo.

Fizički stroj — x86 računalo instalirano u stalak. Najčešće korišten termin domaćin. Tako ćemo to nazvati"uređaj„ili domaćin.

Hipervizor - aplikacija koja se izvodi na fizičkom računalu koja emulira fizičke resurse na kojima se pokreću virtualni strojevi. Ponekad se u literaturi i na internetu riječ “hipervizor” koristi kao sinonim za “host”.

Virtualni stroj - operativni sustav koji radi na fizičkom stroju na vrhu hipervizora. Za nas u ovom ciklusu nije bitno radi li se zapravo o virtualnom stroju ili samo o spremniku. nazovimo to "VM«

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

Višestanarstvo ili multitency - korištenje iste aplikacije od strane različitih klijenata/usluga. Istodobno, izolacija klijenata jednih od drugih postiže se zahvaljujući arhitekturi aplikacije, a ne kroz zasebno pokrenute instance.

ToR — prekidač na vrhu stalka - sklopka ugrađena u rack na koju su spojeni svi fizički strojevi.

Uz topologiju ToR-a, razni pružatelji prakticiraju End of Row (EoR) ili Sredinu retka (iako je potonje rijetkost koja omalovažava i nisam vidio kraticu MoR).

Podložna mreža ili temeljna mreža ili podloga je fizička mrežna infrastruktura: sklopke, usmjerivači, kabeli.

Prekrivajuća mreža ili overlay network ili overlay - virtualna mreža tunela koja se proteže povrh one fizičke.

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

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 ravnine izvan krajnjih mrežnih uređaja do kontrolera.

NFV — Virtualizacija mrežnih funkcija — virtualizacija mrežnih uređaja, sugerirajući da se neke mrežne funkcije mogu izvoditi u obliku virtualnih strojeva ili spremnika kako bi se ubrzala implementacija novih usluga, organiziralo ulančavanje usluga i jednostavnija horizontalna skalabilnost.

VNF - Funkcija virtualne mreže. Određeni virtualni uređaj: router, switch, firewall, NAT, IPS/IDS itd.

Sada namjerno pojednostavljujem opis na konkretnu implementaciju, kako ne bih previše zbunio čitatelja. Za pažljivije čitanje, upućujem ga na odjeljak reference. Osim toga, Roma Gorge, koji kritizira ovaj članak zbog netočnosti, obećava da će napisati zasebno izdanje o tehnologijama virtualizacije poslužitelja i mreže, dublje i pažljivije prema detaljima.

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

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

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

Slika s fokusom na mrežu:

podmetnuti

Podloga je fizička mreža: hardverski prekidači i kabeli. Uređaji u podzemlju znaju kako doći do fizičkih strojeva.

Oslanja se na standardne protokole i tehnologije. Ne samo zato što hardverski uređaji do danas rade na vlasničkom softveru koji ne dopušta niti programiranje čipa niti implementaciju vlastitih protokola, stoga je potrebna kompatibilnost s drugim dobavljačima i standardizacija.

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

Underlay se mijenja relativno rijetko jer je njegov posao osnovna IP povezanost između fizičkih strojeva. Underlay ne zna ništa o uslugama, klijentima ili stanarima koji rade na njemu - samo treba isporučiti paket s jednog stroja na drugi.
Podloga bi mogla biti ovakva:

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

Underlay mreža se konfigurira 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.

Prekriti

Overlay je virtualna mreža tunela protegnutih na vrhu Underlay-a, omogućuje VM-ovima jednog klijenta da međusobno komuniciraju, istovremeno osiguravajući izolaciju od drugih klijenata.

Podaci klijenta su kapsulirani u nekim zaglavljima tuneliranja za prijenos preko javne mreže.

Dakle, VM-ovi jednog klijenta (jedne usluge) mogu međusobno komunicirati putem Overlaya, a da uopće ne znaju kojom putanjom paket zapravo ide.

Prekrivanje bi moglo biti, na primjer, kao što sam gore spomenuo:

• GRE tunel
• VXLAN
• EVPN
• L3VPN
• Geneve

Mreža preklapanja obično se konfigurira i održava putem središnjeg kontrolera. Iz njega se konfiguracija, kontrolna ravnina i podatkovna ravnina dostavljaju uređajima koji usmjeravaju i enkapsuliraju klijentski promet. Malo ispod Pogledajmo ovo na primjerima.

Da, ovo je SDN u svom najčišćem obliku.

Postoje dva bitno različita pristupa organiziranju Overlay mreže:

1. Prekrivanje s ToR
2. Prekrivanje s hosta

Prekrivanje s ToR

Prekrivanje može započeti na pristupnom prekidaču (ToR) koji stoji u stalku, kao što se događa, na primjer, u slučaju VXLAN tkanine.

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

Međutim, u ovom slučaju, ToR prekidač mora moći odvojiti različite usluge, a mrežni administrator mora u određenoj mjeri surađivati ​​s administratorima virtualnog stroja i mijenjati (iako automatski) konfiguraciju uređaja. .

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

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

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

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

Prekrivanje s hosta

Drugi pristup je pokretanje i završetak tunela na krajnjim hostovima.
U tom slučaju mreža (podloga) ostaje što je moguće jednostavnija i statična.
A host sam radi svu potrebnu enkapsulaciju.

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

Prvo, pokretanje klijenta na Linux stroju je lakše ili, recimo, čak i moguće, dok ćete se na switchu najvjerojatnije morati okrenuti vlasničkim SDN rješenjima, što ubija ideju multi-vendora.

Drugo, ToR prekidač u ovom slučaju može biti što je moguće jednostavniji, i sa stajališta kontrolne ravni i podatkovne ravnine. Doista, 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čkog stroja, što uvelike pojednostavljuje prebacivanje/ tablice usmjeravanja.

U seriji ADSM odabirem pristup preklapanja od glavnog računala - tada samo razgovaramo o tome i nećemo se vraćati na VXLAN tvornicu.

Najlakše je pogledati primjere. A kao predmet testiranja uzet ćemo OpenSource SDN platformu OpenContrail, sada poznatu kao Tkanina od volframa.

Na kraju članka dat ću neke misli o analogiji s OpenFlow i OpenvSwitch.

Na primjeru tkanine od volframa

Svaki fizički stroj ima vRouter - virtualni usmjerivač koji zna koje su mreže spojene na njega i kojim klijentima pripadaju - u biti PE usmjerivač. Za svakog klijenta održava izoliranu tablicu usmjeravanja (čitaj VRF). A vRouter zapravo radi Overlay tuneliranje.

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

Svaki VM koji se nalazi na hipervizoru povezan je s vRouterom ovog stroja putem TAP sučelje.

TAP - Terminal Access Point - virtualno sučelje u Linux kernelu koje omogućuje mrežnu interakciju.

Ako iza vRoutera postoji nekoliko mreža, tada se za svaku od njih stvara virtualno sučelje kojemu se dodjeljuje IP adresa - to će biti zadana adresa pristupnika.
Sve mreže jednog klijenta smještene su u jednu VRF (jedan stol), različiti - u različite.
Ovdje ću reći da nije sve tako jednostavno, a znatiželjnog čitatelja poslati na kraj članka.

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

Za izlazak u vanjski svijet postoji izlazna točka iz matrice - virtualni mrežni pristupnik VNGW - Virtualni mrežni pristupnik (moj termin).

Sada pogledajmo primjere komunikacije - i bit će jasnoće.

Komunikacija unutar jednog fizičkog stroja

VM0 želi poslati paket VM2. Pretpostavimo za sada da je ovo VM s jednim klijentom.

podatkovna ravnina

1. VM-0 ima zadanu rutu do svog eth0 sučelja. Paket se šalje tamo.
   Ovo sučelje eth0 zapravo je virtualno povezano s virtualnim usmjerivačem vRouter preko TAP sučelja tap0.
2. vRouter analizira na koje sučelje je paket došao, odnosno kojem klijentu (VRF) pripada te provjerava adresu primatelja s tablicom usmjeravanja tog klijenta.
3. Nakon što je otkrio da je primatelj na istom računalu na drugom portu, vRouter mu jednostavno šalje paket bez ikakvih dodatnih zaglavlja - u ovom slučaju vRouter već ima ARP unos.

U tom slučaju paket ne ulazi u fizičku mrežu – usmjerava se unutar vRoutera.

Upravljačka ravnina

Kada se virtualni stroj pokrene, hipervizor mu govori:

• Njezina vlastita IP adresa.
• Zadana ruta je kroz IP adresu vRoutera na ovoj mreži.

Hipervizor izvještava vRouter putem posebnog API-ja:

• Što vam je potrebno za stvaranje virtualnog sučelja.
• Kakvu virtualnu mrežu (VM) treba stvoriti?
• Na koji VRF (VN) ga povezati.
• Statički ARP unos za ovaj VM - koje se sučelje nalazi iza njegove IP adrese i s kojom je MAC adresom povezano.

Opet, postupak stvarne interakcije je pojednostavljen radi razumijevanja koncepta.

Dakle, vRouter vidi sve VM-ove jednog klijenta na određenom računalu kao izravno povezane mreže i može sam usmjeravati između njih.

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

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

U suprotnoj situaciji, moguće je prelaziti adresne prostore - trebate proći kroz NAT poslužitelj da biste dobili javnu adresu - to 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 strojevima

podatkovna ravnina

1. Početak je potpuno isti: VM-0 šalje paket s odredištem VM-7 (172.17.3.2) prema zadanim postavkama.
2. vRouter ga prima i ovaj put vidi da je odredište na drugom računalu i da je dostupno kroz Tunnel0.
3. Prvo, stavlja MPLS oznaku koja identificira udaljeno sučelje, tako da na poleđini vRouter može odrediti gdje smjestiti ovaj paket bez dodatnih pretraživanja.

   

4. Tunel0 ima izvor 10.0.0.2, odredište: 10.0.1.2.
   vRouter dodaje GRE (ili UDP) zaglavlja i novi IP izvornom paketu.
5. Tablica usmjeravanja vRouter ima zadanu rutu kroz ToR1 adresu 10.0.0.1. Tamo ga šalje.

   
   

6. ToR1, kao član Underlay mreže, zna (na primjer, putem OSPF-a) kako doći do 10.0.1.2 i šalje paket duž rute. Imajte na umu da je ECMP ovdje omogućen. Postoje dva nexthopa na ilustraciji, a različite niti će biti razvrstane u njih prema hash-u. U slučaju prave tvornice vjerojatnije će biti 4 sljedeća koraka.

   U isto vrijeme, on ne mora znati što se nalazi ispod vanjskog IP zaglavlja. To jest, zapravo, pod IP-om može postojati sendvič IPv6 preko MPLS-a preko Etherneta preko MPLS-a preko GRE-a preko preko preko Greek-a.

7. Sukladno tome, na prijemnoj strani, vRouter uklanja GRE i pomoću MPLS oznake razumije na koje se sučelje ovaj paket treba poslati, uklanja ga i šalje u izvornom obliku primatelju.

Upravljačka ravnina

Kada pokrenete automobil, događa se ista stvar kao što je gore opisano.

I plus sljedeće:

• Za svakog klijenta vRouter dodjeljuje MPLS oznaku. Ovo je oznaka usluge L3VPN, po kojoj će klijenti biti odvojeni unutar istog fizičkog stroja.
  

  Zapravo, MPLS oznaku uvijek bezuvjetno dodjeljuje vRouter - na kraju krajeva, nije unaprijed poznato da će stroj komunicirati samo s drugim strojevima koji se nalaze iza istog vRoutera, a to najvjerojatnije nije ni točno.

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

• SDN kontroler prima takve rute od svih povezanih vRoutera i odražava ih drugima. Odnosno, djeluje kao reflektor rute.

Ista stvar se događa u suprotnom smjeru.

Prekrivanje se može mijenjati barem svake minute. To je otprilike ono što se događa u javnim oblacima, gdje klijenti redovito pokreću i gase svoje virtualne strojeve.

Središnji kontroler brine se za svu složenost održavanja konfiguracije i nadzora komutacijskih/usmjerivačkih tablica na vRouteru.

Ugrubo rečeno, kontroler komunicira sa svim vRouterima putem BGP-a (ili sličnog protokola) i jednostavno prenosi informacije o usmjeravanju. BGP, na primjer, već ima Address-Family za prenošenje metode enkapsulacije MPLS-in-GRE ili MPLS-in-UDP.

Pritom se ni na koji način ne mijenja konfiguracija Underlay mreže, koju je, usput rečeno, mnogo teže automatizirati, a lakše je razbiti nespretnim pokretom.

Izlaz u vanjski svijet

Negdje simulacija mora završiti, a vi trebate izaći iz virtualnog svijeta u stvarni. I treba vam govornica.

Prakticiraju se dva pristupa:

1. Instaliran je hardverski usmjerivač.
2. Pokrenut je uređaj koji implementira funkcije usmjerivača (da, nakon SDN-a, susreli smo i VNF). Nazovimo to virtualnim pristupnikom.

Prednost drugog pristupa je jeftina horizontalna skalabilnost - nema dovoljno snage - lansirali smo još jedan virtualni stroj s pristupnikom. Na bilo kojem fizičkom stroju, bez potrebe za traženjem besplatnih regala, jedinica, izlazne snage, kupite sam hardver, transportirajte ga, instalirajte, prebacite, konfigurirajte, a zatim i promijenite neispravne komponente u njemu.

Nedostaci virtualnog pristupnika su u tome što je jedinica fizičkog usmjerivača još uvijek moćnija od višejezgrenog virtualnog stroja, a njegov softver, prilagođen vlastitoj hardverskoj osnovi, radi mnogo stabilnije (ne). Također je teško poreći činjenicu da sklop hardvera i softvera jednostavno radi, zahtijevajući samo konfiguraciju, dok je pokretanje i održavanje virtualnog pristupnika zadatak jakih inženjera.

Jednom nogom pristupnik gleda u Overlay virtualnu mrežu, poput običnog Virtualnog stroja, i može komunicirati sa svim drugim VM-ovima. Istodobno, može terminirati mreže svih klijenata i, sukladno tome, izvršiti usmjeravanje između njih.

Drugom nogom gateway gleda u okosnicu mreže i zna kako doći na Internet.

podatkovna ravnina

Odnosno, proces izgleda ovako:

1. VM-0, nakon što je zadano postavio isti vRouter, šalje paket s odredištem u vanjskom svijetu (185.147.83.177) sučelju eth0.
2. vRouter prima ovaj paket i traži odredišnu adresu u tablici usmjeravanja - pronalazi zadanu rutu kroz VNGW1 gateway kroz Tunel 1.
   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 pakira početni paket s MPLS, GRE i novim IP zaglavljima i prema zadanim postavkama šalje ga ToR1 10.0.0.1.
4. Osnovna mreža isporučuje paket do pristupnika VNGW1.
5. VNGW1 pristupnik uklanja GRE i MPLS zaglavlja za tuneliranje, vidi odredišnu adresu, konzultira svoju tablicu usmjeravanja i razumije da je usmjeren na Internet - to jest, kroz Full View ili Default. Ako je potrebno, izvodi NAT prijevod.
6. Mogla bi postojati redovita IP mreža od VNGW do granice, što je malo vjerojatno.
   Može postojati klasična MPLS mreža (IGP+LDP/RSVP TE), može postojati back fabric s BGP LU ili GRE tunel od VNGW do granice preko IP mreže.
   Bilo kako bilo, VNGW1 izvodi potrebne enkapsulacije i šalje početni paket prema granici.

Promet u suprotnom smjeru prolazi kroz iste korake obrnutim redoslijedom.

1. Granica spušta paket na VNGW1
2. Svuče ga, pogleda adresu primatelja i vidi da je dostupan kroz tunel Tunnel1 (MPLSoGRE ili MPLSoUDP).
3. U skladu s tim, pridaje MPLS oznaku, GRE/UDP zaglavlje i novi IP i šalje ga svom ToR3 10.0.255.1.
   Odredišna adresa tunela je IP adresa vRoutera iza kojeg se nalazi ciljani VM - 10.0.0.2.
4. Osnovna mreža isporučuje paket željenom vRouteru.
5. Ciljni vRouter čita GRE/UDP, identificira sučelje pomoću MPLS oznake i šalje goli IP paket na svoje TAP sučelje povezano s eth0 VM-a.

Upravljačka ravnina

VNGW1 uspostavlja BGP susjedstvo sa SDN kontrolerom, od kojeg prima sve informacije o usmjeravanju o klijentima: koja IP adresa (vRouter) stoji iza kojeg klijenta i kojom MPLS oznakom je identificiran.

Slično tome, 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 obično dolazi do agregacije rute ili NAT prijevoda.

A u drugom smjeru, šalje točno ovu agregiranu rutu u sesiju s granicama ili reflektorima rute. I od njih prima zadanu rutu ili Full-View, ili nešto treće.

U smislu enkapsulacije i razmjene prometa, 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 vatrozidi, farme za čišćenje ili obogaćivanje prometa, IPS i tako dalje.

A uz pomoć sekvencijalnog stvaranja VRF-ova i ispravne najave ruta, možete natjerati promet da se vrti onako kako želite, što se zove ulančavanje usluga.

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

No zapravo, kontroler također objavljuje informacije o ACL-u i PBR-u (usmjeravanje temeljeno na pravilima), uzrokujući da se pojedinačni tokovi prometa odvijaju drugačije nego što im ruta kaže.

FAQ

Zašto uvijek dajete primjedbu GRE/UDP?

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

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

UDP je dobar jer je u izvornom priključku vrlo lako kodirati hash funkciju iz izvornog IP+Proto+Porta u njegovom zaglavlju, što će vam omogućiti balansiranje.

U slučaju GRE-a, nažalost, postoje samo vanjski IP i GRE zaglavlja, koji su isti za sav enkapsulirani promet i nema govora o balansiranju - malo tko može pogledati tako duboko u paket.

Do nekog vremena usmjerivači, ako su i znali koristiti dinamičke tunele, činili su to samo u MPLSoGRE, a tek su nedavno naučili koristiti MPLSoUDP. Stoga uvijek moramo imati na umu mogućnost dva različita enkapsuliranja.

Iskreno radi, vrijedi napomenuti da TF u potpunosti podržava L2 povezivanje pomoću VXLAN-a.

Obećali ste povući paralele s OpenFlowom.
Oni to stvarno traže. vSwitch u istom OpenStacku radi vrlo slične stvari, koristeći VXLAN, koji, usput, također ima UDP zaglavlje.

U Data Planeu rade približno isto, Control Plane se značajno razlikuje. Tungsten Fabric koristi XMPP za isporuku informacija o usmjeravanju vRouteru, dok OpenStack pokreće Openflow.

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

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

Drugi implementira Data Plane - obično u prostoru kernela, ali također može raditi na SmartNIC-u - mrežnim karticama s CPU-om i zasebnim programabilnim preklopnim čipom, koji vam omogućuje da uklonite opterećenje s CPU-a glavnog računala i učinite mrežu bržom i više predvidljiv.

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

vRouter Agent šalje postavke vRouter Forwarderu.

Što je virtualna 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 preklopne mreže, onda je u sljedećoj iteraciji potrebno napraviti pojašnjenja.

Tipično, u mehanizmima virtualizacije, entitet Virtualne mreže (ovo možete smatrati vlastitom imenicom) uvodi se odvojeno od klijenata/stanara/virtualnih strojeva - potpuno neovisna stvar. I ova virtualna mreža već se može povezati preko sučelja s jednim stanarom, s drugim, s dva ili bilo gdje. Tako se, na primjer, ulančavanje usluga implementira kada promet treba proći kroz određene čvorove u traženom slijedu, jednostavno stvaranjem i povezivanjem virtualnih mreža u ispravnom slijedu.

Stoga, kao takva, ne postoji izravna korespondencija između Virtualne mreže i stanara.

Zaključak

Ovo je vrlo površan opis rada virtualne mreže s preklapanjem glavnog računala i SDN kontrolera. No bez obzira koju platformu za virtualizaciju danas odaberete, ona će raditi na sličan način, bilo da se radi o VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric ili Juniper Contrail. Razlikovat će se u vrstama enkapsulacija i zaglavlja, protokolima za isporuku informacija krajnjim mrežnim uređajima, ali će princip softverski konfigurirane višeslojne mreže koja radi na relativno jednostavnoj i statičnoj podložnoj mreži ostati isti.
Možemo reći da je danas SDN temeljen na prekrivnoj mreži osvojio polje stvaranja privatnog oblaka. Međutim, to ne znači da Openflow nema mjesta u modernom svijetu - koristi se u OpenStackeu iu istom VMWare NSX, koliko ja znam, Google ga koristi za postavljanje podzemne mreže.

U nastavku sam dao poveznice na detaljnije materijale ako želite dublje proučiti problem.

A što je s našom podlogom?

Ali općenito, ništa. Nije se promijenio cijelim putem. Sve što treba učiniti u slučaju preklapanja s glavnog računala je ažurirati rute i ARP-ove kako se vRouter/VNGW pojavljuju i nestaju te prenose pakete između njih.

Formulirajmo popis zahtjeva za podložnu mrežu.

1. Moći koristiti neku vrstu protokola usmjeravanja, u našoj situaciji - BGP.
2. Imajte široku propusnost, po mogućnosti bez prekomjerne pretplate, tako da se paketi ne gube zbog preopterećenja.
3. Potporni ECMP sastavni je dio tkanine.
4. Budite u mogućnosti pružiti QoS, uključujući lukave stvari poput ECN-a.
5. Podrška NETCONF-u je temelj za budućnost.

Ovdje sam jako malo vremena posvetio radu same Underlay mreže. To je zato što ću se kasnije u seriji usredotočiti na to, a Overlay ćemo se samo usput dotaknuti.

Očito, sve nas ozbiljno ograničavam koristeći kao primjer DC mrežu izgrađenu u tvornici Cloz s čistim IP usmjeravanjem i preklapanjem s glavnog računala.

Međutim, uvjeren sam da se svaka mreža koja ima dizajn može opisati formalnim terminima i automatizirati. Samo je moj cilj ovdje razumjeti pristupe automatizaciji, a ne zbuniti sve rješavajući problem u općem obliku.

U sklopu ADSM-a, Roman Gorge i ja planiramo objaviti zasebno izdanje o virtualizaciji računalne snage i njezinoj interakciji s virtualizacijom mreže. Ostati u kontaktu.

korisni linkovi

• Arhitektura tkanine od volframa.
• o: oblaku. 6 sati o Yandex.Cloudu, koji također pokriva virtualnu mrežu na TF-u.
• Što je Open vSwitch?
• Uvod u VxLAN.
• RFC 7348. Virtualna proširiva lokalna mreža (VXLAN): okvir za preklapanje virtualiziranih mreža razine 2 preko mreža razine 3.
  
• Scaleway pristup VXLAN EVPN Fabricu. Govori o cijeloj DC mreži, uključujući Underlay, Overlay, pristupe multi-homingu i upravljanju.

Hvala vam

• Roman Gorga - bivša voditeljica podcasta linkmeup a sada stručnjak na području cloud platformi. Za komentare i izmjene. Pa, čekamo njegov opširniji članak o virtualizaciji u bliskoj budućnosti.
• Aleksandar Šalimov - moj kolega i stručnjak u području razvoja virtualnih mreža. Za komentare i izmjene.
• Valentin Sinitsyn - moj kolega i stručnjak na području Tungsten Fabric. Za komentare i izmjene.
• Artjom Černobaj — linkmeup ilustratora. Za KDPV.
• Aleksandar Limonov. Za "automatski" meme.

Izvor: www.habr.com