存储系统故障导致台北桃园机场宕机36小时

 这几天国内 IT 业界最热门的新闻不外乎是中国台湾省台北桃园机场境管系统当机 36 小时了;事情一发生,各种专业的,非专业的猜测,流言,内线消息不断,热闹极了。

有人从政治的角度解读(这好像是这几年国内各种事件必然要有的一个面相),说是为了掩护某些人士的出境;而笔者看到网络上最扯的说法是被“某国”给黑了,放毒了,对于这些,笔者 只能用一句电视上的广告台词“不要再相信那些没有根据的传言了”来响应。

没有任何一位 IT 人员(尤其是 IT 工程师)愿意看到系统在自己的手上“无法上线”36 个小时,笔者 在这里使用“无法上线”而不使用“宕机”,是因为,就IT工程的角度来说,“宕机”指的是一部机器 (不论是主机或存储系统) 因为某些原因而无法开机成功回复运作;这次境管系统的事件,从现有枱面上的消息来说,并不是机器无法运作,而是境管查验系统无法上线作业。

至于被黑或是中毒的说法,更是一般使用者的猜测;现有的境管系统使用的是 UNIX 操作系统,到目前为止,业界还没有发生过 UNIX 作业平台的中毒事件;而且境管系统是一套封闭的系统,即使有办法可以黑入移民署或是桃园机场的网站,也不可能连上境管系统,因为境管系统根本没有对外部的网络联机!

至于系统的备份或是数据备份的问题,“在最短时间内恢复联机操作”本来就是境管系统架构当初设计的目的之一,就 笔者 的了解,桃园机场的境管主机是双机备份作业的架构,也就是只要有一部主机可以运作,就可以维持在线的作业;数据备份,也肯定是有的;至于为什么这些设计没有在需要的时候发挥它应有的功能,这是移民署必须要给的答案,笔者 不愿多做猜测。

回归 IT 专业,这次故障,至少到目前为止,系统维护厂商枱面上给的解释是某供应商的存储系统中有三块磁盘及一片机板故障,而在硬件修复后,必须要等待数据由第二套系统回复,所以需要这么久的时间,我们就从这个故障原因谈起;机板故障的问题我们不讨论,因为机板存粹就是一个硬件组件,换新的就好了。

再来就是磁盘啰!企业级的存储系统是不可能出现某几块磁盘故障而导致无法开机的。那有没有可能导致数据损毁?当然可能!

存储系统最重要的数据其实并不是用户的数据,而是一个我们称之为“元数据”(metadata) 的数据,metadata 简单来说就是存储系统的组态文件,所有磁盘驱动器如何划分,哪些磁盘驱动器组成一个 RAID 群组,每一个数据卷 (volume) 的大小等等,这些相关信息通通存储在 metadata 中。所以一旦metadata 损毁,可以想见的是,也许整个存储系统内的用户数据全部都在,但却不知道如何组织这些数据,这是存储系统的最大灾难,如何确保metadata 的安全是所有存储系统的一个重要课题。

不同的存储系统会使用不同的方法来保存 metadata;企业级的高端存储系统会将 metadata 存放在具镜射保护的非挥发性内存 (non-violated memory) 中,非挥发性内存不会因为没有电源而失去数据,另外为了增加系统的可用性,会把 metadata 复制几份放在磁盘中,以备不时之需。中端存储系统的 metadata 会存放在以 RAID 保护的特定磁盘中,或是分散在系统的不同硬盘中,保护显然就没有大型存储系统来的好,但也足够了。

在最坏的情况下,如果 metadata 真的完全损毁而无法由任何备份来回复时,每家存储系统原厂的研发部门还是可以在某些特定的状况下,试着抢救 metadata,不过修复的时间与修复的程度则没人敢打包票了。就这次的情况来看,境管系统使用的是高端的存储系统,显然并不是 metadata 的损毁,否则可能还要花更长的时间才能修复。

那么在数据硬盘上一次坏掉三颗硬盘?这个就有趣了,值得来讨论一下。

我们都知道现在在存储系统上普遍使用的 RAID (Redundant Array of Independent Disks),就是用来保护资料可以避免因为单一磁盘的故障而致无法使用的技术,RAID5 是可以容许一个 RAID 群组有一颗磁盘故障而不会影响数据的存取,虽然新的 RAID6 技术可以容许二颗磁盘的故障,但 笔者 相信境管系统应该不是使用 RAID6 的技术。所以,如果使用 RAID5,而这三颗故障的磁盘是分散在三个 RAID 群组中,那就不会出事了,显然故障的三颗磁盘至少有二颗是在同一个 RAID 群组。

一个 RAID 群组,或是一个数据卷无法使用,会导致系统无法上线?存在这个数据卷上的是必然是一个极其重要的数据文件,没有它程序无法运作。但从应用系统设计的角度来看,最重要的数据文件会考虑以更好方式来保护,如使用 RAID1,或是在再复制一份存放在其他地方,一旦因为硬件问题无法存取数据,可以以人工的方式要求程序去读取备份的数据文件,在最短时间内恢复联机操作。

