http://s6/middle/4ca83f83x7602322e1445&690&690

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

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

http://s9/middle/4ca83f83x9c15f5d4dab8&690&690

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

http://s14/middle/4ca83f83x9c15f5dca2cd&690&690

实际上，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地址上去了，天晓得“默认值”是哪一个呢，哈哈！

http://s8/middle/4ca83f83x9c15f5d04ea7&690&690

接下来就自动出现了目标
http://s4/middle/4ca83f83x9c15f5d028a3&690&690

选择连接到目标，照例点击“高级”选项
http://s12/middle/4ca83f83x76023231231b&690&690

清晰地指定IP地址
http://s12/middle/4ca83f83x9c15f5eea19b&690&690

OK了！盘挂上来了！
http://s13/middle/4ca83f83x9c15f638380c&690&690

虽然此时群集里还是显示失败，但是已不是问题
http://s3/middle/4ca83f83x9c15f60d4692&690&690

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

照前样配置NODE1
http://s3/middle/4ca83f83x76023238c4a2&690&690

然后资源联机（不要在OS磁盘管理器里做操作，群集的资源最好在群集管理器里操作）
http://s12/middle/4ca83f83x9c15f61c632b&690&690

都OK了！
http://s9/middle/4ca83f83x9c15f62bc718&690&690

启动先前关机的虚拟机
http://s9/middle/4ca83f83x9c15f64a37f8&690&690

一切OK
http://s16/middle/4ca83f83x9c15f64a50ef&690&690

iSCSI服务器端显示2块盘都“正在使用中”
http://s12/middle/4ca83f83x7602323d698b&690&690

最后，我迷信一点，让卷列表刷出来一下，希望它下次能记住配置吧
http://s16/middle/4ca83f83x9c15f665fdaf&690&690

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

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

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

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

所以， 

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

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

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