Alibaba Cloud Elasticsearch クラスターを作成する際、ビジネス要件を満たすために、さまざまなノードタイプの仕様とストレージを設定する必要があります。Elasticsearch クラスターは、データノード、Kibana ノード、専用マスターノード、ウォームノード、フローズンノード、コーディネーティングノードで構成され、それぞれが異なる役割を担っています。
データノード
データノードはインデックスデータを保存し、インデックス作成、検索、集約を実行します。データノードには高い CPU、メモリ、I/O 要件があります。リソースが不足している場合は、クラスターに新しいデータノードを追加することを推奨します。
クラスターに専用マスターノードがある場合、データノードはデータノードとしてのみ機能します。
クラスターに専用マスターノードがない場合、データノードはデータノードと専用マスターノードの両方として機能します。
Alibaba Cloud Elasticsearch クラスターは、基本コントロールプレーン (v2) またはクラウドネイティブコントロールプレーン (v3) のいずれかのコントロールプレーンアーキテクチャを使用します。v2 アーキテクチャでは、専用マスターノードがないクラスターをスケールアップすると、クラスターの再起動がトリガーされます。クラスター全体の負荷が低く、インデックスにレプリカシャードがある場合、再起動中もクラスターの可用性を維持できます。ただし、書き込みやクエリの負荷が高いなどの特定のシナリオでは、再起動中にアクセスがタイムアウトする可能性があります。したがって、これらの操作はオフピーク時間帯に実行することを推奨します。
パラメーター | 説明 |
データノード仕様 | テスト環境では 2 vCPU および 4 GiB メモリのデータノードを使用し、本番環境ではより高い仕様のデータノードを使用することを推奨します。 |
データノードのディスクタイプ |
説明
|
ESSD パフォーマンスレベル | データノードのディスクタイプパラメーターを ESSD に設定した場合、このパラメーターを設定する必要があります。 |
データノードのディスク暗号化 |
|
データノードあたりのストレージ容量 | 各データノードのストレージ容量はディスクタイプによって異なります。単位：GiB。
説明 2,560 GiB を超えるストレージ容量を持つ Ultra ディスクのサイズを変更する場合、ディスクがディスクアレイまたは RAID 0 で実行されるように設計されているため、Ultra ディスクに対してはブルーグリーンアップデートのみが実行可能です。 |
データノード数 | 購入するノード数は、ゾーン数の倍数である必要があります。 重要 データノードが 2 つしかないクラスターは、スプリットブレインのリスクが高く、安定性が低くなります。V6.X や V5.X などの古いバージョンのクラスターにデータノードが 2 つしかない場合、ノードの再起動が必要になったときに専用マスターノードが選択されず、クラスターがサービスを提供できなくなる可能性があります。したがって、このパラメーターはビジネス要件に基づいて設定する必要があります。 |
Kibana ノード
Kibana ノードパラメーターの値は [はい] のみです。
1 vCPU および 2 GiB メモリの Kibana ノードは無料です。ただし、1 vCPU および 2 GiB メモリの Kibana ノードはテスト目的でのみ使用することを推奨します。
クラスターのパフォーマンスと安定性への影響のため、2 vCPU および 4 GiB メモリ以上の仕様の Kibana ノードを購入することを推奨します。
専用マスターノード
専用マスターノードを使用して、インデックスの作成、インデックスの削除、ノードの追跡、シャードの割り当てなどのクラスター操作を実行できます。専用マスターノードの安定性は、クラスターの健全性にとって重要です。デフォルトでは、クラスター内の各ノードが専用マスターノードとして使用される可能性があります。データのインデックス作成、検索、クエリなどの操作には、大量の CPU、メモリ、I/O リソースが必要です。クラスターの安定性を確保するために、専用マスターノードを購入して、専用マスターノードをデータノードから分離することを推奨します。
クラスター内の専用マスターノードが無料の場合、クラスターの構成をアップグレードした後にこれらのノードに課金されます。
専用マスターノードを含まず、古いアーキテクチャ (V2) でデプロイされたクラスターに対してブルーグリーン変更を実行すると、次にクラスターに変更を加えるときにデータノードが再起動されます。したがって、専用マスターノードを購入することを推奨します。
パラメーター | 説明 |
専用マスターノード |
説明
|
専用マスターノード仕様 | サポートされている仕様は購入ページで確認できます。 |
専用マスターノードのディスクタイプ |
サポートされているディスクタイプは購入ページで確認できます。 |
専用マスターノードのストレージ容量 | このパラメーターの値は 20 GB のみです。 |
専用マスターノード数 | このパラメーターの値は 3 のみです。 |
ウォームノード
ワークロードに以下の両方のタイプのデータが含まれる場合、高性能なホットノードと大容量のウォームノードを組み合わせた Hot-Warm アーキテクチャを使用することを推奨します：
ホットデータ：頻繁にクエリされ、書き込み負荷が高く、遅延の影響を受けやすいインデックス。
ウォームデータ：クエリ頻度が低く、ほとんどが読み取り専用または書き込みが最小限のインデックス。これらは通常、履歴データです。
ホットデータとウォームデータを異なるノードタイプにデプロイすることで、ウォームデータによるリソース競合がホットデータのパフォーマンスに影響を与えるのを防ぎ、ストレージコストを大幅に削減し、クラスター全体の効率と安定性を向上させることができます。
詳細については、「"Hot-Warm" Architecture in Elasticsearch 5.x」をご参照ください。
専用マスターノードが購入されている場合、ウォームノードはウォームノードとしてのみ使用されます。
専用マスターノードが購入されていない場合、ウォームノードは専用マスターノードとしても使用されます。
パラメーター | 説明 |
ウォームノード | 購入したウォームノードを無効にすることができます。ウォームノードを無効にする際にクラスターがスタックした場合は、「ウォームノードを無効化した後にクラスターがスタックした場合の対処法」をご参照ください。 |
ウォームノード仕様 | サポートされている仕様については、購入ページをご参照ください。 高い I/O と大容量ストレージを必要とするシナリオでは、
説明
|
ウォームノードのディスクタイプ | Ultra ディスクと ESSD がサポートされています。 |
ウォームノードのディスク暗号化 |
説明
|
ウォームノードのストレージ容量 | このパラメーターの最小値は 500 です。単位：GiB。 |
ウォームノード数 | 購入するノード数は、ゾーン数の倍数である必要があります。 |
ウォームノードを購入すると、システムは次の表に示すように、ノードの起動パラメーターに -Enode.attr.box_type パラメーターを追加します。
ノードタイプ | 起動パラメーター |
データノード | -Enode.attr.box_type=hot |
ウォームノード | -Enode.attr.box_type=warm |
フローズンノード
フローズンノードは、Searchable Snapshot 機能のコンピューティングレイヤーです。インデックスのメタデータを維持し、ローカルの共有キャッシュを管理し、クエリのために Object Storage Service (OSS) から必要なデータブロックをオンデマンドでプルします。履歴データを Alibaba Cloud OSS にスナップショットとして保存することで、フローズンノードは検索機能を維持しながらストレージコストを最大 90% 削減できます。
フローズンノードは V8.17.0 以降のバージョンのインスタンスでのみサポートされています。フローズンノードを有効にした後、無効にすることはできません。無効にするには、テクニカルサポートにお問い合わせください。
データは OSS に保存されるため、フローズンノードには大容量のローカルディスクは必要ありません。キャッシュヒット率を向上させるために、十分なメモリを設定することを推奨します。
詳細な例については、「Searchable Snapshot」をご参照ください。
パラメーター | 説明 |
フローズンノード | V8.17.0 の新しいインスタンスを購入する際、インスタンス仕様セクションのチェックボックスを選択してこの機能を有効にできます。 |
フローズンノード仕様 | 4 vCPU および 16 GiB メモリ以上のインスタンスタイプを推奨します。フローズンノードのメモリはインデックスのメタデータを維持し、共有キャッシュを管理します。十分なメモリはキャッシュヒット率を向上させることができます。サポートされている仕様については、購入ページをご参照ください。 |
フローズンノードのディスクタイプ | Ultra ディスクと ESSD がサポートされています。ローカルディスクは共有キャッシュとしてのみ機能し、データは OSS に永続化されます。 |
フローズンノードのストレージ容量 | 500 GiB 以上を推奨します。ローカルディスク容量は共有キャッシュとして機能します。キャッシュは、ノードの総ディスク容量の 90%、または総容量から 100 GiB を引いた値のいずれか小さい方を使用します。Least Recently Used (LRU) ポリシーにより、コールドデータブロックが削除されます。ディスク容量が大きいほど、キャッシュヒット率は高くなります。 |
フローズンノード数 | 購入するノード数は、アベイラビリティゾーン数の倍数である必要があります。 |
フローズンノードを購入すると、システムは次の表に示すように、ノードの起動パラメーターに -Enode.attr.box_type パラメーターを追加します。
ノードタイプ | 起動パラメーター |
データノード | -Enode.attr.box_type=hot |
ウォームノード | -Enode.attr.box_type=warm |
フローズンノード | -Enode.attr.box_type=frozen |
クライアントノード
クライアントノードを購入して、データノードの CPU オーバーヘッドを分担することができます。これにより、クラスターの処理性能とサービス安定性が向上します。多数の集約クエリを必要とするサービスなど、CPU 負荷の高いサービスには、クライアントノードを購入することを推奨します。
パラメーター | 説明 |
コーディネーティングノード | クラウドネイティブコントロールアーキテクチャでデプロイされたクラスター (V7.16 以降のクラスター) のために購入したクライアントノードをリリースすることはできません。ご利用のクラスターでクライアントノードをリリースできるかどうかは、購入ページで確認できます。 |
コーディネーティングノード仕様 | サポートされている仕様は購入ページで確認できます。 |
コーディネーティングノードのディスクタイプ | このパラメーターの値は Ultra ディスクのみです。 |
コーディネーティングノードのストレージ容量 | このパラメーターの値は 20 GB のみです。 |
コーディネーティングノード数 | 購入するノード数は、ゾーン数の倍数である必要があります。 |
参考文献
Elasticsearch クラスターの購入方法の詳細については、「Alibaba Cloud Elasticsearch クラスターの作成」をご参照ください。
ノードの詳細については、「Node | Elasticsearch Guide」をご参照ください。
ノード仕様の料金の詳細については、「料金」をご参照ください。
よくある質問
ウォームノードを無効化した後にクラスターがスタックする
1. クラスターで box_type に基づくノード割り当てルールが手動で設定されているかどうかを確認します (つまり、インデックスが warm とタグ付けされたノードに強制的に割り当てられているかどうか)
既存のすべてのインデックスに対して
index.routing.allocation.require.box_type設定をクエリします。GET */_settings/index.routing.allocation.require.box_type出力が
{"index.routing.allocation.require.box_type": "warm"}の場合、インデックスはbox_type=warmのノードに割り当てる必要があります。いずれかのインデックステンプレートに
box_type割り当てルールが設定されているかどうかを確認します。すべてのインデックステンプレートをクエリして、
box_type割り当てルールが設定されているかどうかを確認します。テンプレートが"index.routing.allocation.require.box_type": "warm"を返す場合、すべての新しいインデックスはデフォルトでウォームノードに割り当てられます。新しいインデックスが作成されると、テンプレートから設定を継承します。この値がテンプレートで設定されている場合、後続のすべてのインデックスは自動的にこのルールを適用します。
GET _ilm/policy?filter_path=*.policy.phases.warm.actions.allocate.require.box_typeすべての Index Lifecycle Management (ILM) ポリシーのウォームフェーズのノード割り当て設定をクエリします。
インデックスがウォームノードに割り当てられている場合、スケールダウン操作を実行してコールドデータノードをシャットダウンすると、クラスターの変更が 変更のスタック になります：
2. ソリューション
ポリシーから
box_type設定を削除する# まず、ILM を停止します。 POST _ilm/stop # 特定の ILM ポリシーを表示します。 GET _ilm/policy/your_policy_name # ILM ポリシーを更新し、ウォームフェーズから box_type 設定を削除します。 PUT _ilm/policy/your_policy_name { "policy": { "phases": { "warm": { "actions": { "allocate": { "require": { "box_type": null # この設定を削除します。 } } } }, "hot": { "actions": { "allocate": { "require": { "box_type": null # 存在する場合は、これも削除します。 } } } } } } } # allocate 配下の require フィールドが空の場合は、allocate アクション全体を削除します。 # または、レプリカ数など、他の必要な割り当てルールのみを保持します。インデックステンプレートから
box_type設定を削除する# 特定のテンプレート名を表示します。 GET _template/?filter_path=*.settings.index.routing.allocation.require.box_type # テンプレートを更新し、box_type 設定を削除します。 PUT _template/your_template_name { "settings": { "index.routing.allocation.require.box_type": null } } # または、box_type フィールドなしで完全なテンプレート定義を再送信します。インデックスから
box_type設定を削除する# 特定のインデックスの box_type 設定を削除します。 PUT /your_index_name/_settings { "index.routing.allocation.require.box_type": null } # バッチですべてのインデックスの設定を削除します。 { "index.routing.allocation.require.box_type": null }