VMware-View5-磁盘虚拟化解决方案-全-

VMware View5 磁盘虚拟化解决方案（全）

原文：annas-archive.org/md5/df1cf4f029d07c9abb1ff4d8fe4c839d

译者：飞龙

协议：CC BY-NC-SA 4.0

序言

VMware View 5 桌面虚拟化解决方案旨在为架构师、解决方案提供商、顾问、工程师以及任何计划设计和实施基于 VMware View 5 解决方案的人提供指导。它将参考实际场景，因为这些场景可能是最好的教学示例。它将解释成功解决方案所需的设置和配置，以及背后决策的原因。

本书并非旨在替代 VMware 官方发布的管理或安装指南。管理和安装指南在解决方案的安装和实施过程中使用。本书中的材料应在设计阶段使用，即在实施工作开始之前。

VDI 的驱动因素

许多机构和组织正在研究如何以托管服务的形式交付桌面，同时提高端点安全性并降低相关成本。实施 VMware View 解决方案的流行原因包括：

• 安全性： VDI 将敏感数据从终端设备中移除，并提高了管理、保护、修补和审计大量桌面资源的能力。

• Windows 7 迁移： 寻求迁移到 Windows 7 的组织正在考虑使用 VDI 来简化过渡过程。

• 技术/硬件更新： 在硬件更新过程中，替换过时 PC 的繁重任务可能会带来显著的运营成本，并降低生产力。此时是将用户迁移到 VDI 解决方案的一个机会；此外，现有的 PC 可以重新利用为瘦客户端或厚客户端，延长其使用寿命。

• 能源减少： 一些 VDI 解决方案可以通过使用零客户端/瘦客户端和定制的后端硬件显著减少能耗。

• 设备独立性： VDI 可以消除维持严格的“可接受客户端列表”的限制（例如，只允许 Dell Latitude 5400S 和 Mac Books），而允许终端用户群体使用他们偏好的设备，并最终连接回受管控的 VDI。只要设备支持 View 客户端，就可以在组织内使用。这通常被称为自带设备（BYOD）。

• 危机时的远程连接： 无论是 H1N1、喷发的火山、超强暴风雪，还是蝗虫群，VDI 都可以让员工在无法亲自到达工作区域时依然能够工作。

无论驱动原因如何，VDI 是一项在全球多个行业中广泛应用的技术。许多服务器虚拟化架构师也很可能被要求将 VDI 作为其整体虚拟化数据中心解决方案的一部分。

本书涵盖的内容

第一章，VMware View 组件，涵盖了 VDI 的核心概念以及 VMware View 平台的核心概念。本章还介绍了与 VMware View 解决方案相关的 VMware vSphere 组件。

第二章，解决方案方法论，涵盖了一种定义明确的方法论，包括评估、用例定义、建立 VDI 层次结构以建立共同的解决方案设计框架。

第三章，持久性或非持久性虚拟桌面，解释了 VDI 解决方案中最重要的设计点之一——桌面持久性。它还提供了做出决策的指导，并讨论了每种方法的优缺点。

第四章，终端设备，讨论了可以用来连接到 VMware View VDI 的各种终端设备。它还提供了根据环境和组织需求选择适当设备的指导。

第五章，PCoIP 协议，解释了 VMware View 背后的协议——Teradici 的 PCoIP。它还涵盖了性能调优、APEX 卸载卡以及实施 PCoIP 解决方案的最佳实践。

第六章，VDI 规模规划，专注于 VMware View 解决方案的核心组件的规模规划，包括连接服务器和 VMware vCenter 服务器。它还讨论了在设计解决方案时考虑 VMware vSphere 最大限制的因素。

第七章，冗余性，专注于构建强大且具韧性的 VDI 解决方案。它还解释了如何设计和交付完整的冗余性，以及设计考虑和整体环境影响。

第八章，存储规模规划，专注于 VDI 设计中最复杂的组成部分之一——底层存储环境。它还涵盖了从高层到深入的技术考虑因素，以及支持 VDI 的存储系统的设计方面。

第九章，安全性，专注于 VDI 的加固以及强大的身份验证机制。它还讨论了特定环境中的安全考虑因素，例如政府机构。

第十章，从物理桌面迁移到虚拟桌面，讨论了成功将用户从物理桌面迁移到虚拟桌面的技术。它还重点讲解了用户角色管理和抽象。

第十一章，备份 VMware View 基础设施，专注于为 VMware View 环境安排适当的备份计划。

第十二章，VMware View 5.1，讨论了 VMware View 5.1 中的新功能，包括基于内容的读取缓存（CBRC）和额外的产品亮点。

附录，额外工具，提供了额外的工具、在线参考资料以及建议的 Twitter 名人，这些可能在设计 VDI 解决方案时提供帮助。

本书所需内容

本书属于技术类内容，读者需要对以下概念有基本的理解：

• VMware vSphere

  • 虚拟化管理程序基础

  • vMotion

  • 集群功能，如 HA、DRS 和 DPM

• Active Directory（活动目录）

  • 认证类型

  • 使用证书进行加密

  • 组策略对象

  • 文件重定向

  • 漫游配置文件

  • DNS

• 虚拟机基础

  • VMX 和 VMDK 文件

  • 快照

  • VMware 工具

• 网络

  • VLAN（虚拟局域网）

  • DHCP

  • 端口类型

  • 路由

  • LAN 和 WAN 基础知识

本书适合的读者

本书的典型读者应具备扎实的 VMware vSphere 基础知识，并且参与过 VMware 环境的安装或管理工作，时间超过两年。

约定

在本书中，你将看到多种不同的文本样式，以区分不同类型的信息。以下是一些样式示例及其含义的解释。

文本中的代码词汇如下所示：“配置 ODBC 连接并使用<vCenter Server>/SQLEXP_VIM作为连接字符串。将<vCenter Server>替换为你环境中的适当信息。”

新术语和重要词汇用粗体显示。你在屏幕上看到的、在菜单或对话框中出现的词语例如，以这种方式显示在文本中：“可以通过打开设备管理器中的属性标签，并选中相应设备来查找此信息。”

注意

警告或重要提示通常会以这种框框形式呈现。

提示

提示和技巧通常以这种方式呈现。

读者反馈

我们始终欢迎读者的反馈。告诉我们你对本书的看法——你喜欢或不喜欢的地方。读者反馈对我们开发真正能让你受益的书籍至关重要。

要发送一般反馈，请简单地发送电子邮件至<feedback@packtpub.com>，并通过邮件主题注明书籍标题。

如果你在某个话题上有专业知识，并且有兴趣写作或为书籍做贡献，请参见我们作者指南：www.packtpub.com/authors。

客户支持

现在你已经成为一本 Packt 图书的自豪拥有者，我们为你提供了一些帮助你最大化利用购买内容的资源。

勘误

尽管我们已经尽力确保内容的准确性，但错误难免会发生。如果你在我们的书籍中发现错误——无论是文本错误还是代码错误——我们会非常感激你向我们报告。这样，你不仅能帮助其他读者避免困扰，还能帮助我们改进后续版本的书籍。如果你发现任何勘误，请通过访问 www.packtpub.com/support，选择你的书籍，点击 勘误提交表单 链接，并输入错误详情。一旦你的勘误被验证，提交将被接受，勘误将被上传到我们的网站，或添加到该书的勘误列表中。

盗版

网络上侵犯版权的盗版问题在所有媒体中都是一个持续存在的问题。在 Packt，我们非常重视版权和许可的保护。如果你在互联网上发现任何非法复制的我们作品的形式，请立即提供该链接地址或网站名称，以便我们采取措施。

如果你发现任何疑似盗版内容，请通过 <copyright@packtpub.com> 联系我们，并提供相关盗版资料的链接。

我们非常感谢你为保护我们作者的权益所做的帮助，也感谢你支持我们为你提供有价值内容的能力。

问题

如果你在使用本书的过程中遇到任何问题，可以通过 <questions@packtpub.com> 联系我们，我们会尽力解决。

第一章. VMware View 的组成部分

虚拟化，即将操作系统与底层物理服务器组件进行抽象的技术，已经成为数据中心架构的基石。虚拟化使得组织能够在数据中心的单台物理服务器上运行多个操作系统，不仅仅是一个，而是几十个，甚至上百个。虚拟化的好处有很多，包括减少硬件、能源和冷却成本。此外，虚拟化还可以应用新的分布式和弹性技术，如VMware 分布式资源调度器 (DRS)和VMware 高可用性 (HA)。服务器虚拟化，即在服务器硬件上虚拟化服务器操作系统，已经成为一种主流技术，全球各地的组织都在广泛接受、采用和实施。

虚拟桌面基础架构 (VDI)，即在服务器硬件上虚拟化桌面操作系统，是另一个话题。

虚拟桌面推广较慢的原因最初是由于多种因素，包括技术尚不成熟、缺乏对全面解决方案的普遍理解、缺乏经过验证的交付方法以及对虚拟桌面项目成功标准的明确理解。

如今，许多障碍已经被消除。从通信协议到计算密度、平台稳定性以及理想的终端设备，相关的支持技术现已存在。全球一些最大的集成商已经建立了设计方法；然而，虚拟桌面项目仍然面临失败、停滞或受阻的情况。

本书将为架构师、工程师、项目经理、自由顾问或承包商提供一套经过验证的成功蓝图。更重要的是，本书将教授关键的成功标准，帮助读者衡量最重要的设计考虑因素，并如何提高项目成功率并确保顺利通过验收。

在深入讨论这些概念之前，理解虚拟桌面 (vDesktop) 解决方案的组成部分是非常重要的。本书中的技术重点是 VMware View，它是 VDI 领域的市场领导者。虽然本书中的一些概念专门适用于基于 VMware View 的解决方案，但许多话题将帮助任何技术的 VDI 架构师规划并构建成功的解决方案。

VMware View 的核心组件

本书假设读者已经熟悉服务器虚拟化，特别是 VMware vSphere（行业内一些资深人士有时称之为 ESX）。因此，本章将重点讨论：

• VMware vCenter Server

• View 连接服务器的类型

• 代理和客户端软件

vCenter Server

VMware vCenter 是 VMware View 解决方案的必需组件。这是因为 View Connection Server 通过 vCenter Web Service（通常通过 443 端口）与底层的虚拟基础架构（VI）进行交互。vCenter 还负责 VMware vSphere 提供的 VMware View 解决方案的补充组件，包括 VMotion 和 DRS（用于平衡物理主机上的虚拟桌面负载）。当最终客户购买 VMware View 套件时，VMware vCenter 会自动包含在内，无需单独通过库存单位（SKU）购买。在利用 vSphere 进行服务器虚拟化的环境中，vCenter Server 很可能已经存在。为了确保了解 VMware vCenter Server 提供的功能，以下列出了关键术语：

• vMotion： 它是将运行中的虚拟机从一台物理服务器迁移到另一台物理服务器的能力，且没有停机时间。

• DRS： 它是 vCenter Server 的功能，可以在参与同一 vCenter Server 集群的物理服务器之间平衡虚拟机负载。

• 集群： 它是一个物理服务器的集合，这些服务器可以访问相同的网络和共享存储。参与 vCenter 集群的物理服务器将它们的资源（例如 CPU、内存等）逻辑地汇集起来，以供虚拟机使用。

• HA： 它是 vCenter Server 的功能，旨在防止物理服务器故障。HA 会在同一集群中的可用物理服务器上启动驻留在故障物理服务器上的虚拟机。

• 文件夹： 它是虚拟机的逻辑分组，在 vSphere 客户端中显示。

• vSphere 客户端： 它是客户端软件，用于连接到 vCenter Servers（或运行 vSphere 的物理服务器）进行管理、监控、配置及其他相关任务。

• 资源池： 它是资源的逻辑池（例如 CPU、内存等）。位于同一资源池中的虚拟机（或虚拟机组）将共享预定的资源量。

设计 VMware View 解决方案时，通常会涉及到典型的服务器虚拟化设计概念，例如正确的集群设计。由于服务器虚拟化和 VDI 之间设计概念的重叠，许多服务器虚拟化工程师将相同的原则从一个解决方案应用到另一个解决方案中。

VDI 架构师常犯的第一个错误是将 VDI 视为服务器虚拟化并以相同的方式对待它。服务器虚拟化是对服务器操作系统的虚拟化。虽然 VDI 确实使用一些服务器虚拟化技术（例如用于连接基础设施），但有许多新概念对于成功至关重要，需要理解清楚。

VDI 架构师可能犯的第二个错误是未能理解某些 VDI 解决方案的真正规模。对于没有 VDI 环境的普通服务器虚拟化管理员来说，他/她可能只需要管理十几台物理服务器和几百台虚拟机。本书的作者曾参与过涉及数万台 vDesktops 的 VDI 解决方案，远远超出了传统 VMware vSphere 设计的限制。

VDI 通常在不同的规模上进行。架构扩展的概念将在本书后面讨论，但许多扩展概念围绕着 VMware vCenter Server 的限制。需要注意的是，VMware vCenter Server 最初是为了作为企业服务器虚拟化环境的中央管理点而设计的。虽然 VMware 持续改进其扩展能力，但围绕 VMware vCenter Server 进行设计仍然非常重要。

那么，VDI 架构师为什么一开始就需要 VMware vCenter 呢？

VMware vCenter 是 VMware View 解决方案中所有虚拟机任务的网关。包括以下任务：

• 创建虚拟机文件夹以组织 vDesktops

• 创建资源池，将物理资源为不同组的 vDesktops 进行隔离

• vDesktops 的创建

• 快照的创建

VMware vCenter 不用于管理终端设备与 vDesktop 之间的连接。因此，VMware vCenter 的故障不应影响已配置的 vDesktops 的入站连接，因为它只会阻止新的 vDesktops 的创建、刷新或删除。

由于 vCenter Server 在 VDI 解决方案中的重要性，通常会采取额外的步骤来确保其可用性，甚至超出典型服务器虚拟化解决方案中的考虑事项。

本书后面有一个问题，询问是否应该使用现有的 vCenter Server 为组织的 VDI 提供服务，还是应该构建一个新的 vCenter Server 基础设施。

View Connection Server

View Connection Server 是 VMware View 解决方案的核心组件；如果 VMware vCenter Server 是虚拟基础设施和底层物理服务器管理通信的网关，那么 VMware View Connection Server 就是终端用户连接到其 vDesktop 的网关。用传统的 VDI 术语来说，它是 VMware 的代理，连接终端用户与工作空间（无论是物理还是虚拟）。View Connection Server 是 VDI 解决方案的管理中心点，用于管理几乎整个解决方案的基础设施。然而，架构师在设计时有时需要考虑 vCenter 集群配置，如本书后面所讨论的那样。此外，VMware View 管理员有时也需要访问 vCenter Server。

VMware View Connection Servers 的类型

安装 VMware View Connection Server 时有多种选项可供选择。因此，理解不同类型的 View Connection Server 及其在给定 VDI 解决方案中的作用至关重要。

以下是 View Connection Server 可以安装的三种配置：

• 完全安装： 此选项安装所有 View Connection Server 组件，包括一个新的 轻量级目录访问协议（LDAP） 实例。

• 安全性： 此选项仅安装 View Connection 门户所需的组件。View 安全服务器无需属于 Active Directory 域（与 View Connection Server 不同），因为它们不访问任何身份验证组件（例如，Active Directory）。

• 副本： 此选项为现有的 View Connection Server 实例创建副本，用于负载均衡或高可用性目的。认证/LDAP 配置将从现有的 View Connection Server 复制。

  注意

  我们的目标是设计对最终客户高度可用的解决方案。因此，所有设计将利用两个或更多的 View Connection Server（例如，一个完全安装和一个副本）。

在完全安装 View Connection Server 时，将安装以下服务：

• VMware View Connection Server

• VMware View 框架组件

• VMware View 消息总线组件

• VMware View 脚本主机

• VMware View 安全网关组件

• VMware View Web 组件

• VMware VDMDS

VMware VDMDS 提供 LDAP 目录服务。

View Agent

View Agent 是安装在目标桌面上的组件，无论是物理的（很少）还是虚拟的（几乎总是）。View Agent 使 View Connection Server 能够与桌面建立连接。View Agent 还提供以下功能：

• USB 重定向： 它被定义为使一个本地连接的 USB 设备显示为连接到 vDesktop。

• 单点登录（SSO）： 通过智能凭证处理来完成，要求只进行一次安全和成功的身份验证登录请求，而不是多次登录（例如，在连接服务器、vDesktop 等处）。

• 通过 ThinPrint 技术的虚拟打印： 它通过使用 ThinPrint（OEM）来简化打印机驱动程序的管理。

• PCoIP 连接性： 这是由 Teradici 制作并在 VMware View 解决方案中使用的专用 VDI 协议。

• 个人管理： 它是在整个桌面环境中管理用户配置文件的能力；该技术通过 VMware 收购的 恢复时间目标（RTO） 实现。

• View Composer 支持： 它是使用链接克隆和精简配置的功能，能够大幅减少在管理中到大型 VMware View 环境中的操作工作量。

View 客户端

View Client 是安装在终端设备上的组件（例如，用户的笔记本电脑）。View Client 允许设备连接到 View Connection Server，然后将设备引导到可用的桌面资源。以下是两种类型的 View Client：

• View Client

• 带本地模式的 View Client

这些独立版本有各自独特的安装文件（每次只能安装一个）。View Client 提供了在线连接工作的所有功能。如果解决方案中需要使用本地模式，则应安装带有本地模式的 View Client。

VMware View 本地模式是能够将 vDesktop 安全地检查到本地设备中，以便在断开连接的场景下使用（例如，在丛林中）。

安装包的大小差异约为 80 MB（带本地模式的 View Client 较大）。对于大多数场景来说，80 MB 的磁盘空间不会影响解决方案的可行性，因为即使是闪存驱动器也远超过 80 MB 的阈值。

除了提供能够连接到桌面的功能外，View Client 还与 View Agent 通信，以执行以下任务：

• USB 重定向

• 单点登录

可选组件 — VMware View Composer

本章之前介绍的组件属于 VMware View 解决方案中的必需组件。VMware View 解决方案中唯一可选的主要组件是 View Composer。需要注意的是，当一些第三方解决方案（如 Unidesk 或基于存储的克隆）与 VMware View 一起使用时，View Composer 并不被使用。这是因为像 Unidesk 或基于存储的克隆等解决方案有自己的方式来处理 vDesktops 的大规模配置。

View Composer 在当前大多数基于视图的解决方案中都被使用，但也有一些非常有效的场景和解决方案不需要使用 View Composer。由于本书专注于 VMware View 解决方案，而不是 VMware View 与第三方组件的结合，View Composer 将在全书中进行详细讨论。

View Composer 介绍

View Composer 是管理链接克隆部署的组件，稍后将在本章中介绍，旨在通过单一基准快照为桌面虚拟机部署克隆。

注意

View Composer 仅安装在 vCenter 服务器上。

View Composer 还使用一个独立的数据库来存储有关链接克隆桌面的映射、部署等信息。该数据库可以与现有的 vCenter 数据库位于同一数据库服务器上，前提是它是受支持的平台。然而，数据库本身必须是专用于 View Composer 的。这意味着 View Composer 数据库不能使用现有的 vCenter Server 数据库（但可以使用同一服务器上的独立数据库实例）。

此外，必须在 vCenter 服务器上设置一个单独的 开放数据库连接（ODBC） 连接，并提供适当的 View Composer 数据库连接信息。

注意

如果使用 View Composer，则仅支持自动池类型。此外，数据库实例必须是专用于 View Composer 的。

使用 vCenter 的 SQL Express 安装进行 View Composer 配置

小型概念验证（PoC）环境可能希望利用其 VMware vCenter Server 上的现有 SQL Express 安装。只要创建一个单独的数据库，就可以利用相同的 SQL Express 实例。要创建单独的数据库，请执行以下步骤：

1. 下载并安装 SQL Server Management Studio Express。

2. 连接到 SQL Express 的 vCenter Server 实例。

3. 右键点击实例名称，添加一个新数据库（例如，View_Composer）。

4. 配置 ODBC 连接，并使用<vCenter Server>/SQLEXP_VIM作为连接字符串。将<vCenter Server>替换为适合你环境的相关信息。

快照与链接克隆

快照保存了给定虚拟机的某一时刻的状态。超出该时刻快照的变化将写入增量磁盘，而原始虚拟磁盘（.vmdk）则被标记为只读。这样可以保持虚拟机的时刻状态，直到管理员删除快照为止。可以为给定虚拟机拍摄多个快照，这些时刻快照作为 VMware View Composer 链接克隆的基础。

链接克隆

链接克隆是基于虚拟机的特定快照（称为父虚拟机）创建的虚拟机副本。当创建链接克隆池时，VMware View Composer 会创建一个副本。

副本是原始只读基础虚拟机磁盘与特定时刻快照合并后的结果，该快照被选为给定 VMware View 桌面池的部署时刻。副本始终是精简配置的。

一个 View 桌面池一次只能指向一个特定的快照，但可以通过本书后面讨论的技术轻松更改。一个虚拟机可以有多个快照，因此单个虚拟机与多个快照可以作为环境中所有 View 桌面池的基础。这允许每个池基于自己的（或相同的）时刻快照。这是可能的，因为使用链接克隆技术的 View 桌面池并不直接使用基础虚拟机快照，而是使用副本（基础虚拟机+快照）。

虽然链接克隆是基于原始父虚拟机创建的，但每个链接克隆仍然具有唯一的媒体访问控制（MAC）地址和虚拟机通用唯一标识符（UUID）。

上图展示了一个包含三个快照（Snap1、Snap2 和 Snap3）的父虚拟机。每个快照表示虚拟机的不同时间点。例如，Snap1 快照可能安装了 Office 2007，Snap2 快照可能安装了 Office 2010，Snap3 快照可能安装了 Office 2010 和 Visio 2010。在这个例子中，Snap2 快照被选中用于虚拟桌面部署。一旦选择了该快照并启用了桌面池的配置，就会创建一个副本。这个副本不会复制其他 Snap1 或 Snap3 快照的状态。

使用副本可以保持原始父虚拟桌面的快照状态，从而允许父虚拟桌面在不影响使用副本的虚拟桌面状态的情况下进行开机、打补丁或修改。原因是副本是父虚拟桌面快照的副本，而不是实际的父虚拟桌面本身。

模板

模板是通过将虚拟机标记为只读并将其转换为模板而创建的虚拟机。模板只是一个虚拟机，它的 .vmx 配置文件被转换为 .vmxt 配置文件。虚拟机是只读虚拟机，之后用于克隆目的。从虚拟机模板创建的虚拟机是原始模板的直接副本。然而，可以使用自定义规范来更改新创建的虚拟机的某些方面（例如，SID、主机名、IP 地址等）。自定义规范是通过在连接到 vCenter Server 的 vSphere 客户端中使用自定义规范向导创建的。

完全配置与链接克隆的区别

VMware View 可以同时使用完全克隆和链接克隆。完全克隆是现有虚拟机模板的 1:1 独立副本。这与从 VMware vCenter 中部署虚拟机模板的过程相同。选择一个模板作为虚拟桌面的基础，并（可能）选择自定义规范。

使用完全配置（例如，虚拟机模板）部署的虚拟桌面在构建完成后不再需要访问原始模板。

链接克隆使用一个主虚拟机，然后为每个额外的虚拟机创建一个增量磁盘。额外的虚拟机在需要访问其基础镜像时（例如，访问核心 Windows 操作系统组件）会指向主虚拟机，但对于该特定虚拟机或用户的任何独特数据（例如，...\Documents and Settings\）则使用其增量磁盘。使用 View Composer 技术构建的桌面将对副本虚拟机具有只读访问权限，并对其增量磁盘具有读写权限。

注意

完全克隆是基于虚拟机模板创建的，而链接克隆是基于虚拟机快照创建的。

磁盘类型

有三种类型的磁盘——操作系统磁盘、用户数据磁盘和临时数据磁盘。

操作系统磁盘

操作系统磁盘存储系统数据（例如 Windows 7），并为功能齐全的桌面提供基础。

次要操作系统磁盘

次要操作系统磁盘存储必须在某些 View Composer 活动（如刷新或重新组合）期间保留的操作系统数据。每个虚拟桌面都将有一个次要操作系统磁盘。这些磁盘通常为 10 MB 大小，且不可配置。

次要操作系统磁盘只能存储在与操作系统磁盘相同的数据存储中。

用户数据磁盘

持久用户数据磁盘是 VMware View 虚拟桌面的一个可选组件。用户数据磁盘用于存储用户配置文件信息。通过将这些信息存储在持久磁盘上，View Composer 的操作（如刷新和重新组合）将不会影响用户配置文件数据。另一种方式是将这些信息存储在操作系统磁盘内，这将导致在刷新或重新组合任务期间丢失用户配置文件数据。

用户数据磁盘的大小是可配置的。此外，持久用户数据磁盘可以存储在与操作系统磁盘相同的数据存储中，或存储在单独的数据存储中。

临时数据磁盘

非持久临时数据磁盘是 VMware View 虚拟桌面的一个可选组件，也称为一次性磁盘。临时数据磁盘用于存储操作系统交换文件以及在用户会话期间创建的临时数据。通过将这些信息存储在非持久磁盘上，每当虚拟桌面关闭时，VMware View 将删除存储在磁盘上的所有数据。这有助于减少虚拟桌面的增长（以 MB 为单位），因为一次性用户交互会被丢弃，并且不会成为每个用户标准操作系统磁盘的一部分。

临时数据磁盘的大小是可配置的。临时数据磁盘只能存储在与操作系统磁盘相同的数据存储中。

多种磁盘类型和重定向选项

以下是可用的磁盘类型和重定向选项列表：

• 操作系统磁盘

  • 链接克隆 (1)

  • 完全克隆 (2)

• 用户数据

  • 操作系统磁盘 (3)

  • 持久磁盘 (4)

• 临时数据

  • 操作系统磁盘 (5)

  • 非持久磁盘 (6)

下图说明了前述的磁盘类型及其重定向：

在前面的图示中，未显示次要操作系统磁盘，因为它不是 VMware View 中的可配置选项。

精简配置与厚配置

当使用精简配置创建虚拟磁盘时，磁盘只占用磁盘上实际的数据大小。例如，一个大小为 20 GB 但仅包含 8 GB 数据的虚拟磁盘（.vmdk）将只占用数据存储中的 8 GB。如果有两个虚拟桌面，每个桌面都有一个 20 GB 的虚拟磁盘，但每个磁盘只有 8 GB 的数据，这样它们将一起占用数据存储中的 16 GB。

当使用精简配置的虚拟机需要将新数据写入虚拟磁盘（从而增加虚拟磁盘的大小）时，它会在数据存储的块大小所定义的块中进行操作。数据存储的块大小是在格式化为虚拟机文件系统（VMFS）格式之前定义的。在 VMware vSphere 5 中，新的（与从 vSphere 升级的不同）数据存储使用统一的 1 MB 块大小。

例如，如果虚拟机位于一个 500 GB 的 VMFS-3 数据存储上，并且该数据存储是使用 2 MB 的块大小进行格式化的，那么一个 10 MB 的新写入操作将需要写入 5 个块（10 MB 文件/2 MB 块大小），这导致整体存储空间的使用效率较低。

注意

精简配置使得可以超额分配可用存储，并且如果没有适当的监控和管理，可能会引入严重问题。

当使用厚配置（默认）创建虚拟磁盘时，磁盘占据其在磁盘上分配的整个大小。例如，一个大小为 20 GB 的虚拟磁盘，尽管只有 8 GB 的数据，但会在数据存储上占用 20 GB。如果有两个虚拟桌面，每个虚拟桌面都有一个 20 GB 的虚拟磁盘，但每个磁盘只有 8 GB 的数据，它们将占用数据存储上的 40 GB。

View Composer 使用链接克隆技术。使用该技术的虚拟桌面包含一个指向原始金色快照副本的指针。需要澄清的是，该指针指向的不是原始（父）虚拟桌面本身，而是从某个特定时间点开始的父虚拟桌面的精确副本（副本）。View Composer 使用此技术，以便每个虚拟桌面不需要自己的完整虚拟磁盘。指针仅对副本进行只读访问，并将所有更改写入一个辅助磁盘，称为增量磁盘。

增量磁盘可以看作是变更记录。与修改金色快照不同，所有对原始磁盘的更改（增量）都会记录在金色快照之外，存储到增量磁盘中。这使得原始金色快照保持完好无损，同时仍然允许可用的操作系统接受用户和其他应用程序所做的更改。

链接克隆的重置、刷新、重组和再平衡操作

使用链接克隆时，可以对克隆本身执行几个操作。这些操作如下：

重置

重置操作相当于按下虚拟机的重置按钮。这是一个非优雅的虚拟机重启，相当于拔掉桌面电源线然后重新插入。

刷新

刷新操作是将增量磁盘重置回其原始状态的操作。随着用户不断将更改写入其增量磁盘，操作系统增量磁盘可能会膨胀。刷新操作会导致操作系统增量磁盘中的数据丢失。

注意

刷新选项仅在使用持久化和自动化链接克隆桌面池时可用。在此操作期间，如果数据（例如用户数据）未重定向到其他位置（例如非持久磁盘），可能会丢失。

重新合成

重新合成操作是用于更改桌面池所使用的快照和/或父虚拟机的操作：

在前面的图像中，1 号是原始映射到基础快照，2 号表示在重新合成操作期间可用的选项。

管理员可以在以下场景中使用重新合成操作：

• 要更改链接克隆池以使用原始父虚拟机（例如 ParentVM_1）的不同快照（例如 Snapshot_B），而不是当前使用的快照

• 要更改链接克隆池以使用不同父虚拟机（例如 ParentVM_2）的快照（例如 Snapshot_A），而不是当前正在使用的父虚拟机

  注释

  重新合成选项仅在使用持久化和自动化链接克隆桌面池时可用。

重新平衡

Rebalance 动作是一种将桌面均匀分配到桌面池中所有可用数据存储的操作。桌面必须处于就绪、错误或自定义状态（且没有待处理任务或取消）才能进行重新平衡。

Rebalance 操作还会自动执行桌面的刷新操作，这将把操作系统磁盘重置为其原始状态。

在进行重新平衡操作时，管理员可以设置是否在用户注销桌面后重新平衡桌面，或者强制所有活跃用户注销。

Rebalance 操作也是将链接克隆移至新数据存储的唯一支持方式。

可选组件 — VMware View 传输服务器

VMware View 传输服务器是自版本 4.5 以来 VMware View 中的新组件。传输服务器的主要作用是将桌面虚拟机从数据中心传输到最终本地设备，以便在离线场景中使用。在最终设备上本地运行虚拟桌面被称为 VMware View 中的本地模式。

传输服务器还管理虚拟桌面的存储库，这些虚拟桌面将在本地模式下使用，并提供本地镜像与数据中心中桌面镜像之间的同步功能。

注释

传输服务器不能与其他任何 VMware View 组件一起安装。

传输服务器的存储库可以存在于以下位置：

• 本地驱动器上的本地目录

• 通过 通用命名约定 (UNC) 的共享访问

确保传输服务器的存储库没有用完空间非常重要。作为参考，平均签出的 Windows XP 镜像将占用大约 3 GB 的存储空间。

此外，传输服务器必须使用以下组件：

• 静态 IP 地址

• LSI 并行 SCSI 控制器

签出

检查虚拟桌面可能是 VMware 传输服务器执行的最密集的操作。签出操作涉及将整个发布的虚拟桌面镜像从 View 传输服务器下载到本地客户端，并在本地模式下运行；本地镜像以加密格式存储，并与镜像关联一个生命周期。签出操作还会在虚拟桌面上设置一个锁，确保禁止未来任何来自虚拟基础设施内连接的桌面请求：

由于使用了网络带宽（复制大量数据），签出过程应在最终设备与 VDI 位于同一局域网时进行。通过 3G 热点执行签出过程可能需要几个小时，甚至整整一天，具体取决于 vDesktop 基础设施的大小。

检查中

检查虚拟桌面时，涉及将增量数据和配置上传到 VMware View vDesktop，通过 View 传输服务器传输。这些数据存储在操作系统磁盘和用户数据磁盘（如果存在）上。未更改的基础镜像不会被上传。虚拟桌面上的锁定在虚拟基础设施内被释放，未来对该桌面的任何入站连接都将指向数据中心内运行的虚拟机（而不是再次重定向到本地模式）。

复制

复制是将本地虚拟桌面与其数据中心对等体同步的过程。复制仅传输增量数据（由用户生成的更改）。复制由复制策略管理，该策略配置如频率和用户推迟等设置：

如果本地模式虚拟桌面中的更改用户数据被视为有价值的数据，则需要在 View 管理控制台中定义复制策略。否则，如果没有强制复制，最终设备出现故障时，宝贵的数据可能会丢失。

VDI 的一个主要优势是将数据保存在数据中心的概念。本地模式有几个使用场景（本书后续会讨论），但它将数据带回边缘，即使是加密的。本地模式应仅在特定的使用场景下使用，不能将其视为典型的 VMware View 解决方案。

回滚

回滚是一种移除已签出的本地桌面访问权限的方法（另一种方法是移除所有权）。如果视图中的策略设置允许，最终用户也可以执行回滚操作：

回滚执行以下操作：

• 如果用户当前登录的是已签出的本地桌面，则该会话将被终止，且用户不能再次登录本地桌面。必须执行新的签出任务来恢复本地模式功能。

• 如果用户没有登录到已签出的本地桌面，所有后续的登录请求将被发送到数据中心运行的实例。必须执行一个新的签出任务才能恢复本地模式功能。

总结

本章提供了对 VMware View VDI 解决方案组件的一个坚实的介绍，包括 VMware vSphere 的基本知识。如果没有理解 VMware View 架构的基本概念以及底层 VMware vSphere 架构的基础，构建一个合适的 VMware View 解决方案将会非常困难。如需进一步阅读关于 VMware View 或 VMware vSphere 的内容，请参考 VMware 的管理、评估和安装指南，选择你需要的产品套件。

下一章将讲解如何收集组织的输入，以确保 VMware View 设计满足成功的要求。收集需求是许多 VDI 架构师跳过或匆忙完成的阶段，导致最终产品不尽如人意。一旦 VDI 架构师与一个组织进行了多次发现性接洽，他很可能只会问一些常见的陷阱问题（例如，“你们会使用双向音频吗？”），但在达到这种舒适度之前，建议进行全面的发现工作。

本书后续章节将使用第二章收集的输入，解决方案方法论，来为一个组织制定出有效的设计。

第二章：解决方案方法论

本章将重点介绍设计成功的 VMware View 环境所需的解决方案方法，包括收集输入、分析这些输入以及生成 VMware View 设计或项目输出。

虚拟桌面基础架构（VDI） 实施可能有多种项目驱动因素，包括降低成本、提高安全性或终端设备灵活性。在参与 VDI 项目时，定义项目成功标准非常重要。例如，如果一个组织希望减少流动医师的登录时间，那么将简化的登录过程（例如，单点登录）纳入整体解决方案中非常重要。

注释

一个没有解决组织关键标准的强大 VDI 解决方案，可能仍然会被评为中等成功，而不是被视为对最终用户工作环境的显著改善。

此外，对于为多个组织设计 VMware View 解决方案的解决方案提供商和架构师来说，采取科学和有组织的方法来设计 View 解决方案非常重要。并行设计不同组织的解决方案可能会非常混乱。通过对每个项目采取相同的方法，VDI 架构师可以减少错误，更重要的是，简化生产设计所需的工作量。

设计 VMware View 解决方案的关键阶段是：

• 评估

• 用例定义

• 设计

• 验证

• 交接/管理

正如在第一章 VMware View 组件中所述，本书侧重于基于 VMware View 5 设计解决方案。在完整的解决方案中，将有一个实施阶段，该阶段将跟随验证阶段。这些阶段将包括子主题，如定义项目时间表、关键里程碑、交接和操作准备等内容，这些内容也会被纳入其中。然而，这些主题超出了本书的范围。

本书是为架构师提供的指南，旨在设计最有可能成功的解决方案。

评估

VMware View 解决方案可能会替代现有的物理桌面，并需要迁移阶段，或者它可能是一个全新的解决方案，面向组织。无论哪种情况，都需要进行适当的评估，以了解如何确定硬件需求、存储需求以及可能需要的额外解决方案（例如，配置文件管理解决方案）。

评估用于收集必要的信息，以便正确设计解决方案。评估是收集技术信息和组织信息的过程。通常，评估有三个组成部分：

• 问卷

• 度量收集

• 讨论

问卷

问卷，无论是手动填写还是电子填写，都是开始收集必要数据以制定稳固 VMware View 设计的宝贵工具。问卷也是帮助组织感受到参与设计的有效工具，这有助于提高成功的机会。

积极参与 VDI 设计的组织会更加关注其成功。而那些仅被交付了 VDI 解决方案但未参与其中的组织，很可能会怀疑解决方案的效果。

本书作者制作的 VDI Fox™工具提供了一个可通过 iPhone 或 iPad 使用的问卷，适用于现场实时填写。问卷也可以在下一节中找到，可以打印出来现场填写，或者使用 VDI Fox 工具进行填写。有关 VDI Fox 应用程序的更多信息，请访问www.redfoxllc.com/。

VMware View 5 桌面虚拟化解决方案的评估工作表

以下表格显示了 VMware View 5 桌面虚拟化解决方案的评估工作表：

问题	值	描述
桌面池输入
---	---	---
此解决方案将支持多少个自助服务终端（在此表格之后进行说明）？		它提供了将被配置为自助服务终端的 vDesktops 总数，并可能包含自动登录功能。
环境中最多支持多少个 vDesktop 用户？		它提供了一个持久性 vDesktop 解决方案的 vDesktops 总数。
在任何给定时间内，最多会有多少并发用户连接？		它提供了一个非持久性 vDesktop 解决方案的 vDesktops 总数。
VDI 所需的桌面操作系统是什么？		它确定了 vDesktops 所需的内存和 vCPU 的基线。
现有桌面映像的总大小是多少？		它决定了需要多少磁盘空间。
你希望多久刷新一次 vDesktops？		它决定桌面池设置（立即刷新、n分钟后刷新、在n百分比磁盘膨胀时刷新等）。
需要维护多少个时间点快照以保持基础映像？		它决定了需要多少磁盘空间。
完全高可用解决方案？		它决定是否将使用冗余的 View 连接服务器、vCenter 服务器等。
是否支持远程工作人员？		它决定是否需要 View 安全服务器。
用户是否会根据连接位置进行分类？		它决定是否需要 View 连接服务器标签。
外部用户是否应该连接到与内部用户不同的 VDI？		它决定是否应使用 View 连接服务器标签。
是否会使用智能卡、CAC 卡、接近徽章等进行身份验证？		它决定了 View 客户端、View 代理和所需证书的设置。
您是否遵守 FIPS 140-2 合规要求？		它决定了 View 环境的高级设置。
您是否使用双因素 RSA 身份验证？		它用于配置高级身份验证选项。
您的远程用户主要处于连接状态吗？		它决定了解决方案是否需要 VMware View 本地模式。
是否允许使用 USB 驱动器？		它决定了高级 View 配置设置。
环境中是否有轮班工作者？		它决定了桌面池设置。
员工的平均工作日时长是多少？		它决定了桌面池设置。
存储输入
桌面镜像中可用空间是多少？		它决定了镜像的瘦化大小（总空间 - 空闲空间 = 瘦化大小）。
目前环境中有多少台桌面基础镜像？		它作为桌面池数量的输入，帮助解决方案配置。
环境输入
当前桌面是如何打补丁的？		它决定了 vDesktops 的打补丁方案。
您现有的服务器基础设施是什么？		它用于了解技术环境。
您现有的存储基础设施是什么？		它用于了解技术环境。
您的交换基础设施是什么？		它用于了解技术环境。
哪个团队管理您的虚拟服务器环境？		它用于了解政治环境。
哪个团队管理您的物理桌面环境？		它用于了解政治环境。
您预计谁将负责管理您的 VDI？		它用于了解政治环境。
实施后，谁将负责管理该解决方案？		它用于了解需要进行的操作准备水平。
当前的 Microsoft 桌面许可协议是什么？		它决定了是否有必要的 Microsoft 许可。
当前物理桌面的资产追踪方案是什么？		它决定了现有的技术环境。
是否会为该解决方案购买新的终端设备？		它决定了是否可以使用新设备（例如零客户端）或是否会重新利用现有硬件。
网络输入
是否会使用 CD 或 DVD 刻录机？		它用于了解 PCoIP 带宽的考虑因素。
是否会使用麦克风插孔耳机？		它用于了解 PCoIP 带宽的考虑因素。
是否会使用 Dragon Naturally Speaking 或 Dragon Medical？		它用于了解 PCoIP 带宽和存储 IOPS 的考虑因素。
是否会使用 USB 电话、录音机等设备？		它用于了解 PCoIP 带宽的考虑因素。
是否会定期进行视频流播放？		用于了解 PCoIP 带宽的考虑因素。
是否需要 VOIP 解决方案？		用于了解 PCoIP 带宽和终端设备的考虑因素。
大多数用户会远离 VDI 多远？		用于了解网络需求和拓扑结构。
解决方案会部署在敏感或机密网络中吗？		用于了解整体解决方案的高级配置。
目前你的物理桌面网络环境中使用了多少个 VLAN？		用于了解现有的网络布局。
是否支持远程办公地点？		确定是否需要整合远程办公地点解决方案。
目前桌面设备可用的动态主机配置协议（DHCP）范围（及其大小）是多少？		它决定了现有的网络拓扑结构。
配置文件管理输入
你今天使用什么进行配置文件管理？		它决定是否需要配置文件管理，和/或是否已经有现成的解决方案。
用户的主目录存放在哪里？		它决定了现有的配置文件管理解决方案。
成功标准
解决方案上线三个月后，如何确定你选择了正确的解决方案？		它引出了 VDI 项目的成功标准。
你实施 VDI 解决方案的主要动机是什么？		它引出了 VDI 项目的成功标准。

注意事项

自助服务终端用于标识将被配置为自动连接到 VMware View 环境中的虚拟桌面的终端设备。

指标收集

完成问卷后，便可以开始收集来自组织现有物理环境的实际数据。通过在收集使用数据之前完成问卷调查，指标收集阶段可以集中在关注的领域。

例如，如果在问卷调查中发现，VMware View 解决方案将支持工作 10 小时且经常使用双向音频（例如，Dragon Medical）的外科医生，那么收集这些外科医生的数据（如 CPU、内存和网络使用情况）会是有益的，即使他们只是整体最终用户群体中的一小部分。

可以在现有的物理桌面基础设施和现有的 VDI 解决方案上执行评估（例如，对于打算从 Citrix XenDesktop 迁移到 VMware View 的组织）。

有多种方式可以收集评估数据，包括使用 Liquidware Labs Stratusphere Fit™。Fit 使用运行在桌面上的软件，并将数据报告回一个中央位置（Stratusphere Hub）。以下是收集的一些关键指标：

• CPU 和内存使用情况（总量及每个应用的使用情况）

• 平均登录延迟

• 平均输入/输出操作每秒（IOPS）

• 网络延迟

• 外设

除了指标和库存收集外，Fit 还可以用于评估用户是否适合 vDesktop 解决方案。

注意

有许多成功的 VDI 解决方案在没有经过指标收集阶段的情况下实现；然而，这些解决方案很可能是由非常资深的 VDI 专业人员实施的。如果可能的话，建议执行指标收集阶段，因为这将大大提高项目的成功机会，并为项目进展过程中的好坏结果提供数据支持。

指标收集阶段的目标如下：

• 建立基准的平均用户

• 确定环境中使用最频繁的十个应用程序

• 识别当前点

• 识别 VDI 潜在的陷阱

• 将用户分类到不同的使用案例中

Fit 还可以用于将未来的 vDesktop 用户按使用类型进行组织，这些使用类型会转化为 View 基础架构中的桌面池。

例如，如果 Stratusphere Fit 确定绝大多数用户在其物理桌面上分配了 2 GB 的内存（并使用了 80%的分配内存），但一小部分用户有 4 GB 的内存（并使用了 80%的分配内存），则很可能需要两个不同的链接克隆桌面池（至少）。第一个池将有一个基本的桌面映像，内存为 2 GB，而第二个池将有一个基本的桌面映像，内存为 4 GB：

上述图示说明了数据必须先收集，然后进行分析。分析后可以开始设计。

为了正确确定需要采购多少物理硬件以及如何在桌面池中进行用户群体的合理分配，收集基于真实用户活动的信息至关重要。需要收集的一些关键指标包括如下的平均值和峰值：

• 内存使用率

• CPU 使用率

• CPU 准备/等待时间

• 网络吞吐量

• 网络延迟

• 磁盘吞吐量（MBps）

• 磁盘活动（IOPS）

• 磁盘读写百分比

• 使用频率最高的应用程序

• 显示器数量

• 独特的外设需求

• 未使用的应用程序

• 图形密集度

使用大多数收集工具时，必须在待调查的桌面上安装代理。安装该代理的最有效方式通常是通过现有的机制，如组策略对象、Microsoft System Center Configuration Manager、登录脚本或其他多种方法。

注意

虽然数据收集工具在敏感或机密网络上通常是禁止使用的，但 Liquidware Labs 已经采取了必要的措施和认证，使其能够在许多敏感网络上运行这些工具。

Fit from Liquidware Labs 生成的独特报告帮助 VDI 架构师正确理解现有的物理桌面环境，从而设计和实施一个强大的 VMware View 解决方案：

您可以在www.liquidwarelabs.com/images/Bubble_Graphs.png找到前面的截图。

推荐收集数据的时间为两到四周，以确保足够的时间捕捉到最典型的业务周期。如果被评估的组织有已知的高峰工作期（例如，季度末结算），在此期间收集数据可能会有帮助。然而，建议不要让收集异常数据拖慢整体项目进度。仔细分析是重要的，但就像过长的容量规划评估可能使服务器虚拟化项目陷入困境一样，过长的 VDI 评估也可能带来同样的问题。

数据处理

一旦收集了终端用户的数据，重要的是要正确理解和分析从客户环境中获得的信息，如下所示：

• 内存使用量（以 MB 为单位）

  • 输入： 它是终端用户消耗的总内存（包括活动内存和峰值内存）。此指标的总和并不能得出 VDI 解决方案所需的总内存。

  • 输出： 它有助于确定物理环境所需的总内存量。公式如下：

    vDesktops 所需的 MB + 支撑基础设施所需的 MB + 虚拟机管理程序的 MB 开销 + 交换空间所需的 MB = 总所需的 MB。

• CPU 使用量（以 GHz 为单位）

  • 输入： 它是终端用户消耗的总 CPU 使用量（包括活动和峰值）。在 VDI 环境中，总 CPU 使用量可能不如每核心的用户数那么重要。

  • 输出： 这有助于确定物理环境所需的总 CPU 使用量，并用于确定哪些用户可能需要多个 vCPU。

    注意

    为什么是每核心的用户数？

    计算每个核心的用户数比尝试确定每个用户所需的总 MHz 更为重要。两个与 CPU 相关的关键指标是 CPU Ready 和 CPU Wait。CPU Ready是指一台机器在等待 CPU 变得可用时所花费的时间（单位：毫秒）。如果设计中每个核心实现了过多的虚拟桌面（vDesktops），最终用户将会经历较高的 CPU Ready 时间，且他们的虚拟桌面会变得缓慢，因为虚拟桌面需要等待彼此释放 CPU 时间以满足自己的处理需求。CPU Wait是指 CPU 等待 I/O 完成时所花费的时间（单位：毫秒）。较高的 CPU Wait 通常表明存在磁盘或网络瓶颈。例如，某个特定的虚拟桌面可能正在运行一个过程，该过程需要读取和写入大量数据到本地文件系统。如果底层存储无法满足虚拟桌面进程的性能需求，就可能会出现较高的 CPU Wait 时间。

• 网络吞吐量（单位：KBps）

  • 输入： 用于确定现场和/或远程解决方案中的潜在瓶颈。由于 VDI 解决方案通常在一个集中位置实施，网络吞吐量可用于确定远程办公地点与 VDI 位置之间所需的带宽。

  • 输出： 例如，远程站点的最终用户与集中位置 VDI 之间的网络吞吐量较低时，可能会选择在远程办公室实施 VDI，并从中心位置进行管理（这是一种解决有限网络吞吐量的方案）。理解 VDI 用户可能有的任何特殊网络带宽需求也是非常重要的。

• 网络延迟（单位：毫秒）

  • 输入： 用于确定现场和/或远程解决方案中的潜在瓶颈。由于Microsoft 远程桌面协议（RDP）和 VMware 的 PCoIP 协议对延迟敏感，因此理解最终用户与 VDI 位置之间的数据传输的往返时间非常重要。

  • 输出： 例如，具有高网络延迟的环境可能会选择在终端设备和虚拟桌面内实施优化 PCoIP 协议的策略。这些策略可能限制高级图形功能并使用压缩来最大化最终用户的体验。

• 磁盘吞吐量（单位：MBps）

  • 输入： 用于从带宽角度确定支持 VDI 的底层存储环境中潜在的瓶颈。

  • 输出： 例如，某些需要大量磁盘吞吐量的用户（如录音）可能需要将其虚拟桌面存放在与其他虚拟桌面用户不同的数据存储上。这不仅暗示并促进了存储平台的分层，还防止了低磁盘吞吐量的用户受到高吞吐量用户的影响。

• 磁盘活动（单位：IOPS）

  • 输入： 用于从性能角度确定支撑 VDI 的底层存储环境可能存在的瓶颈。

  • 输出： 磁盘 IOPS 是 VDI 设计中最重要的指标之一，因此，本书后续章节将专门讨论 VDI 解决方案中存储的基本概念。在迁移到 VMware View 解决方案之前，收集终端用户消耗的磁盘 IOPS 可以为需要在解决方案中支持的总体磁盘 IOPS 数量提供参考。然而，正如本书稍后讨论的那样，存储设计在 VMware View 解决方案的整体成功中起着至关重要的作用。

• 磁盘读/写百分比

  • 输入： 用于帮助确定适合 VDI 的存储环境。

  • 输出： 关于为 VDI 设计合适存储环境的更多信息可以在本书后续部分找到。

• 最常用的应用程序

  • 输入： 列出大多数用户在特定用户群体中日常使用的常见应用程序。

  • 输出： 了解最常用的应用程序有助于确定给定应用虚拟化（AppVirt）解决方案的候选列表，例如，VMware ThinApp。最常用的应用程序列表还可能有助于确定哪些应用程序将包含在桌面池的父镜像中。

• 显示器数量

  • 输入： 用于确定给定用户正在使用多少个显示器。

  • 输出： 由于支持额外的显示器将改变 vDesktop 的内存设置（如果使用链接克隆，则影响到给定池中的所有 vDesktop），因此，将多显示器用户与单显示器用户区分开来可能会有益。随着环境数量的增加，双显示器已成为标准，而四显示器则属于异常情况。在这种情况下，将四显示器用户单独区分可能会有所帮助：

• 独特的外设要求

  • 输入： 用于确定与 VMware View 解决方案可能存在的兼容性问题。

  • 输出： 例如，一个用户群体可能需要使用网络摄像头进行协作。在撰写本文时，VMware View 5 尚不支持网络摄像头。

• 未使用的应用程序

  • 输入： 用于确定在桌面环境中从不使用或很少使用的应用程序。

  • 输出： 例如，一个环境中可能包含多个当前金镜像中的应用程序。然而，从实际角度考虑，可能不需要将这些应用程序包括在 VMware View vDesktop 部署的基础镜像中。

• 图形强度

  • 输入： 用于从带宽角度确定支撑 VDI 的底层存储环境可能存在的瓶颈。

  • 输出： 例如，用于确定哪些用户可能需要额外的硬件（例如，刀片 PC）来提供终端用户所需的图形水平。在某些环境中，vDesktop 的能力无法提供某些用户群体所需的图形能力。在这些环境中，将刀片 PC 解决方案集成到 VDI 中的解决方案（例如 ClearCube 的解决方案）将是理想的。

使用场景定义

一旦在评估阶段收集了足够的数据，就可以分析这些数据以确定具体的使用场景。

使用场景是一个集合，涵盖连接、性能、外设和其他特征，适用于一组 vDesktop 用户。在定义环境的主要使用场景时，重要的是使用评估阶段收集的数据以及（如果可能）观察到的用户实际操作情况。

例如，通过仔细的评估阶段，可以确定如下内容：

• 总计 300 个 vDesktop 用户

• 其中 50 个需要支持 2 个显示器

• 其中 25 个具有高性能需求，配置为 2 个 vCPU 和 6 GB 内存

• 其中 200 个满足平均需求，配置为 2 个 vCPU 和 1.5 GB 内存

• 其中 25 个需要支持 4 个显示器

如果设计尝试在单一桌面池中支持所有前述需求，则该桌面池将支持 4 个显示器和配置为 6 GB 内存的 vDesktops。此类设计将浪费大量物理资源（例如，175 个 vDesktop 额外需要 4 GB 内存，总共浪费 700 GB）。

因此，正确的设计应如下所示：

• 基于 2 个 vCPU 和 6 GB 内存的金图像的 25 个桌面池

• 一个桌面池，包含 50 个桌面，支持最多 2 个显示器

• 一个桌面池，包含 25 个桌面，支持最多 4 个显示器

• 一个包含 200 个桌面的桌面池，支持大部分用户环境；基于 2 个 vCPU 和 1.5 GB 内存的金图像

一些关键问题可以帮助确定使用场景，具体如下：

• 提供良好 vDesktop 体验所需的最小性能要求是什么？

• 是否有双向音频需求？

• 必须支持多少个显示器？

• 桌面是否是一次性（非持久）？

• 用户配置文件将如何管理（如果适用）？

• 是否有任何独特的安全或合规需求？

通过确定 VDI 解决方案支持的各种使用场景，最终设计不仅可以支持所需的使用场景，还能确保底层物理基础设施的优化。

在使用场景定义阶段结束时，已收集并与组织讨论并达成一致的设计解决方案所需输入。

设计概述

VDI 解决方案是在典型服务器虚拟化解决方案的基础上增加了连接基础设施、角色管理（如果适用）、桌面池基础设施、终端设备等要求，如下图所示，展示了 VMware View 解决方案栈：

此外，对于经验丰富的服务器虚拟化架构师而言，VDI 解决方案的要求通常与典型的服务器虚拟化解决方案有显著不同（例如，vSphere 集群的设计方式），因此在认识到 VMware View 解决方案的新影响时，必须尊重 VMware vSphere 设计的重要性。例如，VDI 解决方案可能比经典服务器虚拟化解决方案拥有更高的虚拟机到物理机的密度。此外，计算和存储需求可能呈现更强的波动性，具有更高的峰值和更短的持续时间，而不是经典服务器虚拟化解决方案。

尽管以下许多小节（例如存储、用户角色管理）将在本书后面更详细地讨论，但在以下章节中，针对每个设计所使用的方法论会提供简要概述。

存储

存储是影响整体 VMware View 解决方案的重要领域。如果存储基础设施设计不当，整个解决方案可能最终失败。

本书主要关注利用 VMware View Composer 提供的链接克隆技术的 VMware View 解决方案。在使用链接克隆的设计中，所有 vDesktop 都共享一个副本磁盘。因此，存储考虑因素，例如读 I/O 操作每秒（IOPS），在设计 VDI 解决方案的存储子系统时至关重要：

在前面的图示中，重读负载被描绘为每个用户在给定桌面池中都从同一个副本磁盘读取。然而，每个用户将写入他/她自己的操作系统磁盘（以及持久用户数据磁盘和/或非持久临时数据磁盘，如果适用的话）。

此外，了解终端用户的应用环境也很重要，因为像 Nuance 的 Dragon Medical 这样的应用程序在执行转录任务时可能会对磁盘造成较大的负载。对于需要高存储 I/O 的用户，建议将其放入独立的桌面池：

如前图所示，链接克隆允许使用存储分层。在前面的示例中，副本磁盘（一个高读 I/O 负载）被放置在企业闪存驱动器（EFDs）上，并通过 RAID 10 保护。用户数据虚拟磁盘被放置在通过 RAID 5 保护的 SCSI 10K 驱动器上。链接克隆使得存储子系统能够在经济性、技术性和功能性上量体裁衣，以匹配 VDI 的需求。

数据存储级别的隔离

在设计 VMware View 解决方案时，尤其是利用链接克隆技术时，理解能够将桌面池、用户类别和性能需求分开存放在不同数据存储上的内在优势是非常重要的。

在下图中，Pool 1 支持需要 I/O 密集型应用的重负载用户，Pool 2 支持一般用户群体，而 Pool 3 支持为上门客户提供的自助服务终端：

例如，在 Pool 1 中，副本磁盘可以存放在性能优化的 EFD 上（支持极高的 IOPS），用户的写入活动（例如，操作系统磁盘）发生在 SCSI 15K 硬盘的 RAID 10 集合中（支持高 IOPS），而用户的非持久性数据存放在 SATA RAID 5（支持低 IOPS）的硬盘上。

此外，对于 Pool 2，副本磁盘可以位于一个基于 EFD 的单独数据存储上，用户的写入活动发生在一个单独的 SCSI 10K RAID 5 数据存储上。Pool 2 也可以使用相同的数据存储来存放非持久性的临时数据，假如需要的话。

最后，Pool 3 还可以使用与 Pool 1 和 Pool 2 分开的数据存储来存放其副本磁盘和用户的操作系统磁盘。

为什么这是有益的？

这样做有以下好处：

• 节省成本： 在此解决方案中，不需要为整个存储阵列配置昂贵的 EFD，而只需购买足够的 EFD 来支持所需的副本磁盘。相反，对于非持久性和性能不敏感的数据，可以使用便宜的 SATA 硬盘。

• 性能调优： 在此解决方案中，使用了适当的技术（例如，EFD）来提供优化的终端用户体验。通过使用分层存储，只有在必要时才使用针对高 I/O 优化的磁盘，而不是将其用于所有磁盘活动。

• 性能隔离： 在此示例中，Pool 1 中的极高负载使用（例如，登录风暴、应用程序批处理等）不应影响 Pool 2 中的终端用户（假设存储阵列网络不是瓶颈）。因此，可以将高 I/O 用户（例如，双向音频医生）与中等 I/O 用户（例如，行政人员）隔离开来。

• 服务级别协议： 在此示例中，每个池使用自己的数据存储来存放副本磁盘。然而，如果每个池使用相同的数据存储来存放副本磁盘，可能会导致一个桌面池的操作和活动影响到另一个桌面池，从而使遵守和执行服务级别协议（SLA）变得非常困难。

网络

在设计 VDI 时，必须考虑几个核心网络组件，包括动态主机配置协议（DHCP）租约、域名系统（DNS）解析、负载均衡和虚拟交换机技术。本书稍后会详细介绍这些内容，但值得注意的是，建议尽早与组织的网络团队进行沟通。

计算

正如在第一章中提到的，VMware View 组件，每个核心的用户数量是 VMware View 解决方案计算层的主要衡量标准。随着处理能力和处理密度的不断提高，计算层变得越来越不需要过多关注，特别是在使用六核或更多核心的处理器时。

VMware vSphere 和 View 桌面池基础架构

正如本书后续章节中更详细讨论的那样，健全的 VMware vSphere 基础架构对强大的 VMware View 解决方案至关重要。对于经验丰富的 vSphere 架构师来说，健全的 vSphere 基础架构的许多概念将是熟悉并且已经实践过的。然而，VMware View 解决方案可能会超出 VMware 定义的某些最大值。例如，在当前版本的 VMware vCenter 中，启动的虚拟机的最大数量为 10,000。对于一些大规模的 VDI 实施，这个数字很容易被超越。无论如何，理解从管理层的角度来看，10,000 个虚拟桌面可能不是一个可以接受的数字是很重要的。本书将介绍如何为大规模 VMware View 解决方案正确设计 VMware vSphere 基础架构。

Pod 架构

如前所述，VMware View 解决方案可能会超出 VMware vSphere（底层虚拟基础架构平台）允许的最大值。因此，多个 VMware vSphere 环境集合，称为 pod，被用来为 VDI 提供模块化的构建块。pod 是一组运行 VMware ESX 的物理服务器，包含一个或多个 VMware vCenter 服务器，以及支持存储和网络基础架构，以提供 n 数量的虚拟桌面。这个数量会根据设计、独特的客户需求以及评估阶段收集的数据而有所不同：

在上面的图示中，pod 由一个 VMware vCenter 环境组成，该环境管理两个集群，每个集群有八个主机。每个集群八个主机的配置是 VMware View 支持的最大配置。因此，在大多数 VMware View pod 中，一个集群通常包含六到八个主机（通常是八个）。

应用分发基础架构

无论是使用 VMware ThinApp、Citrix XenApp、Microsoft App-V 还是其他解决方案来交付应用程序到桌面环境，了解环境的运行位置、使用方式以及它对整体解决方案的影响（例如，网络影响）都至关重要。本书将涵盖与 VMware View 解决方案相关的应用虚拟化的关键概念。然而，本书并不深入探讨应用虚拟化的技术组件。

用户画像管理

在 VDI 解决方案中，管理用户画像有很多选择，例如 Microsoft 文件夹重定向和用户状态迁移工具（User State Migration Tool）、Liquidware Labs ProfileUnity 和 AppSense。

VMware 收购了 RTO，现在提供与 VMware View 5 集成的用户画像管理解决方案。然而，在写作时，VMware View 架构师社区在大规模解决方案中尚未充分利用内置的这一功能。不管怎样，用户画像管理将在本书后续部分中讨论，因为理解它们如何集成（尤其是在非持久性桌面池中的集成方式）以及用户画像可能带来的潜在网络影响是非常重要的。

什么是用户画像？

用户画像是与特定用户相关的一组设置，包括设置、收藏夹、快捷方式、壁纸、自定义、桌面图标、打印机和其他独特的设置。

如前所述，vDesktop 由三个抽象层组成，这些层是操作系统层、应用层和用户画像层。

操作系统层是 vDesktops 的执行环境，主要是 Microsoft Windows XP 或 Microsoft Windows 7（或计划为 Microsoft Windows 7）。

应用程序（Apps）层可以通过使用应用虚拟化解决方案（例如，VMware ThinApp）作为单独的层，或者可以包含在操作系统层中：

在前面的图示中，应用层并不独立，而是嵌套在操作系统层内。这意味着，要更新桌面池中的单个应用程序，必须更新整个父镜像：

在前面的图示中，应用层独立于操作系统层，因此可以独立更新。这使得管理员能够更新单个应用程序，而无需对 VMware View 桌面池的组成进行大规模更改。在大多数情况下，使用应用虚拟化（AppVirt）解决方案来管理 VDI 中的某些或所有应用程序具有显著优势。应用程序的用户群体和性能特点可能会影响你关于如何交付应用程序的整体决策。

连接基础设施

连接基础设施包括代理服务器或 VMware View 连接服务器、可选的负载均衡器、最佳 WAN 优化器、DNS 解决方案以及任何高级路由功能（例如，思科全球站点选择器）。

由于所有传入的连接最终都将首先路由到 VMware View 连接服务器，因此必须确保至少有一个 VMware View 连接服务器始终可供终端用户使用。

一旦连接成功认证，VMware View 客户端会直接连接到 vDesktop 中的 VMware View 代理；这被称为直接连接。对于直接连接，一旦用户已连接到桌面，VMware View 连接服务器的故障不会影响现有连接，但会影响未来的连接请求。

可以使用 Microsoft 协议与 VMware View 进行配合。Microsoft RDP 使用隧道连接。这种隧道连接会与 View 连接服务器或 View 安全服务器打开第二个 HTTPS 连接。在这种情况下，如果提供次要 HTTPS 连接的 View 连接服务器或 View 安全服务器出现故障，会导致终端用户断开连接。

终端设备

如本书后续所详细介绍，有各种终端设备提供不同的好处（和权衡）。了解市场上众多设备是很重要的，这有助于理解它们如何融入 VMware View 解决方案。本书将介绍主要的终端设备类别，包括厚客户端、薄客户端、零客户端、Apple iPad 以及前瞻性的终端设备。

人员

人员是任何 VDI 解决方案中最重要的层面。VDI 架构师必须始终明白，项目的成功往往会根据使用该解决方案的人、他们的体验、他们的感知以及他们过渡到虚拟桌面环境的情况来衡量。

如果不将人们置于解决方案的核心位置，可能会带来灾难性的后果。从终端设备到桌面池配置的选择，都应该考虑最终用户的幸福感。

验证

一旦设计方案已制定、审核并批准，就进入验证阶段。验证通常在全规模解决方案的代表性子集上进行。例如，在一个利用两台完全配置的 HP c7000 Blade 机箱的解决方案中，可以使用一个半配置的机箱来测试配置、基本功能和基础存储性能。在某些场景下，可能会使用一次性硬件来测试软件组件。

利用经济可扩展的硬件平台，如 Nutanix 融合虚拟化设备（www.nutanix.com/）或 Pivot3 vSTAC（pivot3.com/），不仅可以以较低的入门成本验证设计，还可以支持未来的生产解决方案。

验证解决方案的最佳方法之一是根据设计文档中详细的规格构建一个试点环境。试点环境搭建完成后，可以招募一个试点用户组来测试用户体验、功能性，并对底层硬件施加负载。

VMware View Planner 工具（前身为 VMware RAWC）

VMware View Planner 工具，前身为参考架构工作负载模拟器（RAWC）工具，是在 VMware View 环境中模拟终端用户连接和活动的最佳方式。对于希望并行对 VMware 及其他竞争解决方案进行压力测试的组织，Login VSI 工具（www.loginvsi.com/）将支持对比测试。VMware View Planner 工具仅适用于 VMware View 环境。

VMware View Planner 工具包含以下内容：

• 会话启动器虚拟机： 此虚拟机启动实际的 vDesktop 会话。每个会话启动器虚拟机最多可支持 20 个并发会话。

• 控制器虚拟机： 此虚拟机托管 View Planner 界面和用于配置及日志文件的网络共享。

• 目标 vDesktops： 用于压力测试的 vDesktops 上安装了 View Planner 代码（或作为父镜像的一部分）。

• 电子邮件服务器虚拟机（可选）： 如果将使用 Microsoft Outlook 进行 View Planner 测试，并且没有可用的 Microsoft Exchange 服务器进行测试，则此虚拟机是必需的。

View Planner 可以根据需要执行以下终端用户任务：

• Microsoft Word： 插入文本，保存修改，调整窗口大小，关闭应用程序

• Microsoft Excel： 插入数字，插入和删除列和行，复制和粘贴公式，保存修改，调整窗口大小，关闭应用程序

• Microsoft PowerPoint： 打开演示文稿，进行幻灯片演示，调整窗口大小，关闭应用程序

• Microsoft Outlook： 设置邮箱，发送电子邮件，执行发送/接收，调整窗口大小，关闭应用程序

• Internet Explorer： 浏览网页，调整窗口大小，关闭应用程序

• Windows Media Player： 查看视频，关闭应用程序

• Adobe Acrobat Reader： 打开 PDF 文档，滚动浏览文档，调整窗口大小，关闭应用程序

• Java Runtime： 运行 Java 应用程序，关闭应用程序

• McAfee AntiVirus： 执行实时病毒扫描，关闭应用程序

• 7-Zip： 压缩文件，关闭应用程序

通过这份功能全面的清单，可以执行多种测试，以测试整体 VDI 性能、登录风暴、启动风暴、存储性能等。

注

启动风暴与登录风暴

在研究、设计、讨论和规划 VDI 解决方案时，启动风暴和登录风暴这两个术语将经常出现；然而，这两个术语不能互换使用。

启动风暴是指足够多的虚拟桌面启动（或从挂起状态恢复），导致整体 VDI 性能下降。这可能是由于一个或多个数据存储无法承受 I/O 负载，虚拟桌面/数据存储过多导致文件锁冲突，DHCP 租约请求洪水等原因造成的。

登录风暴是指足够多的终端用户登录虚拟桌面，导致整体 VDI 性能下降。这可能是由于创建初始配置文件、流式传输用户的个人信息、Active Directory 性能缓慢、磁盘未对齐（例如，Windows XP 未正确设置偏移量）等原因造成的。

将 RAWC 与像 Liquidware Labs Stratusphere UX（用户体验）或 RTO PinPoint 等监控解决方案结合使用，可以让 VMware View 架构师在验证阶段识别瓶颈，而不是在实施阶段。

比较存储平台

由于 RAWC View Planner 提供了对一系列定制测试（无论是固定的还是随机的）进行科学测试的方法，这些测试可以成为实验中的控制变量，而存储平台则是实验的变量。

例如，如果需要量化 RAID 10 中 EFD 相较于 SCSI 15K RAID 10 的真正优势，可以在第一轮使用 EFD，在第二轮使用 SCSI 15K，针对桌面池运行保存的 RAWC 测试。

该技术不仅可以用来测试、量化和优化存储阵列及其配置，还可以用来比较来自多个供应商的存储阵列。

非常感谢 Fred Schmischeimer 对 RAWC 工具的帮助，以及他提供的信息指南《虚拟桌面参考架构的工作负载考虑因素》。

总结

VDI 解决方案设计复杂；通过采取一种结合硬数据（指标收集）以及组织输入（问卷）的有针对性方法，适当设计的可能性大大增加。本章讨论了 VMware View 解决方案中的各个层次，需注意的一些陷阱，以及可以帮助支持整体设计和验证过程的一些行业工具。

下一章讨论了 VDI 架构师可以做出的最重要的设计考虑之一，持久性还是非持久性？ 这个问题的答案是 VMware View 设计的基石，因此需要充分理解，以确保最佳的设计结果。

第三章：持久或非持久 vDesktop

在设计过程中必须尽早做出的一个基本决策是选择使用持久还是非持久 vDesktop。这个决定可能会影响到整个 VDI 的多个领域，包括存储、桌面池和管理。

本章内容将涵盖：

• 持久桌面

• 非持久桌面

• 多站点解决方案

• 如何为您的组织选择

持久桌面是分配给特定终端用户并且在注销后会保存其状态的 vDesktop：

例如，在上面的图示中，如果 User_1 第一次登录到 VMware View 环境并自动分配到 vDesktop_7，他今天、明天以及直到分配被移除之前，都会连接到 vDesktop_7。如果 vDesktop_7 出现问题并不可用，User_1 将无法获得一个正常的工作环境，也无法进行有效的工作。

使用持久桌面时，如果分配的 vDesktop 不可用，VMware View 不会自动重新分配终端用户到一个可用的 vDesktop。

持久 vDesktop 会保留持久数据，直到：

• vDesktop 已从特定用户解除分配

• vDesktop 所在的桌面池被刷新（链接克隆）

• vDesktop 所在的桌面池被重新组合（链接克隆）

非持久桌面是一种未分配给特定终端用户的 vDesktop，而是提供给终端用户群体使用：

例如，在上面的图示中，如果 User_1 登录到 VMware View 环境，他会被分配一个可用的 vDesktop（例如，vDesktop_9）。当他/她注销后再次登录到 VMware View 环境时，系统会随机分配一个来自池中的其他可用 vDesktop。

每个 vDesktop 在任何给定时间只能有一个所有者。

有几个设置可以从 VMware View 管理员控制台进行调整，决定在用户执行注销时，非持久 vDesktop 从用户解除分配的速度。

持久桌面

从历史上看，持久 vDesktop 在 VDI 实现中得到了广泛使用，因为持久 vDesktop 最接近物理世界，能够让终端用户和 IT 管理员更容易理解虚拟世界。这种 1:1 的关系（终端用户与 vDesktop 之间的关系）可能是最简化的部署选项，但其设计和成本考虑需要被充分理解。

持久 vDesktop 通常在组织中更容易进行政治上的推销，因为每个用户仍然拥有一个独立的（虚拟）桌面资产。下表解释了与持久 vDesktop 相关的领域：

区域	影响
桌面池大小	每个终端用户都需要一个 vDesktop。
可用性	如果用户分配的 vDesktop 不可用，用户将无法连接。
操作系统故障的可恢复性	可以使用 VMware HA 监控 vDesktop 对基本 ping 命令的响应。如果 vDesktop 没有响应，它可以通过 VMware vSphere 自动重启。
站点故障的可恢复性	无法轻松恢复站点故障。
成本	VDI 必须支持整个目标用户群体的 vDesktop，包括计算和存储要求。

示例场景

以此为例，假设 Customer_A 有 6,000 个终端用户。他们计划转向 VMware View 解决方案。Customer_A 每天运行三班制，每班有 2,000 个终端用户工作。

客户请求帮助以确定解决方案所需的硬件范围（例如，提供物料清单或材料清单）。

平台将使用 Windows 7，配置 1 个 vCPU、2GB 的 RAM 和 50GB 的C:\驱动器。

硬件平台决定为每台服务器配置 2U 机架服务器，每台服务器配备两个 6 核处理器（每台服务器总共 12 个核心）。

使用每核心 10 个虚拟机的平均保守估算，得到每台服务器可支持 120 个 vDesktop。每个 vDesktop 需要 2GB 的 RAM，因此需要 240GB 的 RAM 来支持 120 个 vDesktop。加上操作系统开销以及可以轻松从任何供应商处订购的数量后，将 240GB 的 RAM 上调至每台服务器 256GB。

因此，针对该解决方案所使用的服务器规格包括一台 2U 服务器，配有两个 6 核处理器和 256GB 的 RAM。以下表格解释了服务器规格和与持久 vDesktop 相关的成本：

区域	描述
物理服务器规格	一台 2U 服务器，配有两个 6 核处理器和 256GB 的 RAM
每台物理服务器上的 vDesktop 数量	120
终端用户总数	6,000
在任何给定时刻需要 vDesktop 的终端用户总数	2,000
必须配置并可用的 vDesktop 总数	6,000
不考虑 n + 1 情况下所需的物理服务器总数	50
估算所需机架数量	3
每台物理服务器的成本	$40,000
物理服务器成本小计	$2,000,000
处理器总数	100
每个 vDesktop 的 VMware vSphere View Premier 估算费用	$250
VMware View 许可小计	$1,500,000
总成本	$3,500,000

尽管 Customer_A 在任何给定时刻只有 2,000 个终端用户在线，但由于 Customer_A 有 6,000 个独立终端用户，为了支持这个环境下的持久性 vDesktop，VDI 必须提供 6,000 个 vDesktop。可以使用非常严格的超时值和注销参数来减少支持的 vDesktop 总数（可能从 6,000 减少到 5,000），但这会增加整体解决方案的风险，并且在某些环境中可能不可行。

以每台物理服务器 40,000 美元的粗略估算，估计的总成本，包括服务器费用以及 VMware vSphere 和 VMware View Premiere 的粗略估算（不包括捆绑或附加定价），为 3,500,000 美元。

该估算未包括端口费用的财务考虑。例如，如果每台服务器只需要两个网络连接（例如，使用 10GbE），那么生产网络连接还需要额外的 99 个交换机端口，以及一个单独的带外管理连接（例如，HP ILO）。

该估算未包括保护 VMware vCenter 服务器的 VMware vCenter Server Heartbeat 所需的额外 VMware vCenter Server 数量的财务考虑。因为大型 VMware View 解决方案可能需要额外的 VMware vCenter 服务器，并且这些服务器可能会受到 VMware vCenter Server Heartbeat 的保护（每个 vCenter Server 约 15,000 美元）。

该估算未包括与服务器相关的冷却和电力成本的财务考虑。

从人力资源管理的角度来看，操作上也更加困难。随着人员的进出，vDesktop 可能会扩展并消耗资源，因为没有简单的方法来跟踪和维护与用户帐户相关的用户数据磁盘。

最后需要考虑的是持久解决方案所需的物理 U 空间。对于需要最小占用空间的环境（例如，战术安装），每一个 U 都具有重要意义。

总结来说，持久桌面对于大多数环境，特别是大规模环境，可能是一种低效的解决方案。

非持久桌面

非持久 vDesktop 解决方案随着 VDI 在行业中越来越广泛应用，并且实施规模越来越大，已经变得越来越普遍。由于持久 vDesktop 通常需要大量的额外资源，即技术、人力和财力，本书将主要关注利用非持久 vDesktop 的解决方案。

虽然大多数人在想到 VDI 时仍然会想到持久 vDesktop，但展示在某些情况下利用非持久解决方案所带来的优势和成本节省是非常重要的。

VDI 更关注的是在需要时提供桌面资源，而不是数据中心中某台特定虚拟机的拥有权，且这些资源是根据用户的特定配置文件进行定制的。虽然有很多解决方案不需要定制 vDesktop（例如，酒店中的自助服务终端解决方案），但大部分 VDI 实施将针对具有独特桌面需求的用户。以下表格解释了与非持久 vDesktop 相关的领域：

区域	含义
桌面池大小	需要为最大数量的并发用户配置一个 vDesktop。
可用性	只要池中有可用的 vDesktop，用户就可以连接到 vDesktop。
可恢复性操作系统故障	只要池中有可用的 vDesktop，用户就可以连接到 vDesktop。
可恢复性站点故障	尽管从站点故障中恢复尚未“开箱即用”，但非持久性 vDesktop 强制用户的个人配置文件存储在 vDesktop 外部，从而使得 vDesktop 环境的复制和恢复变得更加容易。
成本	VDI 必须支持目标最大并发用户数的 vDesktop；这包括针对峰值负载的计算和存储需求，而不是基于用户总数的理论最大值。

示例场景

为了继续本章之前的示例，Customer_A 有 6,000 名最终用户。他们计划迁移到 VMware View 解决方案。Customer_A 每天运营三班制，在任何给定时间，2,000 名最终用户正在工作。下表解释了与非持久性 vDesktop 相关的服务器规格和成本：

区域	描述
物理服务器规格	一台 2U 服务器，配备两颗 6 核处理器和 256 GB 内存
每台物理服务器的 vDesktop 数量	120
最终用户总人数	6,000
在任何给定时间需要 vDesktop 的最终用户总数	2,000
可恢复性站点故障	2,000
在不考虑n + 1 的情况下所需的物理服务器总数	17
估算所需机架数量	1
单台物理服务器成本	$40,000
物理服务器成本小计	$680,000
处理器总数	34
估算的 VMware vSphere View Premier 每 vDesktop 成本	$250
VMware View 许可证小计	$500,000
总成本	$1,180,000

非持久性解决方案的优势显而易见。例如，在持久性解决方案中，需要 50 台物理服务器（而非持久性解决方案只需 17 台）以满足用户负载的需求。通过节省大量物理服务器（以及相关的软件许可证）的采购成本，整体 VDI 解决方案所需的资金减少了三分之一。这些节省的费用来源于仅支持最大并发用户负载，而不是为每个将连接到 VDI 的用户配置一个固定的 vDesktop。

其他非持久性注意事项和考虑因素

非持久性 vDesktop 解决方案应被视为易变的。这意味着，当用户注销时，写入 vDesktop 本地磁盘的任何数据都将无法访问，甚至可能被销毁。

因此，对于要求用户保持个人资料、定制应用程序、独特设备映射等的解决方案，必须使用个人资料管理解决方案作为整体 VDI 的一部分。个人资料管理将在本书后续部分详细介绍。

非持久性 vDesktops 的另一个潜在好处（如果设计得当）是，它们可能会减少帮助台的支持请求。这是因为该解决方案更注重虚拟桌面资源池中一定数量的 vDesktops 可用性，而非单个用户 vDesktop 的可用性。重点放在桌面池健康（以及可能的用户角色健康）上，因此无需过多担心特定用户的 vDesktop，因为在每次登录时，资源会随机分配给每个最终用户。

潜在的缺点是，支持角色管理层的工作量可能增加，这取决于所选方案的设计和实施。

多站点解决方案

跨多个站点的 VMware View 解决方案并不特别罕见。大学校园、大型公司甚至小型企业可能需要从多个物理位置提供 vDesktops。

在这些场景中，有一些关键问题需要向组织提出。问题如下：

1. 每个最终用户的桌面体验是否应该是独特的？

   • 本质上，是否应该将最终用户角色保存以包括对桌面环境的更改、应用程序的自定义等？

2. 如果前面问题的答案是“是”，那么用户角色是否应该在所有站点之间保持一致？

   • 例如，如果 Liliana 登录到 Site_A 并对她的桌面进行修改，如果她稍后登录到 Site_B 的 VDI，这些设置是否应该被反映出来？

   

上述图示展示了一个多站点的 VDI 解决方案，采用 VMware View 持久性虚拟桌面（vDesktops），并基于真实世界的场景。在这个例子中，Site_A 和 Site_B 属于同一组织——Acme Corp。Acme 必须支持员工流动性，因为其两个位置（Site_A 和 Site_B）被其所有员工使用。

用户可能早上在 Site_A 工作，下午则在 Site_B 开会。

如前所示，用户在早上连接到 Site_A 的 VDI，并且由于使用了持久性 vDesktops，他会获得分配的 vDesktop。请记住，在使用持久性 vDesktops 时，用户会被分配一个特定的 vDesktop，并且在 VMware View 管理员取消分配之前，他会保持这个分配。

当用户离开 Site_A 驱车前往 Site_B 时，可能出现以下两种情况：

1. 他没有被分配 vDesktop。

2. 他在 Site_B 运行的完全独立的 VDI 中被分配了第二个 vDesktop。

为什么 Site_A 中的用户 vDesktop 没有复制到 Site_B？

这是因为 VMware View 持久性 vDesktops 是分配给单个用户的独立虚拟机。

如果使用 VMware View 持久性 vDesktops，将一个站点（例如 Site_A）中的持久性 vDesktop 的更改复制到另一个站点（例如 Site_B）并不是一个开箱即用的受支持用例。使持久性 VMware View vDesktops 表现出这种行为需要大量脚本、深入理解底层存储平台、深入理解 VMware View ADAM 数据库，并且可能需要了解如何使用 PowerCLI 操作对象。

这也会增加过多的变量，导致其无法成为一个可持续的 VDI 模型，无法得到有效支持。

作者的经验是，给足够的时间、深入了解 VMware vSphere 和 VMware View，并且有充足的测试时间，几乎任何事情都可以在 VMware View 上实现。然而，VMware View 并没有设计来支持多站点持久性 vDesktops。

第三方附加解决方案（例如，Unidesk）在这些场景中可能会有所帮助。

为什么非持久性 vDesktop 最适合多站点？

下图显示了使用 VMware View 非持久性 vDesktops 和个性化复制的多站点 VDI 结构：

想象一下前面提到的场景。一家组织有两个站点，Site_A 和 Site_B。用户在早上工作时，连接到位于 Site_A 的 VDI 上的 vDesktop，然后前往 Site_B 参加下午的会议。当用户在 Site_B 时，他/她会连接到该站点本地的 VDI。

VDI 架构师如何在两个站点之间保持 VDI 体验的一致性？

通过使用非持久性 vDesktop，用户的个性化配置自然与底层的桌面操作环境分离。通过使用 VMware View 配置文件管理，或第三方解决方案如 AppSense 或 Liquidware Labs ProfileUnity，非持久性 vDesktop 可以拥有与持久性桌面相同的外观和体验（例如，定制设置得以保留），同时提供非持久性 vDesktops 的优势（例如，更大的灵活性）。

在上图中，用户配置文件存储在一个文件共享中，该共享在两个站点之间进行复制。

无论最终用户连接到哪个站点的 VDI，只要他的/她的配置文件已被复制，都是没有问题的。如果实施了具有复制配置文件的非持久性 vDesktop 解决方案，确保用户配置中没有不必要的文件就显得至关重要。适当的过滤技术可以确保像 GB 级的 MP3 文件或下载的电影不会被视为用户个性化的一部分，从而避免它们在复制传输中造成拥堵。

为什么距离很重要

复制是物理学的一个功能。站点之间连接的大小（吞吐量）、速度（延迟）和完整性（丢包）以及需要复制的数据量，有助于确定复制一组用户资料所需的总时间。如果目标是用户在登录 Site_A 或 Site_B 时没有感知差异，那么必须确保给定用户的 Persona 的复制副本。

只有当底层网络、存储和复制解决方案能够满足要求时，才能提供此保证。

通常情况下，两个站点距离越近，复制的数据集越小，越容易满足这些要求。

尽管如此，如果要实施多站点 VDI 解决方案，执行基本的网络调查以识别潜在的障碍是非常重要的，尤其是在实际实施开始之前。

云中的用户资料

带有本地用户资料副本的多站点 VDI 解决方案可能是最常见的多站点 VDI 解决方案。这是因为 VDI 架构师很可能已经熟悉这些技术，而支持技术人员也对类似的解决方案有所了解，即使这些解决方案与 VDI 完全无关。

然而，如果复制过程中出现中断或拥塞，用户可能会在一个站点登录时无法获得最新的用户 Persona。更糟糕的是，可能会陷入“分脑”情景，导致由于存在两个主副本，用户 Persona 的更改丢失或损坏。

虽然这种情况较为少见，并且可以通过适当的复制设计和复制健康监控来应对，但它仍然是可能发生的。

另一种多站点 VDI 解决方案仍然利用非持久的 VMware View vDesktops 和 Persona 管理，但它将用户 Persona 的本地复制副本存储在云中。

以下图示展示了一个带有 VMware View 非持久 vDesktops 和基于云的 Persona 存储的多站点 VDI：

云在此意义上是指任何存储用户资料的外部存储平台。这可以是基于亚马逊的解决方案、本地云服务提供商，或者是同行的社区云服务，只举几个例子。

在这种情况下，由于用户资料始终是读取和写入云存储平台，因此没有站点间复制。

优势是复制问题不再是问题，但缺点是加载用户资料需要连接到云（如互联网、VPN 等）。如果无法连接到云存储，则无法读取或保存用户资料。

此外，大多数云服务提供商对进出流量收取费用。不过，也有例外情况（例如，Amazon Direct Connect），在决定选择托管伙伴时可能会发挥作用。

混合：持久与非持久混合

尽管通常情况下，组织中首个 VDI 使用案例会明确是持久性或非持久性，但随着 VDI 被越来越多地采用，支持的使用案例数量也会增加。

例如，一个组织最初可以实施 VMware View 解决方案来支持其 250 座位的教室环境。这很可能是一个非持久性的解决方案。然而，在看到 VMware View 为教室带来的好处后，该组织可能决定在更大范围内推广 VDI。现在，除了支持教室，执行团队也决定采用 VDI 来支持其移动化生活方式。此外，CEO 还要求能够通过他的 Apple iPad 使用 VDI。

在这种情况下，持久性虚拟桌面可以使工作变得更加简单。实际上，不需要担心用户配置文件，应用程序分发的概念与物理世界中的分发类似。对于执行团队来说，这也可能是最容易进行故障排除的方式，因为你很容易就能知道每位高管使用的是哪台桌面。

VMware View 本地支持同时拥有持久性和非持久性桌面池。除了各自解决方案中的设计要求外，实际上没有其他需要考虑的设计因素。配置文件管理可以在非持久性和持久性虚拟桌面之间统一应用。需要考虑的一点是，在前面的示例中，课堂和执行团队可能会有不同的支持人员负责各自的组。如果确实如此，则需要在 VMware View 管理控制台中定义适当的权限。

如何选择

幸运的是，使用 VMware View，持久性和非持久性虚拟桌面可以并排测试，以查看哪种方式最适合组织的需求。然而，在为组织设计解决方案时，可以遵循一些指导原则来帮助选择持久性或非持久性虚拟桌面。以下是一些问题及其建议的（但不一定唯一的）解决方案类型。这些建议假设读者会回答是：

• 用户是否会安装自己的本地应用程序？持久性。

• 环境是否支持大量的轮班工人？非持久性。

• 是否会使用应用虚拟化？非持久性。

• 是否会使用漫游配置文件解决方案？非持久性。

• 该解决方案是否支持灾难恢复事件？非持久性。

• 用户是否会因应用程序或操作系统许可限制而被分配专用桌面？持久性。

这些高层次的问题将帮助架构师将解决方案引导到正确的方向。需要记住的是，前面的建议并不是绝对的答案。最后，重要的是要记住，持久性和非持久性解决方案可以在同一 VMware View 环境中共存。

总结

持久性问题是任何 VDI 设计中的核心决策之一。持久性定义了虚拟桌面的波动性、应用程序的分发方式以及所需的底层硬件量。对于 VDI 架构师来说，构建一套经过验证的设计组合非常重要。VDI 是一项复杂的技术，因为它涉及很多动态组件。减少每个项目的变量数量非常重要，这可以通过建立一些松散的参数来实现。以下是来自真实场景的一个示例任务声明：

“我是 Acme 的 IT 总监，我需要支持一个有 2,000 个席位的课堂环境，并且经常有人员流动。”

在这种情况下，VDI 架构师的公式可能是：

• VMware View 非持久性虚拟桌面 + VMware ThinApp + 零客户端

通过事先了解解决方案应该是什么样的，架构师可以集中精力关注一些关键变量，如下所示：

• 桌面镜像有多大？

• 应用程序将如何管理？

从头开始为每个项目构建 VMware View 解决方案既不高效，也比从几个稳定的 VMware View 设计中构建一个更容易出错。

下一章讨论了用于连接 VMware View 解决方案的终端设备。终端设备是 VDI 解决方案中的另一个重要部分，因为选择正确的终端设备可以大大提高成功的可能性。理解每种终端设备类型的局限性对于选择适合特定组织的设备至关重要，下一章将讨论这个问题。

第四章：终端设备

VMware View 是通过 PCoIP 协议向终端设备提供桌面体验的解决方案。VMware View 支持的设备种类繁多，包括厚客户端、瘦客户端、零客户端以及其他设备，例如 Apple iPad。本章将涵盖各种类型的客户端以及它们支持和不支持的功能，以便在整体解决方案中做出适当的设计考虑。

在评估 VMware View 解决方案的客户端设备时，需要注意的是，大多数人将工作电脑的质量与显示器的尺寸和外观关联在一起。

例如，Jenson 的桌面下有一台积满灰尘的 HP 工作站，并连接着一台 17 英寸的显示器。如果 IT 部门将 Jenson 的 HP 工作站替换为零客户端和 24 英寸显示器，他很可能会对新设备产生好感。通过为曾经使用 Windows XP 工作站的 Jenson 提供 Windows 7 虚拟桌面，Jenson 很可能会对他的“新电脑”赞不绝口。

设备选择对于 VDI 项目的成功至关重要，因为它是用户连接到虚拟桌面的门户。

本章将涵盖以下内容：

• 厚客户端与瘦客户端

• Teradici PCoIP 驱动的零客户端及其他客户端

• 为您的组织选择合适的设备

厚客户端

厚客户端是运行完整工作站操作系统版本的笔记本或台式机，例如 Windows XP。厚客户端拥有完全可用的操作系统，并使用本地安装的 VMware View 客户端连接到虚拟桌面基础架构（VDI）。

以下是一些厚客户端的示例：

• Dell OptiPlex 工作站

• Lenovo 笔记本

• Apple MacBook Pro

厚客户端的常见优势如下：

• 它们支持本地模式（仅限基于 Windows 的厚客户端）

• 通常，它们提供较高的性能（从图形卸载的角度来看）

厚客户端和瘦客户端的主要区别在于，基于 Windows 的厚客户端能够支持检出的本地模式桌面。而基于 Windows 的瘦客户端则具备支持检出本地模式虚拟桌面的能力，但它们通常会被锁定，且没有足够的本地存储来容纳加密的虚拟桌面镜像。因此，如果某个解决方案中存在要求终端用户处于断开连接状态的使用场景，通常需要为这些终端用户配发厚客户端，以满足 VMware View 本地模式的要求。

除了支持本地模式，厚客户端通常具有非常好的性能，因为它们通常配备超过 2 GB 的内存、多核处理器和中到高性能的本地硬盘。对于一些入门级的瘦客户端，运行多媒体应用程序可能会导致瘦客户端的 CPU 占用达到 100%，因为它难以处理多媒体重定向。多媒体重定向将媒体渲染到终端设备上，这就需要终端设备具备较强的性能。

厚客户端的缺点如下：

• 另一个需要修补、维护并保持合规的工作站

• 可能会在边缘存储数据（因为该设备本身仍然是一个完全功能的桌面）

• 需要额外操作系统的许可证

• 一个不稳定的终端

• 更高的被盗风险（因为该设备本身是一个完全功能的设备）

• 用户需要额外的培训，因为他们在使用虚拟桌面时可能会感到困惑，尤其是在切换到本地操作系统时

通常，在从现有物理桌面环境迁移到虚拟桌面解决方案的过程中，组织会考虑逐步引入瘦客户端或零客户端。这种方法通常适用于那些最近购买了新厚客户端（例如工作站）和/或那些在未来几年内不打算进行更新的组织。然而，通过逐步引入瘦客户端或零客户端，组织仍然需要管理厚客户端的底层操作系统。

除了强制组织管理底层操作系统外，组织还可能（根据其特定的操作系统许可协议）需要为厚客户端上的操作系统购买许可，这还不包括虚拟桌面操作系统的许可。这可能会迅速增加组织所需的许可证数量，并增加虚拟桌面项目的总体资本支出。

最后，厚客户端通常是从可写分区启动的机器。这意味着设备在每次启动时可能会以略有不同的状态启动。瘦客户端或零客户端的稳定性不会出现，因此，厚客户端的维护任务（如重新映像）可能会增加，从而提高每台厚客户端的运营费用。

重新利用厚客户端

重新利用是将厚客户端（例如，安装了 Windows XP 的 Dell OptiPlex 工作站）转换为专用的 VMware View 终端的过程。重新利用通常包括以下步骤：

• 安装精简版操作系统（例如 Windows XP 嵌入式版或 Linux 发行版）

• 在重新利用的厚客户端上安装的附加应用程序较少，除了 VMware View 客户端

• 防止对厚客户端配置的更改

替代重新映像厚客户端为新的、专门构建的映像的方法是使用可启动解决方案。例如，通过创建带有 Linux 桌面操作系统和运行 VMware View Client 所需组件的 Live CD，厚客户端可以直接从 CD 启动（只读）。这确保了每次用户打开设备时都会有统一的体验。新发布的 Linux 版本 VMware View Client 使得重新利用变得更加吸引许多没有资本投资 PCoIP 零客户端的组织。

重新利用厚客户端通常被视为实现零客户端的过渡措施，也是延长老旧桌面硬件使用寿命的一种方式。

瘦客户端

瘦客户端指的是专门构建的设备，这些设备运行精简版操作系统（例如，Microsoft Windows XP Embedded (XPe)、SUSE Linux），旨在为最终用户提供最小化的桌面环境。在这个最小化的桌面环境中，最终用户启动 VMware View Client，并连接到其虚拟桌面。瘦客户端通常具有受保护或过滤写入的系统分区。

以下是一些瘦客户端的例子：

• ClearCube I8520

• Wyse R50

• Dell Latitude Mobile 13

瘦客户端的常见优势如下：

• 它们提供一致的桌面环境。

• 它们允许安装第三方软件（如 VPN 客户端）。

• 它们比厚客户端占用的空间更小。

• 通常，它们消耗的功率比厚客户端少。

由于瘦客户端通常是被锁定的操作系统，并具有写入过滤器（不允许写入系统分区，或仅允许在特定子目录中写入），最终用户在每次启动过程中将拥有一致的体验。这有助于减少与修补、维护和重新映像厚客户端相关的运营成本。

此外，瘦客户端允许安装第三方软件，以创建特定于组织需求的精简操作系统映像。

当前，零客户端不支持虚拟专用网络（VPN）连接，因为 PCoIP 固件中没有内置客户端。然而，VMware View 4.6 引入了通过安全服务器使用 PCoIP 的功能，这是远程连接的首选方法，因为它相较于典型的 VPN 连接提供了更好的最终用户体验。

对于那些希望锁定最终设备、提供一致体验并且需要 VPN 连接的组织，瘦客户端是终端设备的一个可靠选择。

瘦客户端的缺点如下：

• 成本

• 性能

• 升级时可能会导致供应商锁定（例如，Wyse）。

虽然瘦客户机通常在硬件平台上功能较少，规格较低，但对于大多数组织而言，它们的成本通常与厚客户机相当。这部分是因为厚客户机的采购通常伴随着大宗订单，以及由此带来的大幅折扣。此外，由于瘦客户机总体上仍属于低产量业务，制造成本通常高于传统厚客户机。

此外，由于瘦客户机通常试图为终端用户提供最少的功能，以便提供良好的体验（最终能够连接到一个具备足够计算能力以满足用户需求的虚拟桌面），如果瘦客户机的处理器无法处理多媒体重定向（例如），整体体验可能会受到影响。

Teradici PCoIP 驱动的零客户机

零客户机指的是一种内嵌 Teradici PCoIP 芯片的设备，使得设备可以直接启动 VMware View 客户端，而无需底层操作系统。零客户机没有可写的系统分区，也没有硬盘。相反，零客户机是从嵌入设备中的芯片组启动的。

本节特别强调Teradici PCoIP 驱动的设备，因为作者认为市场上那些未采用 PCoIP 模式的零客户机注定会被淘汰。至少，它们可能无法在 VMware 生态系统中获得相同的采用率。

零客户机的一些例子如下：

• 三星 NC240 显示器

• EVGA PD02

• ClearCube I9424

• Wyse P20

零客户机的常见优点如下：

• 安全性

• 配置简便

• 成本

• 供应商诊断管理

• 通常比瘦客户机占用更小的空间

• 通常比瘦客户机消耗更少的电力

零客户机是组织可以利用的最安全的终端设备，因为它们内部没有硬盘。在基于零客户机的解决方案中，不可能有敏感数据存储在终端设备上，因为这些设备无法存储此类数据。

零客户机通常被认为在配置上与瘦客户机不相上下，甚至更容易配置。这是因为零客户机的设置非常少（IP 设置、VMware View 连接服务器及其他一些小设置），其目标是尽快让终端用户访问他们的虚拟桌面。

最后，零客户机通常被视为不仅是最安全的解决方案，而且也是最具性价比的解决方案。这是因为，对于那些希望替换桌面设备的组织，例如，一台配有键盘和鼠标的三星 NC240 通常比瘦客户机便宜得多（后者仍然需要显示器）。对于希望利用现有显示器的组织来说，标准的零客户机（例如，EVGA PD02）可能是市场上最便宜的选择之一。

零客户机的缺点如下：

• 目前，它们不支持客户端内的 VPN

• 它们不支持本地模式

• 目前，它们不提供原生的 Wi-Fi 支持

• 无客户端缓存

对于需要其终端设备建立 VPN 连接以连接到 VMware View 连接服务器环境的组织，零客户端将不适用。因为目前零客户端没有内嵌 VPN 客户端固件，无法建立到远程对等端的安全连接。

应当注意，利用安全服务器的合适 VMware View 解决方案应能消除对 VPN 连接的需求。

此外，零客户端无法支持在本地模式下原生运行的虚拟桌面。目前没有移动设备专用（例如，装在笔记本外壳中的零客户端）零客户端解决方案，因此需要使用本地模式的移动用户可能仍然最好使用传统的厚客户端。

其他客户端

其他客户端可以包括苹果 iPhone、华硕 Transformer（基于 Android 的平板电脑）、苹果 iPad 或戴尔 Streak 等设备。目前最流行的外设是基于平板的终端设备，主要是苹果 iPad 和基于 Android 的平板电脑。

这些其他客户端的缺点在于它们可能不支持本地模式。另外，像苹果 iPad 这样的设备不支持本地模式，这意味着当终端用户处于无网络连接的状态时（例如，在飞机上没有 Wi-Fi），用户将无法访问自己的桌面。

对于将平板作为终端设备的组织，强烈建议为平板提供键盘解决方案。如今，大多数用户是传统键盘和鼠标解决方案的本地用户。平板设备提供了一种新的输入方式，许多用户仍在适应这一方式。尽管用户体验通常很愉快，但尝试输入一封长邮件或执行某些常规工作任务时，可能会显得有些繁琐。

例如，iPad 的 VMware View 客户端支持蓝牙键盘，如 Zagg Mate（www.zagg.com/accessories/logitech-ipad-2-keyboard-case）。

选择合适的设备

以下问卷可用于帮助确定适合特定组织的设备。该问卷基于经验，应该作为实地工作时的基础：

问题	答案	理由
是否为此 VDI 项目购买新设备？	是	以零客户端为主，其他设备/平板电脑为辅。
是否为此 VDI 项目购买新设备？	否	重新利用现有的厚客户端或薄客户端。
安全性是否至关重要？	是	零客户端，因为它们不提供可写硬盘。
该解决方案是否需要支持常规视频会议？	是	调查 Cisco 等公司即将推出的集成 PCoIP 零客户端解决方案。
是否需要智能卡认证？	是	厚客户端、薄客户端或零客户端都可以；避免使用平板电脑。
是否希望最小化占地面积和电缆基础设施？	是	三星集成显示器零客户端，配合第三方 Wi-Fi 解决方案，以及无线键盘和鼠标。它需要一根电缆（电源）从解决方案连接到墙壁。
大多数用户是否将从固定位置连接？	是	零客户端。
大多数用户是否是移动用户或经常出差？	是	厚客户端（笔记本电脑）。

上表仅是一个起点。理想情况下，可以在试点期间测试几种设备，包括厚客户端和零客户端。这将帮助组织了解零客户端如何为他们工作（或在特定情况下可能无法使用）。

一根电缆零客户端解决方案

电缆减少是一个在教育环境或任何必须快速建立和拆解客户端环境的环境中经常讨论的话题。一个典型的物理桌面解决方案包括：

• 工作站电源电缆

• 工作站网络电缆

• 键盘的 USB 电缆

• 鼠标的 USB 电缆

• 视频电缆

• 显示器电源电缆

该解决方案总共需要六根电缆分布在桌面或会议室中。还包括三根电缆（显示器电源、工作站电源和工作站网络），它们需要连接到墙面插座。

以下解决方案仅需一根电缆连接到墙壁，并基于三星的集成 PCoIP 显示器解决方案（NC190 或 NC240）：

• 三星显示器零客户端的电源电缆

• NETGEAR WNCE2001 通用 Wi-Fi 互联网适配器

  • 这使得零客户端能够通过 Wi-Fi 连接到 VDI，而无需将补丁电缆从设备连接到墙面插座

  • WNCE2001 也可以通过 USB 供电（以去除电源电缆的需求）

• 罗技 MK520 无线键盘和鼠标

  • 发射器只占用一个 USB 端口，并提供无线键盘和鼠标

该解决方案仅需要一根电源电缆，适用于需要快速搭建和拆除的环境，如应急响应、培训和教育环境。

总结

VMware View 是一个极其灵活的解决方案，可以支持各种不同的终端设备。这有助于提高 VDI 项目的整体成功率，因为它允许用户在特定的情况或网络连接状态下，携带最适合自己的设备。例如，用户可以简单地携带一台 Apple iPad，并使用 VMware View 客户端连接到他们的企业虚拟桌面（vDesktop），执行一些轻量任务，如内部浏览、文件管理等。当用户回到家庭办公室或工作桌面时，他们可能会使用带有 View 客户端的完整桌面工作；这将使输入更快，例如。

根据本书作者的集体经验，PCoIP 零客户端通常是组织前进的最佳选择，因为它消除了整体 VDI 解决方案中的一个不必要的变量。PCoIP 零客户端既可靠、可预测，又经济实惠且安全。

下一章讨论了如何正确地调整 VMware View 解决方案的规模，这对确保良好的终端用户体验、冗余性和成本效益至关重要。现在，VMware View 的基础工作已经完成，接下来是时候开始设计软件和硬件基础设施了。

第五章：PCoIP 协议

PCoIP 协议由 Teradici 开发，并由 VMware 授权，是专为局域网（LAN）和广域网（WAN）连接的虚拟桌面解决方案设计的协议。PCoIP 是一种内容感知协议，这意味着它具有区分文本和高分辨率图片等内容的算法，并根据实时网络特性进行传输优化。

VMware 自己的测试表明，与 Microsoft 的远程桌面协议（RDP） 相比，PCoIP 能够在常见操作中将显示延迟减少超过 50%（VMware View PCoIP 网络大小指南）。

本章将涵盖以下内容：

• 为什么无损质量很重要

• 各种 PCoIP 网络基础知识

• 多媒体重定向

• Teradici APEX 卸载卡

与其他竞争的 VDI 解决方案中的协议相比，PCoIP 有许多独特的差异化特点；其中一个特点就是 PCoIP 是一种主机渲染技术。主机渲染意味着所有像素都在数据中心渲染，然后简单地广播到终端设备。这意味着终端设备不需要安装任何编解码器。

PCoIP 最常被宣传的特点之一就是该协议能够构建到无损质量。

假设终端用户正在通过延迟连接连接到他们的虚拟桌面，并试图渲染一个网页。该网页既包含高分辨率图形，也包含文本。注意，最初文本非常清晰，而图形则被大幅压缩以节省带宽。

假设用户没有通过浏览其他网页等方式更改显示内容，那么视觉效果将逐渐呈现为感知上的无损质量。这意味着人眼无法分辨显示内容与由 VDI 渲染的原始版本（具有更高像素数）之间的差异。如果用户在更改显示内容之前还有时间，PCoIP 最终会构建到完全无损的质量。

为什么无损质量很重要

为了理解为什么无损表示很重要，让我们用一个例子来说明。Whitney 是一名安全人员，负责筛查进入大楼的包裹。她的组织已经在她的主工作站上实施了 VDI 解决方案。当包裹进入 X 射线机，内容显示在她的显示器上时，根据机构的政策，她有两秒钟的时间来判断是否为威胁。如果 Whitney 的机构使用的解决方案是基于无法保证在终端设备上呈现无损图像的协议，那么她屏幕上的视觉效果可能不完全准确。在这种情况下，PCoIP 提供的无损图像要比使用可能存在显著压缩、且可能无法精确呈现虚拟桌面图像的解决方案和协议更有价值。

另一个对无损图像至关重要的例子是在医疗环境中。例如，如果在医院实施了 VDI，临床医生通过笔记本电脑、Apple iPad 和其他终端设备访问他们的 vDesktop，确保传输的图像无损非常重要。如果没有能够提供无损渲染的解决方案，临床医生可能无法从正电子发射断层扫描（PET）图像中确定是否有某种特定的诊断，例如癌症。

PCoIP 网络基础

为了了解如何为 PCoIP 会话交付调整网络大小，重要的是了解 PCoIP 的一些关键配置和概念。例如，PCoIP 协议增加的开销非常小，标准 1500 字节的以太网数据包只增加 85 字节的开销。

要建立一个 PCoIP 会话，终端设备上必须运行支持 PCoIP 的客户端，且目标必须是支持 PCoIP 的主机。

支持 PCoIP 的客户端包括：

• 适用于 64 位 Windows 的 VMware View 客户端

• 适用于 Linux 的 VMware View 客户端

• 适用于 Mac 的 VMware View 客户端

• 适用于 Apple iPad 的 VMware View 客户端

• 适用于 Android 的 VMware View 客户端

支持 PCoIP 的主机包括：

• 运行 VMware View 代理软件的 Windows 桌面操作系统（物理或虚拟）

• 具有 PCoIP 硬件主机卡（物理）的 Windows 桌面操作系统

虽然可以使用 PCoIP 连接到基于 Windows 的服务器操作系统，但目前 VMware 不支持该功能。不过，以下 URL 提供了启用此解决方案的说明：

myvirtualcloud.net/?p=2811。

两种 PCoIP 连接类型

有两种类型的 PCoIP 连接——软连接和硬连接。

当连接到 VMware View vDesktops 时，使用软 PCoIP。由于 vDesktop 无法安装 PCoIP 主机卡，因此它使用 PCoIP 的软实现，称为PCoIP 软件主机。软 PCoIP 可以容忍最高 250 毫秒的往返延迟，并能够以每秒 30 帧（FPS）显示视频。

硬 PCoIP 用于连接到带有 Teradici PCoIP 主机卡的物理设备。由于连接终止在 PCoIP 主机卡设备上，因此称为硬 PCoIP 主机。硬 PCoIP 可以容忍最高 150 毫秒的往返延迟，并能够以每秒 60 帧（FPS）显示视频。

PCoIP 类型	往返延迟容忍度	视频的最大帧率
软 PCoIP	250	30
硬 PCoIP	150	60

注意

测试网络延迟时，使用ping l 1400 <destination_ip>，其中<destination_ip>是远程位置的 IP 地址。l 1400开关强制 ping 测试使用 1400 字节的包大小，这是 Teradici 推荐用于测试 PCoIP 网络延迟的大小。

无论是软 PCoIP 还是硬 PCoIP，都利用了本地光标技术，这确保了即使在高延迟情况下，最终用户的光标功能仍然良好。

多媒体重定向

多媒体重定向（MMR）是将媒体文件从 PCoIP 主机（通常是 VMware View vDesktop）重定向到终端设备的过程。更常见的方法是主机视频解码，这是 VMware View 解决方案中的常规做法。

只有当终端设备是 x86 客户端时，MMR 才可用。

此外，x86 终端设备还必须安装适当的编解码器，以支持重定向的媒体文件类型。MMR 是一种最初在多年以前推出的技术，旨在支持终端服务。多年前，瘦客户端的受欢迎程度逐渐上升，主要是通过像 Wyse 这样的公司的努力。如第四章中所学，终端设备，瘦客户端通常配有经过锁定的操作系统版本，例如 Windows XPe。

MMR 通过 PCoIP 支持的媒体文件类型包括：

• MPEG-1

• MPEG-2

• MPEG-4

• WMA

• MP3

• AC3

• WMV

PCoIP MMR 不支持重定向 Adobe Flash 或 Apple QuickTime。通过将媒体渲染任务交由一个或多个终端设备的 CPU 来完成，MMR 在降低主机 CPU 负载方面具有优势，因为不再由服务器 CPU 渲染媒体内容。此外，MMR 还可能减少网络带宽需求，因为已经渲染的视觉数据不需要发送到终端设备，而是发送待渲染的媒体文件。

MMR 有许多缺点。例如，要使用 MMR，必须使用 x86 终端设备。如本书前面所讨论，使用 PCoIP 零客户端在 VMware View 解决方案中有许多优势（例如价格和安全性）。通过在解决方案中使用 MMR，瘦客户端或厚客户端成为唯一可用的选项。

对于需要支持视频编辑器或视频编辑软件的解决方案，硬 PCoIP 解决方案很可能是最佳（也是唯一）可行的解决方案。尽管 PCoIP 协议自初次发布以来已做出显著改进，但基于硬件的 PCoIP 解决方案仍是最佳选择。

注意

PCoIP 是一种独特的桌面交付协议，不仅可以通过软件（软）提供，还能够利用硬件优势，例如主机卡。

以下表格摘自 Teradici 虚拟桌面主机演示文稿：

描述	MMR	主机视频解码
服务器 CPU 负载	中等	中到高
支持任何视频编码	否	是
支持 PCoIP 零客户端	否	是
需要应用程序和补丁管理	是	否
需要编解码器和补丁管理	是	否
WAN 性能	差	好
操作低于原生视频比特率	视频卡顿	平滑播放

随着服务器 CPU 功率和密度的增加，主机视频解码将变得不那么令人担忧，因为随着技术进步，给定物理服务器的可用处理能力也在增加。

MMR 完美风暴

在 VMware View 解决方案中，使用 MMR 的唯一合理原因之一是当需要频繁使用视频并且有特定的编解码器要求时。例如，如果一个公关公司频繁观看客户的视频，并且这些视频采用特定的编解码器（例如，使用 DivX 编解码器的 音频视频交错（AVI） 文件），那么将视频传输到已安装 DivX 编解码器的瘦客户端或厚客户端可能会优于仅依赖 PCoIP 的解决方案。

大多数组织不再依赖诸如 AVI（带 DivX 编解码器）的文件，而更多地依赖 Adobe Flash 和 Apple QuickTime，这些在主机视频解码下能获得最佳表现。

Teradici APEX 卸载卡

2011 年，Teradici 宣布推出 Teradici APEX 2800 卸载卡。APEX 卡是一个 PCIe 卡，用于将 PCoIP 协议编码从物理服务器的 CPU（在虚拟桌面中抽象为 vCPU）卸载到卸载卡。这种卸载仅限于视频，并不涉及 PCoIP 的音频通道。APEX 卸载卡是与 VMware View 集成的解决方案。

正如本书早些时候提到的，VMware View 能够利用硬件解决方案（例如，PCoIP 零客户端和 PCoIP 主机卡）为市场提供独特的能力。

在许多 VMware View 解决方案中，如果不是大多数，APEX 卸载卡可以有效地增加在物理服务器上运行的虚拟桌面数量。提高每核心的用户密度应显著降低 VMware View 解决方案的整体成本，即使将卸载卡的价格算在内。

Teradici APEX 卸载卡解决方案有三个组成部分：

1. Teradici APEX 卸载卡本身

2. ESXi 的 APEX 驱动程序

3. Windows vDesktop 的 APEX 驱动程序

如果没有正确安装和配置这三种组件，硬件卸载将无法实现。以下图示展示了支持 PCoIP 卸载所需的 ESXi 驱动程序和 Windows 驱动程序：

硬件加速的 PCoIP 协议编码用于增加每核心的用户数量。即使在那些内存资源可能比 CPU 更受限的 VMware View 解决方案中（例如，内存管理差的 Java 应用程序较多的环境），使用 APEX 卡仍然可以带来显著的好处。作为一般经验法则，其好处如下：

• 任务工作负载 = 每核心 1.15 倍用户

• 知识工作者 = 每核心 1.5 倍用户

• 视频工作负载 = 每核心 1.75 倍用户

例如，如果一个没有使用 APEX 卡的 VMware View 设计每个 CPU 核心可以支持 10 个知识工作者，那么使用 APEX 卡后每个 CPU 大约可以支持 15 个知识工作者。下图为展示 Windows 7 桌面使用 PCoIP 编码和不使用编码的插图：

在前面的插图中，Windows 7 桌面的显示是使用 VMware View Agent 进行编码的，完全通过软件和虚拟桌面的虚拟 CPU 完成。编码后的显示器随后会被安全地发送到正在使用的终端设备。使用 PCoIP 时，只有编码后的显示器被发送到设备，而不包含桌面本身的任何实际数据。下图为展示使用 PCoIP 卸载编码的 Windows 7 桌面编码插图：

在前面的插图中，Windows 7 桌面的显示是使用 APEX 卸载卡进行编码的。编码后的显示器随后会被安全地发送到正在使用的终端设备。卸载卡并不执行渲染操作，它仅执行编码。渲染操作由 VMware View 虚拟图形驱动程序或虚拟 GPU 完成。

当前版本的 APEX 卸载卡可以支持最多同时对 64 个活跃显示器进行编码。这并不意味着物理服务器不能拥有超过 64 个显示器的虚拟桌面，而是指在任一时刻只能对 64 个显示器进行卸载。

卸载过程

APEX 2800 ESXi 驱动程序监控所有虚拟桌面是否有图像活动，无论虚拟桌面是否使用硬件卸载。APEX 解决方案使用多个因素来确定虚拟桌面的显示是否应卸载。具体如下：

• 资格：该虚拟桌面是否有资格将其显示卸载？

• 图像活动：虚拟桌面的图像活动是否超过最低阈值？

• 优先级：该虚拟桌面当前是否在其同类中具有优先级？

下图展示了 Teradici PCoIP APEX 卸载决策树：

软件和硬件编码之间的切换是一个无缝的过程。在当前版本的解决方案中，显示器的左上角会出现一个小红点（可以禁用），以便让最终用户知道正在使用硬件编码。这通常只应在测试和试点阶段使用，而不是在实际的生产环境中。

定义卸载层级

Teradici APEX 卸载卡将优先级作为确定虚拟桌面的显示是否卸载到硬件卡的因素之一。每个桌面池的优先级在 VMware View Admin 控制台中的“策略”下定义。卸载优先级列为 PCoIP 硬件加速优先级。共有五个优先级设置，具体如下：

• 最低

• 较低

• 中等（默认）

• 较高

• 最高

在许多设计中，只会使用一个或两个卸载优先级设置。例如，一个设计可能会将终端用户群体与高管团队分开。高管们可能会获得“更高”优先级设置，而其他所有人则配置为“中等”。

如果某一解决方案定义了多个优先级组，最佳实践是仅使用“最高”和“最低”优先级设置。通过将“最高”设置为可用选项，如果有需要，桌面池可以在紧急情况下立即获得优先权，优先级高于其他所有人。

设计考虑事项

APEX 卸载卡的实现相当简单；驱动程序的安装文档齐全，并且从 View 管理控制台启用和配置卸载也非常简便。使用 PCoIP 硬件卸载时，主要需要考虑的是它在支持给定桌面池的集群中的能力。

如果桌面池所在的 vCenter 集群中有些主机安装了 APEX 卡，有些则没有，那么 vMotion（无论是手动触发还是由 DRS 触发）可能需要断开并重新连接，以便 PCoIP 能够启动。以下图示展示了一个没有 APEX 卡的集群和一个有 APEX 卡的集群：

由于 vMotion 任务可能会阻止 PCoIP 卸载的启动，建议在给定集群的所有主机上使用 Teradici APEX 卸载卡。这并不是说在给定的 VMware View 解决方案中所有主机都需要 Teradici APEX 卡，但如果需要使用该卡，它应当在集群范围内使用。

摘要

正如本章所述，Teradici PCoIP 协议是将桌面传输到终端设备的技术。无论终端设备是 Apple iPad 还是 IBM 笔记本电脑，PCoIP 利用其智能确保提供最佳的用户体验。理解 Teradici PCoIP 协议的工作原理，对于理解给定 VDI 解决方案的网络要求至关重要。在下一章中，将讨论如何进行网络容量规划，其中包括 PCoIP 相关的考虑因素。对于任何设计 VMware View 解决方案的人来说，了解 Teradici PCoIP 协议的基本知识是必不可少的，否则，网络可能会成为限制一个设计良好的解决方案的瓶颈。

第六章：VDI 大小配置

大小配置是确定 VDI 解决方案中每个组件所需计算能力的过程，理想情况下应基于评估阶段收集的度量数据。在大多数情况下，挑战不在于处理平均日常 VDI 工作负载，而在于处理高峰负载。VDI 环境中的峰值负载通常持续时间较短，可能无法通过传统技术（如 VMware 分布式资源调度器（DRS） 或手动 vMotion 平衡）来缓解。

本书前几章讨论的组件，例如 VMware View 连接服务器，与必须进行配置大小调整的硬件组件相比，其大小调整的考虑因素较少。原因在于，软件组件主要执行相对轻量的工作，仅仅是代理连接或执行配置任务，这些任务可能不会持续进行。

以下图表展示了 VDI 解决方案的大小配置层次：

例如，拥有适当大小和性能的数据库基础设施非常重要，因为数据库响应时间缓慢可能会影响 View Composer 任务以及 vCenter 中的任务。此外，确保 View 连接服务器具有足够的虚拟或物理资源，如 CPU 和内存，也非常重要。然而，本章的主要关注点是 VDI 物理组件的大小配置。

要正确理解如何调整 VDI 的大小，重要的是在评估阶段收集正确的度量数据，这部分内容在第二章，解决方案方法论 中有详细介绍。此类度量数据包括以下内容：

• 同时在线的用户数量

• 用户类别以及每个用户类别所需的 vCPU 数量、内存等

• 网络需求

• USB 重定向频率

本章将重点讨论从大小调整角度看待的以下组件，而不一定从冗余角度进行分析。本章属于 n 中的 n + 1。具体组件包括：

• VMware View 连接服务器

• VMware vCenter 服务器

• 服务器硬件

• 网络基础设施

注意事项

存储大小配置在第八章，存储大小配置 中有详细介绍。

配置不当的 VDI 可能会遇到以下问题：

• 登录缓慢

• 较差的 PCoIP 性能

• 无法启动 vDesktops，因为达到了 vCenter 的最大限制

• 无法登录 VDI

• 认证错误

• 随机故障

网络考虑事项

在远程场景下，理解最终用户与 VDI 之间的网络连接相当显而易见（例如，用户在家工作，地理位置远离 VDI），但在本地场景下则不太明显。虽然本地场景可能不会明显导致 VDI 架构师考虑网络规模问题，但即使所有组件都位于局域网（LAN）上，分析和调整 VDI 解决方案的网络组件仍然至关重要。这是确保最终用户体验尽可能积极的唯一途径。

网络规模调整

一般来说，一个典型的任务工作者需要大约 250 Kbps 的网络吞吐量才能获得良好的最终用户体验。根据行业普遍接受的术语，任务工作者是指具有以下特点的用户：

• 他使用典型的办公应用程序或终端窗口

• 他不需要多媒体

• 他不需要 3D 图形

• 他不需要双向音频

然而，任务工作者在使用 USB 外设时，可能会产生显著的网络带宽需求。如果任务工作者需要 USB 外设来完成工作，那么在全面实施之前，必须对具体 USB 外设的使用进行网络分析。

以下是消耗品（Kbps）列表：

• PCoIP 基线 = 250 Kbps

• PCoIP 突发余量 = 500 Kbps

• 多媒体视频 = 1,024 Kbps

• 3D 图形 = 10,240 Kbps

• 480p 视频 = 1,024 Kbps

• 720p 视频 = 4,096 Kbps

• 1080p 视频 = 6,144 Kbps

• 双向音频 = 500 Kbps

• USB 外设 = 500 Kbps

• 立体声音频 = 500 Kbps

• CD 质量音频 = 2,048 Kbps

网络清单请参考techsupport.teradici.com/ics/support/default.asp?deptID=15164。但在此之前，您需要在此网站创建一个账户：techsupport.teradici.com。

其他权重如下：

• 缓冲区 = 80%

• 带宽偏移 = 105%

提供可接受性能所需的最小带宽由用户会话的活动和要求决定。以下是不同用户类型所需最小带宽的一些基准数字：

描述	Kbps
不带多媒体的低端办公人员	250
不带多媒体的高端办公人员	315
带多媒体的低端办公人员	340
带多媒体的高端办公人员	375

下图展示了给定网络连接的带宽配置示意图：

在大多数环境中，唯一应该比 PCoIP 拥有更高网络优先级的网络流量是与 IP 语音（VoIP） 通信相关的流量。给 PCoIP 设置比 VoIP 更高的优先级可能会导致某些网络不合适的环境中出现差的质量或连接丢失。因此，建议给 VoIP 流量分配更高的优先级（大约占总连接的 20%），给 PCoIP 流量第二高的优先级，并适当分类其余流量。

网络连接特性

Teradici 在处理高延迟和/或低带宽场景时，显著提升了 PCoIP 协议的能力。Teradici 的 PCoIP 协议是一种专门为提供原生桌面体验而设计的协议。为了提供最佳的最终用户体验，PCoIP 会尽可能多地使用可用带宽，直到能够提供理想的用户体验为止。PCoIP 是动态的，随着可用带宽的变化，PCoIP 尝试消耗的带宽量也会相应变化。PCoIP 最初使用 传输控制协议（TCP） 来建立连接，然后使用 用户数据报协议（UDP） 来传输桌面体验。

PCoIP 还具有两个主要设置，应该了解它们，分别是 PCoIP 最大带宽和 PCoIP 带宽底线。

PCoIP 最大带宽是指某个 PCoIP 会话允许消耗的最大带宽量。配置此设置可以确保最终用户永远不会超过某个带宽限制。此外，正确配置 PCoIP 最大带宽可以为解决方案提供一种保障。如果没有限制每个会话的带宽消耗（即使最大带宽配置得非常宽松），也可能出现 PCoIP 会话过度消耗可用带宽的情况，从而对共享同一网络连接的其他用户产生负面影响。

以下图表展示了带宽底线和带宽最大值：

PCoIP 带宽底线是 PCoIP 用于控制数据流的带宽最低阈值。以下是一个示例：

一家组织有 500 名任务工作人员，想了解为他们的 VMware View 解决方案提供多大网络带宽。VDI 用户仅使用基本的办公应用程序，并不需要其他功能。

平均带宽消耗 = (总用户数 * 250 Kbps) + (特殊需求 * 带宽惩罚) * 带宽外部 * 缓冲区

因此，将前面示例中给定的值代入公式，我们得到以下输出：

平均带宽消耗 = (500 * 250 Kbps) + 0 * 80% = 100,000 KBps（约为 97 Mbps）

DHCP 考虑事项

尽管可以拼凑出一个使用静态 互联网协议（IP） 地址的 VDI 解决方案，但强烈不推荐这样做。由于 VDI 的潜在波动性以及管理的方便性，动态主机配置协议（DHCP） 是管理 vDesktops IP 地址分配的首选方法。使用 DHCP 时，vDesktops 并不拥有特定的 IP 地址，而是从 DHCP 服务器租用它。

单一的 DHCP 范围由特定子网上的 IP 地址池组成。一个 DHCP 超范围允许 DHCP 服务器将多个范围中的 IP 地址分发到单一物理网络上的设备。适当的子网划分可以确保在特定范围内有足够的 IP 租约来满足需要 IP 地址的终端设备数量。下图展示了 DHCP 工作流程：

DHCP 租约分配的工作流程如下：

1. 客户端在其物理子网中广播 DHCPDISCOVER 消息。

2. 子网上可用的 DHCP 服务器通过发送 DHCPOFFER 包向客户端回复一个 IP 地址。

3. 客户端通过 DHCPREQUEST 消息回复，以指示他/她接受来自哪个 DHCP 服务器的 DHCPOFFER 包。其他 DHCP 服务器会撤回它们的 DHCP 租约提议。

4. DHCP 服务器在客户端的 DHCPREQUEST 消息中回复一个 DHCPACK 包，以确认租约交易的完成。

当一个已经有有效租约到期窗口内的地址的客户端重启或在关闭后启动时，发生 DHCP 重新分配。它重新启动时，会联系之前通过 DHCPACK 包确认的 DHCP 服务器，以验证租约并获取任何必要的参数。

在原始租约分配后经过一段时间（T1），客户端会尝试续租。如果客户端无法成功续租，则会进入重新绑定阶段（从 T2 开始）。在重新绑定阶段，它会尝试从任何可用的 DHCP 服务器获取租约。

在前面的图中，T[1] 被定义为租约时长的 50%，T[2] 被定义为租约时长的 90%。

假设本示例的租约时长为 120 分钟（两个小时）。

vDesktop 启动并成功从 DHCP_SERVER_01 获得了一个 120 分钟的 DHCP 租约。在 T1 时（120 分钟的一半，即 60 分钟），vDesktop 尝试从 DHCP_SERVER_01 续租。在续租期间，vDesktop 成功续租了 DHCP 租约。由于续租成功，租约时钟会被重置为完整的 120 分钟。

这次 vDesktop 在续租期间未成功，进入了重新绑定阶段。vDesktop 成功从 DHCP_SERVER_03 获得了一个新的 DHCP 租约，租期为 120 分钟。

在大多数 VDI 场景中，1 小时的 DHCP 租约时间已足够。通常，这比大多数组织默认范围内的 DHCP 租约时间要短得多。

如果桌面池设置为在用户注销后删除虚拟桌面，则可能会导致显著的 DHCP 租约波动，并应考虑设置一个非常短的 DHCP 租约时间（具体取决于虚拟桌面删除的频率）。

VMware View Composer 任务（如重新组合和刷新）应在整个过程中保持相同的 MAC 地址，因为与 vNIC 相关的 VMX 设置不应被更改。因此，在启动过程中，原始的租约将尝试重新分配。

虚拟交换机注意事项

设计 VDI 环境中的虚拟交换机是另一个可能对不熟悉大规模虚拟基础设施或习惯于设计具有高虚拟机波动性的解决方案的人来说具有挑战性的组成部分。

上面的图示以高层次展示了 VDI 环境中的网络组件。未显示的是由虚拟化管理程序（hypervisor）执行的抽象（位于物理交换机和虚拟交换机之间）。

创建标准 vSwitch 时，默认有 120 个端口。此参数是在内核（虚拟化管理程序）层定义的，任何更改标准交换机端口数量的操作都需要重启物理主机。

当创建一个分布式 vSwitch（也称为dvSwitch）时，默认有 128 个端口。此参数可以动态更改，并且无需重启物理主机即可更改端口数量（从默认的 128 开始）。

标准交换机与分布式交换机

标准 vSwitch 不受 VMware vCenter Server 丧失的影响，最好用于像服务控制台、vMotion 和存储连接等功能，因为这些都可以通过命令行轻松管理。然而，在利用多个虚拟局域网（VLAN）的大型 VDI 解决方案中，数十台或数百台物理主机的 dvSwitch 帮助大大简化了虚拟基础设施中的虚拟网络管理。

VMware vSphere 主机会在 VMware vCenter Server 无法使用时，保持一个 dvSwitch、dvPortGroup 和 dvPort 信息的本地缓存。该本地缓存配置副本是只读的，管理员无法对其进行操作。

端口绑定

端口绑定是将特定端口（也称为dvPort）分配给特定虚拟机上的特定网络接口控制器（NIC）的过程。可以将这种分配类比为将一根补丁电缆的一端插入物理桌面上的 NIC，另一端插入可用的交换机。dvPorts 决定了虚拟机的网络流量如何映射到特定的分布式端口组或dvPortGroup。

dvSwitch 使用三种类型的端口绑定，具体如下：

• 静态绑定

• 动态绑定

• 临时绑定

静态绑定

当向虚拟机添加 vNIC 时，静态绑定会在 dvSwitch 的 dvPortGroup 上分配一个可用端口。例如，如果 VM009 是已关机的 Windows 2008 虚拟机，并且管理员进入“编辑设置”并在 dvPortGroup VLAN 71 上添加一个 NIC，则会分配 VLAN 71 dvPortGroup 上的一个 dvPort 给该 NIC，前提是有可用的 dvPort。无论虚拟机 VM009 是否已开启，它仍会被分配一个 dvPort，并且该 dvPort 对其他虚拟机不可用。

仅当虚拟机已从 dvPortGroup 中移除时，分配的 dvPort 才会释放。只能通过 vCenter Server 将使用静态绑定的虚拟机连接到 dvPortGroup。

优势： 静态绑定的优势在于，即使 vCenter Server 不可用，虚拟机也可以启动。此外，在 vMotion 事件和虚拟机电源周期后仍然保留网络统计信息。

劣势： 静态绑定的劣势在于，dvPortGroup 无法过度使用。在使用非持久桌面的易失性 VDI 环境中，这可能会导致 dvPortGroup 上的可用 dvPort 不足。在利用 VMware View Composer 的环境中，强烈不建议使用静态绑定。

动态绑定

当虚拟机开启并且其 NIC 处于连接状态时，动态绑定会在 dvPortGroup 上分配一个可用的 dvPort。例如，如果 VM009 是 Windows 2008 虚拟机，并且管理员进入“编辑设置”并在 dvPortGroup VLAN 71 上添加一个 NIC，则 VLAN 71 dvPortGroup 上的 dvPort 尚未分配。一旦虚拟机 VM009 开启，它将在 dvPortGroup 上分配一个 dvPort，该特定 dvPort 将对其他虚拟机不可用。

当虚拟机已经关机或者 NIC 处于断开状态时，分配的 dvPort 会被释放。只能通过 vCenter Server 将使用动态绑定的虚拟机连接到 dvPortGroup。

动态绑定适用于虚拟机数量超过给定 dvPortGroup 上可用 dvPort 的环境；但是，已开启的虚拟机数量不会超过给定 dvPortGroup 上的可用 dvPort 数量。

优势： 动态绑定的优势在于，由于虚拟机在开启之前不占用 dvPort，因此可以在给定的 dvPortGroup 上过度使用端口。此外，在 vMotion 事件后仍然保留网络统计信息。

缺点： 动态绑定的缺点在于，虚拟机直到启动后才会分配 dvPort，因此它必须由 vCenter Server 启动。如果 vCenter Server 不可用，虚拟机将无法启动。由于 dvPort 是在启动时分配的，因此在虚拟机电源循环后，网络统计信息不会被保留。

短暂绑定

短暂绑定在虚拟机启动并且其 NIC 处于连接状态时，会在 dvPortGroup 上创建并分配一个 dvPort。例如，如果 VM009 是一个 Windows 2008 虚拟机，管理员进入编辑设置并添加一个在 dvPortGroup VLAN 71 上的 NIC，那么 VLAN71 dvPortGroup 尚未分配 dvPort。一旦虚拟机 VM009 启动，首先会创建一个 dvPort，并将其分配到 dvPortGroup 上，这个特定的 dvPort 将无法被其他虚拟机使用。

一旦虚拟机关闭或其 NIC 处于断开连接状态，分配的 dvPort 将被释放。使用短暂绑定的虚拟机可以通过 vCenter Server 或从 ESX/ESXi 连接到 dvPortGroup。因此，即使 vCenter Server 不可用，虚拟机的网络连接仍然可以被管理。

当虚拟机进行 vMotion 时，原有的 dvPort 会从源 dvPortGroup 中删除，并且在目标 dvPortGroup 上创建一个新的 dvPort。

短暂绑定在高波动性的环境中非常有用，例如非持久的 VDI 解决方案，在这些环境中，虚拟机经常被创建和删除。dvPortGroup 上的端口数量由 dvSwitch 上可用的端口数量定义和限制。

优点： 短暂绑定的优点在于，虚拟机在启动之前不会占用 dvPort，因此可以在给定的 dvPortGroup 上进行端口过度分配。

缺点： 网络统计信息在虚拟机电源循环后或 vMotion 事件发生后不会被保留，因为 dvPort 是在启动时或 vMotion 时创建并分配的。

端口绑定与 VMware View Composer

对于利用 View Composer 的 VDI 解决方案，重要的是要认识到，诸如重组（Recompose）、负载均衡（Rebalance）和刷新（Refresh）等任务会尝试使用已经分配给副本镜像的端口。

因此，如果要使用 VMware View Composer，建议使用动态绑定或短暂绑定（推荐）。

计算考虑事项

在大多数 VDI 项目中，计算通常不是失败的领域，但在实施最终设计之前，了解组织的计算需求仍然非常重要。可能会导致计算方面预料之外故障的程序如下：

• Dragon Medical/Dragon Naturally Speaking

• Defense Connect Online

• AutoCAD

• Eclipse IDE

对于基于 Windows XP 的 VDI 解决方案，一个 vCPU 很可能能满足大多数基本计算需求。然而，对于基于 Windows Vista 或更重要的 Windows 7 的 VDI 解决方案，可能需要两个 vCPU，以确保提供良好的最终用户体验。

为了最准确地计算 CPU 需求，应对环境进行适当评估。这将帮助识别潜在的陷阱，比如之前列出的一些应用程序问题，以便在部署前处理。

虽然基于 AMD 和 Intel 的 x86 服务器都能满足 VDI 解决方案的需求，但在大规模和/或高需求环境中，基于 Intel 的解决方案在密度（每个核心的 vDesktop 数量）方面始终优于基于 AMD 的解决方案。

在 VDI 解决方案中，还可能由于杀毒扫描、调优不当的应用程序、单线程进程、增加的视觉效果、以及视频或音频处理的影响而导致不必要的 CPU 负载。

上图展示了一个 6 核处理器的示例。作为一个安全的基准，设计时每个核心使用 10 个 vDesktop。对于基本任务工作者，这个数字可以显著更高，且有多个参考架构验证了每个核心 15 到 18 个 vDesktop 的情况。使用 Teradici APEX 卸载卡也可能增加每个核心的用户密度。

继续使用每个核心 10 个 vDesktop 作为基准，并假设服务器有 2 个处理器（每个 6 核），那么每台物理服务器的总核心数为 12 核。每台服务器有 12 个核心，每个核心 10 个用户，那么每台物理服务器的用户数为 120 个（每个处理器 6 核 * 每台服务器 2 个处理器 * 每个核心 10 个用户）。如果每个 vDesktop 使用 1.5 GB RAM（这是对 64 位 Windows 7 的最低建议配置），那么同一台物理服务器需要 180 GB 的内存（1.5 GB * 120 个用户）。这是一个相对的内存最佳点，因为大多数服务器的出厂配置内存为 256 GB。

以下两张表格摘自 Configuration Maximums, VMware vSphere 5.0 指南，链接在这里。这些表格解释了计算的最大值：

主机 CPU 最大值	最大值
每个主机的逻辑 CPU 数量	160
虚拟机最大值	最大值
---	---
每个主机的虚拟机数量	512
每个主机的虚拟 CPU 数量	2048
每个核心的虚拟 CPU 数量	25

根据前面的信息，我们知道，选择每个处理器有显著更多核心（例如每个处理器 24 核或 32 核）的处理器并不会帮助提高某个物理服务器上 vDesktop 的密度。

以下表格解释了内存的最大值：

主机内存最大值	最大值
每个主机的 RAM	2 TB
分配给服务控制台的最大 RAM	800 MB
分配给服务控制台的最小内存	272 MB

增加密度未能实现（或更准确地说，未能最大化）的原因，部分是由于内存限制，也由于现有的 VMware vSphere 限制。假设为了论证的目的，选择了一个 32 核物理服务器作为给定 VDI 解决方案的标准，并且它配备了最大支持的 2 TB 内存。

使用保守的基准，即每个核心 10 个虚拟桌面，这将产生每个主机 320 个虚拟桌面，需要 640 GB 内存。

以下表格说明了集群最大值：

集群最大值	最大
每个集群的主机数	32
每个集群的虚拟机数	3,000
每个主机的虚拟机数	512

将每个主机上的 320 个虚拟桌面与 VMware 定义的集群最大值进行比较时，每个主机的虚拟机数量将达到最大值。

进一步分析来自配置最大值，VMware vSphere指南中描述的内容：“如果超过一个配置选项（例如虚拟机数量、LUN 数量、vDS 端口数量等）达到其最大限制，主机上运行的一些进程可能会耗尽内存。”因此，建议尽可能避免达到配置最大值。

与 VDI 设计的所有部分一样，重要的是尽可能利用真实世界的度量数据，了解虚拟桌面将如何使用，并了解它们如何影响底层的物理基础设施。

根据前述计算，建议节省资本支出，不购买高核心数的处理器，而应将资金集中在其他地方。在大多数环境中，六核、八核或十二核处理器在性能方面已足够，并且能够确保不达到 vSphere 的最大限制。

使用 VMware vSphere 最大值

可以强烈主张，尽管 VMware vSphere 迄今为止是业界领先的服务器虚拟化平台，其当前的最大值可能在超大规模 VDI 环境中存在限制。以下是来自配置最大值，VMware vSphere指南中与 VMware View 解决方案最相关的 vCenter 最大值列表：

vCenter Server 的可扩展性	最大
每个 vCenter Server 上的主机数	1,000
每个 vCenter Server 上的虚拟机开机数	10,000
每个 vCenter Server 注册的虚拟机数	15,000
链接的 vCenter Servers（Pod）	10
链接的 vCenter Servers 中的主机数	3,000
链接的 vCenter Servers 中的虚拟机开机数	30,000
在链接的 vCenter Servers 中注册的虚拟机数	50,000

上述限制将在下一部分通过一个解决方案示例进行分析。

解决方案示例——25,000 个 VMware View 座席

一位 VDI 架构师已被公司聘请，负责为单栋建筑中的 25,000 名任务型员工设计解决方案。在这种情况下，将提供网络和存储，并满足 VDI 解决方案的必要要求；因此，重点是物理服务器规格和 VMware vSphere 及 VMware View 环境的逻辑设计。

公司正在寻找以下信息：

• 物料清单 (BOM) 用于物理服务器

• vSphere 基础设施的逻辑设计

• View 基础设施的逻辑设计

通过快速查看需求，架构师已确定以下内容：

• 每个 vCenter 服务器的开机虚拟机将超出限制（限制为 10,000）

• 每个 vCenter 服务器注册的虚拟机将超出限制（限制为 15,000）

• 链接的 vCenter 服务器中的开机虚拟机将不会超出限制（限制为 30,000）

• 在链接的 vCenter 服务器中注册的虚拟机将不会超出限制（限制为 50,000）

• 每个 vCenter 服务器的最大主机数不会超出限制（限制为 1,000）

• 每个主机的最大虚拟机数量不会超过限制（限制为 320）

解决方案设计 — 物理服务器要求

为了支持运行 Windows 7 vDesktops 的 25,000 名任务型员工，必须确定物理服务器的大小。通过初步测试，每个核心 10 个 vDesktops 是一个保守估计。由于 4 核处理器正在逐步淘汰，选择了 6 核处理器，因为它们在价格和可用性方面更合适。因此，每个物理主机配备 2 个 6 核处理器，总计每个主机 12 个核心。使用每个核心 10 个 vDesktops 和每个主机 12 个核心，得出每个主机 120 个 vDesktops。每个 vDesktop 使用 1.5 GB 内存环境，需要 180 GB 的 RAM 来支持 vDesktops。通过为服务控制台分配最大支持的 800 MB RAM，总共需要 181 GB 的 RAM。因此，配备 192 GB RAM 的服务器将很好地支持该环境。此外，以下是 vNetwork 最大值：

vNetwork 标准 & 分布式交换机	最大值
每个主机的总虚拟网络端口数量	4,096
每个主机的最大活动端口	1,016
每个 vCenter 的分布式交换机数量	32

根据前述最大值，采用了以下物理主机设计：

描述	值
每个处理器的核心数	6
每个主机的处理器	2
每个主机的网卡数量	8
每个主机的内存（GB）	192
每个核心的约 vDesktops 数量	10
每个主机的约 vDesktops 数量	120
标准 vSwitches	2
分布式 vSwitches	1

网络配置如下：

前述图表展示了两个 vNetwork 标准交换机和一个 vNetwork 分布式交换机。第一个标准 vSwitch，vS1，用于服务控制台和 vMotion。第二个标准 vSwitch，vS2，用于基于网络的存储。唯一的分布式 vSwitch，vD1，用于虚拟机。

解决方案设计 — Pod 概念

Pod 的概念是为架构师提供一种创建构建模块的方法，以简化大规模环境设计的可扩展性。它还为解决方案架构提供了一个概念框架。

VMware View Pod 的主要组成部分如下：

• 物理网络： 包括支持 VDI 所需的交换机、VLAN、网络策略以及其他网络基础设施。

• vCenter 块： 包括主机、vCenter 集群设计、vCenter 链接模式配置等。

• View 连接服务器池： 包括 View 连接服务器和（如果适用）View 安全服务器。

这种 Pod 的概念可以通过以下架构类型来实现：

• 传统架构

• 模块化形式的传统架构

• 融合虚拟化设备

传统架构类型涉及使用服务器（机架式或刀片服务器）、网络交换机、存储网络交换机（如果适用）和存储阵列。传统架构方法通常足够满足初始构建需求，但可能无法提供其他方法的扩展能力。以下图示展示了一个典型的传统架构方法，其中存在不成比例的资源：

例如，使用前面的图示，可能拥有足够的计算、网络和存储资源来支持 400 个 VMware View 用户的初始部署。在这个例子中，存储容量过剩。

以下图示展示了典型传统架构扩展挑战的插图：

当组织决定添加 500 个 VMware View 用户时，遇到了问题。在第一阶段的部署中，存储容量过剩。然而，为了以模块化的方式添加容量，计算和网络仍然需要额外的存储模块。因此，每次添加都会产生一定程度的冗余，这由于架构效率低下导致每个虚拟桌面的成本上升。

组织可能不愿意接受这些低效，所以它会在每一步重新设计需求。为 VDI 解决方案的每个额外阶段设计扩展也会通过增加复杂性和人力成本推高总成本。

此外，每次扩展阶段重新架构时，错误的发生概率会更大。

传统模块化架构类型涉及使用服务器（机架式或刀片服务器）、网络交换机、存储网络交换机（如果适用）和存储阵列。而传统架构通常无法按比例扩展，而传统模块化架构则设计为可以按模块扩展。这种方法不需要在每次扩展时进行重新设计，组织可以依赖这种传统的但模块化的架构来实现可预测的扩展设计。

下图展示了典型的传统模块化架构方法的示意图，其中包含了按比例分配的资源：

实施传统模块化架构通常有两种方式。第一种是花时间为客户设计和测试架构，其中计算（例如，戴尔刀片服务器）与网络交换机（例如，思科）和存储阵列（例如，NetApp）结合使用。采用这种方法的风险在于，如果设计解决方案的团队从未设计过 VDI 解决方案，他们可能会在过程中吸取一些经验教训，最终得出一个不太优化的解决方案。这并不是说这种方法不适用或不应该采取，但需要特别注意确保架构的可靠性和可扩展性。一位经验丰富的 VDI 架构师可以使用任何现成的硬件来构建一个可持续的 VDI 架构。

第二种实现传统模块化架构的方法是采用品牌解决方案，如 VCE Vblock（思科服务器 + 思科交换机 + EMC 存储）或 FlexPod（思科服务器 + 思科交换机 + NetApp 存储）等。这些解决方案是经过验证的，可以按可预测的方式进行扩展，并为 VDI 提供已知的架构。这些解决方案的缺点是，它们通常在成本和大规模模块化扩展（例如一次扩展 1,000 个用户）方面存在较高的门槛。

第三种架构类型使用 融合虚拟化设备。融合虚拟化设备通常是 2U 到 6U 的设备，包含一个或多个 ESXi 服务器，并且设备内的本地存储通常在这些 ESXi 服务器之间共享。存储通常通过虚拟存储设备模型共享，其中本地存储作为 iSCSI 或 NFS 存储呈现给设备中的一个或多个 ESXi 服务器。融合虚拟化设备模型对于 VDI 市场来说相对较新。

连接的 vCenter 服务器

随着每个 vCenter Server 虚拟机数量的超出，解决方案将需要多个 vCenter Server。

下表展示了 vCenter 的最大值：

vCenter Server 可扩展性	最大
每个 vCenter Server 启动的虚拟机	10,000
每个 vCenter Server 注册的虚拟机	15,000
已链接的 vCenter 服务器	10
在已链接的 vCenter 服务器中启动的虚拟机	30,000
在已链接的 vCenter 服务器中注册的虚拟机	50,000

vCenter 链接模式有一些基本的先决条件，具体如下：

• 两个 vCenter 服务器必须位于功能正常的 DNS 环境中，在该环境下，能够正确解析每个 vCenter 服务器的 完全限定域名（FQDN）

• 任何参与链接模式的 vCenter 服务器必须位于一个活动目录域中

• 如果 vCenter 服务器位于不同的活动目录域中，则相应的域之间必须建立双向信任关系

• 两个 vCenter 服务器必须位于功能正常的 网络时间协议（NTP） 环境中，在该环境下，两个 vCenter 服务器的时间同步误差不得超过 5 分钟

• 必须允许 Windows RPC 端口映射器打开 远程过程调用（RPC） 端口以支持复制；有关详细信息，请参考 support.microsoft.com/kb/154596

• 两个 VMware vCenter 服务器均拥有 VMware vCenter 标准版许可证（例如，与基础版相比）

• 每个 VMware vCenter 服务器使用独立的数据库

VMware vCenter 链接模式通过 ADAM 数据库复制将两个或多个 vCenter 服务器连接在一起，存储有关用户角色以及 VMware 许可的信息。VMware vCenter 链接模式不进行任何形式的数据库复制。如果 VMware vCenter 链接模式因任何原因失败，两个（或更多）vCenter 服务器仍然可以作为独立实例正常运行。

如前图所示，在两个独立的 vCenter 服务器实例（vCenter1 和 vCenter2）之间，虚拟数据中心、集群、资源池和虚拟机是各自 vCenter 实例独有的。

将多个 vCenter 通过 vCenter 链接模式连接在一起，形成所谓的 pod。一个 pod 最多可以包含 10 个通过链接模式连接的 vCenter 服务器。

vCenter 服务器

根据前面的计算，本解决方案预计每台主机大约支持 120 个 vDesktops；这意味着需要 209 台物理主机来支持该解决方案中的 vDesktop 部分（不考虑虚拟化的 vCenter、数据库等）。

由于最终用户群体的特点、他们的登录时间，以及原始评估的保守性（例如，每个核心支持 10 个 vDesktops），决定了不需要为支持 vDesktops 的 vSphere 服务器配置高可用性（HA）。

还已确定，管理基础设施，包括 View 连接服务器、vCenter 服务器、数据库服务器以及其他几个组件，要求三台物理主机。为了提供一定的保护级别，决定采用 n + 1 解决方案，并使用四台物理主机。

之前已经确定，任何给定的 vCenter 在任何时刻最多只能拥有 10,000 个打开的虚拟机。此解决方案需要支持超过 25,000 个打开的虚拟机；因此，这个解决方案将需要 3 个 vCenter 服务器。

为了平衡负载，vCenter 服务器之间的集群已经尽可能均匀地分配。

请注意，本例中使用的集群命名约定为：

• vCenter 服务器命名格式：vc-{字母}，例如 vc-b

• 集群命名格式：cl-{vCenter 字母}-{编号}，例如 cl-c-6

这些 vCenter 服务器分别命名为 vc-a、vc-b、vc-c。它们的详细信息及图表如下：

上述图表解释了 vCenter 服务器 vc-a。以下是关于 vc-a 的详细信息：

• 9 个每个包含 8 个主机的集群 (cl-a-1, cl-a-2, ..., cl-a-9)

  • 共 72 个主机

  • 共 8,640 个 vDesktops（每个主机 120 个 vDesktops，72 个主机）

上述图表解释了 vCenter 服务器 vc-b。以下是关于 vc-b 的详细信息：

• 9 个每个包含 8 个主机的集群 (cl-b-1, cl-b-2, ..., cl-b-9)

  • 共 72 个主机

  • 共 8,640 个 vDesktops（每个主机 120 个 vDesktops，72 个主机）

上述图表解释了 vCenter 服务器 vc-c。以下是关于 vc-c 的详细信息：

• 7 个每个包含 8 个主机的集群

• 1 个包含 5 个主机的集群

• 1 个包含 4 个主机的集群

• 1 个由 4 个主机构成的集群，专门用于管理

  • 共 69 个主机

  • 共 7,800 个 vDesktops 和约 30 个 vServers（View Connection Server、数据库服务器、vCenter 服务器等）

vCenter vc-c 拥有一个集群 (cl-c-10)，专门用于托管基础设施虚拟机。这些虚拟机包括：

• 3 个 VMware vCenter 服务器 (vc-a, vc-b, vc-c)

• 15 个 View Connection 服务器

• 支持基础设施（如有需要），例如数据库服务器、Liquidware Labs TM 等

VMware 更新管理服务器

VMware 更新管理器是一种自动化应用程序，用于为 vSphere 服务器和虚拟机应用补丁。它最常用于大型环境中为 vSphere 服务器打补丁，因为它能够自动执行将主机置于维护模式、迁移虚拟机、应用补丁、重启以及最小化用户交互的任务。

VMware 更新管理器服务器一次只能与一个 VMware vCenter 服务器实例配对。因此，此解决方案需要 3 个 VMware 更新管理器服务器（每个 vCenter 服务器实例一个）。

VMware vCenter 服务器心跳

在本节中，我们添加了关于 VMware vCenter Server Heartbeat 的说明。在大多数 VMware View 解决方案中，要求有一个或多个高可用的 VMware vCenter Server。vCenter Server 至关重要，因为如果 vCenter 无法使用，将会面临以下问题：

• 新的 vDesktops 无法被配置

• vDesktops 无法被重新组合、刷新或重新平衡

• vDesktops 无法从 View 管理控制台删除

因此，vCenter Server Heartbeat 通常是 VDI 解决方案中 vCenter Server 的一个经济有效的保险措施。

如前所述，VMware Update Manager 只能与一个 VMware vCenter Server 实例关联。然而，值得注意的是，通过 VMware vCenter Server Heartbeat 连接的一对 vCenter Server 被视为一个实例。

因此，解决方案并不要求仅仅因为 VMware vCenter Server Heartbeat 被使用，就需要额外的 VMware Update Manager 服务器。

解决方案设计 — 池

在这里，我们将介绍 View Connection Servers。

View Connection Servers

如下所示，VMware View 基础设施在 VMware vSphere 基础设施已施加的最大值之外，还引入了自己的最大值。View Connection 的最大值见下表：

每个部署的连接服务器	最大
1 个连接服务器支持直接 RDP 或 PCoIP	2,000
7 个连接服务器（5 个热备 + 2 个备用）支持直接 RDP 或 PCoIP	10,000
不使用 View Composer 时，集群中最大主机数	32
使用 View Composer 时，集群中最大主机数	8

如果使用像 Unidesk TM 这样的解决方案替代 View Composer，则最终设计可能支持每个集群更多的主机。

对于必须支持 25,000 个 vDesktops 的解决方案示例，了解任何时候有多少终端用户将登录是非常重要的。一个 VMware View Connection Server 可以支持每次最多 2,000 个直接的 PCoIP 连接。在此示例中，所有 25,000 个终端用户可能会同时登录。因此，至少需要 13 个 View Connection Server（2,000 * 13 = 26,000 个同时直接 PCoIP 连接支持）。

为了在 View Connection Server 故障时提供一定的冗余，建议添加 n + 2（或更多）个解决方案。例如，增加所需的 View Connection Server 数量，即将 13 增加到 15 个 View Connection Server，提供支持最多 30,000 个同时 PCoIP 连接的能力。因此，即使两个 View Connection Server 故障，所有 25,000 个用户仍然可以顺利登录到 VDI。

这 15 台 View Connection Server 应该部署在冗余的负载均衡解决方案后，并配置为通过简单的 ping（如果允许 互联网控制报文协议（ICMP））和 HTTP GET 命令检查 View Connection Server 是否在线，且检查其 URL。整个 View Connection Server 池应通过一个单一的名称进行访问，例如 view.customer.com，最终用户可以通过 https://view.customer.com 来访问 View 环境。

通过利用 HTTP GET 来验证 View Connection Server 的功能，当一个服务器的相关服务停止时，它将无法成功响应 GET 命令，因此会被从负载均衡池中移除。

解决方案设计 — 公式

以下是一些公式，用于计算最小 vCenter 服务器数、连接服务器数和 Pod 数：

• vCenter 服务器的最小数量 = 桌面数 / 10,000

• View Connection Server 的最小数量 = 同时连接数 / 2,000

• vCenter Pod 的最小数量 = vCenter 服务器数 / 10

总结

如本章所述，设计中需要考虑许多因素，如 DHCP 租约时间、最小 vCenter 数量以及服务器平台中需要购买的核心数。对于大规模环境（如成千上万的 vDesktops），最简单的方法可能是从 vSphere 的最大值开始，逐步调整。对于小型环境或不需要大规模虚拟基础设施的 PoC，尽管本章所涵盖的概念仍然适用，因为一个成功的 PoC 可以快速扩展。最后，Pod 架构的概念，或 vCenter 服务器的集合，对于只熟悉 VMware vSphere 平台虚拟服务器解决方案设计的人来说通常是新的。他们可能需要一些时间来理解这些新概念，并了解如何与 vSphere 和 vCenter 的最大值相对接。

第七章：冗余

在构建合适的 VDI 时，必须理解解决方案中的所有可能故障点，以便可以构建冗余来缓解任何故障。虽然不正确地调整 VDI 的规模会导致响应时间慢或最终用户体验差，但如果未能构建适当的冗余，可能会导致解决方案无法访问。在 VDI 解决方案中，需要考虑物理故障点，如网络交换机、电源和硬盘。还需要考虑软件故障点，如 VMware vCenter Server、VMware View Connection Server 和数据库服务器。

本章分析了 VDI 中可能出现的故障点，并提供了针对每个组件的冗余建议。

物理基础设施

本书的范围不涉及高可用虚拟基础设施设计的深入内容。然而，理解并利用以下 VMware vSphere 功能对于实施稳健的 VDI（虚拟桌面基础设施）非常重要。

VMware 高可用性

VMware 高可用性（HA）可用于监控和防止物理主机故障，也可以用于监控和保护 vDesktops 本身。VMware HA 通过监控给定集群中的物理主机来工作。如果主机无法在服务控制台接口上与特定默认网关通信超过 15 秒，HA 故障转移事件将被触发。vSphere 5 还引入了数据存储心跳（Datastore Heartbeating），当发生网络心跳故障时使用。数据存储心跳提供了额外的主机隔离验证层次。

有关 VMware HA 的更多信息，请参阅 Duncan Epping 的 HA Deepdive 文章，链接：www.yellow-bricks.com/vmware-high-availability-deepdiv/。你还可以在他的书籍 vSphere 5 Clustering Technical Deepdive 中查看相关内容。

当主机停止接收来自集群中其他主机的心跳信号且无法 ping 通指定的隔离地址时，该主机被认为是隔离的。

如果 HA 集群的隔离响应设置为保持开机，则主机上的 vDesktops 和其他虚拟机将继续保持开机状态。仅仅因为主机在服务控制台接口上丧失了网络连接，并不意味着 vDesktops 也丧失了网络连接。

如果 HA 集群的隔离响应设置为关机，则主机上的 vDesktops 和其他虚拟机将会关闭电源。这个设置避免了可能出现的脑裂（split-brain）情况。

随着 vSphere 5 的进步，主机隔离事件经过高度验证且准确无误，极有可能指示实际的主机问题。因此，在 VMware View 解决方案中，推荐将隔离响应设置为关机。

如果包含 vDesktops 的特定主机已从集群中隔离，它将执行以下操作：

• 所有虚拟机和 vDesktops 将被关闭。

• 有活动连接的用户将会断开与其 vDesktops 的连接。

  • 如果 vDesktop 是持久桌面池的一部分，用户将在其特定的 vDesktop 启动并上线后重新登录。预计停机时间为 2 分钟。

  • 如果 vDesktop 是非持久桌面池的一部分，用户可以立即重新登录到 vDesktop，前提是当前在线的主机上池中有可用的 vDesktop。预计停机时间不超过 30 秒。

你真的需要 VMware HA 吗？

VMware HA 提供了一定的主机故障保护，当托管 vDesktops 的主机发生故障时，vDesktops 会在无需虚拟基础设施管理员干预的情况下自动启动。

如果入场控制设置为严格，只有当集群中另一主机上有可用资源时，vDesktops 才会启动。

VMware HA 的工作原理是通过确定插槽大小，或支持最密集虚拟机（或 vDesktop）故障切换所需的最小 CPU 和内存量。

例如，如果 vDesktop_A 拥有 4 GHz 的 CPU 和 2 GB 的内存，而 vDesktop_B 拥有 1 GHz 的 CPU 和 6 GB 的内存，则插槽大小将为 4 GHz 的 CPU 和 6 GB 的内存（考虑到内存开销，还需进行额外计算）。

在 VMware View 环境中，通常会有大量具有相同规格的 vDesktops（例如，具有 2 GHz CPU 和 2 GB 内存的 Windows XP vDesktop），因此主要避免了一个名为插槽碎片化的概念。插槽碎片化要求集群中必须有足够的资源以支持在 HA 事件中启动虚拟机，但单个物理主机上没有足够的资源来支持虚拟机的需求。

欲了解有关插槽碎片化的更多信息，请参阅 Duncan Epping 的非常详细的文章，网址如下：www.yellow-bricks.com/vmware-high-availability-deepdiv/，如前所述。

从 vSphere 4.1 起，HA 还与 DRS 配合工作，当集群内出现插槽碎片化时，释放资源插槽。这将涉及到一个故障的服务器必须等待虚拟机在集群中的主机之间进行 vMotion，直到有足够的插槽可用于启动必要的虚拟机。

基于持久 vDesktops 的 VMware View 解决方案应该使用 HA。

在前面的图示中，最终用户连接到了 Host1 上的 vDesktop。Host1 和 Host2 都是同一集群的一部分，并且可以访问相同的共享存储。正如图中所示，vDesktop 的实际虚拟磁盘文件存储在共享存储中，而不是 Host1 的本地存储上。

如前图所示，当 Host1 故障时，最终用户与 vDesktop 的连接会断开。在持久性 vDesktop 解决方案中，最终用户会被分配到特定的 vDesktop。在这种情况下，由于 vDesktop 存储在 Host1 上，而 Host1 刚刚发生故障，因此 vDesktop 无法使用。

最终用户将无法工作，直到 vDesktop 恢复在线，或者最终用户被手动分配到另一个（可用的）vDesktop 资源。

如前图所示，VMware HA 已在 Host2 上启动了最终用户的 vDesktop，Host2 是集群中的可用主机。默认情况下，不会通知最终用户他的 vDesktop 现在已可用，因此最终用户需要反复尝试，直到 vDesktop 在 Host2 上上线。这通常需要 1 到 3 分钟。

注意

对于持久性 vDesktop 环境的高级解决方案概念是监控单个 vDesktop 的故障。如果发现某个用户的持久性 vDesktop 离线，可以向该用户发送电子邮件（用户可能会在手机上收到），告知其 vDesktop 当前不可用，但问题正在解决中。然后，可以使用相同的概念检测 vDesktop 恢复在线并可用（例如，通过在 vDesktop 进入 VMware Tool 的 OK 状态时添加 2 分钟的等待时间），并通知用户他的 vDesktop 已经可用。

对于使用非持久性 vDesktop 的解决方案，VMware HA 的使用问题引起了更广泛的争议。虽然非持久性解决方案依赖于分布在集群中多个主机上的 vDesktop 池，但最终用户并没有被分配到特定的 vDesktop。当主机在非持久性解决方案中发生故障时，任何连接到该特定主机上 vDesktop 的最终用户都会失去连接。此时，最终用户可以重新连接到 VMware View 环境，只要有另一个 vDesktop 可用，用户将成功连接到资源。这是因为在使用非持久性 vDesktop 时，vDesktop 分配是在登录时随机完成的。

非持久性示例

在此示例中，Company_A 有 60 个最终用户，并创建了一个非持久性 vDesktop 池，设置如下：

• 最终用户数量 = 60

• 桌面池大小（最大桌面数量） = 60

• 备用（已开机）桌面数量 = 0

• 电源设置 = 始终开启

• 提前配置所有桌面

采用这些设置时，当池首次建立时，它将自动配置 60 个 vDesktop 并启动它们。

该数量由 VMware View 在 ADAM 数据库中权威管理。如果池的电源设置为 始终开启，VMware View 将创建一个包含 60 个 vDesktops 的池，并立即将其全部启动。无论最终用户社区的负载如何，60 个 vDesktops 总是会保持开启。如果 61 个最终用户尝试同时登录，1 个最终用户将无法访问资源。

假设有这样一种场景，Host1 托管着 30 个 vDesktops，而 Host2 托管着 30 个 vDesktops。桌面池配置为托管 60 个 vDesktops。

在这种环境中，如果 Host1 突然故障，托管在 Host1 上的 30 个 vDesktops 将进入“Agent Unreachable”状态。尽管 VMware View 连接服务器已识别出现在有 30 个 vDesktops 无法访问，但它不会在集群中的可用主机（例如 Host2）上预配新的 30 个 vDesktops。

因此，如果没有使用 HA 将 vDesktops 在另一主机上重新启动，池中 vDesktops 的总数将会减少。通过使用 VMware HA，池中的 vDesktops 总数将不会减少，尽管整体性能可能会下降（如果允许超出可用资源的能力）。

对于非持久性 vDesktop 解决方案，有两条设计路径。第一种是简单地使用 VMware HA 来确保任何位于故障主机上的 vDesktops 能在集群中的另一个可用主机上重新启动。这可能是最简单的配置，通常会导致 5 到 10 分钟的停机时间（因为 vDesktops 需要启动并进入可用状态）。

第二种设计路径是为桌面池设计足够的 vDesktops，以应对主机故障。必须确保使用中的 vDesktops 数量不超过 VMware 授权的法定数量。然而，通过构建一个具有额外容量的桌面池（例如，额外的 30 个 vDesktops），一个主机的停机对最终用户环境的影响将降至最低。对于那些连接到故障主机上 vDesktop 的用户，他们只需重新登录 VMware View 环境，连接到已预配好的、可用的额外 vDesktops。

使用本地存储

本节中我们添加了关于使用本地存储的说明。如本书后续将讨论的，本地存储是某些 VDI 解决方案的可行选项。如果最终用户的 vDesktop 存储在 Host1 的本地存储上，在主机故障时，VMware HA 将无法将 vDesktop 启动到另一台主机上（例如 Host2），因为其他主机无法访问存储在 Host1 本地存储上的虚拟磁盘文件。

如前面的示例图所示，Host1 和 Host2 都有本地 虚拟机文件系统（VMFS） 数据存储，并且能够访问 存储区域网络（SAN） 上的共享 VMFS 数据存储。如果 Host1 发生故障，任何存储在 Host1 本地 VMFS 数据存储上的 vDesktop 或模板将无法使用。

如果使用的是持久性解决方案，并且 vDesktop 被放置在本地 VMFS 数据存储中，那么在主机发生故障时，最终用户将无法访问他们的 vDesktop。VMware HA 将不起作用，因为 vDesktop 并未存储在共享存储上，而是存储在主机的本地 VMFS 数据存储中。

因此，当将 vDesktop 的核心虚拟磁盘放置在本地存储时，必须使用非持久性解决方案，因为最终用户并未专门分配到特定的 vDesktop。如果托管 vDesktop_17 的物理服务器发生故障，而该 vDesktop 是分配给员工 User_LL 的持久性 vDesktop，User_LL 将无法连接到桌面资源。

VMware 分布式资源调度（DRS）

虽然 VMware 分布式资源调度 (DRS) 不提供弹性，但它确实可以最小化在物理主机故障时的潜在影响。通过在集群中所有可用主机之间平衡处理负载，物理主机故障将会带来最小的影响。这对于运行服务器操作系统的虚拟机和 vDesktop 都适用。在虚拟化的 VMware vCenter Server(s) 和/或 VMware View Connection Server(s) 的 VMware View 解决方案中，使用 VMware DRS 来平衡集群中的负载并最小化影响是明智的。有关更多考虑事项，请参阅下文解释的 反亲和性 部分。

在前面的示例图中，集群中有三台主机，并且没有启用 VMware DRS。在集群的第一台主机上，有 70 个 vDesktop；在第二台主机上，有 10 个 vDesktop；而在第三台主机上，有 20 个 vDesktop。由于没有启用 VMware DRS，负载（因此 vDesktop 的数量）在集群中所有可用主机之间并未均衡分配。

继续前面的示例，如果第一台主机发生了预料之外的故障，将有 70 个 vDesktop 受到影响。如果启用了 DRS，并且所有 vDesktop 的 CPU 使用情况大致相同，那么每台主机上大约会分配 34 个 vDesktop。这将大大减少因物理主机故障而导致的最终用户受影响的数量。

反亲和性

亲和性（Affinity）和 反亲和性（Anti-affinity）是 VMware DRS 中的设置，用于确定给定集群中虚拟机之间的相互关系。

在前面的图示中，DRS 已启用并设置为自动模式，适用于四主机集群。没有设置亲和性或反亲和性规则。VMware View 解决方案需要两个 View 连接服务器，这两个服务器都已虚拟化并放置在前述集群中。

通过正常的 DRS 操作，两个 View 连接服务器都被放置在 Host1 上。如果 Host1 发生故障，则不允许有新的连接进入 VDI。

在前面的示意图中，两个 View 连接服务器 View1 和 View2 已经设置了反亲和性规则，并且它们具有相反的极性。该规则表示，在集群中有可用主机时，两个 View 连接服务器不能位于同一台主机上。

配置反亲和性后，单一主机故障不会导致整个 VMware View 连接服务器环境崩溃。

VMware vCenter Server

VMware View 使用 VMware vCenter 执行所有的配置任务。没有功能正常的 VMware vCenter Server，就无法创建、刷新、重新组合、重新平衡或删除 vDesktops。因此，必须高度重视保护解决方案中使用的 VMware vCenter Server。

VMware vCenter Server 服务有两个主要组件，具体如下：

• VMware vCenter Server 服务

• 后端数据库

VMware vCenter Server 服务应以一种消除停机时间或提供少于一分钟恢复时间目标（RTO）的方式进行保护。对于极为活跃的 VDI，长期停机可能导致无法向请求的终端用户提供桌面资源。保护 VMware vCenter Server 服务的最强方法是 VMware vCenter Server Heartbeat（下面会进一步讨论）。

VMware vCenter 使用的后端数据库可以驻留在同一台服务器（物理或虚拟）上，也可以驻留在独立的数据库服务器上。

组件	选项 1	选项 2
vCenter Server	虚拟	物理
数据库位置	在 vCenter Server 上	在一个或多个独立的服务器上
数据库保护	备份解决方案	集群解决方案

注意

在前述表格中，出现粗体字的部分是建议项。

在 VMware View 解决方案中，来自组织数据库团队的合作非常重要，因为 vCenter 故障（通常与数据库相关）可能会对 VDI 造成严重影响。因此，建议在设计过程中与组织的数据库团队进行沟通。

VMware vCenter Server Heartbeat

VMware vCenter Server Heartbeat (vCSH) 是 VMware 的一款产品，由 Neverfail 提供支持。vCSH 监控并保护 VMware vCenter Server 基础架构中所有必要的组件，包括：

• 服务器： vCSH 保护物理或虚拟服务器故障或操作系统故障（例如，蓝屏死机）

• 网络： vCSH 保护网络身份，包括 vCenter Server 的 IP 地址和 DNS 名称。

• 应用： vCSH 保护与 VMware vCenter Server 服务相关的应用环境，以及所需的文件和注册表项。

• 性能： vCSH 监控底层物理或虚拟服务器的性能。

• 数据： vCSH 监控所有数据和相关应用，并保持数据副本，包括数据库（如果是本地的）。

VMware vCenter Server 心跳需要两个 VMware vCenter Server 实例，这两个实例会合并成一个 vCSH 配对。vCSH 配对作为单一的 VMware vCenter Server 实例工作，共享主机名、IP 地址以及其他相关信息和配置。

vCSH 以异步方式将数据从配对中的主 vCenter Server 复制到次 vCenter Server。VMware vCenter 还会识别 VMware View Composer 服务，以确保它也受到保护。

为什么应该使用 VMware vCenter Server 心跳

对于生产环境、大型部署或具有高关键性的解决方案，应该始终使用 VMware vCenter Server 心跳，因为它保护了 VDI 中最脆弱的组件。

存储阵列通常具有内建的高可用性，支持 RAID、多存储处理器、电源供应、风扇、额外磁盘等。

物理主机通过多个网卡、多重电源供应和 VMware 功能（如 VMware HA）来进行保护。

网络层通过硬件和网络路径的冗余来进行保护。

View 连接服务器通过重复实例、负载均衡，以及可能通过 VMware 故障容错来保护。

然而，由于单个 VMware vCenter Server 实例可能负责超过十台物理主机，并且可能管理数百个 vDesktops，因此保护其状态至关重要。

VMware vCenter Server 心跳不仅能够保护 VMware vCenter Server 服务，还能保护 vCenter 数据库（如果是本地的）和 VMware View Composer 服务。

VMware View

VMware View 负责处理来自 vDesktops 的请求，与 VMware vCenter Server 交互以配置、重组和删除 vDesktops；以及执行其他各种必要任务，以确保 VDI 正常运行。

复制

安装 VMware View 连接服务器时，有四种安装类型。具体如下：

• 标准

• 复制

• 安全

• 传输

对于 View Connection Server 池中的第一个 VMware View 连接服务器实例，应选择标准安装。然而，为了消除 View 连接服务器作为单点故障的风险，可以安装第二个（以及其他）View 连接服务器。一旦 View 连接服务器存在于基础设施中，可以将额外的 View 连接服务器加入到原来的服务器，形成 View 连接服务器池。要将新的 View 连接服务器加入现有的 View 连接服务器或 View 连接服务器池，请选择 副本 安装模式。

当创建副本 View 连接服务器实例时，它会从现有的 View 连接服务器实例复制 VMware View LDAP 配置。

负载均衡

VMware View 连接服务器负责在授权的最终用户与 VDI 中的 vDesktop 之间建立连接。因此，如果没有可用的 VMware View 连接服务器，就无法建立新的连接到 VDI。然而，如果没有可用的 VMware View 连接服务器，现有的连接将不受影响。

因此，保护 VDI 中可用的 View 连接服务器非常重要。最佳做法是至少有两个 VMware View 连接服务器（或可能有一个通过 VMware 容错保护的服务器）。实现 VMware View 连接服务器的弹性最简单的方法是使用负载均衡解决方案。市场上有多种负载均衡解决方案，包括 Microsoft 网络负载均衡器 (NLB) 和来自 F5 等公司提供的硬件设备（首选）。

负载均衡解决方案将创建一个虚拟 IP 地址，最终用户将通过该虚拟 IP 地址连接到 VDI。在虚拟 IP 地址背后，将是负载均衡池中所有 VMware View 连接服务器的实际 IP 地址。如果某个 VMware View 连接服务器没有响应 ping 请求（例如），它将被从负载均衡池中移除，以确保传入的最终用户请求不会被路由到不可用的 View 连接服务器。

许多负载均衡解决方案还提供通过 HTTP GET 和类似命令监控可用性的功能，确保服务器不仅在线，而且对基于 Web 的请求做出响应。

VMware 容错

VMware 容错 (FT) 可以作为 VMware View 连接服务器的额外保护层。VMware FT 通过创建并维护一个与主虚拟机完全相同的副本虚拟机来保护虚拟机。副本虚拟机会持续可用，以便在主虚拟机所在主机发生故障时替代主虚拟机。

在 VMware 容错中，不会有停机时间（与 VMware HA 不同）。但 VMware FT 确实有一些限制，包括支持的硬件、vCPU 数量（目前为 1）等。

VMware FT 会将主虚拟机上的输入和事件传递到副虚拟机，副虚拟机在集群中的另一台主机上运行。

VMware FT 确实会影响虚拟基础架构设计，因为它需要为 FT 日志记录配置单独的专用 NIC。FT 日志记录和 vMotion NIC 必须位于不同的子网中。此外，任何单一的 ESX 主机上最多只能容纳四个启用 VMware FT 的虚拟机主虚拟机或副虚拟机。

使用 VMware FT 时的设计影响

为了正确说明使用 VMware FT 的设计影响，将使用以下示例。

经过深入分析，已确定 CustomerA 需要四个 VMware View Connection Servers，以满足进入请求的需求。

作为解决方案的一部分，安装并配置了四个 VMware View Connection Servers，并将其放置在负载均衡器后面。

如果某个 VMware View Connection Server 发生严重故障（例如，蓝屏死机），则仅剩三个连接服务器可供最终用户使用。剩余的三个连接服务器可能无法处理负载，导致部分最终用户无法连接到 VDI。

恢复因故障导致的 View Connection Server 连接的唯一方法是从以前的备份中恢复，或者构建新的 View Connection Server，并将其添加到负载均衡池中，如前图所示。

如果某个 VMware View Connection Server 所在主机发生故障，VMware HA 将在集群中的可用主机上启动该虚拟机。部分最终用户可能会经历几分钟的停机时间（如果剩余的三个 View Connection Servers 无法处理负载）。然而，3 到 5 分钟后，完整的连接应该恢复。

通过利用 VMware FT 保护 View Connection Servers，如果发生物理主机故障，这种解决方案将不会受到任何影响（假设反亲和性已将主虚拟机和副虚拟机分开）。

如果发生影响 View Connection Server 的物理主机故障，VMware FT 会立即使副虚拟机（如前图底行所示）变为活动状态。通过 VMware vLockstep 技术，副虚拟机是主虚拟机的完全副本，主虚拟机原本驻留在故障主机上。故障切换成功后，副虚拟机会被标记为主虚拟机。此外，将从新指定的主虚拟机创建新的副虚拟机。

注意

然而，VMware FT 并不防护来宾操作系统故障（例如，蓝屏死机）。因此，将 VMware FT 与 VMware HA 结合使用 VM 监控，是最强大的解决方案。

虽然 VMware FT 是保护 VMware View 连接服务器的有用技术，但大多数虚拟化架构师更倾向于仅仅向原设计中添加一个额外的 View 连接服务器，而不是增加 VMware FT 的复杂性。

父 vDesktop 和模板

VMware View 在部署选择了完整虚拟机选项的 vDesktops 时使用虚拟机模板。在选择了View Composer 链接克隆选项时，VMware View 使用标准虚拟机（而不是模板）部署 vDesktops。为了使虚拟机被 View Composer 识别，它必须至少有一个快照。View Composer 从选定的快照部署池中的所有 vDesktops。

重要的是要理解，如果父 vDesktop（对于 Linked Clone 池）或黄金 vDesktop 模板（对于 Full Desktop 池）不可用，则无法配置新的 vDesktops。

模板

虚拟机模板的保护稍显复杂。当创建虚拟机模板或将虚拟机模板添加到库存中时，管理员必须在集群中选择一个特定的主机。根据图形用户界面（GUI），"选择集群中的特定主机。在高可用性集群和完全手动的动态工作负载管理集群中，每个模板必须分配给特定的主机。"

因此，如果 vDesktops 的黄金模板存储在 Host1 上，且 Host1 出现故障，VMware HA 将无法恢复该模板。相反，原始模板将在 vCenter 中显示为不可用。从此时起，vCenter 中原始模板的库存条目可以被删除，然后模板可以重新添加。这是可能的，因为虽然主机不可用，但虚拟机模板实际上存储在共享存储中（假设遵循了最佳实践）。

在协助组织进行操作准备时，前述的恢复过程应列入标准操作程序手册中。

带有快照的父 vDesktops

要保护父 vDesktop 及其快照，仅仅执行一个简单的克隆虚拟机任务是不够的。这是因为克隆任务会合并快照树，从而删除所有与基础虚拟机相关的快照。

因此，必须使用 VMware HA 来保护父 vDesktop。由于父 vDesktop 仅仅是一个带有快照的虚拟机（而不是前述场景中的虚拟机模板），在主机故障时，VMware HA 会将父 vDesktop 的所有权转移到集群中可用的主机上。

用户角色

对于使用用户角色解决方案的环境，例如 Liquidware Labs ProfileUnity™，将用户角色放置在高可用的网络共享上对于确保终端用户数据始终可用至关重要。通过使用分布式文件系统 (DFS) 服务或分布式文件系统复制 (DFS-R) 服务，存储用户角色的文件共享即使在文件服务器发生故障时仍然可用。此外，使用 DFS-R，用户角色可以在同一站点或其他站点的其他服务器之间进行复制。DFS-R 通过确保存储用户角色的文件共享将数据复制到异地，从而实现 VDI 的持续运营 (COOP)。

微软 DFS 还利用 Active Directory 站点来确保终端用户从参与 DFS/DFS-R 组的最近服务器中获取他们的角色。此外，站点成本可以用于确定哪个是终端用户尝试从网络共享获取其用户角色时最便宜的目标选择。

以下表格展示了所有组件故障类型的汇总：

组件	故障类型	保护方式	停机时间	备注
vCenter 服务器	底层物理主机	VMware HA	大约 10 分钟	在故障期间，vDesktop 任务（如创建、重新合成等）将无法使用。由于在初始服务启动期间执行的数据库操作，vCenter 可能需要更长时间才能启动（与 View 连接服务器不同）。
vCenter 服务器	底层物理主机	vCenter 服务器心跳	少于 1 分钟	需要第二个 vCenter 服务器实例。
vCenter 服务器	操作系统（蓝屏死机）	vCenter 服务器心跳	少于 1 分钟	需要第二个 vCenter 服务器实例。
vCenter 数据库	任何	集群解决方案	少于 1 分钟	需要两台数据库服务器。
vCenter 数据库	数据库损坏	备份/恢复/快照	变化	恢复时间取决于所使用的解决方案、媒体速度和可用的吞吐量。
View 连接服务器	底层物理主机	VMware HA	大约 5 分钟	需要多个 View 连接服务器位于负载均衡器后，以减轻对终端用户的影响。
View 连接服务器	底层物理主机	负载均衡器	0 分钟	需要多个 View 连接服务器位于负载均衡器后，以减轻对终端用户的影响。如果没有 VMware HA，可能会影响总的入站连接数。
View 连接服务器	底层物理主机	VMware FT	0 分钟	它不能保护客操作系统故障（参见 VMware HA 的虚拟机监控）。
View 连接服务器	View 连接服务器服务	负载均衡器	0 分钟	需要多个 View 连接服务器位于负载均衡器后，以减轻对终端用户的影响。
视图连接服务器	操作系统（蓝屏死机）	VMware HA 的虚拟机监控	大约 5 分钟	需要多个视图连接服务器位于负载均衡器后，以减少对终端用户的影响。
视图编排器	底层物理主机	VMware HA	大约 10 分钟	在停机期间，vDesktop 任务（如配置、重组等）不可用。vCenter 可能需要更长时间启动（与视图连接服务器不同），因为在初始服务启动过程中会执行数据库操作。
视图编排器	底层物理主机	vCenter 服务器心跳	少于 1 分钟	需要第二个 vCenter 服务器实例。
视图编排器	操作系统（蓝屏死机）	vCenter 服务器心跳	少于 1 分钟	需要第二个 vCenter 服务器实例。

总结

到目前为止，已经解决了一些最重要的设计考虑因素（例如，持久性或非持久性），以及整体 VDI 的适当大小。设计一个高度可靠的 VMware View 解决方案对于生产质量的解决方案至关重要。在下一章中，将讨论最后一个主要难题——存储设计。一个大小不当的 VDI 可能会导致用户体验不佳。没有冗余的 VDI 可能会导致意外的停机和停机时间。一个存储设计不当的 VDI 不仅会导致用户体验差，还可能大大增加 VDI 解决方案的整体成本。由于存储通常是 VDI 解决方案中最昂贵的组件之一（如果不是最昂贵的组件），因此合理的尺寸规划至关重要，必须在满足需求的前提下进行。

第八章：存储规模规划

存储层可能是 VMware View 设计中最关键的组件之一。对于许多 VDI 专业人士来说，这可能是当需要进行性能故障排除时面临的主要问题。通常，存储层是性能问题的根本原因。为什么存储如此关键？要回答这个问题，我们首先需要了解基于英特尔®的桌面如何工作并与 Windows 操作系统交互，然后再深入了解 VDI 的存储世界。

物理桌面一直依赖专用硬盘，并且只有一个 Windows 内核可以访问该磁盘，从而造成单一的 I/O 流。尽管该设备专用，但它也面临磁盘争用。这种争用可能是由于过多的磁盘 I/O 操作或 I/O 块大小引起的。重要的是，不论是哪种类型的操作导致争用，最终结果都是高响应时间，也称为延迟。

最近的磁盘技术进展，如固态硬盘（SSD），大幅减少了延迟的影响，从而提升了终端用户体验。最先进的 SSD 可以处理并提供大量的 I/O 和吞吐量。

随着使用更快磁盘的能力，用户习惯了提升的性能。然而，微处理器和 RAM 技术也在快速发展，像英特尔 Core i7 和 DDR3 等技术很快使即便是最先进的 SSD 也再次成为性能瓶颈。

除少数例外，VDI 实现并未使用单一的专用磁盘。相反，VDI 使用磁盘池来提供存储容量、I/O 和吞吐量给 vDesktops。

大多数 VDI 实现需要共享存储，以便为多个服务器提供共享数据存储。共享存储也是 VMware vSphere 功能（如 vMotion、DRS 和容错）的关键支持者。采用浮动池和漫游配置文件组合的实现可能会选择存储设备解决方案，其中没有持久数据存储在这些设备上。

本地磁盘、专用附加存储（DAS），甚至无盘解决方案都可以在 VDI 部署中使用。了解每种方法背后的使用场景和影响非常重要。

在 VDI 设计阶段做出的存储架构决策将深刻影响基础设施的性能和操作方式。所选的存储类型和传输协议将决定 VMware View 和 vSphere 如何运行。然而，存储类型和协议也会决定数据存储的设计方式或每个数据存储上应使用多少桌面。

VMware View Composer

VMware View 基础架构包括 VMware View Composer 作为可选组件。View Composer 作为 Windows 服务在 vCenter Server 上运行，允许 View Manager 从单个集中化的标准基础镜像快速克隆和部署多个虚拟桌面。View Composer 最初设计用于减少 VDI 部署中所需的总存储；然而，今天，View Composer 还提供了重要的管理功能，如刷新和重组操作。

View Composer 使用链接克隆技术。与传统的虚拟机模型不同，在传统模型中，每个虚拟机作为一个独立的实体存在，具有专用的虚拟磁盘，而 View Composer 创建的虚拟机都依赖于一个主虚拟机。这种主虚拟机在 VMware 术语中被称为父虚拟机。

父虚拟机作为基础镜像使用，从父虚拟机拍摄快照并复制，创建复制镜像，这将作为所有链接克隆桌面池中虚拟机的主磁盘。

复制磁盘是作为只读的精简配置实体从父虚拟机创建的，以确保对父虚拟机的任何后续更改不会影响链接克隆桌面。如前所述，复制是精简配置的，这意味着只有父虚拟机中的数据才会被复制到复制镜像中。例如，如果父虚拟机创建时有 40 GB 的磁盘，但在客户的 Windows NTFS 卷中只显示 20 GB，那么复制镜像将是 20 GB。

复制镜像是通过VM LockStatus参数在 vCenter Server 中受保护的实体，该参数添加到虚拟机注释中，如下图所示。如果复制镜像因任何原因需要删除，必须按照 KB1008704 中概述的流程操作。该过程的链接如下：

kb.vmware.com/selfservice/microsites/search.do?language=zh_CN&cmd=displayKC&externalId=1008704.

以下截图显示了VM LockStatus参数：

一个父虚拟机可能包含多个快照，这些快照代表了对基础镜像所做的更改。这些差异可能是由于 Windows 客户操作系统所需的修复、补丁和升级。将新应用程序部署到基础镜像、应用程序升级，甚至是 Windows 配置更改，都可以添加到快照中。

每次修改后，必须由管理员关闭父虚拟机，并拍摄新的快照。

在桌面池配置过程中选择将要使用的快照。整个桌面池分配一个快照。然而，也可以使用来自同一或不同父虚拟机的不同快照，单独重组虚拟桌面。

以下截图演示了 VMware vCenter Server 快照管理器，已经拍摄了一些快照。推荐在描述字段中标注对父虚拟机所做的更改：

桌面池配置过程中可以看到 VMware View 快照选择，以下截图展示了在 View 管理员控制台中的快照选择：

在 VMware View 4.5 之前的版本中，每个托管虚拟桌面的存储区会为桌面池创建一个唯一的副本磁盘。此外，对于桌面池使用的每个不同的快照，曾经会为每个使用的存储区创建一个新的副本磁盘。

每次只能为桌面池分配一个快照。然而，在为桌面池选择了不同的快照并触发重组操作后，会在每个存储区中创建一个表示新快照的第二个副本磁盘，这些存储区由使用副本磁盘的虚拟桌面共享。在这种情况下，每个存储区可能会包含桌面池的两个副本。

在重组操作中，原始副本镜像仅在所有桌面池中的桌面都使用新的基础副本磁盘重新组合，并且不再需要旧副本时才会被删除。因此，确保用于存储副本的存储区上有充足的空间非常重要。

如果管理员在选择存储区时没有选择可选的专用副本存储区功能，那么这个场景在 VMware View 5.0 中依然适用。

VMware View 4.5 及以后的版本实现了为整个桌面池指定唯一存储区以托管副本磁盘的功能。这部分是 VMware View 分层存储功能的一部分。

以下截图展示了在 View 管理员控制台中的存储区选择：

如果桌面池很大，并且最终使用整个 vSphere 集群资源，可能会导致整个集群只使用一个副本磁盘。对于 VMware View 5.0，单个桌面池中支持的最大虚拟桌面数量为 1,000 个。虽然可以超过 1,000 个桌面，但不建议也不支持这样做。

在某些情况下，如果使用了多个快照，那么在池配置期间选择的单个存储区中会创建多个副本。以下图示展示了在 VMware View 4.5 及以上版本中，使用和不使用专用副本存储区选项的区别：

在以下示例场景中，VMware View 在两个桌面池中运行 256 个虚拟桌面，每个池使用 2 个快照。如果副本磁盘大小为 20 GB，则副本磁盘的总存储分配将为 320 GB，每个存储区为 80 GB。

桌面池数量 * 使用中的副本数 * 数据存储数量 * 副本大小 = 2 * 2 * 4 * 20 GB = 160 GB。

使用相同的示例场景，若使用专用副本数据存储，则副本磁盘的总存储分配将在单个数据存储中为 80 GB。

桌面池数量 * 使用中的副本数 * 副本大小 = 2 * 2 * 20 GB = 80 GB

以下图示展示了这两种场景。它展示了在使用多个快照和专用副本磁盘数据存储的情况下，副本磁盘放置的差异，适用于 View 4.5 及以上版本：

对于前述场景，运行相同的计算，若有 2000 个虚拟桌面，View Composer 技术提供的存储节省可能高达 6.3 TB。环境中虚拟机和桌面池的数量越多，当没有选择专用副本数据存储选项时，每个数据存储上的副本数量就会越大。

如果没有为每个桌面池选择所有数据存储，可以分解副本磁盘和存储消耗的量，从而限制虚拟桌面在数据存储之间的分布。

数据存储的数量和数据存储的大小必须满足为所需数量的桌面分配存储容量和性能要求。这个概念假设管理员会仔细管理和选择桌面池使用的数据存储，避免让所有数据存储被所有桌面池使用。

以下截图展示了没有使用专用副本数据存储选项的解决方案：

链接克隆磁盘也叫做 增量磁盘，因为它积累了增量变化。在副本磁盘创建后，View Composer 开始创建链接克隆虚拟桌面。每个链接克隆都有一个唯一的增量磁盘，并与副本磁盘相关联。

增量磁盘仅包含与原只读副本磁盘的差异，这些差异是克隆虚拟桌面特有的，从而节省了大量存储。链接克隆磁盘将根据客户操作系统请求的块写入更改而逐渐增长，可能会增长到父虚拟机的最大大小。

以一个例子说明，如果管理员最初为父虚拟机配置了一个 30 GB 的平面磁盘，那么这将是增量磁盘的最大大小。

View Composer 可以大幅节省存储；然而，可能会有数十个或数百个链接克隆虚拟桌面使用同一数据存储来读取该单一现有的副本磁盘。如果没有使用专用副本数据存储选项，则副本仅被同一数据存储中托管的桌面使用。

所有访问副本磁盘的虚拟桌面将对 LUN、RAID 组和磁盘造成 I/O 压力，并可能导致 I/O 争用。I/O 争用是由于多个虚拟桌面和用户同时访问同一数据存储所引起的。

每个数据存储通常由一个 LUN（逻辑单元号）提供支持（如果使用光纤通道协议 (FCP)）或由一个导出提供支持（如果使用 NFS）。LUN 和导出都由 RAID 组配置支持，RAID 组包含配置以支持工作负载的磁盘池。这些磁盘和 LUN 必须能够满足副本磁盘所需的性能规格。这些规格包括每秒输入/输出操作次数 (IOPS) 和吞吐量。

如果在设计阶段决定使用专用副本数据存储，建议分配 Tier 1 存储，例如，使用 SSD 来承载副本磁盘。

下图展示了一个典型的虚拟磁盘与驱动器类型关联示意图：

存储供应商有不同的解决方案和架构来解决响应时间和延迟问题。一些可用的解决方案包括自动存储分级、存储池、无磁盘环境、内联 I/O 去重和本地主机缓存。

VMware vSphere 文件

下表列出了通过 VMware View 提供的虚拟桌面所创建的文件和磁盘，这些文件是任何在 vSphere 虚拟化平台上创建的虚拟机的标准文件：

文件类型	描述
.vmx	.vmx文件是虚拟机的主要配置文件，包含操作系统、磁盘大小、网络等信息。
.vmsd	关于快照的信息和元数据。
.vmxf	虚拟机在团队中时的补充配置文件。注意，虚拟机从团队中移除时，.vmxf文件仍然保留。
.vswp	.vswp文件是为每个虚拟机创建的交换文件，用于在 ESXi 主机上实现虚拟机内存超分配。当虚拟机启动时会创建此文件，大小与虚拟机未预留的内存大小相等。虚拟机创建时，默认的内存预留为 0 MB，因此.vswp文件的大小等于分配给虚拟机的内存量。如果虚拟机配置了 1024 MB 的内存预留，则.vswp文件的大小将等于分配给虚拟机的内存减去 1024 MB 的预留。
.vmss	.vmss文件是在虚拟机挂起时创建的，用于保存挂起状态。本质上，这是虚拟机内存的副本，大小始终与分配的总 RAM 大小相同。需要注意的是，.vmss文件是在虚拟机进入挂起状态时创建的，但当虚拟机从挂起状态恢复时，该文件不会被删除。.vmss文件只有在虚拟机关机时才会被删除。如果虚拟机配置了 2048 MB 的内存，.vmss文件的大小将为 2048 MB。
.nvram	此文件存储虚拟机 BIOS 的状态。
.vmsn	快照状态文件，存储在拍摄快照时虚拟机的运行状态。
-flat.vmdk	-flat.vmdk 是一个原始磁盘文件，为分配给特定虚拟机的每个虚拟磁盘创建，并且其大小与创建虚拟机时添加的虚拟磁盘大小相同。这是一个预分配的磁盘文件，仅适用于完整克隆虚拟机。
.log	VM 日志文件相对较小。

VMware View 特定文件

以下表格列出了通过 VMware View 配置的虚拟桌面创建的文件和磁盘。某些磁盘仅在使用 View Composer 或为桌面池分配持久或一次性磁盘时创建：

文件类型	Composer	描述
replica-GUID.vmdk	是	副本虚拟机用于启动链接克隆虚拟机。
-internal.vmdk	是	Quick Prep/Sysprep 的数据配置。
VM-s000[n].vmdk	是	当虚拟机有快照时创建。此文件存储虚拟机运行时对虚拟磁盘所做的更改。可能会有多个此类文件。字母后的三位数字（此例中 s 后的 000）表示一个唯一的后缀，用于避免文件名重复。
VDM-disposable-GUID.vmdk	是	重定向的 Windows 操作系统页面文件和临时文件。
.log	否	VM 日志文件。

分层存储

VMware View 4.5 及以上版本允许管理员选择不同的存储区来托管不同类型的虚拟磁盘（副本、链接克隆和持久磁盘）。数据性能分类是存储分层实施的重要部分，允许管理员根据性能、成本和容量为每种类型的磁盘选择提供最合适存储层的存储区。

注意

重要提示：不要将 VMware View 提供的存储分层功能与存储供应商提供的自动存储分层混淆。VMware View 提供的解决方案是静态的，无法自动移动数据以实现最佳性能。两者是互补的解决方案。

随着存储分层的引入以及将工作负载分段到不同存储区和磁盘类型的能力，了解每个虚拟桌面创建的磁盘和数据类型非常重要。每个实施方案中创建的磁盘类型可能不同。使用链接克隆技术的桌面池可能会有额外的虚拟磁盘，而在使用传统完整克隆配置时不会创建这些磁盘。

以下图表展示了 VMware View 使用的多种类型的虚拟磁盘：

副本磁盘

replica-GUID.vmdk 文件夹包含运行虚拟机所需的所有文件，但它将专门用作只读并作为链接克隆虚拟桌面的基础。以下截图展示了用于托管副本磁盘的文件夹和文件。

尽管在以下示例中磁盘的配置大小设置为 30 GB（31,457,280 KB），实际上只使用了 8 GB。这是因为 View Composer 利用了 vSphere VMFS 薄配置技术来创建副本磁盘。这是一个自动设置，无法通过 View Manager UI 更改，并且会独立于父虚拟机是否为薄或厚配置工作。对于 NFS 部署，薄配置也是唯一的配置机制。

内部磁盘

internal.vmdk磁盘是一个小磁盘，包含 Quick Prep/Sysprep 的配置数据。在以前的 VMware View 版本中，操作（例如刷新）会导致完全删除桌面，然后为新的虚拟桌面进行配置和定制。这个过程过去需要很长时间才能完成，并且通常会消耗大量的计算和存储资源。

VMware View 4.5 及以后版本开始实现一种不同的虚拟桌面刷新技术，利用了 vSphere 快照技术。

刷新操作仅仅是一个快照恢复操作。内部磁盘用于存储 Windows 根据默认的 AD 策略设置周期性地进行的 Active Directory 计算机账户密码变更。计算机账户密码在存储到内部磁盘之前会被加密。

每当域计算机账户密码发生更改时，VMware View Agent 会将密码的另一个加密副本存储到磁盘中。这确保了在刷新桌面时，域连接得以保持。

内部磁盘连接到桌面，但不会分配驱动器字母。

以下截图显示了来自客户虚拟桌面内部的内部磁盘截图：

内部磁盘是 VMware View 创建的唯一一个非薄配置磁盘。其大小非常小，因此即使是厚配置，也不会改变解决方案的容量需求。

Delta/差异磁盘

以下截图演示了在虚拟机文件夹中创建的文件夹和文件，用于托管链接克隆桌面。在以下示例中，差异磁盘是VMView-7-D-01-000001.vmdk。

自定义过程完成后，虚拟机会被关闭，View Composer 会对链接克隆拍摄一个快照。

以下截图显示了在各自虚拟机文件夹中创建的文件夹和文件：

在创建快照后，数据不再写入基础.vmdk文件。相反，变更会写入差异磁盘。每次创建快照时都会创建一个差异磁盘。在定义数据存储大小需求时，必须考虑到使用快照的任何需求。

临时磁盘

VMware View 允许为每个虚拟桌面创建一个可选的固定大小的非持久性磁盘。当将可丢弃磁盘分配给桌面池时，VMware View 会将 Windows 临时系统文件和文件夹重定向到可丢弃磁盘。

当虚拟桌面关闭、电源重启或重新组成时，可丢弃磁盘会被自动删除，这意味着在这些操作期间临时文件也会被删除。

可丢弃磁盘也是薄配置的，并将在桌面池配置期间设置的最大大小范围内逐渐增长。

以下截图显示了 View 管理控制台中的可丢弃文件重定向配置：

可丢弃磁盘被硬编码为在 Windows 桌面上注册为第一个可用驱动器。这种行为在尝试在 Windows 虚拟桌面中映射网络驱动器时可能会带来一些影响。即使 CD-ROM 没有使用，第一个可用驱动器字母也会是E:，因为 C: 被操作系统占用，D: 被可丢弃磁盘占用。

常常被卸载到可丢弃磁盘的文件包括 Windows 页面文件、VMware 日志文件和临时 Internet 文件。

Windows 页面文件

当 Windows 不断耗尽物理内存时，它将开始将内存分页到磁盘。这一分页过程会导致块写入，从而增加可丢弃磁盘的大小。作为一种推荐方法，管理员应确保虚拟桌面有足够的虚拟内存以避免磁盘分页。磁盘分页会对性能产生负面影响。

临时 Internet 文件

用户临时文件保存在系统或持久数据磁盘上，这可能包括写入%USERPROFILE%\AppData\Local\Temp和Temporary Internet Files的文件。这些是可能快速增长并占用磁盘空间的临时文件。

由于临时文件被卸载到可丢弃磁盘，增量文件的稳定增长得以减少。View Composer 不再使用根据块更改增长的增量磁盘，而是使用可丢弃磁盘。然而，根据虚拟桌面和工作负载要求对可丢弃磁盘进行合理大小设置非常重要。一旦分配给虚拟桌面池，该设置不能通过 View 管理器更改。

以下截图显示了包含 Windows 临时文件的可丢弃磁盘：

注意

配置链接克隆池时，确保可丢弃磁盘大于 Windows 页面文件大小加上临时文件的开销。

持久磁盘

持久数据磁盘是 VMware View 早期版本中称为用户数据磁盘（UDD）的新名称，并且保持与 UDD 相似的特性。持久磁盘的创建旨在维持用户与虚拟桌面之间的一对一关系。

在桌面池配置时选择该选项时，会创建持久磁盘，并且 VMware View Agent 会对 Windows 客户操作系统进行修改，以便将用户配置文件重定向到该磁盘。

在 VMware View 4.5 及更高版本中，可以管理持久磁盘。可以将磁盘从虚拟桌面上分离并重新附加。请注意，这仅适用于在 VMware View 4.5 或更高版本中创建的磁盘。如果 VMware View 环境是从早期版本升级的，则无法执行这些操作。

与一次性磁盘一样，一旦配置了桌面池，持久磁盘无法禁用或启用。在初始配置之后，也无法通过 View Manager 图形用户界面更改其大小。但是，如果管理员更改了桌面池设置，则可以更改新配置虚拟桌面上的持久磁盘大小。

配置持久磁盘时，应确保磁盘大小足以满足用户的需求。如果未使用 Active Directory 文件夹重定向或 VMware View 用户配置管理，用户配置文件的大小可能会达到几个 GB。

一般来说，如果使用了用户配置管理或 Windows 漫游配置文件，请确保磁盘足够大，以容纳用户的漫游配置文件，或者为漫游配置文件应用配额。

以下截图展示了桌面池配置过程中持久磁盘选择界面。它显示了 View 管理控制台中持久磁盘的配置：

在 Windows 操作系统中，持久磁盘和一次性磁盘可以在 Windows 资源管理器中看到。重要的文件夹会被锁定，用户无法删除它们。但是，通过使用 Windows 组策略，仍然可以隐藏驱动器，同时使其可用。

以下截图展示了在客户端虚拟桌面中看到的各种磁盘：

持久磁盘的驱动器字母在桌面池配置过程中选择，其内容与以下截图类似。在用户文件夹中，可以找到配置文件文件夹和设置：

存储超额承诺

随着链接克隆技术的引入以及能够指定每个虚拟桌面刷新或重建的时间，提供了一个机会，可以指定应过度分配多少存储，以帮助减少存储消耗。

假设并非每个虚拟桌面都会同时使用全部分配的存储空间，从而为存储利用率和过度分配（超额承诺）留下空隙。

在桌面池配置过程中，管理员可以选择“注销后刷新操作系统磁盘”，并提供以下选项之一：

• 从不： 如果选择了从不选项，则虚拟桌面将永远不会执行增量磁盘刷新操作。增量磁盘将随着每个块的变化增长，直到达到磁盘本身的限制。如果为虚拟桌面定义的磁盘大小为 40 GB，则这是限制。当达到 40 GB 时，vSphere VMFS 将开始重新利用块，就像它对全克隆一样。在这种情况下，你不会耗尽磁盘空间。

• 始终： 如果使用始终选项，那么每次用户从桌面注销时，虚拟桌面都会被刷新。假设在使用过程中，增量磁盘只增加了几 GB，它们将在虚拟桌面刷新时被恢复。

• 每 x 天： 如果选择了每 x 天选项，则虚拟桌面将在定义的天数内刷新，无论增量磁盘的利用率如何。增量文件会随着时间的推移而增长，基于包括 Windows 和应用程序在内的多个因素。因此，在选择此选项时，了解增量在此期间可能达到的大小非常重要，以便能够相应地调整数据存储的大小。

• 在 y 百分比的磁盘利用率下： 如果选择了在 y 百分比的磁盘利用率下选项，且 y 设置为 50%，则当增量占用的存储空间达到总分配存储的 50% 时，虚拟桌面将会刷新。此计算不包括额外的磁盘，如持久磁盘或一次性磁盘。如果虚拟桌面的总磁盘大小为 40 GB，则当用户注销时，且增量磁盘利用率达到或超过 20 GB 时，刷新操作将会执行。

一个重要的方面需要记住的是，链接克隆在启动时只有其完整配置大小的一小部分。通过刷新操作，VMware View Composer 提供的存储容量节省使管理员能够决定在存储完全占用之前，如何利用可用的存储容量。举个例子，选择了始终选项的管理员知道，在业务时间段内，增量文件平均将增长至 300 MB。

基于存储利用率，可以强制每个数据存储上放置更多的虚拟桌面，相较于全克隆虚拟桌面，这样做是可行的。这被称为存储超额提交级别。

注意

VMware View 不允许管理员配置每个数据存储的最大链接克隆数量，桌面数量的限制来自于数据存储的大小。为支持所需的桌面数量，同时符合 VMware View 和 View Composer 的最大值和限制，正确设置数据存储的大小至关重要。

通常，超额分配级别是根据虚拟桌面的使用方式来定义的。如果具有浮动分配的桌面池中的桌面在注销后设置为始终刷新，存储消耗将较低，您可以将超额分配设置为激进。然而，如果虚拟桌面不经常刷新，您可能更倾向于将其设置为保守。

存储超额分配级别选项

可以为不同类型的存储池定义不同的超额分配级别，以应对提供的容量、性能或可用性不同的需求。例如，NAS 存储池的超额分配级别可能与 SAN 存储池不同；同样，SSD 存储池的超额分配级别可能与 FC 存储池不同。

选项	存储超额分配级别
无	存储没有超额分配。
保守	存储池大小的四倍。这是默认级别。
中等	存储池大小的七倍。
激进	存储池大小的十五倍。

注意

推荐的做法是始终将 vSphere 存储池与 LUN 或导出进行一一对应。管理员应避免使用由多个存储池支持的大型存储 LUN。

根据存储超额分配级别，每个存储池中链接克隆的数量是基于父虚拟机的大小。以一个 30 GB 的虚拟机和 200 GB 的存储池为例，VMware View 大约可以容纳 6 个完全克隆的虚拟桌面。然而，如果使用超额分配级别为 7（中等），VMware View 大约可以容纳 42 个桌面。

虚拟机大小 (GB)	存储池大小 (GB)	超额分配级别	完全克隆虚拟机数量	链接克隆虚拟机数量
30	200	4	6	24
30	200	7	6	42
30	200	15	6	90

注意

可能会耗尽存储容量。当存储池中的可用存储空间不足时，VMware View 将无法提供新的桌面，然而，现有的链接克隆桌面会继续增长，最终填满存储池。此情况在超额分配级别设置为激进时更为常见。

为确保链接克隆不会耗尽磁盘空间，管理员应定期刷新或重新平衡桌面池，将链接克隆的占用空间减少到原始大小。

以下截图演示了桌面池配置或配置过程中存储超额分配的选择：

存储协议

VMware View 由 VMware vSphere 支持，因此支持多种存储协议来存储数据。VMware vSphere 可以使用光纤通道（Fiber Channel）、iSCSI、以太网光纤通道（FCoE）和 NFS。

VMware View 协议选择的主要考虑因素包括最大吞吐量、VMDK 行为以及重新使用现有存储基础设施与采购新存储基础设施的成本。这些因素会影响网络设计和性能。

本节的目的不是涵盖每种协议或它们在 VDI 环境中的表现。以下表格中的数字基于 VMware View 5 和 vSphere 5，旨在帮助决策使用的存储协议：

	光纤通道	iSCSI	FCoE	NFS
类型	块	块	块	文件
VAAI	是	是	是	是
传输速率	4 Gbps 或 8 Gbps	多条 10 Gbps	多条 10 Gbps	多条 10 Gbps
每个主机的最大数量	8	8	8	8
每个主机的 LUN/导出数量	256	256	256	256
每个数据存储的克隆数量	64 至 140	64 至 140	64 至 140	未验证

最大值和限制

设计大规模 VMware View 解决方案是一项复杂的任务。如果未遵循 VMware 验证的最大值和限制，小规模部署可能也会面临与大规模部署相同的挑战。

注意

在规划 VDI 环境时，建议采取保守的方式。

有一些工具可以帮助管理员从图形、CPU、内存和存储的角度了解需求和限制。其他工具则有助于根据虚拟桌面数量、平均 IOPS、内存大小、共享内存百分比、已用内存百分比、读写 IOPS 百分比等来计算基础设施的规模。

无论这些工具提供什么结果，VDI 架构师应始终确保这些数字在 VMware vSphere 和 VMware View 的最大值和限制范围内。

每个数据存储（VMFS）最多可链接 64 至 140 个克隆

对于支持 vStorage API 用于阵列集成（VAAI） 的 FC 阵列，每个数据存储最多可链接 140 个克隆。增加每个数据存储中虚拟桌面数量的 VAAI 原语称为 硬件辅助锁定 或 原子测试与设置（ATS）。

vSphere VMkernel 必须为涉及存储在 VMFS 中的虚拟桌面的操作更新 VMFS 元数据。元数据的更新发生在启动/关闭虚拟桌面、挂起/恢复虚拟桌面以及其他各种操作时。

在 VDI 环境中，这意味着 VMkernel 可能需要为数百个虚拟桌面更新元数据，因此必须锁定整个 VMFS 才能更新其元数据，即使只为启动一个虚拟桌面。这一操作所需的时间通常不超过几毫秒，但在同时启动多个虚拟桌面时就会变得有问题。

硬件辅助锁定（vSphere 4.1 及兼容的供应商阵列代码提供）允许 VMkernel 在存储阵列上的 VMFS 中按块级别锁定元数据，并允许在 VMFS 内同时进行多个操作，这反过来允许多个桌面虚拟机同时启动。

每个数据存储（NFS）支持 250 个关联克隆。

对于由网络文件系统（NFS）支持的数据存储，每个数据存储上的虚拟桌面数量没有限制，因为 NFS 不涉及相同的 SCSI 预留问题。然而，至今没有来自 VMware 的官方验证，说明单个由 NFS 支持的数据存储可以托管的最大虚拟桌面数量。目前的建议是将每个 NFS 数据存储上的虚拟桌面数量保持在 250 个以下。

每个数据存储（VMFS）可支持 32 个完整克隆桌面。

如果能回答每个文档中最大值和限制的“为什么”问题，那就好了。某些广为人知的限制要么基于质量保证测试，要么基于现场经验。其他一些限制则基于以前技术设定的最佳实践，但由于缺乏额外的测试，这些限制仍然有效。

我们试图理解使用完整克隆时 32 个虚拟桌面限制的来源，VMware 给出的回答是没有明确的答案，除了说明这个限制基于服务器工作负载、SCSI 预留以及存储管理员未能做好基础设施规划。

如果这个限制是针对虚拟服务器工作负载设定的，它可能是在存储架构没有像高级缓存和 VAAI 支持等功能的年代设定的。

使用 View Composer 的每个 vSphere 集群最多支持 8 个主机。

如果集群中使用 View Composer 的主机数超过 8 台，VMware View 将停止提供新的虚拟桌面。这个行为是硬编码到 View Composer 中的。然而，限制的根源在于 VMFS 层。

VMFS 结构仅允许最多 8 个主机访问单个 VMDK 文件进行读写。在关联克隆实现中，集群中的所有主机可能都在读取来自同一副本磁盘的存储块。

注

在撰写本文时，VMware 正在验证每个 vSphere 集群最多支持 16 个主机与 View Composer 配合使用。

每个副本支持 1,000 个克隆。

每个副本的克隆数量还决定了单个桌面池中可以共存的关联克隆数量。这个数字来源于 VMware 的质量保证验证实验室，然而这是一个软性限制，尽管不推荐，但可以增加。

在以前的版本中，VMware View 验证的限制是每个副本或桌面池支持 512 个虚拟桌面。这个限制是由于每个数据存储最大支持 64 个关联克隆，再乘以每个 vSphere 集群支持 8 个主机得出的（64 * 8 = 512）。

存储 I/O 配置文件

每个虚拟桌面产生的 I/O 存储配置完全依赖于所使用的 Windows 操作系统类型、部署的应用程序，甚至每个用户如何单独与环境进行交互。

IOPS（发音为eye-ops）是用于衡量计算机存储设备（如硬盘驱动器（HDD）、固态硬盘（SSD）和存储区域网络（SAN））性能的常见指标。与任何基准测试一样，存储设备制造商发布的 IOPS 数字并不能保证实际应用性能。

根据 Wikipedia，预测平均虚拟桌面 I/O 配置可能会是什么是设计 VDI 解决方案时最困难的任务之一。原因在于缺乏关于在设计时每个虚拟桌面上运行的工作负载的信息。

可以使用预设的趋势数字作为基准；然而，尽管这些数字表明工作负载可能是什么，在某些情况下，它们可能会偏离曲线。

在理想的情况下，VDI 试点项目已经运行了一段时间，可以适当收集和趋势化数据。

几个指标必须考虑进去，以正确配置存储。它们如下：

• 存储大小： 需要多少存储容量？

• LUN 大小： 需要多少个 LUN 和/或数据存储？

• 层级类型： 需要什么类型的磁盘以及磁盘的放置位置？

• IOPS（cmd/s）： 每秒 I/O 命令的数量是多少？

• 读写比例： 读写比例是多少？

列表中的前三项可以在无需深入了解 I/O 工作负载的情况下进行计算；然而，这需要了解虚拟桌面存储容量的利用情况。

实际问题在于每秒 I/O 量和读/写 I/O 模式。如果没有这些数值，存储架构师/管理员可能无法为虚拟桌面基础设施提供所需的性能存储。

IOPS，也被称为磁盘 I/O 配置，对于每种 Windows 操作系统类型来说是不同的。这个配置还依赖于部署的应用程序的类型和数量，包括操作系统中运行的服务。I/O 配置还与用户如何与虚拟桌面进行交互有关。VMware 和合作伙伴已验证可用作基准的 I/O 配置。强烈建议你找出适合你的特定 VDI 环境的正确 I/O 配置。

VMware View 文档确立了一些 I/O 基准：

• 轻度（5 IOPS）： 轻度用户通常在正常工作日使用电子邮件（Outlook）、Excel、Word 和网页浏览器（Internet Explorer 或 Firefox）。这些工作者通常是数据输入操作员或文职人员。

• 重度用户（15 IOPS）： 重度用户是全职知识工作者，使用所有轻度工作者的工具（Outlook, Excel, Word, Internet Explorer 和 Firefox），同时还处理大型 PowerPoint 演示文稿和执行其他大文件操作。这些工作者包括商业经理、主管和营销团队成员。

由 PQR 顾问公司（Herco van Brug）进行的另一项研究展示了 I/O 配置文件，如下所示：

	Windows XP	Windows 7
轻度	3 到 4	4 到 5
中度	6 到 8	8 到 10
重度	12 到 16	14 到 20

VDI & Storage Deep Impact v1-25 hot! 文章可以在www.virtuall.nl/whitepapers/solutions找到。

通常会讨论每个虚拟桌面的平均 IOPS；然而，在规划 VDI 解决方案时，至关重要的是也要考虑到性能高峰。否则，存储基础设施将承受巨大的压力，无法提供所需的 IOPS 和吞吐量。

在启动和登录风暴等常见场景中，需要高性能和高吞吐量。例如，Windows 7 桌面在启动时可以产生高达 700 IOPS。另一个很好的例子是，如果“注销时刷新”选项与浮动池结合使用，当商业用户开始注销时，在工作班次结束时常常会出现利用率的高峰。

现在，我们有一个现有的范式，从成本角度来看，存储基础设施应该根据时间的平均性能需求来规划，但从性能角度来看，它应该根据这些高峰来规划。因此，存储供应商实施了他们自己的专有缓存解决方案，以优化存储阵列以应对高峰但波动的 VDI I/O 需求。

大多数发布的架构文档或白皮书会展示这些数字的差异。如果你想在试点阶段进行自己的 I/O 基准测试，可以使用存储阵列管理工具、VMware vCenter 客户端或工具，例如 vscsiStats，这将为你提供更详细的概览。

读写 I/O 比率

读写 I/O 比率将决定支持 VDI 工作负载所需的磁盘数量，特别是在 RAID 配置中。现在我们将了解，理解读写 I/O 比率对管理员合理规划存储阵列至关重要，既从前端（存储处理器）角度，也从后端（磁盘）角度。

在上一个话题中，我们讨论了虚拟桌面在启动、登录和稳定状态下产生的总 IOPS。IOPS 可以是读取或写入。每次读取磁盘块时，我们就有一个读 I/O，每次写入磁盘块时，我们就有一个写 I/O。

Windows 操作系统本身就非常依赖 I/O，而且大多数 I/O 都是写入 I/O。这其实是一个非常有趣的主题。在工作负载模拟过程中，可以发现 Windows 总是发出更多的写入而不是读取 I/O。然而，最有趣的事实是，即使 Windows 处于空闲状态，它仍然会产生更多的写入而非读取 I/O。

由 PQR 咨询公司（Herco van Brug）进行的同一项研究指出：

“客户端产生的 IOPS 数量很大程度上取决于用户和他们的应用程序。但平均而言，所需的 IOPS 数量大约是每个客户端 8 到 10 次，在 40/60% 到 20/80% 的读写比例下。对于 XP，平均值接近 8；对于 Windows 7，接近 10，假设基本映像已经优化到尽可能少地依赖自身，所有 I/O 都来自应用程序，而非操作系统。”

在 Andre Leibovici 进行的一项实验中，他在他的博客 myvirtualcloud.net/?p=2138 中发布了实验结果，可以清晰地识别出与登录 VSI 工作负载生成过程中的读取 I/O 相对的高强度写入 I/O 模式。

以下屏幕截图展示了在 myvirtualcloud.net/ 进行的 I/O 测试：

VMware View 参考架构文档为我们提供了以下的读写比例：70/30、60/40 和 50/50。然而，VDI 工作负载中看到 10% 读取和 90% 写入的情况并不罕见。

下图展示了来自真实生产数据的读写比例示意图：

我们如此关注 I/O 模式的原因是它决定了支持 VDI 工作负载所需的磁盘数量。虽然有许多专有技术能够减少 I/O 对物理磁盘的影响，但计算所需每秒输入输出次数（IOPS）的方法不会改变。

在许多情况下，架构师会被要求设计一个解决方案，而不知道 I/O 配置会是什么样子。对于大多数情况，都会有一个持续进行的试点。组织通常在进行试点之前就想了解成本，这也是为什么猜测 IOPS 会成为一个困难任务的原因。如果所有组织首先进行一个小型试点，然后决定购买支持 VDI 解决方案的整个基础设施，那我们将生活在一个理想的世界里。

如果你在没有 I/O 配置知识的情况下设计 VDI 架构，你应该非常保守，以避免存储方案不足。如果是这种情况，你应该为所有虚拟桌面使用重型 I/O 配置，读写比例为 20 次读取和 80 次写入。希望你不会遇到这种情况。

选择的 RAID 类型将根据 IOPS 和读/写比率决定支持工作负载所需的性能和硬盘数量。在确定存储基础设施的规模时，选择的 RAID 组会因需要对数据进行条带化并在磁盘驱动器上记录奇偶校验而增加写入性能损失。不同类型的 RAID 组对读取 I/O 没有性能损失。

在 VDI 工作负载中最常用的 RAID 类型是 RAID 5、6 和 10：

• RAID 10 增加了 2 倍的写入性能损失

• RAID 5 增加了 4 倍的写入性能损失

• RAID 6 增加了 6 倍的写入性能损失

前述数字可以按如下方式表格化：

	I/O 影响
RAID 级别	读取	写入
RAID 0	1	1
RAID 1 (和 10)	1	2
RAID 5	1	4
RAID 6	1	6

注意

可以说，对于 RAID 10，读取的影响为 0.5，因为 Windows 操作系统能够同时从两个磁盘读取相同的块，或者读取一个磁盘的一半和另一个磁盘的一半。因此，我们可以获得两倍的读取性能。

计算这些性能损失时常用的公式如下：

虚拟机 I/O = 虚拟机读取 I/O + （虚拟机写入 I/O * RAID 性能损失）

架构 VDI 解决方案时的另一个重要信息是，Windows 操作系统主要有小的随机 I/O。Jim Moyle 在他的论文Windows 7 IOPS for VDI: Deep Dive中，提供了 Windows 生成小 I/O 的特性，地址为jimmoyle.com/wordpress/wp-content/uploads/downloads/2011/05/Windows_7_IOPS_for_VDI_a_Deep_Dive_1_0.pdf：

“这是由于 Windows 内存的工作原理，内存页的大小为 4K，因此 Windows 会将文件以 4K 块加载到内存中，这意味着大多数读取和写入活动具有 4K 的块大小。Windows 7 确实尝试将顺序写入聚合到较大的块大小，以使写入过程更加高效。它会尝试将写入合并为最多 1MB 的大小。这样做的原因是，Windows 期待一个本地的专用磁盘，旋转磁盘在写入大块时表现得非常好。”

Windows 操作系统不断以不同的磁盘布局读取和写入信息，而本地用户交互也是造成这种行为的另一个原因。随机访问小块对于机械硬盘来说是一个费时的任务，每个硬盘每秒的操作次数（IOPS）非常有限。因此，使用 RAID 组来实现所需的 I/O 吞吐量非常重要。

SSD 提供了卓越的读取性能，但也在小的随机写入 I/O 上存在局限性。尽管如此，它们相较于磁盘驱动器提供了更好的性能，代价则高得多。

以下图示展示了顺序访问和随机访问之间的区别：

存储分层和 I/O 分配

在本章之前，我们讨论了 VMware View 分层存储及将不同的存储数据存储或导出分配到不同类型磁盘的功能。现在，我们将从 I/O 角度讨论这些存储层如何与存储基础设施进行交互。

VMware View 4.5 引入了选择专用数据存储的功能，其中存储副本磁盘。VMware View 架构指南建议，该数据存储应由一组 SSD 提供支持。SSD 通常提供更高的每秒输入/输出次数和更高的吞吐量。

如前所述，需要高性能和高吞吐量的常见场景包括启动和登录风暴，以及大规模应用程序部署或 AV 更新。例如，Windows 7 在启动时可能会生成多达 700 IOPS。另一个好例子是，如果在浮动池中使用“注销时刷新”选项，通常可以看到在工作班次结束时，业务用户开始注销时，资源利用率会出现高峰。

虚拟桌面生成的总 IOPS 量是由副本磁盘中的读 I/O 数量加上所有其他磁盘上的读写 I/O 数量组成的。在不同的使用阶段，虚拟桌面的表现不同，并且每个独立存储层所需的 I/O 数量和读写 I/O 模式也各不相同。

了解开机、定制化和首次启动所需的 I/O 数量的最佳方式是找到每个数据存储的平均最大 I/O。原因是每个存储层的性能要求不同。

下图是一个示例，展示了 IOPS 分解。它演示了虚拟桌面从第一次开机到首次启动所生成的 IOPS 数量。涉及的操作如下：

1. 开机。

2. 自定义。

3. 首次启动。

前述图表中的相同数字可以按每个存储层的百分比样式进行展示。下图显示了一个表格，可以清晰地展示虚拟桌面在创建过程中的运行情况：

注意

重要提示：请记住，这些数字在您的 VDI 环境中可能完全不同。

了解有多少虚拟桌面将同时启动、登录或工作，对正确设计支持副本磁盘的存储层至关重要。如果选择了专用副本数据存储选项，则更为关键的是，支持副本磁盘的这一单一磁盘存储层能有效提供所需的性能，考虑到最多有 1,000 个虚拟桌面可能同时使用该单一副本磁盘。

下图是一个示例，展示了使用专用副本数据存储选项的情况：

获取每个存储解决方案层级所需的精确 IOPS 数量可能是一项繁重的任务。为了让你了解这项工作可能有多复杂，假设一个链接克隆虚拟桌面使用了一个一次性磁盘和一个持久磁盘。假设复制磁盘托管在专用的复制数据存储区，链接克隆和一次性磁盘托管在另一个数据存储区，而持久磁盘托管在另一个数据存储区。以下图示展示了这一场景。这是一个展示在使用 VMware View 各种虚拟磁盘时 I/O 分解的示意图：

如前图所示，在这个场景中，虚拟桌面生成了 30% 的读取 I/O 和 70% 的写入 I/O。假设虚拟桌面的总 I/O 为 20，那么我们有 6 个读取 I/O 和 14 个写入 I/O。

我们知道复制磁盘是 100% 读取的；然而，除非仔细检查复制磁盘，否则无法知道 14 个读取 I/O 中有多少实际上是对磁盘发出的。读取 I/O 也可能是发往链接克隆、一次性磁盘或持久磁盘的。

对于支持链接克隆和一次性磁盘的层级，以及支持持久磁盘的层级，我们也会有不同数量的读取和写入 I/O，这些 I/O 仅占虚拟桌面生成的 6 个读取 I/O 和 14 个写入 I/O 的小部分。

如你所见，虚拟桌面产生的总操作次数通常会分布在多个层级和数据存储区之间。收集这些数据的最佳时机是 VDI 测试阶段。VMware 提供了完成这项工作的理想工具：esxtop 和 vscsiStats。

事实是，除了分析现有环境的使用模式之外，没有什么神奇的公式可以帮助你得到精确的 I/O 配置。规划你的存储时要关注性能，并在可能的情况下利用实际的工作负载数据来计算环境。来自白皮书和参考架构指南的预趋势数据可能会为你提供一个基准；然而，它们可能并不适用于你的工作负载，最终你可能会得到一个过小或过大的基础设施。

计算 IOPS 的最常见公式如下：

复制层级（仅读取 I/O）= (并发启动虚拟机数 * 峰值启动 IOPS) + (并发虚拟机数 - 并发启动虚拟机数) * (复制稳态 IOPS)

所有其他层级 = (VM 读取 I/O + (VM 写入 I/O * RAID 惩罚) * 并发虚拟机数)

来自 Citrix 的 Paul Wilson 创建了一个引人注目的复杂模型，基于峰值 IOPS、稳态 IOPS 和估算的启动 IOPS，这个模型考虑了启动速率和桌面登录时间。他的文章可以在 blogs.citrix.com/2010/10/31/finding-a-better-way-to-estimate-iops-for-vdi 中找到。

磁盘类型

一个常见的问题是关于应该为每个存储层使用哪种类型的磁盘。这是一个复杂的问题，您需要与存储管理员或供应商讨论。大多数智能存储阵列提供某种加速或缓存机制，这可能会减少存储后端的要求。随着要求的降低，可以使用容量更大、性能较低的磁盘。

以下图表展示了存储提供商通常使用的虚拟磁盘与磁盘类型之间的关系：

VMware View 部署中最常用的磁盘类型如下：

• 固态硬盘（SSD）： 它们提供最佳的吞吐量性能，可用于需要在启动和登录风暴期间进行爆发性扩展的副本层。

• 光纤通道和 SAS： 它们提供了最佳的成本与性能关系。如今，光纤通道和 SAS 磁盘可能是企业环境中最常见的磁盘类型，并且可以用于托管链接克隆磁盘。

• 串行先进技术附件（SATA）： 它们提供了最高的容量和最低的成本，但性能最差。SATA 磁盘的常见用途是持久存储或用户配置文件磁盘的放置。

需要注意的是，这些只是常规建议，您的环境可能会面临不同的挑战或具有不同的特性。例如，一些扩展型 NAS 设备可能使用非常大的 SATA 磁盘池，并且在吞吐量方面与光纤通道磁盘表现相当。

容量配置练习

正确配置存储基础设施可能是 VDI 部署成功或失败的关键。许多在试点和初始生产阶段表现出色的部署，随着时间的推移，因为对存储层理解不足，迅速遇到存储竞争问题。

在下一节中，我们展示了一些适用于不同 VMware View 实现的配置练习。

配置完整克隆

让我们看两个完整克隆配置的场景。

场景 1

以下是参数：

• 桌面： 1,000

• 池类型： 专用（完整克隆）

• 客户操作系统： Windows 7

• 内存： 2 GB

• 磁盘大小： 40 GB

• 已使用磁盘： 22 GB

• 开销： 10%

父虚拟机

父虚拟机可以是精简配置或厚配置，通常在关闭状态。如果父虚拟机是厚配置，则其大小类似于创建磁盘时加上日志文件的大小。例如，如果父虚拟机的磁盘大小设置为 40 GB，则这是父虚拟机的近似大小。

如果父虚拟机是使用精简配置创建的，则其大小等于 Windows 操作系统在 NTFS 文件系统和日志文件中所占用的存储空间。例如，如果父虚拟机的磁盘大小设置为 40 GB，但只使用了 10 GB，则父虚拟机的总大小大约为 10 GB 加上日志文件。

对于父虚拟机，使用厚配置比薄配置没有显著的性能提升，因为这些是母盘镜像，除非需要新的副本磁盘，否则不会被使用。

开销

VMware 关于每个数据存储开销的建议是至少 10%。

以下表格解释了特性和要求：

特性	要求	理由
每个数据存储的虚拟机数量	32 VMFS	每个数据存储的完整克隆推荐限制
虚拟机数据存储大小		基于以下计算的大小：
		原始文件大小
		日志文件大小
		交换文件大小
		空闲空间分配
		最小分配的数据存储大小 = (虚拟机数量 * (原始文件 + 交换文件 + 日志文件 + 开销)) = (32 * (40,960 MB + 2,048 MB + 100 MB) + 137 GB) = 1.44 TB
数据存储数量	每 32 个虚拟桌面 1 个	每个数据存储的虚拟机/虚拟机数量 = 1,000/32 = 32
总存储		数据存储数量 * 数据存储大小 = 32 * 1.44 TB = 46 TB

评论

以下是评论列表：

• 作为安全数值，假设所有完整克隆原始文件最终将达到完整大小（40 GB）。一些管理员可能会选择使用较小的存储大小来降低计算时的存储成本。

• 除了支持所有完整克隆虚拟桌面所需的存储分配外，重要的是每个 VMware View 集群至少预留一个数据存储，用于托管父虚拟机和 ISO 镜像。

场景 2

这是参数：

• 桌面数量： 2,000

• 池类型： 专用（完整克隆）

• 客户操作系统： Windows 7

• RAM： 2 GB

• 磁盘大小： 32 GB

• 磁盘消耗： 22 GB

• 虚拟机内存保留： 50%（1,024 MB）

• 开销： 10%

以下表格展示了特性和要求：

特性	要求	理由
每个数据存储的虚拟机数量	32 VMFS	每个数据存储的完整克隆推荐限制
虚拟机数据存储大小		基于以下计算的大小：
		原始文件大小
		日志文件大小
		交换文件大小
		空闲空间分配
		最小分配的数据存储大小 = (虚拟机数量 * (原始文件 + 交换文件 + 日志文件 + 开销)) = (32 * (40,960 MB + 1,024 MB + 100 MB) + 108 GB) = 1.13 TB
数据存储数量	每 32 个虚拟桌面 1 个	每个数据存储的虚拟机/虚拟机数量 = 2,000/32 = 33
总存储		数据存储数量 * 数据存储大小 = 32 * 1.12 TB = 36 TB

评论

以下是评论列表：

• 本场景的磁盘大小已更改为 32 GB，从而减少了所需的整体存储占用。为虚拟桌面选择合适的大小非常重要，确保满足用户需求，而不是为基础设施添加额外的负担。

• 此场景引入了 50% 的虚拟机内存保留，从而将 .vswp 文件的大小减少为虚拟桌面内存的一半。在此场景下，.vswp 文件大小为 1,024 MB。

链接克隆大小计算

链接克隆虚拟桌面的大小计算在某种程度上比全克隆更复杂，因为涉及的变量较多。正如本章之前所提到的，链接克隆虚拟桌面引入了新的文件，并且在选择“专用副本数据存储”选项时可能会有不同的工作方式。

母体虚拟机

与全克隆使用的母体虚拟机类似，链接克隆所用的母体虚拟机也包括了由 View Composer 用来确定用于创建副本磁盘的基准映像的虚拟机快照。

副本

副本磁盘是从母体虚拟机创建的精简配置克隆。如果母体虚拟机的磁盘大小设置为 40 GB，则副本的大小等于 Windows 操作系统在 NTFS 上使用的存储量，再加上所选择的快照大小。例如，如果母体虚拟机的磁盘大小设置为 40 GB，但仅使用了 10 GB，则副本的总大小大约为 10 GB。

如果不使用“专用副本数据存储”选项，对于任何桌面池，都会在分配给池的每个数据存储中创建一个独立的副本。如果在桌面池中使用了多个快照，VMware View 可能会决定使用数据存储，并在每个数据存储中创建多个副本。在一个数据存储中同时使用两个或更多快照是常见的，尤其是在重新组合操作期间。

桌面池 * 快照 * 数据存储 = 副本数量

2 * 1 * 32 = 64 个副本（每个数据存储 2 个）

2 * 2 * 32 = 128 个副本（每个数据存储 4 个）

如果启用了“专用副本数据存储”选项，VMware View 将使用一个单独的数据存储来为桌面池创建所有副本。副本数量的计算还受到同时使用的快照数量的影响。

桌面池 * 快照 * 数据存储 = 副本数量

2 * 1 * 1 = 2 个副本

2 * 2 * 1 = 4 个副本

场景 1

以下是参数：

• 桌面数量： 5,000

• 池类型： 浮动（链接克隆）

• 客户操作系统： Windows 7

• 内存： 2 GB

• 磁盘大小： 32 GB

• 磁盘消耗： 22 GB

• 注销时刷新： 10%

• 开销： 10%

• VAAI： 已启用

下表解释了特性和要求：

特性	要求	理由
每个数据存储的虚拟机数量	140 VMFS (VAAI)	每个数据存储的全克隆推荐限制
VM 数据存储大小		基于以下计算的大小：
		原始文件大小
		日志文件大小
		交换文件大小
		空闲空间分配
		最小分配的数据存储大小 = (虚拟机 * (原始 + 交换 + 日志) + 开销) = (140 * (3,277 MB + 1,024 MB + 100 MB) + 60 GB) = 661 GB
数据存储数量	每 140 个虚拟桌面 1 个数据存储	每个数据存储的虚拟机数量 = 5,000/140 = 36
总存储		数据存储数量 * 数据存储大小 = 36 * 661 GB = 23 TB

注释

以下是注释列表：

• 桌面池类型为浮动，这意味着每当用户注销时，虚拟桌面将会被刷新。这里重要的信息是，平均来说，用户会在虚拟桌面上保持连接多长时间，以及在使用过程中增量磁盘上会产生多少数据。

  如果桌面被分配给持续 45 分钟的课程，增量磁盘的增长可能非常有限。然而，如果虚拟桌面整天使用，增量磁盘的大小可能会增长到几百兆字节。

  对于这个练习，我们假设增量磁盘将增长到父虚拟机最大大小的 10%，即 3,277 MB。

• 在此场景中启用了 VAAI，这将提高每个数据存储的虚拟桌面整合度。支持 VAAI 的每个数据存储最大可支持 140 个虚拟桌面。

场景 2

以下是参数：

• 桌面： 10,000

• 池类型： 持久性（链接克隆）

• 客户操作系统： Windows 7 (64 位)

• RAM： 4 GB

• 磁盘大小： 32 GB

• 磁盘占用： 22 GB

• 刷新： 永不

• 开销： 10%

以下表格解释了功能和要求：

功能	要求	解释
每个数据存储的虚拟机数量	100 VMFS	推荐的每个数据存储的完整克隆数量限制
		基于以下计算的大小：
		原始文件大小
		日志文件大小
		交换文件大小
VM 数据存储大小		空闲空间分配
		最小分配的数据存储大小 = （虚拟机 * （原始 + 交换 + 日志）+ 开销）= （100 * （32,768 MB + 4,096 MB + 100 MB）+ 360 GB）= 3.9 TB
数据存储数量	每 100 个虚拟桌面 1 个数据存储	每个数据存储的虚拟机数量 = 10,000/100 = 100
总存储		数据存储数量 * 数据存储大小 = 100 * 3.9 TB = 390 TB

注释

这个场景探讨了使用链接克隆，但没有内部策略来频繁刷新虚拟桌面。结果类似于实现完整克隆，因为增量磁盘将增长到其最大容量，在这种情况下为 32 GB。

使用 64 位 Windows 7 和 4 GB 内存，并且没有虚拟机内存预留时，交换文件会消耗每个虚拟桌面 4 GB 的存储容量。总的来说，.vswap 文件将占用 40 TB 存储空间；然而，如果内存预留仅为 20%，则总存储使用量将降至大约 31 TB。

vSphere 5.0 视频交换

VMware View 一直会根据分辨率和颜色深度自动计算视频内存。直到 VMware View 4.6 版本，仅支持 24 位颜色深度，并且 VMware 发布了每种分辨率类型所需的 vRAM 开销。vRAM 开销是运行在 ESXi 上的虚拟机的 VM 内存开销的一部分。另一个开销部分来自 vCPU 的数量和 RAM 的数量。

VMware View 5.0 引入了 32 位颜色深度，并将其设置为默认选项。除此之外，为了支持 3D，VMware 在 View 5.0 中引入了一个新功能，允许管理员选择应该为虚拟桌面分配多少视频内存。

以下截图展示了需要 3D 功能的虚拟桌面 vRAM 的配置：

VMware View 关于如何配置 vRAM 以支持 3D 的解释并不十分有用，本质上说的是：vRAM 越多，虚拟桌面能够提供的 3D 性能就越高。

为了支持新的 3D 选项，vSphere 5.0 为每个使用硬件版本 7 或 8 创建的虚拟桌面实现了第二个.vswp文件。这个第二个.vswp文件专门用于视频内存开销，当虚拟桌面在视频资源受限时将使用该文件。

以下截图展示了第二个.vswp文件；该文件用于视频内存：

总内存开销由以下因素定义：

• 虚拟 CPU 数量

• RAM 数量

• vRAM 数量（由显示器数量、屏幕分辨率和颜色深度定义）

• 3D 支持

内存开销对 VMware 管理员来说并不新鲜，因为他们过去会根据 vCPU、RAM 和 vRAM 来计算开销。然而，随着视频内存计算器的引入，vSphere Client 5.0 提供了一种简便的方法来定义给定视频配置所需的 vRAM 数量。

以下截图展示了高级视频内存计算器：

新的视频开销.vswp文件将影响存储占用和数据存储的大小。为了理解其实际影响，我们对新的视频支持选项进行了逆向工程。swap (MB)列展示了视频交换文件所使用的总存储空间，而overhead (MB)列展示了每个 vCPU、vRAM 和颜色深度组合所使用的内存开销：

注意

当启用 3D 支持时，会向第二个.vswp文件中添加 256 MB 的开销。因此，如果计划使用 3D，应该适当地调整数据存储，以适应这一差异。这个额外的 256 MB 将帮助虚拟桌面在执行 3D 显示操作时避免出现视频性能问题。256 MB 的开销与在 VMware View 5.0 中分配给虚拟桌面的 vRAM 数量无关。

启用 3D 支持后，包含 100 个桌面的数据存储将需要额外 25 GB 的空间：

100 台虚拟机 * 256 MB = 25 GB

以下截图展示了启用 3D 支持后 .vswp 文件（交换文件）的表格：

在进行 3D 支持的容量规划时，你需要确保数据存储空间足够大，能够容纳所有虚拟桌面，以及任何额外的 3D 交换空间开销。

总结

虚拟化环境的存储从设计角度已经具有相当的复杂性。通过在传统的服务器虚拟化解决方案上增加 VDI，可能会使用的额外存储技术（例如，View Composer），使得存储设计的复杂度呈指数级增加。本章涵盖了 VMware View 解决方案存储设计的高层次方面，以及那些常常决定一个解决方案成败的细微差别。存储设计，特别是针对那些打算随着时间推移扩展的解决方案，可能需要大量的努力。在开始 VMware View 存储设计之前，理解基本的存储原则非常重要，同时还需要理解各种类型的虚拟磁盘，以及底层虚拟机如何使用其磁盘。

现在所有主要的设计概念已经覆盖，下一章将重点讨论备份和恢复。虽然一个强健的 VMware View 解决方案应该能够减轻大多数停机场景，但也有可能在某些情况下需要采取恢复措施；因此，在设计实施并交接给运营团队时，从备份角度理解相关要点以及恢复过程非常重要。

第九章：安全

无论是部署在医院、大学、公司、联邦机构还是非营利组织，终端设备的安全性已成为任何组织的数据丢失防护和信息保障政策的关键组成部分。例如，像维基解密事件或像美国人口普查局、爱尔兰社会与家庭事务部、安海斯·布希等组织丢失带有社会安全号码的笔记本电脑等数据丢失事件，确保敏感数据始终处于公司基础设施的范围内已经引起了广泛关注。

在传统的物理桌面模型中，终端用户会配发包含可写介质（硬盘）的桌面或笔记本电脑。这些终端设备存储如用户的个人资料、文件共享的数据副本、浏览器缓存、纯文本文件、图像、电子表格以及其他商业和个人数据。

即使在终端设备上对硬盘进行加密，敏感数据仍然可能存储在笔记本电脑（例如）中。由于高性能计算实例的可用性，它们的处理能力非常适合密码破解算法，如亚马逊 EC2 GPU 实例，破解密码和加密算法可以被转移到公共云中。因此，最安全的终端设备是不存储任何敏感信息的设备，无论是否加密。基于这个原因，PCoIP 零客户端（具有 Teradici 的 PCoIP 芯片的终端设备）可以说比薄客户端（具有锁定操作系统的设备）更加安全。两者都比厚客户端（传统的笔记本电脑或台式机）安全得多。

VDI 的固有安全性

使用适当设计的 VDI 解决方案，所有敏感数据都存储在安全的数据中心，而不是存储在如笔记本电脑和台式机等设备的硬盘中。虽然可以将数据从 vDesktop 复制到例如插入到终端设备中的 USB 闪存驱动器，但也可以阻止这种设备的 USB 重定向。

在安全的 VDI 实现中，通常传输的唯一数据是视觉和音频流，用以将桌面体验传输到终端设备。这意味着，如果终端用户在连接到其 vDesktop 时使用 Microsoft Word 操作文档，那么该文档不会存储在他的终端设备（例如笔记本电脑）上。相反，它完全存储在 vDesktop 中，理想情况下，这个 vDesktop 运行在数据中心内。桌面的视觉表现，包括 Microsoft Word 的视觉显示和文档，都会通过安全的 PCoIP 协议流式传输到终端设备。

在一个设计得当的 VDI 解决方案中，如果终端设备损坏、被盗、丢失或遗失，最终用户只需更换一个新的终端设备即可重新连接到他们的 vDesktop。例如，如果 Lily 的 PCoIP 零客户端无法使用，她可以领取一台新的零客户端，并能立即恢复在 VDI 中的工作。零客户端无需重新映像，Lily 可以快速恢复生产任务。

如果没有 VDI，她可能需要等待几天才能让终端设备重新利用、采购或配置，才能恢复生产工作。

此外，不需要执行数据恢复操作，因为终端设备上不存在数据。在使用热桌面技术的环境中，或者在办公环境中提供不需要预约的未分配工作区的做法下，Lily 只需走到一个可用的工作区，登录并重新连接到 VDI。同样，Lily 的所有数据都存储在数据中心。

防火墙、区域和防病毒

VMware View 环境安全的基本原则包括仅允许那些对功能性 VDI 至关重要的特定端口和协议。此外，当可用时，还需要使用安全套接字层（SSL）（与通过端口 80 的未加密流量相对）。另外，要求使用 PCoIP，而不是同时允许 RDP 连接，也可以进一步提高环境的安全性。

在给定的 VDI 解决方案中，可能会有多个生效的防火墙。这些防火墙包括：

• Windows 操作系统防火墙： 此防火墙用于限制操作系统层的进出流量

• 网络防火墙（内部）： 这些防火墙用于限制内部局域网环境内的流量

• 网络防火墙（外部/DMZ）： 这些防火墙用于限制通常来自互联网的流量

• 虚拟防火墙： 这些防火墙用于限制虚拟基础设施中虚拟端口组和虚拟交换机之间的流量

精心计算使用防火墙有助于创建被称为区域的物理和虚拟安全隔离区。虚拟安全区是一组网络配置、安全策略、虚拟机及其他虚拟基础设施组件，根据定义的策略允许彼此自由通信。

虚拟安全区有以下几种跨区通信的可能性：

• 允许的： Zone_A 和 Zone_B 中的虚拟机可以基于互相信任关系自由地相互通信（不要与像 Active Directory 信任和关系这样的技术混淆）

• 受限的： Zone_A 和 Zone_B 中的虚拟机只能通过预定义的端口和协议相互通信

• 禁止的： Zone_A 和 Zone_B 中的虚拟机不允许相互通信

安全矩阵的最后一个重要组成部分是 vDesktops 的防病毒保护。防病毒保护确保恶意软件不会渗透并传播到物理和/或虚拟桌面环境中。

基本的防火墙规则

如需更详细的端口和协议列表，请参阅 Christoph Harding 的优秀文章 VMware View 环境的防火墙设置，文章可以在 ThatsMyView.net 网站上找到：www.thatsmyview.net/2011/04/24/firewall-settings-for-a-vmware-view-environment/。

源 IP	方向	目标 IP	传输协议	端口	应用协议	描述
终端用户设备	入站	查看安全服务器	TCP	443	HTTPS	身份验证及其他通信
终端用户设备	双向	查看安全服务器	TCP 和 UDP	4172	PCoIP	PCoIP 握手和数据传输
查看安全服务器	入站	查看连接服务器	TCP	8009	AJP13	AJP-数据流量
查看安全服务器	入站	查看连接服务器	TCP	4001	JMS	Java
查看安全服务器	入站	查看传输服务器	TCP	443	HTTPS	与查看传输服务器的通信
查看安全服务器	双向	查看代理	TCP 和 UDP	4172	PCoIP	PCoIP 握手和数据传输
查看安全服务器	双向	查看代理	TCP	32111		USB 重定向（如适用）
查看连接服务器	出站	Active Directory	TCP 和 UDP	389	LDAP	Active Directory 身份验证和 ADAM
查看连接服务器	双向	查看连接服务器	TCP	4100	JMSIR	内部查看连接服务器通信
查看连接服务器	双向	查看连接服务器	TCP	636	LDAPS	AD LDS
查看连接服务器	双向	查看连接服务器	TCP	1515		Microsoft 端点映射器
查看连接服务器	双向	查看连接服务器	TCP	4001	JMS	Java
查看连接服务器	双向	查看连接服务器	TCP	8009	AJP13	AJP-数据流量
查看连接服务器	双向	查看传输服务器	TCP	8009	AJP13	AJP-数据流量
查看连接服务器	出站	查看传输服务器	TCP	443	HTTPS	与查看传输服务器的通信
查看连接服务器	出站	查看传输服务器	TCP	4001	JMS	Java
查看连接服务器	出站	查看传输服务器	TCP	4100	JMSIR	内部通信
查看连接服务器	出站	vCenter 服务器	TCP	18443	SOAP	查看 Composer 通信
查看连接服务器	出站	vCenter 服务器	TCP	443	HTTPS	vCenter 通信
查看连接服务器	双向	查看代理	TCP	4001	JMS	Java
终端用户设备	出站	查看连接服务器	TCP	443	SSL	与查看连接服务器的通信（用于身份验证及其他活动）
View Security Server	入站	View Connection Server	TCP	8009	AJP13	AJP-数据流量
View Security Server	入站	View Connection Server	TCP	4001	JMS	Java
终端设备	入站	View Transfer Server	TCP	443	HTTPS	与 View Transfer Server 的通信
View Security Server	入站	View Transfer Server	TCP	443	HTTPS	与 View Transfer Server 的通信
View Security Server	入站	View Transfer Server	TCP	8009	AJP13	AJP-数据流量
View Security Server	入站	View Transfer Server	TCP	4100	JMSIR	内部通信
View Security Server	入站	View Transfer Server	TCP	4001	JMS	Java
View Connection Server	入站	View Transfer Server	TCP	8009	AJP13	AJP-数据流量
终端设备	双向	View Agent	TCP 和 UDP	4172	PCoIP	PCoIP 连接和数据
终端设备	双向	View Agent	TCP	32111		USB 重定向（如适用）
View Agent	出站	View Connection Server	TCP	4001	JMS	Java
终端设备	双向	View Agent	TCP 和 UDP	4172	PCoIP	PCoIP 连接和数据
终端设备	入站	View Agent	TCP	32111		USB 重定向（如适用）
终端设备	入站	View Connection Server	TCP	443	HTTPS
终端设备	入站	View Connection Server	TCP	443	HTTPS
终端设备	双向	View Connection Server	TCP 和 UDP	4172	PCoIP	PCoIP 连接和数据

虚拟隔离区

虚拟隔离区是由虚拟机、虚拟端口组、资源（如果使用资源池）以及可能的底层数据存储组成的一个定义好的组。虚拟隔离区的概念是提供 VDI 内部的分段，将一个组与另一个组分隔开。

下图展示了三个独立的隔离区：

在前面的图示中，三个类别的 vDesktops 存在于整个虚拟基础设施中。这些类别由同名的桌面池组成，具体如下：

• 培训：该隔离区由培训室使用，为培训提供虚拟桌面

• 教职工：该隔离区由组织内的教职工用于其主要虚拟桌面

• 服务器：该隔离区由所有运行服务器操作系统的虚拟机使用

在虚拟基础设施中，有以下方法可以隔离这三个隔离区：

• VLAN 标签

• 独立的 vSwitch/vDSwitch 上行链路

• 启用 vSwitch/vDSwitch 安全设置

• 使用资源池来隔离计算消耗

• 使用独立的数据存储来隔离数据和 I/O

• 使用独立集群

所有前述方法均可在 VMware vSphere 中使用，无需额外的软件组件。

然而，使用诸如 VMware vShield TM、Reflex Systems vTrust TM 配合 vmTagging TM 和其他安全产品的解决方案，可以从虚拟基础设施内部提供虚拟气隙。

以下图示展示了 VMware 虚拟网络的不同分段选项：

上面的图示展示了几种虚拟网络技术：

• 虚拟分布式交换机（vDSwitch）

• 三个独立的虚拟分布式端口组

• 两个独立的软件防火墙（通过 VMware vShield 技术或 Reflex Systems vTrust 技术提供）

• 提供商网络连接；该连接可以直接访问互联网（在本例中）

• 三个独立的 vDesktop 组

红色隔离区包含一个组织内需要直接访问互联网以支持外部客户的 vDesktops。

该隔离区的 vDesktops 连接到提供商端口组，该端口组可以直接从虚拟基础设施访问互联网。然而，该连接可以在物理层进一步过滤。

蓝色隔离区包含一个组织内大多数工作员工使用的 vDesktops。

该隔离区的 vDesktops 连接到一个可以访问提供商网络的端口组；然而，它不是直接访问提供商网络，而是使用网络地址转换（NAT）来隐藏蓝色隔离区内 vDesktops 的实际 IP 地址。

绿色隔离区包含一个组织内培训室使用的 vDesktops。

该隔离区的 vDesktops 连接到一个没有访问提供商网络的端口组（注意连接在离开防火墙时终止）。它的虚拟隔离区允许绿色隔离区内的 vDesktops 和资源自由通信。然而，绿色隔离区内的虚拟机无法与隔离区外的资源通信。这个隔离区被描述为隔离的。

除了执行网络分段，VMware vShield 和 Reflex Systems 解决方案还可以在不同的隔离区之间提供基于软件的防火墙保护。

例如，蓝色隔离区中的 vDesktops 可能仅允许通过端口 443（HTTPS）与绿色隔离区中的 vDesktops 进行通信。

越狱场景

越狱场景，摘自一个实际的解决方案，涉及防止同一桌面池内的 vDesktops 之间的通信。桌面池用于定义所有 vDesktops 的几个关键设置；其中一个设置是分配给一个或多个 vDesktop 虚拟网卡的特定端口组（标准或分布式）。此设置是在桌面池级别定义的；因此，给定桌面池中的所有 vDesktops 都将位于同一端口组中。

在越狱场景中，拘留中心的 IT 人员实施了 VDI，以便让囚犯进行各种训练。尽管 vDesktops 已被锁定以防止连接到互联网，但所有 vDesktops 处于同一端口组中这一事实可能会带来威胁。

越狱场景中的最大威胁是，虽然各个 vDesktop 用户与其他网络连接（包括互联网或拘留中心的生产网络）被隔离，但他们仍然可以相互发送数据。威胁在于，多个 vDesktop 用户将利用所有 vDesktop 虚拟机都在同一端口组中的事实，发送消息以协调在特定时间对监狱工作人员发起起义。

例如，如果三十个囚犯登录 VDI 并开始互相发送离散消息，计划在上午 11 点袭击监狱工作人员，那么这可能会对监狱工作人员的个人安全、设施的安全以及周围社区的安全构成巨大风险。

尽管没有现成的解决方案可以防止这种类型的通信（可以说，内置的 Windows 防火墙在这种情况下可能会有所帮助），Reflex Systems 确实提供了将虚拟机彼此隔离的能力。此外，VMware vShield 也可能被用来提供这种虚拟分段。对于具有高度波动性的环境（例如扩展、收缩、View Composer 刷新等），无论是使用 VMware、Reflex Systems 还是其他安全解决方案，这种解决方案都需要大量的定制、脚本编写和集成工作。

USB 重定向与过滤

在越来越多的组织中，USB 硬盘被禁止使用。这是因为终端用户将敏感数据复制到 USB 硬盘上，并可能滥用该设备或恶意使用 USB 硬盘的数据，导致数据泄露的巨大风险。然而，简单地禁止所有 USB 设备可能会阻止以下完全可以接受的 USB 设备，如：

• 指示设备

• 音频耳机

• 转录播放踏板

• 医疗设备，例如病人监测设备

• 科学设备，例如测量仪器

• 摄影设备，例如录像机

• 音频设备，例如 USB MIDI 接口

• 身份验证设备，例如读卡器

因此，重要的是不要简单地禁止所有设备，而是建立一个允许的 USB 设备白名单。这就是所谓的USB 过滤。

下图展示了可用于 USB 过滤的三个主要级别：

USB 过滤可以应用的三个集成点如下：

• 终端设备

• 查看连接服务器

• Windows 桌面操作系统

此外，USB 过滤可以应用于：

• 整个 ClassID，以允许或禁止某一类设备（例如，USB 大容量存储设备）

• 供应商 ID (VID) 和 产品 ID (PID) 以允许或拒绝特定设备（例如，金士顿大容量存储设备）

在终端设备上进行 USB 过滤

使用 PCoIP 零客户机的一个好处是可以创建设备配置文件并将其应用于环境中的所有零客户机。通过这种方式，可以创建一个 USB 过滤设备配置文件，并将其应用于环境中所有的零客户机。通过设置复杂的密码锁定设备，设备的配置文件仅能由例如 Teradici 管理控制台控制。因此，任何定义 USB 过滤的策略都无法被覆盖。通过在终端设备上管理 USB 过滤，例如使用 Teradici 管理控制台，可以基于设备 ID 或设备类别授予权限，从而实现灵活的管理（例如，除非是由 IronKey TM 制造的，否则不允许使用 USB 闪存驱动器）。

在设备级别应用 USB 设备过滤的缺点是，它强烈限制了 自带设备（BYOD） 计划。这些计划鼓励最终用户使用他们最熟悉的设备；因为设备最终会连接到组织拥有的 vDesktop，并且所有工作将在 vDesktop 上进行，所以终端设备在这种情况下的性质并不重要。

使用设备配置文件进行 USB 过滤意味着必须为每个设备创建一个配置文件，并且每个设备都必须进行管理。

在许多组织中，转向 VDI 解决方案的目的是摆脱管理终端设备的工作，而是允许最终用户使用他们首选的计算方式。

通过视图连接服务器进行 USB 过滤

VMware View 连接服务器还提供了执行 USB 过滤的机制。

下图显示了 View 管理控制台中的 USB 访问策略设置：

在 View 管理控制台的 策略 | 全局策略 部分，可以将 USB 访问 设置为全面的 允许 或 拒绝。这不允许对仅授予特定设备访问权限进行精细管理。相反，它允许或禁止所有设备的 USB 重定向。

另一种类似于全有或全无的方法，是不从 vDesktop 模板或父虚拟机中安装 VMware View Agent 的 USB 重定向组件。这种方法不推荐使用，因为它会限制环境中的未来功能。

通过 Windows 操作系统进行 USB 过滤

例如，IronKey 加密 USB 驱动器的设备类别是 Windows 便携设备 (WPD)。

下图显示了来自来宾操作系统的 USB 设备：

通过在 设备管理器中选中相应设备并打开属性选项卡，可以找到此信息。

以下截图具体显示了一个 USB 设备 ID：

在给定设备的硬件 ID下（例如，IronKey U 盘），可以找到 PID 和 固件版本（REV）。在前面的示例中，VID 为 1953，PID 为 0201，REV 为 0208。

NirSoft 提供了一款免费的产品 USBDeview©，它是一个便捷的工具，可以快速查找特定 USB 设备的 PID、VID、序列号以及其他信息。它还以更友好的方式展示这些信息。

以下截图显示了使用 USBDeview 来识别 USB 产品 ID：

在前面的示例中，IronKey U 盘的供应商 ID（VendorID）为 1953，产品 ID（ProductID）为 0201。

配置 USB 过滤还需要 DeviceClassGUID。它也可以在 设备管理器的属性选项卡下找到。

以下截图显示了硬件过滤的注册表键：

例如，要禁止所有 IronKey 加密 U 盘（供应商 ID 1958，产品 ID 0201），可以将 VID_1958&PID_0201 添加到 HardwareIDFilters 键，路径为 **Computer\HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\USB**。

注册表更改会立即生效，无需重新启动。现在，当最终用户尝试连接他们的 IronKey 加密 U 盘时，将会收到错误消息。以下截图展示了在禁止某个 USB 设备的环境中，用户尝试使用 USB 设备时可能收到的错误信息：

有多种方法可以允许或禁止 USB 设备（特别是大容量存储设备）。然而，本节中概述的技术基本适用于所有设备，应该作为最佳实践来使用。

执行 USB 过滤的最安全方法是阻止所有设备，除非它们被定义在白名单中。

智能卡身份验证

智能卡身份验证是一种机制，通过该机制，通常带有金属触点的塑料卡片用于存储由最终用户使用的证书进行身份验证。智能卡在许多行业中都有使用，包括军事、医疗保健、教育、零售和科学界。智能卡身份验证的优点如下：

• 它要求最终用户随身携带身份验证机制

• 它要求最终用户成功地提供挑战（PIN）的答案

智能卡身份验证是一种双因素授权机制，要求最终用户不仅必须物理持有智能卡，还需要成功输入 PIN 码。PIN 码并不用于验证用户对域的身份；而是用来验证用户对智能卡上证书的身份。智能卡上的证书随后用于验证最终用户对域的身份。

智能卡身份验证已经成为医院、教育机构、科学界和军事组织中的标准做法。

智能卡身份验证需要以下内容：

• 一个或多个证书

• 中间件（例如来自 ActivIdentity 的 ActivClient）

  注意

  中间件应在 VMware View Agent 之前安装，以避免任何 GINA 链接问题；正确的安装顺序是 VMware Tools、然后是智能卡中间件，最后是 VMware View Agent。

  设置智能卡移除行为为锁定工作站（对于持久解决方案）或注销（对于非持久解决方案）可能会有所帮助。

• 智能卡

• 智能卡读卡器（例如 SCR331）

此外，必须满足以下先决条件：

• 在 VMware View Connection Server 安装过程中安装了智能卡选项

• VMware View Connection Server 已配置为允许智能卡身份验证

• 中间件（例如 ActivClient）正常运行并配置了必要的证书

• 所有 VMware View Connection 和安全服务器上的 locked.properties 文件已配置为使用包含一个或多个 证书颁发机构（CA） 证书的主密钥库，这些证书用于智能卡上使用的用户证书

智能卡配置对于任何组织应该几乎相同（只有证书是区分的因素）。需要注意的是，尽管大多数智能卡可能看起来相同，但市场上大约有十几种智能卡型号。

智能卡的品牌和型号通常可以通过正在使用的智能卡中间件（例如 ActivClient）发现。

以下截图显示了在 ActivClient 控制台中看到的某智能卡：

在前面的截图中，卡片已插入到经过批准的读卡器中（例如 SCR331）。在 ActivClient 的主屏幕上有三个选项。点击 我的证书 文件夹可以打开存储在智能卡上的用户证书。点击 CA 证书 可以打开存储在智能卡上的 CA 证书，这些证书用于验证用户证书。

打开 智能卡信息 对象会弹出以下截图，显示 ActivClient 中的智能卡信息：

如上图所示，相关智能卡的制造商是Gemalto，型号是Cyberflex Access 64K V2c。此外，用户名（通常与相同名称的 Active Directory 用户账户关联）也显示在用户名字段中。

以下截图显示了给定智能卡上的证书：

尽管前面的截图中只显示了一个用户证书，但智能卡上可能存储多个用户证书。VMware View 将筛选用户证书并提示最终用户选择使用哪个证书进行认证。仅显示具有客户端认证和智能卡登录角色的有效证书。

以下截图显示了通过 ActivClient 查看智能卡的证书详细信息：

上面的截图显示了 ActivClient 中的我的证书屏幕。用户证书的颁发 CA 的主体名称（例如thinkvirt.demo.local）已显示。确保对颁发 CA 的名称解析功能正常非常重要。DNS 解析故障可能会影响智能卡认证的时间。

来自 VMware 的附加智能卡信息可以在《VMware View 4.5/4.6 的智能卡证书认证》白皮书中找到。

为 VMware View 连接服务器配置智能卡认证

智能卡认证受到 PCoIP 零客户端、瘦客户端和厚客户端的支持。重要的是要验证正在使用的卡读卡器型号、卡型号和证书是否在 VMware View/Teradici PCoIP 支持矩阵中得到支持。这些文档可以在www.vmware.com/和www.teradici.com/找到。

此外，智能卡通常用于提供单点登录的安全机制，即用户只需一次登录 VMware View 环境（而不是每次会话连接或重新连接到 vDesktop 时）。

要强制使用智能卡认证，请转到编辑视图连接服务器设置选项卡，路径为视图配置 | 服务器。

以下截图显示了高级智能卡配置选项：

智能卡认证可以设置为不允许、可选或必需。此外，通过勾选在智能卡移除时断开用户会话复选框，可以设置会话在移除智能卡时断开连接。

在许多安全环境中，必需选项将被配置为强制任何请求访问 VDI 中 vDesktop 的传入请求，都必须通过用户的智能卡进行身份验证。

除了在 VMware View 管理控制台中配置智能卡认证外，还有一个在配置过程中非常重要的主文件 locked.properties。

settings.properties 文件也位于 \sslgateway\conf 子目录中，包含 VMware View 管理控制台用于 HTTPS 加密的证书配置；用于选择证书的值存储在 keyfile 字符串中。此外，settings.properties 文件还包含使用该证书所需的哈希密码；密码的值存储在 keypass 字符串中。

为智能卡认证准备环境

为准备智能卡认证环境，请执行以下步骤：

1. 第一步是验证 DNS 和 NTP 环境是否完全正常，因为基于证书的认证对时间漂移或在公钥基础设施（PKI）中解析服务器的困难非常敏感。

2. 接下来，必须下载 CA 证书。可以通过打开浏览器并指向 http://<CA_SERVER>/certsrv 来完成此操作，其中 <CA_SERVER> 是 CA 服务器的完全限定域名（FQDN）或 IP 地址。

3. 选择下载 CA 证书链接，默认选择DER 编码。将证书保存到 VMware View 连接服务器的 \VMware View\Server\jre\bin 目录中。

4. 以管理员权限启动命令提示符（例如，右键单击命令提示符图标并选择以管理员身份运行）。导航到 \VMware View\Server\jre\bin。

5. 接下来，输入以下命令以生成密钥库：

   keytool import alias view4ca file certnew.cer keystore trust.key 
   
   

6. certnew.cer 文件是前一步下载的 CA 证书。trust.key 文件是生成的密钥库，将由 VMware View 连接服务器用于验证存储在智能卡上的最终用户证书。

7. 然后，keytool 工具将提示输入 CA 证书的密码，并询问是否信任该证书。

8. 一旦密钥库成功生成，将文件（例如 trust.key）复制到 \VMware View\Server\sslgateway\conf 子目录中。

9. 接下来，在 \VMware View\Server\sslgateway\conf 子目录中使用记事本（或类似工具）创建名为 locked.properties 的文本文件。

10. 输入以下文本：

    trustKeyFile=trust.key
    trustStoreType=JKS
    UseCertAuth=true
    
    

11. 重启 VMware View 连接服务器服务。

配置 VMware View 安全服务器的智能卡认证

对于利用一个或多个 VMware View 安全服务器的环境，配置 View 安全服务器以使用智能卡认证（以及配置适当的证书）非常重要。否则，只有内部用户或绕过 VMware View 安全服务器的用户才能使用智能卡进行认证。

这些步骤与配置 VMware View 连接服务器的智能卡认证部分中列出的步骤相同。

以下图示显示了locked.properties文件的位置：

因此，配置 VMware View 安全服务器（在前述图示中显示为 VSS）最简单的方法如下：

1. 将trust.key文件（或其他适当的密钥存储文件）复制到\VMware View\Server\sslgateway\conf子目录中。

2. 将locked.properties文件复制到\VMware View\Server\sslgateway\conf子目录中。

3. 重启 VMware View 安全服务器服务。

如果 VMware View 环境利用相同的 PKI 和相同的密钥存储用于 CA 证书，则前述步骤非常简洁，这几乎适用于所有使用智能卡的 VMware View 解决方案。因此，完全有可能脚本化文件从一个服务器到另一个服务器的复制，以及在必要时重启相关服务（例如，VMware View 安全服务器服务）。

配置美国国防部 CAC 认证

美国国防部通用接入卡（DoD CAC）（智能卡）认证是国土安全总统指令 12 号（HSPD-12）批准的机制，供美国军事设施用于身份认证访问 IT 资产。CAC 卡还根据《日内瓦公约》作为通用身份证明卡。

用户通过将 CAC 插入 USB 智能卡读卡器、笔记本电脑智能卡读卡器、集成卡读卡器的瘦客户端或零客户端、或带集成卡读卡器的键盘来登录其物理桌面。一旦卡被读取，终端用户会被提示输入其 PIN。

完全可以在 vDesktop 内部使用 CAC 认证，而无需将其配置为访问 vDesktop 的可接受认证机制。

例如，如果在 vDesktop 中已正确安装和配置了 ActivClient，但在 View 连接服务器环境中尚未配置智能卡认证，则无法使用智能卡连接到 vDesktop。然而，一旦连接到 vDesktop，智能卡可以成功用于 VDI 中的身份认证（例如，RDP 连接）。在正常的智能卡操作中，使用智能卡进行身份认证时，系统会提示终端用户输入其 PIN。虽然这种情况是可能的，但远非首选解决方案，因为 VDI 连接不是通过智能卡认证完成的。

配置 CAC 认证包括在标准智能卡认证配置中使用的技术，并添加了一些细小的注意事项。

配置 CAC 认证的过程如下所示：

1. 在 VMware View 连接服务器上，导航到\VMware View Server\Server\sslgateway\conf子目录。

2. 创建一个名为certexport的子目录。在\certexport中放置所有适用的.cer文件。该目录用于生成当前或未来的主密钥存储。

3. 配置 CAC 认证的下一步是生成或获取一个master keystore，该文件包含所有美国国防部和中间 CA 证书。master keystore文件应放置在VMware View 安装目录中的\sslgateway\conf子目录下，View Connection Server 所在的位置。如何生成master keystore的详细说明将在本章后面进行说明。

4. 将truststore文件复制到\sslgateway\conf子目录下。

   上面的截图是配置了 CAC 认证的工作 VMware View Connection Server 的\\sslgateway\conf子目录的典型屏幕截图。

5. 现在所有证书都已放置在正确的位置，必须配置 VMware View Connection Server 以使用这些证书。

6. 接下来，打开locked.properties文件，该文件也可以在\sslgateway\conf子目录中找到。如果该文件不存在，则应使用记事本或类似工具创建它。

7. locked.properties文件的内容应类似于：

   trustKeyFile=masterkeystore
   trustStoreType=JKS
   useCertAuth=true
   
   

上述文本假设master keystore文件实际命名为masterkeystore。trustStoreType=JKS定义了信任库为使用Java 运行时环境（JRE） keytool.exe或类似工具生成的 Java 密钥库。useCertAuth=true启用了证书的使用。

一旦设置完成，重新启动 VMware View Connection Server 服务或 VMware View Security Server 服务。此时，还需要验证 View Admin 控制台是否仍然可用，因为格式错误的locked.properties文件可能会导致 View Admin 控制台无法正常加载。

证书撤销配置

证书撤销列表（CRL）用于防止那些证书已被撤销的用户（例如，已经被解雇的员工）成功地进行环境认证。VMware View 支持 CRL 和在线证书状态协议（OCSP），用于检查给定证书的撤销状态。如果在 VMware View Connection Server 或 VMware View Security Server 上配置了 OCSP 和 CRL，VMware View 会首先尝试使用 OCSP，如果 OCSP 失败，则会回退到使用 CRL。VMware View 不会从 CRL 回退到 OCSP，如果 CRL 检查失败。

配置 CRL 的使用

通过编辑locked.properties文件并添加以下行来配置 CRL 的使用：

enableRevocationchecking=true
allowCertCRLs=true
crlLocation=<URL_OF_CRL>

enableRevocationchecking和allowCertCRLs字符串启用了 VMware View 执行证书撤销检查。crlLocation字符串用于定义 CRL 的位置。

crlLocation的一个示例值是http://cert.demo.local/certEnroll/ocsp-ROOT_CA.crl。

配置 OCSP 的使用

使用 OCSP 可以通过编辑 locked.properties 文件并添加以下行来进行配置：

enableRevocationchecking=true
enableOCSP=true
allowCertCRLs=true
ocspSigningCert=<OCSP_Signing_Cert>
ocspURL=<URL_OCSP>

enableRevocationchecking 和 allowCertCRLs 字符串使 VMware View 执行证书撤销检查。enableOCSP 字符串启用 OCSP。ocspSigningCert 用于定义 OCSP 授权机构使用的证书，而 ocspURL 用于定义 OCSP 响应者的位置。

配置同时使用 CRL 和 OCSP

要配置同时使用 CRL 和 OCSP，请将所有前述字段及其适当的值插入到 locked.properties 文件中。请注意，allowCertCRLs=true 字符串只需列出一次。

此外，还应将以下内容添加到 locked.properties 文件中：

ocspCRLFailover=true

ocspCRLFailover 字符串允许 VMware View 连接服务器或 VMware View 安全服务器在 OCSP 失败时使用 CRL。

禁止使用复制和粘贴功能

在某些环境中，管理员可能希望防止最终用户在其虚拟桌面与厚客户端或瘦客户端之间进行复制和粘贴。防止复制和粘贴功能的正确方法是通过虚拟桌面的组策略进行配置。

这在 \extras 子目录下任何 View 连接服务器上的 PCOIP.ADM 模板中定义。该设置可以在 计算机配置\管理模板\PCoIP 会话变量\不可覆盖的管理员设置\配置 PCoIP 虚拟通道 中找到。

在此设置中，有一个允许列表和一个不允许列表。如果虚拟通道同时出现在允许列表和不允许列表中，它将被禁止。在 View 4.6 及更高版本中，负责剪贴板的虚拟通道（mksvchan）不再需要明确提及。管理员只需勾选“禁用 PCoIP 主机上的剪贴板处理”并启用该策略即可。

以下截图展示了剪贴板处理的设置：

禁用 PCoIP 主机的剪贴板处理 设置在连接或重新连接时读取。因此，将设置从 未配置 更改为 启用（例如）将会在下次登录时生效，而不是在当前会话中生效。

View 连接服务器标签

VMware View 连接服务器使用标签来控制在多台 View 连接服务器环境中对特定桌面池的访问。任何给定的 VMware View 连接服务器可以没有标签、一个标签或多个标签。标签在 View 管理控制台的 View 配置 | 服务器 | 编辑 View 连接服务器设置 下定义。

以下截图展示了使用连接服务器标签（在本例中为 thinkvirt）：

在上述示例中，已为特定的 VMware View 连接服务器分配了 thinkvirt 标签。要为 VMware View 连接服务器分配多个标签，可以使用分号或逗号分隔标签。

然后，在桌面池的配置中，选择 池设置 选项卡，点击 浏览 进行配置标签。

下图显示了限制标签的使用：

上述截图会显示多个标签（如果使用了多个标签），并允许管理员选择一个、一些或所有可用的标签。

注

标签字段仅会在环境中至少一个 View 连接服务器具有定义标签时填充。

在 连接服务器限制 对话框中，有两个选项：

• 没有限制： 此池可以从任何 VMware View 连接服务器进行访问

• 限制为这些标签： 此池只能从具有定义标签的一个或多个 VMware View 连接服务器访问

以下是标签连接权限的矩阵：

连接服务器是否已定义标签？	桌面池是否配置为使用标签？	结果
没有	没有	可连接
没有	一个或多个	无法连接
一个或多个	没有	可连接
一个或多个	一个或多个	仅在一个或多个标签匹配时才可连接

这种情况的一个例子是，如果一个组织有两个独立的入站 VPN 环境。VPN_A 供顾问和访客使用，VPN_B 供员工使用。如果该组织希望将 VPN_A 的用户限制为一个具有有限功能和最少应用程序安装的桌面，可以分别为 VPN_A 和 VPN_B 设置多个独立的 View 连接服务器。然后，View 连接服务器将分别标记为 VPNA 和 VPNB。此时，有限功能的桌面池将只允许 VPNA 连接，而完全功能的桌面池将只允许 VPNB 连接。

需要注意的是，VMware View 解决方案可以利用多个 vCenter 服务器。因此，标签不仅可能限制传入用户可以访问的池，还可能使后端桌面池存在于完全独立的虚拟基础架构中。

此外，您还可以使用 View 连接服务器标签来识别哪些用户被强制使用双重身份验证，哪些没有。

在前面的示例中，最终用户可以访问多个 View Connection Server（VCS）。绿色 VCS 要求智能卡认证。例如，该 VCS 可能用于军事人员或医生，他们已获得通用访问卡（CAC），而蓝色 VCS 则可供平民、实习生或临时员工（未发放智能卡的人员）使用。在 VDI 环境中，存在一个桌面池，其中包括多个敏感的财务应用程序作为基础镜像。通过使用 VMware View Connection Server 标记，财务桌面池可以被配置为只允许来自绿色 VCS 的连接，从而强制要求来访用户使用智能卡认证。

法医学

法医学，在信息技术领域，通常指从计算机系统中提取法律证据，以支持法律事件。法医学包括识别、保存、恢复、分析和呈现从计算机环境中收集的数据。法医学也是许多敏感计算环境在寻求使用 VDI 解决方案时所需的组件。

要了解法医学如何受到 VDI 的影响，首先需要理解用户创作或用户操控的数据可能存放在哪里。

用户创作或用户操控数据的主要位置如下：

