Delen via

Virtuele Azure-machines waarvoor een Failover-overschakeling naar de primaire regio is uitgevoerd, opnieuw beveiligen

  • Artikel

Wanneer u een failover uitvoert van virtuele Azure-machines van de ene regio naar de andere met behulp van Azure Site Recovery, worden de virtuele machines opgestart in de secundaire regio, met een niet-beveiligde status. Als u een failback wilt uitvoeren van de virtuele machines naar de primaire regio, voert u de volgende taken uit:

  1. Beveilig de virtuele machines in de secundaire regio opnieuw, zodat ze worden gerepliceerd naar de primaire regio.
  2. Nadat de beveiliging is voltooid en de virtuele machines worden gerepliceerd, kunt u een failover uitvoeren van de secundaire naar de primaire regio.

Vereisten

  • De failover van de virtuele machine van de primaire naar de secundaire regio moet worden doorgevoerd.
  • De primaire doelsite moet beschikbaar zijn en u moet resources in die regio kunnen openen of maken.

Een virtuele machine opnieuw beveiligen

  1. Klik in Gerepliceerde items van Kluis>met de rechtermuisknop op de virtuele machine waarvoor een failover is uitgevoerd en selecteer Opnieuw beveiligen. De richting voor opnieuw beveiligen moet van secundair naar primair worden weergegeven.

    Schermopname van een virtuele machine met een contextmenu met Opnieuw beveiligen geselecteerd.

  2. Controleer de resourcegroep, het netwerk, de opslag en beschikbaarheidssets. Selecteer vervolgens OK. Als er resources zijn gemarkeerd als nieuw, worden ze gemaakt als onderdeel van het herbeveiligingsproces.

  3. De herbeveiligingstaak seedt de doelsite met de meest recente gegevens. Nadat de taak is voltooid, vindt deltareplicatie plaats. Vervolgens kunt u een failover uitvoeren naar de primaire site. U kunt het opslagaccount of het netwerk selecteren dat u wilt gebruiken tijdens het opnieuw beveiligen met behulp van de optie aanpassen.

    Schermopname met de optie Aanpassen in Azure Portal.

Instellingen voor opnieuw beveiligen aanpassen

U kunt de volgende eigenschappen van de virtuele doelmachine aanpassen tijdens het opnieuw beveiligen.

Schermopname van Aanpassen in Azure Portal.

Eigenschappen Opmerkingen
Doelresourcegroep Wijzig de doelresourcegroep waarin de virtuele machine wordt gemaakt. Als onderdeel van opnieuw beveiligen wordt de virtuele doelmachine verwijderd. Wanneer u een virtuele machine waarvoor een failover is uitgevoerd opnieuw beveiligt naar de virtuele bronmachine, kan de doelresourcegroep niet worden gewijzigd.
Virtueel doelnetwerk Het doelnetwerk kan niet worden gewijzigd tijdens de taak voor opnieuw beveiligen. Als u het netwerk wilt wijzigen, moet u de netwerktoewijzing opnieuw uitvoeren.
Capaciteitsreservering Configureer een capaciteitsreservering voor de virtuele machine. U kunt een nieuwe capaciteitsreserveringsgroep maken om capaciteit te reserveren of een bestaande capaciteitsreserveringsgroep selecteren. Meer informatie over capaciteitsreservering.
Doelopslag (secundaire virtuele machine gebruikt geen beheerde schijven) U kunt het opslagaccount wijzigen dat door de virtuele machine wordt gebruikt na een failover.
Beheerde replicaschijven (secundaire virtuele machine maakt gebruik van beheerde schijven) Site Recovery maakt replica beheerde schijven in de primaire regio om de beheerde schijven van de secundaire virtuele machine te spiegelen.
Cacheopslag U kunt een cacheopslagaccount opgeven dat moet worden gebruikt tijdens de replicatie. Standaard wordt er een nieuw cacheopslagaccount gemaakt als dit niet bestaat.
Standaard wordt het type opslagaccount (Standard-opslagaccount of Premium Blok-blobopslagaccount) dat u hebt geselecteerd voor de virtuele bronmachine op de oorspronkelijke primaire locatie gebruikt. Als u bijvoorbeeld tijdens de replicatie van de oorspronkelijke bron naar het doel een hoog verloop hebt geselecteerd, wordt premium blok-blob standaard gebruikt tijdens het opnieuw beveiligen van het doel naar de oorspronkelijke bron. U kunt deze configureren en wijzigen voor opnieuw beveiligen. Zie Herstel na noodgevallen van virtuele Azure-machines voor meer informatie: ondersteuning voor hoog verloop.
Beschikbaarheidsset Als de virtuele machine in de secundaire regio deel uitmaakt van een beschikbaarheidsset, kunt u een beschikbaarheidsset kiezen voor de virtuele doelmachine in de primaire regio. Site Recovery probeert standaard de bestaande beschikbaarheidsset in de primaire regio te vinden en te gebruiken. Tijdens het aanpassen kunt u een nieuwe beschikbaarheidsset opgeven.

