24.3. Infinispan

24.3.1. Infinispan 정보

Infinispan은 캐시된 데이터를 관리하기 위해 Jakarta Persistence 2.2와 호환 가능한 캐시 인터페이스를 제공하는 Java 데이터 그리드 플랫폼입니다.

jenkinsfile 기능 및 구성 옵션에 대한 자세한 내용은 jenkinsfile 설명서를 참조하십시오.

infinispan 하위 시스템은 JBoss EAP에 대한 캐싱 지원을 제공합니다. 이를 통해 이름이 지정된 캐시 컨테이너 및 캐시에 대한 런타임 지표를 구성하고 볼 수 있습니다.

관리형 도메인의 ha 또는 full-ha 프로필 또는 독립 실행형 서버에 대한 standalone-ha.xml 또는 standalone-full-ha.xml 구성 파일과 같은 고가용성 기능을 제공하는 구성을 사용하는 경우 infinispan 하위 시스템은 캐싱, 상태 복제 및 상태 배포 지원을 제공합니다. 고가용성이 아닌 구성에서 infinispan 하위 시스템은 로컬 캐싱 지원을 제공합니다.

중요

jenkinsfile은 JBoss EAP 7.4의 공용 모듈입니다. 애플리케이션에 infinispan 하위 시스템을 사용하여 새 cache-containers 또는 캐시를 생성하고 사용할 수 있습니다. 또한 jenkinsfile API 사용은 애플리케이션에서 지원됩니다.

24.3.2. 캐시 컨테이너

캐시 컨테이너는 하위 시스템에서 사용하는 캐시의 리포지토리입니다. 각 캐시 컨테이너는 사용할 기본 캐시를 정의합니다.

JBoss EAP 7은 다음과 같은 기본 Infinispan 캐시 컨테이너를 정의합니다.

  • Singleton 캐싱을 위한 서버
  • 세션 클러스터링을 위한 웹
  • 상태 저장 세션 빈 클러스터링을 위한 EJB
  • 엔터티 캐싱을 위한 Hibernate

예제: 기본 Infinispan 구성

<subsystem xmlns="urn:jboss:domain:infinispan:7.0">
  <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
    <transport lock-timeout="60000"/>
    <replicated-cache name="default">
      <transaction mode="BATCH"/>
    </replicated-cache>
  </cache-container>
  <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
    <transport lock-timeout="60000"/>
    <distributed-cache name="dist">
      <locking isolation="REPEATABLE_READ"/>
      <transaction mode="BATCH"/>
      <file-store/>
    </distributed-cache>
  </cache-container>
  <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
    <transport lock-timeout="60000"/>
    <distributed-cache name="dist">
      <locking isolation="REPEATABLE_READ"/>
      <transaction mode="BATCH"/>
      <file-store/>
    </distributed-cache>
  </cache-container>
  <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
    <transport lock-timeout="60000"/>
    <local-cache name="local-query">
      <object-memory size="1000"/>
      <expiration max-idle="100000"/>
    </local-cache>
    <invalidation-cache name="entity">
      <transaction mode="NON_XA"/>
      <object-memory size="1000"/>
      <expiration max-idle="100000"/>
    </invalidation-cache>
    <replicated-cache name="timestamps" mode="ASYNC"/>
  </cache-container>
</subsystem>

각 캐시 컨테이너에 정의된 기본 캐시를 확인합니다. 예를 들어 캐시 컨테이너는 dist 분산 캐시를 기본값으로 정의합니다. 따라서 웹 세션을 클러스터링할 때 dist 캐시가 사용됩니다.

기본 캐시 변경 및 추가 캐시 추가에 대한 자세한 내용은 캐시 컨테이너 구성에서 참조하십시오.

24.3.2.1. 캐시 컨테이너 구성

관리 콘솔 또는 관리 CLI를 사용하여 캐시 컨테이너 및 캐시 특성을 구성할 수 있습니다.

주의

구성의 다른 구성 요소가 이를 참조할 수 있으므로 캐시 또는 캐시 컨테이너 이름 변경을 피해야 합니다.

24.3.2.1.1. 관리 콘솔을 사용하여 캐시 구성

관리 콘솔의 Configuration(구성 ) 탭에서 Infinispan 하위 시스템으로 이동한 후 캐시 및 캐시 컨테이너를 구성할 수 있습니다. 관리형 도메인에서 구성할 적절한 프로필을 선택해야 합니다.

  • 캐시 컨테이너 추가.

    Cache Container 제목 옆에 있는 Add (+) 단추를 클릭하고 Add Cache Container (캐시 컨테이너 추가)를 선택한 다음 새 캐시 컨테이너의 설정을 입력합니다.

  • 캐시 컨테이너 설정 업데이트.

    적절한 캐시 컨테이너를 선택하고 View(보기 )를 클릭합니다. 필요에 따라 캐시 컨테이너 설정을 구성합니다.

  • 캐시 컨테이너 전송 설정 업데이트.

    적절한 캐시 컨테이너를 선택하고 View(보기 )를 클릭합니다. Transport (전송) 탭을 선택하고 필요에 따라 캐시 컨테이너 전송 설정을 구성합니다.

  • 캐시 구성.

    적절한 캐시 컨테이너를 선택하고 View(보기 )를 클릭합니다. 적절한 캐시 탭(예: 복제된 캐시 )에서 캐시를 추가, 업데이트 및 제거할 수 있습니다.

24.3.2.1.2. 관리 CLI를 사용하여 캐시 구성

관리 CLI를 사용하여 캐시 및 캐시 컨테이너를 구성할 수 있습니다. 관리형 도메인에서는 이러한 명령 앞에 /profile=PROFILE_NAME 을 사용하여 업데이트할 프로필을 지정해야 합니다.

  • 캐시 컨테이너 추가.

    /subsystem=infinispan/cache-container=CACHE_CONTAINER:add
  • 복제된 캐시 추가.

    /subsystem=infinispan/cache-container=CACHE_CONTAINER/replicated-cache=CACHE:add(mode=MODE)
  • 캐시 컨테이너의 기본 캐시 설정.

    /subsystem=infinispan/cache-container=CACHE_CONTAINER:write-attribute(name=default-cache,value=CACHE)
  • 복제된 캐시에 대한 배치 구성.

    /subsystem=infinispan/cache-container=CACHE_CONTAINER/replicated-cache=CACHE/component=transaction:write-attribute(name=mode,value=BATCH)

다음 예제에서는 동시 분산 캐시를 캐시 컨테이너에 추가하는 방법을 보여줍니다. 이 캐시 구성을 사용하면 기본 캐시의 잠금 제한 조건을 완화하여 여러 동시 요청이 동일한 웹 세션에 동시에 액세스할 수 있습니다. 이는 잠금 없이 읽기를 허용하고 배타적 잠금을 더 자주 얻을 수 있지만 더 짧은 기간 동안 이 작업을 수행합니다.

다음 관리 CLI 명령을 사용하여 동시 분산된 캐시를 캐시 컨테이너에 추가하고 기본 캐시로 설정합니다.

batch
/subsystem=infinispan/cache-container=web/distributed-cache=concurrent:add
/subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=concurrent)
/subsystem=infinispan/cache-container=web/distributed-cache=concurrent/store=file:add
run-batch

이렇게 하면 다음과 같은 서버 구성이 생성됩니다.

<cache-container name="web" default-cache="concurrent" module="org.wildfly.clustering.web.infinispan">
  ...
  <distributed-cache name="concurrent">
      <file-store/>
  </distributed-cache>
</cache-container>
24.3.2.1.3. 기본 자카르타 Enterprise Cryostat 캐시 컨테이너 변경

아래 설명된 대로 ejb3 하위 시스템에서 캐시 컨테이너를 사용할 수 있습니다.

  • Jakarta Enterprise Beans 세션 빈의 비활성화를 지원하기 위해 infinispan 하위 시스템에 정의된 ejb 캐시 컨테이너를 사용하여 세션을 저장할 수 있습니다.
  • 서버에서 클러스터형 배포에 연결하는 원격 Jakarta Enterprise Beans 클라이언트의 경우, 상호 작용하는 노드가 실패하는 경우 클러스터의 다른 노드로 페일오버할 수 있도록 이러한 클라이언트에 클러스터 토폴로지 정보를 제공해야 합니다.

비활성화 및 토폴로지 정보 프로비저닝을 지원하는 ejb 라는 기본 캐시 컨테이너의 이름을 변경하거나 변경하는 경우 아래 예제와 같이 cache -container 특성을 passivation-stores 요소클러스터 특성에 추가해야 합니다. 사용할 수 있도록 새 캐시를 추가하는 경우 이러한 변경을 수행하지 않아도 됩니다.

<subsystem xmlns="urn:jboss:domain:ejb3:5.0">
    <passivation-stores>
        <passivation-store name="infinispan" cache-container="ejb-cltest" max-size="10000"/>
    </passivation-stores>

    <remote cluster="ejb-cltest" connectors="http-remoting-connector" thread-pool-name="default"/>
</subsystem>

<subsystem xmlns="urn:jboss:domain:infinispan:7.0">
    ...
    <cache-container name="ejb-cltest" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
</subsystem>
24.3.2.1.4. Infinispan 하위 시스템에서 리소스를 Jakarta EE 애플리케이션에 삽입

@Resource 주석을 사용하여 Infinispan 하위 시스템에서 애플리케이션에 캐시와 같은 Infinispan 리소스를 삽입할 수 있습니다. 다음 예제에서는 @Resource 주석을 사용하여 Jakarta EE 애플리케이션에 캐시를 삽입하는 방법을 보여줍니다.

@Resource(lookup = "java:jboss/infinispan/cache/foo/bar")
private org.infinispan.Cache<Integer, Object> cache;

위의 예에서 foo 는 캐시 컨테이너의 이름이며 bar 는 삽입할 캐시의 이름입니다.

EAP는 삽입된 리소스의 라이프사이클을 관리합니다. 즉, 애플리케이션은 캐시 또는 캐시 관리자와 같은 해당 리소스를 관리할 필요가 없습니다.

참고

리소스를 수동으로 생성할 때 애플리케이션은 EAP가 아닌 해당 리소스를 관리합니다.

다음 예제에서는 Infinispan 하위 시스템의 다양한 리소스를 애플리케이션에 삽입하는 방법을 보여줍니다.

기본 캐시 삽입 예

Infinispan 하위 시스템의 캐시 컨테이너의 기본 캐시를 애플리케이션에 삽입하려면 다음 명령을 사용합니다.

@Resource(lookup = "java:jboss/infinispan/cache/foo/default")

임베디드 캐시 관리자 삽입 예

애플리케이션이 새 캐시 구성 및 캐시를 생성할 수 있도록 포함된 캐시 관리자를 삽입하려면 다음 명령을 사용합니다.

@Resource(lookup = "java:jboss/infinispan/container/foo")
private org.infinispan.manager.EmbeddedCacheManager manager;

캐시 구성 삽입 예

Infinispan 하위 시스템 내에 정의된 모든 캐시 구성은 애플리케이션이 해당 캐시 구성에 명시적으로 종속되지 않는 한 항상 설치하거나 사용할 수 있는 것은 아닙니다. Infinispan 하위 시스템에서 캐시 구성을 애플리케이션에 삽입하려면 @Resource 주석을 사용합니다.

  • 다음 예제에서는 @Resource 주석을 사용하여 foo 컨테이너의 캐시 구성을 삽입합니다.

    @Resource(lookup = "java:jboss/infinispan/configuration/foo/bar")
    private org.infinispan.config.Configuration config;
  • 다음 예제에서는 @Resource 주석을 사용하여 foo 컨테이너의 기본 캐시 구성을 삽입합니다.

    @Resource(lookup = "java:jboss/infinispan/configuration/foo/default")
    private org.infinispan.config.Configuration config;
24.3.2.1.5. Hibernate 캐시 컨테이너의 제거 기능

hibernate 캐시 컨테이너의 제거 기능은 메모리에서 캐시 항목을 제거합니다. 이 기능은 하위 시스템의 메모리 로드를 줄이는 데 도움이 됩니다.

size 속성은 캐시 항목을 제거하기 전에 저장할 최대 캐시 항목 수를 설정합니다.

예제: 제거 기능

  <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
    <transport lock-timeout="60000"/>
    <local-cache name="local-query">
      <object-memory size="1000"/>
      <expiration max-idle="100000"/>

제거는 메모리 내에서만 수행됩니다. 캐시 저장소에는 정보가 영구적으로 손실되지 않도록 제거된 캐시 항목이 있습니다. 제거 기능에 대한 자세한 내용은 Infinispan 사용자 가이드 의 제거 및 데이터 컨테이너 섹션을 참조하십시오.

24.3.2.1.6. Hibernate 캐시 컨테이너의 만료 기능

vGPU 캐시 컨테이너 의 만료 기능은 클러스터형 작업입니다. 따라서 클러스터형 캐시를 사용하면 모든 클러스터 멤버에서 만료된 캐시 항목이 제거됩니다. 자세한 내용은 rhcos 사용자 가이드의 Expiration 섹션을 참조하십시오.

24.3.3. 클러스터링 모드

Infinispan을 사용하여 JBoss EAP의 두 가지 방법으로 클러스터링을 구성할 수 있습니다. 애플리케이션에 가장 적합한 방법은 요구 사항에 따라 달라집니다. 각 모드에 따라 가용성, 일관성, 안정성 및 확장성 사이에는 장단점이 있습니다. 클러스터링 모드를 선택하기 전에 네트워크의 가장 중요한 기능을 확인하고 해당 요구 사항의 균형을 조정해야 합니다.

캐시 모드
복제
복제 모드는 클러스터에 새 인스턴스를 자동으로 감지하고 추가합니다. 이러한 인스턴스의 변경 사항은 클러스터의 모든 노드에 복제됩니다. 복제 모드는 네트워크를 통해 복제해야 하는 정보의 양 때문에 일반적으로 소규모 클러스터에서 가장 효과적입니다. Infinispan은 네트워크 트래픽 정체를 어느 정도 완화하는 UDP 멀티캐스트를 사용하도록 구성할 수 있습니다.
콘텐츠 배포

배포 모드를 사용하면 Infinispan에서 클러스터를 선형으로 확장할 수 있습니다. 배포 모드에서는 일관된 해시 알고리즘을 사용하여 클러스터에서 새 노드를 배치해야 하는 위치를 결정합니다. 보관할 정보의 복사본 또는 소유자 수는 구성할 수 있습니다. 유지된 복사본 수, 데이터의 지속성 및 성능 사이에는 장단점이 있습니다. 유지되는 복사본이 많을수록 성능에 미치는 영향은 높지만 서버 장애 발생 시 데이터 손실이 줄어듭니다. 또한 해시 알고리즘은 멀티캐스팅 또는 메타데이터를 저장하지 않고 항목을 찾아 네트워크 트래픽을 줄이는 데 사용됩니다.

클러스터 크기가 6-8개의 노드를 초과할 때 배포 모드를 캐싱 전략으로 사용해야 합니다. 배포 모드를 사용하면 모든 노드가 아닌 클러스터 내의 노드 하위 집합에만 데이터가 배포됩니다.

분산됨

분산 모드는 일관된 해시 알고리즘을 사용하여 소유권을 결정한다는 점에서 배포 모드와 유사합니다. 그러나 소유권은 두 개의 구성원으로 제한되며, 시작자 또는 지정된 세션에 대한 요청을 수신하는 노드는 항상 잠금 및 캐시 항목 업데이트를 조정하는 데 대한 소유권을 가정합니다. 분산 모드에 사용된 캐시 쓰기 알고리즘은 쓰기 작업으로 인해 두 소유자가 있는 배포 캐시가 두 개의 RPC 호출을 사용할 수 있는 단일 RPC 호출만 발생하도록 보장합니다. 로드 밸런서 장애 조치(failover)는 기본이 아닌 소유자 또는 백업 노드로 트래픽을 전달하는 경향이 있기 때문에 분산 웹 세션에 유용할 수 있습니다. 이를 통해 클러스터 토폴로지 변경 후 경합을 잠재적으로 줄이고 성능을 향상시킬 수 있습니다.

분산 모드는 트랜잭션 또는 L1 캐싱을 지원하지 않습니다. 그러나 이 명령은 편향된 읽기를 지원하므로, 지정된 항목에 대한 캐시 쓰기를 시작하여 일관된 해시에 따라 소유자가 아니지만 일부 기간 동안 해당 항목에 대한 읽기를 계속할 수 있습니다. L1 캐싱과 유사하지만 편향된 읽기 특성과 L1 캐싱의 구성 특성은 별개입니다.

동기 및 비동기 복제

복제는 동기 또는 비동기 모드에서 수행할 수 있으며 선택한 모드는 요구 사항과 애플리케이션에 따라 달라집니다.

중요

JBoss EAP 7.1 이후부터는 세션 복제에 항상 동기(SYNC) 캐시 모드를 사용해야 합니다. 또한 SYNC 가 기본 캐시 모드입니다. 세션 복제 및 적절한 캐시 모드에 대한 자세한 내용은 EAP에 대한 세션 복제를 구성하고 조정하는 방법을 참조하십시오.

동기 복제
동기 복제를 사용하면 복제 프로세스가 사용자 요청을 처리하는 동일한 스레드에서 실행됩니다. 세션 복제는 완료된 응답이 클라이언트로 다시 전송되고 복제가 완료된 후에만 스레드가 릴리스된 후에 시작됩니다. 동기 복제는 클러스터의 각 노드에서 응답해야 하므로 네트워크 트래픽에 영향을 미칩니다. 그러나 클러스터의 모든 노드에 모든 수정 사항이 적용되었는지 확인하는 이점이 있습니다.
비동기 복제
비동기 복제의 경우 Infinispan은 스레드 풀을 사용하여 백그라운드에서 복제를 수행합니다. 발신자는 클러스터의 다른 노드에서 응답을 기다리지 않습니다. 그러나 캐시는 오래된 데이터를 읽지 않도록 이전 복제가 완료될 때까지 차단됩니다. 복제는 한 번에 또는 대기열 크기로 트리거됩니다. 실패한 복제 시도는 로그에 기록되며 실시간으로 알림을 받지 않습니다.

24.3.3.1. 캐시 모드 설정

관리 CLI를 사용하여 기본 캐시를 변경할 수 있습니다.

참고

이 섹션에서는 기본적으로 배포 모드인 웹 세션 캐시 구성과 관련된 지침을 보여줍니다. 단계 및 관리 CLI 명령은 다른 캐시 컨테이너에 적용하도록 쉽게 조정할 수 있습니다.

복제 캐시 모드로 변경

웹 세션 캐시에 대한 기본 JBoss EAP 7 구성에는 repl 복제 캐시가 포함되지 않습니다. 이 캐시를 먼저 추가해야 합니다.

참고

아래 관리 CLI 명령은 독립 실행형 서버용입니다. 관리형 도메인에서 실행하는 경우 / profile=PROFILE_NAME 을 사용하여 /subsystem=infinispan 명령 앞에 업데이트할 프로필을 지정해야 합니다.

  1. repl 복제 캐시를 추가하고 기본 캐시로 설정합니다.

    batch
    /subsystem=infinispan/cache-container=web/replicated-cache=repl:add()
    /subsystem=infinispan/cache-container=web/replicated-cache=repl/component=transaction:add(mode=BATCH)
    /subsystem=infinispan/cache-container=web/replicated-cache=repl/component=locking:add(isolation=REPEATABLE_READ)
    /subsystem=infinispan/cache-container=web/replicated-cache=repl/store=file:add
    /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=repl)
    run-batch
  2. 서버를 다시 로드합니다.

    reload
분산 캐시 모드로 변경

웹 세션 캐시에 대한 기본 JBoss EAP 7 구성에는 이미 dist 배포 캐시가 포함되어 있습니다.

참고

아래 관리 CLI 명령은 독립 실행형 서버용입니다. 관리형 도메인에서 실행하는 경우 / profile=PROFILE_NAME 을 사용하여 /subsystem=infinispan 명령 앞에 업데이트할 프로필을 지정해야 합니다.

  1. 기본 캐시를 dist 배포 캐시로 변경합니다.

    /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=dist)
  2. 배포 캐시의 소유자 수를 설정합니다. 다음 명령은 5 개의 소유자를 설정합니다. 기본값은 2 입니다.

    /subsystem=infinispan/cache-container=web/distributed-cache=dist:write-attribute(name=owners,value=5)
  3. 서버를 다시 로드합니다.

    reload
분산된 캐시 모드로 변경

웹 세션 캐시에 대한 기본 JBoss EAP 구성에는 scattered-cache 가 포함되지 않습니다. 아래 예제에서는 분산된 캐시를 추가하고 기본 캐시로 설정하는 관리 CLI 명령을 보여줍니다.

참고

아래 관리 CLI 명령은 HA 프로필을 사용하는 독립 실행형 서버용입니다. 관리형 도메인에서 실행하는 경우 / profile=PROFILE_NAME 을 사용하여 /subsystem=infinispan 명령 앞에 업데이트할 프로필을 지정해야 합니다.

  1. 기본 웹 세션 시간 제한 값인 30분과 동일한 읽기 바이어스 수명이 있는 분산된 캐시를 만듭니다.

    /subsystem=infinispan/cache-container=web/scattered-cache=scattered:add(bias-lifespan=1800000)
  2. 기본 캐시로 분산을 설정합니다.

    /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=scattered)

이렇게 하면 다음과 같은 서버 구성이 생성됩니다.

<cache-container name="web" default-cache="scattered" module="org.wildfly.clustering.web.infinispan">
    ...
    <scattered-cache name="scattered" bias-lifespan="1800000"/>
    ...
</cache-container>

24.3.3.2. 캐시 전략 성능

SYNC 캐싱 전략을 사용하면 복제가 완료될 때까지 요청이 완료되지 않으므로 복제 비용을 쉽게 측정하고 응답 시간에 직접 확인할 수 있습니다.

ASYNC 캐싱 전략으로 인해 SYNC 캐싱 전략보다 응답 시간이 짧아야 하지만 이는 올바른 조건에서만 적용됩니다. ASYNC 캐싱 전략은 측정하기가 더 어렵습니다. 그러나 요청 간 기간이 캐시 작업을 완료할 수 있을 만큼 충분한 경우 SYNC 전략보다 더 나은 성능을 제공할 수 있습니다. 이는 복제 비용이 응답 시간에 즉시 표시되지 않기 때문입니다.

동일한 세션에 대한 요청이 너무 빨리 생성되면 이전 요청의 복제 비용이 이전 요청의 복제가 완료될 때까지 기다려야 하므로 후속 요청의 앞부분으로 전환됩니다. 응답이 수신된 직후 후속 요청이 전송되는 빠른 실행 요청의 경우 ASYNC 캐싱 전략이 SYNC 캐싱 전략보다 성능이 저하됩니다. 결과적으로 SYNC 캐싱 전략이 ASYNC 캐싱 전략보다 실제로 더 나은 성능을 수행하는 동일한 세션의 요청 간 기간 동안 임계값이 있습니다. 실제 사용 환경에서는 동일한 세션에 대한 요청이 일반적으로 빠른 연속으로 수신되지 않습니다. 대신 일반적으로 요청 사이에는 몇 초 이상의 순서로 기간이 있습니다. 이 경우 ASYNC 캐싱 전략은 적절한 기본값이며 가장 빠른 응답 시간을 제공합니다.

24.3.4. 시/도 (State Transfer)

상태 전송은 기본 데이터 그리드와 클러스터형 캐시 기능입니다. 상태 전송이 없으면 노드가 클러스터에 추가되거나 제거되므로 데이터가 손실됩니다.

상태 전송은 캐시 멤버십 변경에 대한 응답으로 캐시의 내부 상태를 조정합니다. 이 변경은 노드가 클러스터에 참여하거나 나가는 경우 두 개 이상의 클러스터 파티션이 병합되거나 이러한 이벤트를 조합한 후에 자동으로 발생합니다. 아래에 설명된 대로 새 캐시에서 최대 상태의 상태를 수신해야 하므로 새로 시작한 캐시의 초기 상태 전송이 가장 비용이 높습니다.

timeout 속성을 사용하여 새로 시작된 캐시가 상태를 수신 대기하는 기간을 제어할 수 있습니다. 시간 초과 특성이 양수인 경우 캐시는 서비스 요청에 사용할 수 있도록 모든 초기 상태를 수신하도록 기다립니다. 지정된 시간 내에 상태 전송이 완료되지 않으면 기본값은 240000 밀리초이며 캐시에서 오류가 발생하고 시작을 취소합니다. 시간 초과0 으로 설정되면 캐시를 즉시 사용할 수 있으며 백그라운드 작업 중에 초기 상태가 수신됩니다. 초기 상태 전송이 완료될 때까지 캐시가 아직 수신되지 않은 캐시 항목에 대한 모든 요청을 원격 노드에서 가져와야 합니다.

다음 명령을 사용하여 timeout 특성을 0 으로 설정할 수 있습니다.

/subsystem=infinispan/cache-container=server/CACHE_TYPE=CACHE/component=state-transfer:write-attribute(name=timeout,value=0)

상태 전송 동작은 캐시 모드에 따라 결정됩니다.

  • 복제 모드에서는 캐시에 가입하는 새 노드가 기존 노드에서 전체 캐시 상태를 수신합니다. 노드가 클러스터를 벗어나면 상태 전송이 없습니다.
  • 배포 모드에서 새 노드는 기존 노드에서 상태의 일부만 수신하고, 일관된 해시를 통해 확인된 대로 기존 노드는 일부 해당 상태를 캐시에 저장하여 캐시에 각 키의 복사본 을 유지합니다. 노드가 클러스터를 벗어나면 배포 캐시에서 각 키의 소유자가 계속 존재하도록 해당 노드에 저장된 키의 추가 복사본을 만들어야 합니다.
  • 무효화 모드에서 초기 상태 전송은 복제 모드와 유사하며, 유일한 차이점은 노드의 상태가 동일한 것으로 보장되지 않는다는 점입니다. 노드가 클러스터를 벗어나면 상태 전송이 없습니다.

상태 전송은 기본적으로 메모리 내 및 영구 상태를 모두 전송하지만 구성에서 둘 다 비활성화할 수 있습니다. 상태 전송이 비활성화되면 ClusterLoader 를 구성해야 합니다. 그렇지 않으면 데이터가 캐시에 로드되지 않고 노드가 키의 소유자 또는 백업 소유자가 됩니다. 또한 배포 모드에서 상태 전송이 비활성화된 경우 키에 캐시에 소유자 사본보다 적은 경우가 있습니다.

24.3.5. Infinispan 스레드 풀 구성

infinispan 하위 시스템에는 async-operations,expiration,listener,persistence,remote-command,state-transfertransport 스레드 풀이 포함되어 있습니다. 이러한 풀은 Infinispan 캐시 컨테이너에 대해 구성할 수 있습니다.

다음 표에는 infinispan 하위 시스템의 각 스레드 풀에 대해 구성할 수 있는 속성과 각각의 기본값이 나열되어 있습니다.

스레드 풀 이름keepalive-timemax-threadsmin-threadsqueue-length

async-operations

60000L

25

25

1000

만료

60000L

1

해당 없음

해당 없음

리스너

60000L

1

1

100000

지속성

60000L

4

1

0

remote-command

60000L

200

1

0

state-transfer

60000L

60

1

0

전송

60000L

25

25

100000

다음 구문을 사용하여 관리 CLI를 사용하여 Infinispan 스레드 풀을 구성합니다.

/subsystem=infinispan/cache-container=CACHE_CONTAINER_NAME/thread-pool=THREAD_POOL_NAME:write-attribute(name=ATTRIBUTE_NAME, value=ATTRIBUTE_VALUE)

다음은 서버 캐시 컨테이너의 지속성 스레드 풀에서 max-threads 값을 10 으로 설정하는 관리 CLI 명령의 예입니다.

/subsystem=infinispan/cache-container=server/thread-pool=persistence:write-attribute(name="max-threads", value="10")

24.3.6. Infinispan 통계

Infinispan 캐시 및 캐시 컨테이너에 대한 런타임 통계는 모니터링 목적으로 활성화할 수 있습니다. 통계 수집은 성능상의 이유로 기본적으로 활성화되어 있지 않습니다.

통계 수집은 각 캐시 컨테이너, 캐시 또는 둘 다에 대해 활성화할 수 있습니다. 각 캐시의 statistics 옵션은 캐시 컨테이너의 옵션을 덮어씁니다. 캐시 컨테이너에 대한 통계 컬렉션을 활성화하거나 비활성화하면 자체를 명시적으로 지정하지 않는 한 해당 컨테이너의 모든 캐시가 설정을 상속합니다.

24.3.6.1. Infinispan 통계 활성화

주의

Infinispan 통계를 활성화하면 infinispan 하위 시스템의 성능에 부정적인 영향을 줄 수 있습니다. 통계는 필요한 경우에만 활성화해야 합니다.

관리 콘솔 또는 관리 CLI를 사용하여 Infinispan 통계 컬렉션을 활성화하거나 비활성화할 수 있습니다. 관리 콘솔의 Configuration (구성) 탭에서 Infinispan 하위 시스템으로 이동하고 적절한 캐시 또는 캐시 컨테이너를 선택하고 Statistics Enabled 특성을 편집합니다. 관리 CLI를 사용하여 통계를 활성화하려면 아래 명령을 사용합니다.

캐시 컨테이너에 대한 통계 컬렉션을 활성화합니다. 서버를 다시 로드해야 합니다.

/subsystem=infinispan/cache-container=CACHE_CONTAINER:write-attribute(name=statistics-enabled,value=true)

캐시에 대한 통계 컬렉션을 활성화합니다. 서버를 다시 로드해야 합니다.

/subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:write-attribute(name=statistics-enabled,value=true)
참고

다음 명령을 사용하여 캐시 컨테이너의 statistics-enabled 속성 설정을 상속받도록 캐시의 statistics-enabled 특성을 정의할 수 있습니다.

/subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:undefine-attribute(name=statistics-enabled)

24.3.7. Infinispan 파티션 처리

Infinispan 클러스터는 데이터가 저장된 여러 노드에서 빌드됩니다. 여러 노드가 실패하는 경우 데이터 손실을 방지하기 위해 Infinispan은 여러 노드에 동일한 데이터를 복사합니다. 이 수준의 데이터 중복은 owner 특성을 사용하여 구성됩니다. 구성된 노드 수만큼 동시에 충돌하는 경우 Infinispan에 사용 가능한 데이터의 복사본이 있습니다.

그러나 클러스터에서 너무 많은 노드가 사라질 때 발생할 수 있는 치명적인 상황이 있습니다.

줄 바꿈

이렇게 하면 클러스터를 개별적으로 작동하는 두 개 이상의 파티션 또는 하위 클러스터로 나뉩니다. 이러한 상황에서 다양한 파티션에서 읽고 쓰는 여러 클라이언트는 동일한 캐시 항목의 다른 버전을 확인할 수 있습니다. 이 버전의 경우 여러 애플리케이션에 문제가 있습니다.

참고

중복 네트워크 또는 IP 본딩 과 같이 분할 브레이가 발생할 가능성을 완화할 수 있는 방법은 있지만, 이러한 경우 문제가 발생하는 시간만 줄일 수 있습니다.

여러 노드가 순서대로 충돌
여러 노드, 특히 소유자 수와 Infinispan의 충돌이 충돌 간에 해당 상태를 적절하게 재조정할 수 없는 경우 결과적으로 부분적인 데이터 손실이 발생합니다.

목표는 스플릿 블록 또는 여러 노드가 빠르게 충돌하여 잘못된 데이터가 사용자에게 반환되는 상황을 방지하는 것입니다.

24.3.7.1. 브라질 분할

분할 된 경우 각 네트워크 파티션은 고유한 JGroups 보기를 설치하여 다른 파티션에서 노드를 제거합니다. 파티션이 서로 인식하지 못하므로 클러스터가 두 개 이상의 파티션으로 분할되었는지를 직접 확인할 수 없습니다. 대신 명시적인 종료 메시지를 보내지 않고 하나 이상의 노드가 JGroups 클러스터에서 사라질 때 클러스터가 분산되었다고 가정합니다.

파티션 처리가 비활성화되면 이러한 각 파티션이 독립 클러스터로 계속 작동합니다. 각 파티션은 데이터의 일부만 볼 수 있으며 각 파티션은 캐시에 충돌하는 업데이트를 쓸 수 있습니다.

파티션 처리가 활성화되면 분할을 감지하면 각 파티션이 즉시 리밸런싱을 시작하지 않고 먼저 성능이 저하된 모드로 전환해야 하는지 여부를 확인합니다.

  • 하나 이상의 세그먼트가 모든 소유자를 손실한 경우 마지막 리밸런스 이후 지정된 소유자 수가 남아 있으면 파티션이 성능이 저하된 모드로 전환됩니다.
  • 파티션에 안정적인 최신 토폴로지 에 대다수의 노드(floor(numNodes/2) + 1)가 포함되어 있지 않은 경우 파티션은 성능이 저하된 모드로 전환됩니다.
  • 그렇지 않으면 파티션이 정상적으로 작동하고 리밸런싱을 시작합니다.

리밸런스 작업이 종료될 때마다 안정적인 토폴로지 가 업데이트되고 코디네이터는 다른 리밸런스가 필요하지 않음을 결정합니다. 이러한 규칙은 최대 한 개의 파티션이 사용 가능한 모드로 유지되고 다른 파티션이 성능이 저하된 모드로 전환되도록 합니다.

파티션이 성능 저하 모드인 경우 완전히 소유한 키에만 액세스할 수 있습니다.

  • 이 파티션 내의 노드에서 모든 복사본이 있는 항목에 대한 요청(읽기 및 쓰기)이 적용됩니다.
  • 사라진 노드에서 일부 또는 완전히 소유한 항목 요청은 AvailabilityException 과 함께 거부됩니다.

이렇게 하면 파티션이 동일한 키(캐시가 일관됨)에 대해 다른 값을 쓸 수 없으며 한 개의 파티션은 다른 파티션에서 업데이트된 키를 읽을 수 없습니다(고급 데이터 없음).

참고

두 개의 파티션이 격리될 수 있으며 병합되지 않는 한 일관되지 않은 데이터를 읽고 쓸 수 있습니다. 나중에 사용자 정의 가용성 전략(예: 특정 노드가 클러스터의 일부인지 확인) 해당 상황을 처리할 수 있는 외부 시스템에 액세스할 수 있는지 확인할 수 있습니다.

24.3.7.2. 파티션 처리 구성

현재 파티션 처리는 기본적으로 비활성화되어 있습니다. 다음 관리 CLI 명령을 사용하여 파티션 처리를 활성화합니다.

/subsystem=infinispan/cache-container=web/distributed-cache=dist/component=partition-handling:write-attribute(name=enabled, value=true)

24.3.8. 원격 캐시 컨테이너 구성

관리형 도메인의 모든 서버 그룹에 대해 원격 캐시를 구성해야 합니다. 지정된 remote-cache-container에 대한 지표 컬렉션을 활성화하고 statistics- enabled 특성과 연결된 런타임 캐시를 활성화할 수 있습니다.

24.3.8.1. 원격 캐시 컨테이너 생성

관리형 도메인의 각 서버 그룹에는 고유한 원격 캐시가 필요합니다. 캐시는 동일한 데이터 그리드에 속할 수 있습니다. 따라서 사용자는 서버 그룹에 대한 소켓 바인딩을 정의하고 소켓 바인딩을 원격 캐시 컨테이너와 연결하여 모든 서버 그룹에 대해 원격 캐시를 구성해야 합니다.

절차

  1. socket-binding 을 정의하여 클러스터에서 각 원격 Red Hat Data Grid 인스턴스에 필요에 따라 명령을 반복합니다.

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=SOCKET_BINDING:add(host=HOSTNAME,port=PORT)
  2. 새로 생성된 소켓 바인딩을 참조하는 remote-cache-container 를 정의합니다.

    batch
    /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER:add(default-remote-cluster=data-grid-cluster)
    /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER/remote-cluster=data-grid-cluster:add(socket-bindings=[SOCKET_BINDING,SOCKET_BINDING_2,...])
    run-batch

24.3.8.2. 원격 캐시 컨테이너의 통계 활성화

statistics-enabled 특성은 지정된 remote-cache-container 및 관련 런타임 캐시에 대한 메트릭 컬렉션을 활성화합니다.

  • "foo"라는 remote-cache-container 의 경우 다음 작업을 사용하여 통계를 활성화합니다.
/subsystem=infinispan/remote-cache-container=foo:write-attribute(name=statistics-enabled, value=true)
  • remote-cache-container "foo"의 경우 다음 메트릭이 런타임에 표시됩니다.
/subsystem=infinispan/remote-cache-container=foo:read-attribute(name=connections)
/subsystem=infinispan/remote-cache-container=foo:read-attribute(name=active-connections)
/subsystem=infinispan/remote-cache-container=foo:read-attribute(name=idle-connections)
  • 이러한 메트릭에 대한 설명은 remote- cache-container에 대해 read-resource- description 작업을 실행합니다.
/subsystem=infinispan/remote-cache-container=foo:read-resource-description
  • 다음 메트릭은 선택한 배포에서 사용하는 원격 캐시에 고유합니다.
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:read-resource(include-runtime=true, recursive=true)
{
    "average-read-time" : 1,
    "average-remove-time" : 0,
    "average-write-time" : 2,
    "hits" : 9,
    "misses" : 0,
    "near-cache-hits" : 7,
    "near-cache-invalidations" : 8,
    "near-cache-misses" : 9,
    "near-cache-size" : 1,
    "removes" : 0,
    "time-since-reset" : 82344,
    "writes" : 8
}
  • 이러한 메트릭에 대한 설명은 원격 캐시에 대해 read-resource-description 작업을 실행합니다.
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:read-resource-description
  • 이러한 지표 중 일부는 계산된 값(예: average-*)이며 다른 지표는 적중 및 누락과 같은 희미한 상태입니다. 강력한 메트릭은 다음 작업으로 재설정할 수 있습니다.
/subsystem=infinispan/remote-cache-container=foo/remote-cache=bar.war:reset-statistics()

24.3.9. HTTP 세션을 Red Hat Data Grid로 외부화

참고

이 기능을 사용하려면 Red Hat Data Grid 서브스크립션이 필요합니다.

Red Hat Data Grid는 HTTP 세션과 같이 JBoss EAP의 애플리케이션별 데이터를 위한 외부 캐시 컨테이너로 사용할 수 있습니다. 이를 통해 애플리케이션과는 별도로 데이터 계층을 확장할 수 있으며 다양한 도메인에 있을 수 있는 다양한 JBoss EAP 클러스터가 동일한 Red Hat Data Grid 클러스터에서 데이터에 액세스할 수 있습니다. 또한 다른 애플리케이션은 Red Hat Data Grid에서 제공하는 캐시와 상호 작용할 수 있습니다.

다음 예제에서는 HTTP 세션을 외부화하는 방법을 보여줍니다. JBoss EAP의 독립 실행형 인스턴스와 관리형 도메인 모두에 적용됩니다.

  1. remote-cache-container 를 생성합니다. 자세한 내용은 원격 캐시 컨테이너 구성을 참조하십시오.
  2. HotRod 저장소 구성. HotRod 저장소는 JBoss EAP 서버에서 생성한 각 캐시에 대해 하나의 전용 원격 캐시를 사용합니다. 일반적으로 아래 CLI 스크립트에 표시된 대로 JBoss EAP 서버에서 한 개의 무효화 캐시가 사용됩니다.

    참고

    원격 캐시는 Red Hat Data Grid 서버에서 수동으로 구성해야 합니다. 이러한 캐시에 권장되는 구성은 비관적 잠금을 사용하는 트랜잭션 배포 모드 캐시입니다. 캐시 이름은 test.war 와 같은 배포 파일 이름에 해당해야 합니다.

    원격 캐시 컨테이너를 구성하고 나면 기존 저장소를 교체하도록 핫로드 저장소를 구성할 수 있습니다. 다음 CLI 스크립트는 무효화 캐시와 함께 세션을 오프로딩하는 일반적인 사용 사례를 보여줍니다.

    batch
    /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME:add()
    /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/store=hotrod:add(remote-cache-container=CACHE_CONTAINER,fetch-state=false,purge=false,passivation=false,shared=true)
    /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/component=transaction:add(mode=BATCH)
    /subsystem=infinispan/cache-container=web/invalidation-cache=CACHE_NAME/component=locking:add(isolation=REPEATABLE_READ)
    /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache,value=CACHE_NAME)
    run-batch

    스크립트는 새로운 무효화 캐시를 구성합니다. 그런 다음 세션 데이터가 성능을 위해 캐시에서 유지 관리하고 복원력을 위해 저장소에 기록됩니다.

    HotRod 클라이언트는 @Resource 주석을 사용하여 Jakarta EE 애플리케이션에 직접 주입할 수 있습니다. 아래 예제에서 @Resource 주석은 hotrod-client.properties 파일에서 클래스 경로에서 구성 속성을 조회합니다.

    @Resource(lookup = "java:jboss/infinispan/remote-container/web-sessions")
    private org.infinispan.client.hotrod.RemoteCacheContainer client;

    예: hotrod-client.properties 파일

    infinispan.client.hotrod.transport_factory = org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory
    infinispan.client.hotrod.server_list = 127.0.0.1:11222
    infinispan.client.hotrod.marshaller = org.infinispan.commons.marshall.jboss.GenericJBossMarshaller
    infinispan.client.hotrod.async_executor_factory = org.infinispan.client.hotrod.impl.async.DefaultAsyncExecutorFactory
    infinispan.client.hotrod.default_executor_factory.pool_size = 1
    infinispan.client.hotrod.default_executor_factory.queue_size = 10000
    infinispan.client.hotrod.hash_function_impl.1 = org.infinispan.client.hotrod.impl.consistenthash.ConsistentHashV1
    infinispan.client.hotrod.tcp_no_delay = true
    infinispan.client.hotrod.ping_on_startup = true
    infinispan.client.hotrod.request_balancing_strategy = org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy
    infinispan.client.hotrod.key_size_estimate = 64
    infinispan.client.hotrod.value_size_estimate = 512
    infinispan.client.hotrod.force_return_values = false
    
    ## below is connection pooling config
    
    maxActive=-1
    maxTotal = -1
    maxIdle = -1
    whenExhaustedAction = 1
    timeBetweenEvictionRunsMillis=120000
    minEvictableIdleTimeMillis=300000
    testWhileIdle = true
    minIdle = 1

원격 캐시 컨테이너 보안

SSL을 사용하여 원격 Red Hat Data Grid 인스턴스와의 통신을 보호할 수 있습니다. 이 작업은 JBoss EAP 인스턴스에서 remote-cache-container 를 구성하고 활성 보안 영역을 사용하도록 Red Hat Data Grid 인스턴스의 hotrod 커넥터를 조정하여 수행됩니다.

  1. JBoss EAP에서 클라이언트-ssl-context 를 만듭니다. 다른 elytron 구성 요소 생성을 포함한 클라이언트-ssl-context 생성에 대한 자세한 내용은 How to Configure Server Security for JBoss EAP에서 client-ssl-context 사용을 참조하십시오.

    /subsystem=elytron/client-ssl-context=CLIENT_SSL_CONTEXT:add(key-manager=KEY_MANAGER,trust-manager=TRUST_MANAGER)
  2. 클라이언트 SSL 컨텍스트를 사용하도록 원격 캐시 컨테이너를 구성합니다.

    /subsystem=infinispan/remote-cache-container=CACHE_CONTAINER/component=security:write-attribute(name=ssl-context,value=CLIENT_SSL_CONTEXT)
  3. 각 인스턴스에 대해 필요에 따라 반복하여 원격 Red Hat Data Grid 인스턴스를 보호합니다.

    1. client-ssl-context 에 사용된 키 저장소를 원격 Red Hat Data Grid 인스턴스에 복사합니다.
    2. 이 키 저장소를 사용하도록 ApplicationRealm 을 구성합니다.

      /core-service=management/security-realm=ApplicationRealm/server-identity=ssl:add(keystore-path="KEYSTORE_NAME",keystore-relative-to="jboss.server.config.dir",keystore-password="KEYSTORE_PASSWORD")
    3. 이 보안 영역을 가리키도록 hotrod 커넥터를 조정합니다.

      /subsystem=datagrid-infinispan-endpoint/hotrod-connector=hotrod-connector/encryption=ENCRYPTION:add(require-ssl-client-auth=false,security-realm="ApplicationRealm")
    4. 원격 Red Hat Data Grid 인스턴스를 다시 로드합니다.

      reload

24.3.10. 원격 저장소를 사용하여 HTTP 세션을 Red Hat Data Grid로 외부화

참고

이 기능을 사용하려면 Red Hat Data Grid 서브스크립션이 필요합니다.

이 지침은 이전의 세션을 외부화하는 방법을 나타냅니다. JBoss EAP 7.2는 elytron 하위 시스템과 통합된 HotRod 프로토콜을 기반으로 사용자 지정 최적화된 캐시 저장소를 도입했습니다. HTTP 세션을 Red Hat Data Grid로 외부화하는 방법에 설명된 대로 새로운 핫로드 저장소를 사용하는 것이 좋습니다.

참고

배포 가능한 각 애플리케이션에 대해 완전히 새 캐시를 생성해야 합니다. 기존 캐시 컨테이너(예: web )에 생성할 수 있습니다.

HTTP 세션을 외부화하려면 다음을 수행합니다.

  1. socket-binding-group 에 네트워킹 정보를 추가하여 원격 Red Hat Data Grid 서버의 위치를 정의합니다.

    예제: 원격 소켓 바인딩 추가

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-rhdg-server1:add(host=RHDGHostName1, port=11222)
    
    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-rhdg-server2:add(host=RHDGHostName2, port=11222)

    결과 XML

    <socket-binding-group name="standard-sockets" ... >
      ...
      <outbound-socket-binding name="remote-rhdg-server1">
        <remote-destination host="RHDGHostName1" port="11222"/>
      </outbound-socket-binding>
      <outbound-socket-binding name="remote-rhdg-server2">
        <remote-destination host="RHDGHostName2" port="11222"/>
      </outbound-socket-binding>
    </socket-binding-group>

    참고

    각 Red Hat Data Grid 서버에 대해 구성된 원격 소켓 바인딩이 필요합니다.

  2. 원격 캐시 컨테이너가 JBoss EAP의 infinispan 하위 시스템에 정의되어 있는지 확인합니다. 아래 예에서 remote-store 요소의 cache 속성은 원격 Red Hat Data Grid 서버에서 캐시 이름을 정의합니다.

    관리형 도메인에서 실행 중인 경우 해당 명령 앞에 /profile=PROFILE_NAME을 추가합니다.

    예제: 원격 캐시 컨테이너 추가

    /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg:add(mode=SYNC)
    
    /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/component=locking:write-attribute(name=isolation,value=REPEATABLE_READ)
    
    /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/component=transaction:write-attribute(name=mode,value=BATCH)
    
    /subsystem=infinispan/cache-container=web/invalidation-cache=rhdg/store=remote:add(remote-servers=["remote-rhdg-server1","remote-rhdg-server2"], cache=default, socket-timeout=60000, passivation=false, purge=false, shared=true)

    결과 XML

    <subsystem xmlns="urn:jboss:domain:infinispan:7.0">
      ...
      <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan" statistics-enabled="true">
        <transport lock-timeout="60000"/>
        <invalidation-cache name="rhdg" mode="SYNC">
          <locking isolation="REPEATABLE_READ"/>
          <transaction mode="BATCH"/>
          <remote-store cache="default" socket-timeout="60000" remote-servers="remote-rhdg-server1 remote-rhdg-server2" passivation="false" purge="false" shared="true"/>
        </invalidation-cache>
        ...
      </cache-container>
    </subsystem>

  3. 애플리케이션 jboss-web.xml 파일에 캐시 정보를 추가합니다. 다음 예제에서 web 은 캐시 컨테이너의 이름이고 rhdg 는 이 컨테이너에 있는 적절한 캐시의 이름입니다.

    예: jboss-web.xml 파일

    <?xml version="1.0" encoding="UTF-8"?>
    <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd"
               version="10.0">
        <replication-config>
            <replication-granularity>SESSION</replication-granularity>
            <cache-name>web.rhdg</cache-name>
        </replication-config>
    </jboss-web>