Sdílet prostřednictvím


Návrh zotavení po havárii

Virtual WAN umožňuje agregovat, připojovat se, centrálně spravovat a zabezpečit všechna globální nasazení. Vaše globální nasazení můžou zahrnovat libovolnou kombinaci různých větví, point-of-presence (PoP), soukromých uživatelů, poboček, virtuálních sítí Azure a dalších nasazení s více cloudy. K připojení různých lokalit k virtuálnímu centru můžete použít SD-WAN, vpn typu site-to-site, vpn typu point-to-site a ExpressRoute. Pokud máte více virtuálních center, budou všechna centra připojena 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í typu síť jako služba, které Virtual WAN podporuje pro zotavení po havárii.

Možnosti připojení typu Síť jako služba virtual WAN

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

  • Připojení vzdáleného uživatele
  • Pobočka/Pobočka/SD-WAN/Vpn typu Site-to-Site
  • Privátní připojení (privátní partnerský vztah ExpressRoute)

Pro každou z těchto možností připojení nasadí Virtual WAN 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 služba Virtual WAN vytvoří instanci více instancí, když se každý z těchto různých typů bran nasadí v centru Virtual WAN. Další informace o vysoké dostupnosti ExpressRoute najdete v tématu Návrh pro zajištění vysoké dostupnosti pomocí ExpressRoute.

S bránou VPN typu point-to-site je minimální počet nasazených instancí dva. U brány VPN typu point-to-site zvolíte agregovanou kapacitu propustnosti bran typu point-to-site a pro vás se automaticky 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 hlediska připojení klienta jsou instance brány VPN typu point-to-site skryté za plně kvalifikovaným názvem domény (FQDN) brány.

Pro bránu VPN typu site-to-site se v rámci virtuálního centra nasadí dvě instance brány. Každá instance brány se nasadí s vlastní sadou veřejných a privátních IP adres. Dvě instance poskytují dva nezávislé koncové body tunelu pro navázání připojení VPN typu site-to-site z vašich větví. Pokud chcete maximalizovat vysokou dostupnost, podívejte se na výběr cesty Azure napříč několika odkazy isP.

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 dříve, se podíváme nad rámec vysoké dostupnosti a probereme, jak pro BCDR vytvořit architekturu sítě připojení Virtual WAN.

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

Havárie může kdykoliv udeřit kdekoli. K havárii může dojít v oblastech nebo síti poskytovatele cloudu, v síti poskytovatele služeb nebo v rámci místní sítě. Regionální dopad cloudové nebo síťové služby z důvodu určitých faktorů, jako jsou přírodní katastrofy, lidské chyby, válka, terorismus, chybná konfigurace, je obtížné vyloučit. Proto pro kontinuitu důležitých podnikových aplikací musíte mít návrh zotavení po havárii. V případě komplexního návrhu zotavení po havárii je potřeba identifikovat všechny závislosti, které by mohly selhat v ucelené komunikační cestě, a vytvořit nepřekrývající se redundanci pro každou závislost.

Bez ohledu na to, jestli spouštíte klíčové aplikace v oblasti Azure, místně 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 z hlediska 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, firewall), může asymetrické směrování blokovat tok provozu. U privátního připojení se obvykle nebudete moct setkat se stavovými entitami, jako jsou překlad adres (NAT) nebo brány firewall. Asymetrické směrování přes privátní připojení proto nemusí nutně blokovat tok provozu.

Pokud ale vyrovnáváte zatížení provozu mezi 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í. Proto musíme zvážit výkon síťového provozu jak během stabilního stavu (stavu bez selhání), tak i stavu selhání jako součást návrhu zotavení po havárii.

Přístup k redundanci sítě

Většina služeb SD-WAN (spravovaná řešení nebo jinak) poskytuje síťové připojení prostřednictvím více typů přenosu (například širokopásmové připojení k internetu, MPLS, LTE). Pokud chcete zajistit ochranu před selháním přenosové sítě, zvolte připojení přes více než jednu přenosovou síť. Pro scénář 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 připojení k síti 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 prostřednictvím více poskytovatelů 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ých uživatelů

Připojení vzdáleného uživatele se vytváří pomocí sítě VPN typu point-to-site mezi koncovým zařízením a sítí. Po selhání sítě by koncové zařízení zahodilo a pokusilo se znovu vytvořit tunel VPN. V případě sítě VPN typu point-to-site by proto měl být návrh zotavení po havárii zaměřen 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 rozbočovače 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 vaše nasazení Azure v jedné oblasti a koncová zařízení, která se připojují, jsou v těsné blízkosti oblasti, můžete mít redundantní virtuální centra v rámci oblasti. Pokud jsou vaše nasazení a koncová zařízení rozložená do několika oblastí, můžete nasadit virtuální centrum s bránou point-to-site v každé z vybraných oblastí. Virtual WAN má integrovaný traffic manager, který vybere nejlepší centrum pro připojení vzdálených uživatelů automaticky.

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

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

