技(jì )术资料

本期我们精(jīng)心挑选了一次特殊的集群故障抢修案例，想和大家分(fēn)享一下心得體(tǐ)会。本次存储故障之“特殊”在于集群大，更在于问题怪……凭借敏锐的专业能(néng)力，奥工(gōng)小(xiǎo)分(fēn)队终于在尝试了很(hěn)多(duō)方法后发现了解决故障的办(bàn)法，有(yǒu)效保障了客户集群的正常运行。

01/问题介绍

本次项目中(zhōng)故障的超算平台，自建成以来在科(kē)研领域贡献非常突出。本次故障，则是因為(wèi)集群的异常断電(diàn)导致存储中(zhōng)所有(yǒu)阵列全部失败，无法读写，情况十分(fēn)紧急。奥工(gōng)服務(wù)小(xiǎo)分(fēn)队跟集群打交道这么多(duō)年，知道存储故障的修复一般从两方面入手，一个是网络，一个是底层存储，本次集群故障则属于第二种——底层存储出现了问题。

02/处理(lǐ)过程

当运维专组在日常运维过程中(zhōng)发现该集群的GPFS无法正常使用(yòng)，第一时间检查了GPFS的状态，并未发现异常。凭借多(duō)年工(gōng)作(zuò)经验，我们转而去检查了磁盘NSD状态，果然发现了问题。于是通过进一步仔细地排查，最终发现该集群的存储全挂了！相对于常见的只挂一两个盘，这一次竟然全挂了……这是少见且非常严重的故障！运维专组立刻召开紧急会议，力求争分(fēn)夺秒(miǎo)恢复集群正常运行。

奥工(gōng)服務(wù)小(xiǎo)分(fēn)队先设法从存储管理(lǐ)界面进行修复，发现无法修复，只能(néng)从命令行界面进行修复。常规操作(zuò)是，登录修复页(yè)面后，执行强制上線(xiàn)命令。我们在使用(yòng)手册（HELP）中(zhōng)很(hěn)快的找到了命令行的使用(yòng)方式——revive  array  [array name]，然后开始正常输入命令“01”“02”“03”……得到的却是一片“×Failed”。

尝试了很(hěn)多(duō)办(bàn)法，比如在原本手册给的[  ]外面加上“”、{ }或者‘’等等标点符号，或者将[  ]改成别的标点符号，但是都无济于事，集群存储的修复工(gōng)作(zuò)一度停滞下来、陷入了僵局。

不禁思考：难道使用(yòng)手册给出的命令行有(yǒu)问题？那不如换个思考角度，改变数字试试吧！有(yǒu)了这样的想法之后，我们开始在不变动命令行的前提下，随机尝试不同数字，然后发现revive  array  [24]该命令成功了。确定命令无误之后，我们把关注点转到了[  ]里面。在尝试了各种可(kě)能(néng)之后，惊奇地发现revive  array  ["01"]该条命令也成功了！和revive  array  [24]不同的是，多(duō)了一对双引号，且这个双引号用(yòng)在24这条命令中(zhōng)却是不成立的。

在命令行修复过程中(zhōng)，通过反复的尝试和验证，最终发现0开头的命令行必须在[  ]中(zhōng)加双引号，比如01、02、03……09，必须输入成revive  array  ["01"]、revive  array  ["02"]、revive  array  ["03"]……revive  array  ["09"]才可(kě)以正常识别，而非0开头的数字则不需要，可(kě)以直接输入。越过系统恢复最难的一道坎，接下来都是常规操作(zuò)，这里就不多(duō)说了。最终，奥工(gōng)服務(wù)小(xiǎo)分(fēn)队在最短的时间内，将24个阵列全部同时恢复，圆满的恢复了集群的正常运行。

03/经验总结

本次集群存储故障是一个很(hěn)大的警醒，从细节处保证集群安(ān)全和高效运营，是我们由始至终的使命！对此，想和大家分(fēn)享三点小(xiǎo)经验。

1、标点符号很(hěn)重要

