8.4.5. Broker Web Application
Because the broker application is stateless, enabling redundancy is relatively easy. You can set up instances on multiple hosts with a standard HTTP/HTTPS load balancer, such as Apache HTTP Server, HAProxy, or any existing solution, to distribute requests. Enabling sticky sessions is not required.
However, if access to redundant brokers is implemented with a reverse proxy, verify that the request from the proxy is for the public address. The broker API document is generated with the
Host: header by which it is addressed; this includes URLs to various functionality. Clients can be directed to private URLs by way of the API document if the reverse proxy request does not preserve the client's Host: header.
For example, if you have a proxy at
broker.example.com that distributes loads to broker1.example.com and broker2.example.com, the proxy request to broker1.example.com should be https://broker.example.com. If a httpd proxy is used, for example, enable the ProxyPreserveHost directive. For more information, see ProxyPreserveHost Directive at http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypreservehost.
Important
When multiple broker hosts are deployed, the authentication keys need to be the same for all broker hosts. Update
/etc/openshift/server_pub.pem and /etc/openshift/server_priv.pem, and update the AUTH_SALT setting in the/etc/openshift/broker.conf file. Failure to synchronize these will result in authentication failures where gears make requests to a broker host while using credentials created by a different broker host in scenarios such as auto-scaling, Jenkins builds, and recording deployments.
