一站式运维管理工具平台 OCP 到底有多好用，看这篇文章就够了！

2022 年 3 月 18 日
本文字数：6809 字
阅读完需：约 22 分钟

作者简介：雪染，OceanBase 技术专家。

1.OCP 是 OceanBase 一个一站式运维管控平台。

OceanBase 拥有很强大的功能，但当单独使用 OceanBase 内核时，对用户的要求比较高，用户使用并不方便。甚至某些功能的实现，非常依赖于特定工具的配合。比如想要知道 OceanBase 一段时间的 QPS, 系统表内无法直接获取，系统表中只记录累加之后的值，需要特定工具持续采集，并持久化这些原始数据才能进行计算。

所以更好的使用 OceanBase 离不开生态工具的配合，OCP 应运而生。

除了 OCP，还有一些其他的工具来支持 OceanBase，比如 OBD 可以做部署和日常运维，OBAGent + Prometheus + Grafana 可以做监控，这些工具都非常好用。

但是每个工具都只满足特定一部分的需求，在满足日常的生产环境使用时，运维人员需要使用多个独立的工具，非常繁琐耗时耗费精力。而 OCP 可以类比于软件开发中的 IDE 开发环境，在一个环境里提供了最常用的功能，满足绝大部分日常的使用场景。

OCP 的主要功能分为以下三个部分：（表）

① OceanBase 运维。

OceanBase 集群的安装部署和日常运维。
租户管理。
Database 管理。
OceanBase 相关生态工具的运维，目前已经支持 Obproxy。
主机和软件包的管理, 是最基础的运维能力，为运维 OceanBase 提供支持。

② OceanBase 监控。

Metric 监控指标，包括 OceanBase 和 Obproxy 的监控指标。
SQL 统计分析，慢 SQL 分析。
基于监控指标/日志的报警。

③ 元数据查询服务。

存储并实时更新 OceanBase 的 rootservice 地址。
提供给其他组件查询 OceanBase 的 rootservice 地址。
记录 ObProxy 和 OceanBase 的关联关系。这是在前面基础上做的一个能力。

OCP 的应用场景。

① 内部使用：比如蚂蚁内部、阿里集团内部很多机器需要管理，需要标准化管理的平台来支持大规模的管理，让 DBA 专注于更有价值的事。

② 独立输出：为企业用户提供企业级的管理服务。

③ 云上使用：将 OceanBase 以云服务的方式提供给用户。

2. OCP 系统架构

上图为 OCP 的系统架构，其主要模块有三：

① OCP 管理服务：它包括一个由 Java 实现的应用程序，实现 OCP 平台的主要逻辑。它会与其他组件交互，对外提供 http 服务。管理控制台提供给用户前端页面进行交互，其他系统也可以通过 open api 直接调用 OCP。

② 数据库存储：包括元信息数据库和监控数据库。其中元信息数据库存储 OCP 管理资源的记录，监控数据库存储 OCP 采集的一些监控指标，包括采集到的原始值以及计算后的统计数据。

③ OCP-Agent：它部署在每个 OCP 管控的主机上，提供两种能力。首先，提供运维接口，OCP 需要进行的运维操作通过调用 OCP-Agent 来实现，也通过这种方式，实现跨平台的能力；另外，提供监控能力，包括以服务的形式通过 Prometheus 协议提供 metric 数据，以及主动上报 SQL 相关的数据。

3. OCP 主要功能模块以及实现

3.1 运维模块

OceanBase 作为分布式数据库，相对于传统的单机数据库更加复杂，在运维上面临了诸多挑战：

① 需要管控的节点很多；节点是以一定的层次关系组织在一起的，在运维过程中需要考虑到 OceanBase 的各种限制，比如不能破坏多数派，导致运维流程比较复杂。

② 运维任务耗时长；一个运维任务会包括很多步骤，这些步骤之间有一定的依赖关系，不能完全并行执行，此外，一般运维的步骤会有涉及到主机上的一些操作，相对比较耗时。

③ 任务在任何步骤都可能失败；一般运维任务都是需要在管理的主机上进行一些操作，首先，当管理的主机规模大了之后，遇到主机的故障就不再是一个小概率事件，另外，主机上环境并不都是标准的，可能会遇到各种环境相关的问题，都会导致任务失败。

