This topic gives you information about how to use VMware Tanzu RabbitMQ on Cloud Foundry Replicator to install multiple Tanzu RabbitMQ on Cloud Foundry 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 might 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.

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

Common Use Cases

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

• The unreplicated Tanzu RabbitMQ on Cloud Foundry 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.

Click here to view a larger version of the image above

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 Tanzu RabbitMQ on Cloud Foundry 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 Tanzu RabbitMQ on Cloud Foundry tile for SCS, as shown in the diagram below. You can then add replica RabbitMQ clusters for use by apps in the Marketplace.

VMware recommends that you use the unreplicated Tanzu RabbitMQ on Cloud Foundry tile solely for SCS to avoid contention between apps using SCS, and apps using Tanzu RabbitMQ on Cloud Foundry 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, deactivate 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 Tanzu RabbitMQ on Cloud Foundry 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 Tanzu RabbitMQ on Cloud Foundry 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 section describes how to install the replicator and generate replica tiles of Tanzu RabbitMQ on Cloud Foundry.

Prerequisites

• Tanzu RabbitMQ on Cloud Foundry v1.8.x or v1.9.x
• 2.5 GB of free disk space

Download the Replicator

The Tanzu RabbitMQ on Cloud Foundry Replicator is currently available from Broadcom Support. 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:

./rabbitmq-replicator-darwin\
--name YOUR-DESIRED-TILE-NAME\
--path PATH-TO-TILE\
--output DESIRED-FILE-NAME.pivotal

The following are the parameters expected in the above syntax:

Naming Conventions in Original and Replica Tiles

The table below shows the naming conventions for various components related to the original Tanzu RabbitMQ on Cloud Foundry 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:

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 the Pre-Provisioned Service. The On-Demand service is not offered on replica tiles.

Limiting Access to Replica Tiles to Specific Orgs

When you replicate Tanzu RabbitMQ on Cloud Foundry, 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:

   cf create-service-broker BROKER_NAME BROKER_USERNAME BROKER_PASSWORD BROKER_URL
   

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 Tanzu RabbitMQ on Cloud Foundry 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 Tanzu RabbitMQ on Cloud Foundry 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:

./rabbitmq-replicator-darwin\
--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 Tanzu RabbitMQ on Cloud Foundry Tile Replicator from Broadcom Support. You must download the version of Tile Replicator that corresponds with the version of the Tanzu RabbitMQ on Cloud Foundry 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:

    ./rabbitmq-replicator-darwin\
    --name NAME-OF-EXISTING-REPLICA \
    --path PATH-TO-NEW-TILE \
    --plan-uuid PLAN-UUID \
    --service-uuid SERVICE-UUID \
    --output /output/p-rabbitmq-v2-trading-team.pivotal
   

   Where:

   • 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 Tanzu RabbitMQ on Cloud Foundry 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.

Limitations

• The On-Demand service is not offered on replica tiles.