简介这是一份专为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-1FTT11GB 数据要写成 2 份实际占用 2GB。三节点跑 RAID-5FTT1数据切成 2 份加 1 份校验1GB 数据实际占用约 1.33GB。RAID-5 在 3 节点上能省下约三分之一容量正好命中“最大化每个部署的可用容量”。再看性能ESA 的日志结构文件系统会把随机小 I/O 整理成顺序写对低延迟场景更友好OSA 在写路径上要经过缓存盘转发延迟天花板低一截。方案架构RAID 级别1GB 数据实际空间延迟表现AOSARAID-5≈1.33GB受缓存盘写缓冲限制BOSARAID-12GB读缓存有改善但写路径长CESARAID-12GB延迟好但容量冗余太多DESARAID-5≈1.33GB延迟好容量利用率高这里有个容易忽略的点题目问的是“最大化每次部署的可用容量”不是“最大化性能”。如果单看性能C 的 ESA RAID-1 也很能打但它要吃掉双倍容量A 的 OSA RAID-5 容量账没问题但 OSA 的性能上限满足不了“低延迟”这个硬指标。D 是唯一同时满足容量和性能的选项。还有个小细节值得记vSAN ESA 集群里 RAID-5 / FTT1 的最小主机数正好是 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 / FTT1 自适应存储策略的 vSAN ESA 集群主机的绝对最小数量是多少答案 D3。不少人在 3 和 4 之间犹豫理由是多一台主机更保险。但题目问的是“绝对最小数量”不是“推荐数量”。RAID-5 在 vSAN 里的数据布局是这样的一个对象被切成数据块和校验块FTT1 意味着可以容忍一个主机或一块盘故障。数据块需要落在两个不同主机上校验块放在第三个主机三个主机正好构成 21 的条带。四台主机当然可以但三台已经是理论下限。这条规律可以顺势记一下RAID-1 FTT1 最小 2 台RAID-5 FTT1 最小 3 台RAID-6 FTT2 最小 4 台。实践里这个数字影响硬件采购。很多边缘或分支机构的部署就卡着 3 台买之后想扩容节点先要回头确认存储策略能不能放。我建集群的习惯是先定存储策略再定主机数顺序反了后面很被动。3.2 减少容量消耗降副本还是换纠删码第四道样题的场景混合 vSAN 数据存储上所有虚拟机都分配了 FTT2、RAID-1镜像策略管理员要减少虚拟机消耗的容量问怎么做。四个选项里只有一个真正减少了数据副本A 改成“2 故障 - RAID-5纠删码”听起来纠删码省空间但 FTT 保持在 2RAID-5 需要 2 份数据加 1 份校验总开销和 RAID-1 FTT2 的三副本差不多省不了多少而且混合架构上跑纠删码重建时的校验计算会给磁盘和 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 是站点容灾无、FTT1、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.0vSphere Lifecycle Manager 提示无法获取补丁和元数据。原因vLCM 默认从 VMware Online Depot 拉取升级包非互联网环境访问不了外网。选了 D“不可能使用 vLCM”的人是不知道正确解法选 A、B 的人没意识到在线仓库在这个场景下根本不通。解决搭建一个 Update Manager Download ServiceUMDS实例在有网络的机器上把 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 故障域的设计逻辑是把机架抽象成故障域数据副本必须跨故障域放置。FTT1 时数据块和副本落在两个不同故障域理论上两个机架就能满足。但两个机架的问题是一旦某个机架整体断电或网络中断故障域内没有第三个可用故障域来承担重建任务所有虚拟机都挤到剩下的机架上可用性和性能双双告急。三个故障域才是机架级容错的可靠下限。实践里机架分布不只是数量问题还要考虑每个机架上的主机数量。24 台服务器平均分到三个机架每个机架 8 台故障域划分就非常清晰。如果机架数量和主机数量不均衡vSAN 的数据分布会偏向容量大的故障域反而影响冗余均衡。5.2 HCI Mesh跨集群借存储第十五道样题应用虚拟机跑在专用 vSAN 集群上自定义 CPU 和内存不能 vMotion 到其他集群但需要从另一个 vSAN 集群分配额外存储。该用哪个 vSAN 特性答案 BvSAN HCI Mesh。HCI Mesh 是 vSAN 的跨集群存储共享功能允许一个 vSAN 集群把容量以数据存储形式挂载给另一个 vSAN 集群。它的价值在于不用迁移虚拟机、不用改集群配置、不用买新存储就能把一个集群的空闲容量借给另一个集群使用。题目里的约束“不能 vMotion”正好让 HCI Mesh 成为唯一可行解——数据存储可以远程挂载虚拟机计算位置不变。其他选项的排除逻辑A 文件服务是给客户端提供 NFS/SMB 共享不走 vSAN 对象路径C vSAN 复制是站点级灾备复制的是对象快照D 延伸集群是跨站点双活部署三个主机插槽的边缘位置压根不具备条件。5.3 单主机容量盘上限35 个怎么来的第十四道样题单个 vSAN OSA 主机磁盘组中能拥有的最大容量磁盘数是多少答案 A35。这个数字来自两个上限的乘积vSAN 最多支持 5 个磁盘组每个磁盘组最多 7 个容量盘5×735。这不是猜出来的是 vSAN 的架构约束。实际配置到 35 块盘时还得注意缓存盘和容量盘的比例要求——缓存盘容量至少要达到容量盘总量的 10%否则磁盘组无法创建。全 NVMe 环境下缓存盘比例更容易满足但混合环境里 HDD 总量大的话缓存盘数量会先到上限。5.4 VMware Cloud on AWS 的 vSAN 形态第九道样题问在哪种环境里使用 vSAN 存储作为强制的主存储答案 AVMware 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 listdebug 命令需要在维护窗口执行生产环境慎用。日常巡检我主要看 vCenter 里的 vSAN 健康检查重点盯“物理磁盘”和“容量预留”两个分类一旦出现降级盘或预留不足的警报就按第四章的流程处理。巡检清单我一般固定排成五步集群健康vSAN 健康服务里看磁盘状态和容量警报性能服务确认统计类别里能选到 Backend 和 Resync 指标关机流程任何计划性停电前先确认 HA 状态升级顺序大版本升级前核对 vCenter、ESXi、on-disk format 三个版本故障域分布机架级变更前确认故障域数量符合冗余要求具体到 Resync 指标我会在“监控” “vSAN” “性能”里选 Backend 类别然后按“重新同步”过滤做一个固定视图。这样主机故障恢复时能实时看到剩余字节和吞吐不用等告警响了才去翻界面。因为第四道题显示的重新应用策略需要关注时间窗口问题大范围变更前我会看一下集群有没有正在运行的重新同步任务如果有就先等它完成。从那以后我每次接到 vSAN 项目都强制自己先跑一遍esxcli vsan cluster get确认版本、模式、磁盘格式然后才允许自己做任何变更。这套从样题里提炼出来的巡检动作已经帮我避开过好几次升级和扩容的坑。希望帮到你。本文还有配套的精品资源点击获取