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

存储 存储软件 容灾备份
这几天国内 IT 业界最热门的新闻不外乎是中国台湾省台北桃园机场境管系统当机 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 备份呢?

【责任编辑:刘强 TEL:(010)68476606】

责任编辑:刘强 来源: WatchStor整理
相关推荐

2009-01-11 16:20:14

2018-10-26 10:16:55

数据中心存储系统网络故障

2018-05-31 08:39:18

单机存储系统

2020-02-26 14:07:58

删库微盟运维

2011-08-29 18:25:19

Ubuntu

2013-08-26 13:18:02

纳斯达克股票交易网络安全

2009-07-30 18:33:22

VMware ESXESXi操作系统

2018-03-13 18:35:32

华为云软件开发开发云

2018-09-29 14:08:04

存储系统分布式

2012-10-30 09:36:53

VDI存储虚拟化

2014-05-09 14:33:35

2013-08-26 09:49:10

系统故障

2011-05-05 17:03:19

硬盘故障

2018-08-22 10:55:53

WindowsWindows 10系统故障

2009-04-26 15:56:32

vista驱动程序瘦身

2017-03-08 17:00:20

Windows 7Windows系统故障

2009-08-21 14:07:14

海缆系统故障光缆修复

2019-08-19 14:51:56

Linux 系统 数据

2010-08-17 15:09:45

综合布线系统故障

2010-11-02 09:53:57

点赞
收藏

51CTO技术栈公众号