A storage policy for a hybrid federated cloudplatform: a case study for bioinformatics

Deric Lima, Breno Moura, Gabriel Oliveira, Edward Ribeiro, Aleteia Araujo,Maristela Holanda, Roberto Togawa and Maria Emilia Walter

Abstract—Bioinformatics tools require large-scale processing mainly due to very large databases achieving gigabytes ofsize. In federated cloud environments, although services and resources may be shared, storage is particularly difficult, dueto distinct computational capabilities and data management policies of several separated clouds. In this work, we proposea storage policy for BioNimbuZ, a hybrid federated cloud platform designed to execute bioinformatics applications. Ourstorage policy, BioClouZ, aims to perform efficient choices to distribute and replicate files to the best available cloudresources in the federation in order to reduce computational time. BioClouZ uses four parameters - latency, uptime, freesize and cost, weighted (according to ad hoc tests) to model their influences to data storage and recovery. Experimentswere performed with real biological data executing a commonly used tool to map short reads in a reference genome inBioNimbuZ, composed of clouds executing in Amazon EC2, Azure and University of Brasilia. The results showed that,when compared to the greedy algorithm first used in BioNimbuZ, the BioClouZ policy significantly improved the totalexecution time due to more efficient choices of the clouds to store the files. Other bioinformatics applications can be usedwith BioClouZ in BioNimbuZ as well, since the platform was designed independently from particular tools and databases.

Keywords—storage policy, hybrid federated cloud platform, bioinformatics.

�

1 INTRODUCTION

ADVANCES in genome sequencing tech-niques allowed to generate enormous vol-

umes of genomic sequences. These sequencesare stored in files (databases) that have to beanalyzed using bioinformatics tools requiringsignificant computational resources. In this sce-nario, cloud computing can improve executionof bioinformatics applications in an efficientand collaborative way. Many specific bioinfor-matics applications executing in single cloudenvironments have been presented in the lit-erature [1], [2], [3], [4], [5], [6], [7].

In 2012, our group proposed BioNimbus [8],a hybrid federated cloud architecture to exe-cute bioinformatics workflows. BioNimbus wasdesigned to provide functionalities that allow

• D. Lima, B. Moura, G. Oliveira, E. Ribeiro, A. Araujo,M. Holanda and M. E. Walter are with the Department ofComputer Science, University of Brasilia, Brasilia, Brazil.E-mails: {dericlima, mourabreno, gabriel 222zt, edward.ribeiro}@gmail.com, {aleteia, mholanda, mia}@cic.unb.br

• R. Togawa is with the Bioinformatics Laboratory of EMBRAPA/Genetic Resources and Biotechnology, Brasilia, Brasil. E-mail:roberto.togawa@embrapa.br.

Manuscript sent February 28, 2014

to join clouds belonging to different organiza-tions and having different policies, shared in aconsistent and controlled way. A first prototypewas constructed, and one workflow using realgenomic data was executed in the platform. Theexperiments showed that the time to executethis workflow in BioNimbus was improvedwhen compared to its execution in one machinewith big storage and processing resources.

BioNimbus platform was implemented usinga simple greedy storage policy, the first cloudpresenting enough space was chosen to storefiles. In the tests, this policy frequently gen-erated a time overhead, since storing one fileF in a cloud not chosen by the scheduler toexecute a task T using F implied in a secondtransfer of F to the cloud actually executingT . In other words, a cloud executing one taskusing files stored in another cloud implied inextra time to transfer these input files, beforeactually start running. This strongly affectedthe total time, since files containing genomicdata usually have gigabytes of size.

In this context, this work aims to propose anovel storage policy to BioNimbus, in order to

2014 14th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing

978-1-4799-2784-5/14 $31.00 © 2014 IEEE

DOI 10.1109/CCGrid.2014.102

738

perform an efficient choice to distribute filesand reduce the total execution time, consid-ering free storage space and charge of eachcloud as well as network latency and time thata machine remains working (called uptime) inthe federation. Therefore, the proposed storagepolicy, called BioClouZ, is based on four pa-rameters - free space, cost, latency and uptime,weighted according to their influences to datastorage and recovery. Ad-hoc tests and resultsfrom the literature were used to define theseweights.

To implement BioClouZ, a coordination ser-vice was included in BioNimbus, and thecommunication service among the federatedclouds was changed. BioNimbus architecturewas completely reimplemented, which led to asecond version, called BioNimbuZ, a more scal-able, dynamic and easy to program platform,using Zookeeper [9] and Avro [10].

2 BIONIMBUZ PLATFORM

IN this section, we first describe the BioN-imbus architecture [8]. After, we show how

Zookeeper [9] and Avro [10] were used togenerate the BioNimbuZ platform.

2.1 BioNimbus architectureThe BioNimbus architecture [8] is structuredin three layers: application, core and infras-tructure (see Figure 1). All the componentsand respective functions are clearly definedand separated, allowing simple and efficientinclusion of new clouds, transparently to users.

