Nasazování vysoce dostupných síťových virtuálních zařízení

Tento článek vysvětluje nejběžnější možnosti nasazení sady síťových virtuálních zařízení (NVA) pro zajištění vysoké dostupnosti v Azure. Síťové virtuální zařízení se obvykle používá k řízení toku provozu mezi síťovými segmenty klasifikovanými s různými úrovněmi zabezpečení, například mezi virtuální sítí DE-Zonezed Zone (DMZ) a veřejným internetem.

Existuje řada vzorů návrhu, ve kterých se síťová virtuální zařízení používají ke kontrole provozu mezi různými zónami zabezpečení, například:

• Kontrola výchozího přenosu dat z virtuálních počítačů na internet a zabránění exfiltraci dat
• Kontrola příchozího přenosu dat z internetu do virtuálních počítačů a zabránění útokům
• Pokud chcete filtrovat provoz mezi virtuálními počítači v Azure, abyste zabránili laterálním přesunům ohrožených systémů.
• Pokud chcete filtrovat provoz mezi místními systémy a virtuálními počítači Azure, pokud se považují za patřící do různých úrovní zabezpečení. (Například pokud Azure hostuje DMZ a místní interní aplikace.)

Existuje mnoho příkladů síťových virtuálních zařízení, jako jsou síťové brány firewall, reverzní proxy servery vrstvy 4, koncové body sítě VPN IPsec, webové reverzní proxy servery s funkcemi firewallu webových aplikací, internetové proxy servery, které omezují, ke kterým internetovým stránkám lze přistupovat z Azure, z nástrojů pro vyrovnávání zatížení vrstvy 7 a mnoho dalších. Všechny je možné vložit do návrhu Azure se vzory popsanými v tomto článku. Dokonce i síťová virtuální zařízení Azure, jako je Azure Firewall a Aplikace Azure Gateway, používají návrhy popsané dále v tomto článku. Pochopení těchto možností je důležité jak z hlediska návrhu, tak i při řešení potíží se sítí.

První otázka, na kterou je potřeba odpovědět, je důvod, proč je vyžadována vysoká dostupnost síťových virtuálních zařízení. Důvodem je to, že tato zařízení řídí komunikaci mezi síťovými segmenty. Pokud nejsou dostupné, síťový provoz nemůže tokovat a aplikace přestanou fungovat. Naplánované a nenaplánované výpadky můžou a příležitostně přinesou instance síťového virtuálního zařízení (jako jakýkoli jiný virtuální počítač v Azure nebo jiném cloudu). Instance se přenesou i v případě, že jsou tato síťová virtuální zařízení nakonfigurovaná s Spravované disky Premium tak, aby poskytovala smlouvu SLA s jednou instancí v Azure. Proto vysoce dostupné aplikace budou vyžadovat alespoň druhé síťové virtuální zařízení, které zajistí připojení.

Požadavky: Tento článek předpokládá základní znalosti sítí Azure, nástrojů pro vyrovnávání zatížení Azure a směrování provozu virtuální sítě (UDRS).

Při výběru nejlepší možnosti nasazení síťového virtuálního zařízení do virtuální sítě Azure je nejdůležitějším aspektem, který je potřeba vzít v úvahu, jestli dodavatel síťového virtuálního zařízení ověřil a ověřil tento konkrétní návrh. Dodavatel musí také poskytnout požadovanou konfiguraci síťového virtuálního zařízení, která je potřebná k integraci síťového virtuálního zařízení v Azure. Pokud dodavatel síťového virtuálního zařízení nabízí různé alternativy jako podporované možnosti návrhu síťového virtuálního zařízení, můžou rozhodnutí ovlivnit tyto faktory:

• Doba konvergence: jak dlouho trvá v každém návrhu, aby se provoz od instance síťového virtuálního zařízení, který selhal, ztlumil?
• Podpora topologie: Jaké konfigurace síťového virtuálního zařízení podporují jednotlivé možnosti návrhu? Aktivní/aktivní, aktivní/pohotovostní, clustery síťového virtuálního zařízení se škálováním na více systémů s redundancí n+1?
• Symetrie provozu: Přinutí konkrétní návrh síťového virtuálního zařízení provádět překlad zdrojových síťových adres (SNAT) u paketů, aby se zabránilo asymetrickým směrováním? Nebo je symetrie provozu vynucena jinými prostředky?

Následující části dokumentu popisují nejběžnější architektury používané k integraci síťových virtuálních zařízení do hvězdicové sítě.

Přehled architektur vysoké dostupnosti

Následující architektury popisují nezbytné prostředky a konfiguraci pro vysoce dostupná síťová virtuální zařízení:

Návrh Load Balanceru

Tento návrh používá dva nástroje pro vyrovnávání zatížení Azure k zveřejnění clusteru síťových virtuálních zařízení pro zbytek sítě:

