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.
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.
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
Create a
Cache
CR that contains an XML cache configuration.-
Specify a name for the
Cache
CR with themetadata.name
field. -
Specify the target Data Grid cluster with the
spec.clusterName
field. Name your cache with the
spec.name
field.NoteThe
name
attribute in the XML configuration is ignored. Only thespec.name
field applies to the resulting cache.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>
-
Specify a name for the
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
Create a
Cache
CR that specifies the name of a template to use.-
Specify a name for the
Cache
CR with themetadata.name
field. -
Specify the target Data Grid cluster with the
spec.clusterName
field. -
Name your cache with the
spec.name
field. 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
-
Specify a name for the
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
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 yourInfinispan
CRs.Configure backup locations to go offline automatically with the
take-offline
element.-
Set the amount of time, in milliseconds, before backup locations go offline with the
min-wait
attribute.
-
Set the amount of time, in milliseconds, before backup locations go offline with the
- Define any other valid cache configuration.
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 thepersistence
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>