Orchestrator介绍二 自身高可用性方案

已于 2023-09-12 15:28:20 修改
阅读量1k 收藏
点赞数
分类专栏： Orchestrator 文章标签： mysql
于 2023-08-23 17:39:16 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_48154829/article/details/132451743
版权

目录

获得 HA 的方法

一 没有高可用性 （No high availability）

使用场景

架构组成

架构图

二 半高可用性（Semi HA）

三 基于共享数据库后端高可用（HA via shared backend）

四 基于Raft协议高可用

五 方案对比

注意事项

笔记

orchestrator作为高可用的服务运行。本文档列出了orchestrator实现 HA 的各种方法

获得 HA 的方法

HA 可以通过选择以下任一方式来实现：

  • orchestrator/raft设置，orchestrator节点通Raft 共识算法进行通信。每个orchestrator节点都有一个私有数据库后端（MySQL或sqlit)。另请参阅Orchestrator/raft 文档
  • 共享后端设置。多个orchestrator节点都与同一个后端数据库通信，该后端可能是 Galera/XtraDB Cluster/InnoDB Cluster/NDB Cluster。同步是在数据库级别完成的。

一 没有高可用性 （No high availability）

使用场景

这种适用于测试。本地开发环境。

架构组成

这种架构由 单个orchestrator节点和单个后端数据库组成。

后端数据库可以是MySQL也可以是orchestrator自带的sqlite。

架构图

二 半高可用性（Semi HA）

这种架构只有orc服务有高可用行，后端数据库没有高可用行

方式一 

多个orc节点使用MySQL主从中的master。orc 服务实现了高可用，但是后端数据库却没有。后端数据库是主从架构，每个orc节点不能有自己单独的后端数据库。如果后端数据库的master无法进行故障转移

方式二 

多个orc节点使用都配置为代理层的IP 。代理层后端是MySQL双主架构，并且双主架构复制规则设置为statement。

  • 代理层一直指向同一个MySQL节点，除非这个MySQL发生了故障
  • master 宕机后 orc就会通过代理层去访问另一个数据库节点。但是这个数据库节点数据可能有落后，orc会补充这些丢失 通过持续发现的特性。
  • orchestrator查询保证基于STATEMENT格式的复制不会导致重复错误，并且主主设置将始终实现一致性。
  • orchestrator即使在进行故障恢复过程中也可以对后端宕机的master进行启动（恢复将在备用master重新启动）
  • 脑裂是有可能的。 根据您的设置、物理位置、代理类型，可能有不同的orchestrator服务节点与不同的后端MySQL服务器通信。这种情况可能会导致两个orchestrator服务都认为自己是“活动的”，这两个服务都将独立运行故障转移，这将导致拓扑损坏。

三 基于共享数据库后端高可用（HA via shared backend）

完全的高可用是 通过后端数据库也具有高可用能力 实现。现有的后端数据库解决方案有：

  • Galera
  • XtraDB Cluster
  • InnoDB Cluster
  • NDB Cluster

上面的架构都要

  •  Galera/XtraDB Cluster/InnoDB Cluster 使用单写模式运行。多个orchestrator节点可能通过代理与写入节点进行通信。如果写节点发生故障，后端集群将提升另一个数据库作为写节点；由您的代理来识别并将orchestrator的流量引导新的写节点。
  •  Galera/XtraDB Cluster/InnoDB Cluster 在多写模式下运行。一个好的设置建议是将每个orchestrator节点与数据库服务器部署在同一服务器上。由于复制是同步的，因此不存在裂脑。只有一个orchestrator节点可以成为领导者，并且该领导者只会与数据库节点达成共识。

四 基于Raft协议高可用

以上介绍的三种方式都没有引入Raft共识算法。

orchestrator节点直接通过Raft共识算法进行通信。每个orchestrator节点都有自己私有的后端数据库（可以是MySQL或者sqlite）。

只有一个orchestrator节点可以成为leader，并且始终是共识？的一部分。然而，所有其他节点都是独立活动的，并且正在轮询您的拓扑。

在这种设置中

  • 数据库节点之间没有通信
  • orchestrator节点之间通信最少 
  • 与MySQL拓扑节点的通信次数是orc节点个数的倍数。一个3个节点orc 意味着被监控的MySQL集群中需要被3个独立不同的orc节点探测。
  • 建议运行为3个节点或者5个节点
  • sqlite是orc内置的 不需要在额外的安装。如果流量较大 建议使用MySQL。

