企业官网建设流程全解析

简介：这是一份专为VMware vSAN 8.0认证考试（5V0-22.23）整理的备考资料，主要面向需要考取VCP-DCV或vSAN专项认证的虚拟化架构师、运维工程师，以及对软件定义存储技术感兴趣的IT从业人员。资源以单个PDF文档形式打包，共1份文件，压缩包大小约296KB，排版清晰，方便离线下载与快速查阅。资源内容包含多道典型原题及详细答案解析，覆盖vSAN 8.0的磁盘布局设计（OSA与ESA存储池的选择）、同步延迟性能指标查看、RAID-5/FTT容错策略调整、vSphere Lifecycle Manager离线升级、非互联网环境软件仓库设置、节点故障后vSphere HA的虚拟机组恢复行为、vSAN ESA三节点全闪存集群最大化可用容量设计等关键主题，并对站点容灾、性能服务开启、关机集群流程等常见操作场景进行了补充。已有72人学习浏览，适合考前查漏补缺，也能帮助运维人员在实践中快速定位vSAN 8.0常见的配置问题与排错方向。整体内容精炼，适合时间有限的备考者。

1. vSAN 备考不是刷题：5V0-22.23 样题背后的设计取舍

我是从 vSAN 6.5 的磁盘组时代一路维护到 8.0 的，见过太多只背“最多 5 个磁盘组”就去考试的同行。说实话，5V0-22.23 这套题比老题库有意思——它不直接问“最大支持多少”，而是把 ESA、FTT、故障域、HCI Mesh 揉进具体运维场景里，考你的判断。比如 8 块 NVMe 的 ReadyNode 你会怎么配？三节点边缘集群想跑低延迟应用，容量和冗余怎么平衡？性能服务没开，集群摘要页空空如也你知道去哪查吗？这篇文章把样题按设计逻辑拆开：先讲架构选型，再算容量账，然后进运维排障，最后落到验证命令。备考的人能理清思路，搞生产运维的也能直接照着参考。

2. vSAN 8.0 架构选型：OSA 与 ESA 的存储池逻辑

2.1 8 块 NVMe 的布局：磁盘组还是存储池

第一道样题的场景很典型：一个组织要建新的 vSAN 8.0 集群，目的是利用改进的 I/O 流、更好的弹性和更有效的磁盘使用。集群的 ReadyNode 由 8 个 NVMe 磁盘组成，问怎么配置磁盘布局。A 选型是传统玩法：vSAN OSA，建两个磁盘组，每个磁盘组一个缓存盘加三个容量盘。B 是 8.0 的推荐玩法：vSAN ESA 搭配新的存储池，所有磁盘都贡献容量。

为什么 B 对？因为 ESA 里已经没有“缓存盘”这个概念了。磁盘组时代，NVMe 或 SSD 要被拆成写缓冲和读缓存两部分，真正留给容量的空间要打折扣。而 ESA 的存储池把全部磁盘统一池化，写缓冲内置在 vSAN 层，通过专用 PCIe 通道直连，不再和容量盘互相挤占。题干里那句“改进的 I/O 流、更好的弹性和更有效的磁盘使用”，就是在提示你往 ESA 上想。

D 选项是个典型陷阱：vSAN ESA 下根本没有“缓存盘 + 容量盘”的磁盘组结构。如果选了 D，说明你还在用 6.x 的架构思维做 8.0 的题。我一般看到全 NVMe 的 ReadyNode 并且强调“更有效的磁盘使用”，就直接判断是 ESA 存储池。放到生产环境里也一样：新采购的全闪节点，只要硬件兼容列表里支持 ESA，就没必要再手工划分缓存盘和容量盘。

2.2 边缘三节点：ESA 与 RAID-5 为什么是容量最优解

第八道样题是个很实际的项目场景：客户有一批新应用，要求高性能特别是低延迟，部署在边缘位置，每个位置只有三个主机插槽，还要最大化每个部署的可用容量。四个选项都是三节点 vSAN 8.0 全闪集群，差别在 OSA 还是 ESA，以及存储策略选 RAID-1 还是 RAID-5。

