24.2. JGroups와의 클러스터 통신

24.2.1. JGroups 정보

JGroups는 안정적인 메시징을 위한 툴킷이며 노드가 서로 메시지를 보낼 수 있는 클러스터를 생성하는 데 사용할 수 있습니다.

jgroups 하위 시스템은 JBoss EAP에서 고가용성 서비스에 대한 그룹 통신 지원을 제공합니다. 채널에 대한 런타임 통계를 볼 뿐만 아니라 명명된 채널 및 프로토콜 스택을 구성할 수 있습니다. jgroups 하위 시스템은 관리형 도메인에서 ha 또는 full-ha 프로필과 같은 고가용성 기능을 제공하는 구성을 사용하거나 독립 실행형 서버에 standalone -ha.xml 또는 standalone- full-ha.xml 구성 파일을 사용할 때 사용할 수 있습니다.

JBoss EAP는 두 개의 JGroups 스택으로 사전 구성되어 있습니다.

udp
클러스터의 노드는 UDP(User Datagram Protocol) 멀티캐스팅을 사용하여 서로 통신합니다. 기본 스택입니다.
tcp
클러스터의 노드는 TCP(Transmission Control Protocol)를 사용하여 서로 통신합니다.
참고

TCP는 오버헤드가 많으며 오류 검사, 패킷 순서 지정 및 혼잡 제어 자체를 처리하므로 UDP보다 더 느리게 간주됩니다. JGroups는 UDP에 대해 이러한 기능을 처리하는 반면 TCP는 자체적으로 보장합니다. TCP는 불안정하거나 높은 혼잡 네트워크에서 JGroups를 사용하거나 멀티캐스트를 사용할 수 없는 경우 좋은 선택입니다.

미리 구성된 스택을 사용하거나 시스템의 특정 요구 사항에 맞게 자체를 정의할 수 있습니다. 사용 가능한 프로토콜 및 해당 속성에 대한 자세한 내용은 다음 섹션을 참조하십시오.

24.2.2. 기본 NotReady 채널을 TCP를 사용하도록 전환

기본적으로 클러스터 노드는 ee#150 채널에 대해 구성된 udp 프로토콜 스택을 사용하여 통신합니다.

<channels default="ee">
  <channel name="ee" stack="udp"/>
</channels>
<stacks>
  <stack name="udp">
    <transport type="UDP" socket-binding="jgroups-udp"/>
    <protocol type="PING"/>
    ...
  </stack>
  <stack name="tcp">
    <transport type="TCP" socket-binding="jgroups-tcp"/>
    <protocol type="MPING" socket-binding="jgroups-mping"/>
    ...
  </stack>
</stacks>

멀티 캐스트를 사용하여 TCP 구성

일부 네트워크에서는 TCP만 사용할 수 있습니다. 다음 관리 CLI 명령을 사용하여 미리 구성된 tcp 스택을 사용하도록 ee 채널을 전환합니다.

/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)

이 기본 tcp 스택은 IP 멀티캐스트를 사용하여 초기 클러스터 멤버십을 검색하는 MPING 프로토콜을 사용합니다.

멀티 캐스트 없이 TCP 구성

보안 정책에 의해 멀티 캐스트가 우선하지 않거나 허용되지 않는 경우 TCP를 사용하도록 기본 프로토콜 스택을 변경할 수 있습니다. 멀티 캐스트 없이 TCP 기반 클러스터링을 구성하려면 다음 단계를 수행합니다.

  1. 다음 명령을 실행하여 ee 채널을 전환 하여 NotReady 하위 시스템에서 사전 구성된 tcp 스택을 사용합니다.

    <channel name="ee" stack="tcp" cluster="ejb"/>
  2. 클러스터 노드의 이름을 설정합니다.

    • 독립 실행형 구성 모드에서 다음 단계 중 하나를 수행합니다.

      • 다음 명령을 실행합니다.

        <server xmlns="urn:jboss:domain:8.0" name="node_1">
      • 인스턴스를 시작할 때 시스템 속성 jboss.node.name 에 고유한 이름을 지정합니다.
    • 도메인 모드에서 클러스터 서버는 서버 태그의 host-*.xml 파일에 나열됩니다. 기본 구성은 필요에 따라 편집할 수 있는 다음 서버 이름을 지정합니다.

      <servers>
          <server name="server-one" group="main-server-group"/>
          <server name="server-two" group="other-server-group">
              <socket-bindings port-offset="150"/>
          </server>
      </servers>
  3. 다른 클러스터 멤버를 검색하기 위해 다음 프로토콜 중 하나를 선택합니다.

    • TCPGOSSIP: 이 프로토콜은 외부 gossip 라우터 서비스를 사용하여 클러스터의 멤버를 검색합니다. 이를 위해서는 추가 프로세스를 구성하고 관리해야 하지만 개별 EAP 인스턴스가 서로 클러스터 구성원을 나열하지 않도록 합니다. 이 프로토콜은 클러스터 멤버가 자주 변경되는 경우 유용합니다. 자세한 내용은 TCPPING 을 참조하십시오.
    • TCPPING: 이 프로토콜은 정적 클러스터 멤버십 목록을 정의하고 각 노드가 잠재적인 클러스터 구성원을 모두 나열해야 합니다. 이 프로토콜은 클러스터 멤버 주소를 알려진 경우 선호되며 자주 변경되지 않습니다. 자세한 내용은 TCPGOSSIP 를 참조하십시오.

