一杯咖啡时间完成部署！TDSQL全球灵活部署实践

为帮助开发者更好地了解和学习分布式数据库技术，2020年3月-5月，腾讯云数据库、云加社区联合腾讯TEG数据库工作组特推出国产数据库专题线上技术沙龙，邀请数十位鹅厂资深数据库专家在线深入解读TDSQL、CDB/CynosDB、TBase三款鹅厂自研数据库的核心架构、技术实现原理和最佳实践等。本文将带来直播回顾第七篇，分享TDSQL的部署实践。

我们本次是围绕着TDSQL交付的话题分享三个方面内容。包括TDSQL曾经面临的交付要求和挑战，以及我们开发沉淀的自动化交付方案，最后更重要的是这套质量保障体系后续可以如何继续在交付后的用户的全生产流程中为用户提供全方位质量保障。

PartⅠ TDSQL交付要求和挑战：

快速、灵活、安全

1.1 复杂产品组件交付

首先我们想讲的是TDSQL的交付挑战，我们也是以三个方面去展开，第一个我们遇到的挑战是我们TDSQL产品架构所带来的特点：一是产品化不断完善带来的特点——组件多，包括拥有数据库内核，任务分发、冷备中心、平台告警、性能诊断等；二是组件之间相互依赖关系比较复杂。

首先从层次上把这些组件进行划分：赤兔、监控采集、OSS、metacluster、扁鹊、onlineddl等可以划分为一个角色，叫管理节点。对业务来说，实际访问数据库的过程是，先是负载均衡层，然后到SQL引擎层，而SQL引擎层会直接访问底层DB，DB上会部署Agent。图中左侧列这些叫做管理节点；右侧列如冷备中心、消息队列、多源同步等，一般划分为数据节点。而日志分析平台其实是一个其他模块，可划分为其他的节点。

这些节点之间的依赖关系比较复杂。比如管理节点，其主要负责元数据管理，元数据包括比如以监控采集模块为核心的监控数据、以任务分发系统为核心的任务节点数据；第二是DB模块，DB会和管理节点有一些交互——除了DB节点，还有其他的节点都会向管理节点发送监控信息；而管理节点也会下发任务，比如客户在前台进行的垂直扩容、水平扩容、主备切换等变更动作，也会到实际的DB进行交互；数据节点会向管理节点发送数据，和DB节点做一些交互……

所以其实各个组件之间的依赖关系比较复杂，这对于交付带来一定的难处。

1.2 多场景适应性交付

第二个挑战来自于TDSQL多个场景。

TDSQL多个场景主要来源于使用TDSQL的对象是不同的，包括个人、企业、第三方平台。不同的对象使用TDSQL的需求和场景也不同。个人使用可能更想低门槛快速上手产品。企业使用最主要是POC测试和生产场景，关注的是整个产品的性能和功能，包括高可用性、容灾能力、国产化适配等。

不同场景的需求如何高效满足？是要做多个分支去适配不同的场景，还是用一个分支去适配不同的场景？当然我们是用一个分支去适配不同的场景。

1.3 TDSQL交付质量保障：安全、合规、多层级扫描

第三个挑战是，由于时间的推移，负责TDSQL交付的人产生了变化。早期TDSQL由产品研发团队、DBA同学去现场给客户做交付。产品研发团队和DBA团队，大家都是一个团队，团队内由于长期的合作协同形成了标准和质量可靠。而随着TDSQL产品化做大做强，用户规模不断扩大以后，交付人员会发生变化。不同的交付实施方，他们的操作和使用如果不够标准化，则容易带来隐患，体现在几个方面：

第一个是安全。比如说环境的安全，我们知道数据库场景是对内存、CPU、硬盘、IO等能力都是要求比较高的场景，包括对TCP的内核参数优化等这些工作都是作为潜在风险来统一考虑。

第二个是监控。对整个集群、进程、机器的监控，以及自动拉起，即机器级别故障之后，快速恢复的能力，这些都要作为完善的体系来考虑。其他比如定时任务，包括定时清理一些日志，清理一些历史数据，否则磁盘就会撑满，这在生产的环境上也是风险很大。最后是如何保障整个集群的高可用性、容灾能力；如何杜绝潜在旧版本带来的隐患，检测这些版本的漏洞等方面，都是交付质量体系中需要解决的问题。

其实TDSQL交付质量服务和保障就是围绕着上述的各方面问题，实现由不同的实施人、实施方去交付TDSQL产品，都能保证TDSQL的投产质量。这是我们在做的事情。

PartⅡ TDSQL自动交付方案：

全球灵活部署，最快9分钟

针对上述的挑战，TDSQL沉淀出了一套TDSQL自动化交付方案。

2.1 自动化交付方案规划
这是TDSQL自动化交付方案架构图。

TDSQL是基于一个分支来实现多场景、复杂关系下的自动化交付的，其实也可以说是基于三个分支去做的——TDSQL内核包，当前有三个分支：基于CPU的多分支进行发布，当前支持X86、arm、power。TDSQL对客户的发布包中，一个包自动集成了不同CPU版本的TDSQL packet——以ansible组件为基础，加上了条件检测、操作系统调优、环境依赖的解决、安全规范、兼容性问题，是TDSQL标准发布包，可针对于客户不同的场景和不同的环境做适配。

TDSQL的组件分为四个角色，快速交付TDSQL集群，打个比方说就是把不同的鸡蛋放到不同的篮子里。鸡蛋是指这些组件；篮子就是我们准备的机器，可以是虚拟机，也可以是物理机。

首先个人体验的环境：个人体验环境更注重的是较低门槛，在这里我们只需要一台虚拟机的配置就可以达到目的。然后可以把管理节点、DB节点、数据节点和其他的节点都部署在这台机器上。当然在体验的环境下，数据节点和其他的节点这两个功能可以不进行部署。

测试环境：该环境下注重的是性能、功能。首先从管理节点来看，管理节点提供的是元数据的管理和任务的分发功能，要求的是稳定性和容灾能力。在测试环境可以稍微弱化这个要求，比如可以准备一台或者三台虚拟机、配置4C/8G普通磁盘；在测试环境下要做DB节点的话，要考虑到TDSQL的性能问题，这里推荐使用物理机；进行性能测试的时候要求一定是SSD盘，否则性能数据没有任何参考性——这也是由数据库的场景决定的，因为SSD和普通的磁盘，一方面主要表现在随机读写能力上的差距会比较大；数据节点和其他的节点方面，如果有一些客户对测试的功能要求没有那么强，就可以不部署这些节点的功能，而如果想体验完整的TDSQL的功能，则需要准备这些机器，以体验完整的TDSQL的功能；如要部署数据节点，可以选择一台机器或者三台虚拟机，以及准备较大容量的磁盘做数据节点；其他的节点，比如负载均衡和日志分析平台，TDSQL的负载均衡比较灵活，位于SQL引擎层上的上一层，这里推荐开源的LVS，当然也有很多客户会使用F5。最后，以上环境我们的推荐是部署两节点来实现容灾能力。总体而言，为了保证测试的性能，测试环境要求最多的是DB节点模块。

生产环境：生产环境中要求管理节点可以部署在三台或者五台虚拟机，但最好是跨三个机房，比如说“1+1+1”的模式或者“2+2+1”的模式，因为元数据集群是基于多数选举的机制来保障高可用，如果只有两个机房则会失去了本身容灾的意义，因此我们建议生产环境中部署三个机房；DB节点生产环境更推荐的是NVME接口的SSD，因为传统的SSD和NVME的SSD在接口性能上会有比较大的差距，而数量上推荐的是3*N台——事实上这个要去评估生产环境TDSQL集群的数据量，TDSQL是一个分布式数据库，数据量级可以根据用户机器数量实现水平拓展。

举个例子假设客户有3T数据，如果单台物理机是1T、一个set内做的是一主两备三个节点，我们此时需要三个set，三个set可以承担3T数据量，同时会有两个副本的冗余，DB节点的这些数就需要9台这样的机器，这三个set会组成group shard；数据节点的机器也是推荐物理机，同时在生产环境需要考虑容灾能力，因此推荐是三台机器以上。此外，需要一个高性能磁盘来保证回档和备份的效率；最后，访问链路上接入层是非常重要的一层，我们强烈推荐物理机来提高稳定性。

2.2 TDSQL自动化交付特征与要求

前文讲到了TDSQL不同的组件以及我们怎样去管理其中的层次逻辑。在TDSQL真正交付过程中，为了保证交付质量，结合金融级场景的安全合规、高可用容灾考虑，我们沉淀出一些基本要求和特性：

网络：离线部署无外网依赖，机器互通；
存储：支持单磁盘、多磁盘和raid；
冷备中心：支持hdfs和挂载式分布式存储(如ceph)；
机器分布：支持跨机架和跨机房上架服务器，支持多种机器分布模式下的高可用容灾；
CPU：在国产化趋势下，目前机器CPU除了适配x86，还包括arm、power ，而且首要推荐以上其中一款；
操作系统：适配支持centos、ubuntu、以及包括国产化操作系统在内的诸多主流操作系统；
上图右侧展示了简要分布关系，交付过程中我们只要理清楚如何把鸡蛋放到对应的篮子里即可实现自动化交付：我们先选出篮子，一组物理机就是一个篮子，随之把一组的组件DB节点放到这个篮子里。