正确答案是 D：三节点 ESA 集群，每个应用虚拟机配置 RAID-5 存储策略。这道题值得仔细拆，因为它同时考了架构选择和容量计算。

先看容量账。三节点集群跑 RAID-1（FTT=1），1GB 数据要写成 2 份，实际占用 2GB。三节点跑 RAID-5（FTT=1），数据切成 2 份加 1 份校验，1GB 数据实际占用约 1.33GB。RAID-5 在 3 节点上能省下约三分之一容量，正好命中“最大化每个部署的可用容量”。再看性能：ESA 的日志结构文件系统会把随机小 I/O 整理成顺序写，对低延迟场景更友好，OSA 在写路径上要经过缓存盘转发，延迟天花板低一截。

这里有个容易忽略的点：题目问的是“最大化每次部署的可用容量”，不是“最大化性能”。如果单看性能，C 的 ESA + RAID-1 也很能打，但它要吃掉双倍容量；A 的 OSA + RAID-5 容量账没问题，但 OSA 的性能上限满足不了“低延迟”这个硬指标。D 是唯一同时满足容量和性能的选项。

还有个小细节值得记：vSAN ESA 集群里 RAID-5 / FTT=1 的最小主机数正好是 3。数据块分布在 2 个主机，校验块在第 3 个主机，三台就是底线。这也解释了为什么边缘位置三主机插槽能成立——再多一台当然更稳，但架构上 3 已经是合法最小规模。

2.3 OSA 和 ESA 的适用边界：不是所有环境都要换

把两道题放在一起看，容易产生一种误解：vSAN 8.0 就该无脑用 ESA。实际不是这样。OSA 仍然有存在价值：如果你的环境是混合盘（HDD + SSD），或者现有硬件不在 ESA 兼容列表里，又或者你不想动 on-disk format，那 OSA 就是唯一选择。

ESA 的硬性要求包括全闪配置、推荐 NVMe 或高性能 SSD、on-disk format 需要升级到 3.0。升级磁盘格式是单向操作，老集群想要切到 ESA，必须做完整的迁移评估。实践里我见过不少团队卡在这：硬件明明支持 ESA，但 vSAN 集群里还挂着老版本的 on-disk format，升级窗口又排不上，只能继续跑 OSA。

所以选型判断实际是这样：新集群、全闪、硬件支持——优先 ESA；已有集群、混合盘、升级窗口紧张——继续 OSA 不丢人。考试题里那个 8 NVMe 的 ReadyNode 是理想化场景，真实环境里的约束条件比这个复杂得多。

3. 存储策略：FTT、RAID 级别与容量消耗换算

3.1 RAID-5 最小组网：为什么是 3 台主机而不是 4

第三道样题问的是：需要搭建 RAID-5 / FTT=1 自适应存储策略的 vSAN ESA 集群，主机的绝对最小数量是多少？答案 D：3。不少人在 3 和 4 之间犹豫，理由是多一台主机更保险。但题目问的是“绝对最小数量”，不是“推荐数量”。

RAID-5 在 vSAN 里的数据布局是这样的：一个对象被切成数据块和校验块，FTT=1 意味着可以容忍一个主机或一块盘故障。数据块需要落在两个不同主机上，校验块放在第三个主机，三个主机正好构成 2+1 的条带。四台主机当然可以，但三台已经是理论下限。这条规律可以顺势记一下：RAID-1 FTT=1 最小 2 台，RAID-5 FTT=1 最小 3 台，RAID-6 FTT=2 最小 4 台。

实践里这个数字影响硬件采购。很多边缘或分支机构的部署就卡着 3 台买，之后想扩容节点，先要回头确认存储策略能不能放。我建集群的习惯是先定存储策略再定主机数，顺序反了后面很被动。

3.2 减少容量消耗：降副本还是换纠删码

第四道样题的场景：混合 vSAN 数据存储上所有虚拟机都分配了 FTT=2、RAID-1（镜像）策略，管理员要减少虚拟机消耗的容量，问怎么做。四个选项里只有一个真正减少了数据副本：

• A 改成“2 故障 - RAID-5（纠删码）”：听起来纠删码省空间，但 FTT 保持在 2，RAID-5 需要 2 份数据加 1 份校验，总开销和 RAID-1 FTT=2 的三副本差不多，省不了多少；而且混合架构上跑纠删码，重建时的校验计算会给磁盘和 CPU 增加不小压力。
• B 把 Flash 读缓存预留设为 0%：这改的是缓存预留策略，不改变容量副本，属于干扰项。
• C 关闭操作预留和主机重建预留：同样是容量预留策略，不动数据副本。
• D 把 FTT 改成“1 故障 - RAID-1（镜像）”，并在“重新应用到虚拟机”里选“现在”：这是唯一把副本数从 3 降到 2 的操作，容量减少立竿见影。

答案 D 背后是一个容易忽略的判断：减少容量消耗最稳妥的方式就是降副本。在混合 vSAN 上，与其换纠删码，不如先降 FTT。混合盘的随机写性能本来就有限，纠删码引入的额外计算和重建流量，可能会让性能问题盖过容量收益。

“重新应用到虚拟机”里的“现在”选项也值得记住。vSAN 策略变更可以选立即应用或维护窗口应用，生产环境里如果需要立刻释放容量，就必须用“现在”强制执行，否则策略变更会等默认的重新应用周期。

3.3 策略变更不是瞬时的：vSAN 会依次应用

第十道样题：六节点 vSAN ESA 集群，虚拟机策略从“1 故障 - RAID-5（纠删码）”改成“2 故障 - RAID-6（纠删码）”，问结果是什么。答案 D：更新后的策略依次应用于虚拟机。

这道题考的是策略变更的落地机制。vSAN 不会像切换开关一样瞬间把策略应用到所有对象，而是把每个虚拟机的对象重新配置任务放到队列里，逐台处理。你会看到 vCenter 任务列表里出现一串“重新应用存储策略”的任务，每台虚拟机根据对象大小和组件数量，耗时不同。

实际运维里这个行为的坑在于：大范围策略变更期间，临时写放大可能推高容量水位。比如一批虚拟机从 RAID-5 改成 RAID-6，重建校验块的过程中会产生额外 IO 和临时空间占用。我一般会在变更前检查集群容量、确认对象健康，再分批应用，而不是一次性全选。

3.4 主机永久故障与 vSphere HA：谁先响应

第五道样题是个很好的综合场景：五节点 vSAN 集群，配置了 HA 和 DRS，托管 150 台虚拟机，容量用了 60%。虚拟机分两组策略，其中 vSANPolicy1 是站点容灾无、FTT=1、RAID-5（纠删码）。数据中心意外断电后，一台主机永久故障，问对使用 vSANPolicy1 的虚拟机有什么影响。答案 A：每个虚拟机将通过 vSphere HA 在另一个 vSAN 主机上重启。

很多人会被“永久性故障”带偏，以为要等 vSAN 重新同步完成才能恢复，于是选了 C 或 B。实际机制是：vSphere HA 检测到主机失联后，会立即在集群内可用主机上重启虚拟机；vSAN 同时在后台重建故障主机上的数据副本。两个动作并行，虚拟机恢复时间由 HA 主导，不需要等对象同步完成。

这个并行机制在真实故障演练里很容易观察：主机断电，虚拟机在另一台主机上拉起，vSAN 任务栏里同时出现重新同步任务。理解了这条，就不会在故障时干等“数据同步完成”再手动开机。

4. 运维避坑：性能服务、升级顺序与关机流程

4.1 集群摘要页没有性能数据：先查性能服务开关

现象：vSAN 集群摘要页面找不到任何性能统计数据，图表区域一片空白。

原因：vSAN 性能服务默认是关闭的。管理员刚建好集群，最容易忽略这个开关，第一反应是权限不够、vRealize Operations 没集成，甚至以为是 CLI 才能看统计。

解决：在 vCenter 里进入 vSAN 集群，找到“配置” > “vSAN” > “服务”，把性能服务启用。开启后不需要重启任何组件，等几分钟就能看到 IO 延迟、吞吐等指标。命令行也可以验证：

# 查看 vSAN 性能服务状态，enabled 字段是 true 表示已开启 esxcli vsan performance get

如果输出显示 disabled，先到 vCenter 开启，再回来确认。性能服务会占用少量内存和 CPU 资源，规模小的集群影响不大，大规模集群建议在开启前估算一下 overhead。

4.2 Resync 指标藏在 Backend 类别

现象：集群中重新同步的对象耗时比预期长，管理员想查重新同步指标，但在性能类别里找不到 Resync Latency。

原因：vSAN 性能服务把指标分成几个类别，重新同步属于后台任务类，不在 Disks 或 Host Network 里。很多人在 Disks 里翻半天，以为磁盘延迟能反映重新同步状态，方向就偏了。

解决：打开 vSAN 性能服务后，进入“监控” > “vSAN” > “性能”，选 Backend 类别，里面可以看到重新同步的剩余字节、数据吞吐和延迟。实际操作中我会单独过滤出 Resync 相关指标，做成一个固定视图，主机故障恢复时实时观察重建进度。

4.3 非联网环境：vLCM 仓库只能走本地 umds

现象：隔离网络里的 vSAN 7.0 U3 集群要升级到 8.0，vSphere Lifecycle Manager 提示无法获取补丁和元数据。

原因：vLCM 默认从 VMware Online Depot 拉取升级包，非互联网环境访问不了外网。选了 D“不可能使用 vLCM”的人是不知道正确解法；选 A、B 的人没意识到在线仓库在这个场景下根本不通。

解决：搭建一个 Update Manager Download Service（UMDS）实例，在有网络的机器上把 vSAN 8.0 的补丁和元数据同步下来，然后把 UMDS 的共享目录通过 HTTPS 配置为 vLCM 的本地仓库。vCenter 的 depot 设置里填入本地 umds 共享地址，vLCM 就能离线完成 base image 和补丁检查。注意共享目录的权限和 HTTPS 证书要提前配好，这是离线仓库最常见的两个坑。

4.4 升级顺序：先 vCenter 再 vSphere 再 on-disk format

现象：管理员用 vLCM 升级 vSAN，跳过了某些步骤，升级到一半发现 vSAN on-disk format 升级选项不可用。

原因：vSAN 从 7.0.2 到 8.0 的正确升级顺序是 vCenter -> vSphere -> vSAN on-disk format。vCenter 必须先升级，否则它不认识新版本的 ESXi 和 vSAN 能力；vSphere 升级其次；最后再进行 on-disk format 升级。颠倒顺序或跳步，vCenter 和 ESXi 的版本不匹配会导致 on-disk format 选项不出现。

解决：严格按官方顺序执行。先升级 vCenter Server Appliance，再通过 vLCM 或手动方式把集群内 ESXi 升级到 8.0，全部主机完成后再在 vSAN 集群处发起 on-disk format 升级。on-disk format 升级是单向的，开始前确认所有对象健康，否则格式转换会卡在降级对象上。

4.5 关闭集群向导前：先关 HA

现象：计划停电，按关机集群向导操作，健康检查正常，虚拟机关闭了，vCLS 虚拟机也关了，但直接启动向导时提示异常或主机反复上电。

原因：vSAN 会把主机关闭事件登记为故障。如果 HA 没关，vSphere HA 检测到主机失联，会在其他主机上尝试重启虚拟机，造成断电期间 VM 反复上电的混乱局面。

解决：进入 vSAN 集群的“配置” > “服务”，先把 High Availability 关闭，再启动关机集群向导。注意如果 vCenter 本身托管在这个 vSAN 集群上，关机顺序另有讲究——vCenter 虚拟机要留在最后关，否则控制平面提前消失，后续操作全部不可用。顺带提一句，vCLS 虚拟机由 vSphere 自动管理，手动关闭后启动向导可能会报错，按官方文档顺序处理即可。

4.6 Operations Reserve 和主机重建预留不是一回事

现象：使用 vSAN ReadyNode Sizer 规划新环境时，同事问 Operations Reserve 选项是干什么的，很多人答不上来。

原因：Operations Reserve（操作预留）和 Host Rebuild Reserve（主机重建预留）是两个不同概念。前者为 vSAN 内部操作预留空间，包括日志、快照、元数据更新、组件重分布等后台内务活动；后者是主机故障后重建数据副本时需要的临时空间。

解决：在 Sizer 里，Operations Reserve 建议预留 10% 到 20% 的容量，具体比例取决于集群规模和工作负载写入特性。不要把它和主机重建预留混在一起，两个都会吃真实容量，设计时必须同时考虑。生产环境的容量告警，很大一部分就是初始规划时把这类预留留小了。

4.7 降级磁盘更换的最小风险路径

现象：存储池集群迁移到新数据中心，健康检查发现某台 ESXi 主机有两块降级的存储设备，需要更换，直接拔盘可能会影响对象可用性。

原因：存储池模式下，磁盘故障会触发组件重新条带化。如果一次拔掉两块盘，可能同时影响同一个对象的数据块和校验块，导致对象降级甚至不可用。

解决：先看 vSAN 健康检查里的“物理磁盘”状态，确认降级盘是否承担了关键组件。如果 FTT 足够，可以逐台处理：先让主机进入维护模式（选择“确保数据可用”），vSAN 会把组件迁到其他主机，然后再物理更换磁盘。换完退出维护模式，确认重新同步完成后，再处理另一台。不要同时下电两台设备，这是存储池模式下最容易翻车的操作。

5. 高可用扩展与验证：故障域、HCI Mesh 与三机架底线

5.1 机架故障容错：最少三机架三故障域

第十六道样题：24 台物理服务器要配置 vSAN，要求单个机架故障不影响数据可用性，同时尽量减少机架数量。答案 D：把服务器分布在至少三个机架上，并配置三个故障域。

为什么两个机架不够？vSAN 故障域的设计逻辑是：把机架抽象成故障域，数据副本必须跨故障域放置。FTT=1 时，数据块和副本落在两个不同故障域，理论上两个机架就能满足。但两个机架的问题是：一旦某个机架整体断电或网络中断，故障域内没有第三个可用故障域来承担重建任务，所有虚拟机都挤到剩下的机架上，可用性和性能双双告急。三个故障域才是机架级容错的可靠下限。

实践里机架分布不只是数量问题，还要考虑每个机架上的主机数量。24 台服务器平均分到三个机架，每个机架 8 台，故障域划分就非常清晰。如果机架数量和主机数量不均衡，vSAN 的数据分布会偏向容量大的故障域，反而影响冗余均衡。

5.2 HCI Mesh：跨集群借存储

第十五道样题：应用虚拟机跑在专用 vSAN 集群上，自定义 CPU 和内存，不能 vMotion 到其他集群，但需要从另一个 vSAN 集群分配额外存储。该用哪个 vSAN 特性？答案 B：vSAN HCI Mesh。

HCI Mesh 是 vSAN 的跨集群存储共享功能，允许一个 vSAN 集群把容量以数据存储形式挂载给另一个 vSAN 集群。它的价值在于：不用迁移虚拟机、不用改集群配置、不用买新存储，就能把一个集群的空闲容量借给另一个集群使用。题目里的约束“不能 vMotion”正好让 HCI Mesh 成为唯一可行解——数据存储可以远程挂载，虚拟机计算位置不变。

其他选项的排除逻辑：A 文件服务是给客户端提供 NFS/SMB 共享，不走 vSAN 对象路径；C vSAN 复制是站点级灾备，复制的是对象快照；D 延伸集群是跨站点双活部署，三个主机插槽的边缘位置压根不具备条件。

5.3 单主机容量盘上限：35 个怎么来的

第十四道样题：单个 vSAN OSA 主机磁盘组中能拥有的最大容量磁盘数是多少？答案 A：35。

这个数字来自两个上限的乘积：vSAN 最多支持 5 个磁盘组，每个磁盘组最多 7 个容量盘，5×7=35。这不是猜出来的，是 vSAN 的架构约束。实际配置到 35 块盘时，还得注意缓存盘和容量盘的比例要求——缓存盘容量至少要达到容量盘总量的 10%，否则磁盘组无法创建。全 NVMe 环境下，缓存盘比例更容易满足，但混合环境里 HDD 总量大的话，缓存盘数量会先到上限。

5.4 VMware Cloud on AWS 的 vSAN 形态

第九道样题问：在哪种环境里使用 vSAN 存储作为强制的主存储？答案 A：VMware Cloud on AWS。

这道题考的是对 VMware 产品线的了解。VMware Cloud on AWS 的每个 SDDC 集群默认采用 vSAN 作为本地存储，这是它的架构必选项，不是可选项。其他选项里，Horizon 是虚拟桌面方案，Aria Automation 是云管平台，Tanzu Kubernetes Grid 是容器编排，它们都可以对接 vSAN，但都不像 VMC 那样把 vSAN 作为强制依赖组件。

6. 送你一条验证习惯：把样题变成巡检清单

这些样题刷完，别急着关页面。我习惯把每道题对应到生产环境的一个验证动作，这样备考和运维可以复用同一套方法。

动手前先确认 vSAN 版本和磁盘格式，这是所有排障的基础。登录 ESXi 主机，跑两条命令：

# 查看 vSAN 集群配置，确认是否 ESA 模式、on-disk format 版本 esxcli vsan cluster get # 查看性能服务是否已启用，enabled 字段为 true 才是打开状态 esxcli vsan performance get

输出里重点看 storage type 和 perf service 两段。如果是 ESA 模式但性能服务是 disabled，先去 vCenter 的 vSAN 服务里启用，否则后面所有性能排查都会像第六道题一样无从下手。我接到新项目的第一件事就是跑这两条命令，确认基础状态再谈变更。

再看存储策略和对象分布，这一步对应第三章的容量判断：

# 列出集群中的存储策略，确认每个策略的 FTT 和 RAID 级别 esxcli vsan storage policy get # 查看 debug 对象列表，核对对象布局是否健康 esxcli vsan debug object list

debug 命令需要在维护窗口执行，生产环境慎用。日常巡检我主要看 vCenter 里的 vSAN 健康检查，重点盯“物理磁盘”和“容量预留”两个分类，一旦出现降级盘或预留不足的警报，就按第四章的流程处理。

巡检清单我一般固定排成五步：

• 集群健康：vSAN 健康服务里看磁盘状态和容量警报
• 性能服务：确认统计类别里能选到 Backend 和 Resync 指标
• 关机流程：任何计划性停电前先确认 HA 状态
• 升级顺序：大版本升级前核对 vCenter、ESXi、on-disk format 三个版本
• 故障域分布：机架级变更前确认故障域数量符合冗余要求

具体到 Resync 指标，我会在“监控” > “vSAN” > “性能”里选 Backend 类别，然后按“重新同步”过滤，做一个固定视图。这样主机故障恢复时能实时看到剩余字节和吞吐，不用等告警响了才去翻界面。因为第四道题显示的重新应用策略需要关注时间窗口问题，大范围变更前，我会看一下集群有没有正在运行的重新同步任务，如果有就先等它完成。

从那以后，我每次接到 vSAN 项目都强制自己先跑一遍esxcli vsan cluster get，确认版本、模式、磁盘格式，然后才允许自己做任何变更。这套从样题里提炼出来的巡检动作，已经帮我避开过好几次升级和扩容的坑。希望帮到你。

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