Elastic resource pooling for dynamic throughput rebalancing

Abstract

A method for dynamically rebalancing throughput using elastic resource pooling technology includes determining an expected claim on resources in a shared resource pool for each of a plurality of tenants that lease computing resources of the shared resource pool. The expected claim is based on the number of resource access requests received in association with each of the plurality of tenants. The method also includes determining a guaranteed claim and a maximum potential claim on the shared resource pool for each of the plurality of tenants; and based on the determined maximum potential claim and expected claim for each of the plurality of tenants, allocating a surplus resource pool among the plurality of tenants, the surplus resource pool representing the remainder of the shared resource pool after satisfying the guaranteed claim for each of the tenants via an initial resource allocation from the shared resource pool.

Description

Technical Field

[0001] The present application relates to the field of computer technology. 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 provides challenges in allocating computing resources to different tenants who rent those services. When resources are statically allocated between tenants, a large portion of the resources may not be used at any given time. In contrast, dynamic, need-based resource allocation methods tend to give priority to tenants with high activity, and may sometimes leave one or more tenants without computing resources sufficient to meet current computing needs. In addition, some tenants may be willing to purchase higher-cost packages so that they can always be guaranteed a set number of resource units or performance support levels. Current need-based resource allocation methods are not sufficient to provide such guarantees without over-allocating resources that are sometimes not used. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 A system utilizing elastic pooling technology to dynamically rebalance resources among multiple tenants sharing an IoT (Internet of Things) hub is illustrated.

[0004] Figure 2 Another system with a rebalancer is illustrated that utilizes elastic pooling technology to dynamically rebalance computing resources of a shared IoT hub among multiple tenants.

[0005] Figure 3 Illustrated are example operations for allocating elastically pooled computing resources among multiple tenants.

[0006] Figure 4 Example operations for allocating a surplus resource pool among multiple tenants that lease computing resources for a web-based software service are illustrated.

[0007] Figure 5A Illustrated are systems that perform example operations for dynamic throughput rebalancing among multiple IoT hubs that share an elastic resource pool.

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

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

[0010] Figure 5D Pictured Figure 5A-5C The system performs 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 elastically allocating a shared resource pool includes: determining an expected claim for a plurality of tenants of computing resources of a shared resource pool, such as based on the number of resource access requests received at an endpoint associated with each of the plurality of tenants. The method also includes determining a guaranteed claim and a maximum potential claim for the shared resource pool for each of the plurality of tenants, and allocating a surplus resource pool among the plurality of tenants based on the determined maximum potential claim and expected claim for each of the plurality of tenants.

[0013] This summary introduces some concepts in a simplified form, which will be further described in the following detailed description. This summary is not intended to identify the 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 SaaS (Software as a Service) providers to reserve a fixed amount of computing resources for each individual subscriber (also referred to herein as a "tenant") often suffer from massive inefficiencies 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 SaaS providers to dynamically allocate SaaS computing resources based on current demand. However, need-based resource allocation methods are often inconsistent with consumers' requests for a fixed cap that guarantees a minimum amount of SaaS resources available to them at any given time.

[0015] Existing resource allocation solutions do not adequately resolve the conflict between the need-based (dynamic) allocation methods described above, and static (non-dynamic) allocation methods that may allow different tenants to each set their own fixed minimum caps (such as by providing different SaaS subscription tiers associated with different fixed minimum caps). The technology disclosed herein provides a method for dynamically allocating a pool of shared computing resources among multiple tenants based on need-based demand, while also guaranteeing tenants both: (1) an individual fixed minimum cap on available resources; and (2) an individual fixed claim on a fraction of "surplus" resources. The solution allows full utilization of 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] As an example and not limitation, the disclosed technology is described herein with reference to a specific type of SaaS referred to as an IoT (Internet of Things) hub. Typically, an IoT hub provides services for managing data flows between one or more web-based IoT applications and smart devices managed by those IoT applications. For example, a web-based IoT application provider can rent an IoT hub and computing resources to facilitate the ingestion of large amounts of telemetry from smart devices to associated web-based IoT applications. In this context, the IoT hub acts as a central message hub for delivering two-way communications (e.g., device-to-cloud telemetry, cloud-to-device commands) between one or more IoT solutions and smart devices managed by these solutions. Each IoT hub can be provisioned with a certain number of resource units that affect the maximum daily quota of messages that the IoT hub can send to and from IoT solutions and smart devices.

[0017] Different web-based solution providers that rent IoT hubs and associated computing resources have very different activeness support needs. 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. Therefore, IoT hub providers face the challenge of allocating resource units to each IoT hub in a way that is cost-effective and fair to all tenants.

[0018] When resources are statically allocated among tenants, a large portion of the resources may be unused at any given time. In contrast, dynamic, need-based resource allocation approaches tend to prioritize high-activity tenants, which may leave one or more tenants of the IoT hub with insufficient device support to guarantee a set level during times of high activity. Furthermore, a purely need-based dynamic allocation solution may not be able to guarantee competitive uplink and downlink times to tenants willing to purchase a higher-cost IoT hub subscription package.

[0019] Figure 1 A system 100 is illustrated that utilizes elastic pooling techniques to dynamically rebalance resources among multiple tenants of a shared IoT hub 104. The shared IoT hub 104 generally represents multiple, individual IoT hubs, each of which 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 as representing a group of IoT centers, where each IoT center in the group is rented by one of six different tenants (labeled as Tenant #1-Tenant #6). For example, Tenant 1 has a first IoT center; Tenant 2 has a second IoT center, and so on. Each of the rented IoT centers within the shared IoT center 104 is supported by resources dynamically allocated from the shared resource pool 106.

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

[0021] In general, the term "smart device" is used herein to refer to electronic devices with processing and data transmission capabilities, and more specifically, devices managed by a corresponding IoT solution. By way of example and not limitation, Figure 1 Smart devices 108 are illustrated, including various types of home devices (e.g., smart light bulbs, smart sockets, smart thermostats, smart watches, smart earphones, and smart headphones). Each of the IoT solutions can effectively configure, control, command, or otherwise support user interaction with a subset of the smart devices 108. For example, a user can interact with a mobile application of one of the IoT solutions 110 to program a schedule for a smart light bulb, an electrical plug, etc.

[0022] The shared IoT hub 104 supports bidirectional 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 of the IoT solutions 110 associated with a different uniform resource identifier (URI) and the shared IoT hub 104 support data ingestion of the URI and messaging between the URI and the associated smart devices 108.

[0023] In one implementation, the shared resource pool 106 includes a number of total computing resource units that affects a maximum daily quota of messages that the IoT hub 104 can send and receive with smart devices 108 and associated IoT solutions 110. The system 100 includes a rebalancer 102 that dynamically allocates resource units of the shared resource pool 106 to different tenants based on the current activity of each tenant (e.g., based on need 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, an expected claim on the shared resource pool 106, a guaranteed claim on the shared resource pool 106, and a maximum potential claim on the surplus resources remaining in the shared resource pool 106 after the guaranteed resources are allocated. The expected claim is need-based. For example, the rebalancer 102 may evaluate access requests received at an ingestion endpoint associated with each tenant to determine the tenant's current expected claim on the resources of the shared resource pool 106. Conversely, the guaranteed claim and the maximum potential claim may be parameters associated with the tenant's profile that are preset by the tenant or the SaaS service.

[0025] In one implementation, the rebalancer 102 implements allocation logic for dynamically rebalancing the resources of the shared resource pool 106 among the tenants while ensuring, when possible, that the resulting allocations satisfy the expected claims of each of the tenants sharing the IoT hub 104. When the cumulative total of the expected claims on the shared resource pool 106 exceeds the availability of resources, the rebalancer 102 allocates resources among the tenants in a manner that ensures that: (1) all resources are allocated to provide support for current processing requests (e.g., no resources are "reserved" and unused), and (2) all resources are allocated to satisfy the guaranteed claims for each tenant while also amortizing surplus resources based on (e.g., in fair proportion to) each tenant's pre-specified maximum potential claim.

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

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

[0028] Figure 2 Another system 200 is illustrated with a rebalancer 202 that utilizes elastic pooling techniques to dynamically rebalance computing resources of a shared IoT hub 204 among multiple tenants. Each of the multiple tenants of the shared IoT hub 204 leases an IoT hub service for facilitating telemetry flow between smart devices and associated web-based IoT solutions managed by the tenant. In one implementation, the web-hosted IoT hub service provides software configuration to each tenant of the shared IoT hub 204 that effectively ingests data to a specific URI associated with an IoT solution (not shown) owned by the tenant.

[0029] exist Figure 2 , a 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 of the tenant centers are supported by resources in a 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 tenants of the shared IoT hub 204 can send to and from smart devices (not shown) and their associated IoT solutions. In Figure 2 In the example of , the shared resource pool 206 includes 200 resource units, which can be elastically allocated and reallocated dynamically based on the throughput in and out of each of the tenant centers 1-6.

[0030] exist Figure 2, the rebalancer 202 is shown as being included in the throttling engine 210. For each of 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 operations of a specific type that can be performed per minute by an individual resource unit in the resource units 212. 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 the like. For example, the resource units 212 can each support 120 device-to-cloud messages per minute (e.g., 120 operations / second / unit), while supporting 1.67 cloud-to-device messages per minute (e.g., 1.67 operations / second / unit).

[0031] Throughout each day, the rebalancer 202 dynamically changes the number of resource units 212 that are provisioned to service requests for each different one of the tenant centers. In one implementation, the rebalancer 202 dynamically rebalances the resource units 212 of the shared resource pool 206 among the different tenants based on the current activity of each tenant (e.g., based on need 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 real-time request information and certain subscription parameters for each of the multiple tenant centers.

[0032] During an example allocation of resource units 212 to tenant centers 1-4 of a shared IoT hub 204, the rebalancer 202 determines an expected claim, which may be understood as a need-based claim for a subset of resource units 212 of a shared resource pool 206. In one implementation, the expected claim for a specific tenant center is determined based on access requests received at an ingestion endpoint for the individual tenant center, and one or more current throttling limits associated with the ingestion endpoint. For example, an ingestion endpoint (not shown) for tenant center #1 may periodically transmit timestamp information and the number of requests received within a set time interval to the rebalancer. Based on the throttling configuration for the tenant center, the rebalancer 202 calculates a 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 center #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, rebalancer 202 can determine that the expected claim (e.g., sufficient computing capacity to handle the incoming requests) for tenant center #1 is 60 resource units.

[0033] The above examples involve a scenario where Tenant Hub #1 is receiving requests for a single message type governed by a single throttling rate. As mentioned above, some implementations may enforce different throttling limits for different types of messaging requests. Unless otherwise noted, the term "expected demand" is used herein to refer to the total computing capacity sufficient to meet the cumulative (total) current computing needs on an individual IoT Hub. For example, the expected demand for Tenant Hub #1 may be based on a calculation of the computing capacity necessary to meet the request rate for each of multiple different types of messages governed by different throttling rates.

[0034] In addition to determining the expected claim for resource units 212, rebalancer 202 also determines two pre-specified parameters that are not based on an evaluation of the current resource request rate: a "guaranteed claim" and a "maximum potential claim." Each of the guaranteed claim and the maximum potential claim may be set individually for each tenant, such as according to a preset subscription parameter selected by the tenant or according to a subscription tier to which each tenant has subscribed. For example, rebalancer 202 may evaluate each tenant's subscription parameters 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 high paying power 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] The guaranteed claim for a tenant center can be understood as a cap on the number 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 resources of the shared resource pool 206). In one implementation, each active tenant is allocated a guaranteed amount of resources sufficient to satisfy its expected claim as long as the expected claim is less than or equal to the tenant's guaranteed 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. "Surplus resources," as used herein, refers to a subset of resource units 212 that remain after the guaranteed resources are allocated to each of the active tenant centers.

[0036] In one implementation, the rebalancer 202 implements allocation logic for dynamically allocating resources of the shared resource pool 206 while ensuring, when possible, that the resulting allocations satisfy the desired claims of each of the tenants sharing the IoT hub 204. When the cumulative total of tenant requests to access resources exceeds the availability of resources in the shared resource pool 206, the rebalancer 102 allocates resources among the tenants in a manner that ensures that: (1) all resources are allocated to provide support for currently processing requests (e.g., no resources are "reserved" and unused), and (2) all resources are allocated to satisfy the guaranteed claims for each tenant while also amortizing surplus resources based on (e.g., in fair proportion to) each tenant's pre-specified maximum potential claim.

[0037] During an example allocation of resource units 212 among tenant centers #1 through #4, the rebalancer 202 identifies a subset of 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 an expected claim for each tenant center based on the current request rate. When the expected 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 expected claim (e.g., the guaranteed claim is adjusted to be equal to the expected claim). In the case when the expected 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, each active tenant is guaranteed resources sufficient to satisfy the desired claim as long as the desired claim is less than or equal to the guaranteed claim.

[0039] After allocating a guaranteed number of resource units 212 to each of the tenant centers in the above manner, the rebalancer 202 determines the size of the surplus pool—a subset of the remaining resource units 212. If, for example, there are initially 100 elastically pooled resource units, and Figure 2 If the guaranteed claims noted in 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 rebalancer 202 then allocates the surplus pool (e.g., 36 resource units in the above example) among the unsatisfied tenants based on both need-based (e.g., based on expected demand for each tenant center) and fairness-based (e.g., based on a preset maximum potential for each tenant center requesting additional resources) metrics. As used herein, an "unsatisfied tenant" refers to a tenant when the expected demand is not met by the current resource allocation. Figure 3 and Figure 4 Exemplary allocation processes and suitable metrics for achieving this are discussed in more detail.

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

[0042] In some implementations, the determining 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 expected demand can represent a total computing capacity sufficient to cumulatively satisfy the various determined request rates based on the current throttling configuration of the IoT hub.

[0043] Another determination operation 304 determines, for each of the plurality of tenants, a guaranteed claim and a maximum potential claim for resources of the shared resource pool. In one implementation, the guaranteed claim and the maximum potential claim are set individually for each tenant, such as based on a subscription parameter selected by the tenant or according to a subscription tier to which each tenant has subscribed. In some implementations, the guaranteed claim and the maximum potential claim may be changed dynamically by the tenant. For example, a tenant may 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 may determine (e.g., based on a tenant request) the guaranteed claim and the maximum potential claim during each iteration of resource allocation.

[0044] An adjust operation 306 adjusts the minimum guaranteed claim to represent the lower of the guaranteed claim and the desired claim for the shared computing resources. An allocate operation 308 allocates guaranteed resources, which may 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 a 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 the expected claim for each of the plurality of tenants. Figure 4 Example sub-operations of assign operation 312 are discussed in detail.

[0046] After the allocation operation 312, a parameter update operation 314 adjusts the expected demands for one or more tenants based on the current (updated) resource request rate. In response to adjusting one or more of the expected demands, operations 304, 306, 308, 310, and 312 repeat. In one implementation, the parameter update operation 314 is performed after a set time has passed after the allocation operation 312. For example, depending on system parameters, the parameter update operation 314 may 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 of the shared resource pool.

[0047] Figure 4 Example operations 400 are illustrated for allocating a surplus resource pool among a plurality of tenants renting computing resources for a web-based software service. In one implementation, operations 400 represent Figure 3 The following does not describe the sub-operations of the allocation operation 312. Figure 4 The aspects of the surplus resource pool described in detail can be compared with the above Figure 1-Figure 3In one implementation, the surplus resource pool represents: after the guaranteed number of elastic pooled resources is initially allocated to each of the active tenants (such as described above with respect to Figure 2 and Figure 3 The amount 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 (e.g., IoT hubs) that have desired claims that are not met by the current allocation of elastic pooled resources. In the following description, a tenant's desired claim is considered "unmet" when the number of resources or computing capacity allocated to the tenant is less than the number of resources or computing capacity required to meet the tenant's desired claim. For example, when the tenant's initial allocation of guaranteed resources (as described above with respect to Figure 3 A tenant can be considered "unsatisfied" when its IoT Hub services (described in [ 14 ]) are insufficient to support processing incoming IoT Hub requests at a rate equal to or exceeding the request rate.

[0049] For example, the tenants identified by identification operation 402 include tenants that have an initial allocation of less than the guaranteed resources they wish to claim from the shared resource pool. Figure 2 and Figure 3 Consistent with the description of , the expected request can represent the number of resource units from the shared resource pool that is sufficient to meet the current computing needs of the individual tenant. For example, the expected request can quantify the computing capacity that is sufficient to process incoming messages at a rate substantially equal to the rate at which the same messages are received at an endpoint (e.g., an ingestion endpoint of an IoT hub). In one implementation, the expected request is expressed as described above with respect to Figure 2 and Figure 3 Describes a consistent way to determine desired claims.

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

[0051] Another calculation operation 406 calculates another metric referred to herein as "weighted units" that represents the sum of the maximum unit shortage for each of the unsatisfied tenants. In one implementation, the weighted units is given by the following equation (1), where "n" represents the index of one of the identified unsatisfied tenants, and "M" is the total number of unsatisfied tenants.

[0052]

[0053] Yet another calculation operation 408 calculates a calculation allocation ratio based on the calculated sum (weighted units given by equation 1) and the size of the surplus resource pool. The allocation ratio generally represents the fraction of each tenant's expected claim 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 calculated via calculation operation 406.

[0054]

[0055] The allocation operation 410 allocates the surplus units in the surplus resource pool among the unsatisfied tenants based on the calculated allocation ratio and each tenant's expected claim on the shared resource pool. According to one implementation, the surplus allocation for a particular tenant is given by the following equation (3).

[0056] Allocated surplus (tenant (n)) = expected demand (tenant (n)) × allocation ratio (3)

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

[0058] Operations 402-414 may be repeated a set number of times, or until determination operation 412 determines that there are no tenants with current resource allocations that exceed 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 current resource allocations that exceed the desired claim, a wait operation 416 is assumed to wait for a change in the desired claim and a subsequent guaranteed resource allocation (e.g., based on the desired claim). Figure 3 ), at which point operation 400 restarts.

[0059] Figure 5A -5D illustrates example allocation steps that generally illustrate the above Figure 3-Figure 4 discussed. Figure 5A A system 500 is illustrated that performs example allocation operations for dynamic throughput rebalancing among multiple IoT hubs that share an elastic resource pool 504 .

[0060] System 500 includes a rebalancer 502 that dynamically re-provisions computing resources of an elastic resource pool 504 among 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, the rebalancer 502 determines the expected demand associated with each active IoT hub in the IoT hub. Because hubs B and C are idle, the rebalancer 502 determines the expected demand (expected operating capacity) for hub A. In one implementation, the rebalancer 502 determines one or more request rates for hub A and calculates the expected demand based on the request rate(s). For example, the rebalancer 502 may periodically record timestamp information and the number of requests for each of one or more target types made to each hub within a known interval. Using this information, the rebalancer 502 can determine the request rate for each target type requested and calculate the expected demand on the capacity of the elastic pool.

[0062] In the illustrated example, the rebalancer 502 determines that hub A has an expected claim of 5 resource units. The rebalancer 502 determines that hub A has a guaranteed claim of 1 resource unit and a maximum potential claim of 100 resource units. Figure 4Following the outlined logic steps, the 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 an allocation ratio that represents the fraction of the desired claim of hub A that will be allocated from the surplus pool 508 to hub A. The allocation ratio is based on the guaranteed claim and the maximum potential claim of each active tenant.

[0063] To determine the allocation ratio, the rebalancer 502 first calculates the maximum unit shortage for each of the active tenants. Here, center A has a 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 shortage for each of the active tenants). Because center A is the only active tenant at this point in time, the weighted units for the 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 expected claim of center A by the allocation ratio (e.g., 5×1), and allocates 5 of the surplus units to center A. After this allocation, center A has 6 resource units (1 guaranteed + 5 surplus). This exceeds the desired take of 5, so one resource unit is returned to surplus pool 508, leaving center A with 5 total units and 95 resource units in surplus pool 508.

[0064] Figure 5B The system 500 is shown following the Figure 5A Further allocation operations for dynamic throughput rebalancing are performed in accordance with the example operations discussed. At a point in time following the allocation of 5 resource units to hub A described above, the request rate for hub A increases. Hub A determines that the currently allocated 5 resource units are insufficient to satisfy the increased request rate and, therefore, transmits another resource request 512. Hubs B and C remain idle.

[0065] To answer request 512, rebalancer 502 determines an expected claim sufficient to satisfy the request rate for hub A. This time, rebalancer 502 determines that hub A has an expected claim of 100 total resource units. Rebalancer 502 allocates the guaranteed claim (e.g., 1 resource unit) and determines the surplus (e.g., 100-1=99 resource units). Rebalancer 502 calculates a maximum unit shortage for each of the active tenants (e.g., hub A has a maximum unit shortage of 100-1=99 resource units). Rebalancer 502 calculates a weighted unit (the sum of the maximum unit shortage for each of the active tenants). Because hub A is still the only active tenant at this point in time, the weighted unit for the surplus distribution is given by 100-1, or 99. The rebalancer 502 calculates the distribution ratio between the surplus and the weighted units (99 / 99), and multiplies this ratio (1) by the expected claim of center A, awarding all units of the remaining 99 units in center A's surplus pool.

[0066] Figure 5C The system 500 is shown in FIG. Figure 5A-Figure 5B Further allocation operations for dynamic throughput rebalancing are performed after the example operations discussed. Figure 5C , the rebalancer 502 receives resource requests from hub B and hub C. Because hub A was previously allocated 100% of the units in the elastic resource pool 504, the rebalancer 502 responds to the request by performing an action to reallocate the resources of the elastic resource pool 504 among the hubs. The rebalancer 502 identifies the desired claim associated with each active IoT hub among the IoT hubs—hub A, hub B, and hub C. Here, the rebalancer 502 identifies that hub A has a desired claim of 100 resource units; hub B has a desired claim of 20 resource units; and hub C has a desired claim of 30 resource units.

[0067] The rebalancer 502 begins rebalancing by reallocating guaranteed resources to each of the active centers. Because each of the centers has a desired claim that is greater than its guaranteed claim, the rebalancer 502 allocates the guaranteed claims. In an alternative throughput rebalancing scenario where one of the centers has a desired claim that is less than its guaranteed claim, the rebalancer 502 can adjust the guaranteed claim to be equal to the desired claim and allocate that amount. Figure 5C , center A is guaranteed 1 resource unit; center B is guaranteed 10 resource units; and center C is guaranteed 20 resource units. The rebalancer 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 guaranteed resource units, the rebalancer 502 identifies "unsatisfied tenants", or tenants whose expected demands are not met by the current resource allocation. Here, each of the centers A, B, and C is unsatisfied, so the rebalancer 502 will determine how the surplus pool (69 resource units) is to be shared among all three centers (e.g., portions x, y, and z) based on allocation ratios determined based on fairness considerations (e.g., the maximum potential demand and guaranteed demand for each tenant) and the expected demand of each center in the center.

[0069] The rebalancer 502 then determines an allocation ratio to determine the number of fractions of its associated desired claim that each tenant can be allocated. As in the example above, the rebalancer 502 determines the weighted units, or the sum of (potential maximum 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 to each center from the surplus pool 508), 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 The system 500 is shown in FIG. Figure 5C The discussed example operation then performs further allocation operations for dynamic throughput rebalancing. After allocating guaranteed resources to each of centers A, B, and C and allocating surplus claims, 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 surplus units to the surplus pool from all centers with allocations that exceed the associated desired demands, the rebalancer 502 again identifies tenants that are not satisfied, or tenants whose desired demands are not satisfied by the current resource allocations. Here, the rebalancer determines that center C is satisfied, so the remaining surplus pool (3.8 units) will be shared between centers A and B.

[0073] Because the number of satisfied centers has changed, the rebalancer 502 calculates a new allocation ratio that represents the number of fractions of the associated expected claims that each of the unsatisfied centers can be allocated from the returned surplus (3.8 units). Following the same logic detailed above, the rebalancer 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 claim to allocate to each of hubs A and B, the rebalancer 502 multiplies the new allocation ratio by the desired claim for each hub. Here, hub A receives an additional surplus of 3.16 resource units and hub B receives an additional surplus of 0.63 resource units. After this allocation, hub A has a total claim of 50.16 resource units; hub B has a total claim of 19.83 resource units; and hub C has a total claim of 30 resource units. All units in the elastic pool have been allocated.

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

[0076] One or more applications 612 are loaded into the memory 604 and executed by the processor unit(s) 602 on the operating system 610. The applications 612 can receive input from various input local devices, such as microphone 634, input accessories 635 (e.g., keyboard, mouse, stylus, touch pad, game pad, racing wheel, joystick). In addition, the application ... ) with remotely located smart devices such as Figure 1The processing device 600 may 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 speaker, and / or an audio jack), and a storage device 628. Other configurations may also be used.

[0077] Processing device 600 also includes a power supply 616, which is powered by one or more batteries or other power sources and provides power to other components of processing device 600. Power supply 616 may also be connected to an external power source (not shown) or other power source that covers or charges internal batteries.

[0078] In an example implementation, the computing resources of the shared resource pool (e.g., elastic IoT hub resources) may include hardware and / or software embodied by instructions stored in memory 604 and / or storage 628 and processed by processor unit(s) 602. Memory 604 may be a memory of a host device or an accessory coupled to the host.

[0079] The processing device 600 may include various tangible computer-readable storage media and intangible computer-readable communication signals. Tangible computer-readable storage devices may be embodied by any available media that the processing device 600 can access, and include volatile and non-volatile storage media, removable and non-removable storage media. Tangible computer-readable storage media do not include intangible and transient communication signals, and include 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). Tangible computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disk (DVD) or other optical disk storage, cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other tangible media that can be used to store desired information and can be accessed by the processing device 600. In contrast to tangible computer-readable storage media, intangible computer-readable communication signals 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 that has one or more of its characteristics set or changed in a manner encoded in the signal. By way of example, and not limitation, intangible communication signals include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

[0080] Some implementations may include articles of manufacture. Articles of manufacture may include tangible storage media (memory devices) 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 or non-volatile memory, removable and non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of logic may include various software elements, such as software components, programs, applications, computer programs, applications, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operating segments, methods, processes, software interfaces, application program interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. In one implementation, for example, articles of manufacture may store executable computer program instructions, which, when executed by a computer, cause the computer to perform methods and / or operations according to the described implementations. 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, etc. Executable computer program instructions can be implemented according to a predefined computer language, manner or syntax to instruct a computer to perform a certain operation segment. Instructions can 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 that lease computing resources of a shared resource pool, an expected claim on resources in a shared resource pool. The expected claim is based on a 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 claim and the expected claim for each of the plurality of tenants. The surplus resource pool represents a remainder of the shared resource pool after the guaranteed claim for each of the tenants is 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 unsatisfied tenants, calculating an allocation ratio, and allocating the surplus resource pool among the identified unsatisfied tenants based on the allocation ratio. Each unsatisfied tenant among the identified unsatisfied tenants is a tenant that has an expected claim that is not satisfied by the current distribution of resources from the shared resource pool before allocating the surplus 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 unsatisfied tenant among the identified unsatisfied tenants.

