简介：《VSAN设计与Sizing指南》是VMware官方发布的Virtual SAN 6.0技术文档，面向虚拟化架构师、存储工程师与IT运维人员，用于解决超融合环境中VSAN集群的设计规划、容量预估与性能调优问题。资源包为单一PDF文件，共1个文件，压缩包约959KB，内容完整、便于离线查阅与团队传阅。文档系统梳理了VSAN就绪节点、EVO:RAIL、兼容性指南（VCG）、平衡配置、集群生命周期管理、容量规划、维护与可用性、性能考量、成本效益分析、故障域设计及监控调优等核心主题，并给出混合与全闪存配置差异、VSAN各项上限等关键参数。读者可据此掌握从硬件选型、容量测算到故障域隔离与持续调优的完整方法，降低部署风险，保障存储性能与高可用性。目前已有83人学习下载，适合需要系统构建和管理VSAN环境的中高级技术人员参考。

1. 从一次容量告警说起：这份 VSAN 6.0 设计指南到底解决什么问题

去年帮一个朋友看他们刚上线三个月的超融合集群，告警邮件里写着「存储容量使用率 82%」，但实际业务数据算下来只占了裸容量的四成。翻配置才发现，虚拟机存储策略里对象空间预留设成了 100%，加上 FTT=1 的副本和见证组件，一份数据在集群里被放大了好几倍。这不是硬件买少了，是 Sizing 阶段没把策略开销算进去。类似这种翻车，在 VSAN 环境里太常见了——它不像传统 SAN 那样买多少 LUN 就是多少可用空间，容量、性能、可用性三者被存储策略绑在一起，任何一个参数拍脑袋，后面都要用真金白银去补。

这份《VSAN 设计与 Sizing 指南》是 VMware 存储与可用性业务单元在 2015 年 3 月发布的 Virtual SAN 6.0 官方设计文档，作者是 Cormac Hogan。它不讲 API 怎么调、不讲命令行怎么敲，讲的是在动手部署之前，怎么把集群的容量、缓存、网络、磁盘组和存储策略算清楚。适合正在做 VSAN 方案选型、容量规划或者被容量告警折腾过的运维和架构同学。下面我按自己拆文档的顺序，把里面能直接抄作业的部分拎出来。

2. 设计前的硬约束：兼容性、版本与集群生命周期

2.1 为什么必须先过 VCG 这一关

VSAN 和传统存储最大的区别在于，它的可靠性建立在「软件定义」之上，但软件再稳也架不住底层硬件不听话。文档开篇就强调 Follow the Compatibility Guide (VCG) Precisely，这不是客套话。VSAN 对磁盘控制器、SSD 固件、网卡驱动都有明确的兼容性列表，不在列表里的组合，轻则性能跑不满，重则磁盘组反复掉线。

我一般会按这个顺序核对：

1. 在 VCG 里锁定服务器型号，确认它属于 Virtual SAN Ready Nodes 或者至少通过了 VSAN 认证。
2. 逐个核对存储控制器型号和固件版本，尤其是 RAID 卡是否支持 pass-through 或 RAID-0 模式。
3. 核对 SSD 和 HDD 的型号，注意 SSD 的耐久度指标（DWPD）是否满足写入缓存的要求。
4. 核对网卡型号和驱动版本，10GbE 和 1GbE 的选型后面网络章节会展开。

提示：VCG 是按 vSphere 版本和 VSAN 版本交叉查询的，VSAN 6.0 对应的列表和 6.5、7.0 完全不同，别拿新列表去套老环境。

2.2 支持的 vSphere 版本与平衡配置

VSAN 6.0 是嵌在 vSphere 里的，不是外挂存储，所以 ESXi 和 vCenter 的版本必须落在官方支持矩阵内。文档里提到的「Use Supported vSphere Software Versions」说白了就是别混搭，尤其是 vCenter 和 ESXi 的小版本号要对齐，否则 VSAN 的健康服务和策略下发可能出玄学问题。

