Többrégiós BCDR az Azure Virtual Desktophoz

Ez a cikk implementációs szintű architektúrát és konfigurációs útmutatást nyújt az Azure Virtual Desktop többrégiós üzletmenet-folytonossággal és vészhelyreállítással (BCDR) való üzembe helyezéséhez. Leírja, hogy az FSLogix hogyan tárolja a felhasználói profilokat virtuális merevlemez-tárolókban, és hogyan replikálja a felhőgyorsítótár a profilokat régiók között. Emellett ismerteti a BCDR-modell beállításait is, beleértve az Azure Site Recoveryt használó aktív-aktív, aktív-passzív és személyes gazdagépkészleteket, valamint az FSLogix felhőalapú gyorsítótár konfigurációját, a feladatátvételi és feladat-visszavételi eljárásokat, valamint a tárolási szempontokat.

Az útmutató két kapcsolódó erőforrásra épül:

• Az Azure Virtual Desktop kezdőzónájának tervezési útmutatója, amely az Azure Virtual Desktop alapvető infrastruktúráját hozza létre, beleértve az előfizetéseket, a hálózatkezelést, az identitást és a szabályozást.

• Az Azure Virtual Desktop számítási feladatainak BC-szempontjai, amelyek tervezési alapelveket és összetevőszintű javaslatokat nyújtanak az Azure Well-Architected-keretrendszer alapján.

Ez a cikk a megvalósítás részleteire összpontosít, beleértve az architektúradiagramokat, a beállításjegyzékszintű konfigurációt, a lépésenkénti feladatátvételi eljárásokat és a DR tesztelési megközelítéseit.

Célok és hatókör

Ez az útmutató a következő célokat tartalmazza:

• Biztosítsa a maximális rugalmasságot és a geo-vészhelyreállítási képességet, miközben minimalizálja a kiválasztott felhasználói adatok adatvesztését.

• A helyreállítási idő minimalizálása.

Ezeket a célkitűzéseket a helyreállítási pont célkitűzésének (RPO) és a helyreállítási idő célkitűzésének (RTO) is nevezik.

Az elérhető RPO és RTO a kiválasztott BCDR-modelltől és gazdagépkészlet-típustól függ. Az alábbi táblázat az egyes modellek hozzávetőleges becsléseit tartalmazza.

BCDR-modell	RPO	RTO	Főbb tényezők
Aktív-aktív a felhőbeli gyorsítótárral (megosztott)	Másodperc és néhány perc (a felhőalapú gyorsítótár aszinkron replikációs késése)	Közel nulla (nincs szükség feladatátvételre, mindkét gazdagépkészlet kiszolgálja a felhasználókat)	Kétrégiós számítási és tárolási költség. Korlátozza a felhasználókat, hogy egyszerre csak egy gazdagépkészlethez férjenek hozzá.
Aktív-passzív felhő gyorsítótárral (összevont)	Másodperc és néhány perc (a felhőalapú gyorsítótár aszinkron replikációs késése)	15–60 perc a számítási bemelegítési időtől, az automatikus skálázási időtől és az alkalmazáscsoportok újraosztásától függően	A költségek csökkentése érdekében felszabadíthatja a másodlagos számítást. A kapacitás csak akkor garantált, ha virtuális gépek futnak vagy igény szerinti kapacitásfoglalások vannak érvényben.
Személyes gazdagépkészlet a Site Recoveryvel	5–15 perc (Site Recovery replikációs gyakorisága)	A Site Recovery virtuális gép feladatátvételi ideje (általában az egyes virtuális gépek esetében percek), a tartományhoz való újbóli csatlakozás ideje és a virtuális gép bővítmények újbóli alkalmazásának ideje	Nincs FSLogix felhőalapú gyorsítótár. Minden virtuális géphez be kell állítania a Site Recoveryt.

Megjegyzés:

Ezeket a példákat ne a Microsoft garanciájaként, hanem becslésként kezelje. Érvényesítheti őket a környezetben végzett DR-teszteléssel. A tényleges RPO a profil méretétől, a tároló átviteli sebességétől és a régiók közötti hálózati sávszélességtől függ. A tényleges RTO függ a munkamenet-gazdagépek számától, az automatikus skálázási konfigurációtól és az alkalmazáscsoport-hozzárendelések befejezéséhez szükséges időtől.

Ez a megoldás helyi magas rendelkezésre állást, védelmet biztosít egyetlen rendelkezésre állási zóna meghibásodása ellen, és védelmet nyújt egy teljes Azure-régió meghibásodása ellen. A szolgáltatás helyreállításához egy másik, vagy másodlagos Azure-régióban történő redundáns üzembe helyezésre támaszkodik. A párosított régiók használata ajánlott eljárás, de az Azure Virtual Desktop és a BCDR-t támogató technológia nem igényli az Azure-régiók párosítást. Az Azure-régiók bármilyen kombinációját használhatja elsődleges és másodlagos helyekhez, amennyiben a hálózati késés lehetővé teszi. Az Azure Virtual Desktop gazdagépkészletek több földrajzi régióban való üzemeltetése a BCDR-n túli előnyöket is biztosít.

Az egyetlen rendelkezésre állási zóna meghibásodásának hatásának csökkentése érdekében alkalmazza az alábbi rugalmassági eljárásokat a magas rendelkezésre állás javítása érdekében:

• A számítási rétegben terjessze el az Azure Virtual Desktop-munkamenet-gazdagépeket a különböző rendelkezésre állási zónák között.

• A tárolási rétegben lehetőség szerint használja a zóna rugalmasságát.

• A hálózati rétegben helyezzen üzembe zónareziliens Azure ExpressRoute-átjárókat és virtuális magánhálózati (VPN-) átjárókat.

• Minden függőség esetében tekintse át az egyetlen zónakimaradás hatását, és tervezze meg a kockázatcsökkentéseket. Helyezzen üzembe például Active Directory-tartományvezérlőket és más külső erőforrásokat, amelyeket az Azure Virtual Desktop felhasználói több rendelkezésre állási zónán keresztül érnek el.

A használt rendelkezésre állási zónák számától függően fontolja meg a munkamenet-gazdagépek túlterjedését, hogy figyelembe vegye a zóna esetleges elvesztését. Ez a megközelítés segít fenntartani a felhasználói élményt és a teljesítményt, még akkor is, ha csak (n-1) zónák állnak rendelkezésre.

Megjegyzés:

Az Azure rendelkezésre állási zónák magas rendelkezésre állású funkciók, amelyek javíthatják a rugalmasságot. Ne kezelje őket olyan DR-megoldásként, amely védelmet nyújt a régiószintű katasztrófák ellen.

A tárolótípusok, a replikációs lehetőségek, a szolgáltatásképességek és a regionális rendelkezésre állási korlátok lehetséges kombinációi miatt a társpecifikus replikációs mechanizmusok helyett használja az FSLogix felhőgyorsítótár-funkciót .

Hatókör korlátozásai

Ez a cikk a költségvonzatokat ismerteti, de a fő cél egy hatékony geo-vészhelyreállítási üzembe helyezés biztosítása, amely minimalizálja az adatvesztést. Ez nem fedi le a OneDrive-ot. További információ: SharePoint és OneDrive adatrugalmasság a Microsoft 365-ben.

A BCDR-vel kapcsolatos további információkért tekintse meg a következő cikkeket:

• Az Azure Virtual Desktop számítási feladatainak BC-szempontjai
• Az Azure Virtual Desktop BCDR-szempontjai
• Azure Virtual Desktop DR

Előfeltételek

A többrégiós BCDR implementálása előtt telepítse az alapszintű célzóna-infrastruktúrát az elsődleges és a másodlagos Azure-régiókban is. A hálózati topológiával, identitással és előfizetés-struktúrával kapcsolatos útmutatásért tekintse meg az Azure Virtual Desktop kezdőzónájának tervezési útmutatóját , valamint az Azure Virtual Desktop hálózati topológiáját és kapcsolatát.

A BCDR esetében kövesse az alábbi hálózati előfeltételeket:

• Telepítse az elsődleges gazdacsoportot és a másodlagos helyreállítási környezetet külön ág virtuális hálózatokba, amelyek mindegyike a saját régiójuk központi hubjához csatlakozik. A két központ közötti kapcsolat beállítása.

• Győződjön meg arról, hogy mindegyik központ hibrid kapcsolatot biztosít a helyszíni erőforrásokhoz, a tűzfalszolgáltatásokhoz, az identitáserőforrásokhoz, például az Active Directory-tartományvezérlőkhöz és az olyan felügyeleti erőforrásokhoz, mint a Log Analytics.

• Ellenőrizze, hogy az üzletági (LOB) alkalmazások és a függő erőforrások elérhetők-e a másodlagos helyen a feladatátvétel során.

Azure Virtual Desktop vezérlősík BCDR

Az Azure Virtual Desktop vezérlősíkja tartalmazza a webes, a közvetítői, az átjárói, az erőforráskönyvtárat és a diagnosztikai szolgáltatásokat. A Microsoft kezeli a vezérlősíkot, és támogatja a regionális feladatátvételt. Ha egy régió leállást tapasztal, a vezérlősík összetevői automatikusan feladatátvételt hajtanak végre, és továbbra is működnek. Nem kell beállítania a vezérlősík redundanciát. A megosztott feladatokról és a vezérlősík architektúrájáról további információt az Azure Virtual Desktop szolgáltatásarchitektúrájában, valamint az Azure Virtual Desktop számítási feladatainak rugalmasságával és BC-vel kapcsolatos szempontjaiban talál.

Földrajzi vs. regionális gazdagépkészletek

Az Azure Virtual Desktop két gazdagépkészlet üzembehelyezési hatókörét támogatja, amelyek meghatározzák, hogy a szolgáltatás hol és hogyan tárolja a vezérlősík metaadatait:

• Földrajzi gazdagépkészletek (klasszikus modell): Ez a modell egy földrajzi adatbázisban tárolja a gazdagépkészlet metaadatait, amely több Azure-régiót szolgál ki ugyanabban az Azure-földrajzban. Az adatbázis egy párosított régióba replikálódik a régiók közötti helyreállításhoz. A földrajzi adatbázist üzemeltető régió adatbázis- vagy infrastruktúraproblémái akkor is hatással vannak a gazdagépkészletekre az adott földrajzi régióban, ha ezek a régiók egyébként kifogástalan állapotban vannak.

• Regionális gazdagépkészletek: Ez a modell egy régiónkénti adatbázisban tárolja a gazdagépkészlet metaadatait, amelyet közvetlenül a kiválasztott Azure-régióban helyez üzembe. Több replika is lefedi az adott régió rendelkezésre állási zónáit, a metaadatok pedig egy párosított régióba replikálódnak a régiók közötti feladatátvételhez. Az egyik régióban előforduló probléma csak az adott régióban lévő gazdagépkészleteket érinti, ami megszünteti a földrajzi modell régióközi függőségét.

A földrajzi és regionális gazdagépkészletek ugyanúgy működnek. Ezek csak az adatbázis architektúrájában, a metaadatok helyében és a rugalmassági jellemzőkben különböznek.

A BCDR-üzembe helyezéseknél a regionális gazdagép-csoportok a következő előnyöket biztosítják:

• Csökkentett hatástartomány: Az elsődleges régió vezérlősík-problémája nem érinti a másodlagos régió gazdagépkészletét, mert minden régió független adatbázist használ.

• Adatszuverenitás: A gazdagépkészlet metaadatai a kiválasztott Azure-régióban maradnak, ami segít megfelelni az adattárolási helyi követelményeknek.

• Független működés: Regionális kimaradások esetén a másodlagos régió host poolja továbbra is saját vezérlősík-infrastruktúrájával működik, és nem függ az érintett régiótól.

A regionális gazdagépkészletek nyilvános előzetes verzióban érhetők el. Az előzetes verzióban a földrajzi és regionális Azure Virtual Desktop-objektumok, köztük a gazdagépkészletek, a munkaterületek és az alkalmazáscsoportok nem működnek együtt. Csak az azonos üzembehelyezési hatókörrel rendelkező objektumok társítanak egymással. A BCDR-architektúra tervezésekor győződjön meg arról, hogy az elsődleges és a másodlagos gazdagépkészletek, a munkaterületek és az alkalmazáscsoportok egyaránt ugyanazt az üzembehelyezési hatókört használják. A támogatott régiókról, az előzetes verzió korlátairól és a migrálási útmutatóról további információt a Regionális gazdagépkészletek című témakörben talál.

Fontos

Javasoljuk, hogy az összes új hoszthalmazt regionális hoszthalmazként hozza létre a jobb rugalmasság és adat szuverenitás érdekében. Tervezze meg a meglévő földrajzi hosztkészletek regionális hosztkészletekbe történő átmenetét. A Microsoft migrálási eszközöket biztosít, és bejelenti a földrajzi gazdagépkészletek elavulási idővonalait.

Az Azure Virtual Desktop adathelyei függetlenek a munkamenet-gazdagép virtuálisgép-helyétől. Az Azure Virtual Desktop metaadatait egy támogatott régióban helyezheti el, és virtuális gépeket helyezhet üzembe egy másik régióban.

A következő Azure Virtual Desktop-gazdagépkészlet-típusok támogatják a különböző helyreállítási megoldásokat:

• Személyes: Ebben a típusú gazdagépkészletben a felhasználók egy állandóan hozzárendelt munkameneti gazdagéphez kapnak hozzáférést, és a hozzárendelés véglegesen megmarad. Mivel minden felhasználó rendelkezik dedikált virtuális géppel, a virtuális gép tárolhatja a felhasználói adatokat. Az állapot megőrzése és védelme replikációs és biztonsági mentési technikákkal.

• Készletbe helyezve: Az ilyen típusú gazdagépkészletben a rendszer ideiglenesen hozzárendeli a felhasználókat az elérhető munkamenetgazdagépekhez a készletből egy asztali alkalmazáscsoport (DAG) segítségével vagy távoli alkalmazások használatával. A virtuális gépek állapot nélküliek, és a rendszer a felhasználói adatokat és profilokat külső tárolóban vagy OneDrive-on tárolja.

Aktív-aktív és aktív-passzív

Ha a különböző felhasználói csoportok eltérő BCDR-követelményekkel rendelkeznek, javasoljuk, hogy több különböző konfigurációval rendelkező gazdagépkészletet használjon. A kritikus fontosságú alkalmazással rendelkező felhasználók például egy teljes mértékben redundáns gazdagépkészletet rendelhetnek hozzá, amely georedundáns helyreállítási képességekkel rendelkezik. A fejlesztési és tesztelési felhasználók külön gazdagépkészletet használhatnak dr. nélkül.

Minden Azure Virtual Desktop-gazdagépkészlet esetében a BCDR-stratégiát egy aktív-aktív vagy aktív-passzív modellre alapozhatja. Ez a forgatókönyv feltételezi, hogy egy gazdagépkészlet ugyanazt a felhasználókészletet szolgálja ki egyetlen földrajzi helyen.

Aktív-aktív modell jellemzői

Ez a szakasz azt ismerteti, hogyan viselkedik egy aktív-aktív Azure Virtual Desktop-telepítés két Azure-régióban, beleértve a gazdagépkészlet tervezését, a késéssel kapcsolatos szempontokat és a profilkezelést.

Gazdagépkészlet és feladatátvétel tervezése

Az elsődleges régió minden hosztkészletéhez telepítsen egy második hosztkészletet a másodlagos régióban. Ez a konfiguráció közel nulla RTO-t biztosít. A közel nulla RPO többletköltséget igényel. Nincs szükség rendszergazda beavatkozásra vagy feladatátvételre. A normál műveletek során a másodlagos gazdagépkészlet Azure Virtual Desktop-erőforrásokon keresztül szolgálja ki a felhasználókat.

Tárolási és profil-megfontolások

Minden gazdagépkészlet rendelkezik saját tárhelyfiókkal (legalább egy) az állandó felhasználói profilokhoz.

Ha az FSLogix-profil és az Office-tárolók külön-külön történő kezeléséhez tárolóra van szüksége, használja a felhőbeli gyorsítótárat a közel nulla RPO biztosításához. Kerüljék el a felhasználók az egyidejű hozzáférést mindkét host poolhoz a profilütközések elkerülésére. Mivel ez a forgatókönyv aktív-aktív, megtaníthatja a felhasználóknak, hogyan használhatják ezeket az erőforrásokat.

Megjegyzés:

A különálló Office-tárolók használata speciális, összetettebb forgatókönyv. Ezt a beállítást csak bizonyos helyzetekben kell üzembe helyezni.

Felhasználói élmény és alkalmazáscsoportok

A felhasználók különböző alkalmazáscsoportokhoz, például DAG-hoz és RemoteApp-csoportokhoz vannak rendelve az elsődleges és a másodlagos gazdagépkészletekben. Ebben az esetben ismétlődő bejegyzéseket látnak az Azure Virtual Desktop-ügyfélcsatornában. Az egyértelműség kedvéért használjon különálló Azure Virtual Desktop-munkaterületeket, amelyek neve és címkéi az egyes erőforrások rendeltetését tükrözik. Megtaníthatja a felhasználóknak, hogyan használhatják ezeket az erőforrásokat.

Késés és regionális közelség

Értékelje ki a késést a felhasználó fizikai helye és az elérhető kapcsolat alapján. Egyes Azure-régiók, például Nyugat-Európa és Észak-Európa esetében a különbség elhanyagolható lehet, ha az elsődleges vagy másodlagos régiókhoz fér hozzá. Értékelje ki a hálózati késést az egyes felhasználói populációk fizikai helye és a munkamenet-gazdagépeket és a háttérrendszereket egyaránt üzemeltető régiók alapján, beleértve a LOB-alkalmazásokat, az adatbázisokat és a fájlmegosztásokat. A felhasználók, a munkamenet-gazdagépek és az általuk elérhető háttérrendszerek közelsége elengedhetetlen a rugalmas felhasználói élményhez. A késés teszteléséhez üzembe helyezhet teszt virtuális gépeket a kívánt régióban, és a PowerShell-eszközök, például a Test-NetConnection vagy a PsPing használatával tesztforgalmat küldhet az ügyfélrendszerekbe és onnan.

Dr. forgatókönyv esetén a felhasználók a másodlagos régió munkamenet-gazdagépeihez csatlakoznak, amelyek a felhasználóktól és a háttérerőforrásoktól is távolabb lehetnek. Ez a távolság növeli az utazások késését, és csökkentheti az alkalmazások válaszkészségét, különösen a késésre érzékeny számítási feladatok esetében, mint például a valós idejű adatbázisok, a hangátviteli IP-cím (VoIP) vagy az interaktív tervezőeszközök. Egyes Azure-régiópárok, például Nyugat-Európa és Észak-Európa esetében a régiók közötti késés elég alacsony ahhoz, hogy a feladatátvétel során a teljesítmény romlása alig vagy egyáltalán ne legyen hatással. A nagyobb távolságokkal elválasztott többi régiópár esetében a hatás jelentős lehet.

Az Azure hálózat oda-vissza késési statisztikáinak segítségével mérheti a régiók közötti várható késést, és futtasson végfelhasználói elfogadási teszteket a másodlagos régióból, mielőtt éles feladatátvételhez támaszkodna rá.

Aktív-passzív modell jellemzői

Ez a szakasz az aktív-passzív Azure Virtual Desktop üzembe helyezésének működését ismerteti, beleértve a számítástervezést, a feladatátvételi viselkedést és a profilkezelést.

Hosztkészlet és számítási kapacitás tervezés

Az aktív-aktív modellhez hasonlóan egy második gazdagépkészletet is üzembe helyez a másodlagos régióban az elsődleges régióban lévő összes gazdagépkészlethez.

A költségvetéstől függően kevesebb aktív számítási erőforrást helyez üzembe a másodlagos régióban, mint az elsődleges régióban. Az automatikus skálázással nagyobb számítási kapacitást biztosíthat. A skálázáshoz több idő szükséges, és az Azure nem garantálja a kapacitást.

