Self-configuration of services and servers in data centers

Abstract

A method and apparatus for allocating server resources to services is provided. Multiple services compete for resources on one or more servers and bid for resources. The server allocates resources based on bids according to an auction rule mechanism. The service updates bids for each service and set of services according to a probabilistic dynamic that can approximate a continuous-time Markov chain. The method and apparatus may include multiple separate but interacting agents and may be implemented as self-organization, for example, for a data center. The behavior of the agents may be configured so that the collective behavior achieves proportional fair resource allocation.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 679,318, filed on June 1, 2018, entitled “SELF-CONFIGURATION OF SERVICES AND SERVERS IN A DATA CENTER” and U.S. Non-Provisional Patent Application No. 16 / 145,677, filed on September 28, 2018, entitled “SELF-CONFIGURATION OF SERVICES AND SERVERS IN A DATA CENTER”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present application relates to the field of data center configuration, and more particularly to a method and device for configuring a data center server to provide specific services. Background Art

[0004] A data center is a facility that houses computer system components, such as, but not limited to, computer servers. Computer servers can be used to host multiple services. While some services can be hosted entirely on a single server, it is also possible to distribute the hosting of a service across multiple servers. This is also possible, for example, for server redundancy purposes.

[0005] For large-scale systems involving a large number of servers and / or services, pairing servers with services can become complicated. This complexity can become a problem, especially as service requirements change over time, new services emerge, and existing services terminate. It should be understood that different services may require different resource allocations, and different servers may be able to provide different available resource allocations for services. As services start and stop, the allocation of available resources on servers may become somewhat fragmented and inefficient. Inefficient service placement may cause some server resources to go unused, while new servers need to be added to the pool of available resources. This may lead to increased operating costs (which will be passed on to users of the resources) and inefficient power consumption.

[0006] Therefore, a method and apparatus for selecting a server to host a service is needed to eliminate or alleviate one or more limitations of the prior art.

[0007] This background information is provided to reveal information that the applicant believes may be relevant to the present application. It is not intended, and should not be construed, as an admission that any of the foregoing information constitutes prior art with respect to the present application. Summary of the invention

[0008] The purpose of the embodiments of the present application is to provide a method, device, and system for selecting server resources to host one or more services. Services may also be referred to as applications. Server resources may be located in at least one data center, or may be located in multiple data centers. When selecting server resources to host services, some or all of the services may be hosted on server resources (or prepared to be hosted). The embodiments of the present application are used to realize the self-organization of a data center by automatically and dynamically associating server resources with services in a particular manner. In various embodiments, the resulting self-organization may be considered to have ideal performance according to certain metrics (e.g., proportional fairness metrics).

[0009] The provided method, apparatus, and system can be implemented using one or more computing devices, each computing device managing one or more services, one or more servers, or a combination thereof, for decisions related to resource allocation. Each service can be supported by a service agent that manages the expenditure (spend) or bidding (bid) decision of the service. The service uses bidding to obtain server resources. Each server can also be supported by a server agent that manages the resource allocation decision of the server, and the above-mentioned resource allocation decision is responsive to the expenditure or bidding decision received from the service. The service agent and / or the server agent can be physically or functionally separated or partially or completely integrated together. For example, an agent can be provided by the software configuration of the computing device. Multiple networked computing devices and / or agents can interact with each other to implement the method, apparatus, or system. Some or all computing devices and / or agents can be hosted in the same data center. The computing device or the agent operating thereon operates based on a predetermined set of rules to allocate server resources for hosting services.

[0010] According to one aspect of the present application, a method for associating server resources with services is provided, the method being performed by a computer system for managing services. The method generally includes repeatedly performing the following operations: updating a payout allocation according to a probabilistic transition dynamic; and in response to the update of the payout allocation, communicating one or more changes in a bid amount to a corresponding server in one or more servers; receiving feedback from the one or more servers; and controlling the probabilistic transition dynamic based on the feedback. The payout allocation for a service (indexed as service i) includes one or more bid amounts s ij , each bid amount s ij represents the bid for resources on the corresponding server (indexed as server j) in the one or more servers. The feedback indicates the amount of resources allocated by each corresponding server j in the one or more servers b ij , the resource volume b ij Response to expenditure allocations ijThe service expenditure allocation is also referred to herein as the service status. Alternatively, the feedback may indicate that each corresponding server j in the one or more servers has allocated resource amount b. ij The resource price used when

[0011] In various embodiments, the probabilistic transition dynamics include probabilistically transitioning the expenditure allocation from the current expenditure allocation to a different expenditure allocation (e.g., via a random component) according to a particular transition rate (also referred to simply as a probability). The transition rate from the current expenditure allocation to the different expenditure allocation can be determined by calculation. Specifically, the calculation includes determining a transition rate that satisfies the following conditions: the ratio of the following two has a value given by a particular function as described below: the transition rate from the current expenditure allocation to the different expenditure allocation; and the transition rate from the different expenditure allocation to the current expenditure allocation. It should be understood that the random component can be a pseudo-random component. In addition, the transition rate can be determined using numerical calculations by a processor such as a computer processor.

[0012] In some embodiments, the function is given by a particular term raised to a predetermined power. The numerator of the term corresponds to the total expected amount of resources allocated for hosting service i by all servers in the one or more servers in response to different expenditure allocations. The denominator of the term corresponds to the total amount of resources allocated for hosting service i by all servers in the one or more servers in response to the current expenditure allocation. The total amount of resources allocated for hosting service i can be an estimate.

[0013] In other embodiments, the function is given by multiplying a plurality of values, each value comprising a respective term raised to a respective power. The numerator of each term corresponds to the total expected amount of resources allocated by all servers in one or more servers in response to different expenditure allocations for hosting different specific services i in a plurality of services. The denominator of the term corresponds to the total amount of resources allocated by all servers in one or more servers in response to the current expenditure allocation for hosting different specific services i in a plurality of services. The total amount of resources allocated for hosting services may be an estimate.

[0014] While only one "different" spend allocation is explicitly discussed above, it should be noted that controlling the spend allocation may include probabilistically shifting to one of a plurality of different spend allocations according to a corresponding rate, each rate as described above. It is possible to shift from a given spend allocation to any one of a set of one or more different spend allocations. Once a shift to a different spend allocation is triggered, the process is repeated. Those skilled in the art will recognize that repeating the process may be repeated with the newly shifted spend allocation becoming the new (current) spend allocation.

[0015] Determining the transfer rate may include computationally solving a plurality of dependent equations, each of which is described above.

