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
