GlusterFSはパスのない脳を分割しますが、それはどういう意味ですか？

私はちょうど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が提供する、スプリットブレインが状態である場合には、いずれかのためにネットワーク設計内のサーバーの範囲内の重複を持つ2つの別々のデータセットのメンテナンスからのデータや可用性の矛盾の発信元、または、サーバーが相互にデータを通信および同期していないことに基づく障害状態。また、レプリケート構成に適用される用語です。

「データを相互に通信および同期していないことに基づく障害状態」 -何らかの可能性があるため- と言われていることに注意してください。ただし、ノードが接続を失う可能性があるわけではありません。ピアはまだクラスター内にあり、接続されている可能性があります。

スプリットブレインタイプ：

スプリットブレインには3つの異なるタイプがありますが、私が見ることができるのはエントリスプリットブレインです。3種類のスプリットブレインを説明するには：

• データのスプリットブレイン：スプリットブレインの下のファイルの内容はレプリカペアごとに異なり、自動修復は不可能です。

• メタデータsplit-brain：、ファイルのメタデータ（例、ユーザー定義の拡張属性）は異なり、自動修復はできません。

• エントリのスプリットブレイン：ファイルのレプリカペアごとにgfidが異なる場合に発生します。

GFIDとは何ですか？

GlusterFS内部ファイル識別子（GFID）は、クラスター全体で各ファイルに固有のuuidです。これは、通常のファイルシステムのiノード番号に似ています。ファイルのGFIDは、という名前のxattrに保存されますtrusted.gfid。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

これが問題の解決に役立つことを願っています。詳細については、公式ドキュメントをご覧ください。乾杯。

文書はかなり十分に明確であると思います、それはあなたにも同様の例を与えました。

また、Gluesterfsのヒーリングコマンドなど

gluster volume heal ** VOLNAME ** split-brain latest-mtime ** FILE **

FILEは、ボリュームのルートから見た完全なファイル名（または）ファイルのgfid-string表現のいずれかです。

ですから、それについて心配する必要はありません。

そして、として変換パスにGFIDは言います：

GlusterFS内部ファイル識別子（GFID）は、クラスター全体で各ファイルに固有のuuidです。

このスクリプトは、どのファイル名がどのgfidに属しているかを示す場合がありますが、脳の分裂が起こったため、ファイル名がない場合があります。

3.5を実行しており、セミオートヒーリングコマンドがないため、通常は手動で競合を修正する必要があります。これは通常、削除する必要があるgfidファイルを決定することを意味します。

どうすれば修正できますか？

スプリットブレインの解決方法は、こちらで確認できます。あまり役に立たない場合は、ここのマニュアルのハウツーで仕事をしてください。この場合、この記事も参考になります。

スプリットブレインを回避する方法。

ネットワークパーティションに対する保護は、クォーラム投票アルゴリズムによって行われます。ホストで障害が発生した場合、またはノードが引き続き実行されているが相互に通信できないスプリットブレインシナリオがある場合、クラスター内の残りのノードは、ミラーリング監視ドライブにSCSI予約を配置するために競合します。スプリットブレインの場合、目撃者は、データのコピーを保持しているホストのどれが制御を引き継ぐかを決定するのに役立ちます。

いくつかの例。

VMware VSANでは、3番目のホストまたはクラウドで実行されている監視ドライブで2ノードクラスターを実行できます。ソース

StarWind Virtual SANは、Microsoft Failover Clusterサービスを使用する2ノードセットアップで実行されます。これには、スプリットブレインの問題を回避するためのクォーラム投票メカニズムも含まれています。ソース

どちらの場合も、ハートビートネットワークを使用して、ノードとクォーラム間の通信を処理/監視します。スプリットブレインを回避するために、冗長なハートビートチャネルを使用することが必須であると考えています。

スプリットブレインは、クラスターの2つのノードが切断されると発生します。各ノードは、他のノードが機能していないと見なします。

修正するには、2つのノードが互いに通信していない理由を理解する必要があります。