iSCSI:每个目标的LUN？

Question

我的问题具体涉及ZFS/COMSTAR，但我假定它通常适用于任何iSCSI系统。

是否应该为您要公开的每个LUN创建一个目标？还是有多个LUN的单一目标是一个好的练习？

这两种方法都有性能影响吗？还有其他方法有意义的交叉点吗？

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

Answer 1

最好的做法是让多个伦吊在一个目标上。总共有多少目标是不同的，这些目标中有多少实际上暴露了相同的LUN。我倾向于推荐客户端将设置的每个MPIO路径中的一个目标，所以如果我正在设置系统，至少会有2个目标(但它们只是相同的目标组和目标门户组的一部分，并且提供相同的视图--这完全是针对iSCSI的目标)。

超过两个目标的唯一原因通常是业务、网络或其他用例特定压力带来的逻辑分离。4，8，甚至多达16个目标并不是那么疯狂，取决于环境的大小和复杂性。如果你超过了16，尤其是很多，你越来越有可能在架构上犯了一个错误，应该请一位专家来复习。如果您正在使用iSCSI MPIO (而且您必须使用，因为如果您不使用iSCSI MPIO，那么zvols和iSCSI对文件系统和NFS的唯一主要胜利可能就失败了，而现在在NFS上使用iSCSI几乎没有什么好处，绝对有很多缺点)，您通常也应该有偶数的目标(2、4、6、8等)，每对都提供相同的视图(LUN's)。

还请记住，COMSTAR在处理视图方面非常聪明，只要您实际适当地创建和分配目标组和主机组，您就可以有一个单独的目标，提供可能数十个甚至数百个LUN的LUN，其中向传入的启动程序(客户端)公开的实际LUN ID不是578，而是每一个LUN的最低值为0。在处理某些客户端操作系统时，这一点很重要，比如Linux (特别是旧版本的Linux)，它有自动发现和分配设备的坏习惯--它们发现的每一个LUN都有一个最大数量的LUN，并且拥有最大的LUN数(实际的LUN数本身，而不是LUN的数量)。

我从来没有花时间来量化它，但我的直觉反应是，你会感觉到128个目标的性能影响与128个目标相同，或者128个目标的性能略差。当然，COMSTAR的期望是，您正在设置多个LUN的目标，而不是每个目标1 LUN，因为以前都是COMSTAR前的日子。

关于你周围环境的评论：

我们应该为每个VM创建一个单独的LUN，只在VM的总数很低(低于100，最好是小于50)的情况下，或者在考虑到不需要导出/导入服务池时需要导出/导入池的高可用性的情况下，为每个VM创建单独的LUN。

这与导出/导入和通过ZFS通过COMSTAR完全初始化一组LUN所需的时间有关。每增加一次zvol，导入时间就会增加X毫秒。几十个并不是什么大不了的事情，但当你扩展到1000's时，很快就会产生一个明显的问题。我曾经管理过一个Sun 7410，它有3000兹沃尔，用了15分钟的大部分时间使用它们的群集功能完成故障转移(这实际上是从一个节点导出池，在手动故障转移时导入它，就像15分钟的怪物一样)。这在很大程度上是由于数据集的数量，而且更多的是因为它们是zvols。与3,000个文件系统(而不是zvols)完全相同的场景只需5分钟(仍然很长，但已经短了3倍，这是几年前的事了)。尽管在ZFS中完成这些任务的总时间在此后几年有所改善，但zvols到文件系统的相对差异以及完全导入和联机的时间仍然存在，最后我检查了一下。

现在，如果您的设置中没有2个或更多的节点，并且期望在它们之间快速导出和导入，那么没有大量zvols的最大原因已经消失。这并不能让他们中的1000‘S成为一个特别好的主意，因为许多其他的原因与你的问题并不直接相关。你得到的好处，让他们分开，在某种程度上抵消了管理和性能的痛苦，因为有大量的zvols。对于我的钱，我强烈建议改为NFS，即使(见鬼，特别是如果)您希望每个VM一个数据集。

Answer 2

多目标增加你的潜在表面积。实际上，这取决于您的交换机与存储的链接数量，以及您应该使用的专用iSCSI交换机之间可能有多少链接。

它与散列和负载平衡以及您希望看到的路径数有关。理想情况下，如果您有从目标设备到网络的四个链接，您应该有四个IP地址，并且可能有五分之一用来“发现”目标。

因此，唯一真正的答案是:这取决于。