Dela via

Integrera ExpressRoute med haveriberedskap för virtuella Azure-datorer

  • Artikel

Den här artikeln beskriver hur du integrerar Azure ExpressRoute med Azure Site Recovery när du konfigurerar haveriberedskap för virtuella Azure-datorer i en sekundär Azure-region.

Site Recovery möjliggör haveriberedskap för virtuella Azure-datorer genom att replikera data från virtuella Azure-datorer till Azure.

  • Om virtuella Azure-datorer använder Azure-hanterade diskar replikeras data för virtuella datorer till en replikerad hanterad disk i den sekundära regionen.
  • Om virtuella Azure-datorer inte använder hanterade diskar replikeras data från virtuella datorer till ett Azure-lagringskonto.
  • Replikeringsslutpunkter är offentliga, men replikeringstrafiken för virtuella Azure-datorer går inte över Internet.

Med ExpressRoute kan du utöka lokala nätverk till Microsoft Azure-molnet via en privat anslutning, vilket underlättas av en anslutningsleverantör. Om du har konfigurerat ExpressRoute integreras det med Site Recovery på följande sätt:

  • Under replikering mellan Azure-regioner: Replikeringstrafiken för haveriberedskap för virtuella Azure-datorer finns endast i Azure och ExpressRoute behövs inte eller används inte för replikering. Men om du ansluter från en lokal plats till de virtuella Azure-datorerna på den primära Azure-platsen finns det många problem att känna till när du konfigurerar haveriberedskap för de virtuella Azure-datorerna.
  • Redundansväxling mellan Azure-regioner: När avbrott inträffar redundansväxlar du virtuella Azure-datorer från den primära till den sekundära Azure-regionen. När du har växlat över till en sekundär region finns det många steg att vidta för att få åtkomst till de virtuella Azure-datorerna i den sekundära regionen med Hjälp av ExpressRoute.

Innan du börjar

Innan du börjar bör du se till att du förstår följande begrepp:

Allmänna rekommendationer

För bästa praxis och för att säkerställa effektiva mål för återställningstid (RTO) för haveriberedskap rekommenderar vi att du gör följande när du konfigurerar Site Recovery för att integrera med ExpressRoute:

  • Etablera nätverkskomponenter före redundansväxling till en sekundär region:
    • När du aktiverar replikering för virtuella Azure-datorer kan Site Recovery automatiskt distribuera nätverksresurser med hjälp av källnätverksinställningarna. Till exempel nätverk, undernät och gatewayer i azure-målregionen.
    • Site Recovery kan inte konfigurera nätverksresurser automatiskt, till exempel VNet-gatewayer.
    • Vi rekommenderar att du etablerar dessa extra nätverksresurser före redundansväxlingen. En liten stilleståndstid är associerad med den här distributionen och kan påverka den totala återställningstiden om du inte tog hänsyn till den under distributionsplaneringen.
  • Kör regelbundna haveriberedskapstest:
    • Testet verifierar din replikeringsstrategi utan dataförlust eller driftstopp och påverkar inte din produktionsmiljö. Det hjälper till att undvika konfigurationsproblem i sista minuten som kan påverka RTO negativt.
    • När du kör ett redundanstest för detaljnivån rekommenderar vi att du använder ett separat virtuellt Azure-datornätverk i stället för standardnätverket som konfigurerats under replikeringen.
  • Använd olika IP-adressutrymmen om du har en enda ExpressRoute-krets.
    • Vi rekommenderar att du använder ett annat IP-adressutrymme för det virtuella målnätverket. Detta undviker problem när anslutningar upprättas under regionala avbrott.
    • Om du inte kan använda ett separat adressutrymme måste du köra redundanstesttestet för haveriberedskap i ett separat testnätverk med olika IP-adresser. Du kan inte ansluta två virtuella nätverk med överlappande IP-adressutrymme till samma ExpressRoute-krets.

Replikera virtuella Azure-datorer när du använder ExpressRoute

Om du vill konfigurera replikering för virtuella Azure-datorer på en primär plats och du ansluter till dessa virtuella datorer från din lokala plats via ExpressRoute måste du göra följande:

  1. Aktivera replikering för varje virtuell Azure-dator.
  2. Du kan också låta Site Recovery konfigurera nätverk:
    • När du konfigurerar och aktiverar replikering konfigurerar Site Recovery nätverk, undernät och gateway-undernät i azure-målregionen för att matcha dem i källregionen. Site Recovery mappar även mellan de virtuella källnätverken och målnätverken.
    • Om du inte vill att Site Recovery ska göra detta automatiskt skapar du nätverksresurserna på målsidan innan du aktiverar replikering.
  3. Skapa andra nätverkselement:
    • Site Recovery skapar inte routningstabeller, VNet-gatewayer, VNet-gatewayanslutningar, VNet-peering eller andra nätverksresurser och anslutningar i den sekundära regionen.
    • Du måste skapa dessa extra nätverkselement i den sekundära regionen när som helst innan du kör en redundansväxling från den primära regionen.
    • Du kan använda återställningsplaner och automatiseringsskript för att konfigurera och ansluta dessa nätverksresurser.
  4. Om du har en virtuell nätverksinstallation (NVA) distribuerad för att styra flödet av nätverkstrafik:
    • Azures standardsystemväg för replikering av virtuella Azure-datorer är 0.0.0.0/0.
    • Vanligtvis definierar NVA-distributioner också en standardväg (0.0.0.0/0) som tvingar utgående Internettrafik att flöda genom NVA. Standardvägen används när ingen annan specifik vägkonfiguration kan hittas.
    • I så fall kan NVA överbelastas om all replikeringstrafik passerar genom NVA.
    • Samma begränsning gäller även när du använder standardvägar för att dirigera all trafik för virtuella Azure-datorer till lokala distributioner.
    • I det här scenariot rekommenderar vi att du skapar en slutpunkt för nätverkstjänsten i ditt virtuella nätverk för Microsoft.Storage-tjänsten, så att replikeringstrafiken inte lämnar Azure-gränsen.

