バックエンド構成

バックエンド・セット

ロード・バランサ構成のバックエンド・セットは、バックエンド・サーバーのリスト、ロード・バランシング・ポリシーおよびヘルス・チェック・スクリプトで構成されます。バックエンド・セットは、1つ以上のリスナーに関連付ける必要があります。オプションで、セッション永続性設定を追加し、HTTPSリクエストのSSLを構成できます。

注意:

バックエンド・セットのロード・バランシング・ポリシーを変更すると、トラフィックが中断され、アクティブな接続が切断される可能性があります。

バックエンド・サーバー

ロード・バランサを作成する場合、各バックエンド・セットに含めるバックエンド・サーバーを指定する必要があります。バックエンド・サーバーは、個々のコンピュート・インスタンスとして、またはインスタンス・プールとして設定できます。バックエンド・サーバーのトランスポート・プロトコルは、バックエンド・セットの一部として構成されます。トラフィックを中断させずにバックエンド・サーバーを追加および削除できます。

バックエンド・セットにバックエンド・サーバーを追加する場合、追加するサーバーのインスタンスOCIDまたはIPアドレスを指定します。複数のVNICがアタッチされているインスタンスは、それを指し示す複数のIPアドレスを持つことができます。バックエンド・サーバーをOCIDで識別する場合、ロード・バランシング・サービスは、プライマリVNICのプライマリ・プライベートIPアドレスを使用します。バックエンド・セットに追加するバックエンド・サーバーをIPアドレスで識別する場合、同じインスタンスを複数回指すことができます。

ロード・バランサは、選択したロード・バランシング・ポリシーに基づいて、受信トラフィックをバックエンド・サーバーにルーティングします。トラフィックをバックエンド・サーバーにルーティングするために、ロード・バランシング・サービスには、コンピュート・インスタンスのIPアドレスおよび関連するアプリケーション・ポートが必要です。バックエンド・サーバーがロード・バランサと同じVCN内に存在する場合、Oracleでは、コンピュート・インスタンスのプライベートIPアドレスを指定することをお薦めします。プライベートIPアドレスは、ローカル・ピアリング・ゲートウェイがロード・バランサのVCNとバックエンド・サーバーのVCNの間のトラフィックを有効にした場合にも機能します。バックエンド・サーバーとロード・バランサがピアリング接続なしで異なるVCNに存在する場合は、コンピュート・インスタンスのパブリックIPアドレスを指定する必要があります。また、VCNセキュリティ・ルールで外部トラフィックが許可されていることを確認します。

バックエンド・トラフィックを有効にするには、バックエンド・サーバーのサブネットに適切なイングレスおよびエグレス・セキュリティ・ルールが必要です。バックエンド・サーバーをバックエンド・セットに追加する際に、適用可能なネットワーク・セキュリティ・グループ(NSG)を指定できます。 VCNにセキュリティ・リストを使用する場合は、ネットワーキング・サービスを使用して構成できます。

ノート:

大量のトラフィックに対応するために、Oracleでは、ロード・バランサ・サブネットに「ステートレス」セキュリティ・ルールを使用することを強くお薦めします。「仮想ネットワークの概要」の章の「仮想ファイアウォール」を参照してください。

ロード・バランサのヘルス・チェック

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

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

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

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

たとえば:

バックエンドHTTPサービスはヘルス・チェックURLと通信するときに問題があり、ヘルス・チェックURLは5つのnnメッセージを返します。 HTTPヘルス・チェックは、ヘルス・チェックURLからメッセージを捕捉し、サービスを停止としてマークします。この場合、HTTPサービスが使用不可であっても、TCPヘルス・チェックのハンドシェイクは成功し、サービスは正常としてマークされます。
バックエンドHTTPサービスは、認可の問題または構成済コンテンツがないため、4つのnnメッセージで応答します。 TCPヘルス・チェックでは、これらのエラーは捕捉されません。

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

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

ロード・バランサのヘルス問題の解釈

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

ヘルス・チェックの構成が正しくありません

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

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

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

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

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

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

ノート:

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

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

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

ロード・バランサのヘルス・チェックの構成ミスの一般的な副作用

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

不正なポート

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

エラー・メッセージ: errno:EHOSTUNREACH, syscall:connect。

間違ったパス

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

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

レスポンスで構成されたステータス・コードを受け取ります: "msg":"invalid statusCode","statusCode":404,"expected":"200"。

不正なプロトコル

このシナリオでは、すべてのバックエンド・サーバーが異常として報告されます。バックエンド・サーバーに問題がないことを確認した場合、プロトコルの設定が間違っている可能性があります。ヘルス・チェック・プロトコルは、バックエンドがリスニングするように構成されているプロトコルと一致する必要があります。次に例を示します: TCPおよびHTTPのヘルス・チェックのみがサポートされています。バックエンドでHTTPSを使用している場合は、プロトコルとしてTCPを使用する必要があります。

エラー・メッセージ: code:EPROTO, errno:EPROTO。

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

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

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

不正な正規表現パターン

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

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

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

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

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