iSCSI：每个目标的LUN？

最佳做法是让多个LUN挂起一个目标。 总共有多less个目标是不同的，以及这些目标中有多less实际暴露了相同的LUN。 我倾向于build议您的客户端设置一个MPIOpath的目标，所以如果我build立了系统，至less会有两个目标（但它们只是同一个目标组和目标门户组的一部分，提供相同的意见 – 这完全是为了iSCSI MPIO）。

通过2个目标的唯一理由通常是由业务，networking或其他用例特定的压力引起的逻辑分离。 4,8，甚至16个目标也不是那么疯狂，取决于环境的大小和复杂程度。 如果你超过16岁，特别是超过了16岁，那么你越来越可能在架构上犯了一个错误，并且应该聘请专家来进行评估。 如果您正在使用iSCSI MPIO（并且您必须这样做 ，因为如果您不使用iSCSI MPIO，那么可能是zvols和iSCSI over the filesystems和NFS的唯一主要胜利将会丢失，而且现在iSCSI的好处已经不大了通过NFS，绝对是不利的），你通常也应该有一个偶数的目标（2,4,6,8等），每一对都提供相同的视图（LUN）。

另外请记住，COMSTAR在处理视图方面足够智能，只要您实际创build和分配目标组和主机组，您就可以有一个目标提供潜在的数十甚至数百个LUN，其中实际的LUN ID暴露给传入的发起者（客户端）不是578或者什么，但是对于每一个可以低至0。 这在处理某些客户端操作系统时非常重要，比如Linux（尤其是旧版本），这些操作系统具有为每个find的LUN自动发现和分配设备的恶劣习惯，并且具有可以处理的最大数量的LUN并且具有最大的“LUN编号”（实际的LUN编号本身，而不是所看到的LUN的数量）。

我从来没有花时间对其进行量化，但是我的直觉反应是你会感觉到128个目标的性能影响与1个LUN的性能影响相同，你会感觉到1个目标有128个LUN，或者更差与128个目标的performance。 COMSTAR的期望绝对是你设置了具有多个LUN的目标，而不是每个目标的一个LUN，因为以前是COMSTAR的日子。

关于您的环境的一般评论：

对于每台虚拟机，只能在虚拟机总数较less（低于100，最好低于50）的情况下为每个虚拟机创build一个单独的LUN，或者在没有高可用性forms的情况下，需要导出/导入池服务处于离线状态，而池正在导出/导入。

这需要多长时间才能导出/导入，并通过ZFS通过COMSTAR完全初始化一堆LUN。 每个额外的zvol都会将X毫秒添加到导入时间。 在几十年没有什么大不了的，但是当你扩大到1000年的时候，迅速引起一个明显的问题。 我曾经pipe理过超过3000个zvols的Sun 7410，它花费了15分钟的时间来利用集群function进行故障转移（实际上是在执行手动故障转移时从一个节点导出池并在另一个节点上导入池）是15分钟怪物的情况）。 这在很大程度上是由于数据集的数量，另外还有zvols。 与3000个文件系统（不是zvols）重复的完全相同的情况只花了5分钟（仍然很长，但是已经很短了3倍，这是几年前的事情） zvols与文件系统的区别以及完全导入和在线的时间依然存在，最后我检查了一下。

现在，如果您的设置中没有2个或更多的节点，并且期望在它们之间快速导出和导入，那么没有大量zvols的最大原因就没有了。 这还不足以让1000人成为一个特别好的主意，因为其他原因与你的问题没有直接关系。 你们得到的好处让他们分开，有些是由于有大量的zvols引起的行政和表演的痛苦。 对于我的钱，我强烈推荐使用NFS，即使（ 特别是如果）你希望每个虚拟机有一个数据集。

多个目标会增加您的潜在表面积。 实际上，这取决于交换机与存储设备之间的链路数量，以及您应该使用的专用iSCSI交换机之间的数量。

它与散列和负载平衡以及您想要查看的path数量有关。 理想情况下，如果从目标设备到networking有四个链接，则应该有四个IP地址，可能有五分之一用于“发现”目标。

所以唯一真正的答案是：这取决于。