Este contenido no está disponible en el idioma seleccionado.
Chapter 1. Getting started with Data Grid Server
Quickly set up Data Grid Server and learn the basics.
Ansible collection
Automate installation of Data Grid clusters with our Ansible collection that optionally includes Keycloak caches and cross-site replication configuration. The Ansible collection also lets you inject Data Grid caches into the static configuration for each server instance during installation.
The Ansible collection for Data Grid is available from the Red Hat Automation Hub.
1.1. Data Grid Server requirements Copiar enlaceEnlace copiado en el portapapeles!
Data Grid Server requires a Java Virtual Machine. See the Data Grid Supported Configurations for details on supported versions.
1.2. Downloading Data Grid Server distributions Copiar enlaceEnlace copiado en el portapapeles!
				The Data Grid Server distribution is an archive of Java libraries (JAR files) and configuration files.
			
Procedure
- Access the Red Hat customer portal.
 - Download Red Hat Data Grid 8.3 Server from the software downloads section.
 Run the
md5sumorsha256sumcommand with the server download archive as the argument, for example:sha256sum jboss-datagrid-${version}-server.zipsha256sum jboss-datagrid-${version}-server.zipCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 
						Compare with the 
MD5orSHA-256checksum value on the Data Grid Software Details page. 
Reference
- Data Grid Server README describes the contents of the server distribution.
 
1.3. Installing Data Grid Server Copiar enlaceEnlace copiado en el portapapeles!
Install the Data Grid Server distribution on a host system.
Prerequisites
- Download a Data Grid Server distribution archive.
 
Procedure
- Use any appropriate tool to extract the Data Grid Server archive to the host filesystem.
 
unzip redhat-datagrid-8.3.1-server.zip
unzip redhat-datagrid-8.3.1-server.zip
				The resulting directory is your $RHDG_HOME.
			
1.4. Starting Data Grid Server Copiar enlaceEnlace copiado en el portapapeles!
Run Data Grid Server instances in a Java Virtual Machine (JVM) on any supported host.
Prerequisites
- Download and install the server distribution.
 
Procedure
- 
						Open a terminal in 
$RHDG_HOME. Start Data Grid Server instances with the
serverscript.- Linux
 bin/server.sh
bin/server.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Microsoft Windows
 bin\server.bat
bin\server.batCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
Data Grid Server is running successfully when it logs the following messages:
ISPN080004: Protocol SINGLE_PORT listening on 127.0.0.1:11222 ISPN080034: Server '...' listening on http://127.0.0.1:11222 ISPN080001: Data Grid Server <version> started in <mm>ms
ISPN080004: Protocol SINGLE_PORT listening on 127.0.0.1:11222
ISPN080034: Server '...' listening on http://127.0.0.1:11222
ISPN080001: Data Grid Server <version> started in <mm>ms
Verification
- 
						Open 
127.0.0.1:11222/console/in any browser. - Enter your credentials at the prompt and continue to Data Grid Console.
 
1.5. Passing Data Grid Server configuration at startup Copiar enlaceEnlace copiado en el portapapeles!
Specify custom configuration when you start Data Grid Server.
				Data Grid Server can parse multiple configuration files that you overlay on startup with the --server-config argument. You can use as many configuration overlay files as required, in any order. Configuration overlay files:
			
- 
						Must be valid Data Grid configuration and contain the root 
serverelement or field. - Do not need to be full configuration as long as your combination of overlay files results in a full configuration.
 
Data Grid Server does not detect conflicting configuration between overlay files. Each overlay file overwrites any conflicting configuration in the preceding configuration.
If you pass cache configuration to Data Grid Server on startup it does not dynamically create those cache across the cluster. You must manually propagate caches to each node.
					Additionally, cache configuration that you pass to Data Grid Server on startup must include the infinispan and cache-container elements.
				
Prerequisites
- Download and install the server distribution.
 - 
						Add custom server configuration to the 
server/confdirectory of your Data Grid Server installation. 
Procedure
- 
						Open a terminal in 
$RHDG_HOME. Specify one or more configuration files with the
--server-config=or-cargument, for example:bin/server.sh -c infinispan.xml -c datasources.yaml -c security-realms.json
bin/server.sh -c infinispan.xml -c datasources.yaml -c security-realms.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
1.6. Creating and modifying Data Grid users Copiar enlaceEnlace copiado en el portapapeles!
Add Data Grid user credentials and assign permissions to control access to data.
Data Grid server installations use a property realm to authenticate users for the Hot Rod and REST endpoints. This means you need to create at least one user before you can access Data Grid.
By default, users also need roles with permissions to access caches and interact with Data Grid resources. You can assign roles to users individually or add users to groups that have role permissions.
				You create users and assign roles with the user command in the Data Grid command line interface (CLI).
			
				Run help user from a CLI session to get complete command details.
			
1.6.1. Adding credentials Copiar enlaceEnlace copiado en el portapapeles!
					You need an admin user for the Data Grid Console and full control over your Data Grid environment. For this reason you should create a user with admin permissions the first time you add credentials.
				
Procedure
- 
							Open a terminal in 
$RHDG_HOME. Create an
adminuser with theuser createcommand.Add a user assigned to the
admingroup.bin/cli.sh user create myuser -p changeme -g admin
bin/cli.sh user create myuser -p changeme -g adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow Use implicit authorization to gain
adminpermissions.bin/cli.sh user create admin -p changeme
bin/cli.sh user create admin -p changemeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
Open
user.propertiesandgroups.propertieswith any text editor to verify users and groups.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
1.6.2. Assigning roles to users Copiar enlaceEnlace copiado en el portapapeles!
Assign roles to users so they have the correct permissions to access data and modify Data Grid resources.
Procedure
Start a CLI session with an
adminuser.bin/cli.sh
$ bin/cli.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow Assign the
deployerrole to "katie".[//containers/default]> user roles grant --roles=deployer katie
[//containers/default]> user roles grant --roles=deployer katieCopy to Clipboard Copied! Toggle word wrap Toggle overflow List roles for "katie".
[//containers/default]> user roles ls katie ["deployer"]
[//containers/default]> user roles ls katie ["deployer"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
1.6.3. Adding users to groups Copiar enlaceEnlace copiado en el portapapeles!
Groups let you change permissions for multiple users. You assign a role to a group and then add users to that group. Users inherit permissions from the group role.
Procedure
- 
							Start a CLI session with an 
adminuser. Use the
user createcommand to create a group.- 
									Specify "developers" as the group name with the 
--groupsargument. Set a username and password for the group.
In a property realm, a group is a special type of user that also requires a username and password.
[//containers/default]> user create --groups=developers developers -p changeme
[//containers/default]> user create --groups=developers developers -p changemeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
- 
									Specify "developers" as the group name with the 
 List groups.
[//containers/default]> user ls --groups ["developers"]
[//containers/default]> user ls --groups ["developers"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow Assign the
applicationrole to the "developers" group.[//containers/default]> user roles grant --roles=application developers
[//containers/default]> user roles grant --roles=application developersCopy to Clipboard Copied! Toggle word wrap Toggle overflow List roles for the "developers" group.
[//containers/default]> user roles ls developers ["application"]
[//containers/default]> user roles ls developers ["application"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add existing users, one at a time, to the group as required.
[//containers/default]> user groups john --groups=developers
[//containers/default]> user groups john --groups=developersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 
1.6.4. User roles and permissions Copiar enlaceEnlace copiado en el portapapeles!
Data Grid includes a default set of roles that grant users with permissions to access data and interact with Data Grid resources.
					ClusterRoleMapper is the default mechanism that Data Grid uses to associate security principals to authorization roles.
				
						ClusterRoleMapper matches principal names to role names. A user named admin gets admin permissions automatically, a user named deployer gets deployer permissions, and so on.
					
| Role | Permissions | Description | 
|---|---|---|
|   
									  |   ALL  |   Superuser with all permissions including control of the Cache Manager lifecycle.  | 
|   
									  |   ALL_READ, ALL_WRITE, LISTEN, EXEC, MONITOR, CREATE  |   
									Can create and delete Data Grid resources in addition to   | 
|   
									  |   ALL_READ, ALL_WRITE, LISTEN, EXEC, MONITOR  |   
									Has read and write access to Data Grid resources in addition to   | 
|   
									  |   ALL_READ, MONITOR  |   
									Has read access to Data Grid resources in addition to   | 
|   
									  |   MONITOR  |   
									Can view statistics via JMX and the   | 
1.7. Verifying cluster views Copiar enlaceEnlace copiado en el portapapeles!
Data Grid Server instances on the same network automatically discover each other and form clusters.
				Complete this procedure to observe cluster discovery with the MPING protocol in the default TCP stack with locally running Data Grid Server instances. If you want to adjust cluster transport for custom network requirements, see the documentation for setting up Data Grid clusters.
			
This procedure is intended to demonstrate the principle of cluster discovery and is not intended for production environments. Doing things like specifying a port offset on the command line is not a reliable way to configure cluster transport for production.
Prerequisites
Have one instance of Data Grid Server running.
Procedure
- 
						Open a terminal in 
$RHDG_HOME. Copy the root directory to
server2.cp -r server server2
cp -r server server2Copy to Clipboard Copied! Toggle word wrap Toggle overflow Specify a port offset and the
server2directory.bin/server.sh -o 100 -s server2
bin/server.sh -o 100 -s server2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
Verification
					You can view cluster membership in the console at 127.0.0.1:11222/console/cluster-membership.
				
Data Grid also logs the following messages when nodes join clusters:
1.8. Shutting down Data Grid Server Copiar enlaceEnlace copiado en el portapapeles!
Stop individually running servers or bring down clusters gracefully.
Procedure
- Create a CLI connection to Data Grid.
 Shut down Data Grid Server in one of the following ways:
Stop all nodes in a cluster with the
shutdown clustercommand, for example:shutdown cluster
shutdown clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow This command saves cluster state to the
datafolder for each node in the cluster. If you use a cache store, theshutdown clustercommand also persists all data in the cache.Stop individual server instances with the
shutdown servercommand and the server hostname, for example:shutdown server <my_server01>
shutdown server <my_server01>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 
					The shutdown server command does not wait for rebalancing operations to complete, which can lead to data loss if you specify multiple hostnames at the same time.
				
				Run help shutdown for more details about using the command.
			
Verification
Data Grid logs the following messages when you shut down servers:
ISPN080002: Data Grid Server stopping ISPN000080: Disconnecting JGroups channel cluster ISPN000390: Persisted state, version=<$version> timestamp=YYYY-MM-DDTHH:MM:SS ISPN080003: Data Grid Server stopped
ISPN080002: Data Grid Server stopping
ISPN000080: Disconnecting JGroups channel cluster
ISPN000390: Persisted state, version=<$version> timestamp=YYYY-MM-DDTHH:MM:SS
ISPN080003: Data Grid Server stopped
1.8.1. Data Grid cluster restarts Copiar enlaceEnlace copiado en el portapapeles!
When you bring Data Grid clusters back online after shutting them down, you should wait for the cluster to be available before adding or removing nodes or modifying cluster state.
					If you shutdown clustered nodes with the shutdown server command, you must restart each server in reverse order.
 For example, if you shutdown server1 and then shutdown server2, you should first start server2 and then start server1.
				
					If you shutdown a cluster with the shutdown cluster command, clusters become fully operational only after all nodes rejoin.
 You can restart nodes in any order but the cluster remains in DEGRADED state until all nodes that were joined before shutdown are running.
				
1.9. Data Grid Server installation directory structure Copiar enlaceEnlace copiado en el portapapeles!
				Data Grid Server uses the following folders on the host filesystem under $RHDG_HOME:
			
				See the Data Grid Server README for descriptions of the each folder in your $RHDG_HOME directory as well as system properties you can use to customize the filesystem.
			
1.9.1. Server root directory Copiar enlaceEnlace copiado en el portapapeles!
					Apart from resources in the bin and docs folders, the only folder under $RHDG_HOME that you should interact with is the server root directory, which is named server by default.
				
					You can create multiple nodes under the same $RHDG_HOME directory or in different directories, but each Data Grid Server instance must have its own server root directory. For example, a cluster of 5 nodes could have the following server root directories on the filesystem:
				
├── server ├── server1 ├── server2 ├── server3 └── server4
├── server
├── server1
├── server2
├── server3
└── server4
Each server root directory should contain the following folders:
├── server │ ├── conf │ ├── data │ ├── lib │ └── log
├── server
│   ├── conf
│   ├── data
│   ├── lib
│   └── log
server/conf
					Holds infinispan.xml configuration files for a Data Grid Server instance.
				
Data Grid separates configuration into two layers:
- Dynamic
 - 
								Create mutable cache configurations for data scalability.
Data Grid Server permanently saves the caches you create at runtime along with the cluster state that is distributed across nodes. Each joining node receives a complete cluster state that Data Grid Server synchronizes across all nodes whenever changes occur. - Static
 - 
								Add configuration to 
infinispan.xmlfor underlying server mechanisms such as cluster transport, security, and shared datasources. 
server/data
Provides internal storage that Data Grid Server uses to maintain cluster state.
						Never directly delete or modify content in server/data.
					
						Modifying files such as caches.xml while the server is running can cause corruption. Deleting content can result in an incorrect state, which means clusters cannot restart after shutdown.
					
server/lib
					Contains extension JAR files for custom filters, custom event listeners, JDBC drivers, custom ServerTask implementations, and so on.
				
server/log
Holds Data Grid Server log files.