本节书摘来自华章出版社《VMware vSphere设计（原书第2版）》一 书中的第3章，第3.3节，作者：[美] 福布斯·格思里（Forbes Guthrie）斯科特·罗威（Scott Lowe）肯德里克·科尔曼（Kendrick Coleman），更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.3 管理层设计
本节主要讨论如何进行管理层设计。如何组织讨论内容呢？我们将采用第1章介绍的几个基本原则（可用性、可管理性、性能、可恢复性和安全性）作为组织信息的框架。首先从可用性开始。
3.3.1 可用性
开始管理层设计时，要考虑的第一个基本原则就是可用性。如第1章所述，可用性包含很多度量指标，例如正常运行时间，有时候还包括性能（如果应用程序性能太差以至于反应过慢，那这个服务还可用吗？）。
可以为vCenter服务器提供可用性的方法如下：
vSphere HA。
vCenter服务器心跳。
在讨论如何提供可用性之前，请先了解vCenter不可用指什么。表3-5列出了vCenter不可用时各功能的受影响情况。
VMware
从上表可以看出，大多数与vCenter相关的管理任务都无法工作或者只能部分运行正常。尽管很多管理功能都受到了影响，但并不是所有的虚拟机都受到了影响。
可用性可以分为两部分：vCenter应用程序和数据库。首先，介绍如何为vCenter提供可用性。
为vCenter提供可用性
首先保证可用性的组件就是vCenter。有多个选项可供选择；选择哪个主要取决于你的环境需要什么级别的冗余，以及确保vCenter实时可用对整个环境来说有多重要。
vSphere HA
将一个启用HA的集群中的虚拟机作为vCenter，已经在防止硬件故障方面提高了可用性。不管是基于Windows的还是vCSA的vCenter都是如此。如果ESXi host发生故障，短时间内另一个host上的vCenter就会启动并连接到数据库。这是个很好的应对host硬件故障的解决方案，并且应用后不会出现严重的服务中断。
本章开始曾提到过，考虑到vCenter通常需要多个vCPU，那么用vSphere FT来保护vCenter Server是存在一定缺陷的，因为vSphere FT只有一个vCPU。
如果vCenter Server是装在物理主机上的，那么就不需要考虑vSphere HA了，而是要选择vCenter Server Heartbeat。
vCenter Server Heartbeat
vCenter Server Heartbeat是VMware产品中比较新的一个。它的主要用户群是不能容忍丝毫vCenter Server服务中断的企业或组织。vCenter Server Heartbeat通过故障检测和故障切换流程为VMware vCenter Server提供自动故障切换和故障恢复能力，这样就不再需要手动进行故障恢复和切换工作了。有了vCenter Server Heartbeat，管理员可以制定维护周期并通过手动将服务切换到备用服务器来保证可用性。下载地址：www.vmware.com/products/vcenter-server-heartbeat/。
vCenter Server Heartbeat还可以保护vCenter 数据库（即使数据库与vCenter server不在同一个服务器上）。这个技术是基于Neverfail的一个产品（www.neverfailgroup.com）实现的，如图3-3所示。
vCenter Server还有个优点，就是可以跨WAN部署。如果有两个数据中心（比如：美国和欧洲），那么就可以分别在两个地方各自部署一个vCenter Server来提供更高级别的可用性。
部署vCenter Server Heartbeat需要考虑如下因素（前提条件和限制）：
vCenter Server Heartbeat不能安装在域控制器、全局目录服务器和DNS上。当然vCenter Server也不可以安装在域控制器上。
vCenter Server Heartbeat只能保护Microsoft SQL server。
除了vCenter的数据库外，不能在SQL Server上安装其他关键应用的数据库。
主服务器和辅服务器的系统日期、时间和时区设置必须相同。
两个地区（服务器）间的链路延迟不能低于T1连接的标准设置。
有如下三种配置方式：
虚拟对虚拟（Virtual to virtual，V2V）。
物理对虚拟（Physical to virtual，P2V）。如果采用此配置，那么：
两个系统要使用相似的CPU。
两个系统的内存大小要相同。
辅虚拟机在资源管理设置中要有足够高的优先级，以保证虚拟机的性能。
各虚拟网卡必须使用不同的虚拟交换机。
物理对物理（Physical to physical ，P2P）。 如果采用此配置，那么：
主服务器必须满足一定的硬件和软件需求。
辅服务器必须与主服务器相当，以保证具备同等的性能。
Advanced Configuration and Power Interface（ACPI）的符合性必须与主服务器一致。
本书非操作指导类书籍，因此不会介绍安装细节。
再次，有必要强调几点。首先，vCenter Server Heartbeat相对于vSphere产品套件的其他产品而言是个新产品。迄今为止，尚无应用实例。因为它主要针对不能容忍丝毫vCenter服务中断的极少客户。其次，vCenter Server Heartbeat的费用也比较高：每个licence至少12 000美元。最后，vCenter Server Heartbeat只支持基于Windows的vCenter server，不支持基于vCSA的。
根据社区活动判断（或者是由于缺乏相应的活动）http://communities.vmware.com/community/vmtn/mgmt/heartbeat，vCenter Server Heartbeat的应用并不广泛。或者，vCenter Server Heartbeat可能是太完美了，没有人提过关于它的问题。
下面介绍vSphere 管理层的另一个组件：数据库。
为SQL或Oracle数据库提供可用性
保护vCenter Server数据库的方法有很多。因为数据库是整个虚拟环境的核心，因此保护数据库是相当重要的。关于vSphere DRS、vSphere HA、权限等，基本上所有配置信息都保存在数据库中。
vSphere HA
我们可以用vSphere HA来保护vCenter Server，当然也可用用它来保护数据库服务器。但是，数据库服务器崩溃的概率比较大，如果在进行写操作的时候发生服务中断，那么数据就被破坏了，有可能导致整个数据库都不可用。这样，在启用vSphere HA的集群中部署单个数据库服务器可能会引起麻烦。
Microsoft 集群/Oracle 集群
微软和Oracle都有自己针对数据库的active-active和active-passive集群解决方案。令人高兴的是，Microsoft 集群和Oracle 集群可以组合使用。
你可以为vSphere创建高可用的数据库，VMware提供了针对这两个集群平台的最佳实践指南：
VMware上Oracle数据库最佳实践指南www.vmware.com/files/pdf/partners/oracle/Oracle_Databases_onVMware-_Best_Practices_Guide.pdf。
故障转移集群和Microsoft Cluster服务设置pubs.vmware.com/vSphere-50/topic/com.vmware.ICbase/PDF/vSphere-esxi-vcenter-server-50-mscs-guide.pdf。
从上述两个文档中，我们提取了一些进行应用程序虚拟化工作时需要考虑的一些因素和最佳实践：
将vSphere升级到最新版本 在某些情况下，将vSphere升级到最新版本可以提升10-20％的性能。
为vSphere创建一个优化的计算环境 根据ESXi host配置BIOS，推荐配置如下：
启用虚拟化技术以支持64位的guest操作系统。
启用内核加速模式（Turbo Mode）在各内核间均衡负载。
如果系统支持非统一内存架构（non-uniform memory architecture， NUMA），启用节点交叉（node interleaving）。
启用VT-x、AMD-V、EPT和RVI以支持基于硬件的虚拟化。
禁用增强型电源管理状态装换（C1E Halt State），以追求最大性能而不是节能。
禁用节能（power-saving）选项，以防止处理器空闲时会降低其处理速率。
启用支持超线程的CPU的超线程（HyperThreading，HT）特性。
启用网络唤醒（Wake On LAN），以支持分布式电源管理（Distributed Power Management）所需的特性。
将执行禁用（Execute Disable）设置为Yes，以支持vMotion and Distributed Resource Scheduler特性。
优化操作系统 卸载不必要的软件，仅开启必需的服务。
使用尽可能少的vCPU 管理员们犯的一个最大的错误就是为虚拟机分配过多的资源。当为一个仅需一个vCPU的虚拟机配置4个vCPU时，不光是虚拟机的性能会降低，还会严重影响在一个host上运行的其他虚拟机。
为Intel Core i7处理器启用HT 这是VMware针对Xeon 5500系列处理器提供的最新推荐配置。除此之外，至今VMware未提供其他关于启用HT的建议。
允许vSphere根据CPU和guest操作系统选择最佳的Virtual Machine Monitor 像数据库那样有大量的页表操作的负载可以从硬件辅助中获益。但是最好还是根据前面的推荐来设置BIOS。
使用VMXNET家族的超虚拟化网卡 VMXNET家族的超虚拟化网卡采用了最优化的网络接口，可以在虚拟机和物理网卡间以最小的开销传输信息。
为基于IP的存储iSCSI和NFS启用巨型帧（Jumbo Frames） 这样可以降低交换机的负载并提升一定的性能。注意，为确保该性能可以正常运行，必须端到端的启用（VMkernel， vSwitch，物理交换机和存储）。
为数据库负载创建专门的数据存储 如果应用程序或数据库的I/O需求很大，最好为其创建专门的数据存储。 创建专门的数据存储后，不同的应用程序就有了服务层面的保证。这和在物理存储中配置专门的LUN类似。
值得注意的是，数据存储是物理层的一个抽象，它只是物理层的逻辑表示而不是物理表示。因此，如果为了分离出某类特殊的I/O（不管是日志文件还是数据库文件），只为其创建了专门的数据存储，而没有分离出物理存储层，那么是无法实现期望的效果的。
确保VMFS已校准 磁盘校准内容将在第6章和第7章中详细阐述。在此，需要强调的是，如果不校准VMFS或NFS 数据存储，会对性能造成严重影响。
vCenter Server Heartbeat
如前文所述，vCenter Server Heartbeat只能为SQL 数据库提供冗余。而且为保证可用性，该硬件服务器中只能安装这一个数据库。
设计vSphere 管理层时，可用性无疑是个必须牢记心头的重要原则。下一节将介绍第二个原则：可管理性。
3.3.2 可管理性
如第1章所述，可管理型包括兼容性、易用性、互操作性和可扩展性。有些内容已经超出了我们的可控范围。例如，你无法控制管理层大部分内容的易用性，这是VMware自身的原因。如果有用户觉得vSphere Web客户端设计的不人性化，或者vCLI命令的语法不够智能，你也没有办法改变产品，或者解决这些抱怨。但是，下面这些方面则是你可以控制的：
兼容性和互操作性 如果vSphere环境要求vCenter Server能够与其他管理组件互操作，就需要通过第三方组件来搭建它们之间的互操作桥梁。例如Microsoft Systems Center Operations Manager（SCOM）就可以与vSphere产品集成。第三方的产品，比如Veeam Management Pack for VMware可以实现vCenter Server和SCOM之间的互操作性和兼容性。还有些类似的解决方案可以更好地实现vCenter Server与存储系统、网络和服务器硬件之间的互操作性和兼容性。这些额外的组件都是在设计管理层时需要考虑到的。
可扩展性 可管理性的另一个方面是可扩展性。如果管理层不能够在更具预期的增长环境中进行扩展，这个环境就会难以管理。可扩展性与性能密切相关，在3.3.3节中会详细介绍。
可扩展性可以用多种方式来解决，其中一个就是Linked Mode。Linked Mode是个解决方案，会影响到vSphere设计，因此需要更加重视。
Linked Mode
本节将详细介绍vCenter的Linked Mode，它是个可以为管理层设计提供可扩展性的潜在解决方案。VMware是在vSphere 4时推出这个特性的。它解决了大型环境中由于单纯的host和虚拟机数量巨大，而需要部署多个vCenter来管理基础设施的问题。
单个vCenter最多可管理1000个ESXi host，最多可管理的在线虚拟主机数量为10 000个（如果包括离线的，可管理15 000个）。对很多企业来说，这已经完全够用了，他们还一直梦想着自己的环境能够增长到需要这么多虚拟机。而对于其他一些企业来说，vCenter的这个管理能力就成了一个局限。
Linked Mode的到来将多个vCenter连在一起，这样基础设施中就可以有多达10个vCenter Server，3000个host和30 000个在线虚拟机（50 000个，如果包含离线虚拟机）。
你需要了解下许可警告信息。Linked Mode 只能应用于vCenter Server标准版。如果你购买的vSphere是Essentials版本或者 Foundation Bundle版本（其中不包含标准版vCenter授权许可），就无法将多个vCenter通过Linked Mode联系起来。
前提条件
要使用Linked Mode额外扩展管理层，需牢记如下需求。这些需求适用于所有要加入Linked Mode组的vCenter Server系统：
Linked Mode要正常工作必须有一个运行正常的DNS系统。每个Linked Mode组的成员都必须能够成功解析其他成员的域名。
Linked Mode组中的vCenter Server可以属于不同的域名，但这些域之间必须是双向信任关系。
当为Linked Mode 组添加新的vCenter Server时，安装程序必须由对本地vCenter主机和Linked Mode组的目标主机都具有管理员权限的域成员运行。
所有的vCenter Server都必须进行网络时间同步。vCenter Server安装程序会验证主机时间，以确保主机时间与网络时间的误差不会超过5分钟。在单个AD域下，时间同步都是自动实现的（注意，Linked Mode只适用于Windows版本的vCenter Server，自然会涉及活动目录AD）。
设计时需要考虑的因素
配置Linked Mode组之前，需要考虑如下内容：
每个vCenter Server的用户都可以看到自己有访问权限的vCenter Server。如果想屏蔽环境的一部分，不让一些用户看到，那么就得在该部分专门修改用户权限。
首次创建vCenter Linked Mode组时，第一个加入的vCenter Server必须是单机版的，因为你没有远程的vCenter主机可以添加。在这之后，其他vCenter Server就可以加入第一个vCenter Server，或者直接加入到Linked Mode组。
在将某个vCenter Server加入到不属于某个域的单机版vCenter时，必须先把单机版vCenter加入域并添加一个具有管理员权限的域用户。Linked mode不支持工作组环境，但是，反过来，你也不可能会在工作组中使用Linked Mode的。
Linked Mode组中的vCenter Server不需要用同一个域用户登录。
vCenter 服务可以在不同的用户下运行。默认情况下，是以主机的LocalSytem用户运行的。
可以在将VirtualCenter 2.5 升级到 vCenter Server 4.1的过程中，将其加入到Linked Mode组。升级完成则表示成功加入Linked Mode组。
Linked Mode组中的vCenter的版本必须相同。如果要加入Linked Mode组的vCenter既有5.0版本又有5.1版本，那么就必须先将vCenter 5.0升级到vCenter 5.1，这样才能创建Linked Mode组。
带着上述问题，继续研究Linked Mode组背后的工作原理。
Linked Mode组的工作原理
Linked Mode组是如何工作的呢？VMware是使用Active Directory Lightweight Directory Services （AD LDS，即以前的 Active Directory Application Mode（ADAM））来实现Linked Mode组的。
启用目录服务的应用程序的数据是存储在AD LDS中的，而不是组织的AD数据库中。 AD LDS可以和AD DS一起使用。你可以把安全账户保存在中央位置（即AD DS中），把应用程序配置信息和目录数据存储在另一个位置（即AD LDS中）。使用AD LDS 可以降低AD拷贝相关的开销，你不需要为了支持某个应用而扩展AD架构，还可以划分目录机构，这样就只需在需要支持启用目录服务应用的服务器上部署AD LDS就可以了。
Linked Mode就像一个AD应用。将ldp.exe连接到vCenter Server的389端口（如果默认端口没有修改的话），就可以看到Linked Mode 的内部信息，如图3-4所示。
图3-4 用LDP查看vCenter LDS信息
用Active Directory Services Interfaces （ADSI） Edit来查看vCenter LDS的所有属性会更简单些。连接到vCenter Server，使用“DC=virtualcenter, DC=vmware, DC=int”命名上下文就可以看到如图3-5和图3-6所示信息。
图3-5 用ADSI Edit 连接到vCenter LDS
图3-6 在ADSI Edit中查看不同的vCenter LDS命名上下文
你还可以连接到如下三个命令上下文：
DC=virtualcenter，DC=vmware，DC=int
CN=Schema，CN=Configuration，CN={382444B2-7267-4593-9735-42AE0E2C4530} （每个vCenter的GUID都是唯一的）。
CN=Configuration，CN={382444B2-7267-4593-9735-42AE0E2C4530}。
我们有必要熟悉AD LDS的架构和每个LSD的配置信息。目前还没有文档来记录它们，但熟悉这些内容总有一天会派上用场的。
Linked Mode中vCenter的角色
将vCenter Server加入到Linked Mode组时，需要考虑几个关于角色的问题：
每个vCenter Server的角色都会被拷贝到改Linked Mode组中的其他成员vCenter Server上。
如果每个vCenter Server的角色名称都不同，那么它们的角色清单就会被组合成一个单独的共有清单。例如：如果vCenter Server 1的角色，名为ESX_Admins，vCenter server 2的角色名为Admin_ESX，那么当二者加入到Linked Mode组后，都会具有两个角色ESX_Admins和Admin_ESX。
如果两个vCenter Server的角色名相同，且对每个vCenter Server具有相同的访问权限，那么加入Linked Mode组后这两个角色就会合并为一个角色。如果这样个角色对vCenter Server具有不同的访问权限，那么则会产生冲突，必须修改其中一个角色名，可以通过自动或手动两种方式来修改：
如果选择自动调整角色名，将vCenter Server加入Linked 组时，则会将角色名改为 ，其中表示vCenter Server的主机名，而表示原来的角色名。
如果选择手动修改文件名，就不得不通过vSphere客户端连接到其中一个vCenter，修改完角色名之后再继续进行加入Linked Mode组的流程。
将vCenter Server从Linked Mode组中移除后，vCenter Server还会保留原有的角色。
Linked Mode组可以提供更好的可扩展性并聚合来自多个vCenter Server的信息，同时也提高了大型vSphere 环境的可管理性。其实，在vSphere 5.1之前，通过vSphere客户端同时查看多个vCenter Server信息的唯一方法就是使用Linked Mode。
vSphere 5.1发布后，特别是vCenter Server架构方面调整，VMware将vCenter Inventroy Service分离出来作为一个单独的组件来为多个vCenter Server服务。引入新的vSphere Web客户端后，在vSphere 5.1的环境中，还可以使用下一代Web客户端来收集多个vCenter Server的信息，而不必使用Linked Mode组。
下面继续讲解设计的第三个基本原则：性能。
3.3.3 性能
一直以来，性能的很多方面归根结底都是如何有效调整各个组件。所以，在设计管理层考虑性能原则时，首先要分析的就是如何合理调整各个组件。下面将详细阐述这个问题：
调整vCenter Server
调整vCenter Server时，需要考虑如下要素：
操作系统。
数据库的位置。
被管理对象的数量。
VUM。
下面，逐个分析各个要素。
操作系统
如3.2.4节所述，vCenter Server （如果你使用的是基于Windows的版本的话）必须安装在64位的Windows操作系统上。为了避免潜在的内存限制，推荐使用WIndows Server 2008 R2。
下面回顾VMware推荐这个的原因。32位的Windows操作系统有一个限制，即只支持4GB内存。过去，很多vCenter Server都安装在企业版Windows 操作系统上来避免32位操作系统的这个缺陷。有了WIndows Server 2008 R2标准授权许可，其内存限制为32GB，这已完全能够满足大多数vCenter的需求。此外，Windows 操作系统和SQL server的更高版本许可都比标准版贵很多。
数据库的位置
如3.2.3节所述，vCenter Server的数据库（以及相关组件，如vSphere Upgrade Manager）对vCenter Server的资源分配具有显著影响。本节将介绍Microsoft SQL Server的推荐配置。例如：4GB内存、2.0GHZ或以上的CPU。当把数据库的这些需求和分析被管理对象得到的需求放在一起时，就能看出数据库的位置有多重要了。如果将数据库和vCenter Server安装在同一个主机上，那么请确保已为该主机分配足够的资源。为了性能最大化，还是建议你将数据库安装到一个独立的主机上。
被管理对象数
VMware的vCenter安装文档中提供了最佳性能推荐配置，如表3-6所示：
表3-6 最佳性能推荐配置
CUP个数 内存大小（GB） 硬盘大小（GB）
最多50个host和250个在线虚拟机 2 4 3
最多200个host和2000个在线虚拟机 4 4 3
最多300个host和3000个在线虚拟机 4 8 3
可以看出，vCenter 服务器的配置取决于部署规模的大小，最大配置为4个CPU和8GB内存。
Update Manager
你会将vCenter Server作为VUM Server吗?这样做为什么重要?
从资源角度看（CPU和内存），如果不在vCenter Server上安装SQL Server，那么就不需要配置额外的资源。你需要的只是硬盘空间。VMware提供了一个可以用来辅助调整vCenter的工具：VMware vCenter Update Manager Sizing Estimator，下载地址：www.vmware.com/support/vSphere4/doc/vsp_vum_41_sizing_estimator.xls。
撰写本书时，此处列出的VUM 4.1文档是当时最新的版本，而且适用于更新的VUM版本。注意：vSphere各个版本的Configuration Maximums文档中也包含VUM补丁管理相关指导内容。
vCenter Update Manager Sizing Estimator是个Excel电子表格，需要提供如下环境信息：
要打补丁的Host版本（3.0x/3.5x/4.x）。
同时升级的数量。
host的数量。
虚拟机的数量。
操作系统区域。
服务包级别。
host、虚拟机和VMware工具的扫描频率。
输入上述信息后，从vCenter Update Manager Sizing Estimator中获取的结果如表3-7所示。
表3-7 vCenter Update Manager Sizing Estimator输出结果
资源 最初使用资源（MB） 预计每月使用资源
中位数 20％ –20％
数据库空间使用资源 150 133 160 107
硬盘使用资源-补丁内容 50 13 100 15 720 10 480
VUM所需的最大资源就是硬盘空间。由于需要下载所有补丁，所以所需硬盘空间会根据要下载的软件版本（ESX版本或不同的操作系统服务包）的增加而不断增长。
建议你不要将补丁库放在安装VUM时提示的默认安装位置（C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Data\）。大多数管理员在安装VUM时都没有注意到这个问题，然后经过一段时间后，vCenter Server就开始出现C盘空间不足的提醒，这时才想知道为什么。所以做好是将补丁库放在一个独立分区的指定目录下，原因如下：
备份 通常不需要备份已经下载的补丁，因为补丁内容基本不会变化，而且需要的话下载也很方便。
系统驱动器空间不足 如果放在默认位置，很容易使系统盘空间占满。
除了调整vCenter Server外，VUM还可以用来调整数据库，下节将介绍此部分内容。
用VUM调整vCenter 数据库
如果遵从前文的简介，没有将数据库和vCenter安装在同一个服务器上，那么下一步要计划的就是调整数据库。在介绍如何调整数据库之前，先回顾vCenter 数据库的作用。
数据可是整个虚拟基础设施结构和逻辑的中央存储：资源池、vCenter中的访问权限、告警、阈值、集群结构和分布式资源调度，当然还有统计。虚拟环境中所有对象和计数器的统计信息都保存在这个数据库中，包括CPU、内存、硬盘、网络和服务时间。且每一类都有自己的计数器。
VMware还为Microsoft SQL Server提供了一个工具：vCenter Server 4.x Database Sizing Calculator，下载地址：www.vmware.com/support/vSphere4/doc/vsp_4x_db_calculator.xls （这是撰写本书时的最新版本）。
这个工具和前文介绍的VUM工具类似。但是，与前者相比，除了VUM工具所需参数外，它需要更多的参数：
每个Host的网卡数。
每个虚拟机的网卡数。
每个host的数据存储数。
每个虚拟机的VMDK数。
物理CPU数。
虚拟CPU数。
最重要的是，你打算将各个级别的统计信息保存多久。可以在如图3-7所示的vCenter界面中配置。
每个周期的统计信息级别越高，数据库就越庞大。VMware的报告“VMware vCenter 4.0 Database Performance for Microsoft SQL Server 2008”中提供了关于统计信息保留时间的推荐配置，如表3-8所示。
图3-7 vCenter统计信息的配置严重影响数据库的大小
表3-8 VMware提供的Microsoft SQL Server 2008 数据库性能配置
统计周期 统计界别
过去一天 级别2
过去一周 级别2
过去一个月 级别1
过去一年级 级别1
该报告中还提供了一些其他推荐配置，大多数都已经讨论过了或者已经成为经验法则。你需要为数据库服务器配置足够的内存。关于关系型数据库的一个指导原则就是分配必需的内存从而能够在内存中缓存所需数据。请参考相关文档查看需要给操作系统和运行在数据库服务器上的其他应用分配的内存大小。如前文所述，32位的Windows操作系统仅支持4GB内存，所以请选择64位的Windows操作系统。
调整vCenter Server时还需要考虑数据库恢复模型。例如：Microsoft SQL Server的默认恢复模型是全恢复，这意味着如果没有备份，数据库日志会无限制地增长。如果组织内没有专职的DBA为管理SQL Server数据库备份，那么我们建议将恢复模型改为简单恢复。如果你坚持使用完全恢复模型，那么请确保有足够的硬盘空间来保存两次数据库备份间的日志。
插件
插件很厉害，可以让你在不适用多个工具的情况下，在管理控制台中执行所有任务来管理vSphere环境。例如主要的存储供应商（NetApp、EMC、Dell、HP和IBM）都提供了可以用来配置存储阵列的虚拟部分的插件。使用这些插件，你可以创建新的LUN或数据存储、查看与后端存储相关的虚拟机统计信息、根据厂商提供的最佳实践优化ESXi host等。
遗憾的是，除了这些优点外，插件还有一些你不希望有的缺点。特别是运行插件需要额外的资源。需要考虑的资源如下：
硬盘空间。
内存。
你一定想知道这些插件是客户端插件（应用于基于Windows的vSphere 客户端）还是服务端插件（应用于下一代vSphere Web客户端）。很可能自己已经总结出：安装客户端的插件时会对客户端的资源产生影响，服务端插件会影响vCenter Server或vCenter Web Client Server的资源。由于插件间的资源需求差别很大，因此我们无法提供任何具体的推荐配置，只能咨询插件供应商来获取完整详细的插件资源影响、配置硬性和运维影响。
硬件资源
上节讨论的内容很有意义，但归根结底都会落到硬件资源（物理的或者虚拟的）问题上。根据VMware官方文档，vCenter所需的最小资源配置如下：
2个CPU（物理或虚拟内核）。每个CPU都是主频为2.0GHZ或以上的Intel或AMD处理器。如果数据库和vCenter安装在同一个服务器上，要求会更高些。
3GB 内存。如果数据库和vCenter安装在同一个服务器上，要求会更高些。VMware VirtualCenter Management Webservice需要128MB到1.5GB的额外内存，这个进程在vCenter启动时负责分配内存。驱动这些Web Service的引擎是TomcatJVM。
2GB硬盘空间。如果数据库和vCenter安装在同一个服务器上，或者vCenter上还安装了Upgrade Manager并将更新包也放在了同一个服务器上，那么配置要求会更高些。安装vCenter时，需要最大2GB的空间来解压Microsoft SQL Server 2005 Express的安装包。安装完成后，其中大约1.5GB的内容会被删除。
推荐使用Gb的网络连接。
这个最小配置对于测试环境或试验阶段来说是没问题的。但是如果已经确定要部署大量的host和虚拟机，那么就需要更高的配置。事实上，我们已经提供了很多方面的推荐配置：操作系统、数据库位置、被管理对象数以及是否存在VUM。为vCenter Server选择或分配硬件资源时，不应该根据当前需求规划，而是要根据预期的或者必需的扩展需求来规划。
现在，已经讨论了设计的五个基本原则中的三个：可用性、可管理性和性能。下面介绍可恢复性。
3.3.4 可恢复性
当设计管理层考虑到可恢复性时，你想到的应该是故障。多长时间可以恢复vCenter Server故障？多长时间可以恢复vCenter 数据库故障？如第1章所述，可恢复性描述了几个不同的概念：除了像 Mean Time To Repair （MTTR）这样的一些度量指标外，还有Recovery Time Objective （RTO）和Recovery Point Objective （RPO）。灾难恢复和业务连续性也属于可恢复性范畴。
上述概念是如何应用到管理层设计中的呢？在vSphere设计的所有层面中，可恢复性中的一些概念和其他设计原则中的一些概念密切相关且相互交织。
介绍可用性的时候，我们提到过的vSphere HA 和vCenter Server Heartbeat也对可恢复性有直接影响。
介绍性能时提到的将数据库安装到一个独立服务器上，能够通过隔离不同组件和限制故障域来提高MTTR。
备份是保证管理层可恢复性的关键，请确保vSphere设计中包含合理的管理层备份方案。制定管理层备份策略时，需要考虑管理层所有组件的备份问题：vCenter Server、vSphere Update Manager（如果存在）、其他管理软件以及数据库。
最后，关于可恢复性的完善的文档也至关重要。可恢复性的衡量标准不仅仅是从故障或其他事件中恢复所需的时间，还包括用于恢复故障所付出的成本。一套既完整又及时更新的文档在很大程度上可以减少恢复环境所需的时间。
下一节将介绍设计管理层需要应用的第五个原则：安全性。
3.3.5 安全性
也许安全性应该放在第一个来讲解，但先后顺序并不代表其重要性。vSphere管理员中，十有八九都会把安全性放在虚拟化基础设施设计的首位。
如何设计vCenter Server的安全性呢？需要考虑如下三点：
隔离。
权限。
SSL证书。
下面将逐个详细介绍。
隔离
从安全性角度看，vCenter Server是虚拟化基础设施中最重要的组件。如果有人危害到vCenter Sever，例如关闭虚拟机、删除虚拟机中的数据、删除虚拟机甚至整个数据存储，将导致巨大的损失。
不应该让企业网中所有的工作站都能访问vCenter Server，你可以采取如下任一措施来实现：
把vCenter放在一个独立管理的VLAN中。
把vCenter置于防火墙之后。
在交换机上定义访问列表。
在vCenter Server上设置防火墙规则。
权限
默认情况下，vCenter Server上的Administrators Security组用户对整个虚拟化环境具有完全访问权限。你希望让vCenter上的管理员能控制所有的虚拟机吗？这并不一定是个好主意。你可以通过如下方法来限制管理员的默认访问权限：
- 在vCenter Server上创建一个本地安全组（vi-admins）。
- 在vCenter Sever上创建一个本地用户（viadmin-local）。这样，如果域账号不可用或者vCenter无法连接到域时，你还可以控制虚拟化环境。
- 创建一个域用户（viadmin）。
- 将viadmin和viadmin-local用户添加到vi-admins组。
- 将管理员的默认权限修改为vi-admins组。
此外，请遵循最小权限原则，即只给用户赋予完成任务所需的必要权限。完全没有必要给只需要访问VM控制台的用户赋予管理员权限，最好创建一个仅包含该任务所需权限的自定义角色，然后再赋予该用户这个角色。
VM访问就是个很好的例子。假设有人为了能随时给一个服务器上电，向你索要服务器机房的密码。你会给他吗？显然，给他密码是很不明智的做法。
请将vCenter Server视为数据中心的安全区域。不能让所有人都可以访问vSphere基础设施。如果要让某个用户访问服务器，那么他可以通过远程桌面或者SSH连接实现。
在虚拟机上启用VNC客户端是不推荐的方式，这需要额外配置所有ESXi host来允许远程管理。如果真的需要，请使用自定义角色。
SSL证书
客户端与vCenter Server之间的会话可以从任意vSphere API客户端发起，例如vSphere 客户端和PowerCLI。默认情况下，所有通信都是经过SSL加密的，但是默认的证书并不是由受信任的证书机构签署的，因此无法提供生产环境所需的校验安全性。这些自签名证书很容易受到中间人攻击，因此客户端连接到vCenter Server时会收到警告信息。
如果想在企业网外部使用加密的远程连接，那么请从受信任的证书机构获取证书，或者使用企业域自己的PKI设施来为SSL连接提供有效证书。
