Isolating Clusters with the RabbitMQ for PCF Replicator

Warning: RabbitMQ for Pivotal Cloud Foundry v1.17 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.

Note: Previous deprecation warnings for the pre-provisioned service are no longer in effect. Pivotal continues to support the pre-provisioned service.


RabbitMQ for PCF Replicator is a tool that allows you to install multiple RabbitMQ for Pivotal Cloud Foundry (PCF) tiles in a single Ops Manager environment. This lets you run multiple pre-provisioned RabbitMQ clusters that are isolated from each other.

For example, you may want to isolate the cluster serving Spring Cloud Services (SCS) from the cluster serving apps in the Marketplace. Or you may want to give a certain team their own dedicated, pre-provisioned cluster that you manage for them. For information on how to accomplish these scenarios, see Common Use Cases.

Common Use Cases

The image below illustrates how to isolate SCS on RabbitMQ for PCF from clustered and single node service instances dedicated to different teams. In this use case:

  • The unreplicated RabbitMQ for PCF tile deploys two types of services:
    • A pre-provisioned service is used as a backing service for SCS
    • An on-demand service is used to create three completely isolated single node service instances
  • Two replica tiles are used to create two dedicated pre-provisioned clusters, with each one dedicated to a specific team.

    flowchart Click here to view a larger version of this image.

These scenarios are explained below in Running SCS on a Dedicated RabbitMQ Cluster and Providing a Pre-Provisioned Dedicated Cluster.

Running SCS on a Dedicated RabbitMQ Cluster

Replica RabbitMQ tiles cannot be used to provide a backing service for Spring Cloud Services (SCS) because SCS expects that the service is called p-rabbitmq. Therefore, if you want to isolate the RabbitMQ cluster that is used by SCS from other tenants, you can reserve the unreplicated RabbitMQ for PCF tile for SCS, as shown in the diagram below. You can then add replica RabbitMQ clusters for use by apps in the Marketplace.

Pivotal recommends that you use the unreplicated RabbitMQ for PCF tile solely for SCS to avoid contention between apps using SCS, and apps using RabbitMQ for PCF in the Marketplace.

To reserve the unreplicated tile for SCS, turn off the Broker Registrar errand to prevent the broker from being exposed in the Marketplace. For more information, see Errands.

To offer RabbitMQ as a cloud messaging service in the Marketplace, create one or several replicas, install them in Ops Manager, and either allow the broker registrar errand to run, or register the service manually using CF.

Providing a Pre-Provisioned Dedicated Cluster

To reserve a RabbitMQ cluster for use by a specific team, disable the Broker Registrar errand in Ops Manager. This prevents service registration in the Marketplace. For more information, see Errands.

After you deploy the tile, manually expose the service broker to your desired orgs and spaces. For instructions, see Register a Broker.

Using Replicas While Offering the On-Demand RabbitMQ Service

The On-Demand service is not offered in replica tiles, since the purpose of the replicator is to create additional pre-provisioned clusters. If you wish to offer on-demand service plans, use the unreplicated RabbitMQ for PCF tile as shown in the diagram above.

Blue-Green Upgrades (Advanced)

In order to do blue-green style upgrades to minimize downtime, you can stand up a new cluster and migrate data and users over to the new cluster over a period of time. Speak with your Platform Architect about how to enable this workflow.

Generating Replica Tiles

This topic describes how to install the replicator and generate replica tiles of RabbitMQ for PCF.


  • RabbitMQ for PCF v1.8.x or v1.9.x
  • 2.5 GB of free disk space

Download the Replicator

The RabbitMQ for PCF Replicator is currently available from Pivotal Network. Search for and download this archive, and then run the enclosed binary.

Generate Replica Tiles

The following is the syntax for generating a replica tile:

--path PATH-TO-TILE\
--output DESIRED-FILE-NAME.pivotal

The following are the parameters expected in the above syntax:

Parameter Description
name The desired unique identifier for the replica tile, which is used to generate manifests, deployment names, and Marketplace name for the service. Only alphanumeric characters and - are accepted by the tool.
path The location of the original, unreplicated, RabbitMQ for PCF source tile that you downloaded
output The desired file name and path for the replica tile

Naming Conventions in Original and Replica Tiles

The table below shows the naming conventions for various components related to the original RabbitMQ for PCF tile and to the replica tile.