Ez a konfiguráció magasabb RTO-t biztosít, mint az aktív-aktív megközelítés, de kevesebbe kerül.

Átállási folyamat és felhasználói hozzáférés

Rendszergazdai beavatkozásra van szükség az átálláshoz, ha Azure szolgáltatásbeli kimaradás történik. Normál műveletek során a másodlagos gazdagépkészlet nem biztosít felhasználói hozzáférést az Azure Virtual Desktop-erőforrásokhoz. Minden gazdagépkészlet saját tárfiókokkal rendelkezik az állandó felhasználói profilokhoz.

Azok a felhasználók, akik az Azure Virtual Desktop-szolgáltatásokat optimális késéssel és teljesítménnyel használják, csak Azure-kimaradás esetén lesznek érintettek. A feladatátvétel során a felhasználók a másodlagos régióban lévő munkamenet-gazdagépekhez csatlakoznak, ami növeli a felhasználó, a munkamenet-gazdagép és a munkamenet-gazdagép által elért háttérrendszerek közötti fizikai távolságot. Ez a plusz távolság növeli a hálózati utazási késést, és csökkentheti a késésre érzékeny alkalmazások válaszképességét.

Az Azure-hálózat utazási késési statisztikáinak használatával számszerűsítheti az elsődleges és a másodlagos régiók közötti várható késést. Győződjön meg arról, hogy a teljesítmény elfogadható marad a számítási feladatok számára a másodlagos régióból származó végpontok közötti teszteléssel.

Alkalmazáscsoport viselkedése

A felhasználók egy alkalmazáscsoporthoz tartoznak, például asztali és távoli alkalmazásokhoz. Ezek az alkalmazások az elsődleges gazdagépcsoportban futnak a normál műveletek során. Ha leállás történik, és a feladatátvétel befejeződik, a felhasználók a másodlagos gazdagépkészlet alkalmazáscsoportjaihoz lesznek rendelve. Az Azure Virtual Desktop-ügyfél nem jelenít meg ismétlődő bejegyzéseket, a felhasználók ugyanazt a munkaterületet megőrzik, és az átmenet transzparens marad.

FSLogix-szempontok

Ha tárolóra van szüksége az FSLogix-profil és az Office-tárolók kezeléséhez, használja a felhőbeli gyorsítótárat a közel nulla RPO biztosításához.

A profilütközések elkerülése érdekében korlátozza a felhasználók hozzáférését, hogy egyszerre csak egy gazdagépkészlethez férhessenek hozzá. Aktív-passzív forgatókönyvekben a rendszergazdák az alkalmazáscsoport szintjén érvényesítik ezt a korlátozást. A felhasználó csak a feladatátvétel befejezése után érheti el a másodlagos gazdagépkészlet minden egyes alkalmazáscsoportját. A hozzáférést visszavonták az elsődleges gazdagépkészlet alkalmazáscsoportjából, és újrarendelték egy másodlagos gazdagépkészlet alkalmazáscsoporthoz.

Feladatátvételt hajt végre minden alkalmazáscsoport esetében. Ellenkező esetben azok a felhasználók, akik különböző gazdagépkészletekben férnek hozzá különböző alkalmazáscsoportokhoz, profilütközéseket okozhatnak.

Szelektív hibajavítási tesztelés

Engedélyezheti, hogy a felhasználók egy adott részhalmaza szelektíven lépjen át a másodlagos gazdagépkészletbe, hogy tesztelje a korlátozott aktív-aktív viselkedést, és ellenőrizze a feladatátvételi képességet. Adott alkalmazáscsoportok esetében is végrehajthat feladatátvételt. Az ütközések elkerülése érdekében győződjön meg arról, hogy a felhasználók egyszerre csak egy gazdagépmedencéből férnek hozzá az erőforrásokhoz.

Egyetlen gazdagép-csoport különböző régiókban

Adott körülmények között létrehozhat egyetlen gazdagépcsoportot, amely különböző régiókban elhelyezett munkamenet-gazdagépekkel rendelkezik. Egyetlen gazdagépkészlet esetén nincs szükség az asztali és távoli alkalmazások definícióinak és hozzárendeléseinek duplikálására. A megosztott gazdagépkészletek DR használata számos kompromisszumot vezet be. Megosztott gazdagépkészletek esetében nem érvényesítheti a felhasználók regionális kapcsolati beállításait, így a felhasználók nagyobb késleltetést és alacsonyabb teljesítményű csatlakozást tapasztalhatnak, amikor egy távoli régióban lévő munkamenet szerverhez csatlakoznak. Ha tárolóra van szüksége a felhasználói profilokhoz, összetett konfigurációra van szüksége az elsődleges és másodlagos régiókban található munkamenet-gazdagépek hozzárendeléseinek kezeléséhez.

A lefolyó mód használatával ideiglenesen kikapcsolhatja a másodlagos régióban található munkamenet-gazdagépek hozzáférését, de ez a megközelítés összetettséghez, felügyeleti többletterheléshez és nem hatékony erőforrás-használathoz vezethet. A munkamenet-gazdagépeket offline állapotban tarthatja fenn a másodlagos régiókban, de ez a megközelítés összetettséghez és felügyeleti többletterheléshez vezet.

BCDR-modell összehasonlítása

Az alábbi táblázat összefoglalja a BCDR-modellek közötti legfontosabb kompromisszumokat, hogy segítsen kiválasztani a követelményeknek megfelelő megközelítést.

Metric	Aktív-aktív (készletezett)	Aktív-passzív (csoportosított)	Személyes (Helyreállítás)
RTO	Közel nulla	15–60 perc a számítási készültségtől függően	Site Recovery szolgáltatásszintű szerződés (SLA) (jellemzően percek alatt) és újravédelem
RPO	Felhőbeli gyorsítótár aszinkron késése (másodperc és néhány perc)	Felhőalapú gyorsítótár aszinkron késése (néhány másodperc és néhány perc)	Site Recovery-replikáció (általában 5–15 perc)
Stacionárius költség	Magas (kettős számítás, kettős tárolás)	Közepes (minimális másodlagos számítás)	Közepes (Site Recovery replikációs költség)
Rendszergazdai beavatkozás	Nincs	Kötelező (csoportátosztás, kapacitás skálázás)	Kötelező (az egyes virtuális gépek feladatátvételének aktiválása)
Felhasználói élmény	Ismétlődő hírcsatornabejegyzések (két munkaterület)	Átlátszó (egyedi munkaterület)	Átlátható feladatátvétel után
DR-teszt összetettsége	Magas (profilzárolási kockázatok)	Közepes (GRP-TEST megközelítés)	Korlátozott (nincs Azure Virtual Desktop-integrációval rendelkező feladatátvételi teszt)
Kapacitásgarancia	Igen (mindig rendelkezésre áll kapacitás)	Nem (kivéve, ha igény szerinti kapacitásfoglalás van érvényben)	Nem (kivéve, ha igény szerinti kapacitásfoglalás van érvényben)

Építészeti diagramok

Tekintse át az alábbi architektúradiagramokat, mielőtt elolvassa az összetevőszintű tervezési útmutatót a következő szakaszokban.

Személyes gazdagép csoport

Ez az ábra egy azure-beli virtuális asztali személyes gazdagépkészlet balról jobbra többrégiós DR-architektúrát mutat be. A bal oldalon a felhasználói végpontok és az identitásszolgáltatások csatlakoznak az elsődleges Azure-régióhoz. A jobb oldalon a tükrözött másodlagos DR-régió helyreállítási kapacitást biztosít. Felül az A címkével ellátott lépések mindkét régióra kiterjednek, és azt mutatják, hogy a hitelesítés továbbra is elérhető marad egy regionális kimaradás során. A Microsoft Entra-azonosító és az opcionális Active Directory-tartományvezérlők vagy a Microsoft Entra Domain Services-replikakészletek minden régióban léteznek. Középen a B és B2 címkével ellátott útvonalak rugalmas hibrid kapcsolatot biztosítanak az egyes regionális központoktól a helyszíni és régiók közötti függőségekhez, például a tartománynévrendszerhez (DNS), a tartományvezérlőkhöz, a LOB-alkalmazásokhoz és az adatszolgáltatásokhoz. Ezek az útvonalak azt mutatják, hogy a helyreállítási régió munkamenet-gazdagépeinek a feladatátvétel után ugyanahhoz a háttérrendszerhez kell hozzáférniük. Az előfizetési és szabályozási rétegben a C és a C2 címkével ellátott lépések meghatározzák a kvótát, a hozzáférés-vezérlést és a kapacitáskövetelményeket mindkét régióban, igény szerinti kapacitásfoglalásokkal, hogy a virtuális gép elindulhasson egy regionális incidens során. A D. lépés minden régióban a rendelkezésre állási zónák között helyezi el a munkamenet-gazdagépeket, az E lépés pedig az Azure Compute Gallery replikáit használja mindkét régióban, hogy a gazdagép-buildek konzisztensek maradjanak. Az F lépés a Site Recovery, amely replikálja a személyes munkamenetgazda VM-eket az elsődleges régióból a másodlagos régióba, és támogatja a feladatátvételt, valamint a visszavétel utáni ismételt védelmet.

Töltse le az architektúra Visio-fájlját.

