Návrh pro zotavení po havárii s využitím privátního peeringu ExpressRoute
Služba ExpressRoute je navržena tak, aby zajišťovala vysokou dostupnost a aby pro prostředky Microsoftu poskytovala privátní síťové připojení na úrovni operátora. 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 s využitím ExpressRoute a dobře architektury
Pokud se ale něco může pokazit, v tomto článku se zaměříme na řešení, která překračují selhání, která je možné vyřešit pomocí jednoho okruhu ExpressRoute. Podíváme se na aspekty síťové architektury pro vytvoření robustního připojení back-endové sítě pro zotavení po havárii pomocí 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í
Existují možnosti a instance, kdy dojde ke snížení výkonu umístění partnerského vztahu ExpressRoute nebo celé regionální služby. Hlavní příčinou takového regionálního výpadku služeb je přírodní kalamita. Proto je důležité naplánovat 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 zotavení po havárii pro více okruhů ExpressRoute nakonfigurovaných prostřednictvím různých umístění partnerského vztahu. 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:
- Jako zálohu pro provoz privátního partnerského vztahu použijte síť VPN typu site-to-site.
- Připojení k internetu použijte jako zálohu pro přenosy partnerských vztahů 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í zotavením po havárii z aplikací a z hlediska přístupu 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í jiného okruhu ExpressRoute v jiném umístění 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 bránu firewall v cestě, asymetrické směrování může blokovat tok provozu. Obvykle se přes cestu privátního partnerského vztahu ExpressRoute, ke které nepřicházíte, na stavové entity, jako jsou překlad adres (NAT) nebo brány firewall. Asymetrické směrování přes privátní partnerský vztah 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 stejné metro nebo různé metro, které najdete na poskytovatelích podle stránky místa .
Redundance s okruhy ExpressRoute ve stejném metro
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 situace, kdy dojde k převzetí služeb při selhání aplikace, komplexní latence mezi místními aplikacemi a Microsoftem zůstane 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 s okruhy ExpressRoute v různých metrech
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 geografickou politickou oblast, musíte použít skladovou položku Premium pro oba okruhy v paralelních cestách. Výhodou této konfigurace je šance na přírodní katastrofu, která způsobuje výpadky obou propojení, jsou nižší, ale za cenu vyšší latence.
Poznámka:
Povolení BFD v okruhech ExpressRoute pomůže zrychlit detekci selhání propojení mezi zařízeními Microsoft Enterprise Edge (MSEE) a směrovači hraničních zařízení zákazníka nebo partnera. Celkové převzetí služeb při selhání a konvergence k redundantní lokalitě však může za určitých podmínek selhání trvat až 180 sekund a během této doby může docházet ke zvýšení latence nebo snížení výkonu.
V tomto článku si probereme, jak řešit 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
Podívejme se na ukázkovou síť znázorněnou v následujícím diagramu. V tomto příkladu se geograficky redundantní připojení ExpressRoute vytvoří mezi místním umístěním společnosti Contoso a virtuální sítí společnosti Contoso v oblasti Azure. 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á místní provoz vázaný na zatížení Azure napříč všemi cestami ExpressRoute pomocí směrování ECMP (Equal-Cost Multi-Path).
U geograficky redundantních okruhů ExpressRoute ale musíme vzít v úvahu různé výkony sítě s různými síťovými cestami (zejména pro latenci 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.
Azure můžete ovlivnit, aby preferovat 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šší váhy připojení u připojení, 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 poběží dolů, virtuální síť by viděla inzerování tras 10.1.11.0/24 pouze přes ExpressRoute 2; a proto se v tomto stavu selhání používá pohotovostní okruh.
Váha připojení
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 poběží dolů, virtuální síť by viděla inzerování tras 10.1.11.0/24 pouze přes ExpressRoute 2; a proto se v tomto stavu selhání používá pohotovostní 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ém trasě přes ExpressRoute 2 se asN místní sítě předzálohuje navíc na cestě AS 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.
Pokud použijete některou z technik, pokud azure preferujete některou z vašich ExpressRoute před ostatními, musíte také zajistit, aby místní 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 samostatné, musíte je aktivně spravovat a pravidelně testovat operaci převzetí služeb při selhání.
Velká distribuovaná podniková síť
Pokud máte velkou distribuovanou podnikovou síť, pravděpodobně budete mít více okruhů ExpressRoute. V této části se podíváme, jak navrhnout zotavení po havárii pomocí okruhů ExpressRoute aktivní-aktivní, aniž by bylo nutné provádět další samostatné okruhy.
Podívejme se na příklad znázorněný v následujícím diagramu. V tomto příkladu má společnost Contoso dvě místní umístění 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 umístěních partnerského vztahu.
Způsob, jakým jsme navrhli zotavení po havárii, má vliv na směrování provozu mezi oblastmi (region1/region2 do umístění2/location1). Pojďme se podívat na dvě různé architektury havárie, které směrují provoz mezi oblastmi a umístěním odlišně.
Scénář 1
V prvním scénáři navrhneme zotavení po havárii tak, aby veškerý provoz mezi oblastí Azure a místní sítí procházel přes místní okruh ExpressRoute v stabilním stavu. Pokud místní okruh ExpressRoute selže, použije se vzdálený okruh ExpressRoute pro všechny toky přenosů 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 v stabilním stavu a přerušované čáry označují cestu provozu v selhání odpovídajícího okruhu ExpressRoute, který nese tok provozu v stabilním stavu.
Scénář můžete navrhovat pomocí váhy připojení k ovlivnění virtuálních sítí, abyste upřednostnili připojení k místnímu umístění peeringu ExpressRoute pro místní síťový provoz vázaný na síť. 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 jsou okruhy ExpressRoute ukončeny 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. V stabilním stavu proudí plné čáry v diagramu veškerý provoz mezi virtuálními sítěmi a místními umístěními pomocí páteřní sítě Microsoftu normálně a prochází propojením mezi místními umístěními pouze ve stavu selhání, tečkované čáry 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 tak, že použijete konkrétnější trasu (možnost 1) nebo předběžnou cestu AS (možnost 2) a ovlivníte tak výběr cesty k virtuální síti. Pokud chcete ovlivnit výběr místních síťových tras pro provoz vázaný na Azure, musíte nakonfigurovat propojení mezi místním umístěním tak, aby bylo méně vhodnější. Způsob konfigurace propojení 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 přes ExpressRoute směrovat virtuální síť k provozu virtuální sítě. Nedoporučuje se to ale. Pokud chcete povolit připojení k virtuální síti, nakonfigurujte partnerský vztah virtuálních sítí.
Další kroky
V tomto článku jsme probrali, jak navrhnout zotavení po havárii připojení privátního partnerského vztahu okruhu ExpressRoute. Následující články se zabývají zotavením po havárii z aplikací a z hlediska přístupu front-endu: