Scalability of a Mobile Cloud Management System

Transcription

1 Scalablty of a Moble Cloud Management System Roberto Bfulco Unversty of Napol Federco II roberto.bfulco2@unna.t Marcus Brunner NEC Laboratores Europe brunner@neclab.eu Peer Hasselmeyer NEC Laboratores Europe peer.hasselmeyer@neclab.eu Fasal Mr NEC Laboratores Europe fasal.mr@neclab.eu Roberto Canonco Unversty of Napol Federco II roberto.canonco@unna.t ABSTRACT Ubqutous network access allows people to access an ever ncreasng range of servces from a varety of moble termnals, ncludng laptops, tablets and smartphones. A flexble and economcally effcent way of provsonng such servces s through Cloud Computng. Assumng that several cloudenabled datacenters are made avalable at the edges of the Internet, servce provders may take advantage of them by optmally locatng servce nstances as close as possble to ther users. By localzng traffc at the edges of access networks, such an approach may result benefcal for both servce and network provders. In ths paper we present Follow- Me Cloud (FMC), a technology developed at NEC Laboratores Europe that allows transparent mgraton of servces n TCP/IP networks, thanks to the dynamc confguraton of a set of coordnated OpenFlow swtches located at the edge of the network. In partcular, n ths paper we analyze the scalablty propertes of an FMC-based system and propose a role separaton strategy based on dstrbuton of control plane functons whch enables scale-out of the system. By means of smulaton, we prove that the applcaton of the proposed separaton strategy results n less state retaned by ndvdual OpenFlow controllers and n more effectve localzaton of network traffc. Categores and Subject Descrptors C.2.1 [Network Archtecture and Desgn]: Dstrbuted networks Keywords Moble Cloud Computng, Scalablty, Network Management, OpenFlow, Software Defned Networkng Permsson to make dgtal or hard copes of all or part of ths work for personal or classroom use s granted wthout fee provded that copes are not made or dstrbuted for proft or commercal advantage and that copes bear ths notce and the full ctaton on the frst page. To copy otherwse, or republsh, to post on servers or to redstrbute to lsts, requres pror specfc permsson and/or a fee. MCC 12, August 17, 2012, Helsnk, Fnland. Copyrght 2012 ACM /12/08... $ INTRODUCTION Rch meda servces that may be accessed anywhere are expected to play a sgnfcant role n the moble apps envronment n the next few years, due to ther ablty to generate sgnfcant revenues. These applcatons have become techncally feasble thanks to the ubqutous avalablty of multmeda devces and broadband connectvty. Nonetheless, the ablty of provsonng such servces to large numbers of moble users s stll a techncal challenge for servce provders. Servce provsonng, today, fnds n the emergng Cloud Computng paradgm a flexble and economcally effcent soluton, n partcular for small and medum enterprses that do not want to nvest huge captals for creatng and managng ther own IT nfrastructures. The basc tenet of cloud computng s that end users do not need to care about where a servce s actually hosted, whle servce provders may dynamcally acqure the resources they need for servce provsonng n a pay-per-use model. Whle for most of elastc web applcatons the relatve poston of clent and server end-systems does not affect the perceved Qualty of Experence, provded enough bandwdth s avalable n the end-to-end path connectng clents wth servers, rch nteractve applcatons are sensble to other communcaton metrcs, such as delay and jtter. In the absence of explct QoS control mechansms n the network, the only way to mprove Qualty of Experence s to locate servers as close as possble to user termnals. Such an approach, largely exploted by Content Delvery Networks, can be further advanced n the era of Cloud Computng. Assumng that several cloud-enabled datacenters are made avalable at the edges of the Internet, servce provders may take advantage of them for optmally locatng servce nstances as close as possble to ther users. In such a context, moblty of user termnals makes such locaton decsons even more dffcult. In ths paper, we present Follow-Me Cloud (FMC), a technology developed at NEC Laboratores Europe to overcome the current TCP/IP archtecture moblty lmtatons and to support novel Moble Cloud Computng applcatons, by provdng both the ablty to mgrate network end-ponts and to reactvely relocate network servces dependng on users locatons, n order to guarantee adequate performance for the clent-server communcaton and, at the same tme, have a precse control on the use of network resources by localzng network traffc generated by applcatons. The FMC archtecture s based on cooperatng FMC controllers located n the networks of collaboratng operators. FMC controllers modfy packet forwardng n such a way that locaton changes of users and of servces (e.g., through mgraton of Vrtual Machnes) are transparently managed by the network nfrastructure, wthout any need of reconfgurng the end systems. Dependng on the users moblty patterns, 17

