Oh, I agree with all of that. My only point was that, if the environment isn't too crazy, you could have a varnish or nginx box running in an hour or two that would have a bigger impact than the tcp changes and wouldn't require making changes like that. That's why I started w/ the term "proxy" in front of load balancer, because the benefit you'd be deriving would be the tcp offload, not the load balancing (I considered leaving "load balancer" out entirely, maybe it would've been more clear if I had). :)
Nicholas On Fri, Jul 2, 2010 at 2:33 PM, Matt Lawrence <[email protected]> wrote: > On Fri, 2 Jul 2010, Nicholas Tang wrote: > > > Have you considered putting a proxy / load balancer in front of it > (running > > on a modern OS :) ) - varnish, for instance, or something like nginx - > that > > can absorb the workload of managing the TCP connections and just hand off > > the individual requests to the old Apache box on the back-end? There are > > others, too... haproxy... perlbal... I'm not sure how effectively they > work > > at TCP offload, but something like varnish or nginx should do the job. > It > > wouldn't require any changes to the actual server on the back-end, except > > *maybe* changing an ip address or port, and could be done pretty much > > entirely through DNS changes/ tricks. > > > > (I say this with no real knowledge of your infrastructure, but in theory, > it > > should work.) > > A lot of the architecture in this setup is ten years old. Things have > changed a lot in the last decade. The currently accepted way of doing > things is a pair of redundant load balancers talking to multiple > application servers that in turn talk to a redundant database setup. Ten > years ago, not so much. Ten years ago setting up application servers in a > HA cluster was the way to go. Today I'm suggesting they get rid of the HA > clustering and web servers, let the load balancers handle the failover. > Application servers should no longer be aware of their backup server, they > should just be aware that other application servers are running in > parallel. > > Longer term, I'm hoping to convince the folks here to go to architectures > that have been well accepted in the industry for the past few years. > Shorter term they are going to throw better hardware and RHEL 5 at the > problem. For the next few days, I'm trying to convince them that dropping > the tcp_fin_timeout to 30 seconds may get them by without more crashes. > Webserver has already wedged once today, the backup server in the cluster > took over without any issues (everyone was surprised that it actually > worked this time). > > -- Matt > It's not what I know that counts. > It's what I can remember in time to use. > _______________________________________________ > Tech mailing list > [email protected] > http://lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ >
_______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
