投票構成
各Elasticsearchクラスターには投票構成があり、これは新しいマスターを選出したり、新しいクラスター状態をコミットしたりする際に、応答がカウントされるマスター候補ノードのセットです。投票構成内のノードの過半数(半数を超える)が応答した後にのみ、決定が行われます。
通常、投票構成は現在クラスター内に存在するすべてのマスター候補ノードのセットと同じです。しかし、異なる場合もあります。
クラスターが利用可能であることを確実にするためには、投票構成内のノードの半数以上を同時に停止してはいけません。投票ノードの半数以上が利用可能であれば、クラスターは通常通り機能し続けることができます。これは、マスター候補ノードが3つまたは4つある場合、クラスターはそのうちの1つが利用できないことに耐えられることを意味します。マスター候補ノードが2つ以下の場合、すべてが利用可能でなければなりません。
投票構成内のノードの半数以上を同時に停止すると、クラスターは再び定足数を形成するために十分なノードをオンラインに戻すまで利用できなくなります。クラスターが利用できない間、残りのノードはログにマスター ノードを発見または選出できないと報告します。詳細についてはトラブルシューティング発見を参照してください。
ノードがクラスターに参加または離脱すると、Elasticsearchはクラスターが可能な限り回復力を持つように投票構成に自動的に対応する変更を行います。クラスターからさらにノードを削除する前に、この調整が完了するのを待つことが重要です。詳細についてはクラスター内のノードの追加と削除を参照してください。
現在の投票構成はクラスター状態に保存されているため、現在の内容を次のように確認できます:
Python
resp = client.cluster.state(
filter_path="metadata.cluster_coordination.last_committed_config",
)
print(resp)
Ruby
response = client.cluster.state(
filter_path: 'metadata.cluster_coordination.last_committed_config'
)
puts response
Js
const response = await client.cluster.state({
filter_path: "metadata.cluster_coordination.last_committed_config",
});
console.log(response);
コンソール
GET /_cluster/state?filter_path=metadata.cluster_coordination.last_committed_config
現在の投票構成は、クラスター内のすべての利用可能なマスター候補ノードのセットと必ずしも同じではありません。投票構成を変更するには投票を行う必要があるため、ノードがクラスターに参加または離脱する際に構成を調整するのに時間がかかります。また、最も回復力のある構成には利用できないノードが含まれているか、利用可能なノードが含まれていない場合があります。このような状況では、投票構成はクラスター内の利用可能なマスター候補ノードのセットとは異なります。
通常、より大きな投票構成はより回復力があるため、Elasticsearchは通常、ノードがクラスターに参加した後にマスター候補ノードを投票構成に追加することを好みます。同様に、投票構成内のノードがクラスターを離れ、投票構成に含まれていない別のマスター候補ノードがクラスター内に存在する場合、これらの2つのノードを入れ替えることが望ましいです。投票構成のサイズはそのままですが、回復力は向上します。
ノードがクラスターを離れた後に自動的に投票構成からノードを削除するのは簡単ではありません。異なる戦略には異なる利点と欠点があるため、適切な選択はクラスターの使用方法によります。投票構成が自動的に縮小されるかどうかは、cluster.auto_shrink_voting_configuration
設定を使用して制御できます。
cluster.auto_shrink_voting_configuration
がtrue
(これはデフォルトで推奨される値)に設定されていて、クラスター内に少なくとも3つのマスター候補ノードがある場合、Elasticsearchはすべてのマスター候補ノードのうち1つを除いて健康であれば、クラスター状態の更新を処理することができます。
Elasticsearchが複数のノードの喪失を許容する場合がありますが、これはすべての障害シーケンスの下で保証されるものではありません。cluster.auto_shrink_voting_configuration
設定がfalse
の場合、離脱したノードを投票構成から手動で削除する必要があります。希望する回復力を達成するにはvoting exclusions APIを使用してください。
どのように構成されていても、Elasticsearchは「https://en.wikipedia.org/wiki/Split-brain_(computing)[スプリットブレイン]」の不整合に苦しむことはありません。`````cluster.auto_shrink_voting_configuration`````設定は、ノードの一部が故障した場合の可用性と、ノードがクラスターに参加または離脱する際に実行しなければならない管理タスクにのみ影響します。
マスター候補ノードの偶数
クラスター内には通常、奇数のマスター候補ノードが必要です。偶数の場合、Elasticsearchは投票構成から1つのノードを除外して奇数のサイズを確保します。この除外はクラスターの障害耐性を低下させるものではありません。実際には、わずかに改善されます:クラスターがネットワーク分割により2つの同じサイズの半分に分かれた場合、投票構成の過半数を含む半分が操作を続けることができます。すべてのマスター候補ノードからの投票がカウントされていた場合、どちらの側もノードの厳密な過半数を含まないため、クラスターは進展できなくなります。
たとえば、クラスターに4つのマスター候補ノードがあり、投票構成にすべてが含まれている場合、クオラムベースの決定には少なくとも3つの投票が必要です。この状況では、クラスターは1つのマスター候補ノードの喪失にしか耐えられません。このクラスターが2つの同じ半分に分割された場合、どちらの半分も3つのマスター候補ノードを含まないため、クラスターは進展できなくなります。しかし、投票構成に4つのマスター候補ノードのうち3つだけが含まれている場合、クラスターは依然として1つのノードの喪失に完全に耐えられますが、クオラムベースの決定には3つの投票ノードのうち2つからの投票が必要です。偶数に分割された場合、1つの半分には3つの投票ノードのうち2つが含まれるため、その半分は利用可能なままです。
初期投票構成の設定
新しいクラスターが初めて起動するとき、最初のマスターノードを選出する必要があります。この選挙を行うためには、投票がカウントされるマスター候補ノードのセットを知っている必要があります。この初期投票構成はブートストラップ構成として知られ、クラスターのブートストラッププロセスで設定されます。
ブートストラップ構成が最初の選挙でどのノードが投票すべきかを正確に特定することが重要です。クラスターにどれだけのノードが必要かを期待して各ノードを構成するだけでは不十分です。また、ブートストラップ構成はクラスターの外部から来る必要があることにも注意が必要です:クラスターが自分自身でブートストラップ構成を正しく決定する安全な方法はありません。
ブートストラップ構成が正しく設定されていない場合、新しいクラスターを起動すると、1つのクラスターではなく2つの別々のクラスターが形成されるリスクがあります。この状況はデータ損失を引き起こす可能性があります:何かが間違っていることに気づく前に両方のクラスターを使用し始めてしまう可能性があり、後でそれらを統合することは不可能です。
各ノードを特定のクラスターサイズを期待するように構成することの問題を示すために、3ノードのクラスターを起動することを想像してください。各ノードは3ノードのクラスターの一部になることを知っています。3ノードの過半数は2ですので、通常、最初の2つのノードが互いに発見し、クラスターを形成し、3番目のノードが短時間後に参加します。しかし、誤って4つのノードが起動された場合、この場合、2つの別々のクラスターを形成するのに十分なノードがあります。もちろん、各ノードが手動で起動される場合、あまり多くのノードが起動されることは考えにくいです。しかし、自動化されたオーケストレーターを使用している場合、この状況に陥る可能性は確かにあります。特に、オーケストレーターがネットワーク分割などの障害に対して回復力がない場合はなおさらです。
初期のクオラムは、クラスター全体が初めて起動する際にのみ必要です。確立されたクラスターに参加する新しいノードは、選出されたマスターから必要なすべての情報を安全に取得できます。以前にクラスターの一部であったノードは、再起動時に必要なすべての情報をディスクに保存しています。