[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Load balancing/failover



Making, drinking tea and reading an opus magnum from Alejandro G. Belluscio:
> Daniel,
>      I've just subscribed, but on Sat, 10 Aug 2002 23:11:41 +0200 you
> replyed to Loic Cuguen regarding the non existence of a roadmap with:
> > There are certainly some larger goals that have not been achieved yet,
> > like redundancy/failover, load balancing, proxies for further
> > protocols, altq integration, etc.
>      I've always thought about the failover/load balancing by making an
> extension to rdr, something like
> 
> rdr-load on #if inet proto tcp from any to #ExtIf port www -> \
>     {#Ip1 port www, #Ip2 port www, #Ip3 port www} \
>     [balance-weight {4, 5, 9} #idnum | balance-round-robin #idnum]
> 
>    For this to work you'd need to keep state on the tcp connection and
> do something sane on udp. So when a Syn packet comes to the rdr-load
> address/port, you evaluate the balance algorithm (in this case I
> proposed round robin and some fix weight) decide some of the given IPs
> and so you make a rdr to that IP. I haven't taken a look at the pf code
> (not that I'm good enough to understand it) but I though this wouldn't
> kill performance (may be double the lookup time for the rdr packets) and
> shouldn't be too invasive. I've given #idnum so you could eventually
> change the weight or add/takeout IP from the pool for a given rule.
>      A second option would be to create a pseudo device that does the
> balancing, and have a whole syntax just for that, but then we would be
> duplicating information and processing time.
>      I haven't evaluated how would this interact with the route-from
> extension (if it's going to be merged :-) but any of the two alternative
> shouldn't be incompatible.
>      This is just a proposal, if has been discused before, apologies. If
> you find it stupid or uninformed just tell me where can I get more info
> to make better proposals.
ah, uh, my eyes.
this is an ugly hack that violates the whole concept of the networking.
we've discussed this w/ daniel a few times already.
there are a few different approaches here.
one might be to use a vrrp and a state sync between two pf boxens.
the other, in case there are two uplinks from one pf box
is to teach the networking stack about multiple routes to the same
destination and make it do the ballancing or whatever.
both this cases are doable and allow a whole bunch of other usefull
things to be implemented beyond one "useful" pf hack.
i find route-from a very bad idea myself.
cu
-- 
    paranoic mickey       (my employers have changed but, the name has remained)