Network Deployment (Distributed operating systems), v8.0 > Secure applications and their environment > Authenticate users > Select an authentication mechanism > Configure LTPA and working with keys > 2. Generate keys manually or automatically, and control the number of active keys. > Work with nodes - groups of managed servers > Manage nodes

Recover or move nodes with the addNode -asExistingNode command

We can use the -asExistingNode option of addNode.sh to recover and move nodes of a dmgr. Using the -asExistingNode option, federate a new custom node to a dmgr as an existing node. During federation, the product uses information in the dmgr master configuration to transform the custom node into the existing node.

This topic assumes that a WAS ND has a dmgr with one or more managed nodes.

New feature: Use the -asExistingNode option of addNode.sh 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.New feature:

The following procedures describe how to use the -asExistingNode option:

• Recover an existing managed node of a dmgr.
• Move a node to a product installation on a different computer but at the same path.
• Move a node to a product installation on a different operating system or with a different path.
• Create a cell from a template cell.

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

When addNode.sh is run with the -asExistingNode option, the product does not check for or resolve conflicts among ports. We must verify that the ports associated with a node do not conflict with ports that are already in use on the target host.

Procedure

• Recover an existing managed node of a dmgr.

  We can recover an existing damaged node using the -asExistingNode option of addNode.sh. For example, if a computer failure results in an unavailable node but node information remains on the dmgr, you can use the -asExistingNode option to recreate the unavailable node.

  1. Ensure that the existing damaged node is not running. Stop the node agent and any application servers that reside on the node.
  2. 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 we have configured a new computer with the same host name.

     For example, suppose the node1 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 node1.

  3. Run addNode.sh 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.

     1. 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.
     2. Run addNode.sh 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 dmgr.

        addNode dmgr_host dmgr_port -asExistingNode -username user_name -password password 

     Restriction: Previously installed JCA adapters are not stored as part of the WebSphere configuration. After you replace a node, reinstall JCA adapters to enable them to work in the new environment.

     nov2011

  4. Synchronize all the other active nodes in the cell.
     • The easiest and most efficient way to synchronize active nodes is to allow automatic synchronization to run. By default, automatic synchronization is enabled and nodes synchronize themselves at their configured interval.

     • If automatic synchronization is not enabled, you can synchronize the nodes explicitly.

       1. Click System administration > Nodes.

       2. On the Nodes page, select the unsynchronized nodes and click Synchronize.

       If we have more than five unsynchronized nodes, only synchronize five nodes at a time.

  To recover a managed node using a dmgr 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.

  We can use the -asExistingNode option to move a node to a different computer, provided the following settings are the same on the different computer:

  • WAS installation directory
  • Profile name
  • Profile directory
  • Node name

  This procedure involves three different profiles:

  • The dmgr profile is the profile for the dmgr. Run the changeHostName command from the dmgr profile.
  • The source profile is the original profile from which to move.
  • The destination profile is the profile that to move to on the different computer.

  1. Ensure that the node to move, the source profile, is not running. Stop the node agent and any application servers that reside on the node.
  2. Change the host name of the node within the master configuration present at the dmgr.

     Perform the following steps, which involve the dmgr profile:

     1. Open a command prompt and change to the dmgr profile bin directory. For example, if the dmgr profile is named Dmgr01, go to the PROFILE_ROOT/Dmgr01/bin directory.
     2. 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
        

  3. 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:

     1. Install WAS in a directory that has the same name as the product installation directory on the source computer.

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

     3. 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.
     4. Run addNode.sh 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 dmgr.

        addNode dmgr_host dmgr_port -asExistingNode -username user_name -password password 

     Restriction: Previously installed JCA adapters are not stored as part of the WebSphere configuration. After you move a node, reinstall JCA adapters to enable them to work in the new environment.

     nov2011

  4. Use the admin console of the target dmgr or wsadmin to enable servers on the node to run properly.

     1. Start the node. This step involves the destination profile.
     2. Update the virtual hosts (host aliases) to include the target host name of the application server node.

     3. Start the application servers of the node.

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

  6. 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. We 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.
  • We cannot move nodes between product installations on z/OS and non-z/OS operating systems.
  • Previously installed JCA adapters are not stored as part of the WebSphere configuration. After you move a node, reinstall JCA adapters to enable them to work in the new environment.

    nov2011

  This task assumes that the WAS installation directory and profile directory on the computer that has the node 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 dmgr configuration before moving the node to the target computer. For example:

  1. In a dmgr admin console, click Environment > WebSphere variables .

  2. On the WebSphere Variables page, select the node scope and then click the WAS_INSTALL_ROOT variable.

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

  4. On the WebSphere Variables page, with the node scope selected, click the USER_INSTALL_ROOT variable.

  5. 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.
  6. 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 addNode.sh. 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.
  • We must assess whether different resources, such as data sources, are required for each environment.
  • Previously installed JCA adapters are not stored as part of the WebSphere configuration. After you move a node, reinstall JCA adapters to enable them to work in the new environment.

    nov2011

  If security is enabled, you likely must regenerate new keys and tokens for a new cell.

  1. Create and configure a cell to be the template cell to use for new product installations.

  2. Make a copy of the dmgr profile configuration using the backupConfig command. You will use this copy of the configuration to restore the dmgr configuration in the new installation.
  3. Copy the template cell to a new product installation.

     For each new environment to be provisioned, complete the following steps:

     1. Install WAS.

     2. Create the dmgr and application server node profiles.
     3. Restore the dmgr profile configuration using the restoreConfig command. Update the dmgr 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 dmgr 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.
     4. Customize each node configuration on the dmgr profile. For example, change the following settings:
        • Host name
        • Ports
        • Product installation directory
        • Profile directories
        • Security configuration

     5. Run addNode –asExistingNode for each node. We can run the command concurrently from each node.

        1. 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.
        2. Run addNode.sh 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 dmgr.

           addNode dmgr_host dmgr_port -asExistingNode -username user_name -password password 

  4. Use the admin console of the new dmgr or wsadmin to enable servers for each node to run properly.

     1. Start the node. Run the startNode command from the node profile.
     2. Update the virtual hosts (host aliases) to include the host name of the application server node.

     3. Start the application servers of the node.

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

  6. Synchronize all the other active nodes in the cell.

What to do next

Examine the nodes in the target installation to ensure that the node configuration operates properly. If necessary, delete profiles of the source installation.
Managed and unmanaged nodes
Manage nodes
Get started with wsadmin scripting
Create a new SSL certificate to replace an existing one in a node
Create new SSL certificates to replace existing ones in a cell

Related

addNode command
Recover managed node settings
Node collection
Add managed node settings

+

Search Tips   |   Advanced Search