简介VMware vSAN 扩容手册 v1.1 是一份面向虚拟化运维工程师与架构师的实操型技术资料专注于解决企业业务增长时 vSAN 集群容量不足或性能受限的问题。手册将 vSAN 扩容明确划分为横向扩容增加 vSAN 节点、纵向扩容新增磁盘/磁盘组及其他硬件扩容三类并按照五个核心阶段展开扩容评估、备份 vCenter 与 ESXi 配置、扩容前健康检查、实施扩容、扩容后验证每个阶段都配有具体操作场景比如如何向现有磁盘组添加容量层磁盘、如何创建新的磁盘组、如何将新节点加入集群等便于按需查阅。同时手册给出了关键配置边界每台主机最多支持 5 个磁盘组每个磁盘组最多 1 块缓存盘加 7 块容量盘缓存与容量比例建议不低于 10%并提醒硬件配置差异可能影响性能与数据重建效率帮助读者在扩容前做好规划。资源为一个 PDF 文件压缩包整体大小 4.62MB内容结构清晰章节划分与常见运维任务对应且已有 588 人学习由 GSS-China vSAN 团队基于客户实际场景撰写对 vSAN 扩容项目具有较高的参考价值。1. 这套 vSAN 扩容手册解决的是机房里的“没空间了”三个字先说我拿到这份手册第一反应它不教你 vSAN 是什么而是直接回答“当前 vSAN 集群空间或性能不够了下一步该动哪颗螺丝”。手册开头就点破了扩容的本质——横向加节点、纵向加磁盘或磁盘组、其他硬件升级。整套操作流程按五步走评估、备份、前检查、实施、后检查。适合谁手里已经跑着 vSAN 集群需要在不中断业务的前提下给 Oracle RAC、SQL Server 这类关键业务腾出存储空间的一线运维和架构师。手册最值钱的地方是把“能不能扩、怎么扩、扩完怎么验证”拆成了可复盘的步骤而不是一篇纯概念科普。2. 动手前先看懂 vSAN 的硬性边界主机、磁盘组、网络三张表定生死vSAN 扩容第一个坑是硬件边界。手册第一部分花了大篇幅强调必须参考《VMware vSAN 硬件参考手册》上 VMware Compatibility Guide 逐项核对主机、磁盘、固件。这件事不是走流程而是你看不见的“兼容性黑匣子”——硬件不合规VMware 技术团队是可以拒绝对环境提供支持的。2.1 磁盘组与缓存/容量比决定你纵向扩容的上限vSAN 的存储逻辑不是以“块”为单位而是以磁盘组Disk Group为单位。每台 ESXi 主机最多 5 个磁盘组每个磁盘组里最多 1 块缓存层 SSD 加 7 块容量层磁盘缓存层通常占该磁盘组容量总和的 10% 以上混合模式和全闪模式都适用。这条限制直接决定你的扩容路径如果目标主机当前磁盘组没满“17”结构走第四部分加容量磁盘最省事如果磁盘组已经顶满就得看主机还有没有剩余槽位走第五部分加新磁盘组。我遇到不少用户一上来就横向加节点其实纵向就够用成本和耗时完全不同。具体规划时可以按这个逻辑排查看每台主机当前磁盘组数量是否小于 5小于 5 说明还能加磁盘组。看现有磁盘组中容量盘数量是否小于 7小于 7 说明能往已有磁盘组里塞容量盘。算缓存层容量与容量层总容量的比例是否低于 10%低于的话优先补缓存盘再谈扩容否则性能会明显失衡IO 延迟升高。2.2 网络选型1Gb 必须专用10Gb 才谈得上共享网络这块手册写得比较直白混合配置下1Gb 网卡必须给 vSAN 流量专用不能跟 vMotion、管理流量混跑只有 10Gb 及以上才允许共享。全闪配置则强制要求 10Gb 或更高带宽。原因其实好理解——全闪的吞吐量上来了如果还在 1Gb 链路上跑数据重建整网都会被拖死。另外一个细节是如果 10Gb 网卡在多流量类型间共享强烈建议开 Network IO Control防止某一种流量比如备份或 vMotion把带宽吃满vSAN 流量饿死。实际翻车场景我见过混合集群用 1Gb 共享给 vMotion迁移虚拟机时 vSAN 网络延迟暴涨健康检查弹网络分区告警。所以我建议做扩容评估时先建一张表核对当前环境再定扩容方向检查项最大/推荐值当前值结论每主机磁盘组数最大 5例如 1可纵向扩容每磁盘组容量盘最大 7例如 3可添加容量盘缓存/容量比推荐 10%例如 15%可保持网络带宽混合最小 1Gb推荐 10Gb10Gb 共享可接受注意限流磁盘固件与型号必须在 VCG 列表待查扩容前必查2.3 扩容前检查五个条件不满足就别往下走手册的第三部分列出了强制性的前置检查项很多人直接跳过结果扩容过程中数据同步把集群拖垮。我习惯把这五项当作准入条件当前运行的 vSAN、ESXi、vSphere 版本符合兼容列表。没有网络分区vSAN 健康检查中会明确显示是否有分区。所有 vSAN 磁盘状态健康。所有对象可访问。后台当前没有数据同步任务在进行。任何一项不满足都建议先建 VMware Support Request 排障不要带着问题扩容。手册在实验环境里展示了 4 节点集群、磁盘格式版本 V5、无网络分区、健康检查无报错、无后台同步这是扩容前最理想的状态。我血的教训是有一次没注意后台有对象重建任务就插了新盘新盘刚加入就被迫参与数据同步整个集群的 IO 延迟飙到 40ms 以上业务直接感受到了明显卡顿。3. 加容量盘是最高频的扩容操作从重新扫描到手动标注的全流程手册第四部分讲的是最经典的场景——向现有磁盘组添加容量层磁盘。这一步操作本身不复杂但坑全藏在细节里。我按手册流程配上实操经验拆给你看。3.1 新增磁盘的兼容性核对与物理识别新磁盘插上去之前先到 VMware Compatibility Guide 确认磁盘型号和固件版本。这一步很多老手会偷懒觉得“同型号的盘肯定没问题”。实际上固件版本不同就可能触发兼容告警VMware 是可以拒绝支持的。固件信息通常需要登录硬件厂商的管理界面查比如 iDRAC 或 XClarity不带电操作的话直接看盘体标签也行。磁盘物理装好后执行一遍存储设备重新扫描。常规做法是登录 ESXi Web Client在主机配置存储设备里点“重新扫描”或者命令行跑esxcli storage core adapter rescan --all这个命令会让 ESXi 重新枚举所有存储适配器上的设备。如果加了新盘但没重扫vSAN 不认很正常。重扫之后确认新盘出现在存储设备列表里并且系统能正确识别它是 SSD 还是 HDD。3.2 RAID 卡两种模式下的差异化配置这是文档里最容易看漏的一块。vSAN 对 RAID 控制卡有两种用法直通模式Passthrough/JBOD和 RAID 模式。直通模式下磁盘以独立的物理设备形式呈现给 ESXivSAN 直接管理RAID 模式下你需要先在 RAID 控制器里把单块盘配置成 RAID 0 或直通虚拟磁盘再交给 ESXi。如果厂商默认把 RAID 卡设成了 RAID 5 之类的模式vSAN 虽然也能看到盘但性能和可用性都不是 vSAN 预期的。操作上有两个注意点RAID 模式配置通常需要进 RAID 卡 BIOS 或管理软件部分场景要重启主机在 POST 阶段进配置界面提前联系硬件厂商确认是否支持热插拔配置必要时安排维护窗口重启。配置完 RAID 后必须再次做存储设备重扫确保 HBA 把新配置好的虚拟磁盘报给 ESXi。3.3 手动标注磁盘类型SSD 被识别成 HDD 的玄学手册特别提到一个冷门场景RAID 模式下ESXi 偶尔会把 SSD 识别成 HDD或者把 HDD 识别成 SSD。磁盘类型识别错误会导致 vSAN 把 SSD 当容量盘用缓存层规划全部乱套。遇到这种情况需要手动进行磁盘标注。具体在 Web Client 里选中误识别的磁盘点击“标记为 SSD”或“标记为 HDD”。从这里也能看出为什么手册一直强调“添加磁盘模式设为手动”——自动模式下vSAN 会自行决定给哪些盘分工手动标注容易被覆盖掉。3.4 vSAN 磁盘管理界面的添加操作确认主机已经正确识别新盘后进入 vSAN 的磁盘管理界面。操作路径是集群 配置 vSAN 磁盘管理选中目标主机的磁盘组点击“添加磁盘”勾选新识别到的磁盘。这里有个细节很容易踩坑如果下拉列表里没有新盘多数情况是磁盘分区表残留导致的需要在新盘上执行“清除分区”。清除分区路径主机 配置 存储设备 选中新盘 所有操作 清除分区。清完再回 vSAN 磁盘管理界面重试添加。整个步骤串起来核对兼容列表与固件版本确认新盘合规。物理安装磁盘根据 RAID 卡模式做直通或 RAID 0 配置。执行esxcli storage core adapter rescan --all重新扫描存储设备。确认 ESXi 能识别磁盘且磁盘类型正确必要时手动标注 SSD/HDD。集群 配置 vSAN 磁盘管理选择目标磁盘组点击添加磁盘。如果看不到新盘检查存储设备列表执行清除分区后重试。添加完成后验证磁盘已成功加入磁盘组。注意第 4 步不能跳过。手动标注看似多余但实际运维中非常有用。我经手过一个案例某品牌服务器 RAID 卡把 NVMe SSD 报成了 HDDvSAN 直接不认这个盘做缓存层手动标注后问题才解决。这就是典型的主机能识别、vSAN 不买账的场景。4. 加磁盘组和横向加节点两类扩容的实施逻辑与硬性限制第二部分讲完最普遍的加容量盘这一章把另外两招补齐加磁盘组和加节点。先说清楚适用条件再上操作避免你扩到一半发现架构不支持。4.1 加磁盘组的前提还有空余槽位且未达 5 组上限新建磁盘组的硬性条件是主机还有空余槽位并且当前磁盘组数小于 5。新建一个磁盘组必须有 1 块缓存层 SSD加至少 1 块至多 7 块容量层磁盘。换句话说你没法只建一个只有容量盘没有缓存盘的磁盘组。操作流程与加容量盘类似只是在 vSAN 磁盘管理界面选择目标主机而不是目标磁盘组然后点击“添加磁盘组”。在弹出的界面中分别指定缓存层磁盘和容量层磁盘。缓存层和容量层的选择有一个关键区别有些 SSD 只能作为全闪模式下的容量层磁盘不能作为缓存层 SSD。典型如大容量读取密集型 SSD生命周期写入能力有限扛不住缓存层的写入放大。所以选择缓存盘时优先选手册兼容列表里明确标注“支持缓存”型号的 SSD比如写入密集型的 SAS/SATA SSD 或 NVMe。4.2 加磁盘组的等待策略不要手动拖拽数据新磁盘组创建后vSAN 不会立即把数据搬过去。这里又回到 80% 阈值逻辑如果原有磁盘使用率没超过 80%vSAN 默认不触发主动再平衡。如果你想尽早利用新容量需要在 vSAN 健康检查的“磁盘平衡”模块手动触发再平衡任务。再平衡的触发位置集群 监控 vSAN 健康检查下拉找到“磁盘平衡Disk Balance”点击“重新平衡”。触发后 vSAN 会逐步把存量对象迁到新磁盘组上这个过程是后台异步任务不影响业务读写。但要注意再平衡期间不要同时执行其他重负载任务否则 IO 压力叠加可能引发健康检查告警。4.3 横向扩容增加 vSAN 节点时最容易忽略的三大项横向扩容手册放在第六部分核心是添加 vSAN 节点。增加节点同时带来计算资源和存储资源适合集群容量和性能都吃紧的场景。操作上先把新主机加入 vSphere 集群开启 vSAN 服务再创建磁盘组。但横向扩容有三项前置条件漏掉任何一个都可能让后续维护变成灾难新节点硬件必须在 VCG 兼容列表中尤其是 HBA 型号和驱动版本。新节点必须能访问所有 vSAN 网络包括与现有节点相同的 VLAN 和 IP 网段。DMA直接内存访问设置在特定硬件上要提前核对否则 vSAN 网络通信会异常。最容易漏的是网络配置。新节点加进集群后vSAN 会要求它与所有现存节点互通 vSAN 心跳流量如果只有部分互通集群可能进入分区状态。经验做法是加节点前先做三类流量管理、vMotion、vSAN的连通性测试确保新节点能 ping 通所有现存节点的 vSAN 端口。4.4 其他硬件扩容内存和网卡升级的注意点手册第七部分覆盖了一个容易被低估的场景——主机内存和网卡扩展。内存扩容主要影响 vSAN 的内存预留与缓存效率扩容后需要重启主机让固件和 ESXi 重新识别内存容量。网卡扩容通常是为了在 10Gb 共享链路上腾出更多带宽扩容后要确认 vSAN 流量使用的是新网卡并且在 Network IO Control 里给 vSAN 流量设置好优先级。这部分操作不复杂但记住一个核心原则改硬件后重扫并确认 vSAN 健康检查通过别急着把主机切回生产。5. 扩容避坑与排查五个现场最常翻车的真实案例这章是我个人认为这份手册最值得反复读的部分。如果你只按操作步骤走大概率会在下面这几个地方卡住。每条都按“现象 → 原因 → 解决”来拆。5.1 新盘在 vSAN 磁盘管理界面里不出现现象主机存储设备列表里能看到新盘但 vSAN 磁盘管理界面下拉列表为空。原因最常见的是新盘上有残留分区表vSAN 判断该盘不是“未使用”状态拒绝纳管。解决选中新盘执行“清除分区”操作清除后回到 vSAN 磁盘管理重新添加。如果清完还是不出现检查 RAID 卡是否把盘配置成了非直通模式vSAN 对待 RAID 卷的要求是单盘 RAID 0 或直通。5.2 添加磁盘后无法完成并提示磁盘类型无法识别现象添加磁盘组时SSD 被识别成 HDD或反之报错提示磁盘类型信息不符。原因RAID 卡固件或驱动对部分 SSD 的识别存在兼容性问题。解决在主机 配置 存储设备中选中该盘手动标注为 SSD 或 HDD。标注完成后vSAN 会按手动标注结果重新识别。注意手动标注只影响 vSAN 对该盘的使用方式不改变物理盘本身所以必要时可以结合厂商文档验证固件版本。5.3 主机位于 vSAN 集群中但新增节点未启用 vSAN 服务现象新节点加入集群后vSAN 面板显示该主机状态异常提示“主机位于 vSAN 集群中但尚未启用 vSAN 服务”。原因新节点加入 vSphere 集群后vSAN 功能默认不自动开启需要在主机 配置 vSAN 中手动启用。解决在新节点上“配置 vSAN 服务”选择与当前集群一致的 vSAN 模式混合或全闪然后等待 vSAN 状态变成“联机”。如果启用后仍然异常检查该主机的 vSAN 网络是否通重点看 vSAN 流量使用的 VMkernel 端口是否正常。5.4 扩容后整个集群出现网络分区告警现象完成扩容后vSAN 健康检查提示“网络分区”部分对象显示不可访问。原因新增节点或新磁盘加入时vSAN 流量带宽不足或 VLAN 配置错误导致节点间心跳包丢失。解决立即检查 vSAN 相关 VMkernel 端口是否在所有节点间互通。如果是 1Gb 混合场景确认 vSAN 流量独立占用一台物理网卡如果是 10Gb 共享场景确认 NIOC 中 vSAN 流量优先级未被压到过低。5.5 扩容后磁盘使用率严重不均衡新盘闲置现象新加的容量盘使用率长期低于 10%原有磁盘使用率却居高不下。原因vSAN 数据平衡的触发条件是原盘使用率超过 80%新盘加入后未触发自动再平衡。解决在 vSAN 健康检查中找到“磁盘平衡”手动点击“重新平衡”。如果执行后仍不迁移检查集群当前是否处于“低负载”模式数据平衡需要集群资源允许才会继续。6. 扩容后验证与数据平衡的主动控制守住这条底线即可安全交付扩容完成不意味着结束vSAN 集群要到“健康检查全绿”才算真正交付。我这里的习惯是每次扩容后都强制走一遍完整验证流程而不是只看一眼磁盘空间变大了就收工。验证动作分三步。第一步看“集群 监控 vSAN 健康检查”逐项确认无告警重点看“网络”、“对象完整性”、“磁盘健康”这三组。第二步用命令行检查磁盘组状态esxcli vsan storage list这个命令会输出每块盘所属的磁盘组、是否被 vSAN 使用、格式版本等详细信息。如果新盘出现在列表里且状态为“on”说明纳管成功。第三步关注数据均衡度。vSAN 健康检查页里有“磁盘平衡”视图它显示最大使用率与最小使用率之间的差值。差值超过一定比例说明集群数据分布不均此时手动触发一次再平衡让新盘尽快参与数据存储。再平衡期间注意观察“集群 监控 vSAN”下的后台任务等待活动任务全部清空。如果任务长时间卡在“同步数据”阶段检查集群内是否有对象处于“降级”状态。之前我遇到过一次任务卡死排查下来是有主机的磁盘组里一块盘掉线导致数据重建任务一直在重试。所以扩容后确认所有磁盘健康是所有后续操作的前提。从那以后我每次做 vSAN 扩容都会把“验证后调整数据平衡状态”作为最后一关宁可多等半小时让平衡跑完也不带着未完成的数据迁移任务收工。这套手册帮我少踩了不少坑也希望它能帮到你整理出更适合自己团队的扩容 SOP。本文还有配套的精品资源点击获取