④ OceanBase 在快速的迭代更新，存在很多版本，这些版本之间也会存在差异，需要考虑各版本的兼容性问题。

⑤ 用户可能会使用不同操作系统的主机，运维的方式存在差异，需要考虑跨平台能力。

那么， OCP 是如何来解决以上痛点呢？

① 定义原子化的任务；支持正常执行、回滚、重试、跳过这些操作。然后基于原子任务通过编排的方式构造出一个完整的任务，可以实现复杂的运维逻辑，而且，原子任务可以在多个运维场景中得到复用，避免重复开发。

② 针对任务执行时间长的痛点；首先，在编排任务的时候会尽量将不相关的任务进行并行化处理，另外，任务提交之后会在后台执行，只有在失败的时候才需要再介入处理。

③ 针对失败的任务；依赖原子任务提供的能力，可以进行重试或放弃。

④ 针对 OceanBase 多版本兼容；OCP 实现了 OB-SDK，将不同版本的差异在 OB-SDK 中处理掉，对外提供标准的接口，从而屏蔽掉不同版本的差异。

⑤ 主机跨平台的能力是通过 ocp-agent 来实现的；也是通过将不同平台的差异在 ocp-agent 中处理掉，对外提供标准的接口。

⑥ OCP 提供了任务流程的可视化；将整个任务的关系以列表/图表的形式展现出来，用户可以从图表中获知哪一步执行了什么任务、哪些步骤失败了等等，然后进行处理。

上图展示 OCP 运维功能涉及到的主要模块。

用户请求按照业务逻辑由不同的 service 服务进行处理，根据请求构造对应的任务模版和参数然后将其提交给任务引擎，任务引擎会生成 task 实例然后执行，task 中涉及到的操作，根据运维对象的不同，会选择不同的方式进行操作。除手动提交的一次性任务之外，还会有一些需要定时调度的场景，这部分由调度模块来负责，调度模块记录了需要调度的任务模版，参数以及调度策略，当到达调度时间的时候，会向任务引擎来提交。

任务引擎负责任务的执行，是整个运维模块的关键，对外，任务引擎提供了任务的创建、取消、重试、回滚和跳过接口，对应了实际运维中的场景，当任务通过创建接口提交给任务引擎之后，任务引擎会根据任务模版和参数来生成任务实例，任务实例是有多个原子任务实例按照一定的关系来组织的，可以用一个 DAG 图来表示，任务的执行就是按照 DAG 图的顺序来执行其中的原子任务，这部分会由 Task Executor 中的 worker 线程来执行，任务的参数定义在 context 中，context 会在原子任务之间传递。

上图展示 OCP 中的运维任务，有两种展示形式，一种列表形式，一种图的形式，都可以非常直观的展示出任务的整体结构，当前执行进度这些信息。

任务过程中遇到失败或者异常的情况，可以根据实际情况选择重试或者回滚，都是从当前失败的节点处开始执行的，重试操作会重做当前的原子任务，成功之后继续向后执行，回滚操作会按照任务执行相反的顺序，从失败节点向前依次回滚掉所有执行过的原子任务。

3.2 监控模块

OCP 另外一项非常重要的功能是 OceanBase 的监控功能, 对于掌握 OceanBase 的运行状态，保持系统的稳定运行，以及问题分析非常有帮助。

监控 OceanBase 也面临着诸多挑战：

① 监控的节点多。

② 指标的维度多，OceanBase 有许多逻辑概念，比如 zone，租户这些都会对应到指标的维度上。

③ 数据类型不尽相同，即包括 Metric 类型的数据，也有 SQL 这种不怎么标准的监控数据。

④ 需要能方便的新增或修改指标以适应 OceanBase 版本变化带来的改变。

⑤ 可运维性,监控系统需要多个组件来配合使用，节点多，链路长，也是对运维人员的一个考验。

⑥ 高可用，监控系统需要长时间稳定运行，必须考虑服务高可用的方案。

那么，如何通过 OCP 来解决以上痛点呢？

① Agent 程序部署在管理的主机上，伴随着主机的全部生命周期，agent 负责采集所在主机的监控数据，降低了采集端的数据规模。

② Agent 端实现 Prometheus 协议的 exporter，server 端实现了兼容 Prom-QL 语法的查询引擎，指标的维度通过 label 表示，在聚合计算的时候再按照 label 聚合。

③ 提供两种数据采集模式，适配不同场景。对于 metric 数据采取拉的模式，由 ocp-server 主动向 agent 拉取数据，而 SQL 采取推的模式，由 agent 主动将数据推送到 monitordb ,再由定时任务执行之后的聚合计算。

④ 数据采集和计算逻辑通过配置来实现，有指标变化时，不需要修改程序，只需要修改配置即可。

⑤ 使用 OceanBase 做存储，首先，OceanBase 本身是一个高可用的数据库，提供了数据的高可用保障。另外，减少了对其他组件的依赖，保证运维能力可控。

⑥ 高可用的部分，基于分布式锁实现 HA，有节点故障的时候可以实现自动切换。

Metric 类型的指标使用 prometheus 协议，这是监控中常用的一种指标，OCP 为减少对外部组件的依赖，自己实现了监控指标的拉取、解析、存储以及聚合计算的逻辑。SQL 类型的指标是一个相对比较定制化的采集计算逻辑，在本文中只介绍 OCP 如何来处理 metric 类型的指标数据。

整体的监控链路如上图所示，在主机上都部署 ocp-agent, 其中 ocp_exporter 进程负责 metric 监控指标的采集。根据主机上部署的程序的不同，它会采集不同的监控指标。比如上图的 Server2 上，主机上没有其他服务，就只需要采集主机。而 Server1 部署 OBProxy、OB，就会同时采集这些服务的监控指标。 ocp_exporter 的地址会在运维任务中写入到 ocp

的 metadb 中，包括对应各个服务的请求地址，期望的请求周期。

ocp-server 有定时逻辑，会按照配置的频率来生成采集任务，采集 exporter 的数据, exporter 返回的数据包含了所有逻辑查询维度作为 label，下图展示了 ocp_exporter 返回的数据的样例。

ocp 上可以灵活的指定查询维度，对应的，需要这些信息包含在原始的数据中。

Exporter 的数据采集到以后，会被放到队列中，进行异步解析、缓存和存储。ocp-server 中的数据是按照采集周期分级的，按照常用的时间查询维度，分为秒级、分钟级、小时级和天级别, ocp-server 采集到数据之后先记录在缓存当中，然后再定期写入到数据库中，为避免重复的采集，细粒度的监控指标已经采集过，就不会在粗粒度的采集任务中再重复采集，ocp-server 定时的进行采样，写入到粗粒度的缓存中，最终会写入到数据库对应的表当中。

Metric 指标的监控查询需要将采集到的原始指标按照请求的维度进行聚合，OCP 实现支持 Prom-QL 语法子集的查询引擎, 由于采集到的数据首先放在 ocp-server 的缓存当中，定期刷新到数据库中。如果要查询最新的数据，一定要通过采集节点来读取缓存和数据库中的数据，合并之后再进行聚合计算，这样会带来一个问题，采集和计算是在一个单节点上进行的，其他节点只是作为备用节点，只有当发生切换的时候才启用提供监控服务，监控服务的主节点就很容易成为瓶颈，这部分的优化在目前已经在做，会修改成每个 ocp-server 节点处理一定数量 exporter 的数据，充分发挥多节点的能力。

3.3 OceanBase 配置服务

OceanBase 配置服务是 OCP 提供的 http 服务，一般被叫做 config server，支持增删改查操作。当 OceanBase bootstrap 或者之后 rootservice 地址发生了变化的时候，会把自己最新的 rootservice 地址向 OCP 注册，OCP 记录这个集群之后，还会有后台任务主动更新 rootservice 地址，以保证 OCP 中存储的记录是最新的。其他组件如 OBProxy、OMS、Java Client、Table API Client 想要访问 OceanBase ，首先需要知道 rootservice 的地址，可以通过请求 OCP 来进行查询。

