CDH5之Balancer难以在快速增长的集群上平衡大量的数据

简介: 背景: 公司在线上使用了CDH5集群,一开始由于疏忽,忘记了在计划任务中定期执行Balancer来平衡各节点的数据。 后来,在引入大量的Job之后,数据增长非常迅猛,有很多节点开始出现利用率超过99.9%的情况,部分Job甚至开始Failed。

背景:
公司在线上使用了CDH5集群,一开始由于疏忽,忘记了在计划任务中定期执行Balancer来平衡各节点的数据。
后来,在引入大量的Job之后,数据增长非常迅猛,有很多节点开始出现利用率超过99.9%的情况,部分Job甚至开始Failed。

于是我们便执行Balancer来清理数据,结果发现有26T的数据需要平衡,而Balancer每次只移动50G的数据,并且耗时30分钟,而集群每个小时新写入的数据会导致又有40-60G的数据需要平衡。这样一来,Balancer就根本无法胜任了。

  1. 14/10/14 20:31:11 INFO balancer.Balancer: Need to move 26.49 TB to make the cluster balanced.
  2. 14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.10:50010 to 10.100.1.60:50010
  3. 14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.20:50010 to 10.100.1.70:50010
  4. 14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.30:50010 to 10.100.1.80:50010
  5. 14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.40:50010 to 10.100.1.90:50010
  6. 14/10/14 20:31:11 INFO balancer.Balancer: Decided to move 10 GB bytes from 10.100.1.50:50010 to 10.100.1.100:50010
  7. 14/10/14 20:31:11 INFO balancer.Balancer: Will move 50 GB in this iteration
  8. .........

解决办法:

1. 增加Balancer可操作的带宽

我们思考,是否是因为Balancer的默认带宽太小,所以效率低下,于是我们尝试将Balancer的带宽扩容到了500M/s:
     hadoop dfsadmin -setBalancerBandwidth 524288000
但问题并没有得到太大的改善。

2. 强行对节点进行Decommission

我们发现,当对一些节点进行Decommission操作时,上面的数据虽然有10-30T甚至更多,但总能在1天内全部Copy到其它的节点上,这里面由于默认集群副本数为3的原因,应该只有1/3的数据被复制了,但数据是完整的,并且被复制出去的数据也是平均分配到各个节点上的。那么我们何不使用它来作为一个类似Balancer的功能来解决一些磁盘用量超过99.9%的节点呢?
事实证明,这个方法非常可行,我们针对线上8个节点进行了Decommission操作(注意要尽量一台一台进行),在完成下线之后再立刻格式化数据磁盘,并重新添加回集群,新的数据也会非常快的平衡过来。比较完美的解决了之前头疼的问题,并且只花费了不到4天的时间。

3. Hadoop对LVM磁盘卷的支持问题

在解决Balancer的问题时,我们还发现,Hadoop对LVM磁盘卷的支持不是很好,表现在如果在一块磁盘上创建了逻辑卷/根分区等,再创建了逻辑卷/data1分区,Hadoop会一直将/data1写到100%,然后导致一些Job提示没有空间写入。我们猜想Hadoop应该是物理卷为单位来控制用量的。因此,我们不得不将这些包含了逻辑卷数据磁盘的主机重新安装,并分配单独的物理卷,如/dev/sda3作为/data1挂载,便再也没有以上问题。

目录
相关文章
|
API 容器 Kubernetes
当 K8s 集群达到万级规模,阿里巴巴如何解决系统各组件性能问题?
作者 | 阿里云容器平台高级技术专家 曾凡松(逐灵) 本文主要介绍阿里巴巴在大规模生产环境中落地 Kubernetes 的过程中,在集群规模上遇到的典型问题以及对应的解决方案,内容包含对 etcd、kube-apiserver、kube-controller 的若干性能及稳定性增强,这些关键的增强是阿里巴巴内部上万节点的 Kubernetes 集群能够平稳支撑 2019 年天猫 618 大促的关键所在。
|
4月前
|
负载均衡 前端开发 数据处理
"揭秘!ALB负载均衡器如何赋能Airflow,让数据处理命令请求在云端翩翩起舞,挑战性能极限,你不可不知的秘密!"
【8月更文挑战第20天】在现代云计算环境中,负载均衡ALB作为七层HTTP/HTTPS流量分发器,能显著提升系统的可用性和扩展性。结合Airflow这一开源工作流管理平台,ALB可以有效分发其REST API命令请求。通过配置ALB实例监听HTTP/S请求,并将多个Airflow实例加入目标组,再配合健康检查确保实例稳定,即可实现对Airflow命令的高效负载均衡,进而增强数据处理任务的可靠性和性能。
43 0
|
5月前
|
SQL UED
领域模式问题之大模型应用的规模成本增加如何解决
领域模式问题之大模型应用的规模成本增加如何解决
|
6月前
|
资源调度 算法 固态存储
在集群计算的时候,集群的主要瓶颈
在集群计算的时候,集群的主要瓶颈
|
7月前
|
存储 分布式计算 Hadoop
Hadoop集群规模扩展
【4月更文挑战第14天】Hadoop集群扩展可通过添加更多节点、垂直扩展(增强单节点资源)和水平扩展(增加节点数量)来实现。关键点包括规划扩展策略、确保集群稳定性和优化配置。注意在扩展过程中要保证数据完整性,并根据需求调整以提升集群性能和效率。
98 1
|
NoSQL Redis
通信开销:限制Redis Cluster规模的关键因素
通信开销:限制Redis Cluster规模的关键因素
151 0
|
缓存 负载均衡 安全
【可用性设计】 GCP 面向规模和高可用性的设计
【可用性设计】 GCP 面向规模和高可用性的设计
|
容灾 数据处理
ES高可用集群规模实战介绍
ES高可用集群规模实战介绍
1039 0
|
消息中间件 运维 算法
【kafka思考】最小成本的扩缩容副本设计方案
在这篇文章开始前,你需要先了解 【kafka源码】kafka分区副本的分配规则 从【kafka源码】kafka分区副本的分配规则 中我们已经知道了,如何分区副本是如何进行分配的 那么当我们想要批量进行副本扩缩的时候, 如果按照之前 --generate的重新计算分配方式来做的话, 那么这个数据迁移量是非常大的; 很有可能大部分的副本都有变动(牵一发而动全身) 那么我们有没有什么方式能够尽量减少这种变动吗, 根据这个目标,我们本篇文章就好好思考一下设计方案
【kafka思考】最小成本的扩缩容副本设计方案
|
存储 机器学习/深度学习 JSON
探究 | Elasticsearch集群规模和容量规划的底层逻辑
实战中经常遇到的问题: 问题 1:请问下大家是如何评估集群的规模?比如数据量达到百万,千万,亿万,分别需要什么级别的集群,这要怎么评估? ps:自己搭建的测试环境很难达到这一级别。
671 1
探究 | Elasticsearch集群规模和容量规划的底层逻辑