您的位置：首页 > 其它

Keepalive 基础概要及简单示例

2017-05-14 16:56 295 查看

keepalive简介

keepalive的目标是为Linux系统和基于Linux的基础设施提供简单而强大的负载平衡和高可用性保障。负载平衡框架依赖于众所周知的广泛使用的Linux虚拟服务器（IPVS） 内核模块，提供Layer4负载平衡。Keealived动态的管理负债均衡的服务器群，实现服务器的健康检测。而了解keepalive，就不得不了解VRRP协议，keepalived正是以vrrp的工作逻辑来工作的，那么我们就先了解VRRP协议是什么样的协议，再了解keepalived。

keepalived是lvs的扩展项目，因此它们之间具备良好的兼容性。通过对服务器池对象的健康检查，实现对失效机器/服务的故障隔离。负载均衡器之间的失败切换failover，是通过VRRPv2（Virtual Router Redundancy Protocol）stack实现的 。

VRRP 协议

VRRP协议概述

随着Internet的发展，人们对网络的可靠性的要求越来越高。对于局域网用户来说，能够时刻与外部网络保持联系是非常重要的。

通常情况下，内部网络中的所有主机都设置一条相同的缺省路由，指向出口网关（即图1中的路由器RouterA），实现主机与外部网络的通信。当出口网关发生故障时，主机与外部网络的通信就会中断。



配置多个出口网关是提高系统可靠性的常见方法，但局域网内的主机设备通常不支持动态路由协议，如何在多个出口网关之间进行选路是个问题。

IETF（Internet Engineering Task Force，因特网工程任务组）推出了VRRP（Virtual Router Redundancy Protocol）虚拟路由冗余协议，来解决局域网主机访问外部网络的可靠性问题。

VRRP是一种容错协议，它通过把几台路由设备联合组成一台虚拟的路由设备，并通过一定的机制来保证当主机的下一跳设备出现故障时，可以及时将业务切换到其它设备，从而保持通讯的连续性和可靠性。

使用VRRP的优势在于：既不需要改变组网情况，也不需要在主机上配置任何动态路由或者路由发现协议，就可以获得更高可靠性的缺省路由。

VRRP的基本概念

关键词解释
VRRP路由器（VRRP Router）运行VRRP的设备，它可能属于一个或多个虚拟路由器。（实体路由器）
虚拟路由器（Virtual Router）由VRRP管理的抽象设备，又称为VRRP备份组，被当作一个共享局域网内主机的缺省网关。 它包括了一个虚拟路由器标识符和一组虚拟IP地址。(实体路由器组)
虚拟IP地址(Virtual IP Address)s虚拟路由器的IP地址，一个虚拟路由器可以有一个或多个IP地址，由用户配置
IP地址拥有者（IP Address Owner）如果一个VRRP路由器将虚拟路由器的IP地址作为真实的接口地址，则该设备是IP地址拥有者。 当这台设备正常工作时，它会响应目的地址是虚拟IP地址的报文，如ping、TCP连接等
虚拟MAC地址是虚拟路由器根据虚拟路由器ID生成的MAC地址。 一个虚拟路由器拥有一个虚拟MAC地址，格式为：00-00-5E-00-01-{VRID}。 当虚拟路由器回应ARP请求时，使用虚拟MAC地址，而不是接口的真实MAC地址。
主IP地址（Primary IP Address）从接口的真实IP地址中选出来的一个主用IP地址，通常选择配置的第一个IP地址。 VRRP广播报文使用主IP地址作为IP报文的源地址。
Master路由器（Virtual Router Master）是承担转发报文或者应答ARP请求的VRRP路由器，转发报文都是发送到虚拟IP地址的。 如果IP地址拥有者是可用的，通常它将成为Master。
Backup路由器（Virtual Router Backup）一组没有承担转发任务的VRRP路由器，当Master设备出现故障时，它们将通过竞选成为新的Master
抢占模式在抢占模式下，如果Backup的优先级比当前Master的优先级高，将主动将自己升级成Master
非抢占模式只要master路由器没有出现故障，即使backup路由器的优先路由器高于master路由器，也不会成为master路由器

