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": "<ip.or.fqdn.of.this.orchestrator.node>",
"DefaultRaftPort": 10008,
"RaftNodes": [
"<ip.or.fqdn.of.orchestrator.node1>",
"<ip.or.fqdn.of.orchestrator.node2>",
"<ip.or.fqdn.of.orchestrator.node3>"
],</ip.or.fqdn.of.orchestrator.node3></ip.or.fqdn.of.orchestrator.node2></ip.or.fqdn.of.orchestrator.node1></ip.or.fqdn.of.this.orchestrator.node>
后端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使用三个节点运行，每个数据中心一个。
-- roadmap
进行中以及待做事项：
- 故障检测需要仲裁协议（即，DeadMaster需要由多个orchestrator节点进行分析）才能启动故障转移/恢复。
- 支持探测共享（与上述互斥）：leader将划分服务器列表以在所有节点之间进行探测，潜在地可以通过数据中心来划分。这将减少探测负载（每个MySQL服务器将由单个节点而不是所有节点探测）。所有orchestrator节点将看到相同的画像，而不是各自独立的视图。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
