4.8. 클라이언트 연결에 대한 Operator 기반 브로커 배포 구성

4.8.1. 수락자 구성

OpenShift 배포에서 브로커 Pod에 대한 클라이언트 연결을 활성화하려면 배포에 대한 어셉터 를 정의합니다. acceptors는 브로커 Pod에서 연결을 수락하는 방법을 정의합니다. 브로커 배포에 사용되는 주요 CR(사용자 정의 리소스)에서 어셉터를 정의합니다. 어셉터를 생성할 때 acceptor에서 사용할 메시징 프로토콜과 같은 정보와 이러한 프로토콜에 사용할 브로커 Pod의 포트를 지정합니다.

다음 절차에서는 브로커 배포를 위해 CR에 새 어셉터를 정의하는 방법을 보여줍니다.

절차

  1. 초기 설치 중에 다운로드하여 추출한 Operator 아카이브의 deploy/crs 디렉터리에서 broker_activemqartemis_cr.yaml CR(사용자 정의 리소스) 파일을 엽니다.
  2. acceptors 요소에서 named acceptor를 추가합니다. protocolsport 매개 변수를 추가합니다. acceptor 및 각 브로커 Pod의 포트를 해당 프로토콜에 노출할 메시징 프로토콜을 지정하려면 값을 설정합니다. 예를 들면 다음과 같습니다.

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp
        port: 5672
    ...

    구성된 acceptor는 포트 5672를 AMQP 클라이언트에 노출합니다. protocols 매개변수에 지정할 수 있는 전체 값 세트는 표에 표시됩니다.

    프로토콜현재의

    코어 프로토콜

    코어

    AMQP

    amqp

    OpenWire

    Open>-<re

    MQTT

    mqtt

    STOMP

    stomp

    지원되는 모든 프로토콜

    all

    참고
    • 배포의 각 브로커 Pod에 대해 Operator는 포트 61616을 사용하는 기본 어셉터도 생성합니다. 이 기본 어셉터는 브로커 클러스터링에 필요하며 코어 프로토콜이 활성화되어 있습니다.
    • 기본적으로 AMQ Broker 관리 콘솔은 브로커 Pod에서 포트 8161을 사용합니다. 배포의 각 브로커 Pod에는 콘솔에 대한 액세스를 제공하는 전용 서비스가 있습니다. 자세한 내용은 5장. Operator 기반 브로커 배포를 위해 AMQ 관리 콘솔에 연결의 내용을 참조하십시오.
  3. 동일한 어셉터에서 다른 프로토콜을 사용하려면 protocols 매개변수를 수정합니다. 쉼표로 구분된 프로토콜 목록을 지정합니다. 예를 들면 다음과 같습니다.

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
    ...

    이제 구성된 acceptor가 AMQP 및 OpenForwardedre 클라이언트에 포트 5672를 노출합니다.

  4. 수락자가 허용하는 동시 클라이언트 연결 수를 지정하려면 connectionsAllowed 매개변수를 추가하고 값을 설정합니다. 예를 들면 다음과 같습니다.

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        connectionsAllowed: 5
    ...
  5. 기본적으로 어셉터는 브로커 배포와 동일한 OpenShift 클러스터의 클라이언트에만 노출됩니다. OpenShift 외부의 클라이언트에 acceptor도 노출하려면 expose 매개변수를 추가하고 값을 true 로 설정합니다.

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        connectionsAllowed: 5
        expose: true
        ...
    ...

    OpenShift 외부의 클라이언트에 어셉터를 노출하면 Operator는 배포의 각 브로커 포드에 대해 전용 서비스 및 경로를 자동으로 생성합니다.

  6. OpenShift 외부의 클라이언트에서 어셉터에 대한 보안 연결을 활성화하려면 sslEnabled 매개변수를 추가하고 값을 true 로 설정합니다.

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        connectionsAllowed: 5
        expose: true
        sslEnabled: true
        ...
    ...

    수락자(또는 커넥터)에서 SSL(즉, Secure Sockets Layer) 보안을 활성화하면 다음과 같은 관련 구성을 추가할 수 있습니다.

    • OpenShift 클러스터에 인증 자격 증명을 저장하는 데 사용되는 시크릿 이름입니다. 수락자에서 SSL을 활성화하면 시크릿이 필요합니다. 이 시크릿 생성에 대한 자세한 내용은 4.8.2절. “broker-client 연결 보안” 을 참조하십시오.
    • 보안 네트워크 통신에 사용할 TLS(Transport Layer Security) 프로토콜입니다. TLS는 보다 안전한 SSL 버전입니다. enabledProtocols 매개변수에 TLS 프로토콜을 지정합니다.
    • 어셉터가 2방향 TLS를 사용하는지 여부 (중간 인증 이라고도 함) 브로커와 클라이언트 사이입니다. needClientAuth 매개변수의 값을 true 로 설정하여 지정합니다.