Ve výše uvedeném diagramu zobrazují plné zelené čáry primární připojení VPN typu point-to-site a tečkované žluté čáry zobrazují stand-by back-up připojení. Globální profil sítě WAN typu point-to-site vybere primární a zálohovaná 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živatelů.

Aspekty sítě VPN typu Site-to-Site

Podívejme se na příklad připojení VPN typu site-to-site, které je znázorněno v následujícím diagramu pro naši diskuzi. Pokud chcete vytvořit připojení VPN typu site-to-site s vysoce dostupnými tunely typu aktivní-aktivní, přečtěte si kurz : Vytvoření připojení typu Site-to-Site pomocí služby Azure Virtual WAN.

Diagram připojení místní větve k virtual wanu přes site-to-site V P N

Poznámka:

Pro snadné pochopení konceptů probíraných v této části neopakujeme diskuzi o funkci vysoké dostupnosti brány VPN typu site-to-site, která umožňuje vytvořit dva tunely na dva různé koncové body pro každé nakonfigurované propojení VPN. Při nasazování některé z navrhovaných architektur v této části ale nezapomeňte nakonfigurovat dva tunely pro každý odkaz, který vytvoříte.

Pokud chcete chránit před selháním zařízení CPE (VPN Customer Premises Equipment) ve větvi, můžete nakonfigurovat paralelní propojení VPN s bránou VPN z paralelních zařízení CPE na pobočkové lokalitě. Kromě ochrany před selháním sítě poskytovatele služeb na poslední míli do pobočky 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 procesorů lokality větve, která končí na stejné bráně VPN.

Diagram redundantních připojení site-to-site V P N k pobočkové lokalitě

Z brány VPN virtuálního centra můžete nakonfigurovat až čtyři odkazy na pobočkovou lokalitu. Při konfiguraci propojení s pobočkovou lokalitou můžete identifikovat poskytovatele služeb a rychlost propustnosti přidruženou k propojení. Když nakonfigurujete paralelní propojení mezi pobočkou a virtuálním centrem, brána VPN ve výchozím nastavení vyrovnává zatížení provozu mezi paralelními propojeními. Vyrovnávání zatížení provozu by bylo podle ecmp (Equal-Cost Multi-Path) na základě toku.

Topologie s více propojeními chrání před selháními zařízení CPE a selháním sítě poskytovatele služeb v místním umístění pobočky. Kromě toho by vám pomohla ochrana před případným výpadkem virtuální brány VPN-gateway s více rozbočovači. Následující diagram znázorňuje topologii, ve které je v instanci virtual WAN v rámci oblasti nakonfigurováno více virtuálních center:

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

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

Topologie multi-hub multi-link by chránila a poskytovala kontinuitu podnikových procesů proti většině scénářů selhání. Pokud ale katastrofické selhání převezme celou oblast Azure, potřebujete topologii s více oblastmi s více oblastmi, abyste mohli odolat selhání.

Topologie multi-link s více oblastmi chrání před dokonce i katastrofickým selháním celé oblasti, a to kromě ochrany, které nabízí topologie multi-hub multi-link, 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 V P N ve více oblastech k pobočkové lokalitě

Z hlediska technického provozu je potřeba vzít v úvahu jeden podstatný rozdíl mezi redundantními rozbočovači v rámci oblasti v porovnání s centrem zálohování v jiné oblasti. Rozdíl je latence vyplývající z fyzické vzdálenosti mezi primárními a sekundárními oblastmi. 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 místní pobočky rozmístěné kolem dvou nebo více oblastí Azure, topologie s více oblastmi by byla efektivnější při šíření zatížení a získání lepšího síťového prostředí během stabilního stavu. Následující diagram znázorňuje topologii více oblastí 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 více oblastí připojení site-to-site V P N k více větvím lokalit

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 pomocí privátního partnerského vztahu ExpressRoute. Jak je uvedeno v článku, koncepty popsané v tomto článku platí stejně pro brány ExpressRoute vytvořené ve virtuálním centru. 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 vylepšením topologie doporučené pro aspekty místní sítě small až medium.

Diagram připojení ExpressRoute ve více centrech

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 oblasti.

Další kroky

V tomto článku jsme se zabývali návrhem zotavení po havárii služby Virtual WAN. Následující články se zabývají zotavením po havárii z aplikací a z hlediska přístupu front-endu:

Pokud chcete vytvořit připojení typu point-to-site ke službě Virtual WAN, přečtěte si kurz : Vytvoření připojení VPN uživatele pomocí služby Azure Virtual WAN. Postup vytvoření připojení typu site-to-site ke službě Virtual WAN najdete v tématu Kurz: Vytvoření připojení typu Site-to-Site pomocí služby Azure Virtual WAN. Pokud chcete přidružit okruh ExpressRoute ke službě Virtual WAN, přečtěte si kurz : Vytvoření přidružení ExpressRoute pomocí služby Azure Virtual WAN.