Tivoli Storage Manager for Windows Administrator's Guide


Clustering for Server Availability

A cluster is a group of independent computers working together. When you use cluster configurations, you enhance the availability of your servers. In the case of a Microsoft Cluster Server (MSCS), you can join two Windows servers, or nodes, via a shared disk subsystem so that the nodes share data to provide high server availability. The combination of these two servers is a cluster.

TSM uses MSCS failover to offer two configurations: active/passive and active/active. These configurations are configurations of the TSM server, not the cluster. For the active/passive configuration, you create one instance of a TSM server that can run on either node. The other node serves as a online (hot) backup. For the active/active configuration, the cluster runs two independent instances of a TSM server. Although the instances typically run on separate nodes, one node can run both instances. Even if both instances are running on the same physical server, users believe they are accessing separate servers.

In active/passive configurations, the server has one database, recovery log, and one set of storage pool volumes. In active/active configurations, each virtual server has a separate database, recovery log, and a separate set of storage pool volumes because virtual servers can not share data.

MSCS requires each TSM server instance to have a private set of disk resources. Although nodes can share disk resources, only one node can actively control a disk at a time.

Comparing Active/Active and Active/Passive Configurations

Is one configuration better than the other? To determine your best installation, you need to look at the differences in performance and cost. Assume you have a TSM server-dedicated cluster whose nodes have comparable power. During failover, the performance of an active/active configuration degrades because one server must manage both virtual TSM server instances. If each node handles 100 clients in a normal operation, one node must handle 200 clients during a failure. The active/passive configuration provides better performance than the active/active configuration during failure because the cluster is running on one TSM server instance.

However, during normal operations, the active/active configuration uses server resources more efficiently than the active/passive configuration because you are using both nodes. Clusters are expensive to build if you use the second node only for failovers as in the active/passive configuration.

MSCS Virtual Servers

Using TSM you can run an instance of a TSM server on each node. For example, assume a clustered TSM server called TSMSERVER1 is running on node A and a clustered TSM server called TSMSERVER2 is running on node B. Clients connect to the TSM server TSMSERVER1 and the TSM server TSMSERVER2 without knowing which node currently hosts their server. The MSCS concept of a virtual server ensures that the server's location is transparent to client applications. To the client, it appears that the TSM server is running on a virtual server called TSMSERVER1.

Figure 83. Clustering With TSMSERVER1 as Node A and TSMSERVER2 as Node B

Clustering with TSMSERVER1 as Node A and TSMSERVER2 as Node B


A virtual server looks very much like a Windows Server. A TSM server can be one of the virtual services provided by a virtual server.

Clients connect to a TSM virtual server using the virtual server name, rather than the Windows server name.

Failover occurs when one of the software or hardware resources fail. Resources (for example: applications, disks, or an IP address) migrate from the failed node to the remaining node. The remaining node takes over the TSM server resource group, restarts the TSM service, and provides access to administrators and clients.

If node A fails, node B assumes the role of running TSMSERVER1. To a client, it is exactly as if node A were turned off and immediately turned back on again. Clients experience the loss of all connections to TSMSERVER1 and all active transactions are rolled back to the client. Clients must reconnect to TSMSERVER1 after this occurs. The location of TSMSERVER1 is transparent to the client.

Figure 84. Clustering With TSMSERVER2 as Node B and assuming the role of TSMSERVER1 as Node A

Clustering with TSMSERVER2 as Node B and assuming the role of TSMSERVER1 as Node A


Managing the TSM Server on a Cluster

For most tasks, you can administer a virtual TSM server as you would a non-clustered server. However, you must use the Cluster Administrator to perform some important tasks. The Cluster Administrator is available through the Administrative Tools program group. The Cluster Administrator main window displays a detailed view of a virtual server configuration, including the physical Windows servers that make up the cluster and their resources, network connections, and status.

Use the Cluster Administrator to view the components of a virtual server configuration and to start, stop, or fail back a virtual server that has failed over. If you use the TSM utilities or some other method to stop a virtual TSM server, Clustering Service treats the shutdown as a failure and restarts the server on the cluster's secondary node. A virtual TSM server should be controlled from the Cluster Administrator rather than the Windows Service Control Manager.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]