addNode command best practices

Use the addNode command to add a standalone node into a cell.

Overview

The addNode command does the following:

1. Copies the base WAS cell configuration to a new cell structure. This new cell structure matches the structure of dmgr.

2. Creates a new node agent definition for the node that the cell incorporates.

3. Sends commands to the dmgr to add the documents from the new node to the cell repository.

4. Performs the first configuration synchronization for the new node, and verifies that this node is synchronized with the cell.

5. Launches the node agent process for the new node.

6. Updates setupCmdline.sh and wsadmin.properties to point to the new cell.

7. After federating the node, addNode.sh backs up plugin-cfg.xml from...

   APP_ROOT/config/cells

   ...to the...

   config/backup/base/cells

   ...and generates a new plugin-cfg.xml file at the Deployment Manager and the nodeSync operation copies the files to the node level.

Tips for using addNode.sh

• If we add a node to a cell, the cell name of the node we are federating must be different from the name of the cell to which the node is federated. Otherwise, you receive the ADMU0027E message, and addNode.sh does not add the node to the cell.

• Verify that the dmgr and nodes are updated to the same revision level within the WAS. For example, a dmgr at level 6.0.1 will be unable to federate with nodes at 6.0.2.

• Do not put WAS .jar files on the generic CLASSPATH variable (default class path) for the overall system.

• If WAS ND cannot resolve the host name of the server, problems can occur with such situations as adding or administering nodes, or the node agent contacting the appserver. To resolve the host name, WAS opens a port, or queries for an IP address. WAS ND v7.0 then waits for the operating system to return the correct information. The operating system might go to multiple places to find the IP address, but the product does not care about the order in which the operating system does this, if the correct information is returned. If the host name of the server cannot be resolved, refer to the network administration documentation to resolve the problem.

  The following additional information might help you verify the host name is resolved.

  • Some operating systems create an association between the host name of the machine and the loopback address of 127.0.0.1. Red Hat installations create the association by default. The association is in the hosts file.

    If in the hosts file mappings exist from the 127.0.0.1 IP address to a host name other than localhost, remove the mappings.

    The following example illustrates what might happen if the mappings are not removed: When a node agent communicates with the dmgr, it sends its IP address to the deployment manager. The node agent resolves the node agent host name to 127.0.0.1 if the operating system returns a mapping for the host name from the hosts file. This resolution prevents the dmgr from sending a message to the node agent because the 127.0.0.1 IP address is also the IP address for the local machine of the deployment manager.

    [AIX] [HP-UX] [Linux] [Solaris]

    The hosts file is located at /etc/hosts.

    (Windows) The hosts file is located at \WINDOWS\system32\drivers\etc\hosts.

  • [AIX] The default AIX installation checks the DNS first to return the information to a server so that the server host name of that server or another server can be resolved. If the host name cannot be resolved or cannot be resolved in a reasonable amount of time, you can add the following statement to the /etc/netsvc.conf file so that the AIX operating system checks the local hosts file first for the host name.

    hosts=local,bind
    

• By default, applications that are installed on the node will not copy to the cell. If we install an application after using addNode.sh, the application will install on the cell. By specifying the -includeapps option, you force addNode.sh to copy applications from the node to the cell. Applications with duplicate names will not copy to the cell.

• Cell-level documents are not merged. Any changes that you make to the standalone cell-level documents before using addNode.sh must be repeated on the new cell. For example, virtual hosts.

• If we receive an OutOfMemory exception while using addNode.sh, you may need to increase the heap size of the dmgr. To increase the heap size of the dmgr, adjust the Maximum Heap Size parameter using the admin console. In the admin console, go to...

  System Administration | Deployment Manager | Java and Process Management | Process Definition | Java Virtual Machine | Maximum Heap Size

• In some instances it may take longer than anticipated for the dmgr to respond to addNode.sh.

  The default timeout value, which determines how long the client will wait for a server response, is appropriate in the majority of cases. However, you may require more time for the server to respond under heavier processing conditions. For example, if we include the -includeapps option and have a large number of applications, or the applications are very large, the default value of 180 seconds may be insufficient. To change the default timeout value, edit...

  $PROFILE_HOME/properties/soap.client.props

  ...in any ASCII text editor and find the following line (shown here with default value of 180 seconds):

  com.ibm.SOAP.requestTimeout=180

  Set value higher to enable longer running processes. Setting to 0 will disable the timeout check altogether. If the value is too short the dmgr will not have sufficient time to complete requests. Factors that affect server timeouts include processing load, excessive paging, and network latency.

• If addNode.sh is run from a node that was federated to an existing dmgr, the dmgr will be corrupt. You will not be able to start the second dmgr after you stop it. This happens because the addNode command creates a directory...

  dmgrProfile]/config/cells/dmgrCell/nodeName

  ...in the master configuration. This is an incomplete node configuration directory.

  You will come into contact with the issue if we have a federated node and run addNode.sh again for a different dmgr. This causes the dmgr to be corrupted and you will not be able to start the dmgr afterwards because of the incomplete node directory. Perform one of the following solutions to resolve this issue:

  • If the dmgr is running, we can use the cleanupNode command on dmgr where the incomplete node resides.

  • Manually delete the directory created on the deployment manager configuration during an addNode command operation that was incomplete. For example:

    washome/profiles/dmgrProfile/config/cells/dmgrCell/]nodeName
    

---

 

Related tasks

Manage nodes

 

Related

addNode
removeNode
Port_number_settings_in_WAS790.html