Dela via

Utforma för haveriberedskap med ExpressRoute privat peering

  • Artikel

ExpressRoute är utformat för hög tillgänglighet för att tillhandahålla privata nätverksanslutningar i operatörsklass för 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-Architectured Framework

Men med murphys populära talesätt – om något kan gå fel, kommer det att beaktas, i den här artikeln kan vi fokusera på lösningar som går utöver fel som kan åtgärdas med hjälp av en enda ExpressRoute-krets. Vi ska titta på nätverksarkitekturöverväganden för att skapa en robust nätverksanslutning för serverdelen för haveriberedskap 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

Det finns möjligheter och instanser där en ExpressRoute-peeringplats eller en hel regional tjänst degraderas. Rotorsaken till ett sådant regionalt avbrott i tjänsten är naturlig katastrof. Därför är det viktigt att planera för haveriberedskap för affärskontinuitet 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 haveriberedskap från program och klientdelsåtkomstperspektiv:

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ämning trafik över geo-redundant parallella sökvägar, oavsett om du har tillståndskänsliga entiteter eller inte, skulle du uppleva inkonsekventa nätverksprestanda. Dessa geo-redundanta parallella vägar kan vara via samma tunnelbana eller annan metro som finns på leverantörerna efter platssida .

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 anslutningen för båda sökvägarna inte längre är tillgänglig.

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 de parallella sökvägarna. 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.

I den här artikeln ska vi gå igenom hur du kan hantera utmaningar som du kan stöta på när du konfigurerar geo-redundanta sökvägar.

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

Låt oss överväga exempelnätverket som illustreras i följande diagram. I exemplet upprättas geo-redundant ExpressRoute-anslutning mellan en lokal plats i Contoso och Contosos virtuella nätverk i en Azure-region. I diagrammet anger en hel blå linje önskad sökväg (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 som standard annonserar vägar identiskt över alla ExpressRoute-sökvägar, lastbalanserar Azure lokal trafik över alla ExpressRoute-sökvägar med hjälp av ECMP-routning (Equal-cost multi-path).

Med de geo-redundanta ExpressRoute-kretsarna måste vi dock ta hänsyn till olika nätverksprestanda med olika nätverkssökvägar (särskilt för nätverksfördröjning). 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 vägarna via en mindre föredragen 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 önskad sökväg (ExpressRoute 1) och som /24 via stand-by-sökvä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 vägannonsen 10.1.11.0/24 via ExpressRoute 2. och därför används väntelägeskretsen i det här feltillståndet.

Anslutningsvikt

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

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 vägannonsen 10.1.11.0/24 via ExpressRoute 2. och därför används väntelägeskretsen i det här feltillståndet.

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 vägannonsen via ExpressRoute 2 förbereds det lokala nätverkets ASN dessutom på vägens AS-sökväg. När samma väg tas emot via flera ExpressRoute-kretsar föredrar VNet, 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. Följdriktigt skulle den längre AS-vägen bli irrelevant. Därför används väntelägeskretsen i det här feltillståndet.

Om du använder någon av teknikerna, om du påverkar Azure att föredra en av dina ExpressRoute framför andra, måste du också se till att det lokala nätverket också föredrar samma ExpressRoute-sökväg för Azure-bunden trafik 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 inställning är ett internt BGP-mått (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. I det här avsnittet ska vi se hur du utformar haveriberedskap med hjälp av de aktiva ExpressRoute-kretsarna, utan att behöva någon annan stand-by-krets.

Låt oss överväga 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 vi utformar haveriberedskapen påverkar hur trafik mellan regioner och regioner (region1/region2 till plats2/plats1) dirigeras. Låt oss överväga två olika katastrofarkitekturer som dirigerar trafik mellan regioner och platser på olika sätt.

Scenario 1

I det första scenariot ska vi utforma 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 används expressroute-fjärrkretsen för 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 i felet för motsvarande ExpressRoute-krets som bär trafikflödet i stabilt tillstånd.

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

Du kan skapa scenariot med hjälp av anslutningsvikt för att påverka virtuella nätverk att föredra anslutning till lokal peeringplats ExpressRoute för lokal nätverksbunden trafik. 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 diagrammets stadiga, fasta linjer flödar all trafik mellan virtuella nätverk och lokala platser normalt med Hjälp av Microsofts stamnät och flödar genom sammankopplingen mellan lokala platser endast i feltillståndet, 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 skapa scenariot med hjälp av mer specifik väg (alternativ 1) eller AS-sökvägsförberedelse (alternativ 2) för att påverka valet av VNet-sökväg. För att påverka valet av lokal nätverksväg för Azure-bunden trafik behöver du konfigurera sammankopplingen mellan den lokala platsen som mindre att föredra. 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 lokala inställningar med iBGP eller mått 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. Konfigurera peering för virtuella nätverk för att aktivera anslutning till virtuella nätverk.

Nästa steg

I den här artikeln diskuterade vi hur du utformar för haveriberedskap för en privat ExpressRoute-kretss privata peeringanslutning. Följande artiklar behandlar haveriberedskap från program och klientdelsåtkomstperspektiv: