This topic gives you information about the upgrade paths and how to upgrade Redis for VMware Tanzu Application Service.

Compatible upgrade paths

For product versions and upgrade paths, see Upgrade Planner.

Upgrade Redis for Tanzu Application Service

Caution After TLS is activated for the on-demand Valkey service, deactivating TLS causes downtime and service outage for all apps that connect to Valkey through TLS. If you deactivate TLS, you must unbind all apps bound to on-demand instances from the TLS port, rebind to the non-TLS port, and then restage to resume service access.

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

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

Upgrade procedure

To upgrade to the latest version of Redis for Tanzu Application Service:

  1. Download the latest version of the product from Broadcom’s Customer Support Portal.

  2. Upload the new .pivotal file to Tanzu Operations Manager.

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

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

  5. (Optional) To enable TLS:

    1. Follow the procedures in Preparing for TLS.

      In most cases, enabling TLS does not noticeably reduce performance. Performance impact depends on the health of resources, such as network infrastructure and application architecture.

    2. In the Redis for Tanzu Application Service tile, select On-Demand Service Settings.
    3. Under Enable TLS, select Optional.

    4. Enable the checkbox next to each TLS version you want to support. VMware recommends supporting TLS v1.1 and later. VMware does not recommend supporting TLS v1.0 because it is less secure than later versions, but it is an option for apps that only support this protocol.

      After selecting a TLS version, VMware recommends generating a new service key and then rebinding the service instance with the new service key. This makes the service key's tls_versions field reflect the new TLS version, which can help developers who use the service key to see the supported TLS version. To create a new service key, follow the steps in Check Availability. To rebind the instance, follow the steps in Bind Existing Apps with TLS.

    5. Click Save.

  6. (Optional) Enable developers to upgrade service instances individually. For instructions, see Enable Individual Service Instance Upgrades below.
    When this is feature is not enabled, the upgrade-all-service-instances errand runs by default after each upgrade. For more information, see Upgrading all Service Instances.

  7. Go to the Tanzu Operations Manager Installation Dashboard. Click Review Pending Changes and Apply Changes.

Enable individual service instance upgrades

Until you upgrade service instances, they do not benefit from any security fixes or new features included in the tile upgrade. The default upgrade path automatically upgrades all on-demand service instances when you upgrade the tile. This operation can take a long time.

To expedite upgrades, in Redis for Tanzu Application Service v2.3 and later you can enable on-demand service instances to be upgraded individually. This allows developers to upgrade their own service instances after you have upgraded the tile.

This feature is only available for upgrades from Redis for Tanzu Application Service v2.3.0 to later versions. You cannot upgrade individual service instances from v2.2 to v2.3.

To enable upgrading individual service instances:

  1. Ensure that all service instances have been upgraded to Redis for Tanzu Application Service v2.3.0 or later. If not, click Apply changes to run the upgrade-all-service instances errand.

  2. In Redis for Tanzu Application Service tile, navigate to the Errands page.

  3. Select Off for the Upgrade All On-Demand Service Instances errand:

    The 'Errands' pane in Ops Manager. The 'Upgrade All On-Demand Service Instances' section is shown, and 'Off' is selected.

  4. Click Save.

  5. Click Apply changes.

After you enable individual service instance upgrades, developers can upgrade individual service instances following the instructions in Upgrading an individual Redis Service Instance.

Downtime during upgrades

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 Enable BOSH HotSwaps to Reduce Downtime 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 on the existing VM. Stemcell updates incur additional downtime while the IaaS creates the new VM, whereas updates without a stemcell update are faster.

Tanzu Operations 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.

Causes of downtime

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

Changes in Tanzu Operations Manager

In Tanzu Operations Manager, any field that changes the manifest causes a redeploy of the Redis for Tanzu Application Service tile.

Changes in VMware Tanzu Application Service for VMs

In the VMware Tanzu Application Service for VMs tile, changes to any of the following properties can trigger downtime:

  • $runtime.system_domain—Runtime System Domain
  • ..cf.ha_proxy.skip_cert_verify.value—Deactivate SSL certificate verification for this environment in TAS for VMs
  • $runtime.apps_domain—Runtime Apps Domain
  • ..cf.nats.ips—NATS Resource Config
  • $self.service_network—Service Networks in Tanzu Operations Manager

When the operator applies any of the above changes to TAS for VMs, downtime is triggered for:

  • The Redis on-demand broker

  • Shared-VM Services

Upgrading all service instances

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 Tanzu Application Service 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.

Enable BOSH HotSwaps to reduce downtime

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 Pivotal Cloud Foundry v1.14 or earlier was installed. For instructions, see the solution in Apps fail to connect to the Service Instance.

    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 check box in the On-Demand Service Settings tab.

  3. Click Save and then Apply Changes.

Network changes after deployment

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

Shared VMs

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

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

VMware 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. 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 Tanzu Application Service is released soon after. For more information, see the Release Policy.

check-circle-line exclamation-circle-line close-line
Scroll to top icon