Upgrading Clusters and Node Agent Configurations

This section explains additional steps you need to perform when upgrading cluster and node agent configurations from Application Server or Enterprise Server to GlassFish Server 3.1.

GlassFish Server 3.1 does not support node agents. As part of the upgrade process, any node agent elements in the older source configuration are transformed into CONFIG node elements in the domain.xml file for the upgraded DAS. If the source node agent configuration is incompatible with your GlassFish Server 3.1 installation, you must correct the node configuration on the upgraded DAS.

In addition, although the source cluster configuration is retained in the domain.xml file for the upgraded DAS, it is still necessary to install GlassFish Server 3.1 on each node host and manually re-create the server instances that are contained in the clusters.

The following topics are addressed here:

Overview of Cluster and Node Agent Upgrade Procedures
To Correct the Configuration of a Node After an Upgrade
To Re-Create a Cluster

Overview of Cluster and Node Agent Upgrade Procedures

The general steps for upgrading a cluster and node agent configuration so it will work in GlassFish Server 3.1 are as follows:

Perform a side-by-side upgrade of the DAS. This procedure is described in Performing a Side-By-Side Upgrade With Upgrade Tool.
Perform new (not upgrade) GlassFish Server 3.1 installations on each node host. GlassFish Server 3.1 installation instructions are provided in the Oracle GlassFish Server 3.1 Installation Guide.
Correct the node configuration on the upgraded DAS, if necessary. This procedure is described in To Correct the Configuration of a Node After an Upgrade.
Re-create the clusters and server instances on each GlassFish Server 3.1 node host. This procedure is described in To Re-Create a Cluster.

To Correct the Configuration of a Node After an Upgrade

As part of the upgrade process, node agent elements in the DAS configuration are transformed into GlassFish Server node elements of type CONFIG. This transformation does not affect the node agent directories for GlassFish Server instances. To create the equivalent directories for GlassFish Server instances after an upgrade, you must re-create the instances as explained in To Re-Create a Cluster.

The name of an upgraded node is the name of the node agent from which the node is transformed.

The host that the node represents is obtained from the configuration of the original node agent or, if not specified, is not set. If the configuration of the original node agent did not specify the name of the node host, you must update the node to specify the host that the node represents.

Default values are applied to the remainder of the node's configuration data.

The default values of the following items in a node's configuration data might not meet your requirements for the upgraded installation of GlassFish Server:

The parent of the base installation directory of the GlassFish Server software on the host, for example, /export/glassfish3.

The default is the parent of the default base installation directory of the GlassFish Server 3.1 software on the DAS host. If the GlassFish Server software is installed under a different directory on the node host, you must update the node's configuration to specify the correct directory.
The directory that will contain the GlassFish Server instances that are to reside on the node.

The default is as-install/nodes, where as-install is the base installation directory of the GlassFish Server software on the host. If you require the instances to be contained in a different directory, you must update the node's configuration to specify that directory.

If you are using secure shell (SSH) for centralized administration, you must also change the type of the node to SSH to enable the node for remote communication.

For more information about GlassFish Server nodes, see Chapter 3, Administering GlassFish Server Nodes, in Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide.

Before You Begin

Ensure that the following prerequisites are met:

A side-by-side upgrade on the DAS has been performed. For more information, see Performing a Side-By-Side Upgrade With Upgrade Tool.
If you are changing the type of the node to SSH, ensure that SSH is configured on the host where the DAS is running and on the host that the node represents. For more information, see Chapter 2, Setting Up SSH for Centralized Administration, in Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide.
If you are upgrading from an Enterprise Profile configuration that uses NSS authentication, ensure that the procedure in Upgrading Installations That Use NSS Cryptographic Tokens has been performed. GlassFish Server 3.1 does not support NSS authentication.