[0016] The probability transfer dynamics can be basically or roughly corresponding to the probability transfer dynamics of a continuous time Markov chain (Markovchain), wherein the state (i.e., expenditure allocation) transfer occurs randomly according to a specified rate. Conceptually, given the current state of a service agent, it is possible to transfer to a state in a set of one or more potential new states. The expected time until the service agent transfers to each state in these potential new states is given by an exponential probability distribution with a specific rate parameter. The potential new state corresponding to the shortest time among these times is selected as the new state of the Markov chain, and state transfer occurs in this shortest time. Rate parameters that meet the conditions specified above and elsewhere in this article can be generated. For example, these times can be generated by calculation, pseudo-random number generation, or a lookup table. State transfer can be performed by calculation by the service agent. In practice, Poisson splitting and / or Poisson combining can be used and based on the generation of transfer time according to the exponential probability distribution and the weighted random selection of the new state at the generated transfer time to realize probability transfer.

[0017] According to another aspect of the present application, a method for associating server resources with multiple services is provided. The method includes executing the above-mentioned method for associating server resources with the service on behalf of each of the above-mentioned multiple services. In some embodiments, different instances of the above-mentioned method are executed in parallel. Different instances of the method can be executed substantially independently, which is conducive to decentralized solutions. However, since the feedback from the server is based on a combination of bids representing different services, it should be noted that the behavior of different instances of the method (e.g., their transfer rates) are ultimately combined together through server feedback.

[0018] According to another embodiment of the present application, a device for performing operations according to the above method is provided. The device may be a networked computing device or a computing device for implementing one or more service agents thereon. Therefore, an embodiment of the present application provides a device for obtaining server resources for supporting service i. The device includes a computer processor operably coupled to a memory. The device is used to repeatedly perform the following operations: dynamically update an expenditure allocation according to a probabilistic transition, the expenditure allocation including one or more bid amounts s ij , each bid amount s ij Indicating a bid for a resource on a corresponding server j of the one or more servers; and communicating one or more bid amounts s to a corresponding server of the one or more servers in response to an update to the spend allocation ijreceiving feedback from the one or more servers, the feedback indicating the amount of resources b allocated by each corresponding server j in the one or more servers ij , the resource volume b ij Response to expenditure allocations ij and is allocated for hosting service i; and controlling the probability transfer dynamics based on feedback from one or more servers.

[0019] According to another embodiment of the present application, a system including a plurality of the above-mentioned devices is provided, wherein each device implements the operation of one or possibly multiple service agents thereon.

[0020] In various embodiments of the present application, a computing device or management agent uses a predetermined auction-type process to manage the allocation of server resources in response to the allocation of service expenditures. These computing devices or server agents may be included in the apparatus or system described herein. Similarly, actions performed according to one or more such computing devices or server agents may be included in one or more methods described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Other features and advantages of the present application will be apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0022] Figure 1 A diagram showing the interaction of multiple service agents with multiple servers (or server agents) according to an embodiment of the present application is shown.

[0023] Figure 2 The interaction between the service agent and the server according to an embodiment of the present application is shown.

[0024] Figure 3 The operation and functional components of the service according to an embodiment of the present application are shown.

[0025] Figure 4 The operation and functional components of a server according to an illustrative embodiment of the present application are shown.

[0026] Figure 5 A computer device for providing at least one service agent or server agent according to an embodiment of the present application is shown.

[0027] Figure 6 A computer device used as a server according to an embodiment of the present application is shown.

[0028] Figure 7 A portion of a data center including a plurality of computer devices arranged in server racks is shown.

[0029] Figure 8The server manager (ie, server agent) and the service manager (ie, service agent) according to an embodiment of the present application are schematically shown.

[0030] Fig. 9 An example table showing a data center arrangement and examples of state transition dynamics that are allowable by a service agent according to an embodiment of the present application is shown.

[0031] Fig.10 The state space of an embodiment in which two service agents bid for resources on two servers according to an embodiment of the present application is shown.

[0032] Fig.11 Shown according to Fig.10 Equilibrium steady-state probability of a Markov chain of an example embodiment of the invention.

[0033] Fig.12 A method for obtaining server resources for supporting services according to an embodiment of the present application is shown.

[0034] Fig.13 A method for operating a server according to an embodiment of the present application is shown.

[0035] It will be noted that throughout the drawings, like features are identified by like reference numerals. DETAILED DESCRIPTION

[0036] Embodiments of the present application provide a method and apparatus for promoting self-organization of a data center. A server may be a physical server in a data center (or available in a data center) and / or a virtual server entity instantiated on data center resources. The server in the data center provides its resources at a certain price, which can be adjusted according to the auction process. A service agent operates on behalf of the service to select one or more servers on which the service will be instantiated and run. The service agent has a budget and pays for server resources according to the current price (in name or in reality). The server then provides resource allocation to the service that has successfully bid for the resource. The service can be hosted on one or more servers, such as hosting different parts on different servers, or using multiple servers to provide redundancy. Therefore, self-organization is performed by automatically configuring the server to host a service that has successfully bid for its resources. Note that the behavior of the services and servers described herein can be implemented in a single data center, or in multiple data centers, or on multiple resources that are not necessarily accommodated in a physical data center.

[0037] A service may refer to a customer-facing application or an internally supported application. Services include, but are not limited to, web applications, media streaming services, video conferencing services, data caching services, virtualized services for core networks (e.g., 5G networks), cloud-based services, and edge computing applications. Services can be instantiated dynamically, and services can adjust their requirements over time, for example, based on current customer requirements. As described herein, a service agent is a computer or its functional aspects that performs at least operations related to resource allocation on behalf of a service. A service agent can be hosted on a computing resource in a data center. Multiple service agents can be hosted on the same computing resource or on separate computing resources.

[0038] A server may refer to a computer server or a virtual computer server located in a location such as a data center. A server may refer to a collection of resources (e.g., processing resources, communication resources, or memory resources, or a combination thereof). A server may include at least one set of one or more computer processors operably coupled to a memory and a network interface. The term "server" is also used to refer to a server agent, which manages auction-based resource allocation.

[0039] The embodiment of the present application uses Markov approximation (or approximation) method (Markov approximation approach) to provide server resource allocation in a distributed manner. The service agent and the server interact in a manner that can be modeled as a Markov chain according to a predefined set of rules. Markov chain models the combinatorial optimization problem. The transition rate of the Markov chain can be configured so that the probability mass of the steady-state probability distribution of the chain is mainly concentrated on those states that roughly solve the optimization problem. For example, once the service arrives at a state that roughly optimizes the resource allocation problem together, the transition rate of leaving the state may be relatively low. It is worth noting that the resource allocation problem can be regarded as a combinatorial optimization problem rather than a mixed integer / convex optimization problem. This allows Markov approximation techniques to be applied more easily. In some embodiments, the service agent spends most of its time in those states that roughly solve the optimization problem.

[0040] Embodiments of the present application provide a method, an apparatus, and a system, the system comprising one or more servers and one or more service agents, the servers being used to allocate resources according to an auction process; the service agents being used to bid for server resources according to a random process. Because the bidding probability depends on the current resource allocation of the service and the overall impact of the current resource allocation of all services on the server resource price, the random process follows the Markov property. The price of server resources can be calculated in a memoryless manner (i.e., based only on the current bid rather than the bid history). The behavior of the service agent and the server can be configured so that the resulting system behavior corresponds to a Markov chain whose steady-state probability distribution roughly corresponds to the optimal or near-optimal resource allocation. Therefore, a Markov approximation method is used (by the service or the corresponding service agent) to select server resource allocation. The behavior of the server and the service agent can be selected so that a proportional fair resource allocation between services is roughly achieved.

[0041] In various embodiments, the Markov approximation distribution is such that each service agent operates substantially independently. In various embodiments, the service agent estimates the server resource price based on the server reservation price. The service agent may additionally estimate the server resource price based on information received from each server. The service agent may additionally estimate the impact of its resource bid on the server resource price.

[0042] Service Behavior

[0043] As described above, service agents can be used to bid for server resources in a dynamic and probabilistic manner. As a prerequisite for being able to be hosted by a group of servers, services can be associated with service agents that follow the behavior described herein. For example, services can be wrapped in an outer layer that implements service agents. As another example, a set of specifications or published application programming interfaces (application programming interface, API) can be provided to specify how to configure services to implement such service agents. Compliance checks can be performed to ensure that service agents operate as specified. Alternatively, other servers or service agents can be used to detect and punish non-compliant agents.

[0044] Each service may have a specific set of resource requirements. Resource requirements may be constant, or may change over time, for example, in response to customer demand. In a simple implementation, resource requirements may correspond to multiple server resource units. For example, each server resource unit may, for example, represent a predetermined number of processing resources, random access memory, mass storage space, or a combination thereof. In this case, the current resource requirements of each service may be given by a single value. However, it is noted that in a more complex implementation, server resources may be distinguished by type (e.g., processing resources, memory resources, network resources, etc.), by performance (e.g., latency, quality of service (QoS), uptime duty cycle, etc.), or by a combination thereof. In this case, the current resource requirements of each service may be given by multiple values ​​(e.g., vectors), or associated with a more complex resource requirement function. For example, a resource requirement function may be a vector value combination or a weighted combination of different requirements.

[0045] The service agent determines or provides a budget amount S associated with the service. i . The budget amount may be set based on the resource requirements of the service or otherwise. The budget amount may be fixed or may vary over time. The budget amount represents the maximum total number of bid units that a service agent may use to bid for server resources at one time. Optionally, each bid unit represents a temporary or non-temporary payment commitment in a monetary contract. It should be understood that different service agents (each associated with a different service) may have different budget amounts.

[0046] Figure 1 A diagram showing multiple service agents 110, 120, 130 interacting with multiple servers (or server agents) 115, 125, 135 according to an embodiment of the present application is shown. For simplicity, the service agents are also referred to as services. The diagram is a bipartite graph in the sense that services interact directly with servers but not necessarily with other services, and servers interact directly with services but not necessarily with other servers. The interaction can be performed as needed within the computing device or by messaging over a network.

[0047] The following reference Figure 2 describes the interaction between a given service i210 and a given server j220, Figure 2 Shows Figure 1 selected portion of the . Figure 2 The interaction in Figure 1 Note that a service may interact with only one or a limited number of servers at a time, a service may not necessarily interact with every server, and a service may avoid interacting with any server for an extended period of time (usually a limited period of time).

[0048] For more details, refer to Figure 2 , service i is based on a set of service requirements 230 and a budget amount S i 240 determines a spending allocation, which includes bid amounts for resources on one or more servers (including server j). The bid amount of service i for server j is denoted as s ij The bids can be considered as selected from a discrete set, thus supporting combinatorial optimization methods. The sum of all bids submitted by service i at one time is constrained to be less than or equal to the budget amount S i There may also be other constraints, such as a constraint that at least one bid amount must be greater than zero, or a constraint that at least a predetermined number (greater than one) of bid amounts must be greater than zero, or a constraint that at most another predetermined number (greater than one) of bid amounts must be greater than zero. This allows the service to use at least a certain minimum number of servers and / or at most a certain maximum number of servers at a time.

[0049] If server j's bid amount is s ij If the bid amount s has changed relative to the server's previous bid amount, service i communicates this new bid amount 250 to server j. If the bid amount is unchanged, no communication is required. In response to the communication, and if the bid amount s ij 270 . The server may subsequently use this amount of resources to provide 270 the service. This may include configuring these resources to perform computations, storage, communication operations, or a combination thereof to support the service. The amount of resources allocated by the server to support the service is determined by the competitive auctioning dynamic described elsewhere herein. Note that server j may also adjust the amount of resources allocated to support service i in response to other events, such as, but not limited to, changes in the bidding amounts for other services served by server j.

[0050] At certain times, server j may communicate feedback 260 to service i, for example, in response to receiving and processing bid-related communications from service i, in response to a change in the amount of resources that the server has allocated to support service i, or periodically according to a schedule. The feedback may indicate the amount of resources that server j has allocated to support service i. The feedback may additionally or alternatively indicate the resource unit price set by server j. (Note that in some embodiments, the resource allocation can be at least approximately determined from the current bid and resource unit price.) Service i uses this feedback to update (if necessary) its probabilistic shift dynamics to control updates to its spending allocation.

[0051] Figure 3The operation and functional components of the service i310 according to an illustrative embodiment of the present application are shown in detail. Figure 3 Also shown is the communication between service i and one or potentially multiple servers 320. This communication includes as described in reference Figure 2 The bidding 370 and feedback 380 are described. As shown, the communication can be performed via an interface 360 ​​(e.g., a network interface). Figure 3 The service tracks the current state 315, which includes one or more bid amounts s ij The current expenditure allocation of each bid amount represents the current bid for the resource on the corresponding server j in one or more servers. Given the current state, the state transition event generator 350 is used to determine the timing of transitioning to a new state and the new state to be transitioned to. When a state transition occurs, the state transition event generator updates the current state to be equal to the new state.

[0052] The state transition event generator operates according to the probabilistic transition dynamics. The following discussion outlines the probabilistic transition dynamics according to a continuous-time Markov chain. However, it should be readily understood that other probabilistic transition dynamics may also be implemented, such as, but not limited to, a discrete-time Markov chain approximation of a continuous-time Markov chain. State transitions (also referred to as bidding change events) may be roughly generated according to a Poisson process (i.e., an event inter-arrival time has an exponential distribution). Typically, the probabilistic transition dynamics contain random or pseudo-random elements, so that the state transition is (in effect) based in part on random chance. According to an embodiment of the present application, the probabilistic transition dynamics may follow Markov properties, so that the state transition probability or rate depends on the current state and is independent of the past state.

