设计方法控制层

控制层是设计方法的第四个层。

Active Directory

决策:林设计

默认情况下,多林部署在林之间没有域间信任关系。AD 管理员可以在多个林之间建立信任关系,允许一个林中的用户和计算机对另一个林中的资源进行身份验证和访问。

对于具有域间信任的林,建议配置适当的设置,以允许 Delivery Controller 与两个域通信。如果未配置适当的信任,则必须为每个林配置多个 XenDesktop 站点。本部分内容概述了每个产品的存储要求,并提供规模计算。有关详细信息,请参阅 Citrix 文章:CTX134971 – 在复杂 Active Directory 环境中成功部署 XenDesktop

决策:组织单位结构

XenApp 和 XenDesktop 部署的基础结构组件应位于自己的专用组织单位 (OU) 内;分离工作线程和控制器以进行管理。通过拥有自己的 OU,其中的对象在管理上将具有更大的灵活性,同时允许 Citrix 管理员获得委派控制权。

下面可以看到 Citrix OU 结构示例。

Citrix OU 示意图

决策:用户组

只要有可能,应将权限和授权分配给用户组,而非单个用户,从而在创建、修改或删除用户帐户时无需编辑大量资源权限和用户权限。权限应用示例:

  • 发布到一个 1000 个用户的组的应用程序只需要对所有 1000 个用户验证一个对象。
  • 发布到 1000 个用户帐户的同一应用程序需要验证所有 1000 个对象。

数据库

本文档中讨论的大部分 Citrix 产品都需要数据库。下表概述了每个产品的使用情况:

在此表中:

  • Y 表示可用。
  • O 表示可选。
产品 配置数据 运行时数据 审核/更改日志数据 监视数据
XenDesktop Y Y Y Y
Provisioning Services Y   O  
桌面播放器 Y Y Y Y

决策:版本

有多个版本的 Microsoft SQL Server 2012:Express、Web、Standard、Business Intelligence 和 Enterprise。根据可用的各种 SQL Server 版本的功能,Standard Edition 通常用于在生产环境中托管 XenApp 和 XenDesktop 数据库。

Standard Edition 提供足够的功能,能够满足大多数环境的需求。有关 Citrix 产品支持的数据库的详细信息,请参阅 Citrix 数据库支持列表。不同版本的 Citrix 产品支持不同版本的 SQL Server;因此,请务必检查支持列表,以确保使用的 SQL Server 版本与正在部署的 Citrix 产品兼容。

决策:数据库服务器大小调整

SQL Server 的大小必须正确,以确保环境的性能和稳定性。由于每个 Citrix 产品都以不同的方式使用 SQL Server,因此无法提供通用的包罗万象的大小调整建议。相反,下面提供了按产品 SQL Server 大小调整建议。

XenApp 和 XenDesktop

XenApp 和 XenDesktop Broker 将数据库用作消息总线,用于代理通信、存储配置数据以及存储监视和配置日志数据。数据库在不断使用,可以视为对 SQL Server 产生高性能影响。

根据 Citrix 内部可扩展性测试的结果,建议为托管所有 XenDesktop 数据库的服务器使用以下 SQL Server 规范:

  • 2 个内核/4 GB 内存,适用于多达 5000 个用户的环境
  • 4 个内核/8 GB 内存,适用于多达 15000 个用户的环境
  • 8 个内核/16 GB 内存,适用于 15000 个以上的用户的环境

数据库文件和事务日志应托管在单独的硬盘子系统中,以便处理大量事务。例如,在 XenDesktop 站点数据库中,在 15 分钟启动高峰期间注册 20000 个虚拟桌面会导致每秒进行大约 500 个事务,在 30 分钟登录高峰期间登录约 20000 个用户会导致每秒进行大约 800 个事务。

Provisioning Services

除了静态配置数据 Provisioning 服务器在数据库中存储运行时和审核信息。根据启动和管理模式,数据库对性能的影响可视为低到中。

基于此分类,建议将 4 个内核和 4 GB RAM 的 SQL Server 规范作为良好的起点。在测试和试验阶段,应仔细监视 SQL Server,以便确定 SQL Server 的最佳配置。

决策:实例大小调整

调整 SQL 数据库大小时,两个方面都很重要:

  • 数据库文件 – 包含数据库中存储的数据和对象,例如表格、索引、存储过程和视图。
  • 事务日志文件 – 包含所有事务以及每个事务所做的数据库修改的记录。事务日志是数据库的关键组件,如果出现系统故障,可能需要事务日志以使数据库恢复到一致状态。事务日志的使用因所使用的数据库恢复模型而异:
    • 简单恢复 – 无需日志备份。日志空间会自动回收,以保持较小的空间需求,基本上无需管理事务日志空间。自最近一次备份以来对数据库所做的更改不受保护。在发生灾难时,必须重新做出这些更改。
    • 完全恢复 – 需要日志备份。数据库数据文件丢失或损坏不会导致丢失任何工作。任何任意时间点的数据都可以恢复(例如,在出现应用程序或用户错误之前)。数据库镜像需要完全恢复。
    • 批量记录 – 需要日志备份。这是允许高性能批量复制操作的完整恢复模式的辅助功能。它通常不用于 Citrix 数据库。

有关详细信息,请参阅 Microsoft Developer Network – SQL Server 恢复模式

为了预估存储需求,了解常见数据库条目的磁盘空间消耗情况非常重要。本部分内容概述了每个产品的存储要求,并提供规模计算。有关详细信息,请参阅 Citrix 文章:CTX139508 – XenDesktop 7.x 数据库大小调整。

XenDesktop 常规

XenApp 7.x 和 XenDesktop 7.x 使用三个不同的数据库:

  • 站点配置数据库 – 包含静态配置和动态运行时数据
  • 监视数据库 – 包含可通过 Director 访问的监视数据
  • 配置日志记录数据库 – 包含站点内执行的每个管理更改的记录(通过 Studio 访问)

站点数据库

由于 XenApp 或 XenDesktop 站点的数据库包含静态配置数据和动态运行时数据,因此,数据库文件的大小不仅取决于环境的物理大小,还取决于用户模式。以下因素都会影响数据库文件的大小:

  • 连接的会话数量
  • 配置和注册的 VDA 数量
  • 登录期间发生的事务数
  • VDA 检测信号事务

站点数据库的大小取决于 VDA 和活动会话的数量。下表显示了在使用用户、应用程序和桌面交付方法样本数对 XenApp 和 XenDesktop 进行扩展测试时,Citrix 观察到的典型最大数据库大小。

用户 应用程序 桌面类型 预期最大大小 (MB)
1000 50 托管共享 30
10000 100 托管共享 60
100000 200 托管共享 330
1000 不适用 托管池 30
10000 不适用 托管池 115
40000 不适用 托管池 390

注意

此大小调整信息仅供参考。由于数据库的维护方式,实际数据库大小可能因部署而略有不同。

由于可能影响日志的因素,确定站点数据库的事务日志大小很困难,这些因素包括:

  • SQL 数据库恢复模式
  • 高峰时间段内启动速率
  • 正在交付的桌面数量

在 XenDesktop 可扩展性测试期间,Citrix 观察到系统空闲时事务日志增长率为每小时 3.5 MB,每用户每天的增长率大约为 32 KB。在大型环境中,事务日志的使用需要仔细管理和定期备份,以防止过度增长。这可以通过计划作业或维护计划来实现。

监视数据库

在三个数据库中,预计监视数据库将是最大的数据库,因为它包含该站点的历史信息。其大小取决于许多因素,包括:

  • 用户数
  • 会话和连接数
  • 工作线程数
  • 保留期配置 – Platinum 客户可以将数据保留一年以上(默认 90 天)。非 Platinum 客户最多可以保留数据 7 天(默认 7 天)。
  • 每秒的事务数量。监视服务倾向于批量执行更新。每秒的事务数量高于 20 非常罕见。
  • 从监视服务定期整合调用导致的后台事务。
  • 进行隔夜处理,以便删除配置的保留期限外的数据。

