2020 年 - 是否有适用于 DRBD 的可行的 Linux 块级复制替代方案？

Question

我正在研究如何实现从主数据中心到灾难恢复站点的近实时复制。将被复制的数据将是：

• KVM 虚拟机镜像
• MySQL 和 PostgreSQL 数据库

为简单起见，我们假设总共不到 10TB 的数据，平均写入速度低于 100MB/s，峰值为 1500MB/s，主数据中心和备份数据中心之间的链路将具有 10gbit/s 的吞吐量。

异步复制是可以接受和需要的——在突发写入或两个数据中心之间的连接短暂中断的情况下——我们不想降低本地写入速度，并且愿意牺牲可能丢失的最新部分数据以防万一影响主数据中心的灾难性故障。

我的理解是我们可以选择：

• 具有复制功能并可以提供 iSCSI LUN 的专有 SAN 硬件
• 可能需要与 DRBD 代理结合使用的 DRBD [以确保两个数据中心之间的可用带宽或延迟峰值的临时下降不会影响源的写入性能]
• 基于软件的解决方案，如http://schoebel.github.io/mars/，遗憾的是，在最好的情况下，它需要很长时间才能合并到主线内核中
• 对于 DB，数据库级复制也是一种选择，但我们希望偶尔进行 DR 测试，以便在数据中心之间切换所有工作负载。从 DR 站点故障返回到主站点将非常麻烦。

还有其他值得考虑的解决方案吗？

谢谢！

Answer 1

对于数据库以及数据库感知和依赖应用程序来说，由于多种原因，它们的专有复制始终优于“通用”块级复制，数据库一致性就是其中之一。因此，即使使用自 2014 年或 2015 年以来的 SQL Server 标准版本，也可以使用具有一些限制的 SQL Server 可用性组 (AG)，使用 MS Exchange DAG、SAP HANA、AeroSpike 副本等。我不会在 2020 年使用 DRBD，因为它相当I/O 性能较差，尤其是在全闪存配置下，DRBD 显然是为 2000 年代初的旋转磁盘和高延迟非 RDMA 网络而设计的，而且对裂脑问题的防护也极差。作为主要虚拟机管理程序一部分的 Virtual SAN 技术是 DB 内置复制技术的另一个不错的选择。