Többrégiós üzletmenet-folytonosság és vészhelyreállítás (BCDR) az Azure Virtual Desktophoz

Az Azure Virtual Desktop egy átfogó asztali és alkalmazásvirtualizálási szolgáltatás, amely a Microsoft Azure-on fut. A Virtual Desktop lehetővé teszi a biztonságos távoli asztali élményt, amely segít a szervezeteknek az üzleti rugalmasság megerősítésében. Egyszerűsített felügyeletet, Több munkamenetes Windows 10 és 11 Enterprise rendszert, valamint optimalizálást biztosít Nagyvállalati Microsoft 365-alkalmazások számára. A Virtual Desktop segítségével percek alatt üzembe helyezheti és skálázhatja Windows-asztalait és alkalmazásait az Azure-ban, és integrált biztonsági és megfelelőségi funkciókat biztosít az alkalmazások és az adatok biztonságának megőrzéséhez.

Mivel továbbra is engedélyezi a távoli munkát a szervezet számára a Virtual Desktop használatával, fontos megismerni a vészhelyreállítási képességeit és ajánlott eljárásait. Ezek a gyakorlatok erősítik a régiók megbízhatóságát az adatok biztonságának és az alkalmazottak hatékonyságának megőrzéséhez. Ez a cikk az üzletmenet folytonosságával és a vészhelyreállítással (BCDR) kapcsolatos előfeltételekkel, üzembe helyezési lépésekkel és ajánlott eljárásokkal kapcsolatos szempontokat ismerteti. Megismerheti a lehetőségeket, stratégiákat és az architektúra útmutatását. A dokumentum tartalma lehetővé teszi egy sikeres BCDR-terv előkészítését, és segíthet a vállalat rugalmasságának növelésében a tervezett és nem tervezett állásidős események során.

A katasztrófáknak és a kimaradásoknak számos típusa van, és mindegyiknek más hatása lehet. A rugalmasságot és a helyreállítást részletesen tárgyaljuk mind a helyi, mind a régiószintű események esetében, beleértve a szolgáltatás helyreállítását egy másik távoli Azure-régióban. Ezt a típusú helyreállítást geo-vészhelyreállításnak nevezzük. A rugalmasság és a rendelkezésre állás érdekében kritikus fontosságú a Virtual Desktop-architektúra kiépítése. A hibaesemények hatásának csökkentése érdekében maximális helyi rugalmasságot kell biztosítania. Ez a rugalmasság a helyreállítási eljárások végrehajtásához szükséges követelményeket is csökkenti. Ez a cikk a magas rendelkezésre állásról és az ajánlott eljárásokról is tartalmaz információkat.

Virtuális asztal vezérlősíkja

A Virtual Desktop BCDR-t kínál a vezérlősíkhoz, hogy megőrizze az ügyfelek metaadatait a kimaradások során. Ha egy régióban kimaradás történik, a szolgáltatásinfrastruktúra-összetevők feladatátvételt végeznek a másodlagos helyre, és a szokásos módon működnek tovább. Továbbra is hozzáférhet a szolgáltatással kapcsolatos metaadatokhoz, és a felhasználók továbbra is csatlakozhatnak az elérhető gazdagépekhez. A végfelhasználói kapcsolatok online állapotban maradnak, ha a bérlői környezet vagy a gazdagépek továbbra is elérhetők maradnak. Az Azure Virtual Desktop adathelyei eltérnek a gazdagépkészlet munkamenetgazda virtuális gépek (VM-ek) üzembe helyezésének helyétől. A Virtual Desktop metaadatai az egyik támogatott régióban találhatók, majd virtuális gépeket helyezhetnek üzembe egy másik helyen. Nincs szükség más műveletre.

Célok és hatókör

Az útmutató célja:

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

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

A javasolt 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. Bár ez még mindig jó gyakorlat, a Virtual Desktop és a BCDR létrehozásához használt technológia nem követeli meg az Azure-régiók párosítást. Az elsődleges és a másodlagos hely bármilyen Azure-régió kombináció lehet, ha a hálózati késés lehetővé teszi.

Egyetlen rendelkezésre állási zóna meghibásodásának hatásának csökkentése érdekében használja a rugalmasságot a magas rendelkezésre állás javítása érdekében:

• A számítási rétegben terjessze el a Virtual Desktop-munkamenet gazdagépeit a különböző rendelkezésre állási zónák között.
• A tárolási rétegben használja a zóna rugalmasságát, amikor csak lehetséges.
• 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ány vezérlőket és más külső erőforrásokat, amelyeket a Virtual Desktop felhasználói több zónában érhetnek el.

A használt rendelkezésre állási zónák számától függően értékelje ki a munkamenet-gazdagépek túlkiosztását az egy zóna elvesztésének kompenzálása érdekében. A felhasználói élményt és a teljesítményt például még az elérhető (n-1) zónák esetén is biztosíthatja.

Egyes régiókban a típusok, a replikációs lehetőségek, a szolgáltatásképességek és a rendelkezésre állási korlátozások lehetséges kombinációja miatt az FSLogix Cloud Cache összetevőjét használja a rendszer az adott tárolási replikációs mechanizmusok helyett.

A OneDrive-ról ebben a cikkben nem foglalkozunk. A redundanciáról és a magas rendelkezésre állásról a SharePoint és a OneDrive adatrugalmasságáról a Microsoft 365-ben olvashat bővebben.

A cikk további részében megismerkedhet a két különböző virtuális asztali gazdagépkészlet-típus megoldásával. Vannak megfigyelések is, amelyekkel összehasonlíthatja ezt az architektúrát más megoldásokkal:

• Személyes: Az ilyen típusú gazdagépkészletben a felhasználóhoz állandó munkamenet-gazdagép tartozik, amely soha nem változik. Mivel személyes, ez a virtuális gép tárolhatja a felhasználói adatokat. A feltételezés az, hogy replikációs és biztonsági mentési technikákat használ az állapot megőrzésére és védelmére.
• Készletezett: A felhasználók ideiglenesen hozzárendelik a készletből az elérhető munkamenetgazda virtuális gépek egyikét, akár közvetlenül egy asztali alkalmazáscsoporton keresztül, akár távoli alkalmazások használatával. A virtuális gépek állapot nélküliek, a felhasználói adatok és profilok pedig külső tárolóban vagy OneDrive-on vannak tárolva.

A költségekkel kapcsolatos következményeket tárgyaljuk, de az elsődleges cél a hatékony geo-vészhelyreállítás üzembe helyezése minimális adatvesztéssel. További BCDR-részletekért tekintse meg a következő erőforrásokat:

• A Virtual Desktop BCDR-szempontjai
• Virtual Desktop vészhelyreállítás

Előfeltételek

Helyezze üzembe az alapvető infrastruktúrát, és győződjön meg arról, hogy elérhető az elsődleges és a másodlagos Azure-régióban. A hálózati topológiával kapcsolatos útmutatásért használja az Azure felhőadaptálási keretrendszer hálózati topológiáját és kapcsolati modelljeit:

• Hagyományos Azure hálózati topológia
• Virtual WAN hálózati topológia (a Microsoft felügyeli)

Mindkét modellben helyezze üzembe az elsődleges Virtual Desktop-gazdagépkészletet és a másodlagos vészhelyreállítási környezetet különböző küllős virtuális hálózatokon belül, és csatlakoztassa őket az azonos régióban lévő összes központhoz. Helyezzen egy központot az elsődleges helyre, egyet a másodlagos helyre, majd létesítsen kapcsolatot a kettő között.

A központ végül hibrid kapcsolatot biztosít a helyszíni erőforrásokhoz, tűzfalszolgáltatásokhoz, identitáserőforrásokhoz, például Active Directory-tartomány vezérlőkhöz és olyan felügyeleti erőforrásokhoz, mint a Log Analytics.

A másodlagos helyre történő feladatátvételkor érdemes megfontolni az üzletági alkalmazásokat és a függő erőforrások rendelkezésre állását.

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, a Microsoft azt javasolja, hogy több különböző konfigurációjú gazdagépkészletet használjon. A kritikus fontosságú alkalmazásokkal rendelkező felhasználók például teljes mértékben redundáns gazdagépkészletet rendelhetnek hozzá georedundáns vészhelyreállítási képességekkel. A fejlesztési és tesztelési felhasználók azonban használhatnak egy külön gazdagépkészletet, amely egyáltalán nem rendelkezik vészhelyreállítással.

Minden egyes virtuális asztali gazdagépkészlet esetében a BCDR-stratégiát egy aktív-aktív vagy aktív-passzív modellre alapozhatja. Ebben az összefüggésben feltételezzük, hogy egy adott gazdagépkészlet ugyanazt a felhasználókészletet szolgálja ki egy földrajzi helyen.

• Aktív-aktív

  • Az elsődleges régió minden gazdagépkészletéhez üzembe kell helyeznie egy második gazdagépkészletet a másodlagos régióban.

  • Ez a konfiguráció szinte nulla RTO-t biztosít, és az RPO többletköltséggel jár.

  • Nincs szükség rendszergazdai beavatkozásra vagy feladatátvételre. A normál műveletek során a másodlagos gazdagépkészlet virtuális asztali erőforrásokat biztosít a felhasználónak.

  • Minden gazdagépkészlet saját tárfiókkal rendelkezik az állandó felhasználói profilokhoz.

  • A késést a felhasználó fizikai helye és a rendelkezésre álló kapcsolat alapján kell kiértékelnie. Egyes Azure-régiók, például Nyugat-Európa és Észak-Európa esetében a különbség elhanyagolható lehet az elsődleges vagy másodlagos régiók elérésekor. Ezt a forgatókönyvet az Azure Virtual Desktop Élménybecslő eszközével ellenőrizheti.

  • A felhasználók különböző alkalmazáscsoportokhoz, például asztali és távoli alkalmazásokhoz vannak rendelve az elsődleges és a másodlagos gazdagépkészletekben. Ebben az esetben ismétlődő bejegyzéseket fognak látni a Virtual Desktop-ügyfélcsatornában. A félreértések elkerülése érdekében használjon különálló Virtual Desktop-munkaterületeket egyértelmű névvel és címkékkel, amelyek az egyes erőforrások rendeltetését tükrözik. Tájékoztassa a felhasználókat az erőforrások használatáról.

    

  • Ha tárolóra van szüksége az FSLogix-profil és az Office-tárolók kezeléséhez, a Cloud Cache használatával szinte nulla RPO-t biztosít.

    • A profilütközések elkerülése érdekében ne engedélyezze a felhasználók számára, hogy egyszerre férhessenek hozzá mindkét gazdagépkészlethez.
    • Ennek a forgatókönyvnek az aktív-aktív jellege miatt a felhasználókat arra kell megtanítani, hogyan használhatják ezeket az erőforrásokat a megfelelő módon.

