The addNode command incorporates an application server installation into a cell.
Depending on the size and location of the new node you incorporate into the cell, this command can take a few minutes to complete.
You must have Administrator privileges to use
the addNode function.
The node agent server is automatically started as part of the addNode command unless you specify the -noagent option. If you recycle the system that hosts an application server node, and did not set up the node agent to act as an operating system daemon, you must issue a startNode command to start the node agent before starting any application servers.
Read the topic on using command line tools to determine whether to run the command from the profile or application server root directory.
See the command syntax:
addNode dmgr_host [dmgr_port] [-profileName profilename] [-conntype type] [-includeapps] [-startingport portnumber] [-portprops qualified_filename] [-nodeagentshortname name] [-nodegroupname name] [-includebuses] [-registerservice] [-serviceusername name] [-servicepassword password] [-coregroupname name] [-noagent] [-statusport 1231] [-quiet] [-nowait] [-logfile filename] [-replacelog] [-trace] [-username uid] [-password pwd] [-localusername localuid] [-localpassword localpwd] [-help]
The dmgr_host argument is required. All of the other arguments are optional. The default port number is 8879 for the default SOAP port of the deployment manager. SOAP is the default Java Management Extensions (JMX) connector type for the command. If you have multiple product installations or multiple profiles, the SOAP port might be different than 8879. Examine the deployment manager SystemOut.log file to see the current ports in use.
The following options are available for the addNode command:
The applications are mapped to the server that you federated using the addNode command. When the addNode command operation completes, the applications run on that server when the server is started. Since these applications are part of the network deployment cell, you can map them to other servers and clusters in the cell using the administrative console. Read about mapping modules to servers for more information.
Do not use the -includeapps option if the node that you want to federate includes the product-supplied applications, such as the Samples. If you do, the second node to be federated that includes these applications is rejected because the applications already exist in the cell and application merge is not supported.
If you use the -includeapps option on a node that includes a large number of applications, then the timeout for the administrative connector must be extended to account for the additional time required to transfer all of the applications to the deployment manager during the addNode operation and to remotely install them into the cell. The -includeapps option is not a recommended approach unless only a few unique applications exist on the node.
By default, during application
installation, application binaries are extracted in the app_server_root/installedApps/cellName directory.
After the addNode command, the cell name of the configuration on the
node that you added changes from the base cell name to the deployment
manager cell name. The application binary files are located where
they were before you ran the addNode command, for example,
app_server_root/installedApps/old_cellName.
${app_server_root}/${CELL}The variable ${CELL}, specifies the current cell name. Then, when the addNode command runs, the binary files are moved to the following directory:
${app_server_root}/currentCellName
Federating the node to a cell using the addNode command does not merge any cell-level configuration, including virtual host information. If the virtual host and aliases for the new cell do not match the product, you cannot access the applications running on the servers. You have to manually add all the virtual host and host aliases to the new cell, using the administrative console running on the deployment manager.
ADMU0111E: Program exiting with error: java.lang.OutOfMemoryError
This error can occur when large applications are processed, or when there is a large number of applications in the Base Application Server.
To recover from this error and successfully federate the application server, complete the following actions:
SET JVM_EXTRA_CMD_ARGS="-Djava.security.properties=$WAS_HOME/java/jre/lib/security/ java.security -Xms256m -Xmx1024m"
JVM_EXTRA_CMD_ARGS="-Djava.security.properties=$WAS_HOME/java/jre/lib/security/ java.security -Xms256m -Xmx1024m"
To
avoid potential port conflicts, read about port
number settings for more information
on default port settings.
If multiple node agents exist on the same physical server, then you can define the base port number for each by using the -startingport parameter prior to federation, or by modifying the ports in the node agent section of the serverindex.xml file.
You can optionally define a user name and password for the windows service using the -serviceusername parameter and the -servicepassword parameter. If you define a user name, you must give the user name Logon as a service authority for the service to run properly.
If you do not specify a user name and password, then the service runs under the local system account.
SOAP_CONNECTOR_ADDRESS=3000 BOOTSTRAP_ADDRESS=3001
addNode testhost 8879 (adds an application server to the deployment manager) addNode deploymgr 8879 -trace (produces the addNode.log file) addNode host25 8879 -nowait (does not wait for a node agent process)The value 8879 is the default port.
When
adding a node to the cell, you automatically inherit both the user
registry and the authentication mechanism of the cell.
When adding
a node to a cell, the newly federated node automatically inherits
the user registry (Local OS, Lightweight Directory Access Protocol
(LDAP), or Custom), authentication mechanism (LTPA or ICSF), and authorization setting (WebSphere
bindings or System Authorization Facility (SAF) EJBROLE profiles)
of the existing Network Deployment cell.
For distributed security, all servers in the cell must use the same user registry and authentication mechanism. To recover from a user registry change, you must modify your applications so that the user and group-to-role mappings are correct for the new user registry. See the article on assigning users and groups to roles.
Another important consideration is the Secure Sockets Layer (SSL) public-key infrastructure. Prior to running the addNode command with the deployment manager, verify that the addNode command can communicate as an SSL client with the deployment manager. This communication requires that the addNode truststore that is configured in the sas.client.props file contains the signer certificate of the deployment manager personal certificate, as found in the keystore and specified in the administrative console.
See the article, Managing digital certificates.
addNode CELL_HOST 8879 -includeapps -username user -password pass
The -includeapps parameter is optional. This option attempts to include the server applications into the Deployment Manager. The addNode command might fail if the user registries used by the application server and the deployment manager are not the same. To correct this failure, either make the user registries the same or turn off security. If you change the user registries, remember to verify that the users-to-roles and groups-to-roles mappings are correct. Read about the addNode command for more information on the addNode syntax.
You can
also run the addNode command using the z/OS Customization dialog.
If you issue the addNode command with security enabled using the z/OS
Customization dialog or command prompt, you must use a user ID with
authority and specify the -user and -password options.
WebSphere Application Server for z/OS defines
security domain names using the z/OS Customization Dialog. Use caution
when adding a node to a Deployment Manager configuration that defines
a different security domain.