ノードロール

Solr のノードは通常、レプリカのホスティング、インデクシングとクエリのプッシュダウン実行、コレクション管理タスクなど、さまざまなタイプの操作を実行できます。これらの機能を特定の専用ノードに隔離したクラスタをセットアップするには、ノードロールの概念を使用できます。

定義

ノードロール

ロールとは、ノードが特定の機能を実行できることを示す、ノードの指定です。

モード

すべてのロールには、ノードが使用できるモードのリストがあります。単純なもの (例: ["on", "off"]) またはより詳細なもの (例: ["allowed", "preferred", "disallowed"]) があります。

ロール

ノードのロールを指定するには、次のパラメータを使用して Solr ノードを起動する必要があります。

表 1. 起動パラメータ
パラメータ	値	必須？	デフォルト
solr.node.roles	このノードのロールのカンマ区切りリスト (形式: `<role>:<mode>`)。例: `-Dsolr.node.roles=data:on,overseer:allowed` または `-Dsolr.node.roles=overseer:preferred`	いいえ	`data:on,overseer:allowed`

ノードが solr.node.roles パラメータなしで起動された場合、データロールがオンになり、オーバーシーアロールが許可されていると想定されます。以前にロールを使用したことがない場合は、これらのロールに関連付けられた機能に対応するために、起動パラメータを変更する必要はおそらくありません。.

表 2. サポートされているロール
ロール	モード
`data`	on, off
`overseer`	allowed, preferred, disallowed
`coordinator`	on, off

`data` ロール

このロールを持つノード (モード "on") は、コレクションのシャードとレプリカをホストできます。

`overseer` ロール

このロールを持つノードは、オーバーシーアノードの役割を実行できます (モードが disallowed でない限り)。1 つ以上のノードがオーバーシーアロールを preferred モードで持っている場合、オーバーシーアリーダーはこれらのノードのいずれかから選出されます。優先オーバーシーアとして指定されたノードがない場合、またはそのようなノードが稼働していない場合、オーバーシーアリーダーは、オーバーシーアロールを allowed モードで持っているノードのいずれかから選出されます。オーバーシーアロール (許可または優先) で指定されたすべてのノードがダウンしている場合、クラスタはオーバーシーアなしで残されます。

`coordinator` ロール

このロールを持つノードは、クエリが実行されたときに、クラスタ内のすべてのコレクションのレプリカを持っているかのように動作できます。ワークフローは次のとおりです

クラスタに非常に多数のシャードを持つコレクションがある場合、*`データノード`* で分散リクエストを実行すると、次のようになります。

大量のヒープ使用量
頻繁な GC 一時停止

このような場合は、少数の専用ノードを **coordinator** ロールで起動し、そのノードにクエリを送信して、データノードの断続的で予測不可能な負荷を回避できます。コーディネーターノードはステートレスであり、データをホストしません。そのため、データの損失やダウンタイムなしに、コーディネーターノードを作成および破棄できます。.

`coordinator` ノードのワークフロー

設定セット **configset-A** を使用する **coll-A** のリクエストがコーディネーターノードに到着します
設定セット **configset-A** を使用するコアが存在するかどうかを確認します。存在する場合、そのコアは **coll-A** のレプリカとして機能し、**coll-A** のすべてのシャードに分散リクエストを実行して応答を送信します
そのようなコアが存在しない場合、合成コレクション.sys.COORDINATOR-COLL-configset-Aが存在し、そのコレクションのレプリカがローカルに存在するかどうかを確認します。存在しない場合は、コレクションとレプリカがオンザフライで作成され、ステップ1に進みます。

使用例

クラスタ内のノードが大量のクエリまたはインデックス作成負荷を受けている場合、Overseerリーダーノードはコレクション管理タスクを効率的に実行できないことがあります。Overseer専用のノードを用意するのが妥当な場合があります。このような効果は、次のように実現できます。

クラスタ内のほとんどのノード（データノード）は、-Dsolr.node.roles=data:on,overseer:allowed で起動します（または、solr.node.roles のデフォルト値が同じであるため、パラメータなしで起動します）。
1つ以上のノード（Overseer専用ノード）は、-Dsolr.node.roles=overseer:preferred（または-Dsolr.node.roles=overseer:preferred,data:off）で起動できます。
1つ以上の専用コーディネーターノードは、-Dsolr.node.roles=coordinator:on,data:off で起動できます。

この構成では、このような専用ノードは、他のデータノードよりもCPU、メモリ、またはディスク容量が少ないハードウェア（これらはステートレスノードであるため）にプロビジョニングできますが、クラスタは最適に動作します。何らかの理由でOverseer専用ノードがダウンした場合、Overseerリーダーはデータノードのいずれかから選出されます（Overseerが「allowed」モードになっているため）。Overseer専用ノードのいずれかが再びバックアップされると、Overseerリーダーシップのために再選出されます。

専用のコーディネーターノードは、十分なメモリを搭載しつつ、ストレージ容量は非常に少ない状態でプロビジョニングできます。また、ステートレスであるため、必要に応じて起動および停止できます。

ロールAPI

GET /api/cluster/node-roles/supported

このクラスタでサポートされているロールと、それらのサポートされているモードのリストを取得します。

入力

curl https://127.0.0.1:8983/api/cluster/node-roles/supported

出力

{
  "supported-roles":{
    "data":{
      "modes":["off",
        "on"]
    },
    "overseer":{
      "modes":["disallowed",
        "allowed",
        "preferred"]
    }
  }
}

GET /api/cluster/node-roles

クラスタ内のすべてのノードについて、現在のノードロールの割り当てを取得します。

入力

curl https://127.0.0.1:8983/api/cluster/node-roles

出力

{
  "node-roles":{
    "data":{
      "off":["solr2:8983_solr"],
      "on":["solr1:8983_solr"]
    },
    "overseer":{
      "allowed":["solr1:8983_solr"],
      "disallowed":[],
      "preferred":["solr2:8983_solr"]
    }
  }
}

GET /api/cluster/node-roles/role/{role}

指定されたロールの現在のノードロールの割り当てを取得します。

入力

https://127.0.0.1:8983/api/cluster/node-roles/role/data

出力

{
  "node-roles":{
    "data":{
      "off":["solr2:8983_solr"],
      "on":["solr1:8983_solr"]
    }
  }
}

入力

https://127.0.0.1:8983/api/cluster/node-roles/role/data/off

出力

{
  "node-roles":{
    "data":{
      "off":["solr2:8983_solr"]
    }
  }
}

GET /api/cluster/node-roles/node/{node}

指定されたノードの現在のノードロールの割り当てを取得します。

入力

curl https://127.0.0.1:8983/api/cluster/node-roles/node/solr1:8983_solr

出力

{
  "data":"on",
  "overseer":"allowed"
}

ノードロール

定義