前言
为了不影响业务的正常运行,hdfs balancer的默认参数都比较小(宽带,并发等),在集群规模比较大,数据不均衡情况比较严重时(例如:上线大量新节点),使用hdfs balancer无法快速缓解问题,极端情况下,会导致很多节点存储用满,严重影响集群稳定性,且hadoop的一些小版本的balancer都存在一定的bug, 本篇文章主要分享下关于hadoop balancer的一些优化经验。
基本优化
集群使用版本:hadoop-2.7.1 & hadoop-2.7.2
1. 优化拷贝带宽(带宽的设置是影响datanode,设置单个datanode的balance带宽上限):
可通过动态命令进行设置, 设置完成后重新启动balancer任务即可。
dfs dfsadmin -setBalancerBandwidth 50000000
Balancer bandwidth is set to 50000000 for nn.host1/ip1:8020
Balancer bandwidth is set to 50000000 for nn.host2/ip2:8020
2. 加大每台datanode的并行拷贝数:
无法进行动态设置,需要调整配置后重启balancer和datanode进程;
在balancer启动机器hdfs-site.xml中修改配置:dfs.datanode.balance.max.concurrent.moves 默认为5。同时需要修改source机器的该属性,否则会报异常,并且不生效。
3. 适当加大MAX_SIZE_TO_MOVE,使每次迭代中datanode拷贝更多的数据。默认是10GB
final private static long MAX_SIZE_TO_MOVE = 10*1024*1024*1024L; //10GB
优化代码(修复逻辑)
1. 一些特殊场景, 只需要copy存储高的节点到新扩容的节点时,需要优化chooseNodes函数中选择source和dest的规则
若有机器磁盘使用率很高,则只拷贝over的。
若有新加入的机器,则只向under拷贝。
2. 针对balancer的功能合并社区patch,解决一些导致慢的bug,或者一些优化策略
优化:
https://issues.apache.org/jira/browse/HDFS-10297 :Increase default balance bandwidth and concurrent moves
https://issues.apache.org/jira/browse/HDFS-8818 :Allow Balancer to run faster
修复逻辑bug:
https://issues.apache.org/jira/browse/HDFS-10966 : Enhance Dispatcher logic on deciding when to give up a source DataNode
说明:在HDFS-10966之前,原有逻辑存在严重的 bug,由于datanode用于balancer copy并发的限制,会导致每批次只balancer了少量的数据, HDFS-10966加入了时间判断逻辑,能够保证把本批计划的数据copy完成。