Embedding Data Grid in Java Applications
Create embedded caches with Data Grid
Abstract
Red Hat Data Grid Copy linkLink copied to clipboard!
Data Grid is a high-performance, distributed in-memory data store.
- Schemaless data structure
- Flexibility to store different objects as key-value pairs.
- Grid-based data storage
- Designed to distribute and replicate data across clusters.
- Elastic scaling
- Dynamically adjust the number of nodes to meet demand without service disruption.
- Data interoperability
- Store, retrieve, and query data in the grid from different endpoints.
Data Grid documentation Copy linkLink copied to clipboard!
Documentation for Data Grid is available on the Red Hat customer portal.
Data Grid downloads Copy linkLink copied to clipboard!
Access the Data Grid Software Downloads on the Red Hat customer portal.
You must have a Red Hat account to access and download Data Grid software.
Making open source more inclusive Copy linkLink copied to clipboard!
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Chapter 1. Configuring the Data Grid Maven repository Copy linkLink copied to clipboard!
Data Grid Java distributions are available from Maven.
You can download the Data Grid Maven repository from the customer portal or pull Data Grid dependencies from the public Red Hat Enterprise Maven repository.
1.1. Downloading the Data Grid Maven repository Copy linkLink copied to clipboard!
Download and install the Data Grid Maven repository to a local file system, Apache HTTP server, or Maven repository manager if you do not want to use the public Red Hat Enterprise Maven repository.
Procedure
- Log in to the Red Hat customer portal.
- Navigate to the Software Downloads for Data Grid.
- Download the Red Hat Data Grid 8.3 Maven Repository.
- Extract the archived Maven repository to your local file system.
-
Open the
README.mdfile and follow the appropriate installation instructions.
1.2. Adding Red Hat Maven repositories Copy linkLink copied to clipboard!
Include the Red Hat GA repository in your Maven build environment to get Data Grid artifacts and dependencies.
Procedure
Add the Red Hat GA repository to your Maven settings file, typically
~/.m2/settings.xml, or directly in thepom.xmlfile of your project.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Reference
1.3. Configuring your Data Grid POM Copy linkLink copied to clipboard!
Maven uses configuration files called Project Object Model (POM) files to define projects and manage builds. POM files are in XML format and describe the module and component dependencies, build order, and targets for the resulting project packaging and output.
Procedure
-
Open your project
pom.xmlfor editing. -
Define the
version.infinispanproperty with the correct Data Grid version. Include the
infinispan-bomin adependencyManagementsection.The Bill Of Materials (BOM) controls dependency versions, which avoids version conflicts and means you do not need to set the version for each Data Grid artifact you add as a dependency to your project.
-
Save and close
pom.xml.
The following example shows the Data Grid version and BOM:
Next Steps
Add Data Grid artifacts as dependencies to your pom.xml as required.
Chapter 2. Creating embedded caches Copy linkLink copied to clipboard!
Data Grid provides an EmbeddedCacheManager API that lets you control both the Cache Manager and embedded cache lifecycles programmatically.
2.1. Adding Data Grid to your project Copy linkLink copied to clipboard!
Add Data Grid to your project to create embedded caches in your applications.
Prerequisites
- Configure your project to get Data Grid artifacts from the Maven repository.
Procedure
-
Add the
infinispan-coreartifact as a dependency in yourpom.xmlas follows:
2.2. Configuring embedded caches Copy linkLink copied to clipboard!
Data Grid provides a GlobalConfigurationBuilder API that controls the cache manager and a ConfigurationBuilder API that configures embedded caches.
Prerequisites
-
Add the
infinispan-coreartifact as a dependency in yourpom.xml.
Procedure
- Initialize the default cache manager so you can add embedded caches.
-
Add at least one embedded cache with the
ConfigurationBuilderAPI. -
Invoke the
getOrCreateCache()method that either creates embedded caches on all nodes in the cluster or returns caches that already exist.
Chapter 3. Enabling and configuring Data Grid statistics and JMX monitoring Copy linkLink copied to clipboard!
Data Grid can provide Cache Manager and cache statistics as well as export JMX MBeans.
3.1. Enabling statistics in embedded caches Copy linkLink copied to clipboard!
Configure Data Grid to export statistics for the cache manager and embedded caches.
Procedure
- Open your Data Grid configuration for editing.
-
Add the
statistics="true"attribute or the.statistics(true)method. - Save and close your Data Grid configuration.
Embedded cache statistics
XML
GlobalConfigurationBuilder
GlobalConfigurationBuilder global = GlobalConfigurationBuilder.defaultClusteredBuilder().cacheContainer().statistics(true); DefaultCacheManager cacheManager = new DefaultCacheManager(global.build()); Configuration builder = new ConfigurationBuilder(); builder.statistics().enable();
GlobalConfigurationBuilder global = GlobalConfigurationBuilder.defaultClusteredBuilder().cacheContainer().statistics(true);
DefaultCacheManager cacheManager = new DefaultCacheManager(global.build());
Configuration builder = new ConfigurationBuilder();
builder.statistics().enable();
3.2. Configuring Data Grid metrics Copy linkLink copied to clipboard!
Data Grid generates metrics that are compatible with the MicroProfile Metrics API.
- Gauges provide values such as the average number of nanoseconds for write operations or JVM uptime.
- Histograms provide details about operation execution times such as read, write, and remove times.
By default, Data Grid generates gauges when you enable statistics but you can also configure it to generate histograms.
Procedure
- Open your Data Grid configuration for editing.
-
Add the
metricselement or object to the cache container. -
Enable or disable gauges with the
gaugesattribute or field. -
Enable or disable histograms with the
histogramsattribute or field. - Save and close your client configuration.
Metrics configuration
XML
JSON
YAML
GlobalConfigurationBuilder
Verification
For embedded caches, you must add the necessary MicroProfile API and provider JARs to your classpath to export Data Grid metrics.
3.3. Registering JMX MBeans Copy linkLink copied to clipboard!
Data Grid can register JMX MBeans that you can use to collect statistics and perform administrative operations. You must also enable statistics otherwise Data Grid provides 0 values for all statistic attributes in JMX MBeans.
Procedure
- Open your Data Grid configuration for editing.
-
Add the
jmxelement or object to the cache container and specifytrueas the value for theenabledattribute or field. -
Add the
domainattribute or field and specify the domain where JMX MBeans are exposed, if required. - Save and close your client configuration.
JMX configuration
XML
JSON
YAML
GlobalConfigurationBuilder
GlobalConfiguration global = GlobalConfigurationBuilder.defaultClusteredBuilder()
.jmx().enable()
.domain("org.mydomain");
GlobalConfiguration global = GlobalConfigurationBuilder.defaultClusteredBuilder()
.jmx().enable()
.domain("org.mydomain");
3.3.1. Enabling JMX remote ports Copy linkLink copied to clipboard!
Provide unique remote JMX ports to expose Data Grid MBeans through connections in JMXServiceURL format.
You can enable remote JMX ports using one of the following approaches:
- Enable remote JMX ports that require authentication to one of the Data Grid Server security realms.
- Enable remote JMX ports manually using the standard Java management configuration options.
Prerequisites
-
For remote JMX with authentication, define user roles using the default security realm. Users must have
controlRolewith read/write access or themonitorRolewith read-only access to access any JMX resources.
Procedure
Start Data Grid Server with a remote JMX port enabled using one of the following ways:
Enable remote JMX through port
9999.bin/server.sh --jmx 9999
bin/server.sh --jmx 9999Copy to Clipboard Copied! Toggle word wrap Toggle overflow WarningUsing remote JMX with SSL disabled is not intended for production environments.
Pass the following system properties to Data Grid Server at startup.
bin/server.sh -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
bin/server.sh -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow WarningEnabling remote JMX with no authentication or SSL is not secure and not recommended in any environment. Disabling authentication and SSL allows unauthorized users to connect to your server and access the data hosted there.
3.3.2. Data Grid MBeans Copy linkLink copied to clipboard!
Data Grid exposes JMX MBeans that represent manageable resources.
org.infinispan:type=Cache- Attributes and operations available for cache instances.
org.infinispan:type=CacheManager- Attributes and operations available for cache managers, including Data Grid cache and cluster health statistics.
For a complete list of available JMX MBeans along with descriptions and available operations and attributes, see the Data Grid JMX Components documentation.
3.3.3. Registering MBeans in custom MBean servers Copy linkLink copied to clipboard!
Data Grid includes an MBeanServerLookup interface that you can use to register MBeans in custom MBeanServer instances.
Prerequisites
-
Create an implementation of
MBeanServerLookupso that thegetMBeanServer()method returns the custom MBeanServer instance. - Configure Data Grid to register JMX MBeans.
Procedure
- Open your Data Grid configuration for editing.
-
Add the
mbean-server-lookupattribute or field to the JMX configuration for the cache manager. -
Specify fully qualified name (FQN) of your
MBeanServerLookupimplementation. - Save and close your client configuration.
JMX MBean server lookup configuration
XML
JSON
YAML
GlobalConfigurationBuilder
GlobalConfiguration global = GlobalConfigurationBuilder.defaultClusteredBuilder()
.jmx().enable()
.domain("org.mydomain")
.mBeanServerLookup(new com.acme.MyMBeanServerLookup());
GlobalConfiguration global = GlobalConfigurationBuilder.defaultClusteredBuilder()
.jmx().enable()
.domain("org.mydomain")
.mBeanServerLookup(new com.acme.MyMBeanServerLookup());
Chapter 4. Setting up Data Grid cluster transport Copy linkLink copied to clipboard!
Data Grid requires a transport layer so nodes can automatically join and leave clusters. The transport layer also enables Data Grid nodes to replicate or distribute data across the network and perform operations such as re-balancing and state transfer.
4.1. Default JGroups stacks Copy linkLink copied to clipboard!
Data Grid provides default JGroups stack files, default-jgroups-*.xml, in the default-configs directory inside the infinispan-core-13.0.10.Final-redhat-00001.jar file.
| File name | Stack name | Description |
|---|---|---|
|
|
| Uses UDP for transport and UDP multicast for discovery. Suitable for larger clusters (over 100 nodes) or if you are using replicated caches or invalidation mode. Minimizes the number of open sockets. |
|
|
|
Uses TCP for transport and the |
|
|
|
Uses TCP for transport and |
|
|
|
Uses TCP for transport and |
|
|
|
Uses TCP for transport and |
|
|
|
Uses TCP for transport and |
4.2. Cluster discovery protocols Copy linkLink copied to clipboard!
Data Grid supports different protocols that allow nodes to automatically find each other on the network and form clusters.
There are two types of discovery mechanisms that Data Grid can use:
- Generic discovery protocols that work on most networks and do not rely on external services.
-
Discovery protocols that rely on external services to store and retrieve topology information for Data Grid clusters.
For instance the DNS_PING protocol performs discovery through DNS server records.
Running Data Grid on hosted platforms requires using discovery mechanisms that are adapted to network constraints that individual cloud providers impose.
4.2.1. PING Copy linkLink copied to clipboard!
PING, or UDPPING is a generic JGroups discovery mechanism that uses dynamic multicasting with the UDP protocol.
When joining, nodes send PING requests to an IP multicast address to discover other nodes already in the Data Grid cluster. Each node responds to the PING request with a packet that contains the address of the coordinator node and its own address. C=coordinator’s address and A=own address. If no nodes respond to the PING request, the joining node becomes the coordinator node in a new cluster.
PING configuration example
<PING num_discovery_runs="3"/>
<PING num_discovery_runs="3"/>
4.2.2. TCPPING Copy linkLink copied to clipboard!
TCPPING is a generic JGroups discovery mechanism that uses a list of static addresses for cluster members.
With TCPPING, you manually specify the IP address or hostname of each node in the Data Grid cluster as part of the JGroups stack, rather than letting nodes discover each other dynamically.
TCPPING configuration example
<TCP bind_port="7800" />
<TCPPING timeout="3000"
initial_hosts="${jgroups.tcpping.initial_hosts:hostname1[port1],hostname2[port2]}"
port_range="0"
num_initial_members="3"/>
<TCP bind_port="7800" />
<TCPPING timeout="3000"
initial_hosts="${jgroups.tcpping.initial_hosts:hostname1[port1],hostname2[port2]}"
port_range="0"
num_initial_members="3"/>
4.2.3. MPING Copy linkLink copied to clipboard!
MPING uses IP multicast to discover the initial membership of Data Grid clusters.
You can use MPING to replace TCPPING discovery with TCP stacks and use multicasing for discovery instead of static lists of initial hosts. However, you can also use MPING with UDP stacks.
MPING configuration example
<MPING mcast_addr="${jgroups.mcast_addr:228.6.7.8}"
mcast_port="${jgroups.mcast_port:46655}"
num_discovery_runs="3"
ip_ttl="${jgroups.udp.ip_ttl:2}"/>
<MPING mcast_addr="${jgroups.mcast_addr:228.6.7.8}"
mcast_port="${jgroups.mcast_port:46655}"
num_discovery_runs="3"
ip_ttl="${jgroups.udp.ip_ttl:2}"/>
4.2.4. TCPGOSSIP Copy linkLink copied to clipboard!
Gossip routers provide a centralized location on the network from which your Data Grid cluster can retrieve addresses of other nodes.
You inject the address (IP:PORT) of the Gossip router into Data Grid nodes as follows:
-
Pass the address as a system property to the JVM; for example,
-DGossipRouterAddress="10.10.2.4[12001]". - Reference that system property in the JGroups configuration file.
Gossip router configuration example
<TCP bind_port="7800" />
<TCPGOSSIP timeout="3000"
initial_hosts="${GossipRouterAddress}"
num_initial_members="3" />
<TCP bind_port="7800" />
<TCPGOSSIP timeout="3000"
initial_hosts="${GossipRouterAddress}"
num_initial_members="3" />
4.2.5. JDBC_PING Copy linkLink copied to clipboard!
JDBC_PING uses shared databases to store information about Data Grid clusters. This protocol supports any database that can use a JDBC connection.
Nodes write their IP addresses to the shared database so joining nodes can find the Data Grid cluster on the network. When nodes leave Data Grid clusters, they delete their IP addresses from the shared database.
JDBC_PING configuration example
<JDBC_PING connection_url="jdbc:mysql://localhost:3306/database_name"
connection_username="user"
connection_password="password"
connection_driver="com.mysql.jdbc.Driver"/>
<JDBC_PING connection_url="jdbc:mysql://localhost:3306/database_name"
connection_username="user"
connection_password="password"
connection_driver="com.mysql.jdbc.Driver"/>
Add the appropriate JDBC driver to the classpath so Data Grid can use JDBC_PING.
4.2.6. DNS_PING Copy linkLink copied to clipboard!
JGroups DNS_PING queries DNS servers to discover Data Grid cluster members in Kubernetes environments such as OKD and Red Hat OpenShift.
DNS_PING configuration example
<dns.DNS_PING dns_query="myservice.myproject.svc.cluster.local" />
<dns.DNS_PING dns_query="myservice.myproject.svc.cluster.local" />
4.2.7. Cloud discovery protocols Copy linkLink copied to clipboard!
Data Grid includes default JGroups stacks that use discovery protocol implementations that are specific to cloud providers.
| Discovery protocol | Default stack file | Artifact | Version |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Providing dependencies for cloud discovery protocols
To use NATIVE_S3_PING, GOOGLE_PING2, or AZURE_PING cloud discovery protocols, you need to provide dependent libraries to Data Grid.
Procedure
-
Add the artifact dependencies to your project
pom.xml.
You can then configure the cloud discovery protocol as part of a JGroups stack file or with system properties.
4.3. Using the default JGroups stacks Copy linkLink copied to clipboard!
Data Grid uses JGroups protocol stacks so nodes can send each other messages on dedicated cluster channels.
Data Grid provides preconfigured JGroups stacks for UDP and TCP protocols. You can use these default stacks as a starting point for building custom cluster transport configuration that is optimized for your network requirements.
Procedure
Do one of the following to use one of the default JGroups stacks:
Use the
stackattribute in yourinfinispan.xmlfile.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Use the
addProperty()method to set the JGroups stack file:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Data Grid logs the following message to indicate which stack it uses:
[org.infinispan.CLUSTER] ISPN000078: Starting JGroups channel cluster with stack udp
[org.infinispan.CLUSTER] ISPN000078: Starting JGroups channel cluster with stack udp
4.4. Customizing JGroups stacks Copy linkLink copied to clipboard!
Adjust and tune properties to create a cluster transport configuration that works for your network requirements.
Data Grid provides attributes that let you extend the default JGroups stacks for easier configuration. You can inherit properties from the default stacks while combining, removing, and replacing other properties.
Procedure
-
Create a new JGroups stack declaration in your
infinispan.xmlfile. -
Add the
extendsattribute and specify a JGroups stack to inherit properties from. -
Use the
stack.combineattribute to modify properties for protocols configured in the inherited stack. -
Use the
stack.positionattribute to define the location for your custom stack. Specify the stack name as the value for the
stackattribute in thetransportconfiguration.For example, you might evaluate using a Gossip router and symmetric encryption with the default TCP stack as follows:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Check Data Grid logs to ensure it uses the stack.
[org.infinispan.CLUSTER] ISPN000078: Starting JGroups channel cluster with stack my-stack
[org.infinispan.CLUSTER] ISPN000078: Starting JGroups channel cluster with stack my-stackCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Reference
- JGroups cluster transport configuration for Data Grid 8.x (Red Hat knowledgebase article)
4.4.1. Inheritance attributes Copy linkLink copied to clipboard!
When you extend a JGroups stack, inheritance attributes let you adjust protocols and properties in the stack you are extending.
-
stack.positionspecifies protocols to modify. stack.combineuses the following values to extend JGroups stacks:Expand Value Description COMBINEOverrides protocol properties.
REPLACEReplaces protocols.
INSERT_AFTERAdds a protocol into the stack after another protocol. Does not affect the protocol that you specify as the insertion point.
Protocols in JGroups stacks affect each other based on their location in the stack. For example, you should put a protocol such as
NAKACK2after theSYM_ENCRYPTorASYM_ENCRYPTprotocol so thatNAKACK2is secured.INSERT_BEFOREInserts a protocols into the stack before another protocol. Affects the protocol that you specify as the insertion point.
REMOVERemoves protocols from the stack.
4.5. Using JGroups system properties Copy linkLink copied to clipboard!
Pass system properties to Data Grid at startup to tune cluster transport.
Procedure
-
Use
-D<property-name>=<property-value>arguments to set JGroups system properties as required.
For example, set a custom bind port and IP address as follows:
java -cp ... -Djgroups.bind.port=1234 -Djgroups.bind.address=192.0.2.0
java -cp ... -Djgroups.bind.port=1234 -Djgroups.bind.address=192.0.2.0
When you embed Data Grid clusters in clustered Red Hat JBoss EAP applications, JGroups system properties can clash or override each other.
For example, you do not set a unique bind address for either your Data Grid cluster or your Red Hat JBoss EAP application. In this case both Data Grid and your Red Hat JBoss EAP application use the JGroups default property and attempt to form clusters using the same bind address.
4.5.1. Cluster transport properties Copy linkLink copied to clipboard!
Use the following properties to customize JGroups cluster transport.
| System Property | Description | Default Value | Required/Optional |
|---|---|---|---|
|
| Bind address for cluster transport. |
| Optional |
|
| Bind port for the socket. |
| Optional |
|
| IP address for multicast, both discovery and inter-cluster communication. The IP address must be a valid "class D" address that is suitable for IP multicast. |
| Optional |
|
| Port for the multicast socket. |
| Optional |
|
| Time-to-live (TTL) for IP multicast packets. The value defines the number of network hops a packet can make before it is dropped. | 2 | Optional |
|
| Minimum number of threads for the thread pool. | 0 | Optional |
|
| Maximum number of threads for the thread pool. | 200 | Optional |
|
| Maximum number of milliseconds to wait for join requests to succeed. | 2000 | Optional |
|
| Number of times a thread pool needs to be full before a thread dump is logged. | 10000 | Optional |
4.5.2. System properties for cloud discovery protocols Copy linkLink copied to clipboard!
Use the following properties to configure JGroups discovery protocols for hosted platforms.
4.5.2.1. Amazon EC2 Copy linkLink copied to clipboard!
System properties for configuring NATIVE_S3_PING.
| System Property | Description | Default Value | Required/Optional |
|---|---|---|---|
|
| Name of the Amazon S3 region. | No default value. | Optional |
|
| Name of the Amazon S3 bucket. The name must exist and be unique. | No default value. | Optional |
4.5.2.2. Google Cloud Platform Copy linkLink copied to clipboard!
System properties for configuring GOOGLE_PING2.
| System Property | Description | Default Value | Required/Optional |
|---|---|---|---|
|
| Name of the Google Compute Engine bucket. The name must exist and be unique. | No default value. | Required |
4.5.2.3. Azure Copy linkLink copied to clipboard!
System properties for AZURE_PING.
| System Property | Description | Default Value | Required/Optional |
|---|---|---|---|
|
| Name of the Azure storage account. The name must exist and be unique. | No default value. | Required |
|
| Name of the Azure storage access key. | No default value. | Required |
|
| Valid DNS name of the container that stores ping information. | No default value. | Required |
4.5.2.4. OpenShift Copy linkLink copied to clipboard!
System properties for DNS_PING.
| System Property | Description | Default Value | Required/Optional |
|---|---|---|---|
|
| Sets the DNS record that returns cluster members. | No default value. | Required |
4.6. Using inline JGroups stacks Copy linkLink copied to clipboard!
You can insert complete JGroups stack definitions into infinispan.xml files.
Procedure
Embed a custom JGroups stack declaration in your
infinispan.xmlfile.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7. Using external JGroups stacks Copy linkLink copied to clipboard!
Reference external files that define custom JGroups stacks in infinispan.xml files.
Procedure
Put custom JGroups stack files on the application classpath.
Alternatively you can specify an absolute path when you declare the external stack file.
Reference the external stack file with the
stack-fileelement.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
You can also use the addProperty() method in the TransportConfigurationBuilder class to specify a custom JGroups stack file as follows:
In this example, my-jgroups-udp.xml references a UDP stack with custom properties such as the following:
Custom UDP stack example
4.8. Using custom JChannels Copy linkLink copied to clipboard!
Construct custom JGroups JChannels as in the following example:
Data Grid cannot use custom JChannels that are already connected.
4.9. Encrypting cluster transport Copy linkLink copied to clipboard!
Secure cluster transport so that nodes communicate with encrypted messages. You can also configure Data Grid clusters to perform certificate authentication so that only nodes with valid identities can join.
4.9.1. JGroups encryption protocols Copy linkLink copied to clipboard!
To secure cluster traffic, you can configure Data Grid nodes to encrypt JGroups message payloads with secret keys.
Data Grid nodes can obtain secret keys from either:
- The coordinator node (asymmetric encryption).
- A shared keystore (symmetric encryption).
Retrieving secret keys from coordinator nodes
You configure asymmetric encryption by adding the ASYM_ENCRYPT protocol to a JGroups stack in your Data Grid configuration. This allows Data Grid clusters to generate and distribute secret keys.
When using asymmetric encryption, you should also provide keystores so that nodes can perform certificate authentication and securely exchange secret keys. This protects your cluster from man-in-the-middle (MitM) attacks.
Asymmetric encryption secures cluster traffic as follows:
- The first node in the Data Grid cluster, the coordinator node, generates a secret key.
- A joining node performs certificate authentication with the coordinator to mutually verify identity.
- The joining node requests the secret key from the coordinator node. That request includes the public key for the joining node.
- The coordinator node encrypts the secret key with the public key and returns it to the joining node.
- The joining node decrypts and installs the secret key.
- The node joins the cluster, encrypting and decrypting messages with the secret key.
Retrieving secret keys from shared keystores
You configure symmetric encryption by adding the SYM_ENCRYPT protocol to a JGroups stack in your Data Grid configuration. This allows Data Grid clusters to obtain secret keys from keystores that you provide.
- Nodes install the secret key from a keystore on the Data Grid classpath at startup.
- Node join clusters, encrypting and decrypting messages with the secret key.
Comparison of asymmetric and symmetric encryption
ASYM_ENCRYPT with certificate authentication provides an additional layer of encryption in comparison with SYM_ENCRYPT. You provide keystores that encrypt the requests to coordinator nodes for the secret key. Data Grid automatically generates that secret key and handles cluster traffic, while letting you specify when to generate secret keys. For example, you can configure clusters to generate new secret keys when nodes leave. This ensures that nodes cannot bypass certificate authentication and join with old keys.
SYM_ENCRYPT, on the other hand, is faster than ASYM_ENCRYPT because nodes do not need to exchange keys with the cluster coordinator. A potential drawback to SYM_ENCRYPT is that there is no configuration to automatically generate new secret keys when cluster membership changes. Users are responsible for generating and distributing the secret keys that nodes use to encrypt cluster traffic.
4.9.2. Securing cluster transport with asymmetric encryption Copy linkLink copied to clipboard!
Configure Data Grid clusters to generate and distribute secret keys that encrypt JGroups messages.
Procedure
- Create a keystore with certificate chains that enables Data Grid to verify node identity.
Place the keystore on the classpath for each node in the cluster.
For Data Grid Server, you put the keystore in the $RHDG_HOME directory.
Add the
SSL_KEY_EXCHANGEandASYM_ENCRYPTprotocols to a JGroups stack in your Data Grid configuration, as in the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
When you start your Data Grid cluster, the following log message indicates that the cluster is using the secure JGroups stack:
[org.infinispan.CLUSTER] ISPN000078: Starting JGroups channel cluster with stack <encrypted_stack_name>
[org.infinispan.CLUSTER] ISPN000078: Starting JGroups channel cluster with stack <encrypted_stack_name>
Data Grid nodes can join the cluster only if they use ASYM_ENCRYPT and can obtain the secret key from the coordinator node. Otherwise the following message is written to Data Grid logs:
[org.jgroups.protocols.ASYM_ENCRYPT] <hostname>: received message without encrypt header from <hostname>; dropping it
[org.jgroups.protocols.ASYM_ENCRYPT] <hostname>: received message without encrypt header from <hostname>; dropping it
4.9.3. Securing cluster transport with symmetric encryption Copy linkLink copied to clipboard!
Configure Data Grid clusters to encrypt JGroups messages with secret keys from keystores that you provide.
Procedure
- Create a keystore that contains a secret key.
Place the keystore on the classpath for each node in the cluster.
For Data Grid Server, you put the keystore in the $RHDG_HOME directory.
-
Add the
SYM_ENCRYPTprotocol to a JGroups stack in your Data Grid configuration.
Verification
When you start your Data Grid cluster, the following log message indicates that the cluster is using the secure JGroups stack:
[org.infinispan.CLUSTER] ISPN000078: Starting JGroups channel cluster with stack <encrypted_stack_name>
[org.infinispan.CLUSTER] ISPN000078: Starting JGroups channel cluster with stack <encrypted_stack_name>
Data Grid nodes can join the cluster only if they use SYM_ENCRYPT and can obtain the secret key from the shared keystore. Otherwise the following message is written to Data Grid logs:
[org.jgroups.protocols.SYM_ENCRYPT] <hostname>: received message without encrypt header from <hostname>; dropping it
[org.jgroups.protocols.SYM_ENCRYPT] <hostname>: received message without encrypt header from <hostname>; dropping it
4.10. TCP and UDP ports for cluster traffic Copy linkLink copied to clipboard!
Data Grid uses the following ports for cluster transport messages:
| Default Port | Protocol | Description |
|---|---|---|
|
| TCP/UDP | JGroups cluster bind port |
|
| UDP | JGroups multicast |
Cross-site replication
Data Grid uses the following ports for the JGroups RELAY2 protocol:
7900- For Data Grid clusters running on OpenShift.
7800- If using UDP for traffic between nodes and TCP for traffic between clusters.
7801- If using TCP for traffic between nodes and TCP for traffic between clusters.