企业官网建设流程全解析

简介：VMware vSAN 8.pdf 是一份深入解析 VMware vSAN 8.0 U1 Express Storage Architecture 的详细完整英文技术文档，面向虚拟化管理员、存储工程师和超融合架构学习者。文档系统讲解软件定义存储的部署与运维方法，内容覆盖硬件兼容性、VMkernel 网络配置、NIC Teaming、分布式交换机与网络 I/O 控制，以及 vSphere HA、VMCP、分布式 RAID、对象与组件机制等关键知识点。特别是 vSAN ESA 的存储池、数据路径与 On-Disk Format 说明，能帮助对比理解新架构与传统 OSA 读写流程的差异，同时涵盖压缩加密、iSCSI、vSAN HCI Mesh 等扩展功能。资源目录与官方架构说明一致，便于按章节快速定位硬件选型、网络规划、HA 隔离响应、数据缓存与校验等实施细节，亦可作为部署排障手册。资源共 1 个 PDF 文件，约 23.69MB，目录结构清晰便于高效检索；目前已有 155 人学习，适合正在规划、部署或维护 vSAN 集群的读者作为技术参考。

1. VMware vSAN 8 的 PDF 在讲什么：从磁盘组到存储池的跳变

刚拿到 VMware-vSAN-8.pdf 时，我以为又是一份换壳的 vSAN 7 文档，翻到一半才发现，vSAN 8 把过去十年围绕磁盘组的存储逻辑整个推翻了一层。最大的变化是引入了 ESA（Express Storage Architecture）：不再需要单独挑一块小容量 SSD 做缓存盘，所有 NVMe 设备汇成一个存储池，性能和运维都变得简单直接。这份 PDF 适合虚拟化管理员、存储工程师，以及任何准备在 vSphere 8 上把 vSAN 从 7 升级到 8 的人。尤其是那些和我一样，习惯用旧思维规划新架构的人，最该先看。

2. 规划 vSAN 8 集群：兼容性检查与容量估算，动手前先看这两张表

规划决定成败。vSAN 8 的安装向导虽然友好，但如果你在兼容性或容量上偷懒，后面健康检查会直接翻车。我见过不少人把 vSAN 8 当 vSAN 7 来规划，结果 ESA 存储池一直无法声明。这一章先把最容易出问题的两个前置项说清楚：硬件兼容性和容量估算。网络和许可证也会顺带提一句，因为这两者决定了你选 OSA 还是 ESA。

2.1 硬件兼容性：ESA 为什么不允许混插 SATA SSD

vSAN 8 同时提供两种架构。OSA（Original Storage Architecture）就是传统 vSAN 7 的磁盘组模式：每台主机需要一个缓存层设备（通常是小容量 NVMe 或 SAS SSD）加至少一个容量层设备（大容量 SSD 或 HDD）。ESA（Express Storage Architecture）是 vSAN 8 真正的新东西：磁盘组被彻底拿掉，主机上所有经过认证的 NVMe 设备放进同一个存储池，由 vSAN 统一做对象级管理，不再需要独立缓存盘。

ESA 对硬件要求非常苛刻：所有存储设备必须出现在 VMware 官方的 vSAN 兼容性指南（HCL）里，驱动和固件版本也必须匹配。为什么这么苛刻？因为 ESA 没有缓存层兜底，数据路径上任何一块盘的异常都会直接表现为存储池不可用。所以如果你的机器上还插着一块 SATA SSD，ESA 不会绕过它，而是把整台主机的存储标为“未声明”。这不是 bug，是 ESA 的边界。

动手前按这三步检查：先登录 VMware 兼容性指南站点，输入服务器型号，确认系统支持 vSAN 8 ESA；再在 Storage 类型里筛选 NVMe，确认每块盘的型号、固件在列表里；最后检查直通模式——如果 RAID 控制器没有切换为直通（IT 模式），ESA 会认为这些盘没有能力，同样声明失败。别信厂商的宣传页，HCL 上没有就是没有，老老实实走 OSA。