The infrastructure layer includes plugins, usedto map the communication among the feder-ated clouds and the core layer management ser-vices, which offer computational resources, e.g.,virtual machines, data storage and networks.The application layer is the communication in-terface between BioNimbus and users.

The core layer was designed to provide ser-vices that integrate the clouds belonging to thefederation. The job controller connects the coreand the application layers, being responsible formanaging the requests of one user and thecurrent status of the execution of these requests,which can be consulted at any time. It also

Fig. 1. BioNimbus federated cloud architecture.

controls users’ access rights, using the securityservice to verify his/her credentials.

The monitoring service manages the status ofeach cloud, i.e., it notifies all the federatedclouds when a cloud enters or leaves the feder-ation. This service is also responsible to warrantthe execution of the requested tasks.

The security service guarantees integrationamong the clouds in a secure way, throughaccess rules, which have to be carried out ac-cording to the policies and requirements of eachfederated cloud. It also assures a secure com-munication among users and service providers,and offers access control policies for a cloudentering in the federation.

The discovery service finds the clouds integrat-ing the federation, and consolidates informa-tion about their storage, processing and transfercapabilities, and also the offered bioinformaticstools, together with details of execution param-eters and input/output files.

The storage service manages the files usedin the bioinformatics applications, as well asrecovers and controls data transferring.

The scheduling service coordinates task execu-tion, using efficient scheduling policies to dis-tribute these tasks among the federated clouds.

The fault tolerance service guarantees that allthe control services in the core layer are avail-able. For this, it registers each of the managingservices, monitoring them with messages sentin short intervals. When a service does not

739

answer after a fixed time, the fault toleranceservice initiates an election algorithm to definewhich server has to initiate another instance ofthe failed service. When this process finishes,all the clouds are warned about the new choice.

A Service-Level Agreement (SLA) controleris a formal contract between service providersand clients to guarantee Quality-of-Service (QoS)to the users [11]. In BioNimbus, the SLA con-troler is responsible for implementing the SLAlife cycle, in six steps: service provider dis-covery; SLA definition; agreement establish-ment; agreement monitoring violation; contractfinishing; and imposing of penalties due toagreement violation. To identify agreement pa-rameters, SLA templates are used, representing,among others, QoS parameters negotiated be-tween the user and the BioNimbus architecture.

2.2 BioNimbuZ: a new implementationNow, we show the way Zookeper and Avrowere used to create the BioNimbuZ platform.

ZooKeeperBuilding distributed services is often complexand error-prone, e.g., controlling conditionsof executions and treating deadlocks. ApacheZooKeeper [9] is an open source service thatfacilitates to develop distributed applications,being responsible for the implementation ofcoordination services. It provides a simple setof primitives designed to implement high levelservices. e.g., synchronization, maintenance,configuration and group processing.

ZooKeeper stores, among others, data coor-dination, status information, setting and loca-tion information, using znodes, data structuressimilar to directories. An Access Control List(ACL) is associated to each znode, restrictingwho can read/write it. ZooKeeper has also theconcept of ephemeral znode, which exists whilethe session creating it is active, being deletedwhen this session is not active any more. Eachsession corresponds to a connected client.

Another important concept in ZooKeeper isthe watcher, a notice event. A watcher is trig-gered and removed when changes occur inthe corresponding znode. When a watcher istriggered, the client receives a message noticing

that its znode has been changed. If the con-nection between the client and one ZooKeeperserver is interrupted, the client receives a mes-sage stating that the server has crashed. Watch-ers and znodes can be defined by each server.

AvroApache Avro [10] is a system of data seri-alization and RPC (Remote Procedure Call).The main features of this system are: rich datastructure described by schemes; binary data ina compact and fast format; a file container tostore persistent data; use of RPC; and simpleintegration with dynamic languages, i.e., it isnot necessary to code for reading and writingfiles nor to use and implement RPC protocols.

Avro data is stored in a file together withits scheme, being Avro data read together withits corresponding scheme. This makes data se-rialization efficient and easy, since data andcorresponding schemes are self-explanatory, fa-cilitating the use of dynamic script languages.

In RPC, client and server exchange dataschemes to make a connection. Since clientand server have the schemes one of the other,correspondance between the same fields areeasily solved. Avro schemes are defined withJSON [12], which facilitates the implementationin languages also presenting JSON libraries.

BioNimbuZ platformUsing Avro and Zookeper, we modified thefirst prototype of the BioNimbus architectureproposed in Saldanha et al. [8], in order to havea more scalable, dynamic, and easy to manageplatform, called BioNimbuZ. In particular, itscommunication and coordination mechanismswere completely modified.

