Oninit cdi / Archive
Talk to an expert →

Connection Manager Behaviour - Feedback Request

Posted in 2009

Topics: High Availability & Replication, Server Administration, Networking & sqlhosts Configuration, Clustering, Grid & MACH11

theBP — — source: Usenet: comp.databases.informix

Hi, I am currently in discussion with R&D about how Connection Manager behaves, and what behaviour customers want. So, given the following environment, using the sqlhosts as a central reference point (and yes, it IS big), where I have Two MACH11 clusters Each Cluster has 1 Primary 1 HDR Secondary 2 RSS Secondaries 2 SDS Secondaries Each Cluster has 2 Connection Managers Each server has 1 shm connection 2 tcp connections 1 ssl connection *SQLHOSTS* nan_1150f_1_pri_s onipcshm nanook nan_1150f_1_pri_s nan_1150f_1_sec_s onipcshm nanook nan_1150f_1_sec_s nan_1150f_1_rss1_s onipcshm nanook nan_1150f_1_rss1_s nan_1150f_1_rss2_s onipcshm nanook nan_1150f_1_rss2_s nan_1150f_1_sds1_s onipcshm nanook nan_1150f_1_sds1_s nan_1150f_1_sds2_s onipcshm nanook nan_1150f_1_sds2_s nan_1150f_1 group - - i=1 nan_1150f_1_pri_t1 onsoctcp nanook nan_1150f_1_pri_t1 g=nan_1150f_1 nan_1150f_1_pri_t2 onsoctcp nanook nan_1150f_1_pri_t2 g=nan_1150f_1 nan_1150f_1_sec_t1 onsoctcp nanook nan_1150f_1_sec_t1 g=nan_1150f_1 nan_1150f_1_sec_t2 onsoctcp nanook nan_1150f_1_sec_t2 g=nan_1150f_1 nan_1150f_1_rss1_t1 onsoctcp nanook nan_1150f_1_rss1_t1 g=nan_1150f_1 nan_1150f_1_rss1_t2 onsoctcp nanook nan_1150f_1_rss1_t2 g=nan_1150f_1 nan_1150f_1_rss2_t1 onsoctcp nanook nan_1150f_1_rss2_t1 g=nan_1150f_1 nan_1150f_1_rss2_t2 onsoctcp nanook nan_1150f_1_rss2_t2 g=nan_1150f_1 nan_1150f_1_sds1_t1 onsoctcp nanook nan_1150f_1_sds1_t1 g=nan_1150f_1 nan_1150f_1_sds1_t2 onsoctcp nanook nan_1150f_1_sds1_t2 g=nan_1150f_1 nan_1150f_1_sds2_t1 onsoctcp nanook nan_1150f_1_sds2_t1 g=nan_1150f_1 nan_1150f_1_sds2_t2 onsoctcp nanook nan_1150f_1_sds2_t2 g=nan_1150f_1# Confirm SSL functionality nan_1150f_1_pri_ssl onsocssl nanook nan_1150f_1_pri_ssl nan_1150f_1_sec_ssl onsocssl nanook nan_1150f_1_pri_ssl nan_1150f_1_rss1_ssl onsocssl nanook nan_1150f_1_pri_ssl nan_1150f_1_rss2_ssl onsocssl nanook nan_1150f_1_pri_ssl nan_1150f_1_sds1_ssl onsocssl nanook nan_1150f_1_pri_ssl nan_1150f_1_sds2_ssl onsocssl nanook nan_1150f_1_pri_ssl # nan_1150f_2_pri_s onipcshm nanook nan_1150f_2_pri_s nan_1150f_2_sec_s onipcshm nanook nan_1150f_2_sec_s nan_1150f_2_rss1_s onipcshm nanook nan_1150f_2_rss1_s nan_1150f_2_rss2_s onipcshm nanook nan_1150f_2_rss2_s nan_1150f_2_sds1_s onipcshm nanook nan_1150f_2_sds1_s nan_1150f_2_sds2_s onipcshm nanook nan_1150f_2_sds2_s nan_1150f_2 group - - i=2 nan_1150f_2_pri_t1 onsoctcp nanook nan_1150f_2_pri_t1 g=nan_1150f_1 nan_1150f_2_pri_t2 onsoctcp nanook nan_1150f_2_pri_t2 g=nan_1150f_1 nan_1150f_2_sec_t1 onsoctcp nanook nan_1150f_2_sec_t1 g=nan_1150f_1 nan_1150f_2_sec_t2 onsoctcp nanook nan_1150f_2_sec_t2 g=nan_1150f_1 nan_1150f_2_rss1_t1 onsoctcp nanook nan_1150f_2_rss1_t1 g=nan_1150f_1 nan_1150f_2_rss1_t2 onsoctcp nanook nan_1150f_2_rss1_t2 g=nan_1150f_1 nan_1150f_2_rss2_t1 onsoctcp nanook nan_1150f_2_rss2_t1 g=nan_1150f_1 nan_1150f_2_rss2_t2 onsoctcp nanook nan_1150f_2_rss2_t2 g=nan_1150f_1 nan_1150f_2_sds1_t1 onsoctcp nanook nan_1150f_2_sds1_t1 g=nan_1150f_1 nan_1150f_2_sds1_t2 onsoctcp nanook nan_1150f_2_sds1_t2 g=nan_1150f_1 nan_1150f_2_sds2_t1 onsoctcp nanook nan_1150f_2_sds2_t1 g=nan_1150f_1 nan_1150f_2_sds2_t2 onsoctcp nanook nan_1150f_2_sds2_t2 g=nan_1150f_1# Confirm SSL functionality nan_1150f_2_pri_ssl onsocssl nanook nan_1150f_2_pri_ssl nan_1150f_2_sec_ssl onsocssl nanook nan_1150f_2_pri_ssl nan_1150f_2_rss1_ssl onsocssl nanook nan_1150f_2_pri_ssl nan_1150f_2_rss2_ssl onsocssl nanook nan_1150f_2_pri_ssl nan_1150f_2_sds1_ssl onsocssl nanook nan_1150f_2_pri_ssl nan_1150f_2_sds2_ssl onsocssl nanook nan_1150f_2_pri_ssl# Subsequent entries are for the "SLA" cross references to the oncmsm configuration # There are two Connection managers per Cluster each with # SLA nan_1150f_1a_oltp=PRI # SLA nan_1150f_1a_mis=(SDS+HDR+RSS) # SLA nan_1150f_1a_ssl=(PRI,SDS+HDR+RSS) nan_1150f_1a_oltp onsoctcp nanook nan_1150f_1a_oltp nan_1150f_1a_mis onsoctcp nanook nan_1150f_1a_mis nan_1150f_1a_ssl onsocssl nanook nan_1150f_1a_ssl nan_1150f_1b_oltp onsoctcp nanook nan_1150f_1b_oltp nan_1150f_1b_mis onsoctcp nanook nan_1150f_1b_mis nan_1150f_1b_ssl onsocssl nanook nan_1150f_1b_ssl nan_1150f_2a_oltp onsoctcp nanook nan_1150f_2a_oltp nan_1150f_2a_mis onsoctcp nanook nan_1150f_2a_mis nan_1150f_2a_ssl onsocssl nanook nan_1150f_2a_ssl nan_1150f_2b_oltp onsoctcp nanook nan_1150f_2b_oltp nan_1150f_2b_mis onsoctcp nanook nan_1150f_2b_mis nan_1150f_2b_ssl onsocssl nanook nan_1150f_2b_ssl This is the current suggestion of behaviour given the following SLAs : *Client re-direction* # SLA nan_1150f_1a_oltp=PRI Client connects to nan_1150f_1a_oltp CM re-directs to (any equivalent protocol DBSERVERNAME / ALIAS) nan_1150f_1_pri_t1 nan_1150f_1_pri_t2 # SLA nan_1150f_1a_mis=(SDS+HDR+RSS) Client connects to nan_1150f_1a_mis CM re-directs to (any equivalent protocol DBSERVERNAME / ALIAS) nan_1150f_1_sec_t1 nan_1150f_1_sec_t2 nan_1150f_1_rss1_t1 nan_1150f_1_rss1_t2 nan_1150f_1_rss2_t1 nan_1150f_1_rss2_t2 nan_1150f_1_sds1_t1 nan_1150f_1_sds1_t2 nan_1150f_1_sds2_t1 nan_1150f_1_sds2_t2 # SLA nan_1150f_1a_ssl=(PRI,SDS+HDR+RSS) Client connects to nan_1150f_1a_ssl CM re-directs to (any equivalent protocol DBSERVERNAME / ALIAS) nan_1150f_1_pri_ssl nan_1150f_1_sec_ssl nan_1150f_1_rss1_ssl nan_1150f_1_rss2_ssl nan_1150f_1_sds1_ssl nan_1150f_1_sds2_ssl If there is a requirement for an SLA to re-direct to a specific DBSERVERNAME / ALIAS, for example Network Infrastructure issues) then the SLA should be denoted as : SLA nan_1150f_1a_oltp=((nan_1150f_1_pri_t1) <dbserveraliases=off> *INFORMIXSERVER For CM* Another aspect is the INFORMIXSERVER used for the CM environment at startup. There has been a suggestion that using the group name is better in that CM will try to connect to the Primary which MAY have changed due to failover and subsequently try the next in the group. INFORMIXSERVER=nan_1150f_1 There is also the possibility that there is client requirement for CM connecting via SSL to the Server, which would need : INFORMIXSERVER=nan_1150f_1_pri_sslMay be artificual, but I do not think a single CM could do both of the following SLAs - could it?? : Client -> SSL -> CM -> SSL -> Server AND Client -> CM -> Server *Communication Between Servers in the MACH11 Cluster via CM* Unless s=6 is placed in the sqlhosts (i.e. a specific connection for HDR, RSS, SDS communication), then (presumably) communications will be across "any equivalent protocol DBSERVERNAME / ALIAS" - or should this be enforced by HA_ALIAS being used?? Presumably, if s=6 IS present then CM wi

