云计算之路-阿里云上:10:28-10:51云盾清洗以及IP切换引发的主站访问故障

大家好,非常抱歉!今天10:28-10:51期间由于阿里云云盾流量清洗,以及切换IP后负载均衡的带宽跑满,影响了主站的正常访问,给您造成了很大的麻烦,请您谅解!

故障的过程是这样的:

10:28,我们收到了来自阿里云云盾的通知短信:

【阿里云】尊敬的用户:您的 IP 遭受外部流量攻击,已启动免费清洗服务...

以前也收到过几次这样的通知短信,根据以往的经验,这样的云盾流量清洗不会影响网站的正常访问。

可是今天收到短信后,突然发现主站www.cnblogs.com不能访问了(当时我们是通过上海电信的网络访问的)。当时很着急,立即上云盾控制台查看情况,攻击流量在云盾的承受范围内,不是流量攻击造成的不能访问。怀疑问题与云盾的流量清洗有关。所以,一边联系阿里云客服,一边进行了DNS解析切换,将流量切换到了另外一台SLB(阿里云负载均衡)上。

但是在切换时,我们忘记了另外一台SLB上设置了带宽限制。开始的时候由于DNS解析没完全生效,没察觉带宽问题,等后来DNS解析逐渐生效后,由于带宽跑满造成主站访问速度慢,等我们发现后才恢复正常。(这是我们在这次处理故障过程中的疏忽,我们会认真检讨,吸取教训)

之后,原来的SLB在停止流量清洗之后,也恢复了正常。流量清洗期间的不能访问可能是云盾清洗期间误屏蔽了一些地区的IP,这个有待阿里云的进一步分析。

在这次故障中,我们深刻体会到在面对紧急问题时保持沉着冷静的心态是多么重要,否则很容易在处理现有问题过程中制造出新的问题。

时间: 2024-10-09 23:56:34

云计算之路-阿里云上:10:28-10:51云盾清洗以及IP切换引发的主站访问故障的相关文章

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

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

云计算之路-阿里云上:超过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)这个坑我们最多.最神秘.最诡异的坑

云计算之路-阿里云上:什么是“黑色1秒”?

为了更好地分享我们解决"黑色1秒"问题的过程,在这篇博文中我们将专门描述一下"黑色1秒"问题的表现. "黑色1秒"是我们使用阿里云以来继"黑色10秒"之后遭遇的最奇特.最诡异.最难以捉摸.最富有戏剧性的问题. 它有2个最显著的特征: 第一个是最直观的表现,在Windows性能监视器(Performace Monitor)中会出现1秒的ASP.NET Applications -> Requests/Sec(简称QPS)为

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

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

云计算之路-阿里云上:“黑色1秒”问题与2009年Xen一个补丁的故事

在之前对"黑色1秒"问题的分析博文中,我们将最大嫌疑对象锁定在了Xen,在这篇博文我们将从Xen的角度进行分析.也许有人会问,为什么不知道天多高地多厚地去研究不属于自己范围的问题?只因我们对一个问题的强烈好奇心--究竟是不是我们用Windows的错? 2009年3月20日,来自Intel的Yu Ke通过Xen-dev Mailing List给来自Citrix的Keir Fraser(负责的Xen开发者之一)发了一封邮件,提交了Xen的一个patch--cpuidle: suspend

云计算之路-阿里云上:神奇的“黑色30秒”再次出现,究竟是谁的错?

自从4月28日我们从ASP.NET线程的角度对"黑色30秒"问题进行分析之后,我们采用了新的线程设置,然后观察"黑色30秒"是否再次出现. <processModel enable="true" requestQueueLimit="5000" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50&q

云计算之路-阿里云上:因为网络问题,物理机换回虚拟机

今天早上7:00开始的从阿里云虚拟机到物理机的切换(详见切换至物理机验证“黑色1秒”是否与虚拟机有关),由于遭遇阿里云网络问题提前结束,14:38更改了DNS解析将流量切换回虚拟机. 网络问题是我们在14:30左右发现的,当时用浏览器打不开网站.用Firefox测试,显示连接超时. Ping发现很多丢包: 780 packets transmitted, 737 packets received, 5.5% packet loss round-trip min/avg/max/stddev =

云计算之路-阿里云上:原来“黑色0.1秒”发生在socket读取数据时

在昨天的博文(云计算之路-阿里云上:读取缓存时的"黑色0.1秒")中我们犯了一个很低级的错误--把13ms算成了130ms(感谢陈硕发现这个错误!),从而对问题的原因作出了错误的推断,望大家谅解! 从中我们吸取到了一个教训:趁热打铁要小心,容易失去冷静,作出错误的判断. 今天我们痛定思痛,用了一个下午的时间重新分析了"黑色0.1秒"问题,这次从EnyimMemcached的源代码下手(https://github.com/enyim/EnyimMemcached).