Application dependencies

Edit online

Historically, to achieve resource group and application sequencing, system administrators had to build the application recovery logic in their pre-event and post-event processing scripts. Every cluster would be configured with a pre-event script for all cluster events, and with a post-event script for all cluster events.

Such scripts could become all-encompassing case statements. For example, if you want to take an action for a specific event on a specific node, you need to edit that individual case, add the required code for pre-event and post-event scripts, and also ensure that the scripts are the same across all nodes.

To summarize, even though the logic of such scripts captures the desired behavior of the cluster, the scripts can be difficult to customize and even more difficult to maintain later on when the cluster configuration changes.

If you are using pre-event and post-event scripts or other methods, such as resource group processing ordering to establish dependencies between applications that are supported by your cluster, then these methods might no longer be needed or can be significantly simplified. Instead, you can specify dependencies between resource groups in a cluster.

Note: In many cases, applications depend on more than data and an IP address. For the success of any application under PowerHA® SystemMirror®, it is important to know what the application should not depend in order to function properly. This topic outlines many of the major dependency issues. Keep in mind that these dependencies might come from outside the PowerHA SystemMirror and application environment. They might be incompatible products or external resource conflicts. Look beyond the application itself for potential problems within the enterprise.

Locally attached devices

Locally attached devices can pose a clear dependency problem. In the event of a fallover, if these devices are not attached and accessible to the standby node, an application might fail to run properly. These might include a CD-ROM device, a tape device, or an optical juke box. Consider whether your application depends on any of these and if they can be shared between cluster nodes.

Hard coding

Hard coding an application to a particular device in a particular location creates a potential dependency issue. For example, the console is typically assigned as /dev/tty0. Although this assigned name is common, it is by no means guaranteed. If your application assumes the name /dev/tty0, ensure that all possible standby nodes have the same configuration.

Host name dependencies

Some applications are written to be dependent on the AIX® host name. They issue a command in order to validate licenses or name file systems. The host name is not an IP address label. The host name is specific to a node and is not failed over by PowerHA SystemMirror. The host name cannot be changed. Any application that changes the host name is not supported by PowerHA SystemMirror.

Software licensing

Another possible problem is software licensing. Software can be licensed to a particular CPU ID. If this is the case with your application, a fallover of the software will not successfully restart. You might be able to avoid this problem by having a copy of the software on all cluster nodes. Know whether your application uses software that is licensed to a particular CPU ID.