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
