ExpressRoute integreren met herstel na noodgevallen voor virtuele Azure-machines

In dit artikel wordt beschreven hoe u Azure ExpressRoute integreert met Azure Site Recovery wanneer u herstel na noodgevallen instelt voor virtuele Azure-machines naar een secundaire Azure-regio.

Site Recovery maakt herstel na noodgevallen van virtuele Azure-machines mogelijk door gegevens van virtuele Azure-machines te repliceren naar Azure.

• Als virtuele Azure-machines azure managed disks gebruiken, worden gegevens van virtuele machines gerepliceerd naar een gerepliceerde beheerde schijf in de secundaire regio.
• Als virtuele Azure-machines geen beheerde schijven gebruiken, worden gegevens van virtuele machines gerepliceerd naar een Azure-opslagaccount.
• Replicatie-eindpunten zijn openbaar, maar replicatieverkeer voor virtuele Azure-machines loopt niet via internet.

Met ExpressRoute kunt u on-premises netwerken uitbreiden naar de Microsoft Azure-cloud via een privéverbinding, mogelijk gemaakt door een connectiviteitsprovider. Als u ExpressRoute hebt geconfigureerd, wordt deze als volgt geïntegreerd met Site Recovery:

• Tijdens replicatie tussen Azure-regio's: replicatieverkeer voor herstel na noodgevallen van virtuele Azure-machines bevindt zich alleen in Azure en ExpressRoute is niet nodig of gebruikt voor replicatie. Als u echter verbinding maakt vanaf een on-premises site met de virtuele Azure-machines op de primaire Azure-site, zijn er veel problemen waarmee u rekening moet houden wanneer u herstel na noodgevallen instelt voor deze virtuele Azure-machines.
• Failover tussen Azure-regio's: wanneer er storingen optreden, voert u een failover uit van virtuele Azure-machines van de primaire naar de secundaire Azure-regio. Na een failover naar een secundaire regio zijn er veel stappen die moeten worden uitgevoerd om toegang te krijgen tot de virtuele Azure-machines in de secundaire regio met behulp van ExpressRoute.

Voordat u begint

Zorg ervoor dat u de volgende concepten begrijpt voordat u begint:

• ExpressRoute-circuits
• ExpressRoute-routeringsdomeinen
• ExpressRoute-locaties.
• Architectuur voor replicatie van virtuele Azure-machines
• Replicatie instellen voor virtuele Azure-machines.
• Een failover uitvoeren voor virtuele Azure-machines.

Algemene aanbevelingen

