
Vlerësoni lidhjet në mes të diagramit. Më poshtë do t'i kthehemi atyre.
Në një moment, mund të përballeni me faktin se rrjetet e mëdha dhe të ndërlikuara mbi L2 janë rëndë të sëmura. Së pari, për shkak të problemeve që lidhen me përpunimin e trafikut BUM dhe punën e protokollit STP. Së dyti, për një arkitekturë në tërësi të vjetruar. Kjo shkakton probleme të pakëndshme si pushime në shërbim dhe vështirësi në menaxhimin e saj.
Kishim dy projekte paralele, ku klientët e vlerësuan qartë të gjitha përfitimet dhe disavantazhet e mundësive dhe zgjodhën dy zgjidhje të ndryshme overlay, dhe ne i implementuam ato.
Ishte e mundur të krahasohej pikërisht implementimi. Jo operimi, për të cilin vlen të flitet pas dy-tre vjetësh.
Pra, çfarë është fabrika e rrjetit me rrjeta mbi të dhe SDN?
Çfarë të bëni me problemet e njohura të arkitekturës klasike të rrjetit?
Çdo vit shfaqen teknologji dhe ide të reja. Në praktikë, nevoja e nxehtë për të riorganizuar rrjetet nuk ka qenë e pranishme për një kohë të gjatë, sepse gjithçka mund të bëhet me duar sipas metodave tradicionale. E megjithatë, çfarë ka rëndësi që jemi në shekullin e njëzet e një? Në fund të fundit, administratori duhet të punojë, jo të qëndrojë në kabinën e tij.
Pastaj filloi bum i ndërtimit të qendrave të të dhënave në shkallë të madhe. Aty ku u kuptua se arriti kufirin e zhvillimit të arkitekturës klasike, jo vetëm në aspektin e funksionit, qëndrueshmërisë dhe shkallëzueshmërisë. Një nga zgjidhjet për këto probleme ishte ideja e ndërtimit të rrjeteve të mbivendosura mbi një backbone të ruterizuar.
Përveç kësaj, me rritjen e masave të rrjeteve, çështja e menaxhimit të këtyre fabrikave u bë e ngjarë, si rezultat i të cilave filluan të shfaqen zgjidhjet e rrjeteve të menaxhuara nga softueri, me mundësinë për të menaxhuar të gjithë infrastrukturën rrjetore si një entitet të vetëm. Kur rrjeti menaxhohet nga një pikë e vetme, është më e lehtë për komponentët e tjerë të infrastrukturës IT të bashkëveprojnë me të, dhe këto procese bashkëveprimi mund të automatizohen më lehtë.
Gati çdo prodhues i njohur jo vetëm i pajisjeve rrjetore, por edhe i virtualizimit, ka në portofolin e tij mundësi të tilla zgjidhjesh.
Mbetej vetëm të kuptojmë se çfarë do të përshtatet për nevojat e caktuara. Për shembull, për kompanitë shumë të mëdha që kanë një ekip të mirë zhvilluesish dhe operativ, zgjidhjet e gatshme nga furnizuesit nuk përmbushin gjithmonë të gjitha nevojat, dhe ato ndihmojnë në zhvillimin e zgjidhjeve të veta me SD (software defined). Për shembull, këto janë ofruesit e shërbimeve në cloud, të cilët vazhdimisht zgjeruan gamën e shërbimeve që u ofrojnë klientëve të tyre, dhe zgjidhjet e gatshme thjesht nuk arrijnë të përballen me nevojat e tyre.
Për kompanitë mesatare, funksionaliteti i ofruar nga furnizuesi në formën e një zgjidhjeje të gatshme mjafton në 99 përqind të rasteve.
Çfarë janë rrjetet overlay?
Çfarë qëndron pas ideve të rrjeteve me mbivendosje. Në thelb, ju merrni një rrjet të klasës ruter dhe ndërtoni sipër tij një rrjet tjetër, për të fituar më shumë funksionalitete. Më shpesh, ky është një diskutim për shpërndarjen e efektshme të ngarkesës në pajisje dhe linjat e komunikimit, për një rritje të konsiderueshme të kufijve të shkallëzueshmërisë, për forcimin e besueshmërisë dhe një mori avantazhesh për sigurinë (përmes segmentimit). Zgjidhjet SDN, përveç kësaj, ofrojnë mundësi për administrim tepër fleksibël dhe e bëjnë rrjetin më të qartë për konsumatorët e tij.
Në përgjithësi, nëse rrjetet lokale do të ishin sajuar në vitet 2010, ato nuk do të dukeshin aspak si ato që trashëguam nga ushtarët në vitet 1970.
Nga perspektiva e teknologjive për ndërtimin e fabrikave duke përdorur rrjete të mbivendosura, aktualisht ka shumë implementime nga prodhues dhe projekte interneti RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve dhe të tjera). Po, ka standarde, por realizimi i këtyre standardeve nga prodhues të ndryshëm mund të jetë i ndryshëm, prandaj, kur krijoni këto fabrika, është e mundur të heqësh dorë plotësisht nga vendori në teori vetëm në letër.
MeSD mjedisi është edhe më i ndërlikuar; çdo furnizues ka vizionin e vet. Ka zgjidhje plotësisht të hapura, të cilat teori i mundësojnë përmirësimin nga vetë, dhe ka zgjidhje plotësisht të mbyllura.
Cisco ofron variantin e vet SDN për qendrat e të dhënave — ACI. Natyrisht, kjo është një zgjidhje 100% e lokalizuar e furnizuesit në aspektin e përzgjedhjes së pajisjeve rrjetike, por përveç kësaj, ajo integrohet plotësisht me sistemet e virtualizimit, kontejnerizimit, sigurisë, orkestrimit, balancuesve të ngarkesës dhe të tjerëve. Por në thelb, kjo është akoma një kutë e zezë, pa mundësi për qasje të plotë në të gjitha proceset e brendshme. Nuk të gjithë blerësit janë të gatshëm për këtë variant, pasi je plotësisht i varur nga cilësia e kodit të shkruar për zgjidhjen dhe realizimin e saj. Nga ana tjetër, prodhuesi ka një nga mbështetje teknike më të mira në botë dhe ka 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 zgjidhja nga Juniper. Prodhuesi gjithashtu ka SDN të tij për Qendrën e të Dhënave, por klienti vendosi të heqë dorë nga implementimi i SDN. Si teknologji e ndërtimit të rrjetit u zgjodh fabrika EVPN VXLAN pa përdorimin e kontrolerëve të centralizuar.
Për çfarë nevojitet
Krijimi i fabrikës lejon ndërtimin e një rrjeti të lehtë për t'u shkallëzuar, të qëndrueshëm dhe të besueshëm. Arkitektura (leaf-spine) merr parasysh veçoritë e qendrave të përpunimit të të dhënave (rrugët e kalimit të trafikut, minimizimin e vonesave dhe ngushticave në rrjet). Zgjidhjet SD në Qendrat e të Dhënave lejojnë të menaxhohet shumë lehtë, shpejt dhe fleksibël një fabrikë e tillë, duke e integruar atë në ekosistemin e Qendrës së të Dhënave.
Të dy klientët kishin nevojë për ndërtimin e Qendrave të të Dhënave rezervë për sigurimin e qëndrueshmërisë, përveç kësaj, trafiku midis Qendrave të të Dhënave duhej të ishte i enkriptuar.
Klienti i parë tashmë kishte shqyrtuar zgjidhje pa fabrikë si një standard të mundshëm për rrjetet e tij, por në provat e tyre kishin probleme me përputhshmërinë STP midis disa shitësve të pajisjeve. Erdhën ndërprerje që shkaktuan rënien e shërbimeve. Dhe për klientin kjo ishte kritike.
Cisco tashmë ishte standardi i korporatave për klientët, ata shqyrtuan ACI-në dhe opsione të tjera dhe vendosën se duhet të zgjidhnin këtë zgjidhje. U pëlqeu automatizimi i menaxhimit me një buton përmes një kontrollori të vetëm. Shërbimet konfigurohen më shpejt, menaxhohen më shpejt. Për të siguruar enkriptimin e trafikut, ata vendosën të aktivizojnë MACSec ndërmjet switch-ëve IPN dhe SPINE. Kështu arritën të shmangin ngushticën e një kalimi kriptografik, të kursejnë para mbi të dhe të përdorin në maksimum brezin e kapacitetit.
Klienti i dytë zgjodhi një zgjidhje pa kontrollues nga Juniper, pasi që në qendrën e tyre ekzistuese të të dhënave kishte një instalim të vogël me realizimin e fabrikës EVPN VXLAN. Por aty nuk kishte qëndrueshmëri (përdorej një switch i vetëm). Kështu, u vendos të zgjeronin infrastrukturën e qendrës kryesore të të dhënave dhe të ndërtuan fabrikën në qendrën e rezervës. EVPN ekzistues nuk ishte përdorur plotësisht: enkapsulimi VXLAN faktikisht nuk ishte aplikuar, pasi të gjitha hostet ishin të lidhura me një switch të vetëm, dhe të gjitha adresat MAC dhe /32 ishin lokale, ky switch shërbente si gateway për to, dhe nuk kishte pajisje të tjera ku nevojitej ndërtimi i tunelieve VXLAN. U vendos të sigurohej enkriptimi i trafikut duke përdorur teknologjinë IPSEC midis firewalleve (kapaciteti i MСE ishte i mjaftueshëm).
Po ashtu shqyrtuam ACI-në, por vendosëm se për shkak të lokacionit të furnizuesit do të duhej të blinim shumë pajisje, duke përfshirë zëvendësimin e pajisjeve të reja që ishin blerë së fundmi, dhe kjo thjesht nuk kishte kuptim ekonomik. Po, fabrika Cisco integrohet me të gjitha, por brenda vetë fabrikës mund të përdoren vetëm pajisjet e saj.
Nga ana tjetër, siç u tha më parë, nuk mund të përzjehen aq lehtë fabrika EVPN VXLAN me ndonjë ofrues fqinj, sepse implementimet e protokollit ndryshojnë. Është si të përzjehësh Cisco dhe Huawei në një rrjet — ndonëse standardet janë të përbashkëta, do të duhen përpjekje të mëdha. Duke qenë se kjo është një bankë dhe testet e kompatibilitetit do të ishin shumë të gjata, u vendos që të blihen pajisje nga i njëjti ofrues tani, pa u qetësuar shumë për funksionalitetin jashtë bazës.
Plani i migrimit
Dy Qendra të të Dhënave me bazë ACI:

Organizimi i bashkëpunimit midis Qendrave të të Dhënave. U zgjodh zgjidhja Multi-Pod — çdo Qendër të Dhënash është një pod. U morën parasysh kërkesat për shkallëzim sipas numrit të switch-ev dhe për vonesat midis pod-ev (RTT më pak se 50 ms). U vendos të mos ndërtohej një zgjidhje Multi-Site për lehtësinë e menaxhimit (për zgjidhjen Multi-Pod përdoret një ndërfaqe menaxhimi, ndërsa për Multi-Site do të ishin dy ndërfaqe, ose do të duhej një Orkestrator Multi-Site), dhe gjithashtu për shkak se nuk ishte e nevojshme rezervimi gjeografik i vendeve.

Sa i përket migrimit të shërbimeve nga rrjeti Legacy, u zgjodh opsioni më transparent, transferimi gradual i VLAN-eve përkatëse shërbimeve specifike.
Për migrimin e çdo VLAN krijohej një EPG (End-point-group) përkatës në fabrikë. Fillimisht, rrjeti shtrihej midis rrjetit të vjetër dhe fabrikës në L2, pastaj, pasi të ishin migruar të gjitha hostet, porta u transferua në fabrikë, dhe ndërveprimi i EPG me rrjetin ekzistues u realizua përmes L3OUT, ndërsa ndërveprimi midis L3OUT dhe EPG u përshkrua duke përdorur kontrata. Skema e përafërt:

