获取验证码
我在部署VCF9.1.1环境使用NVMe‑Tiering(内存分层)的时候踩过一个很迷惑的告警:vCenter弹出告警“NVMe Memory Tiering device is not healthy.”,但是告警本身没有任何详细故障描述,根本不知道SSD到底哪里出问题。VCF9.1版本专门针对这个痛点做了功能改进,新增NVMe设备健康报告,会过滤整理出和内存分层强相关的SMART指标,不用再去大海捞针看全部原始SMART日志。本篇把WebUI查看、ESXCLI本地命令、PowerCLI集群批量巡检三种实操方式完整整理出来,同时讲清楚关键指标Available Spare的运维阈值与硬件更换时机。
有VMware全系列产品官方资源和定制版资源需求的可以移步:
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指标。
选中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:子系统可靠性是否降级标记
SSH登录ESXi主机,直接调用system health report,报告输出JSON结构化数据,方便脚本解析。
esxcli system health report get -r vmw.memTierHealth
返回JSON包含内存分层全部设备状态、容量、关键SMART统计。可以导出保存做定期基线对比。
如果你有一个多主机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(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写入压力高,不建议混用其他存储业务,脚本适合纳入日常自动化巡检。