Tervezési terület	Leírás
A	A felhasználói identitásnak elérhetőnek kell lennie ahhoz, hogy az Azure Virtual Desktop működjön. A felhasználóknak hitelesíteniük kell magukat ahhoz, hogy elérhessék a távoli asztalokat vagy távoli alkalmazásokat. A Microsoft Entra ID-ra szükség van, és globális rugalmasságot biztosít a tervezéshez. Ha az Active Directory Domain Servicest (AD DS) használja a munkamenetgazda tartományhoz való csatlakozáshoz, helyezzen üzembe tartományvezérlőket mind az elsődleges, mind a másodlagos régiókban, a rendelkezésre állási zónák között elosztva, hogy a hitelesítés továbbra is elérhető maradjon a regionális feladatátvétel során. Ha a Microsoft Entra Domain Services szolgáltatást használja, helyezzen üzembe egy replikakészletet a másodlagos régióban. További információ: Identitás.
B és B2	Ha a munkamenet-gazdagépeknek el kell érniük a helyszíni erőforrásokat, például fájlkiszolgálókat, LOB-alkalmazásokat, adatbázisokat vagy intranetes helyeket, akkor az ezt a kapcsolatot biztosító hálózati infrastruktúrának is rugalmasnak kell lennie. Redundáns hibrid kapcsolatok, például ExpressRoute-kapcsolatcsoportok, VPN-átjárók vagy mindkettő üzembe helyezése minden régióban. Győződjön meg arról, hogy a függő helyszíni vagy régiók közötti erőforrások, köztük a tartománynévrendszer (DNS), a tartományvezérlők és az alkalmazás háttérrendszerei elérhetők a másodlagos régióból a feladatátvétel során. A kapcsolat nélkül elindulnak a munkamenet-gazdagépek a DR régióban, de a felhasználók nem férhetnek hozzá a szükséges alkalmazásokhoz és adatokhoz.
C és C2	Győződjön meg arról, hogy az elsődleges és a másodlagos régióban lévő előfizetések elegendő virtuálisgép-kvótával rendelkeznek a munkamenetgazda által használt virtuálisgép-családok számára, és hogy a megfelelő Azure-szerepköralapú hozzáférés-vezérlési (Azure RBAC) szerepköröket rendeli hozzá. Regionális katasztrófa esetén a felszabadított virtuális gépek vagy az újonnan üzembe helyezett munkamenet-gazdagépek versenyeznek a másodlagos régió kapacitásáért. A kvóta önmagában nem garantálja a fizikai kapacitás rendelkezésre állását. Igény szerinti kapacitásfoglalások használatával előre lefoglalhatja a számítási kapacitást a másodlagos régióban, ami garantálja a virtuális gép indítását, amikor szüksége van rá. Az Azure-foglalások (fenntartott példányok) csökkentik a költségeket, de nem foglalnak le fizikai kapacitást. Tekintse át az Azure Virtual Desktop szolgáltatáskorlátait és győződjön meg arról, hogy a terv mindkét régióban a gazdagépkészlet, a munkamenetgazda és a munkaterület korlátain belül marad.
D	Terítse szét a munkamenet-gazdagép virtuálisgép-flottáját több rendelkezésre állási zónában az elsődleges és a másodlagos katasztrófa utáni helyreállítási régiókban is. Ha a régió nem biztosít rendelkezésre állási zónákat, egy rendelkezésre állási csoport használatával növelheti a rugalmasságot az alapértelmezett üzembe helyezéshez képest.
E	Használja ugyanazt az alpképet a gazdagépkészlet telepítésére mind az elsődleges, mind a másodlagos DR régióban. Tárolja a rendszerképeket az Azure Compute Galleryben, és állítson be több képreplikát mindkét helyen.
F	A személyes gazdagépkészletek esetén tartson fenn biztonsági mentési környezetet a Site Recovery használatával.

Megosztott gazdagépkészlet

Ez az ábra egy balról jobbra kiépített, többrégiós BCDR-architektúrát mutat be egy Azure Virtual Desktop készletezett gazdagépkészlethez, tükrözött elsődleges és másodlagos régiókkal. Az A–K lépéseket mutatja be. Felül a Microsoft Entra ID és az Azure Virtual Desktop vezérlősíkja mindkét régióra kiterjed, ami azt mutatja, hogy az identitás- és vezérlősík-szolgáltatások támogatják az üzembe helyezés mindkét oldalát, az A lépés pedig az egyes régiók identitásfüggőségét mutatja. A bal szélen egy helyszíni rendszerblokk tartományvezérlőket tartalmaz, és rugalmas hibrid kapcsolaton keresztül csatlakozik mindkét regionális központhálózathoz, a B és B2 címkék pedig azokat a hálózati útvonalakat és központfüggőségeket jelenítik meg, beleértve az átjárót, a tűzfalat, a DNS-t, az útválasztást és a biztonsági vezérlőket. A középső és a jobb oldali szakaszokban minden régió tartalmaz egy Azure Virtual Desktop kezdőzóna-területet erőforráscsoportokkal, küllős virtuális hálózatokkal, gazdagépkészlet-erőforrásokkal és a rendelkezésre állási zónák között elosztott munkamenet-gazdagépekkel, a C és C2 címkék pedig az előfizetési kvótát és az RBAC-készültséget, míg a D és D2 címkék az zonális munkamenet-gazdagép-eloszlást jelenítik meg. Az egyes régiók jobb oldalán a tárolási és platformszolgáltatások támogatják a felhasználói profilokat és az alkalmazáskézbesítést. Az E. lépés az FSLogix felhőalapú gyorsítótár és a CCDLocations régiók közötti viselkedését mutatja be. Az F. lépés az Azure NetApp Files teljesítményszintű tárolási lehetőségeit mutatja be. A G. lépés az FSLogix profil-tároló tárolási lehetőségeit jeleníti meg. A H lépés külön profil- és Office-tároló fiókokat jelenít meg. Az I. lépés bemutatja az App Attach csomagtárolást és replikációt. A J lépés a kritikus fájlmegosztások és profiladatok biztonsági mentési védelmét mutatja be. K lépés bemutatja a Számítási katalógus képreplikációját, így mindkét régió összehangolt golden image-eket használ a session-host üzembe helyezéséhez.

Töltse le az architektúra Visio-fájlját.

Tervezési terület	Leírás
A	A felhasználói identitásnak elérhetőnek kell lennie ahhoz, hogy az Azure Virtual Desktop működjön. A felhasználóknak hitelesíteniük kell magukat ahhoz, hogy elérhessék a távoli asztalokat vagy távoli alkalmazásokat. A Microsoft Entra ID-ra szükség van, és globális rugalmasságot biztosít a tervezéshez. Ha az AD DS-t használja a munkamenetgazda tartományhoz való csatlakozáshoz, helyezzen üzembe tartományvezérlőket az elsődleges és a másodlagos régióban is, a rendelkezésre állási zónák között elosztva, hogy a hitelesítés továbbra is elérhető maradjon a regionális feladatátvétel során. Ha a Tartományi Szolgáltatásokat használja, telepítsen egy replikakészletet a másodlagos régióban. Részletes konfigurációs útmutatásért tekintse meg az Identitás című témakört.
B	Ha a munkamenet-gazdagépeknek olyan helyszíni erőforrásokat kell elérniük, mint a fájlkiszolgálók, a LOB-alkalmazások, az adatbázisok vagy az intranetes helyek, akkor az ezt a kapcsolatot biztosító hálózati infrastruktúrának is rugalmasnak kell maradnia. Redundáns hibrid kapcsolatok, például ExpressRoute-kapcsolatcsoportok, VPN-átjárók vagy mindkettő üzembe helyezése minden régióban. Győződjön meg arról, hogy a függő helyszíni vagy régiók közötti erőforrások, köztük a DNS, a tartományvezérlők és az alkalmazás háttérrendszerei a feladatátvétel során elérhetők maradnak a másodlagos régióból. A kapcsolat nélkül elindulnak a munkamenet-gazdagépek a DR régióban, de a felhasználók nem férhetnek hozzá a szükséges alkalmazásokhoz és adatokhoz.
C	Győződjön meg arról, hogy az elsődleges és a másodlagos régióban lévő előfizetések elegendő virtuálisgép-kvótával rendelkeznek a munkamenetgazda által használt virtuálisgép-családok számára, és hogy a megfelelő Azure RBAC-szerepköröket rendeli hozzá. Regionális katasztrófa esetén a felszabadított virtuális gépek vagy az újonnan üzembe helyezett munkamenet-gazdagépek versenyeznek a másodlagos régió kapacitásáért. A kvóta önmagában nem garantálja a fizikai kapacitás rendelkezésre állását. Igény szerinti kapacitásfoglalások használatával előre lefoglalhatja a számítási kapacitást a másodlagos régióban, ami garantálja a virtuális gép indítását, amikor szüksége van rá. Az Azure-foglalások (fenntartott példányok) csökkentik a költségeket, de nem foglalnak le fizikai kapacitást. Tekintse át az Azure Virtual Desktop szolgáltatáskorlátait és győződjön meg arról, hogy a terv mindkét régióban a gazdagépkészlet, a munkamenetgazda és a munkaterület korlátain belül marad.
D	A munkamenet-gazda virtuálisgép-flottát eloszthatja ugyanazon régió különböző rendelkezésre állási zónáiban , hogy nagyobb rugalmasságot és hivatalos 99,99-% magas rendelkezésre állású SLA-t érjen el. Elegendő extra számítási kapacitást foglaljon bele a kapacitástervezésbe, hogy az Azure Virtual Desktop továbbra is működjön, még akkor is, ha egyetlen rendelkezésre állási zóna meghibásodik.
E	Az FSLogix felhőalapú gyorsítótár használatával replikálhatja a profiladatokat régiók között a rugalmasság érdekében. A felhőalapú gyorsítótár növelheti a bejelentkezési és kijelentkezési időt a hagyományos VHDLocation-ekhez képest, különösen alacsony teljesítményű tárolás esetén. Tekintse át az FSLogix felhőalapú gyorsítótár dokumentációját a helyi gyorsítótár-tárolók méretezésére és teljesítményére vonatkozó javaslatokért.
F	Az Azure NetApp Files magasabb átviteli sebességet és kisebb késést biztosít gibibyte-enként (GiB) a Prémium és Az Ultra szinteken az Azure Files Premiumhoz képest. Annak meghatározása, hogy a teljesítménykülönbség indokolja-e a felügyeleti többletterhelést és a replikációs korlátozásokat.
G	Tekintse át az Azure Virtual Desktopban elérhető FSLogix-profil tárolótárolási lehetőségeit a felügyelt tárolási megoldások összehasonlításához, és válassza ki a teljesítmény- és a BCDR-követelményeknek megfelelő lehetőséget.
H	Különítse el a felhasználói profilt és az Office-tárolólemezeket különböző tárfiókokba. Ez az elkülönítés lehetővé teszi különböző biztonsági mentési szabályzatok, adatmegőrzési időszakok és BCDR-konfigurációk alkalmazását minden tárolótípusra. További információ: FSLogix.
I	App Attach-csomagok esetén használja az Azure Storage beépített replikációs mechanizmusait a BCDR-hez. Zónaredundáns tárolás (ZRS) használata zónaszintű rugalmassághoz vagy georedundáns tároláshoz (GRS) az Azure Fileshoz régiószintű védelemhez.
J	Az Azure Backup használatával megvédheti a felhasználói profil adatait az adatvesztéstől vagy a logikai sérüléstől. Biztonsági mentési szabályzatok alkalmazása a kritikus számítási feladat adatait tartalmazó tárfiókokra.
K	Használja ugyanazt az alpképet a gazdagépkészlet telepítésére mind az elsődleges, mind a másodlagos DR régióban. Tárolja a képeket a Compute Galleryben, és állítson be több képreplikát mindkét helyen.

Megfontolandó szempontok és javaslatok

Vegye figyelembe az alábbi szempontokat és javaslatokat.

General

Ha egy aktív-aktív vagy aktív-passzív konfigurációt szeretne üzembe helyezni, amely több gazdagépkészletet és egy FSLogix felhőalapú gyorsítótár-mechanizmust használ, hozza létre a gazdagépkészletet ugyanabban a munkaterületen vagy egy másik munkaterületen, a modelltől függően. Ehhez a megközelítéshez igazításra és folyamatos frissítésekre van szükség ahhoz, hogy a gazda gépek készletei szinkronban legyenek, és azonos konfigurációs szinten maradjanak. Amikor új gazdagép-poolt hoz létre a másodlagos katasztrófa utáni régióhoz, a következő feladatokat kell elvégeznie:

• Hozzon létre új alkalmazáscsoportokat és kapcsolódó alkalmazásokat az új gazdagépkészlethez.

• Vonja vissza a felhasználói hozzárendeléseket az elsődleges gazdagépkészlethez, és a feladatátvétel során manuálisan rendelje hozzá őket az új gazdagépkészlethez.

• Tekintse át az FSLogix BCDR-beállításait.

Megjegyzés:

Ez a cikk nem tartalmaz profil-helyreállítást. Ez magában foglalja a felhőalapú gyorsítótárat (aktív-passzív), és ugyanazt a gazdagépkészletet használja a megvalósításhoz. Egy későbbi szakaszban a felhőalapú gyorsítótárat (aktív-aktív) fedi le.

Ez a megoldás Azure Virtual Desktop-erőforráskorlátokkal rendelkezik, amelyeket figyelembe kell vennie egy Azure Virtual Desktop-architektúra tervezésekor. Ellenőrizze a kialakítást az Azure Virtual Desktop szolgáltatás korlátai alapján.

Diagnosztikához és monitorozáshoz használja ugyanazt a Log Analytics munkaterületet az elsődleges és a másodlagos gazdagépkészletek számára is. Ebben a konfigurációban az Azure Virtual Desktop Insights egységes nézetet biztosít az üzembe helyezésről mindkét régióban.

Egyetlen naplócél problémákat okozhat, ha a teljes elsődleges régió elérhetetlenné válik. A másodlagos régió nem tudja használni a Log Analytics-munkaterületet a nem elérhető régióban. Ha ez az eredmény nem felel meg a rugalmassági követelményeknek, fontolja meg a következő megoldásokat:

• Minden régióhoz használjon külön Log Analytics-munkaterületet, és irányítsa az Azure Virtual Desktop összetevőit úgy, hogy a naplókat a helyi munkaterületükre küldjék.

• A Log Analytics-munkaterület replikációs és feladatátvételi képességeinek tesztelése és áttekintése.

Compute

Ez a szakasz a munkamenet-gazdagépek rendelkezésre állásával, az aranylemez-kezeléssel, az automatikus skálázással, a DR-kapacitással és a felhőalapú gyorsítótár lemezméretezésével kapcsolatos szempontokat ismerteti mind az elsődleges, mind a másodlagos dr. régióban.

Munkamenet-gazdagépek rendelkezésre állása és rugalmassága

Ha mindkét gazdagépkészletet az elsődleges és a másodlagos dr. régióban szeretné üzembe helyezni, terjessze el a munkamenetgazda virtuálisgép-flottát több rendelkezésre állási zónában. Ha a rendelkezésre állási zónák nem érhetők el a helyi régióban, egy rendelkezésre állási csoport használatával rugalmasabbá teheti a megoldást, mint egy alapértelmezett üzembe helyezés.

Arany képkonzisztencia régiók között

A gazdagépkészlet másodlagos DR-régióban való üzembe helyezéséhez használt arany rendszerképnek meg kell egyeznie az elsődleges régióhoz használt aranylemezképpel. Tárolja a képeket a Számítási gyűjteményben, és állítson be több képreplikát az elsődleges és a másodlagos helyeken is. Minden képreplika támogatja a párhuzamosan üzembe helyezhető virtuális gépek maximális számát, és az üzembehelyezési köteg méretétől függően több replikára is szükség lehet. További információ: Képek tárolása és megosztása a Compute Galleryben.

Számítási Galéria replikációja és regionális tervezése

A Számítási gyűjtemény egy regionális erőforrás. Hozzon létre legalább egy másodlagos gyűjteményt a másodlagos régióban. Az elsődleges régióban hozzon létre egy katalógust, egy virtuálisgép-lemezképdefiníciót és egy virtuálisgép-rendszerkép verzióját. Ezután hozza létre ugyanazokat az objektumokat a másodlagos régióban. Amikor a másodlagos régióban hozza létre a virtuálisgép-rendszerkép verzióját, a forrásgyűjtemény, a virtuálisgép-lemezképdefiníció és a virtuálisgép-rendszerkép verziójának megadásával másolhatja a rendszerkép verzióját az elsődleges régióból. Az Azure átmásolja a rendszerképet, és létrehoz egy helyi virtuálisgép-rendszerkép-verziót. Ezt a műveletet az Azure Portalon vagy az Azure CLI-paranccsal futtathatja.

Az aranylemezképek tervezési alapelveit, beleértve a ZRS-t és a replikatervezést, tekintse meg az Arany képek BC-szempontokban című témakört.

Automatikus skálázás és költségoptimalizálás

A másodlagos DR-helyeken nem minden munkamenetgazda virtuális gépnek kell aktívnak lennie, és mindig futnia kell. Először hozzon létre elegendő számú virtuális gépet, és használjon automatikus skálázási mechanizmust, például skálázási terveket. Ezek a mechanizmusok a legtöbb számítási erőforrást offline vagy felszabadított állapotban tartják a költségek csökkentése érdekében.

Az automatizálással munkamenet-gazdagépeket csak akkor hozhat létre a másodlagos régióban, amikor szükséges. Ez a megközelítés optimalizálja a költségeket, de a használt mechanizmustól függően hosszabb RTO-t igényelhet. Ez a megközelítés nem teszi lehetővé a feladatátvételi teszteket új üzembe helyezés vagy szelektív feladatátvétel nélkül adott felhasználói csoportok esetében.

Megjegyzés:

Legalább 90 naponta egyszer néhány órára el kell indítania minden munkamenet-gazdagép virtuális gépét, hogy frissítse az Azure Virtual Desktop vezérlősíkhoz való csatlakozáshoz szükséges hitelesítési tokent. Emellett rendszeresen alkalmazza a biztonsági javításokat és az alkalmazásfrissítéseket.

Kapacitással kapcsolatos szempontok a katasztrófák során

A munkamenet-gazdagép offline vagy felszabadított állapotban történő karbantartása a másodlagos régióban nem garantálja a kapacitást az elsődleges régióra kiterjedő katasztrófa során. Ez a kapacitáskorlát akkor is érvényes, ha szükség esetén új munkamenet-gazdagépeket helyez üzembe igény szerint, valamint a Site Recoveryvel. A számítási kapacitás csak akkor garantált, ha a kapcsolódó erőforrások már ki vannak foglalva és aktívak.

Fontos

Az Azure-foglalások nem biztosítanak garantált kapacitást a régióban.

Felhőalapú gyorsítótárlemez méretezése

A felhőalapú gyorsítótárhasználati esetekben a prémium szintű felügyelt lemezeket javasoljuk. A felhőalapú gyorsítótár minden munkamenet-gazdagépen egy helyi gyorsítótárlemezt használ a profiladatok szakaszosításához a távoli tárolószolgáltatóknak való replikáció előtt. Méretezheti ezt a helyi gyorsítótárlemezt úgy, hogy legalább akkora legyen, mint a legnagyobb várható felhasználói profilú VHD-fájl vagy virtuális merevlemez kiterjesztett (VHDX) fájlja. Az alulméretezett gyorsítótárlemez bejelentkezési hibákat okoz. Kiindulópontként foglaljon le legalább 30 GB-ot minden egyidejű felhasználóhoz, és figyelje a profil tényleges méretét a beállításhoz. További információkért tekintse meg a Cloud Cache dokumentációját.

Storage

Ebben az útmutatóban legalább két különálló tárfiókot használ mindegyik Azure Virtual Desktop-gazdagépkészlethez. Egy fiók az FSLogix-profil tárolóhoz tartozik, egy fiók pedig az Office-tároló adataihoz. Az MSIX-csomagokhoz még egy tárfiókra van szüksége.

Tárolási lehetőségek és rugalmasság

Tárolási alternatívaként használhat azure Files-megosztást és Azure NetApp Files-fájlokat . A beállítások összehasonlításához tekintse meg az FSLogix tárolótárolási beállításait. Az Azure Files-megosztások a ZRS rugalmassági lehetőségével biztosíthatják a zóna rugalmasságát, ha az elérhető a régióban.

A GRS storage szolgáltatás nem használható a következő helyzetekben:

• Olyan régióra van szükség, amely nem rendelkezik régiópárokkal. A GRS régiópárjai rögzítettek, és nem módosíthatók.

