本节书摘来自华章出版社《VMware vSphere设计（原书第2版）》一 书中的第1章，第1.2节，作者：[美] 福布斯·格思里（Forbes Guthrie）斯科特·罗威（Scott Lowe）肯德里克·科尔曼（Kendrick Coleman），更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.2节将详细介绍各个层面。

采用这种方式定义和描述，VMware vSphere设计就显得简单多了。但是正如你即将在本书中看到的，或者根据你的经验已经知道的一样，VMware vSphere设计可能是很复杂的。然而，即使是在最复杂的设计中，都会有一个统一的元素将不同的层面聚合起来。图1-2中所描述的那个统一元素是什么呢？就是设计的功能需求。

功能需求是非常重要的。在VMware vSphere设计（或者任何IT设计工作）中，我们再强调功能需求所扮演角色的重要性也不为过，这是因为它回答了设计需要做什么事情这个问题。需要牢记的是企业实施VMware vSphere都是有它的原因的，并不仅仅是为了安装vSphere。虽然VMware非常希望事情就是如此简单，但事实绝非如此。在很多情况下，VMware vSphere实施背后都会有一个驱动因素、一个动力或者一个目的。当然，这个让企业或组织部署实施VMware vSphere的原因多种多样，因客户或组织的不同而不同。根据我们在虚拟化行业的经验，不同的原因列举如下：整合　企业或组织拥有的物理服务器太多了，希望缩减数量。这个缩减物理服务器数量的需求可能源于很多原因，包括：减少数据中心的使用空间、降低电力和冷却成本，或者降低硬件更新成本。推出新应用　企业或组织想在数据中心部署新的应用或服务，并且已经决定采用虚拟化技术来完成这次部署。这个任务可能是部署某个应用的新版本，例如：企业当前使用Exchange 2007，然后决定通过VMware vSphere构建虚拟环境来推出Exchange 2010；或者某个已经部署了SAP的公司决定改用VMware vSphere来实现。采用虚拟化环境来部署应用或服务的原因不胜枚举，可能包括：增强应用、简化部署和改善对灾难恢复或业务连续性的支持。灾难恢复/业务连续性（DR/BC）　企业或组织正在制定或增强灾难恢复/业务连续性解决方案，并且已经决定使用虚拟化作为这个解决方案的关键部分。它很可能在使用基于阵列的复制解决方案，现在希望使用VMware vSphere和VMware Site Recovery Manager（SRM）来提供更加自动化的灾难恢复/业务连续性解决方案。这个选择通常都是出于经济原因：企业或组织希望减少故障时间（以最小化损失），或者降低实施解决方案的成本。虚拟桌面基础设施　企业或组织希望部署虚拟桌面基础设施（VDI）以实现桌面的移动性、更好的远程接入解决方案、增强的安全性或者较低的桌面管理成本。不管动机如何，VMware vSphere 虚拟环境的应用就是为了支持VDI的部署。如上所述，每个企业或组织采用虚拟化技术的原因都各自不同。他们不会仅为了某一个原因就采用虚拟化技术，但这也是有原因的。通常采用虚拟化技术的原因有多个，而这些原因也就构成了功能需求的基础，它们是虚拟化设计必须“做”的“事情”。功能需求将企业或组织采用VMware vSphere技术的原因具体化，并转化成可执行的条目，而我们正是用这些条目来驱动各个设计决策的。仔细想想刚才列举的例子。那个组织是计划将一个新的Microsoft Exchange Server 2010部署成虚拟化的吗？如果是这样的，那么VMware vSphere的设计最好能满足这个功能需求。这个设计必须明确具体地体现Microsoft Exchange Server 2010的配置需求、支撑性需求和资源约束条件。如果不能合理地解释Microsoft Exchange Server 2010为什么要运行在虚拟化环境中，那么你就是没有考虑到设计的某个功能需求。整个实施很可能也会失败。因为VMware vSphere设计无法完成企业需要它去“做”的“事情”：运行Microsoft Exchange Server 2010。明白了这一点。再回过头去看图1-2就能更好地理解功能需求是如何围绕并将VMware vSphere设计的几个层面统一为一个有机整体了。继续讨论那个在组织的虚拟化环境中部署Microsoft Exchange Server 2010的例子，其功能需求对很多方面都有影响：硬件服务器的选择必须保证能够给虚拟机配置足够的资源以运行Microsoft Exchange Server 2010。运行Exchange的虚拟机要尽可能多配置RAM、虚拟CPU（vCPU）和磁盘空间。Exchange Server 2010的配置还会影响到集群配置，例如vSphere High Availability（HA）、vSphere Distributed Resource Scheduler（DRS）和vSphere Fault Tolerance（FT）。集群配置，例如：应用vSphere FT的能力，反过来还会影响到在虚拟环境中运行的VMware ESXi的网络配置。因vSphere HA、vSphere DRS和vSphere FT这些特性的应用（或应用不足），vSphere设计还要包含运维过程。上述清单还可以不断追加，不过此时你应该已经明白了。功能需求几乎能影响到vSphere设计各个层面的每个决策点，因此它是整个VMware vSphere设计的核心。任何没有直接阐述组织功能需求的设计都不是一个好设计，且其实施也不会成功。任何要设计vSphere虚拟环境的VMware vSphere咨询师或者架构师，如果不了解功能需求，都会以失败告终。毕竟，功能需求是设计要实现的目标，如果连目标都搞不清楚，又怎么谈得上去实现目标呢？有趣的是，虽然功能需求会直接影响到决策点，例如：用什么服务器、服务器的外形因素、网卡（NIC）的种类和数量等，但是这些决策点也会影响到功能需求。功能需求和决策点之间存在固有的相互依赖关系，如图1-3所示。

　虽然之前的讨论一直专注于需求，但是正式的VMware设计文档通常会介绍驱动设计的四个主要因素：需求、风险、约束和假设。需求已经讨论过了，它代表设计必须提供或者满足的具体特性或功能；约束就是决策点，例如：服务器类型的选择、存储类型的使用或者采用何种方式接入现有网络中，这些决策一旦决定就无法更改；风险代表设计未能满足需求或约束的具体区域，例如：如果设计有特定的存储-容量需求，但同时还存在一个约束使设计无法满足存储需求，这就是一个风险。最后，假设就是vSphere架构师为了填补缺失信息在设计中加入的需求或约束，例如：为了规划增长，需要知道具体的增长需求。如果此需求未知，那么架构师在设计的时候就可以通过假设来填补这个空白。下面将继续熟悉vSphere设计流程，请牢记上述四个因素。

由于功能需求和决策点之间的相互依赖，你会发现设计其实是个交互过程。根据功能需求来决策，然后根据决策来确保它能够满足功能需求。如果满足，再继续下一个决策点； 如果不满足，就要根据功能需求修正决策。这个交互过程又一次强调了功能需求在设计过程中的重要性。如本节开始部分所述，“设计”就是一个决策过程，在这个过程中我们决定如何集成、配置VMware vSphere环境的不同组成要素，以构建一个健壮且灵活的虚拟基础设施环境。但是，当我们将功能需求在设计过程中扮演的关键角色（统一技术、组织和运维三个层面）考虑在内的时候，也许对“设计”更好的定义应该是：“设计”就是一个决策过程，我们在这个过程中决定如何集成、配置VMware vSphere环境的不同组成要素，以满足功能需求。或者简而化之：“设计”就是让VMware vSphere环境“做”它需要做的“事情”。现在，你应该比较清楚什么是VMware vSphere设计，以及它为什么如此重要了。下一节将进一步讲解vSphere设计的三个层面。