平安云原生数据库开发与实践

科技 2022-05-15 07:50:57
导读 TiDB作为一种开源的分布式关系数据库,具有良好的扩展性。结合云环境灵活的基础设施,可以充分发挥分布式数据库的优势。至于TiDB为什么一定

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

分享嘉宾:宋歌,高级研发人员;平安科技d工程师

简介:平安科技研发有限公司;d工程师,熟悉Kubernetes投稿人和TiDB投稿人,热爱开源,也是《TiDB in action》的作者之一。

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

事实上,状态本身并没有消失,而是下沉到底层数据库、对象存储和其他有状态应用程序中。那么,以TiDB为代表的有状态应用如何充分发挥云和Kubernetes的潜力,在“发扬光大”的过程中取得进一步的成功呢?平安科技总结的TiDB与Kubernetes的“爱恨关系”,或许能给更多企业的云原生实践带来借鉴!

分布式数据库TiDB技术综述

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

之所以推出TiDB,主要是为了支持平安集团重大业务活动——平安1.8财神节。在短短的10天高峰期,TiDB顺利通过了活动的推广。在活动中,TiDB表现出了出色的扩展性,可以支持快速扩容和收缩,实现高峰业务的覆盖。

众所周知,TiDB是开源的分布式NewSQL数据库服务,起源于Google发布的Spanner,支持OLTP和OLTP;同时TiDB在横向可扩展性上有非常强的横向可扩展性,这是天然架构的优势;TiDB支持分布式事务,与MySQL5.7协议高度兼容,是HTAP事务分析的混合应用。适用于海量数据存储、高并发、高吞吐量、高增长率的业务场景,可以将迁移成本降低到很低的水平。

TiDB为什么需要上云?

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

当时集群管理太多,运维效率满足不了用户的交付时间。但从故障自愈的角度来看,传统环境很难实现自动化。比如服务器挂了,其实是服务能力处于受损状态,需要DBA晚上起来看看怎么解决这个问题。如果晚上业务有高峰,就需要创建新的实例来扩容,这些都需要人工操作。

云自动化之后,给用户最直接的感受就是成本和效率。在传统环境下部署TiDB,是碎片化的,管理成本高。自动部署通过配置脚本完成,缺乏维护和自动管理整个集群状态的能力,资源调度困难,资源调度依赖于外部算法或框架。另外,传统环境下难以实现自愈和柔性服务;但上云后,数据库实例响应失败超过一定时间后,运营商会帮你自动拉起新节点,提供数据库服务故障自愈能力。从用户应用交付的角度来看,我们可能需要几天的时间来准备交付一组生产集群的资源,因为我们需要申请serve

在云化的过程中,我们使用了组件TiDB Operator,同时做了一些二次开发,在K8S集群上交付了一套TiDB容器化集群,可以将资源利用率提高到一个比较高的水平。传统环境下,资源需要人工管理,比如通过粗糙的资源算法,资源利用率比较低;上云后可以统一管理资源池,通过K8s的排列和调度,充分利用主机资源,使主机资源利用率大大提高。同时,云以容器化的方式部署。当一个节点出现故障时,它可以被控制器自动拉起,从而很好地实现了该节点的容灾,并且在一个节点挂机到一台主机上后,可以在其他节点或计算层维持副本的数量。

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

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时候联系我们修改或删除,多谢

最新文章