![]() ![]() ![]() |
Chapter 4: Other Cluster Configuration Tasks
This chapter provides you with a brief overview of additional tasks you may need to do in the HACMP for Linux cluster.
Note: The HACMP for AIX 5L Administration Guide contains a detailed description of WebSMIT components and how to use them. It also describes in detail all the configuration tasks.
This chapter describes:
Identifying Service Adapter Failure for Two-Node Clusters: netmon.cf
In cluster configurations where there are networks that under certain conditions can become single adapter networks, it can be difficult for HACMP to accurately determine adapter failure. This is because RSCT Topology Services cannot force packet traffic over the single adapter to confirm its proper operation. (This shortcoming is less of an exposure if the network adapter is under heavy use. In this case, the inbound packet count continues to increase over the service adapter without stimulation from RSCT Topology Services).
An enhancement to netmon, the network monitor portion of RSCT Topology Services, allows for a more accurate determination of a service adapter failure. This function can be used in configurations that require a single service adapter per network.
You can create netmon.cf configuration file that specifies additional network addresses to which ICMP ECHO requests can be sent.
This file must exist at cluster startup—RSCT Topology Services scans the netmon.cf configuration file during initialization. When netmon needs to stimulate the network to ensure adapter function, it sends ICMP ECHO requests to each IP address. After sending the request to every address, netmon checks the inbound packet count before determining whether an adapter has failed.
Creating the netmon.cf File
The netmon.cf file must be placed in the /usr/sbin/cluster directory on all cluster nodes.
Requirements for creating the file:
The netmon.cf file consists of one IP address or IP label per cable. Include each IP address and its corresponding label for the netmon.cf file in the /etc/hosts file. When selecting IP addresses (or hostnames) for the netmon.cf file, keep in mind ALL possible IP addresses that an interface might hold at any given time (boot IP addresses, service IP addresses used by HACMP, and other interfaces), and ensure that for each interface on the node, the netmon.cf file contains one or more targets that can be reached by those addresses. For example, an adapter on a node that serves as a boot adapter when it is not holding a service address should be able to ping some targets in the netmon.cf file using that boot address.
Note: Ensure that the names in the netmon.cf file are included in the /etc/hosts file. If this is not done, then when the NIM process (that is part of the RSCT Topology Services subsystem) attempts to determine the state of the local adapters, it may try to run the hostname resolution. The hostname resolution may in turn result in the process being blocked in cases when the network used for name resolution is unreachable. The blockage may result in longer adapter failure detection times, which will slow fallover operations.
A maximum of 30 IP addresses/labels can be defined in netmon.cf. The following example shows a /usr/sbin/cluster/netmon.cf configuration file:
Choosing IP Addresses for the netmon.cf File
Guidelines for choosing the IP addresses to include in the netmon.cf file depend on whether the local interface is a service or a non-service interface:
If the local interface is a service interface, it will verify that it is operational via point-to-point communication with the following interfaces:
Existing remote service interface(s) on the same logical network One of the existing local non-service interfaces on the same logical network IP addresses/hostnames in the netmon.cf file. If the local interface is a non-service interface, it verifies that it is operational via point-to-point communication with the following interfaces:
Existing remote non-service(s) on the same logical network One of the existing local interfaces on the same logical network IP addresses/hostnames in the netmon.cf file. The netmon.cf file should contain remote IP labels/addresses that are not in the cluster configuration that can be accessed from HACMP interfaces. Routers can also be used.
Resetting Cluster Tunables
You can change the settings for a list of tunable values that were altered during cluster maintenance and reset them to their default settings, or installation-time cluster settings. The installation-time cluster settings are equal to the values that appear in the cluster after installing HACMP from scratch.
Note: Resetting the tunable values does not change any other aspects of the configuration, while installing HACMP removes all user-configured configuration information including nodes, networks, and resources.
To reset the cluster tunable values:
1. Stop the cluster services.
2. Log in to a URL where WebSMIT is installed. The browser window displays the top-level WebSMIT screen.
3. In WebSMIT, select Extended Configuration > Extended Topology Configuration > Configure an HACMP Cluster > Reset Cluster Tunables and press Continue.
Use this option to reset all the tunables (customizations) made to the cluster. For a list of the tunable values that will change, see the section Listing Tunable Values. Using this option returns all tunable values to their default values but does not change the cluster configuration. HACMP takes a snapshot file before resetting. You can choose to have HACMP synchronize the cluster when this operation is complete.
4. Select the options as follows and press Continue:
Synchronize Cluster Configuration If you set this option to yes, HACMP synchronizes the cluster after resetting the cluster tunables.
5. HACMP asks: “Are you sure?”
6. Press Continue.
HACMP resets all the tunable values to their original settings and removes those that should be removed (such as the nodes’ knowledge about customized pre- and post-event scripts).
Resetting HACMP Tunable Values using the Command Line
We recommend that you use the SMIT interface to reset the cluster tunable values. The clsnapshot -t command also resets the cluster tunables. This command is intended for use by IBM support. See the man page for more information.
Listing Tunable Values
You can change and reset the following list of tunable values:
User-supplied information. Network module tuning parameters, such as, failure detection rate, grace period and heartbeat rate. HACMP resets these parameters to their installation-time default values. Cluster event customizations, such as, all changes to cluster events. Note that resetting changes to cluster events does not remove any files or scripts that the customization use; it only removes the knowledge HACMP has of pre- and post-event scripts. Cluster event rule changes made to the event rules database are reset to the installation-time default values. HACMP command customizations made to the default set of HACMP commands are reset to the installation-time defaults. Automatically generated and discovered information. Generally users cannot see this information. HACMP rediscovers or regenerates this information when the cluster services are restarted or during the next cluster synchronization.
HACMP resets the following:
Local node names stored in the cluster definition database Netmasks for all cluster networks Netmasks, interface names and aliases for disk heartbeating (if configured) for all cluster interfaces SP switch information generated during the latest node_up event (this information is regenerated at the next node_up event) Instance numbers and default log sizes for the RSCT subsystem. Understanding How HACMP Resets Cluster Tunables
HACMP resets tunable values to their default values under the following conditions:
Before resetting HACMP tunable values, HACMP takes a cluster snapshot. After the values have been reset to defaults, if you want to go back to your customized cluster settings, you can restore them with the cluster snapshot. HACMP saves snapshots of the last ten configurations in the default cluster snapshot directory, /usr/es/sbin/cluster/snapshots, with the name active.x.odm, where x is a digit between 0 and 9, with 0 being the most recent. Stop cluster services on all nodes before resetting tunable values. HACMP prevents you from resetting tunable values in a running cluster. In some cases, HACMP cannot differentiate between user-configured information and discovered information, and does not reset such values. For example, you may enter a service label and HACMP automatically discovers the IP address that corresponds to that label. In this case, HACMP does not reset the service label or the IP address. The cluster verification utility detects if these values do not match.
The clsnapshot.log file in the snapshot directory contains log messages for this utility. If any of the following scenarios are run, then HACMP cannot revert to the previous configuration:
cl_convert is run automatically cl_convert is run manually Where You Go from Here
The following chapters describe:
Logging and troubleshooting utilities Interaction of HACMP with other client applications (clinfo utility) Command reference Glossary of HACMP terms.
![]() ![]() ![]() |