プールグループ

プールグループはサーバプールのリストで、リストからサーバプールを選択するロジックを伴います。仮想サービスは、サーバプールを（直接、またはルール、DataScript、またはサービスポートプールセレクタを介して）参照できる場合は、常に代わりにプールグループを参照できます。

注：

プールの選択は、しばしばプールの切り替えと呼ばれます。

プールグループは、次の実装に使用できる強力な構造です。

優先プール/サーバ
バックアッププール
A/B プール
ブルー/グリーン展開
カナリアアップグレード

注：

この機能は IPv6 ではサポートされていません。

プールグループについて

プールグループは、メンバー（サーバ）プールのリストであり、リストからメンバーを選択するためのロジックと組み合わされます。PoolGroup オブジェクトは、各タプルが 1 つのメンバーを記述する 3 タプル { 優先順位, プール, 比率 } のリストとして表されます。たとえば、次に示すプールグループを定義するには、9 つの 3 タプルを持つ PoolGroup オブジェクトが必要です。

プールグループの仕組み

上記の図を使用して一般的なシナリオについて説明するために、図 1 を使用してみましょう。

仮想サービスを担当するサービスエンジンが、特定のクライアント要求の送信先のサーバを特定する必要がある場合は、次の手順を実行します。

[手順 1：グループ内の最適なプールを特定します]。これは、プールの優先順位によって管理されます。この 9 つのメンバーで構成されるグループでは、high_pri、med_pri、low_pri の 3 つの優先順位が定義されていますが、すべてに最も高い優先順位が割り当てられている pool1、pool2、pool3 の 3 つの優先順位が優先されます（最善です）。NSX Advanced Load Balancer は、そのうちの 1 つを選択するために実行できるすべての操作を実行します。
[手順 2：優先順位が最も高いプールのいずれかを特定します]。この選択は、3 つのプールメンバー（weight_1、weight_2、weight_3）に割り当てられた重みによって管理されます。これらの重みによって示される比率は、それぞれに送信されるトラフィックの割合を決定します。
[手順 3：選択したプールを持つサーバを 1 台特定します]。9 つのメンバーはそれぞれ異なるロードバランシングアルゴリズムを使用して構成できます。選択したプールに関連付けられているアルゴリズムは、どのサーバが選択されるかを制御します。

パーシステンスの効果

上記では、パーシステンスの影響がない場合に、最初とその後にクライアント要求に適用されるアルゴリズムについて説明しました。ただし、パーシステンスが構成されている場合、パーシステンスには特定のクライアントからの 2 番目から n 番目の要求に対するオーバーライド効果があり、プール単位で設定できます。

プールでパーシステンスを有効にするには、[アプリケーション] > [プール] > [プールの編集] > [設定] の順に移動し、表示される [パーシステンス] ドロップダウンメニューからパーシステンスを選択します。

プールとプールグループ

プールとプールグループは、仮想サービスでは同じ意味で使用できます。今後の使用事例に対処する必要がある場合は、プールグループを使用します。既存のトラフィックを中断することなく、柔軟性のメリットを得ることができます。プールグループメンバーシップを変更しても、トラフィックの中断はありません。プールメンバーがプールグループから削除された場合でも、既存のプールメンバー内のサーバへの接続は完了します。同様に、プールグループは動的に拡張できます。

プールグループの機能が予測されない場合は、プールを使用します。ジョブを実行する単純なプールは、プールグループよりも効率的です。追加の完全な UUID オブジェクトの構成を回避することで、SE とコントローラのメモリ消費量が少なくなります。

注：

プールグループのメンバーとなる資格のあるプールのリストでは、他の仮想サーバに関連付けられているプールが除外されます。

構成

2 つのプールで構成されるプールグループを考慮した場合、機能を構成するには次の手順を実行します。

プールの作成

プールグループに接続する個別のプールを作成するには、[アプリケーション] > [プール] > [プールの作成] の順に移動します。プール pool-1、pool-2、および cart2 がここで作成されました。

プール設定を構成する方法の詳細については、「サーバプール」を参照してください。

プールグループの作成

