This topic gives you information about how to upgrade VMware Tanzu RabbitMQ for Tanzu Application Service.
VMware Tanzu RabbitMQ for Tanzu Application Service enables automated upgrades between versions of the product. In some versions, you might be required to take the RabbitMQ cluster offline. Whenever this is necessary, it is noted in the release notes for those versions.
For product versions and upgrade paths, see Upgrade Planner.
This topic applies to both the on-demand and pre-provisioned services.
Upgrade Tanzu RabbitMQ for Tanzu Application Service
To upgrade the product:
- Review the release notes for the version that you are upgrading to. See Tanzu RabbitMQ for Tanzu Application Service Release Notes.
- Download the latest version of the product from VMware Tanzu Network.
- Upload the new .pivotal file to Ops Manager.
- If required, upload the stemcell associated with the update.
- If required, update any new mandatory configuration parameters.
- Ensure BOSH DNS is enabled. This is enabled by default. If you have deactivated BOSH DNS, you must activate it for BOSH Hot Swaps to work. For more information, see BOSH Hot Swap below.
- Ensure the
register-on-demand-service-brokererrand is enabled. This errand is enabled by default, but if it has been deactivated, it can be re-activated by navigating to the Errands pane and selecting On for Register On Demand Service Broker. - (Optional) If you want developers to individually upgrade service instances, navigate to the Errands pane and select Off for Upgrade All Service Instances.
By default, theupgrade-all-service-instanceserrand runs after each upgrade. For more information, see About Individual Service Instance Upgrades below. - Click Review Pending Changes. For more information about this Ops Manager page, see Reviewing Pending Product Changes.
- Click Apply Changes. The rest of the process is automated.
General Notes About the Upgrade Process
The following notes about the upgrade process apply to upgrading to any version of Tanzu RabbitMQ for Tanzu Application Service.
-
Upgrading to a newer version of the product does not cause any loss of data or configuration.
-
It might take busy RabbitMQ nodes a long time to shut down during the upgrade and you must not interrupt this process.
-
To benefit from rolling upgrades, configure your apps to reconnect after a node restarts. For more information, see Handling Node Restarts in Applications in the RabbitMQ documentation.
-
The benefit you get from stemcell rolling upgrades depends on how you have configured network partition handling and the Resource Config tab. An HAProxy instance count of 2 and a RabbitMQ node count of 3 are required for rolling stemcell upgrades. These counts are the default. For more information, see Clustering and Network Partitions.
-
Ops Manager ensures the instances are updated with the new packages and any configuration changes are applied automatically
Downtime during Upgrades
The length of downtime during upgrades depends on whether there is a stemcell update to replace the operating system image, or whether the update is for the RabbitMQ software only.
The RabbitMQ cluster becomes unavailable only when upgrading between specific versions of Erlang or RabbitMQ. This is stated in the release notes for those versions. For on-demand service instances created with Tanzu RabbitMQ for Tanzu Application Service v1.20 and later, stemcell updates no longer incur additional downtime while the IaaS creates the new VM. For more information, see BOSH Hot Swap below.
Resilient apps are less likely to crash during downtime. For how developers can create resilient apps, see the resiliency-workloads repository in GitHub.
A guide for downtime during upgrade deployments is shown in the table below. In some cases, the RabbitMQ cluster remains available during a tile upgrade, but individual queues on cluster nodes might be taken offline.
Caution The following table is only a guide. Always read the release notes for the version you are upgrading to.
| Upgrade Type | Is Downtime Required for This Upgrade or Update? |
|---|---|
| Major Tile Version | See the release notes for that version. |
| Minor Tile Version | For 1.17.2 and earlier: The RabbitMQ cluster is taken offline for the duration of the upgrade. For 1.17.3 and later: Normally these are rolling deployments with each node being updated in turn. In these cases, the cluster remains available, but individual queues might be taken offline as each node is restarted. There might be specific migration paths that require downtime. These are identified in the release notes for that version. |
| Patch Tile Version | Normally these are rolling deployments with each node being updated in turn. In these cases the cluster remains available, but individual queues might be taken offline as each node is restarted. There might be specific migration paths that require downtime. These are identified in the release notes for that version. |
| Stemcell-Only Patch Tile Version | Where the patch update is only a new stemcell version these are rolling deployments with each node being updated in turn. In these cases the cluster remains available, but individual queues might be taken offline as each node is restarted. |
BOSH Hot Swap
On-demand service instances created using Tanzu RabbitMQ for Tanzu Application Service v1.20 and later use the vm_strategy create-swap-delete. This significantly reduces downtime because VM creation and deletion does not affect the downtime of a RabbitMQ node being updated. Depending on your IaaS, VM creation and deletion can take between a few seconds and several minutes.
Your IaaS resource usage surges during the deployment while BOSH creates additional VMs in preparation for the update. You might need to review resource limits for your IaaS and account. If your limits are too low, your deployment fails.
To use this feature, you must have BOSH DNS enabled.
For more information about create-swap-delete, see Changing VM Update Strategy in the BOSH documentation.
Note On-demand service instances created using Tanzu RabbitMQ for Tanzu Application Service v1.19 or earlier and upgraded to v1.20 or later continue to use the vm_strategy delete-create.
About Individual Service Instance Upgrades
Important To allow developers to upgrade individual service instances, you must use VMware Tanzu Application Service for VMs v2.7 or later.
After you upgrade the Tanzu RabbitMQ for Tanzu Application Service tile, existing service instances must be upgraded to use the latest version of the tile. Developers cannot create new bindings to service instances that have not been upgraded.
To decrease runtime for service instance upgrades, developers can individually upgrade on-demand service instances using the Cloud Foundry Command Line Interface (cf CLI). Developers can upgrade individual service instances by following the procedure in Upgrade an Individual Service Instance.
Developers can only upgrade individual service instances if you deactivate the upgrade-all-service-instances errand when upgrading the tile. By default, Tanzu RabbitMQ for Tanzu Application Service runs this errand when you upgrade the tile. However, this operation can take a long time. You must also ensure that the Register On Demand Service Broker errand is run during upgrades. For instructions for activating and deactivating errands, see Errands.
Release Policy
When a new version of RabbitMQ is released, a new version of Tanzu RabbitMQ for Tanzu Application Service is released soon after. For more information, see the Release Policy.
The Tanzu RabbitMQ for Tanzu Application Service tile uses floating stemcells in v1.14.0 and later. This means that the tile can be updated to use the latest minor version of a stemcell, without the need to download a new Tanzu RabbitMQ for Tanzu Application Service patch release from Pivnet. For more information see Floating Stemcells.
