如果要学习国产数据库的基础运维技术，看原厂的运维产品功能就够；如果要学习国产数据库的高级技术实践，可以看数据库一体机。本文分享 OceanBase 的航母级产品：数据库一体机 ODM 的功能以及原理。
ODM 产品和技术原理介绍
OB 数据库一体机（OceanBase Data Machine
， 简称 ODM
）是基于 OB 分布式数据库和自研可信硬件打造的软硬一体化产品， 包括五大产品组件 : 数据库软件、 管理平台软件、 网络管理软件、 存储管理软件、 数据保护系统管理软件。
2024年发布的最新一体机产品叫蓝海贝 1 号。这并不是 OB 第一台一体机，在 OB 北京总部的蚂蚁展厅里还能看到上一代产品原型机和介绍。更早的探索就是 2020 年云栖大会展台也展示过一台一体机。
如今的 ODM 并不是简单的软硬件堆砌，而是将主机、网络、存储的一些复杂技术跟 OB 的优势功能有机结合，提供更可靠更便利更高性能的数据库服务。OB 一体机秉承了 OB 的设计理念，把简单留给客户，把复杂留给自己。后面我就一一解读 ODM 里这些复杂高深的技术。
全信创硬件
首先这个一体机里使用到的硬件都是国产的，符合信创要求。下面一一介绍。很多即使不是用的一体机也都见过，我就简单介绍。
服务器 CPU 架构支持海光3号/4号（ x86
架构）和鲲鹏 920（ARM
架构）。二者都入选过中国信息安全测评中心公布的「安全可靠测评结果公告（2023 年第1 号）」，两者的安全可靠等级均为Ⅰ级。操作系统是银河麒麟（ Kylin OS V10
)，跟多款国产主流 CPU 和 OB 数据库都有兼容适配。这个系统在数据库国产市场中使用比例也处于前列。OB 数据库作为一款“根自研”的原生分布式数据库，致力于打造负载关键业务系统的一体化数据库。早已经在数据库国产化中挑起大梁，在多个领域的核心业务场景运行。
网络交换机使用的是华三的交换机，2*32 端口 100GE ，支持 RoCE V2
，双电源和带外管理。
硬件配置里服务器数量有多个选项可选。
ODM 满配下硬件包含：
2 台网络交换机。 3 台管控服务器，包含 ODM 云管平台和 OCP 云管平台。 12 台 OB 服务器。 1 台 CDP 服务器（可选，数据保护用）。
每个 OB 服务器内部通信都是通过 2 个 100Gb 交换机，节点间网络吞吐上限也比大部分企业用户 OB 私有化部署时网络吞吐（10Gb）要高出 9 倍。一体机网络出口还是走用户自己的网络交换机。
ONM 网络加速技术
ODM 一体机里网络都是 100Gb，高于大部分企业客户的 OB 服务器网络。传统的网络协议栈（如 TCP/IP协议栈）不能发挥这么大带宽的效率。而 RDMA 技术（全称 Remote Direct Memory Access
）是一种远程直接内存访问技术，允许服务器之间直接通过网络访问彼此的内存但又不需要经过传统的操作系统的网络栈，减少了很多系统调用和上下文切换，所以网络请求延迟和系统开销都可以更低（低延迟、高带宽）。RDMA 技术还实现了零拷贝，减少了 CPU 的负载（CPU OFFLOAD
）。RDMA 可以跟多种协议一起使用，如InfiniBand
、RoCE
、iWARP
，广泛用于高性能计算（HPC
)、分布式存储、虚拟化场景中。
ODM 一体机实现了一个 ONM 网络加速组件，基于 RoCE 网络( RDMA over Converged Ethernet
）优化数据传输。而 OB 数据库作为一款分布式数据库，其很多优秀的核心功能都跟网络吞吐延时性能密切相关。如 GTS 服务提供的全局一致性快照版本、分布式事务的两阶段提交、SQL 执行计划中的跨节点的分布式扫描或表连接、Paxos 日志（clog
）的跨机同步、复制表的所有备副本的全同步、OB 旁路写入功能时 OBServer之间以及OBServer 和 ODP 之间大量的 RPC 通信。不光 OB 如此，所有的分布式数据库或产品都对网络吞吐延时性能要求很高。
OB 的架构是单机分布式一体化架构，大部分客户的核心业务场景才用的部署结构都还是分布式的。尽管 OB 也提供了一些技术（如表分组、复制表）可以减少跨节点 RPC 通信的概率，大部分业务场景的 SQL 还是会依赖分布式通信性能。在 OLAP 场景下，OB 传统部署架构下数据库的性能瓶颈点很可能就是网络。
如上图，ONM 是一个动态链接的用户空间库，使用 ONM 可绕过内核网络协议栈，得到更低的网络延迟和更高的网络吞吐。ONM 为上层应用提供了标准 Socket API，OB 及应用可以透明使用，无需任何改动，目前一体机会自动为 OB 实例内联网络及 ODP-OBServer 网络开启 ONM 加速。
下面是一个使用 ONM 给 OB 加速后的性能对比说明。
通过 BenchmarkSQL 工具压测，开启 ONM 网络优化模式后，OB 各个延迟响应指标有不同程度降低（分布式事务比例25%
，RPC In
流量7.2Gb/s
），在有网络风暴的业务场景下，系统业务性能提升高达18%
。
OSM 文件系统
OB 生产环境部署推荐的是本地 NVMe SSD。容量规格通常有 4T 和 8T 两种。这类 SSD 性能和吞吐都非常高。一般每台服务器会配置 4 块以上。在私有化部署 OB 准备硬件环境时，总会面临一个难题就是 NVMe SSD 要不要用 RAID 卡。
OB 的建议都是不需要，在操作系统里使用 LVM 技术将多块 NVMe SSD 聚合成一个磁盘卷组（VG）然后再划分为 两个逻辑卷（LV）分别给 OB 的数据文件和日志（指事务日志 clog
等）用。这是一种无奈的方案。因为 LVM 会消耗部分 CPU ，不能完全发挥出 NVMe SSD 的最大性能。理想的是用 NVMe SSD RAID 卡，但是这类 RAID 卡产品非常少，还非常昂贵。所以以前 OB 在企业私有化部署的时候，通过 OB 的多副本技术去应对单机坏盘故障。一般客户 OB 集群业务数据至少是 3 副本；在金融行业里，核心业务 OB 集群还使用的是 5 副本。
在 OB 公有云里产品里，OB 服务器（虚拟机 ECS）使用的都是云盘，云盘自身提供容灾能力。云盘也是一种分布式存储产品。只不过这项技术不会输出到企业客户环境（除非企业选用了公有云厂商的云底座，如阿里云底座飞天、华为云底座等等）。
分布式存储对网络吞吐要求很高，至少是 100GE 的网络。否则，存储的延时和性能都得不到保障。ODM 恰好具备这个网络条件，所以 ODM 也实现了自研的文件系统 OSM ，将服务器本地 NVMe SSD 磁盘资源进行集中管理。
OSM 技术功能优势如下：
提供 RAID 2.0 的副本保护。OSM 能支持 1/2 副本保护，不管盘的数量是奇数还是偶数，数据文件会按 Bucket 进行切分。 OSM 可以做磁盘间的容量均衡、负载均衡等等。可以简单类比为 ORACLE RAC 技术中的 ASM 文件系统。
提供 FailGroup 故障组功能。OMS 支持用户自定义 FailGroup 故障组，文件 Bucket 副本可以跨故障组进行冗余保护。一个 FailGroup 的所有磁盘损坏都不会影响 OSM 里文件的可用性。建议每个 FailGroup 的磁盘数量和容量保持一致，这样数据分布和复杂均衡特性最好。当一个故障组的磁盘修复或替换后重新上线时，OSM 会自动补齐对应磁盘数据。简单的说，当一块 NVMe SSD 故障了，该节点的 OBServer 依然可以继续提供读写服务。没有 OB 节点会挂。运维只需要替换故障的 NVMe SSD 盘，盘里的数据会由 OSM 自动补齐（类似传统 RAID 里磁盘 REBUILD）。磁盘故障不影响 OB 节点使用。
提供智能 IO 路径访问。OSM 采用多副本模式保护数据时，数据写入策略是强制所有副本同步。在读取数据的时候，OSM 的调度可以智能选择读取哪个副本。选择的原理是 OSM 内部会统计每个磁盘的 IO 响应延迟，调度会优先访问延迟较低的副本。这里面的原理跟 RAID、ASM 都是相通的。
提供数据安全与空间容量。前面说了，OB 传统的私有化部署，本地 NVMe SSD 磁盘一般不做 RAID 保护，所以磁盘故障就会导致 OB 节点不可用，部分受影响的数据会发生主备切换。计算存储一体化的部署模式下，此时也同时损失了部分计算能力（节点已经不可用）。 OSM 显然就没有这个问题了。当然代价就是磁盘容量方面。RAID 技术也有容量代价，加上 RAID 组还需要预留 1-2 块热备盘，OSM 不要求这个。实际上由于 OB 数据压缩比非常高，使用 OSM 多副本加 OB 三副本后，在容量方面客户依然能取得 3+ 压缩比效果。
提供 COW 与快照功能。OSM 作为一款文件系统支持 COW 写时复制和 NOCOW 原地写入两种模式。基于 COW 写时复制技术，文件系统底层可以随时创建快照。快照技术不是拷贝原始数据， 而是记录数据块指针的变化。所以对于大多数读多写少的业务，OSM 的快照不会占用太多的空间，用户可以基于快照数据进行历史数据的访问。OB 的 LSM Tree 也非常适合做快照，每日合并产生的一个全量版本就是一个快照。只不过 OB 并没有提供快照的访问接口。
提供更好的读写性能。OSM 有多副本、FailGroup 设计、快照设计、内部数据校验、智能 IO 路径等多项功能，性能方面相比 NVMe SSD 而言是不减反增，可以提升 3-6 倍。
CDP 数据保护技术
OB 的高可用设计能力本身已经很强大，包括多副本高可用、主备复制保护以及租户的备份和恢复能力。当数据库发生逻辑错误时（如误删除库或表），业务需要恢复数据，这时候就要走一个不完全恢复，此时就依赖 OB 的备份和恢复能力。当真走到这一步的时候，客户对恢复的时间是期望尽可能的短。
ODM V4 一体机支持 CDP (全称 Continuous Data Protection
），部署一个 CDP 节点可以对 OB 数据进行持续数据保护。原理如下。
ODM CDP 节点会定时对数据存储做快照，当接到要恢复出一个历史时间点的租户数据时，ODM 会找到最接近这个时间点的历史存储快照，然后存储层面克隆数据然后再对数据库应用快照点和目标时间点之间的归档日志（clog
的备份）。这个原理看起来好像跟 OB 租户的恢复原理类似。OB 是从最近的一个全量数据备份开始还原，后面的原理就差不多。
如果租户数据量很小，ODM CDP 跟 OB 的租户还原性能可能差异不大，但是如果数据量很大，这个恢复时性能差异就体现出来了。 以一个 10TB 的租户快速恢复为例，恢复时间是 5 分钟左右。并且支持多个时间点数据恢复，且能持续数据保护，恢复 RPO 接近 0。这个能力也远高于市面上所有的数据库备份一体机产品。
ODM CDP 这个能力除了做容灾恢复外，还可以用于快速构建测试环境，特别是准生产验证环境。尽管 OB 租户克隆功能也可以，但是仅限于同机克隆租户数据。如果跨机了，依然会涉及到租户全量数据的复制。
NUMA Aware & OB 单机多实例技术
ODM 的 OSM 文件系统的 IO 吞吐量非常高，远超出目前 OBServer 节点的处理能力。不仅是 IO，单个服务器的 CPU 、内存和网络能力的提升幅度也是远超单个 OBServer 处理能力的提升比例。也就是单个 OBServer 并不能充分发挥服务器的资源能力。在十多年前，互联网大厂使用 MySQL 替换 ORACLE 的时候也碰到这个问题，单机 MySQL 相比 ORACLE 处理能力差的太远，所以想出一个解决办法就是单机部署多个 MySQL 实例。这就是最早的 RDS MySQL 的雏形。一个打不过，十个一百个总行吧。单机搞不赢，分布式总行吧。
这个思路同样适合 OBServer。 OBServer 在开发测试环境受限于服务器的数量，是有单机部署多个 OBServer 实例（注：一个 observer 进程称之为一个实例）的做法，但是在生产环境 OB 原厂从来就没有做过这方面的实践，OB 的自动化运维平台 OCP 也不支持单机部署多 OBServer。 蚂蚁业务采取的是将物理机虚拟化出 k8s 容器或 ECS，在 ECS 里部署 OBServer 。目前公有云 OB 就是这个思路。云猿生公司也有针对 OB 部署的 k8s operator
产品。虚拟化会导致硬件资源能力有一定损耗，是不得已的办法。
ODM 里服务器的网络、存储能力非常高，所以目前也支持单服务器部署多个 OBServer 实例做法。这个做法并不复杂，就是每个实例的软件目录、数据文件目录、事务日志目录都保持独立就可以。 ODM 所作的并不止如此，当单机部署多个 OBServer 实例时（实际上选 2 个），ODM 还建议开启服务器的 NUMA 特性，针对每个 OBServer 实例做 NUMA 绑定。这样多实例的 CPU、内存资源使用都不会出现冲突。
单机多实例另外一个优势就是能充分利用存储资源。
如上图所示，在单实例环境中，并行装载数据的速度为 297M/秒，并行查询的性能为 10.05GB /秒，通过使用多实例方式，并行装载速度提升 247%，并行扫描速度提升 311%，随着 OB Server 版本的迭代，每一个实例可以利用消化的 IO 能力也会有或大或小的提升，不过利用多实例提升单机能够利用的 IO 能力是一种通用手段，在绝大部分数据库中都适用。
第三，单机多实例还有个意想不到的好处就是减小了磁盘损坏影响的数据范围。这里暂且不说 ODM 的 OSM 文件系统的 FailGroup 已经有缩小故障范围的能力。退一步说，假设 OSM 没有做多副本冗余。单机多实例的场景下，单个盘的故障只是影响一个实例，而这个实例的数据粒度比以前小，所以影响范围更小一些。
ODM 部署架构
ODM 里的 OB 部署架构有很多种，主要看客户需求。这也是 OB 单机分布式一体化能力的体现。
OB 租户主备架构
不少用户业务系统基于 MySQL Master/Slave，Oracle ADG 架构建设，迁移到OB 后依旧需要使用集中式数据库架构，ODM V4 一体机推出 2 数据节点，1 备份节点的 2+1 精简架构，集HA 故障切换，租户副本同步，CDP 备份保护能力于一身，经济安全，简单易用。
上面这个架构功能是针对 OB V4.2 版本的一体机架构。4.2 版本的 OB 主备粒度是租户，主备租户的切换，业务是需要修改连接的用户名（因为主备集群名或租户名至少有一个不一样）。ODP 4.2.4 版本以后推出租户的服务名连接方式，支持新的业务用户名格式：用户名@SERVICE:服务名，主备租户可以共用一个服务名，不需要带集群名名字。这个功能在 4.2.1 版本还不具备。ODM 这里用了自己的方式去解决了这个问题，通过 ODM VIP 连接租户时，用户名不需要带集群名。
原本 OB 主备租户的切换是需要 DBA 手动做的，ODM 引入了 HA 功能，增加了对 OB 主备租户可用性的监控和自动化故障切换功能。并且结合 CDP 功能还可以提供一个实时的备份环境（随时可以做任意时间点恢复）。ODM 引入的负载 VIP 功能，免去了对外部 F5 等硬负载的依赖。
OB 4.2 带仲裁服务的 2F1A
架构
仲裁服务是 OB 为节省服务器推出的技术，资源消耗非常小。ODM 将仲裁服务跟 CDP 节点合并使用，整体效果更好，资源也没有多出。 仲裁服务会保障 OB 节点故障自动切换，保障 RPO=0 和 RTO~8s，这是 OB 自身的能力。
如果在一体机里大量使用仲裁服务，满配的 12 台 OB 服务器理论上可以部署一个拓扑为 6F-6F-1A 的集群拓扑。
计算存储分离
ODM 一体机可以支持存算分离架构的一体化安装，包括计算节点，存储节点和 RoCE 网络。存储节点基于 NVMe OF 进行SSD 磁盘的高速共享输出，计算节点使用 OSM 加载共享磁盘，并自动编排磁盘设备-OB 实例的对应关系，生成文件系统，整体 IO 网络基于 RDMA 协议，低延迟，无损耗，实现计算资源池和存储资源池的横向扩展。
从文档推测，ODM 的计算存储分离部署架构下，每个计算节点还是单独使用一个数据文件，并不是使用共享的数据文件（否则 OB 内核架构变动太大）。
不过看官网 OB 4.3.4 的文档也提到了一个基于共享存储部署 OB 的架构，这个却跟以往 OB 的架构原理发生了很大变化。
基于共享存储模式（SS 模式）采用了存储计算分离的架构，每个租户在共享对象存储上存储一份数据和日志，每个租户在节点的本地存储上缓存热点数据和日志。
租户的日志流副本间通过 Paxos 实现日志复制，各副本日志先写到节点的本地存储上，每个主副本将一份全量日志上传到对象存储，每个从副本自动识别日志热度，仅在本地缓存少量热点日志。
每个主副本负责将一份全量基线数据上传到对象存储，副本间共享对象存储上的基线数据，所有副本自动识别数据热度，仅在本地缓存热点数据。租户的每个副本独立转储，转储数据不在副本间共享。
这个功能非常新，共享存储是对象存储，所以推测是 OB 公有云产品推出的新的部署架构。使用分布式共享存储技术，可以进一步降本增效。如果这项技术成熟了，那 ODM 一体机结合自身的优势应该也能移植这项技术。
ODM 其他信息
ODM 其他优势就是一体化开箱交付。国产化硬件和数据库交付，最怕的就是软硬件之间的兼容性问题，出了问题容易扯皮。ODM 专门做了兼容性和稳定性、性能测试，消除用户这类问题。
ODM 的使用场景初步判断适合那种业务逻辑复杂或数据量大的场景。如 ERP、BOSS、数据仓库。实际典型客户案例有运营商、证券和保险等。
一体机的性能亮点之一就是 IO 吞吐大。
虽然说 OB 的性能优化诊断能力很强，在索引、执行计划、并行方面都有着不错的能力。但是当业务逻辑很复杂的时候（企业客户很少有说自己业务简单的），SQL 会很复杂。多表连接、条件动态组合。这种情况下靠优化索引，投入大收获小。为了性能更好，一般复杂查询要提升性能就要充分的发挥 HASH 或 Merge 连接和以及并行的特点，这时候业务 SQL 的性能瓶颈通常在 IO 、网络或 CPU 。
这种业务场景如果跑在 ORACLE 上一样是一个慢。这时候就主要靠硬件能力了。ODM 在 IO 吞吐、网络吞吐和延时上比常规的企业环境要好很多，所以 ODM 在面对这种复杂的负载高的业务场景下，会有很大优势。