平衡配置（Balanced Configurations）是另一个容易被忽略的点。VSAN 集群里每台主机的 CPU、内存、磁盘组数量、网卡带宽最好保持一致。原因很直接：VSAN 的数据分布是跨主机的，如果一台主机磁盘多、一台磁盘少，容量和性能就会倾斜，重建和再平衡的时候压力全压在弱的那台上。我见过一个三节点集群，两台各 4 个磁盘组、一台只有 2 个，结果那台少的主机长期 CPU 跑满，因为它的缓存盘要扛的 IO 密度更高。

2.3 集群生命周期与容量预留

文档把 VSAN 集群的生命周期拆成部署、扩展、升级、退役几个阶段，每个阶段都要重新做一次 Sizing。这里有个血泪经验：Sizing 不是一次性的，业务增长、磁盘更换、版本升级都会改变容量和性能的平衡。

容量规划部分，文档反复提到要为维护和可用性留余量。具体来说：

• 预留至少一个主机故障所需的容量，保证 FTT=1 时数据能重建。
• 预留磁盘更换和升级期间的临时空间，别等到磁盘坏了才发现没地方重建。
• 预留快照增长的空间，快照 delta 盘在 VSAN 上也是按策略分布的。

注意：文档里没有给出一个固定的「预留百分比」，因为不同 FTT 和条带宽度下开销不同，后面存储策略章节会具体算。

3. 容量与缓存怎么算：混合与全闪的 Sizing 差异

3.1 混合配置的缓存盘该买多大

混合配置里，SSD 只做缓存，HDD 做容量。缓存分两部分：读缓存和写缓存。写缓存负责吸收写入，等数据攒够了再刷到 HDD；读缓存负责缓存热点数据。文档里给了一个经验比例：写缓存至少按每 1TB 容量盘配 10% 的 SSD 来估算，但这不是死数，要看写入放大和业务写入模式。

我一般会用一个简化公式先框个范围：

# 混合配置写缓存粗算（单位 GB） # 假设容量盘总裸容量 C，写入缓存比例 r 取 10%~20% C=20000 # 20TB 裸容量 r=0.10 write_cache=$((C * r / 100)) echo "建议写缓存下限: ${write_cache} GB"

逻辑说明：这里把容量盘总裸容量乘以一个比例系数，得到写缓存的下限。参数 r 的取值取决于业务写入强度，文档里提到写入密集场景可以往 20% 靠。注意这是下限，不是推荐值，实际还要看 SSD 的耐久度和控制器队列深度。

3.2 全闪配置的缓存与容量比例

全闪配置里，SSD 既是缓存也是容量，Sizing 逻辑变了。文档里全闪的缓存盘主要承担写入缓冲和读缓存，容量盘用大容量 SSD。全闪的缓存比例通常比混合低，因为容量盘本身性能就高，不需要靠缓存扛全部 IO。

文档给了一个全闪的 working example，我把它整理成表格方便对照：

提示：全闪配置下 SSD 的 DWPD 要重点看，写入缓存盘的寿命直接决定集群能扛多久。

3.3 容量盘数量与磁盘组设计

文档里有一句话很关键：Number of magnetic disks matter in hybrid configurations。混合配置里，HDD 的数量直接影响随机 IO 能力，因为每块 HDD 能提供的 IOPS 有限，靠数量堆总 IOPS。但磁盘组不是越多越好，每个磁盘组至少需要一块 SSD 做缓存，磁盘组数量受限于 SSD 数量和控制器端口数。

磁盘组作为故障域的设计也要注意。一个磁盘组挂了，上面所有虚拟机组件都要重建。所以文档建议把磁盘组分散到不同主机，避免单主机上所有磁盘组共享同一个控制器或背板。

3.4 快照和格式化开销

快照在 VSAN 上会创建 delta 盘，这些 delta 盘同样占用容量，而且按虚拟机存储策略分布。文档里专门有一节 Snapshot Cache Sizing Considerations，提醒快照会消耗缓存和容量。格式化开销（Formatting Overhead）也要算进去，VSAN 的磁盘格式会占用一部分裸容量，具体比例文档里有说明，规划时别把裸容量当可用容量。

4. 网络与存储策略：那些影响可用性的参数

4.1 1GbE 还是 10GbE，MTU 怎么定

网络是 VSAN 的血管。文档里网络设计部分明确区分了 1GbE 和 10GbE 的场景。1GbE 在混合配置、小规模集群里还能用，但全闪配置和写入密集场景必须上 10GbE。带宽需求跟磁盘组数量、缓存盘性能直接相关，缓存盘越快，网络越容易成为瓶颈。

MTU 和 Jumbo Frames 是另一个高频踩坑点。文档建议在 VSAN 网络和 vMotion 网络上启用 Jumbo Frames，但前提是整条路径都支持，包括物理交换机、虚拟交换机、网卡。只要有一跳不支持，就会出现分片和性能下降，甚至丢包。我一般会先用 ping 带 DF 标志测试端到端 MTU：

# 测试 9000 MTU 是否端到端支持，-M do 禁止分片，-s 指定数据包大小 ping -M do -s 8972 192.168.10.11 # 如果返回 "Frag needed and DF set"，说明路径上有设备不支持 9000 MTU

逻辑说明：8972 是 9000 MTU 减去 ICMP 头和 IP 头后的数据部分。如果这条命令不通，就别急着在 vSwitch 上开 Jumbo Frames，先排查物理网络。

4.2 多播与 Network I/O Control

VSAN 6.0 依赖多播进行集群通信，文档里 Multicast Considerations 提醒要确保物理网络支持 IGMP snooping 或者多播转发。如果交换机把多播当广播泛洪，规模大了会拖垮网络。Network I/O Control 可以用来给 VSAN 流量做 QoS，保证在拥塞时存储流量优先。

4.3 存储策略里的 FTT、条带与对象空间预留

虚拟机存储策略是 VSAN 的灵魂，也是 Sizing 最容易翻车的地方。文档里 Policy Design Decisions 一节把几个关键参数讲得很细：

• Number of Failures To Tolerate (FTT)：允许几台主机同时故障。FTT=1 时，每个对象有 2 个副本加 1 个见证；FTT=2 时是 3 个副本加见证。副本数直接决定容量开销。
• Number of Disk Stripes Per Object：条带宽度，把对象拆到多个磁盘组上，提升性能。条带数越多，单个对象的 IO 越分散，但元数据开销也越大。
• Flash Read Cache Reservation：读缓存预留，按对象预留 SSD 读缓存。设得太高会浪费缓存，设得太低热点数据命中率下降。
• Object Space Reservation：对象空间预留，决定厚置备还是精简置备。设成 100% 就是厚置备，容量立刻被占满；设成 0% 就是精简置备，按实际写入增长。

我一般会按这个顺序定策略：

1. 先定 FTT，根据业务可用性要求选 1 或 2。
2. 再定条带宽度，IO 密集的虚拟机可以设 2 或 4 条带。
3. 读缓存预留默认 0，除非有明确的热点数据需求。
4. 对象空间预留默认 0，除非有性能隔离要求。

注意：策略改动态生效，但改 FTT 或条带会触发组件重建，业务高峰期别动。

4.4 见证与副本的放置

文档里 Witness and Replicas 一节解释了见证组件的角色。见证不存数据，只参与仲裁，但它也占容量，虽然很小。三节点集群里，见证的放置要避免和副本落在同一台主机，否则那台主机挂了，仲裁也丢了。

5. 避坑与排查：那些文档没明说但一定会遇到的

5.1 磁盘组反复掉线

现象：ESXi 主机上磁盘组状态变成「降级」或「离线」，健康服务里报磁盘或控制器错误。

