HeartBeat 是Linux-HA的高可用性集群软件，主要作用：
（1）该软件安装在负载均衡器和备机Backup上，运行于激活/备用模式，当负载均衡器失效时,备机自动激活，变成负载均衡器；
（2）当切换到激活模式时，按顺序启动虚拟IP（Virtual IP），IPVS，Ldirectord；
当切换到备用模式时，按顺序关闭Ldirectord，IPVS，虚拟IP（Virtual IP）。
Lirectord
在安装Heartbeat的过程中，就会自动的安装Lirectord，它的作用是：
对Realserver进行健康监测，当RS端的某台或全部主机发生故障时，把他们从负载均衡器的列表里面删除掉，等恢复正常时再重新添加。
环境配置：2台Linux企业6.5的虚拟机作为节点主机.
rpm -ivh heartbeat-3.0.4-2.el6.x86_64.rpm
heartbeat-devel-3.0.4-2.el6.x86_64.rpm
heartbeat-libs-3.0.4-2.el6.x86_64.rpm
ldirectord-3.9.5-3.1.x86_64.rpm
yum install -y * ##安装缺少的软件包，解决依赖性.
cd /usr/share/doc/heartbeat-3.0.4/ ##进入heartbeat-3.0.4的相关配置文件目录下
cp -r ha.cf haresources authkeys /etc/ha.d/
vim /etc/ha.d/ha.cf ##主配置文件
keepalive 2 ##心跳频率2秒一次
deadtime 30 ##节点死亡时间阀值,就是从节点在过了 30 后还没有收到心跳就认为主节点死亡
warntime 10 ##发出警告时间为10S
initdead 60 ##守护进程首次启动后等待60秒后再启动主服务器上的资源
udpport 738 ##心跳信息传递的UDP端口,使用端口738进行bcast和ucast 通信
bcast eth0 ##采用udp广播播来通知心跳
auto_failback on ##当主节点恢复后,是否自动切回
node server2.example.com ##主节点名称，排在第一的默认为主节点
node server3.example.com ##副节点名称
ping 172.25.44.251
respawn hacluster /usr/lib64/heartbeat/ipfail ##默认Heartbeat不检测除本身之外的其他任何服务,也不检测网络状况。所以当网络中断时,并不会进行 Load Balancer 和 Backup 之间的切换。
apiauth ipfail gid=haclient uid=hacluster ##可以通过ipfail插件,设置‘ping nodes‘来解决这一问题。
vim /etc/ha.d/haresources ##资源配置文件
server2.example.com IPaddr::172.25.44.144/24/eth0 mysqld ##主节点 虚拟IP 所启用服务的脚本名称
vim /etc/ha.d/authkeys ##认证文件
auth 1
1 crc ##采用第一种：明文加密方式
chmod 600 /etc/ha.d/authkeys ##将认证文件的权限改成600，仅超级用户可读可写
/etc/init.d/heartbeat start ##首先打开主节点的Heartbeat
tail -f /var/log/messages ##查看日志
测试：
无任何报错，说明开启Mysql成功，如图：
然后再打开副节点的Heartbeat,并利用Mysql服务来检测
登陆主节点上的Mysql能成功登陆，而登陆副节点的Mysql,提示无法连接说明操作成功，如图：
当主节点的Heartbeat停掉时，副节点将会接管虚拟IP和mysql服务，如图：
在接管主机server4上添加4G的磁盘用来共享
yum install -y scsi-target-utils.x86_64 0:1.0.24-10.el6
vim /etc/tgt/targets.conf
<target iqn.2016-06.com.example:server.disk>
backing-store /dev/vdb
initiator-address 172.25.35.4
initiator-address 172.25.35.5
</target>
/etc/init.d/tgtd start ##启动Tgt
在节点主机上：
yum install -y iscsi-initiator-utils-6.2.0.873-10.el6.x86_64
scsiadm -t st -m discovery -p 172.25.35.6 ##查找iSCSI服务器所提供的iSCSI目标
iscsiadm -m node -l ##登录服务器上的iscsi目标
在一台节点主机server2上:
fdisk -cu /dev/sda ##把4G磁盘做成一个分区
n
p
1
w
partprobe ##同步分区表
cat /proc/partitions ##查看分区表信息
mkfs.ext4 /dev/sda1 ##格式化成ext4文件系统
vim /etc/ha.d/haresources
server2.example.com IPaddr::172.25.44.144/24/eth0
Filesystem::/dev/sda1::/var/lib/mysql::ext4 mysqld
/etc/init.d/heartbeat restart ##在主节点上重启Heartbeat
tail -f /var/log/messages ##查看日志
测试：
在主节点上,查看挂载信息和虚拟IP的信息，如图：
DRBD指的是分布式复制块设备，是一种基于软件的,无共享的,在服务器之间的对块设备(硬盘,分区,逻辑卷等)内容的复制存储解决方案。
DRBD 镜像数据的特点
实时性:当应用对磁盘的数据进行修改时,复制立即发生。
透明性:应用程序的数据存储在镜像设备上是独立和透明的,数据可存储在不同的服务器上。
同步镜像和异步镜像:同步镜像,当本地发申请进行写操作进行时,同步写到两台服务器上。异步镜像,当本地写申请已经完成对本地的写操作时,开始对对应的服务器进行写操作。
DRBD 技术的核心功能是通过一个 Linux 内核模块实现的。具体来说,DRBD 包含一个虚拟的块设备,因此 DRBD 是位于“右底部附近的”一个系统的 I/ O 堆栈。正因为如此,DRBD极为灵活,这使得它成为几乎适合任何程序的一个高可用的块复制解决方案，如图：
为了能够管理和配置 DRBD 的资源,DRBD 配备了一些管理工具与内核模块进行通信。
drbdadm:高层的 DRBD 程序管理套件工具。它从配置文件/etc/drbd.conf 中获取所有配
置参数。drbdadm 为 drbdsetup 和 drbdeta 两个命令充当程序的前端应用,执行 drbdadm
实际是执行的 drbdsetup 和 drbdeta 两个命令。
drbdsetup:drbdsetup可以让用户配置已经加载在内核中运行的DRBD模块,它是底层
的 DRBD 程序管理套件工具。使用该命令时,所有的配置参数都需要直接在命令行中定义,
虽然命令和灵活,但是大大的降低了命令的简单易用性,因此很多的用户很少使用
debdsetup。
drbdmeta:drbdmeta允许用户创建、转储、还原和修改drbd的原数据结构。这个命令也是用户极少用到的。
在主节点上，对DRDB的编译过程如下：
首先给两台节点主机分别添加一块4G的磁盘
tar zxf drbd-8.4.3.tar.gz
yum install -y gcc flex rpm-build kernel-devel ##解决软件依赖性
cp drbd-8.4.3.tar.gz rpmbuild/SOURCES/ ##把drbd的包拷贝到rpmbuild编译所需的路径下
rpmbuild -bb drbd.spec ##编译生成二进制drbd rpm包
rpmbuild -bb drbd-km.spec ##编译drbd内核模块
cd drbd-8.4.3/
./configure --enable-spec --with-km
cd rpmbuild/RPMS/x86_64/
rpm -ivh *
把生成的rpm包拷贝到另一台节点主机上，并安装软件包：
scp * 172.25.44.33:
rpm -ivh drbd-*
在主节点server2上；
vim /etc/drbd.d/example.res
resource sqldata {
meta-disk internal;
device /dev/drbd1;
syncer {
verify-alg sha1;
}
on server2.example.com {
disk /dev/vdb;
address 172.25.44.22:7789;
}
on server3.example.com {
disk /dev/vdb;
address 172.25.44.33:7789;
}
}
把配好的example.res文件拷贝到另一台节点主机上
scp /etc/hrbd.d/example.res 172.25.44.33:/etc/hrbd.d/
drbdadm create-md sqldata ##在两台节点主机上分别执行初始化
/etc/init.d/drbd start ##并分别开启DRBD
drbdsetup primary sqldata --force ##把sqldata强制设置成primary节点，并同步数据
watch cat /proc/drbd ##在两台节点主机上分别查看同步状态
测试：
同步结束后，如图：
在主节点server2上;
mkfs.ext4 /dev/drbd1 ##数据同步后，将其格式化为ext4文件系统
mount /dev/drbd1 /mnt/ ##挂载文件系统
cp -rp /var/lib/mysql/* /mnt/ ##存放数据
umount /dev/drbd1 ##卸载文件系统
drbdadm secondary sqldata ##将server2设置secondary节点
在副节点server3上：
drbdadm primary sqldata ##将server3设置primary节点
mount /dev/drbd1 /mnt/ ##挂载文件系统
df ##查看挂载信息
注意：两个节点上的/dev/drbd1不能同时都挂载，只有当一个节点为primary节点而另一个节点为secondary时，才能被挂载使用。
首先将两台节点主机都设为secondary状态：
drbdadm secondary sqldata
在主节点上：
vim /etc/ha.d/haresources
server2.example.com IPaddr::172.25.44.144/24/eth0 drbddisk::sqldata
Filesystem::/dev/drbd1::/var/lib/mysql::ext4 mysqld
把编辑好的文件拷贝给副节点：
scp /etc/ha.d/haresources 172.25.44.33:/etc/ha.d/
在两台节点主机上：
/etc/init.d/mysqld start
/etc/init.d/heartbeat start ##先开主节点再开副节点
tail -f /var/log/messages ##查看运行日志
如图：
测试：
df ##查看挂载信息
ip addr show ##查看虚拟IP
如图：
三种 IP 负载均衡技术的优缺点归纳在下表中：
VS/NAT
VS/NAT 的优点是服务器可以运行任何支持TCP/IP的操作系统,它只需要一个IP地址配置在调度器上,服务器组可以用私有的IP地址。缺点是它的伸缩能力有限, 当服务器结点数目升到20时,调度器本身有可能成为系统的新瓶颈,因为在VS/NAT中请求和响应报文都需要通过负载调度器。
VS/TUN
VS/TUN技术对服务器有要求,即所有的服务器必须支持“ IP Tunneling”或者““ IP Encapsulation”协议。目前,VS/TUN的后端服务器主要运行 Linux 操作系统。在VS/TUN 的集群系统中,负载调度器只将请求调度到不同的后端服务器,后端服务器将应答的数据直接返回给用户。这样,负载调度器就可以处理大量的请求,它甚至可以调 度百台以上的服务器(同等规模的服务器),而它不会成为系统的瓶颈。即使负载调度器只有100Mbps的全双工网卡,整个系统的最大吞吐量可超过1Gbps。所以,VS/TUN可以极大地增加负载调度器调度的服务器数量。VS/TUN调度器可以调度上百台服务器,而它本身不会成为系统的瓶颈,可以用来构建高性能的超级服务器。
VS/DR
跟VS/TUN方法相同,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提高整个集群系统的吞吐量。跟VS/TUN相比,这种方法没有IP隧道的开销,但调度器和服务器组都必须在物理上有一个网卡通过不分断的局域网相连,如通过交换机或者高速的HUB相连。VIP地址为调度器和服务器组共享,调度器配置的VIP地址是对外可见的,用于接收虚拟服务的请求报文;所有的服务器把VIP地址配置在各自的Non-ARP网络设备上,它对外面是不可见的,只是用于处 理目标地址为VIP的网络请求。
LVS的负载调度算法在内核中的连接调度算法上,IPVS已实现了以下十种调度算法:
一 轮叫调度(Round-Robin Scheduling)
轮叫调度(Round Robin Scheduling)算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行 i = (i + 1) mod n,并选出第 i 台服务器。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。
二 加权轮叫调度(Weighted Round-Robin Scheduling)
加权轮叫调度 (Weighted Round-Robin Scheduling)算法可以解决服务器间性能不一的情况,它用相应的权值表示服务器的处理性能,服务器的缺省权值为 1。假设服务器 A 的权值为 1,B 的 权值为 2,则表示服务器 B 的处理性能是 A 的两倍。加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接,权值高的服 务器比权值低的服务器处理更多的连接,相同权值的服务器处理相同数目的连接数。
三 最小连接调度(Least-Connection Scheduling)
最小连接调度(Least- Connection Scheduling)算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器,其连接数加1;当连接中止或超时,其连接数减一。
四 加权最小连接调度(Weighted Least-Connection Scheduling)
加权最小连接调度(Weighted Least-Connection Scheduling)算法是最小连接调度的超集,各个服务器用相应的权值表示其处理性能。服务器的缺省权值为 1,系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。
五 基于局部性的最少链接(Locality-Based Least Connections Scheduling )
基于局部性的最少链接调度(Locality-Based Least Connections Scheduling,以下简称为LBLC)算法是针对请求报文的目标 IP 地址的负载均衡调度,目前主要用Cache集群系统,因为在Cache集群中客户请求报文的目标 IP 地址是变化的。这里假设任何后端服务器都可以
处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标 IP 地址的 请求调度到同一台服务器,来提高各台服务器的访问局部性和主存 Cache 命中率,从而整个集群系统的处理能力。LBLC 调度算法先根据请求的目标 IP 地址 找出该目标 IP 地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于其一半的工 作负载,则用“最小连接”的原则选出一个可用的服务器,将请求发送到该服务器。
六 带复制的基于局部性最少链接(Locality-Based Least Connections with
Replication Scheduling)
带复制的基于局部性最少链接调度(Locality-Based Least Connections with Replication Scheduling,以下简称为 LBLCR)算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要 维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求,一台Cache服务器可能会忙不过来处理这些请求。这时,LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器,映射该“热门”站点到这台 Cache服务器，很快这台Cache服务器也会超载,就会重复上述过程选出新的Cache服务器。这样,可能会导致该“热门”站点的映像会出现在所有的Cache服务器上,降低了Cache 服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器(服务器集合),当该“热门”站点的请求负载增加时,会增加集合里的Cache服务器,来处理不断增长的负载;当该“热门”站点的请求负载降低时,会减少集合里的Cache服务器 数目。这样,该“热门”站点的映像不太可能出现在所有的Cache服务器上,从而提供 Cache集群系统的使用效率。LBLCR算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组;按“最小连接”原则从该服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载;则按“最小连接”原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服 务器从服务器组中删除,以降低复制的程度。
七 目标地址散列调度(Destination Hashing Scheduling)
目标地址散列调度 (Destination Hashing Scheduling)算法也是针对目标IP地址的负载均衡,但它是一种静态映射算法,通过一个散列(Hash)函数将一个目标 IP 地址映射到一台服务器。目标地址散列调度算法先根据请求的目标 IP 地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。
八 源地址散列调度(Source Hashing Scheduling)
源地址散列调度(Source Hashing Scheduling)算法正好与目标地址散列调度算法相反,它根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目标地散列调度算法 的相同。它的算法流程与目标地址散列调度算法的基本相似,除了将请求的目标 IP 地址换成请求的源 IP 地址,所以这里不一一叙述。在实际应用中,源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中,它们可以保证整个系统的唯一出入口。
九 最短的期望的延迟（Shortest Expected Delay Scheduling SED）(SED)
基于wlc算法。这个必须举例来说了
ABC三台机器分别权重123 ，连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用sed算法后会进行这样一个运算
A(1+1)/1
B(1+2)/2
C(1+3)/3
根据运算结果，把连接交给C 。
十 最少队列调度（Never Queue Scheduling NQ）(NQ)
无需队列。如果有台 realserver的连接数＝0就直接分配过去，不需要在进行sed运算。
环境配置：两台VS（虚拟服务器）主机server2,server3 两台RS（真实服务器）主机server4，server5
在VS端（server2,server3上作相同操作）：
ip addr add 172.25.44.144/24 dev eth0 ##在eth0上添加VIP（虚拟网络地址）
ipvsadm -l ##显示VS端主机列表
ipvsadm -C ##清除所有列表
ipvsadm -A -t 172.25.44.144:80 -s rr ##给指定的VIP添加轮叫调度算法
ipvsadm -a -t 172.25.44.144:80 -r 172.25.44.44:80 -g ##给VIP添加真实服务器RS的IP，使用默认网关
ipvsadm -a -t 172.25.44.144:80 -r 172.25.44.44:80 -g
在RS端（server4,server5上作相同操作）：
ip addr add 172.25.44.144/32 dev eth0 ##在eth0上添加VIP（虚拟网络地址）
vim /var/www/html/index.html ##在Apache的默认发布目录下写入测试页
server4.example.com ##在server5上作同样操作
yum install -y arptables_jf ##通过使用arptables_jf来直接路由，不对外响应
arptables -A IN -d 172.25.44.144 -j DROP
arptables -A OUT -d 172.25.44.144 -j mangle --mangle-ip-s 172.25.44.55 ##为每台真实服务器（server4,server5)的虚拟IP创建ARP列表，导致真实服务器忽略所有针对于虚拟IP的ARP请求，并且不对外响应，把原来含有虚拟IP的ARP回应改成真实服务器的IP。对VIP回应的节点变成启用中的LVS节点。
/etc/init.d/arptables_jf save ##存储ARP表格项目
/etc/init.d/arptables_jf start ##启动arptables_jf
/etc/init.d/httpd start ##启动Apache
测试：
访问172.25.44.144（虚拟IP），反复刷新网页，每次出现的网页不同则表示成功，如图：
在安装Heartbeat的过程中，就会自动的安装Lirectord，它的作用是：
对Realserver进行健康监测，当RS端的某台或全部主机发生故障时，把他们从负载均的列表里面删除掉，等恢复正常时再重新添加。
cp /usr/share/doc/ldirectord-3.9.5/ldirectord.cf /etc/ha.d/
vim /etc/ha.d/ldirectord.cf
# Sample for an http virtual service
virtual=172.25.44.144:80 ##虚拟IP
real=172.25.44.44:80 gate
real=172.25.44.55:80 gate
fallback=127.0.0.1:80 gate ##RS全部发生故障切换回本机
service=http
scheduler=rr ##轮叫调度算法
#persistent=600
#netmask=255.255.255.255
protocol=tcp
checktype=negotiate
checkport=80
request="index.html"
# receive="Test Page"
# virtualhost=www.x.y.z
vim /var/www/html/index.html ##在Apache的默认发布目录下写入测试页
server2.example.com
测试：
当RS端停掉server4的Apache服务时，用ipvsadm -l 即可监测到故障，如图：
当RS端的全部服务器都停掉Apache时，用ipvsadm -l 即可监测到故障，如图：
在主节点server2上：
vim /etc/ha.d/haresources
server2.example.com IPaddr::172.25.44.144/24/eth0 httpd ldirectord
scp /etc/ha.d/haresources /etc/ha.d/ldirectord.cf 172.25.44.33:/etc/ha.d/ ##将修改过的配置文件拷贝给副节点
/etc/init.d/heartbeat stop
/etc/init.d/ldirectord start
/etc/init.d/httpd start
测试：
当RS端的主机全部停掉Apache服务，同时停掉VS端主节点上的Heartbeat时，由于其具有高可用性，依然具有健康检查的功能，如图：
tar zxf keepalived-1.2.20.tar.gz
rpm -ivh libnfnetlink-devel-1.0.0-1.el6.x86_64.rpm
yum install ipvsadm kernel-devel openssl-devel popt-devel libnl-devel gcc net-snmp-devel -y
##安装软件，解决依赖性
cd keepalived-1.2.20/
./configure --prefix=/usr/local/keepalived
make && make install
ln -s /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
ln -s /usr/local/keepalived/etc/keepalived /etc/
ln -s /usr/local/keepalived/sbin/keepalived /sbin/
ln -s /usr/local/keepalive/bin/genhash /bin/
vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
root@localhost ##接收警报的email地址
}
notification_email_from Keepalived@server2.example.com ###设置邮件的发送地址
smtp_server 127.0.0.1 ##设置smtp server地址
smtp_connect_timeout 30 ##设置连接smtp服务器超时时间
router_id LVS_DEVEL ##load balancer的标识ID,用于email警报
vrrp_skip_check_adv_addr
vrrp_strict
}
vrrp_instance VI_1 {
state MASTER ##备机改为 BACKUP,此状态是由priority的值来决定的,当前
priority的值小于备机的值,那么将会失去MASTER状态
interface eth0 ##HA 监测网络接口
virtual_router_id 51 ##主、备机的virtual_router_id必须相同,取值0-255
priority 100 ##主机的优先级,备份机改为 50,主机优先级一定要大于备机
advert_int 1 ##主备之间的通告间隔秒数
authentication {
auth_type PASS ##设置验证类型,主要有 PASS 和 AH 两种
auth_pass 1111 ##设置验证密码,在一个 vrrp_instance下,MASTER 与 BACKUP必须使用相同的密码才能正常通信
}
virtual_ipaddress { ##设置虚拟 IP 地址
172.25.44.144
}
}
virtual_server 172.25.44.22 80 { ##定义虚拟服务器
delay_loop 6 ##每隔 6 秒查询 realserver 状态
lb_algo rr ##轮叫调度算法
lb_kind DR ##LVS是用DR模式
# persistence_timeout 50 ##会话保持时间,单位是秒,这个选项对于动态网页是非常有用的,为集群系统中 session 共享提供了一个很好的解决方案。有了这个会话保持功能,用户的
请求会被一直分发到某个服务节点,直到超过这个会话保持时间。需要注意的是,这个会话保
持时间,是最大无响应超时时间,也就是说用户在操作动态页面时,如果在 50 秒内没有执行任何操作,那么接下来的操作会被分发到另外节点,但是如果一直在操作动态页面,则不受 50 秒的时间限制。
protocol TCP
real_server 172.25.44.44 80 { ##配置服务节点
weight 1配置服务节点的权值,权值大小用数字表示,数字越大,权值越高,设置权值的大小可以为不同性能的服务器分配不同的负载,可以对性能高的服务器设置较高的权值,而对性能较低的服务器设置相对较低的权值,这样就合理的利用和分配了系统资源。
TCP_CHECK { ##realserve的状态检测设置部分,单位是秒
connect_timeout 3 ##3秒无响应超时
nb_get_retry 3 ##重试次数
delay_before_retry 3 ##重试间隔
}
}
real_server 172.25.44.55 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
scp /etc/keepalived/keepalived.conf root@172.25.44.33:/etc/keepalived/
/etc/init.d/keepalived start ##依次启动主，备机的keepalived
测试：
高可用测试:停止 master 上的 keepalived 服务,看 backup 是否接管，如图：
负载均衡测试:访问 http://192.168.0.163,看到页面在两个Realserver上切换表示成功,如图：
本文出自 “8875406” 博客，谢绝转载！
Heartbeat+DRDB+LVS+Keepalived+Ldirectord
原文地址：http://8885406.blog.51cto.com/8875406/1791208
