CN112367349B - Method and system for collaborative optimization of cloud operator energy consumption and user overhead - Google Patents

Method and system for collaborative optimization of cloud operator energy consumption and user overhead Download PDF

Info

Publication number
CN112367349B
CN112367349B CN202011023821.9A CN202011023821A CN112367349B CN 112367349 B CN112367349 B CN 112367349B CN 202011023821 A CN202011023821 A CN 202011023821A CN 112367349 B CN112367349 B CN 112367349B
Authority
CN
China
Prior art keywords
module
task
user
resource
resources
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
CN202011023821.9A
Other languages
Chinese (zh)
Other versions
CN112367349A (en
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.)
Hangzhou Innovation Research Institute of Beihang University
Original Assignee
Hangzhou Innovation Research Institute of Beihang 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 Hangzhou Innovation Research Institute of Beihang University filed Critical Hangzhou Innovation Research Institute of Beihang University
Priority to CN202011023821.9A priority Critical patent/CN112367349B/en
Publication of CN112367349A publication Critical patent/CN112367349A/en
Application granted granted Critical
Publication of CN112367349B publication Critical patent/CN112367349B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • 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/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0611—Request for offers or quotes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Abstract

The invention discloses a method and a system for collaborative optimization of cloud operator energy consumption and user overhead. The method aims at the problems that in the current cloud data center, the average resource utilization rate is not high, information between operators of a PaaS layer and operators of an IaaS layer are not intercommunicated, and double waste of resources and energy consumption is caused. The system of the invention is provided with a PB module on a PaaS layer and is used for negotiation between PaaS and IaaS. The PB module applies for resources to a plurality of IaaS layer operators and sends a plurality of request schemes according to the task type and the resource requirement corresponding to the task, and the IB module set by the IaaS layer operators returns reference quotations of different request schemes according to the resource requirement and the task type for the PB module to sort and recommend to the user; on the other hand, the method can provide different flexible charging schemes, and can reduce the economic expense of the user to the maximum extent according to the requirement of each user.

Description

