http://freeloda.blog.51cto.com/2033581/1280962
大纲
一、前言
二、Keepalived 详解
三、环境准备
四、LVS+Keepalived 实现高可用的前端负载均衡器
一、前言
这篇文章是前几篇文章的总结,我们先简单的总结一下我们前面讲解的内容,前面我们讲解了,LVS(负载均衡器)、Heartbeat、Corosync、Pacemaker、Web高可用集群、MySQL高可用集群、DRDB、iscsi、gfs2、cLVM等,唯一没有讲解的就是LVS可用,也就是前端高可用,我们这一篇博文主要讲解内容。在说这个之前我们得和大家讨论一个问题,也是好多博友问的问题。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是最佳组合。但说实话我对于软件没有任何倾向性,所以我把所有的集群软件都和大家说了一下,我认为不管什么软件,只要它能存活下来都有它的特点和应用领域,只有把特定的软件放在特定的位置才能发挥最大的作用,那首先我们得对这个软件有所有了解。学习一种软件的最好方法,就是去查官方文档。好了说了那么多希望大家有所收获,下面我们来说一说keepalived。
二、Keepalived 详解
1.Keepalived 定义
Keepalived 是一个基于VRRP协议来实现的LVS服务高可用方案,可以利用其来避免单点故障。一个LVS服务会有2台服务器运行Keepalived,一台为主服务器(MASTER),一台为备份服务器(BACKUP),但是对外表现为一个虚拟IP,主服务器会发送特定的消息给备份服务器,当备份服务器收不到这个消息的时候,即主服务器宕机的时候, 备份服务器就会接管虚拟IP,继续提供服务,从而保证了高可用性。Keepalived是VRRP的完美实现,因此在介绍keepalived之前,先介绍一下VRRP的原理。
2.VRRP 协议简介
在现实的网络环境中,两台需要通信的主机大多数情况下并没有直接的物理连接。对于这样的情况,它们之间路由怎样选择?主机如何选定到达目的主机的下一跳路由,这个问题通常的解决方法有二种:
- 在主机上使用动态路由协议(RIP、OSPF等)
- 在主机上配置静态路由
很明显,在主机上配置动态路由是非常不切实际的,因为管理、维护成本以及是否支持等诸多问题。配置静态路由就变得十分流行,但路由器(或者说默认网关default gateway)却经常成为单点故障。VRRP的目的就是为了解决静态路由单点故障问题,VRRP通过一竞选(election)协议来动态的将路由任务交给LAN中虚拟路由器中的某台VRRP路由器。
3.VRRP 工作机制
在一个VRRP虚拟路由器中,有多台物理的VRRP路由器,但是这多台的物理的机器并不能同时工作,而是由一台称为MASTER的负责路由工作,其它的都是BACKUP,MASTER并非一成不变,VRRP让每个VRRP路由器参与竞选,最终获胜的就是MASTER。MASTER拥有一些特权,比如,拥有虚拟路由器的IP地址,我们的主机就是用这个IP地址作为静态路由的。拥有特权的MASTER要负责转发发送给网关地址的包和响应ARP请求。
VRRP通过竞选协议来实现虚拟路由器的功能,所有的协议报文都是通过IP多播(multicast)包(多播地址224.0.0.18)形式发送的。虚拟路由器由VRID(范围0-255)和一组IP地址组成,对外表现为一个周知的MAC地址。所以,在一个虚拟路由 器中,不管谁是MASTER,对外都是相同的MAC和IP(称之为VIP)。客户端主机并不需要因为MASTER的改变而修改自己的路由配置,对客户端来说,这种主从的切换是透明的。
在一个虚拟路由器中,只有作为MASTER的VRRP路由器会一直发送VRRP通告信息(VRRPAdvertisement message),BACKUP不会抢占MASTER,除非它的优先级(priority)更高。当MASTER不可用时(BACKUP收不到通告信息), 多台BACKUP中优先级最高的这台会被抢占为MASTER。这种抢占是非常快速的(<1s),以保证服务的连续性。由于安全性考虑,VRRP包使用了加密协议进行加密。
4.VRRP 工作流程
(1).初始化:
路由器启动时,如果路由器的优先级是255(最高优先级,路由器拥有路由器地址),要发送VRRP通告信息,并发送广播ARP信息通告路由器IP地址对应的MAC地址为路由虚拟MAC,设置通告信息定时器准备定时发送VRRP通告信息,转为MASTER状态;否则进入BACKUP状态,设置定时器检查定时检查是否收到MASTER的通告信息。
(2).Master
- 设置定时通告定时器;
- 用VRRP虚拟MAC地址响应路由器IP地址的ARP请求;
- 转发目的MAC是VRRP虚拟MAC的数据包;
- 如果是虚拟路由器IP的拥有者,将接受目的地址是虚拟路由器IP的数据包,否则丢弃;
- 当收到shutdown的事件时删除定时通告定时器,发送优先权级为0的通告包,转初始化状态;
- 如果定时通告定时器超时时,发送VRRP通告信息;
- 收到VRRP通告信息时,如果优先权为0,发送VRRP通告信息;否则判断数据的优先级是否高于本机,或相等而且实际IP地址大于本地实际IP,设置定时通告定时器,复位主机超时定时器,转BACKUP状态;否则的话,丢弃该通告包;
(3).Backup
- 设置主机超时定时器;
- 不能响应针对虚拟路由器IP的ARP请求信息;
- 丢弃所有目的MAC地址是虚拟路由器MAC地址的数据包;
- 不接受目的是虚拟路由器IP的所有数据包;
- 当收到shutdown的事件时删除主机超时定时器,转初始化状态;
- 主机超时定时器超时的时候,发送VRRP通告信息,广播ARP地址信息,转MASTER状态;
- 收到VRRP通告信息时,如果优先权为0,表示进入MASTER选举;否则判断数据的优先级是否高于本机,如果高的话承认MASTER有效,复位主机超时定时器;否则的话,丢弃该通告包;
5.ARP查询处理
当内部主机通过ARP查询虚拟路由器IP地址对应的MAC地址时,MASTER路由器回复的MAC地址为虚拟的VRRP的MAC地址,而不是实际网卡的 MAC地址,这样在路由器切换时让内网机器觉察不到;而在路由器重新启动时,不能主动发送本机网卡的实际MAC地址。如果虚拟路由器开启的ARP代理 (proxy_arp)功能,代理的ARP回应也回应VRRP虚拟MAC地址;好了VRRP的简单讲解就到这里,我们下来讲解一下Keepalived的案例。
三、环境准备
1.操作系统
- CentOS 6.4 X86_64
2.软件版本
- ipvsadm.x86_64 0:1.25-10.el6
- keepalived.x86_64 0:1.2.7-3.el6
- httpd-2.2.15-29.el6.centos.x86_64
3.实验拓扑
4.时间同步
node1:
1 |
|
node2:
1 |
|
master:
1 |
|
slave:
1 |
|
5.主机名互相解析
node1:
1 2 3 4 5 |
|
node2:
1 2 3 4 5 |
|
6.安装yum源
node1:
1 2 |
|
node2:
1 2 |
|
master:
1 2 |
|
slave:
1 2 |
|
四、LVS+Keepalived 实现高可用的前端负载均衡器
node1:
1.安装httpd
1 |
|
2.配置httpd
1 2 |
|
3.启动httpd
1 |
|
4.测试
5.设置开机自启动
1 2 3 |
|
6.配置node1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 |
|
7.查看配置
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
好了,node1到这里基本配置完成,下面我们来配置node2。
node2:
1.安装httpd
1 |
|
2.配置httpd
1 2 |
|
3.启动httpd
1 |
|
4.测试
5.设置开机自启动
1 2 3 |
|
6.配置node2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
|
7.查看配置
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
|
好了,到这里node2也基本配置完成。下面我们来配置master与slave。
masterg与slave:
1.安装keepalived与ipvsadm
1 2 |
|
2.修改配置文件
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
|
3.将配置文件同步到slave
1 |
|
4.简单修改一下slave配置文件
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
|
5.启动master与slave的keepalived服务
1 2 3 4 |
|
6.查看一下LVS状态
1 2 3 4 5 6 7 |
|
7.测试
8.模拟故障
(1).停止一下node1
1 2 |
|
(2).查看一下的lvs
1 2 3 4 5 6 |
|
(3).测试一下
(4).查看一下邮件
(5).重新启动一下node1
1 2 |
|
(6).再查看一下lvs状态
1 2 3 4 5 6 7 |
|
(7).再查看一下邮件
(8).关闭master上keepalived
1 2 3 4 5 6 |
|
(9).查看一下slave状态
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
(10).再次测试一下
注,大家可以看到,经过上面的演示我们现在LVS的高可用即前端负载均衡的高可用,同时实现对后端realserver监控,也实现后端realserver宕机时会给管理员发送邮件。但还有几个问题我们还没有解决,问题如下:
- 所有realserver都down机,怎么处理?是不是用户就没法打开,还是提供一下维护页面。
- 怎么完成维护模式keepalived切换?
- 如何在keepalived故障时,发送警告邮件给指定的管理员?
9.所有realserver都down机,怎么处理?
问题:在集群中如果所有real server全部宕机了,客户端访问时就会出现错误页面,这样是很不友好的,我们得提供一个维护页面来提醒用户,服务器正在维护,什么时间可以访问等,下面我们就来解决一下这个问题。解决方案有两种,一种是提供一台备用的real server当所有的服务器宕机时,提供维护页面,但这样做有点浪费服务器。另一种就是在负载均衡器上提供维护页面,这样是比较靠谱的,也比较常用。下面我们就来具体操作一下。
(1).master与slave安装上httpd
1 2 |
|
(2).配置维护页面
1 2 3 4 |
|
(3).启动httpd服务并测试
1 2 3 4 |
|
(4).修改配置文件
master:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
|
slave:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
|
(5).关闭所有的real server并重新启动一下master与slave的keepalived
1 2 3 4 5 6 7 8 9 10 |
|
(6).查看一下lvs
1 2 3 4 5 6 |
|
(7).测试
注,sorry_server测试成功,下面我们继续。
10.怎么完成维护模式keepalived切换?
问题:我们一般进行主从切换测试时都是关闭keepalived或关闭网卡接口,有没有一种方法能实现在不关闭keepalived下或网卡接口来实现维护呢?方法肯定是有的,在keepalived新版本中,支持脚本vrrp_srcipt,具体如何使用大家可以man keepalived.conf查看。下面我们来演示一下具体怎么实现。
(1).定义脚本
1 2 3 4 5 6 7 |
|
(2).执行脚本
1 2 3 |
|
(3).修改配置文件
master:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 |
|
slave:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 |
|
(4).测试
master:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
slave:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
好了,自写监测脚本,完成维护模式切换,到这里就演示成功,下面我们来解决最后一个问题,就是keepalived主从切换的邮件通告。
11.如何在keepalived故障时(或主备切换时),发送警告邮件给指定的管理员?
(1).keepalived通知脚本进阶示例
下面的脚本可以接受选项,其中
- -s, --service SERVICE,...:指定服务脚本名称,当状态切换时可自动启动、重启或关闭此服务;
- -a, --address VIP: 指定相关虚拟路由器的VIP地址;
- -m, --mode {mm|mb}:指定虚拟路由的模型,mm表示主主,mb表示主备;它们表示相对于同一种服务而方,其VIP的工作类型;
- -n, --notify {master|backup|fault}:指定通知的类型,即vrrp角色切换的目标角色;
- -h, --help:获取脚本的使用帮助;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 |
|
(2).在keepalived.conf配置文件中,其调用方法如下所示:
- notify_master "/etc/keepalived/notify.sh -n master -a 192.168.18.200"
- notify_backup "/etc/keepalived/notify.sh -n backup -a 192.168.18.200"
- notify_fault "/etc/keepalived/notify.sh -n fault -a 192.168.18.200"
(3).修改配置文件
master:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 |
|
slave:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 |
|
(4).增加脚本
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 |
|
(5).给脚本增加执行权限
1 |
|
(6).将master上脚本复制到slave上
1 |
|
(7).测试一下脚本
1 2 3 4 5 6 7 |
|
(8).查看一下邮件
注,大家可以看到成功收到邮件,测试成功。在模拟故障时先重启一下keepalived服务。
(9).模拟故障
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
|
(10).查看一下邮件
注,大家可以看到,主备切换时,会发送邮件报警,好了到这里所有演示全部完成。希望大家有所收获^_^……