レイヤー 7 コンテンツスイッチングの設定

NetScaler Application Delivery Management (ADM) は、OpenStack と連携して、NetScaler インスタンス上でレイヤー 7 (L7) スイッチングまたはコンテンツベースのスイッチング機能を構成します。コンテンツスイッチングは、特定の種類の要求を特定のサーバーに転送できる点で、単純なロードバランシングとは異なります。NetScaler インスタンスをプロバイダーとして OpenStack で L7 構成が作成されると、NetScaler ADM は NetScaler インスタンスを割り当て、L7 構成に対応するコンテンツスイッチングおよびレスポンダー構成を展開します。NetScaler インスタンスは、要求のアプリケーション層の特性に基づいて、ユーザー要求を分散およびロードバランスできます。

OpenStack のレイヤー 7 (L7) ロードバランシング機能は、ロードバランシングとコンテンツスイッチングを組み合わせて、特定の種類のコンテンツの最適化された配信を提供します。これにより、コンテンツに適用可能なポリシーのみを実行することで、ロードバランサーのパフォーマンスが向上します。レイヤー 7 ロードバランシングは、アプリケーションインフラストラクチャの効率向上も促進します。タイプ、URI、またはデータに基づいてコンテンツを分離する機能により、アプリケーションインフラストラクチャにおける物理リソースの割り当てが改善されます。たとえば、http://example-sports.com/about-us を閲覧するエンドユーザーには、会社とサービスに関するコンテンツをホストするサーバープールがサービスを提供し、http://example-sports.com/shopping-cart-football を閲覧するユーザーには、オンライン購入を可能にする別のサーバープールがサービスを提供します。

L7 スイッチングでは、ロードバランサーは、ユーザーからの HTTP 要求を受け入れ、それらの要求をアプリケーションサーバーに分散するコンテンツスイッチング仮想サーバーとして実装されます。L7 スイッチングまたはコンテンツスイッチングにより、さまざまなバックエンドサービス (たとえば、Web アプリケーション、Web サービスポータル、Web メールだけでなく、モバイル管理、異なる言語のコンテンツなど) にアクセスするための単一のエントリポイントを持つことができます。つまり、ユーザーに提供するすべてのサービスに対して 1 つのパブリック IP アドレスを提供できます。

下位レベルのロードバランシングとは異なり、レイヤー 7 スイッチングでは、プール内のすべてのサーバーが同じコンテンツを持つ必要はありません。L7 スイッチングを使用するロードバランサー構成では、異なるプールからのアプリケーションサーバーまたはバックエンドサーバーが異なるコンテンツを持つことを想定しています。L7 スイッチは、URI、ホスト、HTTP ヘッダー、またはアプリケーションメッセージ内のその他の要素に基づいて要求を転送できます。アプリケーションサーバーは、本質的に特定の種類のコンテンツを提供します。たとえば、あるサーバーは画像のみを提供し、別のサーバーは PHP や ASP などのサーバーサイドスクリプト言語を実行し、さらに別のサーバーは HTML、CSS、JavaScript などの静的コンテンツを提供できます。

L7 ルール

トラフィックを評価するためのルールには、次の属性が定義されており、ルールで定義された値と比較されます。

• ホスト名: HTTP 要求のホスト名は、ルール内の値パラメーターと比較されます。例: “www.example-sports.com”
• パス: HTTP URI のパス部分は、ルール内の値パラメーターと比較されます。例: “www.example-sports.com/shopping-cart/football_pump.html”
• ファイルタイプ: URI の最後の部分は、ルール内の値パラメーターと比較されます。例: txt、html、jpg、PNG、xls など
• ヘッダー: キーパラメーターで定義されたヘッダーは、ルール内の値パラメーターと比較されます
• クッキー: キーパラメーターで指定されたクッキーは、ルール内の値パラメーターと比較されます。クッキー要求ヘッダーフィールド値には、その URL に保存されている情報の名と値のペアが含まれます。一般的な構文は次のとおりです - Cookie: name=value。たとえば、”football-“ で始まる値を持つ “stores” という名前のクッキーを探すルールは、次のようになります: type = Cookie, compare_type=StartsWith, key = stores value = football-

比較タイプ

トラフィックを評価する際、L7 ポリシーはルールで定義された属性に対して次の式を比較します。

• regex: Perl タイプの正規表現マッチング
• starts_with: 文字列の先頭が一致
• ends_with: 文字列の末尾が一致
• contains: 文字列が含まれる
• equal_to: 文字列が等しい

