(四)高并发负载均衡：基于keepalived的LVS高可用搭建

一，4层和7层的区别

要分清哪些程序是应用层的，哪些程序是内核的。
LVS四层负载均衡服务器，是不会碰握手这一个步骤的。
Nginx是基于反向代理（七层）的负载均衡服务器，要先握手建立连接，才能取到URI，在判定location是否匹配，然后才将URI传递给后面的服务器。
server返回数据时，是需要过Nginx服务器的，而使用LVS的时候不会过LVS服务器。

（一）四层负载均衡

（二）七层nginx 基于反向代理的负载均衡

比LVS多了一次三次握手的连接。

二，单台四层负载均会出现的问题

（一）如果你的LVS负载均衡服务器挂掉了，你整个公司的业务就下线了，这是不能容忍的，这属于单点故障。

解决方法：一变多！但是入口的IP地址只能有一个，怎么变多？怎么实现多点？有2种形式：要么是主备，要么是主主
主备模型：备用机要以最快的速度接管原来的VIP（virtual IP），只有主机对外提供服务，只有主机挂了的时候，备机才顶上去。
主主模型：所有的LVS都是主，现在要借用其他形式搞定只有一个的入口IP地址，比如动态DNS。主和主之间是协作的形式。
我们首先讨论主备，有两个点需要考虑：方向性、效率性。

怎么知道主机挂没挂？
可以由备机轮询主机，但是这样会对主或多或少造成一些压力。
可以由主机发广播到所有的备机，但是网络是不可靠的，所以有一种重试机制。

如果已经确定主机挂了，谁来作为新的主机？
使用加权重的方式，这也是paxos和zookeeper的区别。官方压测200ms就能选出新的主机出来。
(皇帝挂了，孝悌，长兄为父)

（二）如果你后台的某一个RS（Real Server）挂掉了，负载均衡服务器还会对另外两台正常连接，会造成一部分人的业务请求异常，另一部分人的业务正常。

1，怎么知道RS挂了？可以用ping吗？

不可以！ping命令是网络层的只能检验网络层能不能通，连TCP握手都不做，而web服务是应用层的。能ping通不能代表web服务可用，连TCP都不能确定是否存活。那怎么知道RS挂没挂？最简单的方式是“访问一下”。
“访问一下”这个操作，它的底层验证的是 应用层的HTTP协议，
发请求 -> 判断 返回 200 ok

LVS内核中有模块：ipvs负载均衡模块。你想要检测各个RS是否可用的话，可以直接去修改模块的源码，也可以使用第三方实现。第三方可以是人，把人解耦出去也就是自动化（也就有了自动化运维）。

这个自动化的程序就是keepalived！它可以代替人工，实现自动运维。解决LVS单点故障，实现高可用HA。

三，keepalived

（一）keepalived的5条特性

（1）监控自己的LVS服务
（2）每一台机器上都安装keepalived。Master（主机）通告自己还活着，Backup（备机）监听Master状态。如果Master挂了，一堆Backup推举选出一个新的Master.
（3）配置：你不需要再手动配置VIP，添加LVS（ipvs模块）配置，只需要写到配置文件中即可。
（4）对后端的RS（real server）做健康检查，及时剔除不可用的节点
（5）keepalived不仅仅用来解决LVS，它是一个通用的环境，主要作为linux上的HA的实现。例如，当你并发量不大的时候，nginx可以作为公司的负载均衡来使用，此时nginx成为了单点故障。这个问题也可以用keepalived来解决。

（二）keepalived的高可用测量

LVS：没有数据同步的情况，所以可以抢回来主，面向数据包的负载。所有负载操作对用户是透明的。

LVS 非正常死亡，回收程序来不及回来VIP配置，导致node01和node04都有vip,会导致三次和四次的数据包混乱，破坏原子性。
可以使用zookeepr解决这个问题
没有百分百，zookeepr过半机制，如果都挂掉没人管，也会死亡。

（三）keepalived实验手册

（四）keepalived主备的搭建过程

主备：备用机的配置，不需要跟主机的配置相同，有个缓冲时间，把主机重启修复就行，可以节约成本。

1，主机： 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：虚拟路由冗余协议！
虚拟路由冗余协议(Virtual Router Redundancy Protocol，简称VRRP)是由IETF提出的解决局域网中配置静态网关出现单点失效现象的路由协议，1998年已推出正式的RFC2338协议标准。VRRP广泛应用在边缘网络中，它的设计目标是支持特定情况下IP数据流量失败转移不会引起混乱，允许主机使用单路由器，以及即使在实际第一跳路由器使用失败的情形下仍能够维护路由器间的连通性。
通过VRRP，可以在主机的下一跳设备出现故障时，及时将业务切换到备份设备，从而保障网络通信。
如果配置不会写 帮助文档： man 5 keepalied 

				vrrp_instance VI_1 {
					state MASTER         //  node04  角色： state  BACKUP
					interface eth0
					virtual_router_id 51
					priority 100		        //	 node04	权重： priority  50
					advert_int 1
					authentication {
						auth_type PASS
						auth_pass 1111
					}
					virtual_ipaddress {
						192.168.150.100/24 dev eth0 label  eth0:3
					}
				}
         // 想当于  ipvladm -a 
			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
					}   
				}       


            //转发到node04 远程拷贝
			scp  ./keepalived.conf  root@node04:`pwd`

2，备机node02,node03

 跟单机一致，省略

3，启动

四，自己实操搭建

（一）配置

我安装的版本是 keepalived.x86_64 0:1.3.5-19.el7

yum install keepalived ipvsadm -y
vi /etc/keepalived/keepalived.conf

! Configuration File for keepalived

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              //BACKUP
    interface ens33             //用自己网卡的名称
    virtual_router_id 51
    priority 100                    //50
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.141.100/24 dev ens33 label ens33:3
    }
}

virtual_server 192.168.141.100 80 {
    delay_loop 6
    lb_algo rr 
    lb_kind NAT
    persistence_timeout 50
    protocol TCP
    real_server 192.168.141.142 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.141.141 80 {
        weight 1
        HTTP_GET {
            url { 
              path /
              status_code 200
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

（二）验证

service keepalived start
//感觉启动有延迟

主节点stop备机会有对应的网卡设置出现，主节点重新start时对应网卡设置消失。
备机需要关闭防火墙
systemctl stop firewalld.service