总看到很多人在讨论关于vCenter应该安装在物理主机上还是虚拟机里面这个话题，那么，究竟两者有什么异同呢？各自有什么优势？
实际上，就VMware官方而言，无论是安装到物理机还是虚拟机，都是支持的。当然，无论这2种方案的任何一种，都必须保障vCenter的最小需求。
首先，我们先不讨论物理机好还是虚拟机好，我们先搞清楚vCenter究竟能干些什么？
1、VMware HA的初始话创建和简单配置管理需要vCenter支持；
2、VMware VMotion和Svmotion要求vCenter的全程支持；
3、VMware DRS/DPM需要vCenter全程支持；
4、模板化部署虚拟机需要vCenter全程支持；
当然，vCenter还需要Database的支持，如果Database宕机，那么，vCenter服务也将无法应用，在小环境里，建议直接把database和vCenter安装在一起，方便管理和Trouble Shooting。
搞清楚vCenter的作用之后，我们再来分析物理机做vCenter服务器和虚拟机做vCenter服务器的优劣：
物理机做为vCenter服务器：
1、在VI3.x里面，ESX服务器宕机之后License Server依然能工作，这就能够保障可以顺利开启ESX主机和VM；
2、相对而言，不太容易受到潜在的中断影响；
3、具有较强的可扩展性，因为它的性能是由物理服务器的硬件配置决定的；
4、需要1台专用物理服务器，这台服务器只能作为vCenter角色，不能和VCB代理服务器之类的一起使用；
5、只能采用传统的备份手段；
6、在做冗灾方面相对麻烦；
7、在商用解决方案中，可持续性解决方案较麻烦，而且需要多付Money。
虚拟机做为vCenter服务器：
1、vCenter服务器在虚拟机里面就相当于一个vApp了，不需要1台单独的物理服务器；
2、能够快速恢复，就算使用VMware HA重启vCenter服务器也是允许的；
3、能够和备份普通的VM一样备份这个vCenter服务器；
4、在商用解决方案中，可以Free、轻松的搞定vCenter的持续性；
5、甚至可以直接使用VMotion将vCenter服务器在ESX主机之间迁移；
6、在VI3.x时代，License Server和vCenter服务器通常安装在一起，14天宽限期之后，我们会有大麻烦（宽限期时没发现vCenter Error）；
7、同样不太容易受到中断影响；
8、如果设定不准确，可能导致vCenter和其它VM争用资源；
物理机和虚拟机安装vCenter的能否快速切换？
答案是肯定的，当然可以，我们只需要做一件事情即可：
1、备份好Database文件，只要我们备份好Database文件即可快速在物理机和虚拟机之间转换vCenter；
2、当然，如果vCenter服务器是物理机，那么，还可以通过P2V的方式抽取成为VM；
将vCenter服务器安装在虚拟机上还是物理服务器上一直存在着争议。下面，分别介绍支持二者的理由。
物理服务器
这本书是讲如何设计虚拟基础设施环境的，为什么要讨论物理服务器呢？因为虚拟基础设施环境中，一定数量的物理服务器是必需的：至少ESXi host需要物理服务器。但是为什么要考虑把vCenter安装在物理服务器上呢？理由如下：
鸡与蛋的问题 你肯定很熟悉鸡生蛋还是蛋生鸡这个矛盾问题。很多人都用这个来类比虚拟机形式的vCenter。
比如，vSphere环境规模很大：有100个ESXi host。由于某些原因，发生了严重的服务中断。例如：存储vCenter 虚拟机的LUN丢失了。由于各种各种的原因，你不会用几个小时为虚拟机创建备份。你可能认为这样做是没问题的，直到vSphere环境出了大问题才意识到问题的严重性。一个虚拟机由于CPU内存使用率过高而无法工作，你努力在这100个ESXi中的2000个虚拟机中找到它。这简直就是噩梦。如果很侥幸，检查到第三个ESXi host的时候你就定位到了出问题的那个虚拟机。然后想用vMotion来迁移这个虚拟机，但是，对不起，你没有vCenter来执行这个操作。
这只是vCenter搭建在虚拟机上可能发生的问题之一。此外，在VMware View或vCloud Director环境中，如果vCenter发生故障的话，你是无法部署新的虚拟机的。当然也不能执行任何操作来恢复环境，因为你没有vCenter可用。而没有vCenter可用的原因就是你的环境不能正常运行。由此可见，虚拟vCenter服务器故障会导致非常严重的问题。
职责分离 有些组织认为在这些职责问题没有讨论清楚前，不应该在vSphere环境中部署管理应用程序。这并不是说你不能以虚拟机的形式运行vCenter（可以在一个独立的host上运行它），但这样做会失去很多特性（这一点马上就可以看到）。
资源数量 vCenter服务器上的资源是比较密集的。如果把vCenter服务器5.0 和后端数据库服务器部署在同一个虚拟机上，那么就需要4个vCPU和8GB的内存。在vSphere 5.1中，如果你将vCenter SSO、vCenter inventory 服务、vCenter服务器、vCenter Web客户端和后端数据库服务器部署在同一个虚拟机上，那么也需要4个vCPU和8GB的内存的最低配置。实际上，所需最低配置可能更高。你想在单个虚拟机上使用这么多资源吗？
虚拟vCenter服务器
我们已经讨论过为什么在vSphere环境中部署物理的vCenter是必须要的，以及为什么这个选择比部署虚拟的vCenter会更好。现在，看看硬币的另一面：为什么选择用虚拟机形式的vCenter。注意：VMware已将虚拟机形式的vCenter加入到最佳实践中。然而，正如第1章所述，理解有些实践为什么会被列为最佳实践是很必要的。
鸡与蛋的问题 如果事先做好计划和准备，上个场景中发生的问题是可以缓解的。主要是发现问题并找到解决方案。我们继续分析上个场景中LUN的丢失问题。
vCenter是一个应用程序。该环境的问题在于vCenter使用的数据库。所以在上个方案中，如果你将vCenter数据库和vCenter服务器分离，将它们分别装在不同的物理服务器上，或者部署在不同的ESXi host上（如果它们是装在虚拟机上的话），那么是不会导致服务中断6小时的。
表3-4列出了解决这些问题的方法。
服务器整合 使用虚拟基础设施的主要目的就是将众多物理服务器整合为运行在ESXi host上的虚拟机。而现在所做的却与其背道而驰。在合理规划的前提下，我们没有理由不去虚拟化所有负载。而且这也是VMware官方的最佳实践。
快照 假设要给vCenter服务器打补丁、安装插件，或者修改配置文件.cfg。使用虚拟机形式的vCenter的最大优势就是其内置的快照功能：在做变更前，可以截取虚拟机快照。如果发生明显错误，就可以使用变更前截取的快照将虚拟机恢复到原始状态。
便携性 如果需要，可以将虚拟机拷贝到容灾站点。如果想创建测试环境，也能很轻松地复制vCenter 服务器。vCenter崩溃时，还可以保留vCenter的冷备份，然后就可以用冷备份在VMware的 player、server、workstation或单机版的ESXi 服务器上运行虚拟机了（当然，根据冷备份的备份时间可能会存在一定程度的数据丢失）。
冗余 只要vCenter是安装在应用了高可用功能的集群中的，那么vCenter就自动具备了弹性应对硬件故障的能力。为了让vCenter具备和物理硬件相同级别的冗余，还需要一个Microsoft集群（该集群只能使用SQL数据库）。vCenter是个不支持集群的应用程序。很多第三方工具都能为其提供冗余能力，但这些工具费用都很高。
现在，有了vSphere Fault Tolerance（FT），就可以为vCenter提供更高级别的冗余了。目前，vSphere FT不支持vCPU，因此也不能为vCenter提供CPU冗余。vSphere FT对vCPU的支持会在后续版本实现。
对多vCPU容错的支持
在VMworld2011和VMworld 2012中，VMware都展示和讨论了支持vCPU的vSphere FT新版本的研发。但是，VMware（撰写本书时）并未明确指出这个版本的发布日期。
自产自用 当你不愿意把某个关键服务器放到虚拟基础设施中，你如何像虚拟化管理员对客户所承诺的那样对整个平台、它的能力和特性有足够的信心？众所周知，根据正确的规划部署虚拟环境，虚拟化产品就会像物理服务器一样运转，同时你还将得到巨大的额外收益。所以，如果相信虚拟化产品，就应该自己先使用它。
