I'm planning a new infrastructure for our web application. We have two JBossAS5 servers, running in a cluster. Session state will be replicated via JBoss Cache.

In front of that, there should be some cache, to speed up delivery of static elements. However, most of the traffic to our app will be via HTTPS.

So far, I had been thinking of two Varnish caches in front of the JBossASs, each being configured for loadbalancing to the two JBossASs via round-robin. Since Varnish doesn't handle HTTPS, then there would need to be two pound proxies in front of the Varnishs, dealing with the HTTPS. The two pounds would be made high-available with Heartbeat/LinuxHA.

The traffic to www.example.com would then be going through our firewall, from there to the virtual IP of the pounds, from there to the Varnishs, and from there to the JBossASs.

Question 1: Does this make sense? Or is it overly complicated, and the same goal can be reached with simpler methods?

Question 2: If my layout is fine, how do I configure the pound -> Varnish step? Should I a) make the Varnish service high-available through Heartbeat/LinuxHA as well and direct traffic from pound to the virtual IP of the Varnishs, or should I rather b) Configure two independent Varnishs and use load-balancing in pound to address the different Varnishs?

Getting hardware loadbalancing is not an option, unfortunately, because of costs. This is no corporate, but a NGO system, and we're always short on money ... The whole thing is not mission-critical, but I'd like it to be as reliable as possible, because our IT is not always available on short notice (we don't have any full-time IT person employed ...).

Thanks a lot for your insight!



I think your approach makes sense. If you do not have the need for advanced caching of dynamic objects, then I would suggest using nginx as its capable of caching, https and loadbalancing. I do love Varnish, and I think most sites can gain a lot by using it, but based on your information it would make more sense to use nginx (+ heartbeat, or carp).

  • Nginx can cache dynamic objects, but I don't think it's possible to write rules based on uris (or part of them), cookies, connecting ip etc etc. Nginx can cache to disk and memcached, so it would be possible for your pair of nginx to have the same cache, more or less.
  • Can balance load, I think based on a session, ip hash and a lot more.
  • Does https very well.

Good luck! :)


I'd say the solution proposed is over engineered. There's a variety of technologies that would be suitable for your situation.

I use LVS for load balancing and SQUID for caching, particularly in regards to Jboss. For static content, it's generally better to serve from Apache. You can still use heartbeat or pacemaker for redundancy with these technologies.

The main reason I use SQUID is for rewrites but a lot of the content I deal with is dynamic. Caching is a bonus. Most of my Java applications have virtually no static content, so I often skip the mod_jk part. Point being, your requirements can drastically simplify even my proposed solution.

One possible example:

NAT to SQUID (ha cluster -> SQUID transparently proxies to LVS VIP -> LVS VIP to Apache cluster -> mod_jk to Jboss


Is there a reason you don't want to use a hardware load balancer?

Since you describe a HA design, I'm guessing this is a mission critical and possibly high traffic site. As such you may have the budget for such an appliance or appliances to provide HA at that layer.

An appliance such as F5 BigIP would provide you with more features and reliability than pound. You will be able to do ssl offloading to handle the https as well as caching and compression.

  • Thanks for your input, but we won't be able to afford hardware loadbalancing. Updated the original post to reflect this. – andreas-h May 22 '10 at 15:48

Adding more layers definitely makes it more difficult to maintain, but I don't think there's anything wrong with the basic approach. My first thought was that Squid does what you want for caching both http and https connections. I used it successfully for around 4 years on a photo hosting site.

Squid is here: http://www.squid-cache.org/. There are evidently some performance considerations: http://deserialized.com/reverse-proxy-performance-varnish-vs-squid-part-2/, but perhaps those drawbacks are offset by the support of https.

  • Squid will not terminate SSL, cache and start SSL. It would require something else to terminate SSL in front, so that all requests through it is http. Correct me if Im wrong. – 3molo Feb 10 '11 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.