CDH5之Balancer難以在快速增長的叢集上平衡大量的資料

背景：
公司線上上使用了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掛載，便再也沒有以上問題。

轉：