网络到分布式keepalived
2021-09-15 21:29:34 0 举报
OSI七层解释映射到lvs负载均衡器 搭建DR模型 和引入keepalived搭建HADR 根据keepalived引出为什么需要zookeeper搭建稳定的高可用集群
作者其他创作
大纲/内容
①:在部署lvs的那个服务器上netstat -natp监听 [root@huang all]# netstat -natpActive Internet connections (servers and established)Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:6380 0.0.0.0:* LISTEN 1259/redis-server 1 tcp 0 0 127.0.0.1:6381 0.0.0.0:* LISTEN 1265/redis-server 1 tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1046/sshd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1795/master tcp 0 0 192.168.173.128:22 192.168.173.1:49585 ESTABLISHED 17251/sshd: root@pt tcp 0 0 192.168.173.128:22 192.168.173.1:56356 ESTABLISHED 48458/sshd: root@pt tcp6 0 0 :::22 :::* LISTEN 1046/sshd tcp6 0 0 ::1:25 :::* LISTEN 1795/master 不存在80端口②:在真实服务器上的监听 [root@huang html]# netstat -natpActive 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 1053/sshd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1800/master tcp 0 0 192.168.173.129:22 192.168.173.1:56363 ESTABLISHED 2450/sshd: root@pts tcp6 0 0 :::3306 :::* LISTEN 2415/mysqld tcp6 0 0 :::80 :::* LISTEN 2773/httpd tcp6 0 0 :::22 :::* LISTEN 1053/sshd tcp6 0 0 ::1:25 :::* LISTEN 1800/master 存在一个监听 结论:lvs负载均衡不会与真实服务器建立链接 而是直接与客户端建立链接
192.168.173.7
vmnet-8在win上虚拟的网卡,让win上的软件可以进入到虚拟机中与虚拟机通讯
基于上面主备二台vip不可以同时配置 主备中只能同一时刻存在一个vip 这个切换配置在keepalived中帮我们在master挂了之后处理所以在keepalive中配置 vip以及ipvsadm
FD
global_defs { //全局配置 notification_email { //在keepalive出现问题 可以通过发送邮件通知 acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 192.168.200.1 smtp_connect_timeout 30 router_id LVS_DEVEL vrrp_skip_check_adv_addr vrrp_strict vrrp_garp_interval 0 vrrp_gna_interval 0}虚拟路由冗余协议:vrrp_instance VI_1 {//虚拟路由冗余协议 state MASTER //标注 master 另一台可标注BACKUP interface eth0 //使用服务器的eth0网卡组成该网络网络(服 务器可 以存在多个网卡 其他网卡处理其他数据包 将数 据包发送到不同的物理网络 好处为信号不会影 响传输的时效) virtual_router_id 51 // 存在多个keepalived 同一个主备的//组成的网络应该均是51 (标识位这个网络属于该keepalived) priority 100 //这个keepalived中权重 backup选举依据 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { //vip 主备(谁激活了vip谁就是主) 192.168.173.127/24 dev eno16777736 label eno16777736:2 可以根据man 5 keepalived.conf查看配置 }}
运营商会给这个路由器分配一个ip地址
cip--->vip
这里还会涉及NAT转换:
rip---->cip
dma
内存
cip---->vip |rip@mac
vip
三种模型①:为什么只有到达四层的时候才会知道端口号? 因为需要知道端口号 才会知晓需不需要转发这个数据包(os正常启动 也会启动端口号)当收到其他的端口号不会进行转发,只会对特点的端口号转发(在四层的偷窥机制)注意:这里还没有完全到达四层(没有触发四层返回与cleint握手的包) 只是偷窥了四层 数据包的端口 ②:四层无法获取应用层使用的协议 为什么后端需要是镜像的?③:为什么建立握手
8.8.8.8
lvs master
192.168.173.1(winvm8的ip):xxxx(port)--->192.168.173.127(vip地址):80
高并发下的负载均衡:应用层在tcp/ip协议下的通讯必须建立完三次握手
client
传输控制层 socket协议封装syn+ack等等包
网络协议原理 该原理去解决高并发下的负载均衡问题
LVS四层负载均衡器
vip---->cip
httpd
Dip
开机的时候可以采集除自己之外的其他主机ip地址对应的mac地址 arp -a查看 保存到当前主机也就是当开机的时候 会发送一个mac地址全是ffffff+目标地址为网关的包 给交换机 ,此时交换机看到目标地址是ffffff,那么该包会被广播 到当前局域网所有的主机,当目标地址与当前主机相同的时候会响应这个数据包 携带这个主机的mac地址,不相同则丢弃
cip:ncport
hold住流量流量负载层
那么http协议在osi五层如何体现?上述演示的为应用层协议 GET / HTTP/1.0\为手写模拟应用层软件(浏览器)封装好的字符串规范 地址栏https://www.baidu.com/ 完成上述所有演示步骤此时无论发送还是接受 的始终是数据 ;处于应用层的浏览器或者tomcat等等软件只需要将需要发送的数据按照http协议封装好,写给下面的层次;eg:在浏览器和服务器之间没有传输数据前需要建立一个socket用于连接 (此时就需要先 传输控制层(server端在运行的时候就已经建立了监听FD 当client在输入网址的时候 在没有将http请求协议的数据发送前 需要先与server建立socket(tcp协议建立)连接 主要传输控制层开始建立 此时传输控制层可以查看到serverip:serverport+clientip:clientport(这里看到四元组的优点 后面说))) 传输控制层 syn --->server server ack+syn ---->client client ack-----server建立链接 此时server 端如果存在执行accept那么 传统bio模型下 创建一个线程 处理这个cleint与server的四元组 进行读取和书写 (均是tcp传输协议 规定 建立一个连接需要三次握手 以及后续发送一个数据包就会返回一个确认 也是根据tcp协议约定 以及断开连接之后的四次挥手)注意:一次三次握手+传输数据+四次挥手 为链接的最小粒度 (不可分割)二端一个完整的链接建立之后才可以传输数据 在经历一次完整的四次挥手 才会释放资源在纯属控制层 既然需要建立链接 那么肯定知道server的ip和监听fd绑定的端口 此时面临的是如何找到对应ip的server 引出网络层(下一跳机制 传统家里使用的路由器存在一个输入(电信公司给的ip)和多个输出(链接家庭电脑手机上网设备 可定义分配的ip(局域网))) 对应的路由表 为下一跳的位置
global_defs { notification_email { acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 192.168.200.1 smtp_connect_timeout 30 router_id LVS_DEVEL vrrp_skip_check_adv_addr vrrp_strict vrrp_garp_interval 0 vrrp_gna_interval 0}vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.200.16 192.168.200.17 192.168.200.18 }
①:高并发②:高可用③:负载均衡如何落地?为什么存在这个技术?该技术的原理?如何使用?web容器的日志可以记录:访问用户的ip 时间 url资源 来源渠道(淘宝域名过来的 还是某某app首屏广告来的(用于分析打广告的钱花的值不值))====》渠道流量的质量(每一个渠道给我带来的访问量) 然后获取后台的销售记录 (直接通过淘宝域名访问 B站首屏广告链接访问等 对应的销售数据)可以得到每个渠道的转换流 获取到投放广告的性价比 此时的问题: ①:如何获取用户的ip 时间 url资源 ②:如何获取渠道来源此时高并发承载落地上述高流量的访问OSI七层参考模型(参考表示 具体协议使用这几层 其中那些层(eg:http精简为5层 其链路控制层以下在kernel 应用层 表示层 会话层在用户空间 整合到一起)
主备均需要装keepalived主:keepalived通告备备:接受通告
①:无论什么模式 客户单访问服务端的服务器是透明的 也就是只能访问负载均衡器
cip---->vip
win VMware -NAT为win上的后台服务(守护进程) 该服务为相当于这里的192.168.150.2这个ip地址 ;上面的虚拟主机数据包全都是发给这个服务的(相当于路由器);此时数据包想要链接外网则需要将这里的包转发到以太网中
http协议(一套规范和标准 定义客户端和服务器端request和response获取和提交数据的规范)如这里的请求头 GET / HTTP/1.0\ 按照规范 (可以在浏览器的 f12 的network中找到baidu文件 选择headers 可以看到request请求体和response响应头)
server2
存在隐藏的vip
tomcat
cip
②:8.8.8.8:1234-->129.164.123.123:80
要求:由于需要在包嵌套mac地址 所以负载和server在同一局域网内(下一跳可到达的范围)
rip
路由器三层存在路由表和链路表可以做路由的转发和判定
这里封装数据包添加dip--->rip 将vip和vip的数据包发送到server,也就是dip--->rip组成的包相当于隧道, 此时 dip-->rip(附上cip-->vip)的数据包 到server 该服务器存在rip所以包不会被丢弃;当来到这个服务器只要将外面的dip-->rip干掉就可以得到cip-->vip这里的包不需要在使用mac地址了,dr模型存在mac地址是为了cip-->vip实现下一跳到server
负载均衡
TUN隧道技术(应用于现在server可能不在同一个机房)
keepalived文件 : man 5 keepalived.conf
在另一个lvs中配置 ①:将MASTER改为BACKUP②:priority 改为50③:virtual_router_id 51 不变 这个相同表示同一网络下的主备(为以后的主周期性广播包到备用于证明主此时可用)和主挂了 备选举systemctl start keepalived.service启动centos7此时ifconfig出现子接口(主存在 被不存在这个vip) -----原因以vip判定当前virtual_router_id 51主备以及ipvsadm -ln 出现负载条目(主备均存在这个条目)ipvsadm -lnc 查看是否有数据包经过这个lvs当主挂了 主中的vip 发生ip漂移到备ifconfig eth0 down (关掉网卡) //模拟主挂了ifconfig eth0 up (启动网卡)systemctl stop httpd.service //模拟后端服务器应用层的挂了//这也是不可以直接使用ping来检测后端是否正常的原因 ping仅仅在网络层 这里属于应用层//也是keepalived必须在应用层的原因 可以解析keepalived发送的检测后端服务器的http协议 以及解析响应的status_code 200当后端服务器修复之后 也会自动加上去
rip:192.168.173.130vip:192.168.173.127(隐藏)
keepalived配置
此时的server1需要返回的数据包
这里这接返回的好处①:不会存在算力消耗②:解决非对称问题 返回的单独配置自己的 链 路(不走原先的)
从之前的DR模型到这个DR-HA模型的衔接过程①:之前的lvs清除还原成裸机,真实服务器保持不变②:在二台lvs装keepalived 书写配置文件 启动keepalived 之前的 [root@huang ~]# ipvsadm -lnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 192.168.173.127:80 rr -> 192.168.173.129:80 Route 1 1 1 -> 192.168.173.130:80 Route 1 1 1 [root@huang ~]# ipvsadm -C 清空上面的条目IP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn [root@huang ~]# ifconfig eno16777736:2 down //清空vip①:此时在原先的lvs服务器上安装keepalived yum install keepalived -y (keepalived有能力替代ipvsadm这个程序 之所以需要安装时实验的时候需要) [root@huang keepalived]# pwd/etc/keepalived[root@huang keepalived]# lltotal 4-rw-r--r--. 1 root root 3598 Sep 30 2020 keepalived.conf 为配置文件[root@huang keepalived]# cp keepalived.conf ./keepalived.conf.bk//留备份[root@huang keepalived]# lltotal 8-rw-r--r--. 1 root root 3598 Sep 30 2020 keepalived.conf-rw-r--r--. 1 root root 3598 Sep 8 09:36 keepalived.conf.bk
ip3
隐藏vip的方法
①:在路由器中使用公网地址替换私有地址 然后发送给互联网 ;此时 如果响应的数据包返回 (129.164.123.123:80--->8.8.8.8:1234 ) 需要将8.8.8.8替换成192.168.173.7②:如果此时二台电脑同时访问互联网 当二个包的发送到互联网均正常,当互联网响应返回的时候 发现传入的 二个包均是129.164.123.123:80--->8.8.8.8:1234 此时如何区分?以及还原为原先的客户端ip③:解决;路由器会存在一张表 该表会创建一个端口号(假如是999) 映射192.168.173.7:1234, 此时出去包的ip+port变为8.8.8.8:999 此时发送到公网上的包和 原先就存在差距 响应的时候对照路由器中的表 还原原先的私有ip上述为修改源地址(客户端私有ip--->公有ip) 这个nat称之为source-nat;在负载均衡器侧 就是对应的destination-nat(通过负载均衡 修改目标地址)将v-ip换成rip
192.168.150.2
网卡存在mac地址和ip地址在一个局域网内 每个主机会知道网关的mac地址;封装包 @mac|源地址-->目标地址|
node1配置 ipvsadm 先安装yum install ipvsadm -y添加进来的数据包规则 ipvsadm -A -t 192.168.173.127:80 -s rr (这里是目标地址为vip)[root@huang /]# ipvsadm -ln //查看配置的入口规则IP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 192.168.173.127:80 rr在添加出去包的规则(也就是分配到哪些服务器) ipvsadm -a -t 192.168.173.127:80 -r 192.168.173.129 -g ipvsadm -a -t 192.168.173.127:80 -r 192.168.173.130 -g[root@huang /]# ipvsadm -lnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 192.168.173.127:80 rr -> 192.168.173.129:80 Route 1 0 0 -> 192.168.173.130:80 Route 1 0 0 此时访问 http://192.168.173.127出现轮流显示二个网页[root@huang /]# ipvsadm -lnc 用于偷窥每个三次握手链接的状态syn syn+ack ack 然后记录这个链接与那个真实服务器链接,这个为实现lc的基础IPVS connection entriespro expire state source virtual destination TCP 15:00 ESTABLISHED 192.168.173.1:55369 192.168.173.127:80 192.168.173.130:80TCP 14:44 ESTABLISHED 192.168.173.1:64602 192.168.173.127:80 192.168.173.129:80TCP 01:26 FIN_WAIT 192.168.173.1:54911 192.168.173.127:80 192.168.173.129:80
8
virtual_ipaddress { 192.168.173.127/24 dev eno16777736 label eno16777736:2 }相当于在没有HA引入的时候 需要ifconfig eno16777736:2 192.168.173.127/24 在 eno16777736接口配置子接口eno16777736:2
这部分内容在网络IO(多路复用器实现的支持)
osi七层模型 lvs三种模式 DR模式的搭建 验证 解决高并发 keepalive实现高可用
这里使用高并发和不使用的临界点在哪里?
链路层arp协议
Client
①:/proc/sys/net/ipv4/conf/eno16777736放置kernel和启动时候的进程 变量和参数抽象成文件上述为启动的网卡文件;---》这里的文件不要使用vim打开,(vim存在临时文件的原因)只能使用echo重定向去覆盖arp-ignore和arp-announce期初默认值均为0arp-ignore:定义接受到arp请求时的响应级别 (别人请求去访问这个机器的时候) 一个计算器上可以存在多块网卡,可以分配配置 不同的地址。存在一种外界请求到网卡二 是从网卡一到达这 个计算机的 这里的参数0表示:存在一个网卡的ip对外暴露 即访问其他网卡也会暴露这个网卡的ip 参数为1表示:存在一个网卡的ip对外隐藏 arp-announce:通告()一块网卡可以设置多个ip地址 win上通过属性 ipv4 选择高级 继续追加ip地址 参数0:该计算机所有网卡启动就会向外通告ip 参数1: 参数2:仅仅对来的数据包存在该ip的通告(包发来没到达该计算机是不知道改计算机存在这个ip的,当能发来完全靠链路层) (网络层仅仅解决知道去哪里eg:知道自己要从北京南站---》天通苑 此时的链路层需要解决的是怎么走比较划算,下一站得去陶然亭 才是最短 的 ①:北京南站为客户端应用层 天通苑为服务器应用层,从北京南站到天通苑 现在遵从http协议(选择做地铁的想法);②:此时需要考虑地铁有没有停运 那就使用百度搜索(这里相当于链路控制层 三次握手知道没停运) ;③:现在规划去天通苑小区的线路 这是网络层④:北京南站到天通苑规划线路(4-->2--->5) 由于2是环线 我下一站需要到 陶然亭在到菜市口最近(链路层)⑤:物理层
出包配置(离开lvs)后配置
cip---->rip
路由器(包含交换机)
ip1
server1
lo
解决算力问题
重点
解决方案:借助链路层mac地址 (解决下一跳)就拿 包 最外层套了一个mac地址 为下一跳地址所以这里为负载均衡器的mac地址 (arp -a可以看到 ) 此时这里 当原先的cip---->vip | vip@mac包来到span style=\
virtual_server 192.168.173.127 80 { //虚拟服务 vip -A 进来的包根据首先从客户端的包cip--->vip 到lvs 然后套上真实服务器的mac地址cip-->vip|@mac 负载到真实服务器 此时lvs偷窥每个包的三次握手状态当存在syn syn+ack ack 状态记录这个包发送到的服务器信息到lvs保存 delay_loop 6 lb_algo rr //轮询 lb_kind DR //nat模型 DR模型 tun模型 persistence_timeout 50 //相当于client第一次访问129这个服务器 在断开 之后此时该cleint又去访问到130这个服务器 那么129中已经开辟了一些资源 eg: 数据库连接请求的数据 等等 浪费资源 所以使用持久化超时时间来 在规定时间内 同一客户端访问 会负载到之前的服务器中 50单位为秒 实验的时候不可以写50s 太长无法观察 protocol TCP //协议 添加tcp协议的监控 real_server 192.168.173.129 80 {//真实服务器的配置 rip 虚拟网络负载 weight 1 HTTP_GET { //对后端real server的监控检查 这个ssl_get为https协议 //HTTP_GET url { path / //请求的资源路径 status_code 200 //当lvs发送的包返回响应为200的时候RS监控 } url { //可删除 path /mrtg/ digest 9b3a0c85a887a256d6939da88aabd8cd } connect_timeout 3 //当没有 nb_get_retry 3 delay_before_retry 3 //重试次数 当超过这个次数 则判定排除网络波动 造成的 RS挂了 } }//这里配置二个real_server 只需要更改ip地址为130 即可 因为需要负载到二个RS中}virtual_server 10.10.10.2 1358 { delay_loop 6 lb_algo rr lb_kind NAT persistence_timeout 50 protocol TCP sorry_server 192.168.200.200 1358 real_server 192.168.200.2 1358 { weight 1 HTTP_GET { url { path /testurl/test.jsp digest 640205b7b0fc66c1ea91c463fac6334d } url { path /testurl2/test.jsp digest 640205b7b0fc66c1ea91c463fac6334d } url { path /testurl3/test.jsp digest 640205b7b0fc66c1ea91c463fac6334d } connect_timeout 3! Configuration File for keepalived
https://blog.csdn.net/qlj324513/article/details/81541282Nginx、HAProxy、LVS三者的优缺点
如何确定真实服务器挂了如何确定的?如果使用ping ping的是ip ip在网络层 ping的是网络连接通不通(握手的事都确定不了)但是真实服务器所在的应用在第七层 (此时仅仅靠握手也不可以 同样的问题 握手在传输控制层)所以真实确定应用层是否可用 需要验证的是应用层的http协议(发送请求 判断响应状态是否是200 ok)
这里的状态status ①:FIN-AWAIT 正常的 ②:syn-recv(握手只有发送给服务器的包 没有服务器返回确认的包) 真实服务器的网络层出问题了 ③:ESTABLISHED 只是建立了链接 https://blog.csdn.net/yujin2010good/article/details/88732377 状态的说明
相当于ipvsadm -A -t 192.168.173.128:80 -s rr 入包规则对应virtual_server
ip地址分为公有ip地址和私有ip地址;公有地址:dip地址私有地址:局域网的ip 这部分ip是不容许出现在互联网上的
点与点之间什么什么样的通信协议具体为:我这里写什么样的协议可以发送给你接受span style=\
DR模型的搭建
/proc/sys/net/ipv4/conf[root@huang conf]# lltotal 0dr-xr-xr-x. 1 root root 0 Sep 3 08:38 alldr-xr-xr-x. 1 root root 0 Sep 3 08:38 defaultdr-xr-xr-x. 1 root root 0 Sep 6 18:02 eno16777736dr-xr-xr-x. 1 root root 0 Sep 6 18:02 lo[root@huang conf]# cd lo-rw-r--r--. 1 root root 0 Sep 6 18:02 arp_announce //使用cat查看为0-rw-r--r--. 1 root root 0 Sep 6 18:02 arp_filter-rw-r--r--. 1 root root 0 Sep 6 18:02 arp_ignore//使用cat查看为0//该接口当存在局域网中会向外暴露
处理:传输的控制 session 以及会话保持
在执行exec 8<> /dev/tcp/www.baidu.com/80的时候存在系统调用 与百度建立握手span style=\
lvs backup
eno16777736
①:备机上需要配置state为BACKUP②:priority 更改为70
nginx (tomcat) 属于应用层为7层在应用层获取访问哪些信息?
处理数据包的能力上dr模型快于nat模型
vip与客户端链接
nat模式:借助nat转换
调度算法 一:静态调度 rr:轮询(看似平衡 但是有的断开连接的时候 依旧执行轮询 造成倾斜) wrr:加权轮询 指定某个高 dh:目标地址hash调度 sh: 源地址散列调度算法 https://www.cnblogs.com/pengpengboshi/p/13278440.html 调度算法 二: 动态调度 wlc,lc,sed,nq,lblc,lblcr lc:最少链接 (问题:负载均衡器如何知道客户端与后端server链接数量 (负载均衡器不会与客户端建立链,真正建立链接的是client与 server)原因:之前的在建立三次握手的数据包 是存在状态的 syn syn+ack ack 如果负载均衡器偷窥到了每个包的状态) 相当于经过三次握手链接建立完毕,此时负载均衡器会记录链接到那个server ====>最少链接的基础
NAT转换
这里不使用nat修改目标ip地址,还是原先的vip
如果:高并发环境下 如果使用nginx处理分发 需要将连接按照策略 分发给tomcat 此时 tomcat和nginx均在应用层那么二个应用层之间在tcp/ip协议下建立的通讯 需要建立三次握手+ 应用层用户态和内核态之间的切换 吞吐量 存在一定的影响直接使用tomcat去承载链接 性能更低,运行于jvm上,也就是jvm进程中 此时jvm进程堆内存还在逻辑内存中,此时与kernel进行数据交互等行为还不需要经过mmap映射就可以使用这个内存,但是tomcat开辟的堆空间 还在jvm堆内存中,此时无法直接使用需要拷贝之后在使用(虽然也是内存级别的速度也快) 这也就是在IO模型中存在直接内存和堆内存的原因
互联网
网络层
注意每一层存在具体的协议应用层存在的协议:①:(http协议 ssh协议)②:SMTP 简单邮件传输协议span style=\
私网IP(网关地址)
四层
如何建立链接 (传输控制层存在的协议tcp/udp协议 创建socket四元组链接)如何确认链接成功还是失败的 (三次握手和四次挥手机制) 也就是创建握手包和解析确认包 然后发送确认包 准备包 交由网络层+链路层通过(下一跳机制)寻找server地址
ipvsadm -a -t 192.168.173.128:80 -r 192.168.122.8 -g
左侧的全是lvs解决高并发,但是存在单点故障问题 这里引入keepalive解决单点故障实现高可用
真正意义上的 Client需要链接的是VIP ①: cip---->vip 此时如果 数据包经过多次下一跳机制 到vip,并通过dip 负载到后面的某一台, 按照规定这个 后面的服务器不会接受 (目标地址不是rip)所以该数据包会被丢弃②:在负载均衡器侧 就是对应的destination-nat(通过负载均衡 修改目标地址)将v-ip换成rip 原先 经过负载均衡器 目标ip地址改为 此时server可以收下这个包 那么在server端 使用netsta -natp监听 已建立关系的四元组存在③:当server响应client的时候在server创建 包 这个数据包如果直接给client也会被丢弃 所以还需要经过s-nat的转换 将返回的数据包变为④:瓶颈问题:非对称,也就是cleint的http请求发送的数据是很小的 但是响应的时候会携带大量的文件 最终导致返回的 带宽不够(自己找整的6m宽带为全速量 那么此时分为上行和下行每个3m 此时大概3000/8 = 0.375m/s 相 当 于375kb/s 当响应的文件为80kb的时候(最新的百度页面80kb) 那么 这一秒内只能怼4个) 此时的服务器为非对称 也就造成了带宽成为瓶颈 以及每个包都需要经过源地址目标地址的转换也会消耗算力
DR模型的搭建 准备:liunx node1 部署lvs dip:192.168.173.128(需要和后面的node2 node3在同一 网络) 此时给node1多添加一个地址作为vip 192.168.173.127 需要使用ipvsadm 配置输入和输出包集群 node2 部署httpd(webserver)客户端 rip:192.168.173.129 在lo虚拟网卡上创建子接口(不能对外暴露)均是vip地址 需要手动配置arp-ignore和arp-announce防止暴露 node3 部署httpd客户端 rip:192.168.173.130 在lo虚拟网卡上创建子接口(不能对外暴露)均是vip地址 网关:192.16.173.2(可当交换机使用 在没有访问外网的时候不需要nat 转换) windows 浏览器访问 80端口 浏览器请求包
家庭网络
node1 配置vip
数据包的调度
远程拷贝:scp ./keepalived ip地址:路径路径等于`pwd` 则说明当前路径
DIP
当主lvs挂掉之后 又恢复了那么又会切换到主上 备用机还是那个备用机 原因主的priority权重100最高又选举了并不是所有的主备结果 当主重新启动会抢回主的位置: 之所以lvs可以抢回主原因是 lvs需要阻塞双方停止服务同步数据少(要不要抢回主参考成本复杂度)但是会存在弊端:ps -ef | grep *kee* 查看关于kkeepalived进程存在三个 相关的keepalived 一个父进程 二个子进程 愿意? ①:父进程的keepalived为处理lvs中相关配置的操作 ②:二个子进程为 处理实验的二个RS的监控上述在java中是线程 但是c语言下为进程kill -9 进程 干掉全部正在运行的 //异常退出 不会回收资源 (正常退出会 回 收资源)也就是此时不会收回网卡子接口 span style=\
cpu
ipvsadm -L或者l 查看配置了哪些serveripvsadm -c ipvs的链接状况(偷窥等级的有哪些链接 通过抓取三次握手状态登记下来的)ipvsadm -S保存到文件中下次开机还可以使用(即时生效)
[root@huang network-scripts]# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface0.0.0.0 192.168.173.2 0.0.0.0 UG 100 0 0 eno16777736192.168.173.0 0.0.0.0 255.255.255.0 U 100 0 0 eno16777736 ①:destination 目标 ip地址与掩码(255.255.255.0)按位与运算得到的 192.168.173.0(我这个ip地址的主机可以访问 192.168.173.0网络号中的任意主机)②:Destination为0.0.0.0 的获取也是通过ip按位与这个掩码( 0.0.0.0 ) 按位与获取到的 表示可以访问任意ip地址 ③:gateway为下一跳的地址(每个互联网节点只会存储与该主机最近的节点ip(尽可能保存少量数据找到目标地址) eg:这个的网关)
vip(虚拟 ip)
解决算力瓶颈问题
dip
引出keepalived
单点故障问题:
send-q
ip2
192.168.173.1
同一个网卡的路由表
这里由于是四层(socket也是四层的)所以不知道客户端协议无法知晓请求资源路径,为数据包级别的转发 所以后端的为镜像
vip--->cip
eg:ping www.baidu.com (ping将数据包发送到百度 然后在接受这个数据包)PING www.a.shifen.com (36.152.44.96) 56(84) bytes of data.64 bytes from 36.152.44.96: icmp_seq=1 ttl=128 time=10.8 ms64 bytes from 36.152.44.96: icmp_seq=2 ttl=128 time=11.2 ms //为数据包发送到回来的时间36.152.44.96为这个数据包的目标地址 现在这里主机ping如何到达的? 如果拿到36.152.44.96这个ip到路由条目的每个路由条目的掩码按位与运算就可以找到下一跳,36.152.44.96 & 255.255.255.0 得到36.152.44.0 不符合destination 36.152.44.96 & 0.0.0.0 得到0.0.0.0 符合这个路由条目的destination 此时下一跳到Gateway(这个就是下一跳ip(相当于这个数据包想要出局域网先走这个Gateway)) 路由器当中也会存在路由表 对应这个网关之后的下一跳
二个网卡
rip:192.168.173.129vip:192.168.173.127(隐藏)
添加路由条目: 结果是自上而下, 就是说, 哪条在前面, 哪条就有优先, 前面都没有, 就用最后一条defaultroute add -net 192.168.62.0 netmask 255.255.255.0 gw 192.168.1.1// route add font color=\"#ff0000\
网卡 (接受和发送基于某通信协议下的全部数据)做二进制编码发送
win虚拟网卡
keepalived用途:①:监控自己②:在master中master通告 主备其他backup 自己存活③:在backup中监听 master广播的信息 获取状态④:master挂了 主备中的backup推举出新的master⑤:在keepalived中配置 vip 以及添加ipvs配置(之前手工完成的)(存在配置文件)⑥:周期性检测真实服务器 健康,真实服务器出现问题 后端server的rip将被冲ipvsadm表中剔除(规避继 续负载 用户得不到服务)keepalived主要作为HA实现工具一台nginx可以作为公司的负载均衡服务器来使用(2万以内并发) 公司入口就由这一个nginx来完成 此时该nginx也是单点故障 引入keepalived也可以解决(tomcat也可以)
vip-->cip
[root@huang lo]# ifconfig eno16777736:2 192.168.173.127/24 //添加的子接口 vip//撤销这个创建的子接口 [root@huang lo]# ifconfig eno16777736:2 downfont color=\"#ff0000\
192.168.173.8
LVS
路由表
路由
win物理网卡
①:客户端 (为负载均衡器的地址);此时在负载均衡中将追加@mac地址 让该包下一个阶段为server1, 此时的server1存在一个vip(考虑如果对外暴露还造成局域网内ip冲突,此 时 选择隐藏这个vip ) ----->在追加mac地址仅仅需要工作在二层(链路层)②:现在问题一:将这个vip隐藏在哪个网卡?ifconfig出现二个网卡 一:虚拟机通讯的网卡 (物理网卡) -----eno16777736 二:localhost(虚拟网卡)----lo ①:该二个网卡不是联通的 ②:任何接口均存在子接口 (在该lo接口的子接口配置vip 那么此时) 此时需要的事为:①:创建这个子接口 ②:调内核级别要求 对外隐藏这个vip③:如何为每个包追加mac地址③:从server1封装的 如何解决非对称问题出现的带宽瓶颈 也就是选择其他链路到达client而不 是 走原先的路(http请求发送的数据包较小 但是响应的包巨大走原先的路径 导致请求快 但是接受巨慢)
这里的交换机没画
链路表
存在隐藏的vip netstat -natp 存在localaddress 为vip--cip的条目用于封装返回的包直接到cleint
解决负载均衡高并发访问的时存在4层和7层二种解决方案4层:传输控制层7层: 应用层 使用应用程序 (所以免不了用户态到内核 态的转换)每一次均有相应的协议和标准
计算机七层或者五层
分层:无论那一层 只需要调用需要的那一层接口就行 无需大改动
vip---->cip
mac地址欺骗
keepalived(应用层)
一般并发量较大的应用,最前端为lvs
浏览器访问locaolhost:8080/
dip-->rip
nginx基于七层的反向代理负载均衡 nginx和服务器存在三次握手 客户端和nginx存在三次握手(客户端1-2万可以使用nginx做负载均衡)lvs局域四层负载均衡器 客户端和服务器端建立三次握手 ()lvs+nginx组合负载均衡
tcp/ip协议下的osi七层参考模型:协议为参考模型方案(讨论tcp/ip简洁的四层或者五层)为下图的(表示层和会话层被放到了应用层)
kernel进程
公网IP
cip--->vip|@mac1
局域网:保持统一网络号
bash进程
Gateway 等于0.0.0.0表示同一个局域网中的二个设备通讯不需要下一跳转发通过交换机直接转发数据包 不在需要路由
nginx
七层
tomcat运行于应用层
要求:server的网关指向负载均衡器以便响应数据包返回
上面案列为找到下一跳而已(也就是Gateway)为网络层处理任务 ;这里仅仅是找到下一跳(去哪里) 那么如何去呢? 引出链路层之前知道下一跳为192.168.173.2 但是访问的百度地址为 (36.152.44.96) 那么如何将数据包扔给192.168.173.2 也就是在当前ip地址在套一个mac地址(链路层)[root@huang network-scripts]# arp -a(链路层的表)arp为一个协议 dns会解析域名和ip地址映射(全网的) arp解析ip与网卡硬件地址的映射(统一局域网内的所有mac地址)? (192.168.173.254) at 00:50:56:e5:d6:e7 [ether] on eno16777736? (192.168.173.1) at 00:50:56:c0:00:08 [ether] on eno16777736? (192.168.173.2) at 00:50:56:f7:c0:28 [ether] on eno16777736 //之前的网络层根据路由配置已经知晓下一跳 上述三个为当前局域网
链路层下一跳的mac地址(路由器中网关硬件地址)(不同的下一跳存在不同的mac地址 所以这个会改变) + server目标地址 + server端口号(端口号对应进程) 三个地址确定从主机出去之后给那个设备的进程()
入包配置ipvs内核数据先配置
recv-q
交换机只有二层,这里画的不对存在链路表 解决局域网之间链路表中ip和mac地址的映射
第三方实现
dma协处理器
cip:192.168.173.1win上vm8 ip
DR直接路由模式 应用较多
此时这里的netstat -natp需要存在 vip---->cip 关系 才可以封装出上面的返回包此时server1这个服务器上需要存在一个localaddress的地址为vipc此时的一个局域网内出现了二个vip地址冲撞了如何解决?当每个server仅仅知道自己存在vip不就可以了 那么如何隐藏这个vip地址(对外隐藏 对内可见)
cip---->vip | vip@mac
cd /etc/sysconfig/network-scripts/ifcfg-eth0 找到系统配置文件 中eth0网卡配置DEVICE=eth0TYPE=EthernetONBOOT=yes 在开机或重启网卡的时候是否启动网卡NM_CONTROLLED=yesBOOTPROTO=staticIPADDR=192.168.17.66 该计算机的ip地址 点分字节(一个点隔开的为一个字节 所以每个.之间大小0-255)NETMASK=255.255.255.0 掩码 使用ip+掩码会发生二进制的按位与 得到网络号(可以理解为局域网中)NETAWAY=192.168.17.2 网关 DNS1=114.114.114 域名解析地址 域名与映射ip的一张表(从运营商dns库拉取保存到本地) 访问域名 现在本机的dns找到对应的ip地址我这里ip与ifconfig结果不一样需要配置
网卡设备
借助server端隐藏的vip地址 就可以不丢弃 cip---->vip包
①:192.168.173.7:1234-->129.164.123.123:80
tomcat 内部存在资源 访问该资源 开辟的端口为8080(监听端口)(对应该进程)
hold住握手接入层做分流
关于lvs和nginx lvs基于四层(物理层 链路层 网络层 传输控制层(仅仅是窥探数据包端口))并没有与客户端建立三次握 手 以及与服务器建立三次握手, (直接为客户端与服务器建立三次握手 在DR模型下 数据包cip--->vip从client到服务器) nginx基于七层负载:也就是导致需要与client建立握手和断开 且处在应用层每次均需要用户态和内核 态的切换性能方面不如lvs
重点:
129.164.123.123:80为想要访问的ip地址
应用层
该网卡的能力直接转发给操作系统压根没有走到物理网卡
nginx运行于应用层(七层模型下)
HA实验手册HA借助keepalived实现
设备当中如何去路由 如何找到链接点?ip地址所在处下一跳机制:如家庭网络个人使用的电脑ip为路由器分配的,此时
四元组
当将 nginx换成lvs这种四层的(lvs不需要于tomcat建立三次握手,(客户端直接和tomcat建立握手)此时由于负载均衡器没有到达七层 所有无法得到应用层使用什么协议来发送数据(如http协议的 'GET / HTTP/1.1\') :该协议包括请求路径下的资源 / ;此时使用四层无法获取解析应用层的协议(就算获取也无法解析)所以只能在传输控制层窥探到ip和端口那么也就是不知道那些tomcat存在该所需要的资源 所以tomcat只能部署镜像的资源nginx原理:基于反向代理的负载均衡的话 那么后端服务 器可以不一样如果nginx知道client发送什么url的话,那么nginx一定要与客户端建立一次握手的过程?这是为什么?
①:如果使用单个lvs做负载均衡 当lvs挂了之后即使后面的server以后存活也不会暴露vip 请求也蹦跶不了server中 整体服务不可用②:当存在部分真实server挂了之后 此时lvs中还存在记录 也会负载到挂了的server 结果就是负载到没有挂了的依然可以提供服务,负载到挂了的服务器则 没法提供服务引出的二个问题: ①:lvs挂了 出现单点故障 ②:后端的真实服务器的健康检查(也就是真实服务器是否挂了) 当检查存在问题 需要将该真实 服务器在lvs中的条目剔除 规避负载[root@huang /]# ipvsadm -lnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 192.168.173.127:80 rr //为lvs -> 192.168.173.129:80 Route 1 0 0 -> 192.168.173.130:80 Route 1 0 0 问题的解决: 单点故障解决方式:加入多点 思路一:主备 master挂了 backup以最快的速度获取master的vip(用的较多) 思路二:主主 一开始就存在二个master 均可以对外提供服务那么 那么就需要存在二个vip(且相同导致ip冲突) 此时需要借助动态dns 加在二个lvs前面搭建主备: 需要讨论: 方向性:backup如何知道master挂了? 方式一:backup主动去询问master是否存活,存在二三台backup主动发送数据包 给 master master返回响应 方式二:master周期性的向外发送一个广播包给backup;收到这个包那么认为master还 存活 (选择这种实现方式) 由于网络存在波动等问题 会重置 (也就是上述不会一次就会切换) 效率性:如何在多个bakcup选择哪一个作为master 给每个backup添加权重主备和主从的关系: 主备:存在一个运行中 其他的为backup,在master运行的时候 只接收来自master的广播 主从: 几个点协作完成系统业务 此时如果主是单点还需要给主做主备 ------------------------------------------------------------------------------------------- 上述如何判定lvs的master挂了?以及挂了如何将vip怼到backup?以及如何选举出backup作为 下一个master? 那么需要存在一个存在一个应用程序(非内核模块) ①:监控master lvs的状态(是否向backup广播数据包 此时在backup中还是使用这个程 序去接受这个包 判定lvs状态) ②:检查后端真实服务器的健康(当后端服务器存在问题 则将这个服务器从ipvsadm -ln 中 剔除) 当后端服务器修复之后 将其重新加到负载条目中上述可用keepalived替代 实现自动运维 实现高可用HA 200ms内实现切换
[root@huang fd]# exec 8<> /dev/tcp/www.baidu.com/80(磁盘路径(此时还在内存中所以此路径下找不到该目录) 在内核中会转换成一个socket四元组) //这里创建一个fd 8 且建立一个连接连接四元组的输入输出通道lrwx------. 1 root root 64 Sep 6 17:45 8 -> socket:[139610] 创建一个文件描述符8() 支持输入和输出 http协议(规范和约定 通讯的时候应该说什么话 语言规范(说英文和中文的区别)也就是二端的通讯中间如何表述数据 如何加密)现在client如何通过socket将遵循http协议的数据如何提交给百度服务器?①:[root@huang fd]# echo -e 'GET / HTTP/1.0\' >& 8 echo重定向 原先echo指向bash终端 这里>为重定向输出 -e的选项可以使得/n 变为换 行符 注意: echo \"hello\" > hello.txt > 直接+文件 >& 8 后面表示文件描述符②:GET / HTTP/1.0\ 为http协议 请求头规定的request请求最小的写法 获取通过 / 根目录下的文件 HTTP/1.0 http协议版本 + \换行符(协议 规定需要换行符) ③:此时百度服务器 response返回 由于8为输入输出 所以response返回的还在8 所以[root@huang fd]# cat 0<& 8(8为应用层 与四元组fd的链接读取和输出 在更如bash自带的0 标准输出到/dev/pts2终端(也就是屏幕))
后序会使用zookeeper高可用集群的方式来解决这个问题:之前的keepalived也是单点在用 也不可靠,引入zookeeper集群提高可靠性
上述如何解决?
0 条评论
下一页