GPU故障可能由多种因素引起，包括硬件故障、驱动程序问题、GPU容器运行环境问题，应用问题等，不仅可能导致计算任务的性能下降，还可能造成业务应用的中断。本文提供全链路的、结构化的GPU故障诊断流程，以便您快速定位、解决问题。
在启用GPU故障诊断与恢复流程前，推荐您阅读常见GPU故障类型与解决方案，了解常见的GPU故障类型与推荐的解决方案。
GPU诊断与恢复全链路流程介绍
为了解决GPU故障，往往需要一套全面的故障诊断流程，以便快速定位和解决问题。流程如下。
故障诊断流程触发源：判断是什么触发了故障诊断流程。
故障诊断：通过日志分析、监控系统以及各种诊断工具，查看是否存在故障以及故障的具体表现，进一步定位原因。
故障隔离：将故障环节从正常工作流程中隔离出来，以免故障蔓延。
故障确认：经过初步诊断后，再次确认故障信息，确保故障的确存在且可以采取在该场景下采取对应的故障处理措施。
故障恢复：根据确定的故障原因，实施修复方案。
解除故障隔离：问题彻底解决后，将修复好的资源重新上线，恢复其原有的业务应用。
整个流程如下图所示。
步骤一：故障诊断流程触发源
故障诊断流程触发源包括Kubernetes Event机制、Prometheus监控机制、日常巡检机制、手动触发诊断、ECS事件触发、应用触发以及应用所属的Controller触发。
Kubernetes Event机制
Kubernetes事件（Event）是集群中发生事项的记录，可以是任何对象状态的改变，例如Pod的创建、删除、调度失败等。在Kubernetes GPU诊断与恢复场景中，常见的手段是借助Kubernetes ack-node-problem-detector组件实时检测GPU节点状态。当检测到GPU异常状态时，ack-node-problem-detector将上报一个GPU出现故障的Event，故障诊断与恢复系统会捕获到该事件，继而触发整个GPU故障诊断与恢复链路。关于如何在集群中启用事件监控，请参见事件监控。
Prometheus监控机制
Prometheus是一个开源的监控和告警工具，常用于记录实时的时间序列数据。在ACK集群中，Prometheus可以收集节点、Pod、容器等资源的各种指标，例如GPU使用率、内存占用率、硬件设备温度等。当检测到指标异常时，Prometheus可以触发告警，从而启动故障诊断流程。
ACK集群提供基于DCGM的GPU监控2.0能力，拥有全栈的GPU监控能力。关于如何启用GPU监控及相关的指标说明，请参见GPU监控2.0。
日常巡检机制
您可以在ACK集群启用日常巡检机制（集群巡检功能），制定日常巡检规则（例如每周日21：00检查集群节点GPU设备），以便当节点GPU状态异常时启动故障诊断与恢复流程。关于如何在ACK集群中启用集群巡检，请参见集群巡检。
手动触发诊断
某些场景下，如果您想诊断某个节点的GPU卡是否存在问题，可以手动触发故障诊断与恢复流程。具体操作，请参见自助诊断GPU节点问题。
ECS事件触发
某些场景下，ECS事件会报告GPU卡存在故障，需要通过重启节点来完成GPU卡的迁移。关于ECS事件的详细信息，请参见ECS系统事件概述。
应用触发
应用触发的故障诊断流程一般有三类。
日志：应用可能会记录详细的运行日志，如果检测到异常情况或错误，可以通过分析日志内容来触发故障诊断流程。
应用本身透出的监控指标：许多应用会暴露自身的性能指标，例如响应时间、处理速度等。如果这些指标出现异常，可以触发故障诊断流程。
应用本身的诊断工具：一些应用可能会内置诊断工具来监测自身状态。诊断工具检测到问题时会自动启动故障诊断流程。
应用所属的Controller触发
某些场景下，应用所属的Controller发现某些应用状态出现异常，会从应用层面触发一次完整的故障诊断与恢复流程。
步骤二：故障诊断
故障诊断是整个故障诊断与恢复链路图的关键环节。在ACK集群中，故障诊断的流程如下图所示。
硬件故障诊断
驱动故障诊断
容器化环境故障诊断
cGPU故障诊断
应用故障诊断
其他诊断系统（例如集群中安装了一个关于GPU错误日志的系统，接收应用错误日志后能够快速诊断故障根本原因）
系统会遵从由硬件底层向应用上层进行逐层诊断，其原因是上层的故障有可能是由底层的故障引起的。例如，当某个应用无法使用GPU资源时，有可能是底层GPU设备存在问题。这种由底层向上层推进的诊断流程能够在诊断上层问题时，避免底层故障的干扰。
步骤三：故障隔离
如果在故障诊断的流程中检测到故障，接下来需要进行故障隔离。故障隔离的流程如下图所示。
由上图可知，故障隔离可分为调度层隔离和应用层隔离。应用故障场景下，应用本身造成的故障不影响后续其他应用正常使用节点的GPU资源，因此无需进行调度层或应用层的隔离操作。
调度层隔离。可进一步分为：
节点隔离：通常是对节点执行
cordon操作。驱动故障、容器化环境故障、cGPU故障均会影响整个节点上GPU卡的使用，需要隔离整个节点。GPU卡隔离：通常是借助Device Plugin机制向kubelet重新上报健康的GPU卡的编号，忽略上报不健康的GPU卡号。在硬件故障中，如果单张GPU卡坏掉而不影响节点上其他GPU卡的使用，进行单GPU卡的隔离可以减少GPU资源浪费；如果单张GPU卡坏掉且同时影响节点上其他GPU卡的使用，则需要进行节点隔离。
应用层隔离：除调度层隔离外，某些场景下也需要对应用Controller进行隔离。
避免某些配置了“容忍所有污点”的应用再一次调度到故障节点上。
避免直接指定了节点或直接指定了GPU卡的应用调度到故障节点上。
在弹性训练场景中，应用Controller有可能终止该训练任务在当前故障节点上的其他Pod，然后再在其他节点上启动这些Pod，同时避免在故障和故障恢复期间有其他任务调度到故障节点上。
例如，在弹性训练的场景中，如果某个训练任务的某个Pod因为节点故障而重新拉起Pod，此时GPU节点的问题事件源会向训练任务Controller上报故障节点，使得Controller提前感知故障及相关事件，执行定向的缩容动作，从而完成对问题节点或设备的隔离。在节点故障期间以及在故障节点的修复期间，应用Controller可以避免需要反复迁移训练任务Pod。关于如何在ACK集群中部署弹性模型训练任务并进行训练任务的扩缩容，请参见Horovod弹性训练。
步骤四：故障确认
故障隔离操作完成后，还需要进一步确认该故障，以识别故障诊断可能存在的误报情况。
如果故障诊断的确为误报，请取消后续恢复流程。
如果故障诊断结果准确，请进一步根据自身业务场景评估，是否能在恢复流程中执行一些可能对业务产生影响的操作（例如重启节点）。
步骤五：故障恢复
确认故障的确需要进行恢复后，将进入故障恢复流程。流程如下图所示。
针对不同的故障类型，需要选择合适的恢复链路。
硬件故障、驱动故障或者cGPU故障：需要确保故障节点上没有使用GPU资源的应用，即在排空节点后再执行相应的恢复操作。但并不是所有类型的应用都支持排空节点的操作。以弹性训练任务场景为例，贸然排空节点的Pod可能会导致训练任务失败，例如可能无法正确保存任务的状态。所以在进行排空节点操作前，系统会通知应用Controller开始迁移节点上GPU应用的Pod，并在迁移完成时接收通知。
容器化环境故障：重新安装NVIDIA Container Toolkit或重启Device Plugin Pod，无需迁移节点上已运行的GPU应用。
应用故障：定位应用出现的问题并进行恢复。
步骤六：故障隔离解除
在故障恢复操作完成后，需要执行解除故障隔离的操作，保证故障节点或GPU卡能够正常上线使用，且业务应用平稳运行。