VRRP的工作原理

VRRP将局域网的一组路由器构成一个备份组，相当于一台虚拟路由器。局域网内的主机只需要知道这个虚拟路由器的IP地址，并不需知道具体某台设备的IP地址，将网络内主机的缺省网关设置为该虚拟路由器的IP地址，主机就可以利用该虚拟网关与外部网络进行通信。

VRRP将该虚拟路由器动态关联到承担传输业务的物理路由器上，当该物理路由器出现故障时，再次选择新路由器来接替业务传输工作，整个过程对用户完全透明，实现了内部网络和外部网络不间断通信。



如上图所示，虚拟路由器的组网环境如下：

RouterA、RouterB和RouterC属于同一个VRRP组，组成一个虚拟路由器，这个虚拟路由器有自己的IP地址172.18.14.1。虚拟IP地址可以直接指定，也可以借用该VRRP组所包含的路由器上某接口地址。

物理路由器RouterA、RouterB和RouterC的实际IP地址分别是172.18.14.10、172.18.14.11、172.18.14.12

局域网内的主机只需要将缺省路由设为172.18.14.1即可，无需知道具体路由器上的接口地址。

主机利用该虚拟网关与外部网络通信。路由器工作机制如下：

根据优先级的大小挑选Master设备。Master的选举有两种方法：

比较优先级的大小，优先级高者当选为Master。

当两台优先级相同的路由器同时竞争Master时，比较接口IP地址大小。接口地址大者当选为Master。

其它路由器作为备份路由器，随时监听Master的状态。

当主路由器正常工作时，它会每隔一段时间（Advertisement_Interval）发送一个VRRP组播报文，以通知组内的备份路由器，主路由器处于正常工作状态。

当组内的备份路由器一段时间（Master_Down_Interval）内没有接收到来自主路由器的报文，则将自己转为主路由器。一个VRRP组里有多台备份路由器时，短时间内可能产生多个Master，此时，路由器将会将收到的VRRP报文中的优先级与本地优先级做比较。从而选取优先级高的设备做Master。

VRRP的状态机

VRRP协议中定义了三种状态机：初始状态（Initialize）、活动状态（Master）、备份状态（Backup）。其中，只有处于活动状态的设备才可以转发那些发送到虚拟IP地址的报文。

Initialize

设备启动时进入此状态，当收到接口Startup的消息，将转入Backup或Master状态（IP地址拥有者的接口优先级为255，直接转为Master）。在此状态时，不会对VRRP报文做任何处理。

Master 当路由器处于Master状态时，它将会做下列工作：

定期发送VRRP报文。

以虚拟MAC地址响应对虚拟IP地址的ARP请求。

转发目的MAC地址为虚拟MAC地址的IP报文。

如果它是这个虚拟IP地址的拥有者，则接收目的IP地址为这个虚拟IP地址的IP报文。否则，丢弃这个IP报文。

如果收到比自己优先级大的报文则转为Backup状态。

如果收到优先级和自己相同的报文，并且发送端的主IP地址比自己的主IP地址大，则转为Backup状态。

当接收到接口的Shutdown事件时，转为Initialize。

Backup 当路由器处于Backup状态时，它将会做下列工作:

接收Master发送的VRRP报文，判断Master的状态是否正常。

对虚拟IP地址的ARP请求，不做响应。

丢弃目的MAC地址为虚拟MAC地址的IP报文。

丢弃目的IP地址为虚拟IP地址的IP报文。

Backup状态下如果收到比自己优先级小的报文时，丢弃报文，不重置定时器；如果收到优先级和自己相同的报文，则重置定时器，不进一步比较IP地址。

当Backup接收到MASTER_DOWN_TIMER定时器超时的事件时，才会转为Master。

当接收到接口的Shutdown事件时，转为Initialize。

负载分担

现在允许一台路由器为多个作备份。通过多虚拟路由器设置可以实现负载分担。

负载分担方式是指多台路由器同时承担业务，因此需要建立两个或更多的备份组。

负载分担方式具有以下特点:

每个备份组都包括一个Master设备和若干Backup设备。

各备份组的Master可以不同。

同一台路由器可以加入多个备份组，在不同备份组中有不同的优先级。

!

如图所示：

配置两个备份组：组1和组2；

RouterB在备份组1中作为Master，在备份组2中作为Backup；

RouterC在备份组1和2中都作为Backup；

RouterA在备份组2中作为Master，在备份组1中作为Backup。

一部分主机使用备份组1作网关，另一部分主机使用备份组2作为网关。

这样，以达到分担数据流，而又相互备份的目的。

Kepalive基础

Keepalive体系结构



Keepalived 大致分两层结构：用户空间 user space和内核空间 kernel space

在这个结构图里，处于下端的是内核空间，它包括IPVS和NETLINK两个部分。netlink提供高级路由及其他相关的网络功能，如果在负载均衡器上启用netfilter/iptable，将会直接影响它的性能。处于图形上方的组件为用户空间，由它来实现具体的功能，下面选取几个重要的来做说明：

WatchDog 负责监控checkers和VRRP进程的状况；

Checkers 负责真实服务器的健康检查healthchecking，是keepalived最主要的功能；

VRRP Stack负责负载均衡器之间的失败切换FailOver；

IPVS wrapper 用来发送设定的规则到内核ipvs代码；Netlink Reflector 用来设定 vrrp 的vip地址等。

在Linux主机上，以daemon（守护进程）方式实现了vrrp协议，并提供了完成配置ipvs规则及实现相应real server状态检测能力。

能调用外部脚本

轻量灵活，不能解决脑裂问题（需要依靠其他措施来解决）

Keepalived正常运行时，会启动3个进程，分别是core、check和vrrp：

vrrp模块是来实现VRRP协议的；

check负责健康检查，包括常见的各种检查方式；

core模块为keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析。

注意：

keepalived的启动过程并不会对配置文件进行语法检查，就算没有配置文件，keepalived的守护进程照样能够被运行起来。在不指定配置文件位置的状态下—keepalived默认先查找文件

/etc/keepalived/keepalived.conf ，可以手动创建这个文件，然后在这个文件里书写规则，来达到控制keepalived运行的目的。

keepalived特性:

vrrp协议的软件实现，原生设计的目的为了高可用ipvs服务：

vrrp协议完成地址流动；

为vip地址所在的节点生成ipvs规则（在配置文件中预先定义）；

为ipvs集群的各RS做健康状态检测；

基于脚本调用接口通过执行脚本完成脚本中定义的功能，进而影响集群事务；

KeepAlive的配置文件解释：

全局定义块，必须存在：

global_defs {
notification_email {
a@abc.com
b@abc.com    ##故障发生时给谁发邮件通知
}
notification_email_from c@abc.com   ##通知邮件从哪个地址发出
smtp_server 172.18.14.168        ##通知邮件的smtp地址
smtp_connect_timeout 30          ## 连接smtp服务器的超时时间
router_id LVS_DEVEL          ##标识本节点的字条串，故障发生时，邮件通知会用到
}


vrrp_script区域主要用来做健康检查的，当时检查失败时会将vrrp_instance的priority减少相应的值。（自定义脚本）

vrrp_script chk_http_port {
script "path to scirpts " :检测脚本
interval 1    ：检测周期
weight -10  :当发生检测失败事件，权重较低多少
}


VRRP实例定义块主要用来定义对外提供服务的VIP区域及其相关属性：

vrrp_instance VI_1 {
state MASTER       ##可以是MASTER或BACKUP，不过当其他节点keepalived启动时会将priority比较大的节点选举为MASTER

interface IFACE_NAME  ##绑定为当前虚拟路由器使用的物理接口；

priority 100 ## 当前主机在此虚拟路径器中的优先级；范围1-254；

virtual_router_id 1   ## 取值在0-255之间，用来区分多个instance的VRRP组播， 同一网段中该值不能重复，并且同一个vrrp实例使用唯一的标识，即虚拟路由器id

advert_int 1       ##发VRRP包的时间间隔，即多久进行一次master选举，可以认为是健康查检时间间隔，单位为秒

authentication {
auth_type PASS   ##认证类型有PASS和AH（IPSEC），通常使用的类型为PASS，同一vrrp实例MASTER与BACKUP 使用相同的密码才能正常通信
auth_pass 12345678

virtual_ipaddress {    ##可以有多个VIP(虚拟路由器)地址，每个地址占一行，不需要指定子网掩码，必须与RealServer上设定的VIP相一致
#指明虚拟ip地址，配置在哪个网卡/网卡别名
<IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE> label <LABEL>
172.18.14.1
}

track_script {     #调用自定义脚本 即vrrp_script区域的脚本
chk_http_port    #要调用的自定义名称
}

track_interface {  #跟踪监视机制一旦接口出现故障，则转为FAULT状态
eth0
eth1
}

nopreempt：#定义工作模式为非抢占模式；（如果不加，就默认抢占模式）
preempt_delay 300：#抢占式模式下，节点上线后触发新选举操作的

notify_master <STRING>|<QUOTED-STRING>：当前节点成为主节点时(master状态)触发的通知脚本；

notify_backup <STRING>|<QUOTED-STRING> #切换为备用（backup）时的通知脚本

notify_fault <STRING>|<QUOTED-STRING> #出错时（faulty状态）的通知脚本

notify <STRING>|<QUOTED-STRING>
#表示任何状态都会触发的通知脚本，并且该脚本在以上三个脚本执行完成之后进行调用，keepalived会自动传递三个参数：（$1 = "GROUP"|"INSTANCE"，$2 = name of group or instance，$3 = target state of transition(MASTER/BACKUP/FAULT)）
1

}
}


虚拟服务器定义块

virtual_server 172.18.14.1 80 {  ##定义RealServer对应的VIP及服务端口,必须与RealServer上设定的VIP相一致
delay_loop 6          ##延迟轮询时间（单位秒）
lb_algo rr            ## 后端调试算法（load balancing algorithm ）
lb_kind NAT           ##LVS调度类型NAT/DR/TUN
nat_mask 255.255.0.0

persistence_timeout 50   ##持久连接超时时间

protocol TCP         ##转发协议protocol.一般有TCP和UDP两种
sorry_server         ##当所有RealServer宕机时，sorry server顶替
real_server 192.168.200.100 80 {  ##RealServer的IP和端口号，改组可在下面定义多个
weight 1
HTTP_GET {
url {
path /       ##请求Real Serserver上的路径
digest ff20ad2481f97b1754ef3e12ecd3a9cc
status_code 200    ##用genhash算出的结果和http状态码
}
connect_timeout 3        ##超时时长
nb_get_retry 3           ##重试次数
delay_before_retry 3     ##下次重试的时间延迟
}
}
}


虚拟服务器的常用参数：
delay_loop <INT>：#服务轮询的时间间隔；
lb_algo rr|wrr|lc|wlc|lblc|sh|dh：#定义调度方法；
lb_kind NAT|DR|TUN：#集群的类型；
persistence_timeout <INT>：#持久连接时长；
protocol TCP：#服务协议，仅支持TCP；
sorry_server <IPADDR> <PORT> ##备用服务器地址；
real_server <IPADDR> <PORT>
{
weight <INT>
notify_up <STRING>|<QUOTED-STRING>
notify_down <STRING>|<QUOTED-STRING>
HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK { ... }：##定义当前主机的健康状态检测方法；
}

HTTP_GET|SSL_GET：#应用层检测

HTTP_GET|SSL_GET {
url {
path <URL_PATH>：#定义要监控的URL；
status_code <INT>：#判断上述检测机制为健康状态的响应码；
digest <STRING>：#判断上述检测机制为健康状态的响应的内容的校验码；
}
nb_get_retry <INT>：#重试次数；
delay_before_retry <INT>：#重试之前的延迟时长；
connect_ip <IP ADDRESS>：#向当前RS的哪个IP地址发起健康状态检测请求
connect_port <PORT>：#向当前RS的哪个PORT发起健康状态检测请求
bindto <IP ADDRESS>：#发出健康状态检测请求时使用的源地址；
bind_port <PORT>：#发出健康状态检测请求时使用的源端口；
connect_timeout <INTEGER>：#连接请求的超时时长；
}

