Citrix桌面虚拟化实施部署白皮书.doc

Citrix桌面虚拟化技术白皮书Citrix桌面虚拟化技术白皮书思杰系统信息技术有限公司Citrix Systems Information Technology Co., Ltd.2013年05月目录序言：关于方法论3一、Access3二、Design3三、Deploy4四、Maintain4五、项目计划4第一部分：Access5一、业务驱动力5二、数据搜集5三、用户数据搜集6四、应用程序数据搜集8五、用户分类91.FlexCast模型比较92.FlexCast模型选择10六、应用程序评估12七、项目管理131.Roadmap132.项目团队13第二部分：Design21一、概况21二、用户层 User Layer211.终端类型的选择212.Receiver的选择243.资源需求27三、访问层 Access Layer30四、桌面层 Desktop Layer351.应用程序交付35五、控制层 Control Layer391.远程访问架构392.StoreFront423.桌面控制器474.Provisioning Services（PVS的设计）4761序言：关于方法论Citrix Virtual Desktop handbook会紧密遵循Citrix顾问实施方法论，即如下图所示：一、 AccessAccess阶段主要提供Design阶段所需要的信息，包括：1. 业务驱动力；2. 数据搜集：包括用户、应用程序、设备以及基础架构；3. 用户的分类：用户要根据需要的分类而分成不同的组别，随之应对着不同的FlexCast方法论；4. 应用程序分类：旧的应用程序应该被删除、应用程序版本应该标准化、非公司程序应该删除，等等这些构成了应用程序的标准化和合理化；5. 计划：每个用户组都要根据对业务的影响程度指定不同的实施时间优先级，优先级实施进度结果应该随时更新项目进度和计划。二、 Design设计阶段主要聚焦在五层的一个方法论上：1. 用户层：描述推荐的终端以及所需要的用户功能体验；2. 访问层：描述用户层是如何连接到他们的桌面，例如本地桌面是直接连接StoreFront，而外界用户往往要通过Firewall层才能进来，这就涉及到了FW、VPN等技术；3. 桌面层：主要指用户的虚拟桌面实现技术，即FlexCast技术，主要好汉三个主要成分，分别是镜像文件、应用程序，以及个性化内容；4. 控制层：如何管理和维护其他层，又分为访问控制、桌面控制，以及基础架构控制；5. 硬件层：致力于支撑整个解决方案的硬件物理设备，包括了服务器、CPU、内存、存储设备等；三、 Deploy按照第二部分设计好的FlexCast方式实施。四、 Maintain主要包含三种不同的活动：1. 监控：在虚拟桌面环境设计和实施到生产环境以后，持续的监控是必需的。2. 技术支持；3. 测试和变更管理：以后会遇到不断的软件和产品更新；五、 项目计划一个设计详尽的项目计划对项目成功的实施时至关重要的。项目经理要通过项目计划来监控成本、管理项目组成员、跟进项目实施进度等。同时项目进度要及时通告项目组所有成员让大家都知道项目的进度。在项目的初期一般只需要做Access阶段的计划，这个时段需要多FlexCast模式、容量、用户分组等有更多的交接，所以无需做Design的计划。如下图所示就是一个计划表：第一部分：Access一、 业务驱动力桌面虚拟化项目的第一步应该是去了解对公司所造成的影响，并且将这些影响一一定下来，然后对之以优先级排序。有了这些文字描述管理层和项目管理组才能制定出项目成功实施的标准，设计阶段才能有正确的方法论和架构设计。下图就定义了一个业务驱动力的优先级示例：二、 数据搜集数据搜集阶段负责搜集关键信息数据，包括用户、设备、应用程序，以及基础架构等在下一阶段需要使用的数据。有三种方法来搜集数据：1. 手动搜集小型企业有可能通过访问每台终端，或者是远程连接凡是来搜集数据。中大型企业一般般都有了ESD（Enterprise Software Deployment），例如微软的SCCM等。可以通过这些平台去搜集应用程序的使用情况等信息。但是ESD一般都不能提供应用程序性能需求和实际使用的信息。2. 调查表这也是一个好办法，可以通过管理层去通过行政命令来执行。也可以通过面对面的会议或者是电话沟通来进行；这种方式比手动搜集要显著减少了所花费的时间，但是完成率不高也是一个缺点，不够精确反应实际情况也是一个缺点。3. 自动化搜集这样的工具有很多，一般都能自动化生成报表。Citrix公司为了帮助用户节省实施成本，和LanDesk公司合作，为Project Accelerator用户提供了一个60天免费试用的LanDesk FastTack 软件License。LanDesk FastTack 软件是一个专门为Citrix实施方法论开发设计的一个专业信息搜集工具。上述三种方法的优势和劣势如下表所示：三、 用户数据搜集信息搜集表可以参考示例表格：Citrix Virtual Desktop Handbook - Assess Workbook.xlsx1. 业务特性业务特性必须通过业务层的管理人员来手动搜集，无法自动化搜集。包括A. 身份a) 用户名b) 部门；c) 角色d) 业务经理e) 所分配的用户组；B. 业务a) 主要的数据中心b) 移动性，下表是示例分类c) 个性化d) 安全性e) 关键性2. 技术特性a) 工作负荷3. 用户环境a) 用户Profilei. Profile类型：包括本地、漫游、强制、第三方、未知ii. Profile版本：Windows XP和Windows Vista/7iii. Profile位置：文件服务器在哪里iv. 大小：用户Profile的大小b) 用户数据主目录i. 主目录位置ii. 大小4. 客户端硬件，包括以下需要搜集的信息：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 Peripherals5. 本地资源映射，包括以下需要搜集的信息：o Local Drives o Printing o Clipboard o Audio o COM Port o USB o LPT四、 应用程序数据搜集信息搜集表可以参考示例表格：Citrix Virtual Desktop Handbook - Assess Workbook.xlsx1. 身份信息a) 应用程序名称和版本b) 应用程序所有者c) 状态2. 应用程序技术特性a) 分配i. 使用者数量ii. 部门信息iii. 个别用户b) 工作负荷c) 业务特性d) 兼容性五、 用户分类一旦数据搜集工作完成之后，我们就可以开始准备将用户分成不同的组了，这个时候就要按照FlexCast模型的要求去分配不同的实现方式给不同的用户组了。我们一般都是按照人物性工作者、分支机构办公人员、移动工作者等方式去区分用户，但是实际上用户的分类远不止这几类，更有甚者，很多用户组都是同时属于上述几个组的。最快区分用户的方法就是按照用户的需求不同来分组，一旦将用户的需求区分之后，就可以将这些数据填入Citrix Virtual Desktop Handbook - Assess Workbook.xlsx 了。1. FlexCast模型比较1) Hosted Shared2) Hosted VDI，又可以细分为a) Pooled-Random/Streamingb) Pooled-Staticc) Pooled/Streamed with Personal vDiskd) Dedicatede) Existingf) Psysical/Remote PC3) Steamed VHD4) Local VM5) On-Demand Apps下表是关于FlexCast整体技术的一个概览：2. FlexCast模型选择在XenApp和XenDesktop之间有很多技术上的区别，但是他们都是通过HDX来提供的最佳用户体验。他们的区别如下：六、 应用程序评估在用户分组完成之后，我们已经有了根据需求不同确定下来的不同的用户组，下一步就是向用户提供他们工作需要的应用程序。下面是建议的三部曲：1. Rationalization 合理化2. Business Characteristics 业务特性3. 兼容性七、 项目管理1. Roadmap2. 项目团队下面的表格示例告诉我们在一个虚拟桌面项目中可以建议的业务角色和技术角色分类。虽然角色有很多种，但是很多角色的存在时间都很短，同时很多角色都由一个人同时完成。项目经理和Citrix架构师自然是贯穿整个项目的角色，其他就不一定了。1) 业务角色2) 技术角色 第二部分：Design一、 概况桌面虚拟化的设计并没有想象中那么简单，但是也绝不复杂，我们需要做的事情就是去遵循一定的设计理念以及已经被验证过的实践经验就可以了。简单说来，我们可以从桌面虚拟化涉及到的五层设计模型入手：二、 用户层 User Layer设计模型最上面的一层就是用户层，用户层和每个用户组息息相关。这一层将业务优先级的评估标准和用户组需求结合起来，进而可以定义有效的终端设计战略。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模式。下面的图显示什么时候使用用户自己拥有的设备，什么时候选择公司拥有设备：2) 决断：终端生命周期最小标准：即使是考虑到成本因素，为了保证用户体验，还是要不低于最小的硬件标准，这些指包括：1GHz的处理器、1GB的内存、16GB的空余磁盘空间，如果是要好的HDX体验还要有GPU卡；业务驱动：所有项目成功都来自于正确确定优先级。对一个公司来说，延长PC的折旧期对成本节省来说很重要，而公司更多考虑的是绿色环保因素，可能新购终端反而更有利。最终需求还是要考虑Error! Reference source not found.：业务驱动力工作负荷：工作种类应该和FlexCast模型相互配合下面的表格列出了当我们准备重新利用现有的硬件，亦或者是新购设备时的推荐计划：3) 决断：终端规格瘦客户机的处理能力已经极大的增长，即使是中等的手机现在也能够实现图形处理能力了，包括HDX特性等都不在话下，例如多显示器支持等等。很多企业都会将瘦客户机和PC混合部署，我们需要记住的是用户组的特性才是最终决定需要采用哪种模式的最重要因素：4) 决断：瘦机选择瘦机厂商现在有越来越多的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的问题。2. Receiver的选择1) 决断：Receiver的类型大部分的企业都知道将Citrix Receiver简单的部署在兼容它的终端上，但是实际上Citrix Receiver在部署了不同的插件之后，功能还是有着很多的不同的。所以，确定用户组的需求就决定了如何选择Receiver的类型。这里本来有个表格的，可是太大了，建议大家直接看pdf文件的Page 44.我个人以前就对Citrix Receiver和Citrix Receiver Enterprise版本有什么不同就有疑惑，在这个表中就诠释得非常清楚了。前者没有Desktop Lock功能和非接触式智能卡功能，而后者就没有通过Merchandising Server的插件管理功能除此之外，其他我能够看到的差别还有：l 对XenApp的支持中，Win8/RT、黑莓、HTML5上的Receiver就只能部分支持；l 而XenDesktop功能基本上所有版本都支持；l 基于Email地址来配置Receiver：除了黑莓和HTML5的Receiver客户端，其余都支持；l 智能卡支持：所有平台均支持；l 快速访问/非接触式智能卡：目前只有Citrix Receiver Enterprise版本支持；l Flash重定向：只能在Citrix Receiver、Citrix Receiver Enterprise、Receiver Linux版本上支持，其他例如MAC、HTML5以及所有平板和智能手机统统不支持，online plugin也不支持哦；l UDP语音：只在Citrix Receiver和Citrix Receiver Enterprise版本、Receiver MAC、Receiver Linux版本上支持；l Pre-Launch功能：只支持Citrix Receiver和Citrix Receiver Enterprise版本；l AERO特效：Windows的玩意当然只有Citrix Receiver、Citrix Receiver Enterprise版本以及Windows 8/RT的Receiver才支持；l 磁盘重定向：除Win8/RT之外所有的平板、智能手机以及HTML都不支持，l 剪贴板支持：只有 Citrix Receiver、Citrix Receiver Enterprise版本和Receiver MAC才支持，Linux版本的也不支持哦！l HDX 3DPro支持：只有Citrix Receiver和Citrix Receiver Enterprise版本完全支持，Linux、MAC、Win8/RT都是部分支持；l ShareFile：黑莓、HTML5、Win8/RT不支持，其余都支持；l AG的远程访问：Citrix Receiver、Citrix Receiver Enterprise版本和Receiver MAC需要安装插件才支持；Linux不支持哦！Win8/RT、安卓、苹果天生就支持，至于HTML5，不好意思。l 离线应用程序：只有Citrix Receiver和Citrix Receiver Enterprise版本支持；l 单点登录：只有Citrix Receiver和Citrix Receiver Enterprise版本支持；这个要注意一下；l StoreFront支持：黑莓、Linux和HTML5不支持；l Desktop Lock：只有Citrix Receiver Enterprise版本支持，Citrix Receiver都不支持哦！2) 决断：Receiver部署在部署和升级Receiver时，以下机制可以考虑和利用：l StoreFront：如果Citrix StoreFront已经安装，管理员就可以通过一个Web站点来部署Receiver，用户只需要打开网页就能自动安装；l 内部下载站点：有时候用户会被禁止访问互联网，那么管理员就可以创建一个内部站点来安装Receiver。典型的模板可以参考Citrix Receiver Download Page Template主页，它包含了所有版本Receiver的下载软件和自动安装方式。l Web Interface：这是我们最常见的方式，不过要注意的是，他不支持基于电子邮件帐号来发现的安装方式。基于电子邮件帐号来发现的安装方式对BUOD来说非常合适。l Windows Store：在Windows 8 Store里面可以下载到Windows8/RT的Receiver软件。目前Receiver只支持ARM或者是基于Intel芯片的Windows8/RT设备。l 移动设备：移动设备一般都有自己特殊的方式来安装软件，例如n 应用程序商店：包括安卓的Google Play，或者是Apple的Apple Store；n 其他移动部署方法：有的移动平台可以提供企业级方法来部署，例如黑莓就可以通过BlackBerry Enterprise Server来部署BlackBerry平台上的Receiver；l Merchandising Server：这也是一种方法。除此之外，Merchandising Server还能够用来升级Receiver以及安装Receiver的插件，它可以定期连接到Citrix Update Service去检查有没有最新的软件。l Master Image：这个办法最简单，直接将Receiver做到操作系统镜像文件中；Receiver的升级可以通过Citrix Receiver Updater Plug-in，或者是Merchandising Server，也可以是其他软件分发工具；l 软件分发工具：例如LANDesk、MS的SMS，以及Symantec Altiris；l 组策略：可以自己写一个启动脚本来部署Receiver，甚至卸载Receiver，在XenApp和XenDesktop安装光盘里面也自带了这个脚本；l 手动安装：所有版本的Receiver都可以在Citrix Receiver Download Page 下载到。用户只要登录到这个站点，网站会自动检查终端的类型和下载介质。唯一的缺点是你还要手动配置Receiver的连接属性。最好的办法是通过基于电子邮件发现的方式。这种方式最适用于BYOD环境。下面的表格总结了每种方法适用于的Receiver版本，因为表格太大，请大家自行参考第48页。3) 决断：Receiver配置l 基于电子邮件的自动发现和配置：最新版的Receiver可以通过只需要输入自己的公司邮箱就完成配置。这个功能需要StoreFront以及指向StoreFront服务器的FQDN域名的一条SRV记录；n 注意：DNS平台需要支持基于电子邮件的发现，目前只有Windows DNS测试过；n 如果是远程用户，就必须配合Access Gateway，同时在DNS中有对应的SRV记录；此外，在Access Gateway硬件或者是StoreFront服务器上必须有有效的服务器证书。l 组策略：启动脚本也可以用来配置Receiver。脚本中有一行这样的参数：SERVER_LOCATION=Server_URL. 缺省的值是空,将Web Interface或者是StroeFront的地址输入进去l Provisioning File：如果是运行了StroeFront的环境，我们就可以从StoreFront服务器中到处一个.cr为扩展名的文件，然后将此文件放到共享文件夹，或者是发布到网页中，用户下载后双击可以自动打开该文件并继续自动配置。l 自动生成的设置URL：对于移动设备和MAC桌面来说，可以通过一个叫做One Click Provisioning的工具来创建一个设置URL来进行配置。管理员只需要在这个工具中输入所需要的信息，该工具就会自动生成URL。由于该工具并没有包含用户名和密码信息，所以可以将该地址通过电子邮件发送给用户，又或者将该URL发送至文件共享服务器中亦可。该工具对远程用户，Web Interface等适用。l 手动：不多说，呵呵。4) 决断：Receiver升级l 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保持定期通信以升级必须的组件。l 软件分发平台：例如LAN Desk和Symantec Altiris等平台；l 手动升级：最后一个，也是最有效的办法。3. 资源需求无需多言硬件参数，包括服务器的CPU、内存、硬盘以及后台的网络设备、存储有多重要了，其实更重要的是在性能和成本之间达到一个最佳的平衡。我们首先将用户组按照性能需求分为四种性能组：至于Scalability Assumptions，按照以下内容来估算：l CPU的速度：按照2.7GHz和Intel Westmere处理器架构来设计；l 超线程：超线程可能可以达到20%-30%的性能增长，但是有时候也会带来负面效应。我们设计时都是不算超线程的；l 工作负荷：假设已经加载了防病毒软件和标准的监控工具；l Hypervisor开销：已经从每用户core中减去；l 内存：大部分用户在一天中所使用的内存都在不同程度的增长，原因有很多；因此，内存应该算最大值。1) 决断：CPU下面的表格实力了在不同负荷用户情况下每物理CPU core所能支撑的用户数。此外，需要注意的是从两路CPU到4路CPU性能并不是线性增长的，我们要预留15%的用户数降低；此处注意的是，如果你采用了PvD技术，经我们测试显示，大概有14%的性能下降，记住要把这个因素考虑进去。另外，PvD在5.6.10版本及之后的版本都不再支持WinXP，所以目前没有XP下的数据。下面的表格可以用来计算每个用户组所需要的CPU资源：物理CPU核数 = 用户组的最大CCU数量 / 每个物理core所支撑的用户数2) 决断：内存下面的表格列举了在不同负荷和FlexCast模式下所需要的内存数量：3) 决断：IOPS见下表：需要注意的是上面的数字都是稳定状态下的，不是峰值状态。裸IOPS = 写IOPS写惩罚 + 读IOPS写惩罚的规定：4) 决断：存储空间在PVS环境下，所有对虚拟桌面的写操作都是发生在写缓存中，但是在MCS模式下，写操作确实发生在Diff Disk中。写的内容包括：l User Profilel 系统临时文件和应用程序临时文件l Windows、Citrix和应用程序的日志文件PVS模式的写缓存和MCS的差异磁盘所需要的磁盘空间取决于应用程序的使用量和用户的动作。不过，下面的表格有一个大概的评估值：几点注意事项：1) PVS写缓存启动时最小，但是使用过程中会不断增长。重启VM后被清除；2) 在某些情况下需要将数据重定向到写缓存的磁盘中这样在重启时也能保留，例如EdgeSight数据、Windows日志和防病毒软件的定义库文件；3) 包含了10G的PvD数据磁盘大小；4) MCS模式下推荐使用NFS的存储以利用Thin Provisioning能力；三、 访问层 Access Layer访问层的设计主要是基于每个用户组和终端设备的移动性需求。1) 决断：认证点让用户在什么地点做认证是管理员的决定，一般而言，有四个认证点：a) Web Interface：给XA和XD提供安全访问；b) StoreFront：为Receiver交付认证能力和资源；c) Secure Gateway (Web Interface): Secure Gateway是一个Windows的应用程序，她和WI配合工作；d) Access Gateway: 硬件具体采用哪种方式认证由用户组的移动需求来决定，推荐方案如下：2) 决断：预认证策略如果我们使用的是Access Gateway，我们就可以选择是否采用预认证策略，这些策略可以是确定终端是否满足某种接入网络前的扫描条件。我们可以配置的策略包括测试防病毒软件、防火墙软件、操作系统，甚至是注册表键值。XA和XD可以利用这些策略的检查结果确认后续的动作，包括剪贴板是否开启，打印机映射，甚至是否开启特定的应用程序访问权限。例如，如果用户没有安装防病毒软件，可以配置策略隐藏敏感的应用程序。下面的图标从流程上示例策略配置是如何流转的：3) 决断：认证策略l Web Interface, Secure Gateway (Web Interface), or StoreFront: StoreFront是未来的方向，而Web Interface已经是行将就木，所以下面的策略主要是用在StoreFront上，当然也适用于Web Interfacen 用户名/密码n Domain Pass-Through：允许从用户设备上透传Domain登录信息，用户登录到加入域的电脑后自动登录到Store；n Access Gateway Pass-Through：用户登录到Access Gateway后自动登录到Storel Access Gateway：NetScaler支持几种不同的认证手段。下面分别列出了几种主要的认证方法，每种方法都可以单独使用，但是在实践中，我们进场组合起来以提供多因素认证。n LDAP：轻型目录访问协议是我们最为熟悉的认证方法了，它是一种基于TCP协议的目录访问服务，例如MS的活动目录就是其中一种实现形式。n Radius（aka Token）：Radius全名是Remote Authentication Dial In User Service，这是一种基于UDP传输协议的安全认证协议。除了认证外，它还提供授权和计费功能。Access Gateway转发用户输入的用户名和密码给Radius服务器，Radius服务器可以立即检查用户名和密码，也可以转发给目录服务器。n 客户端证书：用户登录到Access Gateway虚拟服务器后，可以通过本地的客户端证书的属性来做认证。客户端证书通常在用户端的形式是智能卡，或者是Common Access Cards (CACs)的形式，再通过客户端本地的读卡器来读取信息。采用什么认证形式通常都是取决于安全的需求，以及使用什么认证点。下表给出了一个基于安全需求级别的示例：4) 决断：会话策略采用Access Gateway作为认证点的用户必须有对应的会话策略来定义用户体验。会话策略的制定是基于Receiver在设计阶段制定的。一般而言，首先我们会将设备分为非移动设备和移动设备两种：l 移动设备：表达式定义为：“REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver”，该语句将移动设备设置为比非移动设备更高优先级以保证移动设备的匹配性。l 非移动设备：表达式定义为：“ns_true”，即所有流量。更多信息，可以参考Citrix公开电子文档：Receiver and Plug-insBTW，另外一种会话策略是采用终端的扫描方法。5) 决断：会话Profile（Session Profile）每个会话策略（Session Policy）都必须定义一个对应的Session Profile（姑且翻译成会话配置文件）。这个会话配置文件定义了用户去访问资源时的访问细节。有两种定义到虚拟桌面环境的访问方式的会话配置文件的形式：l SSL VPN：传统的VPN方式，将网络全部打通。这种方式并不一定十分安全，因为这能导致客户端到内网服务器的攻击访问。另外一种办法是考虑是否在SSL VPN中开辟一条给客户端网络流量的单独通道。这样通过receiver的流量智慧限制在指定的端口，只能访问指定的服务器资源等。上述两种方式各有利弊，第一种方式虽然安全性差了，但是可以做客户端流量可以被企业的网络过滤设备，例如入侵检测设备做监视和控制。l HDX Proxy：在HDX 代理方式下，用户是通过Access Gateway连接到他们的虚拟桌面和虚拟应用。这种方式下完全没有将内部资源暴露到公网上，此时Access Gateway充当了一个微型VPN的作用，它仅处理HDX的流量。其他的流量，例如电子邮件，又或者是使用者上网的流量都不经过Access Gateway。6) 决断：访问带宽最后的访问层决断就是要决定虚拟桌面所需要的最大并发网络带宽。其中很重要的一个关键环节就是决定采用NetScaler Access Gateway的哪一个平台。每个用户所需要的带宽关键还是要看计算的需求。一个时不时才用一下电脑的ERP使用者和一个在电脑前屁股都不挪窝的OA用户肯定带宽要求是不同的，如果是CAD画图的用户那就更不用说了。理想情况下带宽的使用情况是通过带宽分析工具来给出来，不过我们还是可以给出一些经验值：总带宽的的计算公式可以这样来定义：总带宽 = 平均带宽 最大并发用户值更多细节，可以参考Citrix的知识库文章：XenDesktop Planning Guide: User Bandwidth Requirements四、 桌面层 Desktop Layer设计思想的第三层，也是和用户相关的最后一层，就是桌面层。用户是否能接受桌面虚拟化很多程度上就是在这一层实现的，例如包括个性化、应用程序，以及后台操作系统镜像文件的设计。1. 应用程序交付选择正确的应用程序交付方法会对整个系统设计的可扩展性、可管理性，以及用户感受起到非常大的帮助。基于我们在前几章节的“Error! Reference source not found.”，我们可以考虑以下几种交付方法：l 直接安装在操作系统镜像文件上：应用程序是基础操作系统镜像文件的一部分；l 安装在Personal vDisk上：物理是分离的，但是逻辑上是直接安装在基础操作系统镜像文件中；l 流化（Streaming）：应用程序被profiled（XenApp组件）后通过网络交付到桌面上。应用程序的文件和注册表键值在虚拟桌面的一个容器中保存，但是和基础操作系统镜像文件是分离的。l Hosted：应用程序安装在XenApp服务器上，用户通过Citrix HDX协议远程访问。1) 决断：应用程序交付方法系统架构师应该在基于用户需求、应用程序兼容性，以及其他通过在前几章（“Error! Reference source not found.”）搜集上来的应用程序因素基础之上决定采用何种方法来进行应用程序的交付。通常单一的方法是无法满足用户全部的需求的，所以多种方法组合才是最佳答案。但是不管用什么方法，这些交付手段都应当对整个项目的交付复杂程度和后续跟进步骤与以最小的影响。下面的表格就是不同的交付方法对系统不同层面的影响：除了应用程序交付方法对系统不同层面的应用之外，系统架构师还应该考虑应用程序在不同交付手段上的适用性。下面的表格就是不同应用程序所推荐的部署方法示例：上表中需要注意的是最后一种应用程序，我们往往会觉得这种复杂安装和配置的应用程序最好是安装在操作系统镜像文件中，但是最佳实践告诉我们应该安装在XenApp Server上，通过Hosted的方法发布给用户。2) 兼容性任何一个桌面虚拟化项目都会对一个公司的应用程序交付方法产生巨大的应用。举例来说，许多公司都希望通过在桌面虚拟化中使用流化的应用程序交付或者是XenApp交付应用程序来降低升级用户的桌面操作系统的劳动负荷以及提高管理效率。所以在设计阶段我们就要做很多兼容性测试以确定最正确的应用程序交付方法。最重要需要考虑的兼容性需求一般来说包括以下几点：l 桌面操作系统的版本：如果操作系统是通过流化安装或者是直接安装在操作系统中，那么应用程序需要考虑和操作系统的兼容性问题；l 服务器操作系统的版本：有一些应用程序可能会更合适通过XenApp的方式来交付，所以，应用程序是否能安装在服务器版本的操作系统平台上是要考虑的因素；l 应用程序本身的架构：应用程序本身的开发平台有可能是16位的，32位的，也可能是64位的。16位的应用程序就不能运行在64位的操作系统平台上，例如Windows 2008ServerR2、Windows XP 64bits等；l 互操作性：有一些应用程序如果和某些版本的操作系统共存是会有兼容性问题，例如注册表冲突、DLL冲突，或者是ini冲突。l 应用程序流化：应用程序流化到桌面虽然可以简化管理，因为操作系统上不用安装那么多的应用程序了，但是记住有些带有设备驱动程序，或者是使用了COM+等应用程序就不适合了在做应用程序兼容性测试时的三种主要技术手段有：l 手动：不言而喻这种方法最消耗时间，每种交付方法都要测试，每种操作系统版本、不同操作系统语言包等也都要验证。手动模式下想要的出应用程序所有方面的测试结果是非常困难的，对应用程序互操作性的测试是几乎测不出来的。而且更多的测试结果是现场使用人员发现的，而不是测试时发现的。l 预验证的应用程序：很多应用程序的开发商都会提供该应用程序的兼容性文档和最佳安装方式的文档。参考这些文档会有直接的帮助。此外，Citrix Community Verified的网站上也有一整系列的由Citrix的客户和合作伙伴验证过包括采用流化方法/XenApp/Xendesktop兼容的应用程序列表。微软公司也提供了类似的应用程序列表：Microsoft Windows 7 Application Compatibility List for IT Professionals；l 自动化的工具：Citrix AppDNA可以快速而且准确的对应用程序的兼容性做出精确的测试，包括测试不同的操作系统平台，测试不同的交付手段，例如Windows XP、Windows 7、Citrix XenApp、Microsoft App-V，以及Citrix Streaming流化交付方式等。应用程序被导入到AppDNA时，它会被和数千种应用程序进行兼容性的匹配验证以判断是否有互操作性问题。当发现问题时，AppDNA会告知问题出自何处，可能的解决办法，以及估计解决的时间。上述每种方法的优点和缺点都列在下表中：测试做完之后，兼容性的结果就应该填入到之前的应用程序评估表各种以便我们的后续分析：l 预运行环境：许多程序都有运行环境的要求，例如Java、.Net环境，或者是数据库要求；l 程序之间的依赖：例如，需要以pdf格式呈现信息的应用程序就需要电脑上安装了pdf的阅读器；l 16位的代码：应用程序评估也应该判断是否应用程序包含有16位的代码，因为16位的代码是不能运行在64位的操作系统平台上；l Windows XP：确认应用程序是否能通过Windows XP的兼容性测试；l Windows 7：确认应用程序是否能通过Windows 7的兼容性测试；l XenApp 6.5：确认应用程序是否能通过XenApp 6.5的兼容性测试；l Application Streaming 应用程序流化安装：确认应用程序是否能通过流化程序安装的兼容性测试；3) 用户分类通常不是所有用户都需要所有的应用程序，有些程序可能就只有很小一部分用户用的上。所以系统架构师应该做好这个工作，例如如果一个部门的用户都需要的应用程序列表组，我们可以单独做一个操作系统镜像文件。如果只有少部门用户需要使用，那我们建议采用Personal vDisk或者是Streaming的方式交付应用程序。4) 业务特点l IT经验：如果IT部门已经对某种应用程序交付方式有经验，或者是基础架构已经Ready了，那么这种交付模式可能就是合适的方式。例如，如果公司内部已经通过Microsoft App-V平台部署过Streaming的应用程序，那么XenApp Streaming 应用程序就应当优先被考虑。l 管理需求：应用程序交付的方法很可能严重依赖于应用程序的拥有着。如果应用程序是公司拥有的程序，那么IT部门就有责任和义务来维护该应用程序，包括XenApp发布或者是XenApp流化。如果程序的拥有者是某个下级部门，那么IT部门就不方便集中管理，这种情况下应用程序可能就建议安装在Personal vDisk上，让部门自己来管理该应用程序。l 升级频率：应用程序的升级所需要花费的时间和部门协调也对交付模式的选择有很大影响。如果应用程序经常升级，那么系统架构师就应当选择安装数量最少的交付模式，这样可以减少升级的应用程序数量，以及降低升级的复杂程度。这种情况西XenApp交付方式最为合适；l 产品Licensing：如果应用程序没有License要求，例如和软件厂商签订了Site License，那么我们可以将该程序发布给所有的用户也不会产生其他任何成本，将该程序直接安装在操作系统模板里面也能降低交付的复杂性。如果应用程序对License很敏感，系统架构师就需要考虑采用一种能够遵守应用程序软件提供商要求的License模型。5) 技术特点l 资源使用：如果应用程序对资源要求很高，可能会更合适于直接在虚拟桌面里面直接运行；l 技术难点：如果一个应用程序的安装都很复杂，例如需要专门的配置，脚本的运行，或者对其他应用程序有很多要求，我们称之为技术难点。这种情况下，安装在XenApp Server上能减少操作系统镜像文件制作的复杂性。五、 控制层 Control Layer控制层是设计架构的第四层。在上面有关用户的三个层面我们所做的决定都会汇总起来到控制层。访问控制器子层的职责是给每个用户提供予以支持访问控制层的基础架构组件。这么说可能比较绕口，那就换个说法吧，访问控制器一般包括例如Web Interface、StoreFront，以及NetScaler Access Gateway；1. 远程访问架构如果有用户需要远程或者是离线的移动访问能力，那么就要设计远程访问基础架构了。1) 决断：拓扑网络拓扑的设计对远程访问架构能够支撑功能性、性能以及安全性至关重要。远程访问架构应当和安全团队一起合作以确保符合企业的安全规范。以下三种主要的拓扑结构我们在设计师可以考虑，每种的安全性逐渐递增：l 1-Arm (Normal Security，单臂模式)：在这种架构下，Access Gateway使用一个物理的或者是逻辑的Bonded的网络接口，再加上VLAN和IP子网的设计，来传递用户和后台虚拟桌面的流量。l 2-Arm (High Security 双臂模式)：在双臂模式下，Access Gateway利用两张或者更多的物理或者逻辑Bonded的网络接口卡，再加上VLAN和IP子网的设计，来传递用户和后台虚拟桌面的流量。前段用户的流量被导向这些网络接口卡的第一张网卡上，前后端的流量是被分离设计的，就是说说后端虚拟桌面架构服务器的流量是被定向到第二张网卡上的。通过这样的设计我们就可以DMZ区来分离前后端的流量，同时还可以定制防火墙策略和流量监控策略。l 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设备和内部网络的SecureTicketAuthority（STA）也是通过第二个DMZ区的Access Gateway设备来进行代理的。2) 决断：平台在Access Gateway部分，我们曾经讨论过只要是涉及到远程访问，我们都会考虑NetScaler Acce