Taxes & Accounting

Decentralized market-based resource allocation in a heterogeneous computing system

Description
Abstract We present a decentralized market-based approach to resource allocation in a heterogeneous overlay network. The presented resource allocation strategy assigns overlay network resources to traffic dynamically based on current utilization,
Published
of 12
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
    978-1-4244-1694-3/08/$25.00 ©2008 IEEE Decentralized Market-Based Resource Allocationin a Heterogeneous Computing System James Smith 1 , 2 , Edwin K. P. Chong 2 , 4 , Anthony A. Maciejewski 2 , and Howard Jay Siegel 2 , 31 DigitalGlobe Colorado State UniversityLongmont, CO 80503 USA 2 Dept. of Electrical and Computer EngineeringEmail: jtsmith@digitalglobe.com 3 Dept. of Computer Science 4 Mathematics DepartmentFort Collins, CO 80523–1373, USAEmail: { echong, aam, hj } @engr.colostate.edu Abstract We present a decentralized market-based ap-proach to resource allocation in a heterogeneous overlay network. The presented resource allocation strategy assigns overlay network resources to traf- fic dynamically based on current utilization, thus,enabling the system to accommodate fluctuating de-mand for its resources. We present a mathemat-ical model of our resource allocation environment that treats the allocation of system resources as a constrained optimization problem. Our presented resource allocation strategy is based on solving the dual of this centralized optimization problem. The solution to the dual of our centralized optimization problem suggests a simple decentralized algorithm  for resource allocation that is extremely efficient.Our results demonstrate the near optimality of the proposed approach through extensive simulation of a real-world environment. That is, the conducted simulation study utilizes components taken from a real-world middleware application environment and clearly demonstrates the practicality of the approach in a realistic setting. 1 Introduction Recently, information technology (IT) systemshave begun to rely heavily on the concept of  This research was supported by the NSF under GrantsCNS-0615170 and ECCS-0700559, by the Colorado StateUniversity Center for Robustness in Computer Systems(funded by the Colorado Commission on Higher EducationTechnology Advancement Group through the Colorado In-stitute of Technology), and by the Colorado State UniversityGeorge T. Abell Endowment. Services Oriented Architecture (SOA). SOA is ameans of leveraging existing applications as serviceswithin a distributed computing environment to de-velop new applications. One mechanism commonlyused to integrate existing applications is known asthe enterprise services bus (ESB) [16]. Accord-ing to the Business Integration Journal [8], “The[ESB] supports the unifying integration infrastruc-ture required for SOA and heterogeneous environ-ments.” By relying on an ESB to implement a dis-tributed application, service requesters within thedistributed application—using the ESB to commu-nicate with service providers—can remain ignorantof the details of the service providers, e.g., the phys-ical location of the service provider. Instead, ser-vice requesters depend on the abstract definition of the service that they are using and trust the ESBto forward their requests to an appropriate serviceprovider. Because the service requester is not de-pendent on an explicit instance of a service provider,multiple service providers could be deployed withinthe ESB to provide additional capacity for a partic-ular service.An important aspect of an ESB implementationis that it can be decentralized both to increase its re-liability and to ensure its scalability [8]. A commonapproach to increasing the reliability of a service isto duplicate that service many times across manyhardware deployments—a technique often referredto as replication [7].Successfully replicating ESB components re-quires maintaining network transparency [7], i.e.,the user of the ESB infrastructure should beshielded from the existence of any redundant com-ponents used to provide the replicated ESB or itsattached services. To the user, the system shouldappear as if it were a single highly available servicethat always has sufficient capacity to process ser-  vice requests. Achieving this kind of transparencyin service delivery requires a mechanism for allow-ing the ESB infrastructure to adapt to changes insystem load. That is, to transparently utilize repli-cas within an ESB infrastructure, the replication in-frastructure must provide a mechanism for routingrequests to their physical destination. In this work,we focus on the allocation of ESB components to theshipment of service requests; however, our presentedapproach can easily be extended to enable multipleservice providers for a given service definition wherethe ESB components apply an analogous approachto allocating service requests to service providers.This work investigates the application of a decen-tralized market-based approach to resource alloca-tion within a heterogeneous deployment of a repli-cated ESB. In this system, service requesters sendtasks to service providers using an overlay networkprovided by the ESB infrastructure. The decision of how to allocate individual ESB component capacityto service requests is made in a decentralized man-ner based on a quantification of current resourcedemand relative to current system capacity. Indi-vidual service requesters select a transmission ratethrough ESB components that maximizes their in-dividual benefit, while the ESB components adjust“prices” for network links and their own comput-ing capacity to reflect current demand. Thus, pricesetting enables service requester resource allocationdecision making by communicating a simple quan-tification of current system congestion to the deci-sion makers.Figure 1 presents a graphical model of a simpleoverlay network provided by a replicated ESB. Ser-vice requesters are depicted in the figure as trian-gles, service providers are shown as squares, andESB components are depicted as circles. Each ser-vice requester is connected to a collection of ESBcomponents that “service” requests by dispatchingthem to a service provider capable of completingthe request. The number of requests produced byeach service requester may vary with time accord-ing to some unknown process. In this model, thecapacity of the ESB components to service incom-ing requests may differ from one to another, i.e.,the collection of ESB components are assumed het-erogeneous in their performance [9,11,13]. Finally,each ESB component is connected to a collection of service providers by a finite-capacity link.In a real-world computing environment, networktraffic is often triggered by world events outside thecontrol of the computing system. For example, a fi-nancial market sell off could reasonably be expectedto result in an increase in network traffic communi-cating market sell orders to the financial market.In a similar manner, changes in the volume of ser-vice requests that a replicated ESB must process isa source of system uncertainty. That is, a resourcemanager responsible for allocating ESB componentsto service requests cannot accurately predict the up-coming volume of requests that will need to be ser-viced.A system can be considered robust to perturba-tions in system parameters, if the change in systemperformance features due to this uncertainty is lim-ited [1]. In this system, we utilize an overall perfor-mance measure that accounts for requester priori-ties, the number of requests being transferred, andthe quality of the network routes being used. Re-quests are produced by service requesters at somerate and transmitted to the ESB where they arebuffered before being forwarded on to their final des-tination. Because the system is decentralized andthe production rate of service requests is changingwith time, it is possible for the system to experi-ence contention for shared system resources. Whencontention for shared resources occurs, potentiallydue to changes in the production rate of requests,it is possible for low-priority requests to inhibit thetransfer of high-priority requests causing the perfor-mance measure to degrade.Intuitively, the robustness [1,4,17,18,20] of thedecentralized allocation approach can be establishedby answering the following three questions. Whatbehavior of the system makes it robust? What un-certainties is the system robust against? Quanti-tatively, exactly how robust is the system? Uncer-tainty in how shared resources will collectively beused by service requesters can directly impact thesystem performance measure, given fluctuations inservice request production rates. In this system,we might consider a resource allocation strategy ro-bust as long as it maintains a performance measurethat is within X  % of the optimal value, where X  isa user defined constraint on the acceptable perfor-mance of the system. We can quantify robustnessin this environment as the proximity of the systemperformance measure to its optimal value.Our mechanism for resource allocation can bethought of as a market-based approach where mar-ket demand for shared resources helps the systemto set prices for those resources. It is common inmarket-based approaches to instead rely on an auc-tion to create a market where prices are set by thehighest bidder [10,14]. In contrast, our approachutilizes price setting based on duality theory. Ourapproach is analogous to that used to implementcongestion control on the internet [21] and in adhoc sensor networks [5]. In our system model, pricevariables are introduced to model market demandfor shared resources—prices are a simple quantifi-cation of current demand for shared resources. Forexample, as the number of requests through an ESBcomponent increases, the ESB component raisesits “price.” Conversely, if the number of requeststhrough an ESB component decreases, its quotedprice also decreases. In addition to measuring thedemand for the component itself, the ESB compo-  Figure 1. An example system where four service requesters are utilizing two ESB components to com-municate with three service providers. The service requesters are shown as triangles, the ESB compo-nents as circles, and the service providers as squares. The input links to the ESB components from theservice requesters each has a finite-capacity, denoted c (in) re . The output links from the ESB componentsto the service providers each has a finite-capacity denoted c (out) ep . Finally, each ESB component has afinite-capacity for servicing requests, denoted c e .nent is also responsible for stating the demand forthe links from that ESB component to all of theservice providers that the component can commu-nicate. The procedure used to calculate an optimalpricing for resources will be presented. Individualservice requesters directly utilize the current pric-ing information provided by the ESB components tomake local resource allocation decisions about howbest to assign their volume of requests within theoverlay network given current network utilization.Although an analogous methodology has beenstudied previously in the context of internet con-gestion control, it has never been applied withinthe context of an Enterprise Services Bus. A majorcontribution in this work is the design of a decen-tralized market-based approach to resource alloca-tion. This approach is a novel use of market-basedcontrol over shared resources within an ESB envi-ronment. We also demonstrate through simulationthat our decentralized market-based control mech-anism is capable of providing near optimal resourcemanagement in an ESB setting.In the next section, we present a more detailedview of the system model that is used in section 3to present our mathematical model of the system.Section 4 presents a decentralized implementationof our solution approach. Sections 5 and 6 presentour simulation setup and results for the evaluationof this approach in a real-world system setting, withconclusions presented in Section 8. 2 System Model An example model of a replicated ESB overlaynetwork is shown in Figure 1. In this computingsystem, there are three types of entities: service re-questers, ESB components, and service providers.Service requesters send requests to ESB componentsthat post the requests to the appropriate serviceprovider. It is helpful to consider a service requesteras an agent that is making service requests to theESB on behalf of an application that is external tothe replicated ESB system. That is, an externalapplication passes requests to the service requesterwhich makes routing decisions on behalf of the ap-plication. In this way, the service requester can betreated as a component of the ESB instead of as anoutside entity. Let R denote the set of all servicerequesters, P  the set of all service providers, and E  the set of all ESB components. In this system,rates of requests from individual service requestersare not required to be observable; instead, the sys-  tem only requires that each ESB component be ableto measure the number of requests that have arrivedto it at each time step—a value readily availableby inspection of the ESB component’s input buffer.Each service requester r ( r ∈ R ) produces requestsfor a service provider p (  p ∈ P  ) at a rate of  f  rp ( t )requests per unit of time. Service requesters aremodeled as having an output buffer, and all requestsproduced by the requester are written to the outputbuffer prior to transmission. Requests are transmit-ted from the service requester’s output buffer usingthe appropriate overlay network link to the inputbuffer of the selected ESB component. Each ESBcomponent processes requests from its input buffer,forwarding requests to its chosen service provider.In the example of Figure 1, service requesters areconnected to all of the ESB components, i.e., thereis a finite-capacity link connecting each service re-quester to each ESB component, where the finitecapacity is modeled as a constraint on the transmis-sion rate through that link. Thus, a link betweena service requester r ∈ R and an ESB component e ∈ E  is subject to a capacity constraint c (in) re suchthat the rate of requests sent from service requester r to ESB component e cannot exceed c (in) re .Requests received by an ESB component areassumed to be buffered in a finite-capacity inputbuffer for that component. Each ESB componentalso maintains a finite-capacity output buffer forstoring requests that have been processed and areready to be transmitted to an appropriate serviceprovider. Each ESB component e ∈ E  is subject toits own capacity constraint on its computing capa-bilities such that the rate at which e can processrequests is limited to c e . That is, an ESB compo-nent e with processing capacity c e can move at most c e requests from its input buffer to its output bufferin a single time unit.The outgoing links from each ESB component toits attached service providers are subject to capac-ity constraints. The link connecting an ESB com-ponent e to a service provider p ∈ P  has a finitecapacity c (out) ep to move data from the output bufferof ESB component e to the input buffer of serviceprovider p . Lastly, there are no modeled constraintson the capacity of the service providers. That is,for this model we chose to focus on applying themarket-based resource allocation strategy only tothe ESB components. However, it should becomeclear that the presented approach could easily beextended to include allocation decisions regardingmultiple service providers for the same class of ser-vice.In our model, there are two types of shared re-sources, the ESB components and the links connect-ing the ESB components and the service providers.There is a difference between the advertised capac-ity ( c e and c (out) ep ) of shared resources and the phys-ical capacity of a resource. The physical capacityof any given shared resource can be viewed as the“true” capacity afforded by the physical limitationsof the device, i.e., the physical capacity is an upperbound on the performance of the device. It shouldbe clear that if a system were sized such that itwere required to operate at its physical limit forthe duration of its execution, then if that systemwere ever asked to process more than that limit itwould be incapable. That is, it is incumbent uponeach ESB component e to construct its prices notfrom its true capacity but instead from its adver-tised capacity. Specifically, the advertised capacityis given as some reasonable fraction of the true sys-tem capacity, e.g., we can define the advertised ca-pacity as ρ times the true capacity where ρ ∈ (0 , 1)is often called the “load factor.” By communicatingits availability in terms of the advertised capacity,the ESB component is insulated from instantaneousfluctuations that occur during the normal course of system operation that might otherwise overwhelmthe component. The capacity for each shared re-source used in our model ( c e and c (out) ep ) is assumedto be the advertised capacity.The Information Technology (IT) industry is at-tempting to recover the cost of maintaining WideArea Network (WAN) links by billing for networktraffic that is transported across these links. Thatis, companies are beginning to monitor WAN traf-fic volume in an attempt to bill customers for theamount of data transferred across these expensivenetwork links. In a globally distributed system suchas a replicated ESB, network link costs need to beaccounted for during resource allocation. By intro-ducing a pricing scheme for WAN links, the networkprovider has inadvertently created a situation wheresome links are more valuable than others. To helpilluminate the impact of such a decision, considerthe following simple example. Using the model of Figure 1, assume that one ESB component is physi-cally located in Fort Collins, CO, in the U.S.A., andanother is located in Bangalore, India. If a servicerequester located in the U.S.A. intends to commu-nicate with a service provider also in the U.S.A.,then the lowest cost route may be through the ESBcomponent located in Fort Collins. By sending traf-fic through this U.S.A. based ESB component anetwork charge can be avoided. Although some-what exaggerated, this example demonstrates theheterogeneity of the available routes. The systemmodel accounts for this heterogeneity by incorpo-rating a quantification of route quality into the op-timization problem. The value of each route fromservice requester r through ESB component e to aservice provider destination p is given a single nu-meric value, denoted s rep , which quantifies the qual-ity (e.g., speed) of the route to the service requester.The goal of the model is to help ascertain the op-timal allocation of ESB components and associated  links to service providers for transmitting servicerequests. Recall, each service requester r produces f  rp ( t ) service requests per unit time for a particularservice provider p . This traffic is sent through someESB component in E  and all of the traffic must beeventually transmitted to its destination, e.g., someservice provider p . Thus, we can identify the per-centage of requests from a service requester r sentto a service provider p that are transmitted throughESB component e , denoted g rep in the model. Thegoal of a resource management heuristic in this en-vironment is to choose a combination of the g rep values such that the system-wide “utility” is maxi-mized.In our system model, we assume that a service re-quester receives some utility from successfully trans-ferring a request to a service provider. For example,the service provider may provide a printer repairservice—the data being transferred by the servicerequester might be a notification of a printer outage.By successfully delivering the service requester’s re-quest to the service provider, the provider can dis-patch a technician to repair the broken printer. Ad-ditionally, some service requesters may be more im-portant than others, e.g., the system provider maywish to provide to some special customers a higherlevel of service than what is normally offered. Thatis, each service requester’s traffic should be indi-vidually prioritized. Let θ rp denote the priority of requests sent from service requester r ( r ∈ R ) to ser-vice provider p (  p ∈ P  ). The utility, denoted U  ( x ),quantifies the worth of receiving service quality x . 3 Centralized Optimization Given the discussion of the previous section, wepose the replicated ESB resource allocation prob-lem as an optimization problem. The optimizationproblem can directly be solved in a centralized ap-proach to resource allocation by a system-wide re-source manager. The centralized approach could bea reasonable solution for the special case of a staticrate of requests from each service requester. Thatis, if the rate of requests produced by all requestersin the system remains constant, then it may be rea-sonable to calculate a solution to the centralizedproblem off-line. However, if the rate of requestsis changing with time, then the centralized solutionbecomes infeasible to maintain for all systems of rea-sonable size, i.e., the optimal solution to the prob-lem changes faster than the centralized solution canbe calculated. Similarly, if the centralized problemrequires too many decision variables, i.e., there aretoo many service requesters, service providers, orESB components, then it may be unreasonable tocalculate the solution in advance off-line. That is,the centralized approach to resource allocation doesnot scale well, in this environment. We will use thecentralized problem to motivate an alternative de-centralized approach presented in the next section.Using the definitions and system constraints fromthe previous section, the following centralized opti-mization problem can be defined, where each g rep is to be chosen such that system resources are allo-cated optimally:maximize  r,p θ rp f  rp ( t ) U   e g rep s rep  (1)subject to: ∀ r ,  p ,  e g rep = 1 (2) ∀ r , e ,  p , g rep ≥ 0 (3) ∀ r , e ,   p g rep f  rp ( t ) ≤ c (in) re (4) ∀ p , e ,  r g rep f  rp ( t ) ≤ c (out) ep (5) ∀ e ,  r,p g rep f  rp ( t ) ≤ c e (6)In the proposed centralized problem, over-all achieved service quality is calculated as theweighted average of the service quality levels re-ceived where the s rep values provide the weights.Equation (1) expresses the overall goal of the opti-mization to maximize the realized utility given a col-lection of service requesters each with their own pri-ority. The constraint of Equation (2) ensures thatall of the requests from a given service requesterare routed through the overlay network. Finally,Equations (4), (5), and (6) enforce the capacity con-straints for each of the constrained system resourcesand Equation (3) ensures that the g rep values arepositive.Because the rate of requests sent from each ser-vice requester to each service provider, i.e., f  rp ( t ),is a function of time, this centralized form of theproblem must be solved whenever any of the requestproduction rates change. However, for any problemof reasonable size the computation time required tosolve this problem makes it difficult to complete thesolution prior to the request production rates chang-ing again. In the next section, we identify an equiv-alent solution that is much faster to calculate. 4 Decentralized Algorithm 4.1 Decentralized Approach To transform the centralized optimization prob-lem into a decentralized algorithm, we apply the La-grangian multiplier method [2,3,6] to the centralizedoptimization problem to define an equivalent opti-mization problem that can be separated into |R| in-
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks