☰

带快照的定期文件系统复制

tag-icon • tag-icon synchronization replication
带快照的定期文件系统复制

我正在寻找一种支持定期快照的非实时复制解决方案。

这是我目前的情况：

  • 我有 2 个正在运行的电子邮件服务器Ubuntu 12.04 LTS
  • 我使用的邮件服务器程序是Axigen v8.1.1，服务2000+个邮箱，速度约为。工作时间每小时 2000 封电子邮件
  • 配置是主从，使用心跳/起搏器
  • Axigen 使用自己的专有数据库来存储所有设置和消息
  • 大多数用户使用 POP3 访问电子邮件服务器，但有些用户使用 IMAP4

我想要实现的：

  • 每一个氮分钟，应该在主服务器上完成快照并将其发送到从服务器
  • 从机至少应该能够有效地存储中号最新快照，加上 2 个每日快照，以防万一我们需要回滚
  • （我们可以忍受 N 分钟丢失的电子邮件；所有电子邮件都存储在 MailArchiva 存储系统中）

我原来的计划目标是在 ZFS-on-Linux (ZoL) 文件系统上实现 Axigen 的数据存储，并将定期快照（增量地）发送到 Slave。然而，我在大量 I/O 期间被 ZoL 的不稳定所困扰，在那里我经历了几次CPU软锁定。 ZoL 讨论组建议我减小 ARC 缓存的大小，但这当然会影响性能，因此我在 Master 上恢复为 ext4 支持的存储。 （不过，可能仍然在 Slave 上实现 ZFS）。

我正在考虑几种选择：

  1. 重新配置 Master，使数据存储位于 LVM 支持的存储上，并定期创建 LVM 快照以使用csync2或同步到 Slave rsnapshot（并在成功同步后删除 LVM 快照）。在从属端，每次成功同步后，执行 ZFS 快照以维护所需数量的快照和每日快照。

  2. 在主/从配置中实施 DRBD，在主设备上使用硬盘支持的存储，但在从设备上使用 ZVOL 支持的存储。

  3. 实现一个支持快照的集群文件系统……但选择哪一个呢？

非常感谢您的想法和意见。

编辑：由于我部门的预算情况，我无法使用商业解决方案。也许明年，但不幸的是我的需求是当前的。

编辑2：ZoL的不稳定可能不是ZoL本身的不稳定，但我怀疑更多是因为电子邮件服务器令人难以置信的内存搅动（由于某些原因，我必须在Axigen服务器前面实现Perdition，而Perdition创建了一个每个连接都有一个进程，因此服务器的内存可能会严重碎片化，并阻止 ZoL 声明一些 SLAB 来增长其 ARC 缓存）

答案1

好吧，至少你可以考虑使用LVM同步它“……能够读取设备映射器用来跟踪块设备的哪些部分已更改的元数据，并使用该信息仅通过网络发送那些修改过的块。 ……»

相关内容