適用於 Azure 虛擬桌面的多區域商務持續性和災害復原 （BCDR）

Azure 虛擬桌面是Microsoft Azure 上執行的完整桌面和應用程式虛擬化服務。 虛擬桌面可協助啟用安全的遠端桌面體驗，協助組織加強商務復原能力。 它提供簡化的管理、Windows 10 和 11 企業版多重會話，以及 Microsoft 365 Apps 企業版 的優化。 透過虛擬桌面，您可以在幾分鐘內在 Azure 上部署及調整 Windows 桌面和應用程式，提供整合式安全性和合規性功能，以協助保護您的應用程式和數據安全。

當您繼續使用虛擬桌面為組織啟用遠端工作時，請務必瞭解其災害復原 （DR） 功能和最佳做法。 這些做法可加強跨區域的可靠性，以協助數據安全且員工提高生產力。 本文提供商務持續性和災害復原 （BCDR） 必要條件、部署步驟和最佳做法的考慮。 您將瞭解選項、策略和架構指引。 本文件中的內容可讓您準備成功的 BCDR 計劃，並協助您在計劃性和非計劃性停機事件期間為您的企業帶來更多復原能力。

有數種類型的災害和中斷，而且每個類型都有不同的影響。 針對本機和全區域事件，會深入討論復原和復原，包括在不同的遠端 Azure 區域中復原服務。 這種類型的復原稱為異地災害復原。 建置虛擬桌面架構以進行復原和可用性非常重要。 您應該提供最大的本機復原能力，以減少失敗事件的影響。 此復原功能也會減少執行復原程式的需求。 本文也提供高可用性和最佳做法的相關信息。

目標和範圍

本指南的目標是：

• 確保可用性上限、復原能力和異地災害復原功能，同時將重要所選使用者數據的數據遺失降至最低。
• 將復原時間降至最低。

這些目標也稱為恢復點目標 （RPO） 和復原時間目標 （RTO）。

建議的解決方案提供本機高可用性、從單 一可用性區域 失敗的保護，以及整個 Azure 區域失敗的保護。 它依賴不同或次要 Azure 區域中的備援部署來復原服務。 雖然它仍然是很好的作法，但用來建置 BCDR 的虛擬桌面和技術不需要配對 Azure 區域。 如果網路等待時間允許，主要和次要位置可以是任何 Azure 區域組合。 在多個地理區域中 操作 AVD 主機集區可提供更多優點，不限於 BCDR。

若要降低單一可用性區域失敗的影響，請使用復原功能來改善高可用性：

• 在 計算 層，將虛擬桌面會話主機分散到不同的可用性區域。
• 在 儲存 層，盡可能使用區域復原功能。
• 在 網路 層，部署具有區域彈性的 Azure ExpressRoute 和虛擬專用網 （VPN） 閘道。
• 針對每個相依性，請檢閱單一區域中斷和計劃緩和措施的影響。 例如，跨多個可用性區域部署虛擬桌面使用者所存取 Active Directory 網域 控制器和其他外部資源。

根據您使用的可用性區域數目，評估過度布建會話主機數目，以補償一個區域遺失的情況。 例如，即使有可用的 （n-1） 區域，您也能確保用戶體驗和效能。

由於某些區域中類型、復寫選項、服務功能和可用性限制的可能組合，因此建議使用 FSLogix 的雲端快取元件，而不是使用記憶體特定的復寫機制。

本文未涵蓋 OneDrive。 如需備援和高可用性的詳細資訊，請參閱 Microsoft 365 中的 SharePoint 和 OneDrive 資料復原。

針對本文的其餘部分，您將瞭解兩種不同虛擬桌面主機集區類型的解決方案。 另外也會提供觀察，讓您可以比較此架構與其他解決方案：

• 個人： 在此類型的主機集區中，使用者具有永久指派的會話主機，不應變更。 由於此 VM 是個人化，所以此 VM 可以儲存用戶數據。 假設使用復寫和備份技術來保留和保護狀態。
• 集區： 用戶會透過桌面應用程式群組或使用遠端應用程式，從集區暫時指派其中一個可用的會話主機 VM。 VM 是無狀態，用戶數據和配置檔會儲存在外部記憶體或 OneDrive 中。

討論成本影響，但主要目標是提供有效的異地災害復原部署，且數據遺失最少。 如需更多BCDR詳細數據，請參閱下列資源：

• 虛擬桌面的BCDR考慮
• 虛擬桌面災害復原

