Upgrading Redis for PCF

Page last updated:

This section contains the upgrade procedure and upgrade paths for Redis for PCF.

Compatible Upgrade Paths

Before upgrading Redis for PCF, for compatibility information, see the Product Version Matrix.

Upgrade to Redis for PCF v2.2

Note: Follow the procedures in Preparing for TLS before enabling TLS in Redis for PCF v2.2.

Selecting TLS optional does not enforce the use of TLS. After deploying the tile, notify developers that they must unbind, bind, and restage existing service instances to ensure that Spring and Steeltoe apps use TLS.
Developers might also need to configure other frameworks and languages to use the TLS port as well.

For more information, see Using TLS.

Warning: After TLS has been enabled for the on-demand Redis service, disabling TLS causes downtime and service outage for all apps that connect to Redis through TLS.
If you disable TLS, you must unbind all apps bound to on-demand instances from the TLS port, rebind to the non-TLS port and then re-stage to resume service access.

This product enables a reliable upgrade experience between versions of the product deployed through Ops Manager.

For information about the upgrade paths for each released version, see Compatible Upgrade Paths above.

Downtime During Upgrade

During the upgrade each Redis instance experiences a small period of downtime as each instance is updated with the new software components. This downtime is because Redis instances are single VMs operating in a non-high availability (HA) setup. To reduce downtime, you can enable the BOSH HotSwaps feature. Compared to traditional BOSH upgrades, this feature has been shown to reduce downtime by 75%. For instructions on how to enable this feature, see BOSH HotSwaps below.

The length of downtime depends on whether there is a stemcell update to replace the operating system image, or whether the Redis software is updated the on the existing VM. 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.

Upgrade Procedure

To upgrade to Redis for PCF v2.2:

  1. Download the latest version of the product from Pivotal Network.

  2. Upload the new .pivotal file to Ops Manager.

  3. If required, upload the stemcell associated with the update.

  4. If required, update any new mandatory configuration parameters.

  5. (Optional) If enabling TLS, follow the procedures in Preparing for TLS first. When upgrading, TLS remains disabled by default.

    Note: In most cases, enabling TLS does not noticeably reduce performance. This depends, however, on network infrastructure, application architecture, and other such resources being in good shape.

  6. Pivotal recommends that you ensure that the Upgrade All On-Demand Service Instances errand checkbox is selected on the Review Pending Changes page.

    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.

  7. Click Apply changes. The rest of the process is automated.

Downtime During Upgrades and Redeploys

A redeploy causes downtime for the Redis for PCF tile. This section clarifies what events trigger a redeploy.

Ops Manager Changes

In Ops Manager, any field that changes the manifest causes a redeploy of the Redis for PCF tile.

PAS Changes

In the Pivotal Application Service (PAS), changes to any of the following properties can trigger downtime:

  • $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

  • Shared-VM Services in Redis for PCF v1.9 and earlier

Upgrading all Service Instances

  • For Redis for PCF v1.8 and later, downtime for service instances occurs only after the operator runs the upgrade-all-service-instances BOSH 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 upgrade-all-service-instances errand.

BOSH HotSwaps

Enabling BOSH HotSwaps reduces the downtime for on-demand service instances when upgrading. Benchmarking shows that enabling BOSH HotSwaps can reduce service instance downtime by 75% when upgrading. For how it works, see Changing VM Update Strategy in the BOSH documentation. To use this feature, all service bindings must use BOSH DNS instead of IP addresses.

To enable BOSH HotSwaps:

  1. Ensure all service bindings use BOSH DNS. To do so, tell developers to unbind, bind, and restage any apps created while Redis for PCF v1.14 or earlier was installed. For instructions, see the solution in Apps Fail to Connect to the Service Instance.

    Note: You must do this before enabling BOSH HotSwaps. Any apps with service bindings that do not use BOSH DNS fail to connect to the Redis service instance.

  2. Select the BOSH HotSwaps checkbox in the On-Demand Service Settings tab.

  3. Click Save and Apply Changes.

Network Changes after Deployment

This section explains how changing the network after deploying Redis for PCF affects instances and apps.

Shared VMs

To change the network for shared-VM services, click Assign AZs and Networks in the Redis for PCF tile configuration and use the Network dropdown.

You can also change the network by altering the CIDR in the BOSH Director tile.

Pivotal discourages changing the network that a pre-existing shared-VM deployment works with.

If the network is changed, app bindings for existing shared-VM instances might stop working.

On-Demand Service Instances

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.

Release Policy

When a new version of Redis is released, a new version of Redis for Pivotal Platform is released soon after.

For more information about the Pivotal Platform release policy, see Release Policy.