Interoperating with v6.1.2 processes

The high availability manager supports multihomed hosts, which means that WAS processes can communicate with each other even if they are running on different versions of the product. If you are running v6.1.2 processes that need to communicate with each other, there are high availability manager-related issues that you need to consider.

 

Before you begin

Know the version levels of the processes that need to communicate with each other. If no V6.0.1.2 processes exist, see Interoperating with v6.2 and later processes .

 

About this task

In v6.1 without Fix Pack 2 installed, an acceptable value for the DCS_UNICAST_ADDRESS host name field is either a host name, for example, myhost.mydomain, or a textual IP address, for example, 192.168.0.2. If a host name is specified, Domain Name Services (DNS) is used to resolve the host name to an IP address. If the host supports multiple IP addresses, where the host name has multiple mappings in DNS, a host name is ambiguous and a textual IP address is required.

After the installation of v6.1 Fix Pack 2, the asterisk is recognized as a valid value for the DCS_UNICAST_ADDRESS host name field. When this field is set to an asterisk, multihome support allows the high availability manager to open and receive connections on all IP addresses available for the host.

With the introduction of Version 6.0.1 Fix Pack 2, processes can be classified into three separate categories:

Type 1

Processes that can operate only in single-IP mode. This category includes processes on v6 nodes or v6.1 nodes that do not have Version 6.0.1 Fix Pack 2 installed.

Type 2

Processes on v6.1 nodes that have v6.1 Fix Pack 2 installed, but do not have the DCS_UNICAST_ADDRESS host name field for the process set to an asterisk.

Type 3

Processes on v6.1 nodes that have v6.1 Fix Pack 2 installed and have the DCS_UNICAST_ADDRESS host name field for the process set to an asterisk.

The following interoperability rules apply to these process types:

To enable interoperating with v6.1.2 processes:

 

Procedure

  1. Add multihome capability by installing v6.1 Fix Pack 2. This step changes the existing type 1 processes to type 2 processes.

    1. Apply v6.1 Fix Pack 2 to all existing nodes. Nodes on which v6.1 Fix Pack 2 is installed continue to interoperate with nodes on which this fix pack is not installed, as long as the configuration does not change.

  2. Stop all application servers.

  3. Ensure that the deployment manager and all of the node agents are running.

  4. Change the DCS_UNICAST_ADDRESS Host name field of each process to an asterisk. This step changes the existing type 2 processes to type 3 processes.

    1. In the administrative console, go to the configuration data for one of the processes on the new nodes:

      • For an application server, click Servers > Application Servers > servername, and then, under Additional Properties, click > Ports > port_name .

      • For a node agent, click System administration > Node agents > node, and then, under Additional Properties, click > Ports > port_name .

      • For a deployment agent, click System administration > Deployment manager, and then, under Additional Properties, click > Ports > port_name .

    2. Click View associated transports for the port that is associated with the DCS transport channel that you want to review.

    3. Click DCS_UNICAST_ADDRESS, and enter the name of the new host in the Host field.

    4. Click OK, and then click Save.

    5. Repeat the previous steps until the new host name is added for all of the processes on the new nodes.

    6. Select Synchronize changes with nodes, and then click Save again.

  5. Stop all of the servers that contain the processes with configuration changes.

  6. Restart these servers.

 

Results

All of the processes can communicate with each other.

 

What to do next

After multihome support is enabled, all of the new nodes that are added to the installation must have multihome support enabled. The base Version 6.0.1 code and v6.1 Fix Pack 2 must be installed before profiles are created and the node is added. If this procedure is not observed, manual configuration is required to enable the processes to connect.

Your configuration cannot contain a mix of type 1 and type 3 processes. To ensure a valid configuration:

  1. Check for type 1 processes. Type 1 processes log the following message, which indicates that the host name for another process in the core group is an asterisk

    HMGR0024W: An error was encountered while looking up the IP address for 
    the host name of a core group member. The host name is * and the server 
    name is myCell01\myCellManager01\dmgr. The member will be excluded from 
    the core group.
    

  2. Check for type 3 processes. Type 3 processes do not display in a view with type 1 processes, but can be detected by examining the HMGR0218 messages the various processes log. If the processes connect, the same message is logged across all processes. Specifically, processes that connect have the same view identifier and the same number of processes in the view

    HMGR0218I: A new core group view has been installed. The core group is 
    defaultCoreGroup. The view identifier is (8:0.spoletoCell01\
    spoletoCellManager01\dmgr). The number of members in the new view is 2.
    


Related reference

Configuring a core group transport

 



 

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.