linux系统nginx四层负载均衡
四层负载均衡
七层负载均衡：识别域名，是http层
四层负载均衡：不识别域名，是tcp层(相当于端口转发)
四层负载均衡需要用到的模块
[ngx_stream_core_module]
# 官网推荐配置
worker_processes auto;
error_log /var/log/nginx/error.log info;
events {
worker_connections 1024;
}
stream {
upstream backend {
hash $remote_addr consistent;
server backend1.example.com:12345 weight=5;
server 127.0.0.1:12345 max_fails=3 fail_timeout=30s;
server unix:/tmp/backend3;
}
upstream dns {
server 192.168.0.1:53535;
server dns.example.com:53;
}
server {
listen 12345;
proxy_connect_timeout 1s;
proxy_timeout 3s;
proxy_pass backend;
}
server {
listen 127.0.0.1:53 udp reuseport;
proxy_timeout 20s;
proxy_pass dns;
}
server {
listen [::1]:12345;
proxy_pass unix:/tmp/stream.socket;
}
}
环境准备
| 服务器 | 外网IP | 内网IP | 安装服务 | 用途 |
|---|---|---|---|---|
| web01 | 10.0.0.7 | 172.16.1.7 | nginx | web服务器 |
| web02 | 10.0.0.8 | 172.16.1.8 | nginx | web服务器 |
| lb01 | 10.0.0.5 | 172.16.1.5 | nginx | 七层负载均衡 |
| lb02 | 10.0.0.6 | 172.16.1.6 | nginx | 七层负载均衡 |
| nfs | 10.0.0.31 | 172.16.1.31 | nginx | 四层负载均衡 |
web01配置
# 下载nginx
[root@web01 ~]# yum install -y nginx
# 编辑nginx配置文件
[root@web01 ~]# cd /etc/nginx/conf.d/
[root@web01 conf.d]# vim wzh.test.com.conf
server {
listen 80;
server_name wzh.test.com;
root /opt/wzh;
charset "utf-8";
access_log /var/log/nginx/test_access.log main;
index index.html index.htm;
}
# 检查语法
[root@web01 conf.d]# nginx -t
# 启动nginx并加入开机自启
[root@web01 ~]# systemctl start nginx
[root@web01 ~]# systemctl enable nginx
# 创建站点目录
[root@web01 conf.d]# mkdir /opt/wzh
[root@web01 conf.d]# cd /opt/wzh
# 编辑页面
[root@web01 wzh]# echo web01四层负载均衡测试 >index.html
# 域名解析
# 浏览器访问
web02配置
# 下载nginx
[root@web02 ~]# yum install -y nginx
# 编辑nginx配置文件
[root@web02 ~]# cd /etc/nginx/conf.d/
[root@web02 conf.d]# vim wzh.test.com.conf
server {
listen 80;
server_name wzh.test.com;
root /opt/wzh;
charset "utf-8";
access_log /var/log/nginx/test_access.log main;
index index.html index.htm;
}
# 检查语法
[root@web02 conf.d]# nginx -t
# 启动nginx并加入开机自启
[root@web02 ~]# systemctl start nginx
[root@web02 ~]# systemctl enable nginx
# 创建站点目录
[root@web02 conf.d]# mkdir /opt/wzh
[root@web02 conf.d]# cd /opt/wzh
# 编辑页面
[root@web02 wzh]# echo web02四层负载均衡测试 >index.html
# 域名解析
# 浏览器访问
lb01七层负载均衡配置
# 下载nginx
[root@lb01 ~]# yum install -y nginx
# 编辑proxy模块优化文件
[root@lb01 ~]# cd /etc/nginx/
[root@lb01 nginx]# vim proxy_params
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
proxy_connect_timeout 60s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;
proxy_buffering on;
proxy_buffers 8 4k;
proxy_buffer_size 4k;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
# 编辑配置文件
[root@lb01 nginx]# cd conf.d/
[root@lb01 conf.d]# vim wzh.test.com.conf
upstream wzh {
server 172.16.1.7;
server 172.16.1.8;
}
server {
listen 80;
server_name wzh.test.com;
location / {
proxy_pass http://wzh;
include proxy_params;
}
}
# 检查语法
[root@lb01 conf.d]# nginx -t
# 启动nginx并加入开机自启
[root@lb01 conf.d]# systemctl start nginx && systemctl enable nginx
# 域名解析
# 浏览器访问
刷新
lb02七层负载均衡配置
# 下载nginx
[root@lb02 ~]# yum install -y nginx
# 编辑proxy模块优化文件
[root@lb02 ~]# cd /etc/nginx/
[root@lb02 nginx]# vim proxy_params
proxy_set_header HOST $host;
proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
proxy_connect_timeout 60s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;
proxy_buffering on;
proxy_buffers 8 4k;
proxy_buffer_size 4k;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
# 编辑配置文件
[root@lb02 nginx]# cd conf.d/
[root@lb02 conf.d]# vim wzh.test.com.conf
upstream wzh {
server 172.16.1.7;
server 172.16.1.8;
}
server {
listen 80;
server_name wzh.test.com;
location / {
proxy_pass http://wzh;
include proxy_params;
}
}
# 检查语法
[root@lb02 conf.d]# nginx -t
# 启动nginx并加入开机自启
[root@lb01 conf.d]# systemctl start nginx && systemctl enable nginx
# 域名解析
# 浏览器访问
刷新
nfs四层负载均衡配置
# 下载nginx
[root@nfs ~]# yum install -y nginx
# 编辑主配置文件
[root@nfs nginx]# cat nginx.conf
# For more information on configuration, see:
# * Official English Documentation: http://nginx.org/en/docs/
# * Official Russian Documentation: http://nginx.org/ru/docs/
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
include /etc/nginx/stream/*.conf;
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
# Load modular configuration files from the /etc/nginx/conf.d directory.
# See http://nginx.org/en/docs/ngx_core_module.html#include
# for more information.
include /etc/nginx/conf.d/*.conf;
# server {
# listen 80 default_server;
# listen [::]:80 default_server;
# server_name _;
# root /usr/share/nginx/html;
#
# # Load configuration files for the default server block.
# include /etc/nginx/default.d/*.conf;
#
# location / {
# }
#
# error_page 404 /404.html;
# location = /40x.html {
# }
#
# error_page 500 502 503 504 /50x.html;
# location = /50x.html {
# }
# }
#
# Settings for a TLS enabled server.
#
# server {
# listen 443 ssl http2 default_server;
# listen [::]:443 ssl http2 default_server;
# server_name _;
# root /usr/share/nginx/html;
#
# ssl_certificate "/etc/pki/nginx/server.crt";
# ssl_certificate_key "/etc/pki/nginx/private/server.key";
# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 10m;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;
#
# # Load configuration files for the default server block.
# include /etc/nginx/default.d/*.conf;
#
# location / {
# }
#
# error_page 404 /404.html;
# location = /40x.html {
# }
#
# error_page 500 502 503 504 /50x.html;
# location = /50x.html {
# }
# }
}
# 创建include目录
[root@nfs nginx]# mkdir /etc/nginx/stream/
# 编辑配置文件
[root@nfs nginx]# !v
vim stream/wzh.test.com.conf
stream{
upstream lb_07 {
server 172.16.1.5:80;
server 172.16.1.6:80;
}
server {
listen 80;
proxy_pass lb_07;
proxy_connect_timeout 3s;
proxy_timeout 3s;
}
}
# 检测语法
[root@nfs nginx]# nginx -t
# 启动并加入开机自启
[root@nfs nginx]# systemctl start nginx && systemctl enable nginx
# 域名解析
# 浏览器访问
刷新
修改端口
# web 01
[root@web01 nginx]# vim conf.d/wzh.test.com.conf
server {
listen 8007;
server_name wzh.test.com;
root /opt/wzh;
charset "utf-8";
access_log /var/log/nginx/test_access.log main;
index index.html index.htm;
}
[root@web01 nginx]# nginx -t
[root@web01 nginx]# systemctl reload nginx
# web 02
[root@web02 conf.d]# vim wzh.test.com.conf
server {
listen 8008;
server_name wzh.test.com;
root /opt/wzh;
charset "utf-8";
access_log /var/log/nginx/test_access.log main;
index index.html index.htm html;
}
# 检测配置文件
[root@web02 conf.d]# nginx -t
# 重新加载
[root@web02 conf.d]# systemctl reload nginx
# lb01
[root@lb01 conf.d]# vim wzh.test.com.conf
upstream wzh {
server 172.16.1.7:8007;
server 172.16.1.8:8008;
}
server {
listen 8005;
server_name wzh.test.com;
location / {
proxy_pass http://wzh;
include proxy_params;
}
}
[root@lb01 conf.d]# nginx -t
[root@lb01 conf.d]# systemctl reload nginx
# lb02
[root@lb02 conf.d]# vim wzh.test.com.conf
upstream wzh {
server 172.16.1.7:8007;
server 172.16.1.8:8008;
}
server {
listen 8006;
server_name wzh.test.com;
location / {
proxy_pass http://wzh;
include proxy_params;
}
}
[root@lb02 conf.d]# nginx -t
[root@lb02 conf.d]# systemctl reload nginx
# nfs
[root@nfs nginx]# !v
vim stream/wzh.test.com.conf
stream{
upstream lb_07 {
server 172.16.1.5:8005;
server 172.16.1.6:8006;
}
server {
listen 80;
proxy_pass lb_07;
proxy_connect_timeout 3s;
proxy_timeout 3s;
}
}
[root@nfs nginx]# nginx -t
[root@nfs nginx]# systemctl reload nginx
# 浏览器访问
刷新
理论转载IP
*【负载均衡概念】*
负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。负载均衡有两方面的含义：首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。
简单来说就是：其一是将大量的并发处理转发给后端多个节点处理，减少工作响应时间；其二是将单个繁重的工作转发给后端多个节点处理，处理完再返回给负载均衡中心，再返回给用户。目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。
【四层和七层负载均衡】
根据OSI模型可将负载均衡分为二层负载均衡（一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应），三层负载均衡（一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应），四层负载均衡（在三次负载均衡的基础上，用 ip+port 接收请求，再转发到对应的机器），七层负载均衡（根据虚拟的url或是IP，主机名接收请求，再转向相应的处理服务器）。下面介绍最常见的四层和七层负载均衡：
1、四层负载均衡
四层的负载均衡就是基于IP+端口的负载均衡：在三层负载均衡的基础上，通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。
对应的负载均衡器称为四层交换机（L4 switch），主要分析IP层及TCP/UDP层，实现四层负载均衡。此种负载均衡器不理解应用协议（如HTTP/FTP/MySQL等等），常见例子有：LVS，F5。
2、七层负载均衡
七层的负载均衡就是基于虚拟的URL或主机IP的负载均衡：在四层负载均衡的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。
对应的负载均衡器称为七层交换机（L7 switch），除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息，实现七层负载均衡。此种负载均衡器能理解应用协议，常见例子有： haproxy，MySQL Proxy。
【四层和七层的区别】
1、技术原理上的区别
所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。
所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。
2、应用场景的需求
七层应用负载的好处，是使得整个网络更"智能化"。参考这篇利用负载均衡优化和加速HTTP应用，就可以基本上了解这种方式的优势所在。例如访问一个网站的用户流量，可以通过七层的方式，将对图片类的请求转发到特定的图片服务器并可以使用缓存技术；将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。当然这只是七层应用的一个小案例，从技术原理上，这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改，极大的提升了应用系统在网络层的灵活性。很多在后台，例如Nginx或者Apache上部署的功能可以前移到负载均衡设备上，例如客户请求中的Header重写，服务器响应中的关键字过滤或者内容插入等功能。
另外一个常常被提到功能就是安全性。网络中最常见的SYN Flood攻击，即黑客控制众多源客户端，使用虚假IP地址对同一目标发送SYN攻击，通常这种攻击会大量发送SYN报文，耗尽服务器上的相关资源，以达到Denial of Service(DoS)的目的。从技术原理上也可以看出，四层模式下这些SYN攻击都会被转发到后端的服务器上；而七层模式下这些SYN攻击自然在负载均衡设备上就截止，不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略，过滤特定报文，例如SQL Injection等应用层面的特定攻击手段，从应用层面进一步提高系统整体安全。
现在的7层负载均衡，主要还是着重于应用HTTP协议，所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其他TCP应用，例如基于C/S开发的ERP等系统。
3、七层应用需要考虑的问题
（1）是否真的必要。七层应用的确可以提高流量智能化，同时必不可免的带来设备配置复杂，负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时需要考虑四层七层同时应用的混杂情况。
（2）是否真的可以提高安全性。例如SYN Flood攻击，七层模式的确将这些流量从服务器屏蔽，但负载均衡设备本身要有强大的抗DDoS能力，否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。
（3）是否有足够的灵活度。七层应用的优势是可以让整个应用的流量智能化，但是负载均衡设备需要提供完善的七层功能，满足客户根据不同情况的基于应用的调度。最简单的一个考核就是能否取代后台Nginx或者Apache等服务器上的调度功能。能够提供一个七层应用开发接口的负载均衡设备，可以让客户根据需求任意设定功能，才真正有可能提供强大的灵活性和智能性。
4、总体对比
（1）智能性
七层负载均衡由于具备OIS七层的所有功能，所以在处理用户需求上能更加灵活，从理论上讲，七层模型能对用户的所有跟服务端的请求进行修改。例如对文件header添加信息，根据不同的文件类型进行分类转发。四层模型仅支持基于网络层的需求转发，不能修改用户请求的内容。
（2）安全性
七层负载均衡由于具有OSI模型的全部功能，能更容易抵御来自网络的攻击；四层模型从原理上讲，会直接将用户的请求转发给后端节点，无法直接抵御网络攻击。
（3）复杂度
四层模型一般比较简单的架构，容易管理，容易定位问题；七层模型架构比较复杂，通常也需要考虑结合四层模型的混用情况，出现问题定位比较复杂。
（4）效率比
四层模型基于更底层的设置，通常效率更高，但应用范围有限；七层模型需要更多的资源损耗，在理论上讲比四层模型有更强的功能，现在的实现更多是基于http应用。
负载均衡算法
（1）轮循均衡（Round Robin）：每一次来自网络的请求轮流分配给内部中的服务器，从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。
（2）权重轮循均衡（Weighted Round Robin）：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是 3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。
（3）随机均衡（Random）：把来自网络的请求随机分配给内部中的多个服务器。
（4）权重随机均衡（Weighted Random）：此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。
（5）响应速度均衡（Response Time）：负载均衡设备对内部各服务器发出一个探测请求（例如Ping），然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与服务器间的最快响应时间。
（6）最少连接数均衡（Least Connection）：客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。
（7）处理能力均衡：此种均衡算法将把服务请求分配给内部中处理负荷（根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成）最轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七层（应用层）负载均衡的情况下。
（8）DNS响应均衡（Flash DNS）：在Internet上，无论是HTTP、FTP或是其它的服务请求，客户端一般都是通过域名解析来找到服务器确切的IP地址的。在此均衡算法下，分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在同一时间内把此域名解析成各自相对应服务器的IP地址（即与此负载均衡设备在同一位地理位置的服务器的IP地址）并返回给客户端，则客户端将以最先收到的域名解析IP地址来继续请求服务，而忽略其它的IP地址响应。在种均衡策略适合应用在全局负载均衡的情况下，对本地负载均衡是没有意义的。
【负载均衡实施要素】
1、性能
性能是我们在引入均衡方案时需要重点考虑的问题，但也是一个最难把握的问题。衡量性能时可将每秒钟通过网络的数据包数目做为一个参数，另一个参数是均衡方案中服务器群所能处理的最大并发连接数目，但是，假设一个均衡系统能处理百万计的并发连接数，可是却只能以每秒2个包的速率转发，这显然是没有任何作用的。性能的优劣与负载均衡设备的处理能力、采用的均衡策略息息相关，并且有两点需要注意：一、均衡方案对服务器群整体的性能，这是响应客户端连接请求速度的关键；二、负载均衡设备自身的性能，避免有大量连接请求时自身性能不足而成为服务瓶颈。有时我们也可以考虑采用混合型负载均衡策略来提升服务器群的总体性能，如DNS负载均衡与NAT负载均衡相结合。另外，针对有大量静态文档请求的站点，也可以考虑采用高速缓存技术，相对来说更节省费用，更能提高响应性能；对有大量ssl/xml内容传输的站点，更应考虑采用ssl/xml加速技术。
2、可扩展性
IT技术日新月异，一年以前最新的产品，现在或许已是网络中性能最低的产品；业务量的急速上升，一年前的网络，现在需要新一轮的扩展。合适的均衡解决方案应能满足这些需求，能均衡不同操作系统和硬件平台之间的负载，能均衡HTTP、邮件、新闻、代理、数据库、防火墙和 Cache等不同服务器的负载，并且能以对客户端完全透明的方式动态增加或删除某些资源。
3、灵活性
均衡解决方案应能灵活地提供不同的应用需求，满足应用需求的不断变化。在不同的服务器群有不同的应用需求时，应有多样的均衡策略提供更广泛的选择。
4、可靠性
在对服务质量要求较高的站点，负载均衡解决方案应能为服务器群提供完全的容错性和高可用性。但在负载均衡设备自身出现故障时，应该有良好的冗余解决方案，提高可靠性。使用冗余时，处于同一个冗余单元的多个负载均衡设备必须具有有效的方式以便互相进行监控，保护系统尽可能地避免遭受到重大故障的损失。
5、易管理性
不管是通过软件还是硬件方式的均衡解决方案，我们都希望它有灵活、直观和安全的管理方式，这样便于安装、配置、维护和监控，提高工作效率，避免差错。在硬件负载均衡设备上，目前主要有三种管理方式可供选择：一、命令行接口（CLI：Command Line Interface），可通过超级终端连接负载均衡设备串行接口来管理，也能telnet远程登录管理，在初始化配置时，往往要用到前者；二、图形用户接口（GUI：Graphical User Interfaces），有基于普通web页的管理，也有通过Java Applet 进行安全管理，一般都需要管理端安装有某个版本的浏览器；三、SNMP（Simple Network Management Protocol，简单网络管理协议）支持，通过第三方网络管理软件对符合SNMP标准的设备进行管理。
浙公网安备 33010602011771号