IP-adressen behouden tijdens een failover

Azure Site Recovery maakt herstel na noodgevallen mogelijk voor Azure-VM's door VM's te repliceren naar een andere Azure-regio, een failover-overschakeling als er een storing optreedt en een failback naar de primaire regio wanneer de zaken weer normaal zijn.

Tijdens een failover wilt u mogelijk de IP-adressering in de doelregio identiek houden aan de bronregio:

• Wanneer u herstel na noodgevallen inschakelt voor Azure-VM's, maakt Site Recovery standaard doelresources op basis van bronresource-instellingen. Voor Azure-VM's die zijn geconfigureerd met statische IP-adressen, probeert Site Recovery hetzelfde IP-adres in te richten voor de doel-VM, als deze niet in gebruik is. Lees dit artikel voor een volledige uitleg over hoe Site Recovery omgaat met adressering.
• Voor eenvoudige toepassingen is de standaardconfiguratie voldoende. Voor complexere apps moet u mogelijk extra resources inrichten om ervoor te zorgen dat de connectiviteit werkt zoals verwacht na een failover.

Dit artikel bevat enkele voorbeelden voor het behouden van IP-adressen in complexere voorbeeldscenario's. Voorbeelden hiervan zijn:

• Failover voor een bedrijf met alle resources die worden uitgevoerd in Azure
• Failover voor een bedrijf met een hybride implementatie en resources die zowel on-premises als in Azure worden uitgevoerd

Resources in Azure: volledige failover

Bedrijf A heeft alle apps die worden uitgevoerd in Azure.

Vóór failover

Dit is de architectuur vóór failover.

• Bedrijf A heeft identieke netwerken en subnetten in azure-bron- en doelregio's.
• Om de beoogde hersteltijd (RTO) te verminderen, gebruikt het bedrijf replicaknooppunten voor SQL Server AlwaysOn, domeincontrollers, enzovoort. Deze replicaknooppunten bevinden zich in een ander VNet in de doelregio, zodat ze vpn-site-naar-site-connectiviteit tussen de bron- en doelregio's tot stand kunnen brengen. Dit is niet mogelijk als dezelfde IP-adresruimte wordt gebruikt in de bron en het doel.
• Vóór failover is de netwerkarchitectuur als volgt:
  • Primaire regio is Azure - Oost-Azië
    • Azië - oost heeft een VNet (bron-VNet) met adresruimte 10.1.0.0/16.
    • Azië - oost heeft workloads verdeeld over drie subnetten in het VNet:
      • Subnet 1: 10.1.1.0/24
      • Subnet 2: 10.1.2.0/24
      • Subnet 3: 10.1.3.0/24
  • Secundaire (doel)regio is Azure - zuidoost
    • Azië - zuidoost heeft een herstel-VNet (herstel-VNet) dat identiek is aan het bron-VNet.
    • Azië - zuidoost heeft een extra VNet (Azure VNet) met adresruimte 10.2.0.0/16.
    • Azure VNet bevat een subnet (subnet 4) met adresruimte 10.2.4.0/24.
    • Replicaknooppunten voor SQL Server AlwaysOn, domeincontroller enzovoort bevinden zich in Subnet 4.
  • Bron-VNet en Azure VNet zijn verbonden met een VPN-site-naar-site-verbinding.
  • Het herstel-VNet is niet verbonden met een ander virtueel netwerk.
  • Bedrijf A wijst doel-IP-adressen toe/verifieert deze voor gerepliceerde items. Het doel-IP-adres is hetzelfde als het bron-IP-adres voor elke VM.

Na failover

Als er een regionale bronstoring optreedt, kan bedrijf A een failover uitvoeren voor alle resources naar de doelregio.

