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