原因：最常见的是控制器队列深度不够，或者 SSD 固件有 bug。VSAN 对控制器的队列深度有要求，尤其是全闪配置下，队列浅的控制器会成为瓶颈。另一个原因是磁盘组里的 SSD 和 HDD 混用了不同型号，固件行为不一致。

解决：先查 VCG 确认控制器和磁盘型号在列表内，然后升级固件到推荐版本。如果队列深度不够，考虑换控制器或者减少单控制器下的磁盘组数量。

5.2 容量使用率虚高

现象：vCenter 里显示容量使用率远高于实际业务数据量。

原因：对象空间预留设成了 100%，或者 FTT=2 导致副本数翻倍，再叠加条带和快照开销。

解决：检查虚拟机存储策略，把对象空间预留改成 0，确认 FTT 是否真的需要 2。用 RVC 或者 vsanObserver 看对象布局，确认容量被谁占了。

5.3 重建速度慢到离谱

现象：一台主机故障后，数据重建进度条几乎不动，业务性能也受影响。

原因：重建流量和业务流量抢带宽，或者集群里没有足够的空闲容量和缓存。混合配置下，HDD 的随机写能力有限，重建时大量随机写会把 HDD 打满。

解决：给 VSAN 网络留足带宽，重建期间可以用 Network I/O Control 限流。规划时预留至少一台主机的空闲容量，别把集群塞满。

5.4 快照把容量吃光

现象：某台虚拟机做了快照后，集群容量告警，甚至影响其他虚拟机。

原因：快照 delta 盘按策略分布，如果策略里对象空间预留是 100%，delta 盘也会厚置备，容量瞬间被吃掉。

解决：快照用完及时删除，策略里对象空间预留设 0。监控快照增长，设置告警阈值。

5.5 Jumbo Frames 开了反而更慢

现象：启用 Jumbo Frames 后，VSAN 性能不升反降，甚至出现丢包。

原因：路径上有设备不支持 9000 MTU，导致分片或丢包。虚拟交换机的 MTU 改了，但物理交换机没改，或者网卡驱动没生效。

解决：用 ping -M do 逐跳测试 MTU，确认端到端支持后再开。如果搞不定，就老老实实用 1500 MTU，性能损失比丢包小。

6. 进阶技巧：用 RVC 和健康服务验证 Sizing 是否合理

文档里提到 Reviewing Object Layout from UI，但 UI 能看的信息有限。我习惯用 RVC（Ruby vSphere Console）的 vsan 命令看对象布局和组件状态。比如vsan.vm_object_info可以列出虚拟机的对象、组件、所在磁盘组和主机，一眼就能看出副本和见证的分布是否均衡。

# 在 RVC 里查看某个虚拟机的对象布局 # 先进入集群上下文 cd /localhost/Datacenter/computers/Cluster vsan.vm_object_info -v /localhost/Datacenter/vms/MyVM

逻辑说明：这条命令会输出虚拟机的所有对象，包括 VMDK、命名空间、swap 等，每个对象下面列出组件和所在主机。如果发现某个对象的副本全挤在一台主机上，说明策略或者磁盘组设计有问题。

健康服务（Health Services）是另一个验证工具。文档开篇就提到它，但很多人部署完就不看了。健康服务会检查硬件兼容性、磁盘组状态、网络配置、集群平衡等，相当于一个持续运行的 Sizing 校验器。我一般会在集群上线后跑一遍健康检查，把红色和黄色项逐个消掉，再开始跑业务。

还有一个技巧是模拟故障。VSAN 支持在健康服务里做「主动测试」，比如模拟一台主机故障，看集群是否能正常重建、容量是否够用。这比等到真故障了才发现容量不够要主动得多。

从那以后我每次做 VSAN Sizing，都会先把存储策略定下来，用 RVC 看一遍对象布局，再跑健康服务确认没有红色项，最后留出至少一台主机的空闲容量。这套流程走下来，容量告警基本没再出现过。希望帮到你。

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