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.
- You cannot add a Version 5.x node to an existing cell managed
by a Version 6.x deployment manager.
You can only include Version
5.x nodes in a Version 6.x mixed-release cell through migration. First,
migrate the deployment manager from Version 5.x to Version 6.x; and
then, either keep the nodes at Version 5.x or migrate them to Version
6.x.
- 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.