vSAN Sizing与集群配置实战：容量计算、磁盘组与故障域指南-平芜编程栈

简介：VMware官方发布的《VSAN设计与Sizing指南》是一份针对Virtual SAN 6.0的设计与容量规划文档，面向IT基础架构师、虚拟化管理员及存储规划人员，用于解决VSAN环境设计、容量预估与性能优化问题。资源共1个PDF文件，压缩包约959KB，内容紧凑，目录结构清晰，便于按需检索。文档系统覆盖了健康服务、VSAN就绪节点、EVO:RAIL、兼容性指南（VCG）遵循、集群生命周期管理、容量规划、故障域设计、监控与调优等关键主题，并给出混合与全闪存架构的差异对比及VSAN配置限制；从基础架构选型、容量估算到维护与可用性均有完善指引。已有83人学习下载，适合需要系统掌握VSAN设计原则、规避部署风险并制定高可用存储方案的读者。

1. 新主机已进vSAN集群却报未启用服务：这份指南到底在解决什么

机架里四台新到的存储节点，加进 vSAN 集群耗了半小时，vSphere Client 的主机状态列却挂着一行提示：“主机位于 vSAN 集群中，但尚未启用 vSAN 服务”。业务那边在催着上线，集群容量按三副本算出来的数字又总觉得不踏实——这就是 vSAN 设计和 Sizing 的日常。标题里这份指南想解决的问题只有两个：第一，集群容量、磁盘组、故障域、存储策略这些参数怎么按业务算出来，而不是拍脑袋；第二，算完之后怎么把主机真正“启用”进 vSAN，并验证整个集群是健康的。这份东西适合正在规划 vSAN 采购、扩容，或者刚把硬件搬进机柜准备上线的存储与虚拟化工程师。

2. vSAN Sizing 先算容量：三副本开销、闪存缓存比例和磁盘组数量怎么定

2.1 先看懂 vSAN 怎么“吃”磁盘：对象、组件与副本的最小单位

vSAN 不是一个传统意义上的共享存储，它把每台 ESXi 主机上的本地磁盘聚合成一个分布式存储池。上层虚拟机看到的是一个标准数据存储，但底层的数据存放逻辑跟传统 RAID 完全不同。

一台虚拟机的 VMDK 在 vSAN 里被抽象成一个对象（Object）。这个对象会被拆成一个或多个组件（Component），再按存储策略把组件复制多份，分散放在集群里的不同主机上。如果策略要求一份数据存两份（FTT=1，镜像模式），vSAN 会把这个对象的组件复制成两份副本，并额外生成一个见证组件（Witness）来协调故障场景下的数据一致性。

这部分对 Sizing 的意义在于：vSAN 消耗的容量不是简单的“虚拟机磁盘大小 × 2”。组件拆分、条带化、见证组件、元数据都会吃掉一部分空间。见过不少第一次做 vSAN 规划的人，拿着“单台 VM 500GB × 50 台 VM × 2 副本 = 50TB”这个算法去采购，结果磁盘组和故障域配出来根本放不下，或者放得下但容量告警。要算准，必须先理解组件模型。

2.2 容量公式：从原始容量到可用容量的三段计算

在做 vSAN Sizing 时，我习惯把容量计算拆成三段，每一段都有明确的公式和修正系数。

第一段是原始容量。原始容量 = 每台主机的容量盘数量 × 单盘容量 × 集群主机数量。比如 4 台主机，每台塞 6 块 1.92TB 的 SSD，原始容量就是 4 × 6 × 1.92 ≈ 46TB。

第二段是副本开销。默认存储策略 FTT=1、RAID-1 镜像时，数据实际写两份，容量可用率是 1/2。FTT=2 时写三份，可用率 1/3。如果后续改用 RAID-5 或 RAID-6，容量利用率会不一样，后面会单独说。

第三段是系统开销。vSAN 要为元数据、对象布局、快照暂存、各种内部操作保留一部分容量。这个值按经验大约占原始容量的 5% 到 10%。加上运维上通常希望集群容量使用率不超过 80%，我一般直接在公式里乘一个 0.85 到 0.9 的系数。

完整估算公式是：

可用容量 ≈ 原始容量 ÷ (FTT + 1) × 0.9

举一个实际算例。4 主机，每主机 6 块 1.92TB 容量盘，FTT=1 镜像模式：

原始容量 = 4 × 6 × 1.92 ≈ 46TB
副本开销后 = 46 ÷ 2 ≈ 23TB
扣除系统余量 = 23 × 0.9 ≈ 20.7TB

也就是说，这 46TB 的裸盘量，真正能拿来放虚拟机数据的，大约 20TB 出头。如果你把这个误解成 46TB 可用，那虚拟化平台上线后的第二个月就会收到容量告警。

不同容错策略下的容量开销值得有个对比，规划时可以拿来做取舍：

存储策略	最小主机数	数据组件分布	容量开销	可用容量占比
RAID-1，FTT=1（默认）	3	2 副本 + 1 见证	2 倍	约 50%
RAID-1，FTT=2	5	3 副本 + 1 见证	3 倍	约 33%
RAID-5，FTT=1	4	3 数据 + 1 奇偶校验	1.33 倍	约 75%
RAID-6，FTT=2	6	4 数据 + 2 奇偶校验	1.5 倍	约 66.7%

RAID-5 和 RAID-6 在主机数量允许的情况下，容量优势非常明显。但它们的重建代价和性能抖动比镜像更值得关注，后面章节会展开。

闪存缓存盘的容量也必须进入 Sizing 的计算。全闪存 vSAN 中，每个磁盘组需要一块 SSD/NVMe 作缓存盘，缓存盘容量建议不低于该磁盘组内容量盘总容量的 10%。如果某个磁盘组挂了 6 块 1.92TB 容量盘，组容量约 11.5TB，那缓存盘至少要配 1.2TB 级别，实际项目中常见的组合是 1.6TB 缓存盘配 6 块 1.92TB 容量盘。

2.3 FTT 与 FTM 选型：镜像、纠删码在不同主机规模下的取舍

FTT（Failures to Tolerate）决定集群能容忍几台主机同时故障，FTM（Failure Tolerance Method）决定用什么机制去实现这个容忍度。vSAN 提供了 RAID-1 镜像、RAID-5、RAID-6 三种数据放置方式，选哪个不只看容量，还要看主机数量和业务负载类型。

镜像模式是最保守也最通用的方案。RAID-1 FTT=1 只需要 3 台主机，所有虚拟化负载都能跑，性能衰减最小，缺点是容量利用率低。如果业务对性能敏感、数据量不大，这是最省心的起点。

RAID-5 需要至少 4 台主机，数据组件 3 份加 1 份奇偶校验，用 1/3 的额外空间换来比镜像高得多的可用容量。代价是写操作需要计算校验值，随机写性能比镜像差。适合测试开发环境、VDI 桌面池这类读多写少、对容量成本敏感的负载。

RAID-6 需要至少 6 台主机，数据组件 4 份加 2 份奇偶校验，可以容忍任意两台主机同时故障，容量利用率 66.7% 远好于镜像 FTT=2 的 33%。但 RAID-6 的写放大最严重，对磁盘 IO 压力大的业务需要谨慎。

这里有个常见的翻车典型：集群只有 3 台主机，业务方却要求用 RAID-5 策略来省容量，最后虚拟机根本无法放置，因为 RAID-5 的最低主机数就是 4。在选择 FTT/FTM 之前，先把主机数量清点清楚，别让策略白设在虚拟机上。

3. 从容量到拓扑：vSAN 集群设计里的磁盘组与故障域规划

3.1 磁盘组：一块缓存盘加最多七块容量盘的组装规则

磁盘组是 vSAN 的基本故障单元和性能单元。一个磁盘组由一块缓存盘和一到七块容量盘组成，缓存盘负责承接写缓存和读缓存，容量盘负责数据落盘。这些年版本的 vSAN 中，每台主机最多支持 5 个磁盘组，每个磁盘组最多 7 块容量盘。

这里有一个必须理解的约束：如果磁盘组里的缓存盘坏了，整个磁盘组会变成不可用状态，组内所有容量盘的数据都需要从其他副本重建。缓存盘承担的风险比容量盘大得多，这就解释了为什么缓存盘要选高耐久度、高随机写性能的企业级 SSD，而不是拿消费级固态凑数。

磁盘组数量直接影响 vSAN 的性能上限。常见做法是先把每台主机的磁盘按“一个磁盘组”起步，等验证稳定了再加第二个磁盘组。每主机的磁盘组数增加，数据条带化的范围就越广，单台主机的 IO 吞吐能力也随之提升，但组件数量和元数据开销同样上升。

磁盘组里缓存盘与容量盘的比例，直接改的是整个集群的写缓存预算。全闪存架构下，缓存盘容量应为所在磁盘组容量盘总容量的 10% 左右，业界普遍按这个口径采购；如果业务是强写入场景，比如数据库日志盘、交易系统，这个比例提到 15% 到 20% 更保险。混合架构下，SSD 缓存与 HDD 容量的比例通常按 1:10 到 1:15 来配，但混合架构本身已经在逐渐退出主流选择。

