【问题标题】:Mirror vs. HA Data Replication for disaster recovery用于灾难恢复的镜像与 HA 数据复制
【发布时间】:2021-03-02 16:59:05
【问题描述】:

如果我们失去整个数据中心,我正在研究 ActiveMQ Artemis 中用于数据恢复的选项。我们有两个数据中心,一个在东海岸,一个在西海岸。

从文档和论坛中我发现了四个选项:

基于磁盘的方法:

  1. 站点之间基于块的数据目录复制,在一个站点上运行 Artemis(使用带有协议 A 的 Ciphy 或 DRBD)。如果发生灾难(或故障转移测试),请在死站点上停止 Artemis,然后在活动站点上启动它。

  2. 同样的事情,但两个 Artemis 服务器都处于活动状态,使用 ha-policy 指示主服务器和使用 shared store 的从服务器。

网络复制:

  1. 类似于 2,但在 Artemis 中启用了data replication,因此 Artemis 处理复制。

  2. Mirror broker connections.

我们的 IT 团队在我们的其他服务中使用/熟悉 MySQL 复制、NFS 和 rsync。我们目前正在使用通过 MySQL 复制的 JBoss 4 服务器来处理 JMS。

阅读文档后,我的反应是高可用性数据复制是可行的方法,但是否存在我没​​有看到的权衡取舍。唯一提到 DR 和跨站点的是镜像代理连接,但从表面上看,它看起来像是同一事物的更难管理的版本?

我们的限制是我们需要实时集群上的高性能(每秒大约 10 万条消息,都很小) 我们有能力在紧急故障转移中丢失消息(最好尽可能少)。我们不应该在受控故障转移中丢失消息。

我们不希望站点 A 中的客户端连接到站点 B 中的 Artemis - 我们将在发生故障转移时启用站点 B 上的客户端。

【问题讨论】:

    标签: activemq-artemis


    【解决方案1】:

    首先要注意的是,通过 ha-policy 配置的高可用性功能(共享存储和复制 - 选项 #2 和 #3)专为在本地数据中心中使用而设计具有高速、低延迟的网络连接。它不是为灾难恢复而设计的。

    对您而言,基于网络的数据复制的具体问题是复制是同步的,这意味着它很有可能会对性能产生负面影响,因为每条持久消息都必须在全国范围内发送从一个数据中心到另一个。此外,如果复制代理失败,则客户端将自动故障转移到其他数据中心的备份。

    使用基于块存储的解决方案(例如 Ceph 或 DRDB)是可行的,但它确实是 ActiveMQ Artemis 无法控制的独立事物。

    mirror broker connection 的设计考虑了灾难恢复用例。它是异步的,因此它几乎不会对复制的性能产生影响,并且如果镜像代理失败,客户端将不会自动故障转移到镜像。

    【讨论】:

      猜你喜欢
      • 2012-03-16
      • 2018-06-02
      • 1970-01-01
      • 1970-01-01
      • 2016-03-08
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多