小O君
作者小O君2022-09-08 15:52
品牌运营, 北京奥星贝斯科技有限公司

为什么资源隔离对HTAP至关重要?

字数 8344阅读 519评论 0赞 0

此前,通过 《向量化引擎对HTAP的价值与技术思考》 一文,我们分享了 OceanBase 怎样看待向量化引擎技术,并介绍了用它解决复杂查询场景的技术思路。

HTAP 的本意是把 OLTP(事务处理)和 OLAP(分析处理)放在一个系统上更好地运行,帮助客户开展实时业务决策,降低运营成本并提升创新效率。 因为 OLTP 、OLAP 使用资源(CPU、内存、IO 等)的方式不同,同时运行时容易产生资源干扰。 如何将二者的相互影响降到最小,成为实现 HTAP 的关键,也是本篇文章中资源隔离技术要解决的问题。

我们认为真正的 HTAP 需要完备的资源隔离,数据库需要提供逻辑隔离能力,与物理资源隔离形成互补,帮助用户根据实际业务场景进行调整。 需要极致隔离的核心业务采用物理资源隔离,对成本敏感的长尾业务采用逻辑资源隔离。 本篇文章将分享 OceanBase 对资源隔离技术的思考,阐述为什么资源隔离技术是实现 HTAP 的必要前提,以及我们如何应对资源隔离的实施挑战等:

  • HTAP 为什么需要资源隔离;
  • 如何实现适合 HTAP 的资源隔离;
  • OceanBase 资源隔离的实现效果。

HTAP为什么需要资源隔离?

资源隔离是 HTAP 的立足根本

为了说明资源隔离的重要性,我们可以把数据库与操作系统进行比较:这两者的共同点是复杂性,而复杂性来源于两方面:一是功能的开放,二是对性价比的极致追求。功能的开放意味着负载不可控,如一个用户进程可以做任何事,一条 SQL 也可以做任何事;追求性价比则是因为基础软件用户量大,优化节省每一点资源都有重要意义。 而追求性价比有很多方法,其中最直接的就是资源隔离技术。

经过数十年的发展,当前的操作系统都已具备支持多用户,支持 Docker(虚拟化应用容器)的能力,基于 Docker 的 Kubernetes 已经成为业务部署的事实标准。而数据库也有多租户和混合负载的场景需求,比如很多业务把历史库和在线库分开,在历史库上执行分析,不仅增加了运维复杂性,也导致 AP 的实时性不够,无法在有限的硬件资源下实现 TP 和 AP 的动态平衡,未来随着数据库的部署实例继续增加,解决这一问题的价值收益会越来越明显。

资源隔离的需求本质来自于负载的差异分组,只要能分组,自然就产生了某种隔离的需求。 负载的分组:如备份任务和前台 SQL 任务,两者存在时效性的差异,OLTP 和 OLAP 对资源的使用方式不同,也会产生分组。只要一个软件系统要对服务的对象作区别对待,那就自然会产生分组和 QoS(Quality of Service,服务质量)的概念,也就有了资源隔离的需求。

资源隔离对数据库稳定运行至关重要。这有两种典型情况: 一是为数据库内部重要的任务预留资源,避免出现用户负载高导致数据库自身垮掉的情况;另一种是用户原来就有 QoS 要求不同的业务混在一个库里, 比如实时性高的 OLTP 业务,加上少量的重要性低一些的后台任务,如果用户愿意把这些信息告诉 DB ,数据库就可以更稳定地运行。

第二种情况的典型例子就是 OLAP 和 OLTP 两种负载的隔离。传统数据库为了避免 OLTP 和 OLAP 业务间产生干扰,需要配置较多硬件资源分配给不同业务,这样就会出现资源利用率低的现象。我们可以通过引入 consolidation(数据整合)的概念来解决这一问题,consolidation 通过把原有的多套数据库聚合到一个物理库,可以在减少硬件成本的同时降低运维复杂性。

