Citrix 虚拟桌面快速部署手册——规划设计篇-USB迷|专注于互联网分享

2024年2月9日发(作者：门紫萍)

Citrix 虚拟桌面快速部署手册——规划设计篇

修正历史

修正改变说明

V0.1 原始文件

更新者日期

Eric Yao 2013年3月17日星期日

V0.1 uploaded to wiki Martin Liu 2013-7-10

产品版本

产品

SQL Server

XenDesktop

XenApp

XenServer

版本

2008 R2

2008 R2 Express

5.x

6.x

Windows Server 2008 R2

第1章关于方法论

Citrix虚拟桌面快速部署手册会紧密遵循Citrix顾问实施方法论，将整个实施的过程划分成四个阶段，即如下图所示：

[1] Access 评估

Access阶段主要提供Design阶段所需要的信息，包括：

1. 业务驱动力；

2. 数据搜集：包括用户、应用程序、设备以及基础架构；

3. 用户的分类：用户要根据需要的分类而分成不同的组别，随之应对着不同的FlexCast方法论；

4. 应用程序分类：旧的应用程序应该被删除、应用程序版本应该标准化、非公司程序应该删除，等等这些构成了应用程序的标准化和合理化；

5. 计划：每个用户组都要根据对业务的影响程度指定不同的实施时间优先级，优先级实施进度结果应该随时更新项目进度和计划。

[2] Design 设计

设计阶段主要聚焦在五层的一个方法论上：

1. 用户层：描述推荐的终端以及所需要的用户功能体验；

2. 访问层：描述用户层是如何连接到他们的桌面，例如本地桌面是直接连接StoreFront，而外界用户往往要通过Firewall层才能进来，这就涉及到了FW、VPN等技术；

3. 桌面层：主要指用户的虚拟桌面实现技术，即FlexCast技术，主要好汉三个主要成分，分别是镜像文件、应用程序，以及个性化内容；

4. 控制层：如何管理和维护其他层，又分为访问控制、桌面控制，以及基础架构控制；

5. 硬件层：致力于支撑整个解决方案的硬件物理设备，包括了服务器、CPU、内存、存储设备等；

[3] Deploy 部署

按照第二部分设计好的FlexCast方式实施。

[4] Maintain 维护

主要包含三种不同的活动：

1. 监控：在虚拟桌面环境设计和实施到生产环境以后，持续的监控是必需的。

2. 技术支持；

3. 测试和变更管理：以后会遇到不断的软件和产品更新；

4. 项目计划

一个设计详尽的项目计划对项目成功的实施时至关重要的。项目经理要通过项目计划来监控成本、管理项目组成员、跟进项目实施进度等。同时项目进度要及时通告项目组所有成员让大家都知道项目的进度。

在项目的初期一般只需要做Access阶段的计划，这个时段需要多FlexCast模式、容量、用户分组等有更多的交接，所以无需做Design的计划。如下图所示就是一个计划表：

第2章访问及评估

2.1 业务驱动力

桌面虚拟化项目的第一步应该是去了解对公司所造成的影响，并且将这些影响一一定下来，然后对之以优先级排序。有了这些文字描述管理层和项目管理组才能制定出项目成功实施的标准，设计阶段才能有正确的方法论和架构设计。

下图就定义了一个业务驱动力的优先级示例：

2.2 数据搜集

数据搜集阶段负责搜集关键信息数据，包括用户、设备、应用程序，以及基础架构等在下一阶段需要使用的数据。

有三种方法来搜集数据：

1. 手动搜集

小型企业有可能通过访问每台终端，或者是远程连接凡是来搜集数据。

中大型企业一般般都有了ESD（Enterprise Software Deployment），例如微软的SCCM等。可以通过这些平台去搜集应用程序的使用情况等信息。但是ESD一般都不能提供应用程序性能需求和实际使用的信息。

1. 调查表

这也是一个好办法，可以通过管理层去通过行政命令来执行。也可以通过面对面的会议或者是电话沟通来进行；这种方式比手动搜集要显著减少了所花费的时间，但是完成率不高也是一个缺点，不够精确反应实际情况也是一个缺点。

1. 自动化搜集

这样的工具有很多，一般都能自动化生成报表。Citrix公司为了帮助用户节省实施成本，和LanDesk公司合作，为Project Accelerator用户提供了一个60天免费试用的LanDesk FastTack 软件License。LanDesk FastTack 软件是一个专门为Citrix实施方法论开发设计的一个专业信息搜集工具。

上述三种方法的优势和劣势如下表所示：

2.3 用户数据搜集

信息搜集表可以参考示例表格：Citrix Virtual Desktop Handbook - Assess

1. 业务特性

业务特性必须通过业务层的管理人员来手动搜集，无法自动化搜集。包括

1. 身份

1. 用户名

2. 部门；

3. 角色

4. 业务经理

5. 所分配的用户组；

2. 业务

1. 主要的数据中心

2. 移动性，下表是示例分类

- 个性化

- 安全性

- 关键性

- 技术特性

1. 工作负荷

- 用户环境

1. 用户Profile

1. Profile类型：包括本地、漫游、强制、第三方、未知

2. Profile版本：Windows XP和Windows Vista/7

3. Profile位置：文件服务器在哪里

4. 大小：用户Profile的大小

2. 用户数据主目录

1. 主目录位置

2. 大小

3. 客户端硬件，包括以下需要搜集的信息：

o Number of CPUs/Cores

o CPU Speed (GHz)

o Memory (GB)

o Disk Size (GB)

o Operating System

o Age of the System (years)

o Peripherals

1. 本地资源映射，包括以下需要搜集的信息：

o Local Drives

o Printing

o Clipboard

o Audio

o COM Port

o USB

o LPT

2.4 应用程序数据搜集

信息搜集表可以参考示例表格：Citrix Virtual Desktop Handbook - Assess

1. 身份信息

1. 应用程序名称和版本

2. 应用程序所有者

3. 状态

2. 应用程序技术特性

1. 分配

1. 使用者数量

2. 部门信息

3. 个别用户

2. 工作负荷

- 业务特性

1. 兼容性

2.5 用户分类

一旦数据搜集工作完成之后，我们就可以开始准备将用户分成不同的组了，这个时候就要按照FlexCast模型的要求去分配不同的实现方式给不同的用户组了。

我们一般都是按照人物性工作者、分支机构办公人员、移动工作者等方式去区分用户，但是实际上用户的分类远不止这几类，更有甚者，很多用户组都是同时属于上述几个组的。

最快区分用户的方法就是按照用户的需求不同来分组，一旦将用户的需求区分之后，就可以将这些数据填入Citrix Virtual Desktop Handbook - Assess

了。

2.5.1FlexCast模型比较

1. Hosted Shared

2. Hosted VDI，又可以细分为

1. Pooled-Random/Streaming

2. Pooled-Static

3. Pooled/Streamed with Personal vDisk

4. Dedicated

5. Existing

6. Psysical/Remote PC

3. Steamed VHD

4. Local VM

5. On-Demand Apps

下表是关于FlexCast整体技术的一个概览：

2.5.2FlexCast模型选择

在XenApp和XenDesktop之间有很多技术上的区别，但是他们都是通过HDX来提供的最佳用户体验。他们的区别如下：

2.6 应用程序评估

在用户分组完成之后，我们已经有了根据需求不同确定下来的不同的用户组，下一步就是向用户提供他们工作需要的应用程序。下面是建议的三部曲：

1. Rationalization 合理化

2. Business Characteristics 业务特性

3. 兼容性

2.7 项目管理

2.7.1Roadmap

2.7.2项目团队

下面的表格示例告诉我们在一个虚拟桌面项目中可以建议的业务角色和技术角色分类。虽然角色有很多种，但是很多角色的存在时间都很短，同时很多角色都由一个人同时完成。项目经理和Citrix架构师自然是贯穿整个项目的角色，其他就不一定了。

1. 业务角色

- 技术角色

第3章设计原则

3.1 概况

桌面虚拟化的设计并没有想象中那么简单，但是也绝不复杂，我们需要做的事情就是去遵循一定的设计理念以及已经被验证过的实践经验就可以了。简单说来，我们可以从桌面虚拟化涉及到的五层设计模型入手：

3.2 用户层 User Layer

设计模型最上面的一层就是用户层，用户层和每个用户组息息相关。这一层将业务优先级的评估标准和用户组需求结合起来，进而可以定义有效的终端设计战略。

3.2.1终端类型的选择

终端一般有多种类型，每种都有不同的能力：

 Tablet based on Android or iOS 基于安卓或者iOS的平板电脑

 Laptop 笔记本电脑

 Desktop PC 桌面PC

 Thin Client 瘦客户机

 Smartphone 智能手机

1. 决断：终端所有者

在上一讲的Access章节中有一个小节是《Error: Reference source not found用户分类》，这一节的内容将决定个人设备的可用性。并且至少包含以下用户终端的特性：

安全性：高风险区的用户不能携带个人设备进入该区域以防止数据外携；

可移动性：例如用户个人设备将不适合用于离线的Local VM（即XenClient模型）；

关键性：被评价为高关键业务的用户需要额外的冗余设置

FlexCast模式：例如个人所属设备就不适用于例如Steaming VHD、Local VM模式以及Remote PC模式。

下面的图显示什么时候使用用户自己有用的设备，什么时候选择工资拥有设备：

- 决断：终端生命周期

最小标准：即使是考虑到成本因素，为了保证用户体验，还是要不低于最小的硬件标准，这些指包括：1GHz的处理器、1GB的内存、16GB的空余磁盘空间，如果是要好的HDX体验还要有GPU卡；

