• No results found

Single Failover Cluster

In document Caché High Availability Guide (Page 176-180)

The following shows a single failover cluster:

Single Failover Cluster

CLUNODE-1 and CLUNODE-2 are clustered together, and Caché is running on one node.

During normal operations, the following conditions are true:

Disk S is online on CLUNODE-1, and CLUNODE-2 has no database disks online.

• The instance CacheA runs on CLUNODE-1; CLUNODE-2 is idle.

In this setup, if CLUNODE-1 fails, your system looks like this:

Failover Cluster with Node Failure

Disk S is online on CLUNODE-2; CLUNODE-1 has no database disks online.

• The instance CacheA runs on CLUNODE-2; CLUNODE-1 is down.

See the Setting Up a Failover Cluster section for a detailed example.

9.1.1 Setting Up a Failover Cluster

This section gives an example of the steps necessary to set up a failover cluster on Windows Server 2003. The following sections describe the steps on each node:

• Tasks on CLUNODE-1

• Tasks on CLUNODE-2

• Tasks on Both Nodes

9.1.1.1 Tasks on CLUNODE-1

Perform the following steps on the first cluster node, CLUNODE-1:

1. Open the Cluster Administrator from the Windows Administrative Tools submenu.

Verify that all drives that contain Caché files and databases are shared drives and that they are all online on CLUNODE-1.

2. Create a Cluster Group called CacheA Group.

3. Create an IP Address Resource for CacheA Group called CacheA_IP.

You can also create a Network Name resource type if you want applications to connect to Caché by a DNS name as well as an IP address.

4. Create a Physical Disk Resource for the shared disk containing CacheA called Disk S:.

5. Install Caché on CLUNODE-1, naming the instance CacheA and installing it in a new folder, CacheA, on Disk S. The Caché install procedure on a cluster node automatically creates the resource needed to manage the Caché service.

6. Define the instance CacheA and map the database files for the instance on drives that are online on the same cluster as the Caché instance during normal operations. Do the same for all journal files.

7. If you are using the CSP Gateway (to access the System Management Portal, for example) from within this cluster, see the CSP Gateway Considerations section.

8. Move CacheA Group from CLUNODE-1 to CLUNODE-2 by right-clicking CacheA Group under the Groups branch and then clicking Move Group. You do not need to stop Caché; this is the way you fail over.

Dependencies

After you create the resources on CLUNODE-1, the following dependencies exist:

1. IP address, CacheA_IP, has no dependencies.

2. Physical disk resource, Disk S, depends on CacheA_IP.

CSP Gateway Considerations

Caché protects server passwords in the CSP Gateway configuration file (CSP.ini) using Windows DPAPI encryption. The encryption functions work with either the machine store or user store. The Web server hosting the CSP Gateway operates within a protected environment where there is no available user profile on which to base the encryption; therefore, it must use the machine store. Conse-quently, it is not possible to decrypt a CSP Gateway password that was encrypted on another computer.

This creates a situation for clustered environments where the CSP.ini file is on a shared drive and shared among multiple participating computers. Only the computer that actually performs the password encryption can decrypt it. It is not possible to move a CSP.ini file containing encrypted passwords to another computer; the password must be reentered and re-encrypted on the new machine.

Here are some possible approaches to this issue:

• Use a machine outside of the cluster as the Web server.

• Each time you fail over, reset the same password in the CSP Gateway.

• Configure each computer participating in the cluster so that it has its own copy of the CSP Gateway configuration file (CSP.ini) on a disk that does not belong to the cluster. Caché maintains the file in the directory hosting the CSP Gateway DLLs. Save and encrypt the password on each individual computer before introducing the node to the cluster.

For example, where Disk C from each machine does not belong to the cluster and Caché is installed on Disk S, you may have the following:

CLUNODE-1: C:\Inetpub\CSPGateway\CSP.ini with password XXX encrypted by CLUNODE-1 CLUNODE-2: C:\Inetpub\CSPGateway\CSP.ini with password XXX encrypted by CLUNODE-2

• Disable password encryption by manually adding the following directive to the CSP.ini file before starting the CSP Gateway and adding the passwords:

[SYSTEM]

DPAPI=Disabled

See the CSP Gateway Advanced Configuration Guide for more information.

9.1.1.2 Tasks on CLUNODE-2

Perform the following steps on the second cluster node, CLUNODE-2:

1. Install Caché on CLUNODE-2, naming the instance CacheA and installing it in the CacheA folder on Disk S. You are installing Caché on top of itself only to get the Caché entry into the registry.

2. Create a Caché Cluster Resource for CacheA Group called CacheA_controller.

3. Bring CacheA_controller online on CLUNODE-2 using the Cluster Administrator.

9.1.1.3 Tasks on Both Nodes

Verify the failover setup:

1. Move the CacheA Group cluster group from CLUNODE-2 back to CLUNODE-1.

2. When you again have CacheA Group running on CLUNODE-1, run ipconfig on both CLUNODE-1 and CLUNODE-2 to check that each is properly advertising the alias IP addresses.

You now have a failover cluster running Caché.

Important: Do not start and stop Caché from the Caché Cube. Instead, using the Cluster Admin-istrator, take the CacheA_controller offline to shut down Caché, and bring the CacheA_controller online to start Caché.

In document Caché High Availability Guide (Page 176-180)