Hub/Switch Installation Guide

Chapter 1 HPSS Basics

HPSS Installation Guide September 2002 31

Release 4.5, Revision 2

StorageSubsystemswilleffectivelyberunningan HPSSwithasingleStorageSubsystem.Notethat

sites are not required to use multiple Storage Subsystems.

Since themigration/purge server is containedwithin the storagesubsystem, migration andpurge

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

contained withinits particular storage subsystem. Migrationand purge runs are independent and

unsynchronized. This principle holds for other operations such as repack and reclaim as well.

Migration and purge for a storage class may be conﬁgured differently for each storage subsystem.

It is possible to set up a single migration or purge policy which applies to a storage class across all

storage subsystems (to make conﬁguration easier), but it is also possible to control migration and

purge differently in each storage subsystem.

Storage classthresholdsmay be conﬁgured differentlyfor each storage subsystem. Itis possible to

set up a single set of thresholds which apply to a storage class across all storagesubsystems, 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

distributed servers. 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

architectureandhigh-performancestoragesystemcontrol.DCEwasselectedbecauseofits

wide adoption 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),communicaterequestsandstatus(controlinformation)viaRPCs.HPSSdoesnotuse

RPCs to move user data. RPCs provide a communication interface resembling simple, local

procedure calls.

• Transaction Management. Requests to perform actions, such as creating bitﬁles or

accessing ﬁle data, result in client-server interactions between software components. The

problemwithdistributedserversworkingtogetheronacommonjobisthatoneservermay

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.

Transactional integritytoguarantee consistencyofserver stateandmetadata isrequiredin

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

selection was basedon functionalityand vendor platform support. Encina provides begin-

commit-abort semantics, distributed two-phase commit, and nested transactions. It