2.2 网络与许可证：25GbE 和 RoCE 是 ESA 的分水岭

vSAN 8 ESA 的数据路径对网络依赖更重。OSA 在万兆网络下能好好跑，但 ESA 会把多台主机的 IO 聚在一起，千兆网络会直接成为瓶颈，延迟翻倍都正常。VMware 官方建议 ESA 至少使用 25GbE，这不算夸张，只是很多小环境只有万兆，也照样能跑，关键是端到端 MTU 必须一致。

RoCEv2 在 vSAN 8 里是可选项，用来做 RDMA，能显著降低数据搬运时的 CPU 开销，但交换机需要支持 PFC 和 ECN，配置错了表现很诡异，比如网络健康检查时好时坏。我的建议是：中小环境先把 vSAN 流量划到独立 VLAN，启用 Jumbo Frame（MTU 9000），观察延迟指标；如果 CPU 出现瓶颈，再考虑上 RoCE。

许可证这一块，vSAN Standard、Advanced、 Enterprise 对 RAID-5/6、去重压缩、vSAN Max 等高级功能的支持不同。具体能力矩阵以官方对比页为准，不要用 vSAN 7 的记忆去推测 vSAN 8。常见做法是：先把集群功能开起来，再在 Licensing 页面对比允许的特性集，避免后期因为少一个企业版导致功能无法启用。

2.3 容量估算：按 FTT 和故障域反推裸容量

容量估算是翻车重灾区。很多人直接在管理界面看到“可用容量”一个数，就以为那是最终容量，结果加了几个虚拟机就黄色警告。vSAN 8 的容量必须按存储策略反推。

上面只是基础公式，还要考虑两件事。第一，故障域预留：如果配置了故障域，vSAN 需要为每个故障域保留一份数据，容量会被进一步吃掉。第二，重建缓冲：至少预留 20% 裸容量，否则主机故障时重同步会撑满磁盘。去重压缩能省多少？备份、桌面、文件服务器这类冗余数据通常能省 30% 到 50%，但数据库 OLTP 往往省不了多少。做容量规划时，先按最保守的不压缩场景算，再把去重压缩当成惊喜，而不是把惊喜当预算。

3. 在 vSphere 8 上启用 vSAN 8：从建集群到存储策略的完整步骤

规划做完，下一步就是建集群。vSAN 8 的 UI 向导比 vSAN 7 友好，但有几个开关和边界条件不搞清楚，后面会走回头路。这一章按“建集群 → 声明存储 → 配策略”三步走，每一步都给出关键参数和判断依据。

3.1 创建集群并启用 vSAN：三个关键开关

在 vSphere Client 里，新建数据中心下的集群时，勾选“vSAN”并选择“已启用”，后续向导会引导你完成步骤。这里有三个开关，我会逐个确认。

第一个开关，集群功能里的 vSAN 服务必须打开，否则后面主机加进来也不会自动加入 vSAN 数据面。第二个开关，网络配置里要指定用于 vSAN 流量的 VMkernel 适配器。不要偷懒选“自动”，尤其在多网卡环境下，手动指定哪块物理网卡走 vSAN 更可控。第三个开关，添加主机时，向导会做一次 HCL 检查和磁盘格式检查，注意不要跳过这一步。

实际操作顺序：新建集群 → 功能勾选 vSAN → 添加主机 → 等待磁盘亮起 → 检查 vSAN 健康。全部主机加完后，如果硬件满足 ESA 条件，集群设置里会看到“vSAN ESA 已启用”的选项；如果不满足，就只能用 OSA。这里常见做法是让向导自动检测，而不是手动强行开启 ESA，否则后续健康检查会报错。

3.2 声明存储并创建存储池：OSA 磁盘组 vs ESA 存储池

先看 OSA。在主机“配置 > 存储 > vSAN”里，进入磁盘管理，选择一块小容量但写密集的 NVMe 作为缓存盘，再选 1 到 7 块大容量盘作为容量盘，形成磁盘组。这个拓扑和 vSAN 7 一模一样。

