Behålla IP-adresser vid redundans

Azure Site Recovery möjliggör haveriberedskap för virtuella Azure-datorer genom att replikera virtuella datorer till en annan Azure-region, redundansväxa om ett avbrott inträffar och återställa till den primära regionen när det är som vanligt igen.

Under redundansväxlingen kanske du vill att IP-adresserna i målregionen ska vara identiska med källregionen:

• När du aktiverar haveriberedskap för virtuella Azure-datorer skapar Site Recovery som standard målresurser baserat på källresursinställningar. För virtuella Azure-datorer som konfigurerats med statiska IP-adresser försöker Site Recovery etablera samma IP-adress för den virtuella måldatorn, om den inte används. En fullständig förklaring av hur Site Recovery hanterar adressering finns i den här artikeln.
• För enkla program räcker standardkonfigurationen. För mer komplexa appar kan du behöva etablera ytterligare resurser för att se till att anslutningen fungerar som förväntat efter redundansväxlingen.

Den här artikeln innehåller några exempel på hur du behåller IP-adresser i mer komplexa exempelscenarier. Exemplen är:

• Redundansväxling för ett företag med alla resurser som körs i Azure
• Redundansväxling för ett företag med en hybriddistribution och resurser som körs både lokalt och i Azure

Resurser i Azure: fullständig redundans

Företag A har alla sina appar som körs i Azure.

Före redundansväxling

Kommentar

Replikering kan nu göras mellan två Azure-regioner runt om i världen. Kunderna är inte längre begränsade till att aktivera replikering på sin kontinent.

Här är arkitekturen före redundansväxling.

• Företag A har identiska nätverk och undernät i käll- och målregioner i Azure.
• För att minska målet för återställningstid (RTO) använder företaget repliknoder för SQL Server AlwaysOn, domänkontrollanter osv. Dessa repliknoder finns i ett annat virtuellt nätverk i målregionen, så att de kan upprätta VPN-plats-till-plats-anslutning mellan käll- och målregionerna. Detta är inte möjligt om samma IP-adressutrymme används i källan och målet.
• Före redundansväxlingen är nätverksarkitekturen följande:
  • Primär region är Azure East Asia
    • Asien, östra har ett VNet (käll-VNet) med adressutrymmet 10.1.0.0/16.
    • Asien, östra har arbetsbelastningar fördelade på tre undernät i det virtuella nätverket:
      • Undernät 1: 10.1.1.0/24
      • Undernät 2: 10.1.2.0/24
      • Undernät 3: 10.1.3.0/24
  • Sekundär region (mål) är Azure Sydostasien
    • Sydostasien har ett återställnings-VNet (Recovery VNet) som är identiskt med det virtuella källnätverket.
    • Sydostasien har ytterligare ett virtuellt nätverk (Azure VNet) med adressutrymmet 10.2.0.0/16.
    • Azure VNet innehåller ett undernät (undernät 4) med adressutrymmet 10.2.4.0/24.
    • Repliknoder för SQL Server AlwaysOn, domänkontrollant osv. finns i undernät 4.
  • Det virtuella källnätverket och det virtuella Azure-nätverket är anslutna med en VPN-plats-till-plats-anslutning.
  • Det virtuella återställningsnätverket är inte anslutet till något annat virtuellt nätverk.
  • Företag A tilldelar/verifierar mål-IP-adresser för replikerade objekt. Mål-IP-adressen är samma som käll-IP för varje virtuell dator.

Efter redundansväxling

Om ett källregionalt avbrott inträffar kan företag A redundansväxla alla sina resurser till målregionen.

