负载均衡算法

选择的负载均衡算法确定在可用的服务器之间分配连接或 HTTP 请求的方法和优先级。可用的算法包括：

• 一致哈希

• 内核关联性

• 最快响应

• 最少服务器

• 最少连接

• 最少负载

• 循环

• 更少任务

可以使用 NSX Advanced Load Balancer UI 和 NSX Advanced Load Balancer CLI 更改负载均衡算法。使用应用程序 > 池 > 设置页面中的算法字段选择一种本地服务器负载均衡算法。更改池的 LB 算法仅影响新连接或请求，不会影响现有的连接。按字母顺序排列的可用选项包括：

一致哈希

使用哈希在服务器之间分配新连接，该哈希基于在“LB 算法”字段下面显示的字段或用户通过 DataScript 函数 avi.pool.chash 提供的自定义字符串中指定的键。下面是一个保留 URI 查询值的示例：

hash = avi.http.get_query("r")
if hash then
avi.pool.select("Pool-Name")
avi.pool.chash(hash)
end

该算法本身结合了负载均衡和持久性，从而最大限度减少添加持久性方法的需求。该算法非常适合对具有动态内容的大量缓存服务器进行负载均衡。它是“一致的”，因为添加或移除服务器并不会导致完全重新计算哈希表。以缓存服务器为例，它不会强制所有缓存必须重新缓存所有内容。如果池具有 9 个服务器，添加第 10 个服务器将导致已有的服务器根据哈希结果将大约 1/9 的命中发送到新添加的服务器。因此，持久性可能仍是非常有用的。不会中断服务器的其余连接。可用的哈希键包括：

字段	描述
自定义标头	在自定义标头字段中指定要使用的 HTTP 标头，例如来源地址。该字段区分大小写。如果该字段为空或标头不存在，则将连接或请求视为未命中，并根据哈希结果发送到服务器。
调用 ID	指定 SIP 标头中的调用 ID 字段。在使用该选项时，具有新调用 ID 的 SIP 事务使用一致哈希进行负载均衡，而现有调用 ID 保留在以前选择的服务器上。现有调用 ID 的状态在应用程序配置文件中的“事务超时”参数定义的空闲超时时间内保持不变。只要 SIP 事务的底层 TCP/UDP 传输状态保持不变，现有调用 ID 的状态就是相关的。
源 IP 地址	客户端的源 IP 地址。
源 IP 地址和端口	客户端的源 IP 地址和端口。
HTTP URI	它包括主机标头和路径。例如，www.avinetworks.com/index.htm。

注：

• 也可以在作为池组成员的池中使用自定义字符串一致哈希算法。

• 只有在池组选择相同的池时，才会选择相同的服务器。如果池组选择了不同的池，将通过新选择的池中的服务器对流量进行负载均衡，具体取决于相应池的负载均衡算法。

内核关联性

每个 CPU 内核使用一部分服务器，每个服务器由部分内核使用。实质上，它提供服务器和内核之间的多对多映射。这些子集的大小由池对象中的 lb_algorithm_core_nonaffinity 变量参数化。在增加时，映射将增加，一直到在所有内核上使用所有服务器。

如果映射到某个内核的所有服务器都不可用，则该内核使用映射到下一个内核（循环）的服务器。

最快响应

将新连接发送到当前为新连接或请求提供最快响应的服务器。这是以收到第一个字节的时间测量的。在端到端计时图表中，这反映为服务器 RTT 加上应用程序响应时间。在池的服务器包含不同的功能或它们处理短期的连接时，该选项是最佳选择。出现问题（例如，到包含图像的数据存储的连接中断）的服务器通常会很快响应，并显示出现 HTTP 404 错误。在使用最快响应算法时，最佳做法是还要启用被动运行状况监控器，后者考虑服务器响应质量，而不仅仅是响应速度，从而识别此类场景并进行调整。

注：

出现问题（例如，到包含图像的数据存储的连接中断）的服务器通常会很快响应，并显示出现 HTTP 404 错误。可以将最快响应算法与被动运行状况监控器结合使用，后者识别此类场景并进行调整。

最少服务器

NSX Advanced Load Balancer 确定满足当前客户端负载所需的最少服务器数量，而不是尝试在所有服务器之间分配所有连接或请求。多余的服务器将不再接收流量，并且可能会将其取消置备或暂时关闭电源。该算法调整负载和监控服务器的相应响应延迟变化以监控服务器容量。连接发送到池中的第一个服务器，直到认为它达到容量，并按顺序将下一个新连接发送到下一个可用的服务器。该算法非常适合虚拟机产生成本的托管环境。

最少连接

