Cloud 团队：让 TiDB 在云上跳舞 | PingCAP 招聘季

78 阅读 0 评论 52 点赞

我是靠谱客的博主落后心情，最近开发中收集的这篇文章主要介绍Cloud 团队：让 TiDB 在云上跳舞 | PingCAP 招聘季，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

TiDB 是 Cloud Native 的数据库，对于 TiDB 来说，如何用 Cloud 的思想和技术让 TiDB 在云上跳舞，是 Cloud 团队研究的重要课题，本期我司商业产品副总裁刘寅老师将为大家介绍 Cloud 团队，Enjoy~

TiDB 与 Cloud

通过前面的招聘职位解读系列文章，相信大家对开发 TiDB 的挑战有了更深入理解。水平弹性伸缩是 TiDB 最酷的特性之一，不同于传统的单机数据库，TiDB 管理的往往是成百上千的分布式存储节点、计算节点以及监控、日志相关组件，这对于 TiDB 的使用来说是非常大的挑战。因此，我们在开发 TiDB 之初，就将其定义为 Cloud Native 的数据库。我们意识到需要用 Cloud 的思想和技术，让 TiDB 用起来更加简单，开发者和用户才能够轻松 “玩转” TiDB。

Cloud Engineering Team

在 PingCAP 我们有一支专门的团队在做和 Cloud 相关的事情。这里的 Cloud 是一个比较泛泛的概念，它既包括公有云，也包含私有部署，凡是关于“如何以集群化和集中式来管理大规模的 TiDB 实例”的问题都是这个团队需要关心的事情。看到这里小伙伴们可能已经想到了容器和 Kubernetes。是的，容器是在 Cloud 上部署和管理的最佳实践，Cloud Team 的一个主要职责就是把 TiDB 容器化，并结合 TiDB 自身的特性实现集群自动化管理，包括并不限于：

一键部署集群
弹性扩缩容
数据库滚动升级
故障自治愈

上面几个 features 你可能看了并没有什么感觉，我展开说一下。

首先，一键部署不仅要支持像 AWS，GCP，Azure 这样全球顶级云供应商，也要支持国内 Aliyun 等主流的公有云。用户根据自身业务选择云提供商和可用区，甚至可能提出跨云的需求。国内的环境下，很多企业选择混合云的建设方式，因此也会提出 TiDB 要在私有数据中心部署，那么在数据库的一键部署之前我们要先搞定 Kubernetes 集群的一键部署。此外，我们还要考虑很多方面的问题，比如：如何跨可用区高可用，高性能本地盘支持，如何最大化资源利用率，统一监控等等。传统的基于 Ansible 管理的 TiDB 集群即使是熟手也需要 10-20 分钟，而在云上创建一个 TiDB 集群可能是秒级完成。

当应对计划内的业务增长，比如像双 11 这样特殊时间段，用户希望只提出需求，比如：所需的存储容量、QPS / TPS，剩下的交给程序自动完成 TiDB 的扩容。当业务高峰过后，还可以通过缩容把资源释放出来。分布式数据库是有状态的，特别是 TiKV 需要本地盘的支持，那么有状态服务的扩缩容需要尤其谨慎地管理 local volume 的生命周期，以及处理好服务间的依赖关系等。借助公有云提供的 Auto Scaling 能力，按需创建节点，只有在云上才能做到真正的弹性伸缩。

TiDB 的版本迭代速度还很快，线上升级是常态。用户当然期望有计划升级的 RTO/RPO 皆为零，在云上对 TiDB 升级必须把对用户的影响降到最小。这就需要在升级期间配合 TiDB 的 graceful shutdown 和 evict-leader-scheduler 机制，对节点依次进行升级。保证把对上层业务的影响降到最低，同时尽可能缩短升级的时间。

TiDB 利用 Raft 协议保证多副本之间的强一致，可以容忍单个节点，甚至单个可用区挂掉的情况下，不影响提供服务。在传统的运维方式下，一旦发生单点故障虽然不用立刻响应，但后继的节点恢复仍需人工介入，并根据实际情况来判断恢复副本的策略。另外，如需做跨区高可用部署也需要运维人员对 TiDB 原理有充分的理解，而基于 Cloud 这些理所应当是自动来完成。

Cloud Team 在做的事情

以上只是这个团队所解决领域中的一部分问题，接下来看看我们具体做的事情。

Kubernetes

Kubernetes（k8s）几乎已经是容器编排领域的事实标准，它更像一个集群上的操作系统。TiDB 的容器化依托于 k8s 强大的调度和资源管理能力也就成了很自然的事情。可以认为无论是公有云还是私有部署，只要基于标准的 k8s 就可以把 TiDB run 起来。

Cloud Team 必须充分的了解 k8s，不仅包括 k8s 的使用和运维，还要深入到源码理解其内部细节、帮忙贡献代码。k8s 本身是 GitHub 活跃度排名前几的项目，拥有庞大的社区和生态。我们积极的深度参与社区，因为解决有状态服务的调度是一个共性问题，我们既可以从社区找到更先进的思想和方法，也会把我们的成果回馈给社区。

K8s 最初是用于无状态应用部署管理的，所以长期以来一直只支持网络持久化存储，StatefulSet 设计之初也是以网络存储为基础，其对 Pod 处理的顺序保证在最近几个版本增加的 Local PV 已经显得有些捉襟见肘，一台机器挂掉后，对应 Pod 的 Local PV 数据可能就无法恢复，不像网络 PV 数据还在，可以直接从故障机器转移挂载到其它健康节点。如何对使用 Local PV 的有状态应用进行恢复，单纯靠 StatefulSet 是无法做到的。