业务驱动：所有项目成功都来自于正确确定优先级。对一个公司来说，延长PC的折旧期对成本节省来说很重要，而公司更多考虑的是绿色环保因素，可能新购终端反而更有利。最终需求还是要考虑《Error: Reference source not found：业务驱动力》

工作负荷：工作种类应该和FlexCast模型相互配合

下面的表格列出了当我们准备重新利用现有的硬件，亦或者是新购设备时的推荐计划：

- 决断：终端规格

瘦客户机的处理能力已经极大的增长，即使是中等的手机现在也能够实现图形处理能力了，包括HDX特性等都不在话下，例如多显示器支持等等。

很多企业都会将瘦客户机和PC混合部署，我们需要记住的是用户组的特性才是最终决定需要采用哪种模式的最重要因素：

- 决断：瘦机选择

瘦机厂商现在有越来越多的OS选择了，常见的有Windows Thin PC（基于Windows

7），嵌入式的WinXP、Win7和Win8、Linux变种，甚至零客户机。我们在选择时，需要考虑以下因素：

用户的工作负荷：对于人物性工作者，或者是有限需求的知识性工作者来说，Windows Thin PC和类似于Dell Wyse 零客户机是最好的选择；能实现更多功能的Windows嵌入式适合于图形用户、对CPU有更高要求的研发用户等场景；

内行专家：许多公司都已经有了可以管理瘦机基础架构的管理工具集。建议充分利用这些管理工具的管理专家们。

License成本考虑：Windows Thin PC和嵌入式Windows操作系统就肯定要涉及到额外的OS成本开销；而定制的Linux就没有这个问题。但是，在Linux平台上可能媒体解码器却会碰到License的问题。

3.2.2Receiver的选择

1. 决断：Receiver的类型

大部分的企业都知道将Citrix Receiver简单的部署在兼容它的终端上，但是实际上Citrix Receiver在部署了不同的插件之后，功能还是有着很多的不同的。所以，确定用户组的需求就决定了如何选择Receiver的类型。

这里本来有个表格的，可是太大了，建议大家直接看pdf文件的Page 44.

我个人以前就对Citrix Receiver和Citrix Receiver Enterprise版本有什么不同就有疑惑，在这个表中就诠释得非常清楚了。前者没有Desktop Lock功能和非接触式智能卡功能，而后者就没有通过Merchandising Server的插件管理功能

除此之外，其他我能够看到的差别还有：



对XenApp的支持中，Win8/RT、黑莓、HTML5上的Receiver就只能部分支持；

而XenDesktop功能基本上所有版本都支持；

基于Email地址来配置Receiver：除了黑莓和HTML5的Receiver客户端，其余都支持；

智能卡支持：所有平台均支持；

快速访问/非接触式智能卡：目前只有Citrix Receiver Enterprise版本支持；

Flash重定向：只能在Citrix Receiver、Citrix Receiver Enterprise、Receiver Linux版本上支持，其他例如MAC、HTML5以及所有平板和智能手机统统不支持，online plugin也不支持哦；

UDP语音：只在Citrix Receiver和Citrix Receiver Enterprise版本、Receiver MAC、Receiver Linux版本上支持；



Pre-Launch功能：只支持Citrix Receiver和Citrix Receiver

Enterprise版本；

AERO特效：Windows的玩意当然只有Citrix Receiver、Citrix Receiver

Enterprise版本以及Windows 8/RT的Receiver才支持；

磁盘重定向：除Win8/RT之外所有的平板、智能手机以及HTML都不支持，

剪贴板支持：只有 Citrix Receiver、Citrix Receiver Enterprise版本和Receiver MAC才支持，Linux版本的也不支持哦！

HDX 3DPro支持：只有Citrix Receiver和Citrix Receiver Enterprise版本完全支持，Linux、MAC、Win8/RT都是部分支持；

ShareFile：黑莓、HTML5、Win8/RT不支持，其余都支持；

AG的远程访问：Citrix Receiver、Citrix Receiver Enterprise版本和Receiver MAC需要安装插件才支持；Linux不支持哦！Win8/RT、安卓、苹果天生就支持，至于HTML5，不好意思。

离线应用程序：只有Citrix Receiver和Citrix Receiver Enterprise版本支持；

单点登录：只有Citrix Receiver和Citrix Receiver Enterprise版本支持；这个要注意一下；

StoreFront支持：黑莓、Linux和HTML5不支持；

Desktop Lock：只有Citrix Receiver Enterprise版本支持，Citrix

Receiver都不支持哦！

- 决断：Receiver部署

在部署和升级Receiver时，以下机制可以考虑和利用：



StoreFront：如果Citrix StoreFront已经安装，管理员就可以通过一个Web站点来部署Receiver，用户只需要打开网页就能自动安装；

内部下载站点：有时候用户会被禁止访问互联网，那么管理员就可以创建一个内部站点来安装Receiver。典型的模板可以参考Citrix Receiver

Download Page Template主页，它包含了所有版本Receiver的下载软件和自动安装方式。

Web Interface：这是我们最常见的方式，不过要注意的是，他不支持基于电子邮件帐号来发现的安装方式。基于电子邮件帐号来发现的安装方式对BUOD来说非常合适。

Windows Store：在Windows 8 Store里面可以下载到Windows8/RT的Receiver软件。目前Receiver只支持ARM或者是基于Intel芯片的Windows8/RT设备。

移动设备：移动设备一般都有自己特殊的方式来安装软件，例如

应用程序商店：包括安卓的Google Play，或者是Apple的Apple

Store；

其他移动部署方法：有的移动平台可以提供企业级方法来部署，例如黑莓就可以通过BlackBerry Enterprise Server来部署BlackBerry平台上的Receiver；



Merchandising Server：这也是一种方法。除此之外，Merchandising

Server还能够用来升级Receiver以及安装Receiver的插件，它可以定期连接到Citrix Update Service去检查有没有最新的软件。

Master Image：这个办法最简单，直接将Receiver做到操作系统镜像文件中；Receiver的升级可以通过Citrix Receiver Updater Plug-in，或者是Merchandising Server，也可以是其他软件分发工具；

软件分发工具：例如LANDesk、MS的SMS，以及Symantec Altiris；

组策略：可以自己写一个启动脚本来部署Receiver，甚至卸载Receiver，在XenApp和XenDesktop安装光盘里面也自带了这个脚本；

手动安装：所有版本的Receiver都可以在Citrix Receiver Download

Page 下载到。用户只要登录到这个站点，网站会自动检查终端的类型和下载介质。唯一的缺点是你还要手动配置Receiver的连接属性。最好的办法是通过基于电子邮件发现的方式。这种方式最适用于BYOD环境。

下面的表格总结了每种方法适用于的Receiver版本，因为表格太大，请大家自行参考第48页。

- 决断：Receiver配置



基于电子邮件的自动发现和配置：最新版的Receiver可以通过只需要输入自己的公司邮箱就完成配置。这个功能需要StoreFront以及指向StoreFront服务器的FQDN域名的一条SRV记录；

注意：DNS平台需要支持基于电子邮件的发现，目前只有Windows

DNS测试过；

如果是远程用户，就必须配合Access Gateway，同时在DNS中有对应的SRV记录；此外，在Access Gateway硬件或者是StoreFront服务器上必须有有效的服务器证书。

组策略：启动脚本也可以用来配置Receiver。脚本中有一行这样的参数：SERVER_LOCATION=Server_URL. 缺省的值是空,将Web Interface或者是StroeFront的地址输入进去

Provisioning File：如果是运行了StroeFront的环境，我们就可以从StoreFront服务器中到处一个.cr为扩展名的文件，然后将此文件放到共享文件夹，或者是发布到网页中，用户下载后双击可以自动打开该文件并继续自动配置。

自动生成的设置URL：对于移动设备和MAC桌面来说，可以通过一个叫做One Click Provisioning的工具来创建一个设置URL来进行配置。管理员只需要在这个工具中输入所需要的信息，该工具就会自动生成URL。由于该工具并没有包含用户名和密码信息，所以可以将该地址通过电子邮件发送给用户，又或者将该URL发送至文件共享服务器中亦可。该工具对远程用户，Web Interface等适用。

手动：不多说，呵呵。

- 决断：Receiver升级

Merchandising Server：对于支持Citrix Receiver Updater Plug-In平台的Receiver来说（Citrix Receiver, Citrix Receiver Enterprise,

and Citrix Receiver Mac），Merchandising Server是最适合用来保持Receiver以及Plug-In升级的方法了。Citrix Receiver Updater Plug-In负责和Merchandising Server保持定期通信以升级必须的组件。



软件分发平台：例如LAN Desk和Symantec Altiris等平台；



手动升级：最后一个，也是最有效的办法。



3.2.3资源需求

无需多言硬件参数，包括服务器的CPU、内存、硬盘以及后台的网络设备、存储有多重要了，其实更重要的是在性能和成本之间达到一个最佳的平衡。

我们首先将用户组按照性能需求分为四种性能组：

至于Scalability Assumptions，按照以下内容来估算：



CPU的速度：按照2.7GHz和Intel Westmere处理器架构来设计；

超线程：超线程可能可以达到20%-30%的性能增长，但是有时候也会带来负面效应。我们设计时都是不算超线程的；

工作负荷：假设已经加载了防病毒软件和标准的监控工具；

Hypervisor开销：已经从每用户core中减去；

内存：大部分用户在一天中所使用的内存都在不同程度的增长，原因有很多；因此，内存应该算最大值。

