This topic provides recommended use cases for Redis for VMware Tanzu Application Service and information for determining the product’s fit for your enterprise’s use case.

Recommended Use Cases

On-demand plans are configured by default for cache use cases but can also be used as a datastore.

Shared-VM plans are designed for datastore use cases in testing or development environments.

Note: The shared-VM service should only be used for development and testing. Do not use for production.

Redis can be used in many different ways, including:

  • Key/value store: For strings and more complex data structures including Hashes, Lists, Sets, and Sorted Sets
  • Session cache: Persistence enabled preservation of state
  • Full page cache: Persistence enabled preservation of state
  • Database cache: Middle-tier database caching to speed up common queries
  • Data ingestion: Because Redis is in memory, it can ingest data very quickly
  • Message queues: List and set operations. PUSH, POP, and blocking queue commands.
  • Leaderboards and counting: Increments and decrements sets and sorted sets using ZRANGE, ZADD, ZREVRANGE, ZRANK, INCRBY, and GETSET
  • Pub/Sub: Built in publish and subscribe operations: PUBLISH, SUBSCRIBE, and UNSUBSCRIBE

Service Offerings

For descriptions of the service offerings for Redis for Tanzu Application Service, see:

Enterprise-Readiness Checklist

Review the following table to determine if Redis for Tanzu Application Service has the features needed to support your enterprise.

Resilience More Information
Availability All service offerings of Redis for Tanzu Application Service are single VMs without clustering capabilities. This means that planned maintenance jobs (e.g., upgrades) can result in 2–10 minutes of downtime, depending on the nature of the upgrade. Unplanned downtime (e.g., VM failure) also affects the Redis service.
Redis for Tanzu Application Service has been used successfully in enterprise-ready apps that can tolerate downtime. Pre-existing data is not lost during downtime with the default persistence configuration. Successful apps include those where the downtime is passively handled or where the app handles failover logic.
Recommended Use Cases

Support for Multiple AZs
Failure Recovery Recovery from VM failures and process failures are provided for by:

  • Automated service backups (both the on-demand and shared-VM Redis services)
  • BBR backup and recovery (only on-demand Redis services)
  • Manual backup and restore (both the on-demand and shared-VM Redis services)
Configuring Automated Service Backups

BOSH Backup and Restore (BBR) for On-Demand Redis for VMware Tanzu Application Service

Manually Backing Up and Restoring Redis for Pivotal Cloud Foundry
Isolation Isolation is provided when using the on-demand service. Individual apps and workflows should have their own Redis for Tanzu Application Service instance to maximize isolation.
Day 2 Operations More Information
Resource Planning Operators can configure the number of VMs and the size of those VMs. For the on-demand service, the operator does this by creating plans with specific VM sizes and quotas for each plan. For the shared-VM service, the number and size of VMs are pre-provisioned by the operator. BOSH errands used for registration, upgrade and cleanup use short-lived VMs that cannot be configured but can be turned on or off. On-Demand Resource Planning

Shared-VM Plan
Health Monitoring Both the on-demand and shared service instances emit metrics. These include Redis-specific metrics and Redis for Tanzu Application Service metrics. Guidance on critical metrics and alerting levels is captured with the Redis for Tanzu Application Service Key Performance Indicators (KPIs). Key Performance Indicators
Scalability For the on-demand service, the operator can configure three plans with different resource sizes. The operator can also scale up the VM size associated with the plan. Additionally, the operator can increase the quota, which caps the number of instances allowed for each on-demand plan. To prevent data loss, only scaling up is supported. For the shared-VM service, the operators can change the Redis instance memory limit as well as change the instance limit. To prevent data loss, only scaling up is supported. Scaling the On-Demand Service
Logging All Redis services emit logs. Operators can configure syslog forwarding to a remote destination. This enables viewing logs from every VM in the Redis for Tanzu Application Service deployment in one place, effective troubleshooting when logs are lost on the source VM, and setting up alerts for important error logs to monitor the deployment. Configuring syslog forwarding
Customization The on-demand service can be configured to best fit the needs of a specific app. The shared-VM service cannot be customized. Configuring the On-Demand service
Upgrades For information about preparing an upgrade and about understanding the effects on your Redis for Tanzu Application Service and other services, see Upgrading Redis for Tanzu Application Service. Redis for Tanzu Application Service upgrades run a post deployment BOSH errand called smoke tests to validate the success of the upgrade. Upgrades

Smoke Tests
Encryption More Information
Encrypted Communication in Transit You can enable TLS encryption between apps and service instances.

Additionally, Redis for Tanzu Application Service has been tested with the IPsec Add-on for PCF.
OS Redis Security

TLS in Redis for Tanzu Application Service

Securing Data in Transit with the IPsec add-on

Availability Zones

On-demand Redis for Tanzu Application Service supports configuring multiple availability zones (AZs) to improve resiliency. However, assigning multiple AZs to Redis service instances does not provide high availability. This is because each individual Redis service instance is a single VM without clustering capabilities.

The diagram below shows a Redis deployment configured with three availability zones.

A Redis deployment across three availability zones. Availability zone one contains
the on-demand service broker, the shared service broker, shared instances, and on-demand service instances.
Availability zones two and three contain on-demand service instances.

Service instance VMs are placed in availability zones as follows:

  • For on-demand plans: Service instances can be configured to deploy to any AZ. If you select multiple AZs, service instances are distributed randomly between them. This improves resiliency.
  • For the shared-VM plan: Service instances run on a single VM in the AZ in which the tile is deployed.
check-circle-line exclamation-circle-line close-line
Scroll to top icon