Skip to content

Latest commit

 

History

History
91 lines (63 loc) · 6.52 KB

shard backend模式部署.md

File metadata and controls

91 lines (63 loc) · 6.52 KB
Raw

shard backend模式部署

Orchestrator deployment: shared backend

本文描述了shared backend数据库的部署方法. 有关各种后端DB设置，请参阅Orchestrator高可用.

这篇文的完善了在生产环境中部署Orchestrator.

Shared backend

你将需要创建一个shared backend database. 这可以是同步复制(Galera/XtraDB Cluster/InnoDB Cluster), 以实现高可用性, 也可以是主从复制.

后端数据库具有你的拓扑结构的状态. orchestrator本身几乎是无状态的, 并且信任后端数据库中的数据.

The backend database has the state of your topologies. orchestrator itself is almost stateless, and trusts the data in the backend database.

在shard backend模式部署中, 所有orchestrator 服务将全部与同一个后端通信.

  • 对于同步复制(synchronous replication), 建议是:
    • 配置多写模式(数据库集群的每个节点都是可写的)
    • orchestrator和MySQL节点之间是1:1映射的: 每个orchestrator服务与自己的后端数据库节点对话
  • 对于主从复制(异步 & 半同步), 请执行以下操作:
    • 配置所有orchestrator节点访问同一个后端数据库节点(即, 主库)
    • 你可以通过代理(proxysql)将引导流量到主库, 在这种情况下, 配置所有orchestrator节点访问代理即可.

MySQL backend setup and high availability

设置后端数据库是你的责任. 另外, orchestartor doesn't eat its own dog food, 也不能恢复自己后端数据库的故障. 你将需要处理, 例如, 添加Galera节点的问题, 或管理你的代理健康检查等.

What to deploy: service

  • 将orchestrator服务部署到服务盒上. 部署多少个服务盒将取决于你的可用性需求.

 Deploy the orchestrator service onto service boxes. The decision of how many service boxes to deploy will depend on yourOrchestrator高可用

  • In a synchronous replication shared backend setup, these may well be the very MySQL boxes, in a 1:1 mapping. 如果后端数据库采用同步复制(MGR/PXC), 那么orchestrator 服务数量和后端数据库集群节点数应该是1:1的. orchestrator 应该可以直接部署在后端数据库服务器上.
  • 考虑在服务盒(service boxes)之上增加一个代理(proxy);代理最好能将所有流量重定向到leader node(这里指的是orchestrator 服务leader节点). 有一个而且只有一个领导者节点, 状态检查的端点是/api/leader-check . 可以将流量导向任何健康的(orchestrator)服务. 由于所有orchestrator节点都与相同的共享后端数据库通信, 因此可以从一个服务节点执行一些操作, 从另一个服务节点执行其他操作. 内部锁是为了避免运行相互矛盾或干扰的命令.

What to deploy: client

为了通过shell/automation/scripts与orchestrator进行交互, 你可以选择:

  • 直接与HTTP API交互
  • 使用orchestrator-client脚本(orchestrator-client本质是一个shell脚本).
    • 将orchestrator-client部署在你希望与orchestrator交互的任何盒子上.
    • Create and edit /etc/profile.d/orchestrator-client.sh on those boxes to read:
ORCHESTRATOR_API="http://your.orchestrator.service.proxy:80/api"
# 代理

or

ORCHESTRATOR_API="http://your.orchestrator.service.host1:3000/api http://your.orchestrator.service.host2:3000/api http://your.orchestrator.service.host3:3000/api"
# 指定所有orchestrator

在后一种情况下, 你将提供所有orchestrator节点的列表, 而orchetsrator-client脚本将自动计算出哪个是leader. 通过这种设置, 你的自动化将不需要代理（尽管你可能仍然希望为Web界面用户使用代理）.

确保 chef/puppet/whatever 的 ORCHESTRATOR_API 值能够适应环境的变化.

  • orchestrator命令
    • 将orchestrator二进制文件（你可以使用orchestrator-clidistributed package）部署在你希望与orchestrator互动的任何盒子上.
    • 在这些盒子上创建/etc/orchestrator.conf.json，用证书填充(populate with credentials). 该文件一般应与orchestrator服务盒的文件相同. 如果你不确定, 请使用完全相同的文件内容.
    • orchestrator命令将访问共享的后端数据库. 请确保给予它访问权. 通常情况下, 这将是3306端口.

即使在orchestrator服务运行时, 运行orchestrator CLI也是可以的, 因为它们都将在相同的后端DB上进行协调.

Orchestrator service

In a shared-backend deployment, 你可以根据你的需求部署所需数量的orchestrator 节点.

然而, 如前所述, 只有一个orchestrator节点将被选为领导者. 只有领导者会:

  • 发现（探测）你的MySQL拓扑结构
  • 运行故障检测
  • 运行故障恢复

所有节点都:

  • 提供HTTP请求

  • Register their own health check 注册自己的健康检查

所有节点都可以:

  • Run arbitrary command (e.g. relocate, begin-downtime) (运行任意命令?)

  • Run recoveries per human request. (按人的要求运行恢复) 有关部署多个节点的详细信息，请阅读有关Orchestrator高可用的内容.

Orchestrator CLI

CLI执行以完成特定的操作. 它可以选择探测一些服务器, 这取决于操作(e.g. relocate), 也可以根本不探测服务器, 只从后端数据库读取数据.

A visual example

image

在上面图中, 有三个orchestrator节点运行在3个节点的同步复制设置之上. 每个orchestrator节点都与不同的MySQL后端通信, 但是这些节点都是同步复制的, 并且都共享相同的数据(有一定的延迟).

一个orchestrator节点被选为leader, 并且只有这个节点探测MySQL拓扑. 它会探测所有已知的服务器(上面的图片只显示了部分探测，以避免意大利面. (他意思应该是图上画太多线了, 向意大利面一样乱))