• Met doel-IP-adressen die al aanwezig waren vóór de failover, kan bedrijf A failover organiseren en automatisch verbindingen tot stand brengen na failover tussen herstel-VNet en Azure VNet. Dit wordt geïllustreerd in het volgende diagram.
• Afhankelijk van de app-vereisten kunnen verbindingen tussen de twee VNets (herstel-VNet en Azure VNet) in de doelregio tot stand worden gebracht vóór, tijdens (als tussenstap) of na de failover.

  • Het bedrijf kan herstelplannen gebruiken om op te geven wanneer verbindingen tot stand worden gebracht.

  • Ze kunnen verbinding maken tussen de VNets met behulp van VNet-peering of site-naar-site-VPN.

    • Bij VNET-peering wordt geen VPN-gateway gebruikt en er gelden diverse beperkingen voor.
    • De prijzen van VNet-peering worden anders berekend dan de prijzen van VNet-naar-VNet VPN Gateway. Voor failovers raden we over het algemeen aan om dezelfde connectiviteitsmethode te gebruiken als bronnetwerken, inclusief het verbindingstype, om onvoorspelbare netwerkincidenten te minimaliseren.

    

Resources in Azure: geïsoleerde app-failover

Mogelijk moet u een failover uitvoeren op app-niveau. Bijvoorbeeld om een failover uit te voeren voor een specifieke app of app-laag die zich in een toegewezen subnet bevindt.

• In dit scenario kunt u IP-adressering behouden, maar dit is over het algemeen niet raadzaam, omdat dit de kans op inconsistenties in de connectiviteit vergroot. U verliest ook de subnetconnectiviteit met andere subnetten binnen hetzelfde Azure-VNet.
• Een betere manier om app-failover op subnetniveau uit te voeren, is door verschillende doel-IP-adressen te gebruiken voor failover (als u verbinding met andere subnetten op het bron-VNet nodig hebt), of om elke app te isoleren in een eigen toegewezen VNet in de bronregio. Met de laatste benadering kunt u connectiviteit tot stand brengen tussen netwerken in de bronregio en hetzelfde gedrag emuleren wanneer u een failover uitvoert naar de doelregio.

In dit voorbeeld plaatst bedrijf A apps in de bronregio in toegewezen VNets en wordt de verbinding tussen deze VNets tot stand gebracht. Met dit ontwerp kunnen ze geïsoleerde failover van apps uitvoeren en de privé-IP-adressen van de bron in het doelnetwerk behouden.

Vóór failover

Vóór een failover ziet de architectuur er als volgt uit:

• Toepassings-VM's worden gehost in de primaire regio Azië - oost:

  • App1 VM's bevinden zich in VNet Source VNet 1: 10.1.0.0/16.
  • App2 VM's bevinden zich in VNet Source VNet 2: 10.2.0.0/16.
  • Bron-VNet 1 heeft twee subnetten.
  • Bron-VNet 2 heeft twee subnetten.

• Secundaire (doel)regio is Azure Azië - zuidoost. Azië - zuidoost heeft een herstel-VNet (herstel-VNet 1 en herstel-VNet 2) die identiek zijn aan bron-VNet 1 en bron-VNet 2. - Herstel VNet 1 en Herstel VNet 2 hebben elk twee subnetten die overeenkomen met de subnetten in bron-VNet 1 en bron-VNet 2 . Azië - zuidoost heeft een extra VNet (Azure VNet) met adresruimte 10.3.0.0/16. - Azure VNet bevat een subnet (subnet 4) met adresruimte 10.3.4.0/24. - Replicaknooppunten voor SQL Server AlwaysOn, domeincontroller enzovoort bevinden zich in Subnet 4.

• Er zijn een aantal site-naar-site-VPN-verbindingen:

  • Bron-VNet 1 en Azure VNet
  • Bron-VNet 2 en Azure VNet
  • Bron-VNet 1 en Bron-VNet 2 zijn verbonden met VPN-site-naar-site

• Herstel VNet 1 en Herstel VNet 2 zijn niet verbonden met andere VNets.

• Bedrijf A configureert VPN-gateways op Herstel VNet 1 en Herstel VNet 2 om RTO te verminderen.

• Herstel VNet1 en Herstel VNet2 zijn niet verbonden met een ander virtueel netwerk.

• Om de beoogde hersteltijd (RTO) te verminderen, worden VPN-gateways geconfigureerd op Herstel VNet1 en Herstel VNet2 voorafgaand aan de failover.

  

Na failover

In het geval van een storing of probleem dat van invloed is op één app (in **Bron-VNet 2 in ons voorbeeld), kan bedrijf A de betrokken app als volgt herstellen:

• Verbreek DE VPN-verbindingen tussen bron-VNet1 en bron-VNet2 en tussen bron-VNet2 en Azure VNet .
• Vpn-verbindingen tot stand brengen tussen bron-VNet1 en herstel-VNet2 en tussen Herstel VNet2 en Azure VNet.
• Failover van VM's in bron-VNet2 naar herstel VNet2.

• Dit voorbeeld kan worden uitgebreid met meer toepassingen en netwerkverbindingen. Het wordt aanbevolen om zoveel mogelijk een vergelijkbaar verbindingsmodel te volgen bij het uitvoeren van een failover van bron naar doel.
• VPN-gateways maken gebruik van openbare IP-adressen en gatewayhops om verbindingen tot stand te brengen. Als u geen openbare IP-adressen wilt gebruiken of als u extra hops wilt vermijden, kunt u Azure VNet-peering gebruiken om virtuele netwerken te peeren tussen ondersteunde Azure-regio's.

Hybride resources: volledige failover

In dit scenario voert bedrijf B een hybride bedrijf uit, waarbij een deel van de toepassingsinfrastructuur wordt uitgevoerd in Azure en de rest on-premises.

Vóór failover

Hier ziet u hoe de netwerkarchitectuur eruitziet vóór failover.

• Toepassings-VM's worden gehost in Azure - Oost-Azië.
• Azië - oost heeft een VNet (bron-VNet) met adresruimte 10.1.0.0/16.
  • Azië - oost heeft workloads verdeeld over drie subnetten in het bron-VNet:
    • Subnet 1: 10.1.1.0/24
    • Subnet 2: 10.1.2.0/24
    • Subnet 3: 10.1.3.0/24, met behulp van een virtueel Azure-netwerk met adresruimte 10.1.0.0/16. Dit virtuele netwerk heet bron-VNet
• De secundaire (doel)regio is Azure - zuidoost:
  • Azië - zuidoost heeft een herstel-VNet (herstel-VNet) dat identiek is aan het bron-VNet.
• VM's in Oost-Azië zijn verbonden met een on-premises datacenter met Behulp van Azure ExpressRoute of site-naar-site-VPN.
• Om de RTO te verminderen, richt bedrijf B gateways in op herstel-VNet in Azure - zuidoost azië voorafgaand aan de failover.
• Bedrijf B wijst doel-IP-adressen toe voor gerepliceerde VM's of verifieert deze. Het doel-IP-adres is hetzelfde als het BRON-IP-adres voor elke VM.

Na failover

Als er een regionale bronstoring optreedt, kan bedrijf B een failover uitvoeren voor alle resources naar de doelregio.

• Met doel-IP-adressen die al aanwezig waren vóór de failover, kan bedrijf B failover organiseren en automatisch verbindingen tot stand brengen na failover tussen herstel-VNet en Azure VNet.
• Afhankelijk van de app-vereisten kunnen verbindingen tussen de twee VNets (herstel-VNet en Azure VNet) in de doelregio tot stand worden gebracht vóór, tijdens (als tussenstap) of na de failover. Het bedrijf kan herstelplannen gebruiken om op te geven wanneer verbindingen tot stand worden gebracht.
• De oorspronkelijke verbinding tussen Azure - Azië - oost en het on-premises datacenter moet worden verbroken voordat de verbinding tussen Azure - zuidoost Azië en het on-premises datacenter tot stand wordt gebracht.
• De on-premises routering wordt na de failover opnieuw geconfigureerd om te verwijzen naar de doelregio en gateways.

Hybride resources: geïsoleerde app-failover

Bedrijf B kan geen failover uitvoeren voor geïsoleerde apps op subnetniveau. Dit komt doordat de adresruimte op bron- en herstel-VNets hetzelfde is en de oorspronkelijke bron-naar-on-premises verbinding actief is.

• Voor app-tolerantie moet bedrijf B elke app in een eigen toegewezen Azure-VNet plaatsen.
• Met elke app in een afzonderlijk VNet kan bedrijf B een failover uitvoeren voor geïsoleerde apps en bronverbindingen routeren naar de doelregio.

Volgende stappen

Meer informatie over herstelplannen.