使用ldirectord实现后端RS健康状态监测及LVS调度功能

Ldirectord功能描述：

如果在高可用服务中直接将ipvsadm定义为一种资源代理，使用ipvsadm来生成ipvs规则，这样生效的lvs不能实现对后端的RealServer实现健康监测的功能，而heartbeat中的ldirectord可以实现对后端RealServer健康状态监测的功能，同时能使用内核中的ipvs功能利用ipvsadm规则启动lvs服务，实现对后端RealServer的调度功能，即有请求至前端的Director时，可以将请求转发至各RealServer而定义的ipvsadm规则保存在配置文件中，服务无需启动，由ldirectord这个资源代理来实现启动ipvs服务。同时前端的Director上配置有VIP地址，这个地址作为高可用的资源实现在前端的各Director上实现流转。

实验用主机：

Director1:172.16.103.1

Director2:172.16.103.2

RealServer1:172.16.103.3

RealServer2:172.16.103.4

操作步骤：

一、前端的两台主机安装heartbeat，同时要同步时间，两个Director之间通信基于/etc/hosts文件实现主机名称解析，而且要实现基于ssh公钥通信。这些配置请参考前面的博客。

二、在两台Director上安装ldirectord:

# yum install heartbeat-ldirectord-2.1.4-12.el6.x86_64.rpm

安装完成后的ldirectord生成的文件中有一个文件放在了heartbeat的ha.d/resource.d目录下，是一个资源代理文件。同时还提供了一个样例配置文件，这些文件是我们用来实现高可用ipvs规则和定义后端RealServer的配置接口文件。

# rpm -ql heartbeat-ldirectord
/etc/ha.d/resource.d/ldirectord
/etc/init.d/ldirectord
/etc/logrotate.d/ldirectord
/usr/sbin/ldirectord
/usr/share/doc/heartbeat-ldirectord-2.1.4
/usr/share/doc/heartbeat-ldirectord-2.1.4/COPYING
/usr/share/doc/heartbeat-ldirectord-2.1.4/README
/usr/share/doc/heartbeat-ldirectord-2.1.4/ldirectord.cf
/usr/share/man/man8/ldirectord.8.gz

复制ldirector的配置文件到/etc/目录下

# cp /usr/share/doc/heartbeat-ldirectord-2.1.4/ldirectord.cf /etc/ha.d

编辑ldirectord的配置文件，定义其中需要用到的后端RealServer的IP地址以及使用的哪种模型下的lvs，其中gate为dr模型，另外后端的RealServer都出现故障的情况下在这里还定义了fallback server用于显示提示信息，提示当前服务不可用，达到提醒用户的目的，而后面的request等条目是用于检测后端的RealServer的健康状况使用的，同时需要在各个RealServer的站点根目录下提供这个文件，内容设置有OK字样，便于前端的ldirectord服务检测到后端RealServer是否在线。

# cd /etc/ha.d
# vim ldirectord.cf
# Sample for an http virtual service
virtual=172.16.103.50:80
        real=172.16.103.3:80 gate
        real=172.16.103.4:80 gate
        fallback=127.0.0.1:80 gate
        service=http
        request="index.html"
        receive="OK"
        virtualhost=some.domain.com.au
        scheduler=rr

另外需要先使用ipvsadm命令配置好ipvs规则，然后保存在ipvs默认的配置文件中，以便ldirectord调用。

# ipvsadm -A -t 172.16.103.50:80 -s rr   #设定VIP的地址为172.16.103.50
# ipvsadm -a -t 172.16.103.50:80 -r 172.16.103.3 -g 
# ipvsadm -a -t 172.16.103.50:80 -r 172.16.103.4 -g
# service ipvsadm save
# service ipvsadm stop

在该高可用节点上测试启动ldirectord，查看ipvs规则是否生效：

# service ldirectord start
[[email protected] ha.d]# service ldirectord start
Starting ldirectord... success
[[email protected] ha.d]# ipvsadm -L -n 
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.16.103.50:80 rr
  -> 172.16.103.3:80              Route   1      0          0    
  -> 172.16.103.4:80              Route   1      0          0

