A dynamic bandwidth allocator for virtual machines in a cloud environment

Transcription

1 A dynamc bandwdth allocator for vrtual machnes n a cloud envronment Ahmed Amamou, Manel Bourguba, Kamel Haddadou, Guy Pujolle To cte ths verson: Ahmed Amamou, Manel Bourguba, Kamel Haddadou, Guy Pujolle. A dynamc bandwdth allocator for vrtual machnes n a cloud envronment. CCNC IEEE Consumer Communcatons and Networkng Conference, Jan 212, Las Vegas, Unted States. pp.99 14, 212, <1.119/CCNC >. <hal > HAL Id: hal Submtted on 3 Sep 213 HAL s a mult-dscplnary open access archve for the depost and dssemnaton of scentfc research documents, whether they are publshed or not. The documents may come from teachng and research nsttutons n France or abroad, or from publc or prvate research centers. L archve ouverte plurdscplnare HAL, est destnée au dépôt et à la dffuson de documents scentfques de nveau recherche, publés ou non, émanant des établssements d ensegnement et de recherche franças ou étrangers, des laboratores publcs ou prvés.

2 A Dynamc Bandwdth Allocator for Vrtual Machnes n a Cloud Envronment Ahmed Amamou, Manel Bourguba, Kamel Haddadou and Guy Pujolle LIP6, Perre & Mare Cure Unversty 4 Place Jusseu 755 Pars, France Emal: {ahmed.amamou, manel.bourguba, kamel.haddadou, guy.pujolle}@lp6.fr Abstract Cloud computng s an emergent paradgm that allows to customers to rent nfrastructure, platforms and software as a servce. Wth resource sharng and reuse through vrtualzaton technology, cloud envronments become even more effectve and flexble. Nevertheless, networkng wthn vrtualzed cloud stll presents some challenges n performance and resource allocaton. In ths paper, we propose to ntegrate an SLA-based Dynamc Bandwdth Allocator (DBA) n a vtualzed cloud envronment. DBA manages bandwdth allocaton effcently through allocatng bandwdth accordng to the applcaton requrements and the establshed agreement. It also adjusts the allocated bandwdth dynamcally upon change and reduces physcal resources usage by droppng packets n the vrtual machnes rather than the drver doman. Through expermental evaluaton we showed the effcacy of the proposed algorthm and the agreements respect. I. INTRODUCTION Cloud computng s a new technology trend that s reshapng the nformaton technology landscape and ganng much of the nterest of ndustry as well as academa. Cloud computng enables provders to delver software, platform and nfrastructure as a servce to remote customers over the network. The need behnd the cloud computng s the deployment of large scale data centers at low costs. Henceforth, customers do not need to plan for provsonng anymore; they rent computng and networkng resources on demand and ncrease those resources and pay for them on a short-term bass as needed [1]. Cloud computng offers cost effectveness and hgh avalablty of resources. The provder owns a pool of resources that t confgures, adjusts and offers to customers accordng to Servce Level Agreements (SLAs). When coupled wth vrtualzaton, the cloud computng model even enables hgher utlzaton rates whle reducng dedcated hardware costs. Vrtualzaton s an old technology that ganed renewed nterest recently. It bascally offers a parttonng technque to run multple and solated vrtual machnes on a sngle physcal machne. Thus, vrtualzaton optmzes hardware usage through resource reuse and multplexng whch decreases the cost of power, hardware and network bandwdth. Furthermore, through on demand vrtual machne creaton and mgraton and dynamc resource allocaton t enables flexble, scalable and cost effectve vrtualzed data centers deployment. A Vrtual Machne Montor (VMM) s a software layer that manages resource sharng among the concurrent vrtual machnes (VMs) and ensures that dverse and dfferent applcatons run n solated envronments. The drver doman s a specal vrtual machne that s n charge of managng the shared access to the devces, especally the network nterface card (NIC). The drver doman handles networkng by multplexng outgong and demultplexng ncomng traffc. Ths addtonal layer n the packets path obvously ncurs an addtonal overhead. The I/O mechansm of the VMM conssts n copyng the packets to the shared memory between the drver doman and the vrtual machne. Ths costly mechansm s behnd ths addtonal overhead. Although there are compellng advantages behnd vrtualzng the cloud computng nfrastructure, there are stll performance ssues that need to be addressed before vrtualzng the data centers could be fully advantageous. Indeed, concurrent applcatons share equally the avalable bandwdth. Current VMMs only offer a statc allocaton of the bandwdth. In ths paper, we propose an SLA aware Dynamc Bandwdth Allocaton algorthm that dynamcally manages bandwdth allocaton among vrtual machnes accordng to ther prortes whle mnmzng physcal resources consumpton. The remander of ths paper s organzed as follows: Secton 2 descrbes the background of our work. We state the problem n secton 3 and ntroduce related work n secton 4. In secton 5 we detal the proposed soluton and ts expermental evaluaton. Fnally, secton 6 concludes the paper and ntroduces our future work. II. OVERVIEW AND BACKGROUND A. Cloud computng envronment Cloud computng refers to both the applcatons delvered as servces over the Internet and the hardware and systems software n the data centers that provde those servces[9]. Servces n the Cloud can be: Software (SaaS), Platform (PaaS), or Infrastructure (IaaS). The dstncton s made based on the level of abstracton presented to the clent and the level of management of resources. To better understand the performance lmtatons of a cloud computng nfrastructure, we frst need to understand how cloud platforms are desgned. A cloud platform s bascally composed of multple data centers wth a web portal, connected through a WAN. The data center s composed of multple physcal nodes connected through a LAN. Insde the data center, the nfrastructure can be

