GSLB アプリケーションのクライアントからの長期的なトランザクションは、トランザクションが開始されたサイトに存続するように構成できます。この機能は、NSX Advanced Load Balancer SE によって作成された HTTP サイトの Cookie を使用して実装されます。

概要

一部のアプリケーションでは、クライアントとサーバの間に粘着性が必要です。つまり、クライアントからの長期トランザクションのすべての要求は、同じサーバに送信する必要があります。そうしないと、アプリケーション セッションが中断され、クライアントに悪影響が及ぶ可能性があります。これは、構成された GSLB アルゴリズムよりも優先される GSLB サイトの Cookie パーシステンスをオンにすることで実現されます。

アクティブ/アクティブの GSLB 展開では、サイト パーシステンスが非常に重要です。通常、アクティブ/スタンバイ環境では、サイト パーシステンスは問題ではありません。

制限

NSX Advanced Load Balancer は、以下の条件を確認し、違反が行われようとした場合は適切なエラー メッセージが表示されます。これらの制限の必要性は、このセクション全体を読んだ後でよりよく理解できます。

  • サイト パーシステンスは NSX Advanced Load Balancer VIP にのみ適用されます。NSX Advanced Load Balancer 以外(サードパーティ)の VIP は参加できません。

  • 同じ Controller クラスタ内の複数の仮想サービスにまたがるサイト パーシステンスはサポートされていません。

  • グローバル アプリケーションのサイト パーシステンスをオンにするには、そのアプリケーションの個々のメンバー全員がアクティブなサイトで動作している必要があります。逆に、サイト パーシステント GSLB サービスに参加している NSX Advanced Load Balancer グローバル サービス (GS) メンバーがサイトで実行されている場合、そのサイトはアクティブからパッシブに移行できません。

  • サイト パーシステンスが機能するには、NSX Advanced Load Balancer GS メンバーがすべての GSLB サービスで一意である必要があります。つまり、複数の GSLB サービスの GSLB プール メンバーになることはできません。

  • サイト パーシステンス プールは、コントローラによって作成され、サイト パーシステンスがオンになっているときに GSLB 仮想サービス メンバーに関連付けられた内部プール構造です。ユーザーは、この関連付けを実行または変更することはできません。サイト パーシステンス プールに対して、NSX Advanced Load Balancer のプール グループ機能を構成することはできません。

  • is_federated オプションが必要な PKI プロファイルに追加され、すべての GSLB メンバー間で複製できるようになります。定義できる is_federated PKI プロファイルは 1 つだけです。1 つだけなので、フェデレーション PKI プロファイルを GSLB サービスに明示的に関連付ける必要はありません。

  • フェデレーション PKI およびアプリケーション パーシステンス プロファイルを次のようにすることはできません。

    • 非フェデレーション プロファイルに関連付ける。

    • GSLB がオンになっていない場合に作成する。

Cookie ベースのサイト パーシステンスの仕組み

図 1 は、長期的なトランザクションのライフサイクルのフェーズ 1 を示しています。

  1. クライアントは、DNS リゾルバに x.foo.com を解決するように要求します。

  2. 企業 DNS は、2 つの権限を持つ DNS(Site1 と Site2)を決定し、DNS リゾルバに Site1 DNS を試すことを推奨します。

  3. Site1 の DNS は DNS リゾルバのクエリを受け取り、有効なグローバル ロード バランシング アルゴリズムを使用します。また、Site1 の VS1 を DNS リゾルバに推奨し、TTL を設定します。

  4. その後、DNS リゾルバは推奨事項と TTL をクライアントに渡します。

  5. VS1 を実装するグループの各 SE は、サイト パーシステンスがオンの状態を認識しています。クライアントの最初の要求にはサイトの Cookie が含まれていないため、SE はサイトの Cookie を作成して、それを返します。Cookie は AES-256 で暗号化され、cluster_uuid および vs_uuid 文字列に基づいています。Cookie の例を以下に示します。

Set-Cookie: FOO=1S509ceebd-0913-4aomuTiRccdU0ujbfY6eCVkL9muOBwIsnT5fhrMTMMM4-fapeQ2SEGb3ny69-iJQYG6Xg6SmLq9x7crxFEZbZVsCNDYdqXSwx5GIiuEJqlXFbehC2obJUDbYBciac; path=/

グループ内の SE にこの Cookie が表示されている間は、両端の青い矢印で示される双方向ダイアログが続きます。

図 1. 1. GSLB Cookie ベースのサイト パーシステンスのフェーズ 1

図 2 は、TTL の有効期限が切れた後で何が起こるかを示しています。

  1. その有効期限が切れると、クライアントは DNS リゾルバに再び x.foo.com の IP アドレスを提供するように要求します。

  2. DNS リゾルバは、企業 DNS に対して、権限を持つ DNS を提供する要求を再度行います。キャッシュから、企業 DNS は Site2 の DNS を推奨します。

  3. クライアントは Site2 DNS にクエリを実行し、VS2 のローカル IP アドレスである VIP2 を提供します。

図 2. 2. GSLB Cookie ベースのサイト パーシステンスのフェーズ 2

図 3 は、Site2 で VS2 とのダイアログを開始するクライアントを示しています。知らないうちに、以前に取得した Cookie がその要求に付随します。

  1. Site2 の SE は、サイト Cookie とともに要求を受信します。Cookie を復号化し、この要求がそのサイトで開始されなかった会話の継続であることを即座に認識します。代わりに、会話は Site1 の VS1 にプロキシされる必要があります。

  2. VS1 に要求をプロキシする場合、VS2 は要求を VS1 に渡し、リターン アドレスを自身に設定します。

  3. SE は、Site1 の VS1 から提供されたコンテンツを使用してクライアントに応答します。

図 3. 3. GSLB Cookie ベースのサイト パーシステンスのフェーズ 3