☰

Xenserver，iSCSI 和 Dell MD3600i

tag-icon • tag-icon dell iscsi xenserver
Xenserver，iSCSI 和 Dell MD3600i

我有一个功能齐全的 xenserver 6.5 池，有两个节点。它由 Dell MD3600i SAN 上的 iscsi 共享支持，运行良好。它是在我之前设置的。

我们已向池中添加了三个节点。然而，这三个新节点不会连接到存储。

这是原始节点之一，运行良好：

[root@node1 ~]# iscsiadm -m session
tcp: [2] 10.19.3.11:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [3] 10.19.3.14:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [4] 10.19.3.12:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [5] 10.19.3.13:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)

这是新节点之一。注意到地址中的损坏了吗？

[root@vnode3 ~]# iscsiadm -m session
tcp: [1] []:-1,2 ▒A<g▒▒▒-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [2] 10.19.3.12:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [3] 10.19.3.11:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [4] 10.19.3.14:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)

缺失的 IP 地址是 .13，但另一个节点缺少 .12

评论：

我在现有节点上实时运行生产虚拟机，但没有地方移动它们，因此重新启动 SAN 不是一个选择。

尽管 san 有 4 个接口，但原始节点上的多路径功能已禁用。这似乎不是最佳选择，因此我在新节点上启用了多路径功能。

三个新节点的系统负载非常高。原始机器的平均负载为 0.5 到 1，三个新节点的负载约为 11.1，没有运行任何虚拟机。top 显示没有高 CPU 进程，所以这与内核有关？没有进程锁定在状态 D（不可中断睡眠）

如果我告诉 Xencenter“修复”这些存储库，它会一直等待几个小时，直到我点击取消。消息是Plugging PDB for node5

问题：如何让我的新 xenserver 池成员看到池存储并按预期工作？

编辑更多信息

  • 所有新节点都无法进行干净重启 - 它们在重启时卡在“停止 iSCSI”中，我必须使用 drac 来远程重新启动它们。
  • Xencenter 坚持认为节点处于维护模式并且尚未完成启动。

好池节点：

[root@node1 ~]# multipath -ll
36f01faf000eaf7f90000076255c4a0f3 dm-36 DELL,MD36xxi
size=3.3T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=12 status=enabled
| |- 14:0:0:6 sdg 8:96  active ready running
| `- 15:0:0:6 sdi 8:128 active ready running
`-+- policy='round-robin 0' prio=11 status=enabled
  |- 12:0:0:6 sdc 8:32  active ready running
  `- 13:0:0:6 sdh 8:112 active ready running
36f01faf000eaf6fd0000098155ad077f dm-35 DELL,MD36xxi
size=917G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=14 status=enabled
| |- 12:0:0:5 sdb 8:16  active ready running
| `- 13:0:0:5 sdd 8:48  active ready running
`-+- policy='round-robin 0' prio=9 status=enabled
  |- 14:0:0:5 sde 8:64  active ready running
  `- 15:0:0:5 sdf 8:80  active ready running

坏节点

[root@vnode3 ~]# multipath
Dec 24 02:56:44 | 3614187703d4a1c001e0582691d5d6902: ignoring map
[root@vnode3 ~]# multipath -ll
[root@vnode3 ~]#                           (ie no response at all, exit code was 0)

坏节点

[root@vnode3 ~]# iscsiadm -m session
tcp: [1] []:-1,2 ▒A<g▒▒▒-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [2] 10.19.3.12:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [3] 10.19.3.11:3260,1 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)
tcp: [4] 10.19.3.14:3260,2 iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb (non-flash)

[root@vnode3 ~]# iscsiadm -m node --loginall=all
Logging in to [iface: default, target: iqn.1984-05.com.dell:powervault.md3600i.6f01faf000eaf7f900000000531ae9bb, portal: 10.19.3.13,3260] (multiple)
^C iscsiadm: caught SIGINT, exiting...

因此，它尝试登录 SAN 上的 IP，但却旋转了几个小时直到我点击 ^C。

答案1

如果 iSCSI 发现不起作用，则可能是 XenSerever 主机、MD3600i 或两者上的 IQN 无法相互识别。使用 Dell 的 MDSM 实用程序确保允许 MD3600i 从所有 XenServer 主机上的所有 IQN 进行访问，然后尝试重新进行 iSCSI 发现：

iscsiadm -m discovery -t st -p (MD3600i-主控制器-IP 地址)

iscsiadm -m 节点 --loginall=all

iscsiadm -m 会话

如果您有网络访问权限，您至少应该能够从 XenServers ping MD3600i 的主 IP 地址。

还要注意，您需要首先在与每个新 XenServer 关联的 NIC 上设置单独的 iSCSI 接口，并为这些接口分配唯一的静态 IP 地址，并且这些地址与其他主机的 iSCSI 连接位于同一子网中。

希望这些能有所帮助，--Tobias

答案2

最后，发现有多个地方出了问题。

  1. 主机配置为 1500 字节 MTU，而存储 SAN 使用 9216 字节 MTU。
  2. 其中一台主机的 IQN 与实际情况略有不同 - SAN 将正确的 IQN 列为“未分配”，即使它看起来与正在使用的 IQN 相同。
  3. 我原来的两个节点在其板载 1 Gbit 卡上配置了管理 IP。三个新节点在绑定接口（位于 VLAN 中）上配置了可接受的管理 IP。这太不一样了，并且基本上阻止了新主机在启动后退出维护模式。

多路径似乎与这个问题根本没有关系。

删除并摆弄 xenserver 节点上的 /var/lib/iscsi/* 中的文件对问题没有影响。

我不得不使用其他方法来重新启动这些较新的盒子 - 它们会卡住并试图停止 iscsi 服务。

最后，可见的 IQN 名称损坏iscsiadm -m session 已完全消失。这可能与 MTU 不匹配有关。

对于未来的互联网搜索者来说 - 祝你好运！

编辑：2021 年 9 月，我遇到了完全相同的问题，使用的是戴尔 MD3800 SAN 和一些 xcp-ng 服务器。同样，这是由 MTU 不匹配引起的。而谷歌恰好提出了这个问题，我完全忘记了。这说明为未来的读者提供结局是多么重要……那个读者可能就是你。

相关内容