Planning the HACMP Configuration

Plan to have the following components in an HACMP cluster:
•An application
•Up to eight nodes
•Resource groups
•Networks.
Planning Applications
Once you put an application under HACMP’s control, HACMP starts it on the node(s) and periodically polls the application’s status, if you define application monitors. In cases of component failures, HACMP moves the application to other nodes while the process is invisible to application’s end users.
Plan to have the following for your application:
•Customized application start and stop scripts and their locations. The scripts should contain all pre- and post-processing you want HACMP to do so that it starts and stops the applications on the nodes cleanly and according to your requirements. You define these scripts as the application server in WebSMIT.
•Customized scripts you may want to use in HACMP for monitoring the application’s successful startup, and for periodically checking the application’s running process. You define these scripts to HACMP as application monitors in WebSMIT.
•If you have a complex production environment with tiered applications that require dependencies between their startup, or a staged production environment where some applications should start only if their “supporting” applications are already running, HACMP supports these configurations by letting you configure multiple types of dependencies between resource groups in WebSMIT.
To configure a working cluster that will support such dependent applications, first plan the dependencies for all the services that you want to make highly available. For examples of such planning, see the HACMP for AIX Planning Guide and Administration Guide (sections on multi-tiered applications and resource group dependencies).

In HACMP 5.4.1, you can use WebSMIT to take an application out of HACMP’s control temporarily without disrupting it, and then restart HACMP on the nodes that currently run the application.
Planning HACMP Nodes
HACMP for Linux lets you configure up to eight HACMP nodes.
For each critical application, be mindful of the resources required by the application, including its processing and data storage requirements. For example, when you plan the size of your cluster, include enough nodes to handle the processing requirements of your application after a node fails.
Keep in mind the following considerations when determining the number of cluster nodes and planning the nodes:
•An HACMP cluster can be made up of any combination of supported workstations, LPARs, and other machines. See Hardware for Cluster Nodes. Ensure that all cluster nodes do not share components that could be a single point of failure (for example, a power supply). Similarly, do not place nodes on a single rack.
•Create small clusters that consist of nodes that perform similar functions or share resources. Smaller, simple clusters are easier to design, implement, and maintain.
•For performance reasons, it may be desirable to use multiple nodes to support the same application. To provide mutual takeover services, the application must be designed in a manner that allows multiple instances of the application to run on the same node.
For example, if an application requires that the dynamic data reside in a directory called /data, chances are that the application cannot support multiple instances on the same processor. For such an application (running in a non-concurrent environment), try to partition the data so that multiple instances of the application can run—each accessing a unique database.
Furthermore, if the application supports configuration files that enable the administrator to specify that the dynamic data for instance1 of the application reside in the data1 directory, instance2 resides in the data2 directory, and so on, then multiple instances of the application are probably supported.
•In certain configurations, including additional nodes in the cluster design can increase the level of availability provided by the cluster; it also gives you more flexibility in planning node fallover and reintegration.
The most reliable cluster node configuration is to have at least one standby node.
•Choose cluster nodes that have enough I/O slots to support redundant network interface cards and disk adapters.
Ensure you have enough cluster nodes in your cluster. Although this adds to the cost of the cluster, we highly recommend to support redundant hardware, (such as enough I/O slots for network interface cards and disk adapters). This will increase the availability of your application.
•Use nodes with similar processing speed.
•Use nodes with the sufficient CPU cycles and I/O bandwidth to allow the production application to run at peak load. Remember, nodes should have enough capacity to allow HACMP to operate.
for this, benchmark or model your production application, and list the parameters of the heaviest expected loads. Then choose nodes for an HACMP cluster that will not exceed 85% busy, when running your production application.
Planning for Resource Groups in an HACMP Cluster
To make your applications highly available in an HACMP cluster, plan and configure resource groups. Resource groups must include resources related to the application, such as its start and stop script (application server) and the service IP label for the application.
Plan the following for resource groups in HACMP for Linux:
•The nodelist for the resource groups must contain all or some nodes from the cluster. These are the nodes on which you “allow” HACMP to host your application. The first node in the nodelist is the default node, or the home node for the resource group that contains the application. You define the nodelist in WebSMIT.
•You can use any set of resource group policies for a resource group startup, fallover and fallback. In WebSMIT, HACMP lets you combine only valid sets of these policies and prevents you from configuring non-working scenarios.
•HACMP for Linux supports only non-concurrent resource groups.
•HACMP for Linux does not support the fallover policy Fallover using Dynamic Node Priority policy.
•HACMP for Linux does not support cluster sites.
•If your applications are dependent on other applications, you may need to plan for dependencies between resource groups. HACMP lets you have node-collocated resource groups, resource groups that always must reside on different nodes, and also child resource groups that do not start before their parent resource groups are active (parent/child dependencies). Make a diagram of your dependent applications to better plan dependencies that you want to configure for resource groups, and then define them in WebSMIT.
•HACMP processes the resource groups in parallel by default.
•HACMP for Linux does not allow dynamic changes to the cluster resources or resource groups (also known as dynamic reconfiguration or DARE). This means that you must stop the cluster services, before changing the resource groups or their resources.
For complete planning information, see the guidelines in Chapter 6: Planning Resource Groups in the HACMP Cluster in the HACMP for AIX Planning Guide.

