Oracle Cloud Infrastructureドキュメント

ヘルス・チェック

ロード・バランサのヘルス・チェックは、バックエンド・サーバーの可用性を確認するためのテストです。

これらのテストは、プロトコルに応じて、リクエストまたは接続の試行の形式で行われます。ヘルス・チェック・ポリシーには、バックエンド・サーバーが継続的に監視されるように、指定した時間間隔が含まれます。サーバーがヘルス・チェックに失敗すると、ロード・バランサは一時的にそのサーバーをローテーションから除外します。サーバーが後で後続のヘルス・チェックに合格すると、LBはそのバックエンド・サーバーをバランシング・ローテーションに戻します。

ヘルス・チェック・ポリシーは、バックエンド・セットの作成時に構成されます。バックエンド・サーバーに対して、TCPレベルまたはHTTPレベルのヘルス・チェックを構成できます。SSLで構成されたバックエンド・セットの場合、ヘルス・チェックでもSSL暗号化が使用されます。

  • TCPレベルのヘルス・チェックでは、バックエンド・サーバーとのTCP接続を試行し、接続ステータスに基づいてレスポンスを検証します。

  • HTTPレベルのヘルス・チェックでは、特定のURIのバックエンド・サーバーにリクエストを送信し、返されるステータス・コードまたはエンティティ・データ(本文)に基づいてレスポンスを検証します。

ヘルス・チェック・プロトコルをアプリケーションまたはサービスと一致するように構成してください。HTTPサービスを実行する場合は、HTTPレベルのヘルス・チェックを構成してください。HTTPサービスに対してTCPレベルのヘルス・チェックを実行すると、正確なレスポンスを得られないことがあります。HTTPサービスが誤って構成されていたり、他に問題があったりしても、TCPハンドシェイクは成功し、サービスは稼働中であると示される可能性があります。ヘルス・チェックではエラーは返されませんが、トランザクション障害が発生する可能性があります。

次に例を示します。

  • バックエンドHTTPサービスがヘルス・チェックURLと通信中に問題が発生し、ヘルス・チェックURLが5nnメッセージを返します。HTTPヘルス・チェックは、ヘルス・チェックURLからメッセージを捕捉し、サービスを停止としてマークします。この場合、HTTPサービスが使用不可であっても、TCPヘルス・チェックのハンドシェイクは成功し、サービスは正常としてマークされます。

  • 認可の問題があるか、または構成されたコンテンツがないため、バックエンドHTTPサービスは4nnメッセージで応答します。TCPヘルス・チェックでは、これらのエラーは捕捉されません。

このサービスは、可用性を向上し、アプリケーション・メンテナンス・ウィンドウを短縮するのに役立つアプリケーション固有のヘルス・チェック機能を提供します。

ヘルス・ステータス・インジケータは、ロード・バランサとそのバックエンド・サーバー/セットの一般的なヘルスをレポートするために使用されます。可能なステータスは、ok、warning、critical、unknownです。ヘルス・ステータスは3分ごとに更新されます。これより短い間隔は使用できません。履歴ヘルス・データが指定されていません。

Load Balancerのヘルス問題の解釈

最高レベルでは、ロード・バランサ・ヘルスはそのコンポーネントのステータスを反映します。ヘルス・ステータス・インジケータは、さらにドリルダウンして調査するために必要な情報を提供します。次に、ヘルス・ステータス・インジケータが検出と修正に役立ついくつかの一般的な問題を示します。

ヘルス・チェックが正しく構成されていません

影響を受ける1つ以上のリスナーのすべてのバックエンド・サーバーが異常としてレポートされます。バックエンド・サーバーに問題がないことが調査でわかった場合、バックエンド・セットに正しく構成されていないヘルス・チェックが含まれる可能性があります。

リスナーが正しく構成されていません

すべてのバックエンド・サーバーのヘルス・ステータス・インジケータはOKをレポートしますが、ロード・バランサがリスナーのトラフィックを通過させません。リスナーは、間違ったポートでリスニングするか、間違ったプロトコルを使用するか、間違ったポリシーを使用するように構成されている可能性があります。調査の結果、リスナーに障害がない場合は、セキュリティ・ルール構成を確認してください。

セキュリティ・ルールが正しく構成されていません

