无法自动挂接iSCSI盘导致群集当机故障的解决方法

故障描述：此次POC，DPM与提供iSCSI的共享存储是在同一台主机(NODE4)上。由于DPM升级补丁时需要重启主机，即要关闭iSCSI共享存储，为了安全起见，我逐步将群集的2个节点先后关闭（先关闭备用节点NODE1、再关主节点NODE2，顺序反了会产生群集切换），然后我才打上补丁并重启了NODE4。然而，当我将主节点开机时，我却发现iSCSI不会自动挂接上来，仲裁盘和群集共享盘均认不到，重配置了一遍iSCSI目标和加载现有磁盘，并尝试多次刷新iSCSI客户端发起程序，都没有任何效果。然后我尝试启动备用节点，情况依旧。

 

这个群集是承载Hyper-V，用于实现Live Migration、虚拟机高可用特性的群集，有2台虚拟机具备高可用性，此时的SCVMM监测到状态为“丢失”

 

我查看了NODE4上的系统日志，显示iSCSI无效登录

实际上，iSCSI磁盘挂接的不稳定性，我已经不止一次遇到了。每次解决好象都是靠运气。就在这次POC安装刚开始时也遇到过，不论用iqn还是ip地址形式，客户端都刷不出磁盘，后来换了个TARGET名字，莫名其妙地磁盘就挂上来了，记得以前在虚拟机环境下做测试，重启群集也有丢失iSCSI盘的现象，很是让人郁闷。

 

接下来我到内部KB库里读了一堆的有关iSCSI、Wintarget、Storage Server....的EN文档，竞然有一个类似的，解决办法是将虚拟机怎么给从群集共享卷里弄出来，以单机的形式重新挂载到Hyper-V，还说要换个Wintarget新的版本，重建了群集,然后复制一份虚拟机....我的天，奇复杂无比！

 

下午我果断决定还是拉倒，我尝试研究一下iSCSI发起程序（客户端）的问题，果然，问题被我找到了：

 

群集节点有多个IP地址，iSCSI客户端数据包走错了网卡，数据包不能正常到达服务器端吧！

 

来看看我是怎么配置的，结合平常指南上说的iSCSI要用独立网卡、独立网段连接（此次未采用，iSCSI网络与生产网络是混在一起的，同一个网段，毕竞只是POC原型），就不难明白上述结论了。

 

当iSCSI服务器端配置好后，在客户端选择“高级”选项，这时连接方式中的“本地适配器”中一定要选择下拉列表中的“Microsoft iSCSI Initiator”项（默认认时显示“默认值”），这时“发起程序IP”中的下拉列表被激活，我看到了一串IP地址，搞了半天的我突然眼前一亮啊，iSCSI肯定是走到192.168.122.22地址上去了，天晓得“默认值”是哪一个呢，哈哈！

 

接下来就自动出现了目标

选择连接到目标，照例点击“高级”选项

 

清晰地指定IP地址

OK了！盘挂上来了！

 

虽然此时群集里还是显示失败，但是已不是问题

 

群集共享卷开始自动恢复，手动挂位于NODE1上的仲裁盘会显示操作失败，这是由于NODE1上的iSCSI发起程序还没有配置

照前样配置NODE1

 

然后资源联机（不要在OS磁盘管理器里做操作，群集的资源最好在群集管理器里操作）

都OK了！

 

启动先前关机的虚拟机

一切OK

 

iSCSI服务器端显示2块盘都“正在使用中”

 

最后，我迷信一点，让卷列表刷出来一下，希望它下次能记住配置吧


经过此番折腾，额外得出3个教训：

1、DPM要与iSCSI服务器端分开部署，不要混在1台主机上，这样打补丁不至于重启共享存储；

2、iSCSI要使用独立网卡、独立网段，iSCSI服务器不要连接在生产网上，这样路由起来也不会错，数据响应也更快、更安全；

3、iSCSI发起程序在连接时要清晰地指定IP地址；

 

 

 

所以， 

多数情况下，故障原因都是很简单的，

只要数据不丢失，不造成二次损伤，总是有办法的

--这些都算是哲学命题了。