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

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

  之前在阿里广泛使用的是LVS负载均衡,LVS集群就支持坏点检测和剔除,用户访问大概架构如下。
在这里插入图片描述
  起始网络请求经过的路径远比这个复杂,我这里只是个示意图。lvs集群必须能检测到10.11.100.4这台机器的异常。你说啥?lvs是做啥的?我们在访问淘宝的时候,拿到的ip地址并不是真正提供服务的服务器ip地址,不行你用dig命令看下。就两台服务器给几亿用户用?不可能的!!
在这里插入图片描述
  你看到的两个IP只是负载均衡lvs集群的ip,lvs会把你的请求转发的真正提供服务的机器上去。通过lvs转发有好多优点。
1. 节省公网ip,像淘宝这么大的网站,如果服务器全部挂域名下面,这就得需要成千上万公网ip,如果每个公司都这么做,ipv4资源早就耗尽了。
2. 更高的可用性,dns是用缓存的,几分钟到十几分钟不等,如果有ip变化,可能意味着大批用户在十几分钟内都拿到的是错误的ip。但lvs下面的ip可用很快切换。
3. 更方便的运维。如果流量变化,可用快速在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层应用层做的,它不仅能保证数据能否被传送到,而且还检测能否被正常处理。
图片来自网络
  那是不是全部切换到第7层就是最好的解决方案呢,虽然我们当时也是这么做的,为了防止类似的事故发生,我们对阿里妈妈所有的vip都做了检查,全部切换到第二种检查方式。 但其实我觉得这也并不一定是最好的方式,本身对lvs集群而言,4层检查比7层要省事多了,而且对自生的负载压力也小。 另一个原因是,这种应用异常的问题应该交由监控系统去检测,而不是让一个和业务毫无关联的基础服务区兜底。其实当时我们也做了监控上的完善。

打赏

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.