Upgrading RabbitMQ for PCF
RabbitMQ for PCF 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.
The upgrade paths for each version are detailed in the Product Compatibility Matrix.
This topic applies to both the on-demand and pre-provisioned services.
This section provides information about the upgrade process, release cycle, and downtime during upgrades.
The following notes about the upgrade process apply to upgrading to any version of RabbitMQ for PCF.
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.
When a new version of RabbitMQ is released, a new version of RabbitMQ for PCF is released soon after.
For more information about the PCF release policy, see Release Policy.
Starting with RabbitMQ for PCF v1.14.0, the RabbitMQ tile uses floating stemcells. This means that the tile can be updated to use the latest minor version of a stemcell, without the need to download a new RabbitMQ for PCF patch release from Pivnet.
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.
The length of the downtime depends on whether there is a stemcell update to replace the operating system image or whether the existing VM can just have the RabbitMQ software updated. Stemcell updates incur additional downtime while the IaaS creates the new VM.
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.
IMPORTANT: The following table is only a guide. Always check the release notes for the version you are upgrading to.
|Upgrade Type||Will Downtime Be Required For This Upgrade / Update|
|Major Tile Version||The RabbitMQ cluster is taken offline for the duration of the upgrade.|
|Minor Tile Version||The RabbitMQ cluster is taken offline for the duration of the upgrade.|
|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 are specific migration paths that require downtime, which 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.|
To upgrade the product, follow these steps:
- Download the latest version of the product from Pivotal Network.
- Upload the new .pivotal file to Ops Manager.
- Upload the stemcell associated with the update (if required).
- Update any new mandatory configuration parameters (if required).
- Click Apply changes in the Ops Manager Installation Dashboard. The rest of the process is automated.