测试新负载均衡器时的一个常见要求是验证它能否正确均衡负载。循环负载均衡算法通常用作简单的测试用例。
循环负载均衡算法是最早且最可信的负载均衡方法，可以显示非一致的意外流量分布。在许多情况下，这种非一致的流量分布是由与其他功能的互操作所致。
从外部视图（例如，通过 tcpdump）来看，循环操作似乎无法正常运行，因为连接是以非一致方式分发的。虽然期望轮循机制可与其他功能互操作而不出现问题是是非常合理的，但以下是负载分布不均匀的许多可能原因。
非一致循环负载均衡的潜在原因
- 持久性
-
持久性与负载均衡相反。客户端连接后，持久性使其能够在一段时间内坚持使用同一台服务器。验证池中是否未配置持久性。
- 被动运行状况监控器
-
此监控器侦听客户端到服务器的交互，并根据服务器发送的响应动态调整服务器接收的流量比率。因此，当服务器可能正在传递主动（静态）运行状况监控器，并且此服务器发出几条 503（服务器繁忙）消息时，被动监控器会限制发送到服务器的流量，从而中断预期的循环行为。
- 服务器比率
-
在池的服务器选项卡下，确保所有服务器具有相同的比率。
- 连接多路复用
-
默认情况下，将在 HTTP 应用程序配置文件中启用连接多路复用功能，从而尝试通过将空闲连接保持打开状态以进一步重用，而不是终止客户端连接并立即为下一个客户端打开新连接来加速流量。由于这种重用，您将看不到客户端连接与服务器连接之间的明确一对一关联。
- 跨 SE 扩展
-
NSX Advanced Load Balancer SE 基于分布式系统模型。这会影响各个级别的循环。首先，必须跨多个 SE 扩展虚拟服务，以提高容量或提高高可用性。每个 SE 分别为其管理的连接执行循环。
- 跨 CPU 内核扩展
-
在 SE 内部，指定 CPU 内核作为调度程序，该调度程序从网卡中选取数据包并将其（根据数据包流/连接）分发到 CPU 内核（包括它所在的内核）。它考虑了每个内核的忙碌程度，以确保负载最少的 CPU 内核来应答连接。
在繁忙的系统中，这意味着具有调度程序的 CPU 内核（通常为 vCPU0）处理的流量往往比其他内核少。SE 中的每个 CPU 或 vCPU 单独制定负载均衡决策。因此，CPU0 和 CPU1 都执行循环。第一个客户端连接到 CPU0，CPU0 会将连接发送到服务器 1。第二个连接将转到 CPU1，CPU1 也可以将连接发送到服务器 1。
验证
要验证负载均衡行为是否正确，请根据上述建议修改配置（如果适用），然后查看虚拟服务的日志。确保显示重要日志和非重要日志。如果未捕获非重要日志，则必须在虚拟服务配置的分析页面上启用这些日志。
打开日志以查看展开的视图。服务引擎字段显示连接使用的 vCPU。如果跨多个 SE 扩展虚拟服务，请单击要添加到日志筛选器的 SE IP 地址。单击 vCPU 编号，这会筛选此 CPU 处理的连接的日志。
单击日志页面右上角的导出按钮，下载生成的日志。在生成的 CSV 文件中，Server_IP 列显示从筛选的 SE CPU 发送到服务器的请求或连接的顺序。在上面的示例中，列 AU 显示正确选择循环服务器。
