apache-zookeeper - 如何跨多个数据中心部署zookeeper并进行故障转移？

Question

我想了解在跨数据中心运行 Zookeeper 时可用的现有方法？

我在做一些研究后发现的一种方法是有观察者。这种方法是在主数据中心中只有一个具有领导者和追随者的整体。并在备份数据中心设有观察员。当主数据中心崩溃时，我们选择其他数据中心作为新的主数据中心，并手动将观察者转换为领导者/追随者。

我想用更好的方法来实现同样的目标。

谢谢

Answer 1

首先，我想指出您的解决方案的缺点，希望我的解决方案可以解决:

a) 如果主数据中心发生故障，恢复过程是手动的(我引用你的话:“手动将观察者转换为领导者/跟随者”)
b) 只有主数据中心接受写入 -> 如果发生故障，所有数据(当观察者不写日志时)或只有最后一次更新(当观察者写日志时)丢失

因为问题是关于数据中心小号 我会认为我们有足够的(DC)来实现我们的目标:解决 a.和 b。同时拥有一个可用的多数据中心分布式 ZK。

因此，当拥有偶数个数据中心 (DC) 时，可以使用一个额外的 DC 仅用于在集合中获得奇数个 ZK 节点。当有例如可以添加 2 个 DC，而不是第 3 个；每个 DC 可以包含 1 个 rwZK(读写 ZK 节点)，或者为了更好地容忍故障，每个 DC 可以包含 3 个 rwZK，组织为 hierarchical quorums (这两种情况都可能使 ZK 观察者受益)。在 DC 内，所有 ZK 客户端都应仅指向 DC 的 ZK 组，因此 DC 之间的流量仅用于例如领导人选举，写道。使用这种设置可以解决这两个问题。和 b。但会丢失写入/恢复性能，因为写入/选择必须在数据中心之间达成一致:至少 2 个 DC 必须就写入/选择达成一致，每个 DC 有 2 个 ZK 节点协议(protocol)(参见 hierarchical quorums)。 DC 内协议(protocol)应该足够快，因此对整个写入协议(protocol)过程没有太大影响；最重要的是，大约只有 DC 之间的延迟很重要。这种方法的缺点是:
- 第三个数据中心的额外成本:这可以通过使用公司办公室 (a guy did that) 作为第三个数据中心来减轻
- 由于 DC 间网络延​​迟和/或吞吐量而丢失 session :在足够高的超时下，可以达到最大可能的写入吞吐量(取决于 DC 间平均网络速度)，因此该解决方案仅在该最大值可接受时才有效.尽管如此，当每个 DC 使用 1 个 rw-ZK 时，我想您的解决方案不会有太大差异，因为从备份 DC 到主 DC 的写入也必须在 DC 之间传输；但是对于您的解决方案，不会是跨 DC 编写协议(protocol)或与领导选举相关的通信，因此它更快。

其他考虑:

无论选择何种解决方案，DC 间的通信都应该是安全的，为此 ZK 提供 no solution因此必须实现隧道或其他方法。

更新

另一种解决方案是仍然使用额外的第 3 个 DC(或公司办公室)，但只保留 rw-ZK(1、3 或其他奇数)，而其他 2 个 DC 只有观察者 ZK。客户端仍应仅连接到 DC 的 ZK 服务器，但我们不再需要 hierarchical quorums .这里的好处是写入协议(protocol)和领导者选举将仅在具有 rw-ZK 的 DC 内部(我们称之为仲裁 DC)。缺点是:
- 仲裁 DC 是单点故障
- 写入请求仍需从观察者 DC 传送到仲裁者 DC