如果多个虚拟服务具有相同的 IP 地址，但具有不同的侦听端口，则 NSX Advanced Load Balancer 支持 VIP 共享。本节介绍了不同扩展模式下的共享虚拟服务 IP (VIP) 行为。

假设虚拟服务 1 的 VIP 为 1.1.1.1，端口为 80；虚拟服务 2 的 VIP 为 1.1.1.1，端口为 443。

NSX Advanced Load Balancer 放置逻辑限制为将这些虚拟服务放置在同一组服务引擎上，因为仅一个主服务引擎可以通告该 IP 地址。如果主服务引擎发生故障，则需要在相同的辅助服务引擎上激活虚拟服务，该服务引擎将接管主服务引擎的角色。

扩展模式

如果 NSX Advanced Load Balancer 在 L2 扩展模式下运行（在很多环境中都是这种情况，例如 VMware、OpenStack、AWS、Linux 服务器云等），则主服务引擎负责通告 VIP 并将流量转移到辅助服务引擎。

如果 NSX Advanced Load Balancer 在 L3 扩展模式（例如 BGP、ECMP）下运行（在启用了 BGP 的 Azure、GCP、Linux 服务器云等环境中就是这种情况），则下一跳路由器/负载均衡器负责进行基于流的哈希处理，以将流量传送到通告虚拟服务 IP 的服务引擎。

第 2 层扩展模式下的共享 VIP

可以单独扩展共享 VIP 的每个虚拟服务，NSX Advanced Load Balancer 控制器 将它们放置在同一组服务引擎上，并且仅将流分配给托管虚拟服务的一组服务引擎。



第 3 层扩展模式下的共享 VIP

  • 无法单独扩展共享 VIP 的每个虚拟服务。它们需要扩展到相同数量的 SE，才能正常传输流量。

  • 在一个虚拟服务上执行的扩展/缩减操作必须平均应用于共享 VIP 的所有其他虚拟服务。

  • 在一个虚拟服务上执行的迁移将自动应用于共享 VIP 的其他虚拟服务。

在达到容量的 SE 上放置共享 VIP 虚拟服务

如果在已满 SE（已达到 max_vs_per_se）上放置新虚拟服务，并且该虚拟服务与同一 SE 上的现有虚拟服务共享 VIP，则在 NSX Advanced Load Balancer 中阻止该操作。这可能会在共享 VIP 设置中引入不对称性。对于基于 ECMP 的扩展部署，不对称扩展的共享虚拟服务导致流量丢失。

现已放宽共享虚拟服务的 max_vs_per_se 限制。

场景

旧行为

新行为

max_vs_per_se = 2



创建/启用了虚拟服务 1b，并且该虚拟服务必须放置在 SE 1 上，以确保虚拟服务位于同一 SE 上。

由于出现“SE 1 达到最大虚拟服务数”错误，VS 1b 处于 OPER_RESOURCES 状态

将虚拟服务 1b 放置在 SE 1 上。该场景触发打包算法的新行为，该算法在具有同级 VS 1a 的 SE 没有容量时尝试放置虚拟服务。

max_vs_per_se = 2，max_se = 1



同时启用了 VS 1a 和 VS 1b。

VS 1a 处于 OPER_RESOURCES 状态，VS 1b 处于 OPER_RESOURCES 状态，并显示“SE 组已达到最大容量”错误消息

将 VS 1a 放在 SE 1 上，将 VS 1b 放在 SE 1 上。该场景触发打包算法的新行为，其中，如果 SE 组无法创建新的 SE（已达到 max_se），并且 SE 组中的现有 SE 都没有容量同时放置所有共享虚拟服务，则打包算法选择 SE 组中负载最少的 SE。

max_vs_per_se = 2，max_se = 2，min_scaleout_per_vs = 1



VS 1a 扩展到 SE 1 和 SE2，并创建/启用了 VS 1b。

VS 1b 放置在 SE 1 上。

VS 1b 放置在 SE 1 上。

此外，在 L3 扩展中，在 VS 1a 和 VS 1b 上都会发生故障，这强调了不对称性问题，即虚拟服务 1a 仅放置在 SE 1 上，而虚拟服务 1b 放置在 SE 1 和 SE 2 上。

对于情况 3，VS 1a 和 VS 1b 上发生的故障如下所示：故障 1：对于 VS 1a - 该虚拟服务与 2 个虚拟服务共享一个 VsVIP，并不对称地进行扩展。对于 VIP 1，该虚拟服务具有 2 个服务引擎，共享虚拟服务 VS 1b 具有更少的服务引擎（1 个）。

故障 2：对于 VS 1b - 该虚拟服务与 2 个虚拟服务共享一个 VsVIP，并不对称地进行扩展。对于 VIP 1，该虚拟服务具有 1 个服务引擎，共享虚拟服务 VS 1a 具有更多的服务引擎（2 个）。

max_vs_per_se = 2，max_se = 2，min_scaleout_per_vs = 2



VS 1a 扩展到 SE 1 和 SE2，并创建/启用了 VS 1b。

VS 1b 仅放置在 SE 1 上。

VS 1b 仅放置在 SE 1 上。

对于基于 ECMP 的扩展，每当检测到不对称问题时，如果共享 VIP 集中的任何虚拟服务扩展到的 SE 比该集中的其他虚拟服务多/少，则会在所有共享 VIP 虚拟服务上发生故障。

这种变化在打包放置算法中最明显，该算法进行了优化以满足在以下场景中放置共享虚拟服务的要求：在 SE 组中达到 max_se，并且某些 SE 已达到 max_vs_per_se。

注：

由于控制器跟踪当前在 SE 上存在/不存在的所有共享虚拟服务，因此，缓冲区 SE 计算将尽量满足 SE 组中的每个 SE 上存在的虚拟服务数量增加的要求。

下图显示了非对称扩展期间发生的故障：





有关 OpenStack 的 VIP 放置的更多详细信息，请参见《VMware NSX Advanced Load Balancer 安装指南》中的 OpenStack 云高级配置。