本文主要是介绍OceanBase 如何实现多层面的资源隔离，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
OceanBase的资源隔离涵盖了多个方面，如物理机器间的隔离、不同租户之间的隔离、同一租户内的隔离，以及针对大型查询请求的隔离等。在实际应用OceanBase的过程中，我们经常会遇到这些操作场景或产生相关需求。这篇文章针对这些内容进行了简要的梳理与汇总，有需要的朋友们可以通过以下内容进行初步的了解。
物理机器隔离
每个租户可以通过使用不同的服务器，来保证资源层面完全不会有任何影响。默认情况下，如果每个ZONE 有多个OBServer，那么OB会根据租户UNIT的资源配置将其均分到多个OBServer内，当然这个过程对于使用者来说是透明的，无需关注。
但是如果想要自定义UNIT到对应的节点上，也就是不同租户占用不同的机器，那么就需要关闭OB本身的均衡和迁移能力，比如关闭 enable_rebalance 和 enable_transfer，然后通过 ALTER SYSTEM MIGRATE UNIT 手动迁移UNIT 到想要的节点上，通过 ALTER SYSTEM TRANSFER PARTITION 语句用于将指定分区的迁移至指定的日志流。
这种方式可以按照自己需求来自定义分配，但是除非对OB有非常强的掌控力，否则不建议这个操作。因为这样操作以后，OB本身的负载均衡和迁移能力将不会再发挥作用。
租户隔离
租户隔离分为租户间的隔离和租户内的隔离。
租户间主要是通过指定UNIT配置，给到这个租户对应的资源大小以及权重，然后OB 会根据配置调度整个实例的资源给到不同的租户。租户内的隔离主要分为用户资源隔离和SQL资源隔离，通过配置用户和SQL的资源来对租户内的资源进行分配及隔离。
租户间资源隔离
咱们熟知的物理资源一般可以分为两类：一类是弹性资源，比如CPU，磁盘带宽等；另一类是刚性资源，比如内存，磁盘空间等。弹性资源是可以抢占的，刚性资源一旦被占用，除非占有者主动释放，否则是无法抢占的。
租户间资源隔离包含了弹性资源以及刚性资源，比如CPU、IOPS以及内存与磁盘空间，通过UNIT划分控制。
CPU隔离
CPU的隔离通过UNIT CONFIG中的MIN_CPU和MAX_CPU来配置，可以通过配置最小占用、最大占用以及可选择性的开启超卖来实现。
OB的CPU隔离主要有两种方式：基于线程数和基于Cgroup。
在了解CPU隔离之前，可以看一下这个文章，可能对这个内容会更容易理解：容器CPU（1）：怎么限制容器的CPU使用？-CSDN博客
基于线程数的租户工作线程的 CPU 隔离
OBServer 最基础的CPU隔离是通过用户态调度，控制活跃线程数来实现的。每个租户有独立的线程池，线程池的规格是由租户规格和一些配置参数来决定的。
由于 SQL 执行过程中可能会有 IO 等待、锁等待等，所以一个线程无法用满一个物理 CPU，故在缺省配置下，OBServer 节点会给每个 CPU 启动 4 个线程，4 这个倍数可以通过配置 cpu_quota_concurrency 来控制。这就意味着如果一个 Unit 的 MAX_CPU 是 10，那么它能同时运行的活跃线程是 40，最大物理 CPU 的占用是 400%。
但是这种方式的隔离存在一些问题，就是只能限制线程数但是不能完全限制CPU使用率，因为每个线程对CPU的占用这个不可控，所以只能做软隔离。
基于 cgroup 的租户工作线程的 CPU 隔离
OBServer 也支持配置 cgroup 来实现 CPU 的隔离优化。cgroup 能对线程的 CPU 使用率进行精准的限制，达到租户之间 CPU 强隔离的效果。
observer├── tenant1│ └── tasks│ ├── thread1│ ├── thread2│ └── ...├── tenant2│ └── tasks│ ├── thread1│ ├── thread2│ └── ...└── other开启 cgroup 后最大的变化是不同租户的工作线程放到不同的 cgroup 目录内，租户间的 CPU 隔离效果会更好。最后的隔离效果如下：
- 如果一个 OBServer 上只有一个租户负载很高，其余租户比较空闲，那么这个负载高的租户的 CPU 也会受到 MAX_CPU 的限制。
- 延续上面的场景，如果有多个空闲的租户的负载上升了，导致物理 CPU 不够了，cgroup 会按照权重分配时间片。
cgroup 方式可以做到硬隔离，因为可以严格控制每个租户的cpu使用率，所以可以更好的保证cpu之间相互不影响，尤其是在不超卖的情况下。4.2.x版本以后，通过OCP创建的集群，默认会使用cgroup做CPU隔离。
内存隔离
内存空间等资源属于刚性资源，因为这类资源的描述是标量，一块内存被 A 占用了，就不能再分配给 B 使用。所以对于内存隔离就不过多赘述了。
IOPS 隔离
OBServer 内所有的 IO 都是异步 IO，并且是绕过 OS 的 direct IO，磁盘带宽（IOPS）的隔离是通过控制 OBServer 提交异步 IO 的时间间隔来实现的。
OBServer 的 IO隔离没有借助cgroup，而是自研实现的，底层算法可以简单理解为多个租户共用一组io线程，所有租户都根据IO线程来分配资源以及执行租户IO队列中的IO请求，所以不同租户之间的IO请求正常情况下没有冲突，也能通过IO线程保证各个租户IOPS的使用量。
租户的IOPS受三个配置影响，MIN_IOPS、MAX_IOPS 和 IOPS_WEIGHT。
OBServer 内部会统一按照 16 KB 读的 IOPS 值作为有效值进行处理，所以建议MIN_IOPS和MAX_IOPS 根据当前磁盘计算出来的 16KB读对应的值来配置。MIN_IOPS总和建议不超过机器磁盘的IOPS，MAX_IOPS可以根据实际情况配置，可以超过。MAX_IOPS需要大于等于MIN_IOPS，如果没有指定具体的值，那么MIN_IOPS 和 MAX_IOPS 的值均为 INT64_MAX。
多租户之间的资源分配与抢占可以总结为一句话：闲时共享，忙时隔离。空闲带宽可以给有需求的租户或io类别共享，但忙碌时，需要按weight的比例隔离。
举个例子，如果磁盘IO的IOPS为10000，其中，
租户A，MIN_IOPS：4000，MAX_IOPS：8000
租户B，MIN_IOPS：6000，MAX_IOPS：10000
假设两个租户当前使用的IOPS都能达到设置的 MIN_IOPS的值，他们只会占用各自 MIN_IOPS 的 IOPS 大小，因为已经达到了磁盘本身IOPS的上限。如果租户 A 现在只用了2000，租户B是可以挤占的，比如用到8000的 IOPS。当租户A需要的时候，它会挤占回来，以满足MIN_IOPS的需求，并且这个优先级最高。
所以说，如果租户B需要的IOPS是1w，但是租户A至少也需要4000的IOPS，那么这个时候租户B是会受到影响的，因为当前场景下IO是不满足需求的，所以说对于IO也要提前做好规划，如果单台机器的IO满足不了需求可以通过扩容机器的方式来满足。
如果磁盘IO的IOPS为12000，那么剩余的这2000IOPS 租户AB需要使用的话如何分配则根据IOPS_WEIGHT来做权重。
验证磁盘 IO 隔离能力的实例
这里引用研发的文章实例可能更容易理解一些
原文链接：OceanBase 4.1解读：给用户足够灵活简单的IO隔离体验
为了验证磁盘 IO 隔离的能力，我们首先用单测做了一项仿真实验：我们设置 4 个租户，每个租户启动 64 个线程发送 IO 请求，IO 请求固定为 16KB 随机读，租户 1、2、4 的负载持续 20 秒，租户 3 的负载从第 10 秒开始，持续 10 秒。实验磁盘 IOPS 上限大概在 6w，如果不加限制，任意一个租户单独都可以打满磁盘。
首先验证租户间磁盘 IO 隔离，各租户的配置和实验结果如表 1 和图 1 所示：
- 磁盘已经打满时，新加入的租户 3 依然拥有 1 万 IOPS，因为其通过 MIN_IOPS 预留了 1 万；
- 租户 4 的 IOPS 没有超过 5 千，因为其通过 MAX_IOPS 设置了资源上限；
- 无论负载如何变化，租户 1 和租户 2 的 IOPS 比值大概为 2:1，正如权重比例要求。
租户内隔离
租户内资源隔离通过DBMS_RESOURCE_MANAGER系统包的CREATE_PLAN_DIRECTIVE接口进行配置，会对资源使用组的CPU和IO资源进行限制
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (plan IN VARCHAR2, group_or_subplan IN VARCHAR2, comment IN VARCHAR2 DEFAULT'', mgmt_p1 IN NUMBER DEFAULT 100,utilization_limit IN NUMBER DEFAULT 100,MIN_IOPS IN NUMBER DEFAULT 0,MAX_IOPS IN NUMBER DEFAULT 100,WEIGHT_IOPS IN NUMBER DEFAULT 0,
);
其中，utilization_limit 表示CPU 资源使用比例上限。MIN_IOPS、MAX_IOPS和WEIGHT_IOPS用来配置管理IOPS。
目前支持配置租户内用户级和SQL 级的资源隔离，配置的方法可以参考官网：
配置用户级资源隔离：
OceanBase配置用户级资源隔离
配置SQL 级资源隔离：
OceanBase 配置 SQL 级资源隔离
大查询队列
除了上面提到的方式，其实OB还支持大查询队列。
默认情况下，如果TP业务请求的数据库，突然过来AP相关的请求，很有可能会影响到TP的业务甚至整个集群的访问，所以为了避免这类问题，OB提供了一个大查询队列，这个大查询队列默认情况下只会占用 30% 的CPU资源，大查询判断的条件默认为执行时间超过 5s。对于后面进来的大查询，如果在计划缓存中存在，并且预估执行时间超过5s，那么会直接判断它是大查询，然后放到大查询队列中。以此来避免问题SQL或者AP查询对TP业务的影响。
当然，如果当前集群内本身没有小查询，基本上都是大查询的时候，这个限制是不生效的，大查询可以用到全部的CPU资源。
相关参数：
large_query_threshold：用于设置查询执行时间的阈值，默认5s。
large_query_worker_percentage：用于设置预留给处理大查询的工作线程百分比，默认30%。
总结
OB的资源隔离还是涵盖了很多方面的，并且非常的灵活，可以更好的帮助我们管理集群、做业务优化等，在使用OB的过程中，可以按需使用OB的资源隔离能力来满足业务的需求。
这篇关于OceanBase 如何实现多层面的资源隔离的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
