企业官网建设流程全解析

简介：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 的对比表，参数如下：

第二张要记住的，是存储策略的默认参数：

这两张表不用背，但要看架构图时对得上号。为什么 FTT=1 至少需要 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，结果想配 FTT=1 的策略，容量却被最小的节点卡住，白白浪费一大块空间。

3.2 网络规划：vSAN 流量与 MTU 9000

vSAN 流量最好走单独的分布式交换机端口组，使用独立 VMKernel 端口，不要和 vMotion、管理流量混在一起。MTU 务必设置 9000，这是 vSAN 部署的基本操作，但也是后续健康检查最爱出问题的地方。

常用配置步骤：

1. 在 vCenter 里创建一个分布式交换机，上行链路绑定两个物理网卡做链路聚合。
2. 创建 vSAN VMKernel 端口，启用“vSAN 流量”服务。
3. 物理交换机端口和 VDS 端口组统一 MTU 9000。
4. 如果使用单播模式，确认 CMMDS 单播配置正确；如果保留默认多播，确认网络设备允许组播转发。

这里补一句：vSAN 健康检查里最常见的网络问题，多半不是带宽不够，而是 MTU 不一致。物理交换机开了 9000，VDS 没开；或者两个节点一个走标准交换机一个走分布式交换机，MTU 一边 1500 一边 9000。现象就是集群能通，但 IO 延迟时高时低，健康检查报“网络配置错误”。

3.3 集群创建与启用 vSAN 的实际步骤

在 vCenter 里启用 vSAN 8 的路径如下：

1. 新建数据中心，新建集群，开启 vSphere HA 和 DRS。
2. 向集群添加 ESXi 主机，确保版本统一为 vSphere 8 对应版本。
3. 在集群的“配置 → vSAN”里点击“启用”，选择 OSA 或 ESA。
4. 勾选“声明磁盘”，vSAN 会要求确认要纳管的磁盘。
5. 选择故障域数量，设置延迟容错，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，容错数。允许同时故障的组件数。FTT=1 表示至少能坏 1 块盘或 1 台主机，数据不丢。
• 条带化，Stripe Width。一个对象跨几块盘。默认 1，调大提升并发吞吐，但也会放大写开销。
• IOPS 预留。给虚拟磁盘预留的 IOPS 上限，类似 QoS，指定后会占用额外调度资源。
• 对象空间预留。是否提前分配实际容量。0% 是按需分配，100% 是厚置备。

参数选型的关键在于：FTT 决定节点数下限，条带化决定性能，IOPS 预留和空间预留是成本选项。默认策略 FTT=1、条带=1、IOPS 预留=0、空间预留=0%，对大多数业务够用，但高并发数据库和日志型应用需要单独调整。

4.2 镜像还是纠删码：RAID-1/5/6 怎么选

vSAN 支持三种冗余方式：

生产中的选择标准，我常用的一个判断方式：写入占比超过 20% 的虚拟机，用 RAID-1；写入少、容量需求大，用 RAID-5。RAID-6 在容量和性能之间比较尴尬，一般只有监管要求强制双故障时才选。

注意：RAID-5/6 的写惩罚比镜像高，因为需要计算校验块。高并发 OLTP 如果把策略配成 RAID-5，往往会发现延迟比预期高不少，这不是硬件问题，是冗余算法本身的代价。

4.3 把策略绑到虚拟机：最小可行配置

在 vCenter 里给虚拟机设置 vSAN 策略的路径：

1. 虚拟机属性，打开 vSphere 存储策略。
2. 选择已有策略，或新建策略。
3. 新建策略时选择 vSAN 作为规则集。
4. 设定 FTT、条带化、IOPS 预留、空间预留等参数。
5. 保存后应用到虚拟机或模板。

示例，给 MySQL 数据盘配置的参考策略参数：

策略应用不是即时的，vSAN 会在后台通过重新平衡任务迁移对象。刚应用完看到虚拟机存储显示“不符合”是正常的，等几分钟，看存储策略状态变成“符合”即可。如果长时间不变，说明集群里没有足够资源满足策略，需要回去看容量。

5. 运维避坑：vSAN 8 环境里最常见的五个翻车现场

vSAN 的坑大多是配置层面埋下的，不是硬件随机故障。这五条是我见过最常翻车的场景，每一条都按现象、原因、解决拆开说。

5.1 现象一：启用 ESA 后，延迟不降反升

现象：全 NVMe 节点，启用 ESA 后 4K 随机读写延迟反而比旧集群高，IO 监控显示存储延迟经常超过 10 毫秒。

原因：节点里混用了 SATA SSD 和 NVMe。ESA 要求全 NVMe，SATA 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 list

esxcli vsan health cluster list是核心命令，输出每个健康检查项的状态，包括绿色、黄色、红色。升级 ESXi 或换硬件后，我都会在这里跑一次，确认没有黄色项。--health-type perf能看延迟和拥塞情况，数据库业务变更前必跑。

变更后验证的习惯是：

1. 变更前跑一次 health cluster list，把结果存成文本。
2. 变更后重复一次，对比黄色和红色项。
3. 有问题再用 cluster get 和 storage list 定位具体节点。

有一次我就是靠着这个习惯，在一台主机驱动升级后立刻发现了 vSAN 健康检查的红色告警，回滚命令执行得干净利落。从那以后，每次动 ESXi 驱动、固件或存储控制器之前，我都强制走一遍这套命令行检查流程，不依赖 vCenter 界面，也不信“顺手升一下应该没事”。希望帮到你，拿到这份 PDF 之后，建议先翻架构和健康检查那两章再动手，后面能少踩很多坑。

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