On 9/28/2012 4:44 AM, Adam Thompson wrote:
Silly as this may sound at this point I was "trying" to keep things
as simple as I could by using the TCP load balance feature rather
than a third party app like varnish. I, unfortunately at this time,
do not have the option of a separate box/boxes to turn up for load
balancing.
I will be working today to see if the idea you gave me for using a
/31 int the network drop down to snat outbound while keeping an eye
open for dropped packets. If this has problems I will go for 1:1
NAT for now and then get a pair of boxes to load balance with maybe
Varnish, HA proxy , or possibly Apache traffic server.
Thank You for all the help.
JohnM
That makes sense... but if all you're load-balancing is HTTP, you'll find
that using a reverse-proxy like Varnish makes your life a LOT easier than
doing it at the TCP or IP level. Using TCP load-balancing to load-balance
web servers is kind of like using a sledgehammer to kill a fly, IMHO. If
all you have is a sledgehammer, I guess it's better than nothing, but in
this case the flyswatter is free, and you're much less likely to hurt
yourself with it :-).
I know sullrich has commented very favourably on varnish in the past, and
I'd have to agree with him. Its only significant limitation is lack of
SSL support, IMHO.
For reverse-proxies on pfSense 2.1, you currently have Apache, HAproxy,
something called "Proxy Server with mod_security" (Apache with a newer
version of mod_security), Squid, Varnish, and Varnish v3. Stunnel can be
used to SSL-enable any of those that don't do SSL natively.
Any of these will take a little bit more setup than TCP load-balancing,
but the biggest headache you'll have (usually) is figuring out what the
various GUI fields mean.
There are some reasons you wouldn't want to use a reverse-proxy - those
mainly center around the web server needing to see the original client IP
address in the packet (and not just in the HTTP headers, where all the
proxies put it IIRC), or the web server needing to terminate SSL
connections instead of having the reverse-proxy do that.
Stretching my analogy a bit too far, the flyswatter may have been designed
by a programmer, and thus may have more adjustable knobs than you know
what to do with...
-Adam
Unfortunately 99% of all traffic will be HTTPS into the DMZ, which will
then relay pertinent info to the app tier which then pushes and pulls
to/from the DB tier. I haven't actually worked with Varnish yet but
have done some with HAProxy for inbound Load balance and it worked
rather well. I have heard many good things about Varnish also. Our web
servers do need to seethe original IP address but I know that HAproxy
has an "X-Forwarded-For" option that can be used for this purpose and I
"believe" Varnish has similar. As far as a fly swatter with to many
knobs, well that could be a very long thread!<g>
I did try using a /29(due to the addresses I wanted to include) CIDR on
the manual outbound NAT and lost all ability to even ping out of the
DMZ. Did not get as far as checking where I was losing packets but, it
was a 100% loss. Will be moving to 1:1 NAT today and will look at
getting a couple LB servers to run Varnish or such on when down the road.
Since I do not ,as of now, have the option of separate boxes for Varnish
or HAProxy, do you think these would be a better option to run on the
pfSense box considering what I would like to accomplish? Or, would I be
trading one headache for another. We currently have very low traffic
volume and due to the type of traffic I do not see it exceeding 20 to 25
meg in the next year. If it does I will have a good reason, and budget,
for more hardware. Yes I know hardware for this would not be a huge
expense but, a budget is a budget.
Thank You for all your help.
JohnM
_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list
