企业官网建设流程全解析

1. 先想清楚要解决什么问题：为什么分布式存储会长成这个样子

聊 vSAN 之前，我想先说一个挺典型的场景。前几年帮一家做精密零部件的中型企业改造虚拟化平台，原来的架构是"三台服务器 + 一台中端存储阵列"，跑 ERP、MES、文件服务，总共三十来台虚拟机。问题不在于性能不够，而在于扩容方式极其别扭：存储控制器插槽满了，加盘只能换整机；盘坏了一块，整个阵列要进降级模式跑几个小时重建，那段时间所有业务都提心吊胆；再往后想上新业务，采购流程要先算阵列的控制器、缓存、许可、维保，报价单比服务器本身还贵。后来他们换成超融合，用 vSAN 把每台服务器本地的 NVMe 盘聚成一个共享存储池，扩容就是"加一台服务器，把它插上网线、加入集群"，存储容量和计算容量一起涨，这才算把这件事理顺了。

所以 vSAN 是什么，一句话讲：它是把一组 ESXi 主机本地磁盘聚合成一个共享的分布式存储池，用软件实现冗余、策略和容灾，替代传统外置存储阵列。它能干的事情包括给虚拟机提供带副本或纠删码保护的数据存储、通过存储策略给不同业务分级保护、跨站点做双活或拉伸集群、以及在两节点的小规模场景做直连部署。适合谁来参考这篇文章：已经在用虚拟化平台、正在评估超融合、或者已经在跑 vSAN 但总感觉"性能上不去""扩容之后反而变慢""组件不合规天天报警"的运维和实施人员。如果你只是想了解名词解释，那看官方文档更快；这篇更偏向于把架构原理、策略计算和调优手段串起来，讲清楚每一步为什么这么做。

真正让 vSAN 区别于"把本地盘做成 RAID"的关键设计有三点。第一，它把存储保护需求从磁盘层面抬到了对象层面，一个虚拟磁盘就是一个对象，对象由若干组件拼成，每个组件的副本放在哪台主机、用镜像还是纠删码，全部由存储策略（SPBM）声明，而不是由某块 RAID 卡决定。第二，它的 I/O 路径是分布式的，写入不经过某个中心节点，客户端主机自己算好数据该落到哪几台主机上，直接并发写过去。第三，它把"容量不够"和"性能不够"这两个问题的解法分开了——容量靠加盘加主机，性能靠网络带宽、缓存设备和并发条带，不用再被阵列控制器的规格卡住。理解了这三点，后面所有的调优动作才有落脚点，否则很容易变成"照着参数表乱改"。

2. 架构拆解：一个虚拟磁盘从写入到落盘要走哪些路

2.1 对象、组件与那条容易被忽略的 I/O 链路

虚拟机里的一块 VMDK，在 vSAN 里是一个对象（Object）。如果策略是"允许 1 个主机故障、镜像"，那么这个对象会被切成若干个组件（Component），每个组件有两个副本，分别落在不同主机上，另外还可能带一个**见证组件（Witness）**用于在脑裂时投票。默认情况下一个对象由多个组件构成，具体数量跟对象大小、条带宽度（Stripe Width）有关。为什么要切成组件而不是整块复制？因为切分之后，数据可以分散到多台主机、多块磁盘上并发读写，吞吐能随主机数量线性增长；同时故障影响面也被限制在单个组件上，重建时只需要搬那一个组件，不是整个卷。

写入路径大致是这样：运行虚拟机的那台主机（客户端主机）上的DOM（Distributed Object Manager）负责这次 I/O 的归属判断和分发，它把写请求并行发给持有该对象组件的几台主机；每台目标主机上的LSOM（Local Object Manager）接收后写进本地磁盘组的缓存层；CLOM管集群层面的对象归属和再平衡，CMMDS维护集群成员和对象目录，相当于整个集群的"黄页"。这套软件栈全在 VMkernel 里跑，对 Guest OS 完全透明——虚拟机里看到的只是一块普通 SCSI 磁盘。

这里有个实战中特别容易忽略的点：I/O 是走网络的，而且往往是跨主机的。如果你配了镜像策略，一次写要在两台主机上落盘才算完成，那么网络时延和丢包会直接变成虚拟机的写时延。很多"vSAN 性能不如本地盘"的抱怨，追下去都是网络层的问题，而不是磁盘不行。我后面在排查章节会展开讲。

2.2 磁盘组：缓存层和容量层的分工逻辑

传统架构（OSA，Original Storage Architecture）里，每台主机的本地盘要先建成磁盘组（Disk Group），一个磁盘组 = 1 块缓存设备 + 若干块容量设备。缓存设备必须是可以承受高写入的 SSD/NVMe，容量盘可以是 SSD 也可以是 HDD（混合模式）。缓存层承担两件事：全闪存配置下它是写缓冲（Write Buffer），写先落缓存，攒到一定大小再顺序下刷到容量层；混合配置下它还要额外承担读缓存，通常按 70% 读、30% 写来分配。

为什么全闪存不做读缓存？因为容量层本身就是闪存，读命中率和时延已经够好了，再拿宝贵的写寿命去缓存读数据属于浪费。而混合模式下 HDD 随机读很慢，必须靠 SSD 兜住热点，所以缓存层的角色完全不同。这就是为什么"缓存盘容量该配多大"这个问题没有统一答案：全闪存看的是写缓冲深度，一般建议缓存容量不低于容量层总容量的 10%；混合模式看的是热点数据集大小，实践中常见 10%~30%，具体要看业务读放大的程度。

vSAN 8 之后引入了ESA（Express Storage Architecture），取消了传统磁盘组的概念，改成每台主机一个统一的存储池，NVMe 设备直接以"存储池 + 大块"的方式管理，写路径也做了重写（日志结构化、大块追加写），显著降低了写放大。ESA 对硬件要求更严格（基本就是全 NVMe + 较高主频 CPU），但对新部署来说，如果硬件允许，直接上 ESA 是更省心的选择。我个人的判断标准很简单：新采购、全 NVMe、CPU 有余量，就用 ESA；如果是在利旧老服务器、混插 SATA SSD，那还是 OSA 更稳妥。

2.3 网络平面：vSAN 流量为什么必须单独拎出来

vSAN 的通信走 VMkernel 适配器上勾选的"vSAN"服务，标准做法是给每台主机建一个专用的 vSAN VMkernel 口，配独立 IP，绑定到独立的物理上行（或者至少是独立的 VLAN）。原因不复杂：vSAN 的流量特征跟管理流量、虚拟机业务流量完全不同，它是突发的大块顺序写 + 大量小包确认，跟 vMotion 抢带宽的时候会互相拖累。你把它和 vMotion 挤在一块网卡上，做一次批量迁移，vSAN 的重同步就会跟着慢下来。

MTU 是最经典的坑。vSAN 建议端到端 9000 字节巨型帧，但要求链路上每一个环节都一致：物理交换机端口、上行链路、vSwitch、VMkernel 口。只要有一处是 1500，就会出现"小包能通、大包丢失"的诡异现象——集群能建起来，健康检查显示网络正常，但一跑压力测试吞吐就腰斩，日志里全是重传。我在第二个章节会给出具体的验证命令。

还有一个常被问到的问题：能不能做链路聚合？物理层面做冗余当然可以，但 vSAN 流量实际是由 VMkernel 适配器绑定到某块物理网卡上的，LACP 那种把多条链路聚成一条逻辑链路的方式，对单个 vSAN 流的带宽提升非常有限。所以想提高吞吐，正确姿势是提高单块网卡的速率（10G 起步，25G/100G 更好），而不是捆四块 1G 网卡。这一点跟很多人的直觉相反，但确实是这样。

2.4 集群形态与故障域：不同规模该选哪种打法

vSAN 的集群形态直接决定了可用性和成本，选型前必须想清楚。标准集群最少 3 台主机，允许 1 个主机故障需要至少 3 台（FTT=1 镜像），允许 2 个主机故障需要至少 5 台。两节点集群用一台见证主机（Witness Appliance）在第三方位置投票，适合分支机构和边缘场景；**拉伸集群（Stretched Cluster）**是两个站点各若干主机 + 第三站点见证，站点间做同步镜像，能做到站点级容灾，但对站点间时延敏感（一般要求往返时延在 5ms 以内，越低成本越高）。

故障域（Fault Domain）这个概念很多人不用，但它在机柜级容灾时很好使。默认情况下每台主机就是一个故障域，副本不会落在同一台主机上。如果你有机柜级的供电或散热风险，可以把同一机柜的主机划进同一个故障域，这样副本就不会被放进同一机柜，规避整柜掉电导致数据全丢的极端情况。代价是需要更多主机才能满足同样的 FTT 要求。要不要用，看你的机房条件和业务等级，别为了"看起来专业"硬上，最后容量算不平。

3. 存储策略实战：RAID 选型、容量开销与落地方法

3.1 FTT 与 RAID 的组合边界，先搞清楚约束再谈方案

存储策略里两个核心参数是允许的故障数（FTT）和容错方法（RAID 类型）。镜像（RAID-1）最简单，FTT=1 就是两份，FTT=2 就是三份，开销分别是 2 倍和 3 倍。纠删码（Erasure Coding）用校验块换空间，RAID-5 支持 FTT=1，RAID-6 支持 FTT=2，容量开销明显更低，但代价是写入要算校验、重建时读放大更大、对 CPU 有一定要求。

组合的硬性约束必须背下来，否则策略建出来就是不合规的。RAID-5 在 vSAN 里需要至少 4 台主机参与（3+1 是最小形态，还有 4+1、6+1 等配置），RAID-6 需要至少 6 台主机（4+2 最小，还有 6+2 等）。这些都是"参与的主机数"，不是"集群主机数"——如果集群有 6 台主机但只允许 3 台落数据（比如其余主机磁盘满了），策略照样不合规。另外，纠删码只适用于全闪存集群，混合集群只能用镜像，这一点在规划阶段就决定了架构。

我见过最常见的误用是：三节点集群想省空间，配了个 RAID-5 策略，结果所有对象都不合规，虚拟机起不来。三节点只能老老实实用 FTT=1 镜像，开销两倍，认了吧。等扩到 6 台再考虑 RAID-6。

3.2 镜像和纠删码的开销与性能对比

下面这张表是我做方案时常用的对照，数据按"可用容量 = 物理容量 ÷ 开销"粗略估算，实际还要再扣掉约 25%~30% 的 slack 空间（重建余量）：

举个具体算例：12 台主机，每台 8 块 3.84TB NVMe，裸容量 368TB。如果全用 FTT=1 镜像，可用约 184TB，再扣 25% slack，实际可分配约 138TB。如果一半容量用 RAID-6 4+2，一半用镜像，可用容量大约是 368 × 0.5 ÷ 1.5 + 368 × 0.5 ÷ 2 = 122.6 + 92 = 214.6TB，扣掉 slack 后约 161TB。同样的硬件，多出二十多 TB 可用空间，代价是归档类业务的写性能下降。

3.3 从默认策略到业务分级，策略怎么落地才不混乱

策略不是越多越好。我的习惯是分三层：基础层（FTT=1 镜像，默认给一般业务）、核心层（FTT=2 镜像或 RAID-6，给数据库、核心应用）、容量层（RAID-5/RAID-6，给文件、归档、备份）。每一层再配一个"厚置备"的变体给那些对空间预留敏感、或者需要预分配保证性能的场景。策略总数控制在 6~8 个，再多运维就会记不住，也容易配错。

用 PowerCLI 查当前策略和空间占用的命令很直接，我实施时基本第一步就跑这两条：

# 查看集群 vSAN 配置概况 Get-VsanClusterConfiguration -Cluster (Get-Cluster -Name 'Cluster-A') # 查看空间使用与各对象占用 Get-VsanSpaceUsage -Cluster 'Cluster-A'

在 ESXi 侧验证策略是否真的生效，看对象和组件的分布状态：

# 查看本地 vSAN 磁盘与磁盘组状态 esxcli vsan storage list # 查看集群健康检查项（组件是否合规、网络是否正常） esxcli vsan health cluster list # 查看默认策略 esxcli vsan policy getdefault

有一个经验：改策略之后一定要等重同步跑完再判断性能。把一批容量层对象从镜像改成 RAID-5，vSAN 会在后台把组件重写一遍，那段时间网络和磁盘都会很忙，如果这时候上压力测试，数据一定难看。我的做法是改完策略后盯住重同步进度，等归零再开始测。

3.4 容量规划：不要按"可用容量÷副本数"拍脑袋

