运维往事 一次负载均衡坏点检测事故

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
EMR Serverless StarRocks,5000CU*H 48000GB*H
网络型负载均衡 NLB,每月750个小时 15LCU
简介: 之前做运维,有一些印象很深的事故,今天来讲其中一个,为了大家能理解,先说一些背景。现在因为流量巨大,单台机器肯定不足以为所有用户提供服务,所以大公司几乎任何一个服务的背后都是一套集群,然而任意一台机器不是100%可靠,如果你想让你服务尽可能接近100%可靠,你的集群就得具备检测和剔除坏点的能力。

之前做运维,有一些印象很深的事故,今天来讲其中一个,为了大家能理解,先说一些背景。现在因为流量巨大,单台机器肯定不足以为所有用户提供服务,所以大公司几乎任何一个服务的背后都是一套集群,然而任意一台机器不是100%可靠,如果你想让你服务尽可能接近100%可靠,你的集群就得具备检测和剔除坏点的能力。

 之前在阿里广泛使用的是LVS负载均衡,LVS集群就支持坏点检测和剔除,用户访问大概架构如下。

3ea4774f512d1fd63f9b5d70f6f3c944_watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbmRvbw==,size_27,color_FFFFFF,t_70.png

 起始网络请求经过的路径远比这个复杂,我这里只是个示意图。lvs集群必须能检测到10.11.100.4这台机器的异常。你说啥?lvs是做啥的?我们在访问淘宝的时候,拿到的ip地址并不是真正提供服务的服务器ip地址,不行你用dig命令看下。就两台服务器给几亿用户用?不可能的!!

e16fc155c329a27ff1a1817e3f6e08e4_watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbmRvbw==,size_27,color_FFFFFF,t_70.png

 你看到的两个IP只是负载均衡lvs集群的ip,lvs会把你的请求转发的真正提供服务的机器上去。通过lvs转发有好多优点。


节省公网ip,像淘宝这么大的网站,如果服务器全部挂域名下面,这就得需要成千上万公网ip,如果每个公司都这么做,ipv4资源早就耗尽了。

更高的可用性,dns是用缓存的,几分钟到十几分钟不等,如果有ip变化,可能意味着大批用户在十几分钟内都拿到的是错误的ip。但lvs下面的ip可用很快切换。

更方便的运维。如果流量变化,可用快速在lvs下增删机器,出现坏点,lvs也可以快速把坏的机器流量切走。

今天要说的这个事故,就和lvs第三个优点有关,就是有个vip下有一批机器服务有问题,但其实lvs机器并没有将其下线。这里并不是说lvs本身出现了问题,根本原因其实是运维在配置lvs Health Check方式不合理导致的。

 阿里lvs集群其实提供了两种对web服务Health Check的方式。1.检测服务端口是否打开,只要服务器端口支持开着就认为是正常。 2.发出一个http请求,看状态码是否正常。

 事故那次都是用的第一种health check方式,问题的本质在于,端口开着服务并不一定正常,所以lvs把大量请求转发到这些端口开着但服务异常的机器上,这些请求便得不到正常的响应。   第一种health check起始只是在OSI网络分层的第4层传输层做检测,它起始只能检测数据能否被正常的传送到。 而第二种health check方式是在第7层应用层做的,它不仅能保证数据能否被传送到,而且还检测能否被正常处理。

6d94a3530129782797a9faf7dd5634c1_watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hpbmRvbw==,size_27,color_FFFFFF,t_70.png

 那是不是全部切换到第7层就是最好的解决方案呢,虽然我们当时也是这么做的,为了防止类似的事故发生,我们对阿里妈妈所有的vip都做了检查,全部切换到第二种检查方式。 但其实我觉得这也并不一定是最好的方式,本身对lvs集群而言,4层检查比7层要省事多了,而且对自生的负载压力也小。 另一个原因是,这种应用异常的问题应该交由监控系统去检测,而不是让一个和业务毫无关联的基础服务区兜底。其实当时我们也做了监控上的完善。

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
相关文章
|
运维 负载均衡
【运维知识进阶篇】用阿里云部署kod可道云网盘项目(HTTPS证书+负载均衡+两台web)(三)
【运维知识进阶篇】用阿里云部署kod可道云网盘项目(HTTPS证书+负载均衡+两台web)(三)
276 0
|
1月前
|
运维 负载均衡 监控
提升系统性能:高效运维的秘密武器——负载均衡技术
在当今数字化时代,系统的高可用性和高性能成为各类企业和组织追求的目标。本文旨在探讨负载均衡技术在运维工作中的关键作用,通过深入分析其原理、类型及实际应用案例,揭示如何利用这项技术优化资源分配,提高系统的响应速度和可靠性,确保用户体验的稳定与流畅。无论是面对突如其来的高流量冲击,还是日常的运维管理,负载均衡都展现出了不可或缺的重要性,成为现代IT架构中的基石之一。
54 4
|
域名解析 运维 负载均衡
【运维知识进阶篇】Tomcat集群实战之部署zrlog博客(Tomcat服务安装+静态资源挂载NFS+Nginx负载均衡+HTTPS证书+Redis会话保持)
【运维知识进阶篇】Tomcat集群实战之部署zrlog博客(Tomcat服务安装+静态资源挂载NFS+Nginx负载均衡+HTTPS证书+Redis会话保持)
394 1
|
运维 负载均衡 PHP
【运维知识进阶篇】用阿里云部署kod可道云网盘项目(HTTPS证书+负载均衡+两台web)(四)
【运维知识进阶篇】用阿里云部署kod可道云网盘项目(HTTPS证书+负载均衡+两台web)(四)
329 0
|
域名解析 运维 负载均衡
【运维知识进阶篇】用阿里云部署kod可道云网盘项目(HTTPS证书+负载均衡+两台web)(二)
【运维知识进阶篇】用阿里云部署kod可道云网盘项目(HTTPS证书+负载均衡+两台web)(二)
391 0
|
弹性计算 运维 负载均衡
【运维知识进阶篇】用阿里云部署kod可道云网盘项目(HTTPS证书+负载均衡+两台web)(一)
【运维知识进阶篇】用阿里云部署kod可道云网盘项目(HTTPS证书+负载均衡+两台web)
442 0
|
运维 负载均衡 网络协议
【运维知识进阶篇】集群架构-Nginx四层负载均衡详解
【运维知识进阶篇】集群架构-Nginx四层负载均衡详解
434 0
|
运维 负载均衡 NoSQL
【运维知识进阶篇】集群架构-Nginx七层负载均衡详解(二)
【运维知识进阶篇】集群架构-Nginx七层负载均衡详解(二)
189 0
|
5月前
|
缓存 负载均衡 算法
解读 Nginx:构建高效反向代理和负载均衡的秘密
解读 Nginx:构建高效反向代理和负载均衡的秘密
122 2
|
4月前
|
负载均衡 算法 应用服务中间件
nginx自定义负载均衡及根据cpu运行自定义负载均衡
nginx自定义负载均衡及根据cpu运行自定义负载均衡
82 1