• Aktív-passzív

  • Az aktív-aktívhoz hasonlóan az elsődleges régió minden gazdagépkészletéhez üzembe kell helyeznie egy második gazdagépkészletet a másodlagos régióban.
  • A másodlagos régióban aktív számítási erőforrások mennyisége az elérhető költségvetéstől függően csökken az elsődleges régióhoz képest. Az automatikus skálázással több számítási kapacitást biztosíthat, de több időt igényel, és az Azure-kapacitás nem garantált.
  • Ez a konfiguráció magasabb RTO-t biztosít az aktív-aktív megközelítéshez képest, de kevésbé költséges.
  • Azure-beli kimaradás esetén rendszergazdai beavatkozásra van szükség a feladatátvételi eljárás végrehajtásához. A másodlagos gazdagépkészlet általában nem biztosít hozzáférést a felhasználóknak a Virtual Desktop-erőforrásokhoz.
  • Minden gazdagépkészlet saját tárfiókokkal rendelkezik az állandó felhasználói profilokhoz.
  • Az optimális késéssel és teljesítménnyel rendelkező Virtual Desktop-szolgáltatásokat használó felhasználókra csak azure-beli kimaradás esetén lesz hatással. Ezt a forgatókönyvet az Azure Virtual Desktop Élménybecslő eszközével kell ellenőriznie. A másodlagos vészhelyreállítási környezet teljesítményének akkor is elfogadhatónak kell lennie, ha csökkent.
  • A felhasználók csak egy alkalmazáscsoporthoz vannak hozzárendelve, például az asztali és a távoli alkalmazásokhoz. A normál műveletek során ezek az alkalmazások az elsődleges gazdagépkészletben találhatók. A szolgáltatáskimaradás során és a feladatátvételt követően a rendszer a másodlagos gazdagépkészlet alkalmazáscsoportjaihoz rendeli a felhasználókat. A felhasználó Virtual Desktop-ügyfélcsatornájában nem jelennek meg ismétlődő bejegyzések, használhatják ugyanazt a munkaterületet, és minden transzparens számukra.
  • Ha tárolóra van szüksége az FSLogix-profil és az Office-tárolók kezeléséhez, a Cloud Cache használatával szinte nulla RPO-t biztosít.
    • A profilütközések elkerülése érdekében ne engedélyezze a felhasználók számára, hogy egyszerre férhessenek hozzá mindkét gazdagépkészlethez. Mivel ez a forgatókönyv aktív-passzív, a rendszergazdák az alkalmazáscsoport szintjén érvényesíthetik ezt a viselkedést. A felhasználó csak feladatátvételi eljárás után férhet hozzá a másodlagos gazdagépkészlet egyes alkalmazáscsoportaihoz. A hozzáférés vissza lesz vonva az elsődleges gazdagépkészlet alkalmazáscsoportjában, és a másodlagos gazdagépkészlet egy alkalmazáscsoporthoz van rendelve.
    • Feladatátvétel végrehajtása minden alkalmazáscsoport esetében, ellenkező esetben a különböző gazdagépkészletekben különböző alkalmazáscsoportokat használó felhasználók profilütközéseket okozhatnak, ha nem kezelik hatékonyan.
  • Lehetővé teszi, hogy a felhasználók egy adott részhalmaza szelektíven feladatátvételt biztosítson a másodlagos gazdagépkészletbe, és korlátozott aktív-aktív viselkedést biztosítson, és tesztelje a feladatátvételi képességet. Adott alkalmazáscsoportok feladatátvétele is lehetséges, de arra kell megtanítani a felhasználókat, hogy ne használják egyszerre a különböző gazdagépkészletekből származó erőforrásokat.

Adott körülmények között létrehozhat egyetlen gazdagépkészletet különböző régiókban található munkamenet-gazdagépek kombinációjával. Ennek a megoldásnak az az előnye, hogy ha egyetlen gazdagépkészlete van, akkor nincs szükség az asztali és távoli alkalmazások definícióinak és hozzárendeléseinek duplikálására. Sajnos ennek a megoldásnak számos hátránya van.

• Készletezett gazdagépkészletek esetén nem kényszeríthető a felhasználó egy munkamenet-gazdagépre ugyanabban a régióban.
• A távoli régióban lévő munkamenet-gazdagéphez való csatlakozáskor a felhasználók nagyobb késést és optimálisnál alacsonyabb teljesítményt tapasztalhatnak.
• 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 letilthatja a másodlagos régióban található munkamenet-gazdagépek hozzáférését. Ez a módszer azonban összetettebb, felügyeleti többletterhelést és az erőforrások nem hatékony használatát mutatja be.
• A munkamenet-gazdagépeket offline állapotban tarthatja fenn a másodlagos régiókban, de összetettebb és felügyeleti többletterhelést jelent.

Megfontolandó szempontok és javaslatok

Általános

Ha aktív-aktív vagy aktív-passzív konfigurációt szeretne üzembe helyezni több gazdagépkészlet és egy FSLogix felhőgyorsítótár-mechanizmus használatával, a modelltől függően létrehozhatja a gazdagépkészletet ugyanazon a munkaterületen belül, vagy egy másikat. Ehhez a megközelítéshez meg kell tartania az igazítást és a frissítéseket, így a gazdagépkészletek szinkronban és ugyanabban a konfigurációs szinten maradnak. A másodlagos vészhelyreállítási régió új gazdagépkészletén kívül a következőkre van szükség:

• Új különálló alkalmazáscsoportok és kapcsolódó alkalmazások létrehozása az új gazdagépkészlethez.
• Ha vissza szeretné vonni a felhasználói hozzárendeléseket az elsődleges gazdagépkészlethez, majd manuálisan hozzárendelné őket az új gazdagépkészlethez a feladatátvétel során.

Tekintse át az FSLogix üzletmenet-folytonossági és vészhelyreállítási lehetőségeit.

• A dokumentum nem foglalkozik profil-helyreállítással .
• A dokumentum tartalmazza a felhőalapú gyorsítótárat (aktív/passzív), de ugyanazt a gazdagépkészletet használja.
• A dokumentum fennmaradó része a felhőalapú gyorsítótárat (aktív/aktív) fedi le.

A Virtual Desktop-erőforrásokra bizonyos korlátozások vonatkoznak. További információ: Azure Virtual Desktop szolgáltatáskorlátok.

