How to Setup IDS for all IPs

Hi, I like to setup the IDS for all possible IPs on my server. There is one IP switched with heartbeat2. So IDS might already been started, before the IP is activated. Sven ---------------------------------------------- Sven Schuran - Maske AG - IT Operations Telefon: +49 (0) 40 / 88 166 - 283 Telefax: +49 (0) 40 / 88 166 - 5283 E-Mail : sschuran@maske.de <mailto:sschuran@maske.de> -------------------------------------------------------------------- Sie finden uns im Internet unter: www.maske.de Maske AG Behringstraße 120 22763 Hamburg Handelsregister Hamburg HRB 83369 USt-Ident.-Nr. DE 116 923 883 Vorstand: Andreas Maske Vors. d. Aufsichtsrates: Wolfgang Hönen Diese e-mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese e-mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene e-mail. Vielen Dank. This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

Hi, In order to set up the sqlhosts to listen for TCP connections in all the IP addresses of a server having multiple network cards: - You can put * in the hostname/ip-address field of sqlhosts file of the server, before starting the Informix server: Ex: You can use an asterisk (*) as a wildcard in the host name field that the database server uses. When you enter a wildcard in the host name field, the database server can accept connections at any valid IP address on its host computer (hostname is texas, with several ip addresses): texas_srvr ontlitcp * pd1_on - On the client's sqlhosts file / registry, you can either indicate the explicit ip address you want to use, or enter *<hostname> or *<ip address>: Ex: The connectivity information used by a client application must contain an explicit host name or IP address. The client applications on iowa can use any of the following host names: texas1, *texas1, 123.45.67.81, or *123.45.67.81. If there is a wildcard (*) in the host name field, the client application ignores it. You can find documentation here: Wildcard Addressing for TCP/IP Connections http://publib.boulder.ibm.com/infocenter/idshelp/v111/index.jsp?topic=/com.ibm.a dmin.doc/admin146.htm Hope it helps, Regards, Veronica. > To: ids@iiug.org > From: sschuran@maske.de > Subject: How to Setup IDS for all IPs [10501] > Date: Wed, 28 Nov 2007 07:24:02 -0500 > > Hi, > > I like to setup the IDS for all possible IPs on my server. > There is one IP switched with heartbeat2. > > So IDS might already been started, before the IP is activated. > > Sven > > ---------------------------------------------- > Sven Schuran - Maske AG - IT Operations > > Telefon: +49 (0) 40 / 88 166 - 283 > Telefax: +49 (0) 40 / 88 166 - 5283 > E-Mail : sschuran@maske.de <mailto:sschuran@maske.de> > > -------------------------------------------------------------------- > Sie finden uns im Internet unter: www.maske.de > > Maske AG > Behringstraße 120 > 22763 Hamburg > > Handelsregister Hamburg HRB 83369 > USt-Ident.-Nr. DE 116 923 883 > Vorstand: Andreas Maske > Vors. d. Aufsichtsrates: Wolfgang Hönen > > Diese e-mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige > vertrauliche Informationen enthalten. Sollten Sie diese e-mail irrtümlich > erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine > Vervielfältigung oder Weitergabe ausdrücklich untersagt. Bitte benachrichtigen > Sie uns und vernichten Sie die empfangene e-mail. Vielen Dank. > > This e-mail may contain trade secrets or privileged, undisclosed or otherwise > confidential information. If you have received this e-mail in error, you are > hereby notified that any review, copying or distribution of it is strictly > prohibited. Please inform us immediately and destroy the original transmittal. > Thank you for your cooperation. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Hi, this is possible, but in your scenario not so easy to do. It is one reason why I initially said that the IDS Resource Agent supporting Linux-HA is kind of an alternative to IDS HDR. To setup IDS for more than one IP address you have to have an entry in the sqlhosts-file for each IP-address, with different IDS server names. These different IDS server names then need to be reflected in the onconfig file with the parameters DBSERVERNAME and DBSERVERALIASESaccordingly. This will then cause IDS to start a listener thread for each one of these. As a result, this server will be reachable via each configured IP-address. Now with Linux-HA this is a bit of a problem, because not all of these IP-addresses will be functional at all times. My understanding is, that with Linux-HA you (normally) have a virtual IP-address. This is the IP-address that clients use to reach the server, without needing to know, which server (machine) in the cluster is currently active and which is on stand-by. During a failover, the Linux-HA will switch this virtual IP-address from the failing machine over to (one of) the stand-by machine(s). Then the clients can use this same virtual IP-address to reach the new active server server (usually involving a re-connect). This works well when there is only one machine with an active IDS servers at any time. IDS servers on stand-by machines are not running. Therefore all IDS servers can be configured with this same virtual IP-address as well (like the clients). During a failover Linux-HA will make sure that the failing IDS and failing machine will be stopped thoroughly (also see -> "STONITH"). Then it will switch the virtual IP-address to one of the stand-by machines. Then it will start the IDS server on that stand-by machine which becomes the new active machine with running IDS server. But with IDS HDR you will not have only one IDS server running. Instead you will have 2, the Primary and the Secondary running at the same time. But since the virtual IP-address is assigned to only one machine at any time, you can't have both, Primary and Secondary, configured and running with that same one virtual IP-address. It will work only on the active machine. On the other machine it will not work and thus IDS will not work. Therefore you have to configure the IDS Secondary on the stand-by machine with a different IP-address. Then it can run as Secondary. During a failover you then first would have to bring the Secondary down, re-configure it for the virtual IP-address (which gets switched over to this machine by Linux-HA), then start the Secondary again for use of the (new) virtual IP-address and make it the new Primary IDS server. Then clients will be able to connect to this new Primary using the same virtual IP-address (after the obligatory re-connect). This I guess is not exactly what you had in mind. Alternatively you could of course configure the two IDS servers (Primary and Secondary) not using the virtual IP-address at all, but instead using simply different IP-addresses. Then the switch of the virtual IP-address during failover does not affect the IDS servers, i.e. the Secondary can keep running using its own IP-address. Then of course the clients will have to use that IP-address for the re-connect after failover. For this we have mechanisms, e.g. via the DBPATH environment variable. My understanding is these are the possibilities when you want to combine Linux-HA cluster functionality with IDS HDR. Maybe there's another possibility ... which slipped my (non-expert) knowledge of clustering concepts so far. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland GmbH Chairman of the Supervisory Board: Hans Ulrich Märki Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael Diemer Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart, HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940 ids-bounces@iiug.org wrote on 28.11.2007 13:24:02: > Hi, > > I like to setup the IDS for all possible IPs on my server. > There is one IP switched with heartbeat2. > > So IDS might already been started, before the IP is activated. > > Sven > > ---------------------------------------------- > Sven Schuran - Maske AG - IT Operations > > Telefon: +49 (0) 40 / 88 166 - 283 > Telefax: +49 (0) 40 / 88 166 - 5283 > E-Mail : sschuran@maske.de <mailto:sschuran@maske.de> > > -------------------------------------------------------------------- > Sie finden uns im Internet unter: www.maske.de > > Maske AG > Behringstraße 120 > 22763 Hamburg > > Handelsregister Hamburg HRB 83369 > USt-Ident.-Nr. DE 116 923 883 > Vorstand: Andreas Maske > Vors. d. Aufsichtsrates: Wolfgang Hönen > > Diese e-mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige > vertrauliche Informationen enthalten. Sollten Sie diese e-mail irrtümlich > erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine > Vervielfältigung oder Weitergabe ausdrücklich untersagt. Bitte benachrichtigen > Sie uns und vernichten Sie die empfangene e-mail. Vielen Dank. > > This e-mail may contain trade secrets or privileged, undisclosed or otherwise > confidential information. If you have received this e-mail in error, you are > hereby notified that any review, copying or distribution of it is strictly > prohibited. Please inform us immediately and destroy the original transmittal. > Thank you for your cooperation. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Martin Fuerderer wrote: > <SNIP> > Alternatively you could of course configure the > two IDS servers (Primary and Secondary) not > using the virtual IP-address at all, but instead > using simply different IP-addresses. Then the > switch of the virtual IP-address during failover > does not affect the IDS servers, i.e. the Secondary > can keep running using its own IP-address. Then of > course the clients will have to use that IP-address > for the re-connect after failover. For this we have > mechanisms, e.g. via the DBPATH environment > variable. > <SNIP> > Martin, you are forgetting about sqlhosts group names and DBPATH. Either the clients can use DBPATH to automatically fail over to the back up server on reconnect (yes, using that server's ACTUAL IP address not the virtual IP the HA system uses) or they can set up a GROUP in sqlhosts including the two servers with the primary named first in the group. Clients then connect using the group name instead of a specific servername. If the connection fails due to a server or server host failure the client apps can reconnect (or users or the HA software can rerun their apps to reconnect) again using the group name - only this time the group will failover to the secondary. I know that Informix create groups for ER, but they work fine in HDR and even non-replicated sister server environments. Discovered this years ago when the first CSDK & iConnect version 2.xx releases broke DBPATH and our apps stopped failing over on reconnect. If you use groups note that failover timing is more dependent on the settings of INFORMIXCONTIME and INFORMIXCONRETRY than when using DBPATH. I prefer using groups since it's not as dependent on the user's environment and in a 4GL environment DBPATH is also used for locating screen files so it's often cluttered with irrelevant info and prone to muck ups. Art S. Kagel Oninit, LLC > Regards, > Martin >

