Method for dynamically rebalancing throughput with resilient resource pooling techniques

Abstract

A method for dynamically rebalancing throughput with resilient resource pooling techniques includes determining, for each of a plurality of tenants renting computing resources of a shared resource pool, a desired request for resources in the shared resource pool. The desired request is based on a number of resource access requests received in association with each tenant of the plurality of tenants. The method further includes determining, for each tenant of the plurality of tenants, a guaranteed request and a maximum potential request for the shared resource pool; and allocating a pool of surplus resources among the plurality of tenants based on the determined maximum potential and expected requests for each of the plurality of tenants, the surplus resource pool represents a remainder of the shared resource pool after a guaranteed request for each of the tenants is satisfied via an initial resource allocation from the shared resource pool.

Description

[0001] This application is a divisional application of a Chinese patent application with application number 201980063793.2, filing date June 26, 2019, priority date September 28, 2018, and invention title "Elastic Resource Pooling for Dynamic Throughput Rebalancing". Background Art

[0002] Software as a Service (SaaS) is a software licensing and delivery model in which software is licensed on a subscription basis and centrally hosted. SaaS providers face the challenge of apportioning computing resources among different tenants who lease those services. When resources are statically allocated among tenants, a large portion of the resources may be unused at any given time. In contrast, dynamic, demand-based resource allocation methods tend to prioritize highly active tenants and may sometimes leave one or more tenants without sufficient computing resources to meet their current computing needs. Additionally, some tenants may be willing to purchase higher-cost packages to always be guaranteed a set number of resource units or level of performance support. Current demand-based resource allocation methods are insufficient to provide such guarantees without overallocating sometimes unused resources. Brief Description of the Drawings

[0003] Figure 1 Illustrates a system that uses elastic pooling techniques to dynamically rebalance resources among multiple tenants of a shared IoT (Internet of Things) hub.

[0004] Figure 2 Illustrates another system with a rebalancer that uses elastic pooling techniques to dynamically rebalance computing resources of a shared IoT hub among multiple tenants.

[0005] Figure 3 Illustrates example operations for allocating elastic pooled computing resources among multiple tenants.

[0006] Figure 4 Illustrates example operations for allocating a surplus resource pool among multiple tenants renting computing resources for web-based software services.

[0007] Figure 5A Illustrates a system that performs example operations for dynamic throughput rebalancing among multiple IoT hubs sharing an elastic resource pool.

[0008] Figure 5B Illustrates Figure 5A The system of performs further example operations for dynamic throughput rebalancing.

[0009] Figure 5C Illustrates Figure 5A andFigure 5B The system performs further example operations for dynamic throughput rebalancing.

[0010] Figure 5D Illustrated is Figures 5A - 5C the system performing further example operations for dynamic throughput rebalancing.

[0011] Figure 6 An example schematic diagram of a processing device suitable for implementing aspects of the disclosed technology is illustrated. SUMMARY OF THE INVENTION

[0012] A method for elastic allocation of a shared resource pool includes: determining expected claims for resources of multiple tenants for computing resources of the shared resource pool, such as based on the number of resource access requests received at endpoints associated with each of the multiple tenants. The method further includes determining a guaranteed claim and a maximum potential claim for the shared resource pool for each of the multiple tenants, and allocating a surplus resource pool among the multiple tenants based on the determined maximum potential claims and expected claims for each of the multiple tenants.

[0013] This Summary of the Invention introduces some concepts in a simplified form that will be further described in the Detailed Description below. This Summary of the Invention is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. These and various other features and advantages will be apparent from reading the following detailed description. DETAILED DESCRIPTION

[0014] Allocation systems that allow a SaaS (Software as a Service) provider to reserve a fixed amount of computing resources for each individual subscriber (also referred to herein as a "tenant") tend to be highly inefficient on a large scale due to the fact that some of the reserved computing resources may remain unused most of the time. To avoid over - allocating SaaS resources to individual subscribers, other allocation systems allow the SaaS provider to dynamically allocate SaaS computing resources based on current demand. However, need - based resource allocation methods often do not conform to a fixed cap that guarantees consumers a minimum amount of SaaS resources available to them at any given time.

[0015] Existing resource allocation solutions do not adequately address the conflict between the above-described need-based (dynamic) allocation method and the static (non-dynamic) allocation method that can allow different tenants to each set their own fixed minimum caps (such as by offering different SaaS subscription layers associated with different fixed minimum caps). The techniques disclosed herein provide a method for dynamically allocating a pool of shared computing resources among multiple tenants based on need-based requirements, while also ensuring for the tenants both: (1) a minimum cap on individual fixed available resources; and (2) an individual fixed claim on a fraction of the "surplus" resources. The solution allows for full utilization of the available resources at all times, which prevents resources from remaining reserved but unused, while also providing tenants with some individual control over the resources they may access at any given time.

[0016] By way of example and not limitation, the disclosed techniques are described herein with reference to a specific type of SaaS referred to as an IoT (Internet of Things) hub. Generally, an IoT hub provides services that manage the data flow between one or more web-based IoT applications and the smart devices managed by those IoT applications. For example, a web-based IoT application provider may lease an IoT hub and computing resources to facilitate the ingestion of a large amount of telemetry from smart devices to the associated web-based IoT application. In this context, the IoT hub acts as a central message hub for passing two-way communication (e.g., device-to-cloud telemetry, cloud-to-device commands) between one or more IoT solutions and the smart devices managed by these solutions. Each IoT hub can be provisioned with a certain number of resource units, which affect the maximum daily quota of messages that the IoT hub can send to and receive from IoT solutions and smart devices.

[0017] Different web-based solution providers that lease IoT hubs and associated computing resources have very different active support requirements. For example, some IoT hub tenants may require active messaging support with thousands of devices once a day, while other IoT hub tenants may require active messaging support with millions of devices once a minute. Thus, IoT hub providers face the challenge of apportioning resource units to each IoT hub in a manner that is cost-feasible and fair for all tenants.

[0018] When resources are statically allocated among tenants, a majority of the resources may be unused at any given time. In contrast, dynamic, demand-based resource allocation methods tend to prioritize highly active tenants, which may leave one or more tenants of the IoT hub with insufficient device support to guarantee the set levels during peak activity times. Additionally, pure demand-based dynamic allocation solutions may not be able to guarantee competitive uplink and downlink times to tenants willing to purchase higher-cost IoT hub subscription packages.

