我遇到过一套规模不大的 vSAN 环境三台主机、全闪、双口万兆每台机器两个磁盘组4K 随机写压测跑到两万 IOPS 左右延迟就开始往上顶再往上加压力吞吐几乎不动延迟像台阶一样跳。当时第一反应是网络有问题或者缓存盘不行把 vSAN 的对象结构、磁盘组配置、存储策略三样东西摊开对了一遍才发现问题不在某一个慢的部件上而是架构在设计阶段就把上限写死了条带宽度是 1每个虚拟磁盘的所有组件都压在同一个磁盘组里再大的并发也只能靠那一个磁盘组和一个缓存盘去扛。这件事挺典型。vSAN 这套软件定义存储把存储控制平面塞进了 vSphere 内核里好处是部署简单、策略驱动、按虚拟机粒度管数据坏处是所有聪明都藏在默认值里默认值不会主动告诉你它做了哪些妥协。很多人装完集群、点几下鼠标跑通了虚拟机就以为完事了等到真上生产负载才发现性能曲线早早横盘。这篇内容就是想把这套东西拆开讲清楚vSAN 的数据到底怎么落盘、磁盘组怎么设计才不会给自己挖坑、存储策略里每一个选项背后的代价是什么、性能上不去的时候按什么顺序往下查。读者对象很明确管着或者准备管一套 vSAN 集群的人从刚接触的新手到已经踩过几个坑的老手都能在里面找到对得上号的场景。1. 一次压测卡在 2 万 IOPS 之后vSAN 的数据到底落在哪先把架构摊开。vSAN 不是把一堆本地盘拼成一个共享目录这么简单的东西。它在每台 ESXi 主机上运行一个存储层把这些主机的本地磁盘组织成一个分布式对象存储对外呈现为一个 datastore。虚拟机磁盘VMDK、swap 文件、ISO、命名空间目录在 vSAN 眼里都是对象。这个抽象是理解一切性能和策略问题的起点因为你在界面上看到的一个虚拟磁盘 500GB底下可能对应着十几个分布在不同主机上的组件。不理解对象结构的人调优基本等于蒙着眼睛拧旋钮。你会发现策略里那些选项——容错数、纠删码、条带宽度——看起来像是几个孤立开关实际上它们共同决定了这个对象被切成几块、每块放在哪几台主机、每台主机上占几个组件。这几个问题的答案直接决定了这个虚拟磁盘能吃到的并发上限。1.1 对象、组件、见证把一块虚拟磁盘拆开看一个虚拟磁盘对象按存储策略被切分成若干个组件Component组件分布在不同的主机上。以最常见的 FTT1容忍一次故障镜像策略为例一个对象会有两份完整副本分别落在两台不同主机的磁盘组里另外还会有一个**见证Witness**组件放在第三台主机上。见证不存实际数据只存元数据作用是在网络分裂的时候充当仲裁者判断哪一侧的副本是多数派避免出现两个副本都自认为是主的情况。用一个生活化的类比一份重要合同你复印两份放两个不同的抽屉再在第三个抽屉里放一张纸条写着这份合同在 A 抽屉和 B 抽屉各有一份。纸条本身没有合同内容但当某天你发现 A 抽屉打不开时靠这张纸条能确认 B 抽屉里的那份是完整的、可以用的。vSAN 的见证组件干的就是这张纸条的活。这个结构带来两个直接影响。第一容量规划不能只算两份副本。一个带 FTT1 的对象实际占用是 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指标为什么重要参考要求写入耐久度DWPD 或 TBW缓存盘是所有写入的必经之路写入量远超容量盘写密集场景建议 3 DWPD 以上能到 5 到 10 更稳持续写带宽写缓冲满时要有能力持续下刷不能写几十秒就掉速看厂商给的稳态写曲线不看峰值掉电保护PLP缓存盘上有可能尚未落盘的数据掉电不能丢必须带电容或同类掉电保护企业级盘标配还有一点容易被忽略缓存盘不做 RAID 保护。一个磁盘组只有一块缓存盘它坏了整个磁盘组就不可用容量盘上的数据要等其他副本凑齐或者重建。所以缓存盘选的不是性价比是可靠性 稳态性能。为了省一点预算在缓存盘上降规格是这个领域里最不划算的省钱方式。2.3 全闪写缓冲的耐久度换算实例耐久度这个事很多人看到 DWPD 这个参数没概念不知道自己要几个。给一个具体的算法。假设一套全闪集群单台主机配 8 块 3.84TB 容量盘分两个磁盘组每组 4 块容量盘单机原始容量约 30TB。按容量层 10% 的经验值配缓存单机需要约 3TB 的缓存容量也就是每组约 1.5TB实际选型时一般选 1.6TB 的企业级盘。接下来算每天有多少数据会写到这块缓存盘上。假设这套集群承载的业务前端每天实际写入 8TB注意是真正写下去的数据不是读。镜像策略 FTT1 意味着每份数据写两份所以集群层面的后端写入量是 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 与主机数量的硬性对应关系FTTFailures To Tolerate是最基础的选项但它和集群规模是硬绑定的不是想要几就能给几。用镜像策略时副本数是 FTT1加上见证需要的故障域数量是 2×FTT1。用表格看得清楚FTT镜像策略所需最少主机数空间开销典型场景011 倍测试环境、可重建的临时数据132 倍绝大多数生产环境的起点253 倍核心业务、不能忍受同时两台主机故障374 倍极少数高要求场景成本很高这个表最实用的一点是它告诉你三节点集群做 FTT1 是可行的做 FTT2 是做梦。很多人规划的时候想要 FTT2一看成本就砍到三台主机结果策略还挂着 FTT2创建虚拟机直接失败或者被迫降到 FTT1白白浪费规划时间。还有一个细节三节点集群做 FTT1见证组件放在哪里答案是放在三台主机中的一台因为见证不占实际容量只占一点元数据。但这样一来那台承载见证的主机如果掉线虽然数据还在但仲裁能力会受影响。规模小到这个程度冗余本身就是脆弱的心里要有数。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 几个高频元凶与验证方法排查过程中反复遇到的坑差不多就这么几类做个对照表方便快速比对现象最可能的原因怎么验证处理方向写延迟高、读延迟正常缓存盘写缓冲饱和vsantop 看缓存盘的写延迟和下刷量增加磁盘组数量、换更高耐久的缓存盘整体延迟周期性尖刺重建或重新配置在跑看集群任务和组件状态限速、推迟批量任务单台虚拟机持续慢组件集中、条带宽度为 1看该虚拟机的组件分布调大条带宽度、或迁移到空闲主机高并发时后端拥塞飙升队列被打满性能服务看后端拥塞指标分散负载、增加磁盘组容量使用率 80% 以上后变慢空闲空间不足下刷和重建困难看使用率和组件健康状况扩容或清理数据压回 70% 以下所有虚拟机同时变慢网络带宽打满或 MTU 不一致看物理网卡吞吐、做大包连通性测试分流网络、统一 MTU这张表不是穷举但它覆盖了大部分现场问题。用的时候有个顺序建议先看容量使用率再看重建状态再看缓存盘最后才看策略和条带。前两个是最容易被忽略的很多性能问题其实是容量问题。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 文件单独指定一个策略比如 FTT0 或者用纠删码或者在有本地盘的主机上放到本地盘能省下不少容量。7. 扩容与日常维护里那些容易翻车的地方集群跑起来之后真正出事的时间点往往不是上线当天而是扩容、维护、升级这些动一下的操作。这些操作本身不复杂复杂的是它们对集群状态的瞬时影响。7.1 扩容顺序与磁盘组退役加容量有两条路加主机或者在现有主机上加磁盘组/容量盘。加主机是最简单的加进去之后 vSAN 会自动做一次重新平衡把部分数据迁到新主机上。这个过程同样吃带宽别指望加完立刻见效等平衡跑完再看容量和性能。有个细节新主机加入之前先确认固件版本、驱动版本、磁盘型号和现有集群尽量一致混用的后果是性能参差不齐严重的会识别不到盘。在现有主机上加磁盘组要注意主机的控制器和背板能不能撑住。很多服务器的磁盘位是够的但 RAID 控制器或者 HBA 的队列深度、缓存配置跟不上加完盘性能反而下降。上线前查一下控制器对硬盘数量的支持上限别踩这个坑。磁盘组退役撤出数据是把一个磁盘组从集群里摘出去的标准动作换盘、换控制器、调整布局都要用。这个操作会把组上的数据迁走耗时跟数据量成正比。操作期间该磁盘组的性能会下降其他磁盘组要承接迁过来的数据整体延迟会有波动。挑低峰期做一次只撤一个别并行。7.2 维护模式两种模式的取舍主机进维护模式时vSAN 给两个选项确保可访问性Ensure Accessibility和完整数据迁移Full Data Migration。前者只保证数据依然可访问该主机上的组件不会全部迁走只迁到满足策略最低要求的程度。速度快但主机离线期间集群实际上是降级的如果这时再坏一台主机数据就可能不可用。后者把该主机上的所有组件都迁走主机离线期间集群仍然是完整冗余。速度慢可能跑几个小时但安全。选择逻辑很简单维护窗口短、有把握不叠加故障、集群容量紧张 → 确保可访问性维护时间长、风险不确定、容量充足 → 完整数据迁移。生产环境我偏向后者除非时间实在来不及。降级状态下待上几个小时万一这时候有块盘出问题就是一次真故障。7.3 固件、驱动一致性这一条放在最后但绝对不是最不重要。同一集群里控制器固件版本不一致、磁盘固件版本不一致、网卡驱动版本不一致会导致的问题包括识别不到设备、性能差异极大、重建失败、偶发的组件降级。而且这些问题的表现往往很不直观报错信息也指不到根子上。做法很朴素升级前查兼容性列表确认控制器、磁盘、网卡、驱动的组合是被支持的建立集群的时候就把所有主机的固件刷到同一个版本后续加新主机先刷固件再入集群。这些工作在上线前做一遍能省掉后面无数排查时间。我个人在几套环境上折腾下来的体会是vSAN 这套东西的默认行为其实相当合理绝大多数性能问题不是参数调得不对而是规划阶段的假设和实际负载不匹配缓存盘按容量比例配了但没算耐久度、磁盘组数量按容量需求定了但没考虑写并发、条带宽度一直用默认值、容量使用率爬到 80% 才想起来要控制。与其在压测跑不上去的时候翻参数手册不如在画拓扑图的时候多花两个小时把写入量、并发度、故障域、空闲空间这四笔账算清楚。真到了线上再改成本完全是另一个量级。