This document describes how to install HAProxy after the upgrade from 3.10.x to 4.0.x.
Author: Marc Cirauqui
Install HAProxy on the UI Server
Before you begin: check that you have the epel-release package installed. Otherwise HAProxy might not be available or it might be an old version.
# yum -y install haproxy
Configure HAProxy
The configuration to use depends on your architecture.
Running websockify on each Remote Services server
If you have multiple datacenters and are running websockify on each Remote Services server, you will need to define the backend for each server. Configure the UI server with the following model for the /etc/haproxy/haproxy.cfg file and make the changes described below.
global user haproxy group haproxy log /dev/log local0 maxconn 1024 frontend public bind *:41337 ssl crt /etc/pki/abiquo/haproxy.crt mode http timeout client 3600s log global acl 2af9eaa6f48878b7952cbca17bc3d784b642d2ac path 2af9eaa6f48878b7952cbca17bc3d784b642d2ac use_backend 2af9eaa6f48878b7952cbca17bc3d784b642d2ac if 2af9eaa6f48878b7952cbca17bc3d784b642d2ac backend 2af9eaa6f48878b7952cbca17bc3d784b642d2ac balance source mode http log global timeout queue 3600s timeout server 3600s timeout connect 3600s server websockify0 13.19.20.20:41338 weight 1 maxconn 1024 check
The frontend block defines where HAProxy will listen for browser connections, which in this case is port 41337. The bind line also specifies the SSL certificate. Use the same one as you use in the UI to avoid certificate warnings. Note that HAProxy only takes one file so you may need to concat certificate and private key into a single file (use cat cert key > haproxycert).
For multiple datacenters in Abiquo, you will need websockify installed on every Remote Services server. Then configure these servers by creating acl and use_backend lines and backend blocks as described here.
For each remote services server, copy the acl and use_backend lines and replace the hash values. To create the hashes for a server, generate an SHA1 digest of the value of the abiquo.datacenter.id property. For example:
# grep datacenter.id /opt/abiquo/config/abiquo.properties
abiquo.datacenter.id = ss008063
## With openssl toolkit
# echo -n ss008063 | openssl dgst -sha1 | cut -f2 -d' '
2af9eaa6f48878b7952cbca17bc3d784b642d2ac
## With ruby
# ruby -e 'require "digest/sha1"; puts Digest::SHA1.hexdigest "ss008063"'
2af9eaa6f48878b7952cbca17bc3d784b642d2ac
## With python
# python -c "import hashlib; print hashlib.sha1('ss008063').hexdigest()"
2af9eaa6f48878b7952cbca17bc3d784b642d2ac
So requests with path 2af9eaa6f48878b7952cbca17bc3d784b642d2ac will use backend named 2af9eaa6f48878b7952cbca17bc3d784b642d2ac.
To create the backend block, copy the backend text from the example above, but in the server line, replace the IP and port value with the values for the websockify daemon on the corresponding Remote services server.
When you have all the acl and use_backend lines, as well as the backend blocks for all the datacenters, restart the haproxy daemon to start routing requests.
Running one default websockify daemon
If you have multiple datacenters with ESXi hosts and you can allow access to all hosts in all datacenters, then you could use the following configuration with a single default websockify daemon.
global daemon maxconn 1024 frontend public bind *:41337 ssl crt /etc/pki/abiquo/haproxy.cer timeout client 3600s default_backend ws backend ws balance source timeout queue 3600s timeout server 3600s timeout connect 3600s server websockify1 127.0.0.1:41338 weight 1 maxconn 1024 check
Here the frontend block does not have acl or use_backend statements, but instead has a default_backend pointing to the only backend available. That backend in turn, points to the websockify daemon.