This topic gives you information about how to use VMware Tanzu RabbitMQ for Tanzu Application Service Replicator to install multiple Tanzu RabbitMQ for Tanzu Application Service 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.
ImportantPrevious deprecation warnings for the pre-provisioned service are no longer in effect. VMware continues to support the pre-provisioned service.
The image below illustrates how to isolate SCS on Tanzu RabbitMQ for Tanzu Application Service from clustered and single node service instances dedicated to different teams. In this use case:
These scenarios are explained below in Running SCS on a Dedicated RabbitMQ Cluster and Providing a Pre-Provisioned Dedicated Cluster.
Replica Tanzu RabbitMQ for Tanzu Application Service 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 for Tanzu Application Service 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 for Tanzu Application Service tile solely for SCS to avoid contention between apps using SCS, and apps using Tanzu RabbitMQ for Tanzu Application Service 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.
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.
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 for Tanzu Application Service tile as shown in the diagram above.
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.
This section describes how to install the replicator and generate replica tiles of Tanzu RabbitMQ for Tanzu Application Service.
The Tanzu RabbitMQ for Tanzu Application Service Replicator is currently available from Broadcom Support. Search for and download this archive, and then run the enclosed binary.
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:
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, Tanzu RabbitMQ for Tanzu Application Service source tile that you downloaded |
output |
The desired file name and path for the replica tile |
The table below shows the naming conventions for various components related to the original Tanzu RabbitMQ for Tanzu Application Service 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 | Tanzu RabbitMQ for Tanzu Application Service | Tanzu RabbitMQ for Tanzu Application Service (finance) |
Tile name used internally by Ops Manager | p-rabbitmq | p-rabbitmq-finance |
Metrics/Logging Origin | p-rabbitmq | p-rabbitmq-finance |
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.
When you replicate Tanzu RabbitMQ for Tanzu Application Service, 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:
Set the broker registrar errand to Off, and apply your changes.
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
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
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 for Tanzu Application Service tile, using the replicator, and give the new replica the same name
as the existing replica. This is shown in the example workflow below.
Suppose you used the replicator to generate a replica of v1 of the Tanzu RabbitMQ for Tanzu Application Service 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:
Download and unzip the new Tanzu RabbitMQ for Tanzu Application Service Tile Replicator from Broadcom Support. You must download the version of Tile Replicator that corresponds with the version of the Tanzu RabbitMQ for Tanzu Application Service Tile you want to replicate.
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": {<br>
"guid": "a0a2fae9-e5de-47f5-b2b3-23cf07ff6142",<br>
},<br>
"entity": {<br>
"name": "single-node",<br>
"service_guid": "3e3a9413-50bd-4c76-a226-8721b0d2b3d7",<br>
}<br>
}
metadata
, guid
.entity
, service_guid
.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 for Tanzu Application Service 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.
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.