注

ホスト名、パス、ヘッダー、およびクッキー属性はすべての比較タイプをサポートしますが、file_type 属性は regex と equal_to のみをサポートします

L7 ポリシー

L7 ポリシーは、受信 HTTP トラフィックを処理し、ポリシーで定義されたすべてのルールが一致した場合に「true」値を返します。

任意の L7 ポリシーでは、すべてのルールが論理 AND 演算子で結合されます。ポリシーが「true」値を返すには、要求がすべてのルールに一致する必要があります。ロードバランサーが実行するアクションは、ポリシーによって返される値に基づいています。ルール間の論理 OR 演算を実現するために、同じアクションを持つ 2 番目のポリシーを作成できます。

たとえば、受信 HTTP 要求に「EXAMPLE-SPORTS」、「SPORTS-FOOTBALL」、または「EXAMPLE-FOOTBALL」という単語が含まれるポリシーを作成し、ロードバランサーがこれらの要求を Example-sports eコマース会社のサーバープールに転送して、要求されたコンテンツを提供するという適切なアクションを実行するようにできます。同じアクションを実行するが、「example-sports」、「example-sports-football」、または「example-football」に一致する別のポリシーを作成できます。ユーザーがこれらの 6 つのキーワードのいずれかを含む HTTP 要求を送信すると、ロードバランサーは要求を Example-Sports サーバーに転送します。

ポリシーで定義されたルールに応じて、L7 ポリシーは次のいずれかのアクションを実行できます。

• プールへのリダイレクト - L7 ポリシーに関連付けられたルールによって識別されるアプリケーションサーバープールに要求を転送します。つまり、ドメイン名に基づいて特定のロードバランサープールに要求を転送するアプリケーションルールを作成できます。たとえば、example-football.com への一部の要求を pool_1 に、example-sports-online_purchase.com への他の要求を pool_2 に転送するルールを作成できます
• URL へのリダイレクト - クライアントにリダイレクト HTTP 応答を送信します。この応答のロケーション応答ヘッダーには新しいロケーションが含まれます。ブラウザーはアドレスバーを新しいロケーションで更新し、新しい要求を発行します。ユースケースは多数あります。たとえば、Web サイトのアドレスが変更された場合、要求を破棄する代わりに新しいアドレスにリダイレクトできます。または、Web サイトのメンテナンス中に、ユーザーを読み取り専用サイトにリダイレクトできます
• 拒否 - 要求を拒否し、それ以上のアクションを実行しません。たとえば、制限された Web ページへのユーザーのアクセスを拒否するために、401 Unauthorized 応答を返すことができます

コンテンツスイッチング構成は、コンテンツスイッチング仮想サーバー、ロードバランシング仮想サーバーとサービスからなるロードバランシング設定、およびコンテンツスイッチングポリシーで構成されます。コンテンツスイッチング仮想サーバーとポリシーを作成した後、各ポリシーをコンテンツスイッチング仮想サーバーにバインドします。ポリシーをコンテンツスイッチング仮想サーバーにバインドする際、ターゲットのロードバランシング仮想サーバーを指定します。要求がコンテンツスイッチング仮想サーバーに到達すると、仮想サーバーは関連付けられたコンテンツスイッチングポリシーをその要求に適用します。ポリシーの優先度は、コンテンツスイッチング仮想サーバーにバインドされたポリシーが評価される順序を定義します。

リスナー ID を持つ任意のプールは、トラフィックが転送される仮想サーバーのデフォルトプールとして割り当てることができます。プールはリスナーと緩やかにバインドされており、L7 ポリシーの実装を通じてのみリスナーと関連付けられます。プールは、リスナーに必ずしも関連付けられていなくても、ロードバランサーの直下に作成することもできます。そのような場合、プールは「pending_create」状態として作成されます。L7 ポリシーはリスナーと密接にバインドされているため、プールが「アクティブ」になりトラフィック要求の受信を開始するには、プール ID を含む L7 ポリシーを作成して実装する必要があります。

プールは複数の L7 ポリシーによってサービスを提供できますが、少なくとも 1 つのポリシーがアタッチされている場合は「アクティブ」状態を維持します。最後のポリシーが削除されると、別のポリシーが作成されて関連付けられるまで、プールは「pending_create」状態に戻ります。プール自体が削除された場合、それ以外であれば受信していたすべての HTTP 要求はデフォルトプールにリダイレクトされます。