[アプリケーション] > [プールグループ] > [プールグループの作成] の順に移動します。
[プールグループメンバー] セクションで、以前に作成したプールをメンバープールとして追加するか、新しいメンバープールを作成します。ここでは、各プールに優先順位が割り当てられていることに注意してください。
[+ プールグループメンバーの追加] をクリックします。
1. [プール] ドロップダウンメニューからプールを選択/作成します。
2. 1 ～ 1000 の範囲で [比率] を入力します。
3. 優先順位の高いプールを選択します。
4. ドロップダウンメニューから [展開状態] を選択します。展開状態のオプションは次のとおりです。
  1. 評価失敗
  2. 評価の進行中です
  3. サービス提供中
  4. サービス停止中
[プールサーバ] セクションで、プールグループのオプション設定を指定します。
1. [HTTP2 の有効化]：仮想サービスから、このプールグループで構成されているすべてのプール内のすべてのバックエンドサーバへのトラフィックに対して HTTP/2 を有効にする場合に選択します。
  [サーバの最小数]：トラフィックを分散するサーバの最小数。1 ～ 65535 の範囲で入力できます。
[プールグループ障害の設定] セクションで、プールグループに障害が発生したときに実行するアクションを指定します。失敗アクションとして使用できるオプションは 3 つあります。
1. [接続の終了]：プール内のすべてのサーバが停止した場合、仮想サービスはデフォルトで、TCP リセットを発行するか UDP パケットをドロップして新しいクライアント接続の試行を終了します。サーバが「停止」とマークされていても、既存の接続は終了しません。サーバが低速でも、既存のクライアント接続を引き続き処理できることが前提になっています。
2. [HTTP ローカル応答]：単純な Web ページを返します。状態コードとして 200 または 503 を指定します。カスタム HTML ファイルが NSX Advanced Load Balancer にアップロードされていない場合は、エラーコードが表示された基本ページが返されます。
  1. [状態コード]：ドロップダウンメニューから [200] または [503] を選択します。
3. [HTTP リダイレクト]：指定された URL を含むリダイレクト HTTP 応答コードを返します。
  1. [状態コード]：ドロップダウンメニューから 301、302、または 307 を選択します。
  2. [HTTP/HTTPS]：デフォルトでは、HTTP をクリックしない限り、NSX Advanced Load Balancer は HTTPS を使用してリダイレクトされます。
  3. [URL]：domain.com/path/file?query=bbb 形式の URL を入力します。
    
    注：
    デフォルトでは [接続の終了] が選択されています。
[プールグループの展開ポリシー] を選択/作成します。自動スケールマネージャは、[プールグループの展開ポリシー] で定義されている展開目標が達成されると、新しいプールを本番環境に自動的に昇格させます。
[ロールベースのアクセスコントロール (RBAC)] セクションで、[追加] をクリックします。
1. [キー] および対応する [値] を入力します。
  ラベルの構成の詳細については、「アプリケーションごとのきめ細かいロールベースのアクセスコントロール」を参照してください。

プールグループの仮想サービスへの接続

仮想サービスを（[詳細] モードで）作成し、次の手順を実行して、プールグループを含めるようにプール設定を構成します。
[アプリケーション] > [仮想サービスの作成] > [詳細設定] > [新しい仮想サービス] の順に移動します。
1. [手順 1：設定] タブで、[プールグループ] ラジオボタンを選択して、以前に作成したプールグループを仮想サービスに接続します。
2. 次に示すように、プールグループが接続され、仮想サービスがアクティブになります。
仮想サービスおよびプールグループの全体的な設定を表示するには、[アプリケーション] > [ダッシュボード] の順に移動し、[VS リストの表示] ドロップダウンメニューから [VS ツリー] を選択します。

注：

キャッシュはプールグループではサポートされていません。

使用事例

優先プール/サーバ

プールに異なる種類のサーバ（新しい非常に強力なサーバ、古い低速なサーバ、非常に古いサーバ、非常に低速なサーバ）がある場合について考えてみましょう。図では、青いプールが新しい強力なサーバで構成され、緑色のプールには古い低速なサーバ、ピンクのプールには最も古いサーバがあるとします。さらに、high_pri から low_pri までの優先順位が割り当てられていることに注意してください。この配置により、NSX Advanced Load Balancer は、可能な限り、基本的には常に 3 つの青いプール内の新しいサーバを選択します。最も優先順位の高いプールのサーバが見つからない場合にのみ、NSX Advanced Load Balancer は速度の遅いメンバーにも、優先順位に従って一部のトラフィックを送信します。