Ensure that the DAS is running.
Remote subcommands require a running server.
Update the node's configuration data to specify the correct directories and, if necessary, change the type of the node.
Note - Only the options that are required to complete this task are provided in this step. For information about all the options for changing the node's configuration data, see the update-node-ssh(1) help page or the update-node-config(1) help page.
```
asadmin> node-update-subcommand [--installdir install-dir] [--nodedir node-dir] 
[--nodehost node-host] node-name
```
node-update-subcommand
The subcommand to run to update the node.
- If you are leaving the type of the node as CONFIG, run the update-node-config subcommand on the node.
- If you are changing the type of the node to SSH, run the update-node-ssh subcommand on the node.
install-dir

The full path to the parent of the base installation directory of the GlassFish Server software on the host, for example, /export/glassfish3.

node-dir

The path to the directory that will contain GlassFish Server instances that are to reside on the node. If a relative path is specified, the path is relative to the as-install directory.

node-host

The name of the host that the node is to represent after the node is updated.

node-name

The name of the node to update. This name is the name of the node agent from which the node was transformed.

Example 2-2 Correcting the Configuration of a Node After an Upgrade

This example updates the path to the directory that will contain instances that are to reside on the node xk01 to /export/home/gf/nodes. Because this node is transformed from a node agent, the type of the node is CONFIG. Therefore, type of the node is not changed.

asadmin> update-node-config --nodedir /export/home/gf/nodes xk01
Command update-node-config executed successfully.

Next Steps

Re-create the cluster configuration from the older source installation in the new GlassFish Server 3.1 installation in as explained in To Re-Create a Cluster.

To Re-Create a Cluster

This procedure explains how to re-create a clustered GlassFish Server or Enterprise Server configuration for GlassFish Server 3.1.

Before You Begin

Before proceeding with these instructions, ensure that you have completed the following procedures:

Perform the standard upgrade to GlassFish Server 3.1 on the DAS, as described in Performing a Side-By-Side Upgrade With Upgrade Tool.
Perform a new (not upgrade) installation of GlassFish Server 3.1 on each node host. See Oracle GlassFish Server 3.1 Installation Guide for instructions.
Correct the upgraded node configuration, if necessary, as described To Correct the Configuration of a Node After an Upgrade.

Start the upgraded DAS.
```
asadmin> start-domain domain-name
```
If the upgrade succeeded, the migrated cluster configuration exists and the get-health subcommand lists the status of the clustered instances as not running.

Confirm that the cluster configuration exists and contains all its instances.

asadmin> get-health cluster-name

For example, for the sample cluster1 used in this procedure:

asadmin> get-health cluster1
instance1 not started
instance2 not started
Command get-health executed successfully.

Re-create the clustered server instances on each instance host.
The specific commands to use depend on your configuration.
- If remote hosts cannot contact the DAS, export and import the instances' configuration data, as explained in To Resynchronize an Instance and the DAS Offline in Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide.
- If remote hosts can contact the DAS, create each instance individually and resynchronize the instance with the DAS, as explained in the following sections:
  - To Create an Instance Locally in Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide
  - To Resynchronize an Instance and the DAS Online in Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide
Note that the node name matches that used for the node agent in the 2.x installation. If you get an error stating that some attributes do not match the values in the DAS configuration, follow the instructions in To Correct the Configuration of a Node After an Upgrade.
After creating the instances, manually copy the instance-dir/imq directory for each instance from the older source installation to the target GlassFish Server 3.1 installation.
If necessary, start the cluster.
For example:
```
asadmin> start-cluster cluster1
```
This step may or may not be necessary, depending on the procedure you used to create the server instances for the cluster.

Example 2-3 Creating Two Local Instances

The following example shows how to create two local instances in a cluster.

host1$ asadmin --host dashost create-local-instance --node na1 --cluster cluster1 instance1
host2$ asadmin --host dashost create-local-instance --node na2 --cluster cluster1 instance2

dashost: The name of the DAS host.
na1: The name of the node host.
cluster1: The name of the cluster.
instance1, instance2: The names of the instances.

Skip Navigation Links
Exit Print View
	Oracle GlassFish Server 3.1 Upgrade Guide