The Load Balancing of Database Allocation in the Cloud

Transcription

1 , March 3-5, 23, Hong Kong The Load Balancng of Database Allocaton n the Cloud Yu-lung Lo and Mn-Shan La Abstract Each database host n the cloud platform often has to servce more than one database applcaton system. However, under the resource lmtatons of the host, evenly dstrbuted databases nto each host s an mportant ssue needed to be addressed. The database szes and the number of databases must be taken nto account for workload balancng among database hosts. If too many data or databases are gathered n only few database hosts, the data skew may occur and result n poor qualty of servce. Currently, how to evenly allocatng databases nto hosts has not been concerned yet. In ths research, we wll propose fve database allocaton algorthms for dstrbutng databases to hosts n the cloud platform. The equatons used to evaluate the devaton of database allocaton results are also provded n ths report. In our expermental study, one of proposed approach can perform very near optmal soluton. We hope that t wll help the practcal applcatons n the cloud platform. Index Terms cloud computng, database allocaton, load balancng, Best Ft Decreasng Strategy I. INTRODUCTION HE Cloud computng s an emergng busness soluton T and has brought to much attenton [7][2][8][9]. In the cloud platform, the Storage as a Servce (StaaS) s a busness model n whch a large company rents space n ther storage nfrastructure to a smaller company or ndvdual [2][24]. It can address the requrements of each software servce to dstrbute the storage space and all knds of the servce on the resource pool. Cloud storage servces allow users through the web-based applcatons at any place and any tme va Internet-connected devces for facltate the use of ts storage capabltes wthout the need for extra propretary storage system. The storage layer s the man core of the cloud storage, lke nfrastructure as a servce (IaaS) n cloud computng, whch s composed of varous types of storage devces dspersed n dfferent regons. In ths storage layer, ether DAS, FC SAN, SCSI or NAS of IP storage devces can be ntegrated by consoldaton system of storage vrtualzaton technology. Thus remote montorng and management for all devces can be performed n ths consoldaton system. Moreover, there must be collaboraton between dfferent storage devces, and provdes a sngle ntegrated servces. Due to a great dversty and large volume of data n the cloud, the databases are spread across a broad range of hosts to serve numerous of users and must have suffcent scalablty and management capabltes to face any specfc data needs n real tme. Therefore, several researches on how to effcently manage databases n cloud platform have been proposed [6][][][3][6]. Yu-Lung Lo and Mn-Shan La are wth the Department of Informaton management, Chaoyang Unversty of Technology, Wufong Dstrct, Tachung, 4349 Tawan. Phone: ext. 4274; fax: ; e-mal: yllo@cyut.edu.tw; s468@cyut.edu.tw. A database management system on the database server to serve a large number of users s qute resource consumpton, such as the demand on storage space and memory as well as the executng database engne for servce and management of the database. On the practcal applcaton, a host often serves more than one database applcaton systems concurrently. Accordngly, f too many of them share the lmted resources of a host, t may decrease the effcency of the applcaton systems. Therefore, how to allocate varous szes and the number of databases to every host evenly s one of most mportant ssues for ensurng the good performance n the cloud. However, t has not been dscussed untl now. In ths paper, we would lke to study the load balancng of database allocatons n the cloud by consderng both two factors of the varous szes of databases and the number of databases. The remanng of ths paper s organzed as follows: n secton 2, we revew the related works of data allocatons. Then, n secton 3, we propose fve algorthms for database allocaton n cloud platform. After that, we desgn experments to evaluate the effcences of proposed approaches n secton 4. Fnally, a concluson s gven n the last secton. II. RELATED WORKS Cloud nfrastructure conssts of global master nodes and local slave nodes. Databases are always allocated n slave nodes to serve as database hosts. A database host can serve more than one database and the applcaton systems concurrently. There stll has not any report to address the load balancng ssue for database hosts n the cloud platform. There s a smlar concept by Mackey et al [9] for storng small fles n HDFS effcently and mprovng the space utlzaton for metadata. HDFS stands for Hadoop archtecture conssts of a dstrbuted fle system [25]. We wll brefly ntroduce Mackey's approach n ths secton. Furthermore, snce the deas of Round-robn schedulng and the Best ft decreasng strategy wll be used n our proposed schemes, we would also lke to gve an ntroducton for them. A. Metadata Management for Small Fles n HDFS The Hadoop archtecture conssts of a Dstrbuted fle system (HDFS) and a programmng framework MapReduce [2]. It s formed wth a metadata server called the Name node and a large number of I/O nodes called Data nodes, such that a sngle Name node keeps metadata of all fles on dfferent Data nodes as shown n Fgure [9]. In conventonal mult-user envronments, users are gven quotas to access and use such that the HDFS provdes for a mechansm to put quotas on user drectores. In Hadoop s mplementaton, cluster admnstrators are gven two optons for applyng user quotas; ) maxmum number of fles per drectory 2) maxmum fle space for a user drectory. Mackey et al dscuss ther work on these optons [9]. Fgure 2 shows two cases where an

