新年上班第一天生產(chǎn)環(huán)境分布式文件系統(tǒng)崩了！
作者個(gè)人研發(fā)的在高并發(fā)場(chǎng)景下，提供的簡(jiǎn)單、穩(wěn)定、可擴(kuò)展的延遲消息隊(duì)列框架，具有精準(zhǔn)的定時(shí)任務(wù)和延遲隊(duì)列處理功能。自開源半年多以來(lái)，已成功為十幾家中小型企業(yè)提供了精準(zhǔn)定時(shí)調(diào)度方案，經(jīng)受住了生產(chǎn)環(huán)境的考驗(yàn)。為使更多童鞋受益，現(xiàn)給出開源框架地址：
https://github.com/sunshinelyz/mykit-delay
寫在前面
說(shuō)來(lái)也怪，早不崩晚不崩，偏偏在上班第一天的時(shí)候，生產(chǎn)環(huán)境分布式文件系統(tǒng)崩了。我才剛來(lái)到我的工位坐下，“叮鈴鈴”電話響了，是運(yùn)營(yíng)打來(lái)的，“喂，冰河，快點(diǎn)看看，生產(chǎn)環(huán)境的圖片和視頻都無(wú)法上傳了，系統(tǒng)崩潰了，快點(diǎn)看看啊!”。你說(shuō)我一個(gè)不是做運(yùn)維的，直接打來(lái)電話讓我看生產(chǎn)環(huán)境的事故?原來(lái)是運(yùn)維那哥們還沒(méi)上班，額，好吧，我接受了，于是我迅速整理好工位，擺出電腦，登錄服務(wù)器，一頓操作猛如虎，10分鐘搞定了，剩下的就是異步復(fù)制圖片和視頻了。
今天，就和小伙伴們分享下，這次生產(chǎn)環(huán)境分布式文件系統(tǒng)出現(xiàn)的問(wèn)題，以及我是如何10分鐘排查問(wèn)題和解決問(wèn)題的。另外，本文不是基于生產(chǎn)環(huán)境事故寫的，而是事后，我在我本機(jī)虛擬機(jī)上模擬的環(huán)境。解決問(wèn)題的思路和方法都是一樣的。
額，估計(jì)運(yùn)維要被3.25了!!
文章已收錄到：
https://github.com/sunshinelyz/technology-binghe
https://gitee.com/binghe001/technology-binghe
問(wèn)題定位
通過(guò)登錄服務(wù)器查看系統(tǒng)的訪問(wèn)日志，發(fā)現(xiàn)日志文件中輸出了如下異常信息。
- org.csource.common.MyException: getStoreStorage fail, errno code: 28
- at org.csource.fastdfs.StorageClient.newWritableStorageConnection(StorageClient.java:1629)
- at org.csource.fastdfs.StorageClient.do_upload_file(StorageClient.java:639)
- at org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:162)
- at org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:180)
很明顯，是系統(tǒng)無(wú)法上傳文件導(dǎo)致的問(wèn)題，這個(gè)日志信息很重要，對(duì)問(wèn)題的排查起到了至關(guān)重要的作用。
分析原因
既然是上傳文件出現(xiàn)了問(wèn)題，那我先試試能不能訪問(wèn)以前上傳的文件呢?經(jīng)過(guò)驗(yàn)證，以前上傳的文件是可以訪問(wèn)的，再次驗(yàn)證了是上傳文件的問(wèn)題。
既然生產(chǎn)環(huán)境是使用的分布式文件系統(tǒng)，一般情況下是沒(méi)啥問(wèn)題的，上傳文件出現(xiàn)了問(wèn)題，大概率的事件是服務(wù)器磁盤空間不足了。那我就來(lái)順著這個(gè)思路排查下問(wèn)題。
于是乎，我使用df -h 查看服務(wù)器的存儲(chǔ)空間使用率，已經(jīng)達(dá)到91%了。
嗯，磁盤空間有可能是引起問(wèn)題的原因。接下來(lái)，再來(lái)進(jìn)一步確認(rèn)下是否是磁盤空間造成的問(wèn)題。
于是，我再打開/etc/fdfs/目錄下的tracker.conf的配置，看到預(yù)留的存儲(chǔ)空間為10%(注：這里的分布式文件系統(tǒng)使用的是FastDFS)。
看到這里，可以確定就是磁盤空間不足造成的無(wú)法上傳文件的問(wèn)題。
總體原因就是：服務(wù)器磁盤空間已使用91%，而在分布式文件系統(tǒng)的配置中預(yù)留的磁盤空間為10%，實(shí)際在上傳文件的時(shí)候，系統(tǒng)已經(jīng)檢測(cè)到當(dāng)前服務(wù)器剩余的磁盤空間不足10%，拋出異常，拒絕上傳文件。
到此，問(wèn)題出現(xiàn)的原因已經(jīng)確定了，接下來(lái)就是要解決問(wèn)題了。
解決問(wèn)題
首先，有兩種方式可以解決這個(gè)問(wèn)題，一種就是刪除不需要的文件;另一種就是擴(kuò)容磁盤空間。
刪除不需要的文件
這種方式慎用，這里，我也簡(jiǎn)單的介紹下這種方式。我給小伙伴們提供了幾種遞歸刪除的方式。
遞歸刪除.pyc格式的文件。
- find . -name '*.pyc' -exec rm -rf {} \;
打印當(dāng)前文件夾下指定大小的文件
- find . -name "*" -size 145800c -print
遞歸刪除指定大小的文件(145800)
- find . -name "*" -size 145800c -exec rm -rf {} \;
遞歸刪除指定大小的文件，并打印出來(lái)
- find . -name "*" -size 145800c -print -exec rm -rf {} \;
下面是對(duì)上述命令的一些簡(jiǎn)要說(shuō)明。
- "." 表示從當(dāng)前目錄開始遞歸查找
- “ -name '*.exe' "根據(jù)名稱來(lái)查找，要查找所有以.exe結(jié)尾的文件夾或者文件
- " -type f "查找的類型為文件
- "-print" 輸出查找的文件目錄名
- -size 145800c 指定文件的大小
- -exec rm -rf {} \; 遞歸刪除(前面查詢出來(lái)的結(jié)果)
擴(kuò)容磁盤空間
這里，冰河推薦使用這種方式，我修復(fù)生產(chǎn)環(huán)境的故障也是使用的這種方式。
通過(guò)查看服務(wù)器的磁盤空間發(fā)現(xiàn)，/data目錄下的空間足足有5TB，呵呵，運(yùn)維哥們?yōu)樯恫话盐募到y(tǒng)的數(shù)據(jù)存儲(chǔ)目錄指向/data目錄呢。于是乎，我開始將文件系統(tǒng)的數(shù)據(jù)存儲(chǔ)目錄遷移到/data目錄下，整個(gè)過(guò)程如下所示。
注意：這里，我就簡(jiǎn)單的模擬將 /opt/fastdfs_storage_data下的數(shù)據(jù)遷移至/data下。
(1)拷貝文件，遷移數(shù)據(jù)
- cp -r /opt/fastdfs_storage_data /data
- cp -r /opt/fastdfs_storage /data
- cp -r /opt/fastdfs_tracker /data
(2)修改路徑
這里需要修改文件系統(tǒng)的 /etc/fdfs/storage.conf ,mod_fastdfs.conf ,client.conf,tracker.conf文件。
- /etc/fdfs/storage.conf
- store_path0=/data/fastdfs_storage_data
- base_path=/data/fastdfs_storage
- /etc/fdfs/mod_fastdfs.conf
- store_path0=/data/fastdfs_storage_data (有兩處)
- base_path=/data/fastdfs_storage
- /etc/fdfs/client.conf
- base_path=/data/fastdfs_tracker
- /etc/fdfs/tracker.conf
- base_path=/data/fastdfs_tracker
重新建立 M00 至存儲(chǔ)目錄的符號(hào)連接：ln -s /data/fastdfs_storage_data/data /data/fastdfs_storage_data/data/M00
(3)殺掉進(jìn)程, 重啟存儲(chǔ)服務(wù) (追蹤器和存儲(chǔ)器)
依次執(zhí)行以下命令
- pkill -9 fdfs
- service fdfs_trackerd start
- service fdfs_storaged start
(4)修改文件的讀取路徑 nginx配置
- location ~/group1/M00{
- root /data/fastdfs_storage_data/data;
- }
(5)重啟nginx
- cd /opt/nginx/sbin
- ./nginx -s reload
好了，問(wèn)題搞定，運(yùn)營(yíng)可以正常上傳圖片和視頻了。
本文轉(zhuǎn)載自微信公眾號(hào)「 冰河技術(shù)」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系 冰河技術(shù)公眾號(hào)。
