Oracle Cloud Infrastructureドキュメント

ネットワーク・ロード・バランサのヘルス・チェック・ポリシー

ヘルス・チェックを設定して使用し、ネットワーク・ロード・バランサに対するバックエンド・サーバーの可用性を決定します。

ヘルス・チェックは、バックエンド・サーバーの可用性を確認するテストです。ヘルス・チェックは、リクエストまたは接続試行です。指定された時間間隔に基づいて、ネットワーク・ロード・バランサは、ヘルス・チェック・ポリシーを適用し、バックエンド・サーバーを継続的にモニターします。サーバーがヘルス・チェックに失敗すると、ネットワーク・ロード・バランサは一時的にそのサーバーをローテーションから除外します。サーバーが後でヘルス・チェックに合格すると、ネットワーク・ロード・バランサはそれをローテーションに戻します。

ヘルス・チェック・ポリシーは、ネットワーク・ロード・バランサの作成時に構成します。既存のロード・バランサのバックエンド・セットを作成または編集するときに、ヘルス・チェック・ポリシーを構成することもできます。ヘルス・チェック・ポリシーで使用できるプロトコルのサマリーを次に示します。

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

    使用しているプロトコルに対するリクエストの作成が現実的でない場合は、リクエスト・データを省略できます。この場合、TCP接続が成功すると、バックエンドは正常とみなされます。

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

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

  • UDPレベルのヘルス・チェックでは、単一のリクエストをバックエンド・サーバーに送信し、指定されたレスポンス・データとレスポンス(受信した場合)を照合します。

  • DNSレベルのヘルス・チェックでは、UDPまたはTCPを使用して、バックエンド・サーバーにリクエストを送信します。ヘルス・チェックでは、バックエンド・サーバーからのDNSレスポンスを提供する問合せ名および関連情報も使用されます。

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

次のヘルス・チェック・ポリシー管理タスクを実行できます:

アプリケーションまたはサービスと一致するようなヘルス・チェック・プロトコルの構成

HTTPサービスを実行する場合は、必ずHTTPレベルのヘルス・チェックを構成してください。TCPレベルのヘルス・チェックをHTTPサービスに対して実行すると、正しいレスポンスを得られないことがあります。HTTPサービスが誤って構成されていたり、他に問題があったりしても、TCPハンドシェイクは成功し、サービスは稼働中であると示される可能性があります。ヘルス・チェックは良好なようでも、顧客にトランザクション障害が発生する可能性があります。例:

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

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

ヘルス・ステータス・インジケータ

Network Load Balancerサービスには、ヘルス・チェック・ポリシーを使用してネットワーク・ロード・バランサとそのコンポーネントの一般的なヘルスをレポートするヘルス・ステータス・インジケータがあります。ロード・バランサ、バックエンド・セットおよびバックエンド・サーバーのヘルス・ステータス・インジケータは、コンソールの「リスト」および「詳細」ページで確認できます。APIを使用して、この情報を取得することもできます。

ヘルス・ステータス・インジケータには4つのレベルがあります。次の表は、各レベルの一般的な意味を示しています:

レベル

色

説明

OK

緑色

対応は必要ありません。

リソースは正常に機能しています。

警告

黄色

一部のレポート・エンティティに対応が必要です。

リソースが最大効率で機能していないか、リソースが不十分で追加の作業が必要です。

クリティカル

赤色

一部または全部のレポート・エンティティに即座の対応が必要です。

リソースが動作していないか、予期しない障害の可能性があります。

不明

灰色

ヘルス・ステータスを特定できません。

リソースが応答していないか、遷移中のため時間の経過とともに他のステータスに移行する可能性があります。

各レベルの正確な意味は、次のコンポーネントによって異なります:

ヘルス・ステータスの使用

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

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

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

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

すべてのバックエンド・サーバーのヘルス・ステータス・インジケータがOKをレポートしますが、ネットワーク・ロード・バランサはリスナーにトラフィックを渡しません。

リスナーが次のように構成されている可能性があります:

  • 不正なポートでリスニングしています。

  • 不正なプロトコルを使用しています。

  • 不正なポリシーを使用しています。

調査の結果、リスナーに障害が発生していない場合は、セキュリティ・リスト構成を確認してください。

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

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

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

  • すべてのエンティティのヘルス・ステータスが異常としてレポートされます。ヘルス・チェック構成を確認し、サービスがバックエンド・サーバーで正しく実行されていることを確認しました。

    この場合、セキュリティ・ルールにヘルス・チェック・リクエストのソースのIP範囲が含まれていない可能性があります。ヘルス・チェックのソースIPは、各バックエンド・サーバーの「詳細」ページで確認できます。APIを使用して、HealthCheckResultオブジェクトのsourceIpAddressフィールドでIPを確認することもできます。

    ノート

    ヘルス・チェック・リクエストのソースIPは、Network Load Balancerサービスによって管理されるコンピュート・インスタンスから取得されます。

1つ以上のバックエンド・サーバーが異常としてレポートされます。

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

ヘルス・ステータスが役立つ可能性があるその他のケースを示します:

ヘルス・ステータスは3分ごとに更新されます。これより短い間隔は使用できません。

ヘルス・ステータスに履歴ヘルス・データはありません。

ヘルス・チェックのベスト・プラクティス

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

例:

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

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

ヘルス・チェックの構成ミスの一般的な悪影響

