Skip to main content

2026 年 9 月 9 日

Cloud Pod 架构环境中的端到端用户连接工作流

前面的主题分别介绍了 Cloud Pod 架构的各个组成部分。本主题将逐步介绍从最终用户连接那一刻起,直到他们看到远程桌面或已发布的应用程序为止,实际发生的整个过程。

  1. 用户启动 Horizon Client(或浏览器)并连接到服务器 URL。该 URL 可以是特定 Unified Access Gateway 或连接服务器实例的地址,也可以是负载均衡器或 DNS 服务解析为最近 Pod 的单个 DNS 名称。客户端先访问的连接服务器实例在本指南的其他位置称为连接 Pod 或代理 Pod。
  2. 用户进行身份验证。身份验证将针对连接 Pod 进行,可使用 Active Directory 凭据,或者,如果启用了 Workspace ONE 模式,则将先被重定向到通过 Omnissa Access 的登录页面。配置为未验证访问的用户在进行应用授权时可跳过此步骤。
  3. 连接 Pod 解析全局数据层中的用户授权。由于全局授权是复制的数据,因此,连接 Pod 不需要联系任何其他 Pod 即可获知用户(直接或通过组成员资格)属于哪些全局桌面和应用程序授权。此时,还会评估连接服务器限制策略和客户端限制策略:在客户端看到授权之前,标记与连接连接服务器实例的标记不匹配的授权,或者其客户端限制组不包含用户设备的授权,均会从授权列表中筛选掉。
  4. Horizon Client 向用户显示剩余的全局授权以及任何配置的快捷方式。用户选择其中一项。
  5. 连接 Pod 确定从何处开始查找资源。如果全局授权已启用“使用主站点”,则搜索从该用户的主站点开始 — 即用户自己的全局主站点或按授权的主站点覆盖(如果已配置),后者优先。如果没有适用的主站点,则搜索从用户当前连接到的站点开始。
  6. 连接 Pod 应用全局授权的范围策略,以确定允许搜索从该起点向外扩展的范围:仅限连接 Pod(Pod 内/“本地”)、同一站点中的任何 Pod(站点内/“站点”)或整个联合中的任何 Pod(所有站点/“任意”)。
  7. 搜索本身首先在本地运行,然后向外扩展。如果本地 Pod 中存在具有可用容量的匹配桌面或应用程序池,则使用该池。否则,连接 Pod 会使用 VIPA 按优先顺序(先是本地站点的其余部分,然后其他站点)以逐步扩大的范围查询对等连接服务器实例,直至找到资源或用尽允许的范围为止。如果配置了会话负载分配策略(“负载指数”、“会话计数”或“无”),搜索将根据该策略选取负载最少的 Pod 内负载最少的池或场。
  8. 对于专用桌面授权,这个搜索和分配序列每个用户仅执行一次。首次分配特定桌面后,后续的每次连接 — 无论来自此站点、另一个站点还是其他设备 — 都会绕过范围/主站点搜索,而直接代理回该同一桌面。浮动授权在每次连接时都会重复完整的搜索过程。
  9. 拥有所选资源的 Pod 准备会话(将虚拟机打开电源或解除锁定,或者接受新的 RDS 会话),并且连接 Pod 将连接详细信息中继回 Horizon Client。
  10. Horizon Client 直接针对拥有资源的 Pod 打开显示协议会话(Blast 或 PCoIP,具体取决于授权的协议策略)— 通常通过与该 Pod 配对的 Unified Access Gateway 设备进行,该设备可能与用户在步骤 1 中首次连接时所用的设备相同,也可能不同。
  11. 新会话被记录回全局数据层,这就是为什么它会在任何 Pod 上的 Horizon Console 中立即可见,并标记有用户、托管 Pod、代理 Pod 和站点。
  12. 如果用户断开连接并稍后重新连接,则连接 Pod 在开始新搜索之前,会先检查全局数据层,以查找联合中任何位置的现有会话,如果找到则将用户重新连接到该会话。可能仍会出现多个会话(例如,如果托管会话的 Pod 脱机,用户在其他地方启动了一个新会话),在这种情况下,Horizon Client 会提示用户选择会话,而“自动清理冗余会话”策略决定是自动清理用户未选择的会话,还是将其保留以供手动注销。
  13. 如果启用了主站点重定向,则连接到其指定主站点以外站点的用户会被透明地重定向到其主站点的 URL,而无需通过 Unified Access Gateway 重新进行身份验证,因而可减少回传流量。

示例:如何设置基本 Cloud Pod 架构配置中的健康保险销售代理场景使用具体的 Pod、站点和授权名称演示了这一操作序列,是上述步骤的有益补充。

此页面对您有帮助吗?

对本主题提供反馈

本主题对您有帮助吗?

请勿填写任何个人信息或机密信息。

正在生成链接…