3 Fg. 1. Vrtualzed Cloud Platform Fg. 2. Packet transmsson n a Xen envronment vrtualzed (Fgure 1) n whch case each node supports multple solated vrtual machnes. These vrtual machnes share the same hardware and storage, and can be mgrated from one physcal machne to another n the same data center or even n a remote data center. In natve vrtualzaton technologes, vrtual machnes also share the access to the network devce, and the avalable bandwdth. Ths latter s equally allocated among the concurrent vrtual machnes. Dfferent applcatons (game server, meda server..) run over these vrtual machnes and users have drect access to those applcatons through the web portal. The user can ether have access to only the applcaton, or the the development platform or even the whole stack. B. Vrtualzaton technology Most deployed vrtualzaton technologes nclude Xen, VMWare, OpenVZ, and Lnux VServer. OpenVZ and LnuxVServer offer operatng system (OS) level vrtualzaton, where the OS supports multple solated user-space nstances called contaners. They share the same kernel. Xen and VMWare fall nto the full and para-vrtualzaton categores respectvely. In both categores, the Vrtual Machne Montor (VMM) presents software nterfaces to VMs. The man dfference between these two categores s that the guest OS must be ported n para-vrtualzaton and not n fullvrtualzaton. A VMM enables multple vrtual machnes to share the same physcal machne. The VMM must provde shared access to the network nterface and ensure solaton. Shared access s offered by a specal vrtual machne called I/O doman or drver doman (DD). Xen [2] s a popular open source VMM for the x86 archtecture that uses ths networkng model. Guests n a Xen envronments are called Unprvleged domans (DomU). One specal prvleged doman called Doman (Dom) s responsble for managng (creatng, mgratng, destroyng...) the other guest machnes. The drver doman s a dedcated doman (that can be ether one DomU or Dom tself) responsble of the shared access to devces especally the network devce. The drver doman s usually Dom tself. Xen offers a hgh level of solaton through ts memory sharng secure mechansm. The drver doman s responsble for protectng I/O access and s trusted to transfer traffc to the approprate vrtual machne. Moreover, hgh flexblty s also offered snce t s possble to customze data planes by modfyng the network stack n the kernel, whch s not possble n contaner-based vrtualzaton snce only the applcaton level s vrtualzed and all vrtual nstances share the same kernel. In our work, we wll use Xen as a vrtualzaton layer and Dom as the drver doman. In the text Dom and drver doman are used nterchangeably. C. Adopted Xen network I/O archtecture In ths secton, we wll detal networkng wth Xen. In addton to real devce drvers, vrtual drvers are mplemented n both Dom and the guest domans. A vrtual drver s splt nto the netback (n Dom) and the netfront (n each DomU). In each vrtual machne, the netfront corresponds to a vrtual nterface (vf) whch s characterzed by a transmsson bandwdth. All the vrtual nterfaces are connected to the brdge through the netback. The brdge demultplexes the ncomng traffc to the dfferent netbacks and multplexes the outgong traffc to the NIC. Inter-doman communcaton as well as communcaton between the hypervsor and the vrtual machnes s ensured by the event channel. It s a notfcaton mechansm that s partcularly used by the hypervsor to notfy Dom of the arrval of a packet, or by Dom to notfy the DomU destnaton that a packet was placed n ts memory space. Shared memory pages are used to really transfer the packet between domans. Network transmssons and receptons are acheved as llustrated by Fgure 2. In ths paper we are only nterested n traffc transmsson, we below detal packets transmsson path. Whenever a vrtual machne has a packet to transmt, t copes the packet to a memory page and ssues a grant through the VMM n order to nform the Dom that he s allowed to access that page. Then t sends a notfcaton to the Dom to nform hm that the packet has been coped to the memory page. When scheduled, the Dom wll se the notfcaton and handle t by accessng the memory page n order to get the packet. The Dom notfes then the vrtual machne and the packet s henceforth handled by the brdge, whch wll relay the packet to the NIC. As soon as the vrtual machne gets the notfcaton, t revokes the grant. Incomng packets wll bascally follow the opposte path.

