Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
ExpressRoute je navržený tak, aby poskytoval vysokou dostupnost pro privátní síťové připojení na úrovni operátora k prostředkům Microsoft. Jinými slovy, v cestě ExpressRoute v síti Microsoftu neexistuje jediný bod selhání. Aspekty návrhu pro maximalizaci dostupnosti okruhu ExpressRoute najdete v tématu Návrh pro zajištění vysoké dostupnosti pomocí ExpressRoute a Well-Architected Frameworku.
Vezmeme-li v úvahu známé Murphyho rčení (když se něco může pokazit, pokazí se to), tento článek se zaměřuje na řešení pro případy selhání, která jeden okruh ExpressRoute nedokáže pokrýt. Zkoumá aspekty síťové architektury pro vytváření robustního připojení back-endové sítě pro zotavení po havárii s využitím geograficky redundantních okruhů ExpressRoute.
Poznámka:
Koncepty popsané v tomto článku platí stejně, když se okruh ExpressRoute vytvoří ve službě Virtual WAN nebo mimo něj.
Potřeba řešení redundantního připojení
U peeringových umístění ExpressRoute nebo celé regionální služby může dojít ke zhoršení. Výpadek služeb v celé oblasti může zahrnovat přírodní kalamitu. Naplánujte zotavení po havárii pro provozní kontinuitu a klíčové aplikace.
Poznámka:
Pokud potřebujete implementovat návrh zotavení po havárii v časově citlivé situaci, jako je zachování provozní kontinuity během přírodní katastrofy, měli byste vzít v úvahu následující faktory:
- Tento dokument obsahuje pokyny k implementaci robustního návrhu obnovy po havárii pro více ExpressRoute okruhů nakonfigurovaných prostřednictvím různých peeringových lokalit. Tento scénář předpokládá, že máte dostatek času a prostředků pro nastavení okruhů ExpressRoute.
- Pokud potřebujete rychle nakonfigurovat návrh zotavení po havárii pro jeden okruh ExpressRoute, který není geograficky redundantní, můžete použít následující alternativy:
- Použijte VPN typu site-to-site jako zálohu pro provoz privátního peeringu.
- Použijte připojení k internetu jako zálohu pro peeringový provoz Microsoftu.
Bez ohledu na to, jestli spouštíte klíčové aplikace v oblasti Azure nebo 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í obnovením po havárii z pohledu aplikací a přístupu k front-endu:
Pokud se spoléháte na připojení ExpressRoute mezi vaší místní sítí a Microsoftem, musíte zvážit následující kroky, abyste mohli naplánovat zotavení po havárii přes ExpressRoute:
- použití geograficky redundantních okruhů ExpressRoute
- používání různých sítí poskytovatelů služeb pro různé okruhy ExpressRoute
- návrh každého okruhu ExpressRoute pro zajištění vysoké dostupnosti
- ukončení různých okruhů ExpressRoute na různých místech v síti zákazníka
- používání bran virtuální sítě ExpressRoute pracujících se zónou dostupnosti
Problémy s používáním několika okruhů ExpressRoute
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 stavové entity, například NAT nebo firewall v cestě, asymetrické směrování může blokovat tok provozu. Obvykle na cestě privátního peeringu ExpressRoute nenarazíte na stavové entity, jako je NAT nebo firewall. Asymetrické směrování přes privátní propojení ExpressRoute proto nemusí nutně blokovat tok provozu.
Pokud ale vyrovnáváte zatížení provozu napříč geograficky redundantními paralelními cestami bez ohledu na to, jestli máte stavové entity, nebo ne, došlo by k nekonzistentnímu výkonu sítě. Tyto geograficky redundantní paralelní cesty mohou být přes stejnou oblast nebo různé oblasti, které najdete na stránce poskytovatelů podle polohy.
Redundance okruhů ExpressRoute ve stejné metropoli
Mnoho metra má dvě místa ExpressRoute. Příkladem může být Amsterdam a Amsterdam2. Při navrhování redundance můžete vytvořit dvě paralelní cesty k Azure s oběma umístěními ve stejném metro. Tuto úlohu provedete se stejným poskytovatelem nebo se rozhodnete pracovat s jiným poskytovatelem služeb, abyste zlepšili odolnost. Další výhodou tohoto návrhu je, že při selhání aplikace zůstane end-to-end latence mezi místními aplikacemi a Microsoftem přibližně stejná. Pokud ale dojde k přírodní katastrofě, jako je zemětřesení, připojení obou cest už nemusí být dostupné.
Redundance okruhů ExpressRoute v různých metropolích
Při použití různých metra pro redundanci byste měli vybrat sekundární umístění ve stejné geografické politické oblasti. Pokud chcete zvolit umístění mimo geopolitickou oblast, musíte použít tarif Premium pro oba okruhy v paralelních trasách. Výhodou této konfigurace je, že pravděpodobnost, že přírodní katastrofa způsobí výpadek obou spojů, je nižší, ale na úkor zvýšené latence v celé komunikaci.
Poznámka:
Povolení BFD v okruzích ExpressRoute pomůže s rychlejší detekcí selhání spojení mezi zařízeními Microsoft Enterprise Edge (MSEE) a směrovači na okraji sítě zákazníka nebo partnera. Celkové přepnutí na záložní systém a přepnutí na záložní lokalitu však může za určitých podmínek selhání trvat až 180 sekund a během této doby můžete zaznamenat zvýšenou latenci nebo zhoršení výkonu.
Následující části řeší problémy, se kterými se můžete setkat při konfiguraci geograficky redundantních cest.
Důležité informace o malé až střední místní síti
Představte si ukázkovou síť znázorněnou v následujícím diagramu. V tomto příkladu je mezi místním pracovištěm společnosti Contoso a virtuální sítí Contoso v oblasti Azure zřízeno geograficky redundantní připojení ExpressRoute. V diagramu plná modrá čára označuje upřednostňovanou cestu (přes ExpressRoute 1) a tečkovaná čára představuje samostatnou cestu (přes ExpressRoute 2).
Pokud ve výchozím nastavení inzerujete trasy stejně přes všechny cesty ExpressRoute, vyrovnává zatížení Azure místní provoz směřující přes maximálně 4 okruhy ExpressRoute pomocí směrování ECMP (Equal-Cost Multi-Path).
U geograficky redundantních okruhů ExpressRoute ale musíte zvážit různé síťové výkony napříč různými síťovými cestami, zejména latence sítě. Pokud chcete dosáhnout konzistentnějšího výkonu sítě během normálního provozu, můžete chtít preferovat okruh ExpressRoute, který nabízí minimální latenci.
Můžete ovlivnit Azure, aby preferuje jeden okruh ExpressRoute před druhým pomocí jedné z následujících technik (uvedených v pořadí efektivity):
- inzerce konkrétnější trasy přes upřednostňovaný okruh ExpressRoute ve srovnání s jinými okruhy ExpressRoute
- Konfigurace vyšší priority připojení na spojení, které propojuje virtuální síť s upřednostňovaným okruhem ExpressRoute.
- inzerce tras nad méně upřednostňovaným okruhem ExpressRoute s delší cestou AS (předem řazená cesta AS)
Konkrétnější trasa
Následující diagram znázorňuje vliv na výběr cesty ExpressRoute pomocí konkrétnější inzerování tras. V ilustrovaném příkladu se místní rozsah IP adres společnosti Contoso /24 inzeruje jako dva rozsahy adres /25 přes upřednostňovanou cestu (ExpressRoute 1) a jako /24 prostřednictvím samostatné cesty (ExpressRoute 2).
Vzhledem k tomu, že je /25 konkrétnější než /24, Azure odešle provoz směrovaný na 10.1.11.0/24 přes ExpressRoute 1 v normálním stavu. Pokud obě připojení ExpressRoute 1 přestanou fungovat, virtuální síť by viděla oznámení o směrování 10.1.11.0/24 pouze přes ExpressRoute 2; a proto se v tomto stavu selhání používá záložní okruh.
Váha spojení
Následující snímek obrazovky znázorňuje konfiguraci váhy připojení ExpressRoute přes Azure Portal.
Následující diagram znázorňuje vliv na výběr cesty ExpressRoute pomocí váhy připojení. Výchozí váha připojení je 0. V následujícím příkladu je váha připojení pro ExpressRoute 1 nakonfigurovaná jako 100. Když virtuální síť obdrží předponu trasy inzerovanou prostřednictvím více než jednoho okruhu ExpressRoute, virtuální síť upřednostňuje připojení s nejvyšší váhou.
Pokud obě připojení ExpressRoute 1 přestanou fungovat, virtuální síť by viděla oznámení o směrování 10.1.11.0/24 pouze přes ExpressRoute 2; a proto se v tomto stavu selhání používá záložní okruh.
Předpřipravená cesta AS
Následující diagram znázorňuje vliv na výběr cesty ExpressRoute pomocí předběžné cesty AS. V diagramu inzerování trasy přes ExpressRoute 1 označuje výchozí chování protokolu eBGP. V inzerované trasě přes ExpressRoute 2 je ASN místní sítě navíc přidán na AS cestě trasy. Pokud je stejná trasa přijata prostřednictvím více okruhů ExpressRoute, v rámci procesu výběru trasy eBGP by virtuální síť preferovala trasu s nejkratší cestou AS.
Pokud obě připojení ExpressRoute 1 nefunguje, virtuální síť by viděla inzerování tras 10.1.11.0/24 pouze přes ExpressRoute 2. V důsledku toho by delší cesta AS byla irelevantní. Proto by se v tomto stavu selhání používal pohotovostní okruh.
Při použití kterékoliv z technik, pokud přimějete Azure preferovat jednu z vašich ExpressRoute před ostatními, musíte také zajistit, aby podniková síť upřednostňovala stejnou cestu ExpressRoute pro provoz směřující do Azure, aby nedocházelo k asymetrickým tokům. Hodnota místní předvolby se obvykle používá k ovlivnění místní sítě, aby upřednostňovala jeden okruh ExpressRoute před ostatními. Místní předvolba je interní metrika protokolu BGP (iBGP). Preferuje se trasa protokolu BGP s nejvyšší hodnotou místní předvolby.
Důležité
Pokud používáte určité okruhy ExpressRoute jako záložní, musíte je aktivně spravovat a pravidelně testovat přepnutí.
Velká distribuovaná podniková síť
Pokud máte velkou distribuovanou podnikovou síť, pravděpodobně budete mít více okruhů ExpressRoute. Tato část popisuje, jak navrhnout obnovu po havárii pomocí okruhů ExpressRoute v režimu aktivní-aktivní bez nutnosti dalšího záložního okruhu.
Podívejte se na příklad znázorněný v následujícím diagramu. V tomto příkladu má Contoso dvě místní lokality připojené ke dvěma nasazením Contoso IaaS ve dvou různých oblastech Azure prostřednictvím okruhů ExpressRoute ve dvou různých místech partnerského propojení.
Způsob, jakým architektujete zotavení po havárii, ovlivňuje směrování provozu mezi oblastmi (region1/region2 do umístění2/location1). Zvažte dvě architektury zotavení po havárii, které odlišně směrují provoz mezi oblastmi a umístěními.
Scénář 1
V prvním scénáři navrhnete zotavení po havárii tak, aby veškerý provoz mezi Azure oblastí a místní sítí procházel přes místní okruh ExpressRoute v stabilním stavu. Pokud místní okruh ExpressRoute selže, vzdálený okruh ExpressRoute zpracovává všechny toky provozu mezi Azure a místní sítí.
Scénář 1 je znázorněný v následujícím diagramu. V diagramu zelené čáry označují cesty pro tok provozu mezi virtuální sítí VNet1 a místními sítěmi. Modré čáry označují cesty pro tok provozu mezi virtuální sítí 2 a místními sítěmi. Pevné čáry označují požadovanou cestu ve stejnosměrném stavu a přerušované čáry označují cestu provozu v případě selhání příslušného okruhu ExpressRoute, který nese průtok provozu ve stejnosměrném stavu.
Tento scénář můžete navrhnout tak, že pomocí váhy připojení ovlivníte virtuální sítě tak, aby pro provoz směřující do místní sítě upřednostňovaly připojení k místnímu peeringovému umístění ExpressRoute. K dokončení řešení je potřeba zajistit symetrický zpětný tok provozu. Pokud chcete preferovat okruh ExpressRoute, můžete použít místní předvolbu relace protokolu iBGP mezi směrovači protokolu BGP (na kterých okruhy ExpressRoute končí na místní straně). Řešení je znázorněno v následujícím diagramu.
Scénář 2
Scénář 2 je znázorněn v následujícím diagramu. V diagramu zelené čáry označují cesty pro tok provozu mezi virtuální sítí VNet1 a místními sítěmi. Modré čáry označují cesty pro tok provozu mezi virtuální sítí 2 a místními sítěmi. Ve stabilním stavu veškerý provoz mezi virtuálními sítěmi a místními umístěními normálně proudí přes páteřní síť Microsoftu, jak je znázorněno plnými čarami v diagramu. Provoz prochází propojením mezi místními umístěními pouze ve stavu selhání, což je znázorněno tečkovanými čarami v diagramu ExpressRoute.
Řešení je znázorněno v následujícím diagramu. Jak je znázorněno, můžete scénář navrhovat buď pomocí konkrétnější trasy (možnost 1), nebo předem připravené cesty AS (možnost 2) a ovlivnit tak výběr cesty k virtuální síti. Pokud chcete ovlivnit výběr tras v místní síti pro provoz směřující do Azure, musíte nakonfigurovat propojení v místním prostředí tak, aby bylo méně preferované. Jak nastavíte propojení jako preferované závisí na směrovacím protokolu používaném v rámci místní sítě. Místní předvolbu můžete použít s protokolem iBGP nebo metrikou s protokolem IGP (OSPF nebo IS-IS).
Důležité
Pokud je jeden nebo více okruhů ExpressRoute připojených k více virtuálním sítím, může se provoz mezi virtuálními sítěmi směrovat přes ExpressRoute. Nedoporučuje se to ale. Aby bylo možné povolit propojení virtuální sítě s virtuální sítí, konfigurujte propojení virtuálních sítí.
Související obsah
Tento článek popisuje, jak navrhnout obnovení po havárii pro připojení privátního partnerského propojení okruhu ExpressRoute. Následující články se zabývají obnovou po havárii z pohledu aplikací a front-endového přístupu: