我们使用VMware vSphere来保护一些关键业务的服务器和应用程序，但是，对于vCenter的保护是否也要达到相同的级别呢？事实上，VMware官方开发出虚拟机形式的vCenter就是让管理员将vCenter放在虚拟化的环境中。为此，VMware已经开发出了许多工具来对此进行保护，如高可用（HA）、vCenter Server集群（Heartbeat）和分布式资源调度（DRS）。所有这些功能旨在保护虚拟的vCenter Server，防止其出现问题，但是这样做真的可靠吗？
虽然很多人不认可我的这种说法，但我还是宁愿将vCenter服务器以物理服务器的形式使用，而不是构建在其管理的VMware虚拟化架构之中。在你提出质疑前，让我们先来看一个例子。当我离开家时，我锁好门，但没有把房子的钥匙带在身上。相反，我把钥匙放在车库里，只要车库开门机正常，房子就很安全。这一切都运行良好，但是直到有一天，电源出现了问题，此时车库开门机不再工作，房子也进不去了。同样，将vCenter服务器以虚拟机的形式放在它管理的虚拟环境中，前提是VMware的HA、Heartbeat以及DRS能够处理所有出现的问题，但是你能保证它们永远都能为你解决掉所有的故障码？
几年前，在我任职的一家大型公司的数据中心经历了一次完整的数据中心停电事故。这次电力中断的范围涵盖了机房中的每个设备，包括交换机，存储区域网络（SAN），服务器和AC单元。停电的原因是由于一个人不小心碰到了一个安全电源分流器所导致。电力恢复后，ESX主机自动启动，并开始重新启动虚拟机（VM）。但是，此时的存储阵列并没有完全就位，所以HA不能正常启用，使集群处于不稳定状态。我们需要立刻进入vCenter来纠正不稳定的状态，并在存储就位后将主机和虚拟机联机。
在这个例子中，vCenter是独立于虚拟环境的一台物理服务器。进入这个数据中心，访问到这台服务器，我们可以在一个小时左右将VMware的虚拟环境上线。如果vCenter是在虚拟环境中的一台虚拟机，我们首先需要定位到它所在的存储LUN，然后尝试打开一个单独的主机，并手动将LUN挂载，这时才可以访问到中央管理控制台，修复HA后，将整个虚拟环境的其余部分上线。在实际情况中，定位到vCenter所在的LUN可能就需要一个小时，然后才能开始后续的恢复过程。这次事故发生在vSphere 4.1的平台上，当然，现在的版本可能已经做了改进以阻止这种类型的问题。不过，没有任何人愿意在自己管理的数据中心实地验证一下vSphere 5.5对这个问题的解决程度和有效性。
即使vSphere 5.5有了很多的改进，而且HA可以阻止这种管理的噩梦，但仍然需要考虑的问题是，vCenter服务器的虚拟机将如何重新启动。在环境恢复过程中，HA会重新启动vCenter服务器，但也会同时启动标记为“高”重新启动优先级的所有虚拟机。在一个大型环境中，这可能意味着数百台虚拟机。这种情况下，管理员所能做的就是等待vCenter的回应，因为没有办法知道启动的进度，以及启动中遇到的问题。当你无法查看进度以至于只能处于被动的等待状态，这时的心情将非常糟糕。
VMware发布了新的版本，并大力推广虚拟设备格式的vCenter服务器，这很可能使管理员最终将被迫使用一个虚拟的vCenter Server，并存放在它管理虚拟环境中，除非管理员需要将它放在它管理的虚拟环境以外。由于ESXi是免费的，而且没有内存限制。可以将vCenter安装在一台单独的拥有本地存储和备份的虚拟机主机上，或者使用vCenter Heartbeat以确保拥有本地硬件故障的保护。由于没有集群或HA，我们能够准确的定位vCenter所在的位置，有了一个明确的出发点，恢复虚拟数据中心将会非常快速和有效。在出现严重故障时，恢复流程中最重要的步骤就是找到一个明确的起始点。
