Filter
Top Products
2.2.4. Based on Standard Components
HPSS runs on UNIX and is written in ANSI C and Java. It uses remote procedure calls, a selectable
security service (Kerberos or UNIX), UNIX or LDAP for user configuration information, and DB2 as
the basis for its portable, distributed, transaction-based architecture. These components are offered on
many vendors’ platforms.
The full HPSS system has been implemented on IBM AIX and LINUX platforms, and some
components of HPSS have been ported to other platforms. Refer to Section 2.4: HPSS Hardware
Platforms on page 48 and Section 3.3: Prerequisite Software Considerations on page 58 for specific
information.
To aid vendors and users in porting HPSS to new platforms, HPSS source code is available.
2.2.5. Data Integrity Through Transaction Management
Transactional metadata management, provided by DB2, enables a reliable design that protects user
data both from unauthorized use and from corruption or loss. A transaction is an atomic grouping of
metadata management functions such that either all of them take place together or none of them takes
place. Journaling makes it possible to back out any partially complete transactions if a failure occurs.
Transaction technology is common in relational data management systems but not in storage systems.
It is the key to maintaining reliability and security while scaling upward into a large, distributed
storage environment.
2.2.6. Multiple Hierarchies and Classes of Services
Most other storage management systems support simple storage hierarchies consisting of one kind of
disk and one kind of tape. HPSS provides multiple configurable hierarchies, which are particularly
useful when inserting new storage technologies over time. As new disks or tapes are added, new
classes of service can be set up. HPSS files reside in a particular class of service which users select
based on parameters such as file size and performance. A class of service is implemented by a storage
hierarchy which in turn consists of multiple storage classes, as shown in Figure 2. Storage classes are
used to logically group storage media to provide storage for HPSS files. A hierarchy may be as
simple as a single tape, or it may consist of two or more levels of disk and local tape. The user can
even set up classes of service so that data from an older type of tape is subsequently migrated to a
new type of tape. Such a procedure allows migration to new media over time without having to copy
all the old media at once.
2.2.7. Storage Subsystems
Storage subsystems (or simply, “subsystems”) may be used to increase the scalability of HPSS in
handling concurrent requests or to meet local political needs. Each subsystem contains a single Core
Server. If migration and purge are needed for the subsystem, then it will also contain a Migration /
Purge Server. In addition, if HPSS is to be used as a backing store for a 'linked' filesystem such as
XFS, a DMAP Gateway will be required. All other servers are subsystem-independent.
Data stored within HPSS is assigned to different subsystems based on pathname resolution. A
pathname consisting of ‘/’ resolves to the root Core Server which is specified in the global
configuration file. However, if the pathname contains junction components, it may resolve to a Core
Server in a different subsystem. For example, the pathname ‘/JunctionToSubsys2/mydir’ could
lead to a fileset managed by the Core Server in subsystem 2. Sites which do not wish to partition their
HPSS through the use of subsystems will run HPSS with a single subsystem.
HPSS Installation Guide July 2008
Release 6.2 (Revision 2.0) 36