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

Dedicated-VM and Shared-VM Service Offerings

Page last updated:

Redis for Pivotal Cloud Foundry (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 On-Demand Service Offering.

About the Pre-Provisioned Plans

Redis for PCF includes two pre-provisioned service plans:

  • Dedicated-VM Plan

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

  • Shared-VM Plan

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

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

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.

Configuration for the Dedicated-VM Service Plan

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

Operator Notes for the Dedicated-VM Service Plan

  • The following Redis commands are enabled:

    • MONITOR
    • SAVE
    • BGSAVE
    • BGREWRITEAOF
  • 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 a single service broker VM.

  • These instances are pre-provisioned during the deployment of the tile from Ops Manager 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.

  • The number of Dedicated-VM plan instances available to developers is set by the operator. Configurations of up to 100 Dedicated-VM plan instances have been tested.

  • You can disable this plan 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.
  • Cannot scale down the size of VMs on the plan once deployed (this protects against data loss).

Configuration for the Shared-VM Service Plan

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

Operator Notes for the Shared-VM Plan

  • This plan deploys a Redis instance in 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 Ops Manager 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 some 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.

  • The number of Shared VM instances available to developers is set by the operator. The maximum number of shared VM instances is relative to the memory allocated to each Shared VM instance and the total memory of the Redis service broker. See Configuring Service Plans for details.

Known Limitations of the Shared-VM Plan

Limitations of the shared-vm plan include:

  • It cannot be scaled beyond a single VM.
  • 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