XenServer下一个SR异常处理—记录篇

#
## XenServer下一个SR异常处理—记录篇
# 12年IT主机云/Xenserver6.0.2下HDS AMS2500存储SR异常


【简述】
近期，在“12年IT主机云新建项目建设工程”实施过程中，HDS AMS2500存储在XenServer环境下的一个SR（Storage Repository）出现异常。情况如下：
1） 在将3台XenServer下的VM迁移进存储SR时，能够顺利实现；
2） 试图将第4台VM往该SR中迁移时，出现错误：“The SR failed to complete the Operation”此外，无任何有用日志；
3） 该异常SR下的虚拟机运行时无任何异常迹象；
4） 无法在该异常SR下新分配存储空间。




【处理过程】
1） 尝试将该异常SR下的3台虚拟机迁到别的正常SR时，出现错误：“The SR failed to complete the Operation”，此外，无任何有用日志；
2） 试图对该异常SR下的3台虚拟机进行Snapshot时，出现错误：“The SR failed to complete the Operation”，此外，无任何有用日志；
3） 尝试关闭将该异常SR下的3台虚拟机（无论是通过命令关机、还是通过XenServer发出shutdown或force shutdown指令），无错误出现，但进程直接hang住，日志显示正在关闭虚拟机，但此时虚拟机仍然处于正常运行的状态；
4） 登陆异常SR下的虚拟机，创建文件，能正常读写，即虚拟机本身占用的存储空间使用正常；
5） 重新启动物理机后（此时虚拟机为断电后的关闭状态），发现该异常SR下的虚拟机仍然无法迁走。只好利用备份在其他SR下重新创建这3台虚拟机；
6） 删除该异常SR下的虚拟机后，仍然无法在该SR下迁进新的虚拟机，即该SR无法回收旧的存储空间或分配新的存储空间；
7） 试图在XenCenter中对该SR进行“Rescan”操作，系统报错：“The SR failed to complete the Operation”，此外，无任何有用日志；
在出错后，查看各个子节点的日志，未发现错误记录。在查看主节点日志时，发现如下错误：
Dec  4 17:51:16 xenserver212 xapi: [error|xenserver212|6136365 inet-RPC|uploadTask R:e5717c3954bc|import] Caught exception in import: SR_BACKEND_FAILURE: [ non-zero exit; ; Traceback (most recent call last):   File "/opt/xensource/sm/LVMoHBASR", line 220, in
<<此处省略大量输出>>


8） 似乎是主节点（xenserver212）无法识别该SR引起的，于是将主节点改为其他节点，再次对该SR进行“Rescan”操作，此时仍然是报：“The SR failed to complete the Operation”（XenServer的设计师词汇量太少了吧，就会这几个词？），并在新主节点上看到一长串和上一步错误类似的日志；
9） 既然Rescan扫不出来，那就试试“Repair”，涛声依旧，还是那几个错误及主节点上一长串换汤不换药的错误输出；
10） 既然无法修复，那就试试将其“Detach”掉，同上，还是那些错误日志，没啥新鲜的；
11） 直接“Forget”掉呢？没出现意外的惊喜，仍然无法Forget掉，错误也一样无法忘记；
12） 将日志发给XenServer工程师，厂家表示可能是HDS存储的异常，理由略；
13） 将日志发给HDS工程师，厂家表示可能是XenServer的异常引起，理由略；
14） 对存储进行排查，未出现错误；
15） 在出现异常11天后，存储的一个控制器出现告警，登陆存储控制台后，发现一个控制器状态为“Detach”（反映太慢了？），同时XenServer路径少掉一半；
16） 更换损坏的存储控制器，此时，所有的节点都能够与该异常SR连接，状态正常，对该SR进行“Repair”操作，顺利完成。似乎恢复了往日的宁静；
17） 试图将虚拟机迁到该修复的SR中，眼熟的一幕又粗线了：“The SR failed to complete the Operation”,然后还是主节点上那一长串的日志记录，问题依旧；
18） 尔后又尝试对该SR进行“Detach”及“Forget”操作，均以失败告终；
19） 尝试在主节点上重启XenServer的xapi，问题还是没解决；
20） 依照XenServer工程师的建议，重建存储的LUN，但因HDS存储无法在XenServer上定位具体是哪个LUN引起的，故未实施（理论上可以解决该问题），方案搁浅。
21） 转念一想，最淳朴的才是最有效的，只好祭出dd大杀器了，步骤如下：
1、 分别在两个有用到该异常SR的Pool下，对该SR进行“Repair”；
2、 将日志清空；
3、 分别在两个有用到该异常SR的Pool下，对该SR进行“Detach”（只能Detach掉部分节点，原因暂未知。通常主节点无法Detach掉）；
4、 分别进入两个有用到该异常SR的Pool的主节点，在命令行下对该异常SR前面的块进行dd操作（清空磁盘头，灭门该SR下全部数据）；
5、 此时分别在两个Pool中，“Forget”掉该SR（Forget了它重新开始）；
6、 回到XenCenter主菜单，在Tool下重新建立该SR；
7、 测试一下，ok，小功告成。




【注意事项】
1） 该方法仅适用于异常SR下的数据全部有备份，并利用备份在其他正常SR下重建后，该异常SR下的数据为无用数据时；
2） 即使没有备份，该异常SR下运行的虚拟机里面存放的数据还是可以读取的，甚至可以在虚拟机内进行写入操作，其下的虚拟机运行并不一定会受到直接影响。故要求趁早把虚拟机下的数据拷贝一份出来，然后再进行后续操作，防止虚拟机万一虚拟机宕机无法启动，处理就麻烦了；
3） 本例，对于11天后，存储控制器才出现告警及失效，暂无法确定是否因XenServer下的SR异常缘故影响存储日志的记录；对于SR异常锁死，暂未确定是XenServer还是HDS存储引起，需进一步排查；










E.O.F


2012-12-23