Capaciteitsplanning met behulp van Azure Site Recovery

Als organisatie is het essentieel om een BCDR-strategie (business continuity and disaster recovery) te gebruiken die uw gegevens veilig houdt, apps beschikbaar en workloads online houdt tijdens geplande en ongeplande uitval.

Via de replicatie van workloads van virtuele machines (VM's) van een primaire site naar een secundaire locatie biedt Azure Site Recovery op Azure Stack Hub services die de veiligheid van organisatiegegevens, de beschikbaarheid van toepassingen en workloads tijdens storingen kunnen ondersteunen. Als er bijvoorbeeld een storing optreedt op uw primaire site, voert u een failover uit naar een secundaire locatie voor toegang tot uw apps. Zodra de primaire site weer wordt uitgevoerd, kunt u een failback naar de site uitvoeren. Zie Info over Site Recovery voor meer informatie.

Als u de replicatie van VM's tussen twee Azure Stack Hub-stempels wilt inschakelen, configureert u twee omgevingen:

• Bronomgeving :
  • De Azure Stack Hub-stempel waar tenant-VM's worden uitgevoerd.
• Doelomgeving :
  • Waar de Azure Site Recovery-resourceprovider wordt uitgevoerd.

Een essentieel onderdeel voor het succes van een plan voor bedrijfscontinuïteit en herstel na noodgevallen is capaciteitsplanning. Tijdens de capaciteitsplanning moet u rekening houden met een aantal factoren:

• Beoogde hersteltijd (RTO) en RPO (Recovery Point Objectives) voor de specifieke workloads die u wilt beveiligen.

• Workloads en de toepassingskenmerken:

  • Hoe vaak de gegevens binnen de betreffende VM worden gewijzigd.
  • Hoeveel gegevens worden gegenereerd of verwijderd?
  • Hoe het toepassingsontwerp eruitziet en meer?

• VM-grootten, het aantal schijven en hoe elke VM is gekoppeld aan andere VM's.

  • Voor oplossingen waarvoor meerdere VM's nodig zijn, moet u begrijpen in welke volgorde deze VM's moeten worden gestart.

• Netwerkbandbreedte tussen de bron- en doelomgeving. Dit onderdeel kan van invloed zijn op RPO's.

Elk van deze punten is belangrijk en heeft brede gevolgen bij het opstellen van een BCDR-plan.

In de volgende secties vindt u de belangrijkste punten die u moet overwegen vanuit het perspectief van Azure Site Recovery. Elk BCDR-plan is anders en is gebaseerd op de specifieke workloads die u wilt beveiligen. Daarom is deze lijst niet volledig.

Bronoverwegingen

In de bronomgeving voert Azure Stack Hub het Azure Site Recovery VM-apparaat uit. De VM is een Standard_DS4_v2 vm (8 vCPU's, 28 Gb geheugen, 32 gegevensschijven) die wordt uitgevoerd in het Azure Stack Hub-gebruikersabonnement.

Houd rekening met de volgende gebieden in de bronomgeving:

• Quotum:

  • U moet voldoende quotum hebben voor het maken van het Azure Site Recovery VM-apparaat. U hebt er een of meer nodig, afhankelijk van het totale plan.

• Opslag voor het Azure Site Recovery VM-apparaat:

  • Op het Azure Site Recovery VM-apparaat zelf zijn de gegevensvereisten gedefinieerd door de VM-grootte.

  • Wanneer u capaciteit plant, moet u ervoor zorgen dat de VM van het apparaat voldoende opslagruimte heeft om de mechanismen voor failback en opnieuw beveiligen uit te voeren.

    Notitie

    Als er opslagbeperkingen zijn, kunnen de failback en opnieuw beveiligen mislukken met een fout Er is een bericht met een interne fout opgetreden . Gebruikers moeten de gebeurtenislogboeken op het apparaat controleren om de werkelijke azure-Resource Manager-fout te bevestigen. Zie Bekende problemen voor Azure Site Recovery voor meer informatie.

• Bandbreedte:

  • De initiële replicatie genereert een hoog bandbreedtegebruik.
  • Wijzigingen op elke VM worden gerepliceerd, afhankelijk van het replicatiebeleid en elk type toepassing.

Overwegingen bij het doel

In de doelomgeving zijn er twee onderdelen die u moet overwegen voor capaciteitsplanning:

• De vereisten voor de Azure Site Recovery-service: hoeveel wordt er verbruikt om Azure Site Recovery uit te voeren, zonder dat workloads per se worden beschermd.

• De vereisten voor beveiligde workloads.

Voor de doelomgeving moet voor elk Site Recovery apparaat één Azure Site Recovery-kluis worden gemaakt om vm's te beschermen tegen de bron (één apparaat per kluis). Hoewel dit vanuit capaciteitsperspectief geen beperking is, moet er rekening mee worden gehouden bij het plannen van het ontwerp van de algehele omgeving.

Azure Site Recovery RP-resources

Voor de installatie van Azure Site Recovery in Azure Stack Hub moet u de Site Recovery Resource Provider (RP) installeren.

Notitie

Met Microsoft.SiteRecovery-1.2301.2216.2287 heeft Azure Site Recovery op Azure Stack Hub geen Event Hubs nodig als afhankelijkheid.

Deze service wordt gemaakt in het Azure Stack Hub-beheerdersabonnement en wordt beheerd door Azure Stack Hub zelf. Daarom is er geen configuratie vereist. Net als bij elke service verbruiken deze resources echter geheugen en opslag en zijn er bepaalde vCPU's toegewezen:

Service	vCore	Geheugen	Schijfgrootte
Azure Site Recovery	12	42 GB	1,4 TB

Notitie

Deze resources zijn Azure Stack Hub-services aan de beheerzijde van Azure Stack Hub. Na de installatie beheert het platform deze resources.

Beveiligde werkbelastingen

Houd bij het maken van het BCDR-plan rekening met alle aspecten van de beveiligde workloads. De volgende lijst is niet volledig en moet als uitgangspunt worden beschouwd:

• VM-grootte, aantal schijven, schijfgrootte, IOPS, gegevensverloop en nieuwe gemaakte gegevens.

• Overwegingen voor netwerkbandbreedte:

  • De netwerkbandbreedte die vereist is voor replicatie van verschillen.
  • De hoeveelheid doorvoer in de doelomgeving die Azure Site Recovery uit de bronomgeving kan halen.
  • Het aantal VM's dat tegelijk batchgewijs moet worden uitgevoerd. Dit getal is gebaseerd op de geschatte bandbreedte om de initiële replicatie in een bepaalde tijd te voltooien.
  • De RPO die kan worden bereikt voor een bepaalde bandbreedte.
  • Het effect op de gewenste RPO als er een lagere bandbreedte is ingericht.

• Opslagoverwegingen:

  • Hoeveel gegevens zijn vereist voor de initiële replicatie.
  • Hoeveel herstelpunten er worden bewaard en hoe de gegevens toenemen, voor elke beveiligde VM, tijdens deze intervallen.
  • Hoeveel quota moeten worden toegewezen aan de doel-Azure Stack Hub-gebruikersabonnementen, zodat gebruikers over voldoende toewijzing beschikken.
  • Het cacheopslagaccount voor replicatie.

• Overwegingen voor rekenkracht:

  • Wanneer er een failover plaatsvindt, worden de VM's gestart op de doelgebruikersabonnementen van Azure Stack Hub. Er moet voldoende quotumtoewijzing zijn ingesteld om deze VM-resources te kunnen starten.
  • Tijdens de beveiliging van de VM, wanneer de beveiligde VM actief is in de bronomgeving, worden er geen VM-gerelateerde resources zoals vCPU, geheugen, enzovoort gebruikt in de doelomgeving. Deze resources worden alleen relevant tijdens een failoverproces, zoals een testfailover.

Voor het bereik van Azure Site Recovery op Azure Stack Hub is dit een beginpunt voor berekeningen, met name voor het gebruikte cacheopslagaccount:

1. Als er een failover is, vermenigvuldigt u tijdens normale bewerkingen het aantal schijven dat is gerepliceerd met de gemiddelde RPO. U kunt bijvoorbeeld (2 MB * 250s) hebben. Het cacheopslagaccount is normaal gesproken een paar kB tot 500 MB per schijf.

2. Als er een failover is, vermenigvuldigt u in het slechtste geval het aantal schijven dat is gerepliceerd met de gemiddelde RPO gedurende een volledige dag.

   Belangrijk

   Als sommige delen van Azure Site Recovery niet werken, maar andere wel werken, kan er maximaal één dag difflog in het opslagaccount zijn voordat Azure Site Recovery besluit om een time-out op te geven.

3. Failback naar de nieuwe VM. Bereken de som van de schijfgrootte van elke batch.

   • De hele schijf moet worden gekopieerd naar het cacheopslagaccount om de doel-VM toe te passen, omdat het doel een lege schijf is.
   • De gekoppelde gegevens worden verwijderd zodra ze zijn gekopieerd, maar er is waarschijnlijk een piekgebruik met de som van alle schijfgrootten.

Maak het BDCR-plan op basis van de specifieke kenmerken van de oplossing die u probeert te beveiligen.

De volgende tabel is een voorbeeld van tests die worden uitgevoerd in onze omgevingen. U kunt dit inzicht gebruiken om een basislijn voor uw eigen toepassing op te halen, maar elke workload verschilt:

Configuratie

Blokgrootte	Doorvoer/schijf
2 MB	2 MB/s
64 kB	2 MB/s
8 kB	1 MB/s
8 kB	2 MB/s

Resultaat

Aantal ondersteunde schijven	Totale doorvoer	Totaal aantal OP's	Knelpunt
68	136 MB/s	68	opslag
60	120 MB/s	2048	opslag
28	28 MB/s	3584	Azure Site Recovery CPU en geheugen
16	32 MB/s	4096

Notitie

8 kB is de kleinste blokgrootte van gegevens die door Azure Site Recovery worden ondersteund. Wijzigingen kleiner dan 8 kB worden behandeld als 8 kB.

Om verder te testen, hebben we een consistent type workload gegenereerd; bijvoorbeeld consistente opslagwijzigingen in blokken van 8 kB met een totaal van maximaal 1 MB/s per schijf. Dit scenario is waarschijnlijk niet in een echte workload, aangezien wijzigingen op verschillende momenten van de dag kunnen plaatsvinden of in pieken van verschillende grootten kunnen optreden.

Om deze willekeurige patronen te repliceren, hebben we ook scenario's getest met:

• 120 VIRTUELE machines (80 Windows, 40 Linux) beveiligd via hetzelfde Azure Site Recovery VM-apparaat.

  • Elke VM genereert met willekeurige intervallen, ten minste twee keer per uur, willekeurige blokken met in totaal 5 Gb aan gegevens in vijf bestanden.

  • Replicatie is geslaagd voor alle 120 VM's met een lage tot gemiddelde belasting op de Azure Site Recovery-services.

    Notitie

    Deze getallen mogen alleen als basislijn worden gebruikt. Ze worden niet per se lineair geschaald. Het toevoegen van een andere batch van hetzelfde aantal VM's heeft mogelijk minder impact dan de eerste. De resultaten zijn sterk afhankelijk van het type werkbelasting dat wordt gebruikt.

Hoe moet u plannen en testen

Toepassingen en oplossingsworkloads hebben bepaalde RTO-vereisten (Recovery Time Objective) en RPO-vereisten (Recovery Point Objective). Effectief ontwerp voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR) profiteren van de mogelijkheden op platformniveau die aan deze vereisten voldoen, omdat we de oplossingsspecifieke mechanismen gebruiken. Als u BCDR-mogelijkheden wilt ontwerpen, legt u vereisten voor herstel na noodgevallen vast en houdt u rekening met al deze factoren in uw ontwerp:

• Vereisten voor de beschikbaarheid van toepassingen en gegevens:

  • RTO- en RPO-vereisten voor elke workload.
  • Ondersteuning voor actief-actief- en actief-passieve beschikbaarheidspatronen.

• Ondersteuning voor implementaties in meerdere regio's voor failover, met nabijheid van onderdelen voor prestaties. Mogelijk ondervindt u toepassingsbewerkingen met verminderde functionaliteit of verminderde prestaties tijdens een storing.

  Notitie

  De toepassing weet mogelijk dat deze systeemeigen kan worden uitgevoerd of bepaalde onderdelen heeft die kunnen worden uitgevoerd in meerdere Azure Stack Hub-omgevingen. In dat geval kunt u Azure Site Recovery gebruiken om alleen de VM's te repliceren met de onderdelen die deze functionaliteit niet hebben, bijvoorbeeld een front-end- of back-endoplossing, waarin u de front-ends in Azure Stack Hub-omgevingen kunt implementeren.

• Vermijd het gebruik van overlappende IP-adresbereiken in productie- en DR-netwerken.

  • Productie- en DR-netwerken met overlappende IP-adressen vereisen een failoverproces dat failover van toepassingen kan bemoeilijken en vertragen. Plan indien mogelijk een BCDR-netwerkarchitectuur die gelijktijdige connectiviteit met alle sites biedt.

• De grootte van uw doelomgevingen aanpassen:

  • Als u de bron en het doel op een 1:1-manier gebruikt, wijst u iets meer opslagruimte toe aan uw doelomgeving. Dit komt door de manier waarop de geschiedenis van de schijfbladwijzers wordt uitgevoerd. Deze toewijzing is geen 2 keer hoger, omdat deze alleen wijzigingen in de gegevens bevat. Afhankelijk van het type gegevens en de verwachte wijzigingen, en replicatiebeleid met 1,5 tot 2 keer meer opslag op het doel, zorgt ervoor dat failoverprocessen geen problemen veroorzaken.
  • U kunt overwegen om de Azure Stack Hub-doelomgeving als doel te gebruiken voor meerdere Azure Stack Hub-bronnen. In dit geval verlaagt u de totale kosten, maar moet u plannen wat er gebeurt wanneer bepaalde workloads uitvalt; bijvoorbeeld welke bron prioriteit moet krijgen.
  • Als uw doelomgeving wordt gebruikt voor het uitvoeren van andere workloads, moet het BCDR-plan het gedrag van deze workloads bevatten. U kunt bijvoorbeeld de dev/test-VM's uitvoeren in de doelomgeving en als er een probleem optreedt met uw bronomgeving, kunt u alle VM's op het doel uitschakelen om ervoor te zorgen dat er voldoende resources beschikbaar zijn om de beveiligde VM's te starten.

U moet de BCDR testen en regelmatig valideren. U kunt dit doen met behulp van testfailoverprocessen of door de volledige workloads te verplaatsen om de stromen end-to-end te valideren.

Volgende stappen

Azure Site Recovery op Azure Stack Hub