• A Prémium szintet használja.

  Figyelmeztetés

  A prémium szintű Azure Files nem támogatja a GRS-t. Ha prémium szintű teljesítményt igényel az FSLogix-profiltárolóhoz, a beépített georeplikálás helyett az FSLogix felhőbeli gyorsítótárra támaszkodhat régiók közötti replikációhoz.

• Az RPO és az RTO magasabb a felhőalapú gyorsítótárhoz képest.

• A feladatátvétel és a feladat-visszavétel tesztelése éles környezetben nem egyszerű.

Az Azure NetApp Files szempontjai

Az Azure NetApp Files támogatja a rugalmas zónaredundáns köteteket, amelyek a zónaszintű rugalmasság érdekében elosztják az adatokat a rendelkezésre állási zónák között. Annak meghatározása, hogy a rugalmas zónaredundáns kötetek megfelelnek-e az ellenállósági követelményeknek. Az Azure NetApp Files lehet zonális, ami azt jelenti, hogy az Azure-on egyetlen rendelkezésre állási zónát kell választania, ahol a kötet helyet kap.

A zónák közötti replikáció helyreállíthatóságot biztosít, nem automatikus zónaszintű rugalmasságot. Használja arra, hogy egy zónakimaradás után állítsa helyre a szolgáltatást, inkább, mintsem hogy a forgalmat kiszolgálja a kimaradás ideje alatt. A funkció használata előtt tekintse át a zónák közötti replikációra vonatkozó követelményeket és szempontokat.

Az Azure NetApp Files zónaredundáns VPN- és ExpressRoute-átjárókkal is használható, ha a szabványos hálózati funkciót használja, amely támogatja a hálózati rugalmasságot. További információ: Támogatott hálózati topológiák. Az Azure Virtual WAN támogatott, ha az Azure NetApp Files standard hálózatkezeléssel használják.

Azure NetApp Files régióközi replikáció

Az Azure NetApp Files régióközi replikációs mechanizmussal rendelkezik. Ez a mechanizmus nem érhető el minden régióban, és az Azure NetApp Files kötetek régiópárjainak régióközi replikációja eltérhet a Storage-régiópároktól. A régiók közötti replikáció nem használható, ha a zónák közötti replikáció aktív.

Figyelmeztetés

Az Azure NetApp Files régióközi replikációja és zónák közötti replikációja kölcsönösen kizárja egymást. Az egyes kötetekhez zónaszintű helyreállíthatóságot vagy régiószintű helyreállíthatóságot kell választania. Határozza meg, hogy melyik hiba hatóköre kritikusabb az üzembe helyezéshez és ennek megfelelően tervezze meg.

A feladatátvétel nem láthatatlan, és a visszaálláshoz a tárhely újrakonfigurálására van szükség.

Tárolási korlátok és skálázás

Mind az Azure Files-megosztások , mind az Azure NetApp Files-tárfiókok és -kötetek mérete, bemeneti/kimeneti műveletek másodpercenkénti száma (IOPS) és sávszélesség-MBps korlátokkal rendelkezik.

Szükség esetén az FSLogix csoportonkénti beállításaival több tárolóhelyet használhat azonos gazdagépkészlethez az Azure Virtual Desktopban. Ez a megközelítés azonban több tervezést és konfigurálást igényel.

MSIX-tárfiók beállításai

Az MSIX-alkalmazáscsomagokhoz használt tárfióknak különböznie kell a profil- és Office-tárolók többi fiókjától. A következő földrajzi vészhelyreállítási lehetőségek érhetők el:

• Az egytárolós fiók opció a GRS-t használja az elsődleges régióban. A másodlagos régió ki van javítva. Ez a beállítás nem megfelelő a helyi hozzáféréshez, amikor a tárfiók átállása történik.

• Az ajánlott beállítás egy tárfiókot használ az elsődleges régióban és egy tárfiókot a másodlagos régióban. Használja a ZRS-t legalább az elsődleges régióban. Győződjön meg arról, hogy az egyes régiókban lévő gazdagépkészletek alacsony késésű helyi hozzáféréssel rendelkeznek az MSIX-csomagokhoz. Másolja az egyes MSIX-csomagokat mindkét régióba, és regisztrálja a csomagokat mindkét host poolban. Felhasználók hozzárendelése mindkét gazdagépkészlet alkalmazáscsoportjaihoz.

FSLogix

Javasoljuk, hogy a következő FSLogix-konfigurációt és -funkciókat használja.

Ha a profiltároló tartalma az Office-tárolóktól eltérő követelményekkel rendelkező különálló BCDR-kezelést igényel, ossza fel a profiltárolókat és az Office-tárolókat külön tárfiókokra. Az Office-tárolók csak olyan gyorsítótárazott tartalmakat tárolnak, amelyeket katasztrófa esetén újraépíthet vagy újra feltölthet a forrásból. Mivel az Office-tárolók csak gyorsítótárazott adatokat tartalmaznak, előfordulhat, hogy nem kell megőriznie a biztonsági másolatokat, ami csökkentheti a költségeket. Ha különböző tárfiókokat használ, csak a profiltárolón állítson be biztonsági mentéseket. Vagy különböző beállításokat kell megadnia, például a megőrzési időtartamot, a felhasznált tárterületet, a gyakoriságot és az RTO-t vagy az RPO-t.

A felhőalapú gyorsítótár egy FSLogix-funkció, amely lehetővé teszi több profiltároló hely megadását és a profiladatok aszinkron replikálását anélkül, hogy az alapul szolgáló tárolóreplikációs mechanizmusokra támaszkodik. Ha az első tárolási hely meghibásodik vagy nem érhető el, a felhőbeli gyorsítótár automatikusan átjut a másodlagos régióba, amely rugalmassági réteget ad hozzá. A felhőalapú gyorsítótár használatával replikálhatja a profil- és az Office-tárolóadatokat az elsődleges és a másodlagos régiókban található különböző tárfiókok között.

A felhőalapú gyorsítótárat kétszer kell beállítania a munkamenet-gazdagép virtuálisgép-beállításjegyzékében. Állítsa be egyszer a profiltárolóhoz , egyszer pedig az Office-tárolóhoz. Kikapcsolhatja a felhőalapú gyorsítótárat az Office-tárolóhoz, de feladatátvétel és feladat-visszavétel esetén az adatok az elsődleges és a másodlagos DR régió között hibásan lesznek elosztva. Ezt a forgatókönyvet alaposan tesztelje, mielőtt éles környezetben használja.

A felhőalapú gyorsítótár kompatibilis a profil felosztási és csoportonkénti beállításaival. A csoportspecifikus beállítások gondos tervezést és kialakítást igényelnek az Active Directory csoportok és tagság megtervezéséhez és kialakításához. Győződjön meg arról, hogy minden felhasználó pontosan egy csoporthoz van rendelve, és hogy a csoport a gazdakészletekhez való hozzáférés biztosítására van használva.

A másodlagos DR régióban fordítsa vissza a CCDLocations szolgáltatói sorrendjét, hogy a helyi (másodlagos) tárfiók legyen az első. A felhőalapú gyorsítótár az első elérhető szolgáltatónak ír aktív írási célként, és aszinkron módon replikálja a következő bejegyzésekre. Amikor minden régióban először felsorolja a helyi tárfiókot, győződjön meg arról, hogy az írások a helyi tárolóba kerülnek a normál műveletek során, és hogy a replikáció régiókon keresztül áramlik. További információ: Profiltárolók beállítása felhőbeli gyorsítótárral.

Jótanács

Ez a cikk egy adott forgatókönyvre összpontosít. További forgatókönyvek: Az FSLogix magas rendelkezésre állási beállításai és az FSLogix BCDR-beállításai.

Példa felhőgyorsítótár-konfigurációra

Az alábbi példa egy felhőalapú gyorsítótár konfigurációját és a kapcsolódó beállításkulcsokat mutatja be. Cserélje le a helyőrző tárfiókok nevét a környezetében lévő neveknek megfelelőre.

Placeholder	Leírás
primarystgprofiles	Profiltároló konténerhez tartozó tárfiók az elsődleges régióban
primarystgodfc	Office-konténerek tárolófiókja az elsődleges régióban
secondarystgprofiles	Profil tárfiók a másodlagos régióban lévő tárolókhoz
secondarystgodfc	Tárfiók az Office-konténerekhez a másodlagos régióban

Elsődleges régió konfigurálása

Az elsődleges régióban a következő beállítások érvényesek:

• Profiltároló tárolófiók egységes erőforrás-azonosító (URI) = \\primarystgprofiles\profiles

  • Beállításkulcs elérési útja = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles

  • CCDLocations érték = type=smb,connectionString=\\primarystgprofiles\profiles;type=smb,connectionString=\\secondarystgprofiles\profiles

  Megjegyzés:

  Ha letölti az FSLogix-sablonokat, ugyanazokat a konfigurációkat az Active Directory csoportházirend-kezelési konzolján (GPMC) keresztül érheti el. Az FSLogix csoportházirend-objektumának (GPO) beállításáról további információt az FSLogix csoportházirend-sablonfájljainak használata című témakörben talál.

  

• Office-tároló tárfiók URI = \\primarystgodfc\odfc

  • Beállításkulcs elérési útja = HKEY_LOCAL_MACHINE > SOFTWARE > Policy > FSLogix > ODFC

  • CCDLocations érték = type=smb,connectionString=\\primarystgodfc\odfc;type=smb,connectionString=\\secondarystgodfc\odfc

    

Megjegyzés:

Az előző képernyőképek csak az FSLogix és a felhőbeli gyorsítótár ajánlott beállításkulcsainak egy részét jelenítik meg. További információ: FSLogix-konfigurációs példák.

Másodlagos régió konfigurálása

A következő beállítások érvényesek a másodlagos régióban:

• A CCDLocations szolgáltatói rendelése vissza lesz fordítva, hogy a helyi (másodlagos) tárfiók legyen az első.

• Profiltároló tárfiók URI = \\secondarystgprofiles\profiles

  • Beállításkulcs elérési útja = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles

  • CCDLocations érték = type=smb,connectionString=\\secondarystgprofiles\profiles;type=smb,connectionString=\\primarystgprofiles\profiles