24.2.3. TCPPING 구성

이 절차에서는 TCPPING 프로토콜을 사용하여 정적 클러스터 멤버십 목록을 정의하는 새 JGroups 스택을 생성합니다. tcpping 스택을 만들고 이 새 스택을 사용하도록 default ee 채널을 설정하는 기본 스크립트가 제공됩니다. 이 스크립트의 관리 CLI 명령은 사용자 환경에 맞게 사용자 지정해야 하며 배치로 처리됩니다.

  1. 다음 스크립트를 텍스트 편집기에 복사하여 로컬 파일 시스템에 저장합니다.

    # Define the socket bindings
    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-a:add(host=HOST_A,port=7600)
    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-b:add(host=HOST_B,port=7600)
    batch
    # Add the tcpping stack
    /subsystem=jgroups/stack=tcpping:add
    /subsystem=jgroups/stack=tcpping/transport=TCP:add(socket-binding=jgroups-tcp)
    /subsystem=jgroups/stack=tcpping/protocol=TCPPING:add(socket-bindings=[jgroups-host-a,jgroups-host-b])
    /subsystem=jgroups/stack=tcpping/protocol=MERGE3:add
    /subsystem=jgroups/stack=tcpping/protocol=FD_SOCK:add
    /subsystem=jgroups/stack=tcpping/protocol=FD_ALL:add
    /subsystem=jgroups/stack=tcpping/protocol=VERIFY_SUSPECT:add
    /subsystem=jgroups/stack=tcpping/protocol=pbcast.NAKACK2:add
    /subsystem=jgroups/stack=tcpping/protocol=UNICAST3:add
    /subsystem=jgroups/stack=tcpping/protocol=pbcast.STABLE:add
    /subsystem=jgroups/stack=tcpping/protocol=pbcast.GMS:add
    /subsystem=jgroups/stack=tcpping/protocol=MFC:add
    /subsystem=jgroups/stack=tcpping/protocol=FRAG3:add
    # Set tcpping as the stack for the ee channel
    /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcpping)
    run-batch
    reload

    정의된 프로토콜 순서가 중요합니다. add-index 값을 add 명령에 전달하여 특정 인덱스에 프로토콜을 삽입할 수도 있습니다 . 인덱스는 0 기반이므로 다음 관리 CLI 명령은 UNICAST3 프로토콜을 7번째 프로토콜로 추가합니다.

    /subsystem=jgroups/stack=tcpping/protocol=UNICAST3:add(add-index=6)
  2. 환경에 맞게 스크립트를 수정합니다.

    • 관리형 도메인에서 실행 중인 경우 / profile=PROFILE_NAME 을 사용하여 /subsystem=jgroups 명령 앞에 업데이트할 프로필을 지정해야 합니다.
    • 환경에 따라 다음 속성을 조정합니다.

      • socket-bindings: 잘 알려져 초기 멤버십을 조회하는 데 사용할 수 있는 호스트와 포트 조합의 쉼표로 구분된 목록입니다. 소켓 바인딩 정의에 대한 자세한 내용은 소켓 바인딩 구성을 참조하십시오.
      • initial_hosts: HOST[PORT] 구문을 사용하여 호스트 및 포트 조합의 쉼표로 구분된 목록으로 잘 알려져 초기 멤버십을 조회할 수 있습니다(예: host1[1000],host2[2000] ).
      • port_range: 이 속성은 initial_hosts 포트 범위를 지정된 값으로 확장하는 데 사용됩니다. 예를 들어 initial_hostshost1[1000],host2[2000] 로 설정하고 port_range1 로 설정하면 initial_hosts 설정이 host1[1000],host1[1001],host2[2000],host2[2001] 로 확장됩니다. 이 속성은 initial_hosts 속성에서만 작동합니다.
  3. 스크립트 파일을 관리 CLI에 전달하여 스크립트를 실행합니다.

    $ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME

TCPPING 스택을 사용할 수 있으며 TCP는 네트워크 통신에 사용됩니다.

24.2.3.1. 독립 실행형 모드로 TCPPING 구성

이 절차에서는 독립 실행형 모드에서 클러스터된 애플리케이션에 대한 TCP 스택 및 노드를 구성하는 데 도움이 됩니다.

절차

  1. 기본 스택을 OPENSHIFT 하위 시스템에서 udp 에서 tcp 로 변경합니다.

    <channel name="ee" stack="tcp" cluster="ejb"/>
  2. 기본 MPING 프로토콜 대신 TCPPING 프로토콜을 사용하도록 TCP 스택을 구성합니다. 다음 코드에서 initial_hosts 속성은 클러스터 내의 모든 노드 목록과 상관 관계가 있으며 7600 은 구성 및 환경에 따라 다를 수 있는 기본 RuntimeClass -tcp 포트를 나타냅니다.

    <stack name="tcp">
      <transport type="TCP" socket-binding="jgroups-tcp"/>
      <protocol type="TCPPING">
        <property name="initial_hosts">192.168.1.5[7600],192.168.1.9[7600]</property>
        <property name="port_range">0</property>
      </protocol>
      <protocol type="MERGE3"/>
      <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
      <protocol type="FD_ALL"/>
      <protocol type="VERIFY_SUSPECT"/>
      <protocol type="pbcast.NAKACK2"/>
      <protocol type="UNICAST3"/>
      <protocol type="pbcast.STABLE"/>
      <protocol type="pbcast.GMS"/>
      <protocol type="MFC"/>
      <protocol type="FRAG3"/>
    </stack>
    참고

    initial_hosts 에 설정된 포트 번호 7600 은 RuntimeClass -tcp 소켓 바인딩 정의에 정의된 포트 번호와 동일해야 합니다. socket-binding에 port-offset 기능을 사용하는 경우 initial_hosts 에서 오프셋 후 동일한 값을 지정해야 합니다.

  3. NotReady 구성 요소에서 사용하는 개인 인터페이스의 IP 주소를 설정합니다. IP 주소는 initial_hosts 에 지정된 IP 주소 중 하나와 상관 관계가 있어야 합니다.

    <interface name="private">
      <inet-address value="${jboss.bind.address.private:192.168.1.5}"/>
    </interface>
  4. 클러스터 내의 다른 노드를 구성하려면 위의 단계를 반복합니다. 노드가 구성되면 각 노드를 시작하고 클러스터된 애플리케이션을 배포합니다.

