ノード

Elasticsearchのインスタンスを起動するたびに、ノードを起動しています。接続されたノードのコレクションはクラスターと呼ばれます。単一のElasticsearchノードを実行している場合、ノードのクラスターは1つです。

クラスター内のすべてのノードは、デフォルトでHTTPおよびトランスポートトラフィックを処理できます。トランスポート層はノード間の通信専用に使用され、HTTP層はRESTクライアントによって使用されます。

すべてのノードは、クラスター内の他のすべてのノードについて知っており、クライアントリクエストを適切なノードに転送できます。

Elasticsearchノードのパフォーマンスは、しばしば基盤となるストレージのパフォーマンスによって制限されます。インデックス作成および検索のためにストレージを最適化するための推奨事項を確認してください。

ノードの役割

ノードの役割は、node.rolesをelasticsearch.ymlで設定することによって定義します。node.rolesを設定すると、ノードには指定した役割のみが割り当てられます。node.rolesを設定しない場合、ノードには次の役割が割り当てられます：

  • master
  • data
  • data_content
  • data_hot
  • data_warm
  • data_cold
  • data_frozen
  • ingest
  • ml
  • remote_cluster_client
  • transform
  2. -  `````master
    1. または  
    2. `````data

一部のElastic Stack機能は、特定のノード役割も必要とします：

  • クロスクラスター検索およびクロスクラスター複製にはremote_cluster_client役割が必要です。
  • スタックモニタリングおよびインジェストパイプラインにはingest役割が必要です。
  • Fleet、Elastic Securityアプリ、および変換にはtransform役割が必要です。これらの機能でクロスクラスター検索を使用するにはremote_cluster_client役割も必要です。
  • 異常検出などの機械学習機能にはml役割が必要です。

クラスターが成長し、特に大規模な機械学習ジョブや継続的な変換がある場合は、専用のマスター候補ノードを専用のデータノード、機械学習ノード、および変換ノードから分離することを検討してください。

  • マスター候補ノード
  • master役割を持つノードで、クラスターを制御するマスターノードとして選出される資格がある。
  • データノード
  • 複数のデータ役割のいずれかを持つノード。データノードはデータを保持し、CRUD、検索、集計などのデータ関連の操作を実行します。一般的なdata役割を持つノードは、専門のデータノード役割のいずれかを満たすことができます。
  • インジェストノード
  • ingest役割を持つノード。インジェストノードは、インデックス作成前にドキュメントを変換および強化するためにインジェストパイプラインをドキュメントに適用できます。重いインジェスト負荷がある場合は、専用のインジェストノードを使用し、ingest役割をmasterまたはdata役割を持つノードから除外することが理にかなっています。
  • リモート候補ノード
  • remote_cluster_client役割を持つノードで、リモートクライアントとして機能する資格があります。
  • 機械学習ノード
  • ml役割を持つノード。機械学習機能を使用する場合、クラスター内に少なくとも1つの機械学習ノードが必要です。詳細については、機械学習設定およびElastic Stackにおける機械学習を参照してください。
  • 変換ノード
  • transform役割を持つノード。変換を使用する場合、クラスター内に少なくとも1つの変換ノードが必要です。詳細については、変換設定およびデータの変換を参照してください。

コーディネーティングノード

検索リクエストやバルクインデックスリクエストのようなリクエストは、異なるデータノードに保持されているデータを含む場合があります。たとえば、検索リクエストは、クライアントリクエストを受信したノード、すなわちコーディネーティングノードによって調整される2つのフェーズで実行されます。

スキャッターフェーズでは、コーディネーティングノードがデータを保持するデータノードにリクエストを転送します。各データノードはローカルでリクエストを実行し、その結果をコーディネーティングノードに返します。ギャザーフェーズでは、コーディネーティングノードが各データノードの結果を単一のグローバル結果セットに集約します。

すべてのノードは暗黙的にコーディネーティングノードです。これは、node.rolesを介して明示的に空の役割リストを持つノードが、無効にできないコーディネーティングノードとしてのみ機能することを意味します。その結果、そのようなノードはギャザーフェーズを処理するために十分なメモリとCPUを持っている必要があります。

マスター候補ノード

マスターノードは、インデックスの作成や削除、クラスターの一部であるノードの追跡、どのシャードをどのノードに割り当てるかを決定するなど、軽量なクラスター全体のアクションを担当します。安定したマスターノードを持つことは、クラスターの健康にとって重要です。

