网易数据库运维平台化之路--管理精细化

网易DBA团队同时运维众多不同类型的数据库环境，面临的问题是既要保障数据库运维的高效可靠一致，又要针对每一种数据库进行定制的精细化管理。针对这个问题我们给出的解决之道就是构建一个开放式的数据库运维平台OWL：一方面将通用的操作流程标准化、自动化；另一方面将个性化的配置与流程做成模版与插件脚本。根据这一基本指导思想，可以逐步在数据库管理上既实现了高效自动化的基础需求，又保障了灵活性个性化，最终达到精细化管理的目标。

本文由作者授权发布，未经许可请勿转载。

作者：潘威，网易杭州研究院资深DBA

众所周知，标准化和模版化是管理大规模数据库集群的不二法门，可以显著的提高数据库运维的效率与可靠性。但是事务都是具有两面性的：网易的产品众多，涉及的业务类型覆盖电商、社交媒体、云计算、智慧企业、邮箱、IM等多种类型，这些业务对数据库的使用场景不尽相同，进而也对数据库本身的性能、高可用、服务形态、运维管理有不同的要求。当一支数据库团队同时运维这么多不同类型的数据库环境，既要保障运维的高效可靠可持续，又要针对每一种数据库进行定制的精细化管理，这是网易DBA团队不得不解决的问题。

针对这个问题，我们给出的解决之道就是构建一个开放式的数据库运维平台-OWL2.0：一方面将通用的操作流程标准化、自动化；另一方面将个性化的配置做成模版，特化的流程做成插件，从而保障系统的可扩展性。根据这一基本指导思想，可以逐步在数据库管理上既实现了高效自动化的基础需求，又保障了灵活性，最终达到精细化管理的目标。

OWL平台是网易杭州研究院DBA团队开发的面向DBA与开发同学的数据库运维平台，覆盖了数据库运维管理与自助查询等各类功能，OWL平台经过几年时间的发展已经成为网易数据库使用和运维的重要组成。网易杭研DBA团队出品本系列技术文章，将基于OWL平台介绍我们在数据库运维与自动化智能化方面的相关经验，与读者交流。本篇文章主要是围绕数据库运维的几个经典场景，介绍OWL平台在精细化管理方面的实践。

本文专有名词：OWL--数据库运维平台；哨兵--监控系统；夸父--工单系统；DDB--分布式数据库；NOS--对象存储系统。

 

OWL2.0数据运维平台架构图

1. 主动式元数据管理

对于数据库管理来说，元数据是基石，它决定了整个管理体系的深度与广度，无论是监控、自动化部署、巡检以及备份等等都离不开一个可靠稳定的数据库元数据系统。构建元数据是数据库精细管理的第一步，它的目标是完整、准确与实时，主要涉及采集、数据组织、系统互通等工作。不同的业务场景或者组织架构对应的元数据管理实现方式其实不尽相同。

当组织架构比较统一或者运维工具完全统一，比如数据库服务的部署可以收敛到一个入口时，元数据的采集以及对应与业务的认领可以前推到数据库交付阶段，即数据库部署时就将元数据采集录入完整，当数据库有切换或者分布式数据节点变更时，也调用元数据变更接口实时同步这种变化。这种元数据采集方式称之为被动式采集，它的优点是可以做到准确实时，但是可扩展性差，当采集目标有变更时，需要同步修改其他的部署或者高可用模块。另外就是要求数据库新增与变更的入口统一，这在复杂的业务与组织架构实践中并不容易做到。

另外一种元数据采集方式是主动式采集，也是网易DBA团队采用的方式，这种方式的整体采集思路如下：

1. 将数据库管理的目标抽象成几种类型（如MySQL、Redis、DDB 等）
2. 根据类型在线上所有DBA管辖范围内的服务器上进行规则匹配采集，如进程关键字或者本地服务配置文件等
3. 将新增或者变更的元数据清洗处理
4. 处理后的元数据录入到元数据CMDB系统

 

这种采集方式可以做到完整和准确，对于DB的部署或者变更路径没有要求，只要服务器存在符合规则的实例就可以抓取到。而且可扩展性强，当采集目标有新增变更时，只要变更对应的采集规则即可。 缺点是只能做到准实时，如果管理的服务器与db规模较大，需要一套专门的数据抓取与采集通道框架才能最大程度的减少元数据同步的延迟。我们目前采取的是本地agent执行采集脚本定时推送Kafka消息队列，然后利用插件式的handler进程按数据库类型处理消息录入元数据CMDB，可以做到分钟级别的延迟、满足线上的运维需要。

元数据管理的另外一个要点就是一定要与其他的运维系统互联互通，才能发挥出巨大的威力。一个最明显的例子就是与监控系统的互通，当检查到DB元数据有新增或者变更后，自动的建立对应的数据库监控，绑定对应的DBA或者开发。这样一方面可以提高工作效率，减少人工添加监控的重复劳动，另一方面可以极大的提升数据库监控覆盖的完整性，避免遗漏监控造成的线上事故。对于运维产品众多、线上环境复杂、db变更频繁的DBA团队尤其有用。

2. 可定制的数据库交付

数据库交付是数据库精细化管理的重要一环，一方面需要保障交付的数据库符合规范、服务器配置与数据库配置达到上线标准，另一方面又需要根据不同的业务场景与数据库主从拓扑方式定制特化的交付方式。网易的产品众多且变化频繁，几乎每天都有新DB部署或者扩容变更的需求，因此需要打造一个可定制的数据库部署交付平台，即保障效率简化重复劳动又可以根据特定的交付需求输出交付品。

我们把数据库的交付抽象成几个阶段：

• 部署环境配置
• 数据库配置
• 环境预检查
• 部署实施
• 结果检查

 

其中可定制的主要是数据库配置与部署实施两个阶段，以MySQL部署为例，MySQL的数据库配置主要包括redo log size、buffer pool、并行复制、线程池等，这些配置需要根据业务场景的不同进行定制化的配置。我们将数据库配置抽象成一个个的模版，将共用的标准化配置参数固化，特化的参数做成可配置的变量。OWL的数据库交付部署平台提供了几种常见的数据库配置模版，可以适配高并发、响应时间敏感的业务类型或者适配高吞吐密集写入的业务类型。除了平台提供的默认数据库配置模版，也允许DBA定制个性化的数据库配置模版以适应特化的数据库部署场景。

另外一个可以定制的地方是数据库的部署实施阶段，数据库部署实例我们也同样没有固化到平台代码里，而是把部署逻辑抽象成了可编辑的脚本外置于平台之上，有权限的运维开发或者DBA都可以修改部署逻辑。这样做的好处一是提高了可扩展性，当需要新增部署db类型时只需要开发对应的部署脚本即可，二是当原有部署逻辑需要变更适配新的环境或者db类型时，可以方便的修改上线，无需做平台级别的开发与发布。

OWL部署平台本质上的工作只是基于celery异步框架的在指定服务器运行脚本，并且根据标准的输入输出结果处理数据渲染页面。在运行部署实施脚本前需要根据前期平台设置的目标服务器、部署目录等信息参数抽象成标准化的传参传递给部署脚本，脚本运行后可以根据运行结果输出获取部署执行状态与结果，并且反馈给终端用户。这两步规范做好，平台框架就可以高效快捷的实现MySQL、Redis部署、镜像库搭建等数据库交付工作。

3. 可靠的数据库备份

备份也是数据库管理必不可少的组成部分，无论何种场景下备份要实现的目标其实很简单：

1. 覆盖完整
2. 备份成功率高

但是实现这一目标并不简单，多业务复杂非一致性的数据库部署环境、频繁的数据库主从切换与扩容隔离等运维操作都增加了一个可靠的备份系统的难度。与前面介绍的数据库管理理念相同，备份也体现着统一化与个性化的矛盾与中和：一方面需要备份的数据库在网络环境、部署方式、容量大小、数据安全级别等方面都具有差异性；另一方面又需要一个统一的基于元数据的自动化备份平台来保障整体的覆盖率与成功率。

 

