产品解读 | GreatADM如何高效实现数据库资源池化部署?

前段时间，介绍了万里数据库的GreatADM数据库管理平台如何图形化部署MGR（详见文章：探索GreatADM：如何快速定义监控），有朋友想了解GreatADM是否支持资源池化管理、租户隔离、监控等功能。

今天，我们就来介绍一下GreatADM资源池的使用和部署操作，以及如何按项目隔离划分给不同的业务用户(租户)，使用时的一些注意事项等。

也许有人会问，为什么在私有化部署的管理平台中要增加一个资源池方案呢？

理论上，云化部署或容器管理环境下更合适，接下来笔者将结合实际项目解释它的适用场景以及这么做的原因。

项目背景

某金融行业项目中，用户实际部署投产了97套万里数据库GreatDB+GreatDBRouter三副本方案，其中每套使用3台物理主机。用户规划每20套部署一套图形化管理界面，主机用量共97套*3台+5套*2（管理平台采用双机高可用部署）=301台。

目前仍有一部分业务需要同等量的主机做交付部署，承接各单元业务，实际硬件和机房调度存在一定滞后性，但又需完成额定的数据库交付量。

在此背景下，用户希望2个月内拿出一个切实可行、可落地的方案。

需求分析与实现

项目需求设计期间分别讨论了如下3种可实现的方案：

• 方案1：调整实例部署方式，通过容器化方案实习，通过k8s做编排，定制GreatDB Operator交付数据库架构；

• 方案2：仍然选择物理主机部署，额外增加对数据库实例资源单元化管理，混合部署多实例，充分提升硬件利用效率；

• 方案3：调研第三方平台，是否可快速适配支持GreatDBRouter+GreatDB的高可用方案，以及可做已交付的数据库、主机统一管控的平台。

经过调研后初步分析：

针对实际用户集中式业务数据统计和分析，发现新增业务新建环境较多，多采用arm+kylin+GreatDB国产基础软硬件，数据量大多在160GB-800GB之间，超过500G的有数十套。新增新建业务近半年数据量稳定在300GB以内，并发值TPS/QPS相对平稳，峰值并未超过实际性能测试的一半。

初步规划原3台部署在一套高可用架构上，最少可部署3套，以充分利用服务器资源（服务器配置：cpu:36/72C、mem：256/512G、disk:2/4TB、network:10G），可保障数据库的高可用性和故障自动切换能力，且可根据业务负载对节点做横向、纵向的扩缩容管理、不同业务分给不同区域的管理人员维护。即使物理主机发生重启、掉电及其他非预期不可用的问题，也能保证数据库正常对外提供服务。

编辑

如何实现资源的管理和分配

由此，GreatADM基于物理主机的资源池化方案经多方讨论，在时间、成本、落地上均接近私有化交付的方案形式——即在第二种基础上增加实例的资源管理。

基于Linux系统的服务特性做物理主机的资源池化方案，将多台物理主机划为不同资源池，前端管理平台将资源池绑定不同"项目"做业务访问隔离，分配给不同的项目用户。通过平台的项目管理员和平台管理员来配置访问角色、权限，实现不同业务数据库的租户隔离访问。

接下来，我们完整看一下GreatADM从项目管理、角色配置、用户权限范围、资源池管理和数据库创建等方面的实际效果，如何最大化利用主机资源，做好数据库交付。

Demo环境配置cpu、mem、disk分别为：16c、16g、200g 。计划部署3套paxos高可用，且均可保证单台物理主机故障时数据库自动切换，保障业务系统正常运行。

01规划项目

以现有2个区域业务为例，项目名称定义为：北京海淀和天津河东，共用北京机房的3台物理主机。计划所有实例全部创建至北京项目中，通过天津管理员登录adm，验证是否可访问业务库，是否能起到隔离分隔的需求。

新创建2个项目名称如下，如果用户不创建项目，所有的主机都在default默认项目中。

编辑

02配置项目角色和权限

编辑

编辑权限：可细粒度地控制GreatADM的不同页面、功能模块及只读权限，还可编辑调整权限，限定不同级别角色的可见范围。如下：

编辑

完成项目角色和权限的分配：其中hedong角色权限受控，为运维人员日常使用。bjhd则为全局把控整个项目的超管角色，可全局查看天津河东和北京海淀，以及default默认项目的所有数据库实例和全平台的功能模块信息。