• Med mål-IP-adresser redan på plats före redundansväxlingen kan företag A samordna redundans och automatiskt upprätta anslutningar efter redundansväxling mellan det virtuella återställningsnätverket och det virtuella Azure-nätverket. Detta illustreras i följande diagram..
• Beroende på appkrav kan anslutningar mellan de två virtuella nätverken (Recovery VNet och Azure VNet) i målregionen upprättas före, under (som ett mellanliggande steg) eller efter redundansväxlingen.

  • Företaget kan använda återställningsplaner för att ange när anslutningar ska upprättas.

  • De kan ansluta mellan de virtuella nätverken med VNet-peering eller plats-till-plats-VPN.

    • VNET-peering använder ingen VPN-gateway och har även andra restriktioner.
    • Prissättningen för VNet-peering beräknas på ett annat sätt än prissättningen för VPN Gateway för VNet-till-VNet. Vid redundansväxling rekommenderar vi vanligtvis att du använder samma anslutningsmetod som källnätverk, inklusive anslutningstypen, för att minimera oförutsägbara nätverksincidenter.

    

Resurser i Azure: isolerad app-redundans

Du kan behöva redundansväxla på appnivå. Till exempel för att redundansväxla en specifik app- eller appnivå som finns i ett dedikerat undernät.

• I det här scenariot, även om du kan behålla IP-adresser, är det vanligtvis inte tillrådligt eftersom det ökar risken för inkonsekvenser i anslutningen. Du förlorar även undernätsanslutningen till andra undernät i samma virtuella Azure-nätverk.
• Ett bättre sätt att redundansväxling på undernätsnivå är att använda olika mål-IP-adresser för redundans (om du behöver anslutning till andra undernät på det virtuella källnätverket) eller att isolera varje app i sitt eget dedikerade virtuella nätverk i källregionen. Med den senare metoden kan du upprätta anslutningar mellan nätverk i källregionen och emulera samma beteende när du redundansväxlar till målregionen.

I det här exemplet placerar Företag A appar i källregionen i dedikerade virtuella nätverk och upprättar anslutning mellan dessa virtuella nätverk. Med den här designen kan de utföra isolerad appredundans och behålla källans privata IP-adresser i målnätverket.

Före redundansväxling

Arkitekturen är följande före redundansväxling:

• Virtuella programdatorer finns i den primära Azure East Asia-regionen:

  • Virtuella App1-datorer finns i VNet Source VNet 1: 10.1.0.0/16.
  • Virtuella App2-datorer finns i VNet Source VNet 2: 10.2.0.0/16.
  • Käll-VNet 1 har två undernät.
  • Käll-VNet 2 har två undernät.

• Sekundär region (mål) är Azure Sydostasien – Sydostasien har ett återställnings-VNet (Recovery VNet 1 och Recovery VNet 2) som är identiska med VNet-källnätverket 1 och VNet-källa 2. - Recovery VNet 1 och Recovery VNet 2 har vart och ett två undernät som matchar undernäten i VNet-källnätverket 1 och VNet för källa 2 – Sydostasien har ytterligare ett VNet (Azure VNet) med adressutrymmet 10.3.0.0/16. - Azure VNet innehåller ett undernät (undernät 4) med adressutrymmet 10.3.4.0/24. – Repliknoder för SQL Server AlwaysOn, domänkontrollant osv. finns i undernät 4.

• Det finns ett antal VPN-anslutningar från plats till plats:

  • VNet 1-källa och virtuellt Azure-nätverk
  • VNet 2-källa och virtuellt Azure-nätverk
  • Käll-VNet 1 och VNet 2 för källa är anslutna till VPN plats-till-plats

• Recovery VNet 1 och Recovery VNet 2 är inte anslutna till andra virtuella nätverk.

• Företag A konfigurerar VPN-gatewayer på Recovery VNet 1 och Recovery VNet 2 för att minska RTO.

• Recovery VNet1 och Recovery VNet2 är inte anslutna till något annat virtuellt nätverk.

• För att minska målet för återställningstid (RTO) konfigureras VPN-gatewayer på Recovery VNet1 och Recovery VNet2 före redundansväxling.

  

Efter redundansväxling

I händelse av ett avbrott eller problem som påverkar en enskild app (i **Käll-VNet 2 i vårt exempel) kan företag A återställa den berörda appen på följande sätt:

• Koppla från VPN-anslutningar mellan VNet1-källa och käll-VNet2 och mellan VNet2-källa och azure-VNet .
• Upprätta VPN-anslutningar mellan VNet1-källa och återställnings-VNet2 och mellan Recovery VNet2 och Azure VNet.
• Redundansväxla virtuella datorer i VNet2-källa till återställnings-VNet2.

• Det här exemplet kan utökas till att omfatta fler program och nätverksanslutningar. Rekommendationen är att så långt som möjligt följa en liknande anslutningsmodell när du redväxlar från källa till mål.
• VPN-gatewayer använder offentliga IP-adresser och gatewayhopp för att upprätta anslutningar. Om du inte vill använda offentliga IP-adresser, eller om du vill undvika extra hopp, kan du använda Azure VNet-peering till peer-virtuella nätverk i Azure-regioner som stöds.

Hybridresurser: fullständig redundans

I det här scenariot kör företag B ett hybridföretag, där en del av programinfrastrukturen körs i Azure och resten körs lokalt.

Före redundansväxling

Så här ser nätverksarkitekturen ut före redundansväxlingen.

• Virtuella programdatorer finns i Azure East Asia.
• Asien, östra har ett VNet (käll-VNet) med adressutrymmet 10.1.0.0/16.
  • Asien, östra har arbetsbelastningar fördelade på tre undernät i det virtuella källnätverket:
    • Undernät 1: 10.1.1.0/24
    • Undernät 2: 10.1.2.0/24
    • Undernät 3: 10.1.3.0/24 och använder ett virtuellt Azure-nätverk med adressutrymmet 10.1.0.0/16. Det här virtuella nätverket heter VNet för källa
• Den sekundära regionen (mål) är Azure Sydostasien:
  • Sydostasien har ett återställnings-VNet (Recovery VNet) som är identiskt med det virtuella källnätverket.
• Virtuella datorer i Asien, östra är anslutna till ett lokalt datacenter med Azure ExpressRoute eller plats-till-plats-VPN.
• För att minska RTO etablerar företag B gatewayer på återställnings-VNet i Azure Sydostasien före redundansväxling.
• Företag B tilldelar/verifierar mål-IP-adresser för replikerade virtuella datorer. Mål-IP-adressen är samma som källans IP-adress för varje virtuell dator.

Efter redundansväxling

Om ett källregionalt avbrott inträffar kan företag B redundansväxla alla sina resurser till målregionen.

• Med mål-IP-adresser redan på plats före redundansväxlingen kan företag B samordna redundans och automatiskt upprätta anslutningar efter redundansväxling mellan det virtuella återställningsnätverket och det virtuella Azure-nätverket.
• Beroende på appkrav kan anslutningar mellan de två virtuella nätverken (Recovery VNet och Azure VNet) i målregionen upprättas före, under (som ett mellanliggande steg) eller efter redundansväxlingen. Företaget kan använda återställningsplaner för att ange när anslutningar ska upprättas.
• Den ursprungliga anslutningen mellan Azure East Asia och det lokala datacentret bör kopplas från innan anslutningen mellan Azure Sydostasien och det lokala datacentret upprättas.
• Den lokala routningen konfigureras om så att den pekar på målregionen och gatewayerna efter redundansväxlingen.

Hybridresurser: isolerad app-redundans

Företag B kan inte redundansväxla isolerade appar på undernätsnivå. Det beror på att adressutrymmet på de virtuella käll- och återställningsnätverken är detsamma och att den ursprungliga källan till den lokala anslutningen är aktiv.

• För appåterhämtning måste företag B placera varje app i sitt eget dedikerade virtuella Azure-nätverk.
• Med varje app i ett separat virtuellt nätverk kan företag B redundansväxla isolerade appar och dirigera källanslutningar till målregionen.

Nästa steg

Läs mer om återställningsplaner.