VSAN 6.0 设计与 Sizing 指南：容量规划与存储策略避坑

简介《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%加上 FTT1 的副本和见证组件一份数据在集群里被放大了好几倍。这不是硬件买少了是 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 固件、网卡驱动都有明确的兼容性列表不在列表里的组合轻则性能跑不满重则磁盘组反复掉线。我一般会按这个顺序核对在 VCG 里锁定服务器型号确认它属于 Virtual SAN Ready Nodes 或者至少通过了 VSAN 认证。逐个核对存储控制器型号和固件版本尤其是 RAID 卡是否支持 pass-through 或 RAID-0 模式。核对 SSD 和 HDD 的型号注意 SSD 的耐久度指标DWPD是否满足写入缓存的要求。核对网卡型号和驱动版本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 不是一次性的业务增长、磁盘更换、版本升级都会改变容量和性能的平衡。容量规划部分文档反复提到要为维护和可用性留余量。具体来说预留至少一个主机故障所需的容量保证 FTT1 时数据能重建。预留磁盘更换和升级期间的临时空间别等到磁盘坏了才发现没地方重建。预留快照增长的空间快照 delta 盘在 VSAN 上也是按策略分布的。注意文档里没有给出一个固定的「预留百分比」因为不同 FTT 和条带宽度下开销不同后面存储策略章节会具体算。3. 容量与缓存怎么算混合与全闪的 Sizing 差异3.1 混合配置的缓存盘该买多大混合配置里SSD 只做缓存HDD 做容量。缓存分两部分读缓存和写缓存。写缓存负责吸收写入等数据攒够了再刷到 HDD读缓存负责缓存热点数据。文档里给了一个经验比例写缓存至少按每 1TB 容量盘配 10% 的 SSD 来估算但这不是死数要看写入放大和业务写入模式。我一般会用一个简化公式先框个范围# 混合配置写缓存粗算单位 GB # 假设容量盘总裸容量 C写入缓存比例 r 取 10%~20% C20000 # 20TB 裸容量 r0.10 write_cache$((C * r / 100)) echo 建议写缓存下限: ${write_cache} GB逻辑说明这里把容量盘总裸容量乘以一个比例系数得到写缓存的下限。参数 r 的取值取决于业务写入强度文档里提到写入密集场景可以往 20% 靠。注意这是下限不是推荐值实际还要看 SSD 的耐久度和控制器队列深度。3.2 全闪配置的缓存与容量比例全闪配置里SSD 既是缓存也是容量Sizing 逻辑变了。文档里全闪的缓存盘主要承担写入缓冲和读缓存容量盘用大容量 SSD。全闪的缓存比例通常比混合低因为容量盘本身性能就高不需要靠缓存扛全部 IO。文档给了一个全闪的 working example我把它整理成表格方便对照配置项混合配置全闪配置缓存介质SSDSSD容量介质HDDSSD缓存比例参考容量盘的 10%~20%容量盘的 5%~10%主要瓶颈HDD 随机 IOSSD 耐久度与控制器队列典型场景容量优先、成本敏感性能优先、低延迟提示全闪配置下 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 还是 10GbEMTU 怎么定网络是 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 ControlVSAN 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)允许几台主机同时故障。FTT1 时每个对象有 2 个副本加 1 个见证FTT2 时是 3 个副本加见证。副本数直接决定容量开销。Number of Disk Stripes Per Object条带宽度把对象拆到多个磁盘组上提升性能。条带数越多单个对象的 IO 越分散但元数据开销也越大。Flash Read Cache Reservation读缓存预留按对象预留 SSD 读缓存。设得太高会浪费缓存设得太低热点数据命中率下降。Object Space Reservation对象空间预留决定厚置备还是精简置备。设成 100% 就是厚置备容量立刻被占满设成 0% 就是精简置备按实际写入增长。我一般会按这个顺序定策略先定 FTT根据业务可用性要求选 1 或 2。再定条带宽度IO 密集的虚拟机可以设 2 或 4 条带。读缓存预留默认 0除非有明确的热点数据需求。对象空间预留默认 0除非有性能隔离要求。注意策略改动态生效但改 FTT 或条带会触发组件重建业务高峰期别动。4.4 见证与副本的放置文档里 Witness and Replicas 一节解释了见证组件的角色。见证不存数据只参与仲裁但它也占容量虽然很小。三节点集群里见证的放置要避免和副本落在同一台主机否则那台主机挂了仲裁也丢了。5. 避坑与排查那些文档没明说但一定会遇到的5.1 磁盘组反复掉线现象ESXi 主机上磁盘组状态变成「降级」或「离线」健康服务里报磁盘或控制器错误。原因最常见的是控制器队列深度不够或者 SSD 固件有 bug。VSAN 对控制器的队列深度有要求尤其是全闪配置下队列浅的控制器会成为瓶颈。另一个原因是磁盘组里的 SSD 和 HDD 混用了不同型号固件行为不一致。解决先查 VCG 确认控制器和磁盘型号在列表内然后升级固件到推荐版本。如果队列深度不够考虑换控制器或者减少单控制器下的磁盘组数量。5.2 容量使用率虚高现象vCenter 里显示容量使用率远高于实际业务数据量。原因对象空间预留设成了 100%或者 FTT2 导致副本数翻倍再叠加条带和快照开销。解决检查虚拟机存储策略把对象空间预留改成 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 能看的信息有限。我习惯用 RVCRuby 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 看一遍对象布局再跑健康服务确认没有红色项最后留出至少一台主机的空闲容量。这套流程走下来容量告警基本没再出现过。希望帮到你。本文还有配套的精品资源点击获取