검증

  • 로그를 확인하여 노드가 실행 중인지 확인할 수 있습니다.

    INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,node_1) ISPN000094: Received new cluster view for channel server: [node_1|1] (2) [node_1, node_2]
    INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,node_1) ISPN000094: Received new cluster view for channel web: [node_1|1] (2) [node_1, node_2]

24.2.3.2. 도메인 모드에서 TCPPING 구성

이 절차에서는 도메인 모드에서 클러스터된 애플리케이션에 대한 TCP 스택 및 노드를 구성하는 데 도움이 됩니다.

절차

  1. 여러 클러스터에 동일한 프로필이 사용되는 경우 system 속성 값을 initial_hosts 로 설정합니다.

    <protocol type="TCPPING">
      <property name="initial_hosts">${jboss.cluster.tcp.initial_hosts}</property>
    
    Set the system property at the `server-group` level:
    <server-groups>
      <server-group name="a-server-group" profile="ha">
      <socket-binding-group ref="ha-sockets"/>
      <system-properties>
        <property name="jboss.cluster.tcp.initial_hosts" value="192.168.1.5[7600],192.168.1.9[7600]" />
      </system-properties>
  2. 호스트 컨트롤러의 XML 구성 내에서 개인 인터페이스의 IP 주소를 설정합니다. 개인 인터페이스의 IP 주소는 initial_hosts 에 나열된 IP 주소 중 하나와 상관 관계가 있어야 합니다.

    <interfaces>
        ....
      <interface name="private">
        <inet-address value="${jboss.bind.address.private:192.168.1.5}"/>
      </interface>
    </interfaces>

검증

  • 로그를 확인하여 노드가 실행 중인지 확인할 수 있습니다.

    INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,node_1) ISPN000094: Received new cluster view for channel server: [node_1|1] (2) [node_1, node_2]
    INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,node_1) ISPN000094: Received new cluster view for channel web: [node_1|1] (2) [node_1, node_2]

24.2.4. TCPGOSSIP 구성

이 절차에서는 TCPGOSSIP 프로토콜을 사용하여 외부 gossip 라우터를 사용하여 클러스터의 구성원을 검색하는 새 JGroups 스택을 생성합니다. tcpgossip 스택을 생성하고 이 새 스택을 사용하도록 default ee 채널을 설정하는 기본 스크립트가 제공됩니다. 이 스크립트의 관리 CLI 명령은 사용자 환경에 맞게 사용자 지정해야 하며 배치로 처리됩니다.

  1. 다음 스크립트를 텍스트 편집기에 복사하여 로컬 파일 시스템에 저장합니다.

    # Define the socket bindings
    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=jgroups-host-a:add(host=HOST_A,port=13001)
    batch
    # Add the tcpgossip stack
    /subsystem=jgroups/stack=tcpgossip:add
    /subsystem=jgroups/stack=tcpgossip/transport=TCP:add(socket-binding=jgroups-tcp)
    /subsystem=jgroups/stack=tcpgossip/protocol=TCPGOSSIP:add(socket-bindings=[jgroups-host-a])
    /subsystem=jgroups/stack=tcpgossip/protocol=MERGE3:add
    /subsystem=jgroups/stack=tcpgossip/protocol=FD_SOCK:add
    /subsystem=jgroups/stack=tcpgossip/protocol=FD_ALL:add
    /subsystem=jgroups/stack=tcpgossip/protocol=VERIFY_SUSPECT:add
    /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.NAKACK2:add
    /subsystem=jgroups/stack=tcpgossip/protocol=UNICAST3:add
    /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.STABLE:add
    /subsystem=jgroups/stack=tcpgossip/protocol=pbcast.GMS:add
    /subsystem=jgroups/stack=tcpgossip/protocol=MFC:add
    /subsystem=jgroups/stack=tcpgossip/protocol=FRAG3:add
    # Set tcpgossip as the stack for the ee channel
    /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcpgossip)
    run-batch
    reload

    정의된 프로토콜 순서가 중요합니다. add-index 값을 add 명령에 전달하여 특정 인덱스에 프로토콜을 삽입할 수도 있습니다 . 인덱스는 0 기반이므로 다음 관리 CLI 명령은 UNICAST3 프로토콜을 7번째 프로토콜로 추가합니다.

    /subsystem=jgroups/stack=tcpgossip/protocol=UNICAST3:add(add-index=6)
  2. 환경에 맞게 스크립트를 수정합니다.

    • 관리형 도메인에서 실행 중인 경우 / profile=PROFILE_NAME 을 사용하여 /subsystem=jgroups 명령 앞에 업데이트할 프로필을 지정해야 합니다.
    • 환경에 따라 다음 속성을 조정합니다.

      • socket-bindings: 잘 알려져 초기 멤버십을 조회하는 데 사용할 수 있는 호스트와 포트 조합의 쉼표로 구분된 목록입니다. 소켓 바인딩 정의에 대한 자세한 내용은 소켓 바인딩 구성을 참조하십시오.
      • initial_hosts: HOST[PORT] 구문을 사용하여 호스트 및 포트 조합의 쉼표로 구분된 목록으로 잘 알려져 초기 멤버십을 조회할 수 있습니다(예: host1[1000],host2[2000] ).
      • port_range: 이 속성은 initial_hosts 포트 범위를 지정된 값으로 확장하는 데 사용됩니다. 예를 들어 initial_hostshost1[1000],host2[2000] 로 설정하고 port_range1 로 설정하면 initial_hosts 설정이 host1[1000],host1[1001],host2[2000],host2[2001] 로 확장됩니다. 이 속성은 initial_hosts 속성에서만 작동합니다.
      • reconnect_interval: 연결이 끊긴 스텁이 gossip 라우터에 다시 연결을 시도하는 간격(밀리초)입니다.
      • sock_conn_timeout: 소켓 생성을 위한 최대 시간. 기본값은 1000 밀리초입니다.
      • sock_read_timeout: 읽기에서 차단할 최대 시간(밀리초)입니다. 값 0 은 무기한 차단됩니다.
  3. 스크립트 파일을 관리 CLI에 전달하여 스크립트를 실행합니다.

    $ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME

이제 TCPGOSSIP 스택을 사용할 수 있으며 TCP는 네트워크 통신에 사용됩니다. 이 스택은 JGroups 클러스터 구성원이 다른 클러스터 구성원을 찾을 수 있도록 gossip 라우터와 함께 사용하도록 구성됩니다.

24.2.5. JDBC_PING 구성

JDBC_PING 프로토콜을 사용하여 클러스터에서 멤버십을 관리하고 검색할 수 있습니다.

JDBC_PING는 data-source에 지정된 데이터베이스를 사용하여 클러스터의 구성원을 나열합니다.

  1. 클러스터 멤버십을 관리하는 데 사용할 데이터베이스에 연결하는 데이터 소스를 생성합니다.
  2. 다음 스크립트를 텍스트 편집기에 복사하여 로컬 파일 시스템에 저장합니다.

    batch
    # Add the JDBC_PING stack
    /subsystem=jgroups/stack=JDBC_PING:add
    /subsystem=jgroups/stack=JDBC_PING/transport=TCP:add(socket-binding=jgroups-tcp)
    /subsystem=jgroups/stack=JDBC_PING/protocol=JDBC_PING:add(data-source=ExampleDS)
    /subsystem=jgroups/stack=JDBC_PING/protocol=MERGE3:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=FD_SOCK:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=FD_ALL:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=VERIFY_SUSPECT:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.NAKACK2:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=UNICAST3:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.STABLE:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=pbcast.GMS:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=MFC:add
    /subsystem=jgroups/stack=JDBC_PING/protocol=FRAG3:add
    # Set JDBC_PING as the stack for the ee channel
    /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=JDBC_PING)
    run-batch
    reload

    정의된 프로토콜 순서가 중요합니다. add-index 값을 add 명령에 전달하여 특정 인덱스에 프로토콜을 삽입할 수도 있습니다 . 인덱스는 0 기반이므로 다음 관리 CLI 명령은 UNICAST3 프로토콜을 7번째 프로토콜로 추가합니다.

    /subsystem=jgroups/stack=JDBC_PING/protocol=UNICAST3:add(add-index=6)
  3. 환경에 맞게 스크립트를 수정합니다.

    • 관리형 도메인에서 실행 중인 경우 / profile=PROFILE_NAME 을 사용하여 /subsystem=jgroups 명령 앞에 업데이트할 프로필을 지정해야 합니다.
    • ExampleDS를 1단계에서 정의한 데이터 소스의 이름으로 바꿉니다.
  4. 스크립트 파일을 관리 CLI에 전달하여 스크립트를 실행합니다.

    $ EAP_HOME/bin/jboss-cli.sh --connect --file=/path/to/SCRIPT_NAME

JDBC_PING 스택을 사용할 수 있으며 TCP는 네트워크 통신에 사용됩니다.

jdbc_PING: https://developer.jboss.org/wiki/JDBCPING

데이터 소스 생성: JBoss EAP 데이터 소스 정보

24.2.6. 네트워크 인터페이스에 JGroups 바인딩

기본적으로 JGroups는 기본 구성에서 localhost를 가리키는 사설 네트워크 인터페이스에만 바인딩됩니다. 보안상의 이유로 JGroups는 공용 네트워크 인터페이스에 클러스터링 트래픽을 노출해서는 안 되기 때문에 JBoss EAP 시작 중에 지정된 -b 인수로 정의된 네트워크 인터페이스에 바인딩하지 않습니다.

네트워크 인터페이스를 구성하는 방법에 대한 자세한 내용은 이 가이드의 네트워크 및 포트 구성 장을 참조하십시오.

중요

보안상의 이유로 JGroups는 비공용 네트워크 인터페이스에만 바인딩되어야 합니다. 성능상의 이유로 JGroups 트래픽의 네트워크 인터페이스가 전용 VLAN(Virtual Local Area Network)의 일부여야 합니다.

24.2.7. 클러스터 보안

클러스터를 안전하게 실행하기 위해서는 다음과 같은 몇 가지 문제가 있습니다.

24.2.7.1. 인증 구성

JGroups 인증은 AUTH 프로토콜에서 수행합니다. 목표는 인증된 노드만 클러스터에 참여할 수 있도록 하는 것입니다.

적용 가능한 서버 구성 파일에서 적절한 속성 설정을 사용하여 AUTH 프로토콜을 추가합니다. The AUTH 프로토콜은 pbcast.GMS 프로토콜 바로 앞에 구성해야 합니다.

다음 예제에서는 권한 부여 토큰의 형태가 다른 AUTH 를 사용하는 방법을 보여줍니다.

간단한 토큰이 있는 AUTH
...
<protocol type="pbcast.STABLE"/>
<auth-protocol type="AUTH">
  <plain-token>
    <shared-secret-reference clear-text="my_password"/>
  </plain-token>
</auth-protocol>
<protocol type="pbcast.GMS"/>
...
다이제스트 알고리즘 토큰이 있는 AUTH

이 형식은 다이제스트 알고리즘(예: MD5 또는 SHA-2)과 함께 사용할 수 있습니다. JBoss EAP 7.4의 기본 다이제스트 알고리즘은 JVM에서 지원하는 데 필요한 강력한 다이제스트 알고리즘인 SHA-256입니다. 대부분의 JVM은 SHA-512를 추가로 구현합니다.

...
<protocol type="pbcast.STABLE"/>
<auth-protocol type="AUTH">
  <digest-token algorithm="SHA-512">
    <shared-secret-reference clear-text="my_password"/>
  </digest-token>
</auth-protocol>
<protocol type="pbcast.GMS"/>
...
X509 토큰이 있는 AUTH

이 예제에서는 elytron 하위 시스템에서 새 키 저장소를 생성하고 JGroups AUTH 구성에서 참조합니다.

  1. 키 저장소를 생성합니다.

    $ keytool -genkeypair -alias jgroups_key -keypass my_password -storepass my_password -storetype jks -keystore jgroups.keystore -keyalg RSA
  2. 관리 CLI를 사용하여 elytron 하위 시스템에 키 저장소를 추가합니다.

    /subsystem=elytron/key-store=jgroups-token-store:add(type=jks,path=/path/to/jgroups.keystore,credential-reference={clear-text=my_password}, required=true)
  3. JGroups 스택 정의에서 키 저장소를 사용하도록 AUTH 를 구성합니다.

    ...
    <protocol type="pbcast.STABLE"/>
    <auth-protocol type="AUTH">
      <cipher-token algorithm="RSA" key-alias="jgroups_key" key-store="jgroups-token-store">
        <shared-secret-reference clear-text="my_password"/>
        <key-credential-reference clear-text="my_password"/>
      </cipher-token>
    </auth-protocol>
    <protocol type="pbcast.GMS"/>
    ...

24.2.7.2. 암호화 구성

메시지를 암호화하기 위해 JGroups는 클러스터의 구성원이 공유하는 비밀 키를 사용합니다. 발신자는 공유 비밀 키를 사용하여 메시지를 암호화하고 수신자는 동일한 비밀 키를 사용하여 메시지를 암호 해독합니다. SYM_ENCRYPT 프로토콜을 사용하여 구성된 대칭 암호화 에서는 노드에서 공유 키 저장소를 사용하여 비밀 키를 검색합니다. ASYM_ENCRYPT 프로토콜을 사용하여 구성된 비대칭 암호화를 사용하면 노드는 AUTH 를 사용하여 인증한 후 클러스터의 코디네이터에서 비밀 키를 검색합니다.

대칭 암호화 사용

SYM_ENCRYPT 를 사용하려면 각 노드의 JGroups 구성에서 참조할 키 저장소를 설정해야 합니다.

  1. 키 저장소를 생성합니다.

    다음 명령에서 VERSION을 적절한 JGroups JAR 버전으로 바꾸고 PASSWORD 를 키 저장소 암호로 바꿉니다.

    $ java -cp EAP_HOME/modules/system/layers/base/org/jgroups/main/jgroups-VERSION.jar org.jgroups.demos.KeyStoreGenerator --alg AES --size 128 --storeName defaultStore.keystore --storepass PASSWORD --alias mykey

    이렇게 하면 JGroups 구성에서 참조되는 기본Store.keystore 파일이 생성됩니다.

  2. 키 저장소가 생성되면 두 가지 방법 중 하나를 사용하여 SYM_PROTOCOL 에 정의됩니다.

참고

SYM_ENCRYPT 를 사용할 때 AUTH 구성은 선택 사항입니다.

키 저장소를 직접 참조하여 대칭 암호화 사용
  1. jgroups 하위 시스템에서 SYM_ENCRYPT 프로토콜을 구성합니다.

    적용 가능한 서버 구성 파일에서 적절한 속성 설정을 사용하여 SYM_ENCRYPT 프로토콜을 추가합니다. 이 프로토콜은 이전에 생성된 키 저장소를 참조합니다. SYM_ENCRYPT 프로토콜은 pbcast.NAKACK2 프로토콜 전에 즉시 구성해야 합니다.

    <subsystem xmlns="urn:jboss:domain:jgroups:6.0">
      <stacks>
        <stack name="udp">
          <transport type="UDP" socket-binding="jgroups-udp"/>
          <protocol type="PING"/>
          <protocol type="MERGE3"/>
          <protocol type="FD_SOCK"/>
          <protocol type="FD_ALL"/>
          <protocol type="VERIFY_SUSPECT"/>
          <protocol type="SYM_ENCRYPT">
            <property name="provider">SunJCE</property>
            <property name="sym_algorithm">AES</property>
            <property name="encrypt_entire_message">true</property>
            <property name="keystore_name">/path/to/defaultStore.keystore</property>
            <property name="store_password">PASSWORD</property>
            <property name="alias">mykey</property>
          </protocol>
          <protocol type="pbcast.NAKACK2"/>
          <protocol type="UNICAST3"/>
          <protocol type="pbcast.STABLE"/>
          <protocol type="pbcast.GMS"/>
          <protocol type="UFC"/>
          <protocol type="MFC"/>
          <protocol type="FRAG3"/>
        </stack>
      </stacks>
    </subsystem>
Elytron으로 대칭 암호화 사용
  1. 관리 CLI를 사용하여 대칭 암호화를 사용하여 에 생성된 기본Store.keystore 를 참조하는 elytron 하위 시스템에 키 저장소를 생성합니다.

    /subsystem=elytron/key-store=jgroups-keystore:add(path=/path/to/defaultStore.keystore,credential-reference={clear-text=PASSWORD},type=JCEKS)
  2. 적절한 속성 설정을 사용하여 jgroups 하위 시스템에 SYM_ENCRYPT 프로토콜을 추가합니다. SYM_ENCRYPT 프로토콜은 다음 설정에서 볼 수 있듯이 pbcast.NAKACK2 프로토콜 바로 앞에 구성해야 합니다.

    <subsystem xmlns="urn:jboss:domain:jgroups:6.0">
      <stacks>
        <stack name="udp">
          <transport type="UDP" socket-binding="jgroups-udp"/>
          <protocol type="PING"/>
          <protocol type="MERGE3"/>
          <protocol type="FD_SOCK"/>
          <protocol type="FD_ALL"/>
          <protocol type="VERIFY_SUSPECT"/>
          <encrypt-protocol type="SYM_ENCRYPT" key-alias="mykey" key-store="jgroups-keystore">
            <key-credential-reference clear-text="PASSWORD"/>
            <property name="provider">SunJCE</property>
            <property name="encrypt_entire_message">true</property>
          </encrypt-protocol>
          <protocol type="pbcast.NAKACK2"/>
          <protocol type="UNICAST3"/>
          <protocol type="pbcast.STABLE"/>
          <protocol type="pbcast.GMS"/>
          <protocol type="UFC"/>
          <protocol type="MFC"/>
          <protocol type="FRAG3"/>
        </stack>
      </stacks>
    </subsystem>
    참고

    위의 예제에서는 일반 텍스트 암호를 사용하지만 구성 파일 외부에서 암호를 정의하도록 자격 증명 저장소를 정의할 수도 있습니다. 이 저장소 구성에 대한 자세한 내용은 How to Configure Server Security Guide의 Credential Store 섹션을 참조하십시오.

비대칭 암호화 사용

ASYM_ENCRYPT 를 사용하려면 AUTH 프로토콜을 정의해야 합니다. jgroups 하위 시스템에서 AUTH 프로토콜을 구성하는 방법에 대한 지침은 인증 구성 섹션을 참조하십시오.

ASYM_ENCRYPT 는 두 가지 방법 중 하나를 사용하여 구성됩니다.

비밀 키를 생성하여 비대칭 암호화 사용
  1. jgroups 하위 시스템에서 ASYM_ENCRYPT 프로토콜을 구성합니다.

    적용 가능한 서버 구성 파일에서 적절한 속성 설정을 사용하여 ASYM_ENCRYPT 프로토콜을 추가합니다. 다음 설정에서 볼 수 있듯이 ASYM_ENCRYPT 프로토콜은 pbcast.NAKACK2 프로토콜 바로 앞에 구성해야 합니다.

    <subsystem xmlns="urn:jboss:domain:jgroups:6.0">
      <stacks>
        <stack name="udp">
          <transport type="UDP" socket-binding="jgroups-udp"/>
          <protocol type="PING"/>
          <protocol type="MERGE3"/>
          <protocol type="FD_SOCK"/>
          <protocol type="FD_ALL"/>
          <protocol type="VERIFY_SUSPECT"/>
          <protocol type="ASYM_ENCRYPT">
            <property name="encrypt_entire_message">true</property>
            <property name="sym_keylength">128</property>
            <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
            <property name="asym_keylength">512</property>
            <property name="asym_algorithm">RSA</property>
          </protocol>
          <protocol type="pbcast.NAKACK2"/>
          <protocol type="UNICAST3"/>
          <protocol type="pbcast.STABLE"/>
          <!-- Configure AUTH protocol here -->
          <protocol type="pbcast.GMS"/>
          <protocol type="UFC"/>
          <protocol type="MFC"/>
          <protocol type="FRAG3"/>
        </stack>
      </stacks>
    </subsystem>
Elytron으로 비대칭 암호화 사용
  1. 키 쌍을 포함할 키 저장소를 생성합니다. 다음 명령은 mykey 항목을 사용하여 키 저장소를 생성합니다.

    $ keytool -genkeypair -alias mykey -keyalg RSA -keysize 1024 -keystore defaultKeystore.keystore -dname "CN=localhost" -keypass secret -storepass secret
  2. 관리 CLI를 사용하여 defaultStore.keystore 를 참조하는 elytron 하위 시스템에서 키 저장소를 생성합니다.

    /subsystem=elytron/key-store=jgroups-keystore:add(path=/path/to/defaultStore.keystore,credential-reference={clear-text=PASSWORD},type=JCEKS)
  3. 적절한 속성 설정을 사용하여 jgroups 하위 시스템에 ASYM_ENCRYPT 프로토콜을 추가합니다. 다음 설정에서 볼 수 있듯이 ASYM_ENCRYPT 프로토콜은 pbcast.NAKACK2 프로토콜 바로 앞에 구성해야 합니다.

    <subsystem xmlns="urn:jboss:domain:jgroups:6.0">
      <stacks>
        <stack name="udp">
          <transport type="UDP" socket-binding="jgroups-udp"/>
          <protocol type="PING"/>
          <protocol type="MERGE3"/>
          <protocol type="FD_SOCK"/>
          <protocol type="FD_ALL"/>
          <protocol type="VERIFY_SUSPECT"/>
          <encrypt-protocol type="ASYM_ENCRYPT" key-alias="mykey" key-store="jgroups-keystore">
            <key-credential-reference clear-text="secret" />
            <property name="encrypt_entire_message">true</property>
          </encrypt-protocol>
          <protocol type="pbcast.NAKACK2"/>
          <protocol type="UNICAST3"/>
          <protocol type="pbcast.STABLE"/>
          <!-- Configure AUTH protocol here -->
          <protocol type="pbcast.GMS"/>
          <protocol type="UFC"/>
          <protocol type="MFC"/>
          <protocol type="FRAG3"/>
        </stack>
      </stacks>
    </subsystem>
    참고

    위의 예제에서는 일반 텍스트 암호를 사용하지만 구성 파일 외부에서 암호를 정의하도록 자격 증명 저장소를 정의할 수도 있습니다. 이 저장소 구성에 대한 자세한 내용은 How to Configure Server Security Guide의 Credential Store 섹션을 참조하십시오.

24.2.8. JGroups 스레드 풀 구성

jgroups 하위 시스템에는 default,internal,oobtimer 스레드 풀이 포함되어 있습니다. 이러한 풀은 모든 NotReady 스택에 대해 구성할 수 있으며 로컬 노드에 구성된 빈 또는 다른 풀에는 영향을 미치지 않습니다. JGroup 스레드 풀은 클러스터 통신을 지원하는 데 사용됩니다.

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

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

default

이 풀은 대역 외로 표시되지 않는 수신 메시지를 처리하는 데 사용됩니다.

60000L

300

20

100

internal

이 풀은 EAP 유지 관리에 필요한 내부 프로세스를 처리하는 데 사용됩니다.

60000L

4

2

100

OOB

이 풀은 들어오는 대역 외 메시지를 처리하는 데 사용됩니다.

60000L

300

20

0

타이머

이 풀은 시간 바인딩된 스케줄러 메시지를 처리하는 데 사용됩니다.

5000L

4

2

500

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

/subsystem=jgroups/stack=STACK_TYPE/transport=TRANSPORT_TYPE/thread-pool=THREAD_POOL_NAME:write-attribute(name=ATTRIBUTE_NAME, value=ATTRIBUTE_VALUE)

다음은 udp 스택의 기본 스레드 풀에서 max-threads 값을 500 으로 설정하는 관리 CLI 명령의 예입니다.

/subsystem=jgroups/stack=udp/transport=UDP/thread-pool=default:write-attribute(name="max-threads", value="500")

24.2.9. JGroups 전송 및 버퍼 수신 구성

버퍼 크기 경고 해결

기본적으로 JGroups는 특정 전송 및 수신 버퍼 값으로 구성되지만 운영 체제는 사용 가능한 버퍼 크기를 제한할 수 있으며 JBoss EAP는 구성된 버퍼 값을 사용하지 못할 수 있습니다. 이 경우 다음과 유사한 JBoss EAP 로그에 경고가 표시됩니다.

WARNING [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 68)
JGRP000015: the send buffer of socket DatagramSocket was set to 640KB, but the OS only allocated 212.99KB.
This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
WARNING [org.jgroups.protocols.UDP] (ServerService Thread Pool -- 68)
JGRP000015: the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 212.99KB.
This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)

이 문제를 해결하려면 운영 체제 설명서에서 버퍼 크기를 늘리는 방법에 대한 지침을 참조하십시오. Red Hat Enterprise Linux 시스템의 경우 /etc/sysctl.conf 를 루트 사용자로 편집하여 시스템 재시작 후에도 유지되는 버퍼 크기의 최대 값을 구성합니다. 예를 들면 다음과 같습니다.

# Allow a 25MB UDP receive buffer for JGroups
net.core.rmem_max = 26214400
# Allow a 1MB UDP send buffer for JGroups
net.core.wmem_max = 1048576

/etc/sysctl.conf 를 수정한 후 sysctl -p 를 실행하여 변경 사항을 적용합니다.

JGroups 버퍼 크기 구성

