A year or two ago, Transarc, the supplier of AFS, had submitted a new version
of AFS (version 4) to the Open Software Foundation (OSF) for consideration
as the file system for their Distributed Computing Environment (DCE). The
submission was warmly received and accepted as the as OSF's standard Distributed
File System (DFS). DFS is expected to become widely available from vendors
such as DEC, IBM, and HP in late 1993. We will most likely to be cutting
over to this new and much improved file
Unfortunately, the conversion from AFS to DFS will not be straightforward.
Significant structural changes have been made to the current version of
AFS. The Application Programming Interface (API) has also undergone substantial
modifications. Any program written based upon assumptions of the specific
internal structure of AFS 3 will most likely break. This is the case with
virtually all the current locally
Our alternatives are to (a) wait for DFS to become stable and modify all
those applications accordingly or (b) take the opportunity to address the
more fundamental architectural issue of a completely new file system dependent
distributed services environment.
We decided on the latter approach. In the new scenario, the file system
is one of many services attached to the network. Other services would include
printing, mail, backup, authentication, directory services, etc. In a ideal
situation, all services will be equal to each other with little or no cross
dependency upon one another.
Hence, if a service fails, the client will be denied of that, and only
that, service. All other services on the network should still be available.
This is not actually a novel concept. It closely approximates that of the
Macintosh networking environment. Our challenge is to make it scalable
providing services ACROSS THE campus community instead of to a localized
work group.
File service will be provided mainly by DFS.
Printing services will be enhanced to provide for better monitoring of
usage and control. Users should also be able to direct their output to
any desired printer, subject to compatibility, access privileges and other
controls as defined by the owner of the equipment.
Remote backup and archival services will be provided for owners of workstations,
Macintoshes and PCs. Backup is the means to provide a general safeguard
against disk failure, while archiving is DONE AT THE explicit request of
a user to backup specific components. As the usage of multimedia increases,
automatic migration of data from disk to optical storage technology, based
on usage, will also be considered.
Mail and BBoard services will be redesigned to be structurally more modular,
substantially reducing or removing altogether their dependency on the central
file system. More focus will be placed on improving basic capabilities
such as distribution list handling, attachments, etc.
The configuration of the UNIX workstation will fall into two categories:
network dependent and network independent. Network dependent workstations
would function the same way as the Andrew workstations today. They would
likely be the configuration of choice for cluster workstations. Network
independent workstations would have adequate local disk space to support
standalone operation if necessary. Provisions will be made to allow users
to move software packages from appropriate servers easily into the local
disk, subject to licensing constraints. An intriguing area we will address
is <169>network docking.<170> When a network independent workstation, such
as a laptop or notebook machine, is reconnected to the network, a user-definable
set of activities will happen automatically. Hence the user will be advised
if the software packages on his or her machine is out of date, spooled
print jobs will automatically flow into the network, archival request and
backup will happen, the user will be informed of pending mail, etc.
Note that because the servers will have minimum cross dependencies upon
one another, any organization in the university should be able to bring
up its own servers relatively easily. Access to those servers would, of
course, be by the grace of their providers.
The above project is fairly extensive in scope. Instead of approaching
it alone, we have made considerable effort to form partnerships with other
departments on campus, other universities and corporations. Besides getting
potential human and/or financial support for our work, we would very much
like to get long term support for our products from other quarters.
.
Service Overview
A brief overview of the main services we will be providing follows.
Approaches
This time around, we will be approaching the problems somewhat differently
than the original Andrew project. While UNIX workstation support will remain
a key element of this distributed computing environment, we will take providing
service to Macintoshes and PCs into consideration from the outset. We will
also explore the use of public domain and commercial components either
directly or as a base for development whenever possible. Our challenge
will be the graceful integration of the parts to form a relatively seamless
and easy to Timelines
The Computing & Communications Development groups have started working
on this project indirectly since last Fall. The first objective is to achieve
a stable, reliable, environment that performs reasonably and, most importantly,
requires low maintenance so that more developers can be put onto the Phase
II project. We have substantially achieved that goal. While we will continue
to enhance the current Andrew environment, such as by providing support
for new versions of operating systems and/or new platforms and increasing
service capacities, most of the focus will be diverted to Andrew II. Because
of the principle of minimum cross dependencies between servers, components
of Andrew II will be introduced as they become available over the next
two years. Indeed, one may consider LIS II, the recently introduced electronic
library service derived from the Mercury project, as the first component
of this new phase. For components that would be changed between Andrew
I and Andrew II, careful considerations will be taken to ensure the migration
occurs smoothly. The last component to be changed will likely be the cause
of this whole exercise itself: AFS to DFS. That should happen no earlier
than 1994. Finally, we are in the early phase of the Andrew II project
definition. We would welcome the participation of anyone who may be able
to contribute to the effort. For more information, please send mail to
john.leong@cmu.edu.