再看 ESA。不需要建磁盘组，vSAN 会自动发现主机上所有可用的 NVMe 设备，你要做的只有一件事：确认这些设备没有被文件系统或虚拟机占用。最常见的问题是旧 vSAN 分区没有擦干净，导到设备显示“已使用”。可以用esxcli storage core device list查看设备分区信息，也可以在界面中直接选择“擦除磁盘”，把明文清空后再声明。

创建 ESA 存储池时，界面会列出候选磁盘，让你勾选哪些设备加入。这里注意：同池里的设备容量差异不要太大，比如一块 1TB、一块 7TB，容量利用率会按最小容量算，白白浪费空间。可以的话，优先选购同容量同型号的 NVMe 盘，容量规划最简单，健康检查也最干净。

3.3 存储策略怎么设：FTT、RAID-5/6 和条带化

存储策略是 vSAN 的灵魂，vSAN 8 的界面把它从“高级参数”提到了“规则集”的第一层。最核心的参数是 FTT（允许故障数）和故障容忍方法。

创建策略的步骤：在“VM 存储策略”中新建策略，选择 vSAN 规则集，设置 FTT 和故障容忍方法，系统会自动检查集群最小主机数并给出警告。然后把策略应用到虚拟机的虚拟磁盘上。注意，策略应用是异步的，切换后虚拟机会显示“数据不完整”或“重新保护中”，等数据重新条带化完成才算真正好。很多人看到这个状态就以为策略配坏了，其实是在做后台重同步。

对大多数生产虚拟机，FTT=1 + RAID-1 是一个稳的起步配置；如果主机数够 4 台且对容量敏感，RAID-5 (3+1) 空间效率高一些，但故障重建时间会偏长。IO 压力大的虚拟机，条带化建议设 2，但不要为了堆性能而设 4，带宽和 CPU 会先顶不住。

4. 让 vSAN 8 跑出性能：必调参数和阈值

vSAN 8 的默认值大多数是对的，但默认值不会照顾特殊负载。这一章讲三个最值得动手的点：去重压缩的开关、故障域设计、监控阈值。这三个点决定了你的集群是“能跑”还是“跑得好”。

4.1 去重压缩与校验：默认开还是关

vSAN 8 ESA 的去重压缩是存储池层面的能力，默认开启，开销比 vSAN 7 低很多。OSA 的去重压缩则以策略形式存在，由管理员决定是否启用。这里的分水岭是数据类型。

对 OLTP、数据库、高频交易这类随机读写为主的工作负载，数据本身几乎没有重复，去重压缩只会白白消耗 CPU，我的做法是直接关闭。对备份、文件共享、虚拟桌面这类有大量重复块的工作负载，去重压缩能省不少容量，而且 ESA 的实现把性能损耗压得很低，开着收益更大。校验和则相反，无论什么负载都建议开启，vSAN 8 里的校验和默认开启，性能影响可以忽略。有人为了省一点点开销把它关掉，一旦遇到静默数据损坏，后悔药都买不到。

4.2 故障域与拓扑：把数据本地性做出来

vSAN 8 默认把每台主机当作一个故障域，也就是说数据副本分布在不同的主机，能容忍单主机故障。但如果你的是一个多机柜集群，比如三个 TOR 交换机下面各挂了 8 台主机，你要主动配置跨机柜故障域，否则 vSAN 可能把两个副本放在同一个机柜里，这样交换机故障就会同时干掉两个副本。

配置故障域不算难：在集群的“配置 > vSAN > 故障域”里，添加故障域，把同一机柜的主机拖进去，vSAN 会自动把数据分布到不同故障域。关键参数是故障域数量，不要少于 FTT+1。比如 FTT=2 需要至少 3 个故障域。如果你只有两个机柜，又想容忍整个机柜故障，那只能选 FTT=2 并接受容量损失。没有捷径可走，这是数据安全换来的代价。

4.3 监控阈值：延迟、队列深度、组件状态

