社区编辑申请
注册/登录
平安云原生数据库开发与实践
云计算 云原生
本文结合平安科技实际业务环境,具体介绍了开发与应用实践过程!总之,TiDB能超越传统数据库,让数据发挥更大价值,与容器相关的关键组件发挥了重要作用,而从云原生数据库设计的未来发展来看,还有更多可能性以及更大的探索空间!

本期分享嘉宾:平安科技资深研发工程师 宋歌

简介:平安科技研发工程师,熟悉Kubernetes contributor、TiDB contributor,热爱开源,同时也是《TiDB in action》作者之一。

摘要:TiDB作为开源分布式关系型数据库,具备良好的扩展性,结合云环境灵活的基础设施,可以充分发挥分布式数据库的优势。至于,为什么TiDB一定要上云?云原生数据库改造之前最大的挑战是什么?平安科技给出的答案是效率、成本和故障自愈需求!那么,在上云过程中,TiDB使用了哪些关键组件?如何在K8S上有效管理TiDB集群?如何充分利用云环境稳定运行TiDB?TiDB上云后如何提供更好的用户体验?本文结合平安科技实际业务环境,具体介绍了开发与应用实践过程!

云原生时代,以Kubernetes为代表的编排系统成为新应用的事实标准,甚至被称为是提升开发效率的“杀手锏”级应用,其无状态的弹性伸缩以及自动故障转移能力,无疑实现了生产力的又一次解放。

事实上,状态本身从未消失,而是下沉到底层的数据库、对象存储等有状态的应用上。那么,以TiDB为代表的有状态应用,如何在“负重前行”过程中,充分利用云以及Kubernetes的潜力,获得进一步的成功呢?平安科技总结出的关于TiDB与Kubernetes的“爱恨情仇”,或许能为更多企业的云原生实践带来参考和借鉴意义!

分布式数据库TiDB技术回顾

2018年,平安科技开始使用TiDB;2019年首次完成了线上业务部署。2019年以后,平安科技开始着手实现TiDB的上云。2021年,平安科技推出了UbiSQL云原生分布式数据库。

之所以要引入TiDB,主要是为了支持平安集团重大业务活动——平安1.8财神节。在短短10天活动高峰期,TiDB平稳地度过了活动大促。活动中,TiDB表现出卓越的延展性,可以支持快速扩缩容,实现业务峰值的覆盖。

众所周知,TiDB是一款开源分布式NewSQL数据库服务,源于谷歌发布的Spanner,支持OLTP和OLAP;同时,TiDB在横向扩展能力上,具有非常强的水平扩展能力,这是天然架构上的优势;TiDB支持分布式事务,高度兼容MySQL5.7协议,是HTAP交易分析混合型应用,适用于海量数据存储、高并发、高吞吐、高增速的业务场景,能使迁移成本降到极低。

为什么TiDB需要上云?

TiDB为什么要上云?运维成本是最大挑战!

当时,集群管理非常多,运维效率难以满足用户的交付时效。而从故障自愈的角度看,传统环境难以实现自动化。比如:当一个服务器挂掉以后,其实服务能力是受损的状态,需要DBA晚上爬起来去看这个问题怎么解决。如果业务晚上有高峰,还要新建一个实例去扩容,这些都需要去手动操作。

上云自动化以后,对用户来说最直接的感受就是成本和效率。在传统环境去部署TiDB的时候,比较碎片化,管理成本较高,通过配置脚本做自动化部署,缺少对整个集群状态的维护和自动管理能力,也很难做资源调度,并且资源调度依赖于外部的算法或者框架来做。另外,传统环境很难实现故障自愈、弹性服务;但是上云以后,数据库实例超过一定时间没有响应后,Operator会帮你把新的节点自动拉起来,提供数据库服务故障自愈能力。而从用户应用交付来看,我们原来从准备资源到到交付一套生产集群可能需要数天时间,因为需要申请服务器,还需要规划一些端口;而上云以后的交付时效是分钟级别,这是非常明显的用户体验上的提升。

基于上述几点因素,TiDB上云成为最佳选择!

在云化过程中,我们用了TiDB Operator这个组件,同时做了一些二次开发,在K8S集群上去交付一套TiDB容器化的集群,可以很好地将资源利用率提高到一个比较高的水平。在传统环境下,需要人工去管理资源,比如:通过粗糙的资源算法去管理,资源利用率比较低;而云化以后,可统一管理资源池,通过K8s编排和调度充分利用主机资源,使主机资源使用率得到大幅提升。同时,云上是使用容器化的方式去部署的,节点失效了以后可以由Controller自动拉起,很好地做到节点的容灾,确保节点在一台主机挂掉以后,在其他节点或者计算层可以维持副本数量。

尤为重要的是,TiDB上云把所有的TiDB集群做了集约化管理以后,可以很明显看到规模效应。分布式数据库集群组件很多,节点也很多,管理大量集群的时候,会导致信息管理成本、集群的管理成本、运维成本陡然上升,而把所有的集群进行集中化管理后会产生规模效应。TiDB上云以后,可以有效降低每套集群的边际管理成本。

换言之,管理的集群越多,每个节点所需要消耗的技术、人力成本就越少。同时,集约化管理还带来另一个好处,集团各公司用户可以共享技术红利。我们在做代码的提升时,发布了新的功能,比如:快速备份、基于时间点恢复、参数调优等,都可以在云上集约化管理方式下,把技术能力提供给被托管集群,最终效果就是降本增效。

如何在云上管理TiDB集群?

那么,我们如何在K8S集群上管理TiDB集群呢?大概构建了以下5个核心能力!

自动化部署。首先,使用TiDB Operator做了一些二次开发,实现了一些云上自动化的管理能力。比如:自动化交付,让用户在平安云界面上一键点击,创建集群,选择规格、实例,然后选择存储的空间大小,自动在后端创建TiDB集群,交付这个集群。

2.滚动升级。TiDB社区版的升级频率非常高,前几年,大概一个半月,就升级一个小版本。所以,在线上,我们也会有一些碎片化的小版本,在做滚动升级的时候, DBA可以在运维时间段,将集群做一个小版本的一个升级,目前可以做到一键滚动升级。

3.备份管理。基本做到了全量备份、增量备份、全量恢复、按时间点恢复(PITR)。

4. 参数管理。DBA可以在平安云页面上做参数配置,同时这个参数配置可以记录你的参数修改历史,给你一些默认参数;并且,根据不同的套餐给你一些默认的参数。你去修改调整以后,会记录谁什么时候修改的什么东西。并且,还有可以修改参数的时间段,设置控制参数生效规则,比如:不要在业务高峰期调整这个参数,然后由用户在页面上配置。

5. 用户管理。目前,主要针对集团内部子公司,对于数据库的用户管理有一些管理规范,结合内部系统的一些建设规范和审批流程,通过审批以后按照规范去创建用户的功能。

如何充分利用云环境稳定运行TiDB?

第一,容器网络。使用了K8S比较常见的Calico作为网络插件,相比Flannel的好处在于,可以在网络层面通过BGP的方式实现容器网络互连,避免overlay 模型隧道开销。另外,我们还在验证基于自研的K8S网络插件实现静态IP的网络方案。

第二,Load Balancer。数据库实例增加后,业务访问的时候就需要一个负载均衡,目前我们使用了K8S的Service 作为它的一个负载均衡;同时,在做灰度升级、滚动升级的时候,利用了负载均衡的标签选择能力,来做流量的控制。

第三,Service Discovery。基于DNS实现服务自动发现。所谓“服务发现”,在搭建PD的时候,要去配置一些静态节点。PD有几种集群搭建方式,一种是配置一个静态的集群,各节点相互知道其他节点IP。也可以基于服务发现机制,节点自动组建集群。采用服务发现的好处是,集群的规模比较灵活,比较容易做一个动态的集群,而非采用静态的方式。

第四,Backup&Restore。基于社区工具和对象存储实现备份恢复数据。之前备份恢复功能,基于MySQL、Lightning做TiDB层的数据备份和恢复,Lightning还涉及写KV。而Backup&Restore工具直接从KV层备份数据。由于是在每个TiKV节点上直接备份,所以还可以支持更高的并发和吞吐。并且避免计算层的SQL解析,恢复速度也比较快。目前来看,这个工具很快,我们集成了Backup&Restore工具。同时,可以基于云备份到对象存储,再从对象存储做数据恢复。

另外用户更多关心采用容器化以后,如何确保稳定性,如何在一个复杂的系统里使用一个新的技术,让整个系统变得更好而非更糟糕。

这里有几项相对来说比较智能化的技术:

Automatic Failover。相当于你的TiKV本身具备故障自愈能力,假设指定了三个副本,当Operator检测到有个副本挂掉了,超过30分钟没有恢复,他就会做一个故障的自愈,这是传统的Ansible没有的特性,是TiDB Operator独有的一个特性,这也是基于云带来的一个好处。假设有三个副本,有一个副本做了健康检查失败了,时间已经超过30分钟,就会自动恢复一个新的副本。不用管原来的副本了,这个时候依然保持弹性的服务能力。当然,等待故障节点恢复了以后,会有一个超出期望的4个副本,这个时候DBA再去根据故障情况去判断,要不要把新增的副本下线掉。当然,这个30分钟的限制,也是Operator自身的一个参数,可以配置多长时间以后Operator才能新建节点。

Auto-scaling,结合Prometheus、TiDB的Pod及K8S的HPA能力,基于Metrics的一些关键指标,实现实例节点的扩容。当我们发现节点、业务特别繁忙的时候,会基于资源池进行扩容。用户可以指定扩容规则,比如最大的扩容上线,扩容的等待时间,可以有在用户端的页面按需设置。同时,有扩容就会有缩容策略,比如:有一个冷却的时间,超过这个时间以后,关键指标没有达到缩容的最低值,管控组件就自动缩容,告诉这个进程结束了,数据库会终止接受新的会话,并把当前会话进行处理完成,不会出现事务长时间的等待,超过等待时间被清除的情况。

Self-Driving,数据库集群整体有波动、有异常,如何把异常平滑地处理掉?通过监控、日志等自动地分析和识别参数,可以通过Self-Driving来实现。

TiDB上云后如何获得更好的用户体验?

一般情况下,DBA比较习惯在Linux里面去维护数据库,比如查看日志,但在分布式系统里很麻烦,因为需要登录到各个节点去看不同的路径,所以上云之后我们就接入了一些云本身的能力,包括集中日志管理,我们内部叫日志云,把K8S Pod上的日志等集中收集上来,然后在另外的产品页面里去做一些关键字的过滤、分析等。

另外,就是统一的监控页面,方便DBA做更好的分析,帮助用户做数据库性能的分析。该能力可以基于云平台的产品页面去添加,包括可以扩缩容,调整购买规格,调整付费方式,比如预付费还是按量付费等。

最后,云原生数据库也是一个持续演进的过程,为了让应用性能达到最佳,我们在底层技术支撑方面也在做一些新的探索,进行持续发力。

1、 纵向扩缩容(VPA)。我们在2021年推出的UbiSQL分布式数据库,在这方面在做进一步的探索,比如:如何基于实例进行纵向扩缩容(VPA)。原来的CPU有限定,但业务突然遇到高峰期,如果是水平扩容,首先能力和时间有限;另外,水平扩容有些大的SQL在单个实例上还是有瓶颈。于是套餐的规格需要扩大,在应用不用重启的情况下,原地增加可用资源限制,然后再去做纵向的套餐规格的扩容。

