YARN 在字节跳动的优化与实践( 三 ) _YARN

2.2.3 训练场景下的其它定制

文章插图

对于训练场景，我们还定制了更丰富的内容。包括：

为了更好的隔离性，定制了支持 GPU 和 Ceph 的 Docker
为了更灵活的资源申请，定制了带范围的资源值 (传统的 YARN 资源只有个数, 没有范围，比如多少个 CPU ，多少 GB 内存，但在训练场景下，有时希望有范围，比如当需要两个 GPU 卡时，不止希望随意的两张卡，而是希望要一台机器上两个连号的 GPU 卡，比如卡 0 和卡 1 是连号的，而卡 0 和卡 2 不是连号的。这个场景同样也适用于端口号。)
为了更高效的同时使用 CPU 和 GPU 机器，定制了节点属性功能。

2.2.4 跳过高 Load 节点

文章插图

离线批处理场景经常会遇到"Fetch Failed"的问题，主要来源是本地的磁盘 IOPS 不足，导致 Shuffle Service 卡住，为了缓解这个问题，我们在资源调度的过程中加入目标主机 LoadAvg 的考虑因素，如果一台机器的 LoadAvg 过高，则暂时跳过对其分配新任务. 通过这个机制，将"Fetch Failed"问题降低了约 40% 。
2.3 稳定性优化

文章插图

字节跳动的 YARN 服务规模巨大，在稳定性方面遇到了很多挑战，有很多细节方面的优化, 在这里由于时间有限，挑选几个比较有代表性的优化点跟大家分享一下：

将 HDFS 做成弱依赖对于一般的离线批处理来说，如果 HDFS 服务不可用了，那么 YARN 也没必要继续运行了。但是在字节跳动内部由于 YARN 还同时承载流式作业和模型训练，因此不能容忍 HDFS 故障影响到 YARN 。为此，我们通过将 NodeLabel 存储到 ZK 中，将 Container Log 在 HDFS 的目录初始化和上传都改为异步的方式，摆脱了对 HDFS 的强依赖。
Container 分级与驱逐某些 Container 的磁盘空间占用过高，或者将单机 Load 打得非常高，会比较严重的影响到其它 Container 的正常运行，为此，我们为 YARN 定制了 Container 分级与驱逐机制。对于可能会严重影响到其它 Container 的 Container 会进行主动驱逐。对于被驱逐的作业，可申请到独立的 Label 中运行。
非受控 Container 的清理机制由于种种原因，线上总是会出现一些 Container 明明还在运行，但是已经不受 YARN 的管控。通常是由于不正常的运维操作产生，或者机器本身出现故障导致。对于这些 Container 如果不加管制，不仅会让单机的实际资源紧张，有时还会造成 Kafka Topic 的重复消费导致线上事故。为此我们在 YARN 的 NodeManager 中增加了非受控 Container 的清理机制。

2.4 异地多活