必要條件

部署核心基礎結構，並確定其可在主要和次要 Azure 區域中使用。 如需網路拓撲的指引，您可以使用 Azure 雲端採用架構 網路拓撲和連線模型：

• 傳統 Azure 網路拓撲
• 虛擬網路拓撲（由Microsoft管理）

在這兩種模型中，部署主要虛擬桌面主機集區和不同輪輻虛擬網路內的次要災害復原環境，並將其連線至相同區域中的每個中樞。 將一個中樞放在主要位置，一個中樞放在次要位置，然後建立兩者之間的連線。

中樞最終會提供內部部署資源的混合式連線、防火牆服務、身分識別資源，例如 Active Directory 網域 控制器，以及Log Analytics等管理資源。

故障轉移至次要位置時，您應該考慮任何企業營運應用程式和相依的資源可用性。

控制平面商務持續性和災害復原

虛擬桌面為其控制平面提供商務持續性和災害復原，以在中斷期間保留客戶元數據。 Azure 平臺會管理此數據和程式，而且使用者不需要設定或執行任何專案。

虛擬桌面的設計目的是要復原個別元件的失敗，而且能夠快速從失敗中復原。 當區域發生中斷時，服務基礎結構元件會故障轉移至次要位置，並繼續正常運作。 您仍然可以存取服務相關的元數據，而且使用者仍然可以連線到可用的主機。 如果租用戶環境或主機仍可存取，用戶聯機會保持在線狀態。 虛擬桌面 的數據位置與主機集區會話主機虛擬機 （VM） 部署的位置不同。 可以在其中一個支持的區域中找到虛擬桌面元數據，然後在不同的位置部署 VM。 虛擬桌面服務架構和復原一文提供更多詳細數據。

主動-主動與主動-被動

如果不同的使用者集合有不同的 BCDR 需求，Microsoft建議您使用不同的組態使用多個主機集區。 例如，具有任務關鍵性應用程式的使用者可能會指派具有異地災害復原功能的完整備援主機集區。 不過，開發和測試使用者可以使用個別的主機集區，完全沒有災害復原。

針對每個單一虛擬桌面主機集區，您可以將BCDR策略以主動-主動或主動-被動模型為基礎。 此案例假設特定主機集區會提供同一組地理位置中的相同使用者。

• 主動-主動

  • 針對主要區域中的每個主機集區，您會在次要區域中部署第二個主機集區。

  • 此設定提供幾乎零個 RTO，而 RPO 有額外的成本。

  • 您不需要系統管理員介入或故障轉移。 在正常作業期間，次要主機集區會為使用者提供虛擬桌面資源。

  • 每個主機集區都有自己的記憶體帳戶（至少一個）用於持續性使用者配置檔。

  • 您應該根據使用者的實體位置和可用的連線能力來評估延遲。 對於某些 Azure 區域，例如西歐和北歐，存取主要或次要區域時，差異可以忽略不計。 您可以使用 Azure 虛擬桌面體驗估算器工具來驗證此案例。

  • 使用者會指派給主要和次要主機集區中的不同應用程式群組，例如傳統型應用程式群組 （DAG） 和 RemoteApp 應用程式群組 （RAG）。 在此情況下，他們在虛擬桌面用戶端摘要中看到重複的專案。 若要避免混淆，請使用具有清楚名稱和標籤的個別虛擬桌面工作區，以反映每個資源的用途。 通知使用者這些資源的使用量。

    

  • 如果您需要個別管理 FSLogix 配置檔和 ODFC 容器 的記憶體，請使用雲端快取來確保幾乎零 RPO。

    • 為了避免配置檔衝突，不允許用戶同時存取這兩個主機集區。
    • 由於此案例的作用中-主動本質，您應該教育使用者如何以適當的方式使用這些資源。

