我的问题具体与 ZFS/COMSTAR 有关，但我认为它通常适用于任何 iSCSI 系统。
是否应该为每个要公开的 LUN 创建一个目标？还是最好将多个 LUN 设置为一个目标？
这两种方法是否都会对性能产生影响？是否存在某种交叉点，使另一种方法更有意义？
用例是针对 VM 磁盘，其中每个磁盘 (zvol) 都是一个 LUN。到目前为止，我们已经为每个 VM 创建了一个单独的目标；但包含所有 LUN 的单个目标可能会大大简化管理……但我们可能需要每个单个目标数百个 LUN。（然后可能需要数十个启动器连接到该目标）
答案1
最佳实践是让多个 LUN 挂在单个目标上。总共有多少个目标各不相同，以及其中有多少个目标实际上暴露了相同的 LUN。我倾向于建议客户将设置的每个 MPIO 路径都有一个目标，因此如果我要设置系统，则至少会有 2 个目标（但它们只是同一目标组和目标门户组的一部分，并提供相同的视图 - 它完全适用于 iSCSI MPIO）。
超过 2 个 Target 的唯一原因通常是业务、网络或其他用例特定压力带来的逻辑分离。4、8 甚至多达 16 个 Target 并不那么疯狂，具体取决于环境的大小和复杂性。如果超过 16 个，尤其是超过很多，则很有可能您的架构存在错误，应该聘请专家进行审查。如果您正在使用 iSCSI MPIO（并且您必须，因为如果您不使用 iSCSI MPIO，那么 zvols 和 iSCSI 相对于文件系统和 NFS 的唯一主要优势可能会丧失，并且现在使用 iSCSI 而不是 NFS 的优势非常小，而缺点却非常多），您通常还应该有偶数个目标（2、4、6、8 等），每对都提供相同的视图（LUN）。
还请记住，COMSTAR 在处理视图方面足够智能，只要您实际创建并适当分配目标组和主机组，您就可以让单个目标提供数十甚至数百个 LUN，其中向传入启动器（客户端）公开的实际 LUN ID 不是 578 或其他数字，而是每个 LUN 的低至 0。这在处理某些客户端操作系统（例如 Linux（尤其是较旧的版本））时很重要，这些操作系统有一个坏习惯，即自动发现并分配它们找到的每个 LUN 的设备，并且它们可以处理的 LUN 数量是最大的，并且还有最大的“LUN 编号”（实际的 LUN 编号本身，而不是看到的 LUN 数量）。
我从未花时间量化它，但我的直觉是，你会感受到 128 个 Target 各自带有 1 个 LUN 的性能影响，就像 1 个 Target 带有 128 个 LUN 一样，或者 128 个 Target 的性能会略差。期待COMSTAR 是指您可以设置具有多个 LUN 的目标，而不是像 COMSTAR 之前那样每个目标设置 1 个 LUN。
关于您的总体环境的评论：
仅当虚拟机总数较少（少于 100 个，最好少于 50 个）或您没有考虑任何形式的高可用性（在池导出/导入时服务处于离线状态的情况下需要导出/导入池）的情况下，才应该为每个虚拟机创建单独的 LUN。
这与通过 COMSTAR over ZFS 导出/导入和完全初始化一组 LUN 所需的时间有关。每个额外的 zvol 都会使导入时间增加 X 毫秒。几十个 zvol 时没什么大不了，但当扩展到 1000 个时，很快就会出现明显的问题。我曾经管理过一台 Sun 7410，它有超过 3,000 个 zvol，占用了大部分时间15分钟使用其集群功能进行故障转移（本质上是从一个节点导出池并在进行手动故障转移时将其导入另一个节点，就像 15 分钟的怪物一样）。这在很大程度上是由于数据集的数量，更重要的是它们是 zvol。使用 3,000 个文件系统（不是 zvol）重复完全相同的场景仅花费 5 分钟（仍然很长，但已经缩短了 3 倍，这是几年前的事了。虽然自那以后，ZFS 完成这些任务的总时间有所改善，但据我上次检查，zvol 与文件系统的相对差异以及完全导入和上线的时间仍然存在。
现在，如果您的设置中没有 2 个或更多节点，并且希望在它们之间快速导出和导入，那么不拥有大量 zvol 的最大原因就消失了。但这仍然不意味着拥有 1,000 个 zvol 是一个特别好的主意，因为还有许多其他原因与您的问题不直接相关。将它们分开的好处在一定程度上被拥有大量 zvol 所带来的管理和性能痛苦所抵消。就我而言，我强烈建议改用 NFS，即使（哎呀，尤其如果您希望每个虚拟机一个数据集。
答案2
多个目标可增加您的潜在表面积。实际上，这取决于您的交换机与存储之间的链接数，以及您应该使用的专用 iSCSI 交换机之间的链接数。
这与散列和负载平衡以及您想要看到的路径数量有关。理想情况下，如果您的目标设备与网络之间有四条链路，则您应该有四个 IP 地址，并且可能使用第五个 IP 地址来“发现”目标。
因此唯一真正的答案是：视情况而定。