服务器 频道

全面盘点:2011年六大宕机事件

    【IT168 评论】7月11日下午2时,著名的旅行网站艺龙突然无法访问,此后连续二十六个小时,用户纷纷表示无法访问网站,首页均显示系统正在升级。后来证实是存储系统除了问题,导致整体服务停止,系统宕机。因为这一场事故,艺龙蒙受了巨大的客户流失,为此花费了大量维修成本。

  这个事故在业界掀起一阵对数据中心灾难防护的争论,在业务时间按秒计算的今天,IT设备一分一秒的浪费,都会给企业带来不可估量的损失。其实今年的宕机事故并非只有艺龙一个,但是这些事故并没有得到应有的重视。为何非要等到出现严重后果,人们才能意识到预防宕机的重要性呢?

  我们先复习一下TIA-942《数据中心的通信基础设施标准》中对于数据中心等级的划分。

根据 TIA-942 标准,数据中心机房可分为四级:由“等级 Tier I”没有冗余部件组成的系统(可提供99.671%的可用性)到“等级Tier IV”有冗余部件(能够故障容错)和实现不间断维修的系统(可提供99.995%的可用性)。根据该标准场地的可用性分类等级框架分成四个层次等级,下面将介绍该标准中每个等级的特性及其数据中心基础设施等级的类型、要求和相关特性:

  (一) 等级Tier I――基本数据中心

  “等级I”的数据中心对来自有计划和无计划的运营中断反映敏感(影响较大)。数据中心配有计算机电力分配和冷却,但是它可以或不一定有架高的活动地板,一台UPS或者一台发电机。在这些系统上的关键的负荷能达到N的100% 。如果它确实有UPS或者发电机,他们是单个模块的系统并且有很多单个的故障点。一个年度内场地内基础设施被完全关闭停运,是基于进行预防性检修和修理的需要。紧急状态下可能需要频繁地关闭设施。场地内基础设施组成器件故障、操作错误,以及自然产生地失败将引起数据中心运营的中断。等级I由电力和冷却分配的一条单通路组成,没有多余的组成部分,提供99.671%的可用性。
  
  (二) 等级Tier II――基础设施部件冗余

  “等级II”的数据中心采用设备部件冗余要比“基本数据中心”有计划和无计划的运营中断反映稍微要少(影响较小)。场地内有架高的活动地板,一台UPS和发电机,动力的能力设计是N+1,全部有条单一的分配线路。关键的负荷能达到N的100% 。关键线路的维修和场地内其他基础设施的维修维护将需要一次处理性关闭中断。等级II由电力和冷却分配的一条单通路组成,带有多余的组成部分,提供99.749%的可用性。
  
  (三) 等级Tier III――基础设施同时可维修

  “等级III”的数据中心具有能够进行任何有计划的场地基础设施活动,而又不应使计算机硬件系统运行中断的能力。有计划的活动包括预防性和程序性的维修,修理和替换零部件,添加或调整部件的容量,部件和系统的测试。对使用冷冻水系统的大型场地来说,这表示两套独立的管路。要有足够的能力和分配,一定可提供在进行维修或者在其它管路上测试时,在一条管路上同时带负荷。无计划的活动,例如设备基础设施的零部件,在运行中或者自然的情况下发生故障,引起数据中心的运行中断。在一个系统上的关键的负荷不超过N的90%。当客户的业务需要得到正当合理的额外保护时,“等级III”的场地将被有计划地设计成可升级成“等级IV”的场地。等级III由多条有效的电力和冷却分配道路组成,但是只一条道路活跃,有多余的组成部分,并且同时是可维修的,提供的99.982%的可用性。
  
  (四) 等级Tier IV――基础设施故障容错

  “等级IV”的数据中心具有能够进行任何有计划的的活动且不会对关键的负荷造成中断的能力,且有提供场地基础设施容量及其能力。基础设施故障容错的功能性为场地基础设施的能力提供至少维持一种最坏的情况,无计划的故障或者事件将不影响关键的负荷。这需要同时活跃的分配道路,通常在S+S的双电源系统配置里。电力系统供应表示为每个有N+1冗余的两个单独的UPS系统。在一个系统上的涉及的关键的负荷不超过N的90%。“等级IV”需要全部计算机硬件有故障容错的双电源输入。严格的故障容错测验使数据中心具有维持无计划故障或者运行错误时,不发生计算机机房过程中断的能力。等级IV由多条有效的电力和冷却分配道路组成,有多余的组成部分,并且是故障容错,提供的99.995%的可用性。

  可以看出,对于最高等级Tier 4来说,一年仅容许0.4小时的宕机时间,也就是24分钟,对于Tier1来说,也不能超过28.8小时。

  但是,大多数数据中心(包括很多知名企业的大型数据中心)都在一次宕机内就完成了一年的“目标”。

  结合着这一点,我们来回首一下近期影响较大宕机事故:

  4月21日,亚马逊云计算中心宕机

  亚马逊在Virginia的云计算数据中心服务由于误操作宕机,导致大量依赖其云服务的企业利益受损,其中包括手机服务网站FourSquare、新闻网站Reddit等等。这次宕机事故,不但让亚马逊及其客户受到惨痛的损失,更带来了人们对云计算服务的信任危机。

  8月8日,亚马逊云服务由于雷击再次宕机,不过这次仅持续1个小时。

  5月26日, Skype宕机

  网络电话服务软件Skype发生宕机事故,很多用户无法登陆软件或者拨打电话。无处发泄的用户只得在twitter上表达不满,更有用户将其怪罪于微软收购Skype的行为,因为主要是Windows版客户端出问题。在同年6月7日,Skype再度发生宕机事故。

  6月9日,Twitter宕机

  Twitter当天早晨因为不明技术问题,导致API受到影响,但是宕机仅持续了一个多小时就被解决,所以并没有造成太大影响。去年Twitter曾经发生过多起宕机事故,最久持续6小时,而今年情况大为好转,宕机时间较少,而且一旦发生,就能马上解决。

  7月14日,艺龙旅行网宕机

  今年最大的一起宕机事故,事故缘于EMC存储设备,但就其根本,据说是艺龙本身的存储架构不完善,才导致了如此长的修复时间。由于存储灾备的不完善,备份没有起到应有的作用。否则EMC出现故障,也不至于宕机26个小时。

  7月15日,谷歌App Engine宕机

  谷歌应用引擎Java服务出故障,导致宕机1小时,这个问题日期相近的艺龙宕机事故来说不是特别引人注目,但是故障原因基于云计算,把应用程序转到网络上,出现了一些问题。最近云服务颇受欢迎,但是安全问题还是一把达摩克利斯剑。

  8月3日,雅虎邮箱宕机

  用户12小时无法访问雅虎邮箱,一开始并没有得到雅虎的重视,随着反映问题的用户越来越多,才开始作出回应。原因不明。

0
相关文章