用ESX进行虚拟化的技巧

VMware Infrastructure 3 是业内第一个完整的基础架构虚拟化套件，在它的帮助下，无论是大企业还是同类小公司，都能够通过虚拟化技术来转变、管理和优化它们的 IT 系统基础架构。VMware Infrastructure 3 提供了全面的虚拟化、管理、资源优化、应用程序可用性和操作自动化等多种功能。VMware Infrastructure 3 包括以下几个产品：

Ÿ ESX Server

Ÿ VMFS

Ÿ Virtual SMP

Ÿ VirtualCenter

Ÿ VMotion

Ÿ DRS

Ÿ HA

Ÿ Consolidated Backup

本文旨在为不太了解 VMware Virtual Infrastructure 的系统管理员提供充分利用 VMware Infrastructure 主要功能来部署基础架构服务的建议。本文所针对的对象是对 VMware Infrastructure 缺乏了
解的系统管理员。文中的建议适用于小型或中型企业。文中的建议和实例说明了使用 VMware Infrastructure 平台可以完成的任务。

当一项具有突破性的新技术，例如 VMware Infrastructure，进入 IT 领域时，IT 从业人员所面临的最大挑战可能是学会如何以新的思维方式看待服务器和工作负载的管理。人们往往都不喜欢冒风险，因此，一旦在使用 Virtual Infrastructure 的过程中碰到某些困难或问题，他们便会换一种思维方式重新思考这些问题。要让 Virtual Infrastructure 发挥最大的益处，很大程度上取决于始终将虚拟化技术作为一项基础架构原则加以实施。使用虚拟基础架构中提供的工具来解决问题将有助于发挥虚拟基础架构的最大功用。然而很多时候，系统管理员都会过早地下结论，认为某个特定的服务器或应用程序无法被虚拟化。因此，很多的部署按其投资规模原本可以充分利用 VMware Infrastructure 的各种功能的，却并没有实现其最初的投资收益。

将通过介绍针对虚拟平台的新思维、计划和执行方法，帮助系统管理员轻松应对这一棘手的新技术。希望本文有助于读者理解虚拟工作负载，并提供了有关 VMware Infrastructure 使用的实用性提示和技巧。

服务器虚拟化是一种新的服务器管理模式。物理服务器通常是单个购买的，并且受一定预算款项的限制，必须要考虑是否物有所值。而虚拟服务器基本上是根据自身容量规划的需要大批买进的。这样一来，面对 IT 行业中各种日新月异的变化，您可以使用 ESX Server 平台上额外的容量，而不必在调研前还要为征得具体的预算批准而大费周折，从而为您创造了更多体验新解决方案的机会。借助这一解决方案，IT 人员可以更加充分地发挥自身的创造性，对尚未成熟的解决方案进行全面系统地测试和验证。

您可以使用虚拟机模板在数分钟之内部署一个服务器，这样，就能在向管理层提交详细的计划之前对产品进行低风险的验证。通常大中型企业的预算制定极其严格，迫使 IT 员工不得不提交一份最有可能获得财务批准的计划。这种情况阻碍 IT 员工的研发进程，不利于他们寻求新的解决方案。尽管这些解决方案行之有效且成本低廉，但相关人员必须访问用于测试的服务器，才能对其进行验证。如今，用户只要访问了虚拟基础架构，轻松地点击几下鼠标便可以获得这些服务器。无论是验证新的解决方案、进行培训和提高技能，还是创建一个世界级的虚拟实验室，虚拟化技术都将会改变整个 IT 行业的管理方式。如今的 IT 行业能够提供范围更广的服务，从而使广大系统管理员的聪明才智得以充分的发挥。

随着传统 IT 环境中物理服务器的不断增多，这对数据中心范围内的容量规划以及优化资源的管理提出了严峻的挑战。物理服务器将应用程序存储在随机存储器中，并尽可能的减少不同应用程序的 CPU 资源之间的交互。通过将包括 CPU 在内的所有硬件资源纳入池中，虚拟化技术将交互提升到了新的水平。这提供了有效利用硬件的新机会，同时也带来了新的调节风险。投资于虚拟基础架构是一项事关体系结构的决定。它表明您愿意尽可能地寻求与虚拟基础框架兼容的资源管理方法。为了维护所有的基础架构，您必须要改变，有时甚至需要牺牲单个组件以满足整体的利益和完整性。要想从虚拟基础架构投资中获得最大回报，系统管理员必须承认优化基础架构设计和进程的必要性并欣然采用，即使它们有时与物理服务器管理环境中为大家所普遍接受的常识相抵触。文中多处提供了有关这方面的实例。

愿意采用虚拟基础架构的组织最终决定最大限度地对服务进行虚拟化，并且仅在必要的情况下才部署物理服务器。现在，很多基础架构服务都是通过专用硬件工具、专用服务器或其他独立的解决方案提供的。然而若能通过一个通用的平台提供尽可能多的此类服务，将会减少维护环境所需的管理进程。通过虚拟平台提供大部分的 IT 服务将有助于形成统一的解决方案和策略，以便应对一些常见的问题，如备份、灾难恢复、业务连续性、升级管理、资源估算等。首先，应该消除对在虚拟平台上运行解决方案的偏见。学会倾向于采用既满足业务需要且又与虚拟平台相兼容的解决方案，这样做有助于您从这项技术中完全受益。

您在考虑基础架构服务的部署时，必须要清楚地了解物理工作负载和虚拟工作负载之间的一些根本性区别，这一点很重要。物理服务器环境下，工作负载存在于隔离的物理随机存储器中。当最大程度地利用这些随机存储器中的可用资源时，工作负载是优化的。这样就会鼓励每个应用程序占用尽可能多的 CPU、内存、磁盘和网络资源，因为已经假定其他的应用程序也会相应地存在于各自的随机存储器中。一个单 CPU 物理文件服务器的平均利用率达到 40%，就会认为它的资源利用率比一个双 CPU 服务器（每个 CPU 的平均利用率为 20% ）要高。这反映了在物理服务器置备环境中人们对于垂直工作负载的偏见是相当普遍的。在这里，“垂直”的含义是一个资源容器（如给定服务器或群集中的 CPU、磁盘和内存）的最大利用率。

虚拟基础架构的情况恰好相反。通常，大的工作负载需要在必要时“横向”分布在多个虚拟 CPU 中，从而最大限度地增强 VMware Infrastructure 平衡整个平台的能力。采用这种工作负载分布方式的原因在于虚拟化技术的核心。ESX Server 调度程序一直在扫描 ESX Server 主机上所有的可用物理 CPU，查找具有富余资源的 CPU， 以便供正在请求时间的额外虚拟 CPU 使用。在一个忙碌的 ESX Server 上，可以放置较小 CPU 支出块的位置要比对 CPU 需求较大的块多。较小的 CPU 需求可以较容易地添加到物理 CPU 中，而不会导致处在同一 CPU 上的其他虚拟机被重新调度到其他位置，同时其他虚拟机进行 CPU 循环的等待时间也不会比先前更长。试考虑如下情形：一个物理 CPU 服务于四个虚拟机，每个虚拟机均会向物理服务器请求其 20% 的时间。此时已分配的 CPU 可以为所有虚拟机提供所需要的循环，而且物理 CPU自身还会剩余 20% 的富余时间。若再向该 CPU 添加第五个虚拟机，则它还可以分配出 15% 的 CPU 时间，而且几乎不会对其他虚拟机造成任何影响。但如果添加的第五个虚拟机请求 35% 的 CPU 时间，则会导致该 CPU 过载至少 15%。这时，调度程序会决定是把五个虚拟机中的一个迁移到另外一个物理 CPU，还是迁移到一个忙碌的 ESX Server 主机，以便通过调度较少的 CPU 循环，在五个虚拟机间分配 15% 的过载。这可能会导致该 CPU 上的虚拟机性能降低。然而，VMware Infrastructure 完全能够以最少的 CPU 开销应对繁重的负载，它可以将工作负载分为较小的块，从而使调度程序以最灵活的方式保持平台的平衡性和响应能力。在一个将工作负载重新分配成较小块的实例中，可能会将一个非常忙碌的文件服务器分成两个或更多文件服务器，每一个文件服务器都针对不同的内容。