TCP_CHECK {
connect_ip <IP ADDRESS>：#向当前RS的哪个IP地址发起健康状态检测请求
connect_port <PORT>：#向当前RS的哪个PORT发起健康状态检测请求
bindto <IP ADDRESS>：#发出健康状态检测请求时使用的源地址；
bind_port <PORT>：#发出健康状态检测请求时使用的源端口；
connect_timeout <INTEGER>：#连接请求的超时时长；
}


Keepalive示例

简易keepalive

node1配置：/etc/keepalived/keepalived.conf





node2配置：/etc/keepalived/keepalived.conf





接着在两台节点都重启keepalived服务（节点1为master,节点2为backup），节点1，注意观察标记部分，进入了master 模式， 并获取的虚拟路由器ip.



节点2，注意标记部分，收到了高优先级虚拟路由器通告，进入backup模式，主动释放虚拟路由器iP(VIP)



接着人为的把节点1keepalived模式关闭，然后观察节点2 keepalived 状态，可以发现节点2收不到master的通告，由backup模式转入master模式，并获取VIP 地址。



双主模型



双主模型：简单来说，就是在VRRP2中，Router A 是Master状态，router B 是Backup状态；而在VRRP1中，Router A 是 Backup状态，router B 是Master状态。

下面请看配置示例：

节点A：





节点2配置：





之后再重启，验证方法不再复述，自行回去复习哦。

探测网卡，查看arp广播发送情况 。

[root@localhost ~]# tcpdump -i eno16777736 -nn host 224.0.14.14

通知脚本的使用方式（示例）：

1、编写通知脚本，节点A,B都一样：由于截图关系导致截图补全（最上面是shell脚本的shellbang,#!/bin/bash）



2、修改/etc/keepalived/keepalived.conf配置文件：



关闭、重启两个节点的keepalived服务，查看邮件是否发送

高可用LVS 集群：

一、单主配置模式（一主一备），采用lvs-dir模型，采用五台主机，两个DS，两台RS，一台client测试机

1、对2台RS主机分别安装httpd服务，编辑配置文件，以示区分。

RS1



RS2



2、分别对2台RS，配置vip,开启 arp_ignore,arp_announce选项，配置主机路由，这里采用脚本的形式：

对RS1进行lvs-dir相关操作：

编写脚本，再执行脚本

[root@localhost scripts]# cat rs.sh
#!/bin/bash
#
iface=eth0
case $1 in
start)
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/${iface}/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/${iface}/arp_announce

;;
stop)
echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/${iface}/arp_ignore
echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 0 > /proc/sys/net/ipv4/conf/${iface}/arp_announce
;;
*)
echo "usage $(basename $0) start|stop"
exit 1
;;
esac


RS1添加vip ,添加主机路由:



RS2：操作方式和RS1一样，不在复述。

对DS1 keepalive的配置文件进行修改：







对DS2 keepalive的配置文件进行修改：







重启各个DS的keepalive ，在客户机测试结果：



测试keepalive健康状态检测：（蓄意关闭RS1的httpd）

[root@localhost scripts]# service httpd stop
Stopping httpd:                                            [  OK  ]


在DS1进行lvs集群信息查看：（已有一台RS自动被移除。）



测试DS的sorry server功能：

再将另一台RS关闭（模拟故障）

[root@bnpanda script]#systemctl stop httpd


在DS1查看集群信息：已成功转入DS1的错误server



在客户端进行验证：（错误页正常显示）



再将DS1认为关闭，模拟故障：



到DS2查看ip信息，虚拟ip（172.18.14.1）已转到DS2：



客户端测试：（DS2 sorry server发挥作用）



双主模型

基本原则和单主模型一致，需要注意的是，双主模式，存在两个VIP，RS1,RS2需要配置两个VIP，都需要配置两个主机路由，DS1，DS2，keepalive 的/etc/keepalived/keepalived.conf配置文件需要配置两个虚拟路由器，两个虚拟服务器:

DS1配置文件：

[root@localhost keepalived]# cat keepalived.conf
! Configuration File for keepalived

global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id node1
vrrp_mcast_group4 224.0.14.14
}

