我在部署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.memTierHealth；vCenter监视器‑内存分层页面可直接查看设备健康；也可以通过esxcli获取JSON格式报告，配合PowerCLI实现整集群所有主机批量巡检；重点监控Available Spare剩余备用空间百分比，跌到10%就要规划更换SSD；原来vCenter告警只有标题无详情，现在依靠这份报告定位底层硬件故障。
一、业务背景与旧版痛点
NVMe Tiering（Memory 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_GiBs：SSD总容量
tier_size_in_GiBs：实际用作内存分层的容量
tier_used_in_GiBs：已经使用的分层容量
available_spare：SSD剩余备用空间百分比（核心运维指标）
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 Spare
Available Spare（SpareRemainingPct）：SSD剩余备用块百分比，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.1（ESXi9.0）才新增，旧版本环境没有vmw.memTierHealth这份报告。
☑ available_spare到10%只是规划更换的预警，不是立刻宕机，但内存分层场景SSD磨损速度高，不建议继续长期跑生产。
七、高频问答
Q：vCenter弹出NVMe Tiering设备不健康告警，我该先做什么？ A：优先打开主机监控‑Memory Tiering页面查看Health Overview健康报告，看Available Spare以及subsystem_reliability_degraded标记，定位硬件根因。
Q：可以用普通esxcli nvme device log smart get替代这份memTierHealth报告吗？ A：可以拿到完整原始SMART，但是字段非常多；memTierHealth已经筛选出内存分层业务关心的指标，运维效率更高。
Q：SpareRemainingPct到10%，SSD马上就坏吗？ A：不会立刻故障，但是已经到达厂商预警阈值，内存分层业务IO压力高，需要尽快安排维护更换SSD。
Q：PowerCLI脚本报错拿不到memTierHealth？ A：确认ESXi版本是VCF9.1/ESXi9.0；确认该主机已经开启NVMe Memory Tiering；未开启分层的主机报告返回为空。
全文总结
VCF9.1针对NVMe‑Tiering（Memory Tiering）增加专门的vmw.memTierHealth设备健康报告，解决vCenter告警只报故障标题、不给详细原因的痛点。我们有三种排查手段：vCenter WebUI的Memory‑Tiering健康总览页面；ESXi本地esxcli获取JSON报告；PowerCLI脚本实现整集群批量巡检。核心监控指标Available Spare剩余备用百分比，一旦降到10%就要规划更换NVMe SSD。该报告专门筛选内存分层业务相关SMART指标，比原始完整SMART日志更适合运维排查；注意NVMe Tiering的SSD写入压力高，不建议混用其他存储业务，脚本适合纳入日常自动化巡检。