S tímto kouzelným kouskem skriptu Cisco ACI můžete rychle nastavit síť.
Síťová fabrika pro datová centra Cisco ACI existuje již pět let, ale na Habr o ní nebylo moc napsáno, a tak jsem se rozhodl to trochu napravit. Podělím se o svou zkušenost, co to vlastně je, jaký má přínos a kde jsou její úskalí.
Co to je a odkud se vzalo?
V době oznámení ACI (Application Centric Infrastructure) v roce 2013 čelily tradiční přístupy k sítím datových center konkurenci ze tří stran.
Na jedné straně slibovala "první generace" SDN řešení založená na OpenFlow, že učiní sítě flexibilnějšími a levnějšími zároveň. Myšlenka spočívala v tom, že by se rozhodování, tradičně prováděné proprietárním softwarem přepínačů, přesunulo na centrální kontrolér.
Tento kontrolér by měl jednotné vidění všeho, co se děje, a na základě toho by programoval hardware všech přepínačů na úrovni pravidel zpracování konkrétních toků.
Na druhé straně poskytovala overleayová síťová řešení možnost realizovat potřebnou konektivitu a bezpečnostní politiky bez jakýchkoli změn v fyzické síti, vytvářením softwarových tunelů mezi virtualizovanými hostiteli. Nejznámějším příkladem takového přístupu bylo řešení od společnosti Nicira, která byla v té době již koupena společností VMWare za 1,26 miliardy dolarů a stala se základem současného VMWare NSX. K této situaci určitým způsobem přispělo to, že spoluzakladatelé firmy Nicira byli stejní lidé, kteří dříve stáli u zrodu OpenFlow, a nyní tvrdili, že pro vybudování datové továrny. .
No, a konečně, přepínací čipy, dostupné na otevřeném trhu (což se nazývá merchant silicon), dosáhly úrovně zralosti, při které se staly reálnou hrozbou pro tradiční výrobce přepínačů. Zatímco dříve si každý výrobce vyvíjel čipy pro své přepínače sám, časem se čipy od třetích stran, zejména od Brоadcom, začaly přibližovat výrobním čipům z pohledu funkcí a co se týče poměru cena/výkon, je překonávaly. Proto mnozí považovali dny přepínačů s čipy vlastní výroby za sečtené.
ACI se stala "asymetrickou reakcí" společnosti Cisco (přesněji řečeno, společnosti Insieme, která byla založena jejími bývalými zaměstnanci) na vše výše uvedené.
Jaký je rozdíl s OpenFlow?
Z pohledu rozdělení funkcí je ACI vlastně opakem OpenFlow.
V architektuře OpenFlow kontrolér odpovídá za zapisování podrobných pravidel (toků)
do hardwaru všech přepínačů, což znamená, že v rozsáhlé síti může nést odpovědnost za uchovávání a, co je nejdůležitější, změnu desítek milionů záznamů na stovkách míst v síti, proto se její výkon a spolehlivost ve velkém nasazení stává úzkým místem.
V ACI se používá opačný přístup: kontrolér existuje, samozřejmě, ale přepínače dostávají od něj vysoce úrovňové deklarativní politiky a jejich převod na podrobnosti konkrétních nastavení v hardwaru provádí samotný přepínač. Kontrolér může být restartován nebo dokonce vypnut a se sítí se nic špatného nestane, kromě samozřejmě absence možnosti správy v této chvíli. Zajímavé je, že v ACI existují situace, kdy se OpenFlow přece jen používá, ale lokálně v rámci hostitele pro programování Open vSwitch.
ACI je zcela postavena na overlay transportu založeném na VXLAN, ale zároveň zahrnuje v rámci jednoho řešení i spodní IP transport. Cisco to nazvalo termínem „integrovaný overlay“. Jako bod terminace overlay v ACI se v většině případů používají přepínače fabriky (provádějí to rychlostí kanálu). Hosté nemusí nic vědět o fabrice, enkapsulaci atd., nicméně v některých případech (například pro připojení OpenStack hostů) může být VXLAN provoz dodáván i k nim.
Overlay se v ACI používají nejen pro zajištění flexibilní konektivity přes transportní síť, ale také pro přenos meta-informací (ta se používá například pro uplatnění bezpečnostních politik).
Čipy od Broadcom byly dříve použity v přepínačích Cisco řady Nexus 3000. V rodině Nexus 9000, která byla speciálně vydaná pro podporu ACI, byla nejprve implementována hybridní model nazvaný Merchant+. V přepínači byly současně použity nový čip Broadcom Trident 2 a doplňkový čip vyvinutý společností Cisco, který realizoval veškerou magii ACI. Zřejmě to umožnilo urychlit uvedení produktu na trh a snížit cenu přepínače na úroveň blízkou modelům pouze na Trident 2. Tento přístup stačil na první dva až tři roky dodávek ACI. Během této doby Cisco vyvinula a uvedla na trh další generaci Nexus 9000 již na svých vlastních čipech, které měly vyšší výkon a funkčnost, ale za stejné ceny. Vnější specifikace z hlediska interakce ve fabrice zůstaly zcela zachovány. Interní výbava se však zcela změnila: něco jako refaktoring, ale pro hardware.
Jak je uspořádána architektura Cisco ACI
V nejjednodušším případě ACI staví podle topologie Clos, nebo jak se často říká, Spine-Leaf. Přepínačů na úrovni Spine může být od dvou (nebo jednoho, pokud nás nezajímá odolnost proti selhání) do šesti. Čím více jich je, tím vyšší je odolnost (menší snížení šířky pásma a spolehlivosti při havárii nebo údržbě jednoho Spine) a celkový výkon. Všechny vnější připojení jdou do přepínačů na úrovni Leaf: to jsou servery, připojení k externím sítím přes L2 nebo L3 a připojení kontrolerů APIC. Celkově s ACI nejen konfigurace, ale také shromažďování statistiky, monitorování selhání a další — vše se provádí prostřednictvím rozhraní kontrolerů, kterých je v zavedeních běžné velikosti — tři kusy.
K přepínačům se nikdy nemusí připojovat konzole, ani při spuštění sítě: kontroler sám objevuje přepínače a sestavuje z nich fabriku, včetně nastavení všech služebních protokolů, proto je mimochodem velmi důležité při montáži zapsat sériová čísla instalované techniky, aby se pak nemuselo hádat, který přepínač je v které skříni. Pro řešení problémů se k přepínačům v případě potřeby dá připojit přes SSH: na nich jsou dost pečlivě reprodukovány běžné show-příkazy Cisco.
Uvnitř fabriky se využívá IP transport, takže zde není žádný Spanning Tree a podobné hrůzy minulosti: všechny linky jsou využity a konvergence při výpadcích je velmi rychlá. Provoz ve fabrice je přenášen prostřednictvím tunelů založených na VXLAN. Přesněji řečeno, samotná Cisco nazývá enkapsulaci iVXLAN, a liší se od běžného VXLAN tím, že rezervovaná pole v síťové hlavičce se používají k přenosu řízení informací, především o vztahu provozu k EPG skupině. To umožňuje implementovat pravidla interakce mezi skupinami v hardwaru, používající jejich čísla stejně, jako se v běžných přístupových listech používají adresy.
Tunely umožňují rozšiřovat jak L2 segmenty, tak L3 (tedy VRF) prostřednictvím interního IP transportu. Přitom je výchozí brána distribuovaná. To znamená, že směrováním příchozího provozu do fabriky se zabývá každý switch. Z hlediska logiky přenosu provozu je ACI podobné továrně na bázi VXLAN/EVPN.
Pokud je tomu tak, jaké jsou rozdíly? Ve všem ostatním!
Rozdíl číslo jedna, se kterým se v ACI setkáváte, je to, jak se servery připojují do sítě. V tradičních sítích se připojení jak fyzických serverů, tak virtuálních stává v VLAN, a od nich se odvíjí vše ostatní: konektivita, zabezpečení atd. V ACI se však používá struktura, kterou Cisco nazývá EPG (End-point Group), od které se nelze odstoupit. Lze ji rovnat VLAN? Ano, ale v takovém případě hrozí ztráta většiny toho, co ACI poskytuje.
Ve vztahu k EPG se formulují všechna pravidla přístupu, a v ACI se standardně používá princip "bílého seznamu", což znamená, že povolen je pouze provoz, jehož propouštění je výslovně povoleno. To znamená, že můžeme vytvořit EPG skupiny "Web" a "MySQL" a definovat pravidlo, které povoluje interakci mezi nimi pouze na portu 3306. To bude fungovat bez vazby na síťové adresy a dokonce i v rámci jedné podsítě!
Máme zákazníky, kteří si vybrali ACI právě kvůli této funkce, protože umožňuje omezit přístupy mezi servery (virtuálními či fyzickými - nezáleží), aniž by bylo nutné je přesouvat mezi podsítěmi, což znamená, že se nemění adresace. Ano, víme, nikdo totiž ručně nezadává IP adres do konfigurací aplikací, že?
Pravidla pro přesměrování provozu v ACI se nazývají kontrakty. V takovém kontraktu se jedna nebo více skupin nebo vrstev v aplikaci s více úrovněmi stává poskytovatelem služby (dejme tomu, služba databáze), zatímco jiné jsou spotřebiteli. Kontrakt může pouze přesměrovat provoz, nebo může udělat něco sofistikovanějšího, například přesměrovat na firewall nebo vyvažovač, 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 zahrnuto do stávající sítě, do které jsme vytvořili VLAN trunk, pak pro jejich zařazení do EPG bude potřeba uvést port přepínače a používaný VLAN. Jak vidíme, VLANy se objevují tam, kde bez nich nelze.
Pokud jsou servery virtuální, stačí odkázat na připojené prostředí virtualizace, a pak se stane vše automaticky: vytvoří se portová skupina (pokud mluvíme v termínech VMWare) pro připojení VM, přidělí se potřebné VLANy nebo VXLANy, a zapíší se na potřebné porty přepínačů atd. Takže, i když je ACI postavena kolem fyzické sítě, připojení pro virtuální servery vypadají mnohem jednodušeji než pro fyzické. ACI již obsahuje integraci s VMWare a MS Hyper-V, stejně jako podporu pro OpenStack a RedHat Virtualization. Od určitého okamžiku se objevila i vestavěná podpora pro kontejnerové platformy: Kubernetes, OpenShift, Cloud Foundry, přičemž se tato podpora týká jak aplikace politik, tak monitorování, tedy síťový administrátor může okamžitě vidět, na jakých hostitelích jaké pody běží a do jakých skupin se dostali.
Kromě zařazení do určité portové skupiny mají virtuální servery další vlastnosti: jméno, atributy atd., které lze použít jako kritéria pro jejich přesun do jiné skupiny, například při přejmenování VM nebo při získání dalšího štítku. Cisco tomu říká mikrossegregační skupiny, i když, ve skutečnosti, samotná konstrukce s možností vytvářet více bezpečnostních segmentů ve formě EPG ve stejné podsíti je také docela mikrossegregace. No, vendorovi je to jasnější.
EPG jsou čistě logické konstrukce, které nejsou vázány na konkrétní switche, servery atd., takže s nimi a jejich odvozenými konstrukcemi (aplikacemi a tenanty) lze dělat věci, které jsou v běžných sítích obtížně proveditelné, například klonování. Díky tomu je velmi snadné vytvořit klon produkčního prostředí, aby se získalo testovací prostředí zaručeně identické s produkčním. To lze provést ručně, ale lepší (a jednodušší) je to udělat přes API.
Logika správy v ACI se obecně vůbec nepodobá tomu, co běžně potkáváte
v tradičních sítích od stejné firmy Cisco: programové rozhraní je primární, zatímco GUI nebo CLI jsou sekundární, protože fungují přes stejné API. Proto se téměř každý, kdo se zabývá ACI, po určité době začíná orientovat v objektovém modelu, který se používá pro správu, a něco si automatizovat podle svých potřeb. Nejjednodušší to udělat v Pythonu: pro něj existují pohodlné hotové nástroje.
Přislíbené nástrahy
Hlavní problém spočívá v tom, že mnoho věcí v ACI je realizováno jinak. Abyste s tím mohli správně pracovat, musíte se přeučit. To se týká zejména týmů pro síťový provoz u velkých zákazníků, kde se inženýři po léta věnují „šíření VLANů“ podle požadavků. To, že nyní VLAN dělá více než jen VLAN, a pro vytváření nových sítí ve virtualizovaných hostitelských strojích není nutné vytvářet VLANy ručně, úplně „rozsype hlavu“ tradičním síťařům a nutí je držet se zavedených přístupů. Je třeba poznamenat, že Cisco se snažila trochu usnadnit situaci a do kontroléru přidala „CLI podobné NXOS“, které umožňuje konfiguraci z rozhraní podobného tradičním switchům. Nicméně pro to, abyste mohli normálně používat ACI, budete muset pochopit, jak to funguje.
Z pohledu cen na velkých a středních sítích ACI se od tradičních sítí na zařízeních Cisco v podstatě neliší, neboť pro jejich stavbu se používají stejné switche (Nexus 9000 může fungovat jak v režimu ACI, tak v tradičním režimu a stalo se nyní hlavním "koněm" pro nové projekty v datových centrech). Pro datová centra se dvěma switchemi přítomnost kontrolerů a architektura Spine-Leaf samozřejmě dává o sobě vědět. Nedávno se objevila Mini ACI fabrika, kde byly dva kontrolery z tří nahrazeny virtuálními stroji. To umožňuje snížit rozdíl v nákladech, ale stále zůstává. Takže pro zákazníka je volba určena tím, jak moc je zainteresován na funkcích bezpečnosti, integrace s virtualizací, jediné správy a dalších.
Zdroj: habr.com
