Filter
Top Products
Sites can choose to configure zero (0) or more Gatekeepers per HPSS system. Gatekeepers are
associated with storage subsystems. Each storage subsystem can have zero or one Gatekeeper
associated with it and each Gatekeeper can support one or more storage subsystems. Gatekeepers are
associated with storage subsystems using the Storage Subsystem Configuration screen (see Section
4.2: Storage Subsystems of the HPSS Management Guide). If a storage subsystem has no Gatekeeper,
then the Gatekeeper field will be blank. A single Gatekeeper can be associated with every storage
subsystem, a group of storage subsystems, or one storage subsystem. A storage subsystem can NOT
use more than one Gatekeeper.
Every Gatekeeper has the ability to supply the Account Validation Services. A bypass flag in the
Accounting Policy metadata indicates whether or not Account Validation for an HPSS system is on
or off. Each Gatekeeper will read the Accounting Policy metadata file, so if multiple Gatekeepers are
configured and Account Validation has been turned on, then any Gatekeeper can be chosen by the
Location Server to fulfill Account Validation requests.
Every Gatekeeper has the ability to supply the Gatekeeping Service. The Gatekeeping Service
provides a mechanism for HPSS to communicate information through a well-defined interface to a
policy software module to be completely written by the site. The site policy code is placed in a well-
defined site shared library for the gatekeeping policy (/opt/hpss/lib/libgksite.[a|so]) which is linked
to the Gatekeeper. The gatekeeping policy shared library contains a default policy which does NO
gatekeeping. Sites will need to enhance this library to implement local policy rules if they wish to
monitor and/or load balance requests.
The gatekeeping site policy code will determine which types of requests it wants to monitor
(authorized caller, create, open, and stage). Upon initialization, each Core Server will look for a
Gatekeeper in the storage subsystem metadata. If no Gatekeeper is configured for a particular storage
subsystem, then the Core Server in that storage subsystem will not attempt to connect to any
Gatekeeper. If a Gatekeeper is configured for the storage subsystem that the Core Server is
configured for, then the Core Server will query the Gatekeeper asking for the monitor types by
calling a particular Gatekeeping Service API. This API will then call the appropriate Site Interface
which each site can provide to determine which types of requests are to be monitored. This query by
the Core Server will occur each time the Core Server (re)connects to the Gatekeeper. The Core Server
will need to (re)connect to the Gatekeeper whenever the Core Server or Gatekeeper is restarted. Thus
if a site wants to change the types of requests it is monitoring, then it will need to restart the
Gatekeeper and Core Server.
If multiple Gatekeepers are configured for gatekeeping, then the Core Server that controls the files
being monitored will contact the Gatekeeper that is located in the same storage subsystem.
Conversely if one Gatekeeper is configured for gatekeeping for all storage subsystems, then each
Core Server will contact the same Gatekeeper.
A Gatekeeper registers five different interfaces: Gatekeeper Services, Account Validation Services,
Administrative Services, Connection Manager Services, and Real Time Monitoring Services. When
the Gatekeeper initializes, it registers each separate interface. The Gatekeeper specific configuration
will contain any pertinent data about each interface.
The Gatekeeper Service interface provides the Gatekeeping APIs which calls the site implemented
Site Interfaces. The Account Validation Service interface provides the Account Validation APIs. The
Administrative Service provides the server APIs used by SSM for viewing, monitoring, and setting
server attributes. The Connection Manager Service provides the HPSS connection management
interfaces. The Real Time Monitoring Service interface provides the Real Time Monitoring APIs.
The Gatekeeper Service Site Interfaces provide a site the mechanism to create local policy on how to
throttle or deny create, open and stage requests and which of these request types to monitor. For
example, it might limit the number of files a user has opened at one time; or it might deny all create
HPSS Installation Guide July 2008
Release 6.2 (Revision 2.0) 85