On Thursday 26 October 2006 22:28, Kevin Reay wrote: > Hey, > > On 10/26/06, Pete Vickers <[EMAIL PROTECTED]> wrote: > > If I recall correctly, > > You don't. :o) > > > slbd adds new rules to pf for each incoming > > tcp session. Since I couldn't get it to work (old version) I do not > > know what the session and Sources tables will look like, but I > > suspect there will be no problems with them in slbd. Client-server > > association is maintained by slbd and implemented with separate rules > > for each tcp session. > > slbd doesn't maintain separate rules for each tcp session. Client-server > association is NOT maintained by slbd. > > > This seems a bit ineffective and rather pointless since pf has the > > load balancing functionality built in. > > Which slbd relies on. Slbd just inserts the load balancing rules into > pf based on it's own config. Then it does the job of health-checking > the servers listed in it's config file, and removing them from the > server list if they go down. > > > The problems with using pf and a health checking script is related to > > removal of failed backends. There are two separate issues: > > > > 1) When using sticky-address in the rdr rules client-server > > associations are added to the internal Sources table. > > It is impossible to remove entries for a single backend from this > > table. If a backend fails and is removed from the rdr destination > > table this table will have to be flushed, making all clients end > > up on > > new backends, wich is unacceptable in many configurations. > > If this table is not cleared then the rdr destination table is not > > inspected for client IP's found in the Sources table. These clients > > will still be sent to the failed and removed backend. > > Preferably entries could be removed from this table based on > > source-IP and backend-IP:backend-port, and maybe even the virtual > > service IP:port or a pf rule number. > > Which is what slbd avoids. slbd doesn't use sticky-address for this reason. > slbd seems mostly geared for web servers where the web application > is written well enough to not need each request to go back to the same > server. > > Kevin
Hi Kevin I can come up with 100 reasons for using the same web target server over a whole session and very few for not doing it. Can't see we can use slbd for the ordering system as intended if requests goes to just any server in the pool. Or did I miss anything? Regards /Per-Olov
