无论你是大企业还是小公司，下面这个分六部分的虚拟化案例调查探讨了采用服务器虚拟化时应当考虑的一些主要方面和部署方法。每个部分介绍了虚拟化过程的一个关键阶段，借助虚构的Fergenschmeir公司介绍了任何公司都应当注意的一些问题、潜在错误及实际结果――你不太可能在典型的白皮书或案例调查中看到这些内容。

    毫无疑问，服务器虚拟化已经在IT行业刮起了一场风暴。这项技术为显着减少停机时间、增强灵活性、大幅提高硬件利用效率提供了一种经济高效的方式。

    不过，中小型企业常常发现很难评估虚拟化技术是否适合自己；如果适合，又该如何利用较少的IT人员和有限资金来采用它。大公司拥有水平较高的IT人员，比较容易弄清楚这个问题，但仍面临一定难度。

    无论你是大企业还是小公司，下面这个分六部分的虚拟化案例调查探讨了采用服务器虚拟化时应当考虑的一些主要方面和部署方法。每个部分介绍了虚拟化过程的一个关键阶段，借助虚构的Fergenschmeir公司介绍了任何公司都应当注意的一些问题、潜在错误及实际结果――你不太可能在典型的白皮书或案例调查中看到这些内容。

    下面不妨跟随Fergenschmeir的新基础架构经理Eric Brown、其上司Brad Richter、高层管理班子以及Eric领导的IT团队，看看Fergenschmeir对服务器环境采用虚拟化的过程中，这家公司经历了哪些成功和失败。

    第一个阶段：确定理由

    在第一个阶段，IT团队探讨了部署服务器虚拟化的必要性。

    好几个方面促使Fergenschmeir考虑把服务器虚拟化部署到生产环境。2007年5月，基础架构经理Eric Brown刚聘用了夏季招来的实习生：Mike Beyer。Mike最初提出的其中一个问题是：“你们的服务器基础架构当中多少采用了虚拟化？”回答当然是没有。虽说软件开发团队一直在使用寥寥几个EMC VMware工作站和服务器来帮助开发过程，但他们之前没有考虑把虚拟化技术部署到生产环境。但是这个实习生提出的简单问题让Eric认真考虑起来。他还进行了一番研究。

    Eric先找自己的团队谈话。他询问了他们之前遇到的问题，看看虚拟化能不能解决这些问题。虚拟化显然有一些优点，比如虚拟访客服务器可灵活移动。另外再也用不着依赖特定的硬件；而且能够整合服务器、减少IT开销。

    一个月后出现了来自业务方面的实际动力。Fergenschmeir的CRM应用软件虽然未得到开发商的支持，却是业务关键型的；运行该应用软件的一台服务器出现了严重崩溃。谁也不知道如何重新安装应用软件，于是整整停机了四天，才让该应用软件恢复运行。虽然造成停机主要归咎于原来那家软件开发商倒闭了，但这次失败让整个IT部门饱受诟病，而Eric因祸得福，开始了在Fergenschmeir辉煌的职业生涯。

    最后促使虚拟化项目上马的却是Fergenschmeir的CEO Bob Tersitan喜欢看IT行业杂志的爱好。这种爱好的结果是，他经常发内容简短的邮件给Brad，可能会是这样“嗨，我刚看了介绍某个门户网站的文章。我们也做吧。下个月如何？我在船上，打我手机。”Brad通常会拖一拖，或者提交一些高得离谱的预算数字，那样Bob会把目光转移到更有成效的其他方面。这回，Bob在《InfoWorld》网站上看到了服务器虚拟化案例调查，于是发来邮件，要求实施服务器虚拟化，以解决Fergenschmeir长期遇到的问题。太好了！Eric已经完成了研究，现在又得到了高层的批准。这次失败因而成了一次机遇。

    第二个阶段：核查现状

    在第二个阶段，IT团队进行了一番试运行，看看VMware果真能不能胜任。

    Fergenschmeir的基础架构经理Eric Brown很清楚服务器虚拟化如何有助于改善灾难恢复和利用率问题，于是他被委以重任。

    但Eric有些担心，因为自己的团队在虚拟化方面几乎没什么实战经验。实习生Mike Beyer是Eric身边最合适的人选，但是他从来没有从头开始设计过新的虚拟化架构，只是偶尔管理过而已。

    Eric还遇到了员工的阻力。Eric的两名服务器管理员Ed Blum和Mary Edgerton之前用过VMware服务器和微软虚拟服务器，觉得它们的性能不怎么样。首席数据库管理员Paul Marcos表示，他不愿意把数据库服务器部署到虚拟平台上，因为他看过声称虚拟磁盘I/O速率很低的文章。

    Eric和首席技术官（CTO）Brad Richter早已向CEO Bob Tersitan保证一个月内会拿出方案，于是尽管面临重重障碍，他们还是上路了。他们先阅读了介绍其他公司如何构建虚拟化系统的各种资料。Eric让Mike使用VMware ESX平台的试用版构建一个测试平台，因为选择这种平台在IT博客圈似乎很流行。

    没过几天，Mike建好了一台ESX服务器，上面运行着几个测试虚拟机。大家马上发现，虚拟化平台对硬件的要求与普通服务器不一样。测试服务器上的4GB内存不够用，无法同时运行三四个访客服务器；两个板上网络接口提供的网络带宽也不足以满足更多虚拟服务器的要求。

    但是即使存在这些局限，他们部署的测试虚拟机还是运行稳定，性能大大高于Eric团队之前的预期。连原先持怀疑态度的Paul都惊叹于磁盘的吞吐速率之高。他得出结论，许多工作组应用软件可能非常适合虚拟化，尽管他对要不要让虚拟机运行任务关键型数据库服务器并无把握。

    测试完毕后，Brad和Eric都很有信心，觉得能够在几周内把方案交给Bob。现在他们要做关键的规划工作。

    第三个阶段：规划容量

    在第三个阶段，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主机，以便从容运行现有的应用软件，留出一定的增长空间，并且控制某个主机出现故障时的停机时间。

    第三个阶段：规划容量

    在第三个阶段，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主机，以便从容运行现有的应用软件，留出一定的增长空间，并且控制某个主机出现故障时的停机时间。

    第四个阶段：选择平台

    在第四个阶段，IT团队筛选了软件、硬件和网络，并且比较了成本。

    那家咨询公司分析服务器利用率以确定哪些应用软件可以在虚拟服务器上运行、哪些应用软件需要留在物理服务器上，Fergenschmeir的IT团队同时开始考虑在最终实施时使用哪一种硬件作为主机。

    ·虚拟化引擎

    很明显，他们选择的任何硬件都必须与之前测试的虚拟化软件：VMware ESX兼容，于是基础架构经理Eric Brown领导的团队开始核对VMware硬件兼容列表。但服务器管理员Mary Edgerton提出的一个简单问题打断了过程：“我们确信要使用VMware吗？”

    到已经完成的分析和规划阶段，还没有人认真考虑过这个问题。VMware家喻户晓，但市面上还有其他虚拟化平台。事后想想，Eric的团队一直在追求VMware，惟一的原因就是实习生Mike Beyer之前用过。确实有必要进行一番评估。

    从Eric的观点来看，四大得到支持的虚拟化平台可供选择：VMware Virtual Infrastructure（包括VMware ESX服务器）、Virtual Iron、XenSource和微软虚拟服务器。

    Eric不想采用微软的技术，因为他看到的文章以及另一名服务器管理员Ed Blum（他之前用过微软虚拟服务器）的意见表明，微软的技术无论成熟程度还是性能都不如VMware。由于担心XenSource的成熟程度，Eric也有所顾虑；业内盛传XenSource可能会被收购（后来确实被收购了），他想避免这种不确定因素。

    另一方面，Virtual Iron是另一种情况。Virtual Iron的成熟程度与VMware相差无几，但其成本只有后者的四分之一。这让Eric斟酌了一番，于是他与CTO Brad Richter详细谈论了各自的优缺点。

    最后，他们决定采用原先计划的VMware。这主要是由于更多的工程师接触过部署更广泛的VMware平台；而且相信到时也会有更多的第三方工具可以使用。另一个因素就是，CEO Bob Tersitan和CFO Craig Windham已经听说过VMware的大名。采用不同技术需要苦口婆心地解释及拿出理由――Eric和Brad都也不愿冒这个事关饭碗的险。

    ·服务器选择

    平台问题解决后，Eric拿到了最初容量规划分析结果，结果表明需要八九个双插座、四核ESX主机。考虑到这一点，IT小组把目光又转向了为改建的数据中心选择硬件平台。因为Fergenschmeir已经拥有许多戴尔和惠普的硬件，最初讨论的对象主要放在了这两种平台上。Eric的团队几乎每个人在使用这两种平台过程中遇到过可怕经历，所以他们不知道接下来该怎么办。大家的一致看法是，惠普设备质量比较好，而戴尔设备成本比较低。Eric倒觉得无所谓――两者都能与VMware的ESX服务器协同工作；而且他的团队熟悉这两个牌子。Ed和Mary这两名服务器管理员都喜欢惠普的管理软件，于是Eric对选择惠普更放心。

    Eric的队伍开始着手选择某款服务器之前，Bob再次表明了自己的作用：他给Brad发去了一封邮件：“请看一下《InfoWorld》杂志上的刀片系统评测文章。我们要顺应绿色活动这股潮流。采购节能刀片系统。我在船上，打我手机：Bob。”事实证明，Bob给出了另一个宝贵的建议，这是因为刀片服务器架构具有易于管理、能耗低、环保等优点。

    当然，这大大改变了硬件方面的讨论。现在，选择哪种存储类型事关重大，因为刀片架构一般在可以使用哪几种互联技术、哪几种组合方面要求比标准服务器来得严格。

    就存储而言，Eric再次不得不重新考虑人员的技能。他团队中没有人用过任何存储区域网（SAN），更不用说光纤通道了。于是，他需要一种成本低廉、易于配置、性能又很高的SAN技术。比较了众多产品后，反复核对ESX硬件兼容列表、比较价格后，Eric决定采用一对EqualLogic iSCSI阵列――SAS阵列和SATA阵列各一个，分别满足高性能数据和中等性能数据的要求。

    随后，这个选择要求采用这种刀片架构：每块刀片支持数量比较多的千兆以太网链接。这实际上排除了戴尔设备，把选择范围缩小到了惠普的c-Class架构和Sun的6048机架。惠普得到了批准，同样是由于Mary青睐惠普的管理软件。每块刀片将是双插座、四核服务器，配有24GB内存和6Gbps以太网端口。如果以后主机被内存容量所束缚，IT团队可以通过升级来添加每块刀片的内存容量，但这种配置似乎是一个不错的起步。

    ·网络选择

    要考虑的下一个问题是，Eric的团队需要为网络添加哪种设备。Fergenschmeir的网络核心包括一对比较旧的思科Catalyst 4503交换机，它们集合了来自网络柜的所有光纤，提供不了足够的铜线密度，以满足数据中心中所有服务器的要求。也肯定不足以为所有服务器充当双归宿（dual-home）以提供冗余性。之前有人添加了一只杂牌的千兆交换机以弥补不足，这只交换机显然要扔掉。

    比较了价格和规格说明表后，Eric决定采用两只Catalyst 3750E交换机，把两只仍有用的4503交换机移到了网络边缘。一对交换机将安装在光纤终结处附近的电信室，执行核心路由任务；另一对交换机将安装在大厅，负责为服务器集群进行交换。

    为了设法满足将来的要求，Eric决定选购可支持在这两只交换机之间10G链路的机型。这种交换机的成本最终与购买一只高度冗余的Catalyst 6500系列交换机相差无几，不过那样得保留从电信室拉到数据中心的大捆铜线，或者把光纤连线一直拉到数据中心。这两种方案都不可取。

    ·平台的总成本

    虚拟化软硬件预算总共高达30万美元左右，包括约11万美元的服务器硬件、4万美元的网络硬件、10万美元的存储硬件以及约5万美元的VMware许可证。

    这笔预算是从那家独立咨询公司的容量规划报告得出来的，报告表明这种服务器配置保守估计可以让虚拟服务器与物理服务器达到10：1的整合比率，这意味着8台物理服务器就能处理所需的72个应用服务器。加上一些故障切换和增长容量，Eric最多只要九个虚拟化主机和一块管理刀片。

    这种方案意味着，每个虚拟化服务器的成本约为4200美元，包括完全冗余的存储和核心网络基础架构，但不包括人力和软件许可成本。考虑到一台大众化服务器的成本平均一般在5000到6000美元之间，这似乎很划算。如果Eric考虑到这个事实：大众化服务器并不提供各种非应用特定的高可用性或者负荷平衡功能，闲置率可能高达90%以上，费用节省的幅度更是惊人。

    还没有意识到这一点，Eric和Brad的预算已获得了Bob的批准，采购单也传给厂商了。

    第五个阶段：部署虚拟化服务器

    在第五个阶段，IT团队经历了扩建和迁移等挑战。

    购买服务器虚拟化项目所需软硬件的采购单发出去一个月后，Fergenschmeir的IT部门真是忙得不可开交。

    这是因为服务器管理器Mary Edgerton向一家经销商订购了选择的惠普c-Class刀片，不是直接向惠普或增值经销商（VAR）购买、让对方预先装好。这样一来，她可以自己组装（她喜欢组装的乐趣），还能省钱。

    由于这个决定，120多只盒子送到了Fergenschmeir的门口。单单拆盒子就让Mary和实习生Mike Beyer忙乎了大半天。组装硬件并不是特别难；在头一周，他们组装好了刀片机架，并装到数据中心，然后与电工一起连上了新的线路。同时，另一名管理员Ed Blum赶了好几个晚班换掉核心网络交换机。

    没过多久，他们把VMware ESX服务器安装到了九块刀片上，把虚拟中心服务器（VirtualCenter Server）安装到了便于管理而留出的一块刀片上。

    ·突然遇到扩建难题

    就在这时，开始遇到了麻烦。在这之前，Mike在大学里使用VMware ESX方面积累的经验帮了大忙。他知道如何安装ESX服务器，也很了解一旦安装及启动、如何管理的基本知识。可是他没有见过大学导师如何配置网络堆栈，不知道ESX与SAN如何集成。

    试了几次，又接连几天在VMware网上论坛提了一些问题（他们后来认识到这些问题很愚蠢）后，Ed、Mary和Mike终于解决了问题，但他们其实不认为做法正确。网络和磁盘性能不如预料的那么好；而且时常因有些虚拟机而出现网络连接中断。三个人越来越担心自己处理不了。

    基础架构经理Eric Brown认识到要派团队成员另外进行培训，或者听听别人的意见，看看实施的系统是不是果真没问题。VMware班还有几个星期才开课，于是Eric请当初帮助容量规划的那家咨询公司来帮助扩建。

    虽然这是一笔不在计划中的大笔开支，但完全值得。这家咨询公司与Mary一起配置好了最初的几块刀片，帮助Ed把思科交换机与VMware相当复杂的虚拟网络堆栈顺利结合起来。事实证明，这种帮教过程非常重要。后来，Mary在VMware班听课时特别指出，如不是那家咨询公司，即使自己上了这门课，也无法独立完成全面的配置。虚拟化牵涉众多的不同方面：网络、服务器配置和存储配置，需要一名经验丰富的全能型人才，才能在小环境下成功实施。

    ·迁移道路上的障碍

    在开始部署约一个月后，Eric的团队进行全面了测试，他们准备开始迁移服务器。

    Larry之前相当熟悉VMware Converter，这个物理环境到虚拟环境的迁移工具是Virtual Infrastructure套件自带的。他用Converter把最初的几台服务器迁移到了虚拟环境。

    但不久出现了这个问题：Converter的速度和易用性是要付出代价的。从旧的物理服务器迁移至新的虚拟化刀片确实消除了Fergenschmier之前遇到的硬件方面的一些问题，但是多年来在应用软件安装、升级、卸载后积累的软件缺陷似乎更多了。有些服务器运行比较好，有些服务器的性能比在原来硬件上来得差。

    经过一番研究及测试后，结果发现，对不是最近构建的Windows服务器而言，最好从头开始构建虚拟机，重新安装应用软件，然后迁移数据，而不是完全把现有服务器上的东西全部迁移过去。

    明白这点后，迁移所用时间要比计划的长得多。当然，VMware的克隆和部署工具让Ed、Mary和Mike可以在四分钟内利用基本模板构建好一台干净的服务器，但这部分很简单。困难的部分在于，翻阅应用软件的说明文档，确定原先各部分是如何安装的、现在应该怎样安装。与试图弄清楚如何安装及配置VMware相比，三个人用在打电话咨询应用软件开发商的时间长多了。

    由于缺乏经验，另一个问题又出现了：虽然他们在项目规划期间按照VMware的兼容列表核对了硬件，但谁也没有想到要问应用软件开发商：他们是否支持虚拟化架构。在某些情况下，开发商根本不支持。

    在某些情况下，完全是软件公司的问题，他们不想负责对底层基础架构进行配置。IT团队理解这种担心，于是接受了开发商们的忠告：如果出现硬件引起的任何性能问题，他们要自己解决――或者至少得在非虚拟化服务器上重现这个问题。

    在另一些情况下，开发商们对虚拟化一无所知。有些支持合同假定：涉及的对象是VMware工作站或服务器，而不是像VMware ESX这些硬件上虚拟机管理程序产品。如果出现这种情况，就要让开发商派相对了解虚拟化的支持人员过来。

    但有一家公司断然拒绝了为虚拟机提供安装支持。Fergenschmier后来的办法是挂断电话，然后再打电话过去。这回他们没有提到“虚拟”，对方的技术人员过来帮助他们完成了安装和配置。

    这些应用软件开发商的犹豫、无知和断然拒绝支持虚拟化当然不会让Fergenschmeir的IT部门的任何人觉得很舒服，但他们还没有见过实际上归咎于虚拟化硬件的问题。

    第六个阶段：总结经验

    在第六个阶段，IT团队评估了服务器虚拟化项目的优点和教训。

    在Fergenschmeir的IT团队开始拆盒子后过了五个月，他们终于完成了服务器虚拟化部署。

    最后，确保VMware环境运行稳定、培训团队、全面测试环境以确保放心，总共只用了一个月半时间。另外用了三个月时间手动迁移每一个应用软件，同时仍为用户群保持能够合格的支持级别。

    项目快结束时，基础架构经理Eric Brown开始依赖外包提供商来加快完全工作，不过大部分重要工作是由他的团队完成的。

    迁移后的几个月里，Eric惊喜地发现服务器网络相当稳定。当然，出现过几个奇怪的VMware特有的软件缺陷，主要是管理方面，但他们在精简架构、迁移至虚拟环境之前根本没有遇到过问题。

    从头开始重新构建基础架构这项困难工作也让Eric的团队明白了应用软件基础架构是如何运作的。Eric要求把重新构建的每一步记下来，确保团队以后可以利用这些知识。这样一来，要是果真需要另一个根本的技术或架构变化，就熟门熟路了。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。