Designa för katastrofåterställning med ExpressRoute privat peering

ExpressRoute är utformat för hög tillgänglighet för att tillhandahålla privata nätverksanslutningar i transportföretagsklass till Microsoft resurser. Det finns med andra ord ingen enskild felpunkt i ExpressRoute-sökvägen i Microsoft-nätverket. Designöverväganden för att maximera tillgängligheten för en ExpressRoute-krets finns i Designa för hög tillgänglighet med ExpressRoute och Well-Architected Framework.

Men med Murphys populära ordspråk (om något kan gå fel, så gör det det) i åtanke fokuserar den här artikeln på lösningar för avbrott som går utöver vad en enskild ExpressRoute-anslutning kan hantera. Den behandlar överväganden kring nätverksarkitektur för att utforma robust nätverksanslutning till backend-system för katastrofåterställning med hjälp av geo-redundanta ExpressRoute-kretsar.

Kommentar

Begreppen som beskrivs i den här artikeln gäller även när en ExpressRoute-krets skapas under Virtual WAN eller utanför den.

Behov av redundant anslutningslösning

ExpressRoute-peeringplatser eller en hel regional tjänst kan drabbas av försämrad prestanda. Ett regionalt avbrott i tjänsten kan omfatta naturlig katastrof. Planera för haveriberedskap för verksamhetskontinuitet och verksamhetskritiska program.

Kommentar

När du behöver implementera en design för haveriberedskap i en tidskänslig situation, till exempel för att upprätthålla affärskontinuitet under en naturkatastrof, bör du ta hänsyn till följande faktorer:

  • Det här dokumentet innehåller vägledning om hur du implementerar en robust design för haveriberedskap för flera ExpressRoute-kretsar som konfigureras via olika peeringplatser. Det här scenariot förutsätter att du har tillräckligt med tid och resurser för att konfigurera ExpressRoute-kretsarna.
  • Om du snabbt behöver konfigurera en haveriberedskapsdesign för en enskild ExpressRoute-krets som inte är geo-redundant kan du använda följande alternativ:

Oavsett vad, oavsett om du kör dina verksamhetskritiska program i en Azure-region eller lokalt eller någon annanstans, kan du använda en annan Azure-region som redundanswebbplats. Följande artiklar behandlar katastrofåterställning ur perspektiven applikationer och åtkomst till klientdelen:

Om du förlitar dig på ExpressRoute-anslutning mellan ditt lokala nätverk och Microsoft måste du överväga följande för att planera för haveriberedskap via ExpressRoute:

Utmaningar med att använda flera ExpressRoute-kretsar

När du ansluter samma uppsättning nätverk med fler än en anslutning introducerar du parallella sökvägar mellan nätverken. Parallella sökvägar, när de inte är korrekt arkitekterade, kan leda till asymmetrisk routning. Om du har tillståndskänsliga entiteter, till exempel en NAT eller brandvägg i sökvägen, kan asymmetrisk routning blockera trafikflödet. I den privata ExpressRoute-peeringsökvägen stöter du vanligtvis inte på tillståndskänsliga entiteter som NAT eller brandväggar. Därför blockerar asymmetrisk routning via privat ExpressRoute-peering inte nödvändigtvis trafikflödet.

Men om du belastningsutjämnar trafik över parallella geo-redundanta sökvägar, oavsett om du har tillståndskänsliga entiteter eller inte, skulle du uppleva inkonsekvent nätverksprestanda. Dessa geo-redundanta parallela vägar kan gå via samma stadsområde eller olika stadsområden som listas på sidan leverantörer efter plats.

Redundans med ExpressRoute-kretsar i samma tunnelbana

Många metros har två ExpressRoute-platser. Ett exempel skulle vara Amsterdam och Amsterdam2. När du utformar redundans kan du skapa två parallella sökvägar till Azure med båda platserna i samma tunnelbana. Du utför den här uppgiften med samma leverantör eller väljer att arbeta med en annan tjänstleverantör för att förbättra återhämtning. En annan fördel med den här designen är att när programredundans sker förblir svarstiden från slutpunkt till slutpunkt mellan dina lokala program och Microsoft ungefär densamma. Men om det uppstår en naturkatastrof, till exempel en jordbävning, kanske anslutningarna inte längre är tillgängliga.

Redundans med ExpressRoute-kretsar i olika metros

När du använder olika metros för redundans bör du välja den sekundära platsen i samma geopolitiska region. Om du vill välja en plats utanför den geopolitiska regionen måste du använda Premium SKU för båda kretsarna i parallella vägar. Fördelen med den här konfigurationen är risken för att en naturkatastrof orsakar ett avbrott för båda länkarna är lägre, men på bekostnad av ökad svarstid från slutpunkt till slutpunkt.

Kommentar

