从项目实践浅谈桌面级别虚拟化

  　　最近比较忙，刚刚结束了一个桌面虚拟化的项目，总算是松了一口气。但说实话我自己对这个项目并不是太满意，尽管我们尽心竭力地完成了用户的要求，中间也花费了大量的力量去调整，请教过很多所谓的专家，但是总觉得有很多失落的地方，至多是画上了一个忐忑不安的句号吧。从2005年第一次接触虚拟机开始，虚拟化技术对我来说并不是很陌生，但近些年热炒的一些概念弄得人头昏脑胀。通过身体力行之后，我发现认认真真处理问题的人越来越少，更多的专家倾向于做一个架构性质的Solution让人家能相信你。当然这也不能怪人家心浮气躁，毕竟架构师比工程师受尊重多了(包括你的年薪)。这令人不禁想到十年前的装修行业。其实虚拟化技术蕴藏着很深的学问，绝不是随便考个XX认证就可以自诩为Profressional了。
　　当然我写这篇陋文不是为了显示自己有多高明。必须要说的是，在虚拟化领域我也是个新人，只是在项目实践后总结了一些心得，只是谈论一些自己的看法用于和大家来交流，免得将来忘记了。这篇陋文要是不经意地能给初入此行的同仁们些许的帮助就更好了，有什么纰漏或者错误地方欢迎大家指正。

1．应用虚拟化还是桌面虚拟化？
　　之前的调研工作非常重要，确定架构是关键的一步，不要为了节省成本想当然的确定架构。
　　应用虚拟化相对成本较低，但是需要考虑如下一些问题：
你的客户是否具备管理AD架构的能力？
你要发布的应用软件是否支持多用户？
应用软件的多用户支持是否良好？是否存在着多用户互操作的问题？
如何处理软件更新问题？
业务模式是否影响应用软件的使用？
如果某个应用软件耗费资源过多是否有方法限制或者隔离用户间的资源分配？
对于多台物理服务器如何安排应用软件的资源部署？
对于多台服务器重点考虑Profile的问题
那些服务需要组建群集？
需要多少时间完成测试系统的调试？
如果使用非微软的客户端收取邮件，如何处理软件的设置问题？
……
　　桌面虚拟化主要考虑这些问题：
是否有良好的硬件资源支撑(足够的网络带宽，高速的存储，强劲的处理能力)？
选择何种架构模式(池模式、专有模式还是混合模式)？
那些服务需要组建群集？
需要多少时间制作系统模板的调试？
如果使用非微软的客户端收取邮件，如何处理软件的设置问题？
……

　　当然这只是其中的一部分，你肯定还需要考虑更多的事情。

2．隐性成本的考虑
　　应用虚拟化的成本看似较低，但是还有一些问题你是否忽略了？
　　首先终端必须要采用携带OS的瘦客户端提供一个桌面环境以承载应用程序，这里面有两种OS，诚然微软XPE系统的授权费用通常会令每台设备会多出1000元左右的成本，但是Linux系统的桌面能否被业务人员接受也是需要你去考虑的因素。还有品牌的选用，经过测试发现不同品牌的终端质量还是有较大差别的，尤其是要在散热等方面好好进行测试，我的经验是把测试终端放置在你的生产环境中而不是设备厂商用于演示的实验室里。另外很重要一的点是参考工程师的意见确定实施工时，因为最好耗费时间的不是部署虚拟化，而是调试那些应用软件，除非你做的是桌面虚拟化而且不提供应用软件的安装。这是真实的，往往销售只顾自己报价把工程师当Free的。当然还有其他诸如微软CAL的销售费用计算，只不过这已经不在技术的讨论范围内了。
　　桌面虚拟化的也有类似的问题。其实最大的成本在于是否承担那些应用软件的部署，因为你不是厂商，所以基本上你很难推托掉这部分内容。而每一个客户的应用程序都不可能完全相同，所以能够借鉴的经验非常有限，这部分工作的可重用性几乎为零。所以如果你的方向是桌面虚拟化，那么要知道你的人工成本实际上是很高的。

