OCP 的 VIP 和高可用方案

OB 项目的服务器资源规划里，尽量要包含 OCP 服务器的资源，不然 OB 运维很不方便。集中式版本（以前叫单机版）客户，不一定有这个，形势就更不乐观。本来这部分客户群体，对 OB 的了解就很少，运维难度更大。

OCP 产品可以降低 OB 运维门槛，OCP 的故障不会带来业务故障（业务照常使用 OB），只会影响 OB 运维。 如监控告警、备份、性能诊断等。客户可能会觉得既然如此，OCP 给个虚拟机，资源少一点就行。这个就要命了。

OCP 产品里带了一个元数据库 MetaDB，也是一个 OB 数据库。这个 OB 数据库的运行对服务器资源就有个最低要求。加上 OCP 这个应用的数据库负载实际上不低，QPS 和 TPS 并不比一般的业务低（500+）。资源问题绕不开，前面文章已经提过，这里就不展开说了。

这里说的是如果客户在乎 OCP 的重要性，就也需要提供多台虚拟机实现 OCP 的高可用。 OCP 的高可用主要是元数据库 MetaDB 的高可用和 OCP 应用的高可用。 MetaDB 的高可用一般是 3 节点（3 副本集群），节省资源的方案还有 2 副本带一个仲裁（仲裁节点资源可以低一点  4C8G)。OCP 的高可用就简单了，部署 2~3 个 应用即可。

要做高可用就要使用 VIP 提供统一访问。OCP 访问 MetaDB 需要一个统一的 VIP 访问，OCP 对外提供 API 也需要一个统一的地址（含 VIP）。各个 OB 节点上性能数据上传也需要一个统一的 MetaDB 连接地址。针对 MetaDB 的 VIP 是 4 层协议（  TCP ），前端端口可以定为  2883 或  3306，后端是 MetaDB 的各个 OB 节点上的 ODP 的  2883 端口。针对 OCP 应用的 VIP 是 7 层协议（  HTTP)，开会话保持功能。  VIP 的申请需要在部署前准备好。

问题是有些客户做不到提前准备好。交付人都到现场开始了，没有 VIP。那 OCP 还能部署吗？能部署，只是后期换 VIP 会很麻烦。它不是你把 OCP 3 节点部署好了，后面多了一个 VIP 能访问即可。 而是要把这个 VIP 的信息写到 OCP 的元数据库以及 OCP 容器的启动地址里。 这两者之间是有个微小的差异。通常看不出来。

当有一天 OCP 服务器故障了（通常是第一台），就会发现虽然 OCP 是三节点部署，OCP 却还是不能用。这就是前人挖坑后人遭殃。

有关如何修复这个问题或者如何给三节点 OCP 启用 VIP 的方案比较复杂，我在之前的培训视频里讲过，有兴趣的可以去公众号里找视频。

还有一类客户是想着前期资源有限，先用一台部署 OCP，等后期再给 OCP 扩容。跟上面一样， MetaDB 从集中式扩容到分布式后，也需要启用 VIP 才算真正的扩容完毕。

OB 的 IP 更换方案

很少有人知道，OB 是不支持换 IP 的，只有到真的有那个需求的时候，才傻眼了。这种场景最容易出现在 OB 集中式版本客户里。

一个客户先交付了 OB 集中式版本（单机版，后不再重复）。都快上线时客户说网络要重新规划一下，换个 IP。代理商以为 OB 能像 MySQL 一样换个 IP 重启一下即可。然而，OB 不支持换 IP。

OB 不支持服务器更改 IP。 如果服务器强行更改 IP，OB 直接就挂了。这个客户就是这个情况。

OB 不支持换 IP 的原因是 OB 把 IP 写到内部去了，不光写到元数据里，也写到事务日志、运行日志里等等。可以理解为写到骨子里了。根本就不能换 IP。TiDB 也是这样。但是其他基于 MySQL 构建的分布式数据库没这个问题（虽然可能也存在换 IP 也麻烦，但不是不能换）。让 OB 换 IP 不啻于要给 OB 做换血手术。

但 OB 有换 IP 的方案。

在分布式集群里，把一个节点从集群里踢出去，然后更换 IP 再加回来。 三个节点，轮一遍就换完了。单机版 OB 就没法用这个方案。要么删除 OB 重新用新 IP 部署，要么新增一台服务器，用新 IP 跟这个老 IP 的 OB 做主备，然后主备切换一下即可。

这两个方案在这个客户里都行不通。一个是它没有多余的服务器，二个它是网络重新规划（子网更替），两个子网不同时存在。就算客户深谙有困难解决困难这个思路，把这个外在条件解决了，交付人力投入也是问题。让人返工，成本算谁的。

然而，这个问题并非真的毫无办法。这个题目就像初中生考试卷里的附加题一样，考的是运维的综合技能。具体考的就是对 OB 访问原理（跟 IP 有关的部分）以及网络基础原理。

所以，这里的有一个办法就是给这个服务器做两个 IP，一个老的 IP，一个新的 IP。前面说了网络团队不会有 2 个子网同时给 OB 用，但是没有关系， 老的 IP 不需要有路由，这是个单节点的 OB！ 只要老 IP 存在，这个 OB 就可以拉起来。  加上 OB 监听的时候默认是监听所有 IP 的  2881 端口 （这是 OB 的 IP 奇葩解决方案的关键，OB 一体机基础版的解决方案里也用到了这点），所以业务访问 OB 可以通过新的 IP 访问。

这样就两全其美了。当然，给一个网卡做两个 IP 考验一点网络技术（在 AI 的帮助下这都不是问题）。

再把这个题目难度加大一些，如果这个客户部署了 OCP 和业务 OB 呢？两个都要换 IP（子网变更），又该如何？有兴趣的朋友可以自己挑战一下，写在评论里。

OB 把 IP 写到骨子里这个设计，确实让换 IP 不是那么顺利。后来我看 GaussDB 的架构方案里，有个设计巧妙的解决了类似问题。在 GaussDB 的云环境 HCS 里，每个节点有多个 IP。有物理 IP、管理 IP 和 业务 IP 等。管理 IP 是一个 Floating IP（浮动 IP），跟 GaussDB 的运维 TPOPS 是同一个子网。这个 Floating IP 是个虚 IP。当 GaussDB 的节点要更换服务器时，物理 IP 会变，但是 Floating IP 继续沿用（直接换到新的服务器上）。虽然新服务器物理 IP 变了，但是 GaussDB 不依赖他（管理依赖的是 Floating IP，业务访问用的是业务 IP，都是虚 IP，随时可以换）。

所以，参考 GaussDB 的这个设计，部署 OB 分布式或单机版时，也可以考虑这个思路。 部署时使用虚 IP，不要用物理 IP。 这样后面不管是换 IP 不换服务器 还是换服务器又换 IP，都能应对。当然，只要是服务器换了，这个里面就有个节点数据重建的过程（GaussDB 也是如此，重建是管理平台的事情）。

所以，如果服务器真的换了，理论上在 OCP 里重建这个节点就行。 但是这个未经测试。 因为 OCP 的设计从来考虑过这种场景。如果 OCP 重建任务失败了，那就手动处理一下。只要了解这里的原理，重建节点比将节点踢出去再加回来路径更短。这个在以前的文章里也提到过（参考文末文章）。

云上的 VIP 方案

有部分客户是运行在公有云或者专有云环境里，云产品里有负载均衡产品提供 VIP。虽然都叫负载均衡都是 VIP，但跟硬件负载均衡产品（F5 或 A10）的功能并不一定完全一样。F5 或 A10 的 VIP 支持开启 SNAT 和 DNAT 特性，支持后端节点访问 VIP。 但云上的就不一定。

目前用过微软云、阿里云的负载均衡的 VIP 给 OCP 和 MetaDB 使用的时候，就出现过 OCP 间歇性通过 VIP 无法连接 MetaDB。单独在 OCP 服务器上用  mysql 测试元数据库的 VIP 连接，也是有时候能连有时候不行。后来经云产品分析原因是如果后端节点通过 VIP 转发后的请求又被路由回本节点时，本节点不会回包。推测是云产品没有选择 SNAT 方案。

这跟云产品的 VIP 技术原理有关。各个云产品网络方案可能有细节区别，解决方案也有多种。比如说将 OCP 和元数据库分开部署，或者云产品 VIP 开启 DSR 以及将 VIP 绑定在后端  lo 接口上（云产品有方案）。

了解 VIP 的连接路由原理对排查 OB 应用连接异常也很有帮助。

阿里云的负载产品 SLB 是基于开源的 LVS 改造的。对于云下的企业用户，如果没有硬负载产品的话，可以用开源的 LVS 和 KeepAlived 软件。不过开源产品的使用有一定技术门槛，不同客户的使用体验也存在一些差异。这点以后再专门分享。

客户端的 IP

在应用连接问题和性能问题的排查中，如果在数据库里能根据应用的 IP 定位到相应的会话、SQL 审计记录、运行日志的话，排查问题的方向可能会更准确，效率可能会更高。但如果应用是通过 VIP 连接到 OB 时，在 OB 上就不一定能看到应用的真实 IP。

这个首先跟网络技术方案有关。如果 VIP 里有做 SNAT 方案，那么连接到 OB 上的请求的源地址就是负载均衡设备的虚拟 IP。即使没有 VIP 的 NAT 映射，应用在连接数据库的路上如果经过主机的网络转换方案（如 K8S 和 Docker 的网络桥接或 NAT）或者请求走了公网（经过防火墙做了 NAT 映射），OB 的连接请求地址看到的也不是真实的应用客户端 IP。

这个能看到也不一定是好。这模棱两可的说法感觉就像是没说一样。

OB 提供了一个方案能看到应用客户端的真实 IP，适合 JAVA 应用。 当应用使用 OB 的 JDBC 驱动连接 OB 的时候，驱动会自动将客户端真实 IP 信息写入到网络报文里。 OB 接收到这个连接请求会解析出这个真实地址。这个地址会体现在会话视图  gv$ob_processlist.user_client_ip 、  gv$ob_sql_audit.user_client_ip 中。大部分时候，这个特性对问题定位帮助还是很大的。

不过碰到那种大量 K8S 应用的时候，就没用了。很多应用客户端的本地地址都是同一个子网，甚至有重复。如果企业网络管理员对容器产品虚拟网络的地址有做好的规划，这个也不是什么难题。

由于这个特性原因， 在 OB 数据库上就不适合针对客户端 IP 做白名单了。 如果网络上针对数据库访问请求有做 ACL 的需要，就把这个事情交给网络管理员去做（在防火墙等安全产品或交换机设备上做）。

立即试用 OceanBase 企业版，体验国产数据库能力 立即试用 OceanBase 企业版，体验国产数据库能力