1 つまたは複数の状況の組み合わせによって、このような代わりの選択が（優先順位の低いプールから）トリガされます。

実行中のサーバが見つからない。
#1 と同様に、指定された優先順位レベルのサーバが追加の接続を受け入れない。すべての候補が飽和状態になっている。
指定された優先順位レベルのどのプールも、構成された最小数のサーバを実行していない。

運用上の注意事項

優先順位の間隔を確保し、ギャップを残しておくことをお勧めします。これにより、後で新しい優先順位の追加が容易になります。
純粋な優先順位の使用事例では、プールグループの比率はオプションです。
プールの比率を 0 に設定すると、このプールにトラフィックが送信されません。
プールごとに、通常のロードバランシングが実行されます。NSX Advanced Load Balancer が新しいセッションのプールを選択すると、そのプール用に構成されたロードバランシング方法を使用してサーバが選択されます。

優先順位プールのサンプル構成

優先順位が異なるプールが 3 つしかない場合、[比率] 列の値はプールの選択に含まれません。上記の 3 つの状況がなければ、cart2 が常に選択されます。

バックアッププール

バックアッププールの既存の実装については、「プールグループ」セクションで説明します。プールの停止/失敗アクションとしてバックアッププールを指定する既存のオプションは廃止されました。代わりに、優先順位の異なる 2 つ以上のプールを持つプールグループを構成します。サーバが使用可能である限り、最も優先度の高いプールが選択されます（前述の 3 つの状況に合わせて）。

運用上の注意事項

優先順位の値が高いプールの方がより良好とみなされ、このプールが稼動中でサーバの最小数の条件が満たされている限り、トラフィックは最も優先度の高いプールに送信されます。
優先順位の間隔を確保し、ギャップを残しておくことをお勧めします。これにより、後で新しい優先順位の追加が容易になります。
各プールメンバーごとに、通常のロードバランシングが実行されます。NSX Advanced Load Balancer が新しいセッションのプールを選択すると、そのプール用に構成されたロードバランシング方法を使用してサーバが選択されます。
バックアッププールの追加または削除は、プールグループ内の他のプール上の既存のセッションには影響しません。

バックアッププールのサンプル構成

プールグループ「backup」を作成します。このグループには、優先度 10 のプライマリプールと優先度 3 のバックアッププールの 2 つのメンバープールがあります。

オブジェクトの詳細：

{
     url: "https://10.10.25.20/api/poolgroup/poolgroup-f51f8a6b-6567-409d-9556-835b962c8092",
     uuid: "poolgroup-f51f8a6b-6567-409d-9556-835b962c8092",
     name: "backup",
     tenant_ref: "https://10.10.25.20/api/tenant/admin",
     cloud_ref: "https://10.10.25.20/api/cloud/cloud-3957c1e2-7168-4214-bbc4-dd7c1652d04b",
     _last_modified: "1478327684238067",
     min_servers: 0,
     members:
    [
        {
            ratio: 1,
            pool_ref: "https://10.10.25.20/api/pool/pool-4fc19448-90a2-4d58-bb8f-d54bdf4c3b0a",
            priority_label: "10"
        },
        {
            ratio: 1,
            pool_ref: "https://10.10.25.20/api/pool/pool-b77ba6e9-45a3-4e2b-96e7-6f43aafb4226",
            priority_label: "3"
        }
    ],
    fail_action:
    {
        type: "FAIL_ACTION_CLOSE_CONN"
    }
}

A/B プール

NSX Advanced Load Balancer は、同等のプールとみなされる一連のプールの仕様をサポートし、これらのプールに送信されるトラフィックの比率は定義されます。

たとえば、仮想サービスは、A と B の 2 つのプールを持つ単一の優先順位グループで構成できます。さらに、ユーザーは、A に送信されるトラフィックの比率を 4 に、B に送信されるトラフィックの比率を 1 に指定できます。

A/B プール機能は Blue/Green テストとも呼ばれ、仮想サービスのトラフィックをサーバのセット間で段階的に移行する簡単な方法を提供します。たとえば、仮想サービスのプライマリプール (A) で OS またはアプリケーションのメジャーアップグレードをテストするには、アップグレードされたバージョンを実行している 2 つ目のプール (B) をプライマリプールに追加できます。次に、構成に基づいて、クライアントとサーバ間のトラフィックの比率（0 ～ 100）が A プールではなく B プールに送信されます。

