机房流量问题总结分析

标签: 机房 流量 问题 | 发表时间:2016-02-27 19:38 | 作者:jayluns
出处:http://www.iteye.com

1 【提出问题】

【实际案例一】

凌晨 3:00 点某公司(网站业务)的一个 IDC 机房带宽流量突然从平时高峰期 150M 猛增至 1000M ,如下图:

 

该故障的影响:直接导致数百台服务器无法连接,该机房全部业务中断。

 

实际案例二】

某年某月某日夜老男 1 孩接到学生紧急求助,公司网站( web 游戏业务)平时几十 M 带宽,结果突然跑满 100M ,持续 100M 已经很久。事后,该学生的总结开头如下,

凌晨一点接到报警短信,网站无法访问。立马拿起笔记本上网查看,发现整个机柜的网络都无法正常访问。第一感觉是不是IDC网络出问题了,给机房打电话反馈回来的信息是机房网络正常,但是带宽流量异常(100M带宽的流量峰值已跑瞒)。

该故障的影响:直接导致数十台服务器无法连接,该机房全部业务中断,且故障持续时间长。

【实际案例三】

某月某日,接到运维的朋友紧急求助,其公司的CDN源站,源站的流量没有变动,CDN那边的流量无故超了好几个G,不知道怎么处理? 老男孩补充,曾遇到过一张图片不到一天,跑了20多T的一张流量。
该故障的影响:由于是购买的CDN,虽然流量多了几个G,但是业务未受影响,但是,这么大的异常流量,持续下去可直接导致公司无故损失数万元。解决这个问题体现运维的价值。

 

事不过三,暂时先举3个例子吧。这三个案例都是运维工作中实际遇到的故障,事发突然且需要紧急处理。在实际论坛或群里看到朋友反馈的此类问题,也多达数次,其中差不多各种鸟都有,老鸟、中鸟,小鸟。
大部分朋友解决起来,脑袋里没思路(反射弧直接定位DDOS),解决起来耗时长,造成的了业务长时间中断。老鸟解决起来也是按部就班,首先会反射为DDOS问题,结果解决时间加长了,如果能提前做好预案,恢复速度可能就会好很多,下面高手就来谈下个人的一些看法。

 

【分析问题】
1)IDC
带宽被占满的原因很多,常见的有:

a.真实遭受DDOS攻击(遇到过几次,造成影响的不多见,其中还有黑客勒索的案例)。
b.内部服务器中毒,大量外发流量(这个问题老男孩接警5次以上)

c.网站元素(如图片)被盗连,在门户页面被推广导致大量流量产生(接警3次以上)

d.合作公司来抓数据,如:对合作单位提供了API数据接口(有合作的公司的朋友了解这个)

e.购买了CDN业务,CDN猛抓源站(这个次数也不少)。

f.其他原因还有一些,不普遍就不提了。

2)CDN 带宽异常,源站没异常。

这类问题基本都是缓存在CDN的数据被频繁访问引起的。解决方法见结尾案例。

3) CDN 带宽异常,源站也异常。

可能原因如公司做推广,大量数据访问,热点数据cache里不全。或CDN问题导致数据回源(有关CDN回源率问题及提升回源率经验,以后再和大家分享)。影响就是带宽高,后端静态服务器及图片及存储压力大

 

【解决问题】
分析了问题的可能原因,就好比较排查了。

a. 真实遭受 DDOS 攻击

高手提供了17条解决经验思路,供大家参考,这里就不提了,那么实际上

遭受真实DDOS攻击并产生影响的并不是最常见的。

b. 内部服务器中毒,大量外发流量。

这个问题的解决比较简单,可能有的朋友说,看看服务器流量,哪个机器带宽高处理下就好了。其实不然,实际解决比这复杂得多,带宽打满,所有监控都是看不到的。
比较好的思路,是联系机房确定机房自身无问题后(机房一般没法帮我们的),请机房断开连接外部IP服务器的网线,如负载均衡器,仅保留VPN SERVER,然后断掉内部服务器出网光关的线路,切断外发流量源头。
接下来查看监控流量服务,判断外发流量的服务器,然后进行处理。
其实,这个问题的发生及快速定位和很多公司的运维规范、制度关系很大,高手在给一些公司做运维培训分享时发现这个问题很严重(表象很好,内部运维规范、制度欠缺很多),大家都讨论的很深入,实际用的还是和聊的有差距。。

比如有的公司开发直接FTP连接随时发布代码,或者由开发人员负责定时多次上线。而运维人员又不知晓,结果导致问题发生定位时间长,这点建议各公司的老大多思考下。
高手的运维思路是,如果把网站机房比喻为一座房子,那首先要堵住后门(内部),其次是监控好前门(做好安全,留个小窗户给外面人看,即80端口服务,同时安排站岗值班的)。
网站的无休止的随时随意发布代码,对网站的稳定影响是至关重要的。对运维人员对故障的定位快慢也很关键。根据老男孩不完全调查,约50%以上的重要运维故障都是程序代码导致的,这也是老男孩给企业做培训分享时,灌输建议CTO的,多把网站稳定的责任分给开发,而不是运维。如果这个思想不扭转,网站不稳定状况就难以改变。
c. 网站元素(如图片)被盗连
这个属于网站的基本优化了,apache,lighttpd,nginx都有防盗链的方案,必须要搞。说到这也提个案例,高手的一个学生,到了企业工作,发现人家网站没有防盗链,结果上来没有周知老大,直接做防盗链了,然后美滋滋的当时还给我留言,说给公司搞防盗链了,很有成就,结果导致公司对外合作的业务,都是小叉子了,幸亏发现的及时没出大问题。
d-e. 合作公司来抓数据,如:对合作单位提供了 API 数据接口或购买了 CDN 业务。

最常见的就是购买CDN服务,如:CDN新建一个节点(可能数十机器),直接来我们IDC原战来抓数据(有的做好点的夜里来抓)。把原站抓的流量暴涨,严重的导致服务宕机。几家CDN公司,都有过这样的问题。这点希望CDN公司看到了,能改善,毕竟用户上帝嘛。

当然和电信,联通,GOOGLE,BAIDU,词霸等公司的合作,也会有流量暴高的情况,这里面包括了为合作的站搜索引擎爬虫爬数据的问题。有时虽然带宽流量不高,但是服务器或数据库撑不住了,搜索引擎专门喜欢爬我们的站内搜索,DISCUZ,CMS等早期的开源程序的搜索都是全站like %%方式去数据库搜索的,几个爬虫过来,直接就挂掉了,当然这不是本文要讨论的,解决方案以后再聊。

f. 其他原因还有一些,不普遍就不提了。

上面的几点比较常见,其他原因就不多见了,因此,作罢,打这么多字真不轻松啊。

【苦练内功】

首先,高手强调下,大家要经常培养下自己的心里素质,遇到问题不能发慌。遇到不少朋友,处理紧急故障时,大脑都空白缺血了,手抖的无法敲击键盘了,这样的状态如何解决故障呢?如果老大在后面看着就更是雪上加霜了,甚至有个别学生直接跟高手哭鼻子了,宕机几分钟损失上万,负不起责任。

其实上面的大家的表现都是正常的,没什么不对的,曾经高手也是这样过来的,也是不断的挑战自己才练出来的。
希望朋友们能多提前做功课,不要问题来了在思考解决办法,临时的应对一定会是手忙脚乱的,即使是老鸟。如果提前有预案和防范演练,问题发生后就坦然得多,这可以扩展到运维的方方面面,DB,WEB,备份,恢复,流量等。
【亡羊补牢】

发生问题后,要充分总结,争取下次发生了,能提升速度,当然最好不发生。其实,运维人员挺悲催的,开发的下班就没事了,我们还得7*24开手机,来个短信提心吊胆的,甚至看到有个门户DBA发微薄,说making love时都可能被报警短信打断。1、提前优化运维制度、规范。2、提前优化网站结构、单点故障。3、留足备用带宽及服务器资源,把控好风险。4、完善的监控策略及响应机制等。

尽量不打无准备之战。兵法云,知己知彼,百战不殆。运维又何尝不是这个理?

 

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [机房 流量 问题] 推荐:

机房流量问题总结分析

- - 企业架构 - ITeye博客
凌晨 3:00 点某公司(网站业务)的一个 IDC 机房带宽流量突然从平时高峰期 150M 猛增至 1000M ,如下图:. 该故障的影响:直接导致数百台服务器无法连接,该机房全部业务中断. 某年某月某日夜老男 1 孩接到学生紧急求助,公司网站( web 游戏业务)平时几十 M 带宽,结果突然跑满 100M ,持续 100M 已经很久.

跨机房问题