• 主動-被動
  • 如同主動-主動，針對主要區域中的每個主機集區，您會在次要區域中部署第二個主機集區。
  • 相較於主要區域，次要區域中作用中的計算資源量會根據可用的預算而減少。 您可以使用自動調整來提供更多計算容量，但需要更多時間，且 Azure 容量不保證。
  • 相較於主動-主動方法，此組態可提供較高的 RTO，但成本較低。
  • 如果發生 Azure 中斷，您需要系統管理員介入來執行故障轉移程式。 次要主機集區通常不會為使用者提供虛擬桌面資源的存取權。
  • 每個主機集區都有自己的記憶體帳戶，適用於持續性使用者配置檔。
  • 只有在發生 Azure 中斷時，才會影響使用具有最佳延遲和效能的虛擬桌面服務的使用者。 您應該使用 Azure 虛擬桌面體驗估算器 工具來驗證此案例。 即使降級，次要災害復原環境仍可接受效能。
  • 使用者只會指派給一組應用程式群組，例如桌面和遠端應用程式。 在正常作業期間，這些應用程式位於主要主機集區中。 在中斷期間和故障轉移之後，使用者會指派給次要主機集區中的應用程式群組。 使用者虛擬桌面用戶端摘要中不會顯示重複的專案、可以使用相同的工作區，而且所有專案都對它們而言是透明的。
  • 如果您需要記憶體來管理 FSLogix 配置檔和 Office 容器，請使用雲端快取來確保幾乎零 RPO。
    • 為了避免配置檔衝突，不允許用戶同時存取這兩個主機集區。 由於此案例是主動-被動的，系統管理員可以在應用程式群組層級強制執行此行為。 只有在故障轉移程式之後，使用者才能存取次要主機集區中的每個應用程式群組。 存取權會在主要主機集區應用程式群組中撤銷，並重新指派給次要主機集區中的應用程式群組。
    • 針對所有應用程式群組執行故障轉移，否則在不同主機集區中使用不同的應用程式群組的使用者，如果無法有效管理，可能會導致配置檔衝突。
  • 允許特定使用者子集選擇性地故障轉移至次要主機集區，並提供有限的主動-主動行為和測試故障轉移功能。 您也可以故障轉移特定應用程式群組，但您應該教育使用者不要同時使用來自不同主機集區的資源。

針對特定情況，您可以使用位於不同區域的會話主機混合建立單一主機集區。 此解決方案的優點是，如果您有單一主機集區，則不需要重複桌面和遠端應用程式的定義和指派。 不幸的是， 共用主機集 區的災害復原有幾個缺點：

• 針對集區主機集區，您無法強制使用者在同一個區域中的會話主機。
• 當連線到遠端區域中的會話主機時，使用者可能會遇到更高的延遲和次佳效能。
• 如果您需要使用者配置檔的記憶體，則需要複雜的設定來管理主要和次要區域中會話主機的指派。
• 您可以使用清空模式暫時停用存取位於次要區域的會話主機。 但此方法引進了更複雜的管理額外負荷，以及資源使用效率不佳。
• 您可以維護次要區域中處於離線狀態的會話主機，但會產生更複雜的和管理額外負荷。

考慮和建議

一般

若要使用多個主機集區和 FSLogix 雲端快取機制來部署主動-主動或主動-被動組態，您可以根據模型，在相同的工作區或不同的工作區內建立主機集區。 這種方法需要您維持一致性和更新，同時讓主機集區保持同步，以及在同一組態層級。 除了次要災害復原區域的新主機集區之外，您還需要：

• 若要為新的主機集區建立新的不同應用程式群組和相關應用程式。
• 若要撤銷主要主機集區的使用者指派，然後在故障轉移期間手動將它們重新指派給新的主機集區。

檢閱 FSLogix 的商務持續性和災害復原選項。

• 本檔未涵蓋任何配置檔復原 。
• 雲端快取 （主動/被動） 包含在本檔中，但會使用相同的主機集區加以實作。
• 本文件的其餘部分涵蓋雲端快取（作用中/主動）。

虛擬桌面資源在虛擬桌面架構的設計中必須考慮的限制。 根據 虛擬桌面服務限制來驗證您的設計。

針對診斷和監視，最好針對主要和次要主機集區使用相同的Log Analytics工作區。 使用此設定， Azure 虛擬桌面深入解析 在這兩個區域中提供統一的部署檢視。

不過，如果整個主要區域無法使用，使用單一記錄目的地可能會導致問題。 次要區域將無法使用無法使用區域中的Log Analytics工作區。 如果這種情況無法接受，可以採用下列解決方案：

• 針對每個區域使用不同的 Log Analytics 工作區，然後將虛擬桌面元件指向其本機工作區。
• 測試和檢閱記錄分析工作區複 寫和故障轉移功能。

計算

• 若要在主要和次要災害復原區域中部署兩個主機集區，您應該將會話主機 VM 機隊分散到多個可用性區域。 如果本機區域中無法使用可用性區域，您可以使用可用性設定組，讓您的解決方案更具復原性，而不是使用預設部署。

