尽管这次瘫痪不同于Amazon用户所经历的那次（P.S. 亚马逊云计算中心宕机 多站蒙损），但是日前VMware的Cloud Foundry发生的存储基础设施的故障仍然让多数用户感到冒莫名其妙——为什么无法登陆控制面板并执行vmc指令？由云控制器（Cloud Controller）的设置导致的故障致使用户无法启动和停止应用，无法创建新实例、也无法通过vmc命令行工具或Eclipse IDE与之交互。不过很明确，正在运行的应用实例未受影响。

发布于本月初的VMware Cloud Foundry集（运行在VMware vSphere上的）托管PaaS服务(cloudfoundry.com)和开源开发环境(cloudfoundry.org)于一体。Cloud Foundry支持（Java开发者使用的）Spring、Rails、Sinatra和Grails等框架。该项目由VMware资助并托管，整个cloudfoundry.com目前处于beta阶段，在此阶段结束前免费向用户开放。

有别于Amazon，VMWare在Cloud Foundry支持网站和Twitter上每个小时通报一次状态更新，让其用户随时了解问题的最新进展。昨天上午，一个Twitter用户帖出一则消息：“有没有人在执行#cloudfoundry vmc命令时碰到404错误，这种情况是几分钟前开始的。”随后，Cloud Foundry发Twitter：“我们碰到一个问题。应用还可以继续运行，但是与应用的连接却断断续续。”事发几个小时之内，Cloud Foundry支持网站上即发出如下消息：

通知：我们正在持续解决CloudFoundry.com服务的一个存储故障。该故障影响用户登录和管理其应用，但不会影响到正在运行的应用实例。我们将每小时一次地持续发布该故障解决的最新进展。

接下来的更新表明，问题已经找到并且预计系统将于PDT时间12：30恢复运行，但是应急处理小组错过了这一时间点，他们解释道：

存储基础设施中的故障已经找到而且解决了，但是将系统安全地恢复到全功能的运营状态，确保并验证无数据丢失发生，却是一个缓慢的过程，

当天下午InfoQ采访了VMware应用平台高级总经理Jerry Chen，他对这一故障做了确认——用户无法登录vmc命令行工具执行命令。Chen说：

我们向用户每小时一次地持续更新故障解决的最新状态，直到PDT时间下午4点故障最终解决为止。我们感到欣慰的是用户能够透明地获得我们的更新。近期我们还会针对此次故障发布更多信息。

最后的解释指出问题出在云控制器（https://github.com/cloudfoundry/vcap/tree/master/cloud_controller）上。据Ezra Zygmuntowicz发表的博文，"云控制器是系统的大脑"。它是一个Async Rails3应用，对外公开REST接口，命令行工具vmc通过该接口访问云控制器；另外，开发者通过Eclipse的STS plugin访问云控制器。昨天的某个时刻，我们发现云控制器被设置成了只读模式，导致用户无法登录、启动和关闭应用、创建新应用、通过vmc命令行工具或Eclpse IDE访问系统。Cloud Foundry还解释：

正在运行的应用不受此影响，但是若这些应用奔溃了，Cloud Foundry的自治愈功能会受到影响。健康管理器组件https://github.com/cloudfoundry/vcap/tree/master/health_manager将不能执行正确的恢复动作。

明显，beta项目存在若干待解决的缺陷。前日故障之后的第二天cloudfoundry.com和cloudfoundry.org又停用了一个多小时。这一停用与用户抱怨“所有应用都被重定向到同一网址”相符。公司最初的报道是：

我们的数据中心出了点问题。我们将尽快解决问题，抱歉给您带来不便。

不久之后，支持网站再次发表声明，表示Cloud Foundry正在维护之中，因为“需求量大”所以正在扩容。说到底Cloud Foundry仍然处于beta阶段，过去的这两天里，提供项目托管服务的人们一定吸取了很多教训。可是，用户们却无能为力，他们只能看着、等着，期待其数据依然完好无损。对于那些希望深入了解此次事件的人，有几篇很好的文章经验总结：今天的EC2/EBS停用可以参考，建议阅读《亚马逊云计算服务故障之七大教训》。

正如最近发生的事件告诉我们，即便是很小的宕机时间，都能对组织/企业带来巨大影响；至少，当今每个IT组织都应该做好故障应对的计划。