适用于大文件服务器的Linux文件系统

适用于大文件服务器的Linux文件系统

我想从更有经验的人那里了解,对于拥有超过 20TB 硬盘的文件服务器,最好的文件系统选择是什么。就我个人而言,我总是在我的个人电脑和“小型服务器”BOOT 和 ROOT 磁盘上使用 EXT3(过去)和 EXT4(自从推出以来)[曾经使用过 ReiserFS 3,尽管它导致了许多数据损坏]。

然而作为 EXT4工具(虽然不是 EXT4 本身)仅限于 16TB 分区,这可能不是我的最佳选择。发行版将是 Debian 6.0(Squeeze)和/或 Gentoo(最新版本),因此内核应该相当新(在 Debian 上至少有反向移植),这意味着 Linux 内核 >= 2.6.32。

文件服务器主要用于三个目的(以及分离的分区,因为目的是保证数据“安全”而并不真正关心开销)。 所有磁盘均使用 LUKS 加密

  1. 媒体、下载和本地 Debian 存储库 [我至少有 6 台机器运行 Debian] >20TB(媒体、下载和 Debian 存储库之间可能进一步分离)
  2. 数据(文档、照片等)~ 4TB SAFE(即 raid1 或 raid6 + 备份磁盘)
  3. 备份 >= 20 TB,用于备份我的千兆局域网中的其他计算机(您能否推荐一种可以备份整个操作系统的软件,即使是 Windows,BackupPC 也说它可以这样做,还有其他选择吗?)

实际上,快速的速度并不是必要的(并发访问:最多 2 或 3 个大文件,比如视频),即使从 10 HDD Raid6 中“仅仅”读取 200MB/s,我也可以接受。

总之,我寻找一个可靠、可扩展(即易于扩展)的文件系统,支持超过 20TB/分区。文件系统越安全、越可靠越好。使用的硬件至少是四核(amd x4 630 或 intel i5-2500k)和大量 RAM(>8GB,可能>16GB),因此应该满足硬件要求。

我的电脑/服务器将连接到 UPS(不间断电源),以防断电 也可能在不同的机器(即两台服务器)上进行媒体和备份。

答案1

很多人都建议使用 ZFS。但是除了通过 fuse 之外,Linux 本身无法使用 ZFS。我不建议在性能可能很重要的情况下使用 ZFS。

不幸的是,除非许可问题得到解决,否则 ZFS 将永远不会作为原生内核模块提供。

XFS 很好,但有些人报告了损坏问题,对此我实在无法评论。我使用过小型 XFS 分区,没有遇到这些问题,但在生产中没有遇到过。

ZFS 有太多优点和实用功能,不容忽视。总结如下(参见ZFS 维基以完整了解它们的含义):

  • 数据的完整性
  • 存储池
  • L2ARC
  • 大容量
  • 写入时复制
  • 快照和克隆
  • 动态条带化
  • 可变块大小
  • 轻量级文件系统创建
  • 缓存管理
  • 自适应字节序
  • 重复数据删除
  • 加密

那么我们如何解决这个问题呢?我建议的替代方案可能适合你的情况,那就是考虑内克森塔。这是一个 Open Solaris 内核,其上运行着 GNU 用户空间工具。拥有 Open Solaris 内核意味着可以原生使用 ZFS。

答案2

您应该尝试一下 XFS,它非常适合您的要求:

XFS 是 64 位文件系统。它支持的最大文件系统大小为 8 艾比字节减 1 字节,但这取决于主机操作系统施加的块限制。在 32 位 Linux 系统上,这会将文件和文件系统大小限制为 16 太比字节。

答案3

最简单的选择是使用 XFS。许多关于 XFS 的糟糕体验都是基于旧版本和桌面硬件问题,我认为这些问题与在标准质量服务器硬件上进行新部署无关。我写了一篇博客文章关于这个主题的更多内容可能会帮助您理清当前的情况。我帮助管理多个繁忙的 XFS 数据库安装,这些数据库拥有数百名用户和数 TB 的数据。它们都使用 Debian Lenny 内核 (2.6.26) 或更高版本,多年来我从未听说它们出现过任何问题。我不会将 XFS 与任何更早的内核一起使用。我听到一些直接报告说,当系统内存或磁盘空间不足时,人们仍然看到奇怪的 XFS 行为;但我自己还没有看到过这种情况。

唯一合理的选择是使用 ext4一些黑客行为以支持更大的文件系统。我并不认为其可靠性级别会有很大差异。我不得不从多个遇到内核错误的损坏的 ext4 系统中恢复数据,到目前为止,这些错误都已在上游修复,但当时分销商的内核中尚未修复。ext4 有自己的一组元数据问题,例如延迟分配数据丢失,在 ext3 上不太可能发生的事。我估计,如果你强行将其扩展到正常大小限制,你遇到 ext4 错误的几率会比正常情况下更高,这仅仅是因为你似乎更有可能在某个时候遇到一条测试不够充分的新代码路径。

另一种想法是使用更安全、更无趣的 ext3,接受 16TB 的限制,并更好地进行分区,这样单个文件系统就不需要那么大了。

一个与日志问题相关的未解决的问题。您没有谈到所有这些驱动器将如何连接。确保您了解此处存储链中任何写入缓存的含义。要么禁用它,要么确保文件系统正在清除缓存。我已将一些有关此内容的资源存放在可靠写入如果你还未检查该内容。

驱动器很烂。RAID 阵列很烂。文件系统很烂。会发生多次故障。我很高兴看到您已经在考虑备份;从良好到卓越的存储可靠性需要的不仅仅是 RAID 和一些备用驱动器。冗余在每个级别上都需要付出一些代价,而硬件与软件复杂性之间的成本很难平衡。并注意您的性能期望。虽然您正在考虑的 RAID 阵列可以轻松达到数百 MB/s,但只需两个并发读取器不断寻找磁盘,就可以将其降低到只有几 MB/s。我可以轻松压垮一个 24 磁盘 RAID10 阵列,使其仅提供 <5MB/s 的速度,而基准工作负载有一件事很有帮助,那就是如果可以使用多个流式读取器,则确保向上调整预读。

答案4

关于卷大小限制,根据文件系统比较有许多值得注意的文件系统可以满足您的需求,例如 JFS、XFS、UDF、ZFS、GPFS 和 Btrfs。您可以单击最大文件大小最大卷大小列进行排序,看看哪些适合你的需求

但是,由于您的要求不仅包括卷大小,还包括可靠性和可扩展性,因此您应该查看同一页面中的其他功能表。目前,对于大量文件以及弹性而言,最好的是 ZFS 和 Btrfs。它们都已经稳定了很长时间,并且目前可以用作许多发行版的根文件系统。OpenZFS成立于 2013 年,因此无需担心 Linux 中的 ZFS

相关内容