LATEST VERSION: 1.1 - CHANGELOG
Pivotal Cloud Cache for PCF v1.1

Pivotal Cloud Cache

Overview

Pivotal Cloud Cache (PCC) is a high-performance, highly available caching layer for Pivotal Cloud Foundry (PCF). PCC offers an in-memory key-value store. The product delivers low-latency responses to a large number of concurrent data access requests.

PCC provides a service broker for on-demand creation of in-memory data clusters that are dedicated to the PCF space and tuned for the intended use cases defined by the plan. Service operators can create multiple plans to support different use cases. PCC uses Pivotal GemFire.

You can use PCC to store any kind of data objects using the Pivotal GemFire Java client library.

This documentation performs the following functions:

  • Describes the features and architecture of PCC
  • Provides the PCF operator with instructions for installing, configuring, and maintaining PCC
  • Provides app developers instructions for choosing a service plan, creating and deleting PCC service instances, and binding apps

Product Snapshot

The following table provides version and version-support information about PCC:

Element Details
Version v1.1.2
Release date November 2, 2017
Software component version GemFire v9.0.4
Compatible Ops Manager version(s) v1.10.x and v1.11.x
Compatible Elastic Runtime version(s) v1.10.x and v1.11.x
IaaS support AWS, Azure, GCP, OpenStack, and vSphere
IPsec support No

PCC and Other PCF Services

Some PCF services offer on-demand service plans. These plans let developers provision service instances when they want.

These contrast with the more common pre-provisioned service plans, which require operators to provision the service instances during installation and configuration through the service tile UI.

The following PCF services offer on-demand service plans:

  • MySQL for PCF

  • RabbitMQ for PCF

  • Redis for PCF

  • Pivotal Cloud Cache (PCC)

These services package and deliver their on-demand service offerings differently. For example, some services, like Redis for PCF, have one tile, and you configure the tile differently depending on whether you want on-demand service plans or pre-provisioned service plans.

For other services, like PCC, you install one tile for on-demand service plans and a different tile for pre-provisioned service plans.

The following table lists and contrasts the different ways that PCF services package on-demand and pre-provisioned service offerings.

PCF service tile Standalone product related to the service Versions supporting on demand Versions supporting pre-provisioned
RabbitMQ for PCF Pivotal RabbitMQ v1.8 and later All versions
Redis for PCF Redis v1.8 and later All versions
MySQL for PCF MySQL v2.x
(based on Percona Server)
v1.x
(based on MariaDB and Galera)
PCC Pivotal GemFire All versions NA
GemFire for PCF Pivotal GemFire NA All versions

Architecture

PCC deploys cache clusters that use Pivotal GemFire to provide high availability, replication guarantees, and eventual consistency.

When you first spin up a cluster, you will have three locators and at least four servers.

graph TD; Client subgraph P-CloudCache Cluster subgraph locators Locator1 Locator2 Locator3 end subgraph servers Server1 Server2 Server3 Server4 end end Client==>Locator1 Client-->Server1 Client-->Server2 Client-->Server3 Client-->Server4

If you scale the cluster up, you will have more servers, increasing the capacity of the cache. There always will be three locators.

graph TD; Client subgraph P-CloudCache Cluster subgraph locators Locator1 Locator2 Locator3 end subgraph servers Server1 Server2 Server3 Server4 Server5 Server6 Server7 end end Client==>Locator1 Client-->Server1 Client-->Server2 Client-->Server3 Client-->Server4 Client-->Server5 Client-->Server6 Client-->Server7

When a client connects to the cluster, it first connects to a locator. The locator replies with the IP address of a server for it to talk to. The client then connects to that server.

sequenceDiagram participant Client participant Locator participant Server1 Client->>+Locator: What servers can I talk to? Locator->>-Client: Server1 Client->>Server1: Hello!

When the client wants to read or write data, it sends a request directly to the server.

sequenceDiagram participant Client participant Server1 Client->>+Server1: What’s the value for KEY? Server1->>-Client: VALUE

If the server doesn’t have the data locally, it fetches it from another server.

sequenceDiagram participant Client participant Server1 participant Server2 Client->>+Server1: What’s the value for KEY? Server1->>+Server2: What’s the value for KEY? Server2->>-Server1: VALUE Server1->>-Client: VALUE

Workflow

The workflow for the PCF admin setting up a PCC service plan:

graph TD; subgraph PCF Admin Actions s1 s2 end subgraph Developer Actions s4 end s1[1. Upload P-CloudCache.pivotal to Ops Manager] s2[2. Configure CloudCache Service Plans, i.e. caching-small] s1-->s2 s3[3. Ops Manager deploys CloudCache Service Broker] s2-->s3 s4[4. Developer calls `cf create-service p-cloudcache caching-small test`] s3-->s4 s5[5. Ops Manager creates a CloudCache cluster following the caching-small specifications] s4-->s5
  • PCC can be used as a cache. It supports the look-aside cache pattern.
  • PCC can be used to store objects in key/value format, where value can be any object.
  • PCC works with gfsh versions v9.0.0 and later
  • Any gfsh command not explained in the PCC documentation is not supported.
  • PCC supports basic OQL queries, with no support for joins.

Limitations

  • Scale down of the cluster is not supported.
  • Plan migrations, for example, -p flag with the cf update-service command, are not supported.
  • WAN (Cross Data Center) replication is not supported.
  • Persistent regions are not supported.

Security

Pivotal recommends that you do the following:

  • Run PCC in its own network
  • Use a load balancer to block direct, outside access to the Gorouter

To allow PCC network access from apps, you must create application security groups that allow access on the following ports:

  • 1099
  • 8080
  • 40404
  • 55221

For more information, see the PCF Application Security Groups topic.

Authentication

Clusters are created with two default users: cluster_operator and developer. A cluster can only be accessed using one of these two users. All client applications, gfsh, and JMX clients must authenticate as one of these users accounts to access the cluster.

Authorization

Default user roles cluster_operator and developer have different permissions:

  • cluster_operator role has DATA:MANAGE, DATA:WRITE, and DATA:READ permissions.
  • developer role has DATA:WRITE and DATA:READ permissions.

You can find more details about these permissions in the Pivotal GemFire Implementing Authorization topic.

Feedback

Please provide any bugs, feature requests, or questions to the Pivotal Cloud Foundry Feedback list.

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