简介：《VMware vSAN 扩容手册 v1.1》是一份面向 VMware 运维与虚拟化工程师的官方实践指南，针对业务增长带来的 vSAN 容量与性能瓶颈，系统讲解横向扩容（增加节点）、纵向扩容（增加磁盘/磁盘组）及其他硬件扩容三类场景。文档遵循“扩容评估—备份配置—扩容前检查—实施扩容—扩容后检查”五步流程，并给出每主机最多 5 个磁盘组、每个磁盘组 1 块缓存盘 + 7 块容量盘、缓存容量比例建议 10% 以上等关键配置要求，可帮助读者规避扩容风险。
资源为 1 个 PDF 文件，压缩包体积 4.62MB，文档目录清晰，覆盖主机、磁盘/磁盘组、网络配置要求及常见操作场景，适合在扩容前作为核对手册使用。已有 588 人学习，是 vSAN 运维人员值得收藏的参考材料。
1. vSAN扩容手册是干嘛的：容量告警之后，我为什么先看这份手册
vSAN集群亮黄灯，存储页面写着剩余容量不足5%，新建虚拟机卡在资源校验那一步——这种告警一出来，多半是要动扩容了。VMware vSAN扩容手册 v1.1.pdf 这类文档解决的正是两个问题：一是容量不够时怎么把存储池做大，二是扩容动作会不会把正在跑的业务干翻。vSAN不像传统SAN插块盘、映射个LUN就完事，它有自己的磁盘组、故障域和重同步机制，加盘顺序和策略错了，轻则容量不涨，重则全网卡顿。这份 v1.1 手册适合在维护 vSphere+vSAN 生产集群的虚拟化管理员，也适合接手别人集群后第一次做容量扩展的人。读它之前，先做一件事：搞清楚你的容量到底去哪儿了。
2. 扩容前的容量账与预检：FTT、缓冲容量与磁盘组配比
2.1 先算清楚“看起来够”和“真正可用”差多少
vSAN 的容量总被人当成玄学，其实它是能精确算出来的。打开 vCenter 里的 vSAN Datastore 容量页签，你会看到三组数字：原始容量、去重压缩后容量、可满足策略的容量。绝大多数扩容翻车，都是只看了第一组数字就动手加盘，加完发现业务还是写不进去。
可写容量的公式并不复杂：如果存储策略是 FTT=1 的 RAID-1，一份数据在集群里要放两份副本，那么裸容量要除以 2 才是可用容量；哪怕开了去重压缩，也不能按压缩后的最大值规划，因为压缩效果取决于业务数据，数据库和日志的压缩率可能差三倍以上。更稳妥的做法是在可用容量之上再留出 25% 到 30% 的缓冲，这部分是给组件重同步、主机维护模式撤离、临时快照和故障重建用的，没有缓冲的 vSAN 集群像一个没有备用胎的车，看着能跑，一坏就趴窝。
我一般会在扩容前给集群做一张容量账，大概长这样：
| 项目 | 数值 | 说明 |
|---|---|---|
| 容量盘规格 | 1.92TB SSD × 2 / 主机 | 全闪容量盘，不含缓存盘 |
| 集群节点数 | 6 | 常规业务集群 |
| 裸容量 | 约 23TB | 所有容量盘物理总量 |
| 存储策略 FTT=1 RAID-1 | 可用约 11.5TB | 两副本，除以 2 |
| 预留 30% 缓冲 | 建议按 8TB 规划 | 给 Resync 和维护模式留余地 |
这张表做完，你才能真正回答“集群到底缺不缺容量”。如果缺的是可用容量，加盘有用；如果缺的是缓冲容量，加盘也能缓解，但根本问题是策略副本数和对象分布不合理，得先调策略，再谈扩容。
2.2 磁盘组结构与缓存/容量配比：加盘前必须知道的限制
vSAN 的存储不是把盘直接扔进数据存储里，而是按“磁盘组”组织。一个磁盘组由一块缓存盘和若干块容量盘组成，缓存盘负责读写缓存和元数据，容量盘负责真正落数据。加盘前如果不懂这个结构，扩容时最容易犯的错误就是：往一个磁盘组里无脑塞容量盘，塞到超过上限，或者缓存盘和容量盘的配比失衡。
不同版本的 vSAN 对单个磁盘组的容量盘数量有上限，常见约束是 7 个左右。这不是物理限制，是 vSAN 架构设计的边界，超过后性能和故障恢复都会出问题。所以当一台主机要加大量容量盘时，正确的做法往往是新建一个磁盘组，而不是把现有磁盘组塞满。
配比方面，我一般按“缓存盘容量约为该磁盘组总容量盘的 10%”作为起点，也就是常说的 1:10。NVMe 缓存盘性能高，可以放到 1:12 到 1:15，但超过 1:15 要慎重，因为缓存盘还要承担写缓存刷盘和去重元数据，太小了会变成性能瓶颈。混闪架构（SSD缓存+HDD容量）同样建议不低于 1:10，宁可缓存大一点也别让它写穿。
磁盘组配比是我做扩容预检时最看重的一项。很多扩容后性能不升反降的案例，不是盘不够好，而是新磁盘组的缓存盘太小，容量盘一大，vSAN 把数据搬过去后，写缓存直接被打满，延迟直线上升。加盘之前，先数一下每台主机的缓存盘型号和容量盘型号，别混用读写性能差太多的盘。
2.3 扩容前的预检清单：兼容性、健康状态与主机模式
扩容不是插盘动作，而是变更动作。我的习惯是：头一天晚上先把 SSH 打开，逐个主机跑一遍预检命令，把结果截下来留底。重点看三件事：vSAN 健康检查是否全绿、集群里有没有主机处于“不健康”状态、加盘目标主机的磁盘控制卡是否支持直通。
# 在任一台 ESXi 的 ssh shell 中执行 esxcli vsan health cluster list esxcli vsan cluster get vdq -iesxcli vsan health cluster list会触发一次 vSAN 健康检查，重点看“硬件兼容性”和“磁盘格式版本”两项。如果硬件兼容性报警，说明新盘可能不在 vSAN 兼容列表里，这时候加进去也能用，但 vSAN 不支持会一直报，后续升级也可能出问题。esxcli vsan cluster get是看这台主机当前的 vSAN 集群状态，扩容前确认它已经正常加入集群。vdq -i列出的是“尚未被 vSAN 认领”的未使用磁盘，扩容前跑它，你能一眼看到新插的盘到底有没有被系统识别成可用设备。
预检清单最后的重点是目标主机要不要进入维护模式。加容量盘其实可以在线做，不需要把主机挪进维护模式，但如果你要在原有磁盘组里更换缓存盘、或者动 RAID 卡配置，就必须进维护模式，并且选“确保数据可访问”。这个动作会让主机上的所有组件撤离，如果集群没有足够缓冲，撤离会卡住。所以预检的最后一步是：确认目标主机的可用容量，够不够撑起一次完整撤离。
3. 纵向扩容（Scale Up）：向已有主机加盘的操作顺序与 Resync 控制
3.1 加盘前先确认新盘被 ESXi 识别且未被 vSAN Claim
纵向扩容是“加盘不加节点”的做法，适合集群节点数足够、但容量或性能不够的场景。操作看起来简单，就是插盘、认领、等待，但实际上最容易宰在这一步：盘插入服务器后，ESXi 里看不到，或者看到了但 vSAN 不认。
先确认 ESXi 是否识别到新盘。在主机 SSH shell 里执行：
esxcli storage core device list esxcli storage core device partition listesxcli storage core device list会列出所有存储设备，包括本地盘、直通盘和 RAID 卡下的虚拟盘。你要找的是新插入的设备，设备名一般是naa.开头的 WWN。如果这里看不到新盘，先查硬件层：盘是不是没插到位、RAID 卡是不是把盘配置成了单盘 RAID 0、直通模式有没有覆盖新槽位。我曾经遇到过一次，新盘在 BIOS 里能看到，但 ESXi 里死活不出现，最后发现是 RAID 卡把新槽位默认吞进了全局热备池。
看到设备后，再跑一次vdq -i，这个命令输出的是“vSAN 可用但尚未认领”的磁盘列表。如果新盘出现在这里，说明它是干净的、可以被 vSAN 认领；如果没出现，多半是盘上有残留分区表或者之前被别的软件定义存储用过。这时候用esxcli storage core device partition list查看设备上的分区，确认没有数据残留后清理分区表再做认领。注意：清理分区前必须确认盘上没有数据，vSAN 认领磁盘会直接格式化，这个动作没有后悔药。
3.2 用 vSphere Client 创建磁盘组：一次只动一台主机
确认磁盘干净后，认领动作我建议在 vSphere Client 里完成，路径是：选中目标主机 → 配置 → vSAN → 磁盘管理 → 认领磁盘。界面里会区分“缓存盘”和“容量盘”，系统会自动推荐，但建议手动确认角色，尤其是多块同型号盘插在一起时，别让系统把缓存盘和容量盘的角色搞反。
如果这台主机之前没有磁盘组，需要先选择一块盘做缓存盘、再勾选一块或多块盘做容量盘，建一个新的磁盘组；如果主机已有磁盘组并且组内还有空余位置，可以把新容量盘加入现有组。我一般会优先加进现有组，因为新建磁盘组意味着多了新的缓存盘和元数据开销，对容量增长帮助是一样的，但新建组会触发更多组件重分布。
认领完成后，用命令验证一次：
esxcli vsan storage list vdq -qesxcli vsan storage list会列出本机所有已认领的 vSAN 磁盘及其所属磁盘组，数一下容量盘数量和组号，确认新盘在列。vdq -q输出磁盘组级别的摘要，能直接看到每个磁盘组的缓存盘和容量盘对应关系。
这里有一个非常关键的操作纪律：一次只动一台主机。哪怕你有六台主机，每台要加两块盘，也别在主界面里把六台一起勾选认领。vSAN 的一次跨主机认领会同时触发大量组件重建，存储网络瞬间被打满，业务 IO 直接崩溃。一台一台来，每台认领完等 Resync 清零，再做下一台。
3.3 让 Resync 不拖垮业务：窗口、限速与节奏
容量盘认领完成后，vSAN 不会立刻把新空间投入使用，它会在后台做对象重平衡——把现有对象的部分组件搬到新盘上，这个过程就是 Resync。Resync 本身是正常的，但它会占用磁盘 IO 和网络带宽，在业务高峰期触发时，对延迟敏感的业务几乎是毁灭性的。
我的习惯是：扩容动作放在业务低峰窗口，认领完一盘后，先观察每个主机的 Resync 状态，等全部清零后再做下一批。查看 Resync 状态可以在 vSphere Client 的 vSAN 健康页面看“重新同步”项，也可以在各主机的esxcli vsan debug object list输出里看对象层面的修复进度。
如果业务不能停，但又必须在白天扩容，vSAN 的重同步限速就很有用。在集群的“配置 → vSAN → 服务 → 重新同步”里，可以调节带宽和 IOPS 上限，我一般会把上限压到正常值的 30% 到 50%，让 Resync 慢慢跑，而不是一口气冲。另一个常用手段是调大组件修复延迟：
# 在目标 ESXi 上执行，单位毫秒；默认为 60000 毫秒 esxcli system settings advanced set -o /VSAN/ClomRepairDelay -v 300000ClomRepairDelay是 vSAN 的组件修复延迟参数，含义是“检测到组件异常或需要重新平衡时，等多久再触发修复”。默认 60 秒，扩容高峰期我习惯临时调到 300 秒，给业务 IO 和 Resync 错峰。注意这是全局参数，改完后不需要重启，但要记得在扩容结束后调回默认值，否则集群的故障恢复速度会被拉慢。
4. 横向扩容（Scale Out）：加主机、启用 vSAN 与故障域规划
4.1 新主机进集群前：许可证、兼容性与启动 vSAN 服务
横向扩容是加主机。适合集群节点本身已经吃紧、或者单主机容量盘槽位已经加满的情况。规模较大的集群里，加主机还有一个好处：vSAN 的故障域和存储策略能得到更好的满足，RAID-5 和 RAID-6 策略需要的主机数量也能补上来。
新主机加入前，我一般会做三件确认。第一是许可证：vSAN 许可按 CPU 核数或容量计算，不同版本的许可模式不一样，新主机加进来如果超出许可范围，vSAN 会进入“未授权”状态，数据不会丢，但所有策略和健康检查都会报警。第二是硬件一致性：新主机的 CPU 微码、内存规格、网卡固件尽量与现有节点保持一致，尤其是 vSAN 流量所在网卡的队列深度和延迟特性，混用网卡容易在后端出现延迟毛刺。第三是磁盘兼容列表：新主机自带的缓存盘和容量盘型号，最好和存量磁盘组规格一致，因为 vSAN 会跨主机分布组件，混用性能差异大的盘可能导致慢盘拖垮整个对象。
主机加进 vSphere 集群后，第一个要处理的告警往往就是“主机位于 vSAN 集群中，但尚未启用 vSAN 服务”。这是正常的，因为主机刚加入集群，还没有真正启用自己的 vSAN 数据服务。在 vSphere Client 里进入集群 → 配置 → vSAN → 服务，点击启用即可。也可以用命令行完成：
# 在目标 ESXi 上执行，cluster-uuid 用 esxcli vsan cluster get 获取 esxcli vsan cluster get esxcli vsan cluster join -u <cluster-uuid>这里要特别提醒：esxcli vsan cluster join是把这台主机拉进指定 UUID 的 vSAN 集群。如果手滑写错了 UUID，主机可能加入一个完全不相干的测试集群，导致数据组件错乱。我一般只在脚本化交付场景用它，日常操作优先走 UI，因为 vCenter 会做准入检查，比裸命令安全得多。
4.2 故障域：多机柜扩容的从入门到不翻车
集群主机数变多以后，只做“跨主机副本”是不够的。如果六台主机全在同一个机柜，机柜断电就等于整个 vSAN 集群断电，所有副本一起消失。故障域的价值就是把“主机级容错”升级为“机柜级容错”。
在 vSphere Client 的集群 → 配置 → vSAN → 故障域里，可以把主机划分到不同的故障域。扩容时新主机进集群后，第一件事不是急着认领磁盘，而是先把它放进正确的故障域。故障域的数量和存储策略是联动的：
| 故障域数量 | FTT=1 RAID-1 | RAID-5 / RAID-6 | 适用形态 |
|---|---|---|---|
| 2 个 | 支持 | 不支持 | 两个机柜，各放一半主机 |
| 4 个 | 支持 | RAID-5 可考虑 | 常规多机柜生产环境 |
| 6 个 | 支持 | RAID-6 可考虑 | 高可用要求较高的集群 |
注意，RAID-5 至少需要 4 台主机，RAID-6 至少需要 6 台，即使你划分了 6 个故障域，主机总数不够，策略照样无法满足。故障域规划和扩容容量规划要一起做：加主机时不仅看容量增量，还要看故障域内主机数量的对称性。我见过一个生产集群，扩到 8 台主机后，前 6 台在一个故障域、后 2 台在一个故障域，RAID-5 策略表面合规，实际两副本都落在同一个机柜里，机柜断电瞬间业务全挂——这就属于扩容时没带故障域视角。
4.3 扩容后的容量再均衡与策略合规检查
主机加完、故障域分完，新主机认领磁盘后，vSAN 容量已经变大，但对象的组件分布不会立刻变均匀。vSAN 不是一台“主动均衡”的存储，它只在组件创建、修复和 Resync 时才搬移数据。所以新容量加入后，你可能会看到新主机上的磁盘组空着大半，老主机上的磁盘组反而快满了。
要让数据均匀铺到新主机上，常见做法是在虚拟机存储策略上执行“检查合规性”和“强制重新应用”。路径是：选中虚拟机 → 存储策略 → 检查合规性，确认策略满足后，重新应用一次策略。vSAN 会重新评估对象组件的位置，把部分组件分布到新主机。对多数存量虚拟机，这个动作可以批量做，但要注意它同样会触发 Resync，节奏上和纵向扩容一样，别一次性全选 500 台虚拟机一起重应用。
验证组件分布的命令是：
esxcli vsan debug object list这个命令输出每个 vSAN 对象及其组件的分布情况。我一般会重点看：组件是不是集中在少数主机上、同一个对象的多个组件是否落在了同一个故障域或同一个磁盘组里。如果发现组件扎堆，说明当前存储策略的放置约束没生效，需要回 UI 里检查策略配置，而不是继续加盘。
5. vSAN 扩容避坑：5 个常见报错与排查记录
5.1 集群报“主机位于 vSAN 集群中，但尚未启用 vSAN 服务”
现象：新主机加入集群后，vCenter 弹出一条告警，说主机位于 vSAN 集群中，但尚未启用 vSAN 服务。主机的 vSAN 数据存储没有出现在容量列表里，但集群配置页里已经能看到这台主机。
原因：主机只是被加进了 vSphere 集群，但 vSAN 服务还没在这台主机上启动。这个状态在“先加主机、后启 vSAN”的扩容流程里很常见，也可能是因为主机之前处于维护模式，维护模式退出后 vSAN 服务没有自动拉起。
解决：进入集群 → 配置 → vSAN → 服务，确认 vSAN 已启用。如果 UI 上已经启用但仍然报错，在目标主机上执行esxcli vsan cluster get，看输出里的 Cluster UUID 和主集群是否一致。不一致就执行esxcli vsan cluster join -u <正确的集群UUID>，然后再看告警是否消失。这个告警不会丢数据，但它会导致新主机的容量不参与集群可用容量计算，属于必须消除的状态。
5.2 盘插上去，容量却没涨
现象：物理盘插入、ESXi 也认到了，vSAN 数据存储的容量页签却没有任何反应。新盘像失踪了一样。
原因：磁盘没有被 vSAN 认领。最常见的是三种：磁盘型号不在 vSAN 兼容列表里，vSAN 直接过滤掉；磁盘上残留旧分区表，vdq -i里不出现；盘被 RAID 卡配置成了单盘 RAID 0 或全局热备盘，ESXi 只看到了一个空聚合设备，而不是独立的直通盘。
解决：先用vdq -i确认盘是否处于“unused”状态，再用esxcli storage core device list核对设备是否被 ESXi 正确识别。如果是 RAID 卡的问题，需要进 RAID 卡管理界面把盘改成直通模式或 JBOD，再扫描存储设备。如果盘上面有残留分区，清理分区后重新执行认领。注意别用esxcli vsan storage add去强制认领不兼容的盘，vSAN 可能认领成功，但后续健康检查会持续报警，甚至导致整个集群硬件兼容状态变红。
5.3 Resync 风暴把业务 IO 打到个位数
现象：扩容当天业务正常，一到夜里，监控上存储延迟飙高，虚拟机 IO 掉到近乎不可用。查看 vSAN 健康页，发现大量对象处于“重新同步”状态，组件修复进度条刷屏。
原因：一次在多个主机上认领了大量磁盘组，或者扩容前集群里已经积累了太多待修复组件。vSAN 检测到新容量加入后，会集中触发组件重建和重分布，所有主机的 IO 和网络同时被 Resync 打满。
解决：这是做 vSAN 扩容最常见、也最能体现操作纪律的问题。严格做到“一次一台主机、每批认领完成等 Resync 清零再继续”。如果已经发生风暴，先把集群里“重新同步”的带宽和 IOPS 限速调低，压住修复节奏，再用esxcli system settings advanced set -o /VSAN/ClomRepairDelay -v 300000拉长修复延迟，给业务 IO 让路。Resync 是后台操作，慢一点不影响数据安全，不需要恐慌。
5.4 维护模式卡在 0%：容量缓冲不足
现象：把主机进入维护模式，选择“确保数据可访问”，任务一直卡在 0%，主机上的组件撤离不出去。有的管理员等半小时后强退维护模式，结果数据完整性报警。
原因：集群没有足够的空余容量来容纳这台主机撤离出来的组件。也就是说，这台主机承载的数据副本，在集群其他位置放不下了。这往往不是扩容本身造成的，而是扩容前没有留出缓冲容量，或者扩容后存储策略副本数偏高、可用容量被策略吃掉了大半。
解决：先别强推任务。回到容量页看可满足策略的容量，确认集群是否还有空余。如果没有，先删除无用快照、清理孤立 VMDK、临时调整部分虚拟机的存储策略降副本数，把空间腾出来，再重新执行维护模式撤离。扩容前把缓冲容量当成硬性指标，正是为了避开这个坑——卡在 0% 的维护模式是 vSAN 集群最无力的一刻。
5.5 扩容后性能反而下降：缓存/容量盘配比失衡
现象：容量明明变大了，业务虚拟机 IO 延迟却从 1ms 涨到 10ms 以上，尤其是在写入峰值时段。性能页里某个磁盘组的热度异常高，其他磁盘组很闲。
原因：新磁盘组的缓存盘容量太小，或者缓存盘和容量盘的读写性能差太大。vSAN 的写入会先落缓存盘，缓存盘写满再回写到容量盘。缓存盘太小，回写动作变频繁，容量盘的性能短板就全部暴露出来。
解决：扩容前先算配比，全闪架构缓存盘与容量盘容量比保持在 1:10 以上，NVMe 缓存盘也尽可能不要低于 1:15。如果已经出现配比失衡，可以把新盘所在磁盘组的容量盘拆一部分到现有缓存充足的磁盘组里，或者在业务允许的情况下重建磁盘组——但重建代价较大，需要先把数据搬走再删组，建议只在性能问题严重影响业务时操作。更现实的方案是：调整虚拟机存储策略的放置规则，让高 IO 的虚拟机组件优先落在缓存充足的磁盘组上，给新磁盘组一段观察期再说。
6. 扩完怎么验收：容量、健康状态与策略合规检查
6.1 三分钟验收命令
每次扩容后，我不会急着关 SSH 窗口，而是花三分钟跑一组验收命令，确认这次扩容是真的做完了，而不是“看起来做完了”。
esxcli vsan storage list vdq -q esxcli vsan health cluster listesxcli vsan storage list看每台主机新增的磁盘组和容量盘是否都在线，重点确认没有盘处于“degraded”或“absent”状态。vdq -q看磁盘组摘要，数一下每台主机的磁盘组数量是否和预期一致。最后跑一次esxcli vsan health cluster list，等它跑完，看健康检查里与磁盘、容量、硬件兼容性相关的条目是不是全绿。
在 vCenter UI 里还要看两个数字：vSAN 数据存储的总容量是否比扩容前增加了预期值，以及“可满足策略的容量”是否也跟着涨。只涨原始容量、不涨可用容量，说明策略副本数或预留空间把新增容量吃掉了，这样的扩容效果要打问号。
6.2 应用视角的最终验证
命令全绿不代表业务视角没问题，我习惯再选一台测试虚拟机，做一次存储策略的“检查合规性”，然后强制重新应用策略。重新应用后，去虚拟机 → 存储 → 对象里看组件分布：新增主机或新增磁盘组里是否出现了组件，同一个对象的组件是否分散在不同故障域。如果组件全部赖在老盘上不动，说明策略放置规则有问题，或者集群的组件重平衡还没触发，可以再等一个窗口，或者选择一台虚拟机做一次 Storage vMotion 来回迁移来触发重平衡。
最后看一眼 Resync 状态是否清零，如果还有组件在修复，说明扩容引入的数据搬移还没结束，这时候不要进行下一次硬件变更。
vSAN 扩容做完后，真正的验证要等到第一次主机维护模式撤离顺利通过才算完整。我自己现在每做一次扩容，都会在窗口里留一条习惯：每个窗口只做一件事，做完看 Resync 清零，再走下一步。vSAN 的后悔药不在扩容之后，而在扩容之前——预检做得够细，扩容就是个低风险操作；预检偷懒，扩容就是开盲盒。希望帮到你。
本文还有配套的精品资源，点击获取