要访问orc服务 ，你只能与leader角色通信。

  • 使用/api/leader-check作为代理的  HTTP 健康状况检查。
  • 或者使用具有多个orchestrator后端的orchestrator-client；orchestrator-client将找出领导者的身份并向领导者发送请求。

五 方案对比

这比较了两种高可用性部署方法的部署、行为、限制和优势：orchestrator/raft与orchestrator/[galera|xtradb cluster|innodb cluster]

我们将假设并比较：

  • 3数据中心设置（可用区可以算作数据中心）
  • 3节点 orchestrator/raft 设置
  • 3 orchestrator节点和 galera|xtradb cluster|innodb cluster多写模式（集群中的每个 MySQL 都可以接受写入）
  • 代理 可以运行 HTTP或者mysql健康检查
  • MySQL,MariaDB,Percona Server统称为MySQL。

比较orchestrator/raftsynchronous replication backend
通信每个orchestrator节点都有一个私有的后端DB；orchestrator节点通过raft协议进行通信每个orchestrator节点连接到MySQL同步复制组中的不同成员。orchestrator节点之间不进行通信。
后端数据库
 		MySQL 或 sqliteMySQL
对后端数据库的依赖如果无法访问自己的私有后端数据库，服务会出现如果无法访问自己的私有后端数据库，则服务不健康
数据库数据一致性跨数据库后端独立。可能会有所不同，但在稳定的系统上会收敛到相同的整体情况单个数据集，跨数据库后端同步复制
数据库访问千万不要直接写。只有raft节点在协调/合作时访问后端数据库。否则可能会导致不一致。读取没问题可直接访问、写入；所有orchestrator节点/客户端都会看到完全相同的图片

Leader and actions

单一Leader。只有Leader才能进行恢复。所有节点都可以进行发现（探测）和自我分析单一Leader。只有Leader才能进行发现（探测）、分析和恢复。
HTTP 访问必须只能访问领导者（可以通过代理或强制执行orchestrator-client）可以访问任何健康的节点（可以通过代理强制执行）。为了读取一致性，最好只与领导者交谈（可以通过代理或强制执行orchestrator-client）
命令行HTTP/API 访问（例如curl，jq）或orchestrator-client使用熟悉的命令行界面封装常见 HTTP/API 调用的脚本HTTP/API 和/或orchestrator-client脚本或orchestrator ...命令行调用。
安装orchestrator仅在服务节点上提供服务。orchestrator-client任何地方的脚本（需要访问 HTTP/API）。orchestrator服务节点上的服务。orchestrator-client任何地方的脚本（需要访问 HTTP/API）。orchestrator任何地方的客户端（需要访问后端数据库）
ProxyHTTP。只能将流量引导至Leader ( /api/leader-check)HTTP。必须仅将流量引导至健康节点 ( /api/status)；最好只将流量引导至Leader节点 ( /api/leader-check)
No Proxyorchestrator-client与所有后端一起使用orchestrator。orchestrator-client将引导流量至 master。orchestrator-client与所有后端一起使用orchestrator。orchestrator-client将引导流量至 master。
跨机房每个orchestrator节点（以及私有后端）可以在不同的 DC 上运行。节点间通信不多，流量低。每个orchestrator节点（以及关联的后端）可以在不同的 DC 上运行。orchestrator节点不直接通信。MySQL组复制通信频繁。流量主要与拓扑大小和轮询率呈线性关系。写入延迟。
探测orchestrator所有节点探测每个拓扑服务器每个拓扑服务器由单个活动节点探测
故障分析由所有节点独立执行仅由领导者执行（数据库是共享的，因此所有节点无论如何都会看到完全相同的图片）
故障转移仅由Leader执行仅由Leader节点执行
抵御失败的能力

如果有3个节点，1个节点允许宕机

如果有5个节点，2个节点允许宕机

如果有3个节点，1个节点允许宕机

如果有5个节点，2个节点允许宕机

节点从短暂故障中恢复节点重新加入集群，并根据更改进行更新。数据库节点重新加入集群，并根据更改进行更新。
节点从长期中断中恢复必须从健康节点克隆数据库。取决于您的 MySQL 后端实现。可能从备份进行 SST/恢复。

注意事项

以下是在两种方法之间进行选择时的注意事项：

  • 您只有一个数据中心 (DC)：选择共享数据库甚至更简单的设置
  • 您对 Galera/XtraDB Cluster/InnoDB Cluster 感到满意，并且可以自动设置和维护它们：选择共享数据库后端。
  • 您拥有高延迟跨 DC 网络：选择orchestrator/raft方案。
  • 您不想为orchestrator后端分配 MySQL 服务器：选择orchestrator/raft 和  SQLite数据库
  • 您有数千个 MySQL 集群：选择MySQL

笔记

  • 另一种同步复制设置是单个写入器的同步复制设置。这需要orchestrator节点和底层集群之间有一个额外的代理，上面没有考虑。

DBA之路
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论
专栏目录
认识和学习orchestrator之基本使用篇
HULK一线技术杂谈
04-21 4704
01介绍orchestrator目前GitHub上star 4.5k+，非常适用于有多个数据中心MySQL集群的管理。该工具使用起来很简单，但能用好却不容易，其配置参数将近200个，后端存储表47张，下面将介绍orchestrator以及它的使用方法。02orchestrator是什么2.1功能其是一个管理MySQL复制拓扑的高可用、管理、可视化的工具。会定时采集探测到...
arch-orchestrator:大型 node.js 应用程序的 Orchestrator 架构模式
07-08
编曲家 大型 node.js 应用程序的 Orchestrator 架构模式 安装 npm install arch-orchestrator 动机 管理架构或大型 node.js 应用程序可能具有挑战性。 使用协调器方法，您可以通过解耦系统上的不同任务来改进 node.js 应用程序的结构。 让我们看看转向协调器方法后的典型架构。 现在让我们澄清这个架构的一些部分： 参与者 处理程序 知道需要调用哪个编排器方法以交付请求的资源的函数。 编排器 知道如何构建任务链的对象。 这个对象应该知道每个任务。 为了将链交付给处理程序，他需要构建适当的任务链。 任务 知道如何完成某些特定任务的函数。 任务对彼此一无所知。 他们还有小的额外责任。 当任务上的动作完成时，任务需要调用next函数以将结果传递到任务链的下一部分。 下一步将有一些其他责任，依此类推，直到链结束。 当到达链尾时，结果将可用
Mysql orchestrator高可用
u010648194的博客
07-28 2441
Orchestrator是一款开源，对MySQL复制提供高可用、拓扑的可视化管理工具，采用go语言编写，它能够主动发现当前拓扑结构和主从复制状态，支持MySQL主从复制拓扑关系的调整、支持MySQL主库故障自动切换(failover)、手动主从切换(switchover)等功能。............
MySQL高可用工具--orchestrator
翔云
03-30 909
orchestrator是一款MySQL高可用工具，其支持： 集群拓扑探测 集群拓扑重塑 故障恢复 提供3种使用方式： 命令行 HTTP API web页面 orchestator github地址
Orchestrator (1) 高可用管理详解
爱死亡机器人
07-16 1869
背景 在MySQL高可用架构中，目前使用比较多的是Percona的PXC，Galera以及MySQL 5.7之后的MGR等，其他的还有的MHA，今天介绍另一个比较好用的MySQL高可用复制管理工具：Orchestrator（orch）。 Orchestrator 这是一款go编写的MySQL高可用性和复制拓扑管理工具，支持复制拓扑结构的调整，自动故障转移和手动主从切换等。后端数据库用MySQL或SQLite存储元数据，并提供Web界面展示MySQL复制的拓扑关系及状态，通过Web可更改MySQL实例的复制关
orchestrator数据库高可用组件搭建
ApexPredator的博客
10-27 236
orchestrator数据库高可用组件搭建
Orchestrator（orchestrator-3.2.6）
10-14
Orchestrator（orchestrator-3.2.6）是一个 MySQL 高可用性和复制管理工具，作为服务运行并提供命令行访问、HTTP API 和 Web 界面。 orchestrator-3.2.6.tar.gz orchestrator-3.2.6.zip orchestrator_3.2.6_amd64....
H3C NFV Orchestrator产品功能介绍.pptx
10-15
H3C NFV Orchestrator产品功能介绍.pptx
H3C NFV Orchestrator产品功能介绍.pdf
10-15
H3C NFV Orchestrator产品功能介绍.pdf
McAfee ePolicy Orchestrator系统防护解决方案
03-04
ePO 是 McAfee 系统安全解决方案的核心组件，管理员可以保持防护体系的最新状态、配置并强制实施防护策略，以前瞻性地降低恶意系统或不符合安全要求的系统所造成的风险，并通过一个企业级可伸缩的中央控制台对系统的...
orchestrator用作VIP切换的脚本有两个：其一 ----> orch_vip.sh
07-23
用于orchestrator高可用来做 VIP切换的，该脚本略有瑕疵，并没有非常完美。但是生产上是可以用的，不过该脚本没有报警功能，请知悉。
协调器：MySQL复制拓扑管理和高可用性
02-03
orchestrator是MySQL高可用性和复制管理工具，可作为服务运行，并提供命令行访问，HTTP API和Web界面。 orchestrator支持： 发现 orchestrator主动搜寻您的拓扑并进行映射。 它读取基本MySQL信息，例如复制状态和...
MySQL高可用方案orchestrator简介
DBA之路的博客
09-17 1882
官方地址https://github.com/github/orchestrator 介绍 Orchestrator是MySQL高可用性和复制管理工具，可作为服务运行，并提供命令行访问，HTTP API和Web界面 1 发现 Discovery orch可以自动发现MySQL复制拓扑，提供可视化，可以在web页面展示，orch本身具有高可用。 2 重构Refactoring orch可以重构MySQL复制关系，可以在web进行拖图来进行复制关系变更 3恢复Recovery ...
MySQL高可用——Orchestrator架构、配置文件详细介绍和单机搭建部署
最新发布
m0_60006388的博客
01-24 1851
orchestrator可以选择执行自动恢复（或允许用户选择手动恢复的类型）。orchestrator了解复制规则。即使遇到故障，也可以为MySQL环境的拓扑提供流畅的可视化效果，包括复制问题。同时需要注意的是，Orchestrator的server端需要和对外提供服务的MySQL放在一起的，Orchestrator的专属后端可以放到远程服务器上，这点在配置文件中也有体现。在对外提供服务的MySQL服务器上创建用户，使orchestrator可以检测到该MySQL，从而绘制拓补图。
mysql之orchestrator高可用架构-完整版
q936889811的博客
12-20 3168
orchestrator 是MySQL高可用性和复制管理工具。
技术分享 | orchestrator--运维--配置集群自动切换&测试
ActionTech的博客
09-22 481
配置了 orchestrator 后，可以配置⾃动切换的 cluster 范围，参数包含不限于：可以配置收否切换的条件，参数包含不限于：当延迟超过 FailMasterPromotionOnLagMinutes 分钟时，切换失败，当禁⽤了全局恢复时，不会进⾏⾃动切换。
mysql 拓扑_Orchestrator：MySQL复制拓扑结构管理工具
weixin_39978257的博客
01-19 234
What is Orchestrator?orchestrator是MySQL复制结构的一个拓扑管理工具其主要有以下几个特征1.自动监测数据库复制的结构及其状态2.提供了GUI，CLI，API等接口来检查复制拓扑的状态以及做一些调整的操作3.支持自动的master failover，当复制结构的server挂掉以后(不管手动还是自动的)，能够重新形成复制的拓扑结构4.不依赖于特定的server版本...
MySQL高可用架构Orchestrator配置文件详解
雪辉博客
12-16 2862
{ #是否开启debug模式 "Debug": true, #是否记录到系统日志 "EnableSyslog": false, #web 端口 "ListenAddress": ":3000", #被管理数据库用户 "MySQLTopologyUser": "orc_client_user", #被管理数据库密码 "MySQLTopologyPassword": "orc_client_password", #被管理的MySQL的用户密码配置文件 "MySQLTopologyCred
推荐一款MySQL高可用复制管理工具——Orchestrator介绍
开发者导航
07-19 272
背景 在MySQL高可用架构中，目前使用比较多的是Percona的PXC，Galera以及MySQL 5.7之后的MGR等，其他的还有的MHA，今天介绍另一个比较好用的MySQL高可用复制管理工具：Orchestrator（orch）。 Orchestrator 这是一款go编写的MySQL高可用性和复制拓扑管理工具，支持复制拓扑结构的调整，自动故障转移和手动主从...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

DBA之路

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值