云计算之路-阿里云上：负载均衡从七层换成四层后的意外发现

阿里云的负载均衡产品叫SLB，七层负载均衡用的是LVS+Tengine，四层负载均衡用的是LVS。

昨天七层SLB出现了波动，我们后来改用了四层SLB。

使用后意外地发现，用户请求的响应内容TCP出包走的是云服务器的公网网卡。

之前用七层SLB时流量走的都是内网网卡，再加上RDS、Memcached也走的是内网网卡，于是网络负载都集中在一块内网网卡，内网网卡IO成为了瓶颈。而公网网卡却闲置着，我们之前也曾想过要是将一部分网络负载让公网网卡分担该多好啊。

我们用物理服务器的时候，会把Web服务器上的3块网卡都用上。Web服务器与DB服务器之间用1块网卡，Web服务器与其他服务器的内网连接用1块网卡，Web服务器与互联网的连接用1块网卡。这样既充分了利用资源，又提高了效率，还减少了单块网卡的IO负担。

而现在用了四层SLB之后，竟然带来了让人惊喜的“副作用”。

【负载均衡相关资料】

四层和七层负载均衡的区别

负载均衡笔记

云计算之路-阿里云上：负载均衡从七层换成四层后的意外发现,布布扣,bubuko.com

时间： 2024-07-31 04:17:49

云计算之路-阿里云上：负载均衡从七层换成四层后的意外发现的相关文章

云计算之路-阿里云上：Wireshark抓包分析一个耗时20秒的请求

这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程. 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器. 下面是分析的过程: 1. 启动Wireshark,针对内网网卡进行抓包. 2. 在IIS日志中找出要分析的请求(借助Log Parser Studio) 通过c-ip(Client IP Address)可以获知SLB的内网IP,在分析Wireshar抓包时需要依据这个IP进

云计算之路-阿里云上：消灭“黑色n秒”第二招——给w3wp进程指定CPU核

虽然昨天的第一招失败了,但是从失败中我们学到了与多核CPU相关的Processor Affinity(处理器关联)的知识. 既然我们可以让.NET程序的不同线程运行于指定的CPU核,那是不是也可以让IIS应用程序池的进程w3wp运行于指定的CPU核? 虽然看起来"黑色n秒"似乎与w3wp运行于哪些CPU核没有什么关系,但是我们既然把怀疑对象锁定在CPU,那么任何与CPU相关的线索都不能放过.即使失败,也会满载而归,因为如果没有"黑色n秒"这个问题的驱动,我们根本不会

云计算之路-阿里云上：消灭“黑色n秒”第三招——禁用网卡的TCP/IP Offload

程咬金有三板斧,我们有三招.在这篇博文中我们要出第三招,同时也意味着昨天在"希望的田野"上的第二招失败了. 前两招打头(CPU)不凑效,这一招要换一个部位,但依然要坚持攻击敌人最弱(最忙最累)部位的原则.那除了CPU,最忙最累的部位是哪里呢?对于Web服务器来说,毫无悬念,当然是网卡.而且阿里云的云服务器,所有的网络负载都集中在一块内网网卡上,SLB(负载均衡)用它,OCS(缓存服务)用它,RDS(数据库服务)也用它.所以,就对它出招! 招式受这篇博文(XenServer – Wind

云计算之路-阿里云上：SLB会话保持的一个坑

冒着被大家厌烦的风险,今天再发一篇"云计算之路-阿里云上".这是在前一篇发过之后真实发生的事情,我们觉得定位问题的过程值得分享.而且估计园子里不少朋友被这个问题骚扰过,我们有责任让大家知道问题的真正原因. 快下班之前,园区里另外一家公司的朋友说他们公司有的人不能正常访问园子--会出现HTTP Error 400错误,而其他人可以正常访问.这个问题立即引起了我们的警觉,因为之前也有园友反馈过同样的问题,当时什么也没动,后来就好了,以为是他们公司网络代理服务器的问题.由于我们从未遇到过这个

云计算之路-阿里云上：奇怪的CPU 100%问题

这篇博文记录一下6月1日在阿里云上遇到的奇怪的CPU 100%问题,希望多年以后能真相大白. 那天负载均衡(SLB)中只放了1台云服务器(平时都放2台),由于是节假日,虽然只放了一台,但这台服务器的负载也没有平时高.但在上午的时候突然出现了CPU 100%问题,然后切换到另外一台云服务器恢复正常. 下午的时候,我们将负载又切换回那台出问题的服务器,正常运行一段时间后,CPU又飙到100%.切换回之前正常的那台服务器后又恢复正常. 对比两台服务器,虽然那台正常的服务器CPU波动也挺大,但即使偶尔串

云计算之路-阿里云上-容器难容：容器服务故障以及自建 docker swarm 集群故障

3月21日,由于使用阿里云服务器自建 docker swarm 集群的不稳定,我们将自建 docker swarm 集群上的所有应用切换阿里云容器服务 swarm 版(非swarm mode). 3月22日,我们进行移除与重启节点的操作时引发了故障,详见 云计算之路-阿里云上-容器服务:移除节点引发博问站点短暂故障 . 3月24日,我们参考阿里云容器服务帮助文档-指定多节点调度通过给节点添加用户标签的方式成功移除了部分节点.我们是这么操作的,当时所有节点没有添加用户标签,给待移除节点之外的所有节

云计算之路-阿里云上：排查“黑色30秒”问题-为什么请求会排队

http://www.cnblogs.com/cmt/p/3682642.html 针对Web服务器“黑色30秒”问题(详见云计算之路-阿里云上:Web服务器遭遇奇怪的“黑色30秒”问题),经过分析,我们准备从这个地方下手——为什么会出现\ASP.NET\Request Queued大于0的情况(为什么请求会排队)? 首先, 通过Windows性能监视器去观察,看能不能找到这样的线索——在什么条件下会触发请求排队? 我们在性能监视器中增加了1个监视指标——\HTTP Service Reques

云计算之路-阿里云上：超过70秒的请求抓包分析

超过70秒的请求是通过分析IIS日志发现的: 10.159.63.104是SLB的内网IP. 通过Wireshark抓包分析请求是9:22:21收到的(tcp.stream eq 23080): 09:22:21.299838000 10.159.63.104 10.161.241.208 HTTP 291 GET /eastsea/p/3764040.html HTTP/1.0 这个请求响应内容的长度是:Content-Length 1154110(1.1MB) 云服务器(ECS)在收到请求后

云计算之路-阿里云上：对“黑色n秒”问题的最终猜想——CPU C-states引起的

如果说2013年云计算之路的主题是"踩坑",那么2014年我们希望云计算之路的主题变成"填坑"--当然填坑是阿里云来完成的,我们只是见证曾经的坑坑洼洼变成平坦大道. 15号(周四)晚上我们发现了SLB会话保持的坑,16号晚上阿里云成功定位并进行修复,这两天正式发布后会填平这个坑.这次从踩坑到填坑的过程是最痛快的一次. 接下来我们的目标锁定在"黑色n秒"(刚发现一个英文说法:stuck for x seconds)这个坑我们最多.最神秘.最诡异的坑