从 OLTP 和 OLAP 两个库进化到 HTAP 一个库,这一进化过程就可以理解为 consolidation 。我们知道操作系统早已实现多用户和 Docker 的能力,数据库是否也会随着技术发展出现共享物力资源的需求呢?我们认为,随着技术进步和数据库部署规模继续变大,逻辑资源隔离的应用场景会越来越多。同时,现实中原本就有不少用户在一个库中既服务 OLTP 负载,也执行一些简单的 OLAP,只是受限于 OLAP 和资源隔离的的能力,限制较多。 比如一个电商的老板想知道当天卖得最好的商品是什么。那就需要在在线库上执行分析,但主流数据库缺少资源隔离能力,分析类 SQL 可能影响在线交易,为了保证在线交易的稳定性,就需要对数据库扩容,用更多的物理资源换业务稳定性,即使这样,也需要对分析类 SQL 做严格 review,防止这些 SQL 无限制占用资源。

物理&逻辑隔离,哪个是更优选择?

资源隔离并不是一个新概念,传统方式下不共享物理资源,可以理解为物理资源隔离方案。这种方案下不同租户或同一租户内 OLAP 和 OLTP 使用不同的副本,行存副本服务 OLTP,列存副本服务 OLAP,两种业务不共享物理资源。如果不考虑成本,物理资源隔离无疑是更好的选择。

但现实中,大部分客户都会考虑硬件成本及其资源利用率。一方面,数据库硬件的购买和维护成本高昂,而所有硬件都需要定期换新;另一方面,数据库硬件在进行单项业务处理时,平均占用率水平较低。如果不能充分利用硬件资源,无疑会造成巨大的资源浪费。

而要充分利用硬件资源,不同租户或同一租户内 OLAP 和 OLTP 共享物理资源的逻辑资源隔离方案,自然脱颖而出。 同时我们认为,物理资源隔离和逻辑资源隔离不是二选一,而是互为补充的关系。但考量到资源共享可能出现的干扰问题,一些人认为资源共享会导致 QoS 无法保证,因此对用户价值不大;另一些人也会关注完美的资源隔离是否能实现,如果实现方案过于复杂是否会得不偿失等问题。

面对上述问题,我们认为一方面要放弃完美主义,认识到基础的资源隔离能力对客户的明显价值;另一方面要用发展的眼光看问题,了解到逻辑资源隔离技术在持续进步。 因此,适合 HTAP 的资源隔离并不是物理资源隔离或逻辑资源隔离中二选一,理想的资源隔离方案是在完全物理隔离和完全共享中找到平衡点。 基础软件应该给用户更多自由,帮助用户在面对各类场景下都可以做出最合适的选择,数据库产品有必要同时提供物理隔离、逻辑隔离各级别的资源隔离能力。

如何实现适合HTAP的资源隔离?

我们在实施资源隔离前,要先解决两个问题:

  • 定义资源组,以及资源组的 QoS,对数据库来说租户就是最常见的资源组,另外 AP 和 TP 也可以是两个不同的资源组;
  • 按定义好的 QoS 制定实施资源隔离的策略。

我们先看 DBA(数据库管理员)的控制接口,然后再分析要对哪些资源做隔离(一般选择对业务影响最大的资源),最后会以 CPU 时间、IOPS 和网络带宽为例讲述 OceanBase 的隔离方案。

定义资源组,做好 OLTP 和 OLAP 的资源规划

OceanBase 的目标是实现在不同租户间的资源隔离,以及租户内 OLTP 和 OLAP 业务的资源隔离。
怎样描述租户的资源要求?OceanBase 内部是通过 unit config 实现的,比如创建一个租户之前要创建 resource pool(资源池) 、resource pool 的规格描述里就指定了各种资源的限制。对这个概念不太了解的可以点击文末 “阅读原文” 参考 OceanBase 的 DBA 手册集群和多租户管理这一章。

create resource unit box1 max_cpu 4, max_memory 21474836480, max_iops 128, max_disk_size '5G', max_session_num 64, min_cpu=4, min_memory=21474836480, min_iops=128;


