Requirements

When you configure and use mutually-aware OpenSwitch servers, keep these requirements in mind:

• Server and pool names are limited to a maximum of 31 characters.

• 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:

  • MUTUAL_AWARE

  • MUTUAL_CLUSTER

  • UPDATE_CFG

  • SVR_FAIL_ACTION

  • NET_FAIL_ACTION

  • CMP_FAIL_ACTION

  • CMON_FAIL_ACTION

  • FREEZE_CFG_ON_FAIL

  • 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 (Windows), interfaces file (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   <host>   4405
  query   tcp   ether   <host>   4406
  
  OSW2
  query   tcp   ether   <host>   4406
  query   tcp   ether   <host>   4405
  
  

  When you configure a mutually-aware OpenSwitch server using the GUI configuration tool, these entries are created for you automatically.

  When you configure a mutually-aware OpenSwitch server by manually editing the configuration files, you must manually create these entries in the sql.ini (Windows) or interfaces (UNIX) file.

• 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.

  Sybase recommends that you not have other pools in a mutually-aware OpenSwitch, unless the pool is a “catch-all pool” that is not crucial to production.

  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.

  Sybase recommends that you never have two OpenSwitch servers use the same pools of servers, or be the failover entries for each other in the sql.ini (Windows) or interfaces (UNIX) file without being mutually aware. Always set MUTUAL_AWARE to 1 in both companion OpenSwitch server configuration files.

• 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.

• If you are using a CM or RCM, set SVR_FAIL_ACTION to DEFAULT. Specifically, 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.

• Start the primary OpenSwitch first, then start the secondary (companion) OpenSwitch. See Chapter 3, “Starting and Stopping OpenSwitch and RCMs.”

Copyright © 2005. Sybase Inc. All rights reserved.

View this book as PDF