（可选）配置芯片故障频率及时长

操作步骤

以故障码80CB8002为例，如果某张芯片反复发生80CB8002故障，导致训练业务反复重调度，可以手动配置24小时内任务支持的断点续训最大次数为2，达到最大次数后故障的处理策略为ManuallySeparateNPU。

1. 登录环境，进入Ascend Device Plugin解压目录。
2. 执行以下命令，查询是否已经基于faultCode.json文件创建了mindx-dl-fault-config。

   kubectl describe cm -n kube-system mindx-dl-fault-config

   • 如果mindx-dl-fault-config已经存在，且存在faultCustomization.json的相关字段，执行4编辑该文件。
   • 如果mindx-dl-fault-config已经存在，但是不存在faultCustomization.json的相关字段，需要先保存mindx-dl-fault-config内容，再删除mindx-dl-fault-config文件后，执行3创建该文件。
   • 如果不存在mindx-dl-fault-config，执行3创建该文件。

3. 执行以下命令，创建配置芯片故障频率及时长所需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

   回显示例如下。

   1	configmap/mindx-dl-fault-config created

   表1 参数说明

   参数名	是否必选	说明
   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. 执行以下命令，编辑mindx-dl-fault-config文件。

   kubectl edit cm -n kube-system mindx-dl-fault-config

   根据实际情况，修改芯片的故障频率和时长。

   # Please edit the object below. Lines beginning with a '#' will be ignored,
   # and an empty file will abort the edit. If an error occurs while saving this file will be
   # reopened with the relevant failures.
   #
   apiVersion: v1
   data:
   PollInterval: "300"
   # 修改芯片故障的故障级别
   faultCode.json: |
   {
   "NotHandleFaultCodes":[
   ...
   }
   # 修改芯片故障的故障频率和时长
   faultCustomization.json: |
   {
     "GraceTolerance": {
       "WaitProcessReadCMTime": 30,
       "WaitDeviceResetTime": 150,
       "WaitFaultSelfHealingTime": 15
   },
     "FaultFrequency": [
   {
       "EventId": [
         "80C98000","80B78000","80B58000","80A18008","80A38008","80A58008","80B98000","80B98008","80BB8000",
         "80BB8008","80BD8000","80BD8008","80C78008","80C98008","80CB8008","80CD8008","80CF8008","80D98008",
         "80DF8008","80DE1801","80E01801","80E18008","80E38008","80E39200","80E3A202","80E3A203","80E78000",
         "80E78008","80F18000","80F18008","80F38008","80F78008","81318008","81338008","813B8008","81478008",
         "81578008","815F8008","81938008","81958008","81978008"
   ],
       "TimeWindow": 86400,
       "Times": 2,
       "FaultHandling": "ManuallySeparateNPU"
   },
   {
   "EventId": ["80E18005"],
   "TimeWindow": 86400,
   "Times": 3,
   "FaultHandling": "ManuallySeparateNPU"
   }
   ],
     "FaultDuration": [
   {
       "EventId": ["81078603"],
       "FaultTimeout": 20,
       "RecoverTimeout": 60,
       "FaultHandling": "PreSeparateNPU"
   }
   ]
   }
   kind: ConfigMap
   metadata:
   creationTimestamp: "2024-06-20T10:12:07Z"
   name: mindx-dl-fault-config
   namespace: kube-system
   resourceVersion: "52893696"
   selfLink: /api/v1/namespaces/kube-system/configmaps/mindx-dl-fault-config
   uid: bba9e17f-41dd-43b3-848e-3d29cb8c595a

   表2 faultCustomization.json文件参数说明

   一级参数名称	二级参数名称	说明
   GraceTolerance	-	优雅容错相关配置。 说明： GraceTolerance及其子参数不存在或者超出取值范围，则使用默认值。
   -	WaitProcessReadCMTime	使用优雅容错模式时，等待管理进程读取ConfigMap文件的时间，单位为秒，取值范围为5~90，默认值为30。
   -	WaitDeviceResetTime	使用优雅容错模式时，等待芯片重启的最大时长，单位为秒，取值范围为60~180，默认值为150。
   -	WaitFaultSelfHealingTime	使用优雅容错模式时，等待RestartBusiness级别故障恢复时间，单位为秒，取值范围为1~30，默认值为15。
   FaultFrequency	-	自定义故障频率，即某一故障在时间窗口内出现次数达到次数上限时，根据配置的故障处理策略进行处理。 说明： FaultFrequency及其子参数取值范围不正确，则忽略该条配置。 FaultFrequency及其子参数数据格式不正确，则会使用默认配置。
   -	EventId	故障码ID。 说明： 每个故障码（EventId）只允许配置一个FaultFrequency参数，如果配置了多个，则只有第一条正确的会生效。
   -	TimeWindow	时间窗口，即统计当前时间减去TimeWindow的时间至当前时间，这段时间范围内的故障次数，单位为秒，取值范围为60~864000。
   -	Times	任务支持的断点续训最大次数，即同一个故障出现的次数上限，取值范围为1~100。如果在时间窗口内该故障出现次数大于或等于该值，则按照FaultHandling中定义的策略处理和上报。
   -	FaultHandling	达到断点续训最大次数后故障的处理策略，支持配置不同级别的故障处理策略。 说明： PreSeparateNPU：大模型的故障处理策略。该故障处理模式为预隔离芯片，根据训练任务实际运行情况判断是否重调度。 ManuallySeparateNPU：需人工干预的故障处理策略。 出现该策略时，将直接上报K8s该芯片不健康并将芯片名字写入中device-info-cm中。 芯片名称只要保存于该字段中，即使故障恢复也仍然隔离芯片，直到运维人员手动在该字段中删除芯片名称。可以参见步骤8进行处理。 该字段只允许Ascend Device Plugin新增或修改，维护人员只能删除该字段中的芯片名称。 faultCode.json暂不支持该策略。
   FaultDuration	-	自定义故障超时策略，当某一故障持续时间达到配置上限时，该故障会按照指定的故障处理策略进行处理。 说明： FaultDuration及其子参数取值范围不正确，则忽略该条配置。 FaultDuration及其子参数数据格式不正确，则会使用默认配置。
   -	EventId	故障ID。 说明： 每个故障码（EventId）只允许配置一个FaultDuration参数，如果配置了多个，则只有第一条正确的会生效。
   -	FaultTimeout	故障持续时间超过该值，则按照FaultHandling中定义的故障处理策略进行处理，单位为秒，取值范围为0~600，默认值说明如下。 故障ID为81078603的参数面网络故障默认值为20。 其余故障默认值为0。
   -	RecoverTimeout	故障恢复时间超过该值，则上报故障恢复，单位为秒，取值范围为0~86400，默认值说明如下。 故障ID为81078603的参数面网络故障默认值为60。 其余故障默认值为0。
   -	FaultHandling	超过故障持续时间后的故障处理策略，支持配置不同级别的故障处理策略。 说明： 超过故障持续时间后的故障处理策略，建议高于故障本身的故障处理策略，否则配置不生效。
   注 如果一个故障码同时配置了故障频率（FaultFrequency）和故障超时策略（FaultDuration），该故障码在TimeWindow时间窗口中超时次数达到任务支持的最大次数，则取故障本身的故障处理策略、FaultFrequency或FaultDuration中配置的故障处理策略中最严重的情况进行处理。 如果一个故障码同时配置了故障频率和故障超时策略，只有当故障超时后，故障频次才会增加一次。 故障ID为81078603的网络故障只支持配置为NotHandleFault、PreSeparateNPU或SeparateNPU三种故障处理策略，若配置为其他策略则使用默认配置NotHandleFault。

5. 在mindx-dl-fault-config文件中，在FaultFrequency字段下新增以下代码，设置0CB8002故障在24小时内任务支持的断点续训最大次数为2，达到最大次数后故障的处理策略为ManuallySeparateNPU。

   {
     "EventId": ["0CB8002"],
     "TimeWindow": 86400,
     "Times": 2,      
     "FaultHandling": "ManuallySeparateNPU"
   }

6. 修改完成后，按“Esc”键，输入:wq!保存并退出。
7. 等mindx-dl-fault-config文件更新生效（PollInterval取值，不指定则为300s）后，查看操作是否成功。
   1. 执行以下命令，查询Ascend Device Plugin组件日志名称。

      kubectl get pods -A | grep ascend-device-plugin

      回显示例如下：

      1	kube-system ascend-device-plugin-daemonset-910-jmlf5 1/1 Running 0 6h34m

   2. 通过查询到的组件日志名称，查询Ascend Device Plugin的组件日志信息。

      kubectl logs -n kube-system ascend-device-plugin-daemonset-910-jmlf5

      

      • 若日志出现“load fault customization from configmap complete”，表示手动配置故障频率操作成功。
      • 若日志出现“modify xxx success”，表示ConfigMap中faultCustomization.json里的xxx参数设置成功。
      • 若日志出现“insert fault frequency success”，表示记录了一次频率故障发生时间，在频率窗口内，该卡的该故障记录次数达到频率故障触发次数以后，就会上报频率故障对应的故障级别。

8. （可选）手动恢复强制隔离的芯片。故障的处理策略为ManuallySeparateNPU时，故障恢复后该芯片也处于隔离状态，需要手动恢复强制隔离的芯片。
   1. 执行以下命令，查找该节点的Ascend Device Plugin上报的device-info-cm。

      kubectl get cm -n kube-system | grep deviceinfo | grep {nodeName}

   2. 执行以下命令，编辑该device-info-cm。

      kubectl edit cm -n kube-system {configMapName}

   3. 将data下面的ManuallySeparateNPU后面已恢复健康的芯片名称删除。

      apiVersion: v1
      kind: ConfigMap
      data:
        DeviceInfoCfg: '{"DeviceInfo":{"DeviceList":{"huawei.com/Ascend910":"Ascend910-1,Ascend910-2,Ascend910-3,Ascend910-4,Ascend910-5,Ascend910-6,Ascend910-7","huawei.com/Ascend910-Fault":"[]","huawei.com/Ascend910-NetworkUnhealthy":"","huawei.com/Ascend910-Unhealthy":""},"UpdateTime":1718702470},"CheckCode":"4f00cf1d220da26a8fdbeb5ba163a751d4b264c48b81d22149257e272ae3b413"}'
        ManuallySeparateNPU: Ascend910-0  

      

      删除ManuallySeparateNPU字段后所有芯片名称，并将取值设置为空“”。

   4. 修改完成后，按“Esc”键，输入:wq!保存并退出。
   5. 等待1个上报周期（默认为5s）后，执行以下命令，查看device-info-cm中ManuallySeparateNPU是否存在刚才删除的芯片名称。若不存在，则芯片恢复健康成功，可继续正常使用该芯片。

      kubectl describe cm -n kube-system {configMapName}