具体实现上，我们将备份方式与备份的目标存储介质做了统一与自动化，统一与自动化是为了提高覆盖率与成功率，有赖于一个完整的元数据系统CMDB，备份平台可以明确的获取镜像实例的地址，采用经过线上验证安全可靠的备份方式进行定期的备份。比如对于MySQL的备份，我们统一采用了xtrabackup流备份方式，而没有开放太多如mysqldump等其他备份方式。 在备份的目标存储介质方面我们也进行了统一，选择对象存储作为备份的存储介质。早期的备份系统很多是通过流备将备份存储到一个或多个存储机中或者类似NFS的目标存储介质中，这种方式虽然可以做到让备份存储设备与数据库服务器在同一个内网环境甚至是同一个机架下，获得较好的备份速度，但是需要进行人工或者半自动的选择存储备份的数据盘目录，无法屏蔽存储细节。由于数据库的空间是一直在增长变化的，数据库需要备份的实例也是在变化的，当备份实例达到一定规模后，人为的配置这种备份存储目录会变的不可维护，大大的降低了备份的成功率。而对象存储对于用户来说近似于一个可以无限使用的存储池，用户无需关注存储细节，只要指定对象名就可以存取数据，天然的适用数据库备份的场景。 数据库备份也有个性化的需求存在，比如对于备份实例IO限速的需求、备份保留份数的要求可能都不尽相同，在保障基本备份方式的统一的基础上，系统也预留了一系列的可配置参数，满足不同业务的定制需求。

可靠的数据库备份的基本原则就是对于可能频繁变动的因素，尽量采用统一的成熟自动化方案覆盖，如备份目标实例新增与变更、备份空间大小申请等都使用自动化的方案解决；对于变动不大，与业务特性关联的特化需求留给DBA可配置的入口做个性化设置，如备份保留天数等。

4. 插件式的数据库巡检

数据库巡检主要用于发现系统的潜在风险，规范线上配置，争取在故障触发条件来临之前就排除掉异常。一般的数据库巡检分为日常巡检与活动巡检：日常巡检主要是将DBA常年积累的巡检项目定期的在线上进行筛查，发现异常后形成报表提供给负责DBA进行处理，日常巡检主要用于发现新增或者变化的DB实例的潜在风险。活动巡检指的是当某项活动临近或者业务访问行为发生变化时，需要针对性的对某个集群的数据库进行一次巡检、评估数据库是否能够满足业务需求，活动巡检主要用于数据库的性能容量指标发生变化时的风险评估。

无论是日常巡检还是活动巡检，我们都面临两个问题：

一是巡检项频繁变更，事实上数据库的巡检项目很多都是DBA团队根据日常中遇到事故异常不断积累的，随着我们对数据库的认识不断加深，数据库巡检的项目甚至类别都会不断的调整。

二是不同业务不桶数据库的巡检风险指标并不相同，比如对于IO延迟敏感，连接并发大的业务，服务器raid卡缓存策略要求必须是writeback，但是对于延迟要求不高的业务，或者数据可靠性要求高的业务，raid卡缓存策略可以设置为writethrough。

 

为了解决这两个问题，我们开发了一套插件式的数据库巡检框架，允许自定义巡检采集插件与巡检规则。巡检的主要流程是：巡检数据采集->巡检数据存储->巡检数据处理->巡检数据展示，与元数据的采集方法类似，数据库巡检也定义了一套通用的数据采集格式标准，开发可以自定义采集器实现逻辑与采集数据指标，由巡检框架在指定的服务器上执行。当采集数据的逻辑或者采集环境发生变化时，只需要修改独立的巡检采集脚本即可。此外在巡检数据处理阶段，也支持自定义模版，根据不同的业务场景与数据库服务特性，制定特化的巡检指标，从而满足个性化的风险排查与容量评估需求。比如网易云音乐和Lofter，可以根据自己不同的业务特性，为自己的项目制定不同的数据库参数巡检标准。从而得到符合自己业务特性的数据库风险巡检报告。

除了在数据采集与数据处理上支持插件化的扩容功能，我们在数据存储与数据展示层又做了抽象与统一，也就是无论是何种类型的巡检数据，在数据存储与数据展示页面上，都可以使用现有的存储与展示资源，简化了持续变更需求场景下的代码开发量，提高了系统整体的可扩展性与易用性。通过以上不同阶段个性化与统一标准化的选择，最终目标是实现保障开发效率、维护效率的前提下，针对不同业务的巡检需求实现精细化的管理。

 

网易数据库运维与自动化智能化系列文章近期计划包括：

• 管理精细化
• 自动化生命周期管理
• SQL管控

敬请期待。

 

作者简介

潘威，网易杭州研究院资深DBA，负责网易云计算数据库、对象存储NOS等项目的运维管理工作，具有多年的一线数据库运维经验与数据库管控平台开发经验，目前专注于运维平台构建、分布式数据库运维等领域。