このトピックでは、Classic Load Balancer (CLB) のヘルスチェックに関するよくある質問に対する回答を提供します。
健康診断はどのように機能しますか?
CLBインスタンスはクラスターにデプロイされます。 レイヤー4またはレイヤー7クラスターのノードは、ネットワークトラフィックの転送とヘルスチェックの実行を担当します。
レイヤー4クラスターのノードは互いに独立しており、転送ルールに基づいてネットワークトラフィックを転送し、ヘルスチェックを実行します。 バックエンドサーバーがレイヤ4クラスター内のノードによって実行されたヘルスチェックに失敗した場合、バックエンドサーバーは異常と宣言されます。 バックエンドサーバー宛てのリクエストは、他のバックエンドサーバーに配信されます。 レイヤー4クラスター内のすべてのノードが、異常なバックエンドサーバーへのリクエストの配信を停止します。
次の図に示すように、CLBヘルスチェックではCIDRブロック100.64.0.0/10が使用されます。 iptablesなどのセキュリティルールが設定されていない限り、CIDRブロック100.64.0.0/10からのアクセスを許可するようにセキュリティグループルールを設定する必要はありません。 CIDRブロックはAlibaba Cloudによって予約されているため、100.64.0.0/10を許可しても潜在的なリスクは増加しません。 CIDRブロック内のIPアドレスはユーザーに割り当てられません。
詳細については、「ヘルスチェック概要」をご参照ください。
ヘルスチェックに推奨される設定は何ですか?
バックエンドサーバー間で頻繁に切り替わるネットワークトラフィックは、サービスの可用性を損なう可能性があります。 この問題を防ぐために、指定された期間中にバックエンドサーバーが連続してヘルスチェックに合格または失敗した後にのみ、ネットワークトラフィックがバックエンドサーバー間で切り替えられます。 詳細については、「ヘルスチェックの設定」をご参照ください。
次の表に、TCP、HTTP、およびHTTPSリスナーに推奨されるヘルスチェック設定を示します。
パラメーター | 推奨値 |
ヘルスチェック応答タイムアウト | 5秒 |
ヘルスチェック間隔 | 2秒 |
正常なしきい値 | 3回 |
異常しきい値 | 3回 |
次の表に、UDPリスナーの推奨ヘルスチェック設定を示します。
パラメーター | 推奨値 |
ヘルスチェック応答タイムアウト | 10 秒 |
ヘルスチェック間隔 | 5秒 |
正常なしきい値 | 3回 |
異常しきい値 | 3回 |
これらの設定を使用して、バックエンドサーバーがヘルスチェックに失敗した直後にサービスが復旧するようにすることを推奨します。 必要に応じて、より短い応答タイムアウト期間を指定できます。 ただし、指定されたタイムアウト期間がバックエンドサーバーの通常の応答時間よりも長いことを確認する必要があります。
ヘルスチェック機能を無効にできますか?
はい、ヘルスチェック機能を無効にできます。 詳細については、「ヘルスチェックの設定」をご参照ください。
ヘルスチェック機能を無効にすると、異常なECSインスタンスにリクエストが配信される可能性があります。 これにより、サービスが中断する可能性があります。 したがって、ヘルスチェック機能を有効にすることを推奨します。
ビジネスがトラフィック変動に非常に敏感な場合、頻繁なヘルスチェックがビジネスの可用性に影響を与える可能性があります。 ヘルスチェックのビジネスへの影響を減らすには、ヘルスチェックの頻度を減らすか、ヘルスチェックの間隔を増やすか、レイヤー7ヘルスチェックをレイヤー4ヘルスチェックに変更します。 ビジネスの継続性を確保するために、ヘルスチェック機能を有効にすることを推奨します。
TCPリスナーはどのようにヘルスチェックを実行しますか?
TCPリスナーは、HTTPおよびTCPヘルスチェックをサポートしています。
TCPヘルスチェック: リスナーはSYNパケットを送信してバックエンドポートの可用性をチェックします。
HTTPヘルスチェック: リスナーはHEADまたはGETリクエストを送信してバックエンドサーバーの可用性をチェックします。これは、ブラウザーがサーバーにアクセスする方法と同様です。
TCPヘルスチェックは、より少ないサーバーリソースを消費します。 バックエンドサーバーのワークロードが重い場合は、TCPヘルスチェックを設定できます。 それ以外の場合は、HTTPヘルスチェックを設定できます。
ECSインスタンスの重みをゼロに設定するとどうなりますか?
ECSインスタンスの重みをゼロに設定すると、CLBはネットワークトラフィックをECSインスタンスに転送しなくなります。 ただし、ヘルスチェックの結果には影響しません。
ECSインスタンスの重みをゼロに設定すると、ECSインスタンスはワークロードに対応しなくなります。 ECSインスタンスの設定を再起動または変更するときに、ECSインスタンスの重みをゼロに設定できます。
HTTPリスナーは、バックエンドECSインスタンスのヘルスチェックを実行するためにどのような方法を使用しますか。
HTTPリスナーは、HEADリクエストを送信してヘルスチェックを実行します。
HEADリクエストをサポートしていないECSインスタンスは、ヘルスチェックに失敗します。 ECSインスタンスで次のコマンドを実行してIPアドレスにアクセスし、ECSインスタンスがHEADリクエストをサポートしているかどうかを確認することを推奨します。
curl -v -0 -I -H "ホスト:" -X HEAD http:// IP:portHTTPリスナーがECSインスタンスのヘルスチェックを実行するために使用するIPアドレスは何ですか。
CLBはヘルスチェックに100.64.0.0/10を使用します。 このCIDRブロックから送信されたリクエストがECSインスタンスによって許可されていることを確認してください。 iptablesなどのセキュリティルールが設定されていない限り、CIDRブロック100.64.0.0/10からのアクセスを許可するようにセキュリティグループルールを設定する必要はありません。 このCIDRブロックはAlibaba Cloudによって予約されているため、100.64.0.0/10を許可しても潜在的なリスクは増加しません。 CIDRブロック内のIPアドレスはユーザーに割り当てられません。
webログに記録されたヘルスチェック率が、コンソールのヘルスチェック設定と異なるのはなぜですか。
ヘルスチェックは、単一障害点を防ぐためにサーバーのグループによって実行されます。 CLBは複数のサーバーにデプロイされています。 したがって、ログに記録されるヘルスチェック率は、コンソールの設定とは異なります。
障害のあるバックエンドデータベースが原因で発生したヘルスチェックの失敗を処理する方法を教えてください。
問題
静的Webサイト
www.example.comと動的Webサイトaliyundoc.comは、ECSインスタンスにデプロイされています。 CLBは、Webサイトに負荷分散サービスを提供するために使用されます。 バックエンドデータベースがダウンしています。 その結果、www.example.comにアクセスするとHTTP 502エラーが発生します。考えられる原因
ヘルスチェックドメイン名が
aliyundoc.comに設定されています。 ApsaraDB RDSインスタンスまたは自己管理データベースがダウンしていると、aliyundoc.comへのアクセスが失敗し、ヘルスチェックが失敗します。ソリューション
ヘルスチェックドメイン名を
www.example.comに変更します。
バックエンドポートがTCPヘルスチェックに合格しているにもかかわらず、ログデータがバックエンドポートへの接続失敗を示すのはなぜですか。
問題
ログデータは、TCPリスナーのバックエンドポートへの頻繁な接続失敗を示します。 パケットキャプチャツールは、接続要求のソースを識別するために使用される。 結果は、接続要求がCLBによって送信されることを示す。 パケットキャプチャツールは、CLBによって送信されたRSTパケットもキャプチャしています。
考えられる原因
この問題は、ヘルスチェックメカニズムに関連しています。
TCPヘルスチェックを実行するために、CLBはSYNパケットを送信してバックエンドポートの可用性を確認します。 SYN-ACKパケットが返された場合、CLBはバックエンドポートに到達可能であると見なし、3ウェイハンドシェイクが完了した後にRSTパケットを送信して接続を閉じます。 これにより、バックエンドサーバーの負荷が軽減され、サービスの中断が防止されます。 しかし、アプリケーション層は、TCP接続の状態を認識していない。 次のセクションでは、データ交換プロセスについて説明します。
CLBはバックエンドポートにSYNパケットを送信します。
バックエンドポートが期待どおりに機能する場合、SYN-ACKパケットが返されます。
CLBがバックエンドポートから応答を受信した後、CLBはバックエンドポートが到達可能であるとみなす。 この場合、ヘルスチェックは成功します。
次に、CLBは、接続を介してサービス要求を送信する代わりに、接続を閉じるためにRSTパケットをバックエンドポートに送信します。
CLBがヘルスチェックを完了すると、TCP接続が閉じられます。 TCP接続のステータスは、アプリケーション層のサービスの接続プール (Java接続プールなど) に更新されません。 したがって、
[Connection reset by peer]エラーが発生します。ソリューション
TCPヘルスチェックの代わりにHTTPヘルスチェックを実行するようにCLBを設定します。
さらに、CLBのCIDRブロックからのリクエストを記録するログエントリを除外し、関連するエラーメッセージを無視します。
期待どおりに動作するバックエンドサーバーがヘルスチェックに失敗するのはなぜですか?
問題
HTTPヘルスチェックは常に失敗しますが、
curl -Iコマンドを実行すると、返されるステータスコードは正常です。考えられる原因
返されたステータスコードがコンソールのヘルスチェック設定で指定されていない場合、バックエンドサーバーはヘルスチェックに失敗します。 たとえば、コンソールでHTTP 2xxステータスコードを指定し、別のステータスコードが返された場合、バックエンドサーバーはヘルスチェックに失敗します。
TengineまたはNGINXで
curlコマンドを実行すると、宛先に到達可能であることが示されます。 ただし、echoコマンドを実行してテストファイルtest.htmlにアクセスすると、次の図に示すように、既定のWebサイトに誘導され、HTTP 404エラーコードが返されます。
ソリューション
メイン設定ファイルを変更し、デフォルトサイトをコメントアウトします。
ヘルスチェックに使用されるドメイン名をヘルスチェック設定に追加します。