Apache load balancing setup considerations

Plone Support Deployment & hosting
1

I'm currently setting up load balancing for my Plone (still 4.3) site. Currently it doesn't use ZEO but RelStorage, but when it comes to Load Balancing, this shouldn't make any difference, right?

My site is accessible over 3 different hostnames (plus optional www. prefixes which are done by redirection-only mini-host); multiplied by two protocols (http and https), this results in six virtual hosts. That's no maintenance problem, since those six hosts are generated by macros, and so the configuration is in synch automatically.

However, when changing to a load balancing setup, some questions arise.

First - should I unite my virtual hosts and put them all in one? Reasons I could imagine:

  • One place to enable or disable worker processes (/balancer-manager) instead of six;
  • http hosts could be managed by TLS-secured balancer manager;
  • worker processes (which are common to all those hosts) probably shouldn't be attached to more than one balancer
  • server resources considerations: Does it make a difference for Apache whether I have one load balancer or six?

Reasons not to do so:

  • Currently I don't need to use variables for %{HTTP_HOST} and the like; this kind of information is created during macro expansion, i.e. at configuration load time;
  • same for conditional redirections, e.g. to enforce HTTPS for login forms and management views.
  • (edit: added) cached pages contain slightly different contents depending on the hostname, e.g. different logo graphics, but as well different contents subsets

Is it possible and/or desirable to have a VirtualHost serve both HTTP and HTTPS (e.g. using SSLEngine optional? (the <VirtualHost> directive can take more then one ip:port specification)
How would I configure stickyness, and would I e.g. need to install plone.app.caching?

Links, so far:

2

Have you considered redirecting all incoming HTTP requests to the equivalent HTTPS urls? It would be one less problem to deal with.

3

Yes, I have. I do redirect most traffic to HTTPS already (and once you are there, you stay there, of course), including the root-only path "/", but I'm not able yet to shut down HTTP entirely, since I have an old PDFReactor, running in an ancient JVM, which can't cope with modern TLS settings. (This should change some time soon, but that's the current situation).

It might be possible to restrict HTTP access to one requesting IP address, though, and redirect the rest; I'd need to figure this out.

1 Like
4

I did it; Apache configuration snippet:

RewriteCond expr "! -R '12.34.56.78'"
RewriteCond %{REQUEST_URI} !^/(.well-known|balancer-manager)
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R]

This is located before all other redirections in that VirtualHost; I have a few URL corrections which need RewriteCond anyway, so I don't use Redirect and ProxyPass at all.

The exclusion of /.well-known is for Let's Encrypt's certbot utility.

5

Just be aware of this quirk: LetsEncrypt / ACME protocol - verification string may cause Zope BadRequest error - as in: don't let Zope/Plone serve these files...

6

I had a look; in that nginx configuration, there is an alias for that very special sub-location.

In my setup, I have an alias .well-known which points to the very same directory for all HTTP virtual hosts (/var/www/4certbot), and Zope won't ever see any request starting with /.well-known (because of a RewriteCond before the final RewriteRule [P]. This works like a charm.