OVH遭遇服务器冷却液泄漏事故 导致长达24小时服务中断
近日，一套外部水冷系统发生冷却液泄漏事故，直接导致OVH公司在巴黎数据中心内的一台戴尔-EMC VNX存储阵列遭受损坏，进而引发超过5000个网站在接下来的24小时内无**常访问。冷却液泄漏给该公司位于巴黎数据中心内的VNX阵列带来灭顶之灾。http://p3.pstatp.com/large/2f83000ddc11a1a69d40
OVH遭遇服务器冷却液泄漏事故 导致长达24小时服务中断
OVH公司为目前全球第三大互联网托管厂商，其在世界17个国家拥有20座数据中心以及多达26万台服务器，其中托管着约1800万款Web应用程序。
此次事故发生于6月29日晚7点左右，直接影响到OVH公司位于巴黎的P19数据中心——这亦是该公司于2003年建立的首座数据中心。不过其规模随后被位于格拉沃利纳的新数据中心所超越，后者为目前欧洲最大数据中心，部署有约40万台服务器。
OVH公司在其P19数据中心之内采用自主研发的水冷解决方案。冷却液经由服务器机架及其它部件通过组件级热交换装置进行循环冷却，且与顶架式水箱热交换装置相对接。在完成一轮循环后，其与地下水进行热交换以实现自身冷却。这套方案能够有效替代以空调系统为核心的风冷机制，从而节约大量电力。
http://p3.pstatp.com/large/2f85000a7ea0281d534d
OVH遭遇服务器冷却液泄漏事故 导致长达24小时服务中断
OVH公司机架水冷系统
根据事故记录显示，P19数据中心亦在地下室内部署有多台设备，负责通过外界空气实现冷却效果。
OVH公司于2012年从EMC手中购买了数台VNX 5400阵列。此次发生事故的阵列在其三台机架当中装有96块SSD、15套本地磁盘架以及标准的主动-主动控制器对。该公司表示：“这套架构的设计目标在于确保数据的本地可用性以及数据控制器与磁盘的强大容错能力。”
在此之后，该公司又陆续开发出新的解决方案，其被应用于格拉沃利纳数据中心，能够通过非专用商业阵列配合Ceph与ZFS以摆脱对专用设备的依赖。事实上，此次受到影响的阵列原本也已经被纳入清退计划。这两台VNX阵列作为数据库服务器使用，负责为托管网站的动态页面提供数据、用户相关信息以及博客平台中的文章文本与评论内容。
根据事件报告撰文，“6月29日星期四下午6:48，P19数据中心内的3号机房中，由于水冷系统的塑料软管发生破裂，因而导致冷却液泄漏至服务器系统之内。”
“我们两套专用存储托架（机架）中的一套并未使用水冷机制，但由于位置毗邻而受到影响，并直接引发电气故障，最终造成该托架彻底关闭。”
OVH公司承认其将两种采用不同冷却机制的服务器安装在同一机房之内是个错误。“我们做出了错误的判断，我们本应为这些存储设施提供最大程度的保护，正如我们在其它站点中所做的那样。”
故障，又见故障
在此之后，音频警报系统内发生的故障则更为复杂。能够检测机架内液体的探针确实在整座数据中心之内广播了音频警报消息。然而由于此前未能成功为该系统添加多语言支持功能，因此其警报时间点相较泄漏事故出现了延迟，并最终造成长达11分钟的时间间隔。
当天晚6：59，工作人员尝试重启该阵列。当天晚9：25，工作人员未能成功完成重启，并决定采取双管齐下的处理方式——继续尝试重启该故障阵列（A计划），同时尝试利用备份将其数据恢复至辅助系统（B计划）。
A计划
当晚8：00，OVH方面向戴尔-EMC公司拨打求电话，并最终完成了阵列重启。然而，运行20分钟后由于安全机制被触发，阵列再度陷入停止状态。面对这样的情况，OVH公司技术人员决定从法国鲁贝数据中心内选定第三台VNX 5400阵列并将受影响设备上的磁盘驱动器转移至新机架当中，从而替换发生故障的电源模块及控制器。
来自鲁贝数据中心的这套系统于次日清晨4:30被运送至巴黎数据中心，6：00全部磁盘驱动器转移完成。同日早7：00，替代系统启动完成，但遗憾的是磁盘上的数据仍然无法访问。OVH于早8：00再次联系戴尔-EMC技术支持人员，并申请了现场服务。
B计划
B计划使用的资源来自一套日常备份方案，OVH方面指出“这是一套全局基础设施备份，属于我们业务恢复计划中的组成部分，而非客户能够直接访问的数据库快照。”
“进行数据恢复不仅意味着需要将备份数据由冷存储介质迁移至共享托管技术平台中的空余空间内，同时说需要对整体生产环境进行重建。”
具体来讲，为了完成数据恢复，OVH公司需要：
在P19数据中心之内从现有服务器上找到充足的可用存储空间。
迁移整套支持服务运行环境（即负责运行数据库的虚拟机、相关操作系统、其特定软件包以及配置文件）。
将数据迁移至新的托管基础设施当中。
这一流程此前虽然进行过基础测试，但却从未以高达5万个网站的规模进行实际操作。整个流程通过脚本实现，且直到次日凌晨3：00，虚拟机克隆工作才正式开始进行。
次日早9：00，已经有20%的实例得以恢复。时间继续推移，“次日晚23：40，最后一个实例的恢复工作终告完成，所有用户皆可正常访问其站点。惟一的问题在于，部分用户原本托管的MySQL 5.1实例被恢复成了MySQL 5.5版本。”
后见之明
很明显，受影响阵列的灾难恢复流程并不顺利。而且尽管OVH公司的技术支持人员表现出色，但这种状况本可以得到避免。
VNX阵列被安装在了错误的机房当中，除此之外，其还缺少必要的故障转移规划。事实上，主动灾难恢复计划与测试并未能起到应有的作用。
与受影响用户间的沟通亦饱受诟病，OVH公司的表现相当消极。“作为事件的起源，水冷系统冷却液泄漏让我们彻底陷入了恐慌。” 前排观望。。。。。 能不能发原文，看着别扭。 大机房也不容易啊... 错误总是难免的。 以目前来看，油冷才是解决问题的最终方案。
static/image/smiley/yct/003.gif
字太多 懒得看
页:
[1]