The communication mechanism in the firstBioNimbus platform was implemented throughP2P messaging [13], being its control dis-tributed among each federated cloud. The dis-covery service (for clouds belonging to thefederation and their respective resources) wasalso implemented through this P2P network.In contrast, in the new version, communicationamong the federated clouds has been replacedby RPC Avro [10]. While with P2P, a broadcastwas needed (e.g., to find out the clouds inte-grating the federation), with RPC, a message

740

is sent directly to the destination cloud. Thus,Avro allowed to provide a simpler and morerobust communication interface.

Besides, when a cloud enters in the feder-ation, a znode is created with its information,and consulting or updating this cloud informa-tion can be easily done with ZooKeeper [9].This allows to control the federated cloudsin a decentralized way. Thus, coordination inBioNimbuZ was implemented using znodes (seeFigure 2), which contain the service modules.

Fig. 2. Structure of the znodes in BioNimbuZ.

Therefore, when a new cloud C enters in thefederation, one STATUS znode is created to storeits available resources. This ephemeral znode ex-ists until C loses its connection, which indicatesto Zookeeper that C left the federation. A cloudrunning a BioNimbuZ instance, registered in aznode, is called BioNimbuZ server.

3 BIOCLOUZ STORAGE POLICY

THE first prototype of the BioNimbus archi-tecture [8] had a very simple greedy stor-

age policy, as said before. Our novel BioClouZpolicy uses information from one ZooKeeperznode to compute a storage value for eachcloud.

In the experiments developed with the firstBioNimbus prototype, we noted that a bioin-formatics application ran efficiently if the inputfiles were already stored in the cloud chosento execute it [8]. Therefore, a policy warrantingthat the input files of one application are storedin the cloud chosen to perform the task, or nearit, would certainly improve performance. Weintended to model this in the BioClouZ policy.

BioClouZ controls how data is stored, deletedand replicated in BioNimbuZ. To control storeddata, BioClouZ uses the ZooKeeper znodes.Each BioNimbuZ server entering in the feder-ation receives an unique identifier (ID), beinga znode created with this ID, together withthe STATUS znode, which sends to the moni-toring service the resource information of thisBioNimbuZ server. When a BioNimbuZ serverleaves the federation, the STATUS znode ischanged to STATUS WAITING, which asks themonitoring service to immediately initiate thefault tolerance service for this server.

A set of children znodes models the filesbelonging to one BioNimbuZ server. For eachfile, a znode is created with its information(ID, name, size and a pluginlist). The pluginlistis a list of all the BioNimbuZ servers storingthis file, since the storage service automaticallyreplicates all data stored in the federation. Thisprocess is detailed in Section 3.2.

Besides, a pending save znode is created withthe information of each file stored in the fed-eration, being all the BioNimbuZ servers no-ticed about these files (see Figure 2). This pend-ing save znode is deleted only when the file isproperly stored in one BioNimbuZ server.

The idea of the BioClouZ storage policy is tocompute a storage value for each BioNimbuZserver and, based on these values, choose theservers with the lower values to store andreplicate the files to be stored in BioNimbuZ.This computation is shown next.

3.1 Storage valueA storage value is computed for each file savedor replicated in the BioNimbuZ federation.This computation uses information between theclient who requested the task and each BioNim-buZ server with enough disk space to store thefile, transparently to the user. Three variablesare used to compute the storage value for oneBioNimbuZ server:• Free space size (F ): free disk space;• Uptime (U ): time the BioNimbuZ server

remains working in the federation, i.e.,a server working for a longer time ap-pears to be more reliable to store thefile, when compared to others presenting

741

lower times (due to leaving or recentlyintegrating the federation);

• Latency (L): latency between the clientand the BioNimbuZ server, since it isimportant to know if the file transfer tothe destination will be fast, or not.

These variables influence the storage value indifferent ways, thus uptime was more heavilyweighted than the free space size. Regardinguptime, whenever a BioNimbuZ server leavesthe federation, the value of its uptime is re-set, and counting restarts if it re-enters in thefederation. Resetting the uptime does not affectthe computation of the storage values of stableservers since, as shown by Maymounkov andMazieres [14] and Verespej and Pasquale [15],stable servers “remains stable” even if the up-time is reset (due to some failure). Or, if oneserver remains working for one hour tends tocontinue working for more one hour, which isdifferent from servers that usually fail.

Our storage value was based on Xun-Yi andXiao-Dong [16], who proposed that the storagevalue of one file F could be computed from thecost of transferring F to the destination addedto the cost of storing each byte of F .

BioClouZ computes a storage value for eachBioNimbuZ server relative to each client. Whenone client gets a list of the BioNimbuZ serversin order to calculate their storage values, thecomputation is done so that one storage valuecan not be overwritten by another one, if asecond client makes a request before the clientwho had requested first receives his storagevalues. Besides, the storage value computedby BioClouZ models the transfer time betweentwo servers, the lower value indicating thelower cost to transfer the file.

