OVH数据中心服务中断24小时 液冷：怪我咯？(2)

　　在此之后，音频警报系统内发生的故障则更为复杂。能够检测机架内液体的探针确实在整座数据中心之内广播了音频警报消息。然而由于此前未能成功为该系统添加多语言支持功能，因此其警报时间点相较泄漏事故出现了延迟，并最终造成长达11分钟的时间间隔。

　　当天晚6：59，工作人员尝试重启该阵列。当天晚9：25，工作人员未能成功完成重启，并决定采取双管齐下的处理方式——继续尝试重启该故障阵列（A计划），同时尝试利用备份将其数据恢复至辅助系统（B计划）。

　　A计划

　　当晚8：00，OVH方面向戴尔-EMC公司拨打求电话，并最终完成了阵列重启。然而，运行20分钟后由于安全机制被触发，阵列再度陷入停止状态。面对这样的情况，OVH公司技术人员决定从法国鲁贝数据中心内选定第三台VNX5400阵列并将受影响设备上的磁盘驱动器转移至新机架当中，从而替换发生故障的电源模块及控制器。

　　来自鲁贝数据中心的这套系统于次日清晨4:30被运送至巴黎数据中心，6：00全部磁盘驱动器转移完成。同日早7：00，替代系统启动完成，但遗憾的是磁盘上的数据仍然无法访问。OVH于早8：00再次联系戴尔-EMC技术支持人员，并申请了现场服务。

　　B计划

　　B计划使用的资源来自一套日常备份方案，OVH方面指出“这是一套全局基础设施备份，属于我们业务恢复计划中的组成部分，而非客户能够直接访问的数据库快照。”

　　“进行数据恢复不仅意味着需要将备份数据由冷存储介质迁移至共享托管技术平台中的空余空间内，同时说需要对整体生产环境进行重建。”

　　具体来讲，为了完成数据恢复，OVH公司需要：

　　在P19数据中心之内从现有服务器上找到充足的可用存储空间。

　　迁移整套支持服务运行环境（即负责运行数据库的虚拟机、相关操作系统、其特定软件包以及配置文件）。

　　将数据迁移至新的托管基础设施当中。

　　这一流程此前虽然进行过基础测试，但却从未以高达5万个网站的规模进行实际操作。整个流程通过脚本实现，且直到次日凌晨3：00，虚拟机克隆工作才正式开始进行。

　　次日早9：00，已经有20%的实例得以恢复。时间继续推移，“次日晚23：40，最后一个实例的恢复工作终告完成，所有用户皆可正常访问其站点。惟一的问题在于，部分用户原本托管的MySQL5.1实例被恢复成了MySQL 5.5版本。”

　　很明显，受影响阵列的灾难恢复流程并不顺利。而且尽管OVH公司的技术支持人员表现出色，但这种状况本可以得到避免。

　　VNX阵列被安装在了错误的机房当中，除此之外，其还缺少必要的故障转移规划。事实上，主动灾难恢复计划与测试并未能起到应有的作用。

　　与受影响用户间的沟通亦饱受诟病，OVH公司的表现相当消极。“作为事件的起源，水冷系统冷却液泄漏让我们彻底陷入了恐慌。”

　　二、分析、解读以及相关推测

　　远在欧洲的一场故障，也影响到了国内的从业人员。笔者看到，朋友圈里也是众说纷纭，褒贬不一，不同的人出于不同角度，给出了很多分析和结论。下面是笔者的一些分析。

　　1、这套液冷系统是OVH自己研发的，说明了什么问题？

　　关于OVH为什么采用液冷，笔者认为有几个原因：

水冷网www.shuileng.net报道在此之后，音频警报系统内发生的故障则更为复杂。能够检测机架内液体的探针确实在整座数据中心之内广播了音频警报消息。然而由于此前未能成功为该系统添加多语言支持功能，因此其警报时间点相较泄漏事故出现了延迟...