Diagnosztikához és monitorozáshoz használja ugyanazt a Log Analytics-munkaterületet az elsődleges és a másodlagos gazdagépkészlethez is.

Compute

• Az elsődleges és másodlagos vészhelyreállítási régiókban mindkét gazdagépkészlet üzembe helyezéséhez azure-beli rendelkezésre állási zónákat kell használnia, és el kell osztania a virtuálisgép-flottát az összes elérhető zónában. Ha a rendelkezésre állási zónák nem érhetők el a helyi régióban, használhat azure-beli rendelkezésre állási csoportot.

• A másodlagos vészhelyreállítási régióban a gazdagépkészlet üzembe helyezéséhez használt aranylemezképnek meg kell egyeznie az elsődleges szolgáltatással. A rendszerképeket az Azure Compute Galleryben kell tárolnia, és több képreplikát kell konfigurálnia mind az elsődleges, mind a másodlagos helyeken. Minden képreplika maximális számú virtuális gép párhuzamos üzembe helyezését képes fenntartani, és a kívánt üzembehelyezési kötegméret alapján többre is szükség lehet. További információ: Képek tárolása és megosztása egy Azure Compute Galleryben.

  

• Az Azure Compute Gallery nem globális erőforrás, ezért ajánlott legalább egy másodlagos katalógust létrehozni a másodlagos régióban. Miután létrehozott egy katalógust, egy virtuálisgép-rendszerképdefiníciót és egy virtuálisgép-rendszerkép-verziót az elsődleges régióban, ugyanezt a három objektumot a másodlagos régióban is létre kell hoznia. A virtuálisgép-rendszerkép verziója létrehozásakor lehetőség van az elsődleges régióban létrehozott virtuálisgép-rendszerkép verziójának másolására. Ennek eléréséhez a másodlagos régióban meg kell adnia a katalógust, az elsődleges régióban használt virtuálisgép-képdefiníciót és virtuálisgép-rendszerkép-verziót, az Azure pedig másolja a lemezké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 lehet végrehajtani az alábbiak szerint:

  Képdefiníció és képverzió létrehozása

  az sig image-version create

• A másodlagos vészhelyreállítási helyeken nem minden munkamenetgazda virtuális gépnek kell aktívnak lennie, és folyamatosan futnia kell. Kezdetben elegendő számú virtuális gépet kell létrehoznia, majd ezt követően használjon egy automatikus méretezési mechanizmust, például a skálázási terveket. Ezekkel a mechanizmusokkal a legtöbb számítási erőforrás offline vagy felszabadított állapotban tartható fenn a költségek csökkentése érdekében.

• Az automatizálással munkamenet-gazdagépeket is létrehozhat a másodlagos régióban, ha szükséges. Ez a módszer 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 nélkül, és nem engedélyezi a szelektív feladatátvételt adott felhasználói csoportok számára.

• Ha a munkamenet-gazdagépek offline vagy felszabadított állapotban vannak a másodlagos régióban, az nem garantálja, hogy a kapacitás rendelkezésre áll, ha elsődleges régiószintű katasztrófa történik. Akkor is érvényes, ha az új munkamenetek igény szerint vannak üzembe helyezve, valamint a Site Recovery használatával. A számítási kapacitás akkor garantálható, ha:
  • A munkamenet-gazdagépek aktív állapotban vannak a másodlagos régióban.
  • Az új Igény szerinti Azure-szolgáltatás kapacitásfoglalását használja.

• Mivel a Cloud Cache-t használja:
  • A munkamenet-gazdagép virtuális gép operációs rendszer által felügyelt lemezéhez a prémium szintet kell használnia.
  • Helyezze át a Cloud Cache-t az ideiglenes virtuálisgép-meghajtóra, és használja a helyi SSD-tárolót.

Tárolás

Ebben az útmutatóban legalább két különálló tárfiókot használ minden virtuális asztali gazdagépkészlethez. Az egyik az FSLogix-profil tárolója, a másik az Office-tároló adataihoz tartozik. Az MSIX-csomagokhoz még egy tárfiókra van szüksége. A következő szempontokat kell figyelembe venni:

• Tárolási alternatívaként használhatja az Azure Files-megosztást és az Azure NetApp Filesot .
• Az Azure Files-megosztás a zónareplikált tároló rugalmassági beállításával biztosíthatja a zóna rugalmasságát, ha az elérhető a régióban.
• A georedundáns tárolási funkció nem használható a következő helyzetekben:
  • Nem párosított régióra van szükség. A georedundáns tárolás régiópárjai rögzítettek, és nem módosíthatók.
  • A prémium szintet használja.
• Az RPO és az RTO magasabb az FSLogix Cloud Cache-mechanizmushoz képest.
• Éles környezetben nem könnyű tesztelni a feladatátvételt és a feladat-visszavételt.
• Az Azure NetApp Files további szempontokat igényel:
  • A zónaredundancia még nem érhető el. Ha a rugalmassági követelmény fontosabb a teljesítménynél, használja az Azure Files-megosztást.
  • Az Azure NetApp Files lehet zonális, vagyis az ügyfelek eldönthetik, hogy melyik (egyetlen) Azure rendelkezésre állási zónában legyenek lefoglalva.
  • A zónák közötti replikáció a kötet szintjén állítható be. A replikáció aszinkron (RPO>0), és manuális feladatátvételt (RTO>0) igényel. A funkció használata előtt ajánlott áttekinteni a jelen cikk követelményeit és szempontjait.
  • Mostantól zónaredundáns VPN- és ExpressRoute-átjárókkal is használhatja az Azure NetApp Filest, ha standard hálózatkezelési funkciót használ, amelyet a hálózatkezelési rugalmasság érdekében használhat. További információ: Támogatott hálózati topológiák.
  • Az Azure Virtual WAN már támogatott, de az Azure NetApp Files Standard hálózatkezelési funkcióját igényli. További információ: Támogatott hálózati topológiák.
• Az Azure NetApp Files régióközi replikációs mechanizmussal rendelkezik, a következő szempontokat kell figyelembe venni:
  • Nem minden régióban érhető el.
  • A régiópárok rögzítettek.
  • A feladatátvétel nem transzparens, és a feladat-visszavételhez újrakonfigurálásra van szükség.
• Határok
  • Az Azure Files-megosztások és az Azure NetApp Files-tárfiókok és -kötetek méretére, bemeneti/kimeneti műveleteire (IOPS), sávszélesség mb/s-jára vonatkozó korlátozások vonatkoznak. Szükség esetén több is használható ugyanahhoz a gazdagépkészlethez a Virtual Desktopban az FSLogix csoportonkénti beállításaival . Ehhez a konfigurációhoz azonban több tervezésre és konfigurálásra van szükség.

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ő geo-vészhelyreállítási lehetőségek érhetők el:

• Egy georedundáns tárolást engedélyező tárfiók az elsődleges régióban
  • A másodlagos régió ki van javítva. Ez a beállítás nem alkalmas helyi hozzáférésre, ha a tárfiók feladatátvétele történik.
• Két különálló tárfiók, egy az elsődleges régióban és egy a másodlagos régióban (ajánlott)
  • Használjon zónaredundáns tárolást legalább az elsődleges régióhoz.
  • Az egyes régiókban található gazdagépkészletek helyi tárterület-hozzáféréssel rendelkezik az alacsony késésű MSIX-csomagokhoz.
  • Másolja az MSIX-csomagokat kétszer mindkét helyre, és regisztrálja a csomagokat kétszer mindkét gazdagépkészletben. Felhasználók hozzárendelése az alkalmazáscsoportokhoz kétszer.

FSLogix

A Microsoft a következő FSLogix-konfigurációt és funkciókat javasolja:

• Ha a profiltároló tartalmának külön BCDR-kezeléssel kell rendelkeznie, és az Office-tárolóhoz képest eltérő követelményekkel kell rendelkeznie, fel kell osztania őket.

  • Az Office-tároló csak olyan gyorsítótárazott tartalommal rendelkezik, amely katasztrófa esetén újraépíthető vagy újra feltölthető a forrásból. Az Office Container használatával előfordulhat, hogy nem kell biztonsági másolatokat tartania, ami csökkentheti a költségeket.
  • Különböző tárfiókok használata esetén csak a profiltárolón engedélyezheti a 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/RPO-t.

• A Cloud Cache egy FSLogix-összetevő, amelyben több profiltárolóhelyet is megadhat, és aszinkron módon replikálhatja a profiladatokat anélkül, hogy bármilyen mögöttes tárolóreplikációs mechanizmusra támaszkodhat. Ha az első tárolási hely meghibásodik vagy nem érhető el, a Cloud Cache automatikusan feladatátvételt fog végrehajtani a másodlagos használathoz, és hatékonyan hozzáad egy rugalmassági réteget. A Cloud Cache használatával a profil- és Office-tárolókat is replikálhatja az elsődleges és a másodlagos régiókban található különböző tárfiókok között.

  

• A Cloud Cache-t kétszer kell engedélyeznie a munkamenet-gazdagép virtuálisgép-beállításjegyzékében, egyszer a Profiltárolóban, egyszer pedig az Office-tárolóban. Lehetséges, hogy nem engedélyezi a Cloud Cache-t az Office-tárolóhoz, de ha nem engedélyezi, az adateltérést okozhat az elsődleges és a másodlagos vészhelyreállítási régió között feladatátvétel és feladat-visszavétel esetén. Ezt a forgatókönyvet alaposan tesztelje, mielőtt éles környezetben használnák.

• A Cloud Cache kompatibilis a profilfelosztási és a csoportonkénti beállításokkal is. A csoportonkénti active directory-csoportok és tagság gondos tervezését és tervezését igényli. Győződjön meg arról, hogy minden felhasználó pontosan egy csoport része, és hogy a csoport a gazdagépkészletekhez való hozzáférés biztosítására szolgál.

• A másodlagos vészhelyreállítási régió gazdagépkészletének beállításjegyzékében megadott CCDLocations paramétert a rendszer az elsődleges régió beállításaihoz képest sorrendben visszaállítja. További információ : Oktatóanyag: A Cloud Cache konfigurálása profiltárolók vagy office-tárolók több szolgáltatóhoz való átirányításához.

Az alábbi példa egy Cloud Cache-konfigurációt és a kapcsolódó beállításkulcsokat mutatja be:

Elsődleges régió = Észak-Európa

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

  • Beállításkulcs elérési útja = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix-profilok >
  • CCDLocations value = type=smb,connectionString=\northeustg1\profiles; type=smb,connectionString=\westeustg1\profiles

  Feljegyzés

  Ha korábban letöltötte az FSLogix-sablonokat, ugyanezeket a konfigurációkat az Active Directory csoportházirend-kezelési konzolján is elvégezheti. Az FSLogix csoportházirend-objektumának beállításáról további információt az FSLogix csoportházirend-sablonfájljainak használata című útmutatóban talál.

  

• Office-tároló tárfiók URI = \northeustg2\odcf

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

  • CCDLocations value = type=smb,connectionString=\northeustg2\odfc; type=smb,connectionString=\westeustg2\odfc

    

Másodlagos régió = Nyugat-Európa

• Profiltároló tárfiók URI = \westeustg1\profiles
  • Beállításkulcs elérési útja = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix-profilok >
  • CCDLocations value = type=smb,connectionString=\westeustg1\profiles; type=smb,connectionString=\northeustg1\profiles
