Method and system for workload routing in a cloud (17-Nov-2009)

Method and system for workload routing in a cloud

Disclosed is a method and system of workload placement in a geographically disparate cloud. A cloud-based environment needs to be geographically dispersed so that resources can be made available to users at the right location at the right time with the protection from vulnerabilities due to catastrophes. This introduces technical challenges when it comes to placement of the workload in the cloud where resources can change dynamically over time. Centralized workload placement is one solution, but is subject to performance constraints, disruptions in network and effects of scale and latency
[1],[2],[3].

In a preferred embodiment, users access the resource region nearest them with a workload request [4],[5],[6]. Each region has both resources, and a workload scheduler which is:
1) aware of the resources within its region, through discovery, monitoring, registration, etc.
2) aware of the resources within neighboring regions, through communications with schedulers associated with the neighboring regions.

As an example, Figure 1 shows resource regions and their associated schedulers. Note that the scheduler function may be packaged in a gateway, network device, or management device.

Scheduler

Resource

Figure 1

Each scheduler exchanges load information about resources with its closest neighboring schedulers as shown in Figure 2. S1 through S4 are schedulers, each associated with a set of resources available for workload placement. S2 has knowledge of the resources in the regions of S1 and S3. S4 has knowledge only of resources in its

1

S1

S2

S3

S4

own region and that of S3.

Figure 2

When a user submits a workload request, either directly to a scheduler or reaching the scheduler through other means (e.g. a preferred workload router, a geographical optimizer, etc.), the request is honored locally or via a neighboring region that has the resources necessary to satisfy the workload requirement as follows:
Case 1: Resources are available within the managed region: Here the scheduler satisfies the request locally.

Case 2: Resources are not available within the managed region, but are available in a neighboring region (e.g. a region for which the first scheduler has resource knowledge): The scheduler propagates the request to the closest neighboring region with the necessary resources. That is, the request is sent to the scheduler of that region. "Closest neighboring region" may be defined in terms of geographical distance, bandwidth available, etc.

Case 3: Resources are not available in the first region, nor in any neighboring region: The scheduler propagates the workload to a neighboring region. The neighboring scheduler has resource information about a differing set of regions and attempts to satisfy the requirements with one of them. The selection of the neighbor may be random, geographically based (e.g. farthest neighbor), round robin, etc....