NetApp将多达1000台物理服务器整合至20个VMware ESX服务器

在 NetApp 位于印度班加罗尔的工程试验室，我们的运行目标是满足约 700 个开发工程师的计算和存储需求，这些工程师负责众多关键性 NetApp 开发工作，其中包括 WAFL®、NAS、SAN、存储管理、VTL、开放系统 SnapVault®（OSSV）和SnapDrive® for UNIX®。

截至 2008 年 8 月，我们已经部署约 1,000 台 x86 物理服务器，以满足这些及其它工程项目的各种需求，但需求仍以每月约 40 个服务器的速度不断增长，几乎每个月需要增加两个机架的计算服务器。如此增长的需求导致可用机架空间、电力、冷却等方面的问题。由于物理服务器程序比较缓慢而且不灵活，情况变得更加复杂，使我们越来越难以满足工程师的需求。

为此，我们启动了 COLD 项目（Consolidation and Optimization of Lab/Datacenter，即实验室/数据中心的整合与优化），以整合和虚拟化这些关键性工程应用资源。目前我们处于转型中期。项目完成后，我们预计将能够用 20 台 VMware® ESX 取代 50% 甚至更多原有的 1,000 台物理服务器，只有少数物理服务器（最后数目未定）将予以保留，主要用于那些需要物理硬件进行测试的应用。

我们的 VMware 服务器还可以满足未来的增长，极大地提高我们适应工程师不断变化的需求的能力

本文我们将讨论：
•整合和虚拟化的目的
•主要挑战
•设置和配置程序
•P2V 迁移
•转型的现状
•未来计划

整合和虚拟化

服务器和存储整合通过提高运行效率和有效性可以降低成本，虚拟化则通过提高自动化、可扩展性以及从一个单一平台提供多种功能或服务使服务器和存储技术的价值达到最大化。我们新的数据中心正在向虚拟化的模式迈进，该模式将使我们能够利用更加强大的技术满足不断变化的工程应用需求，满足业务增长或者降低的要求。虚拟化技术为我们的数据中心增加了价值，提高了灵活性、可扩展性、易管理性以及响应能力。

虚拟化使 IT 能够在更加经济的规模下运行，最大化利用现有资源，就算基础设施的增长速度非常快，也能够有效地被管理。我们在决定选用 VMware 配合 NetApp® 存储之前评估了多个虚拟化解决方案。最后我们选择 VMware，原因是它支持的客户运行系统的范围很广，这对我们这个项目非常关键。

最初的挑战

在起始阶段，要推进项目我们必须解决众多结构和技术方面的挑战。

有限的预算。首先，由于我们的预算是有限的，这个虚拟化项目必须以最少的设备开始。项目最初是以两台租用的服务器（已安装有 VMware ESX 服务器）和一个独立 NetApp FAS3050 存储系统开始。这使我们有足够的设备做一个概念验证（proof of concept，即POC）。这些租用的服务器通过加大的内存进行了升级，所以可以处理更多的虚拟机。

工程师们的担心。工程师们在开始的时候持怀疑态度。他们不相信一个虚拟的机器能够处理他们原来习惯使用的物理服务器所处理的工作。而且每个工程项目的需求都是独特的，所以更增加了这个问题的复杂性。然而，使用仅仅两台最初的虚拟服务器，我们成功地说服了大部分工程师，使项目得以进行下去。

网络集成。扫除了这个障碍后，我们开始商量如何在现有环境中集成一个虚拟服务器。工程应用实验室网络的设计旨在最小化第 2 层广播。接入层交换机配置了多重 VLAN，向上连接至使用第3层的核心骨干交换机。（这个网络架构相当于一个校园网，每个功能/院系使用一个单独的 VLAN。）

我们有两个选择：在每个 VLAN 上提供一个单独的 ESX 服务器，或修改网络布局。如果是前一种情况，资源将无法完全利用。我们会需要更多的 ESX 授权，而且管理也会更加困难。但是，第二种方案更加复杂，而且需要很长的宕机时间来完成。

在与我们的网络合作伙伴和工程客户进行大量的讨论后，我们最后决定采用包含有一个整合虚拟服务器群的解决方案，可以放置我们所有的 ESX 服务器、存储系统和网络闸，而且可连接至每个项目的 VLAN。

 
图1）虚拟服务器群和网络设置

虚拟服务器群设置和配置

在设计这个设置的时候，我们遵从 TR-3428：NetApp 和 VMware 虚拟基础架构 3：存储最佳实践。我们的虚拟基础架构已经拥有一个由8 个服务器组成的群和一个 NetApp FAS3050 集群，拥有 436 台虚拟机，支持 17 个工程团队。至今我们已经完成了 150 个物理至虚拟（P2V）转换和 100 个 GSX 至 ESX 迁移。以前我们曾在一些项目上采用 VMware GSX 很有限、分散地进行过虚拟化。基本上我们是每个物理服务器拥有 4-5 个虚拟机。

资源池通过 VMware Virtual Center 设置，以聚合和管理多组以组为单位的虚拟机。每个组的网络连接由 2 个 1GB 的网络端口提供，两个端口组合在一起以进行负载平衡和冗余。
我们的集群 FAS3050 配备有 4 个磁盘架，采用 300GB FC 驱动和多路径，以应对存储故障。该存储系统的网络端口采用 NetApp VIF，以处理冗余和进行负载均衡。

所有 ESX 数据存储都采用 NFS 在该存储系统中进行。我们选择 NFS 因为它性价比高，而且很容易配置和管理。光纤通道数据存储可能需要额外的硬件，如 FC 交换机、HBA、线缆，而我们由于预算有限所以可能无法满足。此外，采用 NFS 数据存储的性能与 FC 的性能是具有可比性的。

新的虚拟机配置有 NetApp rapid cloning utility version 1。该过程利用了NetApp FlexClone®，因此类似的虚拟机可以分享同一个存储，而无须浪费很多的空间重存储同一个操作系统的文件。你可以在最近的一篇 Tech OnTap 文章中了解更多该过程，该文章介绍了同样的过程，只不过针对的是 VMware 虚拟桌面。

从物理机迁移至虚拟机

由于工程应用团队要求现有服务器配置保持不变，当我们在将服务器从物理机迁移至虚拟机的过程中，我们面临保持主机命名、IP 地址、操作系统配置不变的挑战。

为了完成这些迁移，我们首先将每个组的数据网络扩展至虚拟服务器群。P2V 转换通过使用 VMware Virtual Center 实现。大部分迁移在周末或节假日进行，以降低宕机时间。定期检测新的虚拟机，确保性能。我们还与团队密切合作，以防止出现性能问题，并在需要的情况下分配更多的资源给虚拟机。

现状

我们定期监测虚拟机的增长和物理服务器的逐渐退役数量，并且用图表标注出来。我们计划在未来 6 至 9 个月内把物理服务器的数目降低至 500 台。同期虚拟机数量预计将增至 1,500。我们预计将所有 1,500 台虚拟机放置至 20 台 VMware ESX 服务器。我们现在 8 台服务器支持 450 个虚拟机，平均的 CPU 和内存使用率约为 30%，因此有很多余量支持更多的虚拟机。

 
图 2）转型进程

未来计划

我们对目前所取得的进展感到非常高兴，而且已经能够看到因为虚拟环境所带来的额外的机会：

•多平台支持。我们目前的环境仅仅包括基于 Intel® 的服务器。我们也希望能够支持采用 IBM 逻辑分区（LPAR）的PowerPC 平台和 AIX 操作环境虚拟，以及采用 Solaris™ container 的 SPARC。

•单一仪表板。我们目前的管理环境主要依赖 Virtual Center 检测和管理 VMware 服务器/虚拟机，以及 NetApp Operations Manager 检测和管理存储。现在我们正在积极采用 NetApp SANscreen，以使我们能够在单一的仪表板上既能看到服务器也能看到存储。

•业务连续性。在物理服务器环境中进行恢复是很难的。新的虚拟环境使我们能够提供更高水平的业务连续性。我们希望采用 SnapMirror 将所有虚拟机数据镜像至一个单一的 NetApp NearStore® 系统。这样一来，我们将能够迅速地从任何服务器或存储硬件错误中进行恢复，提供数据的异地副本进行站点恢复。

•按需分配服务器与存储。我们的最终梦想是创造一个自主服务的环境，实现工程师能够在线询问服务器和存储资源，而且资源无需管理员的参与即可被自动配置。

结论

虽然我们的转型只进行了一半，但我们已经看到虚拟环境所带来了大量好处：

•更快的配置。由于我们快速的增长，以前要走在需求前面或者满足预料之外的要求很困难。如果一个工程项目需要多个附加的服务器进行测试，可能需要长达 4 个星期去准备和配置所需要的硬件。现在我们几分钟就可以配置新的虚拟服务器。

•负载平衡。与配置相似，如果一台物理服务器负载过重，通常会是一个痛苦而且很长的重新配置过程。现在，我们定时检测 VM，查看性能，如果需要就尽快采用 VMware 工具迅速增补资源。如果某一个 VMware 服务器负载过高，我们可以使用 VMotion® 移动虚拟机，在最小的间断内重新平衡负载。

•弹性提高。我们现在可以更快地从服务器/操作系统错误中恢复。如果一个物理服务器有了硬件错误，这显然会很费时间。如果在 VM 上出现一个错误，我们可以很快地重启。如果一个虚拟服务器要出现错误，我们可以采用 VM 移植快速地在其它虚拟服务器上重启它的负载。

•减少宕机时间。VMware 和 NetApp 存储的维护特点使我们的维护几乎没有宕机时间，减少了对工程师的影响。

这些改进最直接的结果就是一个更加灵活、有弹性的开发和测试环境，最终可以提高工程师的生产力，缩短上市时间。认识到这个方法的优势后，其它 NetApp 工程应用实验室也正在采取相似的办法。

本文作者希望特别感谢整个 NetApp 班加罗尔工程应用支持团队的成员，是他们不知劳累的工作才使这个项目获得成功。工程支持 Jim Harrigan和 NFS 产品经理 Sunita Rao 提供了非常有价值的指导。