容量规划最容易犯的错是只看裸容量除以副本数。实际可分配容量 = 裸容量 ÷ 开销 − slack 空间 − 预留的运维空间。slack 空间的作用是保证单台主机故障后，集群还有足够空间做重建；如果空间算得太紧，一旦主机下线，重建会因为没有空间而卡住，集群长时间处于降级状态，风险很高。

每台主机的磁盘组数量也有讲究。全闪存配置下，每主机 1~2 个磁盘组、每组 4~8 块容量盘是比较常见的比例。磁盘组太少，单组的写缓冲会成为瓶颈，并发也上不去；磁盘组太多，磁盘组之间的重建和再平衡开销会变大，缓存设备的写寿命压力也更分散不均。我一般按"主机磁盘数量 ÷ 4~6"来定磁盘组数量，取整。

还有一点：容量盘型号和容量尽量一致。混插不同容量的盘，vSAN 会按最小盘来确定组内平衡，容易出现"大盘浪费"。而且不同型号的写寿命、时延特性不同，混在一起故障行为会变得难以预测。

4. 性能优化实战：从观测到动手的完整链路

4.1 先定位瓶颈，别一上来就改参数

性能优化最忌讳的动作是"听说条带宽度改大能提速"，然后在没测过基线的环境里瞎改。正确的顺序是：建立基线 → 找到拐点 → 只改一个变量 → 再测。基线怎么建？先用一两个虚拟机跑单线程 4K 随机读写，测出单流时延；再用多虚拟机并发加压力，看时延随负载上升的曲线。时延拐点出现的位置，就是瓶颈所在。

观测手段主要是三处。集群层面看 vSAN 性能监控里的时延、IOPS、吞吐、拥塞（Congestion）指标，拥塞值上去了说明后端的排队严重。主机层面用esxcli vsan storage list看磁盘状态，然后在客户端主机用esxtop切到磁盘视图，看每块设备的 DAVG（设备时延）和 KAVG（内核时延）。网络层面看物理网卡的丢包和重传计数。这三处数据结合起来看，基本能定位到"是网络慢、缓存盘饱和、还是容量层追不上"。

我遇到过一个典型案例：某实验室的 vSAN 集群跑备份任务时，虚拟机的交互响应明显变卡。查下来发现缓存设备的写缓冲持续满了——因为备份是持续大块写，缓存层下刷的速度跟不上写入速度，写缓冲满了之后写入直接被限流，同时挤占了其他业务的 I/O。解决办法不是换硬件，而是把备份虚拟机钉在专用主机上、并且给备份用的存储策略单独配 RAID-5 降低写放大，问题就缓解了。

4.2 网络层：先把管道疏通，再谈其他

网络是 vSAN 性能的第一道关口，也是投入产出比最高的环节。检查清单是这样的：

第一，确认 vSAN 流量走的是专用 VMkernel 口，且这个口绑定的物理网卡速率是 10G 或以上。用esxcli network ip interface list查 VMkernel 口和端口组，再用esxcli network nic list确认物理网卡协商速率（Speed 字段）。如果真的协商在 1000Mbps，先查网线、光模块和交换机端口配置，这种情况我见过不止一次。

第二，端到端验证巨型帧。用vmkping指定 vSAN VMkernel 口，带-d（禁止分片）和 8972 字节负载：

vmkping -I vmk1 -d -s 8972 -c 5 192.0.2.21

所有主机两两之间都要通，任何一对不通就说明链路中间有环节 MTU 没配对。这个测试必须在业务上线前做完全量，不能抽测。

第三，确认 vSAN 流量与其他流量隔离。vMotion、管理、虚拟机业务流量各走各的 VLAN 和上行，实在只有两块网卡，那就做双上行冗余，至少保证不因为单网卡故障导致集群降级。

第四，考虑 NUMA 亲和。如果主机是多路 CPU、网卡插在不同的 PCIe 根复合体上，跨 NUMA 访问会带来额外时延。这个优化收益不算大，但在追求极致时延的场景（比如高频交易类的模拟环境）值得调。

4.3 磁盘组与缓存层：把写缓冲这块照顾好

缓存设备的选型直接决定写入性能上限。判断标准不是容量，而是写寿命（DWPD）和稳态写性能。消费级 SSD 拿来当 vSAN 缓存，前三个月跑得飞快，之后性能断崖式下跌，这种坑太多了。选企业级、带掉电保护（PLP）的 NVMe，DWPD 至少在 1 以上，写入密集场景建议 3 以上。

