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

Question

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

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

我想提出更好的方法来实现同样的目标.

谢谢

Answer 1

首先，我想指出您的解决方案的缺点，希望我的解决方案能够解决：

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

因为问题是关于数据中心S，所以我会认为我们有足够的（DC）来实现我们的目标：解决 a。和b。同时拥有一个可用的多数据中心分布式ZK。

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

其他考虑：

无论选择哪种解决方案，DC 间的通信都应该得到保护，为此 ZK没有提供解决方案，因此必须实施隧道或其他方法。

更新

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