悲剧的周末遭遇。遇上iscsi兼容性问题了 ESXi4升级ESXi5 后端是NX3100

seanlaser

本帖最后由 seanlaser 于 7-23-2012 17:39 编辑
整个周末就是个悲剧~
周五晚间在升级过程中，先是遇到iscsi读取延迟大大超过写入，诊断下来，排除了网络等诸多问题后，发现NX3100上的RAID盘阵列在报即将坏盘！这就是第二天的晚上事情了！
连夜保修更换，总算在半夜前rebuild好了，看上去好了很多。rebuild过程中继续升级其他几台，结果发现多台上面内存报错，由于是AdvECC模式，少的丢了一个列的就是1/4，多的丢了N个 12G的居然只有2G了！因为是N久不关机的，继续升级并尝试主板放电恢复内存。并且继续联系保修，这就是第三天早上的事了！！
精彩的来了，全部ESXi升级完成后，持续的发生iscsi target 心跳丢失重新连接的现象！找到关键性提示的报错信息：iscsi启动端提交了一个协议错误，吐血啊，这都第三天中午了！全部的服务除了在本地存储上的和不依赖硬盘读写的 几乎全都有问题。
这个过程，顶着老大多番催促，开始紧急拯救。过程极其坎坷，现在实在写不动了！总算在下午2点开始陆续恢复服务。
先列出此次的环境，大家谈论下各自的看法和解决方法
ESXi4.1*N的EVC群集 启用了DRS 未启用HA（资源跑太满无法HA）
NX3100 microsoft iSCSI Target 3.3 提供iSCSI服务 本身是WSS08r2提供文件服务和NFS服务
全千兆网络
现在还有个疑问，实在没有力气Google了（都奋战N天了才间或眯了8小时），在此贴出来求救吧
一个target的vhd副本或者快照，挂到另一个target再连回同一个esxi，添加datastore的时候会问下列3个选项
1 保留现有数字签名并挂载
2 写入新数字签名并挂载
3 格式化
除了3肯定不选外，1和2应该选哪个？
选1有什么风险么？选了1后怎么处理后续可能的问题？
选2有什么风险么？选了2后怎么处理后续可能的问题？

seanlaser

本帖最后由 seanlaser 于 8-11-2012 14:38 编辑
关于存储重签名的问题
事实上1和2都会用到哦
1用来确认你的snapshot恢复出来的存储是否可用。这时候不会对此存储的签名发生任何变动。VM照样可以用，甚至单挂的这台ESXi上面VM都不需要重新添加。这个时候是留给大家缓冲时间的。如果原来的存储问题修复了，那么就不需要这个snapshot了。可以重新连上旧的存储，最大限度的保留全部配置，无需变动。
2 如果很不幸，你原来的存储无法修复。需要将这个恢复出来的存储作为永久使用的话，那么就需要将这个无变更签名的存储卸载掉，重新添加时选择写入新签名，保留数据。只有经过这个操作的存储恢复才能被多个esxi同时挂载。同样由于存储签名变更，VM需要重新添加，原来的会变成孤立不可用，需要移除。这个过程中会有可能有UUID冲突的问题，可能发生网卡mac重新写入的问题，要注意检查IP地址。

seanlaser

本帖最后由 seanlaser 于 8-11-2012 14:52 编辑
和Dell的TS折腾了2周，未果。
期间收集了VMware log、NX3100 log、windows log等等。
最后升级到Enterprise支持，给我个结论：
这事情吧得找VMware……我们建议重新清洁安装ESXi5
于是只能再申请一个晚上的维护窗口做迁移和重新安装。不过这次由于不用顶着问题，相当顺利。
·#%·！问题当天就Google出来的东西，Dell分析了2周给我同样的解决方案，实在是令人倍感无力。
而且这个问题进一步的Web搜索貌似不仅出现在VMware Esxi上，某些其他的（例如suse ）Linux也有发生对于特定iscsi Target的协议问题。
当然对于VMware是否能解决这个问题，早就得知了：VMware不支持所有不在其兼容列表上的存储。
因此教训就是
1 vSphere存储还是老老实实采购列表上的，起码不论存储厂商还是VMware都会有人切实负起排除问题的责任。
2 vSphere最好还是别原地升级，轮转迁移保险很多。

jar

建议先选1，不行再选2，3肯定不能选。
预祝LZ搞定回家休息。

seanlaser

我选了1了 不过只有1台esxi能看到这个vmfs，其他的就直接选项变成仅3可选了，瀑布汗！
我也可以再试图选2，不过那要另外再等一次备份……那起码又是4-5小时后的事情了！
实在没有体力了……

TiGi

本帖最后由 TiGi 于 7-23-2012 18:35 编辑
你说的“1”、“2”、“3”，这个我遇到过一次，当初是在本地存储上 —— 原本我是将ESXi装载本地存储上的，后来改装到U盘，然后挂载本地存储的时候，遇到了错误：
一开始，是选择了保留现有数字签名并挂载
选择保留之后，系统提示无法挂载。
因为上面没有实际数据，所以之后尝试选择“2”写入新数字签名并挂载
结果无法写入。
这个问题，后来没有深入下去。
依稀记得，后来我是在RAID卡内重建RAID（因为我调整了RAID策略，所以去重新构建RAID了），然后再进入，没有遇到类似的情况。
你那里，因为上面有数据在，建议慎重。
     
所以，个人觉得，存储内的快照/复制，还是有其意义所在的。

TiGi

http://www.vmware.com/files/cn/p ... erver_config_cn.pdf
P87、P88。
ESXi5内 —— 存储指南， P110-P112。

seanlaser

感谢！不过就如你所说的这个是有数据的，而且一旦操作失败意味着4~5小时的Downtime。
因此我觉得还是先另搭环境测试下先，至少确认了重新签名后，能让多台自动识别才行。
睡了几个小时，又发现另外一个存储挂了。还好只是一个nfs，另外只有一个clone的监控用VM在上面！损失算是小的了！天啊，这什么情况啊，怎么那么多事情都在这里发生啊！！我被诅咒了么？

star_xin

楼主这个周末辛苦了～  NX3100 除了有块盘坏了之外， 是由于什么原因造成 加载 iscsi 不成功呢？ microsoft iSCSI Target 3.3 的功能问题？

seanlaser

nx3100上应用日志 错误事件id 117 来源wintarget
iSCSI 发起程序 iqn.1998-01.com.vmware:XXXXXXXX 已经提交了一个协议错误。
这个错误24小时内收到507个，一周内（其实从升级后才开始的）收到35205个
另外 信息事件id20和21 来源wintarget 一周内各有超过17300个
20 iSCSI 发起程序 iqn.1998-01.com.vmware:XXXXXXXX 已成功登录到 iSCSI 目标
21 iSCSI 发起程序 iqn.1998-01.com.vmware:XXXXXXXX 已从 iSCSI 目标注销

TiGi

前面我做了一个实验，和你的情况有较大的差异性，仅供参考。
我新建了一个"LabLun"，Lun上有虚拟机。虚拟机正常运行状态下，在EQL内执行了快照。
然后将快照“Online”（此时，原本的Lun仍旧在线，且VM也开着）。
主机添加存储器，然后出现三个提示“保留现有的签名”、“分配新签名”、“格式化磁盘”。
我选择“保留现有的签名”，结果报错：
我尝试卸载或者删除"LabLun"都不行。将虚拟机“从清单中移除”后，能够卸载。再“添加存储器”、“保留现有的签名”，还是报错。在主机、配置、存储器、数据存储内将“LabLun”（呈现灰色）删除，再“添加存储器”、“保留现有的签名”，添加成功。

jqunjian

LZ是升级到5.0还是5.0.1？通过什么方式升级？VUM还是单机升级包？
根据相关的现象跟以下的链接情况有点相似，你可以尝试更新到5.0 U1
http://kb.vmware.com/selfservice ... ;externalId=2008144
http://vmtoday.com/2012/02/vsphere-5-networking-bug-affects-software-iscsi/

seanlaser

4.1直接升级5.0Update1而且是从 Dell官网下载的客制的ISO，用Update Manager升级的。
升级本身没有任何问题，只是与ms iscsi target3.3兼容性问题。
当前想办法把vhd复制到win2012RC上去用这个自带的iscsi Target功能挂起来了，貌似报错什么的都没有了，速度也不错。只是选择了1 结果仅1台可见。已经把关键的业务VM挂起来了，有了缓冲时间设法搞点其他的了。
正搭建模拟环境，测试重建iscsi Target后的步骤

24242625

UUID冲突的话 存储当然挂不上 无论是快照还是副本 不重新签名的话
UUID当然是一样的

seanlaser

做选项1前 是需要将原来的lun offline的，不然会有挂载冲突。