Keepalive

1 What is Keepalived ?

Keepalived is a routing software written in C.
The main goal of this project is to provide simple and robust facilities for loadbalancing and high-availability to Linux system and Linux based infrastructures.
Loadbalancing framework relies on well-known and widely used Linux Virtual Server (IPVS) kernel module providing Layer4 loadbalancing. Keepalived implements a set of checkers to dynamically and adaptively maintain and manage loadbalanced server pool according their health.
On the other hand high-availability is achieved by VRRP protocol. VRRP is a fundamental brick for router failover.
In addition, Keepalived implements a set of hooks to the VRRP finite state machine providing low-level and high-speed protocol interactions. Keepalived frameworks can be used independently or all together to provide resilient infrastructures.
官网:http://www.keepalived.org/

Usefull links: http://www.keepalived.org/documentation.html
必读:http://www.keepalived.org/pdf/sery-lvs-cluster.pdf

Keepalived是一个基于VRRP协议来实现的WEB 服务高可用方案,可以利用其来避免单点故障。一个WEB服务至少会有2台服务器运行Keepalived,一台为主服务器(MASTER),一台为备份服务器(BACKUP),但是对外表现为一个虚拟IP,主服务器会发送特定的消息给备份服务器,当备份服务器收不到这个消息的时候,即主服务器宕机的时候,备份服务器就会接管虚拟IP,继续提供服务,从而保证了高可用性。
这里写图片描述

1.1 IPVS

1.2 VRRP

1.2.1 概念

keepalived的工作原理是VRRP(Virtual Router Redundancy Protocol)虚拟路由冗余协议。
在VRRP中有两组重要的概念:VRRP路由器和虚拟路由器,主控路由器和备份路由器。
VRRP路由器是指运行VRRP的路由器,是物理实体,虚拟路由器是指VRRP协议创建的,是逻辑概念。一组VRRP路由器协同工作,共同构成一台虚拟路由器。
Vrrp中存在着一种选举机制,用以选出提供服务的路由即主控路由,其他的则成了备份路由。当主控路由失效后,备份路由中会重新选举出一个主控路由,来继续工作,来保障不间断服务。

1.2.2 VRRP协议过程简述

VRRP 将局域网的一组路由器(包括一个Master 即活动路由器和若干个Backup 即备份路由器)组织成一个虚拟路由器,称之为一个备份组。这个虚拟的路由器拥有自己的IP 地址10.100.10.1(这个IP 地址可以和备份组内的某个路由器的接口地址相同,相同的则称为ip拥有者),备份组内的路由器也有自己的IP 地址(如Master的IP 地址为10.100.10.2,Backup 的IP 地址为10.100.10.3)。局域网内的主机仅仅知道这个虚拟路由器的IP 地址10.100.10.1,而并不知道具体的Master 路由器的IP 地址10.100.10.2 以及Backup 路由器的IP 地址10.100.10.3。[1]它们将自己的缺省路由下一跳地址设置为该虚拟路由器的IP 地址10.100.10.1。于是,网络内的主机就通过这个虚拟的路由器来与其它网络进行通信。如果备份组内的Master 路由器坏掉,Backup 路由器将会通过选举策略选出一个新的Master 路由器,继续向网络内的主机提供路由服务。从而实现网络内的主机不间断地与外部网络进行通信。

1.2.3 VRRP原理

一个VRRP路由器有唯一的标识:VRID,范围为0—255该路由器对外表现为唯一的虚拟MAC地址,地址的格式为00-00-5E-00-01-[VRID]主控路由器负责对ARP请求用该MAC地址做应答这样,无论如何切换,保证给终端设备的是唯一一致的IP和MAC地址,减少了切换对终端设备的影响[3]
VRRP控制报文只有一种:VRRP通告(advertisement)它使用IP多播数据包进行封装,组地址为224.0.0.18,

root@node133:~# tcpdump vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:29:48.670190 IP bogon > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype none, intvl 1s, length 20
root@node133:~# ping vrrp.mcast.net
PING vrrp.mcast.net (224.0.0.18) 56(84) bytes of data.

发布范围只限于同一局域网内这保证了VRID在不同网络中可以重复使用为了减少网络带宽消耗只有主控路由器才可以周期性的发送VRRP通告报文备份路由器在连续三个通告间隔内收不到VRRP或收到优先级为0的通告后启动新的一轮VRRP选举[3]
在VRRP路由器组中,按优先级选举主控路由器,VRRP协议中优先级范围是0—255若VRRP路由器的IP地址和虚拟路由器的接口IP地址相同,则称该虚拟路由器作VRRP组中的IP地址所有者;IP地址所有者自动具有最高优先级:255优先级0一般用在IP地址所有者主动放弃主控者角色时使用可配置的优先级范围为1—254优先级的配置原则可以依据链路的速度和成本路由器性能和可靠性以及其它管理策略设定主控路由器的选举中,高优先级的虚拟路由器获胜,因此,如果在VRRP组中有IP地址所有者,则它总是作为主控路由的角色出现对于相同优先级的候选路由器,按照IP地址大小顺序选举VRRP还提供了优先级抢占策略,如果配置了该策略,高优先级的备份路由器便会剥夺当前低优先级的主控路由器而成为新的主控路由器[3]
为了保证VRRP协议的安全性,提供了两种安全认证措施:明文认证和IP头认证明文认证方式要求:在加入一个VRRP路由器组时,必须同时提供相同的VRID和明文密码适合于避免在局域网内的配置错误,但不能防止通过网络监听方式获得密码IP头认证的方式提供了更高的安全性,能够防止报文重放和修改等攻击。

2 安装

2.1 下载安装包安装
下载:# wget http://www.keepalived.org/software/keepalived-1.3.2.tar.gz

【依赖库】
ubuntu
apt-get install gcc openssl libpopt-dev libssl-dev

centos
yum install popt-devel openssl-devel popt-devel

./configure –prefix=/usr
make
make install
2.2 Ubuntu apt安装

root@zhai:~# apt-get install keepalived

如果出错,要用apt-get update and upgrade更新。

3 Heartbeat、Corosync、Keepalived这三个集群组件我们到底选哪个好

Heartbeat、Corosync是属于同一类型,Keepalived与Heartbeat、Corosync,根本不是同一类型的。
Keepalived使用的vrrp协议方式,虚拟路由冗余协议 (Virtual Router Redundancy Protocol,简称VRRP);Heartbeat或Corosync是基于主机或网络服务的高可用方式;
简单的说就是,Keepalived的目的是模拟路由器的高可用,Heartbeat或Corosync的目的是实现Service的高可用。所以一般Keepalived是实现前端高可用,常用的前端高可用的组合有,就是我们常见的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。
而Heartbeat或Corosync是实现服务的高可用,常见的组合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 实现Web服务器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 实现MySQL服务器的高可用。

总结一下,Keepalived中实现轻量级的高可用,一般用于前端高可用,且不需要共享存储,一般常用于两个节点的高可用。而Heartbeat(或Corosync)一般用于服务的高可用,且需要共享存储,一般用于多节点的高可用。这个问题我们说明白了,又有博友会问了,那heartbaet与corosync我们又应该选择哪个好啊,我想说我们一般用corosync,因为corosync的运行机制更优于heartbeat,就连从heartbeat分离出来的pacemaker都说在以后的开发当中更倾向于corosync,所以现在corosync+pacemaker是最佳组合。

4 keepalived 安装验证

/keepalive –D ,然后来检查
keepalived 运行后的状况。
1、 查看进程 ps aux | grep keepalived ,其输出为:
[root@lvs-m ~]# ps aux| grep keepalived |grep -v grep
root 21786 0.0 0.0 4840 564 ? Ss 15:39 0:00 keepalived
-D
root 21787 4.8 0.0 4884 1336 ? S 15:39 23:47
keepalived -D
root 21788 4.9 0.0 4884 904 ? S 15:39 24:15
keepalived -D
Keepalived 正常运行时,共启动 3 个进程,其中一个进程是父进程,负责监控其子进程;一
个是 vrrp 子进程;另外一个是 checkers 子进程。 keepalived 3 个进程之间的关系。
root@lb-haproxy-1152:/opt# pstree | grep keep
|-keepalived—2*[keepalived]

2、 查看内核模块,ip_vs 模块应该被加载到内核空间。 Lsmod | grep ip_vs .
3、 查看系统日志。因为我在启动 keepalived 是使用了选项 –D ,这将详细的打印日志消息。
[root@lvs-m ~]# tail -f /var/log/messages

5 keepalived.conf配置文件说明

keepalived服务安装完成之后,后面的主要工作就是在keepalived.conf文件中配置HA和负载均衡。一个功能比较完整的常用的keepalived配置文件,主要包含三块:全局定义块、VRRP实例定义块和虚拟服务器定义块。全局定义块是必须的,如果keepalived只用来做ha,虚拟服务器是可选的。下面是一个功能比较完整的配置文件模板:

全局定义块

global_defs {
    # 邮件通知配置
    notification_email {
        email1
        email2
    }
    notification_email_from email
    smtp_server host
    smtp_connect_timeout num

    lvs_id string
    router_id string    ## 标识本节点的字条串,通常为hostname
}

VRRP 实例定义块

vrrp_sync_group string { 
    group {
        string
        string
    }
}

vrrp_instance string {
    state MASTER|BACKUP
    virtual_router_id num
    interface string
    mcast_src_ip @IP 
    priority num
    advert_int num
    nopreempt
    smtp_alert
    lvs_sync_daemon_interface string 
    authentication {
        auth_type PASS|AH
        auth_pass string
    }

    virtual_ipaddress {  # Block limited to 20 IP addresses @IP
        @IP
        @IP
    }
}

虚拟服务器定义块

virtual_server (@IP PORT)|(fwmark num) { 
    delay_loop num
    lb_algo rr|wrr|lc|wlc|sh|dh|lblc 
    lb_kind NAT|DR|TUN
    persistence_timeout num 
    protocol TCP|UDP
    real_server @IP PORT { 
        weight num
        notify_down /path/script.sh
        TCP_CHECK { 
            connect_port num 
            connect_timeout num
        }
    }

    real_server @IP PORT {
        weight num
        MISC_CHECK {
            misc_path /path_to_script/script.sh(or misc_path “/path_to_script/script.sh <arg_list>”)
        }
    }

    real_server @IP PORT {
        weight num
        HTTP_GET|SSL_GET {
            url { 
                # You can add multiple url block path alphanum
                digest alphanum
            }
            connect_port num
            connect_timeout num 
            nb_get_retry num 
            delay_before_retry num
        }
    }
}

全局定义块

1、email通知(notification_email、smtp_server、smtp_connect_timeout):用于服务有故障时发送邮件报警,可选项,不建议用。需要系统开启sendmail服务,建议用第三独立监控服务,如用nagios全面监控代替。
2、lvs_id:lvs负载均衡器标识,在一个网络内,它的值应该是唯一的。
3、router_id:用户标识本节点的名称,通常为hostname
4、花括号{}:用来分隔定义块,必须成对出现。如果写漏了,keepalived运行时不会得到预期的结果。由于定义块存在嵌套关系,因此很容易遗漏结尾处的花括号,这点需要特别注意。

VRRP实例定义块

vrrp_sync_group:同步vrrp级,用于确定失败切换(FailOver)包含的路由实例个数。即在有2个负载均衡器的场景,一旦某个负载均衡器失效,需要自动切换到另外一个负载均衡器的实例是哪
group:至少要包含一个vrrp实例,vrrp实例名称必须和vrrp_instance定义的一致
vrrp_instance:vrrp实例名
1> state:实例状态,只有MASTER 和 BACKUP两种状态,并且需要全部大写。抢占模式下,其中MASTER为工作状态,BACKUP为备用状态。当MASTER所在的服务器失效时,BACKUP所在的服务会自动把它的状态由BACKUP切换到MASTER状态。当失效的MASTER所在的服务恢复时,BACKUP从MASTER恢复到BACKUP状态。
2> interface:对外提供服务的网卡接口,即VIP绑定的网卡接口。如:eth0,eth1。当前主流的服务器都有2个或2个以上的接口(分别对应外网和内网),在选择网卡接口时,一定要核实清楚。
3> mcast_src_ip:本机IP地址
4> virtual_router_id:虚拟路由的ID号,每个节点设置必须一样,可选择IP最后一段使用,相同的 VRID 为一个组,他将决定多播的 MAC 地址。
5> priority:节点优先级,取值范围0~254,MASTER要比BACKUP高
6> advert_int:MASTER与BACKUP节点间同步检查的时间间隔,单位为秒
7> lvs_sync_daemon_inteface:负载均衡器之间的监控接口,类似于 HA HeartBeat 的心跳线。但它的机制优于 Heartbeat,因为它没有“裂脑”这个问题,它是以优先级这个机制来规避这个麻烦的。在 DR 模式中,lvs_sync_daemon_inteface与服务接口interface使用同一个网络接口
8> authentication:验证类型和验证密码。类型主要有 PASS、AH 两种,通常使用PASS类型,据说AH使用时有问题。验证密码为明文,同一vrrp 实例MASTER与BACKUP使用相同的密码才能正常通信。
9> smtp_alert:有故障时是否激活邮件通知
10> nopreempt:禁止抢占服务。默认情况,当MASTER服务挂掉之后,BACKUP自动升级为MASTER并接替它的任务,当MASTER服务恢复后,升级为MASTER的BACKUP服务又自动降为BACKUP,把工作权交给原MASTER。当配置了nopreempt,MASTER从挂掉到恢复,不再将服务抢占过来。
11> virtual_ipaddress:虚拟IP地址池,可以有多个IP,每个IP占一行,不需要指定子网掩码。注意:这个IP必须与我们的设定的vip保持一致。
虚拟服务器virtual_server定义块

virtual_server:定义一个虚拟服务器,这个ip是virtual_ipaddress中定义的其中一个,后面一个空格,然后加上虚拟服务的端口号。
1> delay_loop:健康检查时间间隔,单位:秒
2> lb_algo:负载均衡调度算法,互联网应用常用方式为wlc或rr
3> lb_kind:负载均衡转发规则。包括DR、NAT、TUN 3种,一般使用路由(DR)转发规则。
4> persistence_timeout:http服务会话保持时间,单位:秒
5> protocol:转发协议,分为TCP和UDP两种
real_server:真实服务器IP和端口,可以定义多个
1> weight:负载权重,值越大,转发的优先级越高
2> notify_down:服务停止后执行的脚本
3> TCP_CHECK:服务有效性检测
* connect_port:服务连接端口
* connect_timeout:服务连接超时时长,单位:秒
* nb_get_retry:服务连接失败重试次数
* delay_before_retry:重试连接间隔,单位:秒

6 部署keepalived作为web服务器的HA

配置keepalived
配置中的state MASTER决定了节点为主节点
priority决定了优先级,比如在有多个备用节点的时候,主节点故障后优先级值大的接管。
主节点的配置如下:

global_defs {  
    router_id NodeA  
}  
vrrp_instance VI_1 {  
    state MASTER    #设置为主服务器  
    interface eth0  #监测网络接口  
    virtual_router_id 51  #主、备必须一样  
    priority 100   #(主、备机取不同的优先级,主机值较大,备份机值较小,值越大优先级越高)  
    advert_int 1   #VRRP Multicast广播周期秒数  
    authentication {  
    auth_type PASS  #VRRP认证方式,主备必须一致  
    auth_pass 1111   #(密码)  
}  
virtual_ipaddress {  
    192.168.8.100/24  #VRRP HA虚拟地址  
}  

备用节点的配置如下:

global_defs {  
    router_id NodeB  
}  
vrrp_instance VI_1 {  
    state BACKUP    #设置为从服务器  
    interface eth0  #监测网络接口  
    virtual_router_id 51  #主、备必须一样  
    priority 90   #(主、备机取不同的优先级,主机值较大,备份机值较小,值越大优先级越高)  
    advert_int 1   #VRRP Multicast广播周期秒数  
    authentication {  
    auth_type PASS  #VRRP认证方式,主备必须一致  
    auth_pass 1111   #(密码)  
}  
virtual_ipaddress {  
    192.168.8.100/24  #VRRP HA虚拟地址  
}  

3,启动keepalived:
keepalived -D -f /usr/local/etc/keepalived/keepalived.conf
查看log消息:
tail -f /var/log/messages
启动主节点A后的日志为:会广播ARP消息

[root@srv4 ~]# tail -f /var/log/messages  
Sep 20 01:45:29 srv4 Keepalived_vrrp: Configuration is using : 34546 Bytes  
Sep 20 01:45:29 srv4 Keepalived_vrrp: VRRP sockpool: [ifindex(2), proto(112), fd(8,9)]  
Sep 20 01:45:30 srv4 Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER STATE  
Sep 20 01:45:31 srv4 Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE  
Sep 20 01:45:31 srv4 Keepalived_vrrp: VRRP_Instance(VI_1) setting protocol VIPs.  
Sep 20 01:45:31 srv4 Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.8.100  
Sep 20 01:45:31 srv4 Keepalived_vrrp: Netlink reflector reports IP 192.168.8.100 added  
Sep 20 01:45:31 srv4 Keepalived_healthcheckers: Netlink reflector reports IP 192.168.8.100 added  
Sep 20 01:45:31 srv4 avahi-daemon[4029]: Registering new address record for 192.168.8.100 on eth0.  
Sep 20 01:45:36 srv4 Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.8.100  

通过ip a 命令可以看到192.168.8.100/24绑定到了eth0上

[root@srv4 bin]# ip a  
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue   
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00  
    inet 127.0.0.1/8 scope host lo  
    inet6 ::1/128 scope host   
       valid_lft forever preferred_lft forever  
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000  
    link/ether 00:0c:29:50:2d:9d brd ff:ff:ff:ff:ff:ff  
    inet 192.168.8.4/24 brd 192.168.8.255 scope global eth0  
    inet 192.168.8.100/24 scope global secondary eth0  
    inet6 fe80::20c:29ff:fe50:2d9d/64 scope link   
       valid_lft forever preferred_lft forever  

启动备用节点B后的日志为:

[html] view plain copy
Sep 20 01:47:31 hadoopsrv Keepalived_vrrp: Configuration is using : 34262 Bytes  
Sep 20 01:47:31 hadoopsrv Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP STATE  
Sep 20 01:47:31 hadoopsrv Keepalived_vrrp: VRRP sockpool: [ifindex(2), proto(112), fd(7,8)]  
Sep 20 01:47:31 hadoopsrv Keepalived: Starting VRRP child process, pid=20567  

实验:
1 停掉其中master服务器,另一个服务器后自动配置好VIP
停掉132服务器后,133自动配置好VIP

root@node133:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:69:7f:2b brd ff:ff:ff:ff:ff:ff
    inet 192.168.50.133/24 brd 192.168.50.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.50.139/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe69:7f2b/64 scope link 
       valid_lft forever preferred_lft forever

2 配置中都设置为state BACKUP,

root@node132:~# tcpdump vrrp
16:10:08.565789 IP node133 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 90, authtype none, intvl 1s, length 20
16:10:09.566801 IP bogon > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype none, intvl 1s, length 20
16:10:09.566896 IP node133 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 90, authtype none, intvl 1s, length 20
16:10:10.567814 IP bogon > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype none, intvl 1s, length 20
16:10:11.568077 IP bogon > vrrp.mcast.net: VRRPv2, Advertisement, vrid 51, prio 100, authtype none, intvl 1s, length 20

http://atong.blog.51cto.com/2393905/1351479
http://blog.csdn.net/kkdelta/article/details/39433137

参考:
1 http://freeloda.blog.51cto.com/2033581/1280962

Linux服务器集群系统(一) – LVS项目介绍
Linux服务器集群系统(二)–LVS集群的体系结构
Linux服务器集群系统(三)–LVS集群中的IP负载均衡技术
Linux服务器集群系统(四) – LVS集群的负载调度

LVS原理详解及部署之一:ARP原理准备
LVS原理详解及部署之二:LVS原理详解(3种工作方式8种调度算法)
LVS原理详解及部署之三:手动部署LVS
LVS原理详解及部署之四:keepalived介绍

lvs
https://blog.csdn.net/admin_root1/article/details/78911731

高并发场景 LVS 安装及高可用实现
原创 2017年12月27日 14:18:24 2112
1.1 负载均衡介绍

1.1.1 负载均衡的妙用

负载均衡(Load Balance)集群提供了一种廉价、有效、透明的方法,来扩展网络设备和服务器的负载、带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

ü 单台计算机无法承受大规模的并发访问或数据流量了,此时需要搭建负载均衡集群把流量分摊到多台节点设备上分别处理,即减少用户等待响应的时间又提升了用户体验;

ü 7*24小时的服务保证,任意一个或多个有限后端节点设备宕机,不能影响整个业务的运行。

1.1.2 为什么要用lvs

n 工作在网络模型的7层,可以针对http应用做一些分流的策略,比如针对域名、目录结构,Nginx单凭这点可利用的场合就远多于LVS了。

n 最新版本的Nginx也支持4层TCP负载,曾经这是LVS比Nginx好的地方。

n Nginx对网络稳定性的依赖非常小,理论上能ping通就就能进行负载功能,这个也是它的优势之一,相反LVS对网络稳定性依赖比较大。

n Nginx安装和配置比较简单,测试起来比较方便,它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了,LVS对网络依赖比较大。

那为什么要用lvs呢?

ü 简单一句话,当并发超过了Nginx上限,就可以使用LVS了。

ü 日1000-2000W PV或并发请求1万以下都可以考虑用Nginx。

ü 大型门户网站,电商网站需要用到LVS。

1.2 LVS介绍

LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统,可以在UNIX/LINUX平台下实现负载均衡集群功能。该项目在1998年5月由章文嵩博士组织成立,是中国国内最早出现的自由软件项目之一。

1.2.1 相关参考资料

LVS官网:http://www.linuxvirtualserver.org/index.html

相关中文资料

[python] view plain copy
LVS项目介绍 http://www.linuxvirtualserver.org/zh/lvs1.html
LVS集群的体系结构 http://www.linuxvirtualserver.org/zh/lvs2.html
LVS集群中的IP负载均衡技术 http://www.linuxvirtualserver.org/zh/lvs3.html
LVS集群的负载调度 http://www.linuxvirtualserver.org/zh/lvs4.html

1.2.2 LVS内核模块ip_vs介绍

早在2.2内核时, IPVS就已经以内核补丁的形式出现。

从2.4.23版本开始,IPVS软件就合并到Linux内核的常用版本的内核补丁的集合。

从2.4.24以后IPVS已经成为Linux官方标准内核的一部分。

ü LVS无需安装

ü 安装的是管理工具,第一种叫ipvsadm,第二种叫keepalive

ü ipvsadm是通过命令行管理,而keepalive读取配置文件管理

ü 后面我们会用Shell脚本实现keepalive的功能

1.3 LVS集群搭建

1.3.1 集群环境说明

主机名
IP地址
软件
系统版本
lb03
10.0.0.15
lvs keepalived
CentOS Linux release 7.4.1708
lb04
10.0.0.16
lvs keepalived
CentOS Linux release 7.4.1708
web03
10.0.0.18
tomcat
CentOS Linux release 7.4.1708
web04
10.0.0.17
tomcat
CentOS Linux release 7.4.1708
主机说明

[root@lb03 ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
[root@lb03 ~]# uname -a
Linux lb03 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@lb03 ~]# systemctl status firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:firewalld(1)
[root@lb03 ~]# getenforce
Disabled
web环境说明

[root@lb03 ~]# curl 10.0.0.17
web03
[root@lb03 ~]# curl 10.0.0.18
web04
  web服务器的搭建参照: Tomcat: http://www.cnblogs.com/clsn/p/7904611.html

              Nginx: http://www.cnblogs.com/clsn/p/7750615.html

1.3.2 安装ipvsadm管理工具

安装管理工具

yum -y install ipvsadm
查看当前LVS状态,顺便激活LVS内核模块。

ipvsadm
查看系统的LVS模块。

[root@lb03 ~]# lsmod|grep ip_vs
ip_vs_wrr 12697 1
ip_vs 141092 3 ip_vs_wrr
nf_conntrack 133387 1 ip_vs
libcrc32c 12644 3 xfs,ip_vs,nf_conntrack
1.3.3 LVS集群搭建

配置LVS负载均衡服务(在lb03操作)

步骤1:在eth0网卡绑定VIP地址(ip)

步骤2:清除当前所有LVS规则(-C)

步骤3:设置tcp、tcpfin、udp链接超时时间(–set)

步骤4:添加虚拟服务(-A),-t指定虚拟服务的IP端口,-s 指定调度算法 调度算法见man ipvsadm, rr wrr 权重轮询 -p 指定超时时间

步骤5:将虚拟服务关联到真实服务上(-a) -r指定真实服务的IP端口 -g LVS的模式 DR模式 -w 指定权重

步骤6:查看配置结果(-ln)

命令集:

ip addr add 10.0.0.13/24 dev eth0
ipvsadm -C
ipvsadm –set 30 5 60
ipvsadm -A -t 10.0.0.13:80 -s wrr -p 20
ipvsadm -a -t 10.0.0.13:80 -r 10.0.0.17:80 -g -w 1
ipvsadm -a -t 10.0.0.13:80 -r 10.0.0.18:80 -g -w 1
ipvsadm -ln
检查结果:

[root@lb03 ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.0.0.13:80 wrr persistent 20
-> 10.0.0.17:80 Route 1 0 0
-> 10.0.0.18:80 Route 1 0 0
ipvsadm参数说明:(更多参照 man ipvsadm)

参数
(短格式)
参数
(长格式)
参数说明
-A
–add-service
在内核的虚拟服务器表中添加一条新的虚拟服务器记录。也就是增加一台新的虚拟服务器。
-E
–edit-service
编辑内核虚拟服务器表中的一条虚拟服务器记录。
-D
–delete-service
删除内核虚拟服务器表中的一条虚拟服务器记录。
-C
–clear
清除内核虚拟服务器表中的所有记录。
-R
–restore
恢复虚拟服务器规则
-S
–save
保存虚拟服务器规则,输出为-R 选项可读的格式
-a
–add-server
在内核虚拟服务器表的一条记录里添加一条新的真实服务器记录。也就是在一个虚拟服务器中增加一台新的真实服务器
-e
–edit-server
编辑一条虚拟服务器记录中的某条真实服务器记录
-d
–delete-server
删除一条虚拟服务器记录中的某条真实服务器记录
-L|-l
–list
显示内核虚拟服务器表
-Z
–zero

虚拟服务表计数器清零(清空当前的连接数量等)

–set tcp tcpfin udp

设置连接超时值

–start-daemon

启动同步守护进程。他后面可以是master 或backup,用来说明LVS Router 是master 或是backup。在这个功能上也可以采用keepalived 的VRRP 功能。

–stop-daemon
停止同步守护进程
-h
–help
显示帮助信息
-t
–tcp-service service-address [vip:port] or [real-server-ip:port]
说明虚拟服务器提供的是tcp 的服务
-u
–udp-service service-address [vip:port] or [real-server-ip:port]
说明虚拟服务器提供的是udp 的服务
-f
–fwmark-service fwmark
说明是经过iptables 标记过的服务类型。
-s
–scheduler scheduler
使用的调度算法,有这样几个选项
rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq
默认的调度算法是: wlc
-p
–persistent [timeout]
持久稳固的服务。这个选项的意思是来自同一个客户的多次请求,将被同一台真实的服务器处理。timeout 的默认值为300秒。
-M
–netmask netmask
persistent granularity mask
-r
–real-server server-address
真实的服务器[Real-Server:port]
-g
–gatewaying
指定LVS 的工作模式为直接路由模式(也是LVS 默认的模式)
-i
–ipip
指定LVS 的工作模式为隧道模式
-m
–masquerading
指定LVS 的工作模式为NAT 模式
-w
–weight weight

真实服务器的权值

–mcast-interface
interface 指定组播的同步接口
-c
–connection

显示LVS 目前的连接 如:ipvsadm -L -c

–timeout

显示tcp tcpfin udp 的timeout 值 如:ipvsadm -L –timeout

–daemon

显示同步守护进程状态

–stats

显示统计信息

–rate

显示速率信息

–sort

对虚拟服务器和真实服务器排序输出

–numeric -n
输出IP 地址和端口的数字形式
1.3.4 在web浏览器配置操作

步骤1:在lo网卡绑定VIP地址(ip)

步骤2:修改内核参数抑制ARP响应

命令集:

ip addr add 10.0.0.13/32 dev lo

cat >>/etc/sysctl.conf<

配置的内核参数

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
lvs在DR模式下需要关闭arp功能

arp_announce

对网络接口上,本地IP地址的发出的,ARP回应,作出相应级别的限制:

确定不同程度的限制,宣布对来自本地源IP地址发出Arp请求的接口

数值
含义
0(默认)
在任意网络接口(eth0,eth1,lo)上的任何本地地址
1
尽量避免不在该网络接口子网段的本地地址做出arp回应. 当发起ARP请求的源IP地址 是被设置应该经由路由达到此网络接口的时候很有用.此时会检查来访IP是否为所有接口 上的子网段内ip之一.如果改来访IP不属于各个网络接口上的子网段内,那么将采用级别2的方式来进行处理.
2
对查询目标使用最适当的本地地址.在此模式下将忽略这个IP数据包的源地址并尝试 选择与能与该地址通信的本地地址.首要是选择所有的网络接口的子网中外出访问子网中 包含该目标IP地址的本地地址. 如果没有合适的地址被发现,将选择当前的发送网络接口 或其他的有可能接受到该ARP回应的网络接口来进行发送.
arp_ignore定义

对目标地定义对目标地址为本地IP的ARP询问不同的应答模式0

数值
含义
0(默认值)
回应任何网络接口上对任何本地IP地址的arp查询请求
1
只回答目标IP地址是来访网络接口本地地址的ARP查询请求
2
只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内
3
不回应该网络界面的arp请求,而只对设置的唯一和连接地址做出回应
4-7
保留未使用
8
不回应所有(本地地址)的arp查询
抑制RS端arp前的广播情况

抑制RS端arp后广播情况

1.6 LVS集群的工作模式

[python] view plain copy
DR(Direct Routing)直接路由模式
NAT(Network Address Translation)
TUN(Tunneling)隧道模式
FULLNAT(Full Network Address Translation)
1.6.1 LVS集群的工作模式–NAT

通过网络地址转换,调度器LB重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器,真实服务器的响应报文处理之后,返回时必须要通过调度器,经过调度器时报文的源地址被重写,再返回给客户,完成整个负载调度过程。

收费站模式—来去都要经过LB负载均衡器。

NAT方式的实现原理和数据包的改变

[python] view plain copy
(a). 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP
(b). PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
(c). IPVS比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP,然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP
(d). POSTROUTING链通过选路,将数据包发送给Real Server
(e). Real Server比对发现目标为自己的IP,开始构建响应报文发回给Director Server。 此时报文的源IP为RIP,目标IP为CIP
(f). Director Server在响应客户端前,此时会将源IP地址修改为自己的VIP地址,然后响应给客户端。 此时报文的源IP为VIP,目标IP为CIP
LVS-NAT模型的特性

l RS应该使用私有地址,RS的网关必须指向DIP

l DIP和RIP必须在同一个网段内

l 请求和响应报文都需要经过Director Server,高负载场景中,Director Server易成为性能瓶颈

l 支持端口映射

l RS可以使用任意操作系统

l 缺陷:对Director Server压力会比较大,请求和响应都需经过director server

1.6.2 LVS集群的工作模式–隧道模式TUN

采用NAT技术时,由于请求和响应的报文都必须经过调度器地址重写,当客户请求越来越多时,调度器的处理能力将成为瓶颈,为了解决这个问题,调度器把请求的报文通过IP隧道(相当于ipip或ipsec )转发至真实服务器,而真实服务器将响应处理后直接返回给客户端用户,这样调度器就只处理请求的入站报文。由于一般网络服务应答数据比请求报文大很多,采用 VS/TUN技术后,集群系统的最大吞吐量可以提高10倍。

VS/TUN工作流程,它的连接调度和管理与VS/NAT中的一样,只是它的报文转发方法不同。调度器根据各个服务器的负载情况,连接数多少,动态地选择一台服务器,将原请求的报文封装在另一个IP报文中,再将封装后的IP报文转发给选出的真实服务器;真实服务器收到报文后,先将收到的报文解封获得原来目标地址为VIP地址的报文, 服务器发现VIP地址被配置在本地的IP隧道设备上(此处要人为配置),所以就处理这个请求,然后根据路由表将响应报文直接返回给客户。

TUN原理和数据包的改变

[python] view plain copy
(a) 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP 。
(b) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链
(c) IPVS比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层IP报文,封装源IP为为DIP,目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP,目标IP为RIP
(d) POSTROUTING链根据最新封装的IP报文,将数据包发至RS(因为在外层封装多了一层IP首部,所以可以理解为此时通过隧道传输)。 此时源IP为DIP,目标IP为RIP
(e) RS接收到报文后发现是自己的IP地址,就将报文接收下来,拆除掉最外层的IP后,会发现里面还有一层IP首部,而且目标是自己的lo接口VIP,那么此时RS开始处理此请求,处理完成之后,通过lo接口送给eth0网卡,然后向外传递。 此时的源IP地址为VIP,目标IP为CIP
(f) 响应报文最终送达至客户端
LVS-Tun模型特性

l RIP、VIP、DIP全是公网地址

l RS的网关不会也不可能指向DIP

l 所有的请求报文经由Director Server,但响应报文必须不能进过Director Server

l 不支持端口映射

l RS的系统必须支持隧道

1.6.3 LVS集群的工作模式–FULLNAT

LVS的DR和NAT模式要求RS和LVS在同一个vlan中,导致部署成本过高;TUNNEL模式虽然可以跨vlan,但RealServer上需要部署ipip隧道模块等,网络拓扑上需要连通外网,较复杂,不易运维。

为了解决上述问题,开发出FULLNAT,该模式和NAT模式的区别是:数据包进入时,除了做DNAT,还做SNAT(用户ip->内网ip),从而实现LVS-RealServer间可以跨vlan通讯,RealServer只需要连接到内网。

类比地铁站多个闸机。

1.7 IPVS调度器实现了如下八种负载调度算法:

  a) 轮询(Round Robin)RR

调度器通过”轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。

  b) 加权轮叫(Weighted Round Robin)WRR

调度器通过”加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

  c) 最少链接(Least Connections) LC