下表显示了不同方案中一段时间内监视数据库的预估大小。此数据是基于在 XenApp 和 XenDesktop 的扩展测试(假设每周工作 5 天)中看到的数据的预估值。

用户 类型 1 周 (MB) 1 个月 (MB) 3 个月 (MB) 1 年 (MB)
1000 HSD 20 70 230 900
10000 HSD 160 600 1950 7700
100000 HSD 1500 5900 19000 76000
1000 VDI 15 55 170 670
10000 VDI 120 440 1400 5500
40000 VDI 464 1700 5400 21500

每个用户使用 2 个连接和 1 个会话,每周工作 5 天情况下预估

用户 类型 1 周 (MB) 1 个月 (MB) 3 个月 (MB) 1 年 (MB)
1000 HSD 30 100 330 1300
10000 HSD 240 925 3000 12000
100000 HSD 2400 9200 30000 119000
1000 VDI 25 85 280 1100
10000 VDI 200 750 2500 9800
40000 VDI 800 3000 9700 38600

注意

100000 个 HSD 测试基于由以下各项组成的测试环境:

  • 2 个 Delivery Controller
  • 43 个托管共享桌面工作线程
  • 3 个 SQL Server,配置的数据库位于一个 AlwaysOn 可用性组中。

有关详细信息,请参阅 Citrix 支持文章 – XenDesktop 7.x 数据库大小调整

监视数据库的事务日志的大小很难预估,但 XenApp 和 XenDesktop 可扩展性测试显示,当系统空闲时,每小时的增长率约为 30.5 MB,每个用户每日增长率约为 9 KB。

配置日志记录数据库

配置日志记录数据库通常是三个数据库中最小的。其大小和相关事务日志的大小取决于从 Studio、Director 或 PowerShell 脚本启动的日常管理活动,因此其大小难以预估。执行的配置更改越多,数据库将增长越大。可能会影响数据库大小的因素包括:

  • 在 Studio、Director 和 PowerShell 中执行的操作数量。
  • 当没有进行任何配置更改时,数据库上发生的最小事务。
  • 更新期间的事务速率。更新将尽可能分批处理。
  • 从数据库中手动删除的数据。配置日志记录数据库中的数据不受任何保留策略的约束,因此,除非管理员手动执行此操作,否则不会删除该数据。
  • 对会话或用户有影响的活动,例如,会话注销和重置。
  • 用于部署桌面的机制。

在不使用 MCS 的 XenApp 环境中,数据库大小往往介于 30 到 40 MB 之间。对于 MCS 环境,由于记录了所有 VM 构建数据,数据库大小可能很容易超过 200 MB。

临时数据库

除了站点数据库、监视数据库和配置日志记录数据库之外,SQL Server 还提供了系统范围的临时数据库 (tempdb)。此临时数据库用于存储读取已提交的快照隔离数据。XenApp 7.x 和 XenDesktop 7.x 使用此 SQL Server 功能来减少 XenApp 和 XenDesktop 数据库上的锁争用。Citrix 建议所有 XenApp 7.x 和 XenDesktop 7.x 数据库都使用读取已提交的快照隔离。有关详细信息,请参阅如何在 XenDesktop 中启用读取已提交的快照

tempdb 数据库的大小将取决于活动事务的数量,但通常不会增长超过几个 MB。tempdb 数据库的性能不会影响 XenApp 和 XenDesktop 代理的性能,因为生成新数据的任何事务都需要 tempdb 空间。XenApp 和 XenDesktop 往往具有短期事务,这有助于保持 tempdb 的大小较小。

查询生成大型中间结果集时,也会使用 tempdb。可以在 Microsoft TechNet 文章优化 tempdb 性能中找到指导和调整 tempdb 的大小。

Provisioning Services

Provisioning Services 场数据库包含静态配置和配置日志记录(审核跟踪)数据。下面概述的记录大小要求可用于帮助调整数据库的大小:

配置项目 需要数据库空间 (KB) 项目数量(示例) 总计 (KB)
基础场配置 112 - 112
带有场访问权限的用户组 50 10 250
站点 4 5 20
设备集合 10 50 500
场视图 4 10 40
场视图与设备关系 5 1 5000
站点视图 4 5 20
站点视图与设备关系 5 1 5000
设备 2 5000 10000
设备引导程序 10 - -
设备与磁盘关系 35 1 175000
设备打印机关系 1 - -
设备个性化设置数据 1 - -
设备状态(启动时) 1 5000 5000
设备自定义属性 2 - -
虚拟磁盘 1 20 20
虚拟磁盘版本 3 5 300
磁盘定位器 10 1 200
磁盘定位器自定义属性 2 - -
服务器 5 10 50
服务器 IP 2 1 20
服务器状态(启动时) 1 20 20
服务器自定义属性 2 - -
虚拟磁盘存储 8 5 40
虚拟磁盘存储与服务器关系 4 1 40
与 XenServer 的连接 (VirtualHostingPool) 4 - -
虚拟磁盘更新任务 10 10 100
管理变更(启用审核) 1 10000 10000
总数     211732 KB (~212 MB)

在 PVS 场设置期间,将创建初始文件大小为 20 MB 的数据库。由于 PVS 场数据库中数据的性质,除非执行了大量配置,否则事务日志不会快速增长。

与 XenApp 相比,XenApp 还提供了跟踪管理更改的功能,相关信息不会写入专用数据库,而是直接写入到 Provisioning Services 场数据库。为了限制 Provisioning Services 数据库的大小,建议定期存档审核跟踪数据。

决策:数据库位置

XenApp 和 XenDesktop 使用三种不同的数据库:站点配置、监视和配置日志记录。所有三个数据库都可以托管在同一台服务器上,也可以托管在不同的服务器上。理想的配置是在站点配置和配置日志记录数据库中不同的服务器上托管监视数据库。最好将监视数据库分开,因为它记录了更多数据,更改的发生频率更高,并且数据被认为不像其他数据库那样重要。

注意

不能在启用强制日志记录功能时更改配置日志记录数据库的位置。

决策:高可用性

下表突出显示了数据库中断时对 XenApp、XenDesktop 和 Provisioning Services 的影响:

组件 数据库中断的影响
站点配置数据库 用户将无法连接或重新连接到虚拟桌面。注意:本地主机缓存允许具有托管共享桌面、托管 Windows 和浏览器应用程序以及个人桌面的用户重新连接到其应用程序和桌面,即使站点数据库不可用亦如此。
监视数据库 Director 将不显示任何历史数据并且不能启动 Studio。传入用户请求和现有用户会话的代理将不会受到影响。
配置日志记录数据库 如果在 XenApp 和 XenDesktop 日志记录首选项中启用了数据库断开连接时允许更改,则配置日志记录数据库的中断将没有任何影响(不包括未记录配置更改)。否则,管理员将无法对 XenApp 和 XenDesktop 站点配置进行任何更改。用户不会受到影响。
Provisioning Services 场数据库 启用脱机数据库支持并且数据库变得不可用时,流进程将使用数据库的本地副本检索有关 Provisioning 服务器和服务器支持的目标设备的信息。这允许 Provisioning 服务器和目标设备保持运行状态。但是,当数据库处于脱机状态时,下面列出的控制台和管理功能将变得不可用:自动添加目标设备;虚拟磁盘创建和更新;Active Directory 密码更改;流进程启动;映像更新服务;基于 PowerShell 和 MCLI 的管理。如果尚未启用脱机数据库支持,则所有管理功能都将变得不可用,目标设备的引导和故障转移将失败。

注意

请检查各自的软件供应商的第三方数据库(例如 App-V、SCVMM 或 vCenter)的高可用性选项。

除了内置的数据库冗余选项外,Microsoft SQL Server 以及底层虚拟机管理程序(在虚拟环境中)还提供许多高可用性功能。这些功能使管理员能够确保单个服务器中断对 XenApp 和 XenDesktop 基础结构的影响最小(如果有)。下面的 SQL/虚拟机管理程序高可用性功能可用:

  • VM 级别的高可用性 – 此高可用性选项仅适用于虚拟 SQL Server,这些服务器需要在虚拟机管理程序层标记为“高可用性”。如果虚拟机或底层虚拟机管理程序主机意外关闭,虚拟机管理程序将尝试立即在其他主机上重新启动 VM。尽管 VM 级别的高可用性功能可以最大程度地缩短端点情况下的停机时间,但是它不能防止操作系统级别的损坏。此解决方案比镜像或群集更便宜,因为它使用内置的虚拟机管理程序功能。但是,自动故障转移过程较慢,因为它可能需要时间来检测中断并在另一台主机上启动虚拟 SQL Server。这可能会中断对用户的服务。
  • 镜像 – 数据库镜像通过接近瞬间故障转移来提高数据库可用性。数据库镜像可用于维护对应的主体或生产数据库的单个备用数据库或镜像数据库。数据库镜像在高安全模式下运行同步操作,或在高性能模式下运行异步操作。在具有自动故障转移的高安全模式下(推荐用于 XenDesktop),需要第三个服务器实例(称为见证),从而使镜像服务器能够充当热备用服务器。从主体数据库到镜像数据库的故障转移会自动发生,通常会在几秒钟内完成。最好至少为见证启用 VM 级别的高可用性(或类似的自动重新启动功能),以确保 SQL 服务在多服务器中断的情况下的可用性。

注意

Microsoft 计划在将来版本的 SQL Server 中删除镜像作为高可用性选项,并且不鼓励在新的网络开发中使用镜像。有关详细信息,请参阅 Microsoft 文章 – 数据库镜像 (SQL Server)

  • AlwaysOn 故障转移群集实例 – 故障转移群集为 Microsoft SQL Server 的整个实例提供了高可用性支持。故障转移群集是使用共享存储的两个或多个节点(或服务器)的组合。SQL Server 2012 中引入的 Microsoft SQL Server AlwaysOn 故障转移群集实例以单台计算机形式出现在网络中,但如果当前节点变得不可用,则会具有提供从一个节点到另一个节点故障转移的功能。对于连接到群集的客户端而言,从一个节点到另一个节点的过渡是无缝的。AlwaysOn 故障转移群集实例需要一个 Windows Server 故障转移群集 (WSFC) 资源组。WSFC 资源组中支持的节点数将取决于 SQL Server 版本。(请参阅本章前面部分的决策:版本中的表格。)有关详细信息,请参阅 MSDN – AlwaysOn 故障转移群集实例 (SQL Server)
  • AlwaysOn 可用性组 – AlwaysOn 可用性组是 Microsoft SQL Server 2012 中引入的具有高可用性和灾难恢复能力的企业级解决方案,此方案使管理员能够最大程度地提高一个或多个用户数据库的可用性。AlwaysOn 可用性组要求 Microsoft SQL Server 实例必须驻留在 Windows Server 故障转移群集 (WSFC) 节点上。与故障转移群集类似,单个虚拟 IP/网络名称会公开给数据库用户。与故障转移群集相反,不需要共享存储,因为数据是使用网络连接传输的。支持同步和异步复制到一个或多个辅助服务器。与镜像或群集相反,辅助服务器可以主动用于处理传入的只读请求、备份或完整性检查。此功能可用于将用户资源枚举请求卸载到 XenDesktop 环境中的辅助 SQL Server,以在实质上横向扩展 SQL Server 基础结构。由于活动辅助服务器上的数据可能落后于主服务器几秒钟,因此此时无法将只读路由功能用于其他 XenDesktop 数据库请求。有关详细信息,请参阅 MSDN – AlwaysOn 可用性组 (SQL Server)

下表概述了 Citrix 数据库的推荐的高可用性功能:

在此表中:

  • Y 表示推荐。
  • o 表示可行。
  • N 表示不受支持。
  • T 表示仅适用于测试环境。
组件 VM 级别 - 高可用性 镜像 AlwaysOn 故障转移群集实例 AlwaysOn 可用性组
站点数据库 T Y o o
配置日志记录数据库 T o o o
监视数据库 T Y o o
Provisioning Services 场数据库 T Y o o
DesktopPlayer 数据库 T N o o

Citrix Licensing

Citrix 为组织提供了与常见使用情况一致的多种许可模式的灵活性。不同的许可模式因所用的 Citrix 产品而异,但可以包括每用户/设备和每并发用户。多个 Citrix 产品使用许可证服务器,而其他产品则需要在产品本身上安装许可证。

Citrix 许可证服务器

  • XenDesktop
  • XenApp
  • Provisioning Services
  • XenServer

在产品中:

  • NetScaler
  • NetScaler Gateway

有关 XenDesktop 7.x 许可的详细信息,请参阅 CTX128013 - XenDesktop 许可。

有关 Microsoft 许可的详细信息,请参阅 Microsoft 文档 – 许可使用 Microsoft 的虚拟桌面基础结构技术

决策:大小调整

内部可扩展性测试表明,具有两个内核和 2 GB RAM 的单个虚拟许可证服务器可以每秒颁发大约 170 个许可证,或每半小时颁发约 306000 个许可证。如有必要,可以横向扩展许可证服务器的规范,以支持每秒更多的许可证请求。

决策:高可用性

对于典型环境,单台许可证服务器就足够了。如果许可证服务器变得不可用,则相关 Citrix 产品将进入 30 天宽限期,从而提供足够的时间来解决连接问题和/或还原或重建许可证服务器。

注意

  • 如果许可证服务器和 Citrix 产品未在 2 个检测信号(5-10 分钟)内进行通信,则 Citrix 产品将进入宽限期,并且最多允许连接 30 天。重新建立与许可证服务器的通信后,许可证服务器将协调临时许可证和实际许可证。
  • DNS 中的 CNAME 记录是引用许可证服务器的便捷方式。使用 CNAME 可以更改许可证服务器名称,而无需更新 Citrix 产品。

如果需要额外的冗余,Citrix 支持许可证服务器的以下高可用性解决方案。

  • Windows 群集 – 群集服务器是协同工作以提高可用性的计算机组。群集允许许可证服务器角色在发生故障时自动进行故障转移。有关群集的详细信息,请参阅 Citrix Docs 文章 – 群集许可证服务器
  • 复制许可证服务器 – 创建许可证服务器的 VM 级别备份。此备份不应与许可证服务器存储在同一主机上。相反,应将其存储在安全位置(例如高可用存储解决方案)或备份到磁带或磁盘。重复的服务器未处于活动状态,并且将保持待机状态,直到需要还原活动许可证服务器。如果使用此备份还原许可证服务器,则必须将任何新许可证重新下载到服务器。

有关详细信息,请参阅 Citrix eDocs – Licensing 体系结构概述

每种方法都允许管理员在不中断服务的情况下将单个许可证服务器交换为另一个许可证服务器,前提是更改发生在宽限期内,并且考虑了以下限制。

  • 许可证文件将引用分配过程中指定的服务器。这意味着许可证文件只能在与之前指定的服务器具有相同的绑定信息 (Hostname) 的服务器上使用。
  • 两个基于 Windows 的已加入域的许可证服务器不能共享相同的名称,并且在同一时间在环境中处于活动状态。
  • 由于许可证服务器不相互通信,因此,必须在活动许可证服务器和备份许可证服务器上放置任何其他许可证。

决策:优化

通过调整“接收”和“处理”线程的数量,可以优化许可证服务器的性能。如果线程计数设置过低,则请求将被排队,直到线程可用为止。相反,如果线程计数设置过高,许可证服务器将超载。

最佳值取决于服务器硬件、站点配置和许可证请求卷。Citrix 建议测试和评估不同的值以确定正确的配置。将最大处理线程数设置为 30,将最大接收线程数设置为 15 是大规模部署的一个很好的起点。

此优化将提高 Citrix 许可证服务器接收和处理许可证请求的能力,从而提高 Citrix 许可证服务器提供许可证的能力。

有关详细信息,请参阅 Citrix Docs – 通过指定线程使用来提高性能

Delivery Controller

决策:服务器大小调整

Delivery Controller 的可扩展性取决于 CPU 使用率。可用的处理器内核越多,Controller 可以支持的虚拟桌面就越多。每个桌面启动、注册、枚举和启动请求都会影响 Controller 的处理器。随着风暴强度的增加,Controller 的 CPU 利用率将增加。如果 CPU 达到临界阈值(约 80%),则站点需要纵向扩展或横向扩展。

