Dell

Xenserver、iSCSI 和戴爾 MD3600i

  • September 1, 2021

我有一個帶有兩個節點的功能性 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。

對於關閉,有很多事情是錯誤的。

  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 引起的。而Google恰好提供了這個我完全忘記的問題。只是表明為未來的讀者提供封閉是多麼重要……那個讀者可能就是你。

如果 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 連接位於相同子網上的那些。

我希望這會有所幫助,–託拜厄斯

引用自:https://serverfault.com/questions/745072