本文总结 OceanBase 五花八门的部署架构及其原理,满足各个行业企业的形形色色的数据库容灾和多活部署需求。有兴趣的看看,总有一款适合你。

标准部署形态

首先来一个 OB 最基础的最中规中矩的部署架构图。

obd程序开发(闲话OB之部署架构实践)(1)

这个图信息量很大,下面一一说明。

部署一个产品,最大的挑战就是用户环境。100 个用户,可能就有 100 种环境。产品应付不过来,要求部署环境要标准。所以,部署的第一步就是环境标准化。

部署环境标准化

不同客户的机器配置也不尽相同,OB 会对软硬件提一些基本要求。然后提供一个工具对机器进行自动初始化。主要是 OS 内核和会话参数的设置、文件系统的划分、用户和相关目录的创建。

早期的时候需要命令行下每个机器挨个执行。现在提供了一个 OAT 产品(有图形界面),挨个添加机器,点点鼠标,自动初始化环境。现在一次初始化十几台机器也不是问题。

OAT 怎么部署?

OAT 为了适应各种客户环境,选择了 docker 技术,只要启动一个 docker 容器就可以用。

初始化机器环境只是 OAT 基本功能,还可以自动化部署 OCP、OMS、ODC 等产品。这些产品都提供 docker 镜像,都以容器形式运行。就不怕用户环境的千差万别了。

早期没有 OAT,则在命令行下用 OB 提供的软件自动化部署 OCP 容器。

关于 OCP关于 OB

大部分客户案例里,OB 集群的机器数是 3 或 5 的倍数。有的人会觉得客户比较浪费机器。这个却未必,因为 OB 还有多租户和多活的能力。

多租户

OB 以集群形态部署,提供多租户(多实例)能力给不同业务用。

首先看看 OB的多实例示意图。

obd程序开发(闲话OB之部署架构实践)(2)

如果是上面这个部署图,那是给人感觉有点浪费机器。但是 OB 很灵活,它还可以是下面这种部署形态。

obd程序开发(闲话OB之部署架构实践)(3)

当所有机器上都有实例的主的时候,这台机器就不空闲了,也就不浪费了。

如果只是上面这种还好理解。实际上 OB 的灵活性远不止这些。还可以下面这种部署形态。

obd程序开发(闲话OB之部署架构实践)(4)

每个实例 1 的三份数据都是主,彼此双向同步。有人说,这怎么可能?

OB 确实可以这样,这里的奥秘就在于 OB 里主备的粒度很细,可以到表级别(实际更细到表的分区)。

obd程序开发(闲话OB之部署架构实践)(5)

当机器上有主副本的时候,就可以认为实例在这台机器上也提供服务了。自然,这个机器也不会空闲。这就是 OB 的多活能力。

OB 的多租户使得机器资源使用粒度更精细,OB 的多活能力使得机器利用率更高,所以当业务体量有一定规模时,OB 可以用更少的机器满足业务需求。

所以,你还认为 OB 浪费机器吗?

如果你还是这么认为,那 OB 还有更超出你想象的部署形态。

在那之前,先看看 OB 扩展后的形态。

扩容后的 OB 部署形态

假设现在 OB 集群 从 1-1-1 扩容到 2-2-2 。可以变成下面这个形态。

obd程序开发(闲话OB之部署架构实践)(6)

或者是下面这个形态

obd程序开发(闲话OB之部署架构实践)(7)

或者是下面这个形态

obd程序开发(闲话OB之部署架构实践)(8)

纵向看,每2台机器是一个 Zone。OB 实例可以控制主副本在哪个 ZONE 或者在那几个 ZONE。所有实例的主副本都在一个 Zone,就是单机房提供服务,其他两个机房都是备机房。所有实例的主副本都在两个 Zone,那就是双活模式。所有实例的主副本分散在所有 Zone,那就是多活模式。

上面图更突出 OB 灵活性的是 实例 1 和 实例 2 都只用了 3台机器的资源,实例 3 用了6台机器的资源。实例 3依然是3副本,只不过每份数据分布在2台服务器上。

这些可以在线变换,这就是 OB 集群和租户的在线弹性伸缩能力。用户只需要改变策略,数据迁移是 OB 内部事情。

资源异构的部署形态

标准部署形态中,OB 集群三台机器资源都是对等的,每个 Zone 机器数量一样。每个实例在三个 Zone 里的资源大小也基本保持一致。这是最佳实践建议。但是技术上,为了满足一些客户项目机器预算有限,OB 是可以接受三个Zone 资源异构。

OB 的分区副本有多种类型:

obd程序开发(闲话OB之部署架构实践)(9)

日志副本

日志副本不包含数据,使得可以节省磁盘空间。CPU和内存方面也可以适当减少(内存不能太小,不要低于8G)。 日志副本的内存大小会限制整个实例能创建的分区数量,所以不要太小。 日志副本的特性,使得下面这种部署形态也是可以的。图中矩形框的大小可以理解为资源的大小(资源就是CPU、内存和空间)。

obd程序开发(闲话OB之部署架构实践)(10)

架构说明:

上面这种用法只是进一步提升了机器资源利用率,并没有明显减少机器,下面这种玩法就更高级了。

obd程序开发(闲话OB之部署架构实践)(11)

架构说明:

比如说下面这个就是一个业务场景的资源布局图。

obd程序开发(闲话OB之部署架构实践)(12)

架构说明:

只读副本

默认情况下 OB 的三副本只有主副本提供读写服务,备副本不提供服务。但是通过 OBPROXY的会话设置或者 SQL语句设置,业务也可以读备副本。这就是读写分离。

不过由于 OB 特殊的多实例能力,以及多活,这种读备副本的读写分离意义不是特别大。如果是大量的读写分离需求,建议部署只读副本。

obd程序开发(闲话OB之部署架构实践)(13)

架构说明:

只读副本的数据是从主副本同步过来的,理论上会有延时,但是数据绝对不会错。只读副本自身故障后恢复时,数据同步可以自动恢复,不需要 DBA 介入处理数据同步。只读副本也可以在线重建。所以说 OB 的运维是非常方便的,只有体验过一次的人才能理解。

除了资源异构,OB 还有很多种混合部署方案。

混合部署方案国产化方案

OB 集群支持国产化产品:

OB 集群可以全部部署在国产化服务器上并使用国产操作系统。外部有代表性的客户案例有宇宙行的对公理财业务。

当然有些客户可能对国产服务器和软件还有些担心。OB 也支持下面这些混搭方案。

混合云部署方案

主要适合有专有云和自有机房的客户。可以在专有云和自有机房之间部署一个 OB 集群,或者 OB 主备集群。OB 本质是一个软件,可以部署在物理机、ECS上,只要网络通并且延时和带宽满足要求即可。

使用主备集群方案时,可以将备集群放到云上 或者 线下,实现云上和云下的容灾。

多云部署方案

主要适合在多个云厂商有 ECS 并自建数据库的客户。只要打通两边云厂商的 VPC 网络,横跨两个云厂商的ECS部署一个 OB 集群。建议5副本,实现跨云的多活能力。

OB 的容灾多活部署方案

OB 产品的特别之处就在于 OB 集群可以跨机房部署,甚至可以跨城市部署。根据实际需求不同也有多种玩法。

两地三中心三副本

架构说明:

两地三中心五副本

obd程序开发(闲话OB之部署架构实践)(14)

架构说明:

双机房主备容灾方案

使用 Paxos 或者 Raft 技术的产品,都要求副本数是奇数(偶数副本数没有意义),在机房容灾部署的时候都会要求有三个可用区。但是传统客户,尤其是金融客户,都是同城两机房,异地可能还有个机房,只是那个机房很可能延时大带宽太小,规格不够。实际能用的就是同城双机房。

目前 OB对双机房的部署方案就回归到传统 ORACLE 的 Dataguard 方案。

obd程序开发(闲话OB之部署架构实践)(15)

架构说明:

OB 主备集群双机房方案跟传统主备方案的能力和特点一样。缺点也是一样的,就是备集群默认不提供服务,备机房也没有利用上,有点浪费。不过 OB 的备集群也是可以提供只读服务,这也是 OB 读写分离的一种使用方法,分离的更彻底。

如果想利用备机房,OB 的部署架构图还可以调整为下面这种:

obd程序开发(闲话OB之部署架构实践)(16)

架构说明:

单元化部署方案

单元化是多活能力的最高标准,指的是从业务到数据库的链路都发生在某个机房。

要实现单元化,必须在应用层面对数据水平拆分,即分库分表(为什么?这个说来话长,这里不细说请看参考资料)。具体是 1 库 1 表或者 1 库多表,看业务特点。也不是所有的业务都能水平拆分。此外也不要盲目上单元化。

下面仅看能做水平拆分的业务数据的单元化部署架构。

obd程序开发(闲话OB之部署架构实践)(17)

架构说明:

obd程序开发(闲话OB之部署架构实践)(18)

以上是蚂蚁和网商两地三中心五副本单元化的示意架构图,这套架构使用了 SOFA OB 的多个产品。SOFA & OB 最佳实践已经在多个外部客户落地。

蚂蚁做单元化用了至少5个机房,外部客户不一定有这么多机房。4个机房的也可以玩。下面是某国有大行的银行核心业务之一的近似单元化架构。

obd程序开发(闲话OB之部署架构实践)(19)

架构说明:

后记

总结一下,不管 OB 是那种部署方案,在一个集群内部,只要故障节点是少数派节点,OB都能提供极致的高可用能力(RPO=0,RTO~30s)。 OB集群的各种部署架构和性能测试都是把数据安全放到第一位,没有异步同步或半同步等技术。

针对 OB 主备集群,需要认识到主备集群同步跟传统数据库主备同步原理是一样的,不一定能保证故障切换不丢数据(RPO>=0),并且故障切换也是需要手动做的(RTO~分钟级别)。

以上 OB 的能力大部分也适用于 OB 社区版。(社区版没有 OB 主备集群复制能力)。

OB 的部署方案都说到了吗?

还没完,OB 3.2 版本推出计算存储分离架构,前期会先内部业务试用。对外发布后届时可以针对计算和存储能力分开配置服务器数目,上面部署形态又可以进一步变化。。。

“变态”!

如果您觉得文章对您有帮助,可以点赞评论转发支持一下~谢谢!

原文链接:https://www.tuicool.com/articles/iMr26fv

,