本主题介绍了路由聚合配置，该配置用于在 Google Cloud Platform (GCP) 中运行的 NSX Advanced Load Balancer Controller 上置备大量虚拟服务。
路由聚合
路由聚合是一种用于最大限度减少 IP 网络中所需的路由条目数的方法。不同于平面路由（每个路由表包含每个路由的唯一条目），路由聚合会将多个路由整合到一个路由通告中。
对于在 GCP 中部署的 NSX Advanced Load Balancer，如果未启用路由聚合，则控制器会为每个虚拟服务创建一个特定的 /32 路由，以便将入站流量正确转发到指定的虚拟服务。根据所用网络，虚拟服务的数量可以大幅扩展，路由条目也会随之增多。但是，GCP 中仅支持有限的路由条目数（约 2000 个）。为解决此限制，可将属于某个特定子网的路由进行聚合以创建掩码路由，从而减少 GCP 中的路由条目数。
以下几节介绍了配置此功能的步骤。
将路由聚合用于 GCP 中的 NSX Advanced Load Balancer
为能够聚合多个虚拟服务对应的 GCP 路由，为虚拟服务分配的虚拟 IP (VIP) 必须位于同一子网范围内。对于自动分配，将从在 IPAM 配置的“可用的网络”中指定的子网分配 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 中只有一个路由条目 (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 组中的两个服务引擎
未启用路由聚合：
虚拟服务 |
虚拟 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 组中，而虚拟服务的 VIP 则从该 SE 组上配置的 service_ip_subnet 中进行分配。
假设要创建一个具有八个虚拟服务的实例。根据所选 SE 虚拟机的预期吞吐量和大小，需要将每个 SE 的最大虚拟服务数限制为两个。要配置八个虚拟服务，则必须创建四个 SE 组。每个 SE 组将编写两个聚合路由（每个 SE 组中有两个 SE）。因此，需要配置四个子网。这四个子网需要源自一个较大的 IPAM 子网。
以下是计算详情：
配置的 GCP IPAM 子网 = 10.1.1.0/24
配置的每个 SE 的最大虚拟服务数 = 2
预期的最大虚拟服务数 = 8
所需的 SE 组数 = 8/2 = 4
要配置的
service_ip_subnets数 = 4
需要将 IPAM 子网 10.1.1.0/24 划分为四个较小的子网，并且必须分别将每个子网分配给每个 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 |
配置步骤
必备条件：必须设置 NSX Advanced Load Balancer Controller、云、IPAM 和网络。
有关 GCP 云中可用的各种网络配置选项，请参阅 GCP 网络配置。
要更新 GCP 云以启用路由聚合，请执行以下操作：
步骤 1：配置云。
在 GCP 云对象的 vip_allocation_strategy 字段中，启用 match_se_group_subnet 字段。此字段当前在 NSX Advanced Load Balancer UI 中不可用，只能通过 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 表示）。
将 IPAM 网络划分为 N 个较小的子网，以便每个子网最多具有 M 个 IP 地址。控制器会使用这些子网在 GCP 中编写路由，而不是分别为每个 VIP 和放置 VIP 的 SE 各创建一个 /32 路由。
下面提供了上述计算的几个示例：
示例 1：
要置备的虚拟服务总数为 256。
单个 SE 可以托管的最大虚拟服务数为 64。
因此，需要创建的 SE 组数为 256/64 = 4。
为虚拟服务创建的 IPAM 网络为 10.10.0.0/24，该网络具有 254 个 IP 地址。
将该 IPAM 网络划分为四个较小的子网，每个子网 64 个 IP 地址：10.10.0.0/26、10.10.0.64/26、10.10.0.128/26 和 10.10.0.192/26。这些子网为 SE 组的服务子网。
示例 2：
要置备的虚拟服务总数为 512。
单个 SE 可以托管的最大虚拟服务数为 32。
因此，需要创建的 SE 组数为 512/32 = 16。
为虚拟服务创建的 IPAM 网络为 10.10.0.0/23，该网络具有 510 个 IP 地址。
将该 IPAM 网络划分为 16 个较小的子网，每个子网 32 个 IP 地址：10.10.0.0/27、10.10.0.32/27、10.10.0.64/27，直到 10.10.1.224/27。这些子网为 SE 组的服务子网。
步骤 3：设置 SE 组。
路由聚合模式支持活动/活动和活动/备用 HA 模式。
为每个 SE 组配置 service-IP 子网。service-IP 子网为相应 SE 组中的相应虚拟服务提供 IP 地址。要启用此功能，请在 SE 组配置中配置 service-IP 子网对象。
必须将 service-IP 子网划分为若干较小的子网，数量计算方式如步骤 2 (4) 中所述。
此字段只能通过 CLI 进行设置。
如果使用 service-IP 子网字段，将仅从指定的 SE 组分配虚拟服务 IP。
如果未设置子网，则必须为虚拟服务 IP 编写 /32 路由。
将 min_scaleout_per_vs 和 max_scaleout_per_vs 的值配置为在步骤 2 中确定的 SE 组中的 SE 数（请参阅示例 1 中的第 2 点）。
将 max_vs_per_se 值配置为在步骤 2 中确定的单个 SE 可以托管的最大虚拟服务数（本例中为 64，请参阅示例 1 中的第 2 点）。
[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 组中分配虚拟服务。根据自动分配的 VIP，IPAM 将覆盖任何手动选择的 SE 组。有关虚拟服务放置的更多信息，请参阅《VMware NSX Advanced Load Balancer 配置指南》中的“NSX Advanced Load Balancer 服务引擎的弹性高可用性”一节。
使用路由聚合时，将在 GCP 中仅为 SE 组中的一个 SE 创建一个服务子网路由。
虚拟服务扩展
通过增大服务引擎组配置中的 min_scaleout_per_vs 值和 max_scaleout_per_vs 值，可以将虚拟服务扩展到新的服务引擎。这会将服务引擎组中的所有虚拟服务都扩展到新 SE 计数。
如果 SE 组中存在大量 SE，可能会发生一段时间的流量中断。这是因为 GCP 中的路由是在扩展第一个虚拟服务时创建的，但 SE 可能不会开始侦听其余的虚拟服务。
在 SE 组中扩展虚拟服务的步骤：
将 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：选择其他 IPAM 配置文件。
如步骤 3 (4) 中所述，必须根据相应的 IPAM 配置文件，为 SE 组配置 service_ip_subnet 字段。如果选择其他 IPAM 配置文件，则会引发以下错误：
场景 2：未配置静态 IP 地址池。
如前面的示例中所示，您可以通过选择静态范围来修复此问题。