2 , March 3-5, 23, Hong Kong ncomng request may exceed the quota lmtatons. Assumng the user quota for number of fles s seven and storage s 7GB. N shows the current number of fles and S shows the current storage capacty. User 2 n the fgure has reached the lmt on the number of fles, although the space quota s stll under utlzaton. User n has reached the space lmt, but the number of fles s under utlzaton. In both cases, users wll not be allowed to proceed wth the MapReduce job because of the nablty to create new fles n the respectve drectory [9]. C. Best Ft Decreasng Strategy Best ft decreasng strategy s often used to solve the bn packng problem and look for the near optmal soluton [4][5]. In the problem, objects of dfferent volumes (szes) must be packed nto a fnte number of bns wth lmted capacty each n a way that mnmzes the number of bns used. In another smlar problem that the objects dstrbuted nto all the bns are most evenly. By best ft decreasng strategy, the objects are frst sorted nto decreasng order accordng to szes. In the each teraton, the current largest object s assgned to the bn whch currently owns the smallest volumes of packs assgned. Ths process s repeated untl all the objects have been assgned as shown n Fgure 4. In the fgure, P and P 2 could be bns, and B, B 2,..., B 8 could be packages n decreasng order accordng to sze. Ths scheme s also used n many research felds such as data processng and data allocatons [8][][2]. Fgure. Hadoop fle system [9] Fgure 4. Best Ft Decreasng Strategy III. LOAD BALANCING FOR DATABASE ALLOCATIONS Fgure 2. An ncomng request May be exceedng number of fles quota or storage quota [9] B. Round-Robn Schedulng Round-robn schedulng [4] s a smple algorthm desgned especally for tme-sharng systems for arrangng processes n an operatng system n whch all runnable processes are kept n a crcular queue as shown n Fgure 3. The CPU scheduler goes around ths queue and allocates the CPU to each process for a tme nterval of tme slces wthout prorty. It provdes a complete farness among the processes. Round-robn algorthm has been wdely used n many schedulng approaches [5][3][23]. A database host often serves a number of database management systems. If too many of databases share the lmted resources of a host concurrently, t may decrease the effcency of the applcaton systems. Therefore, evenly desgnatng varous szes and the number of databases to every host can ensure the effcences of applcaton systems n the cloud. In ths secton, we desgn fve allocaton algorthms for allocatng databases to the hosts. The volumes of data and the number of databases are taken nto account for load balancng the allocatons. Suppose that all the databases have been sorted n decreasng order accordng to ther szes and wll be allocated nto hosts n ths sequence. A. Round-Robn Allocaton Round-robn allocaton uses the dea of Round-Robn schedulng to allocate databases n round robn fashon as shown n Fgure 5. In the fgure, D, D 2,..., and etc. denote the databases n decreasng order of szes, and are perodcally allocated to hosts N to N 5. Ths allocaton scheme can guarantee to desgnate the number of databases to every host n an optmal dstrbuton. Nevertheless, t cannot ensure the volumes of data n every host beng evenly. Fgure 3. Round-robn schedulng [23]

