OpenSearch Service ドメインが Modifying 状態から移行しない理由を知りたいです。

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

設定を変更すると、OpenSearch サービスクラスターは Modifying 状態になります。設定の変更には、新しいデータノードの追加、1 秒あたりの入出力操作数 (IOPS) のプロビジョニング、AWS Key Management Service (AWS KMS) キーの設定などが含まれます。

注: 設定変更を送信する前に、クラスターがブルー/グリーンデプロイをサポートしているかどうかを確認することをおすすめします。設定変更を送信する前に、ドライランを実行してください。

検証チェックに失敗し、エラーが発生した

設定変更を開始すると、OpenSearch Service は検証チェックを行い、ドメインにアップグレード資格があることを確認します。検証が失敗した場合、ドメインは Modifying 状態に留まります。この問題を解決するには、発生したエラーに応じてトラブルシューティング手順を実行してください。次に、設定の変更を再試行してください。

新しいリソースセットを起動できない

複数の設定変更を同時に送信した場合、クラスターが停止する可能性があります。構成変更を送信するときは、その変更が完了するまで待ってから、別の構成変更を送信してください。

検証ステージで完了した検証チェックは、その構成変更の期間中は有効です。設定が検証ステージに合格した場合は、ドメインに必要なリソースを変更しないでください。たとえば、暗号化に使用する AWS KMS キーを無効化しないよう注意してください。

新しいデータノードセットへのシャード移行が完了していない

OpenSearch Service によって新しいリソースが作成されると、古いデータノードセットから新しいセットへのシャード移行が開始されます。このステージは、クラスターの負荷とサイズに応じて、数分から数時間かかる場合があります。

古いノードと新しいノード間のシャードの現在の移行を監視するには、次の API 操作を使用します。

GET /DOMAIN_ENDPOINT/_cat/recovery?active_only=true

注: DOMAIN_ENDPOINT を実際のドメインエンドポイントに置き換えます。

OpenSearch Service クラスターが赤色のクラスター状態の場合、シャードの移行は失敗します。ヘルスステータスが赤くなっている場合の解決方法については、「Amazon OpenSearch Service クラスターのステータスが赤または黄色になっている原因を教えてください」を参照してください。

クラスターに過負荷がかかると、クラスターはシャードの移行を処理するためのリソースを割り当てることができなくなります。CPU と JVM の負荷が高いクラスターは過負荷になる可能性があります。この問題をトラブルシューティングするには、Amazon CloudWatch メトリクス JVMMemoryPressure および CPUUtilization を監視します。

新しいノードセットに空きストレージ容量が不足していると、シャードの移行が失敗する可能性があります。この問題は、ブルー/グリーンデプロイのプロセス中に、クラスターに新しいデータを追加すると発生する可能性があります。この問題は、古いノードのシャードが大容量であり、OpenSearch Service が新しいノードにシャードを割り当てられない場合にも発生します。

ストレージを解放するには、delete index API 操作を使用して不要になった古いインデックスを削除します。詳細については、Elastic のウェブサイトで「Delete index API」を参照してください。

シャードのサイズを確認するには、cat shards API 操作を使用します。次に、cat allocation API 操作を使用すると、各ノードに割り当てられたシャードの数が表示されます。新しいノードに必要なシャードがすべて揃っていない場合は、cluster allocation explain API 操作を使用して原因を特定します。詳細については、Elastic のウェブサイトで「cat shards API」、「cat allocation API」、「Cluster allocation explain API」を参照してください。

最大再試行回数を超えてもシャードがノードに割り当てられられない場合は、割り当てを再試行してください。

デフォルトでは、クラスターはシャードを連続して最大 5 回割り当てようとします。シャードの index.allocation.max_retries インデックス設定を増やすには、次の API 操作を使用します。

PUT INDEX_NAME/_settings  
{
    "index.allocation.max_retries" : 10
}

**注:**INDEX_NAME を実際のインデックス名に置き換えます。

内部ハードウェア障害により、古いデータノード上のシャードが移行中に行き詰まる可能性があります。ハードウェアの問題に応じて、OpenSearch Service は自己修復スクリプトを実行してノードを正常な状態に戻します。

シャードを古いノードセットに固定すると、行き詰まったシャードの再配置が発生する可能性があります。シャードがいずれのノードにも固定されていないことを確認するために、インデックス設定を参照してください。または、クラスターに ClusterBlockException エラーが発生していないかどうかを確認してください。

新しいノードに割り当てられないシャードと対応するインデックス設定を特定するには、次のコマンドを実行します。

GET /DOMAIN_ENDPOINT/_cluster/allocation/explain?pretty
GET /DOMAIN_ENDPOINT/INDEX_NAME/_settings?pretty

注: DOMAIN_ENDPOINT および INDEX_NAME を実際の値に置き換えます。

インデックス設定出力に次の設定が表示されているかどうかを確認します。

• "index.routing.allocation.require._name": "NODE_NAME"
• "index.blocks.write": true

"index.routing.allocation.require._name": "NODE_NAME" がインデックス設定に含まれている場合は、次のコマンドを実行して設定をリセットします。

PUT /DOMAIN_ENDPOINT/INDEX_NAME/_settings  
{
    "index.routing.allocation.require._name": null
}

注: DOMAIN_ENDPOINT および INDEX_NAME を実際の値に置き換えます。

詳細については、Elasticsearch のウェブサイトで「Index-level shard allocation filtering (インデックスレベルでのシャード割り当てフィルター)」を参照してください。

インデックス設定に "index.blocks.write": true がある場合、インデックスへの書き込みがブロックされています。書き込みがブロックされる問題は、ClusterBlockException エラーが原因で発生する可能性があります。詳細については、「OpenSearch Service での 403 "index_create_block_exception" または "cluster_block_exception" エラーを解決する方法を教えてください」を参照してください。

設定変更の進行状況を監視するには、DescribeDomainChangeProgress API 操作を実行します。

24 時間以上、クラスターが Modifying 状態から移行できなかったり、ドメインが古いリソースの削除中状態に留まったりする場合は、AWS サポートにお問い合わせください。