在生产环境中，如果想要同时访问多个 OceanBase 集群，一般只能使用 config server 的方式，可以查询到 OceanBase 集群列表和 rootservice 地址信息。以 obproxy 为例，如果通过配置 rs_list 的方式启动，obproxy 只能连接一个集群，而且在极端情况下，当集群的 rootservice 都发生变化的时候，会造成无法连接，而使用 configserver 可以获取到集群的列表，obproxy 可以连接多个集群，而且 rootservice 的地址会保证更新到最新的值，可以避免无法连接到 OceanBase 的情况。OCP 也支持管理 obproxy，可以在此基础上再做一层控制，维护 obproxy 和 oceanbase 集群的对应关系，可以很方便的做访问控制。

由上图可以看出，obproxy 启动参数中传入 obproxy_config_server_url 这个参数，obproxy 请求这个地址，可以获取到可以连接的 OceanBase 集群列表，已经 OceanBase 集群的 config server 地址，再通过访问 OceanBase 集群的 configserver 地址，得到真实的 rootservice 地址。

4.OCP 实际应用注意事项

4.1 安装部署

安装部署是使用所有软件的第一步。

OCP 基于 docker 发布，需要 docker 环境。
数据库使用 OceanBase，可以通过 OBD 拉起。
OCP 所需的资源主要由监控模块决定，监控数据的规模和管理的主机数量有关系，另外也和 OceanBase 集群中租户的数量有关系，需要事先做好评估，以免资源紧张造成的各种问题。

4.2 高可用规划

OCP 是一个非常重要的组件，尤其是 config server 服务，它为我们在生产环境其他组件提供连接 OceanBase 的入口。因此 OCP 的高可用也是一个非常重要的考量。

OCP 的状态都是通过元数据库来维护的，因此元数据库需要是高可用的，一般是多节点的 OceanBase 集群。
OCP 程序本身虽然是无状态的，但是为了持续提供服务，需要部署多个节点。
其他组件，比如连接元数据库的 obproxy 也是需要多个节点部署。

4.3 常见使用问题

当前 OCP 在一些使用场景中，有一些默认的假设，因为它本来是在内部使用的一个产品，然后慢慢地放到开源社区使用，用户在使用过程中可能会因不清楚默认的假设导致使用出现问题。以下列举一些常见的问题。

admin 用户不存在。这是由于 OCP 在内部使用过程中，有规范要求要有 admin 用户，并且在 rpm 打包时，也是把程序默认安装在了 homeadmin 目录下。但是在开源的使用场景中，用户可能并没有遵循这种规范。因此首先创建 admin 用户就可以避免这种问题。
缺少依赖，部署 OceanBase 的时候会依赖 mysql 命令来 bootstrap ，obproxy 守护脚本中，会依赖 nc 去检查 obproxy 是否正常,一般任务失败时会有明确的日志，安装对应的依赖重试即可。
路径权限问题。如果之前手动修改了权限或是新接管的集群，它不是由特定用户启动的，会导致出现路径权限的问题。
任务失败了怎么办。这些问题会在任务日志中有详细的体现。但是对于一个失败的任务来说，建议先点击这个失败的节点，查看它失败的原因。一般来说失败的原因是比较明确的，比如缺少依赖，只需补充安装依赖就可以了。当这些处理完之后，可以对这个任务进行重试。当然如果这个任务不需要重试，也可以直接跳过。
失败的任务一定要先处理掉，才可以对相同的资源发起新的任务，避免互相影响。
OCP 认为集群是一个管理的最小单元，许多配置会在集群维度生效，比如 OceanBase 的安装路径，在同一个集群中是要求一致的，在实际使用中，也推荐至少一个集群中使用的机器资源，配置都相同，避免不必要的环境问题。

4.4 OCP 一些好用的功能

用户和权限管理

作为企业级的管控平台，用户和权限管理是必不可少的，OCP 中可以按照角色来划分权限集合，用户可以通过与角色关联来灵活的配置权限，除了系统默认的角色之外，还支持用户来自定义。OCP 中每个用户都有自己专属的密码箱，用来保存各类资源的凭证，用户之间相互隔离，既方便又安全

Topo / 资源分布图

OCP 中以直观的形式展示了 OceanBase 的资源分布，集群和租户都有 topo 图的展示，并且可以直接在上面发起运维操作，减少用户的理解成本。