（可选）动态配置故障级别
断点续训针对芯片故障中的不同级别故障进行分级容错处理。MindCluster Ascend Device Plugin发现故障时会获取到当前故障的故障码，每个故障对应的故障码可参考《Atlas A2 中心推理和训练硬件 健康管理故障定义》和《Atlas A2 中心推理和训练硬件 黑匣子错误码信息列表》。
故障处理级别及类型
MindCluster Ascend Device Plugin从驱动获取到芯片故障码后，将根据故障码对设备及业务的影响将故障划分为以下六种级别，详细说明请参见表1。
故障级别 |
故障类型 |
说明 |
重调度处理 |
优雅容错处理 |
|---|---|---|---|---|
L1 |
NotHandleFault |
对业务无影响的故障，无需处理 |
暂不处理 |
暂不处理 |
L2 |
RestartRequest |
影响业务执行，需要重新执行业务请求 |
隔离设备，进行任务重调度 |
推理场景重执行推理请求，训练场景重新执行训练业务 |
L3 |
RestartBusiness |
影响业务执行，需要重新执行业务 |
重新执行业务 |
|
L4 |
FreeRestartNPU |
影响业务执行，待芯片空闲时需复位芯片 |
复位芯片后重新执行业务 |
|
L5 |
RestartNPU |
影响业务执行，需立即复位芯片 |
||
L6 |
SeparateNPU |
无法恢复，需要隔离设备 |
隔离设备，进行任务重调度 |
- 复位芯片前需要停止训练进程，否则复位将失败。
- 若MindCluster Ascend Device Plugin通过订阅的方式收到了无法识别的故障码（未保存在faultCode.json中），默认按照订阅接口给的处理意见进行故障处理。若订阅接口收到的故障等级为“提示”或“次要”，则按照L1级别处理；若故障等级为其他等级，则按照L6级别处理。
集群调度组件支持的故障码对应的故障类型可以参见MindCluster Ascend Device Plugin组件配置文件faultCode.json；该文件为系统配置文件，若用户无特殊需求，请勿随意修改。若用户需要修改故障码的故障级别，可以通过修改faultCode.json文件实现，操作指导请参见重调度模式或优雅容错模式。
重调度模式
以故障名称dmp_daemon心跳检测异常，对应故障码8C0A4E00为例。将当前故障的处理级别L1（无需处理）修改为L5级别（隔离设备，进行任务重调度）的操作示例如下。
重调度模式L2~L6级别的故障处理方式相同，都是隔离设备，进行任务重调度。
- 登录环境，进入MindCluster Ascend Device Plugin解压目录。
- 执行以下命令，创建动态配置故障码所需ConfigMap文件（mindx-dl-fault-config）。
kubectl create cm mindx-dl-fault-config -n kube-system --from-literal="PollInterval=300" --from-file=./faultCode.json
回显示例如下。configmap/mindx-dl-fault-config created
表2 参数说明 参数名
是否必选
说明
mindx-dl-fault-config
是
动态配置故障码所需的ConfigMap文件名称。
kube-system
是
mindx-dl-fault-config所在命令空间。
PollInterval
否
不指定该参数则默认取值为300s。用于指定查询mindx-dl-fault-config文件是否更新的周期时间，单位为秒，取值范围为30~3600。PollInterval的修改将在下一个周期生效。
faultCode.json
是
用于保存故障码，必须与faultCode.json文件名称保持一致。
- 执行以下命令，编辑mindx-dl-fault-config文件。
kubectl edit cm -n kube-system mindx-dl-fault-config
- 在mindx-dl-fault-config文件中，找到故障码8C0A4E00。
"NotHandleFaultCodes":[ "8C0A4E00","80E20207","80E21007","80E38003","80F78006","80C98006","80CB8006","81318006","80A18006","80A18005", ... ], ... - 将故障码8C0A4E00在L1（NotHandleFaultCodes）中删除，并添加到L5（RestartNPUCodes）中。
"NotHandleFaultCodes":[ "80E20207","80E21007","80E38003","80F78006","80C98006","80CB8006","81318006","80A18006","80A18005", ... ], ... "RestartNPUCodes":[ "8C03A000","8C1FA006","8C2FA001","40F84E00","80E24E00","80E21E01","80E38008","80E3A202","80E3A203","80E39200","8C0A4E00", ... ... ], - 修改完成后，按“Esc”键，输入:wq!保存并退出。
- 等mindx-dl-fault-config文件更新生效（PollInterval取值，不指定则为300s）后，依次执行以下命令，查询MindCluster Ascend Device Plugin组件日志。
cd /var/log/mindx-dl/devicePlugin vi devicePlugin.log
- 若日志出现“handling 'mindx-dl-fault-config' configmap change succeed”，表示动态配置故障码操作成功。
- 若日志出现“handling 'mindx-dl-fault-config' configmap change failed”，表示配置失败，用户可根据MindCluster Ascend Device Plugin日志提示进一步定位失败原因。
- 登录环境，进入MindCluster Ascend Device Plugin解压目录。
- 执行以下命令，创建动态配置故障码所需ConfigMap文件（mindx-dl-fault-config）。
kubectl create cm mindx-dl-fault-config -n kube-system --from-literal="PollInterval=300" --from-file=./faultCode.json --from-file=./faultCustomization.json
回显示例如下。configmap/mindx-dl-fault-config created
表3 参数说明 参数名
是否必选
说明
mindx-dl-fault-config
是
动态配置故障码所需的ConfigMap文件名称。
kube-system
是
mindx-dl-fault-config所在命令空间。
PollInterval
否
不指定该参数则默认取值为300s。用于指定查询mindx-dl-fault-config文件是否更新的周期时间，单位为秒，取值范围为30~3600。PollInterval的修改将在下一个周期生效。
faultCode.json
是
用于保存故障码，必须与faultCode.json文件名称保持一致。
faultCustomization.json
否
用于自定义优雅容错时间、故障频率、故障持续时间（仅支持参数面网络故障）等配置，不指定该参数则没有故障频率配置，其余配置使用默认值进行处理。必须与faultCustomization.json文件名称保持一致；该文件的参数说明请参见表4。
表4 faultCustomization.json文件参数说明 一级参数名称
二级参数名称
说明
GraceTolerance
-
优雅容错相关配置。
-
WaitFlushingCMTime
使用优雅容错模式时，等待杀死训练进程以及等待训练容器中同步Reset-Info ConfigMap信息的总时长，单位为秒，取值范围为90~300，默认值为90。
-
WaitDeviceResetTime
使用优雅容错模式时，等待芯片重启的最大时长，单位为秒，取值范围为60~120，默认值为60。
FaultFrequency
-
自定义配置故障频率，即某一故障在时间窗口内出现次数达到次数上限时，会上报一次指定的故障等级。
-
EventId
故障ID。
-
TimeWindow
时间窗口，即统计当前时间减去TimeWindow的时间至当前时间，这段时间范围内的故障次数，单位为秒，取值范围为60~864000。
-
Times
同一个故障出现的次数上限，取值范围为2~100。如果在时间窗口内该故障出现次数大于或等于该值，则按照FaultHandling中定义的策略处理和上报。
-
FaultHandling
故障级别对应的故障处理策略，支持配置L1~L6级别故障的处理策略，同时还支持配置PreSeparateNPU以及ManuallySeparateNPU故障处理策略。
说明：- PreSeparateNPU：大模型的故障处理策略。该故障处理模式为预隔离芯片，根据训练任务实际运行情况判断是否重调度。
- ManuallySeparateNPU：需人工干预的故障处理策略。
- 出现该策略时，将直接上报K8s该芯片不健康并将芯片名字写入中Device-Info ConfigMap中。
- 芯片名称只要保存于该字段中，即使故障恢复也仍然隔离芯片，直到运维人员手动在该字段中删除芯片名称。
- 该字段只允许MindCluster Ascend Device Plugin新增或修改，维护人员只能删除该字段中的芯片名称。
- faultCode.json暂不支持该策略。
FaultDuration
-
自定义配置故障持续时间，当前只支持参数面网络故障。
-
EventId
只能是故障ID为81078603的参数面网络故障，其他故障类型会被忽略。
-
FaultTimeout
故障持续时间超过该值，则按照FaultHandling中定义的策略处理和上报，单位为秒，取值范围为1~30，默认值为MindCluster Ascend Device Plugin启动yaml中的linkdownTimeout字段取值。
-
RecoverTimeout
故障恢复时间超过该值，则上报故障恢复，单位为秒，取值范围为1~60，默认值为60。
-
FaultHandling
故障处理策略，当前支持的参数面网络故障中，该字段只按照PreSeparateNPU策略处理，其他策略无效且也按照PreSeparateNPU策略处理。
注：
- GraceTolerance及其子参数和FaultDuration及其子参数不存在或者超出取值范围，则使用默认值。
- FaultFrequency及其子参数若存在格式错误或取值范围不正确，则忽略该条配置。
- 每个故障码（EventId）只允许配置一个FaultFrequency参数，如果配置了多个，则只有第一条正确的会生效。
- 执行以下命令，编辑mindx-dl-fault-config文件。
kubectl edit cm -n kube-system mindx-dl-fault-config
- 在mindx-dl-fault-config文件中，找到故障码8C204E00。
... "RestartBusinessCodes":[ "8C084E00","8C204E00","8C124E00","A8028802","A4302003","A4302004","A4302005","A4302006","A4302009","A430200A", ... ], ... - 将故障码8C204E00在L3（RestartBusinessCodes）中删除，并添加到L5（RestartNPUCodes）中。
... "RestartBusinessCodes":[ "8C084E00","8C124E00","A8028802","A4302003","A4302004","A4302005","A4302006","A4302009","A430200A", ... ], ... "RestartNPUCodes":[ "8C03A000","8C1FA006","8C2FA001","40F84E00","80E24E00","80E21E01","80E38008","80E3A202","80E3A203","80E39200", "8C204E00", ... ... ], ... - （可选）在mindx-dl-fault-config文件中，根据实际需求修改由faultCustomization.json文件创建的相关参数取值；不修改则使用默认值进行处理。
- 修改完成后，按“Esc”键，输入:wq!保存并退出。
- 等mindx-dl-fault-config文件更新生效（PollInterval取值，不指定则为300s）后，依次执行以下命令，查询MindCluster Ascend Device Plugin组件日志。
cd /var/log/mindx-dl/devicePlugin vi devicePlugin.log
- 若日志出现“handling 'mindx-dl-fault-config' configmap change succeed”，表示动态配置故障码操作成功。
- 若日志出现“handling 'mindx-dl-fault-config' configmap change failed”，表示配置失败，用户可根据MindCluster Ascend Device Plugin日志提示进一步定位失败原因。