处理(lǐ)过程中(zhōng)，大家对那个小(xiǎo)小(xiǎo)的双引号应该印象非常深刻了。奥工(gōng)小(xiǎo)分(fēn)队花(huā)了很(hěn)大精(jīng)力在寻找正确命令行上，小(xiǎo)小(xiǎo)的标点符号放在什么位置，竟然成了强制上線(xiàn)命令的关键。作(zuò)為(wèi)一名(míng)奥工(gōng)极客工(gōng)程师，每天和成千上万的数字标点打交道，我们深知标点符号的重要性，更深知“专业”就是不放过任何一个小(xiǎo)符号和任何一个小(xiǎo)细节。

2、足够的热备磁盘很(hěn)重要

因為(wèi)本次集群存储“全部故障”的特殊性，我们必须要提醒大家在集群存储恢复的过程中(zhōng)，关于硬盘使用(yòng)模式一定要再三注意。其中(zhōng)最重要的一点，修复阵列的前提是一定要保证存储有(yǒu)足够的热备磁盘可(kě)用(yòng)。

热备磁盘的作(zuò)用(yòng)相当于是在Raid阵列里多(duō)做一个备份，比如说本来Raid里面是只允许坏一个盘的情况下系统和数据依然正常运行，但是坏两个就不行了，但是加了热备之后就可(kě)以同时坏两个盘都没问题，等于多(duō)了个保险。在修复时，系统会自动先调用(yòng)热备磁盘参与阵列修复，同时利用(yòng)异或校验算法，把坏盘上面的数据原样做出来并存储在热备磁盘中(zhōng)，顶替原有(yǒu)异常或者损坏的磁盘，这个修复过程大概需要24小(xiǎo)时。恢复后，所有(yǒu)的异常磁盘恢复了正常，热备磁盘又(yòu)将恢复成热备磁盘。

因為(wèi)常见情况中(zhōng)磁盘阵列故障会少量的出现，往往只会坏几个盘，所以热备盘肯定都是够用(yòng)的。然后这一次整个集群阵列全部故障，算是极端的特殊情况，如果热备盘不够，问题就很(hěn)严重了。值得庆幸的是，这套存储当时非常有(yǒu)先见之明的配置了30块热备磁盘，整个集群共24个阵列，同时发生故障的情况下，热备磁盘的数量也绰绰有(yǒu)余。

3、電(diàn)源保障很(hěn)重要

这里要说到本次集群故障的源头问题了——异常断電(diàn)。可(kě)能(néng)每个运维工(gōng)程师听到“异常断電(diàn)”都会“异常头疼”，集群异常断電(diàn)带来的各种问题实在是让人头秃。对于集群而言，异常突发的電(diàn)路情况是无法从根本上避免的，我们在為(wèi)集群保障電(diàn)源安(ān)全、加强供電(diàn)的同时，也在不断完善强化异常断電(diàn)后的应急保障，力求在最短时间内恢复集群正常运作(zuò)。

但是，面对超算集群超大的耗電(diàn)量和相应的用(yòng)電(diàn)成本，如何平衡好“電(diàn)源”和“经济”又(yòu)是一个难题。针对集群中(zhōng)的关键设备，如核心的网络设备、存储设备、管理(lǐ)服務(wù)器等，往往会采取UPS不间断供電(diàn)方式，来保障数据安(ān)全不丢失。UPS的对電(diàn)源安(ān)全的保障效果非常显著，但是费用(yòng)高昂，并不适用(yòng)于整个集群。所以对于那些非必要的节点，提供普通供電(diàn)即可(kě)，避免不必要的浪费。这种普通供電(diàn)+UPS供電(diàn)相结合的方式，配以专业的断電(diàn)应急保障，足以保证集群供電(diàn)安(ān)全可(kě)靠的同时，有(yǒu)效节省超算集群的UPS建设和维护费用(yòng)。

本篇，关于我们恢复某大型集群存储的小(xiǎo)实践分(fēn)享就到此结束啦！但是，奥工(gōng)服務(wù)小(xiǎo)分(fēn)队的故事并没有(yǒu)结束，“成就客户/成長(cháng)自己”还在继续……