血的教训，大家以后当心

Eisen

一周之前，我正在暗自谋划春节放假怎么回家去呢。客户的一个电话，把我叫了过去把那个EMC Cx200的Lun重新指定一下SP，以期提高共享效率。
我心想这没什么的，就过去了。当把其中一个Lun的default owner从SPA指定到SPB之后，我开始做thepass。没料到就在这个时候，客户的那个该挨千刀万剐的死猪网管跑到机柜后面去看光纤交换机的灯怎么闪的，伸出一脚就踩掉了光纤交换机的电源！！！！我心想没问题，有两个光纤互为冗余呢，就笑笑让她走出来。
没料到就在这个时候，这个猪头(真是个猪头，现在怎么看她也是个母猪脑袋了)缩回一脚又把第二个光纤交换机的电源给蹬掉了………………
这下可好。赶紧全部关机，关CX200，重新……
好容易弄好，结果发现刚才正在thepass的LUN变成了Unknown Device了。而且怎么指定怎么thepass也无法从Unknown里拿出来了。赶紧急电Dell公司，Dell公司又一路问到马来西亚、新加坡、美国总部，都无法解决(听说这么两个光纤交换机在这几秒里先后掉电的情况，我这还是全世界第一次，真个要ft死过去)。急了大半夜，死也救不出来，而那个LUN上面正是应用最关键的数据库所在。555~~~~
最后还是只有unbind这个LUN重新再开一遍了。重新补数据的工作一直干到今天才补完。我的春节，我的休假………………啊啊！！！
事后，Dell公司这样告诉我。原来在第一个交换机断电的时候，LUN会自动thepass到另外一个SP上，而thepass过程中会先脱离原来的owner进入Unknown Device中，然后再从其中将其归属到另一个SP上去。而就在归属到Unknown时，另一个交换机断电，就使这个操作消失了，于是这个LUN就被永远留在了Unknown里拿不出来。唉……
在这里说一说，想请大家以后作thepass的时候一定要注意电源，千万不要发生我这样的惨剧，结果真的很伤人啊。

Eisen

[quote]原帖由 "大山"]按理讲EMC Clariion CX系列不该如此差劲，其内置电池应该支撑足够的时间完成tresspass。不过大家应该吸取教训，尽可能不让悲剧重演。正好我目前有环境可以测试，不过是CX600，测完通知大家。[/quote 发表：

再说一次啦……不是CX200掉电，而是与接受LUN的SP相连的那个光纤交换机掉电。
要真是CX200掉电而不是交换机掉电的话，那就好办了。CX200的电源会支撑完毕这个操作的，但是交换机掉电则使目标SP丢失，所以thepass完不成了。

大山

按理讲EMC Clariion CX系列不该如此差劲，其内置电池应该支撑足够的时间完成tresspass。不过大家应该吸取教训，尽可能不让悲剧重演。正好我目前有环境可以测试，不过是CX600，测完通知大家。

Eisen

原帖由 "david5337" 发表：
呵呵！这是很极端的情况，阵列柜的电源很重要。每做一次操作，都会有一个切换的过程。
但我有一个问题，Cache电池是可以保存设置的，难道没有用吗？！请Eisen确认！

哦……我脑袋都气昏了。不是CX200掉电，而是那两个光纤交换机先后掉电，而且非常精确地在一个thepass过程的一半先后掉电。真的是百年一遇啊……

foxsnow

thx

lsw

做技术的一句话------------胆大心细。

fanw

痛苦啊，同情的，我也有过相似的经历。哈哈

Eisen

to 咸鱼他哥
是的。当时那几个赶来的Dell工程师也是想登入SP，然后用命令行来强制制定该LUN的owner，但是很遗憾的是——SP的命令中没有这个命令。当然，数据确实也都还在那个LUN上没有丢失，但是LUN丢失和数据丢失的效果是一致的。

celling

咸鱼他哥，这只是一次意外的掉电，其中一个lun无sp接管，哪怕是关掉一个sp也是一样。虽然数据确确实实还在，但要恢复难度非常大。

david5337

且！如果在48小时内都还不能供电，或者是提供数据恢复的环境；那么，用户的数据丢掉是很正常的事情，不值得同情！48个小时，而不是48分钟！
48个小时的支持，已经足够了！
我同意 咸鱼他哥 的看法，所有的数据应该都在硬盘上，只是说系统没法识别；可以将RAID信息重新从硬盘读取出来！只是个建议，我没有实际操作过！