Introduction for Operators
Page last updated:
This topic is for PCF operators. It introduces some best practices, but does not provide details about operation.
Redis for PCF can be used as a cache or as a datastore. On-Demand plans, introduced in Redis for PCF v1.8, are configured by default for cache use cases. Dedicated-VM and Shared-VM plans are designed for datastore use cases.
Redis can be used in many different ways, including:
- Key/value store for strings and more complex data structures including Hashes, Lists, Sets, Sorted Sets
- Session cache: persistence enables preservation of state
- Full page cache: persistence enables preservation of state
- Database cache: cache 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/Counting: increments and decrements of sets and sorted sets using
- Pub/Sub: built in publish and subscribe operations:
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. On-Demand instances do not yet have instance-level metrics in v1.8+. See Monitoring Redis for PCF.
- 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.
You can back up Redis for PCF instances in two ways for Dedicated-VM and Shared-VM instances:
- Configure automatic backups to be run for each instance, across both service plans. For information about setting up automatic backups, see Configuring Automated Backups.
- Create manual backups of individual instances. For information about how to make manual backups of instances, see Manually Backing up and Restoring.
Backups are not available for On-Demand instances.
Redis for PCF emits Redis metrics via the firehose. For details, see Monitoring and Metrics.
Metrics are not currently available at the instance-level for On-Demand instances.
Syslog can be forwarded to an external log service.
Syslog for On-Demand instances conforms to RFC5424 standards. This format is as follows:
<$PRI>$VERSION $TIMESTAMP $HOST $APP_NAME $PROC_ID $MSG_ID [instance@47450 deployment="$DEPLOYMENT" group="$INSTANCE_GROUP" az="$AVAILABILITY_ZONE" id="$ID"] $MESSAGE`
<13>1 2017-03-28T15:20:31.490350+00:00 10.0.16.35 redis-server 4951 - [instance@47450 director="us-pws" deployment="service-instance_16c95f89-8d5a-4cb7-839d-79c5d026bd15" group="redis-instance" az="eu-west-1a" id="7f976f34-4105-4475-abbc-5df10e933cfa" ] User requested shutdown
The following example shows syslogs for Dedicated-VM and Shared-VM instances:
Nov 15 17:05:01 10.0.24.10 audispd: [job=dedicated-node index=4] node=7bfe8b1b-6c fd-4d33-b704-c9214ce6bb3e type=USER_ACCT msg=audit(1479229501.290:86): pid=6655 ui d=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="root" exe="/usr/sbi n/cron" hostname=? addr=? terminal=cron res=success'
For information about how to set up syslog output, see Configure Syslog Output.
Downtime is caused by a redeploy of the Redis tile. Here we attempt to clarify what changes will trigger a redeploy.
In Ops Manager, any field that changes the manifest will cause a redeploy of the Redis tile. Any property changes in ERT listed here will trigger downtime for the Redis On-Demand Broker. Note that this list is current at the time of writing (May 2017) but that dependencies with changing products mean that it will change.
- Consul Server Resource Config (..cf.consul_server.ips)
- Runtime System Domain ($runtime.system_domain)
- Disable SSL certificate verification for this environment” in ERT (..cf.ha_proxy.skip_cert_verify.value)
- Runtime Apps Domain ($runtime.apps_domain)
- NATS Resource Config (..cf.nats.ips)
- Service Networks in Ops Manager ($self.service_network)
For Redis for PCF v1.8+, downtime for service instances will only occur once the Operator runs
upgrade-all-service-instances BOSH errand after all tile upgrades have completed successfully. For Redis for PCF v1.7 and earlier, and the Dedicated-VM and Shared-VM Service in Redis for PCF v1.8 and v1.9, downtime is enforced as soon as the operator applies the referenced changes to ERT. Any changes to a field on the Redis tile, will cause BOSH to redeploy the legacy Redis Broker and the On-Demand Broker once
upgrade-all-service-instances is run.
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.
Ops Manager runs Redis for PCF smoke tests as a post-install errand. The operator can also run the smoke tests errand by using
bosh run errand smoke-tests. For more information see Redis for PCF Smoke Tests.