企业官网建设流程全解析

我遇到过一套规模不大的 vSAN 环境，三台主机、全闪、双口万兆，每台机器两个磁盘组，4K 随机写压测跑到两万 IOPS 左右延迟就开始往上顶，再往上加压力，吞吐几乎不动，延迟像台阶一样跳。当时第一反应是网络有问题或者缓存盘不行，把 vSAN 的对象结构、磁盘组配置、存储策略三样东西摊开对了一遍才发现，问题不在某一个"慢"的部件上，而是架构在设计阶段就把上限写死了：条带宽度是 1，每个虚拟磁盘的所有组件都压在同一个磁盘组里，再大的并发也只能靠那一个磁盘组和一个缓存盘去扛。

这件事挺典型。vSAN 这套软件定义存储，把存储控制平面塞进了 vSphere 内核里，好处是部署简单、策略驱动、按虚拟机粒度管数据，坏处是所有"聪明"都藏在默认值里，默认值不会主动告诉你它做了哪些妥协。很多人装完集群、点几下鼠标跑通了虚拟机，就以为完事了，等到真上生产负载，才发现性能曲线早早横盘。这篇内容就是想把这套东西拆开讲清楚：vSAN 的数据到底怎么落盘、磁盘组怎么设计才不会给自己挖坑、存储策略里每一个选项背后的代价是什么、性能上不去的时候按什么顺序往下查。读者对象很明确，管着或者准备管一套 vSAN 集群的人，从刚接触的新手到已经踩过几个坑的老手，都能在里面找到对得上号的场景。

1. 一次压测卡在 2 万 IOPS 之后：vSAN 的数据到底落在哪

先把架构摊开。vSAN 不是"把一堆本地盘拼成一个共享目录"这么简单的东西。它在每台 ESXi 主机上运行一个存储层，把这些主机的本地磁盘组织成一个分布式对象存储，对外呈现为一个 datastore。虚拟机磁盘（VMDK）、swap 文件、ISO、命名空间目录，在 vSAN 眼里都是"对象"。这个抽象是理解一切性能和策略问题的起点，因为你在界面上看到的"一个虚拟磁盘 500GB"，底下可能对应着十几个分布在不同主机上的组件。

不理解对象结构的人调优，基本等于蒙着眼睛拧旋钮。你会发现策略里那些选项——容错数、纠删码、条带宽度——看起来像是几个孤立开关，实际上它们共同决定了这个对象被切成几块、每块放在哪几台主机、每台主机上占几个组件。这几个问题的答案，直接决定了这个虚拟磁盘能吃到的并发上限。

1.1 对象、组件、见证：把"一块虚拟磁盘"拆开看

一个虚拟磁盘对象，按存储策略被切分成若干个组件（Component），组件分布在不同的主机上。以最常见的 FTT=1（容忍一次故障）镜像策略为例，一个对象会有两份完整副本，分别落在两台不同主机的磁盘组里，另外还会有一个**见证（Witness）**组件放在第三台主机上。见证不存实际数据，只存元数据，作用是在网络分裂的时候充当仲裁者，判断哪一侧的副本是"多数派"，避免出现两个副本都自认为是主的情况。

用一个生活化的类比：一份重要合同，你复印两份放两个不同的抽屉，再在第三个抽屉里放一张纸条，写着"这份合同在 A 抽屉和 B 抽屉各有一份"。纸条本身没有合同内容，但当某天你发现 A 抽屉打不开时，靠这张纸条能确认 B 抽屉里的那份是完整的、可以用的。vSAN 的见证组件干的就是这张纸条的活。

这个结构带来两个直接影响。第一，容量规划不能只算两份副本。一个带 FTT=1 的对象，实际占用是 2 倍数据量加上一点见证元数据，所以在四台主机的集群里，可用容量大概只有原始容量的一半，再加上必须留出的空闲空间，实际能用的更少。第二，故障域是主机级别的，不是磁盘级别的。两块盘同时坏在不同主机上，集群还能活；同一台主机上的两块盘坏了，那台主机整体掉线，只要不是同时有多台主机掉线，数据依然可访问。

1.2 存储策略是数据放置契约，不是性能开关

很多人把存储策略当成一个"创建虚拟机时随手选一下"的配置项，用默认的"vSAN 默认存储策略"就完事了。这个理解偏差会带来后续一堆麻烦。存储策略的本质是一份数据放置契约：它规定了这份数据要几份副本、要不要用纠删码、切成几条带、要不要预留空间。这些东西在对象创建的那一刻就被"定型"了，写进对象元数据里，后续所有 I/O 路径、重建逻辑、容量统计都按这个契约走。

它不是一个能在运行时动态生效的性能参数。你在压测跑到一半的时候去改策略，vSAN 不会立刻按新策略服务请求，而是启动一个**重新配置（Reconfigure）**流程，把已有对象按新规则重新布局一遍。这个流程会读旧组件、写新组件、删多余组件，整个过程要占带宽、占磁盘队列、占 CPU。一个几百 GB 的虚拟磁盘改条带宽度，跑上几个小时很正常，改的过程中业务性能会肉眼可见地下降。

注意：改策略不是"刷新一下配置"，而是一次全量数据搬迁。改之前先看集群剩余空间够不够（重新布局期间新旧组件会短暂共存，需要额外的临时空间），再看当前有没有重建任务在跑，两件事叠在一起会让 I/O 延迟直接失控。

所以正确的做法是，在创建对象之前就想清楚这个虚拟磁盘要什么级别的保护、什么样的并发特征，创建时就给定策略。事后改策略，本质上是在为之前的规划缺失补课。

1.3 混合与全闪：同一块缓存盘干着两份不同的活

磁盘组的结构是固定的：每个磁盘组一块缓存盘加若干块容量盘。但缓存盘在混合架构和全闪架构里承担的角色完全不同，这一点经常被忽略，而它恰恰是性能差异的根源。

混合架构下，容量层是机械盘，缓存层是 SSD。这块 SSD 被切成两部分用：大约三成做读缓存，把热点数据从机械盘上"提前"放到 SSD，减少机械盘的寻道；剩下七成做写缓冲，所有写入先落到 SSD 上就算成功返回，等攒够了再批量刷到机械盘。这是一个典型的"用 SSD 掩盖机械盘随机 I/O 差"的设计。它的性能天花板取决于两件事：读缓存的命中率高不高，写缓冲够不够大、下刷跟不跟得上。

全闪架构下，容量层本身就是闪存，随机读的延迟已经很低了，所以那块缓存盘不再承担读缓存，全部容量都用做写缓冲。写入先落缓存盘，累积后刷到容量盘。这时候缓存盘的作用变成了"吸收写入尖峰 + 做写聚合"，把大量小块随机写合并成顺序写落到容量盘上，延长容量盘的寿命，同时压低写延迟。

这个差异带来的实操结论很直接：混合架构必须给读缓存留够空间，缓存盘容量通常建议不低于容量层总容量的 10%，并且实际使用中往往要更高才够；全闪架构更在意缓存盘的写入耐久度和持续写能力，因为它是所有写入的必经之路，一旦写缓冲被写满，前端 I/O 就得等着，延迟会突然抬起来。我见过不止一次，全闪集群用了一块容量很小、写入耐久度只有 1 DWPD 的盘做缓存，跑了几个月之后缓存盘磨损指标掉得飞快，性能也随之下滑。

2. 磁盘组的设计决定了性能上限

磁盘组这个层级的决策，在集群搭建阶段做完就基本改不动了（改要撤出数据、重建磁盘组），但它对性能的影响比任何后期调参都大。我在看别人集群的时候，习惯先问三个数：每台主机几个磁盘组、每个磁盘组几块容量盘、缓存盘是什么型号什么耐久度。这三个数一报出来，性能大概在什么量级基本就心里有数了。

2.1 磁盘组数量与容量盘数量的配比经验

以主流版本为例，每台主机最多支持 5 个磁盘组，每个磁盘组 1 块缓存盘加最多 7 块容量盘（不同版本的上限略有差异，动手前一定查对应版本的配置最大值文档，别按记忆来）。

