Haveriberedskap för virtuella Azure Stack Hub-datorer

Den här artikeln beskriver arkitektur- och designöverväganden för en lösning som ger en optimerad metod för haveriberedskap för arbetsbelastningar som körs på virtuella datorer som finns på Azure Stack Hub.

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

Molnkomponenterna i den föreslagna lösningen innehåller följande tjänster:

• En Azure-prenumeration som är värd för alla molnresurser som ingår i den här lösningen.

• En Microsoft Entra ID-klientorganisation som är associerad med Azure-prenumerationen som tillhandahåller autentisering av Microsoft Entra-säkerhetsobjekt för att auktorisera åtkomst till Azure-resurser.

• Ett Azure Recovery Services-valv i Azure-regionen som ligger närmast ett lokalt datacenter som är värd för Azure Stack Hub-distributionen.

  Kommentar

  Valet av Den Azure-region som ligger närmast det lokala datacentret är specifikt för det exempelscenario som ingår i den här artikeln. Ur haveriberedskapssynpunkt är det bättre att välja en Azure-region som är längre bort från den plats som är värd för produktionsmiljön. Beslutet kan dock bero på andra faktorer, till exempel behovet av att minimera svarstiden för regionala dataflöden eller uppfylla kraven på datahemvist.

• En Azure ExpressRoute-krets som ansluter de lokala datacenter till Azure-regionen som är värd för Azure Recovery Services-valvet, konfigurerat med privat peering och Microsoft-peering. Den förstnämnda ser till att svarstidskraven uppfylls efter en redundansväxling. Syftet med det senare är att minimera den tid det tar att replikera ändringar mellan de lokala arbetsbelastningarna och redundansplatsen i Azure.

• Ett Azure Storage-konto som innehåller blobar som innehåller de VHD-filer som skapas genom replikering av operativsystemet och datavolymerna för skyddade virtuella Azure Stack Hub-datorer. Dessa VHD-filer fungerar som källa för de hanterade diskarna för virtuella Azure-datorer som etableras automatiskt efter en redundansväxling.

• Ett virtuellt Azure-nätverk som är värd för haveriberedskapsmiljön. Den konfigureras på ett sätt som speglar den virtuella nätverksmiljön i Azure Stack Hub som är värd för produktionsarbetsbelastningarna, inklusive komponenter som lastbalanserare och nätverkssäkerhetsgrupper. Det här virtuella nätverket är vanligtvis anslutet till det virtuella Azure Stack Hub-nätverket via en ExpressRoute-anslutning för att underlätta återställning på arbetsbelastningsnivå.

  Kommentar

  Ibland räcker det med en VPN-anslutning från plats till plats i scenarier där kraven på mål för återställningspunkt (RPO) är mindre stränga.

• Ett isolerat virtuellt Azure-nätverk som är avsett för redundanstestning, konfigurerat på ett sätt som speglar den virtuella nätverksmiljön i Azure Stack Hub som är värd för produktionsarbetsbelastningarna, inklusive komponenter som lastbalanserare och nätverkssäkerhetsgrupper.

De lokala komponenterna i den föreslagna lösningen omfattar följande tjänster:

• Ett integrerat Azure Stack Hub-system i den anslutna distributionsmodellen. Systemet kör den aktuella uppdateringen (2002 från och med den 9/20) och finns i kundens lokala datacenter.

• En Azure Stack Hub-prenumeration och ett virtuellt nätverk, eller flera peer-kopplade virtuella nätverk, som är värdar för alla lokala virtuella datorer för den här lösningen.

• Konfigurations- och processservrar för Azure Site Recovery som körs på virtuella Datorer med Windows Server 2016 eller 2012 R2 Azure Hub Stack. Servrarna hanterar kommunikation med Azure Recovery Services-valvet och routning, optimering och kryptering av replikeringstrafik.

  Kommentar

  Som standard är en konfigurationsserver värd för en enda processserver. Du kan distribuera dedikerade processerver för att hantera en större mängd replikeringstrafik.

• De virtuella Azure Stack Hub-datorer som ska skyddas. De kör versioner som stöds av operativsystemen Windows Server, CentOS och Ubuntu.

• Site Recovery-tjänsten Mobility (kallas även mobilitetsagent) som körs på skyddade virtuella datorer. Den spårar ändringar av lokala diskar, registrerar ändringarna i replikeringsloggarna och replikerar loggarna till processervern. Processservern dirigerar dem till azure-mållagringskontot. Loggarna används för att skapa återställningspunkter för hanterade diskar som implementeras med hjälp av blobar som lagras i det Azure-lagringskonto som du anger.

Komponenter

• Microsoft Entra ID
• Azure Virtual Network
• Azure Recovery Services
• Azure ExpressRoute
• Azure Blob Storage
• Azure Stack Hub

Alternativ

Den rekommenderade lösningen som beskrivs i den här artikeln är inte det enda sättet att tillhandahålla funktioner för haveriberedskap för vm-baserade arbetsbelastningar i Azure Stack Hub. Kunder har andra alternativ, inklusive:

• En redundansväxling till en annan Azure Stack Hub-stämpel. Användare som behöver skydda mot ett datacenter eller ett platsstopp kanske kan använda en annan Azure Stack Hub-distribution för att implementera haveriberedskapsbestämmelser. Med primära och sekundära platser kan användare distribuera program i en aktiv/passiv konfiguration i två miljöer. För mindre kritiska arbetsbelastningar kan det vara acceptabelt att använda outnyttjad kapacitet på den sekundära platsen för att utföra återställning på begäran av program från säkerhetskopiering. Du kan också implementera en återställningsplats i ett annat datacenter, som i sin tur använder Site Recovery för att etablera en replik av återställningsplatsen i Azure. Flera faktorer avgör om användningen av Site Recovery med Azure som redundansplats är en fungerande lösning. Dessa faktorer omfattar myndighetsregler, företagsprinciper och svarstidskrav.

  Kommentar

  Från och med juli 2020 stöder Site Recovery inte det här scenariot, vilket innebär att implementeringen måste använda en partner eller intern lösning.

• Säkerhetskopiera och återställa. När du säkerhetskopierar dina program och datauppsättningar kan du snabbt återställa från driftstopp som beror på skadade data, oavsiktliga borttagningar eller lokaliserade avbrott. För Azure Stack Hub VM-baserade program kan du använda en gästagent för att skydda programdata, operativsystemkonfigurationer och data som lagras på volymer. Säkerhetskopiering av en virtuell dator med hjälp av en gästoperativsystemagent omfattar vanligtvis insamling av operativsystemkonfigurationer, filer, mappar, volymer, programbinärfiler och programdata. Återställning av ett program från en agent kräver återskapande av den virtuella datorn, följt av installation av operativsystemet och gästagenten. Då kan du återställa data till gästoperativsystemet.

• Säkerhetskopiering av diskögonblicksbilder. Det går att använda ögonblicksbilder för att avbilda en konfiguration av en virtuell Azure Stack Hub-dator och de diskar som är anslutna till en stoppad virtuell dator. Den här processen kräver säkerhetskopieringsprodukter som integreras med Azure Stack Hub-API:er för att samla in VM-konfiguration och skapa diskögonblicksbilder.

  Kommentar

  Från och med juli 2020 stöds inte användning av diskögonblicksbilder för en virtuell dator som körs. Om du skapar en ögonblicksbild av en disk som är ansluten till en virtuell dator som körs kan prestandan försämras eller påverka operativsystemets eller programmets tillgänglighet på den virtuella datorn.

• Säkerhetskopiera och återställa virtuella datorer med hjälp av en extern säkerhetskopieringslösning i samma datacenter och replikera sedan säkerhetskopiorna till en annan plats. På så sätt kan du återställa virtuella Azure Stack Hub-datorer till samma Azure Stack Hub-instans, till en annan eller till Azure.

Information om scenario

Azure Stack Hub innehåller självåterställningsfunktioner som ger automatisk reparation i en rad scenarier som omfattar lokaliserade fel i komponenterna. Storskaliga fel, inklusive avbrott som påverkar serverrack eller katastrofer på platsnivå, kräver dock ytterligare överväganden. Dessa överväganden bör ingå i strategin för affärskontinuitet och haveriberedskap för VM-baserade användararbetsbelastningar. Den här strategin måste också ta hänsyn till återställningen av Azure Stack-infrastrukturen, som är separat från arbetsbelastningsåterställning.

Traditionella lokala återställningslösningar för arbetsbelastningar är komplexa för att konfigurera, dyra och arbetsintensiva att underhålla och svåra att automatisera, särskilt när du använder en annan lokal plats som redundanswebbplats. Microsoft rekommenderar en alternativ lösning som förlitar sig på en kombination av molnkomponenter och lokala komponenter för att leverera motståndskraftiga, prestandabaserade, högautomatiserade och enkla sätt att implementera, skydda och hantera en kostnadseffektiv strategi för haveriberedskap. Kärnelementet i den här lösningen är Site Recovery, där redundansplatsen finns i Azure.

Potentiella användningsfall

Site Recovery med Azure som redundanswebbplats eliminerar alla ovan nämnda nackdelar. Du kan använda dess funktioner för att skydda både fysiska och virtuella servrar, inklusive de som körs på microsoft Hyper-V- eller VMware ESXi-virtualiseringsplattformar. Du kan också använda samma funktioner för att underlätta återställningen av arbetsbelastningar som körs på virtuella Azure Stack Hub-datorer.

Kärnfunktioner

Site Recovery är en haveriberedskapslösning som underlättar skyddet av fysiska och virtuella datorer genom att tillhandahålla två uppsättningar funktioner:

• Replikering av ändringar av datordiskar som finns mellan produktions- och haveriberedskapsplatserna
• Orkestrering av redundans och återställning efter fel mellan dessa två platser

Site Recovery erbjuder tre typer av redundansväxlingar:

• Testa redundans. Den här redundansväxlingen ger dig möjlighet att verifiera din Site Recovery-konfiguration i en isolerad miljö, utan dataförlust eller påverkan på produktionsmiljön.
• Planerad redundans. Den här redundansväxlingen ger dig möjlighet att initiera haveriberedskap utan dataförlust, vanligtvis som en del av planerad stilleståndstid.
• Oplanerad redundans. Den här redundansväxlingen fungerar som den sista utvägen om ett oplanerat avbrott påverkar tillgängligheten för den primära platsen och kan leda till dataförlust.

Site Recovery stöder flera scenarier, till exempel redundansväxling och återställning efter fel mellan två lokala platser, redundans och återställning efter fel mellan två Azure-regioner och migrering från moln från tredjepartsleverantörer. I den här artikeln fokuserar vi dock på replikering av lokala diskar av virtuella Azure Stack Hub-datorer till Azure Storage, redundansväxling och återställning efter fel mellan en Azure Stack Hub-stack och en Azure-region.

Information om Site Recovery-arkitekturen och dess komponenter beror på ett antal kriterier, bland annat:

• De typer av datorer som ska skyddas (fysiska eller virtuella).
• För virtualiserade miljöer är typen av hypervisor som är värd för de virtuella datorer som ska skyddas (Hyper-V jämfört med VMware ESXi).
• För Hyper-V-miljöer använder du System Center Virtual Machine Manager (SCVMM) för hantering av Hyper-V-värdar.

Med Azure Stack Hub matchar arkitekturen den som gäller för fysiska datorer. Detta är inte särskilt förvånande, eftersom Site Recovery i båda fallen inte kan dra nytta av direkt åtkomst till ett hypervisor-program. I stället implementeras den mekanism som spårar och replikerar ändringar till lokala diskar i det skyddade operativsystemet.

För att åstadkomma detta förlitar sig Site Recovery på Site Recovery-tjänsten Mobility (kallas även mobilitetsagent), som automatiskt distribueras till enskilda virtuella datorer när du registrerar dem i omfånget för Site Recovery-baserat skydd. På varje skyddad virtuell dator övervakar och vidarebefordrar den lokalt installerade instansen av mobilitetsagenten kontinuerligt ändringar till operativsystemet och datadiskarna till processervern. För att optimera och hantera flödet av replikeringstrafik från skyddade virtuella datorer implementerar Site Recovery dock ytterligare en uppsättning komponenter som körs på en separat virtuell dator, som kallas konfigurationsservern.

Konfigurationsservern samordnar kommunikationen med Site Recovery-valvet och hanterar datareplikering. Dessutom är konfigurationsservern värd för en komponent som kallas processserver, som fungerar som en gateway, tar emot replikeringsdata, optimerar den genom cachelagring och komprimering, krypterar den och slutligen vidarebefordrar den till Azure Storage. Konfigurationsservern fungerar i praktiken som integrationsplats mellan Site Recovery och skyddade virtuella datorer som körs på Azure Stack Hub. Du implementerar den integreringen genom att distribuera konfigurationsservern och registrera den med Azure Recovery Services-valvet.

Som en del av Site Recovery-konfigurationen definierar du den avsedda haveriberedskapsmiljön, inklusive infrastrukturkomponenter som virtuella nätverk, lastbalanserare eller nätverkssäkerhetsgrupper på det sätt som speglar produktionsmiljön. Konfigurationen innehåller också en replikeringsprincip som avgör återställningsfunktionerna och består av följande parametrar:

• Tröskelvärde för RPO. Den här inställningen representerar det önskade mål för återställningspunkter som du vill implementera och avgör i vilken frekvens Site Recovery genererar ögonblicksbilder av kraschkonsekventa återställningspunkter. Värdet påverkar inte replikeringsfrekvensen eftersom replikeringen är kontinuerlig. Site Recovery genererar en avisering, och eventuellt ett e-postmeddelande, om det aktuella effektiva RPO som tillhandahålls av Site Recovery överskrider det tröskelvärde som du anger. Site Recovery genererar ögonblicksbilder av kraschkonsekventa återställningspunkter var femte minut.

  Kommentar

  En krasch konsekvent ögonblicksbild samlar in data som fanns på disken när ögonblicksbilden togs. Den innehåller inte minnesinnehåll. I själva verket garanterar en kraschkonsekvent ögonblicksbild inte datakonsekvens för operativsystemet eller lokalt installerade appar.

• Kvarhållning av återställningspunkt. Den här inställningen representerar varaktigheten (i timmar) för kvarhållningsfönstret för varje ögonblicksbild av återställningspunkten. Skyddade virtuella datorer kan återställas till valfri återställningspunkt i ett kvarhållningsfönster. Site Recovery stöder upp till 24 timmars kvarhållning för virtuella datorer som replikeras till Azure Storage-konton med premiumprestandanivån. Det finns en kvarhållningsgräns på 72 timmar när du använder Azure Storage-konton med standardprestandanivån.

• Appkonsekvent ögonblicksbildsfrekvens. Den här inställningen avgör frekvensen (i timmar) där Site Recovery genererar programkonsekventa ögonblicksbilder. En appkonsekvent ögonblicksbild representerar en ögonblicksbild av program som körs i en skyddad virtuell dator. Det finns en gräns på 12 appkonsekventa ögonblicksbilder. För virtuella datorer som kör Windows Server använder Site Recovery tjänsten Volume Shadow Copy (VSS). Site Recovery stöder även appkonsekventa ögonblicksbilder för Linux, men det kräver implementering av anpassade skript. Skripten används av mobilitetsagenten när en appkonsekvent ögonblicksbild tillämpas.

  Kommentar

  Mer information om hur du implementerar appkonsekventa ögonblicksbilder på virtuella Azure Stack Hub-datorer som kör Linux finns i Allmänna frågor om Site Recovery.

För varje disk i en skyddad virtuell Azure Stack Hub-dator som du anger replikeras data till en motsvarande hanterad disk i Azure Storage. Disken lagrar kopian av källdisken och alla kraschkonsekventa och appkonsekventa ögonblicksbilder. Som en del av en redundansväxling väljer du en återställningspunkt med kraschkonsekvent eller appkonsekvent ögonblicksbild som ska användas när du kopplar den hanterade disken till den virtuella Azure-datorn, som fungerar som en replik av den skyddade virtuella Azure Stack Hub-datorn.

Under regelbundna affärsåtgärder körs skyddade arbetsbelastningar på virtuella Azure Stack Hub-datorer, med ändringar av deras diskar som kontinuerligt replikeras via interaktioner mellan mobilitetsagenten, processervern och konfigurationsservern till det avsedda Azure Storage-kontot. När du initierar ett test, en planerad eller oplanerad redundans etablerar Site Recovery automatiskt virtuella Azure-datorer med hjälp av repliker av diskar för motsvarande virtuella Azure Stack Hub-datorer.

Du har möjlighet att samordna en redundans genom att skapa återställningsplaner som innehåller manuella och automatiserade steg. För att implementera det senare kan du använda Azure Automation-runbooks, som består av anpassade PowerShell-skript, PowerShell-arbetsflöden eller Python 2-skript.

När den primära platsen blir tillgänglig igen har Site Recovery stöd för att återställa replikeringsriktningen, så att du kan utföra en återställning efter fel med minimerad stilleståndstid och utan dataförlust. Men med Azure Stack Hub är den här metoden inte tillgänglig. För att kunna återställa vid fel är det i stället nödvändigt att ladda ned diskfiler för virtuella Azure-datorer, ladda upp dem till Azure Stack Hub och koppla dem till befintliga eller nya virtuella datorer.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden som du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

Azure Stack Hub hjälper till att öka tillgängligheten för arbetsbelastningen genom återhämtning i infrastrukturen. Den här återhämtningsförmågan ger hög tillgänglighet för virtuella Azure Stack Hub-datorer som skyddas av Site Recovery och viktiga komponenter i den lokala Site Recovery-infrastrukturen, inklusive konfigurations- och processservrarna.

På samma sätt kan du använda återhämtning för molnbaserade komponenter i Site Recovery-infrastrukturen. Som standard är Azure Recovery Services geo-redundant, vilket innebär att dess konfiguration automatiskt replikeras till en Azure-region som ingår i ett fördefinierat regionpar. Du kan ändra replikeringsinställningarna till lokalt redundanta om det räcker för dina återhämtningsbehov. Observera att du inte kan ändra det här alternativet om valvet innehåller några skyddade objekt. Samma återhämtningsalternativ är tillgängligt för alla Azure Storage-konton med standardprestandanivån, även om det är möjligt att ändra det när som helst.

Du kan ytterligare förbättra graden av denna återhämtning genom att utforma och implementera lösningar som utökar arbetsbelastningsskyddets omfattning. Det här är det mervärde som tillhandahålls av Site Recovery. När det gäller Site Recovery som körs på Azure Stack Hub finns det två huvudsakliga aspekter av arbetsbelastningstillgänglighet som behöver utforskas mer detaljerat:

• Redundansväxla till Azure
• Återställning efter fel till Azure Stack Hub

Du måste tänka på både när du utvecklar en strategi för haveriberedskap som drivs av mål för återställningspunkter och mål för återställningstid . RTO och RPO representerar kontinuitetskrav som anges av enskilda affärsfunktioner inom en organisation. RPO anger en tidsperiod som representerar maximal acceptabel dataförlust efter en incident som påverkade tillgängligheten för dessa data. RTO anger den maximala acceptabla varaktighet som det kan ta att återställa affärsfunktioner efter en incident som påverkade tillgängligheten för dessa funktioner.

Redundansväxla till Azure

Redundansväxling till Azure är kärnan i tillgänglighetsöverväganden i samband med Site Recovery-baserat skydd av virtuella Azure Stack Hub-datorer. För att maximera arbetsbelastningstillgängligheten bör redundansstrategin hantera både behovet av att minimera potentiell dataförlust (RPO) och minimera redundanstiden (RTO).

För att minimera potentiella dataförluster kan du överväga:

• Maximera dataflödet och minimera svarstiden för replikeringstrafiken genom att följa skalbarhets- och prestandaöverväganden. Mer information finns i nästa avsnitt i den här artikeln.
• Öka frekvensen för appkonsekventa återställningspunkter för databasarbetsbelastningar (upp till högst en återställningspunkt per timme). Appkonsekventa återställningspunkter skapas från appkonsekventa ögonblicksbilder. Appkonsekventa ögonblicksbilder samlar in appdata på disk och i minnet. Även om den här metoden minimerar potentiell dataförlust har den en stor nackdel. Appkonsekventa ögonblicksbilder kräver användning av Volume Shadow Copy Service i Windows eller anpassade skript i Linux för att skapa lokalt installerade appar. Insamlingsprocessen kan skada prestanda, särskilt om resursanvändningen är hög. Vi rekommenderar inte att du använder låg frekvens för appkonsekventa ögonblicksbilder för icke-databasarbetsbelastningar.

Den primära metoden för att minimera redundanstiden är att använda Site Recovery-återställningsplaner. En återställningsplan samordnar en redundans mellan de primära och sekundära platserna och definierar sekvensen där skyddade servrar redundansväxlar. Du kan anpassa en plan genom att lägga till manuella instruktioner och automatiserade uppgifter. Dess syfte är att göra processen konsekvent, korrekt, repeterbar och automatiserad.

När du skapar en återställningsplan tilldelar du skyddade servrar till återställningsgrupper i redundanssyfte. Servrar i varje grupp redundansväxlar tillsammans. Detta hjälper dig att dela upp redundansprocessen i mindre, enklare att hantera enheter, vilket representerar uppsättningar servrar som kan redundansväxla utan att förlita sig på externa beroenden.

För att minimera redundanstiden bör du som en del av skapandet av en återställningsplan:

• Definiera grupper av virtuella Azure Stack Hub-datorer som ska redundansväxla tillsammans.
• Definiera beroenden mellan grupper av virtuella Azure Stack Hub-datorer för att fastställa den optimala sekvensen för en redundansväxling.
• Automatisera redundansaktiviteter om möjligt.
• Inkludera anpassade manuella åtgärder om det behövs.

Du definierar en återställningsplan och skapar återställningsgrupper för att samla in appspecifika egenskaper. Låt oss till exempel överväga en traditionell app med tre nivåer med en SQL Server-baserad serverdel, en mellanprogramskomponent och en webbklientdel. När du skapar en återställningsplan kan du styra startordningen för servrar på varje nivå, där servrarna som kör SQL Server-instanser kommer online först, följt av servrarna på mellanprogramsnivån och därefter ansluts av servrar som är värdar för webbklientdelen. Den här sekvensen säkerställer att appen fungerar när den senaste servern startar. För att implementera den kan du helt enkelt skapa en återställningsplan med tre återställningsgrupper som innehåller servrar på respektive nivå.

Förutom att kontrollera redundans och startordning har du också möjlighet att lägga till åtgärder i en återställningsplan. I allmänhet finns det två typer av åtgärder:

• Automatiserad. Den här åtgärden baseras på Azure Automation-runbooks, som omfattar en av två typer av uppgifter:
  • Etablering och konfiguration av Azure-resurser, till exempel att skapa en offentlig IP-adress och associera den med nätverksgränssnittet som är kopplat till en virtuell Azure-dator.
  • Ändra konfigurationen av operativsystemet och programmen som körs på en virtuell Azure-dator som etablerades efter en redundansväxling.
• Manuell. Den här åtgärden stöder inte automatisering och ingår i en återställningsplan främst i dokumentationssyfte.

Återställning efter fel till Azure Stack Hub

I Site Recovery-baserade scenarier innebär återställning efter fel, om det implementeras korrekt, inte dataförlust. Det innebär att fokus för redundansstrategin är att minimera återställningstiden (RTO). Men som tidigare nämnts kan du inte förlita dig på dina återställningsplaner när du inte kommer tillbaka till Azure Stack Hub. I stället omfattar återställning efter fel följande steg:

1. Stoppa och frigöra virtuella Azure-datorer i haveriberedskapsmiljön.
2. Identifiera URI-parametern för var och en av de hanterade diskar som är anslutna till de virtuella datorer som du tänker ladda ned.
3. Ladda ned de virtuella hårddiskfiler (VHD) som identifierades av de URI-parametrar som du identifierade i föregående steg till din lokala miljö.
4. Ladda upp VHD-filerna till Azure Stack Hub.
5. Koppla de uppladdade virtuella hårddiskarna till nya eller befintliga virtuella Azure Stack Hub-datorer.
6. Starta virtuella Azure Stack Hub-datorer.

Den optimala metoden för att minimera återställningstiden är att automatisera den.

Arbetsbelastningsspecifika överväganden

Site Recovery integreras med Windows Server-baserade appar och roller, inklusive SharePoint, Exchange, SQL Server och Active Directory-domän Services (AD DS). På så sätt kan du använda följande funktioner för att implementera skydd och återställning på appnivå:

• Integrering med replikeringstekniker på appnivå, till exempel SQL Server AlwaysOn-tillgänglighetsgrupper, Exchange Database-tillgänglighetsgrupper (DAG:er) och AD DS-replikering
• Appkonsekventa ögonblicksbilder för program på en eller flera nivåer
• Ett omfattande automationsbibliotek som tillhandahåller produktionsklara, programspecifika skript som kan laddas ned och integreras med återställningsplaner

Du kan också använda arbetsbelastningsspecifika replikeringsmekanismer för att ge återhämtning på platsnivå. Det här är ett vanligt alternativ när du implementerar haveriberedskap för AD DS-domänkontrollanter, SQL Server eller Exchange, som alla har inbyggt stöd för replikering. Även om detta kräver etablering av virtuella Azure-datorer som är värdar för dessa arbetsbelastningar i haveriberedskapsmiljön, vilket ökar kostnaden, erbjuder det följande fördelar:

• Minskar den tid som krävs för redundans och återställning efter fel
• Förenklar redundans på arbetsbelastningsnivå och rymmer scenarier där redundans på platsnivå inte krävs

