聊聊NFS為什么會Hang
昨天有個朋友咨詢一個問題,他通過NFS MOUNT了一個分布式文件系統(tǒng),發(fā)現(xiàn)對這個文件系統(tǒng)df的時候經(jīng)常hang死,他檢查了一番系統(tǒng),發(fā)現(xiàn)內(nèi)存使用率很高,大部分物理內(nèi)存都被cache占用了。他想通過分析cache中都有哪些數(shù)據(jù),通過這個分析來確認cache占用率高和NFS hang之間是否存在關(guān)聯(lián)關(guān)系。當(dāng)時我的建議是首先不要把問題直接定位到OS內(nèi)存上,如果系統(tǒng)不存在嚴重的SWAP,哪怕物理內(nèi)存使用率達到98%,也是關(guān)系不大的。
實際上使用NFS文件系統(tǒng),出現(xiàn)客戶端hang死,或者df命令HANG死的情況并不少見,我這些年里也遇到過多次。我遇到的NFS hang死問題的原因也十分復(fù)雜,不過大多數(shù)都與NFS BUG、網(wǎng)絡(luò)問題、系統(tǒng)資源消耗過高、IO負載過大等有關(guān)。
NFS客戶端訪問NFS文件hang住,一般來說有三種可能性,一種是客戶端出現(xiàn)問題,第二種是服務(wù)端出現(xiàn)問題,第三種是客戶端和服務(wù)端都存在問題。似乎這個總結(jié)有點太籠統(tǒng)了,也有點投機取巧,不過窮舉法是我們在針對未知問題分析的最重要的方法。如果我們不能窮舉所有的可能性,那么在問題診斷分析的時候就可能無法定位。在我多年的經(jīng)驗里,很多當(dāng)時認為十分靈異的問題,都是因為我們以前的知識面不足,無法窮舉到真正的故障路徑。
上面的思維導(dǎo)圖是我這些年遇到過的一些NFS HANG的情況,其中遇見最多的還是和網(wǎng)絡(luò)有關(guān)的,自從NFS V3/V4版本之后,NFS或者OS自身BUG導(dǎo)致的問題逐漸減少,而網(wǎng)絡(luò)方面遇到的問題逐漸變多起來。特別是防火墻問題,最近五六年里,我遇到的大型系統(tǒng)中的NFS問題大部分和防火墻有關(guān)。隨著企業(yè)對網(wǎng)絡(luò)安全的要求越來越高,防火墻也不斷地在調(diào)整策略,有時候有一條策略就會導(dǎo)致NFS的網(wǎng)絡(luò)包被防火墻過濾,從而導(dǎo)致NFS的故障。五六年前我遇到過一個客戶的NFS故障,只要訪問一個文件NFS就會HANG死,訪問其他文件就啥事沒有。當(dāng)時實在沒辦法了只能用網(wǎng)絡(luò)抓包的方式去跟蹤,最后發(fā)現(xiàn)客戶最近上了一個敏感詞過濾的策略,因為這個文件名帶有敏感詞匯,因此網(wǎng)絡(luò)就丟包了。
實際上IP存儲專網(wǎng)建設(shè)十分重要,關(guān)鍵系統(tǒng)使用NFS的時候一定要使用IP存儲專網(wǎng),最好不要經(jīng)過防火墻,不過很多大企業(yè)對于跨機房訪問的網(wǎng)絡(luò)安全管理十分變態(tài),防火墻是必須要經(jīng)過的,一個NFS訪問經(jīng)過至少兩個防火墻,一旦網(wǎng)絡(luò)安全管理員與存儲管理員之間沒有很好的溝通,那么因為防火墻導(dǎo)致的NFS問題那就少不了了。另外我們以前遇到的大多數(shù)NFS故障場景都沒有使用IPSAN專網(wǎng),NFS使用的網(wǎng)絡(luò)是和業(yè)務(wù)網(wǎng)混合使用的,業(yè)務(wù)網(wǎng)出現(xiàn)的任何問題,都會引起NFS文件系統(tǒng)的抖動,從而導(dǎo)致NFS服務(wù)不穩(wěn)定。
是否Socket hang的問題可以通過netstat命令來看是不是存在大量的TCP連接處于CLOSEWAIT狀態(tài),如果存在這種情況,那么很可能你遇到了socket hang。Socket hang大多數(shù)和IO負載過高、客戶端或者服務(wù)器端OS相應(yīng)慢或者某個OS bug有關(guān)。也可能和TCP的keepalive參數(shù)設(shè)置有關(guān)。
另外一點是我們是用NFS的環(huán)境中,可能還安裝了數(shù)據(jù)庫服務(wù)器、中間件服務(wù)器等,這些系統(tǒng)要求調(diào)整OS的網(wǎng)絡(luò)參數(shù),而這些參數(shù)的調(diào)整很可能并不適合NFS服務(wù)。其中常見存在沖突的幾個參數(shù)如下:
- lnet.ipv4.tcp_keepalive_time
- lnet.ipv4.tcp_keepalive_intvl
- lnet.ipv4.tcp_keepalive_probes
- lnet.ipv4.tcp_tw_recycle = 0
- lnet.ipv4.tcp_tw_reuse = 0
- lnet.ipv4.tcp_retries1 = 3
- lnet.ipv4.tcp_retries2 = 15
實際上NFS HANG的問題分析因為涉及的原因很多,所以往往還是不容易定位的,不過如果df命令hang,而且是可重現(xiàn)的,那么分析起來還是有方法的。最好的防范就是使用strace去跟蹤df命令的堆棧。看看hang在什么地方,就比較容易定位問題了。
最后要說明的是,messages日志是一定要首要分析的,不管是客戶端還是服務(wù)端的messages日志都應(yīng)該盡早去看。雖然說很可能我們看到的只是NFS命令超時這類的比較籠統(tǒng)的信息。