【原創】centos自帶網卡驅動不兼容硬件，形成hadoop的datanode節點頻繁宕機的解...

•  操做系統 ：CentOS Linux 6.0（Final）
•  內核  ： Linux 2.6.32
•  硬件 ： HP 3300 Series MT ，內存增長到6G。
•  Hadoop集羣： 一臺NameNode 同時做爲client node、三臺DataNode。數據備份爲3分，即dif.replication = 3 。

筆者在測試hadoop性能過程當中，在向hadoop集羣中put大量數據（50G）的時候，集羣中的datanode節點頻繁宕機。而且在centos日誌系統中沒有關於datanode宕機的錯誤報告。

由於hadoop的測試數據是存放在namenode 中的，因此namenode同時也是client node。通過筆者觀察發現，宕機的只是datanode，而client node歷來不宕機。在hadoop put數據的過程當中，經過ganglia觀察到client node的系統負載率要要遠遠高於datanode 。繁忙的client node不宕機，而相對系統負載率低的datanode卻頻繁死機，說明了datanode宕機與cpu、內存無關。筆者將目光轉向了磁盤I/O和網絡I/O。

首先，考慮是否由於磁盤I/O頻繁操做引發的datanode系統宕機。由於測試數據存放在client node上，因此要在clent node上進行大量的磁盤讀取數據操做。client node不宕機，說明了出現的問題與磁盤讀取數據操做無關。hadoop進行put操做，在datanode上只進行極少許的配置文件讀取，主要是將數據進行磁盤寫操做。爲了測試是不是由磁盤寫操做引發的系統宕機，筆者將集羣中的全部datanode代碼中寫磁盤操做的部分註釋掉，這樣datanode在接收到數據後就不在進行磁盤寫操做。可是，在hadoop集羣運行put操做過程當中，datanode依然宕機。那麼，如今能夠斷定磁盤I/O不是形成宕機的緣由。

那麼，形成系統宕機的緣由是否是由於網絡I/O 呢？仔細觀察整個集羣中的網絡I/O發現，由於client node要put數據，因此在client node節點上，有大量數據包發送到集羣網絡上，相比發送大量的數據包，client node接收到的應答包很小，基本能夠忽略不計，在這裏能夠暫時作出如下結論，網絡操做中的發送大量數據包不會使機器宕機。而對於datanode，由於handoop集羣的數據塊備份個數爲3份，因此根據hadoop中生成備份數據的規則，每一個datanode節點會同時發送和接送大量數據。筆者觀察到一個有趣的現象：3臺datanode節點不會所有宕機，最多隻是其中兩臺宕機，剩下的那一臺datanode節點能完成全部工做。這時候觀察網絡流量，由於宕掉了2臺datanode節點，因此hadoop備份機制就不在工做，剩下的那臺沒有宕掉的datanode機器把接收到的數據寫入磁盤就行了，不用再發送給其餘datanode節點進行備份。也就是說最後剩下的那個datanode節點，只接收client node發送來的大量數據和發送能夠忽略不計應答包。在這裏筆者能夠再次作一個暫時性結論，網絡操做中的接收大量數據包不會使機器宕機。爲了驗證結論，筆者去掉了一臺datanode節點，並再次修改了相應hadoop配置文件和datanode代碼，用剩下的兩個datanode節點A和B，其中一個datanode節點A接收client node發送過來的數據，而且再轉發到另外一個只接收數據datanode B節點上，而後節點A將數據寫入磁盤。datanode B節點只接收datanode A節點發送來的數據，而後寫入磁盤。這樣datanode A節點在haodoop put過成中不只接收數據，並且還發送數據。通過測試，datanode A節點頻繁的死機。在這裏筆者基本能夠肯定如下結論，形成datanode頻繁宕機的緣由是因爲datanode節點經過網絡同時接收和發送了大量的數據。

緣由找到了，那麼下一步就須要找到解決問題的方法，經過網絡同時接收和發送大量數據的操做對應用程序來講是很基本和常見的操做，若是Centos由於這個操做就頻繁的宕機，那麼這個操做系統也就太脆弱了。筆記根據經驗判斷，這應該是硬件驅動程序不兼容引發的問題。何況筆者在安裝Centos的時候，使用都是CentOS自帶的驅動程序。而不是硬件廠商針對操做系統推出的驅動程序。有了這個想法後，筆者更新了集羣中全部節點網卡驅動程序，而後再次運行hadoop put操做。終於，hadoop集羣將50G的數據量寫入了磁盤。

至此，困擾筆者十幾日的問題解決了。