vSAN 性能服务会实时收集 IOPS、延迟和吞吐量，但默认的红色阈值属于保守值，直接看可能会误判。我一般按这套经验值来设：读延迟超过 5ms 要警惕，写延迟超过 2ms 就要查网络；NVMe 队列深度超过 32 说明饱和，这时候加 CPU 比加盘更有效。健康检查里有一个“网络 P50/P99 延迟”的指标，红色阈值通常是 5ms，但这个阈值对跨机柜集群来说太激进，后面章节会详细讲。

还有组件状态。vSAN 对象组件列表里会出现“运行中”“重新同步”“降级”等状态。降级多数是策略切换引起的，别慌；如果长时间停在“重新同步”且集群容量不足，就要赶紧扩容，否则重同步会把存储池撑爆。

5. vSAN 8 常见翻车避坑：我踩过的 4 个真实案例

这一章没有理论，只有现象、原因和解决办法。每个案例都是我在实际环境里亲手踩过的，列出“现象 → 原因 → 解决”三段，方便你直接对照。

5.1 现象：启用 ESA 后主机一直显示“存储未声明”

现象：新部署的 vSAN 8 集群，主机加入后，vSAN 存储界面里所有磁盘都是灰色，提示“未声明”，无法创建存储池。查看健康检查，发现 ESA 兼容性标红。

原因：这台服务器的本地磁盘列表里混了一块 SATA SSD 和两块 NVMe。ESA 的规则是“全盘参与”，不是“挑着参与”，只要存在不满足 ESA 条件的设备，整台主机的存储都会被拒绝。另一个常见原因是旧 vSAN 分区没有擦除干净，vSAN 会把有遗留分区的盘视为非空设备，也不同意声明。

解决：先把 SATA SSD 拔出或绕开，只保留 NVMe 设备；然后在 vSphere Client 里把每块 NVMe 的磁盘格式擦除，再回到 vSAN 配置里重新声明。这里还有一个隐藏坑：如果是软 RAID 控制器，必须切成直通模式，否则 vSAN 看不到真实的 NVMe 设备。操作后再刷新存储池列表，存储未声明状态就会消失。

5.2 现象：RAID-5/6 策略卡在“数据不完整”，重建疯狂占带宽

现象：给 VM 应用了 RAID-5 策略后，虚拟机一直处于“数据不完整”，后台重新同步持续几个小时，集群网络被占满，其他 VM 的延迟肉眼可见地变高。

原因：主机数不足或故障域不够。RAID-5 (3+1) 最少要 4 台主机，RAID-6 (4+2) 最少要 6 台主机，这里的“台”是 vSAN 实际参与数据放置的主机数。如果只有 3 台主机就强行应用 RAID-5，策略永远不可能完成，vSAN 会反复尝试重建，占满带宽。另一个原因是配置了故障域，但故障域数量少于策略要求，数据块找不到足够多的物理位置去放置。

解决：先确认集群里可用的 vSAN 主机数，不足就补主机或把策略降回 RAID-1。如果主机数足够，再检查故障域配置，确保每个故障域里主机数对称。重建带宽可以用 vSAN 健康检查里的重同步速率限制功能，临时把重同步占用调低，把核心业务的 IO 让出来。

5.3 现象：iSCSI 走 vSAN 8 高性能路径后，IOPS 反而掉了一半

现象：有一组数据库通过 iSCSI 挂载到 vSAN 8 数据存储上，所有路径都显示正常，但 IOPS 只有测试前的五成，延迟也没有明显下降。

原因：iSCSI 走的是 ESXi 软件适配器，默认只有一条路径在工作，没有启用多路径。vSAN 8 数据存储本身速度很快，但 iSCSI 发起端和目标是两个世界，中间的网络路径如果不做多路径负载均衡，流量全挤在一个 vmkn 上，IOPS 自然上不去。还有一个原因是 MTU 不一致：vSAN 网络开了 9000，iSCSI 网络的 VMkernel 还是 1500，帧被分段重装，CPU 开销反而更高。

解决：在 iSCSI 软件适配器里启用多路径，配置端口绑定，把两个或四个 VMkernel 网络端口都绑给 iSCSI，路径策略选 Round Robin。同步把 MTU 9000 配到 iSCSI 的 VMkernel 和交换机端口上。改完再测，IOPS 回到正常水平。

5.4 现象：vSAN 健康检查报“网络延迟高于红色阈值”但业务不卡

现象：健康检查页面一直报网络延迟红色，但所有虚拟机跑得很稳，业务端完全没有感知。打开指标后发现 P99 延迟是 8ms，而健康检查默认红色阈值只有 5ms。

原因：这个集群的 vSAN 流量跨了三个机柜，每个机柜之间是三层网络，物理链路本身的转发延迟就是 3ms 左右，加上排队和内部处理，P99 到 8ms 是正常物理数据，不是拥塞。健康检查的默认阈值是面向单机柜内网络的，对跨机柜拓扑缺乏适应性。

解决：先确认网络延迟的构成，逐跳 ping 找最慢的链路，排除交换机 PFC 配置错误或环路，确认是物理延迟后再做决策。如果只是阈值问题，可以在 vSAN 健康检查设置的“网络延迟”参数里调整阈值到 10ms，但不要盲目改大，否则会掩盖真实性能问题。我一般会同时在交换机上配置 QoS，优先保证 vSAN 流量不被其他业务抢占。

6. 用 esxcli 与 PowerCLI 给 vSAN 8 做体检：一个终端命令验证全链路

前面五章都在讲配置，这一章讲验收。配置完成后，你最需要的是一个能快速、可重复地验证集群健康的方法。我的习惯是把 esxcli 和 PowerCLI 两个命令固定成自己的“体检套餐”，每个季度跑一次，顺便和 PDF 里的推荐值对比。

6.1 一行命令确认 ESA 存储池的健康状态

在任意 ESXi 主机的 SSH 终端里执行：

esxcli vsan health cluster list

这条命令会返回整个 vSAN 集群的健康检查聚合结果。重点关注Overall Health Status字段，值为green说明健康检查组跑完没有红色告警；如果有yellow或red，继续用下面的命令缩小范围：

esxcli vsan health cluster list -s

逻辑说明：health cluster list走的是 vCenter 里同一套健康检查逻辑，区别在于它不经过 UI，直接查询 vSAN 的 CMMDS 数据。-s参数会输出每个子检查项的详细状态，比如网络延迟、磁盘格式、副本数，适合快速定位哪一项红了。命令行输出里，green对应 UI 的绿色，yellow表示需要关注但不影响服务，red表示必须处理。

再来看存储池：

esxcli vsan storage pool list

输出里重点看UsedBy字段，正常情况下应该显示vsan，如果还出现其他占用者，说明磁盘没完全交出来。Total Capacity和Free Capacity要对照着看，当Free Capacity低于总容量的 20% 时，我建议提前加盘或清理快照，不要等到黄色警告才动手。

6.2 用 PowerCLI 导出健康检查报告

如果你更习惯 vCenter 侧的自动化，PowerCLI 有一个更直接的命令：

Get-VsanCluster -Name "VSAN-CLUSTER" | Get-VsanClusterHealthStatus

执行前需要先连接 vCenter：Connect-VIServer vcenter.example.com。这个命令返回一个健康检查对象，里面包含了集群所有检查项的结果。常见的做法是把结果导成 CSV 或 HTML 留档，下次跑完后对比差异，看有没有新增的 red 项。我的个人习惯是把这份健康检查报告和 vSAN 8 的升级前检查绑定在一起，每次打补丁前先跑一遍，确认基线干净再操作。

命令行体检不会替你做容量判断，但它能帮你把“一切正常”这句话变成可查证的证据。我踩过不少在 UI 上看着绿色、实际命令行报错的案例，所以现在对新集群、新版本、新升级的验收，一律以输出为准。希望这些细节能让你少走一段弯路，也希望你拿到 VMware-vSAN-8.pdf 后，能带着这份经验快速抓住重点，把新架构真正用起来。

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