18.3.1 Configuring application failover manually

To configure NNMi for application failover:

1. Install NNMi on the active server (server X) and the standby server (server Y).

   

2. Install a permanent license in each server, as described in 2.3 Licensing NNMi.

3. Run the ovstop command on each server to shut down NNMi.

4. Configure server X (active) and server Y (standby) for the application failover feature using guidance from the detailed instructions contained in the nms-cluster.properties file.

   Use the procedure shown below. Edit in the following steps means to uncomment (remove the leading #! from) the lines in the text block within the file and to modify the text.

   a. Edit the following file:

   Windows:

   %NnmDataDir%shared\nnm\conf\props\nms-cluster.properties

   Linux:

   $NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

   b. Declare a unique name for the NNMi cluster. Use the same name when configuring both the active and standby servers. Specify alphanumeric characters for the name, which is case-sensitive.

   Specifying this parameter enables the application failover feature:

   com.hp.ov.nms.cluster.name=MyCluster

   c. Add the host names of all nodes in the cluster to the com.hp.ov.nms.cluster.member.hostnames parameter in the nms-cluster.properties file:

   com.hp.ov.nms.cluster.member.hostnames = fqdn_for_active,fqdn_for_standby

   Important

   If either of the nodes has multiple IPv4 addresses, enter the IPv4 address to be used for each node's NNMi communication in the com.hp.ov.nms.cluster.member.hostnames parameter.

5. Configure the NNMi certificate (use nnm-key.p12 and nnm-trust.p12 files or a certification organization).

   Depending on the method you selected, complete the set of instructions described in 10.3.5 Working with Certificates in Application Failover Environments.

   Important

   When configuring the application failover feature, you must merge the nnm-trust.p12 file content for both nodes into a single nnm-trust.p12 file. You must choose your approach and complete one set of instructions.

6. Back up the source files, which will be used when canceling the application failover configuration, and then copy the following file from server X to server Y:

   Windows:

   %NnmDataDir%shared\nnm\conf\nnmcluster\cluster.keystore

   Linux:

   $NnmDataDir/shared/nnm/conf/nnmcluster/cluster.keystore

7. Configure the NIC that is used for cluster communication between both nodes.

   For details, see 18.3.3 Setting application failover communications.

   Important

   Make sure to specify the setting if either of the nodes has multiple NICs.

8. Run the following command on both server X and server Y:

   nnmcluster

   Each server displays something similar to the following:

   ================== Current cluster state ==================
   State ID: 000000001000000005
   Date/Time: 15 3 2011 - 09:37:58 (GMT+0900)
   Cluster name: ThisCluster (key CRC:626,187,650)
   Automatic failover: Enabled
   NNM database type: Embedded
   NNM configured ACTIVE node: NO_ACTIVE
   NNM current ACTIVE node: NO_ACTIVE
   Cluster members are:
    
    Local?  NodeType State OvStatus Hostname/Addresses
   -------  -------- ----- -------- --------------------------
   * REMOTE ADMIN     N/A   N/A      serverX.xxx.yyy.yourcompany.com/16.78.61.68:7800
   (SELF)   ADMIN     N/A   N/A      serverY.xxx.yyy.yourcompany.com/16.78.61.71:7800
   ==========================================================+

   Important

   To terminate the command, press the Enter key and then enter the command quit.

   If NNMi is configured correctly, the display lists both server X and server Y. If information about both nodes is not displayed, the nodes are not communicating with each other. Here are some things to check for and correct before continuing:

   • Specify the same cluster name in com.hp.ov.nms.cluster.name on both servers, as follows:

     - Windows: %NnmDataDir%shared\nnm\conf\props\nms-cluster.properties

     - Linux: $NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

   • The key CRCs might be different on server X and server Y.

     Check the contents of the following file on both server X and server Y:

     - Windows:

     %NnmDataDir%shared\nnm\conf\nnmcluster\cluster.keystore

     - Linux:

     $NnmDataDir/shared/nnm/conf/nnmcluster/cluster.keystore

     If the key CRCs are different, perform step 6.

   • A firewall on server X or server Y might be preventing the nodes from communicating.

     Configure the nodes so that they can communicate.

   • Make sure you merged the nnm-trust.p12 files.

     You should see this error displayed after running the nnmcluster command.

   • Make sure that the IP address that is obtained from the NIC specified in com.hp.ov.nms.cluster.interface matches the IP address that will be resolved from the host name specified in com.hp.ov.nms.cluster.member.hostnames.

     Specify com.hp.ov.nms.cluster.interface in the following file:

     - Windows: %NnmDataDir%Conf\nnm\props\nms-cluster-local.properties

     - Linux: $NnmDataDir/conf/nnm/props/nms-cluster-local.properties

     Specify com.hp.ov.nms.cluster.member.hostnames in the following file:

     - Windows: %NnmDataDir%shared\nnm\conf\props\nms-cluster.properties

     - Linux: $NnmDataDir/shared/nnm/conf/props/nms-cluster.properties

   • Make sure that the remote server's standby IP address matches the IP address specified for the remote server.

     Check that the IP address available to the remote server for cluster communication matches the IP address specified for the remote server for cluster communication.

     The default for the port used for cluster communication is 7800.

     You can use the netstat command to check the standby IP address.

     To determine the IP address specified for the remote server for cluster communication, check the com.hp.ov.nms.cluster.member.hostnames parameter in the nms-cluster.properties file.

     If a host name is specified in com.hp.ov.nms.cluster.member.hostnames, check the IP address that can be resolved from the host name.

   • Server X and server Y are running different operating systems.

     For example, server X might be running a Linux operating system and server Y a Windows operating system. Specify the configuration in an environment in which the same operating system is running.

   • Server X and server Y are running different NNMi versions.

     For example, server X might be running NNMi 11-00 and server Y a patched version of NNMi 11-00. Specify the configuration in an environment in which the same version of NNMi is installed.

9. On server X, start the NNMi cluster manager:

   nnmcluster -daemon

   After you run the nnmcluster -daemon command on NNMi management server X, the NNMi cluster manager goes through the following startup routine:

   • Connects NNMi management server X to the cluster.

   • Detects that there are no other NNMi management servers present.

   • NNMi management server X assumes the active state.

   • Starts the NNMi services on NNMi management server X (the active server).

   • Creates a database backup.

   For details, see the nnmcluster Reference Page.

10. Wait a few minutes for server X to become the first active server in the cluster. Run the nnmcluster -display command on server X and search the displayed results for the term ACTIVE, such as ACTIVE_NNM_STARTING or ACTIVE_SomeOtherState. Do not continue with step 11 until you have confirmed that server X is the active server.

11. On server Y, start the NNMi cluster manager:

    nnmcluster -daemon

    After you run the nnmcluster -daemon command on NNMi management server Y, the NNMi cluster manager goes through the following startup routine:

    • Connects NNMi management server Y to the cluster.

    • Detects that NNMi management server X is present and is in the active state. The display shows STANDBY_INITIALIZING.

    • Compares the database backup on NNMi management server Y to the backup on NNMi management server X. If these do not match, a new database backup is sent from NNMi management server X (active) to NNMi management server Y (standby). The display shows STANDBY_RECV_DBZIP.

    • NNMi management server Y receives a minimal set of transaction logs, which is the minimum necessary for the backup to be applicable for its standby state. The display shows STANDBY_RECV_TXLOGS.

    • NNMi management server Y goes into a waiting state, continuously receiving new transaction logs and heartbeat signals from NNMi management server X. The display shows STANDBY_READY.

    For details, see the nnmcluster Reference Page.

12. If a failover occurs, the NNMi console for server X no longer functions. Close the NNMi console session for server X and log on to server Y (the new active server).

    Instruct NNMi users to store two bookmarks in their browsers, one to server X (the active NNMi management server) and one to server Y (the standby NNMi management server). If a failover occurs, users can connect to server Y (the standby NNMi management server).

13. Change the configuration of the devices being monitored by NNMi to send traps to both server X and server Y.

    While server X (active) is running, it processes the forwarded traps and server Y (standby) ignores the forwarded traps.

To Page Top