LVS
集群的分类
负载均衡集群 (LB Load-balancing) 解决大量并发请求的情况下服务器压力大的问题，服务器之间是平等的，各个服务器之间不会检测相邻节点的状态，需要有一个分发器，使各个服务器能够均衡
高可用性集群 (HA High Availablity )服务不会中断，当一台失效，另一台会立即替代，standby 实时监控主的信息，为了避免主备服务器发生资源争用，双方有个节点（Stonith），当发生资源征用时，主服务器会使备份主机立即断电即（brain-split）
高性能集群 (HP High Performancing) 把一个任务物分给n个服务器，再让她们集合在一起。
一组服务器通过高速的局域网或者地理分布的广域网相互连接，在它们的前端有一个负载调度器（Load Balancer）。负载调度器能无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访问一台高性能、高可用的服务器一样。客户程序不受服务器集群的影响不需作任何修改。系统的伸缩性通过在服务机群中透明地加入和删除一个节点来达到，通过检测节点或服务进程故障和正确地重置系统达到高可用性由于这种负载调度技术是在Linux内核中实现的，所以称之为Linux虚拟服务器。
为了更好的学习以下的内容，我们首先说明一些规则
如上图所示：
CIP指客户端访问VIP的地址
VIP是客户端要访问的地址，也是Director向外提供服务的IP
DIP是Director与realserver进行通信的IP
RIP是集群节点的IP，也是真正提供服务的IP
Director也就是所说的调度器
Cluster node 就是经常说的realserver
LVS具有很好的可伸缩性，可靠性和可管理性。
IP虚拟服务器软件IPVS实现了通过网络地址转换，通过IP隧道，通过直接路由实现虚拟服务器的方法。也即是说IPVS软件实现了这三种IP负载均衡技术。
Virtual Server via Network Address Translation (VS/NAT)
通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址重写，再返回给客户端。所有的真实服务器必须和DIP处以一个网段，RIP必须是私有地址，Director负责调度请求与真实服务器的机制，realserver以DIP作为自己的默认网关，Director可以做端口映射，任意类型的操作系统都可以做realserver，Director往往是网络的瓶颈。常常可以用作20台以下的realserver 和防火墙不兼容
Virtual Server via IP Tunneliing（VS/TUN）
调度器把请求报文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，随意调度器之处理请求报文，Director把客户端的请求数据包重新封装，然后发给realserver，Realserver不需要和Director在同一网段，RIP必须是公网地址，出去的连接不经过Director，Director不能做端口映射。Cluster的网关一定不能指向DIP，必须指向路由器。
Virtual Server via Director Routing（VS/DR）
通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将请求直接返回给客户，要求调度器与真实服务器都有一块网卡连接在同一物理网段上。
IPVS支持的调度算法
静态调度方式：轮流不关注服务器当前工作状态
Round-robin（RR）轮叫，
调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。Weighted round-robin（WRR）加权轮叫
调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。
Destination hashing 只要来源是同一个IP的数据包就把它分给某一个服务器，多用于代理服务器上。
Source hashing 固定源地址，便于防火墙对源地址追踪，多用于director有多个网络接口的情况下，以便于director知道应该从哪个防火墙或者路由器回复数据给客户端
动态调度方式：关注服务器的当前工作状态，但需要额外的开销、Director要做连接追踪，根据服务器工作状态进行分配。当动态调度方式被使用时，Director对活动的和不活动的连接进行追踪，从而决定新的连接到来时把连接分给那个cluster，在linux Enterprise Cluster中，telnet和ssh连接在她们从开始连接时就应该处于活动状态。不活动连接则不需要处于状态检测的状态。因此ESTABLISH可以用来区别活动与不活动连接，当TCP连接超时或者客户端结束连接时，LVS还会保持简单的连接防止是由于外因而造成的意外中断，
Least-connection（LC）最少连接
调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。计算方法是把活动连接乘以256加上非活动连接数，然后决定分发给谁，值最小的就会接受下一个访问，
Weighted Least-connection（WLC）加权负载连接，先计算当前的overhead值，然后将得到的值除以权重，谁的最小谁将接受下一个连接，这就需要为每一个服务器分配权重
Shortest Expected Delay最短期望延迟 不再关注非活动连接，而是将得到的overhead的值加1，然后除以权重，结果小的cluster将处理新的连接
Never Query 如果一个cluster还没有活动的连接，他就会处理新的连接，而不管他的SED值是多少
Locality-Based Least_connection LBLC 基于本地的最少连接 来自于同一个IP地址的发给一个服务器
Locality-Based Least_connection with Replication Scheduling LBLCR带复制的基于本地的最少连接 把realserver分组
我们知道在VS/DR或VS/TUN应用的一种模型中（所有机器都在同一个物理网络），所有机器（包括Director和RealServer）都使用了一个额外的IP地址，即VIP。当一个客户端向VIP发出一个连接请求时，此请求必须要连接至Director的VIP，而不能是RealServer的。因为，LVS的主要目标就是要Director负责调度这些连接请求至RealServer的。因此，在Client发出至VIP的连接请求后，只能由Director将其MAC地址响应给客户端（也可能是直接与Director连接的路由设备），而Director则会相应的更新其ipvsadm table以追踪此连接，而后将其转发至后端的RealServer之一。如果Client在请求建立至VIP的连接时由某RealServer响应了其请求，则Client会在其MAC table中建立起一个VIP至RealServer的对就关系，并以一直进行后面的通信。此时，在Client看来只有一个RealServer而无法意识到其它服务器的存在。为了解决此问题，可以通过在路由器上设置其转发规则来实现。当然，如果没有权限访问路由器并做出相应的设置，则只能通过传统的本地方式来解决此问题了。
这些方法包括：
1、禁止RealServer响应对VIP的ARP请求；
2、在RealServer上隐藏VIP，以使得它们无法获知网络上的ARP请求；
3、基于“透明代理（Transparent Proxy）”或者“fwmark （firewall mark）”；
4、禁止ARP请求发往RealServers；
传统认为，解决ARP问题可以基于网络接口，也可以基于主机来实现。Linux采用了基于主机的方式，因为其可以在大多场景中工作良好，但LVS却并不属于这些场景之一，因此，过去实现此功能相当麻烦。现在可以通过设置arp_ignore和arp_announce，这变得相对简单的多了。Linux 2.2和2.4（2.4.26之前的版本）的内核解决“ARP问题”的方法各不相同，且比较麻烦。幸运的是，2.4.26和2.6的内核中引入了两个新的调整ARP栈的标志（device flags）：arp_announce和arp_ignore。基于此，在DR/TUN的环境中，所有IPVS相关的设定均可使用arp_announce=2和arp_ignore=1/2/3来解决“ARP问题”了。下面是一些定义：
Arp_announce不是发布自己的主地址，而可能是别名地址 0一般使用主地址 1 避免使用与对方的地址不再一个网段的地址响应请求（尽量使用与对方在同一个地址段的地址响应）2 使用最好的地址（基于算法）
arp_ignore 定义怎样响应给别人 0 任意的都可以 1 从那块网卡进用那块网卡响应 2
arp_announce
2009-06-11 14:08arp_announce :INTEGER 不同取值表示对网络接口上本地IP地址发出的ARP回应作出相应级别的限制：相关代码在 默认为0
确定不同程度的限制,宣布对来自本地源IP地址发出Arp请求的接口
0 - (默认) 在任意网络接口上的任何本地地址
1 -尽量避免不在该网络接口子网段的本地地址. 当发起ARP请求的源IP地址是
CIP指客户端访问VIP的地址
VIP是客户端要访问的地址，也是Director向外提供服务的IP
DIP是Director与realserver进行通信的IP
RIP是集群节点的IP，也是真正提供服务的IP
Director也就是所说的调度器
Cluster node 就是经常说的realserver
LVS具有很好的可伸缩性，可靠性和可管理性。
IP虚拟服务器软件IPVS实现了通过网络地址转换，通过IP隧道，通过直接路由实现虚拟服务器的方法。也即是说IPVS软件实现了这三种IP负载均衡技术。
Virtual Server via Network Address Translation (VS/NAT)
通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址重写，再返回给客户端。所有的真实服务器必须和DIP处以一个网段，RIP必须是私有地址，Director负责调度请求与真实服务器的机制，realserver以DIP作为自己的默认网关，Director可以做端口映射，任意类型的操作系统都可以做realserver，Director往往是网络的瓶颈。常常可以用作20台以下的realserver 和防火墙不兼容
Virtual Server via IP Tunneliing（VS/TUN）
调度器把请求报文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，随意调度器之处理请求报文，Director把客户端的请求数据包重新封装，然后发给realserver，Realserver不需要和Director在同一网段，RIP必须是公网地址，出去的连接不经过Director，Director不能做端口映射。Cluster的网关一定不能指向DIP，必须指向路由器。
Virtual Server via Director Routing（VS/DR）
通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将请求直接返回给客户，要求调度器与真实服务器都有一块网卡连接在同一物理网段上。
IPVS支持的调度算法
静态调度方式：轮流不关注服务器当前工作状态
Round-robin（RR）轮叫，
调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。Weighted round-robin（WRR）加权轮叫
调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。
Destination hashing 只要来源是同一个IP的数据包就把它分给某一个服务器，多用于代理服务器上。
Source hashing 固定源地址，便于防火墙对源地址追踪，多用于director有多个网络接口的情况下，以便于director知道应该从哪个防火墙或者路由器回复数据给客户端
动态调度方式：关注服务器的当前工作状态，但需要额外的开销、Director要做连接追踪，根据服务器工作状态进行分配。当动态调度方式被使用时，Director对活动的和不活动的连接进行追踪，从而决定新的连接到来时把连接分给那个cluster，在linux Enterprise Cluster中，telnet和ssh连接在她们从开始连接时就应该处于活动状态。不活动连接则不需要处于状态检测的状态。因此ESTABLISH可以用来区别活动与不活动连接，当TCP连接超时或者客户端结束连接时，LVS还会保持简单的连接防止是由于外因而造成的意外中断，
Least-connection（LC）最少连接
调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。计算方法是把活动连接乘以256加上非活动连接数，然后决定分发给谁，值最小的就会接受下一个访问，
Weighted Least-connection（WLC）加权负载连接，先计算当前的overhead值，然后将得到的值除以权重，谁的最小谁将接受下一个连接，这就需要为每一个服务器分配权重
Shortest Expected Delay最短期望延迟 不再关注非活动连接，而是将得到的overhead的值加1，然后除以权重，结果小的cluster将处理新的连接
Never Query 如果一个cluster还没有活动的连接，他就会处理新的连接，而不管他的SED值是多少
Locality-Based Least_connection LBLC 基于本地的最少连接 来自于同一个IP地址的发给一个服务器
Locality-Based Least_connection with Replication Scheduling LBLCR带复制的基于本地的最少连接 把realserver分组
我们知道在VS/DR或VS/TUN应用的一种模型中（所有机器都在同一个物理网络），所有机器（包括Director和RealServer）都使用了一个额外的IP地址，即VIP。当一个客户端向VIP发出一个连接请求时，此请求必须要连接至Director的VIP，而不能是RealServer的。因为，LVS的主要目标就是要Director负责调度这些连接请求至RealServer的。因此，在Client发出至VIP的连接请求后，只能由Director将其MAC地址响应给客户端（也可能是直接与Director连接的路由设备），而Director则会相应的更新其ipvsadm table以追踪此连接，而后将其转发至后端的RealServer之一。如果Client在请求建立至VIP的连接时由某RealServer响应了其请求，则Client会在其MAC table中建立起一个VIP至RealServer的对就关系，并以一直进行后面的通信。此时，在Client看来只有一个RealServer而无法意识到其它服务器的存在。为了解决此问题，可以通过在路由器上设置其转发规则来实现。当然，如果没有权限访问路由器并做出相应的设置，则只能通过传统的本地方式来解决此问题了。
这些方法包括：
1、禁止RealServer响应对VIP的ARP请求；
2、在RealServer上隐藏VIP，以使得它们无法获知网络上的ARP请求；
3、基于“透明代理（Transparent Proxy）”或者“fwmark （firewall mark）”；
4、禁止ARP请求发往RealServers；
传统认为，解决ARP问题可以基于网络接口，也可以基于主机来实现。Linux采用了基于主机的方式，因为其可以在大多场景中工作良好，但LVS却并不属于这些场景之一，因此，过去实现此功能相当麻烦。现在可以通过设置arp_ignore和arp_announce，这变得相对简单的多了。Linux 2.2和2.4（2.4.26之前的版本）的内核解决“ARP问题”的方法各不相同，且比较麻烦。幸运的是，2.4.26和2.6的内核中引入了两个新的调整ARP栈的标志（device flags）：arp_announce和arp_ignore。基于此，在DR/TUN的环境中，所有IPVS相关的设定均可使用arp_announce=2和arp_ignore=1/2/3来解决“ARP问题”了。下面是一些定义：
Arp_announce不是发布自己的主地址，而可能是别名地址 0一般使用主地址 1 避免使用与对方的地址不再一个网段的地址响应请求（尽量使用与对方在同一个地址段的地址响应）2 使用最好的地址（基于算法）
arp_ignore 定义怎样响应给别人 0 任意的都可以 1 从那块网卡进用那块网卡响应 2
arp_announce
2009-06-11 14:08arp_announce :INTEGER 不同取值表示对网络接口上本地IP地址发出的ARP回应作出相应级别的限制：相关代码在 默认为0
确定不同程度的限制,宣布对来自本地源IP地址发出Arp请求的接口
0 - (默认) 在任意网络接口上的任何本地地址
1 -尽量避免不在该网络接口子网段的本地地址. 当发起ARP请求的源IP地址是
被设置应该经由路由达到此网络接口的时候很有用.此时会检查来访IP是否为所有接口上的子网段内ip之一.如果该来访IP 不属于各个网络接口上的子网段内,那么将采用级别2的方式来进行处理.
2 - 对查询目标使用最适当的本地地址.在此模式下将忽略这个IP数据包的源地址并尝试选择与能与该地址通信的本地地址.首要是选择所有的网络接口的子网中外出 访问子网中包含该目标IP地址的本地地址. 如果没有合适的地址被发现,将选择当前的发送网络接口或其他的有可能接受到该ARP回应的网络接口来进行发送；
当内网的机器要发送一个到外部的ip包，那么它就会请求路由器的Mac地址，发送一个arp请求，这个arp请求里面包括了自己的ip地址和Mac地址，而linux默认是使用ip的源ip地址作为arp里面的源ip地址，而不是使用发送设备上面的，如果设置 arp_announce 为2，则使用发送设备上的ip。
arp_ignore : INTEGER 定义对目标地址为本地IP的ARP询问不同的应答模式，相关代码在arp_announce 函数中 默认为0
0 - (默认值): 回应任何网络接口上对任何本地IP地址的arp查询请求（比如eth0=192.168.0.1/24,eth1=10.1.1.1/24,那么即使 eth0收到来自10.1.1.2这样地址发起的对10.1.1.1 的arp查询也会回应--而原本这个请求该是出现在eth1上，也该由eth1回应的）
1 - 只回答目标IP地址是来访网络接口本地地址的ARP查询请求（比如eth0=192.168.0.1/24,eth1=10.1.1.1/24,那么即使 eth0收到来自10.1.1.2这样地址发起的对192.168.0.1的查询会回答，而对10.1.1.1 的arp查询不会回应）
2 -只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内（比如 eth0=192.168.0.1/24,eth1=10.1.1.1/24,eth1收到来自10.1.1.2这样地址发起的对192.168.0.1 的查询不会回答，而对192.168.0.2发起的对192.168.0.1的arp查询会回应）
3 - 不回应该网络界面的arp请求，而只对设置的唯一和连接地址做出回应(do not reply for local addresses configured with scope host,only resolutions for global and link addresses are replied )
4-7 - 保留未使用
8 -不回应所有（本地地址）的arp查询
如果我们想在cluster上隐藏VIP的方式如下：
echo 1 > /proc/sys/net/ipv4/cconf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/cconf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/cconf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/cconf/lall/arp_announce
这样我们就将VIP附加在了lo上。
LVS persistence可以保证使来自同一个源地址定义到同一台服务器
不管你选择的转发的方式，如果需要确保来自于一个IP的所有连接都发往同一个cluster，这时就需要LVS persistence。Director使用连接追踪记录用来确保同一个Ip的client都到达同一个cluster，当有新的连接请求时director将会查看自己的模板记录看那一台cluster已经和client建立过连接。
Persistence connection Template 持久连接模板，保证所有来自于同一个地址的请求，都定向到同一个服务器
下面我们说一下ipvsadm
ipvsadm是运行于用户空间、用来与ipvs交互的命令行工具，它的作用表现在：
1、定义在Director上进行dispatching的服务(service)，以及哪此服务器(server)用来提供此服务；
2、为每台同时提供某一种服务的服务器定义其权重（即概据服务器性能确定的其承担负载的能力）；
注：权重用整数来表示，有时候也可以将其设置为atomic_t；其有效表示值范围为24bit整数空间，即（2^24-1）；
因此，ipvsadm命令的主要作用表现在以下方面：
1、添加服务（通过设定其权重>0）；
2、关闭服务（通过设定其权重>0）；此应用场景中，已经连接的用户将可以继续使用此服务，直到其退出或超时；新的连接请求将被拒绝；
3、保存ipvs设置，通过使用“ipvsadm-sav > ipvsadm.sav”命令实现；
4、恢复ipvs设置，通过使用“ipvsadm-sav < ipvsadm.sav”命令实现；
5、显示ip_vs的版本号，下面的命令显示ipvs的hash表的大小为4k；
# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
6、显示ipvsadm的版本号
# ipvsadm --version
ipvsadm v1.24 2003/06/07 (compiled with popt and IPVS v1.2.0)
二、ipvsadm使用中应注意的问题
默认情况下，ipvsadm在输出主机信息时使用其主机名而非IP地址，因此，Director需要使用名称解析服务。如果没有设置名称解析服务、服务不可用或设置错误，ipvsadm将会一直等到名称解析超时后才返回。当然，ipvsadm需要解析的名称仅限于RealServer，考虑到DNS提供名称解析服务效率不高的情况，建议将所有RealServer的名称解析通过/etc/hosts文件来实现；
持久连接的类型：
PCC 持久客户端连接 所有服务都定义到一个服务器 服务指定端口为0
例如：如果你想让一个基于http和https连接都到达同一个网站，那么你就要在director上做下列的设置：
ipvsadm -A -t 192.168.0.138:0 -s rr �Cp
ipvsadm -a -t 192.168.0.138:0 -r 192.168.0.132:0 �Cm
ipvsadm -a -t 192.168.0.138:0 -r 192.168.0.131:0 -m
PPC 端口持续连接 只能保证一个连接
PNMP 如果LVS放置于多防火墙的网络中，并且每个防火墙都用到了状态追踪的机制，那么在回应一个针对于LVS的连接请求时必须经过此请求连接进来时的防火墙，否则，这个响应的数据包将会被丢弃。
例如我们希望创建一个一个小时的基于80和443端口持续连接，我们可以做一下设置：
Iptables �Ct mangle �CA PREROUTING �Cd VIP �Cp tcp �Cdport 80 �Cj MARK --set-mark 1
Iptables �Ct mangle �CA PREROUTING �Cd VIP �Cp tcp �Cdport 443 �Cj MARK --set-mark 1
ipvsadm -A -f 1 -s rr -p 3600
ipvsadm -a -f 1 -r realserver1 -m
ipvsadm -a -f 1 -r realserver2 -m
关于IPVS的一些简单设置，这里就不再演示了，因为下面我们会多次用到，在那时再详细的说。
Heartbear
为了提供一个高可用性集群，我们常常需要两台甚至多台转发器，当一台director不再工作时，另外一台转发器就能立即接管direcctor的所有资源，而提供director所提供的所有服务，这样才不至于让客户访问不到资源。为了让备转发器能够在第一时间知道director的工作状态，我们需要时时探测director的工作状态、。这种机制我们称之为“心跳”heartbeat。运行于备用主机上的Heartbeat可以通过以太网连接检测主服务器的运行状态，一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。通常情况下，主、备服务器间的心跳连接是一个独立的物理连接，这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。
Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态，而其只要能通过其中一个连接收到主服务器处于活动状态的信息，就会认为主服务器处于正常状态。
从实践经验的角度来说，建议为Heartbeat配置多条独立的物理连接，以避免Heartbeat通信线路本身存在单点故障。
1、串行电缆：被认为是比以太网连接安全性稍好些的连接方式，因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序，从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度，因此主、备服务器的距离必须非常短。
2、以太网连接：使用此方式可以消除串行线缆的在长度方面限制，并且可以通过此连接在主备服务器间同步文件系统，从而减少了从正常通信连接带宽的占用。
基于冗余的角度考虑，应该在主、备服务器使用两个物理连接传输heartbeat的控制信息；这样可以避免在一个网络或线缆故障时导致两个节点同时认为自已是唯一处于活动状态的服务器从而出现争用资源的情况，这种争用资源的场景即是所谓的“脑裂”（split-brain）或“partitioned cluster”。在两个节点共享同一个物理设备资源的情况下，脑裂会产生相当可怕的后果。
为了避免出现脑裂，可采用下面的预防措施：
1、如前所述，在主、备节点间建立一个冗余的、可靠的物理连接来同时传送控制信息；
2、一旦发生脑裂时，借助额外设备强制性地关闭其中一个节点；
第二种方式即是俗称的“将其它节点‘爆头’（shoot the other node in the head）”，简称为STONITH。基于能够通过软件指令关闭某节点特殊的硬件设备，
Heartbeat即可实现可配置的Stonith。但当主、备服务器是基于WAN进行通信时，则很难避免“脑裂”情景的出现。因此，当构建异地“容灾”的应用时，应尽量避免主、备节点共享物理资源。
Heartbeat的控制信息：
“心跳”信息: （也称为状态信息）仅150 bytes大小的广播、组播或多播数据包。可为以每个节点配置其向其它节点通报“心跳”信息的频率，
以及其它节点上的heartbeat进程为了确认主节点出节点出现了运行等错误之前的等待时间。
集群变动事务（transition）信息：ip-request和ip-request-rest是相对较常见的两种集群变动信息，它们在节点间需要进行资源迁移时为不同节点上heartbeat进程间会话传递信息。比如，当修复了主节点并且使其重新“上线”后，主节点会使用ip-request要求备用节点释放其此前从因主节点故障而从主节点那里接管的资源。此时，备用节点则关闭服务并使用ip-request-resp通知主节点其已经不再占用此前接管的资源。主接点收到ip-request-resp后就会重新启动服务。
重传请求：在某集群节点发现其从其它节点接收到的heartbeat控制信息“失序”（heartbeat进程使用序列号来确保数据包在传输过程中没有被丢弃或出现错误）时，会要求对方重新传送此控制信息。 Heartbeat一般每一秒发送一次重传请求，以避免洪泛。
上面三种控制信息均基于UDP协议进行传送，可以在/etc/ha.d/ha.cf中指定其使用的UDP端口或者多播地址（使用以太网连接的情况下）。
此外，除了使用“序列号/确认”机制来确保控制信息的可靠传输外，Heartbeat还会使用MD5或SHA1为每个数据包进行签名以确保传输中的控制信息的安全性。
为了实验的方便我们需要安装下列软件包
libnet-1.1.4-3.el5.i386.rpm perl-MailTools-1.77-1.el5.noarch.rpm
heartbeat-pils-2.1.4-10.el5.i386.rpm heartbeat-stonith-2.1.4-10.el5.i386.rpm
heartbeat-gui-2.1.4-10.el5.i386.rpm heartbeat-ldirectord-2.1.4-10.el5.i386.rpm
heartbeat-devel-2.1.4-10.el5.i386.rpm heartbeat-2.1.4-10.el5.i386.rpm
perl-Compress-Zlib perl-HTML-Parser
perl-HTML-Tagset perl-URI perl-libwww-perl
perl-MailTools perl-TimeDate perl-String-CRC32 net-snmp-libs
由于包之间有较强的依赖性，我们建议用yum进行安装，这样就省去了很多不必要的麻烦，
Heartbeat的主配置文件是/etc/ha.d/ha.cf,/etc/ha.d/haresources和/etc/authkeys。当我们安装好上面的包时，在/etc/ha.d/目录中没有我们的主配置文件，这时我们可以去/usr/share/doc/heartbeat-2.1.4/目录中拷贝。
/etc/ha.d/ha.cf定义位于不同节点上的heartbeat进程间如何进行通信；
logfile /var/log/ha-log定义日志信息
keepalive N 定义多长时间备设备向主设备探测一次心跳信息，单位为秒
deadtime 30 定义探测不到director心跳后经过多长时间采取措施
udpport 694 定义监听的端口
bcast eth1 定义通过那个网卡监听director的心跳信息
auto_failback on 当主转发器从down机中恢复过来后，是否继续充当director
node node1.example.com 主转发器的主机名
node node2.example.com 备转发器的主机名
/etc/ha.d/haresources
定义对某个资源来说哪个服务器是主节点，以及哪个节点应该拥有客户端访问资源时的目标IP地址。
haresources配置文件介绍：
主从节点上的/etc/ra.d/raresource文件必须完全相同。文件每行通常包含以下组成部分：
1、服务器名字：指正常情况下资源运行的那个节点（即主节点），后跟一个空格或tab；这里指定的名字必须跟某个节点上的命令"uname -n"的返回值相同；
2、IP别名（即额外的IP地址，可选）：在启动资源之前添加至系统的附加IP地址，后跟空格或tab；IP地址后面通常会跟一个子网掩码和广播地址，彼此间用“/”隔开；
3、资源脚本：即用来启动或停止资源的脚本，位于/etc/init.d/或/etc/ha.d/resourcd.d目录中；如果需要传递参数给资源脚本，脚本和参数之间需要用两个冒号分隔，多个参数时彼此间也需要用两个冒号分隔；如果有多个资源脚本，彼此间也需要使用空格隔开；
格式如下：
primary-server [IPaddress[/mask/interface/broadcast]] resource1[::arg1::arg2] resource2[::arg1::arg2]
例如：
primary-server 221.67.132.195 sendmail httpd
/etc/ha.d/authkeys
定义Heartbeat包在通信过程中如何进行加密。
当ha.cf或authkeys文件发生改变时，需要重新加载它们就可以使用之生效；
而如果haresource文件发生了改变，则只能重启heartbeat服务方可使之生效。
HA（高可用性集群）的LVS集群有两台Director，在启动时，主节点占有集群负载均衡资源（VIP和LVS的转发及高度规则），
备用节点监听主节点的“心跳”信息并在主节点出现异常时进行“故障转移”而取得资源使用权，这包括如下步骤：
1、添加VIP至其网络接口；
2、广播GARP信息，通知网络内的其它主机目前本Director其占有VIP；
3、创建IPVS表以实现入站请求连接的负载均衡；
4、Stonith；
我们可以用脚本来实现HA，下面是实验环境：主转发器有两块网卡eth0和eth1，eth-0的IP为192.168.0.131，eth1的IP为192.168.10.20，被转发器也有两块网卡eth0和eth1，eth0的IP为192.168.0.132，eth1的IP为192.168.10.30，我把把eth0的网卡都设为桥接，eth1处于虚拟通道VMnet3下。有两台realserverIP分别为192。168.0.133和192.168.0.134，VIP为192.168.0.138，两台realserver上都提供web服务。
试验步骤：
首先配置主转发器
首先设置其主机名（node1.example.com），
# vim /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=node1.example.com
编辑/etc/hosts在里面输下面的内容
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
192.168.0.131 node1.example.com node1
192.168.0.133 node1.example.com node1
192.168.0.134 node2.example.com node2
192.168.0.132 node2.example.com node2
为了让主机名立即生效，我们可以执行下民的命令
#hostname node1.example.com
2 - 对查询目标使用最适当的本地地址.在此模式下将忽略这个IP数据包的源地址并尝试选择与能与该地址通信的本地地址.首要是选择所有的网络接口的子网中外出 访问子网中包含该目标IP地址的本地地址. 如果没有合适的地址被发现,将选择当前的发送网络接口或其他的有可能接受到该ARP回应的网络接口来进行发送；
当内网的机器要发送一个到外部的ip包，那么它就会请求路由器的Mac地址，发送一个arp请求，这个arp请求里面包括了自己的ip地址和Mac地址，而linux默认是使用ip的源ip地址作为arp里面的源ip地址，而不是使用发送设备上面的，如果设置 arp_announce 为2，则使用发送设备上的ip。
arp_ignore : INTEGER 定义对目标地址为本地IP的ARP询问不同的应答模式，相关代码在arp_announce 函数中 默认为0
0 - (默认值): 回应任何网络接口上对任何本地IP地址的arp查询请求（比如eth0=192.168.0.1/24,eth1=10.1.1.1/24,那么即使 eth0收到来自10.1.1.2这样地址发起的对10.1.1.1 的arp查询也会回应--而原本这个请求该是出现在eth1上，也该由eth1回应的）
1 - 只回答目标IP地址是来访网络接口本地地址的ARP查询请求（比如eth0=192.168.0.1/24,eth1=10.1.1.1/24,那么即使 eth0收到来自10.1.1.2这样地址发起的对192.168.0.1的查询会回答，而对10.1.1.1 的arp查询不会回应）
2 -只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内（比如 eth0=192.168.0.1/24,eth1=10.1.1.1/24,eth1收到来自10.1.1.2这样地址发起的对192.168.0.1 的查询不会回答，而对192.168.0.2发起的对192.168.0.1的arp查询会回应）
3 - 不回应该网络界面的arp请求，而只对设置的唯一和连接地址做出回应(do not reply for local addresses configured with scope host,only resolutions for global and link addresses are replied )
4-7 - 保留未使用
8 -不回应所有（本地地址）的arp查询
如果我们想在cluster上隐藏VIP的方式如下：
echo 1 > /proc/sys/net/ipv4/cconf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/cconf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/cconf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/cconf/lall/arp_announce
这样我们就将VIP附加在了lo上。
LVS persistence可以保证使来自同一个源地址定义到同一台服务器
不管你选择的转发的方式，如果需要确保来自于一个IP的所有连接都发往同一个cluster，这时就需要LVS persistence。Director使用连接追踪记录用来确保同一个Ip的client都到达同一个cluster，当有新的连接请求时director将会查看自己的模板记录看那一台cluster已经和client建立过连接。
Persistence connection Template 持久连接模板，保证所有来自于同一个地址的请求，都定向到同一个服务器
下面我们说一下ipvsadm
ipvsadm是运行于用户空间、用来与ipvs交互的命令行工具，它的作用表现在：
1、定义在Director上进行dispatching的服务(service)，以及哪此服务器(server)用来提供此服务；
2、为每台同时提供某一种服务的服务器定义其权重（即概据服务器性能确定的其承担负载的能力）；
注：权重用整数来表示，有时候也可以将其设置为atomic_t；其有效表示值范围为24bit整数空间，即（2^24-1）；
因此，ipvsadm命令的主要作用表现在以下方面：
1、添加服务（通过设定其权重>0）；
2、关闭服务（通过设定其权重>0）；此应用场景中，已经连接的用户将可以继续使用此服务，直到其退出或超时；新的连接请求将被拒绝；
3、保存ipvs设置，通过使用“ipvsadm-sav > ipvsadm.sav”命令实现；
4、恢复ipvs设置，通过使用“ipvsadm-sav < ipvsadm.sav”命令实现；
5、显示ip_vs的版本号，下面的命令显示ipvs的hash表的大小为4k；
# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
6、显示ipvsadm的版本号
# ipvsadm --version
ipvsadm v1.24 2003/06/07 (compiled with popt and IPVS v1.2.0)
二、ipvsadm使用中应注意的问题
默认情况下，ipvsadm在输出主机信息时使用其主机名而非IP地址，因此，Director需要使用名称解析服务。如果没有设置名称解析服务、服务不可用或设置错误，ipvsadm将会一直等到名称解析超时后才返回。当然，ipvsadm需要解析的名称仅限于RealServer，考虑到DNS提供名称解析服务效率不高的情况，建议将所有RealServer的名称解析通过/etc/hosts文件来实现；
持久连接的类型：
PCC 持久客户端连接 所有服务都定义到一个服务器 服务指定端口为0
例如：如果你想让一个基于http和https连接都到达同一个网站，那么你就要在director上做下列的设置：
ipvsadm -A -t 192.168.0.138:0 -s rr �Cp
ipvsadm -a -t 192.168.0.138:0 -r 192.168.0.132:0 �Cm
ipvsadm -a -t 192.168.0.138:0 -r 192.168.0.131:0 -m
PPC 端口持续连接 只能保证一个连接
PNMP 如果LVS放置于多防火墙的网络中，并且每个防火墙都用到了状态追踪的机制，那么在回应一个针对于LVS的连接请求时必须经过此请求连接进来时的防火墙，否则，这个响应的数据包将会被丢弃。
例如我们希望创建一个一个小时的基于80和443端口持续连接，我们可以做一下设置：
Iptables �Ct mangle �CA PREROUTING �Cd VIP �Cp tcp �Cdport 80 �Cj MARK --set-mark 1
Iptables �Ct mangle �CA PREROUTING �Cd VIP �Cp tcp �Cdport 443 �Cj MARK --set-mark 1
ipvsadm -A -f 1 -s rr -p 3600
ipvsadm -a -f 1 -r realserver1 -m
ipvsadm -a -f 1 -r realserver2 -m
关于IPVS的一些简单设置，这里就不再演示了，因为下面我们会多次用到，在那时再详细的说。
Heartbear
为了提供一个高可用性集群，我们常常需要两台甚至多台转发器，当一台director不再工作时，另外一台转发器就能立即接管direcctor的所有资源，而提供director所提供的所有服务，这样才不至于让客户访问不到资源。为了让备转发器能够在第一时间知道director的工作状态，我们需要时时探测director的工作状态、。这种机制我们称之为“心跳”heartbeat。运行于备用主机上的Heartbeat可以通过以太网连接检测主服务器的运行状态，一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。通常情况下，主、备服务器间的心跳连接是一个独立的物理连接，这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。
Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态，而其只要能通过其中一个连接收到主服务器处于活动状态的信息，就会认为主服务器处于正常状态。
从实践经验的角度来说，建议为Heartbeat配置多条独立的物理连接，以避免Heartbeat通信线路本身存在单点故障。
1、串行电缆：被认为是比以太网连接安全性稍好些的连接方式，因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序，从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度，因此主、备服务器的距离必须非常短。
2、以太网连接：使用此方式可以消除串行线缆的在长度方面限制，并且可以通过此连接在主备服务器间同步文件系统，从而减少了从正常通信连接带宽的占用。
基于冗余的角度考虑，应该在主、备服务器使用两个物理连接传输heartbeat的控制信息；这样可以避免在一个网络或线缆故障时导致两个节点同时认为自已是唯一处于活动状态的服务器从而出现争用资源的情况，这种争用资源的场景即是所谓的“脑裂”（split-brain）或“partitioned cluster”。在两个节点共享同一个物理设备资源的情况下，脑裂会产生相当可怕的后果。
为了避免出现脑裂，可采用下面的预防措施：
1、如前所述，在主、备节点间建立一个冗余的、可靠的物理连接来同时传送控制信息；
2、一旦发生脑裂时，借助额外设备强制性地关闭其中一个节点；
第二种方式即是俗称的“将其它节点‘爆头’（shoot the other node in the head）”，简称为STONITH。基于能够通过软件指令关闭某节点特殊的硬件设备，
Heartbeat即可实现可配置的Stonith。但当主、备服务器是基于WAN进行通信时，则很难避免“脑裂”情景的出现。因此，当构建异地“容灾”的应用时，应尽量避免主、备节点共享物理资源。
Heartbeat的控制信息：
“心跳”信息: （也称为状态信息）仅150 bytes大小的广播、组播或多播数据包。可为以每个节点配置其向其它节点通报“心跳”信息的频率，
以及其它节点上的heartbeat进程为了确认主节点出节点出现了运行等错误之前的等待时间。
集群变动事务（transition）信息：ip-request和ip-request-rest是相对较常见的两种集群变动信息，它们在节点间需要进行资源迁移时为不同节点上heartbeat进程间会话传递信息。比如，当修复了主节点并且使其重新“上线”后，主节点会使用ip-request要求备用节点释放其此前从因主节点故障而从主节点那里接管的资源。此时，备用节点则关闭服务并使用ip-request-resp通知主节点其已经不再占用此前接管的资源。主接点收到ip-request-resp后就会重新启动服务。
重传请求：在某集群节点发现其从其它节点接收到的heartbeat控制信息“失序”（heartbeat进程使用序列号来确保数据包在传输过程中没有被丢弃或出现错误）时，会要求对方重新传送此控制信息。 Heartbeat一般每一秒发送一次重传请求，以避免洪泛。
上面三种控制信息均基于UDP协议进行传送，可以在/etc/ha.d/ha.cf中指定其使用的UDP端口或者多播地址（使用以太网连接的情况下）。
此外，除了使用“序列号/确认”机制来确保控制信息的可靠传输外，Heartbeat还会使用MD5或SHA1为每个数据包进行签名以确保传输中的控制信息的安全性。
为了实验的方便我们需要安装下列软件包
libnet-1.1.4-3.el5.i386.rpm perl-MailTools-1.77-1.el5.noarch.rpm
heartbeat-pils-2.1.4-10.el5.i386.rpm heartbeat-stonith-2.1.4-10.el5.i386.rpm
heartbeat-gui-2.1.4-10.el5.i386.rpm heartbeat-ldirectord-2.1.4-10.el5.i386.rpm
heartbeat-devel-2.1.4-10.el5.i386.rpm heartbeat-2.1.4-10.el5.i386.rpm
perl-Compress-Zlib perl-HTML-Parser
perl-HTML-Tagset perl-URI perl-libwww-perl
perl-MailTools perl-TimeDate perl-String-CRC32 net-snmp-libs
由于包之间有较强的依赖性，我们建议用yum进行安装，这样就省去了很多不必要的麻烦，
Heartbeat的主配置文件是/etc/ha.d/ha.cf,/etc/ha.d/haresources和/etc/authkeys。当我们安装好上面的包时，在/etc/ha.d/目录中没有我们的主配置文件，这时我们可以去/usr/share/doc/heartbeat-2.1.4/目录中拷贝。
/etc/ha.d/ha.cf定义位于不同节点上的heartbeat进程间如何进行通信；
logfile /var/log/ha-log定义日志信息
keepalive N 定义多长时间备设备向主设备探测一次心跳信息，单位为秒
deadtime 30 定义探测不到director心跳后经过多长时间采取措施
udpport 694 定义监听的端口
bcast eth1 定义通过那个网卡监听director的心跳信息
auto_failback on 当主转发器从down机中恢复过来后，是否继续充当director
node node1.example.com 主转发器的主机名
node node2.example.com 备转发器的主机名
/etc/ha.d/haresources
定义对某个资源来说哪个服务器是主节点，以及哪个节点应该拥有客户端访问资源时的目标IP地址。
haresources配置文件介绍：
主从节点上的/etc/ra.d/raresource文件必须完全相同。文件每行通常包含以下组成部分：
1、服务器名字：指正常情况下资源运行的那个节点（即主节点），后跟一个空格或tab；这里指定的名字必须跟某个节点上的命令"uname -n"的返回值相同；
2、IP别名（即额外的IP地址，可选）：在启动资源之前添加至系统的附加IP地址，后跟空格或tab；IP地址后面通常会跟一个子网掩码和广播地址，彼此间用“/”隔开；
3、资源脚本：即用来启动或停止资源的脚本，位于/etc/init.d/或/etc/ha.d/resourcd.d目录中；如果需要传递参数给资源脚本，脚本和参数之间需要用两个冒号分隔，多个参数时彼此间也需要用两个冒号分隔；如果有多个资源脚本，彼此间也需要使用空格隔开；
格式如下：
primary-server [IPaddress[/mask/interface/broadcast]] resource1[::arg1::arg2] resource2[::arg1::arg2]
例如：
primary-server 221.67.132.195 sendmail httpd
/etc/ha.d/authkeys
定义Heartbeat包在通信过程中如何进行加密。
当ha.cf或authkeys文件发生改变时，需要重新加载它们就可以使用之生效；
而如果haresource文件发生了改变，则只能重启heartbeat服务方可使之生效。
HA（高可用性集群）的LVS集群有两台Director，在启动时，主节点占有集群负载均衡资源（VIP和LVS的转发及高度规则），
备用节点监听主节点的“心跳”信息并在主节点出现异常时进行“故障转移”而取得资源使用权，这包括如下步骤：
1、添加VIP至其网络接口；
2、广播GARP信息，通知网络内的其它主机目前本Director其占有VIP；
3、创建IPVS表以实现入站请求连接的负载均衡；
4、Stonith；
我们可以用脚本来实现HA，下面是实验环境：主转发器有两块网卡eth0和eth1，eth-0的IP为192.168.0.131，eth1的IP为192.168.10.20，被转发器也有两块网卡eth0和eth1，eth0的IP为192.168.0.132，eth1的IP为192.168.10.30，我把把eth0的网卡都设为桥接，eth1处于虚拟通道VMnet3下。有两台realserverIP分别为192。168.0.133和192.168.0.134，VIP为192.168.0.138，两台realserver上都提供web服务。
试验步骤：
首先配置主转发器
首先设置其主机名（node1.example.com），
# vim /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=node1.example.com
编辑/etc/hosts在里面输下面的内容
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
192.168.0.131 node1.example.com node1
192.168.0.133 node1.example.com node1
192.168.0.134 node2.example.com node2
192.168.0.132 node2.example.com node2
为了让主机名立即生效，我们可以执行下民的命令
#hostname node1.example.com
2,编辑我们的主配置文件/etc/ha.d/ha.cf在里面进行修改，应包含下面的内容
logfile /var/log/ha-log定义日志信息
keepalive N #定义多长时间备设备向主设备探测一次心跳信息，单位为秒
deadtime 30 #定义探测不到director心跳后经过多长时间采取措施
udpport 694 #定义监听的端口
bcast eth1 #定义通过那个网卡监听director的心跳信息
auto_failback on #当主转发器从down机中恢复过来后，是否继续充当director
node node1.example.com #主转发器的主机名
node node2.example.com #备转发器的主机名
值得注意的是上面的主机名的顺序一定不能弄反了
3，编辑/etc/ha.d/aurhkeys我们可以执行下面的命令
#echo -ne "auth1\n1 sha1" >> authkeys
# dd if=/dev/urandom bs=512 count=1 | openssl md5 >> authkeys
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000372942 seconds, 1.4 MB/s
我们可以看到里面新增了两行
#vim /etc/ha.d/authkeys
auth1
1 sha1 9e43d13a84f2b9ea486516d709e748b5
这样我们就调用auth1的方式对heartbeat之间的数据包进行了加密
4,我们创建下面的脚本编辑一个脚本大致内容如下，
logfile /var/log/ha-log定义日志信息
keepalive N #定义多长时间备设备向主设备探测一次心跳信息，单位为秒
deadtime 30 #定义探测不到director心跳后经过多长时间采取措施
udpport 694 #定义监听的端口
bcast eth1 #定义通过那个网卡监听director的心跳信息
auto_failback on #当主转发器从down机中恢复过来后，是否继续充当director
node node1.example.com #主转发器的主机名
node node2.example.com #备转发器的主机名
值得注意的是上面的主机名的顺序一定不能弄反了
3，编辑/etc/ha.d/aurhkeys我们可以执行下面的命令
#echo -ne "auth1\n1 sha1" >> authkeys
# dd if=/dev/urandom bs=512 count=1 | openssl md5 >> authkeys
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000372942 seconds, 1.4 MB/s
我们可以看到里面新增了两行
#vim /etc/ha.d/authkeys
auth1
1 sha1 9e43d13a84f2b9ea486516d709e748b5
这样我们就调用auth1的方式对heartbeat之间的数据包进行了加密
4,我们创建下面的脚本编辑一个脚本大致内容如下，
#vim /etc/ha.d/resource.d/lvsd
修改此脚本的权限
#chmod 755 /etc/ha.d/resource.d/lvsd
5,编辑/etc/ha.d/haresources在里面增加下面的内容
node1.example.com lvsd
6，在我们的备转发器上做同样的设置（嘿嘿，别忘了更改主机名啊）
7，在我们的两台realserver上编辑下面的脚本，当然脚本的名字可以任意
#vim realserver.d
![]()
修改此脚本的权限
#chmod 755 /etc/ha.d/resource.d/lvsd
5,编辑/etc/ha.d/haresources在里面增加下面的内容
node1.example.com lvsd
6，在我们的备转发器上做同样的设置（嘿嘿，别忘了更改主机名啊）
7，在我们的两台realserver上编辑下面的脚本，当然脚本的名字可以任意
#vim realserver.d
为了演示的方便我们在realserver2上编辑一个要显示的主页，
#vim /var/www/html/index.html
<h2>this is realserver2</h2>
在realserver1上编辑一个要显示的主页，
#vim /var/www/html/index.html
<h2>this is realserver1</h2>
在director上编辑主页
#vim /var/www/html/index.html
<h2>sorry the page you wanted can't connect</h2>
在两台转发器上和realserver上执行脚本，我们就实现了高性能高可用性的目标
大家或许会说这样做很麻烦，因为每次都要亲自执行脚本，再说，director也不能监视realserver的工作状态，也就是说当realserver不再工作时，director也会将请求分配给他，这时就会造成客户端访问不到自己想要的内容，所以我们需要一种机制让dorector对进行realserver进行监控。在我们安装上面的软件包时，安装了heartbeat-ldirectord-2.1.4-10.el5.i386.rpm，ldirectord用来实现LVS负载均衡资源的在主、备节点间的故障转移。在首次启动时，ldirectord可以自动创建IPVS表。此外，它还可以监控各Realserver的运行状态，一旦发现某Realserver运行异常时，还可以将其从IPVS表中移除。ldirectord进程通过向Realserver的RIP发送资源访问请求并通过由Realserver返回的响应信息来确定Realserver的运行状态。
在Director上，每一个VIP需要一个单独的ldirector进程。如果Realserver不能正常响应Directord上ldirectord的请求，ldirectord进程将通过ipvsadm命令将此Realserver从IPVS表中移除。而一旦Realserver再次上线，ldirectord会使用正确的ipvsadm命令将其信息重新添加至IPVS表中。为了监控一组提供web服务的Realserver，ldirectord进程使用HTTP协议请求访问每台Realserver上的某个特定网页。ldirectord进程根据自己的配置文件中事先定义了的Realserver的正常响应结果来判断当前的返回结果是否正常。我们可以在每一台realserver上编辑一个网页.index.html文件，里面写入GOOD，directord进程每隔一段时间就访问一次此网页，并根据获取到的响应信息来判断Realserver的运行状态是否正常。
如果其返回的信息不是"GOOD"，则表明服务不正常。
具体的实现过程如下：
1，我们拷贝/usr/share/doc/heartbeat-ldiractored-2.1.4/ldirectored.cf到/etc/ha.d/目录下，重命名为ldirectord-lvs-httpd.cf
然后编辑文件中的内容
#vim /etc/ha.d/ ldirectord-lvs-httpd.cf
checktimeout=10 #这个值就是ldirectord等待健康检查执行完毕的等待时间，单位秒。如果因为某些原因检查失败或在设置的时间周期内没有完成检查，ldirectord将会从IPVS表中移除真实服务器
checkinterval=3 #指定ldirectord在两个检查之间的间隔时间。
autoreload=yes #是否重新读取配置文件
logfile="/var/log/ldirectord.log" #记录我们的日志信息
quiescent=yes #当某个realserver没有正常显示时，则从ipvs表中删除此realserver
virtual=192.168.0.138:80 #设置VIP地址和端口号
real=192.168.0.133:80 gate 10 #指定要监控的真实服务器和端口
real=192.168.0.134:80 gate 3 #同上
fallback=127.0.0.1:80 gate #如果所有的真实服务器都不能正常工作时，返回director上与设定好的信息
service=http #定义的服务
request=".index.html" #从realserver上读取的文件
receive="GOOD" #realserver正常时返回的信息
scheduler=wlc #指定调度方式
protocol=tcp #指定协议类型
checktype=negotiate #进程用于监控realserver的方法
checkport=80 #检查的端口
2，在/etc/hd.d/haresources中添加类似如下行：
node1.example.com 192.168.0.138/32/eth0/192.168.0.138 ldirectord::ldirectord-lvs-httpd.cf
3,在备转发器上做同样的设置，在两台realserver上执行上面提到的脚本
在两台转发器上和realserver上执行脚本，我们就实现了高性能高可用性的目标
大家或许会说这样做很麻烦，因为每次都要亲自执行脚本，再说，director也不能监视realserver的工作状态，也就是说当realserver不再工作时，director也会将请求分配给他，这时就会造成客户端访问不到自己想要的内容，所以我们需要一种机制让dorector对进行realserver进行监控。在我们安装上面的软件包时，安装了heartbeat-ldirectord-2.1.4-10.el5.i386.rpm，ldirectord用来实现LVS负载均衡资源的在主、备节点间的故障转移。在首次启动时，ldirectord可以自动创建IPVS表。此外，它还可以监控各Realserver的运行状态，一旦发现某Realserver运行异常时，还可以将其从IPVS表中移除。ldirectord进程通过向Realserver的RIP发送资源访问请求并通过由Realserver返回的响应信息来确定Realserver的运行状态。
在Director上，每一个VIP需要一个单独的ldirector进程。如果Realserver不能正常响应Directord上ldirectord的请求，ldirectord进程将通过ipvsadm命令将此Realserver从IPVS表中移除。而一旦Realserver再次上线，ldirectord会使用正确的ipvsadm命令将其信息重新添加至IPVS表中。为了监控一组提供web服务的Realserver，ldirectord进程使用HTTP协议请求访问每台Realserver上的某个特定网页。ldirectord进程根据自己的配置文件中事先定义了的Realserver的正常响应结果来判断当前的返回结果是否正常。我们可以在每一台realserver上编辑一个网页.index.html文件，里面写入GOOD，directord进程每隔一段时间就访问一次此网页，并根据获取到的响应信息来判断Realserver的运行状态是否正常。
如果其返回的信息不是"GOOD"，则表明服务不正常。
具体的实现过程如下：
1，我们拷贝/usr/share/doc/heartbeat-ldiractored-2.1.4/ldirectored.cf到/etc/ha.d/目录下，重命名为ldirectord-lvs-httpd.cf
然后编辑文件中的内容
#vim /etc/ha.d/ ldirectord-lvs-httpd.cf
checktimeout=10 #这个值就是ldirectord等待健康检查执行完毕的等待时间，单位秒。如果因为某些原因检查失败或在设置的时间周期内没有完成检查，ldirectord将会从IPVS表中移除真实服务器
checkinterval=3 #指定ldirectord在两个检查之间的间隔时间。
autoreload=yes #是否重新读取配置文件
logfile="/var/log/ldirectord.log" #记录我们的日志信息
quiescent=yes #当某个realserver没有正常显示时，则从ipvs表中删除此realserver
virtual=192.168.0.138:80 #设置VIP地址和端口号
real=192.168.0.133:80 gate 10 #指定要监控的真实服务器和端口
real=192.168.0.134:80 gate 3 #同上
fallback=127.0.0.1:80 gate #如果所有的真实服务器都不能正常工作时，返回director上与设定好的信息
service=http #定义的服务
request=".index.html" #从realserver上读取的文件
receive="GOOD" #realserver正常时返回的信息
scheduler=wlc #指定调度方式
protocol=tcp #指定协议类型
checktype=negotiate #进程用于监控realserver的方法
checkport=80 #检查的端口
2，在/etc/hd.d/haresources中添加类似如下行：
node1.example.com 192.168.0.138/32/eth0/192.168.0.138 ldirectord::ldirectord-lvs-httpd.cf
3,在备转发器上做同样的设置，在两台realserver上执行上面提到的脚本
4，启动heartbeat
#service heartbeat restart
我们查看一下ipvsadm的设置
![]()
#service heartbeat restart
我们查看一下ipvsadm的设置
可以看到我们刚才指定的realserver和服务的端口号，以及我们定义的“VIP“，我们看到realserver的权重就是刚才我们设定的权重，说明它们工作正常。
我们也可以看到下面的内容
这说明我们的”VIP”被自动加载到了eth0上，现在我们来查看备director的ipvsadm信息，可以发现没有定义ipvsadm信息，如果我们在nide1上执行下面的命令/usr/lib/heartbeat/./hb_standby 也就是让node1处于standby状态，此时再查看node2的ipvsadm信息，我们可以看到下面的内容
我们发现realserver2的权重变为0了，由上面的知识可以知道，我们的director已经探测到了realserver2已经不能正常工作了，我们把realserver1的夫妇也关闭掉，会看到下面的内容
我们可以看到我们的realserver1的权重也变为0了，这说明我们的director也探测到了realserver1也不能正常工作了，这时我们在访问一下，将看到下面的内容
这说明我们的director在检测到所有的realserver都不能呢个正常工做的时候，回复给客户端一个错误的信息，这样我们就实现了一个真正的高性能高可用性的集群了
注：由于时间仓促，整理的不免有些混乱，若有错误或者不明白之处，希望能指出，我们共同交流。