震彻“云”霄:详谈Amazon“云事件”始末(上)

日期: 2011-05-08 作者:Carl Brooks翻译:滕晓龙 来源:TechTarget中国 英文

Amazon网络服务的中断事件暴露了用户对在线服务的期望与云计算实际运行交付能力之间深深的鸿沟。   如果你的系统在本周的Amazon云计算中发生故障,那并不应该由Amazon公司来承担责任。   有一个戏剧性的场景值得我们思考,那简直就是上个世纪那场电信危机的一个缩影:Amazon公司的冗余弹性块存储(EBS)的服务中断事件不仅涉及诸如Reddit之类的热门网站,而且还殃及Heroku等没有备用资源的互联网服务供应商。   “问题在于我们没有可供托管数据库或其它任何资源使用的替代场所,”Architectural Overflow公司的CEO Lee Buescher说,Architectu……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

Amazon网络服务的中断事件暴露了用户对在线服务的期望与云计算实际运行交付能力之间深深的鸿沟。

  如果你的系统在本周的Amazon云计算中发生故障,那并不应该由Amazon公司来承担责任。

  有一个戏剧性的场景值得我们思考,那简直就是上个世纪那场电信危机的一个缩影:Amazon公司的冗余弹性块存储(EBS)的服务中断事件不仅涉及诸如Reddit之类的热门网站,而且还殃及Heroku等没有备用资源的互联网服务供应商。

  “问题在于我们没有可供托管数据库或其它任何资源使用的替代场所,”Architectural Overflow公司的CEO Lee Buescher说,Architectural Overflow是一家向全美各地建筑商和建筑公司销售建筑蓝图和提供建筑规划服务的公司。

  Buescher在Heroku基础上构建他们的业务,Heroku为其提供了一个不需要Buescher运行或维护该公司本身拥有服务器的应用程序平台。他表示,直至上周发生事件之前,相关服务的所有便利性和成本效益都是物有所值的。

  现在,他的信心已经开始了极大的动摇,Buescher表示他仍十分看好云计算,只不过是错误地对Heroku在实际运行能力方面产生了过于单一的依赖性。但是云计算开发平台却因为此次其供应商Amazon网络服务(AWS)所面临的危机而获益匪浅。

  “我错误地认为他们知道他们正在做什么,”Buescher说,“我从未遇到过停机时间如此之长的服务中断事件。我曾使用过其他的应用托管服务,但从来没有这样的中断服务事件。”

  他补充道,由于他本人拥有数据中心运营的背景,他对Heroku所遭遇的麻烦和AWS经营者不得不修复这些级联故障均表示了深深的同情。与此同时,还有一些尚不为人知的东西。

  “我深知那些工作人员正通宵达旦地修复故障,因此我被他们感动,”他说,“但与此同时,由于我正为该服务支付费用,所以我希望它能正常运行。”

  Buescher说,他正在积极地寻觅Heroku的替代者,包括托管他自己的服务器和一个针对他的应用的灾难恢复计划,但他目前主要是在等待Heroku宣布如何防止类似的服务中断事件再次发生。他目前最关心的是客户与供应商之间缺乏沟通的问题。

  Buescher是众多在线服务的用户之一,例如ERP软件即服务(SaaS)NetSuite和协同服务37signals.com。但当事件发生时他们对用户们的考虑呈现了极为不同层次上的考虑。

  “当他们发生中断事件时,他们会积极地进行沟通,即使他们的东西并不是客户的关键业务,”他说。

  Amazon用户表达了对服务中断事件的愤怒

  Buescher(和其他许多用户,从Amazon技术支持论坛和社交媒体网站的评论和反应来看)对Amazon公司在服务中断事件期间缺乏补偿而感到极大的不满。他说,每个人都会遇到中断事件——这就是我们所身处的现实世界——但是不确定感和缺乏沟通则是令人非常沮丧的。他补充说,他并没有真正理解为什么他从其他服务供应商得到的客户响应等级和他试图提供给他自己客户的响应等级并不适用于AWS。

  这一不确定性导致了一些AWS客户采用某些怪异把戏来引起别人的注意和AWS对其的支持:一个用户发帖子说,此次服务中断事件是一次医疗紧急事故,有可能对数百名心脏急症病人造成潜在的生命威胁。

  “对不起,我无法采用任何其他的方法来达到目的,”后续帖子中如是写道。该用户表示,他们在AWS上运行了三个实例来监控数以百计家居患者的ECG信号,但自从4月21日以来就无法再看到这些信号了。

  这一令人震惊但漏洞百出的帖子却招致其他用户对AWS猛烈的口诛笔伐。医疗IT系统,特别是那些有可能涉及威胁生命的系统,都是采用了具有极高冗余性和可用性的标准;用户本可能对犯罪持无所谓态度。此后该用户退而宣称监控应用是至关重要的,或者患者可能已身处危险之中,但这一戏剧性的事件凸显了用户在服务中断事件期间由于缺乏来自于AWS的响应而感受到的绝望情绪。AWS的工作人员并未对用户最初的支持请求做出反应。

  其他用户在Amazon的论坛上讨论可供替代的供应商和服务,如Rackspace和Azure等。大家达成的共识是,可行的方案可能都缺少对妥善业务处理支持的要素。

  “比较明智的做法,Azure比较接近于AWS”在线协作服务NextSlide的CTO Stephane Legay说,“他们把排队、存储、CDN、关系型数据库作为一种服务,把分布式缓存作为一种服务,计算节点、EBS(Azure 驱动)和现在已解决的视频流,而通常来说微软对这些服务的支持相当好。”

  在服务中断开始之后的几乎一周时间里,对于AWS如何处理该故障的困惑和失望仍旧是一个问题。Amazon在其状态页面(顺便说一句,该页面运行于Amazon.com上;零售巨头的网站不会在AWS的云计算上运行)公布了其详细的常规报告,但还未作出有关该问题的公开声明,在其12小时的运行高峰期间,有可能已导致数以千计的网站和业务无法正常运行。

  云计算管理服务供应商RightScale的CTO和创始人Thorsten von Eicken在一篇博客中对这一状态更新的情况提出了批评。他说,在某种程度上,他们帮助RightScale对这一危机做出了次优的决策。

  “事后回想起来,我们本应当在事件早期就有意识地使我们在‘可用性受影响区域’中运行的主数据库停机,”他说,“但是Amazon并没有提供足够的详细信息来帮助我们做出这一决定。”

相关推荐