K8s 虽然已经支持本地持久化存储 Local PV，但对于本地盘的管理还比较初级，要做到磁盘 IOPS 隔离，只能通过一个 PV 一块物理磁盘方式实现，没法动态分配，资源浪费比较严重，如果使用 bind mount 共享磁盘，则无法支持容量和 IOPS 隔离。而隔离性几乎是企业级必须具备的功能，如何解决这些问题需要我们与 k8s 社区一起共同探讨。

磁盘设备如果支持 IOPS 隔离，那 storage 本身除了容量大小之外又增加了 IOPS 这一属性，再加上本地磁盘本身不可移动特性，其调度将会变得异常复杂。

K8s 当前跨 Region 部署能力是借助于集群联邦（Federation）实现，但其功能比较弱而且有不少问题，如何解决跨地域部署实现真正意义上的分布式系统还需要社区大量努力，社区目前也正在设计讨论联邦第二版。

K8s 支持水平自动扩缩容（HPA）和垂直自动扩缩容（VPA），能够使集群资源达到更合理的利用，但是对于有状态应用，如何使自动扩缩容满足业务场景需求同时又不对业务造成较大波动，就不仅仅是拿监控的 CPU/Memory/Disk 几个指标就能完成的。

“Eating your own dog food” 是我们信奉的原则，在 PingCAP 内部的研发和测试资源，只提供唯一的管理方式，也就是 k8s。几乎所有的 DevOps 平台，内部系统，稳定性测试平台，都跑在 k8s 上，在 PingCAP 如果你需要一台虚拟机作为开发机是需要特批的。没错，我们 All in k8s。

TiDB Operator

TiDB Operator 是在 k8s 上运行 TiDB 的关键，它扩展了 k8s 在 TiDB 运维领域的专业知识。弹性伸缩、滚动升级、failover 等特性也主要是由 TiDB Operator 实现的。Operator 自身也是一个 k8s Deployment，扩展了 k8s 的调度器和控制器，而对 k8s 的代码完全没有侵入性。

我们基于 Operator 可以做很多有意思的事情，比如：

跨可用区调度问题，如何将 R 个数据副本的 N 个 tikv 节点均匀分布在 Z 个可用区，结合 pd 数据层面的调度策略，从而保证挂掉任一台机器，一个机柜，甚至整个可用区，都不会影响数据库服务。
当一个集群部署多套 TiDB 实例，如何利用 k8s 亲和与反亲和的特性提高混合部署的效率，实现资源利用率最大化。
如何扩展 k8s 调度器，实现基于本地盘的调度策略，对有状态的服务提供管理。
如何实现数据库的全量备份和增量备份，以及备份数据的管理。
如何利用 Admission Webhooks 机制实现更优雅的节点上下线。
如何更好的处理有状态服务的故障自动转移。

TiDB Operator 本身也是开源项目https://github.com/pingcap/tidb-operator，我们也计划把更多的特性加入进来。比如，CLI 工具，细粒度 API，甚至简单的 UI 界面，k8s 部署工具等等。也欢迎各位小伙伴对这个项目感兴趣，能参与进来。

DBaaS

上面是我们 DBaaS 产品的原型设计截图，这是我们目前还在开发中的项目，预计在 2019 年会做出一个版本出来。

DBaaS 即 Database-as-a-Service，是数据库在云上开箱即用的一个概念，是 Cloud Native 的最佳打开方式。具体来讲，TiDB DBaaS 是由 PingCAP 全托管，支持 multi-cloud 和 cross-cloud，实现了多租户多用户下的多实例管理，具备完整计费和预算控制功能的数据库云平台。用户只需要注册账号即可体验 TiDB 服务，根据业务选择对应的 Cloud 供应商和地理 Region。接下来只需要点点鼠标就可以快速创建具备多副本，跨可用区高可用的 TiDB 实例。TiDB 的节点数可以根据用户资源使用量和预设的预算来自动扩缩。用户通过 VPC Peering Connection 建立应用 VPC 与数据库 VPC 之间的安全通道，保证数据库的安全访问。用户可以看到数据库性能、用量、调度状态等基本的监控，更复杂的运维由我们后台统一管理，用户只关心如何使用的问题。

实现这样一套架构并不容易，不仅要考虑底层对接不同的 Cloud Provider，更重要的是要保障用户的数据安全和资源隔离，以及服务的可靠性（SLA）。同时，成本也是重要的因素，能够实现资源利用率最大化，以及让资源按需自动扩缩才能体现数据库上云的价值。还有一些特性目前还停留在想法阶段，比如同一个 TiDB 集群跨物理地域（跨 VPC）部署，实现在云上的全球级高可用，还有很多技术挑战等着你一起来实现。

测试

虽然把测试写在了最后，但实际上这是我们最重视的一个环节。测试的对象不仅包括 TiDB 和 Operator，还有 k8s。而分布式系统的测试需要应对无数种可能性的组合，在云上的环境更是错综复杂，靠人肉来测试是 impossible mission。分布式系统的测试秉承一切皆可以 scaling 的思想，通过写代码来实现大规模的自动化测试。我们另外一个团队开发的“薛定谔”平台，也是基于 k8s 和容器实现各种错误注入，模拟各种 Chaos 环境，用来专门测试分布式系统的稳定性。下一篇文章我们还会详细介绍“薛定谔”。