Capaciteitsplanning met Behulp van Azure Site Recovery
Als organisatie is het noodzakelijk om een BCDR-strategie (bedrijfscontinuïteit en herstel na noodgevallen) te gebruiken waarmee uw gegevens veilig, apps beschikbaar en workloads online blijven tijdens geplande en ongeplande storingen.
Door de replicatie van vm's (virtuele machines) van een primaire site naar een secundaire locatie, biedt Azure Site Recovery in Azure Stack Hub services die de veiligheid van bedrijfsgegevens, de beschikbaarheid van toepassingen en workloads tijdens storingen kunnen ondersteunen. Wanneer 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 opnieuw operationeel is, kunt u ernaar terugschakelen. Zie Over Site Recovery-voor meer informatie.
Als u replicatie van VM's in twee Azure Stack Hub-stempels wilt inschakelen, configureert u twee omgevingen:
-
bronomgeving:
- De Azure Stack Hub-omgeving waar tenant-VM's draaien.
-
Doelomgeving:
- Waar de Azure Site Recovery-resourceprovider actief is.
Een essentieel onderdeel voor het succes van een plan voor bedrijfscontinuïteit en noodherstel is capaciteitsplanning. Tijdens de capaciteitsplanning zijn er enkele factoren om rekening mee te houden:
Beoogde hersteltijd (RTO) en beoogde herstelpunten (RPO) voor de specifieke workloads die u wilt beveiligen.
Workloads en de toepassingskenmerken:
- Hoe vaak de gegevens binnen de betreffende VM veranderen.
- Hoeveel gegevens worden gegenereerd of verwijderd?
- Hoe het toepassingsontwerp eruitziet en meer?
VM-grootten, het aantal schijven en hoe elke VIRTUELE machine is gekoppeld aan andere VM's.
- Voor oplossingen waarvoor verschillende VM's nodig zijn, moet u begrijpen in welke volgorde deze VM's moeten worden gestart.
Netwerkbandbreedte tussen de bron- en doelomgevingen. Dit onderdeel kan van invloed zijn op RPO's.
Elk van deze punten is belangrijk en heeft brede implicaties bij het bouwen van een BCDR-plan.
In de volgende secties worden de belangrijkste punten vermeld die vanuit het perspectief van Azure Site Recovery moeten worden overwogen. Elk BCDR-plan is verschillend en is gebaseerd op de specifieke kenmerken van de 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 VIRTUELE machine is een vm met Standard_DS4_v2 (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 een of meer nodig, afhankelijk van het algehele plan.
Opslag voor het Azure Site Recovery VM-apparaat:
Het Azure Site Recovery VM-apparaat zelf heeft de gegevensvereisten die zijn gedefinieerd door de VM-grootte.
Zorg er bij het plannen van capaciteit voor dat de VM van het apparaat voldoende opslagruimte heeft om de failback uit te voeren en mechanismen opnieuw te beveiligen.
Notitie
Als er opslagbeperkingen zijn, kan de failback en het opnieuw beveiligen mislukken met een fout Er is een interne fout opgetreden bericht. 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 VIRTUELE machine worden gerepliceerd, afhankelijk van het replicatiebeleid en elk type toepassing.
Doeloverwegingen
In de doelomgeving zijn er twee onderdelen om rekening mee te houden voor capaciteitsplanning:
De vereisten voor de Azure Site Recovery-service: hoeveel wordt er verbruikt om Azure Site Recovery uit te voeren, zonder dat er noodzakelijkerwijs workloads worden beveiligd.
De vereisten voor beveiligde workloads.
Voor de doelomgeving moet één Azure Site Recovery-kluis worden gemaakt voor elk Site Recovery-apparaat om VM's te beveiligen tegen de bron (één apparaat per kluis). Hoewel dit geen beperking is vanuit capaciteitsperspectief, moet rekening worden gehouden met 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 vereist Azure Site Recovery op Azure Stack Hub geen Event Hubs als afhankelijkheid.
Deze service wordt gemaakt in het Azure Stack Hub-beheerabonnement en beheerd door Azure Stack Hub zelf, daarom is er geen configuratie vereist. Net als bij elke service verbruiken deze resources echter geheugen, opslag en hebben bepaalde vCPU's toegewezen:
| Dienst | vCore | Geheugen | Schijfgrootte |
|---|---|---|---|
| Azure Site Recovery | 18 | 64 GB | 384 GB |
Notitie
Deze resources zijn Azure Stack Hub-services aan de beheerzijde van Azure Stack Hub. Zodra het platform is geïnstalleerd, beheert het platform deze resources.
Beveiligde workloads
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 delta-replicatie.
- De hoeveelheid doorvoer in de doelomgeving die Azure Site Recovery kan ophalen uit de bronomgeving.
- Het aantal VM's dat tegelijkertijd in batches moet worden verwerkt. 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 een lagere bandbreedte is toegekend.
Overwegingen voor opslag:
- Hoeveel gegevens zijn vereist voor de initiële replicatie.
- Hoeveel herstelpunten worden bewaard en hoe de gegevens gedurende deze intervallen toenemen voor elke beveiligde VM.
- Hoeveel quota moeten worden toegewezen aan de Azure Stack Hub-doelgebruikersabonnementen, zodat gebruikers voldoende toewijzing hebben.
- Het cacheopslagaccount voor replicatie.
Overwegingen voor berekeningen:
- Wanneer er een failover plaatsvindt, worden de VM's gestart in de bedoelde gebruikersabonnementen van Azure Stack Hub. Er moet voldoende quotum zijn toegewezen om deze VM-resources te starten.
- Wanneer de beveiligde VM actief is in de bronomgeving, worden er tijdens de beveiliging van de VIRTUELE machine geen VM-gerelateerde resources, zoals vCPU, geheugen, enzovoort gebruikt in de doelomgeving. Deze resources worden alleen relevant tijdens een failoverproces, zoals test-failover.
Voor het bereik van Azure Site Recovery in Azure Stack Hub is dit een startpunt voor berekeningen, met name voor het cacheopslagaccount dat wordt gebruikt:
Als er een failover is, vermenigvuldigt u tijdens normale bewerkingen het aantal schijven dat wordt gerepliceerd door de gemiddelde RPO. Je hebt bijvoorbeeld (2 MB * 250 sec). Het cacheopslagaccount is normaal gesproken een paar kB tot 500 MB per schijf.
Als er een failover is, in het ergste geval, vermenigvuldigt u het aantal schijven dat wordt gerepliceerd door de gemiddelde RPO gedurende een volledige dag.
Belangrijk
Als sommige onderdelen van Azure Site Recovery niet werken, maar andere niet werken, kan er maximaal één dag difflog in het opslagaccount zijn voordat Azure Site Recovery besluit een time-out uit te voeren.
Schakel terug naar de nieuwe virtuele machine. Bereken de som van de grootte van de schijven van elke batch.
- De volledige schijf moet worden gekopieerd naar het cache-opslagaccount voor de toepassing op de doel-VM, aangezien het doel een lege schijf is.
- De gekoppelde gegevens worden verwijderd nadat ze zijn gekopieerd, maar het is waarschijnlijk dat het piekgebruik wordt weergegeven 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 OPS | Flessenhals |
|---|---|---|---|
| 68 | 136 MB/s | 68 | opslag |
| 60 | 120 MB/s | 2048 | opslag |
| 28 | 28 MB/s | 3584 | Cpu en geheugen van Azure Site Recovery |
| 16 | 32 MB/s | 4096 |
Notitie
8Kb is de kleinste blokgrootte van gegevens die door Azure Site Recovery worden ondersteund. Wijzigingen van minder 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 die in totaal tot 1 MB/s per schijf bedragen. Dit scenario bevindt zich waarschijnlijk niet in een echte workload, gezien het feit dat wijzigingen op verschillende tijdstippen van de dag kunnen plaatsvinden of in pieken van verschillende grootten.
Om deze willekeurige patronen te repliceren, hebben we ook scenario's getest met:
- 120 VM's (80 Windows, 40 Linux) beveiligd via hetzelfde Azure Site Recovery VM-apparaat.
Elke virtuele machine die met willekeurige intervallen, ten minste twee keer per uur, willekeurige blokken in totaal 5 Gb aan gegevens over vijf bestanden genereert.
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 schalen niet per se lineair. Het toevoegen van een andere batch van hetzelfde aantal VIRTUELE machines kan minder impact hebben dan de eerste. De resultaten zijn sterk afhankelijk van het type workloads dat wordt gebruikt.
Hoe moet u plannen en testen
Toepassingen en oplossingsworkloads hebben bepaalde RTO-vereisten (Recovery Time Objective) en RPO (Recovery Point Objective). Het BCDR-ontwerp (Effectieve bedrijfscontinuïteit en herstel na noodgevallen) profiteert van de mogelijkheden op platformniveau die aan deze vereisten voldoen, omdat we de oplossingsspecifieke mechanismen gebruiken. Als u BCDR-mogelijkheden wilt ontwerpen, legt u dr-vereisten (Platform Disaster Recovery) 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 componenten in de nabijheid voor betere prestaties. Mogelijk ondervindt u toepassingsbewerkingen met verminderde functionaliteit of verminderde prestaties tijdens een storing.
Notitie
De toepassing weet mogelijk van nature te draaien, of bepaalde onderdelen kunnen draaien op 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 niet over deze functionaliteit beschikken; Bijvoorbeeld een front-end- of back-endoplossing, waarin u de front-ends in Azure Stack Hub-omgevingen kunt implementeren.
Vermijd overlappende IP-adresbereiken in productie- en rampenherstel-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 biedt met alle sites.
De grootte van uw doelomgevingen aanpassen:
- Als u de bron en het doel op een 1:1-manier gebruikt, wijst u iets meer opslag toe aan uw doelomgeving. Dit komt door de manier waarop de geschiedenis van de schijfbladwijzers plaatsvindt. Deze toewijzing is geen toename van 2x, omdat deze alleen wijzigingen in de gegevens bevat. Afhankelijk van het type gegevens en de verwachte wijzigingen, zorgt een replicatiebeleid met 1,5 tot 2 keer meer opslagruimte op de doelomgeving ervoor dat failoverprocessen geen zorgen opleveren.
- 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 uitvallen; bijvoorbeeld welke bron voorrang 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 hele workloads te verplaatsen om de stromen end-to-end te valideren.