编辑

完成角色及权限分配后，再按照不同的业务部门申请账号，其中bjadmin为超管用户，关联所有项目。

编辑

tjadmin则为运维人员所用，只管理天津河东业务库。

编辑

用户账号信息如下：

编辑

03资源池的创建

1)、添加主机

添加物理机，选中导航菜单的【资源管理】选项，点击【添服务器】，如下图：

编辑

选项介绍：

1)【sudo免密用户】这里推荐使用root，因为需要一部分systemd服务扩展和操作系统目录权限分配；

2)【数据目录】表示默认数据库安装部署的二进制文件及实例数据的存储路径，建议挂载性能较好的磁盘；

3)【是否共享资源】按钮则表示此物理主机初始化时专门为创建资源池预分配，【开启】则在数据库物理主机交付时，自动屏蔽这部分服务器；

4)【管理用户】是指数据库部署之后，以普通操作系统用户来做管理。

添加完成之后备用，下一步准备配置资源池和要绑定的项目。
 

编辑

2)、创建资源池

选择主菜单【资源管理】--【资源池管理】--【创建资源池】--绑定为【私有】--【北京海淀】--【添加主机】
 

编辑

注意：要添加上报的主机，要求磁盘划分为独立的vg卷组或独立的pv物理盘，以便做磁盘的资源限额。如果临时测试时，主机忘记预留分配vg，可以用losetup方式，临时初始化一个块设备，创建为vg卷组，仅用于个人测试。

方法如下：

3台主机均在/根空间下创建名为disk的文件，将其初始化为块设备：

a、使用dd if=/dev/zero of=/disk1 bs=1024M count=100  创建100G文件空间  注意：需要确认磁盘空间是否充足

b、使用losetup  /dev/loop0  /disk1   模拟将disk1文件识别为块设备

c、使用 pvcreate /dev/loop0  将disk1文件创建为物理盘pv

d、使用vgcreate vg001   /dev/loop0 创建为“vg001”的卷组

[root@master ~]# losetup   #可看到对应临时模拟创建的VG

NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC

/dev/loop0         0      0         0  0 /disk1      0     512

[root@master ~]# vgdisplay    #查看vg信息，表示可用

编辑

查看资源池总量信息

编辑

查看到对应的3台主机已经全部加入资源池，资源池共计48核，46.38，磁盘300g，各台主机信息列表右侧展示。

接下来我们就可以按业务实际数据库运行需求分配资源了，分配的最小单元即为【规格模板】，表示可用多少cpu，内存和磁盘大小。

3)、自定义资源规格

在【资源管理】--【规格管理】路径下创建公共资源模板，默认情况GreatADM已经给出2个模板，可自行调整或默认使用。

同时支持对数据库特定的参数，按照实际模板大小，调整分配量，避免因资源分配不当引起实例无法初始化，或运行之后频繁OOM等情况。

编辑

模板信息

编辑

04 部署数据库

4)、上传软件包

部署数据库之前，我们需要先将数据库的二进制安装包上传到GreatADM，选择【软件包】--【上传】可从本地传到GreatADM中，或直接scp到安装GreatADM平台指定路径下，点击【同步软件包】更新后端adm的元数据库。

GreatADM支持万里安全数据库GreatDB的多个企业级方案，以及开源MySQL常见的复制架构。

这次我们计划分别用3个版本创建3套库，目的是为了明确展示后台进程，便于大家查看图文描述。软件版本为：GreatDB-6.0.1企业版、MySQL-8.0.32社区版、GreatSQL-8.0.32-24社区版本。

编辑

在导航栏中点击【数据库】--【创建数据库】--【资源隔离数据库】，4种架构可按需任选一种部署。本次我们暂时选择paxos，使用三节点部署组复制。

编辑

5)、数据库配置

选择paxos高可用，资源隔离数据库，配置项中，我们选择项目【北京海淀】，数据库软件包使用GreatDB-6.0.1，备份工具使用通用的xtrabackup，然后配置数据库初始账号等信息后，选择部署paxos的【资源规格】和节点数据量，paxos的最大节点数据库为9个，最小默认部署3个节点。

编辑

【高级调度】：其适用场景主要是按需求，人工指定主机部署，增加部分拥有可配置、可操作的灵活性，默认不做配置。默认情况下，GreatADM会根据资源池中的主机资源状态，综合数据库高可用架构，自动将节点分布在不同物理机上，增加数据库的容错。