缓存容量的算法前面提过，全闪存按容量层的 10% 起步估。但如果是写放大严重的业务（比如大量小文件随机写、日志类应用），10% 会不够，建议提到 15%~20%。判断依据是看缓存层的写缓冲使用率是否经常逼近上限——如果长期高位，那就是不够。

磁盘组内的容量盘分布要均匀。一个常见的错误是：主机上 8 块盘，建成 2 个磁盘组，每组 1 缓存 + 3 容量，剩下 1 块盘闲置。这样既浪费容量，又让两个组的负载不均衡。要么加成 4+4，要么就建 1 个组放 7 块，别留单盘。

还有一个细节：磁盘组的缓存设备不要和容量设备共用同一块物理盘（有些入门配置会这么干），共享会导致写缓冲和容量写入互相抢带宽，性能很难看。ESA 架构下这个问题被架构本身解决了，因为它就是全 NVMe、统一池化。

4.4 策略级调优：条带、预留和去重压缩的取舍

条带宽度（Stripe Width）控制一个对象被切成几段分散到不同磁盘组。默认值 1 意味着对象不跨磁盘组，所有 I/O 压在一个磁盘组上。对于高 IOPS 的业务（数据库、虚拟桌面），把条带宽度设成 2 或 4 能明显提升并发。但条带不是越大越好：条带越大，组件数量越多，重建时的开销和元数据压力也越大，而且会消耗更多的主机资源。我的经验值是 2 对大多数业务够用，4 用于明确的 IOPS 密集型场景，8 基本只在极端场景用。

对象空间预留（Object Space Reservation）是个双刃剑。设置成 100% 相当于厚置备，空间提前分配好，写入时不会因为动态分配而产生额外开销，性能更稳定；但代价是空间利用率低，而且没法回收。对于确有性能要求的关键业务，我一般预留 50%~100%；普通业务保持精简置备即可。

去重和压缩是 vSAN 里争议最大的功能。开启之后，重复数据块和可压缩数据会被处理，容量节省效果在虚拟桌面场景非常明显（有些环境能省 50% 以上）。但它要消耗 CPU，而且在写入路径上增加了处理环节，对时延有影响。我的建议是：先在测试环境验证，用真实数据集跑一遍，看容量节省是否值得这点性能损失。全闪存 + CPU 有余量 + 数据重复率高（VDI、开发测试环境），开；数据库、高频写入、CPU 已经吃紧，不开或者只对归档类数据存储开。

4.5 Guest 侧配合：很多时候瓶颈在虚拟机里面

这一块经常被忽略。虚拟机的磁盘分区没对齐，会导致每次写都跨物理块，性能损失可能到 20% 以上。现在主流的操作系统安装程序默认都会对齐，但老系统迁移上来的虚拟机未必，值得检查一下。

队列深度也要匹配。虚拟 SCSI 控制器的队列深度、Guest OS 里的 I/O 调度策略、应用自身的并发设置，三者要协调。如果应用是单线程小队列，那后端配再多的条带也用不上；反过来，如果应用开了几百个并发，而虚拟控制器队列深度不够，就会出现排队。用pvscsi控制器替代默认的 LSI Logic，队列深度和吞吐通常都会更好。

还有 TRIM/UNMAP。开了之后，Guest OS 删除文件会通知后端回收空间，能避免"精简置备的盘越用越胖"。但这个操作本身有开销，不建议在业务高峰期开启自动回收，我一般设成按周在低峰期执行。

5. 常见故障与排查实录

5.1 组件不合规：先查主机数，再查空间，最后查策略

"对象不合规"是 vSAN 最高频的告警。排查顺序我固化成了三步：先看策略要求的主机数是否满足，再看剩余空间是否够放新组件，最后看是否有主机处于维护模式或离线。前两个原因占九成以上。

第一步，确认策略里的 FTT 和 RAID 类型，再对比集群当前可用主机数。RAID-5 需要 4 台以上参与主机，RAID-6 需要 6 台，如果集群刚扩完容但新主机还没加入，或者某几台主机磁盘满了无法接收组件，策略就会不合规。第二步，看集群剩余可分配空间，如果空间不足，vSAN 会拒绝放置组件。第三步，检查是否有主机处于维护模式且选择了"不迁移数据"，那种情况下它的组件会被标记为不可用。

