SupportConsoleDevelopersStart a trialContact

Chapter 12. Creating caches with Data Grid Operator

Use Cache CRs to add cache configuration with Data Grid Operator and control how Data Grid stores your data.

Important

Creating caches with Data Grid Operator is available as a technology preview.

12.1. Technology Previews

Technology Preview features or capabilities are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete.

Red Hat does not recommend using Technology Preview features or capabilities for production. These features provide early access to upcoming product features, which enables you to test functionality and provide feedback during the development process.

For more information, see Red Hat Technology Preview Features Support Scope.

12.2. Data Grid caches

Cache configuration defines the characteristics and features of the data store and must be valid with the Data Grid schema. Data Grid recommends creating standalone files in XML or JSON format that define your cache configuration. You should separate Data Grid configuration from application code for easier validation and to avoid the situation where you need to maintain XML snippets in Java or some other client language.

To create caches with Data Grid clusters running on OpenShift, you should:

  • Use Cache CR as the mechanism for creating caches through the OpenShift front end.
  • Use Batch CR to create multiple caches at a time from standalone configuration files.
  • Access Data Grid Console and create caches in XML or JSON format.

You can use Hot Rod or HTTP clients but Data Grid recommends Cache CR or Batch CR unless your specific use case requires programmatic remote cache creation.

12.3. Cache CRs

Find out details for configuring Data Grid caches with Cache CR.

When using Cache CRs, the following rules apply:

  • Cache CRs apply to Data Grid service pods only.
  • You can create a single cache for each Cache CR.
  • If your Cache CR contains both a template and an XML configuration, Data Grid Operator uses the template.
  • If you edit caches in the OpenShift Web Console, the changes are reflected through the user interface but do not take effect on the Data Grid cluster. You cannot edit caches. To change cache configuration, you must first delete the cache through the console or CLI and then re-create the cache.
  • Deleting Cache CRs in the OpenShift Web Console does not remove caches from Data Grid clusters. You must delete caches through the console or CLI.
Note

In previous versions, you need to add credentials to a secret so that Data Grid Operator can access your cluster when creating caches.

That is no longer necessary. Data Grid Operator uses the operator user and corresponding password to perform cache operations.

12.4. Creating caches from XML

Complete the following steps to create caches on Data Grid service clusters using valid infinispan.xml configuration.

Procedure

  1. Create a Cache CR that contains an XML cache configuration.

    1. Specify a name for the Cache CR with the metadata.name field.
    2. Specify the target Data Grid cluster with the spec.clusterName field.

    3. Name your cache with the spec.name field.

      Note

      The name attribute in the XML configuration is ignored. Only the spec.name field applies to the resulting cache.

    4. Add an XML cache configuration with the spec.template field. 

      apiVersion: infinispan.org/v2alpha1
kind: Cache
metadata:
  name: mycachedefinition
spec:
  clusterName: example-infinispan
  name: mycache
  template: <distributed-cache name="mycache" mode="SYNC"><persistence><file-store/></persistence></distributed-cache>

  2. Apply the Cache CR, for example: 

    $ oc apply -f mycache.yaml
cache.infinispan.org/mycachedefinition created

12.5. Creating caches from templates

Complete the following steps to create caches on Data Grid service clusters using cache templates.

Prerequisites

  • Identify the cache template you want to use for your cache.
    You can find a list of available templates in Data Grid Console.

Procedure

  1. Create a Cache CR that specifies the name of a template to use.

    1. Specify a name for the Cache CR with the metadata.name field.
    2. Specify the target Data Grid cluster with the spec.clusterName field.
    3. Name your cache with the spec.name field.

    4. Specify a cache template with the spec.template field.

      The following example creates a cache named "mycache" from the org.infinispan.DIST_SYNC cache template: 

      apiVersion: infinispan.org/v2alpha1
kind: Cache
metadata:
  name: mycachedefinition
spec:
  clusterName: example-infinispan
  name: mycache
  templateName: org.infinispan.DIST_SYNC

  2. Apply the Cache CR, for example: 

    $ oc apply -f mycache.yaml
cache.infinispan.org/mycachedefinition created

12.6. Adding backup locations to caches

When you configure Data Grid clusters to perform cross-site replication, you can add backup locations to your cache configurations.

Procedure

  1. Create cache configurations that name remote sites as backup locations.

    Data Grid replicates data based on cache names. For this reason, site names in your cache configurations must match site names, spec.service.sites.local.name, in your Infinispan CRs.

  2. Configure backup locations to go offline automatically with the take-offline element.

    1. Set the amount of time, in milliseconds, before backup locations go offline with the min-wait attribute.
  3. Define any other valid cache configuration.

  4. Add backup locations to the named cache on all sites in the global cluster.

    For example, if you add LON as a backup for NYC you should add NYC as a backup for LON.

The following configuration examples show backup locations for caches:

  • NYC 

    <distributed-cache name="customers">
  <encoding media-type="application/x-protostream"/>
  <backups>
    <backup site="LON" strategy="SYNC">
      <take-offline min-wait="120000"/>
    </backup>
  </backups>
</distributed-cache>

  • LON 

    <replicated-cache name="customers">
  <encoding media-type="application/x-protostream"/>
  <backups>
    <backup site="NYC" strategy="ASYNC" >
      <take-offline min-wait="120000"/>
    </backup>
  </backups>
</replicated-cache>

Additional resources

12.6.1. Performance considerations with taking backup locations offline

Backup locations can automatically go offline when remote sites become unavailable. This prevents pods from attempting to replicate data to offline backup locations, which can have a performance impact on your cluster because it results in error.

You can configure how long to wait before backup locations go offline. A good rule of thumb is one or two minutes. However, you should test different wait periods and evaluate their performance impacts to determine the correct value for your deployment.

For instance when OpenShift terminates the site master pod, that backup location becomes unavailable for a short period of time until Data Grid Operator elects a new site master. In this case, if the minimum wait time is not long enough then the backup locations go offline. You then need to bring those backup locations online and perform state transfer operations to ensure the data is in sync.

Likewise, if the minimum wait time is too long, node CPU usage increases from failed backup attempts which can lead to performance degradation.

12.7. Adding persistent cache stores

You can add persistent cache stores to Data Grid service pods to save data to the persistent volume.

Data Grid creates a Single File cache store, .dat file, in the /opt/infinispan/server/data directory.

Procedure

  • Add the <file-store/> element to the persistence configuration in your Data Grid cache, as in the following example: 

    <distributed-cache name="persistent-cache" mode="SYNC">
  <encoding media-type="application/x-protostream"/>
  <persistence>
    <file-store/>
  </persistence>
</distributed-cache>
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.