我有一台服务器，它通过以下方式将包含约 700 万个文件（主要是图像）的目录从本地磁盘导出到网络客户端网络文件系统。
为了 HA，我需要添加第二个，并使其与第一个保持同步，两者之间的增量尽可能小。
研究建议使用同步或其他inotify基于此的解决方案，但考虑到创建的文件数量inotify手表需要永恒。同样的事情同步。
其他可能的解决方案似乎是数据数据库，或簇文件系统例如头孢或者格鲁斯特文件系统，但我对这些没有经验，不知道哪一个更合适，可以很好地处理那么多文件，并且仍然提供不错的性能。
请注意，该活动主要是读取，很少发生写入。
答案1
我倾向于建议与数据无关的复制，例如 drbd。大量文件将导致在比“块存储”更高级别上运行的任何内容花费过多的时间遍历树 - 正如您使用 rsync 或创建 inotify 监视所发现的那样。
我个人故事的简短版本支持了这一点：我没有使用过 Ceph，但我很确定这不是他们的主要市场目标，因为它与 Gluster 相似。然而，过去几年我一直在尝试使用 Gluster 来实现这种解决方案。虽然有几个主要版本更新，但它大部分时间都在运行，但我遇到了无穷无尽的问题。如果您的目标是更多的冗余而不是性能，Gluster 可能不是一个好的解决方案。特别是如果您的使用模式有大量 stat() 调用，Gluster 在复制方面表现不佳。这是因为对复制卷的 stat 调用会发送到所有复制节点（实际上是“块”，但每个主机可能只会有一个块）。例如，如果您有双向副本，则来自客户端的每个 stat() 都会等待两个块的响应，以确保它使用当前数据。然后，如果您使用本机 gluster 文件系统来实现冗余（而不是使用 Gluster 作为后端，以 NFS 作为协议和自动挂载器来实现冗余，但由于 stat() 原因，这仍然很糟糕），那么您还会有 FUSE 开销和缺乏缓存的情况。不过，Gluster 非常适合处理大型文件，您可以将数据分布到多个服务器上；数据条带化和分布效果很好，因为这就是它的真正用途。较新的 RAID10 类型复制的性能优于较旧的直接复制卷。但是，根据我对您的使用模型的猜测，我建议不要这样做。
请记住，您可能必须找到一种方法在机器之间进行主选举，或者实现分布式锁定。共享块设备解决方案需要一个支持多主设备的文件系统（如 GFS），或者需要只有一个节点以读写方式挂载该文件系统。文件系统通常不喜欢在其下面的块设备级别更改数据。这意味着您的客户端需要能够辨别哪个是主服务器，并在那里直接发出写入请求。这可能会成为一个很大的麻烦。如果可以选择 GFS 及其所有支持基础设施，则多主模式下的 drbd（他们称之为“双主”）可以很好地工作。 https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-mode了解更多相关信息。
无论您选择哪个方向，您都可能会发现，如果不给 SAN 公司大量资金，实时实现这仍然是一个相当大的痛苦。
答案2
在 Proxmox VE 设置的帮助下，我已从 rsync 转向 ceph。
现在，我通过实时复制在一个集群中管理 14TB。近4年了。