【官方文档】Nginx负载均衡学习笔记（三） TCP和UDP负载平衡官方参考文档

艾辉

　　本章介绍如何使用NGINX Plus和NGINX开放源代理和负载平衡TCP和UDP流量。

目录

• 介绍
  
• 先决条件
  
• 配置反向代理
  
• 配置TCP或UDP负载平衡
  
  
  
  • 选择负载平衡方法
    
  • 配置会话持久性
    
  
  
• 被动健康监控
  
• 主动健康监控
  
  
  
  • 怎么运行的
    
  • 先决条件
    
  • 基本配置
    
  • 微调健康检查
    
  • 使用匹配配置块进行微调健康检查
    
    
    
    • TCP的微调健康检查
      
    • UDP的微调健康检查
      
    
    
  
  
• 即时配置
  
  
  
  • 动态配置示例
    
  
  
• TCP和UDP负载平衡配置示例
  

介绍
　　负载平衡是指跨多个后端服务器有效分布网络流量。
　　在版本5和更高版本中，NGINX可以代理和负载平衡TCP流量。TCP（传输控制协议）是用于许多流行的应用和服务的协议，例如LDAP，MySQL和RTMP。
　　在版本9和更高版本中，NGINX可以代理和负载平衡UDP流量。UDP（用户数据报协议）是许多流行的非事务性应用程序的协议，例如DNS，syslog和RADIUS。
　　要加载平衡HTTP流量，请参阅HTTP负载平衡一文。

先决条件

• 最新的--with-streamNGINX 开源采用配置标志或最新的NGINX Plus构建（无需额外的构建步骤）
  
• 通过TCP或UDP进行通信的应用程序，数据库或服务
  
• 上游服务器，每个服务器运行应用程序，数据库或服务的同一实例
  

配置反向代理
　　首先，您需要配置反向代理，以便NGINX 可以将客户端的TCP连接或UDP数据报转发到上游组或代理服务器。
　　打开NGINX配置文件并执行以下步骤：
　　1、创建顶级stream {}块：
　　

stream {　　
...
　　
}
　　

　　2、server {}在顶层stream {}上下文中为每个虚拟服务器 定义一个或多个配置块。
　　3、在server {}每个服务器的配置块中，包括listen用于定义服务器侦听的IP地址和/或端口的指令。对于UDP流量，还包括udp参数。TCP是stream上下文的默认协议，因此没有tcp
　　参数listen指令：
　　

stream {　　server {
　　listen
12345;　　...
　　}
　　server {
　　listen
53 udp;　　...
　　}
　　...
　　
}
　　

　　4、包括proxy_pass用于定义代理服务器的指令或服务器转发流量的上游组：
　　

stream {　　server {
　　listen     
12345;　　

#TCP traffic will be proxied to the "stream_backend" upstream group　　proxy_pass stream_backend;
　　}
　　

　　server {
　　listen     
12346;　　

#TCP traffic will be proxied a proxied server　　proxy_pass backend.example.com:
12346;　　}
　　

　　server {
　　listen     
53 udp;　　

#UDP traffic will be proxied to the "dns_servers" upstream group　　proxy_pass dns_servers;
　　}
　　...
　　
}
　　

　　5、或者，如果您的代理服务器有多个网络接口，您可以配置NGINX选择一个源IP地址连接到上游服务器。如果NGINX后面的代理服务器配置为接受来自特定IP网络或IP地址范围的连接，这可能很有用。
　　指定proxy_bind必需的网络接口的伪指令和IP地址：
　　

stream {　　...
　　server {
　　listen     
127.0.0.1:12345;　　proxy_pass backend.example.com:
12345;　　proxy_bind
127.0.0.1:12345;　　}
　　
}
　　

　　6、或者，您可以调整两个内存缓冲区的大小，其中NGINX可以从客户端和上游连接中输入数据。如果存在小量的数据，则可以减少缓冲器，这可以节省存储器资源。如果存在大量数据，则可以增加缓冲区大小以减少套接字读/写操作的数量。一旦在一个连接上接收到数据，NGINX读取它并通过另一个连接转发它。缓冲区由指令proxy_buffer_size控制：
　　

stream {　　...
　　server {
　　listen            
127.0.0.1:12345;　　proxy_pass        backend.example.com:
12345;　　proxy_buffer_size 16k;
　　}
　　
}
　　


配置TCP或UDP负载平衡
　　1、创建一组服务器，或流量将负载平衡的上游组。upstream {}在顶层stream {}上下文中定义一个或多个配置块，并为上游组设置名称，例如，stream_backend对于TCP服务器和dns_serversUDP服务器：
　　

stream {　　upstream stream_backend {
　　...   
　　}
　　

　　upstream dns_servers {
　　...   
　　}
　　...
　　
}
　　

　　注意:确保上一个配置中proxy_pass引用了上游组的名称。
　　2、使用上游服务器填充上游组。在upstream {} 块中，server为每个上游服务器添加一个伪指令，指定其IP地址或主机名（可解析为多个IP地址）和必需的端口号。请注意，您不为每个服务器定义协议，因为它是由您在前面创建listen的server块中的伪指令中包含的参数为整个上游组定义的。
　　

stream {　　upstream stream_backend {
　　server backend1.example.com:
12345;　　server backend2.example.com:
12345;　　server backend3.example.com:
12346;　　...
　　}
　　upstream dns_servers {
　　server
192.168.136.130:53;　　server
192.168.136.131:53;　　...
　　}
　　...
　　
}
　　

　　配置上游组使用的负载分担方法。您可以指定以下方法之一：

• round-robin - 默认情况下，NGINX使用循环算法对流量进行负载均衡，将其顺序​​定向到配置的上游组中的服务器。因为它是默认方法，没有round-robin指令; 只需upstream在顶层stream上下文中创建一个配置块并添加上server一步中描述的指令。
  
• least_conn - NGINX选择当前活动连接数较少的服务器。
  
• least_time - NGINX选择平均延迟最小，活动连接数最少的服务器。最低平均延迟是基于以下参数中的哪一个包括在least_time指令上计算的：
  
  
  
  • connect - 连接到上游服务器的时间
    
  • first_byte - 接收数据的第一个字节的时间
    
  • last_byte - 从服务器接收完整响应的时间
    
  
  
• 　　
  
  upstream stream_backend {　　least_time first_byte;
  　　
  
  　　server backend1.example.com:
  12345;　　server backend2.example.com:
  12345;　　server backend3.example.com:
  12346;　　
  }
  　　
  
  
  
• hash - NGINX基于用户定义的密钥选择服务器，例如源IP地址（$remote_addr）：
  

　　

upstream stream_backend {　　hash $remote_addr;
　　

　　server backend1.example.com:
12345;　　server backend2.example.com:
12345;　　server backend3.example.com:
12346;　　
}
　　

　　所述散列负载平衡方法还用于配置会话持久性。由于散列函数基于客户端IP地址，来自给定客户端的连接始终传递到同一服务器，除非服务器关闭或以其他方式不可用。指定一个可选consistent参数以应用ketama一致性散列方法：
　　

hash $remote_addr consistent;　　

　　或者，对于每个上游服务器，指定服务器特定的参数，包括最大连接数，服务器权重等：
　　

upstream stream_backend {　　hash   $remote_addr consistent;
　　server backend1.example.com:
12345 weight=5;　　server backend2.example.com:
12345;　　server backend3.example.com:
12346 max_conns=3;　　
}
　　

　　upstream dns_servers {
　　least_conn;
　　server
192.168.136.130:53;　　server
192.168.136.131:53;　　...
　　}
　　

　　另一种方法是将流量代理到单个服务器而不是上游组。如果您通过主机名标识服务器，并将主机名配置为解析为多个IP地址，则NGINX使用循环算法在IP地址之间对流量进行负载平衡。在这种情况下，必须在配置参数中指定服务器的端口号，proxy_pass并且不能在IP地址或主机名之前指定协议：
　　

stream {　　...
　　server {
　　listen     
12345;　　proxy_pass backend.example.com:
12345;　　}
　　
}
　　


被动健康监控
　　如果尝试连接到上游服务器超时或导致错误，NGINX开源或NGINX Plus可以将服务器标记为不可用，并停止向其发送请求一段确定的时间。要定义NGINX认为上游服务器不可用的条件，请在指令中包含以下server参数

• fail_timeout - 指定数量的连接尝试必须失败，服务器被认为不可用的时间量。此外，在标记它之后，NGINX认为服务器不可用的时间量。
  
• max_fails - 在指定时间内发生的NGINX认为服务器不可用的失败尝试次数。
  

　　默认值为10秒和1尝试。因此，如果连接尝试在10秒内超时或至少出现一次失败，则NGINX将服务器标记为不可用10秒。该示例显示如何在30秒内将这些参数设置为2个故障：
　　

