简介面向虚拟化运维工程师与vSphere架构师这份VMware vSAN扩容实践手册以PDF格式提供系统梳理vSAN集群在业务增长后的扩容方法与操作流程。文档详细覆盖横向扩容增加节点、纵向扩容添加磁盘/磁盘组以及增加内存、网卡等硬件扩容场景并按“扩容评估—备份配置—扩容前检查—实施扩容—扩容后检查”五个关键阶段展开便于现网环境按步骤落地。手册同时说明了每台主机最多5个磁盘组、每个磁盘组最多7块容量层磁盘等配置上限以及缓存层与容量层容量比例建议能帮助运维人员提前规避规划风险内容还适用于vSAN 5.5/6.x等版本环境。压缩包内为1个PDF文件大小4.62MB内容结构和排版比较适合打印对照操作目前已有588人浏览学习适合需要为vSAN集群做容量扩展的运维与架构设计人员参考。1. vSAN扩容手册到底在解决什么事一次加盘翻车后的复盘如果你接过一次 vSAN 扩容大概率经历过这种场景集群负载还没到顶但可用容量只剩几个百分点业务方催着加盘。你按直觉往主机里塞了几块 NVMe在 vSphere Client 里点了半天最后发现新盘显示“未认领”或者集群弹出一堆黄色告警重同步像蜗牛一样爬。这份《VMware vSAN 扩容手册 v1.1》要解决的正是这类“看着简单、做起来全是细节”的扩容动作。它不讨论 vSAN 是什么而是直接把扩容路径拆成可复现的步骤容量测算、加主机还是加盘、缓存盘怎么配、命令怎么敲、重同步怎么看。适合的人群是一线虚拟化运维和刚接手 vSAN 集群的工程师——你不需要懂 vSAN 的存储堆栈源码但你需要知道扩容时哪些参数动了会导致数据重分布哪些盘不能随手拔以及为什么同样的步骤在不同版本里结果不一样。2. 扩容前的容量测算与磁盘组规划先算账再动手2.1 先搞懂 vSAN 磁盘组和 FTT否则加错盘等于白加vSAN 的存储结构是“磁盘组Disk Group”驱动的每个磁盘组由一块缓存盘和多块容量盘组成缓存盘负责读写缓存容量盘存实际数据。加盘之前先得搞清楚集群当前的 FTT允许故障数策略。FTT1 意味着每个对象存两份副本你加的每 1TB 裸容量实际可用只有差不多一半如果开了 RAID-5/6vSAN 8 的擦除编码可用比例会变高但重建时的 CPU 和网络开销也会变大。这个逻辑必须放在最前面因为它直接决定扩容方向。集群 FTT1 时加一块 2TB 容量盘vSAN 实际可用最多约 1TBFTT2 时可用只有约 0.67TB。很多扩容手册都会先给一张对照表就是为了让你在买盘之前算清楚“加了等于没加”的尴尬境地。常见做法是先登录 vCenter在 vSAN 的“容量”页面看“已用空间”和“剩余空间”再去 vSAN 的“故障域”里确认主机数量最后结合 FTT 策略算出真实可扩容空间。2.2 容量能加多少用一张表算清有效容量我一般会把扩容前测算做成一张固定格式的表填完就知道这次扩容是不是值得做。表里的关键项是裸容量、FTT 复制系数或擦除编码开销、vSAN 自身预留默认会保留一部分空间用于维护操作、以及对象开销少量元数据。项目示例值说明计划新增裸容量8 × 2TB NVMe计划加盘的总物理容量FTT 策略FTT1镜像每份数据占 2 倍空间可用系数1/2 0.5镜像副本开销vSAN 预留约 25%用于重同步、快照等实际有效容量8×2×0.5×0.75 6TB最终可用增量这张表的参数不是拍脑袋定的。vSAN 预留比例我习惯按 25% 算因为在生产集群里重同步、换盘、对象修复都会临时占用空间预留太少会让集群进入“无剩余空间”状态。如果你的集群开了去重压缩可用系数可以往上调一些但建议先保守测算去重率在真实业务里波动很大按 1.5 倍估算已经算乐观了。2.3 选加主机还是加盘两个方向的开销对比扩容并不只有“往现有主机加盘”一条路。往集群里加新主机等于同时增加计算资源和存储资源还顺带提升了 vSAN 的故障域数量往现有主机加盘则只增加容量不改变主机数量。选择依据有几个一是集群主机数量是否低于 3 台低于 3 台时加盘没有意义因为 vSAN 最少需要 3 台主机承载数据副本二是现有主机的磁盘槽位和控制器通道是否够用三是新增主机是否要额外购买 vSAN 许可。对比一下开销加盘方案只需要买硬盘和可能的托架操作是热插拔加命令行认盘加主机方案要买整机、迁移配置、网络布线还要考虑新主机和现有主机的硬件型号是否一致。实操中很多环境在 vSAN 8.x 下倾向于加主机因为新主机还能分担计算压力但扩容手册里最常见的路径仍然是“现有主机加盘”毕竟成本低、流程短。选型建议是如果你的集群主机数正好 3 台且业务增长缓慢优先加盘如果主机数已经 5 台以上、距离槽位上限还有空间按需加盘更稳妥。3. 命令行手动扩容全流程从 cd 到重同步完成的完整操作流3.1 扩容前的环境自检确认集群状态和磁盘识别手动扩容前先确认 vSAN 集群状态健康。就算 vCenter 上看起来一切正常也建议 SSH 登录到目标主机用命令行过一遍环境。vSAN 的集群 UUID 可以在 vCenter 的“vSAN 群集”页面查看但命令行直接拉更稳。# 查看当前主机是否已加入 vSAN 集群以及集群 UUID esxcli vsan cluster get # 查看本机所有磁盘以及它们是否被 vSAN 认领 vdq -q # 查看 vSAN 集群整体健康状态在任意一台主机上执行 esxcli vsan health cluster list这段命令的逻辑是先确认主机已经在集群里再用 vdq 区分出“已被 vSAN 使用”的盘和“空闲待认领”的盘。vdq -q 输出里有一列 DiskMatch会标示盘是否还能被 vSAN 吸纳。如果输出为空或者看不到新插入的磁盘说明磁盘没有被 ESXi 正确识别要先到存储适配器里做一次重新扫描。esxcli vsan health cluster list 会返回一系列检查项比如“vSAN 对象可访问性”“容量预留”等有红色的项就先解决别带着病扩容。3.2 把主机拉进 vSAN 并新建磁盘组新主机加入 vSAN 集群后默认不会自动创建磁盘组。这里就是很多教程说不清的地方主机已经显示“位于 vSAN 集群中”但 vSAN 服务没有真正启用磁盘组。手动创建磁盘组的命令行步骤是固定的。# 在新增主机上创建磁盘组-s 指定缓存盘-d 指定一块或多块容量盘 esxcli vsan storage add -s mpx.vmhba1:C0:T1:L0 -d mpx.vmhba1:C0:T2:L0 -d mpx.vmhba1:C0:T3:L0 # 查看磁盘组是否创建成功以及使用状态 esxcli vsan storage list这条命令的关键参数是 -s 和 -d。缓存盘只能指定一块容量盘可以跟多块官方建议一个磁盘组里容量盘不超过 7 块我实际用下来 5 块左右最稳太多会导致缓存盘 IO 排队严重。磁盘设备名不要凭记忆敲先用ls /dev/disks或者vdq -q拿到准确路径。设备名类似 mpx.vmhba1:C0:T1:L0复制粘贴最安全。创建磁盘组时 vSAN 会自动格式化磁盘并开始往上面放置组件这个过程没有任何确认提示敲下去就执行了。3.3 给已有磁盘组加容量盘并观察重同步如果不想新建磁盘组而是给已有磁盘组加一块容量盘命令更简单。但要注意新加的容量盘只会让磁盘组容量变大不会自动均衡已有数据。# 给已有磁盘组添加一块容量盘 esxcli vsan storage add -d mpx.vmhba2:C0:T4:L0 # 查看当前集群内所有重同步任务和状态 esxcli vsan resync get # 查看所有 vSAN 存储对象的状态 esxcli vsan storage list加盘后vSAN 会在后台启动重同步resync把部分对象迁移到新空间上。重同步的速度受限于主机间的网络带宽和磁盘 IO 能力。esxcli vsan resync get 会列出正在同步的对象数量、剩余数据量以及预估完成时间。日常习惯是加完盘后等 10 到 15 分钟再用esxcli vsan storage list看新盘是否已经出现“online”状态。如果 resync 进度长时间停在某个数值不要急着拔盘先查网络层常见原因是跨主机通信走了一条带宽不足的上联链路。4. 缓存盘与容量盘的匹配逻辑SSD 换型、磁盘组重建的那些坑4.1 缓存盘为什么要按比例选型vSAN 对缓存盘和容量盘的比例有硬性约束缓存盘容量不能小于对应容量盘容量的 10%这是官方要求实际生产中我建议按 15% 以上配。比如一个磁盘组里放了 4 块 2TB 容量盘总容量 8TB缓存盘至少要有 800GB否则 vSAN 会拒绝创建磁盘组。很多扩容翻车就是因为“手里正好有一块 400GB 的旧 SSD凑合当缓存用”结果报错。更隐蔽的问题是缓存盘的寿命。vSAN 的写缓存会持续吸收写入流量对 SSD 的耐久度要求远高于容量盘。扩容时如果新增了容量盘缓存盘的写放大也会增加。选缓存盘时不要只看容量还要看 DWPD每天全盘写入次数我一般要求缓存盘 DWPD 不低于 3容量盘可以放宽到 1 以下。一个磁盘组里缓存盘和容量盘的寿命差距过大会导致缓存盘提前报废换缓存盘又必须重建整个磁盘组代价非常大。4.2 SSD 替换和磁盘组重建的正确顺序扩容时最怕遇到缓存盘故障——vSAN 不允许你只换缓存盘然后等待同步因为缓存盘没了整个磁盘组上面的对象都会进入“不可用”或“降级”状态。正确做法是先把该磁盘组上的对象迁移走再移除磁盘组换盘后重建磁盘组。命令行操作顺序如下。# 1. 把某个磁盘组里的所有组件迁移走-d 指定要移除的容量盘 esxcli vsan storage remove -d mpx.vmhba1:C0:T2:L0 # 2. 删除整个磁盘组-s 指定缓存盘 esxcli vsan storage remove -s mpx.vmhba1:C0:T1:L0 # 3. 更换新硬盘后重新创建磁盘组 esxcli vsan storage add -s mpx.vmhba1:C0:T5:L0 -d mpx.vmhba1:C0:T6:L0这条流程有几个细节必须守住。第一移除容量盘后vSAN 会把上面的对象重新分布到其他磁盘组期间集群负载会明显上升操作窗口尽量选业务低峰。第二移除 -d 和移除 -s 不能同时执行如果直接 remove -svSAN 会拒绝提示磁盘组还有容量盘存在。第三换上的缓存盘容量不能小于原缓存盘否则重建时可能因为容量不足失败。这一套流程做下来单个磁盘组的重建通常在 1 小时以内但如果集群本身没有剩余空间兜底时间会拖长到数小时。4.3 别碰的骚操作直接拔盘、随手 removal、跨磁盘组把盘切走我见过最典型的翻车操作是新加了一块大容量盘想把它从某个磁盘组“借用”给另一个磁盘组直接登录 vCenter 点了移除然后立刻插到别的槽位。vSAN 的磁盘组和物理槽位绑定不严格esxcli vsan storage remove 之后磁盘上的分区标记会被清掉如果再手动分区vSAN 会彻底不认这块盘。另一个常见错误是扩容时为了图快把新主机加入集群后不做“声明磁盘”直接退出维护模式。结果是主机被 vSAN 集群识别了但它的磁盘全是“未认领”状态集群容量一点没涨。碰到这种情况回到 3.2 的步骤重新执行esxcli vsan storage add即可但要知道在此期间新主机上的虚拟机数据并没有得到 vSAN 存储保护。扩容时我习惯把每一步操作都写在纸上做完一步打个勾磁盘组的创建和删除这种不可逆动作尤其不能凭记忆操作。5. vSAN 扩容的常见问题与排查现象、原因、解决5.1 主机显示“位于 vSAN 集群中但尚未启用 vSAN 服务”现象在 vCenter 里看主机状态那一栏写着“位于 vSAN 集群中但尚未启用 vSAN 服务”集群容量没有增加vSAN 数据存储也没有变化。原因通常是主机只是加入集群但没有创建磁盘组或者 vSAN 服务没有启动。解决方法是先确认服务状态再手动创建磁盘组。# 确认 vSAN 服务是否运行 esxcli vsan cluster get # 如果集群 UUID 为空重新加入集群 esxcli vsan cluster join -u vsan-cluster-uuid # 创建磁盘组后再次确认 esxcli vsan storage add -s 缓存盘 -d 容量盘1 -d 容量盘2如果是已有磁盘组但服务没起来重启 vSAN 服务能解决一部分问题。但要注意不能只 join 集群就完事join 之后 vSAN 不会自动“抓取”未认领的磁盘。这条排查是扩容场景里出现频率最高的也是搜索引擎里相关词长期挂在榜上的原因。5.2 新磁盘状态是“未认领”vdq -q 看不到现象物理磁盘已经插进主机ESXi 也能在“存储设备”列表里看到它但 vdq -q 输出里没有这块盘vSphere Client 里显示“未认领”。原因多半是磁盘之前被别的文件系统或 RAID 控制器写过元数据分区表残留导致 vSAN 识别失败。解决方法是先确认磁盘设备名然后清掉分区表再让 vSAN 认领。# 查看磁盘设备名 ls /dev/disks # 清除磁盘分区表设备名替换成实际名称务必确认盘符 partedUtil mklabel mpx.vmhba1:C0:T4:L0 msdos # 重新扫描存储适配器 vmkfstools -V # 让 vSAN 认领该磁盘 esxcli vsan storage add -d mpx.vmhba1:C0:T4:L0这里最危险的一步是 partdedUtil mklabel执行前要拿磁盘序列号反查物理位置确认没有认错盘。清分区表操作不可恢复如果盘里本来有数据这一步直接清零。扩容场景里新盘一般不会有数据但如果有“借调”过来的旧盘这个步骤就得三思。5.3 重同步卡在某个百分比不动现象加完盘后 vSAN 显示有重同步任务但进度条长期停滞比如 96% 一停就是半小时。原因通常不是 vSAN 本身故障而是带宽瓶颈所有主机共享同一对上联网络vSAN 的重同步流量和业务流量互相争抢。解决方法是限速或调整重同步流量优先级vSAN 8 里可以针对网络 IO 做流量整形。# 查看 vSAN 网络流量配置 esxcli network ip get # 限速 vSAN 重同步流量带宽单位为 Mbps esxcli vsan resync throttle set --incoming 100 --outgoing 100重同步卡住的另一个常见原因是目标磁盘组上没有足够空间。前面章节提到预留比例不够就会导致对象无法完成重新分布表现为进度卡在 99%。检查方法很简单看 vSAN 容量页面有没有“空间不足”警告。如果空间不足别再等赶紧清理快照或者加更多的盘不然重同步永远结束不了。5.4 扩容后集群亮黄对象健康度下降现象扩容操作结束后vSAN 集群健康状态从绿色变黄部分存储对象显示“不健康”或“重建中”。原因可能是扩容过程中有一台主机被移入维护模式时选择了“确保可访问性”但数据迁移没有全部完成就提前退出了维护模式。也可能是新磁盘的速度不达标vSAN 判定缓存盘不满足性能要求。解决思路是先确认对象的实际状态再决定是等待还是介入。# 列出所有不健康对象 esxcli vsan health object get # 查看对象的具体告警原因 esxcli vsan debug object get -d object-uuid如果是“重建中”状态通常等着就行vSAN 会自动修复如果是“无冗余”状态说明该对象只有一份副本可用此时不能再执行任何磁盘组重操作否则数据可能丢失。最稳的善后是确认所有对象恢复到绿色后再离开机房。扩容最忌讳的是“加了盘就算完事”对象没有回到健康度后续业务故障就都是你的锅。6. 扩容后的验证与收尾用几条命令确认这次扩容真的成功了6.1 用健康检查和容量统计验证扩容结果扩容结束不代表可以关窗口。我习惯用一组固定命令做收尾验证每一条都有明确目的。esxcli vsan health cluster list 负责整体健康度esxcli vsan storage list 负责确认新盘已经被认领并加入磁盘组vdq -q 负责确认没有漏网之鱼。# 整体健康检查 esxcli vsan health cluster list # 确认新增磁盘组/容量盘状态 esxcli vsan storage list # 确认没有盘处于 unclaimed 状态 vdq -q这三条跑完再看 vCenter 上 vSAN 的“容量”页面如果显示的剩余容量和测算表里算出来的有效增量对得上这次扩容才算闭环。对不上的时候不要直接收工先查是不是 FTT 策略和测算表不一致或者有没有对象仍然处于“无冗余”状态。扩容手册的价值就在这种地方不只看当前操作成功还要看结果是否符合预期。6.2 把“扩容手册 v1.1”沉淀成自己的 checklist我自己的习惯是把这份手册的流程浓缩成一张卡片贴在生产环境的操作记录里。这张卡片正面是步骤背面是禁忌。正面写四步容量测算、环境自检、执行扩容、验证收尾背面写五条红线不确认缓存盘比例不动手、不确认磁盘组无数据不移除、不在重同步时拔盘、不跳过收尾检查、不在集群无预留空间时扩容。这套动作持续练下来扩容从“紧张事”变成“流程事”。vSAN 的玄学大多来自“看着操作成功但实际状态不对”而避免玄学的最好办法是让每一步都有命令输出可以对照。如果你正在准备一次 vSAN 扩容哪怕手册已经很详细也建议先找一个非生产主机把命令完整跑一遍看到 resync 结束后再上生产。这台验证机花的时间会帮你省掉生产环境里几小时的排障时间。希望帮到你。本文还有配套的精品资源点击获取