RabbitMQ® for Pivotal Cloud Foundry
This product enables automated upgrades between versions of the product and is deployed through Ops Manager, and due to RabbitMQ product limitations may require the cluster to be taken offline. When this is necessary it is clearly noted in the release notes for that version.
Note there is a difference between the cluster remaining available during a tile upgrade/update, and an individual queue placed on nodes in a cluster.
A reference guide for deployments is shown the table below. Please be aware that this is a guide only and that the release notes for the version you are updating to must be checked before upgrading.
|Operations Manager Action||Will Downtime Be Required For This Upgrade / Update|
|Major Tile Version Upgrade||
|Minor Tile Version Upgrade||
|Patch Tile Version Upgrades||
|Stemcell Only - Patch Tile Version Upgrades||
The specific upgrade paths are detailed here for each released version.
Note: For specific information about updating RabbitMQ for PCF from v1.6.0–v1.6.4, see Updating RabbitMQ for PCF from versions v1.6.x to v1.6.6.
To upgrade the product:
- The Operator should 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)
- Press “Apply changes” and the rest of the process is automated
It is necessary to increase the number of HAProxy instances from the default of one to two, before an upgrade is initiated to enable a zero downtime upgrade. During a typical upgrade deployment, nodes are upgraded one at a time in the cluster providing a zero downtime deployment. Applications may experience a disconnected session, if the application attempts to reconnect it will be directed to another working node automatically.
Only when upgrading between specific versions of Erlang or RabbitMQ is an outage required on the cluster. This will be clearly stated on the release notes for that version, should this be required.
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 simply have the RabbitMQ software updated. Stemcell updates incur additional downtime while the IaaS creates the new VM while updates without a stemcell update are faster.
Ops Manager ensures the instances are updated with the new packages and any configuration changes are applied automatically.
Upgrading to a newer version of the product does not cause any loss of data or configuration. This is explicitly tested for during our build and test process for a new release of the product. (In future releases of the product the default number of HAProxy instances will be increased to two).
Please note that it may take busy RabbitMQ nodes a long time to shutdown during the upgrade and this process should not be forcibly stopped. Where possible it is advised to fully drain queues before an upgrade involving an update to the version of RabbitMQ running.
When a new version of RabbitMQ is released we aim to release a new version of the product containing this soon after.
Where there is a new version of RabbitMQ or another dependent software component such as the stemcell released due to a critical CVE, Pivotal’s goal is to release a new version of the product within 48 hours.