Oracle Cloud Infrastructureドキュメント

ヘルス・チェック・ポリシーの編集

このトピックでは、バックエンド・セットのヘルス・チェック・ポリシーを変更する方法について説明します。

必要なIAMポリシー

Oracle Cloud Infrastructureを使用するには、管理者が作成するポリシーで、コンソールまたはSDK、CLIまたはその他のツールを使用したREST APIのどちらを使用しているかにかかわらず、必要なタイプのアクセスを付与する必要があります。 アクションを実行しようとしたときに、権限のないメッセージや権限のないメッセージを取得する場合は、管理者に付与されているアクセスのタイプと作業するコンパートメントを確認してください。

管理者向け: ロード・バランサとそのコンポーネントにアクセスできる典型的なポリシーについては、「ネットワーク管理者がロード・バランサを管理できるようにします」を参照してください。

また、inspect load-balancersを含むポリシー・ステートメントは、指定されたグループに、ロード・バランサに関するall情報を表示する機能を提供することに注意してください。 詳細は、「Load Balancingの詳細」を参照してください。

新しいポリシーの場合は、「ポリシーの開始」「共通ポリシー」を参照してください。

ヘルス・チェック・ポリシーの使用

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

「バックエンド・セットを作成」でヘルス・チェック・ポリシーを構成します。 バックエンド・サーバーのTCPレベルまたはHTTPレベルのヘルス・チェックを構成できます。

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

このサービスは、アプリケーション固有のヘルス・チェック機能を提供し、可用性を向上させ、アプリケーションのメンテナンス期間を短縮します。

重要

アプリケーションまたはサービスに合わせてヘルス・チェック・プロトコルを構成します。

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

  • バックエンドHTTPサービスに問題があり、5XXメッセージが返されます。 HTTPヘルス・チェックでメッセージがキャッチされ、サービスが停止しているとマークされます。 この場合、HTTPヘルス・チェック・ハンドシェイクが成功し、HTTPサービスが使用できない場合でも、サービスは健全であるとマークされます。
  • バックエンドのHTTPサービスは、認証の問題や構成されたコンテンツがないため、4XXメッセージで応答します。 TCPヘルス・チェックではこれらのエラーは検出されません。

状態ステータス

Load Balancingサービスは、ヘルス・チェック・ポリシーを使用してロード・バランサとそのコンポーネントの一般的な状態を報告するヘルス・ステータス・インジケータを提供します。 コンソール 「リスト」ページと「詳細」ページには、ロード・バランサ、バックエンド・セット、バックエンド・サーバーのヘルス・ステータス・インジケータが表示されます。 また、Load Balancing APIを使用してこの情報を取得することもできます。

ヘルス・ステータス・インジケータには4つのレベルがあります。 各レベルの一般的な意味は次のとおりです:

ok (緑色)
注意は必要ありません。
リソースが期待通りに機能しています。
警告(黄色)
一部の報告主体は注意が必要です。
リソースがピーク効率で機能していないか、リソースが不完全であり、さらに作業が必要です。
クリティカル(赤)
一部またはすべての報告主体は直ちに注意を要します。
リソースが機能していないか、予期しない障害が差し迫っています。
未知(灰色)
ヘルス・ステータスを特定することはできません。
リソースが応答していないか、移行中であり、時間の経過とともに別のステータスに解決される可能性があります。

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

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

最も高いレベルでは、ロード・バランサの健全性はコンポーネントのヘルスを反映します。 ヘルス・ステータス・インジケータは、既存の問題をドリルダウンして調査する必要がある情報を提供します。 ヘルス・ステータス・インジケータが検出して修正するのに役立つ一般的な問題には、次のものがあります:

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

この場合、1つまたは複数の影響を受けるリスナーのすべてのバックエンド・サーバーが正常でないと報告されます。 バックエンド・サーバーに問題がないことが調査で分かった場合、バックエンド・セットにはヘルス・チェックの設定が誤っている可能性があります。

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

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

リスナーは次のように構成されます:

  • 間違ったポートをリスンします。
  • 間違ったプロトコルを使用します。
  • 間違ったポリシーを使用します。

調査の結果、リスナーに問題がないことが示された場合は、セキュリティ・リストの構成を確認してください。

セキュリティ・リストが誤って設定されています。

ヘルス・ステータス・インジケータは、誤って構成されたセキュリティ・リストの2つのケースを診断するのに役立ちます:

  • すべてのエンティティのヘルス・ステータス・インジケータはOKを報告しますが、トラフィックは流れません(誤った構成のリスナーの場合のように)。 リスナーに障害がない場合は、セキュリティ・リストの構成を確認してください。
  • すべてのエンティティの健全性ステータスは、不健全であると報告されます。 ヘルス・チェックの構成がチェックされ、バックエンド・サーバーでサービスが正常に実行されています。

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

    ノート

    ソースIP

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

1つ以上のバックエンド・サーバーが不健全であると報告します。

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

ヘルス・ステータスが有用と思われるその他の場合には:

ヘルス・ステータスの制限

ヘルス・ステータスは3分ごとに更新されます。 より細かい粒度は利用できません。

ヘルス・ステータスは、履歴データを提供しません。

コンソールの使用

「バックエンド・セットを作成」でヘルス・チェック・テストを作成します。

既存のヘルス・チェック・ポリシーを編集するには

APIの使用

APIおよび署名リクエストの使用については、REST APIおよび「セキュリティ資格証明」を参照してください。 SDKの詳細は、「ソフトウェア開発キットとコマンドライン・インタフェース」を参照してください。

このAPI操作を使用して、バックエンド・セットのヘルス・チェック・ポリシーを編集します:

UpdateBackendSet

これらのAPI操作を使用してヘルス・ステータス情報を取得します: