健康检查概述

负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。

开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。

如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。

健康检查过程

负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。

LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。

如下图所示,负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。

HTTP/HTTPS监听健康检查机制

针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。

对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。

七层监听的检查机制如下:

  1. Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。
  2. 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。
  3. 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。
  4. 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。

TCP监听健康检查机制

针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。

TCP监听的检查机制如下:

  1. LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。
  2. 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。
  3. 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。
  4. 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。

说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。

该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer

解决方案:

  • TCP监听采用HTTP方式进行健康检查。
  • 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。

UDP监听健康检查

针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。

UDP监听的检查机制如下:

  1. LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。
  2. 如果后端ECS相应端口未正常监听,则系统会返回类似port XX unreachable的ICMP报错信息,反之不做任何处理。
  3. 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。
  4. 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。

说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题:

如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。

解决方案:

负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。

健康检查时间窗

健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定:

  • 健康检查间隔(每隔多久进行一次健康检查)
  • 响应超时时间 (等待服务器返回健康检查的时间)
  • 检查阈值(健康检查连续成功或失败的次数)

健康检查时间窗的计算方法如下:

  • 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1)

  • 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1)

    说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。

健康检查状态对请求转发的影响如下:

  • 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。
  • 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。
  • 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。

健康检查响应超时和健康检查间隔示例

以如下健康检查配置为例:

  • 响应超时时间:5秒
  • 健康检查间隔:2秒
  • 健康阈值:3次
  • 不健康阈值:3次

健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1),即5×3+2×(3-1)=19s。

从健康状态到不健康状态的检查过程如下图所示:

健康检查成功时间窗= (健康检查成功响应时间×健康阈值)+检查间隔×(健康阈值-1),即(1×3)+2×(3-1)=7s。

说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。

从不健康状态到健康的状态检查过程如下图所示(假设服务器响应健康检查请求需要耗时1s):

HTTP健康检查中域名的设置

当使用HTTP方式进行健康检查时,可以设置健康检查的域名,但并非强制选项。因为有些应用服务器会对请求中的host字段做校验,即要求请求头中必须存在host字段。如果在健康检查中配置了域名,则SLB会将域名配置到host字段中去,反之,如果没有配置域名,SLB则不会在请求中附带host字段,因此健康检查请求就会被服务器拒绝,可能导致健康检查失败。综上原因,如果您的应用服务器需要校验请求的host字段,那么则需要配置相关的域名,确保健康检查正常工作。

原文:https://help.aliyun.com/document_detail/85958.html

原文地址:https://www.cnblogs.com/jiftle/p/11416580.html

时间: 2024-10-31 19:32:49

健康检查概述的相关文章

Active Directory 健康检查

Active Directory是企业后端最重要的基础架构应用,没有之一.AD的安全与可靠几乎影响所有应用.除了符合微软最佳实践的设计以及标准化的运维之外,定期执行一次健康检查,并且在重大项目启动前也进行一次健康检查将会很好的保障整个活动目录持续可靠的为企业应用提供良好的支撑. 微软原厂可以提供专业的AD健康检查服务,使用ADRAP(Risk Assessment Program)程序,运行ADST(Active Directory Snapshot Tool)工具来抓取AD中的各种信息,并最终

kubernetes之pod健康检查

目录 kubernetes之pod健康检查 1.概述和分类 2.LivenessProbe探针(存活性探测) 3.ReadinessProbe探针(就绪型探测) 4.探针的实现方式 4.1.ExecAction 4.2.HTTPGetAction 4.3.TCPSocketAction 5.探测行为属性 6.扩展的探测机制 kubernetes之pod健康检查 1.概述和分类 pod通过两类探针来检查容器的健康状态.分别是LivenessProbe(存活性探测)和ReadinessProbe(就

springCloud(6):Eureka的自我保护模式、多网卡下的IP选择、Eureka的健康检查

一.Eureka的自我保护模式 进入自我保护模式最直观的体现就是Eureka Server首页的警告,如下图: 默认情况下,如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳,Eureka Server将会注销该实例(默认90秒).但是当网络分区故障发生时,微服务与Eureka Server之间无法正常通信,这就可能变得非常危险了----因为微服务本身是健康的,此时本不应该注销这个微服务. Eureka Server通过"自我保护模式"来解决这个问题----当Eu

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

注意: 配置前需要将上一篇的配置都清除掉 ifconfig eth1:1 down service ipvsadm restart nginx作为请求分发服务器时, 有健康检查机制, 挂了的服务器不会在分发请求 但lvs没有, 需要keepalived进行健康检查, 否则仍然将请求分发过去, 造成无法访问 安装keepalived高可用的lvs集群 1, 安装 ipvsadm 上篇讲过, 不说, 安装好就可以, 不需要配置 2, 安装keepalived 上上篇讲过,,, yum 安装 3, 配

Oracle SQL 调优健康检查脚本

Oracle SQL 调优健康检查脚本 我们关注数据库系统的性能,进行数据库调优的主要工作就是进行SQL的优化.良好的数据架构设计.配合应用系统中间件和写一手漂亮的SQL,是未来系统上线后不出现致命性能问题的有力保证. 在CBO时代,一个SQL的执行计划是多样的.影响执行计划的因素也从过去RBO时代的SQL书写规则变为综合性因素.这为我们生成更加优秀执行计划提供了基础,同时也给我们进行调优带来的很多麻烦. 目前我们通常的做法,是通过AWR报告或者调试手段,发现某某SQL有问题,之后从Librar

lvs+keepalived健康检查

一. LVS简介 LVS是Linux Virtual Server的简称,即Linux虚拟服务器.使用LVS技术要达到的目标是:通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能.高可用的服务器群集,它具有良好可靠性.可扩展性和可操作性.从而以低廉的成本实现最优的服务性能. 二.网络拓扑 三.接口IP及属性配置 1,在Master配置接口IP如下: [[email protected] network-scripts]# ifconfig ens33:flags=4163<UP,BR

Nginx实战系列之功能篇----后端节点健康检查

公司前一段对业务线上的nginx做了整理,重点就是对nginx上负载均衡器的后端节点做健康检查.目前,nginx对后端节点健康检查的方式主要有3种,这里列出: 1.ngx_http_proxy_module 模块和ngx_http_upstream_module模块(自带)     官网地址:http://nginx.org/cn/docs/http/ngx_http_proxy_module.html#proxy_next_upstream 2.nginx_upstream_check_mod

【转】nginx 主动式后端服务器健康检查

原文链接  http://tengine.taobao.org/document_cn/http_upstream_check_cn.html ngx_http_upstream_check_module 该模块可以为Tengine提供主动式后端服务器健康检查的功能. 该模块在Tengine-1.4.0版本以前没有默认开启,它可以在配置编译选项的时候开启:./configure --with-http_upstream_check_module Examples http { upstream

Tengine新增健康检查模块

总结 2.tengine的状态监控 Tengine的状态监控有两种 这里演示一个健康检查模块功能 配置一个status的location location /status { check_status; } 在upstream配置如下 check interval=3000 rise=2 fall=5 timeout=1000 type=http; check_http_send "HEAD / HTTP/1.0\r\n\r\n"; check_http_expect_alive ht