Ask Your Question

Horizon HA, Mirantis deployment

asked 2014-10-06 09:07:22 -0500

tomstephens89 gravatar image

updated 2014-10-06 11:18:13 -0500

mpetason gravatar image

Hi there,

I have been testing a HA deployment of Mirantis Openstack deployed with fuel. 3 controller nodes, 1 compute and 3 ceph nodes.

Mirantis configures HA automatically according to the documentation, but i am wondering on the best/easiest method to enable HA for the Horizon dashboard since I don't think Horizon is made highly available via internal pacemaker/sync methods.

Am I correct? If so, could i just throw a load balancer in front and add the IP of the 3 controllers to it? Or does Mirantis have a trick up its sleeve that I don't know about for Horizon HA?


edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted

answered 2014-10-06 11:17:39 -0500

mpetason gravatar image

If you are deploying HA then the IP address you receive for the Horizon login is actually a VIP. You can check out the configuration in /etc/haproxy/. You'll be able to see the VIP + the three other IP addresses associated with Horizon. Other services may be behind the VIP as well, but you may not see them with CRM because they do not need to be managed the same way:

crm resource list

You'll see HAproxy in listing from the above command.

edit flag offensive delete link more


Thanks for the info. So I suppose this means that Horizon is already in a HA set up behind that VIP. So in theory if I go and kill the primary controller, shortly after horizon should be available to me again automatically via that VIP?

tomstephens89 gravatar imagetomstephens89 ( 2014-10-06 11:24:32 -0500 )edit

Yes, it should work. There are bug fixes in 5.1 that differ from 5.0.1, so it will depend on your version. If you kill a controller node, and have others still available, you will be able to hit Horizon. Basically the VIP just needs to be handed off like you described.

mpetason gravatar imagempetason ( 2014-10-06 11:27:57 -0500 )edit

answered 2015-12-07 14:24:46 -0500

sxc731 gravatar image

updated 2016-02-19 02:39:02 -0500

For future reference, here's the path I have followed as I've just been through the pain of setting this up atop Mirantis OpenStack 6.1 (HA deployment) running on Ubuntu Trusty. With necessary adjustments, this probably works for other HA deployments that leverage HAProxy...

First a note on the rationale: I'm not 100% certain about this but my gut feel is that in order to implement HTTP session affinity that Horizon requires, the SSL connection has to be terminated at the HAProxy layer, so it can inspect its SERVERID cookie. This would obviously not be a concern if Horizon didn't sit behind HAProxy, in which case one can simply follow these instructions and it's probably all a fair bit easier...

So let's implement the HAProxy compatible solution. I've mostly followed the instructions from the very nice folks at DigitalOcean:

You'll need to carry out the following on all three controllers. Don't forget to backup what you change in case of goofs...

  1. Generate a self-signed private key/certificate, eg: sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout my_horizon.key -out my_horizon.crt (if you need help with this refer to the above DigitalOcean tutorial)
  2. Combine the private key and certificate as explained in the instructions: cat my_horizon.crt my_horizon.key > /etc/ssl/private/my_horizon.pem
  3. Now I suppose we ought to ensure the haproxy process can read that file (and take care of appropriately protecting all those sensitive private keys!). On my setup (as deployed by Fuel), the /etc/ssl/private directory is readable by the ssl-cert group; seems perfectly reasonable so I'm adding that group to the haproxy user: usermod -a -G ssl-cert haproxy
  4. Still following the DO tutorial, add the following to the global section in /etc/haproxy/haproxy.cfg: tune.ssl.default-dh-param 2048
  5. Now edit /etc/conf.d/015-horizon.cfg and add following lines underneath the bind line (we're adding both X-Forwarded-Proto and ...Protocol because it looks like Django changed its mind on this around v1.5. In theory the short version should suffice for newer version):
    reqadd X-Forwarded-Proto:\ https
    reqadd X-Forwarded-Protocol:\ https
    redirect scheme https code 301 if !{ ssl_fc }
  6. Still in 015-horizon.cfg replace the bind line. Keep the IP (this is the public VIP, corresponding to the CRM resource vip__public); but replace port 80 with 443 and append ssl crt /etc/ssl/private/my_horizon.pem at the end of the line.
  7. This is nearly good enough but will result in Horizon often generating http URLs (instead of https) which break the application flow; whilst they can be corrected manually in the browser address bar, it's clearly not acceptable. The solution is to edit /etc/openstack-dashboard/ and uncomment the line that starts with SECURE_PROXY_SSL_HEADER (which is the reason we are asking haproxy to add this parameter to HTTP requests when it forwards it, with reqadd X-Forwarded-Protocol:\ https)
  8. Now time to restart everything:
    service apache2 reload
    crm resource restart p_haproxy
  9. Take ...
edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2014-10-06 09:07:22 -0500

Seen: 2,286 times

Last updated: Feb 19 '16