3. 虚拟化平台架构设计
虚拟化平台的架构设计，本质上是在物理硬件与虚拟机之间建立一套可预测、可治理的资源供给体系。Lenovo ThinkSystem 服务器配合 VMware vSphere 或联想问天虚拟化平台时，架构设计需要同时回答四个问题：计算、存储、网络三层如何分层规划；故障发生时如何保证业务连续；资源如何按业务属性划分池；未来扩容时如何避免推倒重来。本节围绕这四个问题展开，并给出可落地的规划方法与示例参数。
一、三层架构的分层规划
三层架构的核心思想是“每层只解决自己的问题，层间通过标准接口衔接”。计算层负责 CPU 与内存的抽象和调度，存储层负责数据持久化与性能供给，网络层负责虚拟机流量、存储流量和管理流量的隔离与转发。三层各自独立扩展，避免某一层的瓶颈直接拖垮整体。
计算层规划的关键是“按集群而非按单机”设计。以 ThinkSystem SR650 V3 为例，双路 CPU、每路 32 核、512GB 内存，单机可提供 64 物理核心与 512GB 内存。规划时先确定 CPU 超分比与内存超分比：生产核心业务通常 CPU 超分比控制在 4:1 以内、内存不超分；测试与开发环境可放宽到 8:1 与 1.5:1。假设某集群需要承载 200 台虚拟机，平均每台 4 vCPU、16GB 内存，则所需物理资源为：CPU 200×4÷4=200 核，内存 200×16=3200GB。按单机 64 核、512GB 计算，至少需要 4 台计算节点（256 核、2048GB）——内存不足，因此实际需 7 台（448 核、3584GB），并预留 1 台作为 N+1 冗余，最终 8 台。这个计算过程说明：内存往往是计算层的真实约束，而非 CPU。
存储层规划要区分“容量”与“性能”两条线。容量线按可用容量、副本或 RAID 开销、快照预留三部分计算；性能线按 IOPS 与时延要求反推磁盘数量。以 vSAN 为例，若业务要求 20000 IOPS、读写比 7:3、单块 NVMe 可提供 80000 IOPS，则理论最少 1 块即可满足，但考虑故障域与均衡，通常每个节点配置 2 块缓存盘加 4 块容量盘。容量方面，若需 20TB 可用空间、FTT=1（允许 1 个节点故障），则原始容量需 20×2=40TB，再叠加 20% 余量，约 48TB。存储层还应明确“缓存层用 NVMe、容量层用 SSD 或 HDD”的分层策略，避免用大容量 HDD 承载高 IOPS 业务。
网络层规划的核心是流量分离。管理流量、vMotion 流量、存储流量、虚拟机业务流量应使用不同 VLAN 或不同物理网卡。ThinkSystem 服务器通常配置 4 个 25GbE 端口，建议 2 个用于业务与 vMotion 绑定，2 个用于 vSAN 或 iSCSI 存储，管理口单独使用 1GbE。这样即使业务流量突发，也不会挤占存储心跳，避免 vSAN 因时延抖动被误判为故障。
二、高可用与容灾设计原则
高可用解决的是“单点故障不中断业务”，容灾解决的是“站点级故障可恢复”。两者目标不同，设计手段也不同，不能混为一谈。
高可用的第一原则是消除单点。计算侧启用 vSphere HA 与 DRS，HA 负责节点故障后虚拟机自动重启，DRS 负责负载均衡；存储侧 vSAN 采用 FTT=1 或 FTT=2，保证 1 到 2 个节点故障时数据不丢失；网络侧使用双上行链路与 LACP 绑定，避免单交换机或单网卡故障。第二原则是“冗余要能被验证”，即定期执行故障演练：手动关闭一台节点，观察虚拟机是否在 5 分钟内完成重启、vSAN 是否进入降级但可用状态、业务时延是否在可接受范围。第三原则是“心跳与隔离”，HA 的隔离响应应设置为“关闭并重启虚拟机”，避免脑裂导致同一虚拟机被两台主机同时运行。
容灾设计遵循“RTO/RPO 决定技术选型”。若 RTO 要求 30 分钟、RPO 要求 15 分钟，可采用 vSphere Replication 做异步复制，配合 SRM 编排恢复；若 RTO 要求接近 0、RPO 接近 0，则需要双活存储或 vSAN 延伸集群，但后者对跨站点时延有严格要求，通常要求站点间 RTT 小于 5ms、带宽不低于 10Gbps。容灾方案必须明确“切换条件”与“回切条件”，例如主站点存储不可用超过 10 分钟即触发切换，主站点恢复后需经数据一致性校验再回切。
三、资源池划分策略
资源池划分不是简单地把主机分组，而是把“业务等级”映射为“资源约束”。建议按业务重要性划分三类池：生产核心池、一般业务池、测试开发池。生产核心池绑定专用集群，CPU 超分比不超过 4:1，内存不超分，并启用资源预留；一般业务池可共享集群，CPU 6:1、内存 1.2:1；测试开发池允许更高超分，但需设置上限，防止测试负载挤占生产资源。
划分时还要考虑“故障域”与“维护域”。同一池内的主机应分布在不同机柜、不同 PDU、不同上行交换机，避免单机柜断电导致整池失效。维护域则用于滚动升级：每次只将一台主机置入维护模式，其余主机仍有足够资源承载全部虚拟机。以 8 节点集群、N+1 冗余为例，单节点维护时剩余 7 节点需承载原 8 节点负载，因此资源水位应控制在 85% 以内。
四、可扩展性考量
可扩展性要在设计初期就预留三类空间：机架空间、网络端口、存储容量。机架空间按“当前节点数 + 未来 2 年增长”预留，例如当前 8 节点，机架应预留 16U 以上；网络端口预留至少 20% 的空闲端口，便于新增节点时无需更换交换机；存储容量按年增长 30% 估算，并预留一个可热插拔的磁盘槽位。
扩展方式上，优先选择“横向扩展”而非“纵向扩展”。横向扩展通过增加节点提升整体能力，同时天然增强冗余；纵向扩展受单机上限约束，且扩容时往往需要停机。以 vSAN 为例，新增节点后集群自动重新均衡数据，无需停机；而传统集中式存储扩容控制器则可能涉及停机窗口。因此，架构设计应尽量选择支持在线横向扩展的技术路线。
综合来看，三层架构规划解决“资源怎么给”，高可用与容灾解决“故障怎么办”，资源池划分解决“给谁用、给多少”，可扩展性解决“以后怎么加”。四者共同构成虚拟化平台架构设计的完整闭环，也是后续部署与运维阶段判断配置是否合理的基准。