从运管到云管，从离散走向集约

刚刚过去的火热七夕节，也恰巧是云计算诞生十周年纪念日。十年前的今天，Google创始人埃里克·施密特在公司年度战略大会上首次公开提出“Cloud Computing”后被业界认为是云计算概念的正式提出日。回想这十年，应该是云计算高速发展的第一个阶段。

过去十年，随着以主机虚拟化为基础技术发起点的IaaS云计算已经日趋成熟，无论企业构建一座私有云，还是租用公有云厂商的计算/存储/网络服务在技术上都已经不再有很大困难。计算层有ESXi、KVM，存储层有Server-SAN、Ceph，网络层有NSX、NFV，云资源管理层的vCloud、OpenStack，公有云资源的EC2、VPC等等，我们都可以任意选配适合的技术，加之一定的人力投入，搭建起来一套数据中心IaaS云。

我们用云逐渐解决了计算/存储/网络的问题。然而，当我们用IaaS的思想去面对我们的数据库时，我们总会疑惑重重，我们究竟是把数据库当做一种应用去对待，还是把她当做一种基础资源去对待，或者用平台即服务的思想去重新定义其在云上的意义？

数据库云管

由于数据库重要性毋庸置疑，在关系型数据库过去30年的发展过程中，已经形成了数据库的开发、运维、监控、备份、归档、容灾、审计、治理脱敏、同步复制等等一整套的管理使用需求和场景，再加上近年来NoSQL、MPP、key-value等技术的丰富，使得数据库更偏向业务化、平台化。

于是，不同的思想就决定了企业构建未来数据库基础架构和运维管理方式的不同方向，如果我们在虚机基础上构建数据库，那么我们对数据库本身仅仅当做一个个的应用去对待，然而，企业IT对类似数据库自动安装交付和灾难切换、数据级备份还是需要单独自行实现；如果我们作为用户角度只看到实例或者用户、甚至表空间的层面，向下托付，那么数据库可以是一种SaaS服务，可能需要配套实现计费绩效、安全等保、合规审计等功能；如果我们从异构、跨中心、灾难恢复、多活、开发测试发布无缝流转等角度去运维管理数据库，那么就需要平台化思维，将数据库平台化，作为一种PaaS去运管。

PaaS下的运管，就进入到云管的阶段，也就是DBaaS的阶段。

DBaaS不像IaaS层，无论从基础设施组件，还是到云资源管理平台，技术层面已经日进成熟。所以，数据库云管不是诗和远方的田野，还有眼前许多的实际问题要解决。

多年IT建设的历史原因，不同业务系统构建了不同的数据库系统。我们的数据库系统变成了：数据库多版本、补丁的维护升级不能统一管理；预警预测基本上是后知后觉；规模越来越庞大，人肉运维明显表现出人力资源不够。管理基本靠喊，维护基本都在救火。

● 随着时间的推移，各个时期建设的数据库都需打补丁或者进行升级，这样会对数据库整体带来非常大的维护成本和安全隐患。尤其是在一些不可中断的生产环境运行过程中，一些人为失误往往是致命的。甚至有些老系统可能不具备回退机制，那么就必须要求升级操作一步都不能错。

● 瞬息万变的市场导致业务需求更迭越来越快，以数据库为中心的系统，不可避免产生表结构等一些调整，而研发团队的知识更新跟不上、责任心不强，有可能使局面变得愈加复杂。

● 我们经常遇到企业用户，仅仅两位DBA，要去运维管理几百套的库和实例。无法通过高效的巡检模式为数据库做健康体检；无法通过敏捷的定位方法提前预警问题隐患；无法通过量化分析的方法展示数据库的历史现状。然而，工作的重心往往可能只在那几套最核心的生产库的运维，以及应对不断新建设的业务系统的数据库应用设计和架构设计上。以往的解决方法是通过人力外包、驻场服务的方式去解决。随之而来的是人力成本越来越大和每年的服务费用越来越吃紧的企业IT采购现状。这种方式恐怕就成了治标不治本的下下之策。

● 系统间（不同的团队、组织、部门各自的系统）的协议调用和接口时常需要做变动。数据的同步、复制、迁移等交互并不是一成不变的，数据库出于安全、合规隔离，性能优化而变化，可能导致延迟、吞吐等性能的变化，应用系统不会出现的一些问题，有可能因为运行环境的变化而出现，而数据库架构弹性、灵活度、容错机制要能够适应这种新的变化。

● 长期平稳运行的架构系统，往往由于时间累积原因，大部分可能都已变成了“易碎”系统。这里的“易碎”，并不是指架构不可靠、不稳定、不健壮，而是可能无法应对突发的、灾难的、此前从未遇到过的故障问题，导致一旦碰到一次就是致命的，长时间无法恢复生产。

2015年某工作日早上，某国内金融企业由于机房电路烧坏，造成该机房整楼层停电，所有运行在该楼层设备上的生产业务系统发生非计划性中断，然而很不幸的是，很多年前建设的灾备中心房容灾系统竟切换不过去。直至下午晚些十分才将问题解决。由于这次事故正好发生在业务高峰时段，给该金融企业造成了一笔不小的经济损失。

● 过去竖井状态下，业务逻辑高度依赖数据库，业务开发可能会将大量业务逻辑下沉到数据库层面去实现。造成很多历史遗留系统有数以百计的表、数以千计的存储过程，加重了运维人员的工作压力。例如，数据库优化的工作也成为了运维工作的一个重要部分。因为开发始终认为性能问题是个硬件问题，硬件问题理应由运维来解决。然后，高性能的场景，现在往往表现成突发性的。业务方只会喊“卡卡卡”、“慢慢慢”，而开发是不可能临时去解决这些问题的。所以架构只能是既要达到性能的弹性需要，又要满足横向扩展的需求。