Resource Group Policies: Overview
HACMP allows you to configure only valid combinations of startup, fallover, and fallback behaviors for resource groups. The following table summarizes the basic startup, fallover, and fallback behaviors you can configure for resource groups in HACMP for Linux v. 5.4.1:
Startup Behavior
Fallover Behavior
Fallback Behavior
Online only on home node (first node in the nodelist)
•Fallover to next priority node in the list
•Never fall back
or
•Fall back to higher priority node in the list
Online on first available node
Any of these:
•Fallover to next priority node in the list
•Bring offline (on error node only)
•Never fall back
or
•Fall back to higher priority node in the list
Planning IP Networks and Network Interfaces
Plan to configure the following networks and IP interfaces:
•A heartbeating IP-based network. An HACMP cluster requires at least one network that will be used for the cluster heartbeating traffic.
•A heartbeating serial network, such as RS232.
•An IP-based network that lets you connect from the application’s client machine to the nodes. The nodes serve as the application’s servers and run HACMP. To configure this network, plan to configure a client machine with a network adapter and a NIC compatible with at least one of the networks configured on the cluster nodes.
•Two HACMP cluster networks. These are TCP/IP-based networks used by HACMP for inter-node communication. HACMP utilities use them to synchronize information between the nodes and propagate cluster changes across the cluster nodes.
For each HACMP cluster network, on each cluster node plan to configure two IP labels that will be available at boot time, will be configured on different subnets, and will be used for IPAT via IP aliasing. See Planning IP Labels for IPAT via IP Aliasing.
•On the cluster node that will serve as a Web server, set up a network connection to access WebSMIT. Typically, you set up WebSMIT to be accessible from the cluster’s internal network that is not reachable from the Internet. To securely run WebSMIT on a node, you must ensure HTTP(S)/SSL connectivity to that node; it is not handled automatically by WebSMIT or HACMP. See Security Considerations.
Planning IP Labels for IPAT via IP Aliasing
IP address takeover via IP aliasing is the default method of taking over the IP address and is supported in HACMP for Linux. IPAT via IP aliasing allows one node to acquire the IP label and the IP address of another node in the cluster, using IP aliases.

To enable that IP Address Takeover via IP aliases can be used in the HACMP for Linux networks configuration, configure NICs for the two HACMP cluster networks that meet the following requirements:
•Plan to configure more than one boot-time IP label on the service network interface card on each cluster node.
•Subnet requirements:
•Multiple boot-time addresses configured on a node should be defined on different subnets.
•Service IP addresses must be configured on a different subnet from all non-service addresses (such as boot) defined for that network on the cluster node.
•Multiple service labels can coexist as aliases on a given interface.
•The netmask for all IP labels in an HACMP network must be the same.
•Manually add the IP labels described in this section into the /etc/hosts file on each node. This must be done before you proceed to configure an HACMP cluster in WebSMIT.
HACMP non-service labels are defined on the nodes as the boot-time addresses, assigned by the operating system after a system boot and before the HACMP software is started. When you start the HACMP software on a node, the node’s service IP label is added as an alias onto one of the NICs that has a non-service label.
When using IPAT via IP Aliases, the node’s NIC must meet the following conditions:
•The NIC has both the boot-time and service IP addresses configured, where the service IP label is an alias placed on the interface.
•The boot-time address is never removed from a NIC, simply an alias is added on the NIC in addition to the boot-time address.
•If the node fails, a takeover node acquires the failed node’s service address as an alias on one of its non-service interfaces on the same HACMP network. During a node fallover event, the service IP label that is moved is placed as an alias on the target node’s NIC in addition to any other service labels that may already be configured on that NIC.
When using IPAT via IP Aliases, service IP labels are acquired using all available non-service interfaces. If there are multiple interfaces available to host the service IP label, the interface is chosen according to the number of IP labels currently on that interface. If multiple service IP labels are acquired and there are multiple interfaces available, the service IP labels are distributed across all the available interfaces.
Once you install HACMP for Linux, proceed to configure WebSMIT for access to the cluster configuration user interface.

Software Prerequisites for Installation
When you install HACMP for Linux, make sure that the following software is installed on the cluster nodes:
•Red Hat™ Enterprise Linux (RHEL) 4 or SUSE™ LINUX Enterprise Server (SLES) 9 (both with latest updates).
Read the readme file for WebSMIT/usr/es/sbin/cluster/wsm/README for information on specific Apache V1 and V2 requirements, and for information on specific issues related to RHEL or SUSE Linux distribution.
•RSCT 2.4.5.2. For the latest information about RSCT levels and the latest available APARs for RSCT, check the HACMP for Linux v. 5.4.1 Release Notes.
•Apache WebServer V1 and V2 (provided with the Linux distribution).
•ksh93. A compliant version of ksh. Ensure that the ksh version you have installed is ksh93 compliant. The ksh93 environment is a prerequisite for the RHEL distribution, and HACMP for Linux checks for it prior to the installation.
You can download ksh93 from the Web. The fileset name is similar to the following: ksh-20050202-1.ppc.rpm.