Behålla IP-adresser vid redundans

Azure Site Recovery möjliggör haveriberedskap för virtuella Azure-datorer genom replikering av virtuella datorer till en annan Azure-region, redundansväxling vid ett avbrott och återställning till den primära regionen när det är normalt 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ällningarna. 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:

• Redundans 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

Anteckning

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 inom sin kontinent.

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

• Företag A har identiska nätverk och undernät i Azure-käll- och målregioner.
• 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:
  • Den primära regionen ä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-adressen för varje virtuell dator.

Efter redundansväxling

Om ett regionalt källfel 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 orkestrera 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å appkraven 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 annorlunda än prissättningen för VNet-till-VNet VPN Gateway. Vid redundansväxling rekommenderar vi vanligtvis att du använder samma anslutningsmetod som källnätverk, inklusive anslutningstyp, för att minimera oförutsägbara nätverksincidenter.

    

Resurser i Azure: redundans för isolerad app

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.

• Även om du kan behålla IP-adresser i det här scenariot är det vanligtvis inte lämpligt eftersom det ökar risken för inkonsekvenser i anslutningen. Du förlorar också 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 redundansväxling (om du behöver anslutning till andra undernät i det virtuella källnätverket) eller att isolera varje app i ett eget dedikerat virtuellt nätverk i källregionen. Med den senare metoden kan du upprätta en anslutning 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 en 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äxlingen:

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

  • App1 Virtuella datorer finns i VNet Source VNet 1: 10.1.0.0/16.
  • App2 Virtuella datorer finns i VNet Source VNet 2: 10.2.0.0/16.
  • Det virtuella källnätverket 1 har två undernät.
  • Det virtuella källnätverket 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 1 för källa och virtuellt källnätverk 2. - Recovery VNet 1 och Recovery VNet 2 har två undernät som matchar undernäten i Det virtuella källnätverket 1 och det virtuella källnätverket 2 – Sydostasien har ytterligare ett virtuellt nätverk (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 för 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 med 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 **Source 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 VNet2-källa och mellan VNet2-källa och virtuellt Azure-nätverk .
• 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ällning VNet2.

• Det här exemplet kan utökas till att omfatta fler program och nätverksanslutningar. Rekommendationen är att så långt det är möjligt följa en liknande anslutningsmodell vid redväxling 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-kopplade virtuella nätverk i Azure-regioner som stöds.

Hybridresurser: fullständig redundans

I det här scenariot kör företag B en hybridverksamhet, 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 adressutrymme 10.1.0.0/16. Det här virtuella nätverket heter VNet-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 regionalt källfel 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 orkestrera 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 appredundans

Företag B kan inte redundansväxla isolerade appar på undernätsnivå. Det beror på att adressutrymmet på käll- och återställnings-VNet är detsamma och 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.