Amazon OpenSearch Service クラスターのステータスが赤または黄色になっているのはなぜですか?

最終更新日: 2021 年 7 月 30 日

Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス) クラスターのステータスが赤または黄色になっています。この原因は何でしょうか?

簡単な説明

OpenSearch Service コンソールの [Monitoring] (モニタリング) タブには、クラスター内で最も正常でないインデックスのステータスが表示されます。クラスターステータスが赤の状態の場合、クラスターがダウンしているわけではありません。この状態は、少なくとも 1 つのプライマリシャードとそのレプリカがノードに割り当てられていないことを示しています。クラスターステータスが黄色の状態の場合、すべてのインデックスのプライマリシャードがクラスター内のノードに割り当てられます。ただし、少なくとも 1 つのインデックスのレプリカシャードが、いずれのノードにも割り当てられていません。

注: 最初に赤のクラスターステータスを解決するまで、ドメインを再設定しないでください。ドメインが赤のクラスターステータスのときに再設定を試みると、[Processing] (処理中) 状態でスタックする可能性があります。[Processing] (処理中) 状態でスタックしているクラスターについての詳細は、Why is my Amazon OpenSearch Service domain stuck in the "Processing" state? を参照してください。

クラスターは、次の理由によって赤のステータスになることがあります。

  • 複数のデータノードの障害
  • 破損したシャード、または赤のシャードをインデックスに使用している
  • JVM メモリプレッシャー、または CPU 使用率が高い
  • ディスク容量またはディスクスキューが少ない

注: 場合によっては、自動スナップショットからインデックスを削除してから復元することで、赤のクラスターステータスを解決できる場合があります。

クラスターは、次の理由で黄色のヘルスステータスになることがあります。

  • 新しいインデックスの作成
  • シャードまたはディスクスキューに割り当てるのに十分なノードがない
  • JVM メモリプレッシャーが高い
  • 単一ノードの障害
  • シャード割り当ての再試行回数の上限を超過した

注: 黄色のクラスターステータスが解決されない場合は、インデックス設定を更新するか、未割り当てのシャードを手動で再ルーティングすることによって、この状態を解決できます。黄色のクラスターステータスを自分で解決できない場合は、根本原因を特定してトラブルシューティングします。黄色のクラスターステータスを回避するには、クラスターの健全性のベストプラクティスを適用します。

解決方法

シャードが未割り当てになっている理由を特定する

未割り当てのシャードを特定するには、次の手順を実行します。

1.    未割り当てのシャードをリスト化します。

$ curl -XGET 'domain-endpoint/_cat/shards?h=index,shard,prirep,state,unassigned.reason' | grep UNASSIGNED

2.    シャードが未割り当てになっている理由の詳細を取得します。

$ curl -XGET 'domain-endpoint/_cluster/allocation/explain?pretty' -H 'Content-Type:application/json' -d'{"index": "<index name>", "shard": <shardId>, "primary":<true or false>}'

3.    (オプション) 赤のクラスターステータスの場合、懸念されるインデックスを削除し、根本原因を特定して対処します。

curl -XDELETE 'domain-endpoint/<index names>'

その後、利用可能なスナップショットを特定し、スナップショットからインデックスを復元します

curl -XGET 'domain-endpoint/_snapshot?pretty'

黄色のクラスターステータスの場合は、シャードが割り当てられるよう根本原因に対処します。

赤または黄色のクラスターステータスのトラブルシューティング

シャードに割り当てる十分なノードがない

レプリカシャードは、プライマリシャードと同じノードには割り当てられません。レプリカシャードを持つ単一ノードクラスターは、常に黄色のクラスターステータスで初期化されます。OpenSearch Service がレプリカの割り当てに利用できる他のノードがないため、単一ノードクラスターはこの方法で初期化されます。

また、OpenSearch Service バージョン 7.x 以降の cluster.max_shards_per_node の設定では、デフォルトの上限が「1,000」になっています。cluster.max_shards_per_node の設定をデフォルト値の「1000」で維持するのがベストプラクティスです。OpenSearch Service のシャード割り当てを制御するためにシャード割り当てフィルターを設定すると、フィルタリングされた十分なノードがないため、シャードが未割り当てとなる可能性があります。このようなノードの不足を防ぐために、ノード数を増やします。各プライマリシャードのレプリカ数が、データノード数よりも少ないことを確認してください。レプリカシャード数を減らすこともできます。詳細については、OpenSearch Service ドメインのサイジングおよび Demystifying OpenSearch Service shard allocation を参照してください。

ディスク容量またはディスクスキューが少ない

十分なディスク容量がない場合、クラスターは赤または黄色のヘルスステータスになります。OpenSearch Service がシャードを配布する前に、シャードを収容できる十分なディスク容量が必要です。

クラスター内の各ノードで使用できるストレージ容量を確認するには、次の構文を使用します。

$ curl domain-endpoint/_cat/allocation?v

ストレージ容量の問題についての詳細については、How do I troubleshoot low storage space in my Amazon OpenSearch Service domain? を参照してください。

ディスクスキューが大きいと、一部のデータノードでストレージ容量の問題が発生する可能性もあります。シャードを再割り当てする場合、シャードの分散中にシャードが未割り当てになることがあります。この問題を解決するには、Amazon OpenSearch Service クラスターで不均等なシャードの分散を再調整するにはどうすればよいですか? を参照してください。

