干货分享 | 数据库资源调度的实践

最新推荐文章于 2022-11-14 21:00:00 发布

阿里云技术

最新推荐文章于 2022-11-14 21:00:00 发布

阅读量311

点赞数

文章标签：运维服务器

原文链接：https://developer.aliyun.com/article/782791?utm_content=g_1000253885

版权

我是程序员专栏收录该内容

328 篇文章 5 订阅

订阅专栏

简介： 云上专属自主可控最省成本

作者：陈招尚（胜通）

一、自建数据库需要考虑的问题

自建数据库需要考虑的问题：

第一，搞定数据库高可用问题。

第二，提升数据库资源利用效率问题。

第三，资源瓶颈。提升利用效率的同时，解决资源瓶颈问题。

第四，运维幸福感。运维数据库需要解决运维幸福感问题。

第五，为公司节省成本。随着公司业务发展越来越强，对节省成本要求更多。

总结：DBA把数据库管理好，是基本岗位要求。“妆成有却无”，我们把妆画好了，但是别人却看不出来。我们数据库产品没有什么问题，并且每年为公司节约成本，对公司管理层来说，是DBA管理工作者的基本功。

但是数据库能否正常运行，受很多因素影响，有问题时DBA可能会背锅。因为应用瓶颈，大多用扩机器解决，但有的时候扩机器无法解决数据库问题。还有DBA人数和研发人数比例失调，一位DBA对应的服务有100位~200位研发人员。对支持业务与解决运维问题之间需要平衡，支持业务多一些，运维投入就少一些，DBA常常疲于支持业务与运维间平衡，两者相互制约。

自建数据库需要考虑的问题很多，在过去很长一段时间里面，经常面临各种选择问题。比方为了提升业务幸福感，如果晚上挂了启用延迟处理机制等。

二、阿里巴巴内部数据库的部署历史

阿里巴巴内部数据库的部署历史，10年前MySQL版本还比较低，没有大规模应用于大型系统中。

1）第一种部署很简单，如图所示：所有主部署全部在一台机器，所有备部署全部在一台机器。

在这种情况下，随着公司的业务高速发展，后端运维岗位投入、IT资本投入都比较大。从DBA团队角度来说，稳定性压倒一切，所以选择这种部署方式。比如部署三个实例，这三个实例同时提供服务，只要这台机器的利用率资源够用就可以满足。

那个年代在平时是没有问题的，但是在双11业务压力突然上涨的环境下，会有连接数问题：连接数很多，如果压力不够，对数据库响应时间会很长。

比如一台数据库实例，前面服务200台应用服务器，平时连到数据库只有5个连接数，正常情况下实例只有1000个，可提供1000个连接服务。如果在双11高压场景情况下，应用服务器从200台扩冲1000台，为了抗住压力，连接数会设到20~40，数据库系统里面的连接很可能会达到10000或者超过10000。

我们当时面临的情况是，应用数据库各个方面都没有异常，但是应用响应时间特别长。MySQL在当时5.1版本，业务压力增大的情况下，连接数是很大的问题。

第二个问题是：主机宕机问题。如果有一台主机挂了，主机内的三个实例全部需要切到新的一台机器上去。切换硬件相对的影响很大，三个实例可能包含公司1/3的业务，那么1/3的业务都会受到影响。为了减小这种影响，要求备库能够百分百支撑起这台主机挂掉的情况，所以主库和备库的配置需要保持一致，那么对备库的投入成本与对主库的投入成本也一样多。

2）第二种部署

因为业务发展太快，硬件达到指数级往上投入，公司要求DBA进行成本优化，如下图所示，实现主备交叉部署，主实例相对用到更多的资源，备实例用于复制备份场景，使用的资源会少一些。

这种部署下，我们面临的第一个问题是：部分超卖，堵运气。举例说明，比如主机部署了64核，感觉是部署了96核。DBA实行了部分超卖，这个时候就是堵运气。左边主机如果挂掉，两个主部署会全部切到右边的主机上面，左边实际达不到64核物理上CPU总数，这是第一个面临的问题。

第二个问题是读写分离。如果主备交叉部署时，还想要提升资源利用效率，自然会想到会将备部署利用起来，做读写分离，会把一些读请求放到部署上面，这种情况下，左侧的主机有流量，右侧的主机也有流量，利用率更高。当然这样做也有堵运气成分在，在大型促销场景下，需要把主备部署自动切换关掉，相信尖峰时刻机器不会挂掉，另外业务上把很多机器切开，影响面会比较小，所以当时以这种方式应对。

3）第三种部署

开始构建集群型的方式，兼顾成本与稳定性，如下图所示：

第一个提升是将不同的机器充分进行打散，引入现在还在用的内部系统叫移山系统，进行资源调度，根据监控每台机器的资源利用效率，及时触发条件，将整个集群里面的实例进行资源调度。相当于整体实例利用率水平保持在比较均衡的状态。

第二个提升是备库预热，如果突然主备切换，备库如果没有承担读会是冷启动，备库需要有一个预热的过程，否则如果流量很大，那么可能会出现备库被烫死的情况，对此我们做了备库预热。

第三个提升是读写分离的问题，我们也考虑到读流量。

4）第四种部署

重要系统和非重要系统交叉部署，如下图所示：

在前面三种模式下，核心系统和非核心系统分成两个集群处理，核心系统更会往稳定性部署，而非核心系统会更向成本优化角度部署。这时出现一个情况，就是我知道哪个系统是核心系统，哪个系统是非核心系统，但是如果出现非核心系统突然变成核心系统的情况，在认为的非核心系统里面咨询，非核心系统用到的资源会增强。为应对这种问题，我们增加了重要系统，锁定资源，不被争抢的功能，锁定资源不会增强。

非重要系统：大量混合部署，资源随时弹性，移山及时再平衡。比如做大型活动，流量上涨，可以根据资源CPU跟IOPS利用效率把机器上其他资源移走，实现资源利用效率整体平衡。

三、经验分享

经验1：主备交叉部署，一种伪超配的降成本方案

如下图所示，实际上一台机器用到了96核，但是主机上是64核，因为主资源备交叉部署，利用的效率并没有达到满负载。

收益：

CPU资源利用效率整体上达到70%。
连接资源被有效利用。
更低成本。

注意点：

HA机制要灵活，什么时候自动切，什么时候手动切。如尖峰时刻手动断开主备库的连接，以应对高流量咨询问题。
主机问题监控，核心资源打散。比如双11的时候，后端资源保障上都会资源打散，大家千万不要让主机满载运行，如果主机满载运行的话，一旦挂掉就会出现雪崩的情况，因为切到备库，备库也会挂掉，这是我们的一个经验。

经验2：应用分级，保障粒度差异化

应用分级，以不同的分级保障不同粒度差异化，比如分为一般性业务或重要性业务。一般性业务，可以利用交叉部署获得更多资源利用。重要性业务，更偏向稳定性方案，一定要有对外SLA保障。因为很多一般性业务依赖于中小型的业务，做应用分级，可以提升整体利用效率，提高可用性。如下图所示：

两种不同等级业务的数据库资源模式

两种不同等级业务的数据库资源模式，需要通过三个阶段的隔离实现:

MySQL实际上是吃内存性的，比如内存有64g基本上会把64g内存用完，超卖在内存这块是做不到的，所以开始从内存隔离，隔离过后，在一台机器上使用内存大家不会抢单。
如果在非重要的集群里面，业务流量突然上涨，非重要变成了重要，就把CPU绑定，实现 CPU的隔离，使其不会被争抢。
如果重要性上升到公司的核心业务，这时可能会把它独立出来，进行物理机隔离，进入第三个阶段。

经验3：两种抽象的资源部署方案

无论是数据库，还是应用部署，资源调度对最底层的分配方式只有两种：均衡分配与紧凑分配。

均衡性分配，如下图所示，离散型数据库实例分布，优先在更空的主机上继续分配实例，资源主机的利用率相对比较均衡，整体性能表现也会相对比较稳定。

紧凑性分配，如下图所示：堆叠型数据库实例分布，优先在更满的主机上继续分配实例，资源主机的利用率会更高，各主机性能表现不一，成本更优。

紧凑型和均衡型交叉应用场景

典型应用场景，比如一开始是紧凑性分配，更关注成本。大促的时候，增加了机器，变成均衡分配，实现资源均衡综合调度。大促做完之后，再回归到紧凑性分配，把机器空出来用到需要的地方。这种资源挪腾可以是自动化的，也可以人工手动方式进行挪腾。平时紧凑分配使资源利用率更高，成本更低，大促时使用均衡分配，稳定性更高。如下图所示：

经验4：资源弹性，消除业务流量评估焦虑

业务流量评估焦虑：

评估过程：业务指标–业务QPS/TPS–全链路压测–数据库准备。
标准上线流程：提前资源报备，详细部署监控，SQL审核，深夜值班观察表现。
三种结果：没抗住是因为没评估好，抗住了是应该的，资源利用率不高是因为没评估好。

如上图所示，业务方心目中的每一个数据库都非常重要，业务是他的全部。但是DBA实际操作时会区分出哪些是核心业务，如右图红色部分；哪些业务是非核心业务，那些业务运行一段时间就下线了等。

所以从DBA角度看，数据库地位实际上是有差异性的，为应对这种差异性，我们在内部专门做了混合性集群，这种模式下，DBA开始时不需要评估流量大小，可以直接放入集群中。如果业务突然涨上来，可以迅速地弹上去，然后立刻锁定CPU，使其不会再增强，保证一段时间内的重要性地位。如果业务持续增长，再把其转移到专门为其设置的集群里面，这个过程保证了数据库的稳定性和可用性。同时减少了因DBA评估错误出现的问题。