L3 a kontejnery bez overlay: Project Calico prakticky (1) – architektura

Dost bylo Spanning Tree a pokusů o L2 fabric. L3 BGP fabric je dnes norma a nad tím overlay (třeba HPE DCN / Nuage). Dnes ale půjdeme (dle mého názoru) ještě dál co do moderního řešení. Podíváme se do datového centra pro cloud native aplikace. Zbavíme se dosavadních způsobů segmentace sítě, řešení bezpečnosti a opustíme termín „síť“. V této sérii budeme zkoumat Project Calico, L3 řešení pro OpenStack nebo kontejnery bez overlay. Pro úvod do problematiky doporučuji předchozí článek.

Co můžete v této sérii očekávat?

Dnes ještě té praxe mnoho nebude (ale slibuji – je to naposled) a zaměříme se na „proč“ a architekturu. V příštím díle už ovšem společně Project Calico nainstalujeme, rozchodíme a získáme první zkušenosti. V dalším článku pak napojíme BGP v compute nodech na BGP v top-of-rack prvku (v rámci ukázky použiji virtuální HPE router s Comware OS). Následně si ukážeme mikrosegmentaci a tvorbu politik včetně nahlédnutí pod technickou kapotu. Co dál? Plánuji ukázat integrace do orchestrátorů – určitě si zkusíme plugin pro Docker libnetwork a Swarm a třeba se dostaneme i k dalším možnostem nasazení Project Calico jako je OpenStack plugin (tedy pro klasičtější VM), Kubernetes (kontejnery) a možná i Mesos (abstrakce hardwaru datového centra aka distribuovaný kernel pro provoz aplikací a platforem).

Proč vznikla overlay

Když přišlo to, čemu dnes říkáme virtualizace, tedy VM a hypervisory, nebyla to vlastně změna přístupu. Izolaci jsme prováděli na úrovni hardwaru, jen jsme ten skutečný nahradili jeho simulací. Uvnitř VM ale běží OS a stále si myslí, že mluví k hardwaru, má celý kernel, drivery a tak podobně. Dostali jsme obrovské výhody (šablony, lepší využití hardwaru, rychlejší instalaci, …), ale nezměnili přístup. A tak jsme přidali virtuální switch a do něj připojili virtuální síťové karty. „Vnitřní“ porty používáme jako access porty ve VLAN (port group), vnější jako VLAN trunk. To co byl dřív přístupový switch jsme přenesli do formy vSwitche, ale koncept jsme opět ponechali. Dodnes přemýšlíme tak, že společné servery dáváme do „sítě“, VLAN. Tím je oddělujeme. Mezi nimi směrujeme a to je také místo, kde může aplikovat politiku a říct která síť s jakou může komunikovat a jak.

Jak jsme se ale stále víc posouvali ke kompletní infrastruktuře jako službě (IaaS, například OpenStack), začalo to být technicky obtížné, málo flexibilní a neudržitelné. Především to ale mělo návaznosti na vytváření VLAN ve fyzické infrastruktuře, což se obtížně automatizovalo. Trh hledal řešení, která neznamenají změnu přemýšlení, ale umožňují je použít v novém světě IaaS, ve větší škále a s automatizací. Tak jsme přišli na to, že L2 fyzické sítě v DC už nechceme (bylo na čase), ale koncept „síť“, router atd. chceme zachovat. Nastoupila overlay – dnes velmi odladěný způsob řešení síťařiny v IaaS, který vám nenutí nic zásadně nového – nemusíte měnit aplikace ani svoje zaběhané přemýšlecí postupy. Vytvořte si sítě jaké chcete, routery, firewally. Každý compute node je schopen zabalit pakety (typicky do VXLAN), takže fyzickou sítí nejste nijak omezováni.

Dokud pracujeme s aplikacemi tak, že VM používáme skoro stejně jako fyzický server, je overlay naprosto ideální řešení zejména pro automatizaci.

Proč vznikl Project Calico

Řešení s overlay ale má i své nevýhody. V první řadě je to poměrně složité řešení. L2/L3 paket je před odesláním na drát zabalen do overlay L4 paketu. Výsledný obrázek je tedy L2-L3-UDP-L2-L3 … docela složitý řetízek zejména pokud řešíte troubleshooting. Má to samozřejmě vliv na věci jako je MTU, latence a výkon (i přes možné akcelerace na kartě). Kromě vyšší složitosti datové vrstvy je tu komplexnější control plane. To má vliv na čas sestavení potřebných nastavení (před startem VM se musí dohodnout podoba tunelu, číslo VXLAN identifikátoru, sestavení konců tunelů apod.). V případě klasického přístupu s VM, které jsou dlouhověké (žijí dny, týdny, měsíce, někdy i dokonce roky), to není problém. Ale ve světě cloud native aplikací a kontejnerů, kde může v rámci autoscaling kontejner existovat jen vteřiny či minuty a kontejnery průběžně vznikají a zanikají podle zátěže aplikace, už to nemusí být dostatečně rychlé. Ve světle budoucích řešení typu server-less computing, tedy například kontejner vlastně neběží a spustí se až při nějaké události, která indikuje, že je to potřeba (například dorazila data z IoT senzoru) a po dokončení zpracování kontejner mizí, je nutnost rychlého a pružného spuštění zásadní.

