Kapacitetsplanering med Azure Site Recovery
Som organisation är det viktigt att anta en strategi för affärskontinuitet och haveriberedskap (BCDR) som håller dina data säkra, tillgängliga appar och arbetsbelastningar online under planerade och oplanerade avbrott.
Genom replikering av arbetsbelastningar för virtuella datorer (VM) från en primär plats till en sekundär plats tillhandahåller Azure Site Recovery på Azure Stack Hub tjänster som kan stödja säkerheten för organisationsdata, programtillgänglighet och arbetsbelastningar under avbrott. När ett avbrott till exempel inträffar på din primära plats redundansväxlar du till en sekundär plats för att komma åt dina appar. Så snart den primära platsen körs igen kan du återgå till den. Mer information finns i Om Site Recovery.
Om du vill aktivera replikering av virtuella datorer över två Azure Stack Hub-stämplar konfigurerar du två miljöer:
-
Källmiljö :
- Azure Stack Hub-stämpeln där virtuella klientdatorer körs.
-
Målmiljö :
- Där Azure Site Recovery-resursprovidern körs.
En viktig komponent för att lyckas med en plan för affärskontinuitet och haveriberedskap är kapacitetsplanering. Under kapacitetsplaneringen finns det några faktorer att tänka på:
Mål för återställningstid (RTO) och mål för återställningspunkter (RPO) för de specifika arbetsbelastningar som du vill skydda.
Arbetsbelastningar och programegenskaper:
- Hur ofta data ändras inom respektive virtuell dator.
- Hur mycket data genereras eller tas bort?
- Hur ser programdesignen ut och mer?
VM-storlekar, antalet diskar och hur varje virtuell dator är knuten till andra virtuella datorer.
- För lösningar som kräver flera virtuella datorer kan du förstå i vilken ordning de virtuella datorerna måste startas.
Nätverksbandbredd mellan käll- och målmiljöerna. Den här komponenten kan påverka RRPOs.
Var och en av dessa punkter är viktig och har stora konsekvenser när du skapar en BCDR-plan.
I följande avsnitt visas de viktigaste punkterna att tänka på ur ett Azure-Site Recovery perspektiv. Varje BCDR-plan är olika och baseras på detaljerna i de arbetsbelastningar som du planerar att skydda. Därför är den här listan inte omfattande.
Källöverväganden
I källmiljön kör Azure Stack Hub azure Site Recovery VM-installationen. Den virtuella datorn är en Standard_DS4_v2 (8 virtuella processorer, 28 GB minne, 32 datadiskar) som körs i Azure Stack Hub-användarprenumerationen.
Överväg följande områden i källmiljön:
Kvoten:
- Du bör ha tillräcklig kvot för att skapa Azure Site Recovery VM-installationen. Du behöver en eller flera, beroende på den övergripande planen.
Lagring för Azure Site Recovery VM-installation:
Själva Azure Site Recovery VM-installationen har de datakrav som definieras av den virtuella datorns storlek.
När du planerar för kapacitet kontrollerar du att den virtuella datorn för installationen har tillräckligt med lagringsutrymme för att använda mekanismerna för återställning efter fel och återskydd.
Anteckning
Om det finns lagringsbegränsningar kan återställning och återskydd misslyckas med ett fel Ett internt fel uppstod . Användarna bör kontrollera händelseloggarna på installationen för att bekräfta det faktiska Azure-Resource Manager felet. Mer information finns i Kända problem för Azure Site Recovery.
Bandbredd:
- Den inledande replikeringen genererar hög bandbreddsanvändning.
- Ändringar på varje virtuell dator replikeras beroende på replikeringsprinciperna och varje typ av program.
Målöverväganden
I målmiljön finns det två delar att tänka på för kapacitetsplanering:
Kraven för Azure Site Recovery-tjänsten: hur mycket som förbrukas för att köra Azure Site Recovery, utan att nödvändigtvis skydda arbetsbelastningar.
Kraven för skyddade arbetsbelastningar.
Målmiljön kräver att ett Azure-Site Recovery-valv skapas för varje Site Recovery installation för att skydda virtuella datorer från källan (en installation per valv). Även om detta inte är en begränsning ur ett kapacitetsperspektiv bör det beaktas när du planerar utformningen av den övergripande miljön.
Azure Site Recovery RP-resurser
Installationen av Azure Site Recovery på Azure Stack Hub kräver att du installerar Site Recovery Resource Provider (RP).
Anteckning
Med Microsoft.SiteRecovery-1.2301.2216.2287 kräver Azure Site Recovery på Azure Stack Hub inte Event Hubs som beroende.
Den här tjänsten skapas i Azure Stack Hub-administratörsprenumerationen och hanteras av Själva Azure Stack Hub, och därför krävs ingen konfiguration. Men som med alla tjänster förbrukar dessa resurser minne, lagring och har vissa vCPU:er allokerade:
| Tjänst | V-kärna | Minne | Diskstorlek |
|---|---|---|---|
| Azure Site Recovery | 12 | 42 GB | 1,4 TB |
Anteckning
Dessa resurser är Azure Stack Hub-tjänster på administrationssidan av Azure Stack Hub. När plattformen har installerats hanterar den dessa resurser.
Skyddade arbetsbelastningar
När du skapar BCDR-planen bör du överväga alla aspekter av de skyddade arbetsbelastningarna. Följande lista är inte fullständig och bör behandlas som en startpunkt:
VM-storlek, antal diskar, diskstorlek, IOPS, dataomsättning och nya data som skapats.
Överväganden för nätverksbandbredd:
- Nätverksbandbredden som krävs för deltareplikering.
- Mängden dataflöde i målmiljön som Azure Site Recovery kan hämta från källmiljön.
- Antalet virtuella datorer som ska batchas åt gången. Det här talet baseras på den uppskattade bandbredden för att slutföra den inledande replikeringen under en viss tidsperiod.
- Det RPO som kan uppnås för en viss bandbredd.
- Effekten på önskat RPO om lägre bandbredd etableras.
Lagringsöverväganden:
- Hur mycket data som krävs för den inledande replikeringen.
- Hur många återställningspunkter som lagras och hur data ökar för varje skyddad virtuell dator under dessa intervall.
- Hur många kvoter som måste tilldelas till azure Stack Hub-målanvändarprenumerationer så att användarna har tillräcklig allokering.
- Cachelagringskontot för replikering.
Beräkningsöverväganden:
- När redundansväxling sker startas de virtuella datorerna på azure Stack Hub-målanvändarprenumerationer. Det måste finnas tillräckligt med kvotallokering för att kunna starta dessa VM-resurser.
- När den skyddade virtuella datorn är aktiv i källmiljön under skyddet av den virtuella datorn förbrukas inga VM-relaterade resurser som vCPU, minne osv. i målmiljön. Dessa resurser blir bara relevanta under en redundansväxlingsprocess, till exempel redundanstest.
Omfånget för Azure Site Recovery på Azure Stack Hub är här en startpunkt för beräkningar, särskilt för det cachelagringskonto som används:
Om det sker en redundansväxling multiplicerar du antalet diskar som replikeras med det genomsnittliga RPO:et under normala åtgärder. Du kan till exempel ha (2 MB * 250s). Cachelagringskontot är normalt några KB till 500 MB per disk.
Om det sker en redundansväxling, givet ett värsta scenario, multiplicerar du antalet diskar som replikeras med det genomsnittliga RPO:et under en hel dag.
Viktigt
Om vissa delar av Azure Site Recovery inte fungerar, men andra arbetar, kan det finnas högst en dag med difflog i lagringskontot innan Azure Site Recovery bestämmer sig för att överskrida tidsgränsen.
Återställning efter fel till den nya virtuella datorn. Beräkna summan av diskstorleken för varje batch.
- Hela disken måste kopieras till cachelagringskontot för att den virtuella måldatorn ska tillämpas, eftersom målet är en tom disk.
- Associerade data tas bort när de har kopierats, men det är troligt att användningen är hög med summan av alla diskstorlekar.
Skapa BDCR-planen baserat på detaljerna i den lösning som du försöker skydda.
Följande tabell är ett exempel på tester som körs i våra miljöer. Du kan använda den här insikten för att få en baslinje för ditt eget program, men varje arbetsbelastning skiljer sig åt:
Konfiguration
| Blockstorlek | Dataflöde/disk |
|---|---|
| 2 MB | 2 MB/s |
| 64 kB | 2 MB/s |
| 8 kB | 1 MB/s |
| 8 kB | 2 MB/s |
Resultat
| Antal diskar som stöds | Totalt dataflöde | Totalt ANTAL OPS | Flaskhals |
|---|---|---|---|
| 68 | 136 MB/s | 68 | storage |
| 60 | 120 MB/s | 2048 | storage |
| 28 | 28 MB/s | 3584 | Azure Site Recovery cpu och minne |
| 16 | 32 MB/s | 4096 |
Anteckning
8Kb är den minsta blockstorleken för data som Azure Site Recovery stöder. Ändringar som är mindre än 8 KB behandlas som 8 KB.
För att testa ytterligare genererade vi en konsekvent typ av arbetsbelastning. Till exempel konsekventa lagringsändringar i block på 8 kB som uppgår till upp till 1 MB/s per disk. Det här scenariot är inte troligt i en verklig arbetsbelastning, med tanke på att ändringar kan ske vid olika tidpunkter på dagen eller i toppar av olika storlekar.
För att replikera dessa slumpmässiga mönster har vi även testat scenarier med:
- 120 virtuella datorer (80 Windows, 40 Linux) som skyddas via samma Azure Site Recovery VM-installation.
Varje virtuell dator som genereras med slumpmässiga intervall, minst två gånger per timme, blockerar slumpmässiga block på totalt 5 GB data i fem filer.
Replikeringen lyckades på alla 120 virtuella datorer med låg till medelhög belastning på Azure Site Recovery-tjänsterna.
Anteckning
Dessa tal ska endast användas som baslinje. De skalas inte nödvändigtvis linjärt. Att lägga till en annan batch med samma antal virtuella datorer kan ha mindre inverkan än den ursprungliga. Resultaten är mycket beroende av vilken typ av arbetsbelastningar som används.
Hur ska du planera och testa
Program och lösningsarbetsbelastningar har vissa krav på mål för återställningstid (RTO) och mål för återställningspunkter (RPO). Effektiv bcdr-design (affärskontinuitet och haveriberedskap) utnyttjar båda funktionerna på plattformsnivå som uppfyller dessa krav, eftersom vi använder lösningsspecifika mekanismer. Om du vill utforma BCDR-funktioner samlar du in krav för haveriberedskap (DR) för plattformen och överväger alla dessa faktorer i din design:
Krav för program- och datatillgänglighet:
- RTO- och RPO-krav för varje arbetsbelastning.
- Stöd för aktiva och aktiva-passiva tillgänglighetsmönster.
Stöd för distributioner i flera regioner för redundans, med komponentnäring för prestanda. Du kan uppleva programåtgärder med nedsatt funktionalitet eller försämrad prestanda under ett avbrott.
Anteckning
Programmet kan vara inbyggt känt för att köras på eller ha vissa komponenter som kan köras i flera Azure Stack Hub-miljöer. I så fall kan du använda Azure Site Recovery för att replikera endast de virtuella datorerna med de komponenter som inte har den här funktionen, till exempel en klientdels- eller serverdelslösning där du kan distribuera klientdelarna i Azure Stack Hub-miljöer.
Undvik att använda överlappande IP-adressintervall i produktions- och DR-nätverk.
- Produktions- och DR-nätverk som har överlappande IP-adresser kräver en redundansväxlingsprocess som kan komplicera och fördröja programredundans. När det är möjligt bör du planera för en BCDR-nätverksarkitektur som ger samtidig anslutning till alla platser.
Ändra storlek på målmiljöerna:
- Om du använder källan och målet på ett 1:1-sätt allokerar du lite mer lagringsutrymme i målmiljön. Detta beror på hur historiken för diskbokmärken sker. Den här allokeringen är inte en ökning med 2 gånger, eftersom den bara innehåller ändringar av data. Beroende på vilken typ av data och vilka ändringar som förväntas och replikeringsprinciper som har en lagring på 1,5 x till 2 gånger mer på målet ser du till att redundansväxlingsprocesserna inte medför några problem.
- Du kan överväga att ha Azure Stack Hub-målmiljön som mål för flera Azure Stack Hub-källor. I det här fallet sänker du den totala kostnaden, men måste planera för vad som händer när vissa arbetsbelastningar går ned. till exempel vilken källa som måste prioriteras.
- Om målmiljön används för att köra andra arbetsbelastningar måste BCDR-planen innehålla beteendet för dessa arbetsbelastningar. Du kan till exempel köra de virtuella dev-/testdatorerna i målmiljön, och om ett problem uppstår med källmiljön kan du inaktivera alla virtuella datorer på målet för att säkerställa att det finns tillräckligt med resurser för att starta de skyddade virtuella datorerna.
Du bör testa BCDR och validera regelbundet. Du kan göra detta med hjälp av redundanstestprocesser eller genom att flytta hela arbetsbelastningarna för att verifiera flödena från slutpunkt till slutpunkt.