本节书摘来自华章出版社《VMware vSphere设计（原书第2版）》一 书中的第1章，第1.4节，作者：[美] 福布斯·格思里（Forbes Guthrie）斯科特·罗威（Scott Lowe）肯德里克·科尔曼（Kendrick Coleman），更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1.4 设计流程
既然已经讨论了设计的三个层面和5个基本原则，那么是时候介绍设计流程了。本节将介绍如何进行VMware vSphere设计，其中要完成哪些任务，以及要完成这些任务需要使用什么工具。
我们在前面提到过，vSphere设计最重要的就是功能需求。那么从功能需求开始介绍设计流程。
1.4.1 收集并定义功能需求
功能需求是vSphere设计的基础和驱动力。大多数设计决策都是基于或者受制于功能需求的，因此在收集和定义功能需求阶段，应该尽可能实现功能需求的全面性和完整性。
很多时候，有些功能需求是不需要收集的。例如，组织准备应用VMware vSphere来达到整合的目的，功能需求可能已经描述得很清楚，比如：用虚拟化环境实现整合后，其承载能力应相当于250台物理服务器。这样就不需要再定义这个需求了（但是，在设计中实现这个功能需求还是要花些心思的）。
根据我们的经验，有现成功能需求的情况并不常见。所以，我们不得不自己收集并定义功能需求。收集功能需求主要有两种方式：
阅读文档。
采访。
你可以这么认为：VMware定义的通过采访来收集信息的方式是一种咨询性方法。
阅读文档
有时候，实施VMware vSphere的客户或单位有概述功能需求的文档。虚拟化的实施是为了实现一个目标（去“做什么”），这个文档就记录了组织大概想要实现什么。例如，实施虚拟化是其桌面虚拟化目标的一部分，这样VMware vSphere环境的一些功能需求就可以直接从为桌面虚拟化项目准备的文档中得到。如果桌面虚拟化文档中有规定：在host故障的时候，VMware vSphere环境可以自动重启桌面虚拟机，那么这就相当于给你提了个醒：你的vSphere环境需要使用vSphere HA来满足这个需求。而且，因为使用vSphere HA，就必然会用到集群，这就意味着还需要冗余管理，而冗余管理又影响到了网络设计…如此，牵一发而动全身。
再举个例子，假设组织要将现有的数据中心迁移到一个新的数据中心，并已经在文档中列出了需要迁移的应用。你可以通过这个文档了解各个应用都有什么要求，然后制定必要的功能需求来实现这些要求。文档中很可能还指出了I/O profile主要是写而不是读，而且应用还需要每秒钟维持一定数量的事务处理（Transactions Per Second，TPS）。将这个信息转化为存储需求就是RAID级别，阵列类型，存储协议和每秒进行读写的操作次数（I/O Operations Per Second，IOPS）。
虽然阅读文档对挖掘需求很有帮助，但是不可能在文档中得到所有信息。如果这个单位和其他单位一样，文档稀少且不完整。那么，就需要直接通过这个单位的人来收集需求信息。
采访
收集信息以了解功能需求的第二个主要方法就是：采访要实施VMware vSphere的单位或组织中的人。
一般而言，除非你已经从别人那里得到了想要的信息（即使得到了，也有可能需要进行采访来确保没有遗漏什么信息），你就得采访组织的以下人群：
桌面支持人员。
服务器管理员。
网络管理员。
存储管理员。
安全经理。
符合性/法务人员。
应用所有人。
业务主管。
项目经理或项目负责人/所有人。
执行/管理负责人。
架构师。
并不是所有情况下，都得采访上述所有人。有选择性地采访，能覆盖到每类人员即可。
这些人可以提供给你很多信息：当前环境支持什么应用、这些应用的需求、当前遵循的服务级别协议、数据中心中不同应用或服务间的相互依赖关系、项目计划或针对未来趋势的计划、复合型或法规要求、业务级别的需求、财务目标、运维层面和工作流，以及其他一些可以用来挖掘出功能需求的信息。
1.4.2 评估环境
收集完足够用来挖掘需求的信息后，就该评估下当前的环境了。评估环境的目的如下：
某些情况下，评估结果可以用来验证或澄清需求定义阶段收集的信息。人毕竟是人，总会犯错误或者遗漏信息。通过对环境进行评估，你可以验证别人告诉你当前在使用的应用的确存在。
评估还为技术层面的设计提供了必要的信息。它能够发现现有环境中服务器的类型和配置、当前的网络配置，以及存储配置。这些信息对创建一个能与当前结构紧密结合的新结构是至关重要的。如果现在使用iSCSI，要部署光纤，就会产生互操作难题。通过评估来彻底了解当前环境有助于合理裁剪vSphere设计的技术层面。
要评估环境，可供选择的工具有很多。如果组织内已经具备足够健壮的管理系统，那么你可以从中得到需要的目录、配置和性能信息。如果没有相应的管理系统，那么你就得分析整个环境，从如下资源中挖掘出想要的信息：
活动目录。
LDAP目录。
网络管理工具。
企业范围的日志解决方案。
IP寻址文档。
网络设备配置。
服务器性能数据。
服务器配置数据。
不难想象，只要是在稍微大一点的环境里，想通过手动收集数据来评估环境是相当耗时的，而且还容易出错。幸运的是，为了节省时间避免丢失关键数据，VMware以及其他虚拟化产品/解决方案供应商都会提供评估工具用来自动收集信息。甚至虚拟化社区也会提供脚本或其他工具来收集物理环境和虚拟环境的信息。
来自虚拟化供应商或社区会员的一些自动化工具如下：
VMware Capacity Planner。
来自社区会员的各种健康检查脚本。
NetIQ PlateSpin Recon （也就是以前的 Novell PlateSpin PowerRecon）。
CiRBA。
在第10章中介绍一些工具，因为容量规划会涉及一些虚拟化之前的评估工作。这些自动化工具还可以用来在准备结束vSphere设计时，评估当前虚拟化环境。
现在，已经了解了一些功能需求、用于定义其他功能需求的必要信息，以及现有环境状况。但是，在准备开始设计前，最好还是先进行差异性分析。
1.4.3 差异性分析
并不是所有的vSphere设计都是gree field implementation（即在一个从未部署过vSphere的环境中搭建全新的vSphere虚拟化环境）。当已经部署了VMware vSphere组织，想要升级或扩展现有环境，或者要迁移到新环境中时，你就需要执行差异性分析。
差异性分析是一个过程，在这个过程中我们对比环境当前状态和未来的期望状态，进而分析得出为了实现期望状态我们需要做什么。很可能当前环境并不支持相应的可扩展性。通过差异性分析就可以知道设计中的那些部分制约了其增长，并找到消除这些制约因素（至少改善其可扩展性）的方向。
一旦明确了功能需求、获得了当前环境的信息，以及执行了差异性分析（必要时），你就可以开始组合vSphere设计了。
1.4.4 组合设计
组合vSphere设计是初始过程，如图1-3所示。组合设计时，你要在每个设计层面做出各种决策。这些决策分别解答什么/谁/如何的问题，而且都是基于功能需求的（直接获取或通过设计的5个基本原则AMPRS定义的）。每个决策都有级联效应，会影响到一系列决策（称为下游决策），如图1-8所示。
每做一个决策，都要检查由此决策引出的所有下游决策的决策结果，以确保满足所有功能需求。如果满足则继续；如果不满足，就得改变决策或者不得不违背一个或多个功能需求。
违背功能需求也许是必要的
有时候，组织会有些不现实的需求。这样，偶尔违背一个功能需求也是必要的，只要有充分的理由并能提供补救措施。是坚持原有的需求，还是接受违背了某个功能需求的设计，这都取决于组织。
组合设计时，还要为VMware vSphere环境定义标准和最佳实践：
标准 好的设计会为host名称、网络配置、存储布局、资源分配和虚拟机配置等定义标准。标准之所以重要是因为它降低了复杂度。复杂度降低了，运维也就简化了，成本也跟着降低。如果没有标准，要想高效运维是十分困难的，而低效恰恰是导致VMware vSphere环境失败的致命因素。
最佳实践 好的设计还会定义并强化执行最佳实践，这些最佳实践都是与组织需要和功能需求相吻合的。“最佳时间”并不单单指供应商在如何部署其产品方面给我们的建议，它还可以是组织应该遵守的运维流程。例如，一个最佳实践指出所有基于Windows的虚拟机的文件系统必须和虚拟硬盘的文件系统对齐。的确，这是VMware的推荐做法，但同时它也是一个好的设计应该遵循的运维实践，这样能确保环境高效且运行稳定。好的设计还会包括一些与实施相关的内容，例如，新虚拟机的机构、新数据存储的配置等。
不要盲目遵从最佳实践
谈及供应商的最佳实践时，不要盲目地马上执行。请首先检验这个时间并试图去理解其背后的原因。如果存储供应商说最好采用某个多路径策略，那么仔细研究下为什么它会推荐这个多路径策略呢？如果服务器供应商把特定的BIOS设置作为最佳实践，那么想想为什么要这么设置。这样你就能够更加深刻透彻地理解虚拟化环境，同时也为制定实施相关的最佳实践做了更充分的准备。
组合设计是个很细致、很耗时的工作。后面的大部分章节都将专注于特定的技术领域以及做VMware vSphere设计时需要做的决策。
1.4.5 文档化设计
设计组合完毕后，也就是说已经做好了每个技术层面的决策，并且将决策结果（以及下游决策结果）和功能需求进行对照，以确保满足功能需求。接下来就可以开始文档化设计了。
设计流程的这个环节可能会和组合设计环节同时进行，而且大部分都是直接记录。你需要确保文档阐述了设计的每个层面。很多时候，IT专家们会忘记组织和运维层面，但是这两个层面和技术层面是同样重要的，在设计资料中应该对三者给予同样的重视。
特别要注意的是，设计资料中至少要包含如下文档：
功能需求描述，包括直接提供的和自己定义的。
技术层面决策的完整描述，解决关于“什么”的问题。
组织层面决策的完整描述，解决关于“谁”的问题。
运维层面决策的完整描述，解决关于“如何”的问题。
构造文档（也叫蓝图），描述构建设计时涉及的细节。
测试计划，描述如何验证该设计是否满足功能需求。
概述性的架构设计文档，将众多元素组织在一起，介绍设计的整个过程。
1.4.6 实施
设计完成且被组织认可后，就可以着手实施了。这样就有机会根据自己的文档来构建虚拟化环境。
如果不是亲自实施，就需要交给其他人来做。这就是为什么设计文档一定要足够详细且完整的原因。当别人实施你的设计时，他不可能知道你设计时脑子里想的是什么。所以，请确保在设计文档中提供尽可能多的信息，让实施过程能够简单顺利地进行。
