Setup and configuration
We set up and configured our test environment as follows:
1. Install HACMP 4.5 or HACMP 4.3.1 or HACMP 4.4 or HACMP 4.4.1 or HACMP/ES 4.5: Before you configure HACMP, network adapters must be defined, the AIX operating system must be updated, and grant clustering nodes permission to access one another. Modify the following configuration files: /etc/netsvc.conf, /etc/hosts, and /.rhosts. Make sure that each node's service adapters and boot addresses are listed in the /.rhosts file on each cluster node so that the /usr/sbin/cluster/utilities/clruncmd command and the /usr/sbin/cluster/godm command can run.
Use smit to install HACMP 4.5, HACMP 4.3.1 or HACMP 4.4 or HACMP 4.4.1 or HACMP/ES 4.5 into both nodes. For installation details, see the HACMP for AIX Installation Guide at: http://www-1.ibm.com/servers/eServer/pseries/library/hacmp_docs.html
You can also install HACMP after you configure the network adapter and shared disk subsystem.
2. Service network configuration: The public network is used to provide services to clients (WebSphere, applications, LDAP, for example). We defined two TCP/IP public networks in our configuration. The public network consists of a service/boot adapter and any standby adapters. It is recommended that you use one or more standby adapters. Define standby IP addresses and boot IP addresses. For each adapter, use smit mktcpip to define the IP label, IP address, and network mask. HACMP will define the service IP address. Since this configuration process also changes the host name, configure the adapter with the desired default host name last. Then use smit chinet to change service adapters so that they will boot from the boot IP addresses. Check your configuration using lsdev -Cc if. Finally, try to ping nodes to test the public TCP/IP connections.
3. Serial network configuration: A serial network is needed for the heartbeat message; it is a serial network in an HACMP cluster. A serial network allows the cluster manager to continuously exchange keep-alive packets, should the TCP/IP-based subsystem, networks, or network adapters fail. The private network can be either a raw RS232 serial line, a target mode SCSI, or a target mode SSA loop. The HACMP for AIX serial line (a null-model, serial to serial cable) was used to connect the nodes. Use smitty to create the TTY device. After creating the TTY device on both nodes, test the communication over the serial line by entering the command stty </dev/ttyx on both nodes (where /dev/ttyx is the newly added TTY device). Both nodes should display their TTY settings and return to prompt if the serial line is okay. After testing, define the RS232 serial line to HACMP for AIX.
4. Shared disk array installation and LVG configuration: The administrative data, application data, session data, LDAP data, log files and other file systems that need to be highly available are stored in the shared disks that use RAID technologies or are mirrored to protect data. The shared disk array must be connected to both nodes with at least two paths to eliminate the single point of failure. We used IBM 7133 Serial Storage Architecture (SSA) Disk Subsystem. You can either configure the shared volume group to be concurrent access or non-concurrent access. A non-concurrent access environment typically uses journaled file systems to manage data, while concurrent access environments use raw logical volumes. There is a graphical interface called TaskGuide to simplify the task of creating a shared volume group within an HACMP cluster configuration. In Version 4.4, the TaskGuide has been enhanced to automatically create a JFS log and display the physical location of available disks. After one node has been configured, import volume groups to the other node by using smit importvg. 5. DB2 or Oracle and LDAP installation, configuration, instance and database creation: For installation details, see the manuals for these products. You can install these products either on the disks in both nodes or on the shared disk. But keep all the shared data such as database files, transaction log files, and other important files on the shared disk array so that another node can access this data when the current node fails. We chose to install these products on each node. In this case, install the same version of the products on both nodes. Create DB2 or Oracle instances on the shared disk subsystem. We created two DB2 instances for the WebSphere application database and session database. On the other test with Oracle, we also created two Oracle instances for the WebSphere application database and session database. You may need to change the appheapsz for the created DB2 database, or the cursor parameters for Oracle. See the WebSphere installation guide for details. See 12.11, One instance for all WebSphere databases? to decide whether one instance or multiple instances must be used for these databases. If "thick" database clients are used, install the database clients on your WebSphere nodes and configure the database clients to connect to the database server. For example, install DB2 clients on all WebSphere nodes and catalog the remote node and database server. 6. Define the cluster topology and HACMP appservers: The cluster topology is comprised of cluster definition, cluster nodes, network adapters, and network modules. The cluster topology is defined by entering information about each component in HACMP-specific ODM classes. These tasks can be performed using smit hacmp. For details, see the HACMP for AIX Installation Guide at: http://www-1.ibm.com/servers/eServer/pseries/library/hacmp_docs.html
An "appserver", in HACMP or HACMP/ES, is a cluster resource that is made highly available by the HACMP or HACMP/ES software, for example in our case DB2 databases, Oracle databases, and LDAP servers. Do not confuse this with WAS. Use smit hacmp to define the HACMP (HACMP/ES) application server with a name and its start script and stop script. Start and stop scripts for both DB2 and Oracle as the HACMP appservers. Our sample DB2 service start script is:
db2start
And our sample DB2 service stop script is:
db2 force applications all
db2stop
For Oracle, our sample service start script is:
lsnrctl start
export SIDS="APP ADMIN SESSION"
for SID in $SIDS ; do
export ORACLE_SID=$SID
echo "connect internal\nstartup\nquit" | svrmgrl
Done
And our sample Oracle service stop script is:
export SIDS="APP ADMIN SESSION"
for SID in $SIDS ; do
export ORACLE_SID=$SID
echo "connect internal\nshutdown\nquit" | svrmgrl
done
lsnrctl stop
You must be the DB2 or Oracle user to use the above scripts. Otherwise, you need to change users with the su - command.
7. Define and configure the resource groups: For HACMP and HACMP/ES to provide a highly available appserver service, you need to define the service as a set of cluster-wide resources essential to uninterrupted processing. The resource group can have both hardware and software resources such as disks, volume groups, file systems, network addresses, and application servers themselves. The resource group is configured to have a particular kind of relationship with a set of nodes. There are three kinds of node relationships: cascading, concurrent access, or rotating. For the cascading resource group, setting the cascading without fallback (CWOF) attribute will minimize the client failure time. We used this configuration in our tests. Use smit to configure resource groups and resources in each group. Finally, you need to synchronize cluster resources to send the information contained on the current node to the other node. 8. Cluster verification: Use /usr/sbin/cluster/daig/clverify on one node to check that all cluster nodes agree on the cluster configuration and the assignment of HACMP for AIX resources. You can also use smit hacmp to verify the cluster. If all nodes do not agree on the cluster topology and you want to define the cluster as it is defined on the local node, you can force agreement of cluster topology onto all nodes by synchronizing the cluster configuration. Once the cluster verification is satisfactory, start the HACMP cluster services using smit hacmp on both nodes, and monitor the log file using tail -f /tmp/hacmp.out. Check the database processes using ps -ef | grep db2 or ora. 9. Takeover verification: To test a failover, use smit hacmp to stop the cluster service with the takeover option. On the other node, enter the tail -f /tmp/hacmp.out command to watch the takeover activity.
Prev | Home | Next WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.