For the purposes of this example, assume that when you generate a replica tile as shown above, in the name field you provide the string finance\. Then the attributes for the original and replica tiles are as follows:

Component Name with Original Tile Name with Replica Tile
Broker name p-rabbitmq p-rabbitmq-finance
Broker URL pivotal-rabbitmq-broker.YOUR_CF_DOMAIN pivotal-rabbitmq-broker-finance.YOUR_CF_DOMAIN
Service name p-rabbitmq p-rabbitmq-finance
URL for the RabbitMQ Management UI pivotal-rabbitmq.YOUR_CF_DOMAIN pivotal-rabbitmq-finance.YOUR_CF_DOMAIN
Tile display name in Ops Manager RabbitMQ RabbitMQ (finance)
Tile name used internally by Ops Manager p-rabbitmq p-rabbitmq-finance
Metrics/Logging Origin p-rabbitmq p-rabbitmq-finance

Installing Replica Tiles

After you have generated a replica tile, you can upload it to Ops Manager as you would any other tile. After you have uploaded it, follow the instructions for Installing and Configuring RabbitMQ for PCF as a Pre-Provisioned Service. The On-Demand service is not offered on replica tiles.

Limiting Access to Replica Tiles to Specific Orgs

When you replicate RabbitMQ for PCF, the replica tile has the Broker Registrar errand set to On by default. This field appears in the Errands tab in the tile:


With any tile, if the Broker Registrar errand is set to On, it runs automatically when you finish installing the tile and causes the tile to be available to all CF orgs.

If you want to limit access to the tile to a specific org, follow these steps:

  1. Set the broker registrar errand to Off, and apply your changes.

  2. Manually register the tile with a specific CF org using the following command. See the above table for BROKER_NAME, BROKER_URL, and SERVICE_NAME:

  3. To give access to the org, use the following command and repeat for each additional org:

    cf enable-service-access SERVICE_NAME -o ORG_NAME

Upgrading Replica Tiles

You can upgrade replica tiles like regular tiles with one important difference. You must generate a replica of the newer version of the RabbitMQ for PCF tile, using the replicator, and give the new replica the same name as the existing replica. This is shown in the example workflow below.

Example of an In-Place Upgrade of a Replica

Suppose you used the replicator to generate a replica of v1 of the RabbitMQ for PCF tile, with the name trading-team, and you installed it in Ops Manager. Here is the sample replicator command you used for the initial installation:

--name trading-team\
--path /download/p-rabbitmq-v1.pivotal\
--output /output/p-rabbitmq-v1-trading-team.pivotal

To upgrade to v2, follow these steps:

  1. Download and unzip the new RabbitMQ for PCF Tile Replicator from Pivotal Network. You must download the version of Tile Replicator that corresponds with the version of the RabbitMQ for PCF Tile you want to replicate.

  2. Find the plan UUID and Service UUID for the service plan you want to update.
    To do this, you can use the CF API. Run the following command, then search the result for the section about the service plan you want:

    cf curl /v2/service_plans

    The result is similar to the following, with some extra properties:

         "metadata": {
            "guid": "a0a2fae9-e5de-47f5-b2b3-23cf07ff6142",
         "entity": {
            "name": "single-node",
            "service_guid": "3e3a9413-50bd-4c76-a226-8721b0d2b3d7",
    • The plan UUID is found under metadata, guid.
    • The service UUID is found under entity, service_guid.
  3. Run the replicator command below to create the replica:

      --path PATH-TO-NEW-TILE \
      --plan-uuid PLAN-UUID \
      --service-uuid SERVICE-UUID \
      --output /output/p-rabbitmq-v2-trading-team.pivotal


    • NAME-OF-EXISTING-REPLICA must be the same as the name used for the existing replica. This is trading-team in this example.
    • PATH-TO-NEW-TILE is the path to the new RabbitMQ for PCF v2 tile.
    • PLAN-UUID is the plan UUID found in Step 2.
    • SERVICE-UUID is the service UUID found in Step 2.

    Specifying the parameters --plan-uuid and --service-uuid ensures the new replica updates the existing service offering and plans.

  4. After you have the replica tile p-rabbitmq-v2-trading-team.pivotal, upload it to Ops Manager. This upgrades the v1 replica tile in place.

You can then proceed with upgrading the cluster.

If you want to do a blue-green style upgrade, see Blue-Green Upgrades.


  • The On-Demand service is not offered on replica tiles.
Was this helpful?
What can we do to improve?