亲历火灾:数据中心灾难恢复启示录

作者注:该故事基于真实事件。每个细节都来自我的学生和我获得的一手事实。

凌晨三点,我的手机收到一封告警。自从我们安装了新的数据中心基础设施管理系统后,每晚我都能收到十倍以上的告警,但都不是很严重的问题。但这次不同,我们主数据中心的温度虽然都在ASHRAE的允许温度范围内——但高于公司运营限制,而且还在不断上升。

财务部门在有人确定既定标准与设计之前就决定了我们新数据中心的预算,我们不得不经常削减其中的灾难恢复策略。我曾坚持要求额外的空调以及模块化的不间断电源系统(UPS)冗余。除了这些,设计师认定我们在Uptime Tier III级别标准,但我们也没有理由去花钱来获得认证。

我通知了保安。他们也收到了相同的告警,但没有一个人能够定位问题。在叫醒了设施经理,他表示会安排人员到场后,我穿好衣服并前往设施。

压力与无力感

一小时后,我走进那个感觉像沙哈拉沙漠的数据中心。灯光到处闪烁,服务器所有的风扇全速运转,我们10台空调有2台出现了故障。一些服务器已经自动关机了。我突然意识到本该落实到位的灾难恢复策略已经开始崩溃。

数据中心基础设施管理显示的内容令人困扰,而且图形用户界面并没有任何意义,用户登陆后的首菜单后,没有看到问题。一大串数据显示温度已经持续升高了数小时。为什么我没有更早得到告警?我发现一张看起来像天书的电气图,但我知道这个可能是UPS系统。我知道从那里可以找到我们服务器机柜的面板,但并不知道具体的控制机制。墙上还有一些电器面板,但标签没有任何意义。“LBTA-3”可能是任何东西,而且面板门被锁住了。

设施与IT不匹配,数据中心就崩溃了——特别是在紧急情况下。解决冲突的一种方案是让某个IT团队成员也对设施管理负责。另一种方法是简化两部门之间的沟通。

设施工作人员赶到现场后,他证实了我已知道的事实:没有足够能源来支持我们所有设备。他检查了所能找到的断路器,没有发现任何错误,但在没有电工的情况下我们无法进一步排查。这时候只好继续打电话给设施经理,接着等电工到达。

一台接一台,我关闭了服务器,避免灾难性崩溃发生。不久电工到了,而且他知道电路板在哪里——那扇我们无法进入,只有靠他的特殊钥匙才能打开的门后面。他开启了大门,里面很凉快。这间同样是UPS室,而里面只有一台空调在运转。单台空调意味着我们的冗余UPS被安置在非冗余冷却环境中。

事情升温

在电工重置了跳闸的主断路器后,空调开始恢复运作——但好景不长。火苗从电箱面板的小裂缝处冒出。我们的吸气式烟雾探测系统如果及时通知我们事情严重了,我们就能在主消防系统释放灭火气体之前解决问题。烟雾迅速弥漫整个数据中心,伴随着震耳欲聋的告警声。但在没有任何预警的情况下,主系统已经开始气体释放倒计时。由于数据中心内没有着火,我按下了重载按钮,但只有倒计时被重置了。消防员出现在门口。只有空调电源出现问题,不是UPS或服务器电源,但他们立刻到达了大红色的EPO(紧急电源关闭)按钮处。我朝他们大喊,但他们还是按下去了。几秒钟后,灭火气体释放了。电工赶往地下室切断机房的主供电,而消防员正在往燃烧的配电箱中浇灌泡沫。

在DR站点遭到冷遇

当外海办事处同事通过越洋电话询问我发生了何事,为什么他们无法访问公司电话时,我向他们保证,根据我们的灾难恢复策略,需求会被转发到灾难恢复站点。然而,虽然我们已经签约了站点,但我们实际并没有进行任何传输操作,就是我们还没有转移IT基础设施——无论是物理的还是虚拟的——到DR站点。当我打电话给DR供应商宣布紧急状况时,他们告诉我站点没有热维护,也无法随时上线。我们一直都在做日常数据备份到灾难恢复中心,但需要时间让我们进行用户转移操作。而且我们需要自己的员工到场才能进行。

当数据中心灾难发生,必须与组织的其余部门进行通信。通过创建通信树计划来避免混乱,也可以通过自动通知系统来告知数据中心灾难。

在电气室,火已经扑灭,电源被关闭,我们需要靠应急灯照明才能工作。电工在移除交换板的面板后,发现总线已经烧毁,把备用总线也烧毁了。我知道现在唯一的选择就是让IT服务在DR站点恢复运转,并重新评估我们的灾难恢复计划。

研究表明,75%的数据中心故障是人为错误,这意味着我们可以从他人的经验中学习,包括上述事件。
本文转自d1net(转载)

时间: 2024-10-26 03:15:40

亲历火灾:数据中心灾难恢复启示录的相关文章

数据中心灾难恢复托管?两大问题必须看清

任何有关数据中心灾难恢复的讨论几乎都会涉及到异地设施的问题.企业在灾难恢复设施的选择面很广,从传统的,非全权托管,到完全基于云的全权托管.实际取决于业务具体需求和能力.作为灾难恢复的增值项,需要更加重视灾难恢复需求.合规性以及持续测试. IT规划中最具挑战性和复杂度的方面是准备应对数据中心和业务处理不可避免的灾害.传统的灾难恢复方法,如远程备份和复制,任然可以发挥作用,但IT组织现在开始向外寻找更好的方式来应对基础设施遭受严重破坏的情况.主机托管已经成为有吸引力的选择之一,因为企业基本上可以复制

数据中心灾难恢复手册

看到了一篇关于数据中心恢复相关的文章,转载至此,虽然没有非常详细的解释原理和相关的操作说明,但看看还是有些认识的. 原文链接: 数据中心灾难恢复说明  PDF版本下载:  数据中心灾难恢复手册

数据中心灾难恢复的最佳实践

如今,数据中心运营商每天都在为数据中心的高可用性感到烦恼,全天候工作以确保100%的正常运行时间.他们部署冗余设施以最大限度地降低风险,严格规划和测试以确保连续性运行,并采取预防措施保护其基础设施免受环境威胁.但是,即使是最好的计划和准备措施也会在自然灾难或突发事故中出错. 事实上,在某些极端情况下,先进的规划和准备工作依然无能为力,而灾后恢复成为确保企业在重建数据中心业务的同时保持功能的重要组成部分. 在任何灾难情况下,时间都是至关重要的,因此数据中心工作人员需要知道在事件发生后的几分钟.几小

IDC数据中心这些隐患您是否知道

这份数据中心灾难报告由两部分构成,该报告完全基于现实经验.在报告的第一部分中(详见<亲历火灾:数据中心灾难恢复启示录>),管理人员一直工作到下午三点,研究如何预防电气火灾,最后决定在数据中心中添加一个声音报警和两个分解总线.通过这份灾难恢复报告我们可以发现故障点以及如何避免云灾难. 整整花费了一天喝半个晚上时间才在DR站点恢复了IR操作运营,而这也仅仅是针对最高级别的优先系统.有了便携式空调设备.临时通信和小型不间断供电设备,我们就可以恢复手机通讯.需要花费几个星期的时间才能替换大型交换机烧毁

数据中心遭破坏后如何恢复!!!

"数据中心"是互联网.云计算和大数据等产业的组成的重要基础设施,尽管许多企业为了降低一系列的商业风险,包括那些数据中心的风险,有业务连续性计划或灾难恢复计划,但有些企业却没有,或者他们就算是有计划但也过于笼统.当你在制定数据中心灾难恢复方案的时候,你的目标是为了保护公司在信息技术.通信和人员方面的投入.一旦遭到破坏,你的数据中心要么是完全不受影响要么就可能遭到彻底的毁坏. 通过对数据中心决策者的广泛调查,商业分析企业451研究公司发现,82%受访者表示拥有某种形式的灾难恢复(DR)计划

认识数据中心两个关键指标RTO和RPO

用来描述和评价数据中心有很多专有参数和指标,通过这些数据可以反映出数据中心的各种运行状态,其中有两个关键指标必须有所了解: RTO和RPO.RTO和RPO是数据中心灾难恢复方面的重要参考指标.现在的数据中心对业务的连续性有苛刻要求,但是故障不可避免,一旦发生了故障就需要启动备份机制,确保业务的连续性,所以现在数据中心都有较为完善的容灾机制,RTO和RPO可以很好地反映出数据中心容灾性能如何.这两个参数是数据中心在运维过程中,一定要重点关注的指标.这个指标的好与差,是基于数据中心现有的各种综合运行

H5数据中心收购位于凤凰城一个数据中心

摘要: 作为颇受欢迎的一家数据中心灾难恢复公司,H5数据中心已将其业务扩展到凤凰城的数据中心市场.H5数据中心收购Nextfort公司在钱德勒的数据中心. H5数据中心首席营运官戴维·邓恩在接受记者采访时表示,凤凰城是一个强大的企业级数据中心市场,也是加利福尼亚州数据中心最适合的灾难恢复位置. 还有一些全球主要的网络公司在该地区建设数据中心,如eBay公司和PayPal公司,苹果公司也将在梅萨附近的面积为130万平方英尺的原生产工厂改建成为数据中心. 邓恩对数据中心供应商T5数据中心在凤凰城郊区

数据中心的业务连续性和灾难恢复计划

为了降低一系列的商业风险,包括那些数据中心的风险,许多组织建立了业务连续性(BC)计划和灾难恢复(DR)计划.这些计划一般侧重于特定的威胁,企业将持续实施这些计划,并对它们进行测试.为确保计划成功,企业需要做的更好.而确保数据中心正确工作是填补这些空白的一种方法. 企业有计划吗?计划具体吗? 尽管许多企业有业务连续性计划或灾难恢复计划,但有些企业却没有,或者他们就算是有计划但也过于笼统.通过对数据中心决策者的广泛调查,商业分析企业451研究公司发现,82%受访者表示拥有某种形式的灾难恢复(DR)

可以将数据中心用作云端的灾难恢复站点吗?

如今,许多公司将部分或全部工作负载转移到云端供应商(如亚马逊,Google或Azure)提供的云平台,但也提出了两个问题:云计算需要灾难恢复吗?如果业务在云端运行,那么如何进行故障切换? 企业需要在云端实施灾难恢复吗? 这个问题的答案是肯定的.记住,没有"云"这样的东西,那只是有别人的数据中心.云计算是具有弹性的,它比大多数企业的数据中心更具弹性,但这不是魔术,当企业的工作负载将会崩溃或中断,这种事情也可能发生在云端. 云计算仍然也会出现错误,云计算供应商也犯了许多错误.例如,微软公司