与运维

Promethues部…在K8S上部署OceanBase的最佳实践

背景与选型

OB下称OB是一款分布式关系型数据库具有高性能、高可用性和弹性扩展等特点其企业版已经在公司内部的去Oracle项目中进行了落地并取得了不错的效果。

此外考虑到我们仍有许多业务在关系型数据库上有着需求同时考虑到我们已经具备MySQL/MariaDB/MongoDB/PostgresSQL在公司内部的K8S集群上进行容器化部署经验因此我们决定将OceanBase也进行容器化部署。

1.1

高可用性OB是基于Paxos算法的强一致性数据库具备强大的容灾能力支持多数据中心部署同时单点故障并不影响业务连续性。

弹性扩展OB的租户特性使得相比MySQL和TiDB等关系型数据库而言OB提供了更灵活的扩展能力能够根据业务需求动态调整资源。

成本OB内核天然自带数据压缩能力相比MySQL/TiDB具备更低的存储成本特别是在大规模部署时能够有效降低硬件成本实测重复性文本数据下OB的存储成本仅为MySQL的1/4甚至更低。

兼容性OB内核天然兼容MySQL协议方便现有应用的迁移和集成。

1.2

OB集群的能力能够简化部署、扩展和运维的复杂性。

其主要优势包括

自动化管理ob-operator

能够自动处理OB集群的生命周期管理包括创建、更新和删除。

灵活性支持自定义OServer/OBTenant资源支持快速扩展集群规模,

支持通过CR文件快速修改参数。

高可用性通过多实例部署和健康检查机制确保集群的稳定运行。

支持静态IP和OVN网络确保POD重建后仍然使用原IP避免了POD重建后IP变化带来的问题。

部署实操

OBClient。

Kubernetes集群需要安装网络插件例如OVN。

2.3.1以上版本

ob-operator

https://github.com/jetstack/cert-manager/releases/download/v1.5.3/cert-manager.yaml#

拉取镜像需要科学上网

安装ob-operator的操作可参考ob-operator部署如果手动通过CRD部署可以自行从github仓库中下载CRD和Operator的yaml文件然后通过kubectl

apply

的会话减少客户端与数据库之间的连接开销。

负载均衡OBProxy

节点发生故障时OBProxy

OBProxy可以集中管理访问控制和安全策略增强系统的安全性。

配置步骤

--from-literalpasswordproxyro_password#

OBProxy

oceanbase/obproxy-ce:4.2.1.0-11ports:-

containerPort:

passwordresources:limits:memory:

2Gicpu:

此时可以通过OBProxy的Service提供OB数据库的访问入口如下obmysql是我提前创建好的租户testdb是提前在obmysql下创建的用户

当然在实际的生产中我们采用的是域名访问的方式而不是通过IP地址访问因此需要进行域名重写可看下一小节。

2.5

odp-headless-ob-{1}.oceanbase.svc.cluster.localanswer

name

odp-headless-ob-(.*).oceanbase.svc.cluster.local

cluster.local

域名。

统一管理通过规范的域名格式ob-*.rds.com便于管理和维护多个

自动完成域名转换对应用层完全透明。

灵活扩展可以根据需求轻松添加新的

访问流程

odp-headless-ob-{clustername}.oceanbase.svc.cluster.localHeadless

Service

应用ob-operator中的promethues.yaml文件进行部署文件链接promethues.yaml

kubectl

root(datamars)mhpl74334-10.20.248.59

kubectl

可以应用ob-operator中的grafana.yaml文件进行部署文件链接grafana.yaml也可以通过grafana的配置页面添加prometheus数据源然后通过prometheus的SVC地址进行接入。

因为我们本地已经有grafana所以这里我们通过grafana的配置页面添加prometheus数据源然后通过prometheus的SVC地址进行接入。

2.6.2.1

http://12.80.144.38:9090(即上面的promethues对应的svc

ip)然后单击

中的grafana-dashboards-ob部分的json配置

监控展示如图

default-scheduler而在我们环境中需要使用自定义的调度器

解决方案

oceanbase.oceanbase.com/v1alpha1

kind:

oceanbase/oceanbase-cloud-native:4.2.3.1-101000032024061316podFields:schedulerName:

custom-scheduler

1使用ob-operator的service模式即为每个OBServer

Pod创建一个Service通过service来做静态IP的绑定从而解决IP变化的问题用法如下:

apiVersion:

oceanbase.oceanbase.com/v1alpha1

kind:

oceanbaseannotations:oceanbase.oceanbase.com/mode:

service

oceanbase/oceanbase-cloud-native:4.2.3.1-101000032024061316podFields:schedulerName:

8memory:

16Gi...但是链路上多一节service做静态IP的绑定会增加网络的复杂度而从生产角度和高可用shang因此我们采用了下面的方案。

2ob-operator更新到2.3.1该版本支持OVN网络插件并且能够做到Pod重建后IP不变。

Pod