3．虚拟化架构师30+的年薪到底值不值？
　　如果企业初次进入虚拟化行业，是否应当大张旗鼓地招几个年薪XX万的架构师来助阵？我倒不是说架构师无用，而是企业是否在适当的时机引入了适当的人才？这取决于企业发展到何种规模以及动用多少资金去做这件事情。
　　当项目做到一定规模后，架构师的作用才会逐渐的显现出来。架构师会对企业目标转向提供有价值的参考，对原有的工作模型提出改进性的建议。在企业进行市场战略决策时，销售、市场和技术架构师都是左右决策的关键。这就和微软工程师的处境一样。为什么现在很多人都转投了Linux？并非做Windows不好，只是在中国没有给你太多的生存市场。试问有多少企业拥有林级别的AD？事实上恐怕能用到子域的就算不错了。更多的公司只是使用Windows来做网站或内部FTP，导致很多Windows工程师成了Windows平台应用程序管理员，然后又衍生为公司网管，像什么装QQ之流的工作也属于这个范畴。我记得当初我就是因为这个才学会了VxVM/VVR for Windows和Sun iplanet Message Server的。
　　然而在虚拟化行业里，同样的尴尬正好调换了角色。企业只是刚刚步入虚拟化行业，还没有成形的规模。这时候架构师提供不了太多的帮助，相反遇到实际问题他们的羽毛理论只能是漂浮在空却难以落地。这时候没有实打实有经验的虚拟化工程师，那么项目经理就只有挨骂的份儿了。
　　如果真的需要架构师的建议，不如先去做好调研工作，鼓励内部致力从事虚拟化研究的员工去学习。然后花一点钱请一个真正的专家去做咨询，和你的员工一起针对这些成果进行良好的交流，而不是急着去三顾茅庐。这就好比给一个没有驾照的人配了一辆法拉利，结果那人还是天天骑自行车去上班。花了那么多钱却没什么用处，并不是法拉利不好，而是你太不会过日子，况且自行车也会有怨言的，大家可都看着呢，法拉利心里的滋味恐怕也不会好受。在初级阶段，与其花费大钱找外援还不如激励内部的员工去做实际的工作。

4．我的Team如何组队？
　　组织一个虚拟化团队就和打网游一样，是虚拟化架构师还是虚拟化工程师，我前面已经说得够多的了。接下来需要注意的是你还需要谁的帮助？
　　当然没有谁是全能的，尽管一个优秀的虚拟化工程师应该对网络、系统以及存储有多方面的了解，但是你也不能指望他一手遮天。看情况的需要，但通常更加专业的系统工程师是不可或缺的，尤其是桌面虚拟化。因为事实上架构不过是那么几种，但是难点在于AD的设计和系统模板的制作。做了这么多年的企业级服务器，AD和GPO可能已经烂熟于胸了，但你会哭笑不得的发现，居然要花一整天的时间去研究一个桌面助手或者国产浏览器，甚至是你从没听说过的软件，还没Support，这恐怕是最令人抓狂的了。这时候就要考验你的功力了，你不但要迅速学会一个软件的使用，还要考虑它是否支持多用户，是否能融入AD的应用，安装后的目录结构是否影响了GPO的变更等一系列的问题。如果你的模板中有太多这样的非主流，没有2-3个人协作，恐怕短时间内很难完成这种工作。那么这个系统制作的小团队成员必须都要具备以下的条件：大体相当的较高的微软理论技术，有较强的学习能力以及测试文档的撰写能力。首先共同制定一个合理的架构，然后按照客户要求安装相应的软件，分析问题，撰写测试报告，解决问题，通过测试，最后汇总Solution文档。
　　除此之外，还要考虑业务部门维护人员的能力，通常他们的水准不会太高，而且很多公司之前可能都没有成熟的AD域结构。正如我前面举的那个微软工程师的尴尬例子一样，更多公司当初需要和招募的不是工程师而是管理员。很多人是Unix出身或是Desktop Helper一类的网管。这种情况下使用应用虚拟化对他们来说是一个不小的打击。你可能需要程序员提供较为方便的定制化管理页面也说不定。还有你的团队最好有具备培训经验的人员参与其中以加强相关方面的增值服务。

