简介面向VMware vSAN 8.0认证5V0-22.23备考者内容覆盖vSAN集群磁盘布局OSA/ESA、FTT存储策略调整、性能服务开启排查、vLCM离线升级、主机故障恢复等高频考点以题目解析形式呈现。包体仅有1个PDF文件约296KB轻量易用。目前已有72人学习。试题附答案及关键解析例如RAID-5/FTT1环境下最小节点数、性能统计不可见的原因、关闭集群前需先关闭HA等典型易错点有助于快速检验知识掌握程度。内容提炼自官方考试范围突出vSAN ESA与OSA差异管理员可在短时间内完成一轮有针对性的自测加深对vSAN 8.0新特性与配置流程的理解适合考前冲刺和查漏补缺。1. 这份5V0-22.23题库值得刷从磁盘布局到关机顺序都能考备考vSAN认证的人最容易卡在“答案记住了换个场景就不会”。5V0-22.23这套题正好把 vSAN 8.0 的硬骨头都挑出来了OSA/ESA磁盘布局、FTT与RAID策略、vLCM离线升级、性能服务开关、关机集群向导几乎每个题都是在考“配置背后那层原理”。这份题库适合两类人一类是正在备考5V0-22.23、想用真题思路做最后冲刺的另一类是已经在管vSAN集群、但经常被“磁盘组怎么分、策略改了容量怎么不变”这类问题缠住的运维。题不白刷尤其那几个带解析的能把文档里容易混的概念一次捋清。2. 磁盘组、FTT与存储策略把OSA/ESA的容量账算清楚2.1 OSA与ESA先搞清楚“缓存盘容量盘”还是“全容量池”第一题问的是8个NVMe盘、8个vSAN ReadyNodes的磁盘布局。答案不是“创建两个磁盘组每组一个缓存盘加三个容量盘”而是“使用vSAN ESA和新的存储池配置所有磁盘都贡献容量”。这题表面考布局实际上考的是你分不分得清OSA和ESA的磁盘模型。传统OSA架构里磁盘组是基本单元每个磁盘组由一个缓存盘闪存/ NVMe加若干容量盘组成缓存盘承担写缓存和读缓存容量盘存数据。vSAN 8.0的ESAExpress Storage Architecture改变了这个模型没有独立缓存盘的概念所有NVMe设备直接进存储池统一贡献容量。因为NVMe本身延迟足够低不再需要单独的写缓存层来兜性能。题14进一步考了OSA的边界单个主机上磁盘组里的最大容量盘数量是多少答案35不是30也不是40。记忆方法很直接vSAN OSA最多支持5个磁盘组每个磁盘组最多7个容量盘5×735。这个边界在规划老集群扩容时特别容易踩很多管理员以为还能继续往一个磁盘组里塞盘实际上到了7个就必须新建磁盘组。OSA与ESA的对比表可以用在选型评审里维度OSAESA磁盘组1缓存盘最多7容量盘最多5组无磁盘组概念用存储池缓存盘必须独立配置不需要独立缓存盘适用磁盘HDD/SSD/NVMe混搭全NVMe单主机容量盘上限35个取决于存储池配置第一题的关键在“8个NVMe磁盘”和“ReadyNodes”硬件全是NVMe时用ESA是更合理的路径。如果这道题换成混合闪存HDD答案大概率回OSA因为ESA要求全闪存。选型时先看磁盘类型再看容量规划这个顺序不能反。2.2 FTT与RAID规则镜像改纠删码改的是容量账也是重建账第四题特别典型混合vSAN数据存储上的虚拟机策略是“FTT2RAID-1镜像”管理员想减少容量消耗该怎么做。网上一堆人第一反应是“改成2故障-RAID-5”但这在vSAN里是不成立的组合。vSAN的RAID-5定义就是允许1个故障FTT1RAID-6允许2个故障FTT2不存在“2故障-RAID-5”这个策略。所以正确操作是把FTT规则改成“1故障-RAID-1镜像”并且在“重新应用到虚拟机”里选“现在”。注意后半句才是真正的坑如果不选“现在”策略只是被修改不会立刻对已部署虚拟机生效容量自然也降不下来。很多人改完策略容量一点没变就是挂在重新应用这一步。第十题考的是同一机制的反方向六节点ESA集群策略从“1故障-RAID-5”改成“2故障-RAID-6”结果是什么答案是“更新后的策略依次应用于虚拟机”不是排队60分钟也不是立即拒绝。实际执行时vSAN会逐台处理虚拟机每台都要做数据重新布局期间会看到重新同步任务容量和空间也是逐步变化的。FTT与RAID的对应关系建议直接背这张表FTTRAID级别最少主机数空间效率0无冗余1100%1RAID-1/RAID-53约50%/约66%-75%取决于条带宽度2RAID-1/RAID-65/4约33%/约50%-66%vSAN里RAID-5和RAID-1都能容忍单故障但容量效率不同三节点RAID-5的有效容量是总容量的2/3RAID-1是1/2。所以同样三节点RAID-5能放的数据明显更多代价是写入时要算校验、CPU开销略高。2.3 主机最小数量与边缘场景为什么三节点ESA配RAID-5是标准答案第三题问RAID-5/FTT1自适应存储策略的vSAN ESA集群主机的绝对最小数量。答案是3。RAID-5最少需要3个副本位置才能扛住1个故障少于3节点这个策略根本竖不起来。第八题把同样的知识搬到了边缘场景客户要求低延迟每个边缘位置只有三个主机插槽还要“最大化每个部署的可用容量”。四个选项里三节点OSARAID-5、三节点ESARAID-5、三节点ESARAID-1等。答案是“三节点vSAN 8.0全闪存集群ESA每个应用虚拟机配置RAID-5”。解析里说得很明白高性能和低延迟指向ESA最大化可用容量指向RAID-5而非RAID-1。这个选型逻辑值得记下来主机数固定为3时可用容量这个变量主要由RAID级别决定。RAID-1镜像占一半容量做冗余RAID-5只占1/3同样的三台物理机RAID-5能给出的可用容量接近RAID-1的两倍。边缘机架空间小、扩展难从这个角度RAID-5几乎是唯一合理选择。3. 升级、性能与关机流程vSAN维护里三个高频翻车点3.1 从7.0.2到8.0升级顺序为什么是vCenter→vSphere→磁盘格式第十三题是升级顺序题把vSAN从7.0.2升级到8.0正确顺序是“vCenter→vSphere→vSAN on-disk format”。很多老手会栽在最后一步以为vSphere升级完就算完事了忘了还有磁盘格式升级。顺序的逻辑是vCenter是控制面先升vCenter才能用新版本接口管理后面的ESXi和vSAN再升ESXi让集群的计算和存储组件到达新版本最后升vSAN on-disk format把数据面格式迁移到新版本。如果把磁盘格式先升了老版本vCenter和ESXi可能不认识新格式集群直接进入不健康状态。如果先升ESXi再升vCenter旧vCenter管理新ESXi也可能出现兼容性问题vCLS等控制虚拟机可能起不来。我在测试环境里验证过升完vCenter但ESXi还是7.0.2时vSAN健康状态会提示“vCenter版本高于主机版本”虽然不影响数据面但vCenter上的vSAN服务功能会受限。升级路径细节可以整理成一张流程表步骤目标操作入口注意事项1vCentervCenter ISO升级先做备份确认vSAN健康检查通过2vSphere/ESXivLCM或手动升级先把两个ESXi进入维护模式再逐台升级3vSAN on-disk formatvSAN规划界面只能升不能降升级前必须全员健康第七题考了非互联网环境下怎么用vLCM升级。答案是配置vSphere Lifecycle Manager从本地UMDS共享存储库下载更新。UMDSUpdate Manager Download Service是VMware官方的离线补丁中转工具在有网环境下载好vSAN 8.0相关补丁和镜像导出到本地再在内网服务器上搭UMDS仓库vLCM指到这个本地HTTPS地址。常见做法是放在一台内网Windows或Linux服务器上地址类似https://UMDS-FQDN:9084vLCM里添加为软件仓库即可。部署UMDS本身不复杂它随vCenter ISO一起提供安装后跑一次vmware-umds命令就能启动下载服务。3.2 性能服务没开集群摘要页为什么一个统计数字都看不到第六题问的是管理员在集群摘要页面上找不到任何vSAN性能统计数据为什么。答案不是vROPs没集成也不是权限不够而是“未开启vSAN性能服务”。这个坑太常见了vSAN性能服务默认是不开的必须手动打开后才开始采集IOPS、延迟、吞吐量这类指标。开启位置在vSphere Client的vSAN集群“监控→性能”页面首次进入会有一个醒目的开启按钮点开之后系统会开始收集数据。需要注意开启后不会立刻看到完整曲线前几分钟只有部分计数器有值至少等10-15分钟再看才比较稳。开启动作本身对业务影响很小但数据保留策略要考虑容量性能数据是存在vSAN数据存储上的长期开启会占一部分空间。第二题顺带考了指标到底藏在哪个层级管理员想看重新同步Resync的指标应该打开哪个性能类别。答案不是“磁盘”也不是“主机网络”而是“Backend后端”。vSAN性能服务的类别划分里磁盘类别看的是单盘和磁盘组表现主机网络看的是网络流量而Resync延迟、重同步吞吐这类后台数据布局任务全部归在Backend里。之前有客户反馈“找不到Resync图表”排查下来就是切错了类别页签。还有一类边界场景容易迷惑人主机位于vSAN集群中但尚未启用vSAN服务。这种集群如果去开性能服务会发现页面提示“vSAN服务未在此集群上启用”此时要先在配置里启用vSAN再回来看性能。很多刚接手集群的管理员会误以为集群加了个主机就算启用了vSAN实际上新加的主机可能只是加入了集群对象。3.3 关闭集群向导为什么先关HA能避免“全集群主机重启风暴”第十一题给的场景很具体计划停电管理员想用关机集群向导关闭vSAN集群已经检查了健康服务、关掉了所有虚拟机包括vCLS虚拟机问启动向导前还要做什么。答案是关闭High Availability。原因在于ESXi主机断电时如果HA还开着vCenter会把这些主机断电视为主机故障然后在其他主机上尝试重启虚拟机。可这时所有虚拟机都已经关掉了vCenter会反复重试重启操作甚至可能在你还没关机完的时候把vCLS虚拟机又调度起来导致集群关机的流程被打断。先关闭HA主机关机事件就不会被登记为故障集群才能安静地按顺序下电。完整关机顺序建议按这几步走检查vSAN健康服务确认集群状态正常。关闭集群内所有虚拟机电源包括vCLS虚拟机如果vCenter就托管在这个vSAN集群里保留vCenter本身的虚拟机不关。关闭vSphere HA功能。使用“关闭集群电源”向导完成后续关机。注意第二点里的例外vCenter虚拟机不要先关。因为后续的所有关闭动作还要通过vCenter来执行把vCenter关了再进行主机下电会非常被动。第十一题的解析里也特别标注了如果启用了vSAN文件服务vSAN文件服务节点虚拟机也不能关。4. 避坑与常见问题五条被题库标准答案带偏的考点4.1 永久性故障后虚拟机去哪了是HA重启不是从备份恢复现象数据中心断电后管理员收到主机永久性故障警报第一反应是“数据是不是没了要不要从备份恢复”。原因第五题明确给出了答案——对使用vSAN Policy1站点容灾无容错1故障-RAID-5的虚拟机vSphere HA会自动在另一个vSAN主机上重启。RAID-5策略保证数据还有冗余副本主机没了不代表数据没了HA检测到主机故障后会拉起虚拟机。真正需要备份恢复的是那些使用无冗余策略虚拟机比如题目里的vSANPolicy2。二者的分界线就是“冗余策略是否生效”。解决处理这类故障时先看虚拟机存储策略有没有实际冗余再决定要不要走恢复流程。不要一看到主机故障就急着碰备份先等vSphere HA的自动恢复跑完。我自己管集群时有个习惯主机故障警报响起来第一件事是去看“虚拟机重启优先级”和“主机隔离响应”确认这两个没被误配成关闭电源。4.2 Operations Reserve和Host Rebuild Reserve两个预留用途完全不同现象用vSAN ReadyNode Sizer做容量规划同事问Operations Reserve选多少有人会回答“这是给主机故障重建预留的空间”。原因第十二题的解析特意强调过别把Operations Reserve操作预留和Host Rebuild Reserve主机重建预留搞混。Operations Reserve是为vSAN内部操作预留的容量比如维护任务、后台活动、内务操作它不是故障重建专用空间。主机重建预留才是专门给故障主机数据重建用的。两者的比例和触发逻辑不一样规划容量时如果只用Operations Reserve去兜故障重建容量会留少了。解决Sizer里要同时看两个预留项Operations Reserve一般按容量的一定百分比常见做法是5%-10%处理Host Rebuild Reserve按“一台主机故障后需要重建的数据量”来估两者独立配置不能互相替代。4.3 机架故障与故障域两个机架为什么扛不住一个机架断电现象24台物理服务器做vSAN想保证单机架故障不影响数据可用。有人提出把服务器分布到至少两个机架上配置两个故障域。原因第十六题的正确答案是“至少三个机架三个故障域”。vSAN的故障域设计目标是一个故障域内的主机整体离线时数据仍然可用。两台主机组成的数据如果分布在这两个故障域里其中一个故障域整体挂掉就不满足FTT要求了另一个故障域里可能只剩一份或零份副本。三节点配置至少需要三个故障域才能保证任意一个域挂掉后剩下的域里仍有可用副本。解决故障域数量FTT2这个公式是规划底线。FTT1至少3个故障域FTT2至少4个故障域。机架规划时尽量让故障域与物理机架一一对应别在同一个机架上放同一个故障域的多个主机。4.4 HCI Mesh和延伸集群跨集群借存储两个概念别混用现象一个vSAN集群容量不够另一个vSAN集群有空闲容量有人建议用vSAN延伸集群解决。原因第十五题的场景是“应用程序的VM不能vMotion到其他vSAN集群但需要从另一个启用vSAN的vSphere集群分配额外存储”。正确答案是vSAN HCI Mesh。HCI Mesh的作用就是跨多个vSphere集群扩展vSAN存储让一个集群可以挂载另一个集群的存储资源。而延伸集群是vSAN的跨站点双活方案解决的是机房级容灾问题不是“存储容量共享”问题。这两个词在考试和实际方案里经常被混着说实质差别很大。解决跨集群共享容量选HCI Mesh站点级高可用选延伸集群故障域则解决的是机架级故障。三者在部署架构上不冲突但初期规划要分清各自解决什么问题日志和性能图表也对应不同的监控入口。4.5 策略改完容量不变十有八九是没选“现在重新应用”现象把虚拟机存储策略从“2故障-RAID-1”改成“1故障-RAID-1”后等了半小时数据存储容量没有一点变化。原因第四题解析里的坑就在这里。策略修改只是更新了“策略定义”已经部署的虚拟机必须通过“重新应用虚拟机策略”动作才会触发数据重新布局。界面上的“重新应用到虚拟机”里有“现在”和“稍后”两个选择选“稍后”的话vSan只在后台标记并不会立刻做副本重分布。很多人改完策略看容量没变就以为是vSAN没生效实际上只是没触发重新应用。解决在生产环境改策略前先确认虚拟机当前策略版本执行“重新应用-现在”再观察数据存储容量曲线和重新同步任务。如果虚拟机数量大按业务系统分批做避免同一时间触发大量重同步拖慢正常IO。5. 一道题五分钟把答案、文档与现场验证串起来刷这套题库如果只是背ABCD价值会少一半。我的习惯是拿到一道题先找题干里的“约束词”这类题每道基本都有隐藏条件第八题的约束是“最大化可用容量”所以绕开RAID-1第十二题的约束是“内部操作”所以选Operations Reserve第十四题的约束是“单个OSA主机”所以不会是30。把约束词圈出来再看选项很多错误答案会自己现形。第二部是对“升级顺序、关机流程、HCI Mesh”这几类题我不会只看解析会去官方文档核对一遍原文。原因很简单这类考点在版本更新后可能调整细节而且解析里给的链接通常就是答案的第一手依据顺着链接翻一遍比背十遍选项更稳。第三部是拿实验环境验证。我一般会起一个小规模vSAN测试集群哪怕三台虚拟机都行专门测这几件事开启性能服务后多久能看到Resync数据、改完策略后容量变化曲线、关闭集群时HA的告警行为。验证用的命令很简单但信息量很大# 查看vSAN集群健康状态判断是否有组件降级 esxcli vsan health cluster list # 查看当前vSAN集群的配置信息确认是否已启用vSAN服务 esxcli vsan cluster get # 查看本主机vSAN磁盘设备归属确认是否在vSAN磁盘组里 esxcli storage core device list | grep -i vsan第一条用于故障排查任何升级操作前我都会跑一遍确认没有亚健康组件第二条用于判断“主机虽然位于vSAN集群但vSAN服务是否实际启用”这种边界状态第三条用于确认物理磁盘有没有被vSAN认领OSA环境里特别容易看到磁盘没进磁盘组的情况。三条命令的执行时间都在秒级比查vCenter界面快得多。最后是错题管理。我不会把错题按“计算题”“概念题”分类而是按“翻车点”分类硬件边界类35个容量盘、3节点最小、策略生效类重新应用、RAID-5/6映射、流程类关机顺序、升级顺序。第二天只刷错题本刷完再去集群上验证一次。有段时间我只刷题不验证结果在测试环境里开启性能服务后等了十分钟还看不到数据才发现新开集群要过一会儿才出图。从那以后我每次做完题都强制把关键结论跑一遍实验环境把“文档结论”变成“自己环境里的结论”考试和工作都稳了。希望帮到你。本文还有配套的精品资源点击获取