使用 Cloud Pod 架构功能，可以将多个 Pod 链接在一起，以提供单个大型桌面与应用程序代理和管理环境。
一个 Pod 包含一组托管桌面和应用程序池所需的连接服务器实例、共享存储、数据库服务器以及 vSphere 和网络基础架构。在传统的 Horizon 8 实施中，您可以单独管理每个 Pod。使用 Cloud Pod 架构功能，可以将多个 Pod 连接在一起，以形成单个名为 Pod 联合的 Horizon 8 实施。
Pod 联合可跨多个站点和数据中心，同时还可简化管理大规模 Horizon 8 部署所需的管理工作。
下图是一个基本 Cloud Pod 架构拓扑的示例。
在示例拓扑中，不同数据中心内以前独立的两个 Pod 连接到一起，组成了单个 Pod 联合。此环境中的最终用户可以连接到纽约 Pod，并接收任一 Pod 中的桌面或应用程序。
将 Cloud Pod 架构与 Unified Access Gateway 设备配合使用时，每个设备必须与单个 Pod 相关联。
Cloud Pod 架构的关键组件
Cloud Pod 架构由少量组件构成，这些组件协同工作，使多个独立的 Pod 表现得如同一个系统。
| 组件 | 说明 | 职责 |
|---|---|---|
| Pod | 一组托管桌面和应用程序池所需的连接服务器实例、共享存储、数据库服务器以及 vSphere /网络基础架构。 | 为与其连接的用户托管和代理桌面和应用程序。 |
| Pod 联合 | 使用 Cloud Pod 架构功能连接在一起的两个或更多 Pod。 | 将连接的 Pod 呈现为单个逻辑代理环境。 |
| 全局数据层 | 第二个副本 LDAP 实例，在 Pod 联合中的每个连接服务器实例上运行。 | 在 Pod 联合范围内存储和复制拓扑、全局授权、主站点、联合访问组和策略。 |
| VIPA (View InterPod API) | 基于 HTTPS 的 Pod 间通信通道。 | Pod 到 Pod 的实时通信：在远程 Pod 上启动会话、查找现有会话，以及交换运行状况。 |
| 站点 | 一组连接良好的 Pod，通常位于一个数据中心内，被 Cloud Pod 架构视为同等 Pod。 | 对网络区域进行建模，以便代理可以优先使用附近的资源，而非通过慢速 WAN 链路访问的资源。 |
| 全局授权 | 将用户或组与联合中任意位置的桌面池或应用程序池相关联的命名对象，以及控制资源查找和分配方式的策略。 | 用户在 Horizon Client 中实际看到并选择的内容。 |
| 主站点 | 用户或组（或者用户/组和特定全局授权）与站点之间的可选关系。 | 定位开始搜索资源的位置，而不考虑用户通过哪个 Pod 进行连接。 |
Cloud Pod 架构与传统 Horizon 8 部署有何不同
在传统的非联合 Horizon 8 部署中，每个 Pod 都是一个独立的孤岛：它拥有自己的连接服务器实例和本地授权，并且对其他任何 Pod 一无所知。连接到 Pod A 的用户只能通过代理访问 Pod A 中实际存在的桌面或应用程序。
Cloud Pod 架构从以下三个方面改变了这一状况：
- **授权从本地变为全局。**您可以授权用户或组使用可由联合内任何 Pod 中池提供支持的全局授权，而不是某个特定连接服务器实例上的池。
- **代理从 Pod 本地变为联合感知。**用户连接到的连接服务器实例（连接 Pod，也称为代理 Pod）可以使用 VIPA，按照由全局授权范围策略和用户主站点控制的顺序，询问其他 Pod 是否有匹配的资源。
- **配置和状态从孤立变为共享。**拓扑、授权和主站点位于全局数据层中，并且可从每个 Pod 中查看。同样，可在 Horizon Console 中查看 Pod 联合范围的会话和运行状况信息。（例外：Horizon 8 事件数据库未在 Pod 间共享。）
不变的部分：每个桌面或应用程序池在物理上仍仅存在于一个 Pod 中，并且每个 Pod 仍然完全能够独立运行。Cloud Pod 架构是在现有 Pod 之上构建的代理和管理层，而不是取代它们。
此页面对您有帮助吗?