高可用解决方案：
heartbeat
corosync
cman
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与heartbeat/corosync等比较：
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是最佳组合。
双机高可用一般是通过虚拟IP（飘移IP）方法来实现的，基于Linux/Unix的IP别名技术。
双机高可用方法目前分为两种：
1）双机主从模式：即前端使用两台服务器，一台主服务器和一台热备服务器，正常情况下，主服务器绑定一个公网虚拟IP，提供负载均衡服务，热备服务器处于空闲状态；当主服务器发生故障时，热备服务器接管主服务器的公网虚拟IP，提供负载均衡服务；但是热备服务器在主机器不出现故障的时候，永远处于浪费状态，对于服务器不多的网站，该方案不经济实惠。
2）双机主主模式：即前端使用两台负载均衡服务器，互为主备，且都处于活动状态，同时各自绑定一个公网虚拟IP，提供负载均衡服务；当其中一台发生故障时，另一台接管发生故障服务器的公网虚拟IP（这时由非故障机器一台负担所有的请求）。这种方案，经济实惠，非常适合于当前架构环境。
一、keepalived简介
keepalived不同于以前三种高可用解决方案的是为了调用ipvsd命令，并且自动生成规则，并将用户请求访问转移到各个节点上实现的，实质就是对ipvs的高可用。
keepalived通过vrrp协议通过各个高可用节点上的信息，保证设备的高可用，主节点称为master，备用节点称为backup。
模块化设计
核心：
vrrp的实现
基于vrrp之上的对虚拟服务器的控制
checkers：监控服务器是否正常，如果主节点故障通过降低优先级并通过来转移服务。
特点：
只能有一个节点处于活动状态，并不能实现负载均衡。如何实现负载均衡呢，这里可以创建多组资源，每组资源定义不同的内容，使他们直接产生相互主被的关系。
应用场景：
基于上面所讲的负载均衡方式，必然会产生两个完全不同的地址，这样的话对于用户来说就由两个不同的选择，如何实现负载均衡呢？
1、适用于路由器，网关设备，可以将用户自定义不同的网关，来分担路由器的负担。
2、适用于应用类服务，比如web服务，可以通过修改DNS来对同一个域名定义多个ip地址来实现负载均衡。
安全认证机制：
1、明文认证
2、md5认证
主配置文件：/etc/keepalived/keepalived.conf
启动脚本：/etc/init.d/keepalived
通过man命令可以查看keepalived.conf的使用帮助
[[email protected] ~]# man keepalived.conf
配置文件讲解：
1、global configuration
全局定义
静态路由
2、vrrpd configuration
vrrpd同步组（一般不用）
vrrp实例（instance），不同节点的实例配置不同。
3、lvs configuration
虚拟服务器组
虚拟服务器，包含realserver。
global_defs {
notification_email {
[email protected] #设置报警邮件地址，可以设置多个，每行一个。需要开启sendmail服务。
}
notification_email_from keepalived@localhost #设置邮件的发送地址
smtp_server 127.0.0.1 #设置SMTP Server地址
smtp_connect_timeout 30 #设置SMTP Server的超时时间
router_id LVS_DEVEL #表示运行Keepalived服务器的一个标识。发邮件时显示大邮件主题中的信息
}
vrrp_instance VI_1 { #vrrp 实例定义部分
state MASTER #指定Keepalived的角色，MASTER表示此主机是主服务器。BACKUP表示此主机是备用服务器
interface eth1 #指定HA监测网络的接口
virtual_router_id 51 #虚拟路由标识，这个标识是一个数字，同一个vrrp实例使用唯一的标识，即同一个vrrp_instance下MASTER与BACKUP必须是一致的
priority 50 #定义优先级，数字越大，优先级越高
authentication {
auth_type PASS #设置验证类型和密码，MASTER和BACKUP必须使用相同的密码才能正常通信
auth_pass 1111
}
virtual_ipaddress { #设置虚拟IP地址，可以设置多个虚拟IP地址，每行一个
192.168.100.250
}
}
virtual_server 192.168.100.250 80 { #设置虚拟服务器，需要指定虚拟IP地址和服务端口，IP与端口之间用空格隔开
delay_loop 6 #设置运行情况检查时间，单位为秒
lb_algo rr #设置负载调度算法，这里设置rr，即轮询算法
lib_kind DR #设置LVS实现负载均衡机制，有NAT、TUN、DR三个模式可选
persistence_timeout 60 #会话保持单位时间，单位是秒
protocol TCP #指定转发协议类型，有TCP和UDP两种
real_server 192.168.100.60 80 { #配置服务节点1，需要指定real server的真实IP地址和端口
weight 1 #配置服务节点的权值，权值数字越大，权值越高
TCP_CHECK { #relserve的状态检测设置部分，单位是秒
connect_timeout 10 #表示10秒无响应超时
nb_get_retry 3 #表示重试次数
dealy_before_retry 3 #表示重试间隔
}
}
real_server 192.168.100.80 80 {
weight 1
TCP_CHECK {
connect_timeout 10 #表示10秒无响应超时
nb_get_retry 3 #表示重试次数
dealy_before_retry 3 #表示重试间隔
}
}
}
============================================================================================
全局配置：
global_defs {
notification_email {
[email protected] 接收报警的邮箱，可以用多个。
}
notification_email_from keepalived@localhost
smtp_server 127.0.0.1 本机转发email（smtp.server地址）
smtp_connect_timeout 30 连接snmp超时时间
router_id LVS_MASTER 运行Keepalived服务器的一个标识。发邮件时显示在邮件标题中
的信息
}
VRRP实例虚拟服务器部分：
vrrp_instance VI_1 {
state MASTER 状态级别，根据priority来设定的，master的值大于slave的值
interface eth0 检测端口
virtual_router_id 相当于组ID master.slave必须在一个组内，这样slave才能接收到
master发送的vrrp包。
priority 100 优先级
advert_int 1 主从通告间隔秒数
authentication {
auth_type PASS 密钥
auth_pass 1111
}
virtual_ipaddress {
192.168.200.16 （VIP可有多个）
192.168.200.17
192.168.200.18
}
}
virtual_server 192.168.200.100 80{
delay_loop 6 每隔6秒查询realserver状态
lb_algo rr lvs调度算法,这里使用轮询
lb_kind DR lvs负载均衡机制,这里使用直连路由
nat_mask 255.255.255.0
persistence_timeout 60 同一IP的连接60秒内被分配到同一台realserver
protocol TCP 指定转发协议类型，有tcp和udp两种
real_server 192.168.201.100 80 {
weight 1 根据性能分配权值大小，负载不同
TCP_CHECK {
connect_timeout 3 连接超时3秒
nb_get_retry 3 重试次数
delay_before_retry 3 重试间隔
}
}
real_server 192.168.201.101 80{
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
global_defs {
notification_email {
[email protected] ##收件人地址
}
notification_email_from [email protected] ##发件人地址
smtp_server 127.0.0.1 ##centos5使用的是sendmail.centos6使用的是postfix，如果要发送到外外网邮箱，需要单独配置postfix配置文件。
smtp_connect_timeout 30 ##超时时间
router_id LVS_DEVEL_dtedu ##路由器标识，可以不用管
}
vrrp_instance VI_1 { ##一个instance定义一个实例
state MASTER ##定义当前服务器是主状态，如果有多个keepalived节点，同一个实例只能有一个master。
interface eth0 ##通告选举使用的网卡接口
virtual_router_id 51 ##虚拟路由id，此id也是虚拟mac最后一位地址的来源。
priority 100 ##主的优先级要高于backup的优先级
advert_int 1 ##通告时间间隔
authentication { ##认证方式pass（明文）
auth_type PASS
auth_pass 123123
}
virtual_ipaddress { ##虚拟ip地址
10.40.0.227
}
}
#virtual_server 192.168.200.100 443 {
# delay_loop 6 ##ipvs工作模型
# lb_algo rr ##负载均衡算法
# lb_kind NAT
# nat_mask 255.255.255.0
# persistence_timeout 50 ##持久链接时间多长，不使用则为 “0”
# protocol TCP ##使用的协议，目前只支持tcp
#
# real_server 192.168.201.100 443 {
# weight 1
# SSL_GET {
# url {
# path /
# digest ff20ad2481f97b1754ef3e12ecd3a9cc
# }
# url {
# path /mrtg/
# digest 9b3a0c85a887a256d6939da88aabd8cd
# }
# connect_timeout 3
# nb_get_retry 3
# delay_before_retry 3
# }
# }
#}
#
#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 { ##适用于httpd服务，tcp_check适用于msyql之类的链接检查，ssl_check适用于https。
# url {
# path /testurl/test.jsp
# digest 640205b7b0fc66c1ea91c463fac6334d
# }
# url {
# path /testurl2/test.jsp
# digest 640205b7b0fc66c1ea91c463fac6334d
# }
# url {
# path /testurl3/test.jsp
# digest 640205b7b0fc66c1ea91c463fac6334d
# }
# connect_timeout 3 ##链接超时时间为3秒
# nb_get_retry 3 ##超时后尝试次数为3次
# delay_before_retry 3 ##每次尝试链接等待时间为3秒
# }
# }
#
# real_server 192.168.200.3 1358 {
# weight 1
# HTTP_GET {
# url {
# path /testurl/test.jsp