Në Kam e përshkruar një kornizë për automatizimin e rrjetit. Nga komentet, disa njerëz besojnë se ky qasje fillestare ndaj problemit tashmë ka ndihmuar për të sqaruar disa çështje. Kjo më gëzon shumë, sepse qëllimi ynë në këtë proces nuk është të mbulojmë Ansible me skenarë Python, por të ndihmojmë për të ndërtuar një sistem.
Kjo kornizë përcakton rendin në të cilin do të merremi me çështjen.
Dhe virtualizimi i rrjetit, për të cilin është dedikuar ky edicion, nuk përshtatet shumë në tematikën e ADSM-së, ku flasim për automatizimin.
Por le të shikojmë atë nga një këndvështrim tjetër.
Shumë shërbime tani përdorin të njëjtin rrjet. Në rastin e operatorit të komunikimit, kjo është 2G, 3G, LTE, SHPD dhe B2B, për shembull. Në rastin e Qendrave të të Dhënave: lidhshmëria për klientë të ndryshëm, Interneti, ruajtja bllokuese, ruajtja objektesh.
Dhe të gjitha shërbimet kërkojnë izolim nga njëra-tjetra. Kështu u krijuan rrjetet e mbivendosura.
Dhe të gjitha shërbimet nuk duan të presin derisa një person t'i konfigurojë ato manualisht. Kështu u krijuan orkestratorët dhe SDN.
Qasja e parë ndaj automatizimit sistematik të rrjetit, më saktë të një pjese të tij, është marrë prej kohësh dhe është zbatuar në shumë vende: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.
Me të do të merremi sot.
PĂ«rmbajtja
- Arsyet
- Terminologjia
- Underlay â rrjeti fizik
- Overlay â rrjeti virtual
- Overlay nga ToR
- Overlay nga hosti
- NĂ« shembullin e Tungsten Fabric
- Komunikimi brenda një makine fizike
- Komunikimi ndërmjet VM-ve të vendosura në makina fizike të ndryshme
- Dalja në botën e jashtme
- FAQ
- PĂ«rfundim
- Useful links
Arsyet
Dhe pasi e përmendem këtë, është mirë të përmendim edhe parakushtet për virtualizimin e rrjetit. Në të vërtetë, ky proces ka filluar prej kohësh.
Ndoshta keni dĂ«gjuar shumĂ« herĂ« se rrjeti gjithmonĂ« ka qenĂ« pjesa mĂ« inerte e çdo sistemi. Dhe kjo Ă«shtĂ« e vĂ«rtetĂ« nĂ« tĂ« gjitha aspektet. 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 tolerojnĂ« kur rrjeti bie. Shpesh, nxjerrja e njĂ« nyje nga shĂ«rbimi mund tĂ« dĂ«mtojĂ« shumicĂ«n e aplikacioneve dhe tĂ« ndikojĂ« nĂ« shumĂ« klientĂ«. PjesĂ«risht pĂ«r kĂ«tĂ« arsye, ekipi i rrjetit mund tĂ« kundĂ«rshtojĂ« çdo ndryshim â sepse tani ndonjĂ«herĂ« funksionon siç duhet (ndoshta madje nuk e dimĂ« si), dhe tani duhet tĂ« konfigurojmĂ« diçka tĂ« re, dhe nuk dihet se si do tĂ« ndikojĂ« nĂ« rrjet.
PĂ«r tĂ« mos pritur qĂ« rrjetarĂ«t tĂ« ngrohin VLAN-in dhe tĂ« mos keni nevojĂ« tĂ« regjistroni çdo shĂ«rbim nĂ« çdo nyje rrjeti, njerĂ«zit shpikĂ«n pĂ«rdorimin e overlay-ve â rrjete tĂ« mbuluara â tĂ« cilat ofrojnĂ« njĂ« shumĂ«llojshmĂ«ri tĂ« madhe: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE etj.
Tërheqja e tyre qëndron në dy aspekte të thjeshta:
- Konfigurohen vetĂ«m nyjet pĂ«rfundimtare â nuk Ă«shtĂ« nevoja tĂ« prekni tĂ« kaluara. Kjo e pĂ«rshpejton procesin ndjeshĂ«m dhe ndonjĂ«herĂ« lejon pĂ«rjashtimin e departamentit tĂ« infrastrukturĂ«s rrjetĂ«sore nga procesi i hyrjes sĂ« shĂ«rbimeve tĂ« reja.
- Ngarkesa Ă«shtĂ« e fshehur thellĂ« brenda titujve â nyjat kaluese nuk kanĂ« nevojĂ« tĂ« dinĂ« asgjĂ« rreth saj, rreth adresave nĂ« hoste, rrugĂ«ve tĂ« rrjetit tĂ« mbuluar. Kjo do tĂ« thotĂ« se nevojitet tĂ« ruajmĂ« mĂ« pak informacione nĂ« tabela, dhe kĂ«shtu tĂ« pĂ«rdorim pajisje mĂ« tĂ« thjeshta dhe mĂ« tĂ« lira.
Në këtë botim jo të plotë nuk kam planifikuar të shqyrtoj të gjitha teknologjitë e mundshme, por më tepër të përshkruaj kornizën e punës së rrjeteve të mbuluara në QK.
E gjithë seria do të përshkruajë një qendër të të dhënave, e përbërë nga radhë stendash homogjene, ku është instaluar pajisje serverike të njëjtë.
Në këtë pajisje fillojnë të funksionojnë makina virtuale/kontejnerë/serverless që realizojnë shërbime.
Terminologjia
Në cikël server do ta quaj programin që realizon anën server të komunikatës klient-server.
Makinat fizike në stenda do t'i quajmë servera jo do të jemi.
MakinĂ« fizike â njĂ« kompjuter x86 i instaluar nĂ« njĂ« stendĂ«. Termi mĂ« i pĂ«rdorur Ă«shtĂ« server. KĂ«shtu do ta quajmĂ« "makinĂ«" ose server.
Hipervizori â njĂ« aplikacion i ekzekutuar nĂ« makinĂ«n fizike qĂ« imiton burimet fizike, mbi tĂ« cilat ekzekutohet Makina Virtuale. NdonjĂ«herĂ« nĂ« literaturĂ« dhe nĂ« rrjet, fjala "hipervizor" pĂ«rdoret si sinonim pĂ«r "host".
MakinĂ« virtuale â njĂ« sistem operativ i ekzekutuar nĂ« makinĂ«n fizike pĂ«rmbi hipervizorin. PĂ«r ne nĂ« kuadĂ«r tĂ« kĂ«tij cikli, nuk ka shumĂ« rĂ«ndĂ«si nĂ«se Ă«shtĂ« vĂ«rtet njĂ« makinĂ« virtuale apo thjesht njĂ« konteiner. Do ta quajmĂ« kĂ«tĂ« "VM«
Tenant â njĂ« term i gjerĂ«, tĂ« cilin do ta pĂ«rcaktoj nĂ« kĂ«tĂ« artikull si njĂ« shĂ«rbim tĂ« veçantĂ« ose njĂ« klient tĂ« veçantĂ«.
Multi-tenancy ose multi-qiraja â pĂ«rdorimi i sĂ« njĂ«jtĂ«s aplikacion nga klientĂ«/shĂ«rbime tĂ« ndryshme. NĂ« kĂ«tĂ« rast, izolimi i klientĂ«ve nga njĂ«ri-tjetri arrihet pĂ«rmes arkitekturĂ«s sĂ« aplikacionit, e jo pĂ«rmes instancave tĂ« veçanta tĂ« drejtuara ndaras.
ToR â NdĂ«rruesi nĂ« MajĂ« tĂ« StendĂ«s â switch mounted in a rack to which all physical machines are connected.
In addition to ToR topology, various providers practice End of Row (EoR) or Middle of Row (although the latter is a rare exception, and I have not encountered the abbreviation MoR).
Underlay network or underlay network â the physical network infrastructure: switches, routers, cables.
Overlay network or overlay network â a virtual tunnel network operating over the physical network.
L3 fabric or IP fabric â a remarkable invention of mankind that allows interviews without repeating STP and learning TRILL. A concept in which the entire network up to the access level is exclusively L3, without VLANs and, consequently, vast broadcast domains. We will address the term "fabric" in the next part.
SDN â Software Defined Network. It hardly needs an introduction. A network management approach where changes in the network are implemented by a program rather than by a person. Usually means moving the Control Plane outside of the end network devices to a controller.
NFV â Network Function Virtualization â virtualization of network devices, suggesting that some network functions can be run as virtual machines or containers to accelerate the deployment of new services, organize Service Chaining, and enable easier horizontal scalability.
VNF â Virtual Network Function. A specific virtual device: router, switch, firewall, NAT, IPS/IDS, etc.
I am intentionally simplifying the description to a specific implementation so as not to confuse the reader. For a more thoughtful read, I refer him to the section . In addition, Roma Gorgé, who criticizes this article for inaccuracies, promises to write a separate issue about server and network virtualization technologies, with more depth and attention to detail.
Most networks today can clearly be divided into two parts:
Underlay â a physical network with a stable configuration.
Overlay â abstraction over Underlay for tenant isolation.
This is true for the case of DC (which we will discuss in this article), as well as for ISP (which we will not address because it has already been covered in ). With enterprise networks, of course, the situation is somewhat different.
A picture focused on the network:
Underlay
Underlay â Ă«shtĂ« njĂ« rrjet fizik: çswitch-e dhe kabllo hardware. Pajisjet nĂ« underlay dinĂ« si tĂ« arrijnĂ« nĂ« makinat fizike.
Ai mbështetet në protokollet dhe teknologjitë standarde. Jo në mënyrë të fundit, sepse pajisjet hardware vazhdojnë të funksionojnë me softuer të pronësishëm, që nuk lejon as programimin e çipave, as implementimin e protokolleve të tij, përkatësisht është e nevojshme të ketë përputhshmëri me furnizues të tjerë dhe standardizim.
Por dikush si Google mund të krijojë çswitch-e të tij dhe të heqë dorë nga protokollet e pranuara. Por LAN_DC nuk është Google.
Underlay rrallĂ« ndryshohet, sepse detyra e tij Ă«shtĂ« â lidhja bazĂ« IP mes makinave fizike. Underlay nuk di asgjĂ« pĂ«r shĂ«rbimet, klientĂ«t, dhe tenantĂ«t qĂ« funksionojnĂ« mbi tĂ« â ai ka vetĂ«m nevojĂ« tĂ« dorĂ«zojĂ« paketat nga njĂ« makinĂ« nĂ« tjetrĂ«n.
Underlay mund të duket kështu:
- IPv4+OSPF
- IPv6+ISIS+BGP+L3VPN
- L2+TRILL
- L2+STP
Rrjeti Underlay konfigurohet nĂ« mĂ«nyrĂ« klasike: CLI/GUâI/NETCONF.
Duar, skenarë, mjete pronësore.
Një artikull më i detajuar do t'i kushtohet underlay në ciklin e ardhshëm.
Overlay
Overlay â njĂ« rrjet virtual tunelesh, i tendosur mbi Underlay, ai lejon qĂ« VM-tĂ« e njĂ« klienti tĂ« komunikojnĂ« mes tyre, duke siguruar izolim nga klientĂ«t e tjerĂ«.
Të dhënat e klientëve inkapsulohen në ndonjë titull tunelimi për t'u dërguar përmes rrjetit të përbashkët.
Kështu, VM-të e një klienti (një shërbimi) mund të komunikojnë mes tyre përmes Overlay, madje pa e ditur se cila është rruga reale që ndjek paketa.
Overlay mund të duket kështu, siç e përmenda më lart:
- Tuneli GRE
- VXLAN
- EVPN
- L3VPN
- GENEVE
Rrjeti Overlay zakonisht konfigurohet dhe mbështetet përmes një kontroluesi qendror. Nga aty, konfigurimi, Plane Kontrolli dhe Plane Të Dhënave dërgohen te pajisjet që merren me ruterimin dhe inkapsulimin e trafikut të klientëve. Pak do ta analizojmë këtë me shembuj.
Po, kjo është SDN në formën e saj të pastër.
Ekzistojnë dy qasje që ndryshojnë në mënyrë 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 qasjes (ToR), që ndodhet në raft, siç ndodh, për shembull, në rastin e fabrikës VXLAN.
Ky është një mekanizëm i vërtetuar me kalimin e kohës në rrjetet ISP dhe të gjithë furnizuesit e pajisjeve rrjetore e mbështesin.
Megjithatë, në këtë rast, kallëpi ToR duhet të jetë në gjendje të ndajë shërbimet e ndryshme, prandaj administratori i rrjetit duhet të bashkëpunojë në njëfarë mase me administratorët e makinave virtuale dhe të bëjë ndryshimet (ndonëse automatikisht) në konfigurimin e pajisjeve.
Këtu dua të rekomandoj lexuesin në artikullin mbi miqtë tanë të vjetër .
Në këtë përshkruhen në detaje qasjet për ndërtimin e rrjetit të DC me fabrikën EVPN VXLAN.
Dhe për një zhytje më të plotë në realitet, mund të lexoni librin e Cisco .
Dua të theksoj se VXLAN është vetëm një metodë e enkapsulimit dhe terminimi i tuneleve mund të ndodhë jo në ToR, por në host, siç ndodh në rastin e OpenStack, për shembull.
Megjithatë, fabrikën VXLAN, ku overlay fillon në ToR është një nga dizajnet e konsoliduara të rrjetit overlay.
Overlay nga hosti
Qasja tjetër është të filloni dhe të terminoni tunelet në hostet përfundimtare.
Në këtë rast, rrjeti (Underlay) mbetet sa më i thjeshtë dhe statik.
Dhe hosti vetë bën të gjitha enkapsulimet e nevojshme.
Për këtë, pa dyshim, do të nevojitet të ekzistojë një aplikacion i veçantë në hoste, por ia vlen.
SĂ« pari, tĂ« fillosh klientin nĂ« njĂ« makinĂ« Linux Ă«shtĂ« mĂ« e thjeshtĂ« ose, tĂ« themi, e mundur â ndĂ«rsa nĂ« ndSwitch, ndoshta, do tĂ« duhet tĂ« pĂ«rdorĂ«sh ende zgjidhje SDN pronĂ«sore, qĂ« shkatĂ«rron idenĂ« e multi-marrĂ«sisĂ«.
SĂ« dyti, nĂ« kĂ«tĂ« rast, kallĂ«pi ToR mund tĂ« mbetet sa mĂ« i thjeshtĂ«, si nga ana e Plane-control-it ashtu edhe nga ana e Plane-tĂ« dhĂ«nash. NĂ« tĂ« vĂ«rtetĂ« â me kontrolluesin SDN, ai nuk ka nevojĂ« tĂ« komunikojĂ«, dhe tĂ« mbajĂ« rrjetet/ARP-tĂ« e tĂ« gjithĂ« klientĂ«ve tĂ« lidhur â Ă«shtĂ« e mjaftueshme qĂ« tĂ« dije adresĂ«n IP tĂ« makinĂ«s fizike, qĂ« e lehtĂ«son ndjeshĂ«m tabelat e kalimeve/rutave.
Në serinë ADSM zgjedh qasjen e overlay nga hosti - më tej ne do të flasim vetëm për të dhe nuk do të kthehemi më në fabrikën VXLAN.
Më e lehtë është të ilustrohet me shembuj. Dhe si subjekti ne do të marrim platformën Open Source SDN OpenContrail, tani e 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Ă« rrugĂ«zues virtual, i cili di pĂ«r rrjetet e lidhura me tĂ« dhe se cilit klient i pĂ«rkasin ato â nĂ« thelb â njĂ« PE-rutĂ«zues. PĂ«r çdo klient, mbĂ«shtet njĂ« tavĂ« tĂ« izoluar tĂ« rrugĂ«zimit (lexo VRF). Dhe rrugĂ«zuesi vĂ«rtetĂ« bĂ«het tunelimi Overlay.
Pak mĂ« nĂ« detaje pĂ«r rrugĂ«zuesin â nĂ« fund tĂ« artikullit.
Ădo VM, e vendosur mbi hipervizorin, lidhet me rrugĂ«zuesin e kĂ«saj makine pĂ«rmes .
TAP â Terminal Access Point â njĂ« interfejs virtual nĂ« kernelin Linux, i cili lejon ndĂ«rveprimin rrjetor.
NĂ«se pas rrugĂ«zuesit ndodhen disa rrjete, pĂ«r secilin prej tyre krijohet njĂ« interfejs virtual, mbi tĂ« cilin caktohet njĂ« adresĂ« IP â kjo do tĂ« jetĂ« adresa e portit tĂ« parazgjedhur.
TĂ« gjitha rrjetet e njĂ« klienti vendosen nĂ« njĂ« VRF (njĂ« tavĂ«), ato tĂ« ndryshme â nĂ« tĂ« ndryshme.
Këtu do të bëj një sqarim, që nuk është gjithçka kaq e thjeshtë, dhe do ta dërgoj lexuesin kureshtar në fund të artikullit..
Për t'u mundësuar rrugëzuesve të komunikojnë me njëri-tjetrin, dhe për pasojë edhe VM-të që ndodhen pas tyre, ata shkëmbejnë informacionin e rrugëzimit përmes SDN-kontrollerit..
PĂ«r t'u zbĂ«rthyer nĂ« botĂ«n e jashtme, ekziston njĂ« pikĂ«dalje nga matrica â porti i rrjetit virtual VNGW â Virtual Network GateWay (termi im).
Tani le tĂ« shqyrtojmĂ« shembujt e komunikimeve â dhe do tĂ« jetĂ« e qartĂ«.
Komunikimi brenda një makine fizike
VM0 dëshiron të dërgojë një paketë në VM2. Supozojmë për tani, se këto janë VM të një klienti.
Data Plane
- VM0 ka një rrugë të parazgjedhur në interfejsin e tij eth0. Paketa dërgohet atje.
Ky interfejs eth0 në të vërtetë është virtualisht i lidhur me rrugëzuesin virtual vRouter përmes TAP-interfejsit tap0. - Rrugëzuesi analizon se në cilin interfejs ka ardhur paketa, pra për cilin klient (VRF) i takon, dhe krahason adresën e marrësit me tavën e rrugëzimit të këtij klienti.
- Duke zbuluar se marrĂ«si ndodhet nĂ« kĂ«tĂ« makinĂ« pĂ«r caqet e ndryshme, rrugĂ«zuesi thjesht dĂ«rgon paketĂ«n nĂ« tĂ« pa ndonjĂ« titull shtesĂ« â pĂ«r kĂ«tĂ« rast, rrugĂ«zuesi ka tashmĂ« njĂ« regjistĂ«r ARP.
Paketa nĂ« kĂ«tĂ« rast nuk i nĂ«nshtrohet rrjetit fizik â ajo Ă«shtĂ« orientuar brenda rrugĂ«zuesit.
Control Plane
Hipervizori, gjatë ndezjes së makinës virtuale, i komunikon asaj:
- Adresën e saj IP.
- RrugĂ«n e parazgjedhur â pĂ«rmes adresĂ«s IP tĂ« rrugĂ«zuesit nĂ« kĂ«tĂ« rrjet.
Rrugëzuesit, përmes një API të veçantë, hipervizori i komunikon:
- ĂfarĂ« duhet tĂ« krijohet si njĂ« interfejs virtual.
- ĂfarĂ« Virtual Network duhet tĂ« krijohet pĂ«r tĂ«.
- Me cilin VRF duhet të lidhet (VN).
- Regjistrimi ARP statik pĂ«r kĂ«tĂ« VM â cilit ndĂ«rfaqe i pĂ«rket adresa e saj IP dhe nĂ« cilit MAC adresa Ă«shtĂ« e lidhur.
Sërish, procedura reale e ndërveprimit është thjeshtuar në funksion të kuptimit të konceptit.
Kështu, të gjitha VM-të e një klienti në këtë makinë vRouter i sheh si rrjete të drejtpërdrejta të lidhura dhe mund të rutesh vetë mes tyre.
Megjithatë, VM0 dhe VM1 i përkasin klientëve të ndryshëm, përkatësisht, ndodhen në tabela të ndryshme të vRouter-it.
A do të mund të komunikojnë drejtpërdrejt me njëri-tjetrin varet nga konfigurimet e vRouter dhe dizajni i rrjetit.
Për shembull, nëse të dy VM-të e klientëve përdorin adresa publike, ose NAT ndodh në vetë vRouter, atëherë mund të bëhet edhe një rruge e drejtpërdrejtë në vRouter.
NĂ« situata tĂ« tjera, mund tĂ« ndodhin kryqĂ«zime tĂ« hapĂ«sirave adresave â duhet tĂ« kaloni pĂ«rmes njĂ« serveri NAT qĂ« tĂ« merrni njĂ« adresĂ« publike â kjo duket si njĂ« dalje nĂ« rrjetet e jashtme, pĂ«r tĂ« cilat do tĂ« flasim mĂ« poshtĂ«.
Komunikimi ndërmjet VM-ve të vendosura në makina fizike të ndryshme
Data Plane
- Fillimi është plotësisht i njëjtë: VM-0 dërgon një paketë me adresën e VM-7 (172.17.3.2) sipas parazgjedhjes së saj.
- vRouter e merr atë dhe këtë herë sheh që adresati ndodhet në një makinë tjetër dhe është i aksesueshëm përmes tunelit Tunnel0.
- Fillimisht, ai vendos një etiketë MPLS, që identifikon ndërfaqen e largët, në mënyrë që nga ana tjetër vRouter të mund të përcaktojë se ku duhet të vendoset kjo paketë pa nevojën për lëvizje shtesë.
- Tunnel0 ka burim 10.0.0.2, marrës: 10.0.1.2.
vRouter shton kokat GRE (ose UDP) dhe një IP të re në paketën origjinale. - Në tabelën e rrugës vRouter ka një rrugë përfundimtare përmes adresës ToR1 10.0.0.1. Aty e dërgon.
- ToR1 si pjesë e rrjetit Underlay e di (për shembull, përmes OSPF) se 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ë ilustro, ka dy next-hop dhe fluxet e ndryshme do të shpërndahen në to sipas hash-it. Në rastin e një fabrike reale, do të kishte me shumë se 4 next-hop.
Në të njëjtën kohë, ai nuk ka nevojë të dijë se çfarë ndodhet nën kokën e jashtme IP. Pra, faktikisht nën IP mund të jetë një sanduiç nga IPv6 mbi MPLS mbi Ethernet mbi MPLS mbi GRE mbi mbi mbi Grek.
- Për pasojë, në anën e pranimit vRouter heq GRE-në dhe përmes etiketës MPLS kupton në cilin ndërfaqe duhet të dorëzojë këtë paketë, e ndan atë dhe e dërgon në formën e saj origjinale te marrësi.
Control Plane
Kur është aktivizuar makina, ndodhin të gjitha ato që janë përshkruar më lart.
Dhe plus edhe kjo:
- Për çdo klient, vRouter i dedikon një etiketë MPLS. Kjo është një etiketë shërbimi L3VPN, sipas së cilës klientët do të ndahen brenda një makine fizike.
NĂ« tĂ« vĂ«rtetĂ«, etiketat MPLS i jepen gjithmonĂ« nga vRouter â sepse nuk dihet paraprakisht se makina do tĂ« ndĂ«rveprojĂ« vetĂ«m me makina tĂ« tjera pas tĂ« njĂ«jtit vRouter dhe ndoshta ashtu nuk Ă«shtĂ«.
- vRouter krijon njĂ« lidhje me SDN-kontrollorin nĂ«pĂ«rmjet protokollit BGP (ose njĂ« protokolli tĂ« ngjashĂ«m â nĂ« rastin e TF, Ă«shtĂ« XMPP 0_o).
- Përmes kësaj seance, vRouter i komunikon SDN-kontrollorit rrugët drejt rrjeteve të lidhura:
- Adresa e rrjetit
- Metoda e kapjes (MPLSoGRE, MPLSoUDP, VXLAN)
- Etiketa MPLS e klientit
- IP-adresa e tij si nexthop
- SDN-kontrollori merr këto rrugë nga të gjithë vRouter-at e lidhur dhe i pasqyron ato për të tjerët. Pra, ai vepron si Route Reflector.
E njëjta gjë ndodh edhe në anën tjetër.
Overlay mund të ndryshojë çdo minutë. Afërsisht ashtu ndodh në re publike, kur klientët rregullisht nisin dhe ndalin makinat e tyre virtuale.
Kontrollori qendror merr përsipër të gjitha vështirësitë me mbështetje të konfigurimit dhe kontrollin e tabelave të komutimit/rutimit në vRouter.
Nëse flasim thjesht, kontrollori lidh të gjitha vRouter-at përmes BGP (ose një protokolli të ngjashëm) dhe thjesht transmeton informacionin e rrugëve. BGP, për shembull, ka tashmë një Address-Family për transmetimin e metodës së kapjes ose .
Në të njëjtën kohë, konfiguracioni i Underlay-rete nuk ndryshon në asnjë mënyrë, që për më tepër, është shumë më e ndërlikuar për t'u automatizuar, ndërsa shkatërrimi i saj me një lëvizje të pakujdesshme është më i lehtë.
Dalja në botën e jashtme
Diku simulimi duhet të përfundojë, dhe nga bota virtuale duhet të dilet në të vërtetë. Dhe nevojitet një taksifon kalimi.
Praktikohen dy qasje:
- Instalohet një router hardware.
- Nis një ndonjë aparat që realizon funksionet e router-it (po, pas SDN-së, ne u përballëm edhe me VNF). Ta quajmë atë kalimi virtual.
Avantazhi i qasjes sĂ« dytĂ« Ă«shtĂ« nĂ« shkallĂ«zimin horizontal tĂ« lirĂ« â nĂ«se fuqia nuk mjafton â nisni njĂ« tjetĂ«r virtual me kalimin. NĂ« çdo makinĂ« fizike, pa nevojĂ«n pĂ«r tĂ« kĂ«rkuar rafte tĂ« lira, njĂ«sitĂ«, linjat e energjisĂ«, blerjen e pajisjeve, transportimin e saj, instalimin, lidhjen, konfiguroj dhe pastaj edhe zĂ«vendĂ«simin e komponenteve tĂ« dĂ«mshme.
MegjithatĂ«, disavantazhet e njĂ« kalimi virtual janĂ« se njĂ« njĂ«si fizike routeri Ă«shtĂ« shumĂ« mĂ« e fuqishme se njĂ« virtual shumĂ«-bĂ«rthamore dhe softueri i saj, i pĂ«rshtatur pĂ«r bazĂ«n e saj harduerike, punon ndjeshĂ«m mĂ« stabilisht (jo). ĂshtĂ« e vĂ«shtirĂ« tĂ« mohohet edhe fakti se kompleksiteti softuerik-harduerik thjesht funksionon, duke kĂ«rkuar vetĂ«m konfigurimin, ndĂ«rsa nisja dhe mbajtja e kalimit virtual Ă«shtĂ« njĂ« aktivitet pĂ«r inxhinierĂ« tĂ« fortĂ«.
Një këmbë e kalimit shikon në rrjetin virtual Overlay, si një Makinë Virtuale e zakonshme, dhe mund të interaktojë me të gjitha VM tjera. Në të njëjtën kohë, ajo mund të përfundojë në vetvete rrjetet e të gjithë klientëve dhe, për pasojë, të realizojë rrugëzimin midis tyre.
Këmbë e tij tjetër shikon në rrjetin kryesor dhe e di se si të dalë në Internet.
Data Plane
Pra, procesi duket kështu:
- VM-0, duke pasur default në të njëjtin vRouter, dërgon një paketë me adresat 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Ă«zimit â gjen rrugĂ«n standarde pĂ«rmes kalimit 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ë fillimisht etiketën MPLS të këtij klienti, e cila pritet nga VNGW1. - vRouter paketizon paketën fillestare në kokat MPLS, GRE dhe IP të re dhe e dërgon në adresën ToR1 10.0.0.1 si default.
- Rrjeti Underlay dërgon paketën te kalimi VNGW1.
- Kalimi VNGW1 heq kokat tuneluese GRE dhe MPLS, sheh adresĂ«n e destinacionit, konsulton tabelĂ«n e tij tĂ« rrugĂ«zimit dhe kupton se ajo Ă«shtĂ« drejtuar pĂ«r nĂ« Internet â domethĂ«nĂ« pĂ«rmes Full View ose Default. NĂ«se Ă«shtĂ« e nevojshme, realizon NAT-translacion.
- Nga VNGW deri te bordi mund të ketë një rrjet IP të zakonshëm, që është e papërfillshme.
Mund të jetë një rrjet klasik MPLS (IGP+LDP/RSVP TE), mund të jetë një fabrikë e kundërt me BGP LU ose një tunel GRE nga VNGW deri te bordi përmes rrjetit IP.
ĂfarĂ«do qĂ« tĂ« ndodhĂ«, VNGW1 realizon inkapsulimet e nevojshme dhe dĂ«rgon paketĂ«n fillestare nĂ« drejtim tĂ« bordit.
Trafiku në drejtimin e kundërt kalon të njëjtat hapa në rendin e kundërt.
- Bordi dërgon paketën deri te VNGW1.
- Ai e heq, shikon adresën e marrësit dhe sheh se ai është i aksesueshëm përmes tunelit Tunnel1 (MPLSoGRE ose MPLSoUDP).
- Për rrjedhojë, vendos etiketën MPLS, kokën GRE/UDP dhe IP të ri dhe e dërgon në ToR3 10.0.255.1.
Adresa e destinacionit tĂ« tunelit â IP adresa e vRouter-it, pas tĂ« cilit qĂ«ndron VM-ja e synuar â 10.0.0.2. - Rrjeti underlay dĂ«rgon paketĂ«n te vRouter-i i duhur.
- vRouter-i i synuar nxjerr GRE/UDP, përcakton interfacin nëpërmjet MPLS-it dhe dërgon paketën e pastër IP në interfacin e tij TAP, të lidhur me eth0 VM-së.
Control Plane
VNGW1 vendos një fqinjësi BGP me SDN-kontrollerin, nga i cili merr të gjitha informacionet për rrugët lidhur me klientët: cilës IP adresë (vRouter) është cilit klient, dhe me cilën MPLS-të përkufizohet ai.
Po ashtu, ai vetë i raporton SDN-kontrollerit rrugën default me etiketën e këtij klienti, duke u shënuar si nexthop. Më pas, ky default arrin në vRouter-a.
Në VNGW zakonisht ndodh agregimi i rrugëve ose përkthimi NAT.
Dhe në anën tjetër, në seancën me border-a ose Route Reflector-a ai jep saktësisht këtë rrugë të agreguar. Dhe prej tyre merr ose rrugën e zakonshme ose Full-View, ose diçka tjetër.
Në planin e inkapsulimit dhe shkëmbimit të trafikut, VNGW nuk ndryshon nga vRouter.
Nëse e zgjeroni pak fushën, atëherë VNGW dhe vRouter-at mund të shtohen me pajisje të tjera rrjetesh, si firewall-a, fermat e pastrimit ose përmirësimit të trafikut, IPS dhe të tjera.
Dhe me ndihmën e krijimit të renditshëm të VRF dhe shpalljes së duhur të rrugëve, mund të bëni që trafiku të bëjë cikle ashtu si ju dëshironi, që quhet Service Chaining.
Pra, edhe këtu SDN-kontrolleri vepron si Route-Reflector midis VNGW, vRouter-ave dhe pajisjeve të tjera rrjetesh.
Por në fakt, kontrolleri jep gjithashtu informacion mbi ACL dhe PBR (Rruga e Bazuar në Politika), duke e detyruar rrjedhjen e veçantë të trafikut të mos ndiqte rrugën siç e thotë rruga.
FAQ
Pse gjithmonë bën këtë shënim GRE/UDP?
Epo, nĂ« tĂ« vĂ«rtetĂ«, kjo Ă«shtĂ« specifike pĂ«r Tungsten Fabric â mund tĂ« mos e konsiderosh fare.
Por nëse e merrni, vetë TF, akoma duke qenë OpenContrail, mbështeste të dy inkapsulimet: MPLS in GRE dhe MPLS in UDP.
UDP është i mirë sepse në Portin e Burimit në titullin e tij është shumë e lehtë të kodosh një funksion hash nga IP+Proto+Port fillestar, gjë që do të lejojë balancimin.
NĂ« rastin e GRE, fatkeqĂ«sisht, ka vetĂ«m titujt e jashtĂ«m IP dhe GRE, tĂ« cilĂ«t janĂ« tĂ« njĂ«jtĂ« pĂ«r tĂ« gjithĂ« trafikun e inkapsuluar dhe flet pĂ«r balancimin nuk Ă«shtĂ« çështje â pak kush mund tĂ« shikojĂ« aq thellĂ« brenda paketĂ«s.
Derisa mbërritshme, ruterët, edhe nëse dinin për tunelë dinamikë, e bënin këtë vetëm me MPLSoGRE, dhe vetëm së fundi mësuan për MPLSoUDP. Prandaj, gjithmonë duhet të theksoj mundësinë e dy enkapsulimeve të ndryshme.
Për të qenë të drejtë, merret parasysh se TF e përkrah plotësisht edhe lidhshmërinë L2 me ndihmën e VXLAN.
Ti e premtove të bësh paralela me OpenFlow.
Ato vërtet i ngjasojnë. vSwitch në të njëjtin OpenStack bën gjëra shumë të ngjashme, duke përdorur VXLAN, i cili, për fat të keq, gjithashtu ka një header UDP.
Në Data Plane ato funksionojnë përafërsisht në të njëjtën mënyrë, por Control Plane ndryshon ndjeshëm. Tungsten Fabric përdor XMPP për të dërguar informacionin mbi rrugët tek vRouter, ndërsa në OpenStack funksionon OpenFlow.
A mund të flasim pak më shumë për vRouter-in?
Ai ndahet në dy pjesë: vRouter Agent dhe vRouter Forwarder.
E para aktivizohet në User Space të sistemit operativ pritës dhe komunikon me SDN-controller-in, duke shkëmbyer informacion mbi rrugët, VRF dhe ACL.
E dyta realizon Data Plane â zakonisht nĂ« Kernel Space, por gjithashtu mund tĂ« aktivizohet dhe nĂ« SmartNIC-at â karta rrjeti me CPU dhe njĂ« çip tĂ« veçantĂ« programues pĂ«r ndĂ«rlidhje, qĂ« ndihmon pĂ«r tĂ« hequr ngarkesĂ«n nga CPU i makinĂ«s pritĂ«se dhe bĂ«n rrjetin mĂ« tĂ« shpejtĂ« dhe mĂ« tĂ« parashikueshĂ«m.
Gjithashtu është e mundshme një skenar ku vRouter është një aplikacion DPDK në User Space.
vRouter Agent dërgon konfigurimet tek vRouter Forwarder.
ĂfarĂ« Ă«shtĂ« Rrjeti Virtual?
E përmenda 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ërfaqshëm të funksionit të rrjetës ovrlyed ishte e mjaftueshme, në iteratën tjetër duhet bërë sqarimet.
Zakonisht, nĂ« mekanizmat e virtualizimit, entiteti Rrjeti Virtual (mund ta konsideroni si emrin e pronarit) Ă«shtĂ« i ndarĂ« nga klientĂ«t/tenantĂ«t/makinat virtuale â njĂ« gjĂ« krejtĂ«sisht e pavarur. Ky Rrjet Virtual mund tĂ« lidhet pĂ«rmes ndĂ«rfaqeve nĂ« njĂ« tenant, nĂ« tjetrin, nĂ« dy, deri ku tĂ« duash. KĂ«shtu, pĂ«r shembull, realizohet Service Chaining, kur trafik duhet tĂ« kalojĂ« pĂ«rmes node-ve tĂ« caktuara nĂ« rendin e duhur, duke krijuar dhe lidhur Rrjetet Virtuale nĂ« rendin e duhur.
Prandaj, siç qëndron, nuk ka ndonjë përputhje të drejtpërdrejtë midis Rrjetit Virtual dhe tenantit.
PĂ«rfundim
Ky është një përshkrim shumë sipërfaqësor i funksionimit të rrjetit virtual me overlay nga një host dhe kontrolluesi SDN. Por cila do qoftë platforma e virtualizimit që merrni sot, do të funksionojë në mënyrë të ngjashme, qoftë VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric apo Juniper Contrail. Ato do të ndryshojnë në llojet e enkapsulimeve dhe kryerësave, protokolleve të shpërndarjes së informacionit në pajisjet finale të rrjetit, por principi i rrjetit me overlay të programuar mbi një rrjet të thjeshtë dhe statik të mbulimit do të mbetet i njëjtë.
Mund tĂ« thuhet se nĂ« fushĂ«n e krijimit tĂ« njĂ« Cloud tĂ« privatizuar, sot SDN e bazuar nĂ« rrjetin overlay ka fituar. MegjithatĂ«, kjo nuk do tĂ« thotĂ« se Openflow nuk ka vend nĂ« botĂ«n moderne â ai pĂ«rdoret nĂ« OpenStack dhe po ashtu nĂ« VMWare NSX, dhe sa kam dijeni, Google e pĂ«rdor atĂ« pĂ«r tĂ« konfiguruar rrjetin e mbulimit.
Pak më poshtë kam përfshirë lidhjet në materiale më të detajuara, nëse dëshiron të hulumtosh më thellë.
Por çfarë ndodh me Underlay-n tonë?
Në përgjithësi, asgjë. Ai nuk ka ndryshuar gjatë gjithë kohës. Gjithçka që i nevojitet në rastin e overlay-it nga hosti është të përditësojë rrugët dhe ARP-të ndërsa vRouter/VNGW shfaqen dhe zhduken, dhe të transportojë paketat ndërmjet tyre.
Le të formulojmë një listë kërkesash për rrjetin Underlay.
- TĂ« jetĂ« i aftĂ« nĂ« njĂ« protokoll rrugĂ«timi, nĂ« situatĂ«n tonĂ« â BGP.
- Të ketë një gjerësi të madhe, preferohet pa shfrytëzim të tepruar, për të mos humbur paketat për shkak të mbingarkesave.
- TĂ« mbĂ«shtesĂ« ECMP â njĂ« pjesĂ« e pandashme e fabrikĂ«s.
- Të jetë në gjendje të sigurojë QoS, duke përfshirë gjëra të komplikuara, siç është ECN.
- TĂ« mbĂ«shtesĂ« NETCONF â njĂ« hap nĂ« tĂ« ardhmen.
Kam kushtuar pak kohë funksionimit të vetë rrjetit Underlay. Kjo është sepse në vazhdim të serisë, unë do të përqendrohem pikërisht aty, ndërsa Overlay do ta prekim vetëm në mënyrë të sipërme.
Padyshim, po e kufizoj shumë vetë duke përdorur si shembull rrjetin e Qendrës së Dhënave, i ndërtuar mbi fabrikën Clos me rrugëtim të pastruar IP dhe overlay nga hosti.
Megjithatë, jam i sigurt se çdo rrjet me dizajn mund të përshkruhet në terma formale dhe të automatizohet. Thjesht këtu po ndjek synimin për të kuptuar qasjet ndaj automatizimit, dhe jo për të ngatërruar të gjithë duke zgjidhur problemin në një formë të përgjithshme.
Në kuadër të ADSN, ne dhe Roman Gorga planifikojmë të publikojmë një edicion të veçantë mbi virtualizimin e kapaciteteve kompjuterike dhe ndërveprimin e saj me virtualizimin e rrjetit. Qëndroni të lidhur.
Useful links
- .
- . 6 orë për Yandex.Cloud, ku përfshihet gjithashtu rrjeti virtual në TF.
- .
- . Këtu përshkruhet e gjithë rrjeti i DC, duke përfshirë Underlay, Overlay, qasjet për multi-homing dhe menaxhimin.
Faleminderit
- â ish-aspirant i podkastit linkmeup, tani ekspert nĂ« fushĂ«n e platformave cloud. FalĂ«nderime pĂ«r komentet dhe korrigjimet. Dhe presim nĂ« tĂ« ardhmen njĂ« artikull mĂ« tĂ« thellĂ« mbi virtualizimin.
- â kolegu im dhe ekspert nĂ« fushĂ«n e zhvillimit tĂ« rrjeteve virtuale. FalĂ«nderime pĂ«r komentet dhe korrigjimet.
- â kolegu im dhe ekspert nĂ« fushĂ«n e Tungsten Fabric. FalĂ«nderime pĂ«r komentet dhe korrigjimet.
- â ilustrator i linkmeup. FalĂ«nderime pĂ«r KDPV.
- Aleksandër Limonov. Falënderime për memin «automato».
Burimi: habr.com
