Me ndihmën e kësaj pjese magjike të skriptit Cisco ACI, mund të konfiguroni shpejt një rrjet.
Fabrika e rrjetit për qendrën e të dhënave Cisco ACI ekziston për pesë vjet, por Habré nuk tha asgjë për të, kështu që vendosa ta rregulloj pak. Unë do t'ju them nga përvoja ime se çfarë është, cili është përdorimi i tij dhe ku ka një grabujë.
Çfarë është dhe nga ka ardhur?
Në kohën kur ACI (Application Centric Infrastructure) u shpall në 2013, konkurrentët po përparonin në qasjet tradicionale ndaj rrjeteve të qendrave të të dhënave nga tre anët menjëherë.
Nga njëra anë, zgjidhjet e gjeneratës së parë SDN të bazuara në OpenFlow premtuan t'i bëjnë rrjetet më fleksibël dhe më të lirë në të njëjtën kohë. Ideja ishte të zhvendosej vendimmarrja e bërë tradicionalisht nga softueri komutues në pronësi në një kontrollues qendror.
Ky kontrollues do të kishte një vizion të vetëm për gjithçka që ndodh dhe, në bazë të kësaj, do të programonte harduerin e të gjithë switcheve në nivelin e rregullave për përpunimin e flukseve specifike.
Nga ana tjetër, zgjidhjet e mbivendosjes së rrjetit bënë të mundur zbatimin e politikave të nevojshme të lidhjes dhe sigurisë pa asnjë ndryshim fare në rrjetin fizik, duke ndërtuar tunele softuerësh midis hosteve të virtualizuar. Shembulli më i njohur i kësaj qasjeje ishte Nicira, e cila deri atëherë ishte blerë tashmë nga VMWare për 1,26 miliardë dollarë dhe i dha rritje VMWare NSX aktuale. Njëfarë pikante e situatës u shtua nga fakti se bashkëthemeluesit e Nicira ishin të njëjtët njerëz që më parë qëndronin në origjinën e OpenFlow, tani duke thënë se për të ndërtuar një fabrikë të qendrave të të dhënave .
Dhe së fundi, çipat komutues të disponueshëm në tregun e hapur (ajo që quhet silikoni tregtar) kanë arritur një fazë pjekurie ku janë bërë një kërcënim real për prodhuesit tradicionalë të çelësave. Nëse më parë secili shitës zhvilloi në mënyrë të pavarur çipa për çelsat e tij, atëherë me kalimin e kohës, çipat nga prodhuesit e palëve të treta, kryesisht nga Broadcom, filluan të zvogëlojnë distancën me çipat e shitësve për sa i përket funksioneve dhe i tejkaluan ato për sa i përket raportit çmim / performancë. Prandaj, shumë besuan se ditët e çelsave në çipat e dizajnit të tyre ishin të numëruara.
ACI është bërë "përgjigja asimetrike" e Cisco-s (më saktë, kompania e saj Insieme, e themeluar nga ish-punonjësit e saj) ndaj të gjitha sa më sipër.
Cili është ndryshimi me OpenFlow?
Për sa i përket shpërndarjes së funksioneve, ACI është në të vërtetë e kundërta e OpenFlow.
Në arkitekturën OpenFlow, kontrolluesi është përgjegjës për shkrimin e rregullave të detajuara (flukseve)
në harduerin e të gjithë ndërprerësve, domethënë në një rrjet të madh, ai mund të jetë përgjegjës për mirëmbajtjen dhe, më e rëndësishmja, ndryshimin e dhjetëra miliona të dhënave në qindra pika të rrjetit, kështu që performanca dhe besueshmëria e tij bëhen një pengesë në zbatim i madh.
ACI përdor qasjen e kundërt: natyrisht, ekziston edhe një kontrollues, por çelsat marrin politika deklarative të nivelit të lartë prej tij, dhe vetë ndërprerësi kryen paraqitjen e tyre në detaje të cilësimeve specifike në harduer. Kontrolluesi mund të rindizet ose fiket fare, dhe asgjë e keqe nuk do të ndodhë me rrjetin, përveç, natyrisht, mungesës së kontrollit në këtë moment. Është interesante se ka situata në ACI në të cilat OpenFlow përdoret ende, por në nivel lokal brenda hostit për programimin Open vSwitch.
ACI është ndërtuar tërësisht në transportin mbivendosje të bazuar në VXLAN, por përfshin transportin themelor IP si pjesë e një zgjidhjeje të vetme. Cisco e quajti këtë termi "mbivendosje e integruar". Si pikë përfundimi për mbivendosjet në ACI, në shumicën e rasteve përdoren çelsat e fabrikës (ata e bëjnë këtë me shpejtësinë e lidhjes). Hostëve nuk u kërkohet të dinë asgjë rreth fabrikës, kapsulimit, etj., megjithatë, në disa raste (për shembull, për të lidhur hostet e OpenStack), trafiku VXLAN mund të sillet tek ata.
Mbivendosjet përdoren në ACI jo vetëm për të siguruar lidhje fleksibël përmes rrjetit të transportit, por edhe për të transferuar metainformacion (për shembull, përdoret për të aplikuar politikat e sigurisë).
Çipat nga Broadcom janë përdorur më parë nga Cisco në çelsat e serisë Nexus 3000. Në familjen Nexus 9000, të lëshuar posaçërisht për të mbështetur ACI, fillimisht u zbatua një model hibrid, i cili u quajt Merchant +. Ndërprerësi përdori njëkohësisht çipin e ri Broadcom Trident 2 dhe një çip plotësues të zhvilluar nga Cisco, i cili zbaton të gjithë magjinë e ACI. Me sa duket, kjo bëri të mundur përshpejtimin e lëshimit të produktit dhe uljen e çmimit të çelësit në një nivel afër modeleve të bazuara thjesht në Trident 2. Kjo qasje ishte e mjaftueshme për dy ose tre vitet e para të dërgesave të ACI. Gjatë kësaj kohe, Cisco zhvilloi dhe lansoi gjeneratën e ardhshme Nexus 9000 në çipat e tij me më shumë performancë dhe grup funksionesh, por me të njëjtin nivel çmimi. Specifikimet e jashtme për sa i përket ndërveprimit në fabrikë janë plotësisht të ruajtura. Në të njëjtën kohë, mbushja e brendshme ka ndryshuar plotësisht: diçka si rifaktorimi, por për hekurin.
Si funksionon arkitektura Cisco ACI
Në rastin më të thjeshtë, ACI është ndërtuar mbi topologjinë e rrjetit Klose, ose, siç thonë shpesh, Spine-Leaf. Ndërprerësit e nivelit të shtyllës kurrizore mund të jenë nga dy (ose një, nëse nuk na intereson toleranca e gabimeve) në gjashtë. Prandaj, sa më shumë prej tyre, aq më e lartë është toleranca e defektit (aq më e ulët është gjerësia e brezit dhe reduktimi i besueshmërisë në rast aksidenti ose mirëmbajtjeje të një shtylle kurrizore) dhe performanca e përgjithshme. Të gjitha lidhjet e jashtme shkojnë te çelsat e nivelit të fletës: këta janë serverë dhe lidhje me rrjetet e jashtme nëpërmjet L2 ose L3, dhe lidhja e kontrollorëve APIC. Në përgjithësi, me ACI, jo vetëm konfigurimi, por edhe mbledhja e statistikave, monitorimi i dështimeve etj. - gjithçka bëhet përmes ndërfaqes së kontrolluesve, prej të cilëve tre janë në zbatime me madhësi standarde.
Asnjëherë nuk duhet të lidheni me çelsat me tastierë, madje edhe për të nisur rrjetin: vetë kontrolluesi zbulon çelsat dhe mbledh një fabrikë prej tyre, duke përfshirë cilësimet e të gjitha protokolleve të shërbimit, prandaj, nga rruga, është shumë e rëndësishme të shkruani numrat serial të pajisjeve që instalohen gjatë instalimit, në mënyrë që më vonë të mos keni nevojë të merrni me mend se cili çelës është në cilin raft ndodhet. Për zgjidhjen e problemeve, nëse është e nevojshme, mund të lidheni me çelësat përmes SSH: ata riprodhojnë komandat e zakonshme të shfaqjes Cisco me mjaft kujdes.
Në brendësi, fabrika përdor transportin IP, kështu që nuk ka në të "Spanning Tree" dhe tmerre të tjera të së kaluarës: të gjitha lidhjet janë të përfshira dhe konvergjenca në rast dështimesh është shumë e shpejtë. Trafiku në pëlhurë transmetohet përmes tuneleve të bazuara në VXLAN. Më saktësisht, vetë Cisco e quan iVXLAN encapsulation, dhe ndryshon nga VXLAN i rregullt në atë që fushat e rezervuara në kokën e rrjetit përdoren për të transmetuar informacionin e shërbimit, kryesisht në lidhje me marrëdhënien e trafikut me grupin EPG. Kjo ju lejon të zbatoni rregullat e ndërveprimit midis grupeve në pajisje, duke përdorur numrat e tyre në të njëjtën mënyrë siç përdoren adresat në listat e zakonshme të aksesit.
Tunelet lejojnë që të dy segmentet L2 dhe segmentet L3 (d.m.th. VRF) të shtrihen përmes transportit të brendshëm IP. Në këtë rast, porta e paracaktuar shpërndahet. Kjo do të thotë se çdo ndërprerës është përgjegjës për drejtimin e trafikut që hyn në pëlhurë. Për sa i përket logjikës së rrjedhës së trafikut, ACI është i ngjashëm me një pëlhurë VXLAN/EVPN.
Nëse po, cilat janë ndryshimet? Gjithçka tjetër!
Dallimi numër një që hasni me ACI është se si serverët janë të lidhur me rrjetin. Në rrjetet tradicionale, përfshirja e serverëve fizikë dhe e makinave virtuale shkon në VLAN dhe gjithçka tjetër kërcen prej tyre: lidhja, siguria, etj. Në ACI, përdoret një dizajn që Cisco e quan EPG (End-point Group), nga i cili nuk ka ku të ikë. Nëse është e mundur të barazohet me VLAN? Po, por në këtë rast ka një shans për të humbur pjesën më të madhe të asaj që jep ACI.
Në lidhje me EPG, të gjitha rregullat e aksesit janë formuluar, dhe në ACI, parimi i "listës së bardhë" përdoret si parazgjedhje, domethënë lejohet vetëm trafiku, kalimi i të cilit lejohet në mënyrë eksplicite. Kjo do të thotë, ne mund të krijojmë grupet EPG "Web" dhe "MySQL" dhe të përcaktojmë një rregull që lejon komunikimin midis tyre vetëm në portin 3306. Kjo do të funksionojë pa u lidhur me adresat e rrjetit dhe madje edhe brenda të njëjtit nënrrjet!
Kemi klientë që kanë zgjedhur ACI-në pikërisht për shkak të kësaj veçorie, pasi ju lejon të kufizoni aksesin midis serverëve (virtuale ose fizikë - nuk ka rëndësi) pa i zvarritur ato midis nën-rrjeteve, që do të thotë pa prekur adresimin. Po, po, ne e dimë që askush nuk përshkruan adresat IP në konfigurimin e aplikacioneve me dorë, apo jo?
Rregullat e komunikacionit në ACI quhen kontrata. Në një kontratë të tillë, një ose më shumë grupe ose nivele në një aplikacion me shumë nivele bëhen një ofrues shërbimi (të themi, një shërbim bazë të dhënash), të tjerët bëhen konsumator. Kontrata thjesht mund të kalojë trafikun, ose mund të bëjë diçka më të ndërlikuar, për shembull, ta drejtojë atë në një mur zjarri ose balancues, dhe gjithashtu të ndryshojë vlerën QoS.
Si futen serverët në këto grupe? Nëse këta janë serverë fizikë ose diçka të përfshirë në një rrjet ekzistues në të cilin kemi krijuar një trunk VLAN, atëherë për t'i vendosur ato në EPG, do t'ju duhet të tregoni portin e ndërprerës dhe VLAN-in e përdorur në të. Siç mund ta shihni, VLAN-et shfaqen aty ku nuk mund të bëni pa to.
Nëse serverët janë makina virtuale, atëherë mjafton t'i referoheni mjedisit të lidhur të virtualizimit dhe më pas gjithçka do të ndodhë vetvetiu: do të krijohet një grup portesh (për sa i përket VMWare) për të lidhur VM-në, VLAN-et ose VXLAN-et e nevojshme do të të caktohen, ato do të regjistrohen në portat e nevojshme të switch-it, etj. Pra, megjithëse ACI është ndërtuar rreth një rrjeti fizik, lidhjet për serverët virtualë duken shumë më të thjeshta se sa për ato fizike. ACI tashmë ka lidhje të integruar me VMWare dhe MS Hyper-V, si dhe mbështetje për Virtualizimin OpenStack dhe RedHat. Nga një moment e tutje, është shfaqur edhe mbështetja e integruar për platformat e kontejnerëve: Kubernetes, OpenShift, Cloud Foundry, ndërsa ka të bëjë si me aplikimin e politikave ashtu edhe me monitorimin, domethënë, administratori i rrjetit mund të shohë menjëherë se cilët hostë në cilat pods punojnë dhe në cilat grupe bëjnë pjesë.
Përveç përfshirjes në një grup portesh të veçantë, serverët virtualë kanë veti shtesë: emri, atributet, etj., të cilat mund të përdoren si kritere për transferimin e tyre në një grup tjetër, të themi, kur një VM riemërohet ose kur shfaqet një etiketë shtesë në atë. Cisco e quan këtë grupe mikro-segmentimi, megjithëse, në përgjithësi, vetë dizajni me aftësinë për të krijuar shumë segmente sigurie në formën e EPG-ve në të njëjtin nën-rrjet është gjithashtu një mikro-segmentim. Epo, shitësi e di më mirë.
Vetë EPG-të janë konstruksione thjesht logjike, jo të lidhura me ndërprerës, serverë, etj., kështu që mund të bëni gjëra me to dhe konstruksione të bazuara në to (aplikacione dhe qiramarrës) që janë të vështira për t'u bërë në rrjetet e zakonshme, si p.sh. klonimi. Si rezultat, le të themi se është shumë e lehtë të klonosh një mjedis prodhimi për të marrë një mjedis testimi që garantohet të jetë identik me mjedisin e prodhimit. Mund ta bëni manualisht, por është më mirë (dhe më e lehtë) përmes API-së.
Në përgjithësi, logjika e kontrollit në ACI nuk është aspak e ngjashme me atë që takoni zakonisht
në rrjetet tradicionale nga i njëjti Cisco: ndërfaqja e softuerit është parësore, dhe GUI ose CLI janë dytësore, pasi ato punojnë përmes të njëjtit API. Prandaj, pothuajse të gjithë të përfshirë në ACI, pas një kohe, fillojnë të lundrojnë në modelin e objektit të përdorur për menaxhim dhe të automatizojnë diçka për t'iu përshtatur nevojave të tyre. Mënyra më e lehtë për ta bërë këtë është nga Python: ka mjete të përshtatshme të gatshme për të.
Grabujë e premtuar
Problemi kryesor është se shumë gjëra në ACI bëhen ndryshe. Për të filluar punën me të normalisht, duhet të ritrajnoheni. Kjo është veçanërisht e vërtetë për ekipet e operacioneve të rrjetit në klientë të mëdhenj, ku inxhinierët kanë "përshkruar VLAN" për vite sipas kërkesës. Fakti që tani VLAN-të nuk janë më VLAN dhe nuk keni nevojë të krijoni VLAN me dorë për të vendosur rrjete të reja në hostet e virtualizuar, i hedh plotësisht çatinë e rrjeteve tradicionale dhe i bën ata të kapen pas qasjeve të njohura. Duhet të theksohet se Cisco u përpoq ta ëmbëlsonte pak pilulën dhe shtoi një CLI "si NXOS" në kontrollues, i cili ju lejon të bëni konfigurimin nga një ndërfaqe e ngjashme me çelësat tradicionalë. Por prapëseprapë, në mënyrë që të filloni të përdorni ACI normalisht, duhet të kuptoni se si funksionon.
Për sa i përket çmimit, në shkallë të mëdha dhe të mesme, rrjetet ACI në fakt nuk ndryshojnë nga rrjetet tradicionale në pajisjet Cisco, pasi të njëjtat ndërprerës përdoren për t'i ndërtuar ato (Nexus 9000 mund të funksionojë në ACI dhe në modalitetin tradicional dhe tani janë bërë kryesore "kalë pune" për projektet e reja të qendrës së të dhënave). Por për qendrat e të dhënave të dy ndërprerësve, prania e kontrolluesve dhe arkitektura Spine-Leaf, natyrisht, e bëjnë veten të ndjehen. Kohët e fundit është shfaqur një fabrikë Mini ACI, në të cilën dy nga tre kontrollorët janë zëvendësuar me makina virtuale. Kjo zvogëlon diferencën në kosto, por ajo ende mbetet. Pra, për klientin, zgjedhja diktohet nga interesi i tij për veçoritë e sigurisë, integrimi me virtualizimin, një pikë e vetme kontrolli, etj.
Burimi: www.habr.com