TDSQL 自动交付方案： 全球灵活部署，最快 9 分钟

自动化交付方案规划

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；数据节点的机器也是推荐物理机，同时在生产环境需要考虑容灾能力，因此推荐是三台机器以上。此外，需要一个高性能磁盘来保证回档和备份的效率；最后，访问链路上接入层是非常重要的一层，我们强烈推荐物理机来提高稳定性。

TDSQL 自动化交付特征与要求

在 TDSQL 真正交付过程中，为了保证交付质量，结合金融级场景的安全合规、高可用容灾考虑，我们沉淀出一些基本要求和特性：

网络：离线部署无外网依赖，机器互通；存储：支持单磁盘、多磁盘和 raid；冷备中心：支持 hdfs 和挂载式分布式存储(如 ceph)；机器分布：支持跨机架和跨机房上架服务器，支持多种机器分布模式下的高可用容灾；CPU：在国产化趋势下，目前机器 CPU 除了适配 x86，还包括 arm、power ，而且首要推荐以上其中一款；操作系统：适配支持 centos、ubuntu、以及包括国产化操作系统在内的诸多主流操作系统；

在交付过程中我们只要理清楚如何把鸡蛋放到对应的篮子里即可实现自动化交付：我们先选出篮子，一组物理机就是一个篮子，随之把一组的组件 DB 节点放到这个篮子里。

灵活交付

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

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

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

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

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

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

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

安全保障：秒级监测

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

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