Në Unë e përshkrova kornizën e automatizimit të rrjetit. Sipas komenteve, disa njerëz madje mendojnë që kjo qasje e parë ndaj problemit tashmë ka sqaruar disa çështje. Dhe kjo më bën shumë të lumtur, sepse qëllimi ynë në këtë cikël është jo të mbushim Ansible me skripte Python, por të ndërtuam një sistem.
Kjo kornizë përcakton rendin në të cilin do të merremi me çështjen.
Dhe virtualizimi i rrjetit, që i dedikohet ky numër, nuk përputhet shumë me tematikën e ADSM, ku diskutojmë automatizimin.
Por le të shohim nga një tjetër këndvështrim.
Shumë shërbime tashmë përdorin një rrjet. Në rastin e operatorit të komunikimit, këtë e përfshin 2G, 3G, LTE, ShPD dhe B2B, për shembull. Në rastin e DC: lidhshmëria për klientë të ndryshëm, Interneti, ruajtja bllok dhe ruajtja objekt.
Dhe të gjitha shërbimet kërkojnë izolim nga njëra-tjetra. Kështu lindën rrjetet mbulese.
Dhe të gjitha shërbimet nuk duan të presin derisa një njeri t'i konfigurojë manualisht. Kështu lindën orkestratorët dhe SDN.
Qashtu që u afrua automatizimi sistematik i rrjetit, më saktësisht një pjese të tij, është ndërmarrë që më parë dhe është zbatuar në shumë vende: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
Sot do ta analizojmë këtë.
PĂ«rmbajtja
- Arsyet
- Termat
- Underlay â rrjeti fizik
- Overlay â rrjeti virtual
- Overlay nga ToR
- Overlay nga hosti
- NĂ« shembullin e Tungsten Fabric
- Komunikimi brenda një makine fizike
- Komunikimi midis VM-ve që ndodhen në makina të ndryshme fizike
- Dalja në botën e jashtme
- FAQ
- PĂ«rfundimi
- Linqe të dobishme
Arsyet
Dhe pasi e përmendëm këtë, është e rëndësishme të përmendim parakushtet për virtualizimin e rrjetit. Në fakt, ky proces ka filluar shumë kohë më parë.
Mund tĂ« keni dĂ«gjuar shpesh se rrjeti gjithmonĂ« ka qenĂ« 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 tĂ« bĂ«sh ndryshime nĂ« tĂ« Ă«shtĂ« mjaft e vĂ«shtirĂ« â shĂ«rbimet nuk e duan kur rrjeti bie. Shpesh, dĂ«shtimi i njĂ« node mund tĂ« dĂ«rgojĂ« nĂ« avari shumĂ« aplikacione dhe ndikojnĂ« nĂ« shumĂ« klientĂ«. PjesĂ«risht pĂ«r kĂ«tĂ« arsye, ekipi i rrjetit mund tĂ« rezistojĂ« ndaj ndonjĂ« ndryshimi â sepse tani funksionon ndonjĂ«herĂ« (ndoshta madje nuk e dimĂ« si), dhe kĂ«tu duhet tĂ« konfigurohet diçka e re, dhe nuk dihet sesi do tĂ« ndikojĂ« nĂ« rrjet.
PĂ«r tĂ« mos pritur qĂ« rrjetarĂ«t tĂ« instalojnĂ« VLAN dhe pĂ«r tĂ« mos e shkruar çdo shĂ«rbim nĂ« çdo nyje tĂ« rrjetit, njerĂ«zit shpikĂ«n pĂ«rdorimin e overlay-ve â rrjete tĂ« mbivendosura â tĂ« cilat janĂ« shumĂ« tĂ« llojeve: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE etj.
Tërheqja e tyre qëndron në dy gjëra të thjeshta:
- Konfigurohen vetĂ«m nyjet pĂ«rfundimtare â nuk preken ato pĂ«rmes. Kjo e acceleron ndjeshĂ«m procesin, dhe ndonjĂ«herĂ« lejon tĂ« pĂ«rjashtohet madje edhe departamenti i infrastrukturĂ«s rrjetore nga procesi i promovimit tĂ« shĂ«rbimeve tĂ« reja.
- Ngarkesa Ă«shtĂ« e fshehur thellĂ« brenda titujve â nyjet tranzit nuk kanĂ« nevojĂ« tĂ« dinĂ« asgjĂ« pĂ«r tĂ«, pĂ«r adresat nĂ« aparate, dhe pĂ«r rrugĂ«t e rrjetit tĂ« mbivendosur. Kjo do tĂ« thotĂ« se duhet tĂ« mbahen mĂ« pak informacione nĂ« tabela, duke lejuar qĂ« tĂ« pĂ«rdoren pajisje mĂ« tĂ« thjeshta / mĂ« tĂ« lira.
Në këtë edicion që nuk është plotësisht i plotë, nuk planifikoj të shqyrtoj të gjitha teknologjitë e mundshme, por më shumë t'i përshkruaj kuadri i punës së rrjeteve overlay në qendrat e të dhënave.
E gjithë seria do të përshkruajë një qendër të dhënash, e cila përbëhet nga rreshta të raftëve të njëtrajtshëm, në të cilat janë instaluar pajisje serverash të ngjashme.
Ky pajisje përdoren për të nisur makina virtuale/kontejnerë/serverless që ofrojnë shërbime.
Termat
Në cikël serverin do ta quaj programin që implementon anën server të komunikimit klient-server.
Makinat fizike në rafte quhen servera nuk do ta bëjmë.
MakinĂ« fizike â njĂ« kompjuter x86, i instaluar nĂ« raft. Termi mĂ« i pĂ«rdorur Ă«shtĂ« host. Dhe kĂ«shtu do ta quajmĂ« «makinë» ose host.
Hypervisor â njĂ« aplikacion qĂ« ekzekutohet nĂ« njĂ« makinĂ« fizike, duke emuluar burimet fizike mbi tĂ« cilat funksionojnĂ« Makina Virtuale. NdonjĂ«herĂ« nĂ« literatura dhe internet fjalĂ«n «hypervisor» e pĂ«rdorin si sinonim tĂ« «host».
MakinĂ« virtuale â njĂ« sistem operativ i ekzekutuar nĂ« makinĂ«n fizike mbi hypervisor. PĂ«r ne, brenda kĂ«tij cikli, nuk Ă«shtĂ« kaq e rĂ«ndĂ«sishme nĂ«se Ă«shtĂ« me tĂ« vĂ«rtetĂ« njĂ« makinĂ« virtuale ose thjesht njĂ« konteiner. Do ta quajmĂ« kĂ«tĂ« «VM«
Tenant â njĂ« koncept i gjerĂ«, tĂ« cilin nĂ« kĂ«tĂ« artikull do ta pĂ«rcaktoj si njĂ« shĂ«rbim tĂ« veçantĂ« ose njĂ« klient tĂ« veçantĂ«.
Multi-tenancy ose multitenancy â pĂ«rdorimi i njĂ«jtit aplikacion nga klientĂ«/shĂ«rbime tĂ« ndryshme. NĂ« kĂ«tĂ« mĂ«nyrĂ«, izolimi i klientĂ«ve arrihet pĂ«rmes arkitekturĂ«s sĂ« aplikacionit dhe jo me instanca tĂ« veçanta tĂ« nisura.
ToR â Switch-i nĂ« krye tĂ« raftit â njĂ« switch i instaluar nĂ« njĂ« raft, ku tĂ« gjitha makinat fizike janĂ« tĂ« lidhura.
Përveç topologjisë ToR, ofrues të ndryshëm praktikojnë End of Row (EoR) ose Middle of Row (pavarësisht se e fundit është një raritet dhe nuk kam hasur abbrevaturën MoR).
Rrjeti nĂ«nkat ose rrjeti nĂ«nkat ose underlay â infrastruktura fizike e rrjetit: switch-e, router-a, kabllo.
Rrjeti mbi ose rrjeti mbi ose overlay â njĂ« rrjet virtual tunelesh qĂ« punon mbi fizikoren.
Fabrika L3 ose fabrika IP â njĂ« shpikje e mahnitshme e njerĂ«zimit, qĂ« lejon qĂ« nĂ« intervista tĂ« mos pĂ«rsĂ«riten STP dhe tĂ« mos mĂ«sohen TRILL. NjĂ« koncept ku e gjithĂ« rrjeti deri nĂ« nivelin e qasjes Ă«shtĂ« ekskluzivisht L3, pa VLAN dhe nĂ« pĂ«rputhje me domene tĂ« mĂ«dha tĂ« pĂ«rhapura tĂ« transmetimit. Nga vjen fjala "fabrikĂ«", do ta shqyrtojmĂ« nĂ« pjesĂ«n tjetĂ«r.
SDN â Rrjeti i Definuar nga Softueri. ĂshtĂ« e njohur mirĂ«. Qasja nĂ« menaxhimin e rrjetit kur ndryshimet nĂ« rrjet bĂ«hen nga programi dhe jo nga njeriu. Zakonisht do tĂ« thotĂ« qĂ« Planin e Kontrollit e nxjerrim jashtĂ« pajisjeve pĂ«rfundimtare tĂ« rrjetit nĂ« njĂ« kontrollues.
NFV â Virtualizimi i Funksioneve tĂ« Rrjetit â virtualizimi i pajisjeve rrjetore qĂ« supozon se disa funksione tĂ« rrjetit mund tĂ« ekzekutohen nĂ« formĂ«n e mjeteve virtuale ose konteinerĂ«ve pĂ«r tĂ« pĂ«rshpejtuar implementimin e shĂ«rbimeve tĂ« reja, organizimin e ShkĂ«mbimit tĂ« ShĂ«rbimeve dhe mĂ« shumĂ« lehtĂ«si nĂ« shkallĂ«zimin horizontal.
VNF â Funksioni Virtual i Rrjetit. NjĂ« pajisje virtuale specifike: router, switch, firewall, NAT, IPS/IDS etj.
Aktualisht po e thjeshtoj qëllimisht përshkrimin në një realizim konkret për të mos e ngatërruar shumë lexuesin. Për një lexim më të thellë, e referoj në seksionin . Për më tepër, Roma Gorge, që kritikon këtë artikull për pasaktësi, premton të shkruajë një numër të veçantë mbi teknologjitë e virtualizimit të serverëve dhe rrjeteve, më të thellë dhe më të vëmendshme ndaj detajeve.
Shumica e rrjeteve sot mund të ndahen qartë në dy pjesë:
Underlay â rrjeti fizik me konfigurim tĂ« qĂ«ndrueshĂ«m.
Overlay â abstraksion mbi Underlay pĂ«r izolimin e tenantĂ«ve.
Kjo është e vërtetë si për rastin e DC (të cilin do ta shqyrtojmë në këtë artikull), ashtu edhe për ISP (të cilin nuk do ta shqyrtojmë, pasi që është trajtuar më parë në ). Me rrjetet enterprise, sigurisht, situata është paksa ndryshe.
Imazhi me përqendrim në rrjet:
Underlay
Underlay â Ă«shtĂ« rrjeti fizik: switch-at dhe kabllot harduerike. Pajisjet nĂ« underlay dinĂ« si tĂ« arrijnĂ« te makinat fizike.
Ai mbështetet në protokollet dhe teknologjitë standarde. Jo në mënyrë të fundit sepse pajisjet harduerike deri më sot punojnë me softuer të pronarit, i cili nuk lejon as programimin e chip-it, as implementimin e protokolleve të veta, përkatësisht, nevojitet përputhshmëri me ofruesit e tjerë dhe standardizim.
Por ndonjë dikush si Google mund të lejojë zhvillimin e switch-eve të veta dhe heqjen dorë nga protokollet e zakonshme. Por LAN_DC nuk është Google.
Underlay relativisht rrallĂ« ndryshohet, sepse detyra e tij Ă«shtĂ« lidhshmĂ«ria bazĂ« IP midis makinave fizike. Underlay nuk di asgjĂ« pĂ«r shĂ«rbimet, klientĂ«t, tenantĂ«t qĂ« funksionojnĂ« mbi tĂ« â ai ka vetĂ«m nevojĂ« tĂ« dĂ«rgojĂ« paketĂ«n nga njĂ« makinĂ« nĂ« njĂ« tjetĂ«r.
Underlay mund të jetë, për shembull, si kjo:
- IPv4+OSPF
- IPv6+ISIS+BGP+L3VPN
- L2+TRILL
- L2+STP
Rrjeti Underlay konfigurtohet në mënyrë klasike: CLI/GUID/NETCONF.
Dora dorës, me skripte, me mjete pronarësh.
Një artikull më i detajuar për Underlay do të publikohet në vijim.
Overlay
Overlay është një rrjet virtual tunelesh, i tendosur mbi Underlay, i cili lejon që VM-të e një klienti të komunikojnë mes tyre, duke siguruar kështu izolim nga klientët e tjerë.
Të dhënat e klientit inkapulohen në ndonjë tituj tunelimi për të kaluar përmes rrjetit të përbashkët.
Kështu VM-të e një klienti (të një shërbimi) mund të komunikojnë mes tyre përmes Overlay, madje pa dyshuar se çfarë rruge kalon paketa në të vërtetë.
Overlay mund të jetë, për shembull, siç e përmenda më lart:
- GRE-tunel
- VXLAN
- EVPN
- L3VPN
- GENEVE
Rrjeti Overlay zakonisht konfigurohet dhe mbështetet përmes një kontrolluesi qendror. Nga aty, konfigurimi, Control Plane dhe Data Plane dërgohen në pajisjet që merren me routing dhe inkapulimin e trafikut të klientëve. Pak më do të shpjegojmë këtë me shembuj.
Po, është SDN në formën më të pastër.
Ekzistojnë dy qasje të ndryshme thelbësore për organizimin e rrjetit Overlay:
- Overlay nga ToR
- Overlay nga hosti
Overlay nga ToR
Overlay mund të fillojë në switch-in e aksesit (ToR), që ndodhet në raft, siç ndodh, për shembull, në rastin e fabrikës VXLAN.
Ky është një mekanizëm që e ka provuar koha në rrjetet ISP dhe të gjithë ofruesit e pajisjeve rrjetike e mbështesin atë.
Megjithatë, në këtë rast, switch-i ToR duhet të jetë në gjendje të separojë shërbime të ndryshme, përkatësisht, dhe administratori i rrjetit duhet të bashkëpunojë në një masë të caktuar me administratorët e makinave virtuale dhe të bëjë ndryshime (edhe në mënyrë automatike) në konfigurimin e pajisjeve.
Këtu do ta referoj lexuesin në artikullin mbi të mirëpriturit tonë të vjetër .
Në këtë janë përshkruar me detaje qasjet për ndërtimin e rrjetit DC me fabrikën EVPN VXLAN.
Dhe për një zhytje më të plotë në realitet, mund të lexoni librin e Cisco-s .
Dua të vë në dukje se VXLAN është vetëm një metodë e inkapsulimit dhe terminimi i tuneleve mund të ndodhë jo në ToR, por në host, siç ndodh në rastin e OpenStack, për shembull.
Megjithatë, një fabrikë VXLAN ku overlay fillon në ToR është një nga dizajnet e konsoliduara të rrjetit overlay.
Overlay nga hosti
Qasje tjetër është të fillohet dhe të terminohen tunelet në hostet përfundimtarë.
Në këtë rast, rrjeti (Underlay) mbetet maksimalisht i thjeshtë dhe statik.
Dhe hosti bën të gjitha inkapsulimet e nevojshme.
Për këtë, do të nevojitet patjetër të ekzekutohet një aplikacion i veçantë në hostet, por ia vlen.
SĂ« pari, e Ă«shtĂ« mĂ« e lehtĂ« tĂ« nisĂ«sh klientin nĂ« njĂ« makinĂ« linux, ose, thĂ«nĂ« ndryshe â Ă«shtĂ« e mundur â ndĂ«rsa nĂ« njĂ« switch, pĂ«r fat tĂ« keq, do tĂ« duhet tĂ« pĂ«rdorim zgjidhje SDN proprietar, qĂ« e vret idenĂ« e multi-operatorĂ«ve.
SĂ« dyti, switch-i ToR nĂ« kĂ«tĂ« rast mund tĂ« mbetet maksimalisht i thjeshtĂ«, si nga pikĂ«pamja e Control Plane-it ashtu edhe e Data Plane-it. NĂ« tĂ« vĂ«rtetĂ« â me controller-in SDN nuk ka nevojĂ« tĂ« komunikojĂ«, dhe pĂ«r tĂ« ruajtur rrjetet/ARP-tĂ« e tĂ« gjithĂ« klientĂ«ve tĂ« lidhur â mjafton tĂ« dihet IP adresa e makinĂ« fizike, qĂ« lehtĂ«son ndjeshĂ«m tabelat e kalimit/routimit.
NĂ« serinĂ« ADSM, unĂ« zgjedh qasjen e overlay nga hosti â mĂ« pas do tĂ« flasim vetĂ«m pĂ«r tĂ« dhe nuk do tĂ« kthehemi mĂ« te fabrika VXLAN.
Më lehtë është të shqyrtojmë me shembuj. Dhe si dëshmitar do të marrim platformën SDN OpenSource OpenContrail, tani të njohur si .
Në fund të artikullit do të jap disa mendime mbi analogjinë me OpenFlow dhe OpenvSwitch.
NĂ« shembullin e Tungsten Fabric
NĂ« çdo makinĂ« fizike ka vRouter â njĂ« ruter virtual, i cili Ă«shtĂ« nĂ« dijeni tĂ« rrjeteve qĂ« janĂ« lidhur me tĂ« dhe cilĂ«ve klientĂ« u pĂ«rkasin ato â nĂ« thelb â Ă«shtĂ« njĂ« ruter PE. PĂ«r çdo klient mbaj njĂ« tabelĂ« ruterizimi tĂ« izoluar (lexo VRF). Dhe vetĂ« vRouter-i bĂ«n tunelimin Overlay.
Pak mĂ« shumĂ« rreth vRouter-it â nĂ« fund tĂ« artikullit.
Ădo VM, e vendosur nĂ« hipervizor, lidhet me vRouter-in e kĂ«saj makine pĂ«rmes .
TAP â Terminal Access Point â njĂ« interfaz virtual nĂ« kernelin linux, e cila lejon ndĂ«rveprimin rrjetor.
NĂ«se pas vRouter-it ka disa rrjete, pĂ«r secilĂ«n krijohet njĂ« interfejs virtual, pĂ«r tĂ« cilin caktohet njĂ« adresĂ« IP â ajo do tĂ« jetĂ« adresa e derĂ«s nga e cila aksesohet.
TĂ« gjithĂ« rrjetet e njĂ« klienti vendosen nĂ« njĂ« VRF (njĂ« tabelĂ«), tĂ« ndryshmet â nĂ« tĂ« ndryshme.
Do të bëj një sqarim këtu, se nuk është gjithçka kaq e thjeshtë, dhe do t'i dërgoj lexuesit kurioz në fund të artikullit..
Për të lejuar vRouter'ët të komunikojnë me njëri-tjetrin, si dhe me VM-të që ndodhen pas tyre, ata shkëmbejnë informacionin mbi rrugët përmes kontrollorit SDN.
PĂ«r tĂ« dalĂ« nĂ« botĂ«n e jashtme, ekziston njĂ« pikĂ« dalĂ«se nga matrica â porta virtuale e rrjetit VNGW â Virtual Network GateWay (termi im).
Tani le tĂ« shqyrtojmĂ« shembuj komunikimesh â dhe do tĂ« qartĂ«sohet.
Komunikimi brenda një makine fizike
VM0 dëshiron të dërgojë një paketë në VM2. Le të supozojmë se këto janë VM-të e klientit të njëjtë.
Data Plane
- VM-0 ka një rrugë për default në ndërfaqen e tij eth0. Paketa dërgohet atje.
Kjo ndërfaqe eth0 në fakt është virtualisht e lidhur me virtualizuesin vRouter përmes ndërfaqes TAP tap0. - vRouter analizojnë në cilën ndërfaqe ka mbërritur paketa, domethënë, në cilin klient (VRF) i përket, duke krahasuar adresën e marrësit me tabelën e rrugëtimit të këtij klienti.
- Duke zbuluar se marrĂ«si ndodhet nĂ« tĂ« njĂ«jtĂ«n makinĂ« nĂ« njĂ« port tjetĂ«r, vRouter-i thjesht e dĂ«rgon paketen atje pa ndonjĂ« header shtesĂ« â pĂ«r kĂ«tĂ« rast, vRouter-i tashmĂ« ka njĂ« regjistrim ARP.
Paketa nĂ« kĂ«tĂ« rast nuk kalon nĂ« rrjetin fizik â Ă«shtĂ« rrugĂ«zuar brenda vRouter-it.
Control Plane
Hipervizori kur aktivizon makinën virtuale i raporton asaj:
- Adresa e saj IP.
- Rruga për default është përmes adresës IP të vRouter-it në këtë rrjet.
vRouter-it i raportohet përmes një API të veçantë nga hipervizori:
- ĂfarĂ« duhet tĂ« krijohet si njĂ« ndĂ«rfaqe virtuale.
- Cila Rrjet Virtual duhet të krijohet për të (VM).
- Në cilin VRF duhet të lidhet (VN).
- Një regjistrim statik ARP për këtë VM - pas cilës ndërfaqe ndodhet adresa e saj IP dhe cilit MAC adresë i është e lidhur.
Dhe sërish, procedura reale e ndërveprimit është thjeshtuar për të lehtësuar kuptimin e konceptit.
Kështu, të gjitha VM-të e një klienti në këtë makinë vRouter-i i shohin si rrjete të drejtpërdrejta të lidhura dhe mund të ruterizojnë ndërmjet tyre vetë.
Megjithatë, VM0 dhe VM1 i përkasin klientëve të ndryshëm, duke qenë se janë në tabela të ndryshme të vRouter-it.
Nëse do të mund të komunikonin direkt me njëri-tjetrin, varet nga konfigurimet e vRouter-it 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-in, atëherë mund të bëhet ruterizim i drejtpërdrejtë në vRouter.
Në rastin tjetër, mund të ketë ndërprerje të hapësirave adresore - duhet të kalosh përmes një serveri NAT për të marrë një adresë publike - kjo i ngjan daljes në rrjetet e jashtme, për të cilat do të flasim më poshtë.
Komunikimi midis VM-ve që ndodhen në makina të ndryshme fizike
Data Plane
- Fillimi është e njëjtë: VM-0 dërgon një paketë me adresë VM-7 (172.17.3.2) sipas default-it të tij.
- vRouter e merr dhe këtë herë sheh se adresati ndodhet në një makinë tjetër dhe është i qasshëm përmes tunelit Tunnel0.
- Fillimisht vendos një etiketë MPLS, e cila identifikon ndërfaqen e largët, në mënyrë që në anën e kundërt vRouter të mund të përcaktojë se ku të vendosë këtë paketë pa nevojën për rrethime të tjera.
- Për Tunnel0 burimi është 10.0.0.2, marrësi: 10.0.1.2.
vRouter shton titujt GRE (ose UDP) dhe një IP të re në paketën origjinale. - Në tabelën e router-it vRouter ka një rrugë të default përmes adresës ToR1 10.0.0.1. Atje e dërgon.
- ToR1 si pjesëtar i rrjetit Underlay di (për shembull, përmes OSPF), si të arrijë në 10.0.1.2, dhe dërgon paketën përmes rrugës. Vini re se këtu aktivizohet ECMP. Në ilustimin janë dy next hop, dhe flukset e ndryshme do të shpërndahen në to sipas hash-it. Në rastin e një fabrike reale, këtu do të ishin më shumë se 4 next hop.
Megjithatë, nuk është e nevojshme të dijë se çfarë ndodhet nën titullin e jashtëm IP. Domethënë, faktikisht nën IP mund të jetë një sanduiç IPv6 mbi MPLS mbi Ethernet mbi MPLS mbi GRE mbi mbi mbi Grek.
- Prandaj, në anën pranuese, vRouter-i heq GRE dhe me etiketën MPLS kupton në cilin ndërfaqe ky paket duhet të dërgohet, e ndan dhe e dërgon në formën e tij fillestare te marrësi.
Control Plane
Kur makineria nis, ndodhin të njëjtat gjëra siç u përshkruan më sipër.
Dhe më shumë:
- Për çdo klient, vRouter-i alokon një etiketë MPLS. Ky është një etiketë shërbimi L3VPN, me të cilën klientët do të ndahen brenda një makine fizike.
NĂ« tĂ« vĂ«rtetĂ«, etiketimi MPLS caktohet nga vRouter-i gjithmonĂ« â sepse nuk dihet paraprakisht nĂ«se makina do tĂ« bashkĂ«punojĂ« vetĂ«m me makinat e tjera qĂ« janĂ« pĂ«rmes tĂ« njĂ«jtit vRouter dhe kjo ndoshta as nuk Ă«shtĂ« e tillĂ«.
- vRouter-i krijon njĂ« lidhje me SDN-kontrollerin nĂ«pĂ«rmjet protokollit BGP (ose ndonjĂ« gjĂ« tĂ« ngjashme â nĂ« rastin TF, Ă«shtĂ« XMPP 0_o).
- Përmes kësaj seance, vRouter-i i njofton SDN-kontrollerit rrugët drejt rrjeteve të lidhura:
- Adresa e rrjetit
- Metoda e inkapsulimit (MPLSoGRE, MPLSoUDP, VXLAN)
- Etiketa MPLS e klientit
- IP adresa e tij si nexthop
- SDN-kontrolleri merr këto rrugë nga të gjitha vRouter-t e lidhura dhe i refleksionon ato të tjerëve. Pra, ai vepron si Route Reflector.
E njëjta gjë ndodh edhe në drejtimin e kundërt.
Përgjigjja mund të ndryshojë çdo minutë. Kështu ndodh në reja publike, kur klientët aktivizojnë dhe çaktivizojnë vazhdimisht makinat e tyre virtuale.
Kontrolluesi kryesor merr përsipër të gjitha vështirësitë me mbajtjen e konfiguracionit dhe kontrollin e tabelave të kalimeve/rutave në vRouter.
Në terma të thjeshtë, kontrolluesi lidhet me të gjithë vRouter-at përmes BGP (ose një protokoll të ngjashëm) dhe thjesht transmeton informacionin e ruterit. BGP, për shembull, ka një Address-Family për transmetimin e metodës së inkapsulimit. ose .
Kjo nuk ndryshon asnjë mënyrë konfigurimin e Underlay-rese, e cila, për fat të keq, automatizohet shumë më vështirë, ndërsa prishja e saj mund të ndodhë me një lëvizje të papërshtatshme.
Dalja në botën e jashtme
Njëherë simulimi duhet të përfundojë, dhe nga bota virtuale duhet të kalojmë në atë reale. Dhe na nevojitet një portal përkufizues.
Praktikohen dy qasje:
- Instalohet një ruter harduerik.
- Nis një pajisje të caktuar që realizon funksionet e ruterit (po, pas SDN ne gjithashtu u përballëm me VNF). Ta quajmë atë portal virtual.
Avantazhi i qasjes së dytë është shkalla e ulët e përmirësimit horizontal - është vendosur një VM tjetër me një kalues. Në çdo makinë fizike, pa pasur nevojë për të kërkuar dole negativ, njësitë, energjinë e daljes, për të blerë harduerin, për ta transportuar, instaluar, lidhur, konfiguruar dhe pastaj për të ndryshuar komponentët e prishur.
MegjithatĂ«, disavantazhet e kaluesit virtual Ă«shtĂ« se njĂ«si e router-it fizik Ă«shtĂ« shumĂ« mĂ« e fuqishme se njĂ« VM me shumĂ« bĂ«rthamĂ«, dhe softi i tij, i optimizuar pĂ«r harduerin pĂ«rkatĂ«s, funksionon ndjeshĂ«m mĂ« stabilisht (jo). ĂshtĂ« e vĂ«shtirĂ« tĂ« mohosh faktin se kompleksiteti softuerik-hardware thjesht funksionon, duke kĂ«rkuar vetĂ«m konfigurim, ndĂ«rsa fillimi dhe mbajtja e kaluesit virtual Ă«shtĂ« njĂ« detyrĂ« pĂ«r inxhinierĂ« tĂ« fortĂ«.
Me njërin nga këmbët e tij, kaluesi shikon në rrjetin virtual Overlay, si një VM e zakonshme, dhe mund të ndërveprojë me të gjitha VM-të e tjera. Në të njëjtën kohë, ajo mund të përfundojë rrjetet e të gjithë klientëve dhe, për rrjedhojë, të bëjë edhe shpërndarjen midis tyre.
Këmbë tjetër, gateway-i tashmë shikon për në rrjetin kryesor dhe di se si të dalë në Internet.
Data Plane
Pra, procesi duket kështu:
- VM-0, duke pasur si defolt të njëjtin vRouter, dërgon një paketë me adresë destinacioni në botën e jashtme (185.147.83.177) në ndërfaqen eth0.
- vRouter merr kĂ«tĂ« paketĂ« dhe bĂ«n njĂ« lookup tĂ« adresĂ«s sĂ« destinacionit nĂ« tabelĂ«n e rrugĂ«ve â gjen rrugĂ«n e defoltit pĂ«rmes gateway-it VNGW1 pĂ«rmes Tunnel 1.
Ai gjithashtu sheh se ky është një tunel GRE me SIP 10.0.0.2 dhe DIP 10.0.255.2, dhe gjithashtu duhet të vendosë së pari etiketën MPLS për këtë klient, e cila pritet nga VNGW1. - vRouter paketalon paketën fillestare në titujt MPLS, GRE dhe një IP të re dhe e dërgon në adresën ToR1 10.0.0.1 si defolt.
- Rrjeti nënndërtues e dërgon paketën deri te gateway-i VNGW1.
- Gateway-i VNGW1 heq titujt e tunneling GRE dhe MPLS, sheh adresĂ«n e destinacionit, konsultohet me tabelĂ«n e tij tĂ« rrugĂ«ve dhe kupton se Ă«shtĂ« drejtuar pĂ«r nĂ« Internet â dmth pĂ«rmes Full View ose Default. NĂ«se Ă«shtĂ« e nevojshme, kryen NAT translation.
- Nga VNGW deri te borderi mund të ketë një rrjet IP standard, gjë që është e pamundur.
Mund të jetë një rrjet klasik MPLS (IGP+LDP/RSVP TE), mund të jetë një fabrikë prapaskenë me BGP LU ose një tunel GRE nga VNGW deri te borderi përmes rrjetit IP.
Në çdo rast, VNGW1 kryen inkapsulimet e nevojshme dhe dërgon paketën fillestare drejt kufirit.
Trafiku në anën tjetër kalon të njëjtat hapat në rendin e kundërt.
- Kufiri e dërgon paketën deri në VNGW1.
- Ai e kërkon, shikon adresën e marrësit dhe sheh se ajo është e aksesueshme përmes tunelit Tunnel1 (MPLSoGRE ose MPLSoUDP).
- Për pasojë, ai i shton etiketën MPLS, titullin GRE/UDP dhe një IP të re dhe e dërgon në ToR3 të tij 10.0.255.1.
Adresa e destinacionit tĂ« tunelit Ă«shtĂ« adresa IP e vRouter-it, pas tĂ« cilit qĂ«ndron VM-ja qĂ« dĂ«shirohet â 10.0.0.2. - Rrjeti anĂ«sor dĂ«rgon paketĂ«n nĂ« vRouter-in e nevojshĂ«m.
- VRouter-i i synuar heq GRE/UDP, përcakton interface-in sipas etiketës MPLS dhe dërgon paketën IP të pastër në TAP-in e tij, i lidhur me eth0 të VM-së.
Control Plane
VNGW1 vendos një fqinjësi BGP me SDN-controller-in, nga i cili merr tërë informacionin mbi rrugët për klientët: pas cilës IP adrese (vRouter-i) qëndron cilësi klient, dhe me cilën etiketë MPLS identifikohet.
Po ashtu, ai vetë SDN-controller-it i raporton rrugën default me etiketën e këtij klienti, duke treguar veten si nexthop. Më pas, ky default arrin në vRouter-et.
Në VNGW zakonisht ndodh agregimi i rrugëve ose NAT-translacioni.
Dhe në anën tjetër, në një sesion me borde ose Route Reflector, ai jep pikërisht këtë rrugë të agreguar. Nga ata merr rrugën e paracaktuar ose Full-View, ose diçka tjetër.
Sa i përket inkapsulimit dhe shkëmbimit të trafikut, VNGW nuk ndryshon nga vRouter.
Nëse zgjeroni pak fushën, VNGW dhe vRouter mund të shtohen me pajisje të tjera rrjetesh, si firewall, ferme pastrimi ose pasurimi të trafikut, IPS etj.
Dhe me ndihmën e krijimit të rradhës së VRF dhe njoftimin e duhur të rrugëve, mund ta bëni trafikun të rrotullohet ashtu siç dëshoni, që quhet Service Chaining.
Pra, këtu kontrolluesi SDN vepron si Route-Reflector midis VNGW, vRouter dhe pajisjeve të tjera rrjetesh.
Por faktikisht, kontrolluesi shpërndan gjithashtu informacion mbi ACL dhe PBR (Routing i Bazuar në Politika), duke e detyruar flukset e veçanta të trafikut të lëvizin ndryshe nga sa i thotë ruga.
FAQ
Pse vazhdimisht bën atë vërejtje për GRE/UDP?
Epo, nĂ« tĂ« vĂ«rtetĂ«, mund tĂ« thuhet se kjo Ă«shtĂ« specifike pĂ«r Tungsten Fabric â mund ta injoroni krejtĂ«sisht.
Por nëse e merrni parasysh, vetë TF, akoma duke qenë OpenContrail, mbështeste të dy inkapsulimet: MPLS në GRE dhe MPLS në UDP.
UDP është i mirë sepse në Portin e Burimit në kokën e tij është shumë e lehtë të kodosh një funksion hash nga IP+Proto+Port fillestar, që do të lejojë balancimin.
NĂ« rastin e GRE, fatkeqĂ«sisht, ka vetĂ«m kokat e jashtme IP dhe GRE, tĂ« cilat janĂ« tĂ« njĂ«jta pĂ«r tĂ« gjithĂ« trafikun e inkapsuluar dhe nuk flasim pĂ«r balancimin â pak kush mund tĂ« shikojĂ« kaq thellĂ« brenda paketĂ«s.
Për një kohë, routerat, nëse dinin për tunelat dinamikë, e bënin atë vetëm në MPLSoGRE, dhe vetëm së fundmi, arritën të mësojnë për MPLSoUDP. Prandaj, gjithmonë duhet të theksohet mundësia e dy inkapsulimeve të ndryshme.
Për drejtësinë, duhet të themi se TF përfshin edhe lidhshmërinë L2 me ndihmën e VXLAN.
Ti premtove se do të bësh paralelizma me OpenFlow.
Ata vërtet bëjnë sens. vSwitch në të njëjtin OpenStack bën gjëra shumë të ngjashme, duke përdorur VXLAN, i cili, përveç kësaj, ka gjithashtu një krye UDP.
Në Data Plane ata punojnë përafërsisht të njëjtën mënyrë, ndërsa Control Plane dallon ndjeshëm. Tungsten Fabric përdor XMPP për të dërguar informacionin në lidhje me rrugët në vRouter, ndërsa në OpenStack punon Openflow.
A mund të tregosh pak më shumë për vRouter?
Ai ndahet në dy pjesë: vRouter Agent dhe vRouter Forwarder.
E para derisa në User Space të sistemit operativ të hostit dhe komunikon me SDN-në kontrollere, duke shkëmbyer informacion në lidhje me rrugët, VRF dhe ACL.
E dyta implementon Data Plane â zakonisht nĂ« Kernel Space, por gjithashtu mund tĂ« ekzekutohet nĂ« SmartNIC-et â kartat e rrjetit me CPU dhe njĂ« çip tĂ« veçantĂ« programues pĂ«r ndĂ«rrimin, gjĂ« qĂ« lejon qĂ« ngarkesa tĂ« hiqet nga CPU e makinĂ«s host dhe tĂ« bĂ«jĂ« rrjetin mĂ« tĂ« shpejtĂ« dhe mĂ« tĂ« parashikueshĂ«m.
Një skenar tjetër i mundshëm është kur vRouter është një aplikacion DPDK në User Space.
Agjenti vRouter transmeton konfigurimet në vRouter Forwarder.
ĂfarĂ« Ă«shtĂ« Rrethi Virtual?
Kam përmendur në fillim të artikullit për VRF, se çdo tenant lidhet me VRF-në e tij. Dhe nëse për një kuptim të sipërfaqes të funksionimit të rrjetit overlay kjo mjaftonte, atëherë në iteracionin e ardhshëm duhet bërë sqarime.
Zakonisht, nĂ« mekanizmat e virtualizimit, entiteti Virtual Network (mund ta konsideroni si njĂ« emĂ«r tĂ« veçantĂ«) prezantohet veçmas nga klientĂ«t/tenantĂ«t/makinat virtuale â Ă«shtĂ« njĂ« gjĂ« e pavarur. Ky Virtual Network mund tĂ« lidhet pĂ«rmes interface-ve me njĂ« tenant, me njĂ« tjetĂ«r, me dy, madje edhe mĂ« shumĂ«. KĂ«shtu, realizohet Service Chaining, kur trafiku duhet tĂ« kalojĂ« nĂ«pĂ«r nodet e caktuara nĂ« njĂ« renditje tĂ« dĂ«shiruar, duke krijuar dhe lidhur Virtual Network-et nĂ« rendin e duhur.
Prandaj, nuk ka një përputhje të drejtpërdrejtë ndërmjet Virtual Network dhe tenantit.
PĂ«rfundimi
Kjo është një përshkrim mjaft i sipërfaqshëm i funksionit të rrjetit virtual me overlay nga hosti dhe SDN-kontrolluesi. Por pavarësisht se cila platformë virtualizimi merrni 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 inkapsulimeve dhe të këshillave, protokollet e dorëzimit të informacionit në pajisjet përfundimtare të rrjetit, por parimi i rrjetit të overlay-it të programuar mbetet i njëjtë, duke funksionuar mbi një rrjet të anshteshëm relativisht të thjeshtë dhe statik.
NjĂ« gjĂ« mund tĂ« thuhet me siguri: domeni i krijimit tĂ« njĂ« cloud-i privat, me bazĂ« nĂ« SDN dhe rrjetin e mbĂ«shtjelljes, ka dominuar sot. MegjithatĂ«, kjo nuk do tĂ« thotĂ« qĂ« Openflow nuk ka vend nĂ« botĂ«n bashkĂ«kohore â pĂ«rdoret nĂ« OpenStack dhe nĂ« VMWare NSX, siç di unĂ«, Google e pĂ«rdor atĂ« pĂ«r konfigurimin e rrjetit nĂ«n mbĂ«shtjellje.
Pak më poshtë kam përfshirë lidhje për materialet më të detajuara, nëse dëshiron të studiosh çështjen më thellë.
ĂfarĂ« ndodh me Underlay-n tonĂ«?
NĂ« thelb, asgjĂ«. Ai ka mbetur i pandryshuar gjatĂ« gjithĂ« kohĂ«s. Gjithçka qĂ« duhet tĂ« bĂ«jĂ« nĂ« rastin e mbĂ«shtjelljes nga hosti â Ă«shtĂ« tĂ« pĂ«rditĂ«sojĂ« ruterat dhe ARP-tĂ« ndĂ«rsa vRouter/VNGW shfaqen ose zhduken dhe tĂ« transportojĂ« paketat midis tyre.
Le të formulim një listë kërkesash për rrjetin Underlay.
- TĂ« jetĂ« nĂ« gjendje tĂ« mbĂ«shtesĂ« njĂ« protokoll rrugĂ«zimi, nĂ« situatĂ«n tonĂ« â BGP.
- Të ketë një bandwidth të gjerë, preferohet pa përsëritje për të mos humbur paketa për shkak të ngarkesave.
- TĂ« mbĂ«shtesĂ« ECMP â njĂ« pjesĂ« e pandashme e fabrikĂ«s.
- Të jetë në gjendje të sigurojë QoS, përfshirë gjëra të komplikuara, si ECN.
- TĂ« mbĂ«shtesĂ« NETCONF â njĂ« pĂ«rgatitje pĂ«r tĂ« ardhmen.
Kam bëra pak kohë rreth funksionimit të rrjetit Underlay. Kjo ndodh sepse më vonë në këtë seri do të përqendrohem pikërisht aty, ndërsa Overlay do ta prekim vetëm nëpërmjet.
Duket qartë se po kufizoj shumë të gjithë ne, duke përdorur si shembull rrjetin DC të ndërtuar në fabrikën e Klozës me IP-routing të pastër dhe overlay nga hosti.
Megjithatë, jam i sigurt se cilido rrjet me dizajn mund të përshkruhet në terma formal dhe të automatizohet. Thjesht, këtu po kërkoj të kuptoj qasjet ndaj automatizimit, e jo të ngaterroj të gjithë duke zgjidhur problemin në një formë të përgjithshme.
Në kuadër të ADSM-së, ne dhe Romani Gorge planifikojmë të publikojmë një episod të veçantë mbi virtualizimin e fuqisë të llogaritjes dhe ndërveprimin e saj me virtualizimin e rrjetit. Qëndroni në kontakt.
Linqe të dobishme
- .
- . 6 orë rreth Yandex.Cloud, ku përfshihet edhe rrjeti virtual në TF.
- .
- . Këtu flitet për tërë rrjetin DC, duke përfshirë Underlay, Overlay, qasjet për multi-homing dhe menaxhimin.
Faleminderit
- â ish-ekspert mbi platformat cloud. Faleminderit pĂ«r komentet dhe rregullimet. Po presim sĂ« shpejti njĂ« artikull mĂ« tĂ« thelluar prej tij mbi virtualizimin.
- â kolegĂ« i imi dhe ekspert nĂ« zhvillimin e rrjeteve virtuale. Faleminderit pĂ«r komentet dhe rregullimet.
- â kolegĂ« i imi dhe ekspert mbi Tungsten Fabric. Faleminderit pĂ«r komentet dhe rregullimet.
- â ilustrues pĂ«r linkmeup. Faleminderit pĂ«r KDPV.
- Aleksandër Limonov. Faleminderit për memin 'automato'.
Burimi: habr.com
