最近有点坑,也是操作的时候考虑不周,缺乏危机意识,导致了一个存储设备的控制器故障。同时再处理故障的时候也发现了一些问题。

1、起因

修改存储管理系统的时间。存储一般为两个控制器,两个控制器要保持同步,但是再改时间的时候却没有考虑周全而进行了操作,导致故障发生。以后真得注意这种事情。

2、遇到的问题

流程图如图·1:
1-1.png

发现的其中一个问题:
原拓扑图是这样,如图2:
2.png

理论上,即使A控损坏「server1」和「server2」应该都能识别到B控,也不会造成『LUN』的失联。然而试试却恰恰相反,A控损坏之后,其中一部分机器无法识别到对应的『LUN』了。通过在存储管理系统上查看发现:「server1」其实是通过上图中4条蓝线连接到了A控,若A控损坏,那确实链路就断了。而实际上我们想要的效果是,「server1」通过两条蓝线,两条橙线连接;即使A控损坏也不会造成连接失败。

假如「server1」的两个光纤口为A、B;「server2」的两个口为C、D;A控的4个为a、b、c、d;B控的4个为e、f、g、h。
线路未更换的时候server的链路分别是:
server1:A-->a A-->b B-->c B-->d
server2:C-->e C-->f D-->g D-->h
实际效果图如图3和图4:

所以这就是导致A控故障之后,「server1」无法识别『LUN』的原因。
34.png

处理方式是,将交叉相连的蓝橙线分别交换一根,更换之后业务恢复正常,如图5:

5.png

更换线路之后,「server1」是可以识别到之前失联的『LUN』了。
此处有个概念,A和B控各4个光纤口,每个光纤口都有两个WWN号,一个是实际的HBA卡的WWN号,一个是虚拟的WWN号。虚拟的WWN号会随着线路的更换而漂移,也就是说d会漂移到B控上(例如d飘逸到了h上,此时B控的一个HBA卡其实有3个地址,1个实际WWN号,两个虚拟WWN号,如虚线所示,server就是靠虚拟WWN号识别线路)。我们在进行更换一条线之后,A控的更换线路的HBA卡的虚拟机WWN号也跟随着到了B控。这就导致线路连接正常的原因。更换线路之后,「server1」和「server2」的线路实际链路如图6和图7:
6-7.png

这虽然业务恢复,但实际上是这样的结果并不是我们想象的效果,并且在控制器恢复好之后,这条更换的线路竟然是断掉的状态。
这种交叉连接的方式是为了避免交换机的损坏引起的故障,但实际效果并不是我们想象的,继续下一步研究。

于是我们采取不交叉连接的方式,如图8:
8.png

OK,这样连接不就避免了控制器的损坏?然而事实并不如人意。等我们去存储管理系统查看的时候发现:「server1」仍然还是只识别一个控制器,「server2」也是;但是在物理链路界面查看的时候,物理链路是通的,也就是说server1应该能识别到B控,但是却识别不到。
最后终于发现,『LUN』是被某个控制器接管的,而非是被两个控制器接管(怀疑是这种情况引起的),实际效果如图8,就是无论怎么连,由于在mapping的时候,A控制直接接管了『LUN』。也就是说每新建一个『LUN』都会其中一个控制器接管,假如这个控制器故障了,那么就会悲剧如图9:
9.png

没找到好的办法,待故障恢复之后,又把线路连接回了交叉连接。