okmi09 - a sharable storage service for distributed computing
TRANSCRIPT
-
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
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
-
8/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing
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
-
8/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing
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.
-
8/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing
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
-
8/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing
5/12
A Sharable Storage Service for Distributed Computing Systems 549
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
-
8/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing
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
-
8/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing
7/12
A Sharable Storage Service for Distributed Computing Systems 551
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
DataData Data Data Data
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/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing
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
DataData Data Data Data
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
-
8/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing
9/12
A Sharable Storage Service for Distributed Computing Systems 553
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.
-
8/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing
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,
-
8/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing
11/12
A Sharable Storage Service for Distributed Computing Systems 555
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.
-
8/3/2019 OkMi09 - A Sharable Storage Service for Distributed Computing
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)