« 上一篇下一篇 »

什么是Nginx服务器四层负载均衡?如何实现服务器四层负载均衡?

   服务器的均衡负载是不少运维朋友常遇到的问题,当一台服务器的单位时间内的访问量越大时,服务器压力就越大,大到超过自身承受能力时,服务器就会崩溃.为了避免服务器崩溃,让用户有更好的体验,我们通过负载均衡的方式来分担服务器压力,这篇文章主要给大家介绍了关于Nginx四层负载均衡配置的相关资料,需要的朋友可以参考下

一、四层负载均衡介绍

什么是四层负载均衡

所谓四层负载均衡,也就是主要通过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。

以常见的TCP为例,负载均衡设备在接收到第一个来自客户端的SYN 请求时,选择一个最佳的服务器,并对报文中目标IP地址进行修改(改为后端服务器IP),直接转发给该服务器。TCP的连接建立,即三次握手是客户端和服务器直接建立的,负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下,为保证服务器回包可以正确返回给负载均衡设备,在转发报文的同时可能还会对报文原来的源地址进行修改。

 

 

应用场景

1.四层+七层来做负载均衡,四层可以保证七层的负载均衡的高可用性;

2.负载均衡可以做端口转发

3.数据库读写分离

四层负载均衡特点

1.四层负载均衡仅能转发TCP/IP协议、UDP协议、通常用来转发端口,如:tcp/22、udp/53;

2.四层负载均衡可以用来解决七层负载均衡端口限制问题;(七层负载均衡最大使用65535个端口号)

3.四层负载均衡可以解决七层负载均衡高可用问题;(多台后端七层负载均衡能同时的使用)

4.四层的转发效率比七层的高得多,但仅支持tcp/ip协议,不支持http和https协议;

5.通常大并发场景通常会选择使用在七层负载前面增加四层负载均衡。

二、四层负载均衡环境搭建

环境准备

主机IP身份
lb4172.16.1.6,10.0.0.6四层负载均衡
lb01172.16.1.4,10.0.0.4七层负载均衡
lb02172.16.1.5,10.0.0.5七层负载均衡

