Upgrading VMware Tanzu RabbitMQ for VMs
Note: Pivotal Platform is now part of VMware Tanzu. In v1.20 and later, VMware Tanzu RabbitMQ [VMs] is named VMware Tanzu RabbitMQ for VMs.
VMware Tanzu RabbitMQ for VMs 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.
To upgrade the product:
- Review the release notes for the version that you are upgrading to. See VMware Tanzu RabbitMQ for VMs 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 disabled BOSH DNS, you must enable it for BOSH Hot Swaps to work. For more information, see BOSH Hot Swap below.
- (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, the
upgrade-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.
The following notes about the upgrade process apply to upgrading to any version of Tanzu RabbitMQ.
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
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 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 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.
Warning: The following table is only a guide. Always read the release notes for the version you are upgrading to.
|Upgrade Type||Will Downtime Be 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.|
On-demand service instances created using Tanzu RabbitMQ v1.20 and later use the
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
Changing VM Update Strategy
in the BOSH documentation.
Note: On-demand service instances created using Tanzu RabbitMQ v1.19 or earlier
and upgraded to v1.20 or later continue to use the
Note: For developers to be able to upgrade individual service instances, you must use VMware Tanzu Application Service for VMs v2.7 or later.
After you upgrade the Tanzu RabbitMQ 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 disable the
errand when upgrading the tile.
By default, Tanzu RabbitMQ 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 how to enable and disable errands, see Errands.
When a new version of RabbitMQ is released, a new version of Tanzu RabbitMQ is released soon after. For more information, see the Release Policy.
The Tanzu RabbitMQ 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 patch release from Pivnet. For more information see Floating Stemcells.