Equation 1 shows the computation of thestorage value (S), where the three variables U(uptime), F (free space time) and L (latency)were weighted by γ, β and α, respectively, suchthat α+β+γ = 1.0. Based on several ad hoc tests,the weights were assigned to the followingvalues: α = 0.5; β = 0.2; and γ = 0.3. Moreover,since BioNimbuZ is a hybrid platform, publicor private clouds can integrate it. Thus it ispossible that a BioNimbuZ server charges forstorage, adding an extra cost to the storagevalue. Some clouds, e.g. Amazon and Azure,

charges for gigabytes of stored data. This cost,dollars per gigabyte, is included in the config-uration file of the corresponding BioNimbuZserver, and this storage price was modeled bythe variable Cost. In clouds not charging forstorage, this variable is assigned to 0.

S = 1/(U ∗ γ + F ∗ β) ∗ (L ∗ α) + Cost (1)

After computing the storage value for eachBioNimbuZ server, a client receives a list con-taining all the server storage values, ordered inascending order, i.e., from the server with thelowest cost to the one with the largest. Next,this list is returned to the client who requestedthe upload, and BioClouZ tries to send the fileto the server appearing first in this list. If it isnot possible, another trial is made to the nextserver, and this continues until the file is stored.

Figure 3 shows, in a simplified form, howBioNimbuZ uses Avro for a file upload: (1) theclient makes a connection to the federation; (2)the client receives a list of BioNimbuZ serversthat may receive the file; (3) the client computeslatency between himelf and each BioNimbuZserver, sending one RPC call to the servers thatmay store the file (these are the latency valuesused by BioClouZ). Next, the best BioNimbuZserver to store the file will be found based onthe values computed by BioClouZ; (4) the firstBioNimbuZ server makes one RPC call to theserver chosen by BioClouZ with informationof the file sent by the client; finally, (5) theclient opens a connection to the destinationBioNimbuZ server and sends the file.

Fig. 3. An upload operation made by RPC Avro.

3.2 BioClouZ servicesBesides uploading, other services were createdto improve data management in BioNimbuZand implemented in the BioClouZ policy:

742

• List: lists all the files stored in the fed-eration. With this command, the clientaccesses a single list with all the filesstored in BioNimbuZ, such that he/shehas the illusion that these files are storedonly in the server he/she is connected;

• Download: makes download to the clientcomputer, or to the BioNimbuZ serverthat needs a file to perform a task. Boththe download and the upload use theSFTP protocol;

• Replicate file stored in the federation:when a new file is uploaded or created inBioNimbuZ, the BioClouZ policy verifieshow many copies of this file are stored inthe federation. If the number of copies isless than a predefined value, the file is im-mediately replicated to different BioNim-bus servers until reaching the number ofcopies set in the configuration file. Defaultis two, being this value easily changeable;

• Fault Tolerance: if a server leaves BioN-imbuZ (e.g., due to network or energyproblems), all the BioNimbuZ servers willbe noticed via ZooKeeper, stating thatthis server is unreachable. Moreover, thisservice seeks, in the disconnected BioN-imbuZ server (znode), the information ofthe files that became unaccessible. Bio-ClouZ uses this information to find theBioNimbuZ servers having copies of eachfile stored in the disconnected server. Bio-ClouZ sends messages to these BioNim-buZ servers, warning that they shouldreplicate these files, since one file copyhas been lost due to one BioNimbuZserver crash. Thus, each server replicatingthis file will have to compute the storagevalue between itself and all the otherservers, to choose the new BioNimbuZserver that will replicate each file withless one copy.

4 CASE STUDIES

THREE case studies were performed to an-alyze the performance of the BioCloudZ

storage policy in practice. They were executedwith real bioinformatics data at BioNimbuZ.

For the experiments, a prototype with treefederated clouds was constructed:• one cloud at the University of Brasilia

(Brazil), composed of three machines,each with a processor Core i7-3770 3.4GHz, 8GB RAM, 2TB hard disk, Linuxoperating system Ubuntu 04.13;

• one cloud at Microsoft Azure [17] (EastAsia), composed of one virtual machinewith 8 cores, 14GB of RAM, 30GB harddisk, Linux operating system Ubuntu04.12 LTS;

• one cloud at Amazon EC2 [18] (UnitedStates), composed of three virtual ma-chines, each with a porcessor Intel Xeon2.4 Ghz, 613MB RAM, 80GB hard disk,Linux operating system Ubuntu 12.04.2.

Case study 1. Consisted in one uploadoperation of a binary file of 70 Megabytes toBioNimbuZ, with the client located in Brazil.Nine uploads were executed with the greedystorage policy and other nine with BioClouZ.The first BioNimbus platform executed with thegreedy policy, just receiving the user requestsand sending the files to the first BioNimbuZserver with enough space to store them.

