Deploying the RabbitMQ
Pre-Provisioned Service

Warning: RabbitMQ for Pivotal Platform v1.13 is no longer supported because it has reached the End of General Support (EOGS) phase as defined by the Support Lifecycle Policy. To stay up to date with the latest software and security updates, upgrade to a supported version.

Default Deployment

Deploying RabbitMQ for Pivotal Cloud Foundry (PCF) through Ops Manager deploys a RabbitMQ cluster of 3 nodes by default.

The deployment includes a single load balancer haproxy which spreads connections on all of the default ports, for all of the shipped plugins across all of the machines within the cluster.

The deployment occurs in a single availability zone (AZ).

The default configuration is for testing purposes only and Pivotal recommends that customers have a minimum of 3 RabbitMQ nodes and 2 HAProxy nodes

Deployment default

Considerations for this deployment

  • Provides high availability for the RabbitMQ cluster
  • Queues must be configured to be high availability as they are placed on one node by default
  • Customers should decide which partition behavior is best suited to their use case. For two nodes ‘automatic’ is preferred.
  • HAProxy is a single point of failure (SPOF)
  • The entire deployment is in a single AZ, which does not protect against external failures from failures in hardware, networking, etc.

Pivotal recommends that RabbitMQ for PCF is deployed across at least two AZs. Scale RabbitMQ server nodes to an odd number that is greater than or equal to three.

Only use replication of queues where required as it can have a big impact on system performance.

The HAProxy job instance count should also be increased to match the number of AZs to ensure there is a HAProxy located in each AZ. This removes the HAProxy SPOF and provides further redundancy.

Deployment recommended

The diagram above shows that you can now suffer the failure of a single HAProxy and single RabbitMQ node and still keep your cluster online and applications connected.

Upgrading to this deployment from a single AZ deployment

It is not possible to upgrade to this setup from the default deployment across a single AZ.

This is because the AZ setup cannot be changed after the tile has been deployed for the first time. This is to protect against data loss when moving jobs between AZs.

Upgrading to this deployment from a multi AZ deployment

If you have deployed the tile across two AZs, but with a single HAProxy instance, you can migrate to this setup by deploying an additional HAProxy instance through Ops Manager. New or re-bound applications to the RabbitMQ service see the IPs of both HAProxies immediately. Existing bound applications will continue to work, but only using the previously deployed HAProxy IP Address. They can be re-bound as required at your discretion.

Considerations for this deployment

  • Requires IaaS configuration for AZs ahead of deploying the RabbitMQ tile
  • Application developers are handed the IPs of each deployed HAProxy in their environment variables
  • Queues must be configured to be high availability as they are placed on one node by default
  • Customers should decide on which partition behavior is best suited to their use case. For three or more nodes 'pause_minority’ is preferred.

Advanced Deployment

This deployment builds upon the above recommended deployment and so follows the same upgrade paths.

This allows you to replace the use of HAProxy with your own external load balancer.

You might choose to do this to remove any knowledge of the topology of the RabbitMQ setup from application developers.

Deployment advanced


  • Application developers do not need to handle multiple IPs for the HAProxy jobs in their applications


  • The load balancer needs to be configured with the IPs of the RabbitMQ Nodes. These are only be known after the deployment is finished. The IPs should remain the same during subsequent deployments but there is a risk they might change.

It is possible to first deploy with multiple HAProxy jobs, as per the recommended deployment, and later use your own external load balancer.

This can be achieved without downtime to your applications. Follow these steps to do so:

  1. Configure your external load balancer to point to the RabbitMQ Node IPs.
  2. Configure the DNS name or IP address for the external load balancer (ELB) on the RabbitMQ tile in Ops Manager.
  3. Deploy the changes. Any new instances of the RabbitMQ service or any re-bound connections will use the DNS name or IP address of the ELB in their VCAP_SERVICES. Any existing instances will continue to use the HAProxy IP addresses in their VCAP_SERVICES
  4. Phase the re-binding of existing applications to update their environment variables.
  5. After all applications are updated, reduce the instance count of the HAProxy job in Ops Manager to 1.
  6. Deploy the changes.

This approach works as any existing bound applications have their VCAP_SERVICES information cached in Cloud Controller and are only updated by a re-bind request.

If you are currently using an external load balancer, then you can move back to using HAProxies instead.

You can achieve this by following the above steps in reverse order and re-instating the HAProxy jobs.

Resource requirements

The following table shows the default resource and IP requirements for installing the tile:

Product Resource Instances CPU Ram Ephemeral Persistent Static IP Dynamic IP
RabbitMQ RabbitMQ node 3 2 8192 16384 30720 1 0
RabbitMQ HAProxy for RabbitMQ 1 1 2048 4096 0 1 0
RabbitMQ RabbitMQ service broker 1 1 2048 4096 0 1 0
RabbitMQ Broker Registrar 1 1 1024 2048 0 0 1
RabbitMQ Broker Deregistrar 1 1 1024 2048 0 0 1
RabbitMQ Smoke Tests 1 1 1024 2048 0 0 1
RabbitMQ RabbitMQ on-demand broker 1 1 1024 8192 1024 0 1
RabbitMQ Register On-Demand Service Broker 1 1 1024 2048 0 0 1
RabbitMQ Deregister On-Demand Service Broker 1 1 1024 2048 0 0 1
RabbitMQ Delete All Service Instances 1 1 1024 2048 0 0 1
RabbitMQ Upgrade All Service Instances 1 1 1024 2048 0 0 1
RabbitMQ Recreate All Service Instances 1 1 1024 2048 0 0 1


  • The number of RabbitMQ Node can be increased if required.
  • Changing the number of RabbitMQ nodes when the erlang cookie is not defined will restart the cluster. Check here for more information.
Was this helpful?
What can we do to improve?