- 决断：CPU

下面的表格实力了在不同负荷用户情况下每物理CPU core所能支撑的用户数。此外，需要注意的是从两路CPU到4路CPU性能并不是线性增长的，我们要预留15%的用户数降低；

此处注意的是，如果你采用了PvD技术，经我们测试显示，大概有14%的性能下降，记住要把这个因素考虑进去。

另外，PvD在5.6.10版本及之后的版本都不再支持WinXP，所以目前没有XP下的数据。

下面的表格可以用来计算每个用户组所需要的CPU资源：

物理CPU核数 = 用户组的最大CCU数量 / 每个物理core所支撑的用户数

- 决断：内存

下面的表格列举了在不同负荷和FlexCast模式下所需要的内存数量：

- 决断：IOPS

见下表：

需要注意的是上面的数字都是稳定状态下的，不是峰值状态。

裸IOPS = 写IOPS×写惩罚 + 读IOPS

写惩罚的规定：

- 决断：存储空间

在PVS环境下，所有对虚拟桌面的写操作都是发生在写缓存中，但是在MCS模式下，写操作确实发生在Diff Disk中。写的内容包括：

User Profile



系统临时文件和应用程序临时文件



Windows、Citrix和应用程序的日志文件



PVS模式的写缓存和MCS的差异磁盘所需要的磁盘空间取决于应用程序的使用量和用户的动作。不过，下面的表格有一个大概的评估值：

几点注意事项：

1. PVS写缓存启动时最小，但是使用过程中会不断增长。重启VM后被清除；

2. 在某些情况下需要将数据重定向到写缓存的磁盘中这样在重启时也能保留，例如EdgeSight数据、Windows日志和防病毒软件的定义库文件；

3. 包含了10G的PvD数据磁盘大小；

4. MCS模式下推荐使用NFS的存储以利用Thin Provisioning能力；

3.3 访问层 Access Layer

访问层的设计主要是基于每个用户组和终端设备的移动性需求。

1. 决断：认证点

让用户在什么地点做认证是管理员的决定，一般而言，有四个认证点：

1. Web Interface：给XA和XD提供安全访问；

2. StoreFront：为Receiver交付认证能力和资源；

3. Secure Gateway (Web Interface): Secure Gateway是一个Windows的应用程序，她和WI配合工作；

4. Access Gateway: 硬件

具体采用哪种方式认证由用户组的移动需求来决定，推荐方案如下：

- 决断：预认证策略

如果我们使用的是Access Gateway，我们就可以选择是否采用预认证策略，这些策略可以是确定终端是否满足某种接入网络前的扫描条件。

我们可以配置的策略包括测试防病毒软件、防火墙软件、操作系统，甚至是注册表键值。XA和XD可以利用这些策略的检查结果确认后续的动作，包括剪贴板是否开启，打印机映射，甚至是否开启特定的应用程序访问权限。例如，如果用户没有安装防病毒软件，可以配置策略隐藏敏感的应用程序。

下面的图标从流程上示例策略配置是如何流转的：

- 决断：认证策略



Web Interface, Secure Gateway (Web Interface), or StoreFront:

StoreFront是未来的方向，而Web Interface已经是行将就木，所以下面的策略主要是用在StoreFront上，当然也适用于Web Interface

用户名/密码

Domain Pass-Through：允许从用户设备上透传Domain登录信息，用户登录到加入域的电脑后自动登录到Store；

Access Gateway Pass-Through：用户登录到Access Gateway后自动登录到Store



Access Gateway：NetScaler支持几种不同的认证手段。下面分别列出了几种主要的认证方法，每种方法都可以单独使用，但是在实践中，我们进场组合起来以提供多因素认证。

LDAP：轻型目录访问协议是我们最为熟悉的认证方法了，它是一种基于TCP协议的目录访问服务，例如MS的活动目录就是其中一种实现形式。

Radius（aka Token）：Radius全名是Remote Authentication Dial

In User Service，这是一种基于UDP传输协议的安全认证协议。除了认证外，它还提供授权和计费功能。Access Gateway转发用户输入的用户名和密码给Radius服务器，Radius服务器可以立即检查用户名和密码，也可以转发给目录服务器。

客户端证书：用户登录到Access Gateway虚拟服务器后，可以通过本地的客户端证书的属性来做认证。客户端证书通常在用户端的形式是智能卡，或者是Common Access Cards (CACs)的形式，再通过客户端本地的读卡器来读取信息。

采用什么认证形式通常都是取决于安全的需求，以及使用什么认证点。下表给出了一个基于安全需求级别的示例：

- 决断：会话策略

采用Access Gateway作为认证点的用户必须有对应的会话策略来定义用户体验。会话策略的制定是基于Receiver在设计阶段制定的。一般而言，首先我们会将设备分为非移动设备和移动设备两种：

移动设备：表达式定义为：“ User-Agent CONTAINS

CitrixReceiver”，该语句将移动设备设置为比非移动设备更高优先级以保证移动设备的匹配性。



非移动设备：表达式定义为：“ns_true”，即所有流量。



更多信息，可以参考Citrix公开电子文档：Receiver and Plug-ins

BTW，另外一种会话策略是采用终端的扫描方法。

- 决断：会话Profile（Session Profile）

每个会话策略（Session Policy）都必须定义一个对应的Session Profile（姑且翻译成会话配置文件）。这个会话配置文件定义了用户去访问资源时的访问细节。有两种定义到虚拟桌面环境的访问方式的会话配置文件的形式：



SSL VPN：传统的VPN方式，将网络全部打通。这种方式并不一定十分安全，因为这能导致客户端到内网服务器的攻击访问。

另外一种办法是考虑是否在SSL VPN中开辟一条给客户端网络流量的单独通道。这样通过receiver的流量智慧限制在指定的端口，只能访问指定的服务器资源等。

上述两种方式各有利弊，第一种方式虽然安全性差了，但是可以做客户端流量可以被企业的网络过滤设备，例如入侵检测设备做监视和控制。

* HDX Proxy：在HDX 代理方式下，用户是通过Access Gateway连接到他们的虚拟桌面和虚拟应用。这种方式下完全没有将内部资源暴露到公网上，此时Access Gateway充当了一个微型VPN的作用，它仅处理HDX的流量。其他的流量，例如电子邮件，又或者是使用者上网的流量都不经过Access Gateway。

- 决断：访问带宽

最后的访问层决断就是要决定虚拟桌面所需要的最大并发网络带宽。其中很重要的一个关键环节就是决定采用NetScaler Access Gateway的哪一个平台。

每个用户所需要的带宽关键还是要看计算的需求。一个时不时才用一下电脑的ERP使用者和一个在电脑前屁股都不挪窝的OA用户肯定带宽要求是不同的，如果是CAD画图的用户那就更不用说了。

理想情况下带宽的使用情况是通过带宽分析工具来给出来，不过我们还是可以给出一些经验值：

总带宽的的计算公式可以这样来定义：

总带宽

平均带宽

最大并发用户值

更多细节，可以参考Citrix的知识库文章：

XenDesktop Planning Guide: User Bandwidth Requirements

3.4 桌面层 Desktop Layer

设计思想的第三层，也是和用户相关的最后一层，就是桌面层。用户是否能接受桌面虚拟化很多程度上就是在这一层实现的，例如包括个性化、应用程序，以及后台操作系统镜像文件的设计。

3.4.1应用程序交付

选择正确的应用程序交付方法会对整个系统设计的可扩展性、可管理性，以及用户感受起到非常大的帮助。基于我们在前几章节的“Error: Reference source

not found”，我们可以考虑以下几种交付方法：

直接安装在操作系统镜像文件上：应用程序是基础操作系统镜像文件的一部分；



安装在Personal vDisk上：物理是分离的，但是逻辑上是直接安装在基础操作系统镜像文件中；



流化（Streaming）：应用程序被profiled（XenApp组件）后通过网络交付到桌面上。应用程序的文件和注册表键值在虚拟桌面的一个容器中保存，但是和基础操作系统镜像文件是分离的。



Hosted：应用程序安装在XenApp服务器上，用户通过Citrix HDX协议远程访问。



- 决断：应用程序交付方法

系统架构师应该在基于用户需求、应用程序兼容性，以及其他通过在前几章（“Error: Reference source not found”）搜集上来的应用程序因素基础之上决定采用何种方法来进行应用程序的交付。通常单一的方法是无法满足用户全部的需求的，所以多种方法组合才是最佳答案。但是不管用什么方法，这些交付手段都应当对整个项目的交付复杂程度和后续跟进步骤与以最小的影响。

下面的表格就是不同的交付方法对系统不同层面的影响：

除了应用程序交付方法对系统不同层面的应用之外，系统架构师还应该考虑应用程序在不同交付手段上的适用性。下面的表格就是不同应用程序所推荐的部署方法示例：

上表中需要注意的是最后一种应用程序，我们往往会觉得这种复杂安装和配置的应用程序最好是安装在操作系统镜像文件中，但是最佳实践告诉我们应该安装在XenApp Server上，通过Hosted的方法发布给用户。

- 兼容性

任何一个桌面虚拟化项目都会对一个公司的应用程序交付方法产生巨大的应用。举例来说，许多公司都希望通过在桌面虚拟化中使用流化的应用程序交付或者是XenApp交付应用程序来降低升级用户的桌面操作系统的劳动负荷以及提高管理

效率。所以在设计阶段我们就要做很多兼容性测试以确定最正确的应用程序交付方法。最重要需要考虑的兼容性需求一般来说包括以下几点：