Voor best practice en om efficiënte beoogde hersteltijd (RTO's) voor herstel na noodgevallen te garanderen, raden we u aan het volgende te doen wanneer u Site Recovery instelt voor integratie met ExpressRoute:

• Netwerkonderdelen inrichten voordat een failover naar een secundaire regio wordt uitgevoerd:
  • Wanneer u replicatie inschakelt voor virtuele Azure-machines, kan Site Recovery automatisch netwerkresources implementeren met behulp van de bronnetwerkinstellingen. Bijvoorbeeld netwerken, subnetten en gateways in de Azure-doelregio.
  • Site Recovery kan geen netwerkresources zoals VNet-gateways automatisch instellen.
  • U wordt aangeraden deze extra netwerkresources in te richten voordat de failover wordt uitgevoerd. Een kleine downtime is gekoppeld aan deze implementatie en kan van invloed zijn op de totale hersteltijd als u er tijdens de implementatieplanning geen rekening mee hebt gehouden.
• Voer regelmatig noodherstelanalyses uit:
  • Een analyse valideert uw replicatiestrategie zonder gegevensverlies of uitvaltijd, en is niet van invloed op uw productieomgeving. Hiermee voorkomt u last-minute configuratieproblemen die een negatieve invloed kunnen hebben op RTO.
  • Wanneer u een testfailover uitvoert voor de analyse, wordt u aangeraden een afzonderlijk azure-VM-netwerk te gebruiken in plaats van het standaardnetwerk dat tijdens de replicatie is ingesteld.
• Gebruik verschillende IP-adresruimten als u één ExpressRoute-circuit hebt.
  • U wordt aangeraden een andere IP-adresruimte te gebruiken voor het virtuele doelnetwerk. Dit voorkomt problemen bij het tot stand brengen van verbindingen tijdens regionale storingen.
  • Als u geen afzonderlijke adresruimte kunt gebruiken, moet u de failover voor noodherstelanalyse uitvoeren op een afzonderlijk testnetwerk met verschillende IP-adressen. U kunt twee VNets met overlappende IP-adresruimte niet verbinden met hetzelfde ExpressRoute-circuit.

Virtuele Azure-machines repliceren wanneer u ExpressRoute gebruikt

Als u replicatie wilt instellen voor virtuele Azure-machines op een primaire site en u verbinding maakt met deze virtuele machines vanaf uw on-premises site via ExpressRoute, moet u het volgende doen:

1. Schakel replicatie in voor elke virtuele Azure-machine.
2. Optioneel toestaan dat Site Recovery netwerken instelt:
   • Wanneer u replicatie configureert en inschakelt, stelt Site Recovery netwerken, subnetten en gatewaysubnetten in de Azure-doelregio in zodat deze overeenkomen met die in de bronregio. Site Recovery wijst ook toe tussen de virtuele bron- en doelnetwerken.
   • Als u niet wilt dat Site Recovery dit automatisch doet, maakt u de netwerkresources aan de doelzijde voordat u replicatie inschakelt.
3. Andere netwerkelementen maken:
   • Site Recovery maakt geen routetabellen, VNet-gateways, VNet-gatewayverbindingen, VNet-peering of andere netwerkresources en -verbindingen in de secundaire regio.
   • U moet deze extra netwerkelementen in de secundaire regio maken, op elk moment voordat u een failover uitvoert vanuit de primaire regio.
   • U kunt herstelplannen en automatiseringsscripts gebruiken om deze netwerkresources in te stellen en te verbinden.
4. Als u een virtueel netwerkapparaat (NVA) hebt geïmplementeerd om de stroom van netwerkverkeer te beheren:
   • De standaardsysteemroute van Azure voor replicatie van virtuele Azure-machines is 0.0.0.0/0.
   • Normaal gesproken definiëren NVA-implementaties ook een standaardroute (0.0.0.0/0) die uitgaand internetverkeer dwingt om via de NVA te stromen. De standaardroute wordt gebruikt wanneer er geen andere specifieke routeconfiguratie kan worden gevonden.
   • Als dit het geval is, kan de NVA overbelast zijn als al het replicatieverkeer via de NVA wordt doorgegeven.
   • Dezelfde beperking geldt ook bij het gebruik van standaardroutes voor het routeren van al het verkeer van virtuele Azure-machines naar on-premises implementaties.
   • In dit scenario wordt u aangeraden een netwerkservice-eindpunt te maken in uw virtuele netwerk voor de Microsoft.Storage-service, zodat het replicatieverkeer de Grens van Azure niet verlaat.

Voorbeeld van replicatie

In typische bedrijfsimplementaties worden workloads verdeeld over meerdere Azure-VNets met een centrale hub voor internet- en on-premises connectiviteit. Deze installatie maakt vaak gebruik van een hub-and-spoke-topologie met ExpressRoute.

• Regio. Apps worden geïmplementeerd in de regio Azure - oost Azië.
• Spoke vNets. Apps worden geïmplementeerd in twee spoke-vNets:
  • Bron vNet1: 10.1.0.0/24.
  • Bron vNet2: 10.2.0.0/24.
  • Elk virtueel spoke-netwerk is verbonden met hub-vNet.
• Hub vNet. Er is een hub vNet Source Hub vNet: 10.10.10.0/24.
  • Dit hub-vNet fungeert als gatekeeper.
  • Alle communicatie tussen subnetten verloopt via deze hub.
    • Hub vNet-subnetten. Het hub-vNet heeft twee subnetten:
    • NVA-subnet: 10.10.10.0/25. Dit subnet bevat een NVA (10.10.10.10).
    • Gatewaysubnet: 10.10.10.128/25. Dit subnet bevat een ExpressRoute-gateway die is verbonden met een ExpressRoute-verbinding die wordt gerouteerd naar de on-premises site via een privé-peeringrouteringsdomein.
• Het on-premises datacenter heeft een ExpressRoute-circuitverbinding via een partnerrand in Hong Kong Special Administrative Region.
• Alle routering wordt beheerd via Azure-routetabellen (UDR).
• Al het uitgaande verkeer tussen vNets of naar het on-premises datacenter wordt gerouteerd via de NVA.

Instellingen voor hub- en spoke-peering

Spoke naar hub

Richting	Instelling	Staat/provincie
Spoke naar hub	Adres van virtueel netwerk toestaan	Ingeschakeld
Spoke naar hub	Doorgestuurd verkeer toestaan	Ingeschakeld
Spoke naar hub	Gatewayoverdracht toestaan	Uitgeschakeld
Spoke naar hub	Gateways verwijderen gebruiken	Ingeschakeld

Hub naar spoke

Richting	Instelling	Staat/provincie
Hub naar spoke	Adres van virtueel netwerk toestaan	Ingeschakeld
Hub naar spoke	Doorgestuurd verkeer toestaan	Ingeschakeld
Hub naar spoke	Gatewayoverdracht toestaan	Ingeschakeld
Hub naar spoke	Gateways verwijderen gebruiken	Uitgeschakeld

Voorbeeldstappen

In ons voorbeeld moet het volgende gebeuren bij het inschakelen van replicatie voor virtuele Azure-machines in het bronnetwerk:

1. U schakelt replicatie in voor een virtuele machine.
2. Site Recovery maakt replica-vNets, subnetten en gatewaysubnetten in de doelregio.
3. Site Recovery maakt toewijzingen tussen de bronnetwerken en de replicadoelnetwerken die worden gemaakt.
4. U maakt handmatig virtuele netwerkgateways, virtuele netwerkgatewayverbindingen, peering van virtuele netwerken of andere netwerkresources of verbindingen.

Failover van virtuele Azure-machines bij gebruik van ExpressRoute

Nadat u een failover hebt uitgevoerd van virtuele Azure-machines naar de Azure-doelregio met behulp van Site Recovery, kunt u deze openen met behulp van persoonlijke ExpressRoute-peering.

• U moet ExpressRoute verbinden met het doel-vNet met een nieuwe verbinding. De bestaande ExpressRoute-verbinding wordt niet automatisch overgedragen.
• De manier waarop u uw ExpressRoute-verbinding met het doel-vNet instelt, is afhankelijk van uw ExpressRoute-topologie.

Toegang met twee circuits

Twee circuits met twee peeringlocaties

Met deze configuratie kunt u ExpressRoute-circuits beschermen tegen regionale noodgevallen. Als uw primaire peeringlocatie uitvalt, kunnen verbindingen vanaf de andere locatie worden voortgezet.

• Het circuit dat is verbonden met de productieomgeving, is meestal het primaire circuit. Het secundaire circuit heeft doorgaans een lagere bandbreedte, die kan worden verhoogd als er zich een noodgeval voordoet.
• Na een failover kunt u verbindingen tot stand brengen vanaf het secundaire ExpressRoute-circuit naar het doel-vNet. U kunt ook verbindingen instellen en gereed maken voor noodgeval, om de totale hersteltijd te verminderen.
• Zorg ervoor dat uw on-premises routering alleen gebruikmaakt van het secundaire circuit en de verbinding na een failover, met gelijktijdige verbindingen met zowel primaire als doel-vNets.
• De bron- en doel-vNets kunnen nieuwe IP-adressen ontvangen of dezelfde behouden na een failover. In beide gevallen kunnen de secundaire verbindingen tot stand worden gebracht voorafgaand aan de failover.

Twee circuits met één peeringlocatie

Deze configuratie helpt u te beschermen tegen fouten in het primaire ExpressRoute-circuit, maar niet als de enkele ExpressRoute-peeringlocatie uitvalt, wat van invloed is op beide circuits.

• U kunt gelijktijdige verbindingen van het on-premises datacenter hebben naar de bron-vNEt met het primaire circuit en naar het doel-vNet met het secundaire circuit.
• Zorg ervoor dat on-premises routering alleen gebruikmaakt van het secundaire circuit en de verbinding na een failover, met gelijktijdige verbindingen met primaire en doel.
• U kunt beide circuits niet verbinden met hetzelfde vNet wanneer circuits op dezelfde peeringlocatie worden gemaakt.

Toegang met één circuit

In deze configuratie is er slechts één Expressroute-circuit. Hoewel het circuit een redundante verbinding heeft voor het geval er een uitvalt, biedt één routecircuit geen tolerantie als uw peeringregio uitvalt. Opmerking:

• Als de Azure-doelregio zich niet op dezelfde locatie bevindt als de bron, moet u ExpressRoute Premium inschakelen als u één ExpressRoute-circuit gebruikt. Meer informatie over ExpressRoute-locaties en ExpressRoute-prijzen.
• U kunt de bron- en doel-vNets niet tegelijkertijd verbinden met het circuit als dezelfde IP-adresruimte wordt gebruikt in de doelregio. In dit scenario:
  • Verbreek de verbinding aan de bronzijde en maak vervolgens de doelverbinding tot stand. Deze verbindingswijziging kan worden gescript als onderdeel van een Site Recovery-herstelplan. Houd er rekening mee dat:
    • Als de primaire regio niet toegankelijk is, kan de verbroken verbinding mislukken in een regionale fout. Dit kan van invloed zijn op het maken van de verbinding met de doelregio.
    • Als u de verbinding in de doelregio hebt gemaakt en de primaire regio later herstelt, kan het zijn dat pakketten worden verwijderd als twee gelijktijdige verbindingen verbinding proberen te maken met dezelfde adresruimte.
    • U kunt dit voorkomen door de primaire verbinding onmiddellijk te beëindigen.
    • Nadat de failback van de virtuele machine naar de primaire regio is uitgevoerd, kan de primaire verbinding opnieuw tot stand worden gebracht nadat u de secundaire verbinding hebt verbroken.
• Als er een andere adresruimte wordt gebruikt op het doel-vNet, kunt u tegelijkertijd verbinding maken met de bron- en doel-vNets van hetzelfde ExpressRoute-circuit.

Voorbeeld van failover

In ons voorbeeld gebruiken we de volgende topologie:

• Twee verschillende ExpressRoute-circuits op twee verschillende peeringlocaties.
• Bewaar privé-IP-adressen voor de virtuele Azure-machines na een failover.
• De doelherstelregio is Azure SouthEast Asia.
• Er wordt een secundaire ExpressRoute-circuitverbinding tot stand gebracht via een partnerrand in Singapore.

Raadpleeg dit artikel voor een eenvoudige topologie die gebruikmaakt van één ExpressRoute-circuit, met hetzelfde IP-adres na een failover.

Voorbeeldstappen

Als u herstel in dit voorbeeld wilt automatiseren, moet u het volgende doen:

1. Volg de stappen om replicatie in te stellen.

2. Voer een failover uit voor de virtuele Azure-machines, met deze extra stappen tijdens of na de failover.

   a. Maak de Azure ExpressRoute-gateway in het VNet van de doelregiohub. Dit is nodig om het vNet van de doelhub te verbinden met het ExpressRoute-circuit.

   b. Maak de verbinding van het vNet van de doelhub naar het ExpressRoute-doelcircuit.

   c. Stel de VNet-peerings in tussen de hub en spoke van de doelregio. De peering-eigenschappen in de doelregio zijn hetzelfde als die in de bronregio.

   d. Stel de UDR's in het hub-VNet en de twee spoke-VNets in.

   • De eigenschappen van de UDR's aan de doelzijde zijn hetzelfde als die aan de bronzijde wanneer dezelfde IP-adressen worden gebruikt.
   • Met verschillende DOEL-IP-adressen moeten de UDR's dienovereenkomstig worden gewijzigd.

De bovenstaande stappen kunnen worden gescript als onderdeel van een herstelplan. Afhankelijk van de vereisten voor de connectiviteit en hersteltijd van de toepassing, kunnen de bovenstaande stappen ook worden voltooid voordat de failover wordt gestart.

Na herstel

Na het herstellen van de virtuele machines en het voltooien van de connectiviteit, is de herstelomgeving als volgt.

Volgende stappen

Meer informatie over het gebruik van herstelplannen voor het automatiseren van app-failover.