Database Reference
In-Depth Information
4.5.1 Challenges of Remote I/O
An ideal remote I/O system allows an unmodified application to access remote
files in the exact same way as local files, differing perhaps only in performance
and naming. That is, a user ought to be able to take any existing application
and attach it to a remote I/O system without requiring any changes to the
code or the local computing system.
In order to design a suitable remote I/O system for an application, we must
address each of the following design challenges:
How should the application be attached to the remote I/O sys-
tem? Distributed file systems such as the network file system (NFS) 74 and
AFS 44 rely on kernel-level drivers and configuration in order to redirect ap-
plications to remote services. As a result, these traditional systems cannot
be used in large-scale distributed systems where the end user is harnessing
machines from multiple independent domains without any help from the local
administrator. Instead, we must find a user-level mechanism for attaching the
application to the remote I/O system.
One way to perform this attachment is by modifying libraries. If the appli-
cation is written to use a middleware library like MPI-IO, 81 then that library
can be modified to perform remote I/O as in RIO. 31 Another technique is to
replace the standard C library. This can be done by recompiling the appli-
cation, as in Condor, 58 or by preloading dynamic libraries as in Bypass 79 or
XUnion. 83 Each of these techniques is effective on a subset of applications,
but none applies to all possible binaries. For these reasons, we recommend
the use of the ptrace interface, described below, for attaching applications to
a remote I/O system.
What protocol should be used for remote I/O? A variety of data
transfer protocols are in use on the Internet today. Unfortunately, few are di-
rectly suitable for carrying small I/O operations over the network. HTTP 26 is
designed for moving entire files, and has no facilities for querying or managing
directories. FTP 69 and variants such as GridFTP 5 provide some directory ca-
pabilities, but are also focused on large-scale data movement, requiring a new
TCP connection for every open file. For the typical application that opens hun-
dreds or thousands of files to access executables, libraries, and data files, one
TCP connection for each file results in poor performance and possibly resource
exhaustion. NFS 74 and its many variants 6 , 9 , 27 , 32 , 43 would appear to be more
well suited, but the NFS protocol is dicult to disentangle from a kernel-level
implementation, due to the use of persistent numeric file handles to identify
files. For these reasons, we recommend that remote I/O requires a custom
network protocol that corresponds more closely to the Unix I/O interface.
What security mechanisms are needed for remote I/O? A tradi-
tional Unix file system has very limited security mechanisms, in which users
are identified by integers, and a total of nine mode bits are used to specify ac-
cess controls. A remote I/O system used in the context of a larger distributed
system must have more sophisticated kinds of access control. Multiple users
Search WWH ::




Custom Search