The Application Server's Upgrade Tool captures cluster details from the clinstance.conf file, the cluster configuration file. If more than one cluster has been defined for the Application Server 7.x, multiple .conf files could exist prior to the upgrade. The configuration files could have any name, but all would have the .conf file extension. If clusters will be included in an upgrade, consider the following points when you are defining clinstance.conf files. Instance names in the clinstance.conf file must be unique. For example, in Application Server 7.x, machine A could have server1 and server2 participating in a cluster. Machine B could also have a server1 participating in the same cluster. Typically, the clinstance.conf file would include server1 and server2 of machine A and server1 of machine B. Application Server 8.1 requires that instance names in a cluster be unique. Therefore, before you upgrade, in the clinstance.conffile, you would need to rename server1 of machine B to a unique name, such as server3or server1ofmachineB.
You do not have to rename the server1 instance itself in machine B. You only need to rename the server in the clinstance.conf file.
The expectation is that instances participating in the cluster are homogeneous, in the sense that they would have same type of resources and same applications deployed in them. When the upgrade process runs, the instance that is marked as the master instance is picked up for transferring the configuration. If there is no instance marked as the master instance, one of the instances is randomly picked up and used for transferring the configuration. A cluster is created in the DAS, along with instances defined in the clinstance.conf file. All these instances participating in this cluster share the same configuration named cluster_name-config, where the cluster_name is cluster_0 for the first cluster, cluster_1 for the next cluster, and so on. Each instance in the cluster has HTTP and IIOP ports set in their system properties. The HTTP port is the port defined in the clinstance.conf file as the instance port. IIOP ports are selected from the iiop-cluster configuration in the server.xml file.
When you are upgrading Application Server 8.x EE to Application Server 8.2 EE, the upgrade tool automatically detects clusters, if any, on the source installation. There is no need to specify the configuration files, in this case.
Server instances that participate in the cluster and that run on a machine that does not have DAS running on it, are created with a node agent named <host-name>-<domain-name>, where the host-name is the name given in the clinstance.conf file for that particular instance and the domain-name is the name to which this cluster belongs.
Copy the node-agent directory from DAS machine to client machine underinstall-dir/nodeagents/. For example, if your DAS is installed on HostA and client machine name is HostB, the upgrade process would have created a node agent named HostB_<domain_name> as the node agent for HostB. Therefore, copyHostB_<domain_name> from HostA<AS82_install_dir>/nodeagents/HostB_<domain_name> directory to HostB<AS82_install_dir>/nodeagents. After copying, delete the copied node agent directory under HostA.
Start the DAS.
Start the node agent named HostB_<domain_name> on HostB. The node agent with rendezvous with the DAS and the remote instances are created in HostBand the deployed applications are copied over.
If you are performing an in-place upgrade , you do not have to upgrade the node agents. The same node-agent directory can be used with the upgraded binaries. If you are performing a side-by-side upgrade , perform the following steps:
Install Application Server 8.2 EE on Machine B in /opt/SUNWappserver8.2 with the default node agent.
Perform a side-by-side upgrade from the install location of Application Server 8.1 EE.
Install Application Server 8.2 EE on Machine B which has a node agent with remote instances referring to a DAS on machine A. You must install only the node gent on Machine B.
After upgrade, verify the nodeagent.properties file
in Machine A and Machine B for the agent.adminPort property . This file must reflect the same value
as that of the
jmx-connector port in the corresponding node-agent element of the domain.xml file.
If not, edit the nodeagent.properties file accordingly.
Start the DAS on Machine A.
Start the default node agent on Machine A. It starts up with the instance, instance1. The cluster1 cluster is partially started after this step.
On Machine B, start up the default node agent of that remote instance.