Normas y procedimientos aduaneros

After the resource group has been created and configured, install Caché in the cluster. The procedure is outlined below. There are different procedures, depending on whether you are installing only one instance of Caché or multiple instances of Caché, as described in the following subsections:

• Installing a Single Instance of Caché in the Cluster

• Installing Multiple Instances of Caché in the Cluster

• Application Controllers and Monitors

• Application Considerations

B.3.1 Installing a Single Instance of Caché in the Cluster

Installing a single instance of Caché is most common in production environments; it is not common in test or development clusters.

Note: If you think you might install additional instances of Caché to run in the cluster at some point in the future, follow the procedure described in Installing Multiple Instances of Caché in the Cluster.

To install a single instance of Caché and your application:

1. Bring the Caché resource group (cacheprod_rg) online on one node. This mounts all required disks, allowing for the proper installation of Caché:

A good choice is to use a ./usr/local/etc/cachesys/ subdirectory under your install directory. For example, assuming Caché is installed in the /cacheprod/cachesys/ subdirectory, specify the following on all nodes in the cluster:

mkdir –p /cacheprod/cachesys/usr/local/etc/cachesys mkdir –p /usr/local/etc/

ln –s /cacheprod/cachesys/usr/local/etc/cachesys/ /usr/local/etc/cachesys

3. Run Caché cinstall on the node with the mounted disks.

Important: Be sure the users and groups (either default or custom) have already been created on all nodes in the cluster, and that they all have the same UID and GIDs.

4. Stop Caché and move the resource group to the other nodes.

5. On the other node in the cluster, create the link in /usr/local/etc and the links in /usr/bin for ccontrol and csession:

mkdir -p /usr/local/etc/

ln –s /cacheprod/cachesys/usr/local/etc/cachesys/ /usr/local/etc/cachesys ln –s /usr/local/etc/cachesys/ccontrol /usr/bin/ccontrol

ln –s /usr/local/etc/cachesys/csession /usr/bin/csession

6. Test connectivity via the virtual IP address.

Important: Be sure the application, all interfaces, any ECP clients, etc. use the virtual IP address as configured here to connect to the Caché resource.

7. Place the cache.sh file in /etc/cluster/<app>/, where <app> is the application controller name (for more information, see Application Controllers and Monitors in this appendix). Ensure the permissions, owner and group allow this script to be executable.

8. Test that the cache.sh script stops and starts the newly installed Caché instance. Assuming the application controller is named cacheprod:

• To test a start of the cache instance of Caché run: /etc/cluster/cacheprod/cache.sh start cacheprod

• To test a stop of the cache instance of Caché run: /etc/cluster/cacheprod/cache.sh stop cacheprod

9. Offline the resource group to prepare to add the control scripts and monitors to your resource group; for more information, see Application Controllers and Monitors in this appendix.

B.3.2 Installing Multiple Instances of Caché in the Cluster

Installing multiple instance of Caché is most common in test and development clusters; it is not common in production environments. To install multiple instances of Caché and your application:

1. Bring the Caché resource group online on one node. This mounts all required disks and allows for the proper installation of Caché:

a. Check the file and directory ownerships and permissions on all mount points and subdirectories.

b. Prepare to install Caché by reviewing the “Installing Caché on UNIX® and Linux” chapter of the Caché Instal-

lation Guide.

2. Run Caché cinstall on the node with the mounted disks,

Important: Be sure the users and groups (either default or custom) have already been created on all nodes in the cluster, and that they all have the same UID and GIDs.

88       Caché High Availability Guide Using IBM PowerHA SystemMirror with Caché

3. The /usr/local/etc/cachesys directory and all its files must be available to all nodes at all times. Therefore, after Caché is installed on the first node, copy /usr/local/etc/cachesys to each node in the cluster, as follows:

cd /usr/local/etc/

scp –p cachesys node2:/usr/local/etc/

4. Verify that ownerships and permissions on this cachesys directory and its files are identical on all nodes.

Note: Keep the Caché registries on all nodes in sync using ccontrol create and/or ccontrol update after Caché upgrades; for example:

ccontrol create CSHAD directory=/myshadow/ versionid=2011.1.475

