CN110740168A - 云中多租户服务器的自适应方法 - Google Patents

Abstract

本发明公开了一种云中多租户服务器的自适应方法，包括以下步骤：S1：将整个服务器按功能分解为多个组件服务器，通过历史大数据获取各组件服务器的质量参数的均值；S2：计算组件服务器的服务质量的关键性和租户的关键性；S3：根据服务质量关键性和租户关键性来计算各组件服务器的关键性；S4：根据计算得到的组件服务器关键性对各组件服务器进行排名；S5：制定服务冗余策略，确定最终冗余策略。本发明通过采用主动的策略在可能发生故障的组件服务器处进行冗余策略，大幅降低了云中服务器自我修复的开销；进一步提高任务的按时完成率，满足用户对服务质量的需求。

Description

云中多租户服务器的自适应方法

技术领域

本发明涉及云中服务器组建领域，特别是涉及一种云中多租户服务器的自适应方法。

背景技术

近年来，云计算得到快速发展，一些企业和个人经常出现需要在云计算环境下来搭建自己的服务器来完成任务。特别是一些大型公司的服务器，如果在运行过程中出现问题，那都将是不可想象的损失。但是在云中搭建服务器的时候，必须面领着云环境的多变性等一些特性。也就是说，在云中搭建的服务器在运行时，很有可能出现组建服务器故障的情况。所以我们需要投入大量的资金进行云服务器的维护。

云计算环境作为一种新的信息技术平台，通过互联网以计费的方式可以为用户提供海量的且廉价的计算、存储和网络资源。在这种模式下，小企业和个人可以根据当前的实际任务量，动态的从云计算服务上获得所需的软件和硬件资源。

但是云计算环境为用户提供的云服务具有与生俱来的不确定性的特点，使得用户在花费尽可能少的费用的前提下，很难确保任务处理的过程中不出现问题。为满足用户对云环境服务质量的需求，需要对这类组建服务器执行过程中进行冗余策略，分析组建服务器运行时的实际执行状态，从而制定一种高效的云中多租户服务器的自适应的方法。

目前在组件服务器的自适应过程中，存在两个难点：

第一，如果组件服务器的关键性计算不合理，比如各个组件服务器之间的某一些服务质量的数值差距太大，那么就会导致最终的关键性不能合理的代表组件服务器在整个服务器中的重要性。如果各个组件服务器之间的某一些服务质量的数值差距过小，那么就会导致各个组件服务器最终的关键性过于集中而没有区分度，致使最后的自适应方案没有很好的效果。所以组件服务器的关键性计算在服务器的自适应系统中至关重要。

第二，给排名靠前组件服务器优先安排备份服务器，所需要的额外服务器资源的数量，如果增加的服务器资源过多，会造成一些不必要的资源浪费和资金浪费，若增加的服务器资源过少，可能导致该服务器按时完成任务，无法满足用户对服务质量的需求。

发明内容

本发明所要解决的技术问题是提供一种高效的云中多租户服务器的自适应方法，能够提高用户任务的按时完成率，满足用户对服务质量的需求。

为解决上述技术问题，本发明采用的一个技术方案是：提供一种云中多租户服务器的自适应方法，包括以下步骤：

S1：将整个服务器按功能分解为多个组件服务器，通过历史大数据获取各组件服务器的质量参数的均值；

S2：计算组件服务器的服务质量的关键性和租户的关键性；

S3：根据服务质量关键性和租户关键性来计算各组件服务器的关键性；

S4：根据计算得到的组件服务器关键性对各组件服务器进行排名；

S5：制定服务冗余策略，确定最终冗余策略。

在本发明一个较佳实施例中，在步骤S1中，所述组件服务器的质量参数包括积极质量参数、消极质量参数，积极质量参数包括吞吐量、可靠性，消极质量参数包括花销、响应时间。

在本发明一个较佳实施例中，在步骤S2中，计算组件服务器的服务质量时，采用公式(1)：

其中

是组件服务器s_i的第p个服务质量降低后的值；Δq_p表示第p个服务质量每次下降的值；

表示第p个服务质量在第k次下降后整体服务器的值与原始值的比值；

表示第p个服务质量在第k次下降后的值与其原始值的比值；

表示组件服务器s_i的第p个服务质量的关键值。

进一步的，所述组件服务器的服务质量聚合的关键性

为：

其中，

分别是第p个服务质量的最大值和最小值；

是组件服务器s_i的第p个服务质量。

计算租户的关键性cr^T(s_i)时，采用公式(4)：

其中τ(s_i)是组件服务器s_i的租户人数；τ(S)是整个服务器S的租户人数；ε(s_i)是组件服务器s_i平均每秒的请求数量；ε(S)是整个服务器S平均每秒的请求数量。

更进一步的，在步骤S3中，根据组件服务器的服务质量聚合的关键性和租户关键性，计算组件服务器的整体关键性采用公式(5)：

其中，w_t，p是第t个租户对第p个服务质量的偏好值，

是所有租户对第P个服务质量偏好的均值，cr^o(s_i)组件服务器的s_i整体关键性。

在本发明一个较佳实施例中，在步骤S5中，在制定冗余策略时，优先考虑排名靠前的组件服务器，即给与更多的备选服务器，具体过程包括以下步骤：

S5.1：当故障出现时，采用顺序的方式来换服务器替代原本的服务器，即每次只有一个服务器处理问题，当出现问题时就换下一个服务器；

S5.2：对备选服务器进行排名，即服务器性能更好的排在前面；

S5.3：采用整数规划的方式对目标进行优化；

S5.4：通过增加服务器资源，在任务完成后统计任务的完成成功率情况。

本发明的有益效果是：本发明通过计算组件服务器的关键性，提前预测服务器在运行时可能会发生延迟的组件服务器，根据以往的一些情况，判断后期执行过程是否会有延迟，若有延迟，根据预测的延迟时间大小，在活动结束前的一段时间内，增加资源，减少过多延迟对整个并行业务流程运行造成的影响，进一步提高任务的按时完成率，满足用户对服务质量的需求；

相比于目前已有的云中服务器自适应的方法，本发明能满足一定的服务质量，通过采用主动的策略在可能发生故障的组件服务器处进行冗余策略，大幅降低了云中服务器自我修复的开销；此外，按时完成率也能达到用户的要求。

附图说明

图1是本发明云中多租户服务器的自适应方法的流程图；

图2是不同活动规模的均值与检测点n值的关系示意图；

图3为检测点位置准确性分析结果示意图；

图4为异常处理后结果示意图。

具体实施方式

下面结合附图对本发明的较佳实施例进行详细阐述，以使本发明的优点和特征能更易于被本领域技术人员理解，从而对本发明的保护范围做出更为清楚明确的界定。

为表述清楚明确，下面对本发明涉及的技术术语进行解释：

组件服务器：由云服务商提供的服务器，可以处理各种不同的任务，各个服务器之间具有性能和价格的差异性。

云中服务器：一个由多个组件服务器组建起来的服务器，用于处理客户完整的任务。

执行路径：即从开始的组件服务器到结束的组件服务器的一条路径。不包含选择分支和并行结构，一个组件服务器可以属于多个执行路径。

执行计划：由一个或者多个执行路径按照选择分支或并行结构组成，包含并行结构，用于完成一个具体的任务。一个组件服务器可以属于多个执行计划。

多租户服务器任务：一个用于服务大量用户的服务器的任务，由于用户之间有不同的偏好，服务器需要结合所有人的偏好来决定各个服务质量的重要性。

请参阅图1，本发明实施例包括：

一种云中多租户服务器的自适应方法，包括以下步骤：

S1：将整个服务器按功能分解为多个组件服务器，通过历史大数据获取各组件服务器的质量参数的均值；

其中，所述组件服务器的质量参数包括积极质量参数、消极质量参数，积极质量参数：该服务质量的数值越大，服务器的性能越好，例如：吞吐量和可靠性等；消极质量参数：该服务质量的数值越大，服务器的性能越差，例如：花销和响应时间等。

对于每个组件服务器，各个服务质量均值大小和租用价格可以很好的反应出每个组件服务器的情况。通过对每个组建服务器的服务质量的均值和整个服务器的均值之间的差值进行比较，并对规模不等的用户数量进行试验，发现差值大小随着选取活动数量的增多而不断变小，且在选取的活动数量达到某一值时逐渐趋于稳定。

S2：计算组件服务器的服务质量的关键性和租户的关键性；

S3：根据服务质量关键性和租户关键性来计算各组件服务器的关键性；

根据服务器的具体任务，整个服务器可以看做是多个组件服务器组成的有向无环图。在这个有向无环图里面包含着选择结构和并行结构，在计算组件服务器关键性的时候必须解决这两个结构对于服务器整体性能的不确定性的问题。下面对S2和S3的具体过程进行详细描述：

(1.1)分步骤地降低组件服务器的某一个性能，观察每次降低之后对整体服务器的影响程度。将每次降低的组件服务器的某一性能的值与整体下降值的比值进行平均，从而求得该组件服务器的某个服务质量的值

其中

是组件服务器s_i的第p个服务质量降低后的值；Δq_p表示第p个服务质量每次下降的值；

表示第p个服务质量在第k次下降后整体服务器的值与原始值的比值；

表示第p个服务质量在第k次下降后的值与其原始值的比值；

表示组件服务器s_i的第p个服务质量的关键值。

这样通过计算每个组件服务器对于整体服务器的影响，很好地解决了有向无环图里面的选择和并行结构对服务器性能产生的不确定影响。

(1.2)在服务器运行时，不是所有的用户所需要完成的任务都会用到每个组件服务器，就具体单个用户来说，该用户所需要完成的任务只需要其中一部分的组件服务器就能完成。所以统计服务器运行时每个组件服务器被需要的量，从而计算得到租户情况的关键性cr^T(s_i)。

其中τ(s_i)是组件服务器s_i的租户人数；τ(S)是整个服务器S的租户人数；ε(s_i)是组件服务器s_i平均每秒的请求数量；ε(S)是整个服务器S平均每秒的请求数量。

(1.3)在得到了组件服务器的服务质量的值，便可以计算每个组件服务器的各个服务质量在所有组件服务器中的关键性

其中，分别是第p个服务质量的最大值和最小值；

是组件服务器s_i的第p个服务质量。

(1.4)结合用户对服务质量的影响，计算得到组件服务器的关键性。

其中，w_t，p是第t个租户对第p个服务质量的偏好值，是所有租户对第P个服务质量偏好的均值，cr^o(s_i)组件服务器的s_i整体关键性。

S4：根据计算得到的组件服务器关键性cr^o(s_i)对各组件服务器进行排名，其中，组件服务器的排名越靠前，对整个服务器来说这个组件服务器的重要性也就越高；

S5：制定服务冗余策略，确定最终冗余策略。在制定冗余策略时，优先考虑排名靠前的组件服务器，即给与更多的备选服务器。在冗余经费有限的情况下，尽量满足靠前的组件服务器的冗余。

其中，冗余策略生成的具体过程如下：

(2.1)当故障出现时，采用顺序的方式来换服务器替代原本的服务器。即每次只有一个服务器处理问题，当出现问题时就换下一个服务器。

(2.2)对备选服务器进行排名，即服务器性能更好的排在前面。备选服务器的关键性计算类同前面组件服务器的方式，但是不考虑租户的影响，即

(2.3)之后采用整数规划的方式对目标进行优化：

优化的目标函数是

条件函数是s_i，j*cost_i，j<＝budget (8)

y_i+1<＝y_i,i＝1,…,n-1 (9)

(2.5)通过增加服务器资源，在任务完成后统计任务的完成成功率情况。

下面以一实施例来说明该方法，在本实施例中，组件服务器的数量为8个。并且在本例中，只考虑响应时间和吞吐量的不同偏好情形。当然可靠性和花销也是服务器很重要的性能，本实例也少不了可靠性和吞吐量，但是不考虑这两个性能的用户偏好。

(1)各组件服务器的关键性计算的具体过程如下：

分步骤地降低组件服务器的某一个性能，观察每次降低之后对整体服务器的影响程度。将每次降低的组件服务器的某一性能的值与整体下降值的比值进行平均，从而求得该组件服务器的某个服务质量的值；在服务器运行时，不是所有的用户所需要完成的任务都会用到每个组件服务器，统计服务器运行时，每个组件服务器被需要的量得到租户情况的关键性；在得到了组件服务器的服务质量的值，便可以计算每个组件服务器的各个服务质量在所有组件服务器中的关键性。

根据计算得到的组件服务器的关键性如表1所示，对组件服务器进行排名。

表1

组件服务器	cr<sup>o</sup>(s<sub>i</sub>)	排名
			s<sub>1</sub>	0.986	1
s<sub>2</sub>	0.121	7
			s<sub>3</sub>	0.164	6
s<sub>4</sub>	0.654	2
			s<sub>5</sub>	0.564	3
s<sub>6</sub>	0.559	4
			s<sub>7</sub>	0.086	8
s<sub>8</sub>	0.365	5

如表1所示，最后计算得到的数值都在0到1之间，这样可以比较好地看到各组件服务器的重要性。当得到组件服务器的排名之后，就可以进行冗余策略的生成了。

(2)冗余策略生成的具体过程如下：