次に、ヘルス・チェックの構成ミスの一般的な悪影響を示します。これらは問題のトラブルシューティングに使用できます。

  • 不正なポート

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

    OCIロギング・エラー: errno":"EHOSTUNREACH","syscall":"connect".

  • パスが正しくありません

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

    例: 

    $ curl -i http://10.0.0.5/health

    レスポンスのOCIロギング・エラーで構成済のステータス・コードを受け取ります: 

    "msg":"invalid statusCode","statusCode":404,"expected":"200".

  • 不正なプロトコル

    このシナリオでは、すべてのバックエンド・サーバーが異常としてレポートされます。バックエンド・サーバーに問題がない場合、バックエンドでリスニングしているプロトコルと一致させる必要があります。例: TCPおよびHTTPヘルス・チェックのみがサポートされます。バックエンド・サーバーがHTTPSを使用している場合は、プロトコルとしてTCPを使用します。

    OCIロギング・エラー:

    "code":"EPROTO","errno":"EPROTO".

  • 不正なステータス・コード

    このシナリオでは、すべてのバックエンド・サーバーが異常としてレポートされます。バックエンド・サーバーに問題がない場合、HTTPヘルス・チェックでは、バックエンドから返される実際のステータス・コードと一致させるステータス・コードの設定が間違っている可能性があります。一般的なシナリオは、バックエンドが302を返しているが、200を予想している場合です。この結果では、バックエンドによってユーザーがサーバーのサインイン・ページまたは別の場所に転送されている可能性があります。このシナリオでは、バックエンドを修正して予想されるコードを返すか、ヘルス・チェック構成で302を使用できます。

    OCIロギング・エラー:

    "msg":"invalid statusCode","statusCode":XX,"expected":"200"

    ここで、XXは、返されるステータス・コードです。

  • 不正な正規表現パターン

    すべてのバックエンド・サーバーが異常としてレポートされます。バックエンド・サーバーに問題がない場合、本文と一致する正規表現パターンの設定が不適切で間違っている可能性があるか、バックエンドが予想されるボディを返していません。このシナリオでは、パターンと一致するようにバックエンドを変更するか、バックエンドと一致するようにパターンを修正できます。次に、具体的なパターンの例を示します。

    • 任意のコンテンツ - ".*"

    • "Status:OK:"という値を返すページ - "Status:OK:.*"

    • OCIロギング・エラー: "response match result: failed"

  • 正しく構成されていないネットワーク・セキュリティ・グループ、セキュリティ・リストまたはローカル・ファイアウォール

すべてまたは一部のバックエンド・サーバーが異常としてレポートされます。バックエンド・サーバーに問題がない場合、NSG、セキュリティ・リストまたはローカル・ファイアウォール(firewalld、iptables、SELiinuxなど)の構成が誤っている可能性があります。このシナリオでは、バランサ・インスタンスHTTPと同じサブネットおよびNSGに属するシステムからcurlまたはnetcatテストを使用できます:

例: 

$ curl -i http://10.0.0.5/health TCP: ex: nc -zvw3 10.0.05 443.

次のコマンドを使用して、ローカル・ファイアウォールを確認できます: 

firewall-cmd --list-all --zone=public.

ファイアウォールに予想されるルールが欠落している場合は、次のようなコマンド・セットを使用してサービスを追加できます(この例はHTTPポート80用です): 

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

アプリケーションまたはサービスと一致するようなヘルス・チェック・プロトコルの構成

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

HTTPサービスを実行する場合は、必ずHTTPレベルのヘルス・チェックを構成してください。TCPレベルのヘルス・チェックをHTTPサービスに対して実行すると、正しいレスポンスを得られないことがあります。HTTPサービスが誤って構成されていたり、他に問題があったりしても、TCPハンドシェイクは成功し、サービスは稼働中であると示される可能性があります。ヘルス・チェックは良好なようでも、顧客にトランザクション障害が発生する可能性があります。例:

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

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

DNSヘルス・チェック

ネットワークLoad Balancerサービスは、IPv4およびIPv6バックエンド・サーバーの両方について、TCPおよびUDPトランスポートを介したDNSヘルス・チェックをサポートします。DNSリゾルバ・バックエンド・サーバーのDNSヘルス・チェックは、DNSリゾルバ・バックエンド・サーバーに対してDNSプロトコルが機能していることを検証するため、TCPまたはUDPベースのチェックよりも改善されます。これらのプロトコルでは、リクエスト・メッセージおよびレスポンス・メッセージを指定するためにbase64形式が使用され、DNSリクエストおよびレスポンスを形成するときに困難になる場合があります。また、レスポンス・メッセージには、NOERROR(0)とNXDOMAIN(3)の両方など、複数の有効な回答とRCODEがあります。標準のTCPまたはUDPヘルス・チェックを使用してこれらのシナリオをすべて処理することはできません。

バックエンド・セットを作成するときに、最初のネットワーク・ロード・バランサの作成時または既存のネットワーク・ロード・バランサにバックエンド・セットを追加するときに、DNSヘルス・チェックを使用している場合は、次のプロトコル固有の構成を指定する必要があります:

  • 問合せ名: 問合せのDNSドメイン名を指定します。

  • 問合せクラス: 次のオプションから選択します。

    • IN: インターネット(デフォルト)

    • CH: カオス

  • 問合せタイプ: 次のオプションから選択します。

    • A: 対応するホスト名IPv4アドレスを示します。(デフォルト)

    • AAAA: 対応するIPv6アドレスを示すホスト名。

    • TXT: テキスト・フィールドを示します。

  • 受理可能な応答コード: 次のオプションから1つ以上を選択します。

    • RCODE:0 NOERROR DNS問合せが正常に完了しました。

    • RCODE:2 SERVFAILサーバーは DNS要求を完了できませんでした。

    • RCODE:3 NXDOMAINドメイン名が存在しません。

    • RCODE:5 REFUSEDサーバーは問合せの回答を拒否しました。