那么问题来了：同样 8 块容量盘，是做"2 个磁盘组 × 4 块容量盘"，还是"4 个磁盘组 × 2 块容量盘"？这两种布局的原始容量一样，但性能特征完全不同。

关键在于磁盘组是并行的最小单位。一个磁盘组的写入，全部要经过它自己那块缓存盘。两个磁盘组意味着两块缓存盘、两个独立的写入队列、两套下刷流程；四个磁盘组就是四块。对于随机写密集的负载，磁盘组越多，能吸收的并发写入就越多，写延迟越稳。而每个磁盘组里塞更多容量盘，好处是单个组内的数据分布更宽、顺序读的带宽可能略高、管理粒度更粗，但所有容量盘共享一个写缓冲，写密集时容易互相拖累。

所以经验上的取舍是：写密集、随机小 IO 为主（数据库、虚拟桌面、OLTP）→ 优先多磁盘组；容量优先、大块顺序写为主（备份、归档、视频素材）→ 少磁盘组多容量盘。做虚拟桌面这类场景，四台主机、每台四个磁盘组的配置并不算夸张，因为写入的并发度直接决定了登录风暴时的体验。

2.2 缓存盘选型：写缓冲要的是耐久和持续写，不是峰值

选缓存盘最容易犯的错，是拿一块消费级或者读密集型 SSD 当写缓冲。这类盘的标称顺序读写很好看，但持续写入能力（Sustained Write）和随机写稳态性能很差，写满 SLC 缓存之后性能断崖式下跌，而且写入耐久度通常只有 0.3 到 1 DWPD。

判断一块盘适不适合做缓存，看三个指标，从来不只看 IOPS：

还有一点容易被忽略：缓存盘不做 RAID 保护。一个磁盘组只有一块缓存盘，它坏了，整个磁盘组就不可用，容量盘上的数据要等其他副本凑齐或者重建。所以缓存盘选的不是"性价比"，是"可靠性 + 稳态性能"。为了省一点预算在缓存盘上降规格，是这个领域里最不划算的省钱方式。

2.3 全闪写缓冲的耐久度换算实例

耐久度这个事，很多人看到 DWPD 这个参数没概念，不知道自己要几个。给一个具体的算法。

假设一套全闪集群，单台主机配 8 块 3.84TB 容量盘，分两个磁盘组，每组 4 块容量盘，单机原始容量约 30TB。按容量层 10% 的经验值配缓存，单机需要约 3TB 的缓存容量，也就是每组约 1.5TB，实际选型时一般选 1.6TB 的企业级盘。

接下来算每天有多少数据会写到这块缓存盘上。假设这套集群承载的业务，前端每天实际写入 8TB（注意是真正写下去的数据，不是读）。镜像策略 FTT=1 意味着每份数据写两份，所以集群层面的后端写入量是 16TB，摊到 4 台主机上，每台 4TB。再考虑写聚合和下刷带来的写放大，缓存盘实际承受的写入量往往还要再乘一个 1.5 到 2 的系数，取 1.8，那就是每台主机每天约 7.2TB 落到缓存盘上。

每台主机有两块缓存盘，每块盘每天承担 3.6TB。这块盘容量 1.6TB，那么 DWPD 需求 = 3.6 / 1.6 ≈ 2.25。这个数说明什么？选一块 1 DWPD 的盘，一年多就磨到寿命边缘；选 3 DWPD 的盘，有比较舒服的余量；如果业务写入量再翻倍，就得往 5 DWPD 甚至写密集专用盘上走。

这个计算里最容易出错的环节是"每天实际写入多少"。没人能一口报准，通常的做法是从现有环境采集一段时间的写入量，或者按业务模型估算，然后留 50% 以上的余量。宁可算大，别算小——缓存盘磨穿是件很麻烦的事，换盘要撤出磁盘组数据，停机窗口不好要。

2.4 故障域与重建带宽：隐藏的容量成本

