requests from a particular host or user. The Site Interfaces will be located in a shared library that is
linked into the Gatekeeper.
It is important that the Site Interfaces return a status in a timely fashion. Create, open, and stage
requests from MPS are timing sensitive, thus the Site Interfaces won't be permitted to delay or deny
these requests, however the Site Interfaces may choose to be involved in keeping statistics on these
requests by monitoring requests from Authorized Callers.
If a Gatekeeper should become heavily loaded, additional Gatekeepers can be configured (maximum
of one Gatekeeper per storage subsystem). In order to keep the Gatekeepers simple and fast, they do
not share state information. Thus if a site wrote a policy to allow each host a maximum of 20 creates,
then that host would be allowed to create 20 files on each storage subsystem that ha s a separate
Gatekeeper.
The Gatekeeper’s Real Time Monitoring Interface supports clients such as a Real Time Monitoring
utility which requests information about particular user files or HPSS Request Ids.
3.7.4. Location Server
All HPSS client API applications, which includes all end user applications, will need to contact the
Location Server at least once during initialization and usually later during exe cution in order to locate
the appropriate servers to contact. If the Location Server is down for an extended lengt h of time,
these applications will eventually give up retrying their requests and become non-operational. To
avoid letting the Location Server become a single point of failure, consider replicat ing it, preferably
on a different node. If replicating the Location Server is not an option or desirable , consider
increasing the automatic restart count for failed servers in SSM. Since the Location Server’s requests
are short lived, and each client contacts it through a cache, performance alone is not usually a reason
to replicate the Location Server. Generally the only time a Location Server should be repl icated
solely for performance reasons is if it is reporting heavy load conditions to SSM.
If any server is down for an extended length of time it is important to mark the server as non-
executable within SSM. As long as a server is marked executable the Location Server continues to
advertise its location to clients which may try to contact it.
The Location Server must be reinitialized or recycled whenever the Location Policy or its
server configuration is modified. Note that it is not necessary to re cycle the Location Server
if an HPSS server’s configuration is added, modified, or removed since this information is
periodically reread.
3.7.5. PVL
The PVL is responsible for mounting and dismounting PVs (such as tape and magnetic disk) and
queuing mount requests when required drives and media are in use. The PVL usually receives
requests from Core Server clients. The PVL accomplishes any physical movement of media that
might be necessary by making requests to the appropriate Physical Volume Repository (PVR). The
PVL communicates directly with HPSS Movers in order to verify media labels.
The PVL is not required to be co-resident with any other HPSS servers and is not a CPU-intensive
server. With its primary duties being queuing, managing requests, and association of physical
volumes with PVRs, the PVL should not add appreciable load to the system.
In the current HPSS release, only one PVL will be supported.
3.7.6. PVR
The PVR manages a set of imported cartridges, mounts and dismounts them when requested by the
HPSS Installation Guide July 2008
Release 6.2 (Revision 2.0) 86