Table of Contents
Advertisement
Chapter 1
HPSS Basics
purge, and storage servers must now exist within a storage subsystem. Each storage subsystem
may contain zero or one gatekeepers to perform site specific user level scheduling of HPSS storage
requests or account validation. Multiple storage subsystems may share a gatekeeper. All other
servers continue to exist outside of storage subsystems. Sites which do not need multiple name and
bitfile servers are served by running an HPSS with a single storage subsystem.
Storage subsystems are assigned integer ids starting with one. Zero is not a valid storage subsystem
id as servers which are independent of storage subsystems are assigned to storage subsystem zero.
Storage subsystem ids must be unique. They do not need to be sequential and need not start with
one, but they do so by default unless the administrator specifies otherwise. Each storage subsystem
has a user-configurable name as well as a unique id. The name and id may be modified by the
administrator at the time the subsystem is configured but may not be changed afterward. In most
cases, the storage subsystem is referred to by its name, but in at least one case (suffixes on metadata
file names) the storage subsystem is identified by its id. Storage subsystem names must be unique.
There are two types of configuration metadata used to support storage subsystems: a single global
configuration record, and one storage subsystem configuration record per storage subsystem. The
global configuration record contains a collection of those configuration metadata fields which are
used by multiple servers and that are commonly modified. The storage subsystem records contain
configuration metadata which is commonly used within a storage subsystem.
It is possible to use multiple SFS servers within a single HPSS system. Multiple storage subsystems
are able to run from a single SFS server or using one SFS server per storage subsystem. In practice,
different metadata files may be located on different SFS servers on a per file basis depending on the
SFS path given for each file. For configuration and recovery purposes, however, it is desirable for
all of the metadata files for a single subsystem to reside on a single SFS server. This single SFS server
may either be a single server which supports the entire HPSS system, or it may support one or more
subsystems. Those metadata files which belong to the servers which reside within storage
subsystems are considered to belong to the storage subsystem as well. In an HPSS system with
multiple storage subsystems, there are multiple copies of these files, and the name of each copy is
suffixed with the integer id of the subsystem so that it may be uniquely identified (for example
bfmigrrec.1, bfmigrrec.2, etc.).
Metadata files that belong to a subsystem (i.e. files with numeric suffix) should never be shared
between servers. For example, the Bitfile Server in Subsystem #1 has a metadata file called
bfmigrrec.1. This file should only be used by the BFS in Subsystem #1, never by any other server.
The definitions of classes of service, hierarchies, and storage classes apply to the entire HPSS
system and are independent of storage subsystems. All classes of service, hierarchies, and storage
classes are known to all storage subsystems within HPSS. The level of resources dedicated to these
entities 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 bitfile server in that storage subsystem
never selects that class of service. If a class of service is enabled for a storage subsystem, then there
must be a non-zero level of storage resources supporting that class of service assigned to the storage
servers in that subsystem.
Data stored within HPSS is assigned to different Storage Subsystems based on pathname
resolution. A pathname consisting of "/" resolves to the root Name Server. The root Name Server is
the Name Server specified in the Global Configuration file. However, if the pathname contains
junction components, it may resolve to a Name Server in a different Storage Subsystem. For
example, the pathname "/JunctionToSubsys2" could lead to the root fileset managed by the Name
Server in Storage Subsystem 2. Sites which do not wish to partition their HPSS through the use of
30
September 2002
HPSS Installation Guide
Release 4.5, Revision 2
Advertisement
Table of Contents