处理办法：要么扩主机、要么降策略、要么清理空间。千万不要用"强制删除组件"这种手段，那是在拿数据完整性换一个干净的界面，后患无穷。

5.2 重同步慢：多半是网络或者限流在起作用

一次主机重启、一块盘更换，都会触发组件重建。如果重建速度极慢，先算一下理论值：假设要重建 2TB 数据，10G 网络理论 1.25GB/s，考虑协议开销和磁盘读写竞争，实际能到 400~600MB/s 就算正常，那 2TB 大概需要 1 小时左右。如果跑了一整天还没完，那肯定有问题。

检查顺序：网络是否真的有 10G（前面说的速率协商）、是否有其他大流量在抢带宽（备份、vMotion、跨集群复制）、重建限流参数是否被压得过低、目标主机的磁盘是否已经成为瓶颈。vSAN 有重建限流的机制，为了防止重建把业务压垮，默认会做一定限制，大规模故障后可以适当放宽，但要监控业务时延，别为了快点恢复把线上业务拖死。

另外一个容易忽略的点是：一次性故障太多。一次掉两台主机，集群会同时重建大量组件，这时候不是"重建慢"，是"重建量太大"。这种情况正确的做法是先把一台主机恢复上线，让它自带的组件生效，减少需要重建的总量，再处理另一台。

5.3 性能间歇性抖动：从"拥塞值"入手

间歇性卡顿是最难查的。业务方说"每天下午三点左右会卡一下"，你去看监控，指标都很平稳。我的经验是先抓 vSAN 的拥塞（Congestion）指标，如果拥塞值有尖峰，说明后端排队严重，那就顺着时间点去找当时的负载来源——可能是某个定时备份、可能是某个批处理任务、也可能是某台主机的磁盘组在做再平衡。

如果拥塞值平稳但业务还是卡，那就要怀疑网络丢包和重传。查物理网卡的丢包计数，查 vmkernel 日志里有没有大量重传记录。真凶往往是一根快要坏掉的网线、一个光模块的收发光功率下降、或者交换机端口协商不稳定。这类问题在虚拟化平台上表现为"存储慢"，实际跟存储一点关系都没有。

5.4 常见问题速查表

磁盘组创建失败这个坑值得多说两句。如果服务器的 RAID 控制器没切成直通（HBA）模式，磁盘会被控制器管理，vSAN 就看不到裸盘。进入 ESXi 后用partedUtil getptbl /vmfs/devices/disks/<naa.id>可以查看是否有残留分区表，确认要清空的话再用partedUtil delete逐分区删除。这一步一定要在确认盘上无数据的前提下做，删错了没法恢复。

6. 日常运维里那些文档不会写的事

扩容的节奏比规模更重要。我见过不少环境，一开始三台主机凑合跑，业务涨了就直接加到六台，加完发现性能没提升多少——因为原有的对象还是按老策略放着，新主机只是增加了容量，没有参与负载分担。vSAN 有再平衡机制，但它不会主动把已有组件打散到新主机上，除非对象被重写或者手动触发。所以扩容之后，我会挑一批核心业务的虚拟机做一次存储迁移（改策略再改回来），强制让它们的组件重新分布，这样新主机的资源才真正被用起来。

升级要留出足够的时间窗口。vSAN 的版本升级涉及磁盘格式、策略兼容性，一旦开始就很难中途回退。升级前必须确认硬件在兼容性列表里，备份关键虚拟机，并且留出足够时间让重同步跑完。我一般会把升级安排在业务低峰期，并且提前一周在测试集群上走一遍全流程，把所有可能报错的步骤先踩一遍。

最后分享一个我觉得很值的小习惯：给集群建一份"基线档案"。内容包括每台主机的磁盘组结构、缓存设备型号和写寿命、各存储策略的配置、网络的 MTU 和 VLAN 规划、以及一次标准压力测试的结果。这份档案在出问题时价值极高——你可以立刻对比"现在的状态和当初建好的状态有什么差异"，很多问题一眼就能看出来。我吃过没有基线的亏，当时一台主机的磁盘组被人误删重建，结构变了但没人发现，直到几个月后性能莫名下降才查出来，中间排查花了整整两天。