Om du aktiverar BFD på ExpressRoute-kretsarna kan du snabbare identifiera länkfel mellan Microsoft Enterprise Edge-enheter (MSEE) och Customer/Partner Edge-routrarna. Den övergripande redundansväxlingen och konvergensen till den redundanta platsen kan dock ta upp till 180 sekunder under vissa felförhållanden och du kan uppleva ökad fördröjning eller prestandaförsämring under den här tiden.

Följande avsnitt beskriver utmaningar som du kan stöta på när du konfigurerar geo-redundanta sökvägar.

Små till medelstora lokala nätverksöverväganden

Överväg exempelnätverket som illustreras i följande diagram. I exemplet upprättas geo-redundant ExpressRoute-anslutning mellan Contosos lokala plats och Contosos virtuella nätverk i en Azure region. I diagrammet anger den helblå linjen den önskade sökvägen (via ExpressRoute 1) och den prickade representerar stand-by-sökvägen (via ExpressRoute 2).

Diagram över små till medelstora lokala nätverksöverväganden.

Om du annonserar rutter standardmässigt identiskt över alla ExpressRoute-sökvägar, lastbalanserar Azure trafik som är på väg till den lokala miljön över högst 4 ExpressRoute-kretsar med ECMP-routning (Equal-cost multi-path).

Men med geo-redundanta ExpressRoute-kretsar måste du ta hänsyn till att nätverksprestandan kan variera mellan olika nätverkssökvägar, särskilt nätverkslatens. För att få mer konsekventa nätverksprestanda under normal drift kanske du vill föredra ExpressRoute-kretsen som erbjuder minimal svarstid.

Du kan påverka Azure att föredra en ExpressRoute-krets framför en annan med någon av följande tekniker (listad i effektivitetsordning):

  • annonsera mer specifik väg över den föredragna ExpressRoute-kretsen jämfört med andra ExpressRoute-kretsar
  • konfigurera högre anslutningsvikt för anslutningen som länkar det virtuella nätverket till önskad ExpressRoute-krets
  • annonsera rutterna via en mindre föredragna ExpressRoute-krets med längre AS-sökväg (AS Path prepend)

Mer specifik väg

Följande diagram visar hur du påverkar valet av ExpressRoute-sökväg med hjälp av mer specifik vägannons. I det illustrerade exemplet annonseras Contosos lokala IP-intervall /24 som två /25-adressintervall via den föredragna vägen (ExpressRoute 1) och som /24 via reservvägen (ExpressRoute 2).

Diagram över hur du påverkar sökvägsval med hjälp av mer specifika vägar.

Eftersom /25 är mer specifik, jämfört med /24, skulle Azure skicka trafiken till 10.1.11.0/24 via ExpressRoute 1 i normalt tillstånd. Om båda anslutningarna för ExpressRoute 1 går ner skulle det virtuella nätverket endast se routningsannonsen 10.1.11.0/24 via ExpressRoute 2, och därför används standbykretsen under detta feltillstånd.

Anslutningsvikt

Följande skärmbild visar hur du konfigurerar vikten för en ExpressRoute-anslutning via Azure Portal.

Skärmbild av konfiguration av anslutningsvikt via Azure-portalen.

Följande diagram visar hur du påverkar valet av ExpressRoute-sökväg med hjälp av anslutningsvikt. Standardanslutningsvikten är 0. I följande exempel konfigureras anslutningens vikt för ExpressRoute 1 som 100. När ett virtuellt nätverk tar emot ett routningsprefix som annonseras via mer än en ExpressRoute-krets föredrar det virtuella nätverket anslutningen med den högsta vikten.

Diagram över hur du påverkar val av sökväg med hjälp av anslutningsvikt.

Om båda anslutningarna för ExpressRoute 1 går ner skulle det virtuella nätverket endast se routningsannonsen 10.1.11.0/24 via ExpressRoute 2, och därför används standbykretsen under detta feltillstånd.

AS-sökvägsförberedelse

Följande diagram visar hur du påverkar valet av ExpressRoute-sökväg med hjälp av AS-sökvägsförberedelser. I diagrammet anger vägannonseringen över ExpressRoute 1 standardbeteendet för eBGP. I ruttannonseringen via ExpressRoute 2 läggs det lokala nätverkets ASN dessutom till i rutten på AS-sökvägen. När samma väg tas emot via flera ExpressRoute-kretsar föredrar det virtuella nätverket, enligt eBGP-vägvalsprocessen, vägen med den kortaste AS-sökvägen.

Diagram över hur du påverkar sökvägsval med hjälp av AS-sökvägsförberedelser.

Om båda anslutningarna för ExpressRoute 1 går ned skulle det virtuella nätverket endast se vägannonsen 10.1.11.0/24 via ExpressRoute 2. Därför skulle den längre AS-vägen bli irrelevant. Därför används väntelägeskretsen i det här feltillståndet.