3.2 故障域：跨机架冗余的边界条件

故障域是 vSAN 在主机之上引入的逻辑容错单位，告诉 vSAN“哪些主机物理上挨在一起、可能同时断电或断网”。最常见的划分方式是让一个机架上的所有主机属于同一个故障域。vSAN 在放置数据副本时，会尽量让多个副本分散到不同故障域，从而避免一个机架断电导致全部副本同时丢失。

这个机制的约束条件也很明确：故障域数量必须大于或等于 FTT + 1。简单说，FTT=1 至少要 2 个故障域，FTT=2 至少要 3 个故障域。实际落地时，可靠的规划通常是故障域数量等于 FTT + 2，留出一个故障域作为重建空间。

故障域规划跟主机数量强关联。比如一个集群有 6 台主机分布在 2 个机架，每个机架一个故障域、各 3 台主机。这时候如果把策略设为 FTT=2，理论上需要 3 个故障域，但实际只有 2 个，vSAN 无法满足策略要求，虚机策略校验会直接报错。正确的做法是给 6 台主机划分 3 个故障域、每个故障域 2 台主机，FTT=2 才能成立。

还要注意故障域设计的粒度：故障域数量少，容错粒度粗，数据可能集中落在少数几个故障域，性能容易出现热点；故障域数量多到每台主机一个，容错粒度最细，但无法抵御“一个机架断电”这类物理风险。怎么权衡，取决于你的机房物理布局和业务能承受的故障半径。

3.3 全闪存与混合架构的选择：延迟预算和成本线的交点

vSAN 的硬件架构有两条路线：全闪存（SSD 缓存盘 + SSD 容量盘）和混合（SSD 缓存盘 + HDD 容量盘）。区别不只在性能，更在 Sizing 的算法上。

全闪存架构下，vSAN 可以跑出亚毫秒级延迟。容量盘和缓存盘都是闪存介质，随机 IO 性能高，数据重建快，适合承载数据库、生产业务虚拟机。这是当前绝大多数新建 vSAN 集群的选择。混合架构使用 HDD 作为容量盘，成本低、容量大，但延迟在 5ms 到 10ms 量级，随机写性能受 HDD 寻道限制明显。

网络带宽是 vSAN 选型时最容易被低估的一环。全闪存 vSAN 强烈建议使用 10Gbps 或更高带宽的业务网络，混合架构虽然可以跑在千兆网上，但重负载时的性能会很不稳定。曾经接触过一套混合架构跑在千兆网络上的集群，主机间数据重建一启动，业务 IO 延迟直接飙升到不可接受。

在 Sizing 阶段把两者放在一张表里对比，决策会清晰很多：

维度	全闪存	混合
典型延迟	0.5 - 1ms	5 - 10ms
随机写性能	高	受 HDD 限制
推荐网络	10Gbps 起	1G 可用，建议 10G
每 GB 成本	高	低
适用负载	生产数据库、关键业务 VM	归档、备份、容量型业务

实际项目里，混合架构如今更多被用于容量敏感、性能不敏感的场景。如果预算紧张到只能上混合架构，那 Sizing 时对容量盘的转速、数量，以及缓存盘的写寿命都要做更保守的估计。

4. 把设计落进 vCenter：主机启用 vSAN、建磁盘组与存储策略的完整动作

4.1 启用 vSAN 服务前的主机检查项

Sizing 算完，接下来是把规划数字变成 vCenter 里的实际配置。在点“启用 vSAN”之前，按下面清单过一遍，能省掉之后大量排错时间。

第一，确认主机已经加入 vSAN 集群，且集群层面的 vSAN 开关处于关闭状态。vSAN 集群的启用动作会直接影响集群内所有主机，所以这个动作要放在业务低峰期做。

第二，确认磁盘控制器模式。vSAN 要求容量盘使用直通模式（Passthrough）或 RAID-0 单盘模式，不能是 RAID5 或 RAID10 阵列。很多服务器出厂默认把磁盘配成 RAID1 或 RAID5，不改成直通或 RAID-0，vSAN 根本认不到盘。检查命令是vdq -q，它会列出所有可以被 vSAN 使用的磁盘设备。

第三，确认磁盘是干净的。vSAN 启用时会格式化磁盘分区，如果磁盘上还有旧分区或旧数据，可能导致格式化失败或者误删数据。每块容量盘在加入前检查一下分区状态。

第四，确认网络就绪。vSAN 流量建议走独立 VLAN 和独立物理网卡，MTU 9000 的所有节点保持一致。如果混合网络存在丢包，vSAN 对象可能会出现健康告警。