首先计算各备选服务器中的处理本任务的能力，然后对这些备选服务器进行排名，排名结果如表2所示。

表2

在制定冗余策略时，优选选用性能好的备选服务器来做冗余策略。最后，用优化器来优化本策略，其中每个组件服务器只采用一种冗余方案，例如，组件服务器s₁选定其备选服务器中的前3个作为冗余方案之后，将不会改变这个备选服务器的数量。

为了验证云服务器的自我修复能力是否达标，对服务器的故障率设置为百分之1，并同时改变用于服务器冗余策略的花销从100按照每次100的增加量增加到1600进行实验测试本策略的自我修复的成功率。之后还可以改变对不同服务质量的偏好设定来改变修复之后的不同服务质量的性能比较。在本实验中，分别设置了时延和吞吐量的不同比重来表现。图2是服务器的自我修复的成功率在不同花销的情况下的成功率。可以发现当花销在1400时，成功率达到了99％以上。图3显示了响应时间权重在0.9和0.1的情况下，随着花销的增长，响应时间的延迟和原本执行所需时间的比值。可见当响应时间的权重较大时，响应时间的增加量比权重小的要好很多。图4显示了吞吐量权重在0.9和0.1的情况下，随着花销的增长，吞吐量下降的程度对比情况。可见当吞吐量的权重较大时，吞吐量的下降程度比权重小的要好很多。

根据本发明可以自我修复云中组建的服务器在运行时的异常，在不需要人工检测的情况下自我修补，不仅避免修复期间花费更多的时间，提高服务器的效率，还能保证大多数用户的任务按时完成率，满足用户对服务质量的要求，一定程度上减少了检测点数量多和申请服务器资源数量不合理而带来的成本开销。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (6)

1.一种云中多租户服务器的自适应方法，包括以下步骤：

S1：将整个服务器按功能分解为多个组件服务器，通过历史大数据获取各组件服务器的质量参数的均值；

S2：计算组件服务器的服务质量的关键性和租户的关键性；

S3：根据服务质量关键性和租户关键性来计算各组件服务器的关键性；

S4：根据计算得到的组件服务器关键性对各组件服务器进行排名；

S5：制定服务冗余策略，确定最终冗余策略。

2.根据权利要求1所述的云中多租户服务器的自适应方法，其特征在于，在步骤S1中，所述组件服务器的质量参数包括积极质量参数、消极质量参数，积极质量参数包括吞吐量、可靠性，消极质量参数包括花销、响应时间。

3.根据权利要求1所述的云中多租户服务器的自适应方法，其特征在于，在步骤S2中，计算组件服务器的服务质量

时，采用公式(1)：

其中

是组件服务器s_i的第p个服务质量降低后的值；Δq_p表示第p个服务质量每次下降的值；表示第p个服务质量在第k次下降后整体服务器的值与原始值的比值；

表示第p个服务质量在第k次下降后的值与其原始值的比值；表示组件服务器s_i的第p个服务质量的关键值。

4.根据权利要求3所述的云中多租户服务器的自适应方法，其特征在于，所述组件服务器的服务质量聚合的关键性

为：

其中，

分别是第p个服务质量的最大值和最小值；

是组件服务器s_i的第p个服务质量。

计算租户的关键性cr^T(s_i)时，采用公式(4)：

其中τ(s_i)是组件服务器s_i的租户人数；τ(S)是整个服务器S的租户人数；ε(s_i)是组件服务器s_i平均每秒的请求数量；ε(S)是整个服务器S平均每秒的请求数量。

5.根据权利要求4所述的云中多租户服务器的自适应方法，其特征在于，在步骤S3中，根据组件服务器的服务质量聚合的关键性和租户关键性，计算组件服务器的整体关键性采用公式(5)：

其中，w_t，p是第t个租户对第p个服务质量的偏好值，是所有租户对第P个服务质量偏好的均值，cr^o(s_i)组件服务器的s_i整体关键性。

6.根据权利要求1所述的云中多租户服务器的自适应方法，其特征在于，在步骤S5中，在制定冗余策略时，优先考虑排名靠前的组件服务器，即给与更多的备选服务器，具体过程包括以下步骤：

S5.1：当故障出现时，采用顺序的方式来换服务器替代原本的服务器，即每次只有一个服务器处理问题，当出现问题时就换下一个服务器；

S5.2：对备选服务器进行排名，即服务器性能更好的排在前面；

S5.3：采用整数规划的方式对目标进行优化；

S5.4：通过增加服务器资源，在任务完成后统计任务的完成成功率情况。

Images