You can add a node, select the discovery protocol for a node, define a custom property for a node, stop servers on a node, and remove a node.
A node is a grouping of managed or unmanaged servers. You can add both managed and unmanaged nodes to the WebSphere® Application Server topology. If you add a new node for an existing WebSphere Application Server to the network deployment cell, you add a managed node. If you create a new node in the topology for managing web servers or servers other than WebSphere Application Servers, you add an unmanaged node.
You can recover an existing managed node of a deployment manager cell. One of the options to add a managed node enables you to quickly recover a damaged node. The option is similar to the -asExistingNode parameter of the addNode command.
To view information about nodes and managed nodes, use the Nodes page. To access the Nodes page, click System administration > Nodes in the administrative console navigation tree.
You can manage nodes on an application server through the wsadmin scripting tool, through the Java application programming interfaces (APIs), or through the administrative console. Perform the following tasks to manage nodes on an application server through the administrative console.
If the deployment manager is on | And the node that you add to the cell is on | Complete the appropriate set of actions: |
---|---|---|
![]() ![]() |
The distributed platform or the IBM i platform | Optionally specify a node group and a core group. Click OK. |
![]() |
A z/OS system and is in the same sysplex as the deployment manager | Optionally specify a node group and a core group. Click OK. |
![]() |
A z/OS system, but is on a different sysplex than the deployment manager | Specify a node group that contains nodes from the same sysplex as the node you are adding. If no such node group exists, create a node group and then specify that node group. Optionally specify a core group. Click OK. |
The distributed platform or the IBM i platform | A z/OS system | Specify a node group that contains nodes from the same sysplex as the node you are now adding. If no such node group exists, create a node group and then specify that node group. Optionally specify a core group. Click OK. |
A z/OS system | The distributed platform or the IBM i platform | Specify a node group that contains distributed nodes. If no such node group exists, create a node group and then specify that node group. Optionally specify a core group. Click OK. |
For the node group option to display, a group other than the default node group must first be created. Likewise, for the core group option to display, a group other than the default core group must first be created.
If security is enabled, you can optionally enter the local operating system user name and password under which you will run the service. If you do not specify a user name and password, the service runs under the local system identity. When you run remove the node, the node agent is de-registered as a Window service.
Join subsequent WebSphere Application Server for z/OS nodes from the same sysplex to the same
sysplex node group. If you add WebSphere Application Server for z/OS nodes from different sysplexes to the same
cell, establish a separate sysplex node group for the nodes of each
sysplex.
Both Internet Protocol Version
4 (IPv4) and Internet Protocol Version 6 (IPv6) are now supported
by WebSphere Application Server, but restrictions
do apply when using both IPv4 and IPv6 in the same cell. When you
add a node to a cell, the format in which you specify the name is
based on the version of IP that the node is using. For details, see IP version considerations for
cells.
0000004d ORBRas E com.ibm.ws.security.orbssl.WSSSLClientSocketFactoryImpl
createSSLSocket ProcessDiscovery : 0 JSSL0080E: javax.net.ssl.SSLHandshakeException -
The client and server could not negotiate the desired level of security.
Reason?com.ibm.jsse2.util.h: No trusted certificate found
gotchaIf the discovery protocol that a node uses is not appropriate for the node, select the appropriate protocol.
User Datagram Protocol (UDP) is faster than Transmission Control Protocol (TCP). However, TCP is more reliable than UDP because UDP does not guarantee the delivery of datagrams to the destination. The default of TCP is the recommended value.
For a node agent or deployment manager, use TCP or UDP.
A managed process uses multicast as its discovery protocol. The discovery protocol is fixed for a managed process. The main benefit of using multicast on managed processes is efficiency for the node agent. Suppose you have forty servers in a node. A node agent that uses multicast sends one broadcast to all forty servers. If a node agent did not use multicast, it would send discovery queries to all managed processes one at a time, totaling forty sends. Additional benefits of using multicast are that you do not have to configure the discovery port for each server or prevent port conflicts because all servers in one node listen to one port instead of to one port for each server.
On the Windows operating
system, multicast requires a router. If you run the product on a Windows operating system, but
the machine the Application Server is on is not connected to the network,
the multicast address is not shared with the application servers.
After you add a managed node or change a managed node configuration, synchronize the node configuration. On the Node agents page, ensure that the node agent for the node is running. Then, on the Nodes page, select the check box beside the node whose configuration files you want to synchronize and click Synchronize or Full Resynchronize.
Clicking either option sends a request to the node agent for that node to perform a configuration synchronization immediately, instead of waiting for the periodic synchronization to occur. This action is important if automatic configuration synchronization is disabled, or if the synchronization interval is set to a long time, and a configuration change is made to the cell repository that needs to replicate to that node. Settings for automatic synchronization are on the File synchronization service page.
Synchronize requests that a node synchronization operation be performed using the normal synchronization optimization algorithm. This operation is fast, but might not fix problems from manual file edits that occur on the node. It is still possible for the node and cell configuration to be out of synchronization after this operation is performed.
Full Resynchronize clears all synchronization optimization settings and performs configuration synchronization anew, so there is no mismatch between node and cell configuration after this operation is performed. This operation can take longer than the Synchronize operation.
Unmanaged nodes cannot be synchronized.
On the Nodes page, select the check box beside the managed node whose servers that you want to stop running, and click Stop.
You can recover an existing damaged node using one of the options to add a managed node. The node must be at the deployment manager level.
For example, suppose the myNode01 node that has the profile name AppSrv01 stops functioning. To replace it with a new node, create an application server profile named AppSrv01 for node myNode01.
You can find the port number in the console of the new application server node. Click Servers > Server Types > WebSphere application servers > server_name > Ports. For example, for a SOAP connector port type, specify the SOAP_CONNECTOR_ADDRESS value for the JMX connector port number.
Also, you
can find the port number in the serverindex.xml file
of the new profile that is replacing the damaged one. The serverindex.xml file
is in the profiles/new_profile_name/config/cells/cell_name/nodes/node_name directory.
For example, for a SOAP connector port type, specify the port value
that is associated with endPointName="SOAP_CONNECTOR_ADDRESS" in
the serverindex.xml file.
Instead of using the Recover managed node console page to recover a node, you can run the addNode command with the -asExistingNode option from a command line at the bin directory of the damaged application server profile. The name of the new node must match the name of the node where you run addNode with the -asExistingNode option.
You can also use the -asExistingNode option of the addNode command to move a node to a product installation on a different computer but at the same path, to move a node to a product installation on a different operating system or with a different path, or to create new cells from a template cell. See the topic on recovering or moving nodes with the addNode -asExistingNode command.
On the Nodes page, select the check box beside the node that you want to delete and click Remove Node. If you cannot remove the node by clicking Remove Node, remove the node from the configuration by clicking Force Delete.
Review the node capabilities, such as the product version through the administrative console. You can also query them through the Application Server application programming interface (API) or the wsadmin tool.
The product versions for WebSphere Application Server are as follows: The base edition of WebSphere Application Server is listed in the version column as Base. The express edition of WebSphere Application Server is listed in the version column as Express. The WebSphere Application Server, Network Deployment product is listed in the version column as ND.
If you changed a node configuration, examine the configuration changes.