Computer Drive User Manual
Table Of Contents
- Chapter 1. HPSS 7.1 Configuration Overview
- Chapter 2. Security and System Access
- Chapter 3. Using SSM
- 3.1. The SSM System Manager
- 3.2. Quick Startup of hpssgui
- 3.3. Configuration and Startup of hpssgui and hpssadm
- 3.4. Multiple SSM Sessions
- 3.5. SSM Window Conventions
- 3.6. Common Window Elements
- 3.7. Help Menu Overview
- 3.8. Monitor, Operations and Configure Menus Overview
- 3.9. SSM Specific Windows
- 3.10. SSM List Preferences
- Chapter 4. Global & Subsystem Configuration
- 4.1. Global Configuration Window
- 4.2. Storage Subsystems
- 4.2.1. Subsystems List Window
- 4.2.2. Creating a New Storage Subsystem
- 4.2.3. Storage Subsystem Configuration Window
- 4.2.3.1. Create Storage Subsystem Metadata
- 4.2.3.2. Create Storage Subsystem Configuration
- 4.2.3.3. Create Storage Subsystem Servers
- 4.2.3.4. Assign a Gatekeeper if Required
- 4.2.3.5. Assign Storage Resources to the Storage Subsystem
- 4.2.3.6. Create Storage Subsystem Fileset and Junction
- 4.2.3.7. Migration and Purge Policy Overrides
- 4.2.3.8. Storage Class Threshold Overrides
- 4.2.4. Modifying a Storage Subsystem
- 4.2.5. Deleting a Storage Subsystem
- Chapter 5. HPSS Servers
- 5.1. Server List
- 5.1. Server Configuration
- 5.1.1. Common Server Configuration
- 5.1.1. Core Server Specific Configuration
- 5.1.2. Gatekeeper Specific Configuration
- 5.1.3. Location Server Additional Configuration
- 5.1.4. Log Client Specific Configuration
- 5.1.1. Log Daemon Specific Configuration
- 5.1.2. Migration/Purge Server (MPS) Specific Configuration
- 5.1.3. Mover Specific Configuration
- 5.1.3.1. Mover Specific Configuration Window
- 5.1.3.1. Additional Mover Configuration
- 5.1.3.1.1. /etc/services, /etc/inetd.conf, and /etc/xinetd.d
- 5.1.3.1.2. The Mover Encryption Key Files
- 5.1.3.1.3. /var/hpss/etc Files Required for Remote Mover
- 5.1.3.1.1. System Configuration Parameters on IRIX, Solaris, and Linux
- 5.1.3.1.1. Setting Up Remote Movers with mkhpss
- 5.1.3.1.2. Mover Configuration to Support Local File Transfer
- 5.1.1. Physical Volume Repository (PVR) Specific Configuration
- 5.1.1. Deleting a Server Configuration
- 5.1. Monitoring Server Information
- 5.1.1. Basic Server Information
- 5.1.1. Specific Server Information
- 5.1.1.1. Core Server Information Window
- 5.1.1.1. Gatekeeper Information Window
- 5.1.1.1. Location Server Information Window
- 5.1.1.2. Migration/Purge Server Information Window
- 5.1.1.3. Mover Information Window
- 5.1.1.1. Physical Volume Library (PVL) Information Window
- 5.1.1.2. Physical Volume Repository (PVR) Information Windows
- 5.1. Real-Time Monitoring (RTM)
- 5.2. Starting HPSS
- 5.1. Stopping HPSS
- 5.2. Server Repair and Reinitialization
- 5.1. Forcing an SSM Connection
- Chapter 6. Storage Configuration
- 6.1. Storage Classes
- 6.2. Storage Hierarchies
- 6.3. Classes of Service
- 6.4. Migration Policies
- 6.5. Purge Policies
- 6.6. File Families
- Chapter 7. Device and Drive Management
- Chapter 8. Volume and Storage Management
- 8.1. Adding Storage Space
- 8.2. Removing Storage Space
- 8.3. Monitoring Storage Space
- 8.4. Dealing with a Space Shortage
- 8.5. Volume Management
- 8.6. Monitoring and Managing Volume Mounts
- 8.7. New Storage Technology Insertion
- Chapter 9. Logging and Status
- Chapter 10. Filesets and Junctions
- Chapter 11. Files, Directories and Objects by SOID
- Chapter 12. Tape Aggregation
- Chapter 13. User Accounts and Accounting
- Chapter 14. User Interfaces
- Chapter 15. Backup and Recovery
- Chapter 16. Management Tools
made to the database. These logs allow DB2 to recover all changes made to the database since the time
of the last database backup, forward to the time when DB2 was stopped by a crash, hardware failure,
power outage or whatever. It is vital that the DB2 log files be hosted on a highly reliable disk systems.
Furthermore, DB2 log mirroring must be used to protect this information on two separate disk systems.
The disks systems must also be protected using RAID 1 or RAID 5 configurations. Reliable access to the
log files is more important than performance. Loss of the DB2 log files can result in a significant impact
to the operation of the system, extensive downtime to repair, and potential loss of end-user data. Proper
protection of the DB2 log files and associated archived backups is critical to a site's HPSS operations.
Similarly, the HPSS administrator must regularly verify that completed DB2 log files are being stored on
reliable media until they are no longer needed. Many sites make multiple copies of DB2 log files and
store them in separate physical locations.
In case of a catastrophic failure of the HPSS database host computer, the database can be restored to a
consistent state at the point in time of the failure, if the administrator has a reliable series of backup
images and log files. After the failure that caused the database failure is corrected, the HPSS databases
can be restored using the backup files, and then by replaying the DB2 log files. Much of this process
happens automatically when DB2 is restarted, but if you have any questions about these requirements and
procedures, please contact your HPSS Support Representative.
Another responsibility of the HPSS administrator is to periodically perform RUNSTATS operations on
the database tables. RUNSTATS is a DB2 process that analyzes the tables and produces statistics that
are vital to DB2's performance. Without good statistics, DB2 may create very inefficient database access
plans that result in very poor performance. Although frequent RUNSTATS are not necessary on HPSS
databases, the administrator should have a plan to perform them on some sort of regular schedule
consistent with local requirements. You should discuss this with your HPSS Support Representative.
It is also important to have a plan to perform REORGCHK operations from time to time to monitor the
organization of the database tables. As a consequence of normal use, a database table may become
significantly disorganized. Database performance can be enhanced by periodic reorganizations, some of
which can be performed with HPSS in operation. You should also discuss this with your HPSS Support
Representative.
15.1.2. Overview of the DB2 Backup Process
Without proper and systematic metadata backup, a database failure could result in total loss of the HPSS
system. For this reason, backing up the DB2 databases containing HPSS metadata is essential.
DB2 databases can be backed up in one of two ways:
1. Online backups are made that can be restored to the point of failure by “rolling forward”
archived logs of transaction activity since the backup.
This is the recommended method for making HPSS backups.
2. An offline snapshot of the database data is taken at a particular point in time.
Offline backups provide recovery only to the point in time at which they were made, and they
require that there be no other activity in the database while they are being made. Therefore, this
method is not recommended for use with HPSS.
Since HPSS installations require the use of online backups, it is useful to understand the types of backup
and restore operations that can be performed with this backup type. Online backups can be described as
HPSS Management Guide November 2009
Release 7.3 (Revision 1.0) 357