Ibm information archive architecture and deployment sg247843

Front cover

IBM Information Archive
Architecture and Deployment

Universal storage repository for all
types of content

High security with Enhanced Tamper
Protection

Support for multiple access
methods

Bertrand Dufrasne
Frank Boerner
Andreas Feldner
Roland Hoppe
Kai Nunnemann
Daniel Wendler
Rene Wuellenweber

ibm.com/redbooks

International Technical Support Organization

IBM Information Archive: Architecture and Deployment

August 2010

SG24-7843-00

Note: Before using this information and the product it supports, read the information in “Notices” on
page ix.

First Edition (August 2010)

This edition applies to the IBM Information Archive V1.2 (program number 5608-IAF).

© Copyright International Business Machines Corporation 2010. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team who wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Stay connected to IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Chapter 1. Introduction to archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 The business need for archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 IBM Smart Archive Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Introducing IBM Information Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Information Archive key objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Information Archive key features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.3 Information Archive value proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Archiving reference architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 2. IBM Information Archive overview and components . . . . . . . . . . . . . . . . . . 9
2.1 Information Archive overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Information Archive archiving concepts and features . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Information Archive security and data retention compliance features. . . . . . . . . . 11
2.1.3 Information Archive hardware and software overview . . . . . . . . . . . . . . . . . . . . . 12
2.2 Hardware components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Rack and intelligent power distribution unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Cluster nodes (2231-S2M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Information Archive Management Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.4 RSM server for Information Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.5 Information Archive Storage Controller (2231-D1A) and expansion drawer
(2231-D1B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.6 Information Archive SAN switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.7 Information Archive Ethernet switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.8 Console kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Software components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.1 IBM Tivoli Storage Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.2 IBM System Storage Archive Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.3 General Parallel File System (GPFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.4 Remote Support Manager for Information Archive . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.5 DS Storage Manager for Information Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.6 IBM Systems Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.7 Integrated Solutions Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Storage configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.1 Storage controller configuration and management . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.2 Storage configuration and partitioning for Storage Controller . . . . . . . . . . . . . . . . 29
2.4.3 Enhanced Remote Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5 Cabling / SAN zoning / TCP/IP addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5.1 KVM cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5.2 SAN cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5.3 Ethernet connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

© Copyright IBM Corp. 2010. All rights reserved. iii

2.5.4 TCP/IP addresses assigned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Chapter 3. Planning and installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1 Determining how many collections you need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2 Hardware configuration planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.1 Planning for Information Archive cluster nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.2 Disk storage and capacity planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.3 Planning the network connection type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.4 Planning tape attachment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.5 High availability with additional cluster nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.6 Planning Enhanced Remote Mirroring configuration. . . . . . . . . . . . . . . . . . . . . . . 49
3.3 Integration planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.1 Before creating any collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.2 Document protection levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.3 System Storage Archive Manager Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.4 Enhanced Tamper Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.5 LDAP considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.6 Time server requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.7 Backing up the appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4 Preparing for installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.1 General planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.2 Initial configuration worksheet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.3 Alerting and monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.4.4 Enhanced Remote Mirroring configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5 Physical installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5.1 Hardware installation (performed by IBM service representative) . . . . . . . . . . . . 57
3.5.2 Running the Initial Configuration Wizard (ICW) . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.5.3 Assigning administrative user roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.4 Changing RSM server passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.5 Configuring the call home feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.6 Activating SAN switch ports 8 through 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.5.7 Attaching tape drives and tape libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.5.8 Configuring the Enhanced Remote Mirroring feature . . . . . . . . . . . . . . . . . . . . . . 70

Chapter 4. System administration and operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.1 Information Archive administration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1.1 User and group management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1.2 Changing the passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.3 Software updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.1.4 System monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.1.5 RSM management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.1.6 DS Storage Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2 Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.2.1 Accessing the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.2.2 Shutting down the appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.2.3 Starting up the appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.2.4 Rebooting the servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.2.5 Maintenance mode for cluster node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.2.6 Suspending a collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.2.7 Resuming a collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.2.8 Retrieving error logs and traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.3 Information Archive Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

iv IBM Information Archive: Architecture and Deployment

4.3.2 Accessing the Information Archive CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.3.3 CLI command categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.3.4 Using the Information Archive CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Chapter 5. System Storage Archive Manager Collections . . . . . . . . . . . . . . . . . . . . . 115
5.1 System Storage Archive Manager Collection overview. . . . . . . . . . . . . . . . . . . . . . . . 116
5.2 IBM System Storage Archive Manager overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.2.1 IBM System Storage Archive Manager architecture overview . . . . . . . . . . . . . . 119
5.2.2 IBM System Storage Archive Manager basic concepts . . . . . . . . . . . . . . . . . . . 127
5.3 IBM System Storage Archive Manager features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.3.1 Access control and authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.3.2 Archive copy group retention parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.3.3 Chronological archive retention. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.3.4 Event-based retention policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.3.5 Deletion hold and release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.3.6 Data retention protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.3.7 Expiration processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.3.8 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
5.3.9 Data shredding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.3.10 Data deduplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.3.11 Archive process of a System Storage Archive Manager Collection . . . . . . . . . 142
5.4 Creating and maintaining a System Storage Archive Manager Collection . . . . . . . . . 143
5.4.1 Creating a System Storage Archive Manager Collection . . . . . . . . . . . . . . . . . . 144
5.4.2 What is preconfigured with System Storage Archive Manager Collection . . . . . 148
5.4.3 System Storage Archive Manager collection administration . . . . . . . . . . . . . . . . 161
5.4.4 Granting client nodes access to a System Storage Archive Manager Collection 165
5.5 Supported archive applications for System Storage Archive Manager Collections. . . 166
5.6 Differences between System Storage Archive Manager Collections and File Archive
Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Chapter 6. File Archive Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.1 File Archive Collections overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
6.2 Network File System (NFS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
6.2.1 Archive process with File Archive Collections (NFS) . . . . . . . . . . . . . . . . . . . . . 169
6.2.2 Policy-based document retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
6.2.3 Metafiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
6.2.4 Initial disk storage and secondary disk storage category . . . . . . . . . . . . . . . . . . 178
6.2.5 Additional considerations for File Archive Collections. . . . . . . . . . . . . . . . . . . . . 181
6.3 Hypertext Transfer Protocol (HTTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.4 Creating and maintaining a File Archive Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . 182
6.4.1 Creating a File Archive Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.4.2 What is preconfigured with the File Archive Collections . . . . . . . . . . . . . . . . . . . 192
6.4.3 File Archive Collection administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
6.4.4 Sharing directories and granting client nodes access. . . . . . . . . . . . . . . . . . . . . 211
6.4.5 Using the data share and the metafile share of a File Archive Collection. . . . . . 218
6.5 Archive applications supporting File Archive Collections . . . . . . . . . . . . . . . . . . . . . . 226

Chapter 7. LDAP environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
7.1 Introduction to directories and LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
7.1.1 Directory components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
7.1.2 Directory and directory services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
7.2 LDAP usage within Information Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
7.2.1 LDAP servers used in our scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
7.2.2 Names used in our scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Contents v

7.3 Configuring Information Archive with IBM Tivoli Directory Server. . . . . . . . . . . . . . . . 230
7.3.1 Configuring the server instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
7.3.2 Configuring the LDAP objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
7.3.3 Using the ITDS LDAP server from Information Archive . . . . . . . . . . . . . . . . . . . 241
7.4 Tivoli Directory Services in IBM i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
7.4.1 Basic configuration for IBM Tivoli Directory Server on IBM i. . . . . . . . . . . . . . . . 242
7.4.2 Starting and stopping the Tivoli Directory Server . . . . . . . . . . . . . . . . . . . . . . . . 246
7.4.3 Populating the LDAP directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
7.4.4 Using the IBM Tivoli Directory Server on IBM i with Information Archive . . . . . . 248
7.5 Configuring Information Archive with OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
7.5.2 Using the OpenLDAP server from Information Archive. . . . . . . . . . . . . . . . . . . . 252
7.6 Configuring Information Archive with Microsoft Active Directory. . . . . . . . . . . . . . . . . 253
7.6.1 Preparing Microsoft Active Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
7.6.3 Using the Active Directory server from Information Archive . . . . . . . . . . . . . . . . 259

Chapter 8. Integrating IBM Information Archive with archiving applications . . . . . . 261
8.1 IBM Enterprise Content Management portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
8.1.1 IBM Content Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
8.1.2 IBM Content Manager OnDemand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
8.1.3 IBM FileNet P8 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
8.2 System Storage Archive Manager-based Integration with Information Archive . . . . . 266
8.2.1 Integrating IBM Tivoli Storage Manager backup-archive client with a System Storage
Archive Manager Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
8.2.2 Integrating IBM Tivoli Storage Manager API with a System Storage Archive Manager
Collection (using dapismp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
8.2.3 Integrating Content Manager with Information Archive System Storage Archive
Manager Collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
8.2.4 Integrating Content Manager OnDemand with System Storage Archive Manager
Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
8.2.5 Integrating IBM FileNet P8 with a System Storage Archive Manager Collection 322
8.3 File archiving-based integration in Information Archive. . . . . . . . . . . . . . . . . . . . . . . . 342
8.3.1 Integrating IBM i with an Information Archive File Archive Collection . . . . . . . . . 342
8.3.2 Granting access to the File Archive Collection in Information Archive . . . . . . . . 343

Chapter 9. Monitoring and call home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
9.1 Status monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
9.1.1 Health Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
9.1.2 Event notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
9.2 Tivoli Storage Manager Health Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
9.2.1 Configuring the Tivoli Storage Manager Health Monitor . . . . . . . . . . . . . . . . . . . 362
9.2.2 Detailed health information for a server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
9.3 Using IBM Systems Director in Information Archive . . . . . . . . . . . . . . . . . . . . . . . . . . 365
9.3.1 Configuring IBM Systems Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
9.3.2 Working with IBM Systems Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
9.4 RSM server for Information Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
9.4.1 Configuring the RSM server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
9.4.2 Working with the Information Archive RSM server . . . . . . . . . . . . . . . . . . . . . . . 389
9.5 Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
9.5.1 Tivoli Common Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
9.5.2 Document status information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
9.5.3 IBM Tivoli Storage Manager reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

vi IBM Information Archive: Architecture and Deployment

9.5.4 IBM Tivoli Storage Productivity Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
9.6 Logging and tracing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
9.6.1 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
9.6.2 Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400

Chapter 10. Tape attachment with IBM Information Archive. . . . . . . . . . . . . . . . . . . . 403
10.1 Information Archive tape attachment overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
10.2 Tape device support for Information Archive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
10.3 Using tape for Information Archive data migration . . . . . . . . . . . . . . . . . . . . . . . . . . 406
10.4 Using tape for Information Archive data backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
10.4.1 System Storage Archive Manager Collections backup . . . . . . . . . . . . . . . . . . . 407
10.4.2 File Archive Collections backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
10.5 Planning for tape attachment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
10.5.1 IBM System Storage Archive Manager and Information Archive Tivoli Storage
Manager tape pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
10.5.2 Database backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
10.6 Configuring tape libraries and drives for use with Information Archive . . . . . . . . . . . 411
10.6.1 Attaching IBM TS3500 library to the internal SAN switches . . . . . . . . . . . . . . . 411
10.6.2 Device driver and device attachment verification . . . . . . . . . . . . . . . . . . . . . . . 412
10.6.3 Defining LTO4 tape drives and TS3500 library in the System Storage Archive
Manager server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
10.6.4 Integrating LTO4 drives and TS3500 library into the storage hierarchy . . . . . . 420
10.6.5 Modifying tape migration thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
10.7 Tape drive encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
10.7.1 Tape drive encryption methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
10.7.2 Encryption method setup for TS3500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
10.7.3 Drive encryption setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
10.8 Persistent naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
10.8.1 Linux device manager udev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
10.8.2 Defining udev rules for tape devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
10.8.3 Defining udev rules for medium changer commands . . . . . . . . . . . . . . . . . . . . 439

Chapter 11. Information Archive data backup and restore . . . . . . . . . . . . . . . . . . . . . 441
11.1 System Storage Archive Manager Collections backup and restore . . . . . . . . . . . . . 442
11.1.1 Backing up System Storage Archive Manager Collections . . . . . . . . . . . . . . . . 442
11.1.2 Restoring a System Storage Archive Manager Collection . . . . . . . . . . . . . . . . 447
11.1.3 Verifying data integrity of storage pool volumes . . . . . . . . . . . . . . . . . . . . . . . . 451
11.2 File Archive Collection backup and restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
11.2.1 File Archive Collection backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
11.2.2 Restoring File Archive Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456

Chapter 12. Enhanced Remote Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
12.1 Enhanced Remote Mirroring overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
12.1.1 Data replication process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
12.1.2 Primary and secondary logical drives setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
12.1.3 Mirror repository logical drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
12.1.4 Mirror relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
12.2 Enhanced Remote Mirroring configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
12.2.1 Enhanced Remote Mirroring requirements and feature codes . . . . . . . . . . . . . 465
12.2.2 Connecting the Fibre Channel cables for Enhanced Remote Mirroring . . . . . . 465
12.2.3 Establishing SSH-tunnel connection between the mirrored appliances . . . . . . 467
12.2.4 Defining an Information Archive to be the secondary appliance for Enhanced
Remote Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
12.2.5 Synchronizing data between the primary and secondary appliances . . . . . . . . 470

Contents vii

12.3 Using tape drives in an Enhanced Remote Mirroring environment . . . . . . . . . . . . . . 472
12.4 Site failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
12.4.1 Running a planned site failover or failback . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
12.4.2 IBM Information Archive disaster recovery with Enhanced Remote Mirroring . 476
12.4.3 Failing components in one of the IBM Information Archives with Enhanced Remote
Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
12.4.4 Connection issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
12.5 Administrative tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
12.5.1 Suspending the data mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
12.5.2 Resuming the data mirroring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
12.5.3 Removing the mirroring relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
12.5.4 Restoring a removed mirrored relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
12.6 Tips for synchronizing appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
12.6.1 Changing synchronization priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
12.6.2 Test the mirror communication in the DS Storage Manager . . . . . . . . . . . . . . . 485
12.6.3 Checking the Enhanced Remote Mirroring status. . . . . . . . . . . . . . . . . . . . . . . 487

Chapter 13. DR550 migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
13.1 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
13.1.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
13.1.2 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
13.1.3 Sizing and duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
13.1.4 Verifying the data after migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
How to get Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495

viii IBM Information Archive: Architecture and Deployment

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.

Any references in this information to non-IBM websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the
materials for this IBM product and use of those websites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.

© Copyright IBM Corp. 2010. All rights reserved. ix

Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. These and other IBM trademarked terms are
marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US
registered or common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the web at http://www.ibm.com/legal/copytrade.shtml

The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX® IBM® System i®
DB2® InfoSphere™ System Storage™
Domino® Lotus Notes® System Storage DS®
DS4000® Lotus® System x®
Electronic Service Agent™ Notes® System z®
FileNet® OmniFind® Tivoli Enterprise Console®
GPFS™ Optim™ Tivoli®
i5/OS® Redbooks® TotalStorage®
IBM Systems Director Active Energy Redpaper™ WebSphere®
Manager™ Redbooks (logo) ® z/OS®

The following terms are trademarks of other companies:

FileNet, and the FileNet logo are registered trademarks of FileNet Corporation in the United States, other
countries or both.

SnapLock, NetApp, and the NetApp logo are trademarks or registered trademarks of NetApp, Inc. in the U.S.
and other countries.

Novell, SUSE, the Novell logo, and the N logo are registered trademarks of Novell, Inc. in the United States
and other countries.

QLogic, and the QLogic logo are registered trademarks of QLogic Corporation. SANblade is a registered
trademark in the United States.

SAP R/3, SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several
other countries.

Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.

Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.

Intel Xeon, Intel, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks
of Intel Corporation or its subsidiaries in the United States and other countries.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

x IBM Information Archive: Architecture and Deployment

Preface

This IBM® Redbooks® publication can help you understand, configure, monitor, and use IBM
Information Archive.

As you address your information retention needs, whether keeping valuable content for long
periods of time, meeting industry retention regulations, or addressing corporate governance,
you need an archiving solution that is secure, scalable, but also cost-effective.

IBM Information Archive is the next-generation information retention solution designed as a
universal archiving repository for all types of content to help midsize and enterprise clients
reduce cost, manage risk, and address clients’ complete information retention needs:
business, legal, or regulatory.

This highly versatile, smart business system can be a useful tool for clients in their efforts to
support regulatory compliance by providing a storage repository with robust security features
designed to prevent the alteration or deletion of the storage repository in which information is
stored until their business-designated retention period has elapsed.

This book is a comprehensive document intended for customers and field personnel who
want to understand, deploy, use, and monitor IBM Information Archive.

The team who wrote this book
This book was produced by a team of specialists from around the world working at the
International Technical Support Organization, San Jose Center.

Bertrand Dufrasne is an IBM Certified Consulting I/T Specialist and
Project Leader for IBM System Storage™ disk products at the
International Technical Support Organization, San Jose Center. He has
worked at IBM in various I/T areas. He has authored many IBM
Redbooks publications and has also developed and taught technical
workshops. Before joining the ITSO, he worked for IBM Global Services
as an Application Architect. He holds a Master’s degree in Electrical
Engineering.

Frank Boerner is an IT Specialist working for IBM Germany. He has 20
years of experience as a customer engineer, software engineer, and
solution support specialist. He works in the Archive Solution Competence
Center in Leipzig and provides worldwide support for DR550 and IBM

Andreas Feldner is an accredited Product Support Professional and
region specialist for DR550 and SAN products and is located in Frankfurt,
Germany. He works for IBM Global Technology Services and has more
than 16 years experience in product support. His areas of expertise
include implementation and maintenance of DR550, IBM System p®
servers, disk subsystems, and tape storage solutions.

© Copyright IBM Corp. 2010. All rights reserved. xi

Roland Hoppe is a Product Service Professional in Germany. He has 20
years of experience as a customer engineer and support specialist. He
works in the Archive Solution Competence Center in Leipzig and
provides worldwide support for DR550 and IBM Information Archive.

Kai Nunnemann is a Senior Consultant and Category Leader for
Information Management at becom - A Divison of Computacenter, in
Germany. He has 14 years of experience with IBM hardware and
software. His areas of expertise include IBM Tivoli® Software, IBM
Content Management software, and related storage hardware. He holds
a degree in Mechanical Engineering. Kai is one of becom’s IBM Certified
Deployment Professionals Tivoli Storage Manager, and an IBM Certified
Solution Advisor Tivoli Storage.

Daniel Wendler is an IT Specialist within the IBM MTS Group in
Germany. After studying computer science and graduating at the
University of applied science Wiesbaden, Daniel joined IBM in 2005. He
wrote his final thesis in the eRMM Software Development department at
IBM about automated policy-based management of removable storage
media. Since then, Daniel is working in the European Storage
Competence Center as a product field engineer for RMSS products. He
provides post-sales support for enterprise tape libraries, Open System
virtualization engines and enterprise tape encryption solutions.

Rene Wuellenweber is an accredited Product Service Professional
working for IBM in Germany. He has 12 years of experience as a
customer engineer, supporting DASD Midrange products and working as
solution support specialist. Rene works in the Archive Solution
Competence Center in Leipzig and provides worldwide support for
DR550 and IBM Information Archive.

Thanks to the following people for their contributions to this project:

BJ Klingenberg, Bonnie Pulver, Mike Griese, Neeta Garimella, Erick Kissel, Greg McBride,
Bryan Jen, Braynt Lee, Jason Auvenshine, Linda Benhase, Tony Ciaravella, Chris Zukowski,
Roger Wofford, Michael Griese, Jim Saunders, Manuel Avalos Vega, Carlos Sandoval, Don A
Hantzsche, Brian Ashmore, Kelly Axup, Matthias Jung, Nils Haustein, Stefan Roth, Stefan
Bender, Alexander Safonov and Harald Uebele.

xii IBM Information Archive: Architecture and Deployment

Now you can become a published author, too!
Here's an opportunity to spotlight your skills, grow your career, and become a published
author - all at the same time! Join an ITSO residency project and help write a book in your
area of expertise, while honing your experience using leading-edge technologies. Your efforts
will help to increase product acceptance and customer satisfaction, as you expand your
network of technical contacts and relationships. Residencies run from two to six weeks in
length, and you can participate either in person or as a remote resident working from your
home base.

Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html

Comments welcome
Your comments are important to us!

We want our books to be as helpful as possible. Send us your comments about this book or
other IBM Redbooks publications in one of the following ways:
Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
Send your comments in an email to:
redbooks@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400

Stay connected to IBM Redbooks publications
Find us on Facebook:
http://www.facebook.com/IBMRedbooks
Follow us on twitter:
http://twitter.com/ibmredbooks
Look for us on LinkedIn:
http://www.linkedin.com/groups?home=&gid=2130806
Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks
publications weekly newsletter:
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html

Preface xiii

xiv IBM Information Archive: Architecture and Deployment

1

Chapter 1. Introduction to archiving
In this chapter we introduce the concept of archiving and its business requirements. We
explain the need for retention managed data and briefly present the IBM Smart Archive
Strategy.

This strategy can help you realize the business value of your information while driving down
costs and risks as well as ensuring that critical business content is properly retained and
protected.

As an element of the IBM Smart Archive Strategy, we highlight the features of the IBM
Information Archive (Information Archive) and position them in this context.

© Copyright IBM Corp. 2010. All rights reserved. 1

1.1 The business need for archiving
Information or data is essential to any business and for the most part can be considered a
company asset. Examples of such data include contracts, CAD/CAM designs, aircraft build
and maintenance records, and email, including attachments, instant messaging, insurance
claim processing, presentations, transaction logs, web content, user manuals, training
material, digitized information (such as check images, medical images, historical documents,
and photographs), and much more. With that understanding, companies see a potential value
in aggregating large amounts of data.

In addition to the sheer growth of data, the laws and regulations governing the storage and
secure retention of business and client information are increasingly becoming part of the
business landscape, making data retention a major challenge to any institution. Regulated
information can include email, instant messages, business transactions, accounting records,
contracts, or insurance claims processing, all of which might need to be retained for varying
periods of time. Some of this data might be kept several years. Some data might also be kept
forever.

Moreover, some data must be kept just long enough and not any longer. Indeed, content is an
asset when it needs to be kept; however, if kept past its mandated retention period, it can also
become a liability. Furthermore, the retention period can change due to factors such as
litigation.

The characteristics of archived data can vary greatly in their representation, size, and industry
segment. It becomes apparent that the most important attribute of this kind of data is that it
needs to be retained and managed, so it is called retention-managed data.

Retention-managed data is data that is written once and is read rarely (sometimes never).
Other terms abound to describe this type of data, such as reference data, archive data,
content data, or other terms implying that the data cannot be altered.

Retention-managed data is data that needs to be kept (retained) for a specific (or unspecified)
period of time, usually years.

Retention-managed data applies to many types of data and formats across all industries.
The file sizes can be small or large, but the volume of data tends to be large (multi-terabyte to
petabyte). It is information that might be considered of high value to an organization,
therefore, it is retained near-line for fast access. It is typically read infrequently and thus can
be stored on economical disk media such as SATA disks. Depending on its nature, it can be
migrated to tape after some period.

It is also important to recognize what does not qualify as retention-managed data. It is not the
data that changes regularly, known as transaction data (account balance, inventory status,
and orders today, for example). It is not the data that is used and updated every business
cycle (usually daily), or the backup copy of this data. The data mentioned here changes
regularly, and the copies used for backup and disaster recovery are there for exactly those
purposes, meaning backup and disaster recovery. They are there so that you can restore data
that was deleted or destroyed, whether by accident, a natural or human-made disaster, or
intentionally.

All these factors mandate tight coordination and a controlled, intelligent approach to
archiving. This is what the IBM Smart Archive Strategy is aimed at.

2 IBM Information Archive: Architecture and Deployment

1.2 IBM Smart Archive Strategy
The IBM Smart Archive Strategy is a comprehensive cross-brand approach that combines
IBM software, systems, and service capabilities designed to help customers extract value and
gain new intelligence from information by collecting, organizing, analyzing, and leveraging
that information. This approach, depicted in Figure 1-1, delivers a comprehensive set of
solutions, products, and services in a unified and integrated strategy that helps you realize
the business value of your information while driving down costs and risks and ensuring that
critical business content is properly retained and protected.

With the IBM Smart Archive Strategy, you can simplify the archiving infrastructure and reduce
overall storage and power needs as well as administrative requirements with the help of
integrated appliances and multiple delivery options. Implementing an IBM Smart Archive
solution can eliminate unnecessary junk content, helping to improve system and process
efficiency and productivity. Reducing discovery costs and legal fees are key objectives, as
well as enhancing response capabilities by providing authorized legal staff quick access to
and analysis of case-relevant information.


Figure 1-1 The IBM Smart Archive Strategy

The IBM Smart Archive Strategy offers the following capabilities:
Optimized and unified ingestion:
– Enables a deeper understanding of what information to archive through
discovery-based and analytics-based assessment technologies.
– Eliminates point solution complexity and cost by unifying data and content archiving
through common collection (ingest) and classification technologies.
The following examples from the IBM Product portfolio fit that category:
– IBM InfoSphere™ Content Assessment software
– IBM InfoSphere Content Collector family of offerings, including integration with IBM
Optim™ Data Growth Solution software

Chapter 1. Introduction to archiving 3

– IBM InfoSphere Classification Module software
– IBM InfoSphere Discovery with Optim Data Growth Solution software
Flexible and secure infrastructure:
– Enables cost-optimized retention with unified, flexible, secure and policy-aware
infrastructure.
– Speeds time to value through modular, integrated solutions including choice of
management and delivery models based on a common information lifespan and
policies. These solutions and services include traditional on-premise software,
preconfigured appliance, software-as-a-service, cloud-ready and hybrid options.
The following examples from the IBM product portfolio fit that category:
– IBM Enterprise Content Management (ECM) repositories
– IBM Information Archive solution (the focus of this book)
– IBM Managed Information Archive Cloud Services
– IBM Global Technology Services – Storage and Archive Services
Integrated Compliance, Records Management, Analytics, and eDiscovery:
Reduce risk, respond more quickly to legal inquiries, establish trust and leverage
information using integrated compliance, analytics, records management, and eDiscovery
software.
The following examples from the IBM product portfolio fit that category:
– IBM InfoSphere Enterprise Records software
– IBM InfoSphere Discovery Manager and Discovery Analyzer software

1.3 Introducing IBM Information Archive
IBM Information Archive (Information Archive) is one of the enablers for the IBM Smart
Archive Strategy, as one of its possible infrastructure elements.

Information Archive is the next-generation information retention solution designed as a
universal archiving repository for all types of content to help midsize and enterprise clients
reduce cost, manage risk, and address clients’ complete information retention needs:
business, legal, or regulatory.

Information Archive is a universal, scalable, and secure storage repository for structured and
unstructured information. Information Archive application support includes IBM ECM and
Optim with policy harmony. Information Archive replaces the IBM System Storage DR550 and
offers significant enhancements over the DR550.

This highly versatile, cloud-ready, smart business system can be a useful tool for users in
their efforts to support regulatory compliance by providing a storage repository with robust
security features designed to prevent the alteration or deletion of the storage repository in
which information is stored until your business-designated retention period has elapsed.

Information Archive is an integrated, appliance-based solution for retaining archived
information in a compliant storage environment. Information Archive connects to application
servers, receives files and documents from these applications, and stores them in a hierarchy
of disk and tape storage. The information is stored in a collection, which is the basic storage
repository within Information Archive. You can use Information Archive as the target storage
for your archiving applications or you can move information from your application or existing
storage domain to Information Archive.


You can manage archived information from a single, simple to use graphical user interface
(GUI). Information Archive scales in capacity by adding more disk storage to the collections
and scales in performance by adding more file system nodes.

Using hierarchical storage management techniques, Information Archive helps move archived
information across a hierarchy of lower cost storage devices, including tape. This can help
you to match the value of your archived information to the cost of the infrastructure on which it
is stored. Information Archive is designed to provide a quick time-to-value so you can begin to
realize its benefits very soon after.

1.3.1 Information Archive key objectives
The key objectives of Information Archive are as follows:
To provide a universal storage repository for all types of content, structured and
unstructured, compliant or non-compliant data
To eliminate complex installation and configuration
To scale easily for both capacity and performance
To support efficient policy-driven retention and tiered storage management
To support standard interfaces into the system for easy integration with applications
To protect data integrity for the entire lifespan of the information
To offer low Total Cost of Ownership (TCO) by allowing use of mixed media (disk and tape)
To support existing retention policies or enable administrators to define customized
policies
To incorporate current DR550 capabilities and much more

1.3.2 Information Archive key features
The Information Archive solution offers the following key features and characteristics:
Provides a single platform for archiving compliant, non-compliant, structured and
un-structured data thus reducing the need multiple systems.
Provides customizable data protection features to meet the industry's most stringent data
retention mandates.
Enables data archiving across multiple tiers of storage, including disk, tape and, other
near-line or offline storage, to provide massive scalability and a more cost-effective,
energy efficient archive system.
Enables specified information protection levels for archive collections. With Information
Archive, IBM has introduced a unique 3x3 architecture that allows businesses to configure
up to three archive collections on a single system with up to three servers. It allows the
flexibility for each collection to be configured with the following information protection
levels:
– Basic Protection enables the greatest flexibility for managing an organization’s data
retention needs.
– Intermediate Protection allows IT administrators to increase and decrease retention
periods as needed, but information deletion is only allowed after the retention period
has expired.
– Maximum Protection helps IT administrators manage information with strict business,
legal, or regulatory retention needs.


Enforces data retention polices that maintain data as non-erasable and non-rewritable
(NENR) until deletion is permitted by retention policy.
Enables users to archive and retrieve directly from or to their workstations as well as
enterprise content management applications.
Offers Enhanced Disaster Recovery based on advanced copy services to increase the
availability of archived documents and to prevent data loss in the event of a disaster.
Implements Enhanced Tamper Protection, a patent-pending feature that prevents root
access to the appliance to avoid modification or deletion of archived data.
Supports data deduplication, which helps to store a single instance of data on disk and
reduces the file size of documents in the archive collections. Data deduplication can
reduce the effective data size on disk by 20 to 80%.
Provides Hierarchical Storage Management, which automatically distributes and
manages data on disk, tape, or both, with the objectives of minimizing access time to data
and maximizing available media capacity.

1.3.3 Information Archive value proposition
The Information Archive value proposition can be summarized as follows:
Manage risk:
– Offers policy-based or general purpose archiving capabilities to help address
compliance and non-compliance requirements: business, legal, and regulatory
– Provides enhanced security with encryption for both disk and tape storage
– Enforces retention polices that meet some of the industry's most stringent data
retention mandates.
– Introduces new patent-pending tamper protection technology
– Locks data into non-erasable, non-rewriteable formats based on specific business
needs.
Reduce cost:
– Information Archive uses a true storage mix of disk and tape technologies combining
fast accessible disk with low cost of tape within a single archive pool.
– It can thus maximize your total cost of ownership over the life of the archived data.
Improve productivity and efficiency:
– Simple to implement (pre-integrated, pre-configured) and manage Industry standard
interface (NFS) supports immediate archiving (no custom APIs required)
– Easily scales, can dynamically add and remove storage and scales to 1 billion objects
across petabytes of storage, from multiple content types
– High performing system based on the IBM patented GPFS™ file system technology


1.4 Archiving reference architecture
A reference model describes an abstraction of the key concepts and their relationships. The
reference model referred to in this book consists of a three layer architecture as depicted in
Figure 1-2.

Layer 1 describes the application layer. Applications in Layer 1 run on computer systems that
generate, analyze, and process information and store this information as data. Typical
examples of such applications are email clients, IBM Lotus® Domino® server, Microsoft®
Exchange server, or Picture Archiving and Communication Systems (PACS).

Layer 1 applications communicate to Layer 2 components through proprietary or open
interfaces (depending on the application). Layer 2 is the archive management layer or
Document Management System (DMS), sometimes also referred to as Content Management.
Archive management components are usually running on hardware systems other than
Layer 1 and Layer 3 components.

The DMS or Content Management systems are collecting, managing, storing and retaining
data and finally transmitting the data and related information to the archive storage system
(Layer 3).

The Information Archive appliance is in Layer 3. In Chapter 8, “Integrating IBM Information
Archive with archiving applications” on page 261, you can find descriptions and practical
illustrations of how Layer 2 applications integrated with Information Archive.

Applications
Layer 1

` ` `

LAN
Layer 2

Document Management
System

Archive
Layer 3

Appliance

Figure 1-2 Reference architecture for digital archiving


2

Chapter 2. IBM Information Archive
overview and components
The IBM Information Archive (Information Archive) hardware and software are preinstalled
and delivered in a base rack (2231-IA3) and one optional expansion rack (2231-IS3). The
base and expansion racks (or frames) are available in various configurations and capacity
options.

In this chapter we present an overview of the Model 2231-IA3 and the optional Model
2231-IS3. First, we review the system as whole and its intended usage, followed by a
description of each of the elements, hardware, and software, with detailed information about
how they are initially packaged, installed, and configured.


2.1 Information Archive overview
The Information Archive appliance is an integrated data retention solution. It is the IBM
follow-on and replacement product for the IBM System Storage DR550. The appliance
includes preinstalled servers, disk storage, and the Information Archive software.

2.1.1 Information Archive archiving concepts and features
Information Archive brings together off-the-shelf IBM hardware and software products. The
hardware comes premounted in a secure rack. The software is preinstalled and to a large
extent preconfigured. It is designed to be easy to deploy.

Information Archive can be used to store and manage multiple billions of documents over its
deployment lifetime. Information Archive provides policy-managed storage for compliance,
archiving, and content management applications. These applications can retrieve files using
standard communication protocols, such as Network File System (NFS) and HTTP, and can
archive files using NFS or the System Storage Archive Manager API in logical containers,
called collections. The Information Archive solution includes time-based and event-based
retention options, compression and deduplication of stored data, and compatibility with
customer applications that can be used by the former DR550 appliance. Optional features of
Information Archive include remote replication for disaster recovery, high-availability server
configurations, and tape library support.

Figure 2-1 shows a general overview of the conceptual Information Archive architecture. It
depicts how applications can store documents into Information Archive over an Ethernet LAN.
The documents are archived in collections that reside on disk. The collections can be of two
types: System Storage Archive Manager collections and File Archive Collections (archive
over NFS). A maximum of three collections (in any combination of System Storage Archive
Manager Collections or File Archive Collections) is supported. The Information Archive
software includes an administrative Graphical User Interface, the Information Archive
Administration GUI (Information Archive GUI).

IBM IA Admin GUI
Applications

LAN

One Namespace

NFS
NAS NFS
NAS NAS
SSAM
Disk Disk Disk
Disk Disk Disk
Disk
Collection 1 Collection 2 Collection 3
Collection 1 Collection 2 Collection 3
Clustered Clustered


Tape or other devices
© 2 00 9 IBM Corp or atio n

Figure 2-1 Information Archive architecture


The Information Archive GUI lets you administrate, operate, and monitor the Information
Archive appliance, and generate reports. The system offers the option to migrate and back up
data to tape. Although optional, tape attachment is highly desirable.

2.1.2 Information Archive security and data retention compliance features
Information Archive is primarily intended to provide a storage solution for archiving and data
retention compliance. Thus, it offers the following retention and document protection features.

Document retention
The Information Archive appliance provides a number of ways to specify how long documents
are retained.You can configure document retention policies, which provide both time-based
and event-based retention options.

Document protection settings
After a document is ingested into archival storage, it cannot be modified until its retention
period expires. You can use document protection settings to further restrict the actions that
can be taken on archived documents.

Document protection levels can be set independently for each collection in the appliance.
There are three levels of document protection available for File Archive Collections. System
Storage Archive Manager collections only support the maximum level of document protection,
which does not allow the deletion of documents or the reduction of retention periods.

Enhanced Tamper Protection
Enhanced Tamper Protection prevents root access to the servers in the Information Archive
appliance. Root access can potentially be used to modify or delete archived data. Enhanced
Tamper Protection is a system-wide setting that affects all the collections in the appliance.
This feature can be enabled during the initial configuration of the appliance, or at a later time.
After being enabled, it cannot be turned off.

If you do not enable Enhanced Tamper Protection, you must use other methods to prevent
tampering and you must securely manage the root passwords on all servers in the appliance.

Access protection
Authentication is required for access to archived documents and the Information Archive GUI.
For File Archive Collections, user accounts for administrators and archive users can be
managed using an external Lightweight Directory Access Protocol (LDAP) server. Access for
users, user groups, or host systems must be granted through the Information Archive
administrative interface. Also see Chapter 7, “LDAP environments” on page 227.

Two predefined user accounts are provided with the appliance: iaadmin and iscadmin. These
user accounts have limited authority, and are intended to be used for a specific set of tasks.
You must change the default passwords for these user accounts during the initial
configuration of the appliance.

Compliance features
Information Archive provides a number of features to enable you meet your legal, regulatory,
or policy compliance requirements for data archiving.

Chapter 2. IBM Information Archive overview and components 11

2.1.3 Information Archive hardware and software overview
The Information Archive, seen in Figure 2-2, is available in several configurations with storage
from 8 TB (one collection) up to 440 TB of raw capacity for up to three collections. Similar to
the DR550, Information Archive is also available as primary and secondary systems for a
Disaster Recovery Protection configuration, based on remote disk mirroring.

Figure 2-2 Photograph of the IBM 2231-IA3 rack

The Information Archive appliance includes Fibre Channel (FC) ports for external tape
attachment but does not include cables or tape drives or tape libraries. You must acquire and
attach tape drives to be able to back up your configuration and collection data (see
Chapter 10, “Tape attachment with IBM Information Archive” on page 403). The backup and
restore process is described in detail in Chapter 11, “Information Archive data backup and
restore” on page 441.

The software bundle includes Information Archive Version 1.2, the IBM Tivoli Storage
Manager 6.x, the IBM System Storage Archive Manager Version 6.x, Information Archive
Cluster Version, the IBM System Director Version 6.1.0, and DS Storage Manager for
Information Archive, customized for additional protection.


2.2 Hardware components
Figure 2-3 shows a diagram that depicts the hardware components and their placement in the
base Information Archive frame (2231-IA3).

A standard Information Archive 2231-IA3 base frame consists of:
One 2231-IA3 rack (7014 T00 rack - 36U)
At minimum, one cluster node (which is an IBM System x® 3560 M2). It is a 4-EIA (2U),
19-inch rack mounted server. It is configured as a two quad-core Intel® processor system.
The default system memory is 24 GB and can be up to 64 GB. It also includes standard
dual power supplies.
One Management Console server (IBM System x 3550 M2) for 2231-IA3
One RSM server (IBM System x 3550 M2) for 2231-IA3
One console kit (1735 3LX with Keyboard, Video, Mouse) and KVM switch
Two optional IBM SAN switches (2498-B24 FC switch)
Two IBM Ethernet switches (SMC 8126 L2 26 port Ethernet switches)
One Storage Controller 2231-D1A (IBM System Storage DS4200)
Up to six optional Expansion Drawers 2231-D1B (IBM System Storage EXP420)

RSM Server

Expansion
Drawers

Management KVM Switch
Console
SAN
Managem ent Node Switches
Ethernet
Cluster Node 1 Switches

Cluster Node 2
Cluster Node 3

Expansion
Drawers

Storage
Controller

1
Front View Rear View © 2009 IBM Corporatio

Figure 2-3 Component locations in 2231-IA3


The base frame 2231-IA3 can be complemented with one expansion frame 2231-IS3 (shown
in Figure 2-4) to provide storage for up to two additional collections. The optional Information
Archive 2231-IS3 Expansion frame consists of the following components:
One 2231-IS3 rack (7014 T00 rack - 36U)
Up to two 2231-D1A Storage Controllers (IBM System Storage DS4200)
Up to ten Expansion Drawers 2231-D1B (IBM System Storage EXP420)

Disk Expansion 2.5

Disk Expansion 1.5

Disk Expansion 2.4

Disk Expansion 1.4

Disk Expansion 2.3

Disk Expansion 1.3

Disk Expansion 2.2

Disk Expansion 1.2

Disk Expansion 2.1

Disk Expansion 1.1

Disk Controller 2

Disk Controller 1

1 © 2009 IBM Corporation

Figure 2-4 Component location in the optional Information Archive 2231-IS3

2.2.1 Rack and intelligent power distribution unit
This section provides details about the Information Archive rack (base and expansion
frames), as well as the integrated intelligent power distribution unit (iPDU).

Rack specifications
The Information Archive rack is a 7014-T00 rack that stacks all the components vertically. The
rack comes with doors in the front and back, and includes the Rack Security Kit to secure
physical access to any of the Information Archive appliance components. The Information
Archive 2231-IA3 (base frame) and the Information Archive 2231-IS3 rack (expansion frame)
have a height of 36U and each contains two iPDUs.

The servers and (optional) SAN and Ethernet switches are placed in the middle of the rack.
The storage units start from the bottom, populating toward the top as the storage capacity
installed increases (also see Figure 2-3 and Figure 2-4.

The hardware specifications provide detailed information for the rack, including dimensions,
electrical, power, temperature, environment, and service clearances. For more information,
see:
http://publib.boulder.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=/iphad/f7
014t00rack.htm


Specifications for the iPDU (PDU+)
The intelligent power distribution unit (iPDU), also called power distribution unit plus (PDU+),
has power-monitoring capabilities. The iPDU is an intelligent AC power distribution unit that
monitors the amount of power being used by the devices that are plugged into it.

Figure 2-5 shows a schematic representation of the iPDU.

Figure 2-5 The iPDU - Power distribution unit with Ethernet ports

All the cabling from the iPDUs to the various Information Archive components is done by
manufacturing.

2.2.2 Cluster nodes (2231-S2M)
Information Archive includes one, or optionally up to three, Information Archive cluster nodes
(2231-S2M). Each node consists of an IBM System x (x-3650 M2, Machine Type 7947),
running a Linux®-based operating system. Cluster nodes process all the documents that
have been saved to Information Archive and perform management operations on the
documents that have been archived.

All cluster nodes have identical hardware, and they are configured as GPFS cluster nodes.

Important: Always order the same amount of memory for each server.

Physically, the System x x3550-M2 is a 2-EIA (2U), 19-inch, rack-mounted server. Up to two
quad- or dual-core Intel Xeon® 5550 Series processors with QuickPath Interconnect (QPI)
technology, up to 2.93 GHz, and up to a 1333 MHz front-side bus are available. This server
has a new energy-efficient design with low 675 W and up to 92% efficient power supplies, six
cooling fans, altimeter monitored by the Integrated Management Module (IMM) and by IBM
Systems Director Active Energy Manager™.

Up to 128 GB of high-performance, new-generation DDR-3 memory are available. It includes
ultimate internal storage flexibility with up to twelve 2.5" hot-swap SAS/SATA/SSD HDD bays.
The x3650 M2 provides four x8 (“by 8”) 8 GBps PCIe (PCI Express) Gen 2 high performance
I/O slots. It also includes two integrated Broadcom 5709C Gigabit Ethernet controllers
standard.

In Information Archive, this server is equipped with a dual quad-core processors, and has
24 GB memory installed (maximum 64 GB possible). There are also two dual-port 4 Gb FC
HBAs and two 146 GB 15k rpm SAS internal disks configured as RAID 1. One FC Ethernet
dual port card is optionally available.


Figure 2-6 shows the front view of the 2231-S2M server.

Figure 2-6 Cluster Node 2231-S2M - front view

Cluster nodes: The Information Archive Model 2231-IA3 must contain at least one cluster
node with a maximum of up to three cluster nodes.

Figure 2-7 shows the Cluster Node rear panel.

Figure 2-7 Cluster Node 2231-S2M - rear view

The minimum configuration supports a single collection with one cluster node 2231-S2M, but
this does not allow a cluster node failover.

The maximum configuration consists of three cluster nodes and supports three collections. In
this configuration, all collections support cluster node failover, but there will be a performance
degradation when more than one collection runs on a single cluster node. Each collection
needs a dedicated Storage Controller 2231-D1A (DS4200). Consequently, for more than one
collection, the configuration requires the 2231-IS3 expansion frame to mount the second and
third 2231-D1A storage controllers.


2.2.3 Information Archive Management Console
The Information Archive also includes one Management Console (IBM System x, x-3550 M2,
M/T 7946) also running a Linux-based operating system. This is your Information Archive
appliance utility server running the Information Archive Administration GUI based on the
Integrated Solutions Console (ISC). It is also used for monitoring through the preinstalled IBM
Systems Director, which provides all core RAS systems management and call home
requirements. The Management Console provides a single point of access for all functions.

The Management Console (M/T 7964 is a member of the IBM System x family (x-3550-M2).
Physically, it is a 1-EIA (1U), up to two quad-core or dual-core Intel Xeon 5500 Series
processors with QuickPath Interconnect (QPI) technology, up to 2.93 GHz, and up to 1333
MHz front-side bus, including the following features:
New energy-efficient design with low 675 W
Up to 92% efficient power supplies, six cooling fan modules, altimeter monitored by IMM,
and IBM Systems Director Active Energy Manager
Up to 128 GB of high-performance, new-generation DDR-3 memory
Ultimate internal storage flexibility with up to six 2.5" hot-swap SAS/SATA/SSD HDD bays

The system includes two PCI-Express (x16) Gen 2 slots: one half-length, full-height; and one
low-profile, as well as two integrated Broadcom 5709 Gigabit Ethernet controllers, standard.

In the Information Archive appliance, the Management Console has 4 GB of memory and two
146 GB 15k rpm SAS internal disks configured as RAID 1. Figure 2-8 and Figure 2-9 show
the front view and rear view, respectively, of the Information Archive Management Console
server.

Figure 2-8 Information Archive Management Console - front view

Figure 2-9 Information Archive Management Console - rear view


2.2.4 RSM server for Information Archive
The IBM Remote Support Manager (RSM) is the solution for alerting and call home support
for the IBM DS4000/DS5000 family of products, including the DS4200, which is the Storage
Controller used in Information Archive. The IBM Remote Support Manager is an application
that is installed on an IBM System x server running Novell® SUSE® Linux Enterprise Server
10, and provides problem reporting and remote access. A special version of the RSM server
to ensure compliance of the appliance is installed in Information Archive (the same version
that was used in the DR550). We refer to that special version as the RSM server for

The RSM server hardware used in Information Archive is also an IBM System x server
M/T7946 (x3550 M2) as used for the Management Console, but equipped with only 2 GB of
memory. For further information about monitoring and call home using the RSM server for IA,
see 9.4, “RSM server for Information Archive” on page 381.

2.2.5 Information Archive Storage Controller (2231-D1A) and expansion
drawer (2231-D1B)
The Storage Controller (2231-D1A) used in Information Archive is the IBM System Storage
DS4200. Additional storage capacity is increased by adding Information Archive expansion
drawers (2231-D1B). The Information Archive expansion drawer is an IBM System Storage
EXP420. Each Storage Controller and expansion drawer used with the Information Archive
includes eight or sixteen 1 TB or 2 TB Serial ATA (SATA) disk drives. The Information Archive
base frame (2231-IA3) can consist of one Information Archive Storage Controller (2231-D1A)
and up to six Information Archive expansion drawers (2231-D1B). In the expansion frame
(2231-IS3) there is space for two optional storage controllers and five optional expansion
drawers for each of these storage controllers (a maximum of ten expansion drawers).

Each Storage Controller has two 4 GB FC ports by default that are used to attach the
Information Archive cluster node servers. Another, optional, two 4 GB FC ports for remote
mirroring can be included.

The Information Archive Storage Controller supports online controller firmware upgrades to
help provide better performance and functionality. For further information about the IBM
DS4200 Storage Controller, see:
http://www.ibm.com/servers/storage/disk/ds4000/ds4200/index.html

References: The foregoing link is only meant for general DS4200 related documentation.
For Information Archive specific software and firmware downloads, you must strictly refer
to the Information Archive support web page:
http://www-03.ibm.com/systems/storage/disk/archive/index.html


The storage units are equipped with Serial Advanced Technology Attachment (SATA) disk
drives. With Information Archive, users get the advanced features of the Storage Controller
with the cost-effective advantage of SATA disks that are well-suited for fixed content, sparingly
accessed storage applications.

Figure 2-10 shows the front view of the Information Archive Storage Controller (2231-D1A).

The 2231-D1B (EXP 420) looks identical from the front except for the label on the front bezel.

Figure 2-10 Information Archive Storage Controller (2231-D1A) - front view

Figure 2-11 shows the rear view of the Information Archive Storage Controller.

Ctrl A

21

1 2

Ctrl B

Ethernet Ports
Host Side connections
Figure 2-11 Information Archive Storage Controller (2231-D1A) - rear view


The 2231-D1B (EXP 420) has two hot-swappable Environmental Service Modules (ESMs),
two power supplies, and two fan units that provide for sufficient redundancy and availability.
The 2231-D1A and the 2231-D1B also have hot-swappable drives. The hot-swap drive bays
are preinstalled in drive trays. This drive and carrier assembly, called a customer replaceable
unit (CRU), includes the drive tray, SATA drive, and hard disk drive interposer card; they are
installed in the 16 drive bays on the front of the unit. Each of these can be replaced as a unit.
Figure 2-11 shows the rear view of Information Archive 2231-D1B.

Reserved

SFP interface connectors

Serial Port

Dv e Ch a n n e l
r
i Dr e Ch a n n e l
v
i
2 B 2 A 1 B 1 A

G/s
b Gb /
s DC
2 4 4 4 OK
2 1 2 1

DDi
I / a g

OK ESM

A

AC

AC

ESM

B OK

DDi
I / a g

1 2 1 2
DC 4 4 4 2
OK Gb /
s G/s
b

1 A 1 B 2 A 2 B
Dv e Ch a n n e l
r
i Dv e Ch a n n e l
r
i

SFP interface connectors
Reserved connectors for
ESM indicator lights future use

Figure 2-12 Information Archive Expansion Drawer (2231-D1B) - rear view

The minimum capacity in the Information Archive appliance is 8 TB of raw disk space that is
built with eight (half a drawer) 1 TB disks in the Information Archive Storage Controller
(2231-D1A) enclosure.

The storage is configured as RAID 6, whereby a half drawer, if it is the only storage drawer, is
formatted 5+2 with a global spare; Otherwise it is formatted as 5+2P and 6+2P with one or
two global spares (depending on how many expansion drawers are used, there is an
additional global spare defined starting with the third expansion drawer).

Information Archive comes in configurations with 1 TB or 2 TB disks.
When equipped with 1 TB disks, the raw capacity varies in increments of 8 TB up to
112 TB for the first collection, and from 8 TB up to 96 TB for the second and third
collections.
When using 2 TB disks, the capacity varies in 16 TB increments up to 224 TB for the first
collection and from 16 TB up to 192 TB from the second and third collections.


Figure 2-13 shows the location of the storage within the Information Archive appliance.

2231 IA3 2231 IS3
36 R SM S e rv e r (F C 5 6 0 1 ) M a n d a to r y 36 D 1 B D is k E xp # 2 -5 O p t io n a l
35 D 1 B D is k E xp # 1 -6 O p t io n a l 35 ( o p tio n a l)
34 ( o p tio n a l) 34 6+2P; 6 + 2 P
33 6 +2 P ; 6 +2 P 33 D 1 B D is k E xp # 1 -5 O p t io n a l
31 ( o p tio n a l) 31 6+2P; 6 + 2 P
28 ( o p tio n a l) 28 6+2P; 6 + 2 P
25 ( o p tio n a l) 25 6+2P; 6 + 2 P
24 5+2P ; S ; 6+2P 24 D 1 B D is k E xp # 2 -3 O p t io n a l
23 23 ( o p tio n a l)
22 22 5 + 2 P; S ; 6 + 2 P
21 K e y b d , M o n ito r , KV M M a n d a to r y 21 D 1 B D is k E xp # 1 -3 O p t io n a l
20 T wo 24 por t B roc a de S A N 24 B 4 O p t io n a l 20 ( o p tio n a l)
19 F C s witc hes (o ption al b ut pai red ) O p t io n a l 19 5 + 2 P; S ; 6 + 2 P
18 M g m t S e rv e r ( F C 5 6 0 0 ) M a n d a to r y 18 D 1 B D is k E xp # 2 -2 O p t io n a l
17 T wo S M C 812 6L 2 26 p or t M a n d a to r y 17 ( o p tio n a l)
E th er net 1 0/100 /1G S w
16 M a n d a to r y 16 6+2P; 6 + 2 P
( 46M 217 5)
15 S 2 M S e rv e r M a n d a to r y 15 D 1 B D is k E xp # 1 -2 O p t io n a l
14 14 ( o p tio n a l)
13 S 2 M S e rv e r O p t io n a l 13 6+2P; 6 + 2 P
12 (opt 1) 12 D 1 B D is k E xp # 2 -1 O p t io n a l
iP D U

iP DU

iP D U

iP D U
11 S 2 M S e rv e r O p t io n a l 11 ( o p tio n a l)
10 (o p t 2 ) 10 6+2P; 6 + 2 P
9 D 1 B D is k E xp # 1 -2 O p t io n a l 9 D 1 B D is k E xp # 1 -1 O p t io n a l
8 ( o p tio n a l) 8 ( o p tio n a l)
7 6 +2 P ; 6 +2 P 7 6+2P; 6 + 2 P
6 D 1 B D is k E xp # 1 -1 O p t io n a l 6 D 1 A D is k C tr lr # 2 O p t io n a l
5 ( o p tio n a l) 5 ( o p ti o na l )
4 6 + 2 P; 6 5 + 2 P 4 5 + 2 P; S ; 6 + 2 P
3 D 1 A D is k C tr lr # 1 M a n d a to r y 3 D 1 A D is k C tr lr # 1 M a n d a to ry
2 2
1 5+2P ; S ; 6+2P 1 5 + 2 P; S ; 6 + 2 P
1 1 2 T B R a w (1 T B H D D s ) 1 9 2 T B R a w (1 T B H D D s )
8 2 T B U s e r (R A ID 6 ) M a n d a to r y 1 4 0 T B U s e r (R A ID 6 ) M a n d a to ry

Figure 2-13 Rack population for 2231-IA3 and 2231-IS3

2.2.6 Information Archive SAN switches
The SAN switches used in Information Archive are IBM System Storage SAN Switch
2498-B24. They are used to interconnect the cluster nodes with the Storage Controller and
optionally, Fibre Channel-based tape solutions.

The SAN switches are optional, but must be installed in pairs. For Enhanced Remote
Mirroring configurations (with Remote Mirroring to a secondary Information Archive), the SAN
switches are required.

SAN switches are also required when Information Archive is configured with three cluster
nodes, or for three collections (that is three storage servers). Indeed, for those configurations,
a direct connection is no longer possible.


Each SAN switch is a 24-port high performance auto-sensing Fibre Channel switch. With next
generation switch technology, these switches are designed to provide improved availability
capabilities, fully non-blocking performance, and advanced intelligence features. The
Information Archive SAN Switch provides 1, 2, or 4 Gbps link speed. The port speeds can be
set to any of these values or can be set to auto-negotiate the highest speed that the attaching
devices support. In Information Archive, the cluster nodes and the Storage Controller ports
operate at 4 Gbps. Figure 2-14 shows the SAN switch.

System Status LED
FC ports (24)
RS-232 console
FC status LEDs
port

USB port AC Receptacle
Power indicator LED

Ethernet port

Figure 2-14 Information Archive SAN switch (IBM System Storage SAN Switch 2498-B24)

The required Fibre Channel cabling between the cluster nodes and the storage controllers is
done by manufacturing for the 2231-IA3 frame. If you ordered an optional 2231-IS3 frame with
additional storage controllers, your IBM Support representative will perform the required
interconnection cabling. The customer does not have to perform any reconfiguration at
installation time. In addition, the zoning definitions are also done at manufacturing time.

Security: Although technically possible, it is best not to share the Information Archive
fabric or fabrics with other fabrics for attaching non-IA components, such as external
servers or storage devices. Doing so compromises the security of the Information Archive
appliance and can have implications on third-party compliance certifications.

2.2.7 Information Archive Ethernet switches
Information Archive has all the required internal Ethernet connections preconfigured and
wired.

Information Archive includes an internal Ethernet network for some connections between the
cluster nodes, the storage controllers, the RSM server for IA, the management node, and the
iPDUs. These connections are realized through two Ethernet switches. Those are SMC 8126
L2 26 port Ethernet switches.

TCP/IP addresses: Do not change the internal TCP/IP addresses. What specific port is
being used for connecting to the internal Ethernet switch is important.


Figure 2-15 shows a picture of the Information Archive Ethernet switch.

Status LEDs RJ45 ports (26) Console port

SFP slots

Figure 2-15 Information Archive Ethernet switch

The Information Archive Ethernet switch is an intelligent layer 2 switch with 26 10/100/1000
BASE-T port. Ports 21 up to 23 are available twice (combo ports). It is possible to plug in
Small Form Factor Pluggables (SFPs) to the bottom rightmost four ports, so that you can use
GB Ethernet fibre for long distance.

The SFP slots are shared with four of the RJ-45 ports (ports 21 to 23). If an SFP transceiver
is present in a slot and has an active link, the corresponding RJ-45 port is disabled and
cannot be used.

2.2.8 Console kit
The Information Archive console kit is an IBM 1735-3LX rack-mounted flat panel console kit
and consisting of the following components:
One 17.0 inch (337.92 x 270.332 mm) backlit panel technology, with a maximum
resolution of 1280 x 1024 at 75 Hz
One rack keyboard tray
IBM keyboard with integrated pointing device
One Keyboard Video Mouse (KVM) switch

The KVM switch is packaged as a 1U kit and is mounted in the rack along with the other
Information Archive components. The KVM switch is mounted in the same rack space,
located behind the flat panel monitor. The keyboard is configured for English. An integrated
mouse is included in the keyboard. The cluster nodes, the RSM server for Information
Archive, and the Management Console are connected to the KVM switch, so that the monitor
and keyboard can access all of the servers in the Information Archive appliance.


2.3 Software components
The following major software components are installed in Information Archive by
manufacturing:
IBM Tivoli Storage Manager
IBM System Storage Archive Manager
General Parallel File System (GPFS)
IBM Systems Director
RSM for Information Archive
DS Storage Manager Client for Information Archive

Important: Do not upgrade any of the software components manually or individually. In
Information Archive, such an upgrade must always be done as part of the overall
Information Archive software upgrade.

The various software components are described in subsequent sections.

2.3.1 IBM Tivoli Storage Manager
IBM Tivoli Storage Manager is a client/server program that provides centralized, automated
data protection and storage management solutions to customers in a multivendor computer
environment. IBM Tivoli Storage Manager provides a policy-managed backup, archive, and
space-management facility for file servers, workstations, applications, and application
servers.

The Tivoli Storage Manager in Information Archive serves two purposes:
It provides tiered storage for Information Archive collections where files might be migrated
and compressed to disk and tape. This is accomplished by deploying IBM Tivoli Storage
Manager Hierarchical Storage Management (HSM) clients on the GPFS cluster nodes.
It helps retain compatibility with IBM's previous archiving product, the IBM DR550, by
using a dedicated, special version of the IBM Tivoli Storage Manager server, known as the
IBM System Storage Archive Manager.

2.3.2 IBM System Storage Archive Manager
The IBM System Storage Archive Manager is designed to provide archive services, prevent
the loss of critical data, and protect data from being erased or overwritten.

The IBM System Storage Archive Manager is used to provide and manage retention
(archiving) of data. It is not meant to be a backup solution.

For applications that use the IBM Tivoli Storage Manager API, policy-based data
management capabilities are already available. With IBM System Storage Archive Manager,
you can also prevent data deletion before retention criteria are met. Content management
and archive applications can use the IBM System Storage Archive Manager client API to
apply business policy management for ultimate deletion of archived data at the appropriate
time.

Tip: IBM System Storage Archive Manager is the same software as the IBM Tivoli Storage
Manager, but with the archiveretentionprotection attribute set to on.


2.3.3 General Parallel File System (GPFS)
The General Parallel File System (GPFS) is a high performance shared-disk file management
solution that provides fast, reliable access from nodes in a cluster environment. Parallel and
serial applications can readily access shared files using standard UNIX® file system
interfaces, and the same file can be accessed concurrently from multiple nodes. GPFS is
designed to provide high availability through logging and replication, and can be configured
for failover from both disk and server malfunctions. GPFS scalability and performance are
able to meet the needs of data intensive applications. GPFS provides high-performance
enterprise file management with the following features:
Seamless capacity expansion to handle the explosive growth of digital information and
improve efficiency through enterprise wide, interdepartmental information sharing
High reliability/availability to eliminate production outages and provide disruption-free
maintenance and capacity upgrades
Performance to satisfy the most demanding applications
Policy-driven automation to ease information life cycle management
Extensible management and monitoring infrastructure to simplify file system
administration
Cost-effective disaster recovery and business continuity

GPFS is used as a core Information Archive system software and runs on the Information
Archive cluster node servers. The overall Information Archive solution benefits from the high
performance, scalability, and robustness of the GPFS while hiding its internal complexities
from the Information Archive appliance users and administrators.

2.3.4 Remote Support Manager for Information Archive
The IBM Remote Support Manager for Information Archive, also called RSM server for
Information Archive, is an application installed on the RSM server (iarsm1) running Novell
SUSE Linux Enterprise Server 10. The version used in Information Archive differs from the
standard version to fulfill compliance requirements.

The problem reporting feature provided by RSM for Information Archive automatically creates
an entry in the IBM call management system for the 2231-IA3 with details to the 2231-D1A
that reports a problem. This is the equivalent of placing a voice call to IBM Service for a
problem. When problems are in the system, they are responded to with the same priority as
specified by the maintenance agreement in place for the product. Management and
configuration tasks are explained in “RSM server for Information Archive” on page 381.

2.3.5 DS Storage Manager for Information Archive
The DS Storage Manager for Information Archive software (here after referred to as DS
Storage Manager) is installed on the Management Console. This special version of DS
Storage Manager is used to support centralized management of the storage controllers in


Generally speaking, DS Storage Manager enables administrators to quickly configure and
monitor their Information Archive Storage Controller from either a command line interface or a
Java™-based graphical user interface. It is designed to enable storage administrators to
customize and change settings, configure new volumes, define mappings, handle routine
maintenance, and dynamically add new enclosures and capacity to existing volumes without
interrupting user access to data. It is also used to configure, monitor, and maintain Enhanced
Remote Mirroring. Failover drivers, performance-tuning routines, and cluster support are also
standard features of the DS Storage Manager.

Important: Do not upgrade the Storage Controller firmware manually. In the Information
Archive appliance, such an upgrade must be done as part of the overall Information
Archive software upgrade.

2.3.6 IBM Systems Director
The IBM Systems Director is an integrated, easy-to-use suite of tools that provide customers
with flexible systems management capabilities to help realize maximum system availability
and help lower IT costs. With IBM Systems Director, IT administrators can view and track the
hardware configuration of remote systems in detail and monitor the usage and performance
of critical components, such as processors, disks, and memory.

Generally speaking, the IBM Systems Director provides the following capabilities:
Unifies the essential management of IBM servers, storage, and network devices delivering
a consistent look and feel for common management tasks that reduces operational
complexity
Integrates the IBM best-of-breed virtualization capabilities to provide new ways to simplify
the management of physical and virtual platform resources
Reduces energy costs and usage by monitoring and managing the energy and cooling
needs of various servers and storage
Easy integration with enterprise service management tools from Tivoli as well as other
third-party providers.

2.3.7 Integrated Solutions Console
Integrated Solutions Console provides a single, common interface for system administration.
It provides the main platform on which IBM and non-IBM products can build administrative
user interfaces as individual plug-ins to a common console framework. Standardizing product
administration functions to run on the Integrated Solutions Console platform gives them a
more common look and feel and a more consistent behavior, thereby reducing the learning
curve and adoption as new management components are introduced. Administrators can
interact with multiple IBM and non-IBM products from a single browser-based console.

Consistency across administrative interfaces
Integrated Solutions Console provides a common appearance (for example, theme, layout
and banner) and behavior (for example, navigation and authentication) to enable consistent
user interaction for administering software products.


A standards-based architecture
Integrated Solutions Console provides a standards-based architecture for web administration.
Each Integrated Solutions Console module consists of one or more web applications that
have access to services within the Java 2 Enterprise Edition (J2EE) environment provided by
IBM WebSphere® Application Server. The help interface is implemented using the Eclipse
open standard. Console modules are developed using the Java Portlet Specification.

Easy deployment of product administration consoles
The Integrated Solutions Console framework provides an XML-based interface for deploying
console modules to a console installation. XML descriptors provide the information needed to
deploy the portlet, resources, and set up the page layout and navigation in the console. A
console module can be easily removed without impact to the remaining console modules.

2.4 Storage configuration
This section describes the Information Archive Storage Controller and expansion drawers.

2.4.1 Storage controller configuration and management
The DS Storage Manager will be used to administrate storage controllers and is used for
monitoring and repair.

The Information Archive is shipped with a special version of the DS Storage Manager for
Information Archive (SMclient) installed on the Information Archive Management Console.
The SMclient has been modified to provide additional security to protect against deletion of
archived data either by accident or by malicious intent, using the SMclient. Figure 2-16 shows
that the delete logical drive and delete array functions, for example, are not visible in the
menu because these functions have been disabled.

Figure 2-16 DS Storage Manager - No delete logical drive or array function


There are two possibilities to start the SMclient graphical user interface:
The interface can be started directly local at the Management Console. Connect the flat
panel monitor to the Management Console by pressing the Print Screen key (alternatively,
by pressing Ctrl twice) on the keyboard and selecting the appropriate entry from the
window. Log in to Management Console as iaadmin. Then open a terminal window
(xterm) and enter sudo SMclient.
The other way is to start the SMclient remote. For this, you need an X-Server at your
remote computer, then open an ssh client such as putty to make a connection to the
Management Console as shown in Figure 2-17. Enter sudo SMclient to start the DS
Storage Manager. For detailed information, also see 4.2.1, “Accessing the system” on
page 95.

Figure 2-17 Start of the DS Storage Manager

After a few seconds, the DS Storage Manager main window (Figure 2-18) is displayed. To
open the subsystem management window, left-click a subsystem in the navigation panel on
the left (for example, Storage Subsystem iastorage1a), right-click, and select Manage Device
from the menu (or just double-click the Storage Controller name).

Figure 2-18 DS Storage Manager - Main Window


2.4.2 Storage configuration and partitioning for Storage Controller
This section introduces common management concepts and basics associated with storage
configuration using Storage Controller (2231-D1A). In parallel, we explain the preconfigured
configuration used for Information Archive.

Storage configuration for the Storage Controller (2231-D1A) is accomplished by means of
storage arrays and logical drives. An array is a set of drives that the controller groups logically
together to provide capacity for logical drives accessed by an application host or cluster.

A logical drive (or volume) is a logical structure that you create on the controller. Creating
arrays and logical drives is one of the most basic steps and is required before you can start
using the physical disk space, that is, you divide your disk drives into arrays and create one or
more logical drives inside each array. For Information Archive, those activities are done by
manufacturing.

Arrays and volumes: The Information Archive Machine Type 2231 Models ordered with
Storage Controller (2231-D1A) come with the arrays and volumes predefined.

RAID levels and array configuration
Redundant Array of Independent Disks (RAID) is a method of configuring multiple disk drives
in a storage subsystem for high availability or high performance, or a combination of both.
These goals are sometimes mutually exclusive and are attained by technologies called
striping (performance enhancer) and mirroring (redundancy and availability). There are
various RAID levels that implement combinations of these technologies.

For reasons of performance, fault tolerance, capacity, and storage efficiency, the Information
Archive appliance is configured with RAID 6 arrays.

RAID 6: The Information Archive uses only RAID 6 arrays.

RAID 6, by definition, means that for each array preconfigured in the Information Archive
appliance, two physical drives are reserved for parity (see Figure 2-19 and Figure 2-20).

Hot-spare drive
Hot-spare drives provide additional protection that might be essential in case of a disk drive
fault. A hot-spare drive is similar to a standby replacement drive. The data from the failed disk
drive is automatically rebuilt by the controller to the hot-spare drive, and the spare takes the
place of the failed one. When the failed drive is eventually replaced with a new one, the data
from the hot-spare drive is copied back to the new drive, and the hot-spare drive goes back to
its role as a replacement drive. It is important to note that the DS4000® series (such as the
DS4200 used in the Information Archive appliance) uses global hot-spares, meaning that they
can take over for any failed drive regardless of its enclosure.

For Information Archive, there is one global hot-spare defined in the first array of each storage
controller, and the first array of any additional third expansion drawer.

Upgrades: At the time of writing, there is no possibility for field capacity upgrades. Any
specific capacity configuration must be ordered as such from manufacturing.


Figure 2-19 shows the possible 1 TB disk configurations in Information Archive (remember
that each collection, with a maximum of three, must have its dedicated storage controller).

Mixing 1 TB and 2 TB drives within one enclosure is not supported. If you have any 2 TB
drives in your system, you can only add 2 TB drives in the future.

First Collection Second and third collection

Disks Usable capacity Disks Usable capacity

D1A w 8 drives 8 4 8 5
D1A w 16 drives 16 10 16 11

D1B #1 w 8 drives 24 16 24 17

D1B #1 w 16 drives 32 22 32 23

D1B #2 w 8 drives 40 28 40 29

D1B #2 w 16 drives 48 34 48 35

D1B #3 w 8 drives 56 39 56 40

D1B #3 w 16 drives 64 45 64 46
D1B #4 w 8 drives 72 51 72 52

D1B #4 w 16 drives 80 57 80 58

D1B #5 w 8 drives 88 63 88 64

D1B #5 w 16 drives 96 69 96 70 TB
D1B #6 w 8 drives 104 75
1 © 2009 IBM Corporation
D1B #6 w 16 drives 112 81 TB

Figure 2-19 Disk calculation with 1 TB disks

Figure 2-20 shows the possible disk configuration and capacities with 2 TB disks.

First Collection Second and third collection

Disks Usable capacity Disks Usable capacity

D1A w 8 drives 16 9 16 10

D1A w 16 drives 32 21 32 22

D1B #1 w 8 drives 48 33 48 34

D1B #1 w 16 drives 64 35 64 46

D1B #2 w 8 drives 80 57 80 58

D1B #2 w 16 drives 96 69 96 70

D1B #3 w 8 drives 112 79 112 80

D1B #3 w 16 drives 128 91 128 92

D1B #4 w 8 drives 144 103 144 104

D1B #4 w 16 drives 160 115 160 116

D1B #5 w 8 drives 176 127 176 128

D1B #5 w 16 drives 192 139 192 140 TB

D1B #6 w 8 drives 208 151

1
D1B #6 w 16 drives 224 163 TB © 2009 IBM Corporation

Figure 2-20 Disk calculation with 2 TB disks


Volume mapping
As you can see from the DS Storage Manager for Information Archive mappings view in
Figure 2-21, all volumes (LUNs) are mapped to the host group iagroup. This means that all
logical drives created on the arrays are available to all cluster nodes attached to the Storage
Controller (2231-D1A).
The LUN utilfs is used to store the configuration and log data.
The LUNs iadata 85_1 and iadata 85_2 are used for (user) archive data, and are
configured as a GPFS file system. Depending on your configuration (number of storage
servers and expansion, there can be additional iadata_85_x LUNs).
The LUN iarecovery (30 MB) is used to bootstrap GPFS in a Disaster Recovery /
Enhanced Remote Mirroring configuration.

Figure 2-21 DS Storage Manager - volume mapping

Preferred path: The Storage Controller (2231-D1A) has two disk controllers (A and B) for
redundancy. All logical drives created on the Information Archive Storage Controller are
accessible from either of the two controllers, as installed. Each FC HBA has one or more
paths to Controller A of the Information Archive Storage Controller. Similarly, the other FC
HBA has one or more paths to Controller B. In case of a path failure, meaning either a FC
HBA failure, switch failure, SFP, fiber link failure, or even a Storage Controller failure, the
logical drives are accessible on the remaining paths. For performance reasons, the preferred
paths are distributed between the controllers automatically.

2.4.3 Enhanced Remote Mirroring
The Enhanced Remote Mirroring option is available as a feature of Information Archive. This
option is used for online, real-time replication of data between data retention subsystems at
various locations. In the event of a disaster or an unrecoverable error at one data retention
subsystem, you can promote the second data retention subsystem to take over responsibility
for normal I/O operations. See Chapter 12, “Enhanced Remote Mirroring” on page 461 for
details.

2.5 Cabling / SAN zoning / TCP/IP addressing
When ordering an Information Archive, components in the rack are already wired (internal
Ethernet and SAN fabric, power connections, and so on). SAN zoning, TCP/IP addresses, net
masks, and other network parameters are also preconfigured in manufacturing.


The settings and cabling done by manufacturing depend on the exact configuration ordered
(storage capacity, number of cluster nodes, optional SAN switches, Enhanced Remote
Mirroring, and so on). The following sections show the most typical configurations.

Important: Cabling diagrams are shown here for information only. Customers must not
change any of the cabling or other settings done by manufacturing.

2.5.1 KVM cabling
The KVM switch allows you to access directly various Information Archive components (while
being physically located at the Information Archive appliance). It allows you to attach the
keyboard, mouse, and monitor to the Management Console and any of the cluster nodes or
the RSM server. The cabling for a 3-node cluster is depicted in Figure 2-22.

Slot 1 1 Slot 2 2 1
RSM
SM E3 E4 E1 E2 Video Serial U1 U2
P P Server

KVM Switch
S
S VID 1 3 5 7 ARI (to
P W= U1 2 4 6 8 Servers)
CF K M
M ACI
U2

Slot 1 1 Slot 2 2 1
Management
P P Console

Slot 1 2 1 Slot 3 2 1
Slot 2 2 1 Slot 4 2 1
Cluster Node P P
#1 SM E3 E4 E1 E2 Video Serial U1 U2

Slot 1 2 1 Slot 3 2 1
Cluster Node Slot 2 2 1 Slot 4 2 1
#2 P P

Slot 1 2 1 Slot 3 2 1
Cluster Node Slot 2 2 1 Slot 4 2 1
#3 P P

Figure 2-22 IBM 2231-IA3 - cabling the KVM switch with cluster nodes


2.5.2 SAN cabling
The Information Archive appliance includes two SAN switches or none. The SAN switches
allow an internal SAN fabric interconnecting the Information Archive cluster nodes to the
Information Archive storage controllers (up to three). The SAN switches also provide
connectivity for Remote Mirroring (DR configuration) and external tape attachment (for
backup or archive migration from disk).

System diagrams
Figure 2-23 shows the cabling from the cluster nodes to the SAN switches.

SAN Cabling - IA Cluster Nodes to Disk

Mgmt Eth
SAN
Switch # 2

Mgmt Eth
SAN
Switch # 1

Slot 1 2 1 Slot 3 2 1 Cluster Node
#1
Slot 2 2 1 Slot 4 2 1

P P

#2
Slot 2 2 1 Slot 4 2 1

P P

#3
Slot 2 2 1 Slot 4 2 1

P P

Figure 2-23 Cabling from the cluster nodes to the SAN switches for disk


Port 1 from the FC HBA in slot 2 of each cluster node is connected to SAN switch #2, while
port 1 from the second FC HBA in slot 3 of each cluster node is connected to SAN switch #1.
This provides a redundant path to the storage controllers from any single cluster node.

Figure 2-24 shows the cabling from the SAN switches to the disk controllers. As previously
mentioned, all the cabling is done by manufacturing.

SAN Cabling - Disk Side

Mgmt Eth
SAN
Switch # 2

Mgmt Eth
SAN
Switch # 1

2 1 2 1
CtrlB
CtrlA
1 2

DS4200 #2 1 2

2 1 2 1 2 1 2 1
CtrlB CtrlB
CtrlA CtrlA
1 2 1 2

DS4200 #1 1 2 DS4200 #1 1 2

IA3 Rack IS3 Rack

Figure 2-24 Cabling from the SAN switches to the storage controller

Figure 2-25 shows FC cabling for tape, between cluster nodes and SAN switches.

Port 2 from the FC HBA in slot 2 of each cluster node is connected to SAN switch #2, while
port 2 from the second FC HBA in slot 3 of each cluster node is connected to SAN switch #1.
This provides a redundant path to optional tape devices from any single cluster node

Note that for tape, cabling to switch is NOT mandatory. Direct connection to customer tape or
external switch is permitted.


SAN Cabling - IA Cluster Nodes to Tape

Mgmt Eth
SAN
Switch # 2

Mgmt Eth
SAN
Switch # 1

#1
Slot 2 2 1 Slot 4 2 1

P P

#2
Slot 2 2 1 Slot 4 2 1

P P

#3
Slot 2 2 1 Slot 4 2 1

P P

Figure 2-25 FC cabling for tape

Figure 2-26 shows SAN ports reserved on the switches for attachment of tape devices, or for
a DR configuration (Enhanced Remote Mirroring).

S witch ports 12: to rem ote mirror s witch ports 1 2
S witch ports 9 and 1 1: to ex terna l ta pe drives & libra ries

X3 X5

S w# 2

IA3 E IA 20

X1

X4 X6

S w #1

IA3 EI A 19

X2

Figure 2-26 IBM 2231-IA3 SAN switch external cabling


For more information, see Chapter 10, “Tape attachment with IBM Information Archive” on
page 403.

Zoning
Zoning for the SAN switches in Information Archive is preconfigured as shown in Figure 2-27
for the server to disk configurations.

Fibre Switch Zones
FC Switch# FC Switch#
[=Domain#] Device Port [=Domain#]
Zone Name Server Port (cable) (port#) (cable) (port#) Use Switch Zone Ports
IA3 D1A#1 Left H1
(C1) Sw #2 (port 4)

IS3 D1A#1 Left H1 Server HBA to
S1L S2M#1 port 1 slot 2 (S1) Sw #2 (port 0) Sw #2 (port 5) Disk Storage Ports 0, 4, 5, 6 Sw#2
(C3)
IS3 D1A#2 Left H1
Sw #2 (port 6)
(C5)
IA3 D1A#1 Right H1
Sw #1 (port 4)
(C2)
IS3 D1A#1 Right H1 Server HBA to
S1R S2M#1 port 1 slot 3 (S2) Sw #1 (port 0) Sw #1 (port 5) Ports 0, 4, 5, 6 Sw#1
(C4) Disk Storage
IS3 D1A#2 Right H1
Sw #1 (port 6)
(C6)
IA3 D1A#1 Left H1
Sw #2 (port 4)
(C1)
S2L S2M#2 port 1 slot 2 (S3) Sw #2 (port 1)
(C3)
Sw #2 (port 5)
Disk Storage
Ports 1, 4, 5, 6 Sw#2
IS3 D1A#2 Left H1
Sw #2 (port 6)
(C5)
IA3 D1A#1 Right H1 Sw #1 (port 4)
(C2)
S2R S2M#2 port 1 slot 3 (S4) Sw #1 (port 1)
(C4)
Sw #1 (port 5)
Disk Storage
Ports 1, 4, 5, 6 Sw#1

IS3 D1A#2 Right H1 Sw #1 (port 6)
(C6)
IA3 D1A#1 Left H1 Sw #2 (port 4)
(C1)
S3L S2M#3 port 1 slot 2 (S5 Sw #2 (port 2)
(C3)
Sw #2 (port 5)
Disk Storage
Ports 2, 4, 5, 6 Sw#2

IS3 D1A#2 Left H1
(C5) Sw #2 (port 6)
IA3 D1A#1 Right H1
Sw #1 (port 4)
(C2)
S3R S2M#3 port 1 slot 3 (S6) Sw #1 (port 2) Sw #1 (port 5) Disk Storage
Ports 2, 4, 5, 6 Sw#1
(C4)
IS3 D1A#2 Right H1
Sw #1 (port 6)
(C6)

Figure 2-27 SAN switch zones - server to disk


2.5.3 Ethernet connectivity
All of the Information Archive components are connected over an internal, private Ethernet
network. This IP network is used for management of the cluster nodes, RSM server,
Management Console, storage controllers, switches, and power.

Figure 2-28 shows the internal Ethernet network connecting the Information Archive cluster
nodes, RSM server, and Management Console to the internal Ethernet switches.

Slot 1 1 Slot 2 2 1

P P

Slot 1 1 Slot 2 2 1

P P

Ethernet Ports: 10/100/1000 RJ45
Ethernet 1 3 5 7 9 11 13 15 17 19 21 23 25 26 Console
Switch # 2 2 4 6 8 10 12 14 16 18 20 22 24 21 22 23 24

Switch # 1 2 4 6 8 10 12 14 16 18 20 22 24 21 22 23 24

#1
Slot 2 2 1 Slot 4 2 1

P P

#2
Slot 2 2 1 Slot 4 2 1

P P

#3
Slot 2 2 1 Slot 4 2 1

P P

Figure 2-28 Ethernet connectivity - 3 node cluster, RSM server, and Management Console


The Ethernet connections to each of the storage controllers (Ctrl A and Ctrl B) are depicted in
Figure 2-29 for an Information Archive configuration with three storage controllers (one in the
base frame, the other two in the expansion frame.

Ethernet Cabling - Storage controllers

Switch # 2 2 4 6 8 10 12 14 16 18 20 22 24 21 22 23 24

Switch # 1 2 4 6 8 10 12 14 16 18 20 22 24 21 22 23 24

2 1 2 1
CtrlB
CtrlA
1 2

DS4200 #2 1 2

2 1 2 1 2 1 2 1
CtrlB CtrlB
CtrlA CtrlA
1 2 1 2

DS4200 #1 1 2 DS4200 #1 1 2

IA3 Rack IS3 Rack

Figure 2-29 Ethernet connectivity to storage controllers


The internal Ethernet network is also use for power control of the various components. The
connections as well as the ports used on the internal Ethernet switches are shown in
Figure 2-30.

Slot 1 1 Slot 2 2 1

P P

Slot 1 1 Slot 2 2 1

P P

Switch # 2 2 4 6 8 10 12 14 16 18 20 22 24 21 22 23 24

Switch # 1 2 4 6 8 10 12 14 16 18 20 22 24 21 22 23 24

#1
Slot 2 2 1 Slot 4 2 1

P P

#2
Slot 2 2 1 Slot 4 2 1

P P

#3
Slot 2 2 1 Slot 4 2 1

P P

Figure 2-30 Ethernet network for components power control (iPDUs not shown)


Adapters used for Ethernet connectivity to the external network for archiving applications to
communicate with the cluster nodes, or for remote Information Archive administration (RSM
server and Management Console) are depicted in Figure 2-31.

External Ethernet – Administration and Data
Ez3 (Fiber) Ez4 (Fiber)

2 1 1
Slot 1 Slot 2 P P
U1 U2
SM E3 E4 E1 E2
RSM server
RSA Video Serial

Ey3 (copper) Ey4 (copper)

Ez1 (Fiber) Ez2 (Fiber)

2 1 2 1
Slot 1 Slot 2 P P Management
SM E3 E4 E1 E2 U1 U2
RSA Serial
Console
Video

Ey1 (copper) Ey2 (copper)

Ew1 (Fiber) Ew2 (Fiber)

Slot 1 2 1 Slot 3 2 1
Slot 2 2 1 Slot 4 2 1

SM E3 E4 E1 E2 U1 U2 P P IA Node
Video Serial

Ex1 Ex2

Figure 2-31 External Ethernet – Administration and Data

You have a choice between copper connection or fiber connection, as indicated:
If you need fiber attachment, you must order a separate “Host Fibre Ethernet Adapter,”
which is an optional feature. Such an adapter is required for all cluster nodes, the
management node, and the RSM server.
If you want to use copper-based cables, with the RJ45 interface, the onboard Ethernet
connectors of the servers will be used and no additional hardware is required.

The customer must provide the Ethernet cables required to connect the appliance to their
network. You can use standard 10/100/1000 copper Ethernet cables (Cat 5e or higher) or
fiber Ethernet cables.

The number of cables required depends on the number of cluster node servers in the
appliance:
One cluster node server: six cables
Two cluster node servers: eight cables
Three cluster node servers: ten cables

Additional network cables are required to configure the remote replication feature and to
connect an optional storage-expansion rack, or tape library.


2.5.4 TCP/IP addresses assigned
The Information Archive appliance uses a range of public TCP/IP addresses to communicate
with the archive client applications and web browsers. The appliance also uses a second pool
of private TCP/IP addresses to communicate among its internal components such as cluster
nodes and storage hardware. The number of public TCP/IP addresses that the appliance
reserves is based on the configuration of the appliance. The following hardware options affect
the number of TCP/IP addresses:
The number of cluster nodes
The number of storage controllers
The number of File Archive Collections
The number of System Storage Archive Manager collections
Using a Disaster Recovery (Enhanced Remote Mirroring-based) configuration

The public TCP/IP addresses that the appliance uses are created and configured during the
Initial Configuration Wizard (ICW). After running the Initial Configuration Wizard, you can
change the IP addresses at any time in the appliance. See 3.5.2, “Running the Initial
Configuration Wizard (ICW)” on page 58.

Attention: The private network that Information Archive uses cannot be customized.
It always uses the TCP/IP range of 172.31.0.1 to 172.31.7.255 (172.30.0.1 for secondary)
with a subnet mask of 255.255.248.0. These TCP/IP addresses are reserved for internal
appliance communications among the components.

Table 2-1 summarizes the various IP addresses assigned to the Information Archive
components.

Table 2-1 IP addresses assigned to Information Archive components
Primary Secondary Description

172.31.3.1 172.30.3.1 iarsm1

172.31.3.2 172.30.3.2 iaconsole1

172.31.1.1 172.30.1.1 ianode1

172.31.1.2 172.30.1.2 ianode 2

172.31.1.3 172.30.1.3 ianode 3

172.31.1.N 172.30.1.N ianodeN

172.31.0.100 172.30.0.100 disk_ctrl_1_a

172.31.0.101 172.30.0.101 disk_ctrl_1_b

172.31.0.102 172.30.0.102 disk_ctrl_2_a

172.31.0.103 172.30.0.103 disk_ctrl_2_b

172.31.0.104 172.30.0.104 disk_ctrl_3_a

172.31.0.105 172.30.0.105 disk_ctrl_3_b

172.31.0.30 172.30.0.30 SAN switch 1

172.31.0.31 172.30.0.31 SAN switch 2

172.31.0.40 172.30.0.40 Ethernet Switch 1


Primary Secondary Description

172.31.0.41 172.30.0.41 Ethernet Switch 2

172.31.0.50 172.30.0.50 IPDU Frame 1left

172.31.0.51 172.30.0.51 IPDU Frame 1 right

172.31.0.52 172.30.0.52 IPDU Frame 2 left

172.31.0.53 172.30.0.53 IPDU Frame 2 right

172.31.3.101 172.30.3.101 IMM-iarsm1

172.31.3.102 172.30.3.102 IMM-iamconsole1

172.31.1.102 172.30.1.102 IMM-ianode1

172.31.1.103 172.30.1.103 IMM-ianode2

172.31.1.104 172.30.1.104 IMM-ianode3

172.31.1.10N 172.30.1.10N IMM-ianodeN

10.0.0.100 10.0.0.200 tcp/ip addresses on MCs for ERM ssh tunnel


3

Chapter 3. Planning and installation
In this chapter we provide planning and installation information for the IBM Information
Archive (Information Archive). This information can help you determine which Information
Archive hardware configuration is needed to meet your business requirements.

We also discuss various planning aspects and Information Archive configuration settings that
you need to prepare for. Those settings must be defined ahead of time when filling out the
configuration worksheet required during the initial configuration.

Finally, we explain the hardware installation steps and the initial configuration tasks.


3.1 Determining how many collections you need
It is possible to define up to three collections for one Information Archive (which, as we have
seen, presumes at least an Information Archive appliance equipped with as many storage
controllers as the number of collections required). Use the information in this section to
determine if you need to create more than one collection to meet your business needs.

The Information Archive supports two archive collection types:
File Archive Collection:
Create a File Archive Collection to archive and retrieve documents using the Network File
System (NFS) protocol. Documents can also be retrieved using the Hypertext Transfer
Protocol (HTTP).
System Storage Archive Manager Collection:
Create a System Storage Archive Manager Collection to transfer files using IBM Tivoli
Storage Manager archive clients or API clients.

You can configure any combination of those collection types in Information Archive. This
means that it is possible to configure three System Storage Archive Manager Collections, or
two System Storage Archive Manager Collections and one File Archive Collection, and so on.

Details about collections can be found in Chapter 5, “System Storage Archive Manager
Collections” on page 115 and Chapter 6, “File Archive Collections” on page 167. For practical
examples, also see Chapter 8, “Integrating IBM Information Archive with archiving
applications” on page 261.

If your archiving needs meet any of the following conditions, you might need to define a
second or even a third collection:
If you want to have a System Storage Archive Manager Collection in addition to a File
Archive Collection, then you must define a second collection. Each collection represents
one collection type.
If the volume of data that you need to archive is larger than the storage capacity available
on one storage controller, you must define a second collection (which also requires
another storage controller). For details about usable capacity, see Figure 2-19 and
Figure 2-20 on page 30.
If you require other collection-wide settings such as auto-commit on or off, you need a
second collection or third collection.

3.2 Hardware configuration planning
The Information Archive consists of the following hardware components:
2231-IA3 Base frame (default):
The base frame holds the following components:
– 2231-S2M cluster nodes (one minimum, three maximum)
– 2231-D1A Disk controller (one)
– 2231-D1B Disk expansion drawer (zero to six)
– Management Console (default)
– RSM server (default)
– SAN switches (optional two)
– Ethernet switches (default two)


2231-IS3 Expansion frame (optional):
The expansion frame holds the following components:
– 2231-D1A Disk controller (one or two)
– 2231-D1B Disk expansion drawer (zero to ten)

The 2231-IS3 expansion frame is required if you want to have more than one document
collection in your IA. The number of collections required also impacts the number of cluster
nodes and storage controllers required.

For more information about hardware components, see Chapter 2, “IBM Information Archive
overview and components” on page 9

At the time of writing, field upgrades are not possible for an Information Archive appliance that
is already deployed. Contact your IBM sales representative for the latest information.

3.2.1 Planning for Information Archive cluster nodes
Use the following guidance to determine the number of cluster nodes and amount of memory
required.

Number of cluster nodes
You can have up to three 2231 S2M cluster nodes in your Information Archive appliance. The
minimum configuration is one cluster node.

The amount of required cluster nodes depends on the number of document collections
required. At a minimum, you must have the same number of cluster nodes as document
collections. You can also have more cluster nodes than document collections for high
availability configurations (a failing node can failover to another working node).

These are possible configurations:
One collection  One, two, or three cluster nodes
Two collections Two or three cluster nodes
Three collections Three cluster nodes

All cluster nodes are installed in the Information Archive base frame (2231-IA3).

Cluster node memory
All cluster nodes have a default memory configuration of 24 GB. If you expect a high workload
on your Information Archive appliance, you can expand the main storage to up to 64 GB per
cluster node (memory expansion feature #4200).

Important: Each of the cluster nodes in one Information Archive appliance must have the
same amount of memory installed.

3.2.2 Disk storage and capacity planning
A collection is a logical object that manages archived data, and each collection is represented
by a file system that requires its own 2231-D1A disk controller. The 2231-D1A disk controller
and the optional expansion drawers provide the storage for the collection file system.

Chapter 3. Planning and installation 45

Disk storage
The minimum storage configuration for a collection consists of a 2231-D1A storage controller
that contains eight disk drives. A pack of eight disk drives can be added to the 2231-D1A
controller for a total of 16 disk drives.

You can add additional disk drives to the collection in eight drive packs. However, for every 16
drives added to the configuration, you must add a 2231-D1B expansion drawer, which, like a
controller, can be half-populated with eight disk drives or fully filled with 16 disk drives. You
can add multiple expansion drawers to the controller for a maximum of six 2231-D1B
expansion drawers in a IA3 frame, or a maximum of five expansion drawers for each storage
controller installed in an 2231-IS3 frame. See 2.4, “Storage configuration” on page 27 for
details.

The base 2231-IA3 appliance frame supports only one storage controller and therefore only
one collection. An expansion frame (2233-IS3) must be attached to the base frame to support
two more collections. The expansion frame can host a maximum of two storage controllers
(fully or half populated) and a maximum of 10 expansion drawers. The expansion drawers
must be evenly distributed between the two controllers allowing for a maximum of five
expansion drawers per collection. Each of the expansion drawers can also be half-populated
(8 disks) or fully populated (16 disks).

Capacity planning
Determine space requirements for your collection(s). You can find valuable information to
calculate the required space in the section, “Estimating space requirements” in the IBM
Archive Introduction and Planning Guide, SC27-2324.

Tip: Carefully consider your future storage requirements when ordering an Information
Archive appliance. If you need to modify the configuration later, it might be necessary to
shut down the appliance while the change is being made.

For example, the appliance must be taken offline to upgrade hardware components, add
storage, or to enable support for some optional features.

The disks operate in a Redundant Array of Independent Disks, RAID 6 configuration to
maintain data integrity even in the event of a disk failure. A RAID 6 array can recover from
single and dual disk drive failures. Because of the RAID 6 configuration, two of every eight
drives are reserved for parity. Also a spare drive is set aside in the first and seventh of eight
drives. Therefore, the usable capacity is reduced by the space which is required for parity
disks and hot spare disks. The remaining usable capacity can vary from 50% up to 70% of the
physical capacity, depending on the hardware configuration.

For details, and a comparison between raw and usable capacity, see Figure 2-19 and
Figure 2-20 on page 30.

The Information Archive V1.1 was delivered with 1 TB disk drives. With Information Archive
V1.2, the disk subsystems are equipped with 2 TB disk drives by default.

A collection with 2 TB disk drives cannot be expanded with 1 TB disk drives.


3.2.3 Planning the network connection type
Information Archive can be connected to copper or fibre cable-based Ethernet network
switches. If you need fibre attachment, you must order a separate “Host Fibre Ethernet
Adapter”, which is an optional feature. Such an adapter is required for all cluster nodes, the
management node, and the RSM server.

If you want to use copper-based cables, with the RJ45 interface, the onboard Ethernet
connectors of the servers will be used and no additional hardware is required.

3.2.4 Planning tape attachment
In this section we provide an overview of tape attachment capabilities for Information Archive.
For tape attachment details, see Chapter 10, “Tape attachment with IBM Information Archive”
on page 403.

Why we use tapes
Depending on the nature of the data or documents archived, it is usually desirable, and often
required to be able to restore the data, in case it is damaged by corruption or disaster. To be
prepared for such situations, you need a copy or a backup of the data, kept at a separate
location. The backup of archived documents to tape has the following advantages:
You can schedule a periodic backup of all archived documents
You can transport and store backup media at off-site locations
You can keep multiple generations of the IBM Tivoli Storage Manager/System Storage
Archive Manager database

In addition, tapes can also be used to extend the storage capacity of your Information Archive
appliance, by migrating documents from disk to tape overtime.

Important: It is highly desirable to have a tape copy or a backup of all archived documents.
Even if you plan to use the Enhanced Remote Mirroring feature, it is a safe practice to use
tape devices to back up the archived data.

Collection capabilities to use tape drives
System Storage Archive Manager Collections and document collections have various
capabilities in using tape drives. Table 3-1 outlines the major differences.

Table 3-1 Tape drive usage capabilities
Use tape drives for: File Archive Collection System Storage Archive
Manager Collection

Backing up archived data No Yes

Migrating documents to tape to extend Yes Yes
storage capacity

Creating an off-site copy of data No Yes

Attention: You cannot use tape drives to back up file document collections. The only
supported method to back up objects in File Archive Collections is to use an external IBM
Tivoli Storage Manager server.


Supported tape drives and libraries
Information Archive supports the same Fibre Channel tape devices as the Linux Tivoli
Storage Manager server except for StorageTek ACSLS and IBM 3494, because those
libraries are not Fibre Channel and require additional software and configuration.

Tape attachment methods
There are multiple ways to attach tape devices to the appliance. The method that you use
depends on the number of tape devices you are attaching, how the devices are shared
among the collections, and the configuration of your network.

Select the attachment method that fits into your environment to determine which features are
needed to use tape and library attachment.

Consider the following options for more information about the requirements:
Direct attach:
In this configuration, a tape device is attached directly to the tape ports of the appliance
cluster nodes. Each cluster node has two ports for tape attachment.
Tape drives cannot be shared with other nodes.
Internal switch attach:
In this configuration, you connect all of the cluster nodes to the appliance Fibre Channel
switches and then connect the tape devices to the Fibre Channel switches.
To use this method, you must order and install feature code 1906 (Fibre Channel switch
kit) and feature code 4520 (activate 8 ports on both Fibre Channel switches).
Each SAN switch has two FC ports reserved for tape, so the maximum number of tape
devices that you can connect to the appliance is four.
External switch attach:
In this configuration, you connect the cluster nodes to a customer-supplied external Fibre
Channel switch.

Tip: Use the internal switch attachment method if you do not need to use more than four
tape devices.

Tape zoning: In an Enhanced Remote Mirroring configuration, Information Archive
provides predefined tape zoning between primary and secondary sites. These zones
enable the usage of tape drives across the sites.

WORM protected tapes
Use WORM protected tapes for your archived data to meet certain compliance requirements.
It is allowed to use RW tapes for IBM Tivoli Storage Manager/System Storage Archive
Manager database backups.

Tape encryption
Consider your security requirements for data copied or moved to tape. If tapes will be moved
to off-site locations, use encrypted tapes for security and compliance. This requires tape drive
hardware that is encryption capable.

For details about tape attachment and other tape related information, see Chapter 10, “Tape
attachment with IBM Information Archive” on page 403.


3.2.5 High availability with additional cluster nodes
You can enhance Information Archive availability by adding additional cluster nodes.

In a single cluster node configuration with only one collection, you are not protected against
hardware errors at the cluster node, and the collection might go offline in such a case. If you
want to reduce this potential risk, you can configure a second cluster node. This node will act
as a standby node and automatically take over the document collection in case of a hardware
error on the primary cluster node.

Nodes needed: In a three node cluster configuration, you need at minimum two nodes up
and running to satisfy the quorum and keep access to all data. In a two node cluster
configuration, only one node is required to keep access to all data.

3.2.6 Planning Enhanced Remote Mirroring configuration
For Information Archive, the optional Enhanced Remote Mirroring feature synchronizes the
Information Archive appliance with a second Information Archive appliance that can assume
the I/O responsibility if the primary appliance becomes unavailable. The secondary appliance
contains a copy of all the files that were archived on the primary appliance so that all files
remain accessible during the outage. Enabling the feature reduces the chances of data loss
and system down time.

Figure 3-1 depicts the Enhanced Remote Mirroring configuration.

Figure 3-1 Enhanced Remote Mirroring overview

Remote replication is enabled by purchasing the Enhanced Remote Mirroring feature key.
The feature must be installed on each of the 2231-D1A storage subsystem in the appliance.


Therefore, if one storage subsystem is mirrored, all of the other storage subsystems in the
Information Archive appliance must be mirrored too.

If you order this optional upgrade, several additional components are included in both the
primary and secondary appliances. These components include shortwave or longwave SFP
transceivers in the SAN switches and additional Fibre Channel cables. You must determine
which SFP type (SW or LW) is required in your environment. You have to purchase the
Enhanced Remote Mirroring enablement for the disk subsystems and the Ports on Demand
feature to enable eight additional ports in the Fibre Channel switch.

Hardware: The hardware, including disk subsystems and cluster nodes for the primary
and secondary appliance, must be configured identically.

3.3 Integration planning
This section discusses planning topics that pertain to the integration and deployment of
Information Archive in a customer environment.

3.3.1 Before creating any collection
The Information Archive supports a maximum of three collections, depending on the number
of disk controllers in the appliance.

Protection: A collection’s document protection settings might prevent you from making
changes after it has been created. Therefore, it is important to determine your collection
requirements before creating any collection.

Keep these considerations in mind before creating any collection on the Information Archive
appliance:
The type of collection:
As previously explained, there are two types of collections (File Archive Collections or
System Storage Archive Manager Collections) supported by Information Archive. The type
must be specified when you create the collection. A collection cannot be converted from
one type to another.
Migrating from a DR550 System Storage Archive Manager archive:
Create a System Storage Archive Manager Collection to transfer files using IBM Tivoli
Storage Manager archive clients or API clients into Information Archive.

Important: If you are migrating files from an existing IBM System Storage DR550 to
Information Archive, do not create a System Storage Archive Manager Collection until
you are directed to do so by the IBM service team that will perform the migration (see
Chapter 13, “DR550 migration” on page 489 for more details).

3.3.2 Document protection levels
When you create a File Archive Collection, you must select a document protection level. The
document protection level determines whether documents stored in the collection can be
deleted before the end of their retention period and whether document retention periods can


be reduced. Select a document protection level that is appropriate for your regulatory
compliance and legal discovery requirements. The level of protection affects all documents
and policies that are contained within the collection.

The protection levels are as follows:
Base:
You can delete documents before their retention period has expired and you can change
the document retention period at any time.
Intermediate:
Documents cannot be deleted until after their retention period has expired, but you can
change the document retention period.
Maximum:
You cannot delete documents until after their retention period has expired and the
document retention period cannot be reduced.

Maximum protection: All System Storage Archive Manager Collections use the maximum
level of document protection. You cannot select another document protection level for
those collections.

3.3.3 System Storage Archive Manager Collections
Be sure to review this section if you plan to use applications that depend on System Storage
Archive Manager Collections.

API client
Information Archive Version 1.2 supports the use of IBM Tivoli Storage Manager API client
versions 5.5 and 6.1.

Requirements for data retention
Information Archive gives you a wide range of options to define the retention criteria and
retention period. Consider the data retention requirements for the various application servers
and type of data that you will archive in your environment. This will facilitate the definition of
the System Storage Archive Manager policies. See “System Storage Archive Manager policy
concepts” on page 130 for more information about retention policies.

Security
In order to make the archived data more secure, the System Storage Archive Manager API
client implements an encryption function, which allows you to encrypt data before it is sent to
the Information Archive System Storage Archive Manager Collection. Consider this option if
your security rules require an encrypted data transfer between clients and Information
Archive. You can find more information about System Storage Archive Manager encryption in
5.3.8, “Encryption” on page 139.

3.3.4 Enhanced Tamper Protection
The Enhanced Tamper Protection feature prevents root access to servers in the Information
Archive appliance. Root access can potentially be used to circumvent document retention
settings and modify or delete archived data.


Consider which level of security is really needed for your environment. Enable Enhanced
Tamper Protection if your policy, local, or regulatory compliance requirements call for a level
of data protection that includes root access prevention.

You can enable the Enhanced Tamper Protection feature during initial configuration of the
appliance, using the Initial Configuration Wizard (ICW).

Important: After being enabled, Enhanced Tamper Protection cannot be disabled.

If you do not enable Enhanced Tamper Protection, you must use other methods to prevent
tampering and you must securely manage the root passwords on all servers in the appliance.

Tip: If you are planning to test the appliance before using it in a production environment,
consider enabling Enhanced Tamper Protection after you have completed testing. This can
make it easier to remove test data from the appliance and to resolve problems that you
might encounter during testing.

If there is a need to gain root authority and Enhanced Tamper Protection is enabled, you have
to call your local IBM support representative.

3.3.5 LDAP considerations
For user access management, you can integrate Information Archive into an existing LDAP
environment.

For Information Archive V1.1, a LDAP server is required for File Archive Collections. With
Information Archive V1.2, the LDAP user management is optional for any collection type.

A user-registry server (LDAP directory server) is not included with the appliance, and must be
separately procured, configured, and managed.

The following user-registry servers are currently supported:
IBM Tivoli Directory Server Version 6
Microsoft Windows® Server 2003-2008 R2 (Active Directory)
OpenLDAP (for example SLES 10 SP2)

For more information about LDAP configuration, see Chapter 7.1, “Introduction to directories
and LDAP” on page 228.

3.3.6 Time server requirements
A Network Time Protocol (NTP) server is used to maintain accurate time in the Information
Archive appliance.

A time server is required to enforce retention policies and to correctly apply time stamps to
audit log events. A time server is included in the appliance, and can be used by external
clients. You can also use an external time server that is maintained by your company and is
accessible through your intranet, or a web-based time server (such as time.nist.gov) that is
available on the Internet.


3.3.7 Backing up the appliance
Information Archive provides several options to enable the recovery of archived data in the
event of a disaster. Depending on the option you choose, some additional planning and site
preparation might be required.

Important: Do not use the Enhanced Remote Mirroring feature to replace collection
backups. Back up all archived data to tape. Regularly backing up the appliance reduces
the risk of data loss. You might have to use write-once-read-many (WORM) tapes to meet
compliance requirements.

For detailed information about the backup and restore procedures for Information Archive
data and collections, see Chapter 11, “Information Archive data backup and restore” on
page 441.

The requirements for backing up archived data differ depending on the types of document
collections you create, as described next.

File Archive Collections
The only supported method to back up the data in File Archive Collections is to use an
external IBM Tivoli Storage Manager server. You can use an existing Tivoli Storage Manager
server or you must install the Tivoli Storage manager on a separate server.

The external IBM Tivoli Storage Manager server must run at a version which supports the
IBM Tivoli Storage Manager client 6.1, which is version installed on the Information Archive
appliance.

All data stored in the File Archive Collection will be backed up to the external IBM Tivoli
Storage Manager server. Data that is migrated to second storage area, or migrated to tape,
will be recalled to the primary storage area and then backed up to the external IBM Tivoli
Storage Manager server.

System Storage Archive Manager Collections
Data stored in System Storage Archive Manager Collections can be backed up directly to an
external tape device. An additional Tivoli Storage Manager server is not required for these
collections. For more information, see 11.1.1, “Backing up System Storage Archive Manager
Collections” on page 442.

3.4 Preparing for installation
This section provides information in preparation for the appliance installation.

3.4.1 General planning considerations
Adequate site planning before the hardware is delivered can help to reduce the risk of
physical installation issues. Site planning has to cover equipment location specifications,
air-conditioning and electrical requirements, raised and non-raised floor determinations, and
determination of cable lengths.
Delivery requirements:
Ensure that your loading dock and receiving area can support the weight and dimensions
of the shipments.


Check the section “Delivery Requirements” in Chapter 2 of the Introduction and Planning
Guide, SC27-2324.
Installation requirements:
Ensure that your planned installation location meets space and floor load requirements.
You can find rack measurements and information about service clearance in the section
“Installation Requirements” in Chapter 2 of the Introduction and Planning Guide,
SC27-2324.
Power requirements:
Determine the correct power outlet requirements, input voltage requirements, power
connector requirements and power consumption for the Information Archive appliance.
Each Information Archive rack requires two power connectors. The plug type of the power
cable depends on the local power standards and requirements.
For details, refer also to the “Power Requirements” section in Chapter 2 of the Introduction
and Planning Guide, SC27-2324.
Network cable requirements:
Obtain the Ethernet cables required to connect the appliance to your network. These
cables are not included with the appliance. You can use standard 10/100/1000 copper
Ethernet cables (Cat 5e or higher) or fiber Ethernet cables, depending on your order.
The number of cables required depends on the number of cluster node servers in the
appliance:
– Two cables for the RSM server
– Two cables for the Management Console
– Two cables for each cluster node
Example:
– One cluster node server: Six cables
– Two cluster node servers: Eight cables
– Three cluster node servers: Ten cables
TCP/IP addresses requirements:
All of the TCP/IP addresses must be on the same network or virtual LAN.
You will need one TCP/IP address for each server and, in addition, a service IP address
for each collection.
For example, for a two cluster node configuration with two collections, you need:
RSM Server = 1 IP address
Management Console = 1 IP address
Two cluster nodes = 2 IP addresses
Two collections = 2 IP addresses
In summary = 6 IP addresses are required.

3.4.2 Initial configuration worksheet
Fill out the initial configuration worksheet before the installation to make sure that all
necessary configuration parameters are defined and that resources will be available when
they are needed. Note the following settings in the initial configuration worksheet:
Appliance name
Time server (NTP)
Type of first collection
Enhanced Tamper Protection


TCP/IP addresses for RSM server, Management Console and cluster nodes
TCP/IP addresses for collections
Netmask
Gateway address
DNS server
LDAP settings (required for File Archive Collections)
Email notification settings
SNMP notification settings

You can find the Initial Configuration work sheet in Appendix B in the Introduction and
Planning Guide, SC27-2324.

3.4.3 Alerting and monitoring
This section lists the requirements to enable the Information Archive call home feature, for the
RSM server and the IBM Systems Director server.

For more information about the RSM server and IBM Systems Director server included with
the Information Archive appliance, as well as their respective call home features, see
Chapter 9, “Monitoring and call home” on page 351.

RSM server for Information Archive
The RSM server provides two possibilities to establish a connection to IBM for call home and
remote support access. You can use a modem line or an SSH connection.

Preparing the modem connection
The optional Modem Card for RSM server (feature code #5622) is required for this connection
type.

To use the optional modem connection, you must provide an analog telephone line dedicated
to the RSM server.

Preparing the SSH connection
Depending on how RSM for Storage is configured, the following ports might have to be open
in an external firewall:
Input:
The internal firewall on the RSM for Storage server allows no inbound connections except
for this one:
nn SSHD
Where nn is the port number (port 22 is the default).
This port is used by the IBM Support Center to remotely access the Information Archive
appliance. To make this port available, you must enable remote support and configure
SSH access. A non-standard port number can also be configured.
443 HTTPS (used to manage RSM for Storage from within the client’s network)
Output:
The internal firewall allows outbound connections on any TCP port, but limits those
connections to the devices that are listed in the RSM for Storage configuration and under
specific conditions, such as when a device is reporting a problem. The following ports are
routinely used:
25 SMTP (used to send RSM for Storage alerts and notifications)
53 DNS (used to send RSM for Storage email notifications)


22 SSH
80 HTTP
443 HTTPS

To use SSH for remote support, it might also be necessary to configure port mapping
between the external firewall and the IP address and inbound port of the RSM server. If a
user name and password are required to authenticate to the firewall, these credentials must
be provided to IBM.

RSM server configuration parameters
During the setup of the RSM server, you will be prompted for several parameters. Prepare this
setup procedure by filling out the RSM for Storage work sheet.

You can find the RSM for Storage work sheet in Appendix C of the Introduction and Planning
Guide, SC27-2324.

The IBM Systems Director, which is included with Information Archive, provides the call home
feature for the appliance nodes. Complete the IBM Systems Director work sheet for the IBM
service representative to install and configure your Information Archive appliance.

You can find the IBM Systems Director worksheet in Appendix D of the Introduction and
Planning Guide, SC27-2324.

3.4.4 Enhanced Remote Mirroring configuration
When planning an Enhanced Remote Mirroring configuration, you must supply the FC cables
that connect the primary and secondary appliance. All optical adapters or SFPs are equipped
with LC connectors.

SAN switch connection
SAN switches are a required feature of Information Archive if you plan to use Enhanced
Remote Mirroring. You must prepare two fibre cables for the Inter-Switch Link (ISL)
connection between primary and secondary side. Each SAN switch will have one ISL
connection which runs at 4 Gbps. The fibre cable type depends on the SFP type that was
ordered.

For mirroring distances over 10 km, you can implement extension technology such as that
available from Brocade or other vendors. These technologies include Dense wavelength
division multiplexing (DWDM), and Coarse wavelength division multiplexing (CWDM). If you
need such extenders, ensure that they are 4 Gbps capable to get the expected performance.

Ethernet switch connection
When two Information Archive appliances are remotely replicated, the connection is running
using the customer network with an SSH protocol communication between primary and
secondary appliance. For this, TCP/IP port 22 needs to be open between the sites.

3.5 Physical installation
The following sequence of steps is required to set up the Information Archive appliance:
1. Perform hardware installation (performed by an IBM service representative).


2. Run the Initial Configuration Wizard.
3. Assign administrative user roles.
4. Change RSM server passwords.
5. Configure call home feature.
6. Configure Enhanced Remote Mirroring feature, if ordered.
7. Attach tape devices, if applicable.
8. Define management classes for System Storage Archive Manager Collections.

3.5.1 Hardware installation (performed by IBM service representative)
Most of the tasks for installing the Information Archive appliance are completed at your
location by an IBM service representative.

As part of the basic services engagement, an IBM service representative will perform the
following tasks:
Unpack and position the appliance.
Optionally connect an IS3 storage expansion rack.
Ensure that all iPDU power connection cords are connected.
Connect the appliance to your Ethernet network.
Start the appliance components in a specified order.
Run the script verify_wellness to verify the correct status of all installed hardware
components.

Example 3-1 illustrates a typical output generated by the verify_welness script

Example 3-1 Output of verify_wellness script
iaadmin@IA-Primary:~> sudo /opt/tivoli/tiam/bin/verify_wellness
Performing Verification of Wellness!
Checking for SAN switch 1
Checking for SAN switch 2
Checking for ethernet switch 1
Checking for ethernet switch 2
Checking for ipdu 1
Checking for ipdu 2
Checking for ipdu 3
Checking for ipdu 4
Checking for DS4200 1
...
...
...
Performing software verification check.
===============================
INFO: The output from this script has been captured in the
/opt/tivoli/tiam/log/setupcheck.Jan_19_10_110844.log file
===============================
The system has passed the wellness verification!


The output from this script has been captured in the
/opt/tivoli/tiam/log/verify_wellness.Jan_19_10_110749 file

Tip: An extended services engagement is also available, which can include migrating data
from an IBM System Storage DR550 to the Information Archive appliance, as well as other
configuration tasks.

3.5.2 Running the Initial Configuration Wizard (ICW)
The Initial Configuration Wizard guides you through the initial setup of the Information Archive
appliance software.

Before starting with the Initial Configuration Wizard, make sure that you have completed the
planning worksheet as mentioned in 3.4.2, “Initial configuration worksheet” on page 54.

In an Enhanced Remote Mirroring configuration, you have to run the Initial Configuration
Wizard on both primary and secondary appliances.

If you plan to use File Archive Collections and require a secure LDAP (LDAPS) connection for
their LDAP server, copy the server certificate file from the LDAP server to a USB flash drive.
You will be asked to mount this USB flash drive later in the procedure.

The verify_wellness script, which runs at the end of the hardware installation, must be
completed successfully and without any errors before you can start the initial configuration of
your Information Archive appliance.

Before actually launching the ICW, you must accept the RSM server license.

RSM server license acceptance
You must accepted the license agreement for the SUSE Linux Enterprise Server (SLES)
operating system on the IBM Remote Support Manager for Storage server. The Initial
Configuration Wizard will not start until this license agreement is accepted.

You must perform the following steps from the console screen at the machine.
1. Click Print Screen and select the iarsm1 from the KVM menu to switch the console
screen to the RSM server.
2. Log in with the user account license and password license.
3. The license terms will automatically appear at the screen. Click the Accept button to
accept.
4. The RSM server will reboot automatically.

Starting the Initial Configuration Wizard
The initial configuration will set IP addresses and names for your appliance.

You must run the Initial Configuration Wizard locally at the Information Archive appliance.
After you complete the wizard, you can perform subsequent tasks remotely using a web
browser.

You must perform the following steps from the local monitor and keyboard at the appliance:
1. Click Print Screen and select the iamconsole1 from the KVM menu to switch the console
screen to the management node.
2. Log in with userid iaadmin and the default password iaadmin.


3. After login, the Firefox web browser opens. The IBM Integrated Solution Console (ISC)
logon window is displayed.
4. Log on to the ISC with userid iscadmin and password iscadmin as shown in Figure 3-2.

Figure 3-2 ISC logon

5. In the navigation tree on the left side of the ISC main window, select Information Archive
Management  Getting Started. An Information Archive administrative interface page,
shown in Figure 3-3, opens with a message indicating that the system must be configured.

Figure 3-3 ISC Welcome -REPLACE

6. This step is only required, if you want to configure secure LDAP connections. If you do not
want to use this feature, proceed with the next step.
If you have copied the certificate file from the client LDAP server to a USB flash drive,
complete the following steps to mount the drive:
a. Insert the flash drive into an open USB port on the Management Console server.
b. Go to the desktop of the Management Console server and open a terminal window.
c. At the Management Console server prompt, enter the following command to obtain the
device name of the USB flash drive: ls /dev/sd*.
d. Enter the following command to mount the device:
sudo mount_usb.py -d /dev/device_name.
e. The USB flash drive is mounted as a read-only device at /media/usb.


Tip: To unmount the device after you complete the Initial Configuration Wizard, use the
following command: sudo umount_usb.py -d /dev/sdb1.

7. Click Configure System (see Figure 3-4) to start the Initial Configuration Wizard.

Figure 3-4 ISC Getting Started

8. On the welcome page for the Initial Configuration Wizard (Figure 3-5), click Next to
continue.

Figure 3-5 Initial Configuration Wizard Welcome

9. Select the radio button I accept to accept the license terms that are displayed for the
Information Archive software, and click Next to continue.


10.In the General dialog window, enter the appliance name, the time server name, or IP
address, and your local time zone. Use the values from the Initial Configuration Planning
Worksheet (Figure 3-6).

Figure 3-6 Initial Configuration Wizard General dialog (part 1)

At the bottom of the same General dialog, select the appropriate check boxes for the
document collection types (file collection or System Storage Archive Manager Collection)
to be enabled. You must select one collection type, at minimum (Figure 3-6). Click Next
when finished.

Figure 3-7 Initial Configuration Wizard General dialog (part 2)

11.Now the Enhanced Tamper Protection page is displayed. Select the radio button on or off
according to your planning worksheet and click Next to continue (Figure 3-8).
You can find a detailed description of Enhanced Tamper Protection in 3.3.4, “Enhanced
Tamper Protection” on page 51.


Tip: Keep Enhanced Tamper Protection off at this time. You can turn on after you have
completed all implementation and test tasks and before placing Information Archive into
production.

Figure 3-8 Initial Configuration Wizard Enhanced Tamper Protection

12.In the Security panel that is displayed (Figure 3-9), change the default passwords for the
user iaadmin and iscadmin. Enter the new passwords and click Next to continue.

Figure 3-9 Initial Configuration Wizard Security panel


13.Enter the IP settings for Information Archive on the panel shown in Figure 3-10.
All IP addresses must be in the same subnet. You can enter a starting address and click
Assign. Then the system will number all nodes and document collections sequentially
beginning with the specified starting IP address. You can also enter the IP addresses
individually. On the right side you must enter domain name, subnet mask, gateway
address and primary DNS server. A secondary DNS server is optional. Click Next, after
you have filled out this panel.

Figure 3-10 Initial Configuration Wizard TCP/IP Settings

14.If you have enabled File Archive Collections in step 10, you now see an LDAP settings
window, as displayed in Figure 3-11, “Initial Configuration Wizard - select LDAP”. Select
the appropriate radio button for your LDAP server type and enter the LDAP server IP
address and choose the protocol, LDAP or LDAPS.
If you choose LDAPS, you have to upload the certificate. The certificate file is on the USB
flash drive that is already mounted. Enter /media/usb/<filename of certificate_file> in the
input field and click Upload,
Now, you have to enter the search distinguished base, the bind distinguished name and
the bind password. The format of the input depends on the selected LDAP server type.


Figure 3-11 Initial Configuration Wizard - select LDAP

Figure 3-12 and Figure 3-13 provide illustrations of possible alternative implementations:
– Figure 3-12, “LDAP Settings Active Directory” shows a sample configuration for
Microsoft Active Directory Service.

Figure 3-12 LDAP Settings Active Directory


– Figure 3-13, “LDAP Settings Open LDAP” shows a sample for the open LDAP
configuration.

Figure 3-13 LDAP Settings Open LDAP

For further information about preparing LDAP servers for use with Information Archive,
see Chapter 7, “LDAP environments” on page 227.

Attention: If you have selected “None (Use Static UID and GID Assignment)”, you
need to administrate locally and manually on the shared file system, users, and groups
that need access.

Click Next, after you have completed your input.
15.In the next ICW dialog window, you can enter the notification method used to monitor
Information Archive. You can activate these notification methods in any combination:
– Select the check box Send events by email, if you want email notification. Then enter
the TCP/IP address and the port address of your mail (SMTP) server and define the
mail addresses of the recipients, as illustrated in Figure 3-14.


Figure 3-14 Initial Configuration Wizard email notification

– Select the check box Send events by SNMP if you want to receive SNMP traps. Enter
the SNMP listener address, the TCP port number and the community name in the
appropriate input fields. See Figure 3-15. The values must match your SNMP server
definitions.
– Mark the check box Send a test notification to immediately send a test message to
the configured destinations, if desired. Click Next to continue.

Figure 3-15 I. initial configuration wizard SNMP notification

16.On the summary window, compare all parameters with your planning worksheet and, if
correct, click Finish to complete the Initial Configuration Wizard, or click Back if you want
to correct your input.

All settings are applied immediately. A reboot is not required.

At this point, you will be able to also access the Information Archive graphical user interface
remotely through an Ethernet network connection. To do so, enter the following web location
in a web browser at a remote workstation:
https://<IP_of_management_node>/ibm/console/logon.jsp


3.5.3 Assigning administrative user roles
Before you can create a new collection, you must define a user and give the appropriate
permissions for that account to perform the create collection action. The default user iscadmin
does not have the authority to create a new collection. Therefore, you must create a new
administrative user.

Within Information Archive, you can define various administrative users and assign them
specific roles.

User accounts: The default iscadmin user account is only intended for use during initial
setup. Create a separate user account for each person who manages the appliance.

If you have an LDAP environment, you must create users or user groups on an external LDAP
server and configure LDAP authentication for administrators first.

If you manage users locally within Information Archive, you have to create all user profiles in
the ISC. If the user already exists in a LDAP environment, you can skip this step and go to the
section, Assign administrative user roles.

Creating a user
To create administrative users and define their roles, perform the following steps:
1. Log on to the administrative interface with userid iscadmin
2. Expand Users and Groups in the navigation tree and click Manage Users.
3. Select Create and enter a user name and define a password. You can also create user
groups at this time.

See 4.1.1, “User and group management” on page 72 to get more information about users
and groups.

Assigning administrative user roles
You can define user roles for locally defined users and also for LDAP users. From the
Information Archive GUI:
1. Select Administrative User Roles.
2. Click Add.
3. Enter the userid that you have created before and select the desired roles.
For a system administrative user, you have to select the following roles:
– Administrator
– tsmAdministrator
– IAArchiveAdministator
– IASystemAdministrator
– adminsecuritymanager
Hold the Strg key while selecting multiple user roles.
Click Apply and Save when finished.

Roles: Each role will enable another subset of functionality. If you want to use all functions,
you have to select all available roles.


See 4.1.1, “User and group management” on page 72 for an overview of all user roles and
their permissions.

The administrative user roles that are assigned to a user or group determine which navigation
items are displayed in the administrative interface.

3.5.4 Changing RSM server passwords
To better secure the appliance and for regulatory compliance, change the passwords for the
IBM Remote Support Manager for Storage server (RSM Server) on a regular basis. You must
manage the root password for this server, even if you enable the Enhanced Tamper
Protection feature.

At the Information Archive local console, follow these steps:
1. Press the Print Screen key to view a list of appliance components. Select iarsm1.
2. Log on to the RSM for Storage server using the root user account, using the default
password.
3. At the RSM for Storage server prompt, enter the following commands. After each
command, you are prompted to enter the current password and a new password:
– passwd root
– passwd admin
– passwd lservice
– rsm-passwd admin
– rsm-passwd lservice

Changing passwords: The passwd commands change the passwords that are used to log
on to the RSM for Storage server command line. The rsm-passwd commands change the
passwords that are used to log on to the RSM for Storage browser interface.

3.5.5 Configuring the call home feature
The call home feature is a communication link that is established between a product and a
service provider. Information Archive provides this feature so that reports can be
automatically sent to the IBM Support Center when critical hardware problems are detected.

When the IBM Support Center receives a call home report, an IBM service representative
contacts your company to work on resolving the problem.

Within Information Archive, you have two components for which you must enable and
configure the call home function:
IBM Remote Support Manager (RSM) for Information Archive:
The RSM server monitors the appliance disk subsystems and provides a remote support
access (dial in) function.
IBM Systems Director:
IBM Systems Director monitors the following appliance components:
– Cluster node servers (2231-S2M)
– Management Console server (2231 feature code 5600)
– RSM server (2231 feature code 5601)

See 9.3.1, “Configuring IBM Systems Director” on page 365 for detailed configuration steps.


3.5.6 Activating SAN switch ports 8 through 15

Attention: If you have not ordered feature code #7200 - ports on demand, to attach tape
drives or use an Enhanced Remote Mirroring configuration, you can skip this section.

Use this section to install the port upgrade license that activates additional Fibre Channel
switch ports on the internal Information Archive SAN switches. These Fibre Channel switch
ports must be enabled before you can connect a tape library or connect the secondary
appliance with the Enhanced Remote Mirroring feature.

Before starting this procedure, check the actual status of the SAN switch ports:
Go to the rear of the appliance and check the LEDs of ports 8 through 15. If SFPs are
plugged in and all LEDs are off, then you must enable these ports before you can use
them.
If all LEDs from port 8 through 15 are off, you need to enter the license activation key.
Locate the document Feature 7200 - Ports on Demand, which is part of the shipping
group. There you will find the instructions on how to download the license activation key
from IBM website and how to enter the activation key into SAN switch. Perform the same
procedure for the secondary SAN switch as well.
If all LEDs from port 8 through 15 are lit yellow, you need to enable these ports:
After you have completed the feature activation, enable ports 8 through 15 by entering the
command portenable N for each port where N is the port you want to activate.
Example: To activate port 9, enter portenable 9.
Repeat this procedure for the appliance secondary Fibre Channel switch.
Ensure that the LED above the newly activated switch ports are lit. If they are not, check
that you have entered the portenable command for the ports that are not lit.

3.5.7 Attaching tape drives and tape libraries
If you want to attach the tape drives to the internal SAN switches, make sure that the SAN
switches ports 8 through 15 are enabled as described above in 3.5.6, “Activating SAN switch
ports 8 through 15”.

Now you can connect external tape drives. The ports where you connect the fibre cables
depend on the connection method used (as explained in 3.2.4, “Planning tape attachment” on
page 47). Refer also to Figure 3-16 on page 70.


The following types of attachment are possible:
Direct attachment:
To connect the tape device directly to the cluster nodes, plug in the cables according to the
following steps (Figure 3-16):
a. Connect a Fibre Channel cable from Slot 2, Port 2 of the cluster node to the Fibre
Channel port on your tape device.
b. Connect a Fibre Channel cable from Slot 3, Port 2 of the cluster node to the Fibre
Channel port on your tape device.
Internal attachment:
To connect the tape device to the internal Fibre Channel switch, plug in the cables
according to the following steps (Figure 3-16):
a. Connect tape devices at Port 9 and 11 of SAN switch 2 (upper SAN switch).
b. Connect tape devices at Port 9 and 11 of SAN switch 1 (lower SAN switch).
External attachment:
To connect the tape device to an external Fibre Channel switch, plug in the cables
according to the following steps:
a. Connect a Fibre Channel cable from Slot 2, Port 2 of the cluster node to your external
Fibre Channel switch.
b. Connect a Fibre Channel cable from Slot 3, Port 2 of the cluster node to your external
Fibre Channel switch.

Figure 3-16 Tape Attachment

3.5.8 Configuring the Enhanced Remote Mirroring feature
For details about configuring Enhanced Remote Mirroring, see 12.2, “Enhanced Remote
Mirroring configuration” on page 464.


4

Chapter 4. System administration and
operations
In this chapter we explain and illustrate important system administration and operation tasks
for the IBM Information Archive (Information Archive), using the Information Archive GUI and
Information Archive CLI.

Here you can find details about the user and group management, passwords management,
software updates, system monitoring, as well as tasks related to RSM and DS Storage
Manager.

We also explain how to start and stop the Information Archive appliance, access the various
Information Archive components, and configure collections. These tasks are normally
performed by an Information Archive appliance administrator and operator.


4.1 Information Archive administration tasks
The tasks described in this section are normally performed by an Information Archive
administrator. These tasks include configuring, managing, and monitoring Information
Archive.

4.1.1 User and group management
The Information Archive includes a set of predefined user roles. These are used to assign
various administrator authority levels. Administrative user roles can only be assigned by a
user that has the adminsecuritymanager role. For example, the default iscadmin user is
assigned this role. Users and groups can be assigned multiple administrative user roles. You
must assign at least one role to each user or user group that will log on to the administrative
interface. Logging on to the administrative interface is only possible as user or user within a
user group.

Authentication ensures that only the designated archive users can read and commit
documents and that only the designated administrators can access the administrative
interface.

Tip: Users who only archive and retrieve documents do not need access to the Information
Archive GUI.

Administrative user roles are always assigned to a user account. In other words, you need to
create a user first before you can assign administrative rights to that user.

The procedure differs depending on whether you create local administrative user accounts or
use an external Lightweight Directory Access Protocol (LDAP) server to authenticate access
to the Information Archive GUI.


Managing users
To create administrative users locally at the Information Archive, logon (as iscadmin) to the
Management Console and complete the following steps:
1. Expand Users and Groups in the navigation tree.
2. If you want to create local user accounts, click Manage Users (see Figure 4-1) and click
Create to add one or more administrative users. The Create a User dialog is displayed
(Figure 4-2). If you are using LDAP, you can skip this step and proceed with “Assigning
administrative user roles” on page 74.

Figure 4-1 Manage Users

3. Enter appropriate data in the corresponding field as illustrated in Figure 4-2, then click
Create. Users can also be part of a user group. Use the Group Membership button to
assign a user group. For more details about user group membership, see “Managing
groups” on page 77.

Figure 4-2 create a user

Chapter 4. System administration and operations 73

Assigning administrative user roles
After you have created the administrative user accounts, you need to assign the proper
administrative roles to those accounts.

Initially you have to log in to Information Archive (through the Information Archive GUI) with
the default predefined user account iscadmin. This user account is only intended for use
during initial setup of the appliance. Use a separate user account for each person who
manages the appliance or accesses audit logs. Administrative user roles can only be
assigned by a user that has the adminsecuritymanager role assigned.

Tip: The default iscadmin user account is only intended for use during initial setup. Create
a separate user account for each person who manages the appliance.

To assign these administrative roles, log on to the system and complete the following steps:

2. Click Administrative User Roles.
3. Click Add and enter the user account that you created in the step “Managing users” or,
to use LDAP authentication, enter the name of a user or user group that is defined on the
external LDAP server.
4. Select the required administrative roles for the specific user, as shown in Figure 4-3.

Figure 4-3 Add administrative user roles

Users and groups can be assigned multiple administrative user roles. Use the Ctrl and Shift
keys to select multiple roles. The following roles are available:
Administrator
Operator
Configurator
Monitor
Deployer


adminsecuritymanager
iscadmins
suppressmonitor
tsmAdministrator
tsmUser
reportAdministrator
reportViewer
IA Auditor
IA Operator
IA Archive Administrator
IA System Administrator

For a description of the various user roles, click the HELP button in the upper right corner on
the administrative interface.

Tip: Consider assigning the suppressmonitor role to all users. Assigning this role reduces
the number of navigation items shown in the Information Archive GUI that are not directly
related to managing the Information Archive appliance.

The user roles that are assigned to a user or group determine which navigation items are
displayed in the administrative interface. For example, the collection overview panel is visible
only to users having the Information Archive Administrator or Information Archive Operator
roles. Administrative user roles also determine which commands can be issued through the
Information Archive command line interface.

The roles also determine which tasks administrators are authorized to perform. It is good
practice to use various administrative user accounts to separate administrative tasks in
Information Archive. Mostly, you will need four separate user roles (IA Archive Administrator,
IA System Administrator, IA Auditor, and IA Operator), as defined next.
The IA Archive Administrator can perform general collection-related management
operations and health reporting actions that include the following tasks:
– Configure metadata fields
– Configure, modify, and monitor collection properties, migration, and System Storage
Archive Manager collections
– Create and delete retention policies
– Delete and manually commit documents
– Grant access permissions
– Grant audit log access to other users
– Monitor documents in expired, retention hold, uncommitted, and ingestion failure
states
– Access the health monitor to view status for overall appliance, collections, and clusters
The IA System Administrator can perform system and storage management operations
that include the following tasks:
– Configure user access to the Tivoli Storage Manager and System Storage Archive
Manager servers and storage pools
– Configure event notification conditions and actions
– Configure logging and tracing, the call home feature, external IP addresses, virtual IP
address ranges, the LDAP server, cluster node password, and the NTP server
– Stop and restart cluster nodes


– Put cluster nodes into maintenance mode
– Download component logs
– Monitor collection resources
– Monitor storage capacity, cluster nodes, and network interface servers
– Monitor the overall status of collections, cluster nodes, interfaces, and storage
– Suspend collections for maintenance
The IA Auditor is authorized to perform the following tasks:
– Download audit logs
The IA Operator can access all pages in the administrative interface (in read-only mode)
that are accessible to the archive administrator and system administrator roles to perform
the following tasks:
– Monitor collection resources and properties
– Monitor documents in expired, retention hold, uncommitted, and ingestion failure states
– Monitor the general and specific status of collections, clusters, storage, and interfaces
– Monitor storage capacity, cluster nodes, and network interface servers

In the illustrations shown in Figure 4-4 and Figure 4-5, you can compare the task views
presented by the Information Archive GUI for an administrative account and an auditor
account, respectively. The window left pane displays only those tasks that apply to the current
user role.

Figure 4-4 Information Archive GUI welcome panel for Information Archive administrator

For example, the Administrator Account has the Tivoli Storage Manager, the User
Management and the Information Archive Management tasks available. The task list for the
Information Archive Operator shows only the Information Archive Management task.


Figure 4-5 Information Archive GUI welcome panel for Information Archive auditor

To modify assigned administrative user roles, log on to the administrative interface with a user
account that has the adminsecuritymanager role assigned, and complete the following steps:
2. Click Administrative User Roles.
3. In the table, click the user name to modify.
4. Enter changes into the form, and click OK.

Managing groups
You can also define access rights at the user group level. The advantage of doing so is that
the access rights will apply to all members of that group. You can work with user groups
configured in LDAP (using File Archive Collections) or locally configured user groups (when
using System Storage Archive Manager).

To create groups locally on Information Archive, log on to the administrative interface
(Information Archive GUI) and complete the following steps:
2. If you have only enabled support for System Storage Archive Manager collections, click
Manage Groups (see Figure 4-6) and click Create to add one or more administrative user
groups.

Figure 4-6 create user groups


3. The Manage Groups dialog is displayed (see Figure 4-7). If you have only enabled support
for File Archive Collections, continue with “Administrative group roles” on page 79.
4. Enter appropriate data in the corresponding field as illustrated in Figure 4-2, then click
Create.

Figure 4-7 create groups dialog


Administrative group roles
After you have created your administrative groups, you need to assign administrative roles to
those groups. Log on to the Information Archive GUI and complete the following steps:
2. Click Administrative Group Roles.
3. Click Add to open the Administrative Group Roles window as shown in Figure 4-8.

Figure 4-8 Administrative Group Roles window

4. Select the administrative roles for the specific user group. User groups can be assigned
multiple administrative user roles. Use the “CTRL” and “SHIFT” keys to select the roles.
The roles available and configurable are listed in “Assigning administrative user roles” on
page 74.


5. After a user group is configured, you can add users to the group, or you can select a group
while configuring a user:
a. Expand Users and Groups in the navigation tree.
b. Click Manage Users.
c. In the table, click the user name to modify. The user properties window will be
displayed as shown Figure 4-9.
d. Click Groups in the upper right corner to open the User Group Window.

Figure 4-9 User properties general

e. Click Add to open the configuration panel as shown in Figure 4-10.

Figure 4-10 User properties group


f. Specify the search criteria to find the groups to which you want to assign that user
(Figure 4-11).

Figure 4-11 add a user to group window

g. Select the user group or groups to which you want the user to belong.
h. Click Add to confirm the selection. If successful. you get the message shown in
Figure 4-12.

Figure 4-12 user added to group message

After administrative user groups are defined, you can modify and update the roles. Log on to
the administrative interface with a user account that has the adminsecuritymanager role
assigned, and complete the following steps:
2. Click Administrative Group Roles.
3. In the table, click the user group to modify.
4. Enter changes into the form, and click OK.

4.1.2 Changing the passwords
Access to most Information Archive appliance components requires authentication.
Depending on your appliance configuration and company security policies, you might need to
change the passwords on a regular basis.


Tip: A password change for the default account iaadmin in IBM Systems Director is not
required because the password change for iaadmin in the Information Archive GUI is
propagated to IBM Director automatically. See “Changing the iaadmin password” on
page 82.

Changing the RSM server passwords
To ensure the security of the appliance, change the passwords for the IBM Remote Support
Manager server on a regular basis. You must manage the root password for this server, even
if you enable the Enhanced Tamper Protection feature.

Log on to the RSM for Storage server using the root user account. At the RSM for Storage
server prompt, enter the following commands.
passwd root
passwd admin
passwd lservice
rsm-passwd admin
rsm-passwd lservice

After each command, you are prompted to enter the current password and a new password.

Passwords: The passwd command changes the passwords that are used to log on to the
RSM server command line. The rsm-passwd command changes the passwords that are
used to log on to the RSM server browser interface.

Changing the iaadmin password
The iaadmin userid is used to log on to the cluster node servers, the IBM Systems Director
interface, install upgrades, and access the Management Console from the appliance’s
keyboard video mouse console (KVM console) or remotely through a Secure Shell (SSH)
connection. If necessary, you can change this password on a regular basis to comply with
your company’s security policy. The iaadmin userid is predefined and cannot be changed.
There is no possibility to create another user with the same role/ authority as the iaadmin
user.

To change the password, log on to the system and complete the following steps:
1. Expand Information Archive Management in the navigation tree.
2. Click System Management.
3. Click Modify iaadmin password in the General Settings section.
4. Complete the form, and click OK.

Changing the iscadmin password
The iscadmin user account is used to log on to Information Archive (using the Information
Archive GUI). This user account is only intended for use during initial setup of the appliance.
Create a separate user account for each person who manages the appliance or accesses
audit logs.

The administrative user role required for this task is adminsecuritymanager. Do these steps:
1. In the Information Archive GUI, expand Users and Groups in the navigation tree.
2. Click Manage Users. The WIM User Management portlet opens.
3. In the Search for Users section of the portlet, click Search. A list of users is shown in the
table.
4. Click iscadmin. The User Properties form opens.
5. Enter a new password, confirm the password, and click OK.


Changing the root password for Management Console / cluster nodes
If you do not enable the Enhanced Tamper Protection feature, you are responsible for
managing the root password for all the appliance components, including the Management
Console server. If Enhanced Tamper Protection is enabled, root access is not available for the
Management Console server.

To change the root password, you need physical access to the Information Archive appliance.
There is no possibility to remotely change the root passwords. With Enhanced Tamper
Protection enabled, root login is no longer possible. The iaadmin userid has less authority
than root to be compliant.

Complete the following steps:
1. Slide the keyboard video mouse console (KVM console) out from the appliance and open
the display panel.
2. Press the Print Screen key to view a list of appliance components.
3. Select iamconsole1/ianoden. The Management Console desktop or logon panel is
displayed.
4. Press Ctrl+Alt+F1 to access the Terminal Screen.
5. Log on to the Management Console using the iaadmin user account.
6. At the server prompt, enter the following command: su root. When prompted, enter the
root password.
7. Enter the command: passwd root
8. You are prompted for a new password and password confirmation.
9. The password is changed. As a best practice, change this password on a regular basis.
You can use Ctrl+Alt+F7 to go back to the graphical panel on the Management Console.

Setting the password in DS Storage Manager
When accessing the DS Storage Manager as described in “Accessing the DS Storage
Manager interface” on page 98, you get a pop-up window as shown in Figure 4-13.

Figure 4-13 set Password po-up window

Select No to continue to the DS Storage Manager Enterprise Window. Because the DS
Storage Manager was customized for compliance, it will prevent deletion or modifications by
the user anyway. Therefore it is not required, and actually it is better not to set a password.


Important: Do not set a password in the DS Storage Manager. The RSM server and
Management Console will run certain SMcli commands to collect information from the
storage controllers. A password can block various queries from these nodes.

Changing the password for local administrative users
The local user accounts are used to log on to the Information Archive GUI to manage,
operate, and monitor the Information Archive appliance. Changing the password in the
Information Archive GUI for users with the “tsmAdministrator role”, will also affect the IBM
Tivoli Storage Manager Administration Center and CLI logon.

Passwords: It is good practice to change the passwords for the administrative users at
regular intervals.

Set the administrative user role adminsecuritymanager required for this task as follows:
1. In the Information Archive GUI, expand Users and Groups in the navigation tree.
2. Click Manage Users. The WIM User Management portlet opens.
3. In the Search for Users section of the portlet, click Search. A list of users is shown in the
table.
4. Click the user account you want to change. The User Properties form opens.
5. Enter a new password, confirm the password, and click OK.

Setting a password for the KVM console
By default, a password is not required to access the keyboard video mouse console (KVM
console). You can optionally set a password for this component.

To do so, complete the following steps:
1. Slide the keyboard video mouse console (KVM console) out from the appliance and open
the display panel.
2. Turn on the KVM console if necessary.
3. Press the Print Screen key to open the OSCAR interface.
4. Click Setup > Security. The Security page opens.
5. In the Change Password section, type a new password in the New and Repeat fields.
6. Click OK and then close the page.

The password is set to the value that you specify. As a best practice, change this password on
a regular basis.

4.1.3 Software updates
IBM provides automated upgrade packages to help you apply interim fixes for most of the
components in the Information Archive appliance. Some firmware updates for the appliance
servers and storage controllers must be applied by an IBM service representative.

As necessary, Information Archive upgrade packages are made available to provide important
product fixes between scheduled releases.


Important: Only the packages that are made available specifically for Information Archive
can be used to upgrade the appliance. Do not apply any other hardware or software
updates to any components in the appliance, unless you are directed to do so by an IBM
service representative.

Upgrade packages are published on the Information Archive support website:
http://www.ibm.com/systems/support/storage/disk/InformationArchive

The Management Console has no Internet access. Because of internal firewall rules, you
cannot download an upgrade package directly to the server. You have to download the
upgrade package to another computer and use SCP, a DVD, or USB flash drive to transfer the
package to the Management Console server. Physical access to the appliance is sometimes
required to complete an upgrade.

Tip: You can subscribe to the support website to receive an email notification when new
upgrade packages are available. The subscription feature is called My notifications.

Use the following link to access the My notification page.
https://www.ibm.com/systems/support/myview/subscription/css.wss/folders?methodName
=listMyFolders

You can add all products to which you want to subscribe, and you are informed by email.
The frequency of those emails can be configured on the My notifications page shown in
Figure 4-14.

Figure 4-14 IBM support - My Notifications

Each upgrade package includes cumulative fixes for one or more appliance components.


Important: All of the collections in Information Archive must be suspended during an
upgrade; documents cannot be archived and retrieved until the upgrade is complete.

A typical upgrade takes less than six hours.

Tip: If you have Enhanced Remote Mirroring, always run the upgrade first on the
secondary appliance. You do not need to suspend the collection and put the nodes in
maintenance mode (this is not possible on a secondary appliance). Just reboot the
Management Console server at the secondary Information Archive and run the upgrade
script.

Instructions for upgrade packages
A readme file is included with each upgrade package. The readme file provides detailed
instructions for applying the upgrade, which typically includes the following tasks:
1. Transfer the upgrade package to the Management Console server. You can use the
transfer method of your choice (scp, a USB flash drive, a DVD image, FTP, and so on).
2. Reboot the Management Server before starting each upgrade attempt, including upgrade
retries.
3. Suspend all collections and place all cluster nodes into maintenance mode.
4. Log on to the Management Console server with iaadmin account and extract the
compressed files from the upgrade package. Unzip the package in a directory of your
choosing, such as /home/iaadmin or /tmp. For example:
iaadmin@iamconsole1:/tmp> unzip ia-1.2.0.1_upgrade.zip
5. Change to the directory that was created when the upgrade zip file was unzipped. For
example:
cd /tmp/ia-1.2.0.1
6. Run the iaupgrade.sh script from the current (ia-1.2.0.1) directory
(/opt/tivoli/tiam/bin/iaupgrade.sh).
iaadmin@iamconsole1:/tmp/ia-1.2.0.1> /opt/tivoli/tiam/bin/iaupgrade.sh
7. After the upgrade is complete, take cluster nodes out of maintenance mode and resume
the collections.
8. Delete the upgrade package from the Management Console server.

In an Enhanced Remote Mirroring configuration, upgrades must be applied to both the
primary and secondary appliances. Upgrade the secondary appliance first,

Important: If tracing is enabled for the clustered file system software (General Parallel File
System or GPFS), this tracing is automatically disabled by the upgrade process. If
necessary, you can re-enable this tracing after the upgrade completes.

Upgrading firmware for servers and storage controllers
Like other Information Archive upgrades, firmware upgrades for the servers and storage
controllers in the appliance are provided in a package on the Information Archive support
website. However, some of these upgrades must be applied by an IBM service representative.
If firmware upgrades are available when you upgrade the appliance, the firmware upgrades
must be applied after the appliance upgrade is complete. Contact the IBM Support Center to
schedule a time for an IBM service representative to apply the firmware upgrades.


4.1.4 System monitoring
An Information Archive administrator must always know about the health of the system. For
that purpose, Information Archive provides various monitoring tools. The administrator
(auditor or monitor role assigned) has the possibility to monitor the entire Information Archive
using the IBM System Director, RSM, Health Monitor, and IBM Tivoli Storage Manager
Reporting functions. The administrator can monitor the various components such as storage
controller, servers, and switches using the IBM Systems Director and Remote Support
Manager. The health monitor will always display the current appliance status. You can
configure email and SNMP alerting to get informed whenever a software or hardware error
has occurred.

Additionally, you can set up the call home functionality from Information Archive.

Configuration and use of the monitoring features is explained in detail in Chapter 9,
“Monitoring and call home” on page 351. Figure 4-15 shows an illustration of the Health
Monitor page.

Figure 4-15 Information Archive GUI - Health Monitor

4.1.5 RSM management
The RSM server software monitors the Information Archive storage controllers. The main
function is described in “RSM server for Information Archive” on page 381. Detailed
documentation for the IBM Remote Support Manager for Storage can be found at the
following website:
http://www.ibm.com/systems/support/supportsite.wss/docdisplay?lndocid=MIGR-66062&b
randind=5000008


Important: Do not download the RSM server software from the RSM web page.
Information Archive uses a special version of RSM for compliance.

See “Accessing the RSM server” on page 97 for information about how to access the RSM.

There are four management areas and one log section on the RSM main page:
System Configuration
Reporting and Alerts
Internal Firewall
Remote Access
Statistics and Logs

These management areas and log section are shown in Figure 4-16,

Figure 4-16 RSM Server - Main Menu

System configuration
The System Configuration page shown in Figure 4-17 allows you to specify the following
information:
Company name and address
One or more contact people that IBM Service must call or email when responding to a
problem report
Connection information about the RSM for Storage system
Storage controllers to be monitored by the RSM system
Other SAN devices
System activation

There are three validation checks made for the configuration information.

The first check occurs when you click the Update Configuration button on each
configuration page. This verifies the format and content of each configuration field. Any
problem will be indicated with a Configuration Incomplete status.

When all configuration Incomplete problems have been fixed, an option will be available at the
bottom on the System Configuration page to run a Configuration Test. This test checks that
the RSM for Storage system has TCP/IP connectivity to all configured storage devices, with
the attached external modem if configured, and that each of the storage controllers can be
contacted. Problems detected during the test are indicated with a Configuration Problem
status.


Error correction: The RSM server software will not process any events until all
configuration errors are corrected and the System Activation step has been completed. For
Information Archive, this is normally already done by manufacturing.

A third configuration check occurs each day when each storage controller is contacted to
verify connectivity. This check will detect the following situations:
If a new version of controller firmware has been installed: This condition will require an
update to RSM for compatibility. In Information Archive, this situation is not expected to
occur, because normally you have to update the whole appliance, including necessary
firmware updates.
If any new expansion drawers have been added to the storage controller: When a new
enclosure (drawer) is detected, the configuration status for the storage controller in RSM
changes to Incomplete and you need to add the IBM Machine Type and Serial number for
the enclosure to the RSM configuration.

A typical System Configuration page is shown in Figure 4-17.

Figure 4-17 RSM Server - System Configuration

Reporting and alerts
Normally, all configured storage controllers are enabled for reporting. This means that RSM
will accept and process any events related to the storage controller. If you are relocating a
storage controller or performing any task that might generate events that IBM does not need
to respond to, you can disable reporting until the storage controller is fully operational again.

While you are making configuration changes to the RSM software, the Reporting Status might
be “Suspended.” This is a reminder that no events will be processed by the RSM system while
any configuration problems exist.

This page, shown in Figure 4-18, displays a summary of all alerts being tracked by the RSM
software and allows you to view details about alerts that are active for each storage controller.

When a storage first reports a problem, an alert is sent to IBM Service. After IBM has been
alerted to the problem, additional alerts for that storage controller are usually held at the RSM
system. However, if another event for the same storage controller occurs and indicates a
hardware failure that differs from the previously sent alert, the new alert will also be sent to
IBM.


IBM will respond to the alert by connecting to the RSM system, at which time they will either
acknowledge or close all of the alerts for the storage controller. Alerts are acknowledged to
indicate that they have been seen by IBM Service but work on the problem has not been
completed. Closing all of the alerts for a storage controller indicates that service is complete.

When all alerts for a storage controller are closed, the RSM software will consider the next
event from that storage controller to be a new problem and an alert will be sent to IBM
Service.

The Reporting and Alerts page will show the number of alerts sent, acknowledge, and
pending for each storage controller that has active alerts.

Pending alerts are ones that are candidates to be sent to IBM Service, but are being held at
the RSM system for one of three reasons: Holding, Queued, or Waiting.
Holding:
Another alert has already been sent to IBM Service for the storage controller.
Queued:
The RSM for Storage software attempted to send the alert, but received an error. The
most likely cause is a network problem that prevents the RSM for Storage software from
reaching the SMTP server. The RSM for Storage software will attempt to re-send the alert
every few minutes.
Waiting:
IBM Service was remotely connected to the RSM system when the alert occurred. If all
other alerts have been closed and the remote user disconnects without acknowledging
this alert, it will then be sent to IBM Service as a new problem.

Figure 4-18 RSM Server - Reporting and Alerts

Internal firewall
The firewall page shown in Figure 4-19 provides status for the RSM server internal firewall.
The purpose of the internal firewall is to limit the scope of access that local and remote users
of the system have to your network.

The normal state for the firewall is Enabled:Closed which means that the firewall is
operational and configured to allow SNMP traps to be received and emails to be sent.
However, access to other devices on your network is not allowed.

The Enabled:Custom state indicates that one or more custom rules have been added to
/etc/rsm/rsmfirewall.conf. These rules will be active any time the firewall is enabled.


The Enabled:Open state means that access to one or more other devices has been enabled.
The firewall allows access to any storage controller that has an active alert, and also storage
controllers that have been placed in Service Access mode.

Disabling the firewall allows unrestricted access from the RSM for Storage system to your
network. To maintain the security of your network, disabling the firewall will also disable
remote access. Likewise, enabling Remote Access will automatically enable the firewall.

Figure 4-19 RSM Server - Internal Firewall

RSM remote access
The RSM Remote Access page shown in Figure 4-20 provides controls and status for remote
access to the RSM system. Enabling remote access unlocks the rservice user account and
depending on your configuration, allows the modem to answer an incoming call, or enables
the firewall to accept SSH connections.

Important: If your Information Archive appliance is behind a firewall, you need to configure
a port forwarding for the SSH service between your firewall and the RSM server.

After being enabled, when a remote user connects to the system, the status will change to
Active.

You can select to have Remote Access automatically enabled when an alert is sent to IBM
Service, or wait to be contacted by IBM Service by phone before manually enabling it.

This page also allows you to set the Remote Access Timeout. This guarantees that the
system will return to a secure state, without intervention. If the problem is difficult to resolve,
or occurs intermittently, you might need to refresh the time-out to allow IBM Service more
time to work on the problem. If you disable Remote Access while a remote user is connected,
the remote user will be disconnected.


Figure 4-20 RSM Server - Remote Access

Statistics and logs
The Statistics and Logs page shown in Figure 4-21 contains information that can be helpful in
solving problems with operation of the RSM server application:
The Activity Log contains time stamped entries for actions performed by the RSM
software.
The Security Log contains time stamped entries for actions performed by the RSM for
software that affect the security of the system.
The System Log contains time stamped entries for actions performed by the Operating
System were the RSM software is running.


Figure 4-21 RSM Server - Activity Logs

4.1.6 DS Storage Manager
You can use the DS Storage Manager interface to perform hardware maintenance tasks on
the storage controller or to verify the health of the storage controllers. You can access the DS
Storage Manager as described in “Accessing the DS Storage Manager interface” on page 98.

Important: The DS Storage Manager is a compliant version. No deletion of LUNs or arrays
is allowed.

Storage controller status
When the Enterprise Management Window is opened (see “Accessing the DS Storage
Manager interface” on page 98), the storage management software establishes
communication with each managed Information Archive storage controller and determines
the current status.

The status icons displayed in the Enterprise Management Window represent a summary
status for each storage controller. If a storage controller has a Needs Attention or Fixing
status, you can select the storage controller and launch its management window to determine
the condition that is causing this status. More detailed status icons are shown in the
Management Window for the various components that comprise the storage controller. Also,
the Recovery Guru option provides a detailed explanation of the conditions and the
appropriate steps to remedy any Needs Attention status.

Error reporting: All critical errors are reported to the RSM server. The configured mail
contact will always get informed when a critical error has occurred.

For a description of the Storage Manager software and its features, see the IBM Redbooks
publication, IBM System Storage DS4000 and Storage Manager, SG24-7010.


Storage controller functions
The major storage controller functions are as follows:
Overall Component Information:
Use the storage controller / expansion drawer, Overall Component Information, to view the
status of all components in the storage controller.
In the Subsystem Management Window, click the View button to display the Summary
information as illustrated in Figure 4-22.

Figure 4-22 DS Storage manager - storage controller summary Information

Recovery Guru:
The Recovery Guru is a component of the Management Window that diagnoses storage
controller problems and describes recovery procedures to fix the problems.
To display Recovery Guru, select the Recovery Guru toolbar button in the Subsystem
Management Window.
Event log:
Use the Event Log Viewer to display a detailed list of events that occur in a storage
controller.
The Event Log is stored on reserved areas on the storage controller disks and records
configuration events and storage controller component failures.
The Event Log stores approximately 8,000 events before replacing them.
Use the following procedure to display events:
– From the Subsystem Management Window, select Advanced  Troubleshooting 
View Event Log.


– Specify or type the number of events to retrieve in the Retrieve most recent events
spinner box. When View only critical events is selected, the box is labeled
Retrieve most recent critical events.
– To view details about a selected event, select View details.
– Click Update to retrieve new events from the storage subsystem for display.

4.2 Operations
In this section, we describe how to start and stop Information Archive and how to access the
system components.

The Information Archive appliance components must be started and stopped in a specific
order. Cluster nodes can be stopped, restarted, or put into maintenance mode. Maintenance
mode prevents the cluster management software from trying to restart the node if it is stopped
or if an error occurs. Cluster nodes must be put into maintenance mode before a software
upgrade on the Information Archive appliance.

4.2.1 Accessing the system
There are multiple ways to access the various components in order to manage, configure,
and operate Information Archive.

Accessing the Management Console
You can access the Management Console locally or from a remote computer through a web
browser. To remotely access the Information Archive command line, you can also use an SSH
client such as putty.

Accessing the Management Console locally
You can access the Information Archive GUI directly from the appliance by using its keyboard
video mouse console (KVM console):
1. Press the Print Screen key to open a list of the appliance nodes. Select iamconsole1.
2. Log on to the Management Console server with the iaadmin user account.

Accessing the Management Console remotely
You can access the Information Archive command line remotely over SSH:
1. Start an SSH client such as putty.
2. Enter the management node server TCP/IP address in the Host Name section.
3. Select the SSH Protocol and port 22.

Starting the Information Archive GUI locally
After you are logged on as mentioned in “Accessing the Management Console locally”, the
IA GUI logon window is displayed. If a web browser does not open automatically, right-click
the Management Console server desktop and select xterm. At the command prompt, enter
firefox. You get a Welcome window as shown in Figure 4-23.


Starting the Information Archive GUI remotely
You can access the remotely, using a supported web browser. Start your web browser and
navigate to the following web address:
https://<management-console-ip-address>:9043/ibm/console

The logon panel is shown in Figure 4-23.

Finding TCP/IP address: The TCP/IP address of the Management Console and the
appliance name can be found in the Information Archive GUI in the System Management
section’s Appliance Properties Notebook. If necessary, access the Information Archive GUI
from the appliance keyboard video mouse console (KVM console) to obtain this
information.

Figure 4-23 Information Archive GUI - logon panel

Accessing the cluster nodes
You can access the cluster nodes only locally by using the keyboard video mouse console
(KVM console).
1. Access Information Archive keyboard video mouse console (KVM console).
2. Press the Print Screen key to open a list of the appliance nodes. Select ianode.

Log on to the cluster nodes using the iaadmin user account.


Accessing the RSM server
You have to access the IBM Remote Support Manager for Storage (RSM for Storage)
interface to view details about disk errors, update call home information for the storage
controller, and to complete other tasks.

Accessing the RSM server from the Information Archive GUI
You can access the RSM server as follows:
1. Log on to the Information Archive GUI locally or remote as described in “Accessing the
Management Console” on page 95.
3. Click Service Tools.
4. Click Open Remote Support Manager on local Appliance as shown in Figure 4-24.
Afterwards you get the Main Menu for the RSM for Storage as shown in Figure 4-25.
5. Click any link to receive a logon prompt.

Figure 4-24 Information Archive GUI - Open RSM interface


Logging on to the RSM server locally
To log on to the RSM server locally, use the following steps:
1. Access the Information Archive keyboard video mouse console (KVM console).
2. Press the Print Screen key to open the KVM console menu. Select iarsm1 to connect to
the RSM server.
3. Log on to the RSM server using the admin user account.
4. Click the Manage icon on the RSM server desktop to open the RSM for Storage interface
as shown in Figure 4-25.

Figure 4-25 RSM Server - Main menu

Accessing the DS Storage Manager interface
Use the IBM System Storage DS® Storage Manager interface to perform hardware
maintenance tasks on the storage controller. You can access the DS Storage Manager locally
or from a remote computer.

Accessing the DS Storage Manager locally
Log on to the Management Console server using the iaadmin user account. Right-click the
Management Console server desktop and click xterm. At the Management Console server
prompt, enter the command sudo SMclient.


Accessing the DS Storage Manager remotely
To access the DS Storage Manager from a remote computer, use the following steps:
1. Install an X-Server on the remote computer
2. Open an ssh client like Putty
3. Enable X11 forwarding as shown in Figure 4-26.

Figure 4-26 Putty - Enable X11 Forwarding

4. As shown in Figure 4-27, you have to select the Category Session from the left menu.
Then do the following steps:
a. Enter the Management Console server TCP/IP address in the Host Name section
b. Select the SSH Protocol and the Port 22
c. Click Open to start the SSH session


Figure 4-27 Putty - Basic options

6. Run the command sudo SMclient to start the DS Storage Manager interface on your
remote computer. This is shown in Example 4-1.

Example 4-1 Starting the SMclient
login as: iaadmin
Using keyboard-interactive authentication.
Password:
Last login: Fri Feb 19 17:30:07 2010
iaadmin@IA-Primary:~> sudo SMclient

If the configurations settings are correct, you get a window as shown in Figure 4-28.

Figure 4-28 SMclient Enterprise window


Accessing the IBM Systems Director
You can use IBM Systems Director to diagnose and troubleshoot hardware errors, and to
configure the call home feature for Information Archive.

Logging on to the IBM Systems Director using the Information Archive GUI
Log on to the IBM Systems Director as follows:
1. Log on to the Information Archive GUI.
3. Click Service Tools. From the Service Tools window shown in Figure 4-24, select
Open IBM Systems Director on Local Appliance locally.
4. Log on using the iaadmin user account and password. You get the Welcome to IBM
Systems Director window as shown in Figure 4-29.

Figure 4-29 IBM System Director - Welcome panel

For details about the IBM Systems Director, see 9.3, “Using IBM Systems Director in
Information Archive” on page 365.

4.2.2 Shutting down the appliance
When you want to power off the whole appliance, you have to do it in a specific order:
1. Shut down all cluster nodes.
2. Shut down the RSM server.
3. Shut down the Management Console.
4. Power off all storage controllers.
5. Power off all expansion drawers.
6. Power off KVM Switch.
7. Power off Rack / Switches.


Shutting down the cluster nodes
From the KVM console, log on to the Management Console using the iaadmin user account.
Log on to the Information Archive GUI with a user account that has Information Archive
System Administrator authority.

Tip: At the command line (X-Term Window on the Management Console server), enter
ia_list_active_hosts.py. Check the output to ensure that all the archiving activities have
been completed. It is better to suspend all collections before you power off cluster node
servers.

Stopping all cluster nodes
Follow these steps to stop all cluster nodes:
3. In the Cluster Node section, stop all cluster nodes:
a. Click the stop icon next to the first cluster node as shown in Figure 4-30.
b. Select Shutdown node and click OK as shown in Figure 4-31
c. Repeat these steps for each cluster node.

Figure 4-30 Stop icon - cluster node

Figure 4-31 Shut down cluster node


Shutting down a cluster node on the secondary appliance
To shut down a cluster node on the secondary appliance, follow these steps:
1. Open a secure shell connection and log in to the secondary appliance Management
Console as iaadmin.
2. At the command line, enter ia_powercontrol -d <nodename> where <nodename> is the
name of the cluster node server you want to power down. (see Example 4-2)
3. Make sure that you see the following output to verify that the node has been successfully
powered down:
Node attached to power control hardware at '<nodename>' powered down.

Example 4-2 shut down secondary cluster node
iaadmin@IA-Secondary:~> ia_powercontrol -d ianode3
Node attached to power control hardware at 'ianode3' powered down.

Shutting down the RSM server
Log on to the RSM server as root user and open a Terminal Window (Desktop icon in the
lower left corner). Enter the shutdown now -h command to shut down the RSM server.

Shutting down the Management Console
Log on to the Management Console and open a terminal window. Enter the sudo
/sbin/shutdown now -h command to shut down the Management Console.

A second way to shut down the Management Console is to slide the power-control button
cover to the left and press the power-control button. The power-control button is located on
the right side of the server, above the optical drive bay.

Powering off the storage controller / expansion drawer
Press the left and right rocker switches on the back of the storage controller (2231-D1A). If
necessary, repeat this operation for the storage controllers in the 2231-IS3 expansion rack.

If you have the optional expansion drawers (2231 D1B), press the left and right rocker switch
on any available expansion drawers.

Important: The storage controller (2231-D1A) must be powered off, before you power off
the expansion drawers (2231-D1B).

Powering off the KVM switch
Press the power button on the keyboard video mouse console (KVM console). The power
button is located at the bottom of the monitor.

Press the rocker switch on the keyboard video mouse switch (KVM switch) in the back of the
Rack.

Powering off the rack / SAN and Ethernet switches
The FC and Ethernet switches in Information Archive are not equipped with rocker switches. If
you need to power off the switches, you have to unplug the power cords or unplug the main
line power cords connected to the left or right power distribution units (iPDUs) in the
appliance.

When you plan to unplug the main line power cords, be sure that all servers are powered off.


4.2.3 Starting up the appliance
When you want to power on the whole appliance, you have to do it in a specific order:
1. Power on rack / switches
2. Power on the KVM switch
3. Power on expansion drawers
4. Power on storage controller
5. Power on Management Console
6. Power on all cluster nodes
7. Power on RSM server

Powering on the rack / SAN and Ethernet switches
The SAN and Ethernet switches within Information Archive are not equipped with rocker
switches. To power on the switches, you have to plug the power cords or plug the main line
power cords to the left or right power distribution units (iPDUs) in the appliance.

Make sure the main line power cords are connected to both iPDUs.

Powering on the KVM switch
Press the rocker switch on the keyboard video mouse switch (KVM switch) in the back of the
rack.

Press the power button on the keyboard video mouse console (KVM console). The power
button is located at the bottom of the monitor.

Powering on the expansion drawers / storage controller
If you are have the optional expansion drawers (2231-D1B), press the left and right rocker
switches on any available expansion drawers.

Press the left and right rocker switches on the back of the storage controller (2231-D1A). If
installed, repeat this step for the storage controllers in the 2231-IS3 expansion rack.

Important: All expansion drawers (2231-D1B) have to be powered on first before you
continue with powering on the storage controllers (2231-D1A).

Powering on the Management Console
On the front of the Management Console, slide the power-control button cover to the left and
press the power-control button. The power-control button is located on the right side of the
server, above the optical drive bay.

Power-control LED: When the server was completely powered off, the power-control
button LED of the server flashes rapidly for up to one minute. When the power-control
button LED is flashing slowly, press the button to start the server.

Powering on the cluster nodes
Starting a cluster node powers on the server and starts the software processes required for
ingesting and managing documents. There are two possibilities to power on the cluster node
server. You can power on the cluster node server from the Information Archive GUI or just by
pressing the power button.


Powering on the cluster node server from the Information Archive GUI
Log on to the Information Archive GUI and complete the following steps:
3. In the Cluster Nodes section, complete the following steps:
a. Click the start icon button next to the cluster node as shown in Figure 4-32. If the
cluster node was shut down using the Information Archive GUI, it starts in maintenance
mode.
b. Click the maintenance mode button next to the cluster node to bring it out of
maintenance. A typical maintenance button is shown in Figure 4-30.

Figure 4-32 Start icon Cluster Node

Powering on the cluster node server using the power button
On the front of the cluster nodes, slide the power-control button cover to the left and press the
power-control button. The power-control button is located on the right side of the server,
above the optical drive bay.


Powering on the RSM server
On the front of the RSM server, slide the power-control button cover to the left and press the
power-control button. The power-control button is located on the right side of the server,
above the optical drive bay.


4.2.4 Rebooting the servers
Occasionally it might be necessary to reboot a server, for example, for troubleshooting,
restoring configuration files, or tracing. Normally this process is directed by IBM support.

Rebooting a cluster node
You can reboot a cluster node from the Information Archive GUI or from the cluster node itself

Rebooting a cluster node using the Information Archive GUI
You can reboot the cluster node using the Information Archive GUI, as follows:
1. Log on to the Information Archive GUI from the Management Console as described in
“Accessing the Management Console” on page 95.


4. In the Cluster Node section, click the stop icon next to the first cluster node as shown in
Figure 4-33.

Figure 4-33 Cluster node stop

Select Restart node and click OK as shown in Figure 4-34.

Figure 4-34 Restart node

Rebooting a cluster node using the Information Archive CLI
You can also reboot the cluster node as follows:
2. Press the Print Screen key to open the KVM console menu.
Select ianodeX to connect to the cluster node server.
3. Log on to the cluster node server using the iaadmin user account.
4. Enter command sudo /sbin/reboot as shown in the Example 4-3.

Example 4-3 Reboot cluster node command
iaadmin@ianode1:~> sudo /sbin/reboot

Rebooting the Management Console
To reboot the Management Console, follow these steps:
Select iamconsole1 to connect to the Management Console.
3. Logon using the iaadmin user account.
4. Enter the command sudo /sbin/reboot.


Rebooting the RSM server
To reboot the RSM server:
Select iarsm1 to connect to the RSM server.
3. Log on to the RSM server using the root user account.
4. Open a terminal window and enter the command reboot.

4.2.5 Maintenance mode for cluster node
Putting a cluster node into maintenance mode prevents the cluster management software
from trying to restart the cluster node if it is stopped. A cluster node must be put into
maintenance mode when you run a software upgrade on the Information Archive.

Secondary cluster: It is not possible to place a secondary cluster node in maintenance
mode, because it is in read-only mode.

Placing a cluster node into maintenance mode
3. In the Cluster Nodes section, click the maintenance mode icon (the right icon) next to the
cluster node to bring the node maintenance mode, as shown in Figure 4-35.

Figure 4-35 Maintenance mode icon

4. In the next window, click Put Node into Maintenance Mode, as shown in Figure 4-36.

Figure 4-36 Maintenance mode


Taking a cluster node out of maintenance mode
3. In the Cluster Nodes section, click the maintenance mode icon (the right icon) next to the
cluster node to bring the node out of maintenance mode.

4.2.6 Suspending a collection
You can suspend a collection to allow maintenance on the storage controller and you have to
suspend all collections to apply a software upgrade. If a File Archive Collection is suspended,
Network File System (NFS) and HTTP accesses are stopped. When a System Storage
Archive Manager Collection is suspended, you cannot commit or retrieve documents. Any
uncommitted documents in the collection file system remain uncommitted and will not be
ingested until the collection is resumed.

To suspend a collection, log on to the Information Archive GUI and complete these steps:
3. In the Collections section, click the suspend button that is next to the collection you are
suspending, as shown in Figure 4-37.

Figure 4-37 Suspend icon

4. Confirm that you really want to suspend the collection. Click Yes or No.

Figure 4-38 Suspend Collection confirmation

Tip: You might have to scroll up the web browser window to see the Yes or No button.


4.2.7 Resuming a collection
You can resume a collection that has been suspended. If you resume a File Archive
Collection, the Network File System (NFS) and HTTP services are started and any
uncommitted documents are processed.

Expand Information Archive Management in the navigation tree.
Click System Management.
In the Collections section, click the resume button that is next to the collection you are
resuming.

4.2.8 Retrieving error logs and traces
You can download a compressed file that contains error and trace logs from the Information
Archive GUI or from the Management Console. The logs are used by IBM service
representatives to troubleshoot errors.

Service ticket: If you have an open service ticket at IBM, you can upload the log files at:
http://www.ecurep.ibm.com/app/upload

Files are excluded from the compressed file if they are too old, too large, or in a directory with
too many files. The files are excluded to reduce the size of the log file. These thresholds are
preset, and cannot be changed.

To override the log collection thresholds and to collect all the log files, use the trace
configuration utility. How to modify the Logging and Tracing options is explained in 9.6,
“Logging and tracing” on page 398.

To download the logs from the Information Archive GUI, perform the following steps:
1. Log on to the Information Archive GUI as an administrative user with Information Archive
System Administrator level of access.
3. Click Service Tools in the lower right corner as shown in Figure 4-39.

Figure 4-39 Service Tool Screen

4. In the Logging and Tracing section, click Download logs.
When the logs are ready, a dialogue box appears. Specify where to save the compressed
file and the file is downloaded. If you use the keyboard video mouse console to download
the logs, they are saved in the /home/iaadmin directory on the Management Console.


4.3 Information Archive Command Line Interface
The Information Archive provides a command line interface (Information Archive CLI) that
gives you an alternative to the Information Archive GUI for executing some tasks. The CLI can
also be used to define scripts for monitoring or for configuration tasks. The Information
Archive CLI runs at the Information Archive Management Console and uses a tool called
wsadmin to issue administrative commands.

4.3.1 Definitions
This section explains some terms and concepts often used in the context of the Information
Archive CLI:
wsadmin
The wsadmin tool is used to manage WebSphere Application Server as well as the
configuration, application deployment, and server run-time operations. The Information
Archive CLI only supports the Jython scripting languages. The wsadmin launcher makes
several scripting objects available: AdminConfig, AdminControl, AdminApp, AdminTask,
and Help. Scripts use these objects for application management, configuration,
operational control, and for communication with MBeans that run in WebSphere
Application Server processes.
jython
Jython, successor of JPython is a pure Java implementation of the Python programming
language that allows you to run Python programs on any Java platform.
iacli.sh
The iacli.sh is a script, available on the Information Archive Management Console to run
Information Archive CLI commands. The script will check Information Archive appliance
prerequisites before the wsadmin tool is opened.

Information Archive CLI commands are case-sensitive. Enter all commands using lowercase
characters.

4.3.2 Accessing the Information Archive CLI
You have two possibilities to get to the command line interface:
From the Information Archive GUI:
If you are directly at the appliance and logged on the Management Console, do a
right-click in the desktop and select “Terminal Window.”
Through SSH:
You can open an SSH session with your SSH client, for example, putty, pointing to the
TCP/IP address of the Management Console. Then, run the command iacli.sh


4.3.3 CLI command categories
There are seven categories of CLI commands available:
Collection management commands
Policy management commands
Collection access commands
System management commands
Event notification commands
Logging and tracing commands
Document management commands

For a detailed command reference, see the Information Archive User Guide, SC27-2325 or
access the information from the Information Archive Information Center at:
http://publib.boulder.ibm.com/infocenter/tivihelp/v37r1/topic/com.ibm.ia.doc_1.0/i
c/c_cli_overview.html

4.3.4 Using the Information Archive CLI
There are three methods available to enter Information Archive CLI commands:
Entering Information Archive CLI commands interactively
Redirecting command output
Using a script to run commands

Role: You will need a userid with the IA Archive Administrator role to perform collection
related CLI commands.

Entering CLI commands interactively
Start and run the Information Archive command line interface (Information Archive CLI) in
interactive mode to enter multiple commands without being prompted for your user account
and password each time (Example 4-4).

The Management Console can be accessed directly from the keyboard video mouse (KVM)
console in the appliance, or remotely through a Secure Shell (SSH) connection. When you
start the Information Archive CLI, you must enter an administrative user account and
password. The user account must be assigned either the IA Archive Administrator or the IA
System Administrator administrative user role to issue commands.

Log on to the Management Console and complete the following steps:
1. At the Management Console prompt, enter iacli.sh.
2. Enter your administrative user account and password when prompted.
3. Enter Information Archive CLI commands. For example showsystemstatus to display the
system health status.
4. Enter quit to exit the Information Archive CLI prompt.

Example 4-4 Enter Information Archive CLI command showsystemstatus interactively
iaadmin@IA-Primary:~> iacli.sh
IA Username: iscadmin
IA Password:
CTJIC0151I The IBM Information Archive command line is ready for use.
IACLI> showsystemstatus


----Cluster Node Status----

Cluster Node Name: ianode1
Cluster Node IP: 172.31.1.1
Collections Hosted: NFS1, SSAM1
State: running

State: running

State: running

----Storage Subsystem Status----

Controller Name: iastorage1a
Hosted Collection: NFS1
Capacity: 9.95 TB
Cache Hit Ratio: 1.0%
Throughput: 2.9 MB/sec
I/O Rate: 59.3 KB/sec
Remote Replication Status: Synchronized

Controller Name: iastorage2a
Hosted Collection: SSAM1
Capacity: 4.5 TB
Cache Hit Ratio: 1.0%
Throughput: 1.1 MB/sec
I/O Rate: 12.2 KB/sec
Remote Replication Status: Synchronized

----Tape Library Status----

Library Name: IBM 00L4U78F6723_LL1 3573-TL /dev/IBMchanger0
Library Name: IBM 00L4U78F6723_LL0 3573-TL /dev/IBMchanger1
Drive 1: IBM 1310127710 ULT3580-TD4 /dev/IBMtape0
Drive 2: IBM 1310125225 ULT3580-TD4 /dev/IBMtape1

IACLI>quit
iaadmin@IA-Primary:~>

Tip: For information about using the Information Archive command line interface, enter
help. To view a full list of available commands, enter help -listcommands yes.


Redirecting command output
Use the wsadmin tool at the Management Console to run a single Information Archive CLI
command and redirect the output to a file. You do not need the iacli.sh script in front of this
command.

To redirect command output, you must translate an Information Archive command to Jython
syntax and enter it as a wsadmin parameter. The format is:
/opt/tivoli/tsm/AC/ISCW61/bin/wsadmin.sh -user ia_user -password ia_password -lang
jython -c "print AdminTask.command_name('[command_parameters]')"

Where ia_user is an administrative user account with the authority to run the command,
ia_password is the password for the administrative user, command_name is the name of an
IA CLI command, and command_parameters is a list of one or more valid command parameter
and value pairs, each separated by a single space.

Example 4-5 illustrates redirecting of the showsystemsettings Information Archive CLI
command output.

Example 4-5 Redirect Information Archive CLI command showsystemsettings
Login as iaadmin.
iaadmin@IA-Primary:~> /opt/tivoli/tsm/AC/ISCW61/bin/wsadmin.sh -user administrator
-password password -lang jython -c "print AdminTask.showsystemsettings('')"
WASX7209I: Connected to process "tsmServer" on node tsmNode using SOAP connector;
The type of process is: UnManagedProcess

----General Appliance----

Name: IA-Primary
Time Server: 172.31.3.2
Enhanced Tamper Protection: on
File Archive Collections: enabled
System Storage Archive Manager collections: enabled

----File Sharing----

Protocol Status Port
Web Sharing (HTTP) RUNNING 80
Network File Sharing (NFS) RUNNING 2049

----LDAP Settings----

LDAP Server: 9.153.1.100
LDAP Port Number: 389
LDAP Type: ITDS
Search Base: dc=ArchiveSolutionCompetenceCenter,dc=Leipzig,dc=local
Bind Distinguish Name:
cn=Administrator,dc=ArchiveSolutionCompetenceCenter,dc=Leipzig,dc=local
SSL Enabled: no
SSL Certificate: n/a


Using a script to run commands
To automate Information Archive command-based tasks, create a Jython script containing the
commands that you want to issue and run the script using the wsadmin tool.

To use a script, complete the following steps (assuming, that you have already created a user
with the account “administrator” by the Information Archive GUI):
1. Log on to the Management Console as iaadmin.
2. Create a Jython script, with each Information Archive CLI command listed on a separate
line.
vi <name_of_script>
Example:
vi query_system_settings.py
See Example 4-6.

Example 4-6 Sample Jython Script query_system_settings.py to query system settings by CLI
#
# This script will display IA system settings
#
print AdminTask.showsystemsettings('')
print AdminTask.listcollection('-format detailed')
print AdminTask.shownotification('')

3. Save the Jython script with a .py file extension on the Management Console.
4. At the Management Console prompt, issue the following command to run the Jython
script:
/opt/tivoli/tsm/AC/ISCW61/bin/wsadmin_cli.sh -user ia_user -password
ia_password -lang jython -f path_to_jython_script
Where ia_user is an administrative user account with the authority to run the scripted
commands, ia_password is the password for the administrative user, and
path_to_jython_script is the location of the Jython script on the Management Console
server.
For example:
/opt/tivoli/tsm/AC/ISCW61/bin/wsadmin_cli.sh -user administrator -password
password -lang jython -f /home/iaadmin/query_system_setting.py

Attention: Created scripts are not backed up automatically. It is a user responsibility.


5

Chapter 5. System Storage Archive Manager
Collections
IBM Information Archive (Information Archive) uses collections to manage archive data.
Depending on the archiving application and the functions needed, there are various types of
collections available.

In this chapter we provide information about the IBM System Storage Archive Manager
Collections. Because this type of collection is based on the product IBM System Storage
Archive Manager, we explain the relevant details of this product. This information is intended
primarily for readers who are new to IBM System Storage Archive Manager. However, we also
indicate which features are most relevant to the particular usage within Information Archive
collections.

Furthermore, we describe the configuration and administration of System Storage Archive
Manager Collections, and we register archiving applications to use this configuration.


5.1 System Storage Archive Manager Collection overview
System Storage Archive Manager Collections are used to archive and retrieve documents
using the IBM Tivoli Storage Manager archive client or the IBM Tivoli Storage Manager
application program interface (API). The latter is considered the preferred technology,
because the API is optimized for archival usage and an encapsulated system. Archive
applications like document management systems or enterprise content management
systems utilize the IBM Tivoli Storage Manager API and archive and retrieve their data by
using the API functions. Figure 5-1 shows a diagram of these concepts.

TSM API Client Web-browser

SSAM Server
IA Management GUI
Clustered Filesystem & Middleware

Disk Storage

SSAM Collection IBM Information Archive

Tape Device (optional)

Figure 5-1 System Storage Archive Manager Collection overview

Each System Storage Archive Manager Collection is hosted by a dedicated IBM System
Storage Archive Manager server. The System Storage Archive Manager server is running on
a Linux operating system on one of up to three cluster nodes, depending on how many cluster
nodes are available in the configuration. Each System Storage Archive Manager Collection is
using its own, dedicated disk storage subsystem.

The IBM System Storage Archive Manager is an integrated component of the PID 5608-IAF
Information Archive software. Because the IBM System Storage Archive Manager is the core
component of the System Storage Archive Manager Collection where all retention policies
and data are managed, we explain the functions and features in detail in the following topics.

The underlying file system is the IBM General Parallel File System (GPFS), where the
System Storage Archive Manager server stores its own IBM DB2 database and the archived
data. The System Storage Archive Manager DB2 database is used to maintain management
information such as retention policies and access credentials. The archived data is not held in
the database, hence it is stored by System Storage Archive Manager storage pools directly
into GPFS. The System Storage Archive Manager server makes use of GPFS functionality by
a certain setup within the Information Archive appliance. For instance, System Storage
Archive Manager uses file device classes instead of random access file device classes. With
that setup, the appliance can store and manage multiple billions of documents over its
deployment lifetime.


The System Storage Archive Manager Collections are created and administrated through the
IA GUI running on the Management Console. The graphical user interface (Information
Archive GUI) on the Management Console can be accessed through a HTTP web browser.
The Information Archive GUI works with various user roles and shows various panels and
results depending on those roles. Each administrative user has to log on to the Information
Archive GUI with its own user account and password.

Optionally you can attach tape devices to the Information Archive appliance. Tape attachment
is already preconfigured in Information Archive and therefore very easy to configure. With
tape attachment, you can automatically migrate data from disk to tape. Thresholds and
migration delays are used to control the migration process and guarantee the availability and
performance for your data. With tape attachment, you can also back up and restore the
System Storage Archive Manager environment and help prepare for disaster protection.

To use the System Storage Archive Manager Collection, you must follow four basic steps:
1. Create a System Storage Archive Manager Collection from the Information Archive GUI
within the Information Archive Management Console. The Create Collection Wizard will
guide you through the entire process.

Tip: Before you create a System Storage Archive Manager Collection, you must enable
support for this collection type. If support was not enabled during initial configuration,
you can use the appliance properties notebook to enable the support.

2. Configure the retention policy for the new collection by creating a System Storage Archive
Manager policy domain or configuring the default System Storage Archive Manager policy
domain that is created during the creation of the collection. System Storage Archive
Manager is also administrated at the administrative interface in the Management Console,
you can use the Information Archive GUI or command line (Information Archive CLI).
3. Register a client node in System Storage Archive Manager so you can create an account
on the Information Archive server for client applications (archive applications).
4. Configure an external archive appliance, such as the one corresponding to a System
Storage Archive Manager client node registered in step 3, to use Information Archive as
storage device. The external archive appliance is not part of the Information Archive
appliance.

If you are using document management systems or other archive applications that cannot
connect to the Information Archive by the System Storage Archive Manager interfaces, you
might consider using the open standard interfaces of Information Archive. These interfaces
are not covered in this chapter, however, we describe them in Chapter 6, “File Archive
Collections” on page 167.

5.2 IBM System Storage Archive Manager overview
A System Storage Archive Manager server is much like any other IBM Tivoli Storage
Manager server. All features to administer the server and manage data objects and the
storage repository are still available. Most of the devices that are supported with Tivoli
Storage Manager server are available for an Information Archive System Storage Archive
Manager server.

System Storage Archive Manager was introduced as a separately licensed product in Version
5.2.2 and was designed to help meet data retention and disposition compliance regulations
and policies. System Storage Archive Manager uses the IBM Tivoli Storage Manager
Extended Edition source code.

Chapter 5. System Storage Archive Manager Collections 117

Tip: IBM Tivoli Storage Manager and IBM System Storage Archive Manager share the
same source code for executables but are intended for other usage. These two products
have unique licenses. However, only the System Storage Archive Manager server shows
the unique name, whereas all accompanying components for that server are still named
with IBM Tivoli Storage Manager.

System Storage Archive Manager provides storage management services that permit users
to archive files from their workstations or file servers to archive retention protected storage.
Archived copies of files can be retrieved to local workstations. System Storage Archive
Manager also includes an application program interface (API) client program that you can use
to enhance a content-management application with storage management services. When an
application is registered with a server as a client node, the application can archive and
retrieve objects from archive retention-protected storage. We refer to all those applications in
general as archive applications.

System Storage Archive Manager uses chronological and event-based retention policies.
Chronological retention is a calendar-based policy in which the final expiration countdown
begins when an object is sent to System Storage Archive Manager storage. Event-based
retention requires a predefined activation event to occur before the final expiration countdown
starts. System Storage Archive Manager provides the ability to override prescribed retention
policies using the deletion hold and release events.

System Storage Archive Manager offers rich functionality and features giving you a powerful
and comprehensive archive retention solution, hence they can all be found in the Information
Archive appliance:
System Storage Archive Manager runs on vendor neutral storage technology, giving you
the ability to utilize hundreds of types of disk, tape, optical, and DVD media on which to
retain your data. In case of Information Archive, the internal disk storage subsystem can
be extended over the time and can also be replaced when necessary. Substitution of the
disk storage subsystem is accompanied by System Storage Archive Manager with data
migration services and validation methods for data integrity.
Hierarchical storage capabilities allow you to create policies so data is stored on the type
of media that best meets data longevity, access speed, and cost needs. For instance, with
Information Archive, you can attach tape devices to back up all data. Migration automates
moving data from one type of media to another as media needs change, and as new types
of media become available in the market.
Archive Manager's expiration policies expire the data when it is no longer needed, thus
freeing up the WORM protected disk storage media and saving you money. With
Information Archive, the expired data in the disk storage subsystem will be erased and the
space will be used again to store new data. If needed, data shredding can be configured to
erase the data in an even more secure way.
Off-site protection of the data is standard in the System Storage Archive Manager. Off-site
copies can be created onto any of the hundreds of types of media supported, and like the
primary copy, is policy-managed to allow for expiration. WORM tape devices are a good
choice for that kind of protection.

It is beyond the scope of this book to explain System Storage Archive Manager in detail.
This book focuses on the System Storage Archive Manager fundamentals necessary to
understand the Information Archive appliance and explores what customizing has already
been done to the System Storage Archive Manager server provided in Information Archive.


Tip: For a detailed overview of System Storage Archive Manager V6.1 and its
complementary products, see the IBM Tivoli Storage Manager Version 6.1 information
center at the following location:
http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp

5.2.1 IBM System Storage Archive Manager architecture overview
System Storage Archive Manager is implemented as a client/server software application with
various components, depending on the function that has to be provided. Figure 5-2 shows the
System Storage Archive Manager architecture and the most important components.

Client Environment Server Environment
TS Administrative Client
M Integrated Solutions Console
Administration Center
Web Browser
Command Line Interf ace
TS Administrative Client
M
Server TS Backup-Archive Client
M
- Lapt op, Desktop
F F
lat ile
- Workstat ion Web Browser
- File Server Command Line Interf ace
DB LOG Disk
- Server (Print , Proxy, …) Graphical User Interface
Local/ Metro/ Wide
File Server TSM for HSM Optical
-F S
ile erver
Area Network
Flat File

Tape
Command Line Interface
Graphical User Interface
SS S
AM erver Storage Repository
Application Server
- Database Server TS API
M
- E-Mail Server Legacy D a
at
- ER Server
P
- Port al Server
Command Line Interface
- File Server

Figure 5-2 IBM System Storage Archive Manager architectural overview

The System Storage Archive Manager server is running in the Information Archive appliance
while various clients are based upon any archiving application connected to the System
Storage Archive Manager server through TCP/IP networks.

The core product of the entire System Storage Archive Manager environment is the System
Storage Archive Manager server with its relational database and storage repository. The
server basically provides data management, retention policies, and storage. The System
Storage Archive Manager server can be administrated from any available Tivoli Storage
Manager administrative client, which is represented by executable files, and a command line
interface, which is connected to the System Storage Archive Manager server or to another
administrative server called the Integrated Solutions Console (ISC).

The ISC can be reached with any web browser in the enterprise. The ISC is a generic IBM
administration interface where various applications can be embedded through plug-ins. The
plug-ins are called the IBM Tivoli Storage Manager Administration Center (Administration
Center) and in the case of a System Storage Archive Manager server, you first log in to the
ISC and then can administrate the System Storage Archive Manager server with the
embedded Administration Center. Both components (ISC and Administration Center) are
available with Information Archive.


From a System Storage Archive Manager perspective, the System Storage Archive Manager
clients are systems that exchange data with the System Storage Archive Manager server
through TCP/IP networks. There are two types of System Storage Archive Manager clients:
The first type of client, the IBM Tivoli Storage Manager backup-archive client, is able to
use System Storage Archive Manager directly as a storage repository for archive data.
Because the System Storage Archive Manager server is intended to help with regulatory
retention, the IBM Tivoli Storage Manager backup-archive client is not able to use its
backup functions with the System Storage Archive Manager server. They are disabled.
The second type of client uses the IBM Tivoli Storage Manager Application Program
Interface (API). Products that use the API with System Storage Archive Manager are
typically document content management systems, enterprise content management
systems, and so on. Tivoli Storage Manager for HSM for Windows is also a product that
uses the API to do hierarchical storage management for NTFS file systems on Microsoft
Windows.

Although various types of System Storage Archive Manager clients can use a storage area
network (SAN) for their normal business, like LAN-free backup and restore, they are not able
to do so with System Storage Archive Manager in Information Archive. Due to the necessity to
share the back-end storage devices between the server and the client in case of SAN
services, Information Archive avoids that for compliance reasons.

Attention: Archive applications (System Storage Archive Manager clients) can only
communicate over TCP/IP when archiving to an Information Archive System Storage
Archive Manager Collection.

IBM System Storage Archive Manager server
The System Storage Archive Manager server consists of a runtime environment, an IBM DB2
database, and a data storage hierarchy (also known as a storage repository). In the case of
Information Archive, those three components are integrated into the appliance and they run
on the cluster nodes.

The DB2 database stores all information about the running environment and the managed
data. Included are retention policies, user management, and metadata for the archived data.
The storage hierarchy is used to store the managed data depending on various requirements
and in association with the retention policies.

System Storage Archive Manager database and database log files
With IBM System Storage Archive Manager V6.1 and later, the recovery log is comprised of
two primary storage locations. These locations are the active log and the archive log. For
security reasons, the active log can be mirrored by DB2, the archive log can have an overflow
location. Information Archive uses all kind of security with the System Storage Archive
Manager database except the archive overflow location. Because Information Archive uses
GPFS, the file system for the archive log is not limited to any size. Hence, Information Archive
has no need to utilize the overflow location.


The DB2 environment for Information Archive is shown in Figure 5-3.

DBDirectory ACTIVELOGDirectory
S0000011.LOG

Database S0000012.LOG

MIRRORLOGDirectory
S0000011.LOG

S0000012.LOG

DBBACKUPDirectory ARCHLOGDirectory
S0000000.LOG

67894321.DBV S0000001.LOG

67894322.DBV ARCHFAILOVERLOGDirectory

S0000006.LOG

Figure 5-3 System Storage Archive Manager database, database log files, and database backup files

The active log is used to store current in-flight transactions for the server. For example, if the
server has 10 archive client sessions performing archiving or retrieving, the transactions used
by those sessions will be represented in the active log and used to track changes to the
server database such as the insert, delete, or update to records for tables within the server
database.

The archive log contains copies of closed log files that were in the active log at an earlier time.
The archive log is not needed for normal processing, but is typically needed for recovery of
the database. To provide roll-forward recovery of the database to the current point in time, all
logs since the last database backup must be available for the restore operation. For the
System Storage Archive Manager server, the archive log is included in database backups, so
that it can be used for roll-forward recovery of the database. The pruning of the archive log
files is based on full database backups. Backups can be written to attached storage devices
like disk storage subsystems or tape devices.

System Storage Archive Manager can designate a secondary archive log location, also called
an archive failover log directory. The archive failover directory is used by the server if the
archive log directory runs out of space. Specifying an archive failover directory is optional, but
can prevent problems that occur if the archive log runs out of space. With Information Archive,
thanks to GPFS and the overall storage capacity, it is very unusual for the archive log
directory to run out of space. Hence, there is no secondary archive log location with

When the active log contains log files that are full, the log files are closed by DB2 and get
copied to the archive log directory, transactions might still be active when the file gets
archived. The server continues to copy full log files to the archive log directory until the
directory becomes full, then copies will go to the failover archive log directory. If even the
failover archive log directory fills up, for example, because of unexpected workload, the active
logs will retain in the active log directory. This can result in an out of log space condition and a
server halt if the active log directory fills up, too. Information Archive health monitoring as well
as its reporting and monitoring features help you become aware of that situation in advance.


Storage repository
A System Storage Archive Manager server can write data to more than 400 types of devices,
including hard disk drives, disk arrays, and subsystems, stand-alone tape drives, tape
libraries, and other forms of random and sequential-access storage. The media that the
server uses are grouped into storage pools, and various device classes support the various
technologies.

For the Information Archive appliance, the storage pools are implemented through a private
SAN attachment to the 2231-D1A disk controllers. The disk subsystem is configured as a
Redundant Array of Independent Disks (RAID) 6 to maintain data integrity even in the event of
two disk failures. The filesystem is build upon the IBM General Parallel File System (GPFS)
and System Storage Archive Manager leverages that file system with its database and
recovery log as well as with all archived data.

The base 2231-IA3 appliance frame supports only one Storage Controller and therefore only
one collection. An expansion frame (2231-IS3) can be attached to the base frame to support
two more storage controllers and so also two more collections, if needed. Multiple System
Storage Archive Manager collections are typically needed for very large environments to
balance the work load, and for compliance reasons to divide systems physically.

Optional tape attachment with Information Archive can expand the storage repository to
migrate data and to use backup and restore as well as disaster protection.

Tip: Although optional, it is highly desirable to use the tape attachment feature for
Information Archive. Tapes extend the Information Archive storage capacity by allowing
migration from the default appliance disk media. Moreover, you can also make backups of
your archived data and other elements of your Information Archive appliance, enabling
Enhanced Remote Mirroring protection.

Client nodes
A client node, in the context of the Information Archive System Storage Archive Manager
Collection, is an application that communicates and transfer data objects for archiving to the
System Storage Archive Manager server. Therefore, the client often is referred to as archiving
application. A client node is registered in a policy domain and bound to the policies of that
domain on the server.

There are three types of client nodes that can be used directly with the System Storage
Archive Manager server:
IBM Tivoli Storage Manager API
IBM Tivoli Storage Manager backup-archive client
IBM Tivoli Storage Manager for HSM for Microsoft Windows

Application program interface (API)
IBM System Storage Archive Manager provides a data management application program
interface (API) that can be used to implement application clients to integrate popular business
applications, such as databases or groupware applications. The API also adheres to an open
standard and is published to enable customers and vendors to implement specialized or
custom clients for particular data management needs or nonstandard computing
environments. The API enables an application client to use the System Storage Archive
Manager storage management functions. The API includes function calls that you can use in
an application to perform the following operations: start or end a session, assign
management classes to objects before they are stored on a server, archive objects to a
server, and signal retention events for retention such as activate, hold, or release.


Alternatively, some vendor applications exploit the API by integrating it into their software
product to implement new data management functions or to provide archival functionality on
additional system platforms. Some examples are IBM Content Manager, IBM Content
Manager OnDemand, IBM CommonStore for SAP® R/3, IBM InfoSphere Content Collector,
IBM Optim, and IBM Filenet.

The API is published to enable customers or vendors to implement their own solutions
following their special needs, including full documentation available on the Internet. For more
information, see IBM Tivoli Storage Manager: Using the Application Programming Interface,
SC23-9793, available at:
http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.client.deve
lop.doc/b_api_using.pdf

IBM Tivoli Storage Manager backup-archive client
The backup-archive client provides an easy and effective way to archive and retrieve data
from a workstation. The process is easy and menu driven. The backup-archive client can be
accessed either directly as an application installed on the client node (command line and
GUI) or can be accessed remotely through a web browser. The processes can be automated
with an integrated scheduler that can be configured on the System Storage Archive Manager
server. Keep in mind that the backup feature of the backup-archive client is disabled when
used with a System Storage Archive Manager server (as is the case for Information Archive).

IBM Tivoli Storage Manager for HSM for Microsoft Windows
The IBM Tivoli Storage Manager for HSM for Windows client provides hierarchical storage
management (HSM) for Windows NTFS file systems.

HSM is a data storage system that automatically moves data between high-cost and low-cost
storage media. HSM exists because high-speed storage devices, such as hard disk drives,
are more expensive per byte stored than slower devices, such as optical discs and magnetic
tape drives. Although it is ideal to have all data available on high-speed devices all the time,
doing this is prohibitively expensive for many organizations. Instead, you can use HSM to
store the bulk of your enterprise data on slower devices, and then copy data to faster disk
drives only when needed. In effect, HSM turns the fast disk drives into caches for the slower
mass storage devices. The HSM for Windows client monitors the way files are used and lets
you automate policies as to which files can safely be moved (migrated) to slower devices and
which files must stay on the hard disks.

File migration, unlike file backup, does not protect against accidental file deletion, file
corruption, or disk failure. Continue to back up your files regardless of whether they reside on
your local file system or are migrated to System Storage Archive Manager storage. You can
use the IBM Tivoli Storage Manager backup-archive client to back up and restore migrated
files in the same manner as you might back up and restore files that reside on your local file
system. That cannot be used with a System Storage Archive Manager but with a regular IBM
Tivoli Storage Manager. If you accidentally delete stub files from your local file system, or if
you lose your local file system, you can restore the stub files.

The IBM Tivoli Storage Manager for Space Management client for UNIX and Linux is a HSM
client that migrates files on appropriate file systems on UNIX and Linux. The client functions
for threshold migration, demand migration, selective migration, selective and transparent
recall includes processing GPFS file systems containing multiple HSM managed storage
pools. Unlike the IBM Tivoli Storage Manager for HSM for Windows client, this kind of client
can only be connected to an IBM Tivoli Storage Manager server. An IBM Tivoli Storage
Manager for Space Management client cannot communicate with a System Storage Archive
Manager server.


Tip: An IBM Tivoli Storage Manager for HSM for Windows client can migrate and recall
data with System Storage Archive Manager, whereas an IBM Tivoli Storage Manager for
Space Management client cannot. Therefore, do not plan to migrate files from UNIX and
Linux into Information Archive through the IBM Tivoli Storage Manager HSM client.

Administrative interfaces
The administrative interfaces allow administrators to control and monitor server activities,
define management policies for clients, and set up schedules to provide services to clients
and the server at regular intervals. Administrative interfaces available include a command-line
administrative client (dsmadmc) and a web browser interface called the Administration Center.
The Administration Center is embedded in the Integrated Solutions Console (ISC) and allows
you to manage and control multiple servers from a single interface that runs in a web browser.

Information Archive supports both types of administration, that is, you can use the
command-line administrative client as well as the Administration Center within the ISC. Also,
depending on how many document collections you are using, there are several System
Storage Archive Manager or IBM Tivoli Storage Manager servers reachable from only that
one Administration Center.

Command-line administrative client (dsmadmc)
The command-line administrative client is preinstalled and preconfigured on the Information
Archive appliance. You can start it with a user account with the administrative role of an
IA Archive Administrator or the IA System Administrator.
Complete the following steps from the keyboard video mouse (KVM) console in the appliance,
or remotely through a Secure Shell (SSH) connection:
1. Log on to the Management Console server.
2. At the command prompt, enter dsmadmc -server=<collection_name>
where collection_name is the name of the System Storage Archive Manager Collection
that you are accessing.
3. Enter the user name and password that are eligible for access to the collection.
4. You will get a shell with a prompt where you can enter Tivoli Storage Manager/System
Storage Archive Manager commands (see Example 5-1.)
5. The help command gives you help for all possible commands and their syntax.
6. To exit the shell, enter the command quit.

Example 5-1 Tivoli Storage Manager/System Storage Archive Manager shell with dsmadmc command
iaadmin@IA-Primary:~> dsmadmc -server=SSAM1
Command Line Administrative Interface - Version 6, Release 1, Level 3.3
(c) Copyright by IBM Corporation and other(s) 1990, 2009. All Rights Reserved.

Enter your user account: itsoadmin

Enter your password:

Session established with server SSAM1: Linux/x86_64
Server Version 6, Release 1, Level 2.2
Server date/time: 02/22/2010 17:29:03 Last access: 02/18/2010 21:53:38

tsm: SSAM1>


Administration Center
For the central administration of one or more System Storage Archive Manager instances,
as well as the whole data management environment, System Storage Archive Manager
provides a Java-based graphical administration interface called the Administration Center,
which is installed as an Integrated Solution Console (ISC) component. The Administration
Center and the ISC are preinstalled and started automatically at the Information Archive
appliance.

The IBM Tivoli Storage Manager Administration Center enables administrators to control and
monitor server activities, define management policies for clients, and set up schedules to
provide services to clients at regular intervals. Figure 5-4 shows the Integrated Solutions
Console as you find it in the Information Archive appliance. The IBM Tivoli Storage Manager
Administration Center is provided as a Tivoli Storage Manager headline and tree structure on
the left.

Figure 5-4 Integrated Solutions Console and Tivoli Storage Manager Administration Center

Working with ISC and IBM Tivoli Storage Manager Administration Center
In this section we give you a short introduction on how to start and configure the IBM Tivoli
Storage Manager Administration Center on the Information Archive appliance. A user account
with the administrative role of a tsmAdministrator is needed for this kind of login.

Follow these steps:
1. To connect to the IBM Tivoli Storage Manager Administration Center web interface, start a
web browser and start an https session (Secure HTTP) to the TCP/IP address of the node
or workstation where the IBM Tivoli Storage Manager Administration Center and the ISC
are installed, using the port number specified when installing the ISC:
https://ip_of_management_station:9043/ibm/console


2. Log in at ISC with the appropriate user account.
3. Expand the Tivoli Storage Manager tree in the left pane of the panel and navigate to the
most convenient topic (Figure 5-5).

Figure 5-5 Tivoli Storage Manager Administration Center - Manage Servers

Now you can select various functions to administrate your Information Archive System
Storage Archive Manager Server. For example, in Figure 5-5, we use the Manage Servers
topic to see all configured System Storage Archive Manager and IBM Tivoli Storage
Manager servers within our Information Archive.
4. Use the Manager Servers, select the System Storage Archive Manager server you want to
connect to, and then Select Action to use the command line.

Figure 5-6 Tivoli Storage Manager Administration Center - Use Command Line

After that, you can use various commands on the command line to administrate your
Information Archive System Storage Archive Manager Server.


Automation
The System Storage Archive Manager server includes a central scheduler that runs on the
System Storage Archive Manager server and provides services for use by the server
(administrative schedules) and clients (client schedules). You can schedule administrative
commands to tune server operations and to start functions that require significant server or
system resources during times of low usage. You can also schedule a client action, but that is
unusual for a data retention-enabled client. Each scheduled command (administrative or
client) is called an event. The server tracks and records each scheduled event in the database
and produces output within its activity log.

There are preconfigured administrative schedules in Information Archive, that can be
analyzed with the query schedule t=a command. There are no preconfigured client
schedules with Information Archive.

5.2.2 IBM System Storage Archive Manager basic concepts
This section is intended for readers who are not familiar with the product IBM System Storage
Archive Manager and its particular concepts. We explain the basics concepts of IBM System
Storage Archive Manager, because from the concepts we can derive several preferences and
best practices for the setup and configuration of a System Storage Archive Manager
Collection.

The System Storage Archive Manager server manages client data objects based on
information provided in administrator-defined policies.

Data objects can be subfile components, files, directories, or raw logical volumes that are
archived from client systems; they can be objects, such as tables, logs, or records from
database applications, or simply a block of data that an application system archives to the
server. The System Storage Archive Manager server stores these objects within his storage
hierarchy that is grouped into storage pools.

We explain these concepts with regard to the IBM System Storage Archive Manager server
on the Information Archive appliance.

System Storage Archive Manager storage pools and storage hierarchy
System Storage Archive Manager manages data as objects stored in System Storage Archive
Manager storage pools (see Figure 5-7). Each object has an associated management policy
to which it is “bound.” The policy defines how long to keep that object and where the object
enters the storage hierarchy.

The physical location of an object within the storage pool hierarchy has no effect on its
retention policies. An object can be migrated or moved to another storage pool within a
System Storage Archive Manager storage hierarchy. This can be useful when freeing up
storage space on higher performance devices, such as disk, or when migrating to new
technology.

Objects also can and ought to be copied to copy storage pools for disaster recovery
protection. To store these data objects on storage devices and to implement storage
management functions, System Storage Archive Manager uses logical definitions to classify
the available physical storage resources. Most important is the logical entity called a storage
pool, which describes a storage resource for a single type of media such as disk volumes,
which are files on a file system, or tape volumes, which are cartridges in a library.


Figure 5-7 shows the IBM System Storage Archive Manager storage hierarchy.

Archive Application

LAN, WAN
Storage Pool Volumes

Data Object D evice Class DISK

Primary
Storage Pool
Copy
Storage Pool

Migrate
Copy
SSAM Server Storage
pool
Devi ce C lass TAPE*

Primary
Device C lass TAPE*
Storage Pool
*Device Class Tape
exam ple:
Storage Hierarchy devclass =3592class
devtyp e=3592
Storage Repository

Figure 5-7 IBM System Storage Archive Manager storage hierarchy

Device classes
A logical entity called a device class is used to describe how System Storage Archive
Manager can access physical volumes to place the data objects on them. Each storage pool
is bound to a single device class.

The storage devices used with System Storage Archive Manager vary mainly in their
technology and total cost.

To understand this concept, you can imagine the storage as a pyramid (or triangle), with
high-performance storage in the top (typically disk), normal performance storage in the
middle (typically optical disk or cheaper disk), and low-performance, but high-capacity,
storage at the bottom (typically tape). Figure 5-7 illustrates this idea, as well as Figure 5-2 on
page 119.

Disk storage devices are random access media, making them better candidates for storing
frequently accessed data. With Tivoli Storage Manager and System Storage Archive
Manager disk storage devices can also be used as sequential access media, but that is done
with certain enhancements. For example, although the access mode is sequential, you have
parallel input and output on the volume available.

Tape, however, is a high-capacity sequential access media, which can easily be transported
off-site for disaster recovery purposes. Access time is much slower for tape due to the
amount of time needed to load a tape in a tape drive and locate the data. However, for many
applications, that access time is still acceptable. With Tivoli Storage Manager/System Storage
Archive Manager, tape volumes, located in a tape library, are accessed by the application that
is retrieving data from them transparently. Tapes no longer in the library are off-line, requiring
manual intervention.


Device types
Each device defined to System Storage Archive Manager is associated with one device class.
Each device class specifies a device type.

A device type identifies a device as a member of a group of devices that share similar media
characteristics. For example, the 3592 device type applies to IBM System Storage Enterprise
Tape Drive 3592 or IBM System Storage TS1120 and TS1130. The LTO device class applies
to the Linear Tape Open standard of tape drives, for example, the IBM System Storage
Ultrium LTO-4 tape drive.

The device type also specifies management information, such as how the server gains
access to the physical volumes, recording format, estimated capacity, and labeling prefixes.

Device types include DISK, FILE, and a variety of removable media types.

Note that a device class for a tape or optical drive must also specify a library.

Device access strategy
The access strategy of a device is either random or sequential in regular System Storage
Archive Manager and IBM Tivoli Storage Manager environments. With Information Archive,
you will use all devices only as sequential, regardless of the physical characteristics:
Primary storage pools
Copy storage pools
System Storage Archive Manager database backups
Export
Import

Tape devices
System Storage Archive Manager supports a wide variety of enterprise class tape drives and
libraries. The following link connects you to the product support website where you will find a
link to the currently supported devices list:
http://www-01.ibm.com/software/sysmgmt/products/support/IBM_TSM_Supported_Devices_
for_Linux.html

Important: With Information Archive, the usage of IBM 3494 Tape Libraries as well as
ACSLS managed tape libraries is not supported. Keep this in mind when reading the
foregoing support list.

Use tape devices for the purpose of backing up your primary storage pools to copy storage
pools and backing up the System Storage Archive Manager database. Tape devices are
well-suited for this, because the media can be transported off-site for disaster recovery
purposes.

A tape drive or tape library is not included in the Information Archive appliance; however, any
system is tape-ready and you can attach tape devices that are supported by System Storage
Archive Manager/Tivoli Storage Manager on the Linux platform (see information above) and
that best suit your data retention requirements. We suggest that you use the IBM System
Storage TS1130 Tape Drive or the IBM Ultrium 4 LTO drives in combination with rewritable
and WORM media. We discuss attaching tape in Chapter 10, “Tape attachment with
IBM Information Archive” on page 403.


System Storage Archive Manager policy concepts
A data storage management environment consists of three basic types of resources: client
systems (for example, applications using the System Storage Archive Manager API to archive
data), policy, and data.

The client systems run the applications that create or collect data to be managed.

The policies are the rules to specify how to manage the archived objects, for example, how
long to retain an archive object in storage, whether chronological or event-based archive
retention is used, in which storage pool to place an object, or, in the case of backup, how
many versions to keep, where they must be stored, and what System Storage Archive
Manager does to the archive object after the data is no longer on the client file system.

Client systems, or nodes, in System Storage Archive Manager terminology, are grouped
together with other nodes with common storage management requirements into a policy
domain. The policy domain links the nodes to a policy set, which is a collection of storage
management rules for various storage management activities.

Client node: The term client node refers to the archive application sending data to the
Information Archive System Storage Archive Manager server.

A policy set consists of one or more management classes. A management class contains the
rule descriptions called copy groups and links these to the data objects to be managed.

A copy group is the place where all the storage management parameters are defined, such as
the number of stored copies, retention period, and storage media. When the data is linked to
particular rules, it is said to be bound to the management class that contains those rules.
There are two types of copy groups available: backup and archive. Only archive copy groups
are used with System Storage Archive Manager.

Another way to look at the components that make up a policy is to consider them in the
hierarchical fashion in which they are defined, that is, consider the policy domain containing
the policy set, the policy set containing the management classes, and the management
classes containing the copy groups and the storage management parameters (Figure 5-8).

Nodes
Clients Policy domain

Policy set
Copy group
Management
class #1 Rules Data

Copy group
Management
class #2 Rules Data

Copy group
Management
class #3 Rules Data

Figure 5-8 Policy relationships and resources


Policy domain
This feature enables an administrator to group client nodes by the policies that govern their
files and by the administrators who manage their policies. A policy domain contains one or
more policy sets, but only one policy set (named ACTIVE) can be active at a time. The server
uses only the ACTIVE policy set to manage files for client nodes assigned to a policy domain.

You can use policy domains to perform the following tasks:
Group client nodes with similar file management requirements
Provide unique default policies for various groups of clients
Direct files from various groups of clients to other storage hierarchies based on need
(unique file destinations with various storage characteristics)
Restrict the number of management classes to which clients have access

Figure 5-9 summarizes the relationships among the physical device environment, System
Storage Archive Manager storage and policy objects, and clients:
1. When clients are registered, they are associated with a policy domain. Within the policy
domain are the policy set, management class, and copy groups.
2. When a client archives an object, the object is bound to a management class. A
management class and the archive copy group within it specify where files are stored first
(destination), and how they are managed when they are archived.
3. Storage pools are the destinations for all stored data. An archive copy group specifies a
destination storage pool for archived files. Storage pools are mapped to device classes,
which represent devices. The storage pool contains volumes of the type indicated by the
associated device class. For example, the storage pool filepool on Information Archive,
which uses the device class FILECLASS, stores all data in a sequential file pool on disk.

Data stored in disk storage pools can be migrated to tape or optical disk storage pools and
can be backed up to copy storage pools.

SSAM Policy Construct Overview
Client Policy Domain
 Policy Domain
Policy Set Active • Group client nodes by policies.
• Specifies retention grace period
Mgmt. Class A Mgmt. Class B

Archive copy Archive copy  Policy set
Group AA Group BB • Contains mgmt classes.
• At least one default mgmt class.
• Multiple policy sets per domain
• Only one is active.
Primary Pool 1 Primary Pool 2
 Mgmt Class
• Associates files with one archive
copy group.
• Multiple mgmt. classes per policy
set,
NextPool Copy Pool • One default – STANDARD - all files
volume1 volume2
not bound to mgmt. class are
assigned to default class.

disk1 disk2  Archive Copy Group
• Controls archive processing of a
file (retention time, option, pool).
• Only one group per mgmt. class.

Figure 5-9 Example of the policy structure for archive


Policy set
The policy set specifies the management classes that are available to groups of users. Policy
sets contain one or more management classes. Only one policy set, the ACTIVE policy set,
controls policies in a policy domain.

Management class
The management class associates client files with archive copy groups. A management class
can contain one backup or archive copy group, both a backup and an archive copy group, or
no copy groups. Users can bind (that is, associate) their files to a management class through
the include-exclude list. You must identify one management class as the default management
class. If objects are not explicitly bound to a certain management class, they are
automatically bound to the default management class.

Attention: With the System Storage Archive Manager Collection, management classes
can only contain archive copy groups, because backups are not possible on a System
Storage Archive Manager server.

Archive copy group
This group controls the archive processing of files associated with the management class. An
archive copy group determines the following characteristics:
The retention method; possible values are creation (time-based) or event-based retention.
How long, in days, the server keeps archived copies of your files
The minimum retention time, which is applicable only for event-based retention
The management class to which the archive copy group is assigned
The storage pool (destination) in which the archived file is stored
Whether to archive a file when it is in use

5.3 IBM System Storage Archive Manager features
In this section, we discuss the System Storage Archive Manager features that are especially
designed for the archive, retrieval, and securing of data.

The available features of System Storage Archive Manager and the System Storage Archive
Manager Collections, respectively, are:
Access control and authentication
Data retention protection
Creation-based retention
Event-based retention
Deletion hold and release
Data encryption / Tape drive encryption
Data shredding
Data deduplication

5.3.1 Access control and authentication
IBM System Storage Archive Manager uses access control and internal code processing to
guarantee data security and data integrity. System Storage Archive Manager prohibits the
deletion of data before its scheduled expiration. Short of physical destruction of the storage
media or server, or deliberate corruption of data or deletion of the Archive Manager database,
System Storage Archive Manager will not allow data to be deleted before its scheduled
expiration date. Content management and archive applications can apply business policy
management for the ultimate expiration of archived data at the appropriate time.


Different user roles and explicit user credentials are the basis for System Storage Archive
Manager access control. A Tivoli Storage Manager/System Storage Archive Manager
administrator manages resources on the server, such as storage pools, devices, and data
management policies. An administrator or operator might also be responsible for backup and
restore of archived data. The number of administrators and their level of privileges will vary
according to environment.

Within Information Archive, you can grant administrative roles to user accounts within the
Information Archive GUI. All user accounts with the administrative role tsmAdministrator are
propagated to the System Storage Archive Manager server automatically. Even password
changes later on in the Information Archive GUI or in LDAP, if you use an centralized user
management, are propagated automatically to the System Storage Archive Manager
Collection. This user is propagated with passexp=0 and system privileges.

Beside this automated propagation of user accounts, there are two ways to create a Tivoli
Storage Manager/System Storage Archive Manager administrator account manually, using
the register node and register admin commands. The register admin command is used
to explicitly create an administrator account with certain defined privileges. The register
node command automatically creates an administrator account with the same name as the
node and owner access privilege to the node.

Privileges are granted to an administrator through the grant authority command. You need
system privileges to issue this command. You can check the privileges of your user with the
command query admin f=d.

In the case of the Information Archive appliance, System Storage Archive Manager user roles
and credentials can be created like described above, with the IBM Tivoli Storage Manager
Administration Center at the Integrated Solutions Console, and with the Information Archive
GUI (that is, when you create Information Archive users with the privilege of
tsmAdministrator).
Authentication for a System Storage Archive Manager collection ensures that only the
designated client nodes (register node) can read and commit documents and only the
designated administrators (register admin) can manage the administrative interface.

Beside the roles, there are several additional features to control the access, security, and
integrity of the environment:
Password expiration period
Limitation for invalid password attempts
Tamper proof internal code processing (deletion protection)
Activity log
Password and data encryption

5.3.2 Archive copy group retention parameters
In order to use the archive function of System Storage Archive Manager, you must define
valid policies that include defining a policy domain, policy set, management class or classes,
and an archive copy group, as well as setting archive retention parameters in the archive copy
group and associating your application clients with the System Storage Archive Manager
policies.

Tip: Define a test policy domain for test data. We suggest that you define a test policy
domain and policy set for any pre-production testing. Remember that all of the test data
that you archive to a System Storage Archive Manager Collection cannot be deleted.


Two methods of archive retention
There are two methods of archive retention, which are defined by the parameters of the
archive copy group:
Chronological archive retention
Event-based archive retention

Next we look at the parameters of the archive copy group and their possible values for the two
archive retention methods.

Archive retention parameters
The most important archive retention parameter in regard to the retention period with System
Storage Archive Manager is RETVER (retain version). Possible values are RETVER=0 to
30,000 days or NOLIMIT.

Important: Selecting the NOLIMIT value on the Information Archive System Storage
Archive Manager server means that you will never be able to delete the data.

The retain version parameter (RETVER) within the archive copy group specifies the number
of days to retain each archive object. Possible values are 0 to 30,000 days or NOLIMIT, which
means that an archive copy is maintained indefinitely.

There are two other archive retention parameters, RETINIT and RETMIN:
RETINIT (retention initiation):
The possible values are RETINIT=creation or event.
The retention initiation (RETINIT) parameter specifies when the time specified by the
retain version (RETVER=n days) attribute is initiated. The possible values for this
parameter are creation or event. The default value is creation. In the following list, we
explain both values:
– RETINIT=creation (chronological archive retention):
By setting this parameter to creation (RETINIT=creation) in the archive copy group, you
specify that the retention time specified by the RETVER attribute (RETVER=n days) is
initiated right at the time an archive copy is stored on the server. This is referred to as
chronological archive retention.
– RETINIT=event (event-based archive retention):
By setting this parameter to event (RETINIT=event) in the archive copy group, you
specify that the retention time (RETVER=n days) for the archived data is initiated by an
application that used API function calls or the Web Client. If the application never
initiates the retention, the data is retained indefinitely. This method of archive retention
is referred to as event-based archive retention.
Possible events to signal through the API or the backup-archive client to the Information
Archive System Storage Archive Manager server are as follows:
– Activate: Activates the countdown of the RETVER value for the given event-based
object.
– Hold: Prevents the Information Archive System Storage Archive Manager server from
deleting the object, even if the RETVER period has ended. Signaling a “hold” does not
extend the retention period, but a hold object will only expire after a release event is
sent.
– Release: Removes the hold status of an object. The System Storage Archive Manager
server will then treat the object again according to the RETVER and RETMIN values.


RETMIN (retain minimum):
Possible values are RETMIN=0 to 30,000 days.
The retain minimum (RETMIN) parameter applies only to event-based archive retention
policy and specifies the minimum number of days to retain an archive object regardless of
the value of RETVER. The default value is 365. Possible values are 0 to 30,000 days.

We provide the following examples to give you insight into archive copy groups and defining
policy.

5.3.3 Chronological archive retention
Figure 5-10 shows a simplified view of a chronological retention policy. With
RETINIT=creation and RETVER=365 days, a file that is archived on day 0 is retained for 365
days and becomes eligible for expiration. In this case, after 365 days from the time the data
was created, all references to that data are deleted from the database, making the data
irretrievable from System Storage Archive Manager storage volumes. This kind of archive
retention is called chronological retention. By default, the RETINIT value is set to creation.

Retention: Choose chronological archive retention when the application that is doing the
archiving is not able to send retention events such as activate, hold, and release.

Figure 5-10 Chronological retention policy

Archive copy groups using the chronological retention policy satisfy many archive retention
requirements.

5.3.4 Event-based retention policy
In certain situations, data retention periods cannot be easily defined, or they depend on
events taking place long after the data is archived. Event-based archive retention is designed
to meet these requirements. Event-based retention policy is designed for applications that
use the IBM Tivoli Storage Manager API function calls to trigger events also known as
retention events. You can also use the IBM Tivoli Storage Manager backup-archive client to
archive client objects (data) using event-based policies and trigger retention events against
those objects.

Figure 5-11 shows a time line depicting an event-based policy. In this example, an application
using the API archives data using the retention values shown. The archived data is retained
for a minimum of 2,555 days (RETMIN=2555). If the retention time (RETVER) is activated
through an API retention event, System Storage Archive Manager assigns an expiration date
for this object.


The expiration date that System Storage Archive Manager assigns is whichever comes later,
either:
The date the object was archived, plus the number of days specified in the RETMIN
parameter.
The date the event was signaled, plus the number of days specified in the RETVER
parameter.

After reaching this expiration date, the data is eligible for expiration. When the time for
expiration occurs, all references to that data are deleted from the System Storage Archive
Manager database, making the data irretrievable from System Storage Archive Manager
storage volumes. This kind of archive retention is referred to as event-based retention.

Retention: Use event-based archive retention if the archive application you are using
(such as Content Manager together with Record Manager, IBM FileNet® P8 and so on)
uses the API function calls to activate the retention period of the archived data objects.

Figure 5-11 Event-based retention policy

Table 5-1 shows the information gathered from two archive queries that run after archiving a
file, one using creation-based archive policy and one using event-based archive policy.

Event-based retention: When an object is archived using event-based retention, System
Storage Archive Manager manages that object as though the RETVER parameter were set
to NOLIMIT until an event initiates the retention period (see Table 5-1).

Table 5-1 Status of files archived with creation-based and event-based retention
Object attributes in System RETINIT=CREATION RETINIT=EVENT
Storage Archive Manager/
Tivoli Storage Manager
database

Insert date 2006/2/28 12:16:30 2006/2/29 1:23:56

Expiration date 2016/3/9 12:16:30 65535/0/0 0:0:0 (= no limit)

Mgmt class CREATION EVENT

Retention initiated STARTED PENDING

Object Held FALSE FALSE


Notice that the status of the Retention-Initiated attribute is STARTED for the management
class CREATION, and PENDING for the management class EVENT. Also, compare the
expiration dates.

5.3.5 Deletion hold and release
Some regulations require that the data is retained longer than the minimum retention period
in certain cases. This might be due to any litigation, a legally-required or a company-required
audit, or a criminal investigation requiring the data as evidence. The IBM Tivoli Storage
Manager API (and IBM Tivoli Storage Manager backup-archive client) supports function calls
used to place a deletion hold on an archive object. These functions are also called retention
events. A deletion hold can be applied at any point in time during the retention period for an
archive object. The object will then be retained until a deletion release is applied. If a deletion
release is not applied, the object is retained indefinitely. Although deletion hold and release
are events, they can be applied to objects archived not only using the event-based policies,
but also the chronological, creation-based policies.

Figure 5-12 shows a time line depicting deletion hold and release. In “Sending retention
events using dapismp” on page 288, we demonstrate how to send deletion activate, hold, and
release on archived objects with the IBM Tivoli Storage Manager API.

Figure 5-12 Deletion hold and release

5.3.6 Data retention protection
Data retention protection ensures that archive objects will not be deleted from the Information
Archive System Storage Archive Manager server until the policy-based retention
requirements for that object have been satisfied.

Retention protection is based on the retention criterion for each object, which is determined
by the RETVER and RETMIN parameters of the archive copy group of the management class
to which the object is bound. If an object uses event-based retention (RETINIT=EVENT), the
object will not expire until whatever comes later: either the date the object was archived plus
the number of days in the RETMIN parameter, or the date the event was signaled plus the
number of days specified in the RETVER parameter. When using the chronological retention
(RETINIT=CREATION), the archive object will expire after the time that is set with the
RETVER parameter has elapsed.

Expiration period: You always need an event to start the expiration period for event-based
retention!


Table 5-2 shows the relationship between the various parameters and their use within certain
retention policies.

Table 5-2 Archive copy group parameters
Archive copy group Chronological retention Event-based retention
parameters

RETINIT RETINIT=CREATION RETINIT=EVENT
Defines when to initiate the The expiration date is based on The expiration date is based on
retention period defined in the the date the object was the date of the retention
RETVER attribute. archived plus RETVER. initiation event plus RETVER.

RETVER RETVER=0 to 30,000 days or RETVER=0 to 30,000 days.
Number of days to retain the NOLIMIT.
archive object after retention is
initiated.

RETMIN Not applicable. RETMIN=days.
Minimum number of days to Based on date object was
retain archive object. archived.

Earliest date when the object (date object was archived) + (Date retention was initiated
can become eligible for RETVER. through Event) + RETVER
expiration after retention has or
been initiated. (date object archived) +
RETMIN, whichever is longer.

Deletion protection: The following operations cannot delete archived data on an Information
Archive System Storage Archive Manager server:
Requests from the application client to delete an archive object prematurely
DELETE FILESPACE (from either a client or administrative command)
DELETE VOLUME DISCARDDATA=YES
AUDIT VOLUME FIX=YES

5.3.7 Expiration processing
The expiration processing deletes expired client archive data from storage pools based on
policy. Without the expiration process, no data is ever deleted from Information Archive.
You can run expiration processing either automatically, scheduled (preferred method), or
manually. Ensure that expiration processing runs periodically to allow the server to reuse
storage pool space that is occupied by expired client files.

Depending on the amount of files and the policies, expiration can consume a lot of hardware
resources (mainly CPU) and time. Therefore expiration processing can be narrowed down to
a single policy domain and client node. Only one expiration process is allowed at any time, but
this process can be distributed among threads (maximum 10). Furthermore, the maximum
time for a single expiration process can also be set.

Expiration: An archive file is not eligible for expiration if there is a deletion hold on it. If a
file is not held, it will be handled according to the existing expiration processing.


5.3.8 Encryption
In order to make the archived data more secure, the IBM Tivoli Storage Manager
backup-archive client, as well as the IBM Tivoli Storage Manager API, implement an
encryption function, which allows you to encrypt data before it is sent to the Information
Archive System Storage Archive Manager server. This helps secure archived-data during
transmission, and it means that the data stored in the System Storage Archive Manager
Collection is encrypted and thus is unreadable even by the administrator.

The encryption processing is the last task performed on the client system before the data is
sent to the server; other client operations such as compression (if enabled) happen before
encryption is done.

API encryption
You can use either a 56-bit DES or 128 AES (Advanced Encryption Standard). The default,
56-bit DES, can be overridden by setting the parameter ENCRYPTIONTYPE AES128 in the
dsm.opt (Windows) or dsm.sys (UNIX or Linux).

The encryption function enables you to choose which files are subject to encryption using an
include/exclude list. Set the include.encrypt parameter in the option file (dsm.opt or dsm.sys)
for the objects to encrypt (the default is NO encryption) and the exclude.encrypt for the
objects that you do not want to encrypt.

For example, to encrypt all data, set:
include.encrypt /.../* (AIX)
or
include.encrypt *...* (Windows)

To encrypt the object /FS1/DB2/FULL, set:
include.encrypt /FS1/DB2/FULL

For client applications using the API, there are two methods to handle encryption:
Application-managed encryption
Transparent encryption

These two methods are exclusive. In other words, choose only one method for any given
application client node. For both methods, an encryption password is used to generate the
real encryption key. The encryption password can be up to 63 characters in length, but the
key generated from it is always 8 bytes for 56 DES and 16 bytes for 128 AES.

Application-managed encryption means that the client application (archiving application) is
responsible for managing the keys (actually encryption passwords used by System Storage
Archive Manager to generate the encryption keys). In addition, the client application code
might have to be changed to communicate the password to the API on each archive or
retrieve operation.

On the other hand, transparent encryption provides encryption of application data without
requiring any changes to the client application and delegates all key management operations
(generation, storage, and retrieval) to the Information Archive System Storage Archive
Manager server.


Important: Because transparent encryption requires no changes in the archive
application, it is more convenient to use the transparent encryption rather then the
application-managed encryption.

Transparent encryption
Transparent encryption is the simplest and safest method to implement data encryption. One
random encryption key is generated per session (every time a client initiates a session with
the Information Archive System Storage Archive Manager server for archiving). The key is
generated with a random number generator on the client side.

For each archived object, the generated encryption key is sent to and stored in the
Information Archive System Storage Archive Manager server database. However, before it is
sent to the Information Archive System Storage Archive Manager server along with the
encrypted archived object, the key is encrypted using DES 56 encryption. After the server
receives the structure containing the encrypted encryption key, it decrypts the key,
re-encrypts the key using a specific server-based encryption mechanism, and stores it in the
database along with the corresponding object_ID.

Do not encrypt backups: If the encryption key is not available, data cannot be retrieved
under any circumstances. Be sure that you back up your System Storage Archive Manager
server database frequently to prevent data loss. Do not store the database backup on
encrypted media.

During a retrieval, the server uses the server-based mechanism to decrypt the key,
re-encrypts, and sends the re-encrypted key to the client along with the encrypted object.
In turn, the client (API) extracts the key and decrypts it. Finally, the decrypted key is used to
decrypt the data.

To enable transparent encryption, specify - ENABLECLIENTENCRYPTKEY YES in the
system option file dsm.opt (Windows) or dsm.sys (UNIX or Linux).

5.3.9 Data shredding
For System Storage Archive Manager Collections, expired documents are always deleted
through an automatic process (see “Expiration processing” on page 138), and can optionally
be “shredded”, whereby their data will be overwritten with a destructive bit pattern to render
them irretrievable.

After client data has expired, it might still be possible to recover it. For sensitive data, this
condition is a potential security exposure. The destruction of deleted data, also known as
shredding, lets you store sensitive data so that it is overwritten one or more times after it has
expired. This process increases the difficulty of discovering and reconstructing the data later.

System Storage Archive Manager performs shredding only on data in random access disk
storage pools. Shredding occurs only after a data deletion commits, but it is not necessarily
completed immediately after the deletion (this is controlled by the parameters, automatic or
manual). The space occupied by the data to be shredded remains occupied while the
shredding takes place and is not available as free space for new data until the shredding is
complete.


Important: There is no default configuration for data shredding on Information Archive.
Because data shredding is only working on random access disk storage pools, but the
predefined FILEPOOL storage pool is a sequential access type, you need to configure a
new storage pool when data shredding is needed. The new storage pool must use the
random access device type and data shredding must be enabled for this pool.

There are two shredding methods available: automatic and manual. You can see the default
method for your system with the System Storage Archive Manager query option command.
You can set the method on your system with the setopt shredding manual or setopt
shredding automatic command.

The advantage of automatic shredding is that it is performed without administrator
intervention whenever deletion of data occurs. This limits the time that sensitive data might be
compromised. Automatic shredding also limits the time that the space used by deleted data is
occupied. Shredding performance is affected by the amount of data to be shredded, the
number of times that data is to be overwritten, and the speed of the disk and server hardware.
You can specify that the data is to be overwritten up to 10 times. The greater the number of
times, the greater the security, but also the greater the impact on server performance.

The advantage of manual shredding is that it can be performed when it will not interfere with
other server operations. Manual shredding is possible only if automatic shredding is disabled.
If you have specified manual shredding with the SHREDDING server option, you can start the
shredding process by issuing the shred data command.

Note that to guarantee that all shreds are written to the disk, disk caching needs to be
disabled while the shred is being run. Therefore, do shredding when archiving of data is at a
minimum. If you do most of the archiving during the day, shredding can be scheduled to run
during the night.

5.3.10 Data deduplication
The integrated System Storage Archive Manager data deduplication is a method of
eliminating redundant data in sequential-access disk pools. One unique instance of the data
is retained on storage media, and redundant data is replaced with a pointer to the unique data
copy. The goal of deduplication is to reduce the overall amount of time that is required to
retrieve data by letting you store more data on disk, rather than on tape.

Data deduplication in the System Storage Archive Manager is a two-phase process. In the
first phase, duplicate data is identified. During the second phase, duplicate data is removed
by certain server processes, such as reclamation processing of storage-pool volumes. By
default, a duplicate-identification process begins automatically after you define a storage pool
for deduplication. (If you specify a duplicate-identification process when you update a storage
pool, it also starts automatically.) Because duplication identification requires extra disk I/O
and CPU resources, System Storage Archive Manager lets you control when identification
begins as well as the number and duration of processes.

You can deduplicate any type of data except encrypted data. System Storage Archive
Manager can deduplicate whole files as well as files that are members of an aggregate. You
can deduplicate data that has already been stored. No additional archive or migration is
required.


5.3.11 Archive process of a System Storage Archive Manager Collection
The archive process of a System Storage Archive Manager Collection is shown in Figure 5-13
and applies to all external archive applications. It is not possible to give all details here, that is,
a real process consists of even more function calls. However, we describe the most important
calls in regard to archiving in Figure 5-13 and the text beyond, from which a basic
understanding of necessary configuration can be derived.

dsmBeginTxn Transaction dsmEndTxn dsmBeginTxn dsmEndTxn
dsmSendObj dsmBindMC dsmEndSendObj dsmRetentionEvent
dsmSendData Implicit bound to Implicitly set to Subsequent send
Y preconfigured Bind-MC WORM event or hold/release
Store Bind-MC? Assign Bind-MC Commit Send Event

N Assign Default-MC
Implicit bound to preconfigured Default-MC

Figure 5-13 Archive process of System Storage Archive Manager Collection

The dsmBeginTxn function call begins one or more System Storage Manager transactions
that begin a complete action; either all the actions succeed or none succeed. An action can
be either a single call or a series of calls. For example, a dsmSendObj call that is followed by a
number of dsmSendData calls can be considered a single action.

The dsmEndTxn function call ends a System Storage Archive Manager transaction. The
dsmEndTxn function call is paired with dsmBeginTxn to identify the call or set of calls that are
considered a transaction. The external archive application can specify on the dsmEndTxn call
whether or not the transaction must be committed or ended.

When objects are stored by the external archive application, the IBM Tivoli Storage Manager
API function dsmSendObj is used. The function call starts a request to send a single object to
storage. Multiple dsmSendObj calls and associated dsmSendData calls can be made within
the bounds of a transaction for performance reasons. The dsmSendObj call processes the
data for the object as a byte stream passed in memory buffers. Alternatively, the application
client can specify only the attributes through the dsmSendObj call and specify the object data
through one or more calls to dsmSendData.

The dsmSendData function call sends a byte stream of data to the System Storage Archive
Manager through a buffer. The external archiving application can pass any type of data for
storage on the server. Usually, these data are file data, but are not limited to such. The
archiving application can call dsmSendData several times, if the byte stream of data that you
want to send is large.

For certain object types, byte stream data might not be associated with the data; for example,
a directory entry with no extended attributes. Before dsmSendObj is called, a preceding
dsmBindMC call must be made to properly bind a management class to the object that you
want to archive. The API keeps this binding so that it can associate the proper management
class with the object when it is sent to the server. The dsmBindMC function call associates, or
binds, a management class to the passed object. If the application does not bind the object to
a specific management class, the default management class of the policy domain and the
policy set, respectively, is used.


The dsmEndTxn call closes the transaction and all transmitted objects are committed. From
that point of time they cannot be deleted or modified unless they are eligible. Depending on
the retention policy, that is if chronological retention or event-based retention is configured,
there are two additional calls possible. In case of the event-based retention the external
archive application can send an event through the dsmRetentionEvent call. The
dsmRetentionEvent function call sends a list of object IDs to the server, with a retention event
operation to be performed on these objects. The function call is used within dsmBeginTxn and
dsmEndTxn calls and therefore it is another transaction taking place.

Only an owner of an object can send an event on that object. The following events are
possible:
eventRetentionActivate
This event can be issued only for objects that are bound to an event based management
class. Sending this event activates the event for this object, and the state of the retention
for this object changes from DSM_ARCH_RETINIT_PENDING to
DSM_ARCH_RETINIT_STARTED.
eventHoldObj
This event issues a retention or deletion hold on the object so that, until a release is
issued, the object is not expired and cannot be deleted.
eventReleaseObj
This event can only be issued for an object that has a value of DSM_ARCH_HELD_TRUE
in the objectHeld field and removes the hold on the object resuming the original retention
policy.

Tip: More information about the IBM Tivoli Storage Manager API can be found in the IBM
publication, Using the Application Programming Interface, SC23-9793-00, available at the
following Web site:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.client.develop.doc/b
_api_using.pdf

5.4 Creating and maintaining a System Storage Archive
Manager Collection
In the following section we show how to create a System Storage Archive Manager
Collection. When finished with the creation, we take a look at the configuration that has be
done automatically by the Create Collection Wizard. Because the wizard is running several
commands in the background, you will not see them during the configuration and our tables
show the appropriate results.

If changes are necessary, we explain how you can administrate the System Storage Archive
Manager Collection and the appropriate parameters and settings. Changes might be
necessary within the initial set up procedure, or somewhere in the entire lifecycle of the
system. At the end of this section, we describe the registration of a System Storage Archive
Manager client and give you all the steps necessary to use the System Storage Archive
Manager Collection.


5.4.1 Creating a System Storage Archive Manager Collection
You must log on to the Information Archive GUI with a user account with the administrative
role, IA Archive Administrator to use the Create Collection Wizard to specify the settings of
the System Storage Archive Manager collection.

Important: If you plan to migrate data from an IBM System Storage DR550, a System
Storage Archive Manager Collection must be created during the migration procedure.
Do not create this collection ahead of time, unless directed to do so by an IBM service
representative.

Log on to the Information Archive GUI, that is, the Integrated Solutions Console (Figure 5-14),
and complete the following steps:
1. In the navigation tree, expand Information Archive Management.
2. Click Collections.

Figure 5-14 Information Archive Management - Collections

3. On the main entry panel, click Create Collection.
Depending on the already created collections in your system, the panel also shows some
other information. At the end of this Create Collection Wizard session, the newly created
collection must be displayed here.
If there is no disk subsystem available, the creation of a new collection is not possible.
The wizard reports an error and rejects the creation (Figure 5-15).


Figure 5-15 Collection Overview - No available disk subsystem

4. On the Welcome page, which is displayed if the creation of a new collection is possible,
read the additional information about collections. Use the Online Help if you need further
assistance. Click Next to proceed.
5. On the General page (Figure 5-16), select Create a System Storage Archive Manager
collection and provide a collection name. Collection names can contain a maximum of 30
characters (only characters 'A-Z', 'a-z', '0-9' and '-' are allowed), and each collection must
have a unique name. You can also fill in a description for the collection. It is optional, but
good practice to complete the description field.

Figure 5-16 Create A System Storage Archive Manager collection - General

In our example, we use the collection name SSAM1, because this is our first System
Storage Archive Manager Collection. We also fill the description field with a rough
description. Provide any meaningful description, particularly if the collection name itself
does not suggest the concrete usage or that this is a System Storage Archive Manager
Collection.
6. On the Disk Storage Subsystem page (Figure 5-17), select the disk system on which the
System Storage Archive Manager Collection is planned to run.


Figure 5-17 Create A System Storage Archive Manager Collection - Select Disk Storage Subsystem

In our example, we select iastorage1, which is one of two available disk storage
subsystems in our environment. The wizard shows all predefined and available disk
subsystems that can be used to create new collections. The wizard will not show any
unavailable disk storage systems. For example, if there is only one disk storage
subsystem available, the wizard will not ask for this input anyway.
Furthermore, keep in mind that there is a difference in the capacities of the two systems in
our example. We have to choose the one that is planned for our System Storage Archive
Manager Collection. The second disk storage subsystem here, that is, iastorage2, can be
used to create another System Storage Archive Manager Collection or another document
collection like a File Archive Collection.
7. On the Summary page (Figure 5-18), read through the given information and write down
the main values, such as the name and the TCP/IP address of the collection.

Figure 5-18 Create A System Storage Archive Manager Collection - Summary


Consider the facts that the collection can never be deleted after its creation and that
Enhanced Tamper Protection is not enabled automatically. The latter is helpful in an initial
set up, because without Enhanced Tamper Protection, you can analyze and reconfigure
more items in the system.

Important: For a production environment, and this is even more true for a compliance
environment, it is definitely best to turn Enhanced Tamper Protection on.

If everything seems in order, click Next to proceed.
8. Observe the progress on the panel (Figure 5-19) as the Create Collection Wizard starts
creating the System Storage Archive Manager Collection.

Figure 5-19 Create A System Storage Archive Manager Collection - Creating Collection

Wait until 100% is reached and the Create Collection Wizard signals the end of the
process. If any errors occur, the wizard shows that too. Only proceed to the next step,
when no errors were reported in the creation process.
Also, on this page you already see the hint, that you need to configure the actual retention
policies and other document settings in the IBM Tivoli Storage Manager Administration
Center. We show those tasks and the related procedures later in this chapter.
9. Click Finish.
After you click Finish, the Create Collection Wizard ends and overview statistics are
collected from the system. As long as the statistics are being collected, you see warning
messages for the collection (Figure 5-20).

Figure 5-20 Collection Overview - Compiling overview statistics


Finally, the messages disappear and the statistics overview is displayed (Figure 5-21).

Figure 5-21 Collection Overview - Overview statistics

That brings you to a collection overview, where you can create another collection or where
you can set the properties of already created collections. We will use that later to do the
further configuration and we set up archive policies and register a client node.

5.4.2 What is preconfigured with System Storage Archive Manager Collection
The predefined definitions of the System Storage Archive Manager environment are shown in
this section. The definitions are mainly the result of the Create Collection Wizard and one
script that is running during the wizard installation.

System Storage Archive Manager database, database logs, and backups
The DB2® database of the System Storage Archive Manager server is created by the Create
Collection Wizard. DB2 consists of database files and log files of various kinds as explained in
“IBM System Storage Archive Manager server” on page 120. Information Archive does not
utilize the archive failover log for DB2, because the GPFS file system for the archive log is
assumed to be large enough to hold all archived log files. The database is also backed up
regularly onto the disk storage subsystem. Depending on the size of the database, the
backup consists of several files for one backup (Figure 5-22).


DBDirectory ACTIVELOGDirectory
/tiam/SSAM1/tsm/db
/tiam/SSAM1/tsm/activelog S0000011.LOG

Database S0000012.LOG

MIRRORLOGDirectory
/tiam/SSAM1/tsm/mirrorlog S0000011.LOG

S0000012.LOG

DBBACKUPDirectory ARCHLOGDirectory
/tiam/SSAM1/tsm/fileclass/ /tiam/SSAM1/tsm/archlog S0000000.LOG

67894321.DBV S0000001.LOG

67894322.DBV ARCHFAILOVERLOGDirectory
n/a

Figure 5-22 Preconfigured System Storage Archive Manager database and database log files for first
System Storage Archive Manager Collection

The results in Figure 5-23 from System Storage Archive Manager queries (query db, query
dbspace) show the preconfigured System Storage Archive Manager database characteristics.

Database Name: TSMDB1
Total Size of File System (MB): 9,390,152
Space Used by Database(MB): 448
Free Space Available (MB): 9,304,063
Full Device Class Name: FILECLASS
Last Complete Backup Date/Time:
Location: /tiam/SSAM1/tsm/db
Total Size of File System (MB): 9,390,152.00
Space Used on File System (MB): 86,024.25
Free Space Available (MB): 9,304,063.75
Figure 5-23 Preconfigured System Storage Archive Manager database

The System Storage Archive Manager server can use all the space that is available to the
drives or file systems where the database directories are located. In Figure 5-23, the
database finds 8.95 GB (9,390,152 MB) on the disk storage subsystem named iastorage1,
that is where we created our System Storage Archive Manager Collection.


The disk storage subsystem iastorage1 delivers 9.85 TB overall (Figure 5-24). At this time
(with System Storage Archive Manager V6.1) the maximum supported size of the System
Storage Archive Manager database is 1 TB.

Figure 5-24 Disk Storage Controller capacity for System Storage Archive Manager Collection

The results in Figure 5-25 from a System Storage Archive Manager query (query log f=d)
show the preconfigured log files of the System Storage Archive Manager database log files.

tsm: SSAM1>q log f=d

Total Used Free Active Log Mirror Log Archive Failover Archive Log
Space(MB) Space(MB) Space(MB) Directory Directory Log Directory Directory
--------- --------- --------- ---------------- ---------------- ---------------- ----------------
40,960 4.21 40,795.78 /tiam/SSAM1/tsm- /tiam/SSAM1/tsm- /tiam/SSAM1/tsm-
/activelog /mirrorlog /archlog

Figure 5-25 Preconfigured System Storage Archive Manager database log files

These outputs depend on the physical configuration of Information Archive and the input
during the Create Collection Wizard process. For example, the location of the System
Storage Archive Manager database depends on the name chosen for the System Storage
Archive Manager Collection. If there are multiple System Storage Archive Manager
Collections, obviously there are unique collection names. Also, if you choose a storage
subsystem with another size, the information will differ from our example.

Default configuration script for System Storage Archive Manager
Collection setup
During the Information Archive GUI Create Collection Wizard, the wizard uses a script
template named tiam_tsm_setup.script to configure the System Storage Archive Manager
Collection (Figure 5-26). During the wizard processing, all necessary System Storage Archive
Manager commands, including retention policies, storage pools, and schedules are added to
the script, and this final script is used to create the System Storage Archive Manager
Collection.


set actlogretention 30

SET TAPEALERTMSG on

register license file=*.lic

define devclass fileclass devtype=file dir=./fileclass

delete stg backuppool
delete stg archivepool
delete stg spacemgpool

define stgpool filepool fileclass maxscr=100000000 dataformat=nonblock crcdata=yes
reclaim=10 reclaimprocess=2 collocate=no

upd MGmtclass STANDARD STANDARD standard SPACEMGTECHnique=SELective MIGREQUIRESBkup=No
MIGDESTination=filepool

upd copygroup standard standard standard type=backup destination=filepool
upd copygroup standard standard standard type=archive destination=filepool

validate policyset standard standard
activate policyset standard standard

register admin adminconsole DfUo79iL passexp=0
grant auth adminconsole class=sys

set servername SSAM1
set serverhla 172.31.4.3
set serverlla 1502

define domain ia_reserved DESC="Policy domain created by IBM Information Archive. Do not
modify or delete."
define policyset ia_reserved ia_reserved DESC="Policy set created by IBM Information
Archive. Do not modify or delete."
define mgmtclass ia_reserved ia_reserved ia_reserved MIGDESTination=filepool
DESC="Management class created by IBM Information Archive. Do not modify or delete."
define copygroup ia_reserved ia_reserved ia_reserved type=backup destination=filepool
define copygroup ia_reserved ia_reserved ia_reserved type=archive destination=filepool
retinit=event
assign defmgmtclass ia_reserved ia_reserved ia_reserved
validate policyset ia_reserved ia_reserved
activate policyset ia_reserved ia_reserved

register node ia_reserved SSAM1 domain=ia_reserved forcepwreset=yes maxnummp=999
VALIdateprotocol=all compression=client
remove admin ia_reserved

set archiveretentionprotection on
SET DBRECOVERY fileclass

define schedule daily_maint type=administrative cmd="run daily_maint" active=yes
description="IA daily maintenance" starttime=06:00 period=1
define script daily_maint file=/opt/tivoli/tiam/bin/ia_tsm_daily_maint.script
description="IA daily maintenance including DB backup"

Figure 5-26 Configuration script for System Storage Archive Manager Collection setup
(/tiam/SSAM1/tsm/tiam_tsm_setup.script)


Another script named ia_tsm_daily_maint.script is invoked during the initial configuration of
the System Storage Archive Manager Collection environment (Figure 5-27).

backup db type=full devclass=fileclass wait=yes
delete volhistory todate=today-3 type=dbb
delete volhistory todate=today-30 type=stgnew
delete volhistory todate=today-30 type=stgreuse
delete volhistory todate=today-30 type=stgdelete
backup volhistory
backup devconfig
Figure 5-27 /opt/tivoli/tiam/bin/ia_tsm_daily_maint.script

The created collection is ready to use by archive applications, after each archive application is
registered as a client node in the policy domain. If the predefined settings for the default
policy domain are inline with your requirements, you can start using Information Archive
immediately after registering a client node. Otherwise, there are two other options to proceed:
Update or enhance the predefined configuration with appropriate System Storage Archive
Manager commands.
Create a new policy domain with all necessary follow-on configurations.

Predefined device classes
Figure 5-28 shows predefined device classes on the System Storage Archive Manager
server, which can be analyzed with the System Storage Archive Manager command query
devclass:
Device class DISK:
This device class represents random access media and must not be used in Information
Archive unless data shredding is needed. All other storage pools must be created with the
FILE device type.
Device class FILECLASS, device type FILE:
FILECLASS uses the device type FILE. It is a sequential access device class that has
been predefined and is used for full database backups that run daily as specified in an
administrative schedule on the System Storage Archive Manager Server. The sequential
access files (volumes) created by this process are located in the
/tiam/<SSAM_collection_name>/tsm/fileclass/ file system.

tsm: SSAM1>q devclass

Device Device Storage Device Format Est/Max Mount
Class Access Pool Type Capacity Limit
Name Strategy Count (MB)
--------- ---------- ------- --------- ------ -------- ------
DISK Random 0
FILECLASS Sequential 1 FILE DRIVE 2,048.0 20

Figure 5-28 Predefined SSAM device classes

Predefined primary storage pools and storage pool volumes
There is one primary disk pool named FILEPOOL and no preconfigured storage pool
volumes. Because the FILEPOOL uses the device class type FILE with the device class
FILECLASS, the volumes are created during write processes (archiving). Each volume is
preconfigured in the device class to be 2.0 GB of size maximum (Est/Max Capacity).


When the volume is written the first time, space in the maximum capacity is allocated on the
disk storage subsystem. The volumes then fill up until they reach their maximum capacity.

To check the storage pool, issue the commands query stg and query vol in the System
Storage Archive Manager.

To make this process more transparent, we show typical output from the query volume
command (Example 5-2) after objects are archived to the collection.

Example 5-2 Output of query vol (excerpt)
Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
------------------------ ----------- ---------- --------- ----- --------
/tiam/SSAM1/tsm/filecla- FILEPOOL FILECLASS 2.0 G 100.0 Full
ss/0000000A.BFS
/tiam/SSAM1/tsm/filecla- FILEPOOL FILECLASS 2.0 G 100.0 Full
ss/0000000B.BFS
/tiam/SSAM1/tsm/filecla- FILEPOOL FILECLASS 2.0 G 100.0 Filling
ss/0000000C.BFS

Predefined administrative schedules and their results
There is one predefined administrative schedule DAILY_MAINT that is executed daily at
6:00:00 o'clock on the System Storage Archive Manager server. You can check the schedule
with the System Storage Archive Manager command query schedule type=admin f=d.

The schedule DAILY_MAINT is running a script instead of a single command. Hence, the
commands will be executed in a sequential order and they provide a full maintenance cycle to
the System Storage Archive Manager environment. The script is shown in Figure 5-29.

Name: DAILY_MAINT
Line Number: 1
Command: backup db type=full devclass=fileclass wait=yes
Line Number: 6
Command: delete volhistory todate=today-3 type=dbb
Line Number: 11
Command: delete volhistory todate=today-30 type=stgnew
Line Number: 16
Command: delete volhistory todate=today-30 type=stgreuse
Line Number: 21
Command: delete volhistory todate=today-30 type=stgdelete
Line Number: 26
Command: backup volhistory
Line Number: 31
Command: backup devconfig

Figure 5-29 Administrative script DAILY_MAINT (excerpt)

The first command (Line Number: 1) produces a full database backup of the System Storage
Archive Manager database using the device class FILECLASS. The resulting backup
volumes are created in the /tiam/<SSAM_collection_name>/tsm/fileclass/ directory.

Example 5-3 shows the output of a query volhist t=dbb command. Use this command to
verify how many and what backup volumes are created by this or other database backup
commands.


Example 5-3 Output of query volhist t=dbb (excerpt)
Date/Time: 03/01/2010 06:00:12
Volume Type: BACKUPFULL
Backup Series: 72
Backup Operation: 0
Volume Seq: 1
Device Class: FILECLASS
Volume Name: /tiam/SSAM1/tsm/fileclass/67423215.DBV
Volume Location:
Command:
Database Backup ID High: 0
Database Backup ID LOW: 30,741
Database Backup Home Position: 0
Database Backup HLA: /NODE0000/
Database Backup LLA: FULL_BACKUP.20100301060012.1
Database Backup Total Data Bytes (MB) : 25.12
Database Backup total Log Bytes (MB) : 21.79
Database Backup Block Num High: -1
Database Backup Block Num Low: -1

Date/Time: 03/01/2010 06:00:12
Backup Series: 72
Backup Operation: 0
Volume Seq: 2
Volume Name: /tiam/SSAM1/tsm/fileclass/67423281.DBV
Volume Location:
Command:

In Example 5-3 you can see one full System Storage Archive Manager database backup that
consists of two backup volumes. The device class FILECLASS creates volumes with a size of
2 GB each. The full database backup command creates as many volumes as needed by the
full backup. In our example, we need two volumes to store an entire full backup.

The next four commands in the script DAILY_MAINT (Line Number: 6, 11, 16, 21) clean the
volume history file. The volume history file stores information about all volumes that System
Storage Archive Manager uses, that is database backups (dbb) and storage pool volumes
(stg). The volume history keeps three versions of database backups and it tracks all storage
pool volume actions such as the creation, reuse, and deletion of volumes over the last 30
days (Example 5-4). Depending on the retention policy, there are new storage volumes
created over the time, but also expired volumes are deleted. You will need that information
when you plan restores of your data.


Tip: The predefined schedule deletes old System Storage Archive Manager database
backups and keeps three versions of database backups on hard disk. If this does not fit
your requirements, reconfigure the schedule and the maintenance scripts, respectively.

Example 5-4 Output of query volhist (excerpt)
Date/Time: 02/01/2010 17:50:07
Volume Type: STGNEW
Backup Series:
Backup Operation:
Volume Seq:
Volume Name: /tiam/SSAM1/tsm/fileclass/0000011F.BFS

The script DAILY_MAINT (Line Number: 26) dumps the volume history file as a backup copy
to a specified directory.

The System Storage Archive Manager command is backup volhistory and the backup is
written to the /tiam/<SSAM_collection_name>/tsm/volumehistory file.

With the last command in the DAILY_MAINT script (Line Number: 31), the device
configuration is dumped out of the database into a plain file. The System Storage Archive
Manager command is backup devconfig and the backup is written to the
/tiam/<SSAM_collection_name>/tsm/devconfig file.

Tip: The preconfigured administrative schedule and the administrative script provide
appropriate protection for the System Storage Archive Manager Collection. However, they
can be customized to better fit your requirements. For example, if the full database backup
at 6:00 interferes with a heavy archiving workload, the start time can be modified to
another time that fits better into the workload profile. Note that you can also use additional
commands within the script to generate more workload. The specific numbering of the
used lines even leaves space for inserting commands between already delivered ones.

When a specific schedule runs, the scheduled action is represented by an event. Hence,
every schedule, every day, produces its own event. You can check out those administrative
events with the System Storage Archive Manager command q event t=a * to see the most
currents events, or q event t=a begind=+1 to see forthcoming events. The latter command is
useful, if you create new schedules and you want to check when they are running next time.

In Example 5-5 we show the specific event that is result of the predefined administrative
schedule DAILY_MAINT. You can see the planned start time compared to the actual start and
the status.

Example 5-5 Output of query event * t=a
tsm: SSAM1>q event * t=a

Scheduled Start Actual Start Schedule Name Status
-------------------- -------------------- ------------- ---------
03/01/2010 06:00:00 03/01/2010 06:00:12 DAILY_MAINT Completed


Installed default policy settings
The Create Collection Wizard configures policy domains and subsequent configurations such
as policy sets, management classes, and archive copy groups in the System Storage Archive
Manager server.

Installed default policy domains
Two policy domains are preconfigured: STANDARD and IA_RESERVED.
STANDARD:
The policy domain STANDARD is predefined on the Information Archive System Storage
Archive Manager server. This is the default policy for archiving through the IBM Tivoli
Storage Manager API (respectively archiving applications) or the IBM Tivoli Storage
Manager backup-archive client. You can either edit this policy domain to suit your data
retention requirements, or you can create new policy domains using your own naming
conventions. Figure 5-30 shows the default settings in the policy domain STANDARD.

tsm: SSAM1>q dom STANDARD f=d

Policy Domain Name: STANDARD
Activated Policy Set: STANDARD
Activation Date/Time: 03/04/2010 12:30:14
Days Since Activation: <1
Activated Default Mgmt Class: STANDARD
Number of Registered Nodes: 0
Description: Installed default policy domain.
Backup Retention (Grace Period): 30
Archive Retention (Grace Period): 365
Last Update by (administrator): SERVER_CONSOLE
Last Update Date/Time: 03/04/2010 12:30:14
Managing profile:
Changes Pending: No
Active Data Pool List:
Figure 5-30 Default settings in the policy domain STANDARD


IA_RESERVED:
The policy domain IA_RESERVED is predefined on the Information Archive System
Storage Archive Manager server for internal processing. Figure 5-31 shows the default
settings for the policy domain IA_RESERVED.

tsm: SSAM1>q dom IA_RESERVED f=d

Policy Domain Name: IA_RESERVED
Activated Policy Set: IA_RESERVED
Days Since Activation: <1
Activated Default Mgmt Class: IA_RESERVED
Description: Policy domain created by IBM Information
Archive. Do not modify or delete.
Managing profile:
Changes Pending: No
Figure 5-31 Default settings in the policy domain IA_RESERVED

Important: The policy domain IA_RESERVED is not intended to be used. This policy
domain is for internal archive processing only, that is to secure the Information Archive
System Storage Archive Manager server by storing archive objects into this domain. Only
use the policy domain STANDARD or create your own policy domain for your archive data.

Installed default policy sets
There are two default policy sets predefined, one for each domain: STANDARD and
IA_RESERVED.

Figure 5-32 shows the active policy set in the STANDARD domain.

tsm: SSAM1>q policyset standard active f=d

Policy Set Name: ACTIVE
Default Mgmt Class Name: STANDARD
Description: Installed default policy set.
Managing profile:
Changes Pending: No
Figure 5-32 Default settings for the active policy set STANDARD


Figure 5-33 shows the active policy set in the IA_RESERVED domain.

tsm: SSAM1>q policyset ia_reserved active f=d

Policy Domain Name: IA_RESERVED
Default Mgmt Class Name: IA_RESERVED
Description: Policy set created by IBM Information Archive.
Do not modify or delete.
Managing profile:
Changes Pending: No
Figure 5-33 Default settings for the active policy set IA_RESERVED

Preconfigured management classes and default management classes
The management classes STANDARD and IA_RESERVED are predefined as management
classes in the two policy domains. Because they are the only management classes in the
appropriate policy domain, they are also the default management classes for their policy
domains (Figure 5-34).
.

tsm: SSAM1>q mgmt

Policy Policy Mgmt Default Description
Domain Set Name Class Mgmt
Name Name Class ?
--------- --------- --------- --------- ------------------------
IA_RESER- ACTIVE IA_RESER- Yes Management class created
VED VED by IBM Information
Archive. Do not modify
or delete.
IA_RESER- IA_RESER- IA_RESER- Yes Management class created
VED VED VED by IBM Information
Archive. Do not modify
or delete.
STANDARD ACTIVE STANDARD Yes Installed default
management class.
STANDARD STANDARD STANDARD Yes Installed default
management class.

Figure 5-34 Default management classes

Defining additional management classes pointing to appropriate archive copy groups with
unique retention rules is the preferred way to separate objects with various retention
requirements within the System Storage Archive Manager server. The management class is
the distinguishing attribute used by a document management application to feed objects into
the System Storage Archive Manager server. If the document management system does not
specify a management class at the delivery of an object to the System Storage Archive
Manager server, the default management class STANDARD and IA_RESERVED will be used
to store the object.

Tip: Use a new management class for your own purposes instead of updating one of the
predefined management classes. As best practice, configure an entirely new policy domain
as shown later in this chapter.


Preconfigured archive copy groups
There are two archive copy groups predefined, one for each predefined management class.
The default archive copy groups are shown in Figure 5-35. If additional archive copy groups
are created, they will always be named STANDARD. Because they are always tied to a
specific management class, this is the criteria to differentiate them.

tsm: SSAM1>query copygroup * active type=archive

Policy Policy Mgmt Copy Retain
Domain Set Name Class Group Version
Name Name Name
--------- --------- --------- --------- --------
IA_RESER- ACTIVE IA_RESER- STANDARD 365
VED VED
STANDARD ACTIVE STANDARD STANDARD 365

Figure 5-35 Settings for default archive copy group STANDARD

Default copy group for policy domain STANDARD:
In the default archive copy group for the management class STANDARD, the retention
initiation (RETINIT) is set to CREATION, therefore the retain minimum (RETMIN)
parameter is not set, and the retain version (RETVER) parameter is set to 365 days. The
archive destination is set to FILEPOOL, so that all files in this archive copy group are
stored in that storage pool.
Files archived using this copy group are held for 365 days. At the end of the retention time
the files are eligible for expiration.

Deletion: A deletion hold can still be applied during the 365 day period, which prevents
that object from being deleted from storage until a deletion release is applied for that
same object. If the release is sent within the 365 days period, the file is kept.

If you want to change the parameters for the default copy group, you can use the update
copygroup command. Take care to update a copy group that uses chronological retention
and that you can only increase the retention time but never decrease it. Instead of
updating the existing archive copy group, create a new management class and a new
archive copy group.
Default copy group for policy domain IA_RESERVED:
In the default archive copy group for the management class IA_RESERVED, the retention
initiation (RETINIT) is set to EVENT, the retain minimum (RETMIN) parameter is set to
365 days, and the retain version (RETVER) parameter is also set to 365 days. The archive
destination is set to FILEPOOL, so that all files in this archive copy group are stored in that
storage pool.
Files archived using this copy group are never expired until an event is sent to the
Information Archive System Storage Archive Manager environment. When the event is
sent, then the objects are held for 365 days minimum before they are eligible for deletion.


You can see all archived objects within the archive copy groups with an SQL select statement
in the System Storage Archive Manager Collection (Figure 5-36).

tsm: SSAM1>select * from archives where node_name='IA_RESERVED'

NODE_NAME: IA_RESERVED
FILESPACE_NAME: /tiam/SSAM1
FILESPACE_ID: 1
TYPE: DIR
HL_NAME: /
LL_NAME: utility
OBJECT_ID: 1025
ARCHIVE_DATE: 2010-03-04 12:30:59.000000
OWNER: root
DESCRIPTION: Archive Date: 03/04/10
CLASS_NAME: IA_RESERVED

FILESPACE_NAME: /tiam/SSAM1
FILESPACE_ID: 1
TYPE: DIR
HL_NAME: /utility/
LL_NAME: config
OBJECT_ID: 1026
ARCHIVE_DATE: 2010-03-04 12:30:59.000000
OWNER: root
CLASS_NAME: IA_RESERVED
Figure 5-36 System Storage Archive Manager archive objects from initial setup

Attention: The policy domain IA_RESERVED is not intended to be used by a customer.
This policy domain is for internal archive processing only, that is, to secure the System
Storage Archive Manager server by storing archive objects into this domain.

Preconfigured client nodes
There is only one client node preconfigured (see Figure 5-37). The node IA_RESERVED is
for the purpose of generating the data, as previously mentioned, to protect the System
Storage Archive Manager server (set archiveretentionprotection on) from being disabled for
retention protection. This registered node is not intended to be used by the customer.

tsm: SSAM1>q node

Node Name Platform Policy Domain Days Since Days Since Locked?
Name Last Acce- Password
ss Set
------------------------- -------- -------------- ---------- ---------- -------
IA_RESERVED Linux86 IA_RESERVED <1 <1 No

Figure 5-37 Preconfigured System Storage Archive Manager client nodes

Preconfigured file expiration
File expiration is automatically processed every 24 hours by default. You can see that with the
System Storage Archive Manager command query option expinterval.


The 24 hour interval starts with the start of the System Storage Archive Manager server, so
depending on particular start times, the actual start time in your environment can vary.

Automatic expiration can be reconfigured, whenever you need more static starting times or if
you recognize impact on your running environment that is caused by the expiration process.
For example, if you have billions of files and the expiration process takes very long, you might
want to run the process in small portions or in other more detailed configurations.

Tip: See the IBM Tivoli Storage Manager documentation to reconfigure the expiration
process, if applicable. Keep in mind that the expiration process is directly related to the
overall retention of your data.

5.4.3 System Storage Archive Manager collection administration
System Storage Archive Manager offers various functions and commands that allow you to
manage the System Storage Archive Manager collection environment and settings:
Managing System Storage Archive Manager storage
Managing retention policies:
– Creating a policy domain
– Creating a policy set
– Creating a management class
– Creating an archive copy group
– Setting document retention
– Register node in the policy domain
Managing data shredding
Media lifecycle management to move data
Cyclic redundancy checking

With Information Archive, the tasks to configure or use those options can be done using the
IBM Tivoli Storage Manager Administration Center and the wizards within this center, or it can
be done using the IBM Tivoli Storage Manager administrative command-line client (dsmadmc).

Because the wizards do not offer all System Storage Archive Manager and IBM Tivoli Storage
Manager commands, we prefer to use the dsmadmc command for configuration. The examples
in the following sections are all created with the administrative command-line client.

Managing System Storage Archive Manager storage
If the preconfigured System Storage Archive Manager storage, that is, the FILEPOOL, is
sufficient for your requirements, you do not need to manage System Storage Archive
Manager storage. We assume that this is true for the most common user scenarios.

In case you have to fulfill further requirements such as data shredding, you have to create a
new System Storage Archive Manager primary disk storage pool. If the pool uses random
access devices, you must also configure its volumes. Follow these steps:
1. Create primary disk storage pool assigned to sequential access device:
define stgpool <pool_name> FILECLASS maxscr=100000000 dataformat=nonblock
crcdata=yes reclaim=10 reclaimprocess=2 collocate=no
Create primary disk storage pool assigned to random access devices (optional):
define stgpool <pool_name> DISK description=‘Primary Disk Pool’ crcdata=yes


2. Create volumes within primary disk storage pool (random access devices only):
define volume <pool_name> <volume_name> formatsize=<megabytes>
The <volume_name> for a System Storage Archive Manager collection must always
include the full path and volume name like
/tiam/SSAM1/tsm/fileclass/<concrete_volume_name> for the first System Storage Archive
Manager collection.

Managing retention policies
Managing retention policies includes the creation of policy domains, policy sets, management
classes, and archive copy groups as well as the update of existing configurations. Here we list
the commands used to define, assign, validate, and activate the policy that fulfills the
requirements:
1. Create policy domain:
define domain <domain_name> description=‘Policy Domain’ archretention=<days>
2. Create policy set:
define policyset <domain_name> <policy_set_name> description=‘Policy Set’
3. Create management class:
define mgmtclass <domain_name> <policy_name> <mgmtclass_name>
description=‘Management Class’
4. Choose one of the following two options to create an archive copy group:
Create archive copy group for chronological (time-based) archiving:
define copygroup <domain_name> <policy_name> <mgmtclass_name> type=archive
destination=<stgpool_name> retinit=creation retver=<days>
Create archive copy group for event-based archiving:
destination=<stgpool_name> retinit=event retver=<days> retmin=<days>
5. Assign default management class:
assign defmgmt <domain_name> <policy_name> <mgmtclass_name>
6. Validate policy set:
validate <domain_name> <policy_name>
Ignore warnings about the missing backup copygroup.
7. Activate policy set:
activate policyset <domain_name> <policy_name>
8. Register node in policy domain:
register node <node_name> <password> domain=<domain_name>

Managing data shredding
By default, the Information Archive appliance is not configured to use data shredding. You can
validate this fact with the System Storage Archive Manager command query stg f=d
(Example 5-6), because for data shredding you need an eligible storage pool. Only random
access storage pools can be utilized for data shredding, and they must show how many times
the shredding procedure has to be executed on the physical volume.


Example 5-6 Storage pool report for FILEPOOL, Overwrite parameter (excerpt)
tsm: SSAM1>q stg f=d

Storage Pool Name: FILEPOOL
Storage Pool Type: Primary
Device Class Name: FILECLASS
Access: Read/Write
Maximum Scratch Volumes Allowed: 100,000,000
Number of Scratch Volumes Used: 0
Delay Period for Volume Reuse: 0 Day(s)
Storage Pool Data Format: Native without Block Headers
Copy Storage Pool(s):
Overwrite Data when Deleted:

Perform the following steps to set up your shredding configuration in the Information Archive
appliance:
1. Specify that you want data to be shredded either automatically after it is deleted or
manually by an administrator. You can specify how shredding is to be done by setting the
SHREDDING server option. You can also set the shredding option dynamically by using the
setopt command. We advise to run with the manual shredding, therefore use the following
command:
setopt shredding manual
2. Set up one or more random access disk storage pool hierarchies that will enforce
shredding and specify how many times the data is to be overwritten after deletion. For
example, define a storage pool with a shredding of 5 times with the following command:
define stgpool <pool_name> disk shred=5 crcdata=yes
3. Define volumes to the pool, and specify disks for which write caching can be disabled. For
example, if your System Storage Archive Manager Collection is named SSAM1, then type
the following command:
define volume <pool_name> /tiam/SSAM1/tsm/fileclass/vol01.dsm formatsize=2048
4. Create policy domain:
define domain <domain_name> description=‘Policy Domain’ archretention=<days>
5. Create policy set:
define policyset <domain_name> <policy_set_name> description=‘Policy Set’
6. Create management class:
define mgmtclass <domain_name> <policy_name> <mgmtclass_name>
description=‘Management Class’
7. Choose one of the following two options to create an archive copy group:
Create archive copy group for chronological (time-based) archiving:
destination=<stgpool_name> retinit=creation retver=<days>
Create archive copy group for event-based archiving:
destination=<stgpool_name> retinit=event retver=<days> retmin=<days>
8. Assign default management class:
assign defmgmt <domain_name> <policy_name> <mgmtclass_name>


9. Validate policy set:
validate <domain_name> <policy_name>
10.Activate policy set:
activate policyset <domain_name> <policy_name>
11.Register node in policy domain:
register node <node_name> <password> domain=<domain_name>
12.Start the shredding process manually with the command:
shred data

Cyclic redundancy checking
Data validation for storage pools allows the server to validate that data sent to a device during
a write operation matches what the server later reads.

When data validation is enabled for storage pools, the server generates a cyclic redundancy
check (CRC) value and stores it with the data when it is written to the storage pool. Data
validation is enabled on the predefined primary disk storage pool FILEPOOL with the initial
setup by the Create Collection Wizard. You can validate this with the System Storage Archive
Manager command query stg f=d, where the CRC Data parameter shows Yes (Example 5-7).

Example 5-7 Storage pool report for FILEPOOL, CRC Data (excerpt)
tsm: SSAM1>q stg f=d

Storage Pool Name: FILEPOOL
Storage Pool Type: Primary
Device Class Name: FILECLASS
Access: Read/Write
Maximum Scratch Volumes Allowed: 100,000,000
Number of Scratch Volumes Used: 0
Delay Period for Volume Reuse: 0 Day(s)
Storage Pool Data Format: Native without Block Headers
Copy Storage Pool(s):
CRC Data: Yes

For new System Storage Archive Manager storage pools, you can use the define stgpool
or update stgpool commands to enable data validation for these storage pools.

Tip: Enable data validation for all System Storage Archive Manager storage pools in your
Information Archive appliance, independent from your actual plan to use it or not. The CRC
value calculation and the storing of these values does not impact the system, and you are
thus prepared for unplanned storage pool audits.

The server validates the data when it audits the volume, by generating a cyclic redundancy
check and comparing this value with the CRC value stored with the data. If the CRC values
do not match, then the server processes the volume in the same manner as a standard audit
volume operation.


Use the audit volume command to validate the data of a storage pool volume. The
command allows you to specify an audit for data written to volumes within a range of days, or
to run an audit for a given storage pool. The audit volume command marks a file as
damaged if a read error is detected for the file. If an undamaged copy is in an onsite copy
storage pool volume, it is used to provide client access to the file.

Reset the damaged status of files if the error that caused the change to damaged status was
temporary. You can use the audit volume command to correct situations when files are
marked damaged due to a temporary hardware problem, such as a dirty tape head. The
server resets the damaged status of files if the volume in which the files are stored is audited
and no read errors are detected. Furthermore, if a primary file copy is marked as damaged
and a usable copy exists in a copy storage pool or an active-data pool volume, the primary file
can be corrected using the restore volume command or restore stgpool command.

While fixing the problems or restoring data, the System Storage Archive Manager server will
not delete archive files that are on deletion hold, also it will not delete archive files whose
retention period has not expired. We assume, that you will involve IBM System Storage
Archive Manager experts in the process of restoring volumes and storage pools. Hence, we
do not elaborate the concrete procedures here.

Using the CRC option in conjunction with scheduling audit volume processing continually
ensures the integrity of data stored in your storage hierarchy.

Audit process: While an audit process is active, clients cannot retrieve data from the
specified volume or store new data to that volume.

5.4.4 Granting client nodes access to a System Storage Archive Manager
Collection
Before an archive application can use the System Storage Archive Manager Collection, you
have to grant the application access. Register the application as a client node so it can store
and retrieve files to the System Storage Archive Manager Collection. The role required for this
task is IA Archive Administrator.

Tip: Creating a client node using this procedure is equivalent to the register node
command in the IBM System Storage Archive Manager command line interface.

Log on to the IBM Tivoli Storage Manager Administrative interface and complete these steps:
1. Expand Tivoli Storage Manager in the navigation tree.
2. Click Client Nodes and Backup sets.
3. From the All Client Nodes tab, click Select Action  Create a Client Node.
4. Click Select a Server and select the collection you are granting access to.
5. Click Select an item and select the policy domain associated with the collection.

Important: In the next step, do not use the node named IA_RESERVED because that
node name was created to run internal archive operations.

6. Complete the remaining fields on the page to set the password that the client node uses to
authenticate with the archive.
7. After you complete these steps, click OK or Add Another in the properties notebook to
commit any changes.


To connect an archive application to the System Storage Archive Manager Collection, you
can get the connection information in the TSAM Administrative interface of the Information
Archive GUI, you need the administrative role of IA Archive Administrator for this procedure.

Log on to the IBM Tivoli Storage Manager Administrative interface and complete these steps:
3. Click Properties in the applicable System Storage Archive Manager Collection.
4. View the TCP/IP address and port number for the collection.

5.5 Supported archive applications for System Storage Archive
Manager Collections
External archive applications must be configured to use the System Storage Archive Manager
Collection as a storage device. For instance, you can use the IBM Tivoli Storage Manager
backup-archive client with its archive functions as an archive appliance. Furthermore, you can
use every archive appliance that leverages the IBM Tivoli Storage Manager API with the
special archive functions. For details about how major archive applications are integrated with
Information Archive, see Chapter 8, “Integrating IBM Information Archive with archiving
applications” on page 261.

Tip: For archive applications that are ready to use Information Archive, see the Tivoli Open
Process Automation Library (OPAL) web page (you can list them by Information Archive):
http://www-01.ibm.com/software/brandcatalog/portal/opal

At the time of writing, Information Archive is running System Storage Archive Manager V6.1
and therefore supports the use of IBM Tivoli Storage Manager API client and backup-archive
client versions 5.5 and 6.1. When the System Storage Archive Manager installation in
Information Archive changes to a newer version, you must check the supported IBM Tivoli
Storage Manager API and backup-archive client version again.

IBM Tivoli Storage Manager V6.2 is already announced. Electronic availability is 19 March
2010, and media is available 16 April 2010. If Information Archive changes to System Storage
Archive Manager server V6.2 or IBM Tivoli Storage Manager server V6.2, the server/client
compatibility says that V5.5, V6.1, and V6.2 clients (API and backup-archive) are still
supported with the V6.2 server.

5.6 Differences between System Storage Archive Manager
Collections and File Archive Collections
A System Storage Archive Manager Collection operates differently than a File Archive
Collection in the following ways:
Documents stored in a System Storage Archive Manager Collection cannot be deleted
before they expire, and retention periods cannot be reduced. It is not possible to configure
less restrictive document protection levels.
System Storage Archive Manager Collections cannot be deleted.
Each System Storage Archive Manager Collection is accessed through one TCP/IP
address.


6

Chapter 6. File Archive Collections
IBM Information Archive (Information Archive) uses collections to manage archived data.
Depending on the archiving application and the functions needed, there are various types of
document collections available.

In this chapter we provide information about File Archive Collections. Because this type of
collection is based on open industry standards such as the Network File System (NFS)
protocol and the Hypertext Transfer Protocol (HTTP), we briefly explain relevant details of
these protocols.

File Archive Collections are accessed through standard network protocols (more precisely,
the NFS v3 protocol) and export a namespace that can be mounted and accessed by an
authorized application to store and retrieve documents. With Information Archive, Hypertext
Transfer Protocol (HTTP) can also be used to access a File Archive Collection; However, with
HTTP, you can read archived files but not write into the collection.

We describe the initial set up, configuration, and administration of File Archive Collections.
At the end of this chapter we go through a scenario to archive documents in the File Archive
Collection and validate the success of the operation.


6.1 File Archive Collections overview
In Chapter 5, “System Storage Archive Manager Collections” on page 115 we describe the
usage of the proprietary IBM System Storage Archive Manager interface for the Information
Archive appliance. There are many benefits from using such a proprietary data interface for
archiving. However. a key challenge is the compatibility between the archiving application that
must support the proprietary data interface to use the Information Archive storage. From that
standpoint. open industry standards can facilitate the integration of archiving applications with
Information Archive. Even more, in certain environments open standards might be the only
supported way to connect systems.

Standardized file system interfaces are the most common, easy to use standards for
applications to archive and retrieve data from an archive storage system. With certain file
system enhancements that are transparent to applications, they can be utilized to facilitate
archiving functions requirements such as compliance, and provide support for embedded
metadata and life cycle management. Additional functions can be made available through
metadata files based on open Extensible Markup Language (XML) that are simple for
applications to support. All those concepts are part of the File Archive Collections design.

A File Archive Collection is a logical container for storing archived documents, as well as the
retention and access policies that specify how the documents are managed. Each File
Archive Collection is represented by a separate Storage Controller with a separate file system
and accessed through the open NFS v3 standard protocol.

Figure 6-1 presents a schematic overview of a File Archive Collection in Information Archive.
We explain the various components and their usage in the following topics.

Web-browser Web-browser NAS Client
Management Retrieve/Analyse Archive/Retrieve

NAS Interface
IA Management GUI

Clustered Filesystem & Middleware
Tape Device (optional)

Primary Disk Storage

Migration Mgr.

File Archive Collection
Secondary Disk Storage


© 2010 IBM Corporat
Figure 6-1 File Archive Collection overview


Information Archive supports three types of retention policies to provide more flexibility for
archiving applications:
Chronological retention (or time-based retention):
After a document is committed in the Information Archive repository, it is retained for the
duration specified by the retention period. At the end of the retention period, documents
are expired and can be deleted.
Event-based retention:
A document’s retention can be controlled using an event. The retention period starts after
the event has been signaled. The document is expired depending on when the event
occurs.
Legal document hold protection:
Retention holds prevent a document from being deleted even if the document’s retention
period ends. A document can only be deleted after the retention hold is released and its
retention period has expired. Retention holds can be placed on a document whether it is
assigned an event-based or chronological retention. Information Archive allows up to eight
concurrent hold events per document.

Depending on your archive application, you can choose between all three policies, or you are
forced to enable only one. The most common interface we see in the market is the
event-based retention policy.

6.2 Network File System (NFS)
Information Archive is based upon the IBM General Parallel File System (GPFS), as
described in previous chapters. GPFS file systems can be exported using the Network File
System (NFS) protocol from one or more Information Archive cluster nodes. After export,
normal access to the file system can proceed from GPFS cluster nodes or NFS client nodes.

Information Archive supports all client operating systems that use NFS version 3.

In Information Archive, the GPFS cluster nodes access the archived documents for
management purposes (such as hierarchical storage management or backup and restore).
NFS client nodes archive and retrieve documents with the File Archive Collections. You can
use the NFS protocol on client nodes with most UNIX-based operating systems, Linux, and
Apple Mac OS. NFS client software is also available for other operating systems, including
Microsoft Windows.

6.2.1 Archive process with File Archive Collections (NFS)
To access file collections in IA, you must use an authorized NFS client to mount the file
system (NFS share) for the collection. The File Archive Collection consists of two main
storage areas, the file directory, and the metafile directory (also called meta directory). The
archiving application writes documents in the file directory that is mounted by NFS. A metafile
is automatically created for each document and the metafile is stored in the metafile directory.

Metafiles contain document-related metadata, such as owner information and retention
periods. Because the archiving application needs to mount both directories before writing, the
mounted areas are also called shares. Hence, file directory and file share describe the same
concept in this context.

Chapter 6. File Archive Collections 169

Documents in the collection file system can be administrated or manipulated using the same
commands that are used with any other directory on an NFS client. After documents are
written to the collection file system, they must be committed to the archive to make them
immutable and apply retention policies. Documents that have been saved to Information
Archive but have not been committed are considered uncommitted. A document that has
been committed cannot become uncommitted.

Tip: A document that has been written to the mount point directory can still be deleted if it
has not been committed.

Document ingestion is the process of adding a document to a File Archive Collection after the
document is committed. Documents are automatically ingested after they are committed to
the collection file system. The retention policy that is applied to a document depends on the
service class that the document is associated with. The service class determines how long
documents remain in the archive. Retention policies can also be explicitly applied, using
POSIX commands or through a document's metafile. For each document a MD5 checksum is
calculated when it is ingested in Information Archive. Archiving applications can use this
checksum to validate the integrity of the document. MD5 checksum can be obtained using the
metafile interface.

Tip: After the document is committed, it can take up to 10 minutes before the file is
ingested. During this time, the document is protected from modification and deletion.

There are three ways to commit documents in the Information Archive appliance and to set
their retention period: metafile commit, explicit commit, and automatic commit.
Metafile commit:
When you mount a file directory and copy your data file to this directory, a metafile is
created automatically in the meta directory for each document. We explain metafiles in
detail in the section “Metafiles” on page 175. Now you can write an event commit tag in the
document XML metafile and the file is committed when the metafile is saved. Writing the
event commit tag makes the file eligible for ingestion during the next ingestion cycle. The
metafile commit can be done manually, or by an archiving application.
You can set the retention of a file by adding an event tag to its metafile (Figure 6-2).
Retention determines how long a file is to remain accessible before expiration.
Mount the meta directory of the applicable collection through the NFS interface and
complete the following steps:
a. Mount /meta/tiam/collection/meta where collection is the name of the collection, and
open the metafile with the same name as the target data file. You can open the metafile
with any XML-capable editor, application, or even a simple text editor.
b. Write the following tag in the metafile anywhere between the <fields> </fields> tags:
<_EVENT_setRetention_>duration</_EVENT_setRetention_> where duration is a
numeric value in seconds.
c. Write the following tag in the metafile anywhere between the <fields> </fields> tags:
<_EVENT_commit_/>. No parameter is required.
d. Save the metafile.
After saving, the metadata component immediately parses and validates the metafile,
completes the event, and removes the EVENT tag.


Figure 6-2 illustrates the metafile commit process.

<_EVENT_setRete ntion_>duration</_EVENT_setRetention_>
<_EVENT_commit_/>

copy data

File-share Meta-share

NAS

Disk

Information Archive

Figure 6-2 File Archive Collection - metafile commit

Explicit commit:
You can change the file permissions for a document to read-only by mounting the
collection file system and issuing Portable Operating System Interface for Computing
Environments (POSIX) commands (compatible with NetApp® SnapLock®). POSIX is a
standard that enables applications portability across UNIX-based operating systems. The
POSIX subsystem supports POSIX file structure, POSIX calls, and executables such as
copy, ls, touch, and chmod. Changing the file permissions can be done manually, or by an
archiving application.
In Figure 6-3 you can see an example of the entire process.

copy file
touch –a -t [[CC]YY]MMDDhhmm[.SS] file
chmod a–w file

Data-share

NAS

Disk


Information Archive

Figure 6-3 File Archive Collections - explicit commit


The archiving application (or the user) must set the last access time of the file to the
expiration time, for example, with the touch -a -t timestamp <file_name> command.
You must run this command before you commit the document.
Issuing the chmod a–w <file_name> command causes the document to be committed
and signals Information Archive to ingest the document during its next ingestion cycle. The
command chmod a-w <file_name> takes away the write permission of the file for all users.
If you copy a read-only file into the data-share, you must enable write-access before
issuing the touch command. To do this, enter chmod +w <file_name>.

Retention: If the write access permissions for the file have been removed before
setting the retention period, you cannot set the retention period using the touch
command, and the retention period is determined by the service classes.

Automatic commit:
You can configure the appliance to periodically commit all documents that have not been
committed (see Figure 6-4). When configuring automatic commit, you must specify an idle
time. All the uncommitted files that have been on the archive longer than the idle time are
then committed.
The idle time delays the document commit so that the entirety of the document data can
be saved to the archive before it is marked read-only. With that setting you guarantee the
data consistency of your file. You can specify a delay of up to 30 days. The countdown of
the idle time starts the moment the document is saved to the archive. The idle time period
is not reset if you modify the document before it is committed.

Archiving: Specify a time interval that allows your archiving applications to finish
writing documents to avoid archiving documents that have not been fully transmitted.
Depending on your retention policies, it might not be possible to delete partially-written
documents from archival storage until they expire.

copy file

Data-share

11
12
1 NAS
10 2

9 3

8 4
7
6
5 Disk


Information Archive

Figure 6-4 File Archive Collections - automatic commit


It is important to understand that after a document is committed, the document is ingested
and its retention period is determined by evaluating all of the retention periods that were set
prior to the ingest using explicit retention period methods. The retention period that is
assigned after ingestion depends on the following factors:
If the collection has the basic or intermediate level of document protection (“Collection
protection” on page 180), a document retention period is determined using the settings in
the policy-based retention. The retention period that is set by the explicit methods such as
the touch command and metafile are overwritten by the policy-based retention period.

Retention: After the document is ingested, you can extend the retention period using
either a policy-based or explicit method of retention.

If the collection has the maximum level of document protection, a document retention
period is determined by evaluating the policy-based and explicit retention methods and
selecting the longest retention period.
You can view the number of documents that are uncommitted in the Collections section of the
Information Archive GUI. The Collection Overview also shows the number of failed ingestions
and other useful statistics for the File Archive Collection (see Figure 6-5).

Figure 6-5 Collection Overview - Uncommitted and Expired Documents

At the end of the lifecycle, eligible documents marked as expired in the Collections Overview
(see Figure 6-5), can be deleted automatically by Information Archive or by the archiving
application. The automatic deletion for Information Archive is configured on a File Archive
Collection basis. Therefore all eligible documents belonging to the same collection will be
deleted according to the same policies. The policies are discussed in the section
“Policy-based document retention” on page 174, where service classes and document rules
are explained. The overall process of archiving with File Archive Collections is shown in
Figure 6-6.

Document action is Internal processing
preconfigured automatically binds
Set retention period policies after commit,
Copy file to IA plus Metafile commit or MD5 hashcode is Subsequent Snaplock or
file share N Explicit commit calculated after ingest
metafile event signal

Store Auto? Commit Ingest Change ret.

Y Automatic Commit
After idle time: bind to service class and its
retention period, commit automatically

Figure 6-6 Archiving process with File Archive Collection


6.2.2 Policy-based document retention
With policy-based retention, Information Archive evaluates document rules and service
classes to determine how long a document is protected in the archive.

When a document is ingested into a collection, its retention period is assigned based on a
combination of these components:
A service class determines the duration of the retention period for every document that is
assigned to it.
Document rules use a set of conditions to determine which service class a document is
assigned to. The order of these document rules is important and can be modified.

Service classes
The service class determines how long documents remain in the archive. Service classes can
be configured to retain a document for a set period or until a defined event occurs.
Time-based retention (or chronological retention):
Time-based retention retains a document until it is stored for a specified period. The
document retention starts when the document is ingested into the archive.
Event-based retention:
Event-based retention retains a document from the time it is ingested until an event is
signaled through the document metafile. Additional retention periods can be specified to
continue retaining the document after the event is signaled. For example, you can use
event-based retention to expire a set of financial documents after a mortgage is paid off.
The retention period of a document is based on the combination of an event-based
retention period and an optional minimum retention period. If you specify a value for both
of these retention periods, the following rules apply:
– If an event occurs before the minimum retention period has passed, the expiration date
that retains the document for the longest time is honored.
– If an event occurs after the minimum retention period has passed, the document
expires after the event retention period ends.

You can use a deletion hold (also called a retention hold or legal hold) to retain a file longer
than the minimum retention period that it was originally assigned. A deletion hold, for
example, can be used if a file needs to be saved for the duration of a legal or
company-required audit. A deletion hold can be applied to an archived file at any time during
its retention period. The file is retained until a deletion release is applied. If a deletion release
is not applied, the object is retained indefinitely. A deletion hold can be placed on a file with
either a chronological archive retention or an event-based retention policy.

You can hold a file by using an archiving client to issue a retention event with the Hold
parameter. When you no longer need to hold the document, use an archiving client to issue a
retention event with the Release parameter. A file in a deletion hold cannot be deleted until
you release it.


Document rules
A document rule is a list of one or more conditions that apply to an ingested document. If the
document matches the conditions in the document rule, the document is assigned to the
associated service class. The purpose of document rules, in combination with service
classes, is to provide a way to automatically set the retention periods for newly ingested
documents.

A rule condition is created by combining parameters, comparisons, and values to form an
expression that is documents are compare against. If, for example, you wanted a retention
policy for all files created by John Smith (user account jsmith), you can create a rule with the
condition User account is jsmith. Multiple conditions can be combined to further control a
document. If, for example, you wanted a special retention policy for all large documents
created by John Smith you can combine the condition User account is jsmith with the
condition File Size greater than 100000.

A document rule can be associated with only one service class. Similarly, each document can
only belong to one service class. If there are multiple document rules, they are organized in a
descending list that documents are evaluated against until one of the rules applies.

Important: Documents that do not match any of the defined rules are automatically
assigned to the default service class. The default service class IADefault is created during
initial setup of the File Archive Collection by the Create Collection Wizard.

6.2.3 Metafiles
A metafile is automatically created for each document stored in the archive. A metafile is an
XML file that contains a list of fields. Fields contain document-related metadata, such as
service class associations, retention periods, and user specific information. All the metafiles
for the documents in a collection are stored in the meta directory of the collection file system.
Each metafile has the same name and extension as the document with which it is associated.

A metafile contains no fields until after a document is committed (Example 6-1).

Example 6-1 Empty metafile
<?xml version="1.0" encoding="UTF-8" ?>

<fields> </fields>

The available fields in each metafile are determined by a collection metafile schema. The
schema is a template that is used to create each document-specific metafile instance.

Some metafile field values are filled automatically and cannot be modified, while other field
values can be dynamically updated at any time to store additional information or to take action
on a document.


You can add new metafile fields to the schema through the Information Archive GUI
(Figure 6-7). We show the procedure in detail in “Modifying the metafile schema” on
page 209.

Figure 6-7 Collection Properties - Metafile configuration - REPLACE

There are three types of metafile fields: system, user, and event fields:
System fields:
System fields are created by the appliance, and only the appliance can update the values
of these fields. System fields can include the following information about a document:
– Expiration date and time
– Event-based retention period
– Service class name
– Document integrity hash value (MD5 checksum)
– Commit date and time
– The names of any retention hold currently in place
System fields are read-only and users or applications must not attempt to modify their
values. After a document has been ingested, several system fields are displayed in the
metafile (Example 6-2).

Example 6-2 Metafile with all available system fields

<fields>

<_SYSTEM_minimumRetention_>Fri Mar 12 10:17:21 2010</_SYSTEM_minimumRetention_>
<_SYSTEM_serviceClass_>IADefault</_SYSTEM_serviceClass_>
<_SYSTEM_md5Checksum_>66a82015cbc5e83329acbb6869857ce8</_SYSTEM_md5Checksum_>
<_SYSTEM_retained_>2010-03-10 10:17:21</_SYSTEM_retained_>
<_SYSTEM_eventDuration_>900</_SYSTEM_eventDuration_>
<_SYSTEM_currentHolds_>LOA</_SYSTEM_currentHolds_>

</fields>


User fields:
User fields are custom fields that you can add to the metafile schema. The values of these
fields can be updated by users and archiving applications.
Before adding user fields to a metafile, the user fields must first be defined in the Metafile
Configuration panel of the Collection Properties in the Information Archive GUI. When you
add a user field to the schema, you can specify whether the field value can be modified
after it is initially set.
User fields can be added to a metafile at any time (following document commit, after a
non-modifiable field value is written, it cannot be updated). In the XML of the metafile, user
field elements are contained within the fields element. The name of the user field element
consists of the _USER_ prefix, followed by the field name, followed by an underscore. For
example, for a custom metafile field with name Department, the corresponding user field
element name is _USER_Department_. User field values must be specified between the
element tag and its end tag (Example 6-3).

Example 6-3 Metafile with user field

<fields>

<_USER_Department_>Human Resources</_USER_Department_>

</fields>

Attention: XML element attributes must not be used and will be ignored.

After the user field has been added, the metafile is saved. When the metafile is viewed,
the user field is displayed along with the system fields. User field values can be updated
by opening the metafile on an NFS client, replacing the value, and writing the metafile. If
the field is modifiable or the document has not yet been committed, the user field value is
updated.
Event fields:
Event fields are predefined fields that can be used to trigger document actions. Events are
triggered by writing a new tag in the metafile, which can be done by users and archiving
applications.
Several predefined events can be triggered using metafiles, including the following events:
– Committing a document
– Setting retention for a document
– Setting or triggering event-based expiration for a document
– Setting or releasing a retention hold on a document
– Specifying a service class for a document
After the metafile is written (see Example 6-4), the event fields are processed and the
archive retention operations are performed on the document.


Example 6-4 Written metafile with HOLD event

<fields>

<_EVENT_hold_>LOA</_EVENT_hold_>

</fields>

When the metafile is reopened for viewing, the previously written event fields are not
displayed. However, the results of the operation might be reflected in one or more of the
System fields (see Example 6-5).

Example 6-5 Metafile after event fields are processed

<fields>


</fields>

Events: When an event is triggered through a metafile, the event is processed
immediately after the metafile is written. After processing, the corresponding EVENT
tags or tag values are automatically removed from the metafile.

6.2.4 Initial disk storage and secondary disk storage category
With File Archive Collections, newly ingested documents are placed in primary disk storage
category (also called initial disk storage). When a capacity utilization threshold is reached,
documents are moved out of primary disk storage category into the secondary disk storage
category. Both disk storage areas are on the same disk storage subsystem, in the same
GPFS filesystem, and migration is not intended to overcome space or technology problems.
Migration is intended to enable additional functions such as data-deduplication, compression
(if enabled), and optional migration to a third hierarchy (tape devices). Migration continues
until the capacity utilization reaches a specified threshold. All documents that have been
migrated can be recalled and viewed.

Migration environment
The migration is done by a migration manager environment, where a special version of IBM
Tivoli Storage Manager server with enhanced security functions is used as the migration
manager within the File Archive Collection. The storage used by this IBM Tivoli Storage
Manager server is named secondary storage category in Information Archive.


Within the primary storage category, a Tivoli Storage Manager Hierarchical Storage Manager
(HSM) client is running and monitoring the file system. You can see the overall layout of the
File Archive Collection in Figure 6-1 on page 168.

Documents can be compressed and deduplicated when they are migrated to secondary
storage to optimize the data storage capacity of the collection. Migration also optimizes the
appliance performance by running the processor-intensive compression (if enabled) and
deduplication procedures on older documents while new documents can be stored with less
processing.

With the migration of a file, a placeholder, or stub file, is created in place of the original file.
The stub file is a small replacement file that makes it appear as though the original file is on
the local file system. It contains required information to locate and recall a migrated file and to
respond to specific operating system commands without recalling the file.

For faster migration, the migration manager uses the premigration process to prepare the files
for automatic migration. Premigrated files are copied from the primary storage to the
secondary storage while the original files remain on the primary storage file system.

Files are not migrated unless doing so saves space in the primary storage. The exact
minimum file size is dependant upon the file system; however, in general, the migrated file
must be larger than the replacement stub file.

Important: The following types of files cannot be migrated from primary disk storage:
Files with names larger than 255 bytes or path names larger than 1024 bytes
Files with names that contain both single and double quotation marks

These files are not compressed, deduplicated, or migrated to tape. The files are ingested
and made immutable, but remain in primary disk storage for the duration of their retention
periods.

The high and low threshold percentages for your file system affect the migration process.
A high threshold determines when migration starts. A low threshold determines when file
migration stops. Specify a value of 0 through 100 percent. The default for a high threshold is
90 percent. The default for a low threshold is 80 percent. For example, if you allocate 10 GB
for a file system, and you must maintain at least 1 GB of free space, set the high threshold to
90 percent. If space usage equals or exceeds 90 percent, files automatically begin migrating
The migration starts with the first file that is listed in the current migration candidates list for
your file system. See “Creating and maintaining a File Archive Collection” on page 182 for the
procedure to set the migration thresholds for your File Archive Collection.

File Archive Collections can also migrate documents to a tape-based storage category. In a
File Archive Collection, tape is the third storage category. Tape migration is only an option if a
tape library is attached and configured. The migration threshold for this category is configured
using the IBM Tivoli Storage Manager server in the appliance.

Tip: If you have configured an external IBM Tivoli Storage Manager server to back up
documents, do not set a migration threshold so low that documents are migrated before
the daily backup is run. The backup is slower when the documents have been migrated to
secondary storage because each document has to be recalled before it is sent to the
external Tivoli Storage Manager server.


Collection protection
The File Archive Collection protection is based on three types of security enhancements:
Document protection
Restricted host and HTTP user access
Audit logs

The document protection level determines whether documents can be deleted before the end
of their retention period, and if retention periods can be reduced. Information Archive provides
three levels of document protection with increasing levels of protection. These levels are:
Basic, Intermediate, and Maximum.

Basic document protection works as follows:
Documents can be deleted before they expire.
Retention periods can be increased and decreased.
Documents with an extended retention because of a retention hold can be deleted.
You can modify the document protection option to one of the other levels at any time.

Intermediate document protection works as follows:
Documents cannot be deleted until they expire.
Retention periods can be increased and decreased.
Documents with an extended retention due to a retention hold cannot be deleted.
You can modify the document protection option to maximum at any time but cannot lower
it to basic.
The collection cannot be deleted.

Maximum protection document works as follows:
Documents cannot be deleted until the end of their retention period.
Documents with an extended retention because of a retention hold cannot be deleted.
Document retention periods can be increased, but not decreased.
After it is enabled, you cannot modify the document protection option to another level.
The collection cannot be deleted.

Tips:
Because the basic document protection permits you to delete files before they expire,
this level might be the best to start with in initial setups, proof of concepts, application
programming, or any other situation where the outcome is not guaranteed until testing.
Before archiving production data, turn to intermediate or maximum document
protection.
For data retention compliance, it is better to use maximum document protection.

Restricted host and HTTP user access mean, that NFS client access to the File Archive
Collection is controlled by granting access to the NFS client allowed to mount the collection.
You can specify whether the host is granted read-only or read-write access. HTTP access is
granted on a user- or group-level basis. A user or group defined in LDAP that wants to access
archived documents using HTTP must be first granted access to the collection. The access is
granted through the Information Archive GUI. We show an example of the appropriate
procedure in “Sharing directories and granting client nodes access” on page 211.


Each File Archive Collection maintains a set of tamper-proof audit logs, which provide an
immutable and retention-protected provenance record for documents in the collection. Audit
logs track document ownership and system lifecycle events including document creation and
deletion, changes to retention policies, and system software upgrades. Audit logs can be
downloaded directly from the administrative interface, or accessed remotely using the
Network File System (NFS) protocol. Audit logs can only be downloaded by users with
Information Archive auditors roles. Additionally, the collection administrator can optionally
designate a user group at the time of creating a collection that will be used to manage access
to the audit logs when using NFS client access.

6.2.5 Additional considerations for File Archive Collections
For performance reasons, some NFS implementations cache file information about the client.
Some of the information (for example, file state information such as file size and timestamp) is
not kept up-to-date in this cache. The client can view stale node data (on ls -l, for example)
if exporting a GPFS file system with NFS.

Turning off caching
If caching is not acceptable for a given installation, caching can be turned off by mounting the
file system on the client using the appropriate operating system mount option (for example,
-o noac on Linux NFS clients). Turning off NFS caching results in extra file system operations
to GPFS, and negatively affects its performance.

Time settings
The Information Archive appliance requires a time server to enforce retention policies and to
correctly apply time stamps for audit log events. Also, NFS relies on metadata timestamps to
validate the local operating system cache. If the same directory is either NFS-exported from
more than one node, or is accessed with both the NFS and GPFS mount point, it is critical
that clocks on all nodes that access the file system (cluster nodes and NFS clients) be
constantly synchronized using appropriate software (for example, NTP). Failure to do so might
result in stale information seen on the NFS clients.

The appliance includes a default time server, which runs on the Management Console server.
During manufacturing, the system time is set and the appliance components are
synchronized with the default time server. The TCP/IP address of the default time server is
172.31.3.2. You must also synchronize the archiving application with the internal NTP server.

For the highest level of system clock protection, use the default time server for the appliance
itself as well as any clients that connect to it. As an alternative, you can specify an external
time server for the appliance. If you choose this option, consider using the same time server
for any clients that connect to the appliance.

Important: If you use an external time server, the appliance ignores any time change
greater than 16 minutes.

Make sure that the clocks of all cluster nodes are synchronized. If this is not the case, NFS
access to the data, as well as other GPFS operations, might be disrupted.

If a cluster node server that is used to access a collection meta directory is restarted or fails
over to another cluster node, the collection file system must be remounted on the NFS client
to continue accessing the meta directory. Until the file system is remounted, the NFS client
will receive a “stale NFS file handle” error when trying to access the meta directory.


Tip: Make sure, that you recognize restarts and fail over situations within the cluster node
environment, so that you can remount the NFS file system. Obviously, that is not applicable
in a single node environment.

6.3 Hypertext Transfer Protocol (HTTP)
The Hypertext Transfer Protocol (HTTP) and secure HTTP interfaces provide a means to
access File Archive Collections to retrieve documents for read operations only.

Information Archive is preconfigured for remote access using the HTTP interface on an
Apache HTTP server. You can also use secure HTTP. Any authorized user can use the HTTP
interface for read-only access to files in a specific File Archive Collection using a web
browser. Self-signed certificates enable secure HTTP access through a public and private key
pair that is configured during installation.

User credentials are authenticated by the Linux operating system at the Information Archive
cluster nodes. Root access to the cluster node through the HTTP interface is prohibited. The
use of an LDAP user repository, either IBM Tivoli Directory Server or Microsoft Active
Directory, is also supported. The authorization for users to execute operations is verified in
GPFS ACLs based on the user account and security role of the issuer.

Information Archive uses the NFS protocol to access documents in File Archive Collections
(see “Network File System (NFS)” on page 169). This method differs from the HTTP protocol
that can retrieve documents but not archive them.

You can retrieve a document from the archive through the Hypertext Transfer Protocol (HTTP)
interface using any supported web browser. The Archive Administrator must ensure that
users have collection-level access permission.

Use the collection access information to configure NFS client applications to archive
documents and to retrieve documents using HTTP.

Important: Within the collection access configuration, to add a user, the user name must
already be defined on the external LDAP server that is used by the appliance.

6.4 Creating and maintaining a File Archive Collection
Creating a File Archive Collection is primarily done automatically by the Create Collection
Wizard (CCW). Because the wizard is running commands in the background, they are not
visible by the user doing the configuration. Changes might be necessary within the initial set
up procedure, or somewhere in the entire lifecycle of the system. For example, you need to
change settings when you attach optional tape devices or change tape technology over the
years. We explain in this section how to use the Information Archive GUI to make such
required changes. At the end of this section we explain how to register a file archive client is
described and illustrate most tasks relevant to the use the File Archive Collections.


6.4.1 Creating a File Archive Collection
You can create a collection if the Information Archive appliance has a disk storage subsystem
and a cluster node not yet used by another collection. To create a File Archive Collection, you
need to log on to the Information Archive GUI with a user account that has a user role of IA
Archive Administrator. That user must also be set up in the LDAP environment with the same
password.

Log on to the Information Archive GUI (Figure 6-8), that is, the Integrated Solutions Console,
and complete the following steps:
1. In the navigation tree, expand Information Archive Management
3. Click Create Collection in the main entry panel.

Figure 6-8 Information Archive Management - Collections

If you have already created other collections in your system, they are displayed in this
Collection Overview panel. After we create our new collection, it will also show up here.
If there is no disk subsystem still available, the creation of a new collection is not possible.
The wizard reports an error and rejects the creation (see Figure 6-9).

Figure 6-9 Collection Overview - No available disk subsystem


4. On the Welcome page, which is displayed if the creation of a new collection is possible,
read the additional information about collections. Use the Online Help if you need further
assistance. Click Next to proceed.
5. On the General page (Figure 6-10), select Create a File Archive Collection (radio
button) and provide a collection name. Collection names can contain a maximum of 30
characters (only characters 'A-Z', 'a-z', '0-9' and '-' are allowed), and each collection must
have a unique name. You can also fill in a description for the collection. It is optional, but
good practice to complete the description field.

Figure 6-10 Create a NFS Collection - General

In our example, we use the collection name NFS1, because this is our first File Archive
Collection and it is based on the Network File System (NFS) protocol.
6. If the Disk Storage Subsystem page is shown, select the disk system where you want the
File Archive Collection to reside.
Keep in mind that there might be differences in the capacities of your available disk
storage subsystems. Hence, choose the one that is most appropriate for your NFS
collection.
If the Disk Storage Subsystem page is not shown, it means that there is only one disk
storage subsystem still available and it is automatically chosen by the Create Collection
Wizard.


7. On the Document Protection page (Figure 6-11), select the appropriate level of protection
from Basic, Intermediate, and Maximum and proceed with Next.

Figure 6-11 Create a NFS Collection - Document Protection

Because we can increase the level of protection from Basic to Maximum, but cannot
decrease the level, we start with the most convenient level and that is Basic. Only use this
level, if your legal or regulatory compliance requirements do allow it. Use Intermediate or
Maximum with production data only.
Click Next to proceed.


8. On the Document Retention page (Figure 6-12), choose between the chronological
retention and event-based retention. This page allows the creation of retention rules.
The settings specified here apply to the default service class IADefault and are valid for
all documents in this service class. You can create more service classes (desirable) and
other document retention settings later.

Figure 6-12 Create a NFS Collection - Document Retention

In our example (see Figure 6-12), we choose the chronological retention and we provide a
very short time as retention period (2 days). We choose this retention time because we
want to test some features in the File Archive Collection and do not want to wait too long
for results.

Tip: In real production environments, it is best not to use such short retention settings.
Also, the use of additional service classes and document rules is highly preferred.

9. On the Document Actions page (Figure 6-13),select one of two methods for committing
documents into the File Archive Collection. Choose the automatic commitment or deny the
automatic commitment. Also, decide whether automatic expiration needs to be provided.
In our illustration, we configure the automatic commitment of documents after 5 minutes
idle time. If using an archive application that provides the functionality to commit
documents, the application can do so within that 5 minutes period. If the application does
not have a commit function, Information Archive will automatically commit the file after
5 minutes.
We do not select the automatic deletion of expired documents. With that setting, archiving
applications with the functionality of deletion can find their documents and do not run into
problems with non-existing documents.

Attention: If you do not use the automatic deletion feature, you must take care of space
allocation and maintenance of the allocated file system. That can be done outside of
Information Archive, that is, by the archiving application or any file system analysis
software.


Figure 6-13 Create a NFS Collection - Document Actions

10.On the Disk Migration page (Figure 6-14), set parameters for the document migration in
your system. Also, choose if you want your documents to be compressed or deduplicated,
or both after a migration.

Figure 6-14 Create a NFS Collection - Disk Migration



11.On the Audit Logs page (Figure 6-15), choose the retention time for audit logs. To be able
to remotely access the audit logs, you need to provide a LDAP user group or groups in the
appropriate field.

Figure 6-15 Create a NFS Collection - Audit Logs

To enable remote access to audit logs, you must specify an LDAP user group that can
access them when using the Create Collection Wizard.

User groups: You cannot add a user group or specify another one after the collection is
created.

We chose an audit log retention time that is equal to our document retention setting.
Therefore, we can use the audit log for analysis during the entire document retention.
Click Next.
12.For the root directory of the File Archive Collection, specify the ownership and internal
access permissions. The root directory is the directory, where the collection data and meta
data are stored - do not confuse this directory with the root directory of the operating
system. The data directory and meta data directory are mounted later from any host that is
granted access.
In Figure 6-16 you see an example, where we grant access to the root directory of the File
Archive Collection. The user with the User Identification Number (UID) 1023 and the Group
Identification Number (GID) 10002 are defined as owner.


The directory permissions are also configured here. You can set read and write
permission as well as execution permissions. In our example, we allow all possible
commands for the user itself, whereas the group and therefore any user belonging to the
same group of the directory owner, can read and write. All other users can only read in the
root directory of the File Archive Collection. They cannot write or execute any file or
program in this directory.
If you are used to a UNIX-based or Linux file system, you can compare this configuration
step with the setup of the ordinary UNIX and Linux file system permissions.

Figure 6-16 Create a NFS Collection - Root Directory Ownership

Click Next.
13.In the next panel, configure the external access to the root directory of the File Archive
Collection (Figure 6-17). Depending on the appliance properties, you see various fields
that can be used to grant directory access to users, groups, and host systems.
– User name - for HTTP (this field is only shown if LDAP support is enabled for the
appliance)
Use this option to grant a user read-only access to the directory. The user can access
the directory using a web browser.

Users: To add a user, the user name must already be defined on the external LDAP
server that is used by the appliance.

– Group name - for HTTP (this field is only shown if LDAP support is enabled for the
appliance)
Use this option to grant the members of a user group read-only access to the directory.
The users can access the directory using a web browser.

User groups: To add a user group, the group name must already be defined on the
external LDAP server that is used by the appliance. You must configure and manage
group membership using the LDAP server.


– Host - for Network File System (NFS)
Use this option to allow the directory to be mounted on a host system that is running an
NFS client.
To specify multiple hosts, you can substitute parts of a host name with the asterisk or
question mark wildcard characters (“*” or “?”). For example, *.cs.foo.edu includes all
of the hosts in the cs.foo.edu domain and any subdomains. As an alternative, you can
specify a TCP/IP address and netmask pair. The netmask can be specified in
dotted-decimal format, or as a contiguous mask length (for example, you can specify a
range of 1024 TCP/IP addresses by appending either “/255.255.252.0” or “/22” to the
network base address).

Figure 6-17 Create a NFS Collection - Root Directory Access

Host access level:
• Read and write - users are allowed to copy new files into the directory, modify or
delete uncommitted documents, modify metafiles, and delete expired documents.
• Read-only - users are only allowed to read committed documents.
Furthermore, you can add, modify, of delete access to the File Archive Collections at any
time after the initial setup. Hence, the configuration at this time does not need to include all
users or systems.
14.On the Summary page (Figure 6-18), read through the given information and write down
the important values like the name, TCP/IP address, and HTTP address of the collection.


Figure 6-18 Create a NFS Collection - Summary

Observe the fact that the collection can never be deleted after its creation and that
Enhanced Tamper Protection is not enabled automatically. Not enabling Enhanced
Tamper Protection is helpful in an initial set up, because without Enhanced Tamper
Protection you can analyze and reconfigure more items in the system. For a production
environment, and that is even more true for a compliance environment, it is advised to turn
the Enhanced Tamper Protection on.
Verify your settings and when OK, press Finish to start the actual configuration of the File
Archive Collection.
15.Observe the progress on the panel (Figure 6-19) as the Create Collection Wizard starts
creating the File Archive Collection.

Figure 6-19 Create an NFS Collection - Progress of creating collection

Wait until the Create Collection Wizard signals the end of the process. The wizard will
indicate if any error occurs.
When finished, the Create Collection Wizard returns you automatically to the collection
overview page. Short after the creation of a File Archive Collection, the internal IBM Tivoli
Storage Manager server is restarted and that is visible for a short moment on the overview
page (Figure 6-20).


Figure 6-20 Collection Overview - IBM Tivoli Storage Manager server warning message

At the very end, all error messages must disappear and the statistics overview panel is
displayed (see Figure 6-21).

Figure 6-21 Collection Overview - Overview statistics

Only proceed to the next step, that is, the administration of the File Archive Collection, if no
errors were reported during the creation process.

6.4.2 What is preconfigured with the File Archive Collections
The default settings and definitions for a File Archive Collection are mainly the result of
executing the Create Collection Wizard and one script used by the Initial Configuration
Wizard.

Predefined service classes and document rules
There is one preconfigured service class named IADefault. This is the default service class
for File Archive Collections. The default service class cannot be deleted, because it is used to
retain documents for which no other retention period is specified.


Document rules cannot be associated with the default service class because again it is used
to retain documents for which no other retention period is specified. Therefore, the default
service class does not have any document rule.

To retain documents with settings other than in the default service class, or to use document
rules, you must create your own service class and at least one document rule. We show the
appropriate procedure in “Creating a service class and a document rule” on page 204.

Predefined initial storage category and secondary disk storage category
The predefined initial storage category location, that is the primary disk storage, and the
secondary disk storage category, are located on the same disk storage subsystem. It is the
disk storage subsystem that you choose during the initial setup of the File Archive Collection.

The primary storage category is always located in the /tiam/<collection_name>/data
directory, where <collection_name> is the name of the File Archive Collection chosen during
the initial setup.

The corresponding metafiles are stored in the /meta/tiam/<collection_name>/meta directory.
The two directories are also referred to as the root directory of the File Archive Collection.

The secondary storage category is located in the /tiam/<collection_name>/tsm/fileclass/
directory, where <collection_name> is the name of the File Archive Collection chosen during
the initial setup.

IBM Tivoli Storage Manager database, database logs, and database
backups
Figure 6-22 illustrates results from Tivoli Storage Manager queries (query db, query dbspace)
that show the preconfigured Tivoli Storage Manager database characteristics for File Archive
Collections:

Database Name: TSMDB1
Total Size of File System (MB): 4,718,592
Space Used by Database(MB): 448
Free Space Available (MB): 4,632,583
Full Device Class Name: FILECLASS
Last Complete Backup Date/Time:
Location: /tiam/NFS1/tsm/db
Total Size of File System (MB): 4,718,592.00
Space Used on File System (MB): 85,945.00
Free Space Available (MB): 4,632,583.00
Figure 6-22 Preconfigured IBM Tivoli Storage Manager database

The IBM Tivoli Storage Manager server can use all the space that is available on the drives or
file systems where the database directories are located. In Figure 6-22, the database finds
4.5 GB (4,718,592 MB) on the disk storage subsystem named iastorage2, that is where we
created our File Archive Collection. The disk storage subsystem iastorage2 has 4.95 TB
overall (see Figure 6-23). At the time of writing (with IBM Tivoli Storage Manager V6.1),
the maximum supported size of the IBM Tivoli Storage Manager database is 1 TB.


Figure 6-23 Disk storage subsystem capacity for File Archive Collection

Figure 6-24 shows results from an IBM Tivoli Storage Manager query (query log f=d) for the
preconfigured log files of the IBM Tivoli Storage Manager database log files:

tsm: NFS1>q log f=d

Total Used Free Active Log Mirror Log Archive Failover Archive Log
Space(MB) Space(MB) Space(MB) Directory Directory Log Directory Directory
--------- --------- --------- --------------- --------------- ---------------- ---------------
40,960 0.84 40,799.16 /tiam/NFS1/tsm- /tiam/NFS1/tsm- /tiam/NFS1/tsm-
/activelog /mirrorlog /archlog

Figure 6-24 Preconfigured IBM Tivoli Storage Manager database log files

These outputs depend on the physical configuration of the Information Archive appliance and
your input during the Create Collection Wizard process. For example, the location of the IBM
Tivoli Storage Manager database depends on the name chosen for the File Archive
Collection. If there are multiple File Archive Collections, obviously there are unique collection
names. Also, if you choose a storage subsystem with another size, the information will differ
from our example.

By default, full database backups scheduled with File Archive Collections and the appropriate
IBM Tivoli Storage Manager server. The database backups can be seen with the IBM Tivoli
Storage Manager command query volhist t=dbb. Example 6-6 shows one IBM Tivoli
Storage Manager database backup consisting of two backup files.

Example 6-6 IBM Tivoli Storage Manager query volhist t=dbb (excerpt)
tsm: NFS1>query volhist t=dbb

Date/Time: 03/07/10 06:00:15
Backup Series: 2
Backup Operation: 0
Volume Seq: 1
Volume Name: /tiam/NFS1/tsm/fileclass/67941616.DBV
Volume Location:
Command:


Date/Time: 03/07/10 06:00:15
Backup Series: 2
Backup Operation: 0
Volume Seq: 2
Volume Name: /tiam/NFS1/tsm/fileclass/67941641.DBV
Volume Location:
Command:

When you use the IBM Tivoli Storage Manager command select * from backups, you also
see the IBM Tivoli Storage Manager database backups, as if they were backed up by a
backup-archive client (see Example 6-7, where we show the same backup files as in
Example 6-6). Because there is a special nodename $$_TSMDBMGR_$$ used for the
backup of IBM Tivoli Storage Manager V6 databases, you cannot see the name in the output
of the select statement.

Example 6-7 IBM Tivoli Storage Manager database backups within backup copy group (excerpt)
tsm: NFS1>select * from backups

NODE_NAME:
FILESPACE_NAME: /TSMDB1
FILESPACE_ID: 888
STATE: ACTIVE_VERSION
TYPE: FILE
HL_NAME: /NODE0000/
LL_NAME: FULL_BACKUP.20100307060015.1
OBJECT_ID: 1029
BACKUP_DATE: 2010-03-07 06:00:16.000000
DEACTIVATE_DATE:
OWNER: u2
CLASS_NAME: DEFAULT

NODE_NAME:
FILESPACE_NAME: /TSMDB1
FILESPACE_ID: 888
TYPE: FILE
HL_NAME: /NODE0000/
LL_NAME: FULL_BACKUP.20100307060015.2
OBJECT_ID: 1030
BACKUP_DATE: 2010-03-07 06:00:41.000000
DEACTIVATE_DATE:
OWNER: u2
CLASS_NAME: DEFAULT


Tip: IBM Tivoli Storage Manager database backups are managed in backup tables in the
IBM Tivoli Storage Manager database. That is the only data in Information Archive that is
managed in backup tables. You do not see any space managed data or archived data with
the select * from backups command.

Default configuration script for IBM Tivoli Storage Manager setup
During the creation of the collection by the Create Collection Wizard, the wizard executes a
script based on a template named tiam_tsm_setup.script and parameters from the
Configuration wizard (Figure 6-25) to configure the File Archive Collections in Tivoli Storage
Manager. The script contains all the commands necessary to create a complete Tivoli
Storage Manager archive environment, including retention policies, storage pools, and
schedules.

set actlogretention 30

SET TAPEALERTMSG on

register license file=*.lic

define devclass fileclass devtype=file dir=./fileclass

delete stg backuppool
delete stg archivepool
delete stg spacemgpool

define stgpool filepool fileclass maxscr=100000000 dataformat=nonblock crcdata=yes
reclaim=10 reclaimprocess=2 collocate=no

upd MGmtclass STANDARD STANDARD standard SPACEMGTECHnique=SELective MIGREQUIRESBkup=No
MIGDESTination=filepool

upd copygroup standard standard standard type=backup destination=filepool
upd copygroup standard standard standard type=archive destination=filepool

validate policyset standard standard
activate policyset standard standard

register admin adminconsole DfUo79iL passexp=0
grant auth adminconsole class=sys

set servername NFS1
set serverhla 172.31.4.2
set serverlla 1501

register node ia_reserved NFS1 forcepwreset=yes maxnummp=999 VALIdateprotocol=all
compression=client
remove admin ia_reserved
set spmretentionprotection on
SET DBRECOVERY fileclass

define schedule daily_maint type=administrative cmd="run daily_maint" active=yes
description="IA daily maintenance" starttime=06:00 period=1
define script daily_maint file=/opt/tivoli/tiam/bin/ia_tsm_daily_maint.script
description="IA daily maintenance including DB backup"

Figure 6-25 Configuration script for NFS Collection setup (/tiam/NFS1/tsm/tiam_tsm_setup.script)


Another script named ia_tsm_daily_maint.script is invoked during the initial configuration of
the IBM Tivoli Storage Manager server environment (Figure 6-26).

backup db type=full devclass=fileclass wait=yes
delete volhistory todate=today-3 type=dbb
delete volhistory todate=today-30 type=stgnew
delete volhistory todate=today-30 type=stgreuse
delete volhistory todate=today-30 type=stgdelete
backup volhistory
backup devconfig
Figure 6-26 /opt/tivoli/tiam/bin/ia_tsm_daily_maint.script

The environment created through the scripts, as such, is ready for use by the File Archive
Collection. If the predefined settings for the default policy domain are also inline with your
requirements, you can start using Information Archive immediately after mounting NFS
shares. Otherwise there are two other options before you proceed:
Update or enhance the predefined configuration with appropriate File Archive Collection
commands. See “File Archive Collection administration” on page 204 for the appropriate
procedures.
Grant access to the NFS collection and archive and retrieve documents.

Predefined device classes
Figure 6-27 shows predefined device classes on the IBM Tivoli Storage Manager server,.
They can be analyzed with the IBM Tivoli Storage Manager command query devclass:
Device class DISK:
This device class represents random access media and must not be used in Information
Archive unless data shredding is needed. All other storage pools will be created with the
FILE device type.
Device class FILECLASS, device type FILE:
FILECLASS uses the device type FILE. It is a sequential access device class that has
been predefined and is used for full database backups that run daily as specified in an
administrative schedule on the IBM Tivoli Storage Manager server. The sequential access
files (volumes) created by this process are located in the
/tiam/<file_archive_collection_name>/tsm/fileclass/ file system.

tsm: NFS1>q devclass

Device Device Storage Device Format Est/Max Mount
Class Access Pool Type Capacity Limit
Name Strategy Count (MB)
--------- ---------- ------- --------- ------ -------- ------
DISK Random 0
FILECLASS Sequential 1 FILE DRIVE 2,048.0 20

Figure 6-27 Predefined IBM Tivoli Storage Manager device classes

Predefined primary storage pools and storage pool volumes
There is one primary disk pool named FILEPOOL, but shortly after the initial setup there is
no preconfigured storage pool volume. A volume will be created later, that is, with the first
automated migration of Information Archive audit logs.


The FILEPOOL uses the device class type FILE with the device class FILECLASS, and the
volumes are created during write processes (for file archive pools, that is, space
management). Each volume is preconfigured in the device class to be 2.0 GB of size
maximum (Est/Max Capacity). When the volume is written the first time, space in the
maximum capacity is allocated on the disk storage subsystem. In the case of the Information
Archive Tivoli Storage Manager server, there is already data archived during the initial setup.
(See Example 6-9 for an illustration of automatically space managed data.)

To check the storage pool, issue the commands query stg and query vol in IBM Tivoli
Storage Manager.

To make process this more transparent, we show an example of a typical output from the
query volume command in Example 6-8 after the first objects were archived in the collection.

Example 6-8 Output of query vol (excerpt)
------------------------ ----------- ---------- --------- ----- --------
/tiam/NFS1/tsm/fileclas- FILEPOOL FILECLASS 2.0 G 0.0 Filling
s/00000002.BFS

Use the Tivoli Storage Manager command query content to see the files that are already in
your environment. Example 6-9 shows an example of space managed Information Archive
audit log directories, that are automatically stored within one storage pool volume.

Example 6-9 Automatically space managed data (excerpt)
tsm: NFS1>q content /tiam/NFS1/tsm/fileclass/00000002.BFS

Node Name Type Filespace FSID Client's Name for File
Name
----------- ---- ---------- ----- ----------------------
IA_RESERVED SpMg /tiam/NFS1 1 /audit/2010/2010-03-05

In larger environments, it is more convenient to use an SQL select statement to query the
contents of the IBM Tivoli Storage Manager environment. Use the Tivoli Storage Manager
command select * from spacemgfiles and appropriate SQL options to query your system
(see Example 6-10).

Example 6-10 IBM Tivoli Storage Manager data within space management
tsm: NFS1>select * from spacemgfiles

FILESPACE_NAME: /tiam/NFS1
EXTOBJID: 0101020C000000001FAC03010406206E0095EA7062571D35410E05E7
OBJECT_ID: 1025
FILE_NAME: /audit/2010/2010-03-05
INSERT_DATE: 2010-03-06 00:01:48.000000
DELETE_DATE:
CLASS_NAME: DEFAULT


The IBM Tivoli Storage Manager server of a File Archive Collection does not manage any
archiving data (Example 6-11). The data that you archive within the File Archive Collection
through the NFS share is stored within the IBM Tivoli Storage Manager server as space
managed data, but not as archived data. You can verify this with the IBM Tivoli Storage
Manager select * from archives command.

Example 6-11 IBM Tivoli Storage Manager data within archive copy group
tsm: NFS1>select * from archives

ANR2034E SELECT: No match found using this criteria.
ANS8001I Return code 11.

Predefined administrative schedules and their results
There is one predefined administrative schedule DAILY_MAINT that is executed daily at
6:00:00 o'clock on the IBM Tivoli Storage Manager server. You can check the schedule with
the IBM Tivoli Storage Manager command query schedule type=admin f=d.

The schedule DAILY_MAINT is running a script instead of a single command. Hence, the
commands will be executed in a sequential order and they provide a full maintenance cycle to
the IBM Tivoli Storage Manager environment. The script is shown in Figure 6-28.

Name: DAILY_MAINT
Line Number: 1
Command: backup db type=full devclass=fileclass wait=yes
Line Number: 6
Command: delete volhistory todate=today-3 type=dbb
Line Number: 11
Command: delete volhistory todate=today-30 type=stgnew
Line Number: 16
Command: delete volhistory todate=today-30 type=stgreuse
Line Number: 21
Command: delete volhistory todate=today-30 type=stgdelete
Line Number: 26
Command: backup volhistory
Line Number: 31
Command: backup devconfig

Figure 6-28 Administrative script DAILY_MAINT (excerpt)

The first command (Line Number: 1) produces a full database backup of the IBM Tivoli
Storage Manager database using the device class FILECLASS. The resulting backup volumes
are created in the /tiam/<file_archive_collection_name>/tsm/fileclass/ directory. Example 6-6
on page 194 shows the output of a query volhist t=dbb command. Use this command to
verify how many and what backup volumes are created by this or other database backup
commands.

The next four commands in the script DAILY_MAINT (Line Number: 6, 11, 16, 21) clean the
volume history file. The volume history file stores information about all volumes that IBM
Tivoli Storage Manager uses, that is database backups (dbb) and storage pool volumes (stg).
The volume history keeps 3 versions of database backups and it tracks all storage pool
volume actions like the creation, reuse, and deletion of volumes over the last 30 days
(Example 6-12). Depending on the retention policies there are new storage volumes created
over the time, but also expired volumes are deleted. You will need that information when you
plan restores of your data.


Tip: The predefined schedule deletes old IBM Tivoli Storage Manager database backups
and keeps three versions of database backups on hard disk. If this setting does not fit your
requirements, reconfigure the schedule and the maintenance scripts, respectively.

Example 6-12 Output of query volhist (excerpt)
Date/Time: 03/06/2010 14:50:32
Volume Type: STGNEW
Backup Series:
Backup Operation:
Volume Seq:
Volume Name: /tiam/NFS1/tsm/fileclass/0000010A.BFS

The script DAILY_MAINT (Line Number: 26) dumps the volume history file as a backup copy
to a specified directory. The IBM Tivoli Storage Manager command is backup volhistory and
the backup is written to the /tiam/<file_archive_collection_name>/tsm/volumehistory file.

With the last command in the DAILY_MAINT script (Line Number: 31), the device
configuration is dumped out of the database into a plain file. The IBM Tivoli Storage Manager
command is backup devconfig and the backup is written to the
/tiam/<file_archive_collection_name>/tsm/devconfig file.

Tip: The preconfigured administrative schedule and the administrative script provide
appropriate protection for the IBM Tivoli Storage Manager environment. However, they can
be customized to better fit your requirements. For example, if the full database backup at
6:00 interferes with a heavy archiving workload, the start time can be modified to another
time that fits better into the workload profile. Note that you can also use additional
commands within the script to generate more workload. The specific numbering of the
used lines even let space for inserting commands between already delivered ones.

When a specific schedule runs, the scheduled action is represented by an event. Hence,
every schedule produces every day its own event. You can check out those administrative
events with the IBM Tivoli Storage Manager command q event t=a * to see the most
currents events or q event t=a begind=+1 to see forthcoming events. The latter command is
useful, if you create new schedules and you want to check when they are running next time.

In Example 6-13, we show the specific event that is result of the predefined administrative
schedule DAILY_MAINT. You can see the planned start time compared to the actual start and
the status.

Example 6-13 Output of query event * t=a
tsm: NFS1>q event * t=a

Scheduled Start Actual Start Schedule Name Status
-------------------- -------------------- ------------- ---------
03/06/2010 06:00:00 03/06/2010 06:00:32 DAILY_MAINT Completed


Installed default policy settings
The Create Collection Wizard configures policy domains and subsequent configurations such
as policy sets, management classes, and archive copy groups in the IBM Tivoli Storage
Manager server.
Installed default IBM Tivoli Storage Manager policy domain:
There is one policy domain preconfigured: STANDARD. This is the default policy for the
internal hierarchical storage management processes. Figure 6-29 shows the default
settings in the policy domain STANDARD.

tsm: NFS1>q dom STANDARD f=d

Activated Policy Set: STANDARD
Days Since Activation: 3
Activated Default Mgmt Class: STANDARD
Description: Installed default policy domain.
Managing profile:
Changes Pending: No
Figure 6-29 Default settings in the policy domain STANDARD

Installed default policy set:
There is one default policy set STANDARD predefined within the policy domain
STANDARD. Figure 6-30 shows the active policy set in the STANDARD domain.

tsm: NFS1>q policyset standard active f=d

Default Mgmt Class Name: STANDARD
Description: Installed default policy set.
Managing profile:
Changes Pending: No
Figure 6-30 Default settings for the active policy set STANDARD


Preconfigured management classes and default management classes:
The management class STANDARD is the only management class predefined
(Figure 6-31). Because this is the only management class in the policy domain, it is also
the default management class. The management class STANDARD is configured for
hierarchical storage management, also known as space management.

tsm: NFS1>q mgmt f=d

Mgmt Class Name: STANDARD
Default Mgmt Class ?: Yes
Description: Installed default management class.
Space Management Technique: Selective
Auto-Migrate on Non-Use: 0
Migration Requires Backup?: No
Migration Destination: FILEPOOL
Managing profile:
Changes Pending: No

Figure 6-31 Default management classes

You can back up and migrate your files to the same IBM Tivoli Storage Manager server or
to other IBM Tivoli Storage Manager servers. If you back up and migrate files to the same
server, the HSM client can verify that current backup versions of your files exist before you
migrate them.
If you back up files to one server and migrate them to another server, the HSM client
cannot verify that current backup versions of your files exist before it migrates them. Any
management class that you assign to files must specify that current backup versions are
not required prior to migration. Otherwise, you cannot migrate your files.

Tip: If you set the attribute Migration Requires Backup? (migrequiresbkup) to Yes in the
management class that you assigned to a file, Tivoli Storage Manager checks for a current
backup version of the file on your migration server only. The migration server is the
Information Archive IBM Tivoli Storage Manager server. If a current backup version does
not exist on your migration server, the file is not migrated, even if a current backup version
exists on another server.


Preconfigured copy groups:
There are two IBM Tivoli Storage Manager copy groups predefined, one backup copy
group (Figure 6-32) and one archive copy group (Figure 6-33). Both copy groups are
named STANDARD, you can differentiate them by their copy group type only.

tsm: NFS1>q co t=b f=d

Copy Group Name: STANDARD
Copy Group Type: Backup
Versions Data Exists: 2
Versions Data Deleted: 1
Retain Extra Versions: 30
Retain Only Version: 60
Copy Mode: Modified
Copy Serialization: Shared Static
Copy Frequency: 0
Copy Destination: FILEPOOL
Table of Contents (TOC) Destination:
Managing profile:
Changes Pending: No

Figure 6-32 Settings for default backup copy group STANDARD

tsm: NFS1>q co t=a f=d

Copy Group Type: Archive
Retain Version: 365
Retention Initiation: Creation
Retain Minimum Days:
Copy Frequency: CMD
Copy Mode: Absolute
Managing profile:
Changes Pending: No

Figure 6-33 Settings for default archive copy group STANDARD

The archive copy group of any File Archive Collection is not intended to be used.
Preconfigured IBM Tivoli Storage Manager client nodes:
There is only one client node preconfigured (Figure 6-34). The node IA_RESERVED is for
the purpose of generating the data, as previously mentioned, to protect the IBM Tivoli
Storage Manager server from being disabled for retention protection. Furthermore, the
client node IA_RESERVED is used for space management processes. This registered
node is not intended to be used by the customer.


tsm: NFS1>q node

Node Name Platform Policy Domain Days Since Days Since Locked?
Name Last Acce- Password
ss Set
------------------------- -------- -------------- ---------- ---------- -------
IA_RESERVED Linux86 IA_RESERVED <1 <1 No

Figure 6-34 Preconfigured IBM Tivoli Storage Manager client nodes

Preconfigured file expiration:
File expiration is automatically processed every 24 hours by default. You can see that with
the IBM Tivoli Storage Manager command query option expinterval.
The 24 hour interval starts with the start of the Information Archive Tivoli Storage Manager
server, so the actual start time in your environment can vary.
Automatic expiration can be reconfigured, whenever you need more static starting times or
if you recognize impact on your running environment that is caused by the expiration
process. For example, if you have billions of files and the expiration process takes very
long, you might want to run the process in small portions or other more detailed
configurations.

Tip: See the IBM Tivoli Storage Manager documentation to reconfigure the expiration
process, if applicable. Keep in mind that the expiration process is directly related to the
overall retention of your data.

6.4.3 File Archive Collection administration
The administration of the File Archive Collection includes various topics, that includes the
following capabilities:
Document retention: Create, modify, and delete service classes and document rules
Document actions: Create rules for committing files and files deletion
Metafile configuration: Create, modify, and delete metafile fields
Disk Migration: Create rules for document migration, compression, and de-duplication
Monitoring settings: Set parameters for the monitoring of uncommitted documents
Audit logs: Retain audit logs and grant access to the audit logs
Directory sharing: Grant, modify, and revoke access to the File Archive Collections

Creating a service class and a document rule
All File Archive Collections have a default service class named IADefault. To retain
documents for a period that differs from than that of the default service class, you must create
a new service class and at least one document rule. The following sections show the
appropriate procedures for these two tasks.

Creating a service class
Use the following procedure to create a service class and specify a retention period:
1. From the Information Archive GUI, expand Information Archive Management in the
navigation tree.
3. Click Properties in the applicable collection.
4. Click the Document Retention tab in the Collection Properties notebook.


5. In the right pane of the Document Retention tab, for Service Classes, select the action
Create Service Class from the scroll down menu (Figure 6-35).

Figure 6-35 Collection Properties - Document Retention - Service Classes - Create Service Class

6. In the Create Service Class window that is displayed, you must specify a name for the
service class and a retention policy for the documents (Figure 6-36). Then click OK.

Figure 6-36 Create Service Class - Chronological Retention

7. In the Collection Properties window, choose if you want to apply the settings to all
documents, including those previously committed, by checking the appropriate box at the
top of the window (Figure 6-37). By default, policy changes only apply to documents that
have not yet been ingested. To save the newly created service class, click Apply or click
OK.


Figure 6-37 Collection Properties - Document Retention - Save Service Class Settings

After you click Apply (if you want to create another service class) or OK (if you are done
with creating service classes), the File Archive Collections is being updated and you can
see the progress on the panel (Figure 6-38).

Figure 6-38 Progress information for update of document collection

Creating a document rule
Use the following procedure to create one or more document rules:
navigation tree.
4. Click the Document Retention tab in the Collection Properties notebook.
5. In the right pane of the Document Retention tab, for Document Rules, select the action
Create Rule from the scroll down menu (Figure 6-39).

Figure 6-39 Collection Properties - Document Retention - Document Rules - Create Rule


6. On the Create Document Rule window (Figure 6-40), create the rule, specifying the
service class that you created under “Creating a service class” on page 204. You can
create one or more criteria within the document rule, to indicate which files the rule will
apply to when the files are ingested. Here we illustrate two criteria.

Figure 6-40 Create Document Rule

7. In the scroll down menu of the Document Rule notepad (Figure 6-41), prioritize the newly
created document rule with the Reorder Rules action This step is optional.

Rules: Rules are applied to newly ingested documents in the order shown in the
Document Rules table. A document is not tested against the newly created document
rule if that document matches the conditions of a rule that has a higher priority.

Figure 6-41 Document Rules - Reorder Rules

In our example, we have document rules with unique criteria for the identification of files
(in other words, we do not have more that any one rule that can apply to a given file).


If you have various document rules and more than one rule can be true for a given file,
then the order of the rules is extremely important.
The order of the document rules can be changed by highlighting the appropriate rule and
the usage of the arrow keys to shift the rule up or down in the order (Figure 6-42).

Figure 6-42 Reorder Rules

8. In the Collection Properties window (Figure 6-43), choose if you want to apply the settings
to all documents, including those previously committed, by checking the appropriate box in
the top of the window. By default, policy changes only apply to documents that have not
yet been ingested.

Figure 6-43 Collection Properties - Document Retention - Save Document Rule Settings

Save the newly created document rules with the Apply button or click OK.


After you click Apply (if you want to create another document rule) or OK (if you want to
finish your work in this area), the File Archive Collection is being updated and you can see
the progress on the panel (Figure 6-44).

Figure 6-44 Progress information for update of document collection

Modifying the metafile schema
The metafile schema is a template that defines the metadata that can be associated with
documents in a collection. A user with the administrative role of Archive Administrator can add
custom fields, called user fields, to the metafile schema. We explain metafiles in more detail
in 6.2.3, “Metafiles” on page 175.

Attention: After a new field is added to metafile, the field settings cannot be modified and
the field cannot be deleted from the schema.

To modify the metafile schema, log on to the Information Archive GUI and complete the
following steps:
navigation tree.
4. Click the Metafile Configuration tab in the Collection Properties notebook.
5. In the Collection Properties window, in the right pane, click Select Action  Create Field
(Figure 6-45).

Figure 6-45 Collection Properties - Metafile Configuration - Select Action - Create Field

6. In the Create Metafile Field window (Figure 6-46), complete the form and click OK (if you
are only adding one field) or Add Another (if you need to add more metafile fields).


Figure 6-46 Create Metafile Field

After clicking OK, the newly created metafile fields are shown with the status of Pending in
the Collection Properties window (Figure 6-47).

Figure 6-47 Pending changes from the creation of new metafile fields (excerpt)

7. In the Collection Properties notebook, click OK or Apply to commit any changes. The
metafile configuration is updated and the update progress is shown (Figure 6-48).

Figure 6-48 Progress information for update of Metafile configuration

The Field Status of the newly created metafile fields is changed to Created, which
indicates that the fields were successfully added. The new fields are then shown in
alphabetical order in line with the already existing metafile fields (see Figure 6-49).

Figure 6-49 Finished changes from the creation of new metafile fields (excerpt)


6.4.4 Sharing directories and granting client nodes access
To grant a client node (NFS client) access to the File Archive Collection, you have to enable
the client node as an authorized host in the File Archive Collection. That can be realized
during the setup of the File Archive Collection or at any time with an administrative task.

Also, you can create and modify your own directories and any subdirectory with appropriate
user rights, which can be mounted by one or more client nodes. There are three ways to
create directories and subdirectories in general:
The root directory is always created during the initial setup of the File Archive Collection
and ready to use directly after finishing the setup.
Any other directory or subdirectory beside the root directory can be created within the
Information Archive by using the Information Archive administrative interface (Information
Archive GUI) and the appropriate procedure (see the following topics for details).
Any directory or subdirectory can also be created outside Information Archive with
ordinary operating system commands. You can use the Information Archive GUI to import
the relevant file system information for the directories created.

With the concept of various directories and user or client permissions, you can establish any
necessary environment to separate organization units and their data. For example, you can
create directories for each department in your organization with rigorous user restrictions and
share general directories between several departments. Also, you can create subdirectories
to separate the data and the access to data even more.

You cannot use the Information Archive administrative interface to delete a directory in a File
Archive Collection. You must delete a directory manually. For example, you can use the
operating system utilities on an NFS client to delete directories.

Attention: The appliance can share a maximum of 1000 directories. Of these directories,
500 can be shared using NFS and 500 can be shared using HTTP. For each shared
directory, a maximum of 50 hosts or users and groups can be granted remote access.

To share directories and grant access, log on to the administrative interface and complete the
following steps:
navigation tree.
4. Click the Directory Sharing tab in the Collection Properties notebook.
5. Select Action as Create Directory or Share Unlisted Directory (see Figure 6-50),
depending on your already existing environment:
– Choose Create Directory if you want to create an archive directory from the
Information Archive appliance.
– Choose Share Unlisted Directory if you want to import an archive directory, that was
created outside of the Information Archive appliance.


Figure 6-50 Collection Properties - Directory Sharing - Select Action

6. If you chose Create Directory in the previous dialog, in the Create Directory window, fill
out the fields for the directory name, user identification number, and group identification
number. Select appropriate directory permissions and proceed with the settings of remote
access (see Figure 6-51). You can repeat this action several times to allow remote access
for various host systems.

Figure 6-51 Directory Sharing - Create Directory

7. If you chose Share Unlisted Directory in the previous dialog, in the Share Unlisted
Directory window, fill in the name of an already existing directory into the directory name
field (see Figure 6-52) and click Import Directory Information.


Figure 6-52 Directory Sharing - Share Unlisted Directory

a. If the directory name is valid and the Information Archive appliance can read the
content and user rights, the appropriate fields for the user identification number (UID)
and group identification number (GID) are filled out automatically. That is a good
indication to proceed with the next step.
b. If the directory name is not valid, the Information Archive appliance issues an error
message. In this case, check that the directory name is correct. Do not proceed before
the fields for the user identification number (UID) and group identification number (GID)
are filled out automatically by the Information Archive appliance.
c. The next step is to validate the UID and GID, because the Information Archive
appliance might find some values, but they do not need to be correct in any case. If
applicable, correct the predefined input and proceed with the next step, that is, to
configure the necessary directory permissions.
d. Finally, you configure the remote access for a host by selecting the action of grant
access (see Figure 6-53). You can repeat this step several times to allow remote
access for various host systems.

Figure 6-53 Share Unlisted Directory - Select Action - Grant Access


8. In the Grant Access window (Figure 6-54), configure the host system that is allowed to
access the directory and decide on an access method for read and write actions.
When finished, click OK to close the window.

Figure 6-54 Grant access to directory for File Archive Collection

9. Back in the Create Directory window or the Share Unlisted Directory window, check that
every host that needs to have access is shown in the appropriate table and click OK to
proceed (Figure 6-55).

Figure 6-55 Remote Access - Different hosts configured

10.Back in the Collection Properties window (Figure 6-56), check the overall settings of the
newly created environment.

Figure 6-56 Collection Properties - New configuration must be committed


Click OK or Apply in the Collection Properties notebook to commit any changes. An
update progress is displayed as shown in Figure 6-57.

Figure 6-57 Progress of the update of the document collection after granting access

Viewing the mount information and HTTP access for a File Archive
Collection
This task requires an administrative user role of Archive Administrator.

Log on to the administrative interface and complete the following steps:
4. Click the General tab in the Collection Properties notebook.
5. View the collection address for each connection type (NFS, HTTP) in the Access
information field (see Figure 6-58).

Figure 6-58 Collection Properties - General - Access information for root directories

For all other directories, that is, for directories that are no root directories, you can find the
access information with the following procedure:

4. Click the Directory Sharing tab in the Collection Properties notebook.
5. View the collection address for each directory and subdirectory (see Figure 6-59), when
you click the appropriate highlighted path name in the Directory Sharing windows.


Figure 6-59 Directory Sharing - Access Information for directory

Mounting the NFS file system
For NFS access to the File Archive Collection, you have to mount the collection file system on
a client using the NFS version 3 protocol. To prevent time-out-related errors, it is better use a
hard NFS mount. Also, mount the metafile share in parallel, so that you or your application
can use the metafiles to set retention policies or send events.

Use the following procedure to mount the NFS file system and the metafile share from
Information Archive:
1. Get the mount information for the File Archive Collection, as described in “Viewing the
mount information and HTTP access for a File Archive Collection” on page 215.
2. Log on to the workstation, where you want to mount the NFS file system and the metafile
share.
Use the owner of the File Archive Collections or any authorized user account to log on.
The user must have access to the File Archive Collections, but also to the local
workstation where to mount the file system.
Validate the TCP/IP connection between the workstation and the NFS file system as well
as the metafile share. Because the NFS share and the metafile share reside on the same
cluster node, you only have to check the connection once.
We used the ping command as shown in Example 6-14 to simply validate the TCP/IP
connection from the local workstation to the remote File Archive Collections on Information
Archive.

Example 6-14 Output of ping command on Linux workstation (excerpt)
nunnemk@LDAP1:~> ping 9.153.1.49
PING 9.153.1.49 (9.153.1.49) 56(84) bytes of data.
64 bytes from 9.153.1.49: icmp_seq=1 ttl=64 time=0.136 ms
64 bytes from 9.153.1.49: icmp_seq=2 ttl=64 time=0.104 ms


Create a local mount point on your workstation to mount the remote NFS file system from
Information Archive. On a UNIX and Linux workstation, for example, you can use the mkdir
command to create appropriate directories. Also, you can change the access rights of
those directories with the chmod command.
In Example 6-15, we first want to see what the current directory is, therefore we use the
Linux command pwd on our system. In the example, our home directory /home/nunnemk
and the subdirectory data are taken as mount point in the next step.

Example 6-15 Output of print working directory (pwd) and list (ls) command on Linux workstation
nunnemk@LDAP1:~> pwd
/home/nunnemk

nunnemk@LDAP1:~> ls -la
total 120
drwxr-xr-x 9 nunnemk users 4096 2010-03-10 11:45 .
drwxr-xr-x 19 root root 4096 2010-02-23 02:28 ..
drwxr-xr-x 2 nunnemk users 4096 2010-03-10 11:28 data
drwx------ 5 nunnemk root 8192 2010-03-12 13:53 meta

3. Mount the remote NFS file system from Information Archive over the local mount point.
In Example 6-16 we mount the NFS file system over the formerly defined local file system.
Because this is only possible with root access on our Linux system, we run the command
sudo in front of our mount command. During the command processing we have to provide
the local root password.

Example 6-16 Mount command on local Linux workstation to mount NFS share
nunnemk@LDAP1:~> sudo mount -t nfs 9.153.1.49:/tiam/NFS1/data /home/nunnemk/data
root's password:

4. Create a local mount point on your workstation where to mount the remote metafile share
from Information Archive. This is the same procedure used before for the NFS share.
In Example 6-17, our home directory /home/nunnemk and the subdirectory meta are taken
as mount point in the next step.

Example 6-17 Output of print working directory (pwd) and list (ls) command on Linux workstation
nunnemk@LDAP1:~> ls -la
total 120
drwxr-xr-x 19 root root 4096 2010-02-23 02:28 ..
drwxr-xr-x 2 nunnemk users 4096 2010-03-10 11:28 data
drwx------ 5 nunnemk root 8192 2010-03-12 13:53 meta

5. Mount the metafile share on the local workstation.
In Example 6-18 we mount the remote Information Archive metafile share
(/meta/tiam/NFS1/meta) by NFS protocol over our local mount point (/home/nunnemk/meta)
so that we can access and use the metafiles from our workstation.

Example 6-18 Mount command on local Linux workstation to mount metafile share
nunnemk@LDAP1:~> sudo mount -t nfs 9.153.1.49:/meta/tiam/NFS1/meta /home/nunnemk/meta
root's password:


We validate the actual mount points on our local workstation (Example 6-19), and we see
the data share and the metafile share mounted on our local home directory.

Example 6-19 Validate mount of data share and metafile share on local Linux workstation
nunnemk@LDAP1:~> mount
9.153.1.49:/tiam/NFS1/data on /home/nunnemk/data type nfs (rw,addr=9.153.1.49)
9.153.1.49:/meta/tiam/NFS1/meta on /home/nunnemk/meta type nfs (rw,addr=9.153.1.49)

6. Create subdirectories, if necessary, within the mounted NFS file system of the File Archive
Collections. Also, set the correct user rights and access rights for the file system or the
creation of a file in the operating system. Use the regular operating system commands for
this task, that is, use the mkdir command and the chmod command on UNIX and Linux
workstations. See Example 6-20, where two subdirectories are created for use by the File
Archive Collection owner only (rwxr-xr-x).

Example 6-20 Subdirectories in the NFS share
nunnemk@LDAP1:~/data> pwd
/home/nunnemk/data
nunnemk@LDAP1:~/data> ls -la
total 36
drwx------ 5 nunnemk root 8192 2010-03-12 13:53 .
drwxrwxrwx 10 nunnemk users 4096 2010-03-23 13:43 ..
drwxr-xr-x 2 nunnemk users 8192 2010-03-10 11:02 directory1
drwxr-xr-x 2 nunnemk users 8192 2010-03-22 19:28 directory2

Directories: The creation of directories and subdirectories as shown here, outside of
Information Archive, is fully supported and functional. You can import the appropriate
information of such created directories later using the Directory Sharing panels in IA, so
that you can manage future access and permissions within IA. You might want to consider
this step right after the manual creation (see step 5 on page 211 for details).

6.4.5 Using the data share and the metafile share of a File Archive Collection
In this section we illustrate procedures that you can use to validate that the data share and
the metafile share are successfully mounted and ready to use.

Archiving data and validating successful creation in Information Archive
We perform the following steps:
1. We use the Linux command cp to copy three files to our share (see Example 6-21),
because our local workstation is Linux-based. The three files are intended to validate our
formerly created policies (see “Creating a document rule” on page 206) and therefore we
choose specific names and file types.

Example 6-21 Copy documents in the NFS file system
nunnemk@LDAP1:/tmp> ls -la
total 224
68 -r--r--r-- 1 nunnemk users 63801 2010-03-22 20:31 UPDATE-NOTES.en.html
64 -r--r--r-- 1 nunnemk users 61413 2010-03-22 20:31 UPDATE-NOTES.en.rtf
48 -r--r--r-- 1 nunnemk users 46674 2010-03-22 20:31 UPDATE-NOTES.en.txt

nunnemk@LDAP1:/tmp> cp UPDATE-NOTES.en.html /home/nunnemk/data/directory2
nunnemk@LDAP1:/tmp> cp UPDATE-NOTES.en.rtf /home/nunnemk/data/directory2
nunnemk@LDAP1:/tmp> cp UPDATE-NOTES.en.txt /home/nunnemk/data/directory2


When copying the three files into the NFS share (/home/nunnemk/data/directory2),
Information Archive creates automatically three metafiles, one for each of the files. Shortly
after the creation, the metafiles are not filled with any information but that coming directly
from the XML template (it is normal if you see an empty XML file). We use a HTTP web
browser to analyze the creation and the content of the metafiles (see Figure 6-60).

Figure 6-60 Metafile short after archiving process and before auto commit or manual commit

After the files are committed, the metafile is filled with the appropriate information. In our
configuration, the commitment takes place automatically after the file was idle for five
minutes. In your environment, depending on your overall setting within the Document
Actions, you might need to commit the files manually (see “Archive process with File
Archive Collections (NFS)” on page 169).
All system fields in the metafile are populated with the corresponding information as can
be seen in Figure 6-61. Again, we use our HTTP web browser to access the metafile.

Figure 6-61 Metafile 1 after archiving process and after auto commit or manual commit

We also check the correct application of the retention policies by looking at the metafiles.
Our retention policies (see “Creating a service class and a document rule” on page 204)
specify to keep plain text files for one year and rich text files for three years. That is
validated by Information Archive when committing the files, and the correct retention
periods and service classes are represented in the metafile.


See Figure 6-62 for a metafile that represents the three year retention period within our
service class SC_3Y_CR.

Figure 6-62 Metafile 2 after archiving process and after auto commit or manual commit

2. We validate the write process in the NFS file system with the Linux command ls
(Example 6-22).

Example 6-22 List documents in NFS file system
nunnemk@LDAP1:/tmp> cd /home/nunnemk/data/directory2
nunnemk@LDAP1:~/data/directory2> ls -la
total 192
drwx------ 5 nunnemk root 8192 2010-03-12 13:53 ..
-r--r--r-- 1 nunnemk users 63801 2010-03-22 17:28 UPDATE-NOTES.en.html
-r--r--r-- 1 nunnemk users 61413 2010-03-22 17:28 UPDATE-NOTES.en.rtf
-r--r--r-- 1 nunnemk users 46674 2010-03-22 17:28 UPDATE-NOTES.en.txt

3. We log on to Information Archive and validate the write process in the Information Archive
Tivoli Storage Manager server of this File Archive Collection.
To validate the existence of the files in Information Archive, we first analyze the available
storage pool volumes with the IBM Tivoli Storage Manager query volume command. In
Example 6-23, we see one storage pool volume, so our files must reside on that volume. If
you have more than one volume, the newest volume must contain the newest data. That is
not always the case, but it is a good starting point to check for the existence of your files.

Example 6-23 Query volume on IBM Tivoli Storage Manager server
tsm: NFS1>q vol

------------------------ ----------- ---------- --------- ----- --------
/tiam/NFS1/tsm/fileclas- FILEPOOL FILECLASS 2.0 G 0.1 Filling
s/00000002.BFS


The next step is to query the content of the formerly identified storage pool volume. In
Example 6-24 we use the IBM Tivoli Storage Manager query content command for that.

Example 6-24 Query content on the IBM Tivoli Storage Manager server (excerpt)
tsm: NFS1>q content /tiam/NFS1/tsm/fileclass/00000002.BFS

Node Name Type Filespace FSID Client's Name for File
Name
--------------- ---- ---------- ---- --------------------------------------
IA_RESERVED SpMg /tiam/NFS1 1 /data/directory2/UPDATE-NOTES.en.html
IA_RESERVED SpMg /tiam/NFS1 1 /data/directory2/UPDATE-NOTES.en.rtf
IA_RESERVED SpMg /tiam/NFS1 1 /data/directory2/UPDATE-NOTES.en.txt

The output confirms the existence of our three archived files in the storage pool volume.

Tip: In larger environments, it is more convenient to use SQL select statements to
validate the existence of your files in the Information Archive Tivoli Storage Manager
server.

A direct access to the information is given when using the file name within the select
statement (see Example 6-25). Obviously, for that command we have to know the name of
the file that we want to trace.

Example 6-25 IBM Tivoli Storage Manager data within space management
tsm: NFS1>
select * from spacemgfiles where file_name='/data/directory2/UPDATE-NOTES.en.txt'
FILESPACE_NAME: /tiam/NFS1
EXTOBJID: 0101020C000000001FAC0201AA16206E00BBC647CCE14E0A0F6BEBB6
OBJECT_ID: 5138
FILE_NAME: /data/directory2/UPDATE-NOTES.en.txt
INSERT_DATE: 2010-03-22 16:42:07.000000
DELETE_DATE:
CLASS_NAME: DEFAULT

Updating the metafile and send events to Information Archive
We follow these steps:
1. Validate that the meta file share is successfully mounted by issuing the ls command to list
our metafiles as shown in Example 6-26.

Example 6-26 Metafiles within the metafile share after mounting on local workstation
nunnemk@LDAP1:~> cd /home/nunnemk/meta
nunnemk@LDAP1:~/meta/directory2> ls -la
total 18
-rw-r--r-- 1 nunnemk users 335 2010-03-22 17:42 UPDATE-NOTES.en.html
-rw-r--r-- 1 nunnemk users 335 2010-03-22 17:42 UPDATE-NOTES.en.rtf
-rw-r--r-- 1 nunnemk users 335 2010-03-22 17:42 UPDATE-NOTES.en.txt


2. We update one of our metafiles with an appropriate XML-compatible application or file
editor, so that we have a user field and an event field beside the default system fields in
our metafile. In Example 6-27 we introduce a previously configured user field (Department)
and event (Hold) in the appropriate metafile (UPDATE-NOTES.en.txt) by editing the
metafile with the Linux text editor, edit.

Example 6-27 Input to the metafile for addition of a user field and an Hold event

<fields>

<_SYSTEM_minimumRetention_>Tue Mar 22 16:42:06 2011</_SYSTEM_minimumRetention_>
<_SYSTEM_serviceClass_>SC_1Y_CR</_SYSTEM_serviceClass_>
<_EVENT_hold_>LOA</_EVENT_hold_>

</fields>

The hold name can be any unique name that is no longer than 30 UTF-8 characters. In our
example we choose to name the hold event LOA, which is the abbreviation for a Letter Of
Acceptance.
We also used the Visual Editor (vi) successfully with another metafile.

Tip: Text editors that create additional files when saving changes cannot be used to edit
metafiles in the meta directory. For example, the GNOME gedit text editor creates a
hidden temporary file during save operations. To use one of these text editors, first copy
the metafile to another directory. Then you can modify and save the file before copying
it back to the meta directory.

In our testing we were not able to insert metafile fields that were not previously defined in
Information Archive. For example, we tried to insert a user field named UndefinedTag, but
we were not able then to save the metafile (see Figure 6-63). This is the expected
behavior. That is also true if you make a typing mistake during the update of the metafile.

Figure 6-63 Error from usage of not defined user fields with a metafile


3. To validate (verify) the update of the metafile with Information Archive, we use an HTTP
web browser to access the updated metafile (see Figure 6-64). In our case, we see the
user field and the result of our Hold event. The system has parsed the file already and the
event tag is not in the file anymore. However a system tag has been created in response,
indicating that the file is on hold with an event of LOA.

Figure 6-64 Metafile after manual update of the contents - Using metafile user fields

4. For a validation, the overall document statistics with Information Archive, we use the
Information Archive Collection Overview notepad after we made changes to the data
share and the metafile share. In Figure 6-65 you can see the retention hold on one of our
documents: that corresponds to the previously created hold on the file
UPDATE-NOTES.en.txt.

Figure 6-65 Collection Overview - Document statistics with Expired Documents


To validate that it is really the previously created hold on our newly ingested document, we
click the On hold hyperlink to get more details (see Figure 6-66).

Figure 6-66 Document Management - On hold

5. We update the metafile again, to send a Release event to Information Archive. This will
override the former Hold event. Make sure that you apply the release to the appropriate
hold event (indeed, you can have more than one hold event on the file), in our case named
LOA (Example 6-28).
Example 6-28 Input to the metafile for addition of an Release event

<fields>

<_EVENT_release_>LOA</_EVENT_release_>

</fields>

6. We validate the update of the metafile in the metafile share. In Linux, we use the less
command to see the contents of the metafile directly after we saved our changes
(Example 6-29).

Example 6-29 Metafile after manual update of the contents - Using event field with Release

<fields>


</fields>


7. We use the Information Archive Collection Overview notepad to see the overall statistics of
our File Archive Collections after the Release event. In Figure 6-67 you can see that no
retention hold is in place anymore.

Figure 6-67 Collection Overview - Document statistics without Expired Documents

Deleting expired documents from the File Archive Collection
To check for and delete expired documents in the collection, we proceed as follows:
1. We identify expired documents in our Information Archive using the Collections Overview.
If there are any documents listed as Expired, you can click the hyperlink and view the
details of the expired files in the Document Management tab (Figure 6-68).

Figure 6-68 Document Management - Expired files

Although we found three expired documents in our environment, we only want to delete
one of them. Hence, the following procedure shows only the deletion of that one file.
2. We access the NFS share from our local workstation. We issue the ls command to see
the expired documents, if any (see Example 6-30). We see a plain text file named
RELEASE-NOTES.en.txt, which we choose to delete.

Example 6-30 Expired files within the NFS share
total 18
-rw-r--r-- 1 nunnemk users 336 2010-03-10 11:07 RELEASE-NOTES.en.html
-rw-r--r-- 1 nunnemk users 336 2010-03-10 11:07 RELEASE-NOTES.en.rtf
-rw-r--r-- 1 nunnemk users 336 2010-03-10 11:17 RELEASE-NOTES.en.txt


First, we also access the metafile share to validate the existence of corresponding
metafiles for all our expired documents (Example 6-31).

Example 6-31 Metafiles for expired files within the metafile share
total 18
-rw-r--r-- 1 nunnemk users 336 2010-03-10 11:17 RELEASE-NOTES.en.txt

3. We delete only one of the expired files manually with the appropriate operating system
command. Here we use the Linux command rm (remove) for the removal (Example 6-32).

Example 6-32 Manual removal of expired files within NFS share
nunnemk@LDAP1:~/data/directory1> rm RELEASE-NOTES.en.txt
rm: remove write-protected regular file `RELEASE-NOTES.en.txt'? yes
nunnemk@LDAP1:~/data/directory1>

4. After the deletion of the document RELEASE-NOTES.en.txt in the NFS share, we change to
the metafile share and validate the existence of the related metafile. Metafiles are named
exactly like the original documents. In our example, the metafile is automatically deleted
by Information Archive following the deletion of the document in the NFS share
(Example 6-33).

Example 6-33 Metafile share after manual deletion of the document
total 17

Deleting metafiles: Metafiles are deleted automatically with the deletion of an archived
document. Archiving applications or users do not need to delete metafiles manually.

6.5 Archive applications supporting File Archive Collections
An external archive application must be configured to use the File Archive Collections as
storage device. For instance, you can use any archive appliance that leverages the NFS v3
protocol with the special archive functions of the File Archive Collection.

If the archiving application that you use to add documents to a File Archive Collection can
read and write XML files, the metafile created for each document can be used to trigger a set
of predefined document actions. For example, retention events can be signaled, and
document holds can be placed. If your application does not provide this support, you can use
the UNIX Visual Editor (vi) to work with metafiles.

Tip: For archive applications that are ready to use Information Archive, see the Tivoli Open
Process Automation Library (OPAL) web page (you can list them by “Information Archive”):
http://www-01.ibm.com/software/brandcatalog/portal/opal


7

Chapter 7. LDAP environments
In previous chapters we have mentioned the benefits of a centralized user management
infrastructure for the IBM Information Archive (Information Archive):
3.5.2, “Running the Initial Configuration Wizard (ICW)” on page 58
4.1.1, “User and group management” on page 72
6.4.3, “File Archive Collection administration” on page 204

There are also more and more applications, such as Filenet P8, which can be used with
Information Archive and which require or can take advantage of the Lightweight Directory
Access Protocol (LDAP) infrastructure. Not using the LDAP approach means that you have to
create the same user accounts (with the same configuration options such as uid, gid,
password) and repeat it for all the various servers and clients. This can be a maintenance
nightmare for large installations, especially if the security rules in your environment mandate
changing passwords on a regular basis.

In other words, local user management is probably acceptable and sustainable only for
organizations with a very small number of users and servers. Medium size and larger
organizations will want to use the LDAP for authentication in Information Archive, and this is
especially important for File Archive Collections.

In this chapter we illustrate, through practical scenarios, the configuration for three LDAP
implementations that are supported for use with Information Archive:
IBM Tivoli Directory Server configuration
Open LDAP configuration, SLES 10 in our example
Microsoft Active Directory configuration

Attention:
If you use File Archive Collections, you always have to configure the file system rights
within the shares as explained in 6.4.4, “Sharing directories and granting client nodes
access” on page 211, independently of the user management technique used.
There is also the possibility to use certificates for an encrypted communication. If your
company uses certificates for the communication already, the certificate administrator
will provide the certificate files and help you with your specific configuration. This topic
is, however, beyond the scope of this book.


7.1 Introduction to directories and LDAP
To improve functionality and ease-of-use, and to enable cost-effective administration of
distributed applications, information describing the various users, applications, files, printers,
and other resources accessible from a network is often collected into a special database that
is called a directory. LDAP is an IT standard that enables the use of such directories.

7.1.1 Directory components
A directory (in LDAP) contains a collection of objects organized in a tree structure. The LDAP
naming model defines how entries are identified and organized. Entries are organized in a
tree-like structure called the Directory Information Tree (DIT).

Entries are arranged within the DIT based on their distinguished name (DN). The DN is a
unique name that unambiguously identifies a single entry. DNs are made up of a sequence of
relative distinguished names, each of which corresponds to a branch in the DIT leading from
the root of the DIT to the directory entry. A DN is composed of a sequence of relative
distinguished names separated by commas, such as cn=thomas,ou=itso,o=ibm.

You can organize entries, for example, after organizations and within a single organization;
you can further split the tree into organizational units, and so on.

Attention: The syntax of the Distinguished Names (DN) differs between the various LDAP
implementations.

7.1.2 Directory and directory services
LDAP and Microsoft Active Directory are examples of popular technologies that support
centralized user management based on directories.

LDAP
Directories in LDAP are accessed using the client/server model. An application that wants to
read or write information in a directory does not access the directory directly, but uses a set of
programs or APIs that cause a message to be sent from one process to another. The second
process retrieves the information, on behalf of the first (client) application, and returns the
requested information if the client has permission to see the information. The format and
contents of the messages exchanged between client and server must adhere to an
agreed-upon protocol (LDAP conforms to RFC2307). There various LDAP implementations
available. The Information Archive appliance can use the IBM Tivoli Directory Server or the
Open LDAP based on Linux.

Microsoft Active Directory
Active Directory is an implementation of LDAP directory services by Microsoft for use
primarily in Windows environments. Information Archive supports Active Directory as well.


7.2 LDAP usage within Information Archive
LDAP can be used in two contexts with the Information Archive appliance:
The first possibility is to use LDAP to authenticate users (administrators) of the Information
Archive Administration GUI itself and give them the authorization to configure and operate
the Information Archive. This usage is described under 4.1.1, “User and group
management” on page 72. Note that in our scenarios, we did not use this capability.
The second possibility is to use an LDAP environment to authorize user access to File
Archive Collections. This allows the user or applications to access their data on the NFS
shares from Information Archive over the Ethernet network. For details, see 6.4.3, “File
Archive Collection administration” on page 204.

7.2.1 LDAP servers used in our scenarios
We have tested Information Archive with LDAP servers running on the following operating
systems:
IBM Tivoli Directory Server (ITSDS) on SLES 10
OpenLDAP on SLES 10
Active Directory with Windows Server 2003
Active Directory with Windows Server 2008 R2

Table 7-1 shows the IP addresses of the servers.

Table 7-1 IP Addresses of the LDAP servers used in our scenario
LDAP Server name IP address

IBM Tivoli Directory Server LDAP2-ITDS 9.153.1.98

OpenLDAP LDAP1 9.153.1.100

Windows Server 2003 Active Directory WINDC-W2K3 9.153.1.201

Windows Server 2008 R2Active Directory WINDC1 9.153.1.101

7.2.2 Names used in our scenarios
In our experiments with the various LDAP implementations, to make it easier for the reader,
we always used the same names for most LDAP elements such as domain names,
organizational unit names, user names and group names. We also used the same uid and
gid numbers on all LDAP implementations (in UNIX, the authentication and file access rights
are always based on uid and gid and not on user accounts).

As previously noted, in our scenarios, we did not use LDAP for the definition and
authentication of Information Archive administrative users (that is, those authorized to access
and use the Information Archive GUI); those were defined as local users (within Information
Archive). See 4.1.1, “User and group management” on page 72 to see how these accounts
are defined to administrate Information Archive.

Chapter 7. LDAP environments 229

Table 7-2 through Table 7-4 list the domain name, group name, and user names that we used
in our scenario.

Table 7-2 Domain name used in our scenario
Domain name

ArchiveSolutionCompetenceCenter.Leipzig.local

Table 7-3 Group names used in our scenario
Group name gid

ArchiveSolutionCompetenceCenter 10002

Table 7-4 User names used in our scenario
User User name uid

Frank Boerner boernerf 1005

Rene Wuellenweber wuellenw 1006

Roland Hoppe hoppe 1009

Daniel Wendler wendler 1021

Andreas Feldner feldner 1022

Kai Nunnemann nunnemk 1023

Administrator Administrator Not needed

In the following sections we show how to configure the various LDAP servers and explain the
dependencies from an Information Archive perspective, especially for the distinguished
names (DN). We do not explain the installation or basic setup of the LDAP servers.

7.3 Configuring Information Archive with IBM Tivoli Directory
Server
IBM Tivoli Directory Server is the IBM implementation of the LDAP for supported Windows,
IBM AIX®, Linux, Solaris, and HP-UX operating systems. IBM Tivoli Directory Server
provides a server that stores directory information using a DB2 database, a proxy server for
routing LDAP operations to other servers, a client, a graphical user interface (GUI) for
managing servers, and a GUI for managing users.


IBM Tivoli Directory Server offers a trusted identity data infrastructure for authentication in the
following ways:
It provides identity management for companies that want to deploy a robust and scalable
identity infrastructure.
It uses LDAP identity infrastructure software and meets LDAP v3 industry compliance
standards.
It enhances proxy server capabilities with flow control for managing requests and paging
search results for single and multiple partitions and a smart fail-back mechanism to
restore server safely.
It maintains high availability with master/subordinate and peer-to-peer replication
capabilities as well as scheduled online or offline backup and remote restore.
It supports virtual list views so that you can scroll forward or backward through entries in a
large sorted data set and can record deleted entries.
It supports leading platforms, including IBM AIX, IBM i5/OS®, IBM z/OS®, Sun Solaris,
Microsoft Windows Server, HP-UX, and SUSE and Red Hat Linux distributions.

We used SLES 10 as the operating system for our scenario.

7.3.1 Configuring the server instance
We explain here how to configure Tivoli Directory Server v6.2 installed on SLES10.

After IBM Tivoli Directory Server (ITDS) is installed under SLES10, you can find the required
configuration scripts in the /opt/IBM/ldap/V6.2/sbin directory. Figure 7-1 presents a listing of
the available scripts.

LDAP2-ITDS:/opt/IBM/ldap/V6.2/sbin # ls
32 ibmslapd idsdb2ldif idsideploy idssetport idsxinst
IDSProgRunner idsadduser idsdbback idsidrop idsslapd ldif
bulkload idsadscfg idsdbmaint idsilist idssnmp ldif2db
createuser idsadsrun idsdbmigr idsimigr idssupport ldtrc
db2ldif idsbulkload idsdbrestore idsldif2db idsucfgchglg migbkup
dbback idscfgchglg idsdiradm idslogmgmt idsucfgdb runstats
dbrestore idscfgdb idsdnpw idsperftune idsucfgsch slapd
ddsetup idscfgsch idsgendirksf idsrunstats idsucfgsuf
ibmdiradm idscfgsuf idsicrt idssethost idsxcfg
LDAP2-ITDS:/opt/IBM/ldap/V6.2/sbin #
Figure 7-1 Program files directory in ITDS

To configure ITDS, you essentially need idsxinst, which is the ITDS Instance Administration
Tool, and idsxcfg, which is the ITDS Configuration Tool.

1. Create at least one directory server instance in your environment. To create an instance,
launch the IBM Tivoli Directory Server Instance Administration Tool (Figure 7-2) by issuing
the ./idsxinst, command from the SLES10 command line (in the directory
/opt/IBM/ldap/V6.2/sbin).


Figure 7-2 ITDS Administration Tool

2. Click Create Instance. The Create new directory server dialog, shown in Figure 7-3 is
displayed. Here we chose to create the default instance. Click Next.

Figure 7-3 ITDS Administration Tool - Create an instance


3. Respond to the next dialog (Figure 7-4), which prompts you for various passwords
(User password, Encryption seed, Administrator DN) as required by ITDS.

Figure 7-4 ITDS Administration Tool - Password settings

4. Verify your settings and click Next to launch the creation of the directory server instance.
The Results panel shown in Figure 7-5 displays several messages indicating the progress
of the creation process. Click Close when finished.

Figure 7-5 ITDS Administration Tool - Create new directory server instance

In SLES 10, the ITDS server instance will not start automatically after a reboot of the
system.


5. Under the /etc/init.d directory, create the script idsldap (as listed in Figure 7-6) to
automate the start of the server instance upon reboot.

LDAP2-ITDS:/etc/init.d # cat idsldap
#!/bin/bash
# /etc/init.d/startLdap

touch /var/lock/startLdap

# carry out specific functions
case "$1" in
start)
echo "Starting itds 6.2 ldap."
/opt/ibm/ldap/V6.2/sbin/idsslapd -I dsrdbm01
;;
stop)
echo "Stopping itds 6.2 ldap."
/opt/ibm/ldap/V6.2/sbin/idsslapd -I dsrdbm01 -k
;;
*)
echo "Usage: /etc/init.d idsldap {start|stop}"
exit 1
;;
esac

exit 0
LDAP2-ITDS:/etc/init.d #
Figure 7-6 File /etc/init.d/idsldap

6. Enable the autostart of the ITDS instance after you have created the script. To enable
autostart, change to the directory /etc/init.d and issue the command chkconfig idsldap.
7. Launch the ITDS Administration tool again, by issuing the ./idsxinst command from the
/opt/IBM/ldap/V6.2/sbin directory. Now that the server instance is created, you can
perform additional configuration as required, using the ITDS Administration tool.

7.3.2 Configuring the LDAP objects
To configure the ITDS instance or to import LDAP Data Interchange Format (LDIF) files, the
ITDS instance must be stopped. Proceed as follows:
1. Click the Start/Stop button to stop the instance. The server instance that was previously
created is now visible in the ITDS Instance Administration Tool window (Figure 7-7).


Figure 7-7 ITDS Administration Tool - Default Instance Running

2. Click the Manage button to configure the instance. The Configuration Tool window opens
and displays the Overview tab as shown in Figure 7-8.

Figure 7-8 ITDS Configuration Tool - Overview

The left pane of the Configuration Tool window (Figure 7-8) contains a list of tasks.


The following actions are possible from the left pane of the Configuration Tool window:
– Change the administrator user or password.
– Perform database related tasks like backup and restore operations or tune the
database performance settings.
– Import existing LDAP Data Interchange Format (LDIF) files (contain the Object entries
of the LDAP tree). This Export/Import function can also be used to create a backup of
critical LDAP information.
For our example, we decided to import the users and other configuration objects from an
LDIF file. In Figure 7-10, you can see a portion of the LDIF file we used.
Before doing the LDIF import, we need to add the suffix for the Distinguished Name (DN)
structure, under the Manage suffixes tab.
For our scenario, we had to add the suffix c=local, which is the highest level in the
Distinguished Name (DN) for our domain name, ou=ArchiveSolutionCompetenceCenter,
o=Leipzig, c=local.
Figure 7-9 shows the content for the Manage suffixes tab after we added the c=local
suffix. Note that all other entries you see here are default and must not be deleted.

Figure 7-9 ITDS Configuration Tool - Manage suffixes

If you want to import an LDIF file as we did, it must have a format similar to that shown in
Figure 7-10 (the values associated to the tags will of course have to correspond to the
naming conventions adopted in your environment).

Important: Be sure to add the objectlass groupOfNames for group objects and
inetOrgPerson for user objects.


version: 1

dn: C=LOCAL
objectclass: top
objectclass: country
description: top domain
c: LOCAL

dn: o=Leipzig,c=local
objectClass: organization
objectClass: top
o: Leipzig

dn: ou=ArchiveSolutionCompetenceCenter,o=Leipzig,c=local
objectclass: top
objectclass: organizationalUnit
ou: ArchivesolutionCompetenceCenter

dn: cn=users,ou=ArchiveSolutionCompetenceCenter,o=Leipzig,c=local
objectclass: groupOfNames
objectclass: top
description: Users
cn: users
member:
cn=boernerf,cn=users,ou=ArchiveSolutionCompetenceCenter,o=Leipzig,c=local
.... (insert other users here as well)

dn: cn=groups,ou=ArchiveSolutionCompetenceCenter,o=Leipzig,c=local
objectclass: groupOfNames
objectclass: top
description: Leipzig Archive Solution Competence Center Team
cn: groups

dn: cn=boernerf,cn=users,ou=ArchiveSolutionCompetenceCenter,o=Leipzig,
c=local
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
sn: boernerf
cn: boernerf
gidNumber: 10002
homeDirectory: /home/boernerf
uid: boernerf
uidNumber: 1005
userPassword: password
Figure 7-10 ASCC.ldif file


3. To import this LDIF file, go to the LDIF Tasks, Import LDIF data tab, select the file to import
as shown in Figure 7-11, and click Import.

Figure 7-11 ITDS Configuration Tool - Import LDIF file

4. After the import has completed successfully, stop the administrative server and start the
ITDS instance in the ITDS Administration Tool main window.
5. To verify graphically that all configuration objects are inserted, use the ITDS Web
Administration Tool:
a. In SLES 10, to start the Administration Tool, first start a web server by changing to the
/opt/IBM/ldap/V6.2/idstools directory and entering ./deploy_IDSWebApp.
b. After the web server is started, you can open an Internet browser and access the ITDS
Web Administration Tool at:
http://localhost:12100/IDSWebApp/IDSjsp/Login.jsp
6. On the login panel for the ITDS Web Administration Tool (Figure 7-12), enter the
appropriate LDAP Server Name, User DN and Password. Be sure to prefix the user DN
name with cn=<administrator_name> as appropriate.


Figure 7-12 ITDS Web Administration Tool - Login panel

If the login is successful, the main window seen in Figure 7-13 displays.

Figure 7-13 ITDS Web Administration Tool - Main Window


7. To verify the entries, select the Directory management tab. Then, as shown in
Figure 7-14, you must see the same suffix entries as shown in Figure 7-9 on page 236.

Figure 7-14 ITDS Web Administration Tool - Directory management

8. Click the “+” sign to expand the directory tree, level by level, until you see the users
displayed. An example of our structure and users can be seen in Figure 7-15.

Figure 7-15 ITDS Web Administration Tool - Users

9. On the panel shown in Figure 7-16, which show the details for one of the users, verify the
settings and compare with the original LDIF file displayed in Figure 7-10 on page 237.


Figure 7-16 ITDS Web Administration Tool - details of a user

If all entries match, the LDAP server instance is now ready for use with Information
Archive. You can proceed to the next section.

7.3.3 Using the ITDS LDAP server from Information Archive
The LDAP server must be available and configured for IA, before you run the Information
Archive Initial Configuration Wizard (see 3.5.2, “Running the Initial Configuration Wizard
(ICW)” on page 58). You can verify that the LDAP server is available using the ldapsearch
command from the Management Console. Open a terminal window.

Following our scenario, the correct command is ldapsearch -x -h 9.153.1.98 -D
“cn=Administrator” -w password -b
“ou=ArchiveSolutionCompetenceCenter,o=Leipzig,c=local” -vv.

If the command was successful, you can run the Initial Configuration Wizard (ICW). The
correct values to enter there for our scenario are:
Search base for users and groups (base distinguished name):
dc=ArchiveSolutionsCompetenceCenter,dc=Leipzig,dc=local


Bind distinguished name:
cn=Administrator,cn=Users,dc=ArchiveSolutionsCompetenceCenter,dc=Leipzig,dc=loc
al

See 3.5.2, “Running the Initial Configuration Wizard (ICW)” on page 58 for details.

7.4 Tivoli Directory Services in IBM i
This section explains the Tivoli Directory Services implementation in an IBM i environment

When you install the IBM i operating system, an IBM Tivoli Directory Server is automatically
installed as well. All you then need to do is to configure and start it.

Very important: The instructions in this section are intended for systems where Tivoli
Directory Server has not been configured already. Following these instructions WILL
COMPLETELY WIPE OUT an existing LDAP configuration.

7.4.1 Basic configuration for IBM Tivoli Directory Server on IBM i
The basic configuration is done by IBM System i® Navigator. Follow these steps:
1. On a computer with System i Access for Windows installed, open the System i Navigator.
If necessary, connect to your IBM i system. Then expand Network  Servers  TCP/IP
in the left pane of the System i Navigator window. In the list of TCP/IP servers, right-click
IBM Tivoli Directory Server for i5/OS (Figure 7-17).
2. Select Reconfigure from the menu.

Figure 7-17 Tivoli Directory Server in System i Navigator


3. Mark the check box Delete current directory services configuration.

Very important: Be aware that the steps that follow WILL COMPLETELY WIPE OUT
your existing directory server configuration.

Click Next.
4. Mark the check boxes Directory server configuration and Directory server contents
(as shown in Figure 7-18). Click Next.

Figure 7-18 Reconfigure Tivoli Directory Server, delete configuration

5. In the Specify Settings window shown in Figure 7-19, select No and click Next.

Figure 7-19 Specify Settings - Not default settings for LDAP configuration

6. In the next dialog, leave the defaults for library and log settings, and click Next.
7. In the next dialog, leave the default for disk pool, and click Next.


8. In the Specify Administrator dialog, uncheck the System generated box and enter a
Password for the Administrator DN (Distinguished Name). Leave the default for the
administrator’s distinguished name itself, that is, cn=administrator (see Figure 7-20).
Click Next.

Figure 7-20 Administrator Distinguished Name for Tivoli Directory Server Administrator

The system generates a suffix based on the system’s name and TCP/IP domain.
9. To remove that suffix, select the suffix, then click Remove. Add a new suffix that matches
your LDAP structure, by typing the new suffix in the single entry line labeled Suffix
(Figure 7-21), and click Add.

Figure 7-21 LDAP Suffix

The newly added suffix is displayed in the list box. Click Next.
10.Leave the defaults for ports (unless you have a requirement to change them due to
network issues). Click Next.
11.Leave the default to use all TCP/IP addresses (unless you have a requirement to change
them due to network issues). Click Next.


12.To start the Tivoli Directory Server automatically after an IPL (when TCP/IP is started),
select Yes in the appropriate window (see Figure 7-22) and proceed with Next.

Figure 7-22 Automatically start Tivoli Directory Server with TCP/IP

13.Check your settings on the summary and click Finish.
The configuration task will take a moment.
14.After the configuration is finished, click Properties of IBM Tivoli Directory Server in the
System i Navigator main window.
15.In the Properties window, select the second tab, Database/Suffixes, and verify that your
previously configured LDAP suffix is displayed correctly (see Figure 7-23).

Figure 7-23 Tivoli Directory Server Properties


7.4.2 Starting and stopping the Tivoli Directory Server
You can start or stop the Tivoli Directory Server through the context menu (mouse right-click)
in the System i Navigator. Alternatively, you can issue a command in a 5250 session
(STRTCPSVR or ENDTCPSVR).

To proceed with the following steps, we assume that your Tivoli Directory Server is stopped.
Use one of the foregoing methods to stop the server, if applicable.

7.4.3 Populating the LDAP directory
You can import an LDAP Data Interchange Format (LDIF) file containing LDAP directory data
using the System i Navigator interface.

Right-click the IBM Tivoli Directory Server entry, then select Tools and then Import File. The
Tivoli Directory Server must be stopped, otherwise this option is greyed out. The LDIF file to
be imported needs to first be transferred to the IBM i IFS (using FTP or a NetServer share on
IBM i).

LDIF: We noticed that the import of an LDIF file can be an extremely long running process
even with only a few records in the LDIF file.

Another way to import data and work with the Tivoli Directory Server is to use a generic LDAP
browser. This can be a much quicker process and even more convenient depending on the
LDAP browser used.

There is a Java-based open-source tool that is very powerful and intuitive, called JXplorer.
We use this tool as an alternative import of LDIF files in our environment. See the website:
http://www.jxplorer.org

The easiest way to install the tool is to download the ...deploy.zip or ...deploy.tar.bz2 file
directly from the website:
http://sourceforge.net/projects/jxplorer/files/

Unpack it, and execute the .bat or .sh files to start it.

To configure and use a connection in JXplorer, follow this procedure:
1. Start the JXplorer after you have successfully installed the software.
2. In the JXplorer window, from the File Menu, select Connect.
3. In the Open LDAP/DSML Connection window (see Figure 7-24), use the following settings
to establish a connection to your Tivoli Directory Server on IBM i:
– Host is your IBM i TCP/IP host name or IP address, Port is 389 unless you changed it
during base configuration.
– Protocol is LDAP v3.
– Base DN is the suffix you created during the base configuration.
– Security Level is User + Password, you can select that from the pull-down-menu.
– User DN is the Administrator Distinguished Name that you created during the previous
base configuration.
– Password is also configured during the base configuration.
Make sure to save your connection configuration by clicking the Save button: That will help
you in the future to establish the connection without retyping everything.


Figure 7-24 shows the Open LDAP/DSML Connection window.

Figure 7-24 JXplorer connection settings in Open LDAP/DSML Connection window

4. On the Open LDAP/DSML Connection window, click OK. This will connect you to the Tivoli
Directory Server on IBM i.
When connected to the Tivoli Directory Server on IBM i, in the JXplorer window left pane,
at the Explore tab, under World, you can see the expanded LDAP suffix that was created
by the previous base configuration (Figure 7-25).

Figure 7-25 JXplorer LDAP view


5. In the menu bar under Tools, use the Import File option to import an LDIF file. Note that
the Tivoli Directory Server needs to be started for this work (contrary to the Import File
option of System i Navigator).

Attention: The import of the LDIF file with the JXplorer is an alternative method to the
native LDIF import through the IBM Tivoli Directory Server for IBM i. Therefore, only
import the file, if you have not already done it before.

7.4.4 Using the IBM Tivoli Directory Server on IBM i with Information Archive
Before you run the Initial Configuration Wizard to create a File Archive Collection on the
Information Archive appliance, make sure that you have the IBM Tivoli Director server on
IBM i and LDAP running.

Verify that the LDAP server is available by using the ldapsearch command from the
Information Archive Management Console.

Following our previous setup, the correct command in our environment is:
ldapsearch -x -h 9.153.1.30 -D “cn=administrator” -w password -b
“dc=stgt,dc=spc,dc=ihost,dc=com” -vv.

If this test was successful, you can run the Initial Configuration Wizard (ICW) on Information
Archive. The correct values to be entered there for our scenario are as follows:
dc=stgt,dc=spc,dc=ihost,dc=com
cn=administrator,dc=stgt,dc=spc,dc=ihost,dc=com

See 3.5.3, “Assigning administrative user roles” on page 67 for details.


7.5 Configuring Information Archive with OpenLDAP
Here we describe how to configure the SLES 10 LDAP server for use with Information
Archive. We used the same naming as described in “Names used in our scenarios” on
page 229.

We use YaST to do the configuration. Proceed as follows:
1. For a graphical version, log on to your system as root, and run yast2 in a graphical
session. The YaST Control Center shown in Figure 7-26 is displayed.

Figure 7-26 SLES 10 - YaST Control Center

2. Click Group Management or User Management, The LDAP server logon dialog shown in
Figure 7-27 is displayed. You have to log on as the LDAP server administrator account.

Figure 7-27 Log on to the LDAP Server


3. Click OK to get the User and Group Administration window shown in Figure 7-28. Here,
you can add/change/delete users and groups.
We selected Groups first and created a group that we use with Information Archive later
on. Create additional groups if you need to.

Figure 7-28 Group Administration View


4. Select the Users radio button after you are done creating your groups, to see all
configured users there. Now you can add or change your users as required in the context
of Information Archive. The Users view (for our scenario) is shown in Figure 7-29.

Figure 7-29 User Administration View

Click Edit to view the details for the selected users, as shown in Figure 7-30.

Figure 7-30 User properties - User Data Tab


5. Select the Details tab (Figure 7-31). Note here the uid and make sure that the user
belongs to the required group for Information Archive (under LDAP groups). You need at
least one group that you have to use as default group for the user accounts.

Figure 7-31 User properties- Details tab

We used the user account Administrator to create the connection from Information Archive
to the LDAP server on SLES 10. You have to use the distinguished names in Information
Archive exactly as displayed in Figure 7-27 on page 249, in our example, Administrator:
cn=Adminstrator,dc=ArchiveSolutionCompetenceCenter,dc=Leipzig,dc=local

7.5.2 Using the OpenLDAP server from Information Archive
Before you can run the Initial Configuration Wizard on the Information Archive appliance, you
need to verify that the LDAP server. For that, use the ldapsearch command in a terminal
window at the Management Console.

Following our scenario, the correct command is:
ldapsearch -x -h 9.153.1.100 -D
“cn=Administrator,dc=ArchiveSolutionCompetenceCenter,dc=Leipzig,dc=local” -w
password -b
“cn=Administrator,dc=ArchiveSolutionCompetenceCenter,dc=Leipzig,dc=local” -vv

If this test was successful, you can run the Initial Configuration Wizard (ICW).

The correct values to enter there for our scenario are as follows:
cn=Administrator,dc=ArchiveSolutionsCompetenceCenter,dc=Leipzig,dc=local


7.6 Configuring Information Archive with Microsoft Active
Directory
In this section we explain how to configure Microsoft Active Directory for use with Information
Archive. In our scenario, we used a domain with two domain controllers.

7.6.1 Preparing Microsoft Active Directory
First, let us review the settings required on the AD server (domain controller) to support the
Information Archive environment.

Identity Management for UNIX makes it easy to integrate computers running Windows into an
existing UNIX environment. Active Directory network administrators can use Server for NIS to
manage Network Information Service (NIS) domains, and Password Synchronization
automatically synchronizes passwords between Windows and UNIX operating systems.

With minor differences, Identity Management for UNIX is compliant with the Internet
Engineering Task Force (IETF) standard Request for Comments (RFC) 2307, meaning that
network passwords and NIS attributes can be resolved by LDAP.

Enabling Identity Management for UNIX in Windows Server 2003
Because Information Archive, a UNIX-based system, will use Active Directory for user
authentication, you need to make sure that the Identity Management for UNIX component is
installed as part of the Active Directory Services.

On the Windows Server 2003 Domain Controller, you need to install the Microsoft Windows
Services for UNIX, also known as UNIX Tools 3.5.
On a Windows Server 2003 R2 Domain Controller, enable Identity Management for UNIX by
going to the Control Panel, and selecting Add/Remove Programs  Add Windows
Components  Active Directory Service. Check Identity Management for UNIX, as
shown in Figure 7-32.

Note that this requires a reboot and Schema Admin privileges. It will add a UNIX Properties
tab to each user account in AD Users and Computers that will allow you to control the user
UID, primary group GID, NIS Server setting, and user shell settings (such as /bin/bash).


Figure 7-32 Windows Server 2003 R2 - install Identity Management for UNIX

Enabling Identity Management for UNIX in Windows Server 2008
In Windows Server 2008, you have to use the Server Manager (as shown in Figure 7-33) to
add the Microsoft Identity Management for UNIX.

Figure 7-33 Windows Server 2008 - Server Manager


If you do not have the role Identity Management for UNIX already installed, click Add Role.
You have to select the role Identity Management for UNIX, which requires Schema Admin
privileges. Click Finish to install the new filesets and add the UNIX Properties tab to each
user account in Active Directory Users and Computers that will allow you to control the user
UID, primary group GID, NIS Server setting, and user shell settings (such as /bin/bash).

Figure 7-34 Windows Server 2008 - Server Manager - Role Services

After your Active Directory environment has been prepared as previously described, you can
start creating accounts.

Creating an LDAP Bind Account
Active Directory is an implementation of LDAP directory services for use primarily in Windows
environments. You need to create an account in Active Directory that will be used to bind to
Active Directory for LDAP queries. This account does not need any special privileges; in fact,
making the account a member of Domain Guests and not a member of Domain Users is fine.
This helps minimize any potential security risks as a result of this account.

Bind DN: To be consistent with the other LDAP implementations in our scenario, we used
the predefined Administrator account as the bind distinguished name (bind DN).

We used the same names as described in “Names used in our scenarios” on page 229.


Preparing Active Directory accounts
Each Active Directory account that will authenticate from Linux (as is the case with
Information Archive) must be configured with a UID and other specific UNIX attributes. To
configure those attributes, select the UNIX Attributes tab in the properties dialog box of a user
account. (Installing the Identity Management for UNIX component enables this, as mentioned
before. Be sure to set login shell, home directory, UID, and primary UNIX group ID.

We created an OU structure for our domain as an example. Within various OUs, you can
delegate rights and configure unique group policies for objects within one OU; for example,
users or computers, that get the same rules.

Active Directory: The OU structure, delegation, and group policy structure/settings are
part of the Active Directory design process. See the Active Directory Design Guide for
more information:
http://download.microsoft.com/download/f/6/a/f6acc021-a05a-48a1-88e2-bc64ec0455
d6/ACTIVE%20DIRECTORY%20DESIGN%20AND%20MIGRATION/Active%20Directory%20Design%20
Guide.pdf

Figure 7-35 Active Directory Organizational Units (OU) structure


Next we create a group for use with Information Archive (Figure 7-36). It is important when
defining user and group accounts to always fill out the UNIX Attribute tab very carefully and
write down the UIDs and GIDs specified.

Figure 7-36 Group properties in AD

Based on the domain name, you can see the NIS Domain name in the UNIX Attributes tab.
Then, specify the GID, as shown in Figure 7-37.

Figure 7-37 Group properties in AD - UNIX Attributes tab


Next you can create all the user accounts that you need for use with Information Archive (or
you can just set the UNIX Attributes if you want to use existing users). Add a new user or
double-click an existing one to open the user properties panel shown in Figure 7-38.

Minimally, you must specify the values shown for the General tab in Figure 7-38; Account tab,
in Figure 7-39; and UNIX attributes tab, in Figure 7-40.

Figure 7-38 User properties in AD - General tab

Figure 7-39 User properties in AD - Account tab


Figure 7-40 User properties in AD - UNIX Attributes tab

We used the predefined user account Administrator to create the connection from Information
Archive to the Microsoft Active Directory.

7.6.3 Using the Active Directory server from Information Archive
Before you run the Initial Configuration Wizard on the Information Archive appliance, you
must verify that the LDAP server is available using the ldapsearch command from the
Management Console.

Following our scenario, the correct command is
ldapsearch -b “DC=ArchiveSolutionCompetenceCenter,DC=Leipzig,DC=local” -x -h
9.153.1.101 -p 389 -D
“cn=Administrator,cn=Users,dc=ArchiveSolutionCompetenceCenter,dc=Leipzig,dc=local”
-w password -v.

If the test was successful, you can run the Initial Configuration Wizard (ICW). The correct
values to enter there for our scenario are as follows:
cn=Administrator,cn=Users,dc=ArchiveSolutionsCompetenceCenter,dc=Leipzig,
dc=local

Important: Setting permissions and ownership at the file system level for the File Archive
Collection in Information Archive must always be done, regardless of the authentication
method.


8

Chapter 8. Integrating IBM Information
Archive with archiving
applications
Documents can be archived in IBM Information Archive (Information Archive) and retrieved by
a wide range of software applications or directly by an administrator or end user.

The IBM software portfolio already offers various products that can be used with Information
Archive. Also, native IBM systems are able to connect to Information Archive and to provide
basic archive and retrieve functions.

In this chapter we illustrate the integration of some of those IBM software products with the
Information Archive appliance. The integration works differently for System Storage Archive
Manager Collections than for File Archive Collections, and we explain both types.

We discuss the following scenarios:
System Storage Archive Manager-based integration:
– System Storage Archive Manager/Tivoli Storage Manager backup-archive client
– System Storage Archive Manager/Tivoli Storage Manager API client
– IBM Content Manager
– IBM FileNet P8
File Archive-based integration: IBM i (native)


8.1 IBM Enterprise Content Management portfolio
Products offered through the IBM Enterprise Content Management (ECM) portfolio can be
configured or integrated with Information Archive. The IBM ECM suite of products manages
content and core business process, and helps ensure compliance while integrating with
existing applications and infrastructure. They integrate and deliver critical business
information when and where it is needed, in context, and under control.

The following key products are offered within the IBM Enterprise Content Management
portfolio:
IBM OmniFind® Enterprise Edition: Provides secure enterprise search among multiple
repositories. It improves the productivity of knowledge workers and maximize the value of
portals and collaboration investments.
CommonStore for Lotus Domino, CommonStore for Exchange Server, and CommonStore
for SAP: Provides email management, including archive, search, and retrieval. Email
management also includes email attachments management. CommonStore for SAP
archives and manages SAP operational data to improve storage management and assist
with compliance regulations.
IBM Content Manager: Provides a content management solution for multiple platforms
including IBM System z®. It offers content integration, collaboration, and content
management services.
FileNet Content Manager: Provide a comprehensive, scalable, and secure content
management system that supports multiple platforms. FileNet Content Manager is the
core content management solution for the IBM FileNet P8 platform. It offers content
federation, collaboration and business content services, DITA, and XML authoring.
Content Manager OnDemand: Provides efficient enterprise report management, including
archive, search, and retrieve. CM OnDemand captures and archives computer output and
archives scanned documents. It integrates with FileNet P8 platform.
Document Manager: Manages the complete life cycle of business documents, including
check-in, check-out, and version control. They are usually used by engineering firms with
complex design documents that go through multiple review and revision cycles.
IBM Records Manager and FileNet Records Manager: Enable organizations to securely
capture, declare, classify, store, and dispose of both electronic and physical records, to
help ensure legal, regulatory, and industry compliance. IBM Records Manager provides
the records management engine that can be embedded in the existing business
applications.
FileNet Business Process Manager: Automates, streamlines, and optimizes critical
business processes by managing the flow of work between people and systems.
FileNet Image Manager Active Edition: Provides comprehensive image management that
includes high volume capturing of paper documents as images, as well as search and
retrieval of the images.

IBM ECM solutions provide the repository back-end services necessary to address an
enterprise content management. It is common to use several products together in an
enterprise-wide solution. For example, IBM Records Manager might be used together with
IBM Content Manager or Content Manager OnDemand to provide the records management
capability to the Content Manager or Content Manager OnDemand solutions.


Because this chapter addresses the usage of the System Storage Archive Manager Server, in
this section, we introduce the following IBM ECM products, which provide the core enterprise
content repositories that interface with System Storage Archive Manager Server:
IBM Content Manager
IBM Content Manager OnDemand
IBM FileNet Content Manager
IBM FileNet Image Manager Active Edition

In addition, we also introduce the IBM FileNet P8 family of products.

More information about the IBM Enterprise Content Management portfolio of products is
available at:
http://www.ibm.com/software/data/cm/

8.1.1 IBM Content Manager
IBM Content Manager Enterprise Edition version 8.4 is a scalable Enterprise Content
Management (ECM) solution that enables users to leverage all of their digital information for
maximum impact. From multimedia to text, Content Manager supports a range of information
formats and makes content available across multiple applications and workgroups. With
full-text search capabilities for both metadata and text-based documents, Content Manager
allows users to easily locate pertinent information.

Content Manager uses a powerful relational database to provide indexed search, security,
and granular access control at the individual content item level.

A Content Manager solution consists of one Library Server, and one to many Resource
Managers. The Library Server responds to user queries, while the Resource Managers
maintain collections of content. Figure 8-1 shows how Content Manager system components
interface with Information Archive.

IBM DB2 Content Manager

Content Manager
Library Server

Content Manager Content Manager
Resource Manager 1 Resource Manager N

TSM API TSM API


Figure 8-1 IBM Content Manager and Information Archive

Chapter 8. Integrating IBM Information Archive with archiving applications 263

Content that Content Manager supports includes HTML and XML web content, document
images, electronic office documents, printed output, audio, and video. Content Manager
provides the content infrastructure (acting as the back-end content repository) for solutions
such as compliance in a regulated life sciences environment, records management,
document life cycle management, IBM Lotus Notes® email management, Exchange Server
email management, and digital media and web content management.

8.1.2 IBM Content Manager OnDemand
IBM Content Manager OnDemand is a high-performance repository optimized for managing
computer output. Content Manager OnDemand provides a highly reliable and flexible system
to meet data archive and retrieval requirements. It can store and index about two million
pages per hour, which is the performance demanded by high-volume billing or statement
processing applications. OnDemand transforms any type of print output format, such as
invoices, customer statements, bills, reports, and check images, into searchable,
web-integrated, electronic content that can be deployed in a variety of ways to meet
customers’ requirements and resolve their problems.

One of the key strengths of OnDemand is its ability to directly archive computer print data
streams. OnDemand is optimized to capture, search, present, and manage large collections
of small objects, such as statements or bills.

An OnDemand solution consists of one Library Server and one or more Object Servers. The
Library Server stores data indexes and the Object Servers store data objects. Object Servers
can be local or remote. Each Object Server can have Tivoli Storage Manager connected to
manage long-term archival to other magnetic, optical, and storage. The OnDemand Object
Server communicates with the Tivoli Storage Manager server through the Tivoli Storage
Manager API. Figure 8-2 shows how the Content Manager OnDemand components interface
with Information Archive.

IBM Content Manager OnDemand Content Manager
OnDemand
Library Server

Content Manager Content Manager
OnDemand OnDemand
Object Serv er 1 Object Serv er N

TSM API TSM API


Figure 8-2 Content Manager OnDemand Object Servers interfacing with Information Archive


8.1.3 IBM FileNet P8 Platform
IBM FileNet P8 Platform is a next-generation, unified enterprise foundation for the integrated
IBM FileNet P8 products. It combines the enterprise content management, comprehensive
business process management, and extensive compliance capabilities to address a wide
range of content-related business requirements. The FileNet P8 family of products, also part
of the IBM ECM portfolio, includes back-end services, development tools, and applications
that address enterprise content and process management requirements. IBM FileNet Content
Manager is one of the core products in the FileNet P8 family.

IBM FileNet Content Manager provides full content life cycle and extensive document
management capabilities for digital content. It combines document management with
workflow and process capabilities to automate and drive content-related tasks and activities.

FileNet Content Manager streamlines document management tasks by providing content
versioning and parent-child capabilities, approval workflows, and integrated publishing
support. It delivers the ability to actively manage content across the enterprise regardless of
what repository it resides in, using FileNet Content Federation Services.

FileNet Content Manager consists of a Content Engine and one to many object stores
(among other components). At the core of the Content Engine are repository services for
capturing, managing, and storing business related digital assets. Multiple repositories, called
object stores, can be created and managed within a single system to serve the business
requirements. Object stores can be configured to store content in a database, a file system, a
fixed content device, or a combination of these options. An object store is capable of storing a
variety of business-related data, for example, an insurance claim, a customer loan account, or
information about Business Partners. It can also store any type of structured or unstructured
content such as XML documents, web pages, photos, voice data, images, process definitions,
and templates. Figure 8-3 shows how object stores interface with the Information Archive
Machine Type 2231-IA3.

IBM FileNet P8 - Content Manager FileNet Content
Manager
Content Engine

FileNet Content FileNet Content
Manager
Object Store 1 Manager
Object Store N

TSM API TSM API


Figure 8-3 FileNet Content Manager object stores interfacing with Tivoli Storage Manager


8.2 System Storage Archive Manager-based Integration with
Information Archive
System Storage Archive Manager Collections are described in Chapter 5, “System Storage
Archive Manager Collections” on page 115. Here we show usage examples of System
Storage Archive Manager Collections to give you a practical understanding of how the
integration with Information Archive System Storage Archive Manager Collections works.

There are two basic possibilities for exploring archive retention features with System Storage
Archive Manager Collections. The first is by using the Tivoli Storage Manager backup-archive
client, which can be launched remotely or directly from the client machine. Alternatively, you
can use the Tivoli Storage Manager API that comes with a sample application called dapismp.
We discuss and illustrate both methods in the remainder of this section.

8.2.1 Integrating IBM Tivoli Storage Manager backup-archive client with a
System Storage Archive Manager Collection
The System Storage Archive Manager/Tivoli Storage Manager backup-archive client
component sends data to, and retrieves data from, a System Storage Archive Manager
server. The System Storage Archive Manager/Tivoli Storage Manager client must be installed
on every machine that will transfer data to server-managed storage. The Information Archive
System Storage Archive Manager server uses a unique node name to identify each client
instance. A password can be used to authenticate communications between the System
Storage Archive Manager/Tivoli Storage Manager client and server. Data can be recovered
from the same client machine that initially transferred it, or to another client with a compatible
file system format.

The backup-archive client basically consists of the software component and a customization
file. This customization file, called the client options file (dsm.opt), specifies client/server
communications parameters and other System Storage Archive Manager/Tivoli Storage
Manager client settings. Client communications parameters must agree with those specified
in the server options file. The client options file is located in the client directory and can be
modified using a text editor.

The backup-archive client allows archiving data to a System Storage Archive Manager. This
will only be possible if you have enabled the client for archive retention protection in the
dsm.opt file. If you do not, then the client rejects to archive or retrieve (Figure 8-4).

Figure 8-4 Trying to archive data without backup-archive client enablement

After being enabled for data retention, the backup-archive client can no longer be used for
backups. You can only archive data (not backup) when connecting to an IBM System Storage
Archive Manager.


Tip: You can use various stanzas in the dsm.opt file together with appropriate environment
variables, corresponding dsm.sys files, or start commands to enable a backup-archive
client to communicate with various IBM System Storage Archive Manager and IBM Tivoli
Storage Manager servers. Therefore, the same backup-archive client can be used with
Information Archive, IBM DR550, and additional IBM Tivoli Storage Manager servers.

In the sections that follow, we explain how to install, configure, and use the backup-archive
client for archive retention and protection. The example applies to Microsoft Windows
environments.

Installing and configuring IBM Tivoli Storage Manager Backup-Archive
Client V6 for Data Retention
Use the following procedure to download and configure the backup-archive client:
1. Download the IBM Tivoli Storage Manager Client V6.1 or later version. You can retrieve
the current maintenance levels of the software from the IBM Support Portal at:
http://www.ibm.com/support/entry/portal/
Download the self-extracting executable client code. See the readme file
(6.1.3.0-TIV-TSMBAC-WinX32-README.FTP) in the same directory; for example, the
code to download might be a file named 6.1.3.0-TIV-TSMBAC-WinX32.exe.
2. Start the installation by extracting the client code in 6.1.3.0-TIV-TSMBAC-WinX32.exe.
3. In the first window (Location to Save Files), choose a folder where the client software can
be unpacked. In our case, it is done in c:tsm_imagesTSM_BA_CLIENT. Click Next.
The install wizard extracts all the files into the specified directory.
4. After the install wizard has completed the extraction, the setup wizard starts executing. In
the Choose Setup Language window, choose your language, such as English (United
States), and click OK.
5. In the Welcome to the Install Wizard window, click Next.
6. In the Destination Folder window, select the installation folder, such as C:Program
FilesTivolitsm, and then click Next.
7. In the Setup Type window, leave the default setting as Typical and click Next.
8. In the Ready to Install the Program window, click Install. The InstallShield Wizard starts
installing the software.
9. When the InstallShield Wizard Completed window opens, check that the installation is
successful, and click Finish. If the install failed, correct the problem and repeat the
installation.
10.If there is no dsm.opt file in the backup-archive client installation folder, copy the dsm.smp
file from the C:Program FilesTivolitsmconfig directory to the backup-archive client
installation folder and rename the sample option file from dsm.smp to dsm.opt.
11.Edit the dsm.opt file within the backup-archive client installation folder (Figure 8-5). Set the
following parameters:
– tcpserveraddress <tcpip_server_address> (TCP/IP Address of the System Storage
Archive Manager server)
– commethod tcpip
– tcpport <port_number> (TCP/IP port number of System Storage Archive Manager
server, that is, 1501)


– nodename <node_name>
– enablearchiveretentionprotection yes
– passwordaccess generate
Save the file.

Figure 8-5 Example of a dsm.opt file

If you configure wrong TCP/IP settings, or the connection to Information Archive is
interrupted, then the backup-archive client will reject the session with an appropriate error
message (Figure 8-6). In this case, check the correct settings and also the connection to your
Information Archive. You can use the ping command for that purpose.

Figure 8-6 Errors from wrong IBM Tivoli Storage Manager backup-client setup

Backup-archive client interfaces
The IBM Tivoli Storage Manager backup-archive client is installed with three unique user
interfaces. All three interfaces provide the basic functions of archive and retrieve.

There is a command-line client (dsmc) that can also be used to run the archive and retrieve in
batch-mode. Another interface is the local installed Graphical User Interface (GUI), a more
convenient type of client with graphical output. The third interface is provided over HTTP and
can be accessed with a regular web-browser. That interface is called the web client and it
provides almost the same graphical output than the GUI.

Client interfaces: All three IBM Tivoli Storage Manager client interfaces provide the basic
functions of archive and retrieve. The usage of events with an event-based archive copy
group, as well as sending a Hold and Release, is only available with the command-line
client and the web client. The BA Client GUI does not provide functions to send events,
Holds, and Releases.

You need to set up remote access functions in order to access the web client. The BA
command-line client and the BA Client GUI can be used without further configuration, if you
had already set up your dsm.opt file as previously described.


Next, we show how to configure the web client access using two methods:
Installation of the web client through the GUI
Installation of the web client at the command-line

Installation of the web client through the GUI
You must have installed and configured the native backup-archive client before you can start
this procedure, as indicated in “Installing and configuring IBM Tivoli Storage Manager
Backup-Archive Client V6 for Data Retention” on page 267.

Perform the following steps to configure the web client for remote access with the GUI:
1. Start your native backup-archive client GUI.
2. From the native BA Client GUI main window, open the Utilities menu and select Setup
Wizard.
3. Select the Help me configure the IBM Tivoli Storage Manager Web Client check box
and click Next.
4. The wizard starts and shows an introduction page, proceed with Next.
5. Select Install a new Web Client Agent, which must be preselected, and click Next.
6. In the Web service name window, accept the preconfigured IBM Tivoli Storage Manager
acceptor name (TSM Client Acceptor) or create a new name. Click Next.
7. In the Option File Name and Location window, name the dsm.opt file with a fully qualified
path (that is, c:program filestivolitsmbaclientdsm.opt) and click Next.
8. In the Web Client options window, specify the port number for your HTTP communication,
that is, 1581, and click Next.
9. Provide the Node Name and IBM Tivoli Storage Manager Password in the Authentication
window and check the box to contact the IBM Tivoli Storage Manager Server to validate
the password. Click Next.
10.in the Service login options window, specify the account and start method, and click Next.
11.Select the name of the Web service (that is, IBM Tivoli Storage Manager Remote Client
Agent) in the appropriate window and proceed to the next page with Next.
12.In the Web Client Parameters window, specify whether you want to restrict an
administrator with client access from accessing the web client, that is, choose No.
Click Next.
13.In the Start Option window, select whether to start the web client upon completion of the
wizard, that is, with Yes. Click Next.
14.In the Confirm and Apply your configuration window, proceed with the Apply button.
Observe that the IBM Tivoli Storage Manager web client service is installed successfully,
then use the Finish button to close the wizard window.

Installation of the web client at the command line
To install and configure the web client from the command line, perform the following steps:
1. Ensure that you specify passwordaccess generate in the client options file (dsm.opt).
2. Install the Client Acceptor Service by entering the following command:
dsmcutil install cad /name:"TSMBA_web" /node:nodename /password:password
/autostart:yes
Where nodename and password are your System Storage Archive Manager node name
and password. TSMBA_web is an example. You can use any name you want. The default
name is Tivoli Storage Manager Client Acceptor.


3. Install the Remote Client Agent Service by entering the following command:
dsmcutil install remoteagent /name:"TSM AGENT" /node:nodename
/password:password /partnername:"TSMBA_web"
Where nodename and password are your Storage Manager node name and password.
TSM AGENT is an example. You can use any name as long as it differs from the Client
Acceptor Daemon (CAD) name. The default name is TSM Remote Client Agent. The
/partnername option value must match the name of the CAD service. The default name is
TSM Client Acceptor.
4. Start the Client Acceptor Service by entering net start “TSM CAD” on the command line,
or do the following steps:
a. Open the Windows Start menu and select Settings  Control Panel.
b. Double-click Administrative Tools and then double-click Services.
c. In the Services window, right-click TSMBA_web, and select Start from the pop-up
menu. The window shown in Figure 8-7 is displayed.

Figure 8-7 Services show Tivoli Storage Manager components

To access the web client, enter the following URL from any supported web browser:
http://your_machine_name:1581

Where your_machine_name is the host name of the machine running the IBM Tivoli Storage
Manager client.

The IBM Tivoli Storage Manager web client interface for client machines requires a Java web
browser. For more information about how to set up the web client, see the IBM Tivoli Storage
Manager Infocenter:
http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.nav.doc/t_p
rotect_wf.html

Testing environment: IBM Tivoli Storage Manager backup-archive client
To show the usage of the command line client and the web client for archiving and retrieve,
we define a new policy domain, policy set, and management classes in the System Storage
Archive Manager server of our System Storage Archive Manager collection in Information
Archive using the administrative command line (dsmadmc).


Proceed as follows:
1. To create a policy domain named CLITEST_PD, we use the following command:
define domain CLITEST_PD
2. Within the policy domain CLITEST_PD, we create one policy set named CLITEST_PS:
define policyset CLITEST_PD CLITEST_PS
3. We create two separate management classes for the purpose of testing creation-based
retention and event-based retention:
define mgmtclass CLITEST_PD CLITEST_PS CLITEST_MG_CR
define mgmtclass CLITEST_PD CLITEST_PS CLITEST_MG_EV
4. We assign the first management class as the default:
assign defmgmtclass CLITEST_PD CLITEST_PS CLITEST_MG_CR
5. Next, we define archive copy groups (type=archive) for each of the management classes.
The archive copy groups must be defined along with the appropriate parameters to
differentiate between creation-based retention and event-based retention:
– Archive Copy Group (chronological retention):
define copygroup CLITEST_PD CLITEST_PS CLITEST_MG_CR type=archive
destination=filepool retver=1825 retinit=creation
– Archive Copy Group (event-based retention)
define copygroup CLITEST_PD CLITEST_PS CLITEST_MG_EV type=archive
destination=filepool retver=365 retinit=event
6. We validate the Policy Set using the following command:
validate policyset CLITEST_PD CLITEST_PS
The command returns the information that the default management class does not have a
backup copy group, and that files will not be backed up by default if policyset is activated.
This message is normal and expected in our case because the DR550 is an archive-only
solution.
7. We now activate the Policy Set:
activate policyset CLITEST_PD CLITEST_PS
8. Finally, we register the client node (CLITEST) that we use for the test:
register node ssam_client1 password domain=CLITEST_PD

With the above environment we now can use the IBM Tivoli Storage Manager command-line
client and the web client to archive and retrieve documents. Also, we can use these types of
IBM Tivoli Storage Manager clients to send events, Holds, and Releases. That is shown on
the next pages.

Testing archive functions with IBM Tivoli Storage Manager command-line client
In this section we use the IBM Tivoli Storage Manager command-line client to execute the
following scenario:
Archive one document (create.file) into the System Storage Archive Manager Collection
with the chronological retention policy.
Archive one document (event.file) into the System Storage Archive Manager Collection,
with the event-based retention policy
Send a Hold to the document in the chronological retention environment
Send an event (Activate Retention) to the document in the event-based environment.


Proceed as follows:
1. Log on to the IBM Tivoli Storage Manager command-line client (dsmc) by starting the
client.
2. Archive a document named create.file with the IBM Tivoli Storage Manager command
archive, specify the fully qualified path to the file along with its name and use the
appropriate archive management class with the -archmc option. See Example 8-1 for the
entire command and response.

Example 8-1 Archive a document with command-line and use chronological retention
tsm> archive c:tempcreate.file -archmc=clitest_mg_cr
Archive function invoked.

Directory--> 0 bscnb1767c$TEMP [Sent]
Normal File--> 7,032,832 bscnb1767c$TEMPcreate.file [Sent]
Archive processing of 'bscnb1767c$TEMPcreate.file' finished without failure.

Total number of objects inspected: 2
Total number of objects archived: 2
Total number of objects updated: 0
Total number of objects rebound: 0
Total number of objects deleted: 0
Total number of objects expired: 0
Total number of objects failed: 0
Total number of bytes transferred: 6.70 MB
Data transfer time: 0.71 sec
Network data transfer rate: 9,567.35 KB/sec
Aggregate data transfer rate: 5,495.48 KB/sec
Objects compressed by: 0%
Elapsed processing time: 00:00:01

3. Archive a document named event.file with the IBM Tivoli Storage Manager command
archive, specify the fully qualified path to the file along with its name and use the
appropriate archive management class with the -archmc option. See Example 8-2 for the
entire command.

Example 8-2 Archive a document with command-line and use event-based retention
tsm> archive c:tempevent.file -archmc=clitest_mg_ev
Archive function invoked.

Normal File--> 7,032,832 bscnb1767c$TEMPevent.file [Sent]
Archive processing of 'bscnb1767c$TEMPevent.file' finished without failure.

4. Log on to the IBM System Storage Archive Manager server of your System Storage
Archive Manager Collection with the administrative command-line client (dsmadmc) and
validate the existence of the two formerly archived files with an appropriate SQL select
statement (Example 8-3).

Example 8-3 Check for files on the Information Archive System Storage Archive Manager server
tsm: SSAM1>select * from archives where node_name='SSAM_CLIENT1'

NODE_NAME: SSAM_CLIENT1
FILESPACE_NAME: bscnb1767c$
FILESPACE_ID: 1
TYPE: FILE


HL_NAME: TEMP
LL_NAME: CREATE.FILE
OBJECT_ID: 3082
ARCHIVE_DATE: 2010-03-23 15:36:51.000000
OWNER:
CLASS_NAME: CLITEST_MG_CR

NODE_NAME: SSAM_CLIENT1
FILESPACE_NAME: bscnb1767c$
FILESPACE_ID: 1
TYPE: FILE
HL_NAME: TEMP
LL_NAME: EVENT.FILE
OBJECT_ID: 3083
ARCHIVE_DATE: 2010-03-23 15:38:41.000000
OWNER:
CLASS_NAME: CLITEST_MG_EV

In the foregoing example, we see both files and the SQL select statement shows
additional details about the archiving process and the management of the files. We use
the file space name (FILESPACE_NAME), high level identifier (HL_NAME), and low level
identifier (LL_NAME) in the next step to send events to the already archived files.
5. Send a Hold event to the create.file. See Example 8-4 for the entire command and the
output.

Example 8-4 Send Hold event with the IBM Tivoli Storage Manager command-line client
tsm> set event -type=hold bscnb1767c$tempcreate.file
Rebinding--> 7,032,832 bscnb1767c$TEMPcreate.file [Sent]

Total number of bytes transferred: 0 B
Network data transfer rate: 0.00 KB/sec
Aggregate data transfer rate: 0.00 KB/sec

6. Send an activation event to the file event.file. See Example 8-5 for the entire command
and the output.

Example 8-5 Send event (activate retention) with the IBM Tivoli Storage Manager command-line client
tsm> set event -type=activateretention bscnb1767c$tempevent.file
Rebinding--> 7,032,832 bscnb1767c$TEMPevent.file [Sent]

Total number of bytes transferred: 0 B
Network data transfer rate: 0.00 KB/sec


Aggregate data transfer rate: 0.00 KB/sec

7. You can only validate the success of formerly sent events with the IBM Tivoli Storage
Manager API or the IBM Tivoli Storage Manager web client. The latter is much easier, and
you can use it directly without any further setup.
Launch the web client from a web browser by entering the URL of the client,
http://<tsm_client_address>:1581, where <tsm_client_address> represents the
address of the IBM Tivoli Storage Manager backup-archive client and 1581 is the port for
the web client service.
In the running web client, select Actions  Set Data Retention Events from the initial
window and proceed in the next window to your files. Use the right mouse button on the
files and click File details to open an Information Window (Figure 8-8).

Figure 8-8 Information Window for archived files

In our example we see the Retention Initiation is started for both files. For the
chronological retention (create.file) this initiation is started with the archival itself. For the
event-based retention(event.file), the initiation is started with the sending of an event.
We sent the event to the event.file in the above example. Also, we see the Hold on the
create.file, but no Hold on the event.file. That is also correct, Because we sent the Hold in
the above example only to one file.
We discuss the usage of the IBM Tivoli Storage Manager web client in more detail in the
next section, when we archive and retrieve documents, and also send events through the
web client. Obviously, in that section we also validate the results with the IBM Tivoli
Storage Manager web client.

Testing archive functions with IBM Tivoli Storage Manager web client
We now archive data using the chronological retention (Example 1) and the event-based
retention (Example 2), that we configured in “Testing environment: IBM Tivoli Storage
Manager backup-archive client” on page 270. For each example, we show how to trigger
retention events and we use the web client for both examples.


Example 1: Chronological retention
This example illustrates data archiving using the creation-based management class
(chronological retention):
1. Launch the IBM Tivoli Storage Manager web client from a web browser by entering the
URL, http://BAclient_IP:1581, where BAclient_IP represents the address of the BA
client and select some files you want to archive, as shown in Figure 8-9.

Figure 8-9 Test files archived to test Chronological Archive

2. Click the Archive tab to archive these files using the default (creation-based management
class). After the Archive is complete, the message box shown in Figure 8-10 displays.

Figure 8-10 Archive complete

You can verify that the data that has been archived and that it has adopted the correct
management class as well as the correct retention period. The menu Actions  Set Data
Retention Events shown in Example 8-11 is only available when you use the IBM Tivoli
Storage Manager web client.


Figure 8-11 Set Data Retention events

You can see an example in Figure 8-12. Notice that the status of Retention Initiation is
Started. This is correct, because with chronological-based retention, the retention period
starts counting down as soon as the data has been archived.

Figure 8-12 Example of Chronological Archive


It is possible to put a hold on the archived data by first selecting the data that is required to be
held, then selecting Hold from the drop-down menu for Select Event Type, and clicking Set
Event. See Figure 8-13.

Figure 8-13 Example of how to set a Hold event

You can see in Figure 8-14 that items on hold are indicated by a lock.

Figure 8-14 Hold event set

The selected data will now be held indefinitely, until a release event is triggered by the user.

To release the hold, select Release from the drop-down menu for Select Event Type, and
click Set Event (see Figure 8-13). The countdown towards expiration resumes as though it
was never put on hold.


Example 2: Event-based retention
This example illustrates data archiving using an event-based management class.
1. Invoke the web client, and select files to archive.
2. Select Options  Override Include Exclude List and choose the desired Management
Class. We select CLITEST_MG_EV (the management class we created for event-based
retention). See Figure 8-15.

Figure 8-15 Changing the Management Class from the BA Client before archiving

You can now verify the characteristics of the archived data by selecting one of the files you
just archived and clicking View  File Details. The result is shown in Figure 8-16. Notice that
in this case that the Retention Initiation shows as Pending, which is to be expected because
we used event-based retention and no Activate Event has been sent yet.


Figure 8-16 Example of event-based retention

The countdown to expiration starts when an Activate Retention event is sent for that file.
Figure 8-17 shows how to activate the retention: Select the file, then choose Activate
Retention from the menu for the Select Event Type, and click Event.

Figure 8-17 Set Activate Retention Event


As seen in Figure 8-18, the file characteristics of this file have now changed from Retention
Initiation Pending to Retention Initiation Started.

Figure 8-18 Information Window - Activated Retention on file

The server will reject any attempt to delete the archived data, as shown in Figure 8-19.

Figure 8-19 Example of data that, after being archived, cannot be deleted


8.2.2 Integrating IBM Tivoli Storage Manager API with a System Storage
Archive Manager Collection (using dapismp)
The System Storage Archive Manager/Tivoli Storage Manager API comes with a sample
application called dapismp. You can use this sample program to explore and better understand
the data retention and compliance-enhanced features.

The sample API program dapismp creates objects and feeds them to the retention policies of
a previously defined management class. You can then use this program to query the
Information Archive System Storage Archive Manager collection for information about the
objects that were created and trigger retention events for these objects.

We use dapismp throughout this section of the book as we explore the features of System
Storage Archive Manager/Tivoli Storage Manager. Furthermore, we use dapismp on a
Microsoft Windows client system; in this environment, you can use the sample API program
right after the installation and configuration of the API (on UNIX-based systems, you will need
to compile the sample API program before you can run it). The executable file dapismp.exe
can typically be found in the directory C:Program FilesTivoliTSMapiSAMPRUN, or an
equivalent location, depending on where the System Storage Archive Manager/Tivoli Storage
Manager client files have been installed. The dapismp sample API program requires a dsm.opt
file in the same directory that must contain at least one of the following statements:
TCPSERVERADDRESS <IP_address_of_IBM_IA_SSAM_server>
ENABLEARCHIVERETENTIONPROTECTION yes

Testing the archive features with dapismp
We demonstrate the following features:
Creation-based retention initiation (chronological retention):
RETINIT=CREATION
Eligible retention events:
– Hold
– Release
Event-based retention initiation:
RETINIT=EVENT
Eligible retention events:
– Activate
– Hold
– Release

Testing environment for the IBM Tivoli Storage Manager API client
For our tests, we set up a new policy domain named APITEST and defined two management
classes. The assigned default management class is named CREATION and uses the
creation-based retention initiation. The second management class is named EVENT and
uses the event-based retention initiation. Figure 8-20 and Figure 8-21 show detailed
information about the retention settings in each management class. Our test node is named
apitest1 and is registered in the policy domain APITEST1.


Policy Domain Name: APITEST1
Mgmt Class Name: CREATION
Retain Version: 1825
Retention Initiation: Creation
Retain Minimum Days:
Copy Frequency: CMD
Copy Mode: Absolute
Last Update by (administrator): ADMIN
Last Update Date/Time: 03/23/2010
Managing profile:

Figure 8-20 Archive copy group settings for management class CREATION

Policy Domain Name: APITEST1
Mgmt Class Name: EVENT
Retain Version: 365
Retention Initiation: Event
Retain Minimum Days: 730
Copy Frequency: CMD
Copy Mode: Absolute
Last Update by (administrator): ADMIN
Managing profile:

Figure 8-21 Archive copy group settings for management class EVENT

The management class CREATION has been updated to be the default management class
(see Figure 8-22). This means that objects delivered (by dapismp or a document management
system) through the API to the System Storage Archive Manager Collection server without a
specific management class assigned will be stored in the System Storage Archive Manager
Collection with the policies of the standard management class, in this case, CREATION.

tsm: TSM>query mgmtclass apitest standard

Policy Policy Mgmt Default Description
Domain Set Name Class Mgmt
Name Name Class ?
--------- --------- --------- --------- ------------------------
APITEST STANDARD CREATION Yes
APITEST STANDARD EVENT No

Figure 8-22 Default management class CREATION


Using the sample API program dapismp
To use the sample API program dapismp, complete the following steps:
1. Start dapismp and sign in (connect to the System Storage Archive Manager Collection).
To start dapismp on a Microsoft Windows client system:
a. Start a command window and change to the C:Progra~1tivoliTSMapiSAMPRUN
directory (or the appropriate installation directory).
b. At the command prompt, type dapismp and press Enter, which starts the dapismp
executable and brings you to the first panel, as shown in Figure 8-23.

Attention: The actual panels contain more options than those shown here. In the
interest of saving space, we show only the minimum input needed to attain the
desired results. We edited out the options not used in this example.

*************************************************************************
* Welcome to the sample application for the Tivoli Storage Manager API. *
* API Library Version = 6.1.3.0 (unicode) *
*************************************************************************

Choose one of the following actions to test:

0. Signon
1. Backup
2. Restore
3. Archive
4. Retrieve
5. Queries
6. Change Password
7. Utilities : Deletes, Updates, Logevent, SetAccess, RetentionEvent
8. Set preferences, envSetUp
9. Exit to system
10. Restore/Retrieve Without Offset Prompt
11. Extended Signon

Enter selection ==>0

Figure 8-23 First window of sample API program dapismp after startup

2. Start a session with the Information Archive System Storage Archive Manager server:
a. Select the option 0. Signon to attempt a session with the Information Archive System
Storage Archive Manager server. The only information that must be provided here is
your node name and password, as shown in Figure 8-24. The other fields can be
skipped. An example of a successful signon is shown in Figure 8-24, where the
success message is Handle on return = 1.

Tip: If you have problems at this stage, check to see that the API environment
variables DSMI_DIR, DSMI_CONFIG, and DSMI_LOG have been set. DSMI_DIR
needs to point to the location of the API files, that is, c:Program FilesTivoliTSMapi


Node name:apitest1
Owner name:
Password:passw0rd
API Config file:dsm.opt
Session options:
User Name:
User pswd:
Are the above responses correct (y/n/q)? y
Doing signon for node ssam_client, owner , with password passw0rd
Handle on return = 1

Figure 8-24 Example of successful signon

b. Submit the query session command on the System Storage Archive Manager server
to verify that a session was started. Figure 8-25 shows that the attempt was
successful. Now that you have successfully signed on to the server, proceed to step 3
on page 284.

Sess Comm. Sess Wait Bytes Bytes Sess Platform Client Name
Number Method State Time Sent Recvd Type
------ ------ ------ ------ ------- ------- ----- -------- ---------------
15 Tcp/Ip IdleW 13 S 468 299 Node Sample-- apitest1
API

Figure 8-25 Output of query session command verifying the session

3. Create archive objects using dapismp.
Use dapismp to create two objects and archive them to the System Storage Archive
Manager server. Then look at their retention policies. Repeat this step and override the
default management:
a. From panel 1 of dapismp, select option 3. Archive, as shown in Figure 8-26. You are
prompted for information about the file that dapismp creates and sends to the server.
You are also prompted to enter the name of another management class, which
overrides the assigned default management class. Figure 8-26 shows the minimum
input required to create the first object in the chronological management class. Repeat
this step with various file name qualifiers and override the default management class
with the event-based management class EVENT, as shown in Figure 8-27. Continue to
the next step.


3. Archive

Filespace:apitest1
Highlevel:
Lowlevel:test1
Object Type(D/F):f
Object Owner Name:
Object already compressed?(Y/N):
Wait for mount?(Y/N):
File size:1000000 (in bytes)
Number of files:1
Seed string:1
Archive description:apitest1
Mgmt class override:
Are the above responses correct (y/n/q)?
y
Creating 1 object(s) called apitest1test1(nnn) each of size 1,000,000.
Creating object 1 of 1 Size=1,000,000 Name=apitest1test1

Figure 8-26 Output of the archive function of dapismp into a standard management class

Filespace:apievent1
Highlevel:apievent1
Lowlevel:eventtest
Object Type(D/F):f
Object Owner Name:
Object already compressed?(Y/N):
Wait for mount?(Y/N):
File size:1000000
Number of files:1
Seed string:1
Archive description:1"test event based"
Mgmt class override:event
y
Creating 1 object(s) called apievent1apievent1eventtest(nnn) each of size 1,000,000.
Creating object 1 of 1 Size=1,000,000 Name=apievent1apievent1eventtest
Object: 1 Buffer: 1 Bytes sent: 1,000,000 Bytes left: 0

Figure 8-27 Event-based retention overrides the management class

Attention: As a reminder, the actual panels contain more options than those shown
here. In the interest of saving space, we show only the minimum input needed to attain
the desired results. We have edited out the options not used in this example.


4. Query the Information Archive System Storage Archive Manager server of the System
Storage Archive Manager Collection.
We now query the System Storage Archive Manager server and compare the policy
information for both objects. Querying the System Storage Archive Manager server for
archives can be done with the dapismp sample program or with select statements from the
System Storage Archive Manager administrative command line.
We show both methods here:
– From the first panel of the dapismp sample program, select option 5. Queries and then
option 2. Archive Query in the following panel. Enter the name of the file space you
want to query, which is required. In addition, the high-level and low-level qualifiers are
required, as specified when the object has been created. In the low-level qualifier, a
wildcard (*) can be used. For detailed output, answer yes when prompted, as shown in
Figure 8-28, and continue. Figure 8-30 shows the output of the query.

Filespace:apitest1
Highlevel:
Lowlevel:*
Object Type(D/F/A):f
Show detailed output? (Y/N):y
y
Figure 8-28 Minimum input required for archive query using dapismp

– From a System Storage Archive Manager administrative command-line (dsmadmc)
prompt, enter the following SQL select statement:
select * from archives where node_name=’APITEST1’
The output in Figure 8-29 shows that an object was archived to the server by node
APITEST1; the object is bound to the default management class.

NODE_NAME: APITEST1
FILESPACE_NAME: apitest1
FILESPACE_ID: 1
TYPE: FILE
HL_NAME:
LL_NAME: test1
OBJECT_ID: 3074
ARCHIVE_DATE: 2010-03-16 12:16:30.000000
OWNER:
DESCRIPTION: apitest1
CLASS_NAME: DEFAULT

Figure 8-29 Output of the select statement


5. Compare the results.
Examine the information that System Storage Archive Manager has associated with the
objects. Figure 8-30 and Figure 8-31 show the output of the archive query issued in the
previous step. You can identify the parameters RETINIT and RETVER, which we
discussed earlier in this book:
– RETINIT=creation
• The file that the dapismp program created was bound to the assigned default
management class, in our case, management class CREATION (see Figure 8-30),
which uses creation-based retention initiation (RETINIT=creation).
• Retention Initiated is STARTED (RETVER=n days is initiated).
• The Expiration date for this object is 2010/3/16 12:16:30.
• The Object Held is FALSE (deletion hold is not set).
• The high-level Object ID is 0-3074. This is important. You will need this information
later.
When expiration processing runs on the server any time after 2011/3/2 12:16:30, this
file will be deleted from the database, unless a “deletion hold” retention event is
triggered for this object. We demonstrate this in “Sending retention events using
dapismp” on page 288.

Item 1: apitest1test1
Object type: File
Desc: apitest1
Insert date: 2010/3/16 12:16:30
Expiration date: 2011/3/16 12:16:30
Owner:
Restore order: 4-0-35-0-0
Object id: 0-3074
Copy group: 1
Media class: Library
Mgmt class: DEFAULT
Object info is :Tivoli Storage Manager API Verify Data
Object info length is :60
Estimated size : 0 1000000
Retention Initiated: STARTED
Object Held : FALSE

Figure 8-30 Creation-based retention initiation: Output of select statement

– RETINIT=event
• The file that the dapismp program created was bound to the EVENT management
class. (You chose to override the default and use the event management class; see
Figure 8-27 on page 285.)
• The status of Retention Initiated is PENDING, because no retention “activate” event
has been issued yet.
• The expiration date for this object is 65535/0/0 0:0:0 (the same is true when
RETVER=nolimit).
• The status of Object Held is FALSE (the deletion hold is not set).
• The high-level Object ID is 0-3076. This is important. You will need this information
later.


Item 1: apievent1apievent1eventtest
Object type: File
Desc: 1"test event based"
Insert date: 2010/3/16 1:23:56
Owner:
Object id: 0-3076
Copy group: 1
Mgmt class: EVENT
Retention Initiated: PENDING
Object Held : FALSE
Press any key to continue

Figure 8-31 Event-based retention initiation: Output from dapismp archive query

Sending retention events using dapismp
To send retention initiation events using the dapismp sample program:
1. Starting from the first panel of dapismp, select option 7. Utilities, which brings you to the
Utilities panel.
2. Select option 12. Retention Event. You are then prompted for the high-level object ID of
the file for which you will trigger a retention event. In this case, the object ID is 0-3074.
3. Next, you are prompted for the low-level object ID, 3074 in this case.
4. Finally, you are prompted for the type of event you want to trigger. There are two
possibilities for creation-based retention initiation: Hold (deletion hold) and Release
(release the hold).
5. Select h for Hold and press Enter twice. Figure 8-32 and Figure 8-33 show the output
resulting from these actions.

7. Utilities : Deletes, Updates, Logevent, SetAccess, RetentionEvent
8. Set preferences, envSetUp
9. Exit to system

Choose one of the following actions:
...
12. Retention Event

Object ID (HI) to signal:0-3074
Object ID (LOW) to signal:3074
Activate (A) Hold (H) Release (R):h
y
Finished Retention Event successfully

Figure 8-32 Triggering retention events


This action triggers a deletion hold event for an archive object. Figure 8-33 shows that the
object has a “deletion hold” status.

Item 1: apitest1test1
Object type: File
Desc: apitest1
Insert date: 2010/3/16 12:16:30
Owner:
Object id: 0-3074
Copy group: 1
Mgmt class: DEFAULT
Retention Initiated: STARTED
Object Held : TRUE
Press any key to continue

Figure 8-33 Deletion hold is set

The object is held, but there is no change to the expiration date.

Deleting archive from application
Because of data retention protection, attempting to delete the object (as shown in
Figure 8-34) results in a failed status (which is the expected result).

10. Object Rename
11. Object Delete
12. Retention Event

Object ID (HI) to DELETE:0-3074
Object ID (LOW) to DELETE:3074
Backup or Archive(B/A):a
y

*** dsmDeleteObj failed:
ANS0266I (RC2302) The dsmEndTxn vote is ABORT, so check the reason field.

Choose one of the following actions:

Figure 8-34 Attempt to delete an archive object in hold status

Table 8-1 illustrates the initial status of “Retention initiated” and “Object Held” after the
creation of an object in the two particular management classes. While “Retention initiated” is
already STARTED in the chronological (CREATION) management class, it is still PENDING in
the event-based class. This will change to STARTED as soon as the retention event activation
has been issued through the API.

“Object Held” is FALSE for both, because no retention event hold has been issued. This will
show TRUE after a hold is received and FALSE again after a release event.


Table 8-1 Initial status of files archived with creation-based and event-based retention
Field RETINIT=creation RETINIT=event

Insert date: 2010/3/16 12:16:30 2010/3/16 12:16:30

Expiration date 2011/3/16 12:16:30 65535/0/0 0:0:0

Mgmt class: CREATION EVENT

Retention Initiated: STARTED PENDING

Object Held: FALSE FALSE

For more information about the IBM System Storage Archive Manager/Tivoli Storage
Manager API, consult Tivoli Storage Manager Using the Application Program Interface.

8.2.3 Integrating Content Manager with Information Archive System Storage
Archive Manager Collection
An IBM Content Manager (CM) system contains a library server and one or more resource
managers. The IBM Content Manager resource manager relies on Tivoli Storage Manager or
System Storage Archive Manager for accessing secondary storage devices other than local
file systems.

The Content Manager resource manager communicates to the System Storage Archive
Manager server using the Tivoli Storage Manager application program interface (IBM Tivoli
Storage Manager API). In this mode, an active retention protection ensures availability of
objects, such as files, for a period of time, which can be determined by the administrator.

Interoperability: IBM Content Manager Enterprise Edition V8.4 and DB2 Information
Integrator for Content V8.4 for Linux/UNIX/Windows operating systems themselves remain
32-bit applications with the exception of Linux on IBM System z, where the library server
component is 64-bit with 31-bit user defined exits. Therefore, you need to use the 32-bit
IBM Tivoli Storage Manager API in conjunction with Content Manager even if the host is
running a 64-bit operating system. You can find more details about interoperability and
support for ECM at the following link:
http://www-01.ibm.com/support/docview.wss?rs=86&uid=swg21293849

The following rules apply to a Content Manager environment set up for the use of a System
Storage Archive Manager, specifically, the System Storage Archive Manager Collection:
You cannot migrate data out of Content Manager volumes.
You cannot have more than one local Content Manager storage class in a Content
Manager policy.
If the first Content Manager storage class in the Content Manager policy does not have a
System Storage Archive Manager volume under retention control:
– You can have other storage classes. In that case, if you also have a storage class with
a System Storage Archive Manager volume under retention control, it must be the last
storage class.
– You can have a remote storage class that contains a System Storage Archive Manager
volume under retention control.


Content Manager configuration for a System Storage Archive Manager
Collection
You have to configure various entities within Content Manager before data can be archived in
the System Storage Archive Manager Collection (see Figure 8-35):
You must have a System Storage Archive Manager Collection configured, and the policies
must include archive copy groups with retention values matching the retention
requirements of the item types in Content Manager that will use the System Storage
Archive Manager Collection.

Event-based retention: The archive copy group must use event-based retention,
because this is the only configuration Content Manager supports for Information
Archive System Storage Archive Manager Collections.

You must register a node in the Information Archive System Storage Archive Manager
server and the appropriate policy domain.
The Tivoli Storage Manager API software (Version 5.5) must be installed and configured
on the Content Manager resource server.

Interoperability: Check the interoperability and support website for supported IBM
Tivoli Storage Manager API versions. At the time of writing this book, Content Manager
8.4 supports the 32-bit IBM Tivoli Storage Manager API in Version 5.5. Because IBM
Tivoli Storage Manager V6.1 and V6.2 are already available, you must check the
interoperability carefully.
http://www-01.ibm.com/support/docview.wss?rs=86&uid=swg27015604

Several options must be set in Content Manager to allow the system to use the Information
Archive System Storage Archive Manager Collection. In a Content Manager for Microsoft
Windows system, the Content Manager System Administration Client is used to set
parameters and options.

Depending on your retention requirements, the configuration of the various entities within the
Content Manager and System Storage Archive Manager Collection can be very complex. In
the following topics, we discuss some of the Content Manager concepts and constructs. We
also provide an example to help illustrate these concepts. Although we cannot explain every
detail here, we assume that you can consult the IBM Content Manager documentation for
further information instead.


Figure 8-35 illustrates Content Manager for Tivoli Storage Manager archive management.

Tivoli Storage Manager Server
(SSAM) DB2 CM Resour ce Manager
Policy Domain S e r ve r D e f i n i t i o n s
< TSM >
name: TSM hostname: 192.168.1.22
Policy Set
D e vi c e Ma n a g e r s
< ICMADDM >
management class: parameters: mode = retention class: TSM

Stor age Classes
< DB2_CM_1Y >
< TSMSTGCLASS_1Y > < TSMSTGCLASS_3Y > < TSMSTGCLASS_5Y >
device manager:
ICMADDM device manager: ICMADDM device manager: ICMADDM
< DB2_CM_3Y >
S t o r a g e S y s t e ms
< DB2_CM_5Y > Ti vol i S t or a ge Ma na ge r V ol um e s
< DB2_CM_1Y > < DB2_CM_3Y > < DB2_CM_5Y >
TSM mgmt: DB2_CM_1Y TSM mgmt: DB2_CM_3Y TSM mgmt: DB2_CM_5Y
storage class: storage class: storage class:
TSMSTGCLASS_1Y TSMSTGCLASS_3Y TSMSTGCLASS_5Y

Mi g r a t i o n P o l i c i e s
< TSMMIGPOL_1Y > < TSMMIGPOL_3Y > < TSMMIGPOL_5Y >
storage class: TSMSTGCLASS_1Y storage class: TSMSTGCLASS_3Y storage class: TSMSTGCLASS_5Y

S t o r a g e Gr o u p s
< TSMSTGGRP_1Y > < TSMSTGGRP_3Y > < TSMSTGGRP_5Y >
volume: DB2_CM_1Y volume: DB2_CM_3Y volume: DB2_CM_5Y
DB2 CM Cli ent
Wor kstati on Collec ti ons
Import < TSMWSCOLL_1Y > < TSMWSCOLL_3Y > < TSMWSCOLL_5Y >
item type: migration policy: TSMMIGPOL_1Y migration policy: TSMMIGPOL_3Y migration policy: TSMMIGPOL_5Y
storage group: storage group: storage group:
TSMSTGGRP_1Y TSMSTGGRP_3Y TSMSTGGRP_5Y
< TSMARCHIVE_1Y >

< TSMARCHIVE_3Y > D B 2 C M L I B R AR Y M ANAG E R
I t e m Ty p e
< TSMARCHIVE_5Y > < TSMARCHIVE_1Y > < TSMARCHIVE_3Y > < TSMARCHIVE_5Y >
collection: TSMWSCOLL_1Y collection: TSMWSCOLL_3Y collection: TSMWSCOLL_5Y

Figure 8-35 Overview: Content Manager for Tivoli Storage Manager archive management

Some important terms of a Content Manager environment include:
Device manager A software artifact that acts as an intermediary between your resource
manager and physical storage. It is the interface between the resource
manager and the storage system defined with it in a migration policy. It
communicates the tasks that you define for the resource manager to
the storage system where you store your objects. You assign device
managers to a storage class so that the storage class can
communicate with the storage systems.
Storage class A logical grouping of similar storage types that identifies the type of
media on which an object is stored. It is not directly associated with a
physical location; however, it is directly associated with the device
manager, which is the interface between the resource manager and
the actual physical location. You can assign only one device manager
to each storage class. Types of storage classes include fixed disk,
VideoCharger, media archive, and Tivoli Storage Manager.


Storage system An actual physical device or unit where the objects are stored. There
are various types of storage systems, such as volumes on Windows,
file systems on UNIX, Content Manager VideoCharger, media archive,
and Tivoli Storage Manager. Storage systems are also known as
volumes. A storage system is associated with a storage class.
Migration policy A user-defined schedule for moving objects from one storage class to
the next. It describes the retention and class transition characteristics
for a group of objects in a storage hierarchy. Creating a migration
policy and defining the migration schedule automates the migration of
objects so that you do not have to manually monitor migration.

Management classes: Tivoli Storage Manager and System
Storage Archive Manager refer to their migration policies as
management classes.

Storage group A group that contains one or more storage systems and storage
classes. It associates each storage system to a storage class.

IBM Content Manager for Windows and System Storage Archive
Manager configuration
We assume that the Content Manager V8.4 software is installed and configured and that a
Content Manager client is available for testing archive functions. The Tivoli Storage Manager
server is located in the Information Archive appliance; therefore, the archive retention
protection is set on, which makes it a System Storage Archive Manager server.

To enable Content Manager for Windows to access the System Storage Archive Manager
server for archive management, complete the following steps on the Content Manager
resource server, and then the Tivoli Storage Manager administrative command-line client
(dsmadmc), and finally, the Content Manager System Administrator Client, as outlined in the
following sections.

Content Manager resource server
First, on the server where the Content Manager resource server will be installed, complete
the following steps:
1. Download the latest supported Tivoli Storage Manager backup-archive client, API, and the
Tivoli Storage Manager administrative client command-line files. You can find the current
maintenance levels of the software at:
ftp://ftp.software.ibm.com/storage/tivoli-storage-management/patches/client/v5r
5/Windows/x32/v552/
Within the download folder, download the self-extracting executable client code. See the
readme.ftp file within the same folder as the code is named, for example, a file named
TSMBAC-WinX32.exe.
2. Start the installation by starting the self-extracting executable client code, such as
TSMBAC-WinX32.exe.
3. In the first window (Location to Save Files), choose a folder where the software can be
unpacked, such as c:tsm_imagesTSM_BA_Client, and click Next.
The install wizard extracts the files.
4. In the Choose Setup Language window, choose your language, such as English
(United States), and click OK.
The install wizard prepares the installation.


5. In the Welcome to the InstallShield Wizard window, click Next.
6. In the Destination Folder window, select the installation folder, such as c:Program
FilesTivoliTSM, and then click Next.
7. In the Setup Type window, change the default setting from Typical to Custom, and then
click Next.
8. In the Custom Setup window, select the Administrative Client Command Line Files and
Client API SDK Files additional features (three are already selected), and then click Next.
(Figure 8-36.)
Although the administrative client command line is not necessary for the Content
Manager, we use this interface to set up the Information Archive System Storage Archive
Manager server and check the results of archive sessions. This step is optional and you
do not need to install this product if you prefer to use the administrative web client. The
Client API SDK Files contain the dapismp command line for testing purposes. It can be
useful to test the server connection to the System Storage Archive Manager server with
this tool.

Figure 8-36 IBM Tivoli Storage Manager Backup-Archive client - Custom Setup window

9. In the Ready to Install the Program window, click Install. The InstallShield Wizard starts
installing the software.
10.When the InstallShield Wizard Completed window opens, check that the installation is
successful and click Finish. If it is not successful, correct the problem and repeat the
installation.
11.The API uses unique environment variables to locate files. Set up the API environment
variables DSMI_CONFIG, DSMI_DIR, and DSMI_LOG in Microsoft Windows (select
System Properties  Environment Variables). It is a best practice to configure the
variables for the entire system (system variables) rather than for a single user (user
variables). See Figure 8-37 for details.


Figure 8-37 Set IBM Tivoli Storage Manager API Environment Variables window

Attention: Check that the file dscenu.txt exists in the API directory. Usually it is located in
the c:program filestivolitsmbaclient directory. In order to get Content Manager connected
by the IBM Tivoli Storage Manager API ensure that the message repository file is also
located in the IBM Tivoli Storage Manager API directory c:program filestivolitsmapi.

12.Copy the dsm.opt file from the backup-archive client installation folder to the API
installation folder. If there is no dsm.opt file, copy the dsm.smp sample option file from the
Tivoli Storage Manager configuration directory (C:Program FilesTivoliTSMconfig) to the
backup-archive client installation folder and to the API installation folder. Rename the
sample option file from dsm.smp to dsm.opt in both folders.
13.Edit the dsm.opt file within the backup-archive client installation folder. Set the IP address
of your System Storage Archive Manager server to (TCPServeraddress), commmethod
tcpip, tcpport 1501, enablearchiveretentionprotection on, and passwordaccess generate.
Save the changes. This step is optional, and you do not need to configure this file if you do
not use the administrative command-line client.
14.Edit the dsm.opt file within the API client installation folder. Set the IP address of your
System Storage Archive Manager server to (TCPServeraddress), commmethod tcpip,
tcpport 1501, enablearchiveretentionprotection on, and passwordaccess prompt. Save the
changes.
The Tivoli Storage Manager API access method “generate” is supported by Content
Manager, but the resource manager first attempts to access Tivoli Storage Manager with
“prompt”. If using prompt is not successful, it retries using generate. If you use generate,
you need to use the Tivoli Storage Manager API sample program dapismp to change the
password, which in turn, enables this feature.


Tip: You can configure Content Manager to signal Tivoli Storage Manager to
use the retention mode instead of using the Tivoli Storage Manager parameter
enablearchiveretentionprotection. To do this, in the Device Manager Properties window,
configure your Tivoli Storage Manager device manager, ICMADDM, and set
Parameters to mode=retention. By using this configuration, you do not have to
configure the Tivoli Storage Manager API options file with
enablearchiveretentionprotection on.

Tivoli Storage Manager administrative command-line client
Next, use the Tivoli Storage Manager administrative command-line client (dsmadmc) to perform
these steps:
1. With the administrative command-line client, first create a new System Storage Archive
Manager policy domain exclusively for Content Manager systems. The policy domain is
named DB2_CM_PD, where the letters PD stand for policy domain. Create the new policy
domain with the following System Storage Archive Manager command:
define domain db2_cm_pd archretention=3650
This command creates the policy domain and sets the archive retention grace period to
3650 days, which is 10 times longer than the default. The grace period specifies the
number of days to retain an archive copy when the management class for the file no longer
contains an archive copy group and the default management class does not contain an
archive copy group. The retention grace period protects archive copies from being
immediately expired.
2. Within the policy domain DB2_CM_PD, we create one policy set named DB2_CM_PS, where
the letters PS stand for policy set. Create the policy set by issuing the following System
Storage Archive Manager command:
define policyset db2_cm_pd db2_cm_ps
3. Create three separate System Storage Archive Manager management classes within the
System Storage Archive Manager policy set so that you can configure various retention
policies. Because the plan is to archive some of your data for one year, some data for
three years, and other data for five years, make sure to reflect that in your System Storage
Archive Manager management classes. The System Storage Archive Manager
management classes are named DB2_CM_1Y, DB2_CM_3Y, and DB2_CM_5Y. Use the
following commands to create the three management classes:
define mgmtclass db2_cm_pd db2_cm_ps db2_cm_1y
Assign the first management class as the default by issuing the following command:
assign defmgmtclass db2_cm_pd db2_cm_ps db2_cm_1y
4. The next step is to define archive copy groups (type=archive) for each of the three
management classes. The archive copy groups must be defined along with the correct
parameters. First, they need to work with the event-based retention (RETINIT=event) and
specify the retention values (RETMIN, RETVER) to reflect the various policies. In our
example, the following System Storage Archive Manager commands apply:
define copygroup db2_cm_pd db2_cm_ps db2_cm_1y type=archive
destination=filepool retver=0 retinit=event retmin=365


Important: The configuration of System Storage Archive Manager archive copy groups
includes the most sensitive retention settings in your System Storage Archive Manager
Collection, because you define the overall rules and time periods here. In production
environments, this is the most important step during the entire setup.

5. Validate the policyset by issuing this System Storage Archive Manager command:
validate policyset db2_cm_pd db2_cm_ps
The command will return the information that the default management class does not have
a backup copy group, and that files will not be backed up by default if this set is activated.
Because the System Storage Archive Manager Collection is an archive-only environment,
and indeed we want to archive Content Manager objects, you can ignore any messages
about backup copy groups and space management setting.
6. Activate the policyset with the following System Storage Archive Manager command:
activate policyset db2_cm_pd db2_cm_ps
7. After the successful definition of all policies, you can register a node in the newly created
policy domain. Name the Content Manager resource manager cmarchive and register it in
the DB2_CM_PD domain:
register node cmarchive password domain=db2_cm_pd archdelete=yes

Content Manager System Administration Client GUI
Finally, in the Content Manager System Administration Client GUI, complete the following
steps:
1. Start the Content Manager System Administration Client GUI for Windows and select
Content Manager as the server type and select the instance you want to enable for Tivoli
Storage Manager use, for example, ICMNLSDB.
2. Log in with your user account and password. You have defined the user account and
password during the installation of the IBM Content Manager. A window similar to the one
shown in Figure 8-38 opens.

Figure 8-38 Content Manager System Administration Client


3. Click Resource Managers and then click RMDB. This will expand the tree of the resource
manager database (RMDB), as shown in Figure 8-38. If your resource manager is not
running, or there are problems in the communication between the library server and the
resource manager, the message shown in Figure 8-39 will be displayed instead of an
enlarged tree. Start the resource manager or correct the problems and click RMDB again.

Figure 8-39 Problems connecting to the resource manager database (RMDB)

4. Configure the resource manager as follows:
a. Right-click Server Definitions in the left pane of the window and click New, as shown
in Figure 8-40, to open the New Server Definition window (see Figure 8-41). This is the
general way to create new entries for all of the entities within the resource manager;
therefore, we do not show this process in detail again.

Figure 8-40 Create new Server Definitions for the resource manager


i. In the Server Definition Properties window, specify the parameters that pertain to
the Information Archive System Storage Archive Manager server. With the
exception of the values in the Hostname and the Password fields, the values shown
in Figure 8-41 can normally be used. Enter the host name of your Information
Archive System Storage Archive Manager server and user CMARCHIVE. The user
CMARCHIVE has been registered as System Storage Archive Manager client node
in previous steps, when you registered the node. Select ftp from the Protocol
drop-down list. Choose an arbitrary port number for the Port number field. Any port
number will work for a server type of Tivoli Storage Manager. Leave the Schema
field blank, but enter a fully-qualified path to the Tivoli Storage Manager API option
file in the Path field (this is optional if you only use one Tivoli Storage Manager
server).

Figure 8-41 New Server Definition window

Click OK to save the server information.


b. Click Device Managers and then double-click ICMADDM in the right pane. This opens
the Device Manager Properties window for ICMADDM, as shown in Figure 8-42.

Figure 8-42 Device Manager Properties: ICMADDM window

In the Parameters field, type mode=retention and enable the device manager by
selecting Enable. Click OK to save the information.
An alternative value, retention_aggregate, has been introduced for the mode
parameter, to overcome the problem with growing System Storage Archive Manager
databases due to high amount of stored objects. Each object stored in a System
Storage Archive Manager server will have an entry in the System Storage Archive
Manager database. On average, each object stored into System Storage Archive
Manager will use ~500 bytes in the database.
The size of the database will increase linearly as the number of objects stored
increases. When the System Storage Archive Manager databases grow very large,
performance can start to degrade. Or, you can even reach the limit of size of the
System Storage Archive Manager database, which is 1 TB for System Storage Archive
Manager V6.1. To alleviate this issue and to allow Content Manager to store large
volumes of objects to the System Storage Archive Manager server, the Content
Manager Resource Manager allows the system administrator to enable “aggregation”.
When aggregation is used, Resource Manager objects are grouped together into one
System Storage Archive Manager object, thereby reducing the overhead on the
System Storage Archive Manager database. Note that you can only use aggregation
when the Resource Manager is using Tivoli Storage Manager or System Storage
Archive Manager in “archive copy group mode,” which is also known as standard
retention mode.
To enable retention and aggregation mode, the Tivoli Storage Manager device driver
(ICMADDM) within the Content Manager Resource Manager configuration must have
its parameters set to mode=retention_aggregate.


Important: Within Content Manager, you can configure the Tivoli Storage Manager
device manager ICMADDM to signal to Tivoli Storage Manager or System Storage
Archive Manager that archive protection is in use. Therefore, the Parameters field
must contain mode=retention. If this parameter is not set, you must enable the
archive protection in the Tivoli Storage Manager API option file dsm.opt with
ENABLEARCHIVERETENTIONPROTECTION ON. It is good practice to always set
both parameters in your environment.

c. Right-click Storage Classes and click New to open the New Storage Class window. In
the Name field, type a meaningful name for your new storage class. Select Local
destination, and select ICMADDM as the Device manager. Click OK to save the
storage class.

Figure 8-43 New Storage Class window

In our example, we created three storage classes named TSMSTGCLASS_1Y,
TSMSTGCLASS_3Y, and TSMSTGCLASS_5Y.
These storage classes will be later attached to the appropriate System Storage Archive
Manager management classes. Hence, we use similar naming conventions for both
configurations, that is the System Storage Archive Manager management classes and
the according Content Manager storage classes.
d. Double-click Storage Systems to expand its contents. Right-click Tivoli Storage
Manager Volumes and click New to open the New Tivoli Storage Manager Volume
window.
Define your new Tivoli Storage Manager volume, but do not assign it at this time
(Assignment: Unassigned). In the Tivoli Storage Manager management class field,
type the Tivoli Storage Manager management class you want to use with this Content
Manager storage system. Select the Server name and Storage class that you created
before and that belong to the volume. See Figure 8-44. Click OK to save the
configuration.


Figure 8-44 Define a new IBM Tivoli Storage Manager Volume for storage class
TSMSTGCLASS1Y

When defining Tivoli Storage Manager volumes for the use of the Information Archive
System Storage Archive Manager server, be aware that Content Manager connects to
the configured System Storage Archive Manager server. Therefore, the Information
Archive System Storage Archive Manager server must be available and configured for
Content Manager at this time; otherwise, Content Manager will display an error
message, as shown in Figure 8-45.

Figure 8-45 Tivoli Storage Manager configuration error message

Important: Always enter your Tivoli Storage Manager management class in
uppercase. Refer only to Tivoli Storage Manager management classes that use the
event-based archive retention.


If you experience a problem as shown in Figure 8-45, it is possible that Content
Manager cannot communicate with the System Storage Archive Manager server. This
might happen when CM cannot access the IBM Tivoli Storage Manager API files. Even
if you already specified the IBM Tivoli Storage Manager API variables in the system
environment, you explicitly need to configure the variables DSMI_DIR and
DSMI_LOG_PATH within the Content Manager DB2 database. To do so, or to verify the
current settings, perform the following steps:
• Log on the Resource Manager Administration Console by using your web browser
and log in as user rmadmin. The user account and the password is created during
the installation of the Content Manager.
The Resource Manager Administration Console can be accessed at the URL:
https://localhost:9443/icmrm/admin/
Also, the TCP/IP port, which must be specified in this URL, is created during the
Content Manager installation and it might not be the same in your environment.
• Select the Advanced Parameter tab and search for the DSMI_DIR and
DSMI_LOG_PATH variable. Verify that the values points to the directory where the
IBM Tivoli Storage Manager API is installed. The example in Figure 8-46 points to
c:program filestivolitsmapi.

Figure 8-46 Resource Manager Administration Console


Figure 8-47 shows an example of how to configure the first of three Tivoli Storage
Manager volumes. Associate this volume with the appropriate System Storage Archive
Manager management class of one year retention (DB2_CM_1Y); this is the name
resource manager gives to the volume. The storage class you created for this
configuration is named TSMSTGCLASS_1Y and it is referenced in the third line.

Figure 8-47 New Tivoli Storage Manager Volume window

Create three volumes in total (DB2_CM_1Y, DB2_CM_3Y, and DB2_CM_5Y) and
assign the same Server name. Choose the appropriate Storage class each time.
The result shows three Tivoli Storage Manager volumes with names belonging to the
Information Archive System Storage Archive Manager management classes, as shown
on the right side of Figure 8-47.
e. Right-click Storage Groups and click New to open the Storage Group Properties
window, as shown in Figure 8-48.
In the Name field, type the name you want to give to the new storage group, for
example, TSMSTGGRP_1Y.
The Storage systems list identifies the available storage systems. From this list, choose
the storage system that you want to associate with this storage group. For example,
choose the volume DB2_CM_1Y for the storage group TSMSTGGRP_1Y.


Figure 8-48 Storage Group Properties window

Click OK to save the configuration.
Create three storage groups (TSMSTGGRP_1Y, TSMSTGGRP_3Y, and
TSMSTGGRP_5Y) and assign the appropriate Tivoli Storage Manager volume each
time. Only assign one volume to one storage group.
f. Right-click Migration Policies and click New to open the New Migration Policy window,
as shown in Figure 8-49.
In the Name field, type the name of the migration policy and click Add. The New
Migration Policy Entry window opens. Select the correct Storage Class and the
Retention period. Always select Forever as the Retention period.

Figure 8-49 New Migration Policy window



Create three migration policies (TSMMIGPOL_1Y, TSMMIGPOL_3Y, and
TSMMIGPOL_5Y) and assign the appropriate Storage Class each time.
g. Right-click Workstation Collections and click New to open the New Workstation
Collection window, as shown in Figure 8-50.
In the Name field, type a unique name for your workstation collection, for example,
TSMWSCOLL_1Y. In the Migration policy field, select the dedicated migration policy you
want to use, for example, TSMMIGPOL_1Y, and the Resource Manager will
automatically fill in the Storage group field, in this case, with TSMSTGGRP_1Y.
You can replicate objects in this collection to several other collections that are on
various resource managers. Because we only have one resource manager in our
environment, we do not use the Add button, but save the configuration instead.

Figure 8-50 New Workstation Collection window

Create three workstation collections (TSMWSCOLL_1Y, TSMWSCOLL_3Y, and
TSMWSCOLL_5Y) and assign the appropriate Migration policy and Storage group
each time.
5. Configure the library server:
The Content Manager library server can be used for various operations and therefore has
a variety of entities to configure. We concentrate on the item type only, because this is the
only entity we need in our environment. It might not be the same in your production
environment.
An item type is a template that consists of a root component, zero or more child
components, and a classification. By classifying the item type, you make a judgement
about the purpose of the items created using this item type. The classifications are item,
resource item, document, and document part.
The following example shows you how to create document item types. The Content
Manager client applications require that each document item type has a base part.
Typically, document item types have ICMBASE (base part), ICMANNOTATION (graphical
annotations that overlay the base part), and ICMNOTELOG (separate textual comments).


There are additional parts (ICMBASETEXT and ICMBASESTREAM) available:
ICMANNOTATION Contains additions to, or commentary about, the main data;
following the document metaphor, annotations include sticky notes,
color highlights, stamps, and other graphical annotations in the text
of a document. These are the typical annotation parts from
previous releases of Content Manager. Using the Client for
Windows or the eClient, your users can create graphical
annotations, which are viewed on top of the file or document being
displayed. Most client applications can show or hide these
annotations.
ICMBASE Contains the fundamental content of a document item type that
stores any non-textual type of content, including image and audio.
Requirement: To be viewable in the eClient, all document item
types must include at least one base document part.
ICMBASETEXT Contains the fundamental content of a document item type that
stores text content. If you plan to index a text part of your
document, store the part in this part item type. Indexing a text part
enables a text search to be performed on the content of the part.
ICMNOTELOG Contains a log of information entered by users, for example,
indicating the reason that the insurance application was denied or
instructions to the next reviewer of the document. These are the
typical notelog parts from previous releases of Content Manager.
Using the Client for Windows or eClient, your users can create,
view, and edit notelog parts. Notelog parts contain the user
account, time stamp, and text comments as entered by client users.
ICMBASESTREAM Contains streamed data, such as video.
To configure the library server, follow these steps:
a. Expand Data Modeling in the system administration tree.
b. Right-click Item Types and click New to open the New Item Type Definition window, as
shown in Figure 8-51:
i. On the Definition page, in the Name field, type a meaningful name. Item type
names are case-sensitive and must be unique. Use names that are easy to
remember and that reflect the folders and documents are included in item type.

Naming conventions: The item type names in our example reflect the use of
Tivoli Storage Manager and the retention period. These names might not be
relevant in your situation, and you might prefer to use names that reflect the
folders and documents that are included in your environment.

ii. Click Translate to open the Translate Display Name window. All of the available
languages defined in the system are listed. In the Translated Name column, type
the translated display name for the other languages.
Click OK to save the information.
iii. In the New version policy field, select Never create. In the Item type classification
list, specify the new item type as Document. In the Item retention period field,
select the retention period for the item. This number is the expiration date
calculated by the library server when an item is created. See Figure 8-51 for other
settings.


Figure 8-51 New Item Type Definition window: Definition tab

iv. Click the Access Control tab. On the Access Control page, in the Access control
list field, select PublicReadACL. In the Access control list checking field, specify
whether the access control list applies to the item type level or item level. For
example, choose Item type level. See Figure 8-52.

Figure 8-52 New Item Type Definition window: Access Control tab


v. Click the Attributes tab. On the Attributes page, select the attributes or attribute
groups that you want to add into the item type from the Available attributes or
groups list. Click Add to add them to the Selected attributes and components list.
See Figure 8-53 for an example.

Figure 8-53 New Item Type Definition window: Attributes tab

In our example, the use of the Auto-linking, Foreign Keys, Logging, and User Exits
tabs is optional. Check if this is also true for your environment.
vi. Click the Document Management tab. On the Document Management page,
click Add to open the Define Document Management Relations window, as shown
in Figure 8-54. In the Part type field, select a first part (ICMANNOTATION) to
associate with the document item type. From the Access control list drop-down list,
select an access control list (PublicReadACL) to associate with the part type. In
the Resource manager field, select the resource manager (RMDB) on which the
part type is stored. In the Collection field, select the collection (TSMWSCOLL_1Y)
on which the part is stored. In the New version policy field, specify a version policy
(Never create) for the part type. Click Apply to apply the first document
management relation.


Figure 8-54 Define Document Management Relations window

vii. In the Part type field, select a second part (ICMBASE) to associate with the
document item type. From the Access control list, select an access control list
(PublicReadACL) to associate with the part type. In the Resource manager field,
select the resource manager (RMDB) on which the part type is stored. In the
Collection field, select the collection (TSMWSCOLL_1Y) on which the part is
stored. In the New version policy field, specify a version policy (Never create) for
the part type. Click Apply to apply the second document management relation.
viii.In the Part type field, select a third part (ICMNOTELOG) to associate with the
document item type. From the Access control list, select an access control list
(PublicReadACL) to associate with the part type. In the Resource manager field,
select the resource manager (RMDB) on which the part type is stored. In the
Collection field, select the collection (TSMWSCOLL_1Y) on which the part is
stored. In the New version policy field, specify a version policy (Never create) for
the part type. Click OK to apply the third document management relation and to
close the window. See Figure 8-55 for the results.

Figure 8-55 New Item Type Definition window: Document Management tab

Click OK at the bottom of the New Item Type Definition window. This saves the
configuration of the new item type.


c. Repeat this procedure to create two more item types (TSMARCHIVE_3Y, TSMARCHIVE_5Y)
with the appropriate settings. The library server now contains three item types created
for archive purposes, as shown in Figure 8-56. The three item types are associated
with the Information Archive System Storage Archive Manager server as a storage unit,
and they provide archive retentions of one year, three years, and five years.

Figure 8-56 Data Modeling: Item Types

Testing the archive features with IBM Content Manager Client
Use the Content Manager Client for Windows for testing of the archive functions and the
retrieval of documents:
1. Start the Content Manager Client for Windows.
2. In the Welcome window, in the Server field, select the library server to which you want to
connect, for example, ICMNLSDB. In the user account and Password fields, you must
provide a user with the authority to import and search data on the library server. For
example, use icmadmin as a user.


3. Next, two windows open at once. Use the Welcome - Select an Action window, or the
regular Client for Windows window for the further tasks (Figure 8-57).
We prefer to use the regular Client for Windows window instead of the alternative
Welcome - Select an Action window. Therefore, we mark the “Do not show this again” box
and close the latter window.

Figure 8-57 Initial Welcome - Select an Action panel

4. In the regular Client for Windows window, go to File  Import to open the Import window.
5. In the Import window, click Add Files to Import and select the files you want to archive
from the list. Use the buttons in the upper part of the window to navigate to the folder
where the data can be found and click one or more of the files you want to import.

Tip: If you select more than one file, only select files of the same type and where you want
to use the same retention policy. Because in the next step you will select the file type for all
selected files, and you select the retention policy (Item Type), the files must be of the same
type.

The files will be displayed in the File name field. Click Open.


6. Back in the Import window, you now see the selected files in the Files to be imported field.
With the File Type pulldown-menu, select the type of file that is appropriate for your files,
that is, JPEG Image. In the Item Type pulldown-menu, select the appropriate retention
policy, i.e TSMARCHIVE_1Y. The fields Timestamp and user account are automatically filled
by the client, but you can fill in any other information, if that is necessary (Figure 8-58).

Figure 8-58 Content Manager Client: Import window

Click Import to import the selected files. The Content Manager Client starts importing the
files and shows the progress in an import progress window, as shown in Figure 8-59.

Figure 8-59 Content Manager Client: Import progress window

7. Repeat the foregoing procedure twice to import two more files. Select various files each
time. For the first file, in the Item Type field, select TSMARCHIVE_3Y. For the second file,
in the Item Type field, select TSMARCHIVE_5Y. When finished, click Close.


8. In the regular Client for Windows window, go to Search  Basic to open the Basic Search
window. In the Item Type pulldown-menu, select the item type TSMARCHIVE_1Y and use
the default search parameters for a general search. See Figure 8-60 for an example of
search results from this kind of search.

Figure 8-60 Content Manager Client: Basic Search window

9. Double-click one of the files matching your search criteria. The integrated document
viewer will display the file content as demonstrated in Figure 8-61.

Figure 8-61 Content Manager Client: File view - Solution-Gnome-1Y.JPG


8.2.4 Integrating Content Manager OnDemand with System Storage Archive
Manager Collection
A Content Manager OnDemand system contains a library server and one or more object
servers. The object server stores data objects in its cache file systems, which can be defined
on locally attached or SAN-attached storage. The object server also supports archive storage
systems. The UNIX and Windows platforms’ OnDemand object server supports Tivoli
Storage Manager as their archive repository and uses the Tivoli Storage Manager API to
communicate with and transfer data objects to archive storage.

When data is loaded into the OnDemand system, OnDemand creates objects, which hold the
compressed data and store it in its cache file systems. These objects can also be archived to
Tivoli Storage Manager at the time the data is loaded into OnDemand, or after the objects
have been stored in the OnDemand cache storage for a predetermined amount of time. This
hierarchical use of storage is useful for storing data on fast access devices such as disk
(online) during the time of the highest likelihood of access to the data and then migrating to
archive storage.

Instead of the IBM Tivoli Storage Manager you can also utilize the IBM System Storage
Archive Manager in an IBM Content Manager OnDemand environment. Hence, you also can
use the Information Archive System Storage Archive Manager Collection with IBM Content
Manager OnDemand.

Configuring OnDemand for Tivoli Storage Manager archive management
There are several steps that you need to complete to enable Content Manager OnDemand to
use the IBM Tivoli Storage Manager server, an IBM System Storage Archive Manager, or a
System Storage Archive Manager Collection. To keep things simple, we use these three
products interchangeably, and refer only to IBM Tivoli Storage Manager:
1. You must have a Tivoli Storage Manager server, and the policies must include archive
copy groups with retention values coinciding with the retention requirements of the
application groups in OnDemand that will use Tivoli Storage Manager.
2. You must register a node in that Tivoli Storage Manager policy domain.
3. The Tivoli Storage Manager API software must be installed and configured on the
OnDemand object server.
4. Several options must be set in OnDemand to let the system use Tivoli Storage Manager.

In an OnDemand for Windows system, the OnDemand configurator is used to set this
parameter so that you can use the Tivoli Storage Manager server as an archive manager. In
an OnDemand UNIX-based system, the ars.cfg configuration file is updated to specify that
Tivoli Storage Manager is to be used.

OnDemand for Windows and Tivoli Storage Manager configuration
To enable OnDemand to access a Tivoli Storage Manager server for archive management,
1. On the object server, install the following components:
a. Tivoli Storage Manager backup-archive client
b. Tivoli Storage Manager API
c. Tivoli Storage Manager administrative client command-line files
2. In the Storage Manager administrative command-line client, name the OnDemand storage
node (we named it ODARCHVE) and register it in the standard domain:
register node ODARCHIVE password domain=standard


3. Use the OnDemand Configurator for these steps:
a. Start the OnDemand for Windows configurator and then select Instances. Click the
instance_name of the instance you want to enable for Tivoli Storage Manager use.
b. Select the Storage tab.
c. In the Configuration area at the top of the Storage tab, select the TSM option.
d. After selecting TSM, click TSM Options. Enter the path to the Tivoli Storage Manager
program files directory of the Tivoli Storage Manager API and the path to the Tivoli
Storage Manager options dsm.opt file, as shown in Figure 8-62. Click OK. On the
Storage tab, click Apply.

Figure 8-62 OnDemand for Windows configuration

e. You will see a warning stating that the OnDemand services must be restarted for the
changes to take effect, as shown in Figure 8-63.

Figure 8-63 Updating the OnDemand instance

4. Use the OnDemand Administrator for these steps:
a. Start the OnDemand Administrator client by selecting Start  Programs  IBM
OnDemand32  OnDemand Administrator. Log on to the OnDemand server.


b. Navigate to the Storage Sets icon and select the storage set that you want to update. In
our case, we chose the storage set Library Server.
c. Right-click and select Update storage set.

Figure 8-64 Update the storage set

d. On the next window, choose the primary object server *ONDEMAND, and click Update
to update the primary object server named Library Server, as shown in Figure 8-65 on
page 317. This brings you to the Update a Primary Node window.

Figure 8-65 Update a Storage Set window

e. From the Update a Primary Node window (Figure 8-66), perform these steps:
i. Clear the Cache Only check box.
ii. In the Logon field, enter the Tivoli Storage Manager node name that you registered
with the System Storage Archive Manager server; see 8.2.3, “Integrating Content
Manager with Information Archive System Storage Archive Manager Collection” on
page 290.


iii. In the Password field, enter the password you entered when registering the node to
Tivoli Storage Manager and verify the password.
iv. You can update the Description field to reflect that this is no longer a cache-only
primary storage node.
v. Select OK in the Update a Primary Node window.
vi. Now, you can update the description of the storage to reflect that this is no longer a
cache-only storage set. Then, select OK in the Update a Storage Set window (see
Figure 8-65).

Figure 8-66 Update Primary Node windows

f. This storage set is now able to store objects to the System Storage Archive Manager
server. You now need to create or update an application group to use the new settings.
5. Use the OnDemand Administrator for these steps:
a. Navigate to the Application Groups icon and select the application group that you want
to update. In our case, we chose the application group jpeg1.
b. Right-click and select Update, as shown in Figure 8-67.

Figure 8-67 Update an Application Group


c. Select the Storage Management tab from the Update an Application Group window.
From the Storage Set Name list, choose the name of the storage set you updated in
the previous steps (Figure 8-68 on page 319).
d. Set the Cache Data values. The cache data setting determines if the report data is
stored in the DASD cache, and if so, how long it is kept in cache before it expires. You
can also choose to have the cache searched or not searched when retrieving
documents for viewing. If you choose not to store reports in cache, a storage set that
supports archive storage must be selected.
e. The Life of Data and Indexes values determine when OnDemand can delete reports,
resources, and index data from the application group. Choose from:
• Never expires: OnDemand maintains application group data indefinitely.
• Expires in __ Days: After reaching this threshold, OnDemand can delete data from
the application group. The default value is 2555 (seven years). The maximum value
that you can type is 99999 (273 years).

Important: If you plan to maintain application group data in archive storage, the
length of time that the archive storage manager maintains the data must be equal
to or exceed the value that you specify for the Life of Data and Indexes fields.
Consult the IBM Content Manager OnDemand for Multi platforms: Administration
Guide, SC18-9237 for more information.

f. Do not select the Cache Data option. Click the Advanced button.

Figure 8-68 Update an application group storage management

g. In the Advanced Storage Management window, choose when you want to have data
objects migrated from the OnDemand cache file system to the System Storage Archive
Manager server. If you leave When Data is Loaded option selected, each time data is
loaded by the OnDemand applications into OnDemand, the objects are stored in the
cache file system and to Tivoli Storage Manager archive storage at the same time.


This configuration setting has the advantage that if the cache file system of this
OnDemand object server is damaged (disk failure), the objects are still accessible from
the Tivoli Storage Manager storage.
6. Migrate the data from cache.
This determines when documents and resources are migrated to archive storage:
a. A storage set associated with a Tivoli Storage Manager client node must be selected to
enable migration to archive storage. See Figure 8-69 on page 320.
The possible values are:
• No: Data is never migrated from cache. This option is unavailable when a storage
set associated with a Tivoli Storage Manager client node is selected for the
application group.
• When Data is Loaded: Data is migrated to archive storage when the data is loaded
into the application group.
• Next Cache Migration: Data is migrated to archive storage the next time that
ARSMAINT is run with the -m option. The -m option indicates that data and
resources are to be copied from cache to archive storage.
• After __ Days in Cache: Specifies the number of days that data is to remain in
cache-only storage. After reaching the prescribed number of days in cache storage,
the data is copied to archive storage the next time that ARSMAINT is run with the
-m option for data migration.

Figure 8-69 Advanced Storage Management window

b. Click OK in the Advanced Storage Management window, and OK in the Storage
Management tab of the application group.

You are now able to load data using an application in the application group that we updated.
This data will be migrated to the System Storage Archive Manager server and stored in the
OnDemand cache file system.

Figure 8-70 and Figure 8-71 show the load command used from the OnDemand command
window to successfully load data with the generic indexer and the output of the select
statement used to query the Tivoli Storage Manager database after the load that shows the
object was archived to Tivoli Storage Manager. In this case, it was a System Storage Archive
Manager server.


C:Program FilesIBMOnDemand for WinNTbin>arsadmin load -g jpeg1 -u admin
-p ondemand -i c:arsloadgen.txt -d c:arsload -h ondemand
OnDemand Load Id = >5014-1-0-4FAA-0-0<
Loaded 1 rows into the database
Document compression type used - OD77. Bytes Stored = >9929<

C:Program FilesIBMOnDemand for WinNTbin>

Figure 8-70 Load data to OnDemand with generic indexer, migrate to Tivoli Storage Manager

NODE_NAME: ODARCHIVE
FILESPACE_NAME: CAA
FILESPACE_ID: 1
TYPE: FILE
HL_NAME: DOC
LL_NAME: 2FAAA
OBJECT_ID: 1043
ARCHIVE_DATE: 2010-03-22 20:57:51.000000
OWNER:
DESCRIPTION: IBM OnDemand
CLASS_NAME: STANDARD
select * from archives where node_name=’ODARCHIVE’

Figure 8-71 Select statement output to Tivoli Storage Manager after OnDemand migration

Figure 8-72 illustrates how storage management works in OnDemand.

Application Group

Storage Set

Storage Node

OnDemand Cach
File Systems

IBM Information
Archive

Figure 8-72 Storage management in OnDemand

If you are configuring an OnDemand for UNIX system to use Tivoli Storage Manager for
archive storage, you need to be sure that the ars.cfg file has been updated to reflect that Tivoli
Storage Manager (SSAM) is to be used as the storage manager. The file also needs to
include valid paths for Tivoli Storage Manager options files and all of the Tivoli Storage
Manager components that will be used.


8.2.5 Integrating IBM FileNet P8 with a System Storage Archive Manager
Collection
The main functions of the IBM FileNet P8 platform are content management, business
process management, and compliance.

The IBM FileNet P8 Platform is composed of the following three core products:
IBM FileNet Content Manager
IBM FileNet Business Process Manager
IBM FileNet Records Manager

The IBM FileNet Content Manager serves as the main content management, security
management, and storage management engine for the family of IBM FileNet P8 products.

The main components of these core products are the following engines (see Figure 8-73):
Content Engine:
The Content Engine provides main library services; manages documents, folders, content,
and business-specific objects; and allows content to be stored, retrieved, transformed,
classified, and secured. The Content Engine can manage content stored in a file store, a
database, or a fixed storage device.
Process Engine:
The Process Engine incorporates software services for managing all aspects of business
processes (also called workflows), such as process execution, process routing, rules
management, process simulation and modeling, and workflow analysis
Application Engine:
The Application Engine provides the presentation layer and includes out-of-the-box user
interfaces and components for building custom solutions. The Application Engine is the
component that hosts the Workplace. Workplace provides an interface for adding content
to the IBM FileNet P8 system and for performing other primary content-oriented tasks,
such as declaring records, accessing workflow queues, and searching. Workplace is built
using the IBM FileNet Web Application Toolkit and runs within a Web Container on a J2EE
application server.

Configuring FileNet P8 for a System Storage Archive Manager Collection
In this section, we illustrate how to configure Filenet P8 for integration with Information
Archive System Storage Archive Manager Collections.

FileNet P8 is a functionally rich software product and we only describe aspects of the product
and its functions that are relevant to its integration with Information Archive.

FileNet P8 can be installed on various operating systems, such as Microsoft Windows and
Linux. It is also possible to install specific modules on various physical servers. Some
modules can even be deployed in multiple instances and operate in parallel to create server
farms for load balancing.

Figure 8-73 shows an overview of the major modules and how they interact. There are
generally two WebSphere instances that can be deployed on the same or other servers.
WebSphere Instance 1 is connected to the Application Engine that contains the
Workplace with the user interface.
WebSphere Instance 2 is connected to the Content Engine and uses IBM DB2 as
database, LDAP for user management (see Chapter 7, “LDAP environments” on
page 227) and the IBM Tivoli Storage Manager API.


As you can see in Figure 8-73, the Content Engine offers interfaces to various data stores,
including the IBM Tivoli Storage Manager API that can be used to store contents in a System
Storage Archive Manager Collection in Information Archive.

The Process Engine module allows you to implement Workflow management. This software
component is available only for Windows. We did not use or install that component for the
illustration of the Information Archive integration scenario.

The FileNet Enterprise Manager is the administration tool for the Content Engine. This tool
runs only on Windows and needs the Web Services Enhancement from Microsoft installed.

The FileNet Configuration Manager is the configuration tool for the WebSphere instance of
the Content Engine.

Important: To implement FileNet P8, an LDAP server is required: The Content Engine,
FileNet Enterprise Manager, and WebSphere Instance 2 are connected to the LDAP server
and use the same account to communicate between the components.

FileNet Enterprise LDAP
Manager

FileNet Configuration DB2
Manager

WebSphere Instance 1 WebSphere Instance 2
https://<ip-adr>:9044/ibm/console/ https://<ip-adr>:9043/ibm/console

Application Engine Process Engine Content Engine
Workflow https://<ip-adr>:9080/FileNet/Engine
Workplace
Local Files

(optional)
SnapLock
TSM API

User Interface (GUI)
https://<ip-adr>:9081/workplace

IBM Archive Appliance
DR550 / IBM IA

Figure 8-73 Overview of FileNet Modules and attachment with Information Archive

FileNet P8 for Windows and System Storage Archive Manager
configuration
To use FileNet P8 with Information Archive, you must first prepare the System Storage
Archive Manager Collection in IA.

After creating the System Storage Archive Manager collection, you must also configure the
retention policies for the collection, in accordance with your business needs (for details, see


8.2, “System Storage Archive Manager-based Integration with Information Archive” on
page 266).

Next, you need to register the FileNet Content Manager server in the System Storage Archive
Manager server (register node). The easiest way to do this is to use the IBM Tivoli Storage
Manager administrative command-line client (dsmadmc). The administrative command-line
client is preinstalled and preconfigured on Information Archive. You can start it with the
authority of an IA Archive Administrator or IA System Administrator.

Complete the following steps from the keyboard video mouse (KVM) console at the appliance,
or remotely through a Secure Shell (SSH) connection:
1. Log on to the Management Console server.
2. At the command prompt, enter dsmadmc -server=<collection_name> where
collection_name is the name of the System Storage Archive Manager collection you are
accessing.
3. Enter the user name and password that are eligible for access to the collection.
4. At the command shell, respond to the prompt to enter System Storage Archive Manager
commands (see Example 8-6.)
5. Register a node for the Filenet Content Manager with the System Storage Archive
Manager register node <nodename> <password> passexp=0 command.
6. To exit the shell, enter the quit command.

Example 8-6 System Storage Archive Manager command line interface

Enter your user account: itsoadmin


Session established with server SSAM1: Linux/x86_64
Server Version 6, Release 1, Level 2.2
Server date/time: 02/22/2010 17:29:03 Last access: 02/18/2010 21:53:38

tsm: SSAM1>reg node winsrvfilenet1 <password> passexp=0

Tip: Add the option passexp=0, otherwise the password for the node will expire after a
predefined period of time and you will need to change it again. To avoid this situation, we
prefer to use the unlimited period of time and manually change the password when it is
most convenient.

Preparing WebSphere Instance to use IBM Tivoli Storage Manager API
After registration of your FileNet Content Manager in the System Storage Archive Manager
Collection, you can now configure the FileNet Content Engine to use the IBM Tivoli Storage
Manager API for archiving. Follow these steps:
1. Log on to the WebSphere Instance that is used with the FileNet Content Engine, typically
by entering the following URL in a browser:
https://localhost:9043/ibm/console/


Use the user account and password that were configured during the installation of the
FileNet P8 environment. The default user account is wsadmin. Figure 8-74 shows the
logon menu.

Figure 8-74 WebSphere Instance for Content Engine

If the login is successful, the ISC Welcome window shown in Figure 8-75 is displayed.

Figure 8-75 WebSphere Environment panel


2. At the Welcome window, expand Environment in the navigation tree (Figure 8-76).
3. Click Shared Libraries. The Shared Libraries dialog displays in the middle pane.
4. Click New.

Figure 8-76 Shared libraries - Creation panel


5. In the Shared Libraries configuration dialog (Figure 8-77), under General Properties, fill in
the correct path for classpath and native library path for the generic .dll library files.
Explanation: FileNet brings generic .dll library files on Microsoft Windows that are used to
attach devices to the IBM Tivoli Storage Manager API. The path to those generic library
files has to be defined. In our example, we are defining the shared library TSMAPILIB in
the Shared Libraries window.

Figure 8-77 Details for TSMAPILIB

6. Map the TSMAPILIB library to the IBM TSM API files that must be on a share. Perform the
following steps (see Figure 8-78):
a. In the Navigation tree, expand Application, then Application Type.
b. Click WebSphere Enterprise Application.
c. Mark the check box FileNet Engine.


Figure 8-78 Enterprise Applications window

7. On the configuration panel (Figure 8-79) for the selected resource (FilenetEngine), click
the Reference shared libraries button to map / check the created share.

Figure 8-79 Share library references window


After completing the configuration changes just described, you have to restart the
WebSphere Instance. You can stop and start it with the following procedure:
1. Open a Microsoft command-line window at the server, where the WebSphere Application
Server is running.
2. Stop the server with the following command:
C:Program FilesIBMWebSphereAppServerprofilesAppSrv01bin>startserver
server1
3. Start the server with the following command:
C:Program FilesIBMWebSphereAppServerprofilesAppSrv01bin>startserver
server1

Configuring the FileNet Content Engine
Now that the WebSphere Instance was configured and is ready, you need to configure the
FileNet Content Engine that uses the System Storage Archive Manager Collection. The main
part of this configuration is the creation of a Fixed Content Device. Figure 8-80 offers a
schematic overview of the various logical constructs (in the FileNet Content Engine) that must
be configured and shows how they relate to each other.

Fixed Storage Area Fixed Content Device

IBM TSM
NetApp SnapLock

Image services

Storage Policy

Document Class Content Area Cache

Application Engine
Workplace

Figure 8-80 Overview of configured parameters in the FileNet Content Engine

Fixed Content Device:
A Fixed Content Device is a FileNet Content Engine object providing connectivity to an
independent software vendor's fixed content system. It can be associated with one or
more Fixed Storage Area(s) for actual content storage. The Fixed Content Device also
often refers to the storage device in an independent software vendor's fixed content
system.


FileNet P8 can work with fixed content devices such as these:
– IBM Tivoli Storage Manager API
– NetApp SnapLock
– Image Services
Fixed Storage Area:
A Fixed Storage Area is a file storage area that has a connection to an independent
software vendor's fixed content system providing additional storage capacity and security.
This connection is provided by the Fixed Content Device.
Storage Policies:
A Storage Policy provides mapping to specific physical storage areas and is used to
specify where content is stored for a given class or object with content (for example, a
document). Content Engine supports the mapping of storage policies to one or more
storage objects; therefore, each Storage Policy can have one or multiple Fixed Storage
Areas as its assigned content storage target.
Document Classes:
Before you can add documents to the Content Engine, you must define custom Document
Classes in the object store. There are predefined Document Classes in Enterprise
Manager, which you can use to create custom subclasses for your application. You can
assign custom properties to these subclasses based on the required values that will be
stored with the documents. For example, you might have a “Contracts” document class
with Contract Type, Date, and Company Name properties assigned to it. Additional system
properties such as Creator and Document Title are automatically assigned to the
document class upon creation, and are stored as system properties. All properties can be
inherited by subclasses. See inheritance for more information.
Content Cache Area:
The Content Cache Areas provide a local storage of frequently accessed documents
accessible over the network. These Content Cache Areas allow users geographically
remote from the File Storage Areas to quickly access frequently requested document
content.

In the following sections we describe the configuration of these objects step by step.

You must first configure the access to the Content Engine in the FileNet Enterprise Manager
administration tool and logon. After you start the FileNet Enterprise manager, you can log on
to a Content Engine instance or configure one to log on to. See Figure 8-81.

Figure 8-81 FileNet Enterprise Manager - choose Content Engine instance


You can Add or Edit a connection. In Figure 8-82 we show the configuration settings for our
server WINSRVFILENET1 as an example.

Figure 8-82 FileNet Enterprise Manager - Connection Configuration

Configuring the Fixed Content Device
Configuring the Fixed Content Device means to create the connection from FileNet P8 to the
Information Archive System Storage Archive Manager Collection.

As you can see in Figure 8-83, we created a Fixed Content Device to connect to an IBM
System Storage DR550, and one to use an Information Archive appliance. Hence, you can
create more than one Fixed Content Device. In each Document Class, you decide which one
to use.

Figure 8-83 FileNet Enterprise Manager


To create a new Fixed Content Device, follow these steps:
1. In the left pane of the Content Engine Enterprise Manager window, right-click the Fixed
Content Devices folder. Click New. The Fixed Content Device wizard starts (Figure 8-84).

Figure 8-84 Fixed Content Device Wizard

2. In the Create Fixed Content Device window, click Next.
3. Insert the name and description of the Fixed Content Device and click Next.
Figure 8-85 shows the connection parameter from the Fixed Content Device object.
In our example the TCP/IP address of our System Storage Archive Manager Collection is
9.153.1.26 and this collection uses port 1502. (You can get that information from the
Collection Properties notepad of the IBM Information Archive GUI if necessary).

Figure 8-85 File Content Device - Parameters


4. Scroll down the Configuration Parameters list to enter the node name and password
(that you defined when you created the System Storage Archive Manager Collection).
5. Provide a filespace name that will be used later in the System Storage Archive Manager
Collection. Click Next. The Fixed Content Device finish window is displayed.
6. Click Finish to complete this part.

Configuring the Fixed Storage Area and Storage Policy
Normally, the Fixed Storage Area and Storage policy are two separate objects and are
configured in two separate steps. Because the wizard for creation of the Fixed Storage Area
has an option to generate the Storage Policy object as well, we use this possibility:
1. In the left pane of the FileNet Enterprise Manager window, select Storage Area, then
right-click and select New from the context menu to start the Fixed Storage Area wizard
(Figure 8-86).

Figure 8-86 Create a Fixed Storage Area


The Create Storage Area wizard welcome window is displayed (Figure 8-87).

Figure 8-87 Fixed Storage Area Wizard - Welcome panel

2. Click Next, and select the site for the FixedStorage Area object. If you do not have more
than one site, just select the default.
3. Enter a name for the new Storage Area and enter a description. The name must be unique
in your FileNet environment.
4. Select the type of the Storage Area. Always select Fixed Storage Area as shown in
Figure 8-88, and then click Next.

Figure 8-88 Select the type of Storage Area


5. Each Fixed Storage Area uses its own staging area on a shared filesystem. A shared
filesystem is necessary because the staging area can reside on a separate server, or you
can have more than one Content Engine instance using the same staging area. The
permissions for the shared filesystem have to be at least Contributor for Everyone.
6. Insert the Staging Area path and select the Management class corresponding to the
System Storage Archive Manager Collection in Information Archive as shown in
Figure 8-89. Then click Next.

Figure 8-89 Staging Area path and selected Management Class from the System Storage Archive
Manager Collection

7. In the Create a Storage Area window, leave the default parameters as shown in
Figure 8-90. (You can limit the used storage size, but it is preferable to keep the default
parameters.) Click Next to proceed.

Figure 8-90 Size parameter of the Fixed Storage Area


As mentioned before, you can create the Storage Policy together with the Fixed Storage
Area in the same wizard and step.
8. On the Create a Storage Area window (Figure 8-91), which displays a summary view of
the parameters configured through the wizard, click Finish.

Figure 8-91 Configuration completion panel

At this stage, a new Fixed Storage Area and the Storage Policy are created. Next you have
to configure the various Document Classes used from your Workplace application.

Configuring Document Classes
In FileNet there are various Document Classes preconfigured. You can use these Document
Classes or add your own. You have to configure each of the Document Classes for any
Storage Policy that you want to associate with a particular Document Class. Figure 8-92
shows an example.


Figure 8-92 Example of a document Class

Configuring a Content Cache
All the configuration tasks required to store data from the FileNet P8 Workplace into
Information Archive are now completed. Optionally, you can create a Content Cache to hold
data for faster retrieval. There are a lot of configuration options. In this section, we just
illustrate basic a configuration of the Content Cache.

To configure a Content Cache Area, proceed as follows:
1. As for the Staging Area used in the Fixed Storage Area, you need a shared filesystem for
the Content Cache. This share needs access rights for Everyone, for example Co-owner.
2. In the FileNet Enterprise Manager, expand the Sites, select your Site and select Content
Cache Areas as shown in Figure 8-93.

Figure 8-93 FileNet Enterprise Manager - Content Cache Area


3. In the Cache Properties window (Figure 8-94), check if the settings are in line with the
needs of your environment. There are many parameters that you can optionally define,
besides the name and the share name. For instance, you can create a new Content Cache
Area here or edit the settings of an already configured Content Cache Area.

Figure 8-94 Content Cache Area - Properties

4. In the FileNet Enterprise Manager (Figure 8-95), set the cache limits for your site. These
limits can be set in the properties of the site itself, in the FileNet Enterprise Manager.

Figure 8-95 Site Properties


After the cache configuration is complete, you can use the FileNet Workplace to archive and
retrieve documents.

Archiving documents in FileNet P8
Here we show how to use the FileNet Workplace to archive documents. FileNet P8 comes
with a preconfigured Workplace web application which you can optionally replace with your
own web application. Follow these steps:
1. Open a regular web browser to use the FileNet Workplace. To logon, use the default web
address:
http://<ip-adr>:9081/Workplace
You can also use any specific address that you created during the installation and setup of
your FileNet P8 environment. See Figure 8-96 for a typical login panel of the FileNet
Workplace.

Figure 8-96 FileNet Workplace - Logon

2. In the next window (Figure 8-97), select the object store that you want to use to archive
your documents. In FileNet P8, the default object store is SYSOS, that is, the database
used for the instance. This database stores all the configuration objects and metadata for
archived documents. In our example we used the default SYSOS object store.


Figure 8-97 FileNet Workplace - Object Store selection

3. In the Workplace: Add Document Wizard (Figure 8-98), to create a new document, set the
required parameters, such as the Document Title. Click Next to define which user
accounts have which access rights to the new document.

Figure 8-98 FileNet Workplace - Create a new Document


4. After the security settings are set, select a file to archive in FileNet. In our example we
archive the file New P8 Order.jpg as you can see in Figure 8-99.

Figure 8-99 FileNet Workplace - File selection for new document

5. Click Finish. The next window, as shown in Figure 8-100, indicates that the document was
archived successfully.

Figure 8-100 FileNet Workplace - Order overview panel


6. As a test, try to delete the document. You get an error message as shown in Figure 8-101.
You can delete the document if it has expired (passed its retention period).

Figure 8-101 FileNet Workplace - Error Message

8.3 File archiving-based integration in Information Archive
File Archive Collections are described in Chapter 6, “File Archive Collections” on page 167.
Here we illustrate the use of this type of collection through an example. The goal is to provide
a practical understanding of how to integrate a file archive application with Information
Archive.

8.3.1 Integrating IBM i with an Information Archive File Archive Collection
Our illustration for file collections is based on the IBM i platform. Note that some IBM i content
management applications such as IBM Content Manager OnDemand for IBM i can also
integrate with an Information Archive System Storage Archive Manager Collection through
the IBM Tivoli Storage Manager API interface. Other IBM i applications can access an
Information Archive File Archive Collection by mounting the NFS shares provided by the File
Archive Collection. This is the type of application that we illustrate in this section: The NFS
share is mounted as a directory in the IBM i Integrated File System (IFS).

We document and illustrate the minimum requirements for an NFS based integration
approach. We assume that you have done the following tasks:
Configured Information Archive to use an LDAP server
Configured a File Archive Collection on Information Archive, and that it uses this LDAP
Server
Defined a user in LDAP who has permission to access the File Archive Collection

The LDAP environment can be implemented with an IBM Tivoli Directory Server on IBM i.
We have documented the setup of such an environment in 7.4, “Tivoli Directory Services in
IBM i” on page 242.

Important: The LDAP environment must be in place before you start the Initial
Configuration Wizard (ICW) and the Create Collection Wizard (CCW) on Information
Archive. If you plan to use the IBM Tivoli Directory Server on IBM i, start with the setup of
this environment before proceeding with the ICW.


You also need a user with *SECOFR authority on IBM i to complete the following steps.

8.3.2 Granting access to the File Archive Collection in Information Archive
After you have an LDAP environment and a File Archive Collection already properly
configured and running, you can start using the File Archive Collection as a user (or from an
integrated archiving application) provided that the user (or application) was granted access to
the File Archive Collection.

To grant access, open the File Archive Collection properties by the Information Archive
Integrated Solutions Console web interface (Information Archive GUI). Log on as the
collection owner or any user with the right to grant access to the collection:
1. In the left pane, navigate to Information Archive Management.
2. Under Information Archive management, click Collections.
3. In the right pane, click the Properties link of the appropriate File Archive Collection.
4. In the Collection Properties window, click User and Host Access.
5. From the Select Action pull-down menu, select Grant Access (Figure 8-102).

Figure 8-102 Grant Access to File Archive Collection at Collection Properties


6. To grant access, enter the TCP/IP host name or TCP/IP address of your IBM i system.
Leave Host access level at its default (Write and Read) as shown in Figure 8-103:

Figure 8-103 Grant access for host IBM i to File Archive Collection

Click OK to go back to the File Archive Collection Properties window (Figure 8-102 on
page 343).
7. In the Collection Properties window, click Apply, otherwise your new address will not be
saved and you will later get cryptic errors when mounting the shares, such as the
message:
(CPFA09C: Not authorized to object. Object is *N).


8. In the Collection Properties window (Figure 8-104), click General for the appropriate File
Archive Collection and write down the Access Information (that is, the addresses of the
NFS shares.

Figure 8-104 General information about File Archive Collection - Access information

Now you are ready to proceed with the IBM i configuration and you can leave the IA GUI.

IBM i: Adding the host name of File Archive Collection
Starting with IBM i 6.1, NFS was changed, and when you try to mount an NFS share with its
IP address instead of a TCP/IP host name, you will get an error:
CPDBCC2: A non-recoverable error occurred when attempting to resolve the name

Action: If your File Archive Collection does not have an entry in your DNS server, add it to
the IBM i TCP/IP Host Table.

To add a new entry to the host table, proceed as follows:
1. In a 5250 session, enter the CFGTCP command, then select option “10. Work with TCP/IP
host table entries”.
2. In the menu now displayed on your panel, use option 1 to add a new entry to the host
table.
3. Make sure that the host name search priority must be set to *LOCAL. Check with option “12.
Change TCP/IP domain information” in the CFGTCP menu.
For details, see:
http://www.ibm.com/support/docview.wss?uid=nas1f80aa805b47506fc8625767f0052666d


IBM i: Adding a user profile to access the File Archive Collection
In the beginning of this chapter we made the assumption that there is a user in the LDAP that
can access the File Archive Collection. There is no easy way to make an IBM i system use an
LDAP (if you want to try, read the chapter about Enterprise Identity Mapping in the IBM i
Information Center). The simplest way to make NFS mount work is to create a user account
on IBM i that has the same UID number as the LDAP user.

Example 8-7 shows some lines in the LDIF corresponding to the user in our example.:

Example 8-7 User management on the IBM i
dn: uid=iiasysusr,ou=users,dc=stgt,dc=spc,dc=ihost,dc=com
...
uidNumber: 2000
gidNumber: 1000
…

In this example, the user account is IIASYSUSR and the UID number is 2000. Using this
information, we create a User Profile in an IBM i 5250 session:
CRTUSRPRF USRPRF(IIASYSUSR) TEXT('IIA System User') SPCAUT(*IOSYSCFG) UID(2000)

Attention: According to the IBM i Information Center, a user needs special authority
*IOSYSCFG to be able to MOUNT an NFS share. We found that this is not enough for
mounting the Information Archive File Archive Collection. We added special authority
*ALLOBJ, otherwise the MOUNT will fail. Also be aware that the user IIASYSUSR has, by
default, the password IIASYSUSR, which is not really safe, especially for a user with
*ALLOBJ authority!

IBM i: Creating NFS mount points
A File Archive Collection provides two NFS shares, one to store the archive data, the other to
present the metafiles. Hence, we need two directories in the IBM i IFS (Integrated File
System) to mount both. If you do not want to use the metafiles, for example, when you use
chronological archive policies only and do not want to send Hold or Release events, you only
need to mount the data share. Here is the procedure:
1. Create a directory tree in the IFS, a directory nas1 in the root, and two subdirectories with
the name data and meta.
In a 5250 session, enter the following commands:
MKDIR DIR('/nas1')
MKDIR DIR('/nas1/data')
MKDIR DIR('/nas1/meta')
2. Give those directories proper authorities and ownership by entering these commands:
CHGOWN OBJ('/nas1') NEWOWN(IIA) SUBTREE(*ALL)
CHGAUT OBJ('/nas1') USER(IIA) DTAAUT(*RWX) OBJAUT(*ALL) SUBTREE(*ALL)
This will transfer ownership of /nas1 and its subdirectories to user IIA. It will also give full
read, write, and execute access to these directories.


3. Use the command WRKAUT '/nas1' and check the authorities (Figure 8-105).

Work with Authority

Object . . . . . . . . . . . . : /nas1
Type . . . . . . . . . . . . . : DIR
Owner . . . . . . . . . . . . : IIASYSUSR
Primary group . . . . . . . . : *NONE
Authorization list . . . . . . : *NONE

Type options, press Enter.
1=Add user 2=Change user authority 4=Remove user

Data --Object Authorities--
Opt User Authority Exist Mgt Alter Ref

*PUBLIC *R
IIASYSUSR *RWX X X X X

Figure 8-105 IBM I: Work with Authority

IBM i: Mounting the NFS shares
Proceed as follows:
1. Sign on to your IBM i system with user IIA, then issue the following commands:
MOUNT TYPE(*NFS)
MFS('nas1:/tiam/nas1/data')
MNTOVRDIR('/nas1/data')
OPTIONS('rw,suid,retry=5,rsize=32768,wsize=32768,timeo=20,retrans=5,
acregmin=1,acregmax=3,acdirmin=30,acdirmax=60,hard,async,sec=sys,
vers=3:2,nocache')

MOUNT TYPE(*NFS)
MFS('nas1:/meta/tiam/nas1/meta')
MNTOVRDIR('/nas1/meta')
OPTIONS('rw,suid,retry=5,rsize=32768,wsize=32768,timeo=20,retrans=5,
acregmin=1, acregmax=3,acdirmin=30,acdirmax=60,hard,async,sec=sys,
vers=3:2,nocache')
We have split the commands over several lines to make them more readable. The
parameters are:
– Type *NFS, of course.
– MFS is the address of the File Archive Collection NFS shares.
– MNTOVRDIR is the IFS mount point created in the previous step.
– OPTIONS are the IBM i NFS default options except acregmin=1, acregmax=3, which
we adapted according to the ISV Developers Guide for Information Archive. They result
in minimum caching time of 1 second, maximum caching time of 3 seconds.
– Defaults for all other parameters (CCSID, CODEPAGE)
If the MOUNT fails, be sure to read the joblog.


2. After the MOUNT has completed, be sure to check the authorities using WRKAUT
'/nas1/data’ (Figure 8-106).

Work with Authority

Object . . . . . . . . . . . . : /nas1/data
Type . . . . . . . . . . . . . : DIR
Owner . . . . . . . . . . . . : IIASYSUSR
Primary group . . . . . . . . : *NOUSRPRF
Authorization list . . . . . . : *NONE

Type options, press Enter.
1=Add user 2=Change user authority 4=Remove user

Data --Object Authorities--
Opt User Authority Exist Mgt Alter Ref

IIASYSUSR *RWX X X X X
*NOUSRPRF *NONE X X X X
*PUBLIC *NONE X X X X

Figure 8-106 IBM i: Work with Authority

Compare this output with the authorities of the directory before the MOUNT. Note that
*PUBLIC has no data authority and that *NOUSRPRF has been added, also with no data
authority.

IBM i: Verifying successful access to the File Archive Collection
Proceed as follows to verify the access:
1. In a 5250 session, enter QSH to start the QShell.
2. Copy a file to the /nas1/data directory. There might be a good test candidate in the /tmp
directory of your IBM i system. QSH behaves like a UNIX shell, for example, use the
following command to copy a file with the name test.txt into the File Archive Collection:
cp /tmp/test.txt /nas1/data/
3. Change directory to the File Archive Collection metafile directory and verify the existence
of an automatically created metafile with the same name as the previously archived test
file. Use the following commands for this:
cd /nas1/meta
more test.txt
4. Change directory to the File Archive Collection data share and use the following command
to set a retention period to the test file:
cd /nas1/data
touch -a -t 09041200 test.txt
This command sets the last access date for test.txt to September 4th 12:00 (which, at the
time of writing, was still in the future).


5. Use the following command to set the read-write permission of the file to read-only for the
owner, group, and the rest of the world.
chmod 444 test.txt
With that command, the file is committed to Information Archive and the ingestion starts.
6. Change directory to the File Archive Collection metafile directory and verify the content of
the metafile with the following commands:
cd /nas1/meta
more test.txt
Observe that the procedure was successful. The metafile is filled with meaningful content
and the information from the previous commands is embedded (Example 8-8). It can take
a while for the archive data to be ingested and for the content of the metafile to show up
with the correct information. Until then, you see an empty metafile only.

Example 8-8 Information Archive metafile for the archive data

<fields>

<_SYSTEM_minimumRetention_>Sat Sep 4 12:00:00 2010</_SYSTEM_minimumRetention_>
<_SYSTEM_md5Checksum_>d41d8cd98f00b204e9800998ecf8427e</_SYSTEM_md5Checksum_>

</fields>


9

Chapter 9. Monitoring and call home
In this chapter we describe the monitoring capabilities and features available with IBM
Information Archive (Information Archive).

Using Information Archive functions, you can remotely monitor disk space usage, cluster
node status, Storage Controller performance, and collection status. You can also configure
automatic notifications through email or Simple Network Management Protocol (SNMP) traps.

In addition, you can also use the call home function from IBM Systems Director and RSM.

We cover the following monitoring topics:
Status monitoring
Tivoli Storage Manager Health Monitor
RSM server
Reporting
Logging and tracing


9.1 Status monitoring
You can monitor the IBM Information Archive system status by logging on to the IA GUI, or
through automatic event notifications. Use the Information Archive GUI to remotely monitor
the appliance status. You can also configure automatic notifications to have events sent as an
email or Simple Network Management Protocol (SNMP) traps. You need an IA System
Administrator role to do this.

9.1.1 Health Monitor
Use the Health Monitor page in the Information Archive GUI to view high-level status
information for the appliance, as illustrated in Figure 9-1.

2. Click Health Monitor.

Health Monitor: There is also an IBM Tivoli Storage Manager Health Monitor available.
See “Tivoli Storage Manager Health Monitor” on page 361.

Figure 9-1 Health Monitor page


The Health Monitor page is divided into sections that are each dedicated to a component in
the IBM Information Archive:
Disk Space Usage:
This section displays how much free space is available in each collection (Figure 9-2).

Figure 9-2 Health Monitor Disk Space

Collection Status:
This section displays a count of how many collections are in critical status and how many
are in a warning status (Figure 9-3). A collection is assigned a warning status only if the
amount of remaining disk space is less than 10%. A collection is assigned a critical status
if a hardware component that is assigned to the collection signals any event notification
(for example: Cluster node is down) or if the amount of remaining disk space is less than
5%. An event notification can affect the status of just one collection or all the collections in
the appliance. For example, if there is a problem with the cluster node servers, which all
the collections share, all the collections are assigned a critical status.

Figure 9-3 Health Monitor Collection Status

Hardware Status:
This section displays a count of how many hardware components are in critical status and
how many are in warning. The information in this section comes from IBM Systems
Director, which is included in the appliance. From this section, you can open IBM Systems
Director to get a more specific view on the errors that are associated with the hardware
components (Figure 9-4).

Figure 9-4 Hardware Status

Chapter 9. Monitoring and call home 353

Events:
The event log provides a list of all the events that have occurred on the appliance,
including events that you did not configure notifications for. You can configure how long
events remain listed in this table. By default, each event is deleted after 30 days, whether
or not it has been resolved. A typical listing is shown in Figure 9-5.

Figure 9-5 Health Monitor Events

To get detailed information about the event, you have to click the Event within the Health
Monitor Event view. An Event details window is displayed as shown in Figure 9-6.

Figure 9-6 Event details


Important: Some events are created by the IBM System Director and forwarded to the
IA GUI Health Monitor. When the detailed “event view” shows Source: IBM_DIRECTOR,
you have to open the IBM Systems Director interface using the Service Tools page in the
IA GUI to view the alerts.

Modifying event record retention: You can modify the time period for retaining records of
system events. Records are deleted after the specified time period. System events are
displayed in the Events table of the Health Monitor.

2. Click Health Monitor.
3. In the Events table, click Select Action / Manage Event Records (Figure 9-7).
4. Enter the number of days, and click OK.
5. After completing these steps, click OK or Apply in the properties notebook to commit any
changes.

Figure 9-7 Manage Event Records

9.1.2 Event notifications
You can create event notifications to send emails or generate Simple Network Management
Protocol (SNMP) traps. The event notifications report important status changes or warnings
for system conditions that might require intervention.

All system events are shown on the Health Monitor page of the Information Archive GUI. For
example, an event is generated if there is a change in the status of an appliance component,
or if the amount of available disk space becomes too low. You can create event notifications to
be automatically triggered when specific system events occur.

Event notifications are not the same as the optional call home feature. Both of these features
can be used to send an automatic notification when an error occurs. However, the call home
feature sends information to the IBM Support Center, while event notifications are only sent to
the email addresses or SNMP listeners that you specify.

Configuring event notification methods
Before you can create event notifications as explained in “Creating event notifications”, you
must configure at least one notification method (email or SNMP traps).

3. Click Properties in the General Settings section.


4. Click the Event Notification tab in the Appliance properties notebook as shown in
Figure 9-8.

Figure 9-8 Configure Event notification page

5. Click Select Action  Configure Notification Method.
6. Enter your values as shown in Figure 9-9. You can use the Test Notification Configuration
button to send a test email to the default list of email recipients.

Important: The Sender email address must be a valid email address, otherwise you
will get a delivery error message.

Figure 9-9 Configure Notification Method

7. Click OK or Apply in the properties notebook to commit the changes.


Creating event notifications
You can create an event notification so that if the appliance status matches a defined
condition, an SNMP trap or an email is sent.

Tip: You must configure at least one event notification method before you can create an
event notification.

To create an event notification, log on to the Information Archive GUI and complete the
following steps:
4. Click the Event Notifications tab in the appliance properties notebook.
5. In the table, click Select Action / Create Notification (Figure 9-10).

Figure 9-10 Select Action Task

Default notifications: There is a predefined set of notifications configured called
default, which includes a set of critical and warning messages. You can modify this set
or use it with default settings.


6. Click Add to select from a list of predefined status events as shown in Figure 9-11. Select
the check box for the events that you want to be notified of. The events are all messages
that are also visible in the Health Monitor. Click OK when the selection is completed.

Figure 9-11 Select Event Notifications

7. Enter changes into the form as shown in Figure 9-12 and click OK.

Figure 9-12 Configure Event Notification


8. After you complete these steps, click OK or Apply in the properties notebook to commit
the changes.

The information sent by trap or email is similar that shown in Example 9-1.

Example 9-1 Example email notification
Tivoli Information Archive Manager Notification Message

Severity: critical
Event: HTTP server is down
Timestamp: Mar 2, 2010 1:41:51 PM GMT+00:00

Appliance: IA-Primary
Appliance type: 2231
Appliance model: IA3
Appliance Serial number: 7800200
Details: CTJIM0103E The HTTP server on cluster node ianode1 is down.

Testing event notifications
After configuring an event notification method, you can test the configuration by sending a
test email or SNMP trap.

Testing event notifications by Information Archive GUI
To test the event notifications, log on to the Information Archive GUI and complete the
following steps:
4. Click the Event Notification tab in the appliance properties notebook.
5. In the table, click Select Action / Configure Notification Method.
6. Click Test Notification Configuration. Depending on the notification methods configured,
a test email (see Example 9-2) is sent to the default email recipients and a test SNMP trap
is sent to the SNMP listener. A message is displayed as shown in Figure 9-13.

Figure 9-13 Test Event Notification

Example 9-2 Test notification email
IBM Information Archive event notification message:
This is an automated notification test message. You are receiving this message
because you have been identified as a default E-mail recipient.

Testing event notifications by Information Archive CLI
To test event notifications through the Information Archive CLI, log on to the Information
Archive CLI and complete the following steps:
1. Access the Information Archive CLI using the command iacli.sh.
2. Enter Username and Password to log on.


3. Run the command sendtestalert -type E-mail or sendtestalert -type snmp to verify
that the notification is working. This is shown in Example 9-3.

Example 9-3 Example Test notification by Information Archive CLI
IACLI> sendtestalert -type E-mail
CTJIC0156I The event notification test was successful. A test E-mail notification
was sent to the default E-mail recipients.

Modifying event notifications
You can modify an existing notification to change which event causes the notification, the
notification method, and the recipient of the notification. The notification name cannot be
modified after it has been created.

4. Click the Event Notification tab in the appliance properties notebook.
5. In the table, select the radio button from the notification you want to modify.
6. Click Select Action / Modify Notification.
7. Enter changes into the form.

After completing these steps, click OK or Apply in the properties notebook to commit any
changes.

Deleting event notifications
You can remove a notification to no longer be alerted of specific appliance status changes.

4. Select the radio button in front of the Event Notification that you want to delete.
5. Click Select Action / Delete Notification.

After completing these steps, click OK or Apply in the properties notebook to commit any
changes.

Obtaining Management Information Base files
The IBM Information Archive Management Information Base (MIB) files are required for use
with applications like the IBM Tivoli Enterprise Console® to manage Information Archive
event notifications that are sent as SNMP traps.

The Information Archive MIB files can be obtained from the Management Console server in
the appliance or from the Information Archive support website.
1. To obtain the MIB files from the Management Console, log in to a remote UNIX system
and enter the following command:
scp iaadmin@mc_address:/usr/share/snmp/mibs/IBM*IA*.txt
where mcs_address is the address of the Management Console server. When prompted,
enter the password for the iaadmin user account. Two MIB files are copied to the local
directory on the remote UNIX system.


2. To obtain the MIB files from the Information Archive support website, start a web browser
and go to:
http://www.ibm.com/systems/support/storage/disk/InformationArchive

You need these two files:
IBM-IAM-NOTIFICATION-MIB
IBMIA-TC-MIB

9.2 Tivoli Storage Manager Health Monitor
Use the Tivoli Storage Manager Health Monitor to determine the overall status of server
operations and to obtain detailed information about client node schedules, the server
database and recovery log, and the status of storage devices managed by the server. The
IBM Tivoli Storage Manager Health Monitor also provides access to the server activity log,
allowing you to view messages generated during server operations.

The IBM Tivoli Storage Manager Health Monitor, shown in Figure 9-14, analyzes the
information it obtains from each server to present an overall health status:
Normal (green):
The server is running and the Health Monitor identified no problems.
Warning or Needs Attention (yellow)
The Health Monitor detected conditions that might develop into significant problems. You
need to take preventive actions for the server's database, storage devices, or both. Click
the server name for details.
Critical or Error (red):
The Health Monitor detected significant problems in the server's database, storage
devices, or both. The problems prevent the server from operating normally. For example,
the database or recovery log is out of space, or a library is not functioning. Click the server
name for details.
Unknown (blue):
The server cannot be contacted. Possible causes include these:
– The server is not currently running.
– Network problems are preventing communications with the server.
– The administrator name that the Health Monitor uses, ADMIN_CENTER, is locked or
does not exist on the server.
– There were internal errors in the Health Monitor.

Click the server name to get more information about possible causes.


Figure 9-14 IBM Tivoli Storage Manager Health Monitor Main Page

9.2.1 Configuring the Tivoli Storage Manager Health Monitor
The Tivoli Storage Manager Health Monitor uses a predefined administrator account,
named ADMIN_CENTER, to obtain status information. The ADMIN_CENTER account is
automatically created on each Tivoli Storage Manager server during installation. Before you
can use the Health Monitor, this administrator's initial password must be reset. You must
configure the Health Monitor as shown below so that the required password reset is
performed for all of the servers that have been added to the Administration Center.

2. Click Health Monitor. An illustration is shown in Figure 9-15.

Figure 9-15 IBM Tivoli Storage Manager Health Monitor

3. Click Select Action and select Configure Health Monitor as shown in Figure 9-16.


Figure 9-16 Select Action Health Monitor

4. Enter the password and click OK, as illustrated in Figure 9-17.

Figure 9-17 ADMIN_CENTER Password

5. After the password is entered, you have to resynch the Health Monitor password:
Click Select Action and Resynch the Health Monitor Password as shown in
Figure 9-16 on page 363. After the password is valid on all servers, you get a message as

Figure 9-18 Resynchronize Password

9.2.2 Detailed health information for a server
Use the Detailed Health Information portlet to view details about server status, including how
key processes and devices are performing.

2. Click Health Monitor. A window similar to the ones shown in Figure 9-19 is displayed.
3. Click the Server Name or use the Select Action Scroll Menu.


Figure 9-19 IBM Tivoli Storage Manager Health Monitor Overview

The window is divided into the following sections:
Schedule Information:
The information is a summary of the results of client schedules in all policy domains for the
last 24 hours. To search for more information about the results of schedules, expand the
Activity Log section, and use the client node name or schedule name as a filter for viewing
the activity log.
Database Information:
The information in this section is the analysis that the Health Monitor performed for the
server's database to determine its status. A database-backup hyperlink appears if the
database has not been backed up within the past 24 hours. From the analysis, the Health
Monitor generates a list of links to actions that need to be or can be performed.
Activity:
Tables in this section display information about currently running server sessions and
processes. A session is established each time an administrator or client node connects
with the server. The server starts a process for each task that it performs.
Activity Log:
The information shows the number of warning and error messages in the activity log in the
last 24 hours. If you make no changes for filtering the activity log and click Update Table,
the list includes all messages in the activity log.
Storage Device Status:
The status is a summary of the availability of all libraries and drives for the server. When a
volume is present in the drive, the status column displays the status of the volume.
Otherwise, the status column indicates whether the drive is online or offline.


9.3 Using IBM Systems Director in Information Archive
You can use IBM Systems Director to diagnose and troubleshoot IBM Information Archive
hardware errors. IBM Systems Director is an application that is installed on the Information
Archive appliance to manage the hardware components. If a hardware error occurs, a system
event is generated.

Event notifications
If you have created hardware-related event notifications, you are notified of the event by email
or an SNMP trap. A summary count of hardware errors is also shown on the Health Monitor
page of the Information Archive GUI.

The included IBM Systems Director monitors the following appliance components:
Cluster Node (2231 Model S2M)
Management Console (2231 feature code 5600)
RSM server (2231 feature code 5601)
Ethernet switches
SAN switches

Call home feature
IBM Systems Director provides the call home feature for the following Information Archive
hardware components:
Cluster nodes
Management Console server
IBM Remote Support Manager Server

IBM Systems Director supports the call home feature through the IBM Electronic Service
Agent™ tool, which is integrated into the IBM Systems Director Service and Support
Manager plug-in that is included with the Information Archive version of IBM Systems
Director.

Call home: Do not get the IBM Systems Director call home feature confused with the RSM
call home feature, also possible with the Information Archive. RSM provides call home for
the storage controllers only.

9.3.1 Configuring IBM Systems Director
You can configure IBM Systems Director to report problems on the cluster nodes, RSM
server, and management server. The IBM Systems Director component of IBM Information
Archive includes the Service and Support Manager plug-in, which uses the Electronic Service
Agent tool to automatically monitor and collect hardware problem information and send this
information to IBM support.

The administrative user role required for this task is IA System Administrator. Log on to the
Information Archive GUI and complete the following steps:
3. Click Open IBM Systems Director. The IBM Systems Director web interface opens as


4. Log on to the web interface, using the iaadmin user account and the password that you
specified in the Initial Configuration Wizard.

Figure 9-20 IBM Systems Director logon panel

5. On the Manage tab of the Welcome page, click Service and Support Manager.
You might have to scroll down the page to see the Service and Support Manager link
(Figure 9-21). Click the Service and Support Manager link to launch the Service and
Support Manager Getting Started wizard. This wizard configures the Electronic Service
Agent tool.

Figure 9-21 Service and Support Manager


6. Complete the Getting Started wizard (Figure 9-22) using the information supplied on the
planning worksheet.

Figure 9-22 welcome panel

Click Next.
7. You must specify contact information as shown in Figure 9-23 so that IBM support knows
whom to contact about the problem.

Figure 9-23 company information panel

Click Next.


8. Specify the System location information so that IBM support can route problem reports to
the appropriate support center. An example is shown in Figure 9-24.

Figure 9-24 location panel

Click Next.
9. You must configure the management server to use an existing Internet connection so that
the Service and Support Manager can report problems and send service information to
IBM support. On the Connection page shown in Figure 9-25, click Test Connection to
ensure that the specified connection method can successfully connect to the Internet.

Figure 9-25 Connection proxy information

Click Next.


If the connection test was successful, you get the message shown in Figure 9-26.

Figure 9-26 Test connection

10.You need an IBM ID to view service information that was sent to IBM support by the
Service and Support Manager (Figure 9-28).

Figure 9-27 Authorize IBM ID panel

Click Next.
11.On the “Automatic monitoring” page, select the Yes, automatically discover and
monitor eligible systems check box if not already selected. See Figure 9-28.
Click Next.

Figure 9-28 Automatically monitoring discovery


12.The Summary panel of the Service and Support Getting Started Wizard displays a
summary of the information you specified and selections that you made to complete the
wizard. Review the information provided on the Summary panel shown in Figure 9-29 to
ensure that the information is correct.
Click Finish.

Figure 9-29 Summary panel

9.3.2 Working with IBM Systems Director
You can use IBM Systems Director to see the operating status of each subcomponent in the
appliance. This section describes how to discover devices, where to look for hardware related
problems, and how to use the event log.

“No access” error for the IBM Systems Director
Use the procedure given in this section to troubleshoot the IBM Systems Director when an
Integrated Management Module (IMM) has a status of “No access” as shown in Figure 9-31.

The Navigate Resources page displays the status of the appliance subcomponents. If an IMM
has a status of No Access, the IBM Systems Director cannot report errors for the associated
subcomponent. This error typically occurs after the IBM Systems Director is restarted or the
IBM Information Archive is upgraded.


Follow these steps to investigate the error:
1. Access the IBM Systems Director and log on using the iaadmin user account and
password. For more information, see “Accessing the IBM Systems Director” on page 101.
2. Click Navigate Resources in the navigation tree as shown in Figure 9-30.
3. In the Groups table, click All Systems.

Figure 9-30 Navigate resources

For each IMM that has an Access status of No access as shown in Figure 9-31, use the
following steps:
1. In the System table, click No access for one of the systems.

Figure 9-31 No access example


2. In the Request Access panel (Figure 9-32), User ID field, type USERID (case sensitive).
In the Request Access Password field, type PASSW0RD (case sensitive; PASSW0RD
includes a zero). Click Request Access. These are the default IMM passwords, which
cannot be changed.

Figure 9-32 No access panel

3. Check the Selected targets table at the bottom of the Request Access panel as shown in
Figure 9-33 and verify that the Access column has a status of OK.

Figure 9-33 Request access panel


If the status does not change to OK, use the following steps to remove and rediscover the
IMM and its subsystem. A rediscover will only discover an internal appliance server:
1. In the All Systems table, click the name of the IMM that has the “No access” status. The
Navigate resources window shown in Figure 9-34 displays.

Figure 9-34 Properties window

2. From the Navigate Resources (Properties) page, click the Inventory tab to get the window

Figure 9-35 inventory tab

3. From the Collected Items navigation tree, click System - Operating System.


4. In the Inventory details window: Operating System table, right-click the entry and select
Remove as shown in Figure 9-36.

Figure 9-36 Remove inventory

After removing the inventory, you get the message shown in Figure 9-37.

Figure 9-37 Removing message

5. In the left-hand navigation tree, expand Inventory and click Advanced System Discovery.
A window is shown as illustrated in Figure 9-38.

Figure 9-38 inventory advanced system recovery


6. In the Advanced System Discovery table, select all of the profile names and click Run.
In the pop-up menu in Figure 9-39, select Run Now and click OK.

Figure 9-39 Run system discovery

In the detailed view, you can verify the status from the discovery process (Figure 9-40).

Figure 9-40 Discovery process

7. Click Navigate Resources in the navigation tree. In the Groups table, click All Systems
and check for the IMM that you removed. Ensure that it has been added and that the
Access status is OK.


Resetting status entries in IBM Systems Director
You can use IBM Systems Director to reset the system status after a hardware failure has
been corrected. You can also use it to suppress the display of an error that you are aware of.
but has not yet been resolved. For example, if a hardware problem has occurred and IBM
Service has been scheduled, you can reset the status for this system so you can be notified if
a new failure occurs on the same system.

You have to open IBM Systems Director, log on using the iaadmin user account, and
1. In the IBM Systems Director Welcome page, click the Manage tab, and then click
Navigate Resources in the Discovery Manager area. The Navigate Resources shown in
Figure 9-41 is displayed.
2. From the Groups properties page, click the group name 2231 IA3 serial_number. In our
example, this is 2231_IA3 7800200.

Figure 9-41 IBM Systems Director Navigate window


3. Locate and click the node with the problem to display the properties page for that node.
An example is shown in Figure 9-42.

Figure 9-42 IBM Systems Director Navigate window 2

4. Click the Event Log tab to display recent activity, and to view additional information
regarding a particular system status.
5. Click the Active Status tab.
6. Click the system status instance that you are interested in. The Ignore and Delete buttons
become active. An illustration is shown in Figure 9-43.

Figure 9-43 Active status window

7. Click Delete to remove the instance from the page. The status on the properties page
change to OK.

Important: Do not click Ignore. Clicking Ignore will cause the system to ignore this type of
event until otherwise specified. If you do accidentally click Ignore, you can reactivate a
status by clicking the Status tab, selecting the item, and clicking Activate.


Viewing hardware errors using the Status Manager
You can use IBM Systems Director to view the configuration and status information for each
of the appliance hardware components. The status information is useful for diagnosing
hardware errors that have been reported by the archive appliance Health Monitor. IBM
Systems Director creates an Information Archive group that includes all nodes, and switches
(both Fibre Channel and Ethernet) that are in the appliance. You can navigate to this group to
view hardware status and events at the group or node levels.

There are various possibilities to show the Hardware errors in the IBM Systems director. The
preferred one is using the Status Manager. This page helps you manage the status,
problems, and events for the systems in your environment.

1. In the Welcome window, click Status Manager as shown in Figure 9-44.
A status window is displayed as shown in Figure 9-45.

Figure 9-44 Status Manager button

Figure 9-45 Status Manager panel

2. Click Critical to show the actual errors.
3. Use the Status tasks to get more information about the health or errors within the
appliance. There are four status tasks available as shown in Figure 9-45.
– Health summary
– View problems
– View active and ignored status
– Groups by status


IBM Systems Director event log
The IBM Systems Director event log is a list of appliance-generated event records that are
used to aggregate important status changes or warn of system conditions that might require
intervention. The event log within IBM Systems Director supports logging hardware events
from all hardware components except for the iPDUs.

IBM Systems Director events are the source for hardware status summaries that are shown
in the Information Archive GUI Health Monitor. The IBM Systems Director event log is useful
because you can use it to diagnose hardware errors for Information Archive components.

If a hardware component has multiple failures, the event is counted only once with the highest
severity level. To resolve the errors in the Information Archive Health Monitor, the events must
be resolved from the IBM Systems Director.

If the severity of a hardware error does not affect the operation of the appliance, it is not
reported to the Information Archive Health Monitor. The hardware error severity is listed in the
IBM Systems Director event log.

IBM Systems Director does not issue software-related events. However, some software
related events are caused by hardware problems. For example, a network error can be
caused by a malfunctioning network card. These types of errors can sometimes be difficult to
diagnose because if the error severity is not critical or warning, the hardware problems are
not reported in the Health Monitor. If you suspect that software problems are caused by a
hardware problem, use the IBM Systems Director event log to investigate the cause.

Viewing event logs
To see the event log, you have to open the IBM Systems Director, log on using the iaadmin
user account, and complete the following steps:
1. Expand System Status and Health in the IBM Systems Director navigation tree.
2. Click Event log.

You can filter the events that are listed in the table to help you find a specific event. Click All
Events and select an event category as shown in Figure 9-46.

Figure 9-46 IBM Systems Director event log


Configuring IBM Systems Director event logs
You can configure how many IBM Systems Director events are saved in the log and for how
long. Events that expire from the event log are not included in the hardware status summary
in the Information Archive GUI.

1. Expand System Status and Health in the IBM Systems Director navigation tree.
2. Click Event Log.
3. Click Event Log Preferences in the lower left corner of the page as shown in Figure 9-47.

Figure 9-47 Event log preferences

4. Complete or modify the form, as applicable, and click OK (Figure 9-48).

Figure 9-48 Configure event preferences


9.4 RSM server for Information Archive
The IBM Remote Support Manager (RSM) server is a dedicated server running the RSM
software. It is used to monitor the IBM Information Archive storage controller. The RSM server
provides the call home, event notification, and alert management features for the storage
controller. It also provides remote access to the appliance for service.

See the RSM Planning, Installation and User’s Guide at the following site:
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/56y7279.pdf

RSM call home feature: The call home feature is a communication link that is established
between a product and the IBM Support Center. The RSM server provides the call home
management for the storage controllers.

9.4.1 Configuring the RSM server
The RSM server needs to be configured to effectively activate call home and alerting. The
configuration provides RSM with required information about the storage controllers, contact
person, and which remote access will be used.

The RSM configuration is done in the RSM web GUI.
Log on to the Information Archive GUI from the management node.
Expand Information Archive Management in the navigation tree.
Click Service Tools.
Click Open Remote Support Manager as shown in Figure 4-24 on page 97. You get the
Main Menu for the RSM server
Click any link to receive a logon prompt.
Log in as user admin to get to the RSM Main Menu, shown in Figure 9-49.

Figure 9-49 RSM Main Menu


Select Update System Configuration in the RSM Main Menu to get the System
Configuration window shown in Figure 9-50.

Figure 9-50 RSM system configuration

Contact Information
First you have to update the contact information. Click Contact Information to get the
Contact Person Information configuration window as shown in Figure 9-51.

You need to define at least one contact person, but you can define up to 20 people.
One of these contacts must be defined as the Primary Contact for the RSM. Later during
configuration of the storage controllers, you will be able to associate one of the contacts
defined here with each Information Archive storage controller. Alerts sent to IBM include the
primary contact information for the RSM server and the information for the contact associated
with the Storage Controller problem.

Figure 9-51 RSM contact person information


Only one of these contact entries can be associated with a given storage controller. You can
use the alternate phone number and hours to call fields to specify another person for IBM
Service to call in case the first person is not available. The phone number fields can only
contain the number. But the hours to call fields are free form and you can put any text into
them.

Fill in each field and then select Update configuration to save the information. Be sure to
include a complete phone number including country codes for international dialing. The
“Alternate phone number” and “Hours to call alternate number” fields are optional. Time Zone
can be entered in any format.

Company Information
In the system configuration window, click Company information to get the Company
Information window.

Fill in the fields and then select Update configuration to save the information. All fields are
required except for “Address 2.” Required fields with missing or incorrect information are
indicated by an asterisk to the right side of the field.

Connection Information
In the System Configuration window (Figure 9-50 on page 382), click Connection
Information to get the Connection Information window shown in Figure 9-53.

Figure 9-52 RSM connection information

Fill in the fields and then select Update configuration to save the information. Required
fields with missing or incorrect information are indicated by an asterisk to the right side of the
field:
SMTP Server:
The default value is DIRECT, which will cause the RSM system to send emails directly to
the destination. You can also specify the TCP/IP address (xxx.xxx.xxx.xxx) of your SMTP
email server.


If using DIRECT, one reason that emails might not be delivered is because your
company's firewall might only forward emails sent from your email server. Specifying the
TCP/IP address of your SMTP email server can resolve this problem.
If using the TCP/IP address of your SMTP email server, one reason that email might not
be delivered is because the filtering on your email server might be blocking email sent by
the RSM system. Check with the administrator of your email server to determine if a
special rule for the RSM system is required.
Management Station:
Enter the optional the TCP/IP address (xxx.xxx.xxx.xxx) of your Management Console
(running IBM DS Storage Manager) that will send SNMP traps to the RSM system. If this
field is filled in, the management station will be periodically pinged to verify that the
network connection is OK
Location of RSM server:
Indicate in which rack, room, or building the server is located.
Country or Region:
If you have attached one of the global modems manufactured by Multitech that IBM has
tested for use with RSM, the modem will automatically be initialized for operation in the
specified country or region.
Remote access method:
Some method of remote access must be configured in order for IBM Service to be able to
respond to alerts from the RSM system. Either the modem connection, the SSH
connection, or both must be configured.
Modem phone number:
Enter phone number for the modem attached to the Remote Support Manager, including
area and country codes. This is the number the IBM service will use to dial the modem.
The following characters are allowed: “0123456789.” All other characters will be
automatically removed.
If no modem is to be attached to the RSM system, enter NOMODEM in this field and
complete the configuration for remote access by SSH client.
Phone Line Check number:
In the United States and some other regions, the RSM system can usually determine that
the phone line is connected without requiring this field. Leave this field blank unless the
RSM system always reports problems when performing phone line checks.
If the RSM system always reports that the phone line check is failing, enter the number
you intend to use to dial the modem from within your internal phone system. If the check
still fails, enter the dialing prefix (if any) required by your internal phone system to reach an
outside line and then the modem phone number used to dial the RSM modem from
outside your internal phone system.
There might be some combinations of location, internal telephone systems, and modems
that will not allow the phone line check to be performed. In this case, enter DISABLE in
this field to bypass the phone line check.
Except for the word “DISABLE,” only spaces and numbers are allowed.
Remote SSH access:
Enter the IP address and port number for the IBM Service to use to connect to the RSM
system using a SSH client. Your external firewall must be configured to map this external
address and port number to the RSM system. The default listening port number for SSH is
22, but you can assign another port number for the RSM system on this page.


If you do not want to use SSH for remote access, specify the internal IP address,
172.31.3.250, to get SSH enabled for the internal SSH communication. This internal
address cannot be used for remote connections.
If an SSH connection is not configured, then a modem must be configured.
You can optionally provide a user account and password to be used by IBM Service to
authenticate with your external firewall before attempting to connect with a SSH client.
All of this information is encoded in the alert, so IBM Service will have the information
necessary to connect to the RSM system.

Storage Subsystems
In the System Configuration window (Figure 9-50 on page 382), click Storage Subsystem to
get the Storage Subsystem window shown in Figure 9-54. Fill out all requested information.

Figure 9-53 RSM Storage Subsystem

Attention: Do not enter a DS Storage Manager password in the password fields.

Name:
The name is predefined within the IBM Information Archive and must match exactly the
hostname used in IBM DS Storage Manager for this subsystem (storage controller). When
using Enhanced Remote Mirroring, it might be necessary to match the Storage Controller
naming.
Location:
Indicate where the Storage Controller subsystem is located: rack, room, or building
number.


IP Address:
The IP Addresses are predefined in Information Archive. The IBM Serial Numbers are on
the label in front of the storage controller.
IBM Product ID:
The Product ID is predefined in Information Archive. Verify that the Product ID is entered
as 2231-D1A.
Contact person:
Choose from the list of previously defined contact people. This person will receive
notifications about problems for this storage controller.
Part of an IBM Solution:
The Storage Controller (or subsystem) is part of an IBM Solution. The RSM must reflect
the IBM Information Archive serial number. This is necessary to route problem reports to
the correct IBM support team. The Part of an IBM Solution field is predefined on IBM
Information Archive. To verify the Information Archive, log on with the lservice user
account.
Click System Configuration and Storage Subsystems and select the affected storage
controller. A window similar to the one shown in Figure 9-54 is displayed.

Figure 9-54 RSM Part of a Solution

Click Update to see the IBM Information Archive Solution Information. The window is


Figure 9-55 Solution Information

The Type, Model and Serial number field must match the IBM Information Archive.

Configuration Test
On the System Configuration page, run the Configuration Test as shown in Figure 9-56.

When each configuration section shows a status of OK, an option to run a Configuration Test
will be available at the bottom of the window. The RSM Configuration Test will verify
connectivity to all configured devices. Click Refresh Status until the test completes and the
results are shown. Any problems are indicated by a status of Problem and the specific device
will be flagged with a double asterisk. Click the areas indicating a problem to determine which
device and/or IP address cannot be reached. Additional information about test results are
written to the Activity Log and displayed on the System Configuration page. See the Help for
the Configuration page for suggestions on resolving the problem. Re-run the configuration
test until all problems are resolved.

Figure 9-56 Run configuration Test


During the configuration test, (see Figure 9-57) the profile for each subsystem (storage
controller) will be downloaded. This will verify connectivity to the storage controller, verify that
this version of RSM software is compatible with the firmware on the Storage Controller and if
the Storage Controller name matches the name used in DS Storage Manager. The
configuration test will also determine if there are any drive expansion units attached to the
controller.

If any drive expansion units are detected, the configuration status for the Storage Controller
will change to Configuration Incomplete and additional configuration fields will now be
available for setting the IBM machine type and serial numbers of each detected drive
expansion unit. When storage expansion units are used, you have to update the fields with
the Model, Type, and Serial number. It has to look like 2231-D1B xxxxxxx.

Figure 9-57 Configuration Test running

After the Configuration Test completes without reporting a problem and Remote Access has
been verified, contact IBM Information Archive support to have a test alert sent and to
activate the system.

System Activation
Before the Remote Support Manager can send alerts to IBM, it must be activated by
contacting IBM Service. This is also the last step in verifying the correct operations of RSM.
1. Contact IBM Support to activate the system. You have to call for service using the Machine
Type and Serial Number of Information Archive.
2. On the RSM user interface, click Remote Access and enable remote access. A window is
displayed as shown in Figure 9-58.
3. Provide IBM Support with the remote access information (either the phone number of the
modem or the SSH connection information).
4. IBM Support will verify that they can connect to the system.
5. After generating and verifying receipt of a Test Alert, IBM Support will activate the system
for reporting.


Figure 9-58 RSM Activation

After RSM is activated, the Information Archive storage controllers are ready for monitoring
and call home.

9.4.2 Working with the Information Archive RSM server
The RSM call home feature is a communication link that is established between a product and
a service provider. IBM Information Archive provides this feature so that reports can be
automatically sent to the IBM Support Center when critical hardware problems from the
storage controllers are detected. When the IBM Support Center receives a call home report,
an IBM service representative contacts your company to work on resolving the problem.
IBM Remote Support Manager (RSM) monitors the appliance storage controllers (2231
Model D1A and Model D1B components).

Call home: After the RSM is activated, it is ready to perform the call home function.

Working with IBM Service
This section provides details about using RSM to work with IBM Service to resolve issues.

Enabling remote access
On the Remote Access management page, you have the option of allowing remote access to
be automatically enabled when an alert is sent to IBM. This allows IBM to connect to the RSM
system without needing to first speak with the contact person for the system. If you choose to
disable this function, IBM Service will contact you to have remote access enabled manually
when an alert is received. Follow these steps:
1. Log on to the Information Archive GUI from the Management Console.
4. Click Open Remote Support Manager as shown in Figure 4-24 on page 97. You will get
the Main Menu for the RSM server.
6. Log in as user admin.


7. Click the Remote Access button. The panel is displayed as shown in Figure 9-59.
8. Click Enable Remote Access to enable the access for IBM Support.

Figure 9-59 Enable Remote Access

When Remote Access is enabled, the remote user login (rservice) is enabled and calls to the
modem will be answered.

Acknowledging alerts
The acknowledge state of an alert is an indication that IBM Service has seen or is aware of
the alert. When IBM Service dials into the RSM system, they will view the existing alerts and
acknowledge them. In some situations, IBM Service might not require remote access to the
RSM or subsystem in order to determine the cause of a problem, and they might call you to
discuss the problem resolution. You can also acknowledge (or close) alerts.

Closing alerts
The RSM software sends an alert to IBM Service for the first event reported for a subsystem
and for each unique event that indicates a hardware failure.

Additional alerts that occur (usually related to the initial event) are held by the RSM system
and are available for examination by IBM Remote Support when they connect to the RSM
system in response to the initial alert. When all active alerts for a subsystem are closed, the
next event for that subsystem will again be sent to IBM Service.

Problem reports: Closing an alert in the RSM software does not close the problem report
with IBM Service.

Remote Access Timeout feature
To ensure that you do not have to remember to disable remote access to the RSM system in
order to make it secure, the RSM software will automatically disable Remote Access based
on a time-out. You can configure this time-out for between 12 and 96 hours. Some intermittent
problems might require occasional access by IBM Service over a period of days and it might
be necessary for you to extend the time-out. To extend the Remote Access Timeout, click the
Update Remote Access Timeout button on the Remote Access management page as
shown in Figure 9-59 on page 390.


Event filtering and handling
The RSM software does not directly monitor storage for problems. Your existing IBM DS
Storage Manager software installed on the management node server already polls each
Storage Controller looking for problems. DS Storage Manager is configured to send critical
events to the RSM systems as SNMP traps.

Security
Adding a modem or enabling SSH connections to one of your systems creates a potential
entry point for unauthorized access to your network. RSM software modifies many
characteristics and behaviors of the system it is installed on to protect this entry point and to
maximize the amount of control you have in managing remote access. To ensure the integrity
of these controls, consider the server that the RSM software is installed on to be a single
purpose appliance.

RSM controls initial access to the system by remote users and then manages an internal
firewall to limit the scope of access a remote user has to your network.

Access to the RSM system
Remote access to your system has the following four layers of control:
The modem is configured to only answer when Remote Access is enabled by the RSM
software. Likewise, the SSH port for remote access is only allowed to respond to
connection attempts when Remote Access is enabled. You can manually enable and
disable remote access, or you can choose to have remote access automatically enabled
when a storage subsystem reports a problem. When remote access is enabled a timer is
started which will automatically disable remote access when it expires. You do not have to
remember to make the system secure after service has been completed. The person
identified as the primary contact for the RSM system is notified by email whenever a
change in the remote access settings occurs and all state changes are also written to the
Security Log.
The userid reserved for remote access (rservice) is only valid when Remote Access is
enabled. Attempts to log in using the root, admin or lservice userids using the modem or
remote SSH connections are rejected. For this reason, do not create additional users on
this system.
The initial login password is changed daily at midnight UTC. IBM Service has an internal
tool that provides the current password for RSM systems.
After validation of the initial login password, remote users are presented with a challenge
string, which also requires access to an internal IBM tool in order to obtain the correct
response. The response also includes an IBM employee user name that is recorded in the
RSM Security Log.

Scope of access to your network
The following sections provide detailed information about the various user access
permissions and privileges available in your network.
1. User permissions and privileges:
After a remote user has logged into the RSM system, that user will have all of the
privileges of a normal user that is logged into the system locally.
– root has complete control of the system and must be used only for maintenance.
– admin performs configuration and management of the RSM software. The password
for this user is set by the root user of the system.
– lservice is primarily intended for use by on-site IBM Service. This user can
acknowledge and close alerts and view configuration settings. The lservice user can


log into the system locally and is also recognized by the RSM browser interface. The
password for this user is set by the root user of the system.
– rservice is used by IBM Service and is only valid on the remote modem or SSH
connection.
The Switch User (su) command is disabled to prevent a normal user from attempting to
become “root” and have unrestricted access to the system. The RSM software makes
other changes in program and directory permissions to limit what programs and files these
users can access.
2. IP connections:
The remote connection made by IBM into the RSM system is a console interface and
programs that can initiate an IP connection on this interface are removed from the system
during installation of the RSM software.
The only TCP/IP related daemons (or services) running on the RSM system are
snmptrapd, sshd, and httpd, which listen for SNMP traps, secure shell session requests
and HTTP(S) requests respectively.
3. Firewall states:
The RSM software manages an internal firewall that limits the TCP/IP destinations that
can be accessed by local and remote users of the system. The “rules” for inbound and
outbound IP traffic that control the internal firewall are managed dynamically by the RSM
software. There are three general states that the firewall can be in:
– Disabled:
All IP traffic is permitted both into and out of the system.
– Enabled: Closed:
This is the normal state when there are no active alerts present and the system is
waiting for notification from IBM DS Storage Manager of a problem:
•The firewall will accept incoming SNMP traps, ping, traceroute and HTTPS
requests.
• Outbound traffic for DNS, ping, traceroute, IBM's WWW and FTP sites and port 25
of your configured SMTP (email) server.
• There is no access to any of your configured SAN devices or other addresses
except as previously noted.
• Forwarding of TCP/IP traffic is also disabled, which prevents the system from being
used as a router.
– Enabled: Open:
In the Enabled: Open state, outbound access to one or more configured storage
systems or other configured SAN devices is also permitted. Access is allowed only to
those devices that have active alerts or those that you have placed in Service Access
mode. If you have defined any custom firewall rules, those rules will also be in effect.
– Enabled: Custom:
The Enabled: Custom state will be seen in place of Enabled: Closed when one or more
custom firewall rules has been configured in /etc/rsm/rsm-firewall.conf. Custom rules
might allow SSH access on your local network for administration. When RSM is
included as part of an IBM Solution, rules can be created to allow communication with
other elements in the solution.

Ports used by RSM
In order to detect events and report them to IBM, the following connections are always
permitted:


Inbound SNMP traps on port 163
Outbound connections to Domain Name Servers (DNS) on port 53.
Outbound connections to the configured email (SMTP) server

In addition, the following connections are allowed for management and maintenance of the
RSM system.
Outbound connections to IBM's websites and FTP servers
Ping requests and responses
Traceroute requests and responses
Inbound HTTPS requests

While a subsystem has an active alert, outbound connections to that subsystem are allowed.
Outbound connections are also allowed for all devices that have been placed in “Service
Access” mode.

The internal firewall permits outbound connections on any TCP port, but limits those
connections to only devices listed in the RSM configuration and under specific conditions,
such as when a device is reporting a problem.

The internal firewall allows no inbound connections except for:
nn SSH (default is port 22):
This port is used to provide remote access to the RSM system for IBM Support. It is
enabled when the RSM Remote Access state is enabled and the SSH configuration has
been provided. A second SSH port that can be used for remote access can be configured
to use a non-standard port number.
443 HTTPS:
Management of the RSM from within the customer network.

9.5 Reporting
The IBM Information Archive provides several ways to view current and historical status
information about the appliance. You can generate historical reports in several formats and
view status information in the Information Archive GUI. You can also use external tools to
obtain additional information. There are some differences in the reporting options available for
each type of document collection.

9.5.1 Tivoli Common Reporting
This reporting tool is available in the Information Archive GUI. The reports allow you to
determine usage trends and help predict future storage needs. You can generate the
following reports.

Capacity utilization analysis for File Archive Collections
This report shows detailed utilization information. It is only available for File Archive
Collections.

To create the report, log on to the Information Archive GUI with the reportViewer role and
1. Expand Tivoli Common Reporting in the navigation tree.
2. Click Work with Reports.


3. In the Navigation tab, expand Tivoli Products and click IBM Information Archive
Reports. The available reports are listed in the Reports table as shown in Figure 9-60.

Figure 9-60 TCR window

4. Right-click the Capacity utilization analysis for File Archive Collections, select
View As, and select the report format. If you select Microsoft Excel, the report data is
exported but not the charts. When you select HTML format, you will get a window as
shown in Figure 9-61 and Figure 9-62.

Important: The Capacity utilization for File Archive Collections report is only available
for File Archive Collections.

5. In the On-Demand Report Parameters window, select a document collection for which to
generate the report and specify a time interval as illustrated in Figure 9-61.

Figure 9-61 Reporting Parameter

The generated report is shown in Figure 9-62. The generated report appears in a separate
web browser window. To save a copy of the report to your local computer, on the web
browser, click File  Save.


Figure 9-62 Capacity utilisation chart

Historical capacity utilization
This report show historical capacity usage by collection. It is available for File Archive
Collections and System Storage Archive Manager collections. These reports are based on
information that is updated once every hour. Historical information is stored for 30 days.

To create the report, log on to the Information Archive GUI with the reportViewer role and
1. Expand Tivoli Common Reporting in the navigation tree.
2. Click Work with Reports.
3. In the Navigation tab, expand Tivoli Products and click IBM Information Archive
Reports. The available reports are listed in the Reports table as shown in Figure 9-60 on
page 394.
4. Right-click the capacity utilization report, select View As, and select the report format.
If you select Microsoft Excel, the report data is exported but not the charts.
5. In the On-Demand Report Parameters window, select a document collection for which to
generate the report and specify a time interval as shown in Figure 9-63. When you select
HTML format, you will get a window as shown in Figure 9-64.

The generated report appears in a separate web browser window. To save a copy of the
report to your local computer, on the web browser click File  Save.


Figure 9-63 Reporting parameter 2

Figure 9-64 Historical capacity utilization chart

9.5.2 Document status information
For File Archive Collections, you can view detailed document status information in the
Information Archive GUI Collection Overview page. You can use this information to identify
documents that are not yet protected by archival retention policy, documents for which a
retention hold has been placed, and documents that are eligible for deletion.

The following document states are shown:
Failed ingestion
Uncommitted
Expired
Retention hold


The Collection Overview page as shown in Figure 9-64 also provides a total count of stored
documents for both File Archive Collections and System Storage Archive Manager
collections. For File Archive Collections, the count is updated every 12 hours. For System
Storage Archive Manager collections, the count is updated each time the page is refreshed.

2. Click Collection. A window is opened as shown in Figure 9-65.

Figure 9-65 collection overview

3. Click one of the four Document status buttons to view detailed document status
information. An illustration is shown in Figure 9-66.
The count shown for File Archive Collections includes all documents, including those
documents that have no content.

Figure 9-66 Document Management


9.5.3 IBM Tivoli Storage Manager reporting
If you install the Tivoli Storage Manager reporting package on a server outside of the
Information Archive appliance, you can generate additional reports for System Storage
Archive Manager collections. For more information, see the Tivoli Storage Manager
documentation.

9.5.4 IBM Tivoli Storage Productivity Center
The Tivoli Storage Productivity Center or IBM System Storage Productivity Center (SSPC)
cannot discover Information Archive or launch the Information Archive GUI in context.
However, you can configure the Information Archive GUI as an “external tool” in the Tivoli
Storage Productivity Center. External tool definitions are available to any client that connects
to the Tivoli Storage Productivity Center server. The external tool definitions allows you to use
the Tivoli Storage Productivity Center as a central access point for managing multiple
Information Archive appliances. For more information, see the Tivoli Storage Productivity
Center documentation.

9.6 Logging and tracing
You can enable logging and tracing to help the IBM Support Center diagnose any
performance or hardware problems affecting your IBM Information Archive appliance.

For each cluster node in the appliance, you can create a compressed file that contains
logging and tracing results. The compressed file can be downloaded through the Information
Archive GUI or from the Management Console server command line.

Important: Enabling logging or tracing can impact the performance of the appliance.
Do not enable these tools unless you are directed to do so by IBM support.


The Logging and Tracing section can be found in the Information Archive Management
navigation tree in the Service Tools menu as shown in Figure 9-67.

Figure 9-67 Logging and tracing window

9.6.1 Logging
System logs record the appliance errors, warnings, and status changes and are used by IBM
service representatives to diagnose problems.

Levels of detail
There are multiple levels of detail that the error logs can be configured to capture, as shown in
Figure 9-68:
Only error messages: Tracks only errors that are generated by the hardware and software
components in the appliance.
Error and warning messages: Records any warnings signaled because of a recoverable
error. The default value is “Error and warning messages.”
Error, warning, and informational messages: Records any informational messages for
normal conditions or events supplied to clarify operations such as state transitions, and
operational changes.


Figure 9-68 Logging and tracing settings

Modifying the logging level
You can change the level of detail that the IBM Information Archive error logs record.
However, do not change the logging level unless directed to do so by the IBM Support Center.
If you are directed to do so, log on to the Information Archive GUI and complete the following
steps:
3. In the Logging and Tracing section, click a collection name.
4. Select the level of logging and click OK. (see Figure 9-68).
5. After you complete these steps, click OK or Apply in the properties notebook to commit
any changes.

9.6.2 Tracing
Traces record how Information Archive components interact with each other. This information
is useful when diagnosing system problems that might not be recorded in the error log. By
default, tracing is set to the intermediate level.

Important: Do not change the tracing level unless you are directed to do so by an IBM
service representative.

Levels of detail for tracing
There are multiple levels of detail (see Figure 9-68) that you can set for tracing the
Information Archive document ingestion and collection management software:
minimum: Captures the basic information that is typically required to diagnose simple
problems.
intermediate: Captures additional information required to diagnose more complex
problems.
maximum: Captures the most detailed set of information. The performance impact of this
setting is significant; enough that this setting is not appropriate in production
environments. This setting is typically used by IBM service representatives to isolate a
specific problem. This level is enabled only for the duration required to capture the needed
data. Use the maximum level for dense tracing of code already suspected to have
problems.


The tracing level that you set from the Information Archive GUI only configures the tracing for
the Information Archive document ingestion and collection management software.

Modifying the tracing level
You can enable tracing to record how the appliance components interact with each other. Use
tracing to provide information that is useful in diagnosing system problems that might not be
recorded by the error log.

Important: Do not enable tracing unless you are directed to do so by the IBM Support
Center because of its impact on the appliance system performance.

If you are directed to enable tracing, you can use these procedures:
1. Modify the tracing level for the Information Archive management software, by completing
a. Log on to the Information Archive GUI.
b. Expand Information Archive Management in the navigation tree.
c. Click Service Tools.
d. In the Logging and Tracing section, click the collection name.
e. Select Enable tracing and the level of tracing and click OK (see Figure 9-68 on
page 400).
2. Modify the tracing level of the remaining appliance software components by completing
a. Log on to the Management Console server with the iaadmin user account.
In the next step, if you specify a component of all or rsm, any user who is connected to
the IBM Remote Support Manager for Storage server remotely is disconnected and
remote access to the appliance is disabled.
b. At the Management Console server command prompt, enter the following command:
ia_service.py –r trace -c component -l trace_level
Substitute component with the component for which you are configuring the trace level.
The values can be:
• all
• dir.agent
• dir.server
• gpfs
• hsm
• mcp
• nfs
• rsm
• sles
• tsm.client
Substitute trace_level with the trace level to set for the subsystem. The values can be:
• min
• mid
• max
• disable
• defaul
• current.


In Example 9-4 we illustrate this process.
After changing the tracing level, the appliance might be unresponsive for a few minutes
while it completes the requested changes.

Example 9-4 Tracing Level example
login as: iaadmin
Using keyboard-interactive authentication.
Password:
Last login: Thu Mar 11 11:41:35 2010
iaadmin@IA-Secondary:~> ia_service.py -r trace -c hsm -l mid
Routing trace config command to node ianode3. This may take several
minutes.
Configuring tracing for 'hsm' on 'ianode1'
Configuring 'hsm' with command: /opt/tivoli/tiam/bin/setHSMTrace.sh mid
Copying dsm.opt.mid to dsm.opt...
Enabling logrotate for HSM trace_tsm.out...
Stopping the HSM Daemons.
killing the dsmwatchd process
Restarting the HSM Daemons.
Trace level set to mid.
Finished setting trace level for 'hsm' to 'mid' on 'ianode1'.
Updating trace_current.properties file.


10

Chapter 10. Tape attachment with
IBM Information Archive (Information Archive) allows you to connect external tape devices to
expand the storage capacity of the appliance or to provide a backup for System Storage
Archive Manager Collections or some of the components configuration data. If you attach
tape devices to the appliance, documents can be automatically migrated or copied to tape
storage depending on the filesystem utilization thresholds that you configure.

In this chapter we explain how to attach, configure, and use tape and library devices to
enhance the standard capabilities of the IBM Information Archive appliance. Furthermore, we
cover additional enhanced configurations topics for tape integration with Information Archive:
Tape attachment strategy
Supported tape devices
Data migration and backup considerations
Tape device configuration through GUI and command line interface
Enabling tape drive-based hardware encryption
Configuring udev for persistent naming / binding support for tape devices


10.1 Information Archive tape attachment overview
There are three possibilities to attach tape devices to the appliance: direct attachment,
internal SAN switch attachment, and external SAN switch attachment. The option that you
choose depends on the number of tape devices you want to attach, how the devices are
shared among the collections, and your network configuration:
Direct attachment:
In this configuration, a tape device is attached directly to the tape ports of the appliance
cluster nodes. Each cluster node has two Fibre Channel ports for tape attachment, so the
maximum number of tape devices in this configuration is twice the number of cluster
nodes in your appliance. If you use this method, only the cluster node that is connected
directly to the tape device can use that device. Therefore, if a cluster node fails and the
collection is moved to another cluster node, the tape device will not be accessible by the
collection (a compromise might be to connect a tape drive with two FC ports such as
TS1130 to two nodes by the tape’s primary and alternate path).
With direct attachment, the number of available HBA ports dictates the number of tape
drives that you can attach to the cluster servers. However, the advantage of this method is
that it can be used without the need for the Information Archive internal SAN switches.

Direct attachment: Using the direct attachment method is technically limited if you
have more than two cluster servers, more than two collections, or Enhanced Remote
Mirroring installed. You can still connect tape drives directly to some of the cluster
nodes, but if any of the criteria above are fulfilled, the internal Fibre Channel switches
are mandatory.

Internal SAN switch attachment:
In this configuration, the node servers and the tape devices are connected to the internal
appliance SAN switches. To use this method, you must order and install the SAN switch
kit, which contains two SAN switches (feature code 1906). Furthermore, you need to
activate additional eight Fibre Channel ports on both switches, as described in the IBM
Information Archive Service Guide, SC27-2327. The SAN switches have two dedicated
ports configured for tape attachment. Port 9 and port 11 on each switch are reserved for
tape attachment. So the maximum number of tape devices that you can connect to the
appliance is four. The internal switch, unlike direct attachment, allows all of the cluster
nodes to access all tape devices. Therefore, if a cluster node fails and a collection is
moved to another cluster node, the collection can still access the tape devices.
If you have installed a secondary Information Archive appliance for Enhanced Remote
Mirroring, the internal SAN switches are mandatory because Enhanced Remote Mirroring
requires dedicated Inter-Switch-Links (ISL) for remote mirroring. If Enhanced Remote
Mirroring is configured and the ISLs are properly set up, each cluster node on the primary
and secondary site server can access the tape drives and library medium changer devices
connected to the switches on the primary and secondary site SAN switches. This means
that a maximum of eight tape drives can be attached, configured, and accessed from all
cluster nodes at the primary and secondary site. In a disaster recovery configuration with
two Information Archive appliances, the attachment of eight tape devices is possible.


Figure 10-1 shows the zoning configuration for tape attachment to the internal SAN
switches.

Figure 10-1 Zoning configuration for tape attachment

To achieve maximum protection level for the Information Archive appliance, for example, it
is possible to configure the primary site to use tape devices attached to the local site for
tape migration but use a tape library and tape devices connected to the remote switch for
database backups and copy pools.

Tip: If you implement a tape attachment strategy where the primary Information Archive
appliance is also using the devices attached to the remote Information Archive
appliance switches, be aware that the actual I/O for backup or migration will be routed
by the Inter Switch Links, which are primarily used for Enhanced Remote Mirroring to
synchronize the primary and secondary disk subsystems.

External SAN switch attachment:
In this configuration, the cluster nodes are connected to a customer-supplied external
SAN switch. You can connect as many tape devices as the external SAN switch can
support. All cluster nodes that are attached to the external switch can access all of the
tape devices. The customer is responsible for determining the interoperability between the
appliance cluster nodes Host Bus Adapters (HBAs) and the external SAN switch as well
as for the implementation of redundant fabric configuration.
The cluster nodes HBAs are QLogic® 4 Gb FC Dual-Port PCIe HBA for IBM System x. To
check if your SAN switch is compatible, see the System Storage Interoperation Center at:
http://www.ibm.com/systems/support/storage/config/ssic/

Important: The tape device connection methods cannot be combined in certain ways:
Do not connect the tape devices directly to the cluster nodes while also through a
switch.
Do not connect the tape devices through the internal SAN switch while also through
an external SAN switch.
Do not connect the internal SAN switch to an external switch of any kind. This can
compromise the zoning of the internal SAN switch.

Chapter 10. Tape attachment with IBM Information Archive 405

10.2 Tape device support for Information Archive
Information Archive supports the same Fibre Channel tape devices compatible with the Linux
IBM Tivoli Storage Manager server 6.1 except for StorageTek ACSLS and the IBM 3494
Library because those libraries require additional software and configuration.

For a list of supported device types and information about IBM Tivoli Storage Manager server
tape device management, see the following website:
http://www.ibm.com/software/sysmgmt/products/support/IBM_TSM_Supported_Devices_for
_Linux.html

Depending on the regulatory requirement that customers are trying to meet, there might or
might not be specific types of media required. Most regulations allow data to be on any device
type as long as the content management application establishes a retention policy.

Tip: You can use the IBM System Storage TS1130 Enterprise Tape Drive in combination
with the IBM System Storage 3592 WORM media, or the latest generation of IBM Ultrium
LTO drives in combination with the 3589 WORM media, to extend the IBM Information
Archive characteristics for non-erasable and non-rewritable data to the tape storage pool.

The following IBM tape drives and tape libraries can be attached to Information Archive:
IBM tape drives:
– TS1120 (supports Drive Encryption and dual drive path)
– TS1130 (supports Drive Encryption and dual drive path)
– LTO Generation 3 tape drive
– LTO Generation 4 tape drive (supports Drive Encryption)
IBM tape libraries:
TS3100 (for LTO 3 and LTO 4 tape drives)
TS3400 (for TS1120 and TS1130 tape drives)
TS3500 (for TS1120, TS1130, LTO 3 and LTO 4 tape drives)

To read more about models and features of IBM tape drives and libraries, go to the website:
http://www.ibm.com/systems/storage/tape/index.html

10.3 Using tape for Information Archive data migration
If you attach a tape device to the appliance, documents can be automatically migrated to tape
storage depending on the filesystem utilization thresholds that you configure. Information
Archive uses optional tape media for the following purposes:
Migrating archived data:
Migrating data off of the primary disk storage pool over time or after a certain percentage
of the pool capacity has been reached onto a tape storage pool can tremendously extend,
at a reasonable cost, the storage capacity of Information Archive. The nature of archived
data is that it is accessed more frequently shortly after its creation, but less and less
frequently as time passes, which increases the need to move data over time from disks to
less expensive media such as tape.


File access times: Retrieving files from a tape device can take minutes depending on
the performance of the tape device, and it is significantly slower than retrieving files
from the appliance disk subsystem. If you must access your files frequently, do not
migrate them to tape storage.

For migration, both File Archive Collections and System Storage Archive Manager
Collections can use tape storage. In both cases, the tape device is the last level in the
storage migration hierarchy:
– For File Archive Collections, documents are migrated from primary disk storage to
secondary disk storage within the appliance, and then migrated to tape.
– For System Storage Archive Manager collections, documents are migrated directly
from initial disk storage to tape.

10.4 Using tape for Information Archive data backup
The configuration for backing up archived data differ depending on the types of document
collections you create:
System Storage Archive Manager collections:
Data stored in System Storage Archive Manager collections can be backed up directly to
an external tape device. An additional Tivoli Storage Manager server is not required for
these collections. Just create a copy storage pool, and use the internal Tivoli Storage
Manager server to manage the backups. In addition to backing up the storage pools, the
Tivoli Storage Manager server database must also be backed up. Scheduling and
management of these backups is done from the IBM Information Archive appliance.
File Archive Collections:
Data stored in File Archive Collections must be backed up to an external IBM Tivoli
Storage Manager server. This server is not part of Information Archive.

10.4.1 System Storage Archive Manager Collections backup
You can use tape devices attached to the Information Archive appliance for System Storage
Archive Manager Collections (archived data and corresponding SSAM database)
Backing up archived data for System Storage Archive Manager Collections:
Keeping a backup of the System Storage Archive Manager archived data in a remote tape
storage pool protects it from disasters that might happen to the disk storage pool at the
site where Information Archive is located. With data being an essential asset for many
enterprises, having the capability to recover from a disaster by restoring from the tape
backup pool is invaluable.

Important: Do not use the Enhanced Remote Mirroring feature as a substitute for
collection backups. Enhanced Remote Mirroring will not protect against data corruption.


Backing up the System Storage Archive Manager database:
Like the actual data, the System Storage Archive Manager database needs protection
from the very same scenarios just described. Without the System Storage Archive
Manager database, access to the archived data is impossible. Therefore, backing up the
database to tape (preferably to a remote site) is as vital as the backup of the original data.
Backing up the System Storage Archive Manager database does not include the actual
System Storage Archive Manager data. A database backup needs to be done for each
collection by its own. Even if you have multiple System Storage Archive Manager
Collections configured, each collection needs to be backed up individually. This also
applies to File Archive Collections.
In Information Archive environments, even with Enhanced Remote Mirroring enabled, it is
also critical to back up the System Storage Archive Manager database to tape in order to
protect against possible database corruption.
The required steps for System Storage Archive Manager database backup are described
in chapter “Backing up the System Storage Archive Manager database” on page 443.

10.4.2 File Archive Collections backup
File Archive Collections data reside on both primary disk storage and secondary disk storage.
As we have seen in 6.2.4, “Initial disk storage and secondary disk storage category” on
page 178, data is progressively migrated form primary to secondary storage under control of
an HSM client. Because data in the primary storage do not reside in a Tivoli storage pool
(defined within the appliance) and because primary and secondary storage data must be kept
in sync for a usable restore, the backup of File Archive Collections must be done through an
external IBM Tivoli Storage Manager server.

Important: Backup of File Archive Collections (data and metadata) must be done through
an external IBM Tivoli Storage Manager server,

Backing up File Archive Collections data:
Data stored in File Archive Collections must be backed up to an external IBM Tivoli
Storage Manager server. This server is not part of Information Archive.
Backing up the IBM Tivoli Storage Manager database for File Archive Collections:
Data stored in File Archive Collections can be backed up to an external IBM Tivoli Storage
Manager server. This server is not part of Information Archive and needs to be provided by
the customer. From that server, you can optionally migrate the data to tape. To use this
backup feature, you must install Tivoli Storage Manager, or use an existing Tivoli Storage
Manager server.
Like the System Storage Archive Manager database the IBM Tivoli Storage Manager
database for File Archive Collections needs to be backed up on a frequent basis to be able
to restore the complete database and File Archive Collection content is a disaster
scenario.

Collections: Each collection has its own disk storage pools and its own database.
Migration settings, database backup, and copy pools must be defined individually for
each collection.


10.5 Planning for tape attachment
To efficiently plan for tape attachment with Information Archive, first determine components
needed:
Tape device and media technology, and product names
Available functionality
Number of tape libraries and tape drives required
Available storage capacity

The tape devices can be used to strengthen data integrity and to prepare for disaster
recovery. Tape is an ideal medium for these tasks because it can easily be moved to an
off-site location. Another reason is the cost/MB ratio of tape media, which is still less
expensive than disk media even with the SATA disk devices.

10.5.1 IBM System Storage Archive Manager and Information Archive Tivoli
Storage Manager tape pools
When using System Storage Archive Manager or File Archive Collections, the technical
reasons to establish a storage hierarchy, which includes disk and tape, are based on the
various functions the product offers:
Backup of storage pools (copy pools)
Data migration
Information Archive Tivoli Storage Manager / System Storage Archive Manager Database
Backup (DBB)

Supported tape devices
IBM Information Archive supports manual and automated tape devices:
Manual tape devices are devices operated by the administrator because they do not have
any automated functionality or the hardware necessary for automation. For example, any
stand-alone tape drive is considered to be a manual tape device. The tapes are mounted
and dismounted by the administrator, and the storage of tape volumes is under the control
of the administrator.
Automated tape devices have the hardware (such as cartridge accessor, storage slots, and
input/output slots) and functionality to operate without administrator intervention. Mounting
and dismounting tape volumes or storage of volumes within the library is fully automated.
Whenever possible, choose automated tape devices over manual tape devices.

Tape devices are defined to System Storage Archive Manager and Information Archive Tivoli
Storage Manager through library and drive definitions. Each physical library (of whatever tape
technology) is associated with or mapped to a tape device class definition. The device class
definition informs the servers about the type of drive being used, for example, the format and
capacity. Tape drives within a large tape library can be logically grouped to meet performance
requirements for various groups of data, as illustrated in Figure 10-2.

Tape devices: See the section “Planning for tape attachment” on page 409 for more
information about supported tape devices.


Tape storage pools
Tape storage pools can typically be used within System Storage Archive Manager and
Information Archive Tivoli Storage Manager for both primary and copy storage pools. Primary
tape pools are defined if migration is configured. To create copies of a primary object, Tivoli
Storage Manager needs to back up the primary object. This process can be automated to
create copies on a daily basis.

Migration
The physical location of an object within the storage pool hierarchy has no effect on its
retention policies. Migrating objects to another storage media such as tape can free up
storage space on higher-performance devices such as disks.

10.5.2 Database backups
The backups of the System Storage Archive Manager and IBM Tivoli Storage Manager
database do not belong to a storage pool and they cannot be copied. The System Storage
Archive Manager and IBM Tivoli Storage Manager for file archive includes daily database
backups to disk as a preconfigured feature. The daily database backup is configured in the
script DAILY_MAINT. When attaching tape devices, you can (and must) also back up the
database to tape. This provides additional security, and can be scheduled to run automatically
every day as well. See Figure 10-2 for an illustration of the backup process.

Tape Library
read on one drive,
write on other

Tape Drive #2

Database Backup Tape Drive #1

SSAM
Database

DB
Volume
DB
Volume DBB Backup DBB DBB DBB

Storage
Recovery Log Pool SSAM Copy Tape Pool

COPY COPY COPY
LOG LOG ITSM
Volume Volume Volume
Volume Volume CONFIG

Primary Disk Pool SSAM Primary Tape Pool
Migration STG STG STG
STG STG STG Volume Volume Volume
Volume Volume Volume

Figure 10-2 Tape attachment for System Storage Archive Manager with migration and copy policies


10.6 Configuring tape libraries and drives for use with
Information Archive
This section describes attaching the IBM Enterprise Library TS3500 with the LTO Ultrium 4
WORM-Capable Tape Drives 3588 Model F4A to Information Archive. We selected these
devices because they support WORM functionality and hardware encryption.

The technical aspects of this illustration remain the same for most of the other possible
devices, including the TS1130 enterprise tape drive with dual port interface. Instead of the
IBM Automated Tape Libraries, you can use simpler options, such as LTO libraries or
stand-alone tape drives.

Use the following procedure to configure tape attachment for migration of archived
documents from disk storage to tape. Tape migration is configured per collection. Before
starting this procedure, ensure that you have completed the following prerequisites:
You have created an Information Archive document collection. Our examples refer to a
System Storage Archive Manager collection SSAM1 and a File Archive Collection NFS1.
The tape device has been started and is connected to the appliance.

10.6.1 Attaching IBM TS3500 library to the internal SAN switches
The implementation in our example assumes that the customer plans to attach the tape
devices to the SAN switches included in the Information Archive appliance. In order to
achieve path redundancy, each drive is connected to another SAN switch. The drives can be
attached to port 9 and port 11 on any of the two internal switches. However, it is best to
connect one drive to the lower internal switch and one to the upper internal switch. In our
sample implementation (Figure 10-3), both tape drives are configured as control path drives
(CPDs) and will report a medium changer device and the tape drive device to the cluster
nodes.


cluster nod e1 cluste r no de2 cluster node 3

A B A B A B

IA internal switch (optional)
FC switch1 FC switch2

A Node server HBA slot2, port2

B Node server HBA slot3, port2
LTO Drive1 LTO Drive2

• LTO Drive1 connected to swi tch1, port 9
• LTO Drive2 connected to swi tch2, port 11
Figure 10-3 Cluster nodes and TS3500 library with LTO4 drives connected to the internal SAN switch

10.6.2 Device driver and device attachment verification
The IBM device driver for Linux, lin_tape, is preinstalled in the Information Archive appliance.
The following steps demonstrate how to verify the correct communication with the TS3500
library controller and the LTO4 Tape Drives, after the physical Fibre Channel connectivity
between the HBA and the tape devices has been established. Our illustration uses a
configuration with two LTO4 tape drives in a 3584 logical library partition. Both tape drives are
defined as control path drives (CPD).

Important: You must be locally at the Information Archive rack and switch to the cluster
nodes at the KVM switch to run the following commands. Log on with user root (note that
log on as root is no longer possible if you have enabled Enhanced Tamper Protection. In
this case, you need to contact IBM support to obtain the Emergency Support Access
(ESA) patch to restore temporary root authentication. The patch can only be obtained from
IBM under very specific conditions.

1. Verify the proper installation of the tape device driver using the rpm -qa lin_tape*
command at the Linux prompt. Example 10-1 shows what the output ought to look like.
The lin_tape driver in version 1.24 is currently installed on the cluster nodes.

Example 10-1 Linux command to query the installed tape device driver
iaadmin@ianode1:~> rpm -qa lin_tape*
lin_tape-1.24.0-1
lin_taped-1.24.0-1


2. Configure the tape devices on all cluster nodes by entering the sudo IBMtapeconfig
command as shown in Example 10-2. The IBMtapeconfig utility is part of the IBM device
driver package and is pre-installed in each cluster node of Information Archive appliances.

Example 10-2 configure the tape devices using the command IBMtapeconfig
iaadmin@ianode1:~>/usr/bin/IBMtapeconfig

Creating IBMtape special files
major number: 253
Attached devices: 0 1
mknod -m 0666 /dev/IBMtape0 c 253 0
mknod -m 0666 /dev/IBMtape0n c 253 1024
mknod -m 0666 /dev/IBMtape1 c 253 1
mknod -m 0666 /dev/IBMtape1n c 253 1025

Creating IBMchanger special files
major number: 253
Attached devices: 0 1
mknod -m 0666 /dev/IBMchanger0 c 253 2048
mknod -m 0666 /dev/IBMchanger1 c 253 2049

3. You can identify the detected tape devices by executing the command cat
/proc/scsi/IBMchanger and cat /proc/scsi/IBMtape. See sample output in
Example 10-3 and Example 10-4.

Example 10-3 Sample content of /proc/scsi/IBMchanger
iaadmin@ianode1:~>cat /proc/scsi/IBMchanger
lin_tape version: 1.24.0
lin_tape major number: 253
Attached Tape Devices:
Number model SN HBA FO Path
0 03584L22 0000078A02340406 qla2xxx NA
1 03584L22 0000078A02340406 qla2xxx NA

Example 10-4 Sample content of /proc/scsi/IBMtape
iaadmin@ianode1:~>cat /proc/scsi/IBMtape
0 ULT3580-TD4 1310125225 qla2xxx NA
1 ULT3580-TD4 1310127710 qla2xxx NA

4. The test for proper communication with the library medium changer can be performed with
the IBMtapeutil utility. Typing the IBMtapeutil -f /dev/IBMchanger0 inquiry command
returns the TS3500 Library (3584-L22) vital product data, as displayed in Example 10-5.

Example 10-5 Sample output of command IBMtapeutil -f /dev/IBMchanger0 inquiry
iaadmin@ianode1:~>IBMtapeutil -f /dev/IBMchanger0 inquiry
Issuing inquiry...

Inquiry Data:

Vendor ID-----------------------------IBM


Product ID----------------------------03584L22
Product Revision Level----------------8900

vendor1, Length 20

0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0000 - 3738 3030 3030 3037 3841 3032 3334 2031 [780000078A0234 1]
0010 - 8000 0000 [.... ]

10.6.3 Defining LTO4 tape drives and TS3500 library in the System Storage
Archive Manager server
This section describes the configuration for a TS3500 tape library with two LTO4 tape drives
in the System Storage Archive Manager server (for System Storage Archive Manager
Collections). The steps are similar if you need to configure tape attachment with an
Information Archive Tivoli Storage Manager server for File Archive Collections.

Note that if you plan to configure tape attachment for more than one collection, you can share
the drives among multiple collections by configuring IBM Tivoli Storage Manager library
sharing. IBM Tivoli Storage Manager library sharing is described in 10.7, “Tape drive
encryption” on page 433. To ensure that your tape devices are connected properly and
detected by the cluster nodes, you can either open the Integrated Solution Console page from
Information Archive Management  System Management (see Figure 10-4) or execute
the cat /proc/scsi/IBMtape command as shown in Example 10-4.

Figure 10-4 Attached tape devices seen in ISC

To define the LTO and library devices to System Storage Archive Manager, complete the
following steps:
1. Start an Information Archive Administration web interface.
Then, select Tivoli Storage Manager  Storage Devices from the main menu on the left
side of the Administration Center web interface.
2. Start the storage device wizard by selecting Servers  Add a storage device. Click Next
to start the wizard.
Figure 10-5 shows a drop-down list with the available device types for new storage
devices. In our example, we use the LTO device type because our 3588 drives use LTO
compatible media, which include LTO4, LTO3, LTO2, and LTO1.
In this window, you can also define devices that are connected to other Tivoli Storage
Manager servers. These devices can be shared between Tivoli Storage Manager servers
defined using the IBM Tivoli Storage Manager library sharing functionality as described
later on this chapter.


Figure 10-5 Storage device wizard: Select your device type

3. Define a TS3500 library named TS3500.
To define the library, type the name TS3500 into the Library name field and choose SCSI
as the library type, as shown in Figure 10-6. Depending on the device type you chose from
the previous menu, there are various library types available.

Figure 10-6 Storage device wizard: Select your library type

4. Define the library settings.
The device special file name is the device name that is used by the operating system to
communicate with the library. In the case of our TS3500 library, this is /dev/IBMchanger0.
Figure 10-7 also gives you the option to share the library with other Tivoli Storage
Manager servers, as mentioned in step 3.


Figure 10-7 Storage device wizard: Select library settings

The next window gives you an overview of the defined library and its parameters.
5. Define the tape drives.
Select Define Drives  Add Drive from the drop-down menu. Specify the drive name
drive01 and the device special file name /dev/IBMtape0 for the first drive. In the case of the
TS3500 library, the drive element address will be determined automatically by the IBM
Tivoli Storage Manager server. Click Add Another to repeat this step for the second drive
using drive02 and /dev/IBMtape1 as parameters. Click OK to define the drives. By clicking
Next, you get an overview of the defined drives.
6. Add Volumes.
This part of the wizard helps you discover and check-in the storage media, in our case, the
tape volumes. We assume the use of an empty tape volume with barcode labels for this
first test. You can add more volumes at a later time by invoking the Add volumes wizard
again in the library properties drop-down menu (see Figure 10-8).

Figure 10-8 Storage device wizard: Add volumes


At this time, you must not have any volume known to the System Storage Archive
Manager database, so you can proceed with the standard options. The wizard will start a
background process that can be monitored by entering the command query process from
the Administrative command line interface (Figure 10-9).

Figure 10-9 Storage device wizard: Volume options

7. Create storage pools.
In this step, we define a primary tape storage pool named TAPE_POOL with a maximum
of 999 scratch volumes (Figure 10-10). The number of scratch volumes depends on your
configuration. You can also define a copy pool, but we will skip this step for now because it
is described later in this example.

Figure 10-10 Storage device wizard: Creating storage pools


The Storage device wizard has finished the steps and shows a list of the defined devices
(Figure 10-11).

Figure 10-11 Storage device wizard: Final overview

In the storage devices main window, you now see the previously defined library. By
clicking the name of the library, you get the library properties overview, where you can
adjust the library parameters and add or remove volumes. Figure 10-12 shows the general
library properties box. Note that the serial number and the worldwide name of the library
have been automatically detected.

Figure 10-12 Library properties box


Note that a standard LTO device class named LTO_CLASS_1 has already been defined
and activated by the wizard in read/write mode.
8. Define an additional device class for the LTO WORM media.
From the storage devices main window, select Servers  View Device Classes. You get
a list showing the Device Classes defined for the System Storage Archive Manager
Server. Select Create a Device Class from the drop-down menu of this list, as shown in
Figure 10-13.

Figure 10-13 Device classes wizard: Select device type

Complete this step by selecting LTO as the device type. By clicking Next, you will see the
device class properties box. Provide a useful name such as LTO_CLASS_WORM and
select the previously defined library. Enable the WORM capability by checking the check
box, as shown in Figure 10-14, and finish the wizard.

Figure 10-14 Device classes wizard: Properties


9. Verify the definitions.
Verify your definitions by issuing the following commands at the command line:
query library
query drive
query path
query devclass
query stgpool
For a more detailed list, specify f=d, which is the short form of format=detailed.
Example 10-6 shows detailed information about the previously defined device class using
the query devclass LTO_CLASS_WORM f=d command.

Example 10-6 Detailed informational output for a WORM-enabled device class
tsm: SSAM1>q devclass LTO_CLASS_WORM f=d

Device Class Name: LTO_CLASS_WORM
Device Access Strategy: Sequential
Storage Pool Count: 0
Device Type: LTO
Format: DRIVE
Est/Max Capacity (MB):
Mount Limit: DRIVES
Mount Wait (min): 60
Mount Retention (min): 60
Label Prefix: ADSM
Library: TS3500
Directory:
Server Name:
Retry Period:
Retry Interval:
Shared:
High-level Address:
Minimum Capacity:
WORM: Yes
Drive Encryption: Allow
Scaled Capacity:
Last Update by (administrator): ISCADMIN

10.6.4 Integrating LTO4 drives and TS3500 library into the storage hierarchy
In this section, we describe three scenarios for integrating the TS3500 library into the storage
hierarchy.

Scenario 1: Using (WORM) tape as the migration destination
For this scenario, complete the following steps (see Figure 10-15):
1. Define a sequential access storage pool for migration-based thresholds, off the primary
disk pool to the tape pool associated with the WORM tape device class.

Define a sequential access storage pool named ARCHIVE_TAPES associated with the
device class named LTO_CLASS_WORM by typing the following command:
define stgpool ARCHIVE_TAPES LTO_CLASS_WORM pooltype=primary maxscratch=999


If you are using the web interface, go to the Storage devices main window and select
Servers  View Storage Pools  Create a Storage Pool and follow the wizard. Fill in
the storage pool name ARCHIVE_TAPES and an optional description. Choose Primary,
sequential access as the storage pool type.

Figure 10-15 Storage pool wizard: Select name, description, and type

Finish the wizard by selecting the device class LTO_CLASS_WORM for the storage pool,
as shown in Figure 10-16, and confirm the overview of the created storage pool settings.

Figure 10-16 Storage pool wizard: Select the WORM-enabled device class


You now see an overview of the defined storage pools, as shown in Figure 10-17. Note
that the FILEPOOL is preconfigured for the System Storage Archive Manager Server
during collection creation.

Figure 10-17 Defined storage pools for the System Storage Archive Manager Server

By clicking the storage pool name, you get the storage pool properties box. Set the values
according to your needs. On the command line, issue the help update stgpool command
for information about syntax and the use of parameters.
In the context of a WORM medium, the Delay Period for Volumes Reuse parameter does
not make sense at first. By nature, a tape WORM media cannot be reused at all. However,
the effect of this parameter is that an “empty” volume (all data expired from the System
Storage Archive Manager point of view) is kept in the System Storage Archive Manager
database in status PENDING until the delay period passes. After that, System Storage
Archive Manager wipes out all references to this volume; it is unknown from now on. This
status enables you to define a mechanism within System Storage Archive Manager to
identify expired volumes, and, for example, convey them to a scrapping process. For
example, a daily query volume status=pending command displays the “empty” tapes.
Furthermore, these volumes must have been kept in pending status for as long as
database backups are held. This allows a rollback to a previous version of the database in
case of a disaster while still having access to the data on the WORM media, which is not
the case if the volumes had already been scrapped. Therefore, it is a good practice to set
the Delay Period for Volumes Reuse to a non-zero value; in the context of the Information
Archive System Storage Archive Manager Server, set this to three days, because
database backups are kept for this period of time.
CRC Data is set to YES; this improves the data integrity for the copy objects. CRC Data
specifies whether a cyclic redundancy check (CRC) validates storage pool data when
audit volume processing occurs on the server. By setting CRC Data Validation to YES,
data is stored that contains CRC information. When you schedule audit volume
processing, you can continually ensure the integrity of data stored in your storage
hierarchy. We assume that you always configure the CRC data validation on the
Information Archive Appliance, even if you never use the audit volume processing to
validate the data.

Tip: Use the IBM Tivoli Storage Manager features such as Delay Period for Volumes
Reuse and cyclic redundancy check (CRC) data validation to improve data integrity.

2. Include the sequential access storage pool in your storage hierarchy.
To use the previously defined storage pool ARCHIVE_TAPES, you need to include it in the
existing storage hierarchy by updating the FILEPOOL to point to the new pool:
update stgpool filepool nextstgpool=archive_tapes


If you are using the web interface, open the FILEPOOL properties box from the Storage
Pools overview and choose ARCHIVE_TAPES from the Next Storage Pool drop-down
menu, as shown in Figure 10-18.

Figure 10-18 FILEPOOL properties box: Choose the next storage pool

The High Migration Threshold and Low Migration Threshold values are kept at the default
values. Crossing the high threshold causes the IBM Tivoli Storage Manager server to start
migrating data off this pool to the next specified pool until the percentage of occupancy
(versus the total capacity of the storage pool) indicated by the low threshold has been
reached. A good practice to control the occupancy level is to work with scripts and
schedules to adjust these values dynamically according to, for example, storage capacity
requirements or backup schedules. For example, set up a schedule to run every day to
initiate the migration of all data from the disk pool to the tape pool on a daily basis.
This schedule calls a script that sets both the low migration threshold and then the high
migration threshold to zero. This will instantly result in the migration of all data off the disk
pool into the tape pool. After completion, the values will be set to the original values, again
using a combination of scripts and schedules. The advantage of this method, rather than
maintaining the migration thresholds constantly at the same level, is a guarantee that all
objects will eventually migrate onto WORM tape. Otherwise, small objects run the risk of
never migrating, because they might always be within a capacity level that is lower than
the low migration threshold.
Cache Migrated Files controls whether or not objects are deleted from the FILEPOOL
after successful migration to the ARCHIVE_TAPES. Deleting objects releases the space in
the primary pool, while caching them increases the hit ratio on disk and reduces the
number of tape mounts required in case a object is accessed by users.
Migration Delay set to 0 means that objects can be migrated by System Storage Archive
Manager according to the occupancy level. If, for example, a requirement exists to keep
objects in the disk pool for at least one year to guarantee fast access times, this parameter
has to be set to a value of 365.
Migration Continue specifies if migration must continue disregarding and overriding the
(non-zero) Migration Delay value. If you do not want this behavior, consider an appropriate
sizing of the primary disk pool.


Scenario 2: Using (WORM) tape as data backup destination
For this scenario, complete the following steps in Figure 10-19:
1. Define a copy storage pool for incremental backups of the archived data to WORM tape
associated with the device class.
Define a primary copy storage pool named COPY_TAPES associated with the device
class named LTO_CLASS_WORM by typing the following command:
define stgpool copy_tapes lto_class_worm pooltype=copy maxscratch=999
reusedelay=3 crcdata=yes
If using the web interface, go to the storage devices main window and select Servers 
View Storage Pools  Create a Storage Pool and follow the wizard. Fill in the storage
pool name COPY_TAPES and add an optional description. Choose Copy as the storage
pool type to create a sequential access storage pool.

Figure 10-19 Storage pool wizard: Select name and description for copypool

Define LTO_CLASS_WORM as the device class and choose the maximum number of
scratch volumes, as shown in Figure 10-20.
Terminate the wizard by confirming the summary.
This new copy storage pool can now be used as a target to incrementally back up data to
the LTO WORM media. The backup will be established with two scheduled processes:
One copying data off the disk storage pool FILEPOOL and another copying data off the
tape storage pool ARCHIVE_TAPES, because any document or data object can be stored
in either of the pools, depending on whether it has already been migrated or not.


Figure 10-20 Storage pool wizard: Choose device class

2. Create a server command script to back up the primary pool to the copy pool with the
following sequences:
a. The primary pool FILEPOOL
b. The sequential access pool ARCHIVE_TAPES
To complete these tasks, create a server command script named BASTGPOOL with the
following syntax:
define script bastgpool
update script bastgpool "backup stgpool filepool copy_tapes wait=yes"
update script bastgpool "backup stgpool archive_tapes copy_tapes wait=yes"
If using the web interface, go to the storage devices main window and select Servers 
Server Properties  Scripts  Create Script, as shown in Figure 10-21.

Figure 10-21 Define a new command script BASTGPOOL

Note that by using the Administration Center web interface, you have the capability to test
scripts (even with user-defined variables) before production use.


3. Create a schedule to execute a server command script.
Create a schedule named BASTGPOOL or execute the previously created server
command script BASTGPOOL at the command line:
define schedule bastgpool cmd="run bastgpool" active=yes starttime="12:00:00"
If using the web interface, select Server Properties  Administrative Schedules 
Create a Schedule. Follow the wizard and provide BASTGPOOL as the schedule name,
add a description, and enter run BASTGPOOL as the command to run in the schedule, as

Figure 10-22 Administrative schedule wizard: Choose name and command to run

Select the time, date, and repeat frequency of this schedule. See Figure 10-23.

Figure 10-23 Define schedule, execution time, and repetition

Specify the options shown in Figure 10-24. End the wizard by committing the summary.


Figure 10-24 Define further options

In our example, the System Storage Archive Manager Server will, from 03/08/2010 (March
08, 2010) and forward, attempt to start the script BASTGPOOL on a daily basis at
06:00:00 pm. If it cannot be started within the specified duration of one hour, the script will
be skipped and thus not be executed until the next day. After being started, the primary
pools will be backed up to the tape copy pool as specified in the server command script.
The Start time has to be chosen individually to reflect the desired schedules and workload
within the customer environment.
Note that the tape library has to have a sufficient number of cartridges and that these are
checked into the System Storage Archive Manager server. The number of cartridges
depends on the amount of data stored in the primary storage pool or pools being backed
up. If not enough media are available, the schedule can be suspended by making it
inactive with the following command:
update schedule bastgpool type=archive active=no
If you are using the web interface, select Server Properties  Administrative
Schedules, select the BASTGPOOL script, and choose Modify Schedule. In the
schedule properties notebook, uncheck the Schedule is active check box as shown in
Figure 10-25.


Figure 10-25 Deactivate administrative schedule

Tip: Working with scripts instead of single schedules has a significant advantage:
Single schedules will be executed based on their starting time, without depending on
other schedules. Within a script, the parameter wait=yes enables you to initiate a
process dependent on the previous one, which is often desired. In our example, we
want to have the backup of the primary disk storage pool happen and complete first,
before the backup of the sequential access storage pool is carried out. A script can
include many and any kind of System Storage Archive Manager server commands,
such as disable session, expire inventory, and update stgpool.

4. Optional: Run the script once to verify that it is working correctly.
The script can be started manually to verify that the desired backups are actually carried
out. Note that this can be a time-consuming process, depending on the amount of data
already stored in the System Storage Archive Manager primary storage pools. It also
assumes that enough tape media are inserted in the library and available for System
Storage Archive Manager use.
Start the script BASTGPOOL to initiate the backup of the primary storage pools:
run bastgpool
If using the web interface, select Server Properties  Scripts, select the BASTGPOOL
script, and choose Run Script. In the Run Script window, leave the check box Show
processing information in addition to script commands checked and watch the script
results. Click Run Script to start the process. See Figure 10-26.


Figure 10-26 Run script: Watch the output in the script results box

The output of a successful backup process will look similar to the illustration shown in
Figure 10-27.

Figure 10-27 Operation results: successful backup process


Scenario 3: Using (rewritable) tape for database backups
For this scenario, create a schedule to execute a System Storage Archive Manager database
backup to rewritable tape media. For this purpose, we use the automatically generated
read/write tape device class LTO_CLASS_1.

Create a schedule named BADBTAPE to periodically generate backups of the Tivoli Storage
Manager database onto rewritable tape media:
define schedule badbtape cmd="backup db devc=LTO_CLASS_1 type=full" active=yes
starttime="07:00:00"

If you are using the web interface, select Server Properties  Administrative Schedules
and run Create a Schedule. Follow the wizard and provide BADBTAPE as the schedule
name, a description, and type backup db devc=LTO_CLASS_1 type=full as the command to
run in this schedule, as shown in Figure 10-28.

Figure 10-28 Create administrative schedule for daily database backups to tape

Accept the default settings for the remaining steps until you get to the summary. Then click
Finish to complete the wizard.

Start the System Storage Archive Manager database backup once with the following
command:
backup db devc=LTO_CLASS_1 type=full

Your database is now successfully backed up to rewritable tape media. Check the activity log
with the command query actlog for entries such as these:
ANR4550I Full database backup (process 10) complete, 643 pages copied.
ANR0985I Process 10 for DATABASE BACKUP running in the BACKGROUND completed with
completion state SUCCESS at 22:47:18.


The command query libvol shows at least one rewritable tape volume with a status of
DbBackup, as shown in Example 10-7.

Example 10-7 Query libvol command output
tsm: SSAM1>q libvol

Library Name Volume Name Status Owner Last Use Home Device
Element Type
------------ ----------- ---------------- ---------- --------- ------- ------
TS3500 IA0000L3 Private NFS1 DbBackup 4,098 LTO
TS3500 IA0001L3 Scratch 4,101 LTO
TS3500 IA0020LT Scratch(WORM) 4,099 LTO

This schedule initiates a full database backup onto rewritable tape media every day at
07:00:00. The preconfigured database backup onto specific disk space in the DS4200 starts
at 06:00:00, and it will be completed by the time the backup to tape starts. If the script cannot
be started within the specified duration of one hour, the script will be skipped and not be
executed until the next day.

This step demonstrates how to integrate a database backup to tape into the preconfigured
System Storage Archive Manager Server. A better practice is again to create a server
command script, combining both the database backup to disk and then to tape, consecutively,
using the wait=yes parameter, as described in the previous steps. It is up to the customer to
customize the IBM Tivoli Storage Manager server concepts according to the business needs
and requirements of the company.

10.6.5 Modifying tape migration thresholds
Migration thresholds are used to manage the migration of documents from the IBM
Information Archive appliance to an optional tape storage device. The migration threshold can
be modified by the ISC or the IBM Tivoli Storage Manager command line interface. Both
methods are described below for storage pool IA_TAPEMIG.

Tip: This procedure applies for the primary tape storage pool only. If you need to modify
the tape copy-pool settings such as backup and simultaneous write, you cannot use the
graphical administrative interface. Instead, use the Tivoli Storage Manager command line
interface to run commands such as BACKUP STGPOOL and UPDATE STGPOOL. For
more information, see the Tivoli Storage Manager information center:
http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp

1. Using the Integrated Solution Console:
a. Expand Tivoli Storage Manager in the navigation tree and click Storage Devices.
b. In the Servers section, select the server that is named after the collection that you are
configuring the tape migration thresholds for and click Select Action  View Storage
Pools.
c. In the Storage Pools table, click the file pool storage pool of the collection to open the
properties notebook for the storage pool.
d. Click the Migration tab and specify the start and stop thresholds for migration.


Figure 10-29 Modify Storage Pool migration trigger

2. Using the IBM Tivoli Storage Manager command line interface:
Open the Administrative command line interface and perform the steps shown in
Example 10-8 to modify the migration thresholds.

Example 10-8 Modify migration setting by command line interface


Enter your user account: dwendler
tsm: SSAM1>query stgpool

Storage Device Estimated Pct Pct High Low Next Stora-
Pool Name Class Name Capacity Util Migr Mig Mig ge Pool
Pct Pct
----------- ---------- ---------- ----- ----- ---- --- -----------
ARCHIVEPOOL DISK 0.0 M 0.0 0.0 90 70 FILEPOOL
FILEPOOL FILECLASS 4,633 G 3.6 3.6 60 40 TAPEMIG
IA_TAPEMIG LTO_CLASS-_1 0.0 M 0.0 0.0 90 70

tsm: SSAM1>update stgpool IA_tapemig hi=50 lo=30
ANR2202I Storage pool IA_TAPEMIG updated.

tsm: SSAM1>q stg IA_TAPEMIG

Storage Device Estimated Pct Pct High Low Next Stora-
Pool Name Class Name Capacity Util Migr Mig Mig ge Pool
Pct Pct
----------- ---------- ---------- ----- ----- ---- --- -----------
IA_TAPEMIG LTO_CLASS-1 0.0 M 0.0 0.0 50 30

Tip: The value that you specify in the migration high threshold field is the percentage of
capacity utilization at which migration starts. The value that you specify in the migration
low threshold field is when migration ends.


10.7 Tape drive encryption
Tape drive-based hardware encryption is supported with the Information Archive System
Storage Archive Manager server as well as with the Information Archive Tivoli Storage
Manager server for File Archive Collections. LTO4, TS1120, or newer tape drives that support
hardware-based encryption are required. In this section, we explain the various tape drive
encryption methods and describe the setup of the application-based tape encryption for IBM
Information Archive, exemplarily for a System Storage Archive Manager Collection.

It is often critical to secure client data, especially when that data might be of a sensitive
nature. To ensure that data for off-site volumes is protected, IBM Tape encryption technology
is available. This technology utilizes a stronger level of encryption by requiring 256-bit
Advanced Encryption Standard (AES) encryption keys. Keys are passed to the drive by a key
manager in order to encrypt and decrypt data.

Encryption: Hardware-based tape drive encryption in conjunction with application-based
encryption is supported for both types of collections. System Archive Storage Manager and
the Tivoli Storage Manager for File Archive Collections support application managed
encryption. The examples in this chapter refer to application managed encryption
configuration with the System Storage Archive Manager server but can be applied to the
IBM Tivoli Storage Manager file archive server as well.

10.7.1 Tape drive encryption methods
IBM tape drives supports the following three methods of drive encryption:

Application managed encryption
Encryption keys are managed by the application, in this case, the System Storage Archive
Manager. System Storage Archive Manager generates and stores the keys in the server
database. Data is encrypted during WRITE operations when the encryption key is passed
from the server to the drive. Data is decrypted on READ operations. The application
encryption method is only supported for storage pool volumes. To use application encryption,
set the DRIVEENCRYPTION parameter to ON in the associated DEVCLASS.

Library managed encryption
Encryption keys are managed by the tape library. Keys are stored in an encryption key
manager such as IBM Tivoli Key Lifecycle Manager (TKLM) and provided to the drive
transparent to System Storage Archive Manager. If the hardware is set up to use library
encryption, System Storage Archive Manager can allow this method to be utilized by setting
the DRIVEENCRYPTION parameter to ALLOW in the associated DEVCLASS.

System managed encryption
System managed encryption is available on AIX and MVS, Solaris, Linux, and Windows.
Encryption keys are managed by the device driver or operating system and stored in an
encryption key manager. They are provided to the drive transparent to System Storage
Archive Manager. If the hardware is set up to use system encryption, System Storage Archive
Manager can allow this method to be utilized by setting the DRIVEENCRYPTION parameter
to ALLOW.

Attention: Hardware-based tape encryption will only encrypt data written to the tape.
No encryption will be done for data stored on disk.


In this chapter, we describe the implementation of application managed encryption with a
System Storage Archive Manager server. Additional information about key management and
how to initiate tape encryption can be found in the IBM Tape Device Drivers Installation and
User’s Guide, also available at the following web sites:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?toc=/com.ibm.itst
ftp://ftp.software.ibm.com/storage/devdrvr/Doc/IBM_Tape_Driver_IUG.pdf

Hardware requirements for drive encryption
At the time of the writing of this book, the following IBM tape drives support drive encryption:
IBM TS1120 Enterprise Tape Drives that are encryption capable (Type: 3592-E05) and
TS1130 (Type: 3592-E06). Application managed tape encryption using the IBM TS1120
Tape Drives is supported in the following libraries:
– IBM System Storage TS3400 Tape Library

Encryption: Only TS1120 with the ENC sticker at the rear side of the drive is
encryption capable. Earlier TS1120s might have no encryption support. If you do not
know how to determine the encryption capability of your tape drive, call IBM support. All
TS1130 tape drives are encryption capable.

IBM TS1040 LTO4 and follow-on products such as LTO5 Tape Drive. Application managed
tape encryption using IBM TS1040 Tape Drives is supported in the following IBM libraries:

10.7.2 Encryption method setup for TS3500
Before you can use the drive encryption in the Information Archive Tivoli Storage Manager or
System Storage Archive Manager server, you must set up the encryption method at the tape
drive or at the tape library that contains the tape drive. The configured encryption method in
the drive or library must match your operating system or application settings. The
configuration steps vary depending on the library type that you are using. To configure
Application Managed Encryption for a logical library in a TS3500 library, execute the following
steps:

For all tape drives that are installed within a TS3500 library, you can set up the encryption
method through the library web interface. Therefore select Library  Logical Libraries 
Select Library  choose  Modify Encryption Method  GO and select Application
Managed encryption. For further information, see the TS3500 Users Guide at this website:
http://www-1.ibm.com/support/docview.wss?rs=1159&context=STCMML8&dc=DA400&uid=ssg1
S7000149&loc=en_US&cs=utf-8&lang=en


10.7.3 Drive encryption setup
The System Storage Archive Manager and File Archive server can manage the encryption
keys associated with hardware-based encryption in the IBM LTO or TS1100 series tape
drives. Because the encryption keys are stored within the server database, you cannot read
the content of an encrypted tape with a tape drive that is not assigned to that server. Do not
use drive encryption for database backups to tape!

The drive encryption will be turned on or off in the device class definition of the tape drives
with the driveencryption option. Three options are available: ALLOW (the default), ON, or
OFF:
ON: Specifies that IBM Tivoli Storage Manager server is the key manager for tape drive
encryption and will permit drive encryption for empty volumes only if the application
method is enabled. If you specify ON and you enable either the library or system method
of encryption, drive encryption will not be permitted and backup operations will fail. This
option is used in our sample implementation of AME with the System Storage Archive
Manager server (see Example 10-9).
ALLOW: Specifies that IBM Tivoli Storage Manager server does not manage the keys for
drive encryption. However, drive encryption for empty volumes is permitted if either the
library or system managed encryption method enabled at the physical library
configuration.
OFF: Specifies that drive encryption will not be permitted. If you enable either the library or
system method of encryption, backups will fail. If you enable the application method, IBM
Tivoli Storage Manager server will disable encryption, and backups will be attempted.

The following simplified example shows the steps you can take to permit the encryption of
data for empty volumes in a storage pool. In this example we assume that a library is already
configured. Log in at the Command Line Administrative interface and update the existing
device class LTO4CLASS to write to encrypted media.

In Example 10-9 we define an additional device class and a storage pool.

Example 10-9 Device class and storage pool for tape encryption
tsm: SSAM1>define devclass LTO_Encrypt library=TS3500 devtype=LTO
DRIVEEncryption=on
ANR2203I Device class LTO_ENCRYPT defined.

tsm: SSAM1>define stgpool LTO_encrypt_pool LTO_Encrypt maxscratch=10
ANR2200I Storage pool LTO_ENCRYPT_POOL defined (device class LTO_ENCRYPT).

10.8 Persistent naming
In a SAN environment, persistent naming, also referred as persistent binding, is used to
ensure that attached devices are always configured with the same logical name across
system reboots based on the SCSI ID, LUN ID, and host bus adapter (HBA). When the Linux
operating system is booted, it performs a device discovery and assigns a default logical name
to each device found in a sequential order. For example, if there are four tape drives attached
the Linux kernel initially configures them with the logical names IBMtapeX, where X is an
increasing number starting with value zero. The generated special file name consists of the
prefix IBMtape or IBMchanger and is unique within the whole system.


Drive path definitions: Tape drives can be connected to more than one host or cluster
node in order to configure library sharing across multiple collections as well as supporting
collection failover to another cluster node in case of cluster node failures. By configuring
the tape devices with identically persistent namings on all cluster nodes, the Information
Archive Tivoli Storage Manager servers can be configured in a way that the drive path
definitions will refer always to the correct tape device.

The output in Example 10-10 shows that four tape drives are attached to the system and the
IBM tape device driver has generated the two special files for each tape device in the /dev
directory, as shown in Example 10-11. The special files in the style /dev/IBMtapeXn are “No
rewind on close” devices. This means that the tape drive does not perform an implicit rewind
of the loaded tape media when the file descriptor to that special file name is closed. This will
be done automatically by the standard special file /dev/IBMtapeX. Both special file names
belong to the same physical device.

Example 10-10 Query installed IBM tape devices
iaadmin@ianode1:~> cat /proc/scsi/IBMtape
0 03592E06 000001327093 qla2xxx NA
1 03592E06 000001327095 qla2xxx NA
2 03592E06 000001327095 qla2xxx NA
3 03592E06 000001327093 qla2xxx NA

Example 10-11 Tape special file names in /dev
iaadmin@ianode1:~> ls -la /dev/IBMtape*
crw-rw-rw- 1 root tsmsrvrs 253, 0 2010-04-13 10:14 /dev/IBMtape0
crw-rw-rw- 1 root tsmsrvrs 253, 1024 2010-04-13 10:14 /dev/IBMtape0n

If one or more drives are powered off or are not connected to the host, the Linux kernel will
detect the tape devices in another order during a reboot and thus existing configurations in
the backup application might refer to an invalid special file name. This is one example, but
there are other cases where the special file names of devices can change when the system is
rebooted. For applications that need a consistent naming convention for all attached devices,
this is accomplished with persistent naming by defining a unique logical name. Certain
applications, such as IBM Tivoli Storage Manager, do not necessarily rely on persistent
namings. A function called SAN discovery enables IBM Tivoli Storage Manager to detect the
correct SAN attached tape devices based on their serial number and WWPN regardless of
the special file name created in the hosts SYSFS.


10.8.1 Linux device manager udev

Root access: In order to configure persistent naming support in the Information Archive
cluster nodes, you need to get root access. This can be achieved by either logging on at
the cluster nodes. Depending on the Enhanced Tamper Protection settings, you might
need to apply an ESA patch to gain temporarily root access. The ESA patch can only be
obtained from IBM under specific conditions.

Starting with Linux kernel 2.6, the new device manager udev has been introduced. udev
manages device nodes in the device directory /dev and handles the /dev directory and all
user space actions when adding/removing devices. On device creation, udev reads the sysfs
directory of the given device to collect device attributes such as serial number, world wide
port name (WWPN), or bus device number. These attributes can be used as keys to
determine a unique name for the device. udev maintains a database for devices present on
the system. On device removal, udev queries its database for the name of the device file to be
deleted. Example 10-12 shows how to query the attributed of a tape drive. The output has
been summarized for demonstration purposes so not all attributes are displayed.

Example 10-12 Query device attributes of tape devices with udevinfo
iaadmin@ianode1:~> udevinfo -a -p $(udevinfo -q path -n /dev/IBMtape0)

looking at device '/class/lin_tape/IBMtape0':
KERNEL=="IBMtape0"
SUBSYSTEM=="lin_tape"
SYSFS{sys_encryption_write}=="2"
SYSFS{sys_encryption_proxy}=="1"
SYSFS{dev}=="253:0"

looking at device
'/devices/pci0000:00/0000:00:03.0/0000:15:00.1/host6/rport-6:0-0/target6:0:0/6:0:0
:0':
ID=="6:0:0:0"
BUS=="scsi"
DRIVER=="lin_tape"
SYSFS{primary_path}=="NA"
SYSFS{ww_port_name}=="0x500507630F810916"
SYSFS{ww_node_name}=="0x500507630F010916"
SYSFS{serial_num}=="000001327093"
SYSFS{rev}=="268F"
SYSFS{model}=="03592E06 "
SYSFS{vendor}=="IBM "

The rules for device naming are read from the files located in the /etc/udev/rules.d/ directory,
or at the location specified by the udev_rules value in the /etc/udev/udev.conf file. Every line in
the rules file defines the mapping between device attributes and the device name. One or
more keys are specified to match a rule with the current device. If all keys are matching, the
rule will be applied and the name is used to name the device file. If no matching rule is found,
the default kernel device name is used.


10.8.2 Defining udev rules for tape devices
In the following example we create udev rules for IBM tape devices based on the tape's
worldwide portname, the serial number, and the SCSI ID and LUNs. As shown in
Example 10-10 on page 436, each tape drive is detected twice, which is indicated by the
serial number, but the WWPN is unique because the TS1130 tape drives are connected to
the cluster nodes by primary and alternate drive port. Each port has a unique WWPN.

Example 10-13 shows a sample command to query the device serial number, the WWPN,
and the SCSI ID. These attributes are used later on to create udev rules for IBM tape devices.

Example 10-13 Query relevant device attributed for udev rule definition
iaadmin@ianode1:~> for i in {0..3}; do echo; udevinfo -a -p $(udevinfo -q path -n
/dev/IBMtape$i) | grep "KERNEL|ww_port_name|serial_num|ID=="[0-9]:[0-9]:[0-9]:
[0-9]"; done;

KERNEL=="IBMtape0"
ID=="6:0:0:0"

KERNEL=="IBMtape1"
ID=="6:0:1:0"

KERNEL=="IBMtape2"
ID=="8:0:0:0"

KERNEL=="IBMtape3"
ID=="8:0:1:0"

The udev rules are defined in the rules file /etc/udev/rules.d/98-lin_tape.rules. Example 10-14
shows an example to create unique special file names for the tape drive devices based on the
attributes SYSFS{serial_num} and SYSFS{ww_port_name}. This creates a device special file
name defined at variable SYMLINK based on the serial number and the WWPN of the drive.

Example 10-14 Create udev rules for IBM tape drive devices

BUS=="scsi", KERNEL=="IBMtape[0-9]", SYSFS{serial_num}=="000001327093",
SYSFS{ww_port_name}=="0x500507630F410916", SYMLINK+="tape0"

BUS=="scsi", KERNEL=="IBMtape[0-9]n", SYSFS{serial_num}=="000001327093",
SYSFS{ww_port_name}=="0x500507630F410916", SYMLINK+="tape0n"

SYSFS{ww_port_name}=="0x500507630F810916", SYMLINK+="tape1"

SYSFS{ww_port_name}=="0x500507630F810916", SYMLINK+="tape1n"


After restarting the udev service or rebooting the operating system, the new special file
names will be created as shown in Example 10-15.

Example 10-15 List new special file names created by udev device manager
iaadmin@ianode2:~> ls -l /dev/tape*
lrwxrwxrwx 1 root root 8 Apr 20 09:23 /dev/tape0 -> IBMtape3
lrwxrwxrwx 1 root root 9 Apr 20 09:23 /dev/tape0n -> IBMtape3n

10.8.3 Defining udev rules for medium changer commands
Analogous to the udev rule definition for tape devices, we briefly describe the definition of
udev rules for medium changer devices. Two TS1130 tape drives are configured as the
control path device (CPD) and are attached to each cluster node by primary and alternate
path. So four medium changer devices are reported to the hosts. Example 10-16 shows a
sample query to retrieve attributes required for creating udev rules.

Example 10-16 Query device attributes of medium changer devices with udevinfo
iaadmin@ianode2:~> for i in {0..3}; do echo; udevinfo -a -p $(udevinfo -q path -n
/dev/IBMchanger$i) | grep "KERNEL|ww_port_name|serial_num|
ID=="[0-9]:[0-9]:[0-9]:1"; done;

KERNEL=="IBMchanger0"
ID=="6:0:0:1"
SYSFS{serial_num}=="0000078A0234040B"

ID=="6:0:1:1"

ID=="8:0:0:1"

ID=="8:0:1:1"


Based on the attributes selected in Example 10-16 on page 439, the following udev rules are
created, as shown in Example 10-17.

Example 10-17 Create udev rules for IBM medium changer devices
BUS=="scsi", KERNEL=="IBMchanger[0-9]", SYSFS{serial_num}=="0000078A0234040B",
ID=="6:0:0:1", SYMLINK+="changer1"

After restarting the udev service or rebooting the operating system, the new special file
names will be created as shown in Example 10-18.

Example 10-18 List new special file names created by udev device manager
ianode2:/etc/udev/rules.d # ls -l /dev/changer*
lrwxrwxrwx 1 root root 11 Apr 20 09:23 /dev/changer0 -> IBMchanger3

The special file names created for persistent naming will remain the same regardless of the
sequence in which the tape devices are reported to the hosts. If these persistent special file
names are defined in the backup application, there is no need to update the path definitions
any more.


11

Chapter 11. Information Archive data backup
and restore
In this chapter we explain backup and recovery methods for data archived in IBM Information
Archive (Information Archive).

It is important to perform backups of all archived data. A backup will allow you to recover most
data (up to the latest valid backup) in case of loss or corruption at the Information Archive
appliance. Backup is critical for archive data, which usually cannot be recreated.

In this chapter we cover both File Archive Collections and System Storage Archive Manager
Collections. We explain how to back up System Storage Archive Manager data to tape drives
and how to define a connection to an external IBM Tivoli Storage Manager server, which is
required for backing up File Archive Collections.

For Disaster Recovery Protection and Business Continuity capabilities based on the
Enhanced Remote Mirroring feature, see Chapter 12, “Enhanced Remote Mirroring” on
page 461.


11.1 System Storage Archive Manager Collections backup and
restore
In this section we cover the backup and restore operations for System Storage Archive
Manager Collections.

11.1.1 Backing up System Storage Archive Manager Collections
The System Storage Archive Manager relies internally on a DB2 database to store all
metadata and policies defined for archived data. The archived data itself is stored in storage
pools. The database and the storage pools physically reside on the Information Archive disk
Storage Controller assigned to that collection.

This section covers the backups from both the database and storage pools to external media.
We assume that you have already defined a tape library and tape drives for your System
Storage Archive Manager Collection, as explained in Chapter 10., “Tape attachment with
IBM Information Archive” on page 403.

Backing up storage pools to tape
In System Storage Archive Manager, you can define a storage copy pool to create a copy of
all archived data stored on the Information Archive disk storage, to external media (tape). This
copy, from the primary storage pool to the storage copypool, can be done on a scheduled
basis and copy all changes since the last run.

To create a scheduled backup of your primary disk storage pool, follow these steps:
1. Log in to the Management Console using the iaadmin user account, locally or remotely
with ssh.
2. In the terminal window, launch the System Storage Archive Manager administrative client
with the command:
dsmadmc -server=<collection_name>
You will be prompted for a userid and password. Use a userid with the TSM administrator
role.
3. Make sure that you have tapes in status SCRATCH available in the library. Enter the IBM
Tivoli Storage Manager command query libvol to display the available tapes.

Tip: Use WORM tapes for storage copy pools, if necessary, for compliance reasons.

4. Create a copy storage pool by issuing the IBM Tivoli Storage Manager command:
define stgpool <name_of_the_copy_pool> <tape_device_class> pooltype=copy
reusedelay=<number_of_days_before_reuse> maxscratch=<number_of_scratch_tapes>
crcdata=yes.
See Example 11-1.

Retention delay: The parameter resusedelay defines the number of days before the
tape can be rewritten after all files on the media are expired. This number depends on
the number of database backup sets that are kept. It is best to set the value at 3
minimum when using rewritable tapes. For WORM tapes, this option has no effect,
because you cannot overwrite them.


Example 11-1 Define a storage copypool
tsm: SSAM1>define stgpool tapecopy LTO_CLASS_1 pooltype=copy reusedelay=3
maxscratch=100 crcdata=yes
ANR2200I Storage pool TAPECOPY defined (device class LTO_CLASS_1).

5. Define a script to summarize all necessary tasks that need to be scheduled. The first
command within this script will be the backup stgpool command which copies all data
from disk to tape.
To define a new script, enter the command
define script <name_of_script> “<command_to_execute>”
desc=’<description_of_script>’
See Example 11-2.

Example 11-2 Define script daily_backup_to_tape
tsm: SSAM1>define script daily_backup_to_tape "backup stgpool filepool tapecopy
wait=yes" desc='daily backup to tape'
ANR1454I DEFINE SCRIPT: Command script DAILY_BACKUP_TO_TAPE defined.

6. Run the script by entering run daily_backup_to_tape, to create the first copy of your data
from the primary storage pool to tape. With the query occ command, you can verify the
success of the copy process. If each defined node does show the same number of files on
the primary disk pool and the storage copypool on tape, then both pools are synchronized.
7. Define a schedule to run the script on a regular basis. Issue the command:
define schedule <name_of_the_schedule> type=administrative
cmd=”<name_of_the_script_which_was_created>” active=yes
starttime=<time_to_start>.
Example 11-3 illustrates the usage of the command.

Tip: It is best to schedule this script at a time when the activity of your collection is low
(nightly hours). The runtime for the backup script depends on the amount of changes in the
storage pool and the speed of your backup device. You can verify the runtime afterwards
by checking the activity log of the System Storage Archive Manager server.

The backup is very I/O intensive and it will impact the performance of your collection, if it
runs in parallel with your daily business or other schedules.

Example 11-3 Define schedule to run the daily_backup_to_tape script
tsm: SSAM1>define schedule backup_to_tape type=administrative cmd="run
daily_backup_to_tape" active=yes starttime=02:00
ANR2577I Schedule DBBACKUP_TO_TAPE defined.

Backing up the System Storage Archive Manager database
A backup of the System Storage Archive Manager database can be performed to the
Information Archive disk storage subsystem and/or to tape devices attached to Information
Archive. The backup to disk is preconfigured, during the creation of a collection.

Backing up System Storage Archive Manager database to disk
When you create a System Storage Archive Manager Collection, Information Archive defines
automatically the script DAILY_MAINT which runs a scheduled backup of the database to
disk. This predefined script runs daily at 6:00AM by default.

Chapter 11. Information Archive data backup and restore 443

You can query the contents of the script with the IBM Tivoli Storage Manager command
q script DAILY_MAINT f=l as shown in Example 11-4.

Example 11-4 Content of the DAILY_MAINT script which performs daily database backup
tsm: SSAM1>q script daily_maint f=l

Name Line Command
Number
---------- ------ ------------------------------------------------------------
DAILY_MAI- 1 backup db type=full devclass=fileclass wait=yes
NT
6 delete volhistory todate=today-3 type=dbb
11 delete volhistory todate=today-30 type=stgnew
16 delete volhistory todate=today-30 type=stgreuse
21 delete volhistory todate=today-30 type=stgdelete
26 backup volhistory
31 backup devconfig

To start a database backup to disk manually, perform the following steps:
1. Log in to the Information Archive Management Console and enter the command dsmadmc
-server=<collection_name> to open a System Storage Archive Manager administrative
command line session.
2. Log in to the System Storage Archive Manager server with a userid and password that has
the TSM Administrator role.
3. Enter the command backup db type=full devclass=fileclass wait=yes. The backup file
will be stored under /tiam/<collection_name>/tsm/fileclass/*.dbv.
4. Issue the command backup volhist to save the history of used volumes into a file.
5. Enter the command backup devconfig to save the device configuration of the System
Storage Archive Manager server into a file.

Tip: Always use the System Storage Archive Manager database backup to disk as well
when you do the backup to tapes.

Backing up database to tape
To schedule a regular System Storage Archive Manager database backup to tape, we extend
the script daily_backup_to_tape that we started to create in “Backing up storage pools to
tape” on page 442.

Perform the following steps to schedule a System Storage Archive Manager database
backup:
1. Make sure that you have tapes in SCRATCH status available in the library. Enter the IBM
Tivoli Storage Manager command query libvol to display the available tapes. Use RW
tapes for database backups.
2. Enter the command backup db devc=<tape_device_class_of_RW_tapes>
type=dbsnapshot to create a backup of the System Storage Archive Manager database.
Run this database backup to tape after the backup of the disk storage pool to tape.
In Example 11-5, “Update script daily_backup_to_tape”, we demonstrate how to extend an
already existing script with the backup db command.

444 IBM Information Archive: Architecture and

Ibm information archive architecture and deployment sg247843

More Related Content

What's hot (18)

Viewers also liked (20)

Similar to Ibm information archive architecture and deployment sg247843 (20)

More from Banking at Ho Chi Minh city (20)

Recently uploaded (20)

Ibm information archive architecture and deployment sg247843