Tivoli Storage Manager V6.x Best Practices Deployment Guide

View Only

Tivoli Storage Manager V6.x Best Practices Deployment Guide

By Archive User posted Thu October 27, 2011 07:02 PM

Like

Originally posted by: csd_tuc

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.

You can find the latest version of the Deployment Guide at this link: http://www-01.ibm.com/support/docview.wss?uid=swg21421060

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.

Question

How do I successfully deploy a Tivoli Storage Manager V6.1, V6.2, or V6.3 server?

Cause

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.

Answer

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.

Critical changes in database protection and recovery
System requirements
Installation
Limitations
Recovery log - sizing to support the workload
Database
Database Operations
Upgrading from V5 to V6
Deduplication effects on operations and resources
Performance
Renaming a server
Operating system and hardware problems and workarounds

Critical changes in database protection and recovery
The following are specific differences with Tivoli Storage Manager V6.1 and V6.2 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 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 now 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.
Refer to the Problem Determination section of either the V6.1 or V6.2 information center for recommendations on diagnosing problems, trace and log files to collect, and other guidance on resolving problems. The following is a link to the Problem Determination section of the V6.2 information center: http://publib.boulder.ibm.com/infocenter/tsminfo/v6r2/topic/com.ibm.itsm.nav.doc/t_probdeterm.html

Back to top

System requirements

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:

It does not use storage pool deduplication.
It supports only a small number of clients, or the nightly backup data transferred is 100 GB or less.
It is used only as a library manager.
On a machine with only 4 GB of RAM, only a single server is being run.

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:

64-bit (Windows, AIX, Linux, HP-UX, Solaris): 12 GB, or 16 GB if using deduplication.
32-bit Windows: 8 GB

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:
http://www-01.ibm.com/support/docview.wss?uid=swg21454067

Note that the memory and system requirements for V6.2 specify higher recommended values than were specified for V6.1.

Back to top

Installation

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:
http://www.ibm.com/support/docview.wss?uid=swg21455299

For additional considerations about upgrading an existing Tivoli Storage Manager V5.x server, see
Upgrading from V5 to V6.

Back to top

Limitations

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 operational limits to consider are:

Ability to support the client workload. Supporting the client workload represents the amount of data that needs to be backed up or archived over a given period of time, typically the nightly backup window. The ingest of data to the server may be limited by storage capacity, I/O bandwidth to the storage devices, network bandwidth, or other system attributes such as available memory or CPU for the server. Also, the client workload can have competing characteristics such as total data to ingest or total concurrent number of clients that need to be supported at a given time.
Time required to perform server maintenance processes such as expiration, migration, reclamation, storage pool backup, and database backup.

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.

The Tivoli Storage Manager development team continues to evaluate the limits of the product. Some key limitations to consider are:

Database Size (total utilization):

* V6.1 is tested to 1 TB.
* V6.2 is tested to 2 TB.

There is not a hard-limit that will prevent the database from exceeding these tested limits. The primary considerations are the performance of the server itself and the time to perform a database backup (or restore). If performance degrades as the database size grows, or the time required to perform a database backup exceeds the time available during server maintenance windows, consider deploying another server and assigning new workload or balancing existing workload to that server.
Concurrent client sessions to the server (Peak Sessions):

The Tivoli Storage Manager server is tested to 500 concurrent client sessions. As this value is exceeded, based on memory or other system limitations, the server performance may degrade or operations may become unresponsive. The actual number of concurrent sessions where this is encountered will vary depending upon the actual resources available to the server. Again, this is a consideration for when deployment of another server might need to be considered. Or else adjustment of the client workload scheduling may be needed in order to avoid a high peak session workload. Consider setting the MAXSESSIONS server option to 500 to prevent a peak session workload greater than this.

Back to top

Recovery log - sizing to support the workload

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.

The following table shows the recommended minimum sizes for the active log and archive log directories.

Storage pool deduplication enabled?	Active log directory Minimum recommended size	Archive log directory Minimum recommended size
No	16 GB	48 GB
Yes	32 GB	96 GB

To determine if larger active log and archive log sizes should be considered, review the following document: http://www.ibm.com/support/docview.wss?uid=swg21389352.

For recommendations on the layout and placement of the active log and archive log files, review this document: http://www.ibm.com/support/docview.wss?uid=swg21394339.

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.

Back to top

Database

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.

The primary considerations for database space related to the use of temporary space are:

If the database is low on space, add more space because operations that require temporary space might use the remaining free space.
If server operations such as expiration might process file spaces that are either very large or that have assigned policies that cause large numbers of file versions, add more database space to allow for the temporary table space that might be needed.
If the server must run with limited memory, add more space for the database because the sort "spill" behaviors are more likely to occur.
If after deploying the V6 server, errors about "out of database space" are reported, add more space for the database. These errors can be symptoms of temporary space in the database being completely consumed. Monitor the server activity log for messages about "out of database space" for this symptom.

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

Database Operations
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.

If you are upgrading from V5 and have existing administrative schedules that manage the backup of the server database, evaluate these schedules:

Consider increasing how often the server database is backed up.
Consider increasing how often the backup that is performed is TYPE=FULL (instead of TYPE=INCREMENTAL), to ensure that archive log space is pruned.

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://www.ibm.com/support/docview.wss?uid=swg1IC72761.

Back to top

Upgrading from V5 to V6

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:

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 following section discusses the space needed for the V6.1 database: http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/c_srv_upgrd_dbspace.html

The space required for a V6.2 database is discussed in the following section:
http://publib.boulder.ibm.com/infocenter/tsminfo/v6r2/topic/com.ibm.itsm.srv.upgrd.doc/c_srv_upgrd_dbspace.html
After the database records are inserted 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 on upgrading to a V6 server, review the following section in the information center:
- For V6.1: http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd.html
- For V6.2: http://publib.boulder.ibm.com/infocenter/tsminfo/v6r2/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd.html

Note that it is possible and supported to upgrade from V5.x directly to V6.2.

Back to top

Deduplication effects on operations and resources

Tivoli Storage Manager V6.1 introduces deduplication for storage pools. To successfully use storage pool deduplication for V6.1 or V6.2, consider the following operational aspects:

The duplicate identification (IDENTIFY) processes for the server make intensive use of the database and system resources. Because these processes place additional load on the CPU and memory of the system, schedule IDENTIFY processes to run when the additional load will not impact client operations or conflict with other server processes such as expiration.

As a best practice, schedule the IDENTIFY process to run outside the client backup window and during a time period when it will not conflict with other server processes such as reclamation, migration, and storage pool backup.

Consider using the Tivoli Storage Manager Administration Center. The Administration Center provides a wizard that guides you through configuring and scheduling an appropriate maintenance script that will run server processes in a recommended order.
The effect of deduplication on system resources (CPU and memory) and the server active log is also related to the size of the file to be deduplicated. As the size of the file increases, more processing time, CPU, memory, and active log space are needed.

Review the following document about server storage pool deduplication. In particular, consider the circumventions listed to avoid issues with this processing. http://www.ibm.com/support/docview.wss?uid=swg21408187

Back to top

Performance

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.

For V6.1, the performance considerations are available at: http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.nav.doc/c_performance.html
For V6.2, the performance considerations are available at: http://publib.boulder.ibm.com/infocenter/tsminfo/v6r2/topic/com.ibm.itsm.nav.doc/c_performance.html

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
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: