主页 / server / 问题 / 30657
Accepted
Kamil Kisiel
Asked: 2009-06-24 14:41:34 +0800 CST

Xen DomU 根文件系统在 iSCSI 虚拟 IP 故障转移上变为只读

  • 772

我的 Xen 服务器是 openSUSE 11.1，带有 open-iscsi 到我们的 iSCSI SAN 集群。SAN 模块位于启动器连接到的虚拟 IP 后面的 IP 故障转移组中。

如果主 SAN 服务器出现故障，则辅助 SAN 服务器将扮演目标角色。这一切都由 LeftHand SAN/iQ 软件处理，并且在大多数情况下都能正常工作。

我遇到的问题是，有时我的一些 Xen DomU 在 IP 故障转移后会使其根文件系统变为只读。它并不一致，并且每次发生故障转移时都会发生在不同的子集上。它们都运行相同的 openSUSE 11.1 软件映像。

每个 DomU 的根文件系统由 Dom0 中的 open-iscsi 挂载，然后 Xen 使用标准块设备驱动程序将其公开给 DomU。

确切的症状是作为 root 运行touch /test返回错误“只读文件系统”。但是， 的输出mount显示它正在以读写方式安装。当然，此时 domU 上的所有其他 I/O 也出现故障，因此机器严重停机。只需xm从 Dom0 重新启动它，甚至无需重新连接 iSCSI 会话，就可以让一切恢复正常。

在 Dom0 端，故障转移期间的 syslog 消息类似于以下内容：

kernel: connection1:0: iscsi: detected conn error (1011)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (1 attempts)

我很难弄清楚在哪一层调试这个问题，它是 DomU 内核中的东西吗？还是在 Dom0 或 Xen 级别？我认为某处可能有一些参数需要调整以增加某种超时，但我不确定在哪里看。

我真的不认为 open-iscsi 有问题，因为连接的块设备仍然可以从 Dom0 读取和写入。

xen linux iscsi

4 个回答

  1. Best Answer

    我最终通过使用 open-iscsi 文档中的以下建议和设置解决了这个问题：

    8.2 iSCSI settings for iSCSI root
---------------------------------

When accessing the root parition directly through a iSCSI disk, the
iSCSI timers should be set so that iSCSI layer has several chances to try to
re-establish a session and so that commands are not quickly requeued to
the SCSI layer. Basically you want the opposite of when using dm-multipath.

For this setup, you can turn off iSCSI pings by setting:

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0

And you can turn the replacement_timer to a very long value:

node.session.timeo.replacement_timeout = 86400

    如上所述设置与每个 LUN 的连接后，故障转移就像一个魅力，即使它需要几分钟才能发生。

    • 6

  2. 这听起来像是在 dom0 上运行的 iSCSI 启动器的问题。发起方不应该那么快地将 SCSI 故障发送到堆栈。您可能希望在 iscsi.conf 中设置 ConnFailTimeout，该设置确定在多长时间之前将连接失败视为错误并将该错误发送到 SCSI 堆栈。

    我还会研究故障转移实际需要多长时间，它可能比您预期的要长。如果是这样，由于 ARP 相关问题，VIP 故障转移可能会花费太长时间。

    • 2

  3. dom0 中是否有任何消息指示故障转移时出现任何类型的读/写错误或 scsi 错误？如果是这样，看起来这个写入错误正在传递给 domU。domU 不“知道”它是一个 iSCSI 设备，因此它的行为就好像底层磁盘已经消失并以只读方式重新挂载文件系统（参见 mount(1) 手册页 - errors=continue / errors=remount-ro / errors=panic）

    从 dom0 的角度来看，它不会变成只读的——这种只读行为是文件系统语义，而不是块设备语义。

    您此时提到“所有其他 I/O 都失败了”-您是指 domU 还是 dom0？

    通常在设置 HA iSCSI 解决方案时，我使用多路径而不是虚拟 IP 接管 - 它允许对主机有更大的可见性，并且您没有 iSCSI 会话突然消失然后需要重新启动 - 它总是在那里，只有其中两个. 在这种环境下这是一个选项吗？

    • 0

  4. 嗯...部分问题还在于您没有以 RO 身份运行/。安全方面的最佳实践表明您应该安装“/” ro，并且任何需要 rw 的文件系统都应该单独安装（即 /var 和 /tmp）。如果 /etc 下有需要写入的目录，则应将它们移动到 /var/etc/path 并符号链接到 /etc。

    “/”只能在单用户模式下挂载 RW。

    与其他建议结合使用时，以这种方式设置可以防止上述情况下的段错误。

    • -1

相关问题