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. 可视化工具Grafana:简介及安装

    随着业务的越发复杂,对软件系统的要求越来越高,这意味着我们需要随时掌控系统的运行情况.因此,对系统的实时监控以及可视化展示,就成了基础架构的必须能力. 这篇博客,介绍下开源的可视化套件grafana的 ...

  2. 调用Runtime.getruntime 下的exec方法时,有",<,|时该怎么办?

    今天写一个用到编译的程序,遇到了问题. 在调用runtime.exec("javac HelloWorld.java");运行完美,也就是有生成.class. 而到了runtime ...

  3. Linux命令1

     1.获取当前系统支持的所有命令的列表: compgen ­-c  2.怎样查看一个linux命令的概要与用法: whatis grep #便可查到grep的用法 3.怎样一页一页地查看一个大文件的内 ...

  4. Delphi Create(nil), Create(self), Create(Application)的区别

    最近的项目中经常在程序中动态创建控件,势必用到Create. 但是随之而来的问题就是动态创建的控件是否可以正确的释放内存? 以及 Create(nil), Create(self), Create(A ...

  5. 【NLP】Conditional Language Modeling with Attention

    Review: Conditional LMs Note that, in the Encoder part, we reverse the input to the ‘RNN’ and it per ...

  6. Android 入门(1)使用第三方控件

    最近公司需要,准备开发扫描枪. 话不多说,直接开始 创建新项目 1 如果遇到 Error:Execution failed for task ':app:preDebugAndroidTestBuil ...

  7. JSON.stringify() 和 JSON.parse()

    stringify()用于从一个对象解析出字符串,如 var obj = {x: 1, y: 2 } console.log(JSON.stringify(obj)) //{"x" ...

  8. python之路day01--变量

    一.变量 变量就是将一些运算的中间结果暂存到内存中,以便后续代码块调用. 规范: 1.必须由数字.字母.下划线任意组合,且不能数字开头. 2.不能是python中的关键字.如:‘print’ 'and ...

  9. Mock7 moco框架重定向

    新建一个startupWithRedirect.json [ { "description": "重定向到百度", "request": { ...

  10. 自动化运维工具Ansible介绍

    一个由 Python 编写的强大的配置管理解决方案.尽管市面上已经有很多可供选择的配置管理解决方案,但他们各有优劣,而 ansible 的特点就在于它的简洁. 让 ansible 在主流的配置管理系统 ...