Connection Manager for DRDA and HDR

Abstract

Informix Dynamic Server (IDS) provides a simple way to replicate a whole instance to a hot standby system, namely High-availability Data Replication (HDR). The similar Remote Standalone Secondary (RSS) mode has some additional features, but is normally only used in addition to HDR when there are more than two nodes in a cluster, as fail-over requires more steps. Note that a passive replica not running any workload does not require a licence.

In either case, a group can be defined for use in client connection details instead of a specific Informix server name, so that the session is routed to whichever is currently the primary in a pair. This is done in the sqlhosts file, except for non-Java APIs on Windows where the Setnet32 app maintains equivalent registry entries.

However, such a group only works for native protocols and not Distributed Relational Database Architecture (DRDA). That protocol is shared with DB2, and has drivers which are better supported for some development environments such as .Net via the IBM Data Server Driver Package on Windows.

Automating fail-over for DRDA clients therefore needs the Informix Connection Manager (CM). This article provides an example configuration in which each server in an HDR pair runs CM as well as IDS, avoiding the need for separate CM hosts, but still providing automated fail-over without any VIP or DNS change.

Content

The solution is already deployed in a real 24×7 production environment on IDS 14.10.FC11. The example shared here uses 14.10.FC13 Developer Edition from Fix Central, which was the latest at the time, installed in a Rocky 9 Docker container as described here. The trick method to have test instances “cluster1” and “cluster2” running HDR in the same VM is described in our article “Changing logical log buffering in a cluster“, which provides scripts “setup-cluster.sh” and “cluster” (to switch between the instances).

Firstly, when configuring HDR, follow the guidelines to “Prevent blocking checkpoints on HDR servers“. We also recommend these settings:

Despite what the documentation says, all of those can be changed dynamically with “onmode -wf” commands.

In the example setup, we have the two instances configured identically except for these parameters:

“$INFORMIXDIR/etc/sqlhosts” contains:

• “ifx_group” would be used for native TCP connections to the current primary without CM.
• When defining a group, it is best to declare the last server in the list that follows with “e=?”.
• The group name should also be appended with “g=?” to the member servers.
• You may see option “i=?” in documentation which is only relevant to Enterprise Replication.
• Native TCP protocol on Linux is “onsoctcp”, and DRDA is “drsoctcp”.
• The asterisk means “listen on all available network interfaces” as at start-up.
• Port numbers can be stated directly instead of service names from /etc/services.
• Aliases for equivalent CM SLAs were given the same port numbers plus 100.

Host names “host1” and “host2” were appended as alternatives to IPv4 “localhost” in /etc/hosts. They were used above to make it clear that these would actually be different hosts in a real case. You would need them to trust each other as documented here. The same “sqlhosts” file would be installed as above on both hosts.

Excluding pre-existing comments from the provided template “cmsm.cfg.sample”, configuration files for each CM were created in $INFORMIXDIR/etc as follows:

• NAME must be unique and identifies the CM in logs and when stopping it.
• “ifx_cluster” is an internal name within the CM config file.
• “ifx_group” is the native TCP listener group in “sqlhosts” for intercommunication.
• SLA names are used to look up the CM protocol and port from “sqlhosts”.
• “DBSERVERS=primary” specifies only ever connecting to the primary instance.
• “FOC ORDER=disabled” prevents CM from initiating HDR fail-over.
• “PRIORITY” must be unique across all CMs connected to a cluster.

Beware of the following pitfalls on other systems or versions:

• CM might not start if environment variable INFORMIXSERVER is set to a shared memory alias.
• CM config entry INFORMIXSERVER might need a list of native TCP listeners, not a group.
• Set INFORMIXSQLHOSTS to a separate “sqlhosts” file with no extraneous entries if necessary.
• Use DEBUG=1 until working.

Start the CMs:

Check CM logs (both similar, first shown):

Check IDS logs (both similar, first shown):

Check with “onstat” on either instance:

Configuration of IBM Data Server Driver Package on Windows:

Test results (similar with the other alias):

CM logs show both redirected to primary instance “cluster1”:

Server types were switched with these commands (run on separate hosts in a real scenario):

After repeating the tests on Windows, logs show connections redirected to “cluster2”:

To stop the CMs:

Unlike IDS, there is no particular need to do that before a shutdown or reboot of the host.

Conclusion

This article provides a way to connect DRDA clients automatically to whichever is currently the primary in an HDR server pair using existing infrastructure without VIP or DNS changes.

Caveats

Some aspects of Connection Manager are under-documented, and may not behave the same on different versions.

For Linux systems with thousands of sessions, we advise appending the following to “/etc/sysctl.conf”:

Apply with the command “sysctl -p”. Both steps must as user “root”.

Otherwise, after an outage, CM can be overwhelmed with a flood of requests, resulting in this error being produced continuously:

None of this article has been tested with IDS running on Windows. The main change would be to create definitions equivalent to “sqlhosts” with Setnet32.

Disclaimer

Suggestions above are provided “as is” without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement.

Contact Us

If you have any questions or would like to find out more about this topic, please contact us.