主页 / server / 问题 / 745072
Accepted
Criggie
Asked: 2015-12-24 16:15:10 +0800 CST

Xenserver、iSCSI 和戴尔 MD3600i

  • 772

我有一个带有两个节点的功能性 xenserver 6.5 池。它由戴尔 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 地址是 0.13，但缺少另一个节点 0.12

评论：

我在现有节点上实时运行生产虚拟机，并且无处可移动它们，因此重新启动 SAN 不是一种选择。

尽管 san 有 4 个接口，但在原始节点上禁用了多路径。这似乎是次优的，所以我在新节点上打开了多路径。

这三个新节点的系统负载非常高。原始盒子的平均负载为 0.5 到 1，三个新节点的负载约为 11.1，没有运行虚拟机。顶部显示没有高 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。

dell

2 个回答

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

    iscsiadm -m discovery -t st -p (MD3600i-primary-controller-IP-address)

    iscsiadm -m 节点 --loginall=all

    iscsiadm -m 会话

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

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

    我希望这会有所帮助，--托拜厄斯

    • 2
  2. Best Answer

    对于关闭，有很多事情是错误的。

    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 引起的。而谷歌恰好提供了这个我完全忘记的问题。只是表明为未来的读者提供封闭是多么重要……那个读者可能就是你。

    • 0

相关问题