Adding, managing, and removing nodes

We 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. We can add both managed and unmanaged nodes to the WAS topology. If we add a new node for an existing WebSphere Application Server to the network deployment cell, we add a managed node. If we create a new node in the topology for managing web servers or servers other than WebSphere Application Servers, we add an unmanaged node.

We 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 console navigation tree.

Manage nodes on an application server through the wsadmin scripting tool, through the Java APIs, or through the console. Perform the following tasks to manage nodes on an application server through the console.

• Add a node.

• Select the discovery protocol.

• Define a custom property for a node.

• Specify a default software development kit for servers on a node.

• Synchronize the node configuration.

• Stop servers on a node.

• Recover an existing managed node of a deployment manager cell.

• Remove a node.

• View node capabilities.

Restriction: The addNode function in the console might fail on non-English, single-byte Windows operating systems when there are non-ASCII characters in the profile name, cell name, or node name. This problem is caused by a code page issue on Windows operating systems. To work around this problem, run the addNode command from the command line rather than from the console on non-English, single-byte Windows operating systems if there are non-ASCII characters in the profile name, cell name, or node name.

• Add a node.

  1. Go to the Nodes page and click Add Node.

  2. On the Add Node page, choose whether to add a managed or unmanaged node, and click Next.

  3. For a managed node...

     1. (dist)(zos) Verify that an application server is running on the remote host for the node that you are adding.

     2. (iseries) Verify that an application server is running on the host for the node that you are adding.

     3. Specify a host name, connector type, and port for the application server at the node you are adding. Perform one of the following sets of actions listed in the table:

        If the deployment manager is on	And the node that we add to the cell is on	Complete the appropriate set of actions:
        (dist)(iseries) The distributed platform or the IBM i platform	The distributed platform or the IBM i platform	Optionally specify a node group and a core group. Click OK.
        (zos) A z/OS system	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.
        (zos) A z/OS system	A z/OS system, but is on a different sysplex than the deployment manager	Specify a node group containing 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 containing 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 containing 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.

     4. (dist)(zos) For managed nodes, another console page is displayed on a Windows operating system. Specify on the page whether to register the node agent to run as a Windows service.

        If security is enabled, we can optionally enter the local operating system user name and password under which you will run the service. If we 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.

  4. For an unmanaged node, on the Nodes > New page, specify a node name, a host name, and a platform for the new node. Click OK.
  The node is added to the WAS environment and the name of the node is displayed in the collection on the Nodes page.

  (zos) Join subsequent WebSphere Application Server for z/OS nodes from the same sysplex to the same sysplex node group. If we 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 we add a node to a cell, the format in which specified the name is based on the version of IP that the node is using. For details, see IP version considerations for cells. On completing this step, you will have added one or more nodes.

  When nodes are added while LDAP security is enabled, the following exception is generated in the deployment manager System.out log under certain circumstances. If this happens, restart the deployment manager to resolve the problem.

  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 level of security we want. Reason?com.ibm.jsse2.util.h: No trusted certificate found

  gotcha

• Select the discovery protocol.

  If the discovery protocol that a node uses is not appropriate for the node, select the appropriate protocol.

  1. On the Nodes page, click the node to access the node setting page.

  2. Select a value for Discovery protocol.

  3. Click OK.

  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 we 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 we 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.

  (dist) On the Windows operating system, multicast requires a router. If we 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.

• Define a custom property for a node.

  1. On the Nodes page, click the node for which to define a custom property.

  2. On the node settings page, click Custom Properties.

  3. On the Property collection page, click New.

  4. On the Custom property settings page, specify a name-value pair and a description for the property, and click OK.

• Specify a default software development kit for a node.

  New feature:

  We can select the default SDK for a node on the Java SDKs page of the console. The page lists all software development kits that are installed on the node. A node can have one default SDK. Servers on the node use the default SDK unless a server overrides the SDK selection and specifies a different SDK.newfeat

  1. Go to the Java SDKs page. Click System administration > Nodes > node > Java SDKs.

  2. On the Java SDKs page, select the check box beside the SDK we want servers on the node to use and click Make Default.

• Synchronize the node configuration.

  After we 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 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.

• Stop servers on a node.

  On the Nodes page, select the check box beside the managed node whose servers to stop running, and click Stop.

• Recover an existing managed node of a deployment manager cell.

  We 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.

  1. Ensure that the existing damaged node is not running. Stop the node agent and any application servers residing on the node.

  2. Create a profile to replace the damaged node and give it the same profile and node names.

     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.

  3. Start the new node, or application server, to use to replace the damaged node.

  4. Use the Recover managed node page to replace the damaged node in the cell with the new node.

     1. In the dmgr console, click System administration > Nodes > Add Node > Recover an existing node > Next.

     2. For Host, specify the host name or IP address of the node to add to the cell. The host value can be an IP address, a domain name server (DNS) name that resolves to an IP address, or the word localhost if the application server is running on the same machine as the deployment manager.

     3. For JMX connector type, select the type of JMX (JMX) connectors that communicate with the product when you run a script.

     4. For JMX connector port, specify the port number of the JMX connector of the new node.

        We 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, we 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 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.

     5. Specify values for the remaining fields as needed and click OK.

  Instead of using the Recover managed node console page to recover a node, we 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.

  We 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.

• Remove a node.

  On the Nodes page, select the check box beside the node to delete and click Remove Node. If we cannot remove the node by clicking Remove Node, remove the node from the configuration by clicking Force Delete.

• View node capabilities.

  Review the node capabilities, such as the product version through the console. We can also query them through the Application Server (API) or wsadmin.sh.

  The product versions for WebSphere Application Server are as follows: The base edition of WAS is listed in the version column as Base. The express edition of WAS is listed in the version column as Express. The WebSphere Application Server Network Deployment product is listed in the version column as ND.

What to do next

If we changed a node configuration, examine the configuration changes.

Subtopics

• Recovering or moving nodes with the addNode -asExistingNode command
  We can use the -asExistingNode option of the addNode command to recover and move nodes of a deployment manager. Using the -asExistingNode option, federate a new custom node to a deployment manager as an existing node. During federation, the product uses information in the deployment manager master configuration to transform the custom node into the existing node.

• Node collection
  Use this page to manage nodes in the WAS environment. Nodes group managed servers. The table lists the managed and unmanaged nodes in this cell. The first node is the deployment manager. Add new nodes to the cell and to the list by clicking Add Node.

• Add managed node settings
  A managed node is a node with an application server and a node agent that belongs to a deployment manager cell. Use this page to add an application server node to a deployment manager cell.

• Recover managed node settings
  Use this page to recover an existing managed node of a deployment manager cell. The node must be at the deployment manager level.

• Node installation properties
  Use this page to view read-only installation properties for this node. These properties provide information about the capabilities of the node that are collected during product installation time, such as the operating system name, architecture and version, or WebSphere Application Server product levels that are installed on the node.

• Java SDK collection
  Use this page to specify the default SDK for a node. This page lists the software development kits that are installed on the node. A node can have one default SDK. Servers on the node use the default SDK unless a server overrides the SDK selection and specifies a different SDK.

Related concepts

Managed and unmanaged nodes

Node groups

Managed object metadata

Related tasks

Get started with wsadmin scripting

Core group servers collection

Custom property settings