[0019] Figure 1 System 100 is illustrated that utilizes elastic pooling techniques to dynamically rebalance resources among multiple tenants of shared IoT hub 104. Shared IoT hub 104 generally represents multiple, individual IoT hubs, where each IoT hub is leased by a different tenant and shares a common pool of computing resources (e.g., shared resource pool 106). For example, Figure 1 the configuration can be understood to represent a group of IoT hubs, where each IoT hub in the group is leased by one of six different tenants (labeled Tenant #1 – Tenant #6). For example, Tenant 1 has the first IoT hub; Tenant 2 has the second IoT hub, and so on. Each of the leased IoT hubs within shared IoT hub 104 is supported by resources dynamically allocated from shared resource pool 106.

[0020] In one implementation, each tenant of shared IoT hub 104 is a web-based IoT solution provider (e.g., one of multiple IoT solutions 110). For example, each tenant of shared IoT hub 104 provides an IoT solution designed to manage certain types of smart devices 108.

[0021] Generally, the term “smart device” is used herein to refer to an electronic device having processing and data transmission capabilities, and more specifically, a device managed by a corresponding IoT solution. By way of example and not limitation, Figure 1 smart device 108 is illustrated that includes various types of home devices (e.g., smart bulbs, smart plugs, smart thermostats, smart watches, smart earphones, and smart headsets). Each of the IoT solutions can effectively configure, control, command, or otherwise support user interaction with a subset of smart devices 108. For example, a user can interact with a mobile application of one of the IoT solutions 110 to program the schedules of smart bulbs, electrical plugs, etc.

[0022] The shared IoT hub 104 enables two-way communication (e.g., device connection requests, device-to-cloud telemetry, cloud-to-device commands) between the smart devices 108 and the corresponding IoT solutions 110. In one implementation, each solution in the IoT solutions 110 associated with different uniform resource identifiers (URIs) and the shared IoT hub 104 support data ingestion for the URIs, as well as messaging between the URIs and the associated smart devices 108.

[0023] In one implementation, the shared resource pool 106 includes a certain number of total computing resource units, and this certain number of total computing resource units affects the maximum daily quota of messages that the IoT hub 104 can send and receive with the smart devices 108 and the associated IoT solutions 110. The system 100 includes a rebalancer 102 that dynamically allocates the resource units of the shared resource pool 106 to different tenants based on the current activity of each tenant (e.g., based on requirements considerations), and also based on preset subscription parameters associated with each tenant (e.g., fairness considerations).

[0024] In one implementation, allocating resources from the shared resource pool 106 requires determining, for each tenant, the desired claim on the shared resource pool 106, the guaranteed claim on the shared resource pool 106, and, after the guaranteed resources are allocated, the maximum potential claim on the surplus resources remaining in the shared resource pool 106. The desired claim is based on requirements. For example, the rebalancer 102 can evaluate the access requests received at the ingestion endpoints associated with each tenant to determine the tenant's current desired claim on the resources of the shared resource pool 106. In contrast, the guaranteed claim and the maximum potential claim can be parameters associated with the tenant's profile preset by the tenant or the SaaS service.

[0025] In one implementation, the rebalancer 102 implements an allocation logic that is used to dynamically rebalance the resources of the shared resource pool 106 among the tenants, while ensuring that the resulting allocation meets the desired claims of each tenant in the tenants of the shared IoT hub 104 when possible. When the cumulative total of the desired claims on the shared resource pool 106 exceeds the availability of resources, the rebalancer 102 allocates resources among the tenants in such a way that ensures: (1) all resources are allocated to support the current processing requests (e.g., no resources are "reserved" and not used), and (2) all resources are allocated to meet the guaranteed claims for each tenant, while also sharing the surplus resources based on the pre-specified maximum potential claims of each tenant (e.g., in a fair proportion).

[0026] For example, Figure 1Illustrated is a scenario where the overall utilization of the shared resource pool 106 is 100%, but each individual tenant is utilizing a different amount of resources and / or resources that may be less than the desired claim of each tenant. Despite the fact that all resources are being used, each active tenant is guaranteed access to a set minimum of resources and is entitled to a portion of the resource surplus, the fraction of which is proportional to the preset maximum potential claim set for each tenant, in order to achieve a balance between need-based considerations and fairness considerations, which may be based on the individual subscription levels of different tenants. As used herein, an "active tenant" refers to a tenant that actively receives requests to access the resources of the shared resource pool 106.

[0027] Further details of elastic resource allocation are discussed in more detail below.

[0028] Figure 2 Illustrated is another system 200 having a rebalancer 202 that utilizes elastic pooling techniques to dynamically rebalance the computing resources of a shared IoT hub 204 among multiple tenants. Each of the multiple tenants of the shared IoT hub 204 leases IoT hub services to facilitate telemetry flows between smart devices and associated tenant-managed web-based IoT solutions. In one implementation, the web-hosted IoT hub services provide software configurations to each tenant of the shared IoT hub 204 that effectively ingest data into a specific URI associated with a tenant-owned IoT solution (not shown).

[0029] In Figure 2 the example, the shared IoT hub 204 is provisioned with six IoT hubs, four of which are shown as occupied (numbered tenant hubs 1 - 4), and two of which are shown as unoccupied (numbered future tenant hubs 5 - 6). The computing operations of each tenant hub in the tenant hubs are supported by resources in the shared resource pool 206. In one implementation, the shared resource pool 206 includes a set number of elastically pooled resource units 212. The set number of resource units 212 affects the maximum quota of messages that a tenant of the shared IoT hub 204 can send to and receive from smart devices (not shown) and their associated IoT solutions. In Figure 2 the example, the shared resource pool 206 includes 200 resource units that can be dynamically and elastically allocated and reallocated based on the throughput of each of the in / out tenant hubs 1 - 6.

[0030] In Figure 2In [the figure], the rebalancer 202 is shown as being included in the throttling engine 210. For each tenant among the tenants of the shared IoT hub 204, the throttling engine 210 enforces one or more throttling limits to control the rate at which incoming requests to the shared IoT hub 204 are processed by each of the resource units 212. For example, the throttling limit can specify the number of specific types of operations that an individual resource unit among the resource units 212 can perform per minute. In one implementation, the throttling engine 210 sets different throttling limits for different types of events, such as by enforcing a first throttling limit for device-to-cloud events, a second throttling limit for cloud-to-device events, a third throttling limit for device connections, and so on. For example, the resource units 212 can each support 120 device-to-cloud messages per minute (e.g., 120 operations / second / unit), while being able to support 1.67 cloud-to-device messages per minute (e.g., 1.67 operations / second / unit).

[0031] Throughout the day, the rebalancer 202 dynamically changes the number of resource units 212 that are supplied to service requests for each different tenant hub among the tenant hubs. In one implementation, the rebalancer 202 dynamically rebalances the resource units 212 of the shared resource pool 206 among different tenants based on the current activity of each tenant (e.g., based on requirements considerations), and also based on preset subscription parameters associated with each tenant (e.g., fairness considerations). In each instance of reallocation (also referred to herein as "rebalancing"), the rebalancer 202 retrieves both the real-time request information and certain subscription parameters for each tenant hub among the multiple tenant hubs.

[0032] During an example allocation of resource units 212 to tenant hubs 1-4 of a shared IoT hub 204, the rebalancer 202 determines a desired claim, which can be understood as a need-based claim for a subset of resource units 212 of the shared resource pool 206. In one implementation, the desired claim for a particular tenant hub is determined based on access requests received at an ingestion endpoint for the individual tenant hub, and one or more current throttling limits associated with that ingestion endpoint. For example, an ingestion endpoint (not shown) for tenant hub #1 may periodically transmit timestamp information and the number of requests received within a set time interval to the rebalancer. Based on the rate-limiting configuration for the tenant hub, the rebalancer 202 calculates the request rate per second to determine the computing capacity sufficient to process incoming requests at a rate comparable to the incoming request rate. For example, if tenant hub #1 is receiving 120 messages of a certain message type (e.g., cloud-to-device messages) per second, and the throttling limit for that message type is currently set to 120 messages per minute, the rebalancer 202 may determine that the desired claim (e.g., the computing capacity sufficient to process incoming requests) for tenant hub #1 is 60 resource units.

[0033] The above example relates to the scenario where tenant hub #1 is receiving requests for a single message type that is governed by a single throttling rate. As mentioned above, some implementations may enforce different throttling limits for different types of messaging requests. Unless otherwise stated, the term "desired claim" is used herein to refer to the total computing capacity sufficient to meet the cumulative (total) current computing demands on an individual IoT hub. For example, the desired claim for tenant hub #1 may be calculated based on the computing capacity necessary to meet the request rate for each of a plurality of different types of messages governed by different throttling rates.

[0034] In addition to determining the desired claim for resource units 212, the rebalancer 202 also determines two pre-specified parameters that are not based on an assessment of the current resource request rate: the "guaranteed claim" and the "maximum potential claim". Each of the guaranteed claim and the maximum potential claim can be set individually for each tenant, such as according to a selection made by the tenant, or according to preset subscription parameters of the subscription tier to which each tenant has subscribed. For example, the rebalancer 202 may evaluate the subscription parameters of each tenant to determine the guaranteed claim and / or the maximum potential claim for resource units 212 of the shared resource pool 206. In one implementation, the guaranteed claim and the maximum potential claim are set according to the tenant's subscription profile. For example, a tenant with a high paying capacity may purchase into a higher subscription tier that guarantees a higher guaranteed claim and / or maximum potential claim than is available via a cheaper, lower subscription tier.

[0035] Guaranteed claims against the tenant center can be understood as a cap on the amount of resources that are guaranteed to be allocated to the tenant center while the center is active (e.g., when the center is receiving resource requests and / or actively using the resources of the shared resource pool 206). In one implementation, as long as the desired claim is less than or equal to the tenant's guaranteed claim, each active tenant is allocated an amount of guaranteed resources sufficient to meet its desired claim. In contrast to the guaranteed claim, the maximum potential claim represents the share that the tenant center has in the unguaranteed resources or "surplus resources" of the shared resource pool 206. As used herein, "surplus resources" refers to a subset of the resource units 212 that remain after the guaranteed resources have been allocated to each active tenant center in the active tenant centers.

[0036] In one implementation, the rebalancer 202 implements an allocation logic that is used to dynamically allocate the resources of the shared resource pool 206 while ensuring, when possible, that the resulting allocation meets the desired claims of each of the tenants in the shared IoT center 204. When the cumulative total of tenant requests for access to resources exceeds the availability of resources in the shared resource pool 206, the rebalancer 102 allocates resources among the tenants in such a way as to ensure that: (1) all resources are allocated to provide support for the currently processing requests (e.g., no resources are "reserved" and not used), and (2) all resources are allocated to meet the guaranteed claims for each tenant while also apportioning the surplus resources based on the pre-specified maximum potential claim for each tenant (e.g., in a fair proportion thereto).

[0037] During an example allocation of the resource units 212 among tenant centers #1 through #4, the rebalancer 202 identifies a subset of the resource units 212 that are guaranteed for distribution to a specific tenant center (e.g., guaranteed resource units). To identify the guaranteed resource units, the rebalancer 202 calculates the desired claim for each tenant center based on the current request rate. When the desired claim is less than or equal to the guaranteed claim for the specific tenant center, the tenant center is guaranteed a number of resource units 212 equal to the desired claim (e.g., the guaranteed claim is adjusted to equal the desired claim). In the case where the desired claim for a tenant is greater than the guaranteed claim, the tenant center is guaranteed a number of resource units equal to the guaranteed claim.

[0038] If, for example, tenant center #1 has a desired claim of six resource units and a guaranteed claim of five resource units (as shown), then tenant center #1 is guaranteed five resource units in the initial allocation. If, alternatively, tenant center #1 has a desired claim of two resource units, then tenant center #1 is guaranteed two resource units in the initial allocation. By the above logic, as long as the desired claim is less than or equal to the guaranteed claim, each active tenant is guaranteed resources sufficient to meet the desired claim.

[0039] After allocating a guaranteed number of resource units 212 to each tenant center in the tenant center in the above manner, the balancer 202 determines the size of the surplus pool - a subset of the remaining resource units 212. If, for example, there are initially 100 elastic pooled resource units and the guaranteed claims annotated in Figure 2 are allocated to each tenant, the total number of guaranteed claims is 64 (the sum of 5 + 5 + 50 + 4), and the surplus pool is 36, which is equal to the difference between the total number of pooled resource units (100) and the guaranteed units (64).

[0040] The balancer 202 then allocates the surplus pool (e.g., the 36 resource units in the above example) among the unsatisfied tenants based on metrics that are both need-based (e.g., based on the desired claims for each tenant center) and fairness-based (e.g., based on a preset maximum potential for each tenant center requesting additional resources). As used herein, an "unsatisfied tenant" refers to a tenant when the desired claim is not met by the current resource allocation. The following regarding Figure 3 and Figure 4 more details the exemplary allocation processes and suitable metrics for implementing these.

[0041] Figure 3 Illustrated is an exemplary operation 300 for allocating elastic pooled computing resources among multiple tenants renting a web-based software service such as an IoT hub. A determination operation 302 determines the desired claims of each tenant among the multiple tenants for the pooled computing resources. In one implementation, for each tenant, the desired claim is determined based on the rate of incoming messages received at the endpoint requesting access to the resources (e.g., the IoT hub gateway). For example, the desired claim can be equal to the computing resources sufficient to process incoming requests at the rate at which the incoming requests are received.

[0042] In some implementations, the determination operation 302 dynamically determines different request rates associated with different types of incoming requests. For example, different request rates can be associated with different types of messages received at the IoT hub gateway (e.g., device connection requests, device-to-cloud requests, cloud-to-device requests). In this case, the desired claim can represent the total computing capacity sufficient to cumulatively satisfy the various determined request rates according to the current throttling configuration of the IoT hub.

[0043] Another determination operation 304 determines, for each of a plurality of tenants, the guaranteed claim and the maximum potential claim for resources of a shared resource pool. In one implementation, the guaranteed claim and the maximum potential claim are each set for each tenant, such as based on subscription parameters selected by the tenant or according to the subscription tier to which each tenant has subscribed. In some implementations, the guaranteed claim and the maximum potential claim can be dynamically changed by the tenant. For example, a tenant can select an optional configuration at any given time to increase the maximum potential claim and / or the guaranteed claim. For this reason, the determination operation 304 can determine (e.g., according to tenant requests) the guaranteed claim and the maximum potential claim during each iteration of resource allocation.

[0044] An adjustment operation 306 adjusts the minimum guaranteed claim to represent the lower of the guaranteed claim and the desired claim for shared computing resources. An allocation operation 308 allocates guaranteed resources, which can be understood as resources from the shared resource pool sufficient to satisfy the adjusted guaranteed claim of each tenant.

[0045] After the allocation operation 308, a determination operation 310 determines the size of the surplus resource pool remaining from the shared resource pool. For example, the size of the surplus pool can be equal to the difference between the total number of resource units available in the shared resource pool and the total number of resource units allocated via the allocation operation 308. Another allocation operation 312 allocates the surplus pool among the plurality of tenants based on the determined maximum potential claim and desired claim for each of the plurality of tenants. Sub - example operations of the allocation operation 312 are discussed in detail regarding Figure 4 An example operation 400 is illustrated, which is used to allocate a surplus resource pool among a plurality of tenants renting computing resources for a web - based software service. In one implementation, the operation 400 represents sub - operations of the allocation operation 312 described regarding

[0046] After the allocation operation 312, a parameter update operation 314 adjusts the desired claim for one or more tenants based on the current (updated) resource request rate. In response to adjusting one or more of the desired claims, the operations 304, 306, 308, 310, and 312 are repeated. In one implementation, the parameter update operation 314 is performed after a set time has elapsed after the allocation operation 312. For example, depending on system parameters, the parameter update operation 314 can be repeated every 30 seconds, every minute, etc. In another implementation, the parameter update operation 314 is performed in response to a tenant request for additional resources for the shared resource pool.

[0047] Figure 4 An example operation 400 is illustrated, which is used to allocate a surplus resource pool among a plurality of tenants renting computing resources for a web - based software service. In one implementation, the operation 400 represents sub - operations of the allocation operation 312 described regarding Figure 3 Aspects of the surplus resource pool that are not specifically described below can be related to those described above regarding Figure 4 Specifically described below regarding Figures 1 - 3The surplus resource pools being discussed are the same or similar. In one implementation, the surplus resource pool represents: after a guaranteed quantity of elastic pooled resources have been initially allocated to each active tenant among the active tenants (such as in the manner described above with respect to Figure 2 and Figure 3 ), the quantity of remaining elastic pooled resources that are still available for distribution among the active tenants of the shared IoT hub.

[0048] The first identification operation 402 identifies tenants (such as IoT hubs) that have a desired claim that is not satisfied by the current distribution of elastic pooled resources. In the following description, a tenant's desired claim is considered to be "not satisfied" when the quantity or computing capacity of resources allocated to the tenant is less than the quantity or computing capacity necessary to satisfy the tenant's desired claim. For example, when the initially allocated guaranteed resources of a tenant (as described above with respect to Figure 3 ) are insufficient to support processing incoming IoT hub requests at a rate equal to or exceeding the requested rate, the tenant can be considered "not satisfied".

[0049] For example, the tenants identified by the identification operation 402 include those tenants that have an initial distribution of guaranteed resources from the shared resource pool that is less than their desired claim. Consistent with the above Figure 2 and Figure 3 description, the desired claim can represent the quantity of resource units from the shared resource pool, the amount of which is sufficient to meet the current computing needs of an individual tenant. For example, the desired claim can quantify the computing capacity that is sufficient to process the same messages at a rate that is substantially equal to the rate at which incoming messages are received at an endpoint (such as the ingestion endpoint of an IoT hub). In one implementation, the desired claim is determined in a manner consistent with the above with respect to Figure 2 and Figure 3 .

[0050] The calculation operation 404 calculates a "maximum unit shortage" for each unsatisfied tenant among the unsatisfied tenants, where the "maximum unit shortage" is a metric that generally quantifies the maximum number of additional resource units that can be allocated to a tenant from the surplus resource pool. According to one implementation, the maximum unit shortage for an unsatisfied tenant is defined by the difference between the tenant's maximum potential claim and the guaranteed resources allocated to the tenant in the initial allocation (e.g., maximum potential claim – current resource allocation).

[0051] Another computational operation 406 computes another metric herein referred to as "weighted units", which represents the sum of the maximum unit shortages of each unmet tenant among the unmet tenants. In one implementation, the weighted units are given by the following equation (1), where "n" represents the index of one of the identified unmet tenants, and "M" is the total number of unmet tenants.

[0052]

[0053] There is yet another computational operation 408 that computes an allocation ratio based on the computed sum (the weighted units given by Equation 1) and the size of the surplus resource pool. The allocation ratio generally represents the fraction of the desired claim of each tenant that will be allocated from the surplus pool to the tenant. In one implementation, the allocation ratio is generally represented by the following equation (2), which is the ratio between the total number of surplus resource units remaining in the shared resource pool and the weighted units computed via computational operation 406.

[0054]

[0055] Allocation operation 410 allocates the surplus units in the surplus resource pool among the unmet tenants based on the computed allocation ratio and the desired claim of each tenant on the shared resource pool. According to one implementation, the surplus allocation for a particular tenant is given by the following equation (3).

[0056] Allocate Surplus (tenant(n)) = Desired Claim (tenant(n)) × Allocation Ratio (3)

[0057] Determination operation 412 determines whether the allocation operation 410 leaves a resource allocation for any of the identified tenants that exceeds the tenant's desired claim. If so, replenishment operation 414 replenishes the surplus pool with the previously allocated surplus units, in an amount that exceeds the desired claim of one or more of the tenants. For example, if tenant A has a desired claim of 11 resource units, and the allocation of surplus (e.g., as determined by Equation (3)) leaves a total allocation of 13 resource units for tenant A, then replenishment operation 414 returns the excess two resource units to the surplus pool, leaving tenant A with 11 resource units. In this case, identification operation 402 is repeated to identify the "still unmet tenants", or the tenants whose associated desired claims have not yet been satisfied. Computational operations 404, 406, and 408 are repeated to compute a new allocation ratio (e.g., based on the new size of the surplus pool and the adjusted weighted units, taking into account the fact that one or more of the initially unmet tenants may have become satisfied through the previous surplus distribution).

[0058] Operations 402 - 414 may be repeated the set number of times, or until it is determined in operation 412 that there are no tenants with a current resource allocation that exceeds the desired claim. According to one example implementation, operations 402 - 414 are repeated up to three times. Other iteration limits may be imposed in other implementations. Once the iteration limit is reached and / or there are no tenants with a current resource allocation that exceeds the desired claim, it is assumed that wait operation 416 waits for a change in the desired claim and a subsequent guaranteed resource allocation (e.g., according to Figure 3 operation 308 in

[0059] Figure 5A –5D illustrates example allocation steps that generally illustrate what was discussed above with respect to Figures 3 - 4 what was discussed above. Figure 5A FIG. illustrates system 500, which performs example allocation operations for dynamic throughput rebalancing among multiple IoT hubs that share elastic resource pool 504.

[0060] System 500 includes a rebalancer 502 that dynamically resupplies computing resources of elastic resource pool 504 among the following three IoT hubs: Hub A, Hub B, and Hub C. In the illustrated example, elastic resource pool 504 includes 100 resource units. Initially, all three hubs are idle. When Hub A becomes active (e.g., upon receiving one or more requests at an ingestion endpoint), Hub A transmits a request 506 for resources to rebalancer 502.

[0061] To answer the request, rebalancer 502 determines the desired claim associated with each active IoT hub among the IoT hubs. Since Hubs B and C are idle, rebalancer 502 determines the desired claim (desired operating capacity) for Hub A. In one implementation, rebalancer 502 determines one or more request rates for Hub A and calculates the desired claim based on the (multiple) request rates. For example, rebalancer 502 may periodically record timestamp information and the number of requests for each target type made to each hub within a known interval. Using this information, rebalancer 502 can determine the request rate for each target type of requests and calculate the desired claim on the capacity of the elastic pool.

[0062] In the illustrated example, rebalancer 502 determines that Hub A has a desired claim of 5 resource units. Rebalancer 502 determines that Hub A has a guaranteed claim of 1 resource unit and a maximum potential claim of 100 resource units. As per what was discussed with respect to Figure 4Following the logical steps outlined, rebalancer 502 allocates the guaranteed claim (e.g., 1 resource unit) and determines the surplus (e.g., 100 – 1 = 99 resource units). The rebalancer 502 then determines the allocation ratio, which represents the fraction of the desired claim for Center A that will be allocated from the surplus pool 508. This allocation ratio is based on the guaranteed and maximum potential claims of each active tenant.

[0063] To determine the allocation ratio, rebalancer 502 first calculates the maximum unit shortage for each of the active tenants. Here, Center A has the maximum unit shortage, which is defined by the difference between its maximum potential claim (100 resource units) and its guaranteed claim (1 resource unit). The rebalancer calculates the weighted units (the sum of the maximum unit shortages for each of the active tenants). Since Center A is the only active tenant at this point in time, the weighted units for surplus distribution are given by 100 - 1, or 99. The rebalancer 502 calculates the allocation ratio, or the ratio between the surplus units (99) and the weighted units (99), which in this example is 99 / 99, or 1. To determine how many surplus units to allocate to Center A, the rebalancer 502 multiplies the desired claim for Center A by the allocation ratio (e.g., 5 × 1), and allocates 5 surplus units out of the surplus units to Center A. After this allocation, Center A has 6 resource units (1 guaranteed + 5 surplus). This exceeds the desired claim of 5, so 1 resource unit is returned to the surplus pool 508, leaving Center A with 5 total units and 95 resource units in the surplus pool 508.

[0064] Figure 5B Illustrates that system 500 follows further allocation operations for dynamic throughput rebalancing following the example operation discussed regarding Figure 5A At the time point following the allocation of 5 resource units to Center A described above, the request rate for Center A increases. Center A determines that the currently allocated 5 resource units are insufficient to meet the increased request rate and, therefore, transmits another resource request 512. Centers B and C remain idle.

[0065] To answer request 512, balancer 502 determines an expected claim sufficient to meet the request rate for Hub A. This time, balancer 502 determines that Hub A has an expected claim of 100 total resource units. Balancer 502 allocates a guaranteed claim (e.g., 1 resource unit) and determines the surplus (e.g., 100 – 1 = 99 resource units). Balancer 502 calculates the maximum unit shortage for each active tenant in the active tenants (e.g., Hub A has a maximum unit shortage of 100 – 1 = 99 resource units). Balancer 502 calculates the weighted units (the sum of the maximum unit shortages for each active tenant in the active tenants). Since Hub A is still the only active tenant at this point in time, the weighted units for surplus distribution are given by 100 – 1, or 99. Balancer 502 calculates the distribution ratio between the surplus and the weighted units (99 / 99) and multiplies that ratio (1) by the expected claim for Hub A, awarding Hub A all 99 of the remaining units in the surplus pool.

[0066] Figure 5C illustrates further allocation operations for dynamic throughput rebalancing performed by system 500 after the example operations discussed Figures 5A - 5B In Figure 5C , balancer 502 receives resource requests from Hub B and Hub C. Since Hub A was previously allocated 100% of the units in elastic pool 504, balancer 502 responds to the request by performing the action of reallocating the resources of elastic pool 504 among the hubs. Balancer 502 identifies the expected claims associated with each active IoT hub among IoT Hub – Hub A, Hub B, and Hub C. Here, balancer 502 identifies that Hub A has an expected claim of 100 resource units; Hub B has an expected claim of 20 resource units; and Hub C has an expected claim of 30 resource units.

[0067] Balancer 502 begins rebalancing by reallocating guaranteed resources to each active hub among the active hubs. Since each hub among the hubs has an expected claim greater than its guaranteed claim, balancer 502 allocates the guaranteed claim. In an alternative throughput rebalancing scenario where one of the hubs has an expected claim less than its guaranteed claim, balancer 502 can adjust the guaranteed claim to be equal to the expected claim and allocate that amount. In Figure 5C , Hub A is guaranteed 1 resource unit; Hub B is guaranteed 10 resource units; and Hub C is guaranteed 20 resource units. Balancer 502 determines the size of the surplus pool by subtracting the allocated guaranteed units from the total elastic pool (e.g., 100 – (1 + 10 + 20) = 69 resource units).

[0068] After the allocation of the guaranteed resource units, the rebalancer 502 identifies the "unsatisfied tenants", or the tenants for which the desired claims are not satisfied by the current resource allocation. Here, each of the centers A, B, and C is unsatisfied, so the rebalancer 502 will determine that the surplus pool (69 resource units) is apportioned (e.g., parts x, y, and z) among all three centers based on the allocation ratio determined based on fairness considerations (e.g., the maximum potential claim and the guaranteed claim for each tenant) and the desired claims for each of the centers.

[0069] The rebalancer 502 then determines the allocation ratio to determine the fractional amount of its associated desired claim that each tenant can be allocated. As in the above example, the rebalancer 502 determines the sum of the weighted units, or (maximum potential claim - guaranteed claim) for each active tenant, which in this case is 149 (e.g., (100 - 1)+(30 - 10)+(50 - 20)). The allocation ratio is given by the surplus pool (69) divided by the weighted units or 69 / 149 = 0.46.

[0070] To determine the surplus claim (e.g., the number of resource units allocated from the surplus pool 508 to each center), the rebalancer 502 multiplies the allocation ratio by the desired claim for each center. Here, Center A receives a surplus of 46 resource units (0.46×100); Center B receives a surplus of 19.2 resource units (0.46×20); and Center C receives a surplus of 13.8 resource units (0.46×30). After this allocation, Center C has a total claim of 33.8 resource units, which is 3.8 resource units. This exceeds the desired claim of 30 resource units, so 3.8 resource units are returned to the surplus pool 508.

[0071] Figure 5D Illustrates that the system 500 performs further allocation operations for dynamic throughput rebalancing after the example operation discussed Figure 5C After allocating the guaranteed resources and the surplus claims to each of Center A, Center B, and Center C, Center C is left with a total claim (33.8 resource units) that exceeds its desired claim (30 resource units). The excess (3.8 resource units) is returned to the surplus pool, and Center C is left with a total claim of 30 resource units.

[0072] After returning the surplus units from all centers with an allocation that exceeds the associated desired claim to the surplus pool, the rebalancer 502 again identifies the unsatisfied tenants, or the tenants for which the desired claims are not satisfied by the current resource allocation. Here, the rebalancer determines that Center C is satisfied, so the remaining surplus pool (3.8 units) will be apportioned between Center A and Center B.

[0073] Since the number of satisfied centers has changed, the balancer 502 calculates a new allocation ratio that represents the fractional quantity of the associated desired claim that each of the unsatisfied centers can be allocated from the returned surplus (3.8 units). Using the same logic detailed above, the balancer 502 determines the sum of the weighted units, or (Potential Maximum Claim – Guaranteed Claim), and arrives at 119 ((100 - 1)+(30 - 10)). The allocation ratio is given by the surplus pool divided by the weighted units, or 3.9 / 119 = 0.0319.

[0074] To determine the secondary surplus claims allocated to each of Center A and Center B, the balancer 502 multiplies the new allocation ratio by the desired claim for each center. Here, Center A receives an additional surplus of 3.16 resource units and Center B receives an additional surplus of 0.63 resource units. After this allocation, Center A has a total claim of 50.16 resource units; Center B has a total claim of 19.83 resource units; and Center C has a total claim of 30 resource units. All units in the flex pool have been allocated.

[0075] Figure 6 An example schematic diagram of a processing device 600 suitable for implementing aspects of the disclosed technology is shown. The processing device 600 includes one or more processor units 602, a memory 604, a display 606, and other interfaces 608 (e.g., buttons). The memory 604 generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory). An operating system 610 (such as the Microsoft operating system, the Microsoft Phone operating system, or a specific operating system designed for a gaming device) resides in the memory 604 and is executed by the (one or more) processor units 602, although it should be understood that other operating systems may be employed.

[0076] One or more applications 612 are loaded into the memory 604 and executed by the (one or more) processor units 602 on the operating system 610. The applications 612 can receive input from various input local devices such as a microphone 634, input accessories 635 (e.g., keyboard, mouse, stylus, touchpad, gamepad, racing wheel, joystick). Additionally, over wired and wireless networks (e.g., mobile phone network, ) with, for example, intelligent devices located remotely (e.g., Figure 1communicate with one or more remote devices of the intelligent device 108), the application 612 can receive input from such devices. These wired and wireless networks use more communication transceivers 630 and antennas 638 to provide network connectivity. The processing device 600 can also include various other components, such as a positioning system (e.g., a global positioning satellite transceiver), one or more accelerometers, one or more cameras, an audio interface (e.g., a microphone 634, an audio amplifier and speakers and / or an audio jack), and a storage device 628. Other configurations may also be employed.

[0077] The processing device 600 also includes a power source 616. The power source 616 is powered by one or more batteries or other power sources and supplies power to other components of the processing device 600. The power source 616 can also be connected to an external power source (not shown) or other power sources that cover or charge the built-in battery.

[0078] In an example implementation, the computing resources of the shared resource pool (e.g., elastic IoT hub resources) can include hardware and / or software, which is embodied by instructions stored in the memory 604 and / or the storage device 628 and processed by the (multiple) processor units 602. The memory 604 can be the memory of the host device or an attachment coupled to the host.

[0079] Processing device 600 may include various tangible computer-readable storage media and intangible computer-readable communication signals. The tangible computer-readable storage device may be embodied by any available medium accessible to processing device 600 and includes volatile and non-volatile storage media, removable and non-removable storage media. The tangible computer-readable storage medium does not include intangible and transient communication signals and includes volatile and non-volatile, removable and non-removable storage media implemented by any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. The tangible computer-readable storage medium includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CDROM, digital versatile disc (DVD) or other optical disc storage devices, magnetic tape cassettes, tapes, magnetic disk storage devices or other magnetic storage devices, or any other tangible medium that can be used to store the desired information and can be accessed by processing device 600. In contrast to the tangible computer-readable storage medium, the intangible computer-readable communication signal may embody computer-readable instructions, data structures, program modules or other data residing in a modulated data signal such as a carrier wave or other signal transmission mechanism. The term "modulated data signal" means a signal in which one or more of its characteristics are set or changed in an encoded manner. By way of example and not limitation, the intangible communication signal includes wired media such as a wired network or a direct wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

[0080] Some implementations may include articles of manufacture. An article of manufacture may include a tangible storage medium (memory device) for storing logic. Examples of storage media may include one or more types of processor-readable storage media capable of storing electronic data, including volatile memory or non-volatile memory, removable and non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. Examples of logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operational segments, methods, processes, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. In one implementation, for example, an article of manufacture may store executable computer program instructions that, when executed by a computer, cause the computer to perform the methods and / or operations according to the described implementations. The executable computer program instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The executable computer program instructions may be implemented according to a predefined computer language, manner, or syntax to instruct the computer to perform an operational segment. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

[0081] A method disclosed herein includes determining, for each of a plurality of tenants renting computing resources from a shared resource pool, a desired claim on resources in the shared resource pool. The desired claim is based on the number of received resource access requests associated with each of the plurality of tenants. The method also includes determining, for each of the plurality of tenants, a guaranteed claim and a maximum potential claim on the shared resource pool, and allocating a surplus resource pool among the plurality of tenants based on the determined maximum potential claims and desired claims for each of the plurality of tenants. The surplus resource pool represents the remainder of the shared resource pool after the guaranteed claims for each of the tenants are satisfied via an initial resource allocation from the shared resource pool.

[0082] Another example method of any of the foregoing methods further includes: in response to determining that the desired claim is less than or equal to the guaranteed claim, adjusting the guaranteed claim to be equal to the desired claim.

[0083] In yet another example method of any of the foregoing methods, the method further includes identifying unmet tenants, calculating an allocation ratio, and allocating a surplus resource pool among the identified unmet tenants based on the allocation ratio. Each unmet tenant among the identified unmet tenants is a tenant that, prior to the allocation of the surplus resource pool, had an expected claim that was not satisfied by the current distribution of resources from the shared resource pool. The allocation ratio is based on the size of the surplus resource pool and the difference between the maximum potential claim and the guaranteed claim for each unmet tenant among the identified unmet tenants.

[0084] In yet another example method of any of the foregoing methods, calculating the allocation ratio further includes calculating a maximum unit shortage for each unmet tenant among the unmet tenants and determining a weighted unit by adding together the maximum unit shortages for each unmet tenant among the unmet tenants. For example, the maximum unit shortage represents the difference between the maximum potential claim and the guaranteed claim, and the allocation ratio is based on the weighted unit.

[0085] In yet another example method of any of the foregoing methods, the allocation ratio represents the ratio between the size of the surplus resource pool and the weighted unit.

[0086] In yet another example method of any of the foregoing methods, the maximum potential claim can be dynamically changed by each of a plurality of tenants.

[0087] In yet another example method of any of the foregoing methods, the method further includes: after the time of allocation of the surplus resource pool, identifying an unmet tenant that has a resource allocation insufficient to satisfy an associated expected claim. Supplementing the surplus resource pool with the quantity of previously allocated resource units that was determined to exceed the associated expected claim of the tenant to whom the quantity of resource units was previously allocated, and reallocating the surplus resource pool among the identified unmet tenants based on the maximum potential claim associated with each tenant.

[0088] An example system disclosed herein includes a rebalancer that is stored in a memory and executable to determine, for each of a plurality of tenants renting computing resources of a shared resource pool, a desired claim on the resources in the shared resource pool. The desired claim is based on the number of resource access requests received at an endpoint associated with each of the plurality of tenants. A guaranteed claim and a maximum potential claim on the resources of the shared resource pool are determined for each of the plurality of tenants, and based on the determined maximum potential claims and desired claims for each of the plurality of tenants, a surplus resource pool is allocated among the plurality of tenants. The surplus resource pool represents the remainder of the shared resource pool after the guaranteed claims for each of the tenants are satisfied via an initial resource allocation from the shared resource pool.

[0089] In another example system of any of the foregoing systems, the rebalancer is further executable to adjust the guaranteed claim to be equal to the desired claim in response to determining that the desired claim is less than or equal to the guaranteed claim.

[0090] In yet another example system of any of the foregoing systems, the rebalancer is executable to allocate the surplus resource pool by: identifying one or more unsatisfied tenants, calculating an allocation ratio, and allocating the surplus resource pool among the identified unsatisfied tenants based on the allocation ratio. Each of the identified unsatisfied tenants is a tenant that, prior to the allocation of the surplus resource pool, has a desired claim on the current distribution of resources from the shared resource pool that is unsatisfied. The allocation ratio is calculated based on the size of the surplus resource pool and the difference between the maximum potential claim and the guaranteed claim for each of the identified unsatisfied tenants.

[0091] In yet another example system of any of the foregoing systems, the rebalancer is executable to calculate the allocation ratio by: calculating a maximum unit shortage for each of the unsatisfied tenants, determining weighted units, and calculating the allocation ratio based on the weighted units. For example, the maximum unit shortage represents the difference between the maximum potential claim and the guaranteed claim, and the weighted units are determined by adding together the maximum unit shortages for each of the unsatisfied tenants.

[0092] In yet another example system of any of the foregoing systems, the allocation ratio represents the ratio between the size of the surplus resource pool and the weighted units.

[0093] In yet another example system of any of the foregoing systems, the maximum potential claim can be dynamically changed by each of the plurality of tenants.

[0094] In yet another example system of any of the foregoing systems, the rebalancer may also be executed to identify unsatisfied tenants having a resource allocation insufficient to meet the associated desired claims; supplement a surplus resource pool with a quantity of previously allocated resource units determined to exceed the associated desired claims of a tenant to which the resource units were previously allocated; and redistribute the surplus resource pool among the identified unsatisfied tenants based on the maximum potential claims associated with each tenant.

[0095] In an example memory device encoding computer-executable instructions for performing a computer process, the computer process includes determining, for each of a plurality of tenants leasing computing resources of a shared resource pool, a desired claim for resources in the shared resource pool. The desired claim is based on the number of received resource access requests associated with each of the plurality of tenants. A guaranteed claim and a maximum potential claim for the shared resource pool are determined for each of the plurality of tenants, and a surplus resource pool is allocated among the plurality of tenants based on the maximum potential claim and the desired claim determined for each of the plurality of tenants. For example, the surplus resource pool represents the remainder of the shared resource pool after the guaranteed claims for each of the tenants are satisfied via an initial resource allocation from the shared resource pool.

[0096] In an example computer process of any of the foregoing computer processes, the computer process further includes adjusting the guaranteed claim to be equal to the desired claim in response to determining that the desired claim is less than or equal to the guaranteed claim.

[0097] In yet another example computer process of any of the foregoing computer processes, the computer process further includes identifying one or more unsatisfied tenants, calculating an allocation ratio, and distributing the surplus resource pool among the identified unsatisfied tenants based on the allocation ratio. Each unsatisfied tenant has a desired claim that is not satisfied by the current distribution of resources from the shared resource pool, and the allocation ratio is based on the size of the surplus resource pool and the difference between the maximum potential claim and the guaranteed claim for each of the identified unsatisfied tenants.

[0098] In yet another example computer process of any of the foregoing computer processes, the computer process further includes calculating a maximum unit shortage for each of the unsatisfied tenants, determining weighted units, and calculating an allocation ratio based on the weighted units. For example, the maximum unit shortage represents the difference between the maximum potential claim and the guaranteed claim, and the weighted units are determined by adding together the maximum unit shortages for each of the unsatisfied tenants.

[0099] In yet another example computer process of any of the foregoing computer processes, the allocation ratio represents the ratio between the size of the surplus resource pool and the weighted units.

[0100] In still another example computer process of any of the foregoing computer processes, the maximum potential claim is dynamically changeable by each of a plurality of tenants.

[0101] An example system disclosed herein includes means for determining, for each of a plurality of tenants renting computing resources of a shared resource pool, a desired claim on resources in the shared resource pool. The desired claim is based on the number of received resource access requests associated with each of the plurality of tenants. The method further includes means for determining, for each of the plurality of tenants, a guaranteed claim and a maximum potential claim on the shared resource pool. The method further includes means for allocating a surplus resource pool among the plurality of tenants based on the determined maximum potential claims and desired claims for each of the plurality of tenants. For example, the surplus resource pool represents the remainder of the shared resource pool after the guaranteed claims for each tenant are satisfied via an initial resource allocation from the shared resource pool.

[0102] The implementations described herein are implemented as logical steps in one or more computer systems. The logical operations may be implemented as (1) a sequence of processor-implemented steps executed in one or more computer systems, and (2) machine or circuit modules interconnected within one or more computer systems. The implementation approach is a matter of choice, depending on the performance requirements of the computer system utilized. Thus, the logical operations constituting the implementations described herein are variously referred to as operations, steps, objects, or modules. Additionally, it should be understood that the logical operations may be performed in any order, unless expressly stated otherwise or the claim language inherently requires a particular order. The foregoing specification, examples and data, and the appended appendix together provide a complete description of the structure and use of the exemplary implementations.

Claims

1. A method, comprising: Determining, for each of a plurality of tenants renting computing resources from a shared resource pool, a guaranteed claim and a desired claim for resources in the shared resource pool, the desired claim being based on the number of resource access requests received in association with each of the plurality of tenants; Identifying unmet tenants, where the desired claim of each unmet tenant is not satisfied by the current resource allocation of the shared resource pool; Calculating, for each unmet tenant among the unmet tenants, a maximum unit shortage, the maximum unit shortage representing the difference between the desired claim and the guaranteed claim; Calculating an allocation ratio for allocating a surplus resource pool, the allocation ratio being based on the amount of resources available in the surplus resource pool and the maximum unit shortage of each unmet tenant among the unmet tenants; And Allocating the surplus resource pool among the unmet tenants based on the desired claim of each unmet tenant among the unmet tenants and the allocation ratio.

2. The method according to claim 1, wherein the surplus resource pool represents the remainder of the shared resource pool after the guaranteed claim for each of the plurality of tenants is satisfied via an initial resource allocation from the shared resource pool.

3. The method according to claim 1, wherein the guaranteed claim is the amount of resources that are guaranteed to be allocated to a tenant when the center of each of the plurality of tenants is active.

4. The method according to claim 3, further comprising: In response to determining that the desired claim is less than or equal to the guaranteed claim, adjusting the guaranteed claim to be equal to the desired claim.

5. The method according to claim 1, wherein calculating the allocation ratio further comprises: Determining a weighted unit by summing the maximum unit shortages of each unmet tenant among the unmet tenants, the allocation ratio representing the ratio between the size of the surplus resource pool and the weighted unit.

6. The method according to claim 1, wherein the desired claim can be dynamically changed by each of the plurality of tenants.

7. The method according to claim 1, further comprising: After the allocation of the surplus resource pool, identifying unmet tenants that have a resource allocation insufficient to satisfy the associated desired claim; Supplementing the surplus resource pool with the number of previously allocated resource units, the number of resource units being determined to exceed the associated desired claim for a tenant to whom the number of resource units was previously allocated; and Reallocating the surplus resource pool among the identified unmet tenants based on the desired claim associated with each tenant.

8. A system, comprising: A tangible memory, A rebalancer, stored in the tangible memory and executable to: Determine, for each of a plurality of tenants that lease computing resources of a shared resource pool, a guaranteed claim and an expected claim for resources in the shared resource pool, the expected claim being based on the number of resource access requests received in association with each of the plurality of tenants; Identify unfulfilled tenants, the expected claim of each unfulfilled tenant not being satisfied by the current resource allocation of the shared resource pool; Calculate, for each unfulfilled tenant among the unfulfilled tenants, a maximum unit shortage, the maximum unit shortage representing the difference between the expected claim and the guaranteed claim; Calculate an allocation ratio for allocating a surplus resource pool, the allocation ratio being based on the amount of resources available in the surplus resource pool and the maximum unit shortage of each unfulfilled tenant among the unfulfilled tenants; And Allocate the surplus resource pool among the unfulfilled tenants based on the expected claim and the allocation ratio of each unfulfilled tenant among the unfulfilled tenants.

9. The system according to claim 8, wherein the surplus resource pool represents the remainder of the shared resource pool after satisfying the guaranteed claim for each of the plurality of tenants via an initial resource allocation from the shared resource pool.

10. The system according to claim 8, wherein the guaranteed claim is the amount of resources that are guaranteed to be allocated to the tenant when the center of each of the plurality of tenants is active.

11. The system according to claim 9, the rebalancer is further executable to: In response to determining that the expected claim is less than or equal to the guaranteed claim, adjust the guaranteed claim to be equal to the expected claim.

12. The system according to claim 8, the rebalancer is further executable to: Determine a weighted unit by summing the maximum unit shortages of each unfulfilled tenant among the unfulfilled tenants, and calculate the allocation ratio, the allocation ratio representing the ratio between the size of the surplus resource pool and the weighted unit.

13. The system according to claim 8, wherein the expected claim can be dynamically changed by each of the plurality of tenants.

14. The system according to claim 8, the rebalancer is further executable to: After the allocation of the surplus resource pool, identify unfulfilled tenants that have a resource allocation insufficient to satisfy the associated expected claim; Supplement the surplus resource pool with the number of previously allocated resource units, the number of resource units being determined to exceed the associated expected claim for a tenant to whom the number of resource units was previously allocated; and Reallocate the surplus resource pool among the identified unfulfilled tenants based on the expected claim associated with each tenant.

15. One or more storage devices, including a tangible computer-readable storage medium, wherein the tangible computer-readable storage medium encodes computer-executable instructions for performing a computer process, the computer process including: For each of a plurality of tenants that lease computing resources of a shared resource pool, determine a guaranteed claim and an expected claim for resources in the shared resource pool, the expected claim being based on the number of resource access requests received in association with each of the plurality of tenants; Identify unsatisfied tenants, where the expected claim of each unsatisfied tenant is not satisfied by the current resource allocation of the shared resource pool; Calculate the maximum unit shortage for each of the unsatisfied tenants among the unsatisfied tenants, the maximum unit shortage representing the difference between the expected claim and the guaranteed claim; Calculate an allocation ratio for allocating a surplus resource pool, the allocation ratio being based on the amount of resources available in the surplus resource pool and the maximum unit shortage of each of the unsatisfied tenants among the unsatisfied tenants; And Based on the expected claim and the allocation ratio of each of the unsatisfied tenants among the unsatisfied tenants, allocate the surplus resource pool among the unsatisfied tenants.

16. The one or more storage devices according to claim 15, wherein the surplus resource pool represents the remainder of the shared resource pool after satisfying the guaranteed claim for each of the plurality of tenants via an initial resource allocation from the shared resource pool.

17. The one or more storage devices according to claim 15, wherein the guaranteed claim is the amount of resources that are guaranteed to be allocated to a tenant when the center of each of the plurality of tenants is active.

18. The one or more storage devices according to claim 15, wherein the computer process further comprises: In response to determining that the expected claim is less than or equal to the guaranteed claim, adjust the guaranteed claim to be equal to the expected claim.

19. The one or more storage devices according to claim 15, wherein calculating the allocation ratio further comprises: Determine a weighted unit by summing the maximum unit shortages of each of the unsatisfied tenants among the unsatisfied tenants, the allocation ratio representing the ratio between the size of the surplus resource pool and the weighted unit.

20. The one or more storage devices according to claim 15, wherein the expected claim can be dynamically changed by each of the plurality of tenants.

Images