业务方始终是焦虑的，支撑方始终是心累的。企业用户在呼唤用资源集中、自动化运维、集约化运营的思想。这也是我们提出云管时代的DBaaS的解决之道。云管不再是运维管理，而是提升为运营管理。

资源集中，从离散走向集约

资源集中要实现两点，首先是实现统一架构部署；然后是从管理角度实现对数据库的统一纳管；最后我们要实现自服务与自运营。

那么，如何做到这三点呢？

1，首先我们要做架构的统一部署

资源池基础架构物理上必须要是可横向扩展的，计算和存储分离，并且节点化。这样，在横向扩展的过程中可以对计算和存储做按需的灵活加减、升级或新老替换。

性能是可分层的，我们对不同TPS/QPS，或者执行时间要求的业务，根据冷/温/热盘的分层得到满足，实现阶梯归档。同时，高可靠性、容错、数据保护，通过架构自身的高冗余机制，得到合理解决。

建设规划的基础上，实现敏捷、弹性的自动化运维。

动态漂移、扩容缩容、自动化的巡检监控、容灾备份恢复。我们从互联网企业最大的经验取得之一，就是实现了如何只需要两个人（A/B）就能管理上千台主机的集群。在我们数据中心机柜数量越来越多，但人手只会越来越不够的情况下，我们迫切需要敏捷、弹性的自动化运维引入，帮助我们提高生产效率、解放生产力。

2，其次我们要做资源纳管

通过规划数据库基础资源池，从而先实现物理上的多库整合、数据集中。从场景上，高密度整合出开发、测试、仿真模拟、生产、容灾备份多个池组，根据不同业务的类型特点，还可以按需要进一步划分子池组，比如可按读写类型（只读/只写/混合读写）、负载均衡等来划分。

这样有利于节省总体硬件投资，做到计算资源合理利用，不造成浪费与空闲。同时也做到了商业数据库的授权数量的精简，甚至对同步复制链路及工具的精简。我们知道，许多商业数据库是按照CPU的CORE数目进行计费，如果对每个CPU的CORE利用不充分，就会陷入授权滥用的状况。

3，最后我们要实现自服务与自运营

我们这里所提到的“从离散走向集约”不仅是针对数据库系统的建设上，更指的是数据库的应用能力与管理水平。

所以，数据中心开始呼唤从运维的基础上衍生出运营与服务的理念。

云管时代，自运维、自运营、自服务三者层次明晰，又是有机一体的新体系结构。

我们构建自动化运营层，实现对数据库的自运营。在运营层面，我们要实现对生命周期管理（开通、暂停、释放回收）、模板管理、资源状态告警监控；对接大平台的管理API，例如：WorkFlow、绩效考核（计费）、OA、安全合规审计等。

● 多用户与安全隔离。根据数据库云的不同使用者，我们在自服务层面需要设计不同的使用权域划分，实现分级管理和安全域隔离。也就是所谓的多账户与分权分域问题。很多企业在这一块都有这样的安全域的划分问题，安全域划分之后，必然是资源部署的不同。

同时，还会涉及到的云的使用者、业务方或部门，可能包含如下几类视角：

A 用户中心视角，通常是数据库的申请者、使用者；

B 运维管理员视角，IT资源运维人员及其部门，可具有最高权限；

C 运营管理员视角，平台部门的业务人员；

D 战略、决策视角、规划视角，通常是企业CIO或CEO等管理层角色。

不同权域级别，不同子账户的视角，分别来实现组织架构、权域分设。

● WorkFlow。工作流，或者流程批复。这是任何一家企业都不可或缺的工作管理系统。不同的行业，同行业不同企业，甚至同企业不同区域公司都有各自不同的审批流程。这跟不同的组织架构是有关系的，各家的组织架构决定各家要有自己的工作流。数据库云管要实现与工作流的对接。

● 计费、计量与绩效。与工作流同样，不同用户都有自己的计费与绩效考核机制。有了云管，基础数据库资源就可以实现对使用部门的计数，可以表现为内/外部计费、计数量化、或者生成绩效。这就需要和原有的计费系统做打通，保持一致。

● 集成其他外围系统。ITIL、OA、财务、安全审计合规、数据仓库等，还有许多在不同行业不同企业，各种不同等级要求的业务系统需要对接。可能因人而异，需要做相应的集成。集成相对复杂，外围系统由不同厂商提供，就要跟不同的厂商、不同的系统去做集成。

从运管到云管

我们所面临的历史现状，是过去数据库的管理方式是散养式、孤立式的。如果我们通过自助式数据库方式（DBaaS）去实现用户空间申请与创建，就能支持各种架构模式，一键式自动化创建/部署/生成/发布；我们通过QoS资源控制去实现计算资源的用户之间安全隔离；通过分布式架构实现性能分层、数据多副本冗余、高可用、弹性伸缩；同时完善云化备份、统一视图监控与硬件自动化运维，并向ITIL、OA、计费绩效等或者大平台提供好友好的API，我们就可全面落地数据库云管。

从运管到云管，云所带来的，其实是这一系列问题的统筹解决方案与平台设计理念。让数据库架构变得弹性灵活，可按需敏捷交付；让数据库资源可通过数据量化；让数据库资源充分资产化，从而真正实现数据库从运管向云管的飞跃！