このトピックでは、Google Cloud Platform (GCP) で動作する NSX Advanced Load Balancer Controller で多数の仮想サービスをプロビジョニングするためのルート集約構成について説明します。
ルートの集約
ルートの集約は、IP アドレス ネットワークで必要なルート エントリの数を最小限に抑えるために使用される方法です。各ルーティング テーブルに各ルートの一意のエントリが含まれるフラット ルーティングとは異なり、ルートの集約は、複数のルートを 1 つのルート アドバタイズに統合します。
ルートの集約なしで GCP に展開された NSX Advanced Load Balancer の場合、コントローラは各仮想サービスに特定の /32 ルートを作成し、受信トラフィックが指定された仮想サービスに正しく転送されるようにします。ネットワークによっては、仮想サービスの数が大量にスケール アップする可能性があり、これによりルート エントリも増加します。GCP でサポートされるルート エントリの数は制限されています（約 2,000 個）。この制限に対処するため、特定のサブネットに属するルートが集約されてマスク ルートが作成されるため、GCP 内のルート エントリの数が減ります。
この機能を構成する手順については、次のセクションで説明します。
GCP での NSX Advanced Load Balancer とのルート統合の使用
複数の仮想サービスに対応する GCP ルートの集約を有効にするには、仮想サービスに割り当てられた仮想 IP アドレス (VIP) が同じサブネット範囲内にある必要があります。自動割り当ての場合、IP アドレス管理構成の使用可能なネットワークで指定されたサブネットから VIP が割り当てられます。
ルートの集約機能を示す例を次に示します。
単一のサービス エンジンの場合
a. ルートの集約なしの場合は次のとおりです。
仮想サービス |
仮想 IP |
GCP でプログラムされたルート |
|---|---|---|
vs1 |
10.1.1.1 |
10.1.1.1/32、ネクスト ホップ = SE1 |
vs2 |
10.1.1.2 |
10.1.1.2/32、ネクスト ホップ = SE1 |
vs3 |
10.1.1.3 |
10.1.1.3/32、ネクスト ホップ = SE1 |
vs4 |
10.1.1.4 |
10.1.1.4/32、ネクスト ホップ = SE1 |
GCP には 1 つのルート エントリ (10.1.1.0/29) のみが存在します。
仮想サービス |
仮想 IP |
GCP でプログラムされたルート |
|---|---|---|
vs1 |
10.1.1.1 |
10.1.1.0/29、ネクスト ホップ = SE1 |
vs2 |
10.1.1.2 |
|
vs3 |
10.1.1.3 |
|
vs4 |
10.1.1.4 |
仮想サービスは SE グループ内の 2 つのサービス エンジンにスケールアウト
ルートの集約なしの場合は次のとおりです。
仮想サービス |
仮想 IP |
GCP でプログラムされたルート |
|---|---|---|
vs1 |
10.1.1.1 |
10.1.1.1/32、ネクスト ホップ = SE1 10.1.1.1/32、ネクスト ホップ = SE2 |
vs2 |
10.1.1.2 |
10.1.1.2/32、ネクスト ホップ = SE1 10.1.1.2/32、ネクスト ホップ = SE2 |
vs3 |
10.1.1.3 |
10.1.1.3/32、ネクスト ホップ = SE1 10.1.1.3/32、ネクスト ホップ = SE2 |
vs4 |
10.1.1.4 |
10.1.1.4/32、ネクスト ホップ = SE1 10.1.1.4/32、ネクスト ホップ = SE2 |
仮想サービス |
仮想 IP |
GCP でプログラムされたルート |
|---|---|---|
vs1 |
10.1.1.1 |
10.1.1.0/29、ネクスト ホップ = SE1 10.1.1.0/29、ネクスト ホップ = SE2 |
vs2 |
10.1.1.2 |
|
vs3 |
10.1.1.3 |
|
vs4 |
10.1.1.4 |
仮想サービスは複数の SE グループにスケールアウト
多数の仮想サービスを構成するときに、サービス エンジンのサイズに基づいて、SE あたりの仮想サービスの制限が上限に達することがあります。これを解決するには、各 SE グループ内の仮想サービスのグループをルートの集約を介して集約できるように、仮想サービスを複数の SE グループに分散する必要があります。
個々の SE グループに対してルートの集約と service_ip_subnet の構成を有効にすると、コントローラは仮想サービスを自動的に SE グループの 1 つに配置しますが、仮想サービスの VIP は、その SE グループで構成された service_ip_subnet 内から割り当てられます。
8 つの仮想サービスを持つインスタンスについて考えます。予想されるスループットと選択した SE 仮想マシンのサイズに基づいて、SE あたりの仮想サービスの最大数を 2 に制限する必要があります。8 つの仮想サービスを構成するには、4 つの SE グループを作成する必要があります。各 SE グループは、2 つの集約ルート（SE グループの SE はそれぞれ 2 つ）をプログラムします。そのため、4 つのサブネットを構成する必要があります。これは、より大きな IP アドレス管理サブネットから分割する必要があります。
この計算の詳細は次のとおりです。
構成済みの GCP IP アドレス管理サブネット = 10.1.1.0/24
構成済みの SE あたりの仮想サービスの最大数 = 2
想定される仮想サービスの最大数 = 8
必要な SE グループの数 = 8/2 = 4
構成する
service_ip_subnetsの数 = 4
IP アドレス管理サブネット 10.1.1.0/24 は 4 つのサブネットに分割する必要があり、それぞれを次のように 1 つの SE グループに割り当てる必要があります。
仮想サービス |
SE グループ |
|
仮想 IP |
GCP でプログラムされたルート |
|---|---|---|---|---|
vs1 |
SE グループ 1 |
10.1.1.0/26 |
10.1.1.1 |
10.1.1.0/26、ネクスト ホップ = SE1 10.1.1.0/26、ネクスト ホップ = SE2 |
vs2 |
SE グループ 1 |
10.1.1.0/26 |
10.1.1.2 |
|
vs3 |
SE グループ 2 |
10.1.1.64/26 |
10.1.1.65 |
10.1.1.64/26、ネクスト ホップ = SE3 10.1.1.64/26、ネクスト ホップ = SE4 |
vs4 |
SE グループ 2 |
10.1.1.64/26 |
10.1.1.66 |
|
vs5 |
SE グループ 3 |
10.1.1.128/26 |
10.1.1.129 |
10.1.1.128/26、ネクスト ホップ = SE5 10.1.1.128/26、ネクスト ホップ = SE6 |
vs6 |
SE グループ 3 |
10.1.1.128/26 |
10.1.1.130 |
|
vs7 |
SE グループ 4 |
10.1.1.192/26 |
10.1.1.193 |
10.1.1.192/26、ネクスト ホップ = SE7 10.1.1.192/26、ネクスト ホップ = SE8 |
vs8 |
SE グループ 4 |
10.1.1.192/26 |
10.1.1.194 |
構成手順 (Configuration Steps)
前提条件：NSX Advanced Load Balancer Controller、クラウド、IP アドレス管理、およびネットワークを設定する必要があります。
GCP クラウドで使用できるさまざまなネットワーク構成オプションについては、「GCP ネットワーク構成」を参照してください。
GCP クラウドを更新してルートの集約を有効にするには、次の手順を実行します。
手順 1：クラウドを構成します。
GCP クラウド オブジェクトの vip_allocation_strategy フィールドで match_se_group_subnet フィールドを有効にします。このフィールドは現在、NSX Advanced Load Balancer ユーザー インターフェイスでは使用できず、CLI を使用してのみ構成できます。
[admin:10-138-10-68]: > configure cloud gcp-cloud-subnetroutes-inband [admin:10-138-10-68]: cloud> gcp_configuration [admin:10-138-10-68]: cloud:gcp_configuration> vip_allocation_strategy [admin:10-138-10-68]: cloud:gcp_configuration:vip_allocation_strategy> routes [admin:10-138-10-68]: cloud:gcp_configuration:vip_allocation_strategy:routes> match_se_group_subnet Overwriting the previously entered value for match_se_group_subnet [admin:10-138-10-68]: cloud:gcp_configuration:vip_allocation_strategy:routes> save [admin:10-138-10-68]: cloud:gcp_configuration:vip_allocation_strategy> save [admin:10-138-10-68]: cloud:gcp_configuration> save [admin:10-138-10-68]: cloud> save +------------------------------+--------------------------------------------+ | Field | Value | +------------------------------+--------------------------------------------+ | uuid | cloud-50b7a230-d378-4f6f-9700-3a068bfbce94 | | name | gcp-cloud-subnetroutes-inband | | vtype | CLOUD_GCP | | apic_mode | False | | gcp_configuration | | | cloud_credentials_ref | avi-service-account | | region_name | us-central1 | | zones[1] | us-central1-a | | zones[2] | us-central1-b | | se_project_id | se-project-id | | network_config | | | config | INBAND_MANAGEMENT | | inband | | | vpc_subnet_name | subnet-1 | | vpc_project_id | network-project | | vpc_network_name | dev-vnet-1 | | firewall_target_tags[1] | http-server | | firewall_target_tags[2] | https-server | | vip_allocation_strategy | | | mode | ROUTES | | routes | | | match_se_group_subnet | True | | dhcp_enabled | True | | mtu | 1500 bytes | | prefer_static_routes | False | | enable_vip_static_routes | False | | license_type | LIC_CORES | | ipam_provider_ref | ipam-gcp-cloud-subnetroutes-inband | | state_based_dns_registration | True | | ip6_autocfg_enabled | False | | dns_resolution_on_se | False | | enable_vip_on_all_interfaces | False | | tenant_ref | admin | | license_tier | ENTERPRISE | | autoscale_polling_interval | 60 seconds | +------------------------------+--------------------------------------------+
admin:10-138-10-68]: > show ipamdnsproviderprofile ipam-gcp-cloud-subnetroutes-inband +--------------------------+-------------------------------------------------------------+ | Field | Value | +--------------------------+-------------------------------------------------------------+ | uuid | ipamdnsproviderprofile-775b580b-f4c1-4edb-93f6-e13a85eb7c68 | | name | ipam-gcp-cloud-subnetroutes-inband | | type | IPAMDNS_TYPE_INTERNAL | | internal_profile | | | ttl | 30 sec | | usable_network_refs[1] | net-gcp-cloud-subnetroutes-inband | | allocate_ip_in_vrf | False | | tenant_ref | admin | +--------------------------+-------------------------------------------------------------+
[admin:10-138-10-68]: > show network net-gcp-cloud-subnetroutes-inband +----------------------------+----------------------------------------------+ | Field | Value | +----------------------------+----------------------------------------------+ | uuid | network-09e899e3-a61f-4147-9575-5a6e9c508620 | | name | net-gcp-cloud-subnetroutes-inband | | vcenter_dvs | True | | dhcp_enabled | True | | exclude_discovered_subnets | False | | configured_subnets[1] | | | prefix | 10.10.0.0/24 | | static_ranges[1] | | | begin | 10.10.0.2 | | end | 10.10.0.254 | | vrf_context_ref | global | | synced_from_se | False | | ip6_autocfg_enabled | True | | tenant_ref | admin | | cloud_ref | gcp-cloud-subnetroutes-inband | +----------------------------+----------------------------------------------+
手順 2：必要な SE と SE グループの数を計画します。
必要な SE グループの最小数は、次のように計算できます。
プロビジョニングされる仮想サービスの合計数を見積もります（V で表されます）。
M が、単一の SE でホストできる仮想サービスの最大数であると仮定します。詳細については、「NSX Advanced Load Balancer Controller のサイジング」を参照してください。
SE グループの合計数は V/M です（N で表します）。
IP アドレス管理ネットワークを N 個の小さなサブネットに分割し、各サブネットに最大で M 個の IP アドレスを設定します。コントローラは、これらのサブネットを使用して、VIP が配置されている各 VIP および SE に対応する個別の /32 ルートを持つ代わりに、GCP でルートをプログラミングします。
上記の計算の例をいくつか次に示します。
例 1：
プロビジョニングされる仮想サービスの合計数は、256 です。
単一の SE にホストできる仮想サービスの最大数は、64 です。
そのため、作成する必要がある SE グループの数は、256/64 = 4 になります。
仮想サービス用に作成された IP アドレス管理ネットワークは 10.10.0.0/24 であり、IP アドレスは 254 個です。
IP アドレス管理ネットワークを、それぞれ 10.10.0.0/26、10.10.0.64/26、10.10.0.128/26、10.10.0.192/26 の 4 つの小さなサブネットに分割します。これらは SE グループ サービス サブネットです。
例 2：
プロビジョニングされる仮想サービスの合計数は、512 です。
単一の SE にホストできる仮想サービスの最大数は、32 です。
そのため、作成する必要がある SE グループの数は、512/32 = 16 になります。
仮想サービス用に作成された IP アドレス管理ネットワークは 10.10.0.0/23 であり、IP アドレスは 510 個です。
IP アドレス管理ネットワークを、それぞれ 10.10.0.0.0/27、10.10.0.32/27、10.10.0.64/27 から 10.10.1.224/27 までの 32 個の IP アドレスの 16 個の小さなサブネットに分割します。これらは SE グループ サービス サブネットです。
手順 3：SE グループを設定します。
ルートの集約モードでは、アクティブ/アクティブ モード、アクティブ/スタンバイ HA モードがサポートされます。
各 SE グループの service-IP サブネットを構成します。service-IP サブネットは、それぞれの SE グループ内の各仮想サービスに IP アドレスを提供します。これを有効にするには、SE グループ構成で service-IP サブネット オブジェクトを構成します。
service-IP サブネットは、手順 2 (4) に示すように計算された小さなサブネットに設定する必要があります。
このフィールドは、CLI を使用してのみ設定できます。
フィールド service-IP サブネットが使用されると、仮想サービス IP アドレスは指定された SE グループからのみ割り当てられます。
サブネットが設定されていない場合は、仮想サービス IP アドレスの /32 ルートをプログラムする必要があります。
手順 2（例 1 の 2 番目のポイント）で決定した SE グループ内の SE の数に対し、min_scaleout_per_vs 値と max_scaleout_per_vs 値を構成します。
max_vs_per_se 値を、手順 2（例 1 の 2 番目のポイント）で決定した単一の SE がホストできる仮想サービスの最大数（この場合は 64）に構成します。
[admin:10-138-10-68]: > configure serviceenginegroup gcp-route-aggregation [admin:10-138-10-68]: serviceenginegroup> ha_mode ha_mode_shared_pair [admin:10-138-10-68]: serviceenginegroup> max_vs_per_se 64 [admin:10-138-10-68]: serviceenginegroup> min_scaleout_per_vs 2 [admin:10-138-10-68]: serviceenginegroup> max_scaleout_per_vs 2 [admin:10-138-10-68]: serviceenginegroup> service_ip_subnets 10.10.0.0/26 [admin:10-138-10-68]: serviceenginegroup> save +---------------------------------------+---------------------------------------------------------+ | Field | Value | +---------------------------------------+---------------------------------------------------------+ | uuid | serviceenginegroup-fbd33752-996d-48aa-9534-08372ef10095 | | name | gcp-route-aggregation | | max_vs_per_se | 64 | | min_scaleout_per_vs | 2 | | max_scaleout_per_vs | 2 | ……… | ha_mode | HA_MODE_SHARED_PAIR | ……… | service_ip_subnets[1] | 10.10.0.0/27 | ……… +---------------------------------------+---------------------------------------------------------+
クラウド内のすべての SE グループに同様の構成が必要です。SE グループごとに異なるのは service-IP サブネットのみです。
手順 4：仮想サービスを作成します。
自動割り当てを使用して、仮想サービスを作成します。すべての仮想サービスは、この機能で自動割り当てを使用する必要があることに注意してください。SE グループは、コントローラによって自動的に選択され、異なる SE グループ間で仮想サービスを分布します。SE グループの手動選択は、自動割り当てされた VIP に基づいて IP アドレス管理によってオーバーライドされます。仮想サービスの配置の詳細については、『VMware NSX Advanced Load Balancer 構成ガイド』の「NSX Advanced Load Balancer サービス エンジンの Elastic HA」セクションを参照してください。
ルートの集約を使用すると、SE グループ内の 1 つの SE に対して GCP に作成されるサービス サブネット ルートは 1 つのみです。
仮想サービスのスケールアウト
サービス エンジン グループ構成の min_scaleout_per_vs 値と max_scaleout_per_vs 値を増やすことで、仮想サービスを新しいサービス エンジンにスケールアウトできます。これにより、サービス エンジン グループ内のすべての仮想サービスが新しい SE 数にスケールアウトされます。
SE グループに多数の SE が存在する場合、トラフィックの中断が発生する可能性があります。これは、GCP のルートが最初の VS スケールアウト自体で作成されますが、SE が残りの仮想サービスのリッスンを開始しない可能性があるためです。
SE グループで VS をスケールアウトする手順は、次のとおりです。
SE グループ構成の min_scaleout_per_vs、max_scaleout_per_vs、および max_se を、必要な SE の数に増やします。
[admin:10-138-10-68]: > configure serviceenginegroup gcp-route-aggregation [admin:10-138-10-68]: serviceenginegroup> min_scaleout_per_vs 4 Overwriting the previously entered value for min_scaleout_per_vs [admin:10-138-10-68]: serviceenginegroup> max_scaleout_per_vs 4 Overwriting the previously entered value for max_scaleout_per_vs [admin:10-138-10-68]: serviceenginegroup> max_se 4 Overwriting the previously entered value for max_se [admin:10-138-10-68]: serviceenginegroup> save +-----------------------------------------+---------------------------------------------------------+ | Field | Value | +-----------------------------------------+---------------------------------------------------------+ | uuid | serviceenginegroup-fbd33752-996d-48aa-9534-08372ef10095 | | name | gcp-route-aggregation | | max_vs_per_se | 64 | | min_scaleout_per_vs | 4 | | max_scaleout_per_vs | 4 | | max_se | 4 | ……… +---------------------------------------+-----------------------------------------------------------+
コントローラは、サービス エンジン グループに新しいサービス エンジンを作成し、サービス エンジン グループ内のすべての仮想サービスを新しい SE にスケールアウトします。
トラブルシューティング
シナリオ 1：別の IP アドレス管理プロファイルを選択します。
手順 3 (4) で説明したように、各 IP アドレス管理プロファイルに一致する SE グループに対して service_ip_subnet フィールドを構成する必要があります。別の IP アドレス管理プロファイルを選択すると、次のエラーがスローされます。
シナリオ 2：静的 IP アドレス プールが構成されません。
この問題は、前の例に示すように、静的範囲を選択することで修正できます。
