Me ndihmën e këtij skripti magjik Cisco ACI, mund të konfiguroni rrjetin shpejt.
Fabrika rrjetësore për Qendrat e të Dhënave Cisco ACI ekziston për pesë vjet, por nuk është folur shumë për të në Habrë, kështu që vendosa ta korrigjoj këtë pak. Do të flas nga përvoja ime se çfarë është, cila është përfitimi i saj dhe ku ndodhen pengesat.
Çfarë është dhe nga erdhi?
Në momentin e njoftimit të ACI (Application Centric Infrastructure) në vitin 2013, konkurentët e qendrave të të dhënave po i qasnin qasjeve tradicionale të rrjetit nga tri anët.
Nga njëra anë, zgjidhjet SDN "të gjeneratës së parë" të bazuara në OpenFlow premtonin të bënin rrjetet më fleksibël dhe më të përballueshme njëherësh. Ideja ishte që të transferohej marrja e vendimeve, e cila tradicionalisht përfaqësohej nga softi i pronarëve të përSwitch-ave, në një kontroler qendror.
Ky kontroler do të kishte një pamje të vetme të gjithçkaje që ndodhte dhe, duke u bazuar në këtë, do të programonte pajisjet e të gjitha switch-ave në nivelin e rregullave për trajtimin e flukseve specifike.
Nga ana tjetër, zgjidhjet rrjetësore me ovelay ofronin mundësinë për të arritur lidhshmëri dhe politika sigurie pa bërë ndryshime në rrjetin fizik, duke ndërtuar tunelë programorë mes hosteve të virtualizuara. Një shembull i njohur i një qasjeje të tillë ishte zgjidhja nga Nicira, e cila në atë kohë ishte blerë nga VMWare për 1.26 miliardë dollarë dhe dha fillimin e VMWare NSX. Një pikë këndore e situatës ishte se bashkëthemeluesit e Nicira ishin ata të njëjtit që më parë ishin në fillimet e OpenFlow, tani duke thënë se për ndërtimin e fabrikave të Qendrave të të Dhënave OpenFlow nuk ishte i përshtatshëm. .
Dhe, përfundimisht, çipat e switch-ave në treg (ato që quhen merchant silicon) arritën një shkallë pjekurie, duke u bërë një kërcënim real për prodhuesit tradicionalë të switch-ave. Nëse më parë çdo ofrues zhvillonte vetë çipat e tij për switch-at, me kalimin e kohës, çipat nga prodhues të jashtëm, kryesisht nga Brоadcom, filluan të ngushtojnë distancën me çipat e ofruesve për funksionalitetet, ndërsa për raportin çmim/përformancë i tejkalonin ata. Prandaj, shumë mendonin se ditët e switch-ave me çipa të zhvilluar vetë i ishin count.
ACI u bë "përgjigjja asimetrike" e Cisco (më saktësisht, e kompanisë Insieme, e cila ishte themeluar nga ish-punonjësit e saj) ndaj gjithçkaje të përmendur më parë.
Cila është dallimi me OpenFlow?
Në aspektin e shpërndarjes së funksioneve, ACI është faktikisht e kundërta e OpenFlow.
Në arkitekturën OpenFlow, kontrolluesi është përgjegjës për shkrimin e rregullave të detajuara (flukseve)
në pajisjet e të gjitha switch-ave, domethënë në një rrjet të madh, ai mund të ketë përgjegjësinë për mbajtjen dhe, më e rëndësishmja, ndryshimin e dhjetëra miliona regjistrimeve në qindra pika në rrjet, prandaj performanca dhe besueshmëria e saj në një implementim të madh bëhen një ngushticë.
Në ACI, përdoret një qasje e kundërt: ka gjithashtu një kontroler, por switch-avat marrin nga ai politika deklarative të niveleve të larta, ndërsa realizimi i detajeve të konfigurimeve specifike në pajisje kryhet nga vetë switch-i. Kontrolluesi mund të ribëhet ose madje të fiket, dhe nuk do ndodhi asgjë e keqe me rrjetin, përveç, natyrisht, mungesës në atë moment të mundësisë për menaxhim. Është e interesantë se në ACI ekzistojnë situata ku OpenFlow ende përdoret, por lokalizuar brenda hostit për programimin e Open vSwitch.
ACI është plotësisht e ndërtuar mbi transportin ovelay të bazuar në VXLAN, por përfshin gjithashtu transportin IP të poshtëm brenda një zgjidhje të vetme. Cisco e quajti këtë termin "ovelaj i integruar". Për pikën e terminimit të ovelave në ACI, në shumicën e rasteve përdoren switch-avat e fabrikës (e bëjnë këtë me shpejtësi kanali). Hostet nuk duhet të dinë asgjë për fabrikën, inkapsulimet etj., por në disa raste (për shembull, për të lidhur hostet OpenStack) trafiku VXLAN mund të arrijë tek ta.
Ovelat përdoren në ACI jo vetëm për të siguruar lidhshmëri fleksibile përmes rrjetit të transportit, por edhe për të transmetuar meta-informacion (ai përdoret, për shembull, për zbatimin e politikave të sigurise).
Çipat nga Broadcom janë përdorur më parë nga Cisco në ndërprerësit e serisë Nexus 3000. Në familjen Nexus 9000, e cila u lëshua posaçërisht për të mbështetur ACI, u zbatua fillimisht një model hibrid, të cilin e quajtën Merchant+. Në ndërprerës, u përdorën njëkohësisht çipi i ri Broadcom Trident 2 dhe një çip mbështetje nga Cisco, i cili realizon të gjithë magjinë e ACI. Duket se kjo ka lejuar përshpejtimin e daljes së produktit dhe uljen e çmimeve të ndërprerësit në një nivel të afërt me modelet që përdorin vetëm 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 lëshoi në treg brezin e ardhshëm të Nexus 9000, tashmë në çipat e saj me performancë më të lartë dhe një set funksionesh, por me të njëjtin nivel çmimi. Specifikimet e jashtme në aspektin e ndërveprimit në fabrikë kanë mbetur plotësisht të pandryshuar. Ndërkohë, brendësia e saj ka ndryshuar plotësisht: një lloj refaktorizimi, por për harduerin.
Si është struktura e arkitekturës Cisco ACI
Në rastin më të thjeshtë, ACI ndërtohet mbi një topologji të rrjetit Clos, ose, siç quhet shpesh, Spine-Leaf. Numri i ndërprerësve të nivelit Spine mund të jetë nga dy (ose një, nëse nuk na intereson disponueshmëria) në gjashtë. Prandaj, sa më shumë të jenë, aq më e lartë është disponueshmëria (më pak ulje e brezit të dhënash dhe besueshmërisë gjatë dështimeve ose mirëmbajtjes së një Spine) dhe performanca totale. Të gjitha lidhjet e jashtme shkojnë në ndërprerësit e nivelit Leaf: këtu bëjnë pjesë serverët, lidhjet me rrjetet e jashtme përmes L2 ose L3, dhe lidhja e kontrolerëve APIC. Në përgjithësi, me ACI jo vetëm konfigurimi, por edhe mbledhja e statistikave, monitorimi i dështimeve dhe gjërat e tjera — gjithçka bëhet përmes ndërfaqeve të kontrolerëve, të cilët në vendosjet e zakonshme janë tre.
Këto ndërprerës nuk lidhin kurrë me konsolë, as për të filluar rrjetin: kontroleri vetë zbulon ndërprerësit dhe krijon fabrikën prej tyre, duke përfshirë konfigurimet e të gjitha protokolleve shërbimi, prandaj, është shumë e rëndësishme që gjatë montimit të regjistrohen numrat serial të pajisjeve që instalohet, në mënyrë që më vonë të mos hamendësojmë se cili ndërprerës është në cilin raft. Për zgjidhjen e problemeve, nëse është e nevojshme, mund të lidhemi me ndërprerësit përmes SSH: në to janë të riprodhuara tërësisht komandat e zakonshme show të Cisco.
Brenda fabrikës përdor transportin IP, kështu që nuk ka Spanning Tree dhe katastrofat e tjera të të kaluarës: të gjitha lidhjet janë aktivizuar dhe konvergjenca gjatë dështimeve është shumë e shpejtë. Trafiku në fabrikë dërgohet përmes tuneleve të bazuara në VXLAN. Nëse saktësisht, Cisco e quan incapsulimin 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, së pari - në lidhje me lidhjen e trafikut me grupin EPG. Kjo lejon realizimin e rregullave të ndërveprimit midis grupeve në harduer, duke përdorur numrat e tyre ashtu siç përdoren adresat në listat e zakonshme të aksesit.
Tunelet lejojnë shtrirjen përmes transportit të brendshëm IP dhe segmenteve L2 dhe L3 (domethënë VRF). Në të njëjtën kohë, gateway i paracaktuar është i shpërndarë. Kjo do të thotë se çdo ndërprerës merret me rrugëtimin e trafikut që hyn në fabrikë. Në aspektin e logjikës së transmetimit të trafikut, ACI është e ngjashme me një fabrikë të bazuar në VXLAN/EVPN.
Nëse është kështu, atëherë çfarë dallimesh ka?
Dallimi numër një, me të cilin përballeni në ACI, është se si serverët lidhen në rrjet. Në rrjetet tradicionale, lidhja e serverëve fizikë dhe virtualëve bëhet në VLAN, dhe nga ata gjithçka tjetër rrjedh: lidhshmëria, siguria etj. Në ACI përdoret një konstrukcion që Cisco e quan EPG (Grupi i Pikave përfundimtare), i cili është i paevitueshëm. A mund të barazohet ajo me VLAN? Po, por në këtë rast ka një shans të humbasësh një pjesë të madhe të asaj që ofron ACI.
Të gjitha rregullat e aksesit formulohen në lidhje me EPG, dhe në ACI, sipas parazgjedhjes, përdoret parimi i "listës së bardhë", do të thotë se vetëm trafiku, kalimi i të cilit është lejuar në mënyrë të qartë, është i lejuar. Domethënë, ne mund të krijojmë grupe EPG "Web" dhe "MySQL" dhe të përcaktojmë një rregull që lejon bashkëpunimin midis tyre vetëm përmes portit 3306. Kjo do të funksionojë pa iu referuar adresave të rrjetit dhe madje brenda një nëndeshme!
Kemi klientë që kanë zgjedhur ACI për shkak të kësaj veçori, pasi ajo lejon kufizimin e qasjeve midis serverëve (virtualë apo fizikë - nuk ka rëndësi), pa i zhvendosur ato midis nëndeshmeve, pra pa prekur adresimin. Po, e dimë, askush nuk i shkruan me dorë adresat IP në konfigurimet e aplikacioneve, apo jo?
Rregullat e kalimit të trafikut në ACI quhen kontrata. Në një kontratë, një ose më shumë grupe ose nivele në një aplikacion multi-tier bëhen ofrues të shërbimit (le të themi, shërbimi i bazës së të dhënave), ndërsa të tjerët janë konsumatorë. Kontrata mund thjesht të kalojë trafikun, apo të bëjë diçka më të sofistikuar, siç është drejtuar në një firewall ose balancues trafiku, si dhe të ndryshojë vlerën e QoS.
Si arrijnë serverat në këto grupe? Nëse janë servera fizikë ose diçka e përfshirë në një rrjet ekzistues, në të cilin kemi krijuar një VLAN trunk, atëherë për t'i futur në EPG duhet të ceket porta e switch-it dhe VLAN-i përdorur aty. Siç e shohim, VLAN-et shfaqen aty ku nuk mund të veprohet pa to.
Nëse serverat janë virtualë, mjafton të referohet mjedisi i virtualizimit të lidhur, dhe më pas gjithçka ndodhi vetë: krijohet një grup porte (nëse flasim në terma - VMWare) për lidhjen e VM, i caktohen VLAN-et ose VXLAN-et e nevojshme, shkruhen në portat e nevojshme të switch-ëve etj. Pra, edhe pse ACI është ndërtuar rreth një rrjeti fizik, lidhjet për serverat virtualë duken shumë më të thjeshta se për ata fizikë. ACI ka tashmë të ndërthurur integrimin me VMWare dhe MS Hyper-V, si dhe mbështetje për OpenStack dhe RedHat Virtualization. Që nga një moment i caktuar, u shfaq edhe mbështetje e integruar për platforma konteinerësh: Kubernetes, OpenShift, Cloud Foundry, ndërsa kjo ndikon gjithashtu në aplikimin e politikave dhe monitorimin, dmth, administratorët e rrjetit mund të shohin menjëherë se në cilat hoste cilat pods punojnë dhe në cilat grupe kanë përfunduar.
Përveç përfshirjes në një grup porte ose tjetër, serverat virtualë kanë vlera shtesë: emri, atributet etj., të cilat mund të përdoren si kritere për t'i kaluar në një grup tjetër, le të themi, kur VM riemërohet ose kur merr një etiketë shtesë. Cisco e quan këtë grupe mikrosigmentimi, megjithatë, në thelb, struktura vetë me mundësinë për të krijuar shumë segmente sigurie në formën e EPG në të njëjtin subnet - është gjithashtu mikrosigmentim. Epo, është më mirë që kjo t'i takojë ofruesit.
EPG-të janë struktura krejt logjike, të papërthyera me switch-e specifikë, serverë etj., kështu që me to dhe struktura që krijohen mbi to (aplikacionet dhe qira) mund të bëjmë gjëra që janë të vështira për t'u realizuar në rrjetet tradicionale, siç është klonimi. Si rezultat, është shumë e lehtë të krijosh një klon të mjedisit produktiv për të marrë një mjedis testimi që është garantsht identik me produktivin. Mund të bëhet manualisht, por është më mirë (dhe më e thjeshtë) përmes API.
Logjika e menaxhimit në ACI është krejt ndryshe nga ajo që zakonisht haset
në rrjetet tradicionale nga Cisco e për të cilat zakonisht ka përvojë: 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ë orientohet në modelin objektit që përdoret për menaxhim, dhe të automatizojë diçka sipas nevojave të tij. Është më e lehtë të bëhet nga Python: për të ka mjete të gatshme dhe të përshtatshme.
Gropa të premtuara
Problemi kryesor është se shumë gjëra në ACI janë bërë ndryshe. Për të filluar të punoni normalisht me të, duhet të ri-edukohemi. Kjo vlen veçanërisht për ekipet e operimit të rrjetit te klientët e mëdhenj, ku inxhinierët punojnë për vite me radhë me "përshkrimin e VLAN-eve" sipas kërkesave. Ajo që tani është VLAN - nuk është më VLAN, dhe për të krijuar rrjete të reja në hostet e virtualizuar nuk është e nevojshme të krijohen VLAN-e me dorë, kjo po e "shkatërron" mendjen e rrjetarëve tradicionalë dhe i detyron ata të mbahen pas qasjeve të zakonshme. Duhet të theksohet se Cisco ka përpiqur të ëmbëlsojë disi pilulën dhe ka shtuar një CLI "NXOS-përjashë", që lejon konfigurimin nga një ndërfaqe që ngjan me switch-et tradicionale. Por gjithsesi, për të filluar të përdorë ACI në mënyrë normale, do të jetë e nevojshme të kuptohet si funksionon ajo.
Sa i përket çmimit në rrjetet ACI në shkallët e mëdha dhe të mesme, ato faktikisht nuk ndryshojnë nga ato tradicionale në pajisjet Cisco, pasi për ndërtimin e tyre përdoren switch-e të njëjtë (Nexus 9000 mund të punojnë si në ACI ashtu edhe në modin tradicional dhe tani janë "kuaj pune" kryesor për projektet e reja të qendrave të të dhënave). Nga ana tjetër, për Qendrat e Të Dhënave nga dy switch-e, prania e kontrollorëve dhe arkitekturës Spine-Leaf sigurisht që ndihen. Së fundmi, u shfaq Mini ACI-fabrika, në të cilën dy kontrollorë nga tre janë zëvendësuar me makina virtuale. Kjo lejon të reduktohet diferenca në kostos, por ajo mbetet gjithsesi. Pra, për klientin, zgjedhja përcaktohet nga sa i interesuar është ai për funksionalitetin e sigurisë, integrimin me virtualizimin, pikën e vetme të menaxhimit dhe gjëra të tjera.
Burimi: habr.com