• Interní Load Balancer se používá k přesměrování interního provozu z Azure a místního prostředí do síťových virtuálních zařízení. Tento interní nástroj pro vyrovnávání zatížení je nakonfigurovaný s pravidly portů vysoké dostupnosti, takže každý port TCP/UDP se přesměruje na instance síťového virtuálního zařízení.
• Veřejný Load Balancer zveřejňuje síťová virtuální zařízení na internetu. Vzhledem k tomu, že porty vysoké dostupnosti jsou pro příchozí provoz, musí být každý jednotlivý port TCP/UDP otevřený ve vyhrazeném pravidlu vyrovnávání zatížení.

Následující diagram popisuje posloupnost segmentů směrování, které pakety z internetu na aplikační server v paprskové virtuální síti následují:

Stáhněte si soubor aplikace Visio s touto architekturou.

Mechanismus pro odesílání provozu z paprsků do veřejného internetu prostřednictvím síťových virtuálních zařízení je trasa definovaná uživatelem s 0.0.0.0/0 ip adresou interního nástroje pro vyrovnávání zatížení.

Pro provoz mezi Azure a veřejným internetem bude každý směr toku provozu překračovat jiný azure Load Balancer (příchozí paket prostřednictvím veřejného ALB a výstupní paket prostřednictvím interního ALB). V důsledku toho, pokud je vyžadována symetrie provozu, musí instance síťového virtuálního zařízení provádět překlad zdrojových síťových adres (SNAT), aby přilákaly zpětný provoz a vyhnuly se asymetrii provozu.

Tento návrh lze použít i ke kontrole provozu mezi Azure a místními sítěmi:

Mechanismus odesílání provozu mezi paprsky přes síťová virtuální zařízení je úplně stejný, takže není k dispozici žádný další diagram. V ukázkových diagramech výše, protože paprsk1 neví o rozsahu paprsku 2, 0.0.0.0/0 směr definovaná uživatelem odešle provoz adresovaný paprsku2 internímu nástroji pro vyrovnávání zatížení virtuálního zařízení.

U provozu mezi místními sítěmi a Azure nebo mezi virtuálními počítači Azure zaručuje interní nástroj pro vyrovnávání zatížení Azure symetrii přenosů: pokud oba směry toku provozu procházejícího stejným Nástrojem pro vyrovnávání zatížení Azure, vybere se stejná instance síťového virtuálního zařízení.

Azure Load Balancer má velmi dobrou konvergenční dobu v případě výpadků jednotlivých síťových virtuálních zařízení. Vzhledem k tomu, že sondy stavu se dají odeslat každých 5 sekund a deklarování back-endové instance z provozu trvá 3 neúspěšné testy, obvykle trvá 10 až 15 sekund, než Azure Load Balancer sloučí provoz do jiné instance síťového virtuálního zařízení.

Toto nastavení podporuje konfiguraci aktivní,aktivní i aktivní/pohotovostní. Pro konfiguraci aktivní/pohotovostní sítě však instance síťového virtuálního zařízení musí nabízet port TCP/UDP nebo koncový bod HTTP, který nereaguje na sondy stavu Load Balanceru, pokud instance není v aktivní roli.

Použití nástrojů pro vyrovnávání zatížení L7

Konkrétním případem tohoto návrhu je nahrazení veřejného Load Balanceru Azure nástrojem pro vyrovnávání zatížení vrstvy 7, jako je brána Aplikace Azure (kterou je možné považovat za vlastní síťové virtuální zařízení). V tomto případě síťová virtuální zařízení budou vyžadovat pouze interní nástroj pro vyrovnávání zatížení před nimi, protože provoz ze služby Application Gateway bude zdroj z virtuální sítě a asymetrie provozu není problém.

Síťové virtuální zařízení by mělo přijímat příchozí provoz pro protokoly, které váš nástroj pro vyrovnávání zatížení vrstvy 7 nepodporuje, a potenciálně veškerý příchozí provoz. Další podrobnosti o této konfiguraci při použití brány Azure Firewall jako síťového virtuálního zařízení a brány Aplikace Azure jako webového reverzního proxy serveru vrstvy 7 najdete v tématu Brána firewall a Application Gateway pro virtuální sítě.

Server tras Azure

Azure Route Server je služba, která umožňuje síťovému virtuálnímu zařízení komunikovat s Azure SDN přes protokol BGP (Border Gateway Protocol). Nejen síťová virtuální zařízení zjistí, které předpony IP adres existují ve virtuálních sítích Azure, ale budou moct vkládat trasy do efektivních směrovacích tabulek virtuálních počítačů v Azure.

V diagramu nad každou instancí síťového virtuálního zařízení je partnerský vztah přes protokol BGP s Azure Route Serverem. V podsítích paprsků není nutná žádná směrovací tabulka, protože Azure Route Server bude programovat trasy inzerované síťovými virtuálními zařízeními. Pokud jsou na virtuálních počítačích Azure naprogramované dvě nebo více tras, budou pro každý tok provozu používat ecMP (Equal Cost MultiPathing) jednu z instancí síťového virtuálního zařízení. V důsledku toho je SNAT v tomto návrhu nutností, pokud je požadavkem symetrie provozu.

