Upgrading Redis for PCF
Note: This version of Redis for PCF is no longer supported because it has reached the End of General Support phase. To stay up to date with the latest software and security updates, upgrade to a supported version.
Page last updated:
This section contains the upgrade procedure and upgrade paths for Redis for PCF.
Breaking Change: Redis for PCF v1.14 and later requires a Xenial stemcell. You must manually download and import a new stemcell into the Ops Manager Stemcell Library before deploying Redis for PCF 1.14.0. This might break automation you have set up to update Redis for PCF deployments that used Trusty stemcells. To download the Xenial stemcell from Pivotal Network, click Stemcells for PCF (Ubuntu Xenial).
Before upgrading Redis for PCF, for compatibility information, see the Product Version Matrix.
Redis for PCF v1.14 and later requires a Xenial stemcell. If you are using any of the following BOSH add-ons with your PCF deployment, you must update the add-on definition to include the Xenial stemcell before you deploy Redis for PCF v1.14:
- File Integrity Monitoring for PCF Add-on. For update instructions, see Updating FIM Add-on for PCF to Run with Xenial Stemcells.
- ClamAV for PCF Add-on. For update instructions, see Updating ClamAV Add-on for PCF to Run with Xenial Stemcells.
- IPsec for PCF Add-on. For update instructions, see Updating IPsec Add-on for PCF to Run with Xenial Stemcells.
This product enables a reliable upgrade experience between versions of the product that is deployed through Ops Manager.
For information on the upgrade paths for each released version, see Compatible Upgrade Paths above.
To upgrade Redis for PCF to v1.14:
Download the latest version of the product from Pivotal Network.
Upload the new
.pivotalfile to Ops Manager.
If required, upload the stemcell associated with the update.
If required, update any new mandatory configuration parameters.
Pivotal recommends that you run the
upgrade-all-service-instanceserrand. For how to run the errand, see Upgrade All Service Instances.
Note: Existing service instances are not upgraded if you do not run this errand. These instances do not benefit from any security fixes or new features included in the upgrade.
Click Apply changes. The rest of the process is automated.
During the upgrade deployment each Redis instance experiences a small period of downtime as each Redis instance is updated with the new software components. This downtime is because the Redis instances are single VMs operating in a non-HA setup.
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 Redis software updated. Stemcell updates incur additional downtime while the IaaS creates the new VM, whereas 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.
A redeploy causes downtime of the Redis for PCF tile. This section clarifies what events trigger a redeploy.
In Ops Manager, any field that changes the manifest causes a redeploy of the Redis for PCF tile.
In the Pivotal Application Service (PAS), changes to any of the following properties can trigger downtime:
..cf.consul_server.ips—Consul Server Resource Config
$runtime.system_domain—Runtime System Domain
..cf.ha_proxy.skip_cert_verify.value—Disable SSL certificate verification for this environment in PAS
$runtime.apps_domain—Runtime Apps Domain
..cf.nats.ips—NATS Resource Config
$self.service_network—Service Networks in Ops Manager
When the operator applies any of the above changes to PAS, downtime is triggered for:
Redis on-demand broker in Redis for PCF v1.8 and later
Dedicated-VM and Shared-VM Services in Redis for PCF v1.9 and earlier
For Redis for PCF v1.8 and later, downtime for service instances occurs only after the operator runs the
upgrade-all-service-instancesBOSH errand, after all tile upgrades are completed successfully.
Any change to a field on the Redis for PCF tile causes BOSH to redeploy the on-demand Redis broker and can cause service instance downtime when the operator runs the
This section explains how changing the network after deploying Redis for PCF affects instances and apps.
To change the network for dedicated-VM and shared-VM services, click Assign AZs and Networks in the Redis for PCF tile configuration and use the Network dropdown. The network applies to both shared-VM and dedicated-VM services.
You can also change the network by altering the CIDR in the BOSH Director tile.
Pivotal discourages changing the network that a pre-existing dedicated-VM deployment or shared-VM deployment works with.
If the network is changed, app bindings for existing dedicated-VM and shared-VM instances might stop working. Dedicated-VMs might also be reallocated as new service instances without their data being cleaned, resulting in a data leak between apps.
To change the service network for on-demand service instances, click Assign AZs and Networks in the Redis tile configuration and use the Service Network dropdown. The service network applies to on-demand service instances.
You can also change the service network by altering the CIDR in the BOSH Director tile.
If you change the service network, you must unbind and rebind existing apps to the on-demand Redis instance.
New on-demand service instances are placed into the new service network, but existing on-demand service instances are not moved. If you need to move the data in on-demand Redis instances to a new service network, you must create a new instance, migrate the data manually, and delete the old instance.
Similarly, changing the availability zone (AZ) for an on-demand plan only applies to new on-demand instances and does not alter existing instances.
When a new version of Redis is released, a new version of Redis for PCF is released soon after.
For more information about the release policy, see Release Policy.