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. 在C#/.NET应用程序开发中创建一个基于Topshelf的应用程序守护进程(服务)

    本文首发于:码友网--一个专注.NET/.NET Core开发的编程爱好者社区. 文章目录 C#/.NET基于Topshelf创建Windows服务的系列文章目录: C#/.NET基于Topshelf ...

  2. 3-STM32物联网开发WIFI(ESP8266)+GPRS(Air202)系统方案安全篇(购买域名,域名绑定IP)

    2-STM32物联网开发WIFI(ESP8266)+GPRS(Air202)系统方案安全篇(监听Wi-Fi和APP的数据) 因为安全连接是和域名绑在一块的,所以需要申请域名 有没有不知道域名是什么的, ...

  3. Python#常用的模块和简单用法

    目录 random 随机模块 os 文件夹模块: time 时间模块: matplotlab.pyplot 作图模块 mpl_toolkits.mplot3d 绘制3D图模块 Pygame Reque ...

  4. 【Swift】iOS开发笔记(一)

    前言 边开发边学习,边攒经验,汇总一下记录到这里 声明 欢迎转载,但请保留文章原始出处:) 博客园:http://www.cnblogs.com 农民伯伯: http://over140.cnblog ...

  5. Effective STL 读书笔记

    Effective STL 读书笔记 标签(空格分隔): 未分类 慎重选择容器类型 标准STL序列容器: vector.string.deque和list(双向列表). 标准STL管理容器: set. ...

  6. 根据json生成c#实体类

    vs 编辑->选择性粘贴->将json粘贴为类

  7. redis简介与持久化

    一 . redis简介 redis属于NoSQL学名(not only sql) 特点: 存储结构与mysql这一种关系型数据库完全不同,nosql存储的是key value形式 nosql有很多产品 ...

  8. 【数学建模】数模day13-灰色系统理论I-灰色关联与GM(1,1)预测

    接下来学习灰色系统理论. 0. 什么是灰色系统? 部分信息已知而部分信息未知的系统,我们称之为灰色系统.相应的,知道全部信息的叫白色系统,完全未知的叫黑色系统. 为什么采用灰色系统理论? 在给定信息不 ...

  9. Django模板语言进阶

    一.母板 1.什么情况下使用母版 当多个页面的大部分内容都一样的时候,我们可以把相同的部分提取出来,放到一个单独的母版HTML文件中 然后在母版中定义需要被替换的block 例如:母板页面 <! ...

  10. 使用@property

    @property装饰器就是负责把一个方法变成属性调用的,既能检查参数,又可以用类似属性这样简单的方式来访问类的变量 class Student(object): @property def scor ...