- Shengbin - NOSQL Notes
跨机房问题一直都是一个老大难的问题,先看传统数据库的跨机房方案. Master/Slave方案. 这是最常用的方案,适用于大多数需求. Master将操作日志实时地发送到Slave,Slave当成Master的一个Hot Backup. Master宕机时,服务切换到Slave,需要修改客户端逻辑使得Master失效时自动寻找新的Master.

流量劫持这种事 不靠求运营商就能用技术解决问题吗?

- - TECH2IPO
有时候你在用手机浏览网页甚至打开 App 的时候(比如打开微信公众号文章或者打开手机淘宝),有时候会出现一个广告弹窗,甚至有时候是运营商自己的流量提醒,这个广告有时候和 App 的内容和类型完全不符,不了解情况的用户很可能会怪罪 App 乱弹广告,也许你真的是怪错人了,你的流量可能被某些机构劫持了.

流量生意

- flypen - 张磊的blog
前些日子网上盛传某联盟的按月分成数据,其中番茄花园、雨木林风的分成都高达百万. 有人惊呼:原来做盗版软件这么赚钱. 也有人质疑:他们怎么可能赚这么多钱. 他们确实很赚钱,简单说,这就是流量生意. 为什么几乎每个巨头都有一个“网站联盟”. 为什么Google当年愿意付费推广Firefox. 为什么,推广Firefox、自己做Chrome的同时,把微软当作对手的Google还特意提供“优化的Internet Explorer”.

稿费问题

- Ruixing F - 创造社新任社长宋石男
据说现在全中国靠给平媒自由撰稿为生的,超不过1000人,而且不少处于相当窘迫的境况,就算想买根绳子来上吊,都买不起质量好的,结果绳子老断. 作为自由撰稿人的一员,我对此深有体会. 1999年国家版权局出台的基本稿酬标准,每千字30元-100元,至今仍为全国发行的报刊的“行业指导价”. 业内估计,全国报刊的稿费中位数大约也就在100元.

lvs 问题

- - 操作系统 - ITeye博客
1: LVS连接的持久时间. 1)同一个ip发来请求到同一台RS的持久超时时间. ipvsadm -A -t 192.168.169.100:80 -s rr -p 120     #该客户的请求120秒内被分配给同一台web.  2)一个链接创建后空闲时的超时时间(分别是:tcp的空闲超时时间、lvs收到客户端tcp fin的超时时间、udp的超时时间).

linux 查看流量

- - 开源软件 - ITeye博客
在Linux下怎么看网络流量. 在Windows下,我们可以很方便的通过360来查看网络流量,知道哪个进程占用的网络带宽比较多. 那在Linux下怎么看流量呢,对于Web服务器来说这是很重要的. 下面这边博客很仔细的介绍了Linux下看流量的方法:. Linux 各种查看网卡流量的方法  http://jasonyong.blog.51cto.com/47753/174197.

Hash Collision DoS 问题

- mazhechao - 酷壳 - CoolShell.cn
最近,除了国内明文密码的安全事件,还有一个事是比较大的,那就是 Hash Collision DoS (Hash碰撞的拒绝式服务攻击),有恶意的人会通过这个安全弱点会让你的服务器运行巨慢无比. 这个安全弱点利用了各语言的Hash算法的“非随机性”可以制造出N多的value不一样,但是key一样数据,然后让你的Hash表成为一张单向链表,而导致你的整个网站或是程序的运行性能以级数下降(可以很轻松的让你的CPU升到100%).

相关性问题

- - 扯氮集--上海魏武挥的博客 - 扯氮集--上海魏武挥的博客
人的本性是趋利避害的,任何合作(或者交易,或者搭伙,或者配对,反正就不是一个人干的事)都会存在三个可能:有利、有害、无利无害. 对于合作一方来说,至少应该保持一个无害的结果,这是常识. 如果觉得有害的可能性很大,于是,我们就会拒绝合作. 问题在于,谁也不是神仙,没有人可以事先100%断定合作必然会有利或至少无害,于是人们需要很多背景信息来供决策.

select 效率问题

- - C++博客_杨粼波
 很多人不知道SQL语句在SQL SERVER中是如何执行的,他们担心自己所写的SQL语句会被SQL SERVER误解. 一些人不知道以上两条语句的执行效率是否一样,因为如果简单的从语句先后上看,这两个语句的确是不一样,如果tID是一个聚合索引,那么后一句仅仅从表的10000条以后的记录中查找就行了;而前一句则要先从全表中查找看有几个name='zhangsan'的,而后再根据限制条件条件tID>10000来提出查询结果.