|
> > 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.
What do you think?
Rumen
|
