使用 Cloud Pod 架構功能可將多個網繭連結在一起，形成單一的大型桌面平台和應用程式代理與管理環境。
網繭由一組連線伺服器執行個體、共用儲存區、一個資料庫伺服器，以及主控桌面平台和應用程式集區所需的 vSphere 與網路基礎結構所組成。在傳統的 Horizon 8 部署中，您需要獨立管理每個網繭。透過 Cloud Pod 架構功能，您可以將多個網繭組合成單一的 Horizon 8 部署，稱為「網繭聯盟」。
網繭聯盟可橫跨多個站台與資料中心，同時簡化管理大型 Horizon 8 部署所需的管理作業。
下圖為基本 Cloud Pod 架構拓撲的範例。
在拓撲範例中，先前在不同資料中心的兩個獨立網繭聯結在一起，形成單一網繭聯盟。此環境中的使用者可連線至紐約網繭，並接收任一網繭中的桌面平台或應用程式。
當 Cloud Pod 架構搭配 Unified Access Gateway 應用裝置使用時，每個應用裝置都必須關聯至單一網繭。
Cloud Pod 架構的主要元件
Cloud Pod 架構由少數幾個元件構成，這些元件相互協作，使多個獨立網繭能如同單一系統般運作。
| 元件 | 元件說明 | 主要功能 |
|---|---|---|
| 網繭 | 一組連線伺服器執行個體、共用儲存區、資料庫伺服器，以及託管桌面平台和應用程式集區所需的 vSphere/網路基礎結構。 | 為連線至該網繭的使用者託管及代理桌面平台和應用程式。 |
| 網繭聯盟 | 使用 Cloud Pod 架構功能加入在一起的兩個以上網繭。 | 將已加入的網繭呈現為單一邏輯代理環境。 |
| 全域資料層 | 在網繭聯盟中的每個連線伺服器執行個體上執行的另一個複寫 LDAP 執行個體。 | 在整個網繭聯盟中儲存及複寫拓撲、全域權利、主站台、聯盟存取群組和原則。 |
| VIPA (View 網繭間 API) | 以 HTTPS 為基礎的網繭間通訊通道。 | 即時網繭對網繭通訊：在遠端網繭上啟動工作階段、尋找現有工作階段，以及交換健全狀況狀態。 |
| 站台 | 由網路連線良好的多個網繭所組成，通常位於同一個資料中心，且 Cloud Pod 架構將這些網繭視為同等地位。 | 建立網路鄰近性模型，讓代理功能可優先選擇鄰近資源，而非透過較慢 WAN 連結存取的資源。 |
| 全域權利 | 一個具名物件，可將使用者或群組連結至聯盟中任何位置的桌面平台或應用程式集區，並包含用於控制資源尋找及配置方式的原則。 | 使用者在 Horizon Client 中實際看到並選取的項目。 |
| 主站台 | 使用者或群組 (或使用者/群組與特定全域權利) 與站台之間的選用關聯。 | 錨定資源搜尋的起始位置，而不受使用者透過哪個網繭連線影響。 |
Cloud Pod 架構與傳統 Horizon 8 部署的差異
在傳統的非聯盟式 Horizon 8 部署中，每個網繭都是獨立運作的封閉環境：各自具有連線伺服器執行個體和本機權利，且彼此之間無法感知其他網繭的存在。連線至網繭 A 的使用者，只能代理至實際存在於網繭 A 中的桌面平台或應用程式。
Cloud Pod 架構透過下列三種方式改變此運作模式：
- **權利由本機權利改為全域權利。**您可以將全域權利授與使用者或群組，而該全域權利可由聯盟中任何網繭的集區提供資源，不再僅限於特定連線伺服器執行個體上的集區。
- **代理功能由網繭本機改為可感知聯盟。**使用者所連線的連線伺服器執行個體 (連線網繭，也稱為代理網繭) 可使用 VIPA 查詢其他網繭是否有相符的資源，查詢順序由全域權利的範圍原則和使用者的主站台控制。
- **組態和狀態由各自獨立改為共用。**拓撲、權利和主站台儲存在全域資料層中，且每個網繭都可存取這些資訊。同樣地，工作階段和健全狀況資訊也可在 Horizon Console 中跨整個網繭聯盟檢視。(例外：Horizon 8 事件資料庫不會在網繭之間共用。)
不變的是：每個桌面平台或應用程式集區仍只會實際存在於一個網繭中，而且每個網繭仍可完全獨立運作。Cloud Pod 架構是建構於現有網繭之上的代理與管理層，而不是用來取代這些網繭。
此頁面對您有幫助嗎?