OpenStack L7 ポリシーと NetScaler エンティティ間のマッピング

「true」と評価される L7 ポリシーのアクションが「create_pending」状態のプールにトラフィックをリダイレクトする場合、NetScaler ADM は指定されたプールをロードバランシング仮想サーバーとともに実装します。NetScaler ADM は、L7 ポリシーからコンテンツスイッチングポリシーを作成し、対応するコンテンツスイッチングアクションを使用して、要求をそのプールに関連付けられたロードバランシング仮想サーバーにリダイレクトします。2 番目の L7 ポリシーが同じプールにリダイレクトする場合、NetScaler ADM はコンテンツスイッチングポリシーとコンテンツスイッチングアクションを作成し、トラフィックをプールに関連付けられた既存のロードバランシング仮想サーバーにリダイレクトします。

ポリシーの配置

OpenStack における L7 ポリシーの評価は、その優先度によって決定されます。OpenStack では、デフォルトで、ポリシーは作成された順序で優先度が割り当てられます。最初に作成されたポリシーには「1」が割り当てられ、その後作成されたポリシーには連続して番号が割り当てられます。しかし、ポリシーの優先度を変更し、異なる優先度を割り当てることができます。ポリシーは常に優先度の順序で評価されます。特定の要求に一致する最初のポリシーが常に最初に実行されます。

ポリシーを作成する際は、次の点に注意してください。

• 新しいポリシーに既存のポリシーと同じ優先度を割り当てると、新しいポリシーがその優先度を取得します。既存のポリシーの優先度は下がります。必要に応じて、ポリシーが評価される順序を維持するために、他のポリシーの優先度も下がります
• 位置を指定せずに新しいポリシーを作成すると、新しいポリシーはリストの末尾に追加されます
• 新しいポリシーを作成し、リストに既に存在するポリシーの数よりも大きい位置を割り当てると、新しいポリシーはリストの末尾に追加されます。つまり、新しいポリシーは常に次に利用可能な優先度を取得します。たとえば、優先度 1、2、3 の 3 つのポリシー A、B、C があり、ポリシーを作成して優先度 8 を割り当てると、新しいポリシーの優先度は 4 になります
• リストにポリシーを追加したり、リストからポリシーを削除したりすると、ポリシーの位置の値は番号をスキップせずに 1 から再順序付けされます。たとえば、ポリシー A、B、C、D が位置値 1、2、3、4 を持ち、リストからポリシー B を削除すると、ポリシー C が 2 番目の位置を占め、ポリシー D が 3 番目の位置を占めます

NetScaler ADM では、常に優先度 1 の csvserver に関連付けられたデフォルトポリシーが存在します。このデフォルトポリシーは、lbvserver が任意の時点で処理する TCP 接続の数を指定します。したがって、NetScaler で対応するレスポンダーポリシーとコンテンツスイッチングポリシーが作成される場合、それらには常に、対応する L7 ポリシーの優先度よりも 1 大きい優先度が割り当てられます。たとえば、優先度 1 の L7 ポリシーが評価され、優先度 2 のコンテンツスイッチングポリシーが作成される場合です。同様に、優先度 2 の L7 ポリシーが評価され、優先度 3 のレスポンダーポリシーが作成される場合です。

OpenStack では、「reject」または「redirect_to_url」ポリシーが最初に評価され、次に「redirect_to_pool」ポリシーが評価されます。NetScaler インスタンスでは、レスポンダーポリシーは常に最初に評価され、要求を破棄するか、ユーザーにリダイレクトされた Web アドレスを提示し、コンテンツスイッチングポリシーは最後に評価されます。この評価順序は、コンテンツスイッチングポリシーとレスポンダーポリシーが相互に排他的である場合、通常は競合を引き起こしません。つまり、2 つの L7 ポリシーが同一の式を持つべきではありません。このような競合を避けるために、導出された式がレスポンダーおよびコンテンツスイッチングポリシーに追加されます。たとえば、「sports-football.com」へのすべての要求を拒否する式と、「example-sports-football.com」への要求を許可する別の式を作成します。要求を拒否するすべてのレスポンダーポリシーが評価リストの最上位に配置され、その後に Web ダイレクト用のレスポンダーポリシー、その後にコンテンツスイッチングポリシーが続くように L7 ポリシーを作成します。