密集型 ESX Server 主机的优势

将这一原则进一步推广，ESX Server 安装的物理 CPU 数量越多，就越能为相互争用的工作负载提供最佳的服务。当可供调度程序搜寻空闲时间的 CPU 数目越多，则该调度程序不必重新分配虚拟机即可为特定工作负载寻找到可用空间的可能性就往往越大。因此，一般而言，购买两个四路 ESX Server许可证比购买四个双路服务器要划算。同理，两个八路服务器比四个四路服务器的调度灵活性更高。就成本而言可以很清楚地做出这样的决定，但是若考虑到虚拟工作负载的优化，还须关注以下因素：

• Ÿ创建较轻的工作负载，将尽可能将较大的 CPU 要求分成几个较小的块。
• 在最大数量的物理 CPU 之间分配工作负载。

这样一来，可以保证 ESX Server 调度程序以最大的灵活性快速而有效地为工作负载提供服务。

SMP 和 CPU 密集型 ESX Server 主机

在调度具有多个虚拟 CPU（VCPU）的虚拟机时，就可以显著地发现 ESX Server 主机上额外的 CPU 所产生的积极效果。目前已发布的 ESX Server 3.0 可以支持四路 SMP（symmetric multiprocessing，对称多处理）虚拟机。为了使调度程序为 SMP 虚拟机分配时间，必须同时为每个 VCPU 都找到可用的 CPU 资源。如果一个双 CPU 虚拟机的每个 VCPU 需要 40% 的时间，调度程序将尽量同时定位具有充足资源的两个物理 CPU。根据所分配的 CPU 份额，调度程序可以调度不具有充足富余资源的 CPU 上的虚拟机,只要这些 CPU 上的其他虚拟机可以取消优先级排序。囿于本文的论述重点不同，我们暂且假定所有的虚拟机都具有相同的份额。

调度所包含的数学问题

在双路物理 ESX Server 主机上调度双 VCPU 虚拟机时，只有一种调度虚拟机的分配方法。 在四路或八路物理 ESX Server 主机上对双 VCPU 虚拟机进行调度时，可通过以下数学组合公式计算可能的调度机会数：N!/（R!（N-R）!）。其中 N= ESX Server 主机上的物理 CPU 数；R= 被调度虚拟机上的 VCPU 数[1]。一个运行在四路 ESX Server 主机上的双 VCPU 虚拟机所具有的调度机会为：（4! /（2!（4-2）!），即（4*3*2 /（2*2））或 6。不太熟悉组合数学的读者请注意，X! 记作 X（X-1）（X-2）（X-3）....（X-（X-1））。例如：5! = 5*4*3*2*1。

按照这种计算方法，一个运行在八路 ESX Server 主机上的双 VCPU 虚拟机所具有的调度机会数为：（8! /（2!（8-2）!），即（40320 /（2*720）或 28。这是一个四路 ESX Server 主机所提供机会数的四倍多。四 vCPU 虚拟机更清楚地体现这一原则在四路物理 ESX Server 主机上调度一个四 vCPU 虚拟机时仅有一种可能性；在八 CPU ESX Server 主机上调度一个四 VCPU 虚拟机时所具有的可能性为（8! /（4!（8-4）!）或 70；而运行在十六路ESX Server 主机上的一个四 vCPU 虚拟机所具有的调度可能性为：（16! /（4!（16-4）!），即（20922789888000 /（24*479001600）或 1820。这意味着调度程序有 1820 种不同的方法在 ESX Server 主机上放置四 vCPU 工作负载。对于四路虚拟机而言，当物理 CPU 数乘以两倍（从 8 增加到 16）时，调度机会数可以增多 26 倍。在一个具有四倍物理处理器数的主机（十六路 ESX Server 主机）上运行的四路虚拟机所具有的调度机会，是一个具有四倍物理处理器数的主机（八路 ESX Server 主机）上运行的双路虚拟机所具有调度机会的六倍多。

这些示例向人们展示了 CPU 密集型 ESX Server 主机的无限递增的优点，在这些例子都采用了 ESX Server 3.0 四路 SMP 功能。CPU 密集型主机提供的调度搜索空间越大，就越有利于调度程序找到最适当的 CPU 组合，来立即服务于复杂的工作负载，而且对其他虚拟机产生的影响非常小。使用 CPU 密集型主机并在多个 vCPU 之间横向地分配虚拟工作负载，可以确保虚拟平台的最佳性能和利用率。

在发布 ESX Server 3.0 和 VMware Infrastructure 3 的同时，VMware 还推出了 VMware DRS（Distributed Resource Scheduler）。DRS 可以在聚合于逻辑资源池中的一系列硬件资源之间动态地分配和平衡计算功能。VMware DRS 持续地监视各个资源池的利用率，并且在虚拟机之间智能地分配可用资源。VMware DRS 可根据业务目标调整计算资源，同时确保硬件资源的灵活性和高利用率。如果某个 ESX Server 主机的 CPU、内存或磁盘活动出现了过载情况，指定的虚拟机会被迁移到可以更好处理负载的 ESX Server 主机上。这便是另外一种工具，可以在多个方面起到辅助作用，特别适用于较大的工作负载。未计划分离到多个 VCPU 之间的虚拟工作负载可以迁移到指定的“重负载”ESX Server 主机或主机组，通过这种方式来获得服务，而不必将其被分割成较轻的工作负载。这些 ESX Server 主机中的虚拟机与物理 CPU 之间的比率较低。

当工作负载从物理服务器迁移至虚拟平台时，系统管理员有责任确保为物理环境设计的工作负载能够在虚拟环境中正常运行。很多时候，人们在没有充分分析如何横向重新分配工作负载的情况下，就会得出某个应用程序无法被虚拟化的结论。如果不充分分析源服务器的限制条件，用于检查一个物理服务器是否可以迁移至虚拟机的工具可能会失去意义。如果物理源服务器具有较重的负载或需要较高的 CPU 负载，一旦转换，即要评估如何将源工作负载分成多个逻辑块，并在新配置中的虚拟平台之间进行分配。物理到虚拟（P2V）工具，例如 VMware P2V Assistant 应该用来尽量缩短将基础架构服务移至 VMware Infrastructure 时所需的时间。P2V 工具是一个快捷方便的方法，它可以避免重新构建服务器的很多手动操作。P2V 迁移之后，根据相同的性能预期或业务单元分组将基础架构虚拟机分配到不同的硬件资源组，即所说的资源池。只要系统管理员明白如何将工作负载分成较小的块并且充分利用新的功能和产品，如资源池、DRS 和 VirtualSMP，基础架构服务便可以完全迁移至 VMware Infrastructure。

虚拟机可以轻松地用来在网络上提供基本的 IP 和目录服务。提供 IP 服务，例如 DNS 和 DHCP，对于网络中的其他功能很重要。这些服务通常是较轻或中等程度的工作负载，应该将它们放在 ESX Server 主机上线时最先引导的虚拟机上。在服务器可操作之前启动依赖于 DNS 或 Active Directory 的虚拟机会导致很多问题。ESX Server 提供了一个计时器，用在一个虚拟机上线和ESX Server 启动（启动顺序中）下一个虚拟机之间。利用这一功能，可确保在启动其他虚拟机之前 IP 服务可以完全发挥作用。反过来也可以在关闭电源事件中应用这一原则。设置关闭顺序，以便能够在最后执行 IP 服务。

对于那些使用 Microsoft 中心网络的公司，应考虑设置两个虚拟机，每个都配置 DHCP、DNS 和 Active Directory。并确保每个 VLAN 中，DHCP 只在一个虚拟机上是活动的。理想情况下，提供 IP 服务的每个虚拟机应运行在不同的 ESX Server 主机上。如果一个 ESX Server 主机发生故障，Active Directory 和 DNS 服务仍会保持在线状态。对于最大规模为 500 名员工的公司来说，运行两个均配有 DHCP、DNS 和 Active Directory 的虚拟机，应该是足够的。

带来的高可用性

由于每个 VLAN 中只能有一个 DHCP 设备，如果启动了 DHCP 功能的虚拟机所在的 ESX Server 主机发生故障，将会导致网络中的 DHCP 不可用。为了应对这一问题和类似的情况，在 VMware Infrastructure 3 和 VirtualCenter 2 中均引入了 VMware HA。VMware HA 为在虚拟机中运行的应用程序提供了易于使用且极具成本效益的高可用性。无需配备专用的独立硬件，VMware HA 即可最大限度地减少宕机次数和 IT 服务中断次数。在此实例中，HA 会被用来自动重新启动虚拟机以便在另一正常运行的 ESX Server 主机上提供 DHCP。这样一来，可以最大限度地减少对 DHCP 服务的中断以及在 ESX Server 主机出现故障时您希望立即重新启动的其他 IP 服务的中断。

需要进行硬件维护时，请使用 VMware VMotion^TM 将正在运行的虚拟机移至其他服务器。通过 VMotion 可以在保持零宕机、服务连续可用性和事务完整性的情况下，将正在运行的虚拟机在不同物理服务器之间实现动态的迁移。使用 VMotion 将生产基础架构中的 Active Directory 虚拟机移至其他 ESX Server 安装中，确保 Active Directory 复制可以不受干扰而一直持续。类似地，如果是安装在不同的虚拟机中，DHCP 和 DNS 也可以进行动态迁移。保证 Active Directory 和 DNS 虚拟机之间的复制，可以降低 ESX Server 重新上线时出现异常情况的风险。维护完成之后，使用 VMotion 对负载重新进行合理的分配，并根据需要重复执行这一操作。

服务

在针对较大的设计时，可以将 Active Directory 工作负载与 DNS 和 DHCP 工作负载分离开来，从而保证每个工作负载都可以单独进行调整。在执行了许多驱动 Active Directory 策略的用户环境中，需要确保在 ESXTO 实用程序中看到的 ESX Server %Ready 时间低于 10。响应不充分的 Active Directory 虚拟机会减缓用户登录进程。VMware Infrastructure 3 中引入了资源池的概念。一个资源池即一组硬件资源，包括处理器、内存、磁盘和网络，VMware Infrastructure 将其聚合为一个统一的逻辑资源，可以按照需要分配给虚拟机。资源池将底层的同类硬件抽离出来，并为虚拟机提供统一的资源。在任意指定的时间点，资源池中的虚拟机并不知道自己运行在哪一特定的物理服务器上。因此，根据反映业务需求和优先级变化的预定义规则，服务器会自动将可用资源动态地分配给不同的虚拟机。在较大的 Active Directory 安装中，用户可以考虑将所有的 Active Directory 服务器放置在同一个资源池中，并通过一个资源池策略控制它们对 VMware Infrastructure 资源的访问。

中的时间同步问题

虚拟化在计时方面引入了一个新的问题。由于多个虚拟机分时共享主机的物理硬件，因此一个虚拟机无法确切复制物理机的计时操作。为了尽可能的减小和掩盖计时操作的差异，VMware 虚拟机采用了几种方法，但是存在差异有时仍会导致客户软件中的计时误差和其他问题。如果物理 CPU 上没有安排虚拟机运行，则客户操作系统时钟会暂停，从外部看来时钟便好像发生偏移。时间一久，这会导致需要与时钟紧密同步的 Active Directory 服务器出现问题。有关计时的最佳操作需要通过 NTP 协议设置 ESX Server 主机，使其与外部时间服务器实现同步。这样，各个 ESX Server 主机之间可以保持同步，从而确保了 VMotion 操作不会导致与 ESX Server 主机时钟保持同步的虚拟机突然出现时间中断接下来，务必选中在 VMTools 中的复选框，使客户操作系统时钟与底层的 ESX Server 时钟保持同步。这样可以保证任意的时间偏移都可以得到及时纠正。有关对这一重要问题的深入探讨，请参阅 VMware 白皮书《Timekeeping in Virtual Machines》。

虚拟环境中，文件服务器会带来特殊的调整风险。为了服务于不同的组群和业务功能，物理文件服务器经常会合并各种内容，与此同时，每个工作负载流在性能方面的要求也各不相同。一个具有高平均使用率的物理文件服务器最初可能会被认为并不适于进行虚拟化。这种情况下，行之有效的方法是将不同的工作负载区分开来并置于多个较小的文件服务器中。这样，ESX Server 调度程序便可以在更多数量的虚拟处理器间分配工作负载。

举例来说，如果一个公司要转换到虚拟基础架构，以期对不断增长的文件服务器需求进行适当的调整。他们的物理服务器中包含有成千上万个小文件，这些文件时常要被某个重要的业务应用程序搜索和访问。如果访问过程很缓慢，会导致该应用程序冻结用户应用程序屏幕。同一服务器上包含很多 Adobe PDF 或 Microsoft Office 格式的用户文件。这些文件所占有的空间更大，但用户的访问频率要稍低些。第三类数据流包括存在于同一文件服务器上“我的文档”中所有最终用户文件和重定向的桌面文件。最后，同一文件服务器上存在有差不多 600 GB 的扫描文档，但很少被用户访问。

该实例中，所有的数据最初会被迁移到单个虚拟机中。在经历了最初的低性能之后，虚拟机上的资源共享水平得到了很大的提高。而服务器的性能仍然很不理想。添加第二个虚拟 CPU 有点帮助，但服务器似乎看上去仍非常忙碌，以至于在 ESX Server 调度程序看来，该虚拟 CPU 很少是闲置的，整个 ESX Server 主机利用率都处在一种虚高水平。最终，公司将该文件服务器分离成了三个独立的单虚拟 CPU 文件服务器。所有的业务内容文件放置在一个服务器上（服务器 A）；用户的个人文档和桌面文档放置在另外一个服务器上（服务器 B）；客户文件和扫描归档文件放置在第三个服务器上（服务器 C）。

通过试验和 esxtop 实用程序的监视，公司认为只要 esxtop 中服务器 A 的“%Ready”衡量指标低于 5，他们的应用程序便能够良好的运行。资源共享水平得到了很大提高，“%Ready” 指标很低。服务器 B 中的文档是用户经常在 Microsoft Office 应用程序中用到的。实验表明：如果“%Ready”低于 10，Excel 和 Word 文档加载时间会少于 1 秒；如果“%Ready”高于 10，加载时间为 2-4 秒；“%Ready”高于 20，则加载时间为 6 秒。调整后，服务器 B 的文档加载时间大约为 1 秒；服务器 C 的调整力度稍小，文档加载时间范围在 2-4 秒之间。分别调整这些工作负载之后，公司的 ESX Server 主机利用率大幅降低，调度程序会在 esxtop 实用程序中正确地报告每个文件服务器的闲置时间。该实例中，每个工作负载根据不同业务的需要对进行了适当的调整，结果提高了整体的 ESX Server 主机性能，而且还提高了对最终用户的响应速度。

上承载打印服务

有些时候打印服务器的负载较高，从而造成系统繁忙，但是在大多数情况下，它们对性能的要求并不高。通常在用户走到网络打印机之前，打印任务就已经完成了。打印服务器只需获得较少的系统资源。可以在优先级较高的机器不需要大量系统资源的时候，将可用的资源分配给打印服务器。

正如我们可以把文件服务器划分为多个逻辑工作流，并放置于多个虚拟机之内，我们也可以将打印服务器划分为多个打印机群组，从而将 CPU 平均利用率降低到 25% 以下。虽然部署多台打印服务器需要一些时间，然而由此实现的单台虚拟机低负载却可以让整个 VMware Infrastructure 虚拟环境更加流畅地运行打印服务器会造成极高的网络通信量，对于那些对延迟较为敏感的应用程序（例如 Citrix），其网络性能可能会由于打印服务器造成的网络通信量而显著降低。如果您在同一个 ESX Server 主机上混合了这些类型的网络通信，请考虑将这两类不同的应用程序分别置于绑定到不同物理网卡的虚拟交换机上。对于那些对延迟较为敏感的应用程序，这将有助于缓解网络拥塞状况。

在迁移文件服务器时，应该将工作负载划分为多个逻辑群组，为每项工作负载创建一个或多个文件服务器，并分别进行调整。切忌仅仅考虑一台服务器是否可以迁移，我们更应该考虑的是如何为每项工作负载确定合理的性能配置。

在安全领域，虚拟基础架构也可以为企业创造价值。例如，规模较小的公司往往认为无需投资购置专用的代理服务器。而通过代理服务器，可以实现显著的性能提升，带宽占用率通常可以降低 25% 乃至更多，并且用户可以更快地浏览经常使用的网站。此外，代理服务器还可以阻止不受欢迎的网站并对 Internet 站点的使用情况进行追踪。

企业可以在虚拟机内部署一个开源产品，例如 IPCOP，从而获得一个快速、一体化，并且可以立刻收到成效的解决方案。IPCOP 以及其他类似的虚拟系统套装可以提供多个版本的 Squid Proxy，Squid Proxy 是成熟的高性能代理服务器代码，并且可以在一体化的框架内流畅运行。很多开源平台都可以随时转化为虚拟系统套装，利用虚拟系统套装可以在不添加独立设备的前提下，实现新的基础架构服务，而 IPCOP 仅仅是这样的实例之一。

IPCOP 还可用于在 VMware Infrastructure 中承载整个 DMZ。如果您计划在您的公司站点设置 Web 服务器、电子邮件服务器或其他接受 Internet 上计算机访问的服务器，那么您就应该创建一个 DMZ。DMZ（Demilitarized Zone，非军事化区）借用军事术语形象地说明了自身在网络中的作用。利用 DMZ 可以在与外部世界相连的网络服务器周围形成防火墙保护层。在部署 DMZ 的时候，我们会假设网络服务器可能会遭受潜在攻击。DMZ 防火墙只允许 DMZ 中的网络服务器与其他更加敏感的服务器进行预定义的网络通信，从而防止这些服务器被用作进入易受攻击的 LAN 环境的跳板。

IPCOP 可以通过 或 VMware 虚拟虚拟系统套装库[1]获得。最近，新泽西一家正在发展壮大的公司使用 IPCOP 承载一个具有 10 多台服务器的繁忙 DMZ，并为一个超过 300 人的用户群提供代理服务。IPCOP 可以在多种 Linux 操作系统上运行，并且只占用 256MB 内存和 2GB 磁盘空间。代理和 DMZ 工作负载很少会让 IPCOP 防火墙的资源占用率超出单个虚拟 CPU 的 15%。IPCOP 具有红色、绿色和橙色的网卡。红色的网卡表示连接到 Internet，绿色的网卡会获得一个 LAN 中的地址，而橙色的网卡则用于 DMZ 地址空间，橙色网卡的地址通常为 10.x.x.x（请见下图 1）。

虚拟交换机

要将 IPCOP 设置为 DMZ 防火墙，请在一个或多个 ESX Server 主机上创建两个虚拟交换机，分别命名为 DMZ-EXT 和 DMZ-INT。将 IPCOP 的红色网卡连接到 DMZ-EXT，将橙色网卡连接到 DMZ-INT。将绿色网卡连接到任何一个与 LAN 地址空间相关联的虚拟交换机。DMZ-INT 将作为服务于 DMZ 虚拟机的交换机。DMZ-EXT 将被用来发送数据包到 WAN 路由器或外围防火墙。内部服务器将通过绿色网卡与虚拟 DMZ 中的服务器进行通信，因而要在 LAN 路由器上添加一条路由以便发送数据到 DMZ。这条路由将指向 DMZ 防火墙绿色网卡的网关地址，以便到达 DMZ 子网。如果您已经拥有基于硬件的外围防火墙，请为红色网卡指定一个传输网络，专门用来在 DMZ-EXT 虚拟交换机与 WAN 路由器或外围防火墙的专用端口之间发送数据包。将每台 ESX Server 主机上与 DMZ-EXT 关联的物理网卡连接到一个公用的物理交换机或 VLAN区段，从而在逻辑上将 DMZ 通信与其他网络区段隔离开来。