Results showed that the BioClouZ storagepolicy (see Figure 4) sent the files to the cloudlocated in Brazil in 67% of the upload oper-ations. In contrast, the greedy policy sent thefiles to the cloud located in East Asia in 56%of the upload operations. This shows that Bio-ClouZ suggested to send the file to the serverclosest to the client, since BioClouZ considerslatency the most important factor, and latencyis reduced when source and destination aregeographically close.

Fig. 4. File storage policy in BioNimbuZ servers.(a) BioClouZ. (b) Greedy.

Besides, since BioClouZ selects the closest

743

server, data transfer is performed faster. Filedownload average time was 33.34 secs withBioClouZ, compared to 51.23 secs of the greedypolicy, showing that BioClouZ reduced thetransfer time to about 65%. The average trans-fer rate was computed from the average timeof the nine file downloads, for each policy.

Case study 2. The objective was to studythe total execution time of jobs sent to BioNim-buZ when compared to the same jobs executedlocally. For this, a federated cloud was con-structed with two clouds, one at the Universityof Brasilia and the other at Amazon EC2 [18],with the same configuration described before,both with the BioClouZ storage policy.

We used Bowtie [4], a typical bioinformaticstool for mapping short sequences to areference genome. Bowtie was available asa service in BioNimbuZ. Five jobs werecreated, each job executing once with Bowtieand one input file. Table 1 shows the files,dowloaded from the NCBI [19] databaseftp://ftp.ncbi.nih.gov/genomes/H sapiens/Assembled chromosomes/seq/, and stored inthe BioNimbuZ servers.

TABLE 1Sizes of the input files used to execute Bowtie.

File name Length Job numberhs alt HuRef chr1.fa 252 MB 1hs alt HuRef chr2.fa 247 MB 2hs alt HuRef chr3.fa 198 MB 3hs alt HuRef chr4.fa 189 MB 4hs alt HuRef chr5.fa 178 MB 5

These five jobs were sequentially executed,with the total execution time measured in mil-liseconds (see Figure 5). Time was computedfrom the initial time of the first job to the finish-ing time of the last job. This experiment showsthat BioNimbuZ is more efficient to executejobs, when compared to the execution in onepowerful machine.

Case study 3. We aimed to investigatethe influence of the number of znodes in thejob execution time. Two executions were per-formed, both with two clouds (University ofBrasilia and Amazon EC2, as described be-fore, both with BioClouZ) and time measuredonce. In the first execution, only one ZooKeeperserver (znode) was used to manage data in each

Fig. 5. Times of each job execution in BioClouZwith 2 znodes, at the University of Brasilia andat Amazon EC2.

BioNimbuZ server. In the second one, threeZooKeeper servers (znodes) were created, one atthe University of Brasilia and two at AmazonEC2.

In the first execution, the total time of the fivejob execution was 401 seconds (see Figure 5).The inclusion of one more znode in AmazonEC2 led to a total time of 190 seconds, about53% faster. This shows that the job executiontime is faster when more znodes are conve-niently used to model each BioNimbuZ serverintegrating the federation.

5 RELATED WORK

RECENT research has been developed to de-sign and implement generic storage in-

frastructure services, e.g., distributed storageservices in clouds [20], [21], [22]. Many stor-age service providers need a strong workof integration, due to distinct interfaces andparticular sets of resources provided by eachprovider [23], [24]. Particularly, in a federatedcloud environment, execution of applicationsinvolves file storage and transferring amongthe clouds integrating the federation.

Although bioinformatics applications usu-ally manipulate large volumes of data, whichjustifies the use of cloud environments, stor-age policies proposed in the literature do notconsider specific characteristics of bioinformat-ics applications. Among these general purpose

744

systems, many storage systems are available inthe literature, e.g., Hadoop Distributed File Sys-tem [25], [26], CassandraFS [27], XtreemFS [28],Lustre [29], [30] and Ceph [31].

These systems have to be carefully adaptedto genomic data, in order to efficiently man-age this kind of data, since gigabytes can beeasily reached in one single project. Generally,time and memory efficient bioinformatics toolsexecute in very large databases, requiring ex-tensive processing and storage resources. Be-sides, distinct bioinformatics research institutesdevelop tools and generate data that may beshared. The storage policy BioClouZ, as wellas BioNimbuZ, are solutions aiming to be easyto use and to provide transparency, scalabilityand elasticity, integrating clouds with distinctpolicies for data and security.

Stockinger et al. [32], in their cost model todistribute and replicate data, presented someaspects that could influence data transfer, e.g.,physical location, bandwidth, size of the fileto be downloaded and transmission protocol.Although this model was more concerned tocost, the authors also considered other aspects,since the objective was to transfer files in theshortest possible time, leading to a lower cost.

Zeng et al. [33] proposed a layer based ar-chitecture to implement a data storage servicein clouds. The more important layers (meta-data managing, management overlapping andinterface) virtualized the details of each cloudprovider, so that the user could access a moreabstract level of an automatic selection man-agement service. The BioClouZ storage policy,proposed here, is similar, since it defines alayer of virtual data management connected toeach cloud integrating the federation, havingalso the possibility to use the local storage ofthese clouds. Besides, the authors used the AntColony Optimization (ACO) algorithm.