Replikeringsexempel

I vanliga företagsdistributioner distribueras arbetsbelastningar över flera virtuella Azure-nätverk med en central hubb för internet och lokal anslutning. Den här konfigurationen använder ofta en topologi med nav och eker med ExpressRoute.

Lokalt till Azure med ExpressRoute före redundansväxling

  • Region. Appar distribueras i Azure East Asia-regionen.
  • Virtuella ekernätverk. Appar distribueras i två virtuella ekernätverk:
    • Källa vNet1: 10.1.0.0/24.
    • Käll-vNet2: 10.2.0.0/24.
    • Varje virtuellt ekernätverk är anslutet till det virtuella hubbnätverket.
  • Hubb-vNet. Det finns ett virtuellt hubbnätverk för hubb för nav: 10.10.10.0/24.
    • Det här virtuella hubbnätverket fungerar som gatekeeper.
    • All kommunikation mellan undernät går via den här hubben.
      • Hubb-vNet-undernät. Det virtuella hubbnätverket har två undernät:
      • NVA-undernät: 10.10.10.0/25. Det här undernätet innehåller en NVA (10.10.10.10).
      • Gateway-undernät: 10.10.10.128/25. Det här undernätet innehåller en ExpressRoute-gateway som är ansluten till en ExpressRoute-anslutning som dirigerar till den lokala platsen via en privat peering-routningsdomän.
  • Det lokala datacentret har en ExpressRoute-kretsanslutning via en partner edge i Hong Kong Special Administrative Region.
  • All routning styrs via Azure-routningstabeller (UDR).
  • All utgående trafik mellan virtuella nätverk eller till det lokala datacentret dirigeras via NVA.

Inställningar för hubb- och ekerpeering

Spoke till hub

Riktning Inställning Delstat
Spoke till hub Tillåt virtuell nätverksadress Aktiverat
Spoke till hub Tillåt vidarebefordrad trafik Aktiverat
Spoke till hub Tillåt gatewayöverföring Inaktiverad
Spoke till hub Använda ta bort gatewayer Aktiverat

Konfiguration av peering för ekrar till hubb

Hub till spoke

Riktning Inställning Delstat
Hub till spoke Tillåt virtuell nätverksadress Aktiverat
Hub till spoke Tillåt vidarebefordrad trafik Aktiverat
Hub till spoke Tillåt gatewayöverföring Aktiverat
Hub till spoke Använda ta bort gatewayer Inaktiverad

Konfiguration av peering mellan nav och eker

Exempelsteg

I vårt exempel bör följande inträffa när du aktiverar replikering för virtuella Azure-datorer i källnätverket:

  1. Du aktiverar replikering för en virtuell dator.
  2. Site Recovery skapar replik-vNet, undernät och gateway-undernät i målregionen.
  3. Site Recovery skapar mappningar mellan källnätverken och de replikmålnätverk som skapas.
  4. Du skapar virtuella nätverksgatewayer manuellt, anslutningar för virtuell nätverksgateway, peering för virtuella nätverk eller andra nätverksresurser eller anslutningar.

Redundansvämna virtuella Azure-datorer när du använder ExpressRoute

När du har redundansväxla virtuella Azure-datorer till azure-målregionen med hjälp av Site Recovery kan du komma åt dem med hjälp av expressroute-privat peering.

  • Du måste ansluta ExpressRoute till det virtuella målnätverket med en ny anslutning. Den befintliga ExpressRoute-anslutningen överförs inte automatiskt.
  • Hur du konfigurerar din ExpressRoute-anslutning till det virtuella målnätverket beror på din ExpressRoute-topologi.

Åtkomst med två kretsar

Två kretsar med två peeringplatser

