Pivotal Cloud Cache
This is the documentation for Pivotal Cloud Cache (PCC). You can download the PCC tile from the Pivotal Network.
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
Current Pivotal Cloud Cache details:
- Version: v1.0.4
- Release Date: June 12, 2017
- Software Component Version: GemFire v9.0.3
- Compatible Ops Manager Version: v1.9.x and v1.10.x
- Compatible Elastic Runtime Version: v1.9.21+ and v1.10.x
- vSphere Support: Yes
- Azure Support: Yes
- GCP Support: Yes
- OpenStack Support: Yes
- AWS Support: Yes
- IPsec Support: No
- Rewrote smoke test using Go to fix timeout issues on some environments
- Upgraded to Gemfire v9.0.3
- Upgraded to v0.15.3 of On-Demand Service Broker
- Fixed JVM parameters for garbage collection
- URL routes were updated to read “cloudcache” rather than “gemfire”
- Upgrades to v0.15.2 of On-Demand Service Broker
- Increased smoke test canary timeout to 5 minutes
- Sets global service instance quota to 50 instances
- Provides option to disable a plan and service access separately
- Validates that plan description doesnt contain any spaces
- Upgrades to v0.15.1 of On-Demand Service Broker
- Smoke test now runs in the
- Improved reliability of Smoke Test errand
- Adds support for gfsh
- Optimized size of tile to make downloading and uploading faster
- Ensured no data loss with when performing a stemcell upgrade for regions with redundancy
- Add post deployment checks that all locators properly join the cluster
- PCC broker can be configured to send logs to a syslog server
- PCC service instances will now send logs to configured syslog endpoint if enabled
- Added option to provide public IP addresses to VMs, which is necessary to allow egress on Google Cloud Platform
- Added errand when deleting tile that deletes all PCC service instances
- PCC requires PCF with PCF Elastic Runtime v1.9.11 or above.
- Support for application look-aside cache pattern
- Multi AZ support
- On-demand provisioning
- MVP role-based access control
- Quotas, both for service instances and for number of servers in a cluster
- GemFire v9.0.2
- Managed and configure clusters using the Cloud Foundry Command Line Interface (cf CLI) service commands and the GemFire gfsh CLI
Upgrade all service instanceserrand can only upgrade the first 50 instances created.
- On PCF for Google Cloud Platform deployments, Ops Manager service network VMs are not assigned the correct firewall rules. As a result, these VMs cannot communicate with the BOSH Director, and the Cloud Cache Broker will fail to create service instances. As a workaround, modify your firewall to use subnet CIDR-based rules.
- The PCC broker will accept requests to modify instances that have ongoing BOSH operations, resulting in an asynchronous failure.
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’ll have three locators and at least four servers.
If you scale the cluster up, you’ll have more servers, increasing the capacity of the cache. There always will be three locators.
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.
When the client wants to read or write data, it sends a request directly to the server.
If the server doesn’t have the data locally, it fetches it from another server.
The workflow for the PCF admin setting up a PCC service plan:
- PCC for PCF 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 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.
- Scale down of the cluster is not supported.
- Plan migrations, for example
-pflag with the
cf update-servicecommand, are not supported.
- WAN (Cross Data Center) replication is not supported.
- Persistent regions are not supported.
Pivotal recommends that you do the following:
- Run PCC for PCF 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:
For more information, see the PCF Application Security Groups topic.
Clusters are created with two default users:
developer. A cluster can only be accessed using one of these two users. All client applications, gfsh, and JMX clients need to use one of these users to access the cluster.
Default user roles
developer have different permissions:
cluster_operatorrole has DATA:MANAGE, DATA:WRITE, and DATA:READ permissions.
developerrole has DATA:WRITE and DATA:READ permissions.
You can find more details about these permissions in the Pivotal GemFire Implementing Authorization topic.
Please provide any bugs, feature requests, or questions to the Pivotal Cloud Foundry Feedback list.