5. Stop Caché and move the resource group to the other nodes.

6. On the other nodes in the cluster, create links in /usr/bin for ccontrol and csession:

ln –s /usr/local/etc/cachesys/ccontrol /usr/bin/ccontrol ln –s /usr/local/etc/cachesys/csession /usr/bin/csession

7. Test connectivity via the virtual IP address. Be sure the application, all interfaces, any ECP clients, etc. use the virtual IP address as configured here to connect to the Caché resource.

8. Place the cache.sh file in /etc/cluster/<app>/, where <app> is the application controller name (for more information, see Application Controllers and Monitors in this appendix). Ensure the permissions, owner and group allow this script to be executable.

9. Test that the cache.sh script stops and starts the newly installed Caché instance. Assuming the application controller is named cacheprod:

• To test a start of the cache instance of Caché run: /etc/cluster/cacheprod/cache.sh start cacheprod

• To test a stop of the cache instance of Caché run: /etc/cluster/cacheprod/cache.sh stop cacheprod

10. Offline the resource group to prepare to add the control scripts and monitors to your resource group; for more information, see Application Controllers and Monitors in this appendix.

B.3.3 Application Controllers and Monitors

Once Caché is installed, configure the application controller resource. For example, assuming the resource group that contains all the disk and IP resources is called cacheprod_rg and the chosen Application Controller Name is cacheprod, you would configure the following in the application controller:

• Application Controller Name: cacheprod

• Start script: /etc/cluster/cacheprod/cache.sh start cacheprod

• Stop script: /etc/cluster/cacheprod/cache.sh stop cacheprod

• Resource Group Name: cacheprod_rg

You can also configure the optional custom application monitors:

Long-running Monitor

Configure the long-running monitor with the following values:

• Application Controller Name: cacheprod

• Monitor Mode: Long-running monitoring

• Monitor Method: /etc/cluster/cacheprod/cache.sh monitor cacheprod

• Monitor Interval: 21

• Stabilization Interval: 60

• Restart Count: 1

• Restart Interval: default

• Action on Application Failure: failover

• Notify Method: (site specific)

• Cleanup Method: default

• Restart Method: default

A long-running monitor uses the monitor function of the cache.sh script. This function, in turn, performs a ccontrol list to determine the status of the application:

• If the status is “ running ” or “ down ” , the monitor returns success.

• If the status is an error, PowerHA attempts to stop and then start the Application Controller.

• For any other status, the monitor hangs for 10 seconds and checks again. Then, if the application is still not running or is down, the monitor returns an error and forces PowerHA to go through an application restart cycle on this node. If that fails to successfully restart Caché, PowerHA fails the resource group to the other node.

Startup Monitor

Configure the startup monitor with the following values:

• Application Controller Name: cacheprod

• Monitor Mode: Startup monitoring

• Monitor Method: /etc/cluster/cacheprod/cache.sh startmonitor cacheprod

• Monitor Interval: 11

• Stabilization Interval: 21

• Restart Count: 1

• Restart Interval: default

• Action on Application Failure: notify

• Notify Method: (site specific)

• Cleanup Method: default

• Restart Method: default

The startup monitor uses the startmonitor function of the cache.sh script. This function, in turn, performs a ccontrol list to determine the status of the application:

• If the status is “ running, ” the Application Controller quits since the application is already running.

90       Caché High Availability Guide Using IBM PowerHA SystemMirror with Caché

• For any other status, the Application Controller exits with a failure, which causes the Application Controller to run the defined Start script to initiate the start of Caché.

B.3.4 Application Considerations

Consider the following for your applications:

• Ensure that all network ports required for interfaces, user connectivity, and monitoring are open on all nodes in the cluster.

• Connect all interfaces, web servers, ECP clients and users to the database using the virtual IP address over the public network.

• Ensure that the application daemons, Ensemble productions, etc. are set to auto-start so the application is fully available to users after unscheduled failovers.

• Consider carefully any code that is part of %ZSTART or otherwise occurs as part of the Caché startup. To minimize time-to-recovery do not place heavy cleanup or query code in the startup such that PowerHA times out before custom code completes.