3 , March 3-5, 23, Hong Kong B. Z-Dstrbuton Fgure 5. Round-Robn Allocaton Z-Dstrbuton modfes the Round-robn allocaton to allocate databases nto hosts n a Z lke manner. In ths approach, databases are sequentally desgnated to hosts from N to N5 n odd teratons and to hosts from N5 to N n even teratons, as shown n Fgure 6. Ths scheme lke Round-robn allocaton can well dstrbute the number of databases to host. In addton, t can dstrbute the volumes of data to every host more evenly than Round-robn allocaton. E. Quantty Rato Allocaton Quantty Rato Allocaton tres to desgnate the databases wth the smallest volumes of data together wth the largest volumes of data to a same host. Snce databases are sorted n decreasng order, a host allocated a few number of databases but large volumes of data should delay the desgnaton and wat for the smaller ones. The Equaton () s desgned for evaluatng the Quantty Rato (QR ) for the host, where NDB avg and DB avg denote the average number of databases and the average data volume respectvely whch each host can be allocated, NDB and DB denote the number of databases and the data volume respectvely already allocated n the th host concurrently. The next desgnaton of database wll go for the host wth the hghest value of quantty rato. We also note that the lmted number of databases for each host can also be appled n ths approach to evenly desgnate the number of databases to hosts. QR DB DB avg = () NDBavg NDB Let's gve an example for llustraton. Suppose that the known average number of databases (NDB avg ) s and average data volume s 5GB. If host A has already been allocated one database wth data volume of GB, ts quantty rato wll be 5.6 (5/9=). If the other host B has already been allocated fve databases wth total data volume of 9GB, ts quantty rato wll be 2 (6/5=). Snce host B has the hgher quantty rato, the next database wll be desgnated to host B. The host A wll be delayed and wat for allocatng smaller databases. Fgure 6. Z-dstrbuton C. Best Ft Decreasng Strategy wth Sze Frst Best ft decreasng strategy wth sze frst uses the Best ft decreasng strategy [5] to allocate databases nto hosts wth consderng the szes of databases only. The desgnaton of ths scheme s smlar to that of the Fgure 4. Ths allocaton method emphaszes that t tres to evenly dstrbutng the volumes of data nstead of the number of databases to each hosts. D. Best Ft Decreasng Strategy wth Lmted Number of Databases Best ft decreasng strategy wth lmted number of databases also use the Best ft decreasng strategy to allocate databases nto hosts addtonal the number of databases s lmted n each host. When the number of databases allocated reaches the lmtaton of a host, the host won't be assgned database agan and the database s allocated to the next host wth smallest volume of data. In ths approach, we specfy the average number of databases (each host assgned f evenly dstrbuted) for the lmted number of databases for each host. Therefore, we can evenly allocate the number of databases to hosts lke n Round-robn allocaton and Z-dstrbuton. However, the load balance of volume of data for each host may not as good as Best ft decreasng strategy wth sze frst. IV. PERFORMANCE STUDY In order to evaluate the performances of our proposed database allocaton schemes, a seres of experments are performed n ths secton. A. Expermental Model We frst desgn followng 3 equatons to evaluate how balance of our fve allocaton approaches. D N sze = NoOfDBs DR = n = n = D D DB DB = sze total avg NDB NDB 2 N + N NoOfDBs total 2 avg (2) (3) (4) In Equaton (2), D sze denotes the total sze of devaton whch accumulates the dfference between the deally average data volume should be allocated and the actually data s allocated to each host. Where n s the total number of databases, DB s the data volume allocated n the th host and DB avg s the deally average data volume should be allocated to every host. In Equaton (3), N NoOfDBs denotes the total number of database devaton whch gathers the dfference between deally average number of databases should be allocated and the actually number of databases are allocated to each host. Where n s the total number of databases, NDB s the number

4 , March 3-5, 23, Hong Kong of databases allocated n the th host and NDB avg s the deally average number of databases should be allocated to every host. In Equaton (4), DR denotes the normalzed Devaton Rato whch looks devaton ratos of sze (D sze / D total ) and of the number of databases (N NoOfDBs / N total ) as an coordnate n two dmensonal space and computes the dstance to the orgn (, ). Where D total s the total sze (volume) of all databases and N total s the total number of databases beng allocated. We normalze the D sze and N NoOfDBs to the ratos of (D sze / D total ) and (N NoOfDBs / N total ), respectvely, n whch ther values are between and such that no one wll overly domnate the DR value f D zse or N NoOfDBs s too vast. The parameters of our experment are presented n Table. Suppose that the database szes are not unformly dstrbuted. The szes of databases are vared and can be determned by the Zpf-lke dstrbuton as shown s Equaton (5) [7][22]. In ths equaton, B s the sze of the th database, R s the total data volume of all databases, Z b s the database skew, and b s the total number of databases. We note that when Z b =, the equaton becomes a Zpf dstrbuton, and when Z b =, t s a unform dstrbuton. The sze dstrbutons for databases when Z b equals to,.5, and. are shown n Fgure 7. In addton, Szes of the largest database and the smallest database for Z b vared from. to. are presented n Table 2. If Z b =, the largest and smallest databases consst of 3.36TB and.3tb data respectvely. Furthermore, databases are sorted n decreasng order accordng to ther szes before allocated to hosts. Parameter Table. expermental parameters settng Hosts (n) Number of databases (b) Total data volume ( R ) TB Database skew (Z b ).~. B = b R j j= (5) =. =.5 =. Table 2. The szes of largest and smallest DBs for varous Z b Z b Largest DB (TB) Smallest DB(TB) For easer dscusson and labelng, Best Ft Decreasng Strategy wth Sze Frst and Best Ft Decreasng Strategy wth Lmted Number of Databases Allocatons wll be shorten as BestFt_Sze and BestFt_NDB, respectvely, n ths secton. The expermental results are shown n the followng subsectons. Our expermentaton conssts of fve parts: () Analyss of database sze devaton () Analyss of the number of database devaton () Analyss of devaton rato (v) Analyss of Scalablty (v) Optmalty study B. Analyss of database sze devaton In ths study, the database sze devatons after databases allocated n hosts are nvestgated. The Equaton (2) s used for computng the total sze of devaton whch accumulates the dfference between the deally average data volume should be allocated and the actually data s allocated to each host. The expermental result s shown n Fgure 8. There s no doubt that the database sze devatons of all allocaton approaches are ncreasng as rsng the database skew from. to.. It's due to the hgher database skew the more dffculty to dstrbute databases to each host evenly. In the fgure, the Quantty Rato allocaton can most evenly allocate databases to hosts when database skew s mnor such as Z b <=.4. However, the BestFt_Sze outperforms all other allocaton schemes f Z b >=.5. That's because ths study consders the database szes as the only nfluence factor and BestFt_Sze allocaton only focuses on balancng the data volume to every host. Snce the Round-robn allocaton consders evenly dstrbutng the number of databases to all the hosts only and gnores the effect of data volume dstrbutons, t performs the worst n ths study GB TB BestFt_Sze BestFt_NDB Round-Robn Z-Dstrbuton Database IDs Fgure 7. DB szes n Zp-lke dstrbutons Fgure 8. Analyss of database sze devaton