4.2 在 vCenter 里把磁盘组和存储策略配上

检查项通过后，开始真正的配置动作。以 vSphere Client 操作为例，步骤如下。

先启用集群的 vSAN 服务。进入集群的“配置”页，找到 vSAN → 服务，点击启用。此时 vSAN 会为集群中每台主机激活 vSAN 功能，如果主机此前没有被加入到任何 vSAN 集群，这一步会触发 vSAN 的初始化。启用后，回到主机清单页，主机的 vSAN 状态列会从“未启用”逐渐变成“运行中”。

创建磁盘组。进入任意一台主机的“配置”页，找到 vSAN → 存储，点击“创建新磁盘组”。勾选一块缓存盘和同组的容量盘，确认缓存盘容量不低于组内容量盘总容量的 10%。我习惯先给每台主机建一个磁盘组，等集群性能和容量验证通过，再考虑增加第二个组。

配置存储策略。vSAN 的数据放置规则由虚拟机存储策略控制。在 vSphere Client 的“策略和配置文件”中新建一个存储策略，添加规则时选择 vSAN，然后设置 FTT、FTM、条带化数量等参数。默认策略建议 FTT=1、RAID-1、条带化 1，这适合大多数虚拟化负载。

把策略关联到虚拟机。新建虚拟机时选择“虚拟机存储策略”为刚才创建的策略，或在已有虚拟机上做“更新虚拟机的存储策略兼容性”。这一步容易被漏掉，因为如果虚拟机用了“基于存储空间最大可用”这类非 vSAN 策略，vSAN 的健康检查会一直报警。

4.3 命令行验证：esxcli 下确认 vSAN 状态的三条命令

图形界面操作完成后，我会再用命令行做三次验证，确认 vSAN 真正处于健康状态。这三条命令在所有 ESXi 主机上都有，是排查 vSAN 问题时最常用的三个路口。

第一条是查看主机与 vSAN 集群的隶属关系：

esxcli vsan cluster get

输出里的Cluster Config Status字段是关键。如果显示Configured，说明主机已经作为 vSAN 集群成员工作正常；如果显示Not Configured或者主机声称“在集群中但未启用”，那问题就出在这一层。

第二条是检查每块磁盘在 vSAN 中的参与状态：

esxcli vsan storage list

这个命令会列出主机上所有已加入 vSAN 的磁盘设备，包含缓存盘和容量盘各自的状态、所属磁盘组、设备 UUID。重点看Device State是否为Enabled，以及容量盘是否被正确归入某个磁盘组。

第三条是触发一次 vSAN 健康检查：

esxcli vsan health cluster list

它会返回一系列健康检查项的结果，包括磁盘级健康、网络级健康、对象级健康。如果有任何一项返回Warning或Error，需要先解决再继续上一线业务。健康检查的响应时间取决于集群规模，大型集群可能耗时几分钟，这是正常现象。

5. 避坑：主机显示“尚未启用 vSAN 服务”与其它四个 Sizing 翻车现场

5.1 现象：主机已在 vSAN 集群，状态列却挂“尚未启用 vSAN 服务”

这是标题里那个热词对应的实际场景。vSphere Client 主机清单里，主机确实在 vSAN 集群中，但 vSAN 状态那一列写的是“主机位于 vSAN 集群中，但尚未启用 vSAN 服务”。

原因通常有三种。第一种是集群级的 vSAN 服务根本没有打开，主机被加进集群了，但 vSAN 开关没点，所有主机都处于这个状态。第二种是主机加入集群时 vSAN 服务正在启动中，主机的 vSAN 代理进程没有完成注册。第三种是主机时间与集群其他节点不同步，导致 vSAN 的握手认证失败。

解决路径也是按这个顺序来。先到集群的“配置 → vSAN → 服务”确认 vSAN 已启用；如果已启用但主机还是这个状态，在主机上执行esxcli vsan cluster get看配置状态；如果依然异常，检查主机和 vCenter 的 NTP 时间校准，并把主机在集群中移除再重新加入一次。最简单高效的后悔药就是这步重启操作，多数情况都能拉回来。

5.2 现象：Sizing 按三副本算好，集群却报容量不足

规划时明明按“所有 VM 总容量 × 2”算好了三副本需求，实际启用后 vSAN 却警告容量不足。

原因是容量计算里漏掉了三块隐性开销：元数据、快照暂存和条带化产生的组件存储。vSAN 里的每个对象都包含元数据信息，每台主机还有本地的 vSAN 内部数据管理结构，这些会占用一部分真实容量。快照在 vSAN 中不是只存变更块，而是可能触发新组件的创建。条带化如果设置大于 1，每个条带成员都是独立组件，组件数量增多，元数据开销也成比例增加。