磁盘组规划还有一个反向约束：容量不能占满。vSAN 需要空闲空间来应对组件重建。当一台主机下线，它上面的组件要在其他主机上重建出来，重建的目标位置需要有足够空间。业内的经验值是把使用率控制在 70% 以内，超过 75% 就开始进入危险区，重建可能因为空间不足而卡住，集群长期处于降级状态。

除了空间，重建还要吃带宽和磁盘队列。一次主机级故障触发的重建，数据量可能到几十 TB 级别，即使限速跑，也要好几个小时甚至一两天。这段时间里，集群的可用冗余是降低的，同时后端磁盘的负载是抬高的，前端性能必然受影响。我见过有环境在重建期间做了大批量数据导入，结果重建进度被反复打断，集群在降级状态里挂了两天。重建期间该限速就限速，该推迟的批量任务就推迟，这个决定比任何调参都管用。

3. 存储策略调优：FTT、纠删码与条带宽度的取舍账

策略这一块，真正需要想清楚的其实就三个问题：要容忍几次故障、用镜像还是纠删码、要不要加条带。三个问题互相牵制，不能单独看。

3.1 FTT 与主机数量的硬性对应关系

FTT（Failures To Tolerate）是最基础的选项，但它和集群规模是硬绑定的，不是想要几就能给几。用镜像策略时，副本数是 FTT+1，加上见证，需要的故障域数量是 2×FTT+1。用表格看得清楚：

这个表最实用的一点是，它告诉你"三节点集群做 FTT=1 是可行的，做 FTT=2 是做梦"。很多人规划的时候想要 FTT=2，一看成本就砍到三台主机，结果策略还挂着 FTT=2，创建虚拟机直接失败，或者被迫降到 FTT=1，白白浪费规划时间。

还有一个细节：三节点集群做 FTT=1，见证组件放在哪里？答案是放在三台主机中的一台，因为见证不占实际容量，只占一点元数据。但这样一来，那台承载见证的主机如果掉线，虽然数据还在，但仲裁能力会受影响。规模小到这个程度，冗余本身就是脆弱的，心里要有数。

3.2 RAID-5/6 什么时候划算，什么时候是陷阱

纠删码是 vSAN 里省空间的利器。RAID-5 用 3 份数据加 1 份校验，空间开销 1.33 倍，容忍一次故障；RAID-6 用 4 份数据加 2 份校验，开销 1.5 倍，容忍两次故障。跟镜像的 2 倍、3 倍一比，容量利用率提升非常明显。

但纠删码不是免费的。它的代价体现在三个方面：

第一是写惩罚。写一份数据要更新对应的校验块，一个小块随机写会变成"读旧数据、读旧校验、算新校验、写新数据、写新校验"这一串操作。虽然 vSAN 的写缓冲和写聚合会缓解这个问题，但在写密集的负载下，纠删码的写延迟和写入放大依然明显高于镜像。

第二是最小主机数的门槛。RAID-5 至少 4 台主机，RAID-6 至少 6 台。小集群根本用不了。

第三是重建粒度。纠删码对象的一个组件丢失，重建时需要读取整个条带上的其他数据来重算，比镜像副本的直接拷贝要重。

所以选择逻辑很清楚：写密集的数据库、虚拟桌面系统盘，老老实实用镜像；虚拟机数量多、单个虚拟磁盘写入不频繁、容量压力大的场景，比如文件服务器、批处理集群的节点盘、测试环境的虚拟机，纠删码很划算。还有一个折中做法是混合策略——同一套集群里，核心业务用镜像策略，次要业务用纠删码策略，按虚拟机粒度分别指定，让容量和性能各得其所。

3.3 条带宽度对并发的影响

这是最容易被忽略、但在特定场景下收益最大的一个参数。默认的条带宽度（Stripe Width）是 1，意思是一个虚拟磁盘对象的所有组件作为一个整体存在，不额外切分。这个默认值对绝大多数场景够用，因为一台虚拟机的 I/O 深度通常不高，单条链路就能吃满。

但如果遇到这种情况——单个虚拟机的监控数据显示队列始终排着、延迟居高不下，而集群整体负载并不高——大概率是这个虚拟机的组件全压在一个磁盘组或少数几台主机上，并发上不去。把条带宽度调到 2 或 4，相当于把这个对象的组件切成几组，分散到更多主机上，让多个磁盘组并行服务同一个虚拟磁盘的 I/O。

代价要一起看。条带宽度的上限受主机数限制（一般不超过 12，且实际能调到多少取决于故障域数量），组件数量会成倍增长，元数据管理的开销上升，一次主机故障影响到的对象更多，重建的时候牵涉面更广。所以这是个针对性手段，不是普适优化。集群整体压测上不去，调条带可能有点用；单台虚拟机慢，调条带通常立竿见影。但如果你给几百台虚拟机都设了宽度 8，那只是把压力均匀地摊开，总量不变，还增加了管理负担。

3.4 在线改策略的真实代价

前面提过，改策略是一次重新布局。这里补充几个实测中的经验。

改FTT 或冗余方式（比如从镜像改成纠删码）是最重的操作，数据要重新组织，几百 GB 的对象跑几个小时很正常。改条带宽度次之，也是全量重写。改对象空间预留（从精简改厚置备）相对快一些，主要是分配空间。这些操作在 vSAN 里都有进度显示，能看到"已重新配置 X%"。

操作时机上有两条纪律：一是不要在集群已经降级或者正在重建的时候改策略，两件事叠加可能导致组件无法满足策略要求，集群会长时间处于不健康状态；二是大范围改策略要分批做，一次改几十台虚拟机，观察后端延迟和拥塞再决定是否继续。我见过一次性地把上百台虚拟机策略从厚置备改成精简，后端磁盘队列直接打满，业务侧感知到明显的卡顿。

4. 网络这一段最容易被低估：带宽、MTU 与故障域

vSAN 是跑在网络上的分布式存储，这句话说起来像废话，但在实际项目里，网络永远是最容易被凑合的那一环。服务器采购有明确的型号和预算，交换机往往"用现成的"，结果磁盘、CPU 都按规划配足了，网络成了瓶颈。

4.1 带宽估算：别只按前端 IOPS 算

一个粗略但好用的估算方法：先算前端的总吞吐，再乘上副本倍数，再留一倍余量。

举例，一台业务主机上跑 10 台虚拟机，峰值时每台 2000 IOPS、平均块大小 16KB，那么这台主机的读吞吐大约 320MB/s。写的话，因为镜像要写两份，后端实际产生的写流量是 640MB/s（一份数据从这台主机出去到另一台，另一份在本地）。再加上重建、快照、备份这些后台流量的余量，单主机的 vSAN 网络峰值需求轻易就能摸到 1GB/s 以上。

这就是为什么万兆是底线，不是目标。万兆理论带宽 1.25GB/s，实际跑满也就 1.1GB/s 左右，一套写密集的集群很容易把它吃满。25GbE 在这些年已经是更舒服的选择，双口做冗余之后单口还能跑 25G，压力小很多。如果预算卡在万兆，至少要做到业务网络和 vSAN 网络分开，或者在同一物理链路上做流量优先级，把备份、迁移这些大流量任务压到业务低峰期。

还有一个常被问的问题：vSAN 网络能不能和 vMotion、管理网络共用？技术上可以，只要带宽够、MTU 一致。但实际运维中，热点迁移和备份流量会把 vSAN 的延迟顶起来。我的建议是能分就分，实在只有两个口，就把 vSAN 和 vMotion 放一起，管理网络单独走，总比全挤在一根线上强。

4.2 MTU 9000 的收益边界与踩坑

巨型帧（Jumbo Frame）是个老话题，讨论了很多年。vSAN 官方建议启用 MTU 9000，理由是减少包处理开销、提升大块传输效率。实际收益要看负载类型：大块顺序 I/O 和重建流量提升明显，4K 随机小 IO几乎没感觉，因为一个 4K 的包远小于 1500 字节的 MTU，改巨型帧对它的收益是零。

