超越整合：使用VMware搭建更好的开发环境

作者Mak King译者沙晓兰，审校: 曹云飞发布于2009年4月29日 上午12时31分

社区

Architecture

主题

虚拟化

标签

VMWare

Mak King的这篇文章描述了服务器整合之外的高级虚拟化应用，证实了虚拟化背后的技术和好处不仅仅局限于老生常谈的服务器整合。此外（绝对不是凑热闹），Mark的文章描述的方法显然是“绿色计算”。

相关厂商内容

6月杭州·第三届网络工程师侠客行大会开始免费报名

如果你在实现这个或者类似的开发环境时需要Mark的建议或者帮助，请联系info@ShiftMETHOD.com。

引言

近年在IT界工作的人肯定对虚拟化多少都有些了解。业界诸多关于虚拟技术多么无可比拟的宣传，让人开始不耐烦起来。众多粉丝甚至将其追捧为IT界过去十几年里的至宝。可以肯定，虚拟技术的应用节省了设备，节省了资金，基本上实现了它众所周知的功能。然而，虚拟技术的应用难道仅此而已?实现虚拟化以后究竟能得到怎样的好处？直到我所在的NYCE PaymentsNetwork，LCC——Metavante子公司——的开发部门实现虚拟化时，我才真正体会到虚拟在现实开发中的意义。我们开发的电子付费网络连接了国内8900多万银行卡、200多万台ATM机和出售点，消费者因此可以在任何时候任何地点安全、实时地访问自己的帐户。因此，系统的可用时间、依赖性和扩展性都是我们在实施基础构架时必须考虑的核心问题。

作者背景

在IT界工作的12年里，我觉得自己在应用新技术解决业务问题方面有相当丰富的经验。当然，一直尽量采用最新的技术来开发充满了挑战，应用虚拟化也不例外。尽管NYCE在2001年就安装了虚拟系统，但我个人在虚拟技术方面的经验仍然局限于在自己电脑上尝试安装几个不同的Linux系统，直到去年的一个目录服务整合项目，我才开始采用VMWareESX结合本地存储介质（基本上是以一个服务器和大量硬盘为基础提供VM存储，而不采用SAN）把3个陈旧的物理服务器整合到单个硬件设备上。这样的手法实在好极了！不仅节省了大量磁盘空间，还摆脱了旧设备，也不再需要很多数据线连接各个设备。在整合项目中采用VMware，证明了虚拟机在小范围内的高效。

项目概述

在目录服务整合项目之后，我把注意转移到了下一个VMware实现上——开发。

在开发环境中工作或者支持开发环境的工作都有很多挑战，这些挑战在产品数据中心很少遇到。首先，一起工作的都是一些对技术了如指掌的技术人员，所以如果环境上有什么不对劲，那就是真的不对劲了，不是什么小事。其次，开发中会修改很多地方，这些修改都应当对项目起推动作用。我工作的大部分内容就是支持开发人员，满足他们的开发环境的需求，包括维护研发实验室、一些产品设备和LAN。实验室当然是最难维护的一个。其中涉及到包括从PC类设备到workstation，再到连接了大量硬件的服务器等各种设备。这些设备都有不同的内存大小，处理能力及磁盘空间，还各自有各自的可避免电源功率波动的UPS。除此之外，它们所连接的硬件也都各不相同，驱动器兼容性的先后次序问题、BIOS升级问题，还有对应用兼容性提供支持的要求更是增加了保证开发环境的一致、可依赖和易管理的难度。另外，每次测试某个特定应用，我们往往会被要求采办新硬件（当然这些硬件往往跟什么都不匹配），或者是增补已有设备，但升级BIOS来支持新OS使得这些举措非常麻烦。

将一个原本建立在独立服务器设备基础上的实验室重新设计为采用VMwareInfrastructure和SAN的构架，这要求一个完全不同的思维方式。转移到这个新构架上来可以避免独立服务器的各种限制。实验室因此成为一个联合资源池，我们可以动态使用这些资源，可以通过对资源池定义一系列的规则来重新按需部署资源和大量设备。高度访问性和分布式资源调度器贯彻于整个设计过程，而不是单独的、空头支票似的特性。这样的解决方案学起来都相当容易！事实证明，前面提到的顾虑仍然阻碍了很多虚拟服务器的部署（我最近看到一个名为高级虚拟管理的视频，作者是VP and Service Director Data Center Strategies，BurtonGroup的RichardJones，他在这个视频中说虚拟服务器的实现，在环境中部署了高度访问性的案例不到10％）。大部分实现都局限于服务器整合，往往是一个物理服务器对应移植到一个虚拟服务器，在同一台机器上寄宿多个虚拟服务器。这样做无疑可以清理数据中心的老机器，但同时又引进了一个单点失败的隐患，一旦宿主机器当掉，会丢失所有虚拟服务器数据。

VMware的部署

在开启三个VMware主机服务器（预载ESX3.5）、SAN，插上fibercable之后，我们就可以开始部署了。安装、配置设备很直接，这中间我只用了一个APC Symmetra中央处理器。我发现fibercable比CAT 5线缆麻烦。设备运行起来以后，就可以开始配置环境了。

虚拟设施客户（Virtual Infrastructure Client -VIC）用来管理、配置VM环境。在安静明亮的小隔间里，用我台式机上的客户端工作，比起之前要在嗡嗡作响的实验室里呆上很多天来要舒适得多。可能你不相信，在嘈杂的实验室里最好的耳机也只能过滤掉风扇的噪声。VIC非常直观，能够构建集群、模板、服务器、虚拟交换机以及HA、DRS参数的配置。我在桌面上保留了几个VIC的快捷图标。我倾向于把3个VMware主机配置到同一个集群里，把所有资源放到根资源池中，而不是由应用或其它准则来分配。整个设施构架修改起来很轻松，不费吹灰之力。这样一来，我们可以随意尝试多种配置，直到找到最适合的为止。一旦确定新环境配置，就该动手把物理服务器移植到虚拟服务器上。我在更新现有环境的过程中结合了Converter（P2V）和服务器模板。当然，在移植到虚拟环境之前，我对所有机器都做了备份，总共占了满满一磁带，以防万一。这只是一些小绊脚石，尤其是在Windows 2000Server设备上使用Converter，但这些都不难处理。有时候还需要从头创建全新的VM，然后复制数据和应用，虽然有点麻烦，但好处是可以在创建和复制过程中清理服务器上的内容。

系统构架的进化

在实现VMware之前，我们研发实验室的部分构架如下图所示。显然，用来连接所有设备的线缆就需要很多管理，很多workstation也没有足够的存储介质。

我们在某些部分安装了VMware、把物理服务器转换到虚拟服务器（P2V），又在某些情况下用VM来替代物理服务器，之后，实验室现有构架如下图所示。

现在实验室有了更多的冗余能力，配置了高可用性，每个服务器的资源都不再是硬性绑定到物理硬件资源上。通过将三个主机服务器的资源组成池，虚拟机可以动态更新各自所需资源。另外，由于通过远程客户端来访问虚拟机，我甚至可以同时开着4个LCD显示屏监控。总体上，这一实现将实验室设备削减了85％。实验室也没有以前那么热，都不需要开什么空调。

高度可行性测试

在集群配置了高可用性之后，让我们来好看看它是不是真有传闻说的那么好。

整个环境中，一个集群下有3个主机（A、B、C），运行有12个VM。有11个VM通过VMotion迁移到了主机B和C,而主机A上单运行一个Windows 2003 Server。然后我做了件通常情况下极为糟糕的事情 —— 拔掉主机A的电源。按计划，VMotionHA应该可以检测到主机A当机了，然后在其它运行的主机上重启受影响的VM。这究竟行不行呢？事实证明，两分钟后，主机A上的VM在主机B上重启运行了。接着，我重复了实验，在主机A上运行Windows 2000Server。结果也一样，不到两分钟的时间，VM就在另一个主机上重启了。在确认了HA的这个功能之后，我才把主机A的电源重新插上，恢复集群原先的冗余，再通过VMotion把VM恢复到早先的主机上。测试结果更加巩固了我在开发环境中采用VMware的信心。

优点

实验室安装运行VMware已经有几个月了，VMware的优点逐渐明显起来。以下是比较明显的几点：

1. 实验室更容易管理。原先13台各不相同的机器，现在只要3台同样的机器，更为简单。KVMs、LCDs、小型中央处理器以及连接这些设备的线缆都不再需要，因此实验室空间得以节省了85％。
2. 增加了灵活度。比如，通过调节分配到VM上的资源数，我们可以决定特定的数据库查询所需要的最恰当的资源（包括RAM和处理器的数目）数量；我们还能重复测试任务，直到到达收益递减的转折点。在物理硬件上做这些简直就是噩梦，又耗硬件资源又花时间。
3. 提高了网络吞吐量。之前，每个设备的网络吞吐量都局限于它的nic端口数——大部分情况都只有一个端口。现在，每个ESX主机都有好几个nic，有多个端口，这些都将带宽扩大了两倍，而且在nic失败的情况下都能提供足够的带宽。这样的配置，还节省了我很多备份的时间。
4. HA、DRS和VMotion的使用极大地提高了冗余性和系统可用时间。

现状

NYCE的开发环境现在已经迁移到VMware，我很高兴，因为这个开发环境很灵活。我们可以很快部署资源服务器，本来需要好几个星期，现在就几分钟就能搞定。VMotion配合HA和DRS的使用，在保证环境全天候运行的前提下提高了可用时间和可信度。商务方面对此也很高兴，因为这一方案削减了现场维护和支持开销，从原先多台机器的使用减少到目前的三台。总之，这对我来说是个非常积极、有益的经验。我很期待在公司其他环境下使用VMware。

作者简介

Mak King是NYCE Payments Network,LLC的高级商业系统工程师，他期待着你的评价。他的Email地址是：akamak at gmail dot com。

申明

本文中的信息、观点仅属于作者，不代表NYCE Payments Network，LLC公司的研发、观点。该公司对本文内容不承担任何责任，作者对本文负全责。