Me ndihmën e këtij skripti magical Cisco ACI, mund të konfigurohet shpejt rrjeti.
Fabrika e rrjetit për qendrat e të dhënave Cisco ACI ekziston prej pesë vjetësh, por në Habra nuk është folur asgjë për të, kështu që vendosa ta rregullojnë pak. Do të flas nga përvoja ime, se çfarë është, çfarë përfitimi ka dhe ku ka pengesa.
ĂfarĂ« Ă«shtĂ« dhe nga erdhi?
Në momentin e shpalljes së ACI (Infrastructure e Fokusuar në Aplikacione) në vitin 2013, për qendrat e të dhënave washin duke u sulmuar nga tre anë.
Nga njëra anë, zgjidhjet SDN "të gjeneratës së parë" bazuar në OpenFlow premtuan të bënin rrjetet më fleksibile dhe më të lira në të njëjtën kohë. Ideja ishte që të kalonte marrjen e vendimeve, që tradicionalisht ishte realizuar nga softi pronar i switch-ave, në një kontrollues qendror.
Ky kontrollues do të kishte një pamje të vetme për të gjithë atë që ndodhte dhe, duke u bazuar në këtë, do të programonte pajisjet e të gjithë switch-ave në nivelin e rregullave të përpunimit të flukseve specifike.
Nga ana tjetër, zgjidhjet rrjetëoresh ofronin mundësinë për të realizuar lidhshmëri dhe politika të sigurisë pa ndonjë ndryshim në rrjetin fizik, duke ndërtuar tunelë programorë mes hosteve të virtualizuara. Një nga shembujt më të njohur të këtij qasjeje ishte zgjidhja nga Nicira, e cila në atë kohë ishte blerë nga VMWare për 1.26 miliard dollarë dhe hodhi themelet e VMWare NSX të tanishëm. Një nuancë e situatës ishte se bashkëthemeluesit e Nicira ishin ata të njëjtët që më parë ishin të angazhuar në krijimin e OpenFlow, tani thoshin se për ndërtimin e fabrikës së Qendrës së të Dhënave, .
Më në fund, çipat e switch-eve, të disponueshëm në tregun e hapur (ajo që quhet merchant silicon), arritën një nivel të pjekurisë, për të cilin ata u bënë një kërcënim real për prodhuesit tradicionalë të switch-eve. Nëse më parë secili prodhues zhvillonte vetë çipat për switch-at e tij, me kalimin e kohës çipat nga prodhues të tretë, kryesisht nga Broadcom, filluan të reduktonin distancën me çipat e prodhuesve për funksionalitetet, ndërsa në raportin çmim/përformancë i kalonin ato. Prandaj, shumë mendonin se ditët e switch-eve me çipa të zhvilluar vetë ishin numëruar.
ACI u bë "përgjigjja asimetrike" e Cisco (në fakt, e kompanisë Insieme, e cila ishte themeluar nga ish-punonjësit e saj) ndaj gjithë asaj që është përmendur.
Cila është dallimi me OpenFlow?
Nga pikëpamja e ndarjes së funksioneve, ACI është në fakt e kundërta e OpenFlow.
Në arkitekturën OpenFlow, kontroluesi është përgjegjës për shkruan rregullat e detajuara (rrjedhat) në pajisjet e të gjitha switcheve, pra në një rrjet të madh, ai mund të ketë përgjegjësinë për të mbajtur dhe, më e rëndësishmja, për të ndryshuar dhjetëra milionë regjistrime në qindra pika në rrjet, kështu që performanca dhe qëndrueshmëria e tij në një zbatim të madh bëhen një ngushticë.
NĂ« ACI pĂ«rdoret njĂ« qasje e kundĂ«rt: ka gjithashtu njĂ« kontrolues, por switchet e marrin prej tij politika deklaruese mĂ« tĂ« nivelit tĂ« lartĂ«, dhe renderimi nĂ« detaje tĂ« konfigurimeve specifike nĂ« pajisje kryhet nga vetĂ« switchi. Kontroluesi mund tĂ« ri-ngarkohet ose madje tĂ« fikohet, dhe asgjĂ« e keqe nuk do t'i ndodhĂ« rrjetit, pĂ«rveç, natyrisht, mungesĂ«s nĂ« atĂ« moment tĂ« mundĂ«sisĂ« sĂ« menaxhimit. ĂshtĂ« interesante qĂ« nĂ« ACI ka situata ku OpenFlow pĂ«rdoret ndonjĂ«herĂ«, por lokalisht brenda hostit pĂ«r programimin e Open vSwitch.
ACI është ndërtuar plotësisht mbi transportin overlay të bazuar në VXLAN, por gjithashtu përfshin transportin IP të poshtëm brenda një zgjidhjeje të vetme. Cisco e quajti këtë termin «overlay i integruar». Si një pikë terminimi për overlay-t në ACI, në shumicën e rasteve përdoren switche të fabrikës (të cilat e bëjnë këtë me shpejtësinë e kanalit). Hostet nuk kanë nevojë të dinë gjë për fabrikën, inkapsulimet etj., megjithatë, në disa raste (për shembull, për lidhjen e hosteve OpenStack) trafik VXLAN mund të dërgohet edhe atyre.
Overlay-t përdoren në ACI jo vetëm për të siguruar lidhje elastike përmes rrjetit të transportit, por gjithashtu për transmetimin e metainformacionit (ai përdoret, për shembull, për të aplikuar politikat e sigurisë).
Overlay-t përdoren në ACI jo vetëm për të siguruar lidhshmërinë fleksibël përmes rrjetit të transportit, por edhe për të kaluar meta-informacione (ato përdoren, për shembull, për të aplikuar politikat e sigurisë).
Ăipat e Broadcom janĂ« pĂ«rdorur mĂ« parĂ« nga Cisco nĂ« switch-at e serisĂ« Nexus 3000. NĂ« familjen Nexus 9000, e cila Ă«shtĂ« nxjerrĂ« posaçërisht pĂ«r tĂ« mbĂ«shtetur ACI, fillimisht u implementua njĂ« model hibrid i quajtur Merchant+. NĂ« switch-in, ishin pĂ«rdorur njĂ«kohĂ«sisht çipi i ri Broadcom Trident 2 dhe njĂ« çip shtesĂ« i zhvilluar nga Cisco, i cili realizonte gjithĂ« magjinĂ« e ACI. Duket se kjo ka lejuar tĂ« pĂ«rshpejtohet dalja nĂ« treg e produktit dhe tĂ« ulet çmimi i switch-it nĂ« njĂ« nivel afĂ«r modele tĂ« thjeshta me Trident 2. Ky qasje ishte e mjaftueshme pĂ«r dy-tre vitet e para tĂ« shpĂ«rndarjeve tĂ« ACI. GjatĂ« kĂ«saj kohe, Cisco zhvilloi dhe nxori nĂ« treg gjeneratĂ«n e ardhshme tĂ« Nexus 9000 e cila pĂ«rdorte çipat e saj me performancĂ« mĂ« tĂ« lartĂ« dhe njĂ« set funksionesh, por nĂ« tĂ« njĂ«jtin nivel çmimi. Specifikimet e jashtme pĂ«rsa i pĂ«rket ndĂ«rveprimit nĂ« fabrikĂ« kanĂ« mbetur krejtĂ«sisht tĂ« pandryshuara. NĂ« kĂ«tĂ« kuptim, brendĂ«sia Ă«shtĂ« ndryshuar krejtĂ«sisht: diçka si njĂ« refaktorizim, por pĂ«r harduerin.
Si është ndërtuar arkitektura Cisco ACI
NĂ« rastin mĂ« tĂ« thjeshtĂ«, ACI ndĂ«rtohet sipas topologjisĂ« sĂ« rrjetit Clos, ose, siç quhet shpesh, Spine-Leaf. Numri i switch-ave tĂ« nivelit Spine mund tĂ« variojĂ« nga dy (ose njĂ«, nĂ«se nuk na intereson qĂ«ndrueshmĂ«ria) deri nĂ« gjashtĂ«. Prandaj, sa mĂ« shumĂ« tĂ« jenĂ«, aq mĂ« e lartĂ« Ă«shtĂ« qĂ«ndrueshmĂ«ria (mĂ« pak humbje tĂ« kapacitetit dhe besueshmĂ«risĂ« gjatĂ« dĂ«shtimit ose mirĂ«mbajtjes sĂ« njĂ« Spine) dhe performanca totale. TĂ« gjitha lidhjet e jashtme shkojnĂ« nĂ« switch-at e nivelit Leaf: kĂ«tu kemi serverĂ«t, kalimin me rrjetet e jashtme pĂ«rmes L2 ose L3, dhe lidhjen e kontrollorĂ«ve APIC. NĂ« tĂ« vĂ«rtetĂ«, me ACI jo vetĂ«m qĂ« konfigurimi, por edhe mbulimi i statistikave, monitorimi i dĂ«shtimeve dhe tĂ« tjera â gjithçka bĂ«het pĂ«rmes ndĂ«rfaqes sĂ« kontrollorĂ«ve, tĂ« cilĂ«t nĂ« implementimet e zakonshme janĂ« tre.
Këshilla e lidhjes me switch-at kurrë nuk është e nevojshme, as edhe për nisjen e rrjetit: kontrollori vetë i zbulohet switch-at dhe formon fabrikën prej tyre, përfshirë konfigurimet e të gjitha protokolleve shërbimi, prandaj, për këtë arsye, është shumë e rëndësishme gjatë montimit të regjistrohen numrat serial të pajisjeve që po instalohen, në mënyrë që më pas të mos mendohet se cili switch ndodhet në cilin raft. Për troubleshooting, nëse është e nevojshme, mund të lidheni me switch-at përmes SSH: ata kanë zbatuar me kujdes komandat e zakonshme show të Cisco.
Brenda përdor transport IP, kështu që nuk ka asnjë Spanning Tree dhe tmerrin e së kaluarës: të gjitha lidhjet janë në përdorim, dhe konvergjenca në rast dështimi është shumë e shpejtë. Trafiku në brendësi transmetohet përmes tunelesh të bazuara në VXLAN. Më saktë, Cisco e quan encapsulimin iVXLAN, dhe ndryshon nga VXLAN i zakonshëm në atë që fushat e rezervuara në titullin rrjetor përdoren për të transmetuar informacione shërbimi, kryesisht për marrëdhënien e trafikut me grupin EPG. Kjo lejon implementimin e rregullave të bashkëpunimit midis grupeve në harduer, duke përdorur numrat e tyre ashtu siç përdoren adresat në listat aksesi.
Tunelat lejojnë shtrirjen e L2-segmenteve dhe L3 (dmth VRF) përmes transportit të brendshëm IP. Në këtë rast, gateway i paracaktuar është i shpërndarë. Kjo do të thotë se çdo switch merret me route-n e trafikut që hyn në brendësi. Në aspektin e logjikës së transmetimit të trafikut, ACI është e ngjashme me një fabrikë të bazuar në VXLAN/EVPN.
Nëse po, atëherë çfarë dallon? Në çdo gjë tjetër!
Dallimi i parë, me të cilin përballesh në ACI, është se si aktivizohen serverët në rrjet. Në rrjetet tradicionale, aktivizimi i serverëve fizikë dhe të virtualizuar shkon në VLAN dhe nga këtu rrjedhin të gjitha në lidhje, siguria etj. Por në ACI përdoret një strukturë, që Cisco e quan EPG (Grupi i Pikave përfundimtare), nga e cila nuk ka shpëtime. A mund ta barazosh atë me VLAN? Po, por në këtë rast ka mundësi të humbasësh pjesën më të madhe të asaj që ofron ACI.
Në lidhje me EPG formulohet e gjithë politika e aksesit, dhe në ACI, në parim, përdoret principi 'listës së bardhë', do të thotë se lejohet vetëm trafiku, të cilit i është lejuar kalimi në mënyrë të qartë. Kështu që ne mund të krijojmë grupe EPG 'Web' dhe 'MySQL' dhe të përcaktojmë një rregull që lejon bashkëpunimin midis tyre vetëm për portin 3306. Kjo do të funksionojë pa u lidhur me adresat rrjetore dhe madje edhe brenda një nënrrjeti!
Kemi klientë që zgjodhën ACI pikërisht për këtë funksion, pasi ai lejon kufizimin e aksesit midis serverëve (virtuel apo fizik - nuk ka rëndësi), pa i lëvizur ata midis nënrrjetesh, duke mos ndryshuar kështu adresimin. Po, ne e dimë, askush nuk i shkruan ato manualisht Adresa IP në konfigurimet e aplikacioneve, apo jo?
Rregullat e kalimit të trafikut në ACI quhen kontrata. Në një kontratë, një ose disa grupe ose nivele në një aplikacion me shumë nivele bëhen ofrues shërbimi (të themi, shërbimi i DB), të tjerët janë konsumatorë. Kontrata mund të kalojë thjesht trafikun, ose mund të bëjë diçka më të sofistikuar, siç është të drejtosh trafik në një firewall ose balancues ngarkese, si dhe të ndryshosh vlerën e QoS.
Si përfundojnë serverat në këto grupe? Nëse janë servera fizikë ose diçka e përfshirë në një rrjet ekzistues, në të cilin ne krijuam një VLAN trunk, atëherë për t'i vendosur në EPG do të nevojitet të tregojmë portin e switch-it dhe VLAN-in që po përdoret atje. Siç e shohim, VLAN-et shfaqen aty ku nuk mund të kalosh pa to.
Nëse serverët janë virtualë, mjafton të referohesh në mjedisin e virtualizimit të lidhur, pastaj gjithçka do të ndodhë vetë: do të krijohet një grup porti (nëse flasim në terminologji VMWare) për lidhjen e VM, do t'i caktohen VLAN-e ose VXLAN-e të nevojshme, do të regjistrohen në portat e nevojshme të switch-it, etj. Pra, megjithëse ACI është ndërtuar përreth rrjetit fizik, lidhjet për serverët virtualë duken shumë më të thjeshta se për ato fizikë. ACI tashmë ka integruar lidhjen me VMWare dhe MS Hyper-V, si dhe mbështetje për OpenStack dhe RedHat Virtualization. Nga një moment i caktuar, u shfaq dhe mbështetje e integruar për platformat e kontejnerëve: Kubernetes, OpenShift, Cloud Foundry, e cila ka të bëjë si me zbatimin e politikave, ashtu edhe me monitorimin, domethënë administratori i rrjetit mund të shohë menjëherë se në cilat host-e punojnë cilat pods dhe në cilat grupe kanë përfunduar.
Përveç përfshirjes në një grup-porti të caktuar, serverët virtualë kanë cilësi të tjera: emri, atributet, etj., që mund të përdoren si kritere për t'i Transferuar ata në një grup tjetër, për shembull, gjatë rinominimit të VM-së ose kur ajo merr një etiketë shtesë. Cisco e quan këtë grupe mikrosektoriale, megjithatë, në thelb, struktura me mundësinë e krijimit të shumë segmenteve të sigurisë në formën e EPG-së në të njëjtën nënrrjetë është në fakt mikrosektorizim. Mirë, është më mirë për ofruesin.
EPG-të janë strukturat e pastra logjike, të paarritura për komutatorë, serverë, etj., kështu që me to dhe me strukturat e bazuara mbi to (aplikacione dhe qiramarrës) mund të bëni gjëra që janë të vështira për t'u realizuar në rrjetet tradicionale, siç është klonimi. Si rezultat, për shembull, është shumë e lehtë të krijoni një klon të një mjedisi prodhimi për të marrë një ambient testi, të garantuar identik me prodhimin. Mund ta bëni manualisht, por është më mirë (dhe më e lehtësuar) përmes API-së.
Në përgjithësi, logjika e menaxhimit në ACI është krejtësisht ndryshe nga ajo që zakonisht hasni
në rrjetet tradicionale nga Cisco: ndërfaqja programore është primare, ndërsa GUI ose CLI janë sekondare, pasi punojnë përmes të njëjtit API. Prandaj, pothuajse çdo person që merret me ACI pas një kohe fillon të orientojë në modelin e objektit që përdoret për menaxhim dhe të automatizojë diçka sipas nevojave të tij. Më së lehti është të bëhet nga Python: për të ka mjete të gatshme dhe të përshtatshme.
Grapat e premtimeve
Problemi kryesor Ă«shtĂ« se shumĂ« gjĂ«ra nĂ« ACI janĂ« bĂ«rĂ« ndryshe. PĂ«r tĂ« filluar tĂ« punoni normalisht me tĂ«, duhet tĂ« rikonceptoni veten. Kjo Ă«shtĂ« veçanĂ«risht e vĂ«rtetĂ« pĂ«r ekipet e operacioneve rrjetĂ«rore nĂ« blerĂ«s tĂ« mĂ«dhenj, ku inxhinierĂ«t kanĂ« kaluar vite duke bĂ«rĂ« «shkrime VLANĂ«sh» sipas kĂ«rkesave. Ajo qĂ« tani VLAN nuk Ă«shtĂ« mĂ« VLAN, dhe pĂ«r tĂ« krijuar rrjete tĂ« reja nĂ« serverĂ«t e virtualizuar, nuk Ă«shtĂ« e nevojshme tĂ« krijoni VLAN me dorĂ«, kjo pĂ«rfundimisht «çmend» specialistĂ«t e rrjeteve tradicionale dhe i detyron ata tĂ« ngjiten pas qasjeve tĂ« njohura. Duhet tĂ« theksohet se Cisco pĂ«rpiqet tĂ« lehtĂ«sojĂ« pak gjĂ«rat dhe ka shtuar nĂ« kontrollues njĂ« CLI âNXOS-pĂ«rputhshĂ«mâ, i cili lejon konfigurimin nga njĂ« ndĂ«rfaqe, e ngjashme me komutatorĂ«t tradicionalĂ«. MegjithatĂ«, pĂ«r tĂ« filluar tĂ« shfrytĂ«zoni normalisht ACI-nĂ«, do tĂ« duhet tĂ« kuptoni se si funksionon.
Nga pikëpamja e çmimit në shkallë të madhe dhe mesatare, rrjeti ACI nga rrjetet tradicionale në pajisjet Cisco në fakt nuk dallon, pasi për ndërtimin e tyre përdoren të njëjtat switch-e (Nexus 9000 mund të funksionojë si në ACI ashtu edhe në mënyrë tradicionale dhe tani janë bërë "kali i punës" për projektet e reja të Qendrës së Të Dhënave). Megjithatë, për Qendrat e Të Dhënave me dy switch-e, prania e kontrollorëve dhe arkitekturës Spine-Leaf vërtet hahet. Së fundi u shfaq Mini ACI-fabrika, në të cilën dy kontrollorë nga tre janë zëvendësuar me makinat virtuale. Kjo lejon të reduktohet ndryshimi në kosto, por ai ende ekziston. Prandaj, për klientin, zgjedhja është e diktuar nga sa shumë është i interesuar për funksionalitetet e sigurisë, integrimit me virtualizimin, pikës së vetme të menaxhimit dhe të tjera.
Burimi: habr.com
