Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Som organisation är det absolut nödvändigt 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å den primära platsen redundansväxlar du till en sekundär plats för att få åtkomst till dina appar. Så snart den primära webbplatsen 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-tjänstleverantören 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 RPOs.
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 den virtuella Azure Site Recovery-installationen. Den virtuella datorn är en Standard_DS4_v2 (8 vCPU:er, 28 GB minne, 32 datadiskar) som körs i Azure Stack Hub-användarprenumerationen.
Tänk på följande områden i källmiljön:
Kvot:
- Du bör ha tillräcklig kvot för att skapa den virtuella Azure Site Recovery-installationen. Du behöver en eller flera, beroende på den övergripande planen.
Lagring för den virtuella Azure Site Recovery VM-installationen:
Själva Azure Site Recovery VM-installationen har de datakrav som definieras av den virtuella datorns storlek.
När du planerar för kapacitet, se till att appliance-VM:n har tillräckligt med lagringsutrymme för att verkställa återställnings- och skyddsmekanismerna efter fel.
Anmärkning
Om det finns lagringsbegränsningar kan återställning och skyddsåtgärder misslyckas med ett felmeddelande: 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.
Överväganden för målsättningar
I målmiljön finns det två delar att tänka på för kapacitetsplanering:
Krav 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 några 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-resursprovidern (RP).
Anmärkning
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 administratörsprenumerationen för Azure Stack Hub och hanteras av själva Azure Stack Hub. Därför krävs ingen konfiguration. Men precis som med alla tjänster förbrukar dessa resurser minne, lagring och har vissa vCPU:er allokerade:
| Tjänster | virtuell kärna | Minne | Diskstorlek |
|---|---|---|---|
| Azure Site Recovery (återställningstjänst för webbplatser) | 18 | 64 GB | 384 GB |
Anmärkning
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 genomströmning i målmiljön som Azure Site Recovery kan få 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 avsätts.
Överväganden för lagring:
- 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 målprenumerationer för Azure Stack Hub-användare, så att användarna har tillräcklig allokering.
- Cachelagringskontot för replikering.
Beräkningsöverväganden:
- När redundansväxlingen inträffar startas de virtuella datorerna på målanvändarprenumerationerna i Azure Stack Hub. 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 skydd av den virtuella datorn förbrukas inga VM-relaterade resurser som vCPU, minne osv. i målmiljön. Dessa resurser blir endast relevanta under en redundansväxlingsprocess, till exempel redundanstest.
För omfattningen av Azure Site Recovery på Azure Stack Hub är detta en utgångspunkt för beräkningar, särskilt för det använda cachelagringskontot:
Om det sker en failover multiplicerar du antalet diskar som replikeras med det genomsnittliga RPO:et under normal drift. Du kan till exempel ha (2 MB * 250 s). Cachelagringskontot är normalt några KB till 500 MB per disk.
Vid en redundansväxling, givet ett värsta scenario, multiplicera antalet diskar som replikeras med det genomsnittliga RPO över en hel dag.
Viktigt!
Om vissa delar av Azure Site Recovery inte fungerar, men andra fungerar, kan det som mest finnas en dags difflog i lagringskontot innan Azure Site Recovery stänger av på grund av tidsgräns.
Återställning efter fel till den nya virtuella datorn. Beräkna summan av diskarnas storlek 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 | Total genomströmning | Totalt OPS | Flaskhals |
|---|---|---|---|
| 68 | 136 MB/s | 68 | lagring |
| 60 | 120 MB/s | 2048 | lagring |
| 28 | 28 MB/s | 3584 | Cpu och minne för Azure Site Recovery |
| 16 | 32 MB/s | 4096 |
Anmärkning
8 kB ä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 totalt uppgår till 1 MB/s per disk. Det här scenariot är troligtvis inte under 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 testade vi även scenarier med:
- 120 virtuella datorer (80 Windows, 40 Linux) som skyddas via samma Azure Site Recovery VM-installation.
Varje virtuell dator genererar vid slumpmässiga tillfällen, minst två gånger per timme, slumpmässiga datamängder på totalt 5 GB fördelat på fem filer.
Replikeringen lyckades på alla 120 virtuella datorer med låg till medelhög belastning på Azure Site Recovery-tjänsterna.
Anmärkning
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 första. 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 de lösningsspecifika mekanismerna. För att utforma BCDR-funktioner bör du fånga upp plattformens krav på haveriberedskap (DR) och överväga 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 övergång vid fel, med komponentnära placering för prestanda. Du kan uppleva programåtgärder med nedsatt funktionalitet eller försämrad prestanda under ett avbrott.
Anmärkning
Programmet kanske vet att det körs internt eller har 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. Planera om möjligt för en BCDR-nätverksarkitektur som ger samtidig anslutning till alla platser.
Storleksbedömning av dina målmiljöer:
- 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 hanteras. Den här allokeringen är inte en ökning på 2 gånger, eftersom den bara innehåller ändringar i data. Beroende på typen av data, de förväntade ändringarna och replikeringsprinciperna, ser du till att ha 1,5 till 2 gånger mer lagring på målet för att säkerställa att failover-processerna 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/Test-datorerna 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 tillgängliga för att starta de skyddade virtuella datorerna.
Du bör testa BCDR och validera regelbundet. Du kan göra detta genom att använda redundanstestprocesser eller genom att flytta hela arbetsbelastningarna för att verifiera flödena från slutpunkt till slutpunkt.