1、写在前面
Oracle中存在资源管理计划，对不同的用户实行资源管理，比如A用户主要是处理白天OLTP交易，夜间业务非常少；B用户主要在晚间处理批量业务，因此在白天的时候会给A提供充足的资源，晚间会给用户B充足的资源。MogDB中也有类似的功能，那就是资源负载管理。
通过下面的图可以看一下资源管理计划在MogDB是如何一步一步分配资源并关联工作的。
上图中蓝色部分是MogDB管理的，不可以进行调整，并且新建用户如果没有绑定控制组，会关联默认控制组中，在默认控制组中的用户是不进行限制的。
绿色部分属于用户管理的资源负载，从右往左看，Class控制组是MogDB管理资源负载的父节点，初始化数据库用户CGroups后自动创建的，父节点下创建子class控制组（Workload控制组），Workload控制组比如应用系统，在每个应用系统下创建两个用户，一个是OLTP用，一个OLAP用，OLTP和OLAP需要不同的资源分配，资源分配就要从组资源池（父租户）创建两个业务资源池（业务租户），这两个业务资源池就根据WorkLoad控制组中分配的资源比例与操作系统的CGroups进行绑定控制。数据库用户通过角色与父租户关联，与业务租户直接关联。
2、创建资源负载
一、测试规划
假设有2个应用系统，每个系统有2个用户，创建如下的资源管理对象。
应用系统 | Appliction_a | Application_b | ||
子Class控制组 | Class_a | Class_b | ||
workload控制组 | Work_a_1 | Work_a_2 | Work_b_1 | Work_b_2 |
组资源池 | Pool_a | Pool_b | ||
角色 | Role_a | Role_b | ||
业务资源池 | Pool_a_1 | Pool_a_2 | Pool_b_1 | Pool_b_2 |
用户 | User_a_1 | User_a_2 | User_b_1 | User_b_2 |
二、修改数据参数
#开启Control Group功能。 gs_guc reload -Z coordinator -Z datanode -N all -I all -c "enable_control_group=on" #开启基于资源池的资源负载管理功能。 gs_guc set -Z coordinator -Z datanode -N all -I all -c "use_workload_manager=on" #开启对数据库的常驻后备线程的控制。 gs_guc set -Z coordinator -Z datanode -N all -I all -c "enable_backend_control=on" #开启对数据库的常驻后备线程中的autoVacuumWorker线程的控制。 gs_guc set -Z coordinator -Z datanode -N all -I all -c "enable_vacuum_control=on" #重启数据库 gs_om -t stop && gs_om -t start |
三、创建控制组
所有节点都要执行，使用root用户为数据库使用的操作系统用户omm创建control groups
source /home/omm/.bashrc Export GAUSSHOME=/opt/mogdb/data/app gsGs_cgroup -U omm -c -H $GAUSSHOME |
切换到omm用户，查看cgroups的情况
su - omm
TOP GROUP部分：
GID=0 ROOT表示系统资源，资源份额按照1000来算，括号里面的50表示IO，不进行控制；
GID=1 Gaussdb:omm表示数据库程序占用系统的83%，也就是833个份额；其余的是为非数据库程序占用17%。
GID=2 Backend表示占用Gaussdb:omm的40%；
GID=3表示占用Gaussdb:omm的60%。
Backend Group部分：
DefaultBackend和Vacuum分别表示占用 GID=2的Backend资源份额。
Class Group部分：
Defaultclass 占用GID=3的class份额为20，我们新建的子class控制组就是从这个控制组分配资源，比如创建完gs_ssh -c "gs_cgroup -c -S class_a -s 40 " 以后，如下图展示：
创建子控制组需要在整个集群范围生效，因此需要使用gs_ssh执行gs_cgroup命令，需要配置执行命令的主机与其他节点之间的数据库安装用户omm的ssh互信。
#创建名称为“class_a”和“class_b”的子Class控制组，CPU资源配额分别为Class的40%和20% gs_ssh -c "gs_cgroup -c -S class_a -s 40 " gs_ssh -c "gs_cgroup -c -S class_b -s 20" #创建子Class控制组“class_a”下名称为“workload_a_1”和“workload_a_2”的Workload控制组，CPU资源配额分别为“class_a”控制组的20%和60%。 gs_ssh -c "gs_cgroup -c -S class_a -G work_a_1 -g 20 " gs_ssh -c "gs_cgroup -c -S class_a -G work_a_2 -g 60 " #创建子Class控制组“class_b”下名称为“workload_b_1”和“workload_b_2”的Workload控制组，CPU资源配额分别为“class_b”控制组的50%和40%。 gs_ssh -c "gs_cgroup -c -S class_b -G work_b_1 -g 50 " gs_ssh -c "gs_cgroup -c -S class_b -G work_b_2 -g 40 " |
标红的部分是新增的workload控制组，从ClsGID：21分配资源。整体是一个树形结构，可以使用gs_cgroup -P命令查看树形结构
四、创建资源池和业务资源池
#创建名称为“pool_a”和“pool_b”的组资源池（父租户），并关联子class控制组 MogDB=# CREATE RESOURCE POOL pool_a WITH (control_group='class_a',MEMORY_LIMIT=’100M’); MogDB=# CREATE RESOURCE POOL pool_b WITH (control_group='class_b'); #在组资源池（父租户）下创建相应的业务资源池（业务租户），并关联workload控制组 MogDB=# CREATE RESOURCE POOL pool_a_1 WITH (control_group='class_a:work_a_1'); MogDB=# CREATE RESOURCE POOL pool_a_2 WITH (control_group='class_a:work_a_2'); MogDB=# CREATE RESOURCE POOL pool_b_1 WITH (control_group='class_b:work_b_1'); MogDB=# CREATE RESOURCE POOL pool_b_2 WITH (control_group='class_b:work_b_2'); |
五、配置用户与业务资源组（业务租户）关联
#创建角色关联组资源池（父租户） CREATE ROLE Role_a RESOURCE POOL 'pool_a' NOLOGIN PASSWORD DISABLE; CREATE ROLE Role_b RESOURCE POOL 'pool_b' NOLOGIN PASSWORD DISABLE; #关联用户关联与业务资源池（业务租户） ALTER USER user_a_1 RESOURCE POOL 'Pool_a_1' IN GROUP 'role_a'; ALTER USER user_a_2 RESOURCE POOL 'Pool_a_1' IN GROUP 'role_a'; ALTER USER user_b_1 RESOURCE POOL 'Pool_b_1' IN GROUP 'role_b'; ALTER USER user_b_2 RESOURCE POOL 'Pool_b_1' IN GROUP 'role_b'; |
3、写在最后
关于官方手册有有一些疑问，在启用资源管理负载的时候提示enable_control_group、enable_backend_control、enable_vacuum_control参数不存在，另外官方文档中 gs_guc修改参数的时候-Z目前只支持datanode，但是在启用资源负载管理的时候却指定了-Z coordinator，因此此次测试部分内容没有测试成功，仅作为记录和学习使用。
MogDB不通过控制组对IO进行限制，主要对CPU配额进行控制，以及可以设置异常处理信息，资源池则可以对内存,最大并发度、od等进行控制。
控制组详细信息请参考官方文档：
https://docs.mogdb.io/zh/mogdb/v3.0/0-gs_cgroup#%E4%BD%BF%E7%94%A8%E7%A4%BA%E4%BE%8B