• Office-tároló tárfiók URI = \\secondarystgodfc\odfc

  • Beállításkulcs elérési útja = HKEY_LOCAL_MACHINE > SOFTWARE > Policy > FSLogix > ODFC

  • CCDLocations érték = type=smb,connectionString=\\secondarystgodfc\odfc;type=smb,connectionString=\\primarystgodfc\odfc

Felhőbeli gyorsítótár replikációja

A felhőalapú gyorsítótár konfigurációs és replikációs mechanizmusai minimális adatvesztéssel replikálják a profiladatokat a különböző régiók között. Mivel csak egy folyamat tudja megnyitni ugyanazt a felhasználói profilfájlt ReadWrite módban, kerülje az egyidejű hozzáférést. A felhasználóknak nem szabad egyszerre megnyitniuk a kapcsolatot mindkét gazdagépkészlethez.

Ez az ábra egy felhőalapú gyorsítótár-replikációs forgatókönyvet mutat be két régióban, és egy sikeres első munkamenetet egy sikertelen második munkamenettel szemben mutat be. A bal szélen egy Azure Virtual Desktop-felhasználó elindítja az első munkamenetet, és csatlakozik egy Azure Virtual Desktop-gazdagépkészlethez az elsődleges régióban. Az elsődleges régió mezőben a munkamenet-gazdagép csatlakoztat egy profillemezt, és olvasási-írási zárolást szerez be. Egy pontozott nyíl, amelyet a felhő gyorsítótár replikájával jelöltek, az elsődleges régió profillemezéről a másodlagos régió profillemezére mutat. Középen a felhőbeli gyorsítótár replikaútvonala az elsődleges oldalról a másodlagos oldalra terjed ki, szaggatott és irányított összekötőkkel, amelyek a régiók közötti aszinkron replikációs viselkedést jelölnek. Egy második munkamenetre címkézett nyíl az Azure Virtual Desktop-felhasználótól a másodlagos régióig a dr. helypontokhoz. A jobb oldalon a másodlagos (DR) régióban található tükrözött gazdagépkészlet doboz tartalmaz egy másik munkamenet-gazdagépet és egy második profillemezt. Megjelenik a 33-ERROR_LOCK_VIOLATION (0x21) hibakód. A nyíl címkével ellátott replika nem hozható létre a profillemezről az elsődleges régió profillemezére.

Töltse le az architektúra Visio-fájlját.

Adatfolyam

1. Egy Azure Virtual Desktop-felhasználó elindítja az Azure Virtual Desktop-ügyfelet, és megnyitja az elsődleges régió gazdagépkészletéhez rendelt közzétett asztali vagy RemoteApp-alkalmazást.

2. Az FSLogix lekéri a felhasználói profilt és az Office-tárolókat, majd csatlakoztatja az alapul szolgáló VHD-t vagy VHDX-et az elsődleges régióban található tárfiókból.

3. A felhőalapú gyorsítótár egyidejűleg inicializálja a replikációt az elsődleges régióban lévő fájlok és a másodlagos régióban lévő fájlok között. A folyamat során az elsődleges régióban lévő felhőbeli gyorsítótár kizárólagos írás-olvasási zárolást alkalmaz ezeken a fájlokon.

4. Ugyanaz az Azure Virtual Desktop-felhasználó egy másik közzétett alkalmazást szeretne elindítani, amely a másodlagos régió gazdagépkészletéhez van hozzárendelve.

5. A másodlagos régióban található Azure Virtual Desktop munkamenetgazda FSLogix-összetevője megpróbálja csatlakoztatni a felhasználói profil VHD- vagy VHDX-fájljait a helyi tárfiókból. A csatlakoztatás sikertelen, mert az Azure Virtual Desktop munkamenetgazda felhőbeli gyorsítótár-összetevője az elsődleges régióban zárolja ezeket a fájlokat.

6. Az alapértelmezett FSLogix- és felhőgyorsítótár-konfigurációban a felhasználó nem tud bejelentkezni, az FSLogix rögzíti a hibát ERROR_LOCK_VIOLATION 33 (0x21) a diagnosztikai naplókban.

   

Identitás

A felhasználói identitás kritikus fontosságú az Azure Virtual Desktop esetében. Ahhoz, hogy a munkamenet-gazdagépekről teljes távoli virtuális asztalokat és távoli alkalmazásokat lehessen elérni, a felhasználóknak hitelesíteni kell magukat. A Microsoft Entra ID ezt a központosított felhőalapú identitásszolgáltatást biztosítja. Az Azure Virtual Desktop a Microsoft Entra-azonosítót használja a felhasználók hitelesítéséhez. A munkamenet-gazdagépek ugyanahhoz a Microsoft Entra-környezethez vagy egy Active Directory-tartományhoz csatlakozhatnak az AD DS vagy a Domain Services használatával. Ez a rugalmasság számos konfigurációs lehetőséget biztosít.

A Microsoft Entra ID rugalmassága

A Microsoft Entra ID egy globális többrégiós és rugalmas szolgáltatás, magas rendelkezésre állású SLA-val. Ebben a környezetben nincs szükség más műveletre egy Azure Virtual Desktop BCDR-csomag részeként.

Az AD DS magas rendelkezésre állási követelményei

Ahhoz, hogy az AD DS rugalmas és magas rendelkezésre állású legyen, akkor is, ha régiószintű katasztrófa történik, helyezzen üzembe legalább két tartományvezérlőt az elsődleges Azure-régióban. Ha lehetséges, helyezze ezeket a tartományvezérlőket különböző rendelkezésre állási zónákba, és biztosítsa a megfelelő replikációt a másodlagos régióban és végül a helyszínen található infrastruktúrában. Hozzon létre legalább egy tartományvezérlőt a másodlagos régióban, amely globális katalógust és DNS-szerepköröket tartalmaz. További információ: AD DS üzembe helyezése Azure-beli virtuális hálózaton.

Microsoft Entra Connect rugalmassági konfigurációja

Ha a Microsoft Entra ID-t az AD DS mellett használja, majd a Microsoft Entra Connect segítségével szinkronizálja a felhasználói identitás adatait az AD DS és a Microsoft Entra ID között, fontolja meg a szolgáltatás rugalmasságát és helyreállítását egy állandó katasztrófa elleni védelem érdekében.

Telepítse a szolgáltatás második példányát a másodlagos régióban, és állítsa be tesztelési módot a magas rendelkezésre állás és katasztrófa utáni helyreállítás érdekében.

Ha helyreállításra van szükség, a rendszergazdáknak elő kell mozdítaniuk a másodlagos példányt, miután eltávolították az előkészítési módból. Az aktív kiszolgálót egy olyan fiókkal kell váltaniuk, amely legalább hibrid identitás-rendszergazdai szerepkörrel rendelkezik.

A Domain Services szempontjai

Bizonyos esetekben a Tartományi szolgáltatásokat az AD DS alternatívaként használhatja. A Domain Services magas rendelkezésre állású SLA-t biztosít.

Ha a földrajzi katasztrófa utáni helyreállítás a forgatókönyvének hatókörébe tartozik, helyezzen üzembe egy másik replikát a másodlagos Azure-régióban egy replikakészleten keresztül. Ezzel a funkcióval növelheti a magas rendelkezésre állást az elsődleges régióban.

Átállás és visszaállás

Fontolja meg a következő hosztkészlet-forgatókönyveket.

Személyes gazdagép csoport szcenárió

Megjegyzés:

Ez a szakasz csak az aktív-passzív modellt ismerteti. Az aktív-aktív modell nem igényel feladatátvételt vagy rendszergazdai beavatkozást.

A személyes gazdagépkészlet feladatátvétele és visszaállítása eltérően működik, mivel nem használ felhő alapú gyorsítótárat vagy külső tárolót a profil- vagy Office-tárolókhoz. Az FSLogix használatával továbbra is tárolhat adatokat egy tárolóban a munkamenet-gazdagépről. A DR régióban nincs másodlagos hosztkészlet, ezért nem kell további munkaterületeket vagy Azure Virtual Desktop-erőforrásokat létrehoznia a replikációhoz vagy igazításhoz. A Site Recovery használatával replikálhatja a munkamenetgazda virtuális gépeket.

A Site Recovery több különböző forgatókönyvben is használható. Az Azure Virtual Desktop esetében használja az Azure–Azure DR architektúrát a Site Recoveryben.

A Site Recovery működési szempontjai

A rendszergazdáknak manuálisan kell elindítaniuk a Site Recovery feladatátvételét az Azure Portal, az API vagy a PowerShell használatával. A Site Recovery teljes konfigurációját és műveleteit a PowerShell használatával szkriptelheti és automatizálhatja. A Site Recovery SLA deklarál egy RTO-t, és a Site Recovery általában perceken belül meghibásodik a virtuális gépeken. A Site Recovery és a Backup együttes használatát is lehetővé teszi. További információ: A Site Recovery támogatása biztonsági mentéssel. A Site Recoveryt a virtuális gép szintjén kell beállítania, mert nincs közvetlen integráció az Azure Virtual Desktopban. Az átállást és visszaállást is az egyes virtuális gépek szintjén kell kezdeményeznie.

Figyelmeztetés

Ne használja a Site Recovery teszt feladatátvételi funkcióját az Azure Virtual Desktop-munkamenetgazda virtuális gépekhez. A feladatátvételi teszt létrehoz egy duplikált virtuális gépet, amely regisztrál az Azure Virtual Desktop vezérlősíkjával, és ütközik az eredeti munkamenet-gazdagéppel. Ehelyett ellenőrizze a DR felkészültségét úgy, hogy rendszeres ütemezés szerint elindítja a másodlagos munkamenet-gazdagépeket, ellenőrzi, hogy minden virtuális gép regisztrál-e a vezérlősíkon, és futtassa a dokumentált feladatátvételi és feladat-visszavételi eljárásokat egy tesztfelhasználói csoporttal.

