当制订服务器整合计划时，分析阶段的目的是为最终状态创建一个完整的定义。最终状态的预定目标可以按照如下形式来描述：

• 所有在整合之后还将存在的服务器的列表，包含将作为最终的虚拟化环境的一部分而被保留的服务器和将要(新)购置的服务器。
• 每个服务器上需要创建的虚拟机的个数。一些服务器可能被留作物理单机——不装虚拟化软件。这些服务器将支撑一个单独的应用，一个单独的数据库或者一套应用组合。
• 每个应用实例和数据库实例在整合后的虚拟化环境中的详细的部署情况，包含支撑运行应用或者数据库的虚拟机的物理主机，不包含专门的非虚拟化主机。

　　在分析阶段，你所要做的第一件事情是搞清楚那些现存的，并且在新的虚拟化环境中还将继续保留服务器。基于此，再次检查这些服务器的详细配置：CPU、内存、网络接口。

　　某些情况下，你可能需要通过某些方法升级这些存在的服务器，比如增加内存。一旦你列出了需要保留的服务器清单，你就可以指定一些代码给它们，比如E1,E2,E3等等。这将使得随后的步骤变得轻松些。

　　搞定这些之后，你就可以开始真正的分析任务——按照最终状态，为每个应用实例和数据库实例分派一个物理服务器。如果你有几百个，甚至几千个服务器要分析，这可能是一个令人生畏的任务。

　　就算你能大大减少待分析服务器的数目，假如该项目用了大概2个月的时间收集数据，那么分析工作也不可能在3个小时内完成。

　　当决定哪些应用和数据库需要部署在同一个物理主机的不同虚拟机上时，这里给出一些宗旨：

• 每个物理主机上虚拟机的个数不要超过一个合理的数目。比如，你可以设定一个限制，用于生产目的物理主机上最多跑10个虚拟机，用于开发和QA/测试目的的物理主机上最多跑20个虚拟机。

　　虚拟化软件可以在每个物理主机上支持超过200个虚拟机，不过，你最好不要在一个物理主机上集中太多的虚拟机，万一物理主机发生故障，那将对业务产生很大影响。

• 物理主机不要过载。保证物理主机可以满足其上每个虚拟机对CPU、内存和网络连接的需求。

　　为了满足以上两个宗旨，可以将重负载和轻负载的虚拟机混合部署。如果在一个物理主机上运行太多轻负载的虚拟机虽然可以有效的利用服务器，但违反了第一条宗旨；但只用少量重负载的虚拟机也会有风险，比如，在业务峰值时期。

　　为了快速的评估潜在的混合部署是否合适，最好从项目数据库中结合并抽取信息到一个单独的应用/数据库实例检查表。

　　很容易将这个表格抽出成一个Excel表，让Excel中每行代表一个应用或者数据库实例。你可能希望不要包含整合后不需要的服务器。Excel表中包含以下各列：

• 应用ID/数据库ID
• 服务器ID
• 角色
• Green Zone(以起始日期和时间到最终的日期和时间表示)
• 负载因子
• 负载类型
• 特殊情况
• 物理服务器指派
• 虚拟机号码

　　前两列是关键列，因为，当组合的时候，会在应用或数据库实例当时所在的服务器上独一无二的标示它们。”角色”，”Green Zone”，”负载因子”等等都是应用/数据库实例的属性。

　　“负载因子”列是一个百分数，描述的是应用或数据库实例部署到最终支撑它们的服务器时的负载。从本质上讲，这个值描述了应用或数据库实例在每月的几个高负载峰值期对资源的需求。同时，也将最终需要何种能力的服务器考虑在内。(最终状态的服务器能力越强，负载因子的值越低。)

　　负载因子有相应的公式算出，该公式包含了项目数据库中服务器表的信息，服务器性能表的信息和你计划购置的最终服务器的规格书或者计划重复使用的、已存在于数据中心内的服务器。

