VMware Aria Automationクラウド テンプレートを作成または編集するときには、目的に最適なロード バランサ リソースを使用します。

クラウド テンプレートで NSXおよびクラウドに依存しないロード バランサ リソースを使用して、展開内のロード バランシングを制御できます。

クラウドに依存しないロード バランサは、複数のクラウドにまたがって展開できます。クラウド固有のロード バランサでは、特定のクラウドやトポロジでのみ使用できる高度な設定や機能を指定できます。クラウド固有のプロパティは、NSXロード バランサ (Cloud.NSX.LoadBalancer) リソース タイプで使用できます。これらのプロパティをクラウドに依存しないロード バランサ (Cloud.LoadBalancer) に追加すると、Amazon Web Services や Microsoft Azure などのロード バランサがプロビジョニングされている場合、プロパティは無視されますが、NSX ロード バランサがプロビジョニングされている場合は認識されます。VMware Aria Automationクラウド テンプレートの条件に基づいて、使用可能なロード バランサ リソース タイプから 1 つを選択します。

デザイン キャンバスでロード バランサ リソースをセキュリティ グループ リソースに直接接続することはできません。

クラウドに依存しないロード バランサ リソース

すべてのタイプのターゲット マシンにネットワーク特性を指定する場合は、クラウドに依存しないロード バランサを使用します。

クラウドに依存しないロード バランサを追加するには、クラウド テンプレートのデザイン画面で [クラウドに依存しない] > [ロード バランサ] リソースを使用します。リソースは、クラウド テンプレート コードでは Cloud.LoadBalancer リソース タイプとして表示されます。デフォルトのリソースは、次のように表示されます。 
Cloud_LoadBalancer_1:
    type: Cloud.LoadBalancer
    properties:
      routes: []
      network: ''
      instances: []
      internetFacing: false

NSXロード バランサ リソース

クラウド テンプレートに NSX 固有の特性（ポリシー API メソッドまたは Manager API メソッド）が含まれている場合は、NSX ロード バランサを使用します。1 つ以上のロード バランサを NSX ネットワークに、あるいは NSX ネットワークに関連付けられたマシンに接続できます。

NSX ロード バランサを追加するには、 [NSX] > [ロード バランサ] リソースを使用します。リソースは、クラウド テンプレート コードでは Cloud.NSX.LoadBalancerリソース タイプとして表示されます。デフォルトのリソースは、次のように表示されます。 
Cloud_NSX_LoadBalancer_1:
    type: Cloud.NSX.LoadBalancer
    properties:
      routes: []
      network: ''
      instances: []

クラウド テンプレート コードのロード バランサ オプション

1 つ以上のロード バランサ リソースをクラウド テンプレートに追加すると、次の設定を指定できるようになります。Automation Assembler のネットワーク、セキュリティ グループ、およびロード バランサ リソースの例にいくつかの例を示します。

HTTP プロトコルは、すべてのオンデマンド ロード バランサでサポートされます。

HTTPS プロトコルは、NSX モードが [ポリシー] に設定されているNSX Cloud アカウントに関連付けられたオンデマンド ロード バランサでのみサポートされます。NSX モードが [マネージャ] に設定されている NSX Cloud アカウントは HTTPS プロトコルを使用できません。

  • マシンの仕様

    名前付きマシン リソースを指定して、ロード バランサ プールに参加させることができます。または、特定のマシン NIC をロード バランサ プールに参加させるように指定することもできます。

    このオプションは、[NSX] ロード バランサ リソース (Cloud.NSX.LoadBalancer) でのみ使用できます。

    • resource.Cloud_Machine_1.id

      クラウド テンプレート コードで Cloud_Machine_1 と指定されているマシンがロード バランサに含まれるように指定します。

    • resource.Cloud_Machine_2.networks[2].id

      マシン NIC Cloud_Machine_2.networks[2] に展開されたとき、クラウド テンプレート コードで Cloud_Machine_2 と指定されているマシンのみがロード バランサに含まれるように指定します。

  • ログ レベル

    ログ レベルの値には、エラー ログの重要度レベルを指定します。オプションは、NONE、EMERGENCY、ALERT、CRITICAL、ERROR、WARNING、INFO、DEBUG、NOTICE です。ログ レベルの値は、クラウド テンプレートのすべてのロード バランサに適用されます。このオプションは、NSXに固有です。親が設定されているロード バランサの場合、親ログ レベルの設定は子のログ レベル設定をオーバーライドします。

    関連情報については、NSX製品ドキュメントのロード バランサの追加などのトピックを参照してください。

  • タイプ

    ロード バランサのタイプを使用して、スケーリング サイズを指定します。デフォルトは小です。このオプションは、NSXに固有です。親が設定されているロード バランサ場合、親のタイプ設定は子のタイプ設定をオーバーライドします。

    • 小

      NSX-Vではコンパクト、NSX-T では小規模に関連付けられます。

    • 中

      NSX-Vでは大、NSX-T では中規模に関連付けられます。

    • 大

      NSX-Vでは特大、NSX-T では大規模に関連付けられます。

    • 特大

      NSX-Vでは超特大、NSX-T では大規模に関連付けられます。

      関連情報については、NSX 製品ドキュメントの「ロード バランサ リソースのスケーリング」などのトピックを参照してください。

    このオプションは、[NSX] ロード バランサ リソース (Cloud.NSX.LoadBalancer) で使用できます。

  • アルゴリズム（サーバ プール）
    アルゴリズム バランシング メソッドを使用して、サーバ プール メンバー間で受信接続を分配する方法を制御します。アルゴリズムはサーバ プールで使用することも、サーバで直接使用することもできます。次の条件のいずれかを満たすサーバは、すべてのロード バランシング アルゴリズムでスキップされます。
    • 管理状態が「DISABLED」に設定されている
    • 管理状態が「GRACEFUL_DISABLED」に設定されていて、一致するパーシステンス エントリがない
    • アクティブまたはパッシブ健全性チェックの状態が「DOWN」になっている
    • サーバ プールの最大同時接続数の上限に達した

    このオプションは、NSXに固有です。

    • IP_HASH

      ソース IP アドレスのハッシュ、および実行されているすべてのサーバの重みの合計に基づいて、サーバを選択します。

      NSX では IP-HASH に対応します。

    • LEAST_CONNECTION

      サーバ上の既存の接続数に基づき、クライアント リクエストを複数のサーバに分散します。新しい接続は、接続数が最も少ないサーバに送信されます。サーバ プール メンバーに重みが設定されている場合でも、重みは無視されます。

      NSX-Vでは LEASTCONN、NSX-T では LEAST_CONNECTION に対応します。

    • ROUND_ROBIN

      受信したクライアント要求を、要求処理能力がある利用可能なサーバのリストに基づいて持ち回りで処理します。サーバ プール メンバーの重みは設定されていた場合でも無視されます。デフォルト。

      NSX では ROUND_ROBIN に対応します。

    • WEIGHTED_LEAST_CONNECTION

      各サーバには、プール内の他のサーバを基準としてこのサーバの実行方法を示す重み値が割り当てられています。この値を基に、プール内の他のサーバと比較して、サーバに送信されるクライアント リクエストの数が決定します。このロード バランシング アルゴリズムは、重み値を使用して、使用可能なサーバ リソース間で負荷を均等に分散する処理に特化しています。重みの値を設定せず、スロー スタートを有効にしている場合、値はデフォルトで 1 になります。

      NSX-Tでは WEIGHTED_LEAST_CONNECTION に対応します。NSX-V では、対応するものはありません。

    • WEIGHTED_ROUND_ROBIN

      各サーバには、プール内の他のサーバを基準としてこのサーバの実行方法を示す重み値が割り当てられています。この値を基に、プール内の他のサーバと比較して、サーバに送信されるクライアント リクエストの数が決定します。このロード バランシング アルゴリズムは、使用可能なサーバ リソース間で負荷をに分散することを目的としています。

      NSX-Tでは WEIGHTED_ROUND_ROBIN に対応します。NSX-Vでは、対応するものはありません。

    • URI

      URI の左側の部分がハッシュされ、実行中のサーバの合計重みによって除算されます。結果により、要求を受信するサーバが指定されます。これにより、サーバが起動または停止しない限り、URI は常に同一のサーバに送信されます。URI アルゴリズム パラメータには 2 つのオプション（uriLength=<len>、uriDepth=<dep>）があります。長さのパラメータの範囲は、1<=len<256にする必要があります。深さのパラメータの範囲は、1<=dep<10にする必要があります。長さと深さのパラメータには、正の整数が続きます。これらのオプションでは、URI の最初の部分のみに基づいてサーバのバランシングを行うことができます。長さのパラメータは、アルゴリズムが URI の最初の部分に定義された文字だけを対象としてハッシュを計算することを示します。深さのパラメータは、ハッシュの計算に使用されるディレクトリの最大の深さを示します。要求に含まれる各スラッシュが 1 つのレベルとして数えられます。両方のパラメータが指定されている場合は、いずれかに達したときに評価が停止します。

      NSX-Vでは URI に対応します。NSX-Tでは、対応するものはありません。

    • HTTPHEADER

      各 HTTP 要求で HTTP ヘッダー名の検索が行われます。括弧内のヘッダー名では、大文字と小文字が区別されません。ヘッダーがない、または値を含んでいない場合は、ラウンド ロビン アルゴリズムが適用されます。HTTPHEADER アルゴリズム パラメータのオプションは 1 つ (headerName=<name>) です。

      NSX-Vでは HTTPHEADER に対応します。NSX-Tでは、対応するものはありません。

    • URL

      引数に指定される URL パラメータは、各 HTTP GET 要求のクエリ文字列内で検索されます。パラメータの後ろに等号の = と値が続く場合、その値がハッシュされ、実行されるサーバの重みの合計で割られます。結果により、要求を受信するサーバが指定されます。このプロセスを使用して要求に含まれるユーザー ID が追跡され、サーバの起動または停止が起こらない限り、常に同一のユーザー ID が同一のサーバに送信されます。値またはパラメータが検出されない場合は、ラウンド ロビン アルゴリズムが適用されます。URL アルゴリズム パラメータのオプションは 1 つ (urlParam=<url>) です。

      NSX-Vでは URL に関連付けられます。NSX-Tでは、対応するものはありません。

    関連情報については、NSX 製品ドキュメントの「ロード バランシング用サーバ プールの追加」などのトピックを参照してください。

  • 健全性監視

    健全性監視は、サーバが使用可能かどうかをテストする際に使用します。HTTP、ICMP、TCP、UDP プロトコルのアクティブな健全性監視がサポートされています。パッシブな健全性監視は、NSX-Tでのみ使用できます。

    このオプションは、NSXに固有です。

    • httpMethod

      健全性チェック要求のサーバ ステータスを検出するために使用する HTTP メソッド。GET、HOST、OPTIONS、HEAD、PUT の各メソッドがあります。

    • requestBody

      健全性チェック要求の本文の内容。HTTP、TCP、UDP の各プロトコルで使用され、これらのプロトコルで必要になります。

    • responseBody

      健全性チェックで予期されるレスポンス本文の内容。受信した文字列がこのレスポンス本文と一致する場合、サーバは健全であると見なされます。HTTP、TCP、UDP の各プロトコルで使用され、これらのプロトコルで必要になります。

    注： UDP 監視プロトコルを使用する場合は、 UDP Data Sentと UDP Data Expected のパラメータが必要です。 requestBodyおよび responseBody のプロパティは、これらのパラメータにマッピングされます。

    このオプションは、NSXロード バランサ リソース (Cloud.NSX.LoadBalancer) で使用できます。

    関連情報については、NSX 製品ドキュメントの「アクティブ健全性モニターの構成」などのトピックを参照してください。

  • 健全性チェック

    健全性チェックのオプションを使用して、ロード バランサが健全性チェックを実行する方法を指定します。

    このオプションは、NSXロード バランサ リソース (Cloud.NSX.LoadBalancer) でのみ使用できます。

    使用できる健全性チェックの設定例については、Automation Assembler のネットワーク、セキュリティ グループ、およびロード バランサ リソースの例を参照してください。

NSX ネットワーク タイプおよびロード バランサのオプション

ロード バランサのオプションは、クラウド テンプレートでロード バランサ リソースが関連付けられているネットワークによって異なります。ロード バランサは、ネットワーク タイプとネットワーク条件に応じて構成できます。

  • オンデマンド ネットワーク

    ロード バランサ コンピューティングがオンデマンド ネットワークに接続されている場合、新しい Tier-1 ルーターが作成されて、ネットワーク プロファイルに指定されている Tier-0 ルーターに接続されます。その後、ロード バランサは Tier-1 ルーターに接続されます。Tier-1 ルーター VIP アドバタイズは、VIP が既存のネットワーク上にあれば有効です。DHCP を使用するようにオンデマンド ネットワークが構成されている場合、オンデマンド ネットワークとロード バランサは Tier-1 ルーターを共有します。

  • 既存のネットワーク

    ロード バランサは、既存のネットワークに接続されている場合、そのネットワークの Tier-1 ルーターで作成されます。Tier-1 ルーターに接続されたロード バランサがない場合は、新しいロード バランサが作成されます。ロード バランサがすでにある場合は、そのロード バランサに新しい仮想サーバが接続されます。既存のネットワークが Tier-1 ルーターに接続されていない場合は、新しい Tier-1 ルーターが作成されて、ネットワーク プロファイルに定義されている Tier-0 ルーターに接続されます。Tier-1 ルーター VIP アドバタイズは有効ではありません。

    VMware Aria Automationは、2 つの異なる既存ネットワークに配置されたNSX-T 2 アーム ロード バランサ（インライン ロード バランサ）をサポートしていません。2 アームロード バランサのシナリオでは、VIP アップリンクは既存のネットワークに配置されますが、プール メンバー マシンはオンデマンド ネットワークに接続されます。既存のネットワークを使用している場合にロード バランシングを指定する際は、ロード バランサ VIP とプール メンバー マシンに同じ既存のネットワークが使用される 1 アーム ロード バランサを構成する必要があります。ただし、ネットワーク プロファイルで選択したロード バランサを使用している場合、2 つの異なる既存ネットワークが接続されていれば、この 2 つの既存ネットワークのマシン間でロード バランシングを実行できます。

  • ネットワーク プロファイルに定義されるネットワークの隔離

    ネットワーク タイプが outboundまたはprivate の場合は、ネットワーク プロファイルでネットワークの隔離設定を指定して、新しいセキュリティ グループをエミュレートできます。マシンが既存のネットワークに接続され、隔離の設定がプロファイルで定義されるため、このオプションは既存のネットワークに作成されるロード バランサと似ています。違いは、データパスを有効にするために、Tier-1 のアップリンク ポート IP アドレスが隔離セキュリティ グループに追加されていることです。

