Design för haveri beredskap med ExpressRoute privat peering

ExpressRoute har utformats för att ge hög tillgänglighet för att tillhandahålla bärvåg för privat nätverks anslutning 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 utforma för hög tillgänglighet med ExpressRoute.

Men om du tar Murphy populärt Adage –om något går fel, kommer det att övervägas, 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 kommer att titta på nätverks arkitektur överväganden för att skapa robusta Server dels nätverks anslutningar för haveri beredskap med hjälp av Geo-redundanta ExpressRoute-kretsar.

Behov av redundant anslutnings lösning

Det finns möjligheter och instanser där en hel regional tjänst (var den Microsoft, nätverks tjänst leverantörer, kund eller andra moln tjänst leverantörer) försämras. Rotor saken till sådan regional omfattande tjänst påverkan är naturlig Calamity. Därför är det viktigt att planera för haveri beredskap för affärs kontinuitet och verksamhets kritiska program.

Oavsett vad, oavsett om du kör dina verksamhets kritiska program i en Azure-region eller lokalt eller var du än befinner dig, kan du använda en annan Azure-region som redundans plats. Följande artiklar behandlar haveri beredskap från program och åtkomst till klient åtkomst perspektiv:

• Haveriberedskap i företagsskala
• SMB-haveriberedskap med Azure Site Recovery

Om du förlitar dig på ExpressRoute-anslutning mellan ditt lokala nätverk och Microsoft för verksamhets kritiska åtgärder bör din katastrof återställnings plan även omfatta Geo-redundant nätverks anslutning.

Utmaningar med att använda flera ExpressRoute-kretsar

När du samman samma uppsättning nätverk med mer än en anslutning, introduceras parallella sökvägar mellan nätverken. Parallella sökvägar, om de inte är korrekt konstruerade, kan leda till asymmetrisk routning. Om du har tillstånds känsliga entiteter (till exempel NAT, brand vägg) i sökvägen kan asymmetrisk routning blockera trafikflöde. Vanligt vis kommer du inte över tillstånds känsliga entiteter, till exempel NAT eller brand väggar, via ExpressRoute privata peering-sökvägen. Därför blockerar asymmetrisk routning via ExpressRoute privat peering inte nödvändigt vis trafikflödet.

Men om du belastningsutjämna trafik över geo-redundanta parallella sökvägar, oavsett om du har tillstånds känsliga entiteter eller inte, så kommer du att uppleva inkonsekvent nätverks prestanda. Dessa geo-redundanta parallella sökvägar kan vara via samma tunnelbane linje eller en annan tunnelbane linje som finns på sidan providers efter plats .

Samma tunnelbane

Många Metros har två ExpressRoute-platser. Ett exempel är Amsterdam -och Amsterdam2. När du designar redundans kan du skapa två parallella sökvägar till Azure med båda platserna i samma tunnelbane linje. Fördelen med den här designen är när programredundans sker, slut punkt till slut punkt mellan dina lokala program och Microsoft förblir ungefär samma. Men om det finns en natur katastrof, till exempel en jord bävning, kan anslutningen för båda Sök vägarna inte längre vara tillgänglig.

Olika Metros

När du använder olika Metros för redundans bör du välja den sekundära platsen i samma geo-politiska region. Om du vill välja en plats utanför geo-politisk regionen måste du använda Premium SKU för båda kretsarna i de parallella Sök vägarna. Fördelen med den här konfigurationen är risken för en natur katastrof som orsakar ett avbrott i båda länkarna är mycket lägre men till kostnaden för ökad latens från slut punkt till slut punkt.

I den här artikeln diskuterar vi hur du kan åtgärda utmaningar som du kan stöta på när du konfigurerar geo-redundanta sökvägar.

Överväganden för små till medel stora nätverks platser

Nu ska vi titta på exempel nätverket som illustreras i följande diagram. I exemplet upprättas Geo-redundant ExpressRoute-anslutning mellan en lokal plats i Contoso och Contosos VNet i en Azure-region. I diagrammet indikerar heldragen grön linje önskad sökväg (via ExpressRoute 1) och den prickade en representerar en behållen väg (via ExpressRoute 2).