5．AD的架构如何设计
　　刚才已经说了，桌面级虚拟化主要还是以微软为主，那么一个合格的架构设计师应该对AD架构的设计理解是到位的。然而不幸的是，我曾经见过很多MCSE亦或是号称有着多年虚拟化经验的专家对此理解竟然是如此的“纯真”，相关的设计在这里往往是粗暴的简单了事，甚至根本就是一片空白。
　　在这里我用一个实际案例和大家分享如何考虑AD架构的设计：
我的客户没有分支机构，实施虚拟化的部门现有员工1500人，初步上线300个虚拟化桌面，而且未来也不会考虑给管理层或者其他部门的使用。这样看来，教条的按照物理位置或组织机构划分都没有任何意义。那么在这种情况下，该如何去考虑AD架构的设计？
　　首先要注意的是，AD的设计和GPO的设计是一体的。如果你割裂的分析问题，那么肯定会走进死胡同。必须要承认一点，AD的设计在一定程度上是为GPO服务的。我们抛开PSO不说，GPO的最小实施单位应该是OU，OU的组织划分也在一定程度上决定了AD架构的组成。对不同类型的对象实施不同的GPO，应当按照这个原则进行OU的结构设计。现在我们的环境中没有分支机构，没有部门，没有职位级别划分，不会岗位调离，不会迁移工位，甚至在这个项目里都不需要太多的GPO设置(客户无法提出任何需求)，怎么办？
　　这里的关键点还是需要找到能够区分用户群的GPO设置。请注意，实施了虚拟化桌面后，原有的存储发生了变更，数据肯定不会存放在虚拟机文件当中。原因很简单，不管Veeam、Symantec等厂商的备份软件是否能够满足要求，从成本上来讲，把用户数据从虚拟机文件中剥离出来，直接放置到现有的企业存储上也是非常不错的想法。而且很多企业都有这样经验老到的存储工程师，把定期备份的任务交给他们是一件很简单的事情，对于文件级的数据恢复可以交付系统管理员来完成。这一切只需要使用文件夹重定向将用户数据转移到存储上即可。
　　这样思路就清晰了，因为别忘了我们还有900个人没有上线呢。一开始没有人会一股脑儿地提供足够的存储空间。那么很可能出现这样一种情况：当人员不断批量上线后，现有存储空间不足，某个批次的人员需要使用另外一个机头提供的存储空间。这时候你就需要重新定义一个OU了。
　　为了便于理解，我索性就按照工程期数划分了OU。这种OU划分方式直到今天看来还是比较合适的，至少那个项目中间历经了多次调整，却没有因为变更AD架构来找我的麻烦。

6．不容忽视的个人文件
　　做虚拟化可以将数据分为三类，第一种是虚拟机文件，第二种是个人配置数据，第三种是商业数据。
　　作为数据备份，商业数据自不必说，虚拟机文件本身没有备份的价值，最值得考虑的是个人配置数据(Profile)。尽管这不是一个好习惯，但我相信仍旧有99%的人会在桌面和我的文档中存放数据，而且他们还都是位于默认设置。尤其是很多应用程序，例如一些邮件的客户端都将邮件存储在用户的主目录中。如果你的用户使用POP3收取邮件，通常这个目录的尺寸是惊人的(反正我见过10几个GiB大小的收件箱)。这时候如果你用了虚拟化厂商提供的类似于漫游用户的功能，估计第一天上线你就会受不了了。原因很简单，所有人在早上9点上班的时候都出现了无法登录的情况，因为每个人都有几个GiB的邮件等着漫游传送，应用虚拟化更要命的是，为了保证负载均衡你肯定有多台服务器，今天是这台服务器，可明天就指不定是哪一台了，这种漫游很可能出现配置文件在各个服务器上不同步的情况，然后就是无尽的传输复制。试想你有多少带宽和IO吞吐能应付？
　　所以像邮件这种本来也属于商业数据的东西要么重定向，要么使用IMAP4，其实我个人是倾向于两者混用，当然你要考虑好客户端软件设置的问题。或者只用WEB方式，不过这个可能会影响业务模式，一般很难实现。
　　对于诸如收藏夹，桌面壁纸等，其实不必作重定向，保持漫游方式或者使用类似个人Profile快照即可，一来数据量比较小，二来也没有必要备份。理由很简单，你买台新机器也不可能要求人家将收藏夹和壁纸什么的都做好吧？这个让终端用户自己处理即可。

7．业务与技术的矛盾
　　请记住，专业做的是技术，大众用的是娱乐。你不能指望所有人都和你一样使用电脑，也许你不屑也不解他们使用电脑的方式，但是他们已经习惯了或者说业务的特点使得他们必须这样去操作。所以一定在测试前洗掉工程师的思想，换个头脑站在用户的角度去操作。

8．测试系统的重要性
　　桌面虚拟化在每次修改模板进行调整后，都需要重新生成快照，然后更新每一台虚拟桌面，这个过程相当耗费时间。如果可以的话，最好搭建小环境的物理测试系统，当测试系统通过后，然后再在生产环境上实施部署。

　　说了这么多，希望大家能理解一个问题：浮沙筑屋，早晚有倒塌的一天，摒弃浮躁，认真做事才是正解啊！

本文出自 “猫咪杀手” 博客，转载请与作者联系！