而配错的代价很实在。MTU 必须端到端一致：vSAN VMkernel 接口、虚拟交换机、物理网卡、物理交换机端口、交换机之间的上行链路，任何一环是 1500 而其他是 9000，就会出现"ping 得通但 vSAN 不通"的诡异现象——小包能过，大包被丢，标准 ping 默认 56 字节，测不出来，要用ping -s 8972 -d这种方式去验证（不同环境的具体参数要按实际 MTU 减掉包头来算）。

实操上，我倾向于：新建集群并且交换机可控，就上 9000，一次配到位；已有环境、交换机配置不在自己手里、或者中间还有别的设备，就老实 1500，别为了那点收益给自己埋雷。启用之前，先在集群所有主机上做一轮大包连通性验证，再开始配置 vSAN 流量，能省掉很多排查时间。

4.3 网络分区与见证放置

vSAN 靠多数派来避免脑裂。两主机加见证的配置，或者双站点延伸集群加第三站点见证，是两种典型拓扑。见证节点的选址有硬性要求：不能和任何一个数据站点在同一个故障域里，不能是同一台物理机上的虚拟机，不能是同一个机柜、同一路供电、同一个接入交换机。这些要求听起来像常识，但真到落地的时候，"临时先放这儿"变成永久配置的情况并不少见。

延伸集群还有额外的网络要求，站点之间的往返延迟要低（通常要求个位数毫秒内），带宽要足够支撑跨站点的副本同步。这些指标在规划阶段就要测量，别等部署完了发现延迟不达标，再回头改拓扑，成本高得多。

5. 性能排查链路：从应用延迟倒推到后端拥塞

性能问题最怕的是"到处看，哪都想改"。有效的做法是建立一条从应用往下的排查链路，逐层排除，定位到具体那一层之后再动手。vSAN 的好处是观测点比较全，坏处是数据太多，不知道该看哪个。

5.1 先定性：慢在前端、网络还是后端

第一步永远是确认"到底哪里慢"。在虚拟机里跑一次磁盘测试，看延迟和 IOPS；同时看这台虚拟机的宿主主机上的 vSAN 后端指标。两者的关系能说明很多问题。

如果虚拟机内延迟高，但 vSAN 后端延迟很低，说明瓶颈不在存储，可能在虚拟机的队列深度设置、客户机操作系统的 I/O 调度、或者虚拟 SCSI 控制器的队列。如果两边延迟都高，那就是后端确实顶不住了。如果后端延迟正常但吞吐上不去，要看是不是网络带宽吃满，或者主机 CPU 在存储栈上打了满。

还有一类问题表现为"周期性卡顿"而不是"持续慢"。这种往往是后台任务在抢资源——重建、重新配置、快照合并、备份任务。看集群的任务列表和重建状态，基本能对上。

5.2 观测点：性能服务、vsantop 与 esxtop 各看什么

vSAN 自带性能服务（Performance Service），打开之后能看到虚拟机、主机、磁盘组三个层级的 IOPS、吞吐、延迟，还有后端拥塞指标。这是最直观的一层，日常排查先从这儿看。看的时候注意区分"虚拟磁盘级"和"后端磁盘级"——前者是虚拟机实际感受到的，后者是磁盘实际承受的，两者差距大说明中间有排队。

命令行工具方面，较新版本提供了vsantop，能实时看到对象、磁盘组、缓存盘的吞吐和延迟，判断是哪个磁盘组在拖后腿很有效。不同版本路径可能不同，一般在/usr/lib/vmware/vsan/bin/下面，找不到就find一下。esxtop里按 v 键切到 vscsi 视图能看到每台虚拟机的 DAVG、KAVG，切换到 VSAN 相关列能看到后端队列的情况。

这三个工具的分工是：性能服务看趋势和总体，vsantop 定位到具体磁盘组和对象，esxtop 定位到具体虚拟机和队列。

5.3 几个高频元凶与验证方法

排查过程中反复遇到的坑，差不多就这么几类，做个对照表方便快速比对：