[0053] Given the current state, the state transition event generator determines all possible next states of the expenditure allocation. In various embodiments, the possible (i.e., allowed) next states are limited by a constraint or a combination of constraints. For example, as described above, a constraint may be that the possible next states are limited to the sum of all bid amounts being less than or equal to the budget amount S. istate. As described above, another constraint may be that the possible next states are limited to states where at least a predetermined number (greater than or equal to one) of the bid amounts are greater than zero. As described above, another constraint may be that the possible next states are limited to states where at most a predetermined number of bid amounts are greater than zero. Another constraint may be that the possible next states are limited to states that differ from the current state only in a limited number of bid amounts. That is, the service can only change its bid for a limited number (e.g., one) of servers at a time. Another constraint may be that the difference in bid amounts can only change by a limited amount (e.g., one unit). In one embodiment, a service may change its bid for one server at a time by raising or lowering the bid by a predetermined fixed amount (e.g., one unit).

[0054] In some embodiments, one or more constraints may be relaxed under certain conditions, such as when the current expenditure of a service is below its total budget by at least a predetermined threshold amount, or when the resources allocated to the service are currently below a target level by another predetermined threshold amount. Constraints may also be gradually relaxed based on the difference between the current expenditure of a service and its total budget, or based on the difference between the current resource allocation of the service and its target resource allocation level. For example, for a service that currently has a lower expenditure or resource allocation, the service may be allowed to change its bid amount for a server by more than one unit at a time. Similarly, in this case, the service may be allowed to change its bid amount for multiple servers at a time. Such constraint relaxation may allow a service to quickly approach an optimal resource allocation.

[0055] In certain embodiments, for each possible next state, the state transition event generator can generate the expected transfer time. For the purpose of analysis, these transfer times (can be regarded as time intervals) can be regarded as random, and in various embodiments can actually be generated in a random or pseudo-random manner. The shortest time in the transfer times of these expectations is selected as the time when the state transition event generator will trigger the current state update. Select the new state as the state corresponding to the shortest time in these transfer times. It should be noted that in actual implementation, it may be unnecessary to generate a plurality of expected transfer times and select the shortest transfer time therefrom. On the contrary, as those skilled in the art will readily appreciate, the different calculation processes of the transfer times (or transfer rates) that are equal mathematically can be performed, and the corresponding state is selected.

[0056] In some embodiments, a Poisson process splitting technique or a Poisson process merging technique may be used to generate state transition events at a suitable rate. This may also provide that only one state transition event is generated at a time. For example, rather than generating multiple expected transition times independently and randomly from multiple different exponential distributions, a single transition time may be generated from a total exponential distribution with a rate parameter equal to the sum of the rate parameters of multiple different exponential distributions. A state transition may occur at a time given by the total exponential distribution, and the state to which the transition is made may be randomly selected. For a given state b, the suitable probability of selecting state b is λ b / λ, where λ b is the rate parameter for transitioning to state b, and λ is the rate parameter for the total exponential distribution. Poisson process splitting and Poisson process merging can additionally or alternatively be used to generate state transition events for a group of multiple services. For example, multiple services can coordinate to initiate state transitions at different times, thereby avoiding the situation where there are multiple services trying to change their bids at one time. Poisson splitting and Poisson merging will be readily understood by those skilled in the art.

[0057] In some embodiments, given the current state a, for each possible new state b, the transition rate from state a to state b (denoted as q ab ) are as follows. ba Defined as the transition rate from state b to state a. The transition rate satisfies any of the following ratio conditions:

[0058] or

[0059]

[0060] In equations (1) and (2) above, β is an external or design parameter (e.g., equal to 4 in some embodiments), and the term S may be replaced by a different term i Item b ij represents the (possibly estimated) amount of resources allocated to service i by server j in response to service i bidding according to the current state a. ij represents the (possibly estimated) expected amount of resources that server j will allocate to service i in response to service i bidding according to the new state b. Although equations (1) and (2) specify ratios between transition rates, transition rates that satisfy these ratios can be easily calculated. In addition, the transition rates between multiple states can be calculated by solving a system of equations, each equation being given according to equation (1) or (2) and representing a different pair of states. Solving the equation or system of equations can be performed numerically by a computer. Note that the term S in the exponent of equation (1) or (2) is i can be represented by the more general term Z i Instead, in some embodiments, Z iCan be equal to S i .

[0061] In other words, equation (1) shows that we can use the equation including raising to the power βS i The ratio of the function evaluation transfer rate of a given term q ab / q ba , where the given term is as follows. The numerator of the term corresponds to the total expected amount of resources allocated by all servers in the one or more servers in response to different expenditure allocations for hosting service i. The denominator of the term corresponds to the total amount of resources allocated by all servers in the one or more servers in response to the current expenditure allocation for hosting service i. It should be understood that the term βS i It can be expressed more generally as βZ i .

[0062] In other words, equation (2) indicates that the ratio of the transfer rates q can be evaluated using the function ab / q ba , where state a is the current spending allocation and state b is a different spending allocation. This function is given by multiplying multiple values. Each of the multiple values ​​is raised to the corresponding power βS i The numerator of each term corresponds to the total expected amount of resources allocated by all servers in the one or more servers in response to different expenditure allocations for hosting different specific services i in the multiple services. The denominator of the term corresponds to the total amount of resources allocated by all servers in the one or more servers in response to the current expenditure allocation for hosting different specific services i in the multiple services. It should be understood that the term βS i It can be expressed more generally as βZ i .

[0063] The expected transition time from the current state a to each possible new state b is calculated according to an exponential probability distribution (conceptually or practically), where the rate parameter of the exponential probability distribution satisfies one of the above two rate conditions given by equations (1) and (2). The rate parameter of the exponential distribution basically corresponds to the transition rate of the service agent.

[0064] Likewise Figure 3 As shown, the service may track applicable state transition rates or related data as state transition rate parameters 340 and use them to notify the state transition event generator. The state transition rate parameters may be updated based on feedback received from the server via the service's interface 360. The state transition rate may be an estimate of a theoretically specified transition rate. For example, each server j may notify the service of the amount of resources b allocated to service i by server j in response to service i's current bid. ij. Server j may update this feedback information over time. In some embodiments, each server j may also inform the service of the amount of resources that server j has allocated to other competing services, for example, in response to the current bids of those other competing services. Server j may additionally or alternatively inform the service of its current resource prices. The information received from each server j is not necessarily up to date.

[0065] It should be noted here that the total amount of resources allocated to service i is given by Given.

[0066] Likewise Figure 3 As shown, the state transition event generator 350 notifies the interface 360 ​​of the state transition when or before the state transition occurs. The new state differs from the previous state in that one or more bid amounts have changed. The interface is used to notify the appropriate server 320 of these bid amount changes, for example, through a message transmitted via a communication network.

