本主題將介紹 Horizon Cloud 租用戶的代理轉換程序,以及執行轉換可帶來的好處。請瞭解單一網繭代理與 Universal Broker 環境之間的差異,以及在進行代理轉換之前、期間和之後會發生的情況。
什麼是代理轉換程序?
完成代理轉換後,您的 Horizon Cloud 租用戶環境會從使用單一網繭代理變更為使用 Universal Broker 來代理使用者指派中的資源。作為新的租用戶範圍代理,Universal Broker 會管理使用者的連線要求,並將其路由至所要求指派中的最佳可用資源。
代理轉換程序會對您的使用者指派進行下列變更。
- VDI 桌面指派會轉換為由 Universal Broker 代理的多雲端指派。多雲端指派可包含來自多個網繭的 VDI 桌面。
- 工作階段型桌面和應用程式指派會保持不變。工作階段型桌面或應用程式指派只能包含來自單一網繭的資源,但此時指派會由 Universal Broker 所代理。
如果您的環境目前使用單一網繭代理,且符合Horizon Cloud - 轉換為 Universal Broker 的系統需求中說明的先決條件,則適用轉換功能。
為何要轉換為 Universal Broker?
轉換為使用 Universal Broker (VMware 最新的雲端式代理技術) 後,將可獲得下列幾項主要好處。
- 使用者指派可包含來自多個網繭的 VDI 桌面
-
使用單一網繭代理時,VDI 指派中的所有桌面必須來自相同的網繭。桌面代理是針對個別的網繭來完成的。
透過 Universal Broker,您可以建立來自多個網繭的 VDI 桌面指派,也稱為多雲端指派。使用者可從該指派中包含的任何網繭存取指派及接收桌面。如需詳細資訊,請參閱VMware Horizon Service Universal Broker 簡介及其副主題。
您也可以像往常一樣繼續使用工作階段型桌面和應用程式指派。不同之處在於,這些指派中的工作階段型桌面和應用程式將會由 Universal Broker 代理,而非個別的網繭代理。
- 所有遠端資源均適用的單一連線 FQDN
-
使用單一網繭代理時,使用者必須分別連線至每個網繭的完整網域名稱 (FQDN),才能存取來自該網繭的指派。代理是針對個別的網繭來完成的。
使用 Universal Broker 時,使用者只需連線至一個 FQDN (如您在 Universal Broker 組態設定中所定義) 即可存取所有指派。透過單一 FQDN,使用者可從環境中的任何站台,存取所有參與網繭中的指派 (包括 Microsoft Azure 中的 Horizon Cloud Pod 和 VMware SDDC 型平台上的 Horizon 網繭)。您的網繭之間不需要內部網路功能。
- 可達到最佳效能的全域網繭連線與感知
- Universal Broker與參與多雲端指派的每個網繭保持直接連線,並留意每個網繭的可用性狀態。因此, Universal Broker 可以管理使用者的連線要求,並直接從這些網繭將其路由至虛擬資源。不需要全域伺服器負載平衡 (GSLB),或任何可能會導致效能降低和延遲問題的網繭間網路通訊。
- 智慧型代理
- Universal Broker 會根據地理站台和網繭拓撲的感知,以最短的網路路由,將來自指派的資源代理給使用者。
是否有任何不進行轉換的原因?
此版本的 Universal Broker 具有一些功能限制。如果您的使用案例需要使用 Universal Broker 不支援的功能,則應考慮讓租用戶環境維持使用單一網繭代理,直到 Universal Broker 支援該功能為止。如需目前的 Universal Broker 限制清單,請參閱Universal Broker - 功能考量事項和已知限制。
在代理轉換期間會發生什麼情況?
轉換工作流程包含幾個階段。如需執行轉換的詳細逐步指示,請參閱排程並完成從單一網繭代理轉換為 Universal Broker 的作業。
以下提供轉換之前和期間所執行程序的高階概觀。
- 若要起始工作流程,您必須先排程執行轉換的日期和時間。除了這項排程工作,請定義轉換期間用來設定 Universal Broker 服務的組態選項。
- 排程的開始時間之前的 15 分鐘以內,在主控台中完成所有進行中的作業,並儲存您想要保留的任何變更。關閉所有組態精靈和對話方塊。此外,確保您在 Microsoft Azure 中的所有網繭都處於線上、健全狀況良好且為就緒狀態。
- 在轉換即將開始時,系統會提示您先登出主控台再重新登入。
- 在轉換的第一個階段期間,預期會發生下列情況:
- 您無法存取主控台的任何編輯控制項,且主控台會顯示一個橫幅,指出轉換正在進行中。
- 您在 Microsoft Azure 中的所有網繭都會新增至名為 Default-Site 的站台。
- 您的 VDI 桌面指派會轉換為由 Universal Broker 代理的多雲端指派。在預設指派設定中,連線相似性會設定為最接近的站台,而範圍會設定為站台內。
- 您的工作階段型桌面和應用程式指派會保持不變。轉換後,這些指派中的資源將會由 Universal Broker 代理。
- 在此期間,所有指派仍可供使用者使用,且所有作用中使用者工作階段仍會保持開啟且正常運作。
備註: 此轉換階段通常需執行約 10 分鐘,但如果您的租用戶環境包含大量指派,則最多可能需要 1 小時。此轉換階段完成時,系統會提示您先登出主控台再重新登入。
- 在轉換的第二個階段中,Universal Broker 服務會完成其設定程序並完全啟用。您可以在主控台中存取所有編輯作業,但建立和編輯指派除外。
備註: 此轉換階段通常會在 30 分鐘內完成。不過,根據您的系統與網路條件,以及環境中的指派總數和專用的使用者到桌面對應,此階段可能需要數小時才能完成。
此轉換階段完成後,已啟用狀態,並出現一個綠點。
頁面會顯示此時,整個代理轉換程序即告完成。
代理轉換之後預期會發生什麼情況?
如需代理轉換之後對租用戶環境所做變更的詳細清單,請參閱您的租用戶環境在轉換為 Universal Broker 之後的新功能。
完成轉換後,您即可開始運用 Universal Broker 環境所提供優勢。下面清單可讓您一睹後續動作,並提供指向詳細頁面的連結。
- 修改站台和多雲端 VDI 指派設定,以充分利用 Universal Broker 功能。例如,您可以將更多網繭新增至現有的指派,或調整站台設定以微調 Universal Broker 將資源配置給使用者的方式。如需詳細資訊,請參閱在 Universal Broker 環境中建立及管理指派和在 Universal Broker環境中使用站台。
- 如果您的 Horizon Cloud 租用戶與 Workspace ONE Access 之間有現有的整合,則必須更新該整合以利使用 Universal Broker。如需完整指示,請參閱Horizon Cloud 環境與 Universal Broker - 整合租用戶與 Workspace ONE Access 和 Intelligent Hub 服務。
備註: 經 VMware Workspace ONE Access 產品團隊確認,將 Universal Broker 與 Horizon Cloud on Microsoft Azure 部署搭配使用時,該組態不支援 VMware Workspace ONE Access 產品的「虛擬應用程式集合」功能。這是因為, Universal Broker 是比舊式每一網繭代理更新的代理技術,這表示 Universal Broker 與 Workspace ONE Access 的整合將不再需要對 Horizon Cloud on Microsoft Azure 部署使用舊版每一網繭的虛擬應用程式集合。因此, Universal Broker 根本沒有對 Horizon Cloud on Microsoft Azure 部署使用虛擬應用程式集合的概念,從而導致不支援將虛擬應用程式集合用於 Universal Broker 和 Horizon Cloud on Microsoft Azure 組態。
如果為 Horizon Cloud on Microsoft Azure 部署設定了 Universal Broker,且您計劃將 Workspace ONE Access 和 Intelligent Hub 服務與這些 Horizon Cloud on Microsoft Azure 部署搭配使用,則在整合程序期間中,當您在執行主控台的清理動作時,需要清理這些部署可能具有的任何現有「虛擬應用程式集合」。完成清理活動,相同的應用程式將透過使用整合的 Universal Broker 以及 Workspace ONE Access 和 Intelligent Hub 服務的新功能,繼續在 Workspace ONE Access 和 Intelligent Hub 服務中執行。
Horizon Cloud - 轉換為 Universal Broker 的系統需求
本文說明您的 Horizon Cloud 租用戶環境必須符合哪些需求,您才能排程及完成租用戶從使用單一網繭代理到使用 Universal Broker 的轉換。此外也會引導您完成為 Universal Broker 支援新連線 FQDN 的規劃和準備步驟。
若要支援轉換程序,以及轉換完成後由 Universal Broker 所代理多雲端指派的進行中作業,請確認您的租用戶環境符合下列需求。
- 除非您的 Horizon Cloud Pod 符合租用戶環境中「最低網繭資訊清單」和「啟用 RSA SecurID 選項」的準則,否則這些網繭僅支援 RADIUS 驗證。(如需詳細資訊,請參閱在 Universal Broker 環境中實作雙因素驗證時的最佳做法。)
- 當 Horizon Cloud Pod 不符合在其外部閘道上設定 RSA SecurID 的準則時,如果您想對機群中的所有網繭 (Horizon 網繭和 Horizon Cloud Pod) 使用雙因素驗證,則每個網繭必須具有一個外部 Unified Access Gateway,並在該閘道上設定 RADIUS 雙因素驗證。
Horizon Cloud Pod 的需求
確認 Microsoft Azure 中的 Horizon Cloud Pod 符合下列需求。
- 您的租用戶至少有一個 Horizon Cloud Pod。Horizon Cloud Pod 以在 Microsoft Azure 中執行的網繭管理員技術為基礎。
- 您租用戶的所有 Horizon Cloud Pod 皆執行網繭資訊清單 2298.0 或更新版本。下列需求也適用特定使用案例。
- 如果您的 Horizon Cloud 租用戶與 Workspace ONE Access 之間有現有的整合,則所有網繭都必須執行資訊清單 2474.0 或更新版本。完成代理轉換後,您必須更新整合以便使用 Universal Broker,如Horizon Cloud 環境與 Universal Broker - 整合租用戶與 Workspace ONE Access 和 Intelligent Hub 服務中所述。
- 如果您在代理轉換完成後想要使用工作取消功能或刪除保護功能,您所有的 Horizon Cloud Pod 皆必須執行資訊清單 2474.0 或更新版本。如果您的網繭執行早於資訊清單 2474.0 的版本,則不支援這些功能。
重要: 確保您的所有 Horizon Cloud Pod 都處於線上、健全狀況良好且為就緒狀態。 Universal Broker 服務必須與那些網繭通訊,並在網繭上執行某些組態步驟,才能完成轉換程序。如果其中有任何網繭離線或無法使用,您將無法排程轉換。如果您排程轉換,但有任何網繭稍後在轉換進行期間離線或變得無法使用,則 Universal Broker 設定將會失敗。 - 轉換期間不會排程任何同時執行的網繭升級。
- 網繭的位置是透過在網繭組態精靈的功能表選項中選取有效位置來設定。如果藉由在文字欄位中手動輸入位置,來設定網繭位置,則轉換將會失敗。
備註: 如果網繭是在 2019 年 3 月 (服務版本 1.9) 之前初次部署,可能會出現這種涉及手動輸入位置的問題。從 2019 年 3 月版本開始,必須使用功能表,從系統的全球城市名稱資料庫內的值中選取位置。
若要降低因設定給網繭的位置而導致轉換失敗的可能性,請導覽至主控台的 [容量] 頁面,然後檢查每個 Horizon Cloud Pod 的 [位置] 資料行的值。如果 [位置] 資料行的值看似手動輸入的名稱,請使用網繭上的編輯動作,移至網繭詳細資料步驟,然後編輯位置欄位,將其值設定為系統的某個城市名稱值。
- 在轉換工作流程期間,如果您的租用戶尚未從網繭機群中的任何 Horizon 網繭進行 Universal Broker 設定,則主控台將提示您進行 Universal Broker 設定。當您計劃在 Universal Broker 設定中設定雙因素驗證設定時,每個網繭必須具有一個外部 Unified Access Gateway 執行個體,且必須為該執行個體設定適當的雙因素驗證類型。(如需背景相關資訊,請參閱在 Universal Broker 環境中實作雙因素驗證時的最佳做法。)
這些需求取決於您的 Horizon Cloud Pod 是否符合在其外部閘道上設定 RSA SecurID 類型的準則:
- 如果您的 Horizon Cloud Pod 符合租用戶環境中「最低網繭資訊清單」和「啟用 RSA SecurID 選項」的準則,則需要將所有網繭中的所有外部 Unified Access Gateway 執行個體設定成使用相同的驗證服務。這包括處於受管理狀態的所有租用戶的 Horizon 網繭。最終的結果是讓所有執行個體使用的驗證類型都一致:全都使用 RADIUS,或全都使用 RSA SecurID。
- 當 Horizon Cloud Pod 不符合在其外部閘道上設定 RSA SecurID 的準則時,如果您想對機群中的所有網繭 (Horizon 網繭和 Horizon Cloud Pod) 使用雙因素驗證,則必須將所有網繭中的所有外部 Unified Access Gateway 執行個體設定成使用相同的 RADIUS 驗證服務。這包括處於受管理狀態的所有租用戶的 Horizon 網繭。
支援 Universal Broker 的 DNS、連接埠和通訊協定需求
確認下列需求。
- 每個網繭皆已適當設定,讓您的區域 Universal Broker執行個體所需的 DNS 名稱可供見解且可連線。請參閱 Microsoft Azure 中 Horizon Cloud Pod 的 DNS 需求中的「網繭部署和作業 DNS 需求」表格。
- 每個網繭皆設定了所需的連接埠和通訊協定,如 Horizon Cloud Pod 的連接埠和通訊協定需求 (2019 年 9 月版本的資訊清單或更新版本) 中的〈Universal Broker 所需的連接埠和通訊協定〉一節中所述。
支援 Universal Broker 的 FQDN 需求
使用單一網繭代理時,使用者必須分別連線至每個網繭的完整網域名稱 (FQDN),才能存取來自該網繭的指派。
轉換為 Universal Broker 之後,使用者只要連線至 Universal Broker 雲端服務的一個 FQDN,即可從您環境內任何站台中的任何網繭存取任何指派。Universal Broker 會將每個使用者要求路由至最可能滿足要求之網繭的個別 FQDN。
您可以在 Universal Broker 組態設定中指定 Universal Broker FQDN,如排程並完成從單一網繭代理轉換為 Universal Broker 的作業中所述。您可以在標準 VMware 提供的網域前面附加有效的子網域以建立 FQDN,也可以設定完全自訂的 FQDN。
規劃和準備代理轉換
由於代理轉換涉及對網路和指派工作流程進行重要變更,請務必採取必要的動作,為環境和使用者準備新的工作流程。請參閱下列規劃指南,以根據您的轉換使用案例進行適當的準備和變更管理步驟。
轉換使用案例 | 規劃和準備步驟 |
---|---|
您的環境包含單一網繭,且您想要使用該網繭的現有 FQDN 作為 Universal Broker FQDN |
|
您的環境包含多個網繭,且您想要將新的 FQDN 設定為 Universal Broker FQDN |
|
排程並完成從單一網繭代理轉換為 Universal Broker 的作業
本主題將引導您完成轉換為 Universal Broker 的排程、準備和執行步驟。請參閱下列程序,以瞭解如何設定 Universal Broker 服務、定義轉換的開始日期和時間,以及順暢地導覽各階段的程序,以成功完成轉換。
在做好排程代理轉換的準備後,Horizon Universal Console 頂端會出現一個含有排程按鈕的通知橫幅。
必要條件
程序
下一步
- 如果您的 Horizon Cloud 租用戶與 Workspace ONE Access 之間有現有的整合,則必須更新該整合以利使用 Universal Broker。如需完整指示,請參閱Horizon Cloud 環境與 Universal Broker - 整合租用戶與 Workspace ONE Access 和 Intelligent Hub 服務。
- 修改站台和多雲端 VDI 指派設定,以充分利用 Universal Broker 功能。例如,您可以將更多網繭新增至現有的指派,或調整站台設定以微調 Universal Broker 代理指派的方式。請參閱在您的 Horizon Cloud 租用戶環境中建立及管理多雲端指派和在 Universal Broker 環境中使用站台。
您的租用戶環境在轉換為 Universal Broker 之後的新功能
本文說明在您成功完成從單一網繭代理轉換為 Universal Broker 的作業後,您在 Horizon Cloud 租用戶環境中預期會看到的變更。變更包含一些新功能行為和一些功能限制。
如需 Universal Broker 環境中關於特定功能限制的詳細資訊,請參閱Universal Broker - 功能考量事項和已知限制。
使用者指派的變更
- 您在 Microsoft Azure 中的所有網繭都會新增至名為 Default-Site 的站台。
- VDI 桌面指派會轉換為由 Universal Broker 代理的多雲端指派。在預設指派設定中,連線相似性會設定為最接近的站台,而範圍會設定為站台內。
備註: 即使指派包含來自多個網繭的桌面,一個特定使用者最多只能從由 Universal Broker 代理的專用指派接收最多一個指派的桌面。重要: 如果使用者先前從單一網繭代理環境中的專用指派接收到多個已指派的桌面,則在轉換為 Universal Broker 環境後,他們將無法存取這些桌面。若要存取已指派的桌面,使用者可以直接連線至網繭的 FQDN,而非使用 Universal Broker FQDN。
- 工作階段型桌面和應用程式指派現在皆由 Universal Broker 代理。
具有相同名稱之桌面集區的變更
如果在代理轉換之前,您的網繭之間有任何桌面集區具有相同名稱,系統會將這些集區編輯為不同的名稱。此變更可確保您能夠將不同網繭中具有唯一名稱的桌面集區新增至 Universal Broker 所代理的單一指派。
例如,假設您在代理轉換之前有下列案例:
- Pod1 包含名為 TestPoolName 的集區。
- Pod2 包含也名為 TestPoolName 的集區。
轉換後,範例集區名稱將變更如下:
- 在 Pod1 中,集區名稱會保持為 TestPoolName。
- 在 Pod2 中,集區會重新命名為 TestPoolName1。
虛擬機器名稱前置詞的變更
在轉換前的單一網繭代理環境中,集區的虛擬機器名稱前置詞最多可以有 11 個可自訂字元。為了形成集區名稱,會在包含 11 個字元的首碼後面附加一個序號 (最多 4 位數)。
轉換為 Universal Broker 後,虛擬機器名稱前置詞最多可包含 9 個可自訂字元。轉換後,任何先前長度超過 9 個字元的虛擬機器名稱前置詞都會自動截斷。
若要在 Universal Broker 環境中形成集區名稱,請在包含 9 個字元的首碼後面附加下列字元:兩個隨機英數字元或字母字元,其後尾隨一個序號 (最多 4 位數)。
如果有多個指派使用相同的虛擬機器名稱前置詞,當您嘗試編輯其中一個指派時,可能會遇到錯誤。若要解決此錯誤,請在編輯精靈中變更指派的虛擬機器名稱前置詞。
轉換後的功能考量事項
轉換為 Universal Broker 後,針對特定功能有下列考量事項。
- 不支援自訂指派 (也稱為 URL 重新導向指派)。
- 如果您的網繭執行早於資訊清單 2474.0 的版本,則不支援工作取消功能。若要使用此功能,您必須將網繭升級至資訊清單 2474.0 或更新版本。
- 如果 Horizon Cloud on Microsoft Azure 部署在現有轉換前已與 Workspace ONE Access 整合,則必須將該整合更新為轉換後狀態以因應 Universal Broker 的使用。如需完整指示,請參閱Horizon Cloud 環境與 Universal Broker - 整合租用戶與 Workspace ONE Access 和 Intelligent Hub 服務。
請注意,在更新該整合時,您必須使用 Horizon Universal Console 清理工作流程來清理這些部署可能具有的任何現有虛擬應用程式集合。清理工作流程將使相同的應用程式透過使用整合的 Universal Broker 以及 Workspace ONE Access 和 Intelligent Hub 服務的新功能 (非舊版、每一網繭虛擬應用程式集合功能),繼續在 Workspace ONE Access 和 Intelligent Hub 服務中執行。經 VMware Workspace ONE Access 產品團隊確認,將 Universal Broker 與 Horizon Cloud on Microsoft Azure 部署搭配使用時,該組態不支援 VMware Workspace ONE Access 產品的「虛擬應用程式集合」功能。這是因為,Universal Broker 是比舊式每一網繭代理更新的代理技術,這表示 Universal Broker 與 Workspace ONE Access 的整合將不再需要使用舊版每一網繭虛擬應用程式集合。因此,Universal Broker 根本沒有對 Horizon Cloud on Microsoft Azure 部署使用虛擬應用程式集合的概念。
例如,如果您的網繭執行早於資訊清單 2474.0 的版本,且在轉換前已啟用刪除保護功能,則該功能在轉換後將會停止運作。如果您後續將網繭升級至資訊清單 2474.0 或更新版本,則刪除保護功能便會重新恢復運作。