BCDR för flera regioner för Azure Virtual Desktop

Den här artikeln innehåller arkitektur och konfigurationsvägledning på implementeringsnivå för distribution av Azure Virtual Desktop med affärskontinuitet i flera regioner och haveriberedskap (BCDR). Den beskriver hur FSLogix lagrar användarprofiler i virtuella hårddiskcontainrar (VHD) och hur molncachen replikerar profiler mellan regioner. Den beskriver också BCDR-modellalternativ, inklusive aktiva, aktiva, passiva och personliga värdpooler som använder Azure Site Recovery, tillsammans med konfiguration av FSLogix-molncache, redundans- och återställningsprocedurer samt överväganden för lagring.

Vägledningen bygger på två relaterade resurser:

• Designguiden för Azure Virtual Desktop-landningszonen, som etablerar grundläggande infrastruktur för Azure Virtual Desktop, inklusive prenumerationer, nätverk, identitet och styrning.

• BC-överväganden för Azure Virtual Desktop-arbetsbelastningar, som innehåller designprinciper och rekommendationer på komponentnivå baserat på Azure Well-Architected Framework.

Den här artikeln fokuserar på implementeringsinformation, inklusive arkitekturdiagram, konfiguration på registernivå, stegvisa redundansprocedurer och DR-testmetoder.

Mål och omfattning

Den här guiden har följande mål:

• Säkerställ maximal återhämtning och geo-haveriberedskap samtidigt som du minimerar dataförlusten för valda användardata.

• Minimera återställningstiden.

Dessa mål kallas även mål för återställningspunkt (RPO) och mål för återställningstid (RTO).

Vilket RPO och RTO som kan uppnås beror på vilken BCDR-modell och vilken värdpoolstyp du väljer. Följande tabell innehåller ungefärliga uppskattningar för varje modell.

BCDR-modell	RPO	RTO	Viktiga faktorer
Aktiv-aktiv med sammankopplad molncache	Sekunder till några minuter (molncachens asynkrona replikeringsfördröjning)	Nära noll (ingen redundans krävs, båda värdpoolerna betjänar användarna)	Beräknings- och lagringskostnader med dubbla regioner. Begränsa användarnas åtkomst till endast en värdpool i taget.
Aktiv-passiv med molncache (poolad)	Sekunder till några minuter (molncachens asynkrona replikeringsfördröjning)	15 till 60 minuter beroende på beräkningsuppvärmningstid, autoskalningsramptid och omtilldelning av programgrupp	Du kan frigöra sekundär beräkning för att minska kostnaderna. Kapaciteten garanteras inte om inte virtuella datorer (VM) körs eller kapacitetsreservationer på begäran finns på plats.
Personlig värdpool med Site Recovery	5 till 15 minuter (Site Recovery-replikeringsfrekvens)	Site Recovery VM-redundanstid (vanligtvis minuter för varje virtuell dator), tiden för domänåterställning och tiden för replikering av VM-tillägg	Ingen FSLogix-molncache. Du måste konfigurera Site Recovery för varje virtuell dator.

Anmärkning

Behandla dessa exempel som uppskattningar, inte Microsoft-garantier. Verifiera dem via DR-testning i din miljö. Verkligt RPO beror på profilstorlek, lagringsdataflöde och nätverksbandbredd mellan regioner. Den faktiska RTO:n beror på antalet sessionsvärdar, autoskalningsinställningar och den tid som krävs för att slutföra omtilldelningar av applikationsgrupper.

Den här lösningen ger lokal hög tillgänglighet, skydd mot ett fel i en enda tillgänglighetszon och skydd mot ett helt Azure-regionfel. Den förlitar sig på en redundant distribution i en annan eller sekundär Azure-region för att återställa tjänsten. Det är bästa praxis att använda kopplade regioner, men Azure Virtual Desktop och den teknik som stöder BCDR kräver inte att Azure-regioner parkopplas. Du kan använda valfri kombination av Azure-regioner för primära och sekundära platser så länge nätverksfördröjning tillåter det. Att använda Azure Virtual Desktop-värdpooler i flera geografiska regioner ger fördelar utöver BCDR.

Använd följande återhämtningsmetoder för att förbättra hög tillgänglighet för att minska effekten av ett fel i en enskild tillgänglighetszon:

• På beräkningslagret ska Azure Virtual Desktop-sessionsvärdarna spridas över olika tillgänglighetszoner.

• Använd zonåterhämtning när det är möjligt på lagringsskiktet.

• På nätverksskiktet distribuerar du zontåliga Azure ExpressRoute- och VPN-gatewayer (virtual private network).

• För varje beroende granskar du effekten av ett avbrott i en enda zon och planerar åtgärder. Du kan till exempel distribuera Active Directory-domänkontrollanter och andra externa resurser som Azure Virtual Desktop-användare har åtkomst till i flera tillgänglighetszoner.

Beroende på antalet tillgänglighetszoner som du använder kan du överväga att överprovisionera sessionsvärdar för att ta hänsyn till den potentiella förlusten av en zon. Den här metoden hjälper till att upprätthålla användarupplevelsen och prestanda, även om endast (n-1) zoner förblir tillgängliga.

Anmärkning

Azure-tillgänglighetszoner är en funktion med hög tillgänglighet som kan förbättra återhämtning. Behandla dem inte som en DR-lösning som skyddar mot katastrofer i hela regionen.

På grund av möjliga kombinationer av lagringstyper, replikeringsalternativ, tjänstfunktioner och regionala tillgänglighetsgränser använder du funktionen för FSLogix-molncache i stället för lagringsspecifika replikeringsmekanismer.

Omfångsbegränsningar

Den här artikeln beskriver kostnadskonsekvenser, men huvudfokus är att tillhandahålla en effektiv implementation av geo-katastrofåterställning som minimerar dataförlust. Den täcker inte OneDrive. Mer information finns i SharePoint- och OneDrive-dataåterhämtning i Microsoft 365.

Mer information om BCDR finns i följande artiklar:

• BC-överväganden för Azure Virtual Desktop-arbetsbelastningar
• BCDR-överväganden för Azure Virtual Desktop
• Azure Virtual Desktop DR

Förutsättningar

Innan du implementerar BCDR för flera regioner distribuerar du infrastrukturen för den grundläggande landningszonen i både de primära och sekundära Azure-regionerna. Vägledning för nätverkstopologi, identitet och prenumerationsstruktur finns i designguiden för Azure Virtual Desktop-landningszonen och Nätverkstopologi och anslutning för Azure Virtual Desktop.

För BCDR följer du dessa nätverkskrav:

• Distribuera den primära värdpoolen och den sekundära DR-miljön i separata virtuella spoke-nätverk, som var och en är anslutna till en hubb i sin egen region. Konfigurera anslutningen mellan de två hubbarna.

• Se till att varje hubb tillhandahåller hybridanslutning till lokala resurser, brandväggstjänster, identitetsresurser som Active Directory-domänkontrollanter och hanteringsresurser som Log Analytics.

• Bekräfta att verksamhetsspecifika program (LOB) och beroende resurser är tillgängliga på den sekundära platsen under redundansväxlingen.

Azure Virtual Desktop-kontrollplanet BCDR

Azure Virtual Desktop-kontrollplanet innehåller webb-, koordinator-, gateway-, resurskatalog- och diagnostiktjänster. Microsoft hanterar kontrollplanet och stöder regional redundans. När en region upplever ett avbrott, växlar kontrollplanskomponenter automatiskt över och fortsätter att fungera. Du behöver inte konfigurera redundans för kontrollplanet. Mer information om delat ansvar och arkitekturen för kontrollplanet finns i Azure Virtual Desktop-tjänstens arkitektur och motståndskraft och BC-överväganden för Azure Virtual Desktop-arbetsbelastningar.

Geografiska eller regionala värdpooler

Azure Virtual Desktop stöder två omfång för distribution av värdpooler som avgör var och hur tjänsten lagrar kontrollplansmetadata:

• Geografiska värdpooler (klassisk modell): Den här modellen lagrar metadata för värdpooler i en geografisk databas som hanterar flera Azure-regioner inom samma Azure-geografi. Databasen replikeras till en länkad region för återställning mellan regioner. Ett databas- eller infrastrukturproblem i regionen som är värd för den geografiska databasen påverkar värdpooler i alla regioner i det geografiska området, även om dessa regioner annars är felfria.

• Regionala värdpooler: Den här modellen lagrar metadata för värdpooler i en databas per region som distribueras direkt till den Azure-region som du väljer. Flera repliker sträcker sig över tillgänglighetszoner inom den regionen och metadata replikeras till en länkad region för redundans mellan regioner. Ett problem i en region påverkar endast värdpooler i den regionen, vilket eliminerar beroendet mellan regioner för den geografiska modellen.

Geografiska och regionala värdpooler fungerar på samma sätt. De skiljer sig bara åt i databasarkitekturen, metadataplatsen och återhämtningsegenskaperna.

För BCDR-distributioner ger regionala värdpooler följande fördelar:

• Begränsad omfattning av påverkan: Ett kontrollplansproblem i den primära regionen påverkar inte värdpooler i den sekundära regionen eftersom varje region använder en oberoende databas.

• Datasuveränitet: Metadata för värdpoolen finns kvar i den Azure-region som du väljer, vilket hjälper dig att uppfylla kraven på datahemvist.

• Oberoende åtgärd: Under ett regionalt avbrott fortsätter den sekundära regionens värdpool att fungera med en egen infrastruktur för kontrollplanet och är inte beroende av den berörda regionen.

Regionala värdpooler är i offentlig förhandsversion. Under förhandsversionen är geografiska och regionala Azure Virtual Desktop-objekt, inklusive värdpooler, arbetsytor och programgrupper, inte kompatibla. Endast objekt som delar samma distributionsomfång associeras med varandra. När du planerar din BCDR-arkitektur ser du till att både den primära och den sekundära värdpoolen, arbetsytorna och programgrupperna använder samma distributionsomfång. Mer information om regioner som stöds, begränsningar för förhandsversioner och migreringsvägledning finns i Regionala värdpooler.

Viktigt!

Vi rekommenderar att du skapar alla nya värdpooler som regionala värdpooler för bättre återhämtning och datasuveränitet. Planera övergången av befintliga geografiska värdpooler till regionala värdpooler. Microsoft tillhandahåller migreringsverktyg och meddelar tidslinjer för utfasning för geografiska värdpooler.

Dataplatser för Azure Virtual Desktop är oberoende av de virtuella sessionsvärddatorernas platser. Du kan placera Azure Virtual Desktop-metadata i en region som stöds och distribuera virtuella datorer i en annan region.

Följande typer av Azure Virtual Desktop-värdpooler stöder olika återställningslösningar:

• Personliga: I den här typen av värdpool har användarna en permanent tilldelad sessionsvärd och tilldelningen är fortfarande fast. Eftersom varje användare har en dedikerad virtuell dator kan den virtuella datorn lagra användardata. Använd replikerings- och säkerhetskopieringstekniker för att bevara och skydda det tillståndet.

• Poolade: I den här typen av värdpool tilldelar systemet tillfälligt användare till tillgängliga virtuella sessionsvärddatorer från poolen, antingen via en skrivbordsprogramgrupp (DAG) eller med hjälp av fjärrappar. Virtuella datorer är tillståndslösa och systemet lagrar användardata och profiler i extern lagring eller OneDrive.

Aktiv-aktiv kontra aktiv-passiv

Om olika uppsättningar av användare har olika BCDR-krav rekommenderar vi att du använder flera värdpooler som har olika konfigurationer. Användare som har en affärskritisk applikation kan till exempel tilldela en fullständigt redundant värdpool som har funktioner för geografisk katastrofåterställning. Utvecklings- och testanvändare kan använda en separat värdpool utan dr.

För varje Azure Virtual Desktop-värdpool kan du basera DIN BCDR-strategi på en aktiv-aktiv eller aktiv-passiv modell. Det här scenariot förutsätter att en värdpool hanterar samma uppsättning användare på en enda geografisk plats.

Egenskaper för aktiv-aktiv modell

I det här avsnittet beskrivs hur en aktiv Azure Virtual Desktop-distribution fungerar i två Azure-regioner, inklusive design av värdpooler, överväganden för svarstid och profilhantering.

Design för värdpool och redundans

Distribuera en andra värdpool i den sekundära regionen för varje värdpool i den primära regionen. Den här konfigurationen ger nästan noll RTO. Nära noll RPO kräver extra kostnad. Du behöver inte en administratör för att ingripa eller hantera övergångar. Under normal drift hanterar den sekundära värdpoolen användare via Azure Virtual Desktop-resurser.

Överväganden för lagring och profil

Varje värdpool har egna lagringskonton (minst ett) för beständiga användarprofiler.

Om du behöver lagring för att hantera FSLogix-profil och Office-containrar separat använder du molncachen för att säkerställa nästan noll RPO. Undvik profilkonflikter genom att hindra användare från att komma åt båda värdpoolerna samtidigt. Eftersom det här scenariot är aktivt kan du lära användarna hur de använder dessa resurser.

Anmärkning

Att använda separata Office-containrar är ett avancerat scenario med högre komplexitet. Distribuera endast den här konfigurationen i specifika scenarier.

Användarupplevelse och programgrupper

Användare tilldelas till olika programgrupper, till exempel en DAG och en RemoteApp-grupp , i både de primära och sekundära värdpoolerna. I det här fallet ser de duplicerade poster i sin Azure Virtual Desktop-klientfeed. För tydlighetens skull använder du separata Azure Virtual Desktop-arbetsytor som har tydliga namn och etiketter som återspeglar syftet med varje resurs. Lär användarna att använda dessa resurser.

Svarstid och regional närhet

Utvärdera svarstiden baserat på användarens fysiska plats och tillgängliga anslutning. För vissa Azure-regioner, till exempel Västeuropa och Norra Europa, kan skillnaden vara försumbar när du kommer åt antingen de primära eller sekundära regionerna. Utvärdera nätverksfördröjningen baserat på varje användarpopulations fysiska plats och de regioner som är värdar för både sessionsvärdar och serverdelssystem, inklusive LOB-program, databaser och filresurser. Närhet mellan användare, deras sessionsvärdar och de serverdelssystem som de har åtkomst till är avgörande för en dynamisk upplevelse. För att testa svarstiden kan du distribuera virtuella testdatorer i önskad region och använda PowerShell-verktyg som Test-NetConnection eller PsPing för att skicka testtrafik till och från klientsystemen.

I ett DR-scenario ansluter användarna till sessionvärdar i den sekundära regionen, som kan vara längre bort från både användarna och back-end-resurserna. Det här avståndet ökar svarstiden tur och retur och kan minska programmets svarstider, särskilt för svarstidskänsliga arbetsbelastningar som realtidsdatabaser, VoIP (Voice Over IP) eller interaktiva designverktyg. För vissa Azure-regionpar, till exempel Västeuropa och Nordeuropa, är latensen mellan regionerna tillräckligt låg för att prestandaförsämringen under redundansväxlingen ger liten eller ingen påverkan. För andra regionpar avgränsade med större avstånd kan effekten vara betydande.

Använd Azure-nätverkets round-trip-fördröjningsstatistik för att mäta förväntad latens mellan regioner och genomför end-to-end användargodkännandetest från den sekundära regionen innan du förlitar dig på den vid produktionsöverlappning.

Egenskaper för aktiv-passiv modell

I det här avsnittet beskrivs hur en aktiv-passiv Azure Virtual Desktop-distribution fungerar, inklusive beräkningsplanering, redundansbeteende och profilhantering.

Värdpool och datorkapacitetsplanering

Precis som i "active-active"-modellen distribuerar du en andra värdpool i den sekundära regionen till varje värdpool i den primära regionen.

Du distribuerar färre aktiva beräkningsresurser i den sekundära regionen än i den primära regionen, beroende på din budget. Du kan använda automatisk skalning för att ge mer beräkningskapacitet. Skalning kräver extra tid och Azure garanterar inte kapacitet.

Den här konfigurationen ger högre RTO än aktiv-aktiv-metoden, men den kostar mindre.

Failover-beteende och användaråtkomst

Du behöver administratörsintervention för att redundansväxla om ett Azure-avbrott inträffar. Under normala åtgärder ger den sekundära värdpoolen inte användaråtkomst till Azure Virtual Desktop-resurser. Varje värdpool har egna lagringskonton för beständiga användarprofiler.

Användare som använder Azure Virtual Desktop-tjänster som har optimal svarstid och prestanda påverkas endast om ett Azure-avbrott inträffar. Under redundansväxlingen ansluter användarna till sessionsvärdar i den sekundära regionen, vilket ökar det fysiska avståndet mellan användaren, sessionsvärden och serverdelssystemen som sessionsvärden kommer åt. Det här extra avståndet ökar svarstiden för nätverket och kan minska svarstiden för program som är känsliga för svarstid.

Använd statistik för svarstidsfördröjning i Azure-nätverket för att kvantifiera den förväntade svarstiden mellan dina primära och sekundära regioner. Bekräfta att prestanda fortfarande är accepterad för dina arbetsbelastningar genom att testa ända-till-ända från den sekundära regionen.

Beteende för programgrupp

Användare tillhör en programgruppsuppsättning, till exempel skrivbordsappar och fjärrappar. Dessa appar körs i den primära värdpoolen under normala åtgärder. När ett avbrott inträffar och redundansväxlingen har slutförts tilldelas användarna till programgrupper i den sekundära värdpoolen. Azure Virtual Desktop-klienten visar inte duplicerade poster, användarna behåller samma arbetsyta och övergången förblir transparent.

FSLogix-överväganden

Om du behöver lagring för att hantera FSLogix-profil och Office-containrar använder du molncachen för att säkerställa nästan noll RPO.

Begränsa användarnas åtkomst till endast en värdpool i taget för att förhindra profilkonflikter. I aktiva-passiva scenarier tillämpar administratörer den här begränsningen på programgruppsnivå. Användaren kan bara komma åt varje programgrupp i den sekundära värdpoolen när redundansväxlingen har slutförts. Åtkomst återkallas i den primära programgruppen för värdpoolen och omtilldelas till en programgrupp i den sekundära värdpoolen.

Utför en redundansväxling för alla programgrupper. Annars kan användare som har åtkomst till olika programgrupper i olika värdpooler orsaka profilkonflikter.

Selektiv redundanstestning

Du kan låta en specifik delmängd användare selektivt växla över till den sekundära värdpoolen för att testa begränsad aktiv-aktiv drift och verifiera failover-funktionaliteten. Du kan också överlåta specifika applikationsgrupper. Se till att användarna bara kommer åt resurser från en värdpool i taget för att undvika konflikter.

Enskild värdpool mellan regioner

För specifika omständigheter kan du skapa en enda värdpool som har sessionsvärdar i olika regioner. En enda värdpool eliminerar behovet av att duplicera definitioner och tilldelningar för skrivbords- och fjärrappar. DR för delade värdpooler introducerar flera kompromisser. För poolade värdpooler kan du inte tillämpa regionala anslutningsinställningar för användare, och användarna kan uppleva högre svarstid och lägre prestanda när de ansluter till en sessionsvärd i en fjärrregion. Om du behöver lagring för användarprofiler behöver du en komplex konfiguration för att hantera tilldelningar för sessionsvärdar i de primära och sekundära regionerna.

Du kan använda tömningsläge för att tillfälligt inaktivera åtkomsten till sessionsvärdar som finns i den sekundära regionen, men den här metoden ger komplexitet, hanteringskostnader och ineffektiv resursanvändning. Du kan underhålla sessionsvärdar i offlineläge i de sekundära regionerna, men den här metoden lägger till komplexitet och hanteringskostnader.

Jämförelse av BCDR-modell

I följande tabell sammanfattas de viktigaste kompromisserna mellan BCDR-modellerna för att hjälpa dig att välja den metod som passar dina behov.

Mätvärde	Aktiv-aktiv (poolad)	Aktiv-passiv (sammanslagen)	Personligt (Återställning av webbplats)
RTO	Nära noll	15 till 60 minuter beroende på beräkningsberedskap	Site Recovery-serviceavtal (SLA) med en typisk tidsram på minuter och återställa skyddet
RPO	Asynkron fördröjning i molncachen (sekunder till några minuter)	Asynkron fördröjning i molncachen (sekunder till några minuter)	Site Recovery-replikering (vanligtvis 5 till 15 minuter)
Stadig tillståndskostnad	Hög (dubbel beräkning, dubbel lagring)	Medel (beräkning med minimal sekundär kapacitet)	Medel (Site Recovery-replikeringskostnad)
Administratörsintervention	Ingen	Krävs (gruppomtilldelning, kapacitetsskalning)	Krävs (utlösa redundans för varje virtuell dator)
Användarupplevelse	Duplicerade flödesposter (två arbetsytor)	Transparent (enskild arbetsyta)	Transparent efter redundansväxling
DR-testkomplexitet	Hög (profillåsrisker)	Medel (GRP-TEST metod)	Begränsad (ingen Azure Virtual Desktop-integrerad testredundans)
Kapacitetsgaranti	Ja (always-on-kapacitet)	Nej (såvida inte kapacitetsreservation på begäran finns på plats)	Nej (såvida inte kapacitetsreservation på begäran finns på plats)

Arkitekturdiagram

Granska följande arkitekturdiagram innan du läser designvägledningen på komponentnivå i efterföljande avsnitt.

Personlig värdpool

Det här diagrammet visar en vänster-till-höger-flera-regioner DR-arkitektur för en personlig värdpool för Azure Virtual Desktop. Till vänster ansluter användarslutpunkter och identitetstjänster till den primära Azure-regionen. Till höger finns en speglad sekundär DR-region som erbjuder återställningskapacitet. Längst upp sträcker sig stegen märkta A över båda regionerna och visar att autentiseringen förblir tillgänglig under ett regionalt avbrott. Microsoft Entra-ID och valfria Active Directory-domänkontrollanter eller Microsoft Entra Domain Services-replikuppsättningar finns i varje region. I mitten tillhandahåller sökvägar märkta B och B2 robusta hybridanslutningar från varje regional hubb till lokala och mellanregionala beroenden, såsom DNS (Domain Name System), domänkontrollanter, LOB-applikationer och datatjänster. De här sökvägarna visar att sessionsvärdar i återställningsregionen behöver åtkomst till samma bakgrundssystem efter felövergång. På prenumerations- och styrningsskiktet definierar stegen C och C2 kvot-, åtkomstkontroll- och kapacitetskrav i båda regionerna, med valfria kapacitetsreservationer på begäran för att säkerställa att den virtuella datorn startas under en regional incident. I varje region placerar steg D sessionsvärdar över tillgänglighetszoner och steg E använder Azure Compute Gallery-repliker i båda regionerna så att värdversionerna förblir konsekventa. Steg F är Site Recovery, som replikerar virtuella sessionsvärddatorer från den primära regionen till den sekundära regionen och stöder redundans och återaktivering av skydd för återställning efter fel.

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

Designområde	Beskrivning
A	Användaridentiteten måste vara tillgänglig för att Azure Virtual Desktop ska fungera. Användarna måste autentisera sig innan de kan komma åt fjärrskrivbord eller fjärrappar. Microsoft Entra-ID krävs och ger global motståndskraft genom design. Om du använder Active Directory Domain Services (AD DS) för anslutning av sessionsvärddomäner distribuerar du domänkontrollanter i både de primära och sekundära regionerna, spridda över tillgänglighetszoner, för att säkerställa att autentiseringen förblir tillgänglig under regional redundansväxling. Om du använder Microsoft Entra Domain Services distribuerar du en replikuppsättning i den sekundära regionen. Mer information finns i Identitet.
B och B2	Om sessionsvärdar behöver nå lokala resurser som filservrar, LOB-program, databaser eller intranätplatser måste även nätverksinfrastrukturen som tillhandahåller den här anslutningen vara motståndskraftig. Distribuera redundanta hybridanslutningar som ExpressRoute-kretsar, VPN-gatewayer eller båda i varje region. Bekräfta att beroende resurser på plats eller mellan regioner, inklusive DNS (Domain Name System), domänkontrollanter och applikationsbackends, är tillgängliga från den sekundära regionen under överflyttning. Utan den här anslutningen startar sessionsvärdar i DR-regionen, men användarna kan inte komma åt de program och data som de behöver.
C och C2	Kontrollera att prenumerationerna i både de primära och sekundära regionerna har tillräcklig VM-kvot för de VM-familjer som sessionsvärdarna använder och att du tilldelar rätt Rollbaserad åtkomstkontroll i Azure (Azure RBAC). Under en regional katastrof konkurrerar frigjorda virtuella datorer eller nyligen distribuerade sessionsvärdar om kapacitet i den sekundära regionen. Enbart kvot garanterar inte att fysisk kapacitet är tillgänglig. Använd kapacitetsreservationer på begäran för att reservera beräkningskapacitet i den sekundära regionen i förväg, vilket garanterar att den virtuella datorn startas när du behöver den. Azure-reservationer (reserverade instanser) minskar kostnaden men reserverar inte fysisk kapacitet. Granska gränserna för Azure Virtual Desktop-tjänsten för att bekräfta att din design håller sig inom värdpoolen, sessionsvärden och arbetsytegränserna i båda regionerna.
D	Sprid sessionsvärdarnas VM-grupp över flera tillgänglighetszoner i både de primära och sekundära DR-regionerna. Om din region inte tillhandahåller tillgänglighetszoner, använd en tillgänglighetsuppsättning för att öka motståndskraften jämfört med en standardkonfiguration.
E	Använd samma gyllene avbildning för distribution av värdpooler i både primära och sekundära DR-regioner. Lagra avbildningar i Azure Compute Gallery och konfigurera flera bildrepliker på båda platserna.
F	För personliga värdpooler använder du Site Recovery för att underhålla en säkerhetskopieringsmiljö.

Poolad värdpool

Det här diagrammet visar en vänster-till-höger BCDR-arkitektur för en Azure Virtual Desktop sammanslagen värdpool med speglade primära och sekundära regioner. Den visar steg A till och med K. Överst sträcker sig Microsoft Entra-ID och Azure Virtual Desktop-kontrollplanet över båda regionerna, vilket visar att identitets- och kontrollplanstjänster stöder båda sidor av distributionen, och steg A visar identitetsberoendet i varje region. Längst till vänster innehåller ett lokalt systemblock domänkontrollanter och ansluter till både regionala hubbnätverk via elastisk hybridanslutning, och etiketterna B och B2 visar dessa nätverkssökvägar och hubbberoenden, inklusive gateway, brandvägg, DNS, routning och säkerhetskontroller. I de mellersta och högra avsnitten innehåller varje region ett landningszonsområde för Azure Virtual Desktop med resursgrupper, spoke-virtuella nätverk, värdpooler och sessionsvärdar som är fördelade över tillgänglighetszoner. Etiketterna C och C2 visar prenumerationskvot och RBAC-beredskap, medan etiketterna D och D2 visar zonindelad distribution av sessionsvärdar. På höger sida av varje region stöder lagrings- och plattformstjänster användarprofiler och programleverans. Steg E visar beteendet för FSLogix-molncache och CCDLocations i olika regioner. Steg F visar lagringsalternativ på prestandanivå för Azure NetApp Files. Steg G visar lagringsalternativen för FSLogix profilcontainer. Steg H visar separata profil- och Office-containerlagringskonton. Steg I visar lagring och replikering av appanslutningspaket. Steg J visar säkerhetskopieringsskydd för viktiga filresurser och profildata. Steg K visar bildreplikering i Compute Gallery, så att båda regionerna använder synkroniserade guldavbildningar för distribution av sessionsvärdar.

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

Designområde	Beskrivning
A	Användaridentiteten måste vara tillgänglig för att Azure Virtual Desktop ska fungera. Användarna måste autentisera sig innan de kan komma åt fjärrskrivbord eller fjärrappar. Microsoft Entra-ID krävs och ger global motståndskraft genom design. Om du använder AD DS för sessionsvärd domänanslutning, distribuerar du domänkontrollanter i både de primära och sekundära regionerna, spridda över tillgänglighetszoner, för att säkerställa att autentiseringen fortsätter vara tillgänglig under regional överflyttning. Om du använder Domain Services distribuerar du en replikuppsättning i den sekundära regionen. Detaljerad konfigurationsvägledning finns i Identitet.
B	Om sessionsvärdar behöver nå lokala resurser som filservrar, LOB-program, databaser eller intranätplatser måste även nätverksinfrastrukturen som tillhandahåller den här anslutningen förbli elastisk. Distribuera redundanta hybridanslutningar som ExpressRoute-kretsar, VPN-gatewayer eller båda i varje region. Bekräfta att beroende lokala resurser eller resurser mellan regioner, inklusive DNS, domänkontrollanter och serverdelar för program, fortfarande kan nås från den sekundära regionen under redundansväxlingen. Utan den här anslutningen startar sessionsvärdar i DR-regionen, men användarna kan inte komma åt de program och data som de behöver.
C	Bekräfta att prenumerationerna i både de primära och sekundära regionerna har tillräcklig VM-kvot för de VM-familjer som sessionsvärdarna använder och att du tilldelar rätt Azure RBAC-roller . Under en regional katastrof konkurrerar frigjorda virtuella datorer eller nyligen distribuerade sessionsvärdar om kapacitet i den sekundära regionen. Enbart kvot garanterar inte att fysisk kapacitet är tillgänglig. Använd kapacitetsreservationer på begäran för att reservera beräkningskapacitet i den sekundära regionen i förväg, vilket garanterar att den virtuella datorn startas när du behöver den. Azure-reservationer (reserverade instanser) minskar kostnaden men reserverar inte fysisk kapacitet. Granska gränserna för Azure Virtual Desktop-tjänsten för att bekräfta att din design håller sig inom värdpoolen, sessionsvärden och arbetsytegränserna i båda regionerna.
D	Sprid ut VM-flottan för sessionsvärdar över olika tillgänglighetszoner i samma region för att uppnå högre tillförlitlighet och ett formellt SLA för hög tillgänglighet på 99,99%. Inkludera tillräckligt med extra beräkningskapacitet i kapacitetsplaneringen för att säkerställa att Azure Virtual Desktop fortsätter att fungera även om en enda tillgänglighetszon misslyckas.
E	Använd FSLogix-molncache för att replikera profildata mellan regioner för återhämtning. Molncache kan öka inloggnings- och utloggningstiderna jämfört med traditionella VHDLocations, särskilt när du använder lagring med låga prestanda. I dokumentationen för FSLogix-molncache finns rekommendationer för storlek och prestanda för lokal cachelagring.
F	Azure NetApp Files ger högre dataflöde och lägre svarstid per gibibyte (GiB) på Premium- och Ultra-nivåerna jämfört med Azure Files Premium. Avgör om prestandaskillnaden motiverar hanteringskostnaderna och replikeringsbegränsningarna.
G	Granska tillgängliga lagringsalternativ för FSLogix-profilcontainer i Azure Virtual Desktop för att jämföra hanterade lagringslösningar och välj det alternativ som uppfyller dina prestanda- och BCDR-krav.
H	Separera användarprofil och Office-containerdiskar i olika lagringskonton. Med den här separationen kan du använda olika säkerhetskopieringsprinciper, kvarhållningsperioder och BCDR-konfigurationer för varje containertyp. Mer information finns i FSLogix.
I	För App Attach-paket använder du inbyggda replikeringsmekanismer i Azure Storage för BCDR. Använd zonredundant lagring (ZRS) för motståndskraft på zonnivå eller geo-redundant lagring (GRS) för Azure Files för skydd på regionnivå.
J	Använd Azure Backup för att skydda användarprofildata från dataförlust eller logisk skada. Tillämpa säkerhetskopieringsprinciper på lagringskonton som innehåller viktiga arbetsbelastningsdata.
K	Använd samma gyllene avbildning för distribution av värdpooler i både primära och sekundära DR-regioner. Lagra avbildningar i Beräkningsgalleriet och konfigurera flera bildrepliker på båda platserna.

