Writing in progress: Quorum(定足数)による決定

Elastic Stack Elasticsearch 公式ドキュメントを読む

Quorum-based decision making

Quorum-based decision making | Elasticsearch Guide [8.1] | Elastic

  • master-eligible nodeの基本的なタスクは次の二つ。
    • master nodeの選出
    • cluster状態の変更
  • この二つのタスクは例えいくつかのノードが使用不能になったとしても正しく動作することが求められる。
    • なぜならこれらのタスクが正常に完了しないと、cluster全体が機能しなくなるからである。
    • このような外的要因による不測の事態においても、システムが正常に稼働する性質のことをロバスト性というらしい。
  • Elasticsearchはmaster eligible nodeの定足数以上から成功を示す応答を受信し上記のタスクを進めることで、ロバスト性を担保する仕組みになっている。
    • ここでmaster eligible nodeが応答することをElasticsearchでは 「投票」（Voting） と言う。

  • master-eligible nodeは動的に追加、削除が可能。
  • master-eligible nodeの数の変化に伴い、Elasticsearchは最適な投票構成の設定を行い、堅牢性を維持しようとする。
    • 投票構成の設定についてはこちら
    • それぞれのタスクにおける決定は、投票構成の半数以上のノードが応答することにより行われる。
    • 通常、投票構成はmaster-eligible nodeと同じ数になるが異なる場合もある。

  • clusterを確実に利用し続けたいのであれば、半数以上の投票構成に含まれるnodeを一度に停止してはいけない。
    • 例えば3つ、または4つのmaster-eligible node構成でclusterを運用しているとき2つ以上が同時に停止するとclusterは正しく動作しなくなるかもしれない。
  • 通常、master-eligible nodeの追加・削除時にmaster nodeは直ぐclusterのステータスを更新し投票構成を適切な値に設定する。

Voting configurations

Voting configurations | Elasticsearch Guide [8.1] | Elastic

  • voting configurationはcluster stateとして管理、保存されている。
    • 次のAPIにより、現在の設定値を確認できる。
GET  /_cluster/state?filter_path=metadata.cluster_coordination.last_committed_config
  • 実際に試してみる。
    • 上記のリクエストのレスポンスは下記の通り。これらの値はnodeIdを表しているらしい。
{
  "metadata": {
    "cluster_coordination": {
      "last_committed_config": [
        "jRRXtWgsQ7atny8aKekv8A",
        "S7MNYHX8TJytYeTBxQGmOw",
        "TlLSYvQASLaxTeO6FCRd0Q"
      ]
    }
  }
}
  • 実際にcat apiで実際のnodeIdを取得してみる。
    • この時、全nodeは計4つでroleにmasterを付与しているノードは計3つのため、それらのnodeがvoting configurationに含まれているということになる。
[
  { "nodeId": "VgZvdqvXSKWeKxneZutYMQ" },
  { "nodeId": "TlLSYvQASLaxTeO6FCRd0Q" },
  { "nodeId": "jRRXtWgsQ7atny8aKekv8A" },
  { "nodeId": "S7MNYHX8TJytYeTBxQGmOw" }
]