LATEST VERSION: 2.0 - RELEASE NOTES

Shared-VM Service Offering

Page last updated:

Redis for Pivotal Cloud Foundry (PCF) offers On-Demand and Shared-VM service plans. This section describes the architecture, lifecycle, and configurations of the Shared-VM plan. For similar information for the On-Demand service plan, see On-Demand Service Offering.

Breaking Change: If you are using dedicated VMs then migrate to the on-demand service plan or back up data before upgrading to Redis for PCF v2.0 to prevent data loss in Redis deployments used as persistent storage.

If you are upgrading from Redis for PCF v1.14.3 or earlier, you must run the upgrade-all-service-instances errand after upgrading.

About the Shared-VM Plan

The Shared-VM Plan is a pre-provisioned service plan for development and testing purposes only. An instance of this plan provisions a single Redis process on a single shared VM. This plan is suitable for workloads that do not require dedicated hardware. This plan is not suitable for production purposes.

Architecture Diagram for Shared Plans

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

Architecture Diagram

Configuration for Shared-VM Service Plans

You cannot change the default Redis configuration for Shared-VM plans. The default configuration is as follows:

  • 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.

  • By default, the maximum number of connections, maxclients, is set at 10000. Redis might reduce this number when run on a system with a low maximum number of file descriptors. You can retrieve the actual setting on your Redis service instances with the Redis command CONFIG GET maxclients. You can use the Redis command CONFIG SET maxclients to temporarily reduce maxclients, but you cannot increase it above 10000. There is no way to configure shared plans to use a custom limit.

  • Replication and event notification are not configured.

For this reason, Shared-VM plans do not support using CLI commands with arbitrary parameters to configure service instances.

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 the value that you want. 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. For details, see Configuring Service Plans.

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.
  • Because the Shared-VM plan does not manage “noisy neighbor” problems, Pivotal does not recommend it for production apps.

Lifecycle for Shared-VM Service Plan

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