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

織金網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)建站于2013年成立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。

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

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

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