|
On Tue, Oct 30, 2007 at 09:43:25AM +0200, Rumen Bogdanovski wrote:
>
> > > Well with this value and my patch restricting connection number on the
> > > backup according the u_threshold it is quite likely to end up in 15
> > > minutes connection refusal on the backup if a failover occurs, while the
> > > old ones are handled, but still depends, for some services it may simply
> > > mean 15 minutes downtime for no reason. It strongly depends on the
> > > service which timeout is acceptable. So user configurable timeout sounds
> > > reasonable. It should not be that difficult to make it configurable at
> > > daemon start up just like the syncid and syncinterface.
> >
> > Sure, lets make it so.
>
> Fine, I can bread normally now :)
>
>
> >
> > > > If however there are more serious problems created by having connection
> > > > entries lying around on the standby server that have been closed on
> > > > the master server, then thats probably not a problem that can be changed
> > > > by twiddling the timeout. Its probably a more fundamental problem.
> > > >
> > >
> > > Well is there any way to make a sunync on any state chagne of the
> > > connection?
> >
> > It is possible, though I'm not entirely convinced it would be a good
> > idea.
>
> Well, but it should be simple to implement, we just need to introduce,
> cp->old_state and to modify a bit the code bellow in ip_vs_core.c:
> if ((ip_vs_sync_state & IP_VS_STATE_MASTER) &&
> (cp->protocol != IPPROTO_TCP ||
> cp->state == IP_VS_TCP_S_ESTABLISHED) &&
> (atomic_read(&cp->in_pkts) % sysctl_ip_vs_sync_threshold[1]
> == sysctl_ip_vs_sync_threshold[0]))
> ip_vs_sync_conn(cp);
>
> I think it is a clean solution since both the master and the backup will
> be very well synchronized.
>
> Also I find it a good idea to sync the connections on ESTABLISHED to
> FIN_WAIT transition, this will reduce the hanging time to 2 minutes and
> we will avoid the short timeout if the conn is established.
I'm not oposed to this idea, but the synchronisation messages are
sent via UDP, and thus an individual message may not arrive
(though hopefully the majority of them will). I guess that
your scheeme will work anyway: In the case where the packet arrives
the state is updated; In the case where it doesn't then we
are just back to where we are now, but that shouldn't happen
very often (hopefully).
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
|