编辑

执行标准的环境检查

编辑

忽略swap的次要提醒，直接确认即可。

编辑

6)、并行交付

接下来使用另外2个版本，交付同项目下的3套数据库。混合部署架构为paxos的组复制结构。并行交付任务中心状态如下：

编辑

完成部署的3套paxos组复制架构，命名如下：

编辑

3套paxos高可用结构都正常运行，这里贴出来一套拓扑，其他不再重复贴了。

编辑

7)、资源池用量

对应资源池的用量和实时状态负载，可以看到，3套数据库资源均匀分布在3台主机上。

编辑

详细查看具体主机的状态和属性信息，如下：可针对单台物理主机查看所包含的实例信息，资源用量信息等。

编辑

实际具体每台主机的实例信息，挂载的实例目录限额信息及实例后台进程信息：3套数据库，在当前节点的数据挂载目录下，以端口号区分，并且均在上报资源池时指定的VG中分配。
 

编辑

系统中注册的实例服务可用：systemctl  list-units |grep db-  获取到实例状态和注册信息。

编辑

纵向扩容方法

关于用户的纵向扩容诉求，特别是根据业务增长，需满足用户纵向扩展算力的诉求，增加cpu/mem或disk空间，且需满足灵活的单实例或多实例调整。

调整的方式有2种，第一种是图形化的GreatADM中调整，第二种是手动编辑调整注册服务中的配置参数，这里不推荐。

如下演示通过GreatADM调整：

编辑

纵向扩容节点计算资源，则选择更高规格的模板即可。如业务并发写时，数据库主节点的cpu和mem使用较高，则需分配较多计算资源，复制节点则可相对少分配或等量分配，磁盘的用量可根据实际用量随时动态调整。

编辑

第二种，通过直接修改systemd中配置的实例资源cpu、内存的配额信息，如CPUQuota、MemroyLimit，磁盘的大小限制则可通过lv的系统命令调整。

但这里直接使用操作系统命令修改方法，可能会造成adm无法准确获取到实例的资源信息，造成资源池的状态更新不及时，及新后续创建的数据库实例分布不平衡的情况，或因资源不足造成数据库无法正常初始化的情况。

用户隔离测试

用初始"配置项目角色和权限"创建的两个管理员用户，tjadmin和bjadmin来了解一下平台的业务隔离性，或者"租户"可见，可操作范围，尝试使用tjadmin访问"北京海淀"项目的数据库列表。

编辑

查看到项目绑定信息只有"天津河东"项目

编辑

对应的北京项目业务数据库信息，完全屏蔽

编辑

主机资源池等信息完全屏蔽

编辑

登录bjadmin超管账号查看下辖管理的3个项目是否可查看到数据库列表

编辑

三个项目的作用域可直观看到，切换不同的项目，可看到不同项目创建的业务数据库。

编辑

选择切换到【北京海淀】项目，则可看到对应的数据库列表

编辑

业务层从平台的访问也实现了隔离，从GreatADM控制台层面实现业务实例的前端访问隔离。

总结

本文从客户项目实际诉求出发，在硬件资源再受限情况下，依据用户诉求，给出如何充分发挥物理机性能实现数据库无差异化交付的方案。

根据用户对平台的期望，对于统一集中管理而言，既未引入新的产品增加运维复杂度和学习成本，也未改变用户对GreatADM平台的使用习惯。而是通过调整实例的注册服务配置，控制资源用量并快速落地。同时兼顾支持，具备将资源隔离方案平滑过渡到物理主机的能力。

此外，支持基于任一节点的物理备份恢复到新的物理机环境，并支持恢复时多种架构的变更，如将单机恢复为主从、双主、双主双从、GreatDBRouter方案，不涉及MGR字段数据类型限制的情况下，直接恢复为MGR等架构，为项目后期的灵活变更调整预留更多空间。

GreatADM数据库管理平台可在有限的硬件资源中，充分整合硬件统管调度，实现了成本可控、投入开发可控、时效可控的三赢方案，再次拓展了产品的场景覆盖度和综合能力。

此外，监控、细粒度告警等功能正在进一步改进提升中。除监控物理机、资源池的利用率外，精细粒度到每一规格模板层，可按需监控和配置告警的聚合、收敛及监控指标采集的数据准确性，规避误报和消息风暴工作。

编辑