解决方法是把容量估算公式从“可用 = 原始 ÷ 2”改成“可用 = 原始 ÷ (FTT+1) × 0.9”，并且在实际使用中维持集群容量告警阈值在 80%。宁可前期多留 15% 的空余容量，也不要等业务虚拟机无法迁移时才去做紧急扩容。

5.3 现象：全闪存用了小容量缓存盘，业务高峰期 IO 延迟飙升

全闪存 vSAN 集群在监控里看到延迟从平时的 0.8ms 突然跳到 10ms 以上，而且集中在业务高峰期。

原因是缓存盘容量配得太小。vSAN 使用缓存盘做写入缓冲和读缓存，如果缓存盘容量不足，写入的数据会很快被迫刷到容量盘，读缓存的命中率也随之下降。当所有虚拟机同时争抢有限的缓存空间时，缓存盘本身还没瓶颈，容量盘的写放大和读放大先一步拖垮了整个磁盘组。

解决方法是回到缓存比例的规划。缓存盘容量按“所在磁盘组容量盘总容量的 10%”作为下限，强写入负载直接按 15% 到 20% 配。另外要检查单台主机的磁盘组数量，如果是多个磁盘组共用一个缓存盘，那缓存容量完全不够，需要重新规划磁盘组。

5.4 现象：三主机集群选了 RAID-5 策略，虚拟机无法放置

以为 RAID-5 能省容量，改成 RAID-5 FTT=1 策略后，虚拟机创建时提示“策略要求的主机数量不足”或“虚拟机无法放置”。

原因是 vSAN 的 RAID-5 要求至少 4 台主机。3 台主机上数据组件 3 份加奇偶校验 1 份，物理上根本没有第 4 个位置可以放置校验组件。vSAN 的策略合规检查会直接拒绝放置。

解决方法是两条路。如果集群短期内无法扩到 4 台主机，把策略改回 RAID-1 FTT=1，接受 50% 的容量利用率。如果确实需要 RAID-5 的容量优势，就加一台主机，这是最直接的硬性条件。

5.5 现象：故障域数量不足 FTT+1，策略校验始终报错

集群总容量够、主机数量也够，但存储策略校验一直报“故障域数量不足”。

原因是没有在主机层面配置故障域，或者配置的故障域数量少于 FTT + 1。vSAN 在放置数据副本时，会强制要求副本落在不同的故障域里。比如集群 5 台主机，没有划分故障域时每台主机算一个故障域，FTT=2 需要至少 3 个故障域，就满足条件；但如果把 5 台主机塞进了 2 个故障域，FTT=2 的策略就永远无法放置。

解决方法是重新规划故障域划分。先在 vSphere Client 的“集群配置 → vSAN → 故障域”里确认当前故障域数量和主机归属，再按“故障域数量 ≥ FTT + 1”的原则调整。机架物理布局允许的话，直接把故障域数量做到 FTT + 2，故障重建时留出冗余空间。

6. Sizing 做完后怎么验收：容量健康检查与一张落地检查单

Sizing 和配置工作收尾时，我习惯用一套固定的验收流程，把规划数字和实际状态对齐。先跑一遍 vSAN 健康检查，在集群的“监控 → vSAN → 健康”里查看对象健康、容量健康、网络健康三个大类。如果容量健康显示“已用容量与总容量比例”接近或超过预估的 80%，就要回头核对实际的磁盘组和缓存配比。

然后找一台测试虚拟机做真实的容量占用验证。给测试 VM 分配一块固定大小的厚置备虚拟磁盘，迁移到 vSAN 数据存储上，再去 vSAN 的“容量”页面观察物理占用是否与“磁盘大小 ÷ 容量利用率”的预期一致。厚置备 VMDK 在 vSAN 上的实际占用应当是虚拟磁盘大小乘以策略的容量开销，误差超过 10% 就说明哪里算错了。

最后按下面这张检查单逐项走一遍，走完就敢把集群交给业务了：

检查项	预期状态	异常处理
主机 vSAN 状态	所有主机“运行中”	主机重建 vSAN 服务
磁盘组数量	每主机至少 1 组	查缓存盘容量比例
缓存盘容量	≥ 磁盘组容量盘总量 10%	扩容缓存盘
存储策略	虚拟机与策略兼容	重建策略并重新关联
故障域数量	≥ FTT + 1	重新划分故障域
MTU / VLAN	全部节点一致	一致性排查