怎样描述租户内 OLTP 和 OLAP 需要的资源规格?OceanBase 参考了 Oracle 经典的 Resource Manager 系统包提供的管理接口。我们观察到,很多客户的跑批业务会安排在业务低峰期,如午夜或者凌晨,此时不用过于担心 OLAP 会影响到 OLTP 类业务,我们可以把集群绝大部分资源分配给 OLAP 类业务,给 OLTP 留下最小资源保证即可。在白天的业务高峰期,通过调整资源隔离方案,可以确保 OLTP 业务资源充足,同时按照预设资源满足基本的 AP 类查询。 在 OceanBase 里,我们只需要预设两套资源管理计划,白天激活 DAYTIME 计划,夜间激活 NIGHT 计划,就可以实现满足基本的隔离需求的同时实现资源利用率的最大化。

比如我们可以用以下语法定义一个白天资源使用计划(resource plan),并且制定了此计划下 OLTP (interactive_group)和 OLAP (batch_group) 的资源百分比。80% 的资源用于 TP,剩下 20% 资源用于 AP。

DBMS_RESOURCE_MANAGER.CREATE_PLAN(
   PLAN    => 'DAYTIME',
   COMMENT => 'More resources for OLTP applications');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN             => 'DAYTIME',
   GROUP_OR_SUBPLAN => 'interactive_group',
   COMMENT          => 'OLTP group',
   MGMT_P1          => 80,
   UTILIZATION_LIMIT => 100);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN             => 'DAYTIME',
   GROUP_OR_SUBPLAN => 'batch_group',
   COMMENT          => 'OLAP group',
   MGMT_P1          => 20,
   UTILIZATION_LIMIT => 20);

定义好 资源使用计划后,可以用以下方式激活它:

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'DAYTIME';

按照类似的方式,我们可以定义夜晚的资源使用计划,并在业务低峰期激活它。

OceanBase 现在提供了按登录用户对 SQL 分类的方法,客户可以创建一个新用户用于执行 分析 SQL,只要是该用户发起的 SQL,都会被判定为是 AP 负载,这样分类简单有效。同时,OceanBase 会把执行时间超过 5s 的请求识别为当作大查询,大查询会被降低优先级。

min, max, weight,满足 QoS 根本诉求的三重定义

QoS(Quality of Service,服务质量)作为一种安全机制,可以在资源过载时保障关键进程的平稳运行。以下我们通过权重分配、资源上限和保留资源来描述 QoS。

在不同的时间段,业务的流量会有波动,所以 QoS 描述需要有一定的弹性,如果像公有云上的 ECS 一样指定一个固定的 CPU 核数和 IO 带宽,在业务高峰的时候容易出现数据库容量不够而导致的故障。

我们假设这样一个场景:总带宽是 100M,由租户 A 和租户 B 共同使用,基于资源的闲时共享和忙时隔离原则,我们尝试让租户 A 和租户 B 互不干扰地共同使用总带宽。

如果两者的重要程度不同,怎样保证重要进程的优先运行?此时我们可以每个租户的重要程度分配使用资源的比例,如给租户 A 和租户 B 分配 1:3 的权重比,当这两个租户都需要 CPU 时,A 将得到 1 份 CPU 时间,B 将得到 3 份 CPU 时间。 这一操作我们称为权重分配,或<weight>

有时候物理资源较为充裕,低权重租户可能会占用大量并不需要的资源,如何限制它的使用呢?我们可以在权重分配的基础上给不同的租户定义资源上限,如租户 A 按照权重比 1/4 时,能使用的带宽最多为 25M,当给它设置资源上限参数 20M 后,它最多能使用 20M 的带宽。

租户数量增减会引发权重配比改变,如何直观判断各租户最低资源需求的满足情况?此时我们可以给各租户设置保留资源,这样不仅可以保证所有租户基本功能的运行,也能直观清晰地描述 QoS。

