作者   郭旭瑞·沃趣科技产品专家

出品   沃趣科技

｜序 言

标题中的DBA其实包含两层含义：Database Architect 与 Database Administrator，我在这里都简称DBA了。

作为Database Architect，我关注：

• 我要建设的数据库服务应该提供什么样的性能与容量，并且满足3~5年的业务增长？
• 为了达到我要的性能与容量，我应该匹配什么样的硬件？
• 资源的整合/分配/隔离。
• RTO & RPO

沃趣在企业级市场耕耘良久，在一些大的企业，IT系统通常以巨石型或者说是烟囱模式进行建设，系统的新建或改造都要经历需求提出、可行性研究、需求确认，经历这三个阶段，最终的硬件、架构选型才得以确定；接下来进入到招投标、商务洽谈、采购，这个时候硬件或者说基础设施才拿到手中；最后经过相应的安装、部署、测试才能最终上线运行。整个过程可能持续半年甚至更久。

对于Database Architect而言，往往对于下面这几个问题比较头痛：

• 巨石型IT架构往往服务于单个业务，但在规划初期，预留了3~5年甚至更长的性能、容量增长余地，较低的资源利用率造成了资源的严重浪费，企业总体拥有成本(TCO)不合理。
• 冗长的系统上线流程，造成系统在遭遇系统突发瓶颈时无法快速扩展，导致业务增长受限。
• 系统建设、选型、采购、上线所带来的大量重复性的工作耗费了大量的人力、物力，造成人的精力不能更多地放在业务创新上。

作为Database Administrator，我关注：

• 安装和部署
• 运维管理、变更
• 监控(性能、空间、日志)
• 可用性
• 数据安全(备份与容灾)

对于Database Administrator而言，往往对于下面这几个问题比较头痛：

• 安装部署复杂，从硬件组装到OS安装到数据库软件的部署
• 数据库手动管理，易出错
• 监控、备份脚本化，手动编写、维护、推送脚本。每天早、中、晚运行脚本，查看性能状态及日志信息，缺乏监控数据的集中式汇总归档与便捷地数据回溯，无法从多维度观察性能的历史变化趋势；备份通过定时任务运行，每天需要确认备份成功与否
• 数据库发生故障时，手动切换，人的反应时间严重影响业务中断时间
• 当然，预算充足的企业可能会采购一个个IaaS平台、监控平台、运维管理平台、高可用切换软件、备份平台等等，但无疑付出了高昂的成本，各平台累积起来学习成本巨大且互不关联

综上，数据库工作者希望有一个完美的数据库运行平台，涵盖如下几个方面的特性：

• 资源按需分配：数据库资源快速方便获取并合理分配，而且高度弹性可扩展
• 高性能高可用：提供高效、稳定的计算、存储资源及容错能力
• 方便易用：监控管理轻松、方便、快捷
• 数据持久安全：统一的备份及有效性校验，保障平台极端故障场景下数据库可恢复
• 成本合理：在合理的成本预算下，实现以上所有功能的有机结合

｜资源调度

巨石型架构是一种常见的IT架构，从需求的提出到资源就位，人力、时间成本巨大。资源独占一方面带来资源的严重浪费，另一方面也意味着资源在使用紧张时无法弹性扩展。

举个很简单的例子，某电商平台，双11交易量是平时的100倍。那么问题来了，系统是按照平时的交易量来做规划，还是按照双11的交易量来做规划？如果按照平时的交易量来规划，那么双11当天如何紧急扩容，过了双11，硬件资源如何处理？如果按照双11的交易量来规划，那就意味着平时要浪费99%的资源，这个成本从哪出？这是一个普遍存在的问题，信息化在企业中已经发展了很长时间了，大大小小系统都是以这种方式在构建，IT预算逐年增加，这看似一个难解的局。

云，通过资源整合，提供了一个按需分配、灵活扩展的资源管理方法。在巨石型架构中，一台服务器是最小的资源调度单元；但在云上，一台服务器的资源可以被灵活拆分，多台服务器的资源可以被动态整合。

