LATEST VERSION: 1.9 - CHANGELOG
Redis for PCF v1.9

Architecture and Lifecycle for Dedicated and Shared Plans

Page last updated:

Redis for PCF offers On-Demand, Dedicated-VM, and Shared-VM service plans. This section describes the architecture, lifecycle, and configurations of Dedicated-VM and Shared-VM plans. For similar information for the On-Demand service plan, see Architecture and Lifecycle for the On-Demand Service.

Architecture Diagram for Shared and Dedicated Plans

This diagram shows how the architecture of the service broker and Shared-VM and Dedicated-VM plans and how the user’s app binds to a Redis instance.

Architecture Diagram

About Shared-VM and Dedicated-VM Service Plans

For Dedicated-VM and Shared-VM plans, Redis is configured with a maxmemory-policy of no-eviction. This policy means that once memory is full, the service will not evict any keys, and no write operations will be possible until memory becomes available.

Persistence is configured for both RDB and AOF. The default maximum number of connections, maxclients, is set at 10000 but this number is adjusted by Redis according to the number of file handles available.

Replication and event notification are not configured.

Shared-VM Service Plan

An instance of this plan provisions a single Redis process on a single shared VM that is suitable for workloads which do not require dedicated hardware.

  • This plan deploys a Redis instance inside the service broker VM.
  • You can disable this plan by setting the Max instances limit on the Shared-VM plan tab in OpsManager to be 0.
  • The maximum number of instances can be increased from the default 5 to a value of your choosing. If you increase the number of instances that can be run on this single VM, you should consider increasing the resources allocated to the VM. In particular RAM and CPU. You can overcommit to a certain extent, but may start to see performance degradations.
  • You can also increase the maximum amount of RAM allocated to each Redis process (service instance) that is running on this VM
  • If you decrease the service instance limit, any instances that are running where the count is now greater than the limit are not terminated. They are left to be removed naturally, until the total count drops below the new limit you cannot create any new instances. For example if you had a limit of 10 and all were used and reduced this to 8, the two instances will be left running until you terminate them yourself.

Dedicated-VM Service Plan

An instance of this plan, provisions a single Redis process, on a single dedicated VM, which is suitable for workloads that require isolation or dedicated hardware.

The following commands are enabled:

  • MONITOR
  • SAVE
  • BGSAVE
  • BGREWRITEAOF

Data persistence is enabled through the use of RDB and AOF.

The maxmemory value for the Redis process is set to be 45% of the RAM for that instance.

The persistent disk should be set to be at least the size of the RAM available to the VM or greater, in order to account for the final and temporary RDB file generated by the Redis background save.

  • This plan deploys the operator-configured number of dedicated Redis VMs alongside the service broker VM.
  • These instances are pre-provisioned during the deployment of the tile from OpsManager into a pool. The VMs are provisioned and configured with a Redis process ready to be used when an instance of the Dedicated-VM plan is requested.
  • A default deployment will provision 5 instances of the Dedicated-VM plan into the pool. This number can be increased on the Resource Config tab in Ops Manager, either in the initial deployment, or subsequently thereafter. The number of VMs cannot be decreased once deployed.
  • When a user provisions an instance, it is marked as in use and taken out of the pool.
  • When a user deprovisions an instance, the instance is cleansed of any data and configuration to restore it to a fresh state and placed back into the pool, ready to be used again.
  • You can disable this plan by setting the number of instances of the Dedicated node job in Ops Manager to 0.

Configuration for Dedicated-VM and Shared-VM Service Plans

For Dedicated-VM and Shared-VM plans, the default Redis configurations cannot be changed. A sample redis.conf from a Dedicated-VM plan instance is provided here.

  • Redis is configured with a maxmemory-policy of no-eviction. This policy means that when the memory is full, the service does not evict any keys or perform any write operations until memory becomes available.

  • Persistence is configured for both RDB and AOF.

  • The default maximum number of connections, maxclients, is set at 10000 but this number is adjusted by Redis according to the number of file handles available.

  • Replication and event notification are not configured.

Operator Notes for the Dedicated-VM Service Plan

  • This plan deploys several dedicated Redis VMs and a single service broker VM.
  • These instances are pre-provisioned during the deployment of the tile from OpsManager into a pool. The VMs are provisioned and configured with a Redis process ready to be used when an instance of the dedicated-vm plan is requested.
  • A default deployment will provision 5 instances of the dedicated-vm plan into the pool. This number can be increased on the Resource Config tab in Ops Manager, either in the initial deployment, or subsequently thereafter. The number of VMs cannot be decreased once deployed.
  • When a user provisions an instance, it is marked as in use and taken out of the pool.
  • When a user deprovisions an instance, the instance is cleansed of any data and configuration to restore it to a fresh state and placed back into the pool, ready to be used again.
  • This plan can be disabled by setting the number of instances of the Dedicated node job in Ops Manager to 0.

Known Limitations of the Dedicated-VM Service Plan

Limitations of the dedicated-vm plan include:

  • No ability to change the Redis configuration. The CONFIG command is disabled.
  • Cannot scale down the number of VMs on the plan once deployed.

Operator Notes for the Shared-VM Plan

  • This plan deploys a shared VM and a single service broker VM.
  • This plan can be disabled by setting the Max instances limit on the Shared-VM Plan tab in OpsManager to be 0.
  • The maximum number of instances can be increased from the default 5 to a value of your choosing. If you increase the number of instances that can be run on this single VM, you should consider increasing the resources allocated to the VM. In particular RAM and CPU. You can overcommit to a certain extent, but may start to see performance degradations.
  • You can also increase the maximum amount of RAM allocated to each Redis process (service instance) that is running on this VM
  • If you decrease the service instance limit, any instances that are running where the count is now greater than the limit are not terminated. They are left to be removed naturally, until the total count drops below the new limit you cannot create any new instances. For example if you had a limit of 10 and all were used and reduced this to 8, the two instances will be left running until you terminate them yourself.

Known Limitations of the Shared-VM Plan

Limitations with the current shared-vm plan include:

  • It cannot be scaled beyond a single virtual machine.
  • The following commands are disabled: CONFIG, MONITOR, SAVE, BGSAVE, SHUTDOWN, BGREWRITEAOF, SLAVEOF, DEBUG, and SYNC.
  • Constraining CPU and/or disk usage is not supported.
  • The Shared-VM plan does not manage ‘noisy neighbor’ problems so it is not recommended for production apps.

Lifecycle for Dedicated-VM and Shared-VM Service Plans

Here is the lifecycle of Redis for PCF, from an operator installing the tile through an app developer using the service then an operator deleting the tile.

Lifecycle Diagram

Create a pull request or raise an issue on the source for this page in GitHub