Lai apspriestu VXLAN vārtejas, vispirms jāapspriež pats VXLAN. Atcerieties, ka tradicionālie VLAN (virtuālie lokālie tīkli) izmanto 12 bitu VLAN ID, lai sadalītu tīklus, atbalstot līdz pat 4096 loģiskajiem tīkliem. Tas labi darbojas mazos tīklos, taču mūsdienu datu centros ar tūkstošiem virtuālo mašīnu, konteineru un daudznomnieku vidēm VLAN ir nepietiekami. VXLAN radās, un to definēja Interneta inženierijas uzdevumu grupa (IETF) RFC 7348. Tā mērķis ir paplašināt 2. slāņa (Ethernet) apraides domēnu 3. slāņa (IP) tīklos, izmantojot UDP tuneļus.
Vienkārši sakot, VXLAN iekapsulē Ethernet kadrus UDP paketēs un pievieno 24 bitu VXLAN tīkla identifikatoru (VNI), teorētiski atbalstot 16 miljonus virtuālo tīklu. Tas ir līdzīgi kā katram virtuālajam tīklam piešķirt "identifikācijas karti", kas ļauj tiem brīvi pārvietoties fiziskajā tīklā, netraucējot vienam otram. VXLAN galvenā sastāvdaļa ir VXLAN tuneļa gala punkts (VTEP), kas ir atbildīgs par pakešu iekapsulēšanu un dekapsulēšanu. VTEP var būt programmatūra (piemēram, Open vSwitch) vai aparatūra (piemēram, ASIC mikroshēma uz slēdža).
Kāpēc VXLAN ir tik populārs? Tāpēc, ka tas lieliski atbilst mākoņdatošanas un SDN (programmatūras definētas tīklošanas) vajadzībām. Publiskos mākoņos, piemēram, AWS un Azure, VXLAN nodrošina nemanāmu nomnieku virtuālo tīklu paplašināšanu. Privātos datu centros tas atbalsta pārklājuma tīkla arhitektūras, piemēram, VMware NSX vai Cisco ACI. Iedomājieties datu centru ar tūkstošiem serveru, katrā no kuriem darbojas desmitiem virtuālo mašīnu (VM). VXLAN ļauj šīm virtuālajām mašīnām uztvert sevi kā daļu no viena 2. slāņa tīkla, nodrošinot vienmērīgu ARP apraides un DHCP pieprasījumu pārraidi.
Tomēr VXLAN nav panaceja. Darbībai L3 tīklā ir nepieciešama L2-L3 konvertēšana, un tieši šeit noder vārteja. VXLAN vārteja savieno VXLAN virtuālo tīklu ar ārējiem tīkliem (piemēram, tradicionālajiem VLAN vai IP maršrutēšanas tīkliem), nodrošinot datu plūsmu no virtuālās pasaules uz reālo pasauli. Pāradresācijas mehānisms ir vārtejas sirds un dvēsele, kas nosaka, kā paketes tiek apstrādātas, maršrutētas un izplatītas.
VXLAN pāradresācijas process ir kā delikāts balets, kurā katrs solis no avota līdz galamērķim ir cieši saistīts. Apskatīsim to soli pa solim.
Vispirms no avota resursdatora (piemēram, virtuālās mašīnas) tiek nosūtīta pakete. Šis ir standarta Ethernet kadrs, kas satur avota MAC adresi, mērķa MAC adresi, VLAN tagu (ja tāds ir) un vērtumu. Saņemot šo kadru, avota VTEP pārbauda mērķa MAC adresi. Ja mērķa MAC adrese ir tā MAC tabulā (iegūta, izmantojot mācīšanos vai pārpludināšanu), tas zina, kuram attālajam VTEP pārsūtīt paketi.
Iekapsulēšanas process ir ļoti svarīgs: VTEP pievieno VXLAN galveni (ieskaitot VNI, karodziņus utt.), pēc tam ārējo UDP galveni (ar avota portu, kas balstīts uz iekšējā kadra jaucējkodu, un fiksētu mērķa portu 4789), IP galveni (ar lokālā VTEP avota IP adresi un attālā VTEP mērķa IP adresi) un visbeidzot ārējo Ethernet galveni. Tagad visa pakete tiek parādīta kā UDP/IP pakete, izskatās kā parasta datplūsma un to var maršrutēt L3 tīklā.
Fiziskajā tīklā paketi pārsūta maršrutētājs vai komutators, līdz tā sasniedz mērķa VTEP. Mērķa VTEP noņem ārējo galveni, pārbauda VXLAN galveni, lai pārliecinātos par VNI sakritību, un pēc tam piegādā iekšējo Ethernet kadru mērķa resursdatoram. Ja pakete ir nezināma uniraides, apraides vai multiraides (BUM) datplūsma, VTEP replicē paketi visiem attiecīgajiem VTEP, izmantojot pārpludināšanu, paļaujoties uz multiraides grupām vai uniraides galvenes replikāciju (HER).
Pāradresācijas principa pamatā ir vadības plaknes un datu plaknes atdalīšana. Vadības plakne izmanto Ethernet VPN (EVPN) vai Flood and Learn mehānismu, lai apgūtu MAC un IP kartējumus. EVPN ir balstīts uz BGP protokolu un ļauj VTEP apmainīties ar maršrutēšanas informāciju, piemēram, MAC-VRF (virtuālā maršrutēšana un pāradresācija) un IP-VRF. Datu plakne ir atbildīga par faktisko pāradresāciju, izmantojot VXLAN tuneļus efektīvai pārraidei.
Tomēr faktiskajās izvietošanās reizēs pārsūtīšanas efektivitāte tieši ietekmē veiktspēju. Tradicionālie pārsūtīšanas procesi var viegli izraisīt apraides vētras, īpaši lielos tīklos. Tas rada nepieciešamību pēc vārteju optimizācijas: vārtejas ne tikai savieno iekšējos un ārējos tīklus, bet arī darbojas kā ARP starpniekserveri, apstrādā maršruta noplūdes un nodrošina īsākos pārsūtīšanas ceļus.
Centralizēta VXLAN vārteja
Centralizēta VXLAN vārteja, ko sauc arī par centralizētu vārteju vai L3 vārteju, parasti tiek izvietota datu centra malā vai kodola slānī. Tā darbojas kā centrālais mezgls, caur kuru jāiziet visai starp-VNI vai starp-apakštīklu datplūsmai.
Principā centralizēta vārteja darbojas kā noklusējuma vārteja, nodrošinot 3. slāņa maršrutēšanas pakalpojumus visiem VXLAN tīkliem. Apsveriet divus VNI: VNI 10000 (apakštīkls 10.1.1.0/24) un VNI 20000 (apakštīkls 10.2.1.0/24). Ja VM A VNI 10000 vēlas piekļūt VM B VNI 20000, pakete vispirms sasniedz lokālo VTEP. Lokālais VTEP nosaka, ka mērķa IP adrese neatrodas lokālajā apakštīklā, un pārsūta to uz centralizēto vārteju. Vārteja dekapsulē paketi, pieņem maršrutēšanas lēmumu un pēc tam atkārtoti iekapsulē paketi tunelī uz mērķa VNI.
Priekšrocības ir acīmredzamas:
○ Vienkārša pārvaldībaVisas maršrutēšanas konfigurācijas ir centralizētas vienā vai divās ierīcēs, ļaujot operatoriem uzturēt tikai dažus vārtejus, lai aptvertu visu tīklu. Šī pieeja ir piemērota maziem un vidējiem datu centriem vai vidēm, kas pirmo reizi ievieš VXLAN.
○Resursu ziņā efektīvsVārtejas parasti ir augstas veiktspējas aparatūra (piemēram, Cisco Nexus 9000 vai Arista 7050), kas spēj apstrādāt milzīgu datplūsmas apjomu. Vadības plakne ir centralizēta, kas atvieglo integrāciju ar SDN kontrolleriem, piemēram, NSX Manager.
○Spēcīga drošības kontroleSatiksmei ir jāiziet cauri vārtejai, kas atvieglo ACL (piekļuves kontroles sarakstu), ugunsmūru un NAT ieviešanu. Iedomājieties vairāku nomnieku scenāriju, kurā centralizēta vārteja var viegli izolēt nomnieku datplūsmu.
Taču trūkumus nevar ignorēt:
○ Viena kļūmes punktaJa vārteja neizdodas, L3 komunikācija visā tīklā tiek paralizēta. Lai gan VRRP (Virtual Router Redundancy Protocol) var izmantot redundances nodrošināšanai, tas joprojām rada riskus.
○Veiktspējas sašaurinājumsVisai austrumu-rietumu virziena datplūsmai (saziņai starp serveriem) jāapiet vārteja, kā rezultātā ceļš nav optimāls. Piemēram, 1000 mezglu klasterī, ja vārtejas joslas platums ir 100 Gb/s, sastrēgumi, visticamāk, radīsies pīķa stundās.
○Slikta mērogojamībaPieaugot tīkla mērogam, vārteju slodze palielinās eksponenciāli. Kā reālu piemēru esmu redzējis finanšu datu centru, kas izmanto centralizētu vārteju. Sākotnēji tas darbojās nevainojami, bet pēc tam, kad virtuālo mašīnu skaits dubultojās, latentums strauji pieauga no mikrosekundēm līdz milisekundēm.
Lietojuma scenārijs: Piemērots vidēm, kurās nepieciešama augsta pārvaldības vienkāršība, piemēram, uzņēmumu privātajiem mākoņiem vai testēšanas tīkliem. Cisco ACI arhitektūra bieži izmanto centralizētu modeli apvienojumā ar lapu-mugurkaula topoloģiju, lai nodrošinātu galveno vārteju efektīvu darbību.
Izplatītā VXLAN vārteja
Izkliedēta VXLAN vārteja, kas pazīstama arī kā izkliedēta vārteja vai jebkuras pārraides vārteja, nodod vārtejas funkcionalitāti katram lapu komutatoram vai hipervizoram VTEP. Katrs VTEP darbojas kā lokāla vārteja, apstrādājot L3 pāradresāciju lokālajam apakštīklam.
Princips ir elastīgāks: katrs VTEP tiek konfigurēts ar to pašu virtuālo IP adresi (VIP) kā noklusējuma vārteja, izmantojot Anycast mehānismu. VM nosūtītās starpapakštīklu paketes tiek maršrutētas tieši lokālajā VTEP, neizejot caur centrālo punktu. EVPN šeit ir īpaši noderīgs: izmantojot BGP EVPN, VTEP apgūst attālo resursdatoru maršrutus un izmanto MAC/IP saistīšanu, lai izvairītos no ARP pārslodzes.
Piemēram, VM A (10.1.1.10) vēlas piekļūt VM B (10.2.1.10). VM A noklusējuma vārteja ir lokālās VTEP (10.1.1.1) VIP. Lokālā VTEP maršrutē uz mērķa apakštīklu, iekapsulē VXLAN paketi un nosūta to tieši VM B VTEP. Šis process samazina ceļu un latentumu.
Izcilas priekšrocības:
○ Augsta mērogojamībaVārtejas funkcionalitātes izplatīšana katrā mezglā palielina tīkla lielumu, kas ir izdevīgi lielākiem tīkliem. Lieli mākoņpakalpojumu sniedzēji, piemēram, Google Cloud, izmanto līdzīgu mehānismu, lai atbalstītu miljoniem virtuālo mašīnu.
○Izcila veiktspējaAustrumu-rietumu virziena datplūsma tiek apstrādāta lokāli, lai izvairītos no sastrēgumiem. Testa dati liecina, ka izkliedētajā režīmā caurlaidspēja var palielināties par 30–50 %.
○Ātra kļūmju novēršanaViena VTEP kļūme ietekmē tikai lokālo resursdatoru, neietekmējot citus mezglus. Apvienojumā ar EVPN ātro konverģenci atkopšanas laiks ir sekundēs.
○Resursu lietderīga izmantošanaIzmantojiet esošo Leaf slēdža ASIC mikroshēmu aparatūras paātrināšanai, pārsūtīšanas ātrumam sasniedzot Tbps līmeni.
Kādi ir trūkumi?
○ Sarežģīta konfigurācijaKatram VTEP ir nepieciešama maršrutēšanas, EVPN un citu funkciju konfigurācija, kas sākotnējo izvietošanu padara laikietilpīgu. Operāciju komandai ir jāpārzina BGP un SDN.
○Augstas aparatūras prasībasSadalītā vārteja: Ne visi komutatori atbalsta sadalītās vārtejas; nepieciešamas Broadcom Trident vai Tomahawk mikroshēmas. Programmatūras ieviešanas (piemēram, OVS uz KVM) nedarbojas tik labi kā aparatūra.
○Konsekvences izaicinājumiIzplatīts nozīmē, ka stāvokļa sinhronizācija balstās uz EVPN. Ja BGP sesija svārstās, tas var radīt maršrutēšanas melno caurumu.
Lietojuma scenārijs: Lieliski piemērots hiperskalas datu centriem vai publiskiem mākoņiem. Tipisks piemērs ir VMware NSX-T izkliedētais maršrutētājs. Apvienojumā ar Kubernetes tas nemanāmi atbalsta konteineru tīklošanu.
Centralizēta VxLAN vārteja salīdzinājumā ar izkliedētu VxLAN vārteju
Tagad nonāksim pie kulminācijas: kurš ir labāks? Atbilde ir "tas atkarīgs no situācijas", taču, lai jūs pārliecinātu, mums ir jāiedziļinās datos un gadījumu izpētē.
No veiktspējas viedokļa izkliedētās sistēmas nepārprotami pārspēj rezultātus. Tipiskā datu centra etalonā (pamatojoties uz Spirent testa iekārtām) centralizētās vārtejas vidējais latentums bija 150 μs, savukārt izkliedētās sistēmas latentums bija tikai 50 μs. Runājot par caurlaidspēju, izkliedētās sistēmas var viegli panākt līnijas ātruma pāradresāciju, jo tās izmanto Spine-Leaf Equal Cost Multi-Path (ECMP) maršrutēšanu.
Mērogojamība ir vēl viens cīņas lauks. Centralizēti tīkli ir piemēroti tīkliem ar 100–500 mezgliem; ārpus šī mēroga izkliedēti tīkli gūst virsroku. Piemēram, Alibaba Cloud. Viņu VPC (virtuālais privātais mākonis) izmanto izkliedētas VXLAN vārtejas, lai atbalstītu miljoniem lietotāju visā pasaulē ar viena reģiona latentumu, kas ir mazāks par 1 ms. Centralizēta pieeja jau sen būtu sabrukusi.
Kā ar izmaksām? Centralizēts risinājums piedāvā zemākas sākotnējās investīcijas, un tam nepieciešami tikai daži augstas klases vārtejas. Izkliedētam risinājumam ir nepieciešams, lai visi lapu mezgli atbalstītu VXLAN atslodzi, kas noved pie augstākām aparatūras jaunināšanas izmaksām. Tomēr ilgtermiņā izkliedēts risinājums piedāvā zemākas ekspluatācijas un uzturēšanas izmaksas, jo automatizācijas rīki, piemēram, Ansible, nodrošina partijveida konfigurāciju.
Drošība un uzticamība: Centralizētas sistēmas veicina centralizētu aizsardzību, taču rada augstu atsevišķu uzbrukuma punktu risku. Izkliedētās sistēmas ir noturīgākas, taču tām ir nepieciešama stabila vadības plakne, lai novērstu DDoS uzbrukumus.
Reālas dzīves gadījuma izpēte: e-komercijas uzņēmums savas vietnes izveidei izmantoja centralizētu VXLAN. Pīķa periodos vārtejas centrālā procesora noslodze pieauga līdz 90%, izraisot lietotāju sūdzības par latentumu. Pāreja uz izkliedētu modeli atrisināja problēmu, ļaujot uzņēmumam viegli dubultot savu darbības apjomu. Turpretī neliela banka uzstāja uz centralizētu modeli, jo tā prioritizēja atbilstības auditus un uzskatīja, ka centralizēta pārvaldība ir vienkāršāka.
Kopumā, ja meklējat ārkārtēju tīkla veiktspēju un mērogu, izkliedēta pieeja ir pareizā izvēle. Ja jūsu budžets ir ierobežots un vadības komandai trūkst pieredzes, centralizēta pieeja ir praktiskāka. Nākotnē, attīstoties 5G un perifērijas skaitļošanai, izkliedēti tīkli kļūs populārāki, taču centralizēti tīkli joprojām būs vērtīgi īpašos scenārijos, piemēram, filiāļu savienošanai.
Mylinking™ tīkla pakešu brokeriatbalsta VxLAN, VLAN, GRE, MPLS galvenes noņemšanu
Atbalstīja VxLAN, VLAN, GRE, MPLS galvenes noņemšanu no sākotnējā datu paketes un pārsūtītās izvades.
Publicēšanas laiks: 2025. gada 9. oktobris