另外一个可能是,这个故障的数据卷是一个大型资料卷的一部份,这在大型资料文件中相当常见;使用数据卷管理 (volume management) 软件,将几个硬件的数据卷合成一个数据卷,为了避免 RAID 重复计算导致数据访问时间的延迟,这种大型的数据卷通常不会再使用 RAID 保护,而是以 stripping 或是 concatenated 的方式来组成大型数据卷,因为没有 RAID 的保护,一旦有某一个硬件数据卷故障,就会导致数据无法存取。

在实务上,笔者通常都会建议使用者在考虑使用这种大型数据卷时,数据的回复时间一定要考虑进去,因为没有人敢打包票硬件一定不会故障,硬件故障会不会造成数据损毁,通常来讲机率不高,但不是零。这也是为什么要一再强调数据备份的重要性。同时还要考虑到,一旦数据不见了,需要的回复时间。

所以回归到硬件上,究竟在一个 RAID 群组发生二块以上的磁盘同时故障的机率到底高不高?笔者看到在网络上绝大部份的人都认为这是中了签王,不过是不是真的如此?

磁盘驱动器的可靠度是以平均故障时间 (MTBF, Mean Time Between Failure) 来评估,以现在的企业级磁盘驱动器来说,MTBF 是一百廿万个小时,大概是 136 年,那在我们有生之年应该看不到磁盘驱动器故障才对!其实 MTBF 并不是这样算的,它是指每一百廿万个使用小时,就可能会有一颗磁盘驱动器故障,所以有人使用没几天,有人可以使用好几年。所以 MTBF 只是一个参考值,它可以显示磁盘驱动器的可靠度,当然 MTBF 越高故障率也越低,但与单一系统可能碰到磁盘故障的机会并没有绝对的长短关系。

另外一个与碰到磁盘驱动器故障机会有关的因素就是工业的产品寿命;每一个单一工业制品都有它的使用寿命,就像电池一样,使用寿命到了,它就是会报废。但是使用寿命与使用状况有极大的关系,运作环境当然是一个很重要因素,国外已经有报告指出,在平均温度偏高的环境中运作的 IT 设备,它的故障频率也会相对的高;以磁盘驱动器来说,除了环境之外,使用频率与使用负载也是影响产品寿命的因素。用通俗的话来说,就是操得比较凶的,挂得也比较快。

所以就理论上来说,在各种条件都相同的状况下,同型的磁盘驱动器如果开始使用的时间相同,那么它们故障的时间也会接近。在实务上,笔者 也的确遇到过这样的状况,同一批上线的磁盘驱动器,一旦其中有部份开始出现故障的状况,在接下来的一段时间,将会出现密集的“换机潮”。

但吊诡的是,在同一部存储系统的磁盘驱动器,虽然外在的环境是相同的,但使用频率和使用负载应该是不同的,它们的“故障期”应该是不同!这就牵涉到存储规划了。一个有经验的存储规划人员,在建置一个存储环境时,通常都会与应用系统或是数据库管理人员有过沟通,了解每一种数据型态未来的使用状况,并且尽可能的将使用负载分散,这是为了数据的存取效能与避免出现磁盘上的热点 (hot spot,指的是磁盘上大量数据存取而容易造成的坏轨)。所以本来应该因为使用状况不同而不致于同时出现的故障时间,却因为规划时其他的考虑因素,反而使故障时间接近。

这次境管系统当机事件,笔者 看网络上一片骂声,当然,移民署绝对有很多值得检讨的地方;虽然 IT 设备是造成这次事件的主因,但 笔者 认为 IT 的环境或是 IT 的建置,是这整个事件最后一个才需要被检讨的部份。不论是政府机关或是民间企业,IT 的“备份”设计有没有被认真当做一件事来讨论?根据 笔者 的经验,一定要发生大事后,才会有人重视!“备份”这件事,不是只有 IT,它是一套应变的方法,如果连应变的计划都没有,那还谈什么 IT 备份呢?

 

作者:phliang

来源:51CTO

时间: 2024-07-29 03:18:53

存储系统故障导致台北桃园机场宕机36小时的相关文章

艺龙旅行网宕机26小时的危机处理

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 7月11日,国内知名的在线旅行网站艺龙旅行网服务器宕机,并导致呼叫中心瘫痪,时间长达26个小时,在业界引起了高度关注.作为一家在线销售旅行产品的网站,艺龙旅行网此次宕机的经济损失不小,但这些都是可以估量的损失.真正无法估量的是品牌声誉,对用户造成的伤害,这将是无法估量.也是无法承受的损失. 艺龙服务器宕机20多个小时候后,我在新浪和腾讯微博发

微软Hotmail等网页电子邮件服务宕机3小时

