Hadoop運維筆記之Balancer難以在快速增長的集群上平衡大量的數(shù)

背景： 公司在線上使用了CDH5集群，一開始由于疏忽，忘記了在計劃任務(wù)中定期執(zhí)行Balancer來平衡各節(jié)點的數(shù)據(jù)。 后來，在引入大量的Job之后，數(shù)據(jù)增長非常迅猛，有很多節(jié)點開始出現(xiàn)利用率超過99.9%的情況，部分Job甚至開始Failed。 于是我們便執(zhí)行Balancer來

背景：
公司在線上使用了CDH5集群，一開始由于疏忽，忘記了在計劃任務(wù)中定期執(zhí)行Balancer來平衡各節(jié)點的數(shù)據(jù)。
后來，在引入大量的Job之后，數(shù)據(jù)增長非常迅猛，有很多節(jié)點開始出現(xiàn)利用率超過99.9%的情況，部分Job甚至開始Failed。

于是我們便執(zhí)行Balancer來清理數(shù)據(jù)，結(jié)果發(fā)現(xiàn)有26T的數(shù)據(jù)需要平衡，而Balancer每次只移動50G的數(shù)據(jù)，并且耗時30分鐘，而集群每個小時新寫入的數(shù)據(jù)會導(dǎo)致又有40-60G的數(shù)據(jù)需要平衡。這樣一來，Balancer就根本無法勝任了。

14/10/14 20:31:11 INFO balancer.Balancer: Need to move 26.49 TB to make the cluster balanced.
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
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
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
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
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
14/10/14 20:31:11 INFO balancer.Balancer: Will move 50 GB in this iteration
...

解決辦法：
1. 增加Balancer可操作的帶寬
我們思考，是否是因為Balancer的默認帶寬太小，所以效率低下，于是我們嘗試將Balancer的帶寬擴容到了500M/s：

hadoop dfsadmin -setBalancerBandwidth 524288000

但問題并沒有得到太大的改善。

2. 強行對節(jié)點進行Decommission
我們發(fā)現(xiàn)，當(dāng)對一些節(jié)點進行Decommission操作時，上面的數(shù)據(jù)雖然有10-30T甚至更多，但總能在1天內(nèi)全部Copy到其它的節(jié)點上，這里面由于默認集群副本數(shù)為3的原因，應(yīng)該只有1/3的數(shù)據(jù)被復(fù)制了，但數(shù)據(jù)是完整的，并且被復(fù)制出去的數(shù)據(jù)也是平均分配到各個節(jié)點上的。那么我們何不使用它來作為一個類似Balancer的功能來解決一些磁盤用量超過99.9%的節(jié)點呢？
事實證明，這個方法非常可行，我們針對線上8個節(jié)點進行了Decommission操作（注意要盡量一臺一臺進行），在完成下線之后再立刻格式化數(shù)據(jù)磁盤，并重新添加回集群，新的數(shù)據(jù)也會非常快的平衡過來。比較完美的解決了之前頭疼的問題，并且只花費了不到4天的時間。

3. Hadoop對LVM磁盤卷的支持問題
在解決Balancer的問題時，我們還發(fā)現(xiàn)，Hadoop對LVM磁盤卷的支持不是很好，表現(xiàn)在如果在一塊磁盤上創(chuàng)建了邏輯卷/根分區(qū)等，再創(chuàng)建了邏輯卷/data1分區(qū)，Hadoop會一直將/data1寫到100%，然后導(dǎo)致一些Job提示沒有空間寫入。我們猜想Hadoop應(yīng)該是物理卷為單位來控制用量的。因此，我們不得不將這些包含了邏輯卷數(shù)據(jù)磁盤的主機重新安裝，并分配單獨的物理卷，如/dev/sda3作為/data1掛載，便再也沒有以上問題。

原文地址：Hadoop運維筆記 之 Balancer難以在快速增長的集群上平衡大量的數(shù)據(jù), 感謝原作者分享。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com