规则生效以后可以尝试关闭后端RealServer的httpd服务，查看前端ldirectord的fallback server是否能正常上线

关闭RealServer的服务：

# service httpd stop

在director上测试一下查看ipvs规则：

[[email protected] ha.d]# ipvsadm -L -n 
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.16.103.50:80 rr
  -> 127.0.0.1:80                 Local   1      0          0         
  -> 172.16.103.3:80              Route   0      0          0    
  -> 172.16.103.4:80              Route   0      0          0

规则文件及资源代理配置好以后，将这两个文件复制到另外一个高可用服务的节点上。

# scp /etc/ha.d/ldirectord.cf node2:/etc/ha.d
# scp /etc/sysconfig/ipvsadm node2:/etc/sysconfig

复制完成后在另一个节点上使用相同的方式测试一下ldirectord服务是否可以正常使用。

三、配置heartbeat的haresource文件，定义高可用集群的各资源及使用的代理，运行的节点等信息：

node2.cluster.com 172.16.103.20/16/eth0/172.16.103.255 ldirectord::/etc/ha.d/ldirectord.cf

在两个节点上启动Heartbeat服务：

# service heartbeat start
# ssh node2 ‘service heartbeat start‘

DR模型下的各RealServer的具体配置未给出。请参考前面的DR模型的博客内容。

在浏览器内输入定义的VIP地址，访问172.16.103.50，显示效果如下：

在启动服务的高可用节点上可以查看到启动的资源结果如下：

[[email protected] ha.d]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0C:29:E1:37:51  
          inet addr:172.16.103.2  Bcast:172.16.255.255  Mask:255.255.0.0
          inet6 addr: fe80::20c:29ff:fee1:3751/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:184223 errors:0 dropped:0 overruns:0 frame:0
          TX packets:125070 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:110659582 (105.5 MiB)  TX bytes:21467745 (20.4 MiB)
eth0:0    Link encap:Ethernet  HWaddr 00:0C:29:E1:37:51  
          inet addr:172.16.103.50  Bcast:172.16.103.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
[[email protected] ha.d]# ipvsadm -L -n 
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.16.103.50:80 rr
  -> 172.16.103.3:80              Route   1      0          0   
  -> 172.16.103.4:80              Route   1      0          0

如果同时间后端的RealServer都出现问题，那么在ipvs规则中可以看到fallback server处于工作状态

[[email protected] ha.d]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  172.16.103.50:80 rr
  -> 127.0.0.1:80                 Local   1      0          0         
  -> 172.16.103.3:80              Route   0      0          1       
  -> 172.16.103.4:80              Route   0      0          1

这样前端是lvs的高可用集群，后端是httpd的LB负载均衡集群的简单模型配置完成。

时间： 2024-10-26 07:53:09

使用ldirectord实现后端RS健康状态监测及LVS调度功能的相关文章

完成rs健康状态检查。

VS具有很好的伸缩缩性.可靠性和管埋性,通过LVS要实现的最终目标是:利用linux 操作系统和LVS集群软件实现一个高可用.高性能,低成本的服务器应用集群. LVS集群的组成利用LVS架设的服务器群系统由3个部分组成:最前端的是负栽均衡层(这里用 Lo ad Balancer表示),中间是服务器集群层(用Server Array表示).LVS体系结构如下图所示: 下面对LVS的各个组成部分进行详细介绍负 栽均衡层:位于整个集群系统的最前端,由一台或多台负栽调度器(Dircctm Server)

nginx（六）反向代理（proxy）与负载均衡（upstream）以及健康状态监测。

