Provozní kontinuita a zotavení po havárii (BCDR) ve více oblastech pro Azure Virtual Desktop

Azure Virtual Desktop je komplexní desktopová a aplikační virtualizační služba spuštěná v Microsoft Azure. Virtual Desktop pomáhá zajistit zabezpečené prostředí vzdálené plochy, které organizacím pomáhá posílit odolnost firmy. Poskytuje zjednodušenou správu, Windows 10 a 11 Enterprise s více relacemi a optimalizace pro Microsoft 365 Apps pro velké organizace. Pomocí služby Virtual Desktop můžete nasazovat a škálovat desktopy a aplikace pro Windows v Azure během několika minut a poskytovat integrované funkce zabezpečení a dodržování předpisů, které vám pomůžou zajistit zabezpečení aplikací a dat.

Vzhledem k tomu, že pro vaši organizaci s Virtual Desktopem nadále povolíte vzdálenou práci, je důležité porozumět jeho možnostem zotavení po havárii a osvědčeným postupům. Tyto postupy posílily spolehlivost napříč oblastmi, které pomáhají zajistit bezpečnost dat a produktivitu zaměstnanců. Tento článek obsahuje důležité informace o požadavcích na provozní kontinuitu a zotavení po havárii (BCDR), krocích nasazení a osvědčených postupech. Dozvíte se o možnostech, strategiích a pokynech k architektuře. Obsah v tomto dokumentu umožňuje připravit úspěšný plán BCDR a může vám pomoct přinést větší odolnost vaší firmy během plánovaných a neplánovaných výpadků.

Existuje několik typů havárií a výpadků a každý z nich může mít jiný dopad. Odolnost a obnovení jsou podrobně popsány pro místní události i události v celé oblasti, včetně obnovení služby v jiné vzdálené oblasti Azure. Tento typ obnovení se nazývá geografické zotavení po havárii. Pro zajištění odolnosti a dostupnosti je důležité vytvořit architekturu služby Virtual Desktop. Měli byste poskytnout maximální místní odolnost, abyste snížili dopad událostí selhání. Tato odolnost také snižuje požadavky na provádění postupů obnovení. Tento článek obsahuje také informace o vysoké dostupnosti a osvědčených postupech.

Řídicí rovina služby Virtual Desktop

Virtual Desktop nabízí BCDR pro řídicí rovinu, aby během výpadků zachovala metadata zákazníků. Když dojde k výpadku v oblasti, komponenty infrastruktury služeb převezme služby služby při selhání do sekundárního umístění a budou fungovat normálně. Stále máte přístup k metadatům souvisejícím se službami a uživatelé se stále můžou připojovat k dostupným hostitelům. Připojení koncových uživatelů zůstávají online, pokud prostředí tenanta nebo hostitelé zůstanou přístupní. Umístění dat pro Azure Virtual Desktop se liší od umístění nasazení virtuálních počítačů hostitelů relací fondu hostitelů. Metadata služby Virtual Desktop je možné vyhledat v jedné z podporovaných oblastí a pak nasadit virtuální počítače do jiného umístění. Nevyžaduje se žádná jiná akce.

Cíle a rozsah

Cílem tohoto průvodce je:

• Zajistěte maximální dostupnost, odolnost a možnosti geografického zotavení po havárii a současně minimalizujte ztrátu dat pro důležitá vybraná uživatelská data.
• Minimalizujte dobu obnovení.

Tyto cíle se také označují jako cíl bodu obnovení (RPO) a cíl doby obnovení (RTO).

Navrhované řešení poskytuje místní vysokou dostupnost, ochranu před selháním jedné zóny dostupnosti a ochranu před selháním celé oblasti Azure. K obnovení služby spoléhá na redundantní nasazení v jiné nebo sekundární oblasti Azure. I když je to stále dobrý postup, Virtual Desktop a technologie používané k sestavení BCDR nevyžadují spárování oblastí Azure. Primární a sekundární umístění můžou být libovolná kombinace oblastí Azure, pokud to latence sítě umožňuje.

Pokud chcete snížit dopad selhání jedné zóny dostupnosti, zvyšte vysokou dostupnost pomocí odolnosti:

• Ve výpočetní vrstvě rozložte hostitele relací služby Virtual Desktop mezi různé zóny dostupnosti.
• Ve vrstvě úložiště používejte odolnost zón, kdykoli je to možné.
• V síťové vrstvě nasaďte brány Azure ExpressRoute odolné vůči zóně a brány virtuální privátní sítě (VPN).
• Pro každou závislost zkontrolujte dopad výpadku jedné zóny a naplánujte zmírnění rizik. Nasaďte například kontrolery Doména služby Active Directory a další externí prostředky, ke které mají uživatelé služby Virtual Desktop přístup napříč několika zónami.

V závislosti na počtu zón dostupnosti, které používáte, vyhodnoťte nadměrné zřizování počtu hostitelů relací, aby se kompenzovala ztráta jedné zóny. Například i s dostupnými zónami (n-1) můžete zajistit uživatelské prostředí a výkon.

Z důvodu možných kombinací typů, možností replikace, možností služby a omezení dostupnosti v některých oblastech se místo konkrétních mechanismů replikace úložiště používá komponenta Cloud Cache z FSLogix .

OneDrive se v tomto článku nezabývá. Další informace o redundanci a vysoké dostupnosti najdete v tématu Odolnost dat SharePointu a OneDrivu v Microsoftu 365.

Ve zbývající části tohoto článku se dozvíte o řešeních pro dva různé typy fondu hostitelů služby Virtual Desktop. K dispozici jsou také pozorování, která vám umožní porovnat tuto architekturu s jinými řešeními:

• Osobní: V tomto typu fondu hostitelů má uživatel trvale přiřazeného hostitele relace, který by se nikdy neměl měnit. Vzhledem k tomu, že je osobní, může tento virtuální počítač ukládat uživatelská data. Předpokladem je použití technik replikace a zálohování k zachování a ochraně stavu.
• Fond: Uživatelům je dočasně přiřazen jeden z dostupných virtuálních počítačů hostitele relace z fondu, a to buď přímo prostřednictvím skupiny desktopových aplikací, nebo pomocí vzdálených aplikací. Virtuální počítače jsou bezstavové a uživatelská data a profily jsou uložené v externím úložišti nebo na OneDrivu.

Náklady jsou popsány, ale primárním cílem je zajistit efektivní nasazení geografického zotavení po havárii s minimální ztrátou dat. Další podrobnosti BCDR najdete v následujících zdrojích informací:

• Důležité informace o BCDR pro Virtual Desktop
• Zotavení po havárii služby Virtual Desktop

Požadavky

Nasaďte základní infrastrukturu a ujistěte se, že je dostupná v primární a sekundární oblasti Azure. Pokyny k topologii sítě najdete v topologii sítě a modelech připojení architektury Přechodu na cloud:

• Tradiční síťová topologie Azure
• Topologie sítě Virtual WAN (spravovaná Microsoftem)

V obou modelech nasaďte primární fond hostitelů služby Virtual Desktop a sekundární prostředí pro zotavení po havárii v různých paprskových virtuálních sítích a připojte je ke každému rozbočovači ve stejné oblasti. Umístěte jedno centrum do primárního umístění, jedno centrum v sekundárním umístění a pak vytvořte propojení mezi těmito dvěma.

Centrum nakonec poskytuje hybridní připojení k místním prostředkům, službám brány firewall, prostředkům identit, jako jsou Doména služby Active Directory Kontrolery a prostředky pro správu, jako je Log Analytics.

Při převzetí služeb při selhání do sekundárního umístění byste měli zvážit všechny obchodní aplikace a dostupnost závislých prostředků.

Aktivní-aktivní vs. aktivní-pasivní

Pokud mají různé sady uživatelů různé požadavky BCDR, Microsoft doporučuje používat více fondů hostitelů s různými konfiguracemi. Například uživatelé s nepostradatelnou aplikací můžou přiřadit plně redundantní fond hostitelů s funkcemi geografického zotavení po havárii. Vývojáři a testovací uživatelé ale můžou používat samostatný fond hostitelů bez zotavení po havárii.

Pro každý fond hostitelů služby Virtual Desktop můžete založit strategii BCDR na modelu aktivní-aktivní nebo aktivní-pasivní. V tomto kontextu se předpokládá, že konkrétní fond hostitelů obsluhuje stejnou sadu uživatelů v jednom geografickém umístění.

• Aktivní–aktivní

  • Pro každý fond hostitelů v primární oblasti nasadíte druhý fond hostitelů v sekundární oblasti.

  • Tato konfigurace poskytuje téměř nulovou plánovanou dobu obnovení a cíl bodu obnovení má dodatečné náklady.

  • Nevyžadujete, aby správce zasahoval nebo převzal služby při selhání. Během normálních operací poskytuje sekundární fond hostitelů uživateli prostředky služby Virtual Desktop.

  • Každý fond hostitelů má svůj vlastní účet úložiště pro trvalé profily uživatelů.

  • Měli byste vyhodnotit latenci na základě fyzického umístění a dostupného připojení uživatele. U některých oblastí Azure, jako je západní Evropa a Severní Evropa, může být rozdíl při přístupu k primárním nebo sekundárním oblastem zanedbatelný. Tento scénář můžete ověřit pomocí nástroje pro odhad prostředí služby Azure Virtual Desktop.

  • Uživatelé se přiřazují k různým skupinám aplikací, jako jsou desktopové a vzdálené aplikace, v primárních i sekundárních fondech hostitelů. V tomto případě uvidí duplicitní položky v klientském kanálu služby Virtual Desktop. Abyste se vyhnuli nejasnostem, použijte samostatné pracovní prostory služby Virtual Desktop s jasnými názvy a popisky, které odrážejí účel jednotlivých prostředků. Informujte uživatele o využití těchto prostředků.

    

  • Pokud potřebujete úložiště pro správu profilů FSLogix a kontejnerů Office, použijte cloudovou mezipaměť, abyste zajistili téměř nulový cíl bodu obnovení.

    • Aby nedocházelo ke konfliktům profilů, nepovolujte uživatelům současně přístup k oběma fondům hostitelů.
    • Vzhledem k aktivní povaze tohoto scénáře byste měli uživatele informovat o tom, jak tyto prostředky používat správným způsobem.

• Aktivní-pasivní

  • Stejně jako aktivní-aktivní, pro každý fond hostitelů v primární oblasti nasadíte druhý fond hostitelů v sekundární oblasti.
  • Množství výpočetních prostředků aktivních v sekundární oblasti se v porovnání s primární oblastí sníží v závislosti na dostupném rozpočtu. Automatické škálování můžete použít k zajištění větší výpočetní kapacity, ale vyžaduje více času a kapacita Azure není zaručená.
  • Tato konfigurace poskytuje vyšší rtO v porovnání s přístupem typu aktivní-aktivní, ale je levnější.
  • Pokud dojde k výpadku Azure, potřebujete zásah správce, abyste provedli postup převzetí služeb při selhání. Sekundární fond hostitelů obvykle neposkytuje uživatelům přístup k prostředkům služby Virtual Desktop.
  • Každý fond hostitelů má vlastní účty úložiště pro trvalé profily uživatelů.
  • Na uživatele, kteří využívají služby Virtual Desktop s optimální latencí a výkonem, mají vliv jenom v případě výpadku Azure. Tento scénář byste měli ověřit pomocí nástroje pro odhad prostředí služby Azure Virtual Desktop. Výkon by měl být přijatelný i v případě snížení výkonu sekundárního prostředí zotavení po havárii.
  • Uživatelům se přiřadí jenom jedna sada skupin aplikací, jako je Desktop a Remote Apps. Během normálních operací jsou tyto aplikace v primárním fondu hostitelů. Během výpadku a po převzetí služeb při selhání se uživatelé přiřazují ke skupinám aplikací v sekundárním fondu hostitelů. V informačním kanálu klienta služby Virtual Desktop uživatele se nezobrazují žádné duplicitní položky, můžou používat stejný pracovní prostor a vše je pro ně transparentní.
  • Pokud potřebujete úložiště pro správu profilů FSLogix a kontejnerů Office, použijte cloudovou mezipaměť, abyste zajistili téměř nulový cíl bodu obnovení.
    • Aby nedocházelo ke konfliktům profilů, nepovolujte uživatelům současně přístup k oběma fondům hostitelů. Vzhledem k tomu, že je tento scénář aktivní-pasivní, můžou správci toto chování vynutit na úrovni skupiny aplikací. Až po převzetí služeb při selhání bude mít uživatel přístup ke každé skupině aplikací v sekundárním fondu hostitelů. Přístup je odvolán ve skupině aplikací primárního fondu hostitelů a znovu přiřazen ke skupině aplikací v sekundárním fondu hostitelů.
    • Spuštění převzetí služeb při selhání pro všechny skupiny aplikací, jinak uživatelé používající různé skupiny aplikací v různých fondech hostitelů můžou způsobit konflikty profilů, pokud nejsou efektivně spravovány.
  • Určité podmnožině uživatelů je možné povolit selektivní převzetí služeb při selhání sekundárnímu fondu hostitelů a zajistit omezené chování aktivní-aktivní a testovací převzetí služeb při selhání. Převzetí služeb při selhání je také možné provést převzetí služeb při selhání konkrétních skupin aplikací, ale měli byste uživatele informovat, aby nepoužívaných prostředků z různých fondů hostitelů současně nepoužívaných prostředků.

Za určitých okolností můžete vytvořit jeden fond hostitelů s kombinací hostitelů relací umístěných v různých oblastech. Výhodou tohoto řešení je, že pokud máte jeden fond hostitelů, nemusíte duplikovat definice a přiřazení pro desktopové a vzdálené aplikace. Toto řešení má bohužel několik nevýhod.

• U fondů hostitelů ve fondu není možné vynutit uživatele k hostiteli relace ve stejné oblasti.
• Uživatel může při připojování k hostiteli relace ve vzdálené oblasti zaznamenat vyšší latenci a neoptimální výkon.
• Pokud potřebujete úložiště pro profily uživatelů, potřebujete složitou konfiguraci pro správu přiřazení pro hostitele relací v primárních a sekundárních oblastech.
• Režim vyprázdnění můžete použít k dočasnému zakázání přístupu k hostitelům relací umístěným v sekundární oblasti. Tato metoda ale přináší větší složitost, režii správy a neefektivní využití prostředků.
• Hostitele relací můžete udržovat v offline stavu v sekundárních oblastech, ale přináší větší složitost a režii správy.

Důležité informace a doporučení

OBECNÉ

Pokud chcete nasadit konfiguraci aktivní-aktivní nebo aktivní-pasivní pomocí více fondů hostitelů a mechanismus cloudové mezipaměti FSLogix, můžete vytvořit fond hostitelů ve stejném pracovním prostoru nebo jiný v závislosti na modelu. Tento přístup vyžaduje, abyste zachovali zarovnání a aktualizace, aby byly oba fondy hostitelů synchronizované a na stejné úrovni konfigurace. Kromě nového fondu hostitelů pro sekundární oblast zotavení po havárii potřebujete:

• Vytvoření nových jedinečných skupin aplikací a souvisejících aplikací pro nový fond hostitelů
• Pokud chcete odvolat přiřazení uživatelů k primárnímu fondu hostitelů a pak je během převzetí služeb při selhání ručně znovu přiřadit novému fondu hostitelů.

Projděte si možnosti provozní kontinuity a zotavení po havárii pro FSLogix.

• Tento dokument neobsahuje žádné obnovení profilu.
• Cloudová mezipaměť (aktivní/pasivní) je součástí tohoto dokumentu, ale implementuje se pomocí stejného fondu hostitelů.
• Zbývající část tohoto dokumentu se zabývá cloudovou mezipamětí (aktivní/aktivní ).

Existují určitá omezení pro prostředky služby Virtual Desktop. Další informace najdete v tématu Omezení služby Azure Virtual Desktop.

Pro diagnostiku a monitorování použijte stejný pracovní prostor služby Log Analytics pro primární i sekundární fond hostitelů.

Compute

• Pro nasazení obou fondů hostitelů v primárních i sekundárních oblastech zotavení po havárii byste měli používat zóny dostupnosti Azure a rozprostřet flotilu virtuálních počítačů do všech dostupných zón. Pokud zóny dostupnosti nejsou v místní oblasti dostupné, můžete použít sadu dostupnosti Azure.

• Zlatá image, kterou používáte pro nasazení fondu hostitelů v sekundární oblasti zotavení po havárii, by měla být stejná jako pro primární. Image byste měli ukládat do galerie služby Azure Compute a nakonfigurovat několik replik imagí v primárním i sekundárním umístění. Každá replika image může udržovat paralelní nasazení maximálního počtu virtuálních počítačů a na základě požadované velikosti dávky nasazení můžete vyžadovat více než jednu. Další informace najdete v tématu Ukládání a sdílení imagí v Galerii výpočetních prostředků Azure.

  

• Galerie výpočetních prostředků Azure není globálním prostředkem a doporučuje se mít v sekundární oblasti alespoň sekundární galerii. Jakmile vytvoříte v primární oblasti galerii, definici image virtuálního počítače a verzi image virtuálního počítače byste měli vytvořit stejné tři objekty také v sekundární oblasti. Při vytváření verze image virtuálního počítače je možné zkopírovat verzi image virtuálního počítače vytvořenou v primární oblasti. Abyste toho dosáhli, musíte v sekundární oblasti zadat galerii, definici image virtuálního počítače a verzi image virtuálního počítače použitou v primární oblasti a Azure zkopíruje image a vytvoří místní verzi image virtuálního počítače. Tuto operaci je možné spustit pomocí webu Azure Portal nebo příkazu AZ CLI, jak je uvedeno níže:

  Vytvoření definice image a verze image

  az sig image-version create

• Ne všechny hostitelské virtuální počítače relace v sekundárních umístěních zotavení po havárii musí být aktivní a spuštěné po celou dobu. Nejprve musíte vytvořit dostatečný počet virtuálních počítačů a potom použít mechanismus automatického škálování, jako je škálování plánů. Díky těmto mechanismům je možné udržovat většinu výpočetních prostředků v offline nebo uvolněném stavu, aby se snížily náklady.

• Automatizaci je také možné použít k vytváření hostitelů relací v sekundární oblasti pouze v případě potřeby. Tato metoda optimalizuje náklady, ale v závislosti na použitém mechanismu může vyžadovat delší rto. Tento přístup nepovolí testy převzetí služeb při selhání bez nového nasazení a nepovolí selektivní převzetí služeb při selhání pro konkrétní skupiny uživatelů.

• Když budou hostitelé relací v offline nebo uvolněném stavu v sekundární oblasti, nezaručíte dostupnost kapacity, pokud dojde k havárii v celé primární oblasti. Platí také v případě, že se v případě potřeby nasadí nové relace na vyžádání a s využitím Site Recovery . Výpočetní kapacita může být zaručena v následujících případech:
  • Hostitelé relací se uchovávají v aktivním stavu v sekundární oblasti.
  • Použijete novou funkci Azure Rezervace kapacity na vyžádání.

• Vzhledem k tomu, že používáte Cloud Cache:
  • Pro spravovaný disk virtuálního počítače s operačním systémem virtuálního počítače relace byste měli použít úroveň Premium.
  • CloudOvou mezipaměť byste měli přesunout na dočasnou jednotku virtuálního počítače a použít místní úložiště SSD.

Úložiště

V této příručce použijete alespoň dva samostatné účty úložiště pro každý fond hostitelů služby Virtual Desktop. Jedna je pro kontejner profilu FSLogix a jedna je určená pro data kontejneru Office. Pro balíčky MSIX potřebujete také jeden další účet úložiště. Vezměte na vědomí následující:

• Jako alternativy úložiště můžete použít sdílenou složku Azure Files a Azure NetApp Files .
• Sdílená složka Azure Files může zajistit odolnost zón pomocí možnosti odolnosti úložiště replikovaného zónou, pokud je dostupná v dané oblasti.
• Funkci geograficky redundantního úložiště nemůžete použít v následujících situacích:
  • Vyžadujete ne spárovanou oblast. Páry oblastí pro geograficky redundantní úložiště jsou pevné a nelze je změnit.
  • Používáte úroveň Premium.
• RPO a RTO jsou ve srovnání s mechanismem cloudové mezipaměti FSLogix vyšší.
• V produkčním prostředí není snadné otestovat převzetí služeb při selhání a navrácení služeb po obnovení.
• Služba Azure NetApp Files vyžaduje další aspekty:
  • Redundance zón ještě není k dispozici. Pokud je požadavek na odolnost důležitější než výkon, použijte sdílenou složku Azure Files.
  • Služba Azure NetApp Files může být zónová, to znamená, že se zákazníci můžou rozhodnout, ve které (jedné) zóně dostupnosti Azure se má přidělit.
  • Replikaci mezi zónami je možné vytvořit na úrovni svazku. Replikace je asynchronní (RPO>0) a vyžaduje ruční převzetí služeb při selhání (RTO>0). Před použitím této funkce se doporučuje zkontrolovat požadavky a důležité informace z tohoto článku.
  • Azure NetApp Files teď můžete používat s zónově redundantními bránami VPN a ExpressRoute, pokud se používá funkce Standardní sítě , kterou můžete použít pro odolnost sítě. Další informace naleznete v tématu Podporované síťové topologie.
  • Azure Virtual WAN se teď podporuje, ale vyžaduje funkci sítě Azure NetApp Files Standard. Další informace naleznete v tématu Podporované síťové topologie.
• Služba Azure NetApp Files má mechanismus replikace mezi oblastmi, platí následující aspekty:
  • Není k dispozici ve všech oblastech.
  • Dvojice oblastí jsou pevné.
  • Převzetí služeb při selhání není transparentní a navrácení služeb po obnovení vyžaduje rekonfiguraci úložiště.
• Limity
  • Existují omezení velikosti, vstupně-výstupních operací za sekundu (IOPS), šířky pásma MB/s pro sdílené složky Azure i účty úložiště Azure NetApp Files a svazky. V případě potřeby je možné použít více než jeden pro stejný fond hostitelů ve službě Virtual Desktop pomocí nastavení pro jednotlivé skupiny v FSLogix. Tato konfigurace ale vyžaduje větší plánování a konfiguraci.

Účet úložiště, který používáte pro balíčky aplikací MSIX, by se měl lišit od ostatních účtů pro profily a kontejnery Office. K dispozici jsou následující možnosti geografického zotavení po havárii:

• Jeden účet úložiště s povoleným geograficky redundantním úložištěm v primární oblasti
  • Sekundární oblast je pevná. Tato možnost není vhodná pro místní přístup, pokud dojde k převzetí služeb při selhání účtu úložiště.
• Dva samostatné účty úložiště, jeden v primární oblasti a druhý v sekundární oblasti (doporučeno)
  • Pro aspoň primární oblast použijte zónově redundantní úložiště.
  • Každý fond hostitelů v každé oblasti má přístup k místnímu úložišti k balíčkům MSIX s nízkou latencí.
  • Dvakrát zkopírujte balíčky MSIX v obou umístěních a zaregistrujte balíčky dvakrát v obou fondech hostitelů. Přiřaďte uživatele ke skupinám aplikací dvakrát.

FSLogix

Microsoft doporučuje používat následující konfiguraci a funkce FSLogix:

• Pokud obsah kontejneru profilů musí mít samostatnou správu BCDR a má v porovnání s kontejnerem Office jiné požadavky, měli byste je rozdělit.

  • Kontejner Office má obsah uložený v mezipaměti, který je možné znovu vytvořit nebo znovu vytvořit ze zdroje, pokud dojde k havárii. U kontejneru Office možná nebudete muset uchovávat zálohy, což může snížit náklady.
  • Při použití různých účtů úložiště můžete v kontejneru profilu povolit pouze zálohy. Nebo musíte mít různá nastavení, jako je doba uchovávání, využité úložiště, frekvence a RTO/RPO.

• Cloud Cache je komponenta FSLogix, ve které můžete zadat více umístění úložiště profilů a asynchronně replikovat data profilu, aniž byste museli spoléhat na všechny základní mechanismy replikace úložiště. Pokud první umístění úložiště selže nebo není dostupné, cloudová mezipaměť automaticky převezme služby při selhání, aby používala sekundární, a efektivně přidá vrstvu odolnosti. Pomocí cloudové mezipaměti můžete replikovat profily i kontejnery Office mezi různými účty úložiště v primárních a sekundárních oblastech.

  

• V registru hostitelského virtuálního počítače relace je nutné povolit službu Cloud Cache dvakrát, jednou pro kontejner profilů a jednou pro kontejner Office. V případě převzetí služeb při selhání a navrácení služeb po obnovení není možné povolit cloudovou mezipaměť pro kontejner Office, ale nepovolit ho, může to způsobit nesprávné zarovnání dat mezi primární a sekundární oblastí zotavení po havárii. Před použitím v produkčním prostředí tento scénář pečlivě otestujte.

• Cloud Cache je kompatibilní s nastavením rozdělení profilu i pro jednotlivé skupiny. pro každou skupinu je potřeba pečlivě navrhovat a plánovat skupiny a členství ve službě Active Directory. Musíte zajistit, aby byl každý uživatel součástí přesně jedné skupiny a tato skupina se používá k udělení přístupu k fondům hostitelů.

• Parametr CCDLocations zadaný v registru pro fond hostitelů v sekundární oblasti zotavení po havárii se vrátí v pořadí v porovnání s nastavením v primární oblasti. Další informace najdete v tématu Kurz: Konfigurace cloudové mezipaměti pro přesměrování kontejnerů profilů nebo kontejneru office na více poskytovatelů.

Následující příklad ukazuje konfiguraci cloudové mezipaměti a související klíče registru:

Primární oblast = Severní Evropa

• Identifikátor URI účtu úložiště kontejneru profilu = \northeustg1\profiles

  • Cesta ke klíči registru = profily HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix >
  • Hodnota CCDLocations = type=smb,connectionString=\northeustg1\profiles; type=smb,connectionString=\westeustg1\profiles

  Poznámka:

  Pokud jste si dříve stáhli šablony FSLogix, můžete stejné konfigurace provést prostřednictvím konzoly pro správu zásad skupiny služby Active Directory. Další podrobnosti o tom, jak nastavit objekt zásad skupiny pro FSLogix, najdete v příručce použití souborů šablon zásad skupiny FSLogix.

  

• Identifikátor URI účtu úložiště kontejneru Office = \northeustg2\odcf

  • Cesta ke klíči registru = HKEY_LOCAL_MACHINE > SOFTWARE >Policy > FSLogix > ODFC

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

    

Sekundární oblast = Západní Evropa

• Identifikátor URI účtu úložiště kontejneru profilu = \westeustg1\profiles
  • Cesta ke klíči registru = profily HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix >
  • Hodnota CCDLocations = type=smb,connectionString=\westeustg1\profiles; type=smb,connectionString=\northeustg1\profiles
• Identifikátor URI účtu úložiště kontejneru Office = \westeustg2\odcf
  • Cesta ke klíči registru = HKEY_LOCAL_MACHINE > SOFTWARE >Policy > FSLogix > ODFC
  • Hodnota CCDLocations = type=smb,connectionString=\westeustg2\odfc; type=smb,connectionString=\northeustg2\odfc

Replikace cloudové mezipaměti

Mechanismy konfigurace a replikace služby Cloud Cache zaručují replikaci dat profilu mezi různými oblastmi s minimální ztrátou dat. Vzhledem k tomu, že stejný soubor profilu uživatele lze otevřít v režimu ReadWrite pouze jedním procesem, měli byste se vyhnout souběžnému přístupu, takže uživatelé by neměli současně otevírat připojení k oběma fondům hostitelů.

Stáhněte si soubor aplikace Visio s touto architekturou.

Tok dat

1. Uživatel služby Virtual Desktop spustí klienta služby Virtual Desktop a pak otevře publikovanou aplikaci Desktop nebo vzdálenou aplikaci přiřazenou k primárnímu fondu hostitelů oblasti.

2. FSLogix načte profil uživatele a kontejnery Office a pak připojí základní virtuální pevný disk úložiště/X z účtu úložiště umístěného v primární oblasti.

3. Současně komponenta cloudové mezipaměti inicializuje replikaci mezi soubory v primární oblasti a soubory v sekundární oblasti. Pro účely tohoto procesu získá cloudová mezipaměť v primární oblasti u těchto souborů výhradní zámek pro čtení i zápis.

4. Stejný uživatel služby Virtual Desktop teď chce spustit jinou publikovanou aplikaci přiřazenou ve fondu hostitelů sekundární oblasti.

5. Komponenta FSLogix spuštěná na hostiteli relace služby Virtual Desktop v sekundární oblasti se pokusí připojit soubory VHD/X profilu uživatele z místního účtu úložiště. Připojení se ale nezdaří, protože tyto soubory jsou uzamčeny komponentou Cloudové mezipaměti spuštěnou na hostiteli relace služby Virtual Desktop v primární oblasti.

6. Ve výchozí konfiguraci FSLogix a cloudové mezipaměti se uživatel nemůže přihlásit a v diagnostických protokolech FSLogix se sleduje chyba ERROR_LOCK_VIOLATION 33 (0x21).

   

Identita

Jednou z nejdůležitějších závislostí pro Virtual Desktop je dostupnost identity uživatele. Pokud chcete získat přístup k virtuálním plochám a vzdáleným aplikacím z hostitelů relací, musí být uživatelé schopni se ověřit. Microsoft Entra ID je centralizovaná cloudová služba identit od Microsoftu, která tuto funkci umožňuje. ID Microsoft Entra se vždy používá k ověřování uživatelů pro Azure Virtual Desktop. Hostitelé relací se můžou připojit ke stejnému tenantovi Microsoft Entra nebo k doméně služby Active Directory pomocí služeb Doména služby Active Directory Services nebo služeb Microsoft Entra Domain Services (Microsoft Entra Domain Services), které vám poskytují možnost volby flexibilní konfigurace.

• Microsoft Entra ID

  • Jedná se o globální službu s více oblastmi a odolnou službou s vysokou dostupností. V tomto kontextu není v rámci plánu BCDR služby Virtual Desktop nutná žádná další akce.

• Active Directory Domain Services

  • Aby služba Doména služby Active Directory byla odolná a vysoce dostupná, i když dojde k havárii v celé oblasti, měli byste nasadit alespoň dva řadiče domény v primární oblasti Azure. Pokud je to možné, měly by být tyto řadiče domény v různých zónách dostupnosti a měli byste zajistit správnou replikaci s infrastrukturou v sekundární oblasti a nakonec místně. V sekundární oblasti byste měli vytvořit alespoň jeden další řadič domény s globálním katalogem a rolemi DNS. Další informace najdete v tématu Nasazení služby AD DS ve virtuální síti Azure.

• Microsoft Entra Připojení

  • Pokud používáte MICROSOFT Entra ID se službami Doména služby Active Directory Services a pak microsoft Entra Připojení k synchronizaci dat identity uživatele mezi Doména služby Active Directory Služby a ID Microsoft Entra, měli byste zvážit odolnost a obnovení této služby pro ochranu před trvalou havárií.

  • Vysokou dostupnost a zotavení po havárii můžete poskytnout tak, že v sekundární oblasti nainstalujete druhou instanci služby a povolíte pracovní režim.

  • Pokud dojde k obnovení, musí správce zvýšit úroveň sekundární instance tím, že ji vyřadí z pracovního režimu. Musí postupovat stejným postupem jako umístění serveru do pracovního režimu. K provedení této konfigurace jsou vyžadovány přihlašovací údaje microsoft Entra Global Správa istrator.

    

• Microsoft Entra Domain Services

  • Microsoft Entra Domain Services můžete v některých scénářích použít jako alternativu ke službám Doména služby Active Directory Services.
  • Nabízí vysokou dostupnost.
  • Pokud je geografické zotavení po havárii v rozsahu pro váš scénář, měli byste nasadit jinou repliku v sekundární oblasti Azure pomocí sady replik. Tuto funkci můžete použít také ke zvýšení vysoké dostupnosti v primární oblasti.

Diagramy architektury

Osobní fond hostitelů

Stáhněte si soubor aplikace Visio s touto architekturou.

Fond hostitelů ve fondu

Stáhněte si soubor aplikace Visio s touto architekturou.

Převzetí služeb při selhání a navrácení služeb po obnovení

Scénář osobního fondu hostitelů

Převzetí služeb při selhání a navrácení služeb po obnovení pro osobní fond hostitelů se liší, protože pro profily a kontejnery Office se nepoužívá žádná mezipaměť cloudu a externí úložiště. K uložení dat v kontejneru z hostitele relace můžete stále použít technologii FSLogix. V oblasti zotavení po havárii neexistuje žádný sekundární fond hostitelů, takže není potřeba vytvářet další pracovní prostory a prostředky služby Virtual Desktop pro replikaci a sladění. Site Recovery můžete použít k replikaci virtuálních počítačů hostitele relace.

Site Recovery můžete použít v několika různých scénářích. Pro Virtual Desktop použijte azure k architektuře zotavení po havárii v Azure Site Recovery.

Platí následující aspekty a doporučení:

• Převzetí služeb při selhání Site Recovery není automatické – správce ho musí aktivovat pomocí webu Azure Portal nebo PowerShellu nebo rozhraní API.
• Pomocí PowerShellu můžete skriptovat a automatizovat celou konfiguraci a operace Site Recovery.
• Site Recovery má deklarovanou rto v rámci smlouvy o úrovni služeb (SLA). Ve většině případů může Site Recovery převzít služby při selhání virtuálních počítačů během několika minut.
• Site Recovery můžete použít se službou Azure Backup. Další informace najdete v tématu Podpora použití Site Recovery se službou Azure Backup.
• Site Recovery musíte povolit na úrovni virtuálního počítače, protože v prostředí portálu Virtual Desktop neexistuje přímá integrace. Musíte také aktivovat převzetí služeb při selhání a navrácení služeb po obnovení na úrovni jednoho virtuálního počítače.
• Site Recovery poskytuje funkce testovacího převzetí služeb při selhání v samostatné podsíti pro obecné virtuální počítače Azure. Tuto funkci nepoužívejte pro virtuální počítače služby Virtual Desktop, protože byste měli dva identické hostitele relací virtuálních počítačů, kteří volají řídicí rovinu virtuálního počítače současně.
• Site Recovery během replikace nedržuje rozšíření virtuálních počítačů. Pokud povolíte všechna vlastní rozšíření pro virtuální počítače hostitele relací služby Virtual Desktop, musíte rozšíření po převzetí služeb při selhání nebo navrácení služeb po obnovení znovu povolit. Předdefinovaná doména připojení k virtual Desktopu a Microsoft.PowerShell.DSC se používají jenom při vytvoření virtuálního počítače hostitele relace. Po prvním převzetí služeb při selhání je bezpečné je ztratit.
• Nezapomeňte zkontrolovat matici podpory pro zotavení po havárii virtuálního počítače Azure mezi oblastmi Azure a zkontrolovat požadavky, omezení a matici kompatibility pro scénář zotavení po havárii Azure-to-Azure, zejména podporované verze operačního systému.
• Když převezmete služby při selhání virtuálního počítače z jedné oblasti do druhé, virtuální počítač se spustí v cílové oblasti zotavení po havárii v nechráněném stavu. Navrácení služeb po obnovení je možné, ale uživatel musí znovu chránit virtuální počítače v sekundární oblasti a potom povolit replikaci zpět do primární oblasti.
• Proveďte pravidelné testování postupů převzetí služeb při selhání a navrácení služeb po obnovení. Pak zdokumentujte přesný seznam kroků a akcí obnovení na základě vašeho konkrétního prostředí Virtual Desktopu.

Scénář fondu hostitelů ve fondu

Jednou zpožadovaných Postupy převzetí služeb při selhání by měly být nezbytné pouze v architektuře aktivní-pasivní.

V modelu aktivní-pasivní by sekundární oblast zotavení po havárii měla být nečinná, s minimálními nakonfigurovanými a aktivními prostředky. Konfigurace by měla být v souladu s primární oblastí. Pokud dojde k převzetí služeb při selhání, dojde k opětovnému přiřazení všech uživatelů ke všem skupinám klientů a aplikací pro vzdálené aplikace v sekundárním fondu hostitelů zotavení po havárii současně.

Je možné mít model aktivní-aktivní a částečné převzetí služeb při selhání. Pokud se fond hostitelů používá jenom k poskytování skupin plochy a aplikací, můžete uživatele rozdělit do několika nepřekrývajících se skupin Služby Active Directory a znovu přiřadit skupinu ke skupinám plochy a aplikací v primárních nebo sekundárních fondech hostitelů zotavení po havárii. Uživatel by neměl mít současně přístup k oběma fondům hostitelů. Pokud existuje více skupin aplikací a aplikací, můžou se skupiny uživatelů, které používáte k přiřazování uživatelů, překrývat. V tomto případě je obtížné implementovat strategii aktivní-aktivní. Při každém spuštění vzdálené aplikace v primárním fondu hostitelů se profil uživatele načte službou FSLogix na virtuálním počítači hostitele relace. Při pokusu o stejný postup v sekundárním fondu hostitelů může dojít ke konfliktu na disku podkladového profilu.

Tady je počáteční situace a předpoklady konfigurace:

• Fondy hostitelů v primární oblasti a sekundární oblasti zotavení po havárii jsou během konfigurace sladěné, včetně cloudové mezipaměti.
• Ve fondech hostitelů se uživatelům nabízejí skupiny aplikací vzdálené aplikace DAG1 i APPG2 i APPG3.
• Ve fondu hostitelů v primární oblasti se skupiny uživatelů Active Directory GRP1, GRP2 a GRP3 používají k přiřazení uživatelů k DAG1, APPG2 a APPG3. Tyto skupiny se můžou překrývat s členstvím uživatelů, ale protože model zde používá aktivní-pasivní s úplným převzetím služeb při selhání, není to problém.

Následující kroky popisují, kdy dojde k převzetí služeb při selhání po plánovaném nebo neplánovaném zotavení po havárii.

1. V primárním fondu hostitelů odeberte přiřazení uživatelů podle skupin GRP1, GRP2 a GRP3 pro skupiny aplikací DAG1, APPG2 a APPG3.
2. Pro všechny připojené uživatele z primárního fondu hostitelů je vynucené odpojení.
3. V sekundárním fondu hostitelů, kde jsou nakonfigurované stejné skupiny aplikací, musíte uživatelům udělit přístup k DAG1, APPG2 a APPG3 pomocí skupin GRP1, GRP2 a GRP3.
4. Zkontrolujte a upravte kapacitu fondu hostitelů v sekundární oblasti. Tady můžete chtít spoléhat na plán automatického škálování, který automaticky zapne hostitele relací. Potřebné prostředky můžete spustit také ručně.

Kroky a tok navrácení služeb po obnovení jsou podobné a celý proces můžete spustit několikrát. Cloud Cache a konfigurace účtů úložiště zajišťuje replikaci dat profilů a kontejnerů Office. Před navrácením služeb po obnovení se ujistěte, že se obnoví konfigurace fondu hostitelů a výpočetní prostředky. Pokud dojde ke ztrátě dat v primární oblasti, služba Cloud Cache pro část úložiště úložiště úložiště replikuje data profilu a kontejneru Office z úložiště sekundární oblasti.

Je také možné implementovat testovací plán převzetí služeb při selhání s několika změnami konfigurace, aniž by to mělo vliv na produkční prostředí.

• Vytvořte několik nových uživatelských účtů ve službě Active Directory pro produkční prostředí.
• Vytvořte novou skupinu služby Active Directory s názvem GRP-TEST a přiřaďte uživatele.
• Přiřaďte přístup k DAG1, APPG2 a APPG3 pomocí skupiny GRP-TEST.
• Poskytněte uživatelům ve skupině GRP-TEST pokyny k testování aplikací.
• Otestujte postup převzetí služeb při selhání pomocí skupiny GRP-TEST k odebrání přístupu z primárního fondu hostitelů a udělení přístupu k sekundárnímu fondu zotavení po havárii.

Důležitá doporučení:

• Automatizujte proces převzetí služeb při selhání pomocí PowerShellu, Azure CLI nebo jiného dostupného rozhraní API nebo nástroje.
• Pravidelně testujte celý postup převzetí služeb při selhání a navrácení služeb po obnovení.
• Proveďte pravidelnou kontrolu sladění konfigurace, abyste zajistili synchronizaci fondů hostitelů v primární a sekundární oblasti havárie.

Backup

Předpokladem v tomto průvodci je rozdělení profilu a oddělení dat mezi kontejnery profilů a kontejnery Office. FSLogix umožňuje tuto konfiguraci a použití samostatných účtů úložiště. Jakmile budete v samostatných účtech úložiště, můžete použít různé zásady zálohování.

• Pokud obsah pro kontejner Office představuje pouze data uložená v mezipaměti, která je možné znovu vytvořit z online úložiště dat, jako je Office 365, není nutné zálohovat data.

• Pokud je potřeba zálohovat data kontejnerů Office, můžete použít levnější úložiště nebo jinou frekvenci zálohování a dobu uchovávání.

• Pro typ osobního fondu hostitelů byste měli spustit zálohování na úrovni virtuálního počítače hostitele relace. Tato metoda se vztahuje pouze v případě, že jsou data uložena místně.

• Pokud používáte OneDrive a známé přesměrování složek, může požadavek na uložení dat uvnitř kontejneru zmizet.

  Poznámka:

  Zálohování Na OneDrivu se v tomto článku a scénáři nepovažuje.

• Pokud neexistuje jiný požadavek, zálohování úložiště v primární oblasti by mělo stačit. Zálohování prostředí pro zotavení po havárii se normálně nepoužívá.

• Pro sdílenou složku Azure Files použijte Azure Backup.

  • Pro typ odolnosti trezoru použijte zónově redundantní úložiště, pokud není potřeba zálohovat úložiště mimo lokalitu nebo oblast. Pokud jsou tyto zálohy potřeba, použijte geograficky redundantní úložiště.

• Azure NetApp Files poskytuje vlastní řešení zálohování. Toto řešení je aktuálně ve verzi Preview a může poskytovat zónově redundantní odolnost úložiště.

  • Ujistěte se, že zkontrolujete dostupnost funkcí oblasti spolu s požadavky a omezeními.

• Samostatné účty úložiště používané pro MSIX by také měly být pokryty zálohováním, pokud úložiště balíčků aplikací nelze snadno znovu vytvořit.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

• Ben Martin Baur | Architekt cloudového řešení
• Igor Pagliai | Hlavní inženýr FastTrack pro Azure (FTA)

Další přispěvatelé:

• Nelson Del Villar | Architekt cloudových řešení, základní infrastruktura Azure
• Jason Martinez | Technický spisovatel

Další kroky

• Plán zotavení po havárii Služby Azure Virtual Desktop
• BCDR pro Azure Virtual Desktop – Architektura přechodu na cloud
• Cloud Cache pro vytvoření odolnosti a dostupnosti

Související prostředky

• Návrh spolehlivých aplikací Azure
• Soubory Azure přístupné místně a zabezpečené službou AD DS
• Azure Virtual Desktop pro velké organizace
• Sdílené složky organizace s zotavením po havárii
• Příklady konfigurace FSLogix