4 III. RELATED WORK Over the last few years, a far number of research efforts has been dedcated to the enhancement of I/O vrtualzaton technology n the context of vrtualzed cloud envronments. In both [3] and [4], the authors conducted extensve measurements to evaluate the performance nterference among vrtual machnes runnng network I/O workloads that are ether CPU or network bound. They showed how dfferent resources schedulng and allocaton strateges and workloads may mpact the performance of a vrtualzed system. In [5] the authors proved that cache and memory archtecture, network archtecture and vrtualzaton overheads can be scalablty bottlenecks n a vrtualzed cloud, dependng on whether the applcaton s compute or memory or network I/O ntensve respectvely. None of these works proposed new technques to mprove I/O performance. [6] proposed several optmzatons to the memory sharng mechansm mplemented n Xen. They mproved the cache localty by movng the grant copy operaton from the drver doman to the guest. Besdes, they proposed to relax the memory solaton property to reduce the number of grant operatons performed. In ths case, performance would come at the cost of solaton, one of the most attractve benefts of the Xen archtecture. In [7], the author shows that the out-of-the-box network bandwdth to another host s only 71% and 45% of non-vrtualzed performance for transmt and receve workloads, respectvely. These bottlenecks are present even on a test system massvely over-provsoned n both memory and computaton resources. Smlar restrctons are also evdent n commercal clouds provded by Amazon, showng that even after much research effort I/O vrtualzaton bottlenecks stll challenge the desgners of modern systems. In[8], Kesavan and Al formalze the way n whch hypervsors support proportonal sharng for I/O requests, by developng and presentng the novel noton of Dfferental Vrtual Tme (DVT). A specfc techncal problem addressed by DVT and elaborated n ths paper s that n the case of proportonal sharng of network I/O, the presence of a conventonal I/O scheduler ntroduces an addtonal delay nto the network processng path. Moreover, the delay experenced by ndvdual VMs changes wth the number of other concurrently actve VMs and wth ther traffc patterns. In [1], the authors used the SLA approach to propose an archtecture for resources provsonng n the context of a vrtualzed cloud. The paper manly addresses ssues related to negotaton and brokerng for vrtual resources provson. However no practcal performance evaluaton has been conducted to show the effectveness of the soluton. Our contrbuton represents an enhancement of the networkng performance of vrtual machnes n the cloud. Ths enhancement takes nto consderaton the agreements set up between the customer and the provder. Experments show ts feasblty wth respect to the establshed agreement. IV. PROBLEM STATEMENT In a vrtualzed cloud, multple vrtual machnes are dedcated to dfferent types of applcatons whle sharng the same physcal machne and network devce. The sum of rates at whch the vrtual nterfaces transmt can not thus exceed the physcal NIC bandwdth. Some applcatons lke vdo streamng servers are requred to sustan an acceptable throughput so that the contract wth the customer could be respected. The vdeo server thus requres a bandwdth that may not be guaranteed n the presence of concurrent flows. Vrtual machnes share the avalable bandwdth equally. Then, nstantatng new vrtual machnes may compromse the QoS requred by already runnng applcatons. The natve system of Xen only offers a tool to statstcally set a cap on the bandwdth a vrtual machne can enjoy. The whole system need to be restarted after each reconfguraton. To encounter ths problem, we propose to ntegrate an SLA-based Dynamc Bandwdth Allocator (BDA) that wll be run n the drver doman to dynamcally adjust the transmsson bandwdth of each vrtual machne accordng to the establshed servce level agreements and the avalable bandwdth. Furthermore, n current VMM mplementatons, when one vrtual machne transmts at a rate exceedng the avalable bandwdth, the drver doman drops the packets (n the netback). Packets are then dropped after they have been transferred through the memory from the netfront to the netback. In [12], the authors have shown that the memory access s the bottleneck preventng the transmsson throughput from scalng up to lne rates. Indeed, the I/O mechansm of Xen nvolves much operatons ncludng grantng the memory page, revokng the grant, copyng the packet and notfyng the netback of the packet transfer. All of these operatons are shown to requre multple memory transactons and CPU cycles. In order to mnmze ths resource consumpton, we further propose to drop packets n the netfront (rather than the netback) whenever the packet s dedcated to be dropped due to bandwdth passng. Thus we elmnate unnecessary and costly packet copes and notfcatons between the netfront and the netback. A. Algorthm V. DBA: DYNAMIC BANDWIDTH ALLOCATOR We consder a vrtualzed system wth a drver doman and multple vrtual machnes hostng dfferent applcatons wth dfferent QoS requrements. Each vrtual machne transmts traffc through ts vrtual nterface (vf). Each vf s connected to the physcal nterface through the brdge. A vrtual machne s nstantated wth a set of characterstcs defned n the Servce Level Agreement (SLA) establshed between the customer and the provder. The SLA specfes the system physcal resources allocated to the vrtual machne and the networkng parameters. Physcal resources nclude CPU cycles and memory and networkng parameters nclude bandwdth, packets delay and jtter,etc. In order to guarantee an acceptable bandwdth to vrtual machnes hostng applcatons requrng QoS (for example: vdeo streamng servers), we propose a dfferentaton mechansm operatng at the drver doman that dynamcally readjusts transmsson bandwdth accordng to the SLAs. Ths mechansm classfes the dfferent vrtual nterfaces nto classes that are characterzed by a prorty and

5 by a maxmum and mnmum bandwdth. The am of the proposed mechansm s to guarantee to each vrtual machne a mnmum bandwdth at whch t can transmt and to prevent t from exceedng a cap bandwdth not to compromse the rest of the machnes QoS. We denote by: N the number of vrtual machnes. vf vrtual nterface, =1..N B p the physcal nterface maxmum bandwdth of the physcal nterface P. B the bandwdth at whch vf s transmttng, =1..N the maxmum bandwdth at whch vf s allowed to emt, set n the SLA. B mn the mnmum guaranteed bandwdth of vf, set n the SLA. Bp ex s the avalable physcal nterface bandwdth. C the class of vf. B max For each physcal nterface P, the DBA browses each vf attached to P startng wth the ones belongng to the hghest prorty class. The DBA measures B for each vf. In the case where multple vrtual nterfaces belong to the same class, the DBA wll start wth the frst created one. For each vf, f B s between B max B < B mn ), then no change s made. In the case where B exceeds B max and B mn (B > B max (B max < ) then B wll be readjusted to B max and the avalable bandwdth BP ex wll be augmented by the resultng dfference of B -B max BP ex Bex B B max ) P +(B - B max. Fnally n the case where B went below B mn then the DBA checks whether there stll s avalable bandwdth ( ) on the physcal nterface and whether (B - B mn ) < or not. If so, B mn dfference B mn s readjusted to B and BP ex - B. P Bex P - (Bmn - B ) B B mn s dmnshed by the If not, n the case where the current vrtual nterface belongs to the least mportant class, t readjusts the bandwdth of all the other vrtual nterfaces vf j, j=1..n belongng to the same class to Bj mn so that B could reach B mn. for ( j n 1..N ){ B j Bj mn BP ex Bex P +(B j - Bj mn ) } f (BP ex > Bmn ){ P Bex P - (Bmn B B mn } else{ B P P } - B ) In the case where there are other less prortzed classes C x, x=1..n, then the bandwdth of each vrtual nterface belongng to the class C x s also readjusted to the mnmum bandwdth of the class C x : Bx mn for ( x n 1..N ){ for (j n 1..N x ){ B j Bj mn BP ex Bex P +(B j - Bj mn )} f (BP ex > Bmn ){ BP ex Bex P - (Bmn B B mn } else{ B P P } startng wth the least prortzed class. - B ) Fnally f the remanng avalable bandwdth > then t wll be reallocated to the dfferent vrtual nterfaces based on ther prortes. B. Performance Evaluaton We have developed the proposed DBA as module that we ntegrated to the drver doman. It conssts of a daemon that perodcally executes the algorthm we descrbed, checks the rates at whch the dfferent vrtual nterfaces are transmttng and confgures them accordngly. Below we present the expermental evaluaton of our system. 1) Expermental setup: For our experments, we used a Dell PowerEdge 295 server, wth two Intel Quad-core CPUs wth a frequency of 249Mhz for each core. Pars of cores share the same L2 cache of 8MB, and all 8 cores share the same man DDR2 667Mhz memory. Networkng s handled by one ggabt card usng a PCI x4 channel. The e1 drver was used wth NAPI enabled. Xen 3.4. s used as a hypervsor. We developed the proposed mechansm wth language C, as a module that we ntegrated to the drver doman. The snk of the traffc s a Nec PC, wth a 24 Mhz core 2 duo processor and a DDR2 667Mhz memory also equpped wth one Ggabt card. For traffc emsson and recepton we used Clck [11]. We nstantated 3 vrtual machnes for traffc transmsson, allocated one core and 1GB of memory each. The Dom s allocated the rest of the cores and memory and s playng the role of drver doman. One UDP flow s generated wthn each vrtual machne. Packets sze s set to 15 bytes. Scenaro: We frst evaluated the throughput acheved by the 3 vrtual machnes wth the natve system wth the followng scenaro: Each vrtual machne belongs to a dfferent class.mv belongs to class C, =1..3. We set the mnmum bandwdth to 3 Mb/s, 1 Mb/s and Mb/s and the maxmum bandwdth to 6 Mb/s, 3 Mb/s and 1 Mb/s for C 1, C 2 and C 3 respectvely. The traffc generaton lasts for 3s and the transmsson rate s dstrbuted as follows: MV1 transmts at 8 Mb/s for the frst 1 s. Then at 2 Mb/s for the next 4 s. The nput rate s ncreased to 6 Mb/s for the next 3 s and decreased to 2 Mb/s durng the next 2 s. After that, MV1 transmts at 5 Mb/s durng 6 s and fnally at 8 Mb/s durng 5 s. However, both of MV2 and MV3 transmt at a constant bt rate of 8 Mb/s durng the whole test duraton. C. Expermental Results 1) System throughput: Fgures 3 and 4 show the throughput of the natve system and DBA-enhanced system respectvely

6 Rate (Mb/s) Class C1 Class C2 Class C3 CPU Cycles (MC/s) Natve System System wth DBA Tme (S) Readjustment Perod (ms) Rate (Mb/s) Class C1 Class C2 Class C3 Fg. 3. Natve System throughput Memory Transactons (MT/s) Fg. 5. CPU consumpton Natve System System wth DBA Tme (S) Readjustment Perod (ms) Fg. 4. System wth DBA throughput Fg. 6. Memory transactons gan for a readjustment perod of 1ms. Note that wth the natve system the bandwdth s globally equally shared between the three vrtual machnes. However, when three of the vrtual machnes transmt at the same rate, we can notce that MV1 acheves a slghtly better throughput (35 Mb/s aganst 3 Mb/s for MV2 and MV1). Ths s due to the fact that MV1 was the frst machne to be started whch allows t to be scheduled frst to execute jobs on the CPU. Furthermore, we note from fgure 3 that after dmnuton n the transmsson rate of one vrtual machne (MV1 after 1s), the remanng bandwdth s shared between the other two vrtual machnes. Globally, the packet loss for the C1 class traffc s about 55.87% wth the basc system. From fgure 4, wth the DBA-system we can notce frst that the most prortzed vrtual machne s allowed to transmt at only 6 Mb/s although ts generated traffc at 8 Mb/s. The DBA adjusted ts transmsson rate to B1 max (durng the frst 1s). A decrease n the MV1 from 6 Mb/s to 2 Mb/s nput rate ncurs an ncrease n MV2 and MV3 throughput to 5 and 2 Mb/s respectvely. Notce that although MV1 transmts at 2 Mb/s, MV2 and MV3 are prevented from enjoyng the totalty of the remanng bandwdth (8 Mb/s). In fact, snce the DBA adjusted the B 1 to B1 mn (3 Mb/s), MV2 and MV3 can only share the remanng 7 Mb/s. We can conclude then that globally our algorthm respects the agreements on the mnmum guaranteed bandwdth and the maxmum allowed bandwdth. Furthermore, the C1 class loss rate has dropped to 16.56% wth the DBA system (aganst 55.87% wth natve system). 2) Resources consumpton: Our mechansm drops packets emtted beyond the allocated bandwdth n the netfront before beng transferred to the netback. We expect then the system to consume less physcal resources (CPU cycles and memory transactons). We profled the resources (CPU cycles and memory transactons) usage usng Xenoprof [13] wth both the natve system and DBA system and determned the mpact of the readjustment perod on the system throughput and physcal resources usage. Fgure 5 llustrates total CPU usage as a functon of the readjustment perod sze. However, for memory transactons we only presented memory transactons acheved by the I/O part as a functon of the readjustment perod sze too. We notce that for a perod of less than 1 ms, our algorthm consumes much CPU, whch wll mpact the system throughput, note the hgh packet loss rate for ths perod n Fgure 7. For perods lastng more than 1 ms, our system CPU consumes as much CPU as the natve system. Nevertheless, our system reduces memory transactons acheved by the I/O part nvolvng transferrng the packets from the netfront to the netback. Note that for a perod of less than 1 ms, the system suffers from hgh packet loss rate. Packets are then dropped n the netfront whch elmnates memory transactons that would have been necessary to transfer packets to the netback. Globally, and even for perods longer than 1 ms, the DBA allows reducng necessary memory transactons. Fnally, we can conclude from fgure 7 that our DBA-system notably reduces packet loss rate for perods beyond 1ms. Note also that the packet loss rate of 16,6% for MV1 traffc s relatve to the scenaro we consdered, where MV1 transmts at rates hgher than ts maxmum allowed bandwdth set n the agreement. Our system then totally respects ths agreement whle reducng acheved memory transactons. Ths leads to an optmal resource allocaton among vrtual machnes and then hgher system scalablty [12]. VI. CONCLUSION Vrtualzed clouds are defntely a compellng technology for both users and provders. They offer flexble servce to the customer accordng to the pay-as-you-use model. Vrtualzaton allows provders to optmze hardware through resource sharng and reuse and thus reduce hardware and power costs.

