简介面向VMware虚拟化运维与架构设计人员这份vSAN扩容手册源于VMware GSS-China vSAN团队的售后最佳实践聚焦业务增长后的存储扩展问题vSAN作为虚拟化存储方案需要在不影响业务的前提下灵活扩容文档系统梳理了横向扩容增加vSAN节点、纵向扩容增加磁盘/磁盘组以及其他硬件扩容三类场景。全文按“扩容评估—备份配置—扩容前检查—实施扩容—扩容后检查”五步主线展开并给出每台主机最多五个磁盘组、每个磁盘组最多七块容量层磁盘、缓存/容量比例建议等关键约束帮助提前规避配置风险。压缩包内为单一PDF文档约4.62MB共分八个部分从扩容评估、健康状态检查到添加容量层磁盘、新建磁盘组、添加vSAN节点、其他硬件扩容再到扩容后检查步骤清晰内容还涉及vCenter和ESXi备份、网络要求如1Gb网卡需专用于vSAN全闪存建议10Gb链路等实践要点。已有588人学习/下载适合需要安全、无中断完成vSAN扩容的VMware管理员参考。1. vSAN 扩容为什么总是做一次折腾一次vSAN 的扩容在多数运维眼里是加盘、加主机、等同步但真正操作过的人都知道扩容本身不难难的是扩容之后集群的各种隐性失衡磁盘组分布不均匀导致容量告警反复出现缓存盘与容量盘比例失调拖慢整机性能甚至因为重建风暴把原本健康的节点拖进维护模式。标题里的这份《VMware vSAN 扩容手册 v1.1》本质上解决的就是这一类看起来简单、做起来要命的问题。它覆盖的并非某个 GUI 向导的点击顺序而是从容量计算、磁盘组结构设计到主机级操作和同步验证的完整流程适合负责 vSphere 集群日常运维的虚拟化工程师也适合刚接手 vSAN 环境、需要对扩容动作做标准化落地的平台管理员。先抛一个反直觉的结论vSAN 扩容的性能瓶颈通常不在新加入的磁盘而在旧有的磁盘组布局——很多集群扩容后容量充足但 IOPS 掉了一半就是因为新盘被自动堆进了同一个磁盘组造成单盘组的队列过载。这篇博文按一套可以照抄的路径来讲先看前置条件和容量模型再给三种扩容路径的具体操作接着处理重建中的坑最后落到验证和调优技巧。2. 扩容前的容量模型检查与磁盘组布局审计2.1 vSAN 容量计算里的三个隐藏参数vSAN 存储的不是裸容量而是经过策略修饰后的逻辑容量。默认策略下FTT1容忍一台主机故障意味着每份数据都有一份副本可用容量约为原始容量的 50%如果开启了 RAID-5/6 纠删码FTT1 使用 RAID-5FTT2 使用 RAID-6可用比例会变成 (n-1)/n 或 (n-2)/n其中 n 是参与的磁盘数。这个公式很多扩容评估都只算了个大概容易忽略的是主机故障域数和镜像条带化带来的额外开销——当策略里设置了Stripe Width 2单对象会横跨两个容量盘如果新扩容磁盘组只有一块盘容量检查能过但性能无法满足策略要求。我一般做扩容前容量审计会先让 vSAN 的容量面板显示可容忍故障数视角再用esxcli vsan storage list核对每个磁盘组的现有盘数。一个很容易被忽略的参数是 vSAN 中每台主机的组件数量上限默认 9000 个组件取决于主机型号扩容增加磁盘组后组件数上限不变但每个对象可能被拆分到更多组件导致组件数暴涨。所以扩容前不仅要看容量百分比还要用下面的命令检查当前组件数与主机上限esxcli vsan cluster get esxcli vsan health cluster list # 查看每台 ESXi 主机的组件数 for h in $(esxcli vsan cluster get | grep -i host); do echo $h ssh $h esxcli vsan debug object list | wc -l done上述命令里第一条拿到集群 UUID 和基本配置第二条做健康检查第三条按主机统计 debug object 数量虽然实际组件数建议到 vCenter 的vSAN 监控 物理磁盘里看但命令行更适合脚本化巡检。参数说明vsan cluster get会输出本机视角的集群状态如果 vSAN 处于已关闭或配置错误状态必须先恢复再扩容否则新加入的磁盘会被标记为不兼容或直接不参与聚合。2.2 磁盘组布局审计容量盘数量必须是规则数vSAN 磁盘组的标准结构是一块缓存盘SSD/NVMe加 1 到 7 块容量盘HDD 或 SSD。如果集群采用全闪存架构缓存盘承担写入缓冲和读缓存容量盘负责持久化数据。扩容时最常见的错误是往一个磁盘组里塞第 8 块容量盘——vSphere 版本不同上限不同但常规上限就是 7 块vSAN 7 及以后支持更多但最佳实践仍建议不超过 7。超标后磁盘组状态会变成不兼容数据不会迁移到新盘上表现为容量一直不变但告警却出现。在做扩容手册时我会先输出当前所有磁盘组的归属关系命令esxcli vsan storage list输出里重点看Is Hybrid、Is SSD、Has Capacity和VSAN Disk GroupUUID。把所有主机上的结果汇总成一个表格检查两点每个磁盘组里容量盘的数量是否一致缓存盘容量是否满足 10% 写入缓冲的推荐值。如果集群里某台主机只有 1 个磁盘组、容量盘 3 块而另一台有 2 个磁盘组、每个磁盘组 2 块那么扩容时应该优先补磁盘组数量少的那台让各主机的磁盘组数趋同这比单纯加容量更能提升数据重建的并行度。检查项推荐值操作建议每磁盘组容量盘数1~7全集群保持一致不一致时优先新增磁盘组而非加盘缓存盘容量比例全闪存 ≥10% 容量盘总容量不满足时先升级缓存盘再扩容主机间磁盘组数差异≤1差异大于 1 时先补齐磁盘组少的主机可用容量倍率至少留 20% 缓冲容量达 80% 必须扩容且此前的重建速度会下降表里这些数字不是死规矩但大量生产环境故障都发生在容量超过 80% 后的重建过程中——因为 vSAN 需要临时额外空间来生成副本容量越满重建越快触发Component Degradation。所以扩容手册的第一步不是拿新盘而是先算扩容后容量能否留足缓冲。如果扩容后可用容量依然低于 30%我会建议暂缓优先清理快照和无效虚拟机而不是盲目加盘。2.3 扩容前必须完成的三个健康项扩容动作会触发数据重新分布如果集群本来就有告警扩容会把小问题放大成大故障。我见过的几次扩容翻车都是没处理存量告警。健康检查命令可以一条条来esxcli vsan health cluster list esxcli vsan health cluster check --verbose第一条看整体健康第二条输出具体检查项的详细结果。重点关注Advanced C19 数据完整性、C17 集群对象状态和C11 网络配置。其中网络配置检查的是 vSAN 通信端口是否通、MTU 是否一致——很多扩容后同步慢的问题都出在 vSAN VMkernel 端口 MTU 是 1500 而物理交换机跑的是 9000导致数据包分片。除了集群健康还要看虚拟机对象是否处于活动状态。在 vCenter 里切换到监控 vSAN 虚拟对象筛选出状态不是活动的虚拟机记录它们的名称和受影响的磁盘组。这些对象在扩容重建时可能因为组件缺失导致新数据无法被复制必须先修复。修复命令用esxcli vsan health cluster repair注意这个命令会触发组件重新创建如果同时有主机处于维护模式建议先把维护模式退出再执行修复。修复完成后确认esxcli vsan health cluster list中所有项目都是正常再进入下一步。这一步做不做直接决定扩容过程是几小时还是一整天。3. 三种常见扩容路径的落地步骤与参数选择3.1 路径 A向现有磁盘组添加容量盘最常见也最安全的扩容方式就是往已有磁盘组里加容量盘。操作前需要在 vCenter 的存储 vSAN 磁盘管理里确认目标磁盘组处于正常状态然后把新物理盘插入对应主机的磁盘槽位。等待 ESXi 识别后在 vCenter 里刷新存储设备列表此时新磁盘会出现在未声明区域。命令行方式也可以做但需要拿到磁盘的 canoical nameesxcli storage core device list | grep -A 4 Display Name # 找到新盘的 naa 标识后声明为 vSAN 容量盘 esxcli vsan storage add -s disk_ssd_naa -d disk_capacity_naa-s指定缓存盘该磁盘组的缓存盘-d指定要添加的容量盘。如果只想声明为容量盘并自动归入某个磁盘组可以只指定-d参数vSAN 会按当前主机上可用的磁盘组自动选择。更推荐的做法是在 vCenter GUI 里勾选要加的磁盘再点添加到 vSAN这样不容易选错缓存盘。我一般给生产环境定的规则是一次只给一个磁盘组加一块盘等待重平衡完成后再加下一块。原因在于 vSAN 的 rebalance 是基于组件的迁移同时加多块盘会造成多个组件同时移动增加网络和磁盘 IO 负载。加完盘后集群容量会实时更新但组件重分布是异步的观察vSAN 监控 运行状况 数据重同步直到显示正常且组件同步百分比为 100%。3.2 路径 B新增磁盘组缓存盘容量盘组合当现有磁盘组的容量盘已经达到 7 块或者缓存盘性能不足时需要添加新的磁盘组。这一步在 GUI 里是选择一块 SSD 作为缓存盘再勾选若干容量盘。命令行的做法是esxcli vsan storage add -s new_cache_naa -d cap1_naa cap2_naa cap3_naa参数里的-s只能指定一个设备作为该磁盘组的缓存盘-d后可以跟多个容量盘。注意一旦磁盘组创建完成缓存盘的角色就固定不能再该只能通过删除磁盘组来变更。所以创建前必须确认缓存盘的容量和寿命满足未来的写入需求。新增磁盘组时需要考虑一个关键参数磁盘组的主机故障域位置。vSAN 允许同一个主机的多个磁盘组但不允许同一主机上的两个磁盘组同时容纳同一个对象的两个副本。所以在默认策略下只要每台主机有一个磁盘组数据冗余就是安全的。如果某台主机创建了两个磁盘组这不会增加故障容错能力反而会让该主机承载更多组件。因此我的建议是优先为磁盘组数量少的加组而不是给已有主机堆第二个磁盘组。另外vSAN 7 之后引入了混合磁盘组和全闪磁盘组的概念不建议在同一个集群里混用 HDD 和 SSD 容量盘否则性能策略会出现不可控的 IO 调度问题。新区中的所有磁盘组都应该保持相同类型。3.3 路径 C添加主机并加入现有集群扩容到主机维度属于横向扩容通常是为了增加计算资源或增加故障域。操作步骤不是简单的把主机加入集群vSAN 会自动将主机上的本地磁盘声明到集群。添加前需要确保新主机的 ESXi 版本与集群一致且 vSAN 许可证已包含所需容量。新主机加入集群时vSAN 会执行一次预检查检查项包括主机时间与 vCenter 的同步这正好对应热搜里那个主机和 vc 之间的时间已同步告警、网络配置、磁盘兼容性。如果新主机的时间偏差超过 5 分钟加入会失败或者加入后出现对象状态异常。解决方法是先配置 NTP再执行chkconfig ntpd on service ntpd restart然后重新加入集群。如果新主机有本地磁盘但未被识别为 vSAN 磁盘可以手动执行esxcli vsan cluster join -u cluster_uuid其中cluster_uuid可以通过现有主机上的esxcli vsan cluster get获取。注意新主机加入后vSAN 不会自动把已有数据迁移到新主机而是将新主机的磁盘组作为空闲容量。如果你希望数据分布得更均匀需要在 vSphere Web Client 中对虚拟机对象执行重新应用存储策略或者等待新虚拟机部署时自动利用新容量。扩容主机时最不该做的是让新主机单独形成一个孤岛磁盘组——如果新主机和旧主机的磁盘类型、容量差异过大vSAN 的容量均衡算法会尽量避免迁移数据到新主机导致新主机容量一直空闲其他主机容量持续告警。此时可以手动调整磁盘组容量比例但这个操作比较复杂我建议直接在扩容前就按同型号主机、同数量磁盘组的原则购置设备。3.4 三种路径怎么选一张决策表现网状况推荐路径原因磁盘组有剩余槽位容量不足路径 A成本最低重建影响面小磁盘组槽位已满或缓存盘性能不足路径 B提升并行度降低单点队列压力计算资源不足或需要增加故障域路径 C从架构层面扩展但需保证版本和磁盘一致性容量紧张且需要优化 IOPS路径 B 增加磁盘组数多个磁盘组有助于分散负载选择路径前一定要先执行第 2 章的审计否则容易做出先加盘、后拆盘的返工。尤其是路径 C如果集群启用了 vSAN 延伸集群Stretched Cluster新主机必须配置在正确的故障域否则数据会出现同故障域双副本的告警。4. 扩容中的数据重平衡与故障恢复避坑指南4.1 重平衡参数不要盲目提升 rebuild 速度扩容后数据会自动重平衡但 vSAN 默认的重平衡阈值是容量或 IO 不均衡达到 30% 以上才触发。如果只是加了少量磁盘可能不会立刻发生重平衡造成新盘容量空闲而旧盘容量满。这时可以手动强制重平衡esxcli vsan cluster rebalance -s这里-s是--silent只显示结果不交互。更细化的参数是设置重平衡的带宽限制esxcli vsan cluster rebalance --bandwidth-limit 100000带宽限制单位是 MB/s默认不限制。生产环境里我建议限制在物理网卡带宽的 50% 以内避免重平衡期间业务出现的延迟毛刺。重建rebuild参数同样需要关注。当某台主机故障后vSAN 会从副本重建数据到其他主机重建速度受vSAN.RebuildThreshold影响默认是 30 分钟即累计 30 分钟未完成则触发快速重建。这个参数在高级选项中调整esxcli vsan cluster set --rebuild-threshold 10设置成 10 分钟意味着当组件重建超过 10 分钟vSAN 会提高优先级但会占用更多 IO。如果扩容场景是加入新主机以替代故障主机建议把重建阈值调低让它激进地把数据从故障主机迁出。4.2 重建风暴的抑制流量控制与维护窗口扩容期间所有组件迁移会造成网络流量激增。vSAN 的默认行为是尽力而为不会主动限速但你可以通过给 vSAN VMkernel 端口设置流量整形来限制。在 vCenter 中选择 vSAN VMkernel 网卡编辑设置在流量整形中设置平均带宽和突发大小。这个整形会作用于所有 vSAN 流量包括正常 IO所以要谨慎设置。另一个做法是利用 vSAN 的机箱感知功能但这个与扩容关系不大更重要的是在扩容前把 DRS 设置为维护模式或半自动防止虚拟机在数据同步期间做 vMotion导致重建上下文切换。我一般在扩容窗口内会暂停涉及该集群的 Storage DRS 和 Storage I/O Control等重平衡完成后重新启用。4.3 扩容过程中的常见告警处理vSAN 集群上的主机和 vc 之间的时间已同步这是 NTP 告警如果扩容前没同步加盘时可能报错处理方式是先修 NTP 再刷新告警。vSAN 磁盘状态不兼容新盘如果是 SAS 或 SATA 接口与当前控制器模式不兼容需要检查 RAID 控制器是否为直通模式Passthrough或 RAID 0 模式的单独卷。vSAN 不认带 RAID 5/6 的虚拟磁盘只认每盘单独 RAID 0或 HBA 直通。组件状态降级扩容过程中如果看到黄色感叹号多半是网络丢包导致组件重同步失败。检查物理交换机端口收敛状态和 vSAN 网卡的丢包率用esxtop的n键查看网络统计。这些告警处理完毕后必须回到 vSAN 健康面板看一遍全绿才认为扩容动作完成。切忌只看容量数字上涨就收工。5. 扩容后的对象分布验证与磁盘组性能调优技巧扩容收尾不能只看容量要看数据是否真正均匀落盘。vSAN 有一个命令可以输出每个组件的分布情况esxcli vsan debug object list但这个输出太原始。更实用的是在 vCenter 里打开监控 vSAN 存储页面选择物理磁盘视图查看每块容量盘的已用空间。如果发现某个磁盘组的容量明显高于其他组可以对该磁盘组所在的虚拟机重新应用策略强制对象迁移。一个小技巧是创建一个零字节的临时虚拟机并部署到集群然后删除利用 vSAN 的对象生成与删除过程触发一次轻量重平衡让空闲容量被均匀填充。这个方法不需要手动干预适合轻微不均衡的情形。如果重平衡需要快速达成可以临时调整存储策略的Stripe Width从 1 改为 2保存后 vSAN 会重新分布对象但注意这会让容量消耗翻倍等均衡后再改回 1数据会再次迁移——有点折腾但比干等自动平衡快得多。最后说一个性能调优点扩容后检查缓存盘的预留空间。全闪存 vSAN 的缓存盘分为写缓存和读缓存默认写缓存占用不超过 70% 的缓存盘容量剩余为读缓存。如果扩容后感觉读取延迟升高可以调整缓存盘的读缓存预留百分比esxcli vsan storage set -u disk_uuid --read-cache-size 30参数里--read-cache-size是百分比建议值在 20~40 之间调调高后读命中率会提升但写缓存空间相应减少适合读密集型业务。调低则相反。修改后使用esxcli vsan storage list验证新的 cache 配置已经生效。如果你手上的环境还没有升级到 vSAN 7/8扩容前先检查去重压缩是否开启——去重压缩开启状态下容量计算会失效实际可用容量取决于数据的重复率。去重开启的集群扩容时新加的容量盘会先经历格式化和去重哈希构建阶段这一阶段磁盘显示为已挂载但不可用需要等到任务结束后才计入容量。因此去重环境扩容的时间要比非去重环境多出 30% 到一倍规划维护窗口时务必把这个时间算进去。验证去重生效可以用esxcli vsan storage list | grep -i dedup esxcli vsan debug object list --type host | grep -A 2 dedup如果输出显示 dedup 状态为 disabled那么新加的盘立即生效否则等待重建完成。整个扩容手册的核心思路就是先审计再选路径然后控制重建节奏最后验证分布。把这四步固化为一套 checklist每次扩容照做vSAN 集群会稳定得多。本文还有配套的精品资源点击获取