В Përshkrova kornizën e automatizimit të rrjetit. Sipas disa njerëzve, edhe kjo qasje e parë ndaj problemit ka zgjidhur tashmë disa pyetje. Dhe kjo më bën shumë të lumtur, sepse qëllimi ynë në ciklin nuk është të mbulojmë Ansible me skriptet Python, por të ndërtojmë një sistem.
E njëjta kornizë përcakton rendin në të cilin do të trajtojmë pyetjen.
Dhe virtualizimi i rrjetit, të cilit i kushtohet kjo çështje, nuk përshtatet veçanërisht në temën ADSM, ku analizojmë automatizimin.
Por le ta shohim nga një kënd tjetër.
Shumë shërbime kanë përdorur të njëjtin rrjet për një kohë të gjatë. Në rastin e një operatori telekomunikacioni, ky është për shembull 2G, 3G, LTE, brez i gjerë dhe B2B. Në rastin e një DC: lidhje për klientë të ndryshëm, internet, ruajtja e bllokut, ruajtja e objekteve.
Dhe të gjitha shërbimet kërkojnë izolim nga njëri-tjetri. Kështu u shfaqën rrjetet e mbivendosjes.
Dhe të gjitha shërbimet nuk duan të presin që një person t'i konfigurojë ato manualisht. Kështu u shfaqën orkestruesit dhe SDN.
Qasja e parë për automatizimin sistematik të rrjetit, ose më saktë një pjesë e tij, është marrë dhe zbatuar prej kohësh në shumë vende: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
Kjo është ajo me të cilën do të merremi sot.
Përmbajtje
- arsyet
- terminologji
- Nënshtresa - rrjet fizik
- Mbivendosje - rrjet virtual
- Mbivendosja me ToR
- Mbivendosja nga hosti
- Përdorimi i pëlhurës së tungstenit si shembull
- Komunikimi brenda një makinerie të vetme fizike
- Komunikimi ndërmjet VM-ve të vendosura në makina të ndryshme fizike
- Dalja në botën e jashtme
- FAQ
- Përfundim
- Lidhje të dobishme
arsyet
Dhe meqenëse po flasim për këtë, ia vlen të përmenden parakushtet për virtualizimin e rrjetit. Në fakt, ky proces nuk ka nisur dje.
Ju ndoshta keni dëgjuar më shumë se një herë se rrjeti ka qenë gjithmonë pjesa më inerte e çdo sistemi. Dhe kjo është e vërtetë në çdo kuptim. Rrjeti është baza mbi të cilën mbështetet gjithçka, dhe bërja e ndryshimeve në të është mjaft e vështirë - shërbimet nuk e tolerojnë atë kur rrjeti është në funksion. Shpesh, çmontimi i një nyje të vetme mund të heqë një pjesë të madhe të aplikacioneve dhe të ndikojë në shumë klientë. Kjo është pjesërisht arsyeja pse ekipi i rrjetit mund t'i rezistojë çdo ndryshimi - sepse tani funksionon disi (ne mund të mos dimë as se si), por këtu duhet të konfiguroni diçka të re dhe nuk dihet se si do të ndikojë në rrjet.
Për të mos pritur që rrjetet të fusin VLAN dhe të mos regjistrojnë asnjë shërbim në secilën nyje të rrjetit, njerëzit erdhën me idenë e përdorimit të mbivendosjeve - rrjetet e mbivendosjes - nga të cilat ka një larmi të madhe: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE, etj.
Apeli i tyre qëndron në dy gjëra të thjeshta:
- Vetëm nyjet fundore janë konfiguruar - nyjet e tranzitit nuk kanë nevojë të preken. Kjo shpejton ndjeshëm procesin dhe ndonjëherë ju lejon të përjashtoni plotësisht departamentin e infrastrukturës së rrjetit nga procesi i prezantimit të shërbimeve të reja.
- Ngarkesa është e fshehur thellë brenda kokave - nyjet e tranzitit nuk kanë nevojë të dinë asgjë për të, për adresimin në host ose për rrugët e rrjetit të mbivendosjes. Kjo do të thotë që ju duhet të ruani më pak informacion në tabela, që do të thotë të përdorni një pajisje më të thjeshtë/më të lirë.
Në këtë çështje jo plotësisht të plotë, unë nuk planifikoj të analizoj të gjitha teknologjitë e mundshme, por përkundrazi të përshkruaj kornizën për funksionimin e rrjeteve të mbivendosjes në DC.
E gjithë seria do të përshkruajë një qendër të dhënash të përbërë nga rreshta raftesh identike në të cilat është instaluar e njëjta pajisje serveri.
Kjo pajisje drejton makina virtuale / kontejnerë / pa server që zbatojnë shërbime.
terminologji
Në një lak server Unë do të emëroj një program që zbaton anën e serverit të komunikimit klient-server.
Makinat fizike në rafte quhen serverë jo ne do.
Makinë fizike — Kompjuteri x86 i instaluar në një raft. Termi më i përdorur mikpritës. Kështu do ta quajmë "makinë"ose mikpritës.
Hipervizor — një aplikacion që funksionon në një makinë fizike që imiton burimet fizike në të cilat funksionojnë Makinat Virtuale. Ndonjëherë në literaturë dhe internet fjala "hipervizor" përdoret si sinonim për "host".
Makine virtuale - një sistem operativ që funksionon në një makinë fizike në krye të një hipervizori. Për ne në këtë cikël, nuk ka shumë rëndësi nëse është në të vërtetë një makinë virtuale apo thjesht një kontejner. Le ta quajmë "VM«
Qiramarrësi është një koncept i gjerë që unë do ta përcaktoj në këtë artikull si një shërbim i veçantë ose një klient i veçantë.
Shumë-qiramarrje ose multitenancy - përdorimi i të njëjtit aplikacion nga klientë/shërbime të ndryshme. Në të njëjtën kohë, izolimi i klientëve nga njëri-tjetri arrihet falë arkitekturës së aplikacionit, dhe jo përmes instancave që funksionojnë veçmas.
ToR - Pjesa e sipërme e çelësit Rack - një ndërprerës i instaluar në një raft në të cilin janë lidhur të gjitha makinat fizike.
Përveç topologjisë ToR, ofrues të ndryshëm praktikojnë End of Row (EoR) ose Middle of Row (edhe pse kjo e fundit është një gjë e rrallë përçmuese dhe unë nuk e kam parë shkurtimin MoR).
Rrjeti i nënshtresës ose rrjeti themelor ose nënshtresa është infrastruktura fizike e rrjetit: çelsat, ruterat, kabllot.
Rrjeti i mbivendosjes ose rrjeti i mbivendosjes ose mbivendosja - një rrjet virtual tunelesh që funksionojnë në krye të atij fizik.
Pëlhurë L3 ose pëlhurë IP - një shpikje e mahnitshme e njerëzimit që ju lejon të shmangni përsëritjen e STP dhe të mësoni TRILL për intervista. Një koncept në të cilin i gjithë rrjeti deri në nivelin e aksesit është ekskluzivisht L3, pa VLAN dhe, në përputhje me rrethanat, domene të mëdha të zgjeruara të transmetimit. Ne do të kuptojmë se nga vjen fjala "fabrikë" në pjesën tjetër.
Sdn - Rrjeti i përcaktuar me softuer. Vështirë se ka nevojë për një prezantim. Një qasje për menaxhimin e rrjetit ku ndryshimet në rrjet nuk bëhen nga një person, por nga një program. Zakonisht nënkupton lëvizjen e Planit të Kontrollit përtej pajisjeve fundore të rrjetit te kontrolluesi.
NFV — Virtualizimi i funksionit të rrjetit — virtualizimi i pajisjeve të rrjetit, duke sugjeruar që disa funksione të rrjetit mund të ekzekutohen në formën e makinave virtuale ose kontejnerëve për të përshpejtuar zbatimin e shërbimeve të reja, organizimin e zinxhirit të shërbimeve dhe shkallëzueshmëri më të thjeshtë horizontale.
VNF - Funksioni i rrjetit virtual. Pajisje specifike virtuale: ruteri, ndërprerësi, muri i zjarrit, NAT, IPS/IDS, etj.
Tani po e thjeshtoj qëllimisht përshkrimin në një zbatim specifik, në mënyrë që të mos ngatërroj shumë lexuesin. Për lexim më të zhytur në mendime, e drejtoj atë në seksion . Për më tepër, Gryka e Romës, e cila kritikon këtë artikull për pasaktësi, premton të shkruajë një numër të veçantë për teknologjitë e virtualizimit të serverëve dhe rrjeteve, më të thelluara dhe të vëmendshme ndaj detajeve.
Shumica e rrjeteve sot mund të ndahen qartë në dy pjesë:
shtresë përfund — një rrjet fizik me një konfigurim të qëndrueshëm.
Mbulesë — abstraksion mbi shtresën e poshtme për izolimin e qiramarrësve.
Kjo është e vërtetë si për rastin e DC (që do ta analizojmë në këtë artikull) ashtu edhe për ISP-në (që nuk do ta analizojmë, sepse tashmë ka qenë ). Me rrjetet e ndërmarrjeve, sigurisht, situata është disi e ndryshme.
Foto me fokus në rrjet:
shtresë përfund
Underlay është një rrjet fizik: çelsat dhe kabllot e harduerit. Pajisjet në nëntokë dinë të arrijnë tek makinat fizike.
Ai mbështetet në protokollet dhe teknologjitë standarde. Jo më pak sepse pajisjet harduerike deri më sot funksionojnë me softuer të pronarit që nuk lejon as programimin e çipit ose zbatimin e protokolleve të veta; në përputhje me rrethanat, nevojiten përputhshmëri me shitësit e tjerë dhe standardizim.
Por dikush si Google mund të përballojë të zhvillojë çelësat e tij dhe të braktisë protokollet e pranuara përgjithësisht. Por LAN_DC nuk është Google.
Nënshtresa ndryshon relativisht rrallë sepse detyra e saj është lidhja bazë IP midis makinave fizike. Underlay nuk di asgjë për shërbimet, klientët ose qiramarrësit që funksionojnë në krye të tij - i duhet vetëm të dorëzojë paketën nga një makinë në tjetrën.
Nënshtresa mund të jetë si kjo:
- IPv4+OSPF
- IPv6+ISIS+BGP+L3VPN
- L2+TRILL
- L2 + STP
Rrjeti Underlay është konfiguruar në mënyrën klasike: CLI/GUI/NETCONF.
Me dorë, skriptet, shërbimet e pronarit.
Artikulli tjetër i serisë do t'i kushtohet nënshtresës në më shumë detaje.
Mbulesë
Overlay është një rrjet virtual tunelesh i shtrirë në majë të Underlay, ai lejon VM-të e një klienti të komunikojnë me njëri-tjetrin, duke siguruar izolim nga klientët e tjerë.
Të dhënat e klientit janë të kapsuluara në disa tituj tunelesh për transmetim në rrjetin publik.
Pra, VM-të e një klienti (një shërbimi) mund të komunikojnë me njëri-tjetrin përmes Overlay, pa e ditur as rrugën që merr paketa.
Mbivendosja mund të jetë, për shembull, siç përmenda më lart:
- Tuneli GRE
- VXLAN
- EVPN
- L3VPN
- GJENI
Një rrjet mbivendosje zakonisht konfigurohet dhe mirëmbahet përmes një kontrolluesi qendror. Prej tij, konfigurimi, Plani i Kontrollit dhe Plani i të Dhënave u dorëzohen pajisjeve që drejtojnë dhe kapsulojnë trafikun e klientit. Pak Le ta shohim këtë me shembuj.
Po, ky është SDN në formën e tij më të pastër.
Ekzistojnë dy qasje thelbësisht të ndryshme për organizimin e një rrjeti Overlay:
- Mbivendosja me ToR
- Mbivendosja nga hosti
Mbivendosja me ToR
Mbivendosja mund të fillojë nga çelësi i aksesit (ToR) që qëndron në raft, siç ndodh, për shembull, në rastin e një pëlhure VXLAN.
Ky është një mekanizëm i testuar me kohë në rrjetet ISP dhe të gjithë shitësit e pajisjeve të rrjetit e mbështesin atë.
Megjithatë, në këtë rast, çelësi ToR duhet të jetë në gjendje të ndajë përkatësisht shërbimet e ndryshme dhe administratori i rrjetit duhet, në një masë të caktuar, të bashkëpunojë me administratorët e makinës virtuale dhe të bëjë ndryshime (megjithëse automatikisht) në konfigurimin e pajisjeve. .
Këtu do t'i referoj lexuesit në një artikull rreth miku ynë i vjetër .
Në këtë qasjet për ndërtimin e një rrjeti DC me një strukturë EVPN VXLAN janë përshkruar në detaje.
Dhe për një zhytje më të plotë në realitet, mund të lexoni librin e Tsiska .
Vërej se VXLAN është vetëm një metodë kapsulimi dhe përfundimi i tuneleve mund të ndodhë jo në ToR, por në host, siç ndodh në rastin e OpenStack, për shembull.
Sidoqoftë, pëlhura VXLAN, ku mbivendosja fillon në ToR, është një nga modelet e vendosura të rrjetit të mbivendosjes.
Mbivendosja nga hosti
Një qasje tjetër është fillimi dhe përfundimi i tuneleve në hostet fundore.
Në këtë rast, rrjeti (Underlay) mbetet sa më i thjeshtë dhe statik.
Dhe vetë hosti bën të gjithë kapsulimin e nevojshëm.
Kjo sigurisht që do të kërkojë ekzekutimin e një aplikacioni të veçantë në hostet, por ia vlen.
Së pari, ekzekutimi i një klienti në një makinë Linux është më i lehtë ose, le të themi, edhe i mundur, ndërsa në një ndërprerës ka shumë të ngjarë të duhet të drejtoheni te zgjidhjet e pronarit SDN, gjë që vret idenë e shumë shitësve.
Së dyti, çelësi ToR në këtë rast mund të lihet sa më i thjeshtë që të jetë e mundur, si nga këndvështrimi i Planit të Kontrollit ashtu edhe i Planit të të Dhënave. Në të vërtetë, atëherë nuk ka nevojë të komunikojë me kontrolluesin SDN, dhe gjithashtu nuk ka nevojë të ruajë rrjetet/ARP-të e të gjithë klientëve të lidhur - mjafton të dihet adresa IP e makinës fizike, e cila thjeshton shumë ndërrimin/ tabelat e drejtimit.
Në serinë ADSM, unë zgjedh qasjen e mbivendosjes nga hosti - atëherë flasim vetëm për të dhe nuk do të kthehemi në fabrikën VXLAN.
Është më e lehtë të shikosh shembuj. Dhe si subjekt testimi do të marrim platformën OpenSource SDN OpenContrail, e njohur tani si .
Në fund të artikullit do të jap disa mendime për analogjinë me OpenFlow dhe OpenvSwitch.
Përdorimi i pëlhurës së tungstenit si shembull
Çdo makinë fizike ka vRuter - një ruter virtual që di për rrjetet e lidhura me të dhe cilët klientë i përkasin - në thelb një ruter PE. Për çdo klient, ai mban një tabelë të izoluar të rrugëtimit (lexo VRF). Dhe vRouter në fakt bën tunelizimin e mbivendosjes.
Pak më shumë rreth vRouter është në fund të artikullit.
Çdo VM e vendosur në hipervizor lidhet me vRouter-in e kësaj makinerie nëpërmjet .
TAP - Terminal Access Point - një ndërfaqe virtuale në kernelin Linux që lejon ndërveprimin në rrjet.
Nëse ka disa rrjete prapa vRouter-it, atëherë për secilën prej tyre krijohet një ndërfaqe virtuale, së cilës i është caktuar një adresë IP - do të jetë adresa e parazgjedhur e portës.
Të gjitha rrjetet e një klienti vendosen në një Zgjerimi VRF (një tabelë), të ndryshme - në të ndryshme.
Unë do të bëj një mohim këtu se jo gjithçka është kaq e thjeshtë dhe do ta dërgoj lexuesin kureshtar deri në fund të artikullit.
Në mënyrë që vRouter-at të mund të komunikojnë me njëri-tjetrin, dhe në përputhje me rrethanat VM-të e vendosura pas tyre, ata shkëmbejnë informacionin e rrugëzimit nëpërmjet Kontrolluesi SDN.
Për të dalë në botën e jashtme, ekziston një pikë dalje nga matrica - një portë rrjeti virtual VNGW - Porta e Rrjetit Virtual (mandati im).
Tani le të shohim shembuj të komunikimeve - dhe do të ketë qartësi.
Komunikimi brenda një makinerie të vetme fizike
VM0 dëshiron të dërgojë një paketë në VM2. Le të supozojmë tani se ky është një VM i vetëm klient.
Plani i të dhënave
- VM-0 ka një rrugë të paracaktuar për ndërfaqen e saj eth0. Pakoja dërgohet atje.
Kjo ndërfaqe eth0 në fakt është e lidhur virtualisht me ruterin virtual vRouter përmes ndërfaqes TAP tap0. - vRouter analizon se në cilën ndërfaqe ka ardhur paketa, domethënë cilit klient (VRF) i përket dhe kontrollon adresën e marrësit me tabelën e rrugëtimit të këtij klienti.
- Pasi zbuloi se marrësi në të njëjtën makinë është në një port tjetër, vRouter thjesht e dërgon paketën tek ai pa asnjë titull shtesë - për këtë rast, vRouter tashmë ka një rekord ARP.
Në këtë rast, paketa nuk hyn në rrjetin fizik - ajo drejtohet brenda vRouter-it.
Avioni i kontrollit
Kur fillon makina virtuale, hipervizori i thotë:
- Adresa e saj IP.
- Rruga e paracaktuar është përmes adresës IP të vRouter-it në këtë rrjet.
Hipervizori raporton te vRouter përmes një API të veçantë:
- Çfarë ju nevojitet për të krijuar një ndërfaqe virtuale.
- Çfarë lloj rrjeti virtual duhet të krijojë (VM)?
- Me cilin VRF (VN) ta lidhni.
- Një hyrje statike ARP për këtë VM - cila ndërfaqe është prapa adresës së saj IP dhe me cilën adresë MAC është e lidhur.
Përsëri, procedura aktuale e ndërveprimit është thjeshtuar për hir të të kuptuarit të konceptit.
Kështu, vRouter i sheh të gjitha VM-të e një klienti në një makinë të caktuar si rrjete të lidhura drejtpërdrejt dhe mund të drejtojë vetë midis tyre.
Por VM0 dhe VM1 i përkasin klientëve të ndryshëm dhe, në përputhje me rrethanat, janë në tabela të ndryshme vRouter.
Nëse ata mund të komunikojnë drejtpërdrejt me njëri-tjetrin varet nga cilësimet e vRouter dhe dizajni i rrjetit.
Për shembull, nëse VM-të e të dy klientëve përdorin adresa publike, ose NAT ndodh në vetë vRouter, atëherë mund të bëhet drejtimi i drejtpërdrejtë në vRouter.
Në situatën e kundërt, është e mundur të kryqëzohen hapësirat e adresave - duhet të kaloni përmes një serveri NAT për të marrë një adresë publike - kjo është e ngjashme me aksesin në rrjetet e jashtme, të cilat diskutohen më poshtë.
Komunikimi ndërmjet VM-ve të vendosura në makina të ndryshme fizike
Plani i të dhënave
- Fillimi është saktësisht i njëjtë: VM-0 dërgon një paketë me destinacionin VM-7 (172.17.3.2) në parazgjedhjen e saj.
- vRouter e merr atë dhe këtë herë sheh që destinacioni është në një makinë tjetër dhe është i aksesueshëm përmes Tunnel0.
- Së pari, ai var një etiketë MPLS që identifikon ndërfaqen në distancë, në mënyrë që në anën e pasme vRouter të mund të përcaktojë se ku ta vendosë këtë paketë pa kërkime shtesë.
- Tunnel0 ka burimin 10.0.0.2, destinacioni: 10.0.1.2.
vRouter shton titujt GRE (ose UDP) dhe një IP të re në paketën origjinale. - Tabela e rrugëtimit të vRouter-it ka një rrugë të paracaktuar përmes adresës ToR1 10.0.0.1. Aty e dërgon.
- ToR1, si një anëtar i rrjetit Underlay, e di (për shembull, nëpërmjet OSPF) se si të arrijë në 10.0.1.2 dhe dërgon paketën përgjatë rrugës. Vini re se ECMP është aktivizuar këtu. Në ilustrim ka dy hops të ardhshëm, dhe temat e ndryshme do të renditen në to sipas hash-it. Në rastin e një fabrike të vërtetë, do të ketë më shumë gjasa 4 hops të ardhshëm.
Në të njëjtën kohë, ai nuk ka nevojë të dijë se çfarë është nën kokën e jashtme të IP-së. Kjo është, në fakt, nën IP mund të ketë një sanduiç të IPv6 mbi MPLS mbi Ethernet mbi MPLS mbi GRE mbi mbi Greqisht.
- Prandaj, në anën marrëse, vRouter heq GRE dhe, duke përdorur etiketën MPLS, kupton se në cilën ndërfaqe duhet të dërgohet kjo paketë, e zhvesh atë dhe ia dërgon në formën e saj origjinale marrësit.
Avioni i kontrollit
Kur nisni makinën, ndodh e njëjta gjë siç përshkruhet më sipër.
Dhe plus sa vijon:
- Për çdo klient, vRouter cakton një etiketë MPLS. Kjo është etiketa e shërbimit L3VPN, me të cilën klientët do të ndahen brenda së njëjtës makinë fizike.
Në fakt, etiketa MPLS ndahet gjithmonë pa kushte nga vRouter - në fund të fundit, nuk dihet paraprakisht që makina do të ndërveprojë vetëm me makina të tjera pas të njëjtit vRouter dhe kjo ka shumë të ngjarë që të mos jetë as e vërtetë.
- vRouter krijon një lidhje me kontrolluesin SDN duke përdorur protokollin BGP (ose i ngjashëm me të - në rastin e TF, ky është XMPP 0_o).
- Nëpërmjet këtij sesioni, vRouter raporton rrugët drejt rrjeteve të lidhura te kontrolluesi SDN:
- Adresa e rrjetit
- Metoda e kapsulimit (MPLSoGRE, MPLSoUDP, VXLAN)
- Etiketa e klientit MPLS
- Adresa juaj IP si nexthop
- Kontrolluesi SDN merr rrugë të tilla nga të gjithë vRouterët e lidhur dhe ua pasqyron ato të tjerëve. Kjo do të thotë, ai vepron si një reflektues i rrugës.
E njëjta gjë ndodh në drejtim të kundërt.
Mbivendosja mund të ndryshojë të paktën çdo minutë. Kjo është përafërsisht ajo që ndodh në retë publike, ku klientët rregullisht fillojnë dhe mbyllin makinat e tyre virtuale.
Kontrolluesi qendror kujdeset për të gjithë kompleksitetin e mirëmbajtjes së konfigurimit dhe monitorimit të tabelave të ndërrimit/drejtimit në vRouter.
Përafërsisht, kontrolluesi komunikon me të gjithë vRouter-at nëpërmjet BGP (ose një protokolli të ngjashëm) dhe thjesht transmeton informacionin e rrugëzimit. BGP, për shembull, tashmë ka Address-Family për të përcjellë metodën e kapsulimit ose .
Në të njëjtën kohë, konfigurimi i rrjetit Underlay nuk ndryshon në asnjë mënyrë, i cili, nga rruga, është shumë më i vështirë për t'u automatizuar dhe më i lehtë për t'u thyer me një lëvizje të vështirë.
Dalja në botën e jashtme
Diku duhet të përfundojë simulimi dhe ju duhet të dilni nga bota virtuale në atë reale. Dhe ju duhet një portë telefonike.
Praktikohen dy qasje:
- Është instaluar një ruter harduerësh.
- Është lëshuar një pajisje që zbaton funksionet e një ruteri (po, pas SDN-së, kemi hasur edhe në VNF). Le ta quajmë një portë virtuale.
Avantazhi i qasjes së dytë është shkallëzueshmëria e lirë horizontale - nuk ka fuqi të mjaftueshme - ne lançuam një makinë tjetër virtuale me një portë. Në çdo makineri fizike, pa pasur nevojë të kërkoni raftet e lira, njësitë, fuqinë dalëse, të blini vetë pajisjen, ta transportoni, ta instaloni, ta ndërroni, ta konfiguroni dhe më pas të ndryshoni komponentët e dëmtuar në të.
Disavantazhet e një porte virtuale janë se një njësi e një ruteri fizik është akoma më e fuqishme se një makinë virtuale me shumë bërthama dhe softueri i saj, i përshtatur për bazën e vet harduerike, funksionon shumë më stabil (jo). Është gjithashtu e vështirë të mohohet fakti që kompleksi i harduerit dhe softuerit thjesht funksionon, duke kërkuar vetëm konfigurim, ndërsa nisja dhe mirëmbajtja e një porte virtuale është një detyrë për inxhinierë të fortë.
Me një këmbë, porta shikon në rrjetin virtual Overlay, si një makinë virtuale e zakonshme, dhe mund të ndërveprojë me të gjitha VM-të e tjera. Në të njëjtën kohë, ai mund të përfundojë rrjetet e të gjithë klientëve dhe, në përputhje me rrethanat, të kryejë rrugëzim midis tyre.
Me këmbën tjetër, porta shikon në rrjetin e shtyllës kurrizore dhe di se si të hyjë në internet.
Plani i të dhënave
Kjo do të thotë, procesi duket si ky:
- VM-0, pasi ka vendosur të njëjtin vRouter, dërgon një paketë me një destinacion në botën e jashtme (185.147.83.177) në ndërfaqen eth0.
- vRouter merr këtë paketë dhe kërkon adresën e destinacionit në tabelën e rrugëtimit - gjen rrugën e paracaktuar përmes portës VNGW1 përmes Tunelit 1.
Ai gjithashtu sheh që ky është një tunel GRE me SIP 10.0.0.2 dhe DIP 10.0.255.2, dhe gjithashtu duhet të bashkojë fillimisht etiketën MPLS të këtij klienti, të cilin VNGW1 e pret. - vRouter paketon paketën fillestare me MPLS, GRE dhe kokë të reja IP dhe e dërgon atë në adresën ToR1 10.0.0.1 si parazgjedhje.
- Rrjeti themelor dërgon paketën në portën VNGW1.
- Porta VNGW1 heq titujt e tunelit GRE dhe MPLS, sheh adresën e destinacionit, konsulton tabelën e saj të rrugëzimit dhe kupton që ajo drejtohet në internet - domethënë përmes Pamjes së plotë ose Parazgjedhjes. Nëse është e nevojshme, kryen përkthimin NAT.
- Mund të ketë një rrjet të rregullt IP nga VNGW në kufi, gjë që nuk ka gjasa.
Mund të ketë një rrjet klasik MPLS (IGP+LDP/RSVP TE), mund të ketë një pëlhurë të pasme me BGP LU ose një tunel GRE nga VNGW në kufi nëpërmjet një rrjeti IP.
Sido që të jetë, VNGW1 kryen kapsulimet e nevojshme dhe dërgon paketën fillestare drejt kufirit.
Trafiku në drejtim të kundërt kalon nëpër të njëjtat hapa në rend të kundërt.
- Kufiri e lëshon paketën në VNGW1
- Ai e zhvesh atë, shikon adresën e marrësit dhe sheh se ai është i aksesueshëm përmes tunelit Tunnel1 (MPLSoGRE ose MPLSoUDP).
- Prandaj, ai bashkëngjit një etiketë MPLS, një kokë GRE/UDP dhe një IP të re dhe e dërgon atë në ToR3 10.0.255.1.
Adresa e destinacionit të tunelit është adresa IP e vRouter-it pas të cilit ndodhet VM e synuar - 10.0.0.2. - Rrjeti themelor dërgon paketën në vRouterin e dëshiruar.
- VRouter-i i synuar lexon GRE/UDP, identifikon ndërfaqen duke përdorur etiketën MPLS dhe dërgon një paketë IP të zhveshur në ndërfaqen e tij TAP të lidhur me eth0 të VM.
Avioni i kontrollit
VNGW1 krijon një lagje BGP me një kontrollues SDN, nga i cili merr të gjitha informacionet e rrugëzimit për klientët: cila adresë IP (vRouter) është prapa cilit klient dhe nga cili etiketë MPLS identifikohet.
Në mënyrë të ngjashme, ai vetë informon kontrolluesin SDN për rrugën e paracaktuar me etiketën e këtij klienti, duke treguar veten si nexthop. Dhe më pas ky parazgjedhje arrin në vRouters.
Në VNGW, zakonisht ndodh grumbullimi i rrugës ose përkthimi NAT.
Dhe në drejtimin tjetër, ai dërgon pikërisht këtë rrugë të grumbulluar në seancën me kufijtë ose Reflektorët e Rrugës. Dhe prej tyre merr rrugën e paracaktuar ose Full-View, ose diçka tjetër.
Për sa i përket kapsulimit dhe shkëmbimit të trafikut, VNGW nuk ndryshon nga vRouter.
Nëse e zgjeroni pak hapësirën, atëherë mund të shtoni pajisje të tjera rrjeti në VNGW dhe vRouter, si muret e zjarrit, fermat e pastrimit ose pasurimit të trafikut, IPS, etj.
Dhe me ndihmën e krijimit të njëpasnjëshëm të VRF-ve dhe njoftimit të saktë të rrugëve, ju mund të detyroni trafikun të qarkullojë ashtu siç dëshironi, që quhet Zinxhirim i Shërbimit.
Kjo do të thotë, edhe këtu kontrolluesi SDN vepron si një reflektor i rrugës midis VNGW-ve, vRouterëve dhe pajisjeve të tjera të rrjetit.
Por në fakt, kontrolluesi nxjerr gjithashtu informacione rreth ACL dhe PBR (Policy Based Routing), duke bërë që flukset individuale të trafikut të shkojnë ndryshe nga sa u thotë rruga.
FAQ
Pse e bëni gjithmonë vërejtjen GRE/UDP?
Epo, në përgjithësi, kjo mund të thuhet se është specifike për pëlhurën e tungstenit - nuk duhet ta merrni fare parasysh.
Por nëse e marrim atë, vetë TF, ndërsa ishte ende OpenContrail, mbështeti të dy kapsulimet: MPLS në GRE dhe MPLS në UDP.
UDP është i mirë sepse në Portin Burim është shumë e lehtë të kodosh një funksion hash nga IP+Proto+Port origjinal në kokën e tij, gjë që do t'ju lejojë të bëni balancimin.
Në rastin e GRE, mjerisht, ka vetëm tituj të jashtëm IP dhe GRE, të cilët janë të njëjtë për të gjithë trafikun e kapsuluar dhe nuk flitet për balancim - pak njerëz mund të shikojnë kaq thellë brenda paketës.
Deri në njëfarë kohe, ruterat, nëse dinin të përdornin tunele dinamike, e bënin këtë vetëm në MPLSoGRE, dhe vetëm kohët e fundit ata mësuan të përdorin MPLSoUDP. Prandaj, gjithmonë duhet të bëjmë një shënim për mundësinë e dy kapsulimeve të ndryshme.
Me drejtësi, vlen të përmendet se TF mbështet plotësisht lidhjen L2 duke përdorur VXLAN.
Ju premtuat të bëni paralele me OpenFlow.
Ata me të vërtetë po e kërkojnë atë. vSwitch në të njëjtin OpenStack bën gjëra shumë të ngjashme, duke përdorur VXLAN, i cili, nga rruga, ka gjithashtu një kokë UDP.
Në planin e të dhënave ato punojnë afërsisht njësoj; rrafshi i kontrollit ndryshon ndjeshëm. Tungsten Fabric përdor XMPP për të dhënë informacionin e rrugëtimit te vRouter, ndërsa OpenStack ekzekuton Openflow.
Mund të më thoni pak më shumë për vRouter?
Ai është i ndarë në dy pjesë: vRouter Agent dhe vRouter Forwarder.
I pari funksionon në hapësirën e përdoruesit të sistemit operativ pritës dhe komunikon me kontrolluesin SDN, duke shkëmbyer informacione rreth rrugëve, VRF-ve dhe ACL-ve.
E dyta zbaton Data Plane - zakonisht në Kernel Space, por mund të funksionojë edhe në SmartNIC - karta rrjeti me një CPU dhe një çip të veçantë komutues të programueshëm, i cili ju lejon të hiqni ngarkesën nga CPU e makinës pritëse dhe ta bëni rrjetin më të shpejtë dhe më shumë e parashikueshme.
Një tjetër skenar i mundshëm është që vRouter është një aplikacion DPDK në Hapësirën e Përdoruesit.
Agjenti vRouter dërgon cilësimet te vRouter Forwarder.
Çfarë është një rrjet virtual?
Unë përmenda në fillim të artikullit për VRF-në se çdo qiramarrës është i lidhur me VRF-në e tij. Dhe nëse kjo ishte e mjaftueshme për një kuptim sipërfaqësor të funksionimit të rrjetit të mbivendosjes, atëherë në përsëritjen tjetër është e nevojshme të bëhen sqarime.
Në mënyrë tipike, në mekanizmat e virtualizimit, entiteti i Rrjetit Virtual (mund ta konsideroni këtë një emër të duhur) prezantohet veçmas nga klientët / qiramarrësit / makinat virtuale - një gjë krejtësisht e pavarur. Dhe ky Rrjet Virtual tashmë mund të lidhet përmes ndërfaqeve me një qiramarrës, me një tjetër, me dy ose kudo. Kështu, për shembull, Zinxhirimi i Shërbimit zbatohet kur trafiku duhet të kalojë nëpër nyje të caktuara në sekuencën e kërkuar, thjesht duke krijuar dhe lidhur Rrjetet Virtuale në sekuencën e duhur.
Prandaj, si e tillë, nuk ka korrespondencë të drejtpërdrejtë midis Rrjetit Virtual dhe qiramarrësit.
Përfundim
Ky është një përshkrim shumë sipërfaqësor i funksionimit të një rrjeti virtual me një mbivendosje nga hosti dhe një kontrollues SDN. Por pavarësisht se çfarë platforme virtualizimi zgjidhni sot, ajo do të funksionojë në një mënyrë të ngjashme, qoftë VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric ose Juniper Contrail. Ato do të ndryshojnë në llojet e kapsulimeve dhe titujve, protokollet për dhënien e informacionit në pajisjet fundore të rrjetit, por parimi i një rrjeti mbivendosjeje të konfigurueshëm nga softueri që punon në krye të një rrjeti nënshtresor relativisht të thjeshtë dhe statik do të mbetet i njëjtë.
Mund të themi se sot SDN e bazuar në një rrjet mbivendosje ka fituar fushën e krijimit të një reje private. Sidoqoftë, kjo nuk do të thotë që Openflow nuk ka vend në botën moderne - përdoret në OpenStacke dhe në të njëjtin VMWare NSX, me sa di unë, Google e përdor atë për të vendosur rrjetin nëntokësor.
Më poshtë kam dhënë lidhje me materiale më të detajuara nëse doni ta studioni çështjen më thellë.
Po në lidhje me shtresën tonë të poshtme?
Por në përgjithësi, asgjë. Ai nuk e ndryshoi të gjithë rrugën. Gjithçka që ai duhet të bëjë në rastin e një mbivendosjeje nga hosti është të përditësojë rrugët dhe ARP-të pasi vRouter/VNGW shfaqen dhe zhduken dhe bartin pako ndërmjet tyre.
Le të formulojmë një listë të kërkesave për rrjetin Underlay.
- Jeni në gjendje të përdorni një lloj protokolli të rrugëtimit, në situatën tonë - BGP.
- Keni një brez të gjerë, mundësisht pa mbiabonim, në mënyrë që paketat të mos humbasin për shkak të mbingarkesave.
- Mbështetja e ECMP është një pjesë integrale e pëlhurës.
- Të jetë në gjendje të ofrojë QoS, duke përfshirë gjëra të ndërlikuara si ECN.
- Mbështetja e NETCONF është një bazë për të ardhmen.
Këtu i kushtova shumë pak kohë punës së vetë rrjetit Underlay. Kjo për shkak se më vonë në serial do të fokusohem në të, dhe do të prekim vetëm kalimthi mbi Overlay.
Natyrisht, unë po na kufizoj rëndë të gjithëve duke përdorur si shembull një rrjet DC të ndërtuar në një fabrikë Cloz me rrugëzim të pastër IP dhe një mbivendosje nga hosti.
Megjithatë, kam besim se çdo rrjet që ka një dizajn mund të përshkruhet në terma zyrtarë dhe të automatizuar. Thjesht qëllimi im këtu është të kuptoj qasjet ndaj automatizimit dhe të mos i ngatërroj të gjithë duke e zgjidhur problemin në një formë të përgjithshme.
Si pjesë e ADSM, Roman Gorge dhe unë planifikojmë të publikojmë një numër të veçantë në lidhje me virtualizimin e fuqisë kompjuterike dhe ndërveprimin e saj me virtualizimin e rrjetit. Qëndroni në kontakt.
Lidhje të dobishme
- .
- . 6 orë rreth Yandex.Cloud, i cili gjithashtu mbulon rrjetin virtual në TF.
- .
- . Ai flet për të gjithë rrjetin DC, duke përfshirë Underlay, Overlay, qasjet ndaj multi-homing dhe menaxhimit.
Faleminderit
- - ish host i podcast-it linkmeup dhe tani ekspert në fushën e platformave cloud. Për komente dhe modifikime. Epo, ne jemi duke pritur për artikullin e tij më të thelluar mbi virtualizimin në të ardhmen e afërt.
- - kolegu dhe eksperti im në fushën e zhvillimit të rrjeteve virtuale. Për komente dhe modifikime.
- - kolegu dhe eksperti im në fushën e pëlhurës së tungstenit. Për komente dhe modifikime.
- - lidhjen e ilustruesit. Për KDPV.
- Aleksandër Limonov. Për meme "automatike".
Burimi: www.habr.com