CN109960591B - 一种面向租户资源侵占的云应用资源动态调度的方法 - Google Patents

Abstract

发明涉及一种面向租户资源侵占的云应用资源动态调度的方法。通过将租户应用及组件与任务管理器相绑定，从而感知租户整体以及局部单元，对租户请求进行并发控制的同时，在一次请求处理过程中复用云服务器任务线程，避免了交互协议重构问题，并且对租户的最大并发规模进行调整，以适应租户负载动态变化时所产生的性能波动，解决租户隔离以及资源侵占的问题。

Description

一种面向租户资源侵占的云应用资源动态调度的方法

技术领域

本发明涉及一种面向租户资源侵占的云应用资源动态调度的方法，属于软件技术领域。

背景技术

Web应用服务器是为事务性Web应用提供一系列运行时服务的中间件平台，在高共享程度的多租户模式下，往往作为租户应用的宿主平台而使用，在多租户Web应用场景中，对应用服务器性能的衡量主要存在以下两种，一种是应用服务器的服务提供能力，包括其线程池的大小，任务线程的绑定与回收，可承载的租户数量等，以及应用服务器所在物理主机的资源提供能力，包括CPU计算能力，内存，存储空间大小，网络带宽等，这种性能指标取决于硬件的性能和应用服务器的实现以及配置，具有明确的衡量标准。当租户的外部请求规模超过应用服务器所能处理的范围时，就会出现严重的性能下降。另一种是以租户服务质量保证为度量的性能指标，对不同租户而言，每个租户对服务质量的要求是不同的，在多租户环境下，资源总量固定，一个租户占用较多服务资源必将对其他租户的服务质量产生影响，如何平衡租户所享有的服务质量，以及在发生资源侵占时对租户的服务质量进行优化配置，是保证应用服务器多租户性能的一个重要问题。因而对Web应用服务器多租户性能的考量，可以看作租户是否能够获取满足其服务质量需求的服务资源，以及在多租户模式下应用服务器资源的合理分配和有效利用。本论文所阐述的性能管理，其本质是通过对租户在请求服务时所享有的资源进行合理分配和管理，从而使得应用服务器性能满足租户服务要求的一种管理方式。

资源是一种系统元素，可以分为物理资源和逻辑资源，其中物理资源是指可度量的物理实体，如处理器、内存、硬盘存储、网络带宽等，逻辑资源是物理资源的逻辑映射，如进程，线程，文件等系统元素，对Web应用来讲，其主要所面向的资源为逻辑资源，可以分为两类，一类是应用业务逻辑层运算资源，即为具有主动执行能力的逻辑资源，如任务线程等，另一类是数据资源，包括用户信息，配置等，因而在多租户Web应用场景下，租户的隔离也包括运算资源隔离和数据资源隔离两部分，对数据部分的隔离研究较多，多是通过对数据库的不同层次的隔离而实现，而在运算资源部分，租户的隔离多从请求调度和请求处理过程入手。

发明内容

本发明的目的：解决高共享程度的多租户模式下容易出现的租户资源侵占问题，对租户提供性能保证。

本发明的原理：对租户提供细粒度的管理，收集租户运行时状态信息和资源使用信息，通过租户请求的并发控制等手段对租户实施隔离，避免租户资源侵占现象的发生，提供良好的性能保证。

本发明技术解决方案：一种面向租户资源侵占的云应用资源动态调度的方法，其特点在于实现步骤如下：

第一步，资源检测

租户的一次请求处理过程中可能包含多个组件或服务的调用。信号量是操作系统中实现同步和互斥的一种普遍机制，包含一个非负的整型信号变量，并带有P，V两个原子操作。利用信号量机制对执行租户请求处理任务的线程资源的在租户和租户内部组件两种粒度约束策略下进行并发控制。每个约束策略包含一个由信号量控制的最大并发任务量，当执行租户请求处理任务的线程在某个信号量上执行P操作时，相当于请求增加任务并发量，如信号量为0，表示该任务并发量已达上限，则线程会被挂起，进入等待队列；当应用请求任务完成或离开组件时，执行V操作，并唤醒队列中等待的线程。在一次请求处理过程中复用同一线程来执行多次组件调用，各组件仍以同步方式进行交互，避免了组件交互协议的重构以及线程切换带来的状态维护代价，同时，排除了死锁与饿死隐患。

当租户请求到达时，先得到请求的上下文信息，然后根据上下文信息获取当前请 求的约束策略以及相关联的。接着，进行并发任务量的约束检查，若约束策略为应用 级约束策略，则对租户应用进行全局并发控制。首先得到当前租户i的任务管理器上 的请求应用并发信号量，对其进行P操作，同时检查约束条件是否满足，如满足，则该线 程继续执行，否则挂起该线程，并放入等待队列。若约束策略为组件级约束策略，则对租户 应用内部的组件进行局部并发控制。与应用级约束策略的区别在于，需要判断所请求的组 件是否为该请求的首个组件。如果非首个组件，则需要对租户i所请求组件的并发信号量进行V操作，并判断是否需要唤醒等待队列中挂起的线程。对未满足约束条件的线程， 在当前信号量中睡眠并等待唤醒，满足约束的线程直接进入调度序列调度执行。

第二步，请求执行

根据上一阶段的约束策略，将请求处理过程分为不同粒度的原子操作并执行。即 执行租户应用或者组件的原生方法。在请求执行完成后， 对当前的的信号量(或)执行V操作，并判断是否唤醒等待队列中挂起的线程。若约束策略为组件级约束策 略，在释放当前组件上的信号量后，需判断当前请求是否需要返回上级组件继续执 行，如存在上级组件，则当前线程请求上级组件约束，继续执行上级组件中的处理流程。对 租户来讲，其对资源的需求并非一直固定，如果租户所依靠的终端用户访问量下降，或者在 租户应用中增加新的特性使其终端用户访问量上升，为节省成本或者满足终端用户的体 验，就需要减少或增加资源的最大占有率，而在租户应用中的不同的组件部分也具有不同 的资源访问开销，如果依据监测数据手工的设置每个租户的最大并发约束，任务量较大，且 在租户负载变化较频繁时，不利于系统的整体性能最优化，因此需要建立一种自适应的并 发量控制机制，来对系统资源进行优化调整。

在系统状态变化时对租户的最大并发规模进行调整，当租户资源占用量到达危险 阈值时，自动降低其最大并发数量，使其不会发生性能侵占，此外，在系统具有一定空闲时， 放宽对资源占用不足的租户的并发限制。管理人员根据租户QoS需求，预先设定服务器最大 资源使用率，以及每个租户的最大资源使用率和 ，运行时采用 层次控制的方法，针对不同粒度的约束策略采用不同的处理方式。

第三步，应用容量调整

在应用级管理粒度下，首先获取服务器节点的资源使用量，如果， 则系统处于过载状态，检查租户当前CPU占用率，如果,则将该租户加入 待调整集合中，如不存在这样的租户，则按在中的比例确定待调整租户，加入待 调整集合，然后检查集合中每个租户的当前并发规模和最大并发容量，将置为，即缩小并发规模，当时，则系统尚有资源空闲，首先检 查所有租户的等待任务数，如等待任务数非0，则获得该租户对应的容量调整值，根据其当前值和等待任务数目，增加最大并发容量，如果所有租户的任务都 没有达到其最大并发数限制，则不做调整。

第四步，组件容量调整

在组件级管理粒度下， 时，检查所有租户的以及，将超过最 大CPU资源约束的租户组件加入待调整集合，同样如不存在此类租户或组件，则按在中所占比例以及每个租户的组件CPU占用率在中所占比例确定待调整租 户的待调整组件，加入待调整集合中。然后检查集合中每个租户组件的当前并发规模 和最大并发容量，将置为，即缩小并发规模,当时，对的租户，检查所有组件的，如果,则将该组件加入待调整集 合中，缩小该组件的并发规模，对的租户，检查所有组件的，如等待任务数 非0，则获得该组件的，根据其当前值和等待任务数目，增加最大并发容量，如 果所有组件的任务都没有达到其最大并发数限制，则不做调整。

本发明与现有技术相比具有如下优点：能够感知和管理租户整体以及局部单元，从而避免了交互协议重构，并且对租户的最大并发规模进行调整，以适应租户负载动态变化时所产生的性能波动，解决租户隔离以及资源侵占的问题。

附图说明

图1为云资源动态调整系统架构。

具体实施方式

以下结合具体实施例和附图对本发明进行详细说明，如图1所示，本发明实施例方法流程：

底层控制模块对租户请求进行并发控制，进行约束检查以及信号量操作的主要场景位于任务管理器作用范围内。请求分发器将租户请求与一个互斥信号量相绑定成为一个带自阻塞能力的任务实例，然后分发到相关联的任务管理器单元进行处理，任务管理器单元负责在约束信号量上执行P，V操作，并将任务实例加入或取出等待队列，同时容量控制器根据外部资源约束以及任务管理器的实时任务状态，对约束信号量的最大值（并发规模）进行调整。根据其功能实现的层次不同，并发控制模块可以分为信号量底层控制模块和自适应容量调整模块两部分。

