关闭与客户端连接的 iSCSI 目标的正确方法是什么？

Question

具有两个 DRBD 主节点的 iSCSI如果两条路径同时收到写入请求，则使用这种方法是个坏主意。但我正在考虑将这个想法用作 ESXi 5.5U2 主机的后端存储。

我已经使用主/辅助配置和经典故障转移群集对此进行了测试。

此时 ESXi 所做的是检测多路径并仅主动使用一条路径。因此在这种情况下，并发写入 io 问题似乎不会出现。

现在两种情况 (主/次或主/主) 下的问题是：如何关闭具有与 iSCSI 客户端 (iSCSI 术语中的 iSCSI 启动器) 的活动开放连接的 iSCSI 服务器 (iSCSI 术语中的 iSCSI 目标提供程序)？

我目前在目标服务器上使用 CentOS 5。

CO5 使用 tgtd 提供目标。令我惊讶的是，如果有连接的客户端，常规停止方法会失败。相反，在这种情况下，forcedstop 似乎是我所需要的。

我想彻底关闭一台服务器（我必须停止对目标的访问，这样我才能将 drbd 切换到辅助服务器），然后另一台服务器应该自动变为活动状态（在我看来，在这种情况下没有什么可做的）。

该背景下的问题是：以下内容可以吗，或者我遗漏了什么？

1. 强制停止 tgtd（将首先使目标脱机）
2. 将 IP 拆除到启动器的方向（与用于 drbd-replication 的线路不同）
3. 关闭 drbd （先使其成为辅助）
4. 重启或关闭服务器

Answer 1

是的，我确实错过了一些东西。问题仍然是底层协议（SCSI）是有状态的协议。因此，即使我设法关闭目标（例如强制停止），它也会让活动启动器处于“挂起”状态。

但是：在我的用例中，这个问题有一个解决方案。

1. 在 vCenter 中禁用到某个 iSCSI 服务器的所有路径。
2. 这将有序地终止所有打开的 iSCSI 事务，并在另一条路径上打开到另一台服务器的新事务。
3. 此后，iSCSI 服务器可以安全地重启，无需客户端中断。
4. 在 iSCSI 服务器重新启动并运行后，可以通过在 vCenter 中启用这些路径来重新激活原始的 iSCSI 路径。

因此，我的问题的正确答案似乎是：

短的：没有合适的方法。您的客户端将会挂起。

长的：视情况而定。如果中间有一层能够先正确抑制/终止 iSCSI 流量，则可以随后终止目标（即使目标服务器仍然认为有连接的启动器客户端）。