この例を続行するには、アップグレードが正常に実行されていれば、NSX Advanced Load Balancer ユーザーは B プールに送信されるトラフィックの比率を増やすことができます。同様に、アップグレードが失敗した場合や最適でない場合は、B プールに対する比率を簡単に減らして代替アップグレードをテストできます。

アップグレードに成功した後に新しいプールへの移行を完了するには、すべてのトラフィックをプールに送信するように比率を調整できます。これにより、プール B が本番プールになります。

次のアップグレードを実行するには、プロセスを逆に実行します。プール A をアップグレードした後、プール B に送信されるトラフィックの比率を減らしてプール A をテストすることができます。アップグレードを完了するために、プール B に対するトラフィックの比率を 0 に戻すことができます。

運用上の注意事項

プールの比率を 0 に設定すると、このプールにトラフィックが送信されません。
プールごとに、通常のロードバランシングが実行されます。NSX Advanced Load Balancer が新しいセッションのプールを選択すると、そのプール用に構成されたロードバランシング方法を使用してサーバが選択されます。
A/B 設定は、既存のセッションには影響しません。たとえば、B に送信される比率を 1 に設定し、A を 0 に設定しても、プール A の既存のセッションは B に移動しません。同様に、A/B プール設定はパーシステンス構成には影響しません。
比率がゼロ以外のプールの 1 つが停止すると、新しいトラフィックは残りのプールに均等に分散されます。
純粋な A/B の使用事例では、プールグループの優先順位はオプションです。
プールグループは、仮想サービスにデフォルトとして適用することも、ルール、DataScripts、サービスポートプールセレクタに接続することもできます。

A/B プールのサンプル構成

優先順位を指定せずにプールグループ「ab」を作成し、そのグループに 2 つのプール（a-pool と b-pool）を作成します。

この例では、a-pool と b-pool の比率を 10:1 に設定することで、トラフィックの 10% が b-pool に送信されます。
A/B 機能を使用する VS にこのプールグループを適用します。

オブジェクトの詳細：

{
    url: "https://

    
      /api/poolgroup/poolgroup-7517fbb0-6903-403e-844f-6f9e56a22633", uuid: "poolgroup-7517fbb0-6903-403e-844f-6f9e56a22633", name: "ab", tenant_ref: "https://
     
       /api/tenant/admin", cloud_ref: "https://
      
        /api/cloud/cloud-3957c1e2-7168-4214-bbc4-dd7c1652d04b", min_servers: 0, members: [ { ratio: 10, pool_ref: "https://
       
         /api/pool/pool-c27ef707-e736-4ab6-ab81-b6d844d74e12" }, { ratio: 1, pool_ref: "https://
        
          /api/pool/pool-23853ea8-aad8-4a7a-8e9b-99d5b749e75a" } ], }

その他の使用事例

Blue/Green 展開

これは、2 つの同一の本番環境を実行することでダウンタイムとリスクを低減するリリース技術です。本番環境のうちの 1 つ（ブルーなど）のみが常に稼動し、すべての本番トラフィックを処理します。新しいリリースの準備として、稼動していない環境（グリーンなど）で展開と最終段階のテストが行われます。Green の場合、受信するすべての要求は Blue ではなく Green になります。Green は現在ライブ状態で、Blue はアイドル状態です。アプリケーションの展開によるダウンタイムが解消されました。また、Green の新しいリリースで予期しない問題が発生した場合は、最後のバージョンにすぐにロールバックします。Blue に切り替えてください。

Canary のアップグレード

このアップグレード手法は、人間が影響を受ける前に有毒ガスを検出する炭鉱のカナリア (Canary) と似ていることから、そのように呼ばれています。これは、システムの更新または変更を実行する際に、最初に代表的なサーバのグループが更新され、しばらくの間モニタリング/テストされた後にのみ、残りのサーバ全体に変更をローリングするという考えに基づいています。

プール グループについて

プール グループの仕組み

パーシステンスの効果

プールとプール グループ

構成

プールの作成

プール グループの作成

プール グループの仮想サービスへの接続

使用事例

その他の使用事例

プールグループについて

プールグループの仕組み

プールとプールグループ

プールグループの作成

プールグループの仮想サービスへの接続