Overview of Redis for PCF v1.8
This topic describes the significant new features in Redis for PCF v1.8. This topic also presents a checklist that you can use to decide if Redis for PCF is ready to meet your business requirements.
Redis for PCF v1.8 introduces the On-Demand Service, which provides dedicated instances of configurable Redis instances tailored for caching that App Developers can provision on-demand from the command line. The Redis for PCF On-Demand service is designed to improve the flexibility in how and when instances are provisioned and allows for more efficient and seamless resource use for both Operator and App Developer. Additionally, both Operator and App Developer can configure essential Redis settings. Redis for PCF v1.8 also packages the p-redis service from the earlier Redis for PCF tiles.
Redis for PCF’s On-Demand Service leverages the on-demand service broker.
The following features are new in Redis for PCF v1.8:
- Operator enabled plans — Operators can enable and configure three service plans for dynamically provisioned instances with different memory and disk sizes.
- Operator set Redis properties - Operators can set select Redis properties for each plan.
- Optimized for cache use cases - The default
maxmemory-policysetting for these plans is
allkeys-lru. This can be updated by the App Developer to other cache options.
- Quotas — Operators can set plan-level quotas and a global quota across all on-demand instances.
- App Developer provisioned instances — App Developers can create an Operator-configured plan from the command line.
- App Developer set Redis properties via arbitrary parameters — App Developers can set select Redis settings for each instance.
PCF Redis offers three on-demand plans as the p.redis service within the PCF Redis tile. Below is a description of each plan as it appears in the cf marketplace and its intended use case.
- Small Cache Plan- A Redis instance deployed to a dedicated VM, suggested to be configured with ~1 GB of memory and >3.5 GB of persistent disk.
- Medium Cache Plan - A Redis instance deployed to a dedicated VM, suggested to be configured with ~2 GB of memory and >10 GB of persistent disk.
- Large Cache- A Redis instance deployed to a dedicated VM, suggested to be configured with ~4 GB of memory and >14 GB of persistent disk.
For each service plan, the operator can configure the Plan name, Plan description, Server VM type and Server Disk type, or choose to disable the plan completely.
Additional Redis Configurations
The operator can configure further properties per plan beyond memory and disk sizes. Appropriate defaults have been pre-configured according to the memory/disk size of each plan.
Operators can update certain plan settings after the plans have been created. If the Operator updates the VM size, disk size, or the Redis configuration settings (enabling Lua Scripting, max-clients, timeout and TCP keep-alive), these settings will be implemented in all instances already created. Operators should not downsize the VMs or disk size as this can cause data loss in pre-existing instances.
|Redis Client Timeout||3600||Server timeout for an idle client specified in seconds (e.g., 3600).|
|Redis TCP Keepalive||60||The max number of connected clients at the same time.|
|Max Clients||1000/5000/10000 (small/medium/large)||The max number of connected clients at the same time.|
|Lua Scripting||Enabled||Enable/Disable Lua scripting|
|Plan Quota||20||Maximum number of Redis service instances for this plan, across all orgs and spaces.|
Application Developers can configure their Redis instances with arbitrary parameters. Please view the Redis documentation for more detail.
||Sets the behavior Redis follows when `maxmemory` is reached|
||“”||Set a combination of the following characters (e.g., “Elg”): K, E, g, $, l, s, h, z, x, e, A||Sets the keyspace notifications for events that affect the Redis data set|
||10000||0-20000||Sets the threshhold execution time (seconds). Commands that exceed this execution time are added to the slowlog.|
||128||1-2024||Sets the length (count) of the slowlog queue.|
Review the following table to determine if Redis for PCF v1.8 has the features needed to support your enterprise.
|Plans and Instances||More Information|
|On-Demand, Dedicated-VM and Shared-VM plans||Redis for PCF provides On-Demand, dedicated VM and shared VM service plans.||Plans|
|Customizable plans||For the On-Demand Plan and Dedicated-VM plan, the operator can customize the VM and disk size.||Configuring|
|Installation and Upgrades||More Information|
|Product upgrades||Redis for PCF can be upgraded from v1.7 tiles||Upgrading Redis for PCF|
|Deployment Smoke Tests||Redis for PCF installation and upgrade runs a post deployment BOSH errand that validates basic Redis operations||Smoke Tests|
|Maintenance and Backups||More Information|
|Operational Monitoring and Logging||Redis for PCF v1.8 provides metrics for monitoring On-Demand plan usage and quotas and syslog redirection to external log ingestors.||Monitoring Redis for PCF|
|Backup and Restore||Redis for PCF v1.8 includes automatic backups on a configurable schedule to a variety of destinations for Dedicated-VM and Shared-VM plans, as well as scripts for backup and restore of service instances. The On-Demand plan does not offer this.||Manual Backup and Restore of Redis for PCF|
|Scale and Availability||More Information|
|Scale||Redis for PCF has been tested with 60 GB of data|
|On-Demand Plan||Redis for PCF provides up to 50 on-demand instances across plans|
|Ability to Scale Up / Down||Operators can scale VMs up, but not down||Configuring|
|Rolling Deployments||Redis for PCF does not support rolling deployments because it is single node; the service is unavailable during upgrades.||Upgrades|
|AZ Support||Assigning multiple AZs to Redis jobs does not guarantee high availability.||About Multiple AZs in Redis for PCF|
|Encrypted Communication in Transit||Redis for PCF has been tested successfully with the BOSH IPsec Add-on||Securing Data in Transit with the IPsec Add-on|
Redis for PCF v1.8 supports configuring multiple AZs. However, assigning multiple AZs to Redis jobs does not guarantee high availability.
- On-Demand plans can be assigned to any of the configured availability zones. However each instance still operates as a single node with no clustering.
- Shared-VM instances run on a single node in just one of the configured availability zones and are therefore not highly available.
- Dedicated-VM instances can be assigned to any of the configured availability zones. However each instance still operates as a single node with no clustering. This separation over availability zones provides no high availability.
The following table lists where you can find topics related to the information on this page:
|For more information about…||See…|
|the v1.8 releases||Release Notes|