Hadoop運維記錄系列（二十五）

耗時很長時間解決了一個spark in docker的問題，記錄一下。

這是個非常奇怪的問題，找遍谷歌都找不到答案，與其說是分析出來倒不如說是偶然發(fā)現(xiàn)。

先介紹一下架構(gòu)和環(huán)境。

Z機器是docker的宿主機，在每個docker里面都跑了一個Zeppelin用作數(shù)據(jù)分析，之所以這樣弄，是客戶要求每個人的環(huán)境都必須是獨立的。

Zdocker假設(shè)是Z上面跑著zeppelin的運行的一個docker鏡像。

Zdocker使用默認的bridge方式連接到外部集群

Hadoop集群按照加入集群的先后順序分為兩部分進行觀察。A為先加入集群的機器有31臺，B為后加入集群的機器15臺。

Spark使用client方式提交，用YARN做資源管理。

表象：

Zdocker里面通過Zeppelin頁面提交的Spark計算任務(wù)一直都是正常的，直到B的15臺加入到集群里

B的15臺配置從操作系統(tǒng)到網(wǎng)絡(luò)到JVM到hadoop全部一模一樣，沒有區(qū)別。

B加入后，所有從Zdocker里面提交的Spark任務(wù)全部不能跑，executor在15臺機器執(zhí)行時會報 NoRouteToHost gateway: 7337

B加入后，所有在Zdocker外面提交的Spark任務(wù)全部正常。

B加入后，所有executor不運行在B機器上的全部正常

B加入后，Zdocker內(nèi)外所有MapReduce任務(wù)正常。

在YARN里去掉B的15臺機器，一切正常。

分析：

7337為spark的yarn shuffle端口

第一階段

既然是NoRouteToHost，第一反應是DNS問題，檢查所有DNS和hosts文件，沒有發(fā)現(xiàn)問題，檢查iptables，route表，全部無問題，解決失敗。

第二階段

懷疑是spark bug，我想知道 gateway 是從哪冒出來的，翻閱了spark里面報錯相關(guān)的scala和java代碼，沒有找到這個跟gateway相關(guān)的東西。

第三階段

因為B加入前是正常的，B加入后就不正常了，檢查docker里面的DNS和hosts，全部正常，繼續(xù)失敗。

第四階段

懷疑環(huán)境變量不同，檢查所有A,B機器配置，環(huán)境變量完全一樣。

因為是yarn shuffle，懷疑spark-assembly問題，檢查后發(fā)現(xiàn)無問題。

第五階段

嘗試暴力解決，將gateway加入DNS解析，強行指到B集群的一臺機器上。也就是所有的spark 外部shuffle會指向到一臺機器的 7337端口。好，跑了一天沒問題，第二天就有問題了，那臺被強行指定的機器報找不到作業(yè)在本地shuffle的index文件。

第六階段

嘗試在docker里面發(fā)現(xiàn)問題，看了一下docker的路由表，發(fā)現(xiàn)172.17.42.1是docker的網(wǎng)關(guān)，抱著死馬心態(tài)在docker里面ping了一下gateway主機名，發(fā)現(xiàn)通的。于是襠下一緊，感覺有門可入。

docker內(nèi)部默認的網(wǎng)關(guān)是172.17.42.1，然后默認還給了個hostname叫g(shù)ateway，或許這就是了。

于是跑到A找了一臺機器ping gateway主機名，ping卡死，因為無論DNS還是hosts，在任何hadoop的節(jié)點都是沒有解析過gateway這個主機名的。然后到B找了一臺機器ping，直接退出報 ping: unknown host gateway。

于是開始琢磨，兩個機器網(wǎng)絡(luò)環(huán)境不同，或許這就是問題點了。

A的幾十臺機器，因為安全需要，沒有開放任何外網(wǎng)訪問。所以在A的機器上ping gateway時，根本連域名都解析不了，所以會卡死。而B的十幾臺機器因為是新加的，運維忘了關(guān)閉外網(wǎng)訪問，所以能找到公網(wǎng)的域名解析服務(wù)器，但是公網(wǎng)解析不了gateway域名，于是直接返回 unknown host 并退出。

讓運維關(guān)閉B機器的公網(wǎng)訪問，再從Zdocker上面提交作業(yè)，一切正常。

原因：

解決了問題再回來分析一下應該是因為zeppelin從docker里面提交spark作業(yè)，spark是client方式跑，driver是跑在docker里面的，driver在向docker外的yarn申請資源分配executor的時候，在哪里帶上了gateway這個主機名作為環(huán)境變量傳遞給了executor的container。如果沒有外網(wǎng)訪問，executor會使用本機的 7337作為yarn shuffle的端口，而有了外網(wǎng)訪問，executor會去查詢gateway的ip，但是DNS返回錯誤，于是就會造成executor執(zhí)行錯誤。這也很好的解釋了為什么docker外面的spark作業(yè)無論B是否啟動都不會報錯正常執(zhí)行。

所以這他媽其實是一個很低端的錯誤，只是誰都不會想到，spark執(zhí)行的失敗還能跟是否訪問公網(wǎng)有關(guān)。就跟上次解決MR速度慢一樣，誰能想到網(wǎng)卡能他媽自己跳成10Mbps啊。

后續(xù)還需要繼續(xù)研究docker的網(wǎng)絡(luò)機制和spark的driver和executor之間的傳參機制，才能徹底干掉這個問題。