lb4和lb02搭建Nginx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
# 配置yum源
[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
 
# 安装Nginx
[root@lb02 ~]# yum install nginx -y
[root@lb4 ~]# yum install nginx -y
 
# 创建用户
[root@lb02 ~]# groupadd www -g 666 && useradd www -u 666 -g 666 -s /sbin/nologin -M
[root@lb4 ~]# groupadd www -g 666 && useradd www -u 666 -g 666 -s /sbin/nologin -M
 
# 配置nginx
[root@lb02 ~]# vim /etc/nginx/nginx.conf
user  www;
[root@lb4 ~]# vim /etc/nginx/nginx.conf
user  www;
 
# 启动Nginx
[root@lb4 ~]# systemctl start nginx && systemctl enable nginx && systemctl status nginx
[root@lb02 ~]# systemctl start nginx && systemctl enable nginx && systemctl status nginx

将lb01配置同步到lb02

1
2
[root@lb01 ~]# scp /etc/nginx/conf.d/* 172.16.1.5:/etc/nginx/conf.d/
[root@lb01 ~]# scp /etc/nginx/proxy_params 172.16.1.5:/etc/nginx/

测试lb02的负载均衡

1
2
3
4
[root@lb02 ~]# nginx -t && systemctl restart nginx
 
#配置hosts测试
10.0.0.5 linux.wp.com

三、配置四层负载均衡

四层负载均衡语法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Syntax: stream { ... }
Default:    —
Context:    main
 
#示例:四层负载均衡stream模块跟http模块在同一级别,不能配置在http里面
stream {
    upstream backend {
        server backend1.example.com:12345 weight=5;
        server 127.0.0.1:12345            max_fails=3 fail_timeout=30s;
    }
 
    server {
        listen 12345;
        proxy_connect_timeout 1s;
        proxy_timeout 3s;
        proxy_pass backend;
    }
}

配置nginx主配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@lb4 ~]# vim /etc/nginx/nginx.conf
#注释http层所有内容
user  www;
worker_processes  1;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
}
#添加一个包含文件
include /etc/nginx/conf.c/*.conf;
#http {
#    include       /etc/nginx/mime.types;
#    default_type  application/octet-stream;
#    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;
#    keepalive_timeout  65;
#    #gzip  on;
#    include /etc/nginx/conf.d/*.conf;
#}

配置四层负载均衡

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#创建目录
[root@lb4 ~]# mkdir /etc/nginx/conf.c
 
#配置
[root@lb4 ~]# vim /etc/nginx/conf.c/linux.lb4.com.conf
stream {
    upstream lbserver {
        server 10.0.0.4:80;
        server 10.0.0.5:80;
    }
 
    server {
        listen 80;
        proxy_pass lbserver;
        proxy_connect_timeout 1s;
        proxy_timeout 3s;
    }
}
 
# 启动Nginx
[root@lb4 ~]# nginx -t && systemctl start nginx
 
# 配置hosts访问
10.0.0.6 linux.lb4.com

四层负载均衡配置日志

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1
#四层负载均衡是没有access的日志的,因为在nginx.conf的配置中,access的日志格式是配置在http下的,而四层负载均衡配置是在http以外的;
 
#如果需要日志则需要配置在stream下面
[root@lb4 ~]# vim /etc/nginx/conf.c/linux.lb4.com.conf
stream {
    log_format  proxy '$remote_addr $remote_port - [$time_local] $status $protocol '
                  '"$upstream_addr" "$upstream_bytes_sent" "$upstream_connect_time"';
    access_log /var/log/nginx/proxy.log proxy;
 
    upstream lbserver {
        server 10.0.0.4:80;
        server 10.0.0.5:80;
    }
 
    server {
        listen 80;
        proxy_pass lbserver;
        proxy_connect_timeout 1s;
        proxy_timeout 3s;
    }
}
 
#查看所有web服务器日志
[root@web01 ~]# tail -f /var/log/nginx/access.log
[root@web02 ~]# tail -f /var/log/nginx/access.log

四、四层负载端口转发

请求负载均衡的5555端口,跳转到web01的22端口

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
3
#简单配置
stream {
    server {
        listen 5555;
        proxy_pass 172.16.1.7:22;
    }
}
 
#一般配置
stream {
    upstream ssh_7 {
        server 10.0.0.7:22;
    }
 
    server {
        listen 5555;
        proxy_pass ssh_7;
    }
}
 
# 测试
[D:\~]$ ssh root@10.0.0.6:5555
成功跳转

请求负载均衡的6666端口,跳转至172.16.1.51:3306

1
2
3
4
5
6
7
8
9
10
stream {
    upstream db_51 {
        server 172.16.1.51:3306;
    }
     
    server {
        listen 6666;
        proxy_pass db_51;
    }
}

数据库从库的负载均衡

1
2
3
4
5
6
7
8
9
10
11
125
stream {
    upstream dbserver {
        server 172.16.1.51:3306;
        server 172.16.1.52:3306;
        server 172.16.1.53:3306;
        server 172.16.1.54:3306;
        server 172.16.1.55:3306;
        server 172.16.1.56:3306;
    }
     
    server {
        listen 5555;
        proxy_pass dbserver;
    }
}

总结

如果一台服务器,反复失败(超过了max_fails或者fail_timeout配置的参数),Nginx也会踢掉这台服务器。服务器被踢掉60秒后,Nginx会偶尔尝试重连它,检测它是否恢复正常。如果服务器恢复正常,Nginx将它加回到upstream组内,缓慢加大连接请求的比例。

之所"缓慢加大",因为通常一个服务都有"热点数据",也就是说,80%以上甚至更多的请求,实际都会被阻挡在"热点数据缓存"中,真正执行处理的请求只有很少的一部分。在机器刚刚启动的时候,"热点数据缓存"实际上还没有建立,这个时候爆发性地转发大量请求过来,很可能导致机器无法"承受"而再次挂掉。以mysql为例子,我们的mysql查询,通常95%以上都是落在了内存cache中,真正执行查询的并不多。

其实,无论是单台机器或者一个集群,在高并发请求场景下,重启或者切换,都存在这个风险,解决的途径主要是两种:

1)请求逐步增加,从少到多,逐步积累热点数据,最终达到正常服务状态。

2)提前准备好"常用"的数据,主动对服务做"预热",预热完成之后,再开放服务器的访问。