Överväganden och rekommendationer

Tänk på följande överväganden och rekommendationer.

Allmänt

Om du vill distribuera en aktiv-aktiv eller aktiv-passiv konfiguration som använder flera värdpooler och en FSLogix-molncachemekanism skapar du värdpoolen på antingen samma arbetsyta eller en annan arbetsyta, beroende på modellen. Den här metoden kräver justering och löpande uppdateringar för att hålla båda värdpoolerna synkroniserade och på samma konfigurationsnivå. När du skapar en ny värdpool för den sekundära DR-regionen måste du utföra följande uppgifter:

• Skapa nya programgrupper och relaterade program för den nya värdpoolen.

• Återkalla användartilldelningar till den primära värdpoolen och tilldela om dem till den nya värdpoolen manuellt under redundansväxlingen.

• Granska BCDR-alternativ för FSLogix.

Anmärkning

Den här artikeln innehåller ingen profilåterställning. Den innehåller molncache (aktiv-passiv) och använder samma värdpool för implementeringen. Den omfattar molncache (aktiv-aktiv) i ett senare avsnitt.

Den här lösningen har resursbegränsningar för Azure Virtual Desktop som du måste tänka på när du utformar en Azure Virtual Desktop-arkitektur. Verifiera din design baserat på tjänstbegränsningarna för Azure Virtual Desktop.

För diagnostik och övervakning använder du samma Log Analytics-arbetsyta för både den primära och den sekundära värdpoolen. I den här konfigurationen ger Azure Virtual Desktop Insights en enhetlig vy över distributionen i båda regionerna.

Ett enda loggmål kan orsaka problem om hela den primära regionen blir otillgänglig. Den sekundära regionen kan inte använda Log Analytics-arbetsytan i den otillgängliga regionen. Om det här resultatet inte uppfyller dina återhämtningskrav bör du överväga följande lösningar:

• Använd en separat Log Analytics-arbetsyta för varje region och konfigurera Azure Virtual Desktop-komponenterna att skicka loggar till dess lokala arbetsyta.

• Testa och granska funktioner för replikerings- och felövergång i Log Analytics-arbetsytor.

Beräkning

I det här avsnittet beskrivs överväganden för sessionsvärdarnas tillgänglighet, hantering av standardavbildningar, automatisk skalning, DR-kapacitet och storlek på molncache-diskar i både primära och sekundära DR-regioner.

Tillgänglighet och återhämtning för sessionsvärdar

Om du vill distribuera båda värdpoolerna i de primära och sekundära DR-regionerna sprider du sessionsvärdens VM-flotta över flera tillgänglighetszoner. Om tillgänglighetszoner inte är tillgängliga i den lokala regionen kan du använda en tillgänglighetsuppsättning för att göra din lösning mer elastisk än en standarddistribution.

Gyllene bildkonsekvens mellan regioner

Den gyllene avbildningen som du använder för distribution av värdpooler i den sekundära DR-regionen ska matcha den gyllene avbildningen som du använder för den primära regionen. Lagra bilder i Beräkningsgalleriet och konfigurera flera bildkopior på både de primära och sekundära platserna. Varje avbildningsreplik stöder ett maximalt antal virtuella datorer som kan distribueras parallellt, och du kan behöva mer än en replik beroende på din distributions batchstorlek. Mer information finns i Lagra och dela bilder i Compute Gallery.

Replikering av Compute Gallery och regional design

Compute Gallery är en regional resurs. Skapa minst ett sekundärt galleri i den sekundära regionen. I din primära region skapar du ett galleri, en VM-avbildningsdefinition och en VM-avbildningsversion. Skapa sedan samma objekt i den sekundära regionen. När du skapar vm-avbildningsversionen i den sekundära regionen kan du kopiera avbildningsversionen från den primära regionen genom att ange källgalleriet, vm-avbildningsdefinitionen och vm-avbildningsversionen. Azure kopierar avbildningen och skapar en lokal vm-avbildningsversion. Du kan köra den här åtgärden med hjälp av Azure-portalen eller Azure CLI-kommandot.

För principer för gyllene bilddesign, inklusive ZRS och replikplanering, se Golden images in BC considerations (Gyllene bilder i BC-överväganden).

Automatisk skalning och kostnadsoptimering

Alla virtuella sessionsvärddatorer på de sekundära DR-platserna måste inte vara aktiva och köras hela tiden. Skapa ett tillräckligt antal virtuella datorer från början och använd en autoskalningsmekanism som skalningsplaner. De här mekanismerna håller de flesta beräkningsresurserna offline eller frigjorda för att minska kostnaderna.

Du kan också använda automatisering för att skapa sessionsvärdar i den sekundära regionen, endast när det behövs. Den här metoden optimerar kostnaderna, men det kan kräva en längre RTO beroende på vilken mekanism du använder. Den här metoden tillåter inte redundanstester utan en ny distribution eller selektiv redundans för specifika användargrupper.

Anmärkning

Du måste starta varje virtuell sessionsvärd i några timmar minst en gång var 90:e dag för att uppdatera den autentiseringstoken som behövs för att ansluta till Azure Virtual Desktop-kontrollplanet. Du bör också rutinmässigt tillämpa säkerhetskorrigeringar och programuppdateringar.

Kapacitetsöverväganden vid katastrofer

Sessionsvärdunderhåll i ett offline- eller frikopplat tillstånd i den sekundära regionen garanterar inte kapacitet under en primär regionomfattande katastrof. Den här kapacitetsgränsen gäller även om du distribuerar nya sessionsvärdar på begäran vid behov och med Site Recovery. Beräkningskapacitet garanteras endast om de relaterade resurserna redan är allokerade och aktiva.

Viktigt!

Azure-reservationer säkerställer inte kapacitet i regionen.

Storleksändring för molncachedisk

För användningsfall för molncache rekommenderar vi Premium-nivån för hanterade diskar. Molncachen använder en lokal cachedisk på varje sessionsvärd för att mellanlagra profildata före replikering till fjärrlagringsprovidrar. Justera storleken på den här lokala cachedisken så att den är minst lika stor som den största förväntade VHD- eller VHDX-filen för användarprofilen. En underdimensionerad cache-disk orsakar inloggningsfel. Som utgångspunkt allokerar du minst 30 GB för varje samtidig användare och övervakar de faktiska profilstorlekarna som ska justeras. Mer information finns i Dokumentation om molncachen.

Storage

I den här guiden använder du minst två separata lagringskonton för varje Azure Virtual Desktop-värdpool. Ett konto är för FSLogix-profilcontainern och ett konto är för Office-containerdata. Du behöver också ytterligare ett lagringskonto för MSIX-paket .

Lagringsalternativ och återhämtning

Du kan använda en Azure Files-resurs och Azure NetApp Files som lagringsalternativ. Information om hur du jämför dessa alternativ finns i Lagringsalternativ för FSLogix-container. En Azure Files-resurs kan ge zonåterhämtning med hjälp av ZRS-återhämtningsalternativet om den är tillgänglig i regionen.

Du kan inte använda GRS-lagringsfunktionen i följande situationer:

• Du behöver en region som saknar ett regionpar. Regionpar för GRS är fasta och kan inte ändras.

• Du använder Premium-nivån.

  Varning

  Azure Files Premium-nivån stöder inte GRS. Om du behöver Premium-prestanda för FSLogix-profillagring förlitar du dig på FSLogix-molncache för replikering mellan regioner i stället för inbyggd geo-replikering i Storage.

