我们应该如何在小型生物信息学集群中提供文件服务?

我们应该如何在小型生物信息学集群中提供文件服务?

我们有一个由六台 ubuntu 服务器组成的小型集群。我们在这些集群上运行生物信息学分析。每次分析大约需要 24 小时才能完成,每台 core i7 服务器一次可以处理 2 个分析,输入大约 5GB 数据,输出大约 10-25GB 数据。我们每周运行数十次。该软件是自定义 perl 脚本和用 C/C++ 编写的第三方序列比对软件的大杂烩。

目前,文件由两个计算节点提供(是的,我们将计算节点用作文件服务器)——每个节点都有 5 个 1TB SATA 驱动器,分别安装(无 RAID),并通过 glusterfs 2.0.1 池化。它们每个都有 3 个绑定的英特尔以太网 pci 千兆以太网卡,连接到 d-link DGS-1224T 交换机(300 美元 24 端口消费级)。我们目前不使用巨型帧(实际上不确定为什么)。然后通过 glusterfs 镜像两个文件服务计算节点。

其他四个节点均通过 glusterfs 挂载文件。

这些文件都很大(4gb+),并且如果重要的话,会存储为裸文件(没有数据库/等)。

您可以想象,这是一个有点混乱的问题,我们自然而然地发展起来,没有经过深思熟虑,现在空间已经不够了,我们想改善它。我们的分析是 I/O 密集型的,这是一个瓶颈——我们在两个文件服务器之间只能获得 140mb/秒,从客户端(只有单个 NIC)获得的速度可能只有 50mb/秒。我们的预算很灵活,我大概可以得到 5000 美元左右。

我们该如何花掉我们的预算?

我们需要至少 10TB 的足够快的存储空间来为所有节点提供服务。这种文件服务器的 CPU/内存必须有多快/多大?我们应该使用 NFS、以太网 ATA、iSCSI、Glusterfs 还是其他什么?我们应该购买两台或更多服务器并创建某种存储集群,还是一台服务器足以满足如此少量节点的需求?我们应该投资更快的 NIC(例如,具有多个连接器的 PCI-express 卡)吗?交换机?我们应该使用 raid 吗?如果是,是硬件还是软件?哪种 raid(5、6、10 等)?

任何想法都值得赞赏。我们是生物学家,不是 IT 专家。

答案1

我从事计算机科学领域,从事生物信息学研究。目前 746映泰:)

我在一所大学运营生物信息学计算设施已有 3 年(大约 40 台 Linux 服务器、300 个 CPU、100TB 磁盘空间 + 备份、总共约 1T RAM - 服务器的 RAM 范围为 16 到 256GB)。我们的集群有 32 个 8 核计算节点、2 个头节点,我们正在用另外 2 个 48 核计算节点对其进行扩展。我们通过 NFS 将文件提供给计算节点。

根据您的情况,我建议切换到 NFS。

我们考虑过切换到 Gluster、Lustre 和 Samba,但决定不使用它们。

NFS

我对 NFS 有几个主要的建议:

  1. 拥有一个专用的 NFS 服务器。为其配备 4 个核心和 16GB RAM。专用服务器更安全,更易于维护。它的设置更稳定。例如,有时您需要重新启动 NFS 服务器 - 专用服务器不会使您的磁盘访问计算失败 - 它们只会冻结并在 NFS 服务器恢复后继续运行。
  2. 仅为您的计算节点和头节点提供服务。无工作站。无公共网络。
  3. 使用 NFS 版本 3。根据我的经验,NFSv4 更脆弱 - 崩溃更多 - 更难调试。我们将集群从 NFSv3 切换到 NFSv4 并切换回来几次才稳定下来。这是一个本地网络,因此您不需要 NFSv4 的安全性(完整性和/或隐私性)。

存储硬件

我们当前的集群是 3 年前购买的,因此它没有使用 SAS,而是具有扩展的 FiberChannel 驱动器和控制器。这种情况正在改变,我们购买的所有新存储都是 SAS。

我建议考虑SAS存储。SAS 正在取代 FiberChannel,成为更便宜、更快、更好的解决方案。最近,我研究了提供的不同解决方案。我们研究的选项方便地记录在 Server Fault 中: 有哪些 SAS 外部存储选项(Promise、Infortrend、SuperMircro ......)?

我们最近从 RAID Incorporated 订购了一套 24TB 6Gb SAS - 6Gb SAS 存储系统。仅存储我们就花了 12,000 美元。订单应该会在几周内到货。这是一个无单点故障的系统 - 所有组件都是冗余的,如果任何组件发生故障,都会自动故障转移。它连接到 2 台服务器,每台服务器使用阵列的不同分区。这是一个交钥匙解决方案,因此一旦发货,我们只需连接它、打开电源,它就会工作(RAID6 分区将安装在 Linux 上)。订单还包括服务器,RAID Incorporated 正在免费在这些服务器上设置 Linux Debian。

其他考虑因素

不幸的是,如果您从事生物信息学基础设施操作,您可能需要成为一名存储专家。

对于 10TB 分区,请选择 RAID6 - 2 个驱动器发生故障不会丢失数据。将 2TB 驱动器重建到热备用驱动器需要 24 小时,在此期间其他驱动器可能会发生故障。我在 16 个驱动器阵列中同时遇到 2 个驱动器发生故障。

考虑将一个驱动器专门用作阵列中的热备用驱动器。当您拥有超过 16 个驱动器时,我认为热备用驱动器是必须的。

