当前位置:云计算企业动态 → 正文

人为失误导致AWS S3的US-EAST-1区服务宕机

责任编辑:editor005 作者:Abel Avram |来源:企业网D1Net  2017-03-08 16:03:49 本文摘自:infoq.com

由一次失误引发的连锁反应导致了很多S3服务器宕机,其中包括两个影响S3运行的关键子系统。由此导致了S3的故障,影响到了不仅S3本身还有其他一些依赖S3的服务。四个小时后S3才重新恢复正常。

Amazon AWS故障十分罕见,一旦发生整个因特网都能感受得到,不少服务会直接受到影响。近期这次故障于2月28日发生在北弗吉尼亚地区(US-EAST-1)。不仅S3运行瘫痪了,而且波及一系列依赖S3的AWS服务,包括EC2、EFS、API Gateway、Athena、Cloudsearch、MapReduce等。这些服务要么是在功能上出现大量错误,要么是完全无法工作。

在四个小时的瘫痪期间,据报告有不少企业服务下线或是受到严重干扰,包括Expedia、GitLab、GitHub、GroupMe、IFTTT、Medium、Nest、Quora、Slack、The Verge、Trello、Twitch、Wix等。就连Amazon自身的Alexa也出现故障了,导致AWS状态仪表盘有两个小时未实时更新。Amazon借助Twitter发布错误报告,期间他们只得为状态页面临时添加一个手工编辑的横幅。

Amazon事后给出了对该次事件分析的诊断报告。当时有一个Amazon团队正在调试S3的计费问题,有人想要输入一条命令,从S3的一个计费子系统中删除一小部分服务器。但是这个工程师输入了错误的命令,导致了大量的S3服务器关闭,包括两台在另外两个子系统中起关键作用的S3服务器。其中一个子系统是为整个区域的S3提供索引服务的,影响到GET、PUT、LIST和DELETE命令;另一个子系统用于S3部署,涉及新对象的空间分配。因为这两个子系统停止工作,S3的功能产生了大量错误,影响到很多用户。

虽然AWS具备快速恢复单个子系统故障的操作规程,但是由于索引子系统已经有数年从未重启过,索引已增长得十分庞大,因此还是需要相当长的重启事件。虽然功能最终得以恢复,但是比预想的要慢。Amazon已经计划今年稍后会对索引子系统进行分区,将索引分区为更小的块,使得重启更加快速。现在他们已经立刻着手进行分区,为将来可能发生的瘫痪情况做好准备。他们对工具做了修改,限制了每条命令可以关闭的服务器数量,还限制使用单个命令关闭整个子系统。他们还将在多个区域实现分布式的S3仪表盘,以确保在一个区域停止服务时仪表盘依然保持工作。

Amazon在2011年曾经历过一次瘫痪,也是发生在US东部区域,那一次瘫痪了4天时间。从两次故障中学习到的并得以应用的基本经验教训是,系统创建不应仅依赖在单一区域上,如果当前区域发生故障,可以切换到其他区域。Netflix已经这样部署了,其他系统同样也可以。但是这会增加网络主机服务费,企业总是倾向于尽量地降低费用。总体来说,Amazon AWS是可靠的,但是服务总不可避免会有瘫痪情况。所有云服务提供商皆是如此。

查看英文原文: A Human Error Took Down AWS S3 US-EAST-1

本文永久更新链接地址:http://www.linuxidc.com/Linux/2017-03/141532.htm

关键字:AWSUSTwitter

本文摘自:infoq.com

x 人为失误导致AWS S3的US-EAST-1区服务宕机 扫一扫
分享本文到朋友圈
当前位置:云计算企业动态 → 正文

人为失误导致AWS S3的US-EAST-1区服务宕机

责任编辑:editor005 作者:Abel Avram |来源:企业网D1Net  2017-03-08 16:03:49 本文摘自:infoq.com

由一次失误引发的连锁反应导致了很多S3服务器宕机,其中包括两个影响S3运行的关键子系统。由此导致了S3的故障,影响到了不仅S3本身还有其他一些依赖S3的服务。四个小时后S3才重新恢复正常。

Amazon AWS故障十分罕见,一旦发生整个因特网都能感受得到,不少服务会直接受到影响。近期这次故障于2月28日发生在北弗吉尼亚地区(US-EAST-1)。不仅S3运行瘫痪了,而且波及一系列依赖S3的AWS服务,包括EC2、EFS、API Gateway、Athena、Cloudsearch、MapReduce等。这些服务要么是在功能上出现大量错误,要么是完全无法工作。

在四个小时的瘫痪期间,据报告有不少企业服务下线或是受到严重干扰,包括Expedia、GitLab、GitHub、GroupMe、IFTTT、Medium、Nest、Quora、Slack、The Verge、Trello、Twitch、Wix等。就连Amazon自身的Alexa也出现故障了,导致AWS状态仪表盘有两个小时未实时更新。Amazon借助Twitter发布错误报告,期间他们只得为状态页面临时添加一个手工编辑的横幅。

Amazon事后给出了对该次事件分析的诊断报告。当时有一个Amazon团队正在调试S3的计费问题,有人想要输入一条命令,从S3的一个计费子系统中删除一小部分服务器。但是这个工程师输入了错误的命令,导致了大量的S3服务器关闭,包括两台在另外两个子系统中起关键作用的S3服务器。其中一个子系统是为整个区域的S3提供索引服务的,影响到GET、PUT、LIST和DELETE命令;另一个子系统用于S3部署,涉及新对象的空间分配。因为这两个子系统停止工作,S3的功能产生了大量错误,影响到很多用户。

虽然AWS具备快速恢复单个子系统故障的操作规程,但是由于索引子系统已经有数年从未重启过,索引已增长得十分庞大,因此还是需要相当长的重启事件。虽然功能最终得以恢复,但是比预想的要慢。Amazon已经计划今年稍后会对索引子系统进行分区,将索引分区为更小的块,使得重启更加快速。现在他们已经立刻着手进行分区,为将来可能发生的瘫痪情况做好准备。他们对工具做了修改,限制了每条命令可以关闭的服务器数量,还限制使用单个命令关闭整个子系统。他们还将在多个区域实现分布式的S3仪表盘,以确保在一个区域停止服务时仪表盘依然保持工作。

Amazon在2011年曾经历过一次瘫痪,也是发生在US东部区域,那一次瘫痪了4天时间。从两次故障中学习到的并得以应用的基本经验教训是,系统创建不应仅依赖在单一区域上,如果当前区域发生故障,可以切换到其他区域。Netflix已经这样部署了,其他系统同样也可以。但是这会增加网络主机服务费,企业总是倾向于尽量地降低费用。总体来说,Amazon AWS是可靠的,但是服务总不可避免会有瘫痪情况。所有云服务提供商皆是如此。

查看英文原文: A Human Error Took Down AWS S3 US-EAST-1

本文永久更新链接地址:http://www.linuxidc.com/Linux/2017-03/141532.htm

关键字:AWSUSTwitter

本文摘自:infoq.com

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^