voting-only nodeでない任意のマスター候補ノードは、マスター選挙プロセスによってマスターノードとして選出される可能性があります。

マスターノードは、データノードと同様に、再起動を通じて持続する内容を持つpath.dataディレクトリを持っている必要があります。これは、クラスターのメタデータが保存される場所です。クラスターのメタデータは、データノードに保存されているデータを読み取る方法を説明しているため、これが失われると、データノードに保存されているデータを読み取ることができなくなります。

専用マスター候補ノード

選出されたマスターノードがその責任を果たすために必要なリソースを持つことは、クラスターの健康にとって重要です。選出されたマスターノードが他のタスクで過負荷になると、クラスターはうまく機能しません。マスターを他のタスクで過負荷にしない最も信頼性の高い方法は、すべてのマスター候補ノードを専用マスター候補ノードとして構成し、master役割のみを持たせて、クラスターの管理に集中できるようにすることです。マスター候補ノードは、クライアントからのリクエストをクラスター内の他のノードにルーティングするコーディネーティングノードとしても機能しますが、この目的のために専用のマスターノードを使用すべきではありません。

小規模または軽負荷のクラスターは、マスター候補ノードが他の役割と責任を持っている場合でもうまく機能することがありますが、クラスターが数ノードを超えると、通常は専用のマスター候補ノードを使用することが理にかなっています。

専用のマスター候補ノードを作成するには、次のように設定します：

Yaml

  1. node.roles: [ master ]

投票専用マスター候補ノード

投票専用マスター候補ノードは、マスター選挙に参加しますが、クラスターの選出されたマスターノードとして機能しません。特に、投票専用ノードは選挙でのタイブレーカーとして機能できます。

投票専用ノードを「マスター候補」と呼ぶのは混乱を招くかもしれませんが、そのようなノードは実際にはマスターになる資格がありません。この用語は歴史的な結果の不幸な結果です：マスター候補ノードは、選挙に参加し、クラスター状態の公開中に特定のタスクを実行するノードであり、投票専用ノードは選出されたマスターになることができなくても同じ責任を持っています。

マスター候補ノードを投票専用ノードとして構成するには、masterおよびvoting_onlyを役割のリストに含めます。たとえば、投票専用データノードを作成するには：

Yaml

  1. node.roles: [ data, master, voting_only ]
  2. 高可用性（HA）クラスターには、少なくとも3つのマスター候補ノードが必要で、そのうち少なくとも2つは投票専用ノードでない必要があります。このようなクラスターは、ノードの1つが失敗してもマスターノードを選出できます。  
  4. 投票専用マスター候補ノードは、クラスター内で他の役割も果たすことができます。たとえば、ノードはデータノードと投票専用マスター候補ノードの両方であることができます。*専用*投票専用マスター候補ノードは、クラスター内で他の役割を果たさない投票専用マスター候補ノードです。専用の投票専用マスター候補ノードを作成するには、次のように設定します：
  7. #### Yaml
  9. ``````yaml
  10. node.roles: [ master, voting_only ]
  11. `

専用の投票専用ノードは、クラスターの選出されたマスターとして機能しないため、真のマスターノードよりも少ないヒープとより弱いCPUを必要とする場合があります。ただし、すべてのマスター候補ノード、投票専用ノードを含むは、クラスター状態の更新を公開するための重要な経路にあります。クラスター状態の更新は、通常、インデックス作成や検索などのパフォーマンスに重要なワークロードとは独立していますが、インデックスの作成やロールオーバー、マッピングの更新、障害後の回復などの管理活動には関与しています。これらの活動のパフォーマンス特性は、各マスター候補ノードのストレージの速度、および選出されたマスターノードとクラスター内の他のノード間のネットワーク接続の信頼性とレイテンシの関数です。したがって、クラスター内のノードに利用可能なストレージとネットワーキングが、パフォーマンス目標を満たすのに十分であることを確認する必要があります。

データノード

データノードは、インデックスされたドキュメントを含むシャードを保持します。データノードは、CRUD、検索、集計などのデータ関連の操作を処理します。これらの操作はI/O、メモリ、CPUに負荷がかかります。これらのリソースを監視し、過負荷の場合はデータノードを追加することが重要です。

専用のデータノードを持つ主な利点は、マスターとデータの役割を分離することです。

マルチティアデプロイメントアーキテクチャでは、特定のティアにデータノードを割り当てるために専門のデータ役割を使用します：data_content、data_hot、data_warm、data_cold、またはdata_frozen。ノードは複数のティアに属することができます。

すべてのティアにノードを含めたい場合、またはクラスターが複数のティアを使用しない場合は、一般的なdata役割を使用できます。

クラスターシャード制限により、ノードごとに1000の非凍結シャードと、専用の凍結ノードごとに3000の凍結シャードの作成が制限されます。必要なシャードの数を処理するために、クラスター内の各タイプのノードが十分にあることを確認してください。

特定のティアに専門のデータ役割を使用してノードを割り当てる場合、一般的なdata役割も割り当てるべきではありません。一般的なdata役割は、専門のデータ役割よりも優先されます。

一般的なデータノード

一般的なデータノードはすべてのコンテンツティアに含まれます。

専用の一般的なデータノードを作成するには、次のように設定します：

Yaml

  1. node.roles: [ data ]

コンテンツデータノード

コンテンツデータノードはコンテンツティアの一部です。コンテンツティアに保存されているデータは、一般的に製品カタログや記事アーカイブなどのアイテムのコレクションです。時系列データとは異なり、コンテンツの値は時間とともに比較的一定であるため、年齢が増すにつれて異なるパフォーマンス特性を持つティアに移動することは意味がありません。コンテンツデータは通常、長期間のデータ保持要件があり、古いデータであっても迅速にアイテムを取得できることが望まれます。

コンテンツティアのノードは通常、クエリパフォーマンスの最適化が行われており、IOスループットよりも処理能力を優先して、複雑な検索や集計を処理し、迅速に結果を返すことができます。インデックス作成も担当しますが、コンテンツデータは通常、ログやメトリクスなどの時系列データと同じ速度で取り込まれることはありません。レジリエンシーの観点から、このティアのインデックスは1つ以上のレプリカを使用するように構成する必要があります。

コンテンツティアは必須です。システムインデックスやデータストリームの一部でない他のインデックスは、自動的にコンテンツティアに割り当てられます。

専用のコンテンツノードを作成するには、次のように設定します：

Yaml

  1. node.roles: [ data_content ]

ホットデータノード

ホットデータノードはホットティアの一部です。ホットティアは、時系列データのElasticsearchのエントリーポイントであり、最も最近の、最も頻繁に検索される時系列データを保持します。ホットティアのノードは、読み取りと書き込みの両方で高速である必要があり、これにはより多くのハードウェアリソースと高速ストレージ（SSD）が必要です。レジリエンシーのために、ホットティアのインデックスは1つ以上のレプリカを使用するように構成する必要があります。

ホットティアは必須です。データストリームの一部である新しいインデックスは、自動的にホットティアに割り当てられます。

専用のホットノードを作成するには、次のように設定します：

Yaml

  1. node.roles: [ data_hot ]

ウォームデータノード

ウォームデータノードはウォームティアの一部です。時系列データは、ホットティアの最近インデックスされたデータよりも頻繁にクエリされなくなった場合、ウォームティアに移動できます。ウォームティアは通常、最近の数週間のデータを保持します。更新はまだ許可されていますが、頻度は低い可能性があります。ウォームティアのノードは、ホットティアのノードほど速くある必要はありません。レジリエンシーのために、ウォームティアのインデックスは1つ以上のレプリカを使用するように構成する必要があります。

専用のウォームノードを作成するには、次のように設定します：

Yaml

  1. node.roles: [ data_warm ]

コールドデータノード

コールドデータノードはコールドティアの一部です。時系列データを定期的に検索する必要がなくなった場合、ウォームティアからコールドティアに移動できます。このティアは、検索速度よりも低いストレージコストに最適化されていることが一般的です。

より良いストレージの節約のために、コールドティアに検索可能なスナップショットの完全にマウントされたインデックスを保持できます。通常のインデックスとは異なり、これらの完全にマウントされたインデックスは、信頼性のためにレプリカを必要としません。障害が発生した場合、基盤となるスナップショットからデータを回復できます。これにより、データに必要なローカルストレージが半分になる可能性があります。コールドティアで完全にマウントされたインデックスを使用するには、スナップショットリポジトリが必要です。完全にマウントされたインデックスは読み取り専用です。

代わりに、コールドティアを使用して、レプリカを持つ通常のインデックスを保存することもできます。これにより、古いデータをより安価なハードウェアに保存できますが、ウォームティアと比較して必要なディスクスペースは減少しません。

専用のコールドノードを作成するには、次のように設定します：

Yaml

  1. node.roles: [ data_cold ]

凍結データノード

凍結データノードは凍結ティアの一部です。データがもはやクエリされない、またはまれにクエリされる場合、それはコールドティアから凍結ティアに移動し、その後の生涯の間そこに留まります。

凍結ティアにはスナップショットリポジトリが必要です。凍結ティアは、スナップショットリポジトリからデータを保存および読み込むために部分的にマウントされたインデックスを使用します。これにより、ローカルストレージと運用コストが削減され、凍結データを検索できるようになります。Elasticsearchは時々凍結データをスナップショットリポジトリから取得する必要があるため、凍結ティアでの検索は通常、コールドティアよりも遅くなります。

専用の凍結ノードを作成するには、次のように設定します：

Yaml

  1. node.roles: [ data_frozen ]

インジェストノード

インジェストノードは、1つ以上のインジェストプロセッサで構成された前処理パイプラインを実行できます。インジェストプロセッサによって実行される操作の種類と必要なリソースに応じて、専用のインジェストノードを持つことが理にかなっている場合があります。これにより、特定のタスクのみを実行します。

専用のインジェストノードを作成するには、次のように設定します：

Yaml

  1. node.roles: [ ingest ]

コーディネーティング専用ノード

マスターの義務を処理する能力、データを保持する能力、ドキュメントを前処理する能力を取り除くと、リクエストをルーティングし、検索の集約フェーズを処理し、バルクインデックスを分配することしかできないコーディネーティングノードが残ります。基本的に、コーディネーティング専用ノードはスマートなロードバランサーとして機能します。

コーディネーティング専用ノードは、大規模なクラスターに利益をもたらし、データノードおよびマスター候補ノードからコーディネーティングノードの役割をオフロードします。彼らはクラスターに参加し、他のノードと同様に完全なクラスター状態を受け取り、クラスター状態を使用してリクエストを適切な場所に直接ルーティングします。

クラスターにコーディネーティング専用ノードを追加しすぎると、選出されたマスターノードがすべてのノードからクラスター状態の更新の確認を待たなければならないため、クラスター全体の負担が増加する可能性があります！コーディネーティング専用ノードの利点は過大評価されるべきではありません—データノードは同じ目的を果たすことができます。

専用のコーディネーティングノードを作成するには、次のように設定します：

Yaml

  1. node.roles: [ ]

リモート候補ノード

リモート候補ノードは、クロスクラスタークライアントとして機能し、リモートクラスターに接続します。接続すると、クロスクラスター検索を使用してリモートクラスターを検索できます。また、クロスクラスター複製を使用してクラスター間でデータを同期することもできます。

Yaml

  1. node.roles: [ remote_cluster_client ]

機械学習ノード

機械学習ノードはジョブを実行し、機械学習APIリクエストを処理します。詳細については、機械学習設定を参照してください。

専用の機械学習ノードを作成するには、次のように設定します：

Yaml

  1. node.roles: [ ml, remote_cluster_client]
  3. ## 変換ノード
  5. 変換ノードは変換を実行し、変換APIリクエストを処理します。詳細については、[変換設定](/read/elasticsearch-8-15/d33920b665efb89c.md)を参照してください。  
  7. 専用の変換ノードを作成するには、次のように設定します：
  10. #### Yaml
  12. ``````yaml
  13. node.roles: [ transform, remote_cluster_client ]
  14. `
  3. ## ノードの役割の変更
  5. 各データノードは、ディスク上に次のデータを保持します：  
  7. -  そのノードに割り当てられたすべてのシャードのシャードデータ、  
  8. -  そのノードに割り当てられたすべてのシャードに対応するインデックスメタデータ、および  
  9. -  設定やインデックステンプレートなどのクラスター全体のメタデータ。
  11. 同様に、各マスター候補ノードは、ディスク上に次のデータを保持します：  
  13. -  クラスター内のすべてのインデックスに対するインデックスメタデータ、および  
  14. -  設定やインデックステンプレートなどのクラスター全体のメタデータ。
  16. 各ノードは、起動時にデータパスの内容をチェックします。予期しないデータを発見した場合、起動を拒否します。これは、赤いクラスターの健康につながる可能性のある不要な[ダングリングインデックス](ca9b224f78ef5d28.md#dangling-indices)をインポートしないようにするためです。より正確には、`````data`````役割を持たないノードは、起動時にディスク上にシャードデータが見つかった場合、起動を拒否します。また、`````master`````および`````data`````役割の両方を持たないノードは、起動時にディスク上にインデックスメタデータがある場合、起動を拒否します。  
  18. ノードの役割を変更するには、`````elasticsearch.yml`````ファイルを調整し、再起動する必要があります。これを*再利用*ノードと呼びます。上記の予期しないデータに関するチェックを満たすために、`````data`````または`````master`````役割なしでノードを起動する際に、ノードを再利用するための準備をするためにいくつかの追加手順を実行する必要があります。  
  20. -  `````data`````役割を削除してデータノードを再利用したい場合は、まず[割り当てフィルター](4867631dc496d585.md#cluster-shard-allocation-filtering)を使用して、クラスター内の他のノードにすべてのシャードデータを安全に移行する必要があります。  
  21. -  `````data`````または`````master`````役割のいずれも持たないノードに再利用したい場合は、空のデータパスと希望する役割を持つ新しいノードを起動するのが最も簡単です。シャードデータをクラスター内の他の場所に移行するために[割り当てフィルター](4867631dc496d585.md#cluster-shard-allocation-filtering)を使用するのが最も安全であると考えられます。
  23. これらの追加手順に従うことができない場合は、ノードの起動を妨げる余分なデータを削除するために、[`````elasticsearch-node repurpose`````](080c1c3e774f76be.md#node-tool-repurpose)ツールを使用できる場合があります。
  26. ## ノードデータパス設定
  28. ## path.data
  30. すべてのデータおよびマスター候補ノードは、シャード、インデックス、およびクラスターのメタデータが保存されるデータディレクトリへのアクセスが必要です。`````path.data`````は`````$ES_HOME/data`````にデフォルト設定されていますが、`````elasticsearch.yml`````設定ファイルで絶対パスまたは`````$ES_HOME`````に対する相対パスとして構成できます。次のように：
  33. #### Yaml
  35. ``````yaml
  36. path.data:  /var/elasticsearch/data
  37. `

すべてのノード設定と同様に、コマンドラインで次のように指定することもできます： 

  1. ./bin/elasticsearch -Epath.data=/var/elasticsearch/data

path.dataディレクトリの内容は再起動を通じて持続する必要があります。これは、データが保存される場所です。Elasticsearchは、ファイルシステムがローカルディスクによってバックアップされているかのように動作することを要求しますが、これは、適切に構成されたリモートブロックデバイス（例：SAN）やリモートファイルシステム（例：NFS）でも正しく機能します。複数のElasticsearchノードを同じファイルシステム上で実行できますが、各Elasticsearchノードは独自のデータパスを持っている必要があります。

.zipまたは.tar.gzディストリビューションを使用する場合、path.data設定は、Elasticsearchホームディレクトリの外にデータディレクトリを配置するように構成する必要があります。これにより、ホームディレクトリを削除してもデータが削除されないようにできます！RPMおよびDebianディストリビューションは、すでにこれを行っています。

データディレクトリ内の何も変更したり、その内容に干渉する可能性のあるプロセスを実行したりしないでください。Elasticsearch以外の何かがデータディレクトリの内容を変更すると、Elasticsearchが失敗し、破損や他のデータの不整合を報告するか、正しく動作しているように見えてもデータの一部を静かに失う可能性があります。データディレクトリのファイルシステムバックアップを試みないでください。そのようなバックアップを復元するためのサポートされた方法はありません。代わりに、スナップショットと復元を使用して、安全にバックアップを取得してください。データディレクトリでウイルススキャナーを実行しないでください。ウイルススキャナーはElasticsearchが正しく動作するのを妨げ、データディレクトリの内容を変更する可能性があります。データディレクトリには実行可能ファイルが含まれていないため、ウイルススキャンは偽陽性しか見つけません。

その他のノード設定

Elasticsearchの設定および重要なElasticsearch設定には、次のようなその他のノード設定が含まれています：