keepalived具有很强大、灵活的后端检测方式,其具有HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK 几种健康检测方式 ,在分别介绍各种检测方式之前,先纠正一个常见的理论问题 。在百度百科keepalived官方老文档(田逸提交的)中,对keepalived的描述是其具有3、4、7层交换及健康检测功能。不过根据官网对当前版本的介绍和这有些出入 。

网上一些文档的介绍如下:

layer 3层检测:进行ICMP ping包检测,确认主机是否存活,如果异常,则会该主机从服务器集群中剔除;

layer 4层检测:进行端口检测,例如80、3306等,端口不通时,将服务器从集群中剔除;

layer 7层检测:这个就是基于应用的了,如http返回码是否为200,确认主机是否正常。

当然,上面这些对keepalived的描述不能说不对,只能说不准确 。对于当前的最近版本来说,管网上关于checkers 的描述如下:

This is one of the main Keepalived functionnality. Checkers are in charge of realserver healthchecking.A checker test if realserver is alive, this test end on a binary decision :remove or add realserver from/into the LVS topology. The internal checker design is realtime networking software,it use a fully multi-threaded FSM design (Finite State Machine).This checker stack provide LVS topology manipulation accoring to layer4 to layer5/ test results.Its run in an independent process monitored by parent process

上面的描述很清楚,是layer4 to layer5/7 ,并不包含上面所谓的三层交换检测 。不过也并不能说网上这些说法是不准确的,因为三层相较于layer5/7这些,属于低层级的基本功能,基于MISC_CHECK 进行ICMP ping 三层网络检测完全是不存在问题的 。不过仅仅通过ping确认一个服务是否正常,显然也太低端了。---(本人有“洁癖” ,以上为对比官网描述和当下网上资料后的一点心得)

一、HTTP及SSL GET检测

这里有几个要点:

1、两者都有两种检测方式,一种是简单的基于返回码确认;另一种是基于确认后端页面内容hash值,确认前后是否发生变化(是不是感觉有点高端,还有简单的防止页面被篡改的作用,当然,动态页面显然不行);

2、两者都是处理简单的GET请求,基于post返回值确认是否正常,这种方法显然不适用 ,不过POST方式是可以通过MISC_CHECK方式进行支持检测的;

3、两者配置语法上相同,只不过类型名不同而已 。同属于大的web请求范畴,只不过一个走的HTTP协议,一个走的HTTPS协议;

基于状态码的检测

配置如下:

real_server 192.168.2.188  {
weight
HTTP_GET {
url {
path /index.html
status_code #http://192.168.2.188/index.html的返回状态码
}
connect_timeout
nb_get_retry
delay_before_retry
}

基于genhash的检测

配置如下:

real_server 192.168.2.188  {
weight
HTTP_GET {
url {
path /index.html
digest bfaa334fdd71444e45eca3b7a1679a4a #http://192.168.2.188/index.html的digest值
}
connect_timeout
nb_get_retry
delay_before_retry
}

安装完keepalived包,系统中会多出一个命令genhash,通过该命令可以获取页面的hash串,如下是我更改某个页面前后的digest值:

[root@lvs-dr ~]# genhash -s 192.168.122.10 -p  -u /index.html
MD5SUM = 6df8d89daedcbb90e3f0c1d1f82cbcf6
[root@lvs-dr ~]# genhash -s 192.168.122.10 -p -u /index.html
MD5SUM = e6368a07d59e3922d2f428b2acd27090

也可以参考官方给出的文档(包安装后,会有该文件生成)

二、TCP_CHECK 检测

配置如下:

real_server 192.168.2.100  {
weight
TCP_CHECK {
connect_timeout #连接超时时间
nb_get_retry #重连次数
delay_before_retry #重连间隔
connect_port
}
}

这个在安装包附带的文档中也有示例 。而且其还可以配合HTTP_GET和SSL_GET一起用,如下:

real_server 192.168.201.100  {
weight
SSL_GET {
url {
path /
digest ff20ad2481f97b1754ef3e12ecd3a9cc
}
connect_port
connect_timeout
nb_get_retry
delay_before_retry
}
}

以上配置也是安装包中的示例

三、SMTP检测

SMTP这个顾名思义,主要用于邮件系统SMTP协议的检测,具体如下示例:

SMTP_CHECK {
connect_timeout
retry
delay_before_retry
helo_name foo.bar.com
host {
connect_ip 172.16.1.11
}
host {
connect_ip 192.168.155.10
}
}

这里也可以指定连接的端口(默认肯定是25啊),监听的地址 ,更多也可以参看帮助文档

四、MISC_CHECK检测

这个是通过调用外部配置名脚本进行检测确认后端主机是否正常的方法 。

    MISC_CHECK {
misc_path <STRING>|<QUOTED-STRING># 外部程序或者脚本路径
misc_timeout <INT># 执行脚本的超时时间
misc_dynamic #如果设置了misc_dynamic,healthchecker程序的退出状态码会用来动态调整服务器的权重(weight).
#返回0:健康检查OK,权重不被修改
#返回1:健康检查失败,权重设为0
#返回2-:健康检查OK,权重设置为:退出状态码-,比如返回255,那么weight=-=
}

对应的脚本后面是支持传参的,两个示例如下:

    #不传参配置
real_server 192.168.200.6 {
weight
MISC_CHECK {
misc_path /usr/local/bin/script.sh
}
}
#传参配置
real_server 192.168.200.6 {
weight
MISC_CHECK {
misc_path "/usr/local/bin/script.sh arg1 arg2"
}
}

转自

keepalived健康检查方式 - 运维之路 http://www.361way.com/keepalived-health-check/5218.html

keepalived健康检查方式【转】的更多相关文章

  1. keepalived健康检查方式

    keepalived对后端realserver的健康检查方式主要有以下几种: TCP_CHECK:工作在第4层,keepalived向后端服务器发起一个tcp连接请求,如果后端服务器没有响应或超时,那 ...

  2. 9-lvs-lvs集群-及keepalived健康检查

    注意: 配置前需要将上一篇的配置都清除掉 ifconfig eth1: down service ipvsadm restart nginx作为请求分发服务器时, 有健康检查机制, 挂了的服务器不会在 ...

  3. 5.Lvs+Keepalived健康检查

    1. Nginx+keepalived对后端服务器心跳检查(需要自定义脚本) 原理:Keepalived并不跟nginx耦合,它俩完全不是一家人但是keepalived提供一个机制:让用户自定义一个s ...

  4. keepalived健康检查及双主MySQL健康检查脚本

    一.http检查 HTTP_GET:工作在第5层,向指定的URL执行http请求,将得到的结果用md5加密并与指定的md5值比较看是否匹配,不匹配则从服务器池中移除:此外还可以指定http返回码来判断 ...

  5. keepalived的常见的健康检查方式

    TCP_CHECK tcp端口检测 HTTP_GET http接口检测 MISC_CHECK 自定义脚本检测 tcp端口检测 TCP_CHECK { connect_port 80 connect_t ...

  6. keepalive的工作原理和如何做到健康检查

    keepalived是以VRRP协议为实现基础的,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议. 虚拟路由冗余协议,可以认为是实现路由器高可用的 ...

  7. 《浅谈F5健康检查常用的几种方式》—那些你应该知道的知识(二)

    版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明.本文链接:https://blog.csdn.net/sinat_17736151/articl ...

  8. LVS节点健康检查及管理脚本

    在LVS负载均衡主节点上,模拟keepalived健康检查功能管理LVS节点,当节点挂掉从服务器池中剔除,好了再加到服务器池中来. 工具:yum install -y ipvsadm web03:10 ...

  9. 针对后台TCP服务F5健康检查配置

    1.TCP-HALF-OPEN方式 TCP-HALF-OPEN的探测方式,实际是F5每隔一个固定的时间,发送一个SYN包给资源池pool中的一个member,等待服务器返回SYN_ACK,在收到SYN ...

随机推荐

  1. sigsuspend()阻塞:异步信号SIGIO为什么会被截胡?

    关键词:fcntl.fasync.signal.sigsuspend.pthread_sigmask.trace events. 此文主要是解决问题过程中的记录,内容有较多冗余.但也反映解决问题中用到 ...

  2. vs2017创建.net core 应用程序,发布到Linux

    1.打开vs2017,创建.net core 应用程序 压缩上传到linux

  3. 【转】详解springboot-修改内置tomcat版本

    1.解析Spring Boot父级依赖 <parent> <groupId>org.springframework.boot</groupId> <artif ...

  4. Fatal error: Call to undefined function json_decode()解决办法

    最近搭建测试服务器,访问网站查看报错日志出现如下错误: Fatal error: Call to undefined function json_decode() 出现该问题原因是安装PHP时没有安装 ...

  5. @deprecated 的方法处理

    因为需要用到poi,偷懒不太想看官方文档,同时自己的github账号忘记密码了.所以直接在别人博客那拷贝一段代码来模仿修改创建HSSF的xsl文件. 虽然能运行,但发现代码太多横线,可以知道方法被标注 ...

  6. 常见的页面中两个div自适应等高CSS控制

    第一种利用dispaly:table,父级div设置dispaly:table子级div设置display: table-cell; 第一种利用dispaly:flex,父级div设置dispaly: ...

  7. ABP中的拦截器之ValidationInterceptor(上)

    从今天这一节起就要深入到ABP中的每一个重要的知识点来一步步进行分析,在进行介绍ABP中的拦截器之前我们先要有个概念,到底什么是拦截器,在介绍这些之前,我们必须要了解AOP编程思想,这个一般翻译是面向 ...

  8. Docker Online - Web Lab

    直接使用浏览器来用Docker http://play-with-docker.cn/

  9. sgu438-The_Glorious_Karlutka_River

    Description SGU似乎死了... 题目搬到了Codeforces... Problem - 99999438 - Codeforces Solution 动态最大流. 考虑如果不求时间, ...

  10. openstack oslo.messaging库

    openstack oslo.messaging库 2017年04月13日 22:13:25 li_101357 阅读数:1383   版权声明:本文为博主原创文章,未经博主允许不得转载. https ...