VSAN 设计与 Sizing 实战：容量、性能与故障域计算指南

简介：《VSAN设计与Sizing指南》是VMware官方发布的Virtual SAN 6.0技术文档，面向虚拟化架构师、存储工程师及IT运维人员，用于指导VSAN环境的设计规划与容量预估，帮助读者在部署前理清兼容性、性能与可用性之间的平衡关系。资源包为单一PDF文件，共1个文件，压缩包约959KB，内容完整涵盖健康服务、就绪节点、EVO:RAIL、集群生命周期管理、容量规划、维护与可用性、性能考量、成本效益分析、故障域设计及监控调优等核心章节。文档从VCG兼容性指南、vSphere版本支持、平衡配置等设计概览切入，逐步展开混合与全闪存差异、VSAN各项上限及ESXi主机数量要求，并给出容量、维护与可用性的Sizing方法。目前已有83人学习，适合需要系统掌握VSAN设计要点、对照官方建议完成方案选型与容量测算的读者参考。

1. VSAN 设计和 Sizing 到底在解决什么问题

很多人第一次接触 VSAN 设计和 Sizing，是在一台台物理服务器已经上架、硬盘已经插满、交换机已经配好之后，才被问一句：这套集群到底能扛多少虚拟机、能剩多少可用容量、故障时还能不能撑住。这时候再回头算，往往已经晚了。VSAN 不是把本地盘简单聚合起来就完事，它是一套把计算、存储、网络耦合在一起的分布式存储方案，设计和 Sizing 的核心，是在业务上线前把容量、性能、故障域三件事同时算清楚。

这份指南面向的是准备落地或正在扩容 VSAN 集群的工程师，尤其是手里只有几台服务器、预算有限、又不想在故障时翻车的人。它要回答的不是“VSAN 是什么”，而是“我这套硬件到底该怎么配、每台放几块盘、预留多少余量、故障后还剩多少可用空间”。把这些算明白，后面调参数才有意义。

2. 先把 VSAN 的容量账算清楚：从原始盘到可用空间

VSAN 的 Sizing 之所以容易算错，是因为从物理盘到虚拟机真正能用的空间，中间要经过好几层扣减。很多人只看了硬盘标称容量，结果上线后发现可用空间只有预期的一半。这一章把这条链路拆开，每一步都给出可复现的算法。

2.1 从物理盘到存储池：容量扣减的四个环节

一块 1.92TB 的 SSD，装进 VSAN 磁盘组之后，并不会以 1.92TB 参与可用容量计算。常见做法是按下面这条链路逐层扣：

也就是说，一块标称 1.92TB 的盘，在 FTT=1、双副本策略下，真正能承载虚拟机数据的部分，往往只有 800GB 上下。这个数字不是玄学，是每一层扣减叠加出来的结果。设计时如果按标称容量乘以盘数再除以二，最后一定会发现空间不够。

计算可用容量的常见公式是：单盘有效容量 = 标称容量 × 0.93（十进制转二进制）× 0.98（元数据保留）；集群原始有效容量 = 单盘有效容量 × 数据盘数量；再除以副本数，得到可承载虚拟机数据的容量。这个公式不追求绝对精确，但能让你在选型阶段就避开数量级错误。

2.2 用脚本把容量账算成一张表

手工算容易漏项，我一般会写一个小脚本，把每台主机的盘数、盘型、策略都代进去，直接输出可用容量和余量。下面这段 Python 就是按上面公式实现的，参数可以按自己集群改。

# vsan_capacity.py # 按磁盘组配置估算 VSAN 可用容量 # 输入：每台主机数据盘数量、单盘标称容量(TB)、主机数、副本数、预留比例 def usable_capacity(disks_per_host, disk_tb, hosts, replicas, reserve=0.10): # 十进制转二进制 + 元数据保留 effective_per_disk = disk_tb * 0.93 * 0.98 raw = effective_per_disk * disks_per_host * hosts # 除以副本数得到可承载数据量 usable = raw / replicas # 再扣掉预留（快照、交换文件等） usable_after_reserve = usable * (1 - reserve) return { "raw_tb": round(raw, 2), "usable_tb": round(usable, 2), "usable_after_reserve_tb": round(usable_after_reserve, 2), } if __name__ == "__main__": # 4 台主机，每台 4 块 1.92TB 数据盘，FTT=1 双副本，预留 10% result = usable_capacity(disks_per_host=4, disk_tb=1.92, hosts=4, replicas=2) print(result)

这段脚本的关键参数有三个：replicas对应 VSAN 存储策略里的 FTT，FTT=1 就是 2 副本，FTT=2 就是 3 副本；reserve是给快照、交换文件和临时对象留的余量，生产环境一般不低于 10%，跑数据库或大量快照的场景要提到 20% 以上；disk_tb用标称容量即可，脚本内部已经做了十进制转二进制的折算。跑出来的usable_after_reserve_tb才是你真正能分配给虚拟机的容量上限。

提示：这个脚本算的是稳态容量，不包含磁盘组重建时的临时占用。重建期间 VSAN 需要额外空间做再平衡，实际可用会比算出来的再低一些，设计时留 15% 以上余量比较稳妥。

2.3 副本数和故障域怎么影响最终可用空间

副本数不是随便定的，它直接决定容量利用率和故障容忍度。FTT=1 时两副本，容量利用率约 50%；FTT=2 时三副本，利用率降到约 33%。如果集群跨机架或跨故障域，VSAN 还会要求副本分布在不同故障域，实际可用空间可能进一步下降。

常见做法是：对容量敏感、可容忍单点故障的业务用 FTT=1；对核心数据库、不能丢数据的业务用 FTT=2，但要在 Sizing 阶段就把这部分容量单独算出来，不要和普通业务混在一起估。故障域数量也要提前规划，三个故障域是 FTT=2 能正常工作的下限，两个故障域时 FTT=2 无法满足放置规则，集群会报错。

3. 性能 Sizing：磁盘组、缓存盘和网络怎么配才不拖后腿

容量算完只是第一步，VSAN 的性能瓶颈往往不在数据盘，而在缓存盘和网络。这一章讲清楚磁盘组怎么组、缓存盘选多大、网络怎么配，以及怎么用最小成本验证配置是否够用。

3.1 磁盘组里缓存盘和数据盘的比例

VSAN 的磁盘组由一块缓存盘和多块数据盘组成。缓存盘承担写入缓冲和读缓存，数据盘负责持久化。常见做法是缓存盘容量占磁盘组总容量的 10% 左右，但这个比例不是硬性规定，关键看写入负载。

如果业务以随机写为主，比如数据库、虚拟桌面，缓存盘要选高耐久、高 IOPS 的 NVMe 或企业级 SSD，容量可以按数据盘的 10%-15% 配。如果业务以顺序读为主，比如文件服务器、备份归档，缓存盘比例可以低一些，但也不能低于 5%，否则写入放大后缓存很快被打满，性能会断崖式下跌。

一个磁盘组里数据盘数量建议控制在 5-7 块。太少则单盘故障影响大，太多则重建时间长、缓存盘压力集中。每台主机通常配 1-2 个磁盘组，具体看主机盘位和控制器队列深度。

3.2 用 fio 在单机上验证磁盘组性能

配置完磁盘组后，不要直接上生产，先用 fio 在单台主机上跑一轮基准测试，确认 IOPS 和延迟在预期范围内。下面这条命令模拟 4K 随机写，是 VSAN 最典型的压力场景。

# 在 ESXi 主机的本地数据盘上跑 4K 随机写基准 # 需要先在一台虚拟机上挂载测试盘，或使用 VSAN 提供的性能测试工具 fio --name=randwrite --ioengine=libaio --direct=1 \ --bs=4k --size=10G --numjobs=4 --rw=randwrite \ --iodepth=32 --runtime=120 --time_based \ --group_reporting --output-format=json

参数说明：bs=4k对应数据库和虚拟桌面最常见的块大小；iodepth=32模拟多队列并发，VSAN 环境下队列深度不足会低估实际性能；numjobs=4模拟多虚拟机并发；direct=1绕过文件系统缓存，测的是真实磁盘性能。跑完后重点看iops和latency两个字段，如果 4K 随机写 IOPS 低于单盘标称值的 60%，说明缓存盘或控制器可能成为瓶颈。

注意：fio 测试会占用磁盘带宽，不要在业务高峰期跑。测试盘最好单独挂载，不要和 VSAN 数据盘混用，否则测试结果会被 VSAN 后台任务干扰。

3.3 网络带宽和 MTU 的取舍

VSAN 的节点间通信走的是 VMkernel 网络，带宽不足会直接拉低性能。常见做法是每台主机至少配 10GbE，两个万兆口做冗余或链路聚合。如果只有 1GbE，小集群勉强能跑，但重建和再平衡会非常慢，故障恢复时间可能从小时级拉长到天级。

MTU 方面，VSAN 支持巨帧，但要求整条链路（物理交换机、VMkernel、上行链路）全部一致。只要有一处没配，就会出现分片和性能下降，排查起来很麻烦。我一般建议：如果网络团队能保证端到端一致，就上 MTU 9000；否则老老实实 1500，别为了那点理论收益引入玄学问题。

网络冗余也要提前规划。VSAN 支持多网卡绑定，但绑定模式要和交换机侧匹配。常见做法是用 LACP 或基于 IP 哈希的负载均衡，配置前先确认交换机端口通道已经配好，否则绑定后反而会出现单点。

4. 避坑与排查：VSAN 设计和 Sizing 里最容易翻车的五件事