Yuan et al. [34] proposed an algorithm toselect a cloud as the data storage provider,using a grouping strategy based on the k-meansmodel.

Ruiz-Alvarez and Humphrey [35] devisedan automatic mechanism to select the storagemanagement. The main contributions of thiswork were: (i) an XML schema to describethe cloud providers and respective storage re-

sources; and (ii) an algorithm to select an stor-age service based in criteria supplied by theusers, e.g., cost, data transfer, durability anddata versioning. A key characteristic of theirmechanism is the possibility to access statisticsof the storage providers in real time, so thatthe algorithms can use current information todecide the best location to store data.

Bermbach et al. [36] reported the problem ofthe dependency of one single storage service,which could limit availability and scalability,besides causing delays in executions carried outby the client’s service. To minimize this prob-lem, they proposed MetaStorage, a federatedstorage system using hash tables integratingdifferent suppliers through data replication.

Zhang et al. [7] proposed a model also basedon layers (access, applications and storage in-frastructure), through a P2P communication.The infrastructure layer is responsible for car-rying out the distribution of files between twodifferent storage services, channels and devices,as well as for performing compression andredundancy. The storage layer controls the pro-cesses to be executed. Updating and retrieving,among others, ensure information availability.

Research in cloud storage and data com-pression usually consider large amounts ofdata. Nicolae [37] presented BlobSeer, a modelto manage distributed data, specially imple-mented to read, write and collate large amountsof information on a large scale, also perform-ing data compression. Bandwidth is used totransfer data. This approach allows to decreasethe amount of disk space. However, it shouldconsider also feasibility due to both time andcost required to perform such operations.

Recently, Hiden et al. [38] presented a modelthat allows to execute workflows and shareapplications developed in distinct institutions(similarly to BioNimbus [8]), where the storagemanagement is hidden by some services. How-ever, their structure can not be used in hybridclouds, like BioNimbuZ.

A more detailed investigation about datastorage in cloud federation is still necessary. Inthis context, two tendencies in storage policieshave to be studied, integration of data process-ing requirements as well as other mechanisms,e.g., security and criptography [39], [40].

745

6 CONCLUSION

IN this paper we presented BioClouZ, a stor-age policy to the BioNimbuZ hybrid fed-

erated cloud platform, which considers fac-tors such as computational capacity of the re-sources, type of clouds (charged or free data)and services provided by each federated cloud.Three case studies were performed, and resultsshowed that BioClouZ led to a more efficientstorage policy, in the sense that the total timeto execute a bioinformatics application is lowerwhen comparing to the same application ex-ecuting with a greedy storage policy, previ-ously used in BioNimbuZ. Moreover, replica-tion and fault tolerance operations improveddata availability as well as file retrieval bothto the clients and the federated clouds. Toimplement the novel storage policy, updates inthe first BioNimbus platform were performed,leading to a second version called BioNimbuZ.Using Zookeper and Avro, the communicationamong the federated clouds was changed, anda decentralized coordination was developed.

Other bioinformatics applications can be eas-ily adapted to BioNimbuZ, since the platformwas designed to be independent from partic-ular tools and databases. Each cloud enteringin the federation may offer its services, man-taining its security and storage policies, andalso can benefit from the services offered by theother clouds. Therefore, commonly used bioin-formatics tools, e.g., Blast and HMMER/Pfam,as well as workflows, may be easily ported toBioNimbuz, if clouds entering in this federatedplatform offer them as services.

Despite the good results obtained by Bio-ClouZ, it could be improved by keeping localand current parameters to foresee the betterclouds to store and replicate data. Besides, thecomputation of storage values of the clouds,based on four parameters (free space size, up-time, latency and storage cost), could includeactual compute capacity of the virtual machineswhere data will be processed. In this direction,we intend to measure to what extent movingdata, e.g., to a 64 Gb machine in Asia affectsthe latency of moving data to a 2 Gb ma-chine at the University of Brasilia, since theresource capacity of the machines executing

one application could affect the total executiontime. Experiments with larger files and moremachines on each cloud are planned. Moreover,the implementation of P-FTP (Parallelized FileTransfer Protocol) [41] to a federated cloudenvironment could accelerate data transfer be-tween clients and servers. Finally, regardingto security aspects, implementation of an ACL(Access Control List) associated to the filesstored in the federation will assure that only au-thorized users could use and modify these files.Clouds where data can be stored and otherdata security information could be negotiatedbetween users and BioNimbuZ.

ACKNOWLEDGMENTS

A. Araujo, M. Holanda and M.E. Walter wouldlike to thank STIC-AmSud project (CAPES41/2013) and M. E. Walter would like to thankCNPq (Project 308509/2012-9).

REFERENCES[1] S. V. Angiuoli, M. Matalka, A. Gussman, K. Galens,

M. Vangala, D. R. Riley, C. Arze, and J. R. White, “CloVR:A virtual machine for automated and portable sequenceanalysis from the desktop using cloud computing,” BMCBioinformatics, vol. 12, no. 356, pp. 1–15, 2011.

[2] S. V. Angiuoli, J. R. White, M. Matalka, O. White, andW. F. Fricke, “Resources and costs for microbial sequenceanalysis evaluated using virtual machines and cloudcomputing,” PLoS ONE, vol. 6, no. 10, p. e26624, 2011.

[3] B. Langmead, M. C. Schatz, J. Lin, M. Pop, andS. Salzberg, “Searching for SNPs with cloud computing,”Genome Biology, vol. 10, no. 11, p. R134, 2010.

[4] B. Langmead, C. Trapnell, M. Pop, and S. Salzberg, “Ul-trafast and memory-efficient alignment of short DNA se-quences to the human genome,” Genome Biology, vol. 10,no. 3, pp. R25+, 2009.

[5] B. Pratt, J. J. Howbert, N. Tasman, and E. J. Nilsson, “MR-Tandem: parallel X!Tandem using Hadoop MapReduceon Amazon Web Services,” Bioinf., vol. 8, pp. 1–12, 2011.

[6] M. C. Schatz, “CloudBurst: Highly sensitive read map-ping with MapReduce,” Bioinformatics, vol. 25, pp. 1363–1369, 2009.

[7] L. Zhang, S. Gu, B. Wan, Y. Liu, and F. Azuaje, “Gene setanalysis in the cloud,” Bioinform., vol. 13, pp. 1–10, 2011.

[8] H. Saldanha, E. Ribeiro, C. Borges, A. Araujo, R. Gallon,M. Holanda, M. E. Walter, R. Togawa, and J. C. Setubal,“Towards a hybrid federated cloud platform to effi-ciently execute bioinformatics workflows,” in BioInform.,H. Perez-Sanchez, Ed. In Tech, 2012, ch. 5, pp. 107–132.

[9] Zookeeper, “The Apache Software Foundation,” 2013,http://zookeeper.apache.org/.

[10] Avro, “Apache AvroTM 1.7.4 Documentation,” 2013,http://avro.apache.org/docs/current/.

746

[11] L. Wu and R. Buyya, “Service Level Agreement (SLA)in Utility Computing Systems,” Cloud Computing andDistributed Systems Laboratory, The University of Mel-bourne, Tech. Rep. CLOUDS-TR-2010-5, 2010.

[12] D. Crockford, “The application/JSON Media Type forJavaScript Object Notation (JSON),” 2006, rFC 4627 (In-formational). http://tools.ietf.org/search/rfc4627. JSON:http://json.org/.

[13] I. Stoica, R. Morris, D. Liben-Nowell, D. Karger,M. Kaashoek, F. Dabek, and H. Balakrishnan, “Chord: ascalable peer-to-peer lookup protocol for internet appli-cations,” IEEE/ACM Transactions on Networking, vol. 11,no. 1, pp. 17–32, 2003.

[14] P. Maymounkov and D. Mazieres, “Kademlia: A peer-to-peer information system based on the XOR metric,” inRevised Papers from the First International Workshop on Peer-to-Peer Systems, ser. IPTPS ’01. London, UK: Springer-Verlag, 2002, pp. 53–65.

[15] H. Verespej and J. Pasquale, “A characterization of nodeuptime distributions in the PlanetLab test bed,” in 30thIEEE Symposium on Reliable Distributed Systems (SRDS),2011, pp. 203–208.

[16] R. Xun-Yi and M. Xiao-Dong, “A* algorithm based op-timization for cloud storage,” JDCTA, vol. 4, no. 8, pp.203–208, 2010.

[17] Azure, “A solid cloud platform for creative ideas,” 2013,http://www.windowsazure.com/pt-br/.

[18] Amazon, “Amazon Elastic Compute Cloud,” 2013,http://aws.amazon.com/pt/ec2/.

[19] NCBI, “U.S. National Library of Medicine,National Center for Biotechnology Information,”http://www.ncbi.nlm.nih.gov/, 2013.

[20] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wal-lach, M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber,“BigTable: A distributed storage system for structureddata,” in Proc. 7th Conference on Usenix Symposium onOpertating Systems Design and Implementation, volume 7,2006, pp. 205–218.

[21] S. Ghemawat, H. Gobioff, and S.-T. Leung, “The Googlefile system,” in ACM SIGOPS Operating Systems Review,vol. 37, no. 5. ACM, 2003, pp. 29–43.

[22] G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati,A. Lakshman, A. Pilchin, S. Sivasubramanian, P. Vosshall,and W. Vogels, “Dynamo: Amazon’s highly availablekey-value store,” in SOSP, vol. 7, 2007, pp. 205–220.

