bad-thing-pass

collab_projects

首先我们来回顾一下历史: Xen-history

上周Citrix把经营和支持多年的开源项目Xen Project加入到了inux Foundation,可以说是Xen Project 的一个新家。可能您还不太了解“Linux Foundation”;访问 FAQ 可获得它的一些基本知识。到目前为止Linux Foundation总共支持了8个开源软件项目。

[![OpenDaylight](http://www.linuxfoundation.org/sites/main/files/logo_od_small_0.jpg)](http://www.opendaylight.org/) [![](http://www.linuxfoundation.org/sites/main/files/wlogo_caf.jpg)](https://www.codeaurora.org/) [![](https://www.linuxfoundation.org/sites/main/files/wlogo_omam.jpg)](http://www.openmama.org) [![](https://www.linuxfoundation.org/sites/main/files/wlogo_tize_0.jpg)](http://www.tizen.org)
[![](https://www.linuxfoundation.org/sites/main/files/wlogo_meeg.jpg)](http://www.meego.com) [![](https://www.linuxfoundation.org/sites/main/files/wlogo_yoct.jpg)](http://yoctoproject.org/) [![](http://www.linuxfoundation.org/sites/main/files/xen_project_unicolor_0.jpg)](http://xenproject.org) [![](https://www.linuxfoundation.org/sites/main/files/wlogo_fbaz.jpg)](http://fossbazaar.org/)

那么Linux foundation能给这些开源软件提供怎么呢?

With ten years of experience managing open source projects and support services, The Linux Foundation can provide the back-office, technical infrastructure and legal framework to get your collaborative project off the ground quickly and efficiently.

想加入Linux fondation的项目还必须满足如下两个标准:

  • The use of open source governance best practices including license and contribution agreement choices in keeping with the ideals of Linux

  • The project must have the potential to fuel innovation in an industry through collaborative software development

我个人认为,这对于Xen Project和Citrix双方来说都是一个好事,Xen Project可以获得跟光明的发展前景,Citrix的商业产品XenServer也基本上可以直接从中受益。对Xen的处理,Citrix的做法和处理CloudStack是相同的,只是CloudStack交给了Apache组织。在国外这是一种成熟和成功的商业模式,开源软件项目周边发展出的是生机盎然的生态系统。

Citrix的官方新闻 :Citrix and Industry Leaders Usher in New Era for Open Source Xen //Strong Industry Support Drives Need for Independent Xen Project Initiative Xen Project官网新闻:Xen is now a Linux Foundation Collaborative Project Linux Foundation 新闻: Xen to Become Linux Foundation Collaborative Project Jim Zemlin (Executive Director of Linux Foundation)欢迎Xen的加入: Welcome Xen as a Linux Foundation Collaborative Project 对Xen Project做持续贡献的厂商么是这么反馈的: 查看 Xen Project的旧家:  http://www.xen.org/ Xen Project 的新家:http://xenproject.org/ 请记住Xen的标志物,功夫熊猫:[gallery ids=”52363,52365,52366”]

ZDNet 的评论: Xen, Citrix’s popular open-source hypervisor, is becoming a Linux Foundation Collaborative Project with the backing of such major technology powers such as Amazon Web Services, Google, and Intel.

arstechnica.comd的评论:Linux Foundation takes over Xen, enlists Amazon in war to rule the cloud ///Xen virtualization gains support from Amazon, Cisco, Google, Intel, and more.

[box color=”orange” icon=”flag”] 感谢 Eric Yao 的供稿,@老树皮Eric [/box]

桌面虚拟化项目的实施白皮书 《Citrix Virtual Desktop Handbook 5.x》,点击下载

智慧的积累靠一蹴而就很难实现,慢慢积累和温故而知新往往是最佳的手段。让我们继续开始《Citrix桌面虚拟化实施部署白皮书》,这晚我们开讲第二部分的第三单元:桌面层。

四、 桌面层 Desktop Layer

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

  1. 应用程序交付

选择正确的应用程序交付方法会对整个系统设计的可扩展性、可管理性,以及用户感受起到非常大的帮助。基于我们在前几章节的“四、 应用程序数据搜集”,我们可以考虑以下几种交付方法:

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

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

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

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

1) 决断:应用程序交付方法

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

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

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

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

2) 兼容性

任何一个桌面虚拟化项目都会对一个公司的应用程序交付方法产生巨大的应用。举例来说,许多公司都希望通过在桌面虚拟化中使用流化的应用程序交付或者是XenApp交付应用程序来降低升级用户的桌面操作系统的劳动负荷以及提高管理效率。所以在设计阶段我们就要做很多兼容性测试以确定最正确的应用程序交付方法。最重要需要考虑的兼容性需求一般来说包括以下几点:

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

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

l 应用程序本身的架构:应用程序本身的开发平台有可能是16位的,32位的,也可能是64位的。16位的应用程序就不能运行在64位的操作系统平台上,例如Windows 2008Server R2、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上能减少操作系统镜像文件制作的复杂性。

[su_box  ] 最近有一篇比较热的文章,中文标题《Forrester:70%的“私有云”根本不是云》;你如果稍微搜索一下,你发现它几乎被转载烂了,但是我看了几篇,真心的担心读者们是否都能正确的理解。写本文,全当是给您的一个阅读帮助。 [/su_box]

中文版网页点这里 英文版网页点这里

中文翻译的质量有限,有些概念和逻辑错误,我做了一点点的修订,从而避免误解。

【基于CNW.com.cn译稿】如果企业数据中心拥有高度虚拟化的环境,有一个Web门户供商业用户申请和访问虚机,再有一种方法可以跟踪有多少资源被使用了……拥有这一切并不能叫做有了一个私有云

假如有足够大的容量可以为员工提供他们所需要的任意数量的计算资源,并能够动态地上下扩展或收缩容量,但仍然需要IT人员制备好系统的话,那么这仍然不能叫私有云。

虚拟化和私有云之间的界限是比较模糊的,根据Forrester的最新报告,在企业的IT高管们所自诩的私有云中,高达70%的IT环境其实并非私有云。“这是个严重的问题。实际上是在做云洗白而已。”Forrester的云专家James Staten如此说。

为什么说这个问题非常重要? Staten认为,如果将一个高度虚拟化的环境称为云环境,但它又不具备私有云的一项或多项关键特征,那么IT部门就给了用户一个不切实际的期望。假如用户们发现这个环境不能自配置,或者没有弹性资源池而感到不满时,他们就有可能因此而气馁。那么当下一次用户需要实时运行一个虚机时,他们会选择在哪里运行呢? 是IT部门给他们的伪私有云? 还是亚马逊的AWS? 如此一来,IT部门就无法控制事态了。

大多数云专家已经对云计算(公有云或私有云)的定义有了普遍的共识,这就是NIST提出的五个关键特征。这些特征包括:

● 用户可按需索取、自服务

● 泛在的网络接入

● 共享资源池

● 弹性扩展资源的能力

● 拥有可计量的服务

如果没有这五大特征,那从技术上说就不能叫云。和某些人的想法相悖的是,虚拟化并不是私有云。它只是为云提供动力的一个基本要素,但只依靠它是创建不出一个云的。VMware的营销经理Mike Adams说,私有云必须在虚拟化环境之上综合更多复杂的管理功能,方能满足NIST的定义要求。

CA的战略解决方案副总裁兼云专家Andi Mann给这场讨论踩了一脚刹车。“如果你不符合所有这五大特征,那么你就陷入了语义学纠结中。”他认为真正的问题并不是说符合这五个复选标记的东西就叫做云,而是在于IT能否为用户提供适当的服务。“有时候,80%的云都已足够好了,”他说。“用户真正在意的是业务服务。谁会在意你的环境叫什么。你要关心的就是客户,就是业务用户是不是得到了他们需要的资源。”

也许企业并不需要弹性扩展,因为原本就是静态工作负载。即便不需要弹性的资源扩展能力,它仍然还可以需要云的其他特征——自服务、计费、泛在网络接入和共享资源池。但它在技术上可能并不符合NIST的定义。“所以,如果你要想技术上也说得过去,也可以将其称为:高效率的虚拟环境,”Mann说。

那么,所有这些云洗白来自哪里? Staten认为,IT管理人员基本上对云都抱有恐惧心理。企业内的虚拟化专家通常都处于支配地位; 在需要资源时,他们可以去制备相应的资源容量。而云被视为一种赋予用户自服务和动态扩展资源权力的模式,对IT是一种威胁。如果用户可以自己开通了,那还要他们这些虚拟化专家干什么呢?

Staten认为,这样想上述问题是错误的。即便有了云,IT管理人员还是有大量的工作可做,比如需要设置和确保云服务有一个可供用户选择的服务目录,需要完成安全访问协议配置,提供资源可用性和虚拟化组件等。管理人员必须接受这样一个理念:如果他们不这么做,那么用户不论如何还是需要访问和使用他们所需要的资源,这样还是会陷入可怕的“影子IT”的局面。(Martin修订)

我想先对以上的几个关键点和名词做一些解释,从而能让我们更好的理解原文作者的意图。

  1. “cloud-washing”  –  “云洗白”   这个比喻是说:本来根本什么云都不是!但是还是要狡辩和伪装为私有云。真像是:纯虚拟化环境不等于云

  2.  ”shadow IT.”   –  “影子IT”  这个比喻是说:IT部门是业务部门挥之不去的阴霾,他们跟没发赶上业务部门需求变化请求的脚本,业务部门的人从来不管你是用的是神马云,你们这帮人根本没有按时的交付过任何东西,甚至于每当想起需要IT部门来配合做什么东西,就感到没有指望,啥都需要漫长的等待。

IT部门真的是技术不行么?IT部门真的是干活的人不够么?这个比喻后背后真是的故事:特别是大规模的企业,业务部门所需要的任何IT资源和变更都必须通过IT自动、半自动或者手工配置实现;小的到开通一个邮箱,重置一次密码;大到新的业务系统的升级和上线;往往IT或者业务用户发频繁和密集地发起种种请求时,没有任何一家传统企业的IT部门(亚马逊、谷歌这种公司除外,因为它们已经是云计算公司了)能够很有自信地、充分让业务部门满意地完成被要求完成的所有工作。它们为什么完成不了呢?这个就走入了IT管理的经典理论,这就是我之前十年工作经验中天天和用户沟通的东西:“保持IT系统的稳定,还是接受变化”;为了既能响应业务部门不断的变化请求和IT用户的日常需求,IT部门想到了很好的流程来加以解决,这个流程是什么?它叫“变更管理流程”。举个例子,大型的商业银行一般一周或者两周有一次系统变更日;所有的对IT系统的配置和改变,必须提前计划安排好工作顺序,只能在变更日当晚的固定时间窗口中完成,例如晚上11点到凌晨5点;如果在这个时间段某个工作没有完成怎么办?对不起!没有完成的变更叫做失败变更,你还必须在变更窗前前就把系统回退到未变更前的状态!你现在发现了么?对生产系统是多么严肃的事情!如果你在变更前,没有万无一失的备份计划,你但失误,你就歇菜了;或者你觉得是顺利完成变更了,但是营业厅一开门,IT的投诉热线就被打爆了,这也不行;变更一但导致生产系统的宕机,轻则IT部门的领导引咎辞职,重则数据中心的大领导乌纱帽不保。

以上讲述的故事可以说是我的亲身经历,就是中国的国情;那么这个文章的出处毕竟是国外的,这几个发话的大佬们都是何方神圣?

Forrester的云专家 James Staten :BIO 从Bio上看,他好像是Forrester的头牌云分析师之一,有20年的IT从业经验。

VMware的营销经理Mike Adams :网上查不到它的Bio,在VMWare网站搜索,也只能看到他是http://blogs.vmware.com/vsphere/ 的负责人。网上并没有关于此人的详细介绍,但是我们从vsphere的blog上在读一下这个产品的定位“BEGIN THE JOURNEY TO A PRIVATE CLOUD WITH DATACENTER VIRTUALIZATION”;这个说法和此大师在文章中说的一样:vsphere是数据中心虚拟化的一个技术组建,数据中心虚拟化技术是私有云建设的起点。但是它是起点,不是私有云。纯种的服务器虚拟化项目也不是那天就能进化成私有云了。

CA的战略解决方案副总裁兼云专家Andi Mann :BIO 从Bio上可以看出,这大叔才是练家子,人家84年从IT管理员出身干起;感觉它说的话比较在点子上,并没有去忽悠云;而是从云的本质,也就是IT的本质去看,去分析的。也就是“IT是提供服务和支持的,为的是让用户能够操作和使用业务系统去完成业务工作。” 如果这句话抽象,我可以举个例子:领导需要阅读邮件,他关心的是IT能否让我安全的在设备上查邮箱,浏览和回复邮件;当然你能让他在任何设备、任何网络上、任何时间都能完成以上动作,那就再好不过了。银行的储蓄业务柜员需要的是完成一个存、取钱、开销户等相关操作,他关心的是IT系统能够正常快速的相应,让客户快速的离开柜台;她根本不关心,网线后面连接的系统是啥做的。

言归正传:把焦点放到“云”的概念上一点意义都没有!倒不如把心思放在云的价值上;把心思放在私/公有云的建设方案上!我试图从云计算的基础特征上来解读一下云计算对云企业的价值:

  1. 用户可按需索取、自服务:让用户能够更方便的访问(请求、开通和使用)IT资源和服务,用户无需等待,资源召之即来

  2. 泛在的网络接入:个人觉得这个应该翻译为高速度高带宽的网络接入,这个是外界访问到计算资源的必要条件之一;如果你资源再多,但是出口太窄也没有意义;如果翻译成这样也凑合如果能理解为,在个中网络条件下都能够正常安全的加入到云所提供的IT服务上也可以。

  3. 共享资源池: 这个可以提高IT资源的利用率,利用率高了,投资就减少了,浪费了低了

  4. 弹性扩展资源的能力:这个可以应付突发的大批量用户访问请求,并且能够自动资源回收,最重要的是这些扩展和收缩的发生都是云系统自动完成的,不需要管理员手工操作

  5. 拥有可计量的服务 : 这个对于IT部门需要向用户收钱的实在是重要;或者对服务提供商更重要,如果国内的用户实在没有这个需求也可以不强求。

那么,我们清楚了云的标准和价值后,我们需要判断的是什么?我认为是,我们为什么要建云?你在建云的时候,必须要有一个原因;有了这个原因了才有云的价值取向,才能谈到云的需求,才能谈到云的方案。当然,云就是以云的方案和设计理念去建设的,不存在伪云计算最终能进化或者发展成云计算这一说,就像是,猴子长的年纪在大也无法开口讲话一样。厂商也要不要故意误导,用户也不要片面理解。

在引申一下:云计算和虚拟化究竟有啥关系?我斗胆从云的经典分类上来说Iaas\PaaS\SaaS;从技术上讲,只有IaaS和服务器虚拟化有必然联系,其它两种PaaS和SaaS可以和虚拟化一点必然关系都没有,但是如果他们需要的话,可能可以利用到虚拟化技术的某些优势,但是用非虚拟化技术的架构实现这两种云计算一点问题都没有。网上盛传的“虚拟化是云计算的基石”根本就是一种误解;不过虚拟化的确能帮你做很多事,能帮助你交付很多种的IT服务。如果你一定要把他们挂上钩,那么你需要回答的是,你是否要建设IaaS云?你的IaaS云管理平台是什么,要关注在IaaS云计算管理平台的功能和能力上来,看你的IaaS是否需要管理多种类型的Hypersior?是否需要管理到分布在各地的成千上万个服务器?等等。。。从这些需求中才会细化出IaaS云管理平台对服务器虚拟化平台的需求。云计算建设是自顶向下的过程,从清晰的概念和建设思路出发,切勿本末倒置,切勿舍本逐末。

[box color=”orange” icon=”flag”] 感谢 Eric Yao 的供稿,@老树皮Eric [/box]

桌面虚拟化项目的实施白皮书 《Citrix Virtual Desktop Handbook 5.x》,点击下载

上周一我们介绍了《Citrix桌面虚拟化实施部署白皮书》的第二部分《设计篇 Design》的第一单元:用户层。今天我们继续往前进,开讲第二单元:访问层的部分。

三、 访问层 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 Interface

n 用户名/密码

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

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

l 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-ins

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

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 : XenDesktop Planning Guide: User Bandwidth Requirements