Modernizujte konektivitu vašich poboček s Azure Virtual WAN

Jak máte víc a víc aplikací v Azure z nichž řada z nich vyžaduje privátní konektivitu možná vám začne dávat smysl využít Azure i pro propojení poboček po celém světě. Tradiční řešení, L3 VPN MPLS služba operátora, se dá dobře využít s Express Route, kdy se z Azure stane vlastně další pobočka celého routing systému. Řada zákazníků se ale začíná dívat na levnější alternativy propojení poboček s technologiemi SD-WAN. Azure vám s tím dokáže pomoci a navíc získáte jednodušší a přímější konektivitu do Azure a navíc přesunete obrovský kus komunikace do sítě Microsoft, která je robustní a obsluhuje celý svět. Co je Azure Virtual WAN a k čemu vám může být dobrá?

Tradiční řešení s IPSec VPN

Klasický scénář je, že máte pár hlavních lokalit a v nich dost možná i lokální datové centrum. Jednu v Evropě, jednu v USA a jednu třeba v Asii. Protože máte privátní služby v Azure rozhodnete se vaši hlavní lokalitu a datové centrum v Praze propojit IPSec tunelem do Azure regionů, které využíváte, například West Europe, North Europe, East US a West US. Totéž uděláte v Americe. Jak následně řešit vaše pobočky v Německu, Anglii a Francii? Možná v nich sestavíte VPN tunel do vaší hlavní lokality, která funguje jako Hub pro vaše připojení a tudy také odchází provoz do Azure. Totéž uděláte v Americe a své dva hlavní huby propojíte dalším tunelem mezi sebou. Toto řešení má velkou výhodu v ceně - od operátorů si kupujete jen silný Internet a nad ním si stavíte privátní síť sami, což je o poznání levnější, než využití služeb MPLS a privátních okruhů. Jsou tady ale i méně příjemné vlastnosti řešení:

  • Všichni uživatelé do Azure chodí přes váš nejbližší Hub, což není optimální trasa - kancelář v Anglii má do Azure regionu v Dublinu určitě kratší cestu, než přes Prahu.
  • Veškerá komunikace jde přes veřejný Internet. Bezpečnostně není problém, protože tunel je silně šifrovaný, ale je otázkou, zda konektivita mezi zeměmi je dostatečně kvalitní. V Evropě to typicky není vážný problém, ale v Asii či Jižní Americe je to výrazně horší.
  • Správa systému je na vás a je tam dost práce, zejména když potřebujete menší spolehlivost Internetu vyvážit redundantními tunely a chytrým posíláním dat tou či onou cestou (tady vám pomohou SD-WAN produkty).

Tradiční řešení s L3 MPLS operátora a Express Route

Velké firmy typicky využijí L3 VPN služby operátora (MPLS). Ten dokáže všechny vaše pobočky připojit do sítě operátora a ten zajišťuje komunikaci mezi nimi, takže nejdete přes Internetové dráty, což může znamenat vyšší spolehlivost. Ale cena takového řešení bývá dost vysoká. A jak napojit Azure? Typicky vybudujete Express Route, díky které se z Azure stane vlastně vaše další pobočka. Tak například zvolíte Express Route v Amsterdamu, kde je konektivita realizována v budově Equinixu, který zajistí propojení Microsoft sítě a sítě vašeho operátora. Pokud zvolíte Premium SKU Express Route, tak jedno takové propojení vám zajistí vstup do Microsoft sítě a odtamtud se doboucháte do kteréhokoli regionu po světě. Má to ale své nevýhody:

  • Pokud uděláte jen Express Route v Amsterdamu, tak veškerý provoz do Azure půjde přes tamní budovu Equinixu. Jistě uznáte, že pro provoz z US není optimální jít po síti operátora do Amsterdamu a odtamtud zpět přes oceán do Azure regionu East US. Obvykle tedy vybudujete druhou Express Route v Americe, aby byl provoz optimálnější, což ale znamená další nemalé náklady. Kontinenty sice vyřešíte, ale i tak není optimální cesta z New Yorku na východním pobřeží do Express route na západním a odtamtud zase změt do regionu East US. Tak přidat pro každé pobřeží další Express Route? Kde se to zastaví? Každá taková optimalizace vede k významným nákladům navíc.
  • Platby operátorovi jsou v těchto scénářích skutečně nemalé
  • Často se nepodaří najít jednoho globálního operátora, s kterým budete spokojeni v Evropě, Americe i Asii. To pak vede na nutnost spravovat různé kontrakty v různých světadílech a řešit jejich propojování a integraci, což zase zvyšuje náklady a potenciálně přináší neoptimální trasy.

Azure Virtual WAN

Jak vám v tomhle může Azure pomoci zejména, když kritické aplikace běžíte tam? Azure Virtual WAN pro vás vytvoří Hub v regionech, ve kterých si řeknete, například West Europe, North Europe, East US a West US. Z pohledu Azure do těchto hubů namíříte svoje VNETy (zatím pouze lokální v daném regionu) a připojíte je do řešení. Nemusíte tedy mít v každém VNETu separátní VPNku ani není nutné vytvořit sdílený VNET a ostatní do něj prohnat přes VNET peering, což vyžaduje složitější konfiguraci. Na hub dále napojíte své pobočky. Praha, Anglie i New York si vytvoří IPSec tunely do všech hubů, pro které se rozhodnete. Na rozdíl od běžné Azure VPN má hub vysokou kapacitu na počet tunelů (aktuálně 1000), takže můžete takto připojit nejen velké lokality, ale i malé kanceláře všude po světě. A teď druhý velký rozdíl oproti běžné Azure VPN - tyto pobočky se mezi sebou vidí. Provoz z nich se sejde v hub v Azure a ten je propojí, můžete tak komunikovat mezi pobočkami.

