简介《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 参与可用容量计算。常见做法是按下面这条链路逐层扣环节扣减原因典型比例物理盘标称容量厂商标称按十进制系统按二进制约 7%磁盘组内保留VSAN 元数据、日志、性能缓冲区每盘约 1-2%策略副本默认 FTT1 时两副本50%预留与开销对象开销、快照、交换文件视负载 10-30%也就是说一块标称 1.92TB 的盘在 FTT1、双副本策略下真正能承载虚拟机数据的部分往往只有 800GB 上下。这个数字不是玄学是每一层扣减叠加出来的结果。设计时如果按标称容量乘以盘数再除以二最后一定会发现空间不够。计算可用容量的常见公式是单盘有效容量 标称容量 × 0.93十进制转二进制× 0.98元数据保留集群原始有效容量 单盘有效容量 × 数据盘数量再除以副本数得到可承载虚拟机数据的容量。这个公式不追求绝对精确但能让你在选型阶段就避开数量级错误。2.2 用脚本把容量账算成一张表手工算容易漏项我一般会写一个小脚本把每台主机的盘数、盘型、策略都代进去直接输出可用容量和余量。下面这段 Python 就是按上面公式实现的参数可以按自己集群改。# vsan_capacity.py # 按磁盘组配置估算 VSAN 可用容量 # 输入每台主机数据盘数量、单盘标称容量(TB)、主机数、副本数、预留比例 def usable_capacity(disks_per_host, disk_tb, hosts, replicas, reserve0.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 数据盘FTT1 双副本预留 10% result usable_capacity(disks_per_host4, disk_tb1.92, hosts4, replicas2) print(result)这段脚本的关键参数有三个replicas对应 VSAN 存储策略里的 FTTFTT1 就是 2 副本FTT2 就是 3 副本reserve是给快照、交换文件和临时对象留的余量生产环境一般不低于 10%跑数据库或大量快照的场景要提到 20% 以上disk_tb用标称容量即可脚本内部已经做了十进制转二进制的折算。跑出来的usable_after_reserve_tb才是你真正能分配给虚拟机的容量上限。提示这个脚本算的是稳态容量不包含磁盘组重建时的临时占用。重建期间 VSAN 需要额外空间做再平衡实际可用会比算出来的再低一些设计时留 15% 以上余量比较稳妥。2.3 副本数和故障域怎么影响最终可用空间副本数不是随便定的它直接决定容量利用率和故障容忍度。FTT1 时两副本容量利用率约 50%FTT2 时三副本利用率降到约 33%。如果集群跨机架或跨故障域VSAN 还会要求副本分布在不同故障域实际可用空间可能进一步下降。常见做法是对容量敏感、可容忍单点故障的业务用 FTT1对核心数据库、不能丢数据的业务用 FTT2但要在 Sizing 阶段就把这部分容量单独算出来不要和普通业务混在一起估。故障域数量也要提前规划三个故障域是 FTT2 能正常工作的下限两个故障域时 FTT2 无法满足放置规则集群会报错。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 --namerandwrite --ioenginelibaio --direct1 \ --bs4k --size10G --numjobs4 --rwrandwrite \ --iodepth32 --runtime120 --time_based \ --group_reporting --output-formatjson参数说明bs4k对应数据库和虚拟桌面最常见的块大小iodepth32模拟多队列并发VSAN 环境下队列深度不足会低估实际性能numjobs4模拟多虚拟机并发direct1绕过文件系统缓存测的是真实磁盘性能。跑完后重点看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 故障域规划不足FTT2 策略无法满足现象存储策略设为 FTT2但虚拟机部署失败提示无法满足放置规则。原因集群只有两个故障域FTT2 要求三个副本分布在三个故障域放置规则无法满足。解决规划阶段就确认故障域数量FTT2 至少需要三个故障域。如果只有两个机架要么改用 FTT1要么增加一个故障域。4.5 磁盘组里混用不同型号数据盘重建时间失控现象磁盘组里混了不同容量、不同型号的数据盘一块盘故障后重建时间远超预期。原因VSAN 重建以最慢的盘为瓶颈混用盘会导致重建速度被拖慢故障窗口拉长。解决同一磁盘组内尽量用同型号、同容量的数据盘。如果已经混用重建时监控vsan.resync_dashboard必要时限制重建速率避免影响业务。5. 用存储策略和容量告警把 Sizing 结果固化下来Sizing 算完不是终点真正让设计落地的是存储策略和告警。这一章讲怎么把前面算出来的容量和性能目标变成 VSAN 里可执行、可监控的配置以及一个我常用的验证技巧。5.1 把 FTT 和预留写成存储策略VSAN 的存储策略决定了每个虚拟机的副本数、条带数和预留。设计阶段算出的 FTT 和预留比例要落到策略里而不是靠人工记忆。常见做法是按业务分级建策略核心业务 FTT2、预留 20%普通业务 FTT1、预留 10%测试业务 FTT1、预留 0%。创建策略时除了 FTT还要关注“对象空间预留”和“闪存读缓存预留”两个参数。前者影响容量后者影响读性能。对读密集业务闪存读缓存预留可以设高一些对写密集业务重点在缓存盘容量读缓存预留可以低一些。5.2 用容量告警提前发现余量不足VSAN 自带容量告警但默认阈值往往偏松。我一般会把告警阈值调到比设计余量低 5 个百分点比如设计留 15% 余量告警就设在 10%。这样在真正触底之前还有时间扩容或迁移。告警要覆盖三个维度集群整体可用容量、单个磁盘组容量、单台主机容量。整体容量告警反映大趋势磁盘组和主机告警能提前发现局部热点。三者结合才能避免“整体还有空间但某台主机已经满了”的情况。5.3 一个验证 Sizing 是否合理的技巧设计完成后我会用一个简单方法验证在集群里部署一批和真实业务同等规格的虚拟机跑一周观察容量增长曲线和性能指标。如果一周内容量增长超过设计余量的三分之一说明 Sizing 偏紧需要调整如果性能指标在高峰期接近阈值说明缓存或网络需要加强。这个技巧不需要复杂工具用 VSAN 自带的监控和一份简单的记录表就能做。关键是提前做不要等生产上线后再补。我自己的习惯是每次扩容或调整策略后都重新跑一遍这个验证把结果记在文档里。时间久了这套记录就是下一次 Sizing 最可靠的依据。希望帮到你。本文还有配套的精品资源点击获取