okmi09 - a sharable storage service for distributed computing

8/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing

1/12

A. Hua and S.-L. Chang (Eds.): ICA3PP 2009, LNCS 5574, pp. 545556, 2009.

Springer-Verlag Berlin Heidelberg 2009

A Sharable Storage Service for Distributed Computing

Systems in Combination of Remote and Local Storage

MinHwan Ok

Korea Railroad Research Institute

Woulam, Uiwang, Gyeonggi, Korea

[email protected]

Abstract. Traditional Grid data management systems have been developed on

the supposition that the network bandwidth is unconstrained with dedicated

broadband network lines and the storage space is enough for storing replicas.

This paper proposes a storage service for distributed computing systems with-

out the supposition, by adopting the concept of pervasive storage in the distrib-

uted computing. The Sharable Storage space is recognized as the application

servers local storage. Whenever the user commits, data transfer is automati-

cally performed using iSCSI protocol. The storage service is destined for nu-

merous data transfer of relatively small files, and simulated under the condition

of a restrictive network bandwidth. File preloading function could make the ap-

plications start early without dedicated broadband network lines. The comput-

ing sites could benefit from the proposed storage service than waiting until thewhole file is transferred for replication and keeping the replica stored without

the users explicit note for reuse.

Keywords: Distributed Computing Systems, Sharable Storage, Preloading,

iSCSI, Pervasive Storage.

1 Introduction

Mobile devices for pervasive computing are developed these days in support of ubiq-

uitous networking such as wireless data communications. Using these devices, com-

monly two essential entities a user manipulates are the software and user data. Most

of users data are usually placed in the users private storage. Wherever the software

is located, user data need be delivered to the software unless the software moves for

execution near user data, suchlike application streaming. Pervasive Storage suits well

to this necessity and the concept is depicted in Fig 1. The industry of storage devices

including VERITAS, EMC, and Hitachi officially predicated the definition[1] and

their definition aims for use with mobile devices. However the pervasive storage

could be utilized not only for the case of mobile applications but also for the case ofdistributed computing including clusters, Grids, or emerging Cloud computing.

Traditional Grid data management have been developed on the supposition that the

network bandwidth is unconstrained with dedicated broadband network lines and

the storage space is enough for storing replicas. The supposition is not practical at all

the computing sites, indicating shortcomings in both performance and resource


2/12

546 M. Ok

Data from

User`s private

storage

Base Station

Remote applicationon Wireless line

Remote application

on Wired line

Internet

Home location ofUser data

Pervasive Storage

Pervasive Storage

Fig. 1. The concept of pervasive storage

utilization. This paper proposes a storage service for distributed computing with the

strategy to lessen the shortcomings, by adopting the concept of pervasive storage into

the distributed computing. The computing sites could benefit from the proposed stor-

age service than waiting until the whole file is transferred for replication and keeping

the replica stored without the users explicit note for reuse.Computing cluster is a resource pool of powerful hardware and specific softwares

for science and engineering. Specific softwares, for scientific simulations or analyses

for engineering, are increasingly engaging faster processing speed, larger memory

area and more storage space. Most of these softwares require powerful hardware,

which has superior processing unit, huge main memory and vast auxiliary storage.

These characteristics make those softwares unmovable, and any user, at other site,

who needs those softwares may use them through the Internet. Many computing sites

including computing cluster sites are gathering to form a Grid computing environ-

ment. Many of the previous storage services have adopted GridFTP[11] to transfer

user data to a computing site in Grid computing environment. Since the applications

require processing large amounts of data, in the case that the objective is a challeng-

ing issue, the storage services previously proposed have used dedicated broadband

network lines. However dedicated broadband network lines are still not general

equipment of most computing sites due to its high cost. Further there are much more

applications processes much less amounts of data as usual cases. In this paper we pro-

pose a storage service that focuses on cooperative computing with small amounts of

data in distributed computing environment. Especially the users data does not remain

at the computing site in the storage service, which is distinct far from the method in

cloud computing. The users data is placed at somewhere out of the computing sites.In our recent knowledge, there has not been any approach similar to our goal in

Grid computing, since proposed storage subsystem supply remote storage space to an

application server as virtually local disks by automatic data transfer among storage

subsystems. Although this work is not for building an entire Data Grid, the

service has characteristics such as a model of Federation (which is peer-to-peer) in


3/12

A Sharable Storage Service for Distributed Computing Systems 547

organization, a function of Overlay network, a security of Authentication, a transfer

mode of Stream in data transport, and an application class of Workflows, a scope of

Individual, a data replication of Decoupled, a locality of Spatial in scheduling, accord-

ing to the taxonomy of [12]. In the next section, the concept of Sharable storage is in-

troduced. Automatic data transfer with system architecture is described in Section 3,showing the other merit of sharable storage. Section 4 describes a file preloading

function for improvement of transfer performance in the condition the sharable stor-

age subsystem has no dedicated network lines. Simulation results are presented under

the condition in Section 5, and Section 6 deals with related works. The last section

summarizes this work.

2 Pervasive Storage in Distributed Computing Systems

Although there could be similar imagination to pervasive storage before, the official

definition of pervasive storage was predicated in [1] as follows;

Pervasive storage is about pervasive access to information which must support dis-

connected as well as connected operation.

It was not determined Disconnected for how long but this should not mean never

connected, since it negates access to information. In this work, the wireless connec-

tion is not considered, and it is presumed the wired connection is always available.

From the definition, we learn pervasive storage is the accessibility toinformation stored in somewhere anytime, than that to the storage device in which the

information is stored. Hence two new terms are introduced in the draft, the first one is

Storage Cell and the second one isInterconnected Storage Farms.

Storage Cell is a cache located close to the user accessing data located remotely,

thus makes the latency in accessing the data. Interconnected Storage Farms is home

location of the data, constituted by storage farms, with support for storage cell. Inte-

grated storage farm is appropriate for distributed computing sites with their storage

subsystems. On the other hand, storage cell is adequate to ubiquitous networking for

caching the data. The integrated storage farm constituted by storage subsystems of

cluster computing sites is shown in Fig. 2.Computing sites that provide application service should accommodate plenty of

processing resources and vast storage capacity, including necessary software set for

users. Dozens of application servers supply numerous processing capabilities from

server farm, and the storage server supply integrated storage volume with a number of

disks. In the cluster sites depicted in Fig. 2, storage subsystem is separated from ap-

plication servers local storage. Each application server has its own disk drives with

operating system installed. The local disk drives are only for the application server

operation and application running. User data are stored in the SAN(Storage Area

Network)[5] disks through the storage server. These storage subsystems could be in-tegrated into the integrated storage farm. Users private storage is not located inside

either of the computing sites. It is located somewhere the user prefers, i.e. his personal

computer. If the storage cell exists, named Sharable Storage in this paper, the user

data becomes ubiquitous for distributed computing through sharable storage.


4/12

548 M. Ok

Data Data Data

SAN Disk Bunch

Internet

Storage Server

Application ServerApplication Server Application Server

Router

ApplicationServer Farm 1

StorageSubsystem 1

Data Data

SAN Disk Bunch

Storage Server

Application Server Application Server

Router

ApplicationServer Farm 2

StorageSubsystem 2

Fig. 2. Two computing sites constitute a part of Grid computing environment with server farms

and their storage subsystems

Fig. 3 depicts an example of user data movement by traditional data transfer when

a user need four specific softwares installed in computing site 1 through computing

site 4, respectively, in sequential order. In some distributed computing environment,

locating the home space in a computing site is straightforward, however, that may not

be desirable for users considering data security in the Cloud or for the administratorconsidering storage space utilization concerns of the computing sites in the Grid. A

sharable storage receives users primitive input data and transfers data of each stage

to/from the computing sites and sends final output data, including data of each stage,

to the user. The user logs-in to the sharable storage and use the software of each com-

puting site as depicted in Fig. 4, and data are automatically transferred between each

computing site and the sharable storage, each time the user commits the transfer.

Computing

Site 1

Computing

Site 2

Computing

Site 3

Computing

Site 4

User Data

Manual DataTransfer

Computing

Site 2

Computing

Site 3

Computing

Site 4

User Data

SharableStorage

Computing

Site 1

Manual DataTransfer

AutomaticData Transfer

Fig. 3. Traditional Data Transfer Fig. 4. Automatic Data Transfer


5/12


The location of sharable storage is inside the computing sites in which the first ap-

plication resides. From the first stage, the storage space becomes sharable with other

computing sites until the output result data is transferred to users private storage, af-

ter the fourth stage. It was assumed that nearly-continuous network access is available

at bandwidth adequate for transmitting the data in the draft[1]. However, this assump-tion is unrealistic and such network access may not be guaranteed among all the

computing sites in the Grid. In this work, we focus on the feasibility of the sharable

storage, a storage cell model for distributed computing, with respect to hit ratios while

accessing the user data cached from its home space.

3 Automatic Data Transfer

The location of sharable storage is an important point to consider. Let the home space

is located in the storage server of one computing cluster, for instance, the left comput-

ing cluster of Fig. 2. The figure implies that the storage subsystem might be immi-

grated outside the site. At present the server farm and home space of sharable storage

coexists for network bandwidth consideration. The router is the gateway of this com-

puting cluster, and it may act as a Grid interface that manages resources and supports

single sign-on. We dont describe in detail the cluster management as a participant of

Grid computing environment since it is not the aim of this work. An application client

willing to log on the storage server should send its request to the router. The router

admits the user by authentication and let the client connected to the storage server.

After log-in the client gets access right from its private storage to the storage server.Then the user selects appropriate application server and manually transfers his data

from his private storage to the home space. When the user logs-on by single sign-on,

a secure connection is established between the storage server and the application

server. The client can also connect to an application server of other computing cluster

in the Grid. By this time, the users home space becomes sharable and cached data

from the home space constitutes sharable storage at the application server of other

computing site. In this work, the home space become sharable is also called sharable

storage, as any file of the home space is cacheable at the application server.

Storage Server

Data Data Data

S t o r a g e

M a n a g e

m e n t

SCSI

DriveriSCSITarget

File System

Application Server

iSCSIInitiator

SCSIDriver

Identi

fier

File System

Applicati

on

TCP/IP

with

security

Pre-

loader

Internet

Data

ApplicationClient

Fig. 5. System architecture to supply processing resources and secure storage


6/12

550 M. Ok

User data is transferred to storage server manually, and transferred to the applica-

tion server automatically. Fig. 5 depicts system architecture for sharable storage.

Since the iSCSI protocol can make clients access the SCSI I/O devices of a storage

server over IP network, a client can use the remote storage of other computing site

transparently without the need to pass through the remote storage servers file sys-tem[6]. The users sharable storage is recognized as the application servers local

storage by a particular network device driver[2]. Once the application requests a file

to the device driver, iSCSI Initiatorin the figure, it relays the request to the other net-

work device driver, iSCSI Target, of the storage server. The storage server starts to

transfer the file to application server via the network device drivers. When the appli-

cation server transfers data to the storage server, data blocks are delivered via iSCSI

Initiatorand iSCSI Target. For performance consideration, block I/O was adopted[3]

that provides necessary blocks of an opened file to the application server and updates

corresponding blocks when modification occur. Block I/O outperforms file I/O andmoreover it does not adhere to a certain file system. Storage Managementmodule in-

tegrates its disk spaces and partitions the integrated volume for home spaces. The disk

spaces can be interleaved to speed up the transfer, suchlike RAID(Redundant Array of

Inexpensive Disks)s. The user may select more than one application server concur-

rently.Identifiermodule monitors connections with application servers and maintains

each connection, i.e. connection re-establishment and transfer recovery.

Sharable storage, recognized as local storage of the application server, has another

merit of expanding local storage with the partition from the storage server, as depicted

in Fig. 6. Suppose two computing sites of Fig. 2. The storage server of the left com-

puting cluster has integrated the capacities of three disks into one volume while the

storage server of the right computing cluster has integrated the capacities of two disks

into one volume. Assuming that sharable storage for the home space be located in the

left volume of Fig. 6(a) and the user selects an application installed in the right com-

puting cluster, the cluster takes extra space from the left cluster, to say, 20% of the

volume if the sharable storage charges 20%. On the other hand, assuming that shar-

able storage for the home space be located in the right volume of Fig. 6(b) and the

user selects an application installed in the left computing cluster, the cluster takes

extra space of the sharable storage from the right cluster, that is 30% of the volume.

DataData Data Data Data

20%

80%

Lend

Space

30%

70%

DataData Data Data DataLend

Space

(a) Sharable storage in the left volume (b) Sharable storage in the right volume

Fig. 6. Sharable storage space is lent to the application server


7/12


Pre-loadermodule caches the user data from sharable storage for computing clus-

ters not equipped with dedicated broadband network lines. Note that only cached

amount of the capacity is charged in the application server. This module is described

further in the next section. The application server and the storage server can exchange

data through the Internet as the data are transferred using iSCSI protocol.

4 Replication by File Preloading

When the application server being used is at one computing site and the storage server

of sharable storage is at the other computing site, network bandwidth is very impor-

tant for application running. An experiment has used a dedicated network bandwidth

of 57Mbytes per second[4], between LBNL in Berkeley, CA and SLAC in Palo Alto,

CA. Without dedicated broadband network among computing sites, which is very ex-

pensive, reading from or writing to a file should prolong execution of the application.

Pre-loader module caches all the files opened by the user, from sharable storage of

the remote storage server to the application server. It preloads a file as a whole once

the file is opened. In the environment the Preloading is necessitated, it makes a

temporal replica at the application server.

Internet

FileA

File

B

File

C

FileA

File

B

FileA

File

B

Foreground Block Stream

Background Block Stream

Blocks from only Pre-loaderBlocks from Pre-loader and the

Other Site


LeftVolume

RightVolume

LendSpace

Application Server

Fig. 7. File caching strategy for reading operations

Fig. 7 illustrates read operations in the preloading strategy. When an application

has requested a block opening a file A, the pre-loader relays the request to the remote

storage server, where the files actually resides, and relay the delivered requestedblock to the application. I call this explicit block delivery as Foreground Block

Stream. As soon as the requested block delivered, the pre-loader initiates loading a

file of the requested block into its local disk. The pre-loader has a size limit in initiat-

ing loading with respect to the capacity of storage devices attached. I call this implicit

block delivery as Background Block Stream, and this stream uses idle resource of


8/12

552 M. Ok

storage servers network interface. In the Fig. 7, file A is loaded as a whole thus the

application requests any block in the loaded file, while some blocks of file B is deliv-

ered from the remote storage server as file B is still being preloaded.

File

A

FileB

FileC

File

A

FileB

File

A

FileB

Foreground Block Stream

Background Block Stream Blocks to only Pre-loaderBlocks to Pre-loader and the

Other Site

Internet


LeftVolume

RightVolume

LendSpace

Application Server

Fig. 8. File caching strategy for writing operations

Fig. 8 illustrates write operations in the preloading strategy. When an application

has requested recording a block, the pre-loader sends response to the application then

relays the request to the remote storage server. If the file should be flushed, closing a

file A for example, the file is added to Background_List and the blocks of files in

the list are delivered by background block stream. The pre-loader periodically deliv-

ers blocks of files in the list and the remote storage server records the blocks delivered

by background block stream.

The temporal replica of an open file is deleted immediately by pre-loader after the

file is closed in the application for the security reason. However the replica may be

not deleted for cooperation among other known users. Thus the management of file

replication[7] can be employed. In this case, synchronization between replica and

original one is processed in soft real-time. Section 6 discusses the cooperation with

the same files, in the way of replicas.

5 Simulation

5.1 Simulation Configuration

The data could be delivered either directly to the application server, or via the storageserver of the application servers site, from remote storage server. In the simulation, itis assumed the data stream is transferred via the storage server of the application

servers site, as the storage server has much higher capacity for caching data. Fig. 9depicts the network of the remote storage server where sharable storage resides, the


9/12


storage server of the application servers site, and the application server, that is simu-lated with Network Simulator 2.27 (NS2). The bandwidth between the applicationserver and the storage server is limited by 1Gbps. The bandwidth between the storageserver and the remote storage server is 10Mbps, what is a restrictive but practical

condition. We consider this condition to evaluate the preloading from a computingsite with commodity network lines. As blocks of a file are stored interleaving, hit ratioof blocks is measured along the number of block streams being loaded in parallel. It isassumed one block stream charges 2Mbps, in average by TCP/IP protocol, in the net-

work lines. The distance from the application server to the remote storage server is200km and delay ratio of A and B is 1:199. The data size is 512 bytes, which isdetermined along a SCSI block size.

RemoteStorageServer

StorageServer

ApplicationServer

iSCSI

TCP sink

iSCSI

TCP sink

iSCSI

TCP

iSCSI

TCP

Delay B Delay A

Fig. 9. Simulation Configuration with NS2

5.2 Hit Ratios by Data Types in Read Operations

The pre-loader aims at the hit ratio up to 100% by accommodating a whole file in the

storage server of the application servers site. The average file size is considered to be

64MBytes. It is usual data size for common softwares for research or engineering.

Some larger files would suffer longer transfer time. The simulation focuses on the hit

ratio of blocks in reading from those files until they are completely loaded.

The simulation adopted three file-access types, random-access, sequential-access and

random-sequential. Random-sequential is an access pattern that seeks a random start

point then accesses sequentially to a stop point. A file of 64MB is being loaded as

shown in Fig. 10. When the pre-loader is loading the file using only one block stream, it

takes 256sec to the 100% hit ratio for one random-access file. Since blocks are re-

quested randomly, hit ratio has reached 100% at the time the file is completely loaded.

File loading takes shorter time proportional to the number of parallel streams being

loaded, PLS in the figure. Although file loading takes the same time as that in the case

of random-access file, sequential files reach the hit ratio of 100% even earlier.

For each case of file types, it takes about 51.2 seconds in loading only one file and

1MBytes of a file is loaded in just 1.25 seconds using 5 block streams. That loadedfront part of 1MBytes suffices ordinary use tendency since an application usually

does not request every blocks of 64MB for several seconds, in all cases including the

case of random-access file. This is why the hit ratios are high from the beginnings.

For higher performance, a storage management technique in [8] can be implemented

for larger files.


10/12

554 M. Ok

PLS=5 PLS=4 PLS=3 PLS=2 PLS=1

0.100

1.000

0

51.2

102.4

153.6

204.8

256

Hit Ratio

0.100

1.000

0

51.2

102.4

153.6

204.8

256

Hit Ratio

0.100

1.000

0

51.2

102.4

153.6

204.8

256

Time(sec)

Hit Ratio

(a) Random-access File (b) Random-Sequential File (c) Sequential-access File

Fig. 10. Hit Ratios in loading a file of 64Mbytes

6 Related Works and Data Sharing by Replication

Data intensive computing is one of major objectives in Grid computing. A data inten-sive Grid employed a distributed parallel storage system(DPSS)[4]. DPSS adopted a

block-striping technique across the servers, which is similar to the technique of this

work. Data management and transfer subsystem is built by Globus Toolkit[11]. The

subsystem adopted GridFTP and manages replication. In the replication schema it is

aimed that replicas are released to unspecified users. In contrast replica sharing is

allow to persons permitted by the user who owns the original in this work. Replication

tool of files and objects is provided with various services[7]. Grid data mirroring

package(GDMP) addresses object replication issues in an object-oriented database.

To provide interactive graphical session in computing Grid, Interactive Gridis intro-duced[10] using and extending VNC and Globus Toolkit. It addresses hierarchical

sessions, admission control, agents, classes of dynamic accounts, application profil-

ing, data management, scheduling for interactive sessions, persistent environment

settings, and remote desktop.

Two recent related works have pointed out two issues similar to those of this work.

For the performance issue, GridTorrent[13] has evolved out of well-known BitTor-

rent. Transferring data in the peer-to-peer model, GridTorrent outperformed GridFTP

with bandwidth constraints in experiments. GridTorrent is advantageous by exploiting

the collaborative sharing properties of the underlying BitTorrent protocol in order to

boost aggregate performance. For the issues of high latency and resource usage in-cluding network and storage, XtreemFS[14] has been designed as a part ofXtreemOS

project. From the motivation the whole files have to be transferred and stored locally

in the traditional Grid data management services of Globus Toolkit including

GridFTP, it manipulates the consistency coordination of replicas at an object level,


11/12


extending the manipulation to sophisticated replication mechanisms at the object

level. Further XtreemFS provides the local replica creation initially empty, to transfer

actually needed data next, so the client can immediately work on its local replica. This

feature is very similar with the strategy in this work, although an intelligent storage

device called Object Storage Device is the hardware prerequisite of XtreemFS.Now lets revisit a work procedure of Fig. 4. The user traverses the computing site

1 through 4 to use respective software in each phase. The output data of each phase

are accumulated at sharable storage. The user may let the replicas of input data and

output data of each phase not deleted in the respective sites. In this case the user can

give the permission of log-in account with the replica to other user. In another case,

the user may open a file to make only a replica of the input data, and logout the site.

The other user takes the permission and uses the replica for cooperation. In any case,

one user could use one replica per phase and thus the users can share the input or/and

output data without disturbing each others work of each phase. In this scenario theusers can work in cooperation by communication with off-the-shelf messaging utility.

The user opens the output data, which the other user worked with replication and pro-

duced, to see the final results. At the same time the replicating of the output data is

initiated.

7 Conclusion

In distributed computing systems such as the Grid, an implicit requirement that the

participating computing sites have dedicated broadband network lines practically notrealistic for all computing sites. Recent related works have approaches to faster trans-

fer in GridTorrent and needed-objects first in XtreemFS. This paper proposed starting

application early with data partially loaded. Automatic data transfer occurs whenever

the application open, read from, write into, and close a file in sharable storage. The

sharable storage can be located either at the computing site where the user logged-in

or at other computing site in distributed computing environment. This functionality let

a user freely select any application server other than those of one computing site and

select the users sharable storage at any site in distributed computing environment.

Many of the previous works have adopted GridFTP, however the underlying storageservice proposed in this work is far different from GridFTP. Therefore there are a

number of future works such as naming, multi-level access-control, and replication

concerns, as summarized in [9].

Pre-loader is an important module for computing cluster sites with cheap commodity

network. The simulation has shown that preloading time was around 1 minute for one

64MB file with 5 block streams in average transfer rate 2Mbps. Enlarging the band-

width of network line should reduce the preloading time however it is an economic is-

sue. It is possible some kinds of applications might wait for more data not preloaded yet

and do not proceed. However it is better proceeding as far as the application could pro-

ceed than waiting until the data is entirely loaded unless the continuous preloading does

not hinder the progress of computation. Multiple applications may order pre-loading

their data at the same time and effective scheduling should be necessitated for pre-

loading in the environment without dedicated broadband network lines. Preloading of a

few applications could be granted due to the network bandwidth constraint.


12/12

556 M. Ok

References

1. Data Storage Devices and Systems Roadmap. In: DS2 Workshop, CA, Information StorageIndustry Consortium (2005)

2. Ok, M., Kim, D., Park, M.-s.: UbiqStor: A remote storage service for mobile devices. In:Liew, K.-M., Shen, H., See, S., Cai, W. (eds.) PDCAT 2004. LNCS, vol. 3320, pp. 685

688. Springer, Heidelberg (2004)

3. Block Device Driver Architecture,http://msdn.microsoft.com/library/en-us/wceddk40/html/

_ wceddk_system_architecture_for_block_devices.asp

4. Tierney, B., Johnston, W., Lee, J., Thompson, M.: A data intensive distributed computingarchitecture for Grid applications. Fut. Gen. Com. Sys. 16, 473481 (2000)

5. Clark, T.: IP SANs: A Guide to iSCSI, iFCP, and FCIP Protocols for Storage Area Net-works. Addison-Wesley, Reading (2002)

6. Lu, Y., Du, D.H.C.: Performance study of iSCSI-based storage subsystems. IEEE Com-munication Magazine 41, 7682 (2003)

7. Stockinger, H., Samar, A., Holtman, K., Allock, B., Foster, I., Tierney, B.: File and objectreplication in data grids. Cluster Comp. 5, 305314 (2002)

8. Yang, S., Ali, Z., Kettani, H., Verma, V., Malluhi, Q.: Network storage management indata Grid environment. In: Li, M., Sun, X.-H., Deng, Q.-n., Ni, J. (eds.) GCC 2003. LNCS,

vol. 3033, pp. 879886. Springer, Heidelberg (2004)

9. Xiao, N., Li, D., Fu, W., Huang, B., Lu, X.: GridDaen: a data grid engine. In: Li, M., Sun,X.-H., Deng, Q.-n., Ni, J. (eds.) GCC 2003. LNCS, vol. 3032, pp. 519528. Springer, Hei-

delberg (2004)

10. Talwar, V., Basu, S., Kumar, R.: Architecture and environment for enabling interactive

Grids. J. Grid Comp. 1, 231250 (2003)11. Allcock, B., Bester, J., Bresnahan, J., Chervenak, A.L., Foster, I., Kesselman, C., Meder,

S., Nefedova, V., Quesnel, D., Tuecke, S.: Data management and transfer in high-

performance computational grid environments. Para. Comp. 28, 749771 (2002)

12. Venugopal, S., Buyya, R., Ramamohanarao, K.: A taxonomy of Data Grids for distributeddata sharing, management, and processing. ACM CSUR 38(1) (2006)

13. Zissimos, A., Doka, K., Chazapis, A., Koziris, N.: GridTorrent: Optimizing data transfersin the Grid with collaborative sharing. In: Proc. Panhellenic Conference in Informatics,

Greece, May 2007, pp. 299309 (2007)

14. Hupfeld, F., Cortes, T., Kolbeck, B., Stender, J., Focht, E., Hess, M., Malo, J., Marti, J.,

Cesario, E.: The XtreemFS architecturea case for object-based file systems in Grids.Conc. Comp. 20(17), 20492060 (2008)

okmi09 - a sharable storage service for distributed computing

Documents