Säkerhet

Att hantera haveriberedskap för användar-VM-baserade arbetsbelastningar i hybridscenarier kräver ytterligare säkerhetsöverväganden. Dessa överväganden kan grupperas i följande kategorier:

• Kryptering under överföring. Detta omfattar kommunikation mellan skyddade virtuella Azure Stack Hub-datorer, lokala Site Recovery-komponenter och molnbaserade Site Recovery-komponenter:

  • Mobilitetsagenten som är installerad på de skyddade virtuella datorerna kommunicerar alltid med processervern via TLS (Transport Layer Security) 1.2.
  • Det är möjligt för kommunikation från konfigurationsservern till Azure och från processervern till Azure att använda TLS 1.1 eller 1.0. Om du vill öka säkerhetsnivån för hybridanslutningar bör du överväga att tillämpa användningen av TLS 1.2.

  Kommentar

  Mer information om hur du konfigurerar TLS 1.2-baserad kryptering finns i registerinställningarna för Transport Layer Security (TLS) och Update för att aktivera TLS 1.1 och TLS 1.2 som standardsäkerhetsprotokoll i WinHTTP i Windows

• Kryptering i vila. Detta inkluderar virtuella Azure Storage- och Azure-datorer på haveriberedskapsplatsen.

  • Azure Storage krypteras i vila för alla lagringskonton med 256-bitars Krypteringsstandardkryptering och är federal informationsbearbetningsstandard 140-2 kompatibel. Kryptering aktiveras automatiskt och kan inte inaktiveras. Som standard använder kryptering Microsoft-hanterade nycklar, men kunder har möjlighet att använda sina egna nycklar som lagras i ett Azure Key Vault.
  • Hanterade diskar med virtuella Azure-datorer krypteras automatiskt med hjälp av kryptering på serversidan av Azure-hanterade diskar, som även gäller för deras ögonblicksbilder, genom att använda plattformshanterade krypteringsnycklar.

Dessutom kan du framtvinga begränsad åtkomst till Azure Storage-konton som är värd för innehåll på Site Recovery-replikerade diskar. Det gör du genom att aktivera den hanterade identiteten för Recovery Services-valvet och tilldela följande Rollbaserade åtkomstkontrollroller (Azure RBAC) för Den hanterade identiteten till den hanterade identiteten på Azure Storage-kontonivå:

• Resource Manager-baserade lagringskonton (standardprestandanivå):
  • Deltagare
  • Storage Blob datadeltagare
• Resource Manager-baserade lagringskonton (premiumprestandanivå):
  • Deltagare
  • Ägare av lagringsblobdata

Azure Recovery Services-valvet erbjuder mekanismer som ytterligare skyddar innehållet, inklusive följande skydd:

• Azure RBAC. Detta möjliggör delegering och uppdelning av ansvar enligt principen om lägsta behörighet. Det finns tre Site Recovery-relaterade inbyggda roller som begränsar åtkomsten till Site Recovery-åtgärder:
  • Site Recovery-deltagare. Den här rollen har alla behörigheter som krävs för att hantera Site Recovery-åtgärder i ett Azure Recovery Services-valv. En användare med den här rollen kan dock inte skapa eller ta bort valvet eller tilldela åtkomsträttigheter till andra användare. Den här rollen passar bäst för administratörer för haveriberedskap som kan aktivera och hantera haveriberedskap för en Azure Stack Hub-klientorganisation.
  • Site Recovery-operator. Den här rollen har behörighet att köra och hantera redundans- och återställningsåtgärder. En användare med den här rollen kan inte aktivera eller inaktivera replikering, skapa eller ta bort valv, registrera ny infrastruktur eller tilldela åtkomstbehörigheter till andra användare. Den här rollen passar bäst för en haveriberedskapsoperator som kan redundansväxla virtuella Azure Stack Hub-datorer när de instrueras av programägare och IT-administratörer i ett verkligt eller simulerat katastrofscenario.
  • Site Recovery-läsare. Den här rollen har behörighet att spåra alla Site Recovery-hanteringsåtgärder. Den här rollen passar bäst för IT-personal som ansvarar för att övervaka statusen för skyddade virtuella Azure Stack Hub-datorer och samla in supportärenden om det behövs.
• Azure-resurslås. Du har möjlighet att skapa och tilldela skrivskyddade och borttagningslås till ett Site Recovery-valv för att minska risken för att valvet oavsiktligt ändras eller tas bort.
• Mjuk borttagning. Syftet med mjuk borttagning är att skydda valvet och dess data från oavsiktliga eller skadliga borttagningar. Med mjuk borttagning behålls allt borttaget innehåll i ytterligare 14 dagar, vilket möjliggör hämtning under den perioden. Den extra kvarhållningen på 14 dagar av valvinnehåll medför ingen kostnad. Mjuk borttagning är aktiverat som standard.
• Skydd av säkerhetskänsliga åtgärder. Med Azure Recovery Services-valvet kan du aktivera ytterligare ett autentiseringslager när en säkerhetskänslig åtgärd, till exempel inaktivering av skydd, görs. Den här extra verifieringen hjälper till att säkerställa att behöriga användare utför sådana åtgärder.
• Övervakning och aviseringar om misstänkt aktivitet. Azure Recovery Services tillhandahåller inbyggd övervakning och avisering av säkerhetskänsliga händelser relaterade till valvåtgärderna.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

När du överväger kostnaden för den Site Recovery-baserade haveriberedskapslösningen som beskrivs i den här artikeln måste du ta hänsyn till både lokala och molnbaserade komponenter. Prismodellen för Azure Stack Hub avgör prissättningen för lokala komponenter. Precis som med Azure erbjuder Azure Stack Hub ett betala per användning-arrangemang som är tillgängligt via företagsavtal och Molnlösningsleverantör-programmet. Det här arrangemanget inkluderar ett månadspris för varje virtuell Windows Server-dator. Om du har möjlighet att använda befintliga Windows Server-licenser kan du avsevärt minska kostnaden för den virtuella datorns baspriser. Med Site Recovery behöver du dock vanligtvis bara en enda virtuell Azure Stack Hub-dator per klientorganisation, vilket krävs för att implementera den klientspecifika konfigurationsservern.

Azure-relaterade avgifter är associerade med användningen av följande resurser:

• Azure Recovery Services. Prissättningen bestäms av antalet skyddade instanser. Det är värt att notera att varje skyddad instans inte medför några Site Recovery-avgifter under de första 31 dagarna.