[23] A. Li, X. Yang, S. Kandula, and M. Zhang, “CloudCmp:comparing public cloud providers,” in Proc. 10th ACMSIGCOMM Conf. on Internet Measurement, 2010, pp. 1–14.

[24] Z. Hill, J. Li, M. Mao, A. Ruiz-Alvarez, and M. Humphrey,“Early observations on the performance of WindowsAzure,” in ACM Proc. 19th International Symposium onHigh Performance Distributed Computing, 2010, pp. 367–376.

[25] D. Borthakur, “Hadoop distributed file system: architec-ture and design,” Hadoop Project Website, pp. 1–14, 2007,http://hadoop.apache.org/common/docs/r0.18.0/hdfsdesign.pdf.

[26] K. Shvachko, H. Kuang, S. Radia, and R. Chansler, “TheHadoop Distributed File System,” in Proc. 2010 IEEE26th Symposium on Mass Storage Systems and Technologies(MSST’10). Washington, DC, USA: IEEE ComputerSociety, 2010, pp. 1–10.

[27] A. Lakshman and P. Malik, “Cassandra: A decentral-ized structured storage system,” SIGOPS Oper. Syst. Rev.,vol. 44, no. 2, pp. 35–40, Apr. 2010.

[28] F. Hupfeld, T. Cortes, B. Kolbeck, J. Stender, E. Focht,M. Hess, J. Malo, J. Marti, and E. Cesario, “The XtreemFSarchitecture: a case for object-based file systems in grids,”Concurr. Comput. : Pract. Exper., vol. 20, no. 17, pp. 2049–2060, Dec. 2008.

[29] Lustre, “Lustre file system,” http://lustre.opensfs.org/,2013.

[30] J. Piernas, J. Nieplocha, and E. J. Felix, “Evaluation of ac-tive storage strategies for the lustre parallel file system,”in Proc. 2007 ACM/IEEE Conference on Supercomputing, ser.SC ’07, New York, NY, USA, 2007, pp. 28:1–28:10.

[31] S. A. Weil, S. A. Brandt, E. L. Miller, D. D. E. Long, andC. Maltzahn, “Ceph: A scalable, high-performance dis-tributed file system,” in Proc. 7th Symposium on OperatingSystems Design and Implementation (OSDI), 2006, pp. 307–320.

[32] H. Stockinger, K. Stockinger, E. Schikuta, and I. Willers,“Towards a cost model for distributed and replicateddata stores,” in Proc. Nineth Euromicro Workshop on Paralleland Distributed Processing. Wien Univ., Austria: IEEEComputer Society, 2001, pp. 461–467.

[33] W. Zeng, Y. Zhao, K. Ou, and W. Song, “Research oncloud storage architecture and key technologies,” in ACMProc. 2nd International Conference on Interaction Sciences:Information Technology, Culture and Human, 2009, pp. 1044–1048.

[34] D. Yuan, Y. Yang, X. Liu, and J. Chen, “A data placementstrategy in scientific cloud workflows,” Future GenerationComputer Systems, vol. 26, no. 8, pp. 1200–1214, 2010.

[35] A. Ruiz-Alvarez and M. Humphrey, “An automated ap-proach to cloud storage service selection,” in Proc. 2ndinternational workshop on Scientific cloud computing. ACM,2011, pp. 39–48.

[36] D. Bermbach, M. Klems, S. Tai, and M. Menzel, “Metas-torage: A federated cloud storage system to manageconsistency-latency tradeoffs,” in Proc. 2011 IEEE 4thInternational Conference on Cloud Computing, ser. CLOUD’11. Washington, DC, USA: IEEE Computer Society, 2011,pp. 452–459.

[37] B. Nicolae, “High throughput data-compression for cloudstorage,” in Proc. Third international conference on Datamanagement in grid and peer-to-peer systems, ser. Globe’10.Berlin, Heidelberg: Springer-Verlag, 2010, pp. 1–12.

[38] H. Hiden, S. Woodman, and P. Watson, “Developingcloud applications using the e-science central platform,”Philosophical Transactions of the Royal Society - A Mathemat-ical Physical Engineering Sciences, vol. 371, no. 1, pp. 17–32,2013.

[39] H. Takabi, J. B. Joshi, and G.-J. Ahn, “Security and privacychallenges in cloud computing environments,” Security &Privacy, IEEE, vol. 8, no. 6, pp. 24–31, 2010.

[40] T. Mather, S. Kumaraswamy, and S. Latif, Cloud securityand privacy: an enterprise perspective on risks and compliance.O’Reilly, 2009.

[41] S. Sohail, S. Jha, and H. ElGindy, “Parallelized file transferprotocol (P-FTP),” in Proc. 28th Annual IEEE InternationalConference on Local Computer Networks (LCN’03), 2003, pp.624–631.

747