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

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

于是我們便執行Balancer來清理數據，結果發現有26T的數據需要平衡，而Balancer每次只移動50G的數據，并且耗時30分鐘，而集群每個小時新寫入的數據會導致又有40-60G的數據需要平衡。這樣一來，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. 強行對節點進行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掛載，便再也沒有以上問題。

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

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