Operating Systems: i5/OS
Personalize the table of contents and search results
addNode command best practices
Use the addNode command to add a standalone node into a
cell.
The addNode command does the following:
- Copies the base WebSphere Application Server cell configuration to a new
cell structure. This new cell structure matches the structure of deployment
manager.
- Creates a new node agent definition for the node that the cell incorporates.
- Sends commands to the deployment manager to add the documents from the
new node to the cell repository.
- Performs the first configuration synchronization for the new node, and
verifies that this node is synchronized with the cell.
- Launches the node agent process for the new node.
- Updates the setupCmdLine.bat or setupCmdline.sh files and the wsadmin.properties
file to point to the new cell.
- After federating the node, the addNode command backs up the plugin-cfg.xml file
from the app_server_root/config/cells directory
to the config/backup/base/cells directory. The addNode command
regenerates a new plugin-cfg.xml file at the Deployment Manger and
the nodeSync operation copies the files to the node level.
Tips for using the addNode command:
- If you add a node to a cell, the cell name of the node you are federating
must be different from the name of the cell to which the node is federated.
Otherwise, you receive the ADMU0027E message, and the addNode command does
not add the node to the cell.
- Verify that the deployment manager and nodes are updated to the same revision
level within the WebSphere Application Server. For example, a deployment manager
at level 6.0.1 will be unable to federate with nodes at 6.0.2.
- Do not put WebSphere Application Server .jar files on the generic CLASSPATH variable
(default class path) for the overall system.
- By default, applications that are installed on the node will not copy
to the cell. If you install an application after using the addNode command,
the application will install on the cell. By specifying the -includeapps option,
you force the addNode command 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 the addNode command must
be repeated on the new cell. For example, virtual hosts.
- If you receive an OutOfMemory exception while using the addNode command,
you may need to increase the heap size of the deployment manager. To increase
the heap size of the deployment manager, adjust the Maximum Heap Size parameter
using the administrative console. In the administrative 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 deployment
manager to respond to the addNode command. 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 you 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, open the file $WAS_HOME/profiles/<profile
name>/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
If
you need to change the default you can edit this line to set the timeout to
a value more appropriate for your situation (Note: setting the above
value to 0 will disable the timeout check altogether). If the timeout value
is set too high you will have to wait a long time to determine if the addNode command
will successfully complete its request to the deployment manager. If the value
is set too short the deployment manager will not have sufficient time to complete
the request before the addNode command concludes that the deployment
manager is not responding and will respond with an error. Other factors that
may affect server timeouts include the processing load or excessive paging
on the deployment manager and network latency. Some of these conditions may
be transient.
- If you use the addNode command from a node that
was federated to an existing deployment manager, the deployment manager will
be corrupt. You will not be able to start the second deployment manager after
you stop it. This happens because the addNode command creates a dmgrProfile]/config/cells/dmgrCell/nodeName directory
in the master configuration. This is an incomplete node configuration directory.
You
will come into contact with the issue if you have a federated node and run
the addNode command again for a different deployment manager. This
causes the deployment manager to be corrupted and you will not be able to
start the deployment manager afterwards because of the incomplete node directory.
Perform
one of the following solutions to resolve this issue:
Related tasks
Managing nodes
Related Reference
addNode command
removeNode command
Reference topic