新连接发送到当前具有最少未完成并发连接数的服务器。这是在创建新的池时的默认算法，最适合通用服务器和协议。将通过池 > 高级页面中的“连接分配缓冲期”设置在短时间内逐渐引入具有零连接的新服务器。该功能慢慢将新服务器提高到池中的其他服务器的连接数。

NSX Advanced Load Balancer 将最少连接作为默认算法，因为通常在所有服务器正常运行时提供相等的分配，但适应于速度较慢或未正常运行的服务器。它非常适合长时间运行的连接和快速连接。

注：

出现问题（例如，拒绝所有新连接）的服务器的并发连接数可能为零，最符合条件以接收所有新连接。NSX Advanced Load Balancer 建议将最少连接算法与被动运行状况监控器结合使用，后者识别此类场景并进行调整。被动监控器将根据它返回到客户端的响应减少发送到服务器的新连接的百分比。

最少负载

新连接发送到负载最少的服务器，而无论该服务器具有多少个连接。例如，如果将需要 200 kB 响应的 HTTP 请求发送到一个服务器，并将生成 1kB 响应的第二个请求发送到一个服务器，该算法根据以前的请求估计发送 1kB 响应的服务器比仍在流式传输 200kB 的服务器的可用性高。这种想法是为了确保不会将小而快的请求排在很长的请求后面。该算法是 HTTP 特定的。对于非 HTTP 流量，将默认使用最少连接算法。

循环

新连接按顺序发送到池中的下一个符合条件的服务器。这种静态算法最适合基本负载测试，但不太适合生产流量，因为它没有考虑各个服务器的速度变化或周期性延迟。速度较慢的服务器仍会收到与性能更好的服务器一样多的连接。

在示例图表中，一个服务器导致端到端计时图中的应用程序响应时间大幅增加，如图中的橙色所示。通过从静态循环算法切换到动态 LB 算法（底部的蓝色配置事件图标），NSX Advanced Load Balancer 成功将连接传送到响应客户端速度更快的服务器，从而几乎消除了应用程序响应延迟。

最少任务

根据服务器反馈自适应地均衡负载。外部运行状况监控器有助于实施该算法，可以通过 NSX Advanced Load Balancer CLI 和 REST API 配置该算法。无法从 NSX Advanced Load Balancer UI 中配置最少任务算法。

使用 NSX Advanced Load Balancer CLI 进行配置

configure pool foo
lb_algorithm lb_algorithm_fewest_tasks
save

外部运行状况监控器可以将数据写入到 <hm_name>.<pool_name>.<ip>.<port>.tasks 文件中，以向算法反馈一个数字（例如，1-100）。该文件的每个输出将作为算法的反馈。可以调整作为反馈提供的数字范围和运行状况监控器发送间隔，以针对特定环境调整负载均衡算法行为。

例如，考虑具有 2 个后端服务器（s1 和 s2）的池 p1。假设运行状况监控器每 10 秒（发送间隔）发送一次请求，并发回反馈 100（高负载）和 10（低负载）。在 t1 时刻，为 s1 和 s2 分别设置了 100 个任务和 10 个任务。现在，如果您发送 200 个请求，前 90 个请求将发送到 s2，因为它具有 90 个额外的可用单元。接下来的 110 请求将平均发送到 s1 和 s2。在 t2 时刻（t1 + 10 秒），将向 s1 和 s2 发送外部运行状况监控器提供的新数据。

以下是外部运行状况监控器使用的示例脚本：

#!/usr/bin/python
import sys
import httplib
import os
conn = httplib.HTTPConnection(sys.argv[1]+':'+sys.argv[2])
conn.request("GET", "/")
r1 = conn.getresponse()
print r1
if r1.status == 200:
print r1.status, r1.reason ## Any output on the screen indicates SUCCESS for health monitor

try:
fname = sys.argv[0] + '.' + os.environ['POOL'] + '.' + sys.argv[1] + '.' + sys.argv[2] + '.tasks'
f = open(fname, "w")
try:
f.write('230') # Write a string to a file - instead of 230 - find the data from the curl output and feed it.
finally:
f.close()
except IOError:
pass

您可以使用 show pool <foo> detail 和 show pool <foo> server detail 命令，以查看有关发送到池中的服务器的连接数的详细信息。

加权比率

NSX Advanced Load Balancer 不包括专用的加权比率算法。相反，可以通过比率来实现权重，可以将比率应用于池中的任何服务器。也可以将比率与任何负载均衡算法结合使用。通过使用比率设置，每个服务器收到以静态方式调整比率的流量。如果一个服务器的比率为 1（默认值），另一个服务器的比率为 4，则设置为 4 的服务器收到的连接数是平常的 4 倍。例如，在使用最少连接时，一个服务器可能具有 100 个并发连接，而第二个服务器具有 400 个并发连接。