简介这份面向企业IT运维人员、虚拟化架构师及初学者的VMware服务器虚拟化方案文档围绕vSphere核心产品系统梳理vCompute、vStorage与vNetwork在企业数据中心中的落地思路可帮助读者理解服务器整合、业务连续性和测试开发三类典型场景的规划方法。文档共1个doc文件压缩包约3.39MB内容以完整方案文本为主适合作为架构设计与实施参考。已有2737人学习说明其在虚拟化入门与方案选型中具有一定参考价值。正文从需求分析、方案拓扑图、软硬件需求切入延伸到基础架构服务层、应用程序服务层和虚拟应用程序层的结构描述并涉及vCenter Server、HA、DRS、vMotion、Lab Manager及SRM异地容灾等技术要点最后讨论降低TCO、提升运营效率与服务水平等收益还包含与同类产品的效率和控制比较便于读者形成从方案设计到价值评估的完整认知。1. 从二十台机器只跑出三台的活说起这套方案要解决什么机房里摆着二十台四路服务器监控面板上 CPU 平均利用率停在 12%内存用掉不到三成可业务部门还在申请新机器。这不是资源不够而是资源散在二十个互不相通的物理孤岛里。这份 VMware 服务器虚拟化解决方案要处理的正是这件事用 vSphere 把计算、存储、网络抽象成资源池再按 vCompute、vStorage、vNetwork 三层基础架构服务往上叠应用。写这份方案的场景很明确高校实验室做数据中心方向的毕设或课程设计需要一个能画出拓扑、能说清选型、能量化收益的完整案例企业 IT 要交一份整合方案要能对得上预算和验收口径。接下来按需求、架构、分层实现、避坑、验收的顺序展开中间每个环节都给出可复现的配置与判断标准。2. 需求分析与总体架构三层服务模型与二十台机器的容量账2.1 先把现状账算清利用率、整合比和三年增长做服务器整合方案最忌讳上来就画拓扑。第一步是把现状数据采集齐每台物理机的 CPU 型号与核数、内存容量、本地磁盘与 HBA 情况、操作系统版本、业务归属、日均 CPU 与内存峰值、峰值时段、磁盘 IOPS 和网络吞吐。这套方案里二十台服务器跑的是文件与打印、目录服务、网页前端、NAT/DHCP 这类基础应用外加少量数据库和内部业务系统典型特征是 CPU 合并度中等、I/O 压力中等、单机资源占用低。采集完数据才会发现两个数多数机器系统资源利用率在 10%15%而内存占用往往比 CPU 更早成为瓶颈。很多人的整合比是这样算的——单台宿主机 16 个物理核除以每台虚拟机 2 个 vCPU得出 8 台。这个算法会直接导致上线后卡顿。合格的算法是三条线取最小值CPU 线按原文给出的「每个 CPU 达到甚至超过 4 个负载」的整合比率推算内存线按物理内存减去虚拟化层开销后留出 20%30% 余量再做超分存储线按聚合 IOPS 除以单块盘的可用 IOPS再乘上 RAID 写惩罚系数。我在做这类方案时习惯把容量表做成三列现有需求、整合后需求、余量。二十台物理机的负载按 4:1 整合到 5 台高配宿主机上剩余机器留作迁移缓冲和故障替换这个比例既能体现整合收益又不至于把风险压到极限。三年增长按每年 15%20% 预留写进方案里作为扩容触发条件比事后临时加机器体面得多。原文给出的收益区间是硬件成本下降 28%53%、运营成本下降 72%79%、综合成本下降 29%64%这些数字要作为目标值写进需求分析但必须注明是同类项目统计口径验收时用自己项目的实测值替换别直接照搬当承诺。2.2 总体拓扑一个管理节点、一个计算资源池、一套共享存储拓扑结构不复杂但每一层的位置不能放错。最上面是管理节点一台普通 PC Server 装 vCenter Server承担集中管理、权限、模板库、告警和调度策略下发中间是计算资源池二十台服务器中的大部分安装 hypervisor 后加入同一个集群通过共享存储挂载同一批数据存储底层是 FC SAN 共享存储双控制器双链路接入两台光纤交换机做冗余最外侧是管理网、业务网、存储网三张网络平面隔离。原文把虚拟架构分成基础架构服务层、应用程序服务层和虚拟应用程序层这个划分是从「资源怎么提供」的角度看的从运维角度看还有另一套三分法基础架构管理层管主机、存储、网络的纳管与监控虚拟资源管理层管虚拟机生命周期、模板、克隆自动化服务管理层管 HA、DRS、告警联动这类策略。两套视角写在同一份方案里不冲突前者用于向决策层解释钱花在哪后者用于向运维团队交代日常怎么干。有一点必须提前定死管理节点不要和业务虚拟机挤在同一个资源池里。vCenter 本身是虚拟机它要管理整个集群如果它所在的宿主机正好资源吃紧、或者被 DRS 迁到别处导致管理网络抖动整个管理面就失联了。通常的做法是单独划一个管理集群一到两台宿主机给 vCenter 虚拟机配置 CPU 和内存预留再配 HA 的接入控制策略保证管理面永远有资源可用。这个细节在拓扑图上只是一个小方框但在实际运行中决定了故障时你能不能登进去处理问题。2.3 软硬件清单与配置基线二十台这个数怎么定清单不能凭感觉写要跟容量模型对齐。下面这张表是这套方案的基线配置读者可以按自己项目的规模等比缩放重点是看清每个角色为什么是这个配置。角色数量关键配置用途说明四路机架服务器宿主机按整合后需求定本项目主力约 58 台4 颗 4 核 CPU、32GB 内存、双盘 RAID1、双口光纤 HBA承载生产虚拟机配置双 HBA 保证存储链路冗余两路机架服务器宿主机若干2 颗 4 核 CPU、16GB 内存、双盘 RAID1、双口光纤 HBA承载测试开发、边缘业务、容灾演练环境普通 PC Server1 台中等配置独立系统盘部署 vCenter Server 与模板库共享存储1 套FC SAN双控制器按容量与 IOPS 规划 LUN所有宿主机共享支撑 vMotion、HA、集群文件系统光纤交换机2 台双平面互联存储链路冗余避免单交换机故障软件侧原文给的基线是 vSphere 4、vCenter Server 4、Lab Manager 4功能清单包括 HA、vMotion、DRS、FT、DPM、Storage vMotion、精简配置、Data Recovery、Update Manager、vShield Zones、Host Profile、vNetwork。这份清单在实际方案里要拆成两列必选和可选。HA、vMotion、DRS、共享存储是整合的地基必须上FT 对网络和存储有额外要求只给最关键的一两台虚拟机开DPM 节能策略在很多场景是锦上添花可以先规划后启用异地容灾在原方案里明确标注为可选、不进入本期实施范围这个边界写清楚反而显得专业。提示清单里的「20 台服务器」是现状盘点数量不是全部都要装成宿主机。规划阶段要区分「保留物理」「转为虚拟」「退役」三类去向否则预算和机柜空间会对不上。3. 基础架构服务层落地vCompute、vStorage、vNetwork 的配置细节3.1 vCompute分配粒度、DRS 与 DPM 的取舍计算资源虚拟化的核心指标是分配粒度与动态调度能力。粒度越细资源浪费越少内存按 MB 分配、CPU 按 MHz 分配这是虚拟化平台相对物理分区方案最直接的优势。在给虚拟机定规格时vCPU 数量不是越多越好超过物理核心数会带来调度开销内存方面可以通过超分提高整合比但生产库和中间件这类内存敏感型业务不要超分测试开发环境可以适度超分。DRS 负责在集群内根据负载自动迁移虚拟机、平衡资源。它的价值不在于「自动」而在于「有依据地自动」——手动迁移靠人盯监控DRS 靠的是资源池的份额、预留和限制三层配置。我一般这么配给每个业务资源池设 CPU 和内存份额关键业务份额调高测试环境份额调低给所有生产虚拟机设内存预留防止气球驱动在资源紧张时回收它们的页把 DRS 先设成半自动模式跑一个月观察它给出的迁移建议是否合理再切成全自动。DPM 是电源管理负载低谷时把虚拟机集中到少数宿主机上把空闲宿主机下电。它能省电但代价是宿主机上下电的等待时间以及某些对启动时序敏感的业务会受影响。方案里可以规划这个能力实施时建议先只对非核心资源池开启并把唤醒延迟、排除列表配好。至于超分比CPU 一般控制在 1:3 到 1:4 之间内存生产池 1:1、测试池 1:1.5 左右这个区间是多数项目的稳态值超出后性能抖动会变得难以归因。Hypervisor 本身的体积也要纳入考虑。原文提到把 hypervisor 代码压缩到 50MB 以下以减小攻击面这是瘦 hypervisor 的思路对性能和安全都有正面意义。这一条在方案里属于「技术选型理由」说明为什么选型偏向精简的虚拟化层而不是把一整套通用操作系统塞进管理域。3.2 vStorageVMFS 卷规划、精简配置与 Storage vMotion存储是这类项目最容易翻车的地方因为它的容量和性能是两个独立维度只看容量必踩坑。集群文件系统 VMFS 的作用是让多台宿主机同时访问同一批 LUN同时保证元数据一致性这是 vMotion、HA 这些功能能够成立的前提。LUN 规划上生产虚拟机、模板、ISO 镜像、备份落地卷要分开别把模板和快照放在同一条 LUN 上——一条快照链把卷撑满所有挂在这条卷上的虚拟机一起暂停。精简配置解决的是「分配了但没用」的浪费按实际写入量占用存储空间原文给出的经验是存储成本可降低 50% 以上。但它有两个前提条件必须写进方案一是存储阵列本身的告警要打通卷使用率到 75% 和 85% 两档必须告警二是不能因为「反正是精简的」就随意分配 2TB 磁盘超额分配会带来静默写满的风险。卷在线扩容、Storage vMotion 不停机迁移存储这两项能力在规划阶段就要留给后续扩容使用把「容量不够就重建卷」这种操作从流程里彻底删掉。存储链路的冗余配置要在实施阶段验证不能只看配置文件。双 HBA 卡、双光纤交换机、存储双控制器任一环节单点都会让冗余形同虚设。验证方法是拔掉一条光纤链路观察业务虚拟机是否持续在线、路径是否自动切换。# 在单台 ESXi 主机上核对存储多路径与设备可见性 # 列出所有 SCSI 设备及其当前多路径策略 esxcli storage nmp device list # 把指定设备的路径策略设为轮询适用于支持 ALUA 的共享阵列 esxcli storage nmp device set --devicenaa.60060160xxxxxxxxxxxxxxxxxxxx --pspVMW_PSP_RR # 查看该设备当前可见的所有路径正常应看到 4 条双 HBA x 双控制器 esxcli storage core path list -d naa.60060160xxxxxxxxxxxxxxxxxxxx三行命令对应三个动作看设备、设策略、验路径。设备标识以naa.开头的十六进制串为唯一标识每套阵列不同不能照抄轮询策略让多条路径轮流承担 I/O相比固定路径更能用满双链路带宽最后一步是核对路径数量正常应等于 HBA 数乘以控制器数如果只看到 12 条说明交换机分区或 HBA 映射没配对要去查 FC 交换机的 zone 配置。这套核对在实施阶段每台主机都要跑一遍记录结果作为验收材料的一部分。3.3 vNetwork标准交换机、端口组与网卡绑定网络虚拟化在方案里常被写成一页带过实际上它是性能问题的高发区。物理网卡要按平面分工管理网走独立网卡vMotion 走独立网卡存储走独立网卡虚拟机业务流量走两条以上网卡绑定的上行链路。全部挤在一两条网卡上就等着迁移时和备份窗口互相打架。标准交换机的端口组规划要跟 VLAN 对齐生产、测试、管理、vMotion、存储各一个端口组VLAN ID 写清楚。网卡绑定的负载均衡策略有两种常见选择基于源虚拟端口 ID 的平衡不依赖交换机侧的聚合配置基于 IP 哈希的平衡需要交换机侧配置链路聚合。前者部署简单、单虚拟机流量上限受单网卡限制后者吞吐更高但两端必须严格匹配配错就会出现链路抖动甚至丢包。多数项目的做法是虚拟机业务网卡用源端口 ID 平衡vMotion 和存储流量用 IP 哈希把两种策略的适用面分开。# 在 ESXi 主机上创建业务用标准交换机绑定两条上行链路并设置负载均衡 esxcli network vswitch standard add --vswitch-namevSwitch1 esxcli network vswitch standard uplink add --uplink-namevmnic2 --vswitch-namevSwitch1 esxcli network vswitch standard uplink add --uplink-namevmnic3 --vswitch-namevSwitch1 # 负载均衡策略基于源虚拟端口 ID交换机侧无需额外聚合配置 esxcli network vswitch standard policy failover set \ --vswitch-namevSwitch1 \ --lbloadbalance_srcid \ --active-uplinksvmnic2,vmnic3 # 创建业务端口组并绑定 VLAN esxcli network vswitch standard portgroup add --portgroup-namePG-VM-Prod --vswitch-namevSwitch1 esxcli network vswitch standard portgroup set --portgroup-namePG-VM-Prod --vlan-id100命令里的vmnic2、vmnic3是主机侧网卡编号实施前要用esxcli network nic list核对物理网卡与网口的对应关系别凭感觉写--lbloadbalance_srcid就是上面说的源端口 ID 平衡--active-uplinks指定两条链路同时 active如果只想做主备把一条放到 standby 即可。端口组的 VLAN ID 必须和物理交换机端口配置一致不一致的典型表现是虚拟机拿不到地址、ping 不通网关排查时先看端口组 VLAN再看物理端口模式。在更大规模的环境里分布式交换机能把散在各主机上的配置统一成一份避免「二十台主机二十种配法」。是否升级到分布式交换机取决于规模和团队习惯本项目规模用标准交换机加上配置基线模板即可把每台主机的交换机、端口组、策略用主机配置文件统一固化新机器入池时套用比事后逐项比对省事得多。4. 应用服务层与虚拟应用层可用性、安全、备份、容灾四件事4.1 可用性分级vMotion、HA 与 FT 各管哪一段可用性不是「上 HA 就完事」它是有层级的。vMotion 解决的是计划内停机宿主机要打补丁、换内存把虚拟机零停机迁走业务无感知。HA 解决的是计划外宿主机故障主机突然掉电集群在其余主机上重启受影响的虚拟机恢复时间取决于虚拟机启动速度和资源预留业务会有几分钟到十几分钟中断。FT 解决的是连续性主虚拟机运行时有一条影子虚拟机同步执行主虚拟机所在主机故障影子立刻接管业务不断代价是资源翻倍、对网络和存储有额外要求。方案里要给业务分级把「哪台虚拟机配什么」写成矩阵。核心数据库和交易入口可以上 FT前提是 vCPU 数量和网络配置在支持范围内内部办公系统、文件服务用 HA 就够测试开发环境只保证 vMotion不需要 HA。这个矩阵写完硬件成本和可用性目标就对应上了答辩或评审时被问「为什么这台不做 FT」答案就是资源成本与中断窗口的权衡而不是「做不了」。NIC 与 HBA 的 Teaming 属于更底层的冗余前面章节讲过配置这里强调它在可用性体系中的位置vMotion 和 HA 都依赖网络和存储链路不断链路单点会让上层机制全部失效。通常的做法是把网卡绑定与存储多路径纳入同一张冗余检查表实施完成和每次变更后各跑一次。4.2 安全与冗余Hypervisor 瘦身、vShield Zones 与访问控制虚拟化环境的安全边界和物理机时代不一样宿主机被攻破上面所有虚拟机都受影响虚拟机在主机之间迁移安全策略如果绑在物理端口上就会失效。方案里对应三条措施。第一条是缩小攻击面控制 hypervisor 的组件数量和补丁面管理接口只开在管理网业务网不暴露管理端口。第二条是策略跟随虚拟机vShield Zones 这类虚拟防火墙的思路是把安全策略绑定到虚拟机而不是物理端口虚拟机迁移时策略一起走这一点在多租户或者分区隔离要求高的场景里很关键。第三条是权限收敛vCenter 按角色分权运维只能操作指定资源池审计日志留存。第三条最容易被忽略也最容易出问题。虚拟化把「一台机器」变成了「一个文件和一个权限」误删虚拟机、误改资源池份额的后果比物理机时代更大。我一般要求生产资源池的操作权限只给到两三个人模板和快照删除走二次确认重要虚拟机加删除保护标记变更前后各拉一次配置快照存档。这些是流程性动作写进方案里显得啰嗦但真出事的时候它就是预防措施。4.3 备份恢复与虚拟应用层Data Recovery 与 vApp 封装备份要解决的是「数据真的能回来」不是「备份任务显示成功」。原文提到的 Data Recovery 是面向中小环境的无代理、基于磁盘的备份恢复方案支持整机恢复和文件级恢复、增量备份与重复数据消除、通过管理平台集中调度。这几个特性对应四个验收点不装代理意味着宿主机层面的批量保护不需要逐台虚拟机改配置文件级恢复意味着误删一个目录不用整机回滚增量加去重意味着备份窗口和存储占用可控集中调度意味着备份策略能按资源池统一下发。需要强调的是快照不是备份。快照是同一个存储卷上的增量文件卷坏了快照一起没而且快照链过长会拖慢 I/O 甚至合并失败。备份和快照在方案里要写成两条独立策略快照只用于变更前置保护和短期回滚保留时间 2472 小时备份用于长期数据保护按天或按周落到独立的备份存储上并定期做恢复演练。虚拟应用程序层是这套架构里容易被当成概念的部分实际价值很实在。vApp 把一台或多台虚拟机、它们的启动顺序、依赖关系、资源策略打包成一个逻辑单元应用交付从「照着文档装三天」变成「导入一个包」。原文提到两条路径应用虚拟化把应用封装成单个或一组文件便于迁移和快速部署应用虚拟设备化把应用和它依赖的运行环境一起做成虚拟机镜像交付用户不需要关心安装过程。需要注意的是这并不意味着所有应用都要改造成 vApp 才能跑在虚拟化平台上传统方式运行的虚拟机照样能跑vApp 只是针对「需要频繁部署、需要保证启动顺序」的那部分应用做的增量优化。写方案时不要把它写成强制要求写成可选的交付方式优化评审时更容易被接受。4.4 异地容灾作为可选项设计边界与预备条件异地容灾在原方案里明确标注为不进入本期实施范围这个处理是对的容灾的投入量级和整合不是一个数量级。但方案里留一节讲清楚技术路径能体现规划完整性。核心思路是虚拟机以文件形式存在、脱离具体硬件所以容灾端不需要预置一模一样的物理服务器只要有一套可用的虚拟化环境和存储复制通道就能在灾备站点恢复业务。具体设计上同步复制能拿到极小的恢复点目标但受限于链路时延通常只适合同城机房异步复制恢复点目标稍大适合远距离。恢复时间目标则取决于灾备端是否有预置的虚拟机、模板和网络配置如果每次都要现场装系统、调注册表恢复时间就没法承诺。常见的做法是在灾备端预先放好模板库和网络配置平常只跑最小规模的验证虚拟机灾难时按预案批量部署。这一节写进方案的价值在于本期不花的钱未来要花在哪里、需要什么前提条件评审方心里有数。4.5 收益口径TCO 怎么算才经得起追问成本收益是方案里最容易被追问的部分也是最容易写得虚的部分。原文给的区间是硬件成本降 28%53%、运营成本降 72%79%、综合成本降 29%64%这些数字来自同类项目统计可以作为目标区间引用但不能直接当成自己项目的结论。我一般把 TCO 拆成四块分别算硬件采购与折旧、机房资源机柜、供电、制冷、软件许可与维保、人力运维工时。前两块用现有机房数据等比推算第三块按宿主机数量而不是虚拟机数量计第四块用「每百台虚拟机所需运维工时」做对比。冗余方式的变化也要算进去。传统双机热备是 2N两套硬件一套干活一套待命虚拟化集群用 N1多备一台宿主机就能给整个集群兜底硬件利用率完全不同。原文提到刀片平台配合虚拟化能节省超过 35% 的运作成本逻辑也是这个减少预制、减少线缆、减少机房占用。这类收益在方案里要写清楚计算过程哪怕只是估算也要让评审方看到公式和假设而不是一堆结论数字。5. 常见问题与排查五个最容易在上线后被翻出来的坑5.1 容量与规划阶段的三个陷阱现象一宿主机 CPU 利用率常年在 30% 以下虚拟机却频繁卡顿、应用超时。原因基本可以锁定在内存和存储整合比只按 CPU 核数算内存做了过度超分宿主机开始用气球驱动回收内存页或者存储卷的 IOPS 被打满虚拟机磁盘队列长度飙升。遇到这种情况先看宿主机的内存 balloon 和 swap 指标再看数据存储的读写延迟。解决方式是把容量模型改成三线取最小值生产资源池内存不超分把 IOPS 预算写进方案并留 30% 余量。我一般在上线前用压测工具跑一轮混合负载把宿主机内存占用压到 80%观察延迟曲线这条经验比任何理论公式都靠谱。现象二集群资源吃紧时管理平台连不上重启管理虚拟机后又恢复。原因多半是管理节点和业务虚拟机混部在同一个资源池业务高峰把资源抢光管理虚拟机被挤到没有资源可用。另一种可能是管理网和业务网共用上行链路业务流量打满导致管理心跳超时。解决办法是管理集群独立、给管理虚拟机配置 CPU 与内存预留、管理网独立网卡独立 VLAN并在 HA 的接入控制策略里给管理资源池保留故障切换余量。现象三规划时按「现在够用」定容量半年后不停加机器整合收益被吃光。原因是没做增长模型和扩容触发条件。方案里应该写明监控指标阈值——集群 CPU 或内存的稳定态超过 70%、数据存储使用率超过 75% 即触发扩容评估扩容按整台宿主机加不做零散加盘。这条写清楚后续预算申请就有依据不会每次都变成临时采购。5.2 运行与变更阶段的三个陷阱现象四把快照当备份用某天数据存储告警一批虚拟机挂起。快照文件在同一个数据存储上卷写满后所有依赖该卷的虚拟机被暂停而且快照链一长合并操作可能失败处理起来非常麻烦。原因是团队把「能回滚」等同于「有备份」。解决方式是把快照策略和备份策略分开写快照保留不超过 72 小时只用于变更前置长期保护走基于磁盘的备份落在独立存储上并且每月抽一台虚拟机做完整恢复演练记录恢复耗时。# 巡检脚本通过 vCenter 拉取所有虚拟机快照找出超过阈值的快照链 from datetime import datetime, timezone from pyVim.connect import SmartConnect, Disconnect from pyVmomi import vim def list_stale_snapshots(host, user, pwd, max_hours72): si SmartConnect(hosthost, useruser, pwdpwd, disableSslCertValidationTrue) content si.RetrieveContent() view content.viewManager.CreateContainerView( content.rootFolder, [vim.VirtualMachine], True) now datetime.now(timezone.utc) for vm in view.view: if not vm.snapshot: continue # 快照树可能有多层逐层取创建时间 stack list(vm.snapshot.rootSnapshotList) while stack: node stack.pop() age_h (now - node.createTime).total_seconds() / 3600 if age_h max_hours: print(f{vm.name}\t{node.name}\t{age_h:.1f}h) stack.extend(node.childSnapshotList) view.Destroy() Disconnect(si)脚本做一件事遍历所有虚拟机把存在超过 72 小时的快照挑出来。max_hours是阈值参数按项目策略调整rootSnapshotList加栈遍历是为了覆盖多层快照链只取根节点会漏掉嵌套快照disableSslCertValidation用在自签证书的实验环境生产环境应换成正规证书校验。这段脚本适合挂在定时任务里每周跑一次输出接到运维群比等人发现存储告警要主动得多。现象五网卡绑定配了双上行拔掉一根网线后业务中断。原因通常是负载均衡策略和交换机侧配置不匹配用了 IP 哈希但交换机没配链路聚合或者两条上行接到了不同交换机却没有做堆叠切换时 MAC 地址表震荡。排查顺序是先看虚拟交换机的策略再看物理交换机端口的聚合配置最后看两条上行是否在同一广播域。解决办法是策略与交换机侧严格对应源端口 ID 平衡最省事IP 哈希必须两端同时配置并做拔线演练。这类问题不演练永远发现不了我一般要求上线验收必须包含拔线测试。现象六虚拟机迁移到某台主机后时间跳变域认证失败、日志时间错乱。原因是宿主机之间没有统一时间源或者主机名与 DNS 正反解不一致导致 HA 代理通信异常。虚拟化环境对时间同步的敏感度比物理机高因为迁移、快照、日志全依赖时间戳对齐。解决方式是把所有宿主机和管理节点指向同一组内网时间源主机名规划好并保证正反解一致纳入入池检查清单新机器加入集群前先跑一遍时间与 DNS 校验。6. 验收与答辩用什么材料证明这套虚拟化方案真的跑起来了验收这件事方案写得再漂亮不如一份能复现的测试记录。我通常按功能、性能、故障、文档四类组织验收材料每一项都要有验证方法和通过标准评审方可以照着抽查。验收项验证方法通过标准资源池与纳管在管理平台查看主机、存储、网络纳管状态全部主机在线无告警配置基线一致vMotion 迁移选中运行中的虚拟机执行迁移同时持续 ping业务不中断丢包为 0 或不超过阈值HA 故障切换对一台宿主机断电观察其上虚拟机虚拟机在其余主机上自动重启恢复时间符合预案存储多路径拔掉一条光纤链路业务持续在线路径自动切换告警上报网络冗余拔掉一条上行网线业务持续在线流量切换至另一条链路备份与恢复抽取一台虚拟机做整机恢复和文件级恢复数据完整恢复耗时记录在案快照巡检运行巡检脚本无超过策略阈值的快照输出可追溯文档交付查配置基线、拓扑图、操作手册、应急预案与实际环境一致变更记录完整答辩或评审时最容易被问的是三个问题整合比怎么来的、可用性为什么这么分级、成本收益怎么算。前两个问题靠第 2 章和第 4 章的矩阵回答第三个问题靠 TCO 的四块拆分回答。准备材料时把这三点做成一页纸比堆二十页截图有效。另外把故障演练的记录放进去——拔电、拔线、快照恢复各一次附上时间线和监控曲线这类证据的说服力远高于文字描述。很多方案被质疑「纸上谈兵」缺的不是技术深度是这类可复现的现场记录。从那以后我每次做虚拟化项目验收前都强制走一遍「拔线拔电」演练哪怕评审不要求。因为配置对不对只有真的断一次才知道方案稳不稳只有真的恢复一次才敢交。希望这套结构能帮到你把你手上的那份方案补齐到可以交付的状态。本文还有配套的精品资源点击获取
