翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon OpenSearch Service の専用マスターノード
Amazon OpenSearch Service は、専用のマスターノードを使用してクラスターの安定性を向上させます。専用マスターノードではクラスター管理タスクを実行しますが、データは保持せず、データのアップロードリクエストにも応答しません。このように、クラスター管理タスクをオフロードすると、ドメインの安定性が向上します。他のすべてのノードタイプと同様に、専用マスターノードごとに時間料金を支払います。
専用マスターノードで実行するクラスター管理タスクは次のとおりです。
-
クラスター内のすべてのノードを追跡します。
-
クラスター内のインデックスの数を追跡します。
-
各インデックスに属するシャード数を追跡します。
-
クラスター内のノードのルーティング情報を保持します。
-
クラスター内のインデックス作成やノードの作成/削除など、状態が変化したときにクラスターの状態を更新します。
-
クラスターの状態に施された変更を、クラスター内のすべてのノードにわたって複製します。
-
クラスター内のデータノードの可用性をモニタリングするハートビートシグナル (定期的なシグナル) を送信することで、すべてのクラスターノードの状態をモニタリングします。
次の図は、10 個のインスタンスを持つ OpenSearch Service ドメインを示しています。インスタンスのうち 7 つはデータノードで、3 つは専用マスターノードです。アクティブになっているのは、専用マスターノードの 1 つだけです。2 つの灰色の専用マスターノードは、アクティブな専用マスターノードに障害が発生した場合のバックアップとして待機します。すべてのデータアップロードリクエストは、7 つのデータノードにより保存され、すべてのクラスター管理タスクは、アクティブな専用マスターノードにオフロードされます。
専用マスターノードの数の選択
マルチ AZ をスタンバイで使用することをお勧めします。スタンバイでは、本番 OpenSearch サービスドメインごとに 3 つの専用マスターノードが追加されます。スタンバイなしのマルチ AZ 、またはシングル AZ でデプロイする場合でも、3 つの専用マスターノードを推奨します。偶数の専用マスターノードを選択しないでください。専用マスターノードの数を選択するときは、次の点を考慮してください。
-
1 つの専用マスターノードは、障害発生時にバックアップがないため、 OpenSearch Service によって明示的に禁止されています。1 つの専用マスターノードのみを持つドメインを作成しようとすると、検証例外が表示されます。
-
2 つの専用マスターノードがある場合、クラスターには、障害が発生した場合に新しいマスターノードを選択するために必要なノードのクォーラムがありません。
クォーラムは、専用マスターノードの数/2 + 1 (直近の整数まで切り捨て) です。ここでは 2/2 + 1 = 2 となります。専用マスターノード 1 つが失敗し、バックアップは 1 つのみであれば、クラスターにはクォーラムがなく、新しいマスターを選択できません。
-
推奨される専用マスターノード数は 3 つです。マスターノードが失敗したときに 2 つのバックアップノードが使用でき、必要なクォーラム (2) で新しいマスターを選択できます。
-
専用マスターノードを 4 つにすると 3 つより良くなるわけではなく、複数のアベイラビリティーゾーンを使用した場合、問題が発生する可能性があります。
-
マスターノード 1 つが失敗した場合、クォーラム (3) で新しいマスターを選択します。2 つのノードが失敗したした場合、そのクォーラムは失われ、専用マスターノードが 3 つの場合と同じ状況になります。
-
3 つのアベイラビリティーゾーン設定では、2 つAZsに 1 つの専用マスターノードがあり、1 つの AZ に 2 つがあります。その AZ に中断が発生した場合、残りの 2 つには新しいマスターを選択するために必要なクォーラム (3) AZsがありません。
-
-
5 つの専用マスターノードは 3 つと同様に機能し、クォーラムを維持しながら 2 つのノードを失うことができます。ただし、一度にアクティブになる専用マスターノードは 1 つしかないため、この設定では 4 つのアイドルノードに対して料金を支払うことになります。多くのお客様は、このレベルのフェイルオーバーは過剰だと考えています。
クラスターに一定数のマスター対象ノードがあり、Elasticsearch バージョン 7.x 以降では、投票設定が常に奇数になるように 1 OpenSearch つのノードを無視する場合。この場合、基本的に専用マスターノード 4 つは 3 つ (2 つは 1 つ) に相当します。
注記
新しいマスターノードを選択するために必要なクォーラムがクラスターにない場合は、クラスターへの書き込みおよび読み取りリクエストの両方が失敗します。この動作は OpenSearch デフォルトとは異なります。
専用マスターノードのインスタンスタイプの選択
OpenSearch サービスドメインとインスタンスのクォータ
次の表に、 OpenSearch サービスドメインに関連するクォータを示します。
名前 | デフォルト | 引き上げ可能 | 説明 |
---|---|---|---|
ドメインあたりの専用マスターインスタンス | サポートされている各リージョン: 3 または 5 | なし |
1 つの Amazon OpenSearch Service ドメイン内の専用マスターインスタンスの最大数。 |
リージョンあたりのドメイン | サポートされている各リージョン: 100 | 可能 |
各 AWS リージョンで作成できる Amazon OpenSearch Service ドメインの最大数。 |
ドメインあたりのインスタンス数 | サポートされている各リージョン: 80 | はい |
1 つの Amazon OpenSearch Service ドメイン内のインスタンスの最大数。ドメインあたり最大 1,002 インスタンスの増加をリクエストできます。 |
ドメインあたりのインスタンス (T2 インスタンスタイプ) | サポートされている各リージョン: 10 | はい |
1 つの Amazon OpenSearch Service ドメイン内の T2 インスタンスの最大数。 |
ドメインあたりのウォームインスタンス | サポートされている各リージョン: 150 | なし |
1 つの Amazon OpenSearch Service ドメイン内のウォームノードの最大数。ドメインあたり最大 750 インスタンスの増加をリクエストできます。 |
ドメインあたりのクロスクラスター接続の数 | 40 | なし | |
AZ あたりの専用コーディネーターインスタンス | サポートされている各リージョン: 200 | はい |
数値は 1~200 の間でなければなりません。コーディネーターノード数はデータノード数を超えることはできません。 |
ドメインあたりの合計ストレージ容量 | 25 PB | なし |
この最大値は、すべてのデータノードとウォームノードの合計です。例えば、ドメインに 45 インスタンスと 140 合計 2.88 PiB のストレージのインスタンス。新しい制限は、データノードで 10 PB、ウォームノードで 15 PB です。 |
リージョンごとのカスタムパッケージ | 25 | なし | |
ドメインあたりのカスタムパッケージ | 20 | なし |
専用マスターノードでは検索およびクエリリクエストを処理しませんが、そのサイズは、管理可能なインスタンスサイズや、インスタンス数、インデックス数、シャード数と大きな相関があります。本番稼働用クラスターでは、最低でも専用マスターノードに以下のインスタンスタイプをお勧めします。
これらの推奨事項は一般的なワークロードに基づいており、お客様の要件によって異なります。多数のシャードまたはフィールドのマッピングがあるクラスターは、大きなインスタンスタイプからメリットを得ることができます。専用マスターノードのメトリクスを監視し、より大きいインスタンスタイプを使用する必要があるかどうかを調べてください。
インスタンス数 |
マスターノードRAMサイズ | サポートされるシャードカウントの上限 |
推奨される最小専用マスターインスタンスタイプ |
---|---|---|---|
1~10 |
8 GiB | 10K |
|
11~30 |
16 GiB | 30K |
|
31~75 | 32 GiB | 40K |
|
76~125 | 64 GiB | 75K |
|
126~200 |
128 GiB | 75K |
|
-
特定の構成変更が専用マスターノードに与える影響の詳細については、「Amazon OpenSearch Service での設定変更」を参照してください。
-
インスタンス数の制限の詳細については、OpenSearch 「サービスドメインとインスタンスクォータ」を参照してください。
-
v 、メモリ、料金などCPU、特定のインスタンスタイプの詳細については、「Amazon OpenSearch Service の料金
」を参照してください。