HCCL集合通信常见问题定位思路
发表于 2024/09/30
01 前言
HCCL（Huawei Collective Communication Library）是基于昇腾AI处理器的高性能集合通信库，提供单机多卡以及多机多卡间的集合通信能力，支持大模型的数据并行、模型并行、专家并行、pipeline并行、序列并行等多种加速方案。更详细的介绍，可参考以下博文：
· HCCL集合通信算法开发Hello World示例（超详细）
本文介绍了集合通信运行时的三个关键阶段，并介绍了这三个阶段对应的常见问题及定位思路。读者读完后，可以建立起对集群故障的基本认识。
02 集合通信问题定位难点
集群出现问题时，会停下来等故障点，并在到达超时时间后，关键的错误信息往往被庞大的错误日志“淹没”，这个现象是去中心化导致的，没有一个Rank能够有“上帝视角”感知远端没响应的原因是什么，因此我们集群问题定位的第一步就是基于现有信息尽快找到罪魁祸首的位置。HCCL本身也在持续演进DFX能力以应对集群规模增加、业务复杂度提高带来的一系列挑战。
03 了解集合通信运行的三个阶段
在正式介绍HCCL常见问题时，我们需先理解集合通信业务运行的三个关键阶段，每个阶段的常见问题和定位思路相对不同，读者定位问题时需要首先分辨这三个阶段。
04 通信域初始化阶段定位思路
4.1 业务逻辑
通信域初始化的主要过程是集群信息探测与协商，该过程会进行集群信息搜集和分发：
1）将调用HcclGetRootInfo的NPU作为Root Rank
2）其他所有Rank通过Host网卡与Root Rank进行TCP建链3）其他每个Rank将自身信息发送给Root Rank
4）Root Rank获取到集群所有Rank信息后，再分发给所有Rank；这样每个Rank都拿到了全量的集群信息
这个过程类似这样一个场景：一个新组建的班级，每位同学都不清楚其他同学的信息与联系方式；老师指定一位同学作为班长，收集了其他所有同学的信息并汇总成为通信簿；班长再把通信簿分发给大家。
如果用户已经提供了包含所有Rank的RankTable文件，通过RankTable文件初始化通信域可以省去集群信息探测协商阶段。
4.2 发生阶段
对于PyTorch、MindSpore msrun启动方式，一般在第一轮迭代完成之前。
4.3 定位思路
此阶段异常时，需要密切关注Root Rank打印的错误信息，信息会包含预期的建链数以及实际成功建链的Rank，我们可以以此寻找未按照预期与其建链的Rank，或者集群信息校验结果。对于其他Rank，则会打印建链超时(EI0006)，如果已经建链成功，由于Root未及时收集到全量的Rank信息并启动分发，会打印数据接收超时或者接收失败。
· 故障点1进程异常：某些业务进程由于各种各样的问题导致未走到和Root节点建链阶段，在发起建链请求前就已经异常退出或者卡死，Root节点未收到和通信域Ranknum匹配的建链请求，会上报建链超时错误（超时时间由HCCL_CONNECT_TIMEOUT调整）协商过程失败。需要注意的是，对于没有明显报错信息的业务进程，有可能是core dump或者卡死，需要分析其异常时的堆栈。
· 故障点2网卡配置异常：进入协商过程后需要使用Host网卡，如果指定Host网卡和端口有问题，也会导致失败。网卡配置错误、端口被抢占是引起这个阶段失败的常见原因（具体配置方式请参见HCCL_IF_IP、HCCL_IF_BASE_PORT、HCCL_SOCKET_IFNAME等环境变量）。
· 故障点3网络异常：网络异常比如某些节点和Root Rank所在节点的Host网卡连通性也可能存在问题，比如交换机上进行了错误的VLan配置。
· 故障点4集群信息校验失败：HCCL也提供了集群信息校验能力，以保证系统尽早发现并暴露问题。在Root Rank完成了所有Rank信息的收集后，会对集群信息进行校验，如果发现收集的Device Ip地址出现了重复，或者同时出现了IPV4/IPV6等情况，Root Rank会及时上报异常并打印校验结果。
5 算子加载阶段定位思路
5.1 业务逻辑
通信算子下发时Rank和Rank之间基于通信算法进行socket建链，通过socket交换彼此内存地址等关键信息，并建立起后续RoCE通信所需要的QP。
5.2 发生阶段
对于PyTorch、MindSpore单算子模式，此流程发生在通信域某类算子第一次被调用时，如第一个AllReduce或者第一个BroadCast，对于同一类算子也会基于算法选择策略变化而重新建链。对于图模式，则发生在每一个通信算子加载过程中。一般发生在第一轮迭代完成之前。
5.3 定位思路
此阶段相比通信域初始化阶段有两个变化点，一个是socket通信走的是NPU侧参数面网络，另外一个是Rank间是按照通信算法进行的两两间建链，无中心节点，无法再通过Root节点打印信息找到异常Rank。
建链超时是算子加载阶段最常见的故障，本阶段定位思路主要针对此类问题展开。需要注意的是，建链超时存在级联传递现象，当一个Rank出现问题或阻塞后，准备与它建链的邻居Rank会建链超时，这样又会导致与邻居Rank建链的其他Rank出现建链超时问题。
一般情况下，这个阶段的异常可以分为三大类：1）部分建链超时；2）全部建链超时；3）一致性校验异常。
· 部分建链超时：需要通过打印日志找到是否有Rank未出现以下行为：建链/P2P超时、recv fail(错误码EI0006)。出现建链超时的节点，一般是由对端异常导致，因此故障根节点一般出现在未出现建链超时的Rank。如果这些Rank有前置报错，则根据日志定位问题即可，如果无前置报错，则分析其进程是否同样存在卡住、coredump、提前退出等情况。
· 全部建链超时：如果通过日志筛查发现所有Rank均有超时报错，则最常见的原因为TLS证书配置不一致，可以通过对怀疑节点进行TLS证书状态查询来确认。如果证书均一致，也有可能是参数面网络连通性问题，可以基于网络检测平台进行诊断，也可以通过HCCN Tool工具对怀疑节点进行ping等操作进行确认。
· 一致性校验异常：HCCL提供了建链时校验彼此的算子参数信息、版本信息的能力，以此尽快发现拦截集群行为不一致的问题，防止后续一系列越界访问、精度异常等疑难问题的发生。因此如果在建链过程中发现了此类报错，请优先分析集群行为不一致的原因。需要注意的是，由于集群内信息校验依赖于Rank间建链，但一个算子在加载时，会复用之前已经建好的链，因此不是每一次算子加载都会进行建链，此机制无法拦截所有的一致性问题。
6 算子执行阶段定位思路
6.1 业务逻辑
通信算子执行时NPU和NPU之间基于通信算法通过RoCE或HCCS链路通信，进行参数数据传输。
6.2 发生阶段
此阶段发生在算子每次被调度执行时，一般在系统稳定运行阶段。
6.3 定位思路
在业务稳定运行时忽然中断，其他Rank长时间接收不到远端的预期同步信号，则会上报Notify Wait超时异常，超时时间由HCCL_EXEC_TIMEOUT环境变量配置。因此，一般认为没有上报Notify Wait超时异常的Rank为异常点；如果所有Rank均报了Notify Wait超时异常，则需要分析是否为网络问题或者某种原因导致的集群行为不一致。判断Rank是否发生了Notify Wait超时异常，可以通过错误码EI0002或者plog 是否打印“base info”进行区分，也可以通过MindX DL集群故障分析工具进行快速定位。
对于部分Rank超时场景，需要尽快找到没有上报超时的Rank。如果集群业务进程或者NPU存在异常导致部分Rank提前退出，调度框架一般会及时发现，根据日志定位原因。如果出现Rank未报错也未及时退出，则有可能是业务进程卡死，需要通过分析卡住时的运行时堆栈来分析原因。
对于全量Rank超时场景，最常见的原因为网络故障导致RoCE报文重传超次（时间和次数可以通过HCCL_RDMA_TIMEOUT、HCCL_RDMA_RETRY_CNT参数进行配置），可以通过查询故障管理框架包含时间的关键事件记录，比如网卡linkdown等；也可以根据重传超次（日志关键字error cqe）的通信两端IP，通过HCCN Tool的查询指令确认端侧网卡linkdown的历史记录。如果未发现网络问题，也可能是一致性问题，比如由于不同Rank上数据集切分不一致，导致在一次集合通信时，不同Rank调用了不同通信算子，这可能会引起同步信号互锁。对于这类问题，可以通过超时打印的算子信息或者atrace日志追溯算子下发历史记录，也可以基于故障时迭代轮次规律进行推测。
HCCL提供了执行阶段故障探测和集群扩散的能力，如果发现各类故障导致的业务进程提前退出、长时间卡住或者网络重传超次等事件，会在集群中进行扩散广播，超时时会打印出故障发生点的Server IP和Device Id，用户也可作为问题定位的参考。
7 获取更多学习资源
HCCL集合通信算法开发的相关介绍就到这里，欢迎大家关注手续技术分享。了解更多集合通信能力介绍，请访问昇腾社区HCCL信息专区：https://www.hiascend.com/hccl
相关博文推荐：
本页内容