在两个Linux服务器之间同步数百万个文件

我有一台服务器，它通过NFS将包含约700万个文件（主要是图像）的目录从其本地磁盘导出到网络客户端。

为了进行HA，我需要添加第二个，并使其与第一个保持同步，并使两者之间的增量尽可能小。

研究建议为此使用lsyncd或其他基于inotify的解决方案，但鉴于创建inotify 监视的文件数量需要花费很长的时间。对于rsync也是一样。

其他可能的解决方案似乎是DRDB，或群集文件系统，如头孢或glusterfs，可是我不得不与那些没有经验，不知道哪一个会更合适，并与许多文件以及应对并仍提供不俗的表现。

请注意，该活动大部分是读取的，几乎没有写入发生。

— 用户名
source

DRDB可以正常工作，并且在两机集群设置中易于设置和理解。但是它不会在不久的将来扩展。对于该主题可能还有其他方法。highscalability.com/blog/2012/6/20/...

— 瑞˚F里贝罗

您是否尝试rsync在守护程序模式下运行？运行rsync命令时，这将加快文件列表的初始生成速度，但取决于文件数量，这会占用大量RAM。

— 托马斯

您可以忍受多少延迟？如果您可以忍受几分钟（或更长时间），请使用btrfs或zfs可以选择将其与cron作业结合使用以创建快照号和/ zfs send或btrfs send它们到备份服务器。（对于发送方和接收方计算机而言）比rsync更快，更轻松（因为发送快照和发送快照不需要比较文件时间戳或校验和）。

— cas

顺便说一句，使用ceph，您还可以选择将其用作对象存储（例如，亚马逊的s3或openstacks的swift）而不是文件系统。实际上，ceph的fs实际上位于其对象存储的顶部。

— cas

@Thomas：rsync -a使用守护程序（在源代码上）需要200分钟才能完成，这超出了可接受的范围。@cas：btrfs send我研究一下可能值得一试。我不是移动应用程序的开发人员，因为我不是使用这些文件的应用程序的开发人员。

— user60039

我倾向于建议与数据无关的复制，例如drbd。大量的文件将导致运行在比“块存储”更高的级别上的所有文件都花费大量时间在树上行走-正如您使用rsync或创建inotify监视表所发现的那样。

我个人故事的简短版本支持这一点：我没有使用过Ceph，但基于与Gluster的相似性，我很确定这不是他们的主要市场目标。但是，过去几年来，我一直在尝试使用Gluster实施这种解决方案。大部分时间它都已经启动并运行了，尽管有几个主要的版本更新，但是我没有遇到任何问题。如果您的目标是冗余而不是性能，那么Gluster可能不是一个好的解决方案。尤其是如果您的使用模式有很多stat（）调用，则Gluster在复制方面做得不好。这是因为对复制卷的stat调用会到达所有复制节点（实际上是“砖”，但是每个主机可能只有一块砖）。例如，如果您有2向复制，客户端的每个stat（）等待两个模块的响应，以确保它正在使用当前数据。然后，如果您使用本机gluster文件系统进行冗余（而不是使用Gluster作为后端，而NFS作为协议和自动挂载程序进行冗余，则仍然存在FUSE开销，并且缺少缓存），由于stat（）原因，这仍然很糟糕）。但是，Gluster对于大型文件确实非常有效，您可以在其中将数据分布在多个服务器上。数据条带化和分发效果很好，因为这确实是它的目的。而且，较新的RAID10类型复制的性能要优于较旧的直接复制卷。但是，根据我猜测的是您的使用模型，我建议您不要使用它。然后，如果您使用本机gluster文件系统进行冗余（而不是使用Gluster作为后端，而NFS作为协议和自动挂载程序进行冗余，则仍然存在FUSE开销，并且缺少缓存），由于stat（）原因，这仍然很糟糕）。但是，Gluster对于大型文件确实非常有效，您可以在其中将数据分布在多个服务器上。数据条带化和分发效果很好，因为这确实是它的目的。而且，较新的RAID10类型复制的性能要优于较旧的直接复制卷。但是，根据我猜测的是您的使用模型，我建议您不要使用它。然后，如果您使用本机gluster文件系统进行冗余（而不是使用Gluster作为后端，而NFS作为协议和自动挂载程序进行冗余，则仍然存在FUSE开销，并且缺少缓存），由于stat（）原因，这仍然很糟糕）。但是，Gluster对于大型文件确实非常有效，您可以在其中将数据分布在多个服务器上。数据条带化和分发效果很好，因为这确实是它的目的。而且，较新的RAID10类型复制的性能要优于较旧的直接复制卷。但是，根据我猜测的是您的使用模型，我建议您不要使用它。由于stat（）的原因仍然很糟糕）。但是，Gluster对于大型文件确实非常有效，您可以在其中将数据分布在多个服务器上。数据条带化和分发效果很好，因为这确实是它的目的。而且，较新的RAID10类型复制的性能要优于较旧的直接复制卷。但是，根据我猜测的是您的使用模型，我建议您不要使用它。由于stat（）的原因仍然很糟糕）。但是，Gluster对于大型文件确实非常有效，您可以在其中将数据分布在多个服务器上。数据条带化和分发效果很好，因为这确实是它的目的。而且，较新的RAID10类型复制的性能要优于较旧的直接复制卷。但是，根据我猜测的是您的使用模型，我建议您不要使用它。

请记住，您可能必须找到一种在计算机之间进行主选举或实现分布式锁定的方法。共享块设备解决方案需要具有多主机感知能力的文件系统（例如GFS），或者仅需要一个节点以读写方式安装文件系统。通常，文件系统不喜欢在其下方的块设备级别更改数据。这意味着您的客户将需要能够分辨出哪个是主服务器，并在那里直接写请求。事实证明，这可能是一个很大的麻烦。如果可以选择GFS及其所有支持的基础结构，则在多主机模式下的drbd（它们称为“双主”）可以很好地工作。 https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-mode了解更多信息。

无论您选择什么方向，都容易发现，在不给SAN公司带来大量资金的情况下，进行实时操作仍然是一个很大的难题。

— 丹尼绍尔
source

我正处于从cron的rsync命令迁移到使用分布式文件系统的初始阶段。如果Gluster在所有积木上运行stat（），则可能需要重新考虑它作为解决方案。

— Jesusaur

在复制的文件系统中只有这种情况。它可以stat()在具有您要查看的特定块的副本的所有砖上运行。例如，如果您有一个2x2的带区副本，则该副本stat将在具有复制块的两个块上运行，而不在其他两个块上运行。在我的应用程序中，有很多小文件（每个文件在4K数据下大约一百万个文件），NFS和FUSE都无法在复制卷上提供良好的性能。在几个配置中，对约20台计算机进行地理复制是非常不可靠的。

— dannysauer

您的工作量可能会有所不同，但是我从Gluster（到处都是我专门用于复制，而不是用于Gluster实际上做得很好的所有其他非常酷的事情）迁移到本地文件系统上的rsync。:)我现在正在考虑迁移到lsyncd（github.com/axkibe/lsyncd）而不是cron，所以我可以在没有Gluster开销的情况下接近实时。

— dannysauer

我已经在Proxmox VE安装程序的帮助下从rsync转到了ceph。

现在，我通过实时复制在一个群集中管理14TB。近四年了。

— 加深达拉
source