Hi Willy,
> > But has any one looked at doing a SourceIP persistence which is not a > > hash i.e. a look up table of source IPs? > > We wanted to work on it but don't have the time to do everything, so... one > thing at a time :-) Why not just balance base on the source IP it work well for us, maybe I'm missing something here ;-) > > The maintenance of real servers is almost impossible in hash > > mode...without users on RDP (or other TCP app.) hitting the wrong > > server. > > yes, I know. I would also like to implement a dual source hash LB mode. It > would do the following : > - hash source => X, divide by total number of servers, returns Y > [0..nbsrv-1] > - if server Y is down, then divide X by number of available servers, > return Z > [0..nbsrvup-1], and use server Z. > > That way, if you lose a server, only this server's clients are > redispatched, > the other ones remain unaffected. This is only true when all servers are up > and we lose one. Because if only half the servers are up and you lose one, > about half of the users will move since they're already on the second hash. > A smarter method would consist in rehashing without the last server as long > as we get a DOWN server. But it would consume huge amounts of CPU for each > request and would probably not be much useful anyway. > > At first glance, the algorithm looks very simple, but when you take into > account the fact that there are already 2 weighted arrays (active and > backup), > it becomes less obvious how to implement this (we need 4 arrays now). So > we'll > keep that for a later version. > > > I might play with the aformentioned trick in the meantime though: > > server TS-1 10.0.0.102 check port 3300 > > server TS-1 10.0.0.102 check port 3389 backup > > > > I guess another option with maintenance is to allow a server weight of > > 0 (offline for maintenance) > > It's allowed now. It will be in version 1.3.19 tomorrow and it's already in > development version. And yes, it helps a lot, since it still supports > persistence (eg: for soft maintenance mode in HTTP). > > > and have two options for this: > > 1) Kill all connections immediately and move to new server. > > 2) Wait for old connections to timeout, and new connections go to new > server. > > you can do that when you restart haproxy with the new configuration, #1 is > done with "-st $oldpid", and #2 is done with "-sf $oldpid". > > Regards, > Willy > > > -- Guillaume Bourque, B.Sc., consultant, infrastructures technologiques libres 514 576-7638
