Oracle Cloud Infrastructureドキュメント

ロード・バランサ・バックエンド・サーバーの問題のトラブルシューティング

ロード・バランサに関連するバックエンド・サーバーの問題について学習します。

バックエンド・サーバーのタイムアウトのデバッグ

バックエンド・サーバーがリクエストへの応答時にレスポンス時間を超えると、バックエンド・サーバーが停止しているか、ロード・バランサによって転送されたリクエストに応答していないことを示す504エラーが発生します。クライアント・アプリケーションは、次のレスポンス・コードを受け取ります: HTTP/1.1 504 Gateway Timeout。

エラーは、次の理由で発生する可能性があります:

  • ロード・バランサは、接続タイムアウトが期限切れになる前にバックエンド・サーバーへの接続を確立できませんでした。
  • ロード・バランサは、バックエンド・サーバーへの接続を確立しましたが、バックエンドがアイドル・タイムアウト期間を経過する前に応答できませんでした。
  • サブネットまたはVNICのセキュリティ・リストまたはネットワーク・セキュリティ・グループによって、バックエンドからロード・バランサへのトラフィックが許可されていませんでした。
  • バックエンド・サーバーまたはアプリケーション・サーバーに障害が発生しました。

バックエンド・サーバーのタイムアウト・エラーをトラブルシューティングするには、次のステップに従います:

  1. curlユーティリティを使用して、同じネットワーク内のホストからバックエンド・サーバーを直接テストします。
    curl -i http://backend_ip_address
    このテストの応答に1秒以上かかる場合、アプリケーションレベルの問題によってレイテンシが発生しています。次のようなレイテンシの原因となる可能性のあるアップストリーム依存関係を確認することをお勧めします。
    • iSCSIやNFSなどのネットワーク接続ストレージ
    • データベース・レイテンシ
    • オフプレミスAPI
    • アプリケーション層
  2. アプリケーションにバックエンド・サーバーから直接アクセスして確認します。アクセス・ログを確認して、アプリケーションにアクセスできるかどうか、およびアプリケーションが適切に機能しているかどうかを判断します。
  3. ロード・バランサとバックエンド・サーバーが異なるサブネットにある場合は、トラフィックを許可するルールがセキュリティ・リストに含まれているかどうかを確認します。ルールが存在しない場合、トラフィックは許可されていません。
  4. 次のコマンドを入力して、トラフィックをブロックするバックエンド・サーバーにファイアウォール・ルールが存在するかどうかを確認します:

    iptables -Lは、iptablesによって適用されるすべてのファイアウォール・ルールをリストします

    sudo firewall-cmd --list-allは、firewalldによって適用されるすべてのファイアウォール・ルールをリストします

  5. ロード・バランサのロギングを有効にして、ロード・バランサまたはバックエンド・サーバーがレイテンシの原因になっているかどうかを判断します。

TCPおよびHTTPバックエンド・サーバーのテスト

このトピックでは、ロード・バランサ接続のトラブルシューティング方法について説明します。この手順に使用されるトポロジでは、パブリック・サブネットにパブリック・ロード・バランサがあり、エンド・サーバーは同じサブネット内にあります。

問題のトラブルシューティングには、Oracle Cloud Infrastructure Loggingサービスを使用することをお薦めします。(ロード・バランサ・ログの詳細を参照してください。)

ただし、Oracle Cloud Infrastructure Loggingの使用に加え、この項にリストされている他のユーティリティを使用して、ロード・バランサで処理されバックエンド・サーバーに送信されたトラフィックをトラブルシューティングできます。これらのテストを実行するには、ロード・バランサと同じネットワークにインスタンスを作成し、同じネットワーク・セキュリティ・グループおよびセキュリティ・リスト内のトラフィックを許可することをお薦めします。次のツールを使用してトラブルシューティングを行います:

  • ping
    ここに示すより高度なユーティリティを使用する前に、基本的なpingテストを実行することをお薦めします。このテストを成功させるには、テスト・インスタンスとバックエンド・サーバー間のICNPトラフィックを許可する必要があります。
    $ ping backend_ip_address
    レスポンスは次のようになります:
    PING 192.0.2.2 (192.0.2.2) 56(84) bytes of data.
