《负载均衡健康检查使用的误区和最佳实践.docx》由会员分享，可在线阅读，更多相关《负载均衡健康检查使用的误区和最佳实践.docx（7页珍藏版）》请在三一文库上搜索。
1、负载均衡健康检查的使用误区和最佳实践本文章来自于阿里云云栖社区分析用户提交的负载均衡（简称 SLB）工单，我们发现很多SLB异常问题与不合理的健康检查策略相关。例如： 健康检查间隔设置过长，SLB无法及时准确发现后端ECS出现服务不可用，造成实际业务中断。 使用HTTP模式健康检查，未合理配置后端日志记录模块，导致后端日志内容记录大量健康检查HEAD日志，造成磁盘负载压力。原理要点SLB服务通过健康检查机制检测后端云服务器池中ECS的健康状态，自动隔离异常状态的ECS，从而解决了单台ECS的单点问题，同时提高了应用的整体服务能力。关于健康检查的原理，详情请参考官网知识点，l 负载均衡健康检查原
2、理浅析文章重点阐述了如下几个方面： 健康检查处理过程 健康检查策略配置说明 健康检查机制说明 健康检查状态切换时间窗总结要点如下：1、4层TCP协议的健康检查通过TCP 3次握手检查后端 ECS 端口是否处于监听转台。与常规TCP连接使用TCP FIN方式销毁不同，健康检查的TCP连接在3次握手建立成功后，发起方以TCP Reset方式主动将连接断开。2、7层HTTP协议的健康检查通过HTTP HEAD 请求检查指定 URL 路径的返回值，如果返回值与自定义的健康检查成功返回值相匹配，则判定检查成功。3、SLB使用 4层 TCP 协议监听时，健康检查方式可选 TCP 协议 或 HTTP 协议。
3、4、4层 UDP 协议的健康检查是通过ICMP Port Unreachable消息来判断，可能存在服务真实状态与健康检查不一致的问题，我们后续会持续产品改进解决该问题。5、健康检查机制的引入，有效提高了承载于SLB的业务服务的可用性。但是，为了避免频繁的健康检查失败引发的切换，对系统可用性带来的冲击，健康检查只有在【连续】多次检查成功或失败后，才会进行状态切换（判定为健康检查成功或失败）。使用误区如下是通过工单梳理总结的健康检查常见的理解和使用误区。误区1 : 怀疑SLB健康检查形成DDoS攻击，导致服务器性能下降。例如，有用户误认为 SLB 使用上百台机器进行健康检查，大量高频次的 TCP
4、 请求会形成DDoS攻击，造成后端 ECS性能低下。但实际上，无论是4层TCP/UDP或7层HTTP协议的健康检查，都根本无法形成DDoS攻击。原理上，SLB集群会利用多台机器 (假定M，个位数级别) 对后端 ECS 的每个服务监听端口 (假定N) ，按照配置的检查间隔(假定 O 秒，一般建议最少 2 秒) 进行健康检查。以4层 TCP 协议为例，每秒的TCP连接建立数为：M*N/O。因此，健康检查带来的每秒TCP并发数，主要取决于创建的监听端口数量。除非监听端口达到巨量，否则健康检查对后端 ECS 的 TCP 并发连接请求根本无法达到 SYN Flood 的攻击级别，实际对后端 ECS 的网
5、络压力极低。误区2 : 用户为了避免 SLB 健康检查的影响，将健康检查间隔设置很长。该配置会导致当后端ECS出现异常时，SLB需要较长时间才能侦测到后端ECS不可用。尤其当后端ECS间断不可用时，由于SLB需要【连续】检测失败时才会移除异常ECS，这会导致SLB集群可能根本无法发现后端ECS不可用。举一个实际案例：背景信息：用户使用后端有2台ECS的1个4层 TCP协议的公网SLB,对外提供服务，TCP协议的健康检查间隔设置为50秒。某天用户做了应用代码改进后，发布到1台测试ECS，而后将该ECS加入SLB。但是由于应用问题以及不合理的健康检查的设置，出现了连续2次的业务不可用。下图失败连接
6、数趋势代表SLB转发到后端ECS但无法建立连接的TCP 3次握手失败的连接数。在SLB 正常工作时其值应该为0。图示. 失败连接数趋势从图中可以看到，出现了2次SLB转发失败，业务间断不可用的情况。阶段1: 15:29 - 16:44: 该问题由于应用代码的原因导致。阶段2: 17:12起 : 该问题由于ECS内核参数的配置错误，单台ECS无法承担业务量导致。如下是复盘的详细过程：【15:26】 用户创建ECS机器(假定名称i-test), 部署最新的应用代码，加入SLB集群中。【15:29】由于新应用代码的问题，SLB将请求转发至该ECS后，其CPU飙升至100%。图示. ECS CPU前图
7、失败连接数趋势显示15:30分SLB的TCP转发失败连接数开始飙升，原因就是新加入的ECS i-test机器在CPU 100%的情况下出现业务不可用。15:34分开始，后端的ECS健康检查日志中出现健康检查失败的信息。但由于健康检查的间隔为50秒，而后端ECS i-test也不是完全不响应，偶尔的TCP 三次握手健康检查还可以成功，因此未出现【连续】健康检查失败，所以该SLB的监听端口未报出异常状态。用户接到终端客户反馈业务出现断续不可用的情况后开始紧急自查。但由于SLB状态未报出异常，用户将排查集中在应用侧。【16:44】用户将ECS i-test从SLB中下线，业务恢复正常，从前图失败连接
8、数趋势中，可以看到失败的数量降到0。【16:56】用户将装有老版本应用的ECS i-test 加入SLB集群，后端3台ECS正常提供服务。【17:12】业务恢复后，用户认为之前问题是由于业务代码的问题导致。此时用户通过将ECS权重设置为0的方式将2台ECS下线，由新上线的那台ECS i-test承担所有业务。由于业务量陡增，ECS i-test机器未合理配置内核TCP参数，IP Conntrack表耗尽，前图失败连接数趋势显示大量新建TCP连接失败。但由于健康检查间隔高，SLB无法及时判断后端ECS实际状态，SLB日志显示该ECS的状态在很长一段时间内保持正常，当前端用户反馈后，才发现实际业务
9、影响，导致业务中断时间较长。后续通过修改ECS 内核TCP配置参数解决。从该示例可以看出，合理的配置健康检查间隔对于及时发现业务不可用非常重要。误区3 : 使用HTTP模式健康检查，未合理配置后端，导致后端日志内容记录大量健康检查HEAD日志，造成磁盘负载压力。我们确实遇到过一例健康检查配置导致后端ECS的性能低下的案例。用户购买低配(1核1G) ECS，使用7层HTTP健康检查，健康检查间隔低，同时配置多个监听，后端ECS的Web服务记录大量的HEAD请求日志，导致IO占用高，引起性能低下。解决方案请参考知识点健康检查导致大量日志的处理。最佳实践结合SLB健康检查的技术要点和实际使用误区，我
10、们提供如下最佳实践。1、根据业务需要合理选择4层TCP 或 7层HTTP的健康检查模式。如果使用HTTP 健康检查模式，请合理配置后端日志配置，避免健康检查HEAD请求过多对IO的影响。HTTP健康检查请不要对根目录进行检查，可以配置为对某个HTML文件检查以确认Web服务正常。2、合理配置健康检查间隔根据实际业务需求配置健康检查间隔，避免因为健康检查间隔过长导致无法及时发现后端ECS出现问题。具体请参考：健康检查的相关配置，是否有相对合理的推荐值？3、合理配置SLB架构，监听、虚拟服务器组合转发策略为满足用户的复杂场景需求，目前SLB可以配置虚拟服务器组和转发策略。详情请参考文档：l 如何实
11、现域名 / URL 转发功能对于虚拟服务器组、转发策略，其与监听对健康检查并发的影响相同，如下图：维度健康检查配置健康检查目标服务器后端服务器使用配置监听时的健康检查配置所有后端 ECS虚拟服务器组使用配置监听时的健康检查配置相应虚拟服务器组包含的服务器转发策略使用配置监听时的健康检查配置相应虚拟服务器组包含的服务器建议用户根据实际业务需求，合理配置监听、虚拟服务器组和转发策略。a、对于4层TCP协议，由于虚拟服务器组可以是有后端ECS不同的端口承载业务，因此在配置4层TCP的健康检查时不要设置检查端口，而默认使用后端服务器的端口进行健康检查, 否则可能导致后端ECS健康检查失败。b、对于7层HTTP协议，使用虚拟服务器组合转发策略时，确保健康检查配置策略中的URL在后端每台机器上都可以访问成功。C、避免过多的配置监听、虚拟服务器组和转发策略，以免对后端ECS形成一定的健康检查压力。