Je L3 bez (!) overlay budoucnost datových center?

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.
Similar posts
  • Moderní 10G v datovém centru s novou ... HPE tento týden oznámilo evoluční vývoj portfolia v oblasti data center 1U prvků s 10G/40G/100G technologií, konkrétně novou řadu 5940. Co je nového? Hardwarové vlastnosti Prvky přichází s novou generací 10/40/100 čipů, které umožnily mít nově prvky se 100G uplinky (a to hned šesti) a také přináší podporou nových vlastností jako je směrování VXLAN (předchozí [...]
  • ArubaOS-Switch 16.02: IP SLA i pro Ar... IP SLA Ve světě směrovačů už poměrně dlouho existuje možnost monitorovat dostupnost a kvalitu spojení s využitím L3 protokolů. Můžete například z pobočky v pravidelných intervalech testovat dostupnost brány datového centra nebo klíčového serveru včetně měření doby jeho reakce (round-trip-time). Dá se také namířit dva routery proti sobě tak, že jeden se ptá a druhý [...]
  • OpenSwitch v GNS3 – chcete GUI ... GNS3 verze 1.5 Pokud neznáte GNS3, jde o velmi dobrý síťový simulátor. Narozdíl od jiných řešení, o kterých jsem na netSvět už psal (Docker, shell skript, Mininet), je zaměřený především na síťaře, kteří chtějí pracovat s virtuální sítí a přizpůsobuje se jejich pohodlí. Do CI/CD pipeline se tedy moc nehodí, ale za to má výborné [...]
  • OpenSwitch a Ansible automatizace pra... Posledně jsme si nastavili naší virtuální OpenSwitch leaf-spine topologii a vybudovali jsme BGP L3 fabric. Dnes si ukážeme více z životního cyklu s použitím Ansible – otestování sítě, vrácení odchylek do požadovaného stavu sítě a rolování změn. Jste líní číst? Mrkněte na video: Playbook pro testování sítě Ansible můžete použít i pro testování, že síť [...]
  • OpenSwitch a Ansible automatizace pra... Minule jsme napojili naši virtuální topologii na Ansible a spustili náš první testovací Playbook. Dnes provodeme automatizovanou konfiguraci L3 fabric a otestujeme síť. Příprava konfiguračních podkladů Pro zprovoznění L3 fabric potřebujeme Loopback adresu, IP adresy na jednotlivých spojeních mezi prvky a nastavení BGP (autonomní systémy, peering). V našem Ansible prostředí si vytvoříme jeden YAML soubor, [...]

2 Comments

  1. Zdenek Zdenek
    21.3.2016    

    Moc pěkný článek jako vždy.
    Jen bych dodal, že existuje jedno velice zajímavé řešení do datových center pro mikrosegmentaci, viz:
    http://www.hillstonenet.com/our-products/hillstone-cloudhive/

    • Tomáš Kubica Tomáš Kubica
      29.3.2016    

      Díky.

      Co se uvedeného řešení Hillstone týče myslím, že je dnes zásadní dívat se na síť v kontextu infrastruktury datového centra, ne jednotlivě. Nešel bych cestou síťově specifického řešení bez integrací do orchestrátorů jako je OpenStack, vRealize či Azure on-prem. Současně bych také preferoval řešení, která mají upgrade cestu a platnost i ve světě kontejnerů – overlay přístupy jako je DCN/Nuage nebo Contrail tam už jsou. Jinak mikrosegmentaci rozhodně považuji za správnou cestu (ať už je řešena jakkoli) a všechna řešení typu DCN, Nuage, čistý Neutron s OVS i Linux Bridge, Azure on-prem, NSX, Weave, Project Calico i zmíněný Hillstone ji nabízí.

      Díky za odkaz, neznal jsem.

No Pings Yet

  1. L3 a kontejnery bez overlay: Project Calico prakticky (1) – architektura – netSvět on 2.8.2016 at 7:00
  2. L3 a kontejnery bez overlay: Project Calico prakticky (3) – BGP – netSvět on 2.8.2016 at 7:00

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *