Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

此内容没有您所选择的语言版本。

Chapter 3. Data Grid Server endpoints

Data Grid Server endpoints provide client access to the cache manager over different protocols. A server endpoint can multiplex multiple protocols on the same socket binding by detecting the incoming traffic type and routing it to the appropriate internal connector handler.

3.1. Data Grid Server protocols
复制链接

3.1.1. Hot Rod
复制链接

Hot Rod is a binary TCP client-server protocol designed to provide faster data access and improved performance in comparison to text-based protocols.

Data Grid provides Hot Rod client libraries in Java, C++, C#, Node.js and other programming languages.

Topology caches

Data Grid uses topology caches to provide clients with cluster views. Topology caches contain entries that map internal JGroups transport addresses to exposed Hot Rod endpoints.

When clients send requests, Data Grid servers compare the topology ID in request headers with the topology ID from the cache. Data Grid servers send new topology views if clients have older topology IDs.

Cluster topology views allow Hot Rod clients to immediately detect when nodes join and leave, which enables dynamic load balancing and failover.

In distributed cache modes, the consistent hashing algorithm also makes it possible to route Hot Rod client requests directly to primary owners.

3.1.2. REST
复制链接

Data Grid exposes a RESTful interface that allows HTTP clients to access data, monitor and maintain clusters, and perform administrative operations.

You can use standard HTTP load balancers to provide clients with load balancing and failover capabilities. However, HTTP load balancers maintain static cluster views and require manual updates when cluster topology changes occur.

3.1.3. RESP
复制链接

Data Grid provides an implementation of the RESP3 protocol used by Redis, Valkey, Elasticache and others.

The RESP connector supports a large subset of the Redis commands.

3.1.4. Memcached
复制链接

Data Grid provides an implementation of the Memcached text and binary protocols for remote client access.

The Data Grid Memcached endpoint supports clustering with replicated and distributed cache modes.

There are some Memcached client implementations, such as the Cache::Memcached Perl client, that can offer load balancing and failover detection capabilities with static lists of Data Grid server addresses that require manual updates when cluster topology changes occur.

3.1.5. Comparison of protocols
复制链接

Expand
 Hot RodHTTP / RESTMemcachedRESP

Topology-aware

Y

N

N

N

Hash-aware

Y

N

N

N

Encryption

Y

Y

Y

Y

Authentication

Y

Y

Y

Y

Conditional ops

Y

Y

Y

N

Bulk ops

Y

N

Y

Y

Transactions

Y

N

N

N

Listeners

Y

N

N

Y

Query

Y

Y

N

N

Execution

Y

N

N

N

Cross-site failover

Y

N

N

N

3.1.6. Hot Rod client compatibility with Data Grid Server
复制链接

Before diving into advanced configuration, here is a quick note on version compatibility. Data Grid Server allows you to connect Hot Rod clients with different versions. For instance, during a migration or upgrade to your Data Grid cluster, the Hot Rod client version might be lower than the Data Grid Server version.

Tip

Data Grid recommends using the latest Hot Rod client version to benefit from the most recent capabilities and security enhancements.

Data Grid 8 and later

Hot Rod protocol version 3.x automatically negotiates the highest version possible for clients with Data Grid Server.

Data Grid 7.3 and earlier

The client no longer supports Hot Rod protocol versions older than 3.0. As such, you must use an older client or the hotrod-client-legacy module.

Clients that use a Hot Rod protocol version that is higher than the Data Grid Server version must set the infinispan.client.hotrod.protocol_version property.

3.2. Configuring Data Grid Server endpoints
复制链接

Control how the different server endpoints bind to sockets and use security realm configuration.

Prerequisites

  • Add socket bindings and security realms to your Data Grid Server configuration.

Procedure

  1. Open your Data Grid Server configuration for editing.
  2. Wrap multiple endpoint configurations with the endpoints element.
  3. Specify the socket binding that the endpoint uses with the socket-binding attribute.
  4. Specify the security realm that the endpoint uses with the security-realm attribute.

  5. Disable administrator access with the admin="false" attribute, if required.

    With this configuration users cannot access Data Grid Console or the Command Line Interface (CLI) from the endpoint.

  6. Save the changes to your configuration.
Note

Data Grid Server must be configured with at least one endpoint which has a REST connector with administrative capabilities.

Multiple endpoint configuration

The following Data Grid Server configuration creates endpoints on separate socket bindings with dedicated security realms and disabling administrative access on the public endpoint:

XML

<server xmlns="urn:infinispan:server:16.0">
  <endpoints>
    <endpoint socket-binding="public"
              security-realm="application-realm"
              admin="false">
    </endpoint>
    <endpoint socket-binding="private"
              security-realm="management-realm">
    </endpoint>
  </endpoints>
</server>

JSON

{
  "server": {
    "endpoints": [
      {
        "socket-binding": "public",
        "security-realm": "application-realm",
        "admin": "false"
      },
      {
      "socket-binding": "private",
      "security-realm": "management-realm"
    }]
  }
}

YAML

server:
  endpoints:
   - socketBinding: public
     securityRealm: application-realm
     admin: false
   - socketBinding: private
     securityRealm: management-realm

3.3. Endpoint protocol connectors
复制链接

Endpoints multiplex different protocol connectors through a single port. Protocol connectors employ detectors to inspect incoming traffic and direct client connections to the appropriate handler. An endpoint will enable all protocol connectors that support the configured security realm, unless connectors are declared explicitly. The default endpoint configuration, using the default property security realm, implicitly enables all the protocol connectors (Hot Rod, REST, RESP, Memcached).

XML

<endpoints socket-binding="default" security-realm="default"/>

JSON

{
  "endpoints": [
    {
      "socket-binding": "default",
      "security-realm": "default"
    }
  ]
}

YAML

server:
  endpoints:
    - socketBinding: default
      securityRealm: default

Enable specific protocol connectors using explicit declaration.

Expand
Configuration element or attributeDescription

endpoints

Wraps endpoint connector configuration.

endpoint

Declares a Data Grid Server endpoint that configures Hot Rod and REST connectors to use a socket binding and security realm.

hotrod-connector

Includes the Hot Rod endpoint in the endpoint configuration.

rest-connector

Includes the REST endpoint in the endpoint configuration.

resp-connector

Includes the RESP endpoint in the endpoint configuration.

memcached-connector

Includes the Memcached endpoint in the endpoint configuration.

Expose a single endpoint with only the REST and Hot Rod connectors on the default socket binding with the default security realm:

XML

<server xmlns="urn:infinispan:server:16.0">
    <endpoints>
        <endpoint socket-binding="default" security-realm="default">
            <rest-connector/>
            <hotrod-connector/>
        </endpoint>
    </endpoints>
</server>

JSON

{
  "endpoints": [
    {
      "endpoint": {
        "socket-binding": "default",
        "security-realm": "default",
        "connectors": {
          "rest": {
            "rest-connector": {}
          },
          "hotrod": {
            "hotrod-connector": {}
          }
        }
      }
    }
  ]
}

YAML

endpoints:
  - socketBinding: default
    securityRealm: default
    connectors:
      rest:
        restConnector: ~
      hotrod:
        hotrodConnector: ~

Expose a REST connector on the default socket binding with the default security realm and a RESP connector on the resp socket binding with the none security realm:

XML

<server xmlns="urn:infinispan:server:16.0">
    <endpoints>
        <endpoint socket-binding="default" security-realm="default">
            <rest-connector/>
            <resp-connector socket-binding="resp" security-realm="none"/>
        </endpoint>
    </endpoints>
</server>

JSON

{
  "endpoints": [
    {
      "endpoint": {
        "socket-binding": "default",
        "security-realm": "default",
        "connectors": {
          "rest": {
            "rest-connector": {}
          },
          "resp": {
            "resp-connector": {
              "socket-binding": "resp",
              "security-realm": "none"
            }
          }
        }
      }
    }
  ]
}

YAML

endpoints:
  - socketBinding: default
    securityRealm: default
    connectors:
      rest:
        restConnector: ~
      resp:
        respConnector:
          socketBinding: resp
          securityRealm: none

3.3.1. Endpoint request limits
复制链接

Endpoints, by default, impose a 10MB limit on request sizes. If the client sends a request larger than the limit, the request may be met with an exception or the connection may be forcibly closed. The limit is configured via the max-content-length attributed. This is expressed in bytes and allows for a string value with a size suffix (e.g. 128KB, 10MB, 1.5GB). Note that this is the size of the entire request and is not limited to a single key or value.

Hot Rod, RESP & Memcached endpoints

<endpoints>
  <endpoint socket-binding="default" security-realm="default">
    <hotrod-connector name="hotrod" max-content-length="5MB">
      ...
    </hotrod-connector>
    <resp-connector name="resp" max-content-length="5MB">
      ...
    </hotrod-connector>
    <memcached-connector name="memcached" max-content-length="5MB">
      ...
    </hotrod-connector>
  </endpoint>
</endpoints>

REST endpoint

<endpoints>
  <endpoint socket-binding="default" security-realm="default">
    <rest-connector name="rest" max-content-length="5MB">
      ...
    </rest-connector>
  </endpoint>
</endpoints>

3.4. Endpoint IP address filtering rules
复制链接

Data Grid Server endpoints can use filtering rules that control whether clients can connect based on their IP addresses. Data Grid Server applies filtering rules in order until it finds a match for the client IP address.

A CIDR block is a compact representation of an IP address and its associated network mask. CIDR notation specifies an IP address, a slash ('/') character, and a decimal number. The decimal number is the count of leading 1 bits in the network mask. The number can also be thought of as the width, in bits, of the network prefix. The IP address in CIDR notation is always represented according to the standards for IPv4 or IPv6.

The address can denote a specific interface address, including a host identifier, such as 10.0.0.1/8, or it can be the beginning address of an entire network interface range using a host identifier of 0, as in 10.0.0.0/8 or 10/8.

For example:

  • 192.168.100.14/24 represents the IPv4 address 192.168.100.14 and its associated network prefix 192.168.100.0, or equivalently, its subnet mask 255.255.255.0, which has 24 leading 1-bits.
  • the IPv4 block 192.168.100.0/22 represents the 1024 IPv4 addresses from 192.168.100.0 to 192.168.103.255.
  • the IPv6 block 2001:db8::/48 represents the block of IPv6 addresses from 2001:db8:0:0:0:0:0:0 to 2001:db8:0:ffff:ffff:ffff:ffff:ffff.
  • ::1/128 represents the IPv6 loopback address. Its prefix length is 128 which is the number of bits in the address.

IP address filter configuration

In the following configuration, Data Grid Server accepts connections only from addresses in the 192.168.0.0/16 and 10.0.0.0/8 CIDR blocks. Data Grid Server rejects all other connections.

XML

<server xmlns="urn:infinispan:server:16.0">
  <endpoints>
    <endpoint socket-binding="default" security-realm="default">
      <ip-filter>
        <accept from="192.168.0.0/16"/>
        <accept from="10.0.0.0/8"/>
        <reject from="/0"/>
      </ip-filter>
    </endpoint>
  </endpoints>
</server>

JSON

{
  "server": {
    "endpoints": {
      "endpoint": {
        "socket-binding": "default",
        "security-realm": "default",
        "ip-filter": {
          "accept-from": ["192.168.0.0/16", "10.0.0.0/8"],
          "reject-from": "/0"
        }
      }
    }
  }
}

YAML

server:
  endpoints:
    endpoint:
      socketBinding: "default"
      securityRealm: "default"
      ipFilter:
        acceptFrom: ["192.168.0.0/16","10.0.0.0/8"]
        rejectFrom: "/0"

Configure IP address filtering rules on Data Grid Server endpoints to accept or reject connections based on client address.

Prerequisites

  • Install Data Grid Command Line Interface (CLI).

Procedure

  1. Create a CLI connection to Data Grid Server.

  2. Inspect and modify the IP filter rules server connector ipfilter command as required.

    1. List all IP filtering rules active on a connector across the cluster: 

      server connector ipfilter ls endpoint-default

    2. Set IP filtering rules across the cluster.

      Note

      This command replaces any existing rules. 

      server connector ipfilter set endpoint-default --rules=ACCEPT/192.168.0.0/16,REJECT/10.0.0.0/8`

    3. Remove all IP filtering rules on a connector across the cluster. 

      server connector ipfilter clear endpoint-default
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部