In the process of planning a HACMP cluster, one of the most important steps is to chose the software levels that will be running on the cluster nodes.
The decision factors in node software planning are:
Operation system requirements: AIX version and recommended levels. Application compatibility: Ensure that all requirements for the applications are
met, and supported in cluster environments.
Resources: Types of resources that may be used (IP addresses, storage configuration, if NFS is required, and so on).
Node 1 Node 2 IP Network Non-IP Network
SSA
Enclosure 1 Enclosure 22.5.1 AIX level and related requirements
Before you install the HACMP, you must check the operating system level requirements.
Table 2-4 shows the recommended HACMP and operating system levels at the time this redbook was written.
Table 2-4 Operating system level requirements for HACMP V5.1 and V5.2
For the latest list of recommended maintenance levels for HACMP V5.1 and V5.2, access the IBM Web site at:
http://www-912.ibm.com/eserver/support/fixes/fcgui.jsp
The following AIX optional base operating system (BOS) components are prerequisites for HACMP:
bos.adt.lib bos.adt.libm bos.adt.syscalls bos.net.tcp.client bos.net.tcp.server bos.rte.SRC bos.rte.libc bos.rte.libcfg bos.rte.libcur
HACMP Version AIX OS Level AIX APARs RSCT Level
HACMP V5.1 5100-05 IY50579, IY48331 2.2.1.30 or higher HACMP V5.1 5200-02 IY48180, IY44290 2.3.1.0 or higher HACMP V5.2 5100-06 IY54018, IY53707,
IY54140, IY55017
2.2.1.30 or higher
HACMP V5.2 5200-03 IY56213 2.3.3.0 or higher
Note:
To use C-SPOC with VPATH disks, Subsystem Device Driver (SDD) 1.3.1.3 or later is required.
To use HACMP Online Planning Worksheets, AIX 5L Java Runtime Environment 1.3.1 or later and a graphics display (local or remote) are required.
HACMP V5.1 and V5.2 support the use of AIX 5L V5.2 Multi-path I/O (MPIO) device drivers for accessing disk subsystems.
bos.rte.libpthreads bos.rte.odm bos.data
When using the (enhanced) concurrent resource manager access, the following components are also required.
bos.rte.lvm.5.1.0.25 or higher (for AIX 5L V5.1) bos.clvm.enh
For the complete list of recommended maintenance levels for AIX 5L V5.1 and V5.2, see the following IBM Web page:
http://www-912.ibm.com/eserver/support/fixes/fcgui.jsp
2.5.2 Application compatibility
HACMP is a flexible, high availability solution, in the sense that virtually
any
application running on an stand-alone AIX server can be protected through the use of an HACMP cluster.When starting cluster application planning, you should consider the following aspects:
Application compatibility with the version of AIX used.
Application compatibility with the storage method to be implemented for high availability.
You also must know all the interdependencies between the application and platform, that is, all the locations where all the application files are stored (permanent data, temporary files, sockets, and pipes, if applicable).
You should be able to provide an unattended application start/stop method (scripts) and the application must be able to recover from errors (for example, in case the node running the application crashes) when restarted.
If you plan to use application monitoring, you should also provide application monitoring tools (methods, behavior, and scripts).
Application client dependencies (client behavior when the server is restarted). Application network dependencies (sockets, routes, and so on)
Licensing issues, that is, if your application is dependent on the CPU ID, you Important: Do not proceed to HACMP implementation if your application does not run correctly on a stand-alone node, or if you are not sure about all application dependencies!!!
application. Also, if the application is licensed based on the number of processors, make sure, in a fail-over situation, that the licensing is not breached.
Application servers
According to the HACMP definition, an application server is represented by a collection of scripts that are used by HACMP to start an application when activating a resource group and to stop the same application when bringing the resource group offline.
Once the application has been started, HACMP can also monitor this application, and take action in case the application does not run properly. The application monitoring can be performed at process level, and also by using a custom method (for example, for a multi-process application like database engines and so on).
HACMP also provides the application availability analysis tool, which is useful for auditing the overall application availability, and for assessing the cluster
environment.
For information about application servers and other resources, see 3.5, “Resource group configuration” on page 128.
2.5.3 Planning NFS configurations
One of the typical applications of HACMP is to provide high availability network file systems (HA-NFS) for client machines and applications. This is useful, especially in a cluster running applications, for mutual takeover with cross-mount network file systems.
Starting with HACMP V4.4, the HA-NFS function has been integrated in HACMP, so there is no separate product anymore.
Some considerations when using NFS:
For the shared volume groups that will be exported via NFS, the volume group
Major Number
is the same on all cluster nodes that can serve the file system(s) in that VG.Note: Application monitoring has been introduced in HACMP/ES V4.4, based on the event management function (EM) of RSCT. Starting with HACMP V5.2, event management has been replaced by Resource Monitoring and Control (RMC), which is functionally equivalent, but provides more flexibility. Starting with HACMP V5.2, it is also possible to monitor application startup.
In AIX, when you export files and directories, the mknfsexp command is used, so the /etc/exports file is created/updated. In HACMP, on the other hand, the file systems and directories to be exported and NFS mounted must be specified in the resource group configuration.
If you need any optional configuration for these file systems, you should create the /usr/es/sbin/cluster/etc/exports file.
For all resource groups that have file systems to export, the “File systems Mounted before IP Address Configured” attribute must be set to “true”. The HACMP scripts contain the default NFS behavior. You may need to
modify these scripts to handle your particular configuration.
In HACMP V5.1, in addition to cascading resource groups, you can configure high availability NFS in either in rotating or custom resource groups.
For more information, see the HACMP for AIX 5L V5.1 Planning and Installation
Guide, SC23-4861-02.
2.5.4 Licensing
Most software vendors require that you have a unique license for each application for each physical machine or per processor in a multi-processor (SMP) machine. Usually, the license activation code is entered at installation time.
However, in a HACMP environment, in a takeover situation, if the application is restarted on a different node, you must make sure that you have the necessary activation codes (licenses) for the new machine; otherwise the application may not start properly.
The application may also require a unique node-bound license (a separate license file on each node).
Some applications also have restrictions with the number of floating licenses available within the cluster for that application. To avoid this problem, be sure that you have enough licenses for each cluster node machine, so the application can run simultaneously on multiple nodes (especially for concurrent applications).
Note: The NFS locking functionality is limited to a cluster with two nodes. This functionality provides a reliable NFS server capability that allows a backup processor to recover current NFS activity should the primary NFS server fail, preserving the locks on NFS file systems and dupcache.
2.5.5 Client connections
During resource group takeover, the application is started on another node, so clients must be aware of the action. In certain cases, the applications client uses the ARP cache on the client machine to reconnect to the server. In this case, there are two possible situations:
The network holding the service IP for that application uses IPAT via IP replacement with locally administered MAC address takeover (thus, the client machine ARP cache does not have to be updated).
HACMP uses the clinfo program that calls the /usr/es/sbin/cluster/etc/clinfo.rc script whenever a network or node event occurs. By default, this action updates the system’s ARP cache and specified clients ARP cache to reflect changes to network addresses. You can customize this script if further action is desired.
Clients running the clinfo daemon will be able to reconnect to the cluster quickly after a cluster event.
If the HACMP nodes and the clients are on the same subnet, and clients are not running the clinfo daemon, you may have to update the local ARP cache
indirectly by pinging the client from the cluster node.
You can achieve this by adding, on the cluster nodes, the IP labels or IP addresses of the client hosts you want to notify to the PING_CLIENT_LIST variable in the clinfo.rc script. Whenever a cluster event occurs, the clinfo.rc scripts executes the following command for each host specified in
PING_CLIENT_LIST:
# ping -c1 $host
In case the clients are on a different subnet, make sure that the router ARP cache is updated when an IPAT occurs; otherwise, the clients will expect delays in reconnecting.