Introduction for Operators
Note: This version of Redis for PCF is no longer supported because it has reached the End of General Support phase. To stay up to date with the latest software and security updates, upgrade to a supported version.
Page last updated:
This topic is for Pivotal Cloud Foundry (PCF) operators. It introduces some best practices, but does not provide details about operation.
Pivotal recommends that operators follow these guidelines:
- Resource Allocation—Work with app developers to anticipate memory requirements and to configure VM sizes. Instances of Dedicated-VM and Shared-VM services have identical VM sizes. However, with the On-Demand service, app developers can choose from three different plans, each with its own VM size and quota. See the service offering for the On-Demand Plan and Resource Usage Planning for On-Demand plans.
- Logs—Configure a syslog output. Storing logs in an external service helps operators debug issues both current and historical. See Configure Syslog Output. In particular, set up alerts on critical logs, such as service backups so that you are alerted if a backup fails. For examples of critical logs for service backups, see Service Backups for Pivotal Cloud Foundry.
- Monitoring—Set up a monitoring dashboard for metrics to track the health of the installation.
- Backing Up Data—When using Redis for persistence, configure automatic backups so that data can be restored in an emergency. Validate the backed-up data with a test restore. See Configuring Automated Backups and also Manually Backing Up and Restoring Redis for Pivotal Cloud Foundry in the Pivotal Support knowledge base.
- Using—Instances of the On-Demand and Dedicated-VM services run on dedicated VMs. Apps in production should have a dedicated or on-demand instance to prevent performance issues caused by sharing an instance. The Shared-VM service shares a VM across many instances. Pivotal recommends that you only use the Shared-VM service for development and testing, but not in production environments. For more information about the plans, see the On-Demand Service Offering and the Dedicated-VM and Shared-VM Service Offering.
Redis can handle up to 232 keys, and was tested in practice to handle at least 250 million keys per instance. Every hash, list, set, and sorted set, can hold 232 elements. VM memory is more likely to be a limiting factor than number of keys that can be handled.
Redis for PCF includes the errands listed below.
The following post-deploy errands are run by default when Apply Changes is triggered, whether or not there has been a configuration change in the Redis for PCF tile itself:
Broker Registrar—Registers the cf-redis-broker with PCF to offer the
p-redisservice, that is, the shared-VM and dedicated-VM plans. The Broker Registrar errand also includes the Deprecate Dedicated-VM Plan errand. It disables service access to the dedicated-VM plan for non-admin app developers.
Deprecate Dedicated-VM Plan—Disables service access to the dedicated-VM plan for non-admin app developers.
Cleanup Metadata if Dedicated-VM Plan Disabled—Cleans up any metadata in PCF for any dedicated-VM service instances if zero dedicated instances are provisioned. You can run this errand to clean up metadata after you have deleted all dedicated instances.
Smoke Tests—Runs lifecycle tests for shared-VM and dedicated-VM plans if these have been enabled and there is remaining quota available. The tests cover provisioning, binding, reading, writing, unbinding, and deprovisioning of service instances.
Register On-Demand Broker—Registers the on-demand Redis broker with PCF to offer the
p.redisservice (on-demand plans).
On-Demand Smoke Tests—Runs lifecycle tests for enabled plans of the
p.redisservice if there is remaining quota available. The tests cover provisioning, binding, reading, writing, unbinding and deprovisioning of service instances.
Upgrade All On-Demand Service Instances—Upgrades on-demand service instances to use the latest plan configuration, service releases, and stemcell. This causes downtime to any service instances with available upgrades.
The following post-deploy errand does not run by default whenever Apply Changes is triggered. This type of post-deploy errand helps operators troubleshoot and maintain their service fleet:
- Recreate All On-Demand Service Instances—Re-creates on-demand service instances one-by-one. This causes downtime to any service instances with available upgrades.
Broker Deregistrar—Deregisters the
Delete All On-Demand Service Instances and Deregister Broker—Deletes all on-demand instances and deregisters the on-demand Redis broker.
The above pre-delete errands are run by default whenever the Redis for PCF tile is deleted.
Pivotal recommends that you run the post-deploy errands at any trigger of Apply Changes. However, this practice can extend the duration of applying changes by several minutes every time. This section helps you decide when it is safe to skip some post-deploy errands.
Changes to Redis for PCF Tile Configuration
If the changes include configuration changes on the Redis for PCF tile or a new stemcell version, the operator must run all post-deploy errands.
Installing Another Tile
When installing another tile that does not make any changes to the BOSH Director or the Pivotal Application Service (PAS), it is not necessary to run any of the Redis for PCF tile’s post-deploy errands.
Changes to Other Tiles
Sometimes the change does not include changes to the Redis for PCF tile’s configuration. Then it might not be necessary to run all of the Redis for PCF tile’s post-deploy errands.
Broker Registrar Errand
- Required to run if the CF system domain is changed in the PAS tile.
- Not necessary to run if the change only involves other tiles except PAS tile.
Deprecate Dedicated-VM Plan Errand
- Run this errand to prepare for deprecation of support for dedicated nodes.
- Only needs to be run once to disable service access to the dedicated-VM plan for non-admin app developers.
- Not needed if the Broker Registrar errand has been run.
Register On-Demand Broker Errand
- Required to run if the network range that the Redis on-demand broker is deployed in is changed in the BOSH Director tile.
- Not necessary to run if the change only involves other tiles except BOSH Director.
Pivotal recommends against changing the BOSH Director’s network configuration in a way that changes the ranges where the Redis for PCF tile deploys VMs.
Smoke Tests and On-Demand Smoke Tests Errands
- Required to run if their respective register broker errand is required.
- Required to run both if a newer stemcell minor version is uploaded. The Redis for PCF tile floats to the newest minor version. For more information, see Understanding Floating Stemcells.
- Good practice to run both for any change in the BOSH Director or PAS tile.
- Not necessary to run either if the change only involves other tiles except PAS and BOSH Director.
Upgrade All On-Demand Service Instances Errand
- Required to run if a newer stemcell minor version is uploaded. The Redis for PCF tile floats to the newest minor version. For more information, see Understanding Floating Stemcells.
- Not necessary to run if there are no on-demand instances provisioned.
Recreate All On-Demand Service Instances Errand
- Run this errand when it is necessary to re-create an instance with different resources, for example, when rotating CA certificates.
- It increases the time to Apply Changes because it follows the typical instance lifecycle.
- Do not run this errand if there are no on-demand instances provisioned. Pivotal recommends that you keep this errand off unless it is needed.
Ops Manager runs Redis for PCF smoke tests as a post-install errand. To run the smoke tests errand manually:
Retrieve the deployment name of the installed product. To find the deployment name:
- From the Ops Manager UI, click the Redis for PCF tile.
- Copy the part of the URL that starts with “p-redis-”.
Run the smoke tests errand:
bosh -d REDIS-DEPLOYMENT-NAME run-errand smoke-tests
For more information, see Redis for PCF Smoke Tests.
Note: Smoke tests fail unless you enable global default application security groups (ASGs).
You can enable global default ASGs by binding the ASG to the
system org without specifying a space.
To enable global default ASGs, use