桌面操作系统的版本：如果操作系统是通过流化安装或者是直接安装在操作系统中，那么应用程序需要考虑和操作系统的兼容性问题；

服务器操作系统的版本：有一些应用程序可能会更合适通过XenApp的方式来交付，所以，应用程序是否能安装在服务器版本的操作系统平台上是要考虑的因素；

应用程序本身的架构：应用程序本身的开发平台有可能是16位的，32位的，也可能是64位的。16位的应用程序就不能运行在64位的操作系统平台上，例如Windows 2008Server R2、Windows XP 64bits等；

互操作性：有一些应用程序如果和某些版本的操作系统共存是会有兼容性问题，例如注册表冲突、DLL冲突，或者是ini冲突。

应用程序流化：应用程序流化到桌面虽然可以简化管理，因为操作系统上不用安装那么多的应用程序了，但是记住有些带有设备驱动程序，或者是使用了COM+等应用程序就不适合了

在做应用程序兼容性测试时的三种主要技术手段有：

手动：不言而喻这种方法最消耗时间，每种交付方法都要测试，每种操作系统版本、不同操作系统语言包等也都要验证。手动模式下想要的出应用程序所有方面的测试结果是非常困难的，对应用程序互操作性的测试是几乎测不出来的。而且更多的测试结果是现场使用人员发现的，而不是测试时发现的。



预验证的应用程序：很多应用程序的开发商都会提供该应用程序的兼容性文档和最佳安装方式的文档。参考这些文档会有直接的帮助。此外，Citrix

Community Verified的网站上也有一整系列的由Citrix的客户和合作伙伴验证过包括采用流化方法/XenApp/Xendesktop兼容的应用程序列表。微软公司也提供了类似的应用程序列表：Microsoft Windows 7

Application Compatibility List for IT Professionals；



自动化的工具：Citrix AppDNA可以快速而且准确的对应用程序的兼容性做出精确的测试，包括测试不同的操作系统平台，测试不同的交付手段，例如Windows XP、Windows 7、Citrix XenApp、Microsoft App-V，以及Citrix Streaming流化交付方式等。应用程序被导入到AppDNA时，它会被和数千种应用程序进行兼容性的匹配验证以判断是否有互操作性问题。当发现问题时，AppDNA会告知问题出自何处，可能的解决办法，以及估计解决的时间。



上述每种方法的优点和缺点都列在下表中：

测试做完之后，兼容性的结果就应该填入到之前的应用程序评估表各种以便我们的后续分析：



预运行环境：许多程序都有运行环境的要求，例如Java、.Net环境，或者是数据库要求；

程序之间的依赖：例如，需要以pdf格式呈现信息的应用程序就需要电脑上安装了pdf的阅读器；

16位的代码：应用程序评估也应该判断是否应用程序包含有16位的代码，因为16位的代码是不能运行在64位的操作系统平台上；

Windows XP：确认应用程序是否能通过Windows XP的兼容性测试；

Windows 7：确认应用程序是否能通过Windows 7的兼容性测试；

XenApp 6.5：确认应用程序是否能通过XenApp 6.5的兼容性测试；

Application Streaming 应用程序流化安装：确认应用程序是否能通过流化程序安装的兼容性测试；

- 用户分类

通常不是所有用户都需要所有的应用程序，有些程序可能就只有很小一部分用户用的上。所以系统架构师应该做好这个工作，例如如果一个部门的用户都需要的应用程序列表组，我们可以单独做一个操作系统镜像文件。如果只有少部门用户需要使用，那我们建议采用Personal vDisk或者是Streaming的方式交付应用程序。

- 业务特点

IT经验：如果IT部门已经对某种应用程序交付方式有经验，或者是基础架构已经Ready了，那么这种交付模式可能就是合适的方式。例如，如果公司内部已经通过Microsoft App-V平台部署过Streaming的应用程序，那么XenApp Streaming 应用程序就应当优先被考虑。



管理需求：应用程序交付的方法很可能严重依赖于应用程序的拥有着。如果应用程序是公司拥有的程序，那么IT部门就有责任和义务来维护该应用程序，包括XenApp发布或者是XenApp流化。如果程序的拥有者是某个下级部门，那么IT部门就不方便集中管理，这种情况下应用程序可能就建议安装在Personal vDisk上，让部门自己来管理该应用程序。



升级频率：应用程序的升级所需要花费的时间和部门协调也对交付模式的选择有很大影响。如果应用程序经常升级，那么系统架构师就应当选择安装数量最少的交付模式，这样可以减少升级的应用程序数量，以及降低升级的复杂程度。这种情况西XenApp交付方式最为合适；



产品Licensing：如果应用程序没有License要求，例如和软件厂商签订了Site License，那么我们可以将该程序发布给所有的用户也不会产生其他任何成本，将该程序直接安装在操作系统模板里面也能降低交付的复杂性。如果应用程序对License很敏感，系统架构师就需要考虑采用一种能够遵守应用程序软件提供商要求的License模型。



- 技术特点

资源使用：如果应用程序对资源要求很高，可能会更合适于直接在虚拟桌面里面直接运行；



技术难点：如果一个应用程序的安装都很复杂，例如需要专门的配置，脚本的运行，或者对其他应用程序有很多要求，我们称之为技术难点。这种情况下，安装在XenApp Server上能减少操作系统镜像文件制作的复杂性。



3.5 控制层 Control Layer

控制层是设计架构的第四层。在上面有关用户的三个层面我们所做的决定都会汇总起来到控制层。

访问控制器子层的职责是给每个用户提供予以支持访问控制层的基础架构组件。这么说可能比较绕口，那就换个说法吧，访问控制器一般包括例如Web Interface、StoreFront，以及NetScaler Access Gateway；

3.5.1远程访问架构

如果有用户需要远程或者是离线的移动访问能力，那么就要设计远程访问基础架构了。

1. 决断：拓扑

网络拓扑的设计对远程访问架构能够支撑功能性、性能以及安全性至关重要。远程访问架构应当和安全团队一起合作以确保符合企业的安全规范。以下三种主要的拓扑结构我们在设计师可以考虑，每种的安全性逐渐递增：



1-Arm (Normal Security，单臂模式)：在这种架构下，Access Gateway使用一个物理的或者是逻辑的Bonded的网络接口，再加上VLAN和IP子网的设计，来传递用户和后台虚拟桌面的流量。

* 2-Arm (High Security 双臂模式)：在双臂模式下，Access Gateway利用两张或者更多的物理或者逻辑Bonded的网络接口卡，再加上VLAN和IP子网的设计，来传递用户和后台虚拟桌面的流量。前段用户的流量被导向这些网络接口卡的第一张网卡上，前后端的流量是被分离设计的，就是说说后端虚拟桌面架构服务器的流量是被定向到第二张网卡上的。通过这样的设计我们就可以DMZ区来分离前后端的流量，同时还可以定制防火墙策略和流量监控策略。

* Double-Hop DMZ (Very High Security): 这种模式既利用了双臂拓扑下的特

性，又使用了两个单独的Access Gateway设备。有一些企业使用了三个物理的/逻辑的防火墙结构来保护他们的内部网络。这三个防火墙将DMZ区划分为两个区域来提供额外的内部网络安全。

在第一个DMZ区的Access Gateway设备处理用户的连接，完成SSL VPN的安全功能。这个Access Gateway设备加密客户端连接，判断用户的认证方式，控制能够访问的内部网络服务器；

第二个DMZ区域的Access Gateway设备充当与一个代理设备角色。这个Access

Gateway设备启用ICA协议将客户端连接穿越第二个DMZ区到后端的服务器场。在第一个DMZ区的Access Gateway设备和内部网络的Secure Ticket

Authority（STA）也是通过第二个DMZ区的Access Gateway设备来进行代理的。

- 决断：平台

在Access Gateway部分，我们曾经讨论过只要是涉及到远程访问，我们都会考虑NetScaler Access Gateway设备。问了确定合适的NetScaler平台来满足项目需求，必须确定一些关键资源。由于所有的远程访问流量都是通过SSL（安全套接层）来加密，再通过HTTPs的HTTP（超文本协议）协议来传输。所以有两种资源metric需要确认：

SSL吞吐量：SSL吞吐量是定义为每秒钟能处理的GB SSL流量；



SSL每秒交易量（TPS）：TPS metric定义在每秒每个应用程序交付控制器（ADC）能处理的SSL交易数量



关于这两个参数的更详细解释，可以参考：Best Practices for implementing

2048-bit SSL

平均的SSL带宽开销在和虚拟桌面的开销比较起来时经常忽略。但是SSL带宽的计算将会有助于确定总带宽是否足够。固定带宽加上数据包头开销常常随着加密算法的不同而变化，总带宽开销也常常随着数据包尺寸大小的变化而不同。理想状态下，开销数字应当通过POC或者是Pilot来实际测试得来，但是在没有这些数据的情况下，在工作负荷带宽基础上加上2%是一个合理的数字。因此，在确定NetScaler平台的时候，SSL的吞吐量常常是最大并发带宽乘以1.02，即：

SSL吞吐量 = 最大并发带宽 × 1.02

例如：鸡舍128M是最大的并发带宽，那么最合适的NetScaler模型应当计算为：

约130Mbps = 128M × 1.02

NetScaler有三种平台，每种都提供了大量的不同的扩展性：

VPX：VPX平台的NetScaler和硬件的NetScaler提供完全一致的功能，不过他只适合于小型的测试环境使用。



MDX：NetScaler MDX是NetScaler设备的硬件版本。他能支持大型网络可扩展环境；



