Requirements

Both OpenSwitch servers must have the same pool and server configurations in their configuration files. When they are not the same, the OpenSwitch that starts first takes precedence.

The following [CONFIG] parameters must be the same in both OpenSwitch server configuration files:

• CMON_FAIL_ACTION

• CMP_FAIL_ACTION

• COORD_MODE

• COORD_TIMEOUT

• FREEZE_CFG_ON_FAIL

• MUTUAL_AWARE

• MUTUAL_CLUSTER

• NET_FAIL_ACTION

• SVR_FAIL_ACTION

• UPDATE_CFG

• USERNAME_PASSWORD_ENCRYPTED

Each of these parameters is checked and compared when a mutually-aware OpenSwitch server starts, and monitored by the mutually-aware OpenSwitch server during runtime. If there is a difference in parameter values between the companions during startup, the OpenSwitch that is being started fails. If any parameter is found to be different between mutually-aware companions at runtime, both companions are suspended until the difference is resolved and the administrator issues rp_go on each companion. In either case, an error message is logged regarding the dissimilar parameters to help you diagnose and correct the problem.

Set UPDATE_CFG to 1 when you set MUTUAL_AWARE to 1.

When starting mutually-aware OpenSwitch servers, verify that the first server starts properly before starting the next server.

When it is preferable for clients to fail over from one OpenSwitch server to the companion, you must set up the sql.ini file in Windows, interfaces file in UNIX, or LDAP directory service to facilitate this failover. For the sql.ini or interfaces file, enter the second OpenSwitch query address under the first OpenSwitch name as a secondary address.

For example:

OSW1
query   tcp   ether   hostname   4405
query   tcp   ether   hostname   4406

OSW2
query   tcp   ether   hostname   4406
query   tcp   ether   hostname   4405

When the data in the OpenSwitch configuration file is more recent than the configuration used by OpenSwitch when it last ran, start the OpenSwitch server with the “-O” parameter to override the data in the Adaptive Server configuration tables with the information from the OpenSwitch configuration file. For example:

On Windows:

%OPENSWITCH%\bin\OpenSwitch.bat -c \
     %OPENSWITCH%\config\config_file_name.cfg -O

On UNIX:

$OPENSWITCH/bin/OpenSwitch -c \
     $OPENSWITCH/config/config_file_name.cfg -O

The configuration table is created in the default database of the CMON user in the Adaptive Servers where CFG_STORAGE=1. When the default database is not explicitly set, it defaults to “master.”

When an Adaptive Server has not been used for a long time and may have legacy information from an outdated OpenSwitch setup, the administrator can truncate the table before starting the new OpenSwitch server, or start the OpenSwitch server with the “-O” parameter to override the information in the OpenSwitch configuration file.

Only the first two pools defined in the OpenSwitch configuration file are mutually aware.

Pools other than the first two pools in the configuration file assume their original behavior. However, if failover occurs in either of the first two pools, a mutually-aware OpenSwitch acts in the best interest of the first two pools. This may involve shutting down to allow the clients to fail over to the companion OpenSwitch server in case of a total network failure.

Verify that all the pools are defined identically in the primary and secondary companion OpenSwitch servers; that is, pools with the same name must contain the same Adaptive Servers and have the same connection attributes.

Each of the first two pools must contain two servers. The two servers must be defined the same in both pools, but defined in reverse order:

[POOL=POOL1]
     servers:
             ASE1
             ASE2
[POOL=POOL2]
     servers:
             ASE2
             ASE1

Currently, only two OpenSwitch servers are supported in a mutually-aware cluster; that is, there can be only one companion OpenSwitch for each mutually-aware OpenSwitch server. Both OpenSwitch servers in the cluster must be mutually aware.

If one of the OpenSwitch companions does not have MUTUAL_AWARE set to 1, the other OpenSwitch companion marks that OpenSwitch server as “down.” This inconsistency is noted in the error log. Until the non-mutually-aware OpenSwitch server is restarted with MUTUAL_AWARE set to 1, it receives no communication from the companion that does have MUTUAL_AWARE set to 1, which acts as the only mutually-aware OpenSwitch server running in the cluster.

A mutually-aware configuration does not require a coordination module (CM) or replication coordination module (RCM) to run. However, a mutually-aware implementation can work with a CM or RCM solution.

You can use concurrent coordination modules in a mutually-aware configuration in OpenSwitch 15.1 and later. See “Using concurrent coordination modules,” in Chapter 2, “Using Coordination Modules” in the OpenSwitch Coordination Module Reference Manual.

If you are using a CM or RCM in OpenSwitch 15.1 and later, you can set SVR_FAIL_ACTION to CUSTOM, MANUAL, CUSTOM_MANUAL, or DEFAULT.

If you using OpenSwitch 15.0 and earlier, you cannot run custom or manual scripts for server failure when you are using a CM or RCM because each CM and RCM is coded differently and its failover procedure may contradict the actions invoked by a custom or manual script.

If you use a system router, it should not block system commands, such as “ping.” OpenSwitch uses ping to monitor the network between mutually-aware OpenSwitch companions and between OpenSwitch and the Adaptive Servers. A ping failure can be incorrectly interpreted as a network failure.