VMware VI3虚拟化产品之第一次接触

在VMware公司发布VMware Infrastructure 3.0（VI3）后的一年左右时间里，发布VI3已被认为是虚拟化领域的重大事件。

VI3及其高级的虚拟机管理工具建立在可靠的VMware ESX 2.5虚拟机管理程序上，它让虚拟化成为了一股强大的IT主流。

虽然前不久升级至ESX Server 3.5和VirtualCenter 2.5的幅度比不上当初一下子升级至VI3，但确实增添了几项新特性，它们对任何虚拟化的实施肯定会很方便。

这些特性通常致力于减轻虚拟化基础架构带来的维护负担。

虚拟化技术有望从根本上简化服务器管理，但是与许多IT技术一样，它同样没有击中每一个目标。

VMware为这个套件添加了补丁管理（Update Manager）、虚拟机磁盘实时迁移（Storage VMotion）和容量规划向导程序（Guided Consolidation）等特性，解决了一些重大的难题。

这每一项新特性填补了各自的空缺；总的来说，表现相当出色。

许多IT部门肯定会在ESX 3.5和VirtualCenter 2.5上部署第一个VMware系统，根本不会使用更早版本，这肯定错不了。

但是同样，许多目前使用VI3的部门会尽快升级至新版本，以便利用新特性。

为此，我们的测试不但包括全新的ESX安装版本，还包括生产版本的升级版――因为这样可以最真实地测试任何软件版本。

升级之路从头开始构建VMware ESX主机再简单不过了。

刻录一张ISO光盘，插入到服务器上，用它来启动，点击几下"确认"，然后即可把该主机添加到VMware Infrastructure客户端。

配置好网络、存储和许可，就大功告成了。

如果你使用PXE网络启动VMware安装程序，甚至还可以简化步骤。

把主机从ESX 3.0升级至ESX 3.5其实比构建新主机还要简单，基本上不需要主机停止运行。

如果你现有的基础架构组建合理，这意味着生产环境的虚拟机其停机时间为零。

升级至整个基础架构的第一步就是升级VirtualCenter（VC）。

以前版本的VirtualCenter 使用微软SQL桌面引擎（MSDE）作为默认数据库，但VMware推荐使用功能完备的微软SQL Server或Oracle Database来处理数据库任务。

VC2.5弃用了原有的MSDE，而是捆绑了微软SQL Server 2005简易版。

这个数据库平台优于MSDE，但仍是为小规模实施而设计。

不过在许多生产VMware环境，只要这个平台就可以了――这比前一个版本是一大改进。

生产版本的VC2.0服务器升级至VC2.5其过程很顺利；简单的安装向导程序在后台负责升级。

升级完毕后，VC2.5服务器就会运行；使用新的VC2.5客户端，可以登录、查看生产主机群（production farm）――只是目前没有一个主机。

升级过程并没有把以前版本的数据库升级至新的安装版本，于是只好重新定义集群、主机，甚至还有位于主机群上的模板。

在小型环境下，这一步很简单。

在大型环境下，这可能是个大问题。

如果认真规划、研究一下升级过程，可以避免这个问题及升级过程中的其他许多问题；如果能仔细阅读软件发布说明，那更好。

但为了让升级更顺利，VMware本该做更多的工作。

我很希望看到简单的数据库迁移过程，并且在升级过程中检查有效性，尽量减少这方面的问题。

升级后，随后重新定义了群方面的一些参数，VC2.5可以在ESX 3.0上顺利运行。

下一步是升级主机。

想把ESX主机升级至ESX 3.5，最简单的方法就是从VMware网站下载ESX升级软件包。

目前签有支持协议的客户可以免费下载更新版；现有的3.0许可证可以在3.5主机上使用。

还有其他方法可以升级主机，但使用升级软件包是最简单的。

ESX 3.5升级软件包实际上是包含RPM软件包和一些支持脚本的压缩文档。

笔者使用SCP命令，把该压缩文档移到了中央群数据存储区（datastore）上的文件夹，开始通过该软件包更新每个主机。

这个过程比较费时间，不过还是相当简单。

先让每个主机处于“维护模式”下，迫使主机上的活动虚拟机转移至群中的其他主机上，然后在该主机上运行esxupdate命令，指定含有ESX 3.5升级软件包的目录。

过了几分钟，等众多RPM更新后，主机升级好了。

然后重启动主机，让它退出VirtualCenter中的“维护模式”。

然后它成了群中的一个普通主机，虚拟机开始根据群上的分布式资源调试器（DRS）规则，迁移到主机上。

对每个主机而言，整个过程耗时约15至20分钟，大部分时间用于等待主机进入“维护模式”，以及等待主机在重启后重新运行。

最后一个主机升级完毕后，整个群就升级至ESX 3.5，没有任何不良后果。

许多软件包都拥有可以升级而不是重新安装的功能。

大多数时候，管理员选择后一项功能。

原因在于，升级可能会带来裸机上重新安装时不会出现的问题。

只要你曾经从Windows 2000升级至Windows XP，就知道确实如此；不过拿ESX 3.5来说，升级程序似乎非常完整。

几周过后，根本没有出现任何问题。

创建虚拟服务器VMware管理员会马上注意到VirtualCenter 2.5带来的几个新变化。

首先就是烦人的启动画面（splash screen），现在启动画面丰富了VMware Infrastructure客户端上的大多数元素。

它们旨在提供对用户友好的宽大窗体，并链接至一些最常用的任务；不过对用过VI3的人来说，这没用。

幸好，这些画面是可以关闭的。

除了这个烦人的地方外，新的VirtualCenter在外观和功能上几乎与前一个版本一模一样，几个新按钮链接至新特性。

值得一提的是，它采用了新的插件架构，这是它与前一个版本大不相同的地方。

实施了插件架构后，VMware拓宽了VirtualCenter的功能范围，有望为把第三方工具集成到综合管理基础架构提供条件。

新的VC客户端顶部那个大大的“整合”（Consolidation）按钮是一个明显的起始点。

VMware 把容量规划器（Capacity Planner）代码集成到VC2.5中，这样管理员不必离开控制台，就可以评估对现有物理服务器进行虚拟化带来的影响。

结合VMware的物理到虚拟（P2V）转换工具，这种内置方法可以局部或全面地迁移现有的数据中心。

虽然许多第三方工具拥有P2V 和迁移规划功能，但把这些工具集成到VC2.5中对许多小型基础架构来说很方便。

这项特性需要Windows系统有管理员级证书，可以发现指定子网上的服务器，并长时间监控它们的利用率和性能。

在此之后，可以生成为如何选择适合虚拟化处理的物理服务器给予指导的报告，并且让用户可以更清楚地了解现有基础架构的总体利用率。

虽然数据太多可能是件坏事，但在做出这些决策时，尽可能详细地了解服务器的实际性能通常不是坏事。

这些新的整合工具会受到许多IT部门的欢迎。

更新管理器（Update Manager）由Shavlik公司的HFNetChkPro工具发展而来，它是VC2.5添加的另一个重要工具。

更新管理器不但提供了一个控制面板，用于临时或指定时间为ESX Server和一组虚拟机打上更新版和补丁；还可以使整个过程自动化，在打上补丁之前拍下虚拟机的快照，并将这些快照保留一段时间（时间可以设置）。

所以即使补丁扰乱了服务器基础架构，也可以迅速退回到快照，让系统恢复运行。

与所有补丁管理工具一样，更新管理器也容易出现试图在操作系统层面进行重要改动的任何自动化系统存在的异常行为。

有些补丁打不上，有些补丁打得上，但更新管理器的视窗和配置使这个缺点在一定程度上还可以忍受。

我们在有生之年不可能看到一款运行顺畅、真正精致的多平台补丁管理解决方案，但更新管理器很实用，可以经常使用，哪怕在处理Linux补丁时――Linux补丁应当要比Windows补丁简单，这就是为什么它没有得到应有的关注。

添加的另一项重要特性就是Storage VMotion.传统的VMotion要求主机服务器必须连接至相同的共享存储资源，无论是iSCSI、NFS还是光纤通道；虚拟机从一台物理主机服务器转移至另一台上时，存储资源仍然在同一个位置――转移的只有虚拟机的内存占用空间和网络连接。

如果使用Storage VMotion，各个部分都从一个主机转移至另一个主机，包括磁盘。

与传统的VMotion一样，这一步实时进行，无须重启动虚拟机。

Storage VMotion可能是个缓慢过程，如果存储系统速度不是非常快，更是如此，但能成功完成。

这项功能在许多情况下意义重大，比如存储迁移和升级期间。

它进一步减少了需要虚拟机重启的管理和维护任务，这最终有助于延长服务正常运行时间，进一步增添了虚拟机做得了、物理服务器却做不了的本领。

与Storage VMotion和DRS配合使用的是新的分布式电源管理（DPM）功能，该功能用于负载减轻后、关闭休眠主机。

这项出色的节能特性需要物理服务器支持局域网唤醒（WOL）功能尚有待改进VMware在这个组合式。

5版本中提供了一些出色的特性，但可以做得更好。

VI3方面还有许多问题未得到解决，尤其是让人一头雾水的错误报告和日志机制。

有一回，我试图建立裸设备映射（RDM），以便虚拟机可以直接联系iSCSI逻辑单元号（LUN），最后一步却老是出错，显示的“一般性错误”（General Error）语句一点也没有帮助。

最后发现，RDM映射的性质要求必须在VMFS文件系统上创建指针文件，指向映射至主机的iSCSI LUN.如果使用的数据存储区正好是NFS文件系统，那就无法创建RDM指针文件，因而也就无法使用。

如果看到错误消息附有详细的相关信息，那样极有帮助。

许多其他常见功能仍有待改进。

比方说，如果你为客户端的虚拟机改名，它会为虚拟机改名，但不会为与该虚拟机有关的文件夹和文件改名。

因而，你无法使用旧名来创建虚拟机。

另外，如果在你把“改名后的”虚拟机迁移至另一个数据存储区的时候突然断电，有些文件的名字改成了新的虚拟机名，有些却没有――尤其是快照。

这种情况下，迁移后出现在你面前的是无法工作的虚拟机。

这个似乎很简单的步骤会让人很沮丧，这毫无理由。

仅仅为虚拟机改名不应该带来那么多的麻烦。

网络方面还是显得过于复杂了，服务控制台、VMkernel接口、多个默认路由，等等。

要是这方面能进行某种整合就好了，对网络功能有更清楚的定义，对常用网络术语有更清楚的定义。

配置光纤通道网卡绑定需要浏览众多对话框，如同进了迷宫，很快让人厌烦，尽管ESX 3.5添加了对思科发现协议（CDP）的支持，大大方便了确认每个ESX主机上的连接交换机端口――前提是使用符合CDP标准的交换机，从而有助于解决一些问题。