2、 异构集群( Heterogeneous Cluster )。存储节点在扩缩容的时候,包括底层存储,每个TiKV对应的存储块不一样,我们在构建集群的时候,允许加入不同的内存、CPU还有存储磁盘的比例,整个TiKV允许他有不同磁盘每一个块的比例。同时,异构集群还有一个特性,就是可以隔离AP和TP的请求。比如:有个做数据中台的业务找过来,有些业务是交易型,希望打在某个节点上;另外,有些业务是分析型的,希望打在另外的计算节点上,并且这些节点资源规格是不一样的,如何把这块功能以产品化的形式提供给用户,也是我们目前在做的事情。

3、 数据库自治能力( Database Autonomy )。我们也在做一些数据库自治探索。首先,构建数据库治理体系,因为治理体系是数据库自治的关键路径,先有一个治理的过程,有数据、有治理能力。接下来,再根据数据和治理能力再去做自动化,包括基于数据的分析、参数的调优。

TiDB可以优化的参数非常多,加上分布式架构组件,两者结合起来调优过程就非常复杂。而数据库自治可以解决很多问题。首先是,参数调优,根据不同的环境和业务负载,可以把数据库的一些参数调整到相对较好的状态。因为交付的集群都是默认的参数,这些参数要么是基于专家模型,专家觉得这个套餐能面向80%的业务,都在用这个参数,那就用这样的。但是,集群交付了以后,部分参数可以根据实际业务负载特性进行适当调整。我们通过数据库自治可以把参数调优变成一个自动化的过程。

然后是,积累下来的慢日志数据如何去优化?过去,很多日志数据都是基于人工的经验去做分析,我们希望把慢日志的分析能力自动化。现在,这些能力都依赖于所使用的基础设施,先把所有慢日志采集下来,然后再根据专家模型转化成自动化过程。

4、使用新型硬件优化KV存储(KVSSD)。将Rocksdb集成到SSD硬件中,从而直接使用硬件KV接口能力,上层应用原来需要通过Rocksdb访问SSD硬件。而现在硬件厂商直接就把KV能力集成到硬件中,类似于存算一体的硬件,可以显著提升SSD的KV读写性能。

总之,TiDB能超越传统数据库,让数据发挥更大价值,与容器相关的关键组件发挥了重要作用,而从云原生数据库设计的未来发展来看,还有更多可能性以及更大的探索空间!

责任编辑:未丽燕 来源: IT168网站
相关推荐

2022-05-11 14:48:33

腾讯云寿险民生保险

2022-05-09 11:57:39

云原生实践安全

2022-05-17 13:40:21

云原生混部开源

2022-05-06 09:40:48

智能云原生云原生人工智能

2022-05-01 12:19:33

云原生公有云云计算

2022-04-19 14:41:29

Oracle数据库SQL

2022-04-06 10:40:32

云原生容器微服务

2022-04-21 10:01:48

VMware

2022-05-17 15:51:32

数据中心运维能力基础设施

2022-05-24 14:26:11

云原生数据库云架构

2022-03-21 16:22:45

云原生火山引擎IDC

2022-05-16 13:37:12

Sysrv僵尸网络微软

2022-04-06 08:14:49

云原生混部系统开源

2022-04-12 15:54:12

阿里云云原生开源

2022-05-11 15:08:52

驱动开发系统移植

2022-05-03 22:25:57

Python浏览器语言

2022-04-19 16:16:35

DevOps云原生容器

2022-04-01 12:23:03

云原生云安全

2022-05-06 10:58:55

数据库智能诊断

2022-05-16 10:36:08

GitHub开源项目

同话题下的热门内容

如葑:阿里云原生网关Envoy Gateway实践运维入坑必看:Kubernetes平台架构解读云原生下一步的发展方向是什么?一起聊聊什么是云原生技术多集群Kubernetes管理和访问云安全你需要问的九个核心问题打破大型机习惯:银行考虑云未来如何避免淹没在云原生可观测性数据中

编辑推荐

Service Mesh真的是云原生应用的绝配吗云原生桌面:虚拟桌面的解构与重新定义解密云原生---看企业云的未来云原生技术及其未来发展趋势展望如何评估云原生NFV中的容器化VNF部署
我收藏的内容
点赞
收藏

51CTO技术栈公众号