↪ replying to theBP
Obnoxio The Clown — — source: Usenet: comp.databases.informix

theBP wrote: > > Anyway, long post and hopefully a bit of an eye opener to CM. Has anybody dubbed it "the Connection Mangler" yet? If not, may I be the person to do so? :o) -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

↪ replying to theBP
Madison Pruet — — source: Usenet: comp.databases.informix

I don't understand. See below theBP wrote: > Hi, > > I am currently in discussion with R&D about how Connection Manager > behaves, and what behaviour customers want. > > So, given the following environment, using the sqlhosts as a central > reference point (and yes, it IS big), > > where I have > > Two MACH11 clusters > Each Cluster has > 1 Primary > 1 HDR Secondary > 2 RSS Secondaries > 2 SDS Secondaries > Each Cluster has > 2 Connection Managers > Each server has > 1 shm connection > 2 tcp connections > 1 ssl connection > > *SQLHOSTS* > nan_1150f_1_pri_s onipcshm nanook nan_1150f_1_pri_s > nan_1150f_1_sec_s onipcshm nanook nan_1150f_1_sec_s > nan_1150f_1_rss1_s onipcshm nanook nan_1150f_1_rss1_s > nan_1150f_1_rss2_s onipcshm nanook nan_1150f_1_rss2_s > nan_1150f_1_sds1_s onipcshm nanook nan_1150f_1_sds1_s > nan_1150f_1_sds2_s onipcshm nanook nan_1150f_1_sds2_s > nan_1150f_1 group - - i=1 > nan_1150f_1_pri_t1 onsoctcp nanook nan_1150f_1_pri_t1 > g=nan_1150f_1 > nan_1150f_1_pri_t2 onsoctcp nanook nan_1150f_1_pri_t2 > g=nan_1150f_1 > nan_1150f_1_sec_t1 onsoctcp nanook nan_1150f_1_sec_t1 > g=nan_1150f_1 > nan_1150f_1_sec_t2 onsoctcp nanook nan_1150f_1_sec_t2 > g=nan_1150f_1 > nan_1150f_1_rss1_t1 onsoctcp nanook nan_1150f_1_rss1_t1 > g=nan_1150f_1 > nan_1150f_1_rss1_t2 onsoctcp nanook nan_1150f_1_rss1_t2 > g=nan_1150f_1 > nan_1150f_1_rss2_t1 onsoctcp nanook nan_1150f_1_rss2_t1 > g=nan_1150f_1 > nan_1150f_1_rss2_t2 onsoctcp nanook nan_1150f_1_rss2_t2 > g=nan_1150f_1 > nan_1150f_1_sds1_t1 onsoctcp nanook nan_1150f_1_sds1_t1 > g=nan_1150f_1 > nan_1150f_1_sds1_t2 onsoctcp nanook nan_1150f_1_sds1_t2 > g=nan_1150f_1 > nan_1150f_1_sds2_t1 onsoctcp nanook nan_1150f_1_sds2_t1 > g=nan_1150f_1 > nan_1150f_1_sds2_t2 onsoctcp nanook nan_1150f_1_sds2_t2 > g=nan_1150f_1 Does each instance have two listener threads? If not, then why the "t1/t2" business? I see 12 TCP connections, but only 6 servers in the diagram. > # Confirm SSL functionality > nan_1150f_1_pri_ssl onsocssl nanook nan_1150f_1_pri_ssl > nan_1150f_1_sec_ssl onsocssl nanook nan_1150f_1_pri_ssl > nan_1150f_1_rss1_ssl onsocssl nanook nan_1150f_1_pri_ssl > nan_1150f_1_rss2_ssl onsocssl nanook nan_1150f_1_pri_ssl > nan_1150f_1_sds1_ssl onsocssl nanook nan_1150f_1_pri_ssl > nan_1150f_1_sds2_ssl onsocssl nanook nan_1150f_1_pri_ssl > # > nan_1150f_2_pri_s onipcshm nanook nan_1150f_2_pri_s > nan_1150f_2_sec_s onipcshm nanook nan_1150f_2_sec_s > nan_1150f_2_rss1_s onipcshm nanook nan_1150f_2_rss1_s > nan_1150f_2_rss2_s onipcshm nanook nan_1150f_2_rss2_s > nan_1150f_2_sds1_s onipcshm nanook nan_1150f_2_sds1_s > nan_1150f_2_sds2_s onipcshm nanook nan_1150f_2_sds2_s > nan_1150f_2 group - - i=2 > nan_1150f_2_pri_t1 onsoctcp nanook nan_1150f_2_pri_t1 > g=nan_1150f_1 > nan_1150f_2_pri_t2 onsoctcp nanook nan_1150f_2_pri_t2 > g=nan_1150f_1 > nan_1150f_2_sec_t1 onsoctcp nanook nan_1150f_2_sec_t1 > g=nan_1150f_1 > nan_1150f_2_sec_t2 onsoctcp nanook nan_1150f_2_sec_t2 > g=nan_1150f_1 > nan_1150f_2_rss1_t1 onsoctcp nanook nan_1150f_2_rss1_t1 > g=nan_1150f_1 > nan_1150f_2_rss1_t2 onsoctcp nanook nan_1150f_2_rss1_t2 > g=nan_1150f_1 > nan_1150f_2_rss2_t1 onsoctcp nanook nan_1150f_2_rss2_t1 > g=nan_1150f_1 > nan_1150f_2_rss2_t2 onsoctcp nanook nan_1150f_2_rss2_t2 > g=nan_1150f_1 > nan_1150f_2_sds1_t1 onsoctcp nanook nan_1150f_2_sds1_t1 > g=nan_1150f_1 > nan_1150f_2_sds1_t2 onsoctcp nanook nan_1150f_2_sds1_t2 > g=nan_1150f_1 > nan_1150f_2_sds2_t1 onsoctcp nanook nan_1150f_2_sds2_t1 > g=nan_1150f_1 > nan_1150f_2_sds2_t2 onsoctcp nanook nan_1150f_2_sds2_t2 > g=nan_1150f_1> # Confirm SSL functionality > nan_1150f_2_pri_ssl onsocssl nanook nan_1150f_2_pri_ssl > nan_1150f_2_sec_ssl onsocssl nanook nan_1150f_2_pri_ssl > nan_1150f_2_rss1_ssl onsocssl nanook nan_1150f_2_pri_ssl > nan_1150f_2_rss2_ssl onsocssl nanook nan_1150f_2_pri_ssl > nan_1150f_2_sds1_ssl onsocssl nanook nan_1150f_2_pri_ssl > nan_1150f_2_sds2_ssl onsocssl nanook nan_1150f_2_pri_ssl> # Subsequent entries are for the "SLA" cross references to the oncmsm > configuration > # There are two Connection managers per Cluster each with > # SLA nan_1150f_1a_oltp=PRI > # SLA nan_1150f_1a_mis=(SDS+HDR+RSS) > # SLA nan_1150f_1a_ssl=(PRI,SDS+HDR+RSS) > nan_1150f_1a_oltp onsoctcp nanook nan_1150f_1a_oltp > nan_1150f_1a_mis onsoctcp nanook nan_1150f_1a_mis > nan_1150f_1a_ssl onsocssl nanook nan_1150f_1a_ssl > nan_1150f_1b_oltp onsoctcp nanook nan_1150f_1b_oltp > nan_1150f_1b_mis onsoctcp nanook nan_1150f_1b_mis > nan_1150f_1b_ssl onsocssl nanook nan_1150f_1b_ssl > nan_1150f_2a_oltp onsoctcp nanook nan_1150f_2a_oltp > nan_1150f_2a_mis onsoctcp nanook nan_1150f_2a_mis > nan_1150f_2a_ssl onsocssl nanook nan_1150f_2a_ssl > nan_1150f_2b_oltp onsoctcp nanook nan_1150f_2b_oltp > nan_1150f_2b_mis onsoctcp nanook nan_1150f_2b_mis > nan_1150f_2b_ssl onsocssl nanook nan_1150f_2b_ssl Do you have 4 connection managers running? Are you wanting to combine the CMs into a group? > > This is the current suggestion of behaviour given the following SLAs : > > *Client re-direction* > > # SLA nan_1150f_1a_oltp=PRI > Client connects to > nan_1150f_1a_oltp > CM re-directs to (any equivalent protocol DBSERVERNAME / ALIAS) > nan_1150f_1_pri_t1 > nan_1150f_1_pri_t2 > > # SLA nan_1150f_1a_mis=(SDS+HDR+RSS) > Client connects to > nan_1150f_1a_mis > CM re-directs to (any equivalent protocol DBSERVERNAME / ALIAS) > nan_1150f_1_sec_t1 > nan_1150f_1_sec_t2 > nan_1150f_1_rss1_t1 > nan_1150f_1_rss1_t2 > nan_1150f_1_rss2_t1 > nan_1150f_1_rss2_t2 > nan_1150f_1_sds1_t1 > nan_1150f_1_sds1_t2 > nan_1150f_1_sds2_t1 > nan_1150f_1_sds2_t2 > > # SLA nan_1150f_1a_ssl=(PRI,SDS+HDR+RSS) > Client connects to > nan_1150f_1a_ssl > CM re-directs to (any equivalent protocol DBSERVERNAME / ALIAS) > nan_1150f_1_pri_ssl > nan_1150f_1_sec_ssl > nan_1150f_1_rss1_ssl > nan_1150f_1_rss2_ssl > nan_1150f_1_sds1_ssl > nan_1150f_1_sds2_ssl > > If there is a requirement for an SLA to re-direct to a specific > DBSERVERNAME / ALIAS, for example Network Infrastructure issues) then > the SLA should be denoted as : > SLA nan_1150f_1a_oltp=((nan_1150f_1_pri_t1) <dbserveraliases=off> > > > *INFORMIXSERVER For CM* > > Another aspect is the INFORMIXSERVER used for the CM environment at > startup. > > There has been a suggestion that using the

↪ replying to Madison Pruet
theBP — — source: Usenet: comp.databases.informix

Madison Pruet wrote: > I don't understand. See below > <snip> >> Two MACH11 clusters >> Each Cluster has >> 1 Primary >> 1 HDR Secondary >> 2 RSS Secondaries >> 2 SDS Secondaries >> Each Cluster has >> 2 Connection Managers >> Each server has >> 1 shm connection >> 2 tcp connections >> 1 ssl connection > Does each instance have two listener threads? If not, then why the > "t1/t2" business? I see 12 TCP connections, but only 6 servers in the > diagram. Each server has 1 shm connection 2 tcp connections 1 ssl connection > Do you have 4 connection managers running? Are you wanting to combine > the CMs into a group? > I have 2 connection managers per cluster (in case one connection manager fails, the other one should be still working)

Glossary