The Application Server’s Upgrade utility 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 may 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 the server1 and server2 of machine A and server1 of machine B. Application Server 8.1 requires instance names in a cluster to be unique. Therefore, prior to the upgrade, in the clinstance.conf file you would need to rename server1 of machine B to a unique name, such as server3 or server1of machineB. You do not, however, need 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 kind of resources, and same applications deployed in them.
When the upgrade process runs, the instance marked as the master instance will be picked up for transferring the configuration. If there is no instance marked as the master instance, one of the instances will be picked up in a random manner 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 forth. 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.
Server instances that participate in the cluster and that run on a machine other than the machine on which the DAS is running, are created with a node-agent named <host-name>-<domain-name>, where the host-name is the name given in the clisntance.conf file for that particular instance and the domain-name is the name to which this cluster belongs.
After the upgrade process has been completed on the DAS, install Application Server 8.1 on the other machines where clustered instances need to run.
Copy the node-agent directory from DAS machine to client machine under install-dir/nodeagents/. For instance, 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. Hence copy HostB-<domain_name> from HostA<AS81_install_dir>/nodeagents/HostB-<domain_name> directory to HostB <AS81_install_dir>/nodeagents. After copying, delete the copied node agent directory under HostA.
Edit nodeagent.properties file on client machine HostB under agent/config directory. Set agent.client.host to the client machine name. In this case it should be HostB.
Edit das.properties file on client machine HostB under agent/config directory. Make sure agent.das.isSecure=false in das.properties file. It should be set to false if by default Application Server 7.x Administration Server was running on non secure port. If Application Server 7.x Administration Server was running on secure port, then it should be set to true.
Start domain and start node agents on both DAS machine as well as client machines. This in turn will run the clustered instance.