基于 iSCSI 的 ZFS

基于 iSCSI 的 ZFS

我计划使用 ZFS 和 BSD 构建一个文件服务器,并且希望通过 iSCSI 连接存储在同一机架中其他机器中的驱动器,使其更具可扩展性(例如,一台机器正在运行 ZFS,其他机器具有可通过 ZFS 盒连接并添加到 zpools 的 iSCSI 目标)。

寻找其他尝试过此方法的人几乎让我找到了有关在 ZFS 之上公开 iSCSI 共享的资源,但没有关于反向操作的资源。我主要有以下问题:

  • 千兆以太网上的 iSCSI 是否足够快以满足此目的,或者我是否必须切换到 10GbE 才能获得不错的性能?
  • 当运行 iSCSI 目标的其中一台机器与网络断开连接时,会发生什么情况?
  • 是否有更好的方法可以做到这一点而我还不够聪明以至于没有意识到?

容量方面,最初约为 10TB 数据(不考虑冗余),可预见的未来合理目标是扩展到 20TB,因此考虑到冗余,总存储量可能约为 40-50TB。如果可能,我们还希望使用 GELI 加密所有数据。

谢谢你的帮助。

答案1

您在容量方面的目标是什么?这绝对是可能的,因为 ZFS 能够看到您的目标并将其聚合到池中。但是,您放弃了大量的性能和可靠性。

我对于扩展的建议(根据我假设的容量需求)是投资外部 SAS 多路径电缆驱动器机箱和 ZFS 友好型控制器。如果在这种情况下您需要的不仅仅是 24TB 可用的 RAID 1+0 存储,那么外部机箱装有 2TB 磁盘,那么专家的设计建议将对您大有裨益。在这种级别,使用其他系统中的磁盘的 iSCSI 不会让速度更快。

iSCSI 设计将会因为延迟、可靠性和可支持性原因而失败。

答案2

至于您关于以太网上的 iSCSI 的问题 - iSCSI 几乎是您能找到的最快的协议。它基本上是通过线路直接访问磁盘块。它将占用相当多的千兆位 NIC。

关于网络上丢失目标的问题,我见过的(几乎)每个 iSCSI 目标实现都支持某种多路径。我认为 open-ietd 可能还不支持多路径。最糟糕的情况是,您使用的是日志文件系统;当目标重新上线时,您可能必须重播日志。我还没有因为存储服务器丢失而损坏 iSCSI 上的文件系统。

答案3

注意:我实际上没有这样做过,所以对此持保留态度。我在阅读有关 ZFS 的文章时看到过对此的提及,但现在找不到这些参考资料……

您希望将每个物理磁盘导出为单独的 LUN,以便 ZFS 能够完全了解物理布局。这对于它做出有关 IO 调度和复制的正确决策是必要的。

千兆以太网上的 iSCSI 是否足够快以满足此目的,或者我是否必须切换到 10GbE 才能获得不错的性能?

这取决于磁盘的速度、磁盘数量以及您想要实现的性能。15k RPM 磁盘的传输速度最高可达 105MiB/s,即 840Mbit/s。通过单个千兆链路访问多个这样的磁盘将使链路饱和,并使您的网络成为瓶颈。找到您要使用的磁盘的最大速度,乘以磁盘数量,您将得到支持该速度所需的网络带宽。

当然,这假设您希望从 ZFS 服务器获得最大性能。如果您只有少数客户端以超过 100Mbit/s 的速度连接,则没有必要这样做,因此请计算您预期的最大需求。请记住,如果您使用 RAIDZ1/2/3,则磁盘的带宽略高于客户端带宽,当然,如果服务器通过与客户端访问服务器相同的 NIC 访问磁盘,则需要共享此带宽。

当运行 iSCSI 目标的其中一台机器与网络断开连接时,会发生什么情况?

ZFS 会认为磁盘不可用。如果您使用的是 RAID1/2/3,这不会中断对客户端的服务。如果您配置了热备用,ZFS 将开始将数据重新同步到该热备用。当 iSCSI 目标恢复时,ZFS 应该会再次开始使用它,假设启动器会自动重新连接。(不过您应该测试一下。)

相关内容