| NAS Environment (continued)
Description of NAS
Elements of a NAS
Configuration
A NAS-based system could be constructed of
equipment and software from many different vendors. Its constituents collaborate in a way
that should make it appear to the world outside as one large computer system. As NAS is
used in this paper, four components constitute a NAS architecture: OODs, Requesters, a
File Server, and the Interconnect.
The Object Oriented
Devices are the storage components of the system. They include disc drives, RAID
subsystems, tape drives, tape libraries, optical drives, jukeboxes, and any other storage
devices to be shared. They must have an I/O channel attachment to the Requesters that will
access them.
The Requesters are
the servers or clients sharing and directly accessing the OODs.
A File Server
performs management and security functions such as request authentication and resource
location. It is key to the self-management capability of NAS. The OODs depend on it for
management direction, while the Requesters are relieved of storage management to the
extent the File Server assumes that responsibility. In smaller systems, a dedicated File
Server might not be feasible; a Requester may take on the responsibility for overseeing
the operation of the NAS environment. Where the security and flexibility that the File
Server brings are not desired or where an overriding need for performance calls for the
cluster of Requesters to talk directly with – and only with – the OODs, a File
Server might not be present.
The Interconnect is
the physical infrastructure through which all NAS components communicate. It must have
properties of both networks and channels. It must have distance and addressability
adequate to connect all components in the networks; it must also have the low latency and
flow control properties of a channel. It must have the manageability features of mainframe
class peripherals.
Figure 3:
NAS Configuration
Overview of NAS
Operation
Startup
When the NAS is powered
up, all devices must identify themselves either to each other or to a common point of
reference, such as the File Server or the Interconnect. The Interconnect offers network
management techniques to be used for this. For instance, in a Fibre Channel based NAS, the
OODs and Requesters would log onto the fabric. Any component wanting to determine the
operating configuration could use fabric services to identify all other components. From
the File Server, the Requesters learn of the existence of the storage devices they could
have access to, while the OODs learn where to go when they need to locate another device
or invoke a management service like backup. Similarly the File Server can learn of the
existence of OODs from the fabric services.
Depending on the security
practice of a particular installation, a Requester may be denied access to some equipment.
From the set of accessible storage devices, it can then identify the files, databases, and
free space available.
At the same time, each NAS
component can identify to the File Server any special considerations it would like known.
Any device level service attributes could be communicated once to the File Server, where
all other components could learn of them. For instance, a Requester may wish to be
informed of the introduction of additional storage subsequent to startup, this being
triggered by an attribute set when the Requester logs onto the File Server. The File
Server could do this automatically whenever new OODs are added to the configuration,
including conveying important characteristics, such as it being RAID 5, mirrored, and so
on.
Accessing
NAS
When a Requester must open
a file, it may be able to go directly to the OODs or it may have to go to the File Server
for permission and location information. To what extent the File Server controls access to
storage is a function of the security requirements of the installation.
First, let's consider the
case where the installation is physically secure. That is, there is not a requirement to
protect the transmission of command and data between a Requester and the OODs. There might
still be a File Server present for management functions, but one that does not oversee the
Requester I/O.
Here a Requester is in a
position to access and create objects directly on an OOD. It can open, read, write and
close objects just as if they were natively attached to the Requester.
A typical sequence might
go something like this. The Requester reads from an OOD one or more well-known objects
that reveal the logical volumes or partitions of the device (more on this later) and how
to start looking at objects. The Requester then opens and reads an object, which might be
a root directory. From this, it is straightforward to find other objects, based on the
contents of the directory. The Requester repeats the process until the desired data is
located. This can be accessed just like any file on a BOD, the difference being that the data is
referenced by the Object ID and a displacement within the object, not an LBA (logical
block address) whose address is relative to the start of the storage device.
Figure 4:
Read Object Sequence
In the second case, where
security is required, the File Server interposes itself into the I/O chain to the degree
necessary for the desired level of protection. A Requester must first go to the File
Server for permission to perform a set of I/O operations. (The File Server may well also
withhold the OODs location information from the Requesters at initialization time in
support of the security requirement.) The File Server accredits the request by returning
sufficient information to allow the Requester to communicate directly with an OOD.
The OODs will also be
informed of the installation security policy when they log into the File Server. Based on
this, they will not allow an I/O request unless it is properly constructed –
including encoded with a valid permission. All NAS elements collaborate to enforce the
security of the system.
Security requirements may
demand both protecting data while in flight – using encryption – and validation
of requests against security criteria at the OODs before servicing.
Figure 5:
Read Object Sequence using File Server
Though the sequence of
operations seems quite similar to the first case, they are quite different, especially in
terms of the payloads associated with each command. In the secure case, both commands and
data may be encrypted. In addition, the permission information must be added to the
command parameters.
Data Sharing and
Concurrent Update
NAS proposes solving the
data-sharing problem by moving to an optimistic control scheme where Requesters can act as
though there is no conflict unless there is actually simultaneous attempts to access the
same records by multiple Requesters. They learn this from the OODs themselves when
attempting to commit updates. An attribute can be set by a Requester to establish that it
intends to update certain data. The attribute is reset after completion of the writes.
Only if another Requester attempts to update data for which the attribute is set is there
a need to resolve a conflict. This approach should greatly reduce the inter-system traffic
database servers generate today to maintain data consistency.
When the cluster starts
up, all Requesters can open the shared data base objects and are ready to update them.
Attribute bits can be used to indicate the appropriate granularity of control. With
something like VIA compliant host interfaces, it will
even be possible for applications to directly establish integrity control.
Differences with CMU
Carnegie Mellon University
has published extensive descriptions of their view of NASD and their research on the subject.
While Seagate is a supporter of that work and one of its principal sponsors, there are
some differences in perspective that should be made clear.
A primary motive for NAS
at CMU is the elimination of the server bottleneck. For high data rate applications, if
the clients can communicate directly with the storage devices, the data need not suffer
the bandwidth loss associated with traveling through a server. While this has some
application in the marketplace, such as in collaborative video editing, the need we hear
about from our customers is for servers to share data.
CMU also advocates the
prospect of any client anywhere talking with any storage device anywhere. As a disc and
tape device manufacturer, we see this as a problem. It opens up the door for huge numbers
of clients accessing a single disc drive simultaneously for arbitrarily long periods.
While this might be possible, it is not something we hear from customers as needed.
Moreover it flies in the face of the fundamental design philosophy of a drive. A disc
drive is intended to be a limited resource device. The buyers of disc drives expect them
to be as low priced as possible. The electronics of a drive is architected with this
requirement in mind. Essentially making a server of a drive leaves the expectation that
the drive has the properties of a server, namely that it can support very large numbers of
connections of infinite duration. Adding even small amounts of additional hardware –
if not needed – to a drive adds significant unacceptable cost due to the
multiplicative effect of large numbers of drives on a system. Rather, the shared storage
and storage management shortcomings of servers are what are cited as barriers to progress.
Fortunately, the
differences in perspective do not result in substantively different views of the problems
nor in different research topics.
|
