IDS Forum

RE: redundant connection manager configuration usi

Posted By: Justin Killen
Date: Monday, 3 June 2013, at 1:40 p.m.

In Response To: redundant connection manager configuration using H (Justin Killen)

Maybe my first example is too complex. How about a simpler question:

If I have a connection manager configuration like this:

CLUSTER cluster_1
{
INFORMIXSERVER hq_prim, hq_sec, hq_rss, siteA_rss, siteB_rss

SLA cm_sla1 DBSERVERS=RSS,(primary,HDR) POLICY=LATENCY

FOC ORDER=HDR TIMEOUT=10 RETRY=2
CMALARMPROGRAM ${INFORMIXDIR}/etc/cmalarmprogram.sh
}

How does Informix choose which RSS to use?
Obviously the POLICY=LATENCY means to use latency as a determining factor, but what order does this happen in? I.e. does that line mean to look at each of the RSS, primary, and HDR secondaries and connect to the one with the least latency, or does it mean to look only at RSS servers and connect to the lowest latency but then revert to the HDR pair only if no RSS servers are available?

Thanks
-Justin

-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Justin Killen
Sent: Friday, May 31, 2013 2:16 PM
To: ids@iiug.org
Subject: redundant connection manager configuration usi.... [30401]

Hi,
Given the following geographical setup:

HQ

|
|--WanA-------WanB--|
SiteA SiteB

Where HQ has an HDR primary and an HDR secondary pair, and each of the remote
sites (SiteA and SiteB) have an RSS.

What we want to accomplish is to have connections coming from HQ to be load
balanced across the HDR primary and HDR secondary, but to have SiteA point to
it's RSS and SiteB point to it's RSS. In the event that both the HDR primary
and HDR secondary fail, HQ users should be directed to either RSS server (in
read-only mode). In the event that an RSS goes down, connections should be
directed at the HDR primary/secondary pair until the RSS comes back online. In
the event that WanA/WanB goes down, their corresponding site should then
become read-only (insert/updates fail). Furthermore, the HDR should be
promoted to primary in the case of failure on the primary, but neither RSS
should ever be promoted. Also, we'd like to setup redundant connection manager
instances (one per server) for client connection availability.

The point we're stumped at is how to configure the configuration manager
instances. At first thought, I created a cluster entry with two SLA's - one
for HQ and one for SiteA/SiteB that looks like this:

CLUSTER cluster_hq
{
INFORMIXSERVER hq_prim, hq_sec, siteARss, siteBRss

SLA cm_hq DBSERVERS=(primary,HDR),RSS
SLA cm_remote DBSERVERS=RSS,(primary,HDR) POLICY=LATENCY

FOC ORDER=HDR TIMEOUT=10 RETRY=2
CMALARMPROGRAM ${INFORMIXDIR}/etc/cmalarmprogram.sh
}

My issue here is that I don't understand how Informix knows which RSS to use
for remote sites. Obviously the POLICY=LATENCY means to use latency as a
determining factor, but what order does this happen in? I.e. does that line
mean to look at each of the RSS, primary, and HDR secondaries and connect to
the one with the least latency, or does it mean to look only at RSS servers
and connect to the lowest latency but then revert to the HDR pair only if no
RSS servers are available?

Also, if I run this configuration for the remote sites' connection manager,
won't it try to promote the HDR secondary to a primary if a WAN link goes
down? or is this information just passed to the connection manager on the
client computers so they know what connection manager instance to connect to
next?

Because of the failover differences, I think it might be best to setup two
clusters, one for HQ and one for each remote site, like this:

CLUSTER cluster_hq
{
INFORMIXSERVER hq_prim, hq_sec, siteARss, siteBRss

SLA cm_hq DBSERVERS=(primary, HDR), RSS

FOC ORDER=HDR TIMEOUT=10 RETRY=2
CMALARMPROGRAM ${INFORMIXDIR}/etc/cmalarmprogram.sh
}

CLUSTER cluster_siteA
{
INFORMIXSERVER hq_prim, hq_sec, siteARss

SLA cm_sitea DBSERVERS=RSS, (primary, HDR)

FOC ORDER=NOTIFY
CMALARMPROGRAM ${INFORMIXDIR}/etc/cmalarmprogram.sh
}

CLUSTER cluster_siteB
{
INFORMIXSERVER hq_prim, hq_sec, siteBRss

SLA cm_siteb DBSERVERS=RSS, (primary, HDR)

FOC ORDER=NOTIFY
CMALARMPROGRAM ${INFORMIXDIR}/etc/cmalarmprogram.sh
}

The downside of this is that it doesn't seem very scalable to me, so I'd like
to stick with fewer CM clusters. One I think would be best, or maybe two - one
for HQ and one for remote sites.

I get the impression that I'm over-thinking this and that it has already been
done, so any opinions would be welcomed. We purchased the redbook "IBM
Informix Flexible Grid, Extending Data Availability" (ISBN 978-0-7384-3569-5);
it does a pretty good job of describing how to set things up, but not such a
great job on differentiating core technologies and why you would use one thing
over another. If anybody has ideas to expand our reading list, we'd appreciate
that info as well.

Thanks,
-Justin

*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.

Messages In This Thread

• redundant connection manager configuration using H
  Justin Killen -- Friday, 31 May 2013, at 5:15 p.m.
  • RE: redundant connection manager configuration usi
    Justin Killen -- Monday, 3 June 2013, at 1:40 p.m.
    • Re: RE: redundant connection manager configuration
      ALEXANDRE MARINI -- Monday, 3 June 2013, at 2:49 p.m.
    • Re: RE: redundant connection manager configuration
      JINMING XIAO -- Monday, 3 June 2013, at 3:57 p.m.
      • RE: RE: redundant connection manager configuration
        Justin Killen -- Tuesday, 4 June 2013, at 1:44 p.m.
        • Re: RE: RE: redundant connection manager configura
          JINMING XIAO -- Wednesday, 5 June 2013, at 9:46 a.m.
          • Re: RE: RE: redundant connection manager configura
            Gaurav Saxena3 -- Wednesday, 5 June 2013, at 10:17 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.