redundant connection manager configuration using H
Justin asked how to configure Connection Managers for a multi-site MACH11 cluster (HDR primary/secondary at HQ, an RSS at each remote site), specifically how an SLA like DBSERVERS=RSS,(primary,HDR) with POLICY=LATENCY picks which RSS to use, and whether one cluster definition or separate per-site definitions is better. An IBM respondent explained that POLICY=LATENCY really targets ER replsets/grid (needing a replicated grid table and QOD monitoring); for MACH11 the CM computes an internal weight from data latency and session queue size and routes to the lowest-weight server. Ordering in the DBSERVERS list is honoured — RSS first, falling back to primary/HDR only if no RSS is available — and since the primary has zero latency, grouping like DBSERVERS=(RSS,HDR),PRIMARY keeps traffic off it. Setting DEBUG=1 in the CM config shows the routing details. No explicit verdict on the one-vs-many cluster layout.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
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
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.
Hello. I would suggest you to search in Member Area, IIUG Conference materials have several presentations about CMs usage, including advanced cluster, with more than 1 CM for failover process. I hope it helps to give you a better idea for your specific needs. But in case you still have some doubts, you could ask again, or even contact the person who presented it at the Conference. Regards.
"POLICY=LATENCY" is good for ER replset and GRID To use the latency and failure policies, you must: create a table through the grid, and the table must have replication enabled enabled quality of data (qod) monitoring with MACH11 cluster, connection manager calculates the server weight internally with data latency and session ready queue size for each RSS server, and re-routes the client to the server with the lowest weight. you can set 'DEBUG' to '1' in the CM configuration file, CM will print out the detail. SLA cm_sla1 DBSERVERS=RSS,(primary,HDR) CM first checks RSS servers, if all RSS are not available, then Primary or HDR
I'm looking specifically at a MACH11 cluster. So then, if I was to just make things simple and do this: SLA cm_sla1 DBSERVERS=(RSS,primary,HDR) Then the HQ connection manager would realize that the RSS is high latency and avoid giving it out, and the remote site connection manager would realize that the primary and hdr servers (and any other RSS servers at different sites) have high latency and avoid giving them out? -Justin -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of JINMING XIAO Sent: Monday, June 03, 2013 12:57 PM To: ids@iiug.org Subject: Re: RE: redundant connection manager configuration [30415] "POLICY=LATENCY" is good for ER replset and GRID To use the latency and failure policies, you must: create a table through the grid, and the table must have replication enabled enabled quality of data (qod) monitoring with MACH11 cluster, connection manager calculates the server weight internally with data latency and session ready queue size for each RSS server, and re-routes the client to the server with the lowest weight. you can set 'DEBUG' to '1' in the CM configuration file, CM will print out the detail. SLA cm_sla1 DBSERVERS=RSS,(primary,HDR) CM first checks RSS servers, if all RSS are not available, then Primary or HDR ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
correct. since PRIMARY always has zero latency, so most time Connection Manager will route client application to the PRIMARY. if you want use secondaries and low the connections to the PRIMARY, you can define cm_sla1 as SLA cm_sla1 DBSERVERS=(RSS,HDR),PRIMARY if all RSS and HDR are not available, CM will route client to the primary.
so you started in iiug too :) Good thing. Thanks and Regards, Gaurav "Either it is done or not done, rest all are excuses." From: "JINMING XIAO" <jxiao@us.ibm.com> To: ids@iiug.org Date: 06/05/2013 07:41 PM Subject: Re: RE: RE: redundant connection manager configura [30430] Sent by: ids-bounces@iiug.org correct. since PRIMARY always has zero latency, so most time Connection Manager will route client application to the PRIMARY. if you want use secondaries and low the connections to the PRIMARY, you can define cm_sla1 as SLA cm_sla1 DBSERVERS=(RSS,HDR),PRIMARY if all RSS and HDR are not available, CM will route client to the primary. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.