web-dev-qa-db-ja.com

GlusterFSデータ破損の原因の特定

2つのサーバー間で構成したレプリケートされたGlusterFSボリュームにデータを書き込むときに、データが破損していました。

私が設定した構成は次のとおりです。

  • サーバーはUbuntu16.04とGlusterFSv3.10.6を実行しています
  • クライアントはUbuntu14.04とGlusterFSv3.10.6を実行しています
  • GlusterFSの2つのボリュームが構成されており、それぞれに2つのブリックが分散されており、各サーバーに1つのブリックがあります。
  • 各ブリックは、EXT4/LUKSファイルシステムを備えたMDADMRAID5アレイです。

  • 各ボリュームは、デフォルトのオプションとビットロット検出で構成されています。これらは次のとおりです。

    features.scrub: Active
features.bitrot: on
features.inode-quota: on
features.quota: on
nfs.disable: on

大きなディレクトリがクライアントマシンの1つのローカルファイルシステムから構成済みのGlusterFSボリュームのいずれかにコピーされると、データの破損が明らかになります。コピーされたファイルとソースファイルのmd5チェックサムを計算し、2つを比較すると、チェックサムの数が異なります。

いずれかのGlusterFSボリュームで手動で自己修復をトリガーすると、修復対象として識別されたファイルが表示されません。さらに、gluster volume bitrot <volname> scrub statusからの出力と、/var/log/glusterfs/bitd.logおよび/var/log/glusterfs/scrub.logの出力ログを見ると、エラーは識別されていないようです。

これらの問題は、最近、両方のボリュームが約10のクライアントによってかなり頻繁に使用された後、明らかになりました。

ボリュームをオフラインにして、基盤となるローカルファイルシステムを介して各ブリックにデータを直接書き込むことをテストしましたが、問題を再現できませんでした。

問題をさらにデバッグするために、VirtualBoxのVMで同様のセットアップを構成しましたが、問題を再現できませんでした。そのため、これらのエラーのこれらの原因が何であるかについて、私はかなり途方に暮れています。

私が実行できるさらなるデバッグ手順の提案、またはGlusterFSと私の構成に関する既知の問題をいただければ幸いです。

linuxubuntunetwork-shareglusterfs
3
PicoutputCls

GlusterFSを適切に動作させることができなかった後、メインサーバーがダウンした場合にある程度のフェイルオーバーを提供するために、ライブマスターとミラーを1時間ごとに同期して、セットアップをNFSに移動することにしました。

最近、ミラーを提供するサーバーでメンテナンスを実行していましたが、そのサーバーのNFSを介したデータ破損に関して同様の問題が発生していることが判明しました。

破損の考えられる原因を何度もデバッグした後、最終的にはネットワークインターフェイスへのハードウェアのオフロードまで追跡しました。SSH経由の大きなパケットでDisconnecting: Packet corruptエラーが発生することもありました。

SSHエラーの考えられる原因を調べたところ、次のUnixとLinuxの質問が見つかりました。 packet_write_waitパイプが壊れていてもトップが実行されたままですか？

このスレッドに関する議論の一部は、バグのあるネットワークインターフェイスドライバーが、セグメンテーションとrx/txチェックサムがインターフェイスに渡されるときにパケットの破損につながる可能性があることを示唆しています。

Rx/txとセグメンテーションオフロードを無効にし（次のブログ投稿の手順に従ってください： ssh切断パケットの破損の問題を解決する方法 ）、ネットワークの負荷が高いサーバーをテストした後、SSHエラーとデータが見つかりましたNFSを介した破損はなくなりました。

サーバーにGlusterFSが構成されていないため、これがデータ破損の原因であるかどうかを確認できません。ただし、NFSに移行した後も、サーバーの1つで問題が解決しないことを考えると、これが問題の原因である可能性があります。

ちなみに、ネットワークインターフェイスドライバーはe1000eドライバーを使用していました。その後、RHELバグトラッカーで次の議論を見つけました： Bug 504811 --e1000サイレントデータの破損 これは、 e1000eドライバー。

2
PicoutputCls

Glusterが破損がないと言った場合、ボリュームに検出可能な破損はない可能性があります。ただし、説明したとおり、これらのglusterボリュームには1を超えるデータレプリカはありません。複数のレピカ（理想的には3つのフルまたは2n + a）がないと、ノードに他のレプリカがないため、ノードがデータを破損したかどうかを判断できません。と比較してください。

これを回避する1つの方法は、デフォルトで無効になっているビットロット検出デーモンを有効にすることです。これにより、ファイルチェックサムを使用したデータスクラビングが可能になります。これは、gluster volume bitrot VOLNAME enableを使用して実行できます。検出されたエラーは、/ var/log/glusterfs /bitd.logおよび/var/log/glusterfs/scrub.logに記録されます。

これはいずれも飛行中の破損を説明するものではありません。

上記に何も表示されない場合は、クライアント自体をチェックし、クライアントとサーバーの両方からの関連ログを確認することができます。また、この破損が発生している場所を正確に特定するために、このパスに沿ってネットワーク、クライアント、またはサーバーのハードウェアをテストする必要がある場合もあります。うまくいけば、そこまで行く必要はありません。

0
Spooler