• Azure Storage. Prissättningen återspeglar en kombination av följande faktorer:

  • Prestandanivå
  • Lagrad datavolym
  • Volymen av utgående dataöverföring
  • Antal och typer av åtgärder som utförs (endast för standardprestandanivå)
  • Dataredundans (endast för standardprestandanivå)

• Azure ExpressRoute. Prissättningen baseras på en av två modeller:

  • Obegränsad data. Den här modellen innehåller en månatlig avgift där alla inkommande och utgående dataöverföringar ingår.
  • Avgiftsbelagda data. Den här modellen innehåller en månatlig avgift där alla inkommande dataöverföringar är kostnadsfria och utgående dataöverföringar debiteras per GB.

  Kommentar

  Den här utvärderingen inkluderar inte kostnaderna för fysiska anslutningar som levereras av tredjepartsanslutningsleverantörer.

• Virtuella Azure-datorer. Prissättningen för virtuella Azure-datorer återspeglar en kombination av två komponenter:

  • Beräkningskostnad. Vm-storleken, dess drifttid och licensieringsmodellen för operativsystemet avgör kostnaden.
  • Kostnad för hanterad disk. Diskstorleken och prestandanivån avgör kostnaden.

  Kommentar

  Det är värt att notera att hydrering eliminerar behovet av att köra virtuella Azure-datorer under regelbundna affärsåtgärder, med arbetsbelastningar som körs på Azure Stack Hub, vilket avsevärt minskar beräkningskostnaderna för Site Recovery-baserade implementeringar, särskilt jämfört med traditionella lösningar för haveriberedskap.

  Kommentar

  Priserna på resurser varierar mellan Azure-regioner.

  Kommentar

  Mer information om priser finns i Priser för Azure.

Driftsäkerhet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.

De viktigaste övervägandena när det gäller hanterbarhet för Site Recovery-baserad haveriberedskap för virtuella Azure Stack Hub-datorer är:

• Implementering av Site Recovery på Azure Stack Hub
• Redundans- och återställningsprocedurer
• Delegering av roller och ansvarsområden
• DevOps

Implementering av Site Recovery på Azure Stack Hub

Om du vill implementera Site Recovery på Azure Stack Hub i en liten till medelstor miljö med en enda klientorganisation kan du följa den manuella etableringsprocessen som drivs av det grafiska gränssnittet för Recovery Services Vault i Azure-portalen. För implementeringar med flera klientorganisationer kanske du vill överväga att automatisera delar av implementeringsprocessen, eftersom du vanligtvis behöver konfigurera en separat virtuell konfigurationsserver och ett separat Recovery Services-valv för varje klientorganisation. Du kan också välja att automatisera distributionen av mobilitetsagenten genom att följa proceduren som beskrivs i Förbereda källdatorn för push-installation av mobilitetsagenten.

Redundans- och återställningsprocedurer

För att förenkla hanteringen av redundans bör du överväga att implementera återställningsplaner för alla skyddade arbetsbelastningar. Mer information finns i avsnittet Tillförlitlighet tidigare i den här artikeln. Du hittar också rekommendationer för att optimera hanteringen av återställningsproceduren.

Delegering av roller och ansvarsområden

Planering för och implementering av haveriberedskap för VM-baserade arbetsbelastningar i Azure Stack Hub med hjälp av Site Recovery innebär vanligtvis interaktion mellan intressenter:

• Azure Stack Hub-operatörer hanterar Azure Stack Hub-infrastruktur, vilket säkerställer att det finns tillräckligt med beräknings-, lagrings- och nätverksresurser som krävs för att implementera en omfattande haveriberedskapslösning och göra dessa resurser tillgängliga för klientorganisationer. De samarbetar också med program- och dataägare för att fastställa den optimala metoden för att distribuera sina arbetsbelastningar till Azure Stack Hub.
• Azure-administratörer hanterar Azure-resurser som krävs för att implementera hybridlösningar för haveriberedskap.
• Microsoft Entra-administratörer hanterar Microsoft Entra-resurser, inklusive användar- och gruppobjekt som används för att etablera, konfigurera och hantera Azure-resurser.
• Azure Stack Hub-klientorganisationens IT-personal utformar, implementerar och hanterar Site Recovery, inklusive redundans och återställning efter fel.
• Azure Stack Hub-användare måste tillhandahålla RPO- och RTO-krav och skicka begäranden för att implementera haveriberedskap för sina arbetsbelastningar.

Se till att det finns en tydlig förståelse för de roller och ansvarsområden som tilldelas programägare och operatörer i samband med skydd och återställning. Användarna ansvarar för att skydda virtuella datorer. Operatörerna ansvarar för driftstatusen för Azure Stack Hub-infrastrukturen.

DevOps

Även om konfiguration av återställning på VM-nivå med Hjälp av Site Recovery främst är ett ansvar för IT-åtgärder, finns det vissa DevOps-specifika överväganden som bör införlivas i en omfattande strategi för haveriberedskap. Azure Stack Hub underlättar implementeringen av IaC (Infrastructure-as-Code), som omfattar automatisk distribution av en mängd olika arbetsbelastningar, inklusive VM-baserade program och tjänster. Du kan använda den här funktionen för att effektivisera etableringen av Site Recovery-baserade haveriberedskapsscenarier, vilket förenklar den inledande installationen i flera klientscenarier.

Du kan till exempel använda samma Azure Resource Manager-mallar för att etablera alla nätverksresurser som krävs för att hantera VM-baserade arbetsbelastningar i en Azure Stack Hub-stämpel för ditt program i en enda samordnad åtgärd. Du kan använda samma mall för att etablera en matchande uppsättning resurser i Azure för att etablera en haveriberedskapsplats. För att ta hänsyn till eventuella skillnader mellan de två miljöerna kan du helt enkelt ange olika värden för mallparametrar i varje enskilt fall.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.

När du planerar att distribuera Site Recovery på Azure Stack Hub måste du överväga mängden bearbetnings-, lagrings- och nätverksresurser som allokeras till konfigurations- och processservrarna. Du kan behöva justera den uppskattade storleken på den virtuella Azure Stack Hub-dator som är värd för Site Recovery-komponenterna efter distributionen för att hantera ändringar i bearbetnings- eller lagringskrav. Du har tre grundläggande alternativ för att justera storleksändringen:

• Implementera vertikal skalning. Detta innebär att ändra mängden och typen av processor-, minnes- och diskresurser för den virtuella Azure Stack Hub-dator som är värd för konfigurationsservern, inklusive processervern. Om du vill beräkna resurskraven kan du använda informationen i följande tabell:

  Tabell 1: Storlekskrav för konfiguration och processerver

  Processor	Minne	Cachedisk	Dataändringshastighet	Skyddade datorer
  8 vCPU:er 2 sockets * 4 kärnor @ 2,5 GHz	16 GB	300 GB	500 GB eller mindre	< 100 datorer
  12 vCPU:er 2 sockets * 6 kärnor @ 2,5 GHz	18 GB	600 GB	500 GB–1 TB	100 till 150 datorer
  16 vCPU:er 2 sockets * 8 kärnor @ 2,5 GHz	32 GB	1 TB	1–2 TB	150–200 datorer

• Implementera horisontell skalning. Detta innebär etablering eller avetablering av virtuella Azure Stack Hub-datorer med processservern installerad för att matcha bearbetningskraven för skyddade virtuella Azure Stack Hub-datorer. Om du i allmänhet måste skala distributionen till fler än 200 källdatorer, eller om du har en total daglig omsättningshastighet på mer än två terabyte (TB), behöver du ytterligare processservrar för att hantera replikeringstrafiken. Om du vill beräkna antalet och konfigurationen av ytterligare processservrar läser du Storleksrekommendationer för processervern.

• Ändra replikeringsprincipen. Detta innebär att replikeringsprincipens parametrar ändras, med fokus på appkonsekventa ögonblicksbilder.

Från nätverkssynpunkt finns det flera olika metoder för att justera bandbredden som är tillgänglig för replikeringstrafik:

• Ändra vm-storlek. Storleken på virtuella Azure Stack Hub-datorer avgör den maximala nätverksbandbredden. Det är dock viktigt att observera att det inte finns några bandbreddsgarantier. I stället kan virtuella datorer använda mängden tillgänglig bandbredd upp till den gräns som bestäms av deras storlek.

• Ersätt växlar för överordnad länk. Azure Stack Hub-system har stöd för en rad maskinvaruväxlar som erbjuder flera alternativ för överordnad länkhastighet. Varje Azure Stack Hub-klusternod har två överordnad länk överst i rackväxlar för feltolerans. Systemet allokerar hälften av överordnad kapacitet för kritisk infrastruktur. Resten är delad kapacitet för Azure Stack Hub-tjänster och all användartrafik. System som distribueras med snabbare hastigheter har mer bandbredd tillgänglig för replikeringstrafik.

  Kommentar

  Även om det är möjligt att separera nätverkstrafik genom att ansluta ett andra nätverkskort till en server, med virtuella Azure Stack Hub-datorer, delar all VM-trafik till Internet samma överordnad länk. Ett andra virtuellt nätverkskort separerar inte trafik på fysisk transportnivå.

• Ändra dataflödet för nätverksanslutningen till Azure. För att hantera större mängder replikeringstrafik kan du överväga att använda Azure ExpressRoute med Microsoft-peering för anslutningar mellan virtuella Azure Stack Hub-nätverk och Azure Storage. Azure ExpressRoute utökar lokala nätverk till Microsoft-molnet via en privat anslutning som tillhandahålls av en anslutningsleverantör. Du kan köpa ExpressRoute-kretsar för ett brett utbud av bandbredder, från 50 megabit per sekund (Mbit/s) till 100 gigabit per sekund.

  Kommentar

  Mer information om hur du implementerar Azure ExpressRoute i Azure Stack Hub-scenarier finns i Anslut Azure Stack Hub till Azure med Azure ExpressRoute.

• Ändra begränsningen av replikeringstrafiken på processervern. Du kan styra hur mycket bandbredd som används av replikeringstrafiken på de virtuella datorer som är värdar för processservrar från det grafiska gränssnittet för Microsoft Azure Recovery Services-agenten. De funktioner som stöds omfattar att ange gränserna för arbete och icke-arbetstimmar, med bandbreddsvärden som sträcker sig från 512 kilobit per sekund till 1 023 Mbit/s. Du kan också använda samma konfiguration med hjälp av PowerShell-cmdleten Set-OBMachineSetting .

• Ändra nätverksbandbredden som allokerats per skyddad virtuell dator på processervern. Det gör du genom att ändra värdet för UploadThreadsPerVM-posten i nyckeln HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication . Som standard är värdet inställt på 4, men du kan öka det till 32 om det finns tillräckligt med nätverksbandbredd.

Distribuera det här scenariot

Förutsättningar

Implementeringen av den rekommenderade lösningen är beroende av att uppfylla följande krav:

• Åtkomst till en Azure-prenumeration med tillräcklig behörighet för att etablera och hantera alla molnkomponenter i Site Recovery-komponenterna, inklusive:

  • Azure Recovery Services-valv i Azure-regionen som har utsetts till haveriberedskapsplats för Azure Stack Hub-produktionsmiljön.
  • Ett Azure Storage-konto som är värd för innehåll på replikerade diskar på virtuella Azure Stack Hub-datorer.
  • Ett virtuellt Azure-nätverk som representerar den haveriberedskapsmiljö som hydratiserade virtuella Azure-datorer ansluts till efter en planerad eller oplanerad redundansväxling.
  • Ett isolerat virtuellt Azure-nätverk som representerar testmiljön som hydratiserade virtuella Azure-datorer ansluts till efter ett redundanstest.
  • En Azure ExpressRoute-baserad anslutning mellan den lokala miljön, virtuella Azure-nätverk och azure-lagringskontot som används för att hantera kopior av VHD-filer med innehåll som replikeras från diskar med skyddade virtuella Azure Stack Hub-datorer.

• En Azure Stack Hub-användarprenumeration. Alla virtuella Azure Stack Hub-datorer som skyddas av en enskild Site Recovery-konfigurationsserver måste tillhöra samma Azure Stack Hub-användarprenumeration.

• Ett virtuellt Azure Stack Hub-nätverk. Alla skyddade virtuella datorer måste ha direkt anslutning till de virtuella datorer som är värdar för processserverkomponenten (som standard är detta den virtuella konfigurationsserverns virtuella dator).

• En virtuell Azure Stack Hub Windows Server-dator som ska vara värd för konfigurationsservern och en processserver. Den virtuella datorn måste tillhöra samma prenumeration och vara ansluten till samma virtuella nätverk som de virtuella Azure Stack Hub-datorer som måste skyddas. Dessutom måste den virtuella datorn:

  • Följ kraven för Site Recovery-konfigurationsservern för programvara och maskinvara
  • Uppfylla dokumentationen om krav för externt anslutningsnätverk.

  Kommentar

  Ytterligare överväganden för lagring och prestanda för konfigurations- och processservrar beskrivs mer detaljerat senare i den här arkitekturen.

  • Uppfylla interna anslutningskrav. I synnerhet måste virtuella Azure Stack Hub-datorer som du vill skydda kunna kommunicera med:

    • Konfigurationsservern via TCP-port 443 (HTTPS) inkommande för replikeringshantering
    • Processervern via TCP-port 9443 för att leverera replikeringsdata.

    Kommentar

    Du kan ändra den port som används av processervern för både extern och intern anslutning som en del av konfigurationen när du kör Den enhetliga installationsprogrammet för Site Recovery.

• Virtuella Azure Stack Hub-datorer som ska skyddas och som kör något av de operativsystem som stöds För att skydda virtuella Azure Stack Hub-datorer som kör Windows Server-operativsystem måste du:

  • Skapa ett Windows-konto med administrativa rättigheter. Du kan ange det här kontot när du aktiverar Site Recovery på dessa virtuella datorer. Processervern använder det här kontot för att installera Site Recovery-tjänsten Mobility. I en arbetsgruppsmiljö ser du till att inaktivera fjärranvändaråtkomstkontroll på Windows Server-måloperativsystem genom att ange värdet för registerposten LocalAccountTokenFilterPolicyDWORD i registerposten HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System till 1.
  • Aktivera regler för fil- och skrivardelning och Windows Management Instrumentation i Microsoft Defender-brandväggen.

• För att skydda virtuella Azure Stack Hub-datorer som kör Linux-operativsystem måste du:

  • Skapa ett rotanvändarkonto. Du kan ange det här kontot när du aktiverar Site Recovery på dessa virtuella datorer. Processervern använder det här kontot för att installera Site Recovery-tjänsten Mobility.
  • Installera den senaste openssh, openssh-server och openssl-paket.
  • Aktivera och kör SSH-port (Secure Shell) 22.
  • Aktivera säker FTP-undersystem och lösenordsautentisering.

Implementeringssteg på hög nivå

På hög nivå består implementeringen av Site Recovery-baserad haveriberedskap på Azure Stack Hub av följande steg:

1. Förbered virtuella Azure Stack Hub-datorer som ska skyddas av Site Recovery. Se till att de virtuella datorerna uppfyller Site Recovery-kraven som anges i föregående avsnitt.

2. Skapa och konfigurera ett Azure Recovery Services-valv. Konfigurera ett Azure Recovery Services-valv och ange vad du vill replikera. Site Recovery-komponenter och -aktiviteter konfigureras och hanteras med hjälp av valvet.

3. Konfigurera källreplikeringsmiljön. Etablera en Site Recovery-konfigurationsserver och processerver genom att installera binärfiler för enhetliga installationsprogram för Site Recovery och registrera den med valvet.

   Kommentar

   Du kan köra den enhetliga installationsprogrammet för Site Recovery igen för att implementera ytterligare processerver på virtuella Azure Stack Hub-datorer.

4. Konfigurera målreplikeringsmiljön. Skapa eller välj ett befintligt Azure-lagringskonto och ett virtuellt Azure-nätverk i Azure-regionen som ska vara värd för haveriberedskapsplatsen. Under replikeringen kopieras innehållet på diskarna för de skyddade virtuella Azure Stack Hub-datorerna till Azure Storage-kontot. Under redundansväxlingen etablerar Site Recovery automatiskt virtuella Azure-datorer som fungerar som repliker av skyddade virtuella Azure Stack Hub-datorer och ansluter dem till det virtuella Azure-nätverket.

5. Aktivera replikering. Konfigurera replikeringsinställningen och aktivera replikering för virtuella Azure Stack Hub-datorer. Mobilitetstjänsten installeras automatiskt på varje virtuell Azure Stack Hub-dator som replikering är aktiverad för. Site Recovery initierar replikering av varje virtuell Azure Stack Hub-dator enligt de principinställningar som du har definierat.

6. Utför ett redundanstest. När replikeringen har upprättats kontrollerar du att redundans fungerar som förväntat genom att utföra ett redundanstest.

7. Utför en planerad eller oplanerad redundansväxling. Efter ett lyckat redundanstest är du redo att utföra antingen en planerad eller oplanerad redundansväxling till Azure. Du har möjlighet att ange vilka virtuella Azure Stack Hub-datorer som ska ingå i redundansväxlingen.

8. Utför en återställning efter fel. När du är redo att växla tillbaka stoppar du de virtuella Azure-datorer som motsvarar de virtuella Azure Stack Hub-datorer som du misslyckades med, laddar ned deras diskfiler till lokal lagring, laddar upp dem till Azure Stack Hub och kopplar dem till en befintlig eller ny virtuell dator.

Sammanfattning

Sammanfattningsvis är Azure Stack Hub ett unikt erbjudande som skiljer sig i många aspekter från andra virtualiseringsplattformar. Det motiverar därför särskilda överväganden när det gäller strategin för affärskontinuitet för dess arbetsbelastningar. Genom att använda Azure-tjänster kan du förenkla utformningen och implementeringen av den här strategin. I den här arkitekturreferensartikeln utforskade vi användningen av Microsoft Site Recovery för att skydda virtuella Azure Stack Hub-baserade arbetsbelastningar i den anslutna distributionsmodellen. Med den här metoden kan kunderna dra nytta av återhämtning och hanterbarhet i Azure Stack Hub och från azure-molnets hyperskala och globala närvaro.

Det är viktigt att observera att den haveriberedskapslösning som beskrivs här uteslutande fokuserar på VM-baserade arbetsbelastningar i Azure Stack Hub. Detta är bara en del av en övergripande strategi för affärskontinuitet som ska ta hänsyn till andra arbetsbelastningstyper och scenarier i Azure Stack Hub som påverkar deras tillgänglighet.

Nästa steg

Produktdokumentation:

• Om Site Recovery
• Översikt av Azure Stack Hub
• Vad är Microsoft Entra-ID?
• Vad är Azure Blob Storage?
• Vad är Azure ExpressRoute?
• Vad är Azure Virtual Network?

Microsoft Learn-moduler:

• Azure Stack Hub
• Konfigurera Microsoft Entra-ID
• Konfigurera lagringskonton
• Konfigurera virtuella nätverk
• Utforma och implementera Azure ExpressRoute
• Utforma din webbplatsåterställningslösning i Azure

Relaterade resurser

• Hybrid arkitekturdesign
• Säkerhetskopiera filer och program på Azure Stack Hub
• Hybridanslutningar
• Hybridfilresurs med haveriberedskap för distansarbetare och lokala grenarbetare