New: Incremental cell upgrade

This topic describes the new feature of incremental cell upgrade. The v6.x deployment manager can manage both v6.x and Version 5.x nodes. This allows the cell to be upgraded to a new release one node at a time, with minimal impact to the applications that are running within the cell.

When upgrading to v6.x, there is no need to export the cell configuration and recreate it in a new cell. However, there are limitation and restriction on the node, server, cluster, and application operations in a mixed node environment. This topic introduces the details as they pertain to:

Application serving environment implications

Migration instructions
Migrate the V5.x Deployment Manager to v6.x before migrating the base nodes that comprise the cell. The Network Deployment node must always be at the highest release and fix level within a cell, to allow it to manage all nodes in the cell. In V6.0.x, the deployment manager has the capability to manage both V6.0.x and V5.x release nodes. This allows a cell to be upgraded to a new release one node at a time, with minimal impact to the applications that are running within the cell.
See Migrating Network Deployment, V5.x to a V6 deployment manager for a description of incremental migration of a deployment manager. See Migrating a V5.x managed node to a V6 managed node for a description of incremental migration of a managed node.

Improve performance after completing mixed cell upgrade
If your cluster members in a mixed release cell include V6.0.x clusters and older versions from 5.0 through 5.1.0, there is an Object Request Broker (ORB) custom property of which you should be aware. If running a mixed release cell with V6.0.x and V5.1.1 servers, one can disregard this note.
In appropriate cases, the migration program automatically sets a custom property for the ORB on the 6.0.x deployment manager, node agent, and servers in the cluster. After migrating the entire cell to v6.x, one can reset the property for a performance improvement.
See Object Request Broker custom properties for details about this com.ibm.websphere.ObjectIDVersionCompatibility setting.
See Migrating a V5.x managed node to a V6 managed node for additional guidance.

V5.x nodes can be added and removed from v6.x cells through indirect means
A V5.x node cannot be added to a v6.x cell. However, the same result can be obtained by first upgrading the node to v6.x before adding the node to the v6.x cell.
A V5.x node in a v6.x cell cannot be removed from the cell. The same result can be obtained in either of the following ways:

Upgrade node to 6.0.x, followed by removeNode, or
Uninstall the node, followed by cleanupNode on the dmgr

Administering servers
With WAS v6.x, one can now upgrade a portion of the nodes in a cell, while leaving others at the older release level. This means that, for a period of time, you may be administering servers that are at the current release and servers that are running the newer release in the same cell. Note that in this mixed environment, there are some restrictions on what one can do with servers at the older release level. For details, see Creating application servers.
There also are restrictions on creating clusters and cluster members. For details, see Creating clusters.

Existing 5.x servers and clusters can be maintained, but not expanded
Supported:

Existing 5.x application servers and JMS servers will continue to work.
Removing a server at any version level
Adding a new 6.0.x member to a cluster the mixed cluster already contains a 6.0.x member through migration of one of its members from 5.x to 6.0.x.

Not supported:

Creating new 5.x application servers and JMS servers
Converting a 5.x server to a cluster
Adding a new 5.x member to a cluster that already contains a 5.x server. To add a new member, all cluster members must first be upgraded

v6.x JMS function does not require a JMS server. See the messaging section for details.

Configuration management

Nodes know their version and capabilities
Information about a node, such as operating system platform and product features, is maintained in the configuration repository in the form of properties. As product features are installed on a node, new property settings are added.
An administrator can query a node's capabilities. For more information, see Managed object metadata.

6.0.x configuration files are transformed for consumption by 5.x nodes
The Websphere Application Server master configuration repository stores configuration documents for all the nodes in the cell. Configuration files stored in v6.x format are transformed into V5.x format for consumption by V5.x nodes in the cell.
For additional information, see Transformation of configuration files.

Create backup configurations after upgrading nodes to Version 6.0.x
Suppose you create a backup configuration for a node, using the backupConfig tool. After upgrading the node, one cannot use the restoreConfig command to restore the configuration.
It is recommended that backups be created after upgrade so that they can be used to restore the upgraded nodes.
Similarly, suppose you back up a node configuration, using the backupConfig tool, before upgrading the node. After upgrading the node, you will be unable to use the restoreConfig tool with that backup configuration you created.

Administrative clients

Use 6.0.x administration to modify 5.x and 6.0.x applications
All applications may be updated via reinstallation, editing, or remapping modules to new targets. When remapping a module, the new target for a v6.x module may not be a V5.x target.
When editing an application from a v6.x client, all editing functions are available for all versions of applications. When editing a v6.x application from an V5.x client, the following functions are not available:

Map Message Destination References to Enterprise Beans
Binding J2CObjects to JNDI name
Binding J2CActivation to Destination JNDI name