[0067] In various embodiments, the service state 315 is initialized so that at least one bid is non-zero. In various embodiments, different services are configured to update their state at different times, or the server is configured to treat updates from different services as occurring at different times.

[0068] Estimation of transfer rate parameters

[0069] Note that the service transfer rate depends on the resource allocation parameter b ij and b′ ij The values ​​of these parameters are not necessarily fully known to the service. For example, the amount of resources (or the unit price of resources) allocated by server j to service i may change due to a change in the bid from another server or due to an external event (such as a complete or partial server outage). In addition, the resource allocation or price adjustment reaction of server j to expected future bids is not necessarily fully known.

[0070] Therefore, the present embodiment includes estimating such parameter b ij and b′ ij The current value of a server resource (or a corresponding resource price), or even an estimated future value of such a parameter. In various embodiments, the server resource allocation and bidding are associated by the server's current resource price, as given in equation (6), which will be described below. The server resource price can be further given according to equations (3) or (4), which will also be described below. Therefore, parameter estimation may include estimating the server resource price and then deriving the required parameters using the above equations. Each service can be used to independently estimate parameters (e.g., b ij and b′ ij (or the corresponding resource price)).

[0071] In some embodiments, service i may estimate the resource price of server j according to the following rules. If the service is not currently using any resources on the server, the estimated resource price may be set equal to the server's minimum resource (reservation) price. Otherwise, the service may set the estimated resource price to the price it currently pays for the resource (e.g., based on the latest feedback received from the server). Given the latest bid and feedback information, this price may be calculated by equation (6). This may be referred to as a "naive" price estimate.

[0072] In some embodiments, the server may continuously assign its current resource prices to services, for example using broadcast messaging or a gossiping protocol (also known as a gossip protocol). Services may use the latest information from the server as their price estimate. This may be referred to as a "pricetaker" price estimate. Note that it takes a non-zero amount of time to communicate resource prices, so prices may no longer be accurate when received. In embodiments using a gossiping protocol, service agents that receive pricing information may forward that information to other service agents with or without processing.

[0073] In some embodiments, the server may assign its current resource prices to all services, and each service will estimate the impact of its expected bid on the server resource price. This may be referred to as an "expected" price estimate. This may be accomplished, for example, by building knowledge of the server resource allocation behavior into each service agent. However, this increases the complexity of the system and makes it difficult to change the server resource allocation behavior.

[0074] In some embodiments, the service is well aware of server resource prices, for example through extensive operational coupling of the service and the server. This can be referred to as a "perfect" price estimate. However, perfect price estimates may be difficult to achieve in a distributed implementation.

[0075] It should also be noted that a service may implement a hybrid approach combining one or more of the above-described price estimation methods or other price estimation methods. Different services do not necessarily use the same price estimation routine.

[0076] Similarly, note that, in various embodiments, each service i is only expected to estimate its own parameter value b ij and b′ ij Therefore, service i can avoid trying to estimate parameter values ​​of other services running simultaneously with service i.

[0077] Server Behavior

