基本3ノードクラスター設定のステップバイステップガイド
耐障害性のある基本的な3ノードElasticsearchクラスターを迅速にセットアップする方法を学びます。このステップバイステップのチュートリアルでは、`elasticsearch.yml`での必須設定、`cluster.initial_master_nodes`を使用したクラスターディスカバリーのブートストラップ、サービスの起動、および実用的なcURLコマンドを使用したノード間のヘルスとシャードレプリケーションの確認について説明します。
基本3ノードクラスター設定のステップバイステップガイド
3ノードのElasticsearchクラスターは、私がラボではなく実際のクラスターとして扱う最小の構成です。過半数でマスターを選出し、プライマリからレプリカを遠ざけ、データとロールが適切に設定されていれば、1つのノードがダウンしても耐えることができます。それでも魔法ではありません。3つの小さなVMでディスクが満杯でも、3つあるというだけで耐障害性のある検索プラットフォームのように動作するわけではありません。
このガイドでは、基本的な最新のElasticsearchレイアウトを使用します。3つのノードはすべてマスター候補かつデータ対応で、プライベートネットワークアドレス上にあります。これは小規模環境にとって合理的な出発点です。大規模な本番環境では、専用のマスターノード、データ層、インジェストノード、機械学習ノード、および調整専用ノードを分離することがよくあります。ここではシンプルに始め、ワークロードが正当化されたときにロールを分割します。
例はLinuxホストとパッケージまたはアーカイブインストールを前提としています。環境に合わせてサービスコマンドを調整してください。
設定を編集する前に
3つの別々のホストまたはVMが必要です。1台のラップトップに3つの「ノード」を置いて高可用性と呼んではいけません。ディスカバリーのテストには役立つかもしれませんが、同じ障害ドメインを共有します。
各ホストには以下が必要です：
- 同じElasticsearchバージョン。
- 安定したプライベートIPまたはDNS名。
- デフォルトでポート
9300でのノード間トランスポート接続。 - 必要に応じて、管理ホストまたはロードバランサーからのポート
9200でのHTTPアクセス。 - プライマリシャードとレプリカシャードに十分なディスク容量。
- NTPまたは類似のサービスによる時刻同期。
- 信頼性のあるローカルまたはアタッチされたストレージ上の設定済みデータパス。
最近のElasticsearchディストリビューションにはバンドルされたJDKが含まれています。パッケージングやバージョンで外部JDKが必要な場合は、推測するのではなく、そのElasticsearchリリースでサポートされているJavaバージョンを使用してください。
discovery.seed_hostsではプライベートアドレスを使用してください。非常に特殊な設計と強力なネットワーク制御がない限り、パブリックIPは避けてください。
このガイドでは、ノードは次のとおりです：
node-1 10.0.10.11
node-2 10.0.10.12
node-3 10.0.10.13
共通のクラスター設定を構成する
すべてのノードで、elasticsearch.ymlを編集します。ファイルの場所はインストール方法によって異なります。パッケージインストールでは通常/etc/elasticsearch/elasticsearch.yml、アーカイブインストールでは抽出されたディレクトリの下のconfig/elasticsearch.ymlを使用します。
3つのノードすべてに同じクラスター名を設定します：
cluster.name: my-three-node-cluster
3つのノードすべてにディスカバリーシードホストを設定します：
discovery.seed_hosts:
- 10.0.10.11:9300
- 10.0.10.12:9300
- 10.0.10.13:9300
最初のブートストラップのみに初期マスターノードを設定します：
cluster.initial_master_nodes:
- node-1
- node-2
- node-3
値はnode.nameと一致する必要があり、IPアドレスではありません（ノード名がIPのような文字列でない限り）。この設定は新しいクラスターを形成するためだけのものです。クラスターが正常に形成された後は、すべてのノードからcluster.initial_master_nodesを削除し、将来の再起動では保持しないでください。これを残しておくと、災害復旧や誤った再ブートストラップの試行中に混乱を引き起こす可能性があります。
プライベートインターフェースまたは安全なホスト値にバインドします：
network.host: 10.0.10.11
http.port: 9200
transport.port: 9300
各ノードの独自のIPをnetwork.hostに使用します。0.0.0.0は例では便利ですが、本番環境では意図しないインターフェースでElasticsearchを公開する可能性があります。お使いのバージョンでセキュリティ自動設定が有効になっている場合は、TLS証明書、登録、認証も考慮する必要があります。
各ノード名を構成する
ノード1の場合：
node.name: node-1
network.host: 10.0.10.11
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
ノード2の場合：
node.name: node-2
network.host: 10.0.10.12
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
ノード3の場合：
node.name: node-3
network.host: 10.0.10.13
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
テスト用に1台のマシンで複数のノードを実行する場合は、別々のpath.dataとpath.logsの値を使用してください。実際のクラスターでは、通常、ホストごとに1つのノードがよりクリーンなモデルです。
ノードロールを選択する
小規模な3ノードクラスターの場合、3つのノードすべてが標準ロールを持つことができます：
node.roles: [ master, data, ingest, remote_cluster_client ]
これにより、3つのマスター候補ノードが得られるため、マスター選出は過半数で機能します。3つのマスター候補ノードがある場合、クラスターは1つのノードを失ってもマスターを選出または維持できます。2つがなくなると、クラスター状態の決定を安全に行えません。
大規模なクラスターでは、データやインジェストの負荷がマスターの責務を枯渇させないため、専用のマスター候補ノードがより適していることがよくあります。これはスケーリングの改善であり、この基本設定の要件ではありません。
OSとネットワークの基本を確認する
Elasticsearchを起動する前に、ノードのペア間のトランスポート接続をテストします：
nc -vz 10.0.10.11 9300
nc -vz 10.0.10.12 9300
nc -vz 10.0.10.13 9300
可能であれば各ノードからこれらを実行します。ファイアウォールとクラウドセキュリティグループは、ノード間のトランスポートトラフィックを許可する必要があります。HTTPポート9200はクライアントと管理呼び出し用です。トランスポートポート9300はクラスターノードが相互に通信するために使用します。
また、データディレクトリとログディレクトリのファイル所有権を確認します。Elasticsearchプロセスは両方に書き込める必要があります。
ノードを起動する
systemdを使用したパッケージインストールの場合：
sudo systemctl daemon-reload
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch
sudo journalctl -u elasticsearch -f
テスト中のアーカイブインストールの場合：
bin/elasticsearch
3つのノードすべてを起動します。完全な順序で起動する必要はありませんが、ログを監視してください。クラスターが一度形成され、ノードが参加するのを確認したいです。ノードがマスターを発見できないと言う場合は、node.name、cluster.name、discovery.seed_hosts、トランスポート接続、およびTLS/セキュリティ設定に焦点を当ててください。
クラスターが形成されたら、すべてのノードの設定からcluster.initial_master_nodesを削除し、必要に応じて計画されたウィンドウで後で再起動します。初めてのブートストラップを試みている間は削除しないでください。
クラスターヘルスを確認する
ポート9200に到達できるホストから：
curl -s "http://10.0.10.11:9200/_cluster/health?pretty"
新しいクラスターでユーザーインデックスがない場合、シャードがゼロでグリーンと表示されることがあります。確認するフィールドはstatus、number_of_nodes、number_of_data_nodesです。
コンパクトなビューの場合：
curl -s "http://10.0.10.11:9200/_cat/health?v"
次にノードメンバーシップを確認します：
curl -s "http://10.0.10.11:9200/_cat/nodes?v&h=ip,name,roles,master,cpu,heap.percent,ram.percent,disk.used_percent"
3つのノードすべてが表示されるはずです。1つのノードに選出されたマスターのマークが付いています。3つすべてに期待するロールが表示されるはずです。
レプリカ付きのテストインデックスを作成する
シャード配置を確認するためのテストインデックスを作成します：
curl -X PUT "http://10.0.10.11:9200/test-data-index?pretty" -H 'Content-Type: application/json' -d '{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}'
シャードを確認します：
curl -s "http://10.0.10.11:9200/_cat/shards/test-data-index?v"
3つのプライマリシャードと1つのレプリカがある場合、ノード全体に6つのシャードコピーが分散されているはずです。Elasticsearchは、プライマリと同じノードにレプリカを配置することを避けます。
クラスターがイエローの場合、理由を尋ねます：
curl -X GET "http://10.0.10.11:9200/_cluster/allocation/explain?pretty" -H 'Content-Type: application/json' -d '{}'
一般的な原因は、十分なデータノードがない、ディスクウォーターマーク、アロケーションの無効化、またはノード属性と一致しないアロケーションアウェアネスルールです。
1ノード障害の動作をテストする
非本番テストで、1つのノードを停止します：
sudo systemctl stop elasticsearch
別のノードからヘルスを確認します：
curl -s "http://10.0.10.12:9200/_cluster/health?pretty"
3つのマスター候補ノードのうち2つが残っているため、クラスターにはまだマスターがいるはずです。タイミング、シャード再配置、レプリカ配置によって、Elasticsearchが反応する間、ヘルスはグリーンまたはイエローになる可能性があります。ノードを再度起動し、リカバリを監視します：
sudo systemctl start elasticsearch
curl -s "http://10.0.10.12:9200/_cat/recovery?v&active_only=true"
このテストは、クラスターが重要になる前に行う価値があります。正常なリカバリがどのようなものかを教えてくれるため、実際のインシデントが驚きにくくなります。
いくつかの本番ガードレール
Elasticsearchバージョンのセキュリティを有効にして理解してください。認証されていないHTTP APIをインターネットや広範な内部ネットワークに公開しないでください。
クラスターに依存する前にスナップショットを取得してください。レプリカはノード損失から保護します。スナップショットは削除、破損、運用ミスから保護します。
ディスク使用量、JVMヒープ圧力、ノード数、クラスターヘルス、保留中のタスク、スナップショットの成功を監視してください。3ノードクラスターは、リカバリに十分な容量がある場合にのみ耐障害性があります。
シャード数を控えめに保ってください。多数の小さなシャードはオーバーヘッドを生み出します。基本的なクラスターは、データ量が大きくなくても、数千の小さなインデックスで圧倒される可能性があります。
最後に、ブートストラップ設定を文書化し、形成後にcluster.initial_master_nodesを削除してください。ほとんどの3ノードセットアップの問題は、小さな不一致から発生します：ブートストラップ名と一致しないノード名、ブロックされたトランスポートポート、古いクラスターからの再利用されたデータディレクトリ、またはセキュリティデフォルトに関する仮定。よりエキゾチックな設定を変更する前に、これらを最初に確認してください。
現在のElasticsearchリリースのセキュリティノート
多くの最新のElasticsearchインストールでは、セットアップ中にセキュリティ機能が有効になります。つまり、HTTP呼び出しにはHTTPS、CA証明書、資格情報が必要になる場合があります。クラスターがTLSで自動設定されている場合、ヘルスチェックは次のようになります：
curl --cacert /etc/elasticsearch/certs/http_ca.crt \
-u elastic \
https://10.0.10.11:9200/_cluster/health?pretty
チュートリアルのコマンドを機能させるためにセキュリティを無効にしないでください。代わりに、証明書のパスとサービスアカウントに合わせて例を調整してください。本番環境では、日常業務に組み込みのスーパーユーザーを使用する代わりに、必要な権限を持つ名前付きユーザーまたはAPIキーを作成してください。
トランスポートTLSはノード参加にも影響を与える可能性があります。ノードが参加できず、ログに証明書の信頼、SANの不一致、ハンドシェイクの失敗、またはリモートトランスポートエラーが表示される場合は、ディスカバリー設定を変更する前に証明書を確認してください。完璧なdiscovery.seed_hostsリストは、TLSハンドシェイク中に互いを拒否するノードを助けません。
一般的な起動失敗
ノードがクラスターを形成しない場合、まず簡単なことを確認してください。
cluster.nameはすべてのノードで一致する必要があります。異なるクラスター名のノードは、シードホストリストに表示されているだけでは参加しません。
node.nameは、最初のブートストラップ中にcluster.initial_master_nodesで使用される値と一致する必要があります。設定がnode-1と言っているのにブートストラップがes-node-1をリストしている場合、ディスカバリーが停止する可能性があります。
トランスポートポートはノード間で到達可能である必要があります。ポート9200でのHTTPアクセスだけでは不十分です。必要に応じてnc、セキュリティグループの検査、またはパケットキャプチャを使用してください。
データディレクトリには、その正確なクラスターに再参加する意図がない限り、古いクラスターのメタデータが含まれていてはなりません。以前のテストからのディスクを再利用すると、クラスターUUIDや安全でないブートストラップに関する混乱するエラーが発生する可能性があります。
非ループバックアドレスにバインドする場合、メモリとブートストラップチェックが重要です。Elasticsearchは、ファイルディスクリプタ、仮想メモリ、メモリロック、ディスカバリー設定に関するチェックを実施する場合があります。盲目的に再試行するのではなく、起動ログを読んでください。
クラスターが動作した後
クラスターが重要なデータを運ぶ前に、スナップショットリポジトリを作成してください。レプリカはバックアップではありません。誤った削除、マッピングミス、アプリケーションのバグは、すべてのコピーに迅速に複製されます。
ノード名、IP、ロール、データパス、証明書の場所、ブートストラップ履歴をランブックに記録してください。障害時に、node-2がマスター候補であるべきかどうかをリバースエンジニアリングしたくはありません。
ノード損失、レッドヘルス、長期間のイエローヘルス、ディスクウォーターマーク、JVMヒープ圧力、スナップショット失敗、頻繁なマスター選出に対するアラートを設定してください。3ノードクラスターは1つの障害を乗り切る余地を与えますが、それは2つ目の障害の前に気づいて修復した場合のみです。
リカバリを考慮して容量を計画してください。各ノードが非常に高いディスク使用率で動作している場合、1つのノードを失うとレプリカを再構築するためのスペースが不足する可能性があります。健全なクラスターには、今日のプライマリに十分なスペースだけでなく、予備容量が必要です。
ローリング再起動の練習
パッケージアップグレードのために必要になる前に、ローリング再起動を練習してください。1つのノードを再起動し、再参加するのを待ち、ヘルスとリカバリを確認してから次のノードに移動します。意図的に全クラスターシャットダウンを行う場合を除き、3つのノードすべてを一度に再起動しないでください。
簡単なシーケンスは次のとおりです：
sudo systemctl restart elasticsearch
curl -s "http://10.0.10.11:9200/_cat/nodes?v"
curl -s "http://10.0.10.11:9200/_cluster/health?pretty"
クラスターに大きなシャードがある場合、計画された再起動の前に遅延アロケーションを調整する必要があるかどうかを検討してください。目標は、ノードが数分で戻ってくる場合に不必要なレプリカ再構築を避けることです。メンテナンス後、アロケーションが有効であり、一時的な設定が削除されていることを確認してください。
また、クライアントの動作をテストしてください。アプリケーションは、複数のElasticsearchエンドポイントまたは障害ノードを削除するロードバランサーを使用する必要があります。3ノードクラスターは、1つのノードがダウンしたときにクライアントが残りの健全なノードに到達できる場合にのみ役立ちます。
もう1つの習慣が役立ちます：各ノードの最終的なelasticsearch.ymlのコピーを構成管理に保持してください。セットアップ中に行われた手動編集はドリフトする傾向があり、ドリフトこそが次のノード交換を必要以上に困難にするものです。