nginx-7+4层负载均衡

7层负载均衡

https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/ --》详细版本

http://nginx.org/en/docs/http/load_balancing.html --》精简版本

算法: method --》方法
backend --》后端
nginx做负载均衡的方法有哪些?
1.Round Robin --》RR 轮询 、轮叫 --》默认的方法

server weights   服务器的权重
server backend1.example.com      weight=5;  --》加权轮询---》weight值越大,负载均衡器在分配任何的时候会多分任务给它  默认值为1

upstream myapp1 {
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
server backend1.example.com weight=5;
}

2.Least Connections 最小连接数
upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
}

3.ip-hash

是基于客户机的ip地址来转发到后端真实服务器的
相同的ip地址的所有的请求都会发送到同一台的真实服务器上
购物:---》登陆的信息,购物车里的信息----》session会话信息 

upstream myapp1 {
ip_hash;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
4. generic hash 可以根据uri来做调度

upstream backend {
hash $request_uri consistent;
server backend1.example.com;
server backend2.example.com;
}

cookie和session的区别?

cookie和session都是用来保存信息的方法和技术。
cookie和session都理解为一个容器,里面用来装一些用户的信息

cookie是存放在客户端的浏览器里
session是存储在服务器里的

HTTP是一种无状态的协议,为了分辨链接是谁发起的,就需要我们自己去解决这个问题。

无状态 --》如何理解?
区别不了,你是新的连接还是旧的连接,每次连接都是全新的对待,每次连接没有区别

HTTP是一种无状态的协议,为了分辨链接是谁发起的,就需要我们自己去解决这个问题。不然有些情况下即使是同一个网站我们每打开一个页面也都要登录一下。而Session和Cookie就是为解决这个问题而提出来的两个机制。

https://www.cnblogs.com/wswang/p/6062461.html

Hash,一般翻译做散列、杂凑,或音译为哈希,是把任意长度的输入(又叫做预映射pre-image)通过散列算法变换成固定长度的输出,该输出就是散列值.

lihu
lidahu
tanzikun
tanxiaokun

#将任意长度的名字取第1个字母和最后一个字母,拼接成一个字符串,输出
def sc_fun(name):
hash_msg = name[0] + name[-1]
reture hash_msg

[root@localhost ~]# cat sc.py
def sc_fun(name):
hash_msg = name[0] + name[-1]
return hash_msg

sc_name = input(“请输入你的名字的汉语拼音:”)
print(f"你的名字的hash值是{sc_fun(sc_name)}")
[root@localhost ~]#

========
负载均衡器:自己不需要提供web服务,它只是将web请求转发到后端的real server

1.定义负载均衡器
定义在http语句块里
#定义一个负载均衡器名字叫sanchuang 调度器
#upstream 上游
upstream sanchuang {
server 192.168.0.19;
server 192.168.0.20;
#server 192.168.0.25;
#server 192.168.0.200;
}

2.将访问请求转发到负载均衡器

server {
    listen       80;
    server_name  www.sc.com;
    location / {
        proxy_pass http://sanchuang;
        #health_check;
    }

休息20分钟
15:28 ~ 15:48
问题:
后端的real server知道前端真正的用户的ip地址?
答案:不知道,因为LB在转发数据的时候,将ip包里的源ip修改为自己的ip地址,目的ip地址也修改为选中的一个后端的real
server 的ip地址

 客户机是不知道LB后端有多少台real server的,也不知道real server的ip地址
 暴露在外面的只是LB的ip地址

客户端---》LB-->real server   real server -->LB--->客户机



后端的real server不知道前端真正访问的ip地址,只是知道负载均衡的ip地址,如何让后端的real server知道前端真正的用户的ip地址?

[root@nginx-server-1 html]# yum install tcpdump -y

[root@nginx-server-1 html]# tcpdump -i ens33 tcp and port 80 -nn

-i ens33 抓ens33网卡的数据 interface
tcp 协议
port 80 端口号是80
dst port 80 目的端口
src port 80 源端口
and 多个条件组合

-nn 以数字的形式显示

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                 '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';
nginx的日志得到的内容都是从nginx这个进程里获取的,上面的这些都是nginx内部的变量

这些变量的初始值都为空,然后会去读取http的请求报文和响应报文然后从新赋值给这些变量

问题:
后端的real server不知道前端真正访问的ip地址,只是知道负载均衡的ip地址,如何让后端的real server知道前端真正的用户的ip地址?

1.在反向代理服务器(负载均衡服务器上)对http协议的头部信息进行修改

 location / {
        proxy_pass http://sanchuang;
        proxy_set_header   X-Real-IP        $remote_addr;  将nginx内部的remote_addr这个变量的值,赋值给X-Real-IP这个变量,X-Real-IP这个变量会在http协议的请求报文里添加一个X-Real-IP的字段,后端的real server 服务器上的nginx就可以读取这个字段的值
        X-Real-IP  这个变量名可以自己定义,随便取名,后面引用的时候,不区分大小写



        #proxy_set_header 指令的作用就是告诉nginx去修改http协议的头部信息,增加一个字段
		proxy_set_header   Host             $host;    #是http协议里的host关键字 对应Host这个变量

    }

前面的修改了http头部信息的字段,在后面的nginx服务器里获取的时候,需要在变量名前面加HTTP

  2.在后端real server的nginx上修改日志的格式,添加$HTTP_X_REAL_IP 字段和$HTTP_Host

log_format  main  '$HTTP_X_REAL_IP - $remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"  $HTTP_Host';

===========

休息20分钟
10:46 ~ 11:06

反向代理和正向代理

proxy 代理
Reverse 相反的
Reverse Proxy --》反向代理

URL:统一资源定位符
https://www.qq.com:80/sanchuang/feng.html
协议+域名(ip)+端口号+服务器里的文件的路径

URI:统一资源标识符
协议+域名(ip)+端口号+服务器里的文件的路径+参数
https://www.qq.com:80/sanchuang?name=feng&age=36&sex=male
服务器里的文件的路径

location = / {
[ configuration A ]
}

location / {
[ configuration B ]
}

location /documents/ {
[ configuration C ]
}

location ^~ /images/ {
[ configuration D ]
}

location ~* .(gif|jpg|jpeg)$ {
[ configuration E ]
}

https://www.baidu.com/s?ie=utf-8&f=8&rsv_bp=1&rsv_idx=1&tn=baidu&wd=%E5%86%AF%E5%BE%B7%E5%8B%87&fenlei=256&rsv_pq=8cca9713000d0ade&rsv_t=ceff6y982wavU8

健康检查 Health checks
max_fails 失败的最多的次数
fail_timeout 失败超时的时间

upstream backend {
server backend1.example.com;
server backend2.example.com max_fails=3 fail_timeout=30s;
在30秒以内达到失败的次数到3次,就标识这台server 为down机状态。
}

Passive Health Checks 被动的健康检查: 当client发请求给LB,然后LB再去转发请求给后端的real server ,这个时候如果后端的服务器出现问题,LB就发现了。被客户机逼着去检查后端的real server

对于每个上游服务器,使用块中server指令的参数定义了标记上游服务器不可用的条件upstream:

fail_timeout –设置必须多次尝试失败才能将服务器标记为不可用的时间,以及将服务器标记为不可用的时间(默认为10秒)。
max_fails –设置在fail_timeout服务器标记为不可用的时间内必须发生的失败尝试次数(默认为1次尝试)。
backup 备份:当其他的服务器都不提供服务的时候,再启用这台服务器提供服务 --》备胎
slow_start 慢启动
down 将上游的服务器标识为不可用,不会再发送任何的请求给这台服务器

upstream backend {
server backend1.example.com slow_start=30s; 晚30秒给上游的服务器转发请求
server backend2.example.com;
server 192.0.0.1 backup;
}

Active Health Checks 主动的健康检查,LB每隔一段时间就去检查下后端的real server的状态,不管是否有client发请求过来,都会去检查。

by default, every five seconds NGINX Plus sends a request for “/” to each server in the backend group. If any communication error or timeout occurs (the server responds with a status code outside the range from 200 through 399) the health check fails. The server is marked as unhealthy, and NGINX Plus does not send client requests to it until it once again passes a health check.
NGINX 的健康检测插件会每隔5秒钟去访问上游的服务器的网页根目录,如果返回的状态码不是200到399之间的,这个插件就会认为上游的服务器挂了
到底是如何去检查的,使用curl命令去访问后端的服务器

server {
location / {
proxy_pass http://backend;
health_check port=8080; 指定检测的端口号
}
}

location / {
proxy_pass http://backend;
health_check interval=10 fails=3 passes=2; 每隔10秒去检查一次后端的real server, 失败的次数到达3次的时候,就标识这台上游服务器不可用,如果连续2次又可用访问了,就标识这台上游的服务器为up(可用)
主动检查:默认的失败次数是1次,默认的时间间隔是5秒,默认只要能成功访问一次就认为服务器up 了

}

是负载均衡器去检查后端的real server是否能正常,如果不正常,如果后端的real server宕机了,负载均衡器就不会再把请求转发给这个宕机的real server

宕机: 死机 down 某个服务挂了,跪了

200
404
401
500
501
502
502 Bad Gateway --》负载均衡器后面的real server 全部down 了

休息20分钟
15:58 ~ 16:18

[root@LB conf]# nginx -t
nginx: [emerg] unknown directive “health_check” in /usr/local/nginx9/conf/nginx.conf:56
nginx: configuration file /usr/local/nginx9/conf/nginx.conf test failed
[root@LB conf]#
NGINX Plus nginx的插件提供了 health_check的功能
安装插件 NGINX Plus
https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/#install_rhel_centos

软件 —》购买
服务 --》购买

======================

nginx的4层负载均衡的配置

https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/

[root@LB-4-layer conf]# cat nginx.conf|egrep -v “#”|egrep -v “^$”

worker_processes 2;
error_log logs/error.log info;
pid logs/nginx.pid;
events {
worker_connections 1024;
}
stream {
upstream sanchuang {
server 192.168.0.19:80;
server 192.168.0.20:80;
}
upstream dns_servers {
server 192.168.0.19:53;
server 192.168.0.20:53;
}
server {
listen 8080;
proxy_pass sanchuang;
}
server {
listen 53 udp;
proxy_pass dns_servers;
}
}
http {
include mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - remoteuser[remote_user [time_local] “KaTeX parse error: Double superscript at position 34: … '̲status bodybytessent"body_bytes_sent "http_referer” ’
‘“httpuseragent""http_user_agent" "http_x_forwarded_for”’;
access_log logs/access.log main;
sendfile on;
tcp_nopush on;
keepalive_timeout 65;
gzip on;
}

#注意下http语句块里没有server语句块了,server语句块全部放到stream语句块里了 --》需要验证

[root@LB-4-layer conf]#

[root@LB-4-layer conf]# netstat -naupltu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 895/sshd
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 18760/nginx: master
tcp 0 36 192.168.0.74:22 192.168.0.15:56144 ESTABLISHED 1695/sshd: root [pr
tcp6 0 0 :::22 ::😗 LISTEN 895/sshd
udp 0 0 0.0.0.0:53 0.0.0.0:* 18760/nginx: master
udp 0 0 192.168.0.74:68 0.0.0.0:* 883/NetworkManager
[root@LB-4-layer conf]#

[root@LB-4-layer conf]# service firewalld stop
Redirecting to /bin/systemctl stop firewalld.service
[root@LB-4-layer conf]# getenforce
Enforcing
[root@LB-4-layer conf]# setenforce 0
[root@LB-4-layer conf]#
[root@LB-4-layer conf]#

查看负载均衡的记录
查看
[root@LB-4-layer logs]# pwd
/usr/local/nginx9/logs
[root@LB-4-layer logs]#

[root@LB-4-layer logs]# tail -f error.log
020/05/08 17:36:04 [info] 18888#18888: *253 client 192.168.0.63:52460 connected to 0.0.0.0:8080
2020/05/08 17:36:04 [info] 18888#18888: *253 proxy 192.168.0.74:35696 connected to 192.168.0.20:80
2020/05/08 17:36:07 [info] 18888#18888: *249 client disconnected, bytes from/to client:0/0, bytes from/to upstream:0/0
2020/05/08 17:36:13 [info] 18888#18888: *255 client 192.168.0.33:52161 connected to 0.0.0.0:8080
2020/05/08 17:36:13 [info] 18888#18888: *255 proxy 192.168.0.74:36234 connected to 192.168.0.19:80
2020/05/08 17:36:13 [info] 18888#18888: *257 client 192.168.0.33:52162 connected to 0.0.0.0:8080
2020/05/08 17:36:13 [info] 18888#18888: *257 proxy 192.168.0.74:35700 connected to 192.168.0.20:80

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章