http://www.aliyun.com/zixun/aggregation/17197.html">北京时间3月13日消息,微软网页电子邮件服务Hotmail和Outlook.com周二持续宕机3小时,许多用户通过Twitter等网站报告了这一宕机事故. 上月有报道称,微软已决定将Hotmail的用户转移至Outlook.com.然而此次宕机事故表明,微软的转移过程可能存在问题.微软这一平台转移是渐进式的,用户可以自主选择是否从Hotmail转向Outlook.com. 在此次事故中,

台北桃园机场计算机为何会当机36小时?!

   根据相关媒体报导,问题起因于第二航站的境管计算机的磁盘阵列系统中有三块硬盘和一片主板在本月3日发生故障,标得移民署计算机维护案的神通计算机于本周一(5日)清晨更换其中一块硬盘,并至第一航站仍正常运作的境管计算机中,抓取与汇入入出境数据的时候,因不明原因导致互为备份的第一航站与第二航站的境管计算机先后当机,计算机当机后,除高雄港与高雄小港机场以外的机场港口皆受影响,全得以人工操作的方式检核入出境旅客数据,历经36小时抢修后,境管计算机已恢复大部分的入出境检核作业.       姑且先不谈有无

艺龙网宕机27小时主因:存储系统备份架构不完善

7月14日消息,11日下午2点到12日下午4点,艺龙旅游网出现了持续的访问故障.据了解,该事件最初是EMC存储设备出现故障,而由于艺龙网的存储结构不完善导致长时间无法修复. 此次事件在互联网行业的系统架构领域引发了很多的讨论,艺龙因为这次宕机事件,其网站服务和呼叫中心业务也无法进行,据一些媒体计算,艺龙网这次直接损失超过14.7万营业收入,而其对客户造成的潜在影响无法估计. EMC存储出现问题引发连锁反应 11日下午,不断有网友反应艺龙网访问出现错误,很快,官方就出现了"系统故障,正在修复中--

美联社新闻数据库宕机5小时 波及美大部分报纸

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 北京时间10月115.html">26日上午消息,据国外媒体报道,周一美联社遭遇计算机故障,在5小时中各家报社及其他一些新闻媒体无法收到该社的大量报道. 故障发生于美国东部时间周一下午3时(北京时间周二凌晨3时),当时美联社正试图安装微软推荐的一个安全补丁.该社希望在下周的美国全国和各州大选前提高安全性. 美联社首席信息官洛林

三星韩国数据中心火灾 多项服务宕机数小时

三星SDS大楼发生火灾新浪科技讯 北京时间4月21日早间消息,三星官方网站Samsung.com网站周日出现宕机,导致许多用户的三星手机.平板电脑和智能电视收到了错误消息.根据社区新闻网站Wikitree的报道,此次宕机是由于位于韩国果川的三星SDS大楼发生火灾.此次宕机导致三星的用户无法访问一些应用.宕机持续了几小时时间,并于美国东部时间周日6:15(北京时间周日18:15)左右得到解决.三星SDS在一篇博客中确认了火灾和宕机事故,并对带来的不便表示道歉.韩国媒体报道称,此次火灾没有导致人员伤

Gitlab.com 误删数据,备份恢复失败已宕机 10 小时

GitLab.com 官方网站发布声明称由于其产品数据库问题导致的网站无法正常访问.据国外媒体报道称 Gitlab 网站疲惫的系统管理员深夜在进行数据库维护时,使用 rm -rf 删了300GB 生产环境数据.等到清醒过来紧急按下ctrl + c,只有4.5GB保留下来.然后恢复备份失败,网站已经宕了10个小时,现在还没恢复. 目前可以确认的是 Gitlab 的数据备份是无效的.报告称此次数据丢失并非仓库的数据,而是仓库相关的 issue 以及合并请求操作. GitLab.com 号称有五重备份

Twitter因系统维护而宕机数小时

北京时间8月1日晚间消息,据国外媒体报道,出于维护需要,微型博客Twitter周日早上一度停止服务数小时,致使全球约1亿用户无法正常使用该服务. 周日早上,当用户访问Twitter网站时,页面给出提示:"因按计划维护而暂时无法访问,预计几个小时候后可恢复." 据悉,Twitter托管服务商NTT America于美国东部时间周二凌晨2点钟进行了系统维护,计划持续约5个小时.凌晨3点半左右,部分用户可以正常使用Twitter.但几个小时之后,仍有部分用户无法访问.(李明)

Twitter网站和移动应用发生全球性宕机 目前已修复

北京时间1月20日消息,据财经频道CNBC报道,社交媒体Twitter周二遭遇全球性宕机.用户在访问Twitter网站时会收到"发生技术故障"的提示信息.Twitter在周二下午修复了服务. 移动用户也发现,Twitter无法更新.Twitter在一份声明中称,内部代码调整导致公司服务发生宕机,时间是在美国东部时间周二3:40分至9:50分(北京时间周二16:40分至22:50分). 到美国东部时间周二13点(北京时间周三2点)时,Twitter恢复了代码设置,修复了问题.在宕机发生时