背景: 公司在線上使用了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的默認(rèn)帶寬太小,所以效率低下,于是我們嘗試將Balancer的帶寬擴(kuò)容到了500M/s:
hadoop dfsadmin -setBalancerBandwidth 524288000
但問題并沒有得到太大的改善。
2. 強(qiáng)行對節(jié)點進(jìn)行Decommission
我們發(fā)現(xiàn),當(dāng)對一些節(jié)點進(jìn)行Decommission操作時,上面的數(shù)據(jù)雖然有10-30T甚至更多,但總能在1天內(nèi)全部Copy到其它的節(jié)點上,這里面由于默認(rèn)集群副本數(shù)為3的原因,應(yīng)該只有1/3的數(shù)據(jù)被復(fù)制了,但數(shù)據(jù)是完整的,并且被復(fù)制出去的數(shù)據(jù)也是平均分配到各個節(jié)點上的。那么我們何不使用它來作為一個類似Balancer的功能來解決一些磁盤用量超過99.9%的節(jié)點呢?
事實證明,這個方法非常可行,我們針對線上8個節(jié)點進(jìn)行了Decommission操作(注意要盡量一臺一臺進(jìn)行),在完成下線之后再立刻格式化數(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ù)磁盤的主機(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