Microsoft Failover Cluster environment overview

Edit online

With a Microsoft Failover Cluster Manager, you can place IBM Storage Protect server cluster resources into a cluster group. The IBM Storage Protect cluster group has a network name, an IP address, one or more physical disks, an IBM Db2 server, and an IBM Storage Protect server service.

The IBM Storage Protect instance network name is independent of the name of the physical node on which the IBM Storage Protect cluster group runs. Clients connect to an IBM Storage Protect server by using the instance network name, rather than the Windows node name. The instance network name maps to a primary or backup node. The mapping depends on which node owns the cluster group. Any client that uses Windows Internet Name Service (WINS) or directory services to locate servers can automatically track the IBM Storage Protect clustered server as it moves between nodes. You can automatically track the clustered server without modifying or reconfiguring the client.

Each IBM Storage Protect cluster group has its own disk as part of a cluster resource group. IBM Storage Protect cluster groups cannot share data between the cluster groups. Each IBM Storage Protect server that is configured in a cluster group has its database, active logs, recovery logs, and set of storage pool volumes on a separate disk. This disk is owned by the cluster group where the server is configured.

Remember: Microsoft Failover Cluster Manager supports an IP address only as a resource. Hence, any IBM Storage Protect server that runs on a cluster must limit its supported communication method to just TCP/IP. Any client that does not use TCP/IP as a communication method is not able to reach the IBM Storage Protect cluster group if it fails over to the other cluster node.

The following example demonstrates the way that a Microsoft Failover Cluster Manager for an IBM Storage Protect cluster server works.

Assume that a clustered IBM Storage Protect server that is named JUPITER is running on Node Z and a clustered IBM Storage Protect server that is named SATURN is running on Node X. Clients connect to the IBM Storage Protect server JUPITER and the IBM Storage Protect server SATURN without knowing which node hosts their server.

Figure 1. Clustering with JUPITER as Node Z and SATURN as Node X
Clustering with JUPITER as Node Z and SATURN as Node X
When a software or hardware resource fails, failover occurs. Resources such as applications, disks, and an IP address move from the failed node to the remaining node. The remaining node completes the following actions:
  • Takes over the IBM Storage Protect cluster group
  • Brings the disk resources, the network resources, and the Db2 resource online
  • Restarts the IBM Storage Protect service
  • Provides access to administrators and clients

If Node X fails, Node Z assumes the role of running SATURN. To a client, it is exactly as if Node X were turned off and immediately turned back on again. Clients experience the loss of all connections to SATURN and all active transactions are rolled back to the client. Clients must reconnect to SATURN after the connection is lost. The location of SATURN is not apparent to the client.