S pomocí tohoto kouzelného kousku skriptu Cisco ACI můžete rychle nastavit síť.
Síťová továrna pro datové centrum Cisco ACI existuje pět let, ale Habré o tom vlastně nic neřekl, tak jsem se rozhodl to trochu napravit. Z vlastní zkušenosti vám řeknu, co to je, k čemu to je a kde to má hrábě.
Co to je a kde se to vzalo?
V době, kdy byla v roce 2013 oznámena ACI (Application Centric Infrastructure), konkurenti postupovali v tradičních přístupech k sítím datových center ze tří stran najednou.
Na jedné straně řešení SDN „první generace“ založená na OpenFlow slibovala, že sítě budou flexibilnější a zároveň levnější. Záměrem bylo přesunout rozhodování tradičně prováděné proprietárním přepínacím softwarem na centrální řídicí jednotku.
Tento kontrolér by měl jednotnou vizi všeho, co se děje a na základě toho by programoval hardware všech přepínačů na úrovni pravidel pro zpracování konkrétních toků.
Na druhou stranu, překryvná síťová řešení umožnila implementovat nezbytnou konektivitu a bezpečnostní politiku bez jakýchkoli změn ve fyzické síti a budovat softwarové tunely mezi virtualizovanými hostiteli. Nejznámějším příkladem tohoto přístupu byla Nicira, kterou v té době již koupila společnost VMWare za 1,26 miliardy dolarů a dala vzniknout současnému VMWare NSX. Jistou pikantnost situaci dodal fakt, že spoluzakladateli Nicira byli titíž lidé, kteří dříve stáli u zrodu OpenFlow, nyní říkají, že za účelem vybudování továrny na datová centra .
A konečně, spínací čipy dostupné na volném trhu (tzv. obchodní křemík) dosáhly stádia zralosti, kdy se staly skutečnou hrozbou pro tradiční výrobce přepínačů. Jestliže dříve každý dodavatel samostatně vyvíjel čipy pro své přepínače, pak postupem času čipy od výrobců třetích stran, především od Broadcomu, začaly zmenšovat vzdálenost od dodavatelských čipů, pokud jde o funkce, a předčily je v poměru cena / výkon. Mnozí proto věřili, že dny přepínačů na čipech vlastní konstrukce jsou sečteny.
ACI se stalo „asymetrickou reakcí“ společnosti Cisco (přesněji její společnosti Insieme, založené jejími bývalými zaměstnanci) na vše výše uvedené.
Jaký je rozdíl s OpenFlow?
Z hlediska distribuce funkcí je ACI vlastně opakem OpenFlow.
V architektuře OpenFlow je kontrolér zodpovědný za psaní podrobných pravidel (toků)
v hardwaru všech přepínačů, tedy ve velké síti, může být zodpovědný za údržbu a hlavně změnu desítek milionů záznamů na stovkách bodů v síti, takže se jeho výkon a spolehlivost stávají úzkým hrdlem v síti. velká implementace.
ACI používá obrácený přístup: samozřejmě existuje i řadič, ale přepínače od něj dostávají deklarativní politiky na vysoké úrovni a přepínač sám provádí jejich vykreslování do detailů konkrétních nastavení v hardwaru. Ovladač lze restartovat nebo úplně vypnout a se sítí se nestane nic špatného, samozřejmě kromě nedostatku kontroly v tuto chvíli. Zajímavé je, že v ACI existují situace, ve kterých se OpenFlow stále používá, ale lokálně v rámci hostitele pro programování Open vSwitch.
ACI je postaveno výhradně na překryvném přenosu založeném na VXLAN, ale zahrnuje základní přenos IP jako součást jediného řešení. Cisco to nazvalo termínem „integrované překrytí“. Jako koncový bod pro překryvy v ACI se ve většině případů používají tovární přepínače (dělají to rychlostí linky). Hostitelé nemusí vědět nic o továrně, zapouzdření atd., nicméně v některých případech (například pro připojení hostitelů OpenStack) na ně může být přenesen provoz VXLAN.
Překryvy se v ACI používají nejen k zajištění flexibilní konektivity prostřednictvím transportní sítě, ale také k přenosu metainformací (využívá se např. k aplikaci bezpečnostních politik).
Čipy od Broadcomu byly dříve používány společností Cisco v přepínačích řady Nexus 3000. V rodině Nexus 9000, speciálně vydané pro podporu ACI, byl původně implementován hybridní model, který se jmenoval Merchant +. Přepínač současně využíval jak nový čip Broadcom Trident 2, tak doplňkový čip vyvinutý společností Cisco, který implementuje veškeré kouzlo ACI. Zřejmě to umožnilo urychlit vydání produktu a snížit cenovku switche na úroveň blízkou modelům jednoduše založeným na Trident 2. Tento přístup stačil na první dva tři roky dodávek ACI. Během této doby společnost Cisco vyvinula a uvedla na trh další generaci Nexus 9000 na vlastních čipech s vyšším výkonem a sadou funkcí, ale za stejnou cenu. Externí specifikace z hlediska interakce v továrně jsou zcela zachovány. Zároveň se úplně změnila vnitřní výplň: něco jako refaktoring, ale na železo.
Jak funguje architektura Cisco ACI
V nejjednodušším případě je ACI postaveno na topologii sítě Klose, nebo, jak se často říká, Spine-Leaf. Páteřní spínače mohou být od dvou (nebo jednoho, pokud nám nezáleží na odolnosti proti poruchám) po šest. V souladu s tím, čím více jich je, tím vyšší je odolnost proti poruchám (tím nižší je šířka pásma a snížení spolehlivosti v případě nehody nebo údržby jednoho Spine) a celkový výkon. Všechna externí připojení jdou do přepínačů na úrovni listu: jedná se o servery a dokování s externími sítěmi prostřednictvím L2 nebo L3 a připojení řadičů APIC. Obecně platí, že u ACI nejen konfigurace, ale také sběr statistik, sledování poruch a tak dále – vše probíhá přes rozhraní kontrolérů, které jsou ve standardních implementacích tři.
Nikdy se nemusíte připojovat k přepínačům pomocí konzole, a to ani pro spuštění sítě: ovladač sám detekuje přepínače a sestaví z nich továrnu, včetně nastavení všech servisních protokolů, proto je mimochodem velmi důležité zapište si sériová čísla instalovaného zařízení během instalace, abyste později nemuseli hádat, který přepínač je ve kterém racku umístěn. Pro odstraňování problémů se v případě potřeby můžete připojit k přepínačům přes SSH: reprodukují obvyklé příkazy Cisco show poměrně pečlivě.
Interně továrna používá IP transport, takže v ní není Spanning Tree a další hrůzy minulosti: jsou zapojeny všechny odkazy a konvergence v případě selhání je velmi rychlá. Provoz ve struktuře je přenášen tunely založenými na VXLAN. Přesněji, Cisco samo nazývá iVXLAN encapsulation a od běžného VXLAN se liší tím, že vyhrazená pole v hlavičce sítě slouží k přenosu informací o službách, především o vztahu provozu ke skupině EPG. To vám umožňuje implementovat pravidla interakce mezi skupinami v zařízení pomocí jejich čísel stejným způsobem, jako se adresy používají v běžných přístupových seznamech.
Tunely umožňují protažení jak segmentů L2, tak segmentů L3 (tj. VRF) prostřednictvím interního přenosu IP. V tomto případě je distribuována výchozí brána. To znamená, že každý přepínač je zodpovědný za směrování provozu vstupujícího do struktury. Pokud jde o logiku toku provozu, ACI je podobná tkanině VXLAN/EVPN.
Pokud ano, jaké jsou rozdíly? Všechno ostatní!
Rozdíl číslo jedna, na který narazíte u ACI, je způsob připojení serverů k síti. V tradičních sítích jde zahrnutí fyzických serverů i virtuálních strojů do VLAN a od nich tančí vše ostatní: konektivita, bezpečnost atd. V ACI se používá design, který Cisco nazývá EPG (End-point Group), ze kterého není kam uniknout. Je možné to přirovnat k VLAN? Ano, ale v tomto případě existuje šance ztratit většinu toho, co ACI dává.
S ohledem na EPG jsou všechna přístupová pravidla formulována a v ACI je standardně používán princip „bílé listiny“, to znamená, že je povolen pouze provoz, jehož průchod je výslovně povolen. To znamená, že můžeme vytvořit skupiny EPG "Web" a "MySQL" a definovat pravidlo, které mezi nimi povolí komunikaci pouze na portu 3306. To bude fungovat bez vazby na síťové adresy a dokonce i v rámci stejné podsítě!
Máme zákazníky, kteří si vybrali ACI právě kvůli této funkci, protože vám umožňuje omezit přístup mezi servery (virtuálními nebo fyzickými - na tom nezáleží), aniž byste je přetahovali mezi podsítě, což znamená, že se nedotýkáte adresování. Ano, ano, víme, že IP adresy v konfiguracích aplikací nikdo nepředepisuje ručně, že?
Pravidla provozu v ACI se nazývají smlouvy. V takové smlouvě se jedna nebo více skupin nebo úrovní ve vícevrstvé aplikaci stane poskytovatelem služby (řekněme databázová služba), ostatní se stanou spotřebitelem. Smlouva může jednoduše předat provoz, nebo může udělat něco složitějšího, například jej nasměrovat na firewall nebo balancer a také změnit hodnotu QoS.
Jak se servery dostanou do těchto skupin? Pokud se jedná o fyzické servery nebo něco, co je součástí existující sítě, do které jsme vytvořili VLAN trunk, pak pro jejich umístění do EPG budete muset ukázat na port přepínače a na něm použitou VLAN. Jak vidíte, VLAN se objevují tam, kde se bez nich neobejdete.
Pokud jsou servery virtuálními stroji, pak se stačí odkázat na připojené virtualizační prostředí a pak se vše stane samo: vytvoří se skupina portů (ve smyslu VMWare) pro připojení VM, potřebné VLANy nebo VXLANy být přiřazeny, budou registrovány na potřebných portech přepínače atd. Přestože je ACI postaveno na fyzické síti, připojení pro virtuální servery vypadá mnohem jednodušeji než pro fyzické. ACI již má vestavěnou konektivitu s VMWare a MS Hyper-V, stejně jako podporu pro OpenStack a RedHat Virtualization. Od určité chvíle se objevila i vestavěná podpora pro kontejnerové platformy: Kubernetes, OpenShift, Cloud Foundry, přičemž se to týká jak aplikace politik, tak monitorování, to znamená, že správce sítě hned vidí, na kterých hostitelích které pody fungují a do kterých skupin spadají.
Kromě toho, že jsou virtuální servery zahrnuty do určité skupiny portů, mají další vlastnosti: název, atributy atd., které lze použít jako kritéria pro jejich přenos do jiné skupiny, řekněme, když je virtuální počítač přejmenován nebo se v něm objeví další značka. to. Cisco to nazývá mikrosegmentačními skupinami, ačkoliv samotný návrh se schopností vytvořit mnoho bezpečnostních segmentů ve formě EPG na stejné podsíti je také docela mikrosegmentace. No, prodejce ví lépe.
Samotné EPG jsou čistě logické konstrukce, které nejsou vázány na konkrétní přepínače, servery atd., takže s nimi a konstrukcemi na nich založenými (aplikace a tenanti) můžete dělat věci, které se v běžných sítích těžko provádějí, jako je například klonování. Ve výsledku řekněme, že je velmi snadné naklonovat produkční prostředí, abyste získali testovací prostředí, které bude zaručeně identické s produkčním prostředím. Můžete to udělat ručně, ale je to lepší (a jednodušší) přes API.
Obecně platí, že logika ovládání v ACI není vůbec podobná té, s jakou se běžně setkáváte
v tradičních sítích od stejného Cisco: softwarové rozhraní je primární a GUI nebo CLI jsou sekundární, protože pracují přes stejné API. Proto téměř každý, kdo se podílí na ACI, se po chvíli začne orientovat v objektovém modelu používaném pro správu a automatizovat něco, co vyhovuje jeho potřebám. Nejjednodušší způsob, jak to udělat, je z Pythonu: existují pro to pohodlné hotové nástroje.
Slíbené hrábě
Hlavním problémem je, že mnoho věcí v ACI se dělá jinak. Abyste s tím začali normálně pracovat, musíte se přeškolit. To platí zejména pro týmy síťového provozu u velkých zákazníků, kde inženýři léta „předepisují VLAN“ na vyžádání. Skutečnost, že nyní VLAN již nejsou VLAN a nemusíte vytvářet VLAN ručně, abyste mohli pokládat nové sítě na virtualizované hostitele, zcela odbourává střechu tradičních síťařů a nutí je lpět na známých přístupech. Je třeba poznamenat, že Cisco se pokusilo pilulku trochu osladit a přidalo do ovladače „NXOS-like“ CLI, které umožňuje provádět konfiguraci z rozhraní podobného tradičním přepínačům. Ale přesto, abyste mohli začít normálně používat ACI, musíte pochopit, jak to funguje.
Pokud jde o cenu, ve velkých a středních měřítcích se sítě ACI ve skutečnosti neliší od tradičních sítí na zařízení Cisco, protože k jejich budování se používají stejné přepínače (Nexus 9000 může pracovat v ACI a v tradičním režimu a staly se nyní hlavní „tahouna“ pro nové projekty datových center). Ale u datových center se dvěma přepínači je přítomnost řadičů a architektury Spine-Leaf samozřejmě znát. Nedávno se objevila továrna Mini ACI, ve které jsou dva ze tří řadičů nahrazeny virtuálními stroji. To snižuje rozdíl v ceně, ale stále zůstává. Takže pro zákazníka je výběr diktován tím, jak moc ho zajímají bezpečnostní prvky, integrace s virtualizací, jeden kontrolní bod a tak dále.
Zdroj: www.habr.com