TiDB v7.1.0】资源管控调研及评测

网友投稿 622 2023-11-27

多租户是什么

有语云,食在广州,玩在杭州,死在柳州,广东人除了天上飞的飞机不吃,地上走的坦克不吃,其它的什么都吃,广州作为省市,吃方面更为极致,它汇集了广府、潮汕、客家的各种特色和口味。一年一度的美食盛宴,广州为四方来客准备了万人宴席,但是万人宴席如何面对成万上亿的中国吃货呢?

【TiDB v7.1.0】资源管控调研及评测

一个笨方法是先入先出【FIFO】,通过先入者得到座席,吃完后先出去的方式,但是很快就出现问题 。有些客人是吃货长服务,他们点了烤乳猪潮汕毒药砂锅粥烧鹅囱鹅肠粉干炒牛河 ,结果只分配了他们5个座席,他们只能默默的吃,占住位置不释放。另外资源分配也有类似的问题,最后发生所有的座席满员,其它的人只能等待。可怜短服务需求的人,有些人不远***过来只为吃一粒牛肉丸,有些人只为了吃一个叉烧包。因为愚蠢程序的设计,结果等着等着,活生生饿死,造成系统大面积瘫痪。

解决问题之道 是加强资源调度管理,IT界引引入了多租户的管理方法。业界有两个渐为成熟的管理方法, 一个是capacity 调度方法 ,一个是fair调度方法,capacity 把资源按比例分配给各个队列,队列下面再划分二层队列,并添加严格的管理制度防止用户或队列独占资源,而fair则是按照公平的原则把资源分给各资源组,力保每一个用户都在进行中。

通俗的话表达,capacity Scheduler就是根据资源适配业务,按比例划分长服务50%、中服务30%、短服务20%,这样长服务得到更多资源吃饭,吃完就走,短服务因为是吃一碗糖水,占平台的资源不多,吃完就走。fair Scheduler则按标签权重划分划分,而且在算法上会关怀短服务以及那些优先高的任务,这样它们快速完成任务资源释放,后面平台可以服务更多的用户。

TiDB与***的多租户或多或少都借鉴capacity Schedulert和fair Schedulert的某些特性。

数据库的多租户

业界应用实践capacity Scheduler和fair Scheduler的产品有YARN,YARN是hadoop2推出来的资源管理调度框架,沉浸多年,技术上已经非常成熟,估计***的开发就是借鉴了很多YARN的特性,***开源后本身就有多租户功能,创建一段OB多租户示例如下

创建15个CPU,3G内存的资源单位unitfish obclient [oceanbase]> CREATE RESOURCE UNIT unitfish MAX_CPU 15, MEMORY_SIZE 3G, MAX_IOPS 1280,LOG_DISK_SIZE 10G, MIN_IOPS=1024; Query OK, 0 rows affected (0.015 sec) ​ 资源单位unitfish绑定资源池poolfish ​ obclient [oceanbase]> CREATE RESOURCE POOL poolfish UNIT = unitfish, UNIT_NUM = 1,ZONE_LIST = (zone1); Query OK, 0 rows affected (0.025 sec) ​ 资源池poolfish绑定租户tenantfish obclient [oceanbase]> create tenant tenantfish resource_pool_list=(poolfish), charset=utf8mb4, replica_num=3, zone_list(zone1), primary_zone=RANDOM, locality=F@zone1 set variables ob_compatibility_mode=mysql, ob_tcp_invited_nodes=%; Query OK, 0 rows affected (24.164 sec)

***的资源管控是三步走的过程。

第一步定义资源单元,资元单元声明里面最少可以占用多少资源,最多可以占用多少资源。

第二步声明资源池,指定资源单元 以及相关 单元数量,两者乘积就是资源池所有的性能。

第三步就是资源池绑定租户,并指定租户与数据副本的映射关系。

***资源管控策略意图很明显,第一步先声明一个细粒度的资源,足够小以后可以按照业务的需求个性化组装, 第二步可以组合成功的资源规格可以满足业务的需求,一般这是完成与业务绑定了。

***的资源管控策略与capacity Scheduler、fair Scheduler不一样, TiDB的创新方式也与***的不一样。

TiDB的资源管控核心理念是RU,Request Unit (RU) 是 TiDB 对 CPU、IO 等系统资源的统一抽象的单位, 目前包括 CPU、IOPS 和 IO 带宽三个指标。这三个指标的消耗会按照一定的比例统一到 RU 单位上。

区别于OB的细粒度管控方式,TiDB通过PRIORITY和BURSTABLE对资源争夺进行管控,如果发生资源恶性竞争,优先满足PRIORITY高的资源组,如果发生资源闲置,打上BURSTABLE的资源组允许当系统有过多的空闲资源,它可以占用更多的资源。

TiDB的资源组除了能够绑定租户,也能绑定会话,语句。不过,笔者认为最有特色的是根据实际负载估算容量

capacity Scheduler的资源管控策略基于集群硬件部署按照比例的方式笼切去切分,***的资源管控策略则是基于硬件部署的精确个数去划分,前提是必须知道服务器有多少个CPU,CPU是什么规格属性,才能灵活分配资源,属于硬件配置校准的方式。

现在TiDB的根据实际负载估算容量 可以忽略服务器软硬件的情况,通过业务负载知道预判该租户可以使用多少资源。技术原理与***的AI4DB的类似,***实现数据库自治运维管理,通过采集CPU、内存、硬盘的工作指标状态,保存在时序promethous里面,定期汇聚合并,通过dbmind分析数据库的运维参数,从而得出哪些参数需要调整优化。

与***不同,TiDB不需要额外安装组件、服务、时序数据库,这个比较省心。不过启用根据实际负载估算容量会占用TiDB额外的计算消耗。

实验环境

故事背景两个小弟是sysbech1【对应RG1】,sysbech2【对应RG2】,一个大佬是chbench1【对应RG3】。

以下创建三个资源组,RG1是100,RG2是500,RG3是2000,如下。

其中RG3是贵宾拥有最高优先权,而RG1和RG2则是同样级别,不过RG2的资源要RG1多。

选 用sysbench以及chbenchmark做压力性能的测试。

​ CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 100 ;   CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 500; CREATE RESOURCE GROUP IF NOT EXISTS rg3 RU_PER_SEC = 2000 PRIORITY = HIGH BURSTABLE; ​ # 创建完后rg1是100RU,优先权是medium,rg2是500RU,优先级是medium,而rg3是优先级高,允许资源空闲让资源组使用它的资源。 ​ ​ CREATE USER sysbench1@% IDENTIFIED BY 123456 RESOURCE GROUP rg1; CREATE USER sysbench2@% IDENTIFIED BY 123456 RESOURCE GROUP rg2; CREATE USER chbench1@% IDENTIFIED BY 123456 RESOURCE GROUP rg3; ​ # sysbench1绑定rg1 # sysbench2绑定rg2 # chbench1绑定rg3 ​ ​ grant all privileges on   chbenchmark.* to chbench1; grant all privileges on   chbenchmark.* to sysbench1; grant all privileges on   chbenchmark.* to sysbench2; ​

测试资源隔离

以sysbench做基准,分别以sysbench1和sysbench2执行相同一个任务,如下。期望 500RU的sysbench2会比100RU的sysbench1快。

sysbench   /usr/share/sysbench/oltp_read_only.lua --mysql-user=sysbench1 --mysql-password=123456 --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run ​ sysbench   /usr/share/sysbench/oltp_read_only.lua --mysql-user=sysbench2 --mysql-password=123456 --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run ​ sysbench1的结果如下 ​ [ 10s ] thds: 4 tps: 23.49 qps: 378.07 (r/w/o: 330.69/0.00/47.38) lat (ms,95%): 204.11 err/s: 0.00 reconn/s: 0.00 [ 20s ] thds: 4 tps: 19.90 qps: 319.62 (r/w/o: 279.82/0.00/39.80) lat (ms,95%): 211.60 err/s: 0.00 reconn/s: 0.00 [ 30s ] thds: 4 tps: 19.80 qps: 316.92 (r/w/o: 277.32/0.00/39.60) lat (ms,95%): 211.60 err/s: 0.00 reconn/s: 0.00 ​ ​ sysbecn2的结果如下 ​ [ 10s ] thds: 4 tps: 110.17 qps: 1766.70 (r/w/o: 1545.95/0.00/220.75) lat (ms,95%): 95.81 err/s: 0.00 reconn/s: 0.00 [ 20s ] thds: 4 tps: 100.80 qps: 1613.18 (r/w/o: 1411.57/0.00/201.61) lat (ms,95%): 42.61 err/s: 0.00 reconn/s: 0.00 [ 30s ] thds: 4 tps: 99.29 qps: 1587.17 (r/w/o: 1388.59/0.00/198.58) lat (ms,95%): 43.39 err/s: 0.00 reconn/s: 0.00

假如我把rg1设成 BURSTABLE,在系统空闲的时间rg1会汲取其它的资源,rg2设置调成200

CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 100 BURSTABLE; CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 200; ​ mysql> SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS; +---------+------------+----------+-----------+ | NAME    | RU_PER_SEC | PRIORITY | BURSTABLE | +---------+------------+----------+-----------+ | default | UNLIMITED  | MEDIUM   | YES       | | rg1     | 100        | MEDIUM   | YES       | | rg2     | 200        | MEDIUM   | NO        | +---------+------------+----------+-----------+ 3 rows in set (0.00 sec) ​ ​

结论,sysbench1是100,sysbench2是500,sysbench2平均值是sysbench1的5倍,满足预期目标。sysbench1是100,sysbench2是200,因为BURSTABLE,sysbench虽然说是100但是可以占用系统其它空闲资源,指数一直上升,而sysbech因为是200,一直在200之间徘徊。

测试资源抢夺

以sysbench做基准,先运行chbench1的oltp_write_only任务10分钟后,再陆续挂起sysbench1和sysbench2的oltp_read_only任务,最后以chbench1的身份再运行一个oltp_read_only任务

期望目标

chbench1的oltp_read_only任务中途插入,凭借PRIORITY = HIGH 可以获得较多的资源

chbench1的oltp_write_only任务结束后,因为资源释放,sysbench1和sysbench2的oltp_read_only任务的计算速度提升,chbench1的oltp_read_only任务也有所提升。

1.首先运行chbench1的oltp_write_only任务 sysbench   /usr/share/sysbench/oltp_write_only.lua --mysql-user=chbench1 --mysql-password=123456 --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run ​ 2.运行sysbench1的oltp_read_only任务 sysbench   /usr/share/sysbench/oltp_read_only.lua --mysql-user=sysbench1 --mysql-password=123456 --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run ​ 3.运行sysbench2的oltp_read_only任务 sysbench   /usr/share/sysbench/oltp_read_only.lua --mysql-user=sysbench2 --mysql-password=123456 --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run ​ ​ 4.运行chbench1的oltp_read_only任务 sysbench   /usr/share/sysbench/oltp_read_only.lua --mysql-user=chbench1 --mysql-password=123456 --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=10 --time=3000 --report-interval=10   run

chbench1的oltp_write_only开始任务运行后,系统约占200RU。10分钟后追加的sysbench1的oltp_read_only任务和sysbench2的oltp_read_only任务,chbench1的oltp_write_only任务依然是200RU,而sysbench1、sysbench2的系统RU分别是100和150。14:00之前的时间线,chbench1、sysbench1、sysbench2分别是200RU、100RU、150RU.

最后插入chbench1的oltp_read_only任务,chbench1升到500以上的RU,平均值接近550RU。而sysbench1和sysbench2并没有任何变化,依然是100和150左右徘徊。14:00到14:30的时间线,chbench1、sysbench1、sysbench2分别是500、100RU、150RU.

chbench1的oltp_write_only任务结束后,sysbench1仍然占系统的100RU,oltp_write_only资源释放后, 而sysbench2迅速从原来的150RU升到接500RU,而chbench1的oltp_read_only任务速度有了质量的提升,飙升到2500RU。14:30到14:45的时间线,chbench1、sysbench1、sysbench2分别是2500、100RU、500RU.

14:45后,sysbench1和sysbench2任务结束后,chbench1因为 的RU进一步急升。14:45之后的时间线,chbench1是3000RU

结论,chbench1、sysbench1、sysbench2三者竞争,优先满足chbench1的资源需求,sysbench2与chbench1竞夺,自己只占有150的RU【本身分配500RU】。 chbench1拥有优先权,本身的oltp_write_only任务只吃200RU的资源,继续给chbench1添加任务oltp_read_only,吃了将近500RU。此刻系统一共有4个长任务进行中,直到oltp_write_only结束,sysbench2终于拿该属于自己的500RU,chbench1也升到2500。 两个小弟吃完了,只剩下老大一人独吃,吃到了3000RU。

测试资源耗尽

以chbenchmark做基准,通过chbench1和sysbench对集群发起HTAP的压力测试,机器预先加载有tpc-h数据,期望平台会对客户提交的不合理要求截断,并提示报警。

​ /root/.tiup/components/bench/v1.12.0/tiup-bench ch --host 192.168.10.13 -Usysbench1 -p123456 -P4000 --warehouses 1 run -D chbenchmark -T 1000 -t 50 --time 60m ​ ​ ​ /root/.tiup/components/bench/v1.12.0/tiup-bench ch --host 192.168.10.13 -Uchbench1 -p123456 -P4000 --warehouses 2 run -D chbenchmark -T 10000 -t 50 --time 60m ​

sysbench1的执行过程中报错,提示failed Error 8252: Exceeded resource group quota limitation,整体系统依然在运行,没有对租户采取强硬措施处理。

chbench1的执行过程中没有报错,系统在持续满足它的资源需求,没有对租户采取强硬措施处理,直到系统不胜负荷,wait使用100%,swap使用100%。

结论,面对chbench1和sysbench1的不合理要求,系统没有把它强行掐断,结果恶性循环导致系统资源消耗殆尽。

通过负载校准

2379监控界面的负载校准必须要持续一段的压力才能出结果,技术原理它是按时序采集压测数据,根据对系统访问,算出平台应该调成多大RU负载。

笔者设了密集的频发的压力测试,经过系统计算后结果是8536RU,相对原来的硬件推荐的14886RU要少。选用8536RH比起14886RU 更合理。

8536 RU代表集群总资源个数,随着压测会不断 变化,负载校准是一个变量。 有经验的工程师,可以借鉴它调整整个集群的资源分配。但是笔者觉得这里美中不足,负载校准应该以时间版本的方式反映它多个时间阶段 不同的负荷,这样更有利于工程师做出精准的选择。

/root/.tiup/components/bench/v1.12.0/tiup-bench ch --host 192.168.10.13 -Uchbench1 -p123456 -P4000 --warehouses 2 run -D chbenchmark -T 10000 -t 50 --time 60m ​ ​ ​ ​ sysbench   /usr/share/sysbench/oltp_read_only.lua --mysql-user=sysbench1 --mysql-password=123456 --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run ​ sysbench   /usr/share/sysbench/oltp_read_only.lua --mysql-user=sysbench2 --mysql-password=123456 --mysql-host=192.168.10.13 --mysql-port=4000 --mysql-db=chbenchmark --tables=4 --table_size=1000 --threads=4 --time=3000 --report-interval=10   run

结论,负载校准相对硬件配置校准的极限负荷,表现更真实,更贴近资源的分配。

总结

多租户管理充分利用了资源,面对百万来宾,不需要摆百万宴席,也不需要假设性十万宴席,通过科学有效的现代化管理手段 ,万人宴席就好。

资源隔离是多租户必备的基本能力,每个租户分配的资源不一样,才能有序进行工作。TiDB满足不同租户的资源隔离,通过打标签让租户可以使用系统的空闲资源。

资源抢夺是多租户的核心处理能力,当出现竞争的时候,保障VIP食客先吃,低级别的用户也可以吃一部分。VIP食客户快速吃完抂,再腾资源出来,整体协调共进。

资源耗尽是多租户最想避免发生的事情,目前资源管控都是通过cgroup技术实现的,本质也是线程管控的。估计这里的测试chbechmark的线程并发有关系,里面有执行tpc-h的昂贵执行,据说目前不支持TIFLASH,跨越管控,最后发生资源耗尽。

通过负载校准是未来的技术趋势,与数据库AI有关,根据真实的业务负荷提供调整数据库建议参数,目前AI在TiDB的应用是租户资源调整,以后还会有很多增长空间。

笔者只知道国产数据库中,只有***有多租户功能,TiDB直至7.1才推出成熟的资源管控手段 ,来的迟,但是没有晚,亮点让人耳目一新,TiDB7.1的硬件配置校准继承传统的资源管控策略,按照工程师的熟悉习惯对服务器配置规格分配资源,同时也在负载校准提供了新的手段,通过人工智能识别数据库的最佳参数。

相对OB的大而周全,TiDB是小而精致。OB新建用户,都必须绑定租户,绑定租户需要三步走,三步走之前必须算好我应该划分多少个CPU、多少内存。 而TiDB假设你没有多租户的需求,那么你直接新建用户,不需要你强制绑定资源组。这样一对比,TiDB的多租户显得锦上添花了!

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:资源池化:多租户与数据库整合解决方案
下一篇:TICDC 数据同步至 MySQL初体验
相关文章