추가 리소스

4.8.2. broker-client 연결 보안

어셉터 또는 커넥터에서 보안을 활성화한 경우(즉, sslEnabledtrue로 설정하여 브로커와 클라이언트 간의 인증서 기반 인증을 허용하도록 TLS(Transport Layer Security)를 구성해야 합니다. TLS는 보다 안전한 SSL 버전입니다. 다음 두 가지 기본 TLS 구성이 있습니다.

단방향 TLS
브로커만 인증서를 제공합니다. 인증서는 클라이언트가 브로커를 인증하는 데 사용됩니다. 가장 일반적인 구성입니다.
양방향 TLS
브로커와 클라이언트 모두 인증서를 제공합니다. 이를 상호 인증 이라고 합니다.

다음 섹션은 다음과 같습니다.

단방향 및 양방향 TLS의 경우 브로커와 클라이언트 간에 성공적인 TLS 핸드셰이크에 필요한 인증 정보를 저장하는 시크릿을 생성하여 구성을 완료합니다. 보안 수락자 또는 커넥터의 sslSecret 매개변수에 지정해야 하는 보안 이름입니다. 시크릿에는 Base64로 인코딩된 브로커 키 저장소(한방향 및 양방향 TLS 모두), Base64로 인코딩된 브로커 신뢰 저장소(two-way TLS만 해당), Base64 인코딩 브로커의 해당 암호도 포함되어야 합니다. 단방향 및 양방향 TLS 구성 프로시저에서는 이 시크릿을 생성하는 방법을 보여줍니다.

참고

보안 수용자 또는 커넥터의 sslSecret 매개변수에 보안 이름을 명시적으로 지정하지 않으면 어셉터 또는 커넥터가 기본 보안 이름을 가정합니다. 기본 시크릿 이름은 < custom_resource_name> - <acceptor_name> -secret 또는 < custom_resource_name> - <connector_name> -secret 을 사용합니다. 예를 들면 my-broker-deployment-my-acceptor-secret 입니다.

어셉터 또는 커넥터가 기본 시크릿 이름을 가정하더라도 이 시크릿을 직접 생성해야 합니다. 자동으로 생성되지 않습니다.

4.8.2.1. 호스트 이름 확인을 위한 브로커 인증서 구성

참고

이 섹션에서는 단방향 또는 양방향 TLS를 구성할 때 생성해야 하는 브로커 인증서의 몇 가지 요구 사항에 대해 설명합니다.

클라이언트가 배포의 브로커 Pod에 연결을 시도할 때 클라이언트 연결 URL의 verifyHost 옵션은 클라이언트가 브로커 인증서의 CN(Common Name)을 호스트 이름과 비교하여 일치하는지 여부를 결정합니다. 클라이언트는 클라이언트 연결 URL에서 verifyHost=true 또는 유사한 것을 지정하는 경우 이 확인을 수행합니다.

연결이 분리된 네트워크의 OpenShift 클러스터에 배포된 경우와 같이 연결 보안에 대한 우려가 없는 드문 경우 이러한 확인을 생략할 수 있습니다. 그렇지 않으면 보안 연결의 경우 클라이언트가 이 확인을 수행하는 것이 좋습니다. 이 경우 클라이언트 연결이 성공하려면 브로커 키 저장소 인증서에 대한 올바른 구성이 필요합니다.

일반적으로 클라이언트가 호스트 확인을 사용하는 경우 브로커 인증서를 생성할 때 지정하는 CN은 클라이언트가 연결하는 브로커 Pod의 전체 호스트 이름과 일치해야 합니다. 예를 들어 단일 브로커 포드가 있는 배포가 있는 경우 CN은 다음과 같을 수 있습니다.

CN=my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain

CN이 여러 브로커가 있는 배포의 모든 브로커 Pod로 확인할 수 있도록 하려면 브로커 Pod의 오디널 대신 별표(*) 와일드카드 문자를 지정할 수 있습니다. 예를 들면 다음과 같습니다.

CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain

이전 예에 표시된 CN은 my-broker-deployment 배포의 브로커 Pod로 성공적으로 확인되었습니다.

또한 브로커 인증서를 생성할 때 지정하는 SAN(Subject Alternative Name)은 배포의 모든 브로커 Pod를 쉼표로 구분된 목록으로 개별적으로 나열해야 합니다. 예를 들면 다음과 같습니다.

"SAN=DNS:my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain,DNS:my-broker-deployment-1-svc-rte-my-openshift-project.my-openshift-domain,..."

4.8.2.2. 단방향 TLS 구성

이 섹션의 절차에서는 broker-client 연결을 보호하기 위해 단방향 전송 계층 보안(TLS)을 구성하는 방법을 보여줍니다.

단방향 TLS에서는 브로커만 인증서를 제공합니다. 이 인증서는 클라이언트가 브로커를 인증하는 데 사용됩니다.

사전 요구 사항

절차

  1. 브로커 키 저장소에 대한 자체 서명 인증서를 생성합니다.

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
  2. 클라이언트와 공유할 수 있도록 브로커 키 저장소에서 인증서를 내보냅니다. Base64로 인코딩된 .pem 형식으로 인증서를 내보냅니다. 예를 들면 다음과 같습니다.

    $ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
  3. 클라이언트에서 브로커 인증서를 가져오는 클라이언트 신뢰 저장소를 생성합니다.

    $ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
  4. 관리자로 OpenShift Container Platform에 로그인합니다. 예를 들면 다음과 같습니다.

    $ oc login -u system:admin
  5. 브로커 배포가 포함된 프로젝트로 전환합니다. 예를 들면 다음과 같습니다.

    $ oc project <my_openshift_project>
  6. TLS 자격 증명을 저장할 시크릿을 생성합니다. 예를 들면 다음과 같습니다.

    $ oc create secret generic my-tls-secret \
    --from-file=broker.ks=~/broker.ks \
    --from-file=client.ts=~/client.ks \
    --from-literal=keyStorePassword=<password> \
    --from-literal=trustStorePassword=<password>
    참고

    시크릿을 생성할 때 OpenShift에서는 키 저장소와 신뢰 저장소를 모두 지정해야 합니다. 신뢰 저장소 키의 이름은 일반적으로 client.ts 로 지정됩니다. 브로커와 클라이언트 간의 단방향 TLS의 경우 실제로 신뢰 저장소가 필요하지 않습니다. 그러나 시크릿을 성공적으로 생성하려면 몇 가지 유효한 저장소 파일을 client.ts 의 값으로 지정해야 합니다. 이전 단계에서는 이전에 생성된 브로커 키 저장소 파일을 재사용하여 client.ts 에 대한 "dummy" 값을 제공합니다. 이는 단방향 TLS에 필요한 모든 자격 증명으로 시크릿을 생성하기에 충분합니다.

  7. Operator를 설치할 때 생성한 서비스 계정에 보안을 연결합니다. 예를 들면 다음과 같습니다.

    $ oc secrets link sa/amq-broker-operator secret/my-tls-secret
  8. 보안 수용자 또는 커넥터의 sslSecret 매개변수에 보안 이름을 지정합니다. 예를 들면 다음과 같습니다.

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        sslEnabled: true
        sslSecret: my-tls-secret
        expose: true
        connectionsAllowed: 5
    ...

4.8.2.3. 양방향 TLS 구성

이 섹션의 절차에서는 broker-client 연결을 보호하기 위해 양방향 전송 계층 보안(TLS)을 구성하는 방법을 보여줍니다.

양방향 TLS에서는 브로커와 클라이언트 모두 인증서를 제공합니다. 브로커와 클라이언트는 이러한 인증서를 사용하여 상호 인증 이라는 프로세스에서 서로 인증합니다.

사전 요구 사항

절차

  1. 브로커 키 저장소에 대한 자체 서명 인증서를 생성합니다.

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
  2. 클라이언트와 공유할 수 있도록 브로커 키 저장소에서 인증서를 내보냅니다. Base64로 인코딩된 .pem 형식으로 인증서를 내보냅니다. 예를 들면 다음과 같습니다.

    $ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
  3. 클라이언트에서 브로커 인증서를 가져오는 클라이언트 신뢰 저장소를 생성합니다.

    $ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
  4. 클라이언트에서 클라이언트 키 저장소에 대한 자체 서명된 인증서를 생성합니다.

    $ keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ks
  5. 클라이언트에서 클라이언트 키 저장소에서 인증서를 내보내 브로커와 공유할 수 있습니다. Base64로 인코딩된 .pem 형식으로 인증서를 내보냅니다. 예를 들면 다음과 같습니다.

    $ keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pem
  6. 클라이언트 인증서를 가져오는 브로커 신뢰 저장소를 생성합니다.

    $ keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pem
  7. 관리자로 OpenShift Container Platform에 로그인합니다. 예를 들면 다음과 같습니다.

    $ oc login -u system:admin
  8. 브로커 배포가 포함된 프로젝트로 전환합니다. 예를 들면 다음과 같습니다.

    $ oc project <my_openshift_project>
  9. TLS 자격 증명을 저장할 시크릿을 생성합니다. 예를 들면 다음과 같습니다.

    $ oc create secret generic my-tls-secret \
    --from-file=broker.ks=~/broker.ks \
    --from-file=client.ts=~/broker.ts \
    --from-literal=keyStorePassword=<password> \
    --from-literal=trustStorePassword=<password>
    참고

    시크릿을 생성할 때 OpenShift에서는 키 저장소와 신뢰 저장소를 모두 지정해야 합니다. 신뢰 저장소 키의 이름은 일반적으로 client.ts 로 지정됩니다. 브로커와 클라이언트 간의 양방향 TLS의 경우 클라이언트 인증서가 포함되므로 브로커 신뢰 저장소를 포함하는 보안을 생성해야 합니다. 따라서 이전 단계에서 client.ts 키에 대해 지정하는 값은 실제로 브로커 신뢰 저장소 파일입니다.

  10. Operator를 설치할 때 생성한 서비스 계정에 보안을 연결합니다. 예를 들면 다음과 같습니다.

    $ oc secrets link sa/amq-broker-operator secret/my-tls-secret
  11. 보안 수용자 또는 커넥터의 sslSecret 매개변수에 보안 이름을 지정합니다. 예를 들면 다음과 같습니다.

    spec:
    ...
      acceptors:
      - name: my-acceptor
        protocols: amqp,openwire
        port: 5672
        sslEnabled: true
        sslSecret: my-tls-secret
        expose: true
        connectionsAllowed: 5
    ...

4.8.3. 브로커 배포의 네트워킹 서비스

브로커 배포를 위해 OpenShift Container Platform 웹 콘솔의 네트워킹 창에는 두 개의 실행 중인 서비스( 헤드리스 서비스 및 ping 서비스)가 있습니다. 헤드리스 서비스의 기본 이름은 < custom_resource_name> -hdls-svc 형식(예: my-broker-deployment-hdls-svc )을 사용합니다. ping 서비스의 기본 이름은 < custom_resource_name> -ping-svc 형식(예: 'my-broker-deployment-ping-svc )을 사용합니다.

헤드리스 서비스는 내부 브로커 클러스터링에 사용되는 포트 61616에 대한 액세스를 제공합니다.

ping 서비스는 브로커가 검색을 위해 사용되며 브로커는 OpenShift 환경 내에서 클러스터를 구성할 수 있습니다. 이 서비스는 내부적으로 포트 8888을 노출합니다.

4.8.4. 내부 및 외부 클라이언트에서 브로커에 연결

이 섹션의 예제에서는 내부 클라이언트(즉, 브로커 배포와 동일한 OpenShift 클러스터에 있는 클라이언트) 및 외부 클라이언트(즉, OpenShift 클러스터 외부의 클라이언트)에 연결하는 방법을 보여줍니다.

4.8.4.1. 내부 클라이언트에서 브로커에 연결

내부 클라이언트를 브로커에 연결하려면 클라이언트 연결 세부 정보에서 브로커 Pod의 DNS 확인 가능한 이름을 지정합니다. 예를 들면 다음과 같습니다.

$ tcp://ex–aao-ss-0:<port>

내부 클라이언트가 Core 프로토콜을 사용하고 있고 useTopologyForLoadBalancing=false 키가 연결 URL에 설정되지 않은 경우 클라이언트가 브로커에 처음 연결된 후 브로커는 클러스터에 있는 모든 브로커의 주소를 알릴 수 있습니다. 그러면 클라이언트가 모든 브로커 간에 연결을 로드 밸런싱할 수 있습니다.

브로커에 미미한 서브스크립션 대기열 또는 요청/응답 대기열이 있는 경우 클라이언트 연결이 부하 분산될 때 이러한 큐 사용과 관련된 주의 사항을 알고 있어야 합니다. 자세한 내용은 4.8.4.4절. “미정형 서브스크립션 대기열 또는 응답/요청 대기열이 있는 경우 클라이언트 연결을 로드 밸런싱하는 경고”의 내용을 참조하십시오.

4.8.4.2. 외부 클라이언트에서 브로커에 연결

외부 클라이언트에 어셉터를 노출하는 경우 (즉, expose 매개변수의 값을 true로 설정하여) Operator는 배포에서 각 브로커 Pod에 대한 전용 서비스 및 경로를 자동으로 생성합니다.

외부 클라이언트는 브로커 Pod에 대해 생성된 경로의 전체 호스트 이름을 지정하여 브로커에 연결할 수 있습니다. 기본 curl 명령을 사용하여 이 전체 호스트 이름에 대한 외부 액세스를 테스트할 수 있습니다. 예를 들면 다음과 같습니다.

$ curl https://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain

브로커 Pod의 경로 전체 호스트 이름은 OpenShift 라우터를 호스팅하는 노드로 확인되어야 합니다. OpenShift 라우터는 호스트 이름을 사용하여 OpenShift 내부 네트워크 내에서 트래픽을 보낼 위치를 결정합니다. 기본적으로 OpenShift 라우터는 보안되지 않은(SSL이 아닌) 트래픽(즉, SSL 암호화) 트래픽에 대해 포트 80을 수신합니다. HTTP 연결의 경우 보안 연결 URL(즉, https)을 지정하거나 안전하지 않은 연결 URL(즉, http)을 지정하면 라우터에서 포트 443으로 트래픽을 자동으로 전달합니다.

외부 클라이언트가 클러스터의 브로커 간에 연결을 로드 밸런싱하려면 다음을 수행합니다.

  • 각 브로커 포드에 대해 OpenShift 경로에 haproxy.router.openshift.io/balance roundrobin 옵션을 구성하여 부하 분산을 활성화합니다.
  • 외부 클라이언트가 Core 프로토콜을 사용하는 경우 기본적으로 useTopologyForLoadBalancing 구성 옵션이 true 로 설정됩니다. 연결 URL에서 이 값이 false로 설정되어 있지 않은지 확인합니다.

브로커에 미미한 서브스크립션 대기열 또는 요청/응답 대기열이 있는 경우 클라이언트 연결을 부하 분산할 때 이러한 큐 사용과 관련된 주의 사항을 알고 있어야 합니다. 자세한 내용은 4.8.4.4절. “미정형 서브스크립션 대기열 또는 응답/요청 대기열이 있는 경우 클라이언트 연결을 로드 밸런싱하는 경고”의 내용을 참조하십시오.

외부 클라이언트가 클러스터의 브로커 간에 연결을 로드 밸런싱하지 않도록 하려면 다음을 수행합니다.

  • 각 클라이언트가 사용하는 연결 URL에서 useTopologyForLoadBalancing=false 키를 설정합니다.
  • 각 클라이언트의 연결 URL에서 각 브로커 Pod의 경로 전체 호스트 이름을 지정합니다. 클라이언트는 연결 URL의 첫 번째 호스트 이름에 연결을 시도합니다. 그러나 첫 번째 호스트 이름을 사용할 수 없는 경우 클라이언트는 연결 URL의 다음 호스트 이름에 자동으로 연결됩니다.

비HTTP 연결의 경우:

  • 클라이언트는 연결 URL의 일부로 포트 번호(예: 포트 443)를 명시적으로 지정해야 합니다.
  • 단방향 TLS의 경우 클라이언트는 연결 URL의 일부로 신뢰 저장소의 경로와 해당 암호를 지정해야 합니다.
  • 양방향 TLS의 경우 클라이언트는 연결 URL의 일부로 저장소의 경로와 해당 암호를 지정해야 합니다.

지원되는 메시징 프로토콜의 일부 클라이언트 연결 URL 예는 다음과 같습니다.

외부 코어 클라이언트, 단방향 TLS 사용

tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&trustStorePath=~/client.ts&trustStorePassword=<password>

참고

외부 Core 클라이언트가 브로커가 반환하는 토폴로지 정보를 사용할 수 없기 때문에 연결 URL에서 useTopologyForLoadBalancing 키는 명시적으로 false 로 설정됩니다. 이 키를 true 로 설정하거나 값을 지정하지 않으면 DEBUG 로그 메시지가 생성됩니다.

외부 코어 클라이언트, 양방향 TLS 사용

tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&keyStorePath=~/client.ks&keyStorePassword=<password> \
&trustStorePath=~/client.ts&trustStorePassword=<password>

외부 OpenECDHEre 클라이언트, 단방향 TLS 사용

ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"

# Also, specify the following JVM flags
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>

외부 OpenECDHEre 클라이언트, 양방향 TLS 사용

ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"

# Also, specify the following JVM flags
-Djavax.net.ssl.keyStore=~/client.ks -Djavax.net.ssl.keyStorePassword=<password> \
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>

외부 AMQP 클라이언트, 단방향 TLS 사용

amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>

외부 AMQP 클라이언트, 양방향 TLS 사용

amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.keyStoreLocation=~/client.ks&transport.keyStorePassword=<password> \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>

4.8.4.3. NodePort를 사용하여 브로커에 연결

경로를 사용하는 대신 OpenShift 관리자는 OpenShift 외부의 클라이언트에서 브로커 포드에 연결하도록 NodePort를 구성할 수 있습니다. NodePort는 브로커에 대해 구성된 어셉터에 의해 지정된 프로토콜별 포트 중 하나에 매핑되어야 합니다.

기본적으로 NodePort는 30000~32767 범위에 있으므로 NodePort가 일반적으로 브로커 Pod에서 의도한 포트와 일치하지 않습니다.

NodePort를 통해 OpenShift 외부의 클라이언트에서 브로커에 연결하려면 < protocol > :// <ocp_node_ip> : <node_ port_number > 형식으로 URL을 지정합니다.

4.8.4.4. 미정형 서브스크립션 대기열 또는 응답/요청 대기열이 있는 경우 클라이언트 연결을 로드 밸런싱하는 경고

조정된 서브스크립션

장악한 서브스크립션은 브로커의 큐로 표현되며, 장엄한 구독자가 먼저 브로커에 연결될 때 생성됩니다. 이 큐가 존재하며 클라이언트가 구독 해제될 때까지 메시지를 수신합니다. 클라이언트가 다른 브로커에 다시 연결되면 해당 브로커에서 또 다른 안정된 서브스크립션 큐가 생성됩니다. 이로 인해 다음 문제가 발생할 수 있습니다.

문제완화 방법

메시지는 원래 서브스크립션 큐에 포함될 수 있습니다.

메시지 재배포가 활성화되었는지 확인합니다. 자세한 내용은 메시지 재배포 활성화를 참조하십시오.

다른 메시지가 라우팅될 때 메시지 재배포 중 창이 있으므로 잘못된 순서로 메시지가 수신될 수 있습니다.

없음.

클라이언트가 구독을 취소하면 마지막으로 연결된 브로커에서만 큐를 삭제합니다. 즉, 다른 대기열은 여전히 존재하며 메시지를 수신할 수 있습니다.

구독 해제된 클라이언트에 대해 존재할 수 있는 다른 빈 큐를 삭제하려면 다음 속성을 둘 다 구성합니다.

큐에 메시지가 없는 경우에만 큐를 삭제할 수 있도록 auto-delete-queues-message-count 속성을 0 으로 설정합니다. 지정된 시간(밀리초)에 사용되지 않은 메시지가 없는 큐를 삭제하도록 auto-delete-queues-delay 속성을 설정합니다.

자세한 내용은 주소 및 큐의 자동 생성 및 삭제 구성을 참조하십시오.

요청/응답 대기열

JMS Producer에서 임시 응답 대기열을 생성하면 큐가 브로커에서 생성됩니다. 작업 대기열에서 소비하고 임시 대기열에 응답하는 클라이언트가 다른 브로커에 연결된 경우 다음 문제가 발생할 수 있습니다.

문제완화 방법

클라이언트가 연결된 브로커에 응답 대기열이 없으므로 클라이언트는 오류를 생성할 수 있습니다.

auto-create-queues 속성이 true 로 설정되어 있는지 확인합니다. 자세한 내용은 주소 및 큐의 자동 생성 및 삭제 구성을 참조하십시오.

작업 큐로 전송된 메시지는 배포되지 않을 수 있습니다.

message-load-balancing 속성을 ON-DEMAND 로 설정하여 필요에 따라 메시지의 부하를 분산시킵니다. 또한 메시지 재배포가 활성화되어 있는지 확인합니다. 자세한 내용은 메시지 재배포 활성화를 참조하십시오.

추가 리소스

  • OpenShift 클러스터 외부에서 클러스터에서 실행되는 서비스와 통신하는 데 경로 및 NodePort와 같은 방법을 사용하는 방법에 대한 자세한 내용은 다음을 참조하십시오.