2.7.  Backup and restore configuration including the use of checkpoints.

[Note]

The addNode -asExistingNode command

You can recover or move nodes by using the -asExistingNode option with the addNode.sh command.

You can recover a damaged node as illustrated in figure below. You can use the -asExistingNode option of the addNode.sh command to recover nodes of a deployment manager. By using the -asExistingNode option, you federate a new custom node to a deployment manager as an existing node. During federation, the product uses information in the master configuration of the deployment manager to transform the custom node into the existing node.

Figure 2.14. Recovering a damaged node

Recovering a damaged node


Exporting and importing a configuration archive

You can use the Config Archive Operations command group to export and import server configurations or entire cell configurations as a compressed archive (CAR) file. You can use this capability to replicate server or profile configuration.

The general procedure to use an archived file is:

  1. Export a WebSphere Application Server configuration into a compressed archived file containing the server configuration.

  2. Optionally, extract the files for browsing or updating for use on other systems, for example, you might need to update resource references.

  3. Upload the archive file to the target system.

  4. Import the archive file. The import process requires that you identify the object in the configuration you want to import and the target object in the existing configuration. The target can be the same object type as the archive or its parent. Consider the following information:

    • If you import a server archive to a server configuration, the configurations are merged.

    • If you import a server archive to a node, the server is added to the node.

NOTE: You can use this capability between two application server profiles under the same or different product installations, on the same or different host environments. You can also use this capability to replicate a profile configuration across different platforms, as long as you do not add operating system-specific system properties to your configuration. An exception to this is that configurations of z/OS and distributed platform profiles are not compatible, so you cannot replicate configurations between these platforms.

Profile archive

You can use the exportWasprofile command to export the entire cell configuration to a configuration archive. This archive file can be used to restore the configuration or clone the original profile on another machine or system.

NOTE: Only a base server configuration with a single node is supported by the exportWasprofile command.

The exportWasprofile command in the AdminTask object can be used to export profile configuration. The command executed through wsadmin from the profile_root/bin directory creates an archive of a profile. Example below shows an example of using Jacl to run the command:


[root@saw211-RHEL2 bin]# pwd
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin
[root@saw211-RHEL2 bin]# ./wsadmin.sh
Realm/Cell Name: <default>
Username: admin
Password:
WASX7209I: Connected to process "server1" on node was85AppSrv01 using SOAP
connector;  The type of process is: UnManagedProcess
WASX7029I: For help, enter: "$Help help"
wsadmin>$AdminTask exportWasprofile {-archive /tmp/was85_archive/Node01_archive_0622.car}
wsadmin>

					

The importWasprofile command in the AdminTask object imports and overwrites the profile with the archive file configuration, as shown in example below:


wsadmin>$AdminTask importWasprofile {-archive /tmp/was85_archive/Node01_archive_0622.car -deleteExistingServers true}

wsadmin>$AdminConfig save

					

The -deleteExistingServers parameter is optional. It deletes existing servers from the target profile. Consider that when importing a profile with multiple servers, the node has to contain exactly the same number of servers. If the number of servers is not the same, the following error message occurs:

ADMB0016E: The number of servers in the configuration archive does not match the
number of servers in the system configuration. The product only supports
importWasprofile for profiles with the same number of servers.
					

You can also export and import the proxy profile using the exportProxyProfile and importProxyProfile commands.

Server archive

The exportServer command in the AdminTask object is used to export the server configuration. The command is executed through wsadmin from a profile_root/bin directory on the application server. Example below shows using Jacl to run the command to export server1 (-serverName specified) of node was85AppSrv01 (-nodeName specified):


[root@saw211-RHEL2 bin]# pwd
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin
[root@saw211-RHEL2 bin]# ./wsadmin.sh
Realm/Cell Name: <default>
Username: admin
Password:
WASX7209I: Connected to process "server1" on node was85AppSrv01 using SOAP
connector;  The type of process is: UnManagedProcess
WASX7029I: For help, enter: "$Help help"
wsadmin>$AdminTask exportServer {-archive /tmp/was85_archive/server1_archive_0622.car -nodeName was85AppSrv01 -serverName server1}
wsadmin>

					

This process removes applications from the server that you specify and breaks the relationship between the specified server and the core group of the server, cluster, or bus membership. If you export a single server of a cluster, the relation to the cluster is eliminated in the archive file.

The importServer command of the AdminTask object imports an archived server template from the previous exportServer result. Example below shows using Jacl to run the command for importing an archive into node was85AppSrv01 as server2:


wsadmin>$AdminTask importServer {-archive /tmp/was85_archive/server1_archive_0622.car -nodeInArchive was85AppSrv01 -serverInArchive server1 -nodeName was85AppSrv01 -serverName server2}
server2(cells/saw211-RHEL2Node01Cell/nodes/was85AppSrv01/servers/server2|server.xml#Server_1340371919134)

wsadmin>$AdminConfig save

					

When you use the importServer command, you can specify a source and a target. First run the command and then you can select a configuration object in the archive (-nodeInArchive and -serverInArchive specified) as the source and select a configuration object on the system (-nodeName and -serverName specified) as the target. Figure below shows the Application Server view in the administrative console after importing server2. As you can see, server2 is added to the existing configuration:

Figure 2.15. Import server to existed configuration

Import server to existed configuration


You can also export and import the proxy server using the exportProxyServer and importProxyServer commands.

Moving a node to a different system

You can also use the -asExistingNode option to move the node to a different machine. The procedure overview is shown in figure below:

Figure 2.16. Moving a node to a destination machine

Moving a node to a destination machine


  1. Ensure that the node you want to move, with the source profile, is not running. Stop the node agent and any application servers that reside on the node.

  2. On the deployment manager, change the host name of the node to target machine host name using the AdminTask.changeHostName command.

  3. Install WebSphere Application Server on the new machine at the same directory location.

  4. Create a profile with the original node name and profile name.

  5. Run the addNode -asExistingNode command.

  6. Synchronize nodes in the network manager cell.

Using addNode -asExistingNode to move the node to a different machine involves three different profiles:

You can use the addNode -asExistingNode command to do the following actions:

In the following scenario, we assume that the source and destination targets use the same profile name and node name, but create a different installation directory and profile path:

  1. Stop the node agent or any application server processes on the source profile, and back up the profile. In this example, we use Node=was85Node01 and profile=Node01.

  2. Change the host name of the source profile node within the master configuration present at the deployment manager, as shown in example below. We assume the source machine is saw211-RHEL2 and the destination is saw211-win1.

    
    [root@saw211-RHEL2 bin]# pwd
    /opt/IBM/WebSphere/AppServer/profiles/Dmgr/bin
    [root@saw211-RHEL2 bin]# ./wsadmin.sh -lang jython -username admin -password
    admin
    WASX7209I: Connected to process "dmgr" on node was85Dmgr01 using SOAP connector;  The type of process is: DeploymentManager
    WASX7031I: For help, enter: "print Help.help()"
    wsadmin>AdminTask.changeHostName('[-hostName saw211-win1 -nodeName was85Node01]')
    ''
    wsadmin>AdminConfig.save()
    ''
    
    								

  3. If the target profile has the new product installation and profile paths, include this step (if not, proceed to next step). This step outlines changing 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. The following process outlines the necessary actions for this step:

    1. In a deployment manager administrative console, click Environment > WebSphere variables.

    2. On the WebSphere Variables page, select the node scope as Node=was85Node01 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.

  4. Log in to the destination target machine, and do the following steps:

    1. Install WebSphere Application Server in a directory that has the same name as the product installation directory on the source profile target.

    2. Create a custom profile that has the same profile name and node name as the one that you want to move, and select to federate the node later (if you move the node with the same profile path, keep the profile directory the same):

      manageprofiles.bat -create -profileName Node01 -profilePath C:\IBM\WebSphere\AppServer\profiles\Node01 -nodeName was85Node01 -hostName saw211-win1 -federateLater true
      											

    3. Change your working directory to the newly created profile bin directory:

      C:\IBM\WebSphere\AppServer\profiles\Node01\bin
      											

    4. Run the addNode command with the -asExistingNode option to replace the application server node with the node that you want to move:

      ./addNode.sh dmgr_host dmgr_port -asExistingNode -username user_name -password password
      											 

      results:

      C:\IBM\WebSphere\AppServer\profiles\Node01\bin>addNode.bat saw211-RHEL2 8879 -asExistingNode -username admin -password admin
      ADMU0116I: Tool information is being logged in file
                 C:\IBM\WebSphere\AppServer\profiles\Node01\logs\addNode.log
      ADMU0128I: Starting tool with the Node01 profile
      ...
      ADMU2010I: Stopping all server processes for node was85Node01
      ADMU0024I: Deleting the old backup directory.
      ADMU0015I: Backing up the original cell repository.
      ADMU0016I: Synchronizing configuration between node and cell.
      ADMU0018I: Launching Node Agent process for node: was85Node01
      ADMU0020I: Reading configuration for Node Agent process: nodeagent
      ADMU0022I: Node Agent launched. Waiting for initialization status.
      ADMU0030I: Node Agent initialization completed successfully. Process id is:
      2524
      ADMU0505I: Servers found in configuration:
      ADMU0506I: Server name: Cluter1_Member1
      ADMU0506I: Server name: nodeagent
      ADMU0300I: The node was85Node01 was successfully added to the
      was85DmgrCell01 cell.
      ...
      ADMU0003I: Node was85Node01 has been successfully federated.
      											 

  5. Synchronize the nodes using the deployment manager console by clicking System Administration > Nodes, selecting the unsynchronized nodes, and clicking Synchronize.

  6. Your node is fully operational again in the new target, as shown in figure below. You can remove the source profile directory and its backup.

    Figure 2.17. Nodes view after move node by asExistingNode

    Nodes view after move node by asExistingNode


Professional hosting         Free 'Oracle Certified Expert Web Services Developer 6' Guide     Free SCDJWS 5.0 Guide