Cisco ACI script-aren zati magiko honen laguntzaz, sare bat azkar konfigura dezakezu.
Cisco ACI datu-zentroaren sare-ehunak bost urte daramatza, baina HabrΓ©-n ez da ezer esaten horri buruz, beraz, pixka bat konpontzea erabaki nuen. Nire esperientziatik esango dizut zer den, zein onurak dituen eta non dagoen bere arrastoa.
Zer da hau eta nondik atera da?
2013an ACI (Application Centric Infrastructure) iragarri zenerako, datu-zentroen sareen ikuspegi tradizionalak hiru aldetako lehiakideek erasotzen zituzten aldi berean.
Alde batetik, OpenFlow-en oinarritutako "lehen belaunaldiko" SDN soluzioek sareak malguagoak eta aldi berean merkeagoak izango zirela hitzeman zuten. Ideia zen erabakiak hartzeko, tradizioz jabedun etengailuaren softwareak kudeatzen dituena, kontrolagailu zentral batera eramatea.
Kontrolagailu honek gertatzen den guztiaren ikuspegi bateratua izango luke eta, horretan oinarrituta, etengailu guztien ekipamendua programatuko luke fluxu zehatzak prozesatzeko arauen mailan.
Bestalde, sare fisikoaren gainjartze-soluzioek nahi diren konektibitate- eta segurtasun-politikak ezartzea ahalbidetu zuten, sare fisikoan inolako aldaketarik gabe, ostalari birtualizatuen artean software-tunelak eraikiz. Planteamendu horren adibiderik ospetsuena Nicira-ren irtenbidea izan zen, ordurako VMWarek 1,26 milioi dolarren truke eskuratu zuena eta egungo VMWare NSX sortu zuena. Egoerari pikagarritasuna gehitu zitzaiona izan zen Nicira-ren sortzaileak lehen OpenFlow-en jatorrian zeuden pertsona berberak zirela, eta orain datu-zentroen fabrika bat eraikitzeko esan zutenak. .
Eta, azkenik, merkatu irekian eskuragarri dauden switch-txipak (merchant silizioa deitzen dena) heldutasun-maila bat lortu dute, non etengailuen fabrikatzaile tradizionalen benetako mehatxu bihurtu diren. Lehenago saltzaile bakoitzak bere etengailuetarako txipak garatu bazituen, denborarekin, hirugarrenen fabrikatzaileen txipak, batez ere Broadcomenak, saltzaileen txipekin distantzia ixten hasi ziren funtzioei dagokienez, eta prezio/errendimendu erlazioan gainditu zituzten. Hori dela eta, askok uste zuten txip jabedunen etengailuen egunak zenbatuta zeudela.
ACI Ciscoren "erantzun asimetrikoa" bihurtu zen (zehazkiago, bere parte zen Insieme enpresa, bere langile ohiek sortua) aurreko guztiari.
Zein desberdintasun dago OpenFlow-ekin?
Funtzioen banaketari dagokionez, ACI OpenFlow-en kontrakoa da.
OpenFlow arkitekturan, kontrolatzailea arau zehatzak (fluxuak) idazteaz arduratzen da.
etengailu guztien hardwarean, hau da, sare handi batean, sareko ehunka puntutan hamar milioi erregistro mantentzeaz eta, batez ere, aldatzeaz arduratu daiteke, beraz, bere errendimendua eta fidagarritasuna hedapen handi batean bilakatzen dira. botila-lepo bat.
ACI-k kontrako ikuspegia erabiltzen du: noski, kontroladore bat dago, baina etengailuek maila altuko politika deklaratiboak jasotzen dituzte bertatik, eta etengailuak berak hardwareko ezarpen zehatzen xehetasunak bihurtzen ditu. Kontrolagailua berrabiarazi edo itzali daiteke guztiz, eta ez zaio ezer txarrik gertatuko sareari, une honetan kontrol falta izan ezik, noski. Interesgarria da ACIn oraindik OpenFlow erabiltzen den egoerak, baina lokalean Open vSwitch programaziorako ostalariaren barruan.
ACI VXLAN-en oinarritutako gainjarri-garraioan eraikita dago guztiz, baina azpian dagoen IP garraioa ere barne hartzen du soluzio bakar baten zati gisa. Ciscok "gainjartze integratua" terminoa deitu zion. Gehienetan, ehuneko etengailuak ACIn gainjartzeen amaiera-puntu gisa erabiltzen dira (esteka abiaduran egiten dute hori). Ostalariek ez dute derrigorrezkoa ehunari, kapsulatzeari eta abarri buruz ezer jakitea, hala ere, kasu batzuetan (esaterako, OpenStack ostalariak konektatzeko), VXLAN trafikoa ekar daiteke.
Gainjartzeak ACIn erabiltzen dira garraio-sarean konektagarritasun malgua eskaintzeko ez ezik, metainformazioa transmititzeko ere (erabiltzen dira, adibidez, segurtasun-politikak betearazteko).
Broadcom-eko txipak Cisco-k erabiltzen zituen Nexus 3000 serieko etengailuetan. Nexus 9000 familiak, bereziki ACI onartzeko kaleratua, Merchant+ izeneko eredu hibrido bat ezarri zuen hasieran. Etengailuak Broadcom Trident 2 txip berria eta Ciscok garatutako txip osagarri bat erabili zituen aldi berean, ACIren magia guztia ezartzen duena. Antza denez, honek produktuaren kaleratzea bizkortu eta etiketa-prezioa murriztea Trident 2-n oinarritutako ereduetatik hurbil dagoen mailara murriztea ahalbidetu zuen. Planteamendu hau nahikoa izan zen ACIren bi edo hiru urteetarako. Denbora horretan, Ciscok hurrengo belaunaldiko Nexus 9000 garatu eta abiarazi zuen bere txipetan, errendimendu eta funtzio multzo handiagoarekin, baina prezio maila berean. Fabrikan elkarrekintzaren ikuspuntutik kanpoko zehaztapenak guztiz gordetzen dira. Aldi berean, barruko betegarria guztiz aldatu da: refactoring bezalako zerbait, baina hardwarerako.
Nola funtzionatzen duen Cisco ACI arkitekturak
Kasurik sinpleenean, ACI Clos sarearen topologiaren arabera eraikitzen da, edo, askotan esaten den bezala, Spine-Leaf. Bizkarrezurreko etengailuak bitik (edo bat, akatsen tolerantziaz arduratzen ez bagara) sei artekoak izan daitezke. Horren arabera, zenbat eta gehiago izan, orduan eta handiagoa izango da akatsen tolerantzia (banda-zabalera eta fidagarritasunaren murrizketa txikiagoa Bizkarrezurra baten istripua edo mantentze-lanak gertatuz gero) eta errendimendu orokorra. Kanpoko konexio guztiak Leaf mailako etengailuetara doaz: zerbitzariak, kanpoko sareetara konektatzea L2 edo L3 bidez eta APIC kontrolagailuen konexioa. Oro har, ACI-rekin, konfigurazioa ez ezik, estatistiken bilketa, hutsegiteen jarraipena eta abar ere - dena kontrolagailuen interfazearen bidez egiten da, horietatik hiru tamaina erregularreko inplementazioetan.
Inoiz ez duzu etengailuetara kontsola batekin konektatu behar, baita sarea martxan jartzeko ere: kontrolagailuak berak detektatzen ditu etengailuak eta haietatik fabrika bat muntatzen du, zerbitzu-protokolo guztien ezarpenak barne. Horregatik, bide batez, oso garrantzitsua da idaztea. instalatutako ekipoen serie-zenbakiak jaitsi instalazioan, gerora ez dadin asmatu behar zein etengailu dagoen zein racktan kokatuta dagoen? Arazoak konpontzeko, behar izanez gero, etengailuetara konekta zaitezke SSH bidez: ohiko Cisco show komandoak arreta handiz erreproduzitzen dira horietan.
Barruan, fabrikak IP garraioa erabiltzen du, beraz, ez dago Spanning Tree edo iraganeko beste izugarrikeriarik: lotura guztiak erabiltzen dira, eta hutsegiteen kasuan konbergentzia oso azkarra da. Ehuneko trafikoa VXLANen oinarritutako tunelen bidez egiten da. Zehatzago esanda, Ciscok berak iVXLAN enkapsulazioa deitzen du, eta VXLAN arruntaren desberdina da sareko goiburuko eremu erreserbatuak zerbitzuaren informazioa transmititzeko erabiltzen direlako, batez ere EPG taldearekiko trafikoaren erlazioari buruzkoa. Horri esker, ekipoko taldeen arteko elkarrekintza-arauak ezar ditzakezu, haien zenbakiak erabiliz, helbideak sarbide-zerrendetan ohikoak diren moduan.
Tunelek L2 eta L3 segmentuak (hau da, VRF) luzatzeko aukera ematen dute IP barneko garraioaren bidez. Kasu honetan, atebide lehenetsia banatzen da. Horrek esan nahi du switch bakoitza ehunera sartzen den trafikoa bideratzeaz arduratzen dela. Trafiko transferentzia-logikari dagokionez, ACI VXLAN/EVPN oinarritutako ehun baten antzekoa da.
Hala bada, zein dira aldeak? Beste guztia!
ACIn aurkitzen duzun lehen aldea zerbitzariak sarera nola konektatzen diren da. Sare tradizionaletan, zerbitzari fisikoak zein makina birtualak sartzea VLANetan sartzen da, eta beste guztia horietatik dantzan jartzen da: konektibitatea, segurtasuna... ihes. VLAN batekin parekatu al daiteke? Bai, baina kasu honetan ACIk ematen duen gehiena galtzeko aukera dago.
Sarbide-arau guztiak EPGri dagokionez formulatzen dira, eta ACIn, lehenespenez, "zerrenda zuria" printzipioa erabiltzen da, hau da, trafikoa soilik onartzen da, berariaz baimenduta dagoen hori igarotzea. Hau da, "Web" eta "MySQL" EPG taldeak sor ditzakegu eta haien arteko elkarrekintza 3306 atakan soilik ahalbidetzen duen arau bat definitu. Horrek funtzionatuko du sareko helbideetara lotu gabe eta baita azpisare berean ere!
Hain zuzen ere, ezaugarri honengatik ACI aukeratu duten bezeroak ditugu, zerbitzarien arteko sarbidea mugatzeko aukera ematen baitu (birtualak edo fisikoak, berdin dio) azpisareen artean arrastatu gabe, eta, beraz, helbideratzeari eragin gabe. Bai, bai, badakigu, inork ez ditu eskuz IP helbideak idazten aplikazioen konfigurazioetan, ezta?
ACIn trafiko-fluxuaren arauak kontratuak deitzen dira. Halako kontratu batean, maila anitzeko aplikazio bateko talde edo geruza bat edo gehiago zerbitzu baten hornitzaile bihurtzen dira (esan, datu-baseen zerbitzu bat), eta besteak kontsumitzaile. Kontratuak trafikoa igarotzen utzi dezake, edo zerbait zailagoa egin dezake, adibidez, suebaki edo karga-orekatzaile batera zuzendu edo QoS balioa aldatu.
Nola sartzen dira zerbitzariak talde horietan? Hauek zerbitzari fisikoak edo lehendik dagoen sare batean sartuta dauden zerbait bada, eta bertan VLAN enbor bat sortu dugun, orduan EPGan jartzeko, switch ataka eta bertan erabiltzen den VLANa apuntatu beharko ditugu. Ikus dezakezunez, VLANak haiek gabe ezin duzun lekuan agertzen dira.
Zerbitzariak makina birtualak badira, nahikoa da konektatutako birtualizazio-inguruneari erreferentzia egitea, eta orduan dena bere kabuz gertatuko da: ataka talde bat sortuko da (VMWare terminoetan) VM-ak konektatzeko, beharrezkoak diren VLAN edo VXLAN-ak. esleitu, beharrezko switch-portuetan erregistratu, etab.. Beraz, ACI sare fisiko baten inguruan eraikita dagoen arren, zerbitzari birtualen konexioak fisikoak baino askoz errazagoak dirudite. ACI-k dagoeneko VMWare eta MS Hyper-V-ekin konexio integratua du, baita OpenStack eta RedHat Virtualization-en laguntza ere. Noizbait, edukiontzi-plataformetarako integratutako euskarria agertu da: Kubernetes, OpenShift, Cloud Foundry, eta politikak aplikatzeari eta monitorizazioari buruzkoa da, hau da, sareko administratzaileak berehala ikus dezake zein ostalaritan zein pod exekutatzen ari diren. zein talde sartzen diren.
Portu talde jakin batean sartzeaz gain, zerbitzari birtualek propietate gehigarriak dituzte: izena, atributuak, etab., beste talde batera eramateko irizpide gisa erabil daitezkeenak, esate baterako, VM izena aldatzean edo etiketa gehigarri bat gehitzean. . Cisco-k mikro-segmentazio-talde deitzen dio horri, nahiz eta, oro har, azpisare berean EPG moduan segurtasun-segmentu asko sortzeko gaitasuna duen diseinua bera ere nahiko mikro-segmentazioa den. Tira, saltzaileak daki ondoen.
EPGak berez eraikuntza logiko hutsak dira, etengailu, zerbitzari eta abar zehatz batzuei lotuta ez daudenak, beraz, haiekin eta horietan oinarritutako eraikuntzak (aplikazioak eta maizterrak) sare arruntetan egiteko zailak diren gauzak egin ditzakezu, hala nola klonazioa. Ondorioz, demagun, oso erraza da ekoizpen-ingurunearen klon bat sortzea produkzio-ingurunearen berdin-berdina izango den proba-ingurune bat lortzeko. Eskuz egin dezakezu, baina hobe (eta errazagoa) APIaren bidez.
Orokorrean, ACIn kontrol logika ez da batere antzekoa aurkitu ohi duzunaren antzekoa
Cisco bereko sare tradizionaletan: software interfazea nagusia da, eta GUI edo CLI bigarren mailakoa, API beraren bidez lan egiten baitute. Hori dela eta, ACIrekin lan egiten duten ia guztiak, denbora baten ondoren, kudeaketarako erabiltzen den objektu-ereduan nabigatzen hasten dira eta beren beharretara egokitzeko zerbait automatizatzen hasten da. Hori egiteko modurik errazena Python-ena da: horretarako prest dauden tresna erosoak daude.
Agindutako arrastoa
Arazo nagusia da gauza asko modu ezberdinean egiten direla ACIn. Normaltasunez lanean hasteko, berriro ikasi behar duzu. Hau bereziki egia da bezero handietako sareko eragiketa taldeentzat, non ingeniariek urteak daramatzate VLANak "idazten" eskaeren arabera. Izan ere, gaur egun VLAN bat jada ez da VLAN bat, eta sare berriak birtualizatutako ostalarietan instalatzeko VLANak eskuz sortu beharrik ez izateak, saregile tradizionalen gogoa erabat lehertzen du eta ohiko planteamenduetara atxikitzera behartzen ditu. Kontuan izan behar da Cisco pilula apur bat gozotzen saiatu zela eta kontroladoreari "NXOS-like" CLI bat gehitu zion, ohiko etengailuen antzeko interfaze batetik konfiguratzeko aukera ematen duena. Hala ere, ACI normalean erabiltzen hasteko, nola funtzionatzen duen ulertu beharko duzu.
Eskala handi eta ertaineko prezioari dagokionez, ACI sareak ez dira ia Cisco ekipoetako sare tradizionaletatik desberdinak, haiek eraikitzeko etengailu berdinak erabiltzen baitira (Nexus 9000 ACI eta modu tradizionalean funtziona dezake eta "langile" nagusi bihurtu da. β datu-zentroko proiektu berrietarako). Baina bi etengailuz osatutako datu-zentroetarako, kontrolagailuen presentzia eta Spine-Leaf arkitektura, noski, sentitzen dira. Duela gutxi, Mini ACI fabrika bat agertu zen, eta bertan hiru kontrolagailuetatik bi makina birtualek ordezkatu zituzten. Horrek kostuaren aldea murrizten du, baina oraindik ere geratzen da. Beraz, bezeroarentzat, segurtasun-funtzioetan, birtualizazioarekin integratzean, kontrol-puntu bakarrean eta abarrekiko interesa duen arabera erabakitzen da aukera.
Iturria: www.habr.com