Classic Load Balancer の失敗したヘルスチェックのトラブルシューティングと解決方法を教えてください。

所要時間2分
0

Classic Load Balancer の背後にある 1 つまたは複数のインスタンスのヘルスチェックが失敗しました。考えられる原因は何であり、どうすれば解決できますか?

簡単な説明

Elastic Load Balancing (ELB) は、Application Load Balancer、Network Load Balancer、Classic Load Balancer をサポートしています。Classic Load Balancers で実行されているインスタンスは、以下の理由でヘルスチェックに失敗することがあります。

  • ロードバランサーとバックエンドの間の接続に関する問題
  • アプリケーションの設定に関する問題
  • ヘルスチェックリクエストについて、バックエンドから「200 OK」応答を受信していない
  • SSL に関する問題があり、HTTPS または SSL ヘルスチェックの失敗を引き起こしている

解決方法

ヘルスチェック関連の問題のトラブルシューティングと解決を行うには、以下を確認します。

ロードバランサーとバックエンドの間の潜在的な接続の問題を解決する

以下が正しいことを確認します。

  • バックエンドが、ヘルスチェックのトラフィックを許可している。 セキュリティグループのルールを確認するには、「Recommended rules for load balancer security groups」(ロードバランサーのセキュリティグループの推奨ルール) を参照してください。バックエンドのインスタンスについては、「Security groups for instances in a VPC」(VPC でのインスタンスのセキュリティグループ) を参照してください。
  • ロードバランサーまたはバックエンドのサブネットのネットワークアクセスコントロールリスト (ACL) が、ヘルスチェックのトラフィックを許可している。 ロードバランサーまたはバックエンドのサブネットの ACL ルールを確認するには、「Network ACLs for load balancers in a VPC」(VPC でのロードバランサーのネットワーク ACL) を参照してください。
  • バックエンドのインスタンスレベルまたは OS レベルのファイアウォールが、ヘルスチェックのトラフィックを許可している。 バックエンドのインスタンスレベルまたは OS レベルのファイアウォールが、ヘルスチェックの送信および受信のトラフィックを許可していることを確認します。
  • バックエンドインスタンスのリソースが、過度に使用されていない。 メモリと CPU の使用率が許容範囲内であることを確認します。メモリまたは CPU の使用率が高すぎる場合は、バックエンドを追加するか、バックエンドをより大きなインスタンスの種類にアップグレードします。
  • 追加のリソースが、ヘルスチェックのトラフィックを許可している。 ヘルスチェックリクエストは、バックエンドによって追加のリソースに転送される可能性があります。追加の依存関係が応答しなかったり応答に時間がかかりすぎると、ヘルスチェックはタイムアウトして失敗します。追加のリソースが、ヘルスチェックリクエストに応答していることを確認します。

アプリケーションの設定に関する潜在的な問題を解決する

  • アプリケーションが実行中である。 例えば、Linux インスタンスで Apache を実行している場合は、sudo service httpd status コマンドを使用して、Apache が実行中であることを確認します。
  • アプリケーションは、ヘルスチェックポートでリッスンしている。 サーバーがヘルスチェックポートでリッスン状態であることを確認するには、サーバーで netstat -ant コマンドを実行します。アプリケーション設定ポートをチェックして、実行中であることを確認します。ロードバランサーとバックエンドの間の TCP 接続をシミュレートするには、インスタンスで telnet <backend private IP> <health-check port> コマンドを実行します。出力が「Connected」であれば、バックエンドはヘルスチェックポートでリッスンしています。
  • アプリケーションが、カスタムホストヘッダーを持つリクエストに応答するように設定されている。 HTTP および HTTPS ヘルスチェックの場合、Classic Load Balancer はヘッダーをバックエンドのプライマリネットワークインターフェイスでのプライベート IP アドレスに設定し、ユーザーエージェントを「ELB-HealthChecker/1.0」に設定します。バックエンドがカスタムホストヘッダーまたはユーザーエージェントを持つリクエストにしか応答しない場合、ヘルスチェック要求は失敗します。
  • アプリケーションは、バックエンドのプライマリネットワークインターフェイスでリッスンしている。 Classic Load Balancer は、バックエンドインスタンスのプライマリネットワークインターフェイスに接続します。アプリケーションがバックエンドインスタンスのプライマリネットワークインターフェイスでリッスンしていて、バックエンドがヘルスチェックリクエストに対する応答を送信できることを確認します。

バックエンドからヘルスチェックリクエストへの「200 OK」レスポンスを確認する

以下が正しいことを確認します。

  • ping のパスが有効である。 ping のパスで指定されたファイルがバックエンドで設定されていない場合、バックエンドは「404 Not Found」(404 見つかりません) レスポンスコードで応答し、ヘルスチェックは失敗します。 注: ping のパスのデフォルト値は /index.html です。バックエンドに index.html ファイルがない場合は、ファイルを作成するか、または ping パスの値をバックエンドのファイル名に変更します。
  • バックエンドで、リダイレクトが設定されていない。 バックエンドで設定されたリダイレクションが 301 または 302 のレスポンスコードとなり、結果としてヘルスチェックが失敗します。例えば、バックエンドで HTTP:80 から HTTPS:443 へのリダイレクトがある場合、ヘルスチェックを HTTPS に変更し、ヘルスチェックポートを 443 に変更しない限り、ポート 80 の HTTP ヘルスチェックは失敗します。注: ロードバランサーに関連付けられたサブネット内のインスタンスからの curl -Ivk http[s]://<private-IP-address-of-the-backend-instance>:<health-check-port>/<health-check-target-page> コマンドを使用して、ロードバランサーによって送信されたヘルスチェックリクエストをシミュレートすることができます。

SSL 関連の問題を解決する

以下が正しいことを確認します。

  • すべてのプロトコルと暗号が一致している。 HTTPS または SSL ヘルスチェックの場合、ロードバランサーとバックエンドが同じプロトコルと暗号を使用している必要があります。バックエンドインスタンスで行われたパケットキャプチャは、ロードバランサーによって送信されたクライアント hello のロードバランサーでサポートされている暗号とプロトコルを示します。登録されているバックエンドインスタンスが、ロードバランサーによって送信された 1 つまたは複数の一致する暗号とプロトコルをサポートしている必要があります。
  • バックエンドサーバーで、Server Name Indication (SNI) が有効になっていない。 ヘルスチェックが HTTPS/SSL であり、SNI がバックエンドインスタンスで有効になっていると、ロードバランサーとバックエンドは SSL ハンドシェイクを確立できません。これは、クライアント hello の後にバックエンドサーバーが RST を送信するためです。SNI を無効にするか、代わりに TCP ヘルスチェックを使用します

関連情報

Registered instances for your Classic Load Balancer (Classic Load Balancer の登録済みインスタンス)

AWS公式
AWS公式更新しました 6年前
コメントはありません

関連するコンテンツ