|
Hi
I've made IPVS to trigger synchronization on some connection status
changes: ANY->FIN_WAIT and ANY->CLOSE_WAIT. If CLOSE fails we will wait
2 minustes for the FIN_WAIT timeout, if even this fails, well we have to
live with the 15min tmout of this unfortunate connection.
Do you want a patch?
How do you want it? To be applied on top of the previous patch I have
sent or on vanilla source?
IMHO this would have to go hand in hand with Andy Gospodarek's patch.
Rumen
On Tue, 2007-10-30 at 18:09 +0900, Simon Horman wrote:
> 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).
>
|
