Non-Dce Client Gateway; Storage Subsystem Considerations; Storage Policy Considerations - IBM Hub/Switch Installation Manual

High performance storage system release 4.5
Table of Contents

Advertisement

must be in use before purging begins, and a lower bound specifying the target percentage of free
space to reach before purging is stopped.

2.6.17 Non-DCE Client Gateway

The Non-DCE Client Gateway provides HPSS access to applications running without DCE and/or
Encina which make calls to the Non-DCE Client API. It does this by calling the appropriate Client
APIs itself and returning the results to the client. Any system which wishes to make use of the Non-
DCE Client APIs must have a properly configured and running NDCG.
An HPSS installation can have multiple NDCG servers. A client can utilize a particular NDCG
server by setting its HPSS_NDCG_SERVERS environment variable with the hostname and port
of the target NDCG server.
The NDCG can be configured to support client authentication. A single NDCG can be configured
to support Kerberos and/or DCE authentication. The client requests one of the supported
authentication methods during the initial connection. Client authentication can also be completely
disabled on a NDCG server basis. In this case, the NDCG server believes the identity of the client
sent during the initial connection. When using DCE authentication, the DCE identity and password
are passed in an encrypted format from client to server during the initial connection. The NDCG
can be configured to support either DES or simple hashing function for encryption of the DCE
identity and password that is passed to the NDCG.
See Section 2.3.4.2: HPSS Non-DCE Mover/Client Machine on page 51 for more information on
prerequisites for a Non-DCE configuration.

2.7 Storage Subsystem Considerations

Storage subsystems have been introduced into HPSS for the purpose of increasing the scalability of
the system - particularly with respect to the name and bitfile servers. In releases prior to 4.2, an
HPSS system could only contain a single name and bitfile server. With the addition of storage
subsystems, an HPSS system must now contain one or more storage subsystems, and each storage
subsystem contains its own name and bitfile servers. If multiple name and bitfile servers are
desired, this is now possible by configuring an HPSS system with multiple storage subsystems.
A basic HPSS system contains a single storage subsystem. Additional storage subsystems allow the
use of multiple name and bitfile servers, but also introduce additional complexity in the form of
extra subsystems and servers being defined. Storage subsystems can also be used to increase
scalability with respect to SFS, but the price of this is that each storage subsystem requires its own
copies of several metadata files to support the servers in that subsystem. Finally, storage
subsystems provide a useful way to partition an HPSS system, though they also require that storage
resources be fragmented in order to support the multiple subsystems.

2.8 Storage Policy Considerations

This section describes the various policies that control the operation of the HPSS system.
HPSS Installation Guide
Release 4.5, Revision 2
September 2002
Chapter 2
HPSS Planning
81

Advertisement

Table of Contents
loading

This manual is also suitable for:

Hpss

Table of Contents