平滑升级3.1实践"/>
小米Hadoop YARN平滑升级3.1实践
小米所有业务的离线和流式计算资源都是基于Hadoop YARN进行管理的。
随着业务快速发展,集群规模成倍增长,带来了单集群调度性能和跨机房部署等挑战。
为了更好地应对这些挑战,经过调研我们决定从2.6版本升级到3.1版本和社区保持同步,之后再基于社区在扩展性、性能等方面做的工作进行二次开发
往期文章回顾:小米Talos GC性能调优实践
背景
小米之前生产环境的Hadoop YARN是基于社区2.6版本修改的内部版本,我们最大规模集群已经数千台,而且还在不断增长。在目前2.6版本,我们主要面临两个问题:
滞后社区多个大版本, 很多新特性以及bug修复没法使用或者需要重新开发;
集群规模增长很快,经历了多次机房迁移,当前版本不能很好地支持跨机房部署方案来实现作业透明迁移;
我们调研3.1过程中发现,基于YARN Federation(YARN-2915)的跨机房部署方案已经很成熟。同时,为了和社区保持同步,减少代码的维护成本。我们决定升级到Hadoop 3.1(注:在我们开始调研的时候3.2还没release)。
在升级到Hadoop 3.1之后,我们会基于YARN Federation这个特性来落地跨机房部署方案。同时,在3.1版本我们会和社区一起推进落地基于公有云的Auto Scaling方案。
目标与挑战
小米Hadoop YARN在生产环境有数十个集群(包括国内和海外),服务于小米所有业务线,包含大量的批处理和流式计算作业(>10w/天)。本次升级到Hadoop 3.1希望能做到对业务透明,尽量减少对业务的影响:
升级期间,不需要停服;
升级期间历史作业不失败;
升级期间可以持续提交新作业;
升级期间,作业日志能够正常查看;
Hadoop YARN的架构组成包括ResourceManager(简写RM)、NodeManager(简写NM)、HistoryServer、ProxyServer等多个组件,这些组件之间需要进行RPC通信,如下图所示:
图1-Hadoop YARN各个组件通信
由于Hadoop YARN组件很多,集群规模也很大,为了控制风险,不能一次性把所有组件都升级到3.1版本。我们面临的挑战是在多个模块不同版本共存的时候,如何保障上层各类计算框架(Spark、Flink、MapReduce等)调度的作业不受影响。
升级过程
>>>>
patch合并/重构
之前我们内部一直维护的是基于社区2.6修改的内部版本,我们实现了很多patch来满足业务场景。为了升级到3.1版本,我们首先要做的就是把内部patch合并到社区的3.1版本。由于版本跨度很大,这一步我们做了大量的重构工作,这期间主要通过单元测试来保障代码质量。
我们内部的工作主要集中在以下几个方面:
稳定性优化,如基于ZK的client配置管理,实现了RM等服务的平滑迁移(YARN-9605),NM隔离优化(YARN-9977),HistoryServer稳定性优化(YARN-9973)等;
调度优化,如延时调度,缓存resource usage提升排序效率,事件处理优化(YARN-9979)等;
易用性优化,如支持MR作业查看实时jstack信息(YARN-10069),支持ui kill app,支持MySQL的StateStore等;
多集群管理和多租户管理,我们主要进行了资源管理服务产品化,提供统一的infra-client和web化的资源管理(支持计量计费等);
目前,这些工作已经陆续往社区提交,为我们后续升级版本减轻工作量,同时也希望我们的解决方案能给社区其他成员提供帮助。
>>>>
兼容性/回归测试
前面提到,我们patch合并重构期间主要是通过单元测试来保证代码质量。但是大量patch合并之后,我们必须对整体功能进行完整的回归测试。
同时,在图1中我们看到Hadoop YARN涉及的RPC通信模块很多,版本升级过程中,需要保证各个模块之间通信协议的兼容性。这里,重点讲一下我们如何进行兼容性测试的。
兼容性测试第一块是Hadoop本身各个服务模块之间的通信兼容,主要设计的case如图2所示:
图2-Hadoop YARN组件兼容性测试
当然,兼容性相关还有一个比较重要的测试就是针对计算框架的测试。这里我们主要针对内部使用的如下框架进行了测试:
Hive 1.2;
Hadoop MapReduce 2.6/3.1;
Spark 1.6/2.1/2.3;
Flink 1.8;
在测试过程,也需要考虑不同版本和不同部署模式的HDFS,比如我们内部有2.6的Federation集群和非Federation集群。另外,考虑到我们目前访问HBase的作业大部分是通过Spark实现,我们主要测试了Spark作业访问HBase的场景。
>>>>
调度器测试
小米之前使用的调度器是基于社区2.6版本修改的FairScheduler。在和社区交流过程发现,社区后续的发展方向主要在CapacityScheduler (YARN-5864),并且在Hadoop 3.x中CapacityScheduler对调度性能、资源利用率等方面进行了很多优化。所以在升级3.1之后我们有一个比较大的改动是从FairScheduler切换到CapacityScheduler。这里主要面临两个问题:
线上生产集群的FairScheduler相关队列配置已经使用了很长一段时间,需要平滑切换到CapacityScheduler;
我们的资源管理服务之前是针对FairScheduler设计的,需要对CapacityScheduler进行适配;
其中比较重要的是问题1,这个问题在社区会议的时候提出来了,之后社区也有相关issue跟进(YARN-9698)。我们内部的解决办法是把重要配置进行了梳理,实现一个工具基于FairScheduler的配置自动化地生成对应的CapacityScheduler配置。这里几个比较重要的配置提一下:
maximum-am-resource-percentuser-limit-factorintra-queue-preemption.disable_preemptiondisable_preemptionmaximum-capacity
其中user-limit-factor和maximum-am-resource-percent在FairScheduler语义不太一样或者是没有实现。我们针对调度器的测试主要是通过线上FairScheduler配置生成CapacityScheduler配置来启动测试RM,然后进行验证。目前,针对调度器的性能测试我们也探索了SLS工具。
针对CapacityScheduler我们提交了一些patch给社区:YARN-7621,YARN-9748,YARN-9709等。
>>>>
升级/回滚方案
经过上面的单元测试、兼容性测试、调度器测试之后,我们设计和演练了升级方案。最后确定的主要步骤如下:
准备好回归测试作业(包括Hive/MR/Spark等),作业类型包含基本的TeraSort、WordCount以及一些用户的作业
升级资源管理服务
支持同时更新FairScheduler和CapacityScheduler的配置,当CapacityScheduler出现问题的时候可以直接回滚到FairScheduler
升级控制节点(RM/HistoryServer/ProxyServer)
RM主节点使用3.1版本的CapacityScheduler,备节点使用2.6版本的FairScheduler,当调度出现问题的时候,可以做主备切换进行恢复
基于回归测试作业进行验证,同时确认日志查看、主备跳转是否正常
升级Hadoop客户端配置和包
升级测试机器,验证回归测试作业是否正常运行
升级监控机器,验证监控作业是否正常运行
分批逐步升级作业调度机器,观察用户作业是否正常运行
升级Hive到兼容3.1的版本
部署一个兼容3.1版本的Hive实例,然后验证回归作业和线上部分历史作业
分批逐步升级其他Hive实例,观察用户查询是否正常运行
分批升级NM(注:我们修改了2.6版本NM的recovery模块,支持直接从3.1回滚到2.6)
我们会按照5%->25%->50%->75%->100%的灰度策略对NM进行操作
每步更新都会对回归测试作业进行验证
在升级过程中,我们主要通过作业级别、队列级别、集群级别的监控报警来帮助我们及时发现问题。
问题&解决
在升级测试、演练和执行落地过程中,我们遇到一些问题:
>>>>
NM回滚2.6版本异常
测试回滚NM的时候,发现如下异常,主要是3.1版本的recovery相关状态多了很多字段
2019-xx-xx,17:06:12,797 FATAL org.apache.hadoop.yarn.server.nodemanager.NodeManager: Error starting NodeManagerorg.apache.hadoop.service.ServiceStateException: java.io.IOException: Unexpected container state key:ContainerManager/containers/container_e36_1558337587778_0027_01_000002/starttime
修复办法就是在2.6版本实现类似逻辑或者是直接兼容一下。
>>>>
MR RPC协议修改导致作业执行异常
Hadoop Mapreduce在3.1版本针对TaskUmbilicalProtocol做了一些改动,如果是2.6和3.1进行通信,会出现下面问题。这里解决办法是通过在client指定classpath保证单个作业依赖的版本是一致的。
2019-xx-xx 16:49:49,306 WARN [main] org.apache.hadoop.mapred.YarnChild: Exception running child : org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.ipc.RPC$VersionMismatch): Protocol org.apache.hadoop.mapred.TaskUmbilicalProtocol version mismatch. (client = 19, server = 21)
>>>>
FileOutputCommitter版本改变导致数据丢失
FileOutputCommitter在3.1版本增加了新的commit算法,并且默认是不写临时目录了。而在2.6版本,默认的commit算法是先写临时目录最后原子的move到最终输出目录。当NM版本是2.6和3.1共存的时候,我们遇到了Spark作业结果数据比预期少很多的问题。
解决办法很简单,先调整代码的默认算法:
mapred-default.xml:
<name>mapreduce.fileoutputcommitter.algorithm.version</name><value>1</value>
FileOutputCommitter:
public static final String FILEOUTPUTCOMMITTER_ALGORITHM_VERSION = "mapreduce.fileoutputcommitter.algorithm.version";public static final int FILEOUTPUTCOMMITTER_ALGORITHM_VERSION_DEFAULT = 1;
>>>>
日志配置文件不存在
3.1和2.6在生成launch container脚本的时候对于log目录的设置存在差异。
log4j:ERROR setFile(null,true) call failed.java.io.FileNotFoundException: /home/work/hdd3/yarn/c4prc-preview/nodemanager/application_1559618566050_0070/container_e18_1559618566050_0070_01_000001 (Is a directory)
>>>>
容量调度器配置不对
容量调度器对于<0,0>的配置是不识别的,并且会直接抛异常导致RM启动失败。
2019-06-25,16:07:19,266 FATAL org.apache.hadoop.yarn.server.resourcemanager.ResourceManager: Error starting ResourceManagerjava.lang.IllegalArgumentException: Parent queue 'root.production' and child queue 'root.production.xiaoqiang_group' should use either percentage based capacityconfiguration or absolute resource together for label
当然,还有很多其他问题这里没有展示。部分修复我们已经提交社区比如:(YARN-9693)、(YARN-9689),后续其他修复我们也会提交社区。
后续计划
2019年我们已经完成了国内外数十个集群的升级,2020年Q1我们会完成最后一个公共集群的升级。从成本和扩展性考虑,我们下一步会在如下几个方向继续探索:
落地Yarn Federation支持超大规模联邦集群,支持同城跨机房部署(>1w台);
在海外落地基于公有云的Auto Scaling方案(YARN-9548),系统化地优化公有云集群成本;
探索落地离在线混部的方案,打通在线/离线计算资源;
致谢
感谢计算平台SRE组同学以及存储团队HDFS同学在升级期间的给力支持!(目前我们存储团队也已经推进多个HDFS集群升级到了Hadoop 3.1,期待他们的分享)
关于我们
小米云平台计算平台团队,负责为小米集团各业务线提供高品质的弹性调度和计算服务。包括离线平台(Spark,Hadoop Yarn,Kylin,Doris等),流式平台(Kafka,Flink及自研Talos等),弹性平台(Docker,Kubernetes等)。 武汉团队主要负责Kylin、Druid等OLAP引擎开发。北京武汉均有职位,欢迎感兴趣的小伙伴加入~ 联系方式:computing-hr@xiaomi
参考
[1] FS Migration CS
[2] YARN Federation
[3] Migrating Hulu’s Hadoop Clusters to a New Data Center
[4] Hydra: a federated resource manager for data-center scale analytics
[5] Make YARN work well in elastic cloud environments
文末福利
评论区获赞数量最多的粉丝将获得小米90分双肩背包一个
我就知道你“在看”
更多推荐
小米Hadoop YARN平滑升级3.1实践
发布评论