2 a) b) Correspondent Swtch (CS) Home Swtch (HS) Mgratng Node (MN) A C Correspondent Node (CN) Foregn Swtch (FS) B Correspondent Controller C CC Home Controller HC Foregn Controller FC Fgure 1: Follow-Me Cloud Use Case FMC control-plane decde f, when and where network servceshavetobemgrated. The coarse flow of actons performed by FMC to manage a mgratng servce s shown n fgure 1. In ths smplfed use case, ntally, a user accesses a dedcated servce, e.g., a remote desktop applcaton, n the home envronment (.e., usually, hs/her offce or home). He/She then goes on a trp and, whle on the move, accesses the servce through an app runnng n a smartphone. Over tme, the smartphone gets connected to the Internet through dfferent moble network operators. After a change of the termnal s network attachment pont, FMC may decde to trgger mgraton of the servce nstance to a dfferent network locaton, e.g. a data center, closer to the new network attachment pont. As shown n step 3, the applcaton mgrated to the new data center, provdng the user wth mproved Qualty of Experence and/or reducng the servce provsonng cost for the network operator. Follow-Me Cloud s mplemented usng OpenFlow (OF) [1]. It uses the packet flterng and rewrtng capabltes of OpenFlow to acheve the seamlessness of mgraton, and confgures network equpment through OpenFlow rules (OFR). OF-enabled networkng equpments (.e., swtches) are therefore needed n the network for FMC to work. Nevertheless, OF equpments are only needed at the edges of the network. In ths paper we present how FMC acheves network end-ponts moblty and our soluton to solve scalablty ssues. Cloud servces reactve relocaton strateges are not dscussed here, and wll be the topc of future work. The rest of ths paper s structured as follows. We dscuss related work n secton 2. FMC moblty management procedures are presented n secton 3, next we dscuss the scalablty ssues of an FMC-based system n secton 4, whle our soluton to support the scale-out of the archtecture s presented n secton 5 and ts evaluaton n secton 6. Fnally, n secton 7 we conclude and present future work. 2. RELATED WORK The dea of explotng the lve mgraton capabltes of modern vrtualzaton technologes for dynamcally changng the poston of a servce nstance on a geographc bass has been alredy proposed n the past (e.g. n [6]). Lve mgraton of Vrtual Machnes s a common practce n vrtualzed data centers, n whch the nternal networkng nfrastructure may be desgned as a large sngle IP subnet. Mgraton of VMs across the boundares of a sngle IP subnet, on the other hand, s not straghtforward, as the TCP/IP protocol stack does not provde the needed flexblty n terms of moblty support for network end-ponts. A technque for the mgraton of network end-ponts n a data-center envronment by means of a coordnated set of agents s presented n [2]. A Fgure 2: a. End-ponts moblty reference scenaro; b. FMC dstrbuted archtecture frst example of the applcaton of OpenFlow to solve network moblty ssues s presented n [3], where OpenFlow s used to mgrate VMs among dfferent IP subnets, usng a network fully composed of OpenFlow swtches. None of these papers present solutons to the control-plane scalablty problems that derve from the applcaton of these technques n large scale networks. Other approaches, lke the Locator/Identfer Separaton Protocol [4] (LISP), are based on the concept of separaton among locator and dentfer addresses. The LISP archtecture uses an alternate topology to dstrbute ID/LOC mappng nformaton among routers n the network. LISP does not provde moblty support natvely, whle t s added n ts moblty extensons that need drect nvolvement of moble devces n the ID/LOC mappng. MobleIP and MobleIPv6 both enable end-pont moblty, but requre drect nvolvement of the movng enttes. On the other end, Proxy MobleIP provdes moblty wthout nvolvng end-ponts, by placng moblty aware proxy devces n the network. In any case, n MobleIP the forwardng of the data packets s usually performed through tunnels and/or trangular routng that are far less effcent n comparson to the FMC soluton. 3. END-POINTS MOBILITY Follow-Me Cloud (FMC) enables moblty of network endponts among dfferent IP subnets n a TCP/IP network, both n closed envronments, such as data-centers, and on a geographc scale, mantanng all the ongong network communcatons of the movng entty actve and requrng no modfcatons to the nvolved end-ponts. FMC s appled to a TCP/IP network n whch access networks are connected to a core network, that provdes connectvty among them, through OpenFlow-enabled swtches (OFS). Current TCP/IP network archtecture uses a sngle address to both dentfy and locate a devce on the network, makng the network unable to support moblty natvely. FMC realzes the splt of dentfer and locator concepts n the edge network, usng the OFSes to enforce the splttng n a transparent manner for network end-ponts. Fgure 2.a shows a typcal applcaton scenaro, wth three access networks, and explans also the names used to dentfy all the network devces nvolved. Names are assgned from the perspectve of a partcular mgratng node (MN). Usng FMC, the MN can mgrate from an access network A, to an access network B, wthout changng t s network confguraton (e.g., IP address, Gateway Address). From a network perspectve, MN s totally unaware that the access network on whch t s resdng s changed. All the ongong communcatons are kept actve, e.g., TCP sessons are not lost. Any correspondent 18

3 node,.e., any node that s on an access network dfferent from A or B and that s communcatng wth MN, s unaware of the MN locaton change as well. To provde ths result, FMC requres that a new IP address, belongng to the B network, s assgned to MN to work as locator. The orgnal IP address of MN s stll used by MN tself and by any node that s communcatng wth MN, snce t works as dentfer. For any mgrated node, the FMC controller (FMC-C) stores the dentfer/locator mappng nformaton, that s used to confgure nvolved OFSes wth proper OpenFlow rules. The outcome of FMC operatons s that each packet destned to a mgrated end-pont, before traversng the core of the network, s processed to substtute the dentfer address wth the locator address. Then, the locator address s substtuted agan wth the dentfer address, before the packet s delvered to MN. A smlar address translaton s performed on the source address of packets sent by MN. Hence, the dentfer address s used to send/receve packets n the edges of the network, whle the locator address s used n the core of the network, to forward packets to the correct locaton. Border devces,.e., OFSes, are n charge of performng the dentfer/locator and locator/dentfer translatons. 4. SCALABILITY FMC uses OpenFlow to provde transparent dentfer/locator (ID/LOC n short) splttng, ntroducng some OFRs to support the redrecton of packets to the new locaton of a mgrated node. Even though the used approach s tryng to be lghtweght, requrng no modfcatons to the tradtonal IP routng, when a mgraton happens, several enttes are nvolved n communcaton at the network control plane. In partcular, FMC controllers need to coordnate ther actvtes, and varous OFSes need updated forwardng rules. In ths secton we are amng at assessng the scalablty of FMC. Our work s manly focused on evaluatng scalablty from the perspectve of the number of managed OFRs. We see two man ssues: () how many rules need to be nstalled on a partcular OFS, and () how many rules must be managed by the FMC controllers. We defne the former as a data-plane scalablty ssue and the latter as a control-plane scalablty ssue. Data-plane scalablty affects the ablty of applyng FMC when an OFS s nvolved n many IP address mgratons,.e., when a large number of rules must be nstalled. An OFS has lmted capacty n the number of rules t s able to support, that means, from FMC perspectve, that there s a lmt on the number of concurrent mgratons that can be provded for the network served by that swtch. Even f ths ssue can be a serous problem, and t s worth to be nvestgated, for the purpose of FMC we assume that t s solvable usng a careful parttonng of the network,.e., reducng the dmenson of the network served by a sngle swtch. Clearly, usng ths scale-out approach, we are addng more network devces, hence, we are potentally ncreasng the work load on the control-plane. Control-plane scalablty s, n fact, related to the number of devces and to the total number of OFRs that must be managed by FMC controllers. The number of devces s strctly dependent on the network dmenson and on the parttonng level we are applyng, e.g., to solve the dataplane scalablty ssue. The total number of rules s nstead drectly dependent on the total number of concurrent IP address mgratons. To evaluate the total number of generated rules we use the smplstc assumpton that there s only one centralzed FMC controller 1. Moreover, we assume that ths controller knows n advance on whch OFSes rule nstallaton s needed. Ths way we are able to evaluate the number of rules needed for the packet forwardng redrecton, wthout takng nto account mplementaton-dependent rules. The number of generated rules for the -th IP address mgraton s: R = r hs + r fs + j r cs j (1) where r hs are the number of rules nstalled at the home swtch (HS) and foregn swtch (FS) for the -th IP and r fs address mgraton, and rj cs s the number of rules nstalled at the j-th correspondent swtch that s exchangng packets wth the -th mgrated IP address. The number of rules for each mgrated IP address s gven by the followng formulas: r hs = α + H (2) r fs = β + F (3) r cs j = γ + C j (4) The varables H, F and C j represent the number of nodes from home, foregn and j-th correspondent networks that are exchangng packets wth the -th mgrated IP address. The constants α, β and γ are the fxed number of rules requred by FMC for packet redrecton per mgraton 2. The total number of OFRs managed by the FMC controller s the sum over of the rules as expressed n (1), plus some rules nstalled once for each HS or FS: R =2N + R (5) where N s the total number of HSes (and snce one FS corresponds to each HS, t s also the total number of FSes) nvolved n IP addresses mgratons. From equatons (1) and (5) t s clear that the number of rules s drectly proportonal to the number of concurrent mgratons, and to the number of nodes on the HN, FN and CNs that are exchangng packets wth mgrated addresses. 5. DISTRIBUTED CONTROLLER Provdng scalablty at the control-plane s a key requrement to make FMC usable n large-scale networks and t s the focus of the work presented n ths secton. Our am s to enable the balancng of the FMC operatons load among a number of FMC controllers, actually buldng a FMC dstrbuted controller. Buldng a dstrbuted controller provdes a twofold outcome: apart from scalablty, t adds also the flexblty and the dstrbuton of responsbltes requred to enable the use of FMC functonaltes across admnstratve boundares. The desgn of the dstrbuted controller follows the prncple of dstrbutng knowledge to where t s actually needed. In our case, the needed nformaton at a partcular controller s the dentfer/locator mappng for a gven network entty, 1 The OpenFlow archtecture actually suggests a centralzed approach to the network control-plane development, through the use of a centralzed OpenFlow controller that s connected to a number of OFSes. 2 In the current mplementaton α =3,β =6andγ =3 19

4 whle the controllers that need to know about ths mappng are the ones that are controllng the HS, the FS and CSes. To manage ths nformaton and to dstrbute t among controllers, we desgned the archtecture depcted n Fgure 2.b. Wth respect to the mgratng node, we dentfy three dfferent roles among FMC controllers: Home Controller (HC) that controls the network to whch the dentfer address belongs to; Foregn Controller (FC) that controls the network to whch the locator address belongs to; Correspondent Controller (CC) that controls one or more CSes. The archtecture s flexble enough to enable a sngle controller to play one, two or all the roles for the same mgratng node, e.g., because the same controller s n charge of managng multple networks. Ths approach also offers the possblty to adapt the number of controllers used n the network, n order to tackle the actual network load: t s possble to use a scale-out approach, ncreasng the number of access networks, and consequently reducng the number of nodes per access network. Then, each controller s assgned a number of access networks to manage (the range s from one to all the access networks), wth the am of sharng the overall load. Snce the MN s dentfer address belongs to a network managed by HC, ths controller s always nvolved n any MN mgraton, makng t a good canddate to be an authortatve repostory for the MN mappng nformaton. HC has therefore been selected to be n charge of managng the mappng nformaton for the MN whle t s away from ts home locaton. When MN mgrates to a foregn network (FN), the HC s notfed about the mgraton and nforms the FC that MN s mgratng to a network that FC tself s managng. Snce FC s n charge of managng the network to whch the locator belongs to, we leave to FC the responsblty to generate the locator address for MN 3. Once the locator s defned, t s sent back to the HC so that both FMC-Cs have the complete nformaton about the ID/LOC mappng to perform the requred confguratons. So far, just HC and FC are nformed and confgured to support the mgraton. Eventually, a CC wll need the nformaton about the ID/LOC mappng, because some endponts connected to CSes are tryng to establsh communcaton wth MN. Whle n the case of HC and FC we know whch are the HS and FS, snce they are source and destnaton of the mgraton, we do not have ths nformaton for the CSes. At any pont n tme, a network entty can be nvolved n a communcaton sesson wth MN, and, dfferently from what we dd n secton 4, we are not assumng to know n advance who s gong to start ths communcaton. To handle ths ssue, our archtecture uses a reactve approach: once a new communcaton wth a CN s establshed, the nvolved CC s updated properly. We have to dstngush two cases: () the correspondent node starts the communcaton, and () the mgratng node starts the communcaton. In the frst case, when the CN sends a packet to MN, t always uses the dentfer address as the packet s destnaton. Snce the CS does not know yet about the updated ID/LOC mappng, t performs no rewrtng on the packet, whch s therefore forwarded along the route to MN s home 3 How the locator address s actually obtaned s out of the scope of ths work, anyway, t s possble to nteract wth a network management system, or wth a DHCP server to easly generate t. HC CC Fgure 3: Overvuew of the eactve update of the dentfer/locator mappng at the CC. packet_n (destnaton IP: dentfer) get CC address from packet source IP Rewrte IP addresses accordng to LOC/ID mappng HC Networks/ Controllers MAP send MN LOC/ID mappng update Add CC to the lst of updated controllers Reroute packet CC Set up OF rules Fgure 4: Reactve update of the dentfer/locator mappng at the CC. network. Once the packet reaches the HS, t s ntercepted and a message to update the ID/LOC mappng at the CC s sent. The packet s then forwarded by substtutng the dentfer wth the locator, usng trangular routng. Fgure 3 shows an overvew of the operatons, whle fgure 4 shows the detals of the nteractons among HC and CC. We pont out here that t s necessary to store the nformaton of whch CC has been updated wth the ID/LOC mappng nformaton, snce subsequent mgratons wll trgger an update for all the stored CCs. Otherwse, packets generated by CNs wll contnue to be drected to the old MN s locaton. In the second case, when MN starts the communcaton wth a CN, we have to take nto account that the FS s already applyng the ID/LOC mappng. Snce, on the other hand, the CS does not know yet about the ID/LOC mappng, the packet would reach the CN usng the locator address as source, then, CN would use the locator address to talk wth the mgrated node. If no more mgratons happen for MN, there are no problems wth ths behavor, but, f a new mgraton happens, then the locator changes, hence, the communcaton wth CN s lost. Because of ths ssue, we should ensure that any entty always uses the dentfer as destnaton address. To provde CS 20

5 Fgure 5: Number of rules managed by centralzed FMC-C and FC, for one mgraton. Fgure 6: Number of long dstance messages sent or receved, for one mgraton. the afore mentoned property, FC has to ntercept any packet that s sent by the mgrated node and s destned to a CN, whose network s FMC controller s stll not updated about the ID/LOC mappng for MN. Ths way, FC s able to send updated ID/LOC nformaton for MN to CC. It s worth to note that the FC does not nform HC about updated CC whle MN s stll located n ts admnstratve doman. Instead, FC mantans a local lst of updated CCs that s sent back to HC when a new MN mgraton happens. When MN mgrates back to ts home network, or to a new network, all the ID/LOC mappng nformaton dstrbuted at dfferent FMC controllers are no longer vald. As for any other MN mgraton, when HC s nformed that MN s mgratng, t updates the old FC about the MN locaton change. Durng ths nteracton, FC sends ts local lst of updated CC to HC. Then, HC updates the ID/LOC mappng nformaton on any prevously updated CC. 6. EVALUATION We tested our prototype mplementaton both on a Mnnet [5] testbed and on a physcal testbed equpped wth NEC OpenFlow swtches. Wth regard to the scalablty of the dstrbuted archtecture, to evaluate the total number of rules we have to modfy the r fs expresson, substtutng the defnton gven n (3) wth the followng formula, to take nto account the reactve update of ID/LOC mappng nformaton: r fs = δ + F + J (6) where J s the number of CNets exchangng packets wth the -th mgrated node, and δ s a fxed number of OFRs. In fgure 5 a comparson of the number of rules managed n the case of a centralzed FMC controller s compared to the number of rules managed by the most loaded FMC controller of the dstrbuted archtecture,.e., the FC. The number of rules s evaluated for one mgraton, wth a lnearly ncreasng number of nodes that are exchangng packets wth MN and that are located at home networks (HNs), foregn networks (FNs), and correspondent networks (CNets). Takng nto account also the OFRs nstallaton tme, we have to consder the ssue that arses when an FMC controller s located far away from the swtch t s controllng, snce the network delay has to be added to the nstallaton tme. Dstrbutng the archtecture enables a better and faster handlng of rules nstallaton: even f FMC-related rule nstallaton stll needs to face some network delays because of the coordnaton among the controllers, the majorty of actons are performed locally at the controller, that s typcally placed close to the network t s controllng. Assume a scenaro n whch managed networks are far apart and further assume that a sngle centralzed controller s placed near the FS whch s the swtch that requres the most rule nstallaton messages. Wth ths deployment, any message exchanged between the controller and HSes/CSes experences hgh delay. In the dstrbuted archtecture, nstead, only nter-fmc controllers messages experence hgh delay. The number of requred long dstance messages s lnearly ncreasng wth the number of nodes n HN, FN and the number of CNets, as shown n fgure 6. The fgure compares the centralzed FMC controller case to the FC of the dstrbuted archtecture, n the worst case (.e., when FC s n charge of updatng CCs). 7. CONCLUSION AND FUTURE WORK In ths paper we ntroduced Follow-Me Cloud, a technology that provdes moblty features n a TCP/IP network for both users and servces, usng OpenFlow-enabled equpment at the edges of the network. We presentedthemplemented moblty technque, the dstrbuted archtecture used to support the operatons and an early scalablty evaluaton of the developed prototype. The current mplementaton and developed test-beds provde a sold base for further research and development. In partcular, the logc for decdng when and where to mgrate servces to needs to be realzed. In addton to the orgnal use case of supportng moble users, t turned out that FMC technology can be used for other scenaros as well, ncludng the general problem of crossoperator servce mgraton and the mgraton of core moble network components. These are just two examples of potental use cases for Follow-Me Cloud technology, hghlghtng ts applcablty n many domans. Acknowledgements Ths research has been partly supported by the PRIN SFINGI project funded by the Italan Mnstry of Unversty and Research. 21

6 8. REFERENCES [1] Openflow - [2] Bfulco, R., Canonco, R., Ventre, G., and Manett, V. Transparent mgraton of vrtual nfrastructures n large datacenters for cloud computng. In Computers and Communcatons (ISCC), 2011 IEEE Symposum on ( july ), pp [3] Erckson, D., Gbb, G., Heller, B., Naous, J., Underhll, D., Appenzeller, G., Parulkar, G., McKeown, N., and Al., E. A demonstraton of vrtual machne moblty n an openflow network. Proceedngs of ACM SIGCOMM Demo (2008), 513. [4] Farnacc, D., Fuller, V., Meyer, D., and Lews, D. Locator/ID separaton protocol (LISP). Internet-Draft draft-etf-lsp-13.txt, IETF Secretarat, June [5] Lantz, B., Heller, B., and McKeown, N. A network n a laptop: rapd prototypng for software-defned networks. In Proceedngs of the Nnth ACM SIGCOMM Workshop on Hot Topcs n Networks (New York, NY, USA, 2010), Hotnets 10, ACM, pp. 19:1 19:6. [6] Manett, V., Canonco, R., Ventre, G., and Stavrakaks, I. System-level vrtualzaton and moble p to support servce moblty. In Proceedngs of the 2009 Internatonal Conference on Parallel Processng Workshops, ICPPW 09 (2009), pp