![81.1]

När du utformar ExpressRoute-anslutningen för haveri beredskap måste du tänka på följande:

• använda geo-redundanta ExpressRoute-kretsar
• använda olika tjänst leverantörs nätverk för olika ExpressRoute-kretsar
• utforma var och en av ExpressRoute-kretsen för hög tillgänglighet
• avsluta olika ExpressRoute-kretsar på olika platser i kundens nätverk

Om du annonserar vägar identiskt över alla ExpressRoute-sökvägar kommer Azure att belastningsutjämna en lokal bindnings trafik över alla ExpressRoute sökvägar med hjälp av ECMP-routning (lika-kostnad multi-path).

Men med de geo-redundanta ExpressRoute-kretsarna behöver vi ta hänsyn till olika nätverks prestanda med olika nätverks Sök vägar (särskilt för nätverks fördröjning). Om du vill få mer konsekvent nätverks prestanda under normal drift kan du vilja föredra den ExpressRoute-krets som har den minsta svars tiden.

Du kan påverka Azure för att föredra en ExpressRoute-krets över en annan med hjälp av någon av följande metoder (anges i effektivitets ordning):

• Annonsera mer speciell väg över den önskade ExpressRoute-kretsen jämfört med andra ExpressRoute-kretsar
• Konfigurera högre anslutnings vikt för anslutningen som länkar det virtuella nätverket till önskad ExpressRoute-krets
• Annonsera vägarna över mindre önskad ExpressRoute-krets med längre sökväg (som sökväg lägga)

Mer speciell väg

Följande diagram illustrerar hur du påverkar ExpressRoute sökvägar med hjälp av mer speciell väg annonsering. I det här exemplet visas Contosos lokalt/24 IP-intervall som två/25 adress intervall via önskad sökväg (ExpressRoute 1) och som/24 via sökvägen (ExpressRoute 2).

![11.2]

Eftersom/25 är mer särskilt 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 ned skulle VNet se 10.1.11.0/24-väg annonsen endast via ExpressRoute 2; och därför används standby-kretsen i det här felet.

Anslutnings vikt

Följande skärm bild visar hur du konfigurerar en ExpressRoute-anslutnings vikt via Azure Portal.

Följande diagram illustrerar hur du påverkar ExpressRoute Sök vägs val med anslutnings vikt. Standard anslutningens vikt är 0. I exemplet nedan konfigureras vikten för anslutningen för ExpressRoute 1 som 100. När ett VNet får ett väg-prefix som annonseras via fler än en ExpressRoute-krets föredrar det virtuella nätverket anslutningen med högsta vikt.

Om båda anslutningarna för ExpressRoute 1 går ned skulle VNet se 10.1.11.0/24-väg annonsen endast via ExpressRoute 2; och därför används standby-kretsen i det här felet.

SOM sökväg lägga

Följande diagram illustrerar hur du påverkar ExpressRoute Sök vägs val med hjälp av sökvägen lägga. I diagrammet anger väg annonsen över ExpressRoute 1 standard beteendet för eBGP. I väg annonsen över ExpressRoute 2 är det lokala nätverkets ASN anpassningsprefix också på vägens AS-sökväg. När samma väg tas emot via flera ExpressRoute-kretsar, skulle VNet prioritera vägen med den kortaste AS-sökvägen per eBGP.

Om båda anslutningarna för ExpressRoute 1 går ned skulle VNet se 10.1.11.0/24-väg annonsen endast via ExpressRoute 2. I tur och ordning skulle den längre som sökvägen bli irrelevant. Därför används standby-kretsen i det här felet.