• 您在次要災害復原區域中用於主機集區部署的黃金映像應該與您用於主要複本的映射相同。 您應該將映像儲存在 Azure 計算資源庫中，並在主要和次要位置中設定多個映像複本。 每個映像複本可以維持最大 VM 數目的平行部署，而且您可能需要根據所需的部署批次大小來要求多個。 如需詳細資訊，請參閱在 Azure Compute Gallery 中儲存及共用映像。

  

• Azure 計算資源庫不是全域資源。 建議在次要區域中至少有次要資源庫。 在您的主要區域中，建立資源庫、VM 映像定義和 VM 映射版本。 然後，也會在次要區域中建立相同的物件。 建立 VM 映像版本時，您可以藉由指定主要區域中所使用的資源庫、VM 映像定義和 VM 映射版本，來複製在主要區域中建立的 VM 映射版本。 Azure 會複製映像並建立本機 VM 映像版本。 您可以使用 Azure 入口網站 或 Azure CLI 命令來執行這項作業，如下所示：

  建立映像定義和映像版本

  az sig image-version create

• 並非所有次要災害復原位置中的會話主機 VM 都必須處於作用中狀態，而且一直都在執行中。 您一開始必須建立足夠的 VM 數目，之後，請使用自動調整機制，例如 調整方案。 透過這些機制，可以維持處於離線或已解除分配狀態的大部分計算資源，以降低成本。

• 您也可以只在需要時，使用自動化在次要區域中建立會話主機。 此方法會優化成本，但視您使用的機制而定，可能需要較長的 RTO。 此方法不允許在沒有新部署的情況下進行故障轉移測試，也不允許特定使用者群組進行選擇性故障轉移。

• 在離線或 解除分配的情況下，在次要區域中擁有會話主機，並不保證在主要區域發生災害時，有可用的容量。 如果視需要視需要部署新的會話主機，以及使用 Site Recovery 使用量，也會適用。 只有在已配置相關資源且作用中時，才能保證計算容量。

針對雲端快取使用案例，建議針對受控磁碟使用進階層。

儲存體

在本指南中，您會針對每個虛擬桌面主機集區使用至少兩個不同的記憶體帳戶。 其中一個適用於 FSLogix 配置檔容器，另一個適用於 Office 容器數據。 您還需要一個 MSIX 套件的記憶體帳戶。 下列考量適用：

• 您可以使用 Azure 檔案儲存體 共用和 Azure NetApp Files 作為記憶體替代方案。 若要比較選項，請參閱 FSLogix 容器記憶體選項。
• Azure 檔案儲存體 共用可以使用區域備援記憶體 （ZRS） 復原選項，以提供區域復原功能，如果區域有提供。
• 在下列情況下，您無法使用異地備援記憶體功能：
  • 您需要 沒有配對的區域。 異地備援記憶體的區域配對已修正且無法變更。
  • 您使用的是進階層。
• 相較於 FSLogix 雲端快取機制，RPO 和 RTO 較高。
• 在生產環境中測試故障轉移和容錯回復並不容易。
• Azure NetApp Files 需要更多考慮：
  • 區域備援尚無法使用。 如果復原需求比效能更重要，請使用 Azure 檔案儲存體 共用。
  • Azure NetApp Files 可以是 區域性，也就是客戶可以決定要配置哪一個 Azure 可用性區域。
  • 跨區域復 寫可以在磁碟區層級建立，以提供區域復原功能，但復寫會以異步方式進行，而且需要手動故障轉移。 此程式需要大於零的恢復點目標 （RPO） 和復原時間目標 （RTO）。 使用此功能之前，請先 檢閱跨區域複寫的需求和考慮。
  • 如果使用 標準網路 功能，您可以使用 Azure NetApp Files 搭配區域備援 VPN 和 ExpressRoute 閘道，而此功能可能會用於網路復原。 如需詳細資訊，請參閱支援的網路拓撲。
  • 搭配 Azure NetApp Files 標準網路使用時，支援 Azure 虛擬 WAN。 如需詳細資訊，請參閱支援的網路拓撲。
• Azure NetApp Files 具有 跨區域複寫機制。 適用下列考慮：
  • 所有區域都無法使用。
  • Azure NetApp Files 磁碟區區域配對的跨區域複寫可能會與 Azure 儲存體 區域配對不同。
  • 無法同時搭配 跨區域複寫使用
  • 故障轉移不透明，且容錯回復需要 重新設定記憶體。
• 限制
  • Azure 檔案儲存體 共用和 Azure NetApp Files 記憶體帳戶和磁碟區的大小、每秒輸入/輸出作業數（IOPS）、帶寬 MBps 都有限制。 如有必要，可以在 FSLogix 中使用個別群組設定，為虛擬桌面中的相同主機集區使用多個主機集區。 不過，此設定需要更多規劃和設定。

您用於 MSIX 應用程式套件的記憶體帳戶應該與其他配置檔和 Office 容器的帳戶不同。 以下是可用的異地災害復原選項：

• 主要區域中已啟用異地備援記憶體的一個記憶體帳戶
  • 次要區域是固定的。 如果記憶體帳戶故障轉移，此選項不適用於本機存取。
• 兩個不同的記憶體帳戶，一個在主要區域，另一個在次要區域（建議）
  • 至少針對主要區域使用區域備援記憶體。
  • 每個區域中的每個主機集區都有 MSIX 套件的本機記憶體存取權，且延遲低。
  • 在兩個位置複製 MSIX 套件兩次，並在兩個主機集區中註冊套件兩次。 將使用者指派給應用程式群組兩次。

FSLogix

Microsoft建議您使用下列 FSLogix 組態和功能：

• 如果配置檔容器內容需要個別的 BCDR 管理，而且與 Office 容器相比有不同的需求，您應該加以分割。

  • 如果發生災害，Office 容器只會快取可重建或重新填入來源的內容。 使用 Office 容器時，您可能不需要保留備份，這可能會降低成本。
  • 使用不同的記憶體帳戶時，您只能在配置檔容器上啟用備份。 或者，您必須有不同的設定，例如保留期間、記憶體使用、頻率和 RTO/RPO。

• 雲端快取 是 FSLogix 元件，您可以在其中指定多個配置檔記憶體位置，並以異步方式複寫配置檔數據，而不需要依賴任何基礎記憶體複寫機制。 如果第一個儲存位置失敗或無法連線，雲端快取會自動故障轉移以使用次要位置，並有效地新增復原層。 使用雲端快取，在主要和次要區域中的不同記憶體帳戶之間復寫配置檔和 Office 容器。

  

• 您必須在會話主機 VM 登錄中啟用雲端快取兩次，一次用於配置檔容器，一次用於 Office 容器。 如果故障轉移和容錯回復，可能無法啟用適用於 Office 容器的雲端快取，但未啟用它可能會導致主要和次要災害復原區域之間的數據不一致。 在生產環境中使用它之前，請先仔細測試此案例。

• 雲端快取與 配置檔分割 和 個別群組 設定相容。 每個群組需要仔細設計和規劃 Active Directory 群組和成員資格。 您必須確定每位使用者都是一個群組的一部分，而且該群組用來授與主機集區的存取權。

• 相較於主要區域中的設定，次要災害復原區域中主機集區登錄中指定的 CCDLocations 參數會依序還原。 如需詳細資訊，請參閱 教學課程：設定雲端快取將配置檔容器或辦公室容器重新導向至多個提供者。

  提示

  本文著重於特定案例。 FSLogix 的高可用性選項和 FSLogix 的商務持續性和災害復原選項會說明其他案例。

下列範例顯示雲端快取組態和相關登錄機碼：

主要區域 = 北歐

• 配置檔容器記憶體帳戶 URI = \northeustg1\profiles

  • 登錄機碼路徑 = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > 配置檔
  • CCDLocations 值 = type=smb，connectionString=\northeustg1\profiles;type=smb，connectionString=\westeustg1\profiles

  注意

  如果您先前已 下載 FSLogix 範本，您可以透過 Active Directory 組策略管理控制台完成相同的設定。 如需如何設定 FSLogix 組策略對象的詳細資訊，請參閱使用 FSLogix 組策略範本檔案指南。

  

• Office 容器記憶體帳戶 URI = \northeustg2\odcf

  • 登錄機碼路徑 = HKEY_LOCAL_MACHINE > SOFTWARE >原則 > FSLogix > ODFC

  • CCDLocations 值 = type=smb，connectionString=\northeustg2\odfc;type=smb，connectionString=\westeustg2\odfc

    

次要區域 = 西歐

• 配置檔容器記憶體帳戶 URI = \westeustg1\profiles
  • 登錄機碼路徑 = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > 配置檔
  • CCDLocations 值 = type=smb，connectionString=\westeustg1\profiles;type=smb，connectionString=\northeustg1\profiles
• Office 容器記憶體帳戶 URI = \westeustg2\odcf
  • 登錄機碼路徑 = HKEY_LOCAL_MACHINE > SOFTWARE >原則 > FSLogix > ODFC
  • CCDLocations 值 = type=smb，connectionString=\westeustg2\odfc;type=smb，connectionString=\northeustg2\odfc

雲端快取複寫

雲端快取組態和復寫機制可保證不同區域之間的配置檔數據複寫，且數據遺失最少。 由於只有一個進程可以在 ReadWrite 模式中開啟相同的使用者配置檔檔案，因此應該避免並行存取，因此使用者不應該同時開啟兩個主機集區的連線。

下載此架構的 Visio 檔案。

資料流程

1. 虛擬桌面使用者啟動虛擬桌面用戶端，然後開啟指派給主要區域主機集區的已發佈桌面或遠端桌面應用程式應用程式。

2. FSLogix 會擷取使用者配置檔和 Office 容器，然後從主要區域中的記憶體帳戶掛接基礎記憶體 VHD/X。

3. 同時，雲端快取元件會初始化主要區域檔案與次要區域中檔案之間的複寫。 在此程式中，主要區域中的雲端快取會取得這些檔案的獨佔讀寫鎖定。

4. 相同的虛擬桌面用戶現在想要啟動次要區域主機集區上指派的另一個已發佈應用程式。

5. 在次要區域中虛擬桌面會話主機上執行的 FSLogix 元件會嘗試從本機記憶體帳戶掛接使用者配置檔 VHD/X 檔案。 但是掛接失敗，因為這些檔案是由主要區域中虛擬桌面會話主機上執行的雲端快取元件鎖定。

6. 在預設的 FSLogix 和 Cloud Cache 組態中，用戶無法登入，而且會在 FSLogix 診斷記錄中追蹤錯誤，ERROR_LOCK_VIOLATION 33 （0x21）。

   

身分識別

虛擬桌面最重要的相依性之一是使用者身分識別的可用性。 若要從會話主機存取完整的遠端桌面和遠端應用程式，您的使用者必須能夠進行驗證。 Microsoft Entra ID 是 Microsoft 提供此功能的集中式雲端識別服務。 Microsoft Entra 識別碼一律用來驗證虛擬桌面的使用者。 會話主機可以加入相同的Microsoft Entra 租使用者，或使用 Active Directory 網域服務 或 Microsoft Entra Domain Services 的 Active Directory 網域，為您提供彈性組態選項的選擇。

• Microsoft Entra ID

  • 它是具有高可用性的全域多區域和復原性服務。 此內容中不需要採取任何其他動作作為虛擬桌面 BCDR 計劃的一部分。

• Active Directory 網域服務

  • 若要讓 Active Directory 網域服務 具有復原性和高可用性，即使發生全區域災害，您也應該在主要 Azure 區域中部署至少兩個域控制器（DC）。 如果可能的話，這些域控制器應該位於不同的可用性區域中，您應該確保使用次要區域中的基礎結構和最終內部部署的適當複寫。 您應該在次要區域中建立至少一個具有全域編錄和 DNS 角色的域控制器。 如需詳細資訊，請參閱在 Azure 虛擬網路中部署 Active Directory 網域服務 （AD DS）。

• Microsoft Entra Connect

  • 如果您使用 Microsoft Entra ID 搭配 Active Directory 網域服務，然後Microsoft Entra Connect 來同步處理 Active Directory 網域服務 與 Microsoft Entra ID 之間的使用者身分識別數據，您應該考慮此服務的復原和復原，以保護永久災害。

  • 您可以在次要區域中安裝服務的第二個實例，並啟用 預備模式，以提供高可用性和災害復原。

  • 如果有復原，系統管理員必須將其從預備模式中取出來升級次要實例。 它們必須遵循與將伺服器置於預備模式相同的程式。 Microsoft Entra 全域管理員認證，才能執行此設定。

    

• Microsoft Entra Domain Services

  • 在某些情況下，您可以使用 Microsoft Entra Domain Services 做為 Active Directory 網域服務 的替代方案。
  • 其提供 高可用性。
  • 如果您的案例範圍中有異地災害復原，您應該使用副本集，在次要 Azure 區域中部署另一個複本。 您也可以使用這項功能來增加主要區域中的高可用性。

架構圖表

個人主機集區

下載此架構的 Visio 檔案。

集區主機集區

下載此架構的 Visio 檔案。

容錯移轉和容錯回復

個人主機集區案例

個人主機集區的故障轉移和容錯回復不同，因為沒有用於配置檔和 Office 容器的雲端快取和外部記憶體。 您仍然可以使用 FSLogix 技術，從會話主機將數據儲存在容器中。 災害復原區域中沒有次要主機集區，因此不需要建立更多工作區和虛擬桌面資源來復寫和對齊。 您可以使用 Site Recovery 來復寫工作階段主機 VM。

您可以在數個不同的案例中使用 Site Recovery。 針對虛擬桌面，請使用 Azure Site Recovery 中的 Azure 至 Azure 災害復原架構。

適用下列考慮和建議：

• Site Recovery 故障轉移不是自動的—系統管理員必須使用 Azure 入口網站 或 Powershell/API 來觸發它。
• 您可以使用PowerShell編寫整個 Site Recovery 設定和作業的腳本並自動化。
• Site Recovery 在其 服務等級協定 （SLA） 內已宣告 RTO。 大部分情況下，Site Recovery 可以在幾分鐘內故障轉移 VM。
• 您可以使用 Site Recovery 搭配 Azure 備份。 如需詳細資訊，請參閱搭配 Azure 備份 使用 Site Recovery 的支援。
• 您必須在 VM 層級啟用 Site Recovery，因為虛擬桌面入口網站體驗中沒有直接整合。 您也必須在單一 VM 層級觸發故障轉移和容錯回復。
• Site Recovery 在一般 Azure VM 的個別子網中提供測試故障轉移功能。 請勿將此功能用於虛擬桌面 VM，因為您會有兩個相同的虛擬桌面會話主機同時呼叫服務控制平面。
• Site Recovery 不會在復寫期間維護虛擬機擴充功能。 如果您為虛擬桌面會話主機 VM 啟用任何自定義擴充功能，則必須在故障轉移或容錯回復之後重新啟用擴充功能。 虛擬桌面內建擴充 功能 joindomain 和 Microsoft.PowerShell.DSC 只會在建立會話主機 VM 時使用。 在第一次故障轉移之後，可以放心地遺失它們。
• 請務必檢閱 Azure 區域 之間的 Azure VM 災害復原支援矩陣，並檢查 Site Recovery Azure 到 Azure 災害復原案例的需求、限制和相容性矩陣，特別是支援的 OS 版本。
• 當您將 VM 從一個區域故障轉移到另一個區域時，VM 會以未受保護的狀態啟動目標災害復原區域。 可能會進行容錯回復，但用戶必須 重新保護 次要區域中的 VM，然後啟用複寫回到主要區域。
• 執行故障轉移和容錯回復程式的定期測試。 然後，根據您的特定虛擬桌面環境，記錄步驟和復原動作的確切清單。

集區主機集區案例

主動-主動災害復原模式的其中一個所需特性是，如果發生中斷，則不需要系統管理員介入來復原服務。 只有在主動-被動架構中才需要故障轉移程式。

在主動-被動模型中，次要災害復原區域應該處於閑置狀態，且設定最少的資源和作用中。 設定應該與主要區域保持一致。 如果有故障轉移，則會同時將所有使用者重新指派給次要災害復原主機集區中遠端應用程式的所有桌面和應用程式群組。

可以有主動-主動模型和部分故障轉移。 如果主機集區只用來提供桌面和應用程式群組，則您可以在多個非重疊的 Active Directory 群組中分割使用者，並將群組重新指派給主要或次要災害復原主機集區中的桌面和應用程式群組。 用戶不應該同時存取這兩個主機集區。 如果有多個應用程式群組和應用程式，您用來指派使用者的使用者群組可能會重疊。 在此情況下，很難實作主動-主動策略。 每當用戶啟動主要主機集區中的遠端應用程式時，會話主機 VM 上的 FSLogix 就會載入使用者配置檔。 嘗試在次要主機集區上執行相同動作，可能會導致基礎配置檔磁碟發生衝突。

以下是初始情況和設定假設：

• 主要區域和次要災害復原區域中的主機集區會在設定期間對齊，包括雲端快取。
• 在主機集區中，DAG1 桌面和 APPG2 和 APPG3 遠端應用程式應用程式群組都會提供給使用者。
• 在主要區域的主機集區中，Active Directory 使用者群組 GRP1、GRP2 和 GRP3 是用來將使用者指派給 DAG1、APPG2 和 APPG3。 這些群組可能會有重疊的使用者成員資格，但因為這裡的模型使用主動-被動搭配完整故障轉移，所以這不是問題。

