Chapter 1 HPSS Basics
HPSS Installation Guide September 2002 31
Release 4.5, Revision 2
StorageSubsystems will effectively be running an HPSS with a single Storage Subsystem. Note that
sites are not required to use multiple Storage Subsystems.
Sincethe migration/purge server is contained within the storage subsystem, migration and purge
operate independently in each storage subsystem. If multiple storage subsystems exist within an
HPSS, then there are several migration/purge servers operating on each storage class. Each
migration/purge server is responsible for migration and purge for those storage class resources
containedwithin its particular storage subsystem. Migration and purge runs are independent and
unsynchronized. This principle holds for other operations such as repack and reclaim as well.
Migrationand purge for a storage class may be configured differently for each storage subsystem.
Itis possible to set up a single migration or purge policy which applies to a storage class across all
storage subsystems (to make configuration easier), but it is also possible to control migration and
purge differently in each storage subsystem.
Storageclass thresholds may be configured differently for each storage subsystem. It is possible to
setup a single set of thresholds which apply to a storage class across all storage subsystems, but it
is also possible to control the thresholds differently for each storage subsystem.
1.3.4 HPSS Infrastructure
The HPSS infrastructure items (see Figure 1-3) are those components that “glue together” the
distributedservers. While each HPSS server component provides some explicit functionality, they
must all work together to provide users with a stable, reliable, and portable storage system. The
HPSS infrastructure components common among servers that tie servers together are discussed
below.
•Distributed Computing Environment (DCE). HPSS uses the Open Software Foundation's
Distributed Computing Environment (OSF DCE) as the basic infrastructure for its
architectureand high-performance storage system control. DCE was selected because of its
wideadoption among vendors and its near industry-standard status. HPSS uses the DCE
Remote Procedure Call (RPC) mechanism for control messages and the DCE Threads
package for multitasking. The DCE Threads package is vital for HPSS to serve large
numbers of concurrent users and to enable multiprocessing of its servers. HPSS also uses
DCE Security as well as Cell and Global Directory services.
Most HPSS servers, with the exception of the MVR, PFTPD, and logging services (see
below),communicate requests and status (control information) via RPCs. HPSS does not use
RPCs to move user data. RPCs provide a communication interface resembling simple, local
procedure calls.
•Transaction Management.Requests to perform actions, such as creating bitfiles or
accessing file data, result in client-server interactions between software components. The
problemwith distributed servers working together on a common job is that one server may
fail or not be able to do its part. When such an event occurs, it is often necessary to abort
the job by backing off all actions made by all servers on behalf of the job.
Transactionalintegrity to guarantee consistency of server state and metadata is required in
HPSS in case a particular component fails. As a result, a product named Encina, from
Transarc Corporation, was selected to serve as the HPSS transaction manager. This
selectionwas based on functionality and vendor platform support. Encina provides begin-
commit-abort semantics, distributed two-phase commit, and nested transactions. It