首页 > 硬件相关 > 一次netapp2050机头故障的修复经历

一次netapp2050机头故障的修复经历

2009年4月3日 发表评论 阅读评论

今天吃饭前,上网管机,惊现存储监控的页面上面闪红灯,紧急赶往机房一看,一台netapp2050的机头a处于关机状态,于是连机头b查看,机头b的cf status状态是FAS2050B has taken over FAS2050A. 目前存储处于机头b接管状态。

于是又输了几条命令查看了下机头b的状态,当输入stats show 之后,没有出现命令行,ctrl+c也无法退出到命令行,断开终端重连输入用户名和密码后还是处于无命令行状态,顿时抓狂。

联系了下售后,决定先找机头a当机原因,起出机头a,由于机头a处于Waiting for giveback状态(ctrl+c重启后autoboot还是这样),无命令行,web也无法进去,直接用nfs连也无法通过。

到此为止,基本情况就是这样,机头a处于Waiting for giveback等待状态,需要机头b进行giveback才能回到正常工作状态,但是进行这个操作必须在机头b进行命令操作,但是机头b无论串口还是telnet都无法出现命令行。
:???:
抓狂了一阵后,忽然想到rsh可以直接写命令进去,试了下
rsh 10.10.1.1 -l root:root rdfile /etc/log/messages

果然有戏,把机头a的日志给读了出来了,一看原来nvram的电池检测到问题,自动关机了
Thu Apr 2 20:00:27 CST [FAS2050A: kern.shutdown:notice]: System shut down because : “NVRAM BATTERY FAILURE”.

把日志发给售后,netapp那边一开始说发配件换电池把,后来又打电话说无法判断是电池还是充电模块问题,干脆换机头把。 :shock: …说等会给我确定送货时间,我一琢磨下一工作日岂不是要4天后才能搞定了 :evil:
等了一会,售后又打电话过来说netapp那边分析下来应该属于固件版本太低的问题,这个版本固件可能有点bug,电池是应该好的,让我直接giveback。 :???:

没办法客服的话总是要听的,rsh 10.10.1.2 -l root:root cf giveback 结果提示
Partner not waiting for giveback, giveback cancelled.
To do a giveback without checking for partner readiness, please either set optio
n “cf.giveback.check.partner” to “off” before doing “cf giveback” again, or do ”
cf giveback -f”.

The first choice disables checking for all future “cf giveback”, until it’s turn
ed back to “on”. The second choice is good for this giveback only.

客服说我插拔过机头用cf giveback -f,咱照做,果然有反应了
在机头b上面cf status,目前状态是
FAS2050B has taken over FAS2050A, giveback in progress.
giveback is in module “snapmirror”, 118 of 131 modules.

一阵等待后,提示ready for giveback,终于真不容易。。。。
继续 cf giveback
哗啦啦一堆信息滚过之后终于
Cluster enabled,2个机头都up了

最后按照客服提示options autosupport.doit 2000669538 导出一份autosupport报告发了过去。
客服说下周安排过来升级固件。

流水账就此结束,幸亏发现的及时,没有造成什么后果,这次经历之后我乖乖的还是把autosupport邮件名单添加了一份我的手机邮地址,可怜每个星期天半夜要被骚扰一次了。





分类: 硬件相关 标签:
  1. 2011年7月30日07:31 | #1

    Hey, that\’s poewrufl. Thanks for the news.

  1. 本文目前尚无任何 trackbacks 和 pingbacks.