本节重点介绍了缩放服务引擎的用例场景。

规模用例

未缩放的虚拟服务提供了从客户端到 NSX Advanced Load Balancer 控制器 再到服务器的最佳数据包路径。缩放 SE 可能会为输入数据包的某些流量(具体是指推送到辅助 SE 的流量)添加额外的跳段。缩放非常适合以下用例:

  • 流量涉及非常少的输入流量和较多的输出流量,例如客户端/服务器应用程序、HTTP 或视频流协议。例如,SE 可能位于具有单个 10 Gbps 网卡的主机上。在扩展后,虚拟服务仍然可以向客户端提供 30 Gbps 流量。

  • 协议或虚拟服务功能消耗大量 CPU 资源,例如,压缩或安全套接字层 (Secure Sockets Layer, SSL)/传输层安全 (Transport Layer Security, TLS)。

  • 并发连接数超过单个 SE 的内存。

缩放不太适合以下用例:

  • 流量涉及的大量客户端上载超过单个 SE(或具体是指底层虚拟机)的网络容量或每秒数据包数容量。由于所有输入数据包都经过主 SE 进行传输,因此,缩放可能不会带来多少好处。有关每秒数据包数限制,请参见有关所需平台或 Hypervisor 的文档。

对现有连接的影响

现有连接不受扩展影响,因为仅新连接符合扩展到另一个 SE 的条件。在缩减时,为辅助 SE 上的连接留出 30 秒的完成时间,然后辅助 SE 将其终止。将在虚拟服务的重要日志中标记这些连接。连接或客户端的后续数据包符合由主 SE 重新进行负载均衡的条件。

辅助 SE 故障

如果辅助 SE 发生故障,主 SE 将很快检测到该故障,并将后续数据包转发到处理虚拟服务的其余 SE。根据选择的高可用性模式,也可能会在组中自动添加新的 SE 以填补容量空白。除了连接数可能增加以外,到其他 SE 的流量不受影响。

主 SE 故障

如果主 SE 发生故障,将自动在辅助 SE 之间选择新的主 SE。与未缩放的故障切换事件类似,新的主节点将为虚拟服务 IP 地址通告一个无故 ARP。如果虚拟服务使用源 IP 持久性,新升级的主 SE 将具有持久性表的镜像副本。其他持久性方法(如 Cookie、安全 HTTPS)是由客户端维护的;因此,不需要进行镜像。对于以前委派给新升级的主 SE 的 TCP 和 UDP 连接,这些连接将继续正常运行,但这些数据包现在不需要在主 SE 和辅助 SE 之间添加额外的跳段。

对于发生故障的主 SE 或其他辅助 SE 拥有的连接,新的主 SE 需要在其连接表中重建它们的映射。在新的主 SE 收到新的非 SYN 数据包时,它将查询其余 SE 以确定它们是否一直在处理该连接。如果是,将重新建立到同一 SE 的连接流。如果没有 SE 声称一直在处理该流量,则假设该流量由发生故障的主 SE 拥有。对于 TCP,将重置连接;对于 UDP,将使用其余 SE 进行负载均衡。

与 HA 模式的关系

缩放与高可用性不同,但两者紧密联系在一起。如果组中的单个 SE 发生故障,扩展的虚拟服务仅会出现性能下降。传统高可用性活动/备用模式(双 SE 配置)不支持缩放。相反,服务连续性取决于在正常运行的 SE 上是否存在初始化的备用虚拟服务。它们可以通过单个命令进行接管。

NSX Advanced Load Balancer 的默认高可用性模式是弹性高可用性 N+M 模式,这会在单个 SE 上以非缩放模式启动 SE 组的每个虚拟服务。在此类配置中,如果运行未缩放的虚拟服务的 SE 发生故障,将导致短暂的服务中断(仅限这些虚拟服务),在此期间,控制器将受影响的虚拟服务放在备用 SE 上。相比之下,已扩展到 N+M 组中的两个或更多 SE 的虚拟服务不会出现中断,但性能可能会有所下降。