飓风桑迪:曼哈顿数据中心的灾难应急方案

译文
运维 系统运维 新闻
飓风、地震、海啸,当这些不可抗拒的自然灾害袭来时,我们的数据中心应该如何应对?作为运维人员的我们又将如何保护好脆弱的服务器?不久前飓风桑迪袭击了美国东海岸,在曼哈顿的运维工程师是如何保护服务器的呢?

【51CTO专稿】在曼哈顿下城区,飓风的影响令电梯无法正常工作,Peer 1 Hosting公司的管理员们不得不用大桶为位于18楼的柴油发电机补充燃料。而在新泽西州,SunGard公司则紧急规划燃油车行进路线,避免车辆为洪水所困。

[[102149]] 

纽约城严阵以待,中心商业区曼哈顿的证券交易所门口摆满了沙袋

灾备规划已经被公认为数据中心运维工作中的***实践之一,但飓风桑迪用自己的强大的威力证明,自然灾害一旦出现,管理人员意料之外的情况总会不请自来。在这个时候,固有灾难恢复计划很可能暴露出诸多弊端,这就需要管理者即兴发挥、针对具体情况迅速做出反应。

即使是SunGard公司这样一家专门从事灾难恢复工作、有着丰富经验的企业同样在新泽西迦勒斯大遇上了麻烦。那里河堤崩溃、附近的三家数据中心受到严重影响。他们在现场搭建起架空地板,希望能凭借这一丁点高度上的优势避免洪水在漫入停车场之后触及数据中心设施。问题还不仅如此,为备用发电机运输燃料的车队同样举步维艰。正所谓祸不单行,接踵而至的打击令管理人员一筹莫展。

位于曼哈顿低处百老汇街75号附近的Peer 1基础设施处境尴尬,管理人员们组成的救灾小队凭借健壮的体魄与坚强的意识,把一个个五加仑容量装满柴油的燃料桶从地下停车场运送到17楼——这堪称一项壮举,理应获得由市长办公室颁发的应变能力奖。数据中心后备柴油发电机位于18楼,源源不断供往17楼日常供应油箱的燃料被泵至上层,保证了服务的正常运作。

Peer 1 Hosting公司董事长兼CEO Sabio Banducci指出,他的公司不得不在“大厅积水达四英尺深”的情况下停止办公,积水甚至一路下渗、影响到了地下室以及正在修建当中的燃料输送系统。本来能够在飓风侵袭下发挥巨大的作用的地下管道就这样被洪水瞬间击溃。

75号的建筑工程师们正试图修建一套后备管道系统,但其传导压力不足以将燃油提升到17层楼的高度。Peer 1公司的灾难恢复小队曾经在2003年困扰整个曼哈顿地区的大规模停电事故中表现出色、成功在逆境中维持了数据中心可用性,这一次他们再次迅速做出反应,希望通过车载泵等手段解决问题。然而现实令人沮丧,由于公共交通几近瘫痪、城市街道严重堵塞,运输公司无法及时为Peer 1提供燃料供应。眼看日常供应油箱里的储备已经不多,停机似乎根本无法避免。

作为Peer 1公司的客户,网站开发企业SquareSpace很快意识到问题的严重性,并在***时间通知自家用户之余,提醒Peer 1称:全市“燃油与供水都处于短缺状态。”该公司于本周二在博客上专门撰写博文陈述了当时的情况。

Peer 1公司也在周二上午10:45更新了博客状态,指出“有计划实施计划内停机。”好在应急小队的英勇表现终于力挽狂澜,使得这次飓风并未导致任何停机故障。

Peer 1公司的柴油发电机部署在大楼楼顶,这一方面免去了设备被雨水淹没的后顾之忧,却在另一方面导致工作人员很难为其供应燃料。Peer 1数据中心经理及其团队决定组织一个“尖刀班”,在电梯无法使用的情况下依靠人力将燃料从楼梯间搬运到油箱所在地。这是一场人与自然之间的艰苦斗争,他们无法利用任何现有灾备计划,只能凭借头脑与双手奋力一搏。

数据中心工作人员连同其他Peer 1员工及多家分包商组成了25个攻坚团队,自十月三十号晚到十月三十一号上午一刻不停地为17楼的日常供应油箱加注燃料,以确保柴油发电机的长效运转。而接到“计划内停机通知”的客户也行动起来,为可能发生的故障提前做好数据保护工作。然而与预期不同,服务并未中断,Peer 1公司不负众望、在飓风桑迪的肆虐下顽强坚持了下来。

“不少客户都以为停机在所难免,但在得知我们为维持服务所做出的艰苦努力后,他们也加入到应急工作中来,”Banducci告诉我们。

由25人组成的运输队在大楼楼梯间随时待命,将装有五加仑柴油的大桶逐级向上传递。曼哈顿网站开发企业SquareSpace公司是率先加入到工作中来的Peer 1客户,其雇员还把双方携手奋战的照片于本周三发布在企业网站上。另一位伸出援手的客户则是Fog Creek公司,这是一家专门为在线项目管理开发协作软件的企业,总部位于相隔不远的百老汇街55号。

在运输卡车抵达的间歇,员工们将货厢中的8个15加仑柴油圆桶逐一卸下,并小心倒入摆放在地面高度上的5加仑容器之中。位于18层的发电机此刻摆出无情的面容,重重叠叠的楼梯考验着每一位员工的体力与意志。就在这种情况下,三个25人队有序开拔,开始了漫长甚至充满折磨的搬运工作。

Banducci不无自嘲地把这次应急行动称为“公司刚刚研制的自发性健身计划”——不过参与者必须自愿放弃睡眠。在他的果断决策下,周三晚间大规模停电出现时发电机油箱几乎处于满载状态,数据中心也始终运转如常。虽然大楼底层仍有储备燃油,但由于缺乏对停机可能性的预估,管理者们没能在电力尚未中断时及时将燃料运送到位。周三中午员工们甚至轻松愉快地花了90分钟享受午餐。为了避开城市拥堵的交通,其他工作人员步行通过布鲁克林桥、给现场同事带来了餐点。正是由于灾难恢复计划对意外事态估计不足,Peer 1公司才在一天之内从天堂摔进地狱。

但并不是每个人都如此幸运。与Peer 1公司相隔不远的另一家托管服务供应商Internap公司的故事则完全不同。他们在停电时立即启用现场发电机及备用燃料供应,“然而洪水持续不断、威力惊人,我们的冗余燃油泵与发电机燃料罐最终进水并引发失效。系统仍然运行了一段时间,直到上午11:45后备油箱被用光、设施就此陷入一片黑暗”。该公司在周二发布的通知中写道。

Internap公司开发及运营高级副总裁Steve Orchard在周三上午的报告中称,百老汇街75号的设施在燃油系统与发电机恢复工作后已经能够正常运行。客户系统再次上线,这时管理者手中已经拥有足以应付40小时使用的柴油与运输卡车资源,他写道。

Internap公司的另一套设施则位于地势更低的曼哈顿第八街111号,其屋顶也部署了发电机。然而由于“建筑燃料供应系统发生故障”且“泵机无法为屋顶的发电机提供柴油,工作人员不得不关闭了持续供电系统。因此备用电池耗尽之后,我们的基础设施也失去了动力,”Orchard在Internap公司的博客状态中解释称。

正因为如此,使用Internap公司第八街设施作为互联网接入点的客户在电力恢复之前彻底丧失了业务能力。“我们一直在努力与供应商协调,尝试尽快恢复现场设施的工作状态,”他在周三的博客中写道。

[[102150]]

桑迪过后 紧张忙碌的救援人员

当时建筑中燃料管道与泵机的状态我们尚不清楚,不过估计这些在短期测试时运转正常的系统发生了很多小问题——管道中存在大量碎片、堵塞了过滤器或是某个机械零件失灵导致接下来24小时中系统始终无法复原。虽然新建楼宇普遍部署了能够报告系统功能、帮助管理者发现薄弱环节的工具,但想在实际应用前准确预测此类问题仍然非常困难。即便如此,经验丰富的建筑工程师仍然应该时刻关注供给系统、通过分析与反馈确定潜在风险。无论出于何种原因,最终的结果证明了第八街111号燃料系统在灾难发生时的无力,这一点值得建筑工程师们加以深思。

不过即使是SunGard公司也承认,不可预见的事件总会发生,并最终破坏看似尽善尽美的灾难恢复规划。Nick Magliato指出,他和他的应急小组兵分两路,分别在现场与大楼底层通过步话机进行沟通,讨论这场规模完全超越往年同季飓风所引发的洪水可能从哪里侵入。

周一晚上,风暴带来的降水超过排水沟11英尺之高,不过此时的水量还处于大坝能够控制的范围之内。SunGard公司地面团队发现雨水已经开始溢出,并慢慢向SunGard公司三个位于工业园区内的数据中心蔓延,但积水高度尽为一两英寸,上涨速度也还不算快。当时工作人员还抱有侥幸心理,希望这次由灾害引发的洪水能够静静地来、悄悄地走。

