I think a simple way to approach is to create Virtual machines and have those fail over between hosts instead of individual cluster resources. With this approach you woud only have a single state to be concerned with.
On 8/11/07, Eddie C <[EMAIL PROTECTED]> wrote: > > conntrackd RA...Sounds like an STD. :) > > I may be totally wrong about this but SSH session is a secure socket > layer. I think you are going to have disconnects even with conntrackd. > CIPHERS and re-keying. I could be wrong but SSL is a protocol designed > not to be tricked like this. I do not see it taking kindly to people > playing switch-a-roo with it. (sorry to get so technical) > > Remember HA failovers are generally in the SECOND not MILLISECOND > range. The same is true with the RA shell script. IPADDR2 is a shell > script. > > Even running ifup eth1 is not 'instantaneous' it takes a split second. > > I think if you add HA-FAILOVER time+Shell script time you are going to > lose the connection regardless. The minimum monitoring frequency is > one second I do not think setting that low is ever a good idea. > > > On 8/11/07, sebastien lorandel <[EMAIL PROTECTED]> wrote: > > On 8/9/07, Dejan Muhamedagic <[EMAIL PROTECTED]> wrote: > > > > > > On Thu, Aug 09, 2007 at 10:27:23AM +0200, sebastien lorandel wrote: > > > > Hi, thanks for your answer David, > > > > > > > > for iptables look into the conntrackd daemon and tools, those would > be > > > what > > > > > you > > > > > would use to syncronise the connection table from one firewall to > the > > > > > other. > > > > > > > > > Ok, so I don't need to manage iptables with Heartbeat, right? > > > > I think I just have to install iptables and conntrackd and to insert > a > > > RA > > > > script for conntrackd like this one: > > > > > > > > http://files.rfc2324.org/patches/conntrackd/heartbeat-ressources.d-script > > > > > > I'm afraid that it won't be that simple. conntrackd operates as a > > > multistate (master-slave) resource, i.e. there's an instance of > > > conntrackd running on both nodes, so you would need to implement > > > both promote and demote operations too. Unfortunately, conntrackd > > > can't say itself if it's a master instance or not, so you'll have > > > to keep track of that in the resource agent. Alternatively, > > > perhaps one could talk to the author and see if it would be > > > possible to implement the state in conntrackd itself (I assume > > > that that would be easier and cleaner). > > > > > > Ok I will try by myself and also ask on the netfilter mailig list if > > somebody has a clue. > > Did anybody here ever tried to install a conntrackd RA on it's heartbeat > > cluster? > > > > > what do you mean when you say you need to manage ssh sessions? if you > mean > > > > > they > > > > > go through the firewall, then the iptables stuff should fix this. > if > > > you > > > > > mean > > > > > that people connect to the firewall itself and you want the ssh > > > session to > > > > > failover to the backup, that's not possible. > > > > > > > > I would like to have my ssh user not to be deconnected when sshd > fails > > > on a > > > > node and has to be relaunched on another. I wish the session could > be > > > kept > > > > safe... > > > > > > I'm not sure if this is possible at all, at least not unless sshd > > > cooperates. You should talk about that with the ssh developers. > > > > > > Ok thanks. > > > > > And does nobody knows anything about this Stateful RA? > > > > > > > > sébastien Lorandel. > > > > > > > > > > > > -- > > Sébastien Lorandel > > _______________________________________________ > > Linux-HA mailing list > > [email protected] > > http://lists.linux-ha.org/mailman/listinfo/linux-ha > > See also: http://linux-ha.org/ReportingProblems > > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > -- Rob Aronson Storage, Virtualization and Orchestration Practice Manager, Novacoast USA _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