SDX：NetScaler SDX设备是在物理NetScaler设备和虚拟NetScaler设备之间的一个桥梁。一个SDX设备能够划分为多个虚拟的NetScaler设备。



3.5.2StoreFront

Citrix StoreFront是Web Interface的下一代产品，它验证用户连接到后台的XenDesktop站点、XenApp场，以及AppController（SaaS应用），然后枚举或者是聚合可用的桌面和应用程序到商店以便让用户通过不同操作系统平台上的Receiver来访问，包括安卓、iOS、Linux、Windows、Win8/RT以及Web站点。

- 决断：Web Interface还是StoreFront

Web Interface和StoreFront是两种不同的解决方案，在一些功能方面有重叠。所以我们要认真评估我们的需求。一般来说，新的方案应该使用StoreFront，因为Web Interface已经不再有新功能添加了。可以参考下面的链接了解Citrix

桌面产品的生命周期：Lifecycle Milestones for Citrix XenDesktop

下面的表格也示例了在何种情况下该使用什么产品：

下面的表格对两种产品在未来功能的开发目标上进行了一个对比，Web

Interface已经不再会有革命性的功能添加了：

下面的表格是功能对比：

有一些Web Interface有的功能也会被完全整合到未来的StoreFront新版本中去：

- 决断：Web 服务的高可用

如果StoreFront服务器不可用，或者是其他对应的Web服务不可用了，那么用户就不能连接到新的会话，例如打开新的虚拟桌面，无法打开应用程序等操作，因此，至少需要规划两台StoreFront来预防单点故障问题。我们可以考虑的方案包括：

DNS Round Robin：在多个服务器之间提供基本的负载均衡功能，无法做到是否可用性的检查；在服务器宕机时，部分用户会受到影响。



Windows NLB：是Windows的一个服务。可以做一些基本的检查来判断服务器是否可用，但是无法判断单个服务的状态。



Citrix NetScaler：智能硬件设备，能检查StoreFront服务的状态，根据用户请求主动激活负载均衡状态。



- 决断：应用程序订阅数据库的高可用

StoreFront的配置数据都存储在每一台StoreFront服务器的本地，然后被复制到服务器组中的其他的系统中。对比之下，用户应用程序订阅信息存储在应用程序订阅数据库中，该数据库可以是本地的StoreFront服务器，也可以是推荐的一个专门的Microsoft SQL Server。

如果应用程序订阅数据库不可用，以下功能将不可用：

用户不能在管理他们的应用程序订阅；



无法登陆至Web 方式的Reciever，但是已经建立起来的会话可以继续正常工作；



为了防止应用程序订阅数据库成为单点故障点，Citrix推荐SQL的高可用方案：

自动容错的SQL镜像：数据库镜像提供了一种比数据库Clustering更简单的快速容错方法。数据库镜像技术在每一个镜像点上需要一个标准的SQL标准版服务器License，在加上一个witness服务器的SQL Express

License即可。更多细节可以参考文档：Configuring StoreFront using

the Configuration Files.



SQl Clustering: 微软的技术，不过老实说，相比较Mirroring技术配置太复杂，此外，自动容错的过程也更慢。在License上，每个Cluster节点都需要一个企业版的SQL license。



Hypervisor高可用：数据库部署在一台虚拟机上，通过Hypervisor的高可用来实现。这个技术比镜像或者是clustering都要便宜，因为只需要一个SQl Express License和一台SQL Server（需要一个具备HA功能的Hypervisor License）。不过，这个技术容错过程较慢，也仅仅是当SQl

Server的操作系统宕机时才能启动容错机制。如果数据库服务出现错误是无法被Hypervisor层检测到的。



注意：未来的StoreFront版本将不会再使用应用程序订阅数据库（Application

Subscription Database），相反，预订信息会自动的在StoreFront服务器组中的StoreFront服务器中自动复制。

- 决断：容量规划

基于扩展性的测试，单个StoreFront服务器可以支持的用户数是无限制的，受限制的是在这个服务器上每小时之内用户同时操作的动作。这是因为仅仅当用户执行一个动作的时候，例如在Receiver中订阅一个应用程序是，StoreFront才被使用。当用户连接到所发布的资源时，StoreFront实际上是idle状态的。因此，下面的表格所展示的内容介绍的是没鸟的请求时，或者是每小时的请求数。我们建立了一个前提条件是每用户在每小时之内启动了五个应用程序，订阅了2个应用程序，取消订阅了一个应用程序，总共每小时是8个操作量。

注意：上述数字是在仿真环境下测试得来：基于SSL的XenApp6.5，发布了100+个应用程序，每个用户在5秒钟之内完成操作的。

StoreFront对CPU的数量更敏感，也就是说对CPU的消耗更大，而不是对内存消耗更大。推荐的企业StoreFront服务器是4个vCPU和4GB RAM。

- 但服务器扩展性 – 应用程序订阅数据库

应用程序订阅数据库包含了每个用户订阅的一系列资源列表情况。基于测试环境下，推荐的一个储存应用程序订阅数据库独立SQL服务器的配置是4vCPU和4GB

RAM。

数据库的增长速度大约是每个订阅10KB空间消耗：

数据库大小 = （用户数 × 每用户的订阅数） × 10KB

1个订阅 = 1个用户订阅一个应用程序，例如，1000个用户订阅10个应用程序就是100MB。

3.5.3桌面控制器

这部分内容主要是介绍XenClient部分，请大家自行参见原始文档。

3.5.4Provisioning Services（PVS的设计）

Citrix Provisioning Services（PVS）使用流化的技术简化了虚拟桌面和物理桌面的部署。计算机从一个单个的共享磁盘镜像上被实时制备（Provisioned），管理员完全不需要去管理或者是给每个单独的用户操作系统打补丁。

- 决断：Farm（场）的数量

一个Provisioning Services的场代表着Provisioning Services基础架构的最高层级。所有在一个场的Provisioning Servers（服务器）都共享同一个SQL 数据库哦Citrix License服务器。当确定需要多少个Provisioning Services的场时，我们一般需要考虑以下几个因素：

网络：Provisioning Servers会始终和场数据库通信以获取系统配置信息。因此，一般来说每个target devices聚集的地理位置应该部署一个独立的场，当然，如果异地之间的网速足够快，理论上也可以只建立一个Provisioning Services场。



重要程度：管理者应该决定它可以容仍什么样的风险。尽管可能性非常的低，但是Provisioning Services场如果出问题还是会影响整个组织架构的使用。如果一个公司需要非常高等级的可用性，那么多个场的搭建就可以避免这个问题。



可管理性：管理者可能需要在基于组织架构划分的基础上，例如国家、地区，又或者是不同部门之间，来进行单独的系统管理。尽管听起来这会增加管理的复杂程度，但是实际上只会增加有限多的配置、桌面创建过程，以及操作系统镜像更新。



- 决断：站点（Sites）的数量

每个Provisioning Services的场都包含一个或者多个的站点。一个Provisioning Services的站点是一个逻辑的实体组成部分，包含了Provisioning Servers（服务器）、vDisk pools，以及target devices的集合。多个站点共享同一个数据库。Target devices可以在同一个站点中容错到其他的Provisioning Servers上。在以下的情况下我们建议创建多个站点：

网络：站点用来控制Provisioning Services的流数据量。例如，一个站点可以根据站点、rack、或者是刀箱来创建，以确保流数据始终保持在本地而不变成一个网络瓶颈。



组织架构：另外一个需要创建多个站点的实际理由是企业组织架构的改变。例如，两个公司通过收购合并了，但是有需要在企业整合过程中保持资源的独立。



- 决断：数据库的配置

Provisioning Services的数据库存储有所有一个场内的的系统配置信息。Provisioning Services 6.X版本支持一下版本的SQL数据库，包括Express、标准版、企业版的SQL Server 2005、2008R2以及2012版。选择哪一个SQL版本其实是取决于你需要哪一个级别的容错水平。以下的表格是一个SQL 2008R2版本的示例：

Provisioning Services场的数据库的大小很少会超过250M容量，即使在大型环境下也不会。所以，在测试环境下Express版本是最佳选择，因为不需要容错功能。

下面的公式是用来计算Provisioning Services的数据库的容量大小：

- 决断：数据库；离线模式

如果到Provisioning Services场的数据库的连接断开，已经连接到Provisioning Servers的target devices仍然可以正常工作，但是新的target

devices将会无法启动。

支持离线数据库功能可以让Provisioning Services在失去连接到数据库后仍然可以保持正常操作。在服务器启动时会对数据库做个快照，然后定期保持同步。如果连接丢失，Stream Services会使用最新的一个快照以获取场的配置信息。一旦数据库连接建立起来了，Stream过程会把断线期间的变化同步到数据库中。

需要注意的是，离线数据库功能默认下是关闭状态的，而且也仅仅是在生产环境下的稳定的场环境下推荐使用。评估环境下不推荐使用

- 决断：服务帐号

Stream和SOAP服务会和其他许多不同的Provisioning Services基础架构中的组件进行通信，如下图所示：

- 决断：设备集合

设备集合是用来创建和管理target devices逻辑组。创建设备集合可以简化设备管理，因为将来的操作可以不用基于target device级别，而是基于集合这个级别。

设备集合可以基于物理地理位置、子网范围、组织架构中不同的部门来设计。也可以考虑基于vDisk的分配来创建不同的设备集合，这样所有分配到一个特定vDisk的所有的target devices就能被快速的定位。

- 决断：Provisioning Server（服务器）的内存