向 Delivery Controller 中添加额外的 CPU 内核将降低整体 CPU 利用率,从而允许单个 Controller 支持更多数量的桌面。这只有在处理虚拟化 Controller 时才可行,因为添加虚拟 CPU 是相当简单和直接的。另一种选择是将另一个 Controller 添加到站点配置中。该 Controller 将具有与其他 Controller 相同的配置,负载将均匀分布在所有 Controller 上,从而有助于减少每个 Controller 上的整体负载。

测试表明,使用以下配置的单个 Delivery Controller 可以支持 5000 多个桌面。

组件 规范
处理器 4 vCPU
内存 4 GB RAM
网络 绑定的虚拟 NIC
主机存储 40 GB 共享存储
操作系统 Windows Server 2012 R2
XenDesktop 7

以下公式可用于计算 Citrix 站点所需的 Delivery Controller 数量。

Delivery Controller 数量示意图

决策:高可用性

如果托管 Delivery Controller 的服务器不可用,用户将无法启动其虚拟桌面或已发布的应用程序。因此,应在不同的物理服务器上每个区域至少部署两个 Delivery Controller(N+1 冗余),以防止此组件成为单一故障点。如果一个 Controller 出现故障,其他的 Controller 可以管理连接和站点。

所有 Delivery Controller 的位置都在 VDA 上指定,如果与一个 Delivery Controller 的通信不可用,则允许其自动故障转移。VDA 按顺序检查以下位置,并在发现 Delivery Controller 的第一个位置停止:

  1. 为自动更新功能所维护的静态存储位置。在启用自动更新并且 VDA 在安装后首次成功完成注册后,此位置包含 Controller 信息。在安装后首次注册时,或者禁用自动更新后,VDA 将检查以下位置:
  2. 策略设置(Delivery Controller、Delivery Controller SID)。
  3. VDA ListofDDCs 注册表项下的 Delivery Controller 信息。VDA 安装程序首次将根据在安装 VDA 时指定的信息填充这些值。
  4. 基于 OU 的发现。这是一种为实现向后兼容性而维护的传统方法。
  5. 由 Machine Creation Services 创建的 Personality.ini 文件。

Citrix Consulting 建议使用自动更新功能(默认启用)。此功能将在添加和删除 Delivery Controller 时保持 VDA 的更新,从而简化环境的管理。

决策:本地主机缓存

即使 SQL 数据库具有高可用性,如果 Delivery Controller 和 SQL 数据库之间的网络连接失败,也存在无法访问数据库的风险,这对跨地理位置的站点而言是一个重要问题。

要克服此风险,Delivery Controller 可以使用本地主机缓存功能,该功能创建 SQL 数据库的本地副本,仅当 Delivery Controller 与数据库断开联系时才使用。

使用本地主机缓存时,必须考虑以下事项:

  • 选举 – 当区域断开与 SQL 数据库的联系时将发生选举,指定单个 Delivery Controller 为主 Controller。所有其余的 Controller 进入空闲模式。简单的按字母顺序排列顺序决定了选举的赢家。
  • 大小调整 – 使用本地主机缓存模式时,单个 Delivery Controller 负责所有 VDA 注册、枚举、启动和更新。选出的 Controller 必须具有足够的资源(CPU 和 RAM)来处理区域的整个负载。单个 Controller 可扩展至 10000 个用户,这会影响区域设计。
    • RAM – 本地主机缓存服务可以消耗 2+ GB 的 RAM,具体取决于中断的持续时间和中断期间用户启动的数量。
    • CPU – 本地主机缓存最多可以在单个套接字中使用 4 个内核。
    • 存储 – 在本地主机缓存模式下,存储空间每 2-3 分钟增加 1 MB,平均每秒 10 次登录。
  • 电源选项 – 当 Delivery Controller 处于本地主机缓存模式时,关闭电源的虚拟资源将不启动。在会话结束时重新启动的池虚拟桌面将置于维护模式。
  • 控制台 – 使用本地主机缓存模式时,Studio 和 PowerShell 不可用。

决策:XML Service 加密

在典型会话中,StoreFront 服务器将凭据传递到 Delivery Controller 上的 Citrix XML Service。Citrix XML 协议使用明文交换除密码之外的所有数据,密码使用混码进行传输。

如果 Storefront 服务器与 XenDesktop 控制器之间的流量可以拦截,则可能会受到以下攻击:

  • 攻击者可截获 XML 通信并窃取资源集信息和票据。
  • 能够破解混码的攻击者可以获取用户凭据。
  • 攻击者可以模拟 XenDesktop 控制器并截获身份验证请求。

对大多数组织而言,Citrix XML 流量将在专用物理或虚拟数据中心网络上隔离,因此不太可能进行拦截。但是,为了安全起见,请考虑使用 SSL 加密通过安全 HTTP 连接发送 StoreFront 数据。

决策:服务器操作系统负载管理

默认负载管理策略应用于所有服务器操作系统交付组。默认设置将服务器可以托管的最大会话数指定为 250,并且不考虑 CPU 和内存使用情况。限制会话计数并不能提供负载的真实指示,这可能会导致服务器操作系统交付组负担过重,导致性能下降或服务器操作系统交付组利用率不足,从而导致资源使用率低下。

Citrix Consulting 建议根据性能和可扩展性测试为每个交付组创建唯一的“自定义”负载管理策略。根据测试期间确定的不同资源瓶颈,可以对每个交付组应用不同的规则和阈值。有关可用负载管理策略配置的详细信息,请参阅 Citrix Docs – 负载管理策略设置

如果不能在生产之前执行足够的测试,Citrix Consulting 建议实施下面的“自定义”负载管理策略,该策略可作为基准应用到所有服务器:

  • CPU 使用率 - 满载:80%
  • 排除 CPU 使用率的进程优先级 – 低于正常或低
  • 内存使用情况 - 满载:80%
  • 内存使用情况基础负载 – 报告零负载 (MB):786
  • 最大会话数 – X

包含“最大会话数”策略是为了设定上限,这被认为是实现弹性的最佳做法。组织可以选择初始值 250(用上面的“X”表示)。强烈建议根据可扩展性测试的结果自定义此值和其他值

Coud Connector

Citrix Cloud 中的 XenApp and XenDesktop Service 使用了 Citrix Cloud Connector 中包含的一组服务。必须在包含 VDA 主机的每个数据中心/资源位置放置一组冗余的 Cloud Connector 虚拟机。

决策:服务器大小调整

Cloud Connector 的可扩展性取决于 CPU 使用率。可用的处理器内核越多,Cloud Connector 可以支持的虚拟桌面就越多。每个桌面启动、注册、枚举和启动请求都会影响 Cloud Connector 的处理器。随着风暴强度的增加,Cloud Connector 的 CPU 利用率将增加。如果 CPU 达到临界阈值(约 80%),则站点需要纵向扩展或横向扩展。

测试表明,使用以下配置的单个 Cloud Connector Controller 可以支持 5000 个桌面。

组件 本地规范 Azure 托管规范
VM 数量(具有 N+1 容错) 3 6 个 Standard_A2_V2 实例
每个 VM 的处理器 4 vCPU 2 vCPU
每台 VM 的内存 4 GB RAM 4 GB RAM
每个 VM 的主机存储 40 GB 共享存储 200 GB 临时存储
操作系统 Windows Server 2012 R2 Windows Server 2012 R2

Provisioning Services

Citrix Provisioning Services (PVS) 使用流技术推送技术来简化虚拟机和物理机的部署。计算机从单个共享磁盘映像实时预配和重新预配。在这一过程中,管理员完全无需管理和修补各个系统,所有映像管理均在主映像上执行。

决策:拓扑

Provisioning Services 场表示 Provisioning Services 基础结构的顶层,可以进一步将其拆分到多个站点中。场中的所有 Provisioning 服务器共享相同的 SQL 数据库和 Citrix 许可证服务器。

每个站点是一个包含 Provisioning 服务器、虚拟磁盘池和目标设备集合的逻辑实体。尽管场中的所有站点共享同一个数据库,但目标设备只能故障转移到同一站点中的其他 Provisioning 服务器。

PVS 站点结构示意图

在确定整体 Provisioning Services 拓扑时,必须考虑以下因素:

  • 网络 — Provisioning 服务器不断与场数据库通信,以检索系统配置设置。因此,应为目标设备所在的每个物理位置创建单独的场,除非其通过快速和稳健的连接连接到数据库服务器。
  • 行政 – 组织可能需要在部门、区域或全国范围内维护行政职责的分离。其他 Provisioning Services 场将增加环境管理的复杂性。但是,此开销通常限于初始配置、桌面创建和映像更新。
  • 组织 – 构建多个站点的一个实际原因是组织变化。例如,两家公司最近可能通过收购方式合并,但在合并过程中需要将资源分开。将组织配置为使用单独的站点是保持业务独立但通过 Provisioning Services 控制台集中管理的一种方法。

只有在业务要求有需要时才创建其他站点。每个场一个站点更容易管理,不需要额外的配置。

决策:设备集合

使用设备集合可以创建和管理目标设备的逻辑分组。创建设备集合后,可以在集合级别而非目标设备级别执行操作,简化了设备管理过程。

设备集合结构示意图

设备集合可以表示组织内的物理位置、子网范围、机箱或不同部门。集合还可用于在逻辑上将生产目标设备与测试和维护目标设备分开。

请考虑根据虚拟磁盘分配创建设备集合,以便快速识别分配给特定虚拟磁盘的所有目标设备的状态。

决策:高可用性

Provisioning Services 是虚拟桌面基础结构的重要组成部分。为了消除单故障点,应遵循以下建议:

  • Provisioning 服务器 – 每个站点应始终至少实现两个 Provisioning 服务器。设计中应包含足够的冗余,以便单个服务器故障不会减少每个站点可支持的目标设备总数。Provisioning Services 引导文件应配置为高可用性。引导文件中最多可以列出四个 Provisioning 服务器。目标设备将尝试按列出的顺序联系服务器。响应的服务器不一定是向目标设备提供流技术推送服务的服务器。如果启用了负载平衡,目标设备可能会重新分配到站点中负载低于其他服务器的另一个服务器。
  • 虚拟磁盘和存储 – 对于托管在本地、直连式存储 (DAS) 或存储区域网络 (SAN) 上的虚拟磁盘存储,应使用复制来同步虚拟磁盘。如果使用网络连接存储 (NAS),请确保虚拟磁盘托管在高可用网络共享上。
  • 网络连接 – Provisioning 服务器应具有冗余 NIC。如果 Provisioning 服务器部署为物理服务器,则冗余 NIC 应分队,如果 Provisioning 服务器部署为虚拟服务器,则基础虚拟机管理程序应包含冗余 NIC。

注意

目标设备仅故障转移到与 PXE 引导 NIC 位于同一子网中的 NIC。

普通文件传输协议 (TFTP) 是一种通信协议,用于在计算机之间传输配置或引导文件。Provisioning Services 可以使用 TFTP 将引导文件交付到目标设备。有多个选项可使 TFTP 服务高度可用。一些更常用的选项包括:

  • DNS 轮询 – 为 TFTP 服务创建一个 DNS 条目,其中有多个 A 记录对应于场中 Provisioning 服务器上运行的 TFTP 服务。不建议使用此方法,因为不监视 TFTP 服务的状态。客户端可能会被发送到无法正常工作的服务器。
  • 硬件负载平衡器 – 使用硬件负载平衡器(例如 Citrix NetScaler)创建与 Provisioning 服务器相对应的虚拟 IP。NetScaler 可以在 Provisioning 服务器之间智能路由流量。如果其中一个服务器变得不可用,NetScaler 将自动停止将 TFTP 请求路由到该服务器。这是使 TFTP 高度可用的最佳方法,但设置可能会很复杂。
  • 多个 DHCP 选项 66 条目 – 此方法易于实现,但需要支持选项 66 中输入多个条目的 DHCP 服务。Microsoft DHCP 服务器允许一个选项 66 条目,因此这种方法在 Microsoft DHCP 服务的环境中是不可行的。如果使用非 Microsoft DHCP 服务器或设备,请咨询制造商以确认是否支持多个选项 66 条目。

还有其他选项可以实现相同的结果,而不必使用 TFTP:

  • 代理 DHCP – 使用 Provisioning 服务器 PXE 服务提供引导信息。如果其中一个服务器已关闭,场中的下一个可用服务器可以提供引导信息。此方法要求 Provisioning 服务器与目标设备位于同一广播域中。如果网络上运行有其他 PXE 服务(Altiris、SCCM 等),则可能需要多个 VLAN 以使 PXE 服务不相互干扰。
  • Boot Device Manager – 使用 Boot Device Manager 创建引导文件,该文件放置在本地硬盘驱动器上,或者用作可引导 ISO 文件。如果使用 ISO 文件,请将目标设备配置为从 CD/DVD-ROM 驱动器引导,并将 ISO 文件放置在高可用的共享网络位置或每个目标设备的本地存储中。使用任一方法时,完全不使用 TFTP 服务。

高可用性应始终纳入 Provisioning Services 设计中。虽然高可用性可能需要额外的资源和增加成本,但它将提供一个高度稳定的环境,以便用户因服务中断而受到的影响最小。

决策:引导程序交付

目标设备通过首先加载引导程序来启动引导过程,该程序初始化目标设备与 Provisioning 服务器之间的流技术推送会话。有三种方法可以让目标设备接收引导程序:

使用 DHCP 选项

  1. 当目标设备引导时,目标设备会发送 IP 地址和引导信息的广播。DHCP 将处理此请求并提供一个 IP 和作用域选项设置 66(Provisioning Services TFTP 服务器的名称或 IP 地址)和 67(引导文件的名称)。

    注意

    如果为 TFTP 服务使用负载平衡器,则在选项 66 中输入负载平衡器的地址。

  2. 使用 TFTP 从目标设备向 Provisioning 服务器发送引导文件请求。目标设备从 Provisioning 服务器下载引导文件。

  3. 目标设备引导分配的虚拟磁盘映像。

注意

当目标不与 DHCP 服务器位于同一子网时,需要配置 UDP/DHCP 帮助程序,以接收 PXE 广播。

使用 PXE 广播

  1. 当目标设备从网络引导时,目标设备会发送 IP 地址和引导信息的广播。DHCP 将处理此请求并提供一个 IP 地址。此外,接收广播的所有 Provisioning 服务器都将返回引导服务器和引导文件名信息。目标设备将合并接收的信息并启动引导过程。

  2. 使用 TFTP 从目标设备向首先响应的 Provisioning 服务器发送引导文件请求。目标设备从 Provisioning 服务器下载引导文件。

注意

  • 确保同一子网中没有其他 PXE 服务(例如 Altiris PXE 服务),或者使用 VLAN 进行隔离,否则可能会与 Provisioning Services 发生冲突。
  • 当目标不与 DHCP 和 PVS 服务器位于同一子网时,需要配置 UDP/DHCP 帮助程序,以便接收 PXE 广播。

使用 Boot Device Manager – Boot Device Manager (BDM) 创建引导文件,目标设备通过物理 CD/DVD、装载的 ISO 映像或作为分配给目标设备的虚拟硬盘获取该引导文件。可通过以下三种方式之一升级 BDM 分区:

  • 通过集合
  • 通过一组突出显示的设备
  • 通过单个设备

下表列出了每种交付方法的优缺点:

交付方法 优势 劣势
DHCP 选项 易于实施 需要更改生产 DHCP 服务。DHCP 服务可能只允许一个选项 66 条目。目标设备的 UDP/DHCP 帮助程序需要位于不同的子网上的目标。
PXE 易于实施 可能会干扰同一子网中其他正在运行的 PXE 服务。需要针对不同子网上的目标的 UDP/DHCP 帮助程序。
BDM ISO 不需要 PXE 或 TFTP 服务 引导物理目标设备需要额外努力。如果使用单个文件,BDM ISO 将被视为单一故障点。
BDM 分区 BDM 引导分区升级过程不需要使用 PXE、TFTP 或 TSB;它被视为一个单级引导程序,在系统启动时它会自动查找所有相关 PVS 服务器信息,而无需使用通过 PXE、TFTP 或 TSB 提供的外部服务。 为每个目标设备创建一个额外的 8 MB 分区。