尽管在只安装了一台 ESX Server 主机的情况下，DMZ-INT 虚拟交换机可以配置为一个孤立的交换机，但是，在虚拟平台具有多个 ESX Server 主机的情况下，最好将该虚拟交换机与每个 ESX Server 上的一个物理网卡相关联。VMotion 要求将服务器连接到与物理网卡相关联的虚拟交换机。具有多个网卡的虚拟机（例如 IPCOP）的 VMotion 要求将所有的网卡都与关联到物理网卡的虚拟交换机进行连接。如果配置得当，可以利用 VMotion 将所有相关的虚拟机乃至 DMZ 防火墙本身迁移到其他的 ESX Server 主机，而在此过程中 DMZ 安全性和代理服务都不会受到影响。如果只安装两台 ESX Server 主机服务于 DMZ，便可以直接用交叉线，连接两台 ESX Server 上与 DMZ-INT 交换机相关联的物理网卡。一个专用的袖珍型交换机或 VLAN 可以连接两台以上的 ESX Server 主机，这样 DMZ 中的元素便可以在一组 ESX Server 主机之间按需进行迁移。

与上游防火墙和路由器

在外围防火墙上创建一个或多个映射的 IP 地址，并将它们映射到分配给 IPCOP 红色网卡的 IP 地址。当 WAN 路由器处在一个或多个外围防火墙之后时，应让数据包从映射的 IP 地址发送到 WAN 路由器，并在 WAN 路由器中设定静态路由，从而通过 IPCOP 的红色网卡将数据包发送到 DMZ。一个比较好的操作方式是，在 WAN 路由器端口和每台与 DMZ-EXT 相关联的ESX Server物理网卡之间设置专用的交换机或 VLAN 用于数据传输。

的优势

创建虚拟 DMZ 带来的益处之一是，在维护过程中可以非常灵活地将所有 DMZ 组件，包括 DMZ 防火墙本身，移至其他的 ESX Server 主机。我们假设以 IPCOP 作为 DMZ 的防火墙，并且 DMZ 中有 10 台虚拟网络服务器。如下面图 1 所示，该示例中所有与 DMZ 相关的虚拟机，包括防火墙和 DMZ 成员服务器，都在一个名为 ESX01 的八路服务器上运行。为了在 ESX01 上进行 BIOS 升级而不影响服务，可以使用 VMotion 来将这些业务关键服务器移至其他 ESX Server 主机。同一网络中的主机 ESX02 和 ESX03 都是四路 ESX Server 主机，且每个主机仅可容纳大约六七个额外的虚拟机。通过虚拟 DMZ（如图 1 所示），IPCOP 防火墙和 DMZ 中的网络服务器可以移至 ESX02，其余的五个 DMZ 网络服务器则可以移至 ESX03。这样的虚拟机重组对于 Internet 上的用户来说是完全察觉不到的，它只需要几分钟时间，并且重组之后的安全级别与整个 DMZ 完全在 ESX01 上运行时相比，毫无二致。Internet 和 DMZ 成员服务器之间的两个火墙，会防止恶意利用防护墙平台已知弱点的入侵企图。

美国东北部一家处于发展阶段的抵押公司，已经非常成功地部署了这一类型的虚拟 DMZ。其灵活性让 DMZ 服务器实现了近两年的无故障运行。然而，对于物理 DMZ 来说，要实现相同的效果是十分困难的，并且需要付出更高的成本，因为在物理环境中，某些组件一旦离线，就必定会造成服务中断。此外，代理加速和 Internet 追踪功能帮助这家公司控制了带宽消耗，并且没有为专用物理服务器进行额外的支出。使用虚拟基础架构承载基础架构服务，将会以低廉的成本实现更高水平的灵活性和精细配置。

本文重点讨论了在 VMware Infrastructure 上部署和管理基础架构服务所需的全新思维方式。文中还提供了在一个或多个具有较轻负载的虚拟 CPU 上创建和分配工作负载的方法，以及有关组合虚拟 SMP 与单虚拟 CPU 工作负载的建议。应尽量保持较轻的工作负载，在多个适当规模的 ESX Server 主机之间对工作负载进行分配，并根据需要利用 DRS 平衡 ESX Server 主机之间的工作负载。应该对 ESX Server 主机之间的虚拟机冗余进行规划，并利用 VMware HA 确保服务的持续可用性。通过在 ESX Server 平台上承载基础架构服务，实现了更高水平的灵活性，更少的停机时间，以及对 IT 资源的统一管理。在通用的虚拟平台上承载基础架构服务和其他类型的服务器，实现了 IT 环境更低的复杂性和更高的可管理性，进而实现了整体上更佳的战略效益和经济效益。