Managed and unmanaged nodes
A node is a logical grouping of managed servers.
A node usually corresponds to a logical or physical computer system with a distinct IP host address. Nodes cannot span multiple computers.
By default, node names are based on the host name of the computer, for example
Nodes can be managed or unmanaged. An unmanaged node does not have a node agent or administrative agent to manage its servers, whereas a managed node does. Both application servers and supported Web servers can be on unmanaged or managed nodes.
A stand-alone application server is an unmanaged node. The application server node becomes a managed node when it is either federated into a cell or registered with an administrative agent.
When you create a managed node by federating the application server node into a deployment manager cell, a node agent is automatically created. The node agent process manages the application server configurations and servers on the node.
When you create a managed node by registering an application server node with an administrative agent, the application server must be an unfederated application server node. The administrative agent is a single interface that monitors and controls one or more application server nodes so that you can use the application servers only to run your applications. Using a single interface reduces the overhead of running administrative services in every application server.
A managed node in a cell can have WebSphere Application Server, Java Message Service (JMS) servers (on Version 5 nodes only), Web servers, or generic servers. A managed node that is not in a cell, but is instead registered to an administrative agent, can have application servers, web servers, and generic servers on the node.
Federating nodes to a cell
A custom profile defines a node that can be added to a cell. The
addNode command is used to federate a
node in a custom profile to a cell.
A stand-alone application server can also be federated to a cell with the
addNode command, or from the
deployment manager administrative console. The administrative console invokes the
addNode command on the
When you federate a node, the node name from the federated node is used as the new node name and must be unique in the
cell. If the name of the node that you are federating already exists, the
addNode operation will fail.
addNode command syntax
The syntax of the
addNode command is shown below:
addNode dmgr_host [dmgr_port] [-conntype <type>] [-includeapps] [-includebuses] [-startingport <portnumber>] [-portprops <qualified-filename>] [-nodeagentshortname <name>] [-nodegroupname <name>] [-registerservice] [-serviceusername <name>] [-servicepassword <password>] [-coregroupname <name>] [-noagent] [-statusport <port>] [-quiet] [-nowait] [-logfile <filename>] [-replacelog] [-trace] [-username <username>] [-password <pwd>] [-localusername <localusername>] [-localpassword <localpassword>] [-profileName <profile>] [-excludesecuritydomains] [-help]
dmgr_host, -username, -password
This command connects to the deployment manager, so you have to specify the deployment manager host name and a user ID/password with administrative privileges on the deployment manager.
The default is to connect to the deployment manager using SOAP and port 8879. If your deployment manager was defined with this port, you do not need to specify anything. If not, you can specify the correct port, or you can use RMI as the connection type.
For SOAP connections, the port defined as the
SOAP_CONNECTOR_PORT number on the deployment manager must
be specified. If you choose to use an RMI connection instead, the
ORB_LISTENER_ADDRESS port must be
specified. You can see these in the port list of the deployment manager in the administrative console.
Tip: Port numbers are also stored in
-startingport, -portprops <filename>
The new node agent is assigned a range of ports automatically. If you want to specify the ports for the node rather
than taking the default, you can specify a starting port using the
-startingport parameter. The numbers
are incremented from this number.
For example, if you specify 3333, the
BOOTSTRAP_ADDRESS port will be 3333,
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS will be 3334, and so on.
As an alternative, you can provide specific ports by supplying a file with the port properties.
If you are federating an application server, you can keep any applications that are deployed to the server and you can keep any service integration bus definitions that have been created. The default is that these are not included during federation and are lost.
addNode command performs the following actions:
Connects to the deployment manager process. This is necessary for the file transfers performed to and from the deployment manager in order to add the node to the cell.
Attempts to stop all running application servers on the node.
Backs up the current stand-alone node configuration to the
Copies the stand-alone node configuration to a new cell structure that matches the deployment manager structure at the cell level.
Creates a new local config directory and definition (
server.xml) for the node agent.
Creates entries (directories and files) in the master repository for the new node's managed servers, node agent, and application servers.
Uses the FileTransfer service to copy files from the new node to the master repository.
Uploads applications to the cell only if the
-includeapps option is specified.
Performs the first file synchronization for the new node. This pulls everything down from the cell to the new node.
Fixes the node's
wsadmin scripts to reflect the new cell environment settings.
Launches the node agent (unless
-noagent is specified).
Federating a custom node to a cell
Note: You only have to do this if you created a custom profile and chose not to federate it at the time. This requires that you have a deployment manager profile and that the deployment manager is up and running.
To federate the node to the cell, do the following actions:
Start the deployment manager.
Open a command window on the system where you created the custom profile for the new node. Switch to the
profile_root/bin directory or
Example of using the
addNode command on a Windows system to add
Node01 to the
deployment manager using
8879 as the SOAP connector address:
C:\WebSphere\AppServer\profiles\Custom01\bin>addNode localhost 8879
Open the deployment manager administrative console and view the node and node agent:
Select "System Administration > Nodes". You should see the new node.
Select "System Administration > Node agents". You should see the new node agent and its status.
The node is started as a result of the federation process. If it does not appear to be started in the console, you can check the status from a command window on the node system:
cd profile_root/bin serverStatus -all
If you find that it is not started, start it with this command:
cd profile_root/bin startNode
Federating an application server profile to a cell
If you are using the administrative console to federate an application server, keep in mind the following considerations:
Both the deployment manager and the application server must be running.
You need to be logged into the console with an ID that has administrator privileges.
The command will connect to the application server. This requires you to specify the application server host name and a user ID that can connect to the server. In turn, the node has to connect to the deployment manager. Specify a user ID and password for this connection.
You need to specify the host name, JMX connection type, and port number to use to connect to the application server. The JMX connection type can be SOAP or RMI. The default is a SOAP connection using port 8880.
To federate an application server profile to a cell, do the following steps:
Ensure that the application server and deployment manager are running.
Open the deployment manager administrative console.
Select "System Administration > Nodes > Add Node".
Select "Managed node" and click "Next".
Enter the host name and SOAP connector port of the application server profile.
If you want to keep the sample applications and any other applications you have installed, check the "Include applications" box.
Enter the administrator user ID and passwords for both the application server and the deployment manager.
If the node is a Windows node, you have the opportunity to register the new node agent as a Windows service. Make your selection and click "OK".
The federation process stops the application server. It creates a new node agent for the node, and adds the node to the cell. The federation process then starts the node agent, but not the server.
You can now display the new node, node agent, and application server from the console. You can also start the server from the console.
At the completion of the process:
The profile directory for the application server still exists and is used for the new node.
The old cell name for the application server has been replaced in the profile directory with the cell name of the deployment manager.
A new entry in the deployment manager profile directory has been added for the new node.
An entry for each node in the cell is added to the application server profile
configuration. Each node entry contains the
serverindex.xml file for the node.
In turn, an entry for the new node is added to the nodes directory for each node in the cell with a
serverindex.xml entry for the new node.
Example of using the
addNode command to add an application server profile to a cell. The command specifies
the deployment manager host (
host60) and the SOAP connector port (8882). Applications currently installed on the application
server will still be installed on the server after federation:
C:\WebSphereV7\AppServer\bin>addNode host60 8882 -profileName node40b -includeapps -username admin -password adminpwd
Managing profiles using the graphical user interface
You can create profiles, which define runtime environments, using the Profile Management Tool. Using profiles instead of multiple product installations saves disk space and simplifies updating the product because a single set of core product files is maintained.
The Profile Management Tool is the graphical user interface for the
NOTE: You cannot use the Profile Management Tool to create profiles for WebSphere Application Server installations on 64-bit architectures except on the Linux for zSeries platform. However, you can use the Profile Management Tool on other 64–bit architectures if you use a WebSphere Application Server 32–bit installation.
Create a cell profile.
With a cell profile, you can create a deployment manager profile and a profile for a federated application server node in a single pass through the Profile Management tool. Use the cell profile creation option to create the deployment manager profile and the federated application server node profile, unless you have a specific reason to create them separately.
After you install the Network Deployment product and apply the feature pack, you can create two different types of cell profiles: one that is enabled for the Network Deployment product only or one that is also enabled for the feature pack.
Create a management profile with a deployment manager server.
With a deployment manager you can create the administrative node for a multinode, multi-machine group of application server nodes that you create later. This logical group of application server processes is known as a cell.
After you install the Network Deployment product and apply the feature pack, you can create a management profile with a deployment manager that is enabled for the Network Deployment product only or a deployment manager profile that is enabled for the feature pack.
Create a management profile with an administrative agent server.
You can create a management profile for the administrative agent to administer multiple application servers that run customer applications only. The administrative agent provides a single administrative console to administer the application servers.
After you install the Network Deployment product and apply the feature pack, you can create a management profile with an administrative agent that is enabled for the Network Deployment product only or an administrative agent profile that is enabled for the feature pack.
Create a management profile with a job manager server.
You can create a management profile for the job manager to coordinate administrative actions among multiple deployment managers, administer multiple unfederated application servers, asynchronously submit jobs to start servers, and a variety of other tasks.
Create an application server profile.
Create an application server profile so that you can make applications available to the Internet or to an intranet, typically using Java technology.
After you install the Network Deployment product and apply the feature pack, you can create two different types of application server profiles: one that is enabled for the Network Deployment product only or one that is also enabled for the feature pack.
Create a custom profile.
A custom profile is an empty node that you can customize through the deployment manager to include application servers, clusters, or other Java processes, such as a messaging server. Create a custom profile on a distributed machine and add the node into the deployment manager cell to get started customizing the node.
After you install the Network Deployment product and apply the feature pack, you can create two different types of custom profiles: one that is enabled for the Network Deployment product only or one that is also enabled for the feature pack.
Create a secure proxy profile.
You can create a secure proxy profile to serve as the initial point of entry into your enterprise environment. Typically, a secure proxy server exists in the DMZ, accepts requests from clients on the Internet, and forwards the requests to servers in your enterprise environment.