设计

设计桌面虚拟化解决方案只是遵循经过验证的流程,并根据组织和用户要求调整技术决策。如果没有标准化和经过验证的过程,架构师往往会随机从主题跳到主题,从而导致混乱和错误。建议的方法侧重于在五个不同的层进行工作:

五个层设计模型示意图

前三层分别针对每个用户组设计,这些用户组在评估阶段的用户细分部分中进行确认。这些层定义用户的资源和用户访问其资源的方式。完成这三个层后,基础层(控制和硬件)将针对整个解决方案而设计。

此过程指导设计思路,因为决策能够做出更高影响力、较低级别的设计决策。

第 0 层:概念体系结构

概念体系结构有助于根据业务目标和组织结构定义整个解决方案的总体战略。

虽然一个组织的概念体系结构将在未来几年发生变化,但还是值得开始设计阶段,方法是围绕交付模型和解决方案的实际地理分布来定义长期目标。

决策:交付模型

XenDesktop 和 XenApp 解决方案可以采用多种交付形式。组织的业务目标帮助您选择正确的方法。即使所有交付模型的体系结构都保持不变,本地 IT 团队的管理范围也会发生变化。

  • 本地 - 从组织的本地数据中心托管的所有组件。本地模型要求本地 IT 团队管理解决方案的各个方面。

本地体系结构示意图

  • 公有云 - 使用基础结构即服务 (IaaS) 从公有云基础结构托管的所有组件。公有云模型从本地 IT 团队的管理范围中消除了硬件管理。

公有云体系结构示意图

  • 混合云 - 单个实现从本地数据中心以及公有云执行。即使解决方案的组件使用不同的托管提供程序,整个解决方案也是使用相同的代码的单个解决方案,并作为单个实体进行管理。本地 IT 团队将继续管理解决方案的各个方面,但与云托管资源相关联的硬件除外。

混合云体系结构示意图

  • Citrix Cloud - Citrix Cloud 提供的 XenApp and XenDesktop Service 将典型部署分解为多个管理域。访问和控制层组件由 Citrix 在 Citrix cloud 中托管和管理,而资源层组件则继续由本地 IT 团队作为本地云、公有云或混合云模型进行管理。Citrix 负责管理硬件、访问和控制组件的大小调整和更新,而本地 IT 团队则管理资源。此外,如果公有云托管资源,则本地 IT 团队不必管理资源硬件。Citrix Cloud 将继续扩大产品数量,以帮助解决特定用户案例。要了解更多信息,并了解完整的产品系列,请浏览 Citrix Cloud 中的 Workspace Service

Citrix cloud 体系结构示意图

决策:站点拓扑

XenApp 和 XenDesktop 站点将桌面和应用程序组合在一起,以形成单个体系结构和管理实体。站点的所有静态和动态数据(包括站点配置、桌面分配和会话状态)都存储在站点的数据库中。

站点可以包含在一个位置中、跨多个位置或是一个部分位置。通过严格的测试,单个 XenApp/XenDesktop 站点可以支持 40000 个或更多个并发会话。

交付站点 1 示意图

交付站点 2 示意图

交付站点 3 示意图

区域对单个站点进行细分,通常与地理位置相关联。在确定 XenApp 和 XenDesktop 解决方案的整体拓扑时,需要考虑下面几个因素:

  • 风险容忍 - 创建多个 XenDesktop 站点以尽量减少站点范围中断的影响。例如,XenDesktop 站点数据库的损坏可能会影响站点范围的可用性。对许多组织而言,实施多个站点减少的风险远远超过所需的额外管理开销和支持基础结构。

来自现场的经验

财务 - 某个大型金融机构托管单个数据中心中的 10000 个桌面。为降低风险,决定任何站点都不应超过 5000 个桌面。因此,尽管桌面通过快速冗余网络连接,但仍创建了两个站点。

  • 安全性 - 尽管委派管理可用,但高安全性的组织可能需要在环境之间完全分离,以证明符合特定服务级别协议。

来自现场的经验

零售 - 某个零售组织要求负责管理财务数据的员工完全分离。为了满足这一要求,在同一数据中心内创建了两个独立的站点,一个面向财务员工,另一个面向所有其他员工。

  • 管理边界 - 由于计费/收费要求或 IT 的结构,可能需要多个站点来分隔管理边界。

  • 地理连接 - 虽然区域的实现允许单个站点跨越地理位置,但卫星区域与主区域之间必须有足够的带宽,以便站点数据库捕获会话信息。更高的延迟或更大的区域会影响用户的响应时间。

变量 XenApp 和 XenDesktop 7.13 XenApp 和 XenDesktop 7.11
延迟时间(毫秒) 90 250
并发请求 48 48
平均响应时间 3.7 7.6
每秒代理请求 12.6 6.3
启动 10000 个用户的时间 13 分钟 26 分钟
会话计数 最大并发会话启动次数 最小站点到站点带宽 最大站点到站点往返行程延迟
小于 50 20 1 Mbps 250 毫秒
50 到 500 25 1.5 Mbps 100 毫秒
500 到 1000 30 2 Mbps 50 毫秒
1000 到 3000 60 8 Mbps 10 毫秒
大于 3000 60 8 Mbps 5 毫秒

一般情况下,管理员应尽可能减少 XenDesktop 站点和区域的数量,以降低体系结构的复杂性并减少管理工作。

决策:映像管理策略

XenApp 和 XenDesktop 解决方案需要创建和管理主映像。组织必须尽早决定采取何种策略进行映像管理。

已安装的映像

已安装的映像要求管理员为每个映像安装操作系统和应用程序。这种方法非常简单,但是当管理员跨多个主映像安装相同的操作系统和核心应用程序时会造成重复劳动。

维护主映像还包括重复工作,因为相同的操作系统版本和核心应用程序是多个映像的一部分,每个映像都需要相同的更新过程。

脚本化映像

管理员可以使用脚本或自动化工具自动执行与已安装的映像相关联的许多任务。许多操作系统和应用程序安装都支持自动编写脚本,从而减轻工作重复对管理员使用已安装映像的时间的影响。

遗憾的是,学习、创建和维护整个映像的脚本框架既具有挑战性又耗时。编写整个构建脚本需要时间,如果目录结构发生变化、进程需要太长时间才能完成或文件名更改,通常会导致意外失败。

分层映像

每个唯一的操作系统(Windows 10、Windows 2012R2 和 Windows 2016)、平台(XenApp/XenDesktop 7.13 VDA、XenApp/XenDesktop 7.14 VDA 和 XenApp/XenDesktop 7.15 VDA)和应用程序(Microsoft Office、Adobe Acrobat、Google Chrome 和 Mozilla Firefox)是一层。主映像是一个操作系统层、一个平台和多个应用程序的合并。

分层映像方法可消除与已安装的映像和脚本化映像相关联的重复工作的挑战。每个唯一的层可用于任何主映像。当应用程序需要更新时,该层将接收更新,而使用该层的所有主映像都将接收更新。如果组织需要十个唯一的 Windows 10 映像,则十个映像中的每个映像都共享相同的 Windows 10 层。当管理员需要跨十个映像将 VDA 从版本 7.14 升级到 7.15 时,管理员仅更新单个平台层。

最初,分层映像方法确实需要较长时间来部署,因为管理员必须构建组织的层库。但是,一旦层可用,维护映像所需的时间就会大大减少。