Hadoop運維記錄系列(二十三)
舊集群的機器是centos 6, 新機房加的機器是centos 7。
一、丟包問題
在跨機房的時候，datanode顯示很多Slow BlockReceiver的日誌
WARN org.apache.hadoop.hdfs.server.datanode.DataNode: Slow BlockReceiver write packet to mirror took 630ms(threshold=300ms)
經查，這個報錯的主要原因出在網卡的MTU設置上，hadoop建議將網卡mtu值從1500設置為9000，以支持接收jumbo frame。調整mtu值後，偶爾還會有幾條，但頻率小多了。而且我記得這個得交換機一起配合修改，光改服務器不好使。
二、centos7 執行df命令掛起，無法退出
在cent7下面執行df命令會死在那裏，用ctrl-c也沒法退出。由於我們的nodemanager健康檢查腳本裏面包含df命令，所以，nm的健康檢查會卡死，最後把所有CPU全吃光，導致計算任務無法正常進行。使用kill命令也無法殺掉僵死的df進程，使用strace跟蹤df命令也無法退出，必須用kill -9 殺掉strace才可以。
stat("/sys/fs/cgroup/memory", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
stat("/sys/kernel/config", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
stat("/", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
stat("/proc/sys/fs/binfmt_misc",最後df就是卡死在 binfmt_misc 這了。
經查，這是centos7 systemd的一個bug，1534701，我們觸發這個bug的原因應該是在執行hadoop安裝的時候，作為依賴更新了systemd相關的組件，但是沒有進行重啟，新的systemd沒生效，所以重啟之後，故障解決。
三、專線流量大，導致跑任務慢
使用tcpdump及nmap綜合分析，發現大量的ARP連接，應是B類地址沒有做VLAN路由，跨機房集群相互之間做ARP通告引發廣播風暴。後續由運維重新規劃vlan解決。
這些故障基本都不是hadoop本身的問題，就像上一篇記錄裏面，幾百臺機器其中一臺的網卡變成了10Mbps，結果拖慢了整個集群的運行速度。這些問題都需要hadoop運維來發現，排查，通知其他部門，所以hadoop運維應該是在數據研發部門和運維部門之間的橋梁，能夠快速定位hadoop，數據應用，操作系統，硬件之間哪裏出現了問題，然後安排各相關人員解決，越快速定位，越能節省成本，時間成本和金錢成本都是成本，比如我司為了跨集群拉的專線據說一天一萬，客戶限定時間內跑不出數據報告丟的錢更多，我估摸著兩天解決這三問題少說能給公司節約幾十萬成本。
等跨機房遷移弄完了，可以專門寫一寫。
Hadoop運維記錄系列(二十三)