すべてのプロダクト
Search
ドキュメントセンター

Server Load Balancer:NLBヘルスチェックの問題のトラブルシューティング方法

最終更新日:Sep 18, 2024

Network Load Balancer (NLB) は、ヘルスチェックを実行してバックエンドサーバーの可用性を確認します。 リスナーのヘルスチェックステータスが異常に変わった場合、バックエンドサーバーにエラーが発生するか、ヘルスチェックまたはバックエンドサーバーが正しく設定されていません。 このトピックでは、NLBのヘルスチェックの問題をトラブルシューティングする方法について説明します。

問題

NLBリスナーのヘルスチェックステータス異常になります。

原因

リスナーのヘルスチェックを初めて設定する場合は、ヘルスチェックが正しく設定されているかどうかを確認することを推奨します。 考えられる次の原因を確認してください。

  • 無効なヘルスチェックのパラメータ設定

  • ヘルスチェックポートが無効

ヘルスチェックが正しく設定された後でも問題が報告される場合は、バックエンドサーバーの問題を確認することを推奨します。 考えられる次の原因を確認してください。

  • 無効なセキュリティサービス設定

  • 無効なルート設定

  • バックエンドサーバーの負荷が大きい

解決策

最初のヘルスチェックプローブの送信後に発生するエラー

原因1: 無効なパラメータ設定

  1. NLBコンソールにログインします。

  2. 上部のナビゲーションバーで、NLBインスタンスがデプロイされています。

  3. 左側のナビゲーションウィンドウで、NLB > サーバーグループを選択します。

  4. [サーバーグループ] ページで、NLBインスタンスに関連付けられているサーバーグループを見つけ、[ヘルスチェック設定の変更] をクリックします。

  5. [ヘルスチェック設定の変更] ダイアログボックスで、パラメーター設定を確認します。 デフォルト設定を使用することを推奨します。

原因2: 無効なヘルスチェックポート

1. ヘルスチェックポートの確認

  1. NLBコンソールにログインします。

  2. 上部のナビゲーションバーで、NLBインスタンスがデプロイされています。

  3. 左側のナビゲーションウィンドウで、NLB > サーバーグループを選択します。

  4. [サーバーグループ] ページで、NLBインスタンスに関連付けられているサーバーグループのIDをクリックします。

  5. サーバーグループの詳細ページで、[バックエンドサーバー] タブをクリックし、バックエンドサーバーポートを記録します。

  6. サーバーグループの詳細ページで、[詳細] タブをクリックし、[ヘルスチェック] セクションの [ヘルスチェック設定の変更] をクリックします。 [ヘルスチェックの変更] ダイアログボックスで、ヘルスチェックの設定を記録します。

TCPリスナー

  1. 異常なバックエンドサーバーにログインし、次のコマンドを実行してヘルスチェックポートをプローブします。

    バックエンドサーバーにログインする方法の詳細については、「接続方法の概要」をご参照ください。

    telnet [$IP] [$Port]
    説明
    • [$IP] をバックエンドサーバーのプライベートIPアドレスに置き換えます。

    • [$Port] をバックエンドサーバーのヘルスチェックポートに置き換えます。 ヘルスチェックポートが指定されていない場合、バックエンドサーバーポートはデフォルトでヘルスチェックポートとして使用されます。 ヘルスチェックポートが指定されている場合は、指定されたヘルスチェックポートを入力します。

  2. コマンド出力を表示します。

    次の図に示すように、出力に "telnet: connect to address [$IP]: Connection refected" というメッセージが含まれている場合、接続要求は拒否されます。 この場合、バックエンドサーバーのヘルスチェックポートはエラー状態になります。image

    出力に "Connected to [$IP]" というメッセージが含まれている場合、次の図に示すように、バックエンドサーバーのヘルスチェックポートにアクセスできます。image

UDPリスナー

  1. 異常なバックエンドサーバーにログインし、次のコマンドを実行してヘルスチェックポートをプローブします。

    バックエンドサーバーにログインする方法の詳細については、「接続方法の概要」をご参照ください。

    netstat -anu | grep [$IP]:[$Port]
    説明
    • [$IP] をバックエンドサーバーのプライベートIPアドレスに置き換えます。

    • [$Port] をバックエンドサーバーのヘルスチェックポートに置き換えます。 ヘルスチェックポートが指定されていない場合、バックエンドサーバーポートはデフォルトでヘルスチェックポートとして使用されます。 ヘルスチェックポートが指定されている場合は、指定されたヘルスチェックポートを入力します。

  2. コマンド出力を表示します。

    出力に [$IP]:[$Port] エントリが含まれていない場合、次の図に示すように、バックエンドサーバーのヘルスチェックポートはエラー状態になります。

    image

    出力に [$IP]:[$Port] エントリが含まれている場合、次の図に示すように、バックエンドサーバーのヘルスチェックポートにアクセスできます。image

