服务器虚拟化项目实战六步曲

　　第三个阶段：规划容量

　　在第三个阶段，IT团队发现，服务器虚拟化规划并非易事。

　　测试了服务器虚拟化软件、了解是否满足性能要求后，Fergenschmeir的几位IT主管随后要进行详细的部署规划。基础架构经理Eric Brown和CTO Brad Richter需要解决规划阶段的两个基本问题：首先，他们希望服务器扮演哪些角色?其次，可以对哪些服务器进行虚拟化处理?

　　Brad先让他的团队给出一份清单，列出每个基于服务器的应用软件以及安装了应用软件的每台服务器。Eric由此画出了一份依赖关系树(dependency tree)，表明哪些服务器和应用系统依赖对方。

　　·评估服务器角色

　　Eric在画依赖关系树时清楚地发现，他们可不想为服务器分配与原来同样的应用软件。在数据中心的约60台服务器当中，只有4台直接负责约20个应用软件的连续运行。这主要是由于几台SQL数据库服务器被当作了"垃圾倾倒地"，许多不同应用软件的数据库都在上面，有时迫使某应用软件使用比它支持的更新或更旧的SQL版本。

　　此外还存在有风险的依赖关系。比方说，五个重要的应用软件都安装在一台服务器上。反过来，Eric和Brad也发现存在效率很低的现象，比如五台服务器都用于部门级文件共享，纯属多余。

　　Eric认为部署的虚拟化系统要避免这些缺陷，于是新架构必须消除不必要的冗余，同时把任务关键型应用软件分配到多台物理服务器上，尽量降低任何一台服务器出现故障的风险。这就意味着服务器数量从60台增至72台，服务器许可证的数量也相应增加。

　　·确定适合使用虚拟化的对象

　　由于现已确定了架构，Eric要弄清楚哪些服务器可以使用虚拟化、哪些保持原状。弄清楚这个问题比他起先预料的来得困难。

　　一个关键问题就是每台服务器的负荷，这个关键因素决定了需要多少个物理虚拟化主机。很明显，没有必要对正在充分利用硬件平台的应用负荷采用虚拟化。最初的测试表明，VMware虚拟机管理程序占用主机服务器约10%的原始性能，所以任何虚拟化主机的实际功能只有专用、非虚拟化物理主机的90%。利用率超过90%的任何应用软件都可能出现性能下降，也不适合服务器整合。

　　但是获得利用率方面的这些数字并非易事。虽然在Windows系统上使用Perfmon系统监视器，或者在Linux系统上使用SAR等工具，很容易显示某服务器在自己的小环境中有多繁忙，但要表明这个小环境与另一个小环境有怎样的关系就不那么容易了。

　　比方说，Thanatos(运行该公司医疗赔偿和福利管理软件的服务器)是时钟频率为2.8GHz的双插座、单核英特尔奔腾4系统，负荷平均只有4%。同时，Hermes(语音邮件系统)运行在时钟频率为2.2GHz的双插座、双核AMD皓龙275系统上，负荷平均为12%。这不但是两种完全不同的处理器架构，Hermes的处理器核心数量还是Thanatos的两倍。让问题更复杂的是，处理器的利用率不是惟一需要考虑的基本资源;在规划虚拟化基础架构时，内存、磁盘和网络的利用率显然同样重要。

　　Eric很快明白，这就是为什么市面上有那么多的软件用于进行容量评估。如果他只有一二十台服务器要考虑，可能比较简单，他只要打开Excel、自己分析即可。那样他可以逐步对负荷进行虚拟化处理，看看实际利用率如何。但他知道，如果拿不出确切的预算方案，CEO Bob Tersitan和CFO Craig Windham不会有兴趣。

　　于是经过一番研究后，Eric向Brad建议从外面请一家咨询公司来进行容量规划。Eric请当地的一个VMware合作伙伴进行评估，结果得知需要一两个月才能完成评估。咨询顾问表示，如果对服务器不进行至少一个月的监测，不可能得出服务器利用率方面完整而准确的分析结果。不然，分析结果将无法体现并非总是活动的流程(比如周末和月末的报告分析)的负荷。

　　这样的延迟完全有必要，但这确实意味着Eric和Brad无法赶在Bob给实施方案所定的最后期限之前。幸好，Craig觉得有必要让方案尽可能准确，于是他的支持最终让Bob对延迟表示了理解。

　　结果证明，这次延迟对Eric和 Bob有利无弊，因为还有其他许多规划任务根本没有完成，比如选择系统运行所需的软硬件。这段分析时期让他们有了喘息之机，可设法弄清楚自己不知道的方面。

　　一段时间后最初的容量规划分析终于完成后，结果表明Fergenschmeir的应用服务器利用率大多数在10%或以下，这样可以对预计部署的72台服务器进行大规模整合。合理的配置需要八九个双插座、四核ESX主机，以便从容运行现有的应用软件，留出一定的增长空间，并且控制某个主机出现故障时的停机时间。