j**ngx_http_proxy_module模块配置(http或https协议)** proxy_pass uri;应用上下文:location,if in location,limit_except location  / {        proxy_set_header Host $http_host;        proxy_pass      #将所有请求都反向代理至本地的http协议的8080端口         index index.html index.htm; } 注:

Lvs FWM及持久连接、健康状态监测

本文介绍关于LVS的健康状态监测及持久连接 lvs的persistence: lvs持久连接 无论使用哪一种调度方法,持久连接功能都能保证在指定时间范围之内,来自于同一个IP的请求将始终被定向至同一个RS: persistence template:持久连接模板 PPC:每端口持久:持久连接生效范围仅为单个集群服务:如果有多个集群服务,每服务被单独持久调度: PCC:每客户端持久:持久连接生效范围为所有服务:定义集群服务时,其TCP或UDP协议的目标端口要使用0: PFWM:持久防火墙标记:每F

LVS自动化添加及删除ipvsadm和后端服务器健康状态检测脚本

  LVS director 负载均衡器增加IPVSADM脚本 #vim director.sh #!/bin/bash #chkconfig: - 88 66 #description: this script to add lvs IP VIP=192.168.0.254 DIP=192.168.0.100 RIP1=192.168.0.101 RIP2=192.168.0.102 PORT=80 SCHELE=wrr LOCKFILE=/var/lock/subsys/ipvsadm ca

利用ldirectord实现lvs后端realserver健康状态检查

ldirectord用来实现LVS负载均衡资源在主.备节点间的故障转移.在首次启动时,ldirectord可以自动创建IPVS表.此外,它还可以监控各RealServer的运行状态,一旦发现某RealServer运行异常时,还可以将其从IPVS表中移除. ldirectord进程通过向RealServer的RIP发送资源访问请求并通过由RealServer返回的响应信息来确定RealServer的运行状态.在Director上,每一个VIP需要一个单独的ldirectord进程.如果RealSe

透过F5，探测后端应用健康状态

起因: 一朋友运维的系统在生产环境中遇到了一些异常,为了排查故障,准备在互联网检测F5后端的50台应用是否正常. (为什么没在内网检测?一开始我也想问,内网检控是有的,但由于环境比较复杂,没有那种从客户端一直到服务器的状态监测.) 环境说明: 前端F5,分发后端50台应用服务器 准备目录:/usr/share/wget/wget_app 准备文件:ap_cookies,放至/usr/share/wget/wget_app 点击链接下载:http://down.51cto.com/data/223

LVS集群RS健康状态检查

生产中,我们需要检测RS状态,当RS服务异常时,应该将RS移出集群,而当RS恢复之后,再将RS加入到集群中.下面是脚本内容 #!/bin/bash VIP=192.168.10.3 ##集群服务端口号 CPORT=80 RS=(192.168.10.7 192.168.10.8) ###RS主机的状态,1表示状态正常 RSTATUS=(1 1) #权重 RW=(2 1) ###RS主机上实际的服务端口 RPORT=80 ###lVS的模式,这里以DR模式为例 TYPE=g ###add函数表示将

如何编写LVS对Real Server的健康状态检测脚本

简介:Linux 虚拟服务器(Linux Virtual Server. LVS),是一个由章文松开发的自由软件.利用KVS可以实现高可用的.可伸缩缩的Web, Mail, Cache和Medial等网络股务..井在此基 础上开发支持庞大用户数的,可伸缩的,高可用的电子商务应用.LVS1998年发展到现在,已经变得比较成熟,目前广泛应用在各种网络服务和电了商务应用 中.LVS具有很好的伸缩缩性.可靠性和管埋性,通过LVS要实现的最终目标是:利用linux 操作系统和LVS集群软件实现一个高可用.

如何利用nginx_upstream_check_module-master对nginx的后端机器进行健康状态检查

用nginx做前端反向代理,如果后端服务器宕掉的话,nginx是不会把这台realserver踢出upstream的,还会把请求转发到后端的这台realserver上面.所以当某台机器出现问题时,我们会看到nginx的日志会有一段转发失败然后转发正常的日志.这次借助与淘宝技术团队开发的nginx模快nginx_upstream_check_module来检测后方realserver的健康状态,如果后端服务器不可用,则会将其踢出upstream,所有的请求不转发到这台服务器.当期恢复正常时,将其加