下列步驟說明故障轉移何時在計劃性或非計劃性災害復原之後發生。

1. 在主要主機集區中，針對應用程式群組 DAG1、APPG2 和 APPG3，移除 GRP1、GRP2 和 GRP3 群組的使用者指派。
2. 主要主機集區中的所有已連線使用者都有強制中斷連線。
3. 在設定相同應用程式群組的次要主機集區中，您必須使用群組 GRP1、GRP2 和 GRP3，將 DAG1、APPG2 和 APPG3 的存取權授與使用者存取權。
4. 檢閱並調整次要區域中主機集區的容量。 在這裡，您可能想要依賴自動調整計劃來自動開啟會話主機電源。 您也可以手動啟動必要的資源。

容錯回復步驟和流程很類似，而且您可以多次執行整個進程。 雲端快取和設定記憶體帳戶可確保配置檔和 Office 容器數據會複寫。 容錯回復之前，請確定已復原主機集區組態和計算資源。 針對記憶體部分，如果主要區域發生數據遺失，雲端快取會從次要區域記憶體複寫配置檔和 Office 容器數據。

您也可以使用一些設定變更來實作測試故障轉移計劃，而不會影響生產環境。

• 在 Active Directory 中為生產環境建立一些新的用戶帳戶。
• 建立名為 GRP-TEST 的新 Active Directory 群組，並指派使用者。
• 使用 GRP-TEST 群組指派 DAG1、APPG2 和 APPG3 的存取權。
• 將指示提供給 GRP-TEST 群組中的使用者，以測試應用程式。
• 使用 GRP-TEST 群組從主要主機集區移除存取權，並授與次要災害復原集區的存取權，以測試故障轉移程式。

重要建議：

• 使用 PowerShell、Azure CLI 或其他可用的 API 或工具，將故障轉移程式自動化。
• 定期測試整個故障轉移和容錯回復程式。
• 進行一般設定對齊檢查，以確保主要和次要災害區域中的主機集區同步。

Backup

本指南中的假設是配置檔容器與 Office 容器之間有配置檔分割和數據區隔。 FSLogix 允許此設定和使用個別的記憶體帳戶。 在不同的記憶體帳戶中，您可以使用不同的備份原則。

• 若為 ODFC 容器，如果內容只代表只能從在線數據存放區重建的快取數據，例如 Microsoft 365，就不需要備份數據。

• 如果需要備份 Office 容器數據，您可以使用成本較低的記憶體或不同的備份頻率和保留期間。

• 針對個人主機集區類型，您應該在會話主機 VM 層級執行備份。 只有在數據儲存在本機時，才適用這個方法。

• 如果您使用 OneDrive 和已知的資料夾重新導向，在容器內儲存資料的需求可能會消失。

  注意

  本文和案例中不會考慮 OneDrive 備份。

• 除非有另一個需求，否則主要區域中記憶體的備份應該就足夠了。 通常不會使用災害復原環境的備份。

• 針對 Azure 檔案儲存體 共用，請使用 Azure 備份。

  • 針對保存庫 復原類型，如果不需要異地或區域備份記憶體，請使用區域備援記憶體。 如果需要這些備份，請使用異地備援記憶體。

• Azure NetApp Files 提供自己的內 建備份解決方案。

  • 請務必檢查區域 功能可用性，以及需求和限制。

• 如果無法輕易重建應用程式套件存放庫，則 MSIX 所使用的個別記憶體帳戶也應該由備份所涵蓋。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

• 本·馬丁·鮑爾 |雲端解決方案架構師
• Igor Pagliai |適用於 Azure 的 FastTrack （FTA） 首席工程師

其他投稿人：

• 納爾遜·德爾維拉爾 |雲端解決方案架構師、Azure Core 基礎結構
• Jason Martinez | 技術手冊撰寫入員

下一步

• 虛擬桌面災害復原計劃
• 適用於虛擬桌面的 BCDR - 雲端採用架構
• 建立復原和可用性的雲端快取

相關資源

• 設計可靠的 Azure 應用程式
• 在內部部署存取並受 AD DS 保護的 Azure 檔案
• 企業虛擬桌面
• 提供災害復原功能的企業檔案共用
• FSLogix 設定範例