Introduction for Operators
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 Dedicted-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.
- 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. On-Demand instances are configured for cache uses and are not intended for backups. See Configuring Automated Backups and Manually Backing up and Restoring.
- Using—Instances of the On-Demand and Dedicated-VM services run on dedicated VMs. Apps in production should have a dedicated instance to prevent performance issues caused by sharing an instance. The Shared-VM service does not provide a Dedicated-VM per instance, and Pivotal recommends that you only use it for development and testing. See the service offerings for the On-Demand Plan and the Dedicated and Shared Plans.
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.
Broker Registrar—Registers the cf-redis-broker with PCF to offer the
Smoke Tests—Runs lifecycle tests for
dedicated-vmplans 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.
The above post-deploy errands are run by default whenever Apply Changes is triggered, whether or not there has been a configuration change in the Redis for PCF tile itself.
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 running 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 Elastic Runtime tile, 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 Elastic Runtime tile.
- Not necessary to run if the change only involves other tiles except Elastic Runtime tile.
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 Elastic Runtime tile.
- Not necessary to run either if the change only involves other tiles except Elastic Runtime 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.
Ops Manager runs Redis for PCF smoke tests as a post-install errand.
The operator can also run the smoke tests errand by running the command:
bosh2 -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