注意

配置引导文件时,最多可以列出四个 Provisioning 服务器。Provisioning 服务器在列表中的显示顺序决定在 Provisioning 服务器访问的顺序。如果第一台服务器没有响应,则会联系列表中的下一台服务器。

决策:虚拟磁盘格式

Provisioning Services 支持固定大小或动态虚拟磁盘:

  • 固定大小的磁盘 – 对于专用模式下的虚拟磁盘,固定大小可防止磁盘碎片,并改善动态磁盘的写入性能。
  • 动态磁盘 – 与固定大小的磁盘相比,动态磁盘所需的存储空间更少,但提供显著降低的写入性能。虽然处于共享模式的虚拟磁盘不会对虚拟磁盘执行写入,但完成虚拟磁盘合并操作所需的时间会随着动态磁盘而增加。这种情况并不常见,因为更多环境在更新时选择创建新虚拟磁盘。

由于大多数读取将访问 RAM 中的系统缓存,因此,在使用固定大小的磁盘或动态磁盘时,性能不会发生重大变化。此外,动态磁盘需要的存储空间要少得多。因此,建议使用动态磁盘。

决策:虚拟磁盘复制

无论何时创建或更改虚拟磁盘,都必须在虚拟磁盘存储之间复制托管在本地、直连式存储或 SAN 上的虚拟磁盘。Provisioning Services 支持从 Provisioning 服务器的本地存储中复制虚拟磁盘,也支持跨多个使用共享存储的站点复制虚拟磁盘。虚拟磁盘的复制可以手动或自动执行:

  • 手动 – 手动复制非常简单,但可能会耗时,具体取决于虚拟磁盘和虚拟磁盘存储的数量。如果在复制过程中发生错误,管理员可以立即捕获这些错误,并采取适当的措施来解决这些问题。手动复制的风险是 Provisioning 服务器之间的虚拟磁盘不一致,这会导致负载平衡和故障转移无法正常工作。例如,如果已跨三个服务器复制虚拟磁盘,但其中一个虚拟磁盘已更新,该虚拟磁盘将不再相同,发生服务器故障转移时,该虚拟磁盘将不在考虑之列。即使对另外两个虚拟磁盘执行了相同的更新,但由于每个虚拟磁盘上的时间戳不同,因而虚拟磁盘也不再相同。
  • 自动 – 对于大型环境,由于所需的虚拟磁盘和虚拟磁盘存储的数量,自动复制速度比手动方法更快。某些自动化工具(例如 Microsoft DFS-R)支持带宽限制以及跨文件远程差分压缩 (CF-RDC),它们使用启发式方法确定目标文件是否与正在复制的文件类似。如果相似,CF-RDC 将使用这些文件中的块来最大程度地减少通过网络传输的数据量。自动复制的风险是,除非自动化工具具有警报功能,否则管理员通常不会实时监控复制事件,并且在出现错误时不会快速响应。某些工具可以配置为发生故障时自动重新启动复制过程。例如,Robocopy 在网络连接中断时支持“恢复复制”。

对于中型和大型项目,请使用工具自动执行虚拟磁盘复制。选择能够从网络中断中恢复、复制文件属性并保留原始时间戳的工具。

注意

除非虚拟磁盘具有相同的时间戳,否则负载平衡和高可用性将无法工作。

决策:服务器大小调整

通常情况下,Provisioning 服务器使用以下规范进行定义:

组件 规范
型号 虚拟
处理器 4 - 8 个 vCPU
内存 2 GB +(虚拟磁盘数量 * 2 GB)
网络 10 GBps NIC
网络 40 GB 共享存储
虚拟磁盘存储 取决于映像/修订数量
操作系统 Windows Server 2012 R2

型号

Citrix Provisioning Services 可以安装在虚拟服务器或物理服务器上:

  • 虚拟 – 提供快速服务器预配、快速恢复或回滚方案的快照以及动态调整服务器资源的功能。虚拟 Provisioning 服务器允许目标设备分布在更多服务器上,有助于减少服务器故障的影响。虚拟化可更有效地利用系统资源。
  • 物理 – 每台服务器提供比虚拟服务器更高级别的可扩展性。物理 Provisioning 服务器可减少与虚拟机竞争基础虚拟机管理程序资源相关的风险。一般情况下,能够提供足够的处理器、内存、磁盘和网络连接资源并保证可用时,首选虚拟 Provisioning 服务器。

注意

对于高可用性,请确保虚拟 Provisioning 服务器分布在多个虚拟化主机上。在多个主机之间分配虚拟服务器将消除单一故障点,并在主机发生故障时不会关闭整个 Provisioning Services 场。

CPU

Provisioning Services 不占用大量 CPU。但是,分配的 CPU 数量不足会影响网络流的优化。Provisioning Services 服务器可以并发运行的流数量可以通过以下公式确定:

最大流数量 = 端口数 x 线程/端口数

默认情况下,Streaming Service 配置了 20 个连续的网络端口,每个端口 8 个线程。因此,默认情况下,Provisioning 服务器可以支持 160 个并发目标。如果需要超过 160 个流,Provisioning Services 在通过流技术推送不同的目标设备之间持续切换

理想情况下,如果环境需要支持 160 多个并发目标,则可以在 Provisioning Services 控制台中调整端口数和每个端口的线程数。当每个端口的线程不超过 Provisioning 服务器上的可用内核数时,将获得最佳性能。如果 Provisioning 服务器没有足够的内核,服务器将显示更高的 CPU 利用率,等待处理请求的目标设备将具有更高的读取延迟。

即使 Provisioning Services 不是 CPU 密集型,分配 2 个 CPU 也需要更大的连续网络端口范围。

  • 建议使用小型环境(最多约 500 台虚拟机)4 个 vCPU。
  • 建议使用更大的环境 8 个 vCPU。

RAM

托管 Provisioning Services 的 Windows 操作系统将虚拟磁盘部分缓存到内存(系统缓存)中,从而减少需要从存储读取的次数。从存储读取比从内存读取慢得多。因此,应为 Provisioning 服务器分配足够的内存,以最大限度地利用此缓存过程的优势。

以下公式可用于确定应分配给 Provisioning 服务器的最佳内存量:

总服务器 𝑅𝐴𝑀 = 2 𝐺𝐵 + (虚拟磁盘数量 ∗ 2 𝐺𝐵)

网络

与大多数其他 XenApp 和 XenDesktop 组件不同,Provisioning Services 不会阻碍 CPU。Provisioning Services 的可扩展性基于网络吞吐量。

下表显示了 Provisioning Services 启动不同操作系统所需的大致数据量:

操作系统 平均引导数据使用量 (MB)
Windows 10 x64 240
Windows 8 x86 178
Windows 8 x64 227
Windows 7 x86 166
Windows 7 x64 210
Windows 2012 225
Windows 2012 R2 232
Windows 2008 R2 251
Windows Vista x86 190%
Windows Vista x64 240

可以使用以下公式来预估引导目标设备所需的时间:

启动公式秒数示意图

操作系统 VM 数 网络吞吐量 引导时间
Windows 10 x64 500 1 GBps 960 秒(16 分钟)
Windows 10 x64 500 10 GBps 96 秒(1 分钟 36 秒)

与 Provisioning Services 结合使用时,建议使用 10 Gbps 网络。如果 10 Gbps 网络不可用,请考虑链接聚合以向 Provisioning 服务器或专用物理流技术推送网络提供额外带宽。

提示

防火墙可以增加延迟以及在 Provisioning Services 环境中创建带宽瓶颈。如果无法避免使用防火墙,请参阅 Citrix 白皮书 CTX101810 – Citrix 技术使用的通信端口,了解应为其启用完整功能的端口列表。

增长

随着场的增长,管理员需要决定是向 Provisioning 服务器添加更多资源,还是向场添加更多 Provisioning 服务器。

在确定应纵向扩展还是横向扩展 Provisioning 服务器时,需要考虑许多环境因素:

  • 冗余 – 将用户负载分散到其他功能较差的服务器上,有助于减少受单个 Provisioning 服务器故障影响的用户数量。如果企业无法接受单个高规范服务器的损失,请考虑横向扩展。
  • 故障转移时间 – 连接到单个 Provisioning 服务器的目标设备越多,在服务器出现故障时,故障转移所需的时间就越长。请考虑横向扩展,以减少目标设备故障转移到另一台服务器所需的时间。
  • 数据中心容量 – 数据中心的可用空间、功率和/或冷却可能有限。在这种情况下,请考虑纵向扩展。
  • 硬件成本 – 最初,纵向扩展可能更具成本效益。但是,在某一点上,横向扩展实际上会变得更具成本效益。应进行成本分析以做出这一决定。
  • 托管成本 – 根据所使用的物理服务器的数量,可能存在托管和/或维护成本。如果出现这种情况,请考虑纵向扩展,以减少这些开销的长期成本。

决策:网络配置

如前所述,必须正确调整网络大小,以防止网络瓶颈导致磁盘访问时间过长,并直接影响虚拟桌面性能。下图概述了常见的 Provisioning Services 网络基础结构:

示例 PVS 网络配置示意图

建议对示意图中的网络部分大纲使用以下网络配置:

  • PVS 上行链路 – 来自目标设备的所有磁盘访问都将通过 PVS 网络上行链路传输。这意味着数百甚至数千台设备将使用此网络连接。因此,至关重要的是,此连接是冗余的,并且可以在没有任何停机的情况下进行故障转移。此外,Citrix 建议每 500 个目标设备的最低带宽为 1 Gbps。对于虚拟 Provisioning 服务器,应配置相应的 QoS 配额或专用物理网络上行链路,以确保最佳性能。
  • 虚拟机管理程序上行链路 – 由特定虚拟机管理程序主机上托管的所有 PVS 目标设备使用。因此,强烈建议使用透明故障转移进行冗余。除非目标设备运行 I/O 密集型工作负载或同时执行 I/O 密集型任务(例如引导),否则对于此上行链路,1 Gbps 的带宽就足够了。
  • VM 上行链路 – 虚拟机的所有网络流量(包括 PVS 流技术推送流量)将遍历此虚拟网络连接。除非工作负载的 I/O 非常密集,否则 100 Mbps 的带宽足以在 I/O 密集型任务(例如从虚拟磁盘启动)期间处理甚至高峰负载。例如,在显示 Windows 登录屏幕之前,Windows 2012 R2 服务器将在 90 秒内从虚拟磁盘读取大约 232 MB。在此期间,平均数据速率为 20.5 Mbps,峰值最高可达 90 Mbps。

对于 Provisioning Services,建议使用以下交换机设置:

  • 禁用跨树启用 PortFast – 在交换环境中,跨树协议 (STP) 将端口置于阻止状态,同时传输桥接协议数据单元 (BPDU) 并侦听以确保该 BPDU 不在环回配置中。在网络收敛之前,端口不会处于转发状态,这取决于网络的大小,可能会产生足够的时间导致预启动执行环境 (PXE) 超时。要消除此问题,请在连接到客户端的边缘端口上禁用 STP 或启用 PortFast。
  • 风暴控制 - 风暴控制是 Cisco 交换机上的一项功能,允许设置阈值,从而抑制多播、广播或单播流量。其目的是防止恶意或错误发件人淹没局域网并影响网络性能。PVS 服务器可能会根据设计发送大量流量且在风暴控制阈值范围内,因此应相应地配置该功能。
  • 广播助手 — 广播助手需要将广播从客户端定向到不会路由的服务器。在 PVS 环境中,当客户端与服务器不在同一子网中时,必须转发 PXE 启动请求。如果可能,建议的网络设计是将 PVS 服务器驻留在与目标设备相同的子网中。这样可以减轻因其他网络基础结构组件而导致的任何服务退化的风险。

在为 Provisioning Services 选择网络接口时,应考虑以下网络接口功能:

  • TCP 卸载 – 将 I/O 任务卸载到网络接口可降低 CPU 使用率并改善整体系统性能,但是,当启用大量发送卸载时,由于网络适配器上放置了额外的工作,PVS Streaming Services 可能会产生负面影响。默认情况下,许多网络适配器将启用大量发送卸载和 TCP 校验和卸载。

注意

如果启用了大量发送卸载功能,并且流量所传递的交换机不支持大量发送卸载引擎发送的帧大小,交换机将丢弃帧,导致数据重新传输。重新传输时,操作系统将分割帧而不是网络适配器,这可能会导致严重的性能下降。

  • 接收端缩放 (RSS) – 接收端缩放使从网络适配器接收的数据包能够在多个 CPU 之间进行平衡,从而允许对传入 TCP 连接进行负载平衡,从而防止出现瓶颈到单个 CPU。在 Windows Server 2008 R2 和 Windows Server 2012/2012 R2 中,默认情况下启用 RSS。

注意

有关 PVS 网络连接最佳做法的详细信息,请参阅在网络上配置 Provisioning Services 的最佳做法

对于在低带宽网络(1 Gbps 或更慢)上实现的 Provisioning Services,可以通过将流技术推送流量与 LAN 上的其他网络流量隔离来提高性能。

Microsoft 不支持在 Windows Server 2008 R2 上执行 NIC 与 Hyper-V 成组;但是,第三方解决方案可用。Microsoft 确实支持在 Windows Server 2012/2012 R2 上将 NIC 与 Hyper-V 成组。有关与 Hyper-V 成组的所有支持查询都应定向到 NIC OEM。

决策:子网相关性

Provisioning Services 子网相关性是一种负载平衡算法,可帮助确保目标设备连接到最合适的 Provisioning 服务器。配置子网相关性时,以下选项可用:

  • – 忽略子网;使用最空闲的服务器。
  • 最佳效果 – 使用同一子网中最空闲的服务器/NIC 组合。如果在子网中没有可用的服务器/NIC 组合,则从子网外部选择最空闲的服务器。如果在选定子网中有多台可用服务器,则在这些服务器之间执行负载平衡。此为默认设置。
  • 固定 – 使用同一子网中最空闲的服务器/NIC 组合。在该子网中的服务器之间执行负载平衡。如果在同一子网中不存在服务器/NIC 组合,则不要引导分配给该虚拟磁盘的目标设备。

以下示例显示了物理 Provisioning 服务器的常见网络配置。可以在不影响性能或功能的情况下为虚拟 Provisioning 服务器实施类似的配置。

刀片式服务器设计

Provisioning 服务器及其支持的目标设备位于同一机箱中。在大多数情况下,机箱将有一个专用 10 Gbps 交换机,在机箱内的所有刀片式服务器之间共享。

刀片式服务器外壳设计示意图

“最大努力”子网相关性选项用于将 Provisioning Services 流量保持在同一机箱内。如果 Provisioning 服务器不可用,目标将故障转移到第二个机箱中的第二个 Provisioning 服务器,但相同的 Provisioning Services 站点中。

机架设计

第二个示例基于机架设计,该设计使用机架交换机将预配流量保持在机架内。

PVS 机架设计示意图

与刀片式服务器机箱设计不同,不使用子网相关性功能。相反,每个服务器机架将配置具有两个 Provisioning 服务器的 Provisioning Services 站点。这将确保目标设备从同一机架中的 Provisioning 服务器进行流技术推送。

来自现场的经验

制造 – 一家制造公司正在设计 Provisioning Services 解决方案以支持五千个虚拟桌面。该公司担心,Provisioning Services 流技术推送流量会在网络上造成瓶颈,影响其他应用程序。该公司选择在刀片式服务器上构建环境,以便预配流量包含在刀片式服务器机柜中,并且不会影响网络上的其他流量。

决策:读取缓存

