Installing and Configuring VMware Tanzu GemFire

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 Tanzu GemFire on VMware Tanzu Application Service for VMs (TAS for VMs):

  1. Download the tile from Tanzu 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 Tanzu GemFire 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 Tanzu GemFire 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 Tanzu GemFire, 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 VMware Tanzu GemFire VMs. VMware recommends selecting all of them.
    Network Select your PAS (or Elastic Runtime) network.
    Service Network Select the network to be used for VMware Tanzu GemFire VMs.

  3. Click Save.

Settings

Settings: Smoke Test Plan

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.

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

Settings: Default Distributed System ID

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 will configure 11 individual plans by selecting each of the tabs. There are Plan 1 through Plan 5, three plans that reside on a single VM (called Co-located Single VM Plan), and three plans that spread locators and servers among three VMs (called Co-located Multi VM Plan).

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 Maximum service instances field sets the maximum number of Tanzu GemFire 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.

For more information on how VM memory is allocated, see VM Memory Allocation.

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

Configure a Co-located Multi VM Plan

Any of the Co-located Multi VM Plans use three VMs to implement a default plan with three locators and three servers. Each of the three VMs has one locator and one server. Co-located Multi VM Plan 1 has a default plan name of small-footprint.

This type of 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 Tanzu GemFire cluster member resides within its own VM.

A Tanzu GemFire service instance using a Co-located Multi VM Plan may be created with more servers than the default three servers. Follow the instructions within Creating a VMware Tanzu GemFire for VMs 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 VMware Tanzu GemFire for VMs 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 VMware Tanzu GemFire for VMs 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 Co-located Multi VM Plan size of three servers.

To configure a Co-located Multi VM Plan, enable the plan with the Co-located Multi VM Plan tab.

Configuring a Co-located Multi VM Plan

Configure a Co-located Single VM Plan

A Co-located Single VM Plan is a type of service plan. The plan provides a single locator and server, which are colocated within a single VM.

WARNING: Data loss results when the single VM this plan provides goes down or restarts.

The plan automatically creates a single region called example_partition_region. The region type is PARTITION, a partitioned region without redundancy or persistence of entries. You can create other regions as desired with a Co-located Single VM Plan service instance.

There are three Co-located Single VM Plans to configure. The page for configuring this plan is similar to the page for configuring other service plans. To configure a Co-located Single VM Plan, input information in the fields and make selections from the options on each Configure Co-located Single VM Plan page.

Co-located Single VM Plan Configuration Sections

Syslog

By default, syslog forwarding is not enabled in Tanzu GemFire. However, Tanzu GemFire 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

There are three configuration aspects to the Security settings. Each of the three must be considered and appropriately handled within these settings. Once the Security properties settings have been set, click Save. The Security properties Settings page appears as:

Security section

The three items in this page to handle are:

  1. 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, click on the box labeled Enable Secure Service Instance Credentials to enable use of CredHub. When service keys are stored within CredHub, output from the cf env APP-NAME command will not show credentials.

  2. An ‘X’ is required in the text box to promote the understanding that the environment must be set up to handle TLS encryption. See Preparing for Transport Layer Security (TLS) for how to prepare the TAS for VMs environment.

  3. If User Account and Authentication (UAA) of Tanzu GemFire users will go through an external system, enable that with the radio button labeled UAA Auth enabled. With UAA enabled, create a UAA client before doing this tile installation as explained in Create a UAA Client. Also follow the instructions in Configuring UAA Roles to complete the configuration by setting up the user roles. With UAA enabled, two text boxes will appear. Fill the boxes with the UAA client name and that client’s secret, which were set when the client was created.

Errands

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

For general information about errands in TAS for VMs, see Managing Errands in Ops Manager

  1. Click Errands.

  2. Change the setting for the errands.

  3. Click Save.