Deployment recommendations for Tivoli Storage Manager V6 servers

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

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 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
Tools for managing Tivoli Storage Manager servers
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

Tivoli Storage Manager V7.1 users: A deployment technote is not available for this release. For information about this release, including the latest deployment information and best practices, see the Tivoli Storage Manager V7.1 Information Center.

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

    -
    V6.1 Problem determination

Back to top

System requirements

For system requirements, see the documentation for your server release:

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.1, 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 such need to 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 or 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 machines 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:
  • If you are using node replication, see the following resources:



Back to top

Installation

For instructions about installing the Tivoli Storage Manager server, see the documentation for your product release:


For information about upgrading or migrating a Tivoli Storage Manager V5 server, see
Upgrading from V5 to V6.

Back to top

Tools for managing Tivoli Storage Manager servers

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




Back to top

Limitations

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


For limitations that apply to V6.2 servers, and for guidelines about managing resources, see the following topics:
For limitations that apply to V6.1 servers, and for guidelines about managing resources, see the following topics:


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. When you estimate space requirements for active and archive logs, include some 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:


For guidelines pertaining to active logs and archive logs for V6.2 servers, see the following topics:
For guidelines pertaining to active logs and archive logs for V6.1 servers, see the following topics:


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

For more information about databases for V6.2 servers, see the following topic:


For more information about databases for V6.1 servers, see the following topic:

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.

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

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:

For instructions about migrating a Tivoli Storage Manager V5 server to V6 on a different operating system, see:
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:


Back to top

Deduplication effects on operations and resources

Tivoli Storage Manager V6.1 introduced data deduplication for storage pools. To successfully use data deduplication for V6.1, 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.


Back to top

Replication considerations

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 filespace, 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, 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 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.
  2. 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. For details, see:
    http://www.ibm.com/support/docview.wss?uid=swg21428557

    This issue does not affect users of Tivoli Storage Manager V6.3 or later.


Back to top

Rate this page:

(0 users)Average rating

Document information


More support for:

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:

2013-12-13

Translate my page

Machine Translation

Content navigation