Hi Art, I thought I mentioned DBPATH ... no? I think you even copied my mention of it in the snippet? :-) Yes, you are right with the group-concept in sqlhosts. That's why I wrote that we have mechanisms for such things and DBPATH is *one* example. I thought for one that explaining the group-concept in sqlhosts is a bit too much in that e-mail as it was (too) long already. And secondly I thought this way I give you a chance to explain the group concept - which you did nicely! :)) Thanks, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland GmbH Chairman of the Supervisory Board: Hans Ulrich Märki Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael Diemer Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart, HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940 "Art S. Kagel (Oninit LLC)" <art@oninit.com> Sent by: ids-bounces@iiug.org 29.11.2007 16:10 Please respond to ids@iiug.org To ids@iiug.org cc Subject Re: How to Setup IDS for all IPs [10533] Martin Fuerderer wrote: > <SNIP> > Alternatively you could of course configure the > two IDS servers (Primary and Secondary) not > using the virtual IP-address at all, but instead > using simply different IP-addresses. Then the > switch of the virtual IP-address during failover > does not affect the IDS servers, i.e. the Secondary > can keep running using its own IP-address. Then of > course the clients will have to use that IP-address > for the re-connect after failover. For this we have > mechanisms, e.g. via the DBPATH environment > variable. > <SNIP> > Martin, you are forgetting about sqlhosts group names and DBPATH. Either the clients can use DBPATH to automatically fail over to the back up server on reconnect (yes, using that server's ACTUAL IP address not the virtual IP the HA system uses) or they can set up a GROUP in sqlhosts including the two servers with the primary named first in the group. Clients then connect using the group name instead of a specific servername. If the connection fails due to a server or server host failure the client apps can reconnect (or users or the HA software can rerun their apps to reconnect) again using the group name - only this time the group will failover to the secondary. I know that Informix create groups for ER, but they work fine in HDR and even non-replicated sister server environments. Discovered this years ago when the first CSDK & iConnect version 2.xx releases broke DBPATH and our apps stopped failing over on reconnect. If you use groups note that failover timing is more dependent on the settings of INFORMIXCONTIME and INFORMIXCONRETRY than when using DBPATH. I prefer using groups since it's not as dependent on the user's environment and in a 4GL environment DBPATH is also used for locating screen files so it's often cluttered with irrelevant info and prone to muck ups. Art S. Kagel Oninit, LLC > Regards, > Martin > ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Martin Fuerderer wrote: > Hi Art, > You do mention DBPATH and 'methods' but I think the focus on: "... the Secondary can keep running using its own IP-address. Then of course the clients will have to use that IP-address for the re-connect after failover." Doesn't make it clear that users and apps do NOT need to deal with the two separate IP address/hostnames for the primary and backup servers but can use connection failover mechanisms built into IDS communications protocols (and ODBC/JDBC protocols for that matter) to failover using a single 'server' name. Art S. Kagel Oninit, LLC > I thought I mentioned DBPATH ... no? I think you even > copied my mention of it in the snippet? :-) > > Yes, you are right with the group-concept in sqlhosts. > That's why I wrote that we have mechanisms for such > things and DBPATH is *one* example. > > I thought for one that explaining the group-concept > in sqlhosts is a bit too much in that e-mail as it was > (too) long already. > And secondly I thought this way I give you a chance > to explain the group concept - which you did nicely! :)) > > Thanks, > Martin >

Hi, when I am using a "*" as IP/host in my sqlhosts file, I may access the database through every IP with same port existing on the server, even when it is assigned later. Sven -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art S. Kagel (Oninit LLC) Sent: Thursday, November 29, 2007 6:50 PM To: ids@iiug.org Subject: Re: How to Setup IDS for all IPs [10535] Martin Fuerderer wrote: > Hi Art, > You do mention DBPATH and 'methods' but I think the focus on: "... the Secondary can keep running using its own IP-address. Then of course the clients will have to use that IP-address for the re-connect after failover." Doesn't make it clear that users and apps do NOT need to deal with the two separate IP address/hostnames for the primary and backup servers but can use connection failover mechanisms built into IDS communications protocols (and ODBC/JDBC protocols for that matter) to failover using a single 'server' name. Art S. Kagel Oninit, LLC > I thought I mentioned DBPATH ... no? I think you even > copied my mention of it in the snippet? :-) > > Yes, you are right with the group-concept in sqlhosts. > That's why I wrote that we have mechanisms for such > things and DBPATH is *one* example. > > I thought for one that explaining the group-concept > in sqlhosts is a bit too much in that e-mail as it was > (too) long already. > And secondly I thought this way I give you a chance > to explain the group concept - which you did nicely! :)) > > Thanks, > Martin > ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. -------------------------------------------------------------------- Sie finden uns im Internet unter: www.maske.de Maske AG Behringstraße 120 22763 Hamburg Handelsregister Hamburg HRB 83369 USt-Ident.-Nr. DE 116 923 883 Vorstand: Andreas Maske Vors. d. Aufsichtsrates: Wolfgang Hönen Diese e-mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese e-mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene e-mail. Vielen Dank. This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

Schuran, Sven wrote: > Hi, > > when I am using a "*" as IP/host in my sqlhosts file, > I may access the database through every IP with same port existing on the > server, even when it is assigned later. > > Clients still have to reconnect and the newly 'assigned' address has to be listed in the sqlhosts file and has to be named either in the INFORMIXSERVER or DBPATH environment variable or INFORMIXSERVER has to be set to a group name that includes the assignable or floating address. But this all misses the point. My point was, instead of having the address failover, just use DBPATH or sqlhosts groups to failover to the back up server's real address. Works just as well and probably more reliably without waiting for heartbeat detection to switch the addressing. Art S. Kagel > Sven > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art S. > Kagel (Oninit LLC) > Sent: Thursday, November 29, 2007 6:50 PM > To: ids@iiug.org > Subject: Re: How to Setup IDS for all IPs [10535] > > Martin Fuerderer wrote: > >> Hi Art, >> >> > > You do mention DBPATH and 'methods' but I think the focus on: > > "... the Secondary can keep running using its own IP-address. Then of > course the clients will have to use that IP-address for the re-connect > after failover." > > Doesn't make it clear that users and apps do NOT need to deal with the > two separate IP address/hostnames for the primary and backup servers but > can use connection failover mechanisms built into IDS communications > protocols (and ODBC/JDBC protocols for that matter) to failover using a > single 'server' name. > > Art S. Kagel > Oninit, LLC > >> I thought I mentioned DBPATH ... no? I think you even >> copied my mention of it in the snippet? :-) >> >> Yes, you are right with the group-concept in sqlhosts. >> That's why I wrote that we have mechanisms for such >> things and DBPATH is *one* example. >> >> I thought for one that explaining the group-concept >> in sqlhosts is a bit too much in that e-mail as it was >> (too) long already. >> And secondly I thought this way I give you a chance >> to explain the group concept - which you did nicely! :)) >> >> Thanks, >> Martin >> >> > > >

Hi, cause of application is not able to handle database errors, a reconnect must be done. I tried to use this line within the sqlhosts of my server: ids_db onsoctcp * ids_db and this one within my client ids_db onsoctcp db01haip ids_db Starting ids without ha ip and afterwards add haip with ifconfig. So the connection via dbhaip is possible. Thanks Sven -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art S. Kagel (Oninit LLC) Sent: Tuesday, December 11, 2007 6:58 PM To: ids@iiug.org Subject: Re: How to Setup IDS for all IPs [10705] Schuran, Sven wrote: > Hi, > > when I am using a "*" as IP/host in my sqlhosts file, > I may access the database through every IP with same port existing on the > server, even when it is assigned later. > > Clients still have to reconnect and the newly 'assigned' address has to be listed in the sqlhosts file and has to be named either in the INFORMIXSERVER or DBPATH environment variable or INFORMIXSERVER has to be set to a group name that includes the assignable or floating address. But this all misses the point. My point was, instead of having the address failover, just use DBPATH or sqlhosts groups to failover to the back up server's real address. Works just as well and probably more reliably without waiting for heartbeat detection to switch the addressing. Art S. Kagel > Sven > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art S. > Kagel (Oninit LLC) > Sent: Thursday, November 29, 2007 6:50 PM > To: ids@iiug.org > Subject: Re: How to Setup IDS for all IPs [10535] > > Martin Fuerderer wrote: > >> Hi Art, >> >> > > You do mention DBPATH and 'methods' but I think the focus on: > > "... the Secondary can keep running using its own IP-address. Then of > course the clients will have to use that IP-address for the re-connect > after failover." > > Doesn't make it clear that users and apps do NOT need to deal with the > two separate IP address/hostnames for the primary and backup servers but > can use connection failover mechanisms built into IDS communications > protocols (and ODBC/JDBC protocols for that matter) to failover using a > single 'server' name. > > Art S. Kagel > Oninit, LLC > >> I thought I mentioned DBPATH ... no? I think you even >> copied my mention of it in the snippet? :-) >> >> Yes, you are right with the group-concept in sqlhosts. >> That's why I wrote that we have mechanisms for such >> things and DBPATH is *one* example. >> >> I thought for one that explaining the group-concept >> in sqlhosts is a bit too much in that e-mail as it was >> (too) long already. >> And secondly I thought this way I give you a chance >> to explain the group concept - which you did nicely! :)) >> >> Thanks, >> Martin >> >> > > > ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. -------------------------------------------------------------------- Sie finden uns im Internet unter: www.maske.de Maske AG Behringstraße 120 22763 Hamburg Handelsregister Hamburg HRB 83369 USt-Ident.-Nr. DE 116 923 883 Vorstand: Andreas Maske Vors. d. Aufsichtsrates: Wolfgang Hönen Diese e-mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese e-mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene e-mail. Vielen Dank. This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