7 Loss rate (%) Natve System System wth DBA Readjustment Perod (ms) Fg. 7. Packet loss rate In a vrtualzed data-center, several vrtual machnes share the same network devce. Access to the NIC s handled by the drver doman and bandwdth s statcally allocated to the dfferent vrtual machnes. In ths paper we have proposed and developed DBA, a dynamc bandwdth allocator for vrtual machnes. Vrtual machnes are classfed nto classes that are dfferentated by the requred bandwdth of transmtted flows. DBA guarantees to each vrtual machne to transmt at the requred bandwdth as agreed n the SLA. Remanng bandwdth s also shared between the concurrent vrtual machnes accordng to ther prortes. DBA updates the allocaton perodcally n order to react as fast as possble to traffc changes. Furthermore, t optmzes physcal resources usage (CPU and memory) through droppng packets beyond the allowed transmsson bandwdth at the vrtual machne nstead of the drver doman. Thus t prevents transferrng packets destned to be dropped through the I/O channel and then extra memory transactons and CPU cycles. Expermental evaluaton of our module shows that DBA ndeed respects the servce level agreements and consderably reduces the packet loss. We ntend next to extend our algorthm to establsh SLA based on flows classes rather than vrtual machnes classes. Furthermore, our proposal could be extended to defne classes accordng to multple QoS parameters lke packet delay and jtter n order to enable vrtualzed cloud totally respond to customers expectatons. [8] M. Kesavan, A. Gavrlovska and K. Schwan, Dfferental vrtual tme (DVT): rethnkng I/O servce dfferentaton for vrtual machnes, Proceedngs of the 1st ACM symposum on Cloud computng, 21 [9] M. Armbrust, A. Fox, R. Grffth, A.D Joseph, R. Katz, A. Konwnsk, G. Lee, D. Patterson, A. Rabkn, I. Stoca, A.Zahara, Above the Clouds: A Berkeley Vew of Cloud Computng, Techncal Report No. UCB/EECS , February 1, 29. [1] A. Kertesz, G. Kecskermet, and I. Brandc An SLA-based Resource Vrtualzaton Approach for On-demand Servce Provson, Internatonal Workshop on Vrtualzaton Technologes n Dstrbuted Computng, Jue 29, Barcelona, Span. [11] E. Kohler, R. Morrs, B. Chen, J. Jahnott, and M. F. Kasshoek, The clck modular router, ACM Transactons on Computer Systems, vol. 18, no. 3, pp , 2. [12] M. Bourguba, K. Haddadou, and G. Pujolle, A Contaner-based Fast Brdge for Vrtual Routers on Commodty Hardware, IEEE GlobeCom, 21, Mam, USA. [13] A. Menon, G. Janakraman, JR. Santos, and W. Zwaenepoel, Dagnosng performance overheads n the Xen vrtual machne envronment, VEE 25. REFERENCES [1] L. M.Vaquero, L. Rodero-Merno, J.Caceres, M.Lndner, A Break n the Clouds: Towards a Cloud Defnton, ACM SIGCOMM Communcaton Revew, vol 39, no. 1, Jan. 29, pp [2] P. Barham, B. Dragovc, K. Fraser, S. Hand, T. Harrs, A. Ho, R.Neugebauer, I.Pratt, and A. Warfeld, Xen and the art of vrtualzaton, 19th ACM Symposum on Operatng Systems Prncples, October 23. [3] P. Xng, L. Lng, M. Yduo, A. Menon, S. Rxner, A.L Cox, W. Zwaenepoel, Performance Measurements and Analyss of Network I/O applcatons n Vrtualzed Cloud, Internatonal Conference on Cloud Computng, 21. [4] P. Xng, L. Lng, M. Yduo, S. Svathanu, K. Younggynm, P. Calton, Understandng Performance Interference of I/O Workload n Vrtualzed Cloud Envronments. Internatonal Conference on Cloud Computng, 21. [5] M. Hasan Jamal, A. Qadeer, W. Mahmood, A. Waheed, J.J. Dng, Vrtual Machne Scalablty on Mult-Core Processors Based Servers for Cloud Computng Workloads, Internatonal Conference on Networkng, Archtecture and Storage, 29. [6] JR. Santos, Y. Turner, G. Janakraman, I. Pratt, Brdgng the gap between software and hardware technques for I/O vrtualzaton, USENIX Annual Techncal Conference, 28. [7] J. Shafer, I/O Vrtualzaton Bottlenecks n Cloud Computng Today, Workshop on I/O Vrtualzaton (WIOV 21), Pttsburgh, 21