设计方法资源层

资源层是设计方法的第三层,也是专门针对用户组的最后一层。

用户对解决方案的整体接受程度由在资源层内所做的决策来定义。配置文件、打印、应用程序和整体桌面映像设计在桌面与用户组的要求的一致性方面起着关键作用,这些要求是在评估阶段确定的。

用户体验

当涉及到良好的 VDI 体验时,感知就是一切。用户期望体验类似于或优于传统物理桌面的体验。

编解码器、传输协议和自助服务功能会影响整体体验。图像质量差、视频滞后或 120 秒登录时间可能会破坏用户体验。适当的用户体验设计可以满足任何网络挑战。

决策:显示协议

选择正确的显示协议决定了用户会话中的静态图像、视频和文本的质量,以及确定对单个服务器可扩展性的影响。管理员可以选择以下选项:

  • 旧版 - 针对 Windows 7 和 Windows 2008R2 图形引擎 (GDI/GDI+) 进行了优化。
  • 桌面组合重定向 - 将桌面 Windows 管理器 DirectX 命令卸载到端点,但仅支持 Windows 桌面 VDA。此外,在 7.15 LTSR 版本中,桌面组合重定向是一项已弃用的功能。
  • Framehawk – 一种基于 UDP 的协议,能够在具有高延迟和高数据包丢失的环境中提供高刷新速率,以更高的网络带宽利用率为代价,常见于宽带无线连接。
  • H.264 – 通常称为视频编解码器,提供高质量视频所需的最高帧速率,同时节省网络带宽。它牺牲了 CPU 处理时间,降低了单个服务器的可扩展性。当用户主要使用多媒体应用程序时,H.264 是首选编解码器。
  • Thinwire – 基于 20 世纪 90 年代最初的 Citrix 专利,通过电线精简传输数据。在大多数用例中使用 Thinwire,因为它以最小的资源成本提供良好的用户体验。有两种 Thinwire 变体:
    • 旧版 - 针对 Windows 7 和 Windows 2008R2 图形引擎 (GDI/GDI+) 进行了优化。
    • Thinwire+ - 在 Windows 8、Windows 10、Windows 2012 和 Windows 2016 中针对桌面窗口管理器 (DWM) 图形引擎进行了优化
  • 选择性 H.264(自适应显示)- 同时使用多个编解码器(H.264 和 Thinwire+)用于屏幕的各部分
    • 不使用 – 仅使用 Thinwire+,不使用 H.264。最适合不使用服务器端呈现的视频或其他图形密集型应用程序的用户。
    • 针对整个屏幕 – 仅使用 H.264。最适合大量使用服务器端呈现的视频和 3D 图形的用户,特别是在低带宽情况下。
    • 针对主动变化的区域 – 对屏幕不断变化的部分使用 H.264,对屏幕的其余部分使用 Thinwire+。这是大多数用户的最佳选择。

选择正确的编解码器不仅会影响整体用户体验,还会影响服务器的可扩展性。

编解码器对单个服务器映像的影响

决策:传输协议

通过网络传输 HDX 协议有三种方法:

  • TCP – 使用行业标准 TCP 传输协议。通过局域网和低延迟广域网连接的通用传输协议,但在连接距离增加时会受到影响,从而增加延迟并导致更多的重新传输。
  • EDT – 使用基于 UDP 的 Citrix 专有传输协议,称为 Enlightened Data Transport。用于高延迟/数据包丢失网络,最常见于远距离广域网链路。为用户提供更具交互性的体验,而不会增加服务器上的 CPU 负载,但比 TCP 占用更多的网络带宽。
  • 自适应传输 – 使用 TCP 和 EDT 传输协议。除非网络不支持通过网络传输 EDT,否则使用 EDT,然后自动更改为 TCP。

大多数环境将使用自适应传输作为标准传输选项,除非网络没有打开适当的防火墙端口或恰当配置 NetScaler Gateway。

决策:登录优化

每次用户登录到 XenApp 和 XenDesktop 会话时,都必须完成登录过程,其中包括会话初始化、用户配置文件加载、组策略首选项执行、驱动器映射、打印机映射、登录脚本执行和桌面初始化。每个进程都需要时间,增加了登录持续时间。

大多数组织包括许多映射和复杂的登录脚本。执行其中的每个项目时,登录时间都会大大增加。

登录时间示意图

Workspace Environment Management 从标准登录过程中删除了驱动器映射、打印机映射、登录脚本和漫游配置文件。通过登录优化,Workspace Environment Management 会在会话和桌面初始化后在后台应用映射/脚本/配置文件。用户接收相同的环境,但他们更快地接收其桌面界面。要了解更多信息,请查看以下 登录优化 视频。

大多数环境应启用登录优化作为默认配置。

决策:用户自助服务

自助服务允许用户自行修改、更新环境并进行故障排除,而无需帮助桌面干预。大多数组织都有要求用户每隔 60 到 90 天更改一次密码的策略。当用户拥有多个具有保存的密码的端点时,在更新每个设备之前,其帐户非常容易被锁定。

使用 StoreFront,可以通过使用以下功能自行维护自己的帐户来节省时间:

  • 帐户解锁 – 当用户的帐户由于登录尝试失败次数过多(常见于多个设备)而被锁定时,如果他们知道安全问题的答案,则可以解锁帐户。
  • 密码重置 – 当用户忘记了新创建的密码时,如果他们知道安全问题的答案,则可以重置其密码。

自助服务密码重置体系结构引入了 SSPR 服务、中央存储和两个帐户:

  • 数据代理帐户 – 负责访问中央存储,其中包含用户安全问题的加密答案。
  • 自助服务帐户 – 具有密码重置和帐户解锁权限的 Active Directory (AD) 帐户。

SSPR 体系结构示意图

此外,正确设计自助服务密码重置要求管理员创建用户将回答的安全问题。理想情况下,管理员应围绕不同类别创建问题组,而非要求用户回答每个组的一部分问题。问题必须是用户知道不会发生变化而其他人不知道的内容。

用户配置文件

用户的配置文件对于在虚拟桌面或虚拟应用程序场景中提供始终如一的正面体验起着至关重要的作用。如果用户由于登录时间过长或设置丢失而感到沮丧,即使是精心设计的虚拟桌面解决方案也会失败。

所选的用户配置文件解决方案必须与评估阶段捕获的用户组的个性化特征以及所选的 VDI 模型保持一致。

决策:配置文件类型

本部分内容概述了可用的不同配置文件类型,并提供了关于每个 VDI 模型的最佳用户配置文件的指导。

  • 本地配置文件 – 本地配置文件存储在每个服务器或桌面操作系统上,并且最初基于默认用户配置文件创建。因此,访问这些资源的用户将在每个系统中创建一个独立的配置文件。用户能够将对其本地配置文件所做的更改保留在每个服务器上,但这些更改只能在该系统上未来的会话中进行访问。本地配置文件不需要配置;如果登录到服务器或桌面操作系统的用户没有以管理方式定义的配置文件路径,则默认情况下会创建本地配置文件。
  • 漫游配置文件 – 漫游配置文件存储在每个用户的集中网络存储库中。漫游配置文件与本地配置文件不同,因为配置文件中的信息(无论是打印机、注册表设置还是存储在文档文件夹中的文件)可以提供给从环境中的所有系统访问的用户会话。为漫游配置文件配置用户需要管理员指定指向特定网络共享的用户配置文件路径(对于虚拟桌面)或终端服务器配置文件路径。用户首次登录服务器或桌面操作系统时,系统使用默认的用户配置文件来创建该用户的漫游配置文件。注销时,会将该配置文件复制到管理员指定的网络位置。
  • 强制配置文件 – 强制配置文件通常存储在许多用户的中央位置。但是,注销时不会保留用户的更改。为强制配置文件配置用户需要管理员从现有的漫游或本地配置文件创建强制配置文件文件 (NTUSER.MAN),并分配具有终端服务配置文件路径的用户。这可以通过 Microsoft 组策略来实现,方法是在 Active Directory 或 Citrix Profile Management 中自定义用户属性。

  • 混合配置文件 – 混合配置文件将强大的配置文件核心(强制配置文件或本地默认配置文件)与用户特定的注册表项或登录期间合并的文件组合在一起。此技术使管理员能够严格控制保留哪些更改,并使用户配置文件的大小保持较小。此外,混合配置文件使用成熟的排队技术解决后写入内容有效问题,这些技术可以自动检测和防止可能会覆盖在另一个会话中所做的更改的同时写入。这样将最大限度地减少用户在同时访问多个服务器或虚拟桌面时因丢失配置文件更改而产生的挫折。此外,它们仅捕获和记录配置文件中的更改,而不是在注销时写入整个配置文件。混合配置文件解决方案的一个很好的例子是 Citrix Profile Management,将在本章中详细讨论该解决方案。

