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

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

織金網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)建站于2013年成立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(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的部分就不動了。
看到這知道了吧，其實跟服務(wù)器裝沒裝HBase一點關(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主機名IP的映射的關(guān)系，而同事寫的代碼里又要連接B主機里那個并不存在的A主機，于是就卡在了查詢主機名的過程中，將A主機加到/etc/hosts里面，故障解決。

然后第二個故障的判斷是比較有意思的，仍然是這個程序，我們有兩個集群，機房分別在無錫和杭州。該代碼需要從杭州機房請求無錫機房的HBase集群取數(shù)據(jù)，然后跟第一個故障的表象一模一樣，毫無區(qū)別，都是無法通過zookeeper獲取table list，但是整個操作系統(tǒng)環(huán)境肯定是沒問題。
雖然表象一樣，但是原因相差十萬八千里。注明一下：無錫的×××網(wǎng)段是10開頭的A類地址，杭州是172開頭的B類地址，需要跑數(shù)據(jù)的杭州服務(wù)器和無錫的HBase之間由運維同事做了×××鏈接。
然后我們動用了jstack，strace各種工具都看不出問題。
jstack提示卡在listTable的線程上，strace卡在FUTEX_WAIT上，看不出來，然后超出35次超時以后的報錯也看不出啥問題。HBase的listtable方法只連接單臺zk服務(wù)器，所以也沒有映射全部HBase主機名到hosts的必要。
看了一眼netstat，發(fā)現(xiàn)杭州機房172發(fā)送了請求杭州機房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īng)該就好了。
兩個問題的排查解決差不多一個多小時吧，沒寫完kerberos的principal/keytab管理頁面就快下班了。這是另外一個集群的故事了。
說明40歲的老程序員還是有點作用的，還是能快速解決點問題，還是有活下去的價值的。

新聞名稱：Hadoop運維記錄系列(二十二)
當(dāng)前URL：http://muchs.cn/article8/johsop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供、網(wǎng)頁設(shè)計公司、全網(wǎng)營銷推廣、外貿(mào)網(wǎng)站建設(shè)、虛擬主機、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)