调度器通过”最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用”最小连接”调度算法可以较好地均衡负载。

  d) 加权最少链接(Weighted Least Connections) Wlc

在集群系统中的服务器性能差异较大的情况下,调度器采用”加权最少链接”调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

  e) 基于局部性的最少链接(Locality-Based Least Connections) Lblc

“基于局部性的最少链接” 调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器 是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用”最少链接”的原则选出一个可用的服务 器,将请求发送到该服务器。

  f) 带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)

“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组,按”最小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器,若服务器超载;则按”最小连接”原则从这个集群中选出一 台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的 程度。

  g) 目标地址散列(Destination Hashing) Dh

“目标地址散列”调度算法根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。

  h) 源地址散列(Source Hashing)SH

“源地址散列”调度算法根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。

1.8 LVS+Keepalived方案实现

1.8.1 keepalived功能

  1. 添加VIP

  2. 添加LVS配置

  3. 高可用(VIP漂移)

  4. web服务器健康检查

1.8.2 在负载器安装Keepalived软件

yum -y install keepalived

检查软件是否安装

[root@lb03 ~]# rpm -qa keepalived
keepalived-1.3.5-1.el7.x86_64
1.8.3 修改配置文件

lb03上keepalied配置文件

1 [root@lb03 ~]# cat /etc/keepalived/keepalived.conf
2 global_defs {
3 router_id LVS_01
4 }
5
6 vrrp_instance VI_1 {
7 state MASTER
8 interface eth0
9 virtual_router_id 51
10 priority 150
11 advert_int 1
12 authentication {
13 auth_type PASS
14 auth_pass 1111
15 }
16 virtual_ipaddress {
17 10.0.0.13/24
18 }
19 }
20
21 virtual_server 10.0.0.13 80 {
22 delay_loop 6
23 lb_algo wrr
24 lb_kind DR
25 nat_mask 255.255.255.0
26 persistence_timeout 50
27 protocol TCP
28
29 real_server 10.0.0.17 80 {
30 weight 1
31 TCP_CHECK {
32 connect_timeout 8
33 nb_get_retry 3
34 delay_before_retry 3
35 connect_port 80
36 }
37 }
38
39 real_server 10.0.0.18 80 {
40 weight 1
41 TCP_CHECK {
42 connect_timeout 8
43 nb_get_retry 3
44 delay_before_retry 3
45 connect_port 80
46 }
47 }
48 }
lb03 /etc/keepalived/keepalived.conf
lb04的Keepalied配置文件