下表比较了每种配置文件类型的功能。

在此表中:

  • Y 表示功能可用。
  • o 表示可选。
  • N 表示功能不可用。
功能 本地 漫游 强制 混合
集中管理/随用户漫游 N Y o
用户设置永久存储 Y Y N
精细捕获用户设置 N N N

为了为每个用户组选择最佳配置文件类型,除了分配的 VDI 模型之外,还必须了解其个性化要求。

下表提供了根据 VDI 资源选择恰当的用户配置文件类型的建议:

在此表中:

  • Y 表示推荐。
  • X表示不推荐。
  • o 表示可行。

需要用户设置持久性(个性化特征:基本/完整)

本地 漫游 强制 混合  
托管 Windows 应用程序 X Y X Y
托管浏览器应用程序 X Y X Y
托管共享桌面 X Y X Y
托管池桌面 X Y X Y
托管个人桌面 º Y X Y
托管专业图形桌面 º Y X Y
本地流桌面 X Y X Y
本地 VM 桌面 Y º X º
Remote PC Access Y º X º

需要用户设置持久性或用户设置持久性必需(个性化特征:无)

本地 漫游 强制 混合  
托管 Windows 应用程序 X X Y X
托管浏览器应用程序 X X Y X
托管共享桌面 X X Y X
托管池桌面 Y X Y X
托管个人桌面 X X Y X
托管专业图形桌面 º X Y X
本地流桌面 Y X Y X
本地 VM 桌面 º X Y X
Remote PC Access º X Y X

决策:文件夹重定向

重定向特殊文件夹可以补充任何描述的配置文件类型。将配置文件文件夹(例如用户文档和收藏夹)重定向到网络共享是最大限度地减少配置文件大小的良好做法,但架构师需要注意,应用程序可能会频繁读取和写入数据到配置文件文件夹(例如 AppData),从而导致文件服务器利用率和响应能力出现潜在的问题。在生产环境中实施之前彻底测试配置文件重定向以避免出现这些问题非常重要。因此,在开始移动到生产环境之前,研究配置文件读取/写入活动和进行试验是非常重要的。Microsoft Outlook 是定期执行配置文件读取活动的应用程序的示例,因为每次创建电子邮件时都会从用户配置文件中读取用户签名。

下表提供了一般建议,以帮助确定要重定向的相应文件夹:

在此表中:

  • Y 表示推荐。
  • X表示不推荐。
  • o 表示可行。
文件夹 本地 漫游 强制 混合
应用程序数据 X o X o
通讯录 X Y X o
桌面 X Y X o
下载 X o X o
收藏夹 o Y o Y
链接 X Y X o
我的文档 o Y o Y
我的音乐 o Y o o
我的图片 o Y o o
我的视频 o Y o o
保存的游戏 X o X o
搜索 X Y X o
“开始”菜单 X X X X

决策:文件夹排除

排除文件夹永久存储为漫游配置文件或混合配置文件的一部分有助于减少配置文件大小和登录时间。默认情况下,Windows 排除 AppData\Local 和 AppData\LocalLow 文件夹,包括所有子文件夹,例如 History、Temp 和 Temporary Internet 文件。此外,下载和保存的游戏文件夹也应排除在外。应将重定向的所有文件夹从配置文件解决方案中排除。

决策:配置文件缓存

服务器或虚拟桌面上的漫游或混合用户配置文件的本地缓存是默认的 Windows 行为,可以减少登录时间和文件服务器利用率/网络流量。使用配置文件缓存,系统只需下载对配置文件所做的更改。配置文件缓存的缺点是可能会占用多用户系统(例如托管共享桌面主机)上的大量本地磁盘存储。

在某些 VDI 模型和配置中,VDI 资源将重置为原始状态。注销时删除本地缓存的配置文件是不必要的资源消耗。基于此,领先的建议是不删除以下 VDI 模型的本地缓存配置文件:

  • 托管个人桌面
  • 托管池桌面 – 仅在注销后重新启动的情况下使用。
  • 本地 VM 桌面
  • Remote PC Access

配置“删除缓存的配置文件之前的延迟”Citrix 策略将设置在注销时删除本地缓存的配置文件之前的延迟的可选延迟时间。如果注销期间进程会使文件或用户注册表配置单元处于打开状态,延长延迟时间将很有用。这样也可以减少大型配置文件的注销时间。

决策:配置文件权限

出于安全原因,默认情况下,管理员无法访问用户配置文件。虽然处理非常敏感数据的组织可能需要这种级别的安全性,但对于大多数环境来说是不必要的,并且可能会使操作和维护复杂化。因此,请考虑启用“将 Administrators 安全组添加到漫游用户配置文件”策略设置。此策略的配置应与评估阶段捕获的用户组的安全特性保持一致。有关托管用户配置文件和数据的文件共享所需的权限的详细信息,请参阅 Microsoft TechNet - 部署漫游配置文件

决策:配置文件路径

确定用户配置文件的网络路径是用户配置文件设计过程中最重要的决策之一。一般情况下,强烈建议使用冗余和高性能的文件服务器或 NAS 设备。 配置文件共享必须考虑四个主题:

  • 性能 – 文件服务器性能将影响登录和注销时间,并且可能会影响用户在会话中的体验,具体取决于其他决策(例如重定向的文件夹和配置文件流技术推送)。对于大型虚拟桌面基础结构,单个文件服务器群集可能不足以处理高峰活动时间段。为了在多个文件服务器上分配负载,需要调整文件服务器地址和共享名称。
  • 位置 – 用户配置文件通过 SMA 协议通过网络传输,在高延迟网络连接中运行不佳。此外,广域网连接通常受带宽限制,这可能会为配置文件加载过程增加额外的延迟时间。因此,文件服务器应位于靠近服务器和虚拟桌面的位置,以尽量缩短登录时间。
  • 操作系统平台 – 用户配置文件与基础操作系统紧密集成,不支持在不同的操作系统或不同的平台(例如 64 位 (x64) 和 32 位 (x86))上重复使用单个用户配置文件。

有关详细信息,请参阅 Microsoft 知识库文章 KB2384951 – 共享 32 位和 64 位用户配置文件。Windows 2008 和 Windows Vista 引入了新的用户配置文件结构,该结构可以通过 .V2 配置文件目录后缀进行识别,这使得较旧的用户配置文件与较新的操作系统(例如 Windows 2012、7 和 8)不兼容。为了确保每个平台使用单独的配置文件,必须调整配置文件目录。

  • 索引功能 – 要充分利用有关用户重定向数据的 Windows 搜索功能,必须使用用于创建用户数据索引的 Windows 文件服务器,而非使用 NAS 设备上的共享。这对于严重依赖 Windows 搜索或对缓慢或延迟感知特别敏感的用例非常重要

有两种方法可用于解决这些基于 Windows 内置技术的挑战:

  • 用户对象 – 对于 Active Directory 中的每个用户对象,可以指定包含文件服务器名称和配置文件目录的单个配置文件路径。由于每个用户对象只能指定单个配置文件路径,因此无法确保为每个操作系统平台加载单独的配置文件。
  • 计算机组策略系统变量 – 用户配置文件路径也可以通过特定于计算机的组策略或系统变量进行配置。这使管理员能够确保用户配置文件专用于该平台。由于计算机特定的配置会影响系统的所有用户,因此,所有用户配置文件都将写入同一文件服务器。要在多个服务器之间对用户配置文件进行负载平衡,必须为每个文件服务器创建专用 XenDesktop 交付组。

注意:对于主动使用的用户配置文件,Microsoft 不支持 DFS-N 与 DFS-R 结合使用。

有关详细信息,请参阅以下 Microsoft 文章:

使用 Citrix Profile Management 时,可以使用第三个选项来应对这些挑战:

用户对象属性和变量 – 使用 Citrix Profile Management,管理员可以通过计算机组策略配置配置文件路径,方法是使用 Active Directory 中用户对象的属性动态指定文件服务器。为了实现这一目标,需要执行三个步骤:

  1. 创建引用实际文件服务器的 DNS 别名(例如,fileserver1)
  2. 使用 DNS 别名填充用户对象的空 LDAP 属性(例如,l 或 UID)
  3. 通过 GPO 配置 Citrix Profile Management,以使用引用 LDAP 属性的配置文件路径(例如,如果使用属性 UID,则配置文件路径变为 \#UlD\#\Profiles\profiledirectory)

此外,Citrix Profile Management 会自动填充变量以基于操作系统平台动态指定配置文件路径。有效的 Profile Management 变量包括:

  • !CTX_PROFILEVER! – 扩展到 v1 或 v2,具体取决于配置文件版本。
  • !CTX_OSBITNESS! – 扩展到 x86 或 x64,具体取决于操作系统的位级别。
  • !CTX_OSNAME! – 扩展到操作系统的短名称,例如 Windows 7。

通过结合 Citrix Profile Management 的这两种功能,可以创建一个完全动态的用户配置文件路径,该路径可以在多个文件服务器上进行负载平衡,并确保不混合不同操作系统平台的配置文件。完全动态的用户配置文件路径的示例如下所示:

\#UID#\profiles$%USERNAME%.%USERDOMAIN%\!CTX_OSNAME!!CTX_OSBITNESS!

决策:配置文件流技术推送

注意:以下设计决策仅适用于使用 Citrix Profile Management 的环境。

通过用户配置文件流技术推送,当用户访问配置文件中包含的文件和文件夹时,将从用户存储(文件服务器)提取到本地计算机。在登录过程中,Citrix Profile Management 会立即报告配置文件加载过程已完成,将配置文件加载时间减少到几乎为零。

Citrix 建议为所有方案启用配置文件流技术推送。如果出于性能原因需要保留用户配置文件的本地缓存副本,建议启用“始终缓存”设置并将大小配置为 0。这样可以确保在后台下载用户配置文件,并使系统能够继续使用此缓存副本。

来自现场的经验

  • 常规 – 如果某些编写不佳的 AppData 已通过流技术推送到 VDI 资源,则其加载速度可能会更快。启用配置文件六级水推送的“始终缓存”选项可帮助提高未重定向 AppData 文件夹时的性能。

决策:主动写回

注意:以下设计决策仅适用于使用 Citrix Profile Management 的环境。

通过启用主动写回功能,Citrix Profile Manager 在应用程序写入并关闭文件时执行检测,并将该文件复制回配置文件中。在单个用户同时利用多个虚拟桌面或托管共享桌面的情况下,此功能将非常有用。但是,Citrix Profile Management 不会将任何注册表更改复制回网络,按顺序注销过程中除外。因此,存在注册表和文件可能无法在非持久性系统中对齐的风险,其中本地缓存的配置文件信息在重新启动时被擦除。因此,建议禁用非持久性场景的主动写回功能。

决策:配置方法

注意:以下设计决策仅适用于使用 Citrix Profile Management 的环境。

Citrix Profile Management 可以通过“.ini”文件、Microsoft 组策略和 Citrix 策略(Citrix Profile Management 5.0 及更新版本)进行配置。虽然每个选项都提供相同的配置设置,但建议使用组策略,因为它允许管理员从单个点执行 Windows 和 Citrix 配置文件配置,从而最大限度地减少配置文件管理所需的工具。

注意:使用 Citrix Profile Management 5.0 及更新版本,系统会自动检测桌面类型,并相应地设置 Citrix Profile Management 策略。有关详细信息,请参阅 Citrix 文档 – 自动配置的工作原理

决策:复制

虽然使用 GSLB 可以轻松实现网络级别的主动/主动数据中心,但用户数据的复制使得在大多数情况下具有完全主动/主动部署的复杂性。要具有用户不静态分配到特定数据中心的主动/主动配置,需要用户不具备任何形式的个性化要求。这将限制用户进行任何配置更改的能力,并且不允许用户创建任何文档或静态数据。当数据中心之间有高速、低延迟连接(例如暗光纤)可用时,会出现例外情况。这将让两个位置中的资源可以指向同一个文件服务器,从而实现真正的主动/主动解决方案。此外,如果应用程序仅依赖于在数据中心之间主动复制的后端数据库,并且不将任何数据存储在用户配置文件中,则可以完成主动/主动配置。

出于冗余和故障转移的目的,应在数据中心之间同步用户数据(例如 Windows 配置文件和文档)。尽管建议在数据中心之间复制用户数据,但复制将是主动/被动配置。这意味着只能从单个数据中心主动使用数据。此限制的原因是 Windows 中仅允许单个用户主动写入文件的分布式文件锁定方法。因此,不支持用户数据的主动/主动复制。任何支持的配置都包含在任何时间点在单个数据中心中处于活动状态的数据的单向复制。

例如,下图描述了用户数据被动地从数据中心 A 复制到数据中心 B 的场景。在此示例中,文件服务器 A 是数据中心 A 中的用户数据的主要位置,文件服务器 B 是数据中心 B 中的主要位置。用户数据单向复制 ,以便在发生故障转移时允许用户数据在相反的数据中心可用。复制技术(例如 Microsoft DFS)可以配置为将用户配置文件和文档镜像到另一个数据中心中的文件服务器。DFS 命名空间也可用于为用户数据位置提供无缝路径。但是,实现此类复制解决方案需要熟悉 Microsoft DFS 和用户配置文件的管理员。

数据中心示意图

用户数据

为了有效,用户必须访问其数据。数据必须靠近应用程序,用户才能获得良好的体验。随着应用程序与数据之间的距离的增加,延迟也会增加,这会减慢任何文件操作(打开、保存、修改)。

在基于 VDI 的环境中,管理员必须了解用户存储其数据的位置以及访问的影响。

决策:用户数据位置

用户传统上将其数据存储在本地设备或指定了驱动器映射的网络文件服务器上。由于 IT 存储空间限制或无法让数据随用户转移到其他移动设备,用户转而使用免费的基于云的存储产品,例如 OneDrive、DropBox 和 Box。要访问数据,用户将在其传统 Windows PC 上安装存储供应商的代理,从而允许其直接访问云托管存储库。

管理员必须通过查看以下选项来设计解决方案以考虑到用户存储:

  • 多代理策略 – 在 VDI 中,用户要求管理员为每个存储提供程序安装和配置代理,这假定存储代理支持非持久性 VDI 模型。每个代理都是管理员必须管理和维护的新应用程序。
  • 存储连接器策略 – 单个代理将来自众多云托管和本地提供商的存储库整合到一个文件夹结构中。例如,当用户连接到 Citrix ShareFile 时,他们将看到一个统一的文件夹结构,其中包含来自云(ShareFile、OneDrive、DropBox、Box 和 Google Drive)和来自本地(SharePoint、Windows 网络共享和本地端点共享)的用户数据。

决策:用户数据访问

VDI 解决方案成功的一个关键方面是用户体验与传统 PC 保持相同。如果用户从应用程序中打开文件,则该功能必须继续运行。如果用户使用资源管理器导航以访问文件,则该功能必须继续运行。

用户的数据可以存在于本地 PC 上、网络文件共享上以及托管在云中。

日期存储位置示意图

通过向用户提供的本地 PC、本地网络共享和云托管存储选项,管理员需要了解用户访问其数据如何影响基础结构和 VDI 体验。

  • 直接数据访问 – 用户访问远程服务器(本地 Windows 服务器或云托管存储提供程序)上的文件。应用程序与文件之间的距离直接影响体验。较长的距离等同于更高的延迟。随着应用程序与文件存储之间的延迟增加,每个文件操作(导航、打开、关闭、保存等)需要更多时间。Windows 文件服务器通常与用户的 VDI 桌面位于同一数据中心中,因此直接访问数据是可行的;但是,如果 VDI 桌面与存储库之间的连接具有高延迟,则云托管解决方案与本地 PC 访问的响应时间会较长。
  • 本地同步 – 使用传统 PC,用户习惯于将文件本地化,从而减轻由于极低延迟而导致的任何缓慢的应用程序响应时间。许多云托管解决方案提供数据同步,以启用与本地存储模型类似的访问速度。许多云托管解决方案为某些文件夹和文件提供完全同步或用户配置的部分同步。使用部分同步时,只有同步的文件在设备上可见并可访问,从而导致用户混淆。完全同步和部分同步会增加 VDI 成本。每个会话都是全新的桌面,需要同步用户的文件夹/文件,这需要时间、网络带宽和 VDI 存储空间。在 VDI 会话期间,同步到 VDI 桌面的每个文件都必须存储在组织的数据中心中。
  • 按需同步 – 在浏览资源管理器时,用户会看到一个完整但虚拟的文件/文件夹结构,即使桌面上实际不存在这些文件/文件夹亦如此。选择文件将开始自动同步到该单个文件的 VDI 桌面。此时,文件访问在本地进行,这会创建像传统 PC 一样的用户体验。当用户保存或关闭文件时,文件将同步回云。仅同步访问的文件,这消除了本地数据访问模式产生的浪费情况。Citrix ShareFile 包括 Drive Mapper,允许用户通过资源管理器与其数据进行交互,同时在访问文件时利用按需同步。由于只有访问的文件同步,因此对底层存储基础结构和关联的存储成本的影响最小。

在此表中:

  • Y 表示推荐。
  • N 表示不推荐。
  直接数据访问 本地同步 按需同步
网络文件服务器 Y    
云托管 N N Y
本地 PC N N Y

决策:数据恢复

文件损坏是大多数用户遇到的问题。错误地关闭应用程序或 PC(点击电源按钮而非关闭应用程序并正常关闭操作系统)通常会导致许多损坏问题。

有几个选项可为用户提供数据恢复选项:

  • 多文件 – 使用传统 PC,如果文件是本地文件,用户几乎没有恢复选项。用户通常每天手动创建文件的新副本,以提供某种程度的恢复。此解决方案很难管理。
  • 备份/还原 – 管理员可以实施备份和还原解决方案,以帮助进行文件恢复。但是,这些解决方案很少适用于本地文件,对于网络文件共享,备份过程通常仅每晚或每周运行。此外,还原损坏的文件需要用户呼叫支持人员。
  • 版本控制 – 云托管选项(例如 Citrix ShareFile)包括文件版本控制,这会在保存更改时自动创建文件的新版本。版本控制不需要用户干预,并且允许用户快速从损坏中恢复,并且不会丢失数据。

ShareFile 版本控制示意图

策略

策略提供配置和微调 XenApp 和 XenDesktop 环境的基础,允许组织根据用户、设备或连接类型的各种组合来控制连接、安全和带宽设置。

在做出策略决策时,必须同时考虑 Microsoft 和 Citrix 策略,以确保考虑所有用户体验、安全性和优化设置。有关所有 Citrix 相关策略的列表,请参阅 Citrix 策略设置参考

决策:首选策略引擎

组织可以选择通过 Citrix Studio 或使用 Citrix ADMX 文件通过 Active Directory 组策略配置 Citrix 策略,这些文件可扩展组策略并提供高级筛选机制。

使用 Active Directory 组策略,组织可以在同一位置同时管理 Windows 策略和 Citrix 策略,并最大限度地减少策略管理所需的管理工具。组策略会自动跨域控制器复制,从而保护信息并简化策略应用过程。

如果 Citrix 管理员无法访问 Active Directory 策略,则应使用 Citrix 管理控制台。架构师应根据组织的需求选择上述两种方法之一,并始终使用该方法以避免与多个 Citrix 策略位置混淆。

必须了解策略的聚合(称为策略优先级)是如何流动的,以便了解由此产生的一套策略是如何创建的。使用 Active Directory 和 Citrix 策略时,优先级如下所示:

策略优先级 策略类型
第一个处理(最低优先级) 本地服务器策略
第二个处理 使用 Citrix 管理控制台创建的 Citrix 策略
第三个处理 站点级别 AD 策略
第四个处理 域级别 AD 策略
第五个处理 域中最高级别的 OU
第六个和后续处理 域中的下一级 OU
最后一个处理(最高优先级) 包含对象的最低级别 OU

每个级别的策略将聚合到应用于用户或计算机的最终策略中。在大多数企业部署中,Citrix 管理员没有权限更改其特定 OU 之外的策略,这通常是优先级的最高级别。在需要例外的情况下,可以使用“块继承”和“无覆盖”设置来管理从 OU 树上较高的策略设置的应用程序。阻止继承会停止将更高级别的 OU(优先级较低)的设置纳入策略。但是,如果配置了无覆盖的更高级别的 OU 策略,则不会应用块继承设置。鉴于此,在策略规划时必须小心谨慎,并且应使用“Active Directory 策略结果集”工具或“Citrix 组策略建模”向导等可用工具来验证观察到的结果以及预期结果。

注意

某些 Citrix 策略设置(如果使用)需要通过 Active Directory 组策略(例如 Controller 和 Controller 注册端口)进行配置,因为 VDA 需要这些设置才能注册。

决策:策略集成

配置策略时,组织通常需要 Active Directory 策略和 Citrix 策略来创建完全配置的环境。使用两个策略集时,由此产生的策略集可能会引起难以确定的混淆。在某些情况下,特别是对于 Windows 远程桌面服务 (RDS) 和 Citrix 策略,可以在两个不同的位置配置类似的功能。例如,可以在 Citrix 策略中启用客户端驱动器映射,并在 RDS 策略中禁用客户端驱动器映射。使用所需功能的能力可能取决于 RDS 和 Citrix 策略的组合。必须了解 Citrix 策略是基于远程桌面服务中的可用功能构建的。如果在 RDS 策略中显式禁用了所需的功能,Citrix 策略将无法影响配置,因为基础功能已被禁用。

为了避免这种混淆,建议仅在需要时配置 RDS 策略,并且 XenApp 和 XenDesktop 配置中没有相应的策略,或者在组织内使用 RDS 是需要专门配置的。以最高通用标准配置策略将简化了解由此产生的策略集和策略配置故障排除的过程。

决策:策略作用域

创建策略后,需要根据所需结果将这些策略应用于用户组和/或计算机。策略筛选提供了针对所需用户或计算机组应用策略的功能。使用基于 Active Directory 的策略时,关键决策是是否将策略应用于站点、域或组织单位 (OU) 对象中的计算机或用户。Active Directory 策略分为计算机配置和用户配置。默认情况下,用户配置中的设置适用于登录时驻留在 OU 中的用户,计算机配置中的设置在系统启动时应用于计算机,并将影响登录到系统的所有用户。与 Active Directory 和 Citrix 部署策略关联的一个挑战围绕三个核心领域:

  • Citrix 环境特定的计算机策略 – Citrix 服务器和虚拟桌面通常具有专为环境创建和部署的计算机策略。通过为服务器和虚拟机创建单独的 OU 结构,可以轻松应用这些策略。然后,可以创建特定策略并将其自信地应用到 OU 及其下方的计算机,而非其他对象。根据要求,虚拟桌面和服务器可能会在 OU 结构中根据服务器角色、地理位置或业务部门进一步细分。
  • Citrix 特定的用户策略 – 为 XenApp 和 XenDesktop 创建策略时,会根据用户的连接应用许多特定于用户体验和安全性的策略。但是,用户的帐户可能位于 Active Directory 结构中的任何位置,因此仅应用基于用户配置的策略会造成困难。不宜在域级别应用 Citrix 特定的配置,因为这些设置将应用于任何用户登录到的每个系统。仅在 Citrix 服务器或虚拟桌面所在的 OU 上应用用户配置设置也不起作用,因为用户帐户不位于该 OU 中。解决方案为应用环回策略,这是一种计算机配置策略,该策略强制计算机将 OU 分配的用户配置策略应用于登录到服务器或虚拟桌面的任何用户,而不管用户在 Active Directory 中的位置如何。环回处理可以通过合并或替换设置应用。使用替换会使用 Citrix 服务器或虚拟桌面 OU 中的策略覆盖整个用户 GPO。合并会将用户 GPO 与 Citrix 服务器或桌面 OU 中的 GPO 结合使用。由于在使用合并时在用户 GPO 之后处理计算机 GPO,因此,Citrix 相关的 OU 设置将具有优先级并在发生冲突时应用。有关详细信息,请参阅 Microsoft TechNet 文章 - 了解用户组策略环回模式
  • Active Directory 策略筛选 – 在更高级的情况下,可能需要将策略设置应用到一小部分用户(例如 Citrix 管理员)。在这种情况下,环回处理不起作用,因为该策略仅应应用于用户子集,而非所有登录到系统的用户。Active Directory 策略筛选可用于指定应用策略的特定用户或用户组。可以为特定函数创建策略,然后可以将策略过滤器设置为仅将该策略应用于一组用户(例如 Citrix 管理员)。策略筛选是使用每个目标策略的安全属性完成的。

使用 Citrix Studio 创建的 Citrix 策略具有可用的特定过滤器设置,可用于解决无法使用组策略进行处理的策略筛选情况。可以使用以下过滤器的任意组合应用 Citrix 策略:

过滤器名称 过滤器说明 作用域
访问控制 基于访问控制条件(客户端借此进行连接)应用策略。例如,通过 Citrix NetScaler Gateway 连接的用户可以应用特定的策略。 用户设置
Citrix CloudBridge 基于用户会话是否通过 Citrix CloudBridge 启动来应用策略。 用户设置
客户端 IP 地址 基于用于连接会话的用户设备的 IPv4 或 IPv6 地址应用策略。如果使用 IPv4 地址范围以避免出现意外结果,请谨慎使用此过滤器。 用户设置
客户端名称 基于连接会话所用的用户设备的名称应用策略。 用户设置
交付组 基于运行会话的桌面的交付组成员身份来应用策略。 用户设置
交付组类型 基于运行会话的计算机的类型应用策略。例如,可以根据桌面是池桌面、专用桌面还是流桌面来设置不同的策略。 用户和计算机设置
组织单位 基于运行会话的桌面或服务器的 OU 来应用策略。 用户和计算机设置
标记 基于应用于运行会话的桌面的任何标记应用策略。标记是可以添加到 XenDesktop 环境中的虚拟桌面的字符串,可用于搜索或限制对桌面的访问。 用户和计算机设置
用户或组 基于连接到会话的用户的 Active Directory 组成员身份应用策略。 用户设置

注意

XenDesktop 7.x 中的 Citrix 策略提供了在用户和计算机级别应用的设置的合并视图。在表 24 中,“作用域”列指示指定的过滤器是应用于用户设置、计算机设置还是两者。

决策:基准策略

基准策略应包含为组织内的大多数用户提供高清晰度体验所需的所有共同要素。基准策略为用户访问以及可能需要创建的任何例外情况创建基础,以满足用户组的特定访问要求。基准策略应是全面的,涵盖尽可能多的用例,并应具有最低优先级,例如 99(优先级数“1”是最高优先级),以便尽可能建立最简单的策略结构,避免在确定由此产生的一套策略时出现困难。Citrix 提供的作为默认策略的未筛选策略集可用于创建应用于所有用户和连接的基准策略。在基准配置中,应启用所有 Citrix 策略设置,甚至使用默认值配置的策略设置,以便显式定义所需/预期行为,并在默认设置随时间变化时避免混淆。

Citrix 策略模板可用于配置 Citrix 策略,以有效管理环境中的最终用户体验,并且可以作为基准策略的初始起点。模板由用于在特定环境或网络条件下优化性能的各种预配置设置组成。XenDesktop 中包含的内置模板如下所示:

内置模板 说明
高清晰度用户体验 包含的设置可向用户提供高质量的音频、图形和视频。
高服务器可扩展性 包含的设置可在单台服务器上托管多位用户并提供经过优化的用户体验。
经过优化的广域网带宽 包含的“计算机”设置和“用户”设置可在低带宽连接或高延迟连接条件下向用户提供经过优化的体验。
安全性与控制 包含的设置可在用户设备上禁用对外围设备的访问、驱动器映射、端口重定向以及 Flash 加速。

有关 Citrix 策略模板的详细信息,请参阅 Citrix Docs - 管理 Citrix 策略模板

基准策略配置还应包括 Windows 策略。Windows 策略反映用户特定的设置,这些设置可优化用户体验,并删除 XenDesktop 环境中不需要的功能。例如,在这些环境中关闭的一个常见功能是 Windows 更新。在虚拟化环境中,特别是在桌面和服务器可能通过流技术传输并且非持久的环境中,Windows 更新会创建处理和网络开销,并且更新过程所做的更改不会持续重新启动虚拟桌面或应用程序服务器。此外,在许多情况下,组织使用 Windows 软件更新服务 (WSUS) 来控制 Windows 更新。在这些情况下,更新将应用于主磁盘,并由 IT 部门按计划提供。

除上述注意事项外,组织的最终基准策略可能包括专门为满足安全要求、常见网络条件或管理用户设备或用户配置文件要求而创建的设置:

打印

Citrix XenApp 和 Citrix XenDesktop 支持各种不同的打印解决方案。为了规划和成功实施正确的打印解决方案,重要的是要了解可用的技术及其优点和局限性。

决策:打印机预配

在 XenApp 或 XenDesktop 会话开始时创建打印机的过程称为打印机预配。有多种方法可用:

  • 用户添加 – 允许用户手动添加打印机使其能够灵活地选择打印机。手动添加基于网络的打印机的缺点是要求用户知道打印机的网络名称或路径。此外,操作系统中还可能未安装本机打印驱动程序,并且 Citrix 通用打印驱动程序不兼容,因此要求用户寻求管理帮助。手动添加打印机最适合以下情形:
    • 用户使用同一客户端设备(即便携式计算机、平板电脑)在不同位置之间漫游。
    • 用户在分配的工作站或打印机分配很少改变的区域工作。
    • 用户拥有具有足够的权限来安装必要的打印机驱动程序的个人桌面。
  • 自动创建 – 自动创建是一种动态预配形式,用于尝试在用户会话开始时在客户端设备上创建部分或全部可用的打印机。这包括本地连接的打印机以及基于网络的打印机。自动创建所有客户端打印机会增加会话登录时间,因为每台打印机都在登录过程中枚举。
  • 基于会话 – 会话打印机是在每个会话开始时通过 Citrix 策略分配给用户的一组基于网络的打印机。
    • 基于邻近的会话打印机按 IP 子网进行筛选。在此策略下创建的网络打印机可能因用户的端点设备所在位置而异。在以下情况下,建议进行邻近打印:用户使用相同的端点设备(即便携式计算机、平板电脑)在不同位置之间漫游,并且使用瘦客户端(无法直接连接到基于网络的打印机)。
    • 可以使用“会话打印机”策略或“打印机分配”策略分配会话打印机。“会话打印机”策略用于为场、站点、大型组或 OU 设置默认打印机。“打印机分配”策略用于将一大组打印机分配给多个用户。如果启用并配置了这两个策略,会话打印机将合并为一个列表。
  • 通用打印机 – Citrix 通用打印机是在会话开始时自动创建并且未链接到打印设备的通用打印机对象。使用 Citrix 通用打印机时,不需要在登录期间枚举可用的客户端打印机,这样可以大大降低资源使用情况并降低用户登录次数。默认情况下,Citrix 通用打印机将打印到客户端的默认打印机,但可以修改行为以允许用户选择任何兼容的本地打印机或基于网络的打印机。

Citrix 通用打印机最适合以下情形:

  • 用户需要访问多个本地和基于网络的打印机,这些打印机可能因每个会话而异。
  • 用户的登录性能是第一优先级,并且由于应用程序兼容性,必须启用 Citrix 策略“等待创建打印机”。
  • 用户正在使用基于 Windows 的设备或瘦客户端进行工作。

注意

可用于预配打印机的其他选项(例如 Active Directory 组策略、“跟随我”集中式打印队列解决方案和其他第三方打印管理解决方案)可用于将打印机预配到 Citrix 会话中。

决策:打印机驱动程序

在 XenApp 和 XenDesktop 中管理打印驱动程序可能是一项繁琐的任务,特别是在拥有数百台打印机的大型环境中。在 XenApp 和 XenDesktop 中,有多种方法可用于帮助管理打印驱动程序。

  • 用户安装的 – 在 XenApp 或 XenDesktop 会话中添加打印机并且本机打印驱动程序不可用时,可以由用户手动安装驱动程序。许多不同的打印驱动程序可能安装在不同的资源上,因而在环境中造成了不一致。打印问题故障排除和维护打印驱动程序可能会变得非常困难,因为每个托管资源都可能安装了不同的打印驱动程序集。为确保一致性并简化支持和故障排除,不建议使用用户安装的驱动程序。
  • 自动安装 – 在 XenApp 或 XenDesktop 会话中连接打印机时,会检查操作系统中是否已安装所需的打印驱动程序。如果尚未安装打印驱动程序,则会自动安装本机打印驱动程序(如果存在)。如果用户在多个端点与位置之间漫游,这可能会在会话之间造成不一致,因为用户每次连接时可能会访问不同的托管资源。出现这种类型的情况时,打印问题故障排除和维护打印驱动程序可能会变得非常困难,因为每个托管资源都可能安装了不同的打印驱动程序集。为确保一致性并简化支持和故障排除,不建议使用自动安装的驱动程序。
  • 通用打印驱动程序 – Citrix 通用打印机驱动程序 (UPD) 是独立于设备的打印驱动程序,旨在用于大多数打印机。Citrix 通用打印机驱动程序 (UPD) 通过减少主映像上所需的驱动程序数量来简化管理过程。对于自动创建的打印机,驱动程序记录应用程序的输出,并且不做任何修改地发送到端点设备。端点使用特定于设备的本地驱动程序完成将作业打印到打印机的过程。UPD 可以与 Citrix 通用打印服务器 (UPServer) 结合使用,以将此功能扩展到网络打印机。

决策:打印机路由

打印作业可以沿不同的路径进行路由:通过客户端设备或通过打印服务器。

  • 客户端设备路由 – 具有本地连接的打印机(通过 USB、LPT、COM、TCP 等连接的打印机)的客户端设备将打印作业直接从客户端设备路由到打印机。
  • Windows 打印服务器路由 – 默认情况下,发送到自动创建的基于网络的打印机的打印作业将从用户的会话路由到打印服务器。但是,当满足以下任意条件时,打印作业将采用回退路由的方式:
    • 会话无法与打印服务器联系
    • 打印服务器位于其他域中,没有建立信任。
    • 本机打印驱动程序在用户的会话中不可用
  • Citrix 通用打印服务器路由 – 打印作业路由遵循与 Windows 打印服务器路由相同的过程,但在用户会话与 Citrix 通用打印服务器之间使用通用打印驱动程序。

打印作业路由的细节取决于打印机预配方法。自动创建的和用户添加的打印机可以根据下图路由打印作业:

打印作业路由示意图

但是,如果将打印机预配为会话打印机,则打印作业路由选项会略有变化。作业无法再通过用户的端点设备进行路由。

会话打印机示意图

推荐的选项基于端点设备、用户会话和打印服务器的网络位置。

  • 客户端设备路由
    • 用于本地连接的打印机实现。
    • 如果 Windows 端点设备和打印机与 Windows 打印服务器位于相同的高速、低延迟网络中,则使用此选项。
  • Windows 打印服务器路由
    • 如果打印机与 Windows 打印服务器和用户会话位于相同的高速、低延迟网络中,则使用此选项。
  • Windows 打印服务器路由(通过通用打印服务器)
    • 如果非 Windows 端点设备和打印机与 Windows 打印服务器位于相同的高速、低延迟网络中,则使用此选项。

决策:打印服务器冗余

使用 Microsoft 打印服务器或 Citrix 通用打印服务器管理的基于网络的打印机应配置冗余,以消除单故障点。Citrix 通用打印服务器冗余应在 Citrix 策略中定义。

来自现场的经验

一家打印媒体公司利用公司总部的瘦客户端和基于 Windows 的工作站。整个大楼都设置了基于网络的打印机(每层楼一台)。Windows 打印服务器驻留在数据中心并管理网络打印机。XenDesktop 和 XenApp 服务器也驻留在数据中心中。

区域办事处拥有许多带有网络上连接的打印机的 Windows、Linux 和 Mac 端点。远程分支机构有几个带有本地连接的打印机的 Windows 工作站。

应用三种不同的打印策略:

  • 总部 - Citrix 通用打印服务器用于在 XenApp 和 XenDesktop 会话中进行打印。基于 Windows 的工作站上不需要本机打印驱动程序。会话打印机策略是按楼层配置的,该策略将每个楼层的打印机连接为默认打印机。根据瘦客户端的子网对策略进行筛选,以便进行邻近打印。执行服务质量 (QoS) 策略。端口 TCP 1494 和 TCP 2598 上的入站和出站网络流量优先于所有其他网络流量。这将防止 HDX 用户会话受到大型打印作业的影响。
  • 区域办事处 - 在区域办事处内部部署通用打印服务器。打印作业使用通用打印驱动程序,并通过广域网对用户会话进行压缩并传递到通用打印服务器。然后,作业将发送到办公室中网络上连接的打印机。
  • 分支机构 - 由于所有分支用户在基于 Windows 的工作站上工作,因此将使用与 Citrix 通用打印机驱动程序一起自动创建的客户端打印机。由于打印作业是通过 ICA 交付的,因此将压缩打印数据,从而节省带宽。Citrix 通用打印机驱动程序可确保连接到客户端的所有打印机都可以在 XenApp 或 XenDesktop 会话中使用,而不必担心所使用的打印机型号。

应用程序

正确集成应用程序需要了解兼容性,以及用户/业务要求如何影响恰当的交付方法。

决策:兼容性

VDI 通常要求对组织的应用程序交付和管理策略进行重大更改。例如,许多组织将利用诸如应用程序流技术推送和应用程序分层等技术减少安装在基础映像中的应用程序数量,以此升级其桌面操作系统并简化管理过程。这些重大更改需要全面的兼容性测试。可能需要验证的重要兼容性要求包括:

  • 操作系统 – 应用程序必须与首选操作系统兼容。
  • 多用户 – 某些应用程序可能更适合通过托管共享桌面或托管 Windows 应用程序进行交付。在这些情况下,必须根据 Windows Server 2012R2 等服务器操作系统的多用户功能验证应用程序的兼容性。
  • 应用程序体系结构 – 了解应用程序包含 16 位、32 位还是 64 位代码非常重要,以便选择合适的操作系统。16 位代码无法在 64 位操作系统中执行。但是,16 位应用程序可以从基于 32 位桌面的操作系统(例如 Windows 7、8 或 10 的 x86 版本)作为托管 Windows 应用程序交付给用户。
  • 互操作性 – 如果某些应用程序在同一操作系统中共存,则可能会遇到复杂情况。可能的原因包括共享注册表配置单元、dll 文件或 INI 文件以及不兼容的依赖关系。应查明应用程序互操作性问题,以便执行适当的补救步骤或选择替代交付模式。
  • 依赖关系 – 应用程序可能需要相互交互,以便为用户提供无缝体验。例如,以 PDF 格式显示信息的应用程序需要使用合适的 PDF 查看器。很多时候,依赖(子)应用程序是特定于父应用程序的版本。
  • 应用程序虚拟化 – 使用应用程序虚拟化技术(例如流技术推送和分层)有助于通过减少安装在基础映像中的应用程序数量来简化映像管理。但是,并非所有应用程序都适用于流技术推送和分层,因为它们可能会安装设备驱动程序、使用 COM+ 或构成操作系统的一部分。

应用程序兼容性可以通过手动和用户测试、利用软件供应商维护的预先验证列表或通过自动化应用程序兼容性解决方案(例如 Citrix AppDNA)来实现,该解决方案通过数千次测试来验证兼容性。

决策:应用程序交付方法

一种交付方法可能无法满足您的所有要求。根据应用程序分类评估过程和整体映像管理策略(已安装的映像、脚本映像和分层映像),可以考虑多种应用程序交付方法。

选择其中一种恰当的应用程序交付方法有助于提高可扩展性、改进管理和用户体验。

  • 已安装的应用程序 – 该应用程序属于基础桌面映像的一部分。安装过程涉及复制到映像驱动器的 dll、exe 和其他文件以及注册表修改。
  • 流应用程序 (Microsoft App-V) – 该应用程序跨网络按需配置并交付到桌面。应用程序文件和注册表设置放置在虚拟桌面上的容器中,与基础操作系统隔离并且相互隔离,有助于解决兼容性问题。
  • 分层应用程序 (Citrix App Layering) – 每个层都包含一个应用程序、代理或操作系统。分层简化了现行的维护过程,因为操作系统、代理和应用程序存在于单个层中;更新层后,包含该层的所有已部署的映像将随之更新。App Layering 有两个不同的交付选项:
    • 分层映像 – 通过集成一个操作系统层、一个平台层(XenApp 和 XenDesktop VDA、Provisioning Services 代理)以及多个应用程序层,管理员可以轻松创建新的可部署映像。
    • 弹性层 – XenApp 和 XenDesktop 用户可以在登录时动态接收新的应用程序层。在 XenApp 主机上,弹性层具有会话感知功能,其中附加层仅可用于授予该层访问权限的用户会话。
  • 托管 Windows 应用程序 – 安装在多用户 XenApp 主机上并且部署为应用程序而非桌面的应用程序。用户从 VDI 桌面或端点设备无缝访问托管 Windows 应用程序,隐藏了应用程序远程运行的事实。
  • 本地应用程序 – 部署在端点设备上的应用程序。应用程序界面在用户托管的 VDI 会话中显示,即使在端点上运行亦如此。

下表提供了关于将应用程序集成到整体解决方案的首选方法的建议。

在此表中:

  • Y 表示推荐。
  • N 表示不推荐。
  • o 表示可行。
应用程序类别 已安装应用程序 流应用程序 分层应用程序 托管 Windows 应用程序 本地应用程序
通用 Y o Y o N
部门 o Y Y Y N
用户 N o Y o Y
管理 Y N Y o N

来自现场的经验

  • 能源 – 一家能源公司为大多数用户在基础映像中安装应用程序,并根据需要通过流技术传输部门应用程序。
  • 财务 – 一家银行客户根据不同部门的要求维护和部署多个桌面映像,其中包含以用户组为重点的应用程序。

虚拟机

虚拟资源需要适当分配处理器、内存和磁盘。这些决策直接影响所需的硬件数量以及用户体验。

成功分配资源的关键是确保虚拟桌面和应用程序提供与物理桌面相似的性能级别。否则,生产率和用户整体满意度将受到影响。但是,将资源分配到超出其要求的虚拟机对业务来说效率低下且成本高昂。

分配的资源应基于评估阶段确定的每个用户组的工作负载特性。

决策:虚拟处理器 (vCPU)

对于基于托管桌面的 VDI 模型(托管池桌面和托管个人桌面),一般建议为每个虚拟机配备两个或多个 vCPU,以便同时执行多个线程。尽管可以为极轻的工作负载分配单个 vCPU,但用户更有可能遇到会话挂起的情况。

对于基于托管服务器的 VDI 模型(托管 Windows 应用程序、托管浏览器应用程序、托管共享桌面),正确的 vCPU 分配基于处理器的非统一内存访问 (NUMA) 体系结构。

NUMA 体系结构示意图

每个插槽被划分为一个或多个 NUMA 节点。托管的基于服务器的 VDI 模型通常会使用 4 个或更多处理器。分配比 NUMA 节点更多的 vCPU 会导致性能下降。如果分配的部分不容易被 NUMA 节点的大小整除,则将 NUMA 节点的一部分分配给虚拟机会导致性能下降。通常情况下,将 NUMA 节点内的内核数量分配给虚拟机或将 ½ 内核分配给虚拟机,同时将虚拟机数量增加一倍。

用户工作负载

操作系统 为扩展配置的 vCPU 为体验配置的 vCPU
Windows 7 2 vCPU 2 vCPU
Windows 10 2 vCPU 2 vCPU
Windows 2012R2 NUMA 或 ½ 的 NUMA NUMA 或 ½ 的 NUMA
Windows 2016 NUMA 或 ½ 的 NUMA NUMA 或 ½ 的 NUMA
操作系统 为扩展配置的 vCPU 为体验配置的 vCPU
Windows 7 2 vCPU 3 vCPU
Windows 10 2 vCPU 3 vCPU
Windows 2012R2 NUMA 或 ½ 的 NUMA NUMA 或 ½ 的 NUMA
Windows 2016 NUMA 或 ½ 的 NUMA NUMA 或 ½ 的 NUMA
操作系统 为扩展配置的 vCPU 为体验配置的 vCPU
Windows 7 3 vCPU 4 vCPU
Windows 10 3 vCPU 4 vCPU
Windows 2012R2 NUMA 或 ½ 的 NUMA NUMA 或 ½ 的 NUMA
Windows 2016 NUMA 或 ½ 的 NUMA NUMA 或 ½ 的 NUMA

注意

Windows 2012 R2 建议基于托管的 Windows 应用程序、托管的浏览器应用程序和托管的共享桌面 VDI 模型。

决策:CPU 优化

在共享和虚拟化环境中,单个用户可以垄断 CPU 资源,因为进程失控或 Excel 中的密集数据处理操作。如果处理器超额订阅,它将无法满足其他用户的请求,导致会话挂起。

Citrix Workspace Environment Management(XenApp 和 XenDesktop 的一个组件)集成了 CPU 优化。当进程在定义的时间范围内消耗一定百分比的 CPU 时,进程优先级从正常到低或非常低,使所有剩余进程具有更高的优先级,并克服失控进程风险。CPU 优化还将记住触发 CPU 保护的进程,并在未来启动时以较低优先级自动启动进程。

大多数环境应启用 CPU 优化作为默认配置。

决策:虚拟内存 (vRAM)

分配给每个资源的内存量取决于用户的预期工作负载和应用程序占用的空间。为虚拟机分配内存不足会导致磁盘分页过多,从而导致用户体验较差;分配过多的 RAM 会增加解决方案的总体成本。

下表提供了有关应根据工作负载分配的虚拟 RAM 的指导。

用户工作负载

操作系统 为扩展配置的 vRAM 为体验配置的 vRAM
Windows 7 2 GB 3 GB
Windows 10 2 GB 3 GB
Windows 2012R2 每个用户 256 MB 每个用户 256 MB
Windows 2016 每名用户 320 MB 每名用户 320 MB
操作系统 为扩展配置的 vRAM 为体验配置的 vRAM
Windows 7 3 GB 4 GB
Windows 10 3 GB 4 GB
Windows 2012R2 每个用户 512 MB 每个用户 512 MB
Windows 2016 每个用户 640 MB 每个用户 640 MB
操作系统 为扩展配置的 vRAM 为体验配置的 vRAM
Windows 7 6 GB 8 GB
Windows 10 6 GB 8 GB
Windows 2012R2 每个用户 1024 MB 每个用户 1024 MB
Windows 2016 每个用户 1280 MB 每个用户 1280 MB

注意

  • Windows 2012R2 建议基于托管的 Windows 应用程序、托管的浏览器应用程序和托管的共享桌面 VDI 模型。
  • 内存分配高于 4 GB 时要求使用 64 位操作系统。
  • 如果使用,则应将 RAM 量的 Machine Creation Services 和 Provisioning Services 缓存添加到虚拟机 RAM 规范中。

决策:RAM 优化

即使用户一次只能在单个应用程序中工作,但大多数用户将运行五个或更多空闲的应用程序。当进程从活动状态移至空闲时,应用程序和操作系统会释放进程的活动内存工作集的一部分以释放系统资源。但是,这只是应用程序工作集的一小部分。其余的应用程序仍然锁定,严重限制了可用的系统资源。

在 Citrix Workspace Environment Management 中使用 RAM 优化时,在一段时间内处于空闲状态(未与用户交互)的应用程序将被强制释放多余的内存,直到其不再处于空闲状态。当应用程序返回到活动状态时,释放的内存将加载回活动工作集中。

大多数环境应启用 RAM 优化作为默认配置。如果某些进程遇到优化问题,RAM 优化排除列表可用。

决策:磁盘缓存

每个 VM 所需的存储量将因工作负载和映像类型而异。如果在不利用映像管理解决方案的情况下创建托管个人桌面,每个 VM 都需要足够的存储空间,用于整个操作系统和本地安装的应用程序。

通过 Machine Creation Services 或 Provisioning Services 部署计算机可以大幅降低每个虚拟机的存储要求。写入缓存和差异磁盘的磁盘空间要求将取决于应用程序的使用情况和用户行为。但是,下表提供了一个起点,用于按照以下准则根据具有 vCPU 和 vRAM 的计算机大小估计磁盘空间需求:

用户工作负载

操作系统 存储空间(差异磁盘/写入缓存磁盘)
Windows 7 10 GB
Windows 10 10 GB
Windows 2012R2 40 GB
Windows 2016 60 GB
操作系统 存储空间(差异磁盘/写入缓存磁盘)
Windows 7 15 GB
Windows 10 15 GB
Windows 2012R2 40 GB
Windows 2016 60 GB
操作系统 存储空间(差异磁盘/写入缓存磁盘)
Windows 7 20 GB
Windows 10 20 GB
Windows 2012R2 40 GB
Windows 2016 60 GB

决策:RAM 缓存

Provisioning Services 和 Machine Creation Services 能够将虚拟机的一部分 RAM 用作存储缓存的缓冲区。RAM 缓存用于通过共享虚拟机的非页面缓冲池内存来提高传统存储的性能。

用户工作负载

操作系统 为扩展配置的 RAM 缓存 为体验配置的 RAM 缓存
Windows 7 128 MB 256 MB
Windows 10 128 MB 256 MB
Windows 2012R2 2 GB 2 GB
Windows 2016 4 GB 4 GB
操作系统 为扩展配置的 RAM 缓存 为体验配置的 RAM 缓存
Windows 7 256 MB 512 MB
Windows 10 256 MB 512 MB
Windows 2012R2 4 GB 4 GB
Windows 2016 8 GB 8 GB
操作系统 为扩展配置的 RAM 缓存 为体验配置的 RAM 缓存
Windows 7 512 MB 1024 MB
Windows 10 512 MB 1024 MB
Windows 2012R2 6 GB 6 GB
Windows 2016 10 GB 10 GB

注意

  • 如果使用,则应将 RAM 量的 Machine Creation Services 和 Provisioning Services 缓存添加到虚拟机 RAM 规范中。
  • 如果主机上有额外的 RAM 可用,则可以增加 RAM 缓存量以提供更高水平的性能。

决策:存储 IOPS

存储性能受其每秒可处理的操作数限制,称为 IOPS。分配存储 IOPS 会导致 VDI 桌面中的应用程序、Web 页面和数据加载速度缓慢。

下表提供了基于工作负载和操作系统为每个用户生成的存储 IOPS 数量的指导。在用户登录/注销期间,存储 I/O 活动会更高。

用户工作负载

操作系统 存储 IOPS(不含基于 RAM 的缓存) 存储 IOPS(包括基于 RAM 的缓存)
Windows 7 10 IOPS 1 IOPS
Windows 10 12 IOPS 1 IOPS
Windows 2012R2 3 IOPS 0.5 IOPS
Windows 2016 4 IOPS 1 IOPS
操作系统 存储 IOPS(不含基于 RAM 的缓存) 存储 IOPS(包括基于 RAM 的缓存)
Windows 7 15 IOPS 1 IOPS
Windows 10 20 IOPS 1.5 IOPS
Windows 2012R2 4 IOPS 0.5 IOPS
Windows 2016 6 IOPS 1 IOPS
操作系统 存储 IOPS(不含基于 RAM 的缓存) 存储 IOPS(包括基于 RAM 的缓存)
Windows 7 25 IOPS 2 IOPS
Windows 10 35 IOPS 3 IOPS
Windows 2012R2 5 IOPS 0.5 IOPS
Windows 2016 8 IOPS 1 IOPS

决策:I/O 优先顺序

使用共享环境,每个用户的 I/O 进程将获得相同份额的资源。运行某些 I/O 密集型任务的用户可能会影响任务关键型应用程序。Citrix Workspace Environment Management 允许管理员定义进程的 I/O 优先级。

如果进程需要更多 I/O 资源或进程垄断 I/O 资源,则将通过控制台手动增加或减少进程和进程优先级。此高级配置仅在特殊情况下使用。

决策:图形 (GPU)

如果没有图形处理器 (GPU),则图形处理由 CPU 使用软件呈现。可以利用图形处理器 (GPU) 来改善服务器可扩展性和用户体验,或者支持使用图形密集型应用程序。在桌面设计过程中,决定如何将 GPU(如果使用)映射到虚拟机非常重要。有三种方法可用。

  • 直通 GPU – 每个物理 GPU 都传递给单个虚拟机(托管应用程序或托管桌面)。
  • 硬件虚拟化 GPU – 使用虚拟机管理程序的 vGPU 技术,NVIDIA GRID 或 Intel Iris Pro 虚拟化并在多个计算机之间共享。每个虚拟机都具有 GPU 驱动程序的完整功能,并可直接访问 GPU。
  • 软件虚拟化的 GPU – GPU 由虚拟机管理程序管理,并拦截 VDI 桌面发出的请求。如果主机中未安装 GPU,则使用此过程。

在此表中:

  • Y 表示可用。
  • X 表示不受支持。

Citrix XenServer

  直通 GPU 硬件虚拟化的 GPU (NVIDIA) 硬件虚拟化的 GPU (Intel) 硬件虚拟化的 GPU (AMD) 软件模拟的 GPU
XenDesktop Y Y Y X Y
XenApp Y Y Y X Y

Microsoft Hyper-V

  直通 GPU 硬件虚拟化的 GPU (NVIDIA) 硬件虚拟化的 GPU (Intel) 硬件虚拟化的 GPU (AMD) 软件模拟的 GPU
XenDesktop Y X X X Y
XenApp Y X X X Y

VMware vSphere

  直通 GPU 硬件虚拟化的 GPU (NVIDIA) 硬件虚拟化的 GPU (Intel) 硬件虚拟化的 GPU (AMD) 软件模拟的 GPU
XenDesktop Y Y X Y Y
XenApp Y Y X Y Y

使用大量图形应用程序的用户组通常需要使用 NVIDIA 硬件虚拟化的 GPU。使用 Intel 提供的硬件虚拟化的 GPU,依赖基于 Office 的应用程序的用户组可以明显受益。

设计方法资源层