(可选)配置芯片故障频率及时长
在制作Ascend Device Plugin镜像时,会将faultCode.json和faultCustomization.json配置文件内置在镜像中,启动Ascend Device Plugin时会读取这两个文件的默认配置,作为当前故障处理依据。faultCode.json和faultCustomization.json的说明请参见配置文件说明。
如果用户想要自定义芯片故障频率及时长,可以在集群中创建ConfigMap文件(mindx-dl-fault-config)。
- 如果Ascend Device Plugin启动时,集群中已经存在mindx-dl-fault-config,Ascend Device Plugin会优先按照已存在的mindx-dl-fault-config中配置的内容,作为当前故障处理依据。
- 如果重新安装Ascend Device Plugin后,集群中已经存在mindx-dl-fault-config,Ascend Device Plugin的默认faultCustomization.json将不会生效,使用集群中已经存在的mindx-dl-fault-config。若想要使用faultCustomization.json的默认配置,可以删除mindx-dl-fault-config,使Ascend Device Plugin读取默认faultCustomization.json文件。
- 如果ConfigMap文件内容存在格式错误等问题,Ascend Device Plugin会默认读取镜像中内置的ConfigMap文件的内容,作为当前故障处理依据。
操作步骤
以故障码80CB8002为例,如果某张芯片反复发生80CB8002故障,导致训练业务反复重调度,可以手动配置24小时内任务支持的断点续训最大次数为2,达到最大次数后故障的处理策略为ManuallySeparateNPU。
- 登录环境,进入Ascend Device Plugin解压目录。
- 执行以下命令,查询是否已经基于faultCode.json文件创建了mindx-dl-fault-config。
- 执行以下命令,创建配置芯片故障频率及时长所需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文件名称保持一致。
- 执行以下命令,编辑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
- 在mindx-dl-fault-config文件中,在FaultFrequency字段下新增以下代码,设置0CB8002故障在24小时内任务支持的断点续训最大次数为2,达到最大次数后故障的处理策略为ManuallySeparateNPU。
{ "EventId": ["0CB8002"], "TimeWindow": 86400, "Times": 2, "FaultHandling": "ManuallySeparateNPU" }
- 修改完成后,按“Esc”键,输入:wq!保存并退出。
- 等mindx-dl-fault-config文件更新生效(PollInterval取值,不指定则为300s)后,查看操作是否成功。
- 执行以下命令,查询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
- 通过查询到的组件日志名称,查询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”,表示记录了一次频率故障发生时间,在频率窗口内,该卡的该故障记录次数达到频率故障触发次数以后,就会上报频率故障对应的故障级别。
- 执行以下命令,查询Ascend Device Plugin组件日志名称。
- (可选)手动恢复强制隔离的芯片。故障的处理策略为ManuallySeparateNPU时,故障恢复后该芯片也处于隔离状态,需要手动恢复强制隔离的芯片。
- 执行以下命令,查找该节点的Ascend Device Plugin上报的device-info-cm。
kubectl get cm -n kube-system | grep deviceinfo | grep {nodeName}
- 执行以下命令,编辑该device-info-cm。
kubectl edit cm -n kube-system {configMapName}
- 将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字段后所有芯片名称,并将取值设置为空“”。
- 修改完成后,按“Esc”键,输入:wq!保存并退出。
- 等待1个上报周期(若设备信息有变化,那么在健康状态检查周期内就会上报,如果设备信息没有变化,那么上报周期固定为5分钟)后,执行以下命令,查看device-info-cm中ManuallySeparateNPU是否存在刚才删除的芯片名称。若不存在,则芯片恢复健康成功,可继续正常使用该芯片。
kubectl describe cm -n kube-system {configMapName}
- 执行以下命令,查找该节点的Ascend Device Plugin上报的device-info-cm。