[0084] In yet another example method of any of the foregoing methods, calculating the allocation ratio further comprises calculating a maximum unit shortage for each of the unsatisfied tenants, and determining a weighted unit by adding together the maximum unit shortage for each of the unsatisfied tenants. For example, the maximum unit shortage represents a difference between a maximum potential claim and a 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 a ratio between the size of the surplus resource pool and the weighted units.

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

[0087] In yet another example method of any of the foregoing methods, the method further comprises: after a time of allocation of the surplus resource pool, identifying unsatisfied tenants having resource allocations insufficient to satisfy associated expected claims, replenishing the surplus resource pool with a number of previously allocated resource units determined to exceed the associated expected claims of the tenants to which the number of resource units was previously allocated, and reallocating the surplus resource pool among the identified unsatisfied tenants based on a maximum potential claim associated with each tenant.

[0088] An example system disclosed herein includes a rebalancer stored in a memory and executable to determine an expected claim on resources in a shared resource pool for each of a plurality of tenants that lease computing resources of the shared resource pool. The expected claim is based on a 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 resources of 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 determined maximum potential claim and expected claim for each of the plurality of tenants. The surplus resource pool represents a remainder of the shared resource pool after the guaranteed claim for each of the tenants is satisfied via an initial resource allocation from the shared resource pool.

[0089] In another example system of any of the foregoing systems, the rebalancer may be further executable to, in response to determining that the desired claim is less than or equal to the guaranteed claim, adjust the guaranteed claim to be equal to the desired 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 unsatisfied tenant in the identified unsatisfied tenants is a tenant that has an expected claim that is not satisfied by the current distribution of resources from the shared resource pool prior to allocation of the surplus resource pool. 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 unsatisfied tenant in 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 a weighted unit, and calculating the allocation ratio based on the weighted unit. For example, the maximum unit shortage represents a difference between a maximum potential claim and a guaranteed claim, and the weighted unit is determined by adding together the maximum unit shortage for each of the unsatisfied tenants.

[0092] In yet another example system of any of the foregoing systems, the allocation ratio represents a ratio between a 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 altered by each of the plurality of tenants.

[0094] In yet another example system of any of the foregoing systems, the rebalancer may also be executable to identify unsatisfied tenants having resource allocations that are insufficient to satisfy associated expected claims; replenish a surplus resource pool with a number of previously allocated resource units that is determined to exceed the associated expected claims of tenants to whom the number of resource units was previously allocated; and reallocate the surplus resource pool among the identified unsatisfied tenants based on a maximum potential claim associated with each tenant.

[0095] In an example memory device encoding computer executable instructions for performing a computer process, the computer process includes determining an expected claim on resources in a shared resource pool for each of a plurality of tenants that rent computing resources of the shared resource pool. The expected claim is based on a number of received resource access requests associated with each of the plurality of tenants. A guaranteed claim and a maximum potential claim on 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 expected claim determined for each of the plurality of tenants. For example, the surplus resource pool represents a remainder of the shared resource pool after the guaranteed claim for each of the tenants is 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, 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.