Schuran, Sven wrote: > Hi, > You miss my point. Yes, clients have to reconnect, either in error aware code that reconnects automatically (perhaps after waiting sufficient time for the disks to be mounted by the backup machine and for the backup server to come online (FYI with IDS 11.00 you can make that backup server live all the time sharing the disks as an SDS Secondary so apps/users don't have to wait to reconnect) or manually as you imply. My point is that if the backup server uses its OWN IP address instead of becoming the failed primary machine, then both addresses can be in the sqlhosts files on both servers AND on the client. Then you can either put the backup server's servername into the DBPATH environment variable or create a connection group in the sqlhosts files and connect using the group name. In either case the reconnect attempt will AUTOMATICALLY fail over to the backup server if the primary server is offline. If, as is usual in these failover schenarios the primary machine itself is offline, failover is very fast. I am also recommending that instead of using shared disk and restarting the server on the secondary you either use HDR to keep a live secondary or use the IDS 11.10+ SDS (shared disk secondary) server feature so that the secondary is always online and recovery from a primary crash is faster and more reliable without waiting for heartbeat detection. Art S. Kagel > cause of application is not able to handle database errors, a reconnect must > be done. > > I tried to use this line within the sqlhosts of my server: > ids_db onsoctcp * ids_db> > and this one within my client > > ids_db onsoctcp db01haip ids_db> > Starting ids without ha ip and afterwards add haip with ifconfig. > So the connection via dbhaip is possible. > > Thanks Sven > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art S. > Kagel (Oninit LLC) > Sent: Tuesday, December 11, 2007 6:58 PM > To: ids@iiug.org > Subject: Re: How to Setup IDS for all IPs [10705] > > Schuran, Sven wrote: > >> Hi, >> >> when I am using a "*" as IP/host in my sqlhosts file, >> I may access the database through every IP with same port existing on the >> server, even when it is assigned later. >> >> >> > > Clients still have to reconnect and the newly 'assigned' address has to > be listed in the sqlhosts file and has to be named either in the > INFORMIXSERVER or DBPATH environment variable or INFORMIXSERVER has to > be set to a group name that includes the assignable or floating > address. But this all misses the point. My point was, instead of > having the address failover, just use DBPATH or sqlhosts groups to > failover to the back up server's real address. Works just as well and > probably more reliably without waiting for heartbeat detection to switch > the addressing. > > Art S. Kagel > > >> Sven >> >> -----Original Message----- >> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art S. >> Kagel (Oninit LLC) >> Sent: Thursday, November 29, 2007 6:50 PM >> To: ids@iiug.org >> Subject: Re: How to Setup IDS for all IPs [10535] >> >> Martin Fuerderer wrote: >> >> >>> Hi Art, >>> >>> >>> >> You do mention DBPATH and 'methods' but I think the focus on: >> >> "... the Secondary can keep running using its own IP-address. Then of >> course the clients will have to use that IP-address for the re-connect >> after failover." >> >> Doesn't make it clear that users and apps do NOT need to deal with the >> two separate IP address/hostnames for the primary and backup servers but >> can use connection failover mechanisms built into IDS communications >> protocols (and ODBC/JDBC protocols for that matter) to failover using a >> single 'server' name. >> >> Art S. Kagel >> Oninit, LLC >> >> >>> I thought I mentioned DBPATH ... no? I think you even >>> copied my mention of it in the snippet? :-) >>> >>> Yes, you are right with the group-concept in sqlhosts. >>> That's why I wrote that we have mechanisms for such >>> things and DBPATH is *one* example. >>> >>> I thought for one that explaining the group-concept >>> in sqlhosts is a bit too much in that e-mail as it was >>> (too) long already. >>> And secondly I thought this way I give you a chance >>> to explain the group concept - which you did nicely! :)) >>> >>> Thanks, >>> Martin >>> >>> >>> >> > >