PVS 加速器允许 PVS 代理驻留在主机上的 XenServer 控制域中,其中对 Provisioning Services 虚拟磁盘的流技术推送在传输到虚拟机之前缓存在代理上。使用缓存时,相同主机上虚拟机的后续引导(或任何 I/O 请求)都可以从代理进行流技术推送,而非通过网络从服务器进行流技术推送。PVS 加速器需要 XenServer 主机上更多的本地资源,但通过网络从服务器进行流技术推送可节省资源,有效地提高了性能。

PVS 读取缓存示意图

PVS 加速器只是 XenServer 的一项功能。利用此集成技术可降低 PVS 服务器上的负载,降低总体网络利用率,并缩短引导虚拟机所需的时间。

PVS 加速器示意图

有关 XenServer 与 Provisioning Services 之间的关系的详细信息,请参阅博客 XenServer 与 PVS:更好地合作

决策:写入缓存

由于主映像是只读的,因此,每个虚拟机都有一个可写磁盘来存储所有更改。管理员必须决定写入缓存磁盘的存储位置。

PVS 服务器 – 本地存储

Provisioning Services 本地存储保存每个目标虚拟机的写入缓存驱动器。尽管这是默认设置,但它确实会增加网络带宽要求并提高 Provisioning Services 服务器的利用率。

服务器端本地存储示意图

PVS 服务器 – 共享存储

与 Provisioning Services 服务器关联的共享存储保存每个目标虚拟机的写入缓存驱动器。此选项确实会增加网络带宽要求并提高 Provisioning Services 服务器的利用率。它还会在昂贵的共享存储上放置临时数据(写入缓存)。

服务器端共享存储示意图

VM – 本地存储

与虚拟机关联的本地存储保存每个目标虚拟机的写入缓存驱动器。此选项使用低成本本地存储,并且不会占用 Provisioning Services 服务器上的其他资源。但是,本地存储必须能够支持主机上所有虚拟机的 IOPS。

VM 本地存储示意图

VM – 在 RAM 中缓存

与虚拟机关联的 RAM 保存每个目标虚拟机的写入缓存驱动器。由于 RAM 的速度,此选项可提供高性能。但是,如果 RAM 缓存空间不足,虚拟机将变得不可用。要使用此选项,必须向每个虚拟机分配大量 RAM,增加了总体成本。

RAM 中的 VM 缓存示意图

VM – 在 RAM 中缓存并溢出到磁盘

RAM 与本地存储的组合用于写入缓存。首先,写入内容存储在 RAM 缓存中,提供高性能。当消耗 RAM 缓存时,大型块将从 RAM 缓存中移除,并放置到本地存储写入缓存磁盘上。此选项提供高级别的性能和低成本的本地存储。

利用此集成技术可将写入 IOPS 减少 95%。

RAM 中的 VM 缓存示意图

“在 RAM 中缓存并溢出到磁盘”是推荐的选项。

RAM 中的 VM 缓存示意图

决策:防病毒

默认情况下,大多数防病毒产品会扫描所有文件和进程,这会对 Provisioning Services 性能产生重大影响。有关如何针对 Provisioning Services 优化防病毒软件的详细信息,请参阅 CTX124185 – Provisioning Services 防病毒最佳做法。

防病毒软件可能会导致 Provisioning 服务器上的文件锁定问题。应从防病毒扫描中排除虚拟磁盘存储和写入缓存,以防止文件争用问题。

当虚拟磁盘以标准模式运行并且需要重新启动时,将下载所有以前加载的病毒定义。这可能会在一次重新启动多个目标设备时导致性能下降,通常会在操作持续时导致网络拥塞。在极端情况下,目标设备和 Provisioning 服务器可能会变得不景气,消耗的资源超过需要。如果防病毒软件支持,应将定义文件重定向到写入缓存驱动器,以便在重新启动期间保留这些文件。

Machine Creation Services

Machine Creation Services (MCS) 使用磁盘克隆技术来简化虚拟机的部署。计算机从单个共享磁盘映像实时预配和重新预配。在这一过程中,管理员无需管理和修补各个系统,相反,管理员可以在主映像上执行所有映像管理操作。

决策:存储位置

Machine Creation Services 允许管理员将虚拟桌面拆分为多个组件,并将这些组件存储在不同的存储阵列中。

共享存储

第一个选项利用操作系统磁盘和差异磁盘的共享存储。

MCS 共享存储示意图

尽管此选项允许在多个虚拟机管理程序主机之间共享主映像,但它会给存储阵列带来更大的压力,因为它还必须托管差异磁盘(即临时数据)。

混合存储

第二个选项为操作系统磁盘使用共享存储,为差异磁盘使用本地虚拟机管理程序存储。

MCS 混合存储示意图

这是最常见的选项,为管理员提供在多个虚拟机管理程序主机之间共享主映像的优势,同时将昂贵的临时写入 IOPS 卸载到便宜的本地虚拟机管理程序存储。

XenServer IntelliCache 存储

第三个选项使用操作系统磁盘的共享存储和差异磁盘的本地虚拟机管理程序存储以及操作系统磁盘的本地缓存的本地 XenServer 存储。

这只是 XenServer 实现的一个选项。它提供了与混合存储方法相同的值,同时减少共享存储的读取 IOPS。如果 XenServer RAM 受限,IntelliCache 可以与基于 XenServer RAM 的读取缓存共存。

MCS IntelliCache 示意图

决策:克隆类型

Machine Creation Services 包含两种类型的克隆技术。

  • 精简 - 目录中的每个 VM 都使用单个只读虚拟磁盘进行所有读取。每个 VM 唯一的第二个虚拟磁盘,捕获所有写入 IO 活动。
  • 完整 - 目录中的每个 VM 都会收到主磁盘映像的完整副本。每个 VM 完全拥有磁盘,允许进行读取/写入活动。完整克隆技术仅适用于个人虚拟桌面,其中专用虚拟机将所有更改保存到本地磁盘。

管理员在决定精简克隆技术与完整克隆技术时应考虑以下几点:

  精简克隆 完整克隆
存储空间要求 节省了最大的存储空间。单个主磁盘映像在多个 VM 之间共享。只有差异磁盘(写入)占用空间,空间会持续增长,直到 VM 重新启动 存储空间要求高。每个 VM 都会收到主映像的完整副本。随着对 VM 进行更改,大小会持续增长。
备份/还原 困难。许多第三方备份/灾难恢复解决方案都不支持快照/增量磁盘,这使得精简预配的 VM 很难/无法备份或移动到其他存储阵列。 简单。VM 存在于单个虚拟磁盘中,便于备份和还原。
预配速度 快。只需要一个磁盘映像 慢(可以缓解)。每个 VM 都需要主映像的完整副本。存储优化技术可以帮助缓解。
性能 较慢。读取 I/O 可以发生两次,一次用于主磁盘,一次用于差异磁盘,从而增加读取 IOPS。 较快。所有读取/写入直接访问单个磁盘。
启动风暴 高影响。在启动风暴中,所有差异磁盘都会重新调整大小,以容纳从 Windows 启动的所有写入操作;对存储施加高负载,因为启动全部同时发生。 低影响

决策:读取缓存

在启动和登录期间,虚拟桌面会产生高水平的存储读取 IOPS,这会给底层存储子系统带来压力。在 Citrix XenServer 上部署时,共享 VDI 和池 VDI 模式会利用每个 XenServer 上托管的基于 RAM 的读取缓存。

MCS 读取缓存示意图

利用此集成技术可将读取 IOPS 减少 50-80%。

MCS 读取缓存网格示意图

决策:写入缓存

在稳定状态期间,虚拟桌面会产生高水平的存储写入 IOPS,这会给底层存储子系统带来压力。共享 VDI 和池 VDI 模式可以通过使用虚拟机操作系统中的非分页池 RAM 来利用基于 RAM 的写入缓存。

MCS 写入缓存示意图

利用此集成技术可将写入 IOPS 减少 95%。

MCS 写入缓存网格示意图

安全性

根据组织的要求,应在解决方案内实施不同的安全标准。建议参阅以下论文:

设计方法控制层