To load-balance your system among application end users and DSS users, you must add an entry to the sql.ini (Windows) or interfaces (UNIX) file for each OpenSwitch server, giving each entry a unique name. The entry for the primary OpenSwitch server is used only by application end users; the entry for the secondary OpenSwitch server is used only by DSS users.
A redundant OpenSwitch environment requires two query lines for each OpenSwitch server entry in the sql.ini (Windows) or interfaces (UNIX) file. This feature enables the automatic rollover of users connecting to a server.
The order of the query lines describes the sequence in which the connectivity software attempts to connect to a specific server when a user logs in. If the connection attempt using the first query line in that server’s entry fails, the software tries to connect using the next query line. This rollover of user connections gives you redundant connectivity through OpenSwitch.
See the Open Client DB-Library/C Reference Manual for more information about placing multiple query entries in your sql.ini (Windows) or interfaces (UNIX) file.
A completely redundant environment features two RCM instances: One coordinates failover; the other waits to take over coordination if the first instance fails.
WARNING! If you use multiple query lines for the RCM administrator login connections to the primary and secondary OpenSwitch servers, your designed failover might be disrupted when you start the RCM. This situation could be catastrophic.
If you use multiple query lines for the RCM connections, and the primary RCM instance successfully connects to the secondary OpenSwitch server after attempting to connect to a failed or nonexistent primary OpenSwitch server, the primary RCM instance is no longer coordinating failover through the primary OpenSwitch server, because it is connected to the secondary OpenSwitch server. In this scenario, neither the RCM nor the system administrator is aware of the change in OpenSwitch servers, but now the RCM is connected to an OpenSwitch server that is configured to be the secondary OpenSwitch server, not the primary OpenSwitch server.
To resolve this issue, you must create two sql.ini (Windows) or interfaces (UNIX) file entries for each OpenSwitch server and give each entry a unique server name. The first sql.ini (Windows) or interfaces (UNIX) file entry is for end users and should include a second query line for automatic rollover to the secondary OpenSwitch in case the primary OpenSwitch fails, as follows:
[usr_os1] master=TCP,tokyo,2000 query=TCP,tokyo,2000 query=TCP,newyork,2900 [usr_os2] master=TCP,newyork,2900 query=TCP,newyork,2900 query=TCP,tokyo,2000
In this sql.ini (Windows) or interfaces (UNIX) file example, the primary OpenSwitch server, “os1,” runs on port number 2000 on the computer “tokyo.” The secondary OpenSwitch server, “os2,” runs on port number 2900 on “newyork.” The sql.ini (Windows) or interfaces (UNIX) file records, “usr_os1” and “usr_os2,” designate the primary and secondary OpenSwitch servers, respectively, used by application end users and DSS users. Because of the dual query lines in the entry, a user logging in to a failed OpenSwitch server is automatically connected, or rolled over, to the secondary OpenSwitch server.
The second sql.ini (Windows) or interfaces (UNIX) file record is for the two RCM administrator logins and should include only one query entry for the primary OpenSwitch server to ensure that the primary RCM instance connects only to the primary OpenSwitch server. It also includes only one query entry for the secondary OpenSwitch server to ensure that the redundant RCM instance connects only to the secondary OpenSwitch server. This is an example of the second sql.ini (Windows) or interfaces (UNIX) file record:
[rcm_os1] master=TCP,tokyo, 2000 query=TCP,tokyo, 2000 [rcm_os2] master=TCP,newyork,2900 query=TCP,newyork,2900
The RCM administrator logins use the server names “rcm_os1” and “rcm_os2” to connect to the two OpenSwitch servers (also identified in the RCM configuration file). Because each OpenSwitch server record that the RCM administrator logins use contains only one query entry, each RCM administrator login connection does not roll over to another query entry like a user login connection would.
For example, if the primary OpenSwitch server, rcm_os1, is not running, the primary RCM instance cannot run. The primary RCM instance does not know to connect to the secondary OpenSwitch, rcm_os2, because it is not indicated in the server record for the primary OpenSwitch server. This enables you to identify a problem with the primary OpenSwitch server or with the connection between the RCM and the OpenSwitch server rather than have the RCM administrative login roll over automatically to the second OpenSwitch server without notifying you. It also ensures that an RCM instance is either in control of failover or it ceases to run. Because end users are now connected through the secondary OpenSwitch server to the back-end database, you can respond manually to the failure when it is convenient to the end users.
Figure 4-3: sql.ini or interfaces file for a redundant environment
To create a redundant environment, create entries for
both the primary and redundant RCM instances in your sql.ini (Windows)
or interfaces (UNIX) file, as well as entries
for both the primary and secondary
OpenSwitch servers.
See “RCM configuration file examples” to find an example of an RCM configuration file used in an environment with two OpenSwitch servers.
