Hi Per-Olav,
If you are dealing with http based services, rather than generic tcp,
then you could take a look at 'pound'. I did a port of it a while
back, and use it in pretty large scale environment here, it supports
sticky backend etc. Works well for me, YMMV.
http://marc.theaimsgroup.com/?l=openbsd-ports&m=115513682623098
/Pete
On 26. okt. 2006, at 23.26, Per-Olov Sjvholm wrote:
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