ヘルス・ステータス・インジケータは、正しく構成されていないセキュリティ・ルールの次のケースの診断に役立ちます:

  • すべてのヘルス・ステータス・インジケータはOKをレポートしますが、トラフィックがフローしません(正しく構成されていないリスナーと同様)。リスナーに障害がない場合は、セキュリティ・ルール構成を確認してください。

  • すべてのヘルス・ステータス・インジケータが異常としてレポートされます。ヘルス・チェック構成は確認済で、サービスはバックエンド・サーバーで正しく実行されています。この場合、セキュリティ・ルールにヘルス・チェック・リクエストのソースのIP範囲が含まれていない可能性があります。ヘルス・チェック・リクエストのソースIPは、ロード・バランシング・サービスによって管理されるコンピュート・インスタンスに属します。

ノート

コンピュート・インスタンス内のルート表が正しく構成されていないため、トラフィックがブロックされることもあります。

バックエンド・サーバーが異常です

バックエンド・サーバーが異常であるか、ヘルス・チェックが正しく構成されていない可能性があります。対応するエラー・コードを参照するには、コンソールまたはCLIを使用して、バックエンド・サーバーの詳細の「ステータス」フィールドを確認します。

Load Balancerのヘルス・チェックの構成ミスの一般的な副作用

誤った構成シナリオは定期的に発生することがわかっています。このページは、トラブルシューティングに役立ちます。

不正なポート
このシナリオでは、すべてのバックエンド・サーバーが異常としてレポートされます。バックエンド・サーバーに問題がないことを確認した場合は、ポートの設定が間違っている可能性があります。トラフィックが許可され、バックエンドがそのポートでリスニングしている必要があります。
パスが正しくありません

このシナリオでは、すべてのバックエンド・サーバーが異常としてレポートされます。バックエンド・サーバーに問題がないことを確認した場合は、HTTPヘルス・チェックのパスの設定が間違っている可能性があります。バックエンドの実際のアプリケーションと一致する必要があります。

curlユーティリティを使用して、同じネットワーク内のシステムからテストを実行できます。例: curl -i http://backend_ip_address/health.

応答で構成済のステータス・コードを受け取ります。 
"msg":"invalid statusCode","statusCode":404,"expected":"200"
不正なプロトコル

このシナリオでは、すべてのバックエンド・サーバーが異常としてレポートされます。バックエンド・サーバーに問題がないことを確認した場合、HTTPヘルス・チェックでは、ステータス・コードの設定が間違っている可能性があります。バックエンドから返される実際のステータス・コードと一致する必要があります。一般的な不一致は、バックエンドが302ステータス・コードを返し、200ステータス・コードが予想される場合です。これは、多くの場合、バックエンドがサーバー上のログイン・ページまたは別の場所に誘導していることが原因です。バックエンドで予想されるコードを返すか、ヘルス・チェック構成で302を使用できます。

エラー・メッセージ: msg:invalid statusCode, statusCode:nnn,expected:200 (ここで、nnnは返される実際のステータス・コードを表します)。

不正な正規表現パターン

このシナリオでは、すべてのバックエンド・サーバーが異常としてレポートされます。バックエンド・サーバーに問題がないことを確認した場合、本文と一致しない正規表現パターンの設定でエラーが発生した可能性があるか、バックエンドが予想される本文を返していません。このシナリオでは、パターンと一致するようにバックエンドを変更するか、バックエンドと一致するようにパターンを修正できます。

エラー・メッセージ: response match resulte: failed。

正しく構成されていないセキュリティ・ルール

このシナリオでは、すべてまたは一部のバックエンド・サーバーが異常としてレポートされます。バックエンド・サーバーに問題がないことを確認した場合、ネットワーク・セキュリティ・グループ、セキュリティ・リストまたはローカル・ファイアウォール(firewalld、iptables、SELinuxなど)のいずれかが正しく構成されていない可能性があります。

このシナリオでは、curlまたはnetcatユーティリティを使用して、ロード・バランサ・インスタンスHTTPと同じサブネットおよびネットワーク・セキュリティ・グループ(NSG)内のシステムからテストを実行できます。例: curl -i http://backend_ip_address/health TCP or nc -zvw3 backend_ip_address 443。

ローカル・ファイアウォールは、firewall-cmd --list-all --zone=publicコマンドを使用して検証できます。ファイアウォール構成に必要なルールがない場合は、必要なサービスを追加します。たとえば、HTTPポート80を追加するには:

firewall-cmd --zone=public --add-service=http
firewall-cmd --zone=public --permanent --add-service=http