vrrp_instance myr1 {
state MASTER
interface eno16777736
virtual_router_id 78
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.18.14.1/16 dev eno16777736
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_fault "/etc/keepalived/notify.sh fault"

}

vrrp_instance myr2 {
state BACKUP
interface eno16777736
virtual_router_id 79
priority 98
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.18.14.2/16 dev eno16777736
}

}

virtual_server 172.18.14.1 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
sorry_server 127.0.0.1 80

real_server 172.18.14.197 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}

real_server 172.18.14.16 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}

virtual_server 172.18.14.2 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
sorry_server 127.0.0.1 80

real_server 172.18.14.197 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}

real_server 172.18.14.16 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}


DS2配置文件：

[root@localhost keepalived]# cat keepalived.conf
! Configuration File for keepalived

global_defs {
notification_email {
root@localhost
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id node1
vrrp_mcast_group4 224.0.14.14
}

vrrp_instance myr1 {
state BACKUP
interface eno16777736
virtual_router_id 78
priority 96
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.18.14.1/16 dev eno16777736
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_default "/etc/keepalived/notify.sh default"

}

vrrp_instance myr2{
state MASTER
interface eno16777736
virtual_router_id 79
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.18.14.2/16 dev eno16777736
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
notify_default "/etc/keepalived/notify.sh default"

}

virtual_server 172.18.14.1 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
sorry_server 127.0.0.1 80

real_server 172.18.14.197 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}

real_server 172.18.14.16 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}

virtual_server 172.18.14.2 80 {
delay_loop 3
lb_algo rr
lb_kind DR
protocol TCP
sorry_server 127.0.0.1 80

real_server 172.18.14.197 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}

real_server 172.18.14.16 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}


RS1添加VIP：(基于单主模型环境做的修改，额外添加一个vip)

#ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2
#route add -host 172.18.14.2 dev lo:1


RS2添加VIP：(基于单主模型环境做的修改，额外添加一个vip)

#ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2
#route add -host 172.18.14.2 dev lo:1


最后重启DS1，DS2，的keepalive

客户机测试：两个地址均能正常访问。



双主模型的高可用nginx proxy服务

采用DIR的模式，在两台RS上分别取消arp应答与通告

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore;
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore;
echo 2 >/proc/sys/net/ipv4/conf/all/arp_anonouce;
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce;


两台主机添加两个VIP，启用两个主机路由（VIP的主机路由）

RS1:   ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 up
route add -host 172.18.14.1 dev lo:0
RS1:   ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2 up
route add -host 172.18.14.2 dev lo:1


RS2:    ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 up
route add -host 172.18.14.1 dev lo:0

RS2:    ifconfig lo:1 172.18.14.2 netmask 255.255.255.255 broadcast 172.18.14.2 up
route add -host 172.18.14.1 dev lo:1


1、在两台代理上安装好nginx :

DS 1:

配置/etc/nginx/nginx.conf:

在http上下文内部定义一个 upstream:



[root@localhost keepalived]# vim /etc/nginx/conf.d/default.conf
在默认的location内部直接添加 proxy_pass http://websrv[/code] 


DS2的nginx配置和DS1基本一致

2配置keepalived

DS1:

[root@localhost keepalived]# vim keepalived.conf


(/etc/keepalived/keepalived.conf)







解释一下：

vrrp_script ngxstatus {   #此处为ngx状态检测脚本：
script 'killall -0 nginx  && exit 0 || exit 1'
interval 1 #探测间隔
weight -5 #如果探测到nginx未启动，权重下降度5
}

track_script {#调用自定义脚本
ngxstatus  #(调用之前定义的status脚本)
}


注意：自定义脚本请先定义，再调用，且在虚拟路由器实体中调用

此处自定义脚本的作用：当探测到本机nginx服务没有启动，就自动的把权重减5.使其从master变为backup,实现了主nginx故障的时候，业务能更换到备nginx上。即实现了nginx的双机备份。

DS2方式和DS1 类似 注意vrrp master,priority即可







3、重启nginx和keealive 两台都要操作（建议systemctl stop keepalive和systemctl startt keepalive）:避免操作失效

4到客户端测试：



