Návrh zotavení po havárii

  • Článek

Virtual WAN umožňuje agregovat, připojovat se, centrálně spravovat a zabezpečit všechna globální nasazení. Globální nasazení můžou zahrnovat libovolnou kombinaci různých větví, bodu přítomnosti,privátních uživatelů, poboček, virtuálních sítí Azure a dalších nasazení ve více cloudech. K připojení různých lokalit k virtuálnímu centru můžete použít SD-WAN, site-to-site VPN, vpn typu point-to-site a ExpressRoute. Pokud máte více virtuálních center, budou všechna centra připojená v plné síti ve standardním nasazení Virtual WAN.

V tomto článku se podíváme na to, jak navrhovat různé typy možností připojení k síti jako službě, které Virtual WAN podporují zotavení po havárii.

Možnosti připojení k síti jako službě Virtual WAN

Virtual WAN podporuje následující možnosti připojení k back-endu:

  • Připojení vzdáleného uživatele
  • Branch/Office/SD-WAN/Site-to-site VPN
  • Privátní připojení (privátní partnerský vztah ExpressRoute)

Pro každou z těchto možností připojení Virtual WAN nasadí samostatnou sadu instancí brány v rámci virtuálního centra.

Virtual WAN je ze své podstaty navržená tak, aby nabízela vysoce dostupné řešení agregace sítě na úrovni operátora. Pro zajištění vysoké dostupnosti Virtual WAN vytvoří instanci několika instancí, když je každý z těchto různých typů bran nasazený v centru Virtual WAN. Další informace o vysoké dostupnosti ExpressRoute najdete v tématu Návrh vysoké dostupnosti pomocí ExpressRoute.

U brány VPN typu point-to-site jsou minimální počet nasazených instancí dvě. Pomocí brány VPN typu point-to-site zvolíte agregovanou propustnost bran typu point-to-site a automaticky se pro vás zřídí více instancí. Agregovanou kapacitu zvolíte podle počtu klientů nebo uživatelů, které chcete připojit k virtuálnímu centru. Z pohledu připojení klienta jsou instance brány VPN typu point-to-site skryté za plně kvalifikovaným názvem domény brány.

Pro bránu VPN typu site-to-site jsou ve virtuálním centru nasazené dvě instance brány. Každá instance brány je nasazená s vlastní sadou veřejných a privátních IP adres. Následující snímek obrazovky ukazuje IP adresy přidružené ke dvěma instancím ukázkové konfigurace brány VPN typu site-to-site. Jinými slovy, tyto dvě instance poskytují dva nezávislé koncové body tunelu pro navázání připojení site-to-site VPN z vašich větví. Pokud chcete maximalizovat vysokou dostupnost, přečtěte si téma Výběr cesty Azure napříč několika odkazy poskytovatele internetových služeb.

Snímek obrazovky znázorňující ukázkovou konfiguraci brány site-to-site V P N

Maximalizace vysoké dostupnosti síťové architektury je klíčovým prvním krokem pro provozní kontinuitu a zotavení po havárii (BCDR). Ve zbývající části tohoto článku, jak jsme uvedli výše, přejdeme nad rámec vysoké dostupnosti a probereme, jak vytvořit architekturu sítě Virtual WAN připojení pro BCDR.

Potřeba návrhu zotavení po havárii

Katastrofa může udeřit kdykoli a kdekoli. K havárii může dojít v oblastech nebo síti poskytovatele cloudu, v rámci sítě poskytovatele služeb nebo v místní síti. Regionální dopad cloudové nebo síťové služby způsobené určitými faktory, jako jsou přírodní kalamita, lidské chyby, válka, terorismus nebo chybná konfigurace, je těžké vyloučit. Pro zajištění kontinuity důležitých podnikových aplikací proto potřebujete návrh zotavení po havárii. V případě komplexního návrhu zotavení po havárii musíte identifikovat všechny závislosti, které by mohly selhat v cestě komunikace mezi koncovými body, a vytvořit nepřekrývající se redundanci pro každou závislost.

Bez ohledu na to, jestli spouštíte důležité aplikace v oblasti Azure, v místním prostředí nebo kdekoli jinde, můžete jako lokalitu převzetí služeb při selhání použít jinou oblast Azure. Následující články se zabývají zotavením po havárii z aplikací a perspektivami přístupu front-endu:

Problémy s používáním redundantního připojení

Když propojíte stejnou sadu sítí pomocí více než jednoho připojení, zavedete mezi sítěmi paralelní cesty. Paralelní cesty, pokud nejsou správně navrženy, můžou vést k asymetrickým směrováním. Pokud máte v cestě stavové entity (například NAT nebo firewall), může asymetrické směrování blokovat tok provozu. Při privátním připojení obvykle nebudete mít nebo narazíte na stavové entity, jako jsou překlad adres (NAT) nebo brány firewall. Proto asymetrické směrování přes privátní připojení nemusí nutně blokovat tok provozu.

Pokud ale vyrovnáte zatížení provozu napříč geograficky redundantními paralelními cestami, dojde k nekonzistentnímu výkonu sítě kvůli rozdílu ve fyzické cestě paralelních připojení. V rámci návrhu zotavení po havárii proto musíme vzít v úvahu výkon síťového provozu ve stabilním stavu (stav bez selhání) i ve stavu selhání.

Přístup k redundanci sítě

Většina služeb SD-WAN (spravovaných řešení nebo jiných) poskytuje síťové připojení prostřednictvím více typů přenosu (například internetové širokopásmové připojení, MPLS, LTE). Chcete-li chránit před selháními přenosové sítě, zvolte připojení přes více než jednu přenosovou síť. V případě scénáře domácího uživatele můžete zvážit použití mobilní sítě jako zálohy pro širokopásmové připojení k síti.

Pokud síťové připojení přes jiný typ přenosu není možné, zvolte síťové připojení přes více než jednoho poskytovatele služeb. Pokud se připojujete přes více než jednoho poskytovatele služeb, ujistěte se, že poskytovatelé služeb udržují nepřekrývající se nezávislé přístupové sítě.

Důležité informace o připojení vzdáleného uživatele

Připojení vzdáleného uživatele se naváže pomocí sítě VPN typu point-to-site mezi koncovým zařízením a sítí. Po selhání sítě se koncové zařízení ukončí a pokusí se znovu stabilizovat tunel VPN. Proto by se u sítě VPN typu point-to-site měl návrh zotavení po havárii zaměřit na minimalizaci doby obnovení po selhání. Následující redundance sítě by pomohla minimalizovat dobu obnovení. V závislosti na tom, jak důležitá jsou připojení, můžete zvolit některé nebo všechny tyto možnosti.

  • Přístup k redundanci sítě (popsáno výše)
  • Správa redundantního virtuálního centra pro ukončení sítě VPN typu point-to-site Pokud máte více virtuálních center s bránami typu point-to-site, poskytuje virtuální síť WAN globální profil se seznamem všech koncových bodů typu point-to-site. S globálním profilem se vaše koncová zařízení můžou připojit k nejbližšímu dostupnému virtuálnímu centru, které nabízí nejlepší výkon sítě. Pokud jsou všechna nasazení Azure v jedné oblasti a koncová zařízení, která se připojují, jsou v těsné blízkosti oblasti, můžete v této oblasti mít redundantní virtuální centra. Pokud jsou vaše nasazení a koncová zařízení rozložená do více oblastí, můžete nasadit virtuální centrum s bránou typu point-to-site v každé z vybraných oblastí. Virtual WAN má integrovaný traffic manager, který automaticky vybere nejlepší centrum pro připojení vzdálených uživatelů.

Následující diagram znázorňuje koncept správy redundantního virtuálního centra pomocí příslušné brány typu point-to-site v rámci oblasti.

Diagram agregace point-to-site s více rozbočovači

Ve výše uvedeném diagramu plné zelené čáry znázorňují primární připojení VPN typu point-to-site a žluté tečkované čáry představují záložní připojení. Globální profil typu point-to-site virtuální sítě WAN vybírá primární a záložní připojení na základě výkonu sítě. Další informace o globálním profilu najdete v tématu Stažení globálního profilu pro klienty VPN uživatele .

Důležité informace o síti VPN typu Site-to-Site

Podívejme se na příklad připojení site-to-site VPN zobrazený v následujícím diagramu pro naši diskuzi. Pokud chcete navázat připojení site-to-site VPN s vysoce dostupnými tunely aktivní-aktivní, přečtěte si kurz: Vytvoření připojení site-to-site pomocí Azure Virtual WAN.

Diagram připojení místní větve k virtuální síti WAN přes site-to-site V P N

Poznámka

Pro snadné pochopení konceptů probíraných v části se neopakujeme v diskuzi o funkci vysoké dostupnosti brány VPN typu site-to-site, která umožňuje vytvořit dva tunely do dvou různých koncových bodů pro každé propojení VPN, které nakonfigurujete. Při nasazování kterékoli z navrhovaných architektur v části však nezapomeňte nakonfigurovat dva tunely pro každé propojení, které vytvoříte.

Pokud chcete chránit před selháním zařízení CPE (Customer Premises Equipment) sítě VPN v lokalitě pobočky, můžete nakonfigurovat paralelní připojení VPN k bráně VPN z paralelních zařízení CPE v lokalitě pobočky. Pokud chcete chránit před selháním sítě poskytovatele služeb na poslední míli na pobočku, můžete nakonfigurovat různá propojení VPN přes jinou síť poskytovatele služeb. Následující diagram znázorňuje několik propojení VPN pocházejících ze dvou různých cpe lokality větve končící na stejné bráně VPN.

Diagram redundantních připojení site-to-site V P N k lokalitě větve