[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 allocating the surplus resource pool among the identified unsatisfied tenants based on the allocation ratio. Each unsatisfied tenant has an expected claim that is not satisfied by a current distribution of resources from the shared resource pool, and the allocation ratio is based on a size of the surplus resource pool and a difference between a maximum potential claim and a 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 comprises calculating a maximum unit shortage for each of the unsatisfied tenants, determining a weighted unit, and calculating the allocation ratio based on the weighted unit. For example, the maximum unit shortage represents a difference between a maximum potential claim and a guaranteed claim, and the weighted unit is determined by adding together the maximum unit shortage for each of the unsatisfied tenants.

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

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

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

[0102] The implementation described herein is implemented as logical steps in one or more computer systems. Logical operations can be implemented as (1) a sequence of processor-implemented steps executed in one or more computer systems, and (2) a machine or circuit module interconnected within one or more computer systems. The implementation is a matter of choice, which depends on the performance requirements of the computer system utilized. Therefore, the logical operations that constitute the implementation described herein are variously referred to as operations, steps, objects, or modules. In addition, it should be understood that the logical operations can be performed in any order unless otherwise explicitly stated, or the claim language inherently requires a specific order. The above description, examples, and data, together with the attached appendix, provide a complete description of the structure and use of the exemplary implementation.

Claims

1. A method for elastically allocating a shared resource pool, comprising: determining, for each of a plurality of tenants that lease computing resources of the shared resource pool, an expected claim for resources in the shared resource pool, the expected claim being based on a number of resource access requests received in association with each of the plurality of tenants; determining, for each of the plurality of tenants, a guaranteed claim and a maximum potential claim on the shared resource pool, the guaranteed claim being an amount of resources guaranteed to be allocated to one or more of the plurality of tenants when a hub for the one or more tenants is active; for each of the one or more of the plurality of tenants, while the hub for the one or more of the plurality of tenants is inactive, reducing the guaranteed claim, the reducing being performed while still providing an automatic future increase of the guaranteed claim when the hub becomes active, the automatic future increase adjusting the guaranteed claim to be equal to the lesser of the desired claim and an initial value of the guaranteed claim; as well as Based on the determined maximum potential claim and the expected claim for each of the plurality of tenants, a surplus resource pool is allocated among the plurality of tenants, the surplus resource pool representing a 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.

2. The method according to claim 1, wherein allocating the surplus resource pool further comprises: Identifying unsatisfied tenants, for each unsatisfied tenant, the desired request is not satisfied by the current distribution of resources from the shared resource pool; as well as calculating an allocation ratio based on the size of the surplus resource pool and a difference between the maximum potential claim and the guaranteed claim for each of the identified unsatisfied tenants; and The surplus resource pool is allocated among the identified unsatisfied tenants based on the allocation ratio.

3. The method according to claim 2, wherein calculating the allocation ratio further comprises: calculating a maximum unit shortfall for each of the unsatisfied tenants, the maximum unit shortfall representing the difference between the maximum potential claim and the guaranteed claim; as well as A weighted unit is determined by adding together the maximum unit shortfall for each of the unsatisfied tenants, and the allocation ratio is based on the weighted unit. The method according to claim 3 , wherein the allocation ratio represents a ratio between the size of the surplus resource pool and the weighted units.

5. The method of claim 1, wherein the maximum potential claim is dynamically changeable by each of the plurality of tenants.

6. The method according to claim 1, further comprising: After said allocating of said surplus resource pool, identifying unsatisfied tenants having resource allocations insufficient to satisfy associated said desired claims; replenishing the surplus resource pool with a number of previously allocated resource units, the number of previously allocated resource units being determined to exceed the associated expected claims for tenants that were previously allocated the number of resource units; and The surplus resource pool is reallocated among the identified unsatisfied tenants based on the maximum potential claim associated with each tenant.

7. A computer system comprising: Tangible storage, a rebalancer stored in the tangible memory and executable to: determining, for a plurality of tenants leasing computing resources of a shared resource pool, an expected claim on resources in the shared resource pool, the expected claim based on a number of resource access requests received at an endpoint associated with each of the plurality of tenants; determining, for each tenant of the plurality of tenants, a guaranteed claim and a maximum potential claim for the resource of the shared resource pool, the guaranteed claim being an amount of resources guaranteed to be allocated to one or more tenants of the plurality of tenants when a hub of the one or more tenants is active; For each of the one or more tenants among the plurality of tenants, when the center of the one or more tenants among the plurality of tenants is inactive, reducing the guaranteed claim while still providing an automatic future increase of the guaranteed claim when the hub becomes active, the automatic future increase adjusting the guaranteed claim to be equal to the lesser of the expected claim and an initial value of the guaranteed claim; as well as Based on the determined maximum potential claim and the expected claim for each of the plurality of tenants, a surplus resource pool is allocated among the plurality of tenants, the surplus resource pool representing a 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.

8. The system of claim 7, wherein the rebalancer is executable to allocate the surplus resource pool by: identifying one or more unsatisfied tenants, the desired claim for each unsatisfied tenant not being satisfied by a current distribution of resources from the shared resource pool; and calculating an allocation ratio based on the size of the shared resource pool and a difference between the maximum potential claim and the guaranteed claim for each of the identified unsatisfied tenants; and The surplus resource pool is allocated among the identified unsatisfied tenants based on the allocation ratio.

9. The system of claim 8, wherein the rebalancer is executable to calculate the allocation ratio by: calculating a maximum unit shortfall for each of the unsatisfied tenants, the maximum unit shortfall representing a difference between the maximum potential claim and the guaranteed claim; and A weighted unit is determined by adding together the maximum unit shortfall for each of the unsatisfied tenants, and the allocation ratio is based on the weighted unit. 10 . The system of claim 9 , wherein the allocation ratio represents a ratio between the size of the surplus resource pool and the weighted units.

11. The system of claim 8, wherein the maximum potential claim is dynamically changeable by each of the plurality of tenants.

12. The system of claim 8, wherein the rebalancer is further executable to: After said allocating of said surplus resource pool, identifying unsatisfied tenants having resource allocations insufficient to satisfy associated said desired claims; replenishing the surplus resource pool with a number of previously allocated resource units, the number of previously allocated resource units being determined to exceed the associated expected claims for tenants that were previously allocated the number of resource units; and The surplus resource pool is reallocated among the identified unsatisfied tenants based on the maximum potential claim associated with each tenant.

13. One or more memory devices comprising a tangible computer-readable storage medium encoding computer-executable instructions for performing a computer process comprising: determining, for each of a plurality of tenants leasing computing resources of a shared resource pool, an expected claim on resources in the shared resource pool, the expected claim being based on a number of resource access requests received in association with each of the plurality of tenants; determining, for each of the plurality of tenants, a guaranteed claim and a maximum potential claim on the shared resource pool, the guaranteed claim being an amount of resources guaranteed to be allocated to one or more of the plurality of tenants when a hub for the one or more tenants is active; for each of the one or more of the plurality of tenants, while the hub for the one or more of the plurality of tenants is inactive, reducing the guaranteed claim, the reducing being performed while still providing an automatic future increase of the guaranteed claim when the hub becomes active, the automatic future increase adjusting the guaranteed claim to be equal to the lesser of the desired claim and an initial value of the guaranteed claim; as well as Based on the determined maximum potential claim and the expected claim for each of the plurality of tenants, a surplus resource pool is allocated among the plurality of tenants, the surplus resource pool representing a 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.

14. The one or more memory devices of claim 13, wherein the computer process further comprises: Identifying unsatisfied tenants, for each unsatisfied tenant, the desired request is not satisfied by the current distribution of resources from the shared resource pool; as well as calculating an allocation ratio based on the size of the surplus resource pool and a difference between the maximum potential claim and the guaranteed claim for each of the identified unsatisfied tenants; as well as The surplus resource pool is allocated among the identified unsatisfied tenants based on the allocation ratio.

15. The one or more memory devices of claim 14, wherein the computer process further comprises: calculating a maximum unit shortfall for each of the unsatisfied tenants, the maximum unit shortfall representing the difference between the maximum potential claim and the guaranteed claim; as well as A weighted unit is determined by adding together the maximum unit shortfall for each of the unsatisfied tenants, and the allocation ratio is based on the weighted unit.

16. The one or more memory devices of claim 15, wherein the allocation ratio represents a ratio between a size of the surplus resource pool and the weighted units.

17. The one or more storage devices of claim 13, wherein the maximum potential claim is dynamically changeable by each of the plurality of tenants.

Images