负载均衡
1.负载均衡和代理的区别
Nginx负载均衡与Nginx代理不同地方在于,Nginx代理仅代理一台服务器,而Nginx负载均衡则是将客户端请求代理转发至一组upstream虚拟服务池
2.实现负载均衡
2.1一个简单的实现效果进行观看
- 准备
3台机器
lb 10.0.0.5 172.16.1.5
web01 172.16.1.7
web02 172.16.1.8 - 配置webserver
web2和web1配置相同复制一份
[root@web01 ~]# cat /etc/nginx/conf.d/node.wyk.com.conf
server {
listen 80;
server_name node.wyk.com;
root /node;
location / {
index index.html;
}
}
[root@web01 ~]# nginx -t
[root@web01 ~]# systemctl restart nginx
[root@web01 ~]# mkdir /node
[root@web01 ~]# echo "Web01..." > /node/index.html
- 请求测试
[root@lb01 ~]# curl -H Host:node.wyk.com 172.16.1.7
Web01...
[root@lb01 ~]# curl -H Host:node.wyk.com 172.16.1.8
Web02...
- 配置负载均衡
[root@lb01 ~]# cat /etc/nginx/conf.d/proxy_node.wyk.com.conf
#定义负载均衡资源池名称
upstream node {
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name node.wyk.com;
location / {
proxy_pass http://node;
include proxy_params;
}
}
2.2.将网站知乎和博客接入到负载均衡
- 环境准备
两台web服务器:
172.16.1.7 blog.wyk.com zh.wyk.com
172.16.1.8 blog.wyk.com zh.wyk.com
负载均衡服务器:
10.0.0.5 blog.wyk.com zh.wyk.com - 负载均衡配置
[root@lb01 ~]# cat /etc/nginx/conf.d/proxy_blog.wyk.com.conf
upstream blog {
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name blog.wyk.com;
location / {
proxy_pass http://blog;
include proxy_params;
}
}
[root@lb01 ~]# cat /etc/nginx/conf.d/proxy_zh.wyk.com.conf
upstream zh {
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name zh.wyk.com;
location / {
proxy_pass http://zh;
include proxy_params;
}
}
#注意这里的include proxy_params是引入的配置
[root@lb01 ~]# cat /etc/nginx/proxy_params
proxy_http_version 1.1;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 30;
proxy_send_timeout 60;
proxy_read_timeout 60;
proxy_buffering on;
proxy_buffer_size 32k;
proxy_buffers 4 128k;
3.调度算法
调度算法 概述
轮询 按时间顺序逐一分配到不同的后端服务器(默认)
weight 加权轮询,weight值越大,分配到的访问几率越高
ip_hash 每个请求按访问IP的hash结果分配,这样来自同一IP的固定访问一个后端服务器
least_conn 将请求传递到活动连接数最少的服务器。
- ip_hash:
解决:会话保持的问题
缺陷:会造成后端某一个节点压力过大,而其他节点没什么压力。 ( NAT )
1.轮询调度算法
默认就是轮询机制,定义了一个load_pass的地址池
upstream load_pass {
server 10.0.0.7:80;
server 10.0.0.8:80;
}
2.加权轮询具体配置
0.7访问五次才会到0.8
upstream load_pass {
server 10.0.0.7:80 weight=5;
server 10.0.0.8:80;
}
3.ip_hash具体配置, 不能和weight一起使用
#如果客户端都走相同代理, 会导致某一台服务器连接过多
upstream load_pass {
ip_hash;
server 10.0.0.7:80 weight=5;
server 10.0.0.8:80;
}
4.后端Web服务器在前端Nginx负载均衡调度中的状态
状态 概述
down 当前的server暂时不参与负载均衡 相当于注释
backup 预留的备份服务器
max_fails 允许请求失败的次数
fail_timeout 经过max_fails失败后, 服务暂停时间
max_conns 限制最大的接收连接数
#允许在十秒内请求失败3次,当失败后会掉到另一个节点
upstream node {
server 172.16.1.7:80 max_fails=3 fail_timeout=10s;
server 172.16.1.8:80;
#限制节点最多连接数为2000
upstream node {
server 172.16.1.7:80 max_fails=3 fail_timeout=10s max_conns=2000;
server 172.16.1.8:80;
- keepalive保持长连接可以不用三次握手,直接连接
[root@lb01 ~]# cat /etc/nginx/conf.d/proxy_node.wyk.com.conf
#定义负载均衡资源池名词
upstream node {
server 172.16.1.7:80 max_fails=3 fail_timeout=10s;
server 172.16.1.8:80 max_fails=3 fail_timeout=10s;
keepalive 16; #单个节点空闲连接数
keepalive_timeout 100s; #连接超时时间
}
server {
listen 80;
server_name node.wyk.com;
location / {
proxy_pass http://node;
proxy_set_header connection ""; #将东西置空和keepalive一起使用可以将这个放到proxy_params文件中
include proxy_params;
}
}
linux客户端:
[root@web01 ~]# echo "10.0.0.5 node.wyk.com" >> /etc/hosts
[root@web01 ~]# yum install httpd-tools -y
[root@web01 ~]# ab -n 10000 -c200 -k http://node.oldxu.com/ #模拟1000w个连接
负载均衡节点通过netstat查看ESTABILED的状态
[root@lb01 ~]# netstat -an | grep ESTABLISHED
- proxy_next_upstream重置
企业案例:使用nginx负载均衡时,如何将后端请求超时的服务器流量平滑的切换到另一台上。如果后台服务连接超时,Nginx是本身是有机制的,如果出现一个节点down掉的时候,Nginx会更据你具体负载均衡的设置,将请求转移到其他的节点上,但是,如果后台服务连接没有down掉,但是返回错误异常码了如:504、502、500,应该如何处理。
可以在负载均衡添加如下配置proxy_next_upstream http_500 | http_502 | http_503 | http_504 |http_404;意思是,当其中一台返回错误码404,500…等错误时,可以分配到下一台服务器程序继续处理,提高平台访问成功率。
[root@lb01 ~]# cat /etc/nginx/conf.d/proxy_blog.wyk.com.conf
upstream blog {
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name blog.wyk.com;
location / {
proxy_pass http://blog;
include proxy_params;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
}
}