2. バックエンドサーバーのヘルスチェックポートが開いているか、ヘルスチェック設定で指定されたポートと同じかを確認します。 この例では、NGINXアプリケーションが使用されます。

  1. 異常なバックエンドサーバーにログインし、次のコマンドを実行してNGINXアプリケーションのステータスを照会します。

    systemctl status nginx
  2. 次の出力は、NGINXアプリケーションが無効になっていることを示します。

    image

  3. 次のコマンドを実行してNGINXアプリケーションを有効にします。

    systemctl start nginx
  4. 次のコマンドを実行して、NGINXアプリケーションのステータスを照会します。

    systemctl status nginx

    次の出力は、NGINXアプリケーションが有効になっていることを示します。image

  5. NLBコンソールにログインし、次の操作を実行します。

    1. [ヘルスチェック設定の変更] ダイアログボックスで、ヘルスチェックポートを表示します。image

    2. リスナーのヘルスチェックのステータスを表示します。 リスナーが異常な場合は、次のコマンドを実行してNGINXアプリケーションのヘルスチェックポートを照会します。

      netstat -tanp |grep nginx
  6. 次の出力は、NGINXアプリケーションのヘルスチェックポートがヘルスチェック設定で指定されたヘルスチェックポートと異なることを示しています。

    image

    /etc/nginx/nginx.confファイルを変更し、リスニング値をヘルスチェック設定で指定されたポートに変更し、変更内容を保存してから、ファイルを閉じます。

    説明

    業務上の制限によりlisten値を変更できない場合は、使用シナリオに応じてヘルスチェック設定のヘルスチェックポートを変更してください。 詳細については、「Overview of NLB listeners」をご参照ください。

    image

  7. 次のコマンドを実行して、NGINXアプリケーションを再起動します。 ヘルスチェックのステータスがHealthyに変わるまで待ちます。

    systemctl restart nginx

その後のヘルスチェックプローブ中に発生するエラー

原因1: セキュリティサービスの設定が無効です

NLBは、仮想プライベートクラウド (VPC) のCIDRブロックを使用してバックエンドサーバーと通信します。 VPC CIDRブロックが、iptablesやサードパーティのセキュリティサービスなどのアクセス制御ポリシーによってブロックされていないことを確認します。 VPC CIDRブロックがブロックされると、ヘルスチェックステータスが異常に変わり、NLBサービスエラーが発生します。 次の例では、VPC CIDRブロックはiptablesによってブロックされています。

  1. NLBコンソールにログインし、バックエンドサーバーとの通信にNLBインスタンスが使用するIPアドレスを表示します。

    image

  2. 異常なバックエンドサーバーにログインし、次のコマンドを実行して、フィルターテーブル内のすべてのルールを照会します。

    iptables -nL

    次の出力は、NLBインスタンスが使用するIPアドレスから送信されたリクエストがバックエンドサーバーによってブロックされていることを示しています。

    image

  3. 次のコマンドを実行して、IPアドレスからのリクエストをブロックするルールを削除します。

    iptables -t filter -D INPUT -s 192.168.20.75 -j DROP  # The IP address is for reference only.
    説明

    コマンドのIPアドレスを、NLBインスタンスで使用されている実際のプライベートIPアドレスに置き換えます。

  4. 次のコマンドを実行して、IPアドレスからのリクエストをブロックする他のルールが存在するかどうかを照会します。 IPアドレスがルールによってブロックされていないことを確認してください。

    iptables -nL

  5. リスナーのヘルスチェックステータスHealthyに変わったことを確認します。

原因2: 無効なルート設定

NLBインスタンスが使用するVPC CIDRブロックがバックエンドサーバーのルートテーブルに追加された場合、NLBインスタンスはヘルスチェックプローブパケットを受信できません。 その結果、ヘルスチェックのステータスが異常に変わります。 次の例では、Linux routeコマンドを使用してルート設定を照会します。

  1. NLBコンソールにログインし、バックエンドサーバーとの通信にNLBインスタンスが使用するIPアドレスを表示します。

    image

  2. 異常なバックエンドサーバーにログインし、次のコマンドを実行してルート設定を照会します。

    route -n

    NLBインスタンスで使用されるIPアドレスを宛先とし、gemaskが255.255.255.255で、ゲートウェイがネットワークインターフェイスコントローラー (NIC) のデフォルトゲートウェイでないルートエントリの場合、ルートエントリは正しく設定されていません。 ルートエントリの宛先が0.0.0.0の場合、Gatewayの値はデフォルトゲートウェイです。

    image

  3. 次のコマンドを実行して、誤ったルートエントリを削除します。

    ip route del blackhole 192.168.20.75 # The IP address is for reference only.
    説明

    コマンドのIPアドレスを、NLBインスタンスで使用されている実際のプライベートIPアドレスに置き換えます。

  4. リスナーのヘルスチェックステータスHealthyに変わったことを確認します。

原因3: バックエンドサーバーの負荷が大きい

バックエンドサーバーが過負荷になっているかどうかを確認します。 詳細については、「Linuxインスタンスの高負荷の問題のトラブルシューティングと解決」をご参照ください。

関連ドキュメント

NLBのインスタンス診断機能を使用して、ヘルスチェックの問題をトラブルシューティングできます。 詳細については、「NLBインスタンスの診断」をご参照ください。