ディスクベースのシャード割り当て設定によって、未割り当てのシャードが発生することもあります。例えば、cluster.routing.allocation.disk.watermark.low メトリクスが 50 GB に設定されている場合、指定された量のディスク領域がシャード割り当てに使用できることが必要です。

現在のディスクベースのシャード割り当て設定を確認するには、次の構文を使用します。

$ curl -XGET domain-endpoint/_cluster/settings?include_defaults=true&flat_settings=true

ディスク領域の問題を解決するには、次の方法を検討してください。

  • 不要なインデックスを削除する。
  • EBS ボリュームをスケールアップする。
  • データノードを追加する。

JVM メモリプレッシャーが高い

すべてのシャード割り当ては、CPU、ヒープ領域、ディスクとネットワークリソースを使用します。JVM メモリプレッシャーが継続的に高くなると、シャード割り当てに失敗する可能性があります。例えば、JVM メモリプレッシャーが 95% を超えると、メモリのメインサーキットブレーカーがトリガーされます。その後、割り当てスレッドがキャンセルされ、シャードは未割り当てのままになります。

この問題を解決するには、まず JVM メモリプレッシャーのレベルを下げます。JVM メモリプレッシャーが低下したら、クラスターを緑のヘルスステータスに戻すために、次に示す別のヒントについて検討してください。

  • デフォルトのシャード再試行数を「5」以上に増やす。
  • レプリカシャードを無効にしてから、再度有効にする。
  • 未割り当てのシャードを手動で再試行する。

JVM メモリ負荷の低減についての詳細については、How do I troubleshoot high JVM memory pressure on my Amazon OpenSearch Service cluster? を参照してください。

ノードの障害

クラスターでノードに障害が発生すると、ノードに割り当てられたシャードが未割当てになります。特定のインデックスに使用できるレプリカシャードがない場合、単一ノードで障害が発生した場合でも、ヘルスステータスが赤くなることがあります。2 つのレプリカシャードとマルチ AZ 配置を使用すると、ハードウェア障害によるデータ損失からクラスターを保護できます。

すべてのインデックスにレプリカシャードがある場合、1 つのノードで障害が発生すると、クラスターが一時的に黄色のヘルスステータスになる可能性があります。クラスターが一時的に黄色のヘルスステータスになった場合、ノードが再び正常になると、すぐに OpenSearch Service が自動的に回復します。または、シャードが新しいノードに割り当てられると、OpenSearch Service は回復します。

Amazon CloudWatch メトリクスをチェックすることで、ノードの障害を確認できます。ノードの障害を特定する方法の詳細については、障害が発生したクラスターノードを参照してください。

注: また、インデックスごとに 1 つのレプリカシャードを割り当てるか、専用のマスターノードを使用してゾーン認識を有効にすることもベストプラクティスです。詳細については、Elasticsearch ウェブサイトの Coping with failure を参照してください。

最大再試行回数の超過

OpenSearch Service では、クラスターでシャード割り当ての最大制限時間 (5,000 ミリ秒) および最大再試行回数 (5 回) を超えることはできません。クラスターが最大しきい値に達した場合、シャード割り当てを手動でトリガーする必要があります。シャード割り当てを手動でトリガーするには、インデックスのレプリカシャードを無効にしてから、再度有効にします。

クラスターの設定を変更すると、シャード割り当てもトリガーされます。ただし、クラスターが赤のヘルスステータスになっている場合は、クラスターの設定を変更しないでください。シャード割り当ての詳細については、Elasticsearch のウェブサイトの Every shard deserves a home を参照してください。

注: クラスターのワークロードが増大している場合は、シャード割り当てを手動でトリガーすることはベストプラクティスではありません。インデックスからすべてのレプリカを削除する場合、インデックスはプライマリシャードにのみに依存している必要があります。ノードで障害が発生すると、プライマリシャードが未割り当てのままになるため、クラスターは赤のヘルスステータスになります。

レプリカシャードを無効にするには、number_of_replicas の値を「0」に設定します。

$ curl -XPUT 'domain-endpoint/<indexname>/_settings' -H 'Content-Type: application/json' -d'
{
  "index" : {
    "number_of_replicas" : 0
  }
}'

また、index.auto_expand_replicas の設定が「false」に設定されていることを確認します。クラスターが緑のヘルスステータスに戻ったら、index.number_of_replicas の値を希望する値に再度設定し、レプリカシャードの割り当てをトリガーします。シャード割り当てが成功すると、クラスターは緑のヘルスステータスになります。

クラスターの健全性のベストプラクティス

黄色または赤のクラスターステータスを解決するには、次のベストプラクティスを検討してください。

  • AutomatedSnapshotFailure で、推奨される Amazon CloudWatch アラーム を設定します。アラームを使用すると、クラスターが赤のステータスになった時点からインデックスを復元できるスナップショットを確実に利用できます。
  • クラスターのワークロードが持続的に増大している場合は、クラスターをスケールします。クラスターのスケーリングの詳細については、How can I scale up an Amazon OpenSearch Service domain? を参照してください。
  • ディスク使用率、JVM メモリ負荷、CPU 使用率をモニタリングして、設定されたしきい値を超過していないことを確認します。詳細については、推奨 CloudWatch アラームおよびクラスターメトリクスを参照してください。
  • ノードの障害から保護するために、すべてのプライマリシャードにレプリカシャードがあることを確認してください。

OpenSearch Service のベストプラクティスの詳細については、Amazon OpenSearch Service のベストプラクティス を参照してください。


この記事はお役に立ちましたか?


請求に関するサポートまたは技術サポートが必要ですか?