1 [root@lb04 ~]# cat /etc/keepalived/keepalived.conf
2 global_defs {
3 router_id LVS_02
4 }
5
6 vrrp_instance VI_1 {
7 state BACKUP
8 interface eth0
9 virtual_router_id 51
10 priority 100
11 advert_int 1
12 authentication {
13 auth_type PASS
14 auth_pass 1111
15 }
16 virtual_ipaddress {
17 10.0.0.13/24
18 }
19 }
20 virtual_server 10.0.0.13 80 {
21 delay_loop 6
22 lb_algo wrr
23 lb_kind DR
24 nat_mask 255.255.255.0
25 persistence_timeout 50
26 protocol TCP
27
28 real_server 10.0.0.17 80 {
29 weight 1
30 TCP_CHECK {
31 connect_timeout 8
32 nb_get_retry 3
33 delay_before_retry 3
34 connect_port 80
35 }
36 }
37
38 real_server 10.0.0.18 80 {
39 weight 1
40 TCP_CHECK {
41 connect_timeout 8
42 nb_get_retry 3
43 delay_before_retry 3
44 connect_port 80
45 }
46 }
47 }
lb04 /etc/keepalived/keepalived.conf
keepalived persistence_timeout参数意义 LVS Persistence 参数的作用

http://blog.csdn.net/nimasike/article/details/53911363

1.8.4 启动keepalived服务

[root@lb03 ~]# systemctl restart keepalived.service

检查lvs状态

[root@lb03 ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.0.0.13:80 wrr persistent 50
-> 10.0.0.17:80 Route 1 0 0
-> 10.0.0.18:80 Route 1 0 0

检查虚拟ip

[root@lb03 ~]# ip a s eth0
2: eth0:

  • 0
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值