A Site Recovery nem tart fenn virtuálisgép-bővítményeket a replikáció során. Ha egyedi kiterjesztéseket használ az Azure Virtual Desktop-munkamenetgazda virtuális gépeihez, a kiterjesztéseket a feladatátvétel vagy a feladat-visszavétel után kell beállítania. Az Azure Virtual Desktop beépített bővítményei joindomainMicrosoft.PowerShell.DSC csak munkamenetgazda virtuális gép első létrehozásakor érvényesek. Az első átváltás után nyugodtan figyelmen kívül hagyhatja őket. Tekintse át az Azure-beli virtuális gépek DR-jének támogatási mátrixát az Azure-régiók között. Ellenőrizze a Site Recovery Azure–Azure DR forgatókönyv követelményeit, korlátozásait és kompatibilitási mátrixát, különösen a támogatott operációsrendszer-verziókat.

Ha egy virtuális gépet egy másik régióba ad át, a virtuális gép nem védett állapotban indul el a cél DR régióban. A helyreállítás lehetséges, de újra kell védenie a másodlagos régióban lévő virtuális gépeket, és el kell indítania a replikációt az elsődleges régióba. Futtassa a feladatátvételi és feladat-visszavételi eljárások rendszeres tesztelését. Dokumentálja a lépések és helyreállítási műveletek listáját az adott Azure Virtual Desktop-környezet alapján.

Közös gazdagép-csoport forgatókönyve

Akkor használjon aktív-aktív DR-modellt, ha rendszergazdai beavatkozás nélkül kell helyreállítania a szolgáltatást egy leállás során. Csak aktív-passzív architektúrához használjon feladatátvételi eljárásokat. Egy aktív-passzív modellben a másodlagos DR régió tétlen marad, és minimális kész erőforrásokat tart fenn. Tartsa a másodlagos konfigurációt az elsődleges konfigurációhoz igazítva. A feladatátvétel során az összes felhasználót hozzárendelje az asztali és távoli alkalmazásalkalmazás-csoportokhoz a másodlagos DR gazdagépkészletben.

Részleges feladatátvétellel implementálhat egy aktív-aktív modellt. Ha a gazdagépkészlet csak asztali környezeteket és alkalmazáscsoportokat tesz közzé, ossza fel a felhasználókat átfedésektől mentes Active Directory-csoportokra, és rendelje hozzá az egyes csoportokat az elsődleges vagy a másodlagos DR (katasztrófa utáni helyreállítás) gazdagépkészlet alkalmazáscsoportjaihoz. Az egyes felhasználókat egyszerre egy gazdagépkészletben tarthatja. Ha több alkalmazáscsoportot és alkalmazást tesz közzé, a csoporttagságok átfedésben lehetnek. Ez az átfedés megnehezíti az aktív-aktív modell működését. Amikor egy felhasználó elindít egy távoli alkalmazást az elsődleges gazdagépkészletben, az FSLogix egy munkamenetgazda VM-re tölti be a felhasználói profilt. Ha ugyanazt az azonos műveletet próbálja végrehajtani a másodlagos fogadó gazdagépkészleten, ütközést okozhat az alapul szolgáló profillemezen.

Figyelmeztetés

Alapértelmezés szerint az FSLogix beállításjegyzék-beállításai megakadályozzák, hogy egyszerre több munkamenetből is hozzáférjenek ugyanahhoz a felhasználói profilhoz. Ebben a BCDR-forgatókönyvben tartsa meg ezt a viselkedést, és állítsa be a ProfileType jegyzék kulcsot a következőre: 0.

Feltételek és konfigurációs feltételezések

Az elsődleges régióban és a másodlagos dr. régióban lévő gazdagépkészletek összehangolt konfigurációkat használnak, beleértve a felhőalapú gyorsítótárat is. Mindkét gazdagépkészletben a felhasználók számára elérhetők a DAG1, az APPG2 és az APPG3. Az elsődleges gazdagépkészletben az Active Directory-csoportok GRP1, GRP2 és GRP3 felhasználókat rendelnek a DAG1, APPG2 és APPG3 csoportokhoz. A csoporttagságok átfedésben lehetnek, de ez a minta elfogadható marad, mivel ez a forgatókönyv egy aktív-passzív modellt használ teljes feladatátvétellel.

Az alábbi lépések egy tervezett vagy nem tervezett DR-esemény feladatátvételi folyamatát írják le:

1. Az elsődleges gazdagépkészletben távolítsa el a GRP1, GRP2 és GRP3 csoport felhasználói hozzárendeléseit a DAG1, APPG2 és APPG3 alkalmazáscsoportokhoz.

2. A csatlakoztatott felhasználók erőszakosan leválnak az elsődleges gazdagépkészletről.

3. A másodlagos gazdagépkészletben, ahol ugyanazok az alkalmazáscsoportok vannak beállítva, hozzáférést kell adnia a felhasználóknak a DAG1, APPG2 és APPG3 csoporthoz a GRP1, GRP2 és GRP3 csoportok használatával.

4. Tekintse át a másodlagos régió gazdagépkészletének kapacitását, majd módosítsa azt. Automatikus skálázási terv használatával automatikusan elindíthatja a munkamenet-gazdagépeket, vagy manuálisan is elindíthatja a szükséges erőforrásokat.

A visszaállítási lépések és a folyamat hasonlóak, és többször is elvégezheti a folyamatot. A felhőalapú gyorsítótár és a tárfiók konfigurációja biztosítja a profil- és az Office-tárolóadatok replikálását. A failback előtt ellenőrizze, hogy visszaállították a gazdagépkészlet konfigurációját és a számítási erőforrásokat. Ha az elsődleges régió tárolási adatvesztéssel rendelkezik, a felhőgyorsítótár a profil- és az Office-tárolóadatokat replikálja a másodlagos régióban lévő tárolóból.

Teszt feladatátvételi tervet is megvalósíthat néhány konfigurációmódosítással, anélkül hogy hatással lenne az éles környezetre.

1. Hozzon létre néhány tesztfelhasználói fiókot az Active Directoryban.

2. Hozzon létre egy GRP-TEST nevű új Active Directory-csoportot, és rendeljen hozzá felhasználókat.

3. Rendeljen hozzáférést a DAG1-hez, APPG2-höz és APPG3-hoz a GRP-TEST csoporttal.

4. Utasíthatja a GRP-TEST csoport felhasználóit az alkalmazások tesztelésére.

5. Tesztelje a feladatátvételi eljárást a GRP-TEST csoporttal. Távolítsa el a hozzáférést az elsődleges gazdagépkészletből, és adjon hozzáférést a másodlagos DR-készlethez.

Kövesse az alábbi javaslatokat:

• Automatizálja a feladatátvételi folyamatot a PowerShell, az Azure CLI vagy más elérhető API vagy eszköz használatával.

• Rendszeresen tesztelje a teljes feladatátvételi és feladat-visszavételi eljárást.

• Futtasson rendszeres konfiguráció-összehangolási ellenőrzést, hogy a gazdacsoportok szinkronban legyenek az elsődleges és a másodlagos katasztrófamentési régiókban.

Backup

Ez az útmutató feltételezi, hogy elkülöníti a profiltárolókat és az Office-tárolókat. Az FSLogix támogatja ezt a konfigurációt és a különálló tárfiókokat. Miután a profil- és Office-tárolókat külön tárfiókokba helyezte, különböző biztonsági mentési házirendeket használhat.

Office-tárolók esetén, ha a tartalom csak gyorsítótárazott adatok, amelyeket újraépíthet egy online adattárból, például a Microsoft 365-ből, akkor nem kell biztonsági másolatot készítenie az adatokról. Ha biztonsági másolatot szeretne készíteni az Office-tárolók adatairól, használhat kevésbé költséges tárhelyet, vagy másik biztonsági mentési gyakoriságot és megőrzési időtartamot választhat. Személyes gazdagépkészlet-típus esetén futtassa a biztonsági mentést a munkamenetgazda virtuális gép szintjén. Ez a módszer csak akkor érvényes, ha az adatokat helyileg tárolja. Ha OneDrive-ot és ismert mappaátirányítást használ, előfordulhat, hogy már nem kell adatokat tárolnia a tárolóban.

Megjegyzés:

Ez a cikk és forgatókönyv nem tartalmazza a OneDrive biztonsági mentését.

Tárolási és régiós szempontok

Ha nem rendelkezik más követelményekkel, készítsen biztonsági másolatot az elsődleges régió tárolási címeinek tipikus biztonsági mentési igényeiről. A legtöbb esetben nem kell biztonsági másolatot készítenie a dr. környezetről. Azure Files-megosztás esetén használja a Backupot. A tároló rugalmassági típusához használja a ZRS-t, ha nincs szükség régión kívüli vagy más helyszínen lévő biztonsági mentési tárra. Ha szüksége van ezekre a biztonsági másolatokra, használja a GRS-t.

Az Azure NetApp Files saját beépített biztonsági mentési megoldást kínál. Ellenőrizze a régió funkcióinak rendelkezésre állását, valamint a követelményeket és a korlátozásokat. Készítsen biztonsági másolatot az MSIX-csomagokat tároló különálló tárfiókokról, ha nem tudja egyszerűen újraépíteni az alkalmazáscsomag-adattárakat.

Közreműködők

A Microsoft fenntartja ezt a cikket. A következő közreműködők írták ezt a cikket.

Fő szerző:

• Ben Martin Baur | Műszaki tervező – Microsoft Innovation Hub

Egyéb közreműködők:

• Jason Martinez | Műszaki író
• Igor Pagliai | Az Azure-hoz készült FastTrack (FTA) főmérnöke
• Nelson Del Villar | Felhőmegoldás-tervező – Azure Core-infrastruktúra

Következő lépések

• Azure Virtual Desktop katasztrófaelhárítási terv
• BCDR az Azure Virtual Desktophoz
• A felhőalapú gyorsítótár áttekintése
• FSLogix-konfigurációs példák
• Megbízható Azure-alkalmazások tervezése

Kapcsolódó erőforrások

• A helyszínen elérhető és az AD DS által védett Azure-fájlok
• Vállalati fájlmegosztások a DR-vel