RabbitMQ for PCF v1.9.5

Installing and Configuring RabbitMQ for PCF as an On-Demand Service

This topic provides instructions to Pivotal Cloud Foundry (PCF) operators about how to install, configure, and deploy the RabbitMQ for PCF tile to provide on-demand service.

Note: For instructions on how to install, configure, and deploy the RabbitMQ for PCF tile as a pre-provisioned service, see the documentation for pre-provisioned RabbitMQ for PCF.

Prerequisites for Deploying the On-Demand Service

Before deploying RabbitMQ for PCF as an on-demand service, you must ensure that the required network rules are in place to allow various components to communicate.

See Required Networking Rules for On-Demand Services for details on the network connections that must be open to enable the on-demand service.

For information on the on-demand service architecture, see this page.

Download and Install RabbitMQ for PCF

  1. Download the product file from Pivotal Network.

  2. Navigate to the Ops Manager Installation Dashboard and click Import a Product to upload the product file.

  3. Under the Import a Product button, click + next to the version number of RabbitMQ for PCF. This adds the tile to your staging area.

  4. Click the newly added RabbitMQ for PCF tile to configure the service.

Configure RabbitMQ for PCF

The configuration screen appears when you click the RabbitMQ for PCF tile in Ops Manager:

Configuring Errand Run Rules

Configure AZs and Networks

Follow the steps below to configure the AZs and networks.

  1. Click Assign AZs and Networks.

    IMPORTANT: You cannot change the regions or networks after you have clicked Apply Changes in the final step below.

  2. Configure the fields on the Assign AZs and Networks as follows:

    Place singleton jobs in Select the region that you want for singleton VMs. PCF creates the RabbitMQ broker in this AZ.
    Balance other jobs in Select additional region. This selection does not affect the on-demand RabbitMQ for PCF service.
    Network Select a network for the RabbitMQ On-Demand Broker.

    This should be a separate network from the one you select for Service Network. This network is represented by the Default Network in this picture. Typically, you select the network used for the Pivotal Elastic Runtime components.
    Service Network Select a separate network that the on-demand service instances run on.

    A typical practice is to put all on-demand services on a single network, separate from the network that ERT and the On-Demand Broker run on.
    This network is represented by the Services Network in this picture.

    This field is also required for the pre-provisioned service, though in that case, it doesn’t matter which network you select.

  3. Click Save.

Configure Global Settings

Follow the steps below to configure global settings.

  1. Click Dedicated Instance: Global Settings and configure the following:

    • Service instance quota min: 0, max: 50 set the total number of dedicated service instances which can be deployed.

    • VM options:

      Allow outbound internet access (IaaS-dependent). This checkbox must be ticked to allow external log forwarding, sending backup artifacts to external destinations, and communicating with an external BOSH blob store.
  2. Click Save.

Configure the Service Plan

In order to enable the on-demand service plan, you must configure the Dedicated Instance: Single Node Plan. The default name of this plan is Solo.

In the Dedicated Instance Single Node Plan, there is a single node in the cluster. However, there is still an HAProxy associated with the cluster.

Note: If the ODB feature is not enabled, the ODB is deployed alongside the RabbitMQ installation, but it is not available in the Marketplace.

  1. Click Dedicated Instance: Single Node Plan.


  2. Configure the fields on the Dedicated Instance: Single Node Plan as follows:

    Enable this plan Select the checkbox.
    Service instance quota Enter the maximum number of dedicated service instances that can be available at one time.
    Plan name Accept the default or enter a name. This is the name that appears in the Marketplace.
    Plan description Accept the default or enter a description.
    Plan features Accept the default or enter information about the plan to help your app developers.
    RabbitMQ VM Type Select a large VM type.
    The plan will create a service instance of this size.
    Persistent disk type This is where RabbitMQ will page messages to disk. See Disk Size Concerns for more details.
    AZ placement This field becomes available after you have completed the Assign AZs and Networks page.
    Select one AZ for the single node. The plan creates all the on-demand service instance VMs in this AZ.

  3. Click Save.

Resource Types and Disk Size Concerns

It is possible to configure the VM type for RabbitMQ and the size of the persistent disk that is going to be attached to the RabbitMQ instances.

Vm ram disk example

RabbitMQ raises alarms when disk space drops below the configured limit. Incorrect disk sizes may cause the deployed instance not to start. RabbitMQ declines to start if there is not enough space available according to the threshold.

Dedicated instances are configured with a threshold set to the 40% of the memory (RAM) of the VM. Operators can take the following table as an example when selecting the size of the persistent disk.

The following table shows an example of possible RAM values, absolute minimal value below which RabbitMQ declines to start, and the disk size suggested for an average use case.

RAM Free disk alarm threshold (0.4xRAM) Suggested disk size (2xRAM)
10 GB 4 GB 20 GB
16 GB 6.4 GB 32 GB
32 GB 12.8 GB 64 GB

For more information, see the following documentation links:

Verify the Stemcell

  1. Click Stemcell.

  2. Verify and, if necessary, import a new stemcell version.
    For more information, see the information about importing the stemcell for your IaaS: AWS, Azure, GCP, or vSphere.

Apply Changes from your Configuration

Your installation is not complete until you apply your configuration changes. Follow the steps below:

  1. Return to the Ops Manager Installation Dashboard.

  2. Click Apply Changes.

Configure Logging to Monitor RabbitMQ for PCF

Pivotal recommends that you configure logging to monitor the health of RabbitMQ for PCF. Follow this procedure to configure logging.


When deploying or updating RabbitMQ for PCF, Ops Manager can optionally run a series of post-deploy errands. An example is the Smoke Tests errand, which checks the health of the RabbitMQ cluster after a deploy or upgrade.

You can decide whether to run errands by toggling them on or off before an update. This is a one-time setting on the installation dashboard:

Configuring One-time Errands

IMPORTANT: As of RabbitMQ for PCF v1.9.0, all post-deploy errands are on by default. Pivotal recommends keeping these defaults, because the smoke tests can encounter unexpected issues, and dedicated instances of RabbitMQ for PCF may fall behind if the Upgrade All Service Instances errand is not on by default.

However, if necessary, you can change these defaults by clicking Errands in the RabbitMQ for PCF Settings tab.

For more information on errand run rules, see the Ops Manager documentation.

Post-Deploy Errands

Errand Description
Broker Registrar Makes the pre-provisioned RabbitMQ service plans available in the Marketplace
Smoke Tests Checks that a pre-provisioned RabbitMQ service instance can be bound to a Cloud Foundry app, and that the app can publish and subscribe to a RabbitMQ cluster (details below)
Register On-Demand Service Broker Makes the on-demand RabbitMQ service plans available in the Marketplace. If you change the Service Plan Configuration, you must run this errand in order for the changes to be reflected in the Marketplace.
Upgrade All Service Instances On-demand instances are updated and redeployed if there are changes to the Dedicated Instance settings or the tile is upgraded. If this errand is set to “Off” or “When Changed”, updates to Dedicated Instance settings will not be applied to existing service instances. Pivotal strongly recommends that this errand is configured to always run.

Pre-Delete Errands

Errand Description
Broker Deregistrar Removes the pre-provisioned RabbitMQ service from the Marketplace and deletes all associated service instances and bindings
Delete All Service Instances Unbinds and deletes existing dedicated service instances. The duration of this errand depends on the number of deployed dedicated instances.
Deregister On-Demand Service Broker Removes the on-demand RabbitMQ service from the Marketplace

Smoke Test Process

The smoke tests perform the following for each available service plan:

  1. Target the org system and create a cf space to run the tests.
  2. Deploy an instance of the CF RabbitMQ Example App this cf space.
  3. Create a RabbitMQ service instance and bind it to the CF RabbitMQ Example App.
  4. Check that the CF RabbitMQ Example App can write to, and read from, the RabbitMQ service instance.
  5. Clean up the deployed Example App and all its service bindings.
  6. Delete the cf space created for the tests.
Create a pull request or raise an issue on the source for this page in GitHub