尧图网站建设 
简介VMware vSAN 8.0 U1 Express Storage Architecture Deep Dive是一份面向虚拟化管理员、存储工程师和数据中心架构师的深度技术资料聚焦vSAN 8在软件定义数据中心中的设计与落地帮助读者厘清超融合存储的部署前提、网络规划及故障处理路径。资源为1个PDF文件容量23.69MB以官方白皮书式的完整篇章呈现适合需要系统掌握vSAN 8的运维与规划人员。文档从vSAN前置条件、硬件与网络兼容性、集群快速启动向导、VMkernel网络和分布式交换机配置讲起逐步深入到vSAN ESA的分布式RAID、对象与组件、VMDK布局、数据缓存与压缩、加密、拉伸集群与ROBO、故障域、vSphere HA及VMCP保护等核心机制最后还涉及存储策略和虚拟机置备流程。相比碎片化教程这份资料提供了完整的架构原理、配置场景和排错思路可直接用于实际环境设计参考。目前已有155人学习下载对上线前评估或日常运维vSAN的技术团队具有较高参考价值。1. vSAN 8 这份 PDF为什么说它比翻官网文档更省时间很多人接触 VMware 是从虚拟机安装教程开始的在 workstation 里装个 Linux 先练手。但到了生产环境真正决定集群稳定性的不是虚拟机怎么装而是底层存储怎么设计。vSAN 8 作为 VMware 超融合架构的核心组件把计算和存储揉进了同一个集群里。这份 vSAN 8 PDF 文档让我觉得值钱的点在于它把从架构选型、硬件兼容性、存储策略到健康检查的完整链路串在一起而不是散落一地的官网章节。尤其适合准备新建全闪集群的虚拟化管理员、要给业务做存储方案选型的架构师以及被 vSAN 健康检查搞到怀疑人生的运维。如果你以为 vSAN 8 只是 vSAN 7 加了个版本号这份文档会直接推翻这个想法。2. 架构优先读OSA 与 ESA 的取舍决定后续所有配置vSAN 8 和以往版本最大的不同是一个版本里同时存在两套存储架构。部署前不搞懂这个后面每一步配置都容易走偏。2.1 OSA磁盘组模式还在但别把老经验直接搬过来OSA 是 Original Storage Architecture延续 vSAN 6.x / 7.x 的对象与磁盘组设计。每个磁盘组由一个缓存设备加最多 7 个容量设备构成缓存盘承担写缓冲和读命中容量盘负责实际数据落盘。这个设计在混合存储时代是合理的缓存层用高性能 SSD容量层用大容量 HDD 或 SATA SSD成本均衡。vSAN 8 保留 OSA 的主要目的是让存量集群能平滑升级。如果你的集群里还混着机械盘或者节点间介质类型差距很大那 OSA 基本是唯一选择。对于已经在 vSAN 7 上跑了很久的环境OSA 也意味着升级路径更短不用重新规划存储池。但这里有个特别容易让老手翻车的点在 vSAN 7 里你习惯先算缓存盘容量一般缓存盘不低于容量盘的 10%容量盘选大容量 SSD这是常规做法。到了 vSAN 8 的 ESA 界面你根本找不到“磁盘组”这个入口。因为 ESA 里没有磁盘组没有缓存盘和容量盘的划分存储池直接纳管所有 NVMe。老经验在这里不是资产是包袱。我一般会先回答三个问题再决定走哪套架构节点是否全 NVMe能否接受集群内所有节点存储配置一致集群里有没有 vSAN 6.x/7.x 时代遗留的混合磁盘节点如果前两问都是“是”直接选 ESA否则留在 OSA。别因为想尝鲜就把现有混合集群强行迁到 ESA那个过程比想象中痛苦。2.2 ESA为什么 vSAN 8 要重写存储栈ESA 是 Express Storage Architecture设计目标很直接让全 NVMe 硬件的性能被真正释放。它取消了磁盘组用存储池统一纳管节点上的多块 NVMe不再单独划分缓存盘读写路径大幅缩短。去重与压缩默认开启数据落盘前先做处理显著降低写放大。另一个关键差异在对象布局。OSA 的对象组件分布规则受磁盘组结构约束组件数量、位置都有限制ESA 把数据分片做得更扁平条带化开销低。实际对比中同样 4K 随机写场景下ESA 的整体延迟表现比 OSA 明显更好尤其是队列深度上来之后。但 ESA 对同质化要求极高。我第一次部署时吃过亏三个节点里有一块 NVMe 型号不同健康检查的“硬件兼容性”界面一直报黄。后来把所有节点的存储控制器模式、NVMe 固件版本、驱动版本统一问题才消失。所以别把 ESA 理解成“更快的 OSA”它是一套新的存储栈要求你用新的部署规范去对待。2.3 这份文档里最值得反复看的参数表读这份 PDF 时我第一件事是圈出 OSA 与 ESA 的对比表参数如下对比项OSAESA设备要求缓存盘加容量盘可混合介质全 NVMe磁盘组结构有1 缓存加最多 7 容量无存储池去重压缩可选仅全闪存场景默认启用控制器模式直通或 RAID 透传仅直通模式存储策略参数FTT、条带、IOPS 预留FTT、条带、IOPS 预留底层映射有差异第二张要记住的是存储策略的默认参数参数默认值含义允许的故障数 FTT1可容忍 1 台主机或磁盘故障条带化 Stripe Width1对象跨盘数量IOPS 预留0不预留性能共享对象空间预留0%按需分配不占冗余这两张表不用背但要看架构图时对得上号。为什么 FTT1 至少需要 3 个节点为什么条带化开太高会放大写开销为什么 IOPS 预留设了反而让部分业务受影响PDF 里都有配套解释。建议先读架构章节再回来看策略章节顺序反了会越看越糊涂。3. 部署落地硬件兼容性、网络规划与集群创建架构选定了接下来是部署。这一步最忌讳“先建集群再补课”硬件和网络的问题藏不住越往后爆越大。3.1 硬件兼容性先过 HCL别让节点数骗了你vSAN 8 的 ESA 对硬件要求比 OSA 严格得多。第一步是查 VMware HCL而不是看官网宣传页。需要确认的硬件项包括存储控制器必须支持直通模式或 RAID 透传HCL 里标注的型号和固件版本必须一致NVMe 设备在 HCL 列表内且全节点型号一致内存每个节点至少 32 GB生产环境建议 64 GB 起BIOS 电源模式建议 Performance 模式vSAN 对 CPU 频率和电源状态敏感常见误区是拿“三个节点”当万金油。vSAN 最少 3 节点没错但 ESA 对节点配置的一致性要求很高三个节点硬件不一致容量规划和故障域设计都会出问题。我见过一个集群节点 A 的 NVMe 是 7.68 TB节点 B 和 C 是 3.84 TB结果想配 FTT1 的策略容量却被最小的节点卡住白白浪费一大块空间。3.2 网络规划vSAN 流量与 MTU 9000vSAN 流量最好走单独的分布式交换机端口组使用独立 VMKernel 端口不要和 vMotion、管理流量混在一起。MTU 务必设置 9000这是 vSAN 部署的基本操作但也是后续健康检查最爱出问题的地方。常用配置步骤在 vCenter 里创建一个分布式交换机上行链路绑定两个物理网卡做链路聚合。创建 vSAN VMKernel 端口启用“vSAN 流量”服务。物理交换机端口和 VDS 端口组统一 MTU 9000。如果使用单播模式确认 CMMDS 单播配置正确如果保留默认多播确认网络设备允许组播转发。这里补一句vSAN 健康检查里最常见的网络问题多半不是带宽不够而是 MTU 不一致。物理交换机开了 9000VDS 没开或者两个节点一个走标准交换机一个走分布式交换机MTU 一边 1500 一边 9000。现象就是集群能通但 IO 延迟时高时低健康检查报“网络配置错误”。3.3 集群创建与启用 vSAN 的实际步骤在 vCenter 里启用 vSAN 8 的路径如下新建数据中心新建集群开启 vSphere HA 和 DRS。向集群添加 ESXi 主机确保版本统一为 vSphere 8 对应版本。在集群的“配置 → vSAN”里点击“启用”选择 OSA 或 ESA。勾选“声明磁盘”vSAN 会要求确认要纳管的磁盘。选择故障域数量设置延迟容错ESA 架构下默认自动处理。启用后用命令行检查集群状态# 查看 vSAN 集群整体状态 esxcli vsan cluster get # 查看每个节点的 vSAN 启用状态 esxcli vsan cluster list # 查看存储设备纳管情况 esxcli vsan storage list这三条命令是初始化后必查的。esxcli vsan cluster get输出里重点看 Cluster UUID 和运行状态如果显示版本不兼容说明集群中不同主机的 vSAN 版本不一致。esxcli vsan storage list输出会列出每块磁盘的状态重点看 State 字段是 Eligible 还是 In use如果磁盘停留在 Eligible说明没有成功声明需要回到 vCenter 检查磁盘筛选条件。启用后不要急着建虚拟机先看健康检查是否全绿再开始测试业务负载。4. 存储策略调参把 FTT、条带化与业务负载对齐存储策略是 vSAN 集群里最值得花时间研究的配置。同一套集群可以同时跑多套策略策略定得好不好直接决定容量利用率和性能表现。4.1 存储策略里的四个核心参数vSAN 存储策略在虚拟机级别生效核心参数有四个FTT容错数。允许同时故障的组件数。FTT1 表示至少能坏 1 块盘或 1 台主机数据不丢。条带化Stripe Width。一个对象跨几块盘。默认 1调大提升并发吞吐但也会放大写开销。IOPS 预留。给虚拟磁盘预留的 IOPS 上限类似 QoS指定后会占用额外调度资源。对象空间预留。是否提前分配实际容量。0% 是按需分配100% 是厚置备。参数选型的关键在于FTT 决定节点数下限条带化决定性能IOPS 预留和空间预留是成本选项。默认策略 FTT1、条带1、IOPS 预留0、空间预留0%对大多数业务够用但高并发数据库和日志型应用需要单独调整。4.2 镜像还是纠删码RAID-1/5/6 怎么选vSAN 支持三种冗余方式策略冗余方式最小节点数空间开销适合场景RAID-1 镜像完整副本32 倍数据库、核心业务延迟敏感RAID-5 纠删码1 校验块41.33 倍大容量读多写少RAID-6 纠删码2 校验块51.5 倍更大容量、更高冗余生产中的选择标准我常用的一个判断方式写入占比超过 20% 的虚拟机用 RAID-1写入少、容量需求大用 RAID-5。RAID-6 在容量和性能之间比较尴尬一般只有监管要求强制双故障时才选。注意RAID-5/6 的写惩罚比镜像高因为需要计算校验块。高并发 OLTP 如果把策略配成 RAID-5往往会发现延迟比预期高不少这不是硬件问题是冗余算法本身的代价。4.3 把策略绑到虚拟机最小可行配置在 vCenter 里给虚拟机设置 vSAN 策略的路径虚拟机属性打开 vSphere 存储策略。选择已有策略或新建策略。新建策略时选择 vSAN 作为规则集。设定 FTT、条带化、IOPS 预留、空间预留等参数。保存后应用到虚拟机或模板。示例给 MySQL 数据盘配置的参考策略参数参数推荐值说明容错方法RAID-1写敏感业务镜像最稳FTT1至少 3 节点条带化2数据卷跨 2 块盘提升并行度IOPS 预留1000保证单盘 IO 下限空间预留0%按需分配策略应用不是即时的vSAN 会在后台通过重新平衡任务迁移对象。刚应用完看到虚拟机存储显示“不符合”是正常的等几分钟看存储策略状态变成“符合”即可。如果长时间不变说明集群里没有足够资源满足策略需要回去看容量。5. 运维避坑vSAN 8 环境里最常见的五个翻车现场vSAN 的坑大多是配置层面埋下的不是硬件随机故障。这五条是我见过最常翻车的场景每一条都按现象、原因、解决拆开说。5.1 现象一启用 ESA 后延迟不降反升现象全 NVMe 节点启用 ESA 后 4K 随机读写延迟反而比旧集群高IO 监控显示存储延迟经常超过 10 毫秒。原因节点里混用了 SATA SSD 和 NVMe。ESA 要求全 NVMeSATA SSD 的存在会让存储池把数据放到低速盘上读写路径没法走最优链路健康检查也会一直报警。解决把 SATA SSD 从 vSAN 声明中排除或直接换掉。重启 vSAN 后确认esxcli vsan storage list里所有被纳管的设备都是 NVMe再重新跑健康检查。5.2 现象二健康检查一直报网络配置错误现象集群能正常创建虚拟机也能跑但 vCenter 里 vSAN 健康检查显示网络配置错误IO 延迟时高时低。原因MTU 不一致。物理交换机端口开了 9000但 VDS 端口组是默认 1500或者 vSAN 流量和管理流量挤在同一个 VMKernel 端口广播域互相干扰。解决给 vSAN 建独立分布式交换机单独一个 vSAN VMKernel 端口所有上行链路和端口组统一 MTU 9000。改完再到健康检查里手动运行网络测试直到全绿。5.3 现象三磁盘组反复进入已挂载但降级状态现象OSA 架构下磁盘组状态在正常和降级之间反复横跳重建任务一直在跑容量时大时小。原因存储控制器处于 RAID 模式vSAN 看到的是 RAID 组而不是单块直通盘。一旦有磁盘在控制器层面被标记异常磁盘组就会降级。解决把控制器切到直通或 JBOD 模式重新声明磁盘。操作前确认控制器 HCL 列表里支持直通并做好数据备份。切模式会触发磁盘重建不要在业务高峰期做。5.4 现象四删除虚拟机后容量没回收现象删掉一批虚拟机后vSAN 集群可用容量没有明显增加容量监控甚至还往上走。原因虚拟机删除后对象进入后台重删除队列清理任务分批执行。如果虚拟机有快照或策略里开了空间预留对象会残留更久。解决确认删除操作完成后检查存储里的对象数量变化。如果长期不回收用esxcli vsan debug object list查看残留对象手动清理孤立对象。不要反复扩容容量未必真的不够。5.5 现象五vCenter 健康检查显示出无响应现象vSAN 健康检查或性能服务显示无响应数据不出来虚拟机性能看着正常但心里没底。原因多节点 vSAN 集群中某个 ESXi 主机开启了 SSH 和性能服务但数据库数据异常或者 vCenter 和 ESXi 版本不一致导致性能收集器拿不到数据。解决先把所有主机统一到同一个补丁版本重启 vSAN 健康检查服务再检查每个节点的 vSAN 集群运行状态。跑一遍esxcli vsan health cluster list看具体是哪个检查项无响应再针对性处理。6. 用命令行做健康检查把验证动作养成习惯vCenter 界面上的健康检查很好点但生产上我更习惯用命令行因为可以脚本化变更前后各跑一次对比。先用三组命令建立基准# 集群级健康检查 esxcli vsan health cluster list # 检查所有节点的性能和拥塞 esxcli vsan health cluster list --health-type perf # 查看存储设备纳管情况 esxcli vsan storage listesxcli vsan health cluster list是核心命令输出每个健康检查项的状态包括绿色、黄色、红色。升级 ESXi 或换硬件后我都会在这里跑一次确认没有黄色项。--health-type perf能看延迟和拥塞情况数据库业务变更前必跑。变更后验证的习惯是变更前跑一次 health cluster list把结果存成文本。变更后重复一次对比黄色和红色项。有问题再用 cluster get 和 storage list 定位具体节点。有一次我就是靠着这个习惯在一台主机驱动升级后立刻发现了 vSAN 健康检查的红色告警回滚命令执行得干净利落。从那以后每次动 ESXi 驱动、固件或存储控制器之前我都强制走一遍这套命令行检查流程不依赖 vCenter 界面也不信“顺手升一下应该没事”。希望帮到你拿到这份 PDF 之后建议先翻架构和健康检查那两章再动手后面能少踩很多坑。本文还有配套的精品资源点击获取 vSAN 8 超融合实战：OSA与ESA架构选型及存储策略指南
简介VMware vSAN 8.0 U1 Express Storage Architecture Deep Dive是一份面向虚拟化管理员、存储工程师和数据中心架构师的深度技术资料聚焦vSAN 8在软件定义数据中心中的设计与落地帮助读者厘清超融合存储的部署前提、网络规划及故障处理路径。资源为1个PDF文件容量23.69MB以官方白皮书式的完整篇章呈现适合需要系统掌握vSAN 8的运维与规划人员。文档从vSAN前置条件、硬件与网络兼容性、集群快速启动向导、VMkernel网络和分布式交换机配置讲起逐步深入到vSAN ESA的分布式RAID、对象与组件、VMDK布局、数据缓存与压缩、加密、拉伸集群与ROBO、故障域、vSphere HA及VMCP保护等核心机制最后还涉及存储策略和虚拟机置备流程。相比碎片化教程这份资料提供了完整的架构原理、配置场景和排错思路可直接用于实际环境设计参考。目前已有155人学习下载对上线前评估或日常运维vSAN的技术团队具有较高参考价值。1. vSAN 8 这份 PDF为什么说它比翻官网文档更省时间很多人接触 VMware 是从虚拟机安装教程开始的在 workstation 里装个 Linux 先练手。但到了生产环境真正决定集群稳定性的不是虚拟机怎么装而是底层存储怎么设计。vSAN 8 作为 VMware 超融合架构的核心组件把计算和存储揉进了同一个集群里。这份 vSAN 8 PDF 文档让我觉得值钱的点在于它把从架构选型、硬件兼容性、存储策略到健康检查的完整链路串在一起而不是散落一地的官网章节。尤其适合准备新建全闪集群的虚拟化管理员、要给业务做存储方案选型的架构师以及被 vSAN 健康检查搞到怀疑人生的运维。如果你以为 vSAN 8 只是 vSAN 7 加了个版本号这份文档会直接推翻这个想法。2. 架构优先读OSA 与 ESA 的取舍决定后续所有配置vSAN 8 和以往版本最大的不同是一个版本里同时存在两套存储架构。部署前不搞懂这个后面每一步配置都容易走偏。2.1 OSA磁盘组模式还在但别把老经验直接搬过来OSA 是 Original Storage Architecture延续 vSAN 6.x / 7.x 的对象与磁盘组设计。每个磁盘组由一个缓存设备加最多 7 个容量设备构成缓存盘承担写缓冲和读命中容量盘负责实际数据落盘。这个设计在混合存储时代是合理的缓存层用高性能 SSD容量层用大容量 HDD 或 SATA SSD成本均衡。vSAN 8 保留 OSA 的主要目的是让存量集群能平滑升级。如果你的集群里还混着机械盘或者节点间介质类型差距很大那 OSA 基本是唯一选择。对于已经在 vSAN 7 上跑了很久的环境OSA 也意味着升级路径更短不用重新规划存储池。但这里有个特别容易让老手翻车的点在 vSAN 7 里你习惯先算缓存盘容量一般缓存盘不低于容量盘的 10%容量盘选大容量 SSD这是常规做法。到了 vSAN 8 的 ESA 界面你根本找不到“磁盘组”这个入口。因为 ESA 里没有磁盘组没有缓存盘和容量盘的划分存储池直接纳管所有 NVMe。老经验在这里不是资产是包袱。我一般会先回答三个问题再决定走哪套架构节点是否全 NVMe能否接受集群内所有节点存储配置一致集群里有没有 vSAN 6.x/7.x 时代遗留的混合磁盘节点如果前两问都是“是”直接选 ESA否则留在 OSA。别因为想尝鲜就把现有混合集群强行迁到 ESA那个过程比想象中痛苦。2.2 ESA为什么 vSAN 8 要重写存储栈ESA 是 Express Storage Architecture设计目标很直接让全 NVMe 硬件的性能被真正释放。它取消了磁盘组用存储池统一纳管节点上的多块 NVMe不再单独划分缓存盘读写路径大幅缩短。去重与压缩默认开启数据落盘前先做处理显著降低写放大。另一个关键差异在对象布局。OSA 的对象组件分布规则受磁盘组结构约束组件数量、位置都有限制ESA 把数据分片做得更扁平条带化开销低。实际对比中同样 4K 随机写场景下ESA 的整体延迟表现比 OSA 明显更好尤其是队列深度上来之后。但 ESA 对同质化要求极高。我第一次部署时吃过亏三个节点里有一块 NVMe 型号不同健康检查的“硬件兼容性”界面一直报黄。后来把所有节点的存储控制器模式、NVMe 固件版本、驱动版本统一问题才消失。所以别把 ESA 理解成“更快的 OSA”它是一套新的存储栈要求你用新的部署规范去对待。2.3 这份文档里最值得反复看的参数表读这份 PDF 时我第一件事是圈出 OSA 与 ESA 的对比表参数如下对比项OSAESA设备要求缓存盘加容量盘可混合介质全 NVMe磁盘组结构有1 缓存加最多 7 容量无存储池去重压缩可选仅全闪存场景默认启用控制器模式直通或 RAID 透传仅直通模式存储策略参数FTT、条带、IOPS 预留FTT、条带、IOPS 预留底层映射有差异第二张要记住的是存储策略的默认参数参数默认值含义允许的故障数 FTT1可容忍 1 台主机或磁盘故障条带化 Stripe Width1对象跨盘数量IOPS 预留0不预留性能共享对象空间预留0%按需分配不占冗余这两张表不用背但要看架构图时对得上号。为什么 FTT1 至少需要 3 个节点为什么条带化开太高会放大写开销为什么 IOPS 预留设了反而让部分业务受影响PDF 里都有配套解释。建议先读架构章节再回来看策略章节顺序反了会越看越糊涂。3. 部署落地硬件兼容性、网络规划与集群创建架构选定了接下来是部署。这一步最忌讳“先建集群再补课”硬件和网络的问题藏不住越往后爆越大。3.1 硬件兼容性先过 HCL别让节点数骗了你vSAN 8 的 ESA 对硬件要求比 OSA 严格得多。第一步是查 VMware HCL而不是看官网宣传页。需要确认的硬件项包括存储控制器必须支持直通模式或 RAID 透传HCL 里标注的型号和固件版本必须一致NVMe 设备在 HCL 列表内且全节点型号一致内存每个节点至少 32 GB生产环境建议 64 GB 起BIOS 电源模式建议 Performance 模式vSAN 对 CPU 频率和电源状态敏感常见误区是拿“三个节点”当万金油。vSAN 最少 3 节点没错但 ESA 对节点配置的一致性要求很高三个节点硬件不一致容量规划和故障域设计都会出问题。我见过一个集群节点 A 的 NVMe 是 7.68 TB节点 B 和 C 是 3.84 TB结果想配 FTT1 的策略容量却被最小的节点卡住白白浪费一大块空间。3.2 网络规划vSAN 流量与 MTU 9000vSAN 流量最好走单独的分布式交换机端口组使用独立 VMKernel 端口不要和 vMotion、管理流量混在一起。MTU 务必设置 9000这是 vSAN 部署的基本操作但也是后续健康检查最爱出问题的地方。常用配置步骤在 vCenter 里创建一个分布式交换机上行链路绑定两个物理网卡做链路聚合。创建 vSAN VMKernel 端口启用“vSAN 流量”服务。物理交换机端口和 VDS 端口组统一 MTU 9000。如果使用单播模式确认 CMMDS 单播配置正确如果保留默认多播确认网络设备允许组播转发。这里补一句vSAN 健康检查里最常见的网络问题多半不是带宽不够而是 MTU 不一致。物理交换机开了 9000VDS 没开或者两个节点一个走标准交换机一个走分布式交换机MTU 一边 1500 一边 9000。现象就是集群能通但 IO 延迟时高时低健康检查报“网络配置错误”。3.3 集群创建与启用 vSAN 的实际步骤在 vCenter 里启用 vSAN 8 的路径如下新建数据中心新建集群开启 vSphere HA 和 DRS。向集群添加 ESXi 主机确保版本统一为 vSphere 8 对应版本。在集群的“配置 → vSAN”里点击“启用”选择 OSA 或 ESA。勾选“声明磁盘”vSAN 会要求确认要纳管的磁盘。选择故障域数量设置延迟容错ESA 架构下默认自动处理。启用后用命令行检查集群状态# 查看 vSAN 集群整体状态 esxcli vsan cluster get # 查看每个节点的 vSAN 启用状态 esxcli vsan cluster list # 查看存储设备纳管情况 esxcli vsan storage list这三条命令是初始化后必查的。esxcli vsan cluster get输出里重点看 Cluster UUID 和运行状态如果显示版本不兼容说明集群中不同主机的 vSAN 版本不一致。esxcli vsan storage list输出会列出每块磁盘的状态重点看 State 字段是 Eligible 还是 In use如果磁盘停留在 Eligible说明没有成功声明需要回到 vCenter 检查磁盘筛选条件。启用后不要急着建虚拟机先看健康检查是否全绿再开始测试业务负载。4. 存储策略调参把 FTT、条带化与业务负载对齐存储策略是 vSAN 集群里最值得花时间研究的配置。同一套集群可以同时跑多套策略策略定得好不好直接决定容量利用率和性能表现。4.1 存储策略里的四个核心参数vSAN 存储策略在虚拟机级别生效核心参数有四个FTT容错数。允许同时故障的组件数。FTT1 表示至少能坏 1 块盘或 1 台主机数据不丢。条带化Stripe Width。一个对象跨几块盘。默认 1调大提升并发吞吐但也会放大写开销。IOPS 预留。给虚拟磁盘预留的 IOPS 上限类似 QoS指定后会占用额外调度资源。对象空间预留。是否提前分配实际容量。0% 是按需分配100% 是厚置备。参数选型的关键在于FTT 决定节点数下限条带化决定性能IOPS 预留和空间预留是成本选项。默认策略 FTT1、条带1、IOPS 预留0、空间预留0%对大多数业务够用但高并发数据库和日志型应用需要单独调整。4.2 镜像还是纠删码RAID-1/5/6 怎么选vSAN 支持三种冗余方式策略冗余方式最小节点数空间开销适合场景RAID-1 镜像完整副本32 倍数据库、核心业务延迟敏感RAID-5 纠删码1 校验块41.33 倍大容量读多写少RAID-6 纠删码2 校验块51.5 倍更大容量、更高冗余生产中的选择标准我常用的一个判断方式写入占比超过 20% 的虚拟机用 RAID-1写入少、容量需求大用 RAID-5。RAID-6 在容量和性能之间比较尴尬一般只有监管要求强制双故障时才选。注意RAID-5/6 的写惩罚比镜像高因为需要计算校验块。高并发 OLTP 如果把策略配成 RAID-5往往会发现延迟比预期高不少这不是硬件问题是冗余算法本身的代价。4.3 把策略绑到虚拟机最小可行配置在 vCenter 里给虚拟机设置 vSAN 策略的路径虚拟机属性打开 vSphere 存储策略。选择已有策略或新建策略。新建策略时选择 vSAN 作为规则集。设定 FTT、条带化、IOPS 预留、空间预留等参数。保存后应用到虚拟机或模板。示例给 MySQL 数据盘配置的参考策略参数参数推荐值说明容错方法RAID-1写敏感业务镜像最稳FTT1至少 3 节点条带化2数据卷跨 2 块盘提升并行度IOPS 预留1000保证单盘 IO 下限空间预留0%按需分配策略应用不是即时的vSAN 会在后台通过重新平衡任务迁移对象。刚应用完看到虚拟机存储显示“不符合”是正常的等几分钟看存储策略状态变成“符合”即可。如果长时间不变说明集群里没有足够资源满足策略需要回去看容量。5. 运维避坑vSAN 8 环境里最常见的五个翻车现场vSAN 的坑大多是配置层面埋下的不是硬件随机故障。这五条是我见过最常翻车的场景每一条都按现象、原因、解决拆开说。5.1 现象一启用 ESA 后延迟不降反升现象全 NVMe 节点启用 ESA 后 4K 随机读写延迟反而比旧集群高IO 监控显示存储延迟经常超过 10 毫秒。原因节点里混用了 SATA SSD 和 NVMe。ESA 要求全 NVMeSATA SSD 的存在会让存储池把数据放到低速盘上读写路径没法走最优链路健康检查也会一直报警。解决把 SATA SSD 从 vSAN 声明中排除或直接换掉。重启 vSAN 后确认esxcli vsan storage list里所有被纳管的设备都是 NVMe再重新跑健康检查。5.2 现象二健康检查一直报网络配置错误现象集群能正常创建虚拟机也能跑但 vCenter 里 vSAN 健康检查显示网络配置错误IO 延迟时高时低。原因MTU 不一致。物理交换机端口开了 9000但 VDS 端口组是默认 1500或者 vSAN 流量和管理流量挤在同一个 VMKernel 端口广播域互相干扰。解决给 vSAN 建独立分布式交换机单独一个 vSAN VMKernel 端口所有上行链路和端口组统一 MTU 9000。改完再到健康检查里手动运行网络测试直到全绿。5.3 现象三磁盘组反复进入已挂载但降级状态现象OSA 架构下磁盘组状态在正常和降级之间反复横跳重建任务一直在跑容量时大时小。原因存储控制器处于 RAID 模式vSAN 看到的是 RAID 组而不是单块直通盘。一旦有磁盘在控制器层面被标记异常磁盘组就会降级。解决把控制器切到直通或 JBOD 模式重新声明磁盘。操作前确认控制器 HCL 列表里支持直通并做好数据备份。切模式会触发磁盘重建不要在业务高峰期做。5.4 现象四删除虚拟机后容量没回收现象删掉一批虚拟机后vSAN 集群可用容量没有明显增加容量监控甚至还往上走。原因虚拟机删除后对象进入后台重删除队列清理任务分批执行。如果虚拟机有快照或策略里开了空间预留对象会残留更久。解决确认删除操作完成后检查存储里的对象数量变化。如果长期不回收用esxcli vsan debug object list查看残留对象手动清理孤立对象。不要反复扩容容量未必真的不够。5.5 现象五vCenter 健康检查显示出无响应现象vSAN 健康检查或性能服务显示无响应数据不出来虚拟机性能看着正常但心里没底。原因多节点 vSAN 集群中某个 ESXi 主机开启了 SSH 和性能服务但数据库数据异常或者 vCenter 和 ESXi 版本不一致导致性能收集器拿不到数据。解决先把所有主机统一到同一个补丁版本重启 vSAN 健康检查服务再检查每个节点的 vSAN 集群运行状态。跑一遍esxcli vsan health cluster list看具体是哪个检查项无响应再针对性处理。6. 用命令行做健康检查把验证动作养成习惯vCenter 界面上的健康检查很好点但生产上我更习惯用命令行因为可以脚本化变更前后各跑一次对比。先用三组命令建立基准# 集群级健康检查 esxcli vsan health cluster list # 检查所有节点的性能和拥塞 esxcli vsan health cluster list --health-type perf # 查看存储设备纳管情况 esxcli vsan storage listesxcli vsan health cluster list是核心命令输出每个健康检查项的状态包括绿色、黄色、红色。升级 ESXi 或换硬件后我都会在这里跑一次确认没有黄色项。--health-type perf能看延迟和拥塞情况数据库业务变更前必跑。变更后验证的习惯是变更前跑一次 health cluster list把结果存成文本。变更后重复一次对比黄色和红色项。有问题再用 cluster get 和 storage list 定位具体节点。有一次我就是靠着这个习惯在一台主机驱动升级后立刻发现了 vSAN 健康检查的红色告警回滚命令执行得干净利落。从那以后每次动 ESXi 驱动、固件或存储控制器之前我都强制走一遍这套命令行检查流程不依赖 vCenter 界面也不信“顺手升一下应该没事”。希望帮到你拿到这份 PDF 之后建议先翻架构和健康检查那两章再动手后面能少踩很多坑。本文还有配套的精品资源点击获取