1.故障描述
在HBase和Hive集群中HDFS的DataNode節點均有大量的異常日誌，詳細日誌信息如下：
2019-02-25 17:02:02,153 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: BlockSender.sendChunks() exception:
java.io.IOException: 斷開的管道
at sun.nio.ch.FileChannelImpl.transferTo0(Native Method)
at sun.nio.ch.FileChannelImpl.transferToDirectlyInternal(FileChannelImpl.java:416)
at sun.nio.ch.FileChannelImpl.transferToDirectly(FileChannelImpl.java:481)
at sun.nio.ch.FileChannelImpl.transferTo(FileChannelImpl.java:596)
at org.apache.hadoop.net.SocketOutputStream.transferToFully(SocketOutputStream.java:223)
...
主要以Hive集群分析為主，該集群中有hive01和hive02兩個節點即是管理節點也是數據節點，這兩個節點上出現了大量的“Broken Pipe”異常日誌
2.故障分析階段（平臺層面）
通過提供給Cloudera售後的HDFS日誌、lsof日誌以及其它蒐集的日誌，在初步分析後反應出來的現象HBase出現性能問題是由於底層的HDFS不穩定導致。在HDFS的DataNode節點有大量的“Broken Pipe”異常，由於大量的Broken Pipe導致DataNode讀寫Block時重試從而導致基於HDFS的HBase等應用會出現性能下降的問題。
售後提出協調系統管理員分析系統層面的問題，在OS層面與舊集群未做任何變動，系統的參數及Hadoop的基本運行環境均與舊集群一致。
1. 通過分析Hive集群發現 NameNode GC頻繁且耗時，如下圖所示
將NameNode的Java heap大小從6GB調整至10GB
增加NameNode的Heap大小後通過jstat命令和CM監控界面進行監控，看到NameNode的GC得到緩解
sudo -u hdfs /usr/java/jdk1.7.0_80/bin/jstat -gcutil 180080 1000 1000
通過調整NameNode Heap大小，解決了NameNode頻繁且耗時的GC問題，但並沒有解決DataNode服務的“Broken Pipe”問題。
2. 期間通過調整hive01節點DataNode服務的日誌未DEBUG級別，重啟DataNode服務後分析輸出的Debug日誌
日誌能夠輸出DN節點操作每個Block的大小等一些詳細信息，但對於拋出的異常堆棧信息還是不夠詳細，無法通過堆棧信息定位到DN在操作哪個Block時輸出的異常，無法很好的跟中異常異常日誌所連接的TCP端口號及對應的DN節點。
3. 在分析集群的配置參數時，發現集群的幾個數據節點內存使用都過高
期間懷疑是集群資源使用過高，導致DataNode節點讀寫數據慢導致，通過將角色分組的方式將hive01和hive02節點劃分到一個獨立的角色組，並降低Yarn資源的內存使用至48GB。通過重啟NodeManager服務觀察DataNode節點任然出現大量“Broken Pipe”異常。
4. 在查看OS的關於tcp的內核參數時，發現多個關於tcp連接有關的參數配置，懷疑內核參數配置導致TCP連接中斷，通過將sysctl.conf配置文件中的部分tcp內核配置屏蔽
原始配置如下：
修改後配置如下：
經過觀察DataNode服務仍然有大量的“Broken Pipe”異常。
5. 通過分析HDFS的源碼異常信息拋出的代碼段，發現DN服務在讀取當前節點的Block時，將Block發送至其他DN節點時，由於TCP連接中斷導致拋出“Broken Pipe”異常信息
通過DataXceiverServer服務判斷當前DatNode啟動的xceiver線程數是否達到設置的最大值（dfs.datanode.max.transfer.threads，默認4096）如果沒有達到最大值則啟動線程
初始化initDataXceiver時指定的sockewriteTimeOut值，該值對於HDFS的
dfs.datanode.socket.write.timeout 默認8*60*1000
dfs.client.socket-timeout 默認60 * 1000
dfs.datanode.socket.reuse.keepalive 默認4000
dfs.datanode.transfer.socket.recv.buffer.size 默認值131072
3.故障分析階段（網絡層面）
1. 從系統網卡的信息上看，網卡存在大量丟包的情況，並且出現”Broken Pipe”異常的節點上的丟包數要明顯多於未出現該異常的節點，懷疑可能是網絡配置問題。
出現”Broken Pipe”異常的hive01和hive02節點：
未出現”Broken Pipe”異常的hive03和hive04節點：
2. 使用tcpdump工具從報錯節點上抓取數據包信息，使用wireshark進行分析，在抓出的數據包中出現如下一些錯誤，運維同事初步懷疑是否是做的bond網卡有問題。
3. 根據運維同事介紹，目前hive集群與hbase集群的網絡架構如下
每一臺節點都通過兩個萬兆物理網卡實現高可用，本次測試通過將hive集群上每臺節點上的一個網卡接口禁用，使用單網卡連接相同的交換機進行通信，測試效果。在未測試前，hive1/2節點存在”Broken Pipe”問題，而hive3/4節點不存在這個問題。
首先，測試hive1/2/3/4節點與A交換機斷開之後的效果，即
此時，hive1/2/3/4節點僅通過一個網卡與交換機B通信，在這種狀態運行一個小時,統計結果：hive1/2仍存在”Broken Pipe”異常，在這一小時內，單節點數量達到15000個，而此前5個小時內該數量最大在單節點每小時5000個，不排除在這一小時內作業突然增多情況，hive3/4仍沒有異常，所有節點都沒有出現其他異常。
測試hive1/2/3/4節點與B交換機斷開之後的效果，即
此時，hive1/2/3/4節點僅通過一個網卡與交換機A通信，在這種狀態運行一個小時,統計結果：hive1/2仍存在”Broken Pipe”異常，在這一小時內，單節點數量為7000個，hive3/4仍然沒有”Broken Pipe”異常，從更換網卡之後，所有節點均出現了新的異常：EOFexception，每個節點都保持在每分鐘有多條該報警記錄。
在做如上兩個測試的過程當中，平臺組件均沒有重啟。
該測試總結：根據cdh平臺的要求，一個萬兆網卡即可滿足平臺需求，理論上bond的網卡在始終保持有一個網卡處於可用狀態的時候，應用層不應當感受到網卡切換的變化，即在更換網卡之後應用不應當出現新的錯誤和原異常顯著增多的情況，所以這更傾向於網絡或者OS底層問題。
4. 在ifconfig中網卡出現dropped的原因：網卡已經接受到數據包，在從網卡緩存傳輸到系統內存中時發生丟失；DELL廠商建議增大網卡緩存大小，增加到2048，在終端執行該操作後重啟網卡，異常仍然沒有消失。
5. 解除所有節點的bond網卡，所有數據節點都使用單網卡模式，取消網卡之後重啟網卡，觀察一段時間，發現報錯仍然沒有消失，報錯的仍然是hive1/2，hive3/4正常。
6. Hive集群中報錯的兩個節點為hive1/2，不報錯的為hive3/4，而hive1/2上組件角色要比hive3/4多，測試是否是因為服務多負載重引起該異常，將hive2上的NameNode,Hiveserver2,HiveMetastore,ResourceManager轉移到hive4節點上，觀察報錯情況，沒有變化，報錯的仍然是hive1/2，hive3/4仍為正常，證明與負載無關。
4.故障分析階段（系統層面）
1. 在排查過程中，發現報錯的hive01,hive02以及hbase集群的四個節點系統語
言皆為中文，但未報錯的hive03則hive04則都為英文：
2. 使用rpm -qa命令查看hive集群四個節點所安裝的rpm包信息，對比之後發
現hive03與hive04所安裝的RPM包完全一致，而hive01與hive02除了hive03上有的rpm之外，還有很多其他的RPM包，在安裝平臺時系統環境其實並不一致，推測是由系統環境不一致引起的異常，在安裝集群之前，節點系統的環境相對已不純淨，可能是由於某些第三方依賴包引起了網絡不穩定。計劃依次採取如下方案繼續測試：
- 更改語言環境
- 更換網卡及光纖通信線
- 逐臺節點下線重裝系統
3. 在更換了hive01與hive02的系統語言環境為英文，並重啟了節點之後,”Broken Pipe”異常未再出現。Hbase集群採取同樣的操作後，該異常也未再出現。
5.總結
1. 該異常的處理辦法是將系統語言改為英文；
2. CDH無系統語言必須為英文的要求，推測可能的原因一方面是否安裝的中文字符集有問題或者該字符集與CentOS6.8兼容性並不好；另一方面，從各個節點上安裝的依賴包來看，還安裝了很多第三方的依賴包，是否存在部分依賴包在中文環境下會導致網絡不穩定的情況。
閱讀更多 Hadoop實操 的文章