UDP 및 TCP JGroups 스택에서 다음 전송 속성을 설정하여 JBoss EAP에서 사용하는 JGroups 버퍼 크기를 구성할 수 있습니다.

UDP 스택
  • ucast_recv_buf_size
  • ucast_send_buf_size
  • mcast_recv_buf_size
  • mcast_send_buf_size
TCP 스택
  • recv_buf_size
  • send_buf_size

JGroups 버퍼 크기는 관리 콘솔 또는 관리 CLI를 사용하여 구성할 수 있습니다.

관리 CLI로 JGroups 버퍼 크기 속성을 설정하려면 다음 구문을 사용합니다.

/subsystem=jgroups/stack=STACK_NAME/transport=TRANSPORT/property=PROPERTY_NAME:add(value=BUFFER_SIZE)

다음은 tcp 스택에서 Rec v_buf_size 속성을 20000000 으로 설정하는 예제 관리 CLI 명령입니다.

/subsystem=jgroups/stack=tcp/transport=TRANSPORT/property=recv_buf_size:add(value=20000000)

JGroups 버퍼 크기는 Configuration (구성) 탭에서 JGroups 하위 시스템으로 이동하고 View (보기), Stack (스택) 탭 선택, 적절한 스택을 선택하고, 전송( Transport )을 클릭하고 Properties (속성) 필드를 편집하여 관리 콘솔을 사용하여 구성할 수도 있습니다.

24.2.10. JGroups 하위 시스템 튜닝

jgroups 하위 시스템의 성능 모니터링 및 최적화에 대한 팁은 성능 튜닝 가이드의 JGroups 하위 시스템 튜닝 섹션을 참조하십시오.

24.2.11. JGroups 문제 해결

24.2.11.1. 노드가 클러스터를 구성하지 않음

시스템이 IP 멀티캐스트에 대해 올바르게 설정되었는지 확인합니다. 다음은 IP 멀티캐스트를 테스트하는 데 사용할 수 있는 JBoss EAP와 함께 제공되는 두 가지 테스트 프로그램입니다. McastReceiverTestMcastSenderTest.

터미널에서 McastReceiverTest 를 시작합니다.

$ java -cp EAP_HOME/bin/client/jboss-client.jar org.jgroups.tests.McastReceiverTest -mcast_addr 230.11.11.11 -port 5555

다른 터미널 창에서 McastSenderTest 를 시작합니다.

$ java -cp EAP_HOME/bin/client/jboss-client.jar org.jgroups.tests.McastSenderTest -mcast_addr 230.11.11.11 -port 5555

특정 NIC(네트워크 인터페이스 카드)에 바인딩하려면 -bind_addr YOUR_BIND_ADDRESS 를 사용합니다. 여기서 YOUR_BIND_ADDRESS 는 바인딩하려는 NIC의 IP 주소입니다. 발신자 및 수신자 모두에서 이 매개변수를 사용합니다.

McastSenderTest 터미널 창을 입력하면 McastReceiverTest 창에 출력이 표시됩니다. 그렇지 않은 경우 다음 단계를 시도합니다.

  • 발신자 명령에 -ttl VALUE 를 추가하여 멀티캐스트 패킷의 TTL(Time-to-Live)을 늘립니다. 이 테스트 프로그램에서 사용하는 기본값은 32 이고 VALUE255 보다 크지 않아야 합니다.
  • 시스템에 여러 인터페이스가 있는 경우 올바른 인터페이스를 사용 중인지 확인합니다.
  • 선택한 인터페이스에서 멀티 캐스트가 작동하는지 확인하려면 시스템 관리자에게 문의하십시오.

멀티 캐스트가 클러스터의 각 시스템에서 제대로 작동하고 나면 위의 테스트를 반복하여 네트워크를 테스트하고 발신자를 한 시스템에 배치하고 수신자를 다른 시스템에 배치할 수 있습니다.

24.2.11.2. 오류 감지에서 부정중한 Heartbeat의 원인

경우에 따라 시간 제한max_tries 로 정의되는 T 시간 동안 하트비트 승인이 수신되지 않았기 때문에 클러스터 구성원이 FD(실패 탐지)로 의심되는 경우가 있습니다.

A, B, C 및 D 노드의 예를 들어 A, B pings, B pings C, C ping D 및 D pings A가 있는 클러스터의 경우 다음과 같은 이유로 C가 의심될 수 있습니다.

  • B 또는 C는 T 초 이상 100% CPU에서 실행됩니다. 따라서 C가 하트비트 승인을 B로 보내더라도 B는 100% CPU 사용량이기 때문에 이를 처리하지 못할 수 있습니다.
  • B 또는 C는 가비지 수집이며 위와 동일한 상황이 발생합니다.
  • 위의 두 가지 사례의 조합.
  • 네트워크에서 패킷이 손실됩니다. 이는 일반적으로 네트워크에 많은 트래픽이 있고 스위치가 패킷 삭제를 시작하고, 일반적으로 먼저 브로드캐스트되고, IP 멀티캐스트 및 TCP 패킷이 지속되기 시작합니다.
  • B 또는 C가 콜백을 처리합니다. 예를 들어 C가 처리할 T + 1초가 걸리는 채널을 통해 원격 메서드 호출을 수신하면 이 시간 동안 C는 하트비트를 포함한 다른 메시지를 처리하지 않습니다. 따라서 B는 하트비트 승인을 받지 않으며 C.