• RPO och RTO är högre jämfört med molncachen.

• Testning av failover och failback i en produktionsmiljö är inte enkel.

Överväganden för Azure NetApp Files

Azure NetApp Files stöder elastiska zonredundanta volymer som distribuerar data mellan tillgänglighetszoner för motståndskraft på zonnivå. Avgör om elastiska zonredundanta volymer uppfyller dina återhämtningskrav. Azure NetApp Files kan vara zonindelad, vilket innebär att du väljer den enda Azure-tillgänglighetszon där volymen allokeras.

Replikering mellan zoner ger återställningsbarhet, inte automatisk motståndskraft på zonnivå. Använd den för att återställa tjänsten efter ett zonstopp i stället för att fortsätta att betjäna trafiken under driftstoppet. Innan du använder den här funktionen bör du granska kraven och övervägandena för replikering mellan zoner.

Du kan använda Azure NetApp Files med zonredundant VPN och ExpressRoute-gatewayer om du använder standardnätverksfunktionen , som stöder nätverksåterhämtning. Mer information finns i Nätverkstopologier som stöds. Azure Virtual WAN stöds när du använder det med standardnätverk i Azure NetApp Files.

Replikering mellan regioner i Azure NetApp Files

Azure NetApp Files har en replikeringsmekanism mellan regioner. Den här mekanismen är inte tillgänglig i alla regioner, och replikering mellan regioner av Azure NetApp Files-volymer kan skilja sig från lagringsregionpar. Du kan inte använda replikering mellan regioner när replikering mellan zoner är aktiv.

Varning

Replikering mellan regioner i Azure NetApp Files och replikering mellan zoner är ömsesidigt uteslutande. Du måste välja återställning på zonnivå eller återställning på regionnivå för varje volym. Ta reda på vilket felomfång som är mer kritiskt för implementeringen och planera därefter.

Felövergång är inte transparent och återgång efter fel kräver omkonfiguration av lagring.

Lagringsgränser och skalning

Både Azure Files-resurser och Azure NetApp Files-lagringskonton och volymer har begränsningar i storlek, indata-/utdataåtgärder per sekund (IOPS) och bandbredds-Mbit/s.

Om det behövs kan du använda mer än en lagringsplats för samma värdpool i Azure Virtual Desktop med hjälp av inställningarna per grupp i FSLogix. Men den här metoden kräver mer planering och konfiguration.

Alternativ för MSIX-lagringskonto

Lagringskontot som du använder för MSIX-programpaket bör skilja sig från de andra kontona för profil- och Office-containrar. Följande alternativ för återställning efter geografiska katastrofer är tillgängliga:

• Alternativet med ett lagringskonto använder GRS i den primära regionen. Den sekundära regionen är fast. Det här alternativet passar inte för lokal åtkomst vid felövergång av lagringskontot.

• Det rekommenderade alternativet använder ett lagringskonto i den primära regionen och ett lagringskonto i den sekundära regionen. Använd ZRS för minst den primära regionen. Kontrollera att varje värdpool i varje region har lokal åtkomst med låg latens till MSIX-paketen. Kopiera varje MSIX-paket till båda regionerna och registrera paketen i båda värdpoolerna. Tilldela användare till programgrupperna i båda värdpoolerna.

FSLogix

Vi rekommenderar att du använder följande FSLogix-konfiguration och funktioner.

Om innehållet i profilcontainern kräver separat BCDR-hantering med andra krav än Office-containrarna delar du upp profilcontainrarna och Office-containrarna i separata lagringskonton. Office-containrar lagrar endast cachelagrat innehåll som du kan återskapa eller fylla i från källan om ett haveri inträffar. Eftersom Office-containrar endast innehåller cachelagrade data behöver du kanske inte behålla säkerhetskopior, vilket kan minska kostnaderna. När du använder olika lagringskonton konfigurerar du endast säkerhetskopior i profilcontainern. Eller så måste du ha olika inställningar som kvarhållningsperiod, lagring som används, frekvens och RTO eller RPO.

Molncache är en FSLogix-funktion som gör att du kan ange flera lagringsplatser för profiler och replikera profildata asynkront utan att förlita dig på underliggande mekanismer för lagringsreplikering. När den första lagringsplatsen misslyckas eller inte kan nås, övergår molncachen automatiskt till den sekundära regionen, vilket lägger till ett lager av återhämtning. Använd molncachen för att replikera både profil- och Office-containerdata mellan olika lagringskonton i de primära och sekundära regionerna.

Du måste konfigurera molncachen två gånger i sessionsvärdens VM-register. Konfigurera den en gång för profilcontainern och en gång för Office-containern. Du kan inaktivera molncachen för Office-containern, men den kan feljustera data mellan den primära och sekundära DR-regionen om redundansväxling och återställning efter fel inträffar. Testa det här scenariot noggrant innan du använder det i produktion.

Molncachen är kompatibel med profildelnings - och gruppinställningar . Inställningar per grupp kräver noggrann design och planering av Active Directory-grupper och medlemskap. Kontrollera att varje användare har tilldelats exakt en grupp och att gruppen används för att ge åtkomst till värdpooler.

I den sekundära DR-regionen återställer du providerordningen för CCDLocations så att det lokala (sekundära) lagringskontot är först. Molncachen skriver till den första nåbara leverantören som det aktiva skrivmålet och replikeras asynkront till efterföljande poster. När du listar det lokala lagringskontot först i varje region ser du till att skrivningar går till lokal lagring under normal drift och att replikering flödar över regioner. Mer information finns i Konfigurera profilcontainrar med molncachen.

Tips/Råd

Den här artikeln fokuserar på ett specifikt scenario. Andra scenarier finns i Alternativ för hög tillgänglighet för FSLogix - och BCDR-alternativ för FSLogix.

Exempel på molncachekonfiguration

I följande exempel visas en molncachekonfiguration och relaterade registernycklar. Ersätt platshållarlagringskontonamnen så att de matchar namnen i din miljö.

Platshållare	Beskrivning
primarystgprofiles	Lagringskonto för profilcontainrar i den primära regionen
primarystgodfc	Lagringskonto för Office-containrar i den primära regionen
secondarystgprofiles	Lagringskonto för profilcontainrar i den sekundära regionen
secondarystgodfc	Lagringskonto för Office-containrar i den sekundära regionen

Konfiguration av primär region

Följande inställningar gäller i den primära regionen:

• Profilcontainerlagringskontots enhetliga resursidentifierare (URI) = \\primarystgprofiles\profiles

  • Registernyckelsökväg = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles

  • CCDLocations-värde = type=smb,connectionString=\\primarystgprofiles\profiles;type=smb,connectionString=\\secondarystgprofiles\profiles

  Anmärkning

  Om du laddar ned FSLogix-mallarna kan du uppnå samma konfigurationer via Active Directory Group Policy Management Console (GPMC). Mer information om hur du konfigurerar grupprincipobjektet (GPO) för FSLogix finns i Använda grupprincipmallfiler för FSLogix.

  

• URI för Office-containerlagringskonto = \\primarystgodfc\odfc

  • Registernyckelsökväg = HKEY_LOCAL_MACHINE > SOFTWARE > Policy > FSLogix > ODFC

  • CCDLocations-värde = type=smb,connectionString=\\primarystgodfc\odfc;type=smb,connectionString=\\secondarystgodfc\odfc

    

Anmärkning

Föregående skärmbilder visar endast en delmängd av rekommenderade registernycklar för FSLogix och molncachen. Mer information finns i FSLogix-konfigurationsexempel.

Konfiguration av sekundär region

Följande inställningar gäller i den sekundära regionen:

• CCDLocations-providerordningen ändras så att det lokala (sekundära) lagringskontot kommer först.

• URI för profilcontainerlagringskonto = \\secondarystgprofiles\profiles

  • Registernyckelsökväg = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles

  • CCDLocations-värde = type=smb,connectionString=\\secondarystgprofiles\profiles;type=smb,connectionString=\\primarystgprofiles\profiles

• URI för Office-containerlagringskonto = \\secondarystgodfc\odfc

  • Registernyckelsökväg = HKEY_LOCAL_MACHINE > SOFTWARE > Policy > FSLogix > ODFC

  • CCDLocations-värde = type=smb,connectionString=\\secondarystgodfc\odfc;type=smb,connectionString=\\primarystgodfc\odfc

Replikering av molncachen

Molncachens konfigurations- och replikeringsmekanismer replikerar profildata mellan olika regioner med minimal dataförlust. Eftersom endast en process kan öppna samma användarprofilfil i ReadWrite-läge kan du undvika samtidig åtkomst. Användare bör inte öppna en anslutning till båda värdpoolerna samtidigt.

Det här diagrammet visar ett scenario för replikering av molncachen i två regioner och kontrasterar en lyckad första session med en misslyckad andra session. Längst till vänster startar en Azure Virtual Desktop-användare den första sessionen och ansluter till en Azure Virtual Desktop-värdpool i den primära regionen. I rutan primär region monterar sessionsvärden en profildisk och hämtar ett läs-skrivlås. En prickad pil med etiketten molncachereplik pekar från profildisken i den primära regionen till profildisken i den sekundära regionen. I mitten sträcker sig en molncache-repliksökväg från den primära till den sekundära sidan, med streckade linjer och riktningsmarkeringar som representerar asynkront replikeringsbeteende mellan regioner. En pil märkt andra sessionen till DR-platsen pekar från Azure Virtual Desktop-användaren till den sekundära regionen. Till höger innehåller en speglad värdpoolbox i den sekundära regionen (DR) en annan sessionsvärd och en andra profildisk. En felkod ERROR_LOCK_VIOLATION 33 (0x21) visas. Det går inte att upprätta en piletiketterad replik från profildisken till profildisken i den primära regionen.

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

Dataflöde

1. En Azure Virtual Desktop-användare startar Azure Virtual Desktop-klienten och öppnar ett publicerat skrivbord eller en RemoteApp-applikation som tilldelats värdpoolen i den primära regionen.

2. FSLogix hämtar användarprofilen och Office-containrarna och monterar därefter den underliggande lagrings-VHD:n eller VHDX:n från det lagringskonto som finns i den primära regionen.

3. Molncachen initierar samtidigt replikeringen mellan filerna i den primära regionen och filerna i den sekundära regionen. Under den här processen tar molncachen i den primära regionen ett exklusivt läs-skrivlås på dessa filer.

4. Samma Azure Virtual Desktop-användare vill starta ett annat publicerat program som tilldelats till värdpoolen för den sekundära regionen.

5. FSLogix-komponenten på Azure Virtual Desktop-sessionsvärden i den sekundära regionen försöker att montera användarprofilens VHD- eller VHDX-filer från det lokala lagringskontot. Monteringen misslyckas eftersom molncachekomponenten på Azure Virtual Desktop-sessionsvärden i den primära regionen blockerar dessa filer.

6. I standardkonfigurationen för FSLogix och molncachen kan användaren inte logga in, FSLogix registrerar felet ERROR_LOCK_VIOLATION 33 (0x21) i diagnostikloggarna.

   

Identitet

Användaridentiteten är viktig för Azure Virtual Desktop. För att få åtkomst till fullständiga virtuella fjärrskrivbord och fjärrappar från sessionsvärdarna måste användarna kunna autentisera. Microsoft Entra ID tillhandahåller den här centraliserade molnidentitetstjänsten. Azure Virtual Desktop använder Microsoft Entra-ID för att autentisera användare. Sessionvärdar kan ansluta till samma Microsoft Entra-klient eller till en Active Directory-domän med hjälp av AD DS eller Domain Services. Den här flexibiliteten ger en mängd olika konfigurationsalternativ.

Microsoft Entra ID-motståndskraft

Microsoft Entra ID är en global multiregion och elastisk tjänst med ett serviceavtal med hög tillgänglighet. Ingen annan åtgärd krävs i den här kontexten som en del av en Azure Virtual Desktop BCDR-plan.

Krav för hög tillgänglighet för AD DS

Om du vill göra AD DS motståndskraftigt och mycket tillgängligt, även om en regionomfattande katastrof inträffar, distribuerar du minst två domänkontrollanter i den primära Azure-regionen. Placera dessa domänkontrollanter i olika tillgänglighetszoner om möjligt och säkerställ korrekt replikering mellan infrastrukturen i den sekundära regionen och så småningom lokalt. Skapa minst en domänkontrollant till i den sekundära regionen som har globala katalog- och DNS-roller. Mer information finns i Distribuera AD DS i ett virtuellt Azure-nätverk.

Microsoft Entra Connect-resilienskonfiguration

Om du använder Microsoft Entra-ID tillsammans med AD DS och sedan Microsoft Entra Connect för att synkronisera användaridentitetsdata mellan AD DS och Microsoft Entra ID bör du överväga återhämtning och återställning av den här tjänsten för skydd mot en permanent katastrof.

Installera en andra instans av tjänsten i den sekundära regionen och konfigurera stagingläge för att tillhandahålla hög tillgänglighet och DR.

Om återställning krävs måste administratörer höja upp den sekundära instansen när de har avlägsnat den från mellanlagringsläget. De måste följa proceduren för att växla den aktiva servern med hjälp av ett konto som har minst rollen hybrididentitetsadministratör.

Överväganden för Domäntjänster

Du kan använda Domain Services i vissa scenarier som ett alternativ till AD DS. Domain Services tillhandahåller ett serviceavtal med hög tillgänglighet.

Om återställning efter geografiska katastrofer ingår i tillämpningsområdet för ditt scenario distribuerar du en annan replik i den sekundära regionen i Azure via en replikuppsättning. Du kan också använda den här funktionen för att öka hög tillgänglighet i den primära regionen.

Felövergång och felåtergång

Överväg följande scenarier för värdpoolen.

Scenario för personlig värdpool

Anmärkning

Det här avsnittet beskriver endast den aktiva-passiva modellen. Den aktiva-aktiva modellen kräver inte redundans eller administratörsintervention.

Redundansövergång och återgång vid fel för en personlig värdpool fungerar annorlunda eftersom molncaching eller extern lagring för profil- eller Office-containrar inte används. Du kan fortfarande använda FSLogix för att lagra data i en container som är associerad med sessionsvärden. Det finns ingen sekundär värdpool i DR-regionen, så du behöver inte skapa extra arbetsytor eller Azure Virtual Desktop-resurser för att replikera eller justera. Du kan använda Site Recovery för att replikera sessionsvärdar (virtuella maskiner).

Du kan använda Site Recovery i flera olika scenarier. För Azure Virtual Desktop använder du Azure-till-Azure DR-arkitekturen i Site Recovery.

Driftöverväganden för Site Recovery

Administratörer måste utlösa Site Recovery-redundans manuellt med hjälp av Azure-portalen, API:et eller PowerShell. Du kan skripta och automatisera hela Site Recovery-konfigurationen och -åtgärderna med hjälp av PowerShell. Serviceavtalet för Site Recovery deklarerar ett återställningstidens mål (RTO) och Site Recovery växlar vanligtvis över virtuella datorer på några minuter. Du kan använda Site Recovery och Backup tillsammans. Mer information finns i Stöd för Site Recovery med säkerhetskopiering. Du måste konfigurera Site Recovery på vm-nivå eftersom det inte finns någon direkt integrering i Azure Virtual Desktop. Du måste också initiera failover och failback på den enskilda virtuella datorns nivå.

Varning

Använd inte redundansfunktionen för Site Recovery-test för virtuella Azure Virtual Desktop-sessionsvärddatorer. Ett test-failover skapar en duplicerad virtuell dator som registrerar sig med Azure Virtual Desktops kontrollplan och som står i konflikt med den ursprungliga sessionsvärden. Verifiera i stället DR-beredskapen genom att starta sekundära sessionsvärdar regelbundet, bekräfta att varje virtuell dator registreras med kontrollplanet och köra de dokumenterade övergångs- och återställningsprocedurerna med en testanvändargrupp.

Site Recovery underhåller inte VM-tillägg under replikeringen. Om du använder anpassade tillägg för sessionsvärd-VM i Azure Virtual Desktop måste du ställa in tilläggen efter failover-process eller återgång efter fel. Inbyggda utökningar joindomain och Microsoft.PowerShell.DSC för Azure Virtual Desktop gäller endast första gången en virtuell sessionsvärd skapas. Du kan bortse från dem efter den första failövern. Granska supportmatrisen för azure VM DR mellan Azure-regioner. Kontrollera krav, begränsningar och kompatibilitetsmatrisen för Site Recovery Azure till Azure DR-scenariot, särskilt de operativsystemversioner som stöds.

När du redundansväxlar en virtuell dator till en annan region startar den virtuella datorn i mål-DR-regionen i ett oskyddat tillstånd. Återställning efter fel är möjlig, men du måste återaktivera skyddet av virtuella datorer i den sekundära regionen och aktivera replikering till den primära regionen. Kör regelbundna tester av redundans- och återställningsprocedurer. Dokumentera en lista över steg och återställningsåtgärder baserat på din specifika Azure Virtual Desktop-miljö.

Scenario för poolbaserad värdpool

Använd en aktiv-aktiv DR-modell när du behöver tjänståterställning utan administratörsintervention under ett avbrott. Använd endast redundansprocedurer för en aktiv-passiv arkitektur. I en aktiv-passiv modell förblir den sekundära DR-regionen inaktiv och behåller minimala färdiga resurser. Behåll den sekundära konfigurationen i linje med den primära konfigurationen. Under redundansväxlingen omtilldelar du alla användare till programgrupper för skrivbords- och fjärrappar i den sekundära DR-värdpoolen.

Du kan implementera en aktiv-aktiv modell med partiell redundansväxling. Om värdpoolen endast publicerar skrivbord och programgrupper delar du upp användare i active directory-grupper som inte överlappar varandra och mappar varje grupp till programgrupper i antingen den primära eller sekundära DR-värdpoolen. Behåll varje användare på en värdpool i taget. Om du publicerar flera programgrupper och program kan gruppmedlemskap överlappa varandra. Den överlappningen gör den aktiva-aktiva modellen svårare att använda. När en användare startar en fjärrapp i den primära värdpoolen läser FSLogix in användarprofilen på en virtuell sessionsvärd. Om du försöker utföra samma åtgärd på den sekundära värdpoolen kan det orsaka en konflikt på den underliggande profildisken.

Varning

Som standard förhindrar FSLogix-registerinställningar samtidig åtkomst till samma användarprofil från flera sessioner. I det här BCDR-scenariot behåller du det här beteendet och anger registernyckeln ProfileType till 0.

Villkor och konfigurationsantaganden

Värdpoolerna i den primära regionen och den sekundära DR-regionen använder justerade konfigurationer, inklusive molncachen. I båda värdpoolerna är DAG1, APPG2 och APPG3 tillgängliga för användare. I den primära värdpoolen tilldelar Active Directory-grupperna GRP1, GRP2 och GRP3 användare till DAG1, APPG2 och APPG3. Gruppmedlemskap kan överlappa varandra, men det här mönstret är fortfarande acceptabelt eftersom det här scenariot använder en aktiv-passiv modell med fullständig redundansväxling.

Följande steg beskriver redundansväxlingsprocessen för antingen en planerad eller oplanerad DR-händelse:

1. I den primära värdpoolen tar du bort användartilldelningar av grupperna GRP1, GRP2 och GRP3 för programgrupperna DAG1, APPG2 och APPG3.

2. Anslutna användare tvingas frånkopplas från den primära värdpoolen.

3. I den sekundära värdpoolen, där samma programgrupper har konfigurerats, måste du ge användarna åtkomst till DAG1, APPG2 och APPG3 med hjälp av grupperna GRP1, GRP2 och GRP3.

4. Granska och justera värdpoolkapaciteten i den sekundära regionen. Du kan använda ett autoskalningsprogram för att starta sessionsvärdar automatiskt, eller så kan du starta de resurser som krävs manuellt.

Återställningsstegen och flödet är liknande, och du kan köra processen flera gånger. Molncachen och lagringskontokonfigurationen säkerställer replikering av profil- och Office-containerdata. Kontrollera att värdpoolkonfigurationen och beräkningsresurserna har återställts innan failback. Om den primära regionen har lagringsdataförlust replikerar molncachen profil- och Office-containerdata från lagring i den sekundära regionen.

Du kan också implementera en redundanstestplan med några konfigurationsändringar och ingen effekt på produktionsmiljön:

1. Skapa några testanvändarkonton i Active Directory.

2. Skapa en ny Active Directory-grupp med namnet GRP-TEST och tilldela användare.

3. Tilldela åtkomst till DAG1, APPG2 och APPG3 med gruppen GRP-TEST.

4. Instruera användare i gruppen GRP-TEST att testa program.

5. Testa failover-proceduren med gruppen GRP-TEST. Ta bort åtkomst från den primära värdpoolen och bevilja åtkomst till den sekundära DR-poolen.

Följ dessa rekommendationer:

• Automatisera redundansväxlingen via PowerShell, Azure CLI eller något annat tillgängligt API eller verktyg.

• Testa den fullständiga redundans- och återställningsproceduren med jämna mellanrum.

• Kör en regelbunden konfigurationsjusteringskontroll för att hålla värdpoolerna i de primära och sekundära DR-regionerna synkroniserade.

Säkerhetskopiering

Den här guiden förutsätter att du separerar profilcontainrar och Office-containrar. FSLogix stöder den här konfigurationen och separata lagringskonton. När du har lagt profil- och Office-containrar i separata lagringskonton kan du använda olika säkerhetskopieringsprinciper.

För Office-containrar behöver du inte säkerhetskopiera data om innehållet bara är cachelagrade data som du kan återskapa från ett onlinedatalager som Microsoft 365. Om du behöver säkerhetskopiera Office-containerdata kan du använda billigare lagring eller välja en annan säkerhetskopieringsfrekvens och kvarhållningsperiod. För en personlig typ av värdpool kör du säkerhetskopiering på vm-nivå för sessionsvärd. Den här metoden gäller endast när du lagrar data lokalt. Om du använder OneDrive och omdirigering av kända mappar kanske du inte längre behöver lagra data i containern.

Anmärkning

Den här artikeln och scenariot innehåller inte OneDrive-säkerhetskopiering.

Överväganden för lagring och region

Om du inte har andra krav hanterar säkerhetskopiering av lagring i den primära regionen vanliga säkerhetskopieringsbehov. I de flesta fall behöver du inte säkerhetskopiera DR-miljön. För en Azure fildelning använder du Säkerhetskopiering. För valvets motståndstyp använder du ZRS om du inte behöver lagring utanför platsen eller regionen. Om du behöver dessa säkerhetskopior använder du GRS.

Azure NetApp Files tillhandahåller en egen inbyggd säkerhetskopieringslösning. Kontrollera regionens funktionstillgänglighet, tillsammans med krav och begränsningar. Säkerhetskopiera de separata lagringskonton som lagrar MSIX-paket om du inte enkelt kan återskapa programpaketdatabaserna.

Bidragsgivare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudförfattare:

• Ben Martin Baur | Teknisk arkitekt – Microsoft Innovation Hub

Övriga medarbetare:

• Jason Martinez | Teknisk författare
• Igor Pagliai | Huvudtekniker för FastTrack för Azure (FTA)
• Nelson Del Villar | Molnlösningsarkitekt – Azure Core-infrastruktur

Nästa steg

• Azure Virtual Desktop DR-plan
• BCDR för Azure Virtual Desktop
• Översikt över molncache
• FSLogix-konfigurationsexempel
• Utforma tillförlitliga Azure-program

Relaterade resurser

• Azure-filer som används lokalt och skyddas av AD DS
• Företagsfilresurser med DR