Vlerësoni lidhjet në pjesën qendrore të skemës. Më poshtë do t'u kthehemi atyre.
Në një moment mund të përballeni me faktin se rrjetet e mëdha dhe komplekse të ndërtuara mbi L2 janë të dëmtuara në mënyrë të pakthyeshme. Së pari, për shkak të problemeve që lidhen me përpunimin e trafikut BUM dhe funksionimin e protokollit STP. Së dyti, për shkak të një arkitekture që, në tërësi, është moralisht e vjetëruar. Kjo sjell probleme të pakëndshme si ndërprerje të shërbimit dhe vështirësi në menaxhim.
Kishim dy projekte paralele, ku klientët vlerësuan me realizëm të gjitha avantazhet dhe disavantazhet e opsioneve dhe zgjodhën dy zgjidhje të ndryshme overlay, ndërsa ne i implementuam ato.
Kishte mundësi të krahasonim pikërisht implementimin. Jo funksionimin në prodhim, për të cilin ia vlen të flitet pas dy ose tre vitesh.
Pra, çfarë është një fabrikë rrjeti me rrjete overlay dhe SDN?
ĂfarĂ« duhet bĂ«rĂ« me problemet e kahershme tĂ« arkitekturĂ«s klasike tĂ« rrjetit?
Ădo vit shfaqen teknologji dhe ide tĂ« reja. NĂ« praktikĂ«, nevoja urgjente pĂ«r tĂ« rindĂ«rtuar rrjetet nuk u ndje pĂ«r njĂ« kohĂ« tĂ« gjatĂ«, sepse shumĂ« gjĂ«ra mund tĂ« bĂ«heshin ende manualisht, me metodat e vjetra tĂ« provuara. Po ç'rĂ«ndĂ«si ka qĂ« jemi nĂ« shekullin e njĂ«zet e njĂ«? NĂ« fund tĂ« fundit, administratori duhet tĂ« punojĂ«, jo tĂ« rrijĂ« nĂ« zyrĂ«n e vet.
Më pas filloi bumi i ndërtimit të qendrave të mëdha të të dhënave. Atëherë u bë e qartë se arkitektura klasike kishte arritur kufijtë e saj të zhvillimit jo vetëm për sa i përket funksionimit, qëndrueshmërisë ndaj dështimeve dhe shkallëzueshmërisë. Dhe një nga mënyrat për t'i zgjidhur këto sfida u bë ideja e ndërtimit të rrjeteve overlay mbi një backbone të routuar.
Përveç kësaj, me rritjen e shkallës së rrjeteve, u shfaq me mprehtësi problemi i menaxhimit të fabrikave të tilla, si rezultat i të cilit nisën të shfaqeshin zgjidhje të rrjeteve të përcaktuara me softuer, me mundësinë për të menaxhuar të gjithë infrastrukturën e rrjetit si një tërësi të vetme. Dhe kur rrjeti menaxhohet nga një pikë e vetme, komponentët e tjerë të infrastrukturës IT e kanë më të lehtë të ndërveprojnë me të, ndërsa procese të tilla ndërveprimi automatizohen më lehtë.
Pothuajse çdo prodhues i madh, jo vetëm i pajisjeve të rrjetit por edhe i virtualizimit, ka në portofolin e vet variante të tilla zgjidhjesh.
Mbetet vetëm të kuptohet se çfarë i përshtatet secilës nevojë. Për shembull, për kompani shumë të mëdha me një ekip të fortë zhvillimi dhe operimi, zgjidhjet standarde nga vendorët jo gjithmonë i mbulojnë të gjitha kërkesat, ndaj ato kalojnë në zhvillimin e zgjidhjeve të veta SD (software defined). Kjo ndodh, për shembull, te ofruesit cloud që e zgjerojnë vazhdimisht gamën e shërbimeve për klientët e tyre, ndërsa zgjidhjet standarde thjesht nuk arrijnë të ecin me ritmin e nevojave të tyre.
Për kompanitë e mesme, funksionaliteti që ofrohet nga vendori si zgjidhje standarde mjafton në 99 për qind të rasteve.
ĂfarĂ« janĂ« rrjetet overlay
Cila është ideja e rrjeteve overlay? Në thelb, merret një rrjet klasik i rutueshëm dhe mbi të ndërtohet edhe një rrjet tjetër për të përfituar më shumë funksione. Më shpesh bëhet fjalë për shpërndarje më efikase të ngarkesës në pajisje dhe linja komunikimi, rritje të ndjeshme të kufirit të shkallëzueshmërisë, rritje të besueshmërisë dhe shumë përfitime në siguri (falë segmentimit). Ndërsa zgjidhjet SDN, përveç kësaj, ofrojnë administrim shumë, shumë, shumë të përshtatshëm dhe fleksibël, si edhe e bëjnë rrjetin më transparent për përdoruesit e tij.
Me pak fjalë, sikur rrjetet lokale të ishin shpikur diku në vitet 2010, ato do të dukeshin krejt ndryshe nga ajo që na ka mbetur trashëgim nga ushtria e viteve 1970.
Nga pikëpamja e teknologjive për ndërtimin e fabric me përdorimin e rrjeteve overlay, aktualisht ekzistojnë shumë implementime nga prodhues të ndryshëm dhe projekte interneti RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve dhe të tjera). Po, ka standarde, por zbatimi i këtyre standardeve nga prodhues të ndryshëm mund të ndryshojë, prandaj gjatë ndërtimit të këtyre fabric-ve, heqja dorë plotësisht nga vendor lock-in për momentin mbetet e mundur vetëm teorikisht, në letër.
Me zgjidhjet SD, situata Ă«shtĂ« edhe mĂ« e ndĂ«rlikuar, sepse çdo vendor ka vizionin e vet. Ka zgjidhje plotĂ«sisht tĂ« hapura, qĂ« teorikisht mund tâi pĂ«rshtatni dhe zhvilloni vetĂ«, si dhe ka zgjidhje plotĂ«sisht tĂ« mbyllura.
Cisco ofron variantin e vet tĂ« SDN pĂ«r qendrat e tĂ« dhĂ«nave â ACI. Natyrisht, nga kĂ«ndvĂ«shtrimi i zgjedhjes sĂ« pajisjeve tĂ« rrjetit, kjo Ă«shtĂ« njĂ« zgjidhje 100% e mbyllur nga njĂ« prodhues i vetĂ«m, por njĂ«kohĂ«sisht integrohet plotĂ«sisht me sistemet e virtualizimit, containerizimit, sigurisĂ«, orkestrimit, balancuesit e ngarkesĂ«s etj. MegjithatĂ«, nĂ« thelb mbetet njĂ« lloj black box, pa mundĂ«si pĂ«r qasje tĂ« plotĂ« nĂ« tĂ« gjitha proceset e brendshme. Jo tĂ« gjithĂ« klientĂ«t pajtohen me kĂ«tĂ« qasje, sepse bĂ«hesh plotĂ«sisht i varur nga cilĂ«sia e kodit tĂ« zgjidhjes dhe mĂ«nyra si Ă«shtĂ« zbatuar, por nga ana tjetĂ«r prodhuesi ka njĂ« nga ekipet mĂ« tĂ« mira tĂ« mbĂ«shtetjes teknike nĂ« botĂ« dhe njĂ« ekip tĂ« dedikuar qĂ« merret vetĂ«m me kĂ«tĂ« zgjidhje. Si zgjidhje pĂ«r projektin e parĂ« u zgjodh pikĂ«risht Cisco ACI.
Për projektin e dytë u zgjodh një zgjidhje nga Juniper. Edhe ky prodhues ka SDN-në e vet për qendrat e të dhënave, por klienti vendosi të heqë dorë nga implementimi i SDN. Si teknologji për ndërtimin e rrjetit u zgjodh EVPN VXLAN fabric pa përdorimin e kontrollorëve të centralizuar.
Për çfarë nevojitet
Krijimi i një fabric bën të mundur ndërtimin e një rrjeti lehtësisht të shkallëzueshëm, rezistent ndaj dështimeve dhe të besueshëm. Arkitektura (leaf-spine) merr parasysh veçoritë qendrat e të dhënave (rrugët e kalimit të trafikut, minimizimin e vonesave dhe të pikave të ngushta në rrjet). Ndërsa zgjidhjet SD në qendrat e të dhënave lejojnë administrim shumë të përshtatshëm, të shpejtë dhe fleksibël të një fabric të tillë, si dhe integrimin e saj në ekosistemin e qendrës së të dhënave.
Të dy klientët kishin nevojë të ndërtonin qendra rezervë të të dhënave për të siguruar rezistencë ndaj dështimeve; përveç kësaj, trafiku midis qendrave të të dhënave duhej të enkriptohej.
Klienti i parë kishte shqyrtuar tashmë zgjidhje pa fabric si standard të mundshëm për rrjetet e veta, por gjatë testeve pati probleme me përputhshmërinë e STP midis pajisjeve të disa prodhuesve. Kjo shkaktonte ndërprerje që sillnin rënien e shërbimeve. Dhe për klientin kjo ishte kritike.
Cisco ishte tashmë standardi korporativ i klientit. Ata shqyrtuan ACI dhe opsione të tjera dhe vendosën se pikërisht kjo zgjidhje ia vlente. U pëlqeu automatizimi i menaxhimit me një klikim përmes një kontrolluesi të unifikuar. Shërbimet konfigurohen më shpejt dhe menaxhohen më shpejt. Enkriptimin e trafikut vendosën ta siguronin duke aktivizuar MACSec midis komutatorëve IPN dhe SPINE. Në këtë mënyrë arritën të shmangnin ngushticën në formën e një crypto gateway, të kursenin në to dhe të shfrytëzonin maksimalisht gjerësinë e brezit.
Klienti i dytë zgjodhi një zgjidhje pa kontrollues nga Juniper, sepse në qendrën e tyre ekzistuese të të dhënave kishte tashmë një instalim të vogël me implementim të fabricës EVPN VXLAN. Por aty ajo nuk ishte fault-tolerant (përdorej një komutator i vetëm). U mor vendimi të zgjerohej infrastruktura e qendrës kryesore të të dhënave dhe të ndërtohej një fabricë edhe në qendrën rezervë të të dhënave. EVPN ekzistues nuk përdorej plotësisht: encapsulation VXLAN në praktikë nuk aplikohej, pasi të gjithë host-et ishin të lidhur me një komutator të vetëm dhe të gjitha adresat MAC dhe adresat /32 të host-eve ishin lokale; gateway për to ishte po ai komutator dhe nuk kishte pajisje të tjera drejt të cilave duhej të ndërtoheshin tunelet VXLAN. Enkriptimin e trafikut vendosën ta siguronin duke përdorur teknologjinë IPSEC midis firewall-eve (performanca e firewall-eve ishte e mjaftueshme).
Edhe ACI e testuan, por vendosën se për shkak të vendor lock-in do t'u duhej të blinin tepër shumë pajisje, përfshirë zëvendësimin e pajisjeve të reja të blera së fundmi, dhe kjo thjesht nuk kishte kuptim ekonomik. Po, fabrica e Cisco integrohet me gjithçka, por brenda vetë fabricës mund të përdoren vetëm pajisjet e saj.
Nga ana tjetĂ«r, siç u pĂ«rmend mĂ« herĂ«t, njĂ« fabricĂ« EVPN VXLAN nuk mund tĂ« pĂ«rzihet lehtĂ«sisht me çdo vendor fqinj, sepse implementimet e protokollit ndryshojnĂ«. ĂshtĂ« si tĂ« bashkosh Cisco dhe Huawei nĂ« tĂ« njĂ«jtin rrjet: nĂ« dukje standardet janĂ« tĂ« pĂ«rbashkĂ«ta, por nĂ« praktikĂ« do tĂ« duhet shumĂ« punĂ« shtesĂ«. MeqenĂ«se bĂ«hej fjalĂ« pĂ«r njĂ« bankĂ« dhe testet e pĂ«rputhshmĂ«risĂ« do tĂ« zgjatnin shumĂ«, u vendos qĂ« pĂ«r momentin tĂ« blihej pajisje nga i njĂ«jti vendor dhe tĂ« mos ndiqeshin shumĂ« funksionalitete pĂ«rtej bazikes.
Plani i migrimit
Dy qendra të të dhënave të bazuara në ACI:
Organizimi i ndĂ«rveprimit midis qendrave tĂ« tĂ« dhĂ«nave. U zgjodh zgjidhja Multi-Pod â çdo qendĂ«r e tĂ« dhĂ«nave Ă«shtĂ« njĂ« pod. U morĂ«n parasysh kĂ«rkesat pĂ«r shkallĂ«zim sipas numrit tĂ« switch-eve dhe pĂ«r vonesat midis pod-eve (RTT mĂ« pak se 50 ms). U vendos tĂ« mos ndĂ«rtohej njĂ« zgjidhje Multi-Site pĂ«r lehtĂ«si menaxhimi (pĂ«r zgjidhjen Multi-Pod pĂ«rdoret njĂ« ndĂ«rfaqe e vetme menaxhimi, ndĂ«rsa pĂ«r Multi-Site do tĂ« kishte dy ndĂ«rfaqe ose do tĂ« kĂ«rkohej Multi-Site Orchestrator), si edhe sepse nuk kĂ«rkohej rezervim gjeografik i lokacioneve.
Nga këndvështrimi i migrimit të shërbimeve nga rrjeti Legacy, u zgjodh opsioni më transparent: transferimi gradual i VLAN-ve që përputhen me shërbime të caktuara.
Për migrim, për secilin VLAN krijohej EPG-ja përkatëse (End-point-group) në fabric. Fillimisht rrjeti shtrihej midis rrjetit të vjetër dhe fabric përmes L2, më pas, pasi migroheshin të gjithë hostët, gateway kalonte në fabric dhe ndërveprimi i EPG me rrjetin ekzistues realizohej përmes L3OUT; ndërkohë, ndërveprimi midis L3OUT dhe EPG përshkruhej duke përdorur kontrata. Skema e përafërt:
Struktura e përafërt e shumicës së politikave të fabric ACI paraqitet në figurën më poshtë. I gjithë konfigurimi ndërtohet mbi politika të përfshira në politika të tjera, dhe kështu me radhë. Në fillim është mjaft e vështirë të kuptohet, por me kalimin e kohës, siç tregon praktika, administratorët e rrjetit mësohen me këtë strukturë brenda rreth një muaji dhe vetëm atëherë e kuptojnë sa e përshtatshme është ajo.
Krahasimi
Në zgjidhjen Cisco ACI duhet të blihet më shumë pajisje (switch-e të veçanta për ndërveprimin Inter-Pod dhe kontrollorë APIC), prandaj ajo doli më e kushtueshme. Zgjidhja Juniper nuk kërkoi blerjen e kontrollorëve dhe pajisjeve ndihmëse; ishte e mundur të përdorej pjesërisht edhe pajisja ekzistuese e klientit.
Ja arkitektura e fabric EVPN VXLAN për dy qendra të të dhënave të projektit të dytë:
Me ACI merr njĂ« zgjidhje tĂ« gatshme: nuk ka nevojĂ« tĂ« gĂ«rmosh nĂ« konfigurime dhe as tĂ« optimizosh gjithçka vetĂ«. NĂ« fazĂ«n e parĂ« tĂ« njohjes sĂ« klientit me fabric-un, nuk duhen zhvillues dhe as specialistĂ« pĂ«r mbĂ«shtetjen e kodit apo automatizimit. Mjafton ekipi i operimit; shumĂ« konfigurime mund tĂ« bĂ«hen edhe pĂ«rmes wizard-it, gjĂ« qĂ« nuk Ă«shtĂ« gjithmonĂ« avantazh, sidomos pĂ«r ata qĂ« janĂ« mĂ«suar me komandĂ«n nga console. SidoqoftĂ«, duhet kohĂ« pĂ«r tâiu pĂ«rshtatur qasjes sĂ« re, veçanĂ«risht logjikĂ«s sĂ« konfigurimit pĂ«rmes politikave dhe menaxhimit tĂ« shumĂ« politikave tĂ« ndĂ«rlidhura mes tyre. PĂ«rveç kĂ«saj, Ă«shtĂ« shumĂ« e kĂ«shillueshme tĂ« keni njĂ« strukturĂ« tĂ« qartĂ« pĂ«r emĂ«rtimin e politikave dhe objekteve. NĂ«se shfaqet ndonjĂ« problem nĂ« logjikĂ«n e funksionimit tĂ« controller-it, zgjidhja mund tĂ« bĂ«het vetĂ«m pĂ«rmes mbĂ«shtetjes teknike.
NĂ« EVPN gjithçka bĂ«het nga console. Vuaj ose kĂ«naqu. ĂshtĂ« njĂ« ndĂ«rfaqe e njohur pĂ«r gardĂ«n e vjetĂ«r. Po, ka konfigurime standarde dhe udhĂ«zues. Do tĂ« duhet tĂ« studiosh dokumentacionin. Ka ndĂ«rtim tĂ« ndryshĂ«m tĂ« konfigurimeve, por gjithçka Ă«shtĂ« e qartĂ« dhe e detajuar.
Natyrisht, nĂ« tĂ« dyja rastet, gjatĂ« migrimit Ă«shtĂ« mĂ« mirĂ« qĂ« fillimisht tĂ« kalohen shĂ«rbimet mĂ« pak kritike, pĂ«r shembull mjediset testuese, dhe vetĂ«m pasi tĂ« zbulohen e tĂ« korrigjohen tĂ« gjitha problemet tĂ« kalohet te production. Dhe jo tĂ« premten nĂ« mbrĂ«mje. Nuk duhet tâi besosh verbĂ«risht vendor-it kur thotĂ« se gjithçka do tĂ« shkojĂ« mirĂ«; Ă«shtĂ« gjithmonĂ« mĂ« mirĂ« tĂ« kesh njĂ« plan rezervĂ«.
Me ACI paguan mĂ« shumĂ«, megjithĂ«se aktualisht Cisco e promovon nĂ« mĂ«nyrĂ« aktive kĂ«tĂ« zgjidhje dhe shpesh ofron zbritje tĂ« mira pĂ«r tĂ«, por kursen nĂ« mirĂ«mbajtje dhe support. Menaxhimi dhe çdo lloj automatizimi i njĂ« EVPN fabric pa controller kĂ«rkon investime dhe kosto tĂ« vazhdueshme: monitorim, automatizim, implementim tĂ« shĂ«rbimeve tĂ« reja. Nga ana tjetĂ«r, nisja fillestare me ACI zakonisht zgjat 30â40 pĂ«r qind mĂ« shumĂ«. Kjo ndodh sepse kĂ«rkon mĂ« shumĂ« kohĂ« krijimi i tĂ« gjithĂ« grupit tĂ« profileve dhe politikave tĂ« nevojshme, tĂ« cilat mĂ« pas do tĂ« pĂ«rdoren vazhdimisht. Por me rritjen e rrjetit, numri i konfigurimeve tĂ« reja qĂ« duhen zvogĂ«lohet. PĂ«rdor politika, profile dhe objekte tĂ« krijuara paraprakisht. Mund tĂ« konfigurosh nĂ« mĂ«nyrĂ« fleksibile segmentimin dhe sigurinĂ«, si edhe tĂ« menaxhosh nĂ« mĂ«nyrĂ« tĂ« centralizuar kontratat qĂ« pĂ«rcaktojnĂ« se cilat ndĂ«rveprime lejohen mes EPG-ve â dhe volumi i punĂ«s bie ndjeshĂ«m.
Në EVPN duhet të konfigurosh çdo pajisje në fabric, ndaj probabiliteti i gabimeve është më i lartë.
NĂ«se ACI po implementohet mĂ« ngadalĂ«, EVPN kĂ«rkoi pothuajse dy herĂ« mĂ« shumĂ« kohĂ« pĂ«r tâu rregulluar dhe optimizuar. Me Cisco gjithmonĂ« mund tĂ« thĂ«rrisni njĂ« inxhinier tĂ« support-it dhe tĂ« pyesni pĂ«r rrjetin nĂ« tĂ«rĂ«si, sepse mbulohet si zgjidhje e plotĂ«. NdĂ«rsa te Juniper Networks blini vetĂ«m pajisjen, dhe mbulimi vlen pikĂ«risht pĂ«r tĂ«. Paketat dolĂ«n nga pajisja? MirĂ«, qĂ« aty e tutje janĂ« problemet tuaja. MegjithatĂ«, mund tĂ« hapni njĂ« kĂ«rkesĂ« pĂ«r zgjedhjen e zgjidhjes ose dizajnin e rrjetit â dhe atĂ«herĂ« do tâju rekomandojnĂ« tĂ« blini professional services, me pagesĂ« shtesĂ«.
Support-i i ACI Ă«shtĂ« shumĂ« i fortĂ«, sepse Ă«shtĂ« i dedikuar: njĂ« ekip i veçantĂ« merret vetĂ«m me kĂ«tĂ«. Ka edhe specialistĂ« rusishtfolĂ«s. Dokumentacioni Ă«shtĂ« i detajuar, zgjidhjet janĂ« tĂ« parapĂ«rcaktuara. E shqyrtojnĂ« situatĂ«n dhe japin rekomandime. E validojnĂ« shpejt dizajnin, gjĂ« qĂ« shpesh Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme. Juniper Networks bĂ«n tĂ« njĂ«jtĂ«n gjĂ«, por shumĂ« herĂ« mĂ« ngadalĂ« (tĂ« paktĂ«n kĂ«shtu ishte nĂ« rastin tonĂ«; sipas asaj qĂ« dĂ«gjohet, tani duhet tĂ« jetĂ« mĂ« mirĂ«), gjĂ« qĂ« ju detyron tâi bĂ«ni vetĂ« ato punĂ« ku njĂ« solution engineer mund tâju kishte orientuar.
Cisco ACI mbĂ«shtet integrimin me sistemet e virtualizimit dhe kontejnerizimit (VMware, Kubernetes, Hyper-V), si edhe menaxhim tĂ« centralizuar. Ka integrim edhe me shĂ«rbimet e rrjetit dhe tĂ« sigurisĂ« â load balancing, firewall, WAF, IPS dhe tĂ« tjera. Ofron mikrosegmentim tĂ« mirĂ« qĂ« nĂ« standard. Te zgjidhja e dytĂ«, integrimi me shĂ«rbimet e rrjetit kĂ«rkon shumĂ« mĂ« tepĂ«r pĂ«rpjekje, ndaj Ă«shtĂ« mĂ« mirĂ« tĂ« lexoni paraprakisht forumet e atyre qĂ« e kanĂ« bĂ«rĂ« tashmĂ« kĂ«tĂ«.
PĂ«rfundimi
Për çdo rast konkret, zgjidhja duhet të përzgjidhet jo vetëm mbi bazën e kostos së pajisjeve, por duke marrë parasysh edhe shpenzimet e mëtejshme të operimit, problemet kryesore me të cilat përballet klienti aktualisht, si dhe planet për zhvillimin e mëtejshëm të infrastrukturës IT.
ACI doli më i kushtueshëm për shkak të pajisjeve shtesë, por është një zgjidhje e gatshme pa nevojë për përshtatje të mëtejshme. Zgjidhja e dytë është më komplekse dhe më e kushtueshme nga pikëpamja e operimit, por më e lirë.
NĂ«se dĂ«shironi tĂ« diskutoni sa mund tĂ« kushtojĂ« implementimi i njĂ« fabric rrjeti me vendorĂ« tĂ« ndryshĂ«m dhe çfarĂ« arkitekture nevojitet, mund tĂ« takohemi dhe tĂ« bisedojmĂ«. Deri te njĂ« skicĂ« paraprake e arkitekturĂ«s (me tĂ« cilĂ«n mund tĂ« llogariten buxhetet) do tâju kĂ«shillojmĂ« pa pagesĂ«; pĂ«rpunimi i detajuar, natyrisht, Ă«shtĂ« tashmĂ« me pagesĂ«.
Vladimir Klepçe, rrjete korporative.
Burimi: habr.com