[0078] As described above, each server (server agent) receives bids from one or more services, allocates server resources according to a bid-based auction process, and uses these allocated server resources to provide some or all of the services of the allocated resources. The auction process can be similar to, for example, "Network Resource Allocation and a Congestion Game: The Single Link Case" by R. Johari, J. Tsitsiklis (Proceedings of the 42 nd The server can update its resource allocation and subsequent service terms in response to the bid changes. The server can also communicate resource allocation information (or pricing information) back to the service agent. The server allocates resources to the service based on the bids of all services to the server. The service behaviors are combined through the server's resource allocation mechanism.

[0079] In various embodiments, each server j allocates an amount b to be given to service i (with a non-zero bid placed at server j) according to the following procedure: ij Server j has a set amount of r j As described above, resources can be allocated to services. As described above, resources can be processing resources, memory resources, communication resources, or other resources, or a packaged and packaged combination of these resources. For clarity, it is assumed that a single type of resource can be allocated. If multiple types of resources can be allocated, the server can allocate each different type of resource separately in a similar manner.

[0080] In some embodiments, server j sets the price of its resources according to:

[0081]

[0082] Here, as mentioned above, p j is the resource price of server j, s ij It’s a bidding for services.

[0083] In other embodiments, server j sets the price of its resources according to:

[0084]

[0085] Here, θ j is the predetermined minimum resource price of server j, also called the reservation price of server j.

[0086] Note that server resource allocation is determined by the total available amount of resources rj Define, that is:

[0087]

[0088] The server allocates resources based on the following:

[0089]

[0090] Note that servers may set resource prices explicitly, or servers may jointly perform resource pricing and allocation operations, thereby eliminating the need to explicitly generate and store resource prices.

[0091] Figure 4 The operation and functional components of server j 420 according to an illustrative embodiment of the present application are shown in detail. Figure 4 Also shown is the communication between server j and one or potentially more services 410. Figure 2 and Figure 3 As described, the communication includes receiving bids 460 from the service and providing feedback 470 to the service. Figure 4 As shown, this communication may be performed via an interface 430 (eg, a network interface).

[0092] according to Figure 4 , the server includes a resource pricer or resource allocator 440, which allocates server resources 450 to those services based on bids received from the services via interface 430. Allocation of server resources may include pricing those resources. Pricing and allocation may be performed by a computer processor executing instructions stored in a memory to perform calculations. The pricing and allocation behavior of the server is as described above. When resource pricing is performed implicitly, the component may be referred to as a resource allocator. The resource allocator manages a set of server resources 450 based on the current resource allocation. Server resources are managed by configuring one or more given amounts of server resources to support one or more given services. A given amount of resources supporting a given service i corresponds to an allocated amount b. ij .

[0093] Server resources may be configured to support services in a variety of ways. For example, a portion of a server's processing bandwidth may be set aside for performing computations in accordance with instructions of a computer program specific to a service. Similarly, a portion of a server's memory or communications bandwidth may be set aside for providing services. Server resources may be dedicated only to supporting a given service. Alternatively, a server may commit to providing a certain amount of resources on average to support services, and then manage the priorities of its internal resources between services accordingly. Certain (e.g., selected) server resources may be used exclusively or non-exclusively to support a given service.

[0094] The resource allocator may also be used to provide information (e.g., current resource allocation) back to the server interface to be communicated as feedback to the individual services. As described above, each server j may inform one or some or all of the services through its interface of the amount of resources b allocated by server j to one or more services i in response to the bids currently received from the services. ij . Server j may update the feedback information over time, for example periodically or in response to changes in bids. In some embodiments, server j may notify each service i only of the resource allocation for the service itself. In other embodiments, server j may notify each service i of the resource allocation for multiple services, such as the resource allocation for all services being served by server j. The server may similarly communicate other relevant information (e.g., pricing information) to the service. Note that, for example, because the service agent knows its current bid, the current resource allocation can be calculated from the current price via equation (6), and vice versa, so from the perspective of the service agent, the resource allocation information and the pricing information may be substantially equivalent.

[0095] Device and computer implementation

[0096] Figure 5 A computer device for providing at least one service agent or server agent according to an embodiment of the present application is shown. The computer device executes program instructions to implement at least one service or server agent 510, and may implement one or more additional servers or service agents 520. The computer device may be hosted inside or outside a data center. When multiple agents are hosted on the same device, communication between agents may be performed through messaging within the device.

[0097] Figure 6 A computer device used as a server according to an embodiment of the present application is shown. The server agent is not shown, but may also be provided by the same device or another computer device operatively coupled thereto. Figure 5 The device can be used with Figure 6 device integration. Figure 6 The apparatus includes resources that can be physically or logically grouped or divided into a plurality of resource units 610, 620, 630, 640 numbered 1 to S. Each resource unit can be individually allocated to support a specified service. Each resource unit can include a resource or a combination of multiple resources, such as computer processing resources, network communication resources, and computer memory resources.

[0098] Figure 5 and Figure 6The device includes one or more computer processors 540, 660, memory 550, 670, network interface 530, 650, and supporting hardware 560, 680 (e.g., power supply, internal communication bus, etc.). The computer device is coupled to the communication network via the network interface. The processor executes program instructions stored in the memory. The processor can store and retrieve dynamically generated information in the memory, such as current bidding or pricing information.

[0099] Figure 7 A portion of a data center including a plurality of computer devices arranged in a server rack 710 is shown. These devices may be used to provide a service agent, a server agent, server resources, or a combination thereof. The data center includes a plurality of equipment racks, each of which may include one or more servers or server components. In some embodiments, the servers may be virtualized and may be dynamically instantiated using resources from one or more equipment racks.

[0100] Performance Evaluation

[0101] For the purpose of analysis, each service can be viewed as trying to minimize the amount of resources it spends, assuming that the service requirements are met. That is, the goal of service i can be to minimize the amount Each service can also have Each service may also have other goals, such as providing the service using a target number of servers, or a goal related to the number of physical layer processors supporting the service, or a goal related to the number of different cloud-based radio access networks supporting the service. In particular, for congested (i.e., fully utilized) data centers where resources may be overutilized, it may be desirable to fairly allocate resources to different services in proportion to each server's budget weighted. That is, a reasonable system goal is to maximize utilization:

[0102]

[0103] According to "Markov Approximation for Combinatorial Network Optimization" by Chen et al. (IEEE Trans. Information Theory, Vol. 59, No. 10, October 2013) (hereinafter referred to as "Chen"), when the optimal value of the combinatorial optimization problem is approximated using the log-sum-exponential function, the solution of the combinatorial optimization problem can be interpreted as a stationary probability distribution of a class of time-reversible Markov chains. Combining the utility function of equation (7) with the optimal probability distribution expression proposed by Chen, that is:

[0104]

[0105] Generate the desired Markov chain equilibrium probability distribution:

[0106]

[0107] It can be shown that under certain conditions, as described earlier in this paper, the collective behavior of the services and servers approximately satisfies the continuous-time Markov chain of equilibrium probability distributions described above, which correspond to the optimal value of the utility function specified in equation (7). The reasoning is as follows. As described above, equation (8) gives the Markov chain equilibrium probability distribution corresponding to the optimal value of the utility function specified in equation (7). This equilibrium probability distribution is implemented for a Markov chain in which the ratio of the transition rates from each current state to each other state has the following form:

[0108]

[0109] The transition rate can be related to the equilibrium probability distribution through the Markov chain detailed balance equation, according to which for a chain with equilibrium probability p a and p b For any two states a and b, the transition rate between these two states depends on the relationship p a q ab =p b q ba , where q ab and q ba are the transition rates from state a to b and from b to a, respectively.

[0110] As mentioned above, b ij and b′ ij are the server resource allocations for the current state and another state, respectively. For example, b′ can be estimated using the form of equation (6): ij Under certain assumptions, equation (9) can be approximated or simplified as:

[0111]

[0112] Equation (10) gives the ratio condition between the transfer rates. It can be further shown that equations (1) and (2) can be used as approximations of equation (10). Therefore, the collective service and server behavior described previously approximately implements the desired Markov chain.

[0113] In various embodiments, a local executor (e.g., a service agent and / or a server agent) does not care about the feasibility of its actions. In other words, when taking an action, the local executor does not necessarily need to consider global feasibility. Instead, another executor or a regulatory agent in the system can perform feasibility decisions and allow or prohibit actions when appropriate. For example, an infeasible bid change may be rejected by a server or regulatory agent. Such a rejected infeasible decision cannot cause the Markov chain to transfer. Because the Poisson processes of control transfer are all independent of each other, system units can reject infeasible decisions without affecting the overall system behavior.

[0114] Examples and Simulations

[0115] Figure 8 A server manager (i.e., server agent) 810 and a service manager (i.e., service agent) 820 according to an example embodiment of the present application are schematically shown. The server manager includes a container (Docker) controller 860 for interacting with Docker 890 to start, stop, and update containers. The container can be used to instantiate a service instance 805 using related resources. The service instance runs as a Docker container. The server manager also includes an auction controller 865 for conducting resource auctions and setting resource prices. The server manager also includes a database 850 for tracking services running on the server. The database can be operably coupled to the auction controller and the container controller. Note that in addition to using containers, other embodiments of the present application can use virtualization methods to support services using server resources.

[0116] The service manager includes a placement controller 875, which is used to implement probabilistic transfer dynamics to regulate the bidding of services. The service manager also includes multiple bidding controllers 885, each of which is used to participate in the corresponding auction on behalf of the service by interacting with the auction controller 865 of a specific server manager 810. During the bidding process, the bidding controllers of multiple service managers interact with the auction controller of a given server manager at the same time. The service manager also includes multiple container agents 880, each of which is used to interact with a specific Docker controller 860, so as to instantiate and manage service instances on the corresponding server, for example, after a successful bid. The service manager 820 also includes a service controller 870 for managing interactions between other components of the service manager. The service manager also includes a service database 855 for tracking information used by different components of the service manager.

[0117] The server manager and / or service manager may also include a topology agent 830 for participating in a data center topology overlay. The data center topology may include servers and their associated resources. For example, in the absence of a central controller, the data center topology overlay provides information indicating the data center topology. The server manager and / or service manager may also include a load monitoring component 840 for tracking server load. The server manager and service manager may communicate via WebSocket 895 or, for example, another communication mechanism.

[0118] Fig. 9 An example table 910 showing a data center layout and an example of state transition dynamics 920 that are allowable for a service agent are shown. In this example, there are 6 servers and 6 service agents. Each entry in the table 910 indicates the bid amount for each server by each respective service. Thus, the current state of the service is indicated. (Alternatively, each entry in the table may indicate the amount of resources allocated to each respective service by each server.) A service may update its current state 922 by increasing 924 its expenditure (bid amount) for a given server or by decreasing 926 its expenditure for a given server according to the probabilistic transition dynamics. In some embodiments, a service may only update its expenditure for one server at a time.

[0119] Fig.10Possible system states 1010 of a simple example embodiment of two service agents, labeled Service 1 and Service 2, bidding for resources on two servers, labeled Server A and Server B, are shown. Each service agent has a budget of two units, each server has two available resources, and a reserved resource price of one unit. Possible system states (service bids) and possible transitions between system states are shown. States are shown as vector quantities, where the first through fourth elements, from left to right, are: the bid amount of Service 1 for Server A; the bid amount of Service 1 for Server B; the bid amount of Service 2 for Server A; the bid amount of Service 2 for Server B. Note that the possible state transitions are constrained so that only one service can change its bid amount for only one server at a time.

[0120] Fig.11 Table 1110 is shown, which shows the Fig.10 0 ...

[0121] Fig.12 A method 1200 for obtaining server resources for supporting a service i is shown. The method includes updating 1210 a payout allocation based on a probabilistic transition dynamic. The payout allocation includes one or more bid amounts s ij , each bid amount s ij represents a bid for a resource on a corresponding server j in the one or more servers. The probabilistic transition dynamics may cause the expenditure allocation to be updated at random times to a randomly selected new expenditure allocation. The update may approximate the behavior of a continuous-time Markov chain. The method further includes communicating 1220 one or more bid amounts s to a corresponding server in the one or more servers in response to the update of the expenditure allocation ij The method also includes receiving 1230 feedback from the one or more servers. The feedback may indicate the amount of resources b allocated by each corresponding server j of the one or more servers. ij , the above resource volume b ij Response to expenditure allocations ij 12. The feedback may additionally or alternatively indicate a resource price set by the server, the resource price indicating the amount of resource allocated. The feedback may be received after the bid change is communicated 1220 or at another time or a combination thereof. The method also includes controlling 1240 the probabilistic transition dynamics based on the feedback from the one or more servers. Controlling the probabilistic transition dynamics may include keeping up-to-date randomization parameters used to select new payout allocations and transition times, such as such that the randomization parameters satisfy the criteria of equation (1) or (2). Fig.12 The illustrated method may be performed by a service agent.

[0122] Fig.13 A method 1300 for operating a server according to an embodiment of the present application is shown. The method includes receiving 1310 a bid for the use of resources held by a server from one or more service agents. The method also includes allocating 1320 resources to one or more service agents using auction rules, wherein the amount of resources allocated to each service is approximately proportional to the amount of the bid for the resource by the service. The method may also include adjusting 1330 resource pricing information based on the currently received bid. The auction rules and resource pricing adjustments may be performed according to equations (3), (4), (5), and (6). The method also includes communicating 1340 an indication of resource allocation and / or associated pricing information to the service agent. The communication may be performed asynchronously with other method steps. The method also includes configuring 1350 the allocated resources to support the corresponding services to which the resources are currently allocated. Fig.13 The method may be executed by a server agent, or by a functional entity implemented as a software function on a computing platform.

[0123] Although the present application has been described with reference to the specific features and embodiments of the present application, it is apparent that various modifications and combinations may be made to the present application without departing from the present application. Therefore, the specification and the drawings should only be regarded as an explanation of the present application as defined by the appended claims, and any and all modifications, variations, combinations, or equivalents falling within the scope of the present application may be expected to be covered.

Claims

1. A method for obtaining support services i A method for managing server resources of a server, the method comprising: i The computer system executes and includes repeatedly performing the following operations: Dynamically update the payout allocation based on the probability transition, the payout allocation includes one or more bid amounts s ij , each bid amount s ij Indicates the corresponding server in one or more servers j Bidding for resources on In response to the updating of the payout allocation, communicating the one or more bid amounts to corresponding servers of the one or more servers s ij one or more changes; receiving feedback from the one or more servers, the feedback indicating the j Amount of resources allocated b ij , or indicates each corresponding server in the one or more servers j In allocating the amount of resources b ij The resource price used, in response to the expenditure allocation s ij , the resource volume b ij Assigned to host the service i ; as well as controlling the probabilistic transition dynamics based on the feedback from the one or more servers; wherein the probabilistic transition dynamics comprises probabilistically transitioning the expenditure allocation from a current expenditure allocation to a different expenditure allocation according to a transition rate, wherein the transition rate is characterized in that a ratio of the transition rate to a corresponding transition rate from the different expenditure allocation to the current expenditure allocation is determinable according to a function, wherein the function comprises a term raised to a predetermined power, wherein the term has: The numerator is equal to the amount of money allocated by all servers in the one or more servers in response to the different expenditure allocations for hosting the service. i The total expected amount of resources, and The denominator is equal to the amount of money allocated by all of the one or more servers to host the service in response to the current expenditure allocation. i The total amount of resources; or, wherein the probabilistic transition dynamics comprises probabilistically transitioning the expenditure allocation from a current expenditure allocation to an expenditure allocation in a plurality of different expenditure allocations according to a respective transition rate, each respective transition rate being characterized by a ratio of the respective transition rate to a corresponding transition rate from the expenditure allocation in the plurality of different expenditure allocations to the current expenditure allocation being determinable according to a function, the function comprising a term raised to a predetermined power, the term having: A numerator equals the amount of money allocated by all of the one or more servers for hosting the service in response to corresponding expenditure allocations in the plurality of different expenditure allocations. i The total expected amount of resources, and The denominator is equal to the amount of money allocated by all of the one or more servers to host the service in response to the current expenditure allocation. i The total amount of resources; or, wherein the probabilistic transition dynamics include probabilistically transitioning the expenditure allocation from a current expenditure allocation to a different expenditure allocation according to a transition rate, wherein the transition rate is characterized in that a ratio of the transition rate to a corresponding transition rate from the different expenditure allocation to the current expenditure allocation can be determined according to a function, wherein the function is given by multiplying a plurality of values, each of the plurality of values ​​being a term raised to a predetermined power, the term having: A numerator, which is equal to the amount of money allocated by all servers in the one or more servers in response to the different expenditure allocations for hosting different services in the plurality of services. i the total expected amount of resources; and A denominator equal to the amount of money allocated by all of the one or more servers in response to the current expenditure allocation for hosting the different services in the plurality of services. i The total amount of resources; or, wherein the probabilistic transition dynamics include probabilistically transitioning the expenditure allocation from a current expenditure allocation to an expenditure allocation in a plurality of different expenditure allocations according to a respective transition rate, each respective transition rate being characterized in that a ratio of the respective transition rate to a corresponding transition rate from the expenditure allocation in the plurality of different expenditure allocations to the current expenditure allocation can be determined according to a function, the function being given by multiplying a plurality of values, each of the plurality of values ​​being a term raised to a predetermined power, the term having: A numerator equals the amount of money allocated by all of the one or more servers for hosting different services in the plurality of services in response to the corresponding expenditure allocations in the plurality of different expenditure allocations. i the total expected amount of resources; and A denominator equal to the amount of money allocated by all of the one or more servers in response to the current expenditure allocation for hosting the different services in the plurality of services. i The total amount of resources.

2. The method according to claim 1, wherein: Each respective server of the one or more servers j The amount of resources at b ij and the corresponding server in the one or more servers j Elements s ij It is a non-decreasing relationship.

3. The method according to claim 1, wherein: The amount of resources in the one or more servers b ij Each server that is greater than zero uses at least that amount b ij The resources hosting the service.

4. The method according to claim 1, wherein: The feedback is in the form of resource pricing information.

5. The method according to any one of claims 1 to 4, wherein: The resources on each server are allocated using auction rules, in which the resources allocated to the server include the services i The resource amount of each service in the multiple services is proportional to the bidding amount of the service in the multiple services for the resources on the server.

6. A method for associating server resources with a plurality of services, the method being performed by one or more computer systems for managing the plurality of services and comprising performing the method according to claim 1 for each of the plurality of services, respectively, wherein: Each of the plurality of services interacts with the same one or more servers.

7. The method according to claim 6 also includes that each of the one or more servers allocates resources using auction rules, in which the amount of resources allocated to each service in the multiple services is proportional to the bid amount of the service in the multiple services for the resources.

8. A method for obtaining support services i The device of the server resource of the present invention comprises a computer processor, the computer processor is operably coupled to a memory, the memory stores program instructions, when the computer processor executes the program instructions, repeatedly performs the following operations: Dynamically update the payout allocation based on the probability transition, the payout allocation includes one or more bid amounts s ij , each bid amount s ij Indicates the corresponding server in one or more servers j Bidding for resources on In response to the updating of the payout allocation, communicating the one or more bid amounts to corresponding servers of the one or more servers s ij one or more changes; receiving feedback from the one or more servers, the feedback indicating each respective server of the one or more servers j Amount of resources allocated b ij , or indicates each corresponding server in the one or more servers j In allocating the amount of resources b ij The resource price used, in response to the expenditure allocation s ij , the resource volume b ij Assigned to host the service i ; as well as controlling the probabilistic transition dynamics based on the feedback from the one or more servers; wherein the probabilistic transition dynamics comprises probabilistically transitioning the expenditure allocation from a current expenditure allocation to a different expenditure allocation according to a transition rate, wherein the transition rate is characterized in that a ratio of the transition rate to a corresponding transition rate from the different expenditure allocation to the current expenditure allocation is determinable according to a function, wherein the function comprises a term raised to a predetermined power, wherein the term has: The numerator is equal to the amount of money allocated by all servers in the one or more servers in response to the different expenditure allocations for hosting the service. i The total expected amount of resources, and The denominator is equal to the amount of money allocated by all of the one or more servers to host the service in response to the current expenditure allocation. i The total amount of resources; or, wherein the probabilistic transition dynamics comprises probabilistically transitioning the expenditure allocation from a current expenditure allocation to an expenditure allocation in a plurality of different expenditure allocations according to a respective transition rate, each respective transition rate being characterized by a ratio of the respective transition rate to a corresponding transition rate from the expenditure allocation in the plurality of different expenditure allocations to the current expenditure allocation being determinable according to a function, the function comprising a term raised to a predetermined power, the term having: A numerator equals the amount of money allocated by all of the one or more servers for hosting the service in response to corresponding expenditure allocations in the plurality of different expenditure allocations. i The total expected amount of resources, and The denominator is equal to the amount of money allocated by all of the one or more servers to host the service in response to the current expenditure allocation. i The total amount of resources; or, wherein the probabilistic transition dynamics include probabilistically transitioning the expenditure allocation from a current expenditure allocation to a different expenditure allocation according to a transition rate, wherein the transition rate is characterized in that a ratio of the transition rate to a corresponding transition rate from the different expenditure allocation to the current expenditure allocation can be determined according to a function, wherein the function is given by multiplying a plurality of values, each of the plurality of values ​​being a term raised to a predetermined power, the term having: A numerator, which is equal to the amount of money allocated by all servers in the one or more servers in response to the different expenditure allocations for hosting different services in the plurality of services. i the total expected amount of resources; and A denominator equal to the amount of money allocated by all of the one or more servers in response to the current expenditure allocation for hosting the different services in the plurality of services. i The total amount of resources; or, wherein the probabilistic transition dynamics include probabilistically transitioning the expenditure allocation from a current expenditure allocation to an expenditure allocation in a plurality of different expenditure allocations according to a respective transition rate, each respective transition rate being characterized in that a ratio of the respective transition rate to a corresponding transition rate from the expenditure allocation in the plurality of different expenditure allocations to the current expenditure allocation can be determined according to a function, the function being given by multiplying a plurality of values, each of the plurality of values ​​being a term raised to a predetermined power, the term having: A numerator equals the amount of money allocated by all of the one or more servers for hosting different services in the plurality of services in response to the corresponding expenditure allocations in the plurality of different expenditure allocations. i the total expected amount of resources; and A denominator equal to the amount of money allocated by all of the one or more servers in response to the current expenditure allocation for hosting the different services in the plurality of services. i The total amount of resources.

9. The device according to claim 8, wherein: Each respective server of the one or more servers j The amount of resources at b ij and the corresponding server in the one or more servers j Elements s ij It is a non-decreasing relationship.

10. The device according to claim 8, wherein: The amount of resources in the one or more servers b ij Each server that is greater than zero uses at least that amount b ij The resources hosting the service.

11. The device according to claim 8, wherein: The feedback is in the form of resource pricing information.

12. The device according to any one of claims 8 to 11, wherein: The resources on each server are allocated using auction rules, in which the resources allocated to the server include the services i The resource amount of each service in the multiple services is proportional to the bidding amount of the service in the multiple services for the resources on the server.

13. A system for associating server resources with a plurality of services, the system comprising a plurality of apparatuses according to claim 8, each apparatus being configured to support a different set of one or more services in the plurality of services.

14. A computer program product, comprising program instructions, which, when executed by a computer, enable the method according to any one of claims 1 to 7 to be executed.

Images