CN111625347B - 基于服务组件级的细粒度云资源管控系统和方法 - Google Patents

基于服务组件级的细粒度云资源管控系统和方法 Download PDF

Info

Publication number
CN111625347B
CN111625347B CN202010168157.0A CN202010168157A CN111625347B CN 111625347 B CN111625347 B CN 111625347B CN 202010168157 A CN202010168157 A CN 202010168157A CN 111625347 B CN111625347 B CN 111625347B
Authority
CN
China
Prior art keywords
component
request
contribution
load
target application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010168157.0A
Other languages
English (en)
Other versions
CN111625347A (zh
Inventor
赵来平
杨亚南
张凯炫
李克秋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tianjin University
Original Assignee
Tianjin University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tianjin University filed Critical Tianjin University
Priority to CN202010168157.0A priority Critical patent/CN111625347B/zh
Publication of CN111625347A publication Critical patent/CN111625347A/zh
Application granted granted Critical
Publication of CN111625347B publication Critical patent/CN111625347B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明涉及云计算技术领域，为提高云计算数据中心延迟敏感型服务和尽力批处理服务混合部署时的资源效率问题，从而提高混合部署时的资源利用率，本发明，基于服务组件级的细粒度云资源管控系统和方法，包括请求追踪器、贡献分析器、协调控制器，请求追踪器会解析出服务访问的路径，并且得出其在每一个组件上的运行时间；然后，贡献分析器通过分析得出服务级别协议SLA通过控制不同组件的执行时间的均值和方差来保证采用皮尔森相关系数来衡量组件上的执行时间和总的尾延迟的相关性，基于均值、方差、皮尔森相关系数，得出每个组件对于总的尾延迟的贡献；最后实现资源分配控制。本发明主要应用于云计算场合。

Description

基于服务组件级的细粒度云资源管控系统和方法
技术领域
本发明涉及云计算技术领域，特别是数据中心的任务调度与优化领域。
背景技术
云计算实现了租户之间的资源共享，提高了云服务器的资源利用率，但也给每个租户的用户体验带来了很多挑战。将多个应用程序部署到云服务器上，会在部署的工作负载之间产生性能干扰，显著影响应用程序的服务质量。为了减少共享资源例如中央处理器(Center Process Unit，简称CPU)、末级缓存(Last Level Cache，简称LLC)、内存带宽(Memory Bandwidth，简称MemBW)竞争导致的性能差异，2015年英特尔推出了资源管理技术(Resource Director Technology，简称RDT)，支持一些Xeon至强系列处理器监视和分配多个共享资源1，但是目前尚不支持对内存带宽的分配。PARD2支持在硬件层次上通过可编程的按需的架构来区分不同的服务，但使用它需要新的硬件支持。
在现有的云系统中，租户通常采用资源过度分配的方法来减少干扰。但是，浪费性的过度分配导致低的资源利用率，从而增加了云服务的成本。如何在保证用户体验的同时提高云系统的资源利用率成为一个大挑战。为了解决这一挑战，最常用的方法之一是根据非竞争应用程序的资源使用特性合并它们。然而，将它们广泛部署在大型云系统中是不实际的，首先，随着新的云应用的不断涌现，当今的云应用非常多，几乎不可能对所有的云应用进行准确的描述。其次，即使对于相同的应用程序，其资源消耗也可能随访问负载(或数据大小、版本升级)而变化。第三，可能合并的数量将随着工作负载的数量以指数形式进一步增长，很难有效地找到合适的合并。在不描述资源使用模式的情况下，还可以通过监控是否违反服务级别协议SLA(Service Level Agreement，简称SLA)的反馈响应来减轻问题，包括系统重新配置以及资源重新分配。然而，为了尽可能避免影响用户体验，它们的响应策略通常相当保守。对服务性能的描述表明，保守响应是非常安全的，但是可能会损害资源的利用率，并且仍然有可能通过积极的整合来提高资源的利用率。
1Ioannis Papadakis,Konstantinos Nikas,Vasileios Karakostas,GeorgiosGoumas,and Nectarios Koziris.Improving qos and utilisation in modern multi-core servers with dynamic cache partitioning.In Proceedings of the JoinedWorkshops COSH 2017and VisorHPC 2017,2017.
2Jiuyue Ma,Xiufeng Sui,Ninghui Sun,Yupeng Li,Zihao Yu,Bowen Huang,Tianni Xu, Zhicheng Yao,Yun Chen,Haibin Wang,Lixin Zhang,and YungangBao.Supporting differentiated services in computers via programmablearchitecture for resourcing-on-demand(pard).SIGARCH Comput.Archit.News,43(1):131–143,March 2015。
发明内容
为克服现有技术的不足，本发明旨在提高云计算数据中心延迟敏感型服务(Latency Critical，简称LC)和尽力批处理服务(Best-effort，简称BE)混合部署时的资源效率问题，通过考虑不同组件对尾延迟的贡献的不同，优化不同LC组件与BE任务的混合部署的策略，从而提高混合部署时的资源利用率。为此，本发明采取的技术方案是，基于服务组件级的细粒度云资源管控系统，包括请求追踪器、贡献分析器、协调控制器，由于对于一个LC服务的请求可能被不同的服务组件处理，请求追踪器会解析出服务访问的路径，并且得出其在每一个组件上的运行时间；然后，贡献分析器采用皮尔森相关系数来衡量组件上的执行时间和总的尾延迟的相关性，基于均值、方差、皮尔森相关系数，得出每个组件对于总的尾延迟的贡献；最后协调控制器采用基于贡献的阈值化方法来控制每台机器上批处理服务BE作业的资源分配。
请求追踪器中，为了获得组件的执行时间，在每个LC组件中记录4个活动事件:syscall_accept表示接收请求，tcp_sendmsg表示数据包的发送，tcp_rcvmsg表示数据包的接收，syscall_close表示请求调用的结束，将它们分别表示为接受连接ACCPET、接收RECV、发送SEND和关闭连接CLOSE四种事件；根据不相关进程的进程控制符pid(ProcessIdentifier)过滤掉由它们产生的噪声系统调用，组件中事件之间的因果关系是使用它们的线程tid标识的，因为请求中的事件共享相同的tid，对于组件之间的因果关系，SEND和RECV 之间的映射使用它们的IP地址、端口号和pid；
规定
Figure BDA0002408203180000021
或
Figure BDA0002408203180000022
代表节点h上的发送或接受事件，并且i,j代表从节点i到j的数据流，在通过systemTap采集到各个组件的
Figure BDA0002408203180000023
或
Figure BDA0002408203180000024
后，可以计算得出组件i上的请求执行时间Ti以及组件i和组件j之间的通信时间T(i,j)；
贡献分析器中，为了决定每个LC组件上可以部署的BE作业的数量，为每个组件定义一个贡献值，以描述其对整体尾延迟的影响，给定由请求跟踪器输出的请求的组件运行时间和网络传输时间，总体响应时间计算如下：
Figure BDA0002408203180000025
n代表LC服务的组件的数量，Ti代表一个请求在组件i上的执行时间，并且T(i,i+1)代表组件i与组件i+1的网络传输时间。
指导定义贡献的三项原则：
(1)具有较高的执行时间的组件对尾延迟的贡献更高，这项原则强调了每个组件的平均执行时间；
(2)具有较高的执行时间的方差的组件对尾延迟的贡献更高；
(3)与尾部延迟高度相关的组件对尾部延迟的贡献更大；
基于以上原则，接下来将展示如何计算组件的贡献，设
Figure BDA0002408203180000026
是请求在组件i上的平均执行时间，Ti k表示在负载级别k下，请求在组件i上的平均执行时间，然后得到：
Figure BDA0002408203180000027
m是请求负载强度级别的数量，组件i上的请求平均执行时间在所有组件中的占比pi表示如下，
Figure BDA0002408203180000031
使用皮尔森相关系数
Figure BDA0002408203180000032
来评估组件i和应用整体尾延迟的99分位数之间的相关性，设
Figure BDA0002408203180000033
是在负载j下的应用99分位延迟，得到：
Figure BDA0002408203180000034
使用归一化的变化系数来得到组件i的变化的贡献如下
Figure BDA0002408203180000035
最后，定义组件i的贡献使用其乘积
Figure BDA0002408203180000036
协调控制器中将LC组件的请求负载和贡献作为输入，并对BE任务的启动/停止做出决策，详细步骤如下：
(1)Agent架构
Agent系统架构由一个顶层控制器和四个子控制器构成，顶层控制器对BE任务作出决策，包括load-based决策和slack-based决策，load-based决策启动或停止BE任务是根据当前请求负载，而slack-based决策启动或停止BE任务根据目前的尾延迟与SLA中规定的尾部延迟之间的差距，CPU核心与LLC通路控制器、CPU核心频率的控制器、内存(memory)控制器和网络带宽(net)控制器，4个子控制器根据顶级控制器的控制指令增加或减少分配给BE任务的资源。
总控制器的决策状态分为5种，分别是：
(a)允许混部BE，该状态允许利用现有的空闲资源去增加BE作业的数量并增加BE作业使用的资源量；
(b)不允许继续混部BE，该状态不允许继续增加BE作业的数量或者资源量，现有正在运行的BE作业可以保有资源量并继续运行；
(c)减少BE的资源，该状态运行BE作业继续运行，但是需要减少BE作业保有的资源；
(d)暂停所有BE作业，该状态暂停当前所有正在运行的BE作业，停止作业的执行但是 BE作业可以继续保有资源；
(e)清除所有BE作业，该状态立即杀掉所有正在运行的BE作业，并释放BE作业占用的所有资源；
总控制的算法如下：
实时查询目标应用的负载和距离违反SLA的松弛度slack，
Figure BDA0002408203180000037
slack为负，代表违反SLA，否则slack越接近1，代表距离违反SLA越远，分为下面几种情况：
1.当前目标应用slack<0，则进入状态e；
2.当前目标应用slack>0，目标应用负载大于loadLimit，则进入状态d；
3.当前目标应用负载小于loadLimit，且0<slack<slackLimit/2，进入状态c；
4.当前目标应用负载小于loadLimit，且slackLimit/2<slack<slackLimit，进入状态b；
5.当前目标应用负载小于loadLimit，slack>slackLimit，进入状态a；
(2)阈值机制
利用相应LC组件的贡献，独立地推导出每台机器的loadLimit和slackLimit的阈值；
对于loadLimit，阈值负载限制表示允许将BE任务与LC组件一起运行的请求负载上限，使用归一化的变化系数(Vi)来配置这个阈值，选择波动大于平均值的第一个负载点作为 loadLimit；
对于slackLimit，表示允许BE任务增长的slack的下界，如果一个组件对整体延迟的贡献很小LC服务，只需要一个较小的slackLimit，这样更多的BE任务就可以部署在这台机器上，或者子控制器可以分配更多的资源给BE任务，基于LC组件的贡献，采用迭代算法来寻找每台机器的最佳slackLimit值。
子控制器的资源控制共分为4种，分别是：
1.CPU核心与LLC通路控制器，控制CPU核心的分配，如果决策状态不为a，则睡眠等待，否则判断当前内存带宽是否超限，超限则减少BE作业的核心数量、LLC通路以及内存带宽，如果当前内存带宽不超限则预判断增加LLC通路和CPU核心数量是否导致内存带宽超限，否则增加资源给BE作业；
2.CPU核心频率的控制，判断如果计算系统的当前CPU功耗达到散热设计功耗TDP(Thermal Design Power)的80％且目标应用的运行频率小于额定频率，则降低BE作业的运行频率来提升目标应用的运行频率；
3.memory控制器，监测目标应用的内存使用率，如果超过限制，则分配空闲的资源拓展目标应用的内存容量，如果当前没有空闲内存，则减少BE作业的内存容量来提供给目标应用使用；
4.net控制器，监测目标应用的网络带宽使用，预留给目标应用一部分用于突发情况，之后计算当前可用的空闲带宽提供给BE作业使用。
基于服务组件级的细粒度云资源管控方法，请求追踪器：解析出服务访问的路径，并且得出其在每一个组件上的运行时间；然后，贡献分析：通过分析得出服务级别协议SLA通过控制不同组件的执行时间的均值和方差来保证，采用皮尔森相关系数来衡量组件上的执行时间和总的尾延迟的相关性，基于均值、方差、皮尔森相关系数，得出每个组件对于总的尾延迟的贡献；最后协调控制：采用基于贡献的阈值化方法来控制每台机器上批处理服务BE作业的资源分配。
本发明的特点及有益效果是：
本发明使用一个多层结构的电子商务系统和扇出结构的redis集群，在生产负载下研究系统的性能。实验结果表明，与保守的策略相比，在保证SLA的前提下，使用所提出的系统后，系统的生产量提升7％-8％，CPU利用率提升10％-27％，内存带宽利用率13％-25％。
附图说明：
图1是干扰对LC组件上共享资源的影响。这些值是延迟，且规范化为SLA延迟。
(a)为Redis内存数据库主从节点对比，(b)为电子商务网站前后端对比。
图2为系统的设计架构。
图3是对组件间的一个请求追踪因果关系的示意图。
图4是组件的平均执行时间和它们的标准化的变化率。(a)为平执行时间图，(b)为归一化变异系数图。
图5是设计的系统相对于已有系统Heracles的资源利用率的提升。
(a)、(b)、(c)、(d)、(e)分别为电子商务服务E-commerce，远程字典服务 Redis，搜索应用服务Solr，社交网络服务Elgg，搜索与分析服务Elasticsearch的动态变化图。
图6系统运行过程，包括资源分配，负载动态变化，执行的操作等。
具体实施方式
本发明旨在提高云计算数据中心延迟敏感服务(LC)和尽力批处理服务(BE)
接下来介绍系统的设计，并展示它如何利用LC组件之间的特性差异来布置更多的BE任务。基本思想是，对尾延迟贡献大的组件采用保守的方式来控制，对于其它对尾延迟贡献小的组件，在布置BE任务时，采用积极部署的方式。本系统由三个模块组成：请求追踪器、贡献分析器、协调控制器。由于对于一个LC服务的请求可能被不同的服务组件处理(由于各种微服务或同一微服务的不同副本)，请求追踪器会解析出服务访问的路径，并且得出其在每一个组件上的运行时间。然后，通过分析得出SLA可以通过控制不同组件的执行时间的均值和方差来保证，采用皮尔森相关系数来衡量组件上的执行时间和总的尾延迟的相关性。基于均值、方差、皮尔森相关系数，可以得出每个组件对于总的尾延迟的贡献。最后协调控制器提出了一种基于贡献的阈值化方法来控制每台机器上BE作业的资源分配。它决定BE作业的资源分配，利用资源隔离机制减少LC工作负载和BE任务之间的性能干扰。
1.请求追踪器
为了识别请求的因果路径，使用systemTap在LC组件上收集相关的系统调用。然而，跟踪请求的临时路径并不容易，首先，在一个请求处理中，在用户模式和内核模式之间有几个变换，生成一个深度为数百个系统调用的调用堆栈。需要确定用于正确地派生运行时的事件。其次，虽然systemTap可以跟踪请求的系统调用，但它也捕获由其他不相关进程生成的大量系统调用，如何过滤不相关事件是有挑战性的。第三，请求可能在不同的时间和机器上调用系统调用，如何从不同时间和机器的系统调用中提取因果路径是另一个挑战。
为了获得组件的执行时间，在每个LC组件中记录4个活动事件:syscall_accept表示接收请求，tcp_sendmsg表示数据包的发送，tcp_rcvmsg表示数据包的接收，syscall_close表示请求调用的结束。将它们分别表示为ACCPET、RECV、SEND和CLOSE。根据不相关进程的进程pid过滤掉由它们产生的噪声系统调用。组件中事件之间的因果关系是使用它们的线程 tid标识的，因为请求中的事件共享相同的tid。对于组件之间的因果关系，发现SEND和RECV 之间的映射使用它们的IP地址、端口号和pid。
规定
Figure BDA0002408203180000061
(或
Figure BDA0002408203180000062
)代表节点k上的发送或接受事件，并且i,j代表从节点i到j的数据流。在通过systemTap采集到各个组件的
Figure BDA0002408203180000063
或
Figure BDA0002408203180000064
后，可以计算得出组件i上的执行时间Ti以及组件i和组件j之间的通信时间T(i,j)。
2.贡献分析器
为了决定每个LC组件上可以部署的BE作业的数量，为每个组件定义一个贡献值，以描述其对整体尾延迟的影响。通过这种方式，可以把更多的任务放在对尾延迟贡献小的LC组件上，从而提高资源利用率。
给定由请求跟踪器输出的请求的组件运行时间和网络传输时间，总体响应时间可以计算如下：
Figure BDA0002408203180000065
n代表LC服务的组件的数量，Ti代表组件i的执行时间，并且T(i,i+1)代表组件i与组件i+1 的网络传输时间。
指导定义贡献的三项原则：
(4)具有较高的执行时间的组件对尾延迟的贡献更高。这项原则强调了每个组件的平均执行时间。
(5)具有较高的执行时间的方差的组件对尾延迟的贡献更高。这一原理将尾部延迟与每个组件的波动特征联系起来，因为波动构成了整体延迟的“重尾”。
(6)与尾部延迟高度相关的组件对尾部延迟的贡献更大。如果一个组件的平均运行时间很高，但是在各种请求负载下仍然保持稳定，并且假设所有组件的变化系数也都是稳定的，那么尾延迟就会随着其他组件平均运行时间的增加而增加。在这种情况下，仅仅使用均值和方差系数来得出贡献是不够的。所以，还分析了每个组件的运行时间和尾延迟的相关性，并将其作为贡献的重要因素。
基于以上原则，接下来将展示如何产生组件的贡献。设
Figure BDA0002408203180000066
是组件i的平均执行时间，Ti j是在请求负载强度j下，请求在组件i上的平均执行时间。然后可得
Figure BDA0002408203180000067
m是请求负载强度级别的数量，(假设请求负载从最大可支持负载的10％开始变化，每隔一级增长10％，直至100％，则负载强度级别m为10)请求在组件i上的平均执行时间的贡献度占比如下，
Figure BDA0002408203180000071
使用皮尔森相关系数
Figure BDA0002408203180000072
来评估组件i和尾延迟的99分位数之间的相关性。设
Figure BDA0002408203180000073
是在负载j下的99分位延迟，可得
Figure BDA0002408203180000074
使用归一化的变化系数来得到组件i的变化的贡献如下
Figure BDA0002408203180000075
最后，定义组件i的贡献使用其乘积
Figure BDA0002408203180000076
3.协调控制器
设计了一个协调控制器作为Agent运行在每台布置有LC组件的机器上。控制器将LC组件的请求负载和贡献作为输入，并对BE任务的启动/停止做出决策。
(2)Agent架构
Agent系统架构由一个顶层控制器和四个子控制器构成。顶层控制器对BE任务作出决策，包括load-based决策和slack-based决策。load-based决策启动或停止BE任务是根据当前请求负载，而slack-based决策启动或停止BE任务根据目前的尾延迟与SLA中规定的尾部延迟之间的差距。四个子控制器根据顶级控制器的控制指令增加或减少分配给BE任务的资源。
总控制器的决策状态分为5种，分别是：
(a)允许混部BE，该状态允许利用现有的空闲资源去增加BE作业的数量并增加BE作业使用的资源量。
(b)不允许继续混部BE，该状态不允许继续增加BE作业的数量或者资源量，现有正在运行的BE作业可以保有资源量并继续运行。
(c)减少BE的资源，该状态运行BE作业继续运行，但是需要减少BE作业保有的资源。
(d)暂停所有BE作业，该状态暂停当前所有正在运行的BE作业，停止作业的执行但是 BE作业可以继续保有资源。
(e)清除所有BE作业，该状态立即杀掉所有正在运行的BE作业，并释放BE作业占用的所有资源。
总控制的算法如下：
实时查询目标应用的负载和距离违反SLA的松弛度slack，
Figure BDA0002408203180000077
slack为负，代表违反SLA，否则slack越接近1，代表距离违反SLA越远。分为下面几种情况：
1.当前目标应用slack<0，则进入状态e；
2.当前目标应用slack>0，目标应用负载大于loadLimit，则进入状态d；
3.当前目标应用负载小于loadLimit，且0<slack<slackLimit/2，进入状态c；
4.当前目标应用负载小于loadLimit，且slackLimit/2<slack<slackLimit，进入状态b；
5.当前目标应用负载小于loadLimit，slack>slackLimit，进入状态a；
子控制器的资源控制共分为4种，分别是：
1.CPU核心与LLC通路控制器，控制CPU核心的分配，如果决策状态不为a，则睡眠等待。否则判断当前内存带宽是否超限，超限则减少BE作业的核心数量、LLC通路以及内存带宽。如果当前内存带宽不超限则预判断增加LLC通路和CPU核心数量是否导致内存带宽超限，否则增加资源给BE作业。
2.CPU核心频率的控制，判断如果计算系统的当前CPU功耗达到TDP的80％且目标应用的运行频率小于额定频率，则降低BE作业的运行频率来提升目标应用的运行频率。
3.memory控制器，监测目标应用的内存使用率，如果超过限制，则分配空闲的资源拓展目标应用的内存容量，如果当前没有空闲内存，则减少BE作业的内存容量来提供给目标应用使用。
4.net控制器，监测目标应用的网络带宽使用，预留给目标应用一部分用于突发情况，之后计算当前可用的空闲带宽提供给BE作业使用。
(2)阈值机制
利用相应LC组件的贡献，独立地推导出每台机器的loadLimit和slackLimit的阈值。因为 LC组件的贡献是不同的，所以LC组件的阈值也不同。
对于loadLimit，阈值负载限制表示允许将BE任务与LC组件一起运行的请求负载上限。使用归一化的变化系数(Vi)来配置这个阈值。选择波动大于平均值的第一个负载点作为 loadLimit。
对于slackLimit，表示允许BE任务增长的slack的下界。如果一个组件对整体延迟的贡献很小LC服务，只需要一个小slackLimit，这样更多的BE任务就可以部署在这台机器上，或者子控制器可以分配更多的资源给BE任务。基于LC组件的贡献，设计了一种迭代算法来寻找每台机器的最佳slackLimit。
Algorithm 1：确定BE控制阈值
Figure BDA0002408203180000081
Figure BDA0002408203180000082
CRi是组件i的延迟贡献比
curLimit＝0.9；//init curLimit
minLimit＝0；//init minLimit
SLA_violation_num＝0；//SLA违反次数
While(SLA_violation_num＝＝0&&(curLimit-minLimit)<0.1){
curLimit-＝0.1*IncreRate；//不同组件以不同的速度减少该值，单步精度＝0.1
/**
*Run_system for a while...
**/
SLA_violation_num＝SLA_evaluation()；//运行系统一段时间评估效果
If(SLA_violation_num>0){//如果发生了打破SLA的事件
minLimit＝curLimit；//改变limit值的下界
curLimit＝Record.getLastLimit()；//后退1步
}else{
Record.add(curLimit)；//记录当前的limit值
}
}
return curLimit；
以下结合附图及较佳实施例，对依据本发明提供的具体实施方式、结构、特征及其功效， 详细说明如下：
1.请求追踪器
如图3所示，一条电子商务网站的访问的抽象调用路径，Client向
Figure BDA0002408203180000091
发送一个请求，haproxy收到请求，并记录为事件
Figure BDA0002408203180000092
经过处理后，haproxy发送一条消息调用tomcat 上的函数，这个远程调用在haproxy上生成一个发送事件
Figure BDA0002408203180000093
和一个接受事件
Figure BDA0002408203180000094
这个过程持续递归的进行直到client收到响应以及事件
Figure BDA0002408203180000095
和
Figure BDA0002408203180000096
产生。
在同一个组件上捕获的事件，比如集合
Figure BDA0002408203180000097
表示haproxy上发生的四个事件, 可以算出haproxy上的执行时间
Figure BDA0002408203180000098
同理，可以算出haproxy和tomcat间的通信时间
Figure BDA0002408203180000099
且T(Haproxy,Tomcat)是精确的，因为它不依赖组件间的时钟同步性。
2.贡献分析器
先算出各个组件的
Figure BDA00024082031800000910
Figure BDA00024082031800000911
是组件i的平均执行时间，Ti j是组件i在负载j下的执行时间
Figure BDA00024082031800000912
m是请求负载强度级别的数量，
然后算出各个组件的贡献pi，通过组件i的平均运行时间得出贡献如下，
Figure BDA0002408203180000101
算出各个组件对应的皮尔森相关系数
Figure BDA0002408203180000102
Figure BDA0002408203180000103
是在负载j下的99分位延迟，
Figure BDA0002408203180000104
算出各个组件对应的归一化的变化系数Vi，使用归一化的变化系数来得到组件i的变化的贡献
Figure BDA0002408203180000105
最后，计算各个组件的贡献Ci，定义组件i的贡献使用其乘积
Figure BDA0002408203180000106
3.协调控制器
先利用相应LC组件的贡献，独立地推导出每台机器的loadLimit和slackLimit的阈值。
对于loadLimit，使用归一化的变化系数来求得这个阈值，选择波动大于平均值的第一个负载点作为loadLimit。
如图6所示，对于电商网站的mysql组件，选取loadLimit＝76％,意味着当mysql上的负载超过76％时，开始暂停mysql机器上的BE任务，对于tomcat，loadLimit为87％。
对于slackLimit，使用算法Algorithm 1，找到每台机器对应的slackLimit，在实验中，最好的slackLimit对于mysql和tomcat是0.078和0.032，对于mysql和amoeba是0.347和0.04，所以相对于mysql组件，可以在amoeba,tomcat和haproxy上部署更多的BE任务。
然后，在得到slackLimit和loadLimit后，顶层控制器可以根据控制算法控制管理BE任务，四个子控制器根据顶级控制器的控制指令增加或减少分配给BE任务的资源。
以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (4)

1.一种基于服务组件级的细粒度云资源管控系统，其特征是，包括请求追踪器、贡献分析器、协调控制器，请求追踪器会解析出服务访问的路径，并且得出其在每一个组件上的运行时间；然后，贡献分析器采用皮尔森相关系数来衡量组件上的执行时间和总的尾延迟的相关性，基于均值、方差、皮尔森相关系数，得出每个组件对于总的尾延迟的贡献，其中，指导定义贡献的三项原则：
(1)具有较高的执行时间的组件对尾延迟的贡献更高，这项原则强调了每个组件的平均执行时间；
(2)具有较高的执行时间的方差的组件对尾延迟的贡献更高；
(3)与尾部延迟高度相关的组件对尾部延迟的贡献更大；
基于以上原则，接下来将展示如何计算组件的贡献，设
Figure FDA0003560185670000011
是请求在组件i上的平均执行时间，Ti k表示在负载级别k下，请求在组件i上的平均执行时间，然后得到：
Figure FDA0003560185670000012
m是请求负载强度级别的数量，组件i上的请求平均执行时间在所有组件中的占比pi表示如下，
Figure FDA0003560185670000013
使用皮尔森相关系数
Figure FDA0003560185670000014
来评估组件i和应用整体尾延迟的99分位数之间的相关性，设
Figure FDA0003560185670000015
是在负载j下的应用99分位延迟，得到：
Figure FDA0003560185670000016
使用归一化的变化系数来得到组件i的变化的贡献如下
Figure FDA0003560185670000017
最后，定义组件i的贡献使用其乘积
Figure FDA0003560185670000018
最后协调控制器采用基于贡献的阈值化方法来控制每台机器上尽力批处理服务BE作业的资源分配。
2.如权利要求1所述的基于服务组件级的细粒度云资源管控系统，其特征是，请求追踪器中，为了获得组件的执行时间，在每个延迟敏感服务LC组件中记录4个活动事件:syscall_accept表示接收请求，tcp_sendmsg表示数据包的发送，tcp_rcvmsg表示数据包的接收，syscall_close表示请求调用的结束，将它们分别表示为接受连接ACCPET、接收RECV、发送SEND和关闭连接CLOSE四种事件；根据不相关进程的进程控制符pid(ProcessIdentifier)过滤掉由它们产生的噪声系统调用，组件中事件之间的因果关系是使用它们的线程tid标识的，因为请求中的事件共享相同的tid，对于组件之间的因果关系，SEND和RECV之间的映射使用它们的IP地址、端口号和pid；
规定
Figure FDA0003560185670000021
或
Figure FDA0003560185670000022
代表节点h上的发送或接受事件，并且i,j代表从节点i到j的数据流，在通过systemTap采集到各个组件的
Figure FDA0003560185670000023
或
Figure FDA0003560185670000024
后，可以计算得出组件i上的请求执行时间Ti以及组件i和组件j之间的通信时间T(i,j)；
贡献分析器中，为了决定每个LC组件上可以部署的BE作业的数量，为每个组件定义一个贡献值，以描述其对整体尾延迟的影响，给定由请求跟踪器输出的请求的组件运行时间和网络传输时间，总体响应时间计算如下：
Figure FDA0003560185670000025
n代表LC服务的组件的数量，Ti代表一个请求在组件i上的执行时间，并且T(i,i+1)代表组件i与组件i+1的网络传输时间。
3.如权利要求1所述的基于服务组件级的细粒度云资源管控系统，其特征是，协调控制器中将LC组件的请求负载和贡献作为输入，并对BE任务的启动/停止做出决策，详细步骤如下：
(1)Agent架构
Agent系统架构由一个顶层控制器和四个子控制器构成，顶层控制器对BE任务作出决策，包括load-based决策和slack-based决策，load-based决策启动或停止BE任务是根据当前请求负载，而slack-based决策启动或停止BE任务根据目前的尾延迟与SLA中规定的尾部延迟之间的差距，CPU核心与LLC通路控制器、CPU核心频率的控制器、内存(memory)控制器和网络带宽(net)控制器，4个子控制器根据顶级控制器的控制指令增加或减少分配给BE任务的资源；
总控制器的决策状态分为5种，分别是：
(a)允许混部BE，该状态允许利用现有的空闲资源去增加BE作业的数量并增加BE作业使用的资源量；
(b)不允许继续混部BE，该状态不允许继续增加BE作业的数量或者资源量，现有正在运行的BE作业可以保有资源量并继续运行；
(c)减少BE的资源，该状态运行BE作业继续运行，但是需要减少BE作业保有的资源；
(d)暂停所有BE作业，该状态暂停当前所有正在运行的BE作业，停止作业的执行但是BE作业可以继续保有资源；
(e)清除所有BE作业，该状态立即杀掉所有正在运行的BE作业，并释放BE作业占用的所有资源；
总控制的算法如下：
实时查询目标应用的负载和距离违反SLA的松弛度slack，
Figure FDA0003560185670000031
slack为负，代表违反SLA，否则slack越接近1，代表距离违反SLA越远，分为下面几种情况：
1)当前目标应用slack<0，则进入状态e；
2)当前目标应用slack>0，目标应用负载大于loadLimit，则进入状态d；
3)当前目标应用负载小于loadLimit，且0<slack<slackLimit/2，进入状态c；
4)当前目标应用负载小于loadLimit，且slackLimit/2<slack<slackLimit，进入状态b；
5)当前目标应用负载小于loadLimit，slack>slackLimit，进入状态a；
(2)阈值机制
利用相应LC组件的贡献，独立地推导出每台机器的loadLimit和slackLimit的阈值；
对于loadLimit，阈值负载限制表示允许将BE任务与LC组件一起运行的请求负载上限，使用归一化的变化系数(Vi)来配置这个阈值，选择波动大于平均值的第一个负载点作为loadLimit；
对于slackLimit，表示允许BE任务增长的slack的下界，如果一个组件对整体延迟的贡献很小LC服务，只需要一个较小的slackLimit，这样更多的BE任务就可以部署在这台机器上，或者子控制器可以分配更多的资源给BE任务，基于LC组件的贡献，采用迭代算法来寻找每台机器的最佳slackLimit值。
4.如权利要求1所述的基于服务组件级的细粒度云资源管控系统，其特征是，子控制器的资源控制共分为4种，分别是：
1)CPU核心与LLC通路控制器，控制CPU核心的分配，如果决策状态不为a，则睡眠等待，否则判断当前内存带宽是否超限，超限则减少BE作业的核心数量、LLC通路以及内存带宽，如果当前内存带宽不超限则预判断增加LLC通路和CPU核心数量是否导致内存带宽超限，否则增加资源给BE作业；
2)CPU核心频率的控制，判断如果计算系统的当前CPU功耗达到散热设计功耗TDP(Thermal Design Power)的80％且目标应用的运行频率小于额定频率，则降低BE作业的运行频率来提升目标应用的运行频率；
3)memory控制器，监测目标应用的内存使用率，如果超过限制，则分配空闲的资源拓展目标应用的内存容量，如果当前没有空闲内存，则减少BE作业的内存容量来提供给目标应用使用；
4)net控制器，监测目标应用的网络带宽使用，预留给目标应用一部分用于突发情况，之后计算当前可用的空闲带宽提供给BE作业使用。
CN202010168157.0A 2020-03-11 2020-03-11 基于服务组件级的细粒度云资源管控系统和方法 Active CN111625347B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010168157.0A CN111625347B (zh) 2020-03-11 2020-03-11 基于服务组件级的细粒度云资源管控系统和方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010168157.0A CN111625347B (zh) 2020-03-11 2020-03-11 基于服务组件级的细粒度云资源管控系统和方法

Publications (2)

Publication Number Publication Date
CN111625347A CN111625347A (zh) 2020-09-04
CN111625347B true CN111625347B (zh) 2022-06-17

Family

ID=72271734

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010168157.0A Active CN111625347B (zh) 2020-03-11 2020-03-11 基于服务组件级的细粒度云资源管控系统和方法

Country Status (1)

Country Link
CN (1) CN111625347B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113094235B (zh) * 2021-04-14 2023-03-10 天津大学 一种尾延迟异常云审计系统及方法
CN114422492B (zh) * 2022-01-17 2023-12-12 星环信息科技(上海)股份有限公司 一种请求转发方法、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101515883A (zh) * 2008-02-18 2009-08-26 华为技术有限公司 资源分配请求和分配方法及系统、光网络和光线路终端
CN108574600A (zh) * 2018-03-20 2018-09-25 北京航空航天大学 云计算服务器的功耗和资源竞争协同控制的服务质量保障方法
CN109039954A (zh) * 2018-07-25 2018-12-18 广东石油化工学院 多租户容器云平台虚拟计算资源自适应调度方法及系统
CN109947619A (zh) * 2019-03-05 2019-06-28 上海交通大学 基于服务质量感知提高吞吐量的多资源管理系统及服务器

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140229608A1 (en) * 2013-02-14 2014-08-14 Alcatel-Lucent Canada Inc. Parsimonious monitoring of service latency characteristics

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101515883A (zh) * 2008-02-18 2009-08-26 华为技术有限公司 资源分配请求和分配方法及系统、光网络和光线路终端
CN108574600A (zh) * 2018-03-20 2018-09-25 北京航空航天大学 云计算服务器的功耗和资源竞争协同控制的服务质量保障方法
CN109039954A (zh) * 2018-07-25 2018-12-18 广东石油化工学院 多租户容器云平台虚拟计算资源自适应调度方法及系统
CN109947619A (zh) * 2019-03-05 2019-06-28 上海交通大学 基于服务质量感知提高吞吐量的多资源管理系统及服务器

Also Published As

Publication number Publication date
CN111625347A (zh) 2020-09-04

Similar Documents

Publication Publication Date Title
US8869160B2 (en) Goal oriented performance management of workload utilizing accelerators
Thinakaran et al. Phoenix: A constraint-aware scheduler for heterogeneous datacenters
US8701118B2 (en) Adjusting thread priority to optimize computer system performance and the utilization of computer system resources
US20080271030A1 (en) Kernel-Based Workload Management
CN109564528B (zh) 分布式计算中计算资源分配的系统和方法
CN109947619B (zh) 基于服务质量感知提高吞吐量的多资源管理系统及服务器
CN111625347B (zh) 基于服务组件级的细粒度云资源管控系统和方法
US11438271B2 (en) Method, electronic device and computer program product of load balancing
US20130055283A1 (en) Workload Performance Control
Wang et al. An adaptive model-free resource and power management approach for multi-tier cloud environments
El Khoury et al. Energy-aware placement and scheduling of network traffic flows with deadlines on virtual network functions
WO2011076486A1 (en) A method and system for dynamic workload allocation in a computing center which optimizes the overall energy consumption
Dimopoulos et al. Justice: A deadline-aware, fair-share resource allocator for implementing multi-analytics
US20180316626A1 (en) Guided Optimistic Resource Scheduling
Saha et al. Exploring the fairness and resource distribution in an apache mesos environment
Zhang et al. Zeus: Improving resource efficiency via workload colocation for massive kubernetes clusters
Björkqvist et al. Cost-driven service provisioning in hybrid clouds
CN113505084A (zh) 基于访存和性能建模的内存资源动态调控方法及系统
Yazdanov et al. EHadoop: Network I/O aware scheduler for elastic MapReduce cluster
Hassan et al. Efficient resource scheduling for big data processing in cloud platform
Tesfatsion et al. PerfGreen: performance and energy aware resource provisioning for heterogeneous clouds
Yau et al. Adaptive resource allocation for service-based systems
CN109144664B (zh) 一种基于用户服务质量需求差异的虚拟机动态迁移方法
Nagar et al. Class-based prioritized resource control in Linux
Zabolotnyi et al. Profiling-based task scheduling for factory-worker applications in infrastructure-as-a-service clouds

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant