Share via

IP-adressen behouden tijdens een failover

  • Artikel

Met Azure Site Recovery kunt u herstel na noodgevallen voor Azure-VM's uitvoeren door VM's te repliceren naar een andere Azure-regio, failover-overschakeling uit te voeren als er een storing optreedt en een failback naar de primaire regio wordt uitgevoerd 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 Virtuele Azure-machines, maakt Site Recovery standaard doelresources op basis van de bronresource-instellingen. Voor Virtuele Azure-machines die zijn geconfigureerd met statische IP-adressen, probeert Site Recovery hetzelfde IP-adres in te richten voor de doel-VM, als deze niet wordt gebruikt. Raadpleeg dit artikel voor een volledige uitleg over hoe Site Recovery de adressering afhandelt.
  • 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. De voorbeelden 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

Notitie

Replicatie kan nu worden uitgevoerd tussen twee Azure-regio's over de hele wereld. Klanten zijn niet langer beperkt tot het inschakelen van replicatie binnen hun continent.

Dit is de architectuur vóór de failover.

  • Bedrijf A heeft identieke netwerken en subnetten in bron- en doelregio's van Azure.
  • 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 een VPN-site-naar-site-verbinding tot stand kunnen brengen tussen de bron- en doelregio's. Dit is niet mogelijk als dezelfde IP-adresruimte wordt gebruikt in de bron en het doel.
  • Voordat de failover wordt uitgevoerd, 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 regio (doel) is Azure - zuidoost Azië
      • 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 site-naar-site-VPN-verbinding.
    • Herstel-VNet is niet verbonden met een ander virtueel netwerk.
    • Bedrijf A wijst doel-IP-adressen toe/verifieert voor gerepliceerde items. Het doel-IP-adres is hetzelfde als het bron-IP-adres voor elke VIRTUELE machine.

Resources in Azure vóór volledige failover

Na failover

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

  • Met ip-doeladressen die al aanwezig zijn vóór de failover, kan bedrijf A failover organiseren en automatisch verbindingen tot stand brengen na een 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 VNet's (Herstel-VNet en Azure VNet) in de doelregio vóór, tijdens (als tussenliggende stap) of na de failover tot stand worden gebracht.

    • 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.
      • Prijzen voor VNet-peering worden anders berekend dan de prijzen van VNet-naar-VNet VPN Gateway. Voor failovers adviseren we over het algemeen om dezelfde connectiviteitsmethode te gebruiken als bronnetwerken, inclusief het verbindingstype, om onvoorspelbare netwerkincidenten te minimaliseren.

      Resources in volledige failover van Azure

Resources in Azure: geïsoleerde app-failover

Mogelijk moet u een failover uitvoeren op app-niveau. Als u bijvoorbeeld een failover wilt uitvoeren voor een specifieke app of app-laag in een toegewezen subnet.

  • In dit scenario, hoewel u IP-adressering kunt behouden, is het over het algemeen niet raadzaam omdat het de kans op inconsistenties in de connectiviteit verhoogt. 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 nodig hebt met andere subnetten op het bron-VNet), of om elke app te isoleren in een eigen toegewezen VNet in de bronregio. Met de laatste benadering kunt u connectiviteit tussen netwerken in de bronregio tot stand brengen en hetzelfde gedrag emuleren wanneer u een failover naar de doelregio uitvoert.

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

Vóór failover

Vóór een failover is de architectuur als volgt:

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

    • App1-VM's bevinden zich in VNet-bron-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 regio (doel) is Azure Zuidoost-Azië - Azië - zuidoost heeft een herstel-VNets (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 Recovery VNet1 en Recovery VNet2 voorafgaand aan de failover.

    Resources in Azure vóór app-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 betreffende 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-VM's in bron-VNet2 naar Herstel VNet2.

Resources in Azure-app-failover

  • Dit voorbeeld kan worden uitgebreid met meer toepassingen en netwerkverbindingen. De aanbeveling is om een vergelijkbaar verbindingsmodel te volgen, voor zover mogelijk, wanneer er een failover van de bron naar het doel wordt uitgevoerd.
  • VPN-gateways gebruiken 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 voorkomen, kunt u Azure VNet-peering gebruiken om virtuele netwerken te koppelen in ondersteunde Azure-regio's.

Hybride resources: volledige failover

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

Vóór failover

Hier ziet u hoe de netwerkarchitectuur eruitziet vóór de 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 bron-VNet:
      • Subnet 1: 10.1.1.0/24
      • Subnet 2: 10.1.2.0/24
      • Subnet 3: 10.1.3.0/24, waarbij gebruik wordt gemaakt van een virtueel Azure-netwerk met adresruimte 10.1.0.0/16. Dit virtuele netwerk heeft de naam Bron-VNet
  • De secundaire regio (doel) is Azure - zuidoost Azië:
    • Azië - zuidoost heeft een herstel-VNet (herstel-VNet) dat identiek is aan het bron-VNet.
  • VM's in Azië - oost zijn verbonden met een on-premises datacenter met Azure ExpressRoute of site-naar-site-VPN.
  • Om RTO te verminderen, richt bedrijf B gateways in op herstel-VNet in Azure - zuidoost Azië vóór de failover.
  • Bedrijf B wijst doel-IP-adressen toe/verifieert voor gerepliceerde VM's. Het doel-IP-adres is hetzelfde als het bron-IP-adres voor elke VIRTUELE machine.

On-premises naar Azure-connectiviteit vóór failover

Na failover

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

  • Met ip-doeladressen die al aanwezig zijn vóór de failover, kan bedrijf B failover organiseren en automatisch verbindingen tot stand brengen na een failover tussen Herstel-VNet en Azure VNet.
  • Afhankelijk van de app-vereisten kunnen verbindingen tussen de twee VNet's (Herstel-VNet en Azure VNet) in de doelregio vóór, tijdens (als tussenliggende stap) of na de failover tot stand worden gebracht. Het bedrijf kan herstelplannen gebruiken om op te geven wanneer verbindingen tot stand worden gebracht.
  • De oorspronkelijke verbinding tussen Azure - oost Azië 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 opnieuw geconfigureerd om te verwijzen naar de doelregio en gateways na een failover.

On-premises-naar-Azure-connectiviteit na failover

Hybride resources: geïsoleerde app-failover

Bedrijfs 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 een 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.