这一章记录的是我在实际项目里踩过的坑，每一条都按现象、原因、解决来写。有些问题在实验室里不会出现，只有上了生产、跑了几个月才会暴露。

4.1 容量算够了，但磁盘组重建时空间不足

现象：一块数据盘故障后，VSAN 开始重建，但重建到一半报空间不足，集群进入降级状态。

原因：Sizing 时只算了稳态可用容量，没有给重建预留额外空间。VSAN 重建需要临时空间做再平衡，如果集群已经接近满载，重建无法完成。

解决：设计时预留至少 15%-20% 的可用空间，不要按 100% 利用率规划。已经满载的集群，先扩容或迁移部分虚拟机，再触发重建。

4.2 缓存盘选小了，写入延迟周期性飙升

现象：业务低峰期正常，一到高峰期写入延迟从几毫秒飙到几十毫秒，虚拟机卡顿。

原因：缓存盘容量或耐久度不足，写入缓冲被快速填满，VSAN 被迫直接写数据盘，延迟上升。

解决：缓存盘按数据盘容量的 10%-15% 配置，选企业级高耐久 SSD 或 NVMe。已经上线的集群，如果缓存盘无法更换，可以把部分冷数据迁移到其他集群，降低写入压力。

4.3 MTU 不一致导致性能不升反降

现象：配了巨帧之后，VSAN 性能没有提升，反而出现间歇性丢包和延迟抖动。

原因：物理交换机、VMkernel 或上行链路中有一处 MTU 没改成 9000，导致大包被分片或丢弃。

解决：用vmkping -s 8972 -d逐段测试，确认整条链路都支持巨帧。如果无法保证端到端一致，改回 1500，不要强行上巨帧。

4.4 故障域规划不足，FTT=2 策略无法满足

现象：存储策略设为 FTT=2，但虚拟机部署失败，提示无法满足放置规则。

原因：集群只有两个故障域，FTT=2 要求三个副本分布在三个故障域，放置规则无法满足。

解决：规划阶段就确认故障域数量，FTT=2 至少需要三个故障域。如果只有两个机架，要么改用 FTT=1，要么增加一个故障域。

4.5 磁盘组里混用不同型号数据盘，重建时间失控

现象：磁盘组里混了不同容量、不同型号的数据盘，一块盘故障后重建时间远超预期。

原因：VSAN 重建以最慢的盘为瓶颈，混用盘会导致重建速度被拖慢，故障窗口拉长。

解决：同一磁盘组内尽量用同型号、同容量的数据盘。如果已经混用，重建时监控vsan.resync_dashboard，必要时限制重建速率，避免影响业务。

5. 用存储策略和容量告警把 Sizing 结果固化下来

Sizing 算完不是终点，真正让设计落地的是存储策略和告警。这一章讲怎么把前面算出来的容量和性能目标，变成 VSAN 里可执行、可监控的配置，以及一个我常用的验证技巧。

5.1 把 FTT 和预留写成存储策略

VSAN 的存储策略决定了每个虚拟机的副本数、条带数和预留。设计阶段算出的 FTT 和预留比例，要落到策略里，而不是靠人工记忆。常见做法是按业务分级建策略：核心业务 FTT=2、预留 20%；普通业务 FTT=1、预留 10%；测试业务 FTT=1、预留 0%。

创建策略时，除了 FTT，还要关注“对象空间预留”和“闪存读缓存预留”两个参数。前者影响容量，后者影响读性能。对读密集业务，闪存读缓存预留可以设高一些；对写密集业务，重点在缓存盘容量，读缓存预留可以低一些。

5.2 用容量告警提前发现余量不足

VSAN 自带容量告警，但默认阈值往往偏松。我一般会把告警阈值调到比设计余量低 5 个百分点，比如设计留 15% 余量，告警就设在 10%。这样在真正触底之前，还有时间扩容或迁移。

告警要覆盖三个维度：集群整体可用容量、单个磁盘组容量、单台主机容量。整体容量告警反映大趋势，磁盘组和主机告警能提前发现局部热点。三者结合，才能避免“整体还有空间但某台主机已经满了”的情况。

5.3 一个验证 Sizing 是否合理的技巧

设计完成后，我会用一个简单方法验证：在集群里部署一批和真实业务同等规格的虚拟机，跑一周，观察容量增长曲线和性能指标。如果一周内容量增长超过设计余量的三分之一，说明 Sizing 偏紧，需要调整；如果性能指标在高峰期接近阈值，说明缓存或网络需要加强。

这个技巧不需要复杂工具，用 VSAN 自带的监控和一份简单的记录表就能做。关键是提前做，不要等生产上线后再补。我自己的习惯是：每次扩容或调整策略后，都重新跑一遍这个验证，把结果记在文档里。时间久了，这套记录就是下一次 Sizing 最可靠的依据。

希望帮到你。

本文还有配套的精品资源，点击获取