Is Redis for PCF right for your enterprise?
Page last updated:
This topic provides recommended use cases for Redis for Pivotal Cloud Foundry (PCF) and information for determining the product’s fit for your enterprise’s use case.
Dedicated-VM and Shared-VM plans are designed for datastore use cases. On-Demand plans, introduced in Redis for PCF v1.8, are configured by default for cache use cases but can also be used as a datastore.
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.
POP, and blocking queue commands.
- Leaderboards and Counting: Increments and decrements sets and sorted sets
- Pub/Sub: Built in publish and subscribe operations:
Successful use cases handle the downtime that occurs with the Redis for PCF service. This happens in two ways:
For use cases with lower availability requirements, write simple failover logic that enables the app to work while Redis for PCF is down.
For use cases with higher availability requirements, write more complex failover logic that enables the app to failover to another singleton Redis for PCF instance.
For descriptions of the three Redis for PCF service offerings, see:
Note: The Shared-VM service should only be used for development and testing. Do not use for production.
Review the following table to determine if Redis for PCF has the features needed to support your enterprise.
|Availability||All Redis for PCF services are single nodes without clustering capabilities.
This means that planned downtime, for example, upgrades, can result in 2–10 minutes of downtime,
depending on the nature of the upgrade.
Unplanned downtime, for example, VM failure, also affects the Redis service.
Redis for PCF 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 the app handles failover logic.
|Recommended Use Cases
Support for Multiple AZs
|Failure Recovery||VM failures and process failures are handled automatically by BOSH and Redis for PCF. Manual backup and restore instructions are available for all three Redis services. Automatic backup capabilities are enabled for the Dedicated-VM service.||
Manual Backup and Restore Flow
Automatic Backups for Dedicated-VM Service
|Isolation||Isolation is provided when using the On-Demand and Dedicated-VM service. Individual apps and workflows should have their own Redis for PCF 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 Dedicated-VM and Shared-VM services, 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
Pre-provisioning Dedicated-VM and Shared-VM Instances
|Health Monitoring||The On-Demand service and Dedicated-VM service emit metrics. These include Redis-specific metrics and Redis for PCF metrics. Guidance on critical metrics and alerting levels is captured with the Redis for PCF KPIs.||
|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. For the Dedicated-VM Service, the operators can change the number of dedicated nodes deployed as well as change the VM size associated for the Dedicated-VMs. 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
Scaling the Dedicated-VM 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 PCF 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 Dedicated-VM and 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 PCF and other services, see Upgrading Redis for PCF. Redis for PCF upgrades run a post deployment BOSH errand called smoke tests to validate the success of the upgrade.||
|Encrypted Communication in Transit||Redis for PCF has been tested with the IPsec Add-on for PCF. Beyond that Redis for PCF does not provide additional encryption on top of Redis.||Securing Data in Transit with the IPsec add-on OS Redis Security|
Redis for PCF supports configuring multiple availability zones (AZs). However, assigning multiple AZs to Redis instances does not guarantee high availability as clustered Redis is not supported. Redis instances operate as single nodes.
- On-Demand plans can be configured to deploy instances to any AZ.
- Shared-VM instances run on a single node in the AZ in which the tile is deployed.
- Dedicated-VM instances can be assigned to any of the configured AZs.