LATEST VERSION: 1.7 - RELEASE NOTES
Pivotal Cloud Cache for PCF v1.6

Installing and Configuring Pivotal Cloud Cache

With an Ops Manager role (detailed in Understand Roles in Ops Manager) that has the proper permissions to install and configure, follow these steps to install PCC on PCF:

  1. Download the tile from the Pivotal Network.
  2. Click Import a Product to import the tile into Ops Manager.
  3. Click the + symbol next to the uploaded product description.
  4. Click on the Cloud Cache tile.
  5. Complete all the configuration steps in the Configure Tile Properties section below.
  6. Return to the Ops Manager Installation Dashboard. Click Review Pending Changes (see Reviewing Pending Product Changes).
  7. Click Apply Changes to complete the installation of the PCC tile.

Configure Tile Properties

Configure the sections listed on the left side of the page.

Tile Configuration Sections

As you complete a section, save it. A green check mark appears next to the section name. Each section name must show this green check mark before you can complete your installation.

Assign Availability Zones and Networks

To select AZs and networks for VMs used by PCC, do the following:

  1. Click Assign AZs and Networks.

  2. Configure the fields on the Assign AZs and Networks pane as follows:

    FieldInstructions
    Place singleton jobs in Select the region that you want for singleton VMs.
    Balance other jobs in Select the AZ(s) you want to use for distributing other GemFire VMs. Pivotal recommends selecting all of them.
    Network Select your PAS (or Elastic Runtime) network.
    Service Network Select the network to be used for GemFire VMs.

  3. Click Save.

Settings

Smoke Test Settings

The smoke-tests errand that runs after tile installation. The errand verifies that your installation was successful. By default, the smoke-test errand runs on the system org and the p-cloudcache-smoke-test space.

Note: Smoke tests will fail unless you enable global default application security groups (ASGs). You can enable global default ASGs by binding the ASG to the system org without specifying a space. To enable global default ASGs, use cf bind-running-security-group.

To select which plan you want to use for smoke tests, do the following:

Select a plan to use when the smoke-tests errand runs.

Ensure the selected plan is enabled and configured. For information about configuring plans, see Configure Service Plans below. If the selected plan is not enabled, the smoke-tests errand fails.

Pivotal recommends that you use the smallest four-server plan for smoke tests. Because smoke tests create and later destroy this plan, using a very small plan reduces installation time. Configuring Smoke Tests Plan

Settings: Allow Outbound Internet Access Settings

By default, outbound internet access is not allowed from service instances.

If BOSH is configured to use an external blob store, you need allow outbound internet access from service instances. Log forwarding and backups, which require external endpoints, might also require internet access.

To allow outbound internet access from service instance, do the following:

Select Allow outbound internet access from service instances (IaaS-dependent).

Outbound Internet Access

Note: Outbound network traffic rules also depend on your IaaS settings. Consult your network or IaaS administrator to ensure that your IaaS allows outbound traffic to the external networks you need.

Default Distributed System ID Setting

Every service instance has an integer identifier called a distributed system ID. The ID defaults to the value 0. Service instances that form a distributed system that communicates across a WAN will need distinct IDs. Those distinct ID values are set when creating the service instance.

To change the default distributed system ID value, replace the default value of 0 with your new default value. Acceptable values are integers greater than or equal to 0 and less than or equal to 255.

Default Distributed System ID setting

Configure Service Plans

You can configure five individual plans for your developers. Select the Plan 1 through Plan 5 tabs to configure each of them.

Configuring a Plan

The Plan Enabled option is selected by default. If you do not want to add this plan to the CF service catalog, select Plan Disabled. You must enable at least one plan.

The Plan Name text field allows you to customize the name of the plan. This plan name is displayed to developers when they view the service in the Marketplace.

The Plan Description text field allows you to supply a plan description. The description is displayed to developers when they view the service in the Marketplace.

The Enable metrics for service instances checkbox enables metrics for service instances created using the plan. Once enabled, the metrics are sent to the Loggregator Firehose.

The CF Service Access drop-down menu gives you the option to display or not display the service plan in the Marketplace. Enable Service Access displays the service plan the Marketplace. Disable Service Access makes the plan unavailable in the Marketplace. If you choose this option, you cannot make the plan available at a later time. Leave Service Access Unchanged makes the plan unavailable in the Marketplace by default, but allows you to make it available at a later time.

The Service Instance Quota sets the maximum number of PCC clusters that can exist simultaneously.

When developers create or update a service instance, they can specify the number of servers in the cluster. The Maximum servers per cluster field allows operators to set an upper bound on the number of servers developers can request. If developers do not explicitly specify the number of servers in a service instance, a new cluster has the number of servers specified in the Default Number of Servers field.

The Availability zones for service instances setting determines which AZs are used for a particular cluster. The members of a cluster are distributed evenly across AZs.

WARNING! After you’ve selected AZs for your service network, you cannot add additional AZs; doing so causes existing service instances to lose data on update.

The remaining fields control the VM type and persistent disk type for servers and locators. The total size of the cache is directly related to the number of servers and the amount of memory of the selected server VM type. We recommend the following configuration:

  • For the VM type for the Locator VMs field, select a VM that has at least 2 CPUs, 1 GB of RAM and 4 GB of disk space.
  • For the Persistent disk type for the Locator VMs field, select 10 GB or higher.
  • For the VM type for the Server VMs field, select a VM that has at least 2 CPUs, 4 GB of RAM and 8 GB of disk space.
  • For the Persistent disk type for the server VMs field, select 10 GB or higher.

When you finish configuring the plan, click Save to save your configuration options.

Configure a Small Footprint Plan

The Small Footprint Plan uses three VMs to implement a default plan with three locators and three servers. Each of the three VMs has one locator and one server.

This plan is appropriate for production installations that can tolerate the diminished load-handling capacity and reduced resilience that would result from the loss of a VM. Installations needing resilience in the face of a VM loss should use a plan in which each PCC cluster member resides within its own VM.

A PCC service instance using the Small Footprint Plan may be created with more servers than the default three servers. Follow the instructions within Creating a Pivotal Cloud Cache Service Instance to increase the number of servers.

Scale up an existing service instance by increasing the number of servers, as specified in Updating a Pivotal Cloud Cache Service Instance.

Whether creating a new service instance or updating an existing service instance to have more servers, each additional server will be within its own VM.

Scaling down the quantity of servers within an existing service instance is accomplished one server at a time to ensure redundancy is correctly maintained. To scale down, use the cf update-service command as described in Updating a Pivotal Cloud Cache Service Instance to specify one server fewer than the total quantity of servers currently running.

An error message will be issued if an attempt is made to scale down by more than one server at a time, or if an attempt is made to reduce the number of servers below the minimum size of the default Small Footprint Plan size of three servers.

To configure a Small Footprint Plan, enable the plan with the Small Footprint Plan tab.

Configuring a Small Footprint Plan

Configure a Dev Plan

A Dev Plan is a type of service plan. Use a Dev Plan for development and testing. The plan provides a single locator and server, which are colocated within a single VM.

The page for configuring a Dev Plan is similar to the page for configuring other service plans. To configure the Dev Plan, input information in the fields and make selections from the options on the Plan for test development page.

Dev Plan Configuration Sections

If you have enabled post-deploy scripts in your BOSH Director, a region is automatically created. To confirm that post-deploy scripts are enabled, navigate to the Director Config pane of Ops Manger Director and verify that Enable Post Deploy Scripts is selected.

Enable post deploy scripts

Syslog

By default, syslog forwarding is not enabled in PCC. However, PCC supports forwarding syslog to an external log management service (for example, Papertrail, Splunk, or your custom enterprise log sink). The broker logs are useful for debugging problems creating, updating, and binding service instances.

To enable remote syslog for the service broker, do the following:

  1. Click Syslog. Configuring Log Management Service
  2. Configure the fields on the Syslog pane as follows:

    FieldInstructions
    Enable Remote Syslog Select to enable.
    External Syslog Address Enter the address or host of the syslog server for sending logs, for example, logs.example.com.
    External Syslog Port Enter the port of the syslog server for sending logs, for example,29279.
    Enable TLS for Syslog Select to enable secure log transmission through TLS. Without this, remote syslog sends unencrypted logs. We recommend enabling TLS, as most syslog endpoints such as Papertrail and Logsearch require TLS.
    Permitted Peer for TLS Communication. This is required if TLS is enabled. If there are several peer servers that can respond to remote syslog connections, then provide a regex, such as *.example.com.
    CA Certificate for TLS Communication If the server certificate is not signed by a known authority, for example, an internal syslog server, provide the CA certificate of the log management service endpoint.
    Send service instance logs to external By default, only the broker logs are forwarded to your configured log management service. If you want to forward server and locator logs from all service instances, select this. This lets you monitor the health of the clusters, although it generates a large volume of logs.

    If you don’t enable this, you get only the broker logs which include information about service instance creation, but not about on-going cluster health.

  3. Click Save.

Service Instance Upgrades

A configurable number of service instances may be upgraded concurrently by entering a new value that is greater than one and less than the BOSH worker count for the Number of simultaneous upgrades.

Specify a set of service instances to act as canaries for the upgrade process by changing the Number of upgrade canary instances to a value greater than 0. If all canary instances successfully upgrade, the remaining instances are upgraded. If any canary instance fails to upgrade, the upgrade fails and no further instances are upgraded.

Click Save after changing values.

Instance Upgrades section

Security

The environment may be configured to more securely store service keys within CredHub, instead of within the cloud controller’s data store. To enable this functionality:

  1. Click Security.

  2. Click on the box labeled Enable Secure Service Instance Credentials to enable use of CredHub.

  3. An ‘X’ is required in the text box to promote the understanding that a TLS-enabled service instance cannot be created if the PCF environment is not set up to handle TLS. See Preparing for TLS for how to prepare the PCF environment.

  4. Click Save.

Security section

Errands

By default, post-deploy and pre-delete errands always run. Pivotal recommends keeping these defaults. However, if necessary, you can change these defaults as follows.

For general information about errands in PCF, see Managing Errands in Ops Manager

  1. Click Errands.

  2. Change the setting for the errands.

  3. Click Save.

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