这张表不是穷举，但它覆盖了大部分现场问题。用的时候有个顺序建议：先看容量使用率，再看重建状态，再看缓存盘，最后才看策略和条带。前两个是最容易被忽略的，很多"性能问题"其实是容量问题。

5.4 重建期间的性能塌陷怎么缓解

重建是 vSAN 里无法避免的事，磁盘坏了、主机维护、扩容，都会触发。重建期间集群的可用带宽是降低的，而且后端磁盘的读放大明显增加。这时候前端延迟抬升是正常现象，不需要恐慌，但可以做几件事把影响压到最小。

一是限制重建的并发度。vSAN 允许限制同时进行的重建任务数量，把默认值调低能明显减轻磁盘压力，代价是重建时间变长。这个取舍在业务高峰期是值得的。二是推迟非关键的大批量任务，备份、批处理、数据迁移都往重建结束后排。三是保证有足够的空闲空间，空间不足会让重建碎片化，效率极低。四是别在重建期间改策略，两个数据搬迁任务叠加，会互相拖累。

6. 空间效率与性能的拉扯：去重压缩、TRIM 与预留

容量和性能在 vSAN 里经常是互相拉扯的关系。省空间的方案往往要额外算力或者额外 I/O，性能好的方案往往吃容量。这一节说清楚几种常见的省空间手段和它们的代价。

6.1 去重压缩的开启时机与代价

去重和压缩（全闪架构支持，按 4KB 块做去重和压缩）能省出可观的容量，在虚拟桌面、克隆密集型场景里，省下三四成空间是常见的结果。但它有几个前提要认清。

第一，它消耗计算和内存资源，去重表要占用内存，压缩要占 CPU，主机配置太紧的时候开启会影响其他负载。第二，它对已经压缩或者加密的数据基本无效，如果业务数据本身是压缩格式（视频、图片、备份流），收益很低，还白吃开销。第三，开启的瞬间会触发全量数据重写，对已有数据做转换，这个过程对 I/O 的压力不小，几百 GB 到几 TB 的数据可能要跑很久。

时机上，我的建议是新集群规划时就开启，而不是事后补。新集群开启，数据写入时就按去重压缩的格式落盘，没有转换成本。已有集群事后开，得挑一个业务低峰窗口，并且提前确认缓存盘还有余量，因为转换过程会产生大量写入。

6.2 精简置备、TRIM 与空间回收

虚拟磁盘默认是精简置备的，用多少占多少。这个特性对容量友好，但会带来一个隐患：虚拟磁盘在客户机里删除了文件，vSAN 未必知道那块空间已经不用了，因为没有"回收"动作，容量就一直被占着。

解决这个问题的机制是TRIM/UNMAP。客户机操作系统支持 discard（主流系统都支持），虚拟磁盘配置里打开相应选项，删除文件时会给底层发信号，vSAN 收到后把这些块标记为空闲，后续可以复用。这件事对长期运行的集群意义很大——不回收的话，用了一两年的集群，容量使用率会虚高得离谱，明明客户机里只有 40% 的数据，vSAN 上显示 80%。

操作上有几个细节：客户机里的文件系统要支持并开启 discard（有些系统默认是按周期批量 TRIM 而不是实时）。回收不是瞬时的，后台有个处理过程，别指望删完立刻看到容量下降。还有，批量删除大量数据之后，短期内的后台回收会给磁盘带来额外负载，挑低峰期做。

6.3 预留与 swap 文件的落点

对象空间预留（厚置备）是另一个方向的选择。开启预留之后，创建虚拟磁盘时就把空间全部分配好，不会出现"用着用着空间不够"的情况。代价是容量利用率低。

什么场景该开预留？我的经验是：对可用性要求高、且集群容量比较宽裕的核心业务，开预留能避免后期因为空间紧张导致组件无法重建。反过来，容量吃紧、虚拟机数量多的环境，老老实实精简置备，靠监控使用率来管。

还有一个常被忽略的点是swap 文件（.vswp）的位置。虚拟机内存的交换文件默认放在 vSAN datastore 上，它的大小等于分配给虚拟机但未预留的内存。一个 32GB 内存、没有内存预留的虚拟机，会在 vSAN 上占一个 32GB 的 swap 对象。几十台这样的虚拟机，就是几百 GB 的空间，而且这些文件基本不产生 I/O，纯占容量。合理的做法是给 swap 文件单独指定一个策略（比如 FTT=0 或者用纠删码），或者在有本地盘的主机上放到本地盘，能省下不少容量。

7. 扩容与日常维护里那些容易翻车的地方

集群跑起来之后，真正出事的时间点往往不是上线当天，而是扩容、维护、升级这些"动一下"的操作。这些操作本身不复杂，复杂的是它们对集群状态的瞬时影响。

7.1 扩容顺序与磁盘组退役

加容量有两条路：加主机，或者在现有主机上加磁盘组/容量盘。

加主机是最简单的，加进去之后 vSAN 会自动做一次重新平衡，把部分数据迁到新主机上。这个过程同样吃带宽，别指望加完立刻见效，等平衡跑完再看容量和性能。有个细节：新主机加入之前，先确认固件版本、驱动版本、磁盘型号和现有集群尽量一致，混用的后果是性能参差不齐，严重的会识别不到盘。

在现有主机上加磁盘组，要注意主机的控制器和背板能不能撑住。很多服务器的磁盘位是够的，但 RAID 控制器或者 HBA 的队列深度、缓存配置跟不上，加完盘性能反而下降。上线前查一下控制器对硬盘数量的支持上限，别踩这个坑。

磁盘组退役（撤出数据）是把一个磁盘组从集群里摘出去的标准动作，换盘、换控制器、调整布局都要用。这个操作会把组上的数据迁走，耗时跟数据量成正比。操作期间该磁盘组的性能会下降，其他磁盘组要承接迁过来的数据，整体延迟会有波动。挑低峰期做，一次只撤一个，别并行。

7.2 维护模式两种模式的取舍

主机进维护模式时，vSAN 给两个选项：确保可访问性（Ensure Accessibility）和完整数据迁移（Full Data Migration）。

前者只保证数据依然可访问，该主机上的组件不会全部迁走，只迁到"满足策略最低要求"的程度。速度快，但主机离线期间集群实际上是降级的，如果这时再坏一台主机，数据就可能不可用。

后者把该主机上的所有组件都迁走，主机离线期间集群仍然是完整冗余。速度慢，可能跑几个小时，但安全。

选择逻辑很简单：维护窗口短、有把握不叠加故障、集群容量紧张 → 确保可访问性；维护时间长、风险不确定、容量充足 → 完整数据迁移。生产环境我偏向后者，除非时间实在来不及。降级状态下待上几个小时，万一这时候有块盘出问题，就是一次真故障。

7.3 固件、驱动一致性

这一条放在最后但绝对不是最不重要。同一集群里，控制器固件版本不一致、磁盘固件版本不一致、网卡驱动版本不一致，会导致的问题包括：识别不到设备、性能差异极大、重建失败、偶发的组件降级。而且这些问题的表现往往很不直观，报错信息也指不到根子上。

做法很朴素：升级前查兼容性列表，确认控制器、磁盘、网卡、驱动的组合是被支持的；建立集群的时候就把所有主机的固件刷到同一个版本；后续加新主机，先刷固件再入集群。这些工作在上线前做一遍，能省掉后面无数排查时间。

我个人在几套环境上折腾下来的体会是，vSAN 这套东西的"默认行为"其实相当合理，绝大多数性能问题不是参数调得不对，而是规划阶段的假设和实际负载不匹配：缓存盘按容量比例配了但没算耐久度、磁盘组数量按容量需求定了但没考虑写并发、条带宽度一直用默认值、容量使用率爬到 80% 才想起来要控制。与其在压测跑不上去的时候翻参数手册，不如在画拓扑图的时候多花两个小时，把写入量、并发度、故障域、空闲空间这四笔账算清楚。真到了线上再改，成本完全是另一个量级。