To ale není vše, teď přijde něco myslím velmi zajímavého. Nefunguje to tak, že všechny pobočky musí Internetem dorazit až do Amsterdamu, kde máte hub. Podobně jako třeba u služby Front Door bude vaše komunikace zakončena na nejbližším edge uzlu Microsoft sítě, kterých je dnes 130 a jeden z nich najdete třeba v Praze. Jinak řečeno vaše pražská pobočka jde přes Internet pouze malý kousek a v Praze se naleje do Microsoft sítě a odtamtud už jde jeho dráty. Využíváte tak rozsáhlou síť Microsoftu a veškerá komunikace jde jen do nejbližšího edge místa. Odtamtud po Microsoft síti pokračuje váš tunel do příslušného hubu třeba do Amsterdamu, nebo pokud máte hub v Americe, tak do Ameriky. Kontinent tedy překročíte využitím Microsoft sítě. Pokud uživatel v Praze přistupuje na server nasazený v regionu West US, tunel v Praze vleze do Microsoft sítě odkud pokračuje až do vámi nasazeného Azure Virtual WAN hubu ve West US. A pokud v San Jose máte pobočku, tak Microsoft tam má i edge lokalitu - váš provoz jde tunelem do West US, tam přesedlá na tunel do vaší pobočky v San Jose, ale protože v něm má Microsoft edge lokalitu, tak až tam půjdete přes Microsoft síť. Mezi edge lokalitou a vaší pobočkou už je to jen malý kousíček, kde váš tunel běží místním Internetem.

Proč vás to může zajímat? Je to velmi efektivní z hlediska nejkratších cest, náklady jsou velmi příjemné a zjednodušuje vám to síťový design v Azure.

Mimochodem v preview už je i podpora pro P2S tunely a také Express Route. Vaše investice do této privátní konektivity tak nejsou zmařené (ostatně pořád dává smysl) a ta se stává součástí celého WAN řešení.

A jakou roli v tom hraje SD-WAN?

Na všechno dosud zmíněné vám stačí na pobočce jakýkoli router/firewall s podporou IPSec. Ale jak to celé spravovat? Najednou je ve hře velké množství krabiček a jejich konfigurace bude jistě velmi náročná. Dost možná chcete i možnost jednoduše nasadit novou pobočku - ideálně poslat tam krabičku, zapojit a ta ať se sama stane součástí celého řešení. Pokud je všechno v Azure, tak by to takhle stačilo, ale jistě máte i řadu aplikací jinde - v datových centrech, na pobočkách. Navíc ne všechno chcete hnát přes SD-WAN, spoustu věcí potřebujete poslat nejkratší cestou do Internetu (pokud už nemáte vyřešeno třeba cloudovou proxy typu ZScaler), protože SaaS služby jako je Office365 jsou na to optimalizované (nebo třeba vaše globální aplikace dostupné odkudkoli přes Azure Front Door). Chtělo by to tedy i mít možnost nastavovat nějaké pokročilejší směrovací politiky - co kam a za jakých okolností posílat. Nebo možná máte v klíčových lokalitách připojení od dvou operátorů. Azure Virtual WAN nabízí HA a vždy vám tak dává dva endpointy, tedy sestavujete typicky dva tunely. Každý tedy může jít přes jiného operátora a kromě vysoké dostupnosti můžete chtít dělat nějaké politiky jak provoz rozvažovat. Například měřit latenci linky a provoz, který je citlivý na latenci (například hlas) přenášet tamtudy, zatímco provoz náročný na pásmo spíše než latenci (nějaké batch přenosy dat) posílat druhou.

Tohle všechno typicky řeší SD-WAN nějakého výrobce, který vám díky kontroleru nabídne jednotné řízení celé planety. Řada těchto dodavatelů je krásně s Azure Virtual WAN integrovaná, aktuálně Barracuda, Check Point, Citrix, Netfoundry, Palo Alto, Riverbed a 128 Technology.

Jste velká globální firma a přemýšlíte jak vyřešit pobočky a napojení do Azure? Podívejte se blíže na Azure Virtual WAN. Příště se podíváme na toto řešení prakticky a zkusíme si něco nastavit.



Cloud-native Palo Alto firewall jako služba pro Azure Virtual WAN Security Networking
Chcete Azure Kubernetes Service, ale máte málo IP adres? Použijte novou Azure CNI overlay. Networking
Federované workload identity v AKS - preview bezpečného řešení pro autentizaci služeb bez hesel Security
Azure Firewall Basic - levnější bráška pro malá prostředí nebo distribuované IT Networking Security
Azure Kubernetes Service v kombinaci s Private Link Service - například pro privátní doručení na Front Door nebo k vašim Azure klientům Networking