Home

VMware vSphere 数据存储 APD / PDL 事件处理

3634字 预计阅读时间：18.2分钟 VMware

这篇文章整理 vSphere 环境中数据存储出现 APD 和 PDL 时的判断方法、排查命令和处理流程。

这类故障看起来都像“主机访问不到存储”，但处理思路完全不同。APD 更偏向临时路径中断，重点是恢复路径和观察 I/O 是否恢复；PDL 则表示设备被明确判定为永久丢失，重点是确认数据是否还能恢复，以及如何安全清理残留引用。

在生产环境里，最重要的不是第一时间敲命令，而是先判断故障类型、影响范围和数据是否还有恢复机会。

一、先区分 APD 和 PDL

APD 是 All Paths Down，意思是 ESXi 到某个存储设备的所有路径都不可用。它通常表示“暂时访问不到”，例如 SAN 交换机重启、FC 链路闪断、iSCSI 网络中断、NFS 服务临时不可达等。

PDL 是 Permanent Device Loss，意思是 ESXi 收到明确的设备永久丢失信号。常见原因包括 LUN 被删除、阵列端取消映射、存储卷永久下线，或者阵列返回了表示设备不存在的 SCSI sense 信息。

可以先用下面这个表快速判断：

对比项APDPDL
含义所有路径暂时不可用设备被判定为永久丢失
常见原因交换机重启、链路抖动、阵列控制器切换、NFS/iSCSI 网络中断LUN 删除、LUN unpresent、阵列明确返回设备不存在
阵列响应通常没有有效响应返回明确的 SCSI 错误
VM 影响I/O 挂起，路径恢复后可能继续运行I/O 失败，原数据存储不可继续使用
恢复方式先恢复链路，再 rescan 或等待自动恢复先确认数据恢复可能性，再清理设备和数据存储引用
操作风险误重启主机、误 detach 可能放大影响误清理可能切断后续恢复机会

简单记法：

  • APD：设备像是“暂时失联”，优先恢复路径。
  • PDL：设备像是“被确认移除”，优先确认数据是否还能找回。

二、故障发生时先做什么

收到 All Paths Down、Permanent Device Loss、datastore inaccessible 这类告警后，不建议马上重启 ESXi 主机，也不要直接 detach 设备。

第一轮判断先做三件事：

  1. 判断影响范围：是单台主机、部分主机，还是整个集群。
  2. 判断故障类型：从 vCenter 事件和 vmkernel.log 区分 APD / PDL。
  3. 判断业务影响：哪些 VM、数据库、ISO、模板、RDM 或备份任务正在使用这个 datastore。

如果是单台主机异常，优先怀疑这台主机的 HBA、网卡、光模块、线缆、zoning、multipath 或 iSCSI vmkernel 网络。

如果所有主机同时异常，优先怀疑存储阵列、SAN 交换机、NFS 服务端、iSCSI 网络、LUN masking 或上游变更。

三、日志和命令检查

1. 查看 vmkernel 日志

先在受影响主机上看 vmkernel.log。这是区分 APD / PDL 最直接的证据。

# 查 APD 相关事件
grep -i "APD\|All Paths Down" /var/log/vmkernel.log

# 查 PDL 相关事件
grep -i "PDL\|Permanent Device Loss\|permanent device" /var/log/vmkernel.log

# 同时查看设备 NAA、sense code、路径变化
grep -i "naa\.\|sense\|lost communication\|dead path" /var/log/vmkernel.log

APD 日志通常会出现设备进入 All Paths Down 状态，以及后续是否退出 APD 状态。

PDL 日志通常会出现 Permanent Device Loss、设备永久丢失、SCSI sense code 等信息。排查时不要只看告警标题，最好把对应时间段的日志上下文一起保存。

2. 查看路径状态

# 快速查看多路径状态
esxcfg-mpath -b

# 查看更详细的路径、适配器、目标端口和状态
esxcli storage core path list

重点关注：

  • 是否所有路径都处于 dead、off、not responding 等状态。
  • 是否只有某个 HBA 或某条链路异常。
  • 是否多个主机看到相同路径异常。

如果只有一条路径异常，多路径通常可以自动切换；如果所有路径都异常，才会进入 APD 或更严重的不可访问状态。

3. 查看设备状态

# 列出存储设备
esxcli storage core device list

# 针对某个 naa 设备查看状态
esxcli storage core device list -d naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

重点关注：

  • Status 是否为 on、off、dead、lost communication。
  • 设备是否仍然有路径。
  • 设备是否被标记为 detached。
  • 是否存在 Perennially Reserved 等特殊标记。

4. 查看文件系统挂载

# 查看 ESXi 当前识别到的数据存储
esxcli storage filesystem list

# 查看 VMFS 卷
esxcli storage vmfs extent list

这里要确认 datastore 名称、UUID、对应的 naa 设备，以及是否仍处于挂载状态。

四、APD 的处理流程

APD 的核心原则是：先恢复路径，不要急着清理设备。

1. 常见触发场景

APD 常见于这些场景：

  • FC SAN 交换机重启或级联链路闪断。
  • 存储阵列控制器 failover 时间过长。
  • iSCSI 专用网络丢包、MTU 不一致或交换机端口异常。
  • NFS 服务端重启、网络中断或导出目录短暂不可访问。
  • LUN masking 或 zoning 临时变更后又恢复。

2. 处理步骤

第一步，确认是否只有单台主机受影响。

如果只有单台主机受影响，优先检查这台主机：

# 查看 FC HBA 状态
esxcli storage san fc list

# 查看 FC HBA 统计信息
esxcli storage san fc stats get

# 查看 iSCSI 适配器状态
esxcli iscsi adapter list

# 查看 vmkernel 网卡
esxcli network ip interface list

第二步，确认存储侧是否已经恢复。

如果 SAN、阵列、NFS 或 iSCSI 服务端仍然异常，在 ESXi 上反复 rescan 意义不大。此时应该先让存储或网络侧恢复链路。

第三步，在确认上游恢复后执行 rescan。

# 扫描所有存储适配器
esxcli storage core adapter rescan --all

# 只扫描某个 HBA
esxcli storage core adapter rescan -A vmhba0

第四步，观察 APD 是否退出。

# 查看 APD 是否有退出日志
grep -i "exited.*All Paths Down\|APD" /var/log/vmkernel.log

# 再次确认路径状态
esxcfg-mpath -b

如果路径恢复，VM 的 I/O 可能继续执行。但数据库、文件系统和应用不一定完全无感知，仍然需要做业务侧检查。

3. APD 下不要轻易做的事

APD 期间最容易犯的错误是把“暂时访问不到”当成“设备没了”处理。

不建议在没有确认的情况下做这些动作：

  • 重启所有 ESXi 主机。
  • detach 设备。
  • 强制删除 datastore。
  • 在阵列端删除或重建 LUN。
  • 把 APD 设备手工当作 PDL 清理。

这些动作可能会让本来可恢复的临时故障变成复杂事故。

五、PDL 的处理流程

PDL 的核心原则是：先确认数据是否还有恢复机会，再清理。

1. 常见触发场景

PDL 常见于这些场景：

  • 存储管理员误删 LUN。
  • 阵列端取消了主机或集群的 LUN 映射。
  • zoning 或 masking 变更导致主机不再被允许访问该设备。
  • 阵列端明确返回设备不存在或永久不可用。

如果是误删 LUN，第一优先级不是 ESXi 清理，而是立即确认阵列侧是否有快照、回收站、克隆、复制或其他回退机制。

2. 处理前检查

处理 PDL 前，至少确认以下信息：

  • 这个 LUN 是否是有意删除。
  • 上面是否还有 VM、模板、ISO、RDM、快照或备份任务。
  • 是否所有主机都看到 PDL。
  • 是否有阵列侧快照或备份可以恢复。
  • 是否已经记录 datastore 名称、UUID、naa 设备号和受影响 VM 清单。

如果存储管理员不能确认 LUN 是有意删除，不要急着 detach。

3. 有意下线 LUN 的清理步骤

如果确认 LUN 已不再使用，并且没有恢复需求，可以按下面流程清理。

先卸载 datastore：

# 按 datastore 名称卸载
esxcli storage filesystem unmount -l <datastore_name>

# 或按 UUID 卸载
esxcli storage filesystem unmount -u <datastore_uuid>

再将设备置为 off：

# 关闭指定 naa 设备
esxcli storage core device set --state=off -d <naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

然后 rescan：

# 重新扫描存储适配器
esxcli storage core adapter rescan --all

如果这个 datastore 曾经被多台主机挂载，需要在所有相关 ESXi 主机上执行一致的卸载和清理动作。

4. 无意 PDL 的应急思路

如果 PDL 是误操作或未知原因导致，处理顺序应该反过来：

  1. 暂停所有相关变更。
  2. 保留 ESXi 和 vCenter 当前状态。
  3. 让存储管理员确认 LUN 是否还能恢复。
  4. 如果阵列侧可恢复，先恢复 LUN 映射，再让 ESXi rescan。
  5. 如果阵列侧不可恢复，再从备份恢复 VM，并清理 PDL 残留。

这里最关键的一点是：不要先把 ESXi 侧清理干净。清理动作本身不一定销毁阵列数据，但会减少现场证据，也可能让后续判断更困难。

六、HA 和 VMCP 配置要点

vSphere HA 可以结合 VMCP（VM Component Protection）对 APD 和 PDL 做自动响应。

常见配置位置：

Cluster
  Configure
    vSphere Availability
      Failure Conditions and VM Response

生产环境通常会关注两类响应：

  • Datastore with APD
  • Datastore with PDL

可以选择只发事件，也可以选择关闭并重启 VM。是否启用自动重启，要结合业务特点、存储架构和集群冗余能力决定。

需要注意几个前提：

  • 目标主机必须能访问 VM 所需的数据存储，否则 HA 无法在其他主机成功拉起 VM。
  • 如果整个集群都访问不到同一个 datastore，自动重启并不能解决问题。
  • 对数据库类业务，I/O 挂起和强制关机都有风险，需要和业务团队确认可接受策略。
  • APD 自动响应不等于修复存储，只是让 VM 不一直挂在无响应 I/O 上。

所以 HA/VMCP 是“降低业务等待时间”的手段，不是替代存储排障的手段。

七、vSAN 场景的特别说明

如果环境是 vSAN，不要把传统 SAN LUN 的 APD / PDL 流程直接套上去。

vSAN 的数据可用性依赖对象、组件、副本、磁盘组、主机和存储策略。某个磁盘或磁盘组异常时，应该优先从 vSAN 健康状态和对象状态判断。

建议检查：

# 查看 vSAN 磁盘状态
esxcli vsan storage list

# 查看 vSAN 集群状态
esxcli vsan cluster get

# 查看 vSAN 对象健康信息，具体命令随版本可能不同
esxcli vsan debug object list

在 vSAN 场景里，重点不是“这个 LUN 是否还在”，而是：

  • 对象是否仍然合规。
  • 组件是 Absent 还是 Degraded。
  • 当前 FTT 策略是否还能承受下一次故障。
  • 是否正在大量 resync。
  • 故障是否来自磁盘、控制器、网络还是整台主机。

如果是 vSAN 数据存储异常，优先走 vSAN Health、Skyline Health、对象状态和物理磁盘健康检查，不要直接按传统 datastore detach 流程处理。

八、排查流程汇总

可以按下面顺序执行：

1. 收到 datastore / APD / PDL 告警
2. 判断影响范围：单主机、部分主机、全集群
3. 查看 vCenter 事件和 vmkernel.log
4. 判断 APD 还是 PDL
5. 记录 datastore、naa、主机、VM 清单
6. APD：优先恢复路径和上游存储网络
7. PDL：优先确认 LUN 是否可恢复
8. 恢复后 rescan，验证路径和 datastore 状态
9. 检查受影响 VM 和业务系统
10. 补齐根因、变更记录和预防措施

实际排障中，最容易节省时间的是第 2 步。单主机和全集群的排查方向完全不同。

九、常用命令速查

# 查看 APD / PDL 日志
grep -i "APD\|All Paths Down\|PDL\|Permanent Device Loss" /var/log/vmkernel.log

# 查看多路径摘要
esxcfg-mpath -b

# 查看路径详细状态
esxcli storage core path list

# 查看设备列表
esxcli storage core device list

# 查看指定设备
esxcli storage core device list -d <naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

# 查看文件系统挂载
esxcli storage filesystem list

# 查看 VMFS 卷和 extent
esxcli storage vmfs extent list

# 重新扫描所有适配器
esxcli storage core adapter rescan --all

# 重新扫描指定 HBA
esxcli storage core adapter rescan -A vmhba0

# 卸载 datastore
esxcli storage filesystem unmount -l <datastore_name>

# 关闭设备
esxcli storage core device set --state=off -d <naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

# 查看 FC HBA
esxcli storage san fc list

# 查看 FC 统计信息
esxcli storage san fc stats get

# 查看 iSCSI 适配器
esxcli iscsi adapter list

十、预防建议

APD / PDL 事故的重点不只在故障时处理，还在平时把风险降下来。

1. 存储链路冗余

生产环境不建议单 HBA、单交换机、单链路访问关键 datastore。

常见要求包括：

  • 双 HBA 或双端口网卡。
  • 双 SAN 交换机或独立 iSCSI 交换平面。
  • 多路径策略正确配置。
  • 主机、交换机、阵列端口分布在不同故障域。

2. 变更流程

LUN 删除、unpresent、zoning、masking、NFS 导出变更都应该有双人确认。

变更前至少确认：

  • datastore 是否仍被 ESXi 挂载。
  • 是否还有 VM 或模板。
  • 是否存在 RDM、ISO、备份任务引用。
  • 是否已完成备份或快照。
  • 是否所有主机已卸载。

3. 监控告警

建议至少监控：

  • datastore 可访问性。
  • HBA link 状态。
  • SAN 交换机端口错误计数。
  • iSCSI 网络丢包和 MTU。
  • NFS 服务端可用性。
  • vSAN Health 和对象合规性。

4. 演练和记录

APD / PDL 不是适合临场学习的故障。平时应该准备好：

  • 常用命令清单。
  • 主机到 HBA、交换机、阵列端口的映射表。
  • datastore 到 LUN / volume 的映射表。
  • HA/VMCP 当前配置截图。
  • 备份恢复流程和责任人。

总结

APD / PDL 都属于 vSphere 存储不可访问故障，但处理方法不能混用。

APD 的关键是恢复路径。它通常意味着 ESXi 暂时访问不到存储，先查链路、交换机、阵列和网络，确认上游恢复后再 rescan。

PDL 的关键是确认数据是否还能恢复。它通常意味着设备被判定为永久丢失，清理前必须先确认 LUN 是否被误删、是否还有快照或备份、是否还有业务引用。

生产环境里，最稳妥的排障顺序是：先保留现场，再判断类型，再恢复上游，最后清理残留。不要把所有“存储不可访问”都当成同一种故障处理。

参考资料

VMware vSphere 存储 故障排查