简介这份《VSAN设计与Sizing指南》是VMware官方发布的Virtual SAN 6.0技术文档面向虚拟化架构师、存储工程师与IT运维人员用于解决VSAN环境的设计规划、容量预估与性能可用性保障问题。资源包共1个PDF文件大小约959KB内容为完整的英文技术指南便于离线查阅与团队传阅。文档系统梳理了VSAN就绪节点、EVO:RAIL、兼容性指南VCG、平衡配置、集群生命周期管理、容量规划、维护与可用性、性能考量、成本效益分析、故障域设计及监控调优等核心议题并区分混合与全闪存架构的差异给出ESXi主机数量、虚拟机上限等具体限制。读者可据此掌握从硬件选型到性能优化的完整设计方法对照官方建议完成容量估算与冗余规划降低部署风险。目前已有83人学习下载适合需要系统构建和管理VSAN环境的中高级技术人员参考。1. VSAN 设计和 Sizing 指南从容量估算到故障域一份能直接套用的规划方法很多人第一次做 VSAN 规划都是先数硬盘——买几块 SSD、几块 HDD凑够容量就下单。结果上线三个月某节点一块盘掉了集群直接进入降级状态重建窗口拉到十几个小时业务侧开始报警。问题不在硬件质量而在设计阶段就没把「故障域」和「重建带宽」算进去。VSAN 设计和 Sizing 指南要解决的就是这件事在采购之前把容量、性能、故障域、重建余量四笔账算清楚让集群在坏一块盘、掉一个节点的情况下仍然能扛住。这套方法适合正在做超融合选型的基础架构工程师、需要给 VSAN 集群出配置单的售前以及已经上线但发现容量或性能吃紧、想回头做二次规划的运维。下面按「先立模型、再算参数、最后避坑」的顺序展开每一步都给出可复现的估算方式和参数取值。2. VSAN 容量与性能的底层模型先搞清楚三份账2.1 为什么「裸容量」不能直接当可用容量用VSAN 的容量账本有三层裸容量、可写容量、可用容量。裸容量是所有参与 VSAN 的磁盘物理容量之和可写容量要扣掉每台主机的 ESXi 系统分区占用通常每台 816 GB视安装方式而定可用容量再扣掉存储策略带来的开销。最常见的坑是把裸容量乘以节点数就当可用容量报给业务方最后发现实际能用的只有七成左右。存储策略里影响容量最大的是 FTTFailures To Tolerate允许故障数和 RAID 方式。FTT1 配 RAID-1镜像时一份数据写两份容量利用率约 50%FTT1 配 RAID-5 时4 个以上故障域利用率约 75%FTT2 配 RAID-6 时6 个以上故障域利用率约 67%。这些比例不是拍脑袋是 VSAN 对象在故障域上的分布规则决定的。估算可用容量的通用公式可以写成可用容量 ≈ 裸容量 × 容量利用率 × (1 - 预留余量)其中预留余量建议留 25%30%用于快照、Swap、重建期间的临时占用和未来增长。如果业务侧对容量增长没有明确预期宁可把余量留到 30%也不要上线半年就扩容。2.2 故障域数量怎么决定 RAID 方式故障域在 VSAN 里通常指主机数量也可以配置为机架级别。RAID-5 和 RAID-6 对故障域数量有硬性要求RAID-5 至少 4 个故障域RAID-6 至少 6 个故障域。如果集群只有 3 台主机FTT1 只能用 RAID-1容量利用率直接砍半这时候再谈「用 RAID-5 省容量」就是空话。实际规划时先确定集群规模再反推能用的 RAID 方式最后算容量。顺序反了配置单就会出错。比如 4 台主机的集群FTT1 可以走 RAID-5利用率约 75%但如果业务要求 FTT24 个故障域不够 RAID-6 的最低要求只能退回 RAID-1利用率又回到 50%。这个约束在规划早期就要确认不然后面所有容量数字都要重算。2.3 性能账IOPS 和带宽要分开算容量算完只是第一步性能账同样不能省。VSAN 的性能取决于缓存层和容量层的配比。常见做法是每台主机配 12 块 SSD 或 NVMe 作为缓存盘容量层用 HDD 或 SSD。缓存盘和容量盘的容量比建议控制在 1:10 以内超过这个比例缓存命中率下降读性能会明显波动。IOPS 估算要区分读写比例。全闪配置下VSAN 的读操作主要走缓存层写操作先写缓存再落容量层。混合配置下读操作如果未命中缓存会直接读容量层 HDD延迟会从毫秒级跳到十几毫秒。所以混合配置的性能估算不能只看缓存盘的 IOPS要把容量层的随机读能力也算进去。一个可用的估算方式是先统计业务侧的总 IOPS 需求和读写比再按 70% 缓存命中率估算容量层需要承担的 IOPS最后对比容量层磁盘的随机读写能力。如果容量层是 7.2K HDD单盘随机 IOPS 大约 75100这个数字要记牢它决定了混合集群的性能天花板。3. 用表格和公式做 Sizing从业务需求到配置单3.1 把业务需求翻译成 VSAN 参数Sizing 的起点不是磁盘是业务。需要收集的信息包括虚拟机数量、每台虚拟机的 vCPU/内存/存储配置、总 IOPS 需求、读写比例、可接受的故障级别、未来 1224 个月的增长预期。这些信息收集齐了才能往下算。下面这张表是我常用的需求映射表左边是业务侧输入右边是对应的 VSAN 参数业务输入对应 VSAN 参数取值建议可接受故障级别FTT一般业务 FTT1核心业务 FTT2集群主机数故障域数量决定 RAID 方式总 IOPS 需求缓存盘规格与数量按读写比折算总容量需求容量层磁盘数量叠加 25%30% 余量增长预期预留余量年增长 20% 以上留 30%这张表的价值在于把模糊的业务语言转成可计算的参数。比如业务说「不能停」对应到 VSAN 就是 FTT2 加 RAID-6再往下就是至少 6 个故障域也就是至少 6 台主机。这个推导链条要写进规划文档后面采购和验收都靠它。3.2 容量估算的完整算例假设一个 6 主机集群每台主机配 2 块 1.92 TB SSD 作为容量盘1 块 800 GB SSD 作为缓存盘。裸容量是 6 × 2 × 1.92 TB 23.04 TB。ESXi 系统分区每台占 16 GB6 台共 96 GB约 0.094 TB。扣除后约 22.95 TB。业务要求 FTT16 个故障域满足 RAID-5 要求容量利用率约 75%。可用容量约 22.95 × 0.75 17.21 TB。再留 25% 余量实际可分配给业务的容量约 12.91 TB。如果业务要求 FTT26 个故障域刚好满足 RAID-6 最低要求利用率约 67%。可用容量约 22.95 × 0.67 15.38 TB留 25% 余量后约 11.53 TB。两种策略差了约 1.4 TB这个差距在规划阶段就要让业务方知道由他们决定是否值得为更高的故障容忍度牺牲容量。3.3 性能估算与缓存盘选型继续上面的例子。假设业务总 IOPS 需求是 50000读写比 7:3。全闪配置下读操作 35000 IOPS 走缓存层写操作 15000 IOPS 先写缓存。每台主机分担约 5833 读 IOPS 和 2500 写 IOPS。单块 800 GB SSD 的随机读 IOPS 通常在 100000 以上写 IOPS 也在 30000 以上单块缓存盘足够。如果是混合配置容量层是 7.2K HDD单盘随机 IOPS 约 75100。每台主机 2 块 HDD容量层随机 IOPS 约 150200。按 70% 缓存命中率容量层需要承担的读 IOPS 是 35000 × 30% / 6 1750 IOPS远超 2 块 HDD 的能力。这时候要么增加 HDD 数量要么改用全闪要么接受性能不达标。这个计算过程就是 Sizing 的核心价值——在采购前发现瓶颈而不是上线后。提示缓存盘和容量盘的容量比建议不超过 1:10。如果容量层是 2 × 1.92 TB缓存盘至少 384 GB。800 GB 缓存盘在这个配置下是安全的。4. VSAN 设计中的避坑与排查五条血泪经验4.1 重建带宽没留够坏一块盘集群就卡死现象某节点一块容量盘故障VSAN 开始重建数据业务侧虚拟机响应时间从 5 ms 涨到 80 ms持续数小时。原因重建流量和业务流量共享同一套网络和磁盘 IO规划时没有为重建预留带宽和 IOPS。VSAN 重建默认会占用较多资源如果集群本身已经接近性能上限重建就会把业务压垮。解决规划时按「N1」原则预留重建余量即集群在少一个节点或一块盘的情况下剩余资源仍能满足业务需求。网络侧建议为 VSAN 流量配置独立的 VMkernel 网卡和物理上行链路重建期间可以通过esxcli vsan cluster get查看重建状态必要时用esxcli vsan rebalance调整重建速率。4.2 磁盘组配置不一致容量分布倾斜现象集群运行一段时间后某台主机的磁盘使用率明显高于其他主机虚拟机迁移时发现部分主机没有足够空间。原因各主机的磁盘组配置不一致比如有的主机 1 个磁盘组 2 块盘有的主机 2 个磁盘组 4 块盘。VSAN 在放置对象时会优先选择资源充足的主机导致配置高的主机承担更多数据。解决规划阶段就统一各主机的磁盘组配置包括磁盘组数量、缓存盘规格、容量盘数量和规格。如果已经出现倾斜可以通过存储策略调整或手动迁移虚拟机来平衡但根治还是要统一硬件配置。4.3 网络带宽按峰值估忽略重建和 vMotion 叠加现象业务高峰期做 vMotion 或触发重建时VSAN 网络出现丢包虚拟机出现短暂卡顿。原因VSAN 网络带宽只按业务峰值估算没有把重建、vMotion、备份流量叠加进去。这些流量在特定时间点会同时出现带宽需求可能是业务峰值的 23 倍。解决VSAN 网络建议按业务峰值带宽的 2 倍以上规划或者为重建和 vMotion 配置独立的网络流量通道。10 GbE 是当前比较稳妥的起点25 GbE 在全闪集群中更常见。规划时可以用esxcli network ip interface list确认 VMkernel 网卡配置用vsish查看网络统计。4.4 存储策略用默认值业务虚拟机没有区分现象核心数据库虚拟机和测试虚拟机用同一套存储策略测试虚拟机的大量写入影响了数据库的响应时间。原因VSAN 默认存储策略是 FTT1、RAID-1没有区分业务优先级。所有虚拟机共享同一套故障域和缓存资源高写入的虚拟机可能挤占缓存。解决按业务等级创建多套存储策略。核心业务用 FTT2、RAID-6测试业务用 FTT1、RAID-5 或 RAID-1。通过策略区分故障容忍度和性能优先级避免低优先级业务影响核心业务。4.5 容量余量留太少快照和 Swap 把空间吃光现象集群容量使用率超过 80% 后VSAN 开始拒绝新的写入虚拟机无法开机或快照失败。原因规划时只算了虚拟机磁盘的容量没有为快照、Swap 文件、内存开销预留空间。VSAN 在容量使用率超过一定阈值后会进入只读或拒绝写入状态具体阈值和配置有关。解决容量余量至少留 25%有快照需求的业务留 30%。定期用esxcli vsan storage list和esxcli vsan cluster get检查容量使用情况在达到 70% 时就开始规划扩容。5. 进阶技巧用 RVTools 和 vsan-health 做上线前验证规划做完、硬件到货、集群搭起来之后不要直接上业务。先做一轮验证确认实际配置和规划一致性能达标故障域符合预期。这一步能提前发现大部分配置问题比上线后救火成本低得多。我常用的验证组合是 RVTools 加 VSAN 健康检查。RVTools 可以导出集群的虚拟机清单、磁盘使用、网络配置用来核对实际部署和规划文档是否一致。VSAN 健康检查通过esxcli vsan health cluster list查看重点关注「数据健康」「磁盘平衡」「网络健康」三项。如果数据健康显示「降级」说明有对象没有达到策略要求的故障容忍度需要排查磁盘组或网络。下面是一个验证脚本的骨架用来批量检查各主机的磁盘组和容量使用情况#!/bin/bash # 批量检查 VSAN 集群各主机的磁盘组和容量状态 # 需要提前配置好 SSH 免密登录主机列表放在 hosts.txt 中 while read host; do echo $host # 查看磁盘组列表 ssh root$host esxcli vsan storage list | grep -E Display Name|Is SSD|Capacity # 查看容量使用 ssh root$host esxcli vsan storage list | grep -i used # 查看 VSAN 健康状态 ssh root$host esxcli vsan health cluster list | grep -E State|Description done hosts.txt这个脚本的逻辑是逐台主机拉取磁盘组和健康状态输出结果可以重定向到文件和规划文档逐项对比。参数方面esxcli vsan storage list会列出每块盘的显示名称、是否 SSD、容量和使用量esxcli vsan health cluster list会给出各项健康检查的状态和描述。如果某台主机的磁盘组数量和规划不一致或者容量使用率超过 70%就要在业务上线前处理。另一个容易忽略的点是 VSAN 的「对象修复时间」。集群上线后可以手动触发一次模拟故障观察重建时间和业务影响。具体做法是在测试集群中关闭一台主机记录 VSAN 开始重建到完成的时间以及期间业务虚拟机的响应时间变化。这个数据比任何理论估算都可靠可以作为后续扩容和故障预案的依据。我自己的习惯是规划文档里每个容量和性能数字都要有出处要么来自业务需求要么来自硬件规格要么来自实测数据。没有出处的数字上线后大概率会翻车。VSAN 设计和 Sizing 不是一次性的工作集群运行期间要定期复核容量、性能和故障域状态业务增长或硬件变更后及时更新规划。希望帮到你。本文还有配套的精品资源点击获取