5 , March 3-5, 23, Hong Kong C. Analyss of the number of database devaton In ths secton, we examne the number of database devaton. The Equaton (3) s used for calculatng the total number of database devaton whch gathers the dfference between the deally the average number of databases should be allocated and the actually number of databases are allocated to each host. The expermental result s shown n Fgure 9. In the fgure, all approaches can perfectly allocate the even number of databases to every host except BestFt_Sze. To evenly dstrbute the number of databases to all hosts s not taken nto account by BestFt_Sze allocaton. Therefore, the number of database devaton for BestFt_Sze grows up as ncreasng the database skew. No. of DBs BestFt_Sze BestFt_NDB Round-Robn Z-Dstrbuton Fgure 9. Analyss of the number of database devaton D. Analyss of Devaton Rato Snce the studes of prevous two sectons consdered ether database sze devaton or the number of database devaton only, both of them wll be taken nto account smultaneously n ths secton. To prevent any one of these two devaton factors over domnatng the expermental results, they are normalzed to desgn the total devaton rato calculated by Equaton (5). We use ths equaton to analyze the devaton ratos of fve approaches. The expermental result s presented n Fgure. We can fnd that Quantty rato allocaton performs best n fve schemes. The BestFt_NDB almost acts as good as Quantty rato allacton when Z b >=.7. Nevertheless, the BestFt_NDB performs worse than Quantty rato allocaton and stands n the second best f Z b <.7. We also note that Round-robn allocaton whch consders evenly dstrbutng the number of databases only almost performs the worst except when Z b =. In addton, the Bestft_Sze s very senstve to database skew when ncreasng the skew the devaton ratos of BestFt_Sze grows most rapdly and becomes the worst when Z b =. DR BestFt_Sze BestFt_NDB Round-Robn Z-Dstrbuton E. Analyss of Scalablty The scalablty of our fve allocaton approaches are examned n ths secton. In ths study, the total number of databases s vared from 5 to 3. The total data volume and the number of hosts are stll fxed for TB and, respectvely. The database skew (Z b ) s fxed at.5. The devaton rato by Equaton (4) s used to evaluate the performances of allocaton schemes. The expermental result s shown n Fgure. All the devaton ratos of fve approaches are decreased as we ncreasng the number of databases. It s due to that more number of databases, whch mples smaller data volume for every database, s more easly to balance the database allocatons. Moreover, the Quantty rato allocaton stll outperforms the other four approaches. It benefted greatly by larger number of databases. DR BestFt_Sze BestFt_NDB Round-Robn Z-Dstrbuton No. of DBs Fgure. Analyss of scalablty F. Optmalty study By devaton rato analyss, the Quantty rato allocaton s the best approach for database allocaton. In ths secton, we would lke to nvestgate Quantty rato allocaton comparng to optmal soluton for devaton rato to fnd how well Quantty rato allocaton already be. We defne that the database allocaton wth the smallest devaton rato s the optmal soluton. However, to fnd optmal soluton for smallest devaton rato, there are databases and hosts n our experment whch lke the bn packng problem s an NP hard problem [4] and can result n combnatons of possble database allocatons. It s mpossble to be done n our PC devces. Therefore, we narrow down the expermental scale to 2 databases and 4 hosts whch stll has 4 2 (over one trllon) combnatons of possble database allocatons. The total data volume s also decreased to TB. We look for the smallest devaton rato for the optmal soluton from all the possble combnatons and compare wth Quantty rato allocaton. The expermental result s presented n Fgure 2. We are glad that the devaton ratos for Quantty rato allocaton and optmal soluton are very close. It means that Quantty rato allocaton perform very well and s near optmal soluton. Although ths study s only for small scale expermental envronment, we optmstcally expect that t stll can perform well n real practcal applcatons Fgure. Analyss of devaton rato

