Amazon的EC2 服务器停转事件将当下故障切换系统的局限性推向风口浪尖，但Amazon并不是惟一无法保证云服务正常工作率达到100%的供应商。
上周发生的Amazon EC2服务器停转事件，再次为当今所采用的保障应用程序正常运行的负载平衡及故障切换系统的功能局限性敲响了警钟。但Amazon只是个突出的例子，在云服务供应商中，任何一家都无法保证自己的系统能够提供100%的正常运行率。
构建以云技术为基础的应用程序时，要实现当某座数据中心发生故障时，所有应用功能都可以及时由其它运行正常的中心来提供，这一要求不仅是对供应商技术力量的挑战，同时可能也要求客户具备良好的技术支持团队。因为客户必须与云供应商紧密协作并购置第三方出品的负载平衡产品来保证当类似Amazon事件发生时，相关的应用程序仍能正常运行。
GoGrid，这家公司以一种与Amazon类似的形式提供基础设施即服务（简称IaaS）计算，并且向消费者做出了一系列当数据中心出现故障时的承诺。但是这并不意味着整套云服务体系绝不会出现当机情况。
“对于我们所提供的服务来说，我们希望能够使其好评率达到100%，并且不会发生有损双方利益的事故，”GoGrid公司创始人同时也是现任CEO的John Keagy说道。“而一旦事故发生了，客户不应该把100%的好评率解释为100%的正常运行率。”
但消费者仍然能够通过部署一些灾备措施的方式，来保障其应用程序在发生服务器停机事故时仍能正常运作，Keagy说道。那些没有做过任何事故恢复及故障切换准备工作的Amazon客户，在上周的停机事件中所遭受的损失很可能远远大于那些做过相关准备的客户，他说。
GoGrid公司的云服务产品部署在十一座数据中心当中，而其主要负载以主机代管的形式实现。客户们希望在灾难性事件发生时自己的应用程序支持可以由一个数据中心切换至另一个的愿望，能够借助第三方公司提供的全局流量管理产品来实现，Keagy说。客户还可以通过与GoGrid公司所提供的增值服务来对自己的应用部署这套完整的保护方案，但“必须与我们协同进行构建工作，”Keagy说。
“这就是关于必要的基础设施的全部内容，”Keagy说道。“这跟服务器类的运行平台或是软件不同，这是从基础设施的源头上进行改造，需要使用者对整套执行体系有一定的了解。”
Amazon的方案是将客户的主机应用程序部署在多个“资源供应区”内来应对局部故障，但这些区域彼此之间的距离到底有多远、是否真的能立即提供切换并保持应用流畅还是未知数。至少从上周的情况来看，多个“资源供应区”这套方案彻底失败了。
虽然包括Foursquare，Reddit，Quora以及Hootsuite在内的许多站点相继发生断线事故，但SmugMug这一照片分享网站的成功经验表明了做好预防工作确实能够帮助客户成功应对故障。上周的Amazon事件，SmugMug公司的CEO Don MacAskill将其称为“Amazon启示录”。
SmugMug将其服务分别部署于三个资源供应区中，并且决定不采用Amazon的“弹性模块存储”方案，因为其“性能无法保证且耐用性不理想，”MacAskill在他的博文中写道。而数据存储服务在上周的大崩溃中需要承担主要责任。
如果大家打算将自己的关键性应用服务依靠云技术实现，MacAskill的建议是应将其分散部署于Amazon各地的机房（包括东海岸及西海岸等）或是干脆采用多家云服务供应商。
Amazon的负载平衡服务无法在跨地区的前提下正常发挥作用，因此客户必须亲自做一些额外的工作，并依靠引入第三方软件的办法来彻底实现该保障方案，Gartner公司的分析师Drue Reeves说。然而，将应用程序分散部署在多家服务供应商那里虽然不是不可能，但也难度极大，因为各供应商的服务之间缺乏一套统一的标准和交互操作规范。
Rackspace公司，另一家基础设施即服务供应商，最近开始提供云负载平衡服务，借以在某台服务器失效时，保护其上的特定应用程序。但是负载平衡工具的运作机理并不是将信息分别部署在不同的数据中心当中。
Josh Odom，Rackspace公司云平台产品开发的负责人，指出将应用程序运行于多个数据中心以保证100%的正常运行时间是最理想的，而Rackspace公司正在尝试使客户能够更容易地利用第三方的负载平衡工具及故障切换机制来达成上述目标。***的挑战并非来自应用程序本身，而是来自数据，Odom说。“任何与相关数据库系统有联系的数据库复制工作都是相当麻烦的，”Odom说。“而我们所做的正是尽量清理这类阻碍。”
Rackspace公司部署于德克萨斯州的数据中心曾于2009年遭遇了一些电力供应中断状况，这迫使该公司不得不向客户做出信誉承诺。此后，公司引入了新的数据中心管理专家，并对低端以及高端的全部设施进行了重新审核，Odom说道。不管过去发生了什么样的问题，Odom说，如今Rackspace公司的数据中心已经被设计为专门抵御“灾难性故障”，包括主要供电中断以及网络问题。
虽然基础设施层面上的事故恢复规划对技术水平有所要求，但并不是所有的云服务都需要配备专门的管理人员。平台即服务产品——例如微软的Windows Azure或谷歌的App Engine——旨在尽量减少基础设施的介入，并为开发人员提供一个相对简单的方式来建立并托管网页应用程序。
然而负载平衡以及数据中心之间的故障切换体系对于平台即服务这类云产品仍然具有巨大的积极意义。
微软近来公布了一款名为“微软Azure流量管理器”的工具，据说它将使“同一款应用程序的开发过程以拓扑形式环状部署于各数据中心当中，并构成故障切换及负载平衡功能的基础。”Azure流量管理器目前仅在某个社区中展示技术预览效果，这意味着它并不能为每一类客户提供帮助。虽然Windows Azure流量管理器将流量分布在不同的数据中心中，但SQL Azure数据同步工具，同样处于测试阶段，能够复制“不同数据中心中的数据库信息以防止资料在直接传输过程中的丢失，”微软如是说。
开发人员Rober McLaws在Twitter上发布文章称，即使没有Windows Azure流量管理器，客户们仍然能够为自己的应用程序构建起数据中心之间的故障切换机制，只要我们“事必躬亲地进行管理”。
谷歌的App Engine服务能够将应用程序及数据从一个数据中心转移到另一个，而不会在故障发生时造成数据丢失或是当机，谷歌产品经理Greg D’alesandre说。谷歌没有透露该种切换是否对数据中心之间的距离有所限制，但他说：“该系统的设计使单一地理区域内的主机故障不再产生影响。”
而与此同时，Amazon方面被指责没有为上周的事件提供详尽的故障说明。Amazon将其归咎于“网络问题”，即“由大量的镜像引用所造成的”存储量，引发了短暂的服务中断，并导致虚拟机无法连接。
Thorsten von Eicken，RightScale公司的创始人及CTO，曾为Amazon EC2提供过功能强化服务，而对于上述事态，他的意见是Amazon在公关交流水平方面“只得了F”，并且完全没有提供一套深层次的事故原因分析。
原文名：Cloud failover a challenge for Amazon competitors, too 作者：Jon Brodkin
【本文乃51CTO精选译文，转载请标明出处！】
【编辑推荐】
- 使用Microsoft Azure 让云迁移变得简便的5种方法
- VMware的混合云迁移工具：vCloud Connector
- 企业CRM等业务系统迁移到 "云"中的***实现
- 云计算该“迁移”还是“自建”?
- 云迁移全攻略：哪些应用适合迁移
- 亚马逊 谷歌 微软三大试用云服务大比拼（上）
- 亚马逊推出1年免费云计算服务
- 亚马逊EC2中断 “可用区”遭质疑
- 从亚马逊云服务故障中吸取的七个教训
