2.3.3. HPSS Storage Subsys tems
The goal of storage subsystems (or just “subsystems”) is to increase the scalabilit y of HPSS by
allowing multiple Core Servers to be used within a single HPSS system. Every HPSS system is
partitioned into one or more subsystems. Each subsystem contains a single Core Server. If migration
and purge are needed, then the subsystem should contain a single Migration/Purge Server. Each Core
Server and each Migration/Purge Server must exist within a storage subsystem. Each subsystem may
optionally be serviced by a Gatekeeper which performs site-specific user-level scheduling of HPSS
storage requests or account validation. Each Gatekeeper may service multiple subsystems. If a
subsystem wishes to utilize XDSM filesets, a DMAP Gateway must also be configured. Only one
DMAP Gateway is needed for multiple subsystems. All other servers exist independently of storage
subsystems. Sites which do not need multiple Core Servers use a single storage subsystem.
The computer that runs the Core Server for subsystem X is referred to as the “Subsystem X node”,
while the computer running the Root Core Server is known as the “Root Subsystem Node”.
Each HPSS system consists of two types of DB2 databases. The global database contains subsystem-
independent data, and a subsystem database contains subsystem-dependent data. An HPSS system
has exactly one global database and one or more subsystem databases.
The definitions of classes of service, hierarchies, and storage classes apply to the entire HPSS system
(they are subsystem-independent). All classes of service, hierarchies, and storage classes are known
to all storage subsystems within HPSS. The level of resources dedicated to these entit ies by each
storage subsystem may differ. It is possible to disable selected classes of service within given storage
subsystems. Although the class of service definitions are global, if a class of service is disabled
within a storage subsystem then the Core Server in that subsystem never selects that class of service.
Since the Migration/Purge Server (MPS) is contained within the storage subsystem, migration and
purge operate independently in each subsystem. Each Migration/Purge Server is responsible for
migration and purge for those storage class resources contained within its particul ar storage
subsystem. Migration and purge runs are independent and are not synchronized. 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 all storage subsystems (t o
make configuration easier), but it is also possible to control migration and purge differ ently in each
storage subsystem.
Similarly, storage class thresholds may be configured differently for each storage subsystem. It is
possible to set up a single set of thresholds which apply to a storage class across all storage
subsystems, but it is also possible to control the thresholds differentl y for each storage subsystem.
2.3.4. HPSS Infrastructu re
The HPSS infrastructure items (see Figure 3) are those components and services used by the various
HPSS servers. The HPSS infrastructure components common among servers are discussed below.
•Remote Procedure Calls (RPC). 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.
•Thread Services. HPSS uses a threads package for multitasking. The threads package is vital
for HPSS to serve large numbers of concurrent users and to enable multiprocessing of its
servers.
•Transaction Management. Requests to perform actions, such as creating bitfiles or
accessing file data, result in client-server interactions between software components. The
HPSS Installation Guide July 2008
Release 6.2 (Revision 2.0) 44