Method and system for collaborative optimization of cloud operator energy consumption and user overhead
Technical Field
The invention relates to the field of cloud computing, in particular to a method and a system for collaborative optimization of energy consumption overhead of cloud operators and economic overhead of users.
Background
Cloud computing is a business model based on resource sharing, and software and hardware resources shared by service providers can be provided for users according to user requirements through the cloud computing. The cloud computing data center provides software and hardware resources as an infrastructure of cloud computing. In terms of architecture, cloud computing is mainly divided into IaaS, PaaS and SaaS, wherein IaaS (infrastructure as a service), infrastructure is a service, and mainly provides computing resources through virtualization technology, and provides various computing resources such as computing, storage, network and the like for users, and users can use allocated resources but cannot control cloud computing infrastructure; PaaS (platform as a service), a platform is a service, allows a user to deploy a customized application and deploy a modular component provided by a service provider onto a cloud computing infrastructure, the user does not need to manage hardware resources, and the PaaS allows the user to host the application or to control the application by himself; SaaS (software as a service), software is a service, and a service provider directly provides developed application programs to users, the application programs are operated on cloud computing infrastructure, and the users do not need to manage or control the cloud computing infrastructure. For some scenes with certain requirements on resources, since the SaaS cannot provide a flexible and elastic solution according to the user requirements, the user can only select IaaS or SaaS services. In the current cloud data center, the average utilization rate of resources is not high, and from the perspective of a cloud operator, double waste of resources and energy consumption is caused; from a user perspective, the user is burdened with additional economic overhead caused by inefficient resource management by the cloud operator.
On the IaaS layer, the utilization rate of each resource can be clearly seen. In the PaaS layer, a user cannot see the remaining conditions of each resource, usually, the PaaS user directly submits a program to the PaaS layer and pays related fees, and the PaaS layer immediately applies for the corresponding resource to an operator of the IaaS layer and runs a task after the resource is successfully applied. The PaaS layer does not know the resource utilization rate and power consumption of an IaaS layer operator. In addition, there is a base power consumption for each physical machine at the IaaS layer operator. Under the condition that a single physical machine is operated and does not execute any task, the basic power consumption of the physical machine accounts for more than 30% of the peak power consumption. Because the PaaS layer does not know the resource utilization rate of the IaaS layer operator, when the PaaS layer receives a resource application from a user, the PaaS layer directly requests the required resource to the IaaS layer operator. If the operator of the IaaS layer has enough resources corresponding to the task resource requirements of the user, directly reserving the resources and returning the resources to the PaaS layer; if all the running servers of the current IaaS layer operator do not have enough resources corresponding to the task resource requirements of the user, the IaaS layer operator directly starts a new physical machine to run the task. For an IaaS layer operator, a physical machine is started for one task independently, and if no new task arrives for a long time, the basic power consumption of the physical machine consumes a lot of unnecessary energy; from the perspective of the PaaS operator, as long as the user pays the relevant fee, the operator does not pay priority to the waste of resources and energy, and the cost caused by the waste of resources and energy is finally spread to the economic cost of each user. But the user does not know about the utilization rate of each resource of the cloud computing resource which is finally paid for and purchased by the user. Users may buy orders for additional economic expenses due to unreasonable use of cloud operator resources and energy.
Meanwhile, the data center can be accessed to various power supplies, the electricity charge is not uniform according to types and time periods, more price alternatives are provided for users, and a PaaS operator can provide multiple different IaaS operators. Therefore, from the perspective of operators and users, a negotiation mechanism should be proposed to solve the problem caused by the non-information intercommunication between PaaS and IaaS layer operators, and on one hand, it is desirable to improve the utilization rate of various resources to reduce the power consumption of the data center, and at the same time, to reduce the user economic overhead caused by the unreasonable use of resources.
Disclosure of Invention
Aiming at the defects of various technologies at the present stage, the invention provides a method for cooperatively optimizing energy consumption and user overhead of a cloud operator. The technical scheme of the invention is as follows:
the invention firstly discloses a method for collaborative optimization of energy consumption and user overhead of a cloud operator, which comprises the following steps:
s01: a user submits a task application to a PaaS layer;
s02: a PB (PaaS broker) module arranged in a PaaS layer confirms task types submitted by a current user after receiving a task application submitted by the user, wherein the task types comprise a delay sensitive type and a non-delay sensitive type, and the PB module applies resources (including price enquiry) to a plurality of IaaS layer operators according to the task types and resource requirements corresponding to the tasks; for non-delay sensitive tasks, the application of the PB module to each IaaS layer operator includes three request schemes:
1) Direct: directly running according to the resources required by meeting the task SLA and corresponding to the reference economic cost p1；
2) The Delayed: tolerance t in time according to the resources required to meet task SLAwaitRun-in, corresponding to a reference economic cost p2；
3) Mutation: reducing the resource needed by the task by one level, meeting the QoS (Quality of Service) of the user or approaching the QoS, prolonging the running time of the task, and corresponding to the reference price p3；
S03: each IaaS layer operator returns a reference quotation according to the resource demand and the task type; for non-delay sensitive tasks, each IaaS layer operator respectively returns reference prices corresponding to the three schemes, and the reference prices are p in sequence1、p2、p3；
S04: and after each IaaS layer operator returns a quote, the PB module sequences all the quotes fed back by each request scheme, and selects the reference price with the optimal economic cost of each request scheme for the user to select.
As a preferred embodiment of the present invention, in step S02, for the task submitted by the current user, the PB module calculates a resource requirement meeting the SLA (Service-Level Agreement) of the current user<dvcpu,dram>,dvcpuRepresenting the number of CPU cores required for the running of its task, dramRepresenting the amount of memory required for its task.
As a preferred scheme of the present invention, in step S03, for a delay-sensitive task, after receiving a PB resource application, each IaaS layer operator performs resource retrieval in a physical machine owned by the operator and in a running state, and if it is found that there is a physical machine that owns a corresponding resource, one of the physical machines is selected; if no physical machine has the resources meeting the requirements, starting a new physical machine; returning and attaching the economic expense c;
the economic cost c of the user is defined based on the energy supply distribution of the current IaaS layer operator:
c＝α*ebrown+β*egreen
the economic expenditure is the final economic expenditure fed back to the PB module by each IaaS layer operator, alpha and beta are weight coefficients of non-renewable energy sources and renewable energy sources respectively, and ebrownRepresenting a non-renewable energy source, egreenRepresenting a renewable clean energy source (e.g., a photovoltaic energy source).
As a preferred scheme of the present invention, in step S03, for the Direct request scheme, after receiving the PB resource application, each IaaS layer operator performs resource retrieval in the physical machines in the running state owned by the operator, and if it is found that there is a corresponding resource in the physical machine, selects one of the physical machines; if no physical machine has the resources meeting the requirements, starting a new physical machine; returning and attaching the economic cost c;
The economic cost c of the user is defined based on the energy supply distribution of the current IaaS layer operator:
c＝α*ebrown+β*egreen
the economic expenditure is the economic expenditure fed back to the PB module by each IaaS layer operator, alpha and beta are weight coefficients of non-renewable energy and renewable energy respectively, and ebrownRepresenting a non-renewable energy source, egreenRepresenting a renewable clean energy source (e.g., a photovoltaic energy source). Wherein, the economic cost p in the Direct of the scheme1＝c。
As a preferred embodiment of the present invention, in step S03, for the Delayed request scheme, the search is performed at a future time t1(t1≤ccurrent+twait) Whether a task is finished and resources are released in the currently running physical machine or not<dvcpu′,dram′>And simultaneously satisfies:
Mcpu+d′vcpu-|cpuused|≥dvcpu
Mram+d′ram-|ramused|≥dram
calculating a reward function:
cgain＝eprice*pidle*(t1-tcurrent)
wherein e ispriceThe unit time energy cost, namely the electricity cost; p is a radical ofidleThe basic power consumption is the basic power consumption when the physical machine idles; t is tcurrentIs the current time;
return reference price p2，p2＝ρ*(c-cgain)+(1-ρ)*t1Rho is a self-defined weight coefficient; and c is the economic expense corresponding to the Direct request scheme, and if no physical machine meeting the requirement exists, null is returned to the PB module.
As a preferred embodiment of the present invention, in step S03, d is required for the task for the Mutation request schemevcpuThe resource is compressed as follows:
Figure GDA0003601691430000041
after the required resources are compressed, evaluating and predicting whether the SLA required by the user can be achieved; if SLA can be achieved, then find the physical machine m that can meet the resource demand and calculate the economic cost c 3(ii) a If no physical machine meeting the current resource requirement exists, null is returned to the PB module, and the economic expense c is3The definition of (A) is as follows,
Figure GDA0003601691430000042
wherein gamma is a weight coefficient, and after calculation is finished, each IaaS layer operator feeds back a price p3，p3＝(c3,t3) I.e. the task completion is delayed by t in total3Completion of second, t3＝t1+t2Wherein t is1And t in the Delayed request scheme1Similarly, the presentation task may be delayed by t1The second is started to be executed; t is t2Representing the delay due to the resources required for the compression task.
As a preferred embodiment of the present invention, in step S04, after each IaaS layer operator returns the PB module result, the PB module returns the reference price p for all feedbacks1,p2,p3And sorting in an ascending order, and respectively selecting the optimal IaaS service provider price in each item and feeding back the optimal IaaS service provider price to the user.
The invention also discloses a system for collaborative optimization of energy consumption and user overhead of the cloud operator, which comprises a PaaS layer and a plurality of IaaS layer operators;
the PaaS layer comprises a PB module, and the PB module is used for communicating with an IaaS layer operator; the PB module applies for resources from a plurality of PaaS layers according to the task type and the resource requirements corresponding to the task; for a non-delay sensitive task, the application of the PB module to each PaaS layer includes three request schemes:
1) Direct: directly running according to the resources required by meeting the task SLA and correspondingly referring to the economic expense p1；
2) Delayed: tolerating t at a time according to the resources required to satisfy the task SLAwaitInternal operation, corresponding to a reference economic cost p2；
3) Mutation: reducing the resource needed by the task by one level, meeting the QoS of the user or approaching to the QoS, prolonging the running time of the task and corresponding to the reference price p3；
The PB module also sequences quotes fed back by all IaaS layer operators in each request scheme, and selects the IaaS operator reference price with optimal cost in each request scheme for a user to select;
each IaaS layer operator returns a reference quotation according to the resource demand and the task type; for non-delay sensitive tasks, each IaaS layer operator respectively returns reference prices p corresponding to three request schemes1、p2、p3To the PB module.
Compared with the prior art, the invention provides a negotiation mechanism for cooperation of a collaborative cloud infrastructure layer (IaaS) and a cloud platform layer (PaaS), on one hand, the resource utilization rate can be improved, and the energy consumption of a cloud operator can be reduced; on the other hand, different flexible and economical charging schemes can be provided, and the economic expenditure of the user can be reduced to the maximum extent according to the requirement of each user.
In order to optimize the use of resources, the invention can provide different schemes according to the self condition of an IaaS layer operator, a) the performance is prior; b) the performance is guaranteed but has a certain delay, and the delay is within the acceptable range of the user; c) a compromise between performance and price; therefore, on one hand, unnecessary power consumption is reduced on the operator side of the IaaS layer, and more flexible and economic schemes are provided for users on the PaaS layer.
The PaaS layer of the invention asks resource quotations for a plurality of IaaS operators and then feeds back the optimal selection to the user, thereby further reducing the economic expense of the user.
Drawings
FIG. 1 illustrates the response times of an embodiment when processing different numbers of data streams with a vCPU8 and a vCPU 24;
FIG. 2 is a schematic diagram of TS-class task feedback;
fig. 3 is a TNS type task feedback diagram.
Detailed Description
The invention will be further illustrated and described with reference to specific embodiments. The technical features of the embodiments of the present invention can be combined correspondingly without mutual conflict.
In the invention, a PaaS Broker module (PB module for short) is arranged on a PaaS layer as a negotiation module, is positioned on the PaaS layer and is used for negotiation between PaaS and IaaS. Here, there should be a plurality of IaaS layer operator service providers. Each IaaS operator has an IaaS Broker module (IB module for short) for communicating and negotiating with the PB module. The IB module monitors the usage rate of each resource in the cloud computing data center, specifically the usage rate of resources such as a processor, a memory, a network, and a hard disk of each physical machine. Meanwhile, the IB module can see the proportion of real-time supply of each energy in the data center, for example, 70% of the current electric energy is supplied by thermal power, and 30% of the current electric energy is supplied by renewable energy such as solar energy. Different power supply types may have an impact on the final economic overhead.
When the PB module receives a task application submitted by a user, the PB module firstly confirms the task type, namely a delay sensitive type or a non-delay sensitive type, submitted by the current user.
The delay sensitivity type, TS for short, has strict requirements on the completion time of the task.
The non-delay sensitive type is called TNS for short, namely the current task has certain tolerance to the completion time. The user only has a rough requirement on the completion of the task, and usually the task running is finished before the time required by the user.
In other words, the current task can be run with fewer resources and at a lower final price, and the completion time of the current task can also be longer. And if the user has high time tolerance, the PB module analyzes the task resource demand and then sends the resource demand to each IaaS supplier.
When each IaaS supplier receives PaaS application, for TS tasks, the IaaS supplier gives corresponding quotation p according to the current energy supply condition1(ii) a For TNS-like tasks, the IaaS supplier gives energy supply and resource use conditions and prices of three different schemes, namely, no delay p1Resource p is not compressed with a certain delay2With delay and compression of resource p3Three kinds of quotations; and finally feeding back to the PB module.
After the PB module receives the quotations of all IaaS layer operators, the quotations are sorted from low to high to form a triple<p1,p2,p3>And after the user makes a decision, the PB module completes resource reservation to the corresponding IB module according to the decision fed back by the user, and the whole process is ended.
The specific implementation process is described as follows:
tasks submitted by a user to the PB module can be defined as a triplet<jtype,jdescription,twait>. And after receiving the user request, the PB module analyzes the task.
If the task type is delay sensitive (TS), PB (partition board) modeThe block passes through a resource assessment module based on jdescriptionCalculate resource requirements to meet its SLA<dvcpu,dram>,dvcpuRepresenting the number of CPU cores required for the running of its task, dramRepresenting the amount of memory required for its task. PB module directly meets resource requirements<dvcpu,dram>And sending resource demand and quotation applications to all IaaS suppliers, wherein each IaaS supplier can be regarded as being provided with an IaaS Broker module (IB module for short). After each IB module receives the PB module resource application, resource retrieval is carried out in a physical machine which is owned by the IB module and is in a running state, and if the IB module finds that the physical machine has corresponding resources, a physical machine m is selected based on a First creating (FFD) algorithm; if no physical machine has the resources meeting the requirements, starting a new physical machine m, returning and attaching the economic cost c;
The economic cost c is most directly related to the energy supply distribution of the current IaaS service provider:
c＝α*ebrown+β*egreen
this economic overhead is the final economic overhead fed back to the PB by each IB, which also corresponds to the TNS type task p1And (4) the price.
If the type is non-delay-sensitive (TNS), the PB module directly applies for resources from all IaaS suppliers.
Unlike TS type tasks, here the request is divided into three 1.Direct 2.Delayed 3.Mutation
Direct: directly running according to the resources required by meeting the task SLA and correspondingly referring to the economic expense p1；
Delayed: tolerating t at a time according to the resources required to satisfy the task SLAwaitInternal operation, slightly reduced economic cost and corresponding reference economic cost p2；
The Mutation: the resources required by the tasks are reduced by one level, the QoS of the user can be met or the user is close to the QoS, the economic cost is greatly reduced, the task running time is prolonged, and the corresponding reference price p is obtained3。
After each IB module receives the request, it first addresses each IB module owned by the IB moduleSearching the resources of the physical machine, and adding the resources into the list if the physical machine has enough resources to meet the task resource requirement; if none of the computers can meet the resource requirements of the task SLA, a search is first made for future times t 1(t1≤ccurrent+twait) Whether a task is to be finished and resources are released in the currently running physics or not<dvcpu′,dram′>And simultaneously satisfies:
Mcpu+d′vcpu-|cpuused|≥dvcpu
Mram+d′ram-|ramused|≥dram
calculating a reward function:
cgain＝eprice*pidle*(t1-tcurrent)
wherein epriceThe unit time energy cost, namely the electricity cost; p is a radical ofidleThe basic power consumption is the basic power consumption when the physical machine idles; t is tcurrentIs the current time. This scheme corresponds to an economic overhead p2，p2＝ρ*(c-cgain)+(1-ρ)*t1Rho is a self-defined weight coefficient; and c is the economic expense corresponding to the Direct request scheme, and if no physical machine meeting the requirement exists, null is returned to the PB module.
Economic overhead p3：
At present, no physical machine meets the task resource requirement and at the future time t1(t1≤ccurrent+ d), there is no any physical machine to meet the task resource requirement, i.e. d is needed for the taskvcpuResource compression
Figure GDA0003601691430000081
After the resources required by the task are compressed,
and whether the SLA required by the user can be achieved. If the SLA can be achieved, the physical machine m which can meet the resource requirement is found, and new economic cost c is returned to the PB; if there is no physical machine that meets the current resource demand, null is returned to the PB. The new economic overhead c is calculated as follows,
Figure GDA0003601691430000082
where γ is a weighting factor, IaaS providers can set themselves for revenue enhancement, typically 0<Gamma is less than or equal to 2. After the calculation is completed, each IB feeds back three schemes with different prices of PB <p1,p2,p3>。p3Finally expressed as (c)3,t3) I.e. the task completion is delayed by t in total3Completion of second, t3＝t1+t2Wherein t is1And p2Middle t1Similarly, the presentation task may be delayed by t1The second is started to be executed; t is t2Representing the delay due to the resources required by the compressed resource task.
After each IB module returns the PB module result, the PB module feeds back p to all the IB modules1,p2,p3And performing ascending sorting. After each IaaS layer operator returns the PB module result, the PB module returns all the feedback reference prices p1,p2,p3And sorting in an ascending order, and respectively selecting the optimal IaaS service provider price in each item and feeding back the optimal IaaS service provider price to the user. As shown in fig. 1, a real-time processing task is taken as an example, and such a task is computationally intensive and requires high CPU resources. And after the IB module receives the task requirement, the IB module respectively uses the 24vCPU and the 8vCPU to process the same request. Suppose that the maximum data flow of the task is 6, that is, the task needs to access six data flows at the peak value and simultaneously carries out real-time processing, and the task response time and the quality service level (QoS) requirement are within 200 ms.
Note: ds1 is data streaming-1, ds2, ds3, and so on. Fig. 1 shows the response speed for the same task for different vcpus. ds1 shows that vCPU8 and vCPU24 process the same 1 data stream, vCPU8 response time is 100 ms, vCPU24 response speed is 90 ms; ds2 represents the response time for processing two data streams simultaneously with vCPU8 and vCPU24, which is more computationally complex and therefore more computationally dependent. In ds2, vCPU8 and vCPU24 both provide the quality of service (QoS) required by the user; ds3, etc. Among these, in the context of ds4, vCPU8 has a response time of 220 milliseconds, and has been unable to meet the quality of service requirements (QoS) of the current task, while vCPU24 still meets its QoS. Therefore, from ds4 (including ds4), vCPU8 can no longer meet the quality of service requirements of the current task. From the energy consumption perspective, for an IaaS operator whose currently running server can only provide vCPU8 resources, the task can only be postponed until it has enough resources (vCPU24) to meet the user quality service requirement or directly enables a server with enough resources.
FIG. 2 shows that for TS-class tasks, each IB block feeds back the price of the PB block, and the PB block selects the direct feedback user with the lowest economic cost, namely IB _1(118,0)
Fig. 3 is a scheme in which, for TNS-type tasks, a plurality of IB modules feed back to a PaaS layer operator according to their own current resources after receiving a PB module resource request. The price fed back by each IB module consists of three schemes<p1,p2,p3>. For example, IB _1{ (118,0), (82,120), (57,260) }, where IB _1 gives a performance priority IB _1(118,0) to run after 0 seconds, economic cost 118; (82,120) priority quotes for energy consumption, 82 economic cost, 120 runtime after 120 delay; (57,260) is the optimal economic cost, which is only 57, but the whole task can be completed by prolonging 260 seconds, which 260 seconds can be caused by compressing resources, delaying operation or the two together. Prices given by different IaaS layer operators are possibly different, and after the PB module receives quoted prices and other information of all IB modules, the IB _1(118,0) with the shortest waiting time is selected, namely the performance is best and the economic cost is higher; latency is most balanced with economic overhead, from IB _2 (88, 102); the longest latency, optimal economic overhead, IB _3(45,381). Where null is shown to indicate that the IB module is currently unable to provide such services.
The above-mentioned embodiments only express several embodiments of the present invention, and the description thereof is specific and detailed, but not to be understood as limiting the scope of the present invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent should be subject to the appended claims.

Claims (8)

1. A method for collaborative optimization of cloud operator energy consumption and user overhead is characterized by comprising the following steps:
s01: a user submits a task application to a PaaS layer;
s02: after receiving a task application submitted by a user, a PB module arranged in a PaaS layer confirms the task type submitted by the current user, wherein the task type comprises a time delay sensitive type and a non-time delay sensitive type, and the PB module applies for resources to a plurality of IaaS layer operators according to the task type and the resource requirement corresponding to the task; for non-delay sensitive tasks, the application of the PB module to each IaaS layer operator includes three request schemes:
1) direct: directly running according to the resources required by meeting the task SLA and corresponding to the reference price p 1；
2) The Delayed: tolerating t at a time according to the resources required to satisfy the task SLAwaitInternal run, corresponding to reference price p2；
3) Mutation: reducing the resource needed by the task by one level, meeting the QoS of the user or approaching to the QoS, prolonging the running time of the task and corresponding to the reference price p3；
S03: an IB module set by each IaaS layer operator returns a reference quotation according to the resource requirement and the task type; for non-delay sensitive tasks, each IB module respectively returns reference prices p corresponding to three request schemes1、p2、p3；
S04: and after the IB modules set by each IaaS layer operator all return quotes, the PB module sequences all the returned quotes of each request scheme, and selects the reference price with the optimal economic cost of each request scheme for the user to select.
2. The method according to claim 1, wherein in step S02, for the task submitted by the current user, the PB module calculates the resource demand to meet its SLA<dvcpu，dram>，dvcpuRepresenting the number of CPU cores required for the running of its task, dramRepresenting the amount of memory required for its task.
3. The method according to claim 2, wherein in step S03, for the delay-sensitive task, after each IB module receives the PB resource application, it performs resource search in all physical machines owned by the IB module, searches each physical machine, and selects one physical machine if it is found that there is a corresponding resource in the physical machine; if no physical machine has the resources meeting the requirements, starting a new physical machine; returning and attaching the economic cost c;
The economic cost c and the energy supply distribution of the current IaaS layer operator are as follows:
c＝α*ebrown+β*egreen
the economic cost is the final economic cost fed back to the PB module by each IaaS layer operator, alpha and beta are corresponding weight coefficients, ebrownRepresenting a non-renewable energy source, egreenRepresenting a renewable clean energy source.
4. The method according to claim 1, wherein in step S03, for a Direct request scheme, after each IB module receives a PB resource application, resource retrieval is performed in all physical machines owned by the IB module, each physical machine is retrieved, and if a physical machine has a corresponding resource, one physical machine is selected; if no physical machine has the resources meeting the requirements, starting a new physical machine; returning and attaching the economic cost c;
the economic overhead c and the energy supply distribution of the current IaaS layer operator are as follows:
c＝α*ebrown+β*egreen
the economic cost is the final economic cost fed back to the PB module by each IB module, alpha and beta are corresponding weight coefficients, ebrownRepresenting a non-renewable energy source, egreenRepresenting a renewable clean energy source.
5. The method for collaborative optimization of cloud operator energy consumption and user overhead according to claim 1, wherein in step S03, for a Delayed request scheme, a search is performed at a future time t 1(t1≤tcurrent+twait) Whether a task is finished and resources are released in the currently running physical machine or not<dvcpu′，dram′>And simultaneously satisfies:
Mcpu+d′vcpu-|cpuused|≥dvcpu
Mram+d′ram-|ramused|≥dram
calculating a reward function:
cgain＝eprice*pidle*(t1-tcurrent)
wherein M iscpu、MramRespectively corresponding to CPU resources and memory resources of the physical machine; CPU (Central processing Unit)used、ramusedCorresponding to CPU resources and memory resources which are already used by the current physical machine; e.g. of the typepriceThe unit time energy cost, namely the electricity cost; p is a radical ofidleThe basic power consumption is the basic power consumption when the physical machine idles; t is tcurrentIs the current time;
return reference price p2，p2Is represented by (c-c)gain，t1) (ii) a And c is the economic expense corresponding to the Direct request scheme, and if no physical machine meeting the requirement exists, null is returned to the PB module.
6. The method for collaborative optimization of cloud operator energy consumption and user overhead according to claim 1, wherein in step S03, for a Mutation request scheme, tasks are requireddvcpuThe resource is compressed as follows:
Figure FDA0003604345920000021
where the parameter rc represents the resource compression ratio; after the required resources are compressed, evaluating and predicting whether the SLA required by the user can be achieved; if SLA can be reached, then find the physical machines that can meet the resource demand and calculate the economic cost c3(ii) a If no physical machine meeting the current resource requirement exists, null is returned to the PB module, and the economic cost c is saved3The calculation is as follows,
Figure FDA0003604345920000031
Wherein gamma is a weight coefficient, and after calculation is finished, each IaaS layer operator feeds back a reference price p3，p3Finally expressed as (c)3，t3) I.e. the task completion is delayed by t in total3Completion of second, t3＝t1+t2Wherein t is1And t in the Delayed request scheme1Similarly, the presentation task may be delayed by t1The second is started to be executed; t is t2Representing the delay due to the resources required by the compressed resource task.
7. The method for collaborative optimization of cloud operator energy consumption and user overhead according to claim 1, wherein in step S04, after each IB module returns the PB module result, the PB module returns the reference price p for all feedbacks1，p2，p3Sorting is carried out; selecting the optimal reference price of the economic expenditure of each request scheme for the user to select;
wherein for p1Then to select the p with the best economic cost1(ii) a For p2Then according to p2＝ρ*(c-cgain)+(1-ρ)*t1Sorting out p by ascending order2IaaS layer operator with the first ranking, rho is self-definedDefining a weight coefficient; for p3And selecting the IaaS layer operator with the minimum economic expenditure.
8. A system for collaborative optimization of cloud operator energy consumption and user overhead, comprising: a PaaS layer and a plurality of IaaS layer operators;
the PaaS layer comprises a PB module, and the PB module is used for communicating with an IaaS layer operator; the PB module applies for resources to a plurality of PaaS layer operators according to the task type and the resource requirements corresponding to the task; for non-delay sensitive tasks, the application of the PB module to each PaaS layer operator includes three request schemes:
1) Direct: directly running according to the resources required by meeting the task SLA and corresponding to the reference price p1；
2) The Delayed: tolerance t in time according to the resources required to meet task SLAwaitInternal run, corresponding to reference price p2；
3) Mutation: reducing the resource needed by the task by one level, meeting the QoS of the user or approaching to the QoS, prolonging the running time of the task and corresponding to the reference price p3；
The PB module also sequences quoted prices fed back by all IaaS layer operators of each request scheme, and selects a reference price with the optimal economic cost of each request scheme for a user to select;
each IaaS layer operator is provided with an IB module, and the IB module returns reference quotations according to resource requirements and task types in a request scheme sent by the PB module; for non-delay sensitive tasks, the IB module set by each IaaS layer operator respectively returns the reference prices p corresponding to the three request schemes1、p2、p3To the PB module.
CN202011023821.9A 2020-09-25 2020-09-25 Method and system for collaborative optimization of cloud operator energy consumption and user overhead Active CN112367349B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011023821.9A CN112367349B (en) 2020-09-25 2020-09-25 Method and system for collaborative optimization of cloud operator energy consumption and user overhead

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011023821.9A CN112367349B (en) 2020-09-25 2020-09-25 Method and system for collaborative optimization of cloud operator energy consumption and user overhead