2.2.1 灵活交付

当然这其中有很多细节，客户要做的，是自由决定模块的机器分布和集群规模，TDSQL可以通过模块之间的数量差异，自适应地做出单点方案和多节点高可用容灾方案。这个过程用户在操作上是无感知的。举个例子，比如TDSQL是支持HDFS作为冷备中心，如果HDFS选的是一个节点，系统会做一个HDFS的单点方案。如果是三节点的配置规划，它会自动感知到要做的是一个高可用容灾方案。HDFS用的高可用容灾方案是基于QJM的方式。

2.2.2 简单高效：整个部署过程最快仅需9分钟

做完部署规划，第二件事情是解决各个组件之间的一些关系，包括兼容性等问题。举个例子，如果部署的TDSQL环境是基于ARM国产服务器的操作系统的国产化环境。我们如何通过一个交付物料包去适配不同的环境？其实秘密就在这个配置文件里：

用户无需关注TDSQL较为复杂的各模块的互相依赖和配置管理问题，只需要根据实际，填写变量文件配置即可；
用户填写一个机器规格配置文件、一个变量配置文件，填写后可以适配操作系统和CPU实现一键自动化交付
操作简单用户可独立完成，自动化部署命令可重复执行，在北京信通院机构现场对TDSQL产品化的测试显示，整个部署过程最快仅需9分钟

2.2.3 适配与集成：国产化、全栈式

当前国产化已经成为一个趋势，TDSQL在国产化适配方面也做了很多工作，从底层的服务器到存储器、操作系统、CPU、行业软件、数据库软件等，都在相关部门指导下进行了与各个厂商合作实现从下层到上层全方位的国产化适配。在国产化的浪潮下，TDSQL作为一个腾讯自研分布式数据库，我们也是义不容辞的担当了国产化的责任。包括腾讯内部的操作系统tlinux，以及中标麒麟、银河麒麟、UOS等主流国产化操作系统，TDSQL都完成了适配。除了适配全系国产操作系统，TDSQL同时已相继完成对全系国产芯片，全系列国产服务器等的兼容适配工作。而在完成适配工作的同时，腾讯也提供了对应的技术服务，帮助行业用户更好地迁移到国产基础技术生态当中。这些是我们国产化方面的工作。

技术服务生态方面，TDSQL不仅可作为一个独立发布的产品，在TDSQL发展的历程中，也被其他很多平台厂商和合作伙伴接纳，包括腾讯内部的TCE、Tstack、MDB架构等。TCE是腾讯云金融级平台，TDSQL和TCE在部署方案、告警、用户权限等等各种维度和TCE进行了深度的集成，可为金融政务机构提供全方位的PaaS基础技术服务，在完成高性能的分布式架构转型升级的同时保障金融级稳定高可用。除了内部的平台，TDSQL许多合作伙伴的行业解决方案中也集成了TDSQL，把TDSQL的能力输入到他们自己的平台。

2.2.4 安全保障：秒级监测

TDSQL在发展中对交付场景做了许多优化：

条件检测：首先会自动对规划的TDSQL集群下的所有机器做前置检测，包括机器时间同步、时区一致、端口占用、系统默认sh、机器规格等做检；
环境优化：针对关系型数据库场景，对系统50处左右进行针对性调优，并解决一些基础的依赖；
机器秒级监控：大部分的监控平台都是基于分钟级的，对于金融级数据库这种敏感场景，分钟级的监控是不够的，所以我们针对这样的场景提供了秒级监控，包括针对机器的IO、CPU、网络、内存等多个维度。

2.3 多集群下的自动化和交付
前文讲的是TDSQL在单集群下的交付场景和交付细节，接下来介绍在多集群下的交付具体是怎样进行的。

“两地三中心”部署体系

“两地三中心”架构顾名思义：在一个城市有A、B两个机房，另一个城市有C机房，在第一个城市中TDSQL数据库实例采用同IDC异步、跨IDC强同步的方式，我们需要在第一个城市将四个数据节点部署在二个机房，其中主节点和一个备节点在一个机房，另外两个备节点在另一个机房。并且在第一个城市和第二个城市的数据库实例间，采用的是异步复制，保障金融城市级高可用容灾。

“两地四中心”部署体系

“两地四中心”的架构，是一个自动化切换的强同步架构，对任何数据中心及故障都能30秒内切换，并且数据零丢失，性能也稳定可靠，对业务和用户来说是实现更高的可用性和更低的成本。