Administrative clients display only relevant settings, and settings are validated against the node version
When displaying the properties for a node, node agent, or server, the administrative console is aware of the version of the node on which the object resides, and will only display those properties that are valid for that version.
The wsadmin scripting client is also aware of the version of node on which a configuration object resides. An exception is thrown if you attempt to view or modify a property that is not valid for the version. A warning is logged if you attempt to show or modify a property that has been deprecated.

JDBC Provider and DataSource templates provided are at the 6.0.x level
A set of JDBC Provider and DataSource templates are provided for simplifying the creation of data access objects for database vendors supported by WebSphere Application Server. These templates are used when creating JDBC Provider and DataSource objects from the administrative console, or from wsadmin using the createUsingTemplate command. The templates available are based on the version of your deployment manager. Not all templates available in the V6.0x template file are supported on older node levels. When creating new JDBC Providers and DataSources on v5.x nodes, ensure that the template you are using is supported on the WAS release level of your node.
Ensure you do not persist config IDs in your scripts
Due to changes in the allowed format for ObjectName, the config ID in v6.x now contains '|", where as in V5.x ':' is used. This change is reflected in the output for wsadmin clients.
For example, this is the output from a V5.x client
wsadmin>  $AdminConfig list Cell
DefaultCellNetwork
   (cells/DefaultCellNetwork:cell.xml#Cell_1)
This is the output from a v6.x client
wsadmin>  $AdminConfig list Cell
DefaultCellNetwork     
   (cells/DefaultCellNetwork|cell.xml#Cell_1)
The delimiter change is not a problem because config IDs are generated dynamically. However, you should not persist a config ID.
When a V5.x client passes a config ID containing ':', it is automatically transformed into a config ID containing '|' by the JMX runtime for upwards compatibility. Similarly, a reverse transformation is performed for backwards compatibility.
Be aware of deprecated or invalid attributes
A type may be enhanced in v6.x to contain more attributes compared to V5.x. The "$AdminConfig attributes type" command is not version specific. It lists all attributes available in v6.x for the type, even though the new attributes may not be used on a V5.x node.

JMX administrative programs are interoperable across V5.x and 6.0.x
v6.x implements JMX 1.2, while V5.x implements JMX 1.1. Due to the evolution of the JMX specification, the serialization format for JMX objects, such as javax.management.ObjectName differs between the two specifications.
The v6.x JMX runtime has been enhanced to be aware of the version of the client with which it is communicating. It makes appropriate transformations on these incompatible serialized formats so as to allow the different version runtimes to communicate with each other. This makes it possible for a V5.x administrative client can call a v6.x deployment manager, node, or server. Similarly, a v6.x administrative client can call a V5.x node or server.
Instances of JMX classes new in v6.x cannot be passed back into V5.x. Problems usually are signaled by a particular exception. Also, note that you might see different exceptions from your v6.x and V5.x administrative programs.
For additional information, see Java Management Extensions interoperability.

Migration instructions	Migrate the V5.x Deployment Manager to v6.x before migrating the base nodes that comprise the cell. The Network Deployment node must always be at the highest release and fix level within a cell, to allow it to manage all nodes in the cell. In V6.0.x, the deployment manager has the capability to manage both V6.0.x and V5.x release nodes. This allows a cell to be upgraded to a new release one node at a time, with minimal impact to the applications that are running within the cell. See Migrating Network Deployment, V5.x to a V6 deployment manager for a description of incremental migration of a deployment manager. See Migrating a V5.x managed node to a V6 managed node for a description of incremental migration of a managed node.

Improve performance after completing mixed cell upgrade	If your cluster members in a mixed release cell include V6.0.x clusters and older versions from 5.0 through 5.1.0, there is an Object Request Broker (ORB) custom property of which you should be aware. If running a mixed release cell with V6.0.x and V5.1.1 servers, one can disregard this note. In appropriate cases, the migration program automatically sets a custom property for the ORB on the 6.0.x deployment manager, node agent, and servers in the cluster. After migrating the entire cell to v6.x, one can reset the property for a performance improvement. See Object Request Broker custom properties for details about this com.ibm.websphere.ObjectIDVersionCompatibility setting. See Migrating a V5.x managed node to a V6 managed node for additional guidance.

V5.x nodes can be added and removed from v6.x cells through indirect means	A V5.x node cannot be added to a v6.x cell. However, the same result can be obtained by first upgrading the node to v6.x before adding the node to the v6.x cell. A V5.x node in a v6.x cell cannot be removed from the cell. The same result can be obtained in either of the following ways: Upgrade node to 6.0.x, followed by removeNode, or Uninstall the node, followed by cleanupNode on the dmgr

Administering servers	With WAS v6.x, one can now upgrade a portion of the nodes in a cell, while leaving others at the older release level. This means that, for a period of time, you may be administering servers that are at the current release and servers that are running the newer release in the same cell. Note that in this mixed environment, there are some restrictions on what one can do with servers at the older release level. For details, see Creating application servers. There also are restrictions on creating clusters and cluster members. For details, see Creating clusters.

Existing 5.x servers and clusters can be maintained, but not expanded	Supported: Existing 5.x application servers and JMS servers will continue to work. Removing a server at any version level Adding a new 6.0.x member to a cluster the mixed cluster already contains a 6.0.x member through migration of one of its members from 5.x to 6.0.x. Not supported: Creating new 5.x application servers and JMS servers Converting a 5.x server to a cluster Adding a new 5.x member to a cluster that already contains a 5.x server. To add a new member, all cluster members must first be upgraded v6.x JMS function does not require a JMS server. See the messaging section for details.

Nodes know their version and capabilities	Information about a node, such as operating system platform and product features, is maintained in the configuration repository in the form of properties. As product features are installed on a node, new property settings are added. An administrator can query a node's capabilities. For more information, see Managed object metadata.

6.0.x configuration files are transformed for consumption by 5.x nodes	The Websphere Application Server master configuration repository stores configuration documents for all the nodes in the cell. Configuration files stored in v6.x format are transformed into V5.x format for consumption by V5.x nodes in the cell. For additional information, see Transformation of configuration files.

Create backup configurations after upgrading nodes to Version 6.0.x	Suppose you create a backup configuration for a node, using the backupConfig tool. After upgrading the node, one cannot use the restoreConfig command to restore the configuration. It is recommended that backups be created after upgrade so that they can be used to restore the upgraded nodes. Similarly, suppose you back up a node configuration, using the backupConfig tool, before upgrading the node. After upgrading the node, you will be unable to use the restoreConfig tool with that backup configuration you created.

Use 6.0.x administration to modify 5.x and 6.0.x applications	All applications may be updated via reinstallation, editing, or remapping modules to new targets. When remapping a module, the new target for a v6.x module may not be a V5.x target. When editing an application from a v6.x client, all editing functions are available for all versions of applications. When editing a v6.x application from an V5.x client, the following functions are not available: Map Message Destination References to Enterprise Beans Binding J2CObjects to JNDI name Binding J2CActivation to Destination JNDI name

Administrative clients display only relevant settings, and settings are validated against the node version	When displaying the properties for a node, node agent, or server, the administrative console is aware of the version of the node on which the object resides, and will only display those properties that are valid for that version. The wsadmin scripting client is also aware of the version of node on which a configuration object resides. An exception is thrown if you attempt to view or modify a property that is not valid for the version. A warning is logged if you attempt to show or modify a property that has been deprecated.

JDBC Provider and DataSource templates provided are at the 6.0.x level	A set of JDBC Provider and DataSource templates are provided for simplifying the creation of data access objects for database vendors supported by WebSphere Application Server. These templates are used when creating JDBC Provider and DataSource objects from the administrative console, or from wsadmin using the createUsingTemplate command. The templates available are based on the version of your deployment manager. Not all templates available in the V6.0x template file are supported on older node levels. When creating new JDBC Providers and DataSources on v5.x nodes, ensure that the template you are using is supported on the WAS release level of your node.

Ensure you do not persist config IDs in your scripts	Due to changes in the allowed format for ObjectName, the config ID in v6.x now contains '\|", where as in V5.x ':' is used. This change is reflected in the output for wsadmin clients. For example, this is the output from a V5.x client wsadmin> $AdminConfig list Cell DefaultCellNetwork (cells/DefaultCellNetwork:cell.xml#Cell_1) This is the output from a v6.x client wsadmin> $AdminConfig list Cell DefaultCellNetwork (cells/DefaultCellNetwork\|cell.xml#Cell_1) The delimiter change is not a problem because config IDs are generated dynamically. However, you should not persist a config ID. When a V5.x client passes a config ID containing ':', it is automatically transformed into a config ID containing '\|' by the JMX runtime for upwards compatibility. Similarly, a reverse transformation is performed for backwards compatibility.

Be aware of deprecated or invalid attributes	A type may be enhanced in v6.x to contain more attributes compared to V5.x. The "$AdminConfig attributes type" command is not version specific. It lists all attributes available in v6.x for the type, even though the new attributes may not be used on a V5.x node.

JMX administrative programs are interoperable across V5.x and 6.0.x	v6.x implements JMX 1.2, while V5.x implements JMX 1.1. Due to the evolution of the JMX specification, the serialization format for JMX objects, such as javax.management.ObjectName differs between the two specifications. The v6.x JMX runtime has been enhanced to be aware of the version of the client with which it is communicating. It makes appropriate transformations on these incompatible serialized formats so as to allow the different version runtimes to communicate with each other. This makes it possible for a V5.x administrative client can call a v6.x deployment manager, node, or server. Similarly, a v6.x administrative client can call a V5.x node or server. Instances of JMX classes new in v6.x cannot be passed back into V5.x. Problems usually are signaled by a particular exception. Also, note that you might see different exceptions from your v6.x and V5.x administrative programs. For additional information, see Java Management Extensions interoperability.