iSCSI：每个目标的 LUN？

Question

我的问题特别与 ZFS/COMSTAR 有关，但我认为一般适用于任何 iSCSI 系统。

是否应该为您想要公开的每个 LUN 创建一个目标？或者有多个 LUN 的单个目标是一种好习惯吗？

这两种方法对性能有影响吗？是否存在其他方法有意义的交叉点？

该用例适用于 VM 磁盘，其中每个磁盘 (zvol) 都是一个 LUN。到目前为止，我们已经为每个 VM 创建了一个单独的目标；但是包含所有 LUN 的单个目标可能会大大简化管理……但我们可能需要每个目标有数百个 LUN。（然后可能有数十个启动器连接到该目标）

Answer 1

最佳实践是让多个 LUN 挂在单个目标上。总共有多少个目标，以及这些目标中有多少实际上公开了相同的 LUN。我倾向于为您的客户将设置的每个 MPIO 路径推荐一个目标，因此如果我正在设置系统，至少会有 2 个目标（但它们只是同一目标组和目标门户组的一部分，并且是提供相同的视图 - 它完全用于 iSCSI MPIO）。

超过 2 个目标的唯一原因通常是业务、网络或其他用例特定压力带来的逻辑分离。4 个、8 个，甚至多达 16 个目标并不是那么疯狂，这取决于环境的大小和复杂性。如果您的年龄超过 16 岁，尤其是超过 16 岁，则您在架构中出现错误的可能性越来越大，应该聘请专家进行审查。如果您正在使用 iSCSI MPIO（并且您必须使用 iSCSI MPIO ，因为如果您不使用 iSCSI MPIO，那么 zvols 和 iSCSI 对文件系统和 NFS 的唯一主要胜利可能会丢失，现在使用 iSCSI 的好处很小超过 NFS，并且绝对有很多缺点），您通常还应该拥有偶数个目标（2、4、6、8 等），

还要记住，COMSTAR 在如何处理视图方面足够智能，只要您实际创建并适当地分配目标组和主机组，您就可以让单个目标提供潜在的数十甚至数百个 LUN，其中实际 LUN ID暴露给传入的发起者（客户端）不是 578 或其他什么，而是每个人都可以低至 0。这在处理某些客户端操作系统时很重要，例如 Linux（尤其是旧版本），它们有自动发现和为他们找到的每个 LUN 分配设备的坏习惯，并且有他们可以处理的最大数量的 LUN 看到并且还有一个最大的“LUN 编号”（实际的 LUN 编号本身，而不是所看到的 LUN 的数量）。

我从未花时间对其进行量化，但我的直觉反应是，128 个目标（每个目标具有 1 个 LUN）与 1 个目标具有 128 个 LUN 时所感受到的性能影响相同，或者稍差128 个目标的性能。COMSTAR绝对期望您设置具有多个 LUN 的目标，而不是像以前那样在 COMSTAR 时代之前为每个目标设置 1 个 LUN。

关于您的环境的评论：

只有在 VM 总数较少（低于 100，最好低于 50）的情况下，或者您没有考虑高可用性形式的情况下，才应该为每个 VM 创建一个单独的 LUN，在以下情况下需要导出/导入池池正在导出/导入时，服务处于脱机状态。

这与通过 ZFS 上的 COMSTAR 导出/导入和完全初始化一组 LUN 所需的时间有关。每增加一个 zvol，导入时间就会增加 X 毫秒。几十个没什么大不了的，但是当您扩展到 1000 个时，会迅速引起明显的问题。我曾经管理超过 3,000 个 zvol 的 Sun 7410，这需要15 分钟的大部分时间使用他们的集群功能进行故障转移（本质上是从一个节点导出池并在进行手动故障转移时将其导入另一个节点，就像 15 分钟的怪物一样）。这在很大程度上是由于数据集的数量，而且它们是 zvol。用 3,000 个文件系统（不是 zvols）重复完全相同的场景只用了 5 分钟（仍然很长，但已经缩短了 3 倍，这是几年前的情况。虽然从那时起，在 ZFS 中完成这些任务的总时间有所改善，但相对的zvols 与文件系统的差异以及完全导入和在线的时间仍然存在，最后我检查了。

现在，如果您的设置中没有 2 个或更多节点，并且希望在它们之间快速导出和导入，那么没有大量 zvol 的最大原因就消失了。由于许多与您的问题没有直接关系的其他原因，这仍然不能使其中的 1,000 个成为一个特别好的主意。将它们分开所获得的好处在一定程度上被大量 zvol 引起的管理和性能痛苦所抵消。为了我的钱，我强烈建议改为使用 NFS，即使（见鬼，特别是如果）您希望每个 VM 有一个数据集。