Den här konfigurationen hjälper till att skydda ExpressRoute-kretsar mot regionala katastrofer. Om din primära peeringplats slutar fungera kan anslutningarna fortsätta från den andra platsen.

  • Kretsen som är ansluten till produktionsmiljön är vanligtvis den primära. Den sekundära kretsen har vanligtvis lägre bandbredd, vilket kan ökas om en katastrof inträffar.
  • Efter redundansväxlingen kan du upprätta anslutningar från den sekundära ExpressRoute-kretsen till det virtuella målnätverket. Du kan också ha anslutningar konfigurerade och klara vid haveri, för att minska den totala återställningstiden.
  • Med samtidiga anslutningar till både primära och virtuella målnätverk kontrollerar du att din lokala routning endast använder den sekundära kretsen och anslutningen efter redundansväxlingen.
  • De virtuella käll- och målnätverken kan ta emot nya IP-adresser eller behålla samma efter redundansväxlingen. I båda fallen kan de sekundära anslutningarna upprättas före redundansväxling.

Två kretsar med en enda peeringplats

Den här konfigurationen hjälper till att skydda mot fel i den primära ExpressRoute-kretsen, men inte om den enskilda ExpressRoute-peeringplatsen slutar fungera, vilket påverkar båda kretsarna.

  • Du kan ha samtidiga anslutningar från det lokala datacentret för att hämta vNEt med den primära kretsen och till det virtuella målnätverket med den sekundära kretsen.
  • Med samtidiga anslutningar till primär och mål kontrollerar du att lokal routning endast använder den sekundära kretsen och anslutningen efter redundansväxling.
  • Du kan inte ansluta båda kretsarna till samma virtuella nätverk när kretsar skapas på samma peeringplats.

Åtkomst med en enda krets

I den här konfigurationen finns det bara en Expressroute-krets. Även om kretsen har en redundant anslutning om en går ner, ger en enda routningskrets inte motståndskraft om din peering-region går ner. Tänk på följande:

  • Om azure-målregionen inte finns på samma plats som källan måste du aktivera ExpressRoute Premium om du använder en enda ExpressRoute-krets. Lär dig mer om ExpressRoute-platser och ExpressRoute-priser.
  • Du kan inte ansluta virtuella käll- och målnätverk samtidigt till kretsen om samma IP-adressutrymme används i målregionen. I det här scenariot:
    • Koppla från anslutningen på källsidan och upprätta sedan målsidans anslutning. Den här anslutningsändringen kan skriptas som en del av en Site Recovery-återställningsplan. Observera att:
      • Om den primära regionen inte är tillgänglig i ett regionalt fel kan frånkopplingsåtgärden misslyckas. Detta kan påverka skapandet av anslutningar till målregionen.
      • Om du har skapat anslutningen i målregionen och den primära regionen återställs senare kan det uppstå paketförluster om två samtidiga anslutningar försöker ansluta till samma adressutrymme.
      • Om du vill förhindra detta avslutar du den primära anslutningen omedelbart.
      • När den virtuella datorn har återställts till den primära regionen kan den primära anslutningen upprättas igen när du har kopplat från den sekundära anslutningen.
  • Om ett annat adressutrymme används på det virtuella målnätverket kan du samtidigt ansluta till de virtuella käll- och målnätverken från samma ExpressRoute-krets.

Redundansexempel

I vårt exempel använder vi följande topologi:

  • Två olika ExpressRoute-kretsar på två olika peeringplatser.
  • Behåll privata IP-adresser för de virtuella Azure-datorerna efter redundansväxlingen.
  • Målåterställningsregionen är Azure SouthEast Asia.
  • En sekundär ExpressRoute-kretsanslutning upprättas via en partner edge i Singapore.

En enkel topologi som använder en enskild ExpressRoute-krets, med samma IP-adress efter redundansväxling, finns i den här artikeln.

Exempelsteg

För att automatisera återställningen i det här exemplet behöver du göra följande:

  1. Följ stegen för att konfigurera replikering.

  2. Redundansväxla de virtuella Azure-datorerna med dessa extra steg under eller efter redundansväxlingen.

    a. Skapa Azure ExpressRoute Gateway i det virtuella målregionhubbens virtuella nätverk. Detta måste ansluta målhubbens virtuella nätverk till ExpressRoute-kretsen.

    b. Skapa anslutningen från målhubbens virtuella nätverk till ExpressRoute-målkretsen.

    c. Konfigurera VNet-peeringarna mellan målregionens virtuella nav- och ekernätverk. Peeringegenskaperna i målregionen är desamma som i källregionen.

    d. Konfigurera UDR:erna i det virtuella hubbnätverket och de två virtuella ekernätverken.

    • Egenskaperna för målsidans UDR:er är desamma som på källsidan när samma IP-adresser används.
    • Med olika MÅL-IP-adresser bör UDR ändras i enlighet med detta.

Stegen ovan kan skriptas som en del av en återställningsplan. Beroende på kraven på programanslutning och återställningstid kan ovanstående steg också slutföras innan redundansväxlingen påbörjas.

Efter återställning

När du har återställt de virtuella datorerna och slutfört anslutningen är återställningsmiljön följande.

Lokalt till Azure med ExpressRoute efter redundansväxling

Nästa steg

Läs mer om hur du använder återställningsplaner för att automatisera programredundans.