Ohodnoťte spojení ve střední části schématu. K nim se vrátíme níže.
V určitém okamžiku se můžete setkat s tím, že velké složité sítě založené na L2 jsou nevratně postižené. Především problémy spojené se zpracováním BUM provozu a s fungováním protokolu STP. A pak také s celkově morálně zastaralou architekturou. To způsobuje nepříjemné problémy v podobě výpadků a nepohodlí při správě.
Měli jsme dva paralelní projekty, kde si klienti realisticky vyhodnotili všechny výhody a nevýhody a zvolili dvě různá overlay řešení, která jsme implementovali.
Měli jsme možnost porovnat právě realizaci. Ne provoz, o tom bychom měli mluvit za dva až tři roky.
Takže, co je to síťová fabrika s overlay sítěmi a SDN?
Co dělat s palčivými problémy klasické architektury sítě?
Každý rok se objevují nové technologie a myšlenky. V praxi se dlouho neobjevila naléhavá potřeba přestavět sítě, protože se stále dalo všechno dělat manuálně starými dobrými metodami. No a co, že je dvacáté první století? Koneckonců, administrátor by měl pracovat, a ne sedět v kanceláři.
Pak přišel boom stavby rozsáhlých datových center. Tehdy se ukázalo, že byl dosažen limit rozvoje klasické architektury nejen z hlediska funkčnosti, odolnosti a škálovatelnosti. A jedním z možných řešení těchto úkolů se stala myšlenka budování overlay sítí nad směrovatelným backbone.
Kromě toho, s rostoucími rozměry sítí, se akutně objevila problematika správy těchto továren, v důsledku čehož začala vznikat řešení softwarově definovaných sítí, které umožňují spravovat celou síťovou infrastrukturu jako celek. A když je síť spravována z jednoho bodu, ostatním komponentům IT infrastruktury se snadněji spolupracuje a takové procesy interakce se snadněji automatizují.
Téměř každý velký výrobce nejen síťového zařízení, ale také virtualizace, má ve svém portfoliu varianty takových řešení.
Zůstává jen pochopit, co se hodí pro jaké potřeby. Například pro velmi velké společnosti s dobrou vývojovou a provozní skupinou nemusí krabicová řešení od dodavatelů stačit všem potřebám, a proto přistupují k vývoji vlastních řešení definovaných softwarem (SD). Například to jsou cloudoví poskytovatelé, kteří neustále rozšiřují nabídku služeb poskytovaných svým klientům, a krabicová řešení zkrátka nestačí na jejich potřeby.
Pro střední společnosti v 99 procentech případů postačuje funkcionalita, kterou dodavatel nabízí ve formě krabicového řešení.
Co jsou to overlayové sítě
Jaká je myšlenka overlayových sítí? V podstatě vezmete klasickou směrovatelnou síť a nad ni postavíte další síť, abyste získali více funkcí. Nejčastěji jde o efektivní rozložení zátěže na zařízení a spojové linky, významné zvýšení limitu pro škálovatelnost, zlepšení spolehlivosti a celou řadu vylepšení v oblasti bezpečnosti (díky segmentaci). A SDN řešení navíc umožňují velmi, velmi, velmi pohodlné flexibilní administraci a činí síť jasnější pro uživatele.
Obecně, pokud by lokální sítě byly vynalezeny někdy v 2010. letech, vypadaly by velmi odlišně od toho, co jsme zdědili od vojenských sítí ze 70. let.
Z pohledu technologií pro budování továren s využitím overlayových sítí existuje v současné době mnoho realizací od výrobců a internetových projektů RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve a další). Ano, existují normy, ale implementace těchto norem různými výrobci se může lišit, takže při vytváření takových továren je teoreticky možné se zcela vzdát vendor lock pouze na papíře.
S SD řešeními je to ještě složitější, každý dodavatel má svůj vlastní pohled. Existují zcela otevřená řešení, která si teoreticky můžete upravit sami, a existují zcela uzavřená.
Cisco nabízí svůj vlastní variant SDN pro datové centrum - ACI. Samozřejmě se jedná o 100% řešení zaměřené na dodavatele z hlediska výběru síťového vybavení, ale zároveň se plně integruje se systémy virtualizace, kontejnerizace, zabezpečení, orchestrace, vyvažování zátěže a dalšími. V podstatě se ale jedná o černou skříňku, bez možnosti plného přístupu ke všem vnitřním procesům. Ne všichni zákazníci souhlasí s takovou variantou, protože jste plně závislí na kvalitě napsaného kódu řešení a jeho implementaci, ale na druhou stranu výrobce má jednu z nejlepších technických podpor na světě a má vyčleněný tým, který se zabývá pouze tímto řešením. Jako řešení pro první projekt byl vybrán právě Cisco ACI.
Pro druhý projekt bylo zvoleno řešení od Juniper. Výrobce má také svůj SDN pro datové centrum, ale zákazník se rozhodl vzdát se zavádění SDN. Jako technologie pro budování sítě byla vybrána EVPN VXLAN fabrika bez použití centralizovaných kontrolérů.
K čemu je to potřeba
Vytvoření fabric umožňuje vybudovat snadno škálovatelnou, odolnou, spolehlivou síť. Architektura (leaf-spine) zohledňuje specifika datových center (cesty prošení provozu, minimalizaci zpoždění a úzkých míst v síti). SD řešení v datových centrech umožňují velmi pohodlně, rychle a flexibilně spravovat takovou fabric, integrovat ji do ekosystému datového centra.
Oběma zákazníkům bylo nezbytné vybudovat záložní datová centra pro zajištění odolnosti, navíc by měl být provoz mezi datovými centry šifrován.
První zákazník již zvažoval řešení bez fabric jako možný standard svých sítí, ale při testech se potýkali s problémy s kompatibilitou STP mezi několika dodavateli hardwaru. Vznikaly výpadky, které způsobovaly pády služeb. A pro zákazníka to bylo kritické.
Cisco už byla firemním standardem zákazníka, podívali se na ACI a další možnosti a rozhodli se, že stojí za to zvolit právě toto řešení. Líbila se jim automatizace správy jedním tlačítkem pomocí jednoho ovladače. Služby se nastavují rychleji, lépe se spravují. Šifrování provozu se rozhodli zajistit spuštěním MACSec mezi přepínači IPN a SPINE. Tímto způsobem se podařilo vyhnout užšímu místu v podobě kryptografické brány, ušetřit na ní a maximálně využít šířku pásma.
Druhý zákazník zvolil řešení bez ovladače od Juniper, protože v jejich stávajícím datovém centru již byla malá instalace s realizací továrny EVPN VXLAN. Ale tam nebyla odolná proti výpadkům (používal se jeden přepínač). Rozhodli se rozšířit infrastrukturu hlavního datového centra a postavit továrnu v záložním datovém centru. Stávající EVPN nebyl plně využit: enkapsulace VXLAN se prakticky nepoužívala, protože všechny hosty byly připojeny k jednomu přepínači a všechny MAC adresy a /32 adresy hostů byly lokální, bránou pro ně byl tento stejný přepínač, nebyla jiná zařízení, kam by bylo třeba stavět VXLAN tunely. Šifrování provozu se rozhodli zajistit pomocí technologie IPSEC mezi firewally (výkon MSCE byl dostatečný).
Také si osahali ACI, ale rozhodli se, že kvůli vendor-locku budou muset zakoupit příliš mnoho zařízení, včetně výměny nedávno zakoupeného nového vybavení, a to prostě nemá ekonomický smysl. Ano, továrna Cisco se integruje se vším, ale uvnitř samotné továrny jsou možné pouze její zařízení.
Na druhou stranu, jak bylo řečeno dříve, továrnu EVPN VXLAN s jakýmkoli sousedním dodavatelem jen tak nesmixujete, protože realizace protokolu se liší. Je to jako křížení Cisco a Huawei v jedné síti — zdánlivě, standardy jsou společné, jen s bubnem si člověk bude muset zatančit. Vzhledem k tomu, že se jedná o banku, a testy na kompatibilitu by byly velmi dlouhé, rozhodli se, že bude lepší nyní nakoupit od stejného dodavatele a neodcházet příliš od základních funkcí.
Plán migrace
Dva datové centra na bázi ACI:
Organizace interakce mezi datovými centry. Bylo vybráno řešení Multi-Pod — každé datové centrum je pod. Byly zohledněny požadavky na škálovatelnost počtu přepínačů a na latenci mezi podmi (RTT méně než 50 ms). Bylo rozhodnuto nebudovat Multi-Site řešení kvůli snadnosti správy (pro řešení Multi-Pod se používá jednotné řídící rozhraní, pro Multi-Site by byly potřeba dvě rozhraní, nebo by byl potřebný Multi-Site Orchestrator), a protože nebylo požadováno geografické zálohování lokalit.
Z pohledu migrace služeb ze staré sítě byl vybrán nejtransparentnější variant, postupně přenášet VLAN odpovídající určitým službám.
Pro migraci byl každému VLAN vytvořen odpovídající EPG (End-point-group) na fabric. Nejprve byla síť roztažena mezi starou sítí a fabric za L2, poté po migraci všech hostitelů byl brána přenesena na fabric a interakce EPG se stávající sítí probíhala přes L3OUT, přičemž interakce mezi L3OUT a EPG byla popsána pomocí kontraktů. Příkladná schéma:
Příkladná struktura většiny politik fabric ACI na obrázku níže. Veškeré nastavení je založeno na politikách, vnořených do jiných politik atd. Zpočátku je velmi obtížné se v tom zorientovat, ale postupem času, jak ukazuje praxe, administrátoři sítí si na tuto strukturu zvyknou přibližně za měsíc, a poté přichází pochopení, jak je pohodlná.
Porovnání
V řešení Cisco ACI je třeba zakoupit více vybavení (samostatné přepínače pro Inter-Pod interakci a APIC kontroléry), což způsobilo, že je dražší. Řešení Juniper nevyžadovalo nákup kontrolérů a pomocného vybavení; podařilo se částečně využít již existující vybavení zákazníka.
Toto je architektura EVPN VXLAN fabric pro dvě datová centra druhého projektu:
V ACI dostáváš hotové řešení – není potřeba zasahovat, není potřeba optimalizovat. Při prvním seznámení zákazníka s továrnou nejsou potřeba vývojáři ani podpůrný personál pro kód a automatizaci. Stačí pouze provoz, mnoho nastavení lze provádět přímo pomocí průvodce, což není vždy výhodné, zejména pro lidi zvyklé na příkazový řádek. V každém případě je potřeba čas na to, abychom si přestavili myšlení na nové koleje, na specifika nastavení prostřednictvím politik a manipulaci s mnoha vzájemně se prolínajícími politikami. Je velmi žádoucí mít také jasnou strukturu pojmenování politik a objektů. Při jakémkoli problému v logice práce kontroleru lze problém vyřešit pouze prostřednictvím technické podpory.
V EVPN – konzole. Trp nebo se raduj. Známé rozhraní pro starou gardu. Ano, existuje standardní konfigurace a příručky. Budeš muset studovat manuály. Různé konstrukce, vše jasné a detailní.
Samozřejmě, v obou případech je lepší při migraci nejdříve migrovat méně kritické služby, například testovací prostředí, a až poté, po odhalení všech chyb, přistoupit k produkci. A nenastavovat to v pátek večer. Není dobré věřit dodavateli, že vše bude v pořádku, vždy je lepší se zabezpečit.
Na ACI platíš více, ačkoli v současnosti Cisco aktivně propaguje toto řešení a často poskytuje dobré slevy, ale šetříš na údržbě – podpoře. Správa a jakákoli automatizace továrny EVPN bez kontroléru vyžaduje investice a pravidelné výdaje – monitoring, automatizaci, zavádění nových služeb. Přitom počáteční spuštění ACI trvá o 30–40 procent déle. Děje se to proto, že déle trvá vytvoření celého potřebného souboru profilů a politik, které budou následně použity. Ale s růstem sítě se množství potřebných konfigurací snižuje. Používáš již předem vytvořené politiky, profily, objekty. Můžeš flexibilně nastavovat segmentaci a bezpečnost, centrálně spravovat kontrakty, které odpovídají za povolení různých interakcí mezi EPG, – objem práce se náhle zmenšuje.
V EVPN je potřeba konfigurovat každé zařízení v továrně, pravděpodobnost chyby je vyšší.
Pokud se ACI zavádí pomaleji, EVPN se ladil téměř dvakrát déle. Zatímco v případě Cisco můžete vždy zavolat technickou podporu a zeptat se na síť jako celek (protože je to pokryté jako řešení), u Juniper Networks kupujete pouze hardware, a to je vše, co je pokryto. Odeslaly se pakety z zařízení? No dobře, dál jsou to vaše problémy. Můžete však otevřít otázku ohledně výběru řešení nebo návrhu sítě — a pak doporučí zakoupit profesionální službu za příplatek.
Podpora ACI je velmi kvalitní, protože je oddělená: samostatný tým se zaměřuje pouze na to. Jsou zde také specialisté, kteří mluví rusky. Příručka je podrobná, řešení jsou předem definována. Sledují a radí. Rychle validují návrh, což je často důležité. Juniper Networks dělá to samé, ale mnohem pomaleji (my jsme to měli tak, nyní by to mělo být podle drbů lepší), což vás nutí dělat vše sami tam, kde by vás mohl poradit řešení-inženýr.
Cisco ACI podporuje integraci se systémem virtualizace a kontejnerizace (VMware, Kubernetes, Hyper-V) a centralizované řízení. Existují síťové služby a bezpečnostní služby — vyvažování zátěže, firewally, WAF, IPS a další… Dobrá mikrosegmentace hned z krabice. U druhého řešení je integrace se síťovými službami složitější a je lepší se předem podívat na fóra s těmi, kdo to tak dělali.
Výsledek
Pro každý konkrétní případ je třeba vybrat řešení, nejen na základě ceny vybavení, ale také je třeba zohlednit další náklady na provoz a hlavní problémy, s nimiž se zákazník aktuálně potýká, a jaké má plány na rozvoj IT infrastruktury.
ACI se díky dalšímu vybavení ukázalo jako dražší, ale je to hotové řešení bez potřeby dodatečných úprav, druhé řešení je složitější a nákladnější z hlediska provozu, ale levnější.
Pokud chcete probrat, kolik by mohla stát implementace síťové fabriky u různých dodavatelů a jaká architektura je potřeba, rádi se setkáme a promluvíme si o tom. Před návrhem hrubé architektury (se kterým lze počítat rozpočty) poradíme zdarma, podrobné zpracování je samozřejmě již zpoplatněné.
Vladimir Klepče, firemní sítě.
Zdroj: habr.com