Om du använder någon av teknikerna, om du påverkar Azure för att föredra en av dina ExpressRoute över andra, måste du också se till att det lokala nätverket också föredrar samma ExpressRoute-sökväg för Azure-bindningen för att undvika asymmetriska flöden. Inställningen för lokalt värde används vanligt vis för att påverka det lokala nätverket för att föredra en ExpressRoute-krets över andra. Lokal preferens är ett internt BGP (iBGP) mått. BGP-vägen med det högsta lokala preferens värdet är föredra.

Stort distribuerat företags nätverk

När du har ett stort distribuerat företags nätverk har du förmodligen flera ExpressRoute-kretsar. I det här avsnittet får du se hur du kan designa haveri beredskap med hjälp av aktiva ExpressRoute-kretsar, utan att behöva en annan uppsättning kretsar.

Vi ska titta på exemplet som illustreras i följande diagram. I exemplet har contoso två lokala platser som är anslutna till två contoso IaaS-distribution i två olika Azure-regioner via ExpressRoute-kretsar på två olika peering-platser.

![3-6]

Hur vi skapar haveri beredskap har en inverkan på hur trafiken mellan regioner och över platser (Region1/Region2 till location2/location1) dirigeras. Vi tänker på två olika katastrof arkitekturer som dirigerar trafik mellan olika regioner.

Scenario 1

I det första scenariot kan vi utforma haveri beredskap, så att all trafik mellan en Azure-region och ett lokalt nätverks flöde via den lokala ExpressRoute-kretsen i stabilt tillstånd. Om den lokala ExpressRoute-kretsen Miss lyckas används fjärran sluten ExpressRoute-kretsen för alla trafikflöden mellan Azure och det lokala nätverket.

Scenario 1 illustreras i följande diagram. I diagrammet indikerar gröna linjer sökvägar för trafikflöde mellan VNet1 och lokala nätverk. De blå linjerna indikerar vägar för trafikflöde mellan VNet2 och lokala nätverk. Heldragna linjer anger önskad sökväg i stabilt läge och de streckade linjerna indikerar trafik Sök vägen vid en ExpressRoute-krets som har ett stabilt tillstånds trafikflöde.

![3,7]

Du kan skapa scenariot med anslutnings vikt för att påverka virtuella nätverk för att föredra anslutning till den lokala peering-platsen ExpressRoute för den lokala nätverks bindnings trafiken. För att slutföra lösningen måste du se till att symmetriskt flöde för trafikflödet återställs. Du kan använda lokal inställning på iBGP-sessionen mellan BGP-routrarna (där ExpressRoute-kretsar avslutas på den lokala sidan) för att föredra en ExpressRoute-krets. Lösningen illustreras i följande diagram.

Scenario 2

Scenario 2 illustreras i följande diagram. I diagrammet indikerar gröna linjer sökvägar för trafikflöde mellan VNet1 och lokala nätverk. De blå linjerna indikerar vägar för trafikflöde mellan VNet2 och lokala nätverk. I stabilt läge (heldragna linjer i diagrammet) flödar all trafik mellan virtuella nätverk och lokala platser via Microsoft stamnät för den mesta delen, och flödar genom samtrafik mellan lokala platser endast i felläget (prickade linjer i diagrammet) för en ExpressRoute.

![1.9]

Lösningen illustreras i följande diagram. Som det illustreras kan du skapa scenariot med hjälp av en mer speciell väg (alternativ 1) eller som lägga (alternativ 2) för att påverka val av VNet-sökväg. Om du vill påverka det lokala nätverks vägs valet för Azure-Bound, måste du konfigurera sammanlänkningen mellan den lokala platsen så att den blir mindre prioriterad. Howe du konfigurerar länken mellan anslutning som helst beror på routningsprotokollet som används i det lokala nätverket. Du kan använda lokal inställning med iBGP eller Metric med IGP (OSPF eller är-är).

Nästa steg

I den här artikeln diskuterade vi hur du utformar för haveri beredskap för en privat peering-anslutning i ExpressRoute-kretsen. Följande artiklar behandlar haveri beredskap från program och åtkomst till klient åtkomst perspektiv:

• Haveriberedskap i företagsskala
• SMB-haveriberedskap med Azure Site Recovery