その他のクラスタ設定

メタデータ

クラスタ全体を読み取り専用に設定するには、次の設定を使用します：

  • cluster.blocks.read_only
  • （動的）クラスタ全体を読み取り専用にします（インデックスは書き込み操作を受け付けません）、メタデータは変更できません（インデックスの作成や削除）。デフォルトは false です。
  • cluster.blocks.read_only_allow_delete
  • （動的）cluster.blocks.read_only と同じですが、リソースを解放するためにインデックスを削除することができます。デフォルトは false です。

この設定に依存してクラスタへの変更を防ぐことはできません。cluster-update-settings API にアクセスできるユーザーは、クラスタを再び読み書き可能にすることができます。

クラスタシャード制限

クラスタ内のシャードの数には制限があり、これはクラスタ内のノードの数に基づいています。これは、暴走プロセスがパフォーマンスを損なうほど多くのシャードを作成するのを防ぐことを目的としています。極端な場合、クラスタが不安定になる可能性があります。

これらの制限は、暴走シャード作成から保護するための安全ネットとして意図されており、サイズの推奨ではありません。クラスタが安全にサポートできるシャードの正確な数は、ハードウェア構成やワークロードに依存し、デフォルトの制限よりも少ない場合があります。

これらの制限をデフォルト以上に増やすことはお勧めしません。シャードが多いクラスタは、通常の操作ではうまく動作しているように見えるかもしれませんが、ネットワークパーティションや予期しないノードの再起動などの一時的な中断から回復するのに非常に長い時間がかかる可能性があり、ローリング再起動やアップグレードなどのメンテナンス作業を行う際に問題が発生する可能性があります。

新しいインデックスの作成、インデックスのスナップショットの復元、または閉じたインデックスのオープンなどの操作が、クラスタ内のシャード数をこの制限を超えることになる場合、その操作はシャード制限を示すエラーで失敗します。これを解決するには、ノードを追加してクラスタをスケールアウトするか、いくつかのインデックスを削除してシャード数を制限内に戻します。

クラスタがすでに制限を超えている場合、ノードのメンバーシップの変更や設定の変更により、インデックスを作成またはオープンするすべての操作が失敗します。

クラスタシャード制限は、通常（非凍結）インデックスの場合、非凍結データノードごとに 1000 シャード、凍結インデックスの場合、凍結データノードごとに 3000 シャードのデフォルトです。すべてのオープンインデックスのプライマリシャードとレプリカシャードは、未割り当てシャードを含めて制限にカウントされます。たとえば、プライマリシャードが 5 つ、レプリカが 2 つのオープンインデックスは 15 シャードとしてカウントされます。閉じたインデックスはシャード数に寄与しません。

次の設定を使用して、クラスタシャード制限を動的に調整できます：

  • cluster.max_shards_per_node

  • （動的）クラスタのプライマリシャードとレプリカシャードの合計数を制限します。Elasticsearch は次のように制限を計算します：
    cluster.max_shards_per_node * number of non-frozen data nodes
    閉じたインデックスのシャードはこの制限にカウントされません。デフォルトは 1000 です。データノードがないクラスタは無制限です。
    Elasticsearch は、この制限が許可するよりも多くのシャードを作成するリクエストを拒否します。たとえば、cluster.max_shards_per_node 設定が 100 で、データノードが 3 つのクラスタは、シャード制限が 300 です。クラスタにすでに 296 シャードが含まれている場合、Elasticsearch はクラスタに 5 つ以上のシャードを追加するリクエストを拒否します。
    cluster.max_shards_per_node がデフォルトよりも高い値に設定されている場合、mmap カウント および オープンファイルディスクリプタ の制限も調整が必要になる場合があります。
    凍結シャードには独自の独立した制限があります。

  • cluster.max_shards_per_node.frozen
  • （動的）クラスタのプライマリシャードとレプリカ凍結シャードの合計数を制限します。Elasticsearch は次のように制限を計算します：
    cluster.max_shards_per_node.frozen * number of frozen data nodes
    閉じたインデックスのシャードはこの制限にカウントされません。デフォルトは 3000 です。凍結データノードがないクラスタは無制限です。
    Elasticsearch は、この制限が許可するよりも多くの凍結シャードを作成するリクエストを拒否します。たとえば、cluster.max_shards_per_node.frozen 設定が 100 で、凍結データノードが 3 つのクラスタは、凍結シャード制限が 300 です。クラスタにすでに 296 シャードが含まれている場合、Elasticsearch はクラスタに 5 つ以上の凍結シャードを追加するリクエストを拒否します。

これらの制限は、シャードを作成するアクションにのみ適用され、各ノードに割り当てられるシャードの数を制限するものではありません。各ノードに割り当てられるシャードの数を制限するには、cluster.routing.allocation.total_shards_per_node 設定を使用します。

ユーザー定義のクラスタメタデータ

ユーザー定義のメタデータは、クラスタ設定 API を使用して保存および取得できます。これは、インデックスを作成することなく、クラスタに関する任意の頻繁に変更されないデータを保存するために使用できます。このデータは、cluster.metadata. でプレフィックスされた任意のキーを使用して保存できます。たとえば、cluster.metadata.administrator というキーの下にクラスタの管理者のメールアドレスを保存するには、次のリクエストを発行します：

