我在部署VCF9.1.1环境使用NVMe‑Tiering内存分层的时候踩过一个很迷惑的告警vCenter弹出告警“NVMe Memory Tiering device is not healthy.”但是告警本身没有任何详细故障描述根本不知道SSD到底哪里出问题。VCF9.1版本专门针对这个痛点做了功能改进新增NVMe设备健康报告会过滤整理出和内存分层强相关的SMART指标不用再去大海捞针看全部原始SMART日志。本篇把WebUI查看、ESXCLI本地命令、PowerCLI集群批量巡检三种实操方式完整整理出来同时讲清楚关键指标Available Spare的运维阈值与硬件更换时机。VCF9.1新增NVMe Tiering专用健康报告vmw.memTierHealthvCenter监视器‑内存分层页面可直接查看设备健康也可以通过esxcli获取JSON格式报告配合PowerCLI实现整集群所有主机批量巡检重点监控Available Spare剩余备用空间百分比跌到10%就要规划更换SSD原来vCenter告警只有标题无详情现在依靠这份报告定位底层硬件故障。一、业务背景与旧版痛点NVMe TieringMemory Tiering内存分层Tier0是主机物理DRAM内存Tier1使用高速NVMe SSD作为扩展内存层用来提升主机可寻址内存总量。旧体验SSD硬件出现劣化vCenter只会弹出“NVMe Memory Tiering device is not healthy.”告警告警文本没有细节无法区分是磨损、温度、子系统可靠性降级哪一类问题。以前排查需要手动导出完整NVMe SMART原始日志里面指标繁多很难筛选出对内存分层真正有意义的字段。VCF9.1做的改进独立生成一份内存分层专用健康报告只提取和Tier1业务强相关的SMART指标。二、vCenter WebUI图形界面查看健康报告选中ESXi主机监控选项卡 →Memory Tiering内存分层。页面可以直观看到Tier0 DRAM、Tier1 NVMe分层容量与实时使用率。页面找到Health Overview健康总览链接点击直接跳转NVMe Tiering设备健康报告。报告重点关注字段device_state设备工作状态capacity_in_GiBsSSD总容量tier_size_in_GiBs实际用作内存分层的容量tier_used_in_GiBs已经使用的分层容量available_spareSSD剩余备用空间百分比核心运维指标subsystem_reliability_degraded子系统可靠性是否降级标记三、ESXi本地命令行获取JSON健康报告SSH登录ESXi主机直接调用system health report报告输出JSON结构化数据方便脚本解析。esxcli system health report get -r vmw.memTierHealth返回JSON包含内存分层全部设备状态、容量、关键SMART统计。可以导出保存做定期基线对比。四、PowerCLI脚本整集群批量巡检所有NVMe‑Tiering设备如果你有一个多主机VCF集群一台台登录UI/SSH效率很低。下面脚本遍历集群全部ESXi主机调用esxcli v2接口拉取vmw.memTierHealth报告整理成表格输出适合日常巡检、自动化监控。$vSphereClusterWithNVMeEnabledHosts VCF‑Mgmt‑Cluster $vmhosts Get‑Cluster ‑Name $vSphereClusterWithNVMeEnabledHosts | Get‑VMHost $results foreach ($vmhost in $vmhosts) { $esxcli Get‑EsxCli ‑VMHost $vmhost ‑V2 $response $esxcli.system.health.report.get.Invoke({ reportnames (vmw.memTierHealth) }) $rawResult if ($response.result) { $response.result } else { $response } $data if ($rawResult ‑is [string]) { $rawResult | ConvertFrom‑Json } else { $rawResult } $tierHealth $data.vmw.memTierHealth $deviceData $tierHealth.unstructured[0] [PSCustomObject]{ VMHost $vmhost.Name Device $deviceData.model DeviceState $deviceData.device_state CapacityGiB $deviceData.capacity_in_GiBs TierSizeGiB $deviceData.tier_size_in_GiBs TierUsedGiB $deviceData.tier_used_in_GiBs SpareRemainingPct $deviceData.device_smart_stats.available_spare SubsystemDegraded $deviceData.device_smart_stats.subsystem_reliability_degraded } } $results | Format‑Table ‑AutoSize运行输出表格一次性看到集群每台主机的SSD型号、状态、容量、剩余备用空间、可靠性降级标记。可以输出CSV用于定期巡检归档。五、关键运维指标解读 Available SpareAvailable SpareSpareRemainingPctSSD剩余备用块百分比0‑100。正常状态100%随着SSD磨损该数值逐步下降。运维阈值下降至10%需要立刻规划更换这块NVMe SSD。当available_spare跌到阈值会触发vCenter “NVMe Memory Tiering device is not healthy.”告警。注意不要只看普通存储的SMART一定要看这份vmw.memTierHealth报告它专门面向内存分层场景做指标筛选。六、实操踩坑与注意事项☑ 告警“NVMe Memory Tiering device is not healthy”本身只是提示详情必须去看Memory Tiering健康报告告警消息不会自带故障细节。☑ NVMe SSD是专门给Memory‑Tiering使用不建议同时跑vSAN或者普通虚拟机存储该用途写入压力极大磨损速度会明显高于普通业务盘。☑ PowerCLI脚本只解析unstructured[0]也就是每台主机配置单块Tier‑NVMe场景如果未来支持多块设备脚本需要循环遍历数组。☑ 报告是VCF9.1ESXi9.0才新增旧版本环境没有vmw.memTierHealth这份报告。☑ available_spare到10%只是规划更换的预警不是立刻宕机但内存分层场景SSD磨损速度高不建议继续长期跑生产。七、高频问答QvCenter弹出NVMe Tiering设备不健康告警我该先做什么 A优先打开主机监控‑Memory Tiering页面查看Health Overview健康报告看Available Spare以及subsystem_reliability_degraded标记定位硬件根因。Q可以用普通esxcli nvme device log smart get替代这份memTierHealth报告吗 A可以拿到完整原始SMART但是字段非常多memTierHealth已经筛选出内存分层业务关心的指标运维效率更高。QSpareRemainingPct到10%SSD马上就坏吗 A不会立刻故障但是已经到达厂商预警阈值内存分层业务IO压力高需要尽快安排维护更换SSD。QPowerCLI脚本报错拿不到memTierHealth A确认ESXi版本是VCF9.1/ESXi9.0确认该主机已经开启NVMe Memory Tiering未开启分层的主机报告返回为空。全文总结VCF9.1针对NVMe‑TieringMemory Tiering增加专门的vmw.memTierHealth设备健康报告解决vCenter告警只报故障标题、不给详细原因的痛点。我们有三种排查手段vCenter WebUI的Memory‑Tiering健康总览页面ESXi本地esxcli获取JSON报告PowerCLI脚本实现整集群批量巡检。核心监控指标Available Spare剩余备用百分比一旦降到10%就要规划更换NVMe SSD。该报告专门筛选内存分层业务相关SMART指标比原始完整SMART日志更适合运维排查注意NVMe Tiering的SSD写入压力高不建议混用其他存储业务脚本适合纳入日常自动化巡检。