新年最初の仕事の日に、本番環境の分散ファイルシステムがクラッシュしました！

[[383073]]

著者は、正確にスケジュールされたタスクと遅延キュー処理機能を備えた、高同時実行シナリオ向けのシンプルで安定したスケーラブルな遅延メッセージ キュー フレームワークを個人的に開発しました。半年以上前にオープンソース化されて以来、10 社を超える中小企業に正確でタイムリーなスケジューリング ソリューションを提供することに成功し、実稼働環境でのテストにも耐えてきました。より多くの人々の利益のために、オープンソース フレームワークのアドレスが次のように提供されます。

https://github.com/sunshinelyz/mykit-delay

序文

不思議なことに、実稼働環境の分散ファイルシステムは、それより早くも遅くもなく、作業初日にクラッシュしました。ちょうど自分のワークステーションに座った時に電話が鳴りました。それは運用部門でした。 「こんにちは、Bingheさん、急いで確認してください。本番環境の写真とビデオをアップロードできません。システムがクラッシュしました。急いで確認してください！」運用保守担当者ではない私が、本番環境での事故確認のために直接呼ばれたということですか？結局、運用保守担当者はまだ出勤していなかったことが判明しました。まあ、わかりました。受け入れました。そこで私はすぐにワークステーションを片付け、コンピューターを出して、サーバーにログインし、虎のように働きました。 10分で完了しました。残りは写真とビデオを非同期にコピーすることでした。

今日は、実稼働環境の分散ファイルシステムで発生した問題と、その問題を 10 分でトラブルシューティングして解決した方法を皆さんと共有したいと思います。なお、この記事は本番環境での事故を基に書かれたものではなく、その後にローカルの仮想マシン上でシミュレートした環境を元に書かれています。問題を解決するための考え方や方法は同じです。

えっと、運用保守は3.25になると思います!!

この記事は以下に収集されています:

https://github.com/sunshinelyz/technology-binghe

https://gitee.com/binghe001/technology-binghe

問題の場所

サーバーにログインし、システムアクセスログを確認すると、ログファイルに以下の異常な情報が見つかります。

 org.csource.common.MyException: getStoreStorage 失敗、エラーコード: 28
 org.csource.fastdfs.StorageClient.newWritableStorageConnection(StorageClient.java:1629)で
org.csource.fastdfs.StorageClient.do_upload_file(StorageClient.java:639)で
org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:162)で
org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:180)で

明らかに、この問題はシステムがファイルをアップロードできないことが原因で発生しています。このログ情報は非常に重要であり、問​​題のトラブルシューティングに重要な役割を果たします。

原因を分析する

ファイルのアップロードに問題があったため、以前にアップロードしたファイルにアクセスしてみます。検証後、以前にアップロードされたファイルにアクセスできるようになりました。これにより、問題はファイルのアップロードにあることが再度確認されます。

実稼働環境では分散ファイルシステムを使用しているため、通常は問題はありません。ファイルのアップロードに問題がある場合、最も可能性が高いのはサーバーのディスク容量が不足していることです。次に、この考え方に従って問題を解決します。

そこで、df -h を使用してサーバーのストレージ容量の使用状況を確認したところ、91% に達していました。

そうですね、ディスク容量が問題の原因となっている可能性があります。次に、問題がディスク容量によって発生しているかどうかをさらに確認してみましょう。

そこで、/etc/fdfs/ ディレクトリの tracker.conf 構成を開き、予約済みのストレージ領域が 10% であることを確認しました (注: ここでの分散ファイル システムは FastDFS を使用します)。

これを見ると、ファイルをアップロードできない問題はディスク容量不足によって発生していることが分かります。

全体的な理由は次のとおりです。サーバーのディスク領域の 91% が使用されているのに対し、分散ファイル システム構成で予約されているディスク領域は 10% です。実際にファイルをアップロードするときに、現在のサーバーの残りのディスク容量が 10% 未満であることがシステムによって検出されたため、例外がスローされ、ファイルのアップロードが拒否されます。

この時点で問題の原因は特定されており、次のステップは問題を解決することです。

問題を解決する

まず、この問題を解決するには 2 つの方法があります。 1つは不要なファイルを削除することです。もう 1 つはディスク領域を拡張することです。

不要なファイルを削除する

この方法は注意して使用する必要があります。ここでは、この方法について簡単に紹介します。私は友人のために再帰削除のいくつかの方法を提供します。

.pyc ファイルを再帰的に削除します。

探す 。 -名前  '*.pyc' - exec rm -rf {} \;

現在のフォルダ内の指定されたサイズのファイルを印刷します

探す 。 -名前  "*" -サイズ145800c -印刷

指定されたサイズのファイルを再帰的に削除します (145800)

探す 。 -名前  "*" -サイズ145800c - exec rm -rf {} \;

指定されたサイズのファイルを再帰的に削除し、印刷します

探す 。 -名前  "*" -サイズ145800c -print - exec rm -rf {} \;

上記のコマンドの簡単な説明を以下に示します。

• 「。」現在のディレクトリから始まる再帰検索を意味します
• 「 -name '*.exe' 」は名前で検索し、.exeで終わるすべてのフォルダまたはファイルを見つけます。
• " -type f "検索タイプはファイルです
• 「-print」は検索されたファイルディレクトリ名を出力します
• -size 145800cはファイルのサイズを指定します
• -exec rm -rf {} \;再帰削除（前回のクエリの結果）

ディスク容量を拡張する

ここで、Binghe はこの方法を推奨しており、私もこの方法を使用して本番環境での障害を修正しています。

サーバーのディスク容量を確認すると、/data ディレクトリ以下の容量が 5TB もあることがわかりました。ハハ、なぜ運用保守担当者はファイルシステムのデータ保存ディレクトリを /data ディレクトリに指定しないのでしょうか?そこで、ファイルシステムのデータ保存ディレクトリを /data ディレクトリに移行する作業を開始しました。全体のプロセスは次のとおりです。

注: ここでは、/opt/fastdfs_storage_data の下にあるデータの /data への移行を単純にシミュレートします。

（１）ファイルのコピーとデータの移行

cp -r /opt/fastdfs_storage_data /データ
cp -r /opt/fastdfs_storage /データ
cp -r /opt/fastdfs_tracker /データ

（２）パスを変更する

ここでは、ファイルシステムの /etc/fdfs/storage.conf、mod_fastdfs.conf、client.conf、および tracker.conf ファイルを変更する必要があります。

• ストレージ

store_path0=/data/fastdfs_storage_data  
ベースパス=/data/fastdfs_storage

• :mod_fastdfs.conf は、

 store_path0=/data/fastdfs_storage_data (場所は2か所あります)
ベースパス=/data/fastdfs_storage

• /etc/fdfs/クライアント.conf

ベースパス=/data/fastdfs_tracker

• トラッカー

ベースパス=/data/fastdfs_tracker

M00 からストレージ ディレクトリへのシンボリック リンクを再確立します: ln -s /data/fastdfs_storage_data/data /data/fastdfs_storage_data/data/M00

（３）プロセスを終了し、ストレージサービス（トラッカーとストレージ）を再起動する

以下のコマンドを順番に実行します

pkill -9 fdfs
 サービス fdfs_trackerd 開始
 サービス fdfs_storaged 開始

（4）ファイル読み込みパスのnginx設定を変更する

場所 ~/group1/M00{
 ルート /data/fastdfs_storage_data/data;
 }

（5）nginxを再起動する

cd /opt/nginx/sbin
 ./nginx -s リロード

はい、問題は解決し、操作により写真やビデオを正常にアップロードできるようになりました。

この記事はWeChatの公開アカウント「Glacier Technology」から転載したものです。下のQRコードからフォローできます。この記事を転載する場合は、Glacier Technology 公式アカウントまでご連絡ください。