NSXに関連付けられたネットワークでロード バランサ設定を指定するには、クラウド テンプレート デザインで NSX ロード バランサ リソースを使用します。

詳細については、VMware ブログのvRA Cloud Assembly Load Balancer with NSX-T Deep Diveを参照してください。

NSX-Tロード バランサ プロファイルのパーシステンス

VMware Aria Automationクラウド テンプレートおよび展開では、SOURCE_IP および COOKIE 設定でNSX-T ロード バランサ パーシステンス プロファイルのオプションがサポートされています。NSX-Tでこれらの設定を構成し、VMware Aria Automation クラウド テンプレートおよび展開で使用できるようにする方法については、NSX-T ドキュメントのパーシステンス プロファイルの追加を参照してください。

複数のロード バランサで NSX-TTier-1 または NSX-V Edge が共有されている場合のログ レベルまたはタイプの設定の再構成

複数のロード バランサを含むクラウド テンプレートを使用し、これらのロード バランサで NSX-Tエンドポイントの Tier-1 ルーターまたはNSX-V エンドポイントの Edge ルーターを共有している場合、いずれかのロード バランサ リソースでログ レベルまたはタイプの設定を再構成しても、他のロード バランサの設定は更新されません。設定が一致しない場合、NSXに不整合が生じます。これらのログのレベルまたはタイプの設定を再構成するときに不整合が生じないようにするには、関連付けられた NSXエンドポイントの Tier-1 ルーターまたは Edge ルーターを共有するクラウド テンプレート内のすべてのロード バランサ リソースに同じ再構成値を使用します。

利用可能な Day 2 操作

ロード バランサを含む展開をスケール インまたはスケール アウトすると、そのロード バランサは、新しく追加されたマシンを含めるように、または撤去対象のロード バランシング マシンを停止するように構成されます。

クラウド テンプレートおよび展開で使用できる一般的な Day 2 操作のリストについては、Automation Assembler 展開またはサポートされるリソースで実行できるアクションを参照してください。

詳細情報

ネットワーク プロファイルでのロード バランサ設定の定義については、VMware Aria Automation でのネットワーク プロファイルの詳細を参照してください。

ロード バランサを含むテンプレート デザインの例については、「Automation Assembler のネットワーク、セキュリティ グループ、およびロード バランサ リソースの例」を参照してください。

VMware Avi Load Balancer リソースについては、「VMware Avi Load Balancer リソースの使用」を参照してください。