负载均衡与网络底层刨析-优快云博客

本文链接：https://blog.youkuaiyun.com/python_start/article/details/107436642

网络
OS网络七层：
应用层，表示层，会话层，传输控制层，网络层，链路层，物理层
TCP/IP四层：
应用层，传输层，网络层，网络接口层
图片: https://uploader.shimo.im/f/35T3sSMRq81B5FGL.png
图片: https://uploader.shimo.im/f/gsLwOx0aG1QUfK2l.png
交换机：物理层进行网络通信
路由器：网络层，链路层，物理层
网络通信连接
https://baijiahao.baidu.com/s?id=1654225744653405133&wfr=spider&for=pc
1、三次握手
客户端发送seq和syn，希望建立连接
服务端接收到请求确认后，返回同意
客户端需要向服务端确认时，可以将数据和确认包同时发送服务器（为什么3次握手的原因）
2、四次挥手
第一次挥手"：日久见人心，男孩发现女孩变成了自己讨厌的样子，忍无可忍，于是决定分手，随即写了一封信告诉女孩。
第二次挥手”：女孩收到信之后，知道了男孩要和自己分手，怒火中烧，心中暗骂：你算什么东西，当初你可不是这个样子的！于是立马给男孩写了一封回信：分手就分手，给我点时间，我要把你的东西整理好，全部还给你！男孩收到女孩的第一封信之后，明白了女孩知道自己要和她分手。随后等待女孩把自己的东西收拾好。
“第三次挥手”：过了几天，女孩把男孩送的东西都整理好了，于是再次写信给男孩：你的东西我整理好了，快把它们拿走，从此你我恩断义绝
“第四次挥手”：男孩收到女孩第二封信之后，知道了女孩收拾好东西了，可以正式分手了，于是再次写信告诉女孩：我知道了，这就去拿回来！
数据包传输原理
传输包包含以下内容：
源端口号->目标端口号
源IP地址->目标IP地址
源MAC地址->目标MAC地址
结论：
TCP/IP协议：
基于下一跳的机制：
IP是端点间
mac地址是节点间的
三次握手->数据传输->四次分手,成为一个最小粒度,不可被分割
图片: https://uploader.shimo.im/f/bJPlrgcv7GU2Tgyz.png
cd /proc/$$/fd
exec 8<> dev/tcp/www.baidu.com/80
echo -e ‘GET / HTTP/1.0\n’ >& 8
cat <& 8
负载均衡（lvs）
CIP，VIP, DIP, RIP
图片: https://uploader.shimo.im/f/dAcDxWivfs6VuBD2.png
单点故障和两端非对称问题LVS
1、D-NET模式
图片: https://uploader.shimo.im/f/LHLHg0nOnGO61QGH.png
优点：CIP到VIP不会进行握手操作，只走了4层，网络传输快，VIP-RIP进行正常网路七层通信
缺点：非对称，带宽成为瓶颈，消耗算力，要求RS的GW指向负载均衡服务器
2、DR(直接路由模式)
图片: https://uploader.shimo.im/f/eupcxt9cvYXWdcnT.png
RIP直接和CIP进行连接，减轻负载端宽带的负担
VIP->RIP运用了网络通信一跳的想法，基于2层网络通信，速度快，RIP对VIP进行了封装可以直接和CIP进行通信，封装的VIP对外隐藏，对内可见。
缺点：负载服务器和服务器在同一个网段。
3、TUN隧道技术
VPN & 翻墙
(1) IP隧道技术又称为IP封装技术，它可以将带有源和目标IP地址的数据报文使用新的源和目标IP进行第二次封装，这样这个报文就可以发送到一个指定的目标主机上；
(2)VS/TUN模式下，调度器和后端服务器组之间使用IP隧道技术。当客户端发送的请求(CIP–>VIP)被director接收后，director修改该报文，加上IP隧道两端的IP地址作为新的源和目标地址，并将请求转发给后端被选中的一个目标；
(3)当后端服务器接收到报文后，首先解封报文得到原有的CIP–>VIP，该后端服务器发现自身的tun接口上配置了VIP，因此接受该数据包。
(4)当请求处理完成后，结果将不会重新交给director，而是直接返回给客户端；在后端服务器返回给客户端数据包时，由于使用的是普通网卡接口，根据一般的路由条目，源IP地址将是该网卡接口上的地址，例如是RIP。因此，要让响应数据包的源IP为VIP，必须添加一条特殊的路由条目，明确指定该路由的源地址是VIP。
理论解释
四种静态：
rr:轮循
wrr:
dh:
sh:
动态调度方法：
lc: 最少连接
wlc: 加权最少连接
sed: 最短期望延迟
nq: never queue
LBLC: 基于本地的最少连接
DH:
LBLCR: 基于本地的带复制功能的最少连接
隐藏VIP方法：对外隐藏，对内可见：
kernel parameter:
目标mac地址为全F，交换机触发广播
/proc/sys/net/ipv4/conf/IF/
arp_ignore: 定义接收到ARP请求时的响应级别；
0：只要本地配置的有相应地址，就给予响应；
1：仅在请求的目标(MAC)地址配置请求
到达的接口上的时候，才给予响应；
arp_announce：定义将自己地址向外通告时的通告级别；
0：将本地任何接口上的任何地址向外通告；
1：试图仅向目标网络通告与其网络匹配的地址；
2：仅向与本地接口上地址匹配的网络进行通告；
ipvs内核模块
yum install ipvsadm -y
管理集群服务
添加：-A -t|u|f service-address [-s scheduler]
-t: TCP协议的集群
-u: UDP协议的集群
service-address: IP:PORT
-f: FWM: 防火墙标记
service-address: Mark Number
修改：-E
删除：-D -t|u|f service-address
ipvsadm -A -t 192.168.9.100:80 -s rr
管理集群服务中的RS
添加：-a -t|u|f service-address -r server-address [-g|i|m] [-w weight]
-t|u|f service-address：事先定义好的某集群服务
-r server-address: 某RS的地址，在NAT模型中，可使用IP：PORT实现端口映射；
[-g|i|m]: LVS类型
-g: DR
-i: TUN
-m: NAT
[-w weight]: 定义服务器权重
修改：-e
删除：-d -t|u|f service-address -r server-address