• Office-tároló tárfiók URI = \westeustg2\odcf
  • Beállításkulcs elérési útja = HKEY_LOCAL_MACHINE > SOFTWARE >Policy > FSLogix > ODFC
  • CCDLocations value = type=smb,connectionString=\westeustg2\odfc; type=smb,connectionString=\northeustg2\odfc

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

A Cloud Cache konfigurációs és replikációs mechanizmusai minimális adatvesztéssel garantálják a profiladatok replikációját a különböző régiók között. Mivel ugyanazt a felhasználói profilfájlt csak egy folyamattal lehet megnyitni ReadWrite módban, kerülni kell az egyidejű hozzáférést, így a felhasználók nem nyithatnak meg kapcsolatot egyszerre mindkét gazdagépkészlettel.

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

Adatfolyam

1. A Virtual Desktop felhasználó elindítja a Virtual Desktop-ügyfelet, majd megnyitja az elsődleges régió gazdagépkészletéhez rendelt közzétett asztali vagy távoli alkalmazásalkalmazást.

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

3. A Cloud Cache összetevő ugyanakkor 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. Ehhez a folyamathoz a Cloud Cache az elsődleges régióban kizárólagos írási-olvasási zárolást szerez be ezeken a fájlokon.

4. Ugyanez a Virtual Desktop-felhasználó most egy másik közzétett alkalmazást szeretne elindítani a másodlagos régió gazdagépkészletéhez rendelve.

5. A másodlagos régió virtuális asztali munkamenet-gazdagépén futó FSLogix-összetevő megpróbálja csatlakoztatni a felhasználói profil VHD/X fájljait a helyi tárfiókból. A csatlakoztatás azonban meghiúsul, mivel ezeket a fájlokat a Cloud Cache összetevő zárolja, amely az elsődleges régióban futó Virtuális asztali munkamenet-gazdagépen fut.

6. Az alapértelmezett FSLogix- és Cloud Cache-konfigurációban a felhasználó nem tud bejelentkezni, és a rendszer hibát követ nyomon az FSLogix diagnosztikai naplóiban, ERROR_LOCK_VIOLATION 33 (0x21).

   

Identitás

A Virtual Desktop egyik legfontosabb függősége a felhasználói identitás rendelkezésre állása. Ahhoz, hogy a munkamenet-gazdagépekről virtuális asztalokat és távoli alkalmazásokat lehessen elérni, a felhasználóknak hitelesíteni kell magukat. A Microsoft Entra ID a Microsoft központosított felhőalapú identitásszolgáltatása, amely lehetővé teszi ezt a képességet. A Microsoft Entra ID-t mindig az Azure Virtual Desktop felhasználóinak hitelesítésére használják. A munkamenet-gazdagépek ugyanahhoz a Microsoft Entra-bérlőhöz vagy Active Directory-tartományhoz csatlakoztathatók a Active Directory tartományi szolgáltatások vagy a Microsoft Entra Domain Services (Microsoft Entra Domain Services) használatával, így rugalmas konfigurációs lehetőségek közül választhat.

• Microsoft Entra ID

  • Ez egy globális többrégiós és rugalmas szolgáltatás, magas rendelkezésre állással. Ebben a környezetben nincs szükség más műveletre a Virtual Desktop BCDR-csomag részeként.

• Active Directory Domain Services

  • Ahhoz, hogy Active Directory tartományi szolgáltatások rugalmasak és magas rendelkezésre állásúak legyenek, akkor is, ha régiószintű katasztrófa történik, legalább két tartományvezérlőt kell üzembe helyeznie az elsődleges Azure-régióban. Ezeknek a tartományvezérlőknek lehetőség szerint különböző rendelkezésre állási zónákban kell lenniük, és biztosítania kell a megfelelő replikációt a másodlagos régióban és végül a helyszínen található infrastruktúrával. Legalább egy további tartományvezérlőt kell létrehoznia a másodlagos régióban globális katalógussal és DNS-szerepkörökkel. További információ: AD DS üzembe helyezése Azure-beli virtuális hálózaton.

• Microsoft Entra Csatlakozás

  • Ha Microsoft Entra-azonosítót használ Active Directory tartományi szolgáltatások, majd a Microsoft Entra Csatlakozás a felhasználói identitás adatainak szinkronizálásához Active Directory tartományi szolgáltatások és a Microsoft Entra ID azonosítót, figyelembe kell vennie a szolgáltatás rugalmasságát és helyreállítását az állandó katasztrófák elleni védelem érdekében.

  • Magas rendelkezésre állást és vészhelyreállítást úgy biztosíthat, hogy a szolgáltatás egy második példányát telepíti a másodlagos régióban, és engedélyezi az előkészítési módot.

  • Ha van helyreállítás, a rendszergazdának elő kell segítenie a másodlagos példányt az előkészítési módból való kivételével. Ugyanazt az eljárást kell követniük, mint amikor a kiszolgálót átmeneti módba helyezik. A konfiguráció végrehajtásához a Microsoft Entra Global Rendszergazda istrator hitelesítő adatai szükségesek.

    

• Microsoft Entra Domain Services

  • A Microsoft Entra Domain Services bizonyos esetekben a Active Directory tartományi szolgáltatások alternatívaként is használható.
  • Magas rendelkezésre állást biztosít.
  • Ha a georedundáns helyreállítás a forgatókönyv hatókörébe tartozik, egy replikakészlettel üzembe kell helyeznie egy másik replikát a másodlagos Azure-régióban. Ezzel a funkcióval növelheti a magas rendelkezésre állást az elsődleges régióban.

Architektúradiagramok

Személyes gazdagépkészlet

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

Készletezett gazdagépkészlet

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

Feladatátvétel és feladat-visszavétel

Személyes gazdagépkészlet forgatókönyve