然而天不遂人愿,来自地面小队的信息显示,短短十分钟洪水深度已经上升了一点五英尺——来自数据中心的标尺测量结果令人揪心。大坝出现裂缝,水流逐渐涌出。面对这样的状况,Magliato意识到“按照这样的速度,用不了太长时间整个地方就会被洪水彻底淹没。”

观察员根据远距离测量结果向数据中心发出警报,提醒管理者尽快组织应对措施。不过老天爷留给大家的时间并不多,仅在警报发出之后不久,工业园的停车场边界就出现了大量积水,园区内部也很快惨遭侵袭。Magliato仍然在努力指挥工作人员把数据中心设备搬运到设施中的活动地板上,希望能够依靠这一点点高度差优势与洪水对抗。然而每个忙碌在现场的人都知道水位还将增加六到七英尺,无论如何挣扎设备最终都必然受到损害——因为根据灾备规划,没人能想到洪水能达到现在的规模。

尽管如此,SunGard公司的应急小队还是发现自己所做的抢救工作与保护目标越来越南辕北辙——迦勒斯大当地从未遇到过此等降雨,所以预先制订的措施几乎瞬间失效。当时企业整个管理团队都投身其中,甚至全部董事会成员都接到了紧急通知。公司向客户发出警示,并以电话会议的形式随时通报***情况——在严峻的形势下,客户得以准确了解现场事态、实时水位,并以此为依据时刻准备迅速转移或关闭程序。

有鉴于此,Magliato在接受采访时指出,他意识到了自己在制定灾备恢复规划时的疏忽与大意。举例来说,原本企业打算利用燃料驱动后备发电机并以此为设施供电。但当Magliato查阅地图时,发现燃料运输车的必经之路正好毗邻大堤,而当时大堤侧畔的水位达到了全市最深。在千头万绪的复杂情况下,他和员工开始选择替代路线,最终确保卡车免于熄火在地势低洼的路口、成功来到数据中心门口。不久之后,两辆具备7500加仑载重能力的卡车终于突破重围,为多变的未来储备下宝贵的40000加仑燃料。

按照规划,“洪水终将随时间退去,所以其间的燃料补充就成了重中之重,”然而大自然根本就没按套路出牌。“我们不得不即兴发挥,在地图上挑选出一条相对安全的通路,”Magliato不无遗憾地表示。

沿海地区每天都要经历两次涨潮过程,而且每一次的时间都不尽相同——通常涨潮持续一个小时,并很快回复到平潮状态。对于Magliato和他的团队而言,“这是一次久久不愿退去的涨潮过程。我们一直到周四中午都没能盼到涨潮结束,”他指出。

就整体而言,灾难规划还是按照预定效果稳步执行,而SunGard公司保护下的基础设施也没有造成停机,保障了客户的正常权益。虽然结果还算差强人意,但却没有哪一位敢站出来,声称整套规划已经涵盖了可能出现的任何挑战、或者说其中不需要任何即兴发挥的情况。正所谓知己知彼才能百战不殆,希望这次飓风桑迪的肆虐能给每一位管理者带来启示。

原文:Hurricane Sandy: Disaster Recovery Improv Tales

【编辑推荐】

  1. 《Linux运维趋势》2012年9月号 总22期
  2. 运维经验分享:Hadoop管理员的十个***实践
  3. IT运维自动化概览
责任编辑:张浩 来源: 51CTO.com
相关推荐

2012-11-08 10:48:28

数据中心灾难应急飓风

2009-10-19 09:50:43

LINUX FSCK数据出错灾难应急方案

2017-11-13 06:05:10

数据中心灾难恢复

2011-08-31 11:42:06

数据中心艾琳飓风

2015-11-23 16:55:30

数据中心应急关机

2012-11-12 00:13:12

回顾数据中心云计算

2022-08-05 13:38:00

数据中心飓风团队

2010-06-28 13:48:32

中心数据中心建设

2010-10-14 10:25:41

数据中心灾难

2012-11-01 10:02:45

飓风数据中心社交网站

2017-12-26 09:36:36

数据中心灾难恢复

2015-08-18 15:37:31

数据中心灾备

2011-07-07 11:04:07

数据中心灾难恢复

2012-12-04 10:23:14

2012-03-12 10:51:41

数据中心灾难备份

2021-12-08 13:58:59

数据中心数据中心架构数据中心网络

2015-10-13 11:37:04

数据中心业务连续性灾难恢复

2018-06-14 11:11:59

灾难恢复数据中心

2015-08-27 09:26:27

UPS数据中心

2016-10-24 12:42:52

数据中心
点赞
收藏

51CTO技术栈公众号