Hadoop運維記錄系列(二十二)

今天下午寫了一會代碼，然后幫同事解決了一個hbase相關的故障分析，定位了問題根源，覺得比較有代表性，記錄一下。
先說一下問題的發生與背景。
這個故障其實是分為兩個故障的，第一個比較簡單，第二個相對復雜一些。

同事寫了一個HBase相關的測試代碼，使用Hbase原生Java API，編譯打包后分別放在兩臺測試服務器測試，一臺可以，另一臺不可以。

第一個故障是發生在兩臺測試服務器的：
A服務器是正常連通的服務器，裝了HBase，centos6
B服務器是無法連通的服務器，沒裝HBase，centos7
表象是在A服務器可以正常跑編譯的jar包，B服務器無法正常跑，卡在連接Zookeeper獲取table list的部分就不動了。
看到這知道了吧，其實跟服務器裝沒裝HBase一點關系都沒有。
首先懷疑是防火墻，先關掉B服務器的firewalld，沒起作用，然后用netstat看了一下，發現A服務器連接Hbase走的是tcp，而B服務器是centos7，連接hbase走的是tcp6，而hbase集群是centos6，沒有ipv6，禁用B服務器的tcp6，然后仍然沒起作用。
netstat查看HBase ZK服務器，跟B服務器也建立連接了，也ESTABLISHED了，就是不返回數據。
之后，唉，在經過35次超時以后，報錯日志出來了，是B服務器里缺少一條A主機名IP的映射的關系，而同事寫的代碼里又要連接B主機里那個并不存在的A主機，于是就卡在了查詢主機名的過程中，將A主機加到/etc/hosts里面，故障解決。

然后第二個故障的判斷是比較有意思的，仍然是這個程序，我們有兩個集群，機房分別在無錫和杭州。該代碼需要從杭州機房請求無錫機房的HBase集群取數據，然后跟第一個故障的表象一模一樣，毫無區別，都是無法通過zookeeper獲取table list，但是整個操作系統環境肯定是沒問題。
雖然表象一樣，但是原因相差十萬八千里。注明一下：無錫的×××網段是10開頭的A類地址，杭州是172開頭的B類地址，需要跑數據的杭州服務器和無錫的HBase之間由運維同事做了×××鏈接。
然后我們動用了jstack，strace各種工具都看不出問題。
jstack提示卡在listTable的線程上，strace卡在FUTEX_WAIT上，看不出來，然后超出35次超時以后的報錯也看不出啥問題。HBase的listtable方法只連接單臺zk服務器，所以也沒有映射全部HBase主機名到hosts的必要。
看了一眼netstat，發現杭州機房172發送了請求杭州機房10網段zk 2181端口的請求，記得是停在了SYN_SEND上，半天也沒有ESTABLISHED，然后馬上又看了一下無錫HBase的netstat，發現根本沒有連接建立，立即大徹大悟。
跟同事分析了一下，應該是×××的隧道連接是單向路由或者以NAT方式連接的，我推測應該是無錫10網段的×××可能是NAT，是可以通過×××連接杭州172網段的，而杭州172網段無法連接無錫10網段，于是讓同事在兩邊分別做了ping測試，結果和我預想的一樣，杭州無法ping通無錫，而無錫可以ping通杭州。
因為做×××的運維同事不在，打電話問了一下，確實×××是單向路由，至此問題就算解決了，等著運維同事回來加路由表應該就好了。
兩個問題的排查解決差不多一個多小時吧，沒寫完kerberos的principal/keytab管理頁面就快下班了。這是另外一個集群的故事了。
說明40歲的老程序員還是有點作用的，還是能快速解決點問題，還是有活下去的價值的。