由CloudFlare宕机引发的思考 | 云防线技术博客

由CloudFlare宕机引发的思考

来源:本站原创 未分类 超过围观 0条评论

来源   CSDN

摘要:高速发展的网站安全服务商CloudFlare刚刚经历了一次重大的事故,DDoS新策略导致DNS服务集群失效,影响持续了一个多小时。虽然事故的原因很简单,但如何避免类似事件发生,国内的相关企业和用户可以从中得到哪些启示,CSDN搜集了多方观点。

【CSDN综合编译】3月3日, CloudFlare经历了过去四年间第三次严重的事故。UTC时间9:47(北京时间3月3日17:47),CloudFlare的边缘路由器发生故障,这导致使用CDN和安全服务的785000多个网站受到影响。约30分钟后故障被排除,事故持续影响了一个多小时。

CloudFlare的联合创始人及CEO Matthew Prince在事故当天就通过 blog对事故进行了分析,并向用户道歉。从广泛的评论来看,主流舆论对于此次事故还是报以宽容和理解,对CloudFlare的勇于认错的态度和快速的行动进行了肯定。

据TechCrunch 报道,中国是除美国本土外CloudFlare的最大市场,尽管此次事故在国内也引起了大量讨论,但还没有商业用户的抱怨声音(企业用户每月需支付3000美元)。

去年四月,CloudFlare的月PV达到400亿,目前这个数据已经达到1000亿。CloudFlare帮助网站节省带宽、提高访问速度,并过滤恶意攻击。

什么引起了事故?

Matthew Prince在blog上表示(编译来自 36kr):

CloudFlare 的管理团队发现一处DDoS攻击,监测工具显示攻击包大小在 99971 ~ 99985 bytes 左右(正常包大小是 1500 bytes,通常都在 500 ~ 600 bytes),于是将其规则加入 Juniper 的 Junos 防火墙设置中,不过预期大小的包并没有被拦截,因为实际上并不存在这么大的数据包,取而代之的是匹配规则的数据包冲刷到内存中,直到内存耗尽,系统崩溃。

通 常系统崩溃会自动重启而恢复工作,但这次例外了。由于系统没有正常启动,管理端口没有响应控制,于是 CloufFlare的管理中心只能电话通知全球 14 个国家的 23 个数据中心的管理员硬启动机器,这个过程大概花费了 30 分钟。最早恢复的数据中心由于负荷了最多了访问流量,仍然导致了 CloudFlare 服务的不稳定性,加上等待 DNS 缓存更新等,服务恢复时已经影响已持续超过 1 小时。

我们学到了什么?

网络技术工程师 IKE123在微博上评论:

1、主因:flowspec的bug引起的加载filter的时候导致的内存泄露。
2、Crash以后未能自动重启,所有收到该flowspec路由的边缘设备全玩完。
3、非架构问题,所以SDN/Openflow不会更好。
4、软件都有bug,这只是flowspec用的少,才有低级错误,不过换SDN估计更差(使用案例更少)。
5、ISP玩PCEP(路径计算单元通信协议)。

他特意向CSDN澄清:SDN和这次事故无关,只是有人提出来说SDN能有帮助。他认为:ISP骨干应该用PCEP,而不是Openflow。 PCEP是集中计算RSVP TE(基于流量工程扩展的资源预留协议),下发到设备上。Google是大驱动因素。

蓝盾股份是国内提供类CloudFlare服务的公司之一,该公司负责应用安全产品线研发总监 余志刚告诉CSDN:

我最近研发的产品是 云防线,技术架构与CloudFlare类似。

CloudFlare 这种技术架构中DNS服务集群充当的是全局负载均衡、智能路由的角色,而其他的分数据中心的运作都将依赖全局的DNS智能集群,如果这个中心集群宕机,将导致整个系统瘫痪,哪怕分中心无任何问题,数据流量也将路由不到。

通过分析官方blog的内容,我猜测CloudFlare 的DNS应该是有热备的,但可能这两套系统都在这个核心路由器后面。路由器出问题后导致两套系统都无法访问。

余志刚认为,这次事故反映出这种基于SaaS概念的安全系统需要完善一下几个方面:

1、加强全局负载均衡,也就是DNS智能集群的安全防护及运营水平。
2、在财力允许的情况下,尽量建立DNS智能集群的备份系统,两套系统做到热备。
3、将用户管理系统也就是www.cloudflare.com这个网站管理系统和核心系统分开,当DNS智能集群宕机,无法为用户网站提供加速、防护服务后,保证管理系统能正常使用,然后给用户提供快速切换到原有DNS解析服务器的选项。

陈利人认为:

CloudFlare CDN加速的原理:当用户访问已经启用CloudFlare CDN加速网站时,首先通过DNS重定向技术确定最接近用户的最佳CDN节点,同时将用户的请求指向该节点。当用户的请求到达指定节点 时,CloudFlare的服务器(节点上的高速缓存)负责将用户请求的内容提供给用户。说白了,就是基于DNS的负载均衡。

在Hacker News上对此次事故有着疯狂的 讨论

“如果你将Juniper和Cisco的设备放在一起,那么就会产生很多奇怪的问题。”

“最好不用只使用一家供应商。”

“Junos的更新速度显然慢了。”

“任何设备都不能保证网络万无一失。”

敏捷开发者、趴猫网 创始人 王龙

自己运营的主打产品不要用任何第三方的产品,金窝银窝不如自己的草窝,所有东西自己来搭建,框架用自己开发的,平台用自己运维的,服务器用自己的,插件自己来写,CDN自己搭建,云架构自己部署,就不会出现这种由于第三方问题出现的问题,起码问题是可控的。

行人23

电话14个国家23个数据中心管理员只需要30分钟,放到国内厂商需要多久呢?

wanght1979

作为刚刚从机房出来的苦逼,深刻理解其困扰。

如果你有任何观点,不妨在评论中告诉我们。

国内的类CloudFlare市场

在国内, 安全宝、 知道创宇和云防线都提供类CloudFlare的服务。国内两大CDN 服务商网宿和蓝汛这块业务跃跃欲试,电信运营商已经参与这个市场。尽管市场竞争非常激烈,但和所有其它云计算服务一样,用户的 接受程度还很低,“目前来说用户对这种SaaS概念的安全服务接受程度还比较有限。随着发展,SaaS服务慢慢被大家接受,这肯定是未 来安全行业发展的方向”,余志刚表示。(文/ 包研  责编/仲浩)

参考信息: Techcrunch  CloudFlare  36kr

关注 @CSDN云计算微博参与讨论,了解更多云信息。

相关链接:http://www.csdn.net/article/2013-03-04/2814337-rethink_of_CloudFlare_down

版权信息:原创文章:云防线
本文链接:http://blog.cloudfence.cn/?p=464转载请注明转自云防线
如果喜欢:点此订阅本站