我们希望把更完美的资源隔离,做进 OceanBase 数据库

资源按照使用情况有刚性和弹性的区别,资源隔离的对象通常是弹性资源。刚性资源是保障程序完成功能必须的资源,一旦被占用,短时间内也难以释放。 刚性资源的典型是磁盘空间和内存空间,连接数等,这类资源做好静态规划后,每个组可以使用的资源数量就会固定下来。弹性资源是指和程序功能无关,但是和性能有关的资源,比如 IOPS、CPU 时间、网络带宽等,这类资源一般可以抢占或被迅速释放,因此资源调度策略可以介入,实现闲时共享,忙时隔离。我们需要关注的正是弹性资源的共享机制。

刚性资源比较重要的是内存和磁盘空间,弹性资源比较重要的是 CPU 时间,IOPS 和网络带宽,OceanBase 会优先把这些资源的隔离做好。
**
CPU 隔离 **

OceanBase 目前已实现 CPU 时间的隔离,未来会加入 CPU cache 的隔离。CPU 隔离有一个特点,那就是只有在内核态才能做得比较实时,因为一个资源要能调度,前提是要能切分成很多小片,网络 IO 天然就是一个一个的 packet,磁盘 IO 也类似。CPU 时间被操作系统切分成了很多片,但是这个时间片对用户态是透明的,用户态无法介入时间片调度。用户态要调度,那就需要在代码中插入很多检查点,通过检查点把用户线程的 CPU 时间切分成很多段,同时在检查点执行调度策略。用户态插入检查点切分效果无法保证,如何在一个静态库函数里插入检查点呢?

OceanBase 选择了内核态解决方案,即 cgroup 的 cpu controller,cgroup 目前能支持 ,但不支持 min。这对我们来说不构成问题,因为 CPU 总时间不会波动,按照 weight 分配就可以保证每个组的保留时间片的要求。

CPU 隔离不仅可以隔离用户负载,也可以隔离系统内部的不同任务。比如对 OBServer 来说,多副本的 leader 选举是一个高优先级任务,我们不希望用户 SQL 把 CPU 打满最后影响到选举。我们在 cgroup 的顶层把选举和用户 SQL 分到两个目录,在用户 SQL 的目录进一步分目录,对应租户和租户内的用户。

IOPS 隔离

对于 SSD 磁盘,带宽可以通过 IOPS 来等价描述(bandwidth = size * iops)。其次不同大小的 IO,我们根据经验公式可以归一化,我们设定一次 IO 的标准大小是 16K,那么一次 2M 的 IO 就可以等价为多次 16K 的 IO。IOPS 隔离要区分设备,但是把设备暴露出来会让配置比较复杂,所以大部分情况下可以让多个设备共用一套配置。

OceanBase 从 VMware 用于隔离虚拟机 IO 的一篇论文《mClock: Handling Throughput Variability for Hypervisor IO Scheduling》中获得启发。

在公有云上部署的时候,我们发现云盘的 IO 能力是会有波动的,OceanBase 可以快速适应云盘 IO 能力的下降,保障最重要的 TP 业务不受损。同时 OceanBase 的 IO 隔离会和数据库的块缓存一起联动,OceanBase 不仅会限制 AP 的 IO 带宽,还会限制 AP 的缓存使用,这样就能避免 AP 污染块缓存,最终保障 TP 的低延迟。

网络带宽隔离

我们可以把 OBServer 之间的 RPC 分为机房内通信和机房间通信:前者主要是 SQL 分布式执行以及两阶段提交引起的,后者主要是为了高可用而做的日志复制和数据备份。不同于机房内通信,对于机房间通信的来说,一个机器到不同的机房的延迟和可用带宽都是不一样的,通常机房间带宽是共享资源,所以带宽的分配和限制需全局考虑才有意义。关键问题就在于全局的范围是什么?比如有多套 OceanBase 集群,是否要协同考虑;就算只有一套 OceanBase 集群,如果出现网络分区怎么办?我们怎么才能确保拿到全局视图?

