Skip to main content

Deployment recommendations for Tivoli Storage Manager V6 server


Technote (FAQ)


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
Replication considerations
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, 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 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, V6.2, or V6.3 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 minimum recommended memory for a V6.3 server is 12 GB for a general use server and 16 GB (minimum) if that server will use the Tivoli Storage Manager data deduplication capability. In addition to these minimum, starting points, for system memory, also consider the following:

  • For heavily used servers, consider at minimum 32 GB of RAM. Using 32 GB or more of memory enhances performance of the TIvoli Storage Manager server database inventory. In this context, "heavily used" may be many concurrent client sessions (100's), large file workloads (backup for files in the 100's of GB or TB range), backup of client systems with large workloads (backup for systems with millions of files), or other such high workload characteristics. In practice, the TSM development team has observed TSM server configurations where a heavily used server is configured with 64 GB or 128 GB or more of memory available to a single TSM server.
  • If you plan to run multiple instances on the same machine, each instance requires the memory listed for one server. Multiply the memory for one server by the number of instances planned for the system. Note that this consideration is true whether it is multiple TSM servers in an since "machine" instance or if it is mulitple TSM servers each running as it's own LPAR/WPAR on a given physical host. Any actions that result in more than a single TSM server on a given physical machine needs to consider the complete memory requirements of that single TSM server and the requirement and impact that will have on the resources available on the physical machine where the TSM server is being run.
  • The recommendations stated are to be considered a starting point. As workload is increased for a given TSM server, the memory usage, performance, page file (system paging space) and such need to be monitored. And in the event that performance decreases or other operational issues arise, this may be the result of too much workload relative to the available resources assigned to TSM. And in this case one step to resolve or mitigate the issue is to add more memory or make more memory available to the TSM server. As indicated earlier, we typically see customers using 64 GB or 128 GB or more of memory for large deduplication, replication, or deduplication and replication workloads.
  • TSM servers are optimized for and perform best on machines running with 64-bit architectures. Versions prior to V6.3 supported running on 32-bit windows. In that case, TSM 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 work-load environments, TSM deduplication, or other such capabilities.

The discussion above relates to V6.3 servers, this is also applicable to V6.1 or V6.2 servers as these values are provided based on observations of TSM implementations by customers and what has been observed to be the minimum amount of memory in order to provide a successful TSM server environment.

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. As a minimum, paging space should be 1.5-2 times the available memory on the system.



Back to top

Installation

The installation tools used for Tivoli Storage Manager V6.1, V6.2, and V6.3 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.
    * V6.3 is tested to 4 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, V6.2, and V6.3 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, V6.2, or V6.3, 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. It is also possible and support to upgrade from V5.x directly to V6.3.


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, V6.2, or V6.3 consider the following operational aspects:

  1. 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.

  2. 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.

  3. Deduplication has an affect on server database operations such that IBM recommends that TSM administrator's implement a database configuration change in order to address this operational impact. Refer to the following for the database configuration changes to implement: https://www.ibm.com/support/entdocview.wss?uid=swg1IC82886.


Refer to the "Best Practices" white paper for the current recommendations and guidance on using deduplication:

http://www.ibm.com/developerworks/wikis/display/tivolistoragemanager/Data+deduplication+best+practices+for+Tivoli+Storage+Manager+V6.2


Back to top

Replication Considerations

TSM V6.3 introduces server to server replication. This provides the ability to replicate the database entries and corresponding data for client nodes assigned to the server. Replication can be done for the entire server or other levels of granularity such as by client, by filespace, or by data type (backup, archive, etc). Please refer to the V6.3 information center for explanation and details about the TSM replication capability.

In addition to the information published in the V6.3 information center, also consider the following best practice recommendations: http://www.ibm.com/support/docview.wss?uid=swg21595727.


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.


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:


  1. If the TCP/IP host name is changed, it affects the DB2 database 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. Refer to the Tivoli Storage Manager Information Center for additional information on how to change the name for a TSM server. The following link is to the V6.3 information center topic which discusses renaming the server host name:

    http://publib.boulder.ibm.com/infocenter/tsminfo/v6r3/topic/com.ibm.itsm.srv.doc/t_srv_mng_srvnamechange.html
  2. Changing the Tivoli Storage Manager server name 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 the Administrator's Guide (Setting the server name) or the information for APAR IC35878 for additional details.

Back to top

Operating system and hardware problems and workarounds


Back to top

Rate this page:

(0 users)Average rating

Copyright and trademark information

IBM, the IBM logo and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.

Rate this page:


(0 users)Average rating

Add comments

Document information

Tivoli Storage Manager

Server

Software version:
6.1, 6.2, 6.3, 6.4

Operating system(s):
AIX, HP-UX, Linux, Solaris, Windows

Software edition:
All Editions

Reference #:
1421060

Modified date:
2011-12-02

Translate my page

Content navigation