This patent application claims priority under 35U.S. c. § 119 of U.S. provisional patent application No. 60/908,350 entitled "economic allocation and Management of Resources Via a Virtual resource emarket", filed on 27/3/2007, the entire disclosure of which is hereby incorporated by reference herein in its entirety.
Detailed Description
Aspects of the exemplary embodiments will be described with reference to the drawings, wherein like numerals represent like elements.
FIG. 1 is a block diagram depicting a system 100 for allocating and managing distributed computing resources according to an exemplary embodiment of the invention. The system 100 will be discussed in more detail with reference to the methods shown in fig. 2-9 and 11.
FIG. 2 is a flow chart depicting a method 200 for allocating and managing distributed computing resources in accordance with an exemplary embodiment of the present invention. The method 200 will be described with reference to fig. 1 and 2.
According to an exemplary embodiment, the distributed computing resources may be resources of an enterprise organization. In this case, the users of the resource are members of the organization. Or the distributed computing resources may be resources of multiple organizations coupled to a central system to allocate those resources.
As shown in step 205 of fig. 2, the resource broker device (resource broker)102 monitors distributed computing resources for providing computing services to identify resource capabilities that are available to run one or more applications. In an exemplary embodiment, the distributed computing resources may include physical computing resources 103, such as an operational fabric 104, a network fabric 106, and a storage fabric 108. Each compute fabric 104, network fabric 106, and storage fabric 108 may contain one or more virtual resources 109 configured to provide services. For example, as shown in FIG. 1, the compute fabric 104 includes virtual compute fabrics C1 and C2, the network fabric 106 includes virtual network fabrics N1 and N2, and the storage fabric 108 includes virtual storage fabrics S1 and S2.
In an exemplary embodiment, the resource broker 102 may contain software modules that run in a distributed computing environment and serve as an interface between the virtual resources 109 and the marketplace exchange 112.
In step 210, resource broker 102 creates a bid for each resource to provide available virtual resources 109 at a specified price per unit of performance. Such a offer is referred to herein as a "resource offer 110" 110. One or more resource offers 110 may be created for each of the structures 104, 106, 108. For example, as shown in FIG. 1, the resource offer 110 includes an operational structure C1Three offer and calculation structure ofC2Two offer-on-demand, network architecture N1Three requests for sale, network structure N2Two request for sale, storage structure S1Three orders and storage structure S2Two offers for sale. Step 210 will be described in further detail below with reference to fig. 3.
Then, in step 215, the resource broker device 102 communicates the resource offer 110 to the marketplace exchange 112. In an exemplary embodiment, the marketplace exchange 112 may contain software modules that run in a distributed computing environment and that act as an interface between the resource broker 102 and the requirements broker 114.
In step 220, the requirements broker 114 identifies the service level resource requirements needed to run the application. In an exemplary embodiment, the required resources may include computing, network, and storage resources, such as one or more of the operational structures 104, network structures 106, and storage structures 108 shown in fig. 1. The application may conform to an established architecture such as typical application architecture 116. The exemplary typical application architecture shown in fig. 1 comprises a message center shown as typical architecture a, n-tier applications shown as typical application architecture B, and a compute farm shown as typical application architecture C. Other application architectures are also within the scope of the present invention. Step 220 will be described in further detail below with reference to fig. 4.
In an exemplary embodiment, the requirements broker 114 can comprise a software module that runs in a distributed computing environment and serves as an interface between applications and the marketplace exchange 112.
In step 225, a bid is created for purchasing the resource units needed to meet the application service level requirements. Such a purchase offer is referred to herein as a "demand purchase offer 118". One or more demand purchase offers 118 may be created for each application. For example, as shown in FIG. 1, the demand purchase offers 118 include a purchase offer for a computing structure, a purchase offer for a network structure, and a purchase offer for a storage structure for each of the exemplary architectures A, B, C. Step 225 will be described in further detail below with reference to fig. 5.
In step 230, the demand broker 114 communicates the demand bid 118 to the marketplace exchange 112. The marketplace exchange 112 then matches the resource offer 110 to the demand purchase offer 118 to determine an economical and efficient allocation of resources to each application in step 235. Step 235 will be described in further detail below with reference to fig. 6.
In step 240, the marketplace exchange 112 allocates resources needed by the application based on the matching offer and the bid completion transaction. Step 240 will be described in further detail below with reference to fig. 7.
In step 245, the operation of the application is migrated to the allocated resources. Step 245 will be described in further detail below with reference to fig. 8.
In step 250, the demand broker 114 monitors the performance of the allocated resources and the service level requirements of each application to ensure that the performance of the allocated resources meets the service level requirements of each application. Step 250 will be described in further detail below with reference to fig. 10.
In step 255, based on the performance monitoring accomplished in step 250, the demand broker 114 determines whether the allocated resources are under-utilized or performing poorly with reference to the service level requirements of the particular application. If so, the method 200 forks back to step 225 to obtain a new resource that meets the application service level requirements. If the requirements broker 114 determines in step 255 that the allocated resources meet the application service level requirements, the method forks to step 260.
In step 260, the method 200 determines whether the execution of the application is complete. If not, the method 200 branches back to step 250 to continue monitoring the performance of the allocated resources and the service level requirements of the application. If the method 200 determines in step 260 that the execution of the application is complete, the method 200 branches to step 265 where the operation of the application is removed from the allocated resources in step 265.
The method 200 also includes managing maintenance, procurement, and de-funding of resources based on the allocation of resources for a predetermined period of time, as shown in step 270 of FIG. 1. Step 270 is described in further detail below with reference to FIG. 11.
FIG. 3 is a flowchart describing a method 210 for creating a bid offer for each virtual resource 109 to provide an available virtual resource 109 at a specified price per unit of performance, as referenced in step 210 of FIG. 2, in accordance with an exemplary embodiment of the present invention. The method 210 will be described with reference to fig. 1 and 3.
In step 305, the resource broker device 102 selects the physical resources 103 available to the application. For example, resource broker 102 may select computational, network, or storage resources, such as computational fabric 104, network fabric 106, and storage fabric 108. In an exemplary embodiment, resource broker 102 may monitor usage of each resource to identify an unused excess capacity of each resource. Such excess capacity may be identified as resources available to the application.
The resource broker 102 then identifies an amount of the selected physical resource 103 that is available for use by the application in step 310. In an exemplary embodiment, the amount of each resource may include the type and/or configuration of hardware, including the particular manufacturer and/or component, and the excess capacity currently available for each resource. In this regard, the available physical resources 103 may be combined to create a virtual resource 109, such as virtual operation structure C1、C2Virtual network architecture N1、N2And a virtual storage structure S1、S2. For example, available computer processors at distributed locations may be aggregated to create virtual computing resources available to an application. Representative resource capabilities may include CPU cycles for computing resources, bandwidth for network resources, and disk space and/or memory for storage resources。
The amount of available resources may also include performance and reliability characteristics associated with each virtual resource 109. For example, such characteristics may include execution time, response time, result accuracy (e.g., error rate), availability, reliability, security, or other suitable characteristics that indicate performance of virtual resource 109.
In step 315, resource broker device 102 identifies a unit amount of virtual resource 109 to include a sale offer for providing virtual resource 109 for use by an application. In this regard, the resource broker 102 can identify portions of the virtual resources 109 that can be allocated in increments of the identified units up to a maximum amount of the virtual resources 109 available. If the resource broker 102 identifies multiple virtual resources 109 in step 310, such as virtual operation structures C1, C2, the resource broker 102 may identify a unit amount for each virtual resource 109.
In step 320, a price is established for each unit of virtual resource 109, and each unit of virtual resource 109 is to be included in the offer to provide virtual resource 109 for use by the application. In an exemplary embodiment, the resource broker 102 may calculate the price of a unit virtual resource 109 based on resource complexity, cost data, supply, demand, or other economic data entered into the resource broker 102 by a user or obtained by the resource broker 102 based on historical data of completed resource allocation transactions. For example, more complex resources may be more expensive than less complex resources, and high demand resources may be more expensive than low demand resources. The price may comprise a monetary amount of the resource sold for use by the application. Or the value may represent the perceived value of the resource that is not based on the actual monetary value. For example, the perceived value may be based on business needs and priorities established within the business enterprise.
In step 325, the resource broker device 102 generates one or more resource offers 110 for providing the available virtual resources 109 for use by the application. Based on the information obtained in step 310-320, the resource offer 110 may specify the virtual resource 109, the amount of available virtual resource 109 (including capacity and performance), and the price per unit of the virtual resource 109.
In step 330, the resource broker device 102 determines whether a resource offer 110 is to be generated for another virtual resource 109. For example, if the resource broker 102 has generated resource offers 110 only for the available computing structures 104, the resource broker 102 may decide to generate resource offers 110 for the available network and storage structures 106 and 108. In this case, the method 210 branches back to step 305 to generate a resource offer 110 for another resource. If the method 210 determines in step 330 that a resource offer 110 is not to be generated for another virtual resource 109, the method 210 branches to step 215 (FIG. 2).
FIG. 4 is a flowchart describing a method 220 for identifying service level requirements needed to run an application, as mentioned in step 220 of FIG. 2, according to an exemplary embodiment of the invention. The method 220 will be described with reference to fig. 1 and 4.
In step 405, an application is selected. The specific service level requirements of the selected application are then identified in step 410-.
In step 410, an available budget for the running application is identified. In an exemplary embodiment, the budget may be input by a user of the application and designed to meet the user's budget constraints. For example, the user may enter an available budget for running a particular program based on known funds for that application. In another exemplary embodiment, the budget information may include a value associated with running the application. The value may comprise a monetary amount that the user is willing to pay to obtain the resources necessary to run the application. Or the value may represent a perceived value of the application that is not based on the actual monetary value. For example, the perceived value may be based on a priority of operation of the application to the user and/or to other users running additional applications in the distributed computing environment. Budget restrictions may be provided in several alternative forms, such as a command to obtain the best available resource regardless of cost, to obtain the cheapest resource, to obtain the resource at a specified total or per unit of resource price, or to obtain the resource through another suitable budget form.
In step 415, a time period during which the application must run is identified. In an exemplary embodiment, the period of operation may be input by a user of the application and designed to meet the user's budget and consumer service constraints. For example, the user may input a time period during which the application must run, such as 24/7 (twenty-four hours per day, seven days per week), 24/5 (twenty-four hours per day, five days per week), monday through friday at 8:00 am to 5:00 pm, or any other suitable time period during which the application must run. The user may also adjust a particular time period of operation based on budget constraints. For example, a user may specify that an application be run during off-peak hours to reduce the cost of running the application.
In step 420-. According to an exemplary embodiment, step 420-435 may comprise identifying the hardware type and/or configuration, including the particular manufacturer and/or component, and the capabilities required for each resource. Representative resource capabilities needed may include CPU cycles of computing resources, bandwidth of network resources, and disk space and/or memory of storage resources. Step 420-. For example, such characteristics may include execution time, response time, accuracy of results (e.g., error rate), availability, reliability, security, or other suitable characteristics that indicate the performance of the resource.
In an exemplary embodiment, the requirements broker 114 may optionally determine the required resources based on a minimum or optimal resource requirement necessary to run the application. In this case, the requirements broker 114 may obtain that information directly from the specification of the application. Or a user of the application may enter a desired, configurable setting to specify the amount of one or more of the resources. In this regard, the user may input characteristics that will provide the desired level of service, which can be read by the demand broker 114 in step 420-.
According to an exemplary embodiment, the service level requirement may be expressed as a threshold or range. For example, the required response time may be established at less than 1 second, which allows a future determination of whether the performance of the resource meets the service level requirement threshold. Another example is that the required response time may be established in a range of e.g. 0.5 seconds to 1.5 seconds. In this case, if the response time of the resource falls within the specified range, the resource meets that service level requirement. Performance thresholds and ranges may be specified for each service level requirement.
In step 440, the method 220 determines whether a service level requirement is to be identified for another application. If so, the method 220 branches back to step 405 to select another application for which it will identify service level requirements. In this regard, the method 220 may identify service level requirements for a plurality of applications. For example, a service level requirement may be identified for an application using one of the exemplary architectures A, B, C shown in FIG. 1. If the method 220 determines in step 440 that it does not recognize a service level requirement for another application, the method 220 forks to step 225 (FIG. 2).
The particular service level requirements described with reference to steps 410 and 435 may depend on the particular requirements of the particular application and the particular requirements of the user of the application or the owner of the distributed computing resources. Accordingly, the service level requirement may comprise all or a subset of the items described in steps 410-435, and additional service level requirements are within the scope of the present invention.
FIG. 5 is a flowchart describing a method 225 for creating a bid for obtaining resource units needed to meet service level requirements of an application, as referenced in step 225 of FIG. 2, in accordance with an exemplary embodiment of the present invention. Method 225 will be described with reference to fig. 1 and 5.
In step 505, the requirements broker 114 selects a first application for which one or more requirements bid 118 are to be created. And in step 510, the requirements broker 114 selects a first resource required to run the selected application. For example, the requirements broker 114 can select one of the computing, network, or storage resources needed to run the application.
In step 515, the demand broker 114 reads the service level requirements for the selected resource based on the service level requirements determined in step 415 and 435 of FIG. 4. Additionally, in step 520, the requirements broker 114 reads budget information indicating budget limits for running the application based on the budget determined in step 410 of FIG. 4.
Then in step 525, the requirements broker 114 establishes a price per unit of the selected resource based on the service level requirements and the available budget, which it will pay to obtain the selected resource to run the application. In an exemplary embodiment, the demand broker 114 may calculate a price per unit of resource based on cost data, supply, demand, or other economic data entered by the user into the demand broker 114 or obtained by the demand broker 114 based on historical data of completed resource allocation transactions. The demand broker 114 can also establish a price per unit based on a command to obtain the best available resource regardless of cost, to obtain the cheapest resource, to obtain the resource at a specified total or per unit price of the resource, or to obtain the resource through another suitable budget format, depending on the budget information and the priority of the application.
In step 530, the requirements broker 114 generates one or more requirements bid 118 for obtaining the selected resources for use by the selected application. Based on the information obtained in steps 515 through 525, the demand purchase offer 118 may specify the resource, the service level requirements that the resource must satisfy, and the unit price the user will pay to obtain the resource. As previously discussed, the unit price may comprise an actual monetary value or a perceived value.
In step 535, the requirements broker 114 determines whether a requirements bid 118 for another resource needed to run the application is to be generated. For example, if the demand broker 114 has only generated a demand bid 118 for computational resources, the demand broker 114 may decide to generate a demand bid 118 for network or storage resources. In this case, the method 225 branches back to step 510 to generate a demand purchase offer 118 for another resource. If the method 225 determines in step 535 that a demand purchase offer 118 for another resource is not to be generated, the method 225 branches to step 540.
Then, in step 540, the requirements broker 114 determines whether a requirements bid 118 is to be generated for another application. If so, the method 225 branches back to step 505 to generate the demand purchase offer 118 for another application. If the method 225 determines in step 540 that the demand purchase offer 118 is not to be generated for another application, the method 225 branches to step 230 (FIG. 2).
FIG. 6 is a flowchart describing a method 235 for matching resource offers 110 to demand offers 118 for use by applications for obtaining virtual resources 109, as referenced by step 235 in FIG. 2, in accordance with an exemplary embodiment of the present invention. The method 235 will be described with reference to fig. 1 and 6.
In step 602, the marketplace exchange 112 selects an application and will identify available resources for the selected application to run. In step 605, the marketplace exchange 112 selects the resources needed to run the selected application. More specifically, if multiple resources are needed to run the selected application, the method 235 selects one of those resources in step 605, allowing the method 235 to match the resource offer 110 to the demand purchase offer 118 for the selected resource. The matching step may then be repeated for other resources needed to run the application, as described below.
In step 610, the marketplace exchange 112 selects a demand bid for purchasing units of the selected resource for the selected application. The marketplace exchange 112 then determines, at step 615, whether there is a resource offer offering the virtual resource 109 at the service level requirement and price parameter specified in the selected demand offer. Accordingly, in step 620, the marketplace exchange 112 determines whether there is such a matching offer. If so, the method 235 branches to step 630. If not, the method 235 branches to step 625, where the marketplace exchange 112 allows the resource broker 102 and the demand broker 114 to revise the resource offer 110 and/or the selected demand purchase offer until a matching offer is identified, at step 625. The method 235 then proceeds to step 630.
The method used by the marketplace exchange 112 to identify resource offers 110 that match the selected demand offers includes any suitable form for allocating goods in the economic marketplace. For example, the marketplace exchange 112 may employ methods such as a commodity market model, a bid price model, a bid/contract network model, an auction model (including a reduced price auction model), a monopoly/oligopolism model, and/or a proportional resource sharing model based on bid. In these exemplary embodiments, the marketplace exchange 112 operates an economic marketplace to efficiently allocate resources at a market settlement price and within budget parameters specified in the selected demand bid.
When considering the budget parameters specified in the selected demand bid, the marketplace exchange 112 may compare the resource bids to identify the best resource bid to satisfy the demand bid. For example, if multiple resource offers provide the appropriate types of resources, the marketplace exchange 112 may identify the best resource offer under budget constraints, such as a command to obtain the best available resource without regard to cost, obtain the cheapest resource, obtain the resource at a specified total or per unit price of the resource, or obtain a demand purchase offer for the resource through another appropriate budget format.
In step 630, the marketplace exchange 112 links the matching resource offer to the selected demand purchase offer. The marketplace exchange 112 then determines whether additional units of the selected resource are needed to run the selected application in step 635. For example, if the matching resource offer offers only a portion of the resources needed to meet the service level requirements, the marketplace exchange 112 may determine that additional units of the selected resource are also needed. If so, the method 235 branches back to step 610 to select another demand bid for purchasing units of the selected resource at the specified price. The newly selected demand bid may be a revised version of the previously selected demand bid, with the amount of resources selected reduced to an amount equal to the amount of resources provided by the matching resource bid.
Referring back to step 635, if no additional units of the selected resource are needed, the method 235 branches to step 640. In step 640, the marketplace exchange 112 determines whether another resource is needed to run the selected application. For example, if the marketplace exchange 112 has only identified matching resource offers 110 for providing computing resources, the marketplace exchange 112 may decide to identify matching resource offers 110 for providing network or storage resources needed to run the application. In this case, the method 235 branches back to step 605 to identify a matching resource offer 110 for providing another resource. If the marketplace exchange 112 determines in step 640 that a matching resource offering 110 is not to be identified for providing another resource, the method 235 branches to step 645.
The marketplace exchange 112 then determines whether the demand purchase offer 118 and the resource sale offer 110 are to be matched for another application in step 645. If so, the method 235 branches back to step 602. If not, the method 235 branches to step 240 (FIG. 2).
FIG. 7 is a flowchart describing a method 240 for completing a transaction to purchase resources required to run an application based on a matched resource offer 110 and demand purchase offer 118, as referenced in step 240 of FIG. 2, according to an exemplary embodiment of the present invention. The method 240 will be described with reference to fig. 1 and 7.
In step 702, the marketplace exchange 112 selects an application. In step 705, the marketplace exchange 112 selects a demand purchase offer and its matching resource purchase offer for the application. In step 710, the demand broker 114 commits to pay the resource broker 102 to use the virtual resources 109 specified in the resource offer. In step 715, the marketplace exchange 112 takes care of the commitment to pay for use of the virtual resource 109 by debiting the demand broker apparatus 114 account and crediting the resource broker apparatus 102 account. The marketplace exchange 112 then issues a service level agreement between the demand broker apparatus 114 and the resource broker apparatus 102 in step 720, in which the resource broker apparatus 102 agrees to provide the virtual resources 109 specified in the resource offer (including a commitment to meet the service level requirement specified in the matching demand purchase offer) in exchange for payment of the fee specified in the resource offer, if any.
In step 725, the marketplace exchange 112 determines whether the application has additional matching demand offers 118 and resource offers 110. If so, the method 240 branches back to step 705 to complete the transaction for another resource needed to run the application. If not, the method 240 branches to step 730.
In step 730, the marketplace exchange 112 determines whether it will complete a transaction for another application to obtain the resource. If so, the method 240 branches back to step 702 to select another application. If not, method 240 branches to step 245 (FIG. 2).
FIG. 8 is a flowchart depicting a method 245 for migrating the operation of an application to a purchased resource, as referenced in step 245 of FIG. 2, in accordance with an exemplary embodiment of the present invention. The method 245 will be described with reference to fig. 1 and 8.
In step 802, an application is selected. In step 805, resource broker device 102 selects virtual resources 109 that have been purchased for the selected application. The resource broker 102 then allocates the purchased virtual resource 109 to the application in step 810, and the requirements broker 114 instructs the application to run the application using the allocated virtual resource 109 in step 815.
In step 820, the method 245 determines whether another resource has been purchased for the application. If so, the method 245 branches back to step 805 to allocate another virtual resource 109 to the application. If not, method 245 branches to step 825.
In step 825, the method 245 determines whether to migrate the operation of another application to the purchased resource. If so, method 245 branches back to step 802 to select another application. If not, the method 245 branches to step 250 (FIG. 2).
Fig. 9 is a flowchart describing a method 250 for monitoring performance of allocated resources and service level requirements of an application according to an exemplary embodiment of the present invention, as mentioned in step 250 of fig. 2. The method 250 will be described with reference to fig. 1 and 9.
In step 905, the requirements broker 114 selects the resources being used by the application. For example, the requirements broker 114 can select one of the computing, network, or storage resources being used by the application.
In step 910, the requirements broker 114 determines the service level requirements for the application specified in the requirements bid for the selected resource. In an exemplary embodiment, the requirements broker 114 can make this determination based on the service level requirements listed in the service level agreement. Then, in step 915, the requirements broker 114 determines whether a new service level requirement is established for this resource (in addition to the service level requirement specified in the requirements bid for the selected resource). If so, the method 250 branches to step 920 to determine a new service level requirement for the application, e.g., by reading a new requirement entered by a user of the application. The method 250 then proceeds to step 925. Referring back to step 915, if the requirements broker 114 determines that a new service level requirement has not been established for the application, the method 250 may branch directly to step 925.
In step 925, the demand broker 114 monitors the performance of the selected resources used by the application. In step 930, the requirements broker 114 compares the performance of the selected resource to the service level requirements of the application. Then, in step 935, the requirements broker 114 determines whether the performance of the resource exceeds the service level requirements of the application. If so, the method branches to step 940.
In step 940, the demand broker 114 determines whether it is paying for excess resources. For example, if an application is running at or near its maximum resource utilization and the resource has excess capacity, the demand broker 114 can determine that it is paying for the excess resource. Or if the resource has excess capacity but the application is currently running at less than its maximum resource utilization, the demand broker 114 can determine that it is not paying for the excess resource. If the requirements broker 114 determines that it is paying for excess resources, the method 250 branches to step 255 (FIG. 2), where the requirements broker 114 determines that it is paying for underutilized resources in step 255.
Referring back to step 940, if the requirements broker 114 determines that it has not paid for the excess resources, the method 250 branches to step 955 to continue monitoring the selected resources.
Referring back to step 935, if the demand broker 114 determines that the performance of the resource does not exceed the service level requirements of the application, the method 250 forks to step 945. In step 945, the requirements broker 114 determines whether the performance of the selected resource does not meet the service level requirements of the application. If not, the method forks to step 950 and in step 950, the requirements broker 114 determines whether the resource fails to meet the service level requirements. For example, if the application is running at or below its maximum resource utilization and the resource does not provide sufficient performance to meet the service level requirement, the demand broker 114 can determine that the selected resource cannot meet the service level requirement. Alternatively, if the application is temporarily running at a utilization rate that exceeds that specified in the service level requirement, the demand broker 114 can determine that the resource is capable of meeting the service level requirement. If the resource broker 114 determines that the resource cannot meet the service level requirements, the method 250 forks to step 255 (FIG. 2), where the requirements broker 114 determines that it is paying for the underperforming resource in step 255.
Referring back to step 950, if the requirements broker 114 determines that it has not paid for excess resources, the method 250 branches to step 955 to continue monitoring the selected resources.
Referring back to step 945, if the demand broker 114 determines that the performance of the resource is not below the service level requirement, the method 250 forks to step 955 to continue monitoring the selected resource.
From step 955, the method 250 proceeds to step 960, where in step 960, the demand broker 114 determines whether to monitor the performance of another resource being used by the application. If so, the method 250 branches back to step 905 to select another resource to monitor. If not, the method forks to step 255 (FIG. 2), where the demand broker 114 may determine that the resources used by the application are not under-utilized or underperforming in step 255.
The method 250 may be performed for each application that has been allocated resources through a service level agreement in a distributed computing environment. In this manner, the performance of the allocated resources is continuously or periodically monitored to ensure that the resources meet service level requirements. If the resource is not providing the required level of service, the requirements broker 114 generates new requirements bids 118 and submits those bids to the marketplace exchange 112 to obtain the resource that will meet the service level requirements. In addition, in this manner, the performance of the allocated resources is continuously or periodically monitored to ensure that the performance of the resources does not exceed the service level requirement by an amount that would indicate that the demand broker 114 is paying for unused resources (in other words, excess capacity of the resources). If the resources are not being fully utilized by the application, then the requirements broker 114 generates new requirements bids 118 and submits those bids to the marketplace exchange 112 to obtain resources that are more appropriate and/or economical for the service level requirements.
The method 250 illustrated in fig. 9 monitors the performance of allocated resources to determine whether those resources are under-utilized or performing poorly. If so, the method 250 returns to the method 200 shown in FIG. 2 to perform step 225 and 245. In step 225-245 of the method 200, a new resource is identified and allocated to the application and the operation of the application is migrated to the new resource.
FIG. 10 is a block diagram depicting the reallocation of distributed computing resources for an application in system 100, according to an exemplary embodiment of the invention. As shown in fig. 10, the demand broker 114 has identified a breach in the service level agreement for the currently allocated network and storage virtual resources 109. In other words, the performance of currently allocated network and storage virtual resources 109 is not meeting the service level requirements specified in the service level agreements for those virtual resources 109. More specifically, virtual network architecture N2Is not sufficient to provide the necessary communication rate between the allocated resources and requires that the broker 114 obtain faster network resources. In addition, the virtual storage structure S2 is insufficient to provide the necessary storage and retrieval rates, and the demand broker 114 needs to obtain more resilient storage resources.
Accordingly, theThe requirements broker 114 generates new requirements bids 118 for obtaining new network and storage resources that can meet the specified service level requirements and submits the bids to the marketplace exchange 112. The marketplace exchange 112 identifies matching resource offers 110 and completes service level agreements to allocate new network and storage virtual resources 109 to the application. The operation of the application is then migrated to the new network and storage virtual resource 109. As shown in FIG. 10, the operation of the application is transferred from the virtual network architecture N2Migrating to virtual network architecture N1And from the virtual storage structure S2Migrating to virtual storage Structure S1。
As also shown in FIG. 10, the demand broker 114 has identified a violation of the budget of the currently allocated computational virtual resources 109. In other words, the performance of the currently allocated virtual compute structure C1 is exceeding the service level requirements specified in the service level agreement for those resources. More specifically, the demand broker 114 is paying more for unused computing resources, and therefore needs to obtain new resources that operate within service level requirements, which will likely reduce the cost of running applications.
Accordingly, the requirements broker 114 generates one or more new requirements bids 118 for obtaining new computing resources operating within the specified service level requirements and submits the bids to the marketplace exchange 112. The marketplace exchange 112 identifies matching resource offers 110 and completes a service level agreement to allocate new computing virtual resources 109 to the application. The operation of the application is then migrated to the new compute virtual resource 109. As shown in FIG. 10, the operation of the application program is transferred from the virtual operation structure C1Migrating to virtual operation Structure C2。
FIG. 11 is a flowchart describing a method 270 for managing maintenance, procurement and/or decommissioning of resources based on allocation of resources over a period of time according to an exemplary embodiment of the invention, as referenced in step 270 of FIG. 2. The method 270 will be described with reference to fig. 1 and 11.
In step 1105, a resource manager, such as resource broker device 102, monitors revenue generated by each physical resource 103. In an exemplary embodiment, the resource manager may monitor such revenue generated by aggregating payments corresponding to service level agreements for each particular physical resource 103. Each payment represents an amount that the demand broker 114 pays the resource broker 102 for use of the particular physical resource 103 included in the service level agreement. In this regard, the resource manager may continuously obtain a running total of revenue generated by each physical resource 103 during the time period.
Then in step 1110, the method determines whether a time period has elapsed. In an exemplary embodiment, the time period may be a quarter, a half year, a year, or any other suitable time period for monitoring revenue generated by the physical resources 103. In another exemplary embodiment, method 270 may determine whether a time period has elapsed based on a predetermined time period monitored by resource broker device 102, the expiration of which may trigger an alert that the time period has elapsed. Or the method 270 may determine whether a time period has elapsed based on the user manually accessing revenue information generated from step 1105. Regardless, if the time period has not elapsed, the method 270 branches back to step 1105 to continue monitoring revenue generated by each physical resource 103. If the time period has elapsed, the method 270 branches to step 1115.
In step 1115, the method identifies the costs and expenses associated with, among other things, purchasing and maintaining each physical resource. In an exemplary embodiment, the user may enter that information based on actual and/or projected purchase and maintenance costs. The profit or loss of each physical resource 103 is then determined by subtracting the costs and overheads associated with the physical resource 103 from the revenue generated by the physical resource 103 in step 1120.
In step 1125, a particular physical resource 103 is selected, and in step 1130, it is determined whether the selected resource produces a profit or a loss during the time period. If the revenue of the physical resource is greater than its cost and overhead, the physical resource generates a profit during the time period. Or if the revenue of the physical resource is less than its cost and overhead, the physical resource incurs a deficit during the time period.
If the selected physical resource produces a profit, the method 270 branches to step 1135. In step 1135, the profitability of the selected physical resource is compared to the profitability of other similar resources. A determination is then made in step 1140 whether to maintain the current position of the selected physical resource or to invest in the selected physical resource. For example, if the resource is only producing a small amount of profit compared to other resources, the user may decide to maintain the current position for the resource. In other words, the user does not purchase more resources. Alternatively, if the resource is producing a large amount of profit compared to other resources, or if the demand for the resource is expected to grow, the user may decide to invest in the resource by purchasing more resources or upgrading existing resources. After determining whether the position of the selected physical resource is to be maintained or to be invested, the method 270 proceeds to step 1150.
Referring back to step 1130, if the selected physical resource produces a deficit during the time period, the method 270 branches to step 1145. In step 1145, a determination is made whether to maintain a current position of the selected physical resource or to retire the selected physical resource. For example, if the resource produces only a small deficit, or if the resource meets a high priority need that justifies the cost, the user may decide to maintain the current position for the resource. In other words, the user does not fund the resource. Or if the resource produces a huge or undesirable deficit, the user may decide to retire the resource by selling the resource or not continuing to support or maintain the resource. In other embodiments, the user may decide to reduce the use of the resource to reduce the deficit associated with the resource, or the user may decide to use the profit generated by another resource to subsidize continued use of the resource. After determining whether the position of the selected physical resource is to be maintained or retired, method 270 proceeds to step 1150.
In step 1150, it is determined whether the position of another resource is to be evaluated. If so, the method 270 branches back to step 1125 to select another resource. If not, method 270 and method 200 (FIG. 2) end.
Accordingly, the method 270 allows a user to evaluate physical resources to determine which resources are most economical, including price and performance aspects. For example, a computing resource may comprise different platforms, each with different price and performance characteristics. Comparing the profit-loss tables for each resource will show which platforms are most used by the application resulting in more profits. Based on this information, the user can determine which platforms to maintain or to add company position to and which to retire. Since the resources have been allocated as described with reference to method 200 (FIG. 2), method 270 provides an indication of which resources are more desirable to have for use by the application based on price and performance characteristics.
Although the present invention has been described in detail with reference to allocating and managing distributed computer resources, the present invention is also applicable to allocating and managing other distributed resources. For example, the present invention can also be applied to distributed workforce. In this case, resource offers 110 are generated to identify characteristics and prices associated with available individuals or group members of the workforce and those offers are submitted to the marketplace exchange 112. Demand buys 118 for obtaining services from the workforce for a particular work project are generated and submitted to the marketplace exchange 112. The marketplace exchange 112 then identifies matching purchase offers and offer offers, and allocates labor resources to the project. The performance of the allocated resources may be monitored and resources may be reallocated when necessary to correct underutilized or underperforming labor members. Over time, the profit-loss of individual or group members of the labor force may be determined, and this profit-loss information may be used to determine investment and funding decisions regarding specific aspects of the labor force.
The present invention can be used with computer hardware and software that performs the methods and processing functions described above. Those of skill in the art will appreciate that the systems, methods, and steps described herein may be embodied in a programmable computer, computer-executable software, or digital circuitry. The software may be stored on a computer readable medium. For example, the computer readable medium may include floppy disks, RAM, ROM, hard disks, removable media, flash memory, memory sticks, optical media, magneto-optical media, CD-ROMs, and the like. The digital circuitry may include integrated circuits, gate arrays, building block logic, Field Programmable Gate Arrays (FPGAs), and the like.
Although specific embodiments of the invention have been described herein in detail, this description is for illustrative purposes only. The exemplary methods described herein are merely illustrative, and in alternative embodiments of the invention, certain steps may be performed in a different order, in parallel with one another, or omitted altogether, and/or certain additional steps may be performed without departing from the scope and spirit of the invention. In addition, various modifications of the disclosed aspects of the exemplary embodiments, in addition to those described herein, may be made by those skilled in the art and various equivalent steps may be made corresponding to the disclosed aspects of the exemplary embodiments without departing from the spirit and scope of the invention as defined by the following claims, the scope of which is to be accorded the broadest interpretation so as to encompass such modifications and equivalent structures.