HP Distributed Cloud Networking (3) – politiky a ovládání řešení (VSD)

Část 3 z celkových 7 v seriálu HP Distributed Cloud Networking

Administrátoři i automatizační a cloudové nástroje komunikují s DCN řešením skrze definici politik v komponentě Virtual Services Directory. Jak funguje?

Komunikace VSD s ostatními

Rekapitulujme z předchozích částí jak VSD komunikuje. Směrem nahoru používá tři základní prostředky. Webové rozhraní je určeno lidským uživatelům, kteří chtějí definovat politiky pro jednotlivé tenanty, zóny a tak podobně. RESTful API umí totéž v programovatelné podobě ideální pro automatizační IT nástroje jako je HP Operation Orchestration nebo HP Cloud Service Automation (samostatně nebo jako součást HP Helion CloudSystem). Třetí formou je přímá integrace do cloud management nástrojů přes speciální message bus – například tak, že HP nabízí integrační OpenStack Neutron plugin (zahrnující L2 i L3 funkce). Další podporované integrace jsou s CloudStack a VMware vCenter nebo vCloud.

vsd_1

Jednotlivé politiky jsou komunikovány k VSC kontrolerům, kterých může být hned několik (počet není v zásadě omezen). Maximální škálovatelnost jedné instance VSD je 256 000 VM (nad tuto hranici se lze dostat vícero VSD systémy s replikací databáze). Protokol pro politiky je XMPP ( Extensible Messaging and Presence Protocol). Zajímavostí je, že protokol se původně jmenoval Jabber (to je vám asi povědomé) a vznikl v roce 1999 jako otevřený protokol postavený na XML pro messaging a presence.

Síťové abstrakce – architektura politik

Konečným cílem VSD je definice konkrétních parametrů a nastavení virtuálních portů tak, jak se do nich připojují VM. Jak se k němu propracovat?

vsd-3_654x425

Prvním stupněm je definice tenant (někdy také označováno jako enterprise či organizace). U veřejné služby by se jednalo o konkrétního zákazníka, v nadnárodním enterprise třeba o dceřiné společnosti či státní pobočky. V rámci tenanta se pak zakládají domény, což je společný L3 prostor. V klasické terminologii bychom o doméně mluvili jako o VRF (ve skutečnosti to tak je, jde o VRF definovanou v distribuovaném VSC/VRS routeru s možností mapovat ji na L3 VPN na PE routeru). Následně uvnitř domény můžeme vytvářet zóny. Podobně jako firewallů jde o skupinu virtuálních portů sdílejících stejné bezpečnostní nastavení. Při vytváření politik se lze právě odkazovat na tyto zóny, například říci, že při komunikaci mezi zónou „APP“ a zónou „WEB“ musí provoz procházet firewallem, load-balancerem a mít správnou QoS. Zóna nevytváří žádnou skutečnou entitu (nedá se mapovat na nějaký klasický konstrukt typ VLAN apod.) a podobně jako u firewallů je skutečně jen logickou množinou zjednodušující vytváření pravidel. A co je obsahem těchto množin? Jednak jsou to subnety (tedy L2 segmenty, řekněme VLAN, ve které se VM vzájemně přímo vidí) nebo kokrétní vPorty. Je tedy možné pracovat až s granularitou konkrétních virtuálních portů (a k těm se automaticky po discovery připojí VM dle politiky, případně gateway). Pro zjednodušení konfigurace některých složitějších úloh (typicky service chaining) se na úrovni domény dají definovat ještě vPortTagy (jakési logické seskupení vPortů).

Jak se to dělá krok za krokem?

  1. Nejprve tenant administrátor vytvoří Domain Template, tedy šablonu pro doménu. Přidá zóny, subnety a vPortTagy a může i definovat bezpečnostní, QoS nebo service insertion politiky (o těch podrobněji jindy). Následně může říci, kteří uživatelé budou mít právo tuto šablonu využít.
  2. Uživatel, který na to má právo šablonu použije, přiřadí jí unikátní jméno, route target a route distinguisher a tím vznikne Domain Instance. Teprve v tento okamžik se služby reálně vytvoří. Pokud by došlo k modifikaci původní šablony, tyto změny se promítnou ve všech instancích.
  3. Dále je možné Domain Instance upravit. Například přidat další zóny a subnet, statické routy do okolního světa (nemají vliv na lokální směrování, které vždy jde přímo na cílový vPort a v praxi se častěji použije MP-BGP bez nutnosti statických cest). Bezpečnostní a QoS politiky je možné vytvářet, ale nelze jimi přemostit (nahradit) ty definované v šabloně (operátor s nižšími právy tak emůže obejít bezpečnostní politiku nadřazeného administrátora). Je možné přidávat nové vPortTagy a samozřejmě nové vPorty (virtuální porty, do kterých zapadnou VM).
  4. V dalším kroku se dají definovat sdílené zdroje, tedy to, že tenant vystoupí ze svého ohraničeného prostoru do globálního či jiného světa. Například k jeho web serverům s aplikací bude přístup z Internetu. Lze použít entitu nazvanou public subnet, dále klasickou cloudovou floating IP (tedy 1:1 NAT na externí reálnou IP) a L2 subnety (propojení někam jinam po L2).
  5. Poslední fáze je vznik VM a její přiřazení k vPortu (na tom je vlastní politika). Při definování VM v hypervisoru má VSD k dispozici klíčové informace jako UUID nebo tenant údaje, u vPortů pak zase zónu, adresaci, QoS politiky, service chaining a tak podobně.

Analytické údaje

Druhou klíčovou funkcí VSD je sběr údajů a to velmi podrobně ze všech VRS komponent (a těch může být tisíce) s granularitou až na samotné VM. Z toho důvodu je technicky postavena na systémech určených pro zpracování Big Data, konkrétně OpenTSDB běžící nad Apacha HBase. To dovoluje dlouhodobě a přesně shromažďovat veškeré metriky včetně analytických služeb. Co všechno lze sledovat? Pro každý vPort (tedy VM) můžete sledovat pakety a byty in a out, chyby in a out, zahozené pakety in a out a pakety zahozené kvůli překročení rate-limit pravidel in a out.

vsd-5_654x269

Kromě shromažďování surových dat si můžete proaktivně nechat zasílat informace o událostech překračujících jisté meze (například zaplacené pásmo apod.). Tyto ukazetele můžete nastavit na per-tenant, per-doména, per-zóna i per-subnet úrovni a to pro libovolný ze zmíněných ukazatelů. Akce je vyvolána pokud je hodnota překročena po určitou nastavenou dobu (například dáte limit přenesených dat v konkrétní zóně) nebo se sleduje průměrná hodnota v plovoucím okně.
O některých politikách jako je QoS, bezpečnost nebo service chaining bude v seriálu řeč později.

Series Navigation<< HP Distributed Cloud Networking (2) – architekturaHP Distributed Cloud Networking (4) – jak se plní RIB/FIB? (VSC) >>
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 [...]

No Comments Yet

Napsat komentář

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