企业官网建设流程全解析

简介：面向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 存储的不是裸容量，而是经过策略修饰后的逻辑容量。默认策略下，FTT=1（容忍一台主机故障）意味着每份数据都有一份副本，可用容量约为原始容量的 50%；如果开启了 RAID-5/6 纠删码（FTT=1 使用 RAID-5，FTT=2 使用 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 块，那么扩容时应该优先补磁盘组数量少的那台，让各主机的磁盘组数趋同，这比单纯加容量更能提升数据重建的并行度。

表里这些数字不是死规矩，但大量生产环境故障都发生在容量超过 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 name：

esxcli 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 三种路径怎么选：一张决策表

选择路径前一定要先执行第 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 集群会稳定得多。

本文还有配套的精品资源，点击获取