Z brány VPN virtuálního centra můžete nakonfigurovat až čtyři odkazy na lokalitu větve. Při konfiguraci propojení na lokalitu větve můžete identifikovat poskytovatele služby a rychlost propustnosti přidruženou k propojení. Při konfiguraci paralelních propojení mezi lokalitou větve a virtuálním centrem brána VPN ve výchozím nastavení vyrovnává zatížení provozu napříč paralelními propojeními. Vyrovnávání zatížení provozu by bylo podle Equal-Cost více cest (ECMP) na základě jednotlivých toků.

Topologie s více propojeními chrání před selháním zařízení CPE a selháním sítě poskytovatele služeb v umístění místní větve. K ochraně před výpadky brány VPN-gateway virtuálního centra by navíc pomohla topologie s více rozbočovači. Následující diagram znázorňuje topologii, ve které se v rámci Virtual WAN instance v rámci oblasti konfiguruje více virtuálních center:

Diagram připojení site-to-site s více rozbočovači V P N k lokalitě větve

Vzhledem k tomu, že latence připojení mezi centry v rámci oblasti Azure je ve výše uvedené topologii nevýznamná, můžete použít všechna připojení site-to-site VPN mezi místním a dvěma virtuálními rozbočovači v aktivním stavu, a to rozložením paprskových virtuálních sítí mezi rozbočovače. V topologii by provoz mezi místní a paprskovou virtuální sítí ve výchozím nastavení procházel přímo přes virtuální centrum, ke kterému je paprsková virtuální síť připojena během stabilního stavu, a jako zálohu se používalo jiné virtuální centrum pouze v případě selhání. Provoz by procházel přímo připojeným centrem ve stabilním stavu, protože trasy protokolu BGP inzerované přímo připojeným centrem by měly ve srovnání s centrem zálohování kratší cestu AS.

Topologie s více rozbočovači by chránila a poskytovala provozní kontinuitu před většinou scénářů selhání. Pokud ale katastrofické selhání zabere celou oblast Azure, potřebujete topologii s více oblastmi, aby se selhání vydrželo.

Vícenásobná topologie více oblastí chrání i před katastrofálním selháním celé oblasti, a to kromě ochrany, které nabízí topologie s více rozbočovači, kterou jsme probrali dříve. Následující diagram znázorňuje topologii s více oblastmi. Virtuální centra v jiné oblasti je možné nakonfigurovat ve stejné instanci Virtual WAN.

Diagram připojení site-to-site mezi více oblastmi V P N k lokalitě větve

Z hlediska dopravního inženýrství je potřeba vzít v úvahu jeden podstatný rozdíl mezi redundantními rozbočovači v rámci oblasti a mezi centrem zálohování v jiné oblasti. Rozdíl je latence způsobená fyzickou vzdáleností mezi primární a sekundární oblastí. Proto můžete chtít nasadit prostředky služby stabilního stavu v oblasti, která je nejblíže vaší větvi nebo koncovým uživatelům, a použít vzdálenou oblast čistě pro zálohování.

Pokud jsou vaše umístění místních poboček rozložená do dvou nebo více oblastí Azure, bude topologie s více oblastmi efektivnější při rozložení zatížení a při získávání lepšího síťového prostředí během stabilního stavu. Následující diagram znázorňuje topologii s více oblastmi s větvemi v různých oblastech. V takovém scénáři by topologie navíc poskytovala efektivní zotavení po havárii provozní kontinuity (BCDR).

Diagram připojení site-to-site mezi více oblastmi V P N k lokalitám s více větvemi

Důležité informace o ExpressRoute

Aspekty zotavení po havárii pro privátní partnerský vztah ExpressRoute jsou popsány v tématu Návrh pro zotavení po havárii s využitím privátního partnerského vztahu ExpressRoute. Jak je uvedeno v článku, koncepty popsané v tomto článku platí také pro brány ExpressRoute vytvořené v rámci virtuálního centra. Použití redundantního virtuálního centra v rámci oblasti, jak je znázorněno v následujícím diagramu, je jediným doporučeným vylepšením topologie pro aspekty místní sítě s malými až středními.

Diagram připojení Expresss Route s více rozbočovači

Ve výše uvedeném diagramu se ExpressRoute 2 ukončí na samostatné bráně ExpressRoute v rámci druhého virtuálního centra v rámci dané oblasti.

Další kroky

V tomto článku jsme probrali Virtual WAN návrh zotavení po havárii. Následující články se zabývají zotavením po havárii z aplikací a perspektivami přístupu front-endu:

Pokud chcete vytvořit připojení typu point-to-site k Virtual WAN, projděte si kurz: Vytvoření připojení VPN uživatele pomocí Azure Virtual WAN. Pokud chcete vytvořit připojení typu site-to-site k Virtual WAN přečtěte si kurz: Vytvoření připojení typu site-to-site pomocí Azure Virtual WAN. Pokud chcete přidružit okruh ExpressRoute k Virtual WAN, přečtěte si kurz: Vytvoření přidružení ExpressRoute pomocí Azure Virtual WAN.