sun.com | docs.sun.com | How To Buy | My Sun | Worldwide Sites |  |

| Previous Contents Index Next
2. 3. Chapter 9 # 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 NMA Not Restarted After Failure NMA Not Sending SNMP Traps to a Given Target The `switchOver` Method Does Not Finish Executing Cascading Fails ## 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. ### To Investigate Why an External Client Cannot Communicate With an NMA on a Peer Node 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. If the NMA is not accessible through RMI, do the following. Uncomment the `java.rmi.server` property in the `nma.properties` file. Set the value of the `java.rmi.server` property to the IP address or host name of the node. Restart the NMA on all nodes:
          # /etc/opt/SUNWcgha/init.d/nma stop
1. 2. If the NMA fails to restart, see NMA Not Restarted After Failure. 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. ### To Investigate Why the NMA Is Not Restarted 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 Foundation Services 2.1 6/03 NMA Programming Guide. 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 3. If the reset retry count has been exceeded, try one or both of the following: Reset the reset retry counter by using the `resetRetryCount` method. For information, see "Manipulating Daemon Monitor Retry Settings" in the Netra High Availability Suite Foundation Services 2.1 6/03 NMA Programming Guide. Analyze the traces to diagnose the cause of the problem. 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: ``installDir``/etc/opt/SUNWcgha/nma.targets.txt ``installDir``/etc/opt/SUNWcgha/nma.params.txt ``installDir``/etc/opt/SUNWcgha/nma.notifs.txt 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 Foundation Services 2.1 6/03 Reference Manual. For information about sending SNMP traps, see "Developing a Remote SNMP Manager" in the Netra High Availability Suite Foundation Services 2.1 6/03 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. ### To Examine Why Cascading Fails Confirm that cascading is enabled. Open the `/etc/opt/SUNWcgha/nma.properties` file. Confirm that the following line is commented out:
          com.sun.nhas.ma.cascading.enabled=false
   - If the line is commented out, go to Step 2. If the line is not commented out, comment it out and restart the NMA:
         # /etc/opt/SUNWcgha/init.d/nma stop
2. 4. - If the NMA fails to restart, see NMA Not Restarted After Failure. Confirm that the maximum number of HTTP clients has not been exceeded. 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 Foundation Services 2.1 6/03 NMA Programming Guide. Find the number of connected clients. The number of connected clients is specified in the `com.sun.nhas.ma.connectors.http.client` property. Find the maximum number of connected clients. Open the `/etc/opt/SUNWcgha/nma.properties` file. Find the value of the connectors.http.client parameter. 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. If you cannot resolve this problem, contact your customer support center.
Previous Contents Index Next

Copyright 1994-2004 Sun Microsystems