运行Provisioning Services的Windows操作系统会把vDisk的部分内容缓存在内存（系统缓存）中以降低从存储中读取的操作。从存储中读取数据的速度是显著低于从内存中读取数据的，所以，正确计算Provisioning Servers的内存是非常关键的。请参见以下的公式：

简单地说，就是给每个vDisk分配2G左右的内存。

- 决断：Scale Up还是Scale Out

题外话：首先对这两个词进行一下解释：

Scale Out(向外扩展)：就是指企业可以根据需求增加不同的服务器应用，依靠多部服务器协同运算，借负载平衡及容错等功能来提高运算能力及可靠度。

Scale Up(向上扩展)：指企业后端大型服务器以增加处理器等运算资源进行升级以获得对应用性能的要求。

随着Farm场的增长，管理员需要作出决定以判断是不是需要给Provisioning

Server增加更高的资源，也可以是在场中增加更加多的Provisioning Servers，一下了可以是考虑因素：

冗余：将用户符合扩展到其他负荷不重的服务器上会有助于降低当Provisioning Servers宕机情况下爱所影响的用户数量。如果公司无法接受单点高性能服务器宕机所造成的损失，那就考虑Scaling Out，就是我们说的向外扩展（既增加多台服务器）。



容错时间：在一个单台的Provisioning Server上所连接的Target

Devices越多，在服务器宕机后所需要的恢复时间也就越多。Citrix的内部测试显示在Provisioning Services 5.6 SP2版本下，1500台Target

Devices需要大约8分钟恢复生产能力；



数据中心容量：数据中心一般都是只有有限的空间、电源、冷却能力，此时，可以考虑Scaling Up，即向上扩展（增加单台服务器的处理能力）。



硬件成本：刚开始时，可能Scale Up会有更高的性价比，但是继续往后可能Scale Out会开始更具性价比，应该做一个成本分析；



- 决断：vDisk的存储位置

一个场可以包含一个或者多个的vDisk存储。一般来说有两个主要的选择：



本地存储或者是DAS：DAS可以是本地的，或者是基于Block的存储类型，Provisioning Server可以直接访问，例如SATA、SCSI、iSCSI，以及光纤。本地的vDisk就只能被本地的Provisioning Server所反问，因此，vDisk应当被手动或者自动的复制到其他的vDisk存储位置上。

注意：将vDisk部署在本地存储上并不会造成单点故障，因为Provisioning

Service的负载均衡技术可以让target devices自动的在其他Provisioning

Servers之间做容错动作。

2024年2月9日发(作者：门紫萍)

Citrix 虚拟桌面快速部署手册——规划设计篇

修正历史

修正改变说明

V0.1 原始文件

更新者日期

Eric Yao 2013年3月17日星期日

V0.1 uploaded to wiki Martin Liu 2013-7-10

产品版本

产品

SQL Server

XenDesktop

XenApp

XenServer

版本

2008 R2

2008 R2 Express

5.x

6.x

Windows Server 2008 R2

第1章关于方法论

Citrix虚拟桌面快速部署手册会紧密遵循Citrix顾问实施方法论，将整个实施的过程划分成四个阶段，即如下图所示：

[1] Access 评估

Access阶段主要提供Design阶段所需要的信息，包括：

1. 业务驱动力；

2. 数据搜集：包括用户、应用程序、设备以及基础架构；

3. 用户的分类：用户要根据需要的分类而分成不同的组别，随之应对着不同的FlexCast方法论；

4. 应用程序分类：旧的应用程序应该被删除、应用程序版本应该标准化、非公司程序应该删除，等等这些构成了应用程序的标准化和合理化；

5. 计划：每个用户组都要根据对业务的影响程度指定不同的实施时间优先级，优先级实施进度结果应该随时更新项目进度和计划。

[2] Design 设计

设计阶段主要聚焦在五层的一个方法论上：

1. 用户层：描述推荐的终端以及所需要的用户功能体验；

3. 桌面层：主要指用户的虚拟桌面实现技术，即FlexCast技术，主要好汉三个主要成分，分别是镜像文件、应用程序，以及个性化内容；

4. 控制层：如何管理和维护其他层，又分为访问控制、桌面控制，以及基础架构控制；

5. 硬件层：致力于支撑整个解决方案的硬件物理设备，包括了服务器、CPU、内存、存储设备等；

[3] Deploy 部署

按照第二部分设计好的FlexCast方式实施。

[4] Maintain 维护

主要包含三种不同的活动：

1. 监控：在虚拟桌面环境设计和实施到生产环境以后，持续的监控是必需的。

2. 技术支持；

3. 测试和变更管理：以后会遇到不断的软件和产品更新；

4. 项目计划

第2章访问及评估

2.1 业务驱动力

下图就定义了一个业务驱动力的优先级示例：

2.2 数据搜集

数据搜集阶段负责搜集关键信息数据，包括用户、设备、应用程序，以及基础架构等在下一阶段需要使用的数据。

有三种方法来搜集数据：

1. 手动搜集

小型企业有可能通过访问每台终端，或者是远程连接凡是来搜集数据。

1. 调查表

1. 自动化搜集

上述三种方法的优势和劣势如下表所示：

2.3 用户数据搜集

信息搜集表可以参考示例表格：Citrix Virtual Desktop Handbook - Assess

1. 业务特性

业务特性必须通过业务层的管理人员来手动搜集，无法自动化搜集。包括

1. 身份

1. 用户名

2. 部门；

3. 角色

4. 业务经理

5. 所分配的用户组；

2. 业务

1. 主要的数据中心

2. 移动性，下表是示例分类

- 个性化

- 安全性

- 关键性

- 技术特性

1. 工作负荷

- 用户环境

1. 用户Profile

1. Profile类型：包括本地、漫游、强制、第三方、未知

2. Profile版本：Windows XP和Windows Vista/7

3. Profile位置：文件服务器在哪里

4. 大小：用户Profile的大小

2. 用户数据主目录

1. 主目录位置

2. 大小

3. 客户端硬件，包括以下需要搜集的信息：

o Number of CPUs/Cores

o CPU Speed (GHz)

o Memory (GB)

o Disk Size (GB)

o Operating System

o Age of the System (years)

o Peripherals

1. 本地资源映射，包括以下需要搜集的信息：

o Local Drives

o Printing

o Clipboard

o Audio

o COM Port

o USB

o LPT

2.4 应用程序数据搜集

信息搜集表可以参考示例表格：Citrix Virtual Desktop Handbook - Assess

1. 身份信息

1. 应用程序名称和版本

2. 应用程序所有者

3. 状态

2. 应用程序技术特性

1. 分配

1. 使用者数量

2. 部门信息

3. 个别用户

2. 工作负荷

- 业务特性

1. 兼容性

2.5 用户分类

最快区分用户的方法就是按照用户的需求不同来分组，一旦将用户的需求区分之后，就可以将这些数据填入Citrix Virtual Desktop Handbook - Assess

了。

2.5.1FlexCast模型比较

1. Hosted Shared

2. Hosted VDI，又可以细分为

1. Pooled-Random/Streaming

2. Pooled-Static

3. Pooled/Streamed with Personal vDisk

4. Dedicated

5. Existing

6. Psysical/Remote PC

3. Steamed VHD

4. Local VM

5. On-Demand Apps

下表是关于FlexCast整体技术的一个概览：

2.5.2FlexCast模型选择

在XenApp和XenDesktop之间有很多技术上的区别，但是他们都是通过HDX来提供的最佳用户体验。他们的区别如下：

2.6 应用程序评估

在用户分组完成之后，我们已经有了根据需求不同确定下来的不同的用户组，下一步就是向用户提供他们工作需要的应用程序。下面是建议的三部曲：

1. Rationalization 合理化

2. Business Characteristics 业务特性

3. 兼容性

2.7 项目管理

2.7.1Roadmap

2.7.2项目团队

1. 业务角色

- 技术角色

第3章设计原则

3.1 概况

3.2 用户层 User Layer

3.2.1终端类型的选择

终端一般有多种类型，每种都有不同的能力：

 Tablet based on Android or iOS 基于安卓或者iOS的平板电脑

 Laptop 笔记本电脑

 Desktop PC 桌面PC

 Thin Client 瘦客户机

 Smartphone 智能手机

1. 决断：终端所有者

安全性：高风险区的用户不能携带个人设备进入该区域以防止数据外携；

可移动性：例如用户个人设备将不适合用于离线的Local VM（即XenClient模型）；

关键性：被评价为高关键业务的用户需要额外的冗余设置

FlexCast模式：例如个人所属设备就不适用于例如Steaming VHD、Local VM模式以及Remote PC模式。

下面的图显示什么时候使用用户自己有用的设备，什么时候选择工资拥有设备：

- 决断：终端生命周期

工作负荷：工作种类应该和FlexCast模型相互配合

下面的表格列出了当我们准备重新利用现有的硬件，亦或者是新购设备时的推荐计划：

- 决断：终端规格

瘦客户机的处理能力已经极大的增长，即使是中等的手机现在也能够实现图形处理能力了，包括HDX特性等都不在话下，例如多显示器支持等等。

很多企业都会将瘦客户机和PC混合部署，我们需要记住的是用户组的特性才是最终决定需要采用哪种模式的最重要因素：

- 决断：瘦机选择

瘦机厂商现在有越来越多的OS选择了，常见的有Windows Thin PC（基于Windows

7），嵌入式的WinXP、Win7和Win8、Linux变种，甚至零客户机。我们在选择时，需要考虑以下因素：

内行专家：许多公司都已经有了可以管理瘦机基础架构的管理工具集。建议充分利用这些管理工具的管理专家们。

