私はglusterfsボリュームのステータスを確認しているだけで、パスのないスプリットブレインエントリを持つものがあります。
# gluster volume heal private_uploads info
Brick server01:/var/lib/glusterfs/brick01/uploads/
<gfid:4c0edafb-0c28-427c-a162-e530280b3396> - Is in split-brain
<gfid:42d62418-1be9-4f96-96c4-268230316869> - Is in split-brain
Number of entries: 2
Brick server02:/var/lib/glusterfs/brick01/uploads/
<gfid:42d62418-1be9-4f96-96c4-268230316869> - Is in split-brain
<gfid:4c0edafb-0c28-427c-a162-e530280b3396> - Is in split-brain
Number of entries: 2
どういう意味ですか?どうすれば修正できますか?
GlusterFS 3.5.9を実行しています。
# gluster --version
glusterfs 3.5.9 built on Mar 28 2016 07:10:17
Repository revision: git://git.gluster.com/glusterfs.git
RedHatが提供する スプリットブレインの管理に関する公式ドキュメント で述べたように、split-brainは、データまたはネットワーク設計内のサーバー、またはサーバー間でデータを通信および同期していないサーバーに基づく障害条件が原因で、スコープが重複している2つの個別のデータセットのメンテナンスに起因する可用性の不整合。また、レプリケート構成に適用される用語です。
「サーバーが相互にデータを通信および同期していないことに基づく障害状態」と言われていることに注意してください-可能性があるため-ただし、ノードが接続が失われる可能性があります。ピアはまだクラスタ内にあり、接続されている可能性があります。
スプリットブレインタイプ:
スプリットブレインには3種類ありますが、私が見る限り、スプリットブレインはエントリです。 3種類のスプリットブレインを説明するには:
データスプリットブレイン:スプリットブレイン下のファイルの内容は、レプリカペアごとに異なり、自動修復はできません。
メタデータsplit-brain:、ファイルのメタデータ(例、ユーザー定義の拡張属性)が異なり、自動修復ができません。
エントリsplit-brain:これは、ファイルのレプリカペアごとに異なるgfidがある場合に発生します。
GlusterFS内部ファイル識別子(GFID)は、クラスター全体で各ファイルに固有のuuidです。これは、通常のファイルシステムのiノード番号に似ています。ファイルのGFIDは、trusted.gfid
という名前のxattrに保存されます。 GFIDからのパスを見つけるために、GlusterFSによって提供される この公式記事 を読むことを強くお勧めします。
スプリットブレインの発生を防ぐ方法は複数ありますが、解決するには、対応するgfid-linkファイルを削除する必要があります。 gfid-linkファイルは、ブリックの最上位ディレクトリの.glusterfsディレクトリにあります。ちなみに、gfid-linksを削除する前に、そのブリックに存在するファイルへのハードリンクがないことを確認する必要があります。ハードリンクが存在する場合は、それらも削除する必要があります。次に、次のコマンドを実行して自己回復プロセスを使用できます。
それまでの間、スプリットブレイン状態のボリューム上のファイルのリストを表示するには、次のコマンドを使用できます。
# gluster volume heal VOLNAME info split-brain
また、複製されたボリュームの場合、ブリックがオフラインになり、オンラインに戻ったときに、すべてのレプリカを再同期するために自己修復が必要であることにも注意してください。
ボリュームとファイルの修復ステータスを確認するには、以下を使用できます。
# gluster volume heal VOLNAME info
バージョン3.5を使用しているため、自動修復機能はありません。したがって、前述の手順を実行した後、自己回復をトリガーする必要があります。そうするために:
修復が必要なファイルのみ:
# gluster volume heal VOLNAME
すべてのファイル:
# gluster volume heal VOLNAME full
これが問題の解決に役立つことを願っています。詳細については、公式ドキュメントをお読みください。乾杯。
私は document は十分に明確であると思います、それはあなたに同様の例を与えさえしました。
そしてGluesterfsのような癒しのコマンドのために
glusterボリュームの修復** VOLNAME **スプリットブレインlatest-mtime ** FILE **
FILEは、ボリュームのルートから見た完全なファイル名(または)ファイルのgfid-string表現のいずれかです。
だからあなたはそれについて心配する必要はありません。
そして GFIDをパスに変換 が言うように:
GlusterFS内部ファイル識別子(GFID)は、クラスター全体で各ファイルに固有のUUIDです。
この script は、どのファイル名がどのgfidに属しているかを通知しますが、脳の分割が発生しました。ファイル名がない可能性があります。
3.5を実行していて、半自動修復コマンドがないため、手動で競合を修正する必要がある場合があります。これは、通常、削除する必要があるgfidファイルを決定することを意味します。
どうすれば修正できますか?
スプリットブレイン解決は、 ここ のいずれかで見つけることができます。あまり役に立たない場合は、手動のハウツー ここ で十分です。ケースについては、 記事 も参考になります。
スプリットブレインを回避する方法
ネットワークパーティションに対する保護は、クォーラム投票アルゴリズムによって行われます。ホストに障害が発生した場合、またはノードが引き続き実行されているが相互に通信できないスプリットブレインシナリオがある場合、クラスター内の残りのノードは、監視ドライブにSCSI予約を配置するために競合します。スプリットブレインの場合、証人は、データのコピーを保持しているホストのどれが制御を引き継ぐべきかを決定するのに役立ちます。
いくつかの例
VMware VSANを使用すると、第3のホストまたはクラウドで実行される監視ドライブで2ノードのクラスターを実行できます。 ソース
StarWind Virtual SANスプリットブレインの問題を回避するためのクォーラム投票メカニズムも含む、Microsoftフェールオーバークラスターサービスを使用した2ノードセットアップで実行されます。 ソース
どちらの場合も、ハートビートネットワークは、ノードとクォーラム間の通信を提供/監視するために使用されます。スプリットブレインを回避するために、冗長なハートビートチャネルを使用することが必須であると思います。