PartⅢ TDSQL质量保障服务：

全生产流程自动化巡检

最后，最重要的是我们如何保证TDSQL的交付质量服务的质量。

TDSQL的交付质量通过一个自动化巡检的方案保证。TDSQL自动化巡检方案通过三个维度保障交付质量：

监控指标分析
第一个维度基于TDSQL现有的监控中心进行相关指标性的分析，包括当前时刻的指标分析和历史时刻的指标分析。当我们要在验证一个集群是否有问题的时候，往往除了要分析此时此刻的集群是否存在异常和告警、是否存在资源负载过重等情况，还需要分析历史性的问题，比如说在历史过去七天中各个指标的曲线如何。为什么要分析过去历史七天的指标曲线？举个简单的场景案例，例如一个场景在每天下午三点到五点是业务高峰期，在业务高峰期期间可能有很多业务的慢查询，甚至有一些慢查询带来的性能的问题。系统如何监控在历史某个时刻出现的问题？那么我们发起自动化巡检方案的时候，比如是上午8点钟，适逢业务低峰期，此时是发现不了问题的，所以我们需要对历史指标进行分析。

方案中具体分析的指标包括检测前台连通性、实例的复制方式、主备切换方式等。监控主要分为两个方面：第一是监控指标的采集、上报、搜集，这是监控中心负责。第二是对监控数据进行分析，并对认为异常的分析进行告警。分析和告警过程中会遵循一定的策略——怎样的监控数据才是异常、有必要告警的？当前TDSQL维护了一套告警模板，也给客户提供了可配置的、定制化的选项，客户可以根据自己的实际情况进行告警策略的修改；同时提供基于实践经验积累的告警策略对比，以防用户做出不合理的修改，暴露告警策略的潜在风险。

在这个维度，TDSQL多源同步等模块可以对数据同步情况进行监控，他们当前同步的稳定性、同步的性能如何，等其他就是各个模块的告警的监控指标。

集群环境扫描
第二个维度是对第一个维度的补充。第二个维度的分析是机器级的，不是通过采集的监控数据，是直接访问服务器后台，对机器级的IO、CPU、内存、磁盘、稳定性等进行检测。

除了机器级和进程级，我们还会进行实例级的定制化扫描，这个体现在实例体检模块——实例的体检就是TDSQL智能诊断分析平台“扁鹊”的接口，可以为实例提供从运营、开发、性能等各个指标的系统性分析。

集群级层面，我们会关注这个集群各个机器之间是否是同步、实例下元数据集群是否是有备份、备份是否是正常等。

自动化演练
在我们以各个维度去扫描当前集群没有问题的情况下，TDSQL还会从结果出发，对整个集群做一次P0级别的自动化演练，演练的场景就是我们正常运营和管理的场景，包括购买实例、创建用户、用户授权、创建库表，在这个库表上做一些表结构的变更、水平扩容、垂直的扩容、多重备机、慢查询入库、备份和回档等。最后系统会对购买的实例进行删除，实现对P0级别的场景进行闭环的自动化演练。

总结来说，TDSQL自动化巡检方案从指标级，到整个集群环境进行扫描，以及通过自动化演练这三个维度确保整个交付的集群安全、稳定、可靠、高可用。

除了技术上的保障方案，TDSQL同时沉淀了大量产品化工作，帮助用户快速、方便地使用分布式数据库。

我们也会对客户信息进行定期维护，首先对客户定期发起集群的巡检，通过这个巡检可以保证客户当前以及历史一段时间内环境是没有问题的。巡检主要进行功能性和容灾性的演练，通过自动的定期巡检，管理系统如果扫描到有建议客户要升级的版本，则会自动推送到客户代表，由客户代表推动客户升级。

最后，在客户日常运营、日常变更中，可能运营面临的大部分问题是怎么扩容、升级、处理告警？TDSQL对各个节点的扩容提供了自动化的扩容方案，可以一键扩容。同样升级也是提供了前台化一键操作的功能，既可以进行点对点升级，也可以进行整个集群的批量升级。TDSQL的高可用性一方面在于自身的弹性架构和容灾能力，以及数据强一致性。

可用性方面TDSQL提供了自动化告警处理方案，可实现自动化告警分析，并对部分告警自动处理，减少现网运营的工作量。

以上我们以交付为核心介绍了TDSQL在历史过程中遇到的几个交付上的挑战，和针对这些交付挑战，我们提出的自动化交付方案，以及最后对整个TDSQL标准化交付的质量和客户服务提供了一系列机制和能力方面的提升。

以上是今天的分享，谢谢大家！