Tivoli Storage Manager V6.x Best Practices Deployment Guide
csd_tuc 0700000PTS Visits (16094)
Tivoli Storage Manager Version 6 first GA'd in 2009 with a new internal database, our highest levels of scalability and availability, and new data reduction features such as deduplication at the source and target. Along the way, we published "Deployment Recommendations for TSM v6 Server" to streamline customers' deployment planning and experience, greatly improving time to value for clients. The Deployment Guide is a living document with "real time" updates occurring whenever new insights are discovered in areas such as installation, configuration, or resource allocation. Client feedback suggests this document has greatly improved their deployment experience, resulting in quality metrics that have consistently meet or beat pre-v6 standards.
Be sure to refer back to the document link from time to time to see what is changed, new insights, and recommendations to make TSM V6 deployment a success.
Below, I've copied the the October 2011 version below for your reference.
How do I successfully deploy a Tivoli Storage Manager V6.1, V6.2, or V6.3 server?
The Tivoli Storage Manager version 6 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.1, V6.2, or V6.3 server. This document will be updated periodically. Refer back to this document from for the latest recommendations. The date published is displayed with this document and is updated when it is republished.
The published memory requirements for the Tivoli Storage Manager V6.1 server specify the minimum possible that can be used. For example, the RAM requirement is specified as 2 GB for testing and 4 GB for production. However, a system that has 4 GB of RAM is appropriate only for a small production server. A server is considered to be small if it has the following characteristics:
Memory requirements for larger production servers are expected to be more than the 4 GB minimum that is documented. The memory recommendations for a production server running Tivoli Storage Manager V6.1 depend on the architecture:
For production servers, 64-bit architecture is preferred and recommended. The 32-bit platform, which is supported for Windows only, has constrained memory and therefore might not be suitable for large production use.
The available system paging space may also need to be reviewed and set to a higher value to support one or more Tivoli Storage Manager V6 servers running on the system. Review the following for recommendations and guidance on setting the paging space appropriately:
Note that the memory and system requirements for V6.2 specify higher recommended values than were specified for V6.1.
The installation tools used for Tivoli Storage Manager V6.1 and V6.2 manage installation of the product along with any required upgrades of existing installed product resources. Review the following topic for guidance, recommendations, and known issues for installation:
The Tivoli Storage Manager servers are limited by operational concerns similar to those that were encountered for V5. While the database and recovery log sizes can be much larger in V6 than was possible in V5, the operational limits will still dictate how large a server may be or the total workload 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).
The key item to consider is that over a given period of time, usually 24 hours, many different tasks need to be accomplished. These tasks support the client workloads by storing data or retrieving it and returning it to the client when requested. These tasks keep the server environment healthy and take appropriate steps for disaster recovery of the server.
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, there was a single log (comprising one or more physical volumes) used for this purpose. The maximum log size available for earlier versions of the product was approximately 13 GB. With Tivoli Storage Manager V6.1 and later releases, the log is now 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.
For recommendations on the layout and placement of the active log and archive log files, review this document: http
For the active and archive log directories, it is better to have them too large as opposed to too small. The values shown in the preceding table are recommended minimum values for production. Using these values or higher values can prevent log space problems for a server.
The database for a V6.1 or V6.2 server is managed automatically by the server's database manager. The database is used to store and track information about server policies, stored data describing client files, and other attributes important to the server. It is also used as temporary storage space for intermediate results for queries or other processing that the server performs.
When the server database is initially configured (formatted), use multiple storage paths (multiple directories). As a general recommendation, start with 4 or more storage paths. The database manager for the Tivoli Storage Manager server has a better opportunity to exploit parallel I/O when using multiple storage paths.
To support database operations, the server's database manager manages and allocates many different system resources as it sees fit. Two primary resources that it uses are system memory and disk space for the database.
Important: The amount of database space that is needed can be influenced by the available memory on the system as well as the workloads that are being run. For example, the database manager orders the data in a specific sequence in response to the underlying SQL statement that was executed to request that data. If the database manager is unable to sort the result data using available memory, it "spills" into temporary database space by writing out portions of the sorted result to the database space allocated on disk.
Because of the relationship between result set size and available memory, the available space needed in the database can increase if these sort spills occur frequently. The database manager dynamically manages the memory used for these sort operations but ultimately a spill and use of temporary space in the server database might be unavoidable. The use of the temporary database space might then occur as a by-product of total workload on the server, or because the result for a single operation is so large that it cannot be contained and managed in memory.
One operation that can produce large result sets such that temporary database space is used is expiration. When expiration selects a given node and file space to process, it determines a candidate set of files to evaluate based on a SQL statement. If expiration is processing a node and file space that is very large, for example 10,000,000 objects, then it is unlikely that the database manager can contain that result in memory for the sort operation.
Attention: Do not alter the Db2 software that is installed with Tivoli Storage Manager installation packages and fix packs. Do not install or upgrade to a different version, release, or fix pack of Db2 software because doing so can damage the database.
Back to top
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, specifying deletion criteria based on how sequential media is used in your environment. In particular, consider the volumes used by database backups. With the increased frequency of TYPE=FULL database backups in V6, prune the volume history for volumes used by the database backup more frequently to manage the availability of scratch volumes for operations.
Attention: If the volume history file is not pruned periodically, server performance for operations that require sequential media can be adversely affected. For additional explanation of the importance of regular pruning of volume history, read the following documentation APAR: http
Back to top
If you are upgrading a server from an earlier version of Tivoli Storage Manager to V6.1 or V6.2, be sure to review the documented procedures and recommendations in the information center. Consider the following key items:Note that it is possible and supported to upgrade from V5.x directly to V6.2.
Back to top
Tivoli Storage Manager publishes a set of performance considerations and recommendations in the information centers. The tips and recommendations can help to successfully implement and deploy a Tivoli Storage Manager V6 server.
The following links provide additional guidance related to performance improvement:
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:
Back to top
Operating system and hardware problems and workarounds
Back to top