如果专用 NFS 服务器上的硬件出现故障,请考虑采取的行动计划。我会保留一个孪生节点作为计算节点,作为原始 NFS 服务器的潜在替代品。

最后,我必须提到我们的文件服务器正在运行 OpenSolaris(听起来很不寻常 - 我知道)。事实证明,OpenSolaris 具有出色的服务器硬件支持(FiberChannel、IniniBand 等)。从头开始设置 NFS 服务器需要 1 小时 - 所有步骤都非常简单:安装操作系统、通过 NAT 更新、设置网络、创建 zfs 池、创建 zfs 文件系统、共享 NFS。Sun 是 1984 年开发 NFS 的公司,因此 OpenSolaris 在服务 NFS 方面非常出色,这并不奇怪。使用 OpenSolaris 的主要原因是虚拟文件系统- A适合生物信息学的文件系统. 我喜欢的一些功能:

  • 完整性(所有写入都经过校验)
  • 池化存储、快照
  • NFS 导出在服务文件系统中进行配置
  • 在线压缩
  • 预订(座位保证)
  • 块级别重复数据删除
  • 高效备份(参见zfs send)。

使用 Linux 作为您的 NFS 服务器就可以了 - 在这种情况下坚持使用 XFS 或 Ext4。

答案2

您的预算不足以让您在 SAN 级硬件方面取得很大进展,但通过增强现有硬件,您应该能够获得更好的性能。获得一个不错的 RAID 控制器,购买更多磁盘,获得更好的交换机,也许还有一个好的多端口 NIC(获得不错的服务器级 NIC,如 Intel PRO 1000 GT 或 ET)。

如果您对 IO 模式的描述正确,则您的读/写比率为 15:85,因此您需要选择 RAID 10 才能提高 SATA 磁盘的吞吐量。考虑到您的写入偏好,如果您只是将当前驱动器重新配置为 RAID-5(或 RAID6,在这个规模下更可取),性能就会大幅下降。不过 RAID-10 会将磁盘的可用容量减半。

获得上述所有东西,以及足够的磁盘以在 RAID10 中提供 10TB 容量,只需 5000 美元,这是可行的,但这并非毫无风险。在这个问题如果您愿意承担风险并愿意构建自己的解决方案,那么它的答案值得考虑。

然而,我的主要建议是开始问自己(或签支票的人)存储故障实际上会给您的业务带来多少损失,以及您是否愿意承担这种风险。您的 5000 美元预算可能刚好允许您提高性能,但您谈论的是将 10TB 的业务关键数据和处理容量全部放在具有许多单点故障的基础设施上。现在可能是认真考虑这种基础设施的重要性并确定您是否有足够的预算来购买合适的入门级 SAN 或 NAS 解决方案的好时机。

答案3

你们的处理任务是自主开发的吗?它们是通过为每个节点分配一些数据块来处理而分布式的吗?

如果是这样,那么让流程更接近数据,而不是将数据提供给流程可能会更有效。这并不难,但需要一种与仅仅构建服务器不同的思维过程。

首先,在每个节点上放置一些驱动器。可能不是 RAID,每个节点上只有一个文件系统。将数据拆分到所有节点上的所有磁盘上,并在保存任务所需数据的节点上启动任务。尽量减少节点间传输。

当然,如果您的任务需要不可预测的数据部分,那么这些都行不通。

答案4

如果可以避免,我认为您很可能不想使用 ATAoE、iScsi 或 FC。这些都是块存储技术,并且更擅长从公共磁盘池为各个服务器提供磁盘空间。它们并非设计用于在客户端计算机之间轻松共享数据,除非您运行一些特殊的软件来处理具有元数据管理器等的共享文件系统。NFS
是基于文件的,旨在为您在多个服务器之间共享文件系统,并且是免费的。如果您需要按照 Javier 所说的那样,将数据移动到进程以进行计算,那么 Aleksandr 会为您指明正确的方向。如果您希望任何作业都能转到任何节点,那么 NFS 就是您的最佳选择。如果您可以预先将数据填充到节点并将需要特定数据的作业发送到拥有该数据的节点,那么吞吐量可能会更好。这就是 Hadoop、map/reduce 的做法。例如,如果您将小鼠基因组预先加载到其中一个节点,当有人针对该基因组执行 blast 作业时,您会将作业发送到已经拥有数据的节点。没有实际数据移动。但是,如果该节点拥有的数据集很受欢迎,并且当其他节点空闲时作业可能会备份,那么这可能会在该节点造成瓶颈。

最近与我合作的一些研究人员使用了一些“胖”节点或盒装集群。其中一位购买了一台 48 核(4 个 12 核 CPU)的 AMD 系统,其中有 128GB 的​​ RAM,花费了大约 15,000 美元。他的算法是高度并行的,因此对他来说,更大的核心数是有意义的。有了这么多的内存,Linux 就有足够的空间用于文件缓存,因此该机器上后续读取多 GB 数据文件的速度非常快。此外,使用他拥有的 raid 卡,他的本地存储每秒可以读取大约 300 MB。我不是说这台机器适合所有人,但它对他来说很合适。在我们把它给他使用之前,为了好玩,我在那台机器上对并行 bzip 作业进行了基准测试,将一个 3GB 的文本文件压缩到 165MB,大约需要 4 秒。(文件缓存在 RAM 中)。速度很快。

仅供参考,您将看到我们过去所说的高核心数机器的疯狂负载平均值。在这台机器上,20+ 的负载平均值相当常见,而且它的交互性能仍然相当强劲。

相关内容