Další vlastností overlay je, že váš mobil VXLANám nerozumí. Tedy než paket opustí vaše datové centrum, musí se přemontovat na regulerní paket bez tunelu. Například v případě distribuovaného routeru compute node tunel odstraní a provede překlad adresy (NAT, Floating IP). Nebo to provede centralizovaný softwarový router (problém s výkonem). Rozbalení může provádět i switch ve funkci hardwarového VTEP, ale podpora VXLAN musí být přímo vlastností použitého ASIC (a například u Broadcom Trident II sice toto v ASIC je, ale pouze pro L2 transofrmaci z VXLAN do VLAN – nemůžete paket rozbalit a zaroutovat nebo přeroutovat z jedné VXLAN do druhé na základě vnitřku paketu – něco z toho umí novější čipy typu Tomahawk). Další variantou tedy je rozbalení na nějakém hardwarovém routeru, ale tam si za rozumný výkon docela připlatíte.

Overlay je tedy relativně složité řešení, s nižším výkonem, často nepřímou adresovatelností jednotlivých IP adres uvnitř a vně cloudu a s požadavkem na bránu mezi světy cloudu a uživatelů.

Project Calico na to jde jinak. Nepoužívá overlay ani složitý control plane. Každý workload, ať už je to VM nebo kontejner, dostane svojí přímo adresovatelnou IP adresu bez nutné segmentace – L3 flat prostor. Z pohledu konektivity může každá VM a kontejner mluvit přímo s každou další, případně i přímo se systémy mimo cloud. Místo definice pravidel „kdo s kým smí“ na úrovni směrování sítí, používá výhradně mikrosegmentaci přímo v compute node. O adresách „v cloudu“ se fyzická síť (prakticky vždy top-of-rack prvek, tedy první fyzický box) dozvídá přes osvědčený a dobře škálující BGP protokol. Jednoduché, rychlé, dobře škálovatelné.

Architektura

Felix

Jde o agenta, který běží na každém compute node. Poslouchá požadavky a stará se o vytváření interfaců, směrovací tabuly (kernel FIB pro lokální VM a kontejnery), programování bezpečnostních pravidel (iptables) a udržuje zdravotní stav nodu (reportuje problémy).

Orchestrační plugin

Calico je typicky řízeno z vyššího orchestrátoru. Například má Neutron ML2 plugin do OpenStack, libnetwork driver pro Docker, podporuje Kubernetes a Mesos. Nejen, že orchestrátor žádá Calico o vytvoření „spojení“, ale Calico také poskytuje zpětnou vazbu (například v momentu havárie).

Etcd

Stav Calico je držen externím způsobem v Etcd – distribuovaném Key-Value store, tedy řekněme distribuované databázi.

BGP Client – BIRD

Compute node participuje v BGP a poskytuje informace o IP adresách svých VM a kontejnerů. V produkčním nasazení se nejčastěji kombinuje s Route reflectorem třeba v top-of-rack prvku. BIRD se podívá na kernel FIB (naplněný Fenixem) a poskytuje tyto informace BGP Peerům.

Konec teorie – příště už si Calico nainstalujeme.

Series NavigationL3 a kontejnery bez overlay: Project Calico prakticky (2) – rozjezd >>
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í [...]
  • 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, [...]
  • OpenSwitch a Ansible automatizace pra... V minulém díle jsme si rozjeli Lead-Spine OpenSwitch topologii s využitím Dockeru a skript nám vygeneroval také hosts file pro Ansible. Dnes se vyzkoušíme napojení na Ansible 2.1. Příprava Ansible a vašeho VM První co potřebujeme udělat je nainstalovat Ansible minimálně ve verzi 2.1. Postup najdete zde: http://docs.ansible.com/ansible/intro_installation.html Dále vyřešíme nastavení SSH klienta v naší [...]
  • L3 a kontejnery bez overlay: Project ... Část 6 z celkových 6 v seriálu L3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico prakticky (1) – architekturaL3 a kontejnery bez overlay: Project Calico prakticky (2) – rozjezdL3 a kontejnery bez overlay: Project Calico prakticky (3) – BGPL3 a kontejnery bez [...]

Napsat komentář

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