Sítě datových center dnes rychle migrují z hierarchických L2 řešení na moderní L3 fabric postavený na BGP až do Top-of-Rack prvku. Nad tím pak provozují overlay. Nepřijde čas s nástupem kontejnerů a cloud native aplikací nahradit overlay za čistou tradiční L3?

Tradiční hierarchická L2 síť

Nejprve jsme měli datová centra optimalizovaná na client/server architekturu, kde jsme předpokládali, že většina provozu je mezi klientem a serverem. Stavěli jsme přístupovou vrstvu a agregační vrstvu na L2 (s využitím legendárně nenáviděného Spanning Tree protokolu) a v core byl L3 směrovač (u některých bylo L3 i v agregaci, ale serveraři nadávali). Jenže virtualizace, méně monolitické aplikace a IP (a předsmrtný záškub FCoE) storage nám to dost nabourala. Daleko víc provozu začalo být mezi systémy uvnitř DC a klasická architektura nevyhovovala. Bylo nutné něco změnit a navíc nás stále trápí to, že než udělat aplikaci moderněji a pořádně, tak budeme využívat vMotion a Live Migration a přesouvat dědečky z jednoho domečku do druhého. Osud byl určen – nové L2 řešení.

L2 fabric

Většina existujících datových center už dnes jede na druhé generaci L2 sítí. Nejprve byly snahy přijít s komplexním pohledem na L2 fabric přes celé datové centrum a po letech práce vznikly (vzájemně si konkurující) standardy TRILL a SPB (a také z obchodních důvodů proprietární drobně pozměněné varianty téhož, například FabricPath). Také zde byly pokusy sjednotit to celé pod jediný control plane jako v případě Q-fabric a v jistém smyslu sem patří i ACI. Bohužel se rozšířily i nesmysly jako je Fabric Extender (něco co jde proti myšlence fabriců s důrazem na konektivitu uvnitř datového centra) a nutno bohužel říct, že nejen Cisco budiž souzeno. Nicméně nakonec přes všechny vychytávky naleznete ve většině sítí řešení postavené na M-LAG jako je vPC, IRF, Virtual Chassis, SMLT a tak podobně.

Typicky tedy v racku najdete dva ToR přepínače s nějakou formou M-LAG, takže se minimálně z pohledu LACP tváří jako jedno zařízení. Typicky je budeme považovat za Leaf a ten napojíme do všech Spine prvků (minimálně 2, maximálně kolik vám výrobce a ECMP dovolí). Spine bude rovněž v M-LAG, takže dosahujeme všech aktivních linek s ECMP (a nemáme potřebu Spanning Tree). Přes všechny chytristiky je tohle nejčastější design, který je navíc navenek M-LAG prvků standardizovaný, takže můžete mít co rack to jiného výrobce ToR.

L3 BGP fabric od ToR a nad to overlay

Moderní datová centra velkých hráčů už ovšem fungují jinak a enterprise postupně začíná prozírat a jde stejným směrem. L2 nebylo vymyšleno pro neomezené počty koncových bodů a proto Internet používá principů L3 a BGP protokolu. Nabízí tak velkou škálu (určitě si říkáte, že ji nepotřebujete, ale srovnejte počet vašich nevirtualizovaných serverů před deseti lety s počtem VM, které máte dnes a představte co se stane, když nasadíte kontejnery s distribuovanými aplikacemi postavenými na mikroslužbách), stabilitu, spolehlivost a schopnost pevně a rozhodně mít věci pod kontrolou. Moderní datové centrum je postavené na L3 fabric, tedy Top-of-Rack prvek je L3 směrovač. Typycky využívá BGP protokolu a nejčastěji tak, že každý rack (jeden nebo dva ToR prvky) je vlastní AS a mezi Leaf a Spine vrstvou jede eBGP s ECMP (rozkládání zátěže na redundantní stejně vzdálené cesty). Jednoduchý troubeshooting, naprosto standardizovaná technologie s dlouhou historií. Síťařké nebe.

„Hele, ale nejede nám vMotion !!“, zakřičel serverař. A má pravdu. Stávající aplikace si často neumí poradit samy a přesouvání serverů za živa je důležitou (a doufejme prozatimní a umírající) součástí života dnešního datového centra. Navíc občas najdeme i ne-IP protokoly pro heartbeat clusterů a podobné záležitosti. V hlavách nám stále zůstávají naučené principy jako je síť (třeba VLAN), kde se uvnitř vidíme a ven jdeme přes router, kde se řekne co a jak (policy). Jak tohle všechno mít, ale nevzdat se snu o L3 fabricu (a ještě přitom získat velkou hromadu dalších výhod v oblasti automatizace a bezpečnosti)? Overlay. Postavme nad skvělou L3 sítí něco jako soustavu VPN, v kterých můžeme simulovat klasičtější svět, ale daleko elegantněji, programovatelně a bez návaznosti na drahý hardware (tedy pokud nezvolíte jediné řešení, které tento princip porušuje – ACI). Nativní OpenStack Neutron řešení, HPE DCN, Nokia Nuage, Juniper Contrail, VMware NSX, Weave, Flannel a další. O overlay toho na tomto webu najdete docela dost a je to v dnešním stavu věcí myslím nejlepší řešení.

Nicméně není bez potíží. Je to kostrbaté – pakety zabalené v jiných paketech (ve Wiresharku si trochu pobrečíte), docela složitý control plane, výkonnostní limity (daň za sbalování a rozbalování) a nutnost převaděče mezi „cloudem“ a uživatelem. Když chcete mluvit ven čeká vás pravděpodobně nějaké rozbalení na konkrétním prvku (VXLAN VTEP na switchi, MPLSoGRE na routeru apod.), nebo v nějakém softwarovém routeru a nebo můžete čekat nějakou formu NAT operace.

Návrat k jednoduchosti s L3 BGP až ke kontejneru

Plánujete moderní aplikace (mnoho informací o cloud native vývoji najdete na www.cloudsvet.cz)? Ty nepotřebují vMotion ani L2 heartbeat. S nástupem kontejnerů lze očekávat ještě více koncových bodů (tedy kontejnerů) – na fyzický server se vám vejde třeba 20 VM nebo třeba 500 kontejnerů. Je zřejmé, že se neobejdete bez automatizace a možná ani bez jiného řešení izolace workloadů. Složitost overlay tak možná nebude vítaná – tak ji dejte pryč. L3 BGP můžete dotáhnout až do hostitele, tedy do fyzického serveru. Týká se to jak VM tak kontejnerů, ale protože moderní aplikace bude častěji využívat právě kontejnery, mluvím převážně o nich. Co to znamená a jak takový design vypadá?

Z více možností vyberu jednu. Přímo v hostiteli (compute node) budete mít například Project Calico. Každý kontejner dostane svojí IP adresu a chceme zajistit, že s ostatními se může jednoduše bavit na IP – žádná NAT, žádná FloatingIP, žádná overlay enkapsulace (jako je VXLAN) – jen krásná čistá IP komunikace. V každém hostiteli běží BGP, které se používá k přenášení informací a použitých IP adresách (tedy o běžících kontejnerech). Typicky budou servery v jednom racku s jejich Top-of-Rack prvkem sdílet autonomní systém. ToR tak bude fungovat jako Route Reflector a uvnitř racku poběží iBGP, které bude vyměňovat /32 informace o kontejnerech. Hostitel na všechny ARP dotazy z kontejneru odpovídá svojí MAC adresou. Uvnitř hostitele není vSwitch, ale pouze vRouter – kromě odpovědi na ARP se tady žádné L2 prostě vůbec neděje. ToR Leaf je pak přes eBGP napojen do Spine a může snižovat množství potřebných záznamů ve směrovací tabulce tím, že bude používat sumarizaci a výchozí routu. Díky tomu se dá i při relativně velké instalaci udržet požadavek na ToR směrovací tabulku relativně nízko a plně v možnostech dnešního hardware.

Jak se izolují jendotlivé provozy, když se nepoužívají subnety ani L3 VPN? Calico jednoduše používá politiku přímo na kraji sítě. Každému kontejneru přiřadíte tag (nebo volitelně i TCP/UDP porty) a na jejich základě se přímo v hostiteli zajistí odělení přes iptables. Je to dobře spravovatelné, chytré a při tom velmi jednoduché a čitelné.

Pokud budujete prostředí pro moderní aplikace vypadá cesta plného L3 zcela bez overlay velmi lákavě. Na Project Calico, který můžete rozjet třeba s OpenStack IaaS nebo Docker, se na těchto stránkách podíváme podrobněji někdy příště.

Doporučení

Chcete provozovat moderní datové centrum třeba s OpenStack a hledáte velkou stabilitu a spolehlivost a současně potřebujete využít stávajích konceptů? Chcete robustní řešení, která už jsou dobře odzkoušená reálným provozem? Volte overlay s tím, že underlay (fyzickoou síť) postavíte na L3 fabric. Přemýšlíte o budoucnosti vašich cloud native aplikací, sázíte na kontejnery a nebojíte se trochu experimentovat? Zkuste to bez overlay, třeba s Project Calico. A nebojte se mít víc systémů. Doba, kdy celé datové centrum muselo být jeden systém, je myslím pryč. Klidně bude jeho část legacy, druhá část OpenStack a třetí Kubernetes – jiné aplikace mohou používat jiný model chování, žádná ostuda – naopak.