3.2.2Receiver的选择

1. 决断：Receiver的类型

这里本来有个表格的，可是太大了，建议大家直接看pdf文件的Page 44.

除此之外，其他我能够看到的差别还有：



对XenApp的支持中，Win8/RT、黑莓、HTML5上的Receiver就只能部分支持；

而XenDesktop功能基本上所有版本都支持；

基于Email地址来配置Receiver：除了黑莓和HTML5的Receiver客户端，其余都支持；

智能卡支持：所有平台均支持；

快速访问/非接触式智能卡：目前只有Citrix Receiver Enterprise版本支持；

UDP语音：只在Citrix Receiver和Citrix Receiver Enterprise版本、Receiver MAC、Receiver Linux版本上支持；



Pre-Launch功能：只支持Citrix Receiver和Citrix Receiver

Enterprise版本；

AERO特效：Windows的玩意当然只有Citrix Receiver、Citrix Receiver

Enterprise版本以及Windows 8/RT的Receiver才支持；

磁盘重定向：除Win8/RT之外所有的平板、智能手机以及HTML都不支持，

剪贴板支持：只有 Citrix Receiver、Citrix Receiver Enterprise版本和Receiver MAC才支持，Linux版本的也不支持哦！

HDX 3DPro支持：只有Citrix Receiver和Citrix Receiver Enterprise版本完全支持，Linux、MAC、Win8/RT都是部分支持；

ShareFile：黑莓、HTML5、Win8/RT不支持，其余都支持；

离线应用程序：只有Citrix Receiver和Citrix Receiver Enterprise版本支持；

单点登录：只有Citrix Receiver和Citrix Receiver Enterprise版本支持；这个要注意一下；

StoreFront支持：黑莓、Linux和HTML5不支持；

Desktop Lock：只有Citrix Receiver Enterprise版本支持，Citrix

Receiver都不支持哦！

- 决断：Receiver部署

在部署和升级Receiver时，以下机制可以考虑和利用：



StoreFront：如果Citrix StoreFront已经安装，管理员就可以通过一个Web站点来部署Receiver，用户只需要打开网页就能自动安装；

内部下载站点：有时候用户会被禁止访问互联网，那么管理员就可以创建一个内部站点来安装Receiver。典型的模板可以参考Citrix Receiver

Download Page Template主页，它包含了所有版本Receiver的下载软件和自动安装方式。

Windows Store：在Windows 8 Store里面可以下载到Windows8/RT的Receiver软件。目前Receiver只支持ARM或者是基于Intel芯片的Windows8/RT设备。

移动设备：移动设备一般都有自己特殊的方式来安装软件，例如

应用程序商店：包括安卓的Google Play，或者是Apple的Apple

Store；

其他移动部署方法：有的移动平台可以提供企业级方法来部署，例如黑莓就可以通过BlackBerry Enterprise Server来部署BlackBerry平台上的Receiver；



Merchandising Server：这也是一种方法。除此之外，Merchandising

Server还能够用来升级Receiver以及安装Receiver的插件，它可以定期连接到Citrix Update Service去检查有没有最新的软件。

软件分发工具：例如LANDesk、MS的SMS，以及Symantec Altiris；

组策略：可以自己写一个启动脚本来部署Receiver，甚至卸载Receiver，在XenApp和XenDesktop安装光盘里面也自带了这个脚本；

手动安装：所有版本的Receiver都可以在Citrix Receiver Download

下面的表格总结了每种方法适用于的Receiver版本，因为表格太大，请大家自行参考第48页。

- 决断：Receiver配置



注意：DNS平台需要支持基于电子邮件的发现，目前只有Windows

DNS测试过；

如果是远程用户，就必须配合Access Gateway，同时在DNS中有对应的SRV记录；此外，在Access Gateway硬件或者是StoreFront服务器上必须有有效的服务器证书。

组策略：启动脚本也可以用来配置Receiver。脚本中有一行这样的参数：SERVER_LOCATION=Server_URL. 缺省的值是空,将Web Interface或者是StroeFront的地址输入进去

手动：不多说，呵呵。

- 决断：Receiver升级

Merchandising Server：对于支持Citrix Receiver Updater Plug-In平台的Receiver来说（Citrix Receiver, Citrix Receiver Enterprise,



软件分发平台：例如LAN Desk和Symantec Altiris等平台；



手动升级：最后一个，也是最有效的办法。



3.2.3资源需求

无需多言硬件参数，包括服务器的CPU、内存、硬盘以及后台的网络设备、存储有多重要了，其实更重要的是在性能和成本之间达到一个最佳的平衡。

我们首先将用户组按照性能需求分为四种性能组：

至于Scalability Assumptions，按照以下内容来估算：



CPU的速度：按照2.7GHz和Intel Westmere处理器架构来设计；

超线程：超线程可能可以达到20%-30%的性能增长，但是有时候也会带来负面效应。我们设计时都是不算超线程的；

工作负荷：假设已经加载了防病毒软件和标准的监控工具；

Hypervisor开销：已经从每用户core中减去；

内存：大部分用户在一天中所使用的内存都在不同程度的增长，原因有很多；因此，内存应该算最大值。

- 决断：CPU

此处注意的是，如果你采用了PvD技术，经我们测试显示，大概有14%的性能下降，记住要把这个因素考虑进去。

另外，PvD在5.6.10版本及之后的版本都不再支持WinXP，所以目前没有XP下的数据。

下面的表格可以用来计算每个用户组所需要的CPU资源：

物理CPU核数 = 用户组的最大CCU数量 / 每个物理core所支撑的用户数

- 决断：内存

下面的表格列举了在不同负荷和FlexCast模式下所需要的内存数量：

- 决断：IOPS

见下表：

需要注意的是上面的数字都是稳定状态下的，不是峰值状态。

裸IOPS = 写IOPS×写惩罚 + 读IOPS

写惩罚的规定：

- 决断：存储空间

在PVS环境下，所有对虚拟桌面的写操作都是发生在写缓存中，但是在MCS模式下，写操作确实发生在Diff Disk中。写的内容包括：

User Profile



系统临时文件和应用程序临时文件



Windows、Citrix和应用程序的日志文件



PVS模式的写缓存和MCS的差异磁盘所需要的磁盘空间取决于应用程序的使用量和用户的动作。不过，下面的表格有一个大概的评估值：

几点注意事项：

1. PVS写缓存启动时最小，但是使用过程中会不断增长。重启VM后被清除；

2. 在某些情况下需要将数据重定向到写缓存的磁盘中这样在重启时也能保留，例如EdgeSight数据、Windows日志和防病毒软件的定义库文件；

3. 包含了10G的PvD数据磁盘大小；

4. MCS模式下推荐使用NFS的存储以利用Thin Provisioning能力；

3.3 访问层 Access Layer

访问层的设计主要是基于每个用户组和终端设备的移动性需求。

1. 决断：认证点

让用户在什么地点做认证是管理员的决定，一般而言，有四个认证点：

1. Web Interface：给XA和XD提供安全访问；

2. StoreFront：为Receiver交付认证能力和资源；

3. Secure Gateway (Web Interface): Secure Gateway是一个Windows的应用程序，她和WI配合工作；

4. Access Gateway: 硬件

具体采用哪种方式认证由用户组的移动需求来决定，推荐方案如下：

- 决断：预认证策略

如果我们使用的是Access Gateway，我们就可以选择是否采用预认证策略，这些策略可以是确定终端是否满足某种接入网络前的扫描条件。

下面的图标从流程上示例策略配置是如何流转的：

- 决断：认证策略



Web Interface, Secure Gateway (Web Interface), or StoreFront:

StoreFront是未来的方向，而Web Interface已经是行将就木，所以下面的策略主要是用在StoreFront上，当然也适用于Web Interface

用户名/密码

Domain Pass-Through：允许从用户设备上透传Domain登录信息，用户登录到加入域的电脑后自动登录到Store；

Access Gateway Pass-Through：用户登录到Access Gateway后自动登录到Store



LDAP：轻型目录访问协议是我们最为熟悉的认证方法了，它是一种基于TCP协议的目录访问服务，例如MS的活动目录就是其中一种实现形式。

Radius（aka Token）：Radius全名是Remote Authentication Dial

采用什么认证形式通常都是取决于安全的需求，以及使用什么认证点。下表给出了一个基于安全需求级别的示例：

- 决断：会话策略

移动设备：表达式定义为：“ User-Agent CONTAINS

CitrixReceiver”，该语句将移动设备设置为比非移动设备更高优先级以保证移动设备的匹配性。



非移动设备：表达式定义为：“ns_true”，即所有流量。



更多信息，可以参考Citrix公开电子文档：Receiver and Plug-ins

BTW，另外一种会话策略是采用终端的扫描方法。

- 决断：会话Profile（Session Profile）



SSL VPN：传统的VPN方式，将网络全部打通。这种方式并不一定十分安全，因为这能导致客户端到内网服务器的攻击访问。

上述两种方式各有利弊，第一种方式虽然安全性差了，但是可以做客户端流量可以被企业的网络过滤设备，例如入侵检测设备做监视和控制。

- 决断：访问带宽

最后的访问层决断就是要决定虚拟桌面所需要的最大并发网络带宽。其中很重要的一个关键环节就是决定采用NetScaler Access Gateway的哪一个平台。

理想情况下带宽的使用情况是通过带宽分析工具来给出来，不过我们还是可以给出一些经验值：

总带宽的的计算公式可以这样来定义：

总带宽

平均带宽

最大并发用户值

更多细节，可以参考Citrix的知识库文章：

XenDesktop Planning Guide: User Bandwidth Requirements

3.4 桌面层 Desktop Layer

3.4.1应用程序交付

选择正确的应用程序交付方法会对整个系统设计的可扩展性、可管理性，以及用户感受起到非常大的帮助。基于我们在前几章节的“Error: Reference source

not found”，我们可以考虑以下几种交付方法：

直接安装在操作系统镜像文件上：应用程序是基础操作系统镜像文件的一部分；



安装在Personal vDisk上：物理是分离的，但是逻辑上是直接安装在基础操作系统镜像文件中；



Hosted：应用程序安装在XenApp服务器上，用户通过Citrix HDX协议远程访问。



- 决断：应用程序交付方法

下面的表格就是不同的交付方法对系统不同层面的影响：

- 兼容性

效率。所以在设计阶段我们就要做很多兼容性测试以确定最正确的应用程序交付方法。最重要需要考虑的兼容性需求一般来说包括以下几点：



桌面操作系统的版本：如果操作系统是通过流化安装或者是直接安装在操作系统中，那么应用程序需要考虑和操作系统的兼容性问题；

互操作性：有一些应用程序如果和某些版本的操作系统共存是会有兼容性问题，例如注册表冲突、DLL冲突，或者是ini冲突。

在做应用程序兼容性测试时的三种主要技术手段有：



预验证的应用程序：很多应用程序的开发商都会提供该应用程序的兼容性文档和最佳安装方式的文档。参考这些文档会有直接的帮助。此外，Citrix

Application Compatibility List for IT Professionals；



上述每种方法的优点和缺点都列在下表中：

测试做完之后，兼容性的结果就应该填入到之前的应用程序评估表各种以便我们的后续分析：



预运行环境：许多程序都有运行环境的要求，例如Java、.Net环境，或者是数据库要求；

程序之间的依赖：例如，需要以pdf格式呈现信息的应用程序就需要电脑上安装了pdf的阅读器；

16位的代码：应用程序评估也应该判断是否应用程序包含有16位的代码，因为16位的代码是不能运行在64位的操作系统平台上；

Windows XP：确认应用程序是否能通过Windows XP的兼容性测试；

Windows 7：确认应用程序是否能通过Windows 7的兼容性测试；

XenApp 6.5：确认应用程序是否能通过XenApp 6.5的兼容性测试；

Application Streaming 应用程序流化安装：确认应用程序是否能通过流化程序安装的兼容性测试；

- 用户分类

- 业务特点



- 技术特点

资源使用：如果应用程序对资源要求很高，可能会更合适于直接在虚拟桌面里面直接运行；



3.5 控制层 Control Layer

控制层是设计架构的第四层。在上面有关用户的三个层面我们所做的决定都会汇总起来到控制层。

3.5.1远程访问架构

如果有用户需要远程或者是离线的移动访问能力，那么就要设计远程访问基础架构了。

1. 决断：拓扑



* Double-Hop DMZ (Very High Security): 这种模式既利用了双臂拓扑下的特

第二个DMZ区域的Access Gateway设备充当与一个代理设备角色。这个Access

Gateway设备启用ICA协议将客户端连接穿越第二个DMZ区到后端的服务器场。在第一个DMZ区的Access Gateway设备和内部网络的Secure Ticket

Authority（STA）也是通过第二个DMZ区的Access Gateway设备来进行代理的。

- 决断：平台

SSL吞吐量：SSL吞吐量是定义为每秒钟能处理的GB SSL流量；



SSL每秒交易量（TPS）：TPS metric定义在每秒每个应用程序交付控制器（ADC）能处理的SSL交易数量



关于这两个参数的更详细解释，可以参考：Best Practices for implementing

2048-bit SSL

SSL吞吐量 = 最大并发带宽 × 1.02

例如：鸡舍128M是最大的并发带宽，那么最合适的NetScaler模型应当计算为：

约130Mbps = 128M × 1.02

NetScaler有三种平台，每种都提供了大量的不同的扩展性：

VPX：VPX平台的NetScaler和硬件的NetScaler提供完全一致的功能，不过他只适合于小型的测试环境使用。



MDX：NetScaler MDX是NetScaler设备的硬件版本。他能支持大型网络可扩展环境；



SDX：NetScaler SDX设备是在物理NetScaler设备和虚拟NetScaler设备之间的一个桥梁。一个SDX设备能够划分为多个虚拟的NetScaler设备。



3.5.2StoreFront

- 决断：Web Interface还是StoreFront

桌面产品的生命周期：Lifecycle Milestones for Citrix XenDesktop

下面的表格也示例了在何种情况下该使用什么产品：

下面的表格对两种产品在未来功能的开发目标上进行了一个对比，Web

Interface已经不再会有革命性的功能添加了：

下面的表格是功能对比：

有一些Web Interface有的功能也会被完全整合到未来的StoreFront新版本中去：

- 决断：Web 服务的高可用

DNS Round Robin：在多个服务器之间提供基本的负载均衡功能，无法做到是否可用性的检查；在服务器宕机时，部分用户会受到影响。



Windows NLB：是Windows的一个服务。可以做一些基本的检查来判断服务器是否可用，但是无法判断单个服务的状态。



Citrix NetScaler：智能硬件设备，能检查StoreFront服务的状态，根据用户请求主动激活负载均衡状态。



- 决断：应用程序订阅数据库的高可用

如果应用程序订阅数据库不可用，以下功能将不可用：

用户不能在管理他们的应用程序订阅；



无法登陆至Web 方式的Reciever，但是已经建立起来的会话可以继续正常工作；



为了防止应用程序订阅数据库成为单点故障点，Citrix推荐SQL的高可用方案：

License即可。更多细节可以参考文档：Configuring StoreFront using

the Configuration Files.



Server的操作系统宕机时才能启动容错机制。如果数据库服务出现错误是无法被Hypervisor层检测到的。



注意：未来的StoreFront版本将不会再使用应用程序订阅数据库（Application

Subscription Database），相反，预订信息会自动的在StoreFront服务器组中的StoreFront服务器中自动复制。

- 决断：容量规划

注意：上述数字是在仿真环境下测试得来：基于SSL的XenApp6.5，发布了100+个应用程序，每个用户在5秒钟之内完成操作的。

StoreFront对CPU的数量更敏感，也就是说对CPU的消耗更大，而不是对内存消耗更大。推荐的企业StoreFront服务器是4个vCPU和4GB RAM。

- 但服务器扩展性 – 应用程序订阅数据库

RAM。

数据库的增长速度大约是每个订阅10KB空间消耗：

数据库大小 = （用户数 × 每用户的订阅数） × 10KB

1个订阅 = 1个用户订阅一个应用程序，例如，1000个用户订阅10个应用程序就是100MB。

3.5.3桌面控制器

这部分内容主要是介绍XenClient部分，请大家自行参见原始文档。

3.5.4Provisioning Services（PVS的设计）

- 决断：Farm（场）的数量



- 决断：站点（Sites）的数量



- 决断：数据库的配置

Provisioning Services场的数据库的大小很少会超过250M容量，即使在大型环境下也不会。所以，在测试环境下Express版本是最佳选择，因为不需要容错功能。

下面的公式是用来计算Provisioning Services的数据库的容量大小：

- 决断：数据库；离线模式

如果到Provisioning Services场的数据库的连接断开，已经连接到Provisioning Servers的target devices仍然可以正常工作，但是新的target

devices将会无法启动。

需要注意的是，离线数据库功能默认下是关闭状态的，而且也仅仅是在生产环境下的稳定的场环境下推荐使用。评估环境下不推荐使用

- 决断：服务帐号

Stream和SOAP服务会和其他许多不同的Provisioning Services基础架构中的组件进行通信，如下图所示：

- 决断：设备集合

- 决断：Provisioning Server（服务器）的内存

简单地说，就是给每个vDisk分配2G左右的内存。

- 决断：Scale Up还是Scale Out

题外话：首先对这两个词进行一下解释：

Scale Out(向外扩展)：就是指企业可以根据需求增加不同的服务器应用，依靠多部服务器协同运算，借负载平衡及容错等功能来提高运算能力及可靠度。

Scale Up(向上扩展)：指企业后端大型服务器以增加处理器等运算资源进行升级以获得对应用性能的要求。

随着Farm场的增长，管理员需要作出决定以判断是不是需要给Provisioning

Server增加更高的资源，也可以是在场中增加更加多的Provisioning Servers，一下了可以是考虑因素：



容错时间：在一个单台的Provisioning Server上所连接的Target

Devices越多，在服务器宕机后所需要的恢复时间也就越多。Citrix的内部测试显示在Provisioning Services 5.6 SP2版本下，1500台Target

Devices需要大约8分钟恢复生产能力；



数据中心容量：数据中心一般都是只有有限的空间、电源、冷却能力，此时，可以考虑Scaling Up，即向上扩展（增加单台服务器的处理能力）。



硬件成本：刚开始时，可能Scale Up会有更高的性价比，但是继续往后可能Scale Out会开始更具性价比，应该做一个成本分析；



- 决断：vDisk的存储位置

一个场可以包含一个或者多个的vDisk存储。一般来说有两个主要的选择：



注意：将vDisk部署在本地存储上并不会造成单点故障，因为Provisioning

Service的负载均衡技术可以让target devices自动的在其他Provisioning

Servers之间做容错动作。

USB迷 | 专注于互联网分享

Citrix 虚拟桌面快速部署手册——规划设计篇

与本文相关的文章

评论列表 (0)