[转帖]【官方文档】Nginx负载均衡学习笔记(三) TCP和UDP负载平衡官方参考文档

官方,文档,nginx,负载,均衡,学习,笔记,tcp,udp,负载平衡,参考 · 浏览次数 : 0

小编点评

**NGINX运行状况检查** NGINX运行状况检查用于监控服务器的健康状态并确保其正常运行。检查包括 TCP运行状况检查、UDP运行状况检查和块级检查。 **TCP运行状况检查** NGINX每5秒尝试连接一个上游服务器组中的每个服务器。如果无法建立连接,NGINX认为健康检查失败,并将服务器标记为不健康。 **UDP运行状况检查** NGINX每5秒尝试连接一个块的服务器,并检查其响应是否正确。如果服务器响应不正确,NGINX认为健康检查失败。 **块级检查** NGINX块级检查用于监控特定负载均衡条目的健康状态。检查包括对每个节点的健康检查和块级检查。 **运行状况检查参数** 运行状况检查参数用于指定检查的频率、端口、检查类型等。例如,您可以指定 health_check 参数来设置健康检查检查的频率。 **自定义端口检查** 您可以指定端口来覆盖默认端口的运行状况检查。例如,您可以指定 port 指令的 health_check 参数来设置端口 8080 的健康检查。

正文

本章介绍如何使用NGINX Plus和NGINX开放源代理和负载平衡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;
    </span>#TCP traffic will be proxied to the <span style="color:#800000;">"</span><span style="color:#800000;">stream_backend</span><span style="color:#800000;">"</span><span style="color:#000000;"> upstream group
    proxy_pass stream_backend;
}

server {
    listen     </span><span style="color:#800080;">12346</span><span style="color:#000000;">;

    </span>#<span style="color:#000000;">TCP traffic will be proxied a proxied server
    proxy_pass backend.example.com:</span><span style="color:#800080;">12346</span><span style="color:#000000;">;
}

server {
    listen     </span><span style="color:#800080;">53</span><span style="color:#000000;"> udp;

    </span>#UDP traffic will be proxied to the <span style="color:#800000;">"</span><span style="color:#800000;">dns_servers</span><span style="color:#800000;">"</span><span style="color:#000000;"> 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地址)和必需的端口号。请注意,您不为每个服务器定义协议,因为它是由您在前面创建listenserver块中的伪指令中包含的参数为整个上游组定义的。

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:</span><span style="color:#800080;">12345</span><span style="color:#000000;">;
    server backend2.example.com:</span><span style="color:#800080;">12345</span><span style="color:#000000;">;
    server backend3.example.com:</span><span style="color:#800080;">12346</span><span style="color:#000000;">;
    

    }


  • hash - NGINX基于用户定义的密钥选择服务器,例如源IP地址($remote_addr):

upstream stream_backend {
    hash $remote_addr;
server backend1.example.com:</span><span style="color:#800080;">12345</span><span style="color:#000000;">;
server backend2.example.com:</span><span style="color:#800080;">12345</span><span style="color:#000000;">;
server backend3.example.com:</span><span style="color:#800080;">12346</span><span style="color:#000000;">;

}

所述散列负载平衡方法还用于配置会话持久性由于散列函数基于客户端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 </span><span style="color:#800080;">192.168</span>.<span style="color:#800080;">136.130</span>:<span style="color:#800080;">53</span><span style="color:#000000;">;
    server </span><span style="color:#800080;">192.168</span>.<span style="color:#800080;">136.131</span>:<span style="color:#800080;">53</span><span style="color:#000000;">;
    ...
}</span></span></pre> 

另一种方法是将流量代理到单个服务器而不是上游组。如果您通过主机名标识服务器,并将主机名配置为解析为多个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:</span><span style="color:#800080;">12345</span><span style="color:#000000;">;
server backend2.example.com:</span><span style="color:#800080;">12345</span><span style="color:#000000;">;
server backend3.example.com:</span><span style="color:#800080;">12345</span><span style="color:#000000;">;

}
}

  • 您已配置将流量(在这种情况下为TCP连接)传递到服务器组的服务器:
server {
    listen     12345;
    proxy_pass stream_backend;
}

基本配置

  1. 指定共享内存区域 - 一个特殊区域,NGINX Plus工作进程共享关于计数器和连接的状态信息。zone指令添加到上游服务器组,并指定区域名称内存量
stream {
    upstream stream_backend {
    zone   stream_backend 64k; 
    server backend1.example.com:</span><span style="color:#800080;">12345</span><span style="color:#000000;">;
    server backend2.example.com:</span><span style="color:#800080;">12345</span><span style="color:#000000;">;
    server backend3.example.com:</span><span style="color:#800080;">12345</span><span style="color:#000000;">;

}
}

对上游组中的服务器启用运行状况检查。health_checkhealth_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秒。

 

文章知识点与官方知识档案匹配,可进一步学习相关知识
网络技能树首页概览23285 人正在系统学习中

与[转帖]【官方文档】Nginx负载均衡学习笔记(三) TCP和UDP负载平衡官方参考文档相似的内容:

[转帖]【官方文档】Nginx负载均衡学习笔记(三) TCP和UDP负载平衡官方参考文档

本章介绍如何使用NGINX Plus和NGINX开放源代理和负载平衡TCP和UDP流量。 目录 介绍先决条件配置反向代理配置TCP或UDP负载平衡被动健康监控 选择负载平衡方法配置会话持久性 主动健康监控 怎么运行的先决条件基本配置微调健康检查使用匹配配置块进行微调健康检查 TCP的微调健康检查UD

[转帖]NGINX官方文档[译]:HTTP负载均衡

负载均衡是一种优化资源利用率、提升最大吞吐量、减少延迟、提高系统容错率的常用技术。 要使用Nginx对一组服务器的HTTP流量进行负载均衡,首先需要使用upstream定义一组后端服务器(配置于http字段中),然后使用server对upstream组中的服务进行配置(同样配置于http字段中,注意

[转帖]NGINX的一些SEO优化常用配置

https://www.jianshu.com/p/e55073e5ebc7 官方文档:http://nginx.org/en/docs/ 常用模块: ngx_http_core_module ngx_http_rewrite_module ngx_http_proxy_module ngx_htt

[转帖]nginx上传模块—nginx upload module-

https://www.cnblogs.com/lidabo/p/4171515.html 一. nginx upload module原理 官方文档: http://www.grid.net.ru/nginx/upload.en.html Nginx upload module通过nginx服务来

[转帖]使用Prometheus和Grafana监控RabbitMQ集群 (使用RabbitMQ自带插件)

https://www.cnblogs.com/hahaha111122222/p/15683696.html 配置RabbitMQ集群 官方文档:https://www.rabbitmq.com/prometheus.html#quick-start 官方github地址:https://gith

[转帖]PostgreSQL | 学习一下Barman备份,防止删库跑路(一)

https://www.modb.pro/db/48181 PostgreSQL PRIP备份 PostgreSQL官方文档指定了以下三种备份方法,详见:https://www.postgresql.org/docs/current/backup.html 「SQL转储」,用pg_dump或pgdu

[转帖]VCSA证书过期问题处理

1. 故障现象 2022年10月25日,登陆VC报错。 按照报错信息,结合官方文档,判断为STS证书过期导致。 vCenter Server Appliance (VCSA) 6.5.x, 6.7.x or vCenter Server 7.0.x 在/var/log/vmware/vpxd-svc

[转帖]理解 postgresql.conf 的work_mem 参数配置

https://developer.aliyun.com/article/401250 简介: 主要是通过具体的实验来理解 work_mem 今天我们着重来了解 postgresql.conf 中的 work_mem 参数 官方文档描述如下: 指定在写入临时文件之前内部排序操作和散列表使用的内存量。

[转帖]高性能分布式对象存储——MinIO实战操作(MinIO扩容)

https://juejin.cn/post/7132852449244610574 一、前言 MinIO的基础概念和环境部署可以参考我之前的文章:高性能分布式对象存储——MinIO(环境部署) 二、客户端操作MinIO Client(mc) 官方文档:docs.min.io/docs/minio-

[转帖]tidb-系统内核调优及对比

一、背景 验证系统调优对性能的影响,用sysbench做了一些简单的测试,具体调整方法可见官方文档 二、特殊说明 1.透明大页查看 # 查看透明大页是否开启,[]在always处表示开启,[]在never处表示关闭 cat /sys/kernel/mm/transparent_hugepage/en