Možnosti provozní kontinuity a zotavení po havárii pro FSLogix
Poznámka:
Všechny diagramy jsou příklady založené na službě Azure Virtual Desktop a platí pro jiné platformy virtuálních klientských počítačů.
Efektivní plán provozní kontinuity a zotavení po havárii (BCDR) se zaměřuje na procesy a prostředky nezbytné pro organizaci, aby fungovala v případě katastrofy nebo jiného významného výpadku. Cestovní profily uživatelů nejsou běžně popisované jako obchodní nebo klíčové součásti strategie BCDR . Ve virtuálním desktopovém prostředí uživatel neví, že má cestovní profil. Profil je posílaný, aby uživatelům poskytoval konzistentní prostředí bez ohledu na virtuální počítač. Obchodní nebo kritická data by neměla být uložena v profilu uživatele, pokud je to vůbec možné. Použití OneDrivu, SharePointu nebo jiných řešení představuje efektivní způsob ochrany dat během události BCDR , a přitom se nespoléhá na datový roaming s uživatelem jako součást svého profilu. Tento proces je nejlépe popsaný ve cvičení cíle bodu obnovení (RTO) a cíle bodu obnovení (RPO), ve kterém je možné zvážit výhodu nákladů a analýzu rizik na základě organizačních a obchodních cílů.
Možnost 1: Bez obnovení profilu
I když tato možnost nevypadá jako návrh BCDR , zaměřuje se na zajištění, aby obchodní a důležitá data nebyla v profilu uživatele. Během havárie by uživatelé vytvářeli nové profily buď v novém umístění, nebo v novém poskytovateli úložiště (obojí může být pravdivé). Tato možnost je nákladově nejefektivnější z hlediska nákladů na infrastrukturu, i když má pokutu z důvodu účinku, který může mít na uživatelské prostředí.
Obrázek 1: Bez obnovení profilu | Standardní kontejnery FSLogix (VHDLocations)
V diagramu je fond hostitelů s více oblastmi pomocí služby Azure Virtual Desktop. Primární oblasti i oblasti převzetí služeb při selhání mají vyhrazenou sdílenou složku Azure Files pomocí zónově redundantního úložiště (ZRS), které poskytuje vysokou dostupnost v rámci oblasti. Oblast převzetí služeb při selhání má hostitele relací, které jsou zastavené nebo uvolněné. V případě havárie se oblast převzetí služeb při selhání stane primární oblastí a uživatelé se přihlásí k těmto hostitelům relací a vytvoří nové profily ve sdílené složce Azure Files v této oblasti.
Možnost 2: Cloud Cache (primární / převzetí služeb při selhání)
Návrh převzetí služeb při selhání je běžnou strategií pro zajištění dostupnosti a spolehlivosti infrastruktury v případě havárie nebo selhání. Cloud Cache umožňuje používat FSLogix pomocí tohoto typu návrhu převzetí služeb při selhání. Pomocí služby Cloud Cache můžete zařízení nakonfigurovat tak, aby používala dva (2) poskytovatele úložiště, kteří ukládají vaše profilová data do různých umístění. Cloud Cache synchronizuje data vašeho profilu s jednotlivými dvěma poskytovateli úložiště asynchronně, takže vždy máte nejnovější verzi dat. Některá vaše zařízení jsou v primárním umístění a ostatní zařízení jsou v umístění převzetí služeb při selhání. Cloud Cache upřednostňuje prvního poskytovatele úložiště (nejblíže vašemu zařízení) a jako zálohu používá jiného poskytovatele úložiště. Pokud je například primární zařízení v oblasti USA – západ a vaše zařízení s podporou převzetí služeb při selhání je v oblasti USA – východ, můžete cloudovou mezipaměť nakonfigurovat takto:
- Primární zařízení jako první možnost používá poskytovatele úložiště v oblasti USA – západ a jako druhou možnost poskytovatele úložiště v oblasti USA – východ.
- Zařízení s podporou převzetí služeb při selhání používá poskytovatele úložiště v oblasti USA – východ jako první možnost a jako druhou možnost poskytovatele úložiště v oblasti USA – západ.
- Pokud primární zařízení nebo nejbližší poskytovatel úložiště selže, můžete přepnout na zařízení s podporou převzetí služeb při selhání nebo poskytovatele úložiště zálohování a pokračovat v práci bez ztráty dat profilu.
Existuje však několik nevýhod použití návrhu převzetí služeb při selhání s cloudovou mezipamětí. Nejprve musíte zaplatit další poplatky za ukládání dat profilu do dvou (2) umístění. Za druhé, musíte ručně zahájit proces převzetí služeb při selhání, který může vyžadovat schválení obchodních zúčastněných stran. Za třetí může docházet k určité latenci nebo nekonzistence dat profilu kvůli asynchronní synchronizaci se dvěma poskytovateli úložiště.
Tip
- Než povolíte uživatelům navrácení služeb po obnovení do profilů v primárním umístění, ujistěte se, že se všichni uživatelé z umístění převzetí služeb při selhání úspěšně odhlásili, aby primární umístění mělo aktuální repliku dat profilu uživatele.
- Cloud Cache je systém náročný na vstupně-výstupní operace a může snadno způsobit kritické body sítě nebo úložiště v obnovené lokalitě.
Obrázek 2: CloudOvá mezipaměť (primární / převzetí služeb při selhání) | Cloudová mezipaměť FSLogix (CCDLocations)
V diagramu máme fond hostitelů s více oblastmi využívající Službu Azure Virtual Desktop. Součástí tohoto nastavení jsou primární oblasti i oblasti převzetí služeb při selhání. Každá z nich má vyhrazenou sdílenou složku Azure Files s využitím zónově redundantního úložiště (ZRS), která zajišťuje vysokou dostupnost v rámci oblasti. Oblast převzetí služeb při selhání obsahuje hostitele relací, které jsou buď zastavené, nebo uvolněné. V případě havárie se oblast převzetí služeb při selhání stane primární oblastí. Uživatelé se přihlásí k těmto hostitelům relací a načtou svůj replikovaný profil z oblasti převzetí služeb při selhání.
Je však důležité vzít v úvahu následující:
- Události BCDR (Provozní kontinuita a zotavení po havárii) jsou zřídka elegantní. V závislosti na okolnostech nemusí být zaručena, že data profilu uživatele nebudou nedotčena.
- Uživatelé přihlášení k hostitelům relací v oblasti převzetí služeb při selhání můžou zaznamenat ztrátu dat nebo v horších případech poškození kontejneru.
Vzhledem k této situaci je důležité používat platformy úložiště, jako je OneDrive nebo SharePoint, pro důležitá data. Tyto platformy poskytují další redundanci a ochranu před ztrátou dat. Mějte na paměti, že plánování zotavení po havárii je nezbytné a správné strategie úložiště může zmírnit rizika a zajistit kontinuitu podnikových procesů.
Možnost 3: CloudOvá mezipaměť (aktivní/ aktivní)
Při diskusi o infrastruktuře je běžné používat aktivní/aktivní návrhy, které je možné použít také u řešení profilu FSLogix. Díky této možnosti je cloudová mezipaměť nastavená se dvěma poskytovateli úložiště, kteří se aktualizují asynchronně tak, aby odrážely všechny změny provedené v místní mezipaměti. Nejprve je uveden poskytovatel úložiště, který je nejblíže aktivnímu umístění, zatímco nejbližší poskytovatel je uvedený jako druhý. V druhém umístění je pořadí obrácené. Tato možnost nese další náklady na ukládání dat poskytovatele ve dvou umístěních a před zahájením převzetí služeb při selhání vyžaduje ruční rozhodnutí podnikových zúčastněných stran.
Tip
- Pokud je neúspěšná oblast funkční, může trvat dlouho, než se data profilu plně replikují.
- Cloud Cache je systém náročný na vstupně-výstupní operace a může snadno způsobit kritické body sítě nebo úložiště v obnovené lokalitě.
Obrázek 3: Mezipaměť cloudu (aktivní / aktivní) | Cloudová mezipaměť FSLogix (CCDLocations)
V diagramu jsou dva (2) fondy hostitelů AVD a hostitelé relací umístěných v konkrétních oblastech Azure. Uživatelé přiřazení k oblasti USA – západ přistupují k těmto virtuálním počítačům. Uživatelé v oblasti USA – východ mají přístup pouze k těmto virtuálním počítačům a jsou jim přiřazeni. Během havárie musí mít přeživší oblast dostatečnou kapacitu pro podporu všech uživatelů. Kromě toho uživatelé z oblasti, která selhala, potřebují udělený přístup k virtuálním počítačům v přeživší oblasti.
Události BCDR nejsou nikdy elegantní a v závislosti na okolnostech události není zaručeno, že data profilů uživatelů nebudou nedotčená. Uživatelé, kteří se přihlašují k hostitelům relací v přeživší oblasti, můžou zaznamenat ztrátu dat nebo horší poškození kontejneru. Tato situace zesiluje potřebu používat úložné platformy, jako je OneDrive nebo SharePoint, pro důležitá uživatelská data.