Deployment recommendations for Tivoli Storage Manager Version 6 servers
How do I successfully deploy a Tivoli Storage Manager Version 6 server?
Tivoli Storage Manager V6 servers delivered many significant changes to the architecture of the product. The most notable change is the replacement of the proprietary embedded database with the IBM DB2 database. Because of the scope and magnitude of these changes, there are new and changed considerations for deploying a Tivoli Storage Manager server compared to what was needed for previous releases.
The following topics discuss aspects of planning for, and successfully deploying, a Tivoli Storage Manager V6.2 or V6.3 server.
Tip: This document does not provide detailed information about V6.1, whose end of support date was April 30, 2014. A support extension is available until April 30, 2017. No extension is available for the Administration Center or for the reporting and monitoring feature. Transport Layer Security is not supported for extensions. For information about the V6.1 release, see the PDF files, which are available at IBM developerWorks.
This document will be updated periodically. Refer back to this document for the latest recommendations. The date published is displayed with this document and is updated when it is republished.
Critical changes in database protection and recovery
Tools for managing Tivoli Storage Manager servers
Recovery log sizing to support the workload
Upgrading from V5 to V6
Data deduplication effects on operations and resources
Renaming a server
Operating system and hardware problems and workarounds
Tips for V7.1 users:
- Beginning with Version 7.1.3, IBM Tivoli Storage Manager is now IBM Spectrum Protect. Some applications such as the software fulfillment systems and IBM License Metric Tool use the new product name. However, the software and its product documentation continue to use the Tivoli Storage Manager product name. To learn more about the rebranding transition, see http://www.ibm.com/support/docview.wss?uid=swg21963634.
- A deployment technote is not available for the V7.1 release. For information about this release, including the latest deployment information and best practices, see the V7.1 documentation.
The following are specific differences with Tivoli Storage Manager V6.2 and V6.3 that represent differences in capability or administration that must be considered.
- Database mirroring is not available or possible with Tivoli Storage Manager Version 6. Mirroring can be done using operating system or file system capabilities. Alternatively, consider device redundancy such as RAID capabilities in the storage that is used for the server database.
- The server volume history file is required to restore the database. The volume history in Tivoli Storage Manager Version 6 contains information that is used during the restore operation that cannot be recreated manually if the file is missing. Use the VOLUMEHISTORY server option to automatically create at least one, and preferably multiple copies of the volume history file. Protect these files and store redundant copies in multiple places.
- For recommendations about diagnosing problems, collecting trace and log files, and other guidance for problem resolution, see the problem determination information for your product release:
- V6.4 Problem determination
- V6.3 Problem determination
- V6.2 Problem determination
For system requirements, see the documentation for your server release:
- V6.3 Planning to install the Tivoli Storage Manager server
- V6.2 Planning to install IBM Tivoli Storage Manager
Ensure that your system meets the memory requirements. For minimum memory requirements, see the System requirements for AIX systems topic. The memory requirements listed in this topic apply to V6.2 and V6.3 servers on all operating systems.
In addition, consider the following guidelines:
- The recommendations are to be considered a starting point. As workload is increased for a given Tivoli Storage Manager server, the memory usage, performance, page file (system paging space), and other items must be monitored. If performance decreases or other operational issues arise, this may be the result of too much workload relative to the available resources assigned to Tivoli Storage Manager. In this case, one step to resolve or mitigate the issue is to add more memory or make more memory available to the Tivoli Storage Manager server. We typically see customers using 64 GB, 128 GB, or more of memory for large deduplication, replication, or deduplication and replication workloads.
- Tivoli Storage Manager servers are optimized for and perform best on computers that are running with 64-bit architectures. Versions prior to V6.3 supported running on 32-bit Windows. In that case, Tivoli Storage Manager running on a 32-bit architecture will be limited by the memory available to it and it is not recommended to use those servers for heavy workload environments, data deduplication, or other such capabilities.
- If you are using data deduplication, see the following resources:
- Data deduplication checklist
- Determining the impact of deduplication on a Tivoli Storage Manager server database and storage pools
- Effective Planning and Use of IBM Tivoli Storage Manager V6 Deduplication
- If you are using node replication, see the following resources:
For instructions about installing the Tivoli Storage Manager server, see the documentation for your product release:
- V6.3 Installing the server on AIX, HP-UX, Linux, Oracle Solaris, and Windows systems
- V6.2 Installing the server on AIX, HP-UX, Linux, Sun Solaris, and Windows systems
For information about upgrading or migrating a Tivoli Storage Manager V5 server, see
Upgrading from V5 to V6.
Back to top
Starting with the Tivoli Storage Manager V6.3.4 server, you can use the Operations Center, a web-based interface, to manage your storage environment. The Operations Center includes an Overview page that shows the interaction of Tivoli Storage Manager servers and clients. You can use the Operations Center to identify potential issues at a glance, manage alerts, and access the Tivoli Storage Manager command line.
For more information about the Operations Center, see Managing servers with the Operations Center.
To determine the system requirements for running the Operations Center in your environment, see IBM Tivoli Storage Manager Operations Center System Requirements Calculator.
The Operations Center is the preferred monitoring interface. Alternatively, if you have Tivoli Storage Manager V6.2 or V6.3 installed, you can use the Administration Center to manage your environment. For more information about the Administration Center, see Managing servers with the Administration Center.
Tivoli Storage Manager servers are limited by operational concerns similar to those that were encountered for V5. Although the database and recovery log sizes can be much larger in V6 than was possible in V5, the operational limits still dictate how large a server may be, or the total workload that it can support. The operational limits of a server vary based on workload, server deployment (system, CPU, memory, I/O bandwidth), and risk tolerance of an organization (recovery objectives for the Tivoli Storage Manager server itself).
For limitations that apply to V6.3 servers, and for guidelines about managing resources, see the following topics:
- Limits for the server database size and peak client sessions
- Potential bottlenecks in the data flow for Tivoli Storage Manager operations
- Workloads for the server
For limitations that apply to V6.2 servers, and for guidelines about managing resources, see the following topics:
Back to top
Tivoli Storage Manager uses a database to record information about server policies, registered nodes, data stored on the server and other attributes that must be tracked. To preserve the integrity and consistency of the records in the database, Tivoli Storage Manager has always used a transaction log. In earlier versions of the product, a single log (comprising one or more physical volumes) was used for this purpose. The maximum log size available for earlier versions of the product was approximately 13 GB. Starting with Tivoli Storage Manager V6.1, the log is composed of an active log, limited to a maximum size of 128 GB, and an archive log that is limited in size only by the size of the file system where it resides. When you estimate space requirements for active and archive logs, include extra space for contingencies such as occasional heavy workloads and failovers.
For guidelines pertaining to active logs and archive logs for V6.3 servers, see the following topics:
- Recovery log sizing
- Recovery log space requirements
- Checklist for server recovery log disks
- Checklist for data deduplication
- Checklist for node replication
For guidelines pertaining to active logs and archive logs for V6.2 servers, see the following topics:
- Estimating recovery log space requirements
- Disk space requirements for the server database and recovery log
Back to top
The database for a V6.2 or V6.3 server is managed automatically by the server's database manager. The database is used to store and track information about server policies, and to store data describing client files and other attributes that are important for the server. The database is also used as temporary storage space for intermediate results for queries or other processing that the server performs.
For more information about databases for V6.3 servers, see the following topics:
- Managing the database and recovery log
- Database configuration and tuning
- The database manager and temporary space
For more information about databases for V6.2 servers, see the following topic:
Back to top
Full backups (TYPE=FULL) of the server database must be completed more frequently compared to V5. The primary reason is that pruning of the archive log space in the archive log directory occurs only as a result of a BACKUP DB TYPE=FULL operation. Full database backups are done automatically if the available active and archive log space gets low. However, to help prevent space problems, schedule regular TYPE=FULL database backups with some frequency.
For more information about operational changes when you upgrade the server from V5 to V6, see Preparing for operational changes.
Also evaluate how you manage volume history. The volume history occupies space in the server database, plus space for one or more files as configured by the VOLUMEHISTORY server option. Prune the volume history periodically by using the DELETE VOLHISTORY command. For instructions, see Deleting information about volume history.
Back to top
If you are upgrading a server from an earlier version of Tivoli Storage Manager to V6.2 or V6.3, review the documented procedures and recommendations in the information center. Consider the following key items:
- Plan for database space that is 1.3 to 1.5 times the size of the current database. This size is needed to allow for some intermediate or temporary space that is used to perform the database updates needed during this processing.
The space required for a V6.2 database is discussed in the following section:
The space required for a V6.3 database is discussed in the following section:
- After the database records are loaded into the V6 server during upgrade processing, the server must perform the final transformations to prepare the database for use. This operation must be allowed to run to completion. Monitor the CPU and I/O usage for the server process and the corresponding DB2 process.
- For complete documentation and recommendations about upgrading to a V6 server, review the following documentation:
- Migrating Tivoli Storage Manager V5 servers on AIX, HP-UX, or Solaris systems to V6.3.4 on Linux
- Migrating Tivoli Storage Manager V5 servers on z/OS systems to V6 on AIX or Linux on System z
In addition to the procedures that are described in the documentation, additional methods are available to upgrade or migrate a Tivoli Storage Manager server from V5 to V6. The following alternative methods are designed to reduce the downtime that is associated with upgrade and migration processes:
- Database backup and restore operations can be used to migrate the database. For instructions, see Migrating Tivoli Storage Manager Servers from One Operating System to Another.
- Migration Engine from Butterfly Software can be used to plan and complete the upgrade or migration process. The Butterfly software is available as part of a service offering. For more information, see Migration Engine from Butterfly Software.
- Expert users can take advantage of the hybrid upgrade-migration method. The hybrid upgrade-migration method combines database migration with export and import operations. For more information, see Tivoli Storage Manager Version 6 Hybrid Upgrade Migration Method.
Back to top
Tivoli Storage Manager V6.1 introduced data deduplication for storage pools. To successfully use data deduplication for V6.2 or V6.3, see the Deduplication page in the Tivoli Storage Manager wiki. This page provides a consolidated view of information related to data deduplication.
Tivoli Storage Manager V6.3 introduced server-to-server replication. This provides the ability to replicate the database entries and corresponding data for client nodes that are assigned to the server. Replication can be done for the entire server or other levels of granularity such as by client, by file space, or by data type (backup, archive, etc,). For more information, see Replicating client node data.
In addition to the information published in the V6.3 information center, consider the following best practice recommendations: http://www.ibm.com/support/docview.wss?uid=swg21595727.
The following performance information can help you to successfully implement and deploy a Tivoli Storage Manager V6 server.
- For V6.2, the performance considerations are available at: http://www.ibm.com/support/knowledgecenter/SSGSG7_6.2.0/com.ibm.itsm.perf.doc/c_srv_tuning.html
- For V6.3, the performance considerations are available at:
The following links provide additional guidance related to performance improvement:
- Daily operations for a Tivoli Storage Manager server: avoiding resource contention: http://www.ibm.com/support/docview.wss?uid=swg21419733
- Tuning the schedule for daily operations: http://www.ibm.com/support/knowledgecenter/SSGSG7_6.3.4/com.ibm.itsm.perf.doc/t_srv_tuning_daily.html
- V6 server database size, database reorganization, and performance considerations: http://www.ibm.com/support/docview.wss?uid=swg21452146
Back to top
Renaming a server
A Tivoli Storage Manager server is referenced in an environment by two attributes: the TCP/IP host name for the system where the server is running, and the server name that is defined by the SET SERVERNAME command. Changing either or both of these values has the following implications:
- If the TCP/IP host name is changed, it affects the DB2 database that is used by the V6 server. When the server is installed, attributes for its database are set that are dependent on the host name. If the host name is changed, the database must be updated to match this corresponding value. For more information, see Changing names in Tivoli Storage Manager.
- Changing the Tivoli Storage Manager server name by using the SET SERVERNAME command affects clients and other operations. When you change the server name, the following warning is displayed:
Changing the server name could adversely affect: communication from the server to backup archive nodes, event logging, virtual
volumes, library sharing, and storage agents used for LAN-free and
server-to-server operations such as enterprise configuration. See the administrator's guide for more information on these areas and the impact of changing the server name.
For example, changing the server name affects Windows clients that are using generated passwords. See Setting the server name.
Back to top
Operating system and hardware problems and workarounds
- Heavy load on AIX: For AIX systems, an operating-system defined limit affects the resources that are available for Tivoli Storage Manager V6.1 or V6.2 to communicate with DB2.
This issue does not affect users of Tivoli Storage Manager V6.3 or later.
Back to top
More support for:
Tivoli Storage Manager
Software version: 6.1, 6.2, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.3, 6.3.2, 6.3.3, 6.3.4, 6.4, 6.4.1
Operating system(s): AIX, HP-UX, Linux, Solaris, Windows
Software edition: All Editions
Reference #: 1421060
Modified date: 2016-06-03