Publications (2)

Publication Number Publication Date
CN112367349A CN112367349A (en) 2021-02-12
CN112367349B true CN112367349B (en) 2022-06-28

Family

ID=74508262

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011023821.9A Active CN112367349B (en) 2020-09-25 2020-09-25 Method and system for collaborative optimization of cloud operator energy consumption and user overhead

Country Status (1)

Country Link
CN (1) CN112367349B (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1801808A (en) * 2005-08-24 2006-07-12 华为技术有限公司 Method and system for improving resource utilization efficiency in communication network
CN102640475A (en) * 2009-12-03 2012-08-15 国际商业机器公司 Inter-cloud resource sharing within a cloud computing environment
WO2016195716A1 (en) * 2015-06-05 2016-12-08 Hewlett Packard Enterprise Development Lp Price, completion time, and resource allocation determination for cloud services

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130346227A1 (en) * 2012-06-22 2013-12-26 Microsoft Corporation Performance-Based Pricing for Cloud Computing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1801808A (en) * 2005-08-24 2006-07-12 华为技术有限公司 Method and system for improving resource utilization efficiency in communication network
CN102640475A (en) * 2009-12-03 2012-08-15 国际商业机器公司 Inter-cloud resource sharing within a cloud computing environment
WO2016195716A1 (en) * 2015-06-05 2016-12-08 Hewlett Packard Enterprise Development Lp Price, completion time, and resource allocation determination for cloud services

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
何丽，饶俊，赵富强.《一种基于能耗优化的云计算***任务调度方法》.《计算机工程与应用》.2013, *
赵又霖.《基于服务等级协议的云服务成本计算模型研究》.《信息科技辑》.2017, *
魏艺.《SaaS应用的任务调度与资源配置算法研究》.《信息科技辑》.2019, *

Also Published As

Publication number Publication date
CN112367349A (en) 2021-02-12

Similar Documents

Publication Publication Date Title
Doulamis et al. Fair scheduling algorithms in grids
Gomoluch et al. Market-based Resource Allocation for Grid Computing: A Model and Simulation.
Lee et al. Profit-driven service request scheduling in clouds
US8396757B2 (en) Estimating future grid job costs by classifying grid jobs and storing results of processing grid job microcosms
US7941427B2 (en) Dynamically managing computer resources based on valuations of work items being processed
Mansouri et al. Cost-based job scheduling strategy in cloud computing environments
Stößer et al. Market-based pricing in grids: On strategic manipulation and computational cost
CN110308967A (en) A kind of workflow cost based on mixed cloud-delay optimization method for allocating tasks
US20210294661A1 (en) TASK MANAGEMENT OF LARGE COMPUTING WORKLOADS in A CLOUD SERVICE AGGREGATED FROM DISPARATE, RESOURCE-LIMITED, PRIVATELY CONTROLLED SERVER FARMS
CN109740870B (en) Resource dynamic scheduling method for Web application in cloud computing environment
Thirumalaiselvan et al. A strategic performance of virtual task scheduling in multi cloud environment
CN104994150B (en) A kind of request distribution method of facing cloud Video service
Keivani et al. Task scheduling in cloud computing: A review
Goudarzi et al. Joint customer/provider evolutionary multi-objective utility maximization in cloud data center networks
Chunlin et al. Multi economic agent interaction for optimizing the aggregate utility of grid users in computational grid
Neumann et al. A framework for commercial grids—economic and technical challenges
Yadav et al. Study of task scheduling algorithms in the cloud computing environment: a review
CN112367349B (en) Method and system for collaborative optimization of cloud operator energy consumption and user overhead
Chunlin et al. Multi-queue scheduling of heterogeneous jobs in hybrid geo-distributed cloud environment
CN109213588A (en) A kind of cloud data center Batch Arrival task allocation apparatus, system and method
CN112306642B (en) Workflow scheduling method based on stable matching game theory
Rajeshwari et al. Efficient task scheduling and fair load distribution among federated clouds
CN111882134A (en) Cloud computing service scheduling method, system, medium and electronic device
Rahman et al. Group based resource management and pricing model in cloud computing
Tiwari et al. An efficient hybrid SJF and priority based scheduling of jobs in cloud computing

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