原文链接:
https://github.com/github/orchestrator/blob/master/docs/raft.md

前言
本篇文章翻译自orchestrator官方文档,讲一讲Orchestrator/raft一致性集群相关的内容。

Orchestrator/raft,一致性集群


Orchestrator/raft是一种部署配置,其中orchestrator节点通过raft一致性协议进行互相通讯。


Orchestrator/raft的部署方式解决了orchestrator自身的高可用,以及解决了网络隔离的问题,尤其是跨数据中心网络分区和隔离。

raft特征的简要概述
通过一致性协议,orchestrator节点可以选出具有法定票数的leader,这意味这它没有被隔离。举例来说,有一个3节点的Orchestrator/raft配置。正常情况下,3个节点之前会互相通讯,其中一个会被选为leader。然而,面临网络分区的时候,假设节点n1被n2和n3隔离出去,Orchestrator/raft保证了leader是n2或者n3。n1因为没有法定票数,不会成为leader(一个3节点的配置,法定票数是2;一个5节点的配置,法定票数是3)。
这种方式在跨数据中心的配置情况下被验证是有用的。假设有三个orchestrator节点,每个节点位于各自的数据中心。如果一个数据中心被隔离了,则确保活跃的orchestrator节点是一个具有一致性共识的节点,即活跃的是被隔离节点之外的两个节点。

Orchestrator/raft配置技术细节

服务节点

配置3个或者5个(推荐的raft节点数)orchestrator节点。其他数量也是可以的,但至少要3节点。


目前为止,orchestrator节点还不能动态加入集群。节点列表已预先配置如下:


"RaftEnabled": true,
"RaftDataDir": "/var/lib/orchestrator",
"RaftBind": "",
"DefaultRaftPort": 10008,
"RaftNodes": [
"",
"",
""
  ],


后端DB

每个orchestrator节点有自己的专用后端服务器。这可以是:


- MySQL后端数据库(无需复制设置,但如果此服务器有副本也可以) 作为部署建议,此MySQL服务器可以在同一orchestrator节点主机上运行。

- 一个SQLite后端数据库。使用:


"BackendDB": "sqlite",
"SQLite3DataFile": "/var/lib/orchestrator/orchestrator.db",


orchestrator与sqllite,无需安装额外的依赖项。

Proxy:leader

只有leader才能做变更操作。


最简单的配置是将流量路由到leader,通过http proxy(例如HAProxy)在orchestrator服务之上设置代理。


- 使用/api/leader-check做健康检查。在任何时间,针对健康检查,最多有一个orchestrator节点将回复HTTP 200/OK;其他节点会回应HTTP 404/Not found。


提示:例如,可以使用/api/leader-check/503来返回用户期望的响应代码503,或者任意相似的代码。


- 仅将流量定向到通过此测试的节点。


举个例子,下面是HAProxy的配置:


listen orchestrator
bind 0.0.0.0:80 process 1
bind 0.0.0.0:80 process 2
bind 0.0.0.0:80 process 3
bind 0.0.0.0:80 process 4
mode tcp
option httpchk GET /api/leader-check
maxconn 20000
balance first
retries 1
timeout connect 1000
timeout check 300
timeout server 30s
timeout client 30s
default-server port 3000 fall 1 inter 1000 rise 1 downinter 1000 on-marked-down shutdown-sessions weight 10
server orchestrator-node-0 orchestrator-node-0.fqdn.com:3000 check
server orchestrator-node-1 orchestrator-node-1.fqdn.com:3000 check
server orchestrator-node-2 orchestrator-node-2.fqdn.com:3000 check


Proxy:健康的raft节点

放宽了上述约束。


健康的raft节点将用户请求反向代理给leader。你可以选择访问任一健康的raft节点。


你不能访问不健康的raft节点,也就是说被法定投票隔离出去的节点。


- 使用/api/raft-health来辨认一个节点是健康的raft group的一部分。


- 一个HTTP 200/OK的响应说明节点是健康组的一部分,可以直接流量到此节点。


- HTTP 500/Internal Server Error表明节点不是健康组的一部分。请注意,启动后立即进行选举,直到选举出领导者为止,您可能需要等待一段时间,在这段时间,所有节点均报告为不正常。请注意,在重新选举领导者后,您可能会看到一个短暂的时期,所有节点均报告为不正常。


