About this task
New feature: Use the
-asExistingNode option
of the
addNode command to quickly recover a damaged
node, 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
cells from a template cell.
newfeat
The following procedures describe
how to use the -asExistingNode option:
Avoid trouble: Other
addNode options
for node configuration are incompatible with this
-asExistingNode option.
Do not use
-asExistingNode with the following incompatible
options:
- -includeapps
- -includebuses
- -startingport
- -portprops
- -nodeagentshortname
- -nodegroupname
- -registerservice
- -serviceusername
- -servicepassword
- -coregroupname
- -excludesecuritydomains
gotcha
When
the addNode command is run
with the -asExistingNode option, the product does
not check for or resolve conflicts among ports. You must verify that
the ports associated with a node do not conflict with ports that are
already in use on the target host.
- Recover an existing managed node of a deployment
manager.
You can recover an existing damaged node using
the -asExistingNode option of the addNode command.
For example, if a computer failure results in an unavailable node
but node information remains on the deployment manager, you can use
the -asExistingNode option to recreate the unavailable
node.
- Ensure that the existing damaged
node is not running.
Stop the node agent and any application servers that reside on the
node.
- Remove the original profile, and
create a profile to
replace the damaged node and give it the same profile path, profile
name, and node name as the unavailable node. Or, you can create the
profile on a different computer from the original node, if your original
computer is unavailable and you have configured a new computer with
the same host name.
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.
- 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.
- Open a command
prompt and change to the application server profile bin directory.
For example, for the application server profile AppSrv01,
go to the profile_root/AppSrv01/bin directory.
- Run the addNode command with the -asExistingNode option
to replace the application server node with the new node. The following
example command assumes that security is enabled and that the product
requires you to enter a user name and password. For dmgr_host and dmgr_port,
specify the host name and port number of the deployment manager.
addNode dmgr_host dmgr_port -asExistingNode -username user_name -password password
- Synchronize all
the other active nodes
in the cell.
To
recover a managed node using a deployment manager administrative
console, see the topic on adding, managing, and removing nodes.
- Move a node to a product installation
on a different computer but at the same path.
You can
use the -asExistingNode option to move a node to
a different computer, provided the following settings are the same
on the different computer:
- WebSphere Application Server installation
directory
- Profile name
- Profile directory
- Node
name
This procedure involves three different profiles:
- The deployment manager profile is
the profile
for the deployment manager. Run the changeHostName command
from the deployment manager profile.
- The source profile is
the original profile
from which you want to move.
- The destination profile is
the profile that
you want to move to on the different computer.
- Ensure that the node you want to move, the
source profile,
is not running. Stop the node agent and any application servers that
reside on the node.
- Change the host name
of the node within the master configuration
present at the deployment manager.
Perform the following
steps, which involve the deployment manager profile:
- Open
a command prompt and change to the deployment manager profile bin directory.
For example, if the deployment manager profile is named Dmgr01,
go to the profile_root/Dmgr01/bin directory.
- Run wsadmin Jython commands that change the host name of the node.
The following example commands assume that security is enabled and
that the product requires you to enter a user name and password. For new_host_name,
specify the host name of the target computer.
wsadmin -lang jython -userName user_name -password password
AdminTask.changeHostName('[-hostName new_host_name -nodeName node_name]')
AdminConfig.save()
quit
- Move the
node from the product installation on the source
computer to the product installation on the target computer.
Perform
the following steps, which involve the destination profile, on the
target computer:
- Install WebSphere Application Server in
a directory that has the same name as the product installation directory
on the source computer.
- Create a custom profile that has the
same profile name, profile
directory, and node name as the profile for the node that you want
to move. When creating the custom profile, select to federate the
node later. Do not select to federate the node during profile creation.
- Open a command prompt and change to the application server profile bin directory.
For example, if the application server profile is named AppSrv01,
go to the profile_root/AppSrv01/bin directory.
- Run the addNode command with the -asExistingNode option
to replace the application server node with the node that you want
to move. The following example command assumes that security is enabled
and that the product requires you to enter a user name and password.
For dmgr_host and dmgr_port,
specify the host name and port number of the target deployment manager.
addNode dmgr_host dmgr_port -asExistingNode -username user_name -password password
- Use the administrative console
of the target deployment
manager or wsadmin to enable servers on the node to run properly.
- Start the node. This step involves the destination profile.
- Update the virtual hosts (host aliases) to include the target
host name of the application server node.
- Start the application
servers of the node.
- If the node uses a Secure Sockets
Layer (SSL) certificate, change the default certificate to contain
the host name of the node.
See the topic on creating
SSL certificates to replace existing certificates in a node.
- Synchronize
all the other active nodes in the cell.
You might need to update the configurations of
other infrastructure
components, such as web servers, that are statically configured to
use application servers residing on specific hosts.
- Move a node to a product installation
on a different operating system or with a different path.
You
can use the -asExistingNode option to move a node
to a product installation on a different computer with the same operating
system, but different host name and path. You can also use the option
to move a node to a product installation on a different computer that
has a different operating system but compatible configuration files;
for example, from an AIX operating system to a Windows operating system.
Restriction: - Applications that use Scheduler only work
with the same host name.
Because the host name is embedded in each scheduled task, tasks that
exist before you move a node will not work properly, but tasks created
after the move will work properly. After you move a node, reschedule
any scheduled tasks that existed when you moved the node.
- You
cannot move nodes between product installations on z/OS and
non-z/OS operating systems.
This task assumes that
the WebSphere Application Server installation
directory
and profile directory on the computer that has the node you want to
move (source computer) is different from the directories on the target
computer. However, the node profile name and node name must be the
same on both the source and target computers.
To complete this
task, perform the steps in the Move a node to a
product installation on a different computer but at the same path task,
except change the product installation and profile paths of each node
in the variable maps on the deployment manager configuration before
moving the node to the target computer. For example:
- In
a deployment manager administrative console, click .
- On the WebSphere Variables page, select the
node scope and then
click the WAS_INSTALL_ROOT variable.
- On
the settings page for the WAS_INSTALL_ROOT variable, change
the Value setting to specify the new product
installation path and save the change.
- On the WebSphere Variables
page, with the node scope selected,
click the USER_INSTALL_ROOT variable.
- On
the settings page for the USER_INSTALL_ROOT variable, change
the Value setting to specify the new profile
installation path and save the change.
- Repeat these steps
as needed to change the product installation
and profile paths of each node so that the paths are correct for the
target computer.
For this task, the product installation
and profile directories
do not need to be the same on the target computer as on the source
computer.
- Create a cell
from a template cell.
You
can quickly create a cell from an existing cell using the -asExistingNode option
of the addNode command. The new cell must have
the same name as the template cell.
Restriction: - Scheduler
application does not work with multiple environments.
Because the host name is embedded in each scheduled task, tasks that
exist before you move a node will not work properly, but tasks created
after the move will work properly. After you move a node, reschedule
any scheduled tasks that existed when you moved the node.
- You
must assess whether different resources, such as data sources,
are required for each environment.
If security
is enabled, you likely must regenerate
new keys and tokens for a new cell.
- Create
and configure a cell to be the template cell
that you want to use for new product installations.
- Make a copy of the deployment manager profile configuration
using the backupConfig command. You will use this
copy of the configuration to restore the deployment manager configuration
in the new installation.
- Copy the template
cell to a new product installation.
For each new environment
to be provisioned, complete the
following steps:
- Install WebSphere Application Server.
- Create
the deployment manager and application server node profiles.
- Restore
the deployment manager profile configuration using the restoreConfig command.
Update the deployment manager host name using wsadmin in local mode.
If the profile path or the product installation path has changed,
modify the variables.xml file of the deployment
manager node to reflect the new paths. Update additional properties
files as needed. Properties files that you might need to update include,
for example, wsadmin.properties and soap.client.props.
- Customize each node configuration on the deployment manager profile.
For example, change the following settings:
- Host
name
- Ports
- Product installation directory
- Profile
directories
- Security configuration
- Run addNode
–asExistingNode for each node.
You can run the command concurrently from each node.
- Open a
command prompt and change to the application server profile bin directory.
For example, if the application server profile is named AppSrv01,
go to the profile_root/AppSrv01/bin directory.
- Run the addNode command with the -asExistingNode option
to replace the application server node with the node on the target
cell. The following example command assumes that security is enabled
and that the product requires you to enter a user name and password.
For dmgr_host and dmgr_port,
specify the host name and port number of the target deployment manager.
addNode dmgr_host dmgr_port -asExistingNode -username user_name -password password
- Use the administrative
console of the new deployment
manager or wsadmin to enable servers for each node to run properly.
- Start the node. Run the startNode command
from
the node profile.
- Update the virtual hosts (host aliases)
to include the host name
of the application server node.
- Start the application servers
of the node.
-
If the cell uses a Secure Sockets
Layer (SSL) certificate, replace the self-signed root certificate
in the root keystore, DmgrDefaultRootStore.
See the
topic on creating SSL certificates to replace existing certificates
in a cell.
- Synchronize
all the other active nodes in the cell.