![当需要检查和修复大型文件系统时,如何避免停机](https://linux22.com/image/805430/%E5%BD%93%E9%9C%80%E8%A6%81%E6%A3%80%E6%9F%A5%E5%92%8C%E4%BF%AE%E5%A4%8D%E5%A4%A7%E5%9E%8B%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E6%97%B6%EF%BC%8C%E5%A6%82%E4%BD%95%E9%81%BF%E5%85%8D%E5%81%9C%E6%9C%BA.png)
我正在研究构建和运行大型存储服务器(必须运行 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 等。与一个大型阵列完全不同。实现方式的不同之处在于它们是否使用底层文件系统,以及它们是否向用户提供块或文件协议。