How To Solve A Problem In A Powerline (Powerline) With A Powerbook (Powerbook)

Transcription

1 MIT 8.996: Topc n TCS: Internet Research Problems Sprng 2002 Lecture 7 March 20, 2002 Lecturer: Bran Dean Global Load Balancng Scrbe: John Kogel, Ben Leong In today s lecture, we dscuss global load balancng problems and formulaton of such problems as nstances of network flow problems and stable marrage problems. 7. Introducton/Motvaton Server Data Center Clent Fgure 7.. Smple model of the Internet. In our model, the Internet conssts of a collecton of clents, servers and data centers. A data center s smply a group of servers all stuated at the same place. Our goal s to map the clents to the servers (or data centers) gven a set of constrants. In our model, a clent can be servced by any server (ths s n contrast to the clent-cache model present the prevous week where data s avalable only on selected servers. Our goal s to ensure that localty s enforced and clents are served by servers whch are located near them. 7.. Obectves In makng assgnments, the followng are the obectves that we would lke to meet:. Assgn clents to close servers. We can defne dstance accordng to varous measures (.e., png latency or AS hops). 2. Map clents to servers wth low utlzaton. As shown n Fgure 7.2, we wll consder 2 ways of modelng the cost of utlzaton. In one model, there s no cost untl the load on a server 7-

2 MIT Lecture 7 March 20, 2002 Sprng 2002 reaches a hard capacty Ñ Ü, and thereafter the cost s nfnte; n the second model, cost ncreases as a (typcally convex) functon of utlzaton. 3. Mnmze the bandwdth cost. The cost of bandwdth s typcally a concave functon wth respect to bandwdth utlzaton as shown n Fgure 7.3. We note that obectves and 2 are desrable from the perspectve of the clents/users whle obectve 3 s desrable from the perspectve of the servers/provders. Also, the frst two obectves usuallly act n opposton to the thrd. For the purposes of ths lecture, we wll focus on obectves and 2. Cost Cost +oo 2 C max Load Bandwdth Utlzaton Fgure 7.2. Possble cost models. Fgure 7.3. Graph of cost versus bandwdth What Happens n Practce We ll focus n ths talk on ways to model and solve abstract load balancng problems; however, actual load balancng systems typcally nvolve much more complex machnery than ust a core algorthm. In practce, our load balancng system may need to do qute a bt of work ust to mantan the problem nstance (clent nformaton, server nformaton, and localty nformaton between the two) whch s perodcally fed to the load balancng algorthm. In practce, the number of clents s too large for us to assgn them ndvdually to servers, so we usually aggregate clents n some fashon (.e., by network or by IP address). Servers need to montored to make sure that f a server crashes, we remove t from the problem nstance. Fnally, one must somehow determne and mantan a measure of localty (e.g. AS hops) between clents and servers. Our load balancng algorthm wll perodcally re-compute assgnments from clents to servers, whch then need to be publshed (e.g., usng DNS). In terms of tmescale, any tme a clent s reassgned to a new server t takes some tme for traffc from that clent to mgrate fully to the new server, especally for long connectons such as streams. So we are lookng at a system that wll probably be updatng ts assgnments every few seconds or few mnutes. 7.2 Network Flows In ths secton we descrbe how to formulate ncreasngly-sophstcated varants of the clent-server assgnment problem each as network flow problems. 7-2

3 MIT Lecture 7 March 20, 2002 Sprng Fndng a Feasble Assgnment We start wth the followng basc formulaton of the problem: we have Ò clents (whch are actually aggregates of ndvdual clents as descrbed above) and Ñ servers. Each clent has an assocated Ñ Ò µ and each server has an assocated Ô ØÝ µ. Each clent can be mapped to a subset of the servers (presumably those close to t). We can represent ths problem nstance usng a drected bpartte graph as shown n Fgure 7.4. We allow the demand for a clent to be splt between varous servers, and we want to determne f a feasble assgnment exsts whch satsfes the clent demands and respects the server capactes. demand() capacty() s hgh capacty u = capacty() t t u = demand() s n clents n clents Fgure 7.4. Basc model. Fgure 7.5. As a max-flow problem. To solve ths problem, we transform t nto an equvalent max-flow problem by addng a source node,, and a snk node, Ø. We also add an edge between and all the clents and also an edge between all the servers and Ø. The capactes for the source-clent edges are set as Ñ Ò µ whle that for the server-snk edges are set as Ô ØÝ µ. A feasble assgnment exsts (gven by the flows on the nteror edges) only f the max -Ø flow saturates all of the edges leavng the source. The well-known max-flow problem s defned as follows: Gven a drected graph Î µ, source and snk nodes and Ø, and non-negatve capactes Ù for all edges µ ¾, fnd the maxmum flow Ü ¾Ê one may send from the source to the snk. As a mathematcal program, Maxmze Ü µ¾ nodes ¾ Î Ò Ø Ü Ü ¼ (Flow Conservaton) edges µ ¾ ¼ Ü Ù (Lower and Upper Capactes) The max-flow problem has been extremely well-studed and many effcent soluton algorthms exst for ts soluton Mnmzng Maxmum Utlzaton We next consder an extenson of our problem n whch we wsh to mnmze the maxmum utlzaton among the servers. To do so, we set the capacty of the edge onng each server to the snk as Ô ØÝ µ, as shown n Fgure 7.6. We now want to mnmze such that there exsts a 7-3

4 MIT Lecture 7 March 20, 2002 Sprng 2002 max flow saturatng all of the edges leavng the source. Ths turns out to be a well studed problem called the parametrc max-flow problem. Interestng note: algorthms exst whch can solve ths type of parametrc max flow problem n essentally the same amount of tme as a standard max flow problem (ths s a result of Gallo, Grgorads, and Taran). s hgh capacty u = λcapacty() t t cost c hgh capacty u t = capacty() zero cost t u = demand() s n clents n clents Fgure 7.6. Mnmzng Max Utlzaton. Fgure 7.7. Addng Mappng Costs Addng a Cost to the Mappng Between Clents and Servers Next, we add a cost for each connecton between the clent and the server as shown n Fgure 7.7 and attempt to fnd a mnmal-cost assgnment of the demands. The problem now becomes a mn-cost flow problem: Mnmze nodes ¾ Î edges µ ¾ Ü µ¾ Ü Ü ¼ Ü Ù We assgn to each clent, Ñ Ò µ, to each server, ¼, and to Ø, Ø The mn-cost flow problem s also well-studed and effcently solvable Replacng Capacty wth a Cost Functon Ñ Ò µ. All of the prevous formulatons adhere to our frst model of utlzaton cost (Fgure 7.2) n whch utlzaton of a server s free up untl the server s load reaches some hard capacty lmt. We now consder the second model of utlzaton cost, n whch we replace the capactes, Ô ØÝ µ, wth load-dependent cost functons as shown n Fgure 7.8. Ths changes only the obectve functon of our mn-cost flow problem: Mnmze nodes ¾ Î edges µ ¾ Ü 7-4 µ¾ Ü µ Ü ¼ Ü Ù

5 MIT Lecture 7 March 20, 2002 Sprng 2002 The server-snk edges may contnue to have upper capactes Ù Ø, although ths s no longer necessary as our cost functons can express an upper capacty by umpng to nfnty when load reaches a certan level. Also, by adustng the costs assocated wth the server-snk edges versus the costs assocated wth the clent-server edges, we can select whch obectve we wsh to emphasze more: mappng wth good localty or achevng low utlzaton. Assumng the cost functons are all convex (as s typcally the case), the entre obectve functon wll be convex, so we are mnmzng a convex functon over a convex polyhedral set of feasble solutons; such a problem stll les wthn the realm of nce optmzaton problems. Moreover, f we approxmate the convex cost functons as pecewse lnear functons, we can reduce ths problem back to the smpler prevous (lnear) mn-cost flow problem. To do so, we replace each server-snk lnk wth several parallel lnks, each representng one lnear pece of the pecewse lnear cost functon as shown n Fgure 7.9. Cost A hgh capacty (convex) cost c (x ) t t 2 A (lnear) cost c x hgh capacty t Load 4 A 2 2 2, A 3 4 Server t 4,A n clents 4,2A (Capacty, Cost) Fgure 7.8. Replacng capactes wth costs. Fgure 7.9. Pecewse lnear approxmaton. There are no known good technques for solvng such problems wth non-convex cost functons; moreover, t was shown n a prevous lecture that such problems wth concave cost functons are NP-Hard and also very dffcult to approxmate. 7.3 Advanced Topcs for Network Flows We now proceed to dscuss some nterestng research topcs related to the above network flow problems Unsplttable Flows For the unsplttable flow problem, we assume for a gven nstance of our basc assgnment problem wth costs (Fgure 7.7) that a feasble fractonal assgnment exsts. The queston that we would lke to ask s whether an assgnment exsts for whch the demand for each clent cannot be splt between servers and s hence satsfed by only one server. The approach that we wll take to solve 7-5

6 MIT Lecture 7 March 20, 2002 Sprng 2002 ths problem s to take the fractonal soluton and round t to gve us an unsplttable soluton wth no worse cost, allowng the capacty constrants to be slghtly volated n the process (we shall refer to the excess capacty as congeston ). Congeston may be defned two dfferent ways: () the addtve amount we ncrease capacty, or () the multplcatve factor by whch we must scale capacty. The problem then becomes that of fnd the unsplt assgnment wth mnmum congeston,.e. that mnmzes the maxmum congeston experenced over all edges, assumng that a feasble fractonal assgnment ntally exsts. There s a lower bound for ths problem whch states that n the worst case, one experences congeston of at least Ñ Ü Ñ Ü Ñ Ò µ. Ths s addtve congeston, as opposed to multplcatve congeston. The example gven n Fgure 7.0 satsfes ths bound. In ths example, we ve reversed the locaton of the clents and servers, as s often done wth unspltable flow problems, snce we now want to route flow on dsont paths from the source (whch was formerly the snk) to each of the clents. Here, the total demand s equal to total capacty, and a feasble fractonal assgnment exsts. However, because the demand of each clent s but each server has Ñ Ñ ½ only capacty ½, each server can satsfy only one clent ntegrally wthout experencng congeston. Snce there s one clent more than the number of servers, one of the servers wll have to servce 2 clents n an unsplt soluton, and the edge lnkng the source to that server wll be congested by an addtve amount whch gets arbtrarly close to Ñ Ü as Ñ gets large. d m = m+ s complete bpartte graph d m = m+ m+ clents d = m+ m m+ Fgure 7.0. Example whch satsfes lower bound. It can be shown that n the bpartte case, there exst smple polynomal-tme approxmaton algorthms whch acheve an addtve congeston of Ñ Ü. It s an open queston as to when we can meet ths bound wthout the bpartte constrant Vector (Mult-resource) Load Balancng The vector load balancng problem s formulated by generalzng the demand and capacty functons from scalars to vectors. An example s gven n Fgure 7.. Clearly a problem that allows for fractonal assgnment can be solved as a lnear program by addng more constrants. The nterestng queston s thus whether there s a feasble ntegral assgnment for a gven problem. We know that such a problem s NP-Complete, snce t s NP-Complete for scalars (t s the unsplttable flow problem). It mght be nterestng to know f the problem can be solved more effcently than 7-6

7 MIT Lecture 7 March 20, 2002 Sprng 2002 wth lnear programmng (ponted out by Bobby). It mght also be nterestng to see f any results for the unsplttable flow problem generalze to the vector problem. demand() cost c capacty() = bandwdth CPU tme dsk memory = bandwdth CPU tme dsk memory n clents Unknown Demand Fgure 7.. An example of a vector load balancng problem Oftentmes, we know the number of requests made by a clent, but we do not know beforehand the actual load whch wll be mposed on the servers by the requests. Thus, we may be nterested to fgure out how we can do load assgnment wthout full knowledge of the demand. One smple approach s to derve a scalng factor based on the total system-wde load and requests measured n some hstorcal nterval of tme: total load total # of requests. We then estmate the demand for each clent based on the number of requests on the assumpton that the rato s a constant across all clents. Although ths approach seems to provde us wth a reasonable approxmaton, the assumpton that the rato s a constant across all clents s questonable. In partcular, f we consder the aggregaton of clents by geographc locaton, then due to dfferent tme zones, t s clear that the nature of the actvtes of dfferent clents would be dfferent for dfferent tme zone (.e. clents n areas where t s nghttme may have slow dalup access whle those n areas where t s daytme may be usng hgh speed Internet access n ther offces). The challenge s thus to come up wth a scheme that can handle unknown demand wthout assumng that s system-wde constant. The mappng through DNS s prmarly responsble for ths problem, snce the clent requests can be dentfed wth IP address of the clent s DNS server, but the load nduced on servers s dentfed wth the actual IP address of the clent (not the clent s DNS server) Dynamc Stablty Clearly, the demands of clents are not constant, but they change n tme. Hence, we want an algorthm that wll not make changes n assgnment f there are only small changes n the demand. We would lke to have persstent mappngs because ths s requred n cachng and state preservaton. For example, t would be very annoyng for a user f hs shoppng cart gets lost frequently because hs browser s drected to another server. Ths s also to make the system mmune to dynamc nstablty and oscllatons. One smple approach for ths problem s to slghtly ncrease the cost of adacent lnks once a stable soluton s found for a gven lnk. 7-7

8 MIT Lecture 7 March 20, 2002 Sprng Stable Marrage Technques In the second half of ths talk, we dscuss methods for formulatng and solvng load balancng problems usng stable marrage technques. In the basc stable marrage problem, we have Ò men and Ò women, whch we can model as nodes n a bpartte graph. Assocated wth each man s a preference lst of all the women and assocated wth each woman s a preference lst of all the men. We then compute a marrage between the men and women, whch s nothng more than a matchng n our bpartte graph. w3, w2, w m, m2, m3 w3, w, w2 m2, m, m3 w, w3, w2 m, m3, m2 n men n women Fgure 7.2. A stable marrage. Gven some marrage, we call a man-woman couple Ñ Ûµ a rogue couple f they are not pared together but both of them prefer each-other to ther currently-assgned mates. A marrage s sad to be stable f t has no rogue couples, and unstable otherwse Gale-Shapley Algorthm Stable marrages are typcally computed usng the well-known Gale-Shapley algorthm. The algorthm s actually qute smple: each man proceeds through hs preference lst, startng from hs preferred mate, and he proposes to each of the women on the lst n sequence untl he s accepted. Each woman smply wats and accepts the best proposal ssued to her so far. If she s currently engaged to a man Ñ and then receves a proposal for a more favorable man, she wll drop Ñ and accept the new proposal, n whch case Ñ wll smply contnue down hs preference lst untl he s agan accepted. The algorthm s actually completely symmetrc, n that ether the men or the women may do the proposng, but for smplcty we ll assume here that the men do the proposng. More precsely, the algorthm repeats the followng operatons untl all men and women are pared: Fnd an un-pared man Ñ A proposal s ssued by Ñ to the next canddate on hs lst, Û If Ñ s more preferable to Û than her currently-assgned mate (f any), then she accepts Ñ and drops her currently-assgned mate (f any). Ths algorthm runs n tme Ç Ò ¾ µ n the worst case, snce we consder at most once each entry n each man s preference lst, and spend Ç ½µ tme per entry. Theorem 7.. At the end of the Gale-Shapley algorthm, everyone s engaged. 7-8

9 MIT Lecture 7 March 20, 2002 Sprng 2002 Proof: Note that the number of engaged men at the end wll be equal to the number of engaged women at the end. It could not be the case that there remans an un-pared couple Ñ Ûµ, snce at some pont Ñ would have proposed to Û, and she would have accepted. Theorem 7.2. The soluton obtaned by the Gale-Shapley Algorthm s a stable matchng. Proof: Assume that the fnal matchng s not stable,.e. that there exsts parngs Ñ ½ Û ½ µ and Ñ ¾ Û ¾ µ but Ñ ½ Û ¾ µ s a rogue couple. Snce Ñ ½ prefers Û ¾ to Û ½, Ñ ½ would have proposed to Û ¾ frst, who must have reected hm, so Û ¾ s current mate must be preferred to Ñ ½. Ths s a contradcton, snce Ñ ½ s hgher than Ñ ¾ n Û ¾ s preference lst. Hence, the matchng must be stable. A stable par Ñ Ûµ s a par whch s matched n some stable marrage. If Ñ Ûµ s a stable par, we say that Û s a stable partner of Ñ. Theorem 7.3. The outcome of the Gale-Shapley Algorthm s a man-optmal assgnment. That s, each man s pared wth hs most-preferred stable partner. Proof: Suppose not. Consder some executon order and consder the frst pont n tme when a stable par, Ñ ½ Û ¾ µ, s reected...., w2,..., w,... m Stable par..., w2,..., w3,... m2 Frst reecton of a stable par w w2..., m2,..., m,... Another stable par w3 Ths reecton can ether occur f Û ¾ s already engaged to a preferred man (Ñ ¾ ), or f Ñ ¾ comes along and proposes to Û ¾ whle she s engaged to Ñ ½. Snce we re presumng that Ñ ½ Û ¾ µ s a stable par, there s some stable matchng Å n whch Ñ ½ and Û ¾ are pared together let Û be the woman wth whom Ñ ¾ s pared n Å, meanng that Ñ ¾ Û µ s also a stable par. It cannot be the case that Û s hgher than Û ¾ on Ñ ¾ s preference lst, as that would mply that Ñ ¾ would have already proposed to Û and been reected, and we are assumng that Ñ ½ s reecton by Û ¾ s the frst reecton of a stable partner so far. Thus Û ¾ appears before Û on Ñ ¾ s preference lst. Ths means that Ñ ¾ Û ¾ µ s a rogue couple n Å, whch contradcts the stablty of Å. The precedng theorem tells us that remarkably, the order of the proposals durng the algorthm s rrelevant. The algorthm always arrves at the same stable matchng, even though there s not necessarly a unque stable matchng. Usng a smlar lne of reasonng, we can show that the matchng computed by the Gale-Shapley algorthm s also woman-pessmal, n the every woman ends up assgned to her least-preferred 7-9

10 MIT Lecture 7 March 20, 2002 Sprng 2002 stable partner. Rememberng the symmetry of the problem, however, one should note that f the women were to do the proposng, they would receve an optmal assgment whle the men would receve a pessmal assgnment. Some researchers have attempted to address the queston of computng stable marrages whch are far to both partes Truncatng the Preference Lsts In order to model the load balancng problem usng stable marrages, we need to consder a few extensons to the basc stable marrage problem above. Frst, we consder a class of problems where we truncate the preference lsts of the men and/or, snce for large load balancng problems, we shall see that mantanng complete preference lsts may lead to mpractcal storage requrements. For the purposes of determnng whom to reect, women can consder the men not on ther preference lsts as beng arbtrarly-ordered at the bottom of ther preference lsts. We now redefne Ñ Ûµ as a rogue couple f:. Both Ñ and Û are on each other s preference lsts, 2. Ñ s ether unassgned or prefers Û to hs current mate, and 3. Û s ether unassgned or prefers Ñ to her current mate The Gale-Shapley algorthm runs essentally the same on problem nstances wth truncated preference lsts. The outcome wll be a stable assgnment (.e. there wll be no rogue couples, as defned above), although t s possble that some men and women may end up unassgned. The followng theorem then holds. Theorem 7.4. Applyng the Gale-Shapley Algorthm wth truncated preference lsts stll gves a stable assgnment. Furthermore, each man who ends up assgned (unassgned) wll be assgned (unassgned) n every stable assgnment, and each assgned (unassgned) woman wll be end up beng assgned (unassgned) n every stable assgnment. Proof of ths theorem and the remanng theorems s omtted. For a complete treatment of these topcs, refer to the book The Stable Marrage Problem by Gusfeld and Irvng Dfferent Numbers of Men and Women Next, we can consder a class of problems where the numbers of men and women are not the same but the men and women all have complete preference lsts. The Gale-Shapley algorthm stll works n ths settng, and stll computes a stable matchng wth some nce propertes. Theorem 7.5. If there are fewer men than women, and everyone has a complete preference lst, the Gale-Shapley algorthm computes a stable matchng whch s stll man-optmal and womanpossble. Moreover, the men wll all be assgned, and the women wll be parttoned nto 2 sets: () those who are always assgned n every stable matchng, and () those who are never assgned n any stable matchng. If there are more men than women, then the women wll all be assgned and the men wll undergo a partton nto 2 sets. 7-0

11 MIT Lecture 7 March 20, 2002 Sprng 2002 Theorem 7.6. In the event that there are dfferent numbers of men and women and that preference lsts are ncomplete, there wll be a partton nto 2 sets nduced n both the men and n the women. Members of one set wll be assgned n every stable matchng, and members n the other set wll never be assgned n any stable matchng Many-to-One Assgnments: Addng Capactes To avod any awkward stuatons gong forward, we wll alter our dscusson to talk about assgnng medcal students to hosptals (ths was actually one of the orgnal applcatons of stable marrage technques). The dfference here s that hosptals can accept more than one medcal student; to each hosptal À we assgn an ntegral capacty...., H,... S C nodes, all wth dentcal preference lsts H..., S,... Capacty C Medcal Students Hosptals Fgure 7.3. Assgnng medcal students to hosptals (wth capactes). Ths generalzaton of the stable marrage problem s easy to accomodate f we smply splt every hosptal node À nto nodes wth unt capacty, all wth equvalent preference lsts. Ths transforms the problem nto an uncapactated stable marrage problem, whch we can solve usng the Gale-Shapely algorthm as descrbed above. One should note that t s not necessary to explctly perform ths transformaton. All we need to do s mantan, for each hosptal, a lst of medcal students currently assgned to t. If the hosptal ever receves a proposal when t has already reached capacty, t smply reects the least-preferred of these students (ncludng possbly the proposng student). If the algorthm stores these lsts of assgned students n heaps, then we wll only spend Ç ÐÓ Òµ tme per proposal (here, Ò s the number of students), for a total runnng tme whch s Ç Ä ÐÓ Òµ, where Ä s the sum of the lengths of all of the medcal students preference lsts (snce Ä s an upper bound on the total number of proposals ssued). 7-

12 MIT Lecture 7 March 20, 2002 Sprng Dealng wth Demands and Capactes We now take the fnal steps necessary to model our load balancng problem. Consder the problem of assgnng clents to servers, where each server has an ntegral capacty and each clent has an ntegral demand. The clents rank the servers accordng to localty, and the servers must choose some method of rankng the clents one potental way to do ths s to have a server Ë prefer clent to clent f clent B wll suffer less from a reecton (.e., clent B may have other choces n ts preference lst whch are nearly as good as Ë). We reduce the problem to an uncapactated problem by splttng each clent wth demand nto unt-szed nodes wth equal preference lsts, and by (mplctly) splttng each server wth capacty nto unt-szed nodes wth equal preference lsts. To avod utlzng excessve space, we typcally truncate each clent s preference lst to contan only ts frst few preferred servers. We may not need to explctly generate and store preference lsts for the servers at all, for example f we base these on the clent preference lsts as dscussed above. The Gale-Shapley Algorthm gves us a stable assgnment, but t may be fractonal n the sense that a clent may have some unts of ts demand assgned to dfferent servers. It s also possble that f there s not enough capacty, there may not be a matchng whch assgns all of the demand. However, due to the stable marrage propertes prevously dscussed, we at least know that f a clent has only an «fracton of ts demand satsfed by our stable marrage soluton, then t wll have exactly an «fracton of ts demand satsfed n every stable matchng. Smlarly, we utlze the same amount of capacty n each server n every stable marrage soluton Improvng the Runnng Tme Recall that when we added capactes to the servers, we could mplctly blow up server nodes nto clouds of unt nodes wthout affectng runnng tme much. Ths s not qute possble wth the clent nodes, however, so the runnng tme of our algorthm wll now be roughly lnear n the total demand over all clents, whch could be qute neffcent. To reduce ths runnng tme, we make requests n batches. That s, an aggregate clent node wll propose to a server wth a block of several unts of demand all at once. If the server can accept all of these, then we contnue to treat the clent node as an aggregate quantty. If the server accepts only part of the request, then we splt the clent node nto two smaller aggregate nodes, one of whch s assgned to the server and the other of whch contnues to ssue aggregate proposals. The ssuance of aggregate proposals by tself does not mprove our worst-case runnng tme, so we use the followng trck: a clent node wll only ssue an aggregate request f at least some fracton of ts demand remans unassgned. If ths s the case, there wll be Ç Ä µ total requests, and one may conclude after a bt of analyss that ths yelds a total runnng tme of Ç Ä ÐÓ Òµ. The algorthm may termnate wth some demand unassgned, but at most an fracton of every clent s demand wll reman unassgned, whch s perhaps a reasonable trade-off for a runnng tme whch s nearly lnear n the szes of the clents preference lsts. 7-2