NetScaler ADM では、常に優先度 1 の csvserver に関連付けられたデフォルトポリシーが存在します。このデフォルトポリシーは、lbvserver が任意の時点で処理する TCP 接続の数を指定します。したがって、NetScaler で対応するレスポンダーポリシーとコンテンツスイッチングポリシーが作成される場合、それらには常に、対応する L7 ポリシーの優先度よりも 1 大きい優先度が割り当てられます。たとえば、優先度 1 の L7 ポリシーが評価され、優先度 2 のコンテンツスイッチングポリシーが作成される場合です。同様に、優先度 2 の L7 ポリシーが評価され、優先度 3 のレスポンダーポリシーが作成される場合です。

OpenStack では、「reject」または「redirect_to_url」ポリシーが最初に評価され、次に「redirect_to_pool」ポリシーが評価されます。NetScaler では、レスポンダーポリシーは常に最初に評価され、要求を破棄するか、ユーザーにリダイレクトされた Web アドレスを提示し、コンテンツスイッチングポリシーは最後に評価されます。この評価順序は、コンテンツスイッチングポリシーとレスポンダーポリシーが相互に排他的である場合、通常は競合を引き起こしません。つまり、2 つの L7 ポリシーが類似の式を持つことはありません。このような競合を避けるために、類似の導出された式がレスポンダーおよびコンテンツスイッチングポリシーに追加されます。たとえば、「sports-football.com」へのすべての要求を拒否する式と、「example-sports-football.com」への要求を許可する別の式を作成します。要求を拒否するすべてのレスポンダーポリシーが評価リストの最上位に配置され、その後に Web ダイレクト用のレスポンダーポリシー、その後にコンテンツスイッチングポリシーが続くように L7 ポリシーを作成します。

構成タスク

L7 ポリシーとアクションの実装は、Neutron LBaaS コマンドを通じて実行されます。

OpenStack で環境変数を設定し、ロードバランサー (例: LB1) を作成します。ロードバランサーが正常に作成された後、リスナーとプール (例: L1、P1、P2) を作成し、プールにメンバーとモニターを追加します。たとえば、P1 は L1 のデフォルトプールであり、P2 は LB1 に関連付けられ、アプリケーションサーバーを管理するプールです。

コマンドラインを使用して LBaaS V2 を構成する方法の詳細については、「コマンドラインを使用した LBaaS V2 の構成」を参照してください。

次のコマンドは、ポリシーを作成し、特定のアクションを定義します。

要求を破棄する L7 ポリシーの作成

neutron lbaas-l7policy-create --name <L7 policy name> --listener <listener name> --action<action-name>

例:

neutron lbaas-l7policy-create –name policy11 –action REJECT –listener L1

上記のコマンドは、要求を拒否するために、レスポンダーポリシーである policy11 を作成し、コンテンツスイッチングサーバーにバインドします。このポリシーに対してルールが作成されていないため、ポリシーは「false」と評価され、要求は拒否されます。

特定の URL に要求をリダイレクトする L7 ポリシーの作成

neutron lbaas-l7policy-create --name <L7 policy name> --listener <listener name> --action <action-name> --redirect-url <redirect-url>

例:

neutron lbaas-l7policy-create –name policy12 –action REDIRECT_TO_URL –listener admin-list1 –redirect-url http://example-sports/about-us.html

上記のコマンドは、要求を URL にリダイレクトするレスポンダーアクションを作成し、アクションを持つレスポンダーポリシーを作成し、このポリシーをコンテンツスイッチング仮想サーバーにバインドします。

neutron lbaas-l7rule-create --type HOST_NAME --compare-type CONTAINS --value <value-string> <L7 policy name>

neutron lbaas-l7rule-create --type PATH --compare-type CONTAINS --value <value-string> <L7 policy name>

上記の 2 つのルールは、AND 演算子で接続して、レスポンダーポリシーの式を導出できます。

要求をプールにリダイレクトする L7 ポリシーの作成

neutron lbaas-l7policy-create --name <L7 policy name> --listener <listener name> --action <action-name> --redirect-pool <redirect-pool>

例:

neutron lbaas-l7policy-create –name policy13 –action REDIRECT_TO_POOL –listener admin-list1 –redirect-pool admin-pool2

これが最初の L7 ポリシーである場合、上記のコマンドは P2 を LB1 とともに実装し、コンテンツスイッチングリダイレクトアクションを作成し、要求を LB1 にリダイレクトします。P2 が既に存在する場合、コマンドはコンテンツスイッチングリダイレクトアクションを作成し、要求を LB1 にリダイレクトします。