Wat gebeurt er tijdens het opnieuw beveiligen?

Standaard gebeurt het volgende:

  1. Er wordt een cacheopslagaccount gemaakt in de regio waar de virtuele machine waarvoor een failover is uitgevoerd.
  2. Als het doelopslagaccount (het oorspronkelijke opslagaccount in de primaire regio) niet bestaat, wordt er een nieuw account gemaakt. De naam van het toegewezen opslagaccount is de naam van het opslagaccount dat wordt gebruikt door de secundaire virtuele machine, met achtervoegsel .asr
  3. Als uw virtuele machine beheerde schijven gebruikt, worden replica beheerde schijven gemaakt in de primaire regio om de gegevens op te slaan die zijn gerepliceerd van de schijven van de secundaire virtuele machine.
  4. Tijdelijke replica's van de bronschijven (schijven die zijn gekoppeld aan de virtuele machines in de secundaire regio) worden gemaakt met de naam ms-asr-<GUID>, die worden gebruikt voor het overdragen/lezen van gegevens. Met de tijdelijke schijven kunnen we de volledige bandbreedte van de schijf gebruiken in plaats van slechts 16% bandbreedte van de oorspronkelijke schijven (die zijn verbonden met de virtuele machine). De tijdelijke schijven worden verwijderd zodra de beveiliging is voltooid.
  5. Als de doelbeschikbaarheidsset niet bestaat, wordt er zo nodig een nieuwe gemaakt als onderdeel van de taak voor opnieuw beveiligen. Als u de instellingen voor opnieuw beveiligen hebt aangepast, wordt de geselecteerde set gebruikt.

Wanneer u een taak voor opnieuw beveiligen activeert en de doel-VM bestaat, gebeurt het volgende:

  1. De virtuele machine aan de doelzijde is uitgeschakeld als deze wordt uitgevoerd.
  2. Als de virtuele machine beheerde schijven gebruikt, wordt er een kopie van de oorspronkelijke schijf gemaakt met een -ASRReplica achtervoegsel. De oorspronkelijke schijven worden verwijderd. De -ASRReplica kopieën worden gebruikt voor replicatie.
  3. Als de virtuele machine niet-beheerde schijven gebruikt, worden de gegevensschijven van de doel-VM losgekoppeld en gebruikt voor replicatie. Er wordt een kopie van de besturingssysteemschijf gemaakt en gekoppeld op de virtuele machine. De oorspronkelijke besturingssysteemschijf wordt losgekoppeld en gebruikt voor replicatie.
  4. Alleen wijzigingen tussen de bronschijf en de doelschijf worden gesynchroniseerd. De differentiëlen worden berekend door zowel de schijven te vergelijken als vervolgens overgedragen. Controleer hieronder om de geschatte tijd te vinden voor het voltooien van de herbeveiliging.
  5. Nadat de synchronisatie is voltooid, wordt de deltareplicatie gestart en wordt er een herstelpunt gemaakt in overeenstemming met het replicatiebeleid.

Wanneer u een taak voor opnieuw beveiligen activeert en de doel-VM en schijven niet bestaan, gebeurt het volgende:

  1. Als de virtuele machine beheerde schijven gebruikt, worden replicaschijven gemaakt met -ASRReplica achtervoegsel. De -ASRReplica kopieën worden gebruikt voor replicatie.
  2. Als de virtuele machine niet-beheerde schijven gebruikt, worden replicaschijven gemaakt in het doelopslagaccount.
  3. De volledige schijven worden gekopieerd van de regio waarvoor een failover is uitgevoerd naar de nieuwe doelregio.
  4. Nadat de synchronisatie is voltooid, wordt de deltareplicatie gestart en wordt er een herstelpunt gemaakt in overeenstemming met het replicatiebeleid.

Notitie

De ms-asr schijven zijn tijdelijke schijven die worden verwijderd nadat de actie voor opnieuw beveiligen is voltooid. Er worden minimale kosten in rekening gebracht op basis van de door Azure beheerde schijfprijs voor de tijd dat deze schijven actief zijn.

Geschatte tijd voor het opnieuw beveiligen

In de meeste gevallen repliceert Azure Site Recovery de volledige gegevens niet naar de bronregio. De hoeveelheid gerepliceerde gegevens is afhankelijk van de volgende voorwaarden:

  1. Azure Site Recovery biedt geen ondersteuning voor opnieuw beveiligen als de gegevens van de virtuele bronmachine om een of andere reden worden verwijderd, beschadigd of niet toegankelijk zijn. Bijvoorbeeld een wijziging of verwijdering van een resourcegroep. U kunt ook de vorige bescherming tegen herstel na noodgevallen uitschakelen en een nieuwe beveiliging vanuit de huidige regio inschakelen.
  2. Als de gegevens van de virtuele bronmachine toegankelijk zijn, worden differentiële berekeningen berekend door zowel de schijven als alleen de verschillen te vergelijken. In dit geval is de herbeveiligingstijd groter dan of gelijk aan de checksum calculation time + checksum differentials transfer time + time taken to process the recovery points from Azure Site Recovery agent + auto scale time.

Factoren voor herbeveiligingstijd in scenario 2

De volgende factoren zijn van invloed op de herbeveiligingstijd wanneer de virtuele bronmachine toegankelijk is in scenario 2:

  1. Berekeningstijd voor controlesom: de tijd die nodig is om het inschakelen van het replicatieproces van de primaire naar de locatie voor herstel na noodgevallen te voltooien, wordt gebruikt als een benchmark voor de differentiële berekening van de controlesom. Navigeer naar Recovery Services-kluizen>die Site Recovery-taken bewaken>om de tijd te zien die nodig is om het inschakelen van het replicatieproces te voltooien. Dit is de minimale tijd die nodig is om de berekening van de controlesom te voltooien. Schermopname van de duur van het opnieuw beveiligen van een virtuele machine in Azure Portal.

  2. De differentiële gegevensoverdracht van controlesom vindt plaats bij ongeveer 23% van de schijfdoorvoer.

  3. De tijd die nodig is om de herstelpunten te verwerken die zijn verzonden vanuit de Azure Site Recovery-agent : de Azure Site Recovery-agent blijft ook herstelpunten verzenden tijdens de berekenings- en overdrachtsfase van controlesom. Azure Site Recovery verwerkt deze echter slechts zodra de diff-overdracht van controlesom is voltooid. De tijd die nodig is om herstelpunten te verwerken, is ongeveer een vijfde (1/5e) van de tijd die nodig is voor de berekening van de controlesom differentiële berekeningen en de overdrachtstijd van controlesomverschil (tijd voor de berekening van de controlesom en de tijd voor de overdracht van controlesom). Als de tijd die nodig is voor de differentiële berekening van de controlesom en de differentiële overdracht van controlesom bijvoorbeeld 15 uur is, is de tijd die nodig is om de herstelpunten van de agent te verwerken drie uur.

  4. De tijd voor automatisch schalen is ongeveer 20-30 minuten.

Voorbeeldscenario:

We nemen het voorbeeld uit de volgende schermopname, waarbij Replicatie van de primaire naar de locatie voor herstel na noodgevallen een uur en 12 minuten duurde. De berekeningstijd van de controlesom is ten minste een uur en 12 minuten. Ervan uitgaande dat de hoeveelheid gegevenswijziging na failover 45 GB is en de schijf een doorvoer van 60 Mbps heeft, vindt de differentiële overdracht plaats bij 14 Mbps en de tijd die nodig is voor differentiële overdracht is 45 GB / 14 Mbps, dat ongeveer 55 minuten is. De tijd die nodig is om de herstelpunten te verwerken, is ongeveer een vijfde van de totale tijd die nodig is voor de berekening van de controlesom (72 minuten) en de tijd die nodig is voor gegevensoverdracht (55 minuten). Dit is ongeveer 25 minuten. Daarnaast duurt het 20-30 minuten voordat automatisch wordt geschaald. De totale tijd voor opnieuw beveiligen moet dus ten minste drie uur zijn.

Schermopname van een voorbeeldduur van het opnieuw beveiligen van een virtuele machine in Azure Portal.

Het bovenstaande is een eenvoudige illustratie van het schatten van de herbeveiligingstijd.

Wanneer de virtuele machine opnieuw wordt beveiligd tegen een regio voor herstel na noodgevallen naar de primaire regio (na een failover van de primaire regio naar de regio voor herstel na noodgevallen), worden de doel-VM (oorspronkelijke bron-VM) en de bijbehorende NIC('s) verwijderd.

Wanneer de virtuele machine echter opnieuw wordt beveiligd van de primaire regio naar een regio voor herstel na een failback, worden de virtuele machine en de bijbehorende NIC('s) niet verwijderd in de regio voor herstel na noodgevallen die tijdens de eerdere failover zijn gemaakt.

Volgende stappen

Nadat de virtuele machine is beveiligd, kunt u een failover starten. Met de failover wordt de virtuele machine in de secundaire regio afgesloten en wordt de virtuele machine in de primaire regio gemaakt en opgestart, met korte downtime tijdens dit proces. U wordt aangeraden een geschikt tijdstip voor dit proces te kiezen en een testfailover uit te voeren voordat u een volledige failover naar de primaire site start.

Meer informatie over Azure Site Recovery-failover.