64 bytes from 192.0.2.2: icmp_seq=1 ttl=64 time=0.028 ms
64 bytes from 192.0.2.2: icmp_seq=2 ttl=64 time=0.044 ms

    "64 bytes from..."を含むメッセージが表示された場合は、pingに成功しました。

    「Destination Host Unreachable」を含むメッセージが表示されたら、システムが存在しないことを示します。

    メッセージが表示されない場合、システムは存在するがICMPプロトコルが許可されないことを示します。すべてのファイアウォール、セキュリティ・リストおよびネットワーク・セキュリティ・グループをチェックして、ICMPが許可されていることを確認します。

  • カール

    curlユーティリティを使用して、HTTPリクエストを特定のホスト、ポートまたはURLに送信します。

    • 次の例は、curlを使用して、403 Forbiddenエラーを送信するバックエンド・サーバーに接続する方法を示したものです:

      $ curl -I http://backend_ip_address/health
HTTP/1.1 403 Forbidden
Date: Tue, 17 Mar 2021 17:47:10 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 3539
Connection: keep-alive
Last-Modified: Tue, 10 Mar 2021 20:33:28 GMT
ETag: "dd3-5b3c6975e7600"
Accept-Ranges: bytes

      前述の例では、ヘルス・チェックが失敗し、403エラーが返されます。これは、バックエンド・サーバーにヘルス・チェック・ページのローカル・ファイル権限が正しく構成されないことを示しています。

    • 次の例は、curlを使用して、404 Not Foundエラーを送信するバックエンド・サーバーに接続する方法を示したものです:
      $ curl -I http://backend_ip_address/health
HTTP/1.1 404 Not Found
Date: Tue, 17 Mar 2021 17:47:10 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 3539
Connection: keep-alive
Last-Modified: Tue, 10 Mar 2021 20:33:28 GMT
ETag: "dd3-5b3c6975e7600"
Accept-Ranges: bytes

      前述の例では、ヘルス・チェックが失敗し、404エラーが返されます。これは、ヘルス・チェック・ページが予期した場所に存在しないことを示しています。

    • 次の例は、存在するバックエンド・サーバーを示しており、ネットワーク・セキュリティ・グループ、セキュリティ・リストまたはローカル・ファイアウォールがトラフィックをブロックしています:
      $ curl -I backend_ip_address
curl: (7) Failed connect to backend_ip_address:port; Connection refused
    • 次の例は、存在しないバックエンド・サーバーを示しています。
      $ curl -I backend_ip_address
curl: (7) Failed connect to backend_ip_address:port; No route to host
  • Netcat

    Netcatは、TCPまたはUDPを使用してネットワーク接続の読取りと書込みを行うためのネットワーキング・ユーティリティです。

    • 次の例は、TCPレベルでnetcatユーティリティを使用して、宛先バックエンド・サーバーが接続を受信できるようにする方法を示しています:
      $ nc -vz backend_ip_address port
Ncat: Connected to backend_ip_address:port.

      前述の例では、接続に対してportがオープンしています。

    • $ nc -vn backend_ip_address port
Ncat: Connection timed out.

      前述の例では、portがクローズしています。

  • Tcpdump

    tcpdumpユーティリティを使用して、バックエンド・サーバーへのすべてのトラフィックを取得し、どのトラフィックがロード・バランサからのものか、ロード・バランサに返されるものかを確認します。

    sudo tcpdump -i any -A port port src load_balancer_ip_address
11:25:54.799014 IP 192.0.2.224.39224 > 192.0.2.224.80: Flags [P.], seq 1458768667:1458770008, ack 2440130792, win 704, options [nop,nop,TS val 461552632 ecr 208900561], length 1341: HTTP: POST /health HTTP/1.1
  • OpenSSL

    ロード・バランサ・インスタンスとバックエンド・サーバー間のSSLの問題をトラブルシューティングする場合は、opensslユーティリティを使用することをお薦めします。このユーティリティは、特定のホスト名およびポートへのSSL接続を開き、SSL証明書やその他のパラメータを出力します。

    トラブルシューティングに関するその他のオプションは:

    • -showcerts

      このオプションは、バックエンド・サーバーによって提供された証明書チェーン内のすべての証明書を出力します。中間認証局証明書がないなどの問題を識別するには、このオプションを使用します。

    • -cipher cipher_name

      このオプションは、クライアントとサーバーが特定の暗号スイートを使用するように強制し、バックエンド・サーバーが特定の暗号を許可しているかどうかをルールから除外するのに役立ちます。

  • Netstat

    netstat -natpコマンドを使用して、バックエンド・サーバーで実行されているアプリケーションが稼働中であることを確認します。TCPまたはHTTPトラフィックの場合、バックエンド・アプリケーション、IPアドレスおよびポートはすべてリスニング・モードである必要があります。バックエンド・サーバーのアプリケーション・ポートをリスニング・モードにしないと、アプリケーションのTCPポートは稼働しません。

    この問題を解決するには、アプリケーションまたはバックエンド・サーバーを再起動して、アプリケーションが稼働していることを確認してください。