- Server Load Balancer (SLB) のヘルスチェック機能はどのように機能しますか。
- 推奨されるヘルスチェックの設定を教えてください。
- ヘルスチェック機能を無効にすることはできますか。
- TCP リスナーの推奨ヘルスチェック方法を教えてください。
- ECS インスタンスの重みがゼロである場合、ヘルスチェックに何らかの影響がありますか。
- バックエンド ECS インスタンスの HTTP リスナーに使用されるのはどのヘルスチェック方法ですか。
- HTTP リスナーがバックエンド ECS インスタンスのヘルスチェックを実行するために使用する IP アドレス範囲を教えてください。
- コンソールに表示されるヘルスチェックの頻度が、Web ログに記録されているものと異なるのはなぜですか。
- ヘルスチェックはシステムリソースを使用しますか。
- 障害のあるバックエンドデータベースが原因でヘルスチェックに失敗した場合はどのようにすればよいですか。
- ネットワーク接続の例外がバックエンドサービスのログに記録されているのに、TCP ヘルスチェックが成功と表示されるのはなぜですか。
- サービスが正常に動作しているのに、ヘルスチェック結果が異常として返されるのはなぜですか。
Server Load Balancer (SLB) のヘルスチェック機能はどのように機能しますか。
SLB は、バックエンドサーバーでヘルスチェックを実行して、バックエンドサーバー (ECS インスタンス) のサービス可用性をチェックします。ECS インスタンスの異常を検出すると、SLB は再び正常になるまで ECS インスタンスへのリクエストの配布を停止します。
ヘルスチェックの実行に使用される IP アドレス範囲は 100.64.0.0/10 です。 バックエンド ECS インスタンスがこの CIDR ブロックをブロックしないようにしてください。 この CIDR ブロックからのアクセスを許可するセキュリティグループルールの追加設定は必要ありません。 ただし、iptables などのセキュリティルールを設定している場合は、この CIDR ブロックからのアクセスを許可する必要があります。 (100.64.0.0/10 は Alibaba Cloud によって予約されています。他のユーザーはこの CIDR ブロックで一切の IP アドレスを使用できないため、セキュリティ上のリスクはありません。)
詳細については、「ヘルスチェックの概要」ご参照ください。
推奨されるヘルスチェックの設定を教えてください。
頻繁なヘルスチェックの失敗によって引き起こされるバックエンドサーバーの切り替えがシステム可用性に影響を与えないように、バックエンドサーバーのヘルスチェックのステータスを切り替える前に、ヘルスチェックの失敗または成功が特定のしきい値に達する必要があります。 詳細については、「ヘルスチェックの概要」をご参照ください。
TCP/HTTP/HTTPS リスナーに推奨されるヘルスチェックの設定は次のとおりです。
設定項目 | 推奨値 |
---|---|
レスポンスタイムアウト | 5 秒 |
ヘルスチェック間隔 | 2 秒 |
異常状態のしきい値 | 3 回 |
以下は、UDP リスナーに推奨されるヘルスチェック設定です。
設定項目 | 推奨値 |
---|---|
レスポンスタイムアウト | 10 秒 |
ヘルスチェック間隔 | 5 秒 |
異常状態のしきい値 | 3 回 |
正常状態のしきい値 | 3 回 |
ヘルスチェック機能を無効にすることはできますか。
HTTP と HTTPS リスナー向けのヘルスチェックのみ無効にすることができます。 UDP と TCP リスナーのヘルスチェックを無効にすることはできません。 詳細については、「ヘルスチェックの無効化」をご参照ください。
TCP リスナーの推奨ヘルスチェック方法を教えてください。
TCP リスナーの場合、TCP ヘルスチェックと HTTP ヘルスチェックの両方に対応しています。
- TCP ヘルスチェックは、バックエンドサーバーのポートが正常かどうかをチェックするために、SYN ハンドシェイクパケットをバックエンドサーバーに送信します。
- HTTP ヘルスチェックは、HEAD リクエストと GET リクエストを送信してユーザーのブラウザからの訪問をシミュレートすることで、バックエンドサーバー上のアプリケーションのヘルスステータスを検出します。
TCP ヘルスチェックはバックエンドサーバーのパフォーマンスへの影響を最小限に抑え、サーバーリソースの消費量を減らします。 バックエンドサーバーのトラフィック負荷が高い場合は TCP ヘルスチェック、低い場合は HTTP ヘルスチェックを選択します。
ECS インスタンスの重みがゼロである場合、ヘルスチェックに何らかの影響がありますか。
ECS インスタンスの重みをゼロに設定すると、SLB はトラフィックをこの ECS インスタンスに転送しなくなり、レイヤー 4 リスナーのヘルスチェックはバックエンド ECS インスタンスの異常を示します (ヘルスチェックはレイヤー 7 リスナーの場合は正常です)。
重み値をゼロに設定することは、Server Load Balancer から ECS インスタンスを手動で削除することと同じです。 通常ウェイトは、ECS インスタンスを再起動、調整、または維持するときにのみゼロに設定されます。
バックエンド ECS インスタンスの HTTP リスナーに使用されるのはどのヘルスチェック方法ですか。
HEAD リクエストメソッドです。
curl -v -0 -I -H "Host:" -X HEAD http://IP:port
HTTP リスナーがバックエンド ECS インスタンスのヘルスチェックを実行するために使用する IP アドレス範囲を教えてください。
SLB のヘルスチェックで使用される IP アドレスの範囲は 100.64.0.0/10 (100.64.0.0/10 は Alibaba Cloud によって予約済みで、ユーザーには使用できません。セキュリティリスクはありません) です。 バックエンド ECS インスタンスが iptables などのアクセス制御を有効にしている場合は、イントラネット NIC で 100.64.0.0/10 (100.64.0.0/10 は Alibaba Cloud によって予約済みで、ユーザーには使用できません。セキュリティリスクはありません) のアクセスを許可する必要があります。
コンソールに表示されるヘルスチェックの頻度が、Web ログに記録されているものと異なるのはなぜですか。
単一障害点を回避するために、クラスターでヘルスチェックが実行されます。 したがって、ログに記録されたヘルスチェックの頻度は、コンソールで設定された頻度とは異なります。
ヘルスチェックはシステムリソースを使用しますか。
HTTP ヘルスチェックは、バックエンド ECS インスタンスのリソースをほとんど消費しません。
障害のあるバックエンドデータベースが原因でヘルスチェックに失敗した場合はどのようにすればよいですか。
現象:
2 つの Web サイトが ECS インスタンスに設定されています。 Web サイト www.test.com は静的 Web サイトで、Web サイト app.test.com は動的 Web サイトです。 www.test.comにアクセスすると、バックエンドデータベースの障害により502 エラーが発生します。
原因:
ドメイン名 app.test.com はヘルスチェック用に設定されています。RDS または自己構築データベースの障害により、app.test.com へのアクセスエラーが発生するため、ヘルスチェックが失敗します。
解決方法:
ヘルスチェックに使用するドメイン名を www.test.com に設定します。
ネットワーク接続の例外がバックエンドサービスのログに記録されているのに、TCP ヘルスチェックが成功と表示されるのはなぜですか。
現象:
SLB リスナーでバックエンド TCP ポートを設定した後、ネットワーク接続の例外がバックエンドサービスログに頻繁に表示されます。リクエストは SLB インスタンスから送信され、SLB インスタンスは同時に RST パケットをバックエンドサーバーにも送信します。
原因:
問題はヘルスチェックメカニズムに関連しています。
TCP は上位レベルのアプリケーションに対して透過的で、ヘルスチェックのコストとバックエンドサービスへの影響を減らすために利用されます。 TCP ヘルスチェックは、単純な 3 ウェイハンドシェイクを実行してから直接 RST パケットを送信して、TCP 接続を終了します。 データ交換のプロセスは次のとおりです。
- SLB インスタンスは SYN パケットをバックエンドポートに送信します。
- バックエンドポートが正常な状態にある場合、バックエンドサーバは SYN-ACK でレスポンスします。
- バックエンドポートからのレスポンスを正常に受信した後、SLB インスタンスはポートが正常な状態にあり、バックエンドサーバーの状態が正常であると見なします。
- SLB インスタンスは RST パケットをバックエンドポートに送信して、接続をアクティブに終了します。 この時点で、ヘルスチェックは完了しています。
ヘルスチェックが成功すると、SLB インスタンスは RST パケットを直接送信して接続を終了します。その後、データは送信されません。 したがって、上位レベルのサービス
(Java 接続プールなど) は、接続が異常であると判断し、Connection reset by pee
などのエラーが発生します。
解決方法:
- HTTPプロトコルを使用してください。
- サービス層で、SLB IP アドレス範囲からログをフィルタリングし、関連するエラーメッセージを無視します。
サービスが正常に動作しているのに、ヘルスチェック結果が異常として返されるのはなぜですか。
現象:
curl -I
テストを実施して取得したステータスコードは以下のとおり正常です。
echo -e ‘HEAD /test.html HTTP/1.0\r\n\r\n’ | nc -t 192.168.0.1 80
原因:
返されたステータスコードがコンソールで設定されている通常のステータスコードと異なる場合、バックエンド ECS インスタンスは異常と判断されます。 たとえば、設定されている通常のステータスコードが http_2xx の場合、返されたステータスコードでこのステータスコードと一致しないものはすべてヘルスチェック失敗と見なされます。
Tengine/Nginx クラスターで curl テストを実行してもエラーは発生しませんでしたが、デフォルトサイトがエコーテストで使用されているため、test.html テストファイルで 404 エラーが発生しました。
解決方法:
- メイン設定ファイルを修正し、デフォルトサイトにアノテーションを付けます。
- ヘルスチェック設定にヘルスチェックに使用されるドメイン名を追加します。