简介VMware官方发布的《VSAN设计与Sizing指南》是一份针对Virtual SAN 6.0的设计与容量规划文档面向IT基础架构师、虚拟化管理员及存储规划人员用于解决VSAN环境设计、容量预估与性能优化问题。资源共1个PDF文件压缩包约959KB内容紧凑目录结构清晰便于按需检索。文档系统覆盖了健康服务、VSAN就绪节点、EVO:RAIL、兼容性指南VCG遵循、集群生命周期管理、容量规划、故障域设计、监控与调优等关键主题并给出混合与全闪存架构的差异对比及VSAN配置限制从基础架构选型、容量估算到维护与可用性均有完善指引。已有83人学习下载适合需要系统掌握VSAN设计原则、规避部署风险并制定高可用存储方案的读者。1. 新主机已进vSAN集群却报未启用服务这份指南到底在解决什么机架里四台新到的存储节点加进 vSAN 集群耗了半小时vSphere Client 的主机状态列却挂着一行提示“主机位于 vSAN 集群中但尚未启用 vSAN 服务”。业务那边在催着上线集群容量按三副本算出来的数字又总觉得不踏实——这就是 vSAN 设计和 Sizing 的日常。标题里这份指南想解决的问题只有两个第一集群容量、磁盘组、故障域、存储策略这些参数怎么按业务算出来而不是拍脑袋第二算完之后怎么把主机真正“启用”进 vSAN并验证整个集群是健康的。这份东西适合正在规划 vSAN 采购、扩容或者刚把硬件搬进机柜准备上线的存储与虚拟化工程师。2. vSAN Sizing 先算容量三副本开销、闪存缓存比例和磁盘组数量怎么定2.1 先看懂 vSAN 怎么“吃”磁盘对象、组件与副本的最小单位vSAN 不是一个传统意义上的共享存储它把每台 ESXi 主机上的本地磁盘聚合成一个分布式存储池。上层虚拟机看到的是一个标准数据存储但底层的数据存放逻辑跟传统 RAID 完全不同。一台虚拟机的 VMDK 在 vSAN 里被抽象成一个对象Object。这个对象会被拆成一个或多个组件Component再按存储策略把组件复制多份分散放在集群里的不同主机上。如果策略要求一份数据存两份FTT1镜像模式vSAN 会把这个对象的组件复制成两份副本并额外生成一个见证组件Witness来协调故障场景下的数据一致性。这部分对 Sizing 的意义在于vSAN 消耗的容量不是简单的“虚拟机磁盘大小 × 2”。组件拆分、条带化、见证组件、元数据都会吃掉一部分空间。见过不少第一次做 vSAN 规划的人拿着“单台 VM 500GB × 50 台 VM × 2 副本 50TB”这个算法去采购结果磁盘组和故障域配出来根本放不下或者放得下但容量告警。要算准必须先理解组件模型。2.2 容量公式从原始容量到可用容量的三段计算在做 vSAN Sizing 时我习惯把容量计算拆成三段每一段都有明确的公式和修正系数。第一段是原始容量。原始容量 每台主机的容量盘数量 × 单盘容量 × 集群主机数量。比如 4 台主机每台塞 6 块 1.92TB 的 SSD原始容量就是 4 × 6 × 1.92 ≈ 46TB。第二段是副本开销。默认存储策略 FTT1、RAID-1 镜像时数据实际写两份容量可用率是 1/2。FTT2 时写三份可用率 1/3。如果后续改用 RAID-5 或 RAID-6容量利用率会不一样后面会单独说。第三段是系统开销。vSAN 要为元数据、对象布局、快照暂存、各种内部操作保留一部分容量。这个值按经验大约占原始容量的 5% 到 10%。加上运维上通常希望集群容量使用率不超过 80%我一般直接在公式里乘一个 0.85 到 0.9 的系数。完整估算公式是可用容量 ≈ 原始容量 ÷ (FTT 1) × 0.9举一个实际算例。4 主机每主机 6 块 1.92TB 容量盘FTT1 镜像模式原始容量 4 × 6 × 1.92 ≈ 46TB副本开销后 46 ÷ 2 ≈ 23TB扣除系统余量 23 × 0.9 ≈ 20.7TB也就是说这 46TB 的裸盘量真正能拿来放虚拟机数据的大约 20TB 出头。如果你把这个误解成 46TB 可用那虚拟化平台上线后的第二个月就会收到容量告警。不同容错策略下的容量开销值得有个对比规划时可以拿来做取舍存储策略最小主机数数据组件分布容量开销可用容量占比RAID-1FTT1默认32 副本 1 见证2 倍约 50%RAID-1FTT253 副本 1 见证3 倍约 33%RAID-5FTT143 数据 1 奇偶校验1.33 倍约 75%RAID-6FTT264 数据 2 奇偶校验1.5 倍约 66.7%RAID-5 和 RAID-6 在主机数量允许的情况下容量优势非常明显。但它们的重建代价和性能抖动比镜像更值得关注后面章节会展开。闪存缓存盘的容量也必须进入 Sizing 的计算。全闪存 vSAN 中每个磁盘组需要一块 SSD/NVMe 作缓存盘缓存盘容量建议不低于该磁盘组内容量盘总容量的 10%。如果某个磁盘组挂了 6 块 1.92TB 容量盘组容量约 11.5TB那缓存盘至少要配 1.2TB 级别实际项目中常见的组合是 1.6TB 缓存盘配 6 块 1.92TB 容量盘。2.3 FTT 与 FTM 选型镜像、纠删码在不同主机规模下的取舍FTTFailures to Tolerate决定集群能容忍几台主机同时故障FTMFailure Tolerance Method决定用什么机制去实现这个容忍度。vSAN 提供了 RAID-1 镜像、RAID-5、RAID-6 三种数据放置方式选哪个不只看容量还要看主机数量和业务负载类型。镜像模式是最保守也最通用的方案。RAID-1 FTT1 只需要 3 台主机所有虚拟化负载都能跑性能衰减最小缺点是容量利用率低。如果业务对性能敏感、数据量不大这是最省心的起点。RAID-5 需要至少 4 台主机数据组件 3 份加 1 份奇偶校验用 1/3 的额外空间换来比镜像高得多的可用容量。代价是写操作需要计算校验值随机写性能比镜像差。适合测试开发环境、VDI 桌面池这类读多写少、对容量成本敏感的负载。RAID-6 需要至少 6 台主机数据组件 4 份加 2 份奇偶校验可以容忍任意两台主机同时故障容量利用率 66.7% 远好于镜像 FTT2 的 33%。但 RAID-6 的写放大最严重对磁盘 IO 压力大的业务需要谨慎。这里有个常见的翻车典型集群只有 3 台主机业务方却要求用 RAID-5 策略来省容量最后虚拟机根本无法放置因为 RAID-5 的最低主机数就是 4。在选择 FTT/FTM 之前先把主机数量清点清楚别让策略白设在虚拟机上。3. 从容量到拓扑vSAN 集群设计里的磁盘组与故障域规划3.1 磁盘组一块缓存盘加最多七块容量盘的组装规则磁盘组是 vSAN 的基本故障单元和性能单元。一个磁盘组由一块缓存盘和一到七块容量盘组成缓存盘负责承接写缓存和读缓存容量盘负责数据落盘。这些年版本的 vSAN 中每台主机最多支持 5 个磁盘组每个磁盘组最多 7 块容量盘。这里有一个必须理解的约束如果磁盘组里的缓存盘坏了整个磁盘组会变成不可用状态组内所有容量盘的数据都需要从其他副本重建。缓存盘承担的风险比容量盘大得多这就解释了为什么缓存盘要选高耐久度、高随机写性能的企业级 SSD而不是拿消费级固态凑数。磁盘组数量直接影响 vSAN 的性能上限。常见做法是先把每台主机的磁盘按“一个磁盘组”起步等验证稳定了再加第二个磁盘组。每主机的磁盘组数增加数据条带化的范围就越广单台主机的 IO 吞吐能力也随之提升但组件数量和元数据开销同样上升。磁盘组里缓存盘与容量盘的比例直接改的是整个集群的写缓存预算。全闪存架构下缓存盘容量应为所在磁盘组容量盘总容量的 10% 左右业界普遍按这个口径采购如果业务是强写入场景比如数据库日志盘、交易系统这个比例提到 15% 到 20% 更保险。混合架构下SSD 缓存与 HDD 容量的比例通常按 1:10 到 1:15 来配但混合架构本身已经在逐渐退出主流选择。3.2 故障域跨机架冗余的边界条件故障域是 vSAN 在主机之上引入的逻辑容错单位告诉 vSAN“哪些主机物理上挨在一起、可能同时断电或断网”。最常见的划分方式是让一个机架上的所有主机属于同一个故障域。vSAN 在放置数据副本时会尽量让多个副本分散到不同故障域从而避免一个机架断电导致全部副本同时丢失。这个机制的约束条件也很明确故障域数量必须大于或等于 FTT 1。简单说FTT1 至少要 2 个故障域FTT2 至少要 3 个故障域。实际落地时可靠的规划通常是故障域数量等于 FTT 2留出一个故障域作为重建空间。故障域规划跟主机数量强关联。比如一个集群有 6 台主机分布在 2 个机架每个机架一个故障域、各 3 台主机。这时候如果把策略设为 FTT2理论上需要 3 个故障域但实际只有 2 个vSAN 无法满足策略要求虚机策略校验会直接报错。正确的做法是给 6 台主机划分 3 个故障域、每个故障域 2 台主机FTT2 才能成立。还要注意故障域设计的粒度故障域数量少容错粒度粗数据可能集中落在少数几个故障域性能容易出现热点故障域数量多到每台主机一个容错粒度最细但无法抵御“一个机架断电”这类物理风险。怎么权衡取决于你的机房物理布局和业务能承受的故障半径。3.3 全闪存与混合架构的选择延迟预算和成本线的交点vSAN 的硬件架构有两条路线全闪存SSD 缓存盘 SSD 容量盘和混合SSD 缓存盘 HDD 容量盘。区别不只在性能更在 Sizing 的算法上。全闪存架构下vSAN 可以跑出亚毫秒级延迟。容量盘和缓存盘都是闪存介质随机 IO 性能高数据重建快适合承载数据库、生产业务虚拟机。这是当前绝大多数新建 vSAN 集群的选择。混合架构使用 HDD 作为容量盘成本低、容量大但延迟在 5ms 到 10ms 量级随机写性能受 HDD 寻道限制明显。网络带宽是 vSAN 选型时最容易被低估的一环。全闪存 vSAN 强烈建议使用 10Gbps 或更高带宽的业务网络混合架构虽然可以跑在千兆网上但重负载时的性能会很不稳定。曾经接触过一套混合架构跑在千兆网络上的集群主机间数据重建一启动业务 IO 延迟直接飙升到不可接受。在 Sizing 阶段把两者放在一张表里对比决策会清晰很多维度全闪存混合典型延迟0.5 - 1ms5 - 10ms随机写性能高受 HDD 限制推荐网络10Gbps 起1G 可用建议 10G每 GB 成本高低适用负载生产数据库、关键业务 VM归档、备份、容量型业务实际项目里混合架构如今更多被用于容量敏感、性能不敏感的场景。如果预算紧张到只能上混合架构那 Sizing 时对容量盘的转速、数量以及缓存盘的写寿命都要做更保守的估计。4. 把设计落进 vCenter主机启用 vSAN、建磁盘组与存储策略的完整动作4.1 启用 vSAN 服务前的主机检查项Sizing 算完接下来是把规划数字变成 vCenter 里的实际配置。在点“启用 vSAN”之前按下面清单过一遍能省掉之后大量排错时间。第一确认主机已经加入 vSAN 集群且集群层面的 vSAN 开关处于关闭状态。vSAN 集群的启用动作会直接影响集群内所有主机所以这个动作要放在业务低峰期做。第二确认磁盘控制器模式。vSAN 要求容量盘使用直通模式Passthrough或 RAID-0 单盘模式不能是 RAID5 或 RAID10 阵列。很多服务器出厂默认把磁盘配成 RAID1 或 RAID5不改成直通或 RAID-0vSAN 根本认不到盘。检查命令是vdq -q它会列出所有可以被 vSAN 使用的磁盘设备。第三确认磁盘是干净的。vSAN 启用时会格式化磁盘分区如果磁盘上还有旧分区或旧数据可能导致格式化失败或者误删数据。每块容量盘在加入前检查一下分区状态。第四确认网络就绪。vSAN 流量建议走独立 VLAN 和独立物理网卡MTU 9000 的所有节点保持一致。如果混合网络存在丢包vSAN 对象可能会出现健康告警。4.2 在 vCenter 里把磁盘组和存储策略配上检查项通过后开始真正的配置动作。以 vSphere Client 操作为例步骤如下。先启用集群的 vSAN 服务。进入集群的“配置”页找到 vSAN → 服务点击启用。此时 vSAN 会为集群中每台主机激活 vSAN 功能如果主机此前没有被加入到任何 vSAN 集群这一步会触发 vSAN 的初始化。启用后回到主机清单页主机的 vSAN 状态列会从“未启用”逐渐变成“运行中”。创建磁盘组。进入任意一台主机的“配置”页找到 vSAN → 存储点击“创建新磁盘组”。勾选一块缓存盘和同组的容量盘确认缓存盘容量不低于组内容量盘总容量的 10%。我习惯先给每台主机建一个磁盘组等集群性能和容量验证通过再考虑增加第二个组。配置存储策略。vSAN 的数据放置规则由虚拟机存储策略控制。在 vSphere Client 的“策略和配置文件”中新建一个存储策略添加规则时选择 vSAN然后设置 FTT、FTM、条带化数量等参数。默认策略建议 FTT1、RAID-1、条带化 1这适合大多数虚拟化负载。把策略关联到虚拟机。新建虚拟机时选择“虚拟机存储策略”为刚才创建的策略或在已有虚拟机上做“更新虚拟机的存储策略兼容性”。这一步容易被漏掉因为如果虚拟机用了“基于存储空间最大可用”这类非 vSAN 策略vSAN 的健康检查会一直报警。4.3 命令行验证esxcli 下确认 vSAN 状态的三条命令图形界面操作完成后我会再用命令行做三次验证确认 vSAN 真正处于健康状态。这三条命令在所有 ESXi 主机上都有是排查 vSAN 问题时最常用的三个路口。第一条是查看主机与 vSAN 集群的隶属关系esxcli vsan cluster get输出里的Cluster Config Status字段是关键。如果显示Configured说明主机已经作为 vSAN 集群成员工作正常如果显示Not Configured或者主机声称“在集群中但未启用”那问题就出在这一层。第二条是检查每块磁盘在 vSAN 中的参与状态esxcli vsan storage list这个命令会列出主机上所有已加入 vSAN 的磁盘设备包含缓存盘和容量盘各自的状态、所属磁盘组、设备 UUID。重点看Device State是否为Enabled以及容量盘是否被正确归入某个磁盘组。第三条是触发一次 vSAN 健康检查esxcli vsan health cluster list它会返回一系列健康检查项的结果包括磁盘级健康、网络级健康、对象级健康。如果有任何一项返回Warning或Error需要先解决再继续上一线业务。健康检查的响应时间取决于集群规模大型集群可能耗时几分钟这是正常现象。5. 避坑主机显示“尚未启用 vSAN 服务”与其它四个 Sizing 翻车现场5.1 现象主机已在 vSAN 集群状态列却挂“尚未启用 vSAN 服务”这是标题里那个热词对应的实际场景。vSphere Client 主机清单里主机确实在 vSAN 集群中但 vSAN 状态那一列写的是“主机位于 vSAN 集群中但尚未启用 vSAN 服务”。原因通常有三种。第一种是集群级的 vSAN 服务根本没有打开主机被加进集群了但 vSAN 开关没点所有主机都处于这个状态。第二种是主机加入集群时 vSAN 服务正在启动中主机的 vSAN 代理进程没有完成注册。第三种是主机时间与集群其他节点不同步导致 vSAN 的握手认证失败。解决路径也是按这个顺序来。先到集群的“配置 → vSAN → 服务”确认 vSAN 已启用如果已启用但主机还是这个状态在主机上执行esxcli vsan cluster get看配置状态如果依然异常检查主机和 vCenter 的 NTP 时间校准并把主机在集群中移除再重新加入一次。最简单高效的后悔药就是这步重启操作多数情况都能拉回来。5.2 现象Sizing 按三副本算好集群却报容量不足规划时明明按“所有 VM 总容量 × 2”算好了三副本需求实际启用后 vSAN 却警告容量不足。原因是容量计算里漏掉了三块隐性开销元数据、快照暂存和条带化产生的组件存储。vSAN 里的每个对象都包含元数据信息每台主机还有本地的 vSAN 内部数据管理结构这些会占用一部分真实容量。快照在 vSAN 中不是只存变更块而是可能触发新组件的创建。条带化如果设置大于 1每个条带成员都是独立组件组件数量增多元数据开销也成比例增加。解决方法是把容量估算公式从“可用 原始 ÷ 2”改成“可用 原始 ÷ (FTT1) × 0.9”并且在实际使用中维持集群容量告警阈值在 80%。宁可前期多留 15% 的空余容量也不要等业务虚拟机无法迁移时才去做紧急扩容。5.3 现象全闪存用了小容量缓存盘业务高峰期 IO 延迟飙升全闪存 vSAN 集群在监控里看到延迟从平时的 0.8ms 突然跳到 10ms 以上而且集中在业务高峰期。原因是缓存盘容量配得太小。vSAN 使用缓存盘做写入缓冲和读缓存如果缓存盘容量不足写入的数据会很快被迫刷到容量盘读缓存的命中率也随之下降。当所有虚拟机同时争抢有限的缓存空间时缓存盘本身还没瓶颈容量盘的写放大和读放大先一步拖垮了整个磁盘组。解决方法是回到缓存比例的规划。缓存盘容量按“所在磁盘组容量盘总容量的 10%”作为下限强写入负载直接按 15% 到 20% 配。另外要检查单台主机的磁盘组数量如果是多个磁盘组共用一个缓存盘那缓存容量完全不够需要重新规划磁盘组。5.4 现象三主机集群选了 RAID-5 策略虚拟机无法放置以为 RAID-5 能省容量改成 RAID-5 FTT1 策略后虚拟机创建时提示“策略要求的主机数量不足”或“虚拟机无法放置”。原因是 vSAN 的 RAID-5 要求至少 4 台主机。3 台主机上数据组件 3 份加奇偶校验 1 份物理上根本没有第 4 个位置可以放置校验组件。vSAN 的策略合规检查会直接拒绝放置。解决方法是两条路。如果集群短期内无法扩到 4 台主机把策略改回 RAID-1 FTT1接受 50% 的容量利用率。如果确实需要 RAID-5 的容量优势就加一台主机这是最直接的硬性条件。5.5 现象故障域数量不足 FTT1策略校验始终报错集群总容量够、主机数量也够但存储策略校验一直报“故障域数量不足”。原因是没有在主机层面配置故障域或者配置的故障域数量少于 FTT 1。vSAN 在放置数据副本时会强制要求副本落在不同的故障域里。比如集群 5 台主机没有划分故障域时每台主机算一个故障域FTT2 需要至少 3 个故障域就满足条件但如果把 5 台主机塞进了 2 个故障域FTT2 的策略就永远无法放置。解决方法是重新规划故障域划分。先在 vSphere Client 的“集群配置 → vSAN → 故障域”里确认当前故障域数量和主机归属再按“故障域数量 ≥ FTT 1”的原则调整。机架物理布局允许的话直接把故障域数量做到 FTT 2故障重建时留出冗余空间。6. Sizing 做完后怎么验收容量健康检查与一张落地检查单Sizing 和配置工作收尾时我习惯用一套固定的验收流程把规划数字和实际状态对齐。先跑一遍 vSAN 健康检查在集群的“监控 → vSAN → 健康”里查看对象健康、容量健康、网络健康三个大类。如果容量健康显示“已用容量与总容量比例”接近或超过预估的 80%就要回头核对实际的磁盘组和缓存配比。然后找一台测试虚拟机做真实的容量占用验证。给测试 VM 分配一块固定大小的厚置备虚拟磁盘迁移到 vSAN 数据存储上再去 vSAN 的“容量”页面观察物理占用是否与“磁盘大小 ÷ 容量利用率”的预期一致。厚置备 VMDK 在 vSAN 上的实际占用应当是虚拟磁盘大小乘以策略的容量开销误差超过 10% 就说明哪里算错了。最后按下面这张检查单逐项走一遍走完就敢把集群交给业务了检查项预期状态异常处理主机 vSAN 状态所有主机“运行中”主机重建 vSAN 服务磁盘组数量每主机至少 1 组查缓存盘容量比例缓存盘容量≥ 磁盘组容量盘总量 10%扩容缓存盘存储策略虚拟机与策略兼容重建策略并重新关联故障域数量≥ FTT 1重新划分故障域MTU / VLAN全部节点一致一致性排查这套动作做完集群的状态和规划的数字才算是真正对上了。vSAN Sizing 这件事最怕的不是算错一个公式而是算完公式就没再回头看实际集群。我自己的血泪经验是每次扩容采购前先把检查单跑一遍对着当前实际容量占用和测量出来的剩余空间再决定买多少盘、加几台主机。Sizing 不是一次性的事是可以反复用来避免后悔药的执行依据。希望帮到你。本文还有配套的精品资源点击获取