Pomocou tohto magického kúsku skriptu Cisco ACI môžete rýchlo nastaviť sieť.
Sieťová štruktúra pre dátové centrum Cisco ACI existuje už päť rokov, ale na Habré sa o nej vlastne nič nehovorí, tak som sa rozhodol ju trochu napraviť. Poviem vám z vlastnej skúsenosti, čo to je, aké sú jeho výhody a kde sú jeho hrable.
Čo to je a odkiaľ to prišlo?
V čase, keď bola v roku 2013 ohlásená ACI (Application Centric Infrastructure), na tradičné prístupy k sieťam dátových centier útočili konkurenti z troch strán naraz.
Na jednej strane riešenia SDN „prvej generácie“ založené na OpenFlow sľubovali, že siete budú flexibilnejšie a zároveň lacnejšie. Myšlienkou bolo preniesť rozhodovanie, tradične ovládané proprietárnym softvérom prepínačov, na centrálny kontrolér.
Tento kontrolér by mal jednotnú víziu o všetkom, čo sa deje a na základe toho by naprogramoval vybavenie všetkých prepínačov na úrovni pravidiel pre spracovanie konkrétnych tokov.
Na druhej strane, prekryvné sieťové riešenia umožnili implementovať požadovanú konektivitu a bezpečnostnú politiku bez akýchkoľvek zmien vo fyzickej sieti, čím sa vytvorili softvérové tunely medzi virtualizovanými hostiteľmi. Najznámejším príkladom tohto prístupu bolo riešenie od Nicira, ktoré už v tom čase získal VMWare za 1,26 miliardy dolárov a dal vznik súčasnému VMWare NSX. Čo dodalo situácii na pikantnosti, že spoluzakladatelia Nicira boli tí istí ľudia, ktorí predtým stáli pri počiatkoch OpenFlow, ktorí teraz povedali, že postaviť továreň na dátové centrá .
A nakoniec, spínacie čipy dostupné na otvorenom trhu (nazývaný obchodný kremík) dosiahli úroveň zrelosti, kedy sa stali skutočnou hrozbou pre tradičných výrobcov prepínačov. Ak predtým každý predajca sám vyvíjal čipy pre svoje prepínače, časom sa čipy od výrobcov tretích strán, predovšetkým od Broadcomu, začali funkčne približovať k čipom dodávateľov a prekonávali ich v pomere cena/výkon. Preto mnohí verili, že dni prepínačov na proprietárnych čipoch sú spočítané.
ACI sa stalo „asymetrickou odpoveďou“ spoločnosti Cisco (presnejšie spoločnosti Insieme, ktorá bola jej súčasťou, založenej jej bývalými zamestnancami) na všetko spomenuté.
Aký je rozdiel s OpenFlow?
Z hľadiska rozloženia funkcií je ACI vlastne opakom OpenFlow.
V architektúre OpenFlow je kontrolér zodpovedný za písanie podrobných pravidiel (tokov)
v hardvéri všetkých prepínačov, teda vo veľkej sieti, môže byť zodpovedný za údržbu a hlavne zmenu desiatok miliónov záznamov na stovkách bodov v sieti, takže sa jeho výkon a spoľahlivosť pri veľkom nasadení stáva úzke miesto.
ACI používa opačný prístup: samozrejme, existuje kontrolér, ale prepínače od neho dostávajú deklaratívne politiky na vysokej úrovni a samotný prepínač ich vykresľuje do detailov konkrétnych nastavení v hardvéri. Ovládač je možné reštartovať alebo úplne vypnúť a so sieťou sa nestane nič zlé, samozrejme, okrem nedostatku kontroly v tejto chvíli. Je zaujímavé, že v ACI existujú situácie, v ktorých sa OpenFlow stále používa, ale lokálne v rámci hostiteľa na programovanie Open vSwitch.
ACI je postavené výlučne na prekryvnom prenose založenom na VXLAN, ale zahŕňa aj základný prenos IP ako súčasť jediného riešenia. Cisco to nazvalo výrazom „integrované prekrytie“. Vo väčšine prípadov sa látkové prepínače používajú ako koncový bod pre prekrytia v ACI (robia to rýchlosťou linky). Hostitelia nemusia vedieť nič o štruktúre, zapuzdrení atď., avšak v niektorých prípadoch (povedzme na pripojenie hostiteľov OpenStack) k nim môže byť privedená prevádzka VXLAN.
Prekrytia sa v ACI používajú nielen na poskytovanie flexibilnej konektivity cez transportnú sieť, ale aj na sprostredkovanie metainformácií (používajú sa napríklad na presadzovanie bezpečnostných politík).
Čipy od Broadcom boli predtým používané spoločnosťou Cisco v prepínačoch série Nexus 3000. Rodina Nexus 9000, špeciálne vydaná na podporu ACI, pôvodne implementovala hybridný model s názvom Merchant+. Prepínač súčasne využíval nový čip Broadcom Trident 2 a doplnkový čip vyvinutý spoločnosťou Cisco, ktorý implementuje všetky kúzla ACI. Zrejme to umožnilo urýchliť vydanie produktu a znížiť cenovku switchu na úroveň blízku modelom jednoducho založeným na Trident 2. Tento prístup stačil na prvé dva až tri roky dodávok ACI. Počas tejto doby spoločnosť Cisco vyvinula a uviedla na trh ďalšiu generáciu Nexus 9000 na vlastných čipoch s vyšším výkonom a sadou funkcií, no na rovnakej cenovej úrovni. Externé špecifikácie z pohľadu interakcie v továrni sú úplne zachované. Zároveň sa úplne zmenila vnútorná výplň: niečo ako refaktoring, ale na hardvér.
Ako funguje architektúra Cisco ACI
V najjednoduchšom prípade je ACI zostavená podľa topológie siete Clos, alebo, ako sa často hovorí, Spine-Leaf. Prepínače na úrovni chrbtice môžu byť od dvoch (alebo jedného, ak sa nestaráme o odolnosť voči chybám) po šesť. V súlade s tým, čím viac ich je, tým vyššia je odolnosť voči poruchám (tým menšie zníženie šírky pásma a spoľahlivosti v prípade nehody alebo údržby jedného Spine) a celkový výkon. Všetky externé pripojenia smerujú k prepínačom na úrovni listov: zahŕňajú servery, pripojenie k externým sieťam cez L2 alebo L3 a pripojenie ovládačov APIC. Vo všeobecnosti sa pri ACI nielen konfigurácia, ale aj zhromažďovanie štatistík, monitorovanie porúch atď. - všetko robí cez rozhranie kontrolérov, z ktorých sú tri v implementáciách bežnej veľkosti.
K prepínačom sa už nikdy nemusíte pripájať pomocou konzoly, a to ani na spustenie siete: ovládač sám detekuje prepínače a zostaví z nich továreň vrátane nastavení pre všetky servisné protokoly. Preto je mimochodom veľmi dôležité zapisovať pri inštalácii si zapíšte sériové čísla inštalovaného zariadenia, aby ste neskôr nemuseli hádať, ktorý prepínač je v akom stojane umiestnený? Ak je to potrebné, na riešenie problémov sa môžete pripojiť k prepínačom cez SSH: zvyčajné príkazy Cisco show sú na nich reprodukované pomerne starostlivo.
Vnútri továreň využíva IP transport, takže v nej nie je Spanning Tree ani iné hrôzy minulosti: všetky prepojenia sú použité a konvergencia v prípade porúch je veľmi rýchla. Prevádzka v látke sa uskutočňuje cez tunely založené na VXLAN. Presnejšie, samotné Cisco nazýva zapuzdrenie iVXLAN a od bežného VXLAN sa líši tým, že vyhradené polia v hlavičke siete slúžia na prenos informácií o službách, predovšetkým o vzťahu prevádzky k skupine EPG. To vám umožňuje implementovať pravidlá interakcie medzi skupinami v zariadení pomocou ich čísel rovnakým spôsobom, ako sa adresy používajú v bežných zoznamoch prístupových práv.
Tunely vám umožňujú natiahnuť segmenty L2 aj L3 (to znamená VRF) prostredníctvom interného prenosu IP. V tomto prípade je distribuovaná predvolená brána. To znamená, že každý prepínač je zodpovedný za smerovanie prevádzky vstupujúcej do štruktúry. Pokiaľ ide o logiku prenosu prevádzky, ACI je podobná tkanine založenej na VXLAN/EVPN.
Ak áno, aké sú rozdiely? Všetko ostatné!
Rozdiel číslo jedna, s ktorým sa stretávate v ACI, je spôsob, akým sú servery pripojené k sieti. V tradičných sieťach ide zahrnutie fyzických serverov aj virtuálnych strojov do VLAN a všetko ostatné od nich tancuje: konektivita, bezpečnosť atď. ACI používa dizajn, ktorý Cisco nazýva EPG (End-point Group), z ktorého neexistuje uniknúť. Dá sa to prirovnať k VLAN? Áno, ale v tomto prípade existuje šanca stratiť väčšinu toho, čo ACI dáva.
Všetky pravidlá prístupu sú formulované vo vzťahu k EPG av ACI sa štandardne používa princíp „bielej listiny“, to znamená, že je povolená iba premávka, ktorej prechod je výslovne povolený. To znamená, že môžeme vytvoriť EPG skupiny „Web“ a „MySQL“ a definovať pravidlo, ktoré umožňuje interakciu medzi nimi iba na porte 3306. Toto bude fungovať bez toho, aby sme boli viazaní na sieťové adresy a dokonca v rámci rovnakej podsiete!
Máme zákazníkov, ktorí si vybrali ACI práve kvôli tejto funkcii, pretože vám umožňuje obmedziť prístup medzi servermi (virtuálnymi alebo fyzickými, na tom nezáleží) bez ich presúvania medzi podsiete, a teda bez ovplyvnenia adresovania. Áno, áno, vieme, nikto ručne nezapisuje IP adresy do konfigurácií aplikácií, však?
Pravidlá pre tok dopravy v ACI sa nazývajú zmluvy. V takejto zmluve sa jedna alebo viacero skupín alebo vrstiev vo viacvrstvovej aplikácii stáva poskytovateľom služby (povedzme databázovej služby) a ostatné sa stávajú spotrebiteľmi. Zmluva môže jednoducho povoliť priechod prenosu alebo môže urobiť niečo zložitejšie, napríklad nasmerovať ho na bránu firewall alebo na vyrovnávanie zaťaženia alebo zmeniť hodnotu QoS.
Ako sa servery dostanú do týchto skupín? Ak ide o fyzické servery alebo niečo, čo je súčasťou existujúcej siete, do ktorej sme vytvorili VLAN trunk, potom na ich umiestnenie do EPG budeme musieť ukázať na port prepínača a na ňom použitú VLAN. Ako vidíte, siete VLAN sa objavujú tam, kde sa bez nich nezaobídete.
Ak sú servery virtuálne stroje, potom sa stačí odkázať na pripojené virtualizačné prostredie a potom sa všetko stane samo: vytvorí sa skupina portov (v podmienkach VMWare) na pripojenie VM, potrebné siete VLAN alebo VXLAN sa byť pridelené, zaregistrované na potrebných portoch prepínača atď. atď. Takže aj keď je ACI postavená na fyzickej sieti, pripojenia pre virtuálne servery vyzerajú oveľa jednoduchšie ako pre fyzické. ACI má už zabudovanú konektivitu s VMWare a MS Hyper-V, ako aj podporu pre OpenStack a RedHat Virtualization. V určitom okamihu sa objavila vstavaná podpora pre kontajnerové platformy: Kubernetes, OpenShift, Cloud Foundry a týka sa to aplikácie politík aj monitorovania, to znamená, že správca siete okamžite vidí, na ktorých hostiteľoch sú spustené a v do ktorých skupín patria.
Okrem toho, že sú virtuálne servery zahrnuté do konkrétnej skupiny portov, majú ďalšie vlastnosti: názov, atribúty atď., ktoré možno použiť ako kritériá na ich presun do inej skupiny, povedzme pri premenovaní virtuálneho počítača alebo pri pridávaní ďalšej značky. . Cisco to nazýva mikro-segmentačné skupiny, hoci samotný dizajn so schopnosťou vytvárať veľa bezpečnostných segmentov vo forme EPG v tej istej podsieti je tiež dosť mikro-segmentačný. No, predajca vie najlepšie.
Samotné EPG sú čisto logické konštrukcie, ktoré nie sú viazané na konkrétne prepínače, servery atď., takže s nimi a konštruktmi na nich založenými (aplikáciami a nájomníkmi) môžete robiť veci, ktoré je ťažké robiť v bežných sieťach, ako je napríklad klonovanie. V dôsledku toho je povedzme veľmi jednoduché vytvoriť klon produkčného prostredia s cieľom získať testovacie prostredie, ktoré je zaručene totožné s produkčným. Môžete to urobiť manuálne, ale je to lepšie (a jednoduchšie) prostredníctvom rozhrania API.
Vo všeobecnosti sa logika ovládania v ACI vôbec nepodobá na to, s čím sa bežne stretávate
v tradičných sieťach od rovnakého Cisco: softvérové rozhranie je primárne a GUI alebo CLI sú sekundárne, pretože pracujú cez rovnaké API. Preto takmer každý, kto pracuje s ACI, sa po chvíli začne orientovať v objektovom modeli používanom na správu a automatizovať niečo, čo vyhovuje jeho potrebám. Najjednoduchší spôsob, ako to urobiť, je z Pythonu: existujú na to pohodlné hotové nástroje.
Sľúbené hrable
Hlavným problémom je, že veľa vecí sa v ACI robí inak. Aby ste s ním začali normálne pracovať, musíte sa to znova naučiť. To platí najmä pre sieťové prevádzkové tímy u veľkých zákazníkov, kde inžinieri už roky „píšu VLAN“ podľa požiadaviek. Skutočnosť, že teraz VLAN už nie je VLAN a na inštaláciu nových sietí vo virtualizovaných hostiteľoch nie je potrebné vytvárať VLAN ručne, úplne ohromí hlavu tradičných networkerov a núti ich držať sa zaužívaných prístupov. Treba poznamenať, že Cisco sa pokúsilo tabletku trochu osladiť a do ovládača pridalo „NXOS-like“ CLI, ktoré umožňuje konfiguráciu z rozhrania podobného tradičným prepínačom. Aby ste však mohli začať normálne používať ACI, budete musieť pochopiť, ako to funguje.
Pokiaľ ide o cenu vo veľkých a stredných rozsahoch, siete ACI sa prakticky nelíšia od tradičných sietí na zariadeniach Cisco, pretože na ich zostavenie sa používajú rovnaké prepínače (Nexus 9000 môže pracovať v režime ACI aj v tradičnom režime a stal sa hlavným „ťažným koňom“). pre nové projekty dátových centier). Ale pre dátové centrá pozostávajúce z dvoch prepínačov je prítomnosť ovládačov a architektúry Spine-Leaf samozrejme cítiť. Nedávno sa objavila továreň Mini ACI, v ktorej boli dva z troch ovládačov nahradené virtuálnymi strojmi. To znižuje rozdiel v nákladoch, ale stále zostáva. Takže pre zákazníka je výber diktovaný tým, aký má záujem o bezpečnostné prvky, integráciu s virtualizáciou, jeden bod kontroly atď.
Zdroj: hab.com