Struktura e përafërt e politikave më të shumta të fabrikës ACI në figurën më poshtë. E gjithë konfigurimi ndërtohet mbi politika, të vendosura brenda politikave të tjera dhe kështu me radhë. Në fillim është shumë e vështirë të kuptohet, por gradualisht, siç tregon praktika, administratorët e rrjetit e zakonisht e përshtatin veten me këtë strukturë për rreth një muaj, dhe pastaj vetëm vjen kuptimi se sa e përshtatshme është ajo.

Krahasimi
Në zgjidhjen Cisco ACI duhet të blihet më shumë pajisje (switch-e të veçantë për bashkëveprimin Inter-Pod dhe kontrollues APIC), për çka ajo doli më e shtrenjtë. Zgjidhja Juniper nuk kërkoi blerjen e kontrolluesve dhe pajisjeve ndihmëse; arriti të përdorte pjesërisht pajisjet ekzistuese të klientit.
Kjo është arkitektura e fabrikës EVPN VXLAN për dy Qendrat e të Dhënave të projektit të dytë:


Në ACI merr një zgjidhje të gatshme — nuk është e nevojshme të gërmosh, nuk është e nevojshme të optimizosh. Kur klienti fillon të njihet me fabrikën, nuk janë të nevojshëm zhvilluesit, as njerëzit mbështetës për kodin dhe automatizimin. Mjafton thjesht përdorimi, shumë nga konfigurimet mund të bëhen nëpërmjet një wizardi, që nuk është gjithmonë një plus, sidomos për ata që janë mësuar me komandën e linjës. Në çdo rast, nevojitet kohë për të ristrukturuar mendjen në binarët e rinj, në veçoritë e konfigurimeve përmes politikave dhe operimin e një numri të madh politikash të ndërlidhura me njëra-tjetrën. Shumë e dëshirueshme është gjithashtu të kesh një strukturë të qartë emërtimi të politikave dhe objekteve. Kur të lind ndonjë problem në logjikën e punës së kontrolluesit, mund të zgjidhesh vetëm përmes mbështetjes teknike.
Në EVPN — konsola. Pëso ose gëzo. Një ndërfaqe e njohur për gardën e vjetër. Po, ka një konfigurim standard dhe udhëzues. Do të duhet të lexosh manualet. Konstruktime të ndryshme, gjithçka është e qartë dhe e detajuar.
Sigurisht, në të dy rastet, është më mirë që gjatë migrimit të filloni me shërbimet më pak kritike, siç janë ambientet testuese, dhe vetëm pas identifikimit të të gjitha problemeve të kaloni në prodhim. Dhe mos e konfiguroni në fundjavë. Nuk duhet të besoni te ofruesi që gjithçka do të shkojë mirë; gjithmonë është më mirë të jeni të sigurt.
Me ACI paguan më shumë, megjithëse Cisco aktualisht po promovon këtë zgjidhje dhe shpesh ofron zbritje të mira për të, por kursen në shërbimin e mbështetjes. Menaxhimi dhe çdo automatizim i fabrikës EVPN pa një kontrollor kërkon investime dhe shpenzime të rregullta — monitorim, automatizim, implementim të shërbimeve të reja. Ndërkohë, nisja fillestare në ACI zgjat 30–40 përqind më shumë. Kjo ndodh për shkak se zgjat më gjatë të krijohet e gjithë paketa e nevojshme e profileve dhe politikave që do të përdoren. Por me rritjen e rrjetit, numri i konfigurimeve të nevojshme zvogëlohet. Përdor politikë, profile, objekte të krijuara paraprakisht. Mund të konfigurosh në mënyrë fleksibël segmentimin dhe sigurimin, menaxhimin qëndror të kontratave që përshkruajnë interaksionet midis EPG-ve, — volumi i punës bie ndjeshëm.
Në EVPN duhet të konfigurosh çdo pajisje në fabrikë, probabiliteti i gabimit është më i lartë.
Nëse ACI implementohet ngadalë, atëherë EVPN është dyfish më i ngadalshëm për rikuperim. Në rastin e Cisco gjithmonë mund të thërrasësh inxhinierin e mbështetjes dhe të pyesësh për rrjetin në përgjithësi (sepse mbulon si një zgjidhje), ndërsa me Juniper Networks blen vetëm harduerin, dhe kjo është ajo çka mbulohet. Pakot nga pajisja ikën? Ok, tani janë problemet tuaja. Por mund të hapni një çështje rreth zgjedhjes së zgjidhjes ose dizajnit të rrjetit — dhe atëherë do të rekomandohet të blini një shërbim profesional, me pagesë shtesë.
Mbështetja ACI është shumë e shkëlqyer, sepse është e veçantë: një ekip i veçantë është aty vetëm për këtë. Ka gjithashtu dhe specialistë që flasin rusisht. Udhëzuesi është i detajuar, zgjidhjet janë të paracaktuara. Ata shqyrtojnë dhe japin sugjerime. Shpejt validojnë dizajnin, gjë që shpesh është e rëndësishme. Juniper Networks bën të njëjtën gjë, por me shumë ngadalë (ne e kemi përjetuar, tani duhet të jetë më mirë sipas thashethemeve), gjë që të detyron të bësh gjithçka vetë, aty ku mund të kishte këshilluar inxhinieri i zgjidhjeve.
Cisco ACI mbështet integrimin me sistemet e virtualizimit dhe kontejnerizimit (VMware, Kubernetes, Hyper-V) dhe menaxhimin e centralizuar. Ka shërbime rrjeti dhe shërbime sigurie — balancimi, firewall, WAF, IPS dhe të tjera... Mikrosektorizimi i mirë nga kutia. Në zgjidhjen e dytë, integrimi me shërbimet rrjetore bëhet me vështirësi, dhe është më mirë të hulumtoni përpara në forume me ata që e kanë bërë këtë.
Përfundimi
Për çdo rast të veçantë, është e nevojshme të zgjidhet një zgjidhje, jo vetëm në bazë të kostos së pajisjeve, por gjithashtu duhet të merren parasysh shpenzimet e ardhshme të operimit dhe problemet kryesore me të cilat përballet klienti tani, si dhe planet për zhvillimin e infrastrukturës IT.
ACI, për shkak të pajisjeve shtesë, doli më e kushtueshme, por zgjidhja është e gatshme pa nevojën për përmirësime, zgjidhja e dytë është më komplekse dhe e shtrenjtë në aspektin e operimit, por më e lirë.
Nëse dëshironi të diskutoni se sa mund të kushtojë zbatimi i një fabrike rrjetesh me ofrues të ndryshëm dhe cila është e nevojshme arkitektura, mund të takohemi dhe të flasim. Para skicës përfundimtare të arkitekturës (me të cilën mund të llogariten buxhetet), do t'ju ndihmojmë falas; përpunimi më i detajuar, sigurisht, do të jetë me pagesë.
Vladimir Klepche, rrjetet korporative.
Burimi: habr.com