ipvsadm -a -t 172.16.100.1:80 -r 192.168.10.8 –g

ipvsadm -a -t 172.16.100.1:80 -r 192.168.10.9 -g

查看
-L|l
-n: 数字格式显示主机地址和端口
–stats：统计数据
–rate: 速率
–timeout: 显示tcp、tcpfin和udp的会话超时时长
-:c 显示当前的ipvs连接状况
删除所有集群服务
-C：清空ipvs规则
保存规则
-S

ipvsadm -S > /path/to/somefile

载入此前的规则：
-R

ipvsadm -R < /path/form/somefile

实验
LVS：

node01:
ifconfig eth0:8 192.168.150.100/24
node02~node03:
1)修改内核：
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
2）设置隐藏的vip：
ifconfig lo:3 192.168.150.100 netmask 255.255.255.255

RS中的服务：
node02~node03:
yum install httpd -y
service httpd start
vi /var/www/html/index.html
from 192.168.150.1x

LVS服务配置
node01:
yum install ipvsadm
ipvsadm -A -t 192.168.150.100:80 -s rr
ipvsadm -a -t 192.168.150.100:80 -r 192.168.150.12 -g -w 1
ipvsadm -a -t 192.168.150.100:80 -r 192.168.150.13 -g -w 1
ipvsadm -ln

验证：
浏览器访问 192.168.150.100 看到负载疯狂F5
node01：
netstat -natp 结论看不到socket连接
node02~node03:
netstat -natp 结论看到很多的socket连接
node01:
ipvsadm -lnc 查看偷窥记录本
TCP 00:57 FIN_WAIT 192.168.150.1:51587 192.168.150.100:80 192.168.150.12:80
FIN_WAIT：连接过，偷窥了所有的包
SYN_RECV：基本上lvs都记录了，证明lvs没事，一定是后边网络层出问题

keepalived实验：
主机： node01~node04

node01:
ipvsadm -C
ifconfig eth0:8 down

node01,node04:
yum install keepalived ipvsadm -y
配置：
cd /etc/keepalived/
cp keepalived.conf keepalived.conf.bak
vi keepalived.conf
node01:
vrrp：虚拟路由冗余协议！
vrrp_instance VI_1 {
state MASTER // node04 BACKUP
interface eth0
virtual_router_id 51
priority 100 // node04 50
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.150.100/24 dev eth0 label eth0:3
}
}
virtual_server 192.168.150.100 80 {
delay_loop 6
lb_algo rr
lb_kind DR
nat_mask 255.255.255.0
persistence_timeout 0
protocol TCP

			real_server 192.168.150.12 80 {
				weight 1
				HTTP_GET {
					url {
					  path /
					  status_code 200
					}
					connect_timeout 3
					nb_get_retry 3
					delay_before_retry 3
				}   
			}       
			real_server 192.168.150.13 80 {
				weight 1
				HTTP_GET {
					url {
					  path /
					  status_code 200
					}
					connect_timeout 3
					nb_get_retry 3、
					delay_before_retry 3
				}
			}
		scp  ./keepalived.conf  root@node04:`pwd`