　　估算负载因子的时候，你必须将你决定使用的性能测量值(比如，CPU利用率百分比)和当前服务器的能力考虑在内。服务器的能力包含该服务器有多少个CPU以及这些CPU的处理能力和最终状态的服务器的CPU处理能力的比率。

　　“负载类型”这一列采用一种应用/数据库实例的粗分类法，由计算出的负载因子和其他相似的测量值得出，这些测量值有助于选择一个实例的组合放置在一个指定的服务器上。比如，你可以使用以下分类方案：基于每个实例在最终状态的预期的CPU利用率。

 ＜2%  = 低
 ＞2%  & ＜5%  = 中
 ＞5%  & ＜10%  = 高
 ＞10%  & ＜30%  = 很高
 ＞30%  = 不适合

　　最后一个值(“不适合”)表示该实例因为消耗的资源太高，运行在虚拟机上是不合适的。很多机构的微软Exchange应用都属于此类。

　　如果当前的服务器以组合的方式运行——一个应用和一个数据库运行在同一个主机上——计算的时候就需要一些调整。这个调整应该能够区分应用和数据库分别消耗的资源而不是当前服务器整体的性能数据。不过，很难确定应用和数据库各自的负载。

　　以各占50%来对待不合适。可取的方法是拿每个实例负载因子的3/4或者将全部的负载因子分配给每个应用和数据库实例。

　　“特殊情况”列包含应用和数据库的关键信息。这些数据来自数据中心的记录或者以前的访谈记录，在制定虚拟化相关的最终决定之前，你必须将他们考虑在内。

　　最后两列——“物理服务器指派和虚拟机号码”——你需要输入一个代码(比如，E3)来标示要支撑一组应用和数据库的物理服务器。虚拟机号码标示位于那台物理服务器的指定虚拟机。

　　假设你已经为将要保留的服务器按照如下形式编号：E1,E2,E3等，你可以为将要购置的服务器按照如下形式编号：N1,N2,N3等等。

　　当你使用应用/数据库实例检查表和自动排序/手工选择的那些Excel行的组合时，决定最终状态下每个物理服务器上分配那个实例将会很容易。

　　这里有涉及物理实例指定的一般步骤供你参考采用：

1. 按照”特殊情况”对实例进行排序以分离需要部署在某指定服务器上的应用/数据库实例。在每个实例行(Excel中每行代表一个实例)的”物理服务器指派”列中输入指定的服务器的编号(E1,E2,E3…)。”虚拟机号码”列没有任何值，因此，可以输入”NV”代表它不是一个虚拟化服务器。到此，你可以分开每个已经虚拟化的服务器上的实例并为这些服务器指定一个唯一的代码。
2. 按照负载类型对其余的实例进行排序，然后为所有”不适合”放置在虚拟化平台的实例指定一个独立的服务器。
3. 按照”角色”对前两步中未处理的实例进行排序，然后再按”Green Zone”使它们按组排列。将具有相关角色的实例放置在同一个物理服务器上是个好主意，这样就可以为实例应用不同的标准和程序来支持它们。你还应该预防QA/测试实例的负载测试，避免这些测试影响生产系统。
4. 选择具有相同角色和Green Zone的行，也就是将要放置在每个物理服务器上的实例。你的选择应该兼顾负载类型的平衡——比如，两高，三中，五低。并且确认所有的负载因子加起来高于30%,低于50%。如果开发和QA/测试服务器一直都是低负载的类型，你就可以为每个物理服务器分派较多数量的实例(比如，20个)。一旦你做出的选择看上去可以接受了，在服务器指派列为下一个可用的服务器输入一个编号。然后，为每个选择的实例分配虚拟机的号码。为每个实例使用不同的数字，对每个服务器可以从1开始。
5. 重复以上过程直至你处理完一个共有的Green Zone组内的所有的实例。然后，接着处理下一个共有的Green Zone。继续这个过程，直到每个实例(所有的角色和所有的Green Zone)都分配到一个物理服务器并给定了一个虚拟机号码。