Tato metoda vložení podporuje jak aktivní,tak aktivní (všechna síťová virtuální zařízení inzerují stejné trasy na Azure Route Server) i aktivní/pohotovostní (jedno síťové virtuální zařízení inzeruje trasy s kratší cestou AS než druhá). Azure Route Server podporuje maximálně 8 sousedství protokolu BGP. Proto pokud používáte cluster s horizontálním navýšením kapacity aktivních síťových virtuálních zařízení, bude tento návrh podporovat maximálně 8 instancí síťového virtuálního zařízení.

Konvergenční doba je v tomto nastavení poměrně rychlá a bude ovlivněna keepalive a holdtime časovači sousedství protokolu BGP. I když má Azure Route Server výchozí keepalive a holdtime časovače (60 sekund a 180 sekund), síťová virtuální zařízení můžou během zřizování sousedství protokolu BGP vyjednat nižší časovače. Nastavení příliš nízkých časovačů může vést k instibility protokolu BGP.

Tento návrh je nejběžnější možností síťových virtuálních zařízení, které potřebují komunikovat se směrováním Azure, například ukončení sítě VPN, které potřebují zjistit předpony nakonfigurované ve virtuálních sítích Azure nebo inzerovat určité trasy přes privátní partnerské vztahy ExpressRoute.

Gateway Load Balancer

Azure Gateway Load Balancer je nový způsob vkládání síťových virtuálních zařízení do cesty k datům, aniž by bylo nutné směrovat provoz pomocí tras definovaných uživatelem. U virtuálních počítačů, které zpřístupňují své úlohy přes Azure Load Balancer nebo veřejnou IP adresu, je možné příchozí a odchozí provoz transparentně přesměrovat na cluster síťových virtuálních zařízení umístěných v jiné virtuální síti. Následující diagram popisuje cestu, kterou pakety sledují pro příchozí provoz z veřejného internetu v případě, že úlohy zpřístupňují aplikaci přes Azure Load Balancer:

Jednou zhlavníchch metodou síťového virtuálního zařízení je to, že pro zajištění symetrie provozu není vyžadován zdrojový překlad síťových adres (SNAT). Další výhodou této možnosti návrhu je to, že stejné síťové virtuální zařízení je možné použít ke kontrole provozu do/z různých virtuálních sítí, čímž dosáhnete víceklientské architektury z hlediska síťového virtuálního zařízení. Mezi virtuální sítí síťového virtuálního zařízení a virtuálními sítěmi úloh není vyžadován žádný partnerský vztah virtuálních sítí virtuálních sítí definovaných uživatelem, což výrazně zjednodušuje konfiguraci.

Injektáž služby pomocí Nástroje pro vyrovnávání zatížení brány se dá použít pro příchozí toky, které dorazí na veřejný Load Balancer Azure (a jejich návratový provoz), a také pro odchozí toky pocházející z Azure. Provoz mezi virtuálními počítači Azure – západ mezi virtuálními počítači Azure nemůže využít Load Balancer brány pro injektáž síťového virtuálního zařízení.

V clusteru síťového virtuálního zařízení se sondy kontroly stavu Azure Load Balanceru použijí k detekci jednotlivých selhání instancí síťového virtuálního zařízení a dosažení velmi rychlého času konvergence (10–15 sekund).

Změna uživatelem definovaného uživatelem PIP

Myšlenka za tímto návrhem spočívá v nastavení, které by se vyžadovalo bez redundance síťového virtuálního zařízení, a upravilo se v případě výpadku síťového virtuálního zařízení. Následující diagram znázorňuje, jak je veřejná IP adresa Azure přidružená k aktivnímu síťovému virtuálnímu zařízení (NVA1) a trasy definované uživatelem v paprskech mají jako další segment směrování10.0.0.37 aktivní IP adresu síťového virtuálního zařízení.

Pokud se aktivní síťové virtuální zařízení stane nedostupným, pohotovostní síťové virtuální zařízení zavolá rozhraní Azure API, aby znovu namapoval veřejnou IP adresu a trasy definované uživatelem paprsku na sebe (nebo také přesunulo privátní IP adresu). Tato volání rozhraní API mohou trvat několik minut, což je důvod, proč tento návrh nabízí nejhorší konvergenci všech možností v tomto dokumentu.

Dalším omezením tohoto návrhu je, že se podporují pouze konfigurace aktivní/pohotovostní, což může vést k problémům se škálovatelností: pokud potřebujete zvýšit šířku pásma podporovanou síťovými virtuálními zařízeními, jedinou možností tohoto návrhu je vertikální navýšení kapacity obou instancí.

Jednou z výhod tohoto návrhu je, že k zajištění symetrie provozu není potřeba žádný zdrojový překlad síťových adres (SNAT), protože v daném okamžiku je aktivní jenom jedno síťové virtuální zařízení.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

• Keith Mayer | Hlavní architekt cloudového řešení
• Telmo Sampaio | Principal Service Engineering Manager

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

• Zjistěte, jak implementovat zabezpečenou hybridní síť pomocí služby Azure Firewall.
• Hraniční sítě – Architektura přechodu na cloud
• Cloud DMZ – Architektura přechodu na cloud