A személyes gazdagépkészlet feladatátvétele és feladat-visszavétele eltérő, mivel a Profil- és Office-tárolókhoz nincs felhőgyorsítótár és külső tároló. Az FSLogix technológiával továbbra is mentheti az adatokat egy tárolóba a munkamenet-gazdagépről. A vészhelyreállítási régióban nincs másodlagos gazdagépkészlet, ezért nem kell több munkaterületet és virtuális asztali erőforrást létrehozni a replikáláshoz és az 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ó. A Virtual Desktop esetében használja az Azure-ból azure-ba irányuló vészhelyreállítási architektúrát az Azure Site Recoveryben.

A következő szempontok és javaslatok érvényesek:

• A Site Recovery feladatátvétele nem automatikus – a rendszergazdának aktiválnia kell azt az Azure Portal vagy a PowerShell/API 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 szolgáltatásiszint-szerződésében (SLA) deklarált RTO található. A Site Recovery általában perceken belül feladatátvételt végezhet a virtuális gépeken.
• A Site Recoveryt az Azure Backup használatával használhatja. További információ: A Site Recovery és az Azure Backup használatának támogatása.
• Engedélyeznie kell a Site Recoveryt a virtuális gép szintjén, mivel nincs közvetlen integráció a Virtual Desktop portálon. A feladatátvételt és a feladat-visszavételt az egyetlen virtuális gép szintjén is aktiválnia kell.
• A Site Recovery teszt feladatátvételi képességet biztosít egy külön alhálózatban általános Azure-beli virtuális gépekhez. Ne használja ezt a funkciót virtuális asztali virtuális gépekhez, mivel egyszerre két azonos Virtual Desktop-munkamenetgazda hívná meg a Virtual Desktop vezérlősíkot.
• A Site Recovery nem tart fenn virtuálisgép-bővítményeket a replikáció során. Ha egyéni bővítményeket engedélyez virtuális asztali munkamenetgazda virtuális gépekhez, a feladatátvétel vagy feladat-visszavétel után újra engedélyeznie kell a bővítményeket. A Virtual Desktop beépített bővítményei joindomain és Microsoft.PowerShell.DSC csak munkamenetgazda virtuális gép létrehozásakor használhatók. Az első feladatátvétel után nyugodtan elveszítheti őket.
• Mindenképpen tekintse át az Azure-beli virtuális gépek Azure-régiók közötti vészhelyreállításának támogatási mátrixát, és ellenőrizze a Site Recovery Azure–Azure vészhelyreállítási forgatókönyv követelményeit, korlátait és kompatibilitási mátrixát, különösen a támogatott operációsrendszer-verziókat.
• Ha egy virtuális gépet egyik régióból a másikba szeretne feladatba venni, a virtuális gép nem védett állapotban indul el a cél vészhelyreállítási régióban. A feladat-visszavétel lehetséges, de a felhasználónak újra kell védenie a másodlagos régióban lévő virtuális gépeket, majd engedélyeznie kell a replikációt az elsődleges régióba.
• Végezze el a feladatátvételi és feladat-visszavételi eljárások rendszeres tesztelését. Ezután dokumentálja a lépések és helyreállítási műveletek pontos listáját az adott Virtual Desktop-környezet alapján.

Készletezett gazdagépkészlet forgatókönyve

Az aktív-aktív vészhelyreállítási modell egyik kívánt jellemzője, hogy a szolgáltatás helyreállításához nincs szükség rendszergazdai beavatkozásra, ha kimaradás történik. Feladatátvételi eljárásokra csak aktív-passzív architektúrában van szükség.

Aktív-passzív modellben a másodlagos vészhelyreállítási régiónak tétlennek kell lennie, minimális erőforrások konfigurálva és aktívként. A konfigurációt az elsődleges régióhoz kell igazítani. Ha feladatátvétel történik, a másodlagos vészhelyreállítási gazdagépkészletben lévő távoli alkalmazások összes asztali és alkalmazáscsoportjának összes felhasználója számára történő hozzárendelések egyszerre történnek.

Aktív-aktív modell és részleges feladatátvétel is lehetséges. Ha a gazdagépkészletet csak asztali és alkalmazáscsoportok biztosítására használják, akkor több, nem átfedésben lévő Active Directory-csoportban particionálhatja a felhasználókat, és hozzárendelheti a csoportot az elsődleges vagy másodlagos vészhelyreállítási gazdagépkészletek asztali és alkalmazáscsoportjaihoz. A felhasználók nem férhetnek hozzá egyszerre mindkét gazdagépkészlethez. Ha több alkalmazáscsoport és alkalmazás létezik, a felhasználók hozzárendeléséhez használt felhasználói csoportok átfedésben lehetnek. Ebben az esetben nehéz egy aktív-aktív stratégiát implementálni. Amikor egy felhasználó elindít egy távoli alkalmazást az elsődleges gazdagépkészletben, az FSLogix betölti a felhasználói profilt egy munkamenet-gazdagép virtuális gépére. Ha ugyanezt próbálja végrehajtani a másodlagos gazdagépkészleten, ütközést okozhat a mögöttes profillemezen.

Íme a kezdeti helyzet és a konfigurációs feltételezések:

• Az elsődleges régió és a másodlagos vészhelyreállítási régiók gazdagépkészletei a konfiguráció során igazodnak, beleértve a Cloud Cache-t is.
• A gazdagépkészletekben az asztali DAG1 és az APPG2 és az APPG3 távoli alkalmazásalkalmazás-csoportok is elérhetők a felhasználók számára.
• Az elsődleges régió gazdagépkészletében az Active Directory GRP1, GRP2 és GRP3 felhasználói csoportjai a DAG1, az APPG2 és az APPG3 felhasználók hozzárendelésére szolgálnak. Előfordulhat, hogy ezek a csoportok átfedésben vannak a felhasználói tagságokkal, de mivel a modell aktív-passzív, teljes feladatátvétellel rendelkezik, ez nem jelent problémát.

