简介《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 手册适合在维护 vSpherevSAN 生产集群的虚拟化管理员也适合接手别人集群后第一次做容量扩展的人。读它之前先做一件事搞清楚你的容量到底去哪儿了。2. 扩容前的容量账与预检FTT、缓冲容量与磁盘组配比2.1 先算清楚“看起来够”和“真正可用”差多少vSAN 的容量总被人当成玄学其实它是能精确算出来的。打开 vCenter 里的 vSAN Datastore 容量页签你会看到三组数字原始容量、去重压缩后容量、可满足策略的容量。绝大多数扩容翻车都是只看了第一组数字就动手加盘加完发现业务还是写不进去。可写容量的公式并不复杂如果存储策略是 FTT1 的 RAID-1一份数据在集群里要放两份副本那么裸容量要除以 2 才是可用容量哪怕开了去重压缩也不能按压缩后的最大值规划因为压缩效果取决于业务数据数据库和日志的压缩率可能差三倍以上。更稳妥的做法是在可用容量之上再留出 25% 到 30% 的缓冲这部分是给组件重同步、主机维护模式撤离、临时快照和故障重建用的没有缓冲的 vSAN 集群像一个没有备用胎的车看着能跑一坏就趴窝。我一般会在扩容前给集群做一张容量账大概长这样项目数值说明容量盘规格1.92TB SSD × 2 / 主机全闪容量盘不含缓存盘集群节点数6常规业务集群裸容量约 23TB所有容量盘物理总量存储策略 FTT1 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 → 故障域里可以把主机划分到不同的故障域。扩容时新主机进集群后第一件事不是急着认领磁盘而是先把它放进正确的故障域。故障域的数量和存储策略是联动的故障域数量FTT1 RAID-1RAID-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 的后悔药不在扩容之后而在扩容之前——预检做得够细扩容就是个低风险操作预检偷懒扩容就是开盲盒。希望帮到你。本文还有配套的精品资源点击获取