第31章 ネットワークパーティションの処理 (スプリットブレイン)
ネットワークパーティションは、クラスターが 2 つ以上のパーティションに分割される場合に作成されます。結果として、各パーティションのノードは他のパーティションのノードを見つけたり、そのノードと通信したりできません。この結果、意図せずにネットワークが分割されます。
Red Hat JBoss Data Grid などの分散システムでネットワークパーティションが発生した場合は、CAP (ブリュワーの) 定理を使用します。CAP 定理によると、ネットワークパーティション (P) の発生時に、分散システムがデータの整合性 (C) または利用可能性 (A) のいずれかを提供できます (ただし、両方は提供できません)。
デフォルトでは、JBoss Data Grid でパーティション処理は無効になっています。ネットワークパーティションの発生時に、パーティションは整合性 (C) を犠牲にして利用可能性 (A) を維持します。
ただし、パーティション処理が有効な場合は、JBoss Data Grid により利用可能性 (A) よりも整合性 (C) が優先されます。
Red Hat JBoss Data Grid は、分割されたネットワークを修復するためにプライマリーパーティションストラテジーを提供します。ネットワークパーティションが発生し、キャッシュが 2 つ以上のパーティションに分割されると、最大 1 つのパーティションがプライマリーパーティションになり (利用可能な状態)、他のパーティションがセカンダリーパーティションとして指定されます (劣化モードになります)。パーティションがマージされ 1 つのキャッシュに戻ると、プライマリーパーティションはすべてのセカンダリーパーティションの参照として使用されます。セカンダリーパーティションのすべてのメンバーは現在の状態の情報を削除し、プライマリーパーティションのメンバーからの最新の状態情報で置き換える必要があります。分割時にプライマリーパーティションがない場合は、各ノードの状態が正しいと見なされます。
JBoss Data Grid では、キャッシュは複数のノードに格納されたデータから構成されます。ノードで障害が発生した場合にデータ損失を防ぐために、JBoss Data Grid は複数のノードでデータアイテムをレプリケートします。分散モードでは、この冗長性は
numOwners 設定属性を使用して設定され、キャッシュ内の各キャッシュエントリーのレプリカの数が指定されます。結果として、障害が発生したノードの数が numOwners の値よりも小さい限り、JBoss Data Grid は損失データのコピーを保持し、復元できます。
注記
ただし、JBoss Data Grid のレプリケーションモードでは、各ノードにキャッシュ内の各データアイテムのコピーが含まれるため、
numOwners は常にキャッシュ内のノードの数と同じになります。
場合によっては、
numOwners の値よりも大きいノードの数がキャッシュからなくなることがあります。この一般的な理由は、以下の 2 つのです。
- スプリットブレイン: 通常は、ルーターのクラッシュの結果、キャッシュが 2 つ以上のパーティションに分割されます。各パーティションは他のパーティションに関係なく動作し、各パーティションには同じデータの別のバージョンが含まれることがあります。
- 連続クラッシュノード:
numOwnersの値よりも大きいノードの数が何らかの理由で連続してクラッシュします。JBoss Data Grid は、クラッシュの間に状態を適切に分散できず、結果として部分的なデータ損失が発生します。
31.1. スプリットブレインの検出および回復
スプリットブレインがデータグリッドで発生した場合、各ネットワークパーティションには、削除された他のパーティションからノードとともに独自の JGroups ビューがインストールされます。パーティションはお互いを認識しないため、ネットワークが分割されたパーティションの数を判断することはできません。Red Hat JBoss Data Grid では、1 つまたは複数のノードが明示的なメッセージを送信せずに JGroups キャッシュから消失した場合に (実際の原因は物理的 (スイッチのクラッシュやケーブルの障害など) または仮想的 (stop-the-world ガーベッジコレクション))、キャシュが予期せずに分割されることを前提とします。
新しく分割された各パーティションは独立して稼働し、同じデータエントリーの競合アップデートを保存することがあるため、この状態は危険です。
パーティション処理モードが有効であり (手順については「パーティション処理の設定」を参照)、JBoss Data Grid が 1 つまたは複数のノードにアクセスできないことを疑う場合は、各パーティションで再調整がすぐに開始されませんが、代わりに劣化モードに切り替えるかどうかがチェックされます。劣化モードに切り替えるには、以下の以下のいずれかの条件が満たされている必要があります。
- 少なくとも 1 つのセグメントがすべての所有者を失います。つまり、
numOwnersの値以上の数のノードが JGroups ビューから脱退します。 - パーティションには、最新の安定したトポロジーの過半数のノード (半分超) が含まれます。安定したトポロジーは、再調整操作が正常に行われ、コーディネーターが追加の再調整が必要ないことを確認するたびに更新されます。
いずれの条件も満たさない場合は、パーティションが引き続き正常に稼働し、JBoss Data Grid がノードを再調整しようとします。これらの条件に基づき、最大 1 つのパーティションを利用可能モードのままにすることができます。他のパーティションは劣化モードになります。
パーティションが劣化モードになると、エントリーのすべての所有者 (コピー) が同じパーティション内のノードに存在するエントリーの読み取り/書き込みアクセスのみが許可されます。1 人または複数の所有者がプラットフォームから消失したノードに存在するエントリーの読み取りおよび書き込み要求が
AvailabilityException で拒否されます。
注記
制限としては、2 つのパーティションが分離パーティションとして開始され、マージしない場合、これらのパーティションは不整合なデータを読み取り、書き込むことができます。JBoss Data Grid はこのようなパーティションを分割パーティションと認識しません。
警告
データ整合性は、キャッシュが物理的に分割されたとき (t1) から JBoss Data Grid が接続の変更を検出し、パーティションの状態を変更するとき (t2) までの間で損なわれることがあります。
- 物理的な分割が行われたとき (t1) に処理中だったトランザクション書き込みが一部の所有者でロールバックされることがあります。また、これにより、このような書き込みで影響を受けたエントリーのコピー (パーティションの再参加後) 間で不整合が発生することがあります。ただし、t1 後に開始されたトランザクション書き込みは予想どおりに失敗します。
- 書き込みが非トランザクションである場合は、この時間枠の間に、(物理的に分割され、パーティションがまだ劣化状態ではないため) マイナーパーティションにのみ書き込まれた値がパーティションの再参加時に失われることがあります (このマイナーパーティションは再参加時にプライマリー (利用可能な) パーティションから状態を受け取ります)。パーティションが再参加時に状態を受け取らない場合 (つまり、すべてのパーティションが劣化状態)、値は失われませんが、不整合が維持されることがあります。
- マイナーパーティションが劣化状態になるまでエントリーが引き続き利用可能になるため、この移行期間中にマイナーパーティションで無効な読み取りが発生することもあります。
ネットワークパーティションの実行後にパーティションがマージされる場合は、以下の状況が発生します。
- ネットワークパーティション中にいずれかのパーティションが利用可能な場合は、参加パーティションが消去され、利用可能な (パーティション) パーティションから参加ノードへの状態転送が実行されます。
- すべての参加パーティションがスプリットブレインの間に劣化状態にある場合は、マージ中に状態転送が実行されません。結合されたキャッシュは、メージパーティションに最新の安定したトポロジー (トポロジー ID が最大のトポロジー) の過半数のメンバーが含まれ、各セグメントに対して少なくとも 1 の所有者がいる (つまり、キーは失われません) 場合にのみ利用可能になります。
警告
パーティションがマージを開始したとき (t1) からマージが完了したとき (t2) の間に、ノードは一連のマージイベントを介して再接続されます。この時間枠の間に、ノードがクラスターを一時的に脱退したとして報告されることがあります。トランザクションキャッシュの場合、t1 から t2 の時間枠にこのようなノードが他のノードにまたがるトランザクションを実行すると、このトランザクションがリモートノードで実行されないことがあります (ただし、元のノードでは正常に実行されます)。結果として、このトランザクションをコミットしなかったノードで影響を受けたエントリーの値が無効になることがあります。
t2 の後に、すべてのノードでマージが完了すると、この状況は以降のトランザクションで発生しません。ただし、t1 と t2 の間の時間枠に実行中のトランザクションによって影響を受けたエントリーで発生した不整合は、これらのエントリーが結果的に更新または削除されるまで解決されません。それまでは、影響を受けたこのようなエントリーの読み取りによって無効な値が返されることがあります。