upstream stream_backend {　　server backend1.example.com:
12345 weight=5;　　server backend2.example.com:
12345 max_fails=2 fail_timeout=30s;　　server backend3.example.com:
12346 max_conns=3;　　
}
　　


主动健康监控
　　可以配置运行状况检查以测试各种故障类型。例如，NGINX Plus可以连续测试上游服务器的响应能力，避免出现故障的服务器。

怎么运行的
　　NGINX Plus向每个上游服务器发送特殊的健康检查请求，并检查满足特定条件的响应。如果无法建立与服务器的连接，则健康检查将失败，并认为服务器不正常。NGINX Plus不会将客户端连接代理到不正常的服务器。如果为一组服务器定义了几个运行状况检查，则任何一个检查的失败都足以使相应的服务器被视为不正常运行。

先决条件

• 您已在stream上下文中配置了上游服务器组，例如：
  

　　

stream {　　upstream stream_backend {
　　server backend1.example.com:
12345;　　server backend2.example.com:
12345;　　server backend3.example.com:
12345;　　}
　　
}
　　

• 您已配置将流量（在这种情况下为TCP连接）传递到服务器组的服务器：
  

　　

server {　　listen     
12345;　　proxy_pass stream_backend;
　　
}
　　


基本配置

• 指定共享内存区域 - 一个特殊区域，NGINX Plus工作进程共享关于计数器和连接的状态信息。将zone指令添加到上游服务器组，并指定区域名称和内存量：
  

　　

stream {　　upstream stream_backend {
　　

　　zone   stream_backend 64k;
　　server backend1.example.com:
12345;　　server backend2.example.com:
12345;　　server backend3.example.com:
12345;　　}
　　
}
　　

　　对上游组中的服务器启用运行状况检查。将health_check和health_check_timeout指令添加到代理到上游组的连接的服务器：
　　

server {　　listen        
12345;　　proxy_pass    stream_backend;
　　health_check;
　　health_check_timeout 5s;
　　
}
　　

　　该health_check指令启用运行状况检查功能，同时health_check_timeout覆盖proxy_timeout运行状况检查的值，对于运行状况检查，此超时需要显着缩短。
　　要对UDP流量启用运行状况检查，在health_check指令中指定udp启用UDP的运行状况检查的参数，以及包含用于验证服务器响应的测试match=的相应match块的名称的参数（请参阅微调UDP运行状况检查）：
　　

server {　　listen      
5053;　　proxy_pass   dns_servers;
　　health_check udp match
=dns;　　health_check_timeout 5s;
　　
}
　　


微调健康检查
　　默认情况下，NGINX Plus每5秒尝试连接一个上游服务器组中的每个服务器。如果无法建立连接，NGINX Plus认为健康检查失败，将服务器标记为不正常，并停止将客户端连接转发到服务器。
　　要更改默认行为，请在参数中包含health_check参数：

• interval - NGINX Plus发送健康检查请求的频率（以秒为单位）（默认为5秒）
  
• passes - 服务器必须响应以认为健康的连续运行状况检查的数量（默认值为1）
  
• fails - 服务器必须无法响应以认为不正常的连续运行状况检查数（默认值为1）
  
• 　　
  
  server {　　listen      
  12345;　　proxy_pass   stream_backend;
  　　health_check interval
  =10 passes=2 fails=3;　　
  }
  　　
  
  
  

　　在该示例中，TCP运行状况检查之间的时间增加到10秒，服务器在3连续失败的运行状况检查后被认为不健康，并且服务器需要通过2连续检查以再次被视为健康。
　　默认情况下，NGINX Plus会向块中server指令指定的端口发送运行状况检查消息upstream。您可以指定另一个端口进行运行状况检查，这在监视同一主机上许多服务的运行状况时尤其有用。要覆盖端口，请指定port指令的health_check参数：
　　

server {　　listen      
12345;　　proxy_pass   stream_backend;
　　health_check port
=8080;　　
}
　　

　　

uptream name {　　server
192.168.0.21:80;　　server
192.168.0.22:80;　　check interval
=3000 rise=2 fall=5 timeout=1000 type=http;　　}
　　

#上面配置的意思是，对name这个负载均衡条目中的所有节点，每个3秒检测一资，请求2资下正常则标记realserver状态为up,如果检测5次都失败，则标记realserver的状态为down，超时间为1秒。