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

9

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

如果主SAN服务器发生故障，则辅助SAN将充当目标服务器。所有这些都由LeftHand SAN / iQ软件处理，并且在大多数情况下都可以正常工作。

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

每个DomU的根文件系统都是通过open-iscsi装入Dom0的，然后Xen使用标准块设备驱动程序将其公开给DomU。

确切的症状是，以根用户身份运行时touch /test返回错误“只读文件系统”。但是，的输出mount显示它是可读写安装的。当然，此时domU上的所有其他I / O也会发生故障，因此机器会严重掉下来。只需xm从Dom0 重新启动它，甚至无需重新连接iSCSI会话，即可使一切重新工作。

在Dom0端，故障转移期间的系统日志消息如下所示：

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读取和写入。

linux xen iscsi

— 卡米尔·基西尔（Kamil Kisiel）
source

6

我最终通过使用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的连接后，即使需要花费几分钟时间，故障转移也像超级按钮一样起作用。

— 卡米尔·基西尔（Kamil Kisiel）
source

1

我与坐在iscsi卷上的mysql prod db有相同的问题，在/ var / log / messages和文件系统处于只读模式时存在相同的错误。这个技巧解决了这个问题。

— RainDoctor 2010年

2

这听起来像dom0上运行的iSCSI启动器有问题。启动器不应迅速将SCSI故障发送到堆栈。您可能需要在iscsi.conf中设置ConnFailTimeout，此设置确定在认为连接失败是错误之前将错误发送到SCSI堆栈的时间。

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

— 斯科特·多德森
source

我认为这正是我所需要的。

— 卡米尔·基西尔

0

dom0中是否有任何消息指示故障转移时出现任何类型的读/写错误或scsi错误？如果是这样，则看起来此写入错误正在传递给domU。domU并不“知道”它是iSCSI设备，因此其行为似乎是基础磁盘已消失并以只读方式重新安装文件系统（请参见mount（1）联机帮助- errors=continue / errors=remount-ro / errors=panic）

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

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

通常，在设置HA iSCSI解决方案时，我使用多路径而不是虚拟IP接管-它提供了对主机更大的可见性，并且您没有iSCSI会话突然消失然后需要重新启动-它始终存在，只有两个。在这种环境下可以选择吗？

— 米奇
source

更新了原始说明，并回答了您的问题。我想我可以考虑使用多路径，但是该系统更适合于以当前形式进行虚拟IP故障转移。我不确定块级复制将如何与多路径配合使用，特别是因为其中一个SAN单元需要指定为主节点。感谢您向我介绍有关文件系统的部分。我认为几乎可以解释这一点。我想我可以尝试将其切换为“继续”模式，或者可以考虑将文件系统更改为更具弹性的东西，例如XFS。

— 卡米尔·基西尔

1

ext3本质上没有任何坏处-XFS也会遇到类似的问题。而且我不建议使用onerror = continue-系统将认为该块不可读，并且您将丢失数据。多路径不是镜像-您无需担心主机上的任何复制。您只需通过iSCSI连接到主目标和辅助目标，主机就会知道，如果主服务器发生故障，则不要将错误传递到堆栈上，而是尝试针对次目标的相同命令。

— MikeyB

我对复制的评论是关于两个SAN服务器需要同步其数据这一事实。在内部，我认为该系统的工作方式与drbd类似，其中一个单元（当前拥有VIP的单元）为主机。它可能适用于多路径，但是我真的很想解决这个问题而不必离开当前的体系结构。否则，应该有一种方法可以使此工作正常进行，我的直接安装iSCSI卷的系统永远不会出现卷变为只读的问题。

— 卡米尔·基西尔

-1

嗯...部分问题还在于您没有以RO身份运行/。最佳实践安全明智的做法是，您应将“ /”挂接到ro上，并且需要rw的所有文件系统都应分开挂载（即/ var和/ tmp）。如果/ etc下有需要写入的目录，则应将它们移至/ var / etc / path并符号链接至/ etc。

“ /”只能以单用户模式安装在RW上。

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

— 米格尔
source

2

您确定要回答正确的问题吗？

— 卡米尔·基西尔