Python

  1. resp = client.cluster.put_settings(
  2.    persistent={
  3.    "cluster.metadata.administrator": "[email protected]"
  4.    },
  5. )
  6. print(resp)

Ruby

  1. response = client.cluster.put_settings(
  2.   body: {
  3.    persistent: {
  4.    'cluster.metadata.administrator' => '[email protected]'
  5.    }
  6.   }
  7. )
  8. puts response

Js

  1. const response = await client.cluster.putSettings({
  2.   persistent: {
  3.    "cluster.metadata.administrator": "[email protected]",
  4.   },
  5. });
  6. console.log(response);

コンソール

  1. PUT /_cluster/settings
  2. {
  3.   "persistent": {
  4.    "cluster.metadata.administrator": "[email protected]"
  5.   }
  6. }

ユーザー定義のクラスタメタデータは、機密情報や秘密情報を保存することを目的としていません。ユーザー定義のクラスタメタデータに保存された情報は、Cluster Get Settings API にアクセスできるすべての人に表示され、Elasticsearch のログに記録されます。

インデックストンボストーン

クラスタ状態は、削除されたインデックスを明示的に示すためにインデックストンボストーンを維持します。クラスタ状態で維持されるトンボストーンの数は、次の設定によって制御されます：

  • cluster.indices.tombstones.size
  • （静的）インデックストンボストーンは、削除が発生したときにクラスタの一部でないノードがクラスタに参加し、削除が発行されなかったかのようにインデックスを再インポートするのを防ぎます。クラスタ状態が巨大になるのを防ぐために、最後の cluster.indices.tombstones.size 回の削除のみを保持します。デフォルトは 500 です。ノードがクラスタから欠落し、500 回以上の削除を見逃すことが予想される場合は、これを増やすことができます。これは稀であると考えられるため、デフォルトです。トンボストーンはあまりスペースを占有しませんが、50,000 のような数はおそらく大きすぎると考えています。

Elasticsearch が現在のクラスタ状態に存在しないインデックスデータに遭遇した場合、それらのインデックスはダングリングと見なされます。たとえば、Elasticsearch ノードがオフラインの間に cluster.indices.tombstones.size インデックスを削除すると、これが発生する可能性があります。

この状況を管理するには、ダングリングインデックス API を使用できます。

ロガー

ロギングを制御する設定は、logger. プレフィックスを使用して 動的に 更新できます。たとえば、indices.recovery モジュールのロギングレベルを DEBUG に引き上げるには、このリクエストを発行します：

Python

  1. resp = client.cluster.put_settings(
  2.    persistent={
  3.    "logger.org.elasticsearch.indices.recovery": "DEBUG"
  4.    },
  5. )
  6. print(resp)

Ruby

  1. response = client.cluster.put_settings(
  2.   body: {
  3.    persistent: {
  4.    'logger.org.elasticsearch.indices.recovery' => 'DEBUG'
  5.    }
  6.   }
  7. )
  8. puts response

Js

  1. const response = await client.cluster.putSettings({
  2.   persistent: {
  3.    "logger.org.elasticsearch.indices.recovery": "DEBUG",
  4.   },
  5. });
  6. console.log(response);

コンソール

  1. PUT /_cluster/settings
  2. {
  3.   "persistent": {
  4.    "logger.org.elasticsearch.indices.recovery": "DEBUG"
  5.   }
  6. }

永続タスクの割り当て

プラグインは、永続タスクと呼ばれる一種のタスクを作成できます。これらのタスクは通常、長期間にわたるタスクであり、クラスタ状態に保存され、クラスタの完全な再起動後にタスクを復元できるようにします。

永続タスクが作成されるたびに、マスターノードがタスクをクラスタのノードに割り当てることを担当し、割り当てられたノードがタスクを取得してローカルで実行します。永続タスクをノードに割り当てるプロセスは、次の設定によって制御されます：

  • cluster.persistent_tasks.allocation.enable
  • （動的）永続タスクの割り当てを有効または無効にします：
    • all - （デフォルト）永続タスクをノードに割り当てることを許可します
    • none - いかなるタイプの永続タスクの割り当ても許可されません
      この設定は、すでに実行中の永続タスクには影響しません。この設定の影響を受けるのは、新しく作成された永続タスクや、ノードがクラスタを離れた後に再割り当てが必要なタスクのみです。
  • cluster.persistent_tasks.allocation.recheck_interval
  • （動的）マスターノードは、クラスタ状態が大きく変化したときに永続タスクを割り当てる必要があるかどうかを自動的にチェックします。ただし、メモリ使用量など、永続タスクをノードに割り当てるかどうかに影響を与える他の要因がある場合もありますが、クラスタ状態の変化を引き起こさない場合もあります。この設定は、これらの要因に反応するために割り当てチェックが行われる頻度を制御します。デフォルトは 30 秒です。最小許可値は 10 秒です。