Návrh pro vysokou dostupnost s ExpressRoute
ExpressRoute je navržená pro vysokou dostupnost, aby poskytovala privátní síťové připojení na úrovni dopravce k prostředkům Microsoftu. Jinými slovy, cesta ExpressRoute v síti Microsoftu neobsahuje jediný bod selhání. Aby se maximalizovala dostupnost, měl by být také zákaznický segment a segment poskytovatele služeb vašeho okruhu ExpressRoute architektonický s cílem zajistit vysokou dostupnost. V tomto článku se nejprve podíváme na aspekty síťové architektury pro vytváření robustního síťového připojení pomocí ExpressRoute a pak se podíváme na funkce pro ladění, které vám pomůžou zlepšit vysokou dostupnost vašeho okruhu ExpressRoute.
Poznámka
Koncepty popsané v tomto článku platí také při vytvoření okruhu ExpressRoute v rámci Virtual WAN nebo mimo něj.
Aspekty architektury
Následující obrázek znázorňuje doporučený způsob připojení pomocí okruhu ExpressRoute pro maximalizaci dostupnosti okruhu ExpressRoute.
Pro zajištění vysoké dostupnosti je nezbytné udržovat redundanci okruhu ExpressRoute v celé celé síti. Jinými slovy, potřebujete zachovat redundanci v rámci místní sítě a neměli byste ohrozit redundanci v síti poskytovatele služeb. Zachování redundance minimálně znamená, že se vyhnete jedinému bodu selhání sítě. Redundantní napájení a chlazení síťových zařízení dále zlepší vysokou dostupnost.
Aspekty návrhu první fyzické vrstvy najeté na vzdálenost
Pokud ukončíte primární i sekundární připojení okruhů ExpressRoute na stejném zařízení CPE (Customer Premises Equipment), je ohrožena vysoká dostupnost v rámci místní sítě. Pokud navíc nakonfigurujete primární i sekundární připojení přes stejný port CPE (buď ukončením těchto dvou připojení v rámci různých dílčích rozhraní, nebo sloučením těchto dvou připojení v rámci partnerské sítě), vynutíte, aby partner ohrozil také vysokou dostupnost v segmentu sítě. Toto ohrožení zabezpečení je znázorněno na následujícím obrázku.
[![2.]][2.]
Na druhé straně, pokud ukončíte primární a sekundární připojení okruhů ExpressRoute v různých geografických umístěních, může dojít k ohrožení výkonu sítě připojení. Pokud je provoz aktivně vyvážený napříč primárními a sekundárními připojeními ukončenými v různých geografických umístěních, potenciální podstatný rozdíl v latenci sítě mezi těmito dvěma cestami by měl za následek neoptimální výkon sítě.
Důležité informace o geograficky redundantním návrhu najdete v tématu Návrh pro zotavení po havárii pomocí ExpressRoute.
Připojení aktivní-aktivní
Síť Microsoftu je nakonfigurovaná tak, aby provozovala primární a sekundární připojení okruhů ExpressRoute v režimu aktivní-aktivní. Prostřednictvím inzerování tras však můžete vynutit redundantní připojení okruhu ExpressRoute, aby provozovala v režimu aktivní-pasivní. Inzerování konkrétnějších tras a předpřipravení cesty AS protokolu BGP jsou běžné techniky, které upřednostní jednu cestu před druhou.
Pro zlepšení vysoké dostupnosti se doporučuje provozovat obě připojení okruhu ExpressRoute v režimu aktivní-aktivní. Pokud připojení pustíte do provozu v režimu aktivní-aktivní, bude síť Microsoftu vyvažovat zatížení provozu napříč připojeními podle jednotlivých toků.
Spuštění primárního a sekundárního připojení okruhu ExpressRoute v režimu aktivní-pasivní čelí riziku selhání obou připojení v případě selhání v aktivní cestě. Běžné příčiny selhání při přepnutí jsou nedostatečná aktivní správa pasivního připojení a pasivní inzerování zastaralých tras připojení.
Případně pokud po selhání připojení ExpressRoute po spuštění primárního a sekundárního připojení okruhu ExpressRoute v režimu aktivní-aktivní selhává a přesměrovává se pouze polovina toků. Proto režim aktivní-aktivní výrazně pomůže vylepšit střední dobu obnovení (MTTR).
Poznámka
V průběhu údržby nebo v případě neplánovaných událostí, které mají vliv na jedno z připojení, bude Microsoft preferovat použití předchytáky cesty AS k vyprázdnění provozu do připojení, které je v pořádku. Při konfiguraci předpřipravené cesty od Microsoftu a správné konfiguraci požadovaných inzerování tras budete muset zajistit, aby provoz mohl směrovat přes cestu, která je v pořádku, a zabránit tak přerušení služeb.
Překlad překladu (NAT) pro partnerský vztah Microsoftu
Partnerský vztah Microsoftu je navržený pro komunikaci mezi veřejnými koncovými body. Místní privátní koncové body jsou proto obvykle přeložené na základě síťových adres (NATed) s veřejnou IP adresou zákazníka nebo partnerské sítě předtím, než komunikují přes partnerský vztah Microsoftu. Za předpokladu, že používáte primární i sekundární připojení v režimu aktivní-aktivní, kde a jak má na nat vliv na to, jak rychle se zotavíte po selhání jednoho z připojení ExpressRoute. Na následujícím obrázku jsou znázorněny dvě různé možnosti NAT:
[![3]][3]
Možnost 1:
Nat se použije po rozdělení provozu mezi primární a sekundární připojení okruhu ExpressRoute. Pro splnění stavových požadavků na nat se pro primární a sekundární zařízení používají nezávislé fondy NAT. Návratový provoz dorazí na stejné hraniční zařízení, přes které tok vystupoval.
Pokud připojení ExpressRoute selže, možnost kontaktovat odpovídající fond NAT se pak přerušine. To je důvod, proč všechny poškozené síťové toky musí být znovu vytvořeny protokolem TCP nebo aplikační vrstvou po odpovídajícím časovém limitu okna. Během selhání se Azure nemůže připojit k místním serverům pomocí odpovídajícího nat, dokud se připojení nebude obnovovat pro primární nebo sekundární připojení okruhu ExpressRoute.
Možnost 2:
Před rozdělením provozu mezi primární a sekundární připojení okruhu ExpressRoute se používá společný fond NAT. Je důležité rozlišit, že společný fond NAT před rozdělením provozu neznamená, že by došlo k jedinému bodu selhání, jako je ohrožení vysoké dostupnosti.
Fond NAT je dostupný i po selhání primárního nebo sekundárního připojení. To je důvod, proč samotná síťová vrstva může přesměrovat pakety a po selhání urychlit obnovení.
Poznámka
- Pokud použijete možnost NAT 1 (nezávislé fondy NAT pro primární a sekundární připojení ExpressRoute) a namapujte port IP adresy z jednoho z fondu NAT na místní server, server nebude dostupný prostřednictvím okruhu ExpressRoute, pokud příslušné připojení selže.
- Ukončení připojení ExpressRoute BGP na stavových zařízeních může způsobit problémy s převzetím služeb při selhání během plánované nebo neplánované údržby microsoftem nebo vaším poskytovatelem ExpressRoute. Nastavení byste měli otestovat, abyste zajistili správné převzetí služeb při selhání provozu a pokud je to možné, ukončete relace protokolu BGP na bezstavových zařízeních.
Vyladění funkcí pro privátní peering
V této části si projdeme volitelné funkce (v závislosti na nasazení Azure a citlivosti na MTTR), které pomáhají zlepšit vysokou dostupnost vašeho okruhu ExpressRoute. Konkrétně se podívejme na nasazení bran virtuální sítě ExpressRoute s zónou a detekci obousměrného předávání (BFD).
Brány virtuální sítě ExpressRoute s zónou dostupnosti
Zóna dostupnosti v oblasti Azure je kombinací domény selhání a aktualizační domény. Pokud se rozhodnete pro zónově redundantní nasazení Azure IaaS, můžete také nakonfigurovat zónově redundantní brány virtuální sítě, které ukončuje privátní partnerský vztah ExpressRoute. Další informace najdete v tématu Informace o zónově redundantních branách virtuálních sítí v Zóny dostupnosti Azure. Informace o konfiguraci zónově redundantní brány virtuální sítě najdete v tématu Vytvoření zónově redundantníbrány virtuální sítě v Zóny dostupnosti Azure .
Zlepšení doby detekce selhání
ExpressRoute podporuje BFD přes privátní peering. BFD zkracuje dobu detekce selhání sítě vrstvy 2 mezi směrovači Microsoft Enterprise Edge (MSEE) a jejich sousedy BGP na místní straně z přibližně 3 minut (výchozí) na méně než sekundu. Rychlá doba detekce selhání pomáhá zrychlit obnovení při selhání. Další informace najdete v tématu Konfigurace BFD přes ExpressRoute.
Další kroky
V tomto článku jsme probrali, jak navrhnout návrh pro vysokou dostupnost připojení okruhu ExpressRoute. Bod partnerského vztahu okruhu ExpressRoute je připnutý k zeměpisnému umístění, a proto ho může ovlivnit katastrofické selhání, které ovlivňuje celé umístění.
Informace o aspektech návrhu pro vytvoření geograficky redundantního síťového připojení k páteřní síti Microsoftu, které dokáže odolat katastrofickým selháním, která mají dopad na celou oblast, najdete v tématu Návrh zotavení po havárii s privátním partnerským vztahem ExpressRoute.