6 , March 3-5, 23, Hong Kong DR Optmal Fgure 2. Quantty rato vs. optmal soluton V. CONCLUSION Storage as a Servces (StaaS) s one of the mportant servces n Cloud platform. All the essental applcatons and database servces are gathered here. In ths Cloud platform, databases are dspersed across a broad range of hosts to servce numerous users. A database management system whch needs storage space for data and memory for database engne runnng s qute resource consumpton. On the practcal applcaton, a host often serves more than one database applcaton systems concurrently. Therefore, balance allocated databases to every host can ensure the effcency of each applcaton system. In ths paper, we proposed fve database allocaton schemes n whch both data volume and the number of databases are taken nto account. A devaton rato, whch s derved by normalzed data sze devaton and the number of databases devaton, s desgned for evaluatng the degree of evenly dstrbuted databases. Our expermental results pont out that the Quantty rato allocaton approach has the best performance and s very close to the smallest devaton rato of optmal soluton. Besdes, f evenly dstrbuted data volume to each host s most concerned, the Best Ft Decreasng Strategy wth Sze Frst approach (BestFt_Sze) can perform t well. In addton, f the lmtaton of CPU power and memory s serous to care for, all proposed approaches, except BestFt_Sze, can evenly allocate the number of databases to each host. REFERENCES [] S.A. Cook, The Complexty of Theorem Provng Procedures, In proceedngs of 3rd Annual ACM Symposum on the Theory of Computng, New York: ACM. 97: [2] J. Dean and S. Ghemawat, MapReduce: Smplfed Data Processng on Large Clusters, In Proceedngs of the 6th Symposum on Operatng System Desgn and Implementaton (OSDI 4), Usenx Assoc., pages 37 5, 24. [3] D.J. DeWtt, J. Gray, Parallel Database Systems: The Future of Hgh Performance Database Systems, Comm. ACM 35 (6), 85-98, 992. [4] M.R. Garey and D.S. Johnson, Computers and Intractablty: A Gude to the Theory of NP Completeness, Freeman, San Francsco, 979. [5] D.S. Johnson, Near-optmal bn packng algorthms, Ph.D. Thess, MIT, Cambrdge, MA, 973. [6] J.L. Johnson, SQL n the Clouds, Computng n Scence and Engneerng, pp. 2-28, July/August, 29. [7] Y. Kakuda, H. Yuktomo, S. Kusumoto, and T. Kkuno, "Scentfc Computng n the Cloud, " IEEE Desgn & Test, Vol. 2, Issue 3, IEEE Computer Socety Press, pp , May 2. [8] M. Ktsuregawa and Y. Ogawa. Bucket spreadng parallel hash: A new, robust, parallel hash jon method for data skew n the super database computer (SDC), In Proc. of 6th Int l Conf. on VLDB, pages 2-22, Brsbane, Australa, August 99. [9] G. Mackey, S. Sehrsh and J. Wang, "Improvng metadata management for small fles n HDFS," CLUSTER 9. IEEE Internatonal Conference on Cluster Computng and Workshops, September, 29. [] V. Mateljan, D. Csc, and D. Ogrzovc, Cloud Database-as-a-Servce (DaaS) ROI, proceedngs of the 33rd Internatonal Conventon MIPRO, pp , May 2. [] Z. Man and Z. Nong, The Study of Multmeda Data Model Technology Based on Cloud Computng, The 2nd Internatonal Conference on Sgnal Processng Systems (ICSPS), pp. V3-743-V3-746, July 2. [2] A. Mchael, F. Armando, G. Rean, A. D. Joseph, K. Randy, K. Andy, L. Gunho, P. Davd, R. Arel, S. Ion, and Z. Mate, A Vew of Cloud Computng, Communcatons of the ACM, Vol.53, No. 4, pp. 5-58, 2. [3] J. Rogers,O. Papaemmanoul, and U. Cetntemel, "A Generc Auto-Provsonng Framework for Cloud Databases," IEEE 26th Internatonal Conference on Data Engneerng Workshops (ICDEW), pp , 2. [4] A. Slberschatz, P. B. Galvn, and G. Gagne, " Process Schedulng," Operatng System Concepts, John Wley & Sons, Inc., 8th edton. pp. 94, 2. [5] T. Stöhr, H. Märtens, E. Rahm, Mult-Dmensonal Database Allocaton for Parallel Data Warehouses, Proc. 26th VLDB Conference, Caro, Egypt, Sep. 2. [6] N.E. Taylor and Z.G. Ives, Relable Storage and Queryng for Collaboratve Data Sharng Systems, IEEE 26th Internatonal Conference on Data Engneerng (ICDE), pp. 4-5, 2. [7] C. Turbyfll. Comparatve Benchmark of Relatonal Database System,. PhD thess, Cornell Unversty, September 987. [8] M.A. Vouk, Cloud Computng- Issues, Research and Implementatons, the 3th Internatonal Conference on Informaton Technology Interfaces, pp. 3-4, June 23-26, 28. [9] E. Walker, W. Brsken, and J. Romney, To Lease or Not to Lease from Storage Clouds, Computer, Vol. 43, Issue 4, IEEE Computer Socety Press, pp. 6-9, Aprl 2. [2] J.L. Wolf, D.M. Das, P.S. Yu, and J. Turek, Comparatve performance of parallel jon algorthms, In Proc. of Int l Conf. on Parallel and Dstrbuted Informaton Systems, pages 78-88, Mam, Florda, December 99. [2] S. Zhang, S. Zhang, X. Chen, and X. Huo, Cloud Computng Research and Development Trend, the 2nd Internatonal Conference on Future Networks, pp , Jan. 2. [22] G.K. Zpf, Human Behavor and the Prncple of Least Effort: An Introducton to Human Ecology, Addson-Welsey, Readng, MA [23] Y.F., Zheng, C., Shao, An effcent round-robn algorthm for combned nput-crosspont-queued swtches, In: Dn P, ed. Proc. of the IEEE ICAS/ICNS, Papeete: IEEE Computer Socety, pp , 25. [24] Gartner Says Cloud Computng Wll Be as Influental as E-busness, October 29, [25] The Hadoop archtecture,