5、人为关闭DNS1的keepalive，到DNS2观察 VIP是否已经获取到了。





6、重启DNS1 的keepalive,观察是否获取



7、DS1 关闭nginx，保持keepalived开启，查看DNS2是否获取vip，是否实现了nginx的故障切换，实现nginx高可用集群。





8、DNS1，重新启动nginx，查看是否重新获取ip,



附加测试：问：ipvs使用持久连接时，故障切换后，同一个客户端是否依然能关联至此前绑定的RS？

DS两台，RS两台，client一台

1、ipvs使用持久连接：

采用DIR模式：

RS1，RS2

采用DIR的模式，在两台RS上分别取消arp应答和通告：

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore;
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore;
echo 2 >/proc/sys/net/ipv4/conf/all/arp_anonouce;
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce;


两台主机添加两个VIP，启用两个主机路由（VIP的主机路由）

RS1:   ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 up
route add -host 172.18.14.1 dev lo:0

RS2:    ifconfig lo:0 172.18.14.1 netmask 255.255.255.255 broadcast 172.18.14.1 up
route add -host 172.18.14.1 dev lo:0


DS1 keepalived 配置 /etc/keepalived/keepalived.conf







DS2:配置 /etc/keepalived/keepalived.conf







在客户端测试：（因为持久连接的缘故，所以都是同一个页面）



现在，把RS1的  httpd关闭：



再次测试：业务成功转移到RS2



再次回复RS1 的httpd



关闭DS1 的keepalived



再次测试：访问的依旧是原来的页面



附加测试：问：ipvs使用sh算法时，故障切换后，同一个客户端是否依然能关联至此前绑定的RS？

基础配置和上述的基本一致，主要就是设定算法的地方有所区别：

DS1



DS2



经过测试：

第一次访问



关闭DS1 的keepalive

再次测试：（业务成功迁移）



保证DS1 和DS2 的keepalived服务开启，将RS1的httpd关闭，即使在SH算法下，业务也能够正常迁移





问：nginx使用ip_hash算法时，故障切换后，同一个客户端是否依然能关联至此前绑定的upstream server？

本次实验采用的单主模式：（双主模式请到前文去找了啦）

IP_hash 算法：

1、准备nginx的负载均衡配置：

DS1：

安装nginx：

修改/etc/nginx/nginx.conf,在http上下文中增加 upstram



注：server 172.18.14.197:80 表示的是RS1，server 172.18.14.33:80表示的RS2，可以根据实际修改配置，而127.0.0.1:8080是本机的sorry server(这里选用的是http，已更改监听端口为8080，可根据实际需要修改)

修改/etc/nginx/conf.d/default.conf，直接在location内添加代理语句：（proxy_pass http://websrv）



上图使用的是ip_hash算法

DS2：

安装方法，和配置方式和DS1基本一致哦，除了sorry sever需要写自己本机的地址（或者写其他sorry server的ip地址也没问题啦。看个人想法）

2、准备 keepalived 配置 (编辑自定义脚本，使用killall时，确保系统安装了 psmisc 程序包 啊！)

DS1配置文件：





DS2配置文件：





（改配置前文有类似的实验，具体验证方法前文也有说明，此处不再负叙述，已经过验证，当DS1  nginx服务down掉，ip是能够转移到DS2上的）

测试：在所有业务都正常开启的时候 ，由于ip_hash算法，都被定位到RS2 上



故障测试：将RS2 web服务（httpd)关闭，再从客户端浏览访问：，此次业务并未终端，成功迁移到RS1上。





问：nginx使用hash requesturi算法时，故障切换后，同一个客户端是否依然能关联至此前绑定的upstreamserver？hashrequest_uri  算法  配置和ip_hash 基本一致，除了nginx的配置所有差异：

DS1：

/etc/nginx/nginx.conf



DS2 nginx配置文件:



所有服务均正常的情况（keepalive ,nginx,httpd开启）：



将RS2 web服务关闭：





将所有服务恢复：访问测试



A、关闭 DS1 的nginx：再进行访问测试：





B、  启动 DS1 的nginx：再进行访问测试：
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息
标签：  管理
相关文章推荐
新的分享
章节导航