十个最严重的云断网故障及其教训

[摘要]导言:为了帮助企业避免在云服务中出现故障,《网络世界》网站提供了网站曾经历过的十个最严重的云服务中断故障以及我们能够从中吸取的教训。

【CNW.com.cn独家译稿】导言:为了帮助企业避免在云服务中出现故障,《网络世界》网站提供了网站曾经历过的十个最严重的云服务中断故障以及我们能够从中吸取的教训。

严重的云中断1:亚马逊Web服务中断。免除你乏味的网络维护工作是在云中做生意的主要卖点。但是他的缺点是:当你的云厂商例行性改变配置让你的业务中断的时候,你会束手无策。

这是许多亚马逊Web服务用户在今年4月经历的事情。当时,亚马逊北弗吉尼亚州的数据中心出现故障,完全无法使用。

这个故障是在网络升级期间发生的。当时,信息寻找可用的设备把自己作为备份嵌入到这些设备中时,一个错误路线的通讯移动把一连串的亚马逊EBS(弹性块存储)通讯量发送到一个重新镜像的风暴。这是一种反常的现象。这引起了一系列事件,最终导致亚马逊在美国东部地区的许多服务中断。

这个故障持续了大约四天时间。但是,在许多企业陷入困境之中的同时,Netflix等其它公司的排除了故障。生存的关键是什么?设计系统的时候就要考虑到这种类型的故障。

Netflix工程师在题为“Netflix从亚马逊Web服务中断故障中吸取的教学”的博客中称,我们的架构避免使用EBS作为我们的主要数据存储服务。我们依靠的SimpleDB、S3和Cassandra服务从而没有受到这次中断事故的影响。无国家的服务和可用地区的数据的多个冗余热拷贝是避免亚马逊Web服务云故障的关键。

考虑一下你必须是Netflix规模的企业才能保证安全吗?再考虑一下。帮助开发人员把通讯与其Web应用程序集成在一起的Twilio公司利用亚马逊的EC2服务托管其核心的基础设施。尽管如此,4月份的中断故障对它的稳定性几乎没有影响。

Twilio共同创始人和首席技术官Evan Cooke称,建立云的前提是假设这个网络将出现故障。我们围绕着主机能够并且将发生故障这个思路建立了一个基础设施。因此,我们不依赖于核心架构本身的任何一台机器或者一个组件。

严重的云中断2:Sidekick关闭。智能手机让你很容易在移动中访问自己的数据。但是,某些东西并不能因为名字中有“智能”二字而不会傻。例证:大约在2009年秋季发生的T-Mobile Sidekick中断故障。

还记得这次大惨败吗?微软拥有的Sidekick遭受了将近一个星期的服务中断,使用户不能访问电子邮件、日历信息和其它个人数据。后来,微软承认它完全失去了云存储的数据并且也许不能回复这些数据。微软的人员显然忘记了做备份。

这个技术从那以后也许已经发展了。但是,教训是相同的:当涉及到重要数据的时候,永远不要假设其他人将自动保护你。要保证你理解你的云提供商的灾难恢复设置。最好是制定独立地备份你的重要数据的计划。

AlertSite公司负责监视产品的副总裁Ken Godskind称,同样的运营规则甚至适用于云。使用云的机构不能仅仅假设因为它是在云中,业务持续性计划的全部责任已经交给了提供商。

本文导航责任编辑:崔楚楚 联系邮箱:cui_chuchu@cnw.com.cn




免责声明:

本站系本网编辑转载,会尽可能注明出处,但不排除无法注明来源的情况,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与本网联系, 来信: liujun@soft6.com 我们将在收到邮件后第一时间删除内容!

[声明]本站文章版权归原作者所有,内容为作者个人观点,不代表本网站的观点和对其真实性负责,本站拥有对此声明的最终解释权。