Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 9. 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.

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 them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

Red Hat Technology Preview Features Support Scope

When using Cache CRs, the following rules apply:

  • Cache CRs apply to Data Grid service nodes 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.

9.1. Adding Credentials for Data Grid Operator
Copy link

Data Grid Operator must authenticate with Data Grid service clusters to create caches. You add credentials to a secret so that Data Grid Operator can access your cluster when creating caches.

The following procedure explains how to add credentials to a new secret. If you already have a custom secret that contains credentials, you can use that instead of creating a new one.

Procedure

  1. Define a Secret object type that provides valid user credentials for accessing Data Grid service clusters in a StringData map.

    For example, create an basic-auth.yaml file that provides credentials for the developer user as follows: 

    apiVersion: v1
stringData:
  username: developer
    1 
    
  password: G8ZdJvSaY3lOOwfM
    2 
    
kind: Secret
metadata:
  name: basic-auth
    3 
    
type: Opaque
    1
    Names a user that can create caches.
    2
    Specifies the password that corresponds to the user.
    3
    Specifies a name for the secret.

  2. Create a secret from the file, as in the following example: 

    $ oc apply -f basic-auth.yaml

9.1.1. Using Custom Credentials Secrets
Copy link

Data Grid Operator requires that credentials exist as values for the username and password keys in a secret. If you have a custom secret that contains Data Grid credentials, but uses different key names, you can override those names in your Cache CR.

For example, you have a secret named "my-credentials" that holds a list of Data Grid users and their passwords as follows: 

stringData:
  app_user1: spock
  app_user1_pw: G8ZdJvSaY3lOOwfM
  app_user2: jim
  app_user2_pw: zTzz2gVyyF4JsYsH

Procedure

  • In your Cache CR, override custom key names with username and password as follows: 
spec:
  adminAuth:
    username:
      key: app_user1
1 

      name: my-credentials
2 

    password:
      key: app_user1_pw
3 

      name: my-credentials
1
Overrides the app_user1 key name with username.
2
Specifies the name of your custom credentials secret.
3
Overrides the app_user1_pw key name with password.

9.2. Creating Data Grid Caches from XML
Copy link

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

Prerequisites

  • Create a secret that contains valid user credentials for accessing Data Grid clusters.

Procedure

  1. Create a Cache CR that contains the XML cache definition you want to create. 

    apiVersion: infinispan.org/v2alpha1
kind: Cache
metadata:
  name: mycachedefinition
    1 
    
spec:
  adminAuth:
    2 
    
    secretName: basic-auth
  clusterName: example-infinispan
    3 
    
  name: mycache
    4 
    
  template: <infinispan><cache-container><distributed-cache name="mycache" mode="SYNC"><persistence><file-store/></persistence></distributed-cache></cache-container></infinispan>
    5
    1
    Names the Cache CR.
    2
    Specifies a secret that provides credentials with username and password keys or an override for custom credentials secrets.
    3
    Specifies the name of the target Data Grid cluster where you want Data Grid Operator to create the cache.
    4
    Names the cache on the Data Grid cluster.
    5
    Specifies the XML cache definition to create the cache. Note that the name attribute is ignored. Only spec.name applies to the resulting cache.

  2. Apply the Cache CR, for example: 

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

9.3. Creating Data Grid Caches from Templates
Copy link

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

Prerequisites

  • Create a secret that contains valid user credentials for accessing Data Grid clusters.
  • Identify the cache configuration template you want to use for your cache. You can find a list of available configuration templates in Data Grid Console.

Procedure

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

    For example, the following CR creates a cache named "mycache" that uses the org.infinispan.DIST_SYNC cache configuration template: 

    apiVersion: infinispan.org/v2alpha1
kind: Cache
metadata:
  name: mycachedefinition
    1 
    
spec:
  adminAuth:
    2 
    
    secretName: basic-auth
  clusterName: example-infinispan
    3 
    
  name: mycache
    4 
    
  templateName: org.infinispan.DIST_SYNC
    5
    1
    Names the Cache CR.
    2
    Specifies a secret that provides credentials with username and password keys or an override for custom credentials secrets.
    3
    Specifies the name of the target Data Grid cluster where you want Data Grid Operator to create the cache.
    4
    Names the Data Grid cache instance.
    5
    Specifies the infinispan.org cache configuration template to create the cache.

  2. Apply the Cache CR, for example: 

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

9.4. Adding Backup Locations to Caches
Copy link

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 with identical names for each site.

    Cache configurations at each site can use different cache modes and backup strategies. Data Grid replicates data based on cache names.

  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 

    <infinispan>
  <cache-container>
    <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>
  </cache-container>
</infinispan>

  • LON 

    <infinispan>
  <cache-container>
    <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>
  </cache-container>
</infinispan>

Backup locations can automatically go offline when remote sites become unavailable. This prevents nodes 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.

9.5. Adding Persistent Cache Stores
Copy link

You can add Single File cache stores to Data Grid service nodes to save data to the persistent volume.

You configure cache stores as part of your Data Grid cache definition with the persistence element as follows: 

<persistence>
   <file-store/>
</persistence>

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

Procedure

  • Add a cache store to your cache configurations as follows: 

    <infinispan>
  <cache-container>
    <distributed-cache name="customers" mode="SYNC">
      <encoding media-type="application/x-protostream"/>
      <persistence>
        <file-store/>
      </persistence>
    </distributed-cache>
  </cache-container>
</infinispan>
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. Explore our recent updates.

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.

Theme

© 2026 Red HatBack to top