VMware也遇云计算中断 恢复工作导致二次宕机

VMware公司证实称，他们在试图恢复其中断的全新云计算服务时，意外造成了第二次宕机。

距离被广泛报道的亚马逊弹性计算云宕机事件不到一周的时间，VMware公司目前仍处于测试阶段的全新Cloud Foundry服务便于上周遭遇了两天停机事故。

于4月12日正式推出的Cloud Foundry是一款“平台即服务”（PaaS）解决方案，专为云计算环境、企业级数据中心和公有云服务提供商所打造。通过它这个托管环境，可以建立运行Web应用程序。但就在上月的25和26日，Cloud Foundry连续两天都发生了云“服务中断”故障。

第一次故障是由一个存储柜的电供应停止所导致的。虽然应用仍然在线，但开发者已不能进行最基本的操作，例如登录或创建新应用。该停电事故持续了近10个小时，于当天下午整修完毕并恢复了服务。

然而就在服务恢复的第二天，VMware一官员在进行前期检测以防止前一天的事故再发时，意外造成了第二次的云服务中断事故。

VMware官方发言人Dekel Tankel解释称，“4月25日的停电事故是偶尔会发生的”。他还表示，VMware已经确保其软件，监控系统和运作模式足够稳定，使其能防止这种由停电导致的用户系统下线。

考虑到这一点，VMware公司于第二天（也就是26日）便开始部署了“一套全面用以实施前期检测、预防及恢复的方案”。

Tankel在声明中写道，“4月26日早八点，根据详细的指导我们开始了方案的实施，预计在中午由我们运营及工程组的同事进行正式评审。这个方案本应仅在理论上应用，我们原计划在不触动键盘按键的前提下进行部署练习，直至审查工作完成。不幸的是，在上午10点15分时，团队中一位运营工程师触动了键盘。这直接导致了Cloud Foundry整个网络基础设施的中断。此举令所有的负载平衡器、路由器和防火墙都失灵了，导致我们内部部分DNS基础设施停止工作，最终造成Cloud Foundry与外部链接完全中断。”

第二天故障的情况比第一天更加糟糕。Tankel表示："这是我们首次遭遇整体宕机，此次事故尤为严重，我们需为此建立维护页面。在宕机过程中，所有的应用和系统部件仍在持续工作。然而，由于前端网络中断，只有我们清楚系统出了问题。直到上午11点半，前端网络才完全恢复运行。"

VMware第二日的事故属于云端网络操作中的人为失误，这也与之前亚马逊云服务中断的根本原因分析相一致。在亚马逊中断事件中，系统升级过程中的错误导致宕机，亚马逊花费了多日才得以将故障修复。

相关阅读：带您揭开亚马逊云服务中断的幕后之手

http://server.zdnet.com.cn/server/2011/0426/2032247.shtml

英雄难过"安全"关 盘点云计算安全事故

http://server.zdnet.com.cn/server/2011/0504/2033465.shtml

虚拟化和云基础架构厂商VMware是服务器虚拟化市场的领头羊，但在提供公有云服务领域上还算是一个新手。在此之前，VMware也向用户及服务提供商出售其技术，帮助他们构建自己的“云”计算。

万幸的是，由于Cloud Foundry是新近的业务应用，所以此次事故对于用户的影响远不及先前亚马逊的中断事件。那次由于亚马逊云服务的中断，导致众多依赖亚马逊基础设施的网站中断服务。不过此次事故也让VMware尝到了身为服务提供商的苦头，毕竟一次宕机故障就足以造成部分客户流失。