Az alábbi lépések azt írják le, hogy mikor történik feladatátvétel egy tervezett vagy nem tervezett vészhelyreállítás után.

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. Az elsődleges gazdagépkészlet összes csatlakoztatott felhasználójának kényszerített leválasztása van érvényben.
3. A másodlagos gazdagépkészletben, ahol ugyanazok az alkalmazáscsoportok vannak konfigurálva, hozzáférést kell adnia a felhasználóknak a DAG1, AZ APPG2 és az APPG3 csoporthoz a GRP1, GRP2 és GRP3 csoportokkal.
4. Tekintse át és módosítsa a másodlagos régió gazdagépkészletének kapacitását. Itt egy automatikus méretezési tervre támaszkodhat, amely automatikusan bekapcsolja a munkamenet-gazdagépeket. Manuálisan is elindíthatja a szükséges erőforrásokat.

A feladat-visszavétel lépései és folyamata hasonló, és a teljes folyamatot többször is végrehajthatja. A Cloud Cache és a tárfiókok konfigurálása biztosítja a profil- és office-tárolóadatok replikálását. A feladat-visszavétel előtt győződjön meg arról, hogy a gazdagépkészlet konfigurációja és a számítási erőforrások helyreállnak. A tárolási rész esetében, ha az elsődleges régióban adatvesztés történik, a Cloud Cache replikálja a profil- és Office-tárolóadatokat a másodlagos régió tárolójából.

A tesztelési feladatátvételi terv néhány konfigurációs módosítással is implementálható anélkül, hogy az hatással lenne az éles környezetre.

• Hozzon létre néhány új felhasználói fiókot az Active Directoryban éles környezetben.
• Hozzon létre egy GRP-TEST nevű új Active Directory-csoportot, és rendeljen hozzá felhasználókat.
• A DAG1, AZ APPG2 és az APPG3 hozzáférésének hozzárendelése a GRP-TEST csoport használatával.
• Útmutatást adhat a GRP-TEST csoport felhasználóinak az alkalmazások teszteléséhez.
• Tesztelje a feladatátvételi eljárást a GRP-TEST csoport használatával, hogy eltávolítsa a hozzáférést az elsődleges gazdagépkészletből, és hozzáférést adjon a másodlagos vészhelyreállítási készlethez.

Fontos javaslatok:

• 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.
• Végezzen rendszeres konfigurációigazítási ellenőrzést annak érdekében, hogy az elsődleges és másodlagos vészrégióban lévő gazdagépkészletek szinkronban legyenek.

Backup

Az útmutató egyik feltételezése, hogy a profiltárolók és az Office-tárolók között profilfelosztás és adatelválasztás van. Az FSLogix engedélyezi ezt a konfigurációt és a különálló tárfiókok használatát. Ha külön tárfiókokban van, különböző biztonsági mentési szabályzatokat használhat.

• Az Office Container esetében, ha a tartalom csak az online adattárból, például az Office 365-ből újraépíthető gyorsítótárazott adatokat jelöli, nem szükséges biztonsági másolatot készíteni az adatokról.

• Ha az Office-tárolók adatairól biztonsági másolatot kell készítenie, használhat kevésbé költséges tárterületet, vagy más biztonsági mentési gyakoriságot és megőrzési időtartamot.

• Személyes gazdagépkészlet-típus esetén a biztonsági mentést a munkamenetgazda virtuális gép szintjén kell végrehajtania. Ez a módszer csak akkor érvényes, ha az adatokat helyileg tárolják.

• Ha a OneDrive-ot és az ismert mappaátirányítást használja, a tárolón belüli adatok mentésének követelménye eltűnhet.

  Feljegyzés

  A OneDrive biztonsági mentése ebben a cikkben és forgatókönyvben nem szerepel.

• Ha nincs más követelmény, az elsődleges régióban lévő tároló biztonsági mentésének elegendőnek kell lennie. A vészhelyreállítási környezet biztonsági mentését általában nem használják.

• Az Azure Files-megosztáshoz használja az Azure Backupot.

  • A tároló rugalmassági típusához használja a zónaredundáns tárolást, ha nincs szükség helyszíni vagy régión kívüli biztonsági mentési tárolóra. Ha ezekre a biztonsági másolatokra van szükség, használjon georedundáns tárolást.

• Az Azure NetApp Files saját biztonsági mentési megoldást kínál. Ez a megoldás jelenleg előzetes verzióban érhető el, és zónaredundáns tárolási rugalmasságot biztosít.

  • Ellenőrizze a régió funkcióinak rendelkezésre állását, valamint a követelményeket és a korlátozásokat.

• Az MSIX-hez használt különálló tárfiókokat biztonsági mentésnek is ki kell terjednie, ha az alkalmazáscsomagok adattárait nem lehet könnyen újraépíteni.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerzők:

• Ben Martin Baur | Felhőmegoldás-tervező
• Igor Pagliai | Az Azure-hoz készült FastTrack (FTA) főmérnöke

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

• Nelson Del Villar | Felhőmegoldás-tervező, Azure Core-infrastruktúra
• Jason Martinez | Műszaki író

Következő lépések

• Azure Virtual Desktop vészhelyreállítási terv
• BCDR az Azure Virtual Desktophoz – felhőadaptálási keretrendszer
• Cloud Cache a rugalmasság és a rendelkezésre állás létrehozásához

Kapcsolódó erőforrások

• Megbízható Azure-alkalmazások tervezése
• A helyszínen elérhető és az AD DS által védett Azure-fájlok
• Nagyvállalati Azure Virtual Desktop
• Vállalati fájlmegosztások vészhelyreállítással
• FSLogix-konfigurációs példák