底层控制模块负责对租户的当前请求进行并发控制，其任务流程属于管理框架请求处理流程的子流程为：

（1）请求到达请求管理器时，请求管理器将其与一个互斥信号量绑定，封装成一个任务，并向其所属的任务管理器请求资源；

（2）任务管理器接收到请求资源的消息后，检查其最大并发约束，对其执行资源信号量的P操作，如当前资源信号量的值大于0，则同意获取资源，执行当前任务，同时资源信号量的值减少，否则将其阻塞在互斥信号量上，加入资源信号量等待队列；

（3）当一个任务执行完成后，向任务管理器发出释放资源请求，任务管理器检查最大并发约束，对其执行资源信号量的V操作，如当前资源信号量的值大于0，则直接增加资源信号量的值，然后返回，如当前资源信号量的值等于0，则从等待队列中取出一个排队任务，从互斥信号量中唤醒，继续执行，如等待队列为空，则增加资源信号量的计数；

（4）任务执行完成后，返回租户响应。

容量调整模块负责在系统运行时调整任务管理器所绑定的被管单元的最大并发规模。性能管理系统提供了手动和自动调整两种模式，手动模式是指管理人员通过管理控制台直接对被管理单元的最大并发规模进行调整，自动模式是通过管理控制台读入租户SLA约束条件，根据系统当前状态决定并发规模的调整。容量调整模块的任务流程为：

（1）管理人员通过管理控制台，直接对任务管理器进行并发规模控制，任务管理器接到控制信号后，修改最大并发约束值；

（2）管理人员设定租户的SLA约束，在性能管理系统中，SLA约束即租户或租户组件所能占用的CPU占用率的最大值；

（3）手动模式与自动模式可通过管理控制台进行切换，自动调整模式下，并发控制服务周期性执行容量控制器的功能，容量控制器获得租户SLA约束，以及任务管理器运行的状态信息，获取待调整任务管理器，依次对其进行控制，修改最大并发约束值。

Claims (1)

1.一种面向租户资源侵占的云应用资源动态调度的方法,方法特征在于实现步骤如下：

第一步，资源检测：当租户请求到达时，先得到上下文信息，获取当前请求的约束策略以及相关联的任务管理器，进行并发任务量的约束检查，若约束策略为应用级约束策略，则对租户应用进行全局并发控制；若约束策略为组件级约束策略，则对租户应用内部的组件进行局部并发控制；如果非首个组件，则需要对租户所请求组件的并发信号量进行信号量操作，并判断是否需要唤醒等待队列中挂起的线程；对未满足约束条件的线程，在当前信号量中睡眠并等待唤醒，满足约束的线程直接进入调度序列调度执行；

第二步，请求执行：将请求处理过程分为不同粒度的原子操作并执行，在请求执行完成后，对当前的信号量执行信号量操作，并判断是否唤醒等待队列中挂起的线程，若约束策略为组件级约束策略，在释放当前组件信号量管理器上的信号量后，需判断当前请求是否需要返回上级组件继续执行；

第三步，应用容量调整：获取服务器节点的资源使用量 ，如果，则系统处 于过载状态，检查租户当前CPU占用率，如果,则将该租户加入待调整 集合中；如不存在这样的租户，则按在中的比例确定待调整租户，加入待调整集 合，然后检查集合中每个租户的当前并发规模和最大并发容量，将置 为，即缩小并发规模；当时，系统尚有资源空闲，检查所有租户 的等待任务数AQ；如等待任务数非0，则获得该租户对应的容量值，根据其当前值和等待任 务数目，增加最大并发容量；如果所有租户的任务都没有达到其最大并发数限制，则不做调 整；

第四步，组件容量调整：当服务器节点的资源使用量时，检查所有租户的当前 CPU占用率，将超过最大CPU资源约束的租户组件加入待调整集合；如不存在此类租户 或组件，则按在中所占比例以及每个租户的组件CPU占用率加入待调整集合中， 检查集合中租户i的组件j已用容量和最大并发容量，将置为，即缩小并发规模；当时，对的租户，检查租户i的组件j 当前CPU占用率；如果,则将该组件加入待调整集合中，缩小该组件的并发规模； 对的租户，检查所有租户i的组件j等待任务数；如等待任务数非0，则获得 该组件的，根据其当前值和等待任务数目，增加最大并发容量；如果所有组件 的任务都没有达到其最大并发数限制，则不做调整。