我正在研究构建和运行大型存储服务器（必须运行 Linux）的方法，在该服务器中，我可以对所有数据阵列运行一致性检查和修复，而使用阵列（读取和写入）的常用应用程序则继续照常工作。
假设您在一个传统的 Linux 文件系统（EXT4、XFS）上存储了数 TB 的数据，并且有数百名用户在使用，然后系统突然报告一致性/损坏问题，或者您知道机器最近出现了问题，并且文件系统很可能会出现损坏。
使文件系统脱机并运行文件系统检查很容易导致数小时/数天的停机时间，因为 EXT4 和 XFS 都无法在正常运行时运行检查和修复；需要先使文件系统脱机。
如何避免 Linux 中 EXT4/XFS 的这个弱点？如何构建大型存储服务器，而无需将其离线数小时进行维护？
我读了很多关于 ZFS 及其可靠性的文章，因为它使用了数据/元数据一致性检查。是否可以在不使 ZFS 文件系统脱机的情况下运行一致性检查并修复它？其他一些新文件系统或磁盘上数据的其他组织方式会更好吗？
我正在考虑的另一个选择是将数据阵列划分为非常多（数百个）分区，每个分区都有自己独立的文件系统，并修复应用程序以了解使用所有这些分区。然后，当需要检查其中一个分区时，只需将该分区脱机。这不是一个完美的解决方案，但总比没有好。
这个问题有完美的解决办法吗？
答案1
现实情况是，传统文件系统并不适合多 TB 卷。例如，RedHat 推荐EXT4 文件系统不大于 50 TB；时间fsck是限制因素之一。
XFS 的情况更好，一方面因为它速度更快xfs_repair（与旧版本相比xfs_check），另一方面也得益于正在进行的项目添加在线清理。
EXT4、XFS 和其他文件系统（BTRFS 除外）可以通过对主卷进行快照并fsck针对快照（而不是主文件系统本身）运行来在线检查。这将捕获任何严重错误而无需停机，但显然需要在文件系统下安装卷管理器（具有快照功能）。顺便说一句，这是 RedHat 默认使用 LVM 的主要原因之一。
尽管如此，最知名、最可靠的具有在线清理功能的文件系统显然是 ZFS：它从一开始就被设计为高效支持非常大的阵列，并且其在线清理功能非常有效。如果有的话，它有一个相反的问题：它缺乏离线 fsck，这将有助于纠正一些罕见的错误。
答案2
这可能是 XFS 或 ZFS 的情况。FSCK 不是 ZFS 世界中的概念。
以稳健的方式构建这样的事物需要大量的技能。如果有预算聘请专家或ZFS 顾问，您的组织应该考虑这样做。
答案3
通过询问组织可以接受多少停机时间来进行业务连续性分析。要比每年几次计划内停机和几个小时的停机时间做得更好，通常需要投资多节点解决方案。
尽可能多地防范停机风险。例如，无论使用哪种存储技术，数据中心发生火灾都会导致系统停机几个小时。如果必须继续提供服务，请将数据复制到另一栋大楼的其他系统。
关于文件系统，选择您可以修复和/或您的供应商可以支持的东西。EXT4 强烈建议您每隔一定数量的挂载进行一次 fsck。XFS fsck 由于日志而无法执行任何操作，但 xfs_check 处于离线状态。ZFS 没有 fsck，而是有在线清理。
在某种程度上，将数据拆分成多个卷可能有意义。可以隔离故障，可能是按组织单位或应用程序。但是，仅为了保持 fsck 速度而使用数百个小卷会增加工作量。集中管理存储的一个优点应该是减少管理工作。
为了实现多节点可用性和性能，请考虑添加另一层，即横向扩展分布式文件系统。 Ceph、Lustre、Gluster 等。与一个大型阵列完全不同。实现方式的不同之处在于它们是否使用底层文件系统，以及它们是否向用户提供块或文件协议。