在云上，一切随需随取，我不需要在一个系统创建初期就赋予它3~5年的性能余量；在系统业务发生波动甚至急剧增长时，云上都有足够弹性的资源作保障。还是刚才提到的场景，电商企业大大小小的系统如果部署在云上，在经历双11时，除电商核心业务之外的系统完全可以出让一部分的计算资源甚至停摆一天，保障电商核心业务的使用体验。在大规模计算领域，通过云的弹性特征进行离在线混合部署，是一种非常好的资源利用最大化的手段。

基于Kubernetes + Docker的QFusion 3.0数据库云平台很好地实现了云的这一特性，借助容器这一轻量级虚拟化技术甚至可以做到资源的高密度整合，相比基于Hypervisor的虚拟化技术，实现资源的更高效利用。

在Kubernetes上，容器是最小的资源分配单元。

下面这个配置就是一段申明式地在原生Kubernetes上创建一个业务应用的逻辑的一部分，你只需要把这个配置提交给Kubernetes，一个MySQL数据库实例就被创建出来了。“上帝说，要有光，于是便有了光”，Kubernetes上定义了一些基础的资源以及API，让一切都变成所见即所得，在Kubernetes上，这样的“优雅”的设计处处可见。

containers:
- name: db
image: mysql
resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

可以看到，这段配置创建了一个容器(其实是Kubernetes中Pod概念的一部分，Pod的概念在此不详述，大家理解为容器也不会错)，包含一个MySQL容器，并通过resources对容器的CPU、Memory等资源进行限定。当业务负载升高时，通过对resource进行修改，进行计算资源的扩展。同时，通过resource亦可以定义资源的优先级进行资源隔离和QoS。

对于kubernetes resource的介绍，等读完本文走传送门：  https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-types 

https://medium.com/google-cloud/quality-of-service-class-qos-in-kubernetes-bb76a89eb2c6

｜快速部署

聊到快速部署，Docker提供的镜像绝对是神一样的设计。 

有人举了很形象的例子，Java出现之前，不同OS平台上需要写几套不同的代码，JVM的出现实现了代码运行的平台无关性，“Write once,run anywhere”；而软件的部署也是依赖平台的，Docker engine与Docker镜像解决了软件部署的平台无关性，”Build once,run anywhere,Configure Once,run anything“。

在数据库的部署过程中，依赖包、内核参数、用户与组、目录等等一系列前置条件都需要DBA人工或脚本方式进行操作，大量重复性无意义的时间、精力消耗。docker的镜像便是将这所有的一切配置进行打包，一个镜像就是一个容易分发的即启即用的应用，与数据库结合后一个镜像就是一个迅速部署、即启即用的数据库。

｜高性能

各种基于虚拟机技术实现的IaaS平台开启了云计算时代，在这种平台上，虚拟机是资源调度的单元。每一个虚拟机都安装、运行一个Guest OS，糟糕的是，Guest OS本身会消耗很多CPU和内存。更糟糕的是，在虚拟化技术中，CPU、Memory、IO都是由Hypervisor软件来模拟的，这就意味着应用程序在使用这些资源时，在Hypervisor这一层会产生额外的资源开销。

容器作为下一代、轻量级虚拟化技术，容器中的应用是在宿主机的内核上运行的，它有着比只能通过Hypervisor访问宿主机资源的虚拟机有着更好的性能。CPU、Memory、IO都是以本地方式直接使用的。

下图分别是我们在虚拟化与容器环境中对IO延迟所做的对比：

基于相同的服务器与存储设备，虚拟化环境中的读延迟是容器环境的15倍(读者可以在自己的环境中进行验证)。

基于相同的服务器与存储设备，虚拟化环境中的写延迟甚至能达到容器环境的62倍(读者可以在自己的环境中进行验证)。

数据库需要对数据进行存储、提取、计算，既属于计算密集型负载，更属于IO密集型负载。数据库容器化可以显著的提高数据库实例的性能、部署密度和计算资源利用率。

数据库OLTP场景下的性能对比测试：

虚拟化：

容器化： 

基于相同的硬件资源，容器化数据库的QPS可以做到虚拟化环境的2.5倍，Latency降低50%以上。提供更高系统吞吐量的同时，保证更高的服务质量。

｜高可用

资源动态分配、经济高效是Kubernetes、Docker的原始属性，但他们并不能理解什么是数据库的高可用，这就是QFusion 3.0 RDS平台需要重点发力的地方。QFusion 3.0支持Oracle Primary + Standby的DataGuard架构的部署，支持MySQL Master + Slave主从复制读写分离架构的部署，支持数据路由中间件 + Sharding架构的部署，支持MGC/PXC/MGR强同步集群的部署，同时在部署方式上，既兼容计算、存储分离又兼容本地存储方式。

那么问题来了，任何一个Node、容器、Instance发生故障，都会不同程度上影响业务的连续性。这是沃趣科技数据库专家、Kubernetes与容器技术专家、开发专家需要通力合作去攻关的，让客户用上最好的数据库技术，是我们不懈的追求。

下图是计算、存储分离架构中，Kubernetes结合沃趣科技QCFS分布式存储实现的数据库实例快速failover的技术实现。

将有状态的数据下沉到存储层，Node故障Scheduler重新调度容器时，无需感知计算节点的存储介质，只需调度到满足计算资源要求的 Node，数据库实例启动时，只需在分布式文件系统挂载相应的 volume 即可。

分布式存储自带数据多副本冗余特性，但是在MGC/PXC/MGR架构中，数据库集群层已经解决了数据的多副本存放，所以，在这种情况下，使用分布式存储看起来并不是一个高效、经济的方案。从用户的角度出发，在这种架构中，我们认为本地存储是更优的方案，但当Node发生故障时，意味着我们要做更多的工作。这种种复杂场景，都是沃趣作为专业数据库产品服务厂商要下决心帮用户搞定的。

｜数据持久安全

当今经济社会，数据发挥着越来越大的重要性，企业依托数据本身，提供形形色色的服务，不仅如此，对数据的挖掘亦能创造未来价值。数据的重要性不言而喻，如何保证数据的安全可靠，企业对数据备份提出了越来越高的要求。

QFusion 3.0作为涵盖数据库全生命周期的RDS云平台，数据的备份与安全存放是产品设计考虑的重要一环，涵盖数据库的定时备份，备份有效性校验及数据恢复服务。

｜监控管理

不多说，直接上图。 

QFusion 3.0 RDS云平台高度的产品化将数据库全生命周期管理工作全部以web形式呈现给用户，轻松速学易上手，极大解放DBA的生产力。

｜小结

Kelsey Hightower是Google的Kubernetes布道师，曾经有不建议将database运行在Kubernetes上的言论。但沃趣科技投入了大量的人力、精力进行数据库容器化的落地工作，数据库专家、Kubernetes与容器技术专家、开发专家通力合作，不仅完成了技术难点的攻克，并以此为基础完成了QFusion 3.0 RDS全生命周期管理云平台的高度产品化。

可喜的是，在2月28日，云原生应用计算基金会 (Cloud Native Computing Foundation，以下简称CNCF) 宣布沃趣科技私有云RDS平台QFusion正式通过 “Kubernetes软件一致性认证”。

沃趣科技将持续回馈社区，积极参与CNCF组织的技术分享，并通过技术文章，给业界传播基于云原生架构的私有云RDS平台价值。未来，沃趣科技还将给社区贡献关于MySQL、Oracle各种集群架构的Docker Image，这些正是目前社区所紧缺的资源。

｜作者简介

郭旭瑞·沃趣科技产品专家

熟悉Oracle数据库内部机制，丰富的数据库及RAC集群层故障诊断、性能调优、OWI、数据库备份恢复及迁移经验。历任沃趣科技高级数据库工程师，负责华夏银行、华泰证券、中信证券、浙江电力、浙江移动等金融及企业级客户的数据库产品、架构实施方案、容灾方案、迁移方案设计及服务工作；任产品服务交付部门负责人，带领项目交付团队完成公司产品及服务交付职能；任数据库架构专家，负责私有云RDS等产品的数据库架构设计、技术预研及落地工作。