• 操作系统： 对于不使用 View Composer 或不使用重定向用户人物配置文件的 VMware View 解决方案，用户数据将位于操作系统分区中。

• 人物层： 对于使用 Microsoft 漫游配置文件的 VMware View 解决方案，或者使用例如 Liquidware Labs ProfileUnity TM 的个人管理解决方案，或 VMware View 的持久性用户数据驱动器，用户数据将位于人物分区中。对于 Microsoft 漫游配置文件、AppSense 或 ProfileUnity，用户数据将存储在网络共享中。因此，确保存储用户数据的网络共享根据组织政策进行备份是至关重要的，因为法医学分析将在此位置进行。

  对于使用持久性用户数据驱动器的解决方案，保存这些虚拟磁盘文件至关重要，以便在需要进行法医学分析时，它们可以附加到其他虚拟机上。当用户数据位于人物层时，虚拟机的不稳定性就不再是一个大问题。

• 网络资源： 对于网络资源，例如文件共享、基于 Web 的协作资源，保留这些数据点的范围超出了本书的讨论范围，更依赖于理解各种平台以及它们如何提供审计和数据恢复能力。

• 临时位置： 对于那些利用重定向用户配置文件的解决方案，可能由于配置错误导致用户数据未被正确捕捉，因此在 vDesktop 或桌面池的 View Composer 过程中可能会被丢弃。

对于需要取证能力的 VDI（虚拟桌面基础设施）最大的挑战是使用非持久性桌面池。持久性桌面池会自动分配一次，因此能够保持数据、版本、状态等信息。

总结

虽然 VDI 解决方案本质上是安全的，因为最终用户的数据通常存储在安全的数据中心，但了解组织的安全态势、政策和攻击向量，并在必要时采取适当的措施仍然至关重要。由于最终用户可以从任何位置连接，例如咖啡店的非安全 Wi-Fi、通过 AT&T 3G 网络的 Apple iPad、公司局域网或家庭有线 ISP，因此保护公司数据和知识产权非常重要。使用智能卡身份验证（这一解决方案正在迅速普及）是保护身份验证入口的一种有效方法。合理的网络策略，限制流量到定义的端口、协议、来源和目的地，是确保 VDI 安全的另一个关键组成部分。

最后，了解数据取证的基本原理，以确保合规性（如果需要），是 VDI 解决方案团队必须具备的重要技能。虽然大多数 VDI 解决方案可能不需要深入的取证能力，但理解需要保留、监控和收集的数据点非常重要。

下一章将重点介绍从物理桌面解决方案迁移到虚拟桌面解决方案的过程。可以采取许多不同的方法，每种方法的优缺点将进行详细讨论。

第十章：从物理桌面迁移到虚拟桌面

本章分析了将用户从物理桌面环境迁移到虚拟桌面解决方案的策略和技术。虽然许多 VDI 解决方案是全新构建，不涉及用户迁移，但大多数要实施的 VDI 解决方案都会涉及用户迁移的某个环节。

为了确保 VDI 项目的整体成功，重要的是尽量减少过渡过程中对最终用户的感知影响。减少这种影响的一部分是了解如何正确迁移用户特定的数据，也就是用户的个人资料。

用户的个人资料包含用户偏好、应用设置、主题、快捷方式、收藏夹、打印机以及其他独特配置。为了将用户的个人资料从桌面中解耦，个人资料最终必须位于桌面操作系统之外。通常，用户个人资料存储在经典的网络文件共享或分布式文件系统共享中。通过将个人资料存储在网络共享中，无论用户连接到哪个虚拟桌面资源，都能提供一致的终端用户体验，因为个人资料不绑定到特定的虚拟桌面。

市场上有多种解决方案可以帮助迁移用户的个人资料，包括微软的漫游配置文件和文件夹重定向、AppSense、以及 Liquidware Labs 的 ProfileUnity 等。

用户个人资料的迁移

为了迁移用户的个人资料，首先必须将其与桌面操作系统解耦。在完全耦合的情况下，用户的个人资料位于物理桌面的操作环境中。

以下图示展示了物理桌面的特点：

在前面的图示中，操作系统、应用程序和用户个人资料都位于同一环境中。没有应用程序虚拟化（例如，VMware ThinApp）或个人资料管理解决方案（例如，ProfileUnity）。成功将前述物理桌面迁移到完全功能的虚拟桌面（vDesktop）的第一步，是将个人资料与操作环境分离。

将个人资料与操作环境分离

通过将用户的个人资料与底层桌面分离，可以将其自由地迁移到另一个物理桌面，或者理想情况下，迁移到虚拟桌面。这与应用程序虚拟化的方式相同，例如，某个应用程序通过 ThinApp 进行打包，并且不再与底层操作系统绑定。

以下图示展示了用户个人资料与物理桌面解耦的过程：

解耦用户个人资料与物理桌面操作环境的三种最简单的方式如下：

• 微软漫游配置文件 + 文件夹重定向

• Liquidware Labs ProfileUnity

• AppSense

在这种状态下，物理桌面仍包含已安装的应用程序，但用户的定制设置和其他组成用户个人资料的详细信息则存储在客体操作系统之外。

文件夹重定向

文件夹重定向通过将文件夹的路径（例如，\My Documents）重定向到新位置，通常是网络共享，用户对此一无所知。将\My Documents重定向到网络共享的最终用户，依然会在其\My Documents中打开、保存和操作文件，但实际上操作的是网络共享上的文件，而非本地驱动器。文件夹重定向的优点如下：

• 用户的数据可以通过任何桌面资源访问，只要有适当的网络连接。

• 组策略可以用来强制执行磁盘配额，以最小化用户个人资料的空间。

• 用户的数据如果已经被重定向，通常在桌面发生故障时更容易恢复，因为生产网络共享通常比桌面更频繁地备份。

使用微软本地解决方案时，我的文档、应用数据、桌面和开始菜单父文件夹可以被重定向。上述父文件夹的子文件夹也会被重定向。

我的文档是一个用户拥有读/写权限的文件夹，用于保存文档、图片、媒体和其他数据。我的文档是许多 Microsoft 应用程序的默认保存位置。

应用数据文件夹是应用程序用来保存与特定应用程序相关的用户定制设置的文件夹。

桌面文件夹是包含用户桌面上所有项目的文件夹。

开始菜单文件夹包含桌面开始菜单列表中的项目。

配置文件

为了理解漫游配置文件的工作原理，了解 Windows 环境中配置文件的组成非常重要。在 Windows 中，配置文件由以下内容组成：

• 注册表根： 存储为NTuser.dat的注册表根存储着 HKEY_CURRENT_USER 的内容。

• 配置文件夹：（例如，C:\Users\User4）

在注册表根和配置文件夹中，存储着与映射的打印机、桌面快捷方式、驱动器映射、独特进程和日志记录等配置设置。

在 Windows 中，有几种类型的配置文件，如下所示：

• 本地配置文件： 这是最常用的配置文件类型，用户第一次登录桌面时创建。

• 漫游配置文件： 这种类型的配置文件在登录时会创建网络主副本的本地副本；登出时，所做的更改会被复制回网络主副本。

• 强制性个人资料: 这种类型的个人资料由管理员使用，以指定用户的设置；用户所做的更改将在注销时丢失。

在许多虚拟桌面基础设施（VDI）解决方案中，尤其是那些非持久性的解决方案中，通常会使用漫游个人资料或其他个人资料管理方案。这是因为漫游个人资料允许任何用户访问任何可用的虚拟桌面，并且仍然保持自己的独特个性化设置。

如何构建个人资料：第一次登录

要理解 Windows 个人资料是如何构建的，首先需要了解C:\Users的文件夹目录结构。

在C:\Users下，有以下几个文件夹：

• 所有用户: 此文件夹中的设置适用于任何登录桌面的用户。

• 默认用户: 此文件夹中的设置作为模板应用于任何登录工作站的新用户，这意味着这些用户在桌面上尚未有个人资料文件夹。

• 用户名: 此文件夹中的设置对特定用户是唯一的。

当用户第一次登录到桌面时，无论是物理桌面还是虚拟桌面，该用户都会在C:\Documents and Settings（例如 Windows XP）或C:\Users（例如 Windows 7）下创建一个独特的个人资料文件夹。此文件夹的内容基于默认用户中的内容。此外，所有用户中的任何内容也会作为个人资料的一部分加载。

后续登录

一旦用户在桌面上拥有了自己独特的个人资料文件夹，他们就不再使用默认用户文件夹。这意味着，如果用户已经创建了个人资料，之后在默认用户中放置的任何设置或快捷方式将不会反映在用户的个人资料中。然而，放置在所有用户文件夹中的快捷方式将会被反映出来。

注意

如果用户具有管理员权限并删除来自所有用户的快捷方式或文件，那么该快捷方式或文件将对机器上的所有用户删除。

放置在所有用户中的快捷方式或文件会立即显示给任何登录桌面的用户。

漫游个人资料

漫游个人资料是存储在中央存储库中并在登录桌面操作系统时按需访问的个人资料。

下图展示了一个用户能够登录到任一桌面并仍能接收到个人资料设置的示意图：

使用漫游个人资料是一种将用户的个人资料文件夹存储在网络共享上的技术，从而将用户个人资料与实际桌面解耦。

在没有漫游个人资料的示例场景中，用户 Dwayne 走到物理桌面 Desktop1，Dwayne 处理文档、改变桌面壁纸、映射打印机，然后注销。如果 Dwayne 接着走到另一个物理桌面 Desktop2 并登录，他将不会有在 Desktop1 上所做的任何工作、设置或映射。这是因为 Dwayne 的个人资料物理上存储在 Desktop1 的本地驱动器上。

在启用漫游配置文件的相同场景下，Dwayne 的文档、壁纸、打印机映射和其他设置将在从 Desktop1 注销时复制到中央网络位置。因此，当 Dwayne 登录到 Desktop2 时，所有设置、文档和映射将从中央网络位置下载。

漫游配置文件的一个缺点是，可能会进入一个场景，用户的配置文件非常大，导致登录和注销任务受到限制，因为配置文件正在与网络共享同步。例如，如果用户有一个 5 GB 的漫游配置文件，并且第一次登录某台机器，所有 5 GB 的数据将从网络位置下载，直到用户看到工作桌面为止。因此，重要的是要尽量减少漫游配置文件中的数据，以确保良好的终端用户体验。

注意

确保禁用“允许离线文件”和/或“允许离线缓存”。如果使用非持久性 VDI 解决方案且允许离线缓存，用户可能登录到虚拟桌面时，无法下载其配置文件的最新版本（因为存在缓存副本）。

漫游配置文件 + 文件夹重定向：提高性能

由于用户配置文件中大多数大型文件可能位于如 \My Documents 这样的目录中，重定向此类文件夹到网络位置可以确保用户的配置文件不会过度膨胀。

以下图示展示了通过文件夹重定向和漫游配置文件对用户个性化进行分段的示例：

通过结合文件夹重定向和漫游配置文件，大型文件（例如，通常存储在 \My Documents 中的文档）可以被重定向到网络位置，同时设置和配置文件可以通过漫游配置文件进行同步。

其他第三方解决方案：Liquidware Labs ProfileUnity

尽管市场上有多种配置文件管理解决方案，Liquidware Labs ProfileUnity 是一个具有成本竞争力的解决方案，它以本地 Windows 格式保存设置和配置，而不是将其存储在专有数据库中。

此外，ProfileUnity 还提供额外的好处，例如：

• 从一个控制台管理用户配置文件和文件夹重定向

• 轻松配置 MAPI 配置文件以便与 Microsoft Exchange Server 一起使用

• 基于规则、机器类别、操作系统、连接类型等筛选脚本的执行

• 通过使用压缩和配置文件损坏减少技术来加速登录时间

此外，对于不太熟悉高级组策略管理的系统管理员，ProfileUnity 提供了一个相当直观的用户界面进行管理。

从物理环境切换到虚拟环境

一旦配置文件与桌面解耦，用户可以在周二登录物理桌面，周三登录虚拟桌面，并保持所有设置。需要考虑的几个事项如下：

• 如果在迁移过程中涉及操作系统升级，确保旧操作系统的所有设置应用于新操作系统。

• 如果计划提供在旧操作系统和新操作系统之间来回切换的能力，可能需要做出特殊的考虑，以确保设置能够应用。例如，Windows XP 和 Windows 7 之间的壁纸文件类型不同。

此外，还需要考虑实现的是哪种类型的桌面池（持久性或非持久性）以及选择的配置文件管理解决方案（例如，原生 Microsoft 方案、Liquidware Labs ProfileUnity 等），因为首次登录可能会花费较长时间。

VMware View 用户数据磁盘的使用

VMware View 提供了将用户配置文件存储在用户数据磁盘（UDD）上的功能。该用户数据磁盘与 VDI 中的特定虚拟桌面绑定。

以下图示展示了用户数据磁盘在配置文件管理中的使用：

VMware View 提供了将用户配置文件重定向到持久性用户数据磁盘（UDD）的功能。该磁盘与构成用户虚拟桌面（vDesktop）的其他磁盘分开；然而，用户的 UDD 一次只能附加到一个虚拟桌面。此外，UDD 仅可用于持久桌面池。

用户配置文件可以通过使用标准的 Microsoft 工具或第三方解决方案迁移到 UDD。一旦用户配置文件完全并成功地迁移到 UDD，它将不再驻留在网络共享上，其内容仅在将 UDD（.vmdk 文件）附加到虚拟机后才能访问。

与用户数据相关的操作考虑事项

除了在 VMware View 解决方案中需要做出的技术性考虑外，还有需要做出的操作性考虑。其中一个考虑是用户数据的管理，特别是与人力资源活动相关的管理。这些活动包括员工的雇佣和离职。例如，当员工离职时，通常需要将用户数据归档并存储一定的时间。

以下图示展示了在 VMware View 环境中用户数据磁盘的管理：

如果用户数据磁盘是解决方案的一部分，那么当员工离职时，必须将用户数据磁盘从虚拟桌面上分离，并可能移动到专门存储历史数据的数据存储区。如果之后需要分析历史数据，则必须先将用户数据磁盘附加到现有的虚拟机上。对于有季节性员工流动的组织（例如，管理选举活动的团队），这可能变得繁琐。

以下图示展示了管理用户配置文件在中央文件共享中的方式：

通过使用中央文件共享，所有组织中的用户数据都存储在一个地方。对文件共享的访问通常由用户的活动目录账户控制，因此禁用用户账户（例如因离职）也会禁用其访问配置文件目录的权限；然而，配置文件目录仍然存在于文件共享中，直到管理员采取行动（如有必要）。

总结

对于全新的 VDI 环境（例如教室设施），如果不需要导入用户数据，则用户个人数据的迁移无关紧要。然而，对于许多组织而言，从物理桌面迁移到虚拟桌面的用户数据迁移将是实施过程中的一个重要部分。通过将用户数据与桌面操作系统解耦，用户的设置可以保持不变，同时实际桌面从物理迁移到虚拟。此外，了解用户配置文件解决方案如何影响业务流程，尤其是与人力资源相关的流程，也至关重要。

下一章将重点讨论 VDI 的备份及在故障期间的恢复。尽管冗余设计已在本书中覆盖，但有时不可预见的或未计划的故障可能会在 VDI 中造成潜在问题。因此，了解如何保护并从此类故障中恢复是非常重要的。

第十一章：备份 VMware View 基础架构

尽管 VMware View 环境中不应存在单点故障，但确保定期备份以便在发生故障时能快速恢复仍然非常重要。此外，如果设置发生损坏或更改，备份可以用于恢复到先前的时间点。VMware View 环境的备份应该根据组织现有的备份方法定期执行。VMware View 环境包含文件和数据库。

VMware View 环境的主要备份点如下：

• VMware View ADAM 数据库

• VMware View Composer 数据库

• VMware vCenter 数据库

• VMware View Connection Server 设置

通过备份所有前述组件，在发生故障时可以恢复 VMware View Server 基础架构。

为了最大化恢复环境中的成功机会，建议同时备份 View ADAM、View Composer 和 vCenter 数据库，以避免数据不一致。备份可以计划和自动执行，也可以手动执行；理想情况下，应该使用计划备份以确保定期执行和完成。

正确的设计要求始终应有两个或更多的 View Connection Server。由于同一副本池中的所有 View Connection Server 都包含相同的配置数据，因此只需要备份一个 View Connection Server。此备份通常配置为在标准模式下安装的第一个 View Connection Server。

备份 VMware View Connection Server 环境

可以通过 VMware View Admin 控制台配置 View Connection Server 备份。这些备份将配置文件和数据库信息转储到 VMware View Connection Server 上的一个位置，之后必须通过常规机制进行备份，如备份代理和计划任务。VMware View Connection Server 备份的工作流程如下：

1. 安排 VMware View 备份任务并导出到 C:\View_Backup\。

2. 第三方备份解决方案在 View Connection Server 上运行，并备份 System State、Program Files 和 C:\View_Backup\ 文件夹。

在 VMware View Admin 控制台中，有三个主要选项必须配置以备份 VMware View Connection Server 设置：

• 自动备份频率： 这是自动执行备份的频率。

  • 每日推荐： 由于大多数服务器备份是每天执行的，如果在 Windows 服务器的完整备份之前进行自动的 View Connection Server 备份，该备份将包含在夜间备份中；根据需要进行调整。

• 最大备份数量： 这是 View Connection Server 上可以存储的最大备份数量；一旦达到最大数量，备份将根据年龄进行轮换，最旧的备份将被最新的备份替换。

  • 建议 30 天： 这将确保服务器上保留大约一个月的备份；根据需要进行调整

• 文件夹位置： 这是 View 连接服务器上将存储备份的地点

  • 确保第三方备份解决方案正在备份此位置

一旦备份被自动运行或手动执行，将会在备份位置保存两种类型的文件，如下所示：

• LDF 文件：这些是来自 VMware View 连接服务器 ADAM 数据库的 LDIF 导出文件，存储着 VMware View 环境的配置设置

• SVI 文件：这些是 VMware View Composer 数据库的备份

View 连接服务器的备份过程相当简单。虽然过程容易，但不应忽视。

安全服务器注意事项

出人意料的是，没有通过 VMware View 管理控制台备份 VMware View 安全服务器的选项。对于 View 连接服务器，可以通过选择服务器、选择编辑，然后选择备份来配置备份。突出显示 View 安全服务器并没有提供此功能。

相反，安全服务器应该通过正常的第三方机制进行备份。最需要关注的是安装目录，默认情况下为C:\Program Files\VMware\VMware View\Server。

在...\sslgateway\conf目录中是.config文件，其中包含以下设置：

• pcoipClientIPAddress: 这是安全服务器使用的公共地址

• pcoipClientUDPPort: 这是用于 UDP 流量的端口（默认值：4172）

此外，settings文件位于此目录中，包含如下设置：

• maxConnections: 这是 View 安全服务器一次可以支持的最大并发连接数（默认值：2000）

• serverID: 这是安全服务器使用的主机名

此外，定制证书和日志文件存储在 VMware View 安全服务器的安装目录中。因此，如果要保留日志文件数据（且没有将其导入到更大的企业日志文件解决方案中），定期备份这些数据是非常重要的。

转移服务器和 ThinApp 仓库注意事项

在环境中备份 VMware View 转移服务器有两个组成部分。第一个组成部分是转移服务器的 VMware 安装目录和服务器的注册表。第二个组成部分更为重要，即实际存储已发布 vDesktops 的仓库。

如果 View 转移服务器本身出现故障，但仓库仍在线，签出和签入任务将无法使用，但主要数据，即已发布的 vDesktops，将仍然得到保留。一旦 View 转移服务器重新构建并恢复，它应当正常运行。在大多数生产环境中，应该有两个转移服务器，通常指向相同的冗余文件共享。

如果视图传输服务器在线但存储库失败，任何与传输相关的活动（如结账、更新或签入）都将失败。

ThinApp 存储库的性质与传输服务器存储库类似，它应该位于一个冗余文件共享上，并定期进行备份。如果 ThinApp 包已配置为保留每个用户的沙箱，那么 ThinApp 存储库应该可能每晚进行备份。

恢复 VMware View 环境

执行视图连接服务器恢复的步骤主要可以在 VMware KB 文章 执行 View Manager 3.x 或 4.x 的端到端备份与恢复 中找到。

备份黄金模板

对于使用完全克隆作为虚拟桌面（vDesktops）配置技术的环境，应该定期备份黄金模板。黄金模板是所有其他虚拟桌面克隆自的母模板。VMware KB 文章 使用 VMware API 备份和恢复虚拟机模板 介绍了备份和恢复模板的步骤。简而言之，大多数备份解决方案要求将黄金模板从模板转换为常规虚拟机，然后才能进行备份。

备份母虚拟机

备份母虚拟机可能比较棘手，因为它是一个虚拟机，通常有多个时间点的快照。最常见的技术是在特定时间点的快照处合并虚拟机快照树，然后将新创建的虚拟机备份或复制到第二个数据存储区。通过将母虚拟机存储在冗余存储解决方案中，母虚拟机丢失的可能性非常小。更可能的情况是，可能会在母虚拟机处于非功能性或不理想状态时创建时间点快照。

总结

正如预期的那样，备份 VMware View 解决方案的基本组件非常重要。尽管弹性设计应该能缓解大多数类型的故障，但仍然有一些情况下需要备份才能将环境恢复到可操作的状态。在 附录 其他工具 中讨论了一些对设计 VMware View 解决方案的 VDI 架构师可能有用的额外工具。

第十二章：VMware View 5.1

在本书发布时，VMware View 5.0 正在被 VMware View 5.1 版本取代，尽管是一个.1 版本，但 VMware View 团队添加了大量功能，改善了 VMware View 的性能、可扩展性和用户体验。

本章将新功能分为以下五个主要领域：

• 平台

• 用户体验与客户端

• 管理与管理

• 个人信息管理

• 安全性

平台功能

VMware View 5.1 中的平台功能增强旨在减少存储需求的剧烈变化。由于本书的很大一部分内容专门用于简化和优化存储需求，因此 VMware View 5.1 的改进备受欢迎。

基于内容的读取缓存（也称为视图存储加速器）

基于内容的读取缓存（CBRC）功能是 VMware vSphere 5 的原生功能，并由 VMware View 管理。CBRC 有助于解决一些典型的 VDI 性能瓶颈，并帮助降低 VDI 的整体存储成本。

CBRC 是一个基于 RAM 的缓存解决方案，位于给定的 ESXi 主机上，帮助减少对存储子系统发出的读取 I/O 次数。通过减少对存储子系统发出的读取 I/O 次数，可以实现存储子系统的可扩展性和整体性能的提升。CBRC 对客户操作系统（vDesktop）完全透明。

VMware 宣布，在与 CBRC 的测试中，启动风暴的减少大约如下：

• 峰值 IOPS 减少 80%

• 平均 IOPS 减少 45%

• 峰值吞吐量减少 65%

• 平均吞吐量减少 25%

这些是存储子系统的重大节省，应在 VMware View 设计过程中仔细考虑。需要注意的是，CBRC 仅用于读取 I/O。

缓存有两个组件，具体如下：

• 内存缓存： 由管理员配置，具有固定的最大大小为 2 GB，默认的内存预留为 400 MB

• 动态缓存： 它根据需求加载块，并根据 VMDK 上各个块的访问模式管理缓存

每个主机上的 VMDK 磁盘在磁盘上维护一个摘要/元数据表。元数据保存关于 VMDK 上各种块的信息。可以将其想象成一个哈希表，每个哈希条目指向一个特定的块。

将前两个组件组合起来，如果对 VMDK 上某个特定块有读取请求，则计算一个哈希值，并检查内存缓存中是否存在该块。如果不存在，则访问哈希表并将相应的块加载到内存缓存中。如果该块已经在内存缓存中，则将其返回给用户。

CBRC 占用的额外内存在内存消耗方面被视为回归。由于在稳定状态的工作负载下，CBRC 的内存需求并不高，vSphere 会对内存消耗进行表征并加以减少。

CBRC 将使没有智能阵列和缓存管理的 VDI 环境受益。然而，对于具有读取或读写缓存管理的阵列，CBRC 也将有助于减少存储传输中的 I/O 延迟。由于读取的 I/O 从主机内存中提供，因此无需通过网络检索数据块。此外，数据块的检索时间为微秒级，而非毫秒级。

上面的图示突出了 ESXi 主机直接访问其内存的情况，CBRC 就存储在内存中。如果数据必须从典型的存储阵列中检索，请求必须通过任何路径才能完成。CBRC 提供的 I/O 性能提升在终端用户使用桌面时会明显感受到。然而，应该注意的是，在稳定状态的工作负载下，大多数 I/O 操作是写入操作，而非读取操作。

视图存储加速器允许主机对操作系统磁盘和用户持久磁盘进行缓存，适用于链接克隆桌面；管理员还可以指定缓存元数据应多久重新生成一次。

CBRC 存储大小

启用视图存储加速器时（操作系统磁盘或操作系统和持久磁盘），会为每个 VMDK 创建一个摘要文件，以存储关于 VMDK 块的哈希信息。

每个摘要文件的预计大小大约为：

• 当哈希碰撞检测关闭时（默认值），每 1 GB 的 VMDK 大小约为 5 MB。

• 当哈希碰撞检测开启时，每 1 GB 的 VMDK 大小约为 12 MB。

上述截图显示了给定数据存储中 CBRC 摘要文件的存在。

在 VMware vCenter 的任务窗格中，也会显示虚拟磁盘摘要的创建过程。

创建大型副本磁盘的摘要文件可能需要相当长的时间和 IOPS，因此建议在生产时间内不要运行该操作、创建新的桌面池或重新组成现有的桌面池。

举个例子，一个 25 GB 的 Windows 虚拟机副本将为摘要文件消耗大约 125 MB 的存储空间。对于快照（增量）或持久磁盘，摘要文件也会为快照创建。如果克隆 VMDK，摘要文件也会被复制。

由于基于 Windows 的桌面之间会有大量相同的块，假设在使用 CBRC 时，可以通过完全桌面克隆实现性能提升。然而，截至目前，CBRC 不支持完全桌面克隆。

对于 5 GB 的持久磁盘，摘要文件大约为 24 MB。

主机内存大小

CBRC 使用 RAM 缓存来管理缓存的磁盘块。每个 VMDK 的摘要文件也会被加载到内存中。

在内存过度分配的环境下不应启用 CBRC。如果主机内存已被过度分配并且启用了 CBRC，内存压力将增加，因为 CBRC 也会使用内存作为缓存。在这种情况下，主机可能会经历增加的交换操作，整体性能也可能受到影响。在这种情形下，启用 CBRC 可能会导致性能更差。

以下截图展示了在主机上启用 512 MB 缓存的 CBRC 时的图示：

由于 CBRC 在其架构中消耗主机内存，因此可以通过减少虚拟机密度来缓解主机磁盘交换和性能下降的问题。更理想的做法是适当配置主机，包含支持 CBRC 功能所需的额外 RAM。

为每个创建的 VMDK 摘要文件，将额外消耗大约 24 MB 的 RAM，除了已定义的 CBRC 缓存。例如，如果只有一个系统磁盘进行哈希计算，且主机缓存为 500 MB，则 500 MB + 24 MB = 总共将使用 524 MB 内存。

需要记住的是，也可以为系统盘和持久磁盘创建摘要。

另一个例子是，如果有 64 个虚拟机在使用，则会有 64 个持久磁盘，再加上 1 个副本磁盘。在这种情况下，我们将有 65 个 VMDK 需要进行哈希计算。假设主机缓存使用了 2 GB RAM（最大大小），那么 2048 MB +（65 * 24 MB）= 总共将使用 3.5 GB 的内存。

管理 CBRC

在 VMware View 中，CBRC 位于 vCenter Server 配置的 Host Caching 标签下。可以启用并定义分配给主机的总 RAM 缓存大小。每个主机的缓存大小可能不同，但建议在 vSphere 集群中保持一致性。

在创建桌面池的过程中，管理员可以定义该池应使用 CBRC，选择要为其创建摘要文件的磁盘类型，以及摘要文件应该多频繁地重新生成。

以下选项通过 /config/CBRCFilter/intOpts 显示，并可通过 VMware vSphere Client 高级配置进行查看。VMware View 内置有管理以下选项的功能，建议不要手动修改这些项目：

• /config/CBRC/intOpts/DCacheMemReserved: CBRC 数据缓存所消耗的内存（以 MB 为单位）。

• /config/CBRC/intOpts/DCacheSize: CBRC 数据缓存的大小（以 MB 为单位）。如果CBRC.Enable设置为1，则此值不能更改。

• /config/CBRC/intOpts/DigestJournalBootInterval: 为避免干扰启动过程，Digest Journal 临时禁用的时间间隔（以分钟为单位）。

• /config/CBRC/intOpts/Enable: 启用基于内容的读取缓存（CBRC）。

需要注意的是，在某些条件下，不支持视图存储加速器，包括：

• 使用视图组合器阵列集成 API，这是 View 5.1 的技术预览功能

• 用于启用本地模式功能的桌面

• 当启用 VMware View 副本分层时。

视图组合器阵列集成

视图组合器阵列集成（VCAI）是 VMware View 5.1 中的一项技术预览功能，允许管理员在 VMware View 和 View Composer 的正常管理工作流程中利用存储本地快照功能。

VCAI 通过vSphere vStorage 阵列集成 API（VAAI）与网络附加存储（NAS）合作伙伴的本地克隆能力集成。VCAI 加速了在自动化池中链接克隆虚拟桌面的配置，帮助减轻 CPU 消耗和网络带宽压力。

建议阅读VMware 终端用户计算博客，网址为blogs.vmware.com/euc/2012/05/view-composer-array-integration-tech-preview.html.

支持在 NAS 上的集群中最多 32 个（从 8 个增加到 32 个）主机

直到 VMware View 5.1，任何支持 VMware View 部署的 vSphere 集群仅允许最多 8 个主机的集群。此限制的原因是 VMFS 限制了可以同时对单个文件（副本磁盘）执行 I/O 操作的主机数量。

这在谈到 NFS 导出时从未成为大问题；然而，这一限制是硬编码在 View Composer 中的，这个工具负责创建链接克隆。

在 VMware View 5.1 中，这一限制已被移除，View Composer 将支持最多 32 个主机的集群，前提是底层存储文件系统和协议为 NFS。这一更改彻底修改了许多基于 NFS 集群的 VMware View 部署架构。由于这是书中的一个后期补充，其对 NFS 支持的主机数（从 8 个增加到 32 个）将通过未来的博客文章或附录进行详细说明。

独立视图组合器服务器

VMware View Composer 是负责创建链接克隆的软件下载程序，现在可以安装在除了 vCenter Server 之外的其他服务器上。此举旨在推动高度可扩展的 VMware View 架构。

上述截图展示了可以配置独立视图组合器服务器的配置选项卡。对于需要保护 VMware vCenter Server 和 VMware View Composer Server 的弹性和性能的大型环境，这是理想的配置。

可自定义一次性磁盘驱动器字母

VMware View 5.1 增加了指定临时磁盘驱动器字母的功能。过去，临时磁盘会使用桌面上第一个可用的驱动器字母。VMware View 仍然可以通过将驱动器字母选项设置为自动模式来自动选择驱动器字母，如下图所示：

上图显示了临时磁盘驱动器字母的配置选项卡。

用户体验和客户端功能

VMware View 5.1 进行了大量改进，直接影响到用户体验。VMware View 和 Teradici PCoIP 在每次发布中都在不断演进。比较 VMware View 4.x 和 VMware View 5.1 的最终用户体验，显示出了非常显著的改进。

VMware View 5.1 在多个用户体验和客户端方面进行了增强，包括本地模式和 USB 重定向。

VMware View 本地模式的增强功能如下：

• 多显示器支持

• 磁盘 I/O 性能改进及减少重复数据删除 I/O 成本

• 支持通过 TCP 的 DNS NAT

• 本地模式磁盘一致性验证

• 支持虚拟硬件版本 8

• 改进的 NAT、DNS 解析性能、链路状态传播

• 一键发送Ctrl + Alt + Delete键盘快捷键

• 自动化支持销售点操作

• 数据完整性和安全性强化

VMware 还在 VMware View 5.1 中重新设计了 Windows 客户端的 USB 堆栈。USB 的增强功能如下：

• 更广泛的设备支持

• 新的过滤机制，用于通过组策略更好地管理客户端上的设备

• 支持 USB View 客户端的多平台

• 新的过滤机制，用于更好地管理代理上的设备，允许阻止不需要的设备以及通过其他方式转发的设备（例如键盘/智能卡），可通过组策略进行配置

• 设备驱动程序不再需要在客户端机器上安装

PCoIP 也有少量的增强功能。这些增强包括减少客户端上解码 PCoIP 帧的 CPU 使用率，从而最终改善协议性能。

管理和操作

虽然 VMware View 被证明相对易于管理和操作，但仍然存在一些需要改进的领域，包括一些基本的 UI 功能，例如右键。在 VMware View 5.1 中，UI 和管理方面有了若干改进。

用户界面增强和本地化

VMware View 5.1 中的用户界面焕然一新，外观更为简洁且响应更快。VMware View 还支持五种不同的外语本地化（法语、德语、日语、韩语和简体中文）。

在用户界面中新增了右键功能，帮助简化管理桌面池、权限和桌面的过程。

支持预创建的 Active Directory 计算机账户

利用预创建的 Active Directory 计算机对象是一个很好的补充，适用于那些由于安全规范需要创建自己的 Active Directory 计算机账户的组织，或者因为现有的自动化流程要求在用户加入组织时确保创建 Active Directory 对象。

上面的截图展示了配置标签，用于允许使用预先存在的 Active Directory 计算机账户。

VMware vCenter 和 View Composer 高级设置

VMware View 用户界面现在允许管理员指定最大并发的配置和维护操作数。此前，用户界面仅提供电源和 vCenter 并发操作的配置选项。

建议在生产环境中不要更改默认设置，因为这可能会影响用户体验；这是因为在进行大量配置或维护任务的环境下，可能会产生显著的 IOPS，从而影响到所有当前用户的使用体验。

上面的截图展示了配置标签，用于指定操作最大值。

电话回家

这是一个在安装时可选择的选项，用于收集匿名的 VMware View 使用统计信息。所有数据都会被匿名处理且无法追踪，电话回家将收集有关版本、使用的功能、系统架构选择以及部署规模的信息。

VMware 旨在利用这些信息提供更好的支持并增强最受欢迎的功能。此外，VMware 认为此数据收集将有助于更好地调整 View 产品的研发优先级，以便与现场客户的使用需求匹配。

上面的截图展示了配置标签，用于启用电话回家支持（参与匿名用户体验改进计划）。

配置文件管理

在 VMware View 5.1 中，用户配置文件管理也得到了增强。尽管许多组织将继续使用像 Liquidware Labs ProfileUnity 这样的第三方解决方案，VMware View 中的本地配置文件管理正逐步发展为更为可接受的解决方案。View 5.1 对配置文件管理的增强包括：

• 允许物理机器的虚拟配置文件管理

• 一次性从 Windows XP 升级到 Windows 7 的迁移功能

VMware View 配置文件管理现在提供对物理机器的配置文件支持，帮助用户从物理桌面过渡到 VMware View 桌面。如本书前面提到的，从 vDesktop 中提取用户配置文件（通常在非持久性解决方案中使用）可以更容易地将用户从物理桌面迁移到 vDesktop。

在物理到虚拟的迁移过程中，管理员可以首先在物理桌面上安装 View Persona Management，当用户使用启用了 Persona 管理的虚拟桌面时，用户数据和设置会自动同步。

VMware 还支持一次性从 Windows XP 迁移到 Windows 7。

安全

安全性是 VMware View 5.1 中的一个重要主题，包括安全加固和修复。安全性是许多组织采用 VDI 的主要驱动力。产品在安全领域的持续改进突显了 VMware 对高度安全环境的承诺。View 5.1 的发布包括以下安全增强功能：

• 支持多种双因素身份验证与 RADIUS 支持，包括 RSA SecurID、VASCO DIGIPASS、SMS Passcode、SafeNet 等供应商。

• VMware View 管理员会话超时： 会话超时选项一直存在，但现在可以由管理员进行配置。

• SSL 证书安全增强： VMware View 5.1 现在会在使用自签名证书时发出警告。管理员必须验证自签名证书的使用。VMware 建议使用受信任的证书颁发机构（CA）服务。

上面的截图展示了启用 VMware View 管理员会话超时的配置选项。

上面的截图展示了使用自签名证书时生成的错误。

摘要

VMware 通过收购、内部研发、客户反馈、合作伙伴支持（如 Teradici）以及社区参与，持续推动 View 产品的发展。由于本书在 View 5.1 发布时已经完成并处于最终出版阶段，作者认为概述新内容非常重要。欲了解更多信息，请参阅博客myvirtualcloud.net/和www.thinkvirt.com/。

附录 A. 额外工具

每个 VDI 架构师都有自己偏好的工具集。这个工具集可能包括 I/O 压力测试工具，如 Iometer 或某些 Visio 模板。附录提供了一些可以帮助设计过程的工具推荐。虽然设计过程中不一定需要使用这些工具，但它们可能对许多人有帮助。

VMware RAWC

VMware RAWC（现在称为 VMware Desktop Planner）是一个用于测试 VMware View 环境的工具，测试内容包括 PCoIP 流量和 vDesktops 上的生成工作负载。此工具仅提供给 VMware 合作伙伴，并通过 VMware Partner Central 网站提供。然而，个人顾问可以作为低级别的 VMware 合作伙伴自行注册，并获得该工具的访问权限。你可以在 www.vmware.com/ 获取该工具。

VDI Fox

VDI Fox 是一本由本书作者开发的基于 iOS 的应用程序。VDI Fox 使用了 myvirtualcloud.net VDI 计算器中的逻辑，这些计算器已成为行业标准，并将其带到了 VDI 工程师掌中。此外，VDI Fox 通过一份问卷引导用户进行 VDI 设计，帮助各级 VDI 工程师在 VDI 设计中找到方向。

预计 VDI Fox 将在 2012 年 6 月的 iTunes 应用商店上线。有关 VDI Fox 的最新信息，请访问 www.redfoxllc.com/ 或关注 Red Fox 的 Twitter 账号 @RedFoxLLC。

网站和社交媒体

由于 VMware View 具有非常活跃的社区，互联网中有大量与 VMware View 相关的信息，这些信息来源于各类网站、Twitter 和 VMTN 论坛。

以下网站提供了关于 VDI 技术的精彩内容：

• itbloodpressure.com/

• www.vladan.fr/

• blog.simonbramfitt.com/

• communities.vmware.com/index.jspa

此外，使用社交媒体是组织了解他人在 VDI 领域所做工作的好方法（使用 #VDI 标签可以根据 VDI 相关话题进行过滤）。以下人员在 Twitter 上值得推荐：

• @dlink7

• @simonbramfitt

• @brianmadden

• @etrnjanin

• @vladan

• @vdiinfo

• @vmwjourney

• @thinapp_pso

• @terastu

• @roidude

• @ronoglesby

• @vmwareview

此外，像 BriForum 这样的 VDI 相关会议，应该能提供大量关于当前 VDI 趋势的信息。

要查看更新后的推荐网站、iOS 应用信息以及 Twitter 粉丝列表，请访问 www.redfoxllc.com/ 并浏览该书的相关部分。