När du använder någon av teknikerna och påverkar Azure att föredra en av dina ExpressRoute framför andra, måste du också se till att det lokala nätverket föredrar samma ExpressRoute-väg för trafik som ska till Azure, för att undvika asymmetriska flöden. Normalt används det lokala inställningsvärdet för att påverka det lokala nätverket att föredra en ExpressRoute-krets framför andra. Lokal preferens är en intern BGP-metrik (iBGP). BGP-vägen med det högsta lokala inställningsvärdet är att föredra.

Viktigt!

När du använder vissa ExpressRoute-kretsar som stand-by måste du aktivt hantera dem och regelbundet testa redundansväxlingen.

Stort distribuerat företagsnätverk

När du har ett stort distribuerat företagsnätverk kommer du förmodligen att ha flera ExpressRoute-kretsar. Det här avsnittet visar hur du utformar haveriberedskap med hjälp av aktiva ExpressRoute-kretsar utan att behöva någon annan stand-by-krets.

Tänk på exemplet som illustreras i följande diagram. I exemplet har Contoso två lokala platser som är anslutna till två Contoso IaaS-distributioner i två olika Azure regioner via ExpressRoute-kretsar på två olika peeringplatser.

Diagram över stora överväganden för distribuerat lokalt nätverk.

Hur du utformar haveriåterställning påverkar hur trafik från regionövergripande till platsövergripande routning (region1/region2 till plats2/plats1) dirigeras. Överväg två katastrofarkitekturer som dirigerar trafik mellan regioner på olika sätt.

Scenario 1:

I det första scenariot utformar du haveriberedskap så att all trafik mellan en Azure region och det lokala nätverket flödar via den lokala ExpressRoute-kretsen i stabilt tillstånd. Om den lokala ExpressRoute-kretsen misslyckas hanterar ExpressRoute-fjärrkretsen alla trafikflöden mellan Azure och det lokala nätverket.

Scenario 1 illustreras i följande diagram. I diagrammet visar gröna linjer sökvägar för trafikflödet mellan VNet1 och lokala nätverk. De blå linjerna anger sökvägar för trafikflödet mellan VNet2 och lokala nätverk. Solida linjer anger önskad sökväg i stabilt tillstånd och de streckade linjerna indikerar trafiksökvägen vid fel på motsvarande ExpressRoute-krets som hanterar trafikflödet i stabilt tillstånd.

Diagram över trafikflödet för det första scenariot.

Du kan utforma scenariot med hjälp av anslutningsvikt för att påverka virtuella nätverk (VNets) att föredra anslutning till den lokala peeringplatsen för ExpressRoute för trafik som är avsedd för det lokala (on-premises-)nätverket. För att slutföra lösningen måste du säkerställa symmetriskt omvänd trafikflöde. Du kan använda lokala inställningar för iBGP-sessionen mellan dina BGP-routrar (där ExpressRoute-kretsar avslutas lokalt) för att föredra en ExpressRoute-krets. Lösningen illustreras i följande diagram.

Diagram över aktiv-aktiv ExpressRoute-kretslösning 1.

Scenario 2

Scenario 2 illustreras i följande diagram. I diagrammet visar gröna linjer sökvägar för trafikflödet mellan VNet1 och lokala nätverk. De blå linjerna anger sökvägar för trafikflödet mellan VNet2 och lokala nätverk. I stadigvarande tillstånd, de solida linjerna i diagrammet, flödar all trafik mellan VNets och lokala platser normalt med hjälp av Microsofts stamnät och flödar genom anslutningen mellan lokala platser endast vid fel, markerat som prickade linjer i diagrammet, för en ExpressRoute.

Diagram över trafikflödet för det andra scenariot.

Lösningen illustreras i följande diagram. Som illustreras kan du utforma scenariot antingen genom att använda en mer specifik väg (alternativ 1) eller AS-path prepend (alternativ 2) för att påverka val av sökväg i det virtuella nätverket. För att påverka val av nätverksrutt i det lokala nätverket för trafik som är på väg till Azure måste du konfigurera sammankopplingen med den lokala miljön som mindre prioriterad. Hur du konfigurerar anslutningslänken som att föredra beror på vilket routningsprotokoll som används i det lokala nätverket. Du kan använda lokal preferens med iBGP eller metric med IGP (OSPF eller IS-IS).

Diagram över aktiv-aktiv ExpressRoute-kretslösning 2.

Viktigt!

När en eller flera ExpressRoute-kretsar är anslutna till flera virtuella nätverk kan trafik mellan virtuella nätverk dirigeras via ExpressRoute. Detta rekommenderas dock inte. För att aktivera anslutning mellan virtuella nätverk, konfigurera peering mellan virtuella nätverk.

Relaterat innehåll

Den här artikeln beskriver hur du utformar privat peering-anslutning för en ExpressRoute-krets för haveriåterställning. Följande artiklar behandlar katastrofåterställning ur applikations- och klientåtkomstperspektiv:

  • Uppdaterades senast