orchestrator-client
一个替代proxy的方法是使用orchestrator-client。


orchestrator-client是一个封装脚本,可以通过HTTP API访问orchestrator服务,并对用户提供命令行接口。


可以配置好所有orchestrator API endpoint列表供orchestrator-client使用。在这种情况下,orchestrator-client会找到哪个endpoint是leader,并将请求直接发给它。


例如,我们可以设置:


export ORCHESTRATOR_API="https://orchestrator.host1:3000/api https://orchestrator.host2:3000/api https://orchestrator.host3:3000/api"


调用orchestrator-client会先进行检查。

其他情况,如果你已经有了proxy,orchestrator-client也可以使用此代理,例如:


export ORCHESTRATOR_API="https://orchestrator.proxy:80/api"


Orchestrator/raft配置下的行为和可能的结果

- 在raft设置中,每个orchestrator节点独立运行所有服务器的发现(discovery)。这意味着在三节点设置中,每个MySQL拓扑服务器将由三个不同的orchestrator节点独立访问。


- 在正常情况下,这三个节点看到的拓扑大致相同。但是他们每个节点都有自己独立的分析(analysis)。


- 每个orchestrator节点都写入自己的专用后端DB服务器(无论是MySQL还是sqlite)


- orchestrator节点的通信是最小的。他们不共享发现信息(因为他们各自独立发现)。相反,领导者与其他节点共享截获了哪些用户指令,例如:

begin-downtime


register-candidate


等等


leader还会针对进行中的故障转移对follower进行educate。


orchestrator节点之间的通信与数据库的事务提交是不相关的,并且是稀少的。


- 所有用户更改都必须经过领导者,尤其是要通过HTTP API。你不能直接操作后端数据库,因为这样的更改不会发布到其他节点。


- 在orchestrator/raft配置下,启用了raft之后,运行客户端命令orchestrator会被拒绝。


- 可以使用orchestrator-client脚本,它提供了和命令行orchestrator相似的接口,来使用和操作HTTP API调用。


- 你只需要在orchestrator服务器上安装orchestrator二进制包。而orchestrator-client脚本可以安装在任意地方。


- 单个orchestrator节点的故障不会响应orchestrator服务的可用性。3节点的配置最多可以一个故障,5节点的配置最多可以有二个故障。


- 没有后端数据库,orchestrator节点无法运行。如果后端数据库是sqllite,,这是不重要的,因为sqlite嵌入了orchestrator。如果后端数据库是MySQL,如果在一段时间内orchestrator无法连接到后端数据库,则该服务将失效。


- 一个orchestrator节点可能会下线,然后再加入。它将重新加入该raft小组,并接收下线时错过的任何事件。节点离开多长时间都没有关系。如果它没有相关的本地raft日志/快照,则另一个节点将自动向其提供最新的快照。


- 如果orchestrator无法加入raft组,则它会失效。


orchestrator/raft的主要优势

- 高可用


- 一致性:故障转移是由仲裁成员的领导者节点进行的(不是孤立的)


- 支持SQLite(内嵌)后端,MySQL尽管支持,但不一定需要。


- 跨节点通信少;适用于高延迟的跨DC网络


数据中心隔离示例

考虑三个数据中心,这个例子中DC1,DC2和DC3。我们orchestrator/raft使用三个节点运行,每个数据中心一个。




当DC2网络隔离时会发生什么?






roadmap
进行中以及待做事项:


- 故障检测需要仲裁协议(即,DeadMaster需要由多个orchestrator节点进行分析)才能启动故障转移/恢复。


- 支持探测共享(与上述互斥):leader将划分服务器列表以在所有节点之间进行探测,潜在地可以通过数据中心来划分。这将减少探测负载(每个MySQL服务器将由单个节点而不是所有节点探测)。所有orchestrator节点将看到相同的画像,而不是各自独立的视图。


|  译者简介

韩杰  沃趣科技高级数据库工程师
专注MySQL数据库三年,精通MySQL体系结构,数据库优化,trouble shooting。服务过多家银行客户,熟悉银行业务及系统下数据库不同架构使用场景。熟悉MySQL主从复制原理,及应用的各种高可用场景。



沃趣科技,让客户用上更好的数据库技术!