Chapter 1 HPSS BasicsHPSS Installation Guide September 2002 31Release 4.5, Revision 2Storage Subsystems will effectively be running an HPSS with a single Storage Subsystem. Note thatsites are not required to use multiple Storage Subsystems.Since the migration/purge server is contained within the storage subsystem, migration and purgeoperate independently in each storage subsystem. If multiple storage subsystems exist within anHPSS, then there are several migration/purge servers operating on each storage class. Eachmigration/purge server is responsible for migration and purge for those storage class resourcescontained within its particular storage subsystem. Migration and purge runs are independent andunsynchronized. This principle holds for other operations such as repack and reclaim as well.Migration and purge for a storage class may be configured differently for each storage subsystem.It is possible to set up a single migration or purge policy which applies to a storage class across allstorage subsystems (to make configuration easier), but it is also possible to control migration andpurge differently in each storage subsystem.Storage class thresholds may be configured differently for each storage subsystem. It is possible toset up a single set of thresholds which apply to a storage class across all storage subsystems, but itis also possible to control the thresholds differently for each storage subsystem.1.3.4 HPSS InfrastructureThe HPSS infrastructure items (see Figure 1-3) are those components that “glue together” thedistributed servers. While each HPSS server component provides some explicit functionality, theymust all work together to provide users with a stable, reliable, and portable storage system. TheHPSS infrastructure components common among servers that tie servers together are discussedbelow.• Distributed Computing Environment (DCE). HPSS uses the Open Software Foundation'sDistributed Computing Environment (OSF DCE) as the basic infrastructure for itsarchitecture and high-performance storage system control. DCE was selected because of itswide adoption among vendors and its near industry-standard status. HPSS uses the DCERemote Procedure Call (RPC) mechanism for control messages and the DCE Threadspackage for multitasking. The DCE Threads package is vital for HPSS to serve largenumbers of concurrent users and to enable multiprocessing of its servers. HPSS also usesDCE Security as well as Cell and Global Directory services.Most HPSS servers, with the exception of the MVR, PFTPD, and logging services (seebelow), communicate requests and status (control information) via RPCs. HPSS does not useRPCs to move user data. RPCs provide a communication interface resembling simple, localprocedure calls.• Transaction Management. Requests to perform actions, such as creating bitfiles oraccessing file data, result in client-server interactions between software components. Theproblem with distributed servers working together on a common job is that one server mayfail or not be able to do its part. When such an event occurs, it is often necessary to abortthe job by backing off all actions made by all servers on behalf of the job.Transactional integrity to guarantee consistency of server state and metadata is required inHPSS in case a particular component fails. As a result, a product named Encina, fromTransarc Corporation, was selected to serve as the HPSS transaction manager. Thisselection was based on functionality and vendor platform support. Encina provides begin-commit-abort semantics, distributed two-phase commit, and nested transactions. It