C H A P T E R  8

Cannot Collect Statistics by Using the Node Management Agent

For information about how to recover from errors that occur when you are using the Node Management Agent (NMA), see the following sections:


An External Client Cannot Communicate With the Node Management Agent

If an external client cannot communicate with the NMA on a peer node, perform the following procedure.

procedure icon  To Investigate Why an External Client Cannot Communicate With an NMA on a Peer Node

  1. Confirm that an RMI registry has not been instantiated on a designated NMA TCP port.

    When a Java Dynamic Management Kit agent enables an RMI connector, the agent instantiates an RMI registry on the port it is using. If an RMI registry uses the same TCP port as the NMA, communication with the NMA is impossible. The RMI registry that initially allocated the port has control of the port.

  2. If the NMA is not accessible through RMI, do the following.

    1. Uncomment the java.rmi.server property in the nma.properties file.

    2. Set the value of the java.rmi.server property to the IP address or host name of the node.

    3. Restart the NMA on all nodes:


      # /etc/opt/SUNWcgha/init.d/nma stop
      

      If the NMA fails to restart, see NMA Not Restarted After Failure.

  3. If you cannot resolve this problem, contact your customer support center.


NMA Not Restarted After Failure

The NMA process is monitored by the Daemon Monitor. If the NMA on a peer node fails, the Daemon Monitor restarts it. If the NMA fails to restart, perform the following procedure.

procedure icon  To Investigate Why the NMA Is Not Restarted

  1. Find the current number of times that the Daemon Monitor has attempted to restart the NMA.

    This parameter is called the reset retry count. For information, see Daemon Monitor Statistics in the Netra High Availability Suite 3.0 1/08 Foundation Services NMA Programming Guide.

  2. Confirm that the reset retry count does not exceed 10.

    The Daemon Monitor attempts to restart the NMA up to 10 times.

    • If the reset retry count has not been exceeded, go to Step 5.

    • If the reset retry count has been exceeded, try one or both of the following:

      a. Reset the reset retry counter by using the resetRetryCount method.

      For information, see Manipulating Daemon Monitor Retry Settings in the Netra High Availability Suite 3.0 1/08 Foundation Services NMA Programming Guide.

      b. Analyze the traces to diagnose the cause of the problem.

  3. If you cannot resolve this problem, contact your customer support center.


NMA Not Sending SNMP Traps to a Given Target

If the NMA does not send SNMP traps to a target, confirm that the following files are configured:

where installDir is the root installation directory. Replace installDir with the root installation directory if the root installation directory is not /.

For information about these files, see their man pages in the Netra High Availability Suite 3.0 1/08 Foundation Services Reference Manual. For information about sending SNMP traps, see “Developing a Remote SNMP Manager” in the Netra High Availability Suite 3.0 1/08 Foundation Services NMA Programming Guide.


The switchOver Method Does Not Finish Executing

The switchOver method is run on the NMA on the master node to initiate a switchover. When you use the switchOver method, do not use the floating external address to access the master node. When the floating external address is used, the switchOver method breaks the connection. Instead, use a fixed IP address on the master node.


Cascading Fails

Cascading is the transfer of statistics from the NMA on each of the peer nodes into the namespace of the master node. Cascading provides the NMA of the master node with a view of the entire cluster. If the NMA on a peer node cannot be detected by the NMA on the master node, perform the following procedure.

procedure icon  To Examine Why Cascading Fails

  1. Confirm that cascading is enabled.

    1. Open the /etc/opt/SUNWcgha/nma.properties file.

    2. Confirm that the following line is commented out:


      com.sun.nhas.ma.cascading.enabled=false
      

      • If the line is commented out, go to Step 6.

      • If the line is not commented out, comment it out and restart the NMA:


        # /etc/opt/SUNWcgha/init.d/nma stop
        

        If the NMA fails to restart, see NMA Not Restarted After Failure.

  2. Confirm that the maximum number of HTTP clients has not been exceeded.

    1. Connect to the NMA of the node that is not cascading correctly, using an Internet browser.

      For information, see Accessing the NMA in the Netra High Availability Suite 3.0 1/08 Foundation Services NMA Programming Guide.

    2. Find the number of connected clients.

      The number of connected clients is specified in the com.sun.nhas.ma.connectors.http.client property.

    3. Find the maximum number of connected clients.

      • Open the /etc/opt/SUNWcgha/nma.properties file.

      • Find the value of the connectors.http.client parameter.

    4. If the number of connected clients exceeds the maximum, increase the maximum.

      • Change the connectors.http.client parameter in the /etc/opt/SUNWcgha/nma.properties file.

      • Restart the NMA:


        # /etc/opt/SUNWcgha/init.d/nma stop
        

        If the NMA fails to restart, see NMA Not Restarted After Failure.

  3. If you cannot resolve this problem, contact your customer support center.