OceanBase 从 3.2 版本开始支持 region 级别的带宽控制,接下来,我们的思路是多套 OceanBase 集群之间不做协调,需要 DBA 静态划分资源,也就是要给每个集群设置机房和机房间的可用带宽, OceanBase 在集群内部把带宽动态分到每个 OBServer ,每个 OBServer 内进一步把带宽按优先级分给不同的组。

对大部分业务来说,机房内的网络带宽分配更为关键,带宽的隔离和 IOPS 隔离是非常像的。不过由于通信目的端众多,一般不区别通信目的端,算法实施的时候把网卡当作一个 IO 设备,而不是把通信目的端当作一个设备。

网络带宽隔离问题可以分解为两部分:首先要对流量分组,或者说打标签;其次要按设定的要求对打好标签的流量做隔离。其中第一步只能由应用逻辑提供,第二步可以在应用层解决,或者在内核层面解决。因为 linux 下 tc 提供了非常丰富的限速和优先级策略,所以 OceanBase 选择应用层打标,内核态限速的方案。复用内核的能力,同时也是在复用内核的生态,用户不再需要学习一套新的限速机制。

OceanBase资源隔离的实现效果

OceanBase 目前实现了内存隔离、磁盘空间隔离、CPU 隔离以及 IOPS 隔离,未来还将支持网络带宽隔离,下文我们会以 CPU 隔离为例,对 OceanBase 资源隔离实现效果进行测试。

在介绍定义资源组的方法时,我们提到可以建一个特殊用户专门来服务 AP。在本次实验中,先创建两个测试用户:

AP@ORACLE 和 TP@ORACLE。我们把 AP 任务绑定到 AP_GROUP,TP 任务绑定到 TP_GROUP。假设这个业务白天的时候 TP 负载高,AP 集中在晚上。 因此我们为白天和晚上设置两个不同的资源使用计划,白天的时候我们希望 80% 的资源用于 TP,剩下 20% 资源用于 AP,夜晚的时候希望 50% 的资源用于 TP,剩下 50% 资源用于 TP。

从白天计划切换到夜晚计划

从结果上可以看出来,切换为夜晚计划后,AP 的 CPU 资源占比变大后,AP 的 QPS 明显变高,TP 的 QPS 有一些降低。下图中 AP 和 TP QPS 发送变化的点就是切换资源使用计划的时间。

看起来 TP 的 QPS 降低比较少,和 AP 的 QPS 变化比起来不明显。这里要注意,按理想情况来算,TP 的 QPS 变化本来就要比 AP 的变化小,因为 AP 是从 0.3 到 0.5,增加了 66.7%, TP 从 0.7 到 0.5,降了 28.5%,然后实际算一下,TP 下降了 24.7%(19000 到 14300),和理想值的差距不算特别大。

CPU 隔离能否起到理想作用,和负载类型有很大关系,如果网络成为瓶颈,那就必须要加上网络带宽隔离才能起效。 这个实验目的也不是为了表明 CPU 隔离就很牛,能解决很多问题,但是它表明了对 CPU bound 的负载,简单的 CPU 隔离效果还不错,比如目前我们还没有考虑 CPU cache 的隔离。隔离能力的建设是个渐进的过程,单纯的 CPU 隔离对 TP 加简单 AP,或者 TP 和 TP 之间的隔离就能直接起效;适当的 IOPS 隔离和网络带宽隔离加上之后,适应范围就足够广了。

本文介绍了 OceanBase 对资源隔离技术的思考和实现方案。HTAP 数据库要实现不同租户间、以及同一租户内 OLTP 和 OLAP 业务的硬件资源共享,对资源隔离提出了很高的要求, 我们认为更适合 HTAP 数据库的资源隔离方案是物理隔离、逻辑隔离两者互补的方案。 展望未来,OceanBase 的资源隔离技术也会不断演进和完善,更好地满足用户对资源隔离的需求。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广