AMQ Broker 구성
보다 포괄적 수용을 위한 오픈 소스 용어 교체 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.
1장. 개요 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker 구성 파일은 브로커 인스턴스의 중요한 설정을 정의합니다. 브로커의 구성 파일을 편집하여 브로커가 환경에서 작동하는 방식을 제어할 수 있습니다.
1.1. AMQ Broker 구성 파일 및 위치 링크 복사링크가 클립보드에 복사되었습니다!
모든 브로커 구성 파일은 < broker_instance_dir> /etc 에 저장됩니다. 이러한 구성 파일에서 설정을 편집하여 브로커를 구성할 수 있습니다.
각 브로커 인스턴스는 다음 구성 파일을 사용합니다.
broker.xml- 기본 구성 파일입니다. 이 파일을 사용하여 네트워크 연결, 보안 설정, 메시지 주소 등과 같은 브로커의 대부분의 측면을 구성합니다.
bootstrap.xml-
AMQ Broker에서 브로커 인스턴스를 시작하는 데 사용하는 파일입니다. 이를 사용하여
broker.xml의 위치를 변경하고, 웹 서버를 구성하며, 일부 보안 설정을 설정합니다. logging.properties- 이 파일을 사용하여 broker 인스턴스에 대한 로깅 속성을 설정합니다.
artemis.profile- 이 파일을 사용하여 broker 인스턴스가 실행되는 동안 사용되는 환경 변수를 설정합니다.
login.config,artemis-users.properties,artemis-roles.properties- 보안 관련 파일 이러한 파일을 사용하여 broker 인스턴스에 대한 사용자 액세스에 대한 인증을 설정합니다.
1.2. 기본 브로커 구성 이해 링크 복사링크가 클립보드에 복사되었습니다!
broker.xml 구성 파일을 편집하여 대부분의 브로커 기능을 구성합니다. 이 파일에는 브로커를 시작하고 작동하기에 충분한 기본 설정이 포함되어 있습니다. 그러나 기본 설정 중 일부를 변경하고 새 설정을 추가하여 환경에 대한 브로커를 구성해야 할 수도 있습니다.
기본적으로 broker.xml 에는 다음 기능에 대한 기본 설정이 포함되어 있습니다.
- 메시지 지속성
- 수락자
- 보안
- 메시지 주소
기본 메시지 지속성 설정
기본적으로 AMQ Broker 지속성은 디스크의 파일 세트로 구성된 추가 전용 파일 저널을 사용합니다. 저널은 메시지, 트랜잭션 및 기타 정보를 저장합니다.
기본 어셉터 설정
브로커는 어셉터 구성 요소를 사용하여 클라이언트가 연결을 수행하는 데 사용할 수 있는 포트 및 프로토콜을 정의하여 들어오는 클라이언트 연결을 수신합니다. 기본적으로 AMQ Broker에는 지원되는 각 메시징 프로토콜에 대한 어셉터가 포함되어 있습니다.
기본 보안 설정
AMQ Broker에는 주소에 따라 큐에 보안을 적용하기 위한 유연한 역할 기반 보안 모델이 포함되어 있습니다. 기본 구성은 와일드카드를 사용하여 모든 주소에 amq 역할을 적용합니다(숫자 기호 #).
기본 메시지 주소 설정
AMQ Broker에는 생성된 대기열 또는 항목에 적용할 기본 구성 설정 세트를 설정하는 기본 주소가 포함되어 있습니다.
또한 기본 구성은 두 개의 큐를 정의합니다. DLQ (Dead Letter Queue)는 알려진 대상 없이 도달한 메시지를 처리하고 Expiry Queue 는 만료가 지난 메시지를 보유하고 있으므로 원래 대상으로 라우팅해서는 안 됩니다.
1.3. 설정 업데이트 다시 로드 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 브로커는 구성 파일의 변경 사항을 5000밀리초 마다 확인합니다. 브로커가 구성 파일의 "최근 수정" 타임 스탬프의 변경을 감지하면 브로커는 구성 변경이 발생했음을 결정합니다. 이 경우 브로커는 구성 파일을 다시 로드하여 변경 사항을 활성화합니다.
브로커가 broker.xml 구성 파일을 다시 로드하면 다음 모듈이 다시 로드됩니다.
주소 설정 및 대기열
구성 파일이 다시 로드되면 주소 설정에서 구성 파일에서 삭제된 주소 및 큐를 처리하는 방법을 결정합니다.
config-delete-addresses및config-delete-queues속성을 사용하여 이 값을 설정할 수 있습니다. 자세한 내용은 부록 B. 주소 설정 Configurationknative의 내용을 참조하십시오.보안 설정
기존의 수락자의 SSL/TLS 키 저장소 및 신뢰 저장소를 다시 로드하여 기존 클라이언트에 영향을 주지 않고 새 인증서를 설정할 수 있습니다. 연결된 클라이언트(이전 또는 다양한 인증서)도 계속해서 메시지를 보내고 받을 수 있습니다.
crlPath 매개변수를 사용하여 구성된 인증서 취소 목록 파일도 다시 로드할 수 있습니다.
diverts
구성 다시 로드 시 추가한 새 부팅이 배포됩니다. 그러나 구성에서 반전하거나 <
divert> 요소 내의 하위 요소로의 변경 사항은 브로커를 다시 시작할 때까지 적용되지 않습니다.
다음 절차에서는 브로커가 broker.xml 구성 파일에 대한 변경을 확인하는 간격을 변경하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
core> 요소 내에서 <configuration-file-refresh-period> 요소를 추가하고 새로 고침 기간(밀리초)을 설정합니다.이 예에서는 구성 새로 고침 기간을 60000밀리초로 설정합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
어떤 이유로든 구성 파일에 액세스할 수 없는 경우 Management API 또는 콘솔을 사용하여 구성 파일을 다시 로드할 수도 있습니다. 구성 파일은 ActiveMQServerControl 의 관리 작업 reloadConfigurationFile() 을 사용하여 다시 로드할 수 있습니다( ObjectName org.apache.activemq.artemis:broker="BROKER_NAME" 또는 리소스 이름 서버)
추가 리소스
- 관리 API 사용 방법에 대한 자세한 내용은 AMQ Broker 관리에서 관리 API 사용을 참조하십시오.
1.4. 브로커 구성 파일 수정 링크 복사링크가 클립보드에 복사되었습니다!
공통 구성 설정을 공유하는 브로커가 여러 개인 경우 별도의 파일에 공통 구성을 정의한 다음 각 브로커의 broker.xml 구성 파일에 이러한 파일을 포함시킬 수 있습니다.
브로커 간에 공유할 수 있는 가장 일반적인 구성 설정은 다음과 같습니다.
- 주소
- 주소 설정
- 보안 설정
절차
공유하려는 각
broker.xml섹션에 대해 별도의 XML 파일을 생성합니다.각 XML 파일에는
broker.xml의 단일 섹션만 포함할 수 있습니다(예: 주소 또는 주소 설정, 둘 다는 아님). 최상위 수준 요소는 요소 네임스페이스(xmlns="urn:activemq:core")도 정의해야 합니다.이 예에서는
my-security-settings.xml에 정의된 보안 설정 구성을 보여줍니다.my-security-settings.xml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
공통 구성 설정을 사용해야 하는 각 브로커에 대해 <
broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 개설한 각
broker.xml파일에 대해 다음을 수행하십시오.broker.xml시작 부분에 있는 <configuration> 요소에서 다음 행이 표시되는지 확인합니다.xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xi="http://www.w3.org/2001/XInclude"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 공유 구성 설정이 포함된 각 XML 파일에 대해 XML 포함을 추가합니다.
이 예제에는
my-security-settings.xml파일이 포함되어 있습니다.broker.xml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 필요한 경우
broker.xml의 유효성을 검사하여 XML이 스키마에 대해 유효한지 확인합니다.XML 검증기를 사용할 수 있습니다. 이 예제에서는
xmllint를 사용하여artemis-server.xsl스키마에 대해broker.xml의 유효성을 검사합니다.xmllint --noout --xinclude --schema /opt/redhat/amq-broker/amq-broker-7.2.0/schema/artemis-server.xsd /var/opt/amq-broker/mybroker/etc/broker.xml /var/opt/amq-broker/mybroker/etc/broker.xml validates
$ xmllint --noout --xinclude --schema /opt/redhat/amq-broker/amq-broker-7.2.0/schema/artemis-server.xsd /var/opt/amq-broker/mybroker/etc/broker.xml /var/opt/amq-broker/mybroker/etc/broker.xml validatesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 리소스
- XML 포함(XIncludes)에 대한 자세한 내용은 https://www.w3.org/TR/xinclude/ 을 참조하십시오.
1.4.1. 모듈식 구성 파일 다시 로드 링크 복사링크가 클립보드에 복사되었습니다!
브로커가 구성 변경 사항(config -file-refresh-period로 지정된 빈도에 따라) 주기적으로 확인하면 xi:include 를 통해 broker.xml 구성 파일에 포함된 구성 파일에 대한 변경 사항을 자동으로 감지하지 않습니다. 예를 들어 broker.xml 에 my-address-settings.xml 이 포함되어 있고 my-address-settings.xml 설정을 변경하는 경우 브로커는 my-address-settings.xml 의 변경 사항을 자동으로 탐지하고 구성을 다시 로드하지 않습니다.
broker.xml 구성 파일 및 여기에 포함된 수정된 구성 파일을 강제로 다시 로드하려면 broker.xml 구성 파일의 "최종 수정됨" 타임 스탬프가 변경되었는지 확인해야 합니다. 표준 Linux touch 명령을 사용하여 다른 변경없이 broker.xml 의 마지막 수정 타임 스탬프를 업데이트할 수 있습니다. 예를 들면 다음과 같습니다.
touch -m <broker_instance_dir>/etc/broker.xml
$ touch -m <broker_instance_dir>/etc/broker.xml
또는 관리 API를 사용하여 브로커를 강제로 다시 로드할 수 있습니다. 구성 파일은 ActiveMQServerControl 의 관리 작업 reloadConfigurationFile() 을 사용하여 다시 로드할 수 있습니다( ObjectName org.apache.activemq.artemis:broker="BROKER_NAME" 또는 리소스 이름 서버)
추가 리소스
- 관리 API 사용 방법에 대한 자세한 내용은 AMQ Broker 관리에서 관리 API 사용을 참조하십시오.
1.4.2. 외부 XML 엔티티(XXE) 처리 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
broker.xml 파일에 포함된 별도의 파일에 브로커 구성을 모듈화하지 않으려면 XXE 처리를 비활성화하여 XXE 보안 취약점으로부터 AMQ 브로커를 보호할 수 있습니다. 모듈식 브로커 구성이 없는 경우 XXE 처리를 비활성화하는 것이 좋습니다.
절차
-
<
;broker_instance_dir>/etc/artemis.profile파일을 엽니다. Java 시스템 인수의
JAVA_ARGS목록에 새 인수-Dartemis.disableXxe를 추가합니다.-Dartemis.disableXxe=true
-Dartemis.disableXxe=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
artemis.profile파일을 저장합니다.
1.5. 문서 규칙 링크 복사링크가 클립보드에 복사되었습니다!
이 문서에서는 sudo 명령, 파일 경로 및 대체 가능한 값에 대해 다음 규칙을 사용합니다.
sudo 명령
이 문서에서는 root 권한이 필요한 모든 명령에 sudo 를 사용합니다. sudo 를 사용할 때는 변경 사항이 전체 시스템에 영향을 줄 수 있으므로 항상 주의해야 합니다.
sudo 사용에 대한 자세한 내용은 sudo 액세스 관리를 참조하십시오.
이 문서에서 파일 경로 사용 정보
이 문서에서 모든 파일 경로는 Linux, UNIX 및 유사한 운영 체제(예: /home/.. )에 유효합니다. Microsoft Windows를 사용하는 경우 동등한 Microsoft Windows 경로(예 : C:\Users\.. )를 사용해야 합니다.
교체 가능한 값
이 문서에서는 환경에 고유한 값으로 교체해야 하는 대체 가능한 값을 사용하는 경우가 있습니다. 교체할 수 있는 값은 소문자로 묶고(< >), italics 및 monospace 글꼴을 사용하여 스타일을 지정합니다. 여러 단어가 밑줄(_)으로 구분됩니다.
예를 들어 다음 명령에서 < install_dir>을 사용자 고유의 디렉터리 이름으로 바꿉니다.
<install_dir>/bin/artemis create mybroker
$ <install_dir>/bin/artemis create mybroker
2장. 네트워크 연결에서 어셉터 및 커넥터 구성 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에 사용되는 연결 유형은 네트워크 연결과 VM 내 연결의 두 가지 유형이 있습니다. 네트워크 연결은 두 당사자가 동일한 서버 또는 물리적으로 원격에 관계없이 다른 가상 시스템에 있을 때 사용됩니다. 애플리케이션 또는 서버든 클라이언트가 브로커와 동일한 가상 머신에 있을 때 In-VM 연결이 사용됩니다.
네트워크 연결에서는 Netty 를 사용합니다. Netty는 Java IO 또는 NIO, TCP 소켓, SSL/TLS 또는 HTTP 또는 HTTPS를 통한 터널링 등 다양한 방법으로 네트워크 연결을 구성할 수 있는 고성능 하위 수준의 네트워크 라이브러리입니다. 또한 Netty는 모든 메시징 프로토콜에 단일 포트를 사용할 수 있습니다. 브로커는 사용 중인 프로토콜을 자동으로 감지하고 수신 메시지를 추가 처리를 위한 적절한 처리기로 보냅니다.
네트워크 연결의 URI에 따라 유형이 결정됩니다. 예를 들어 URI에서 vm 를 지정하면 VM 내 연결이 생성됩니다.
<acceptor name="in-vm-example">vm://0</acceptor>
<acceptor name="in-vm-example">vm://0</acceptor>
또는 URI에 tcp 를 지정하면 네트워크 연결이 생성됩니다. 예를 들면 다음과 같습니다.
<acceptor name="network-example">tcp://localhost:61617</acceptor>
<acceptor name="network-example">tcp://localhost:61617</acceptor>
다음 섹션에서는 네트워크 연결 및 VM 내 연결에 필요한 두 가지 중요한 구성 요소인 어셉터 및 커넥터 에 대해 설명합니다. 이 섹션에서는 TCP, HTTP 및 SSL/TLS 네트워크 연결 및 인-VM 연결에 대한 어셉터 및 커넥터를 구성하는 방법을 보여줍니다.
2.1. 수락자 정보 링크 복사링크가 클립보드에 복사되었습니다!
수락자는 브로커에 대한 연결을 만드는 방법을 정의합니다. 각 어셉터는 클라이언트가 연결하는 데 사용할 수 있는 포트 및 프로토콜을 정의합니다. 간단한 어셉터 구성은 다음과 같습니다.
<acceptors> <acceptor name="example-acceptor">tcp://localhost:61617</acceptor> </acceptors>
<acceptors>
<acceptor name="example-acceptor">tcp://localhost:61617</acceptor>
</acceptors>
브로커 구성에 정의된 각 어셉터 요소는 단일 어셉터 요소에 포함됩니다. 브로커에 대해 정의할 수 있는 수락자 수에 대한 상한은 없습니다. 기본적으로 AMQ Broker에는 다음과 같이 지원되는 각 메시징 프로토콜에 대한 어셉터가 포함됩니다.
2.2. 수락자 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 수락자를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. acceptors요소에서 새acceptor요소를 추가합니다. 프로토콜을 지정하고 브로커에 포트를 지정합니다. 예를 들면 다음과 같습니다.<acceptors> <acceptor name="example-acceptor">tcp://localhost:61617</acceptor> </acceptors>
<acceptors> <acceptor name="example-acceptor">tcp://localhost:61617</acceptor> </acceptors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 앞의 예제에서는 TCP 프로토콜에 대한 수락자를 정의합니다. 브로커는 TCP를 사용하는 클라이언트 연결에 대해 포트 61617에서 수신 대기합니다.
수락자에 대해 정의된 URI에 키-값 쌍을 추가합니다. 여러 키-값 쌍을 분리하려면 ;(;)를 사용합니다.
예를 들면 다음과 같습니다.<acceptor name="example-acceptor">tcp://localhost:61617?sslEnabled=true;key-store-path=</path/to/key_store></acceptor>
<acceptor name="example-acceptor">tcp://localhost:61617?sslEnabled=true;key-store-path=</path/to/key_store></acceptor>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이제 구성에서 TLS/SSL을 사용하고 필요한 키 저장소의 경로를 정의하는 어셉터를 정의합니다.
추가 리소스
- 어셉터 및 커넥터에 사용 가능한 구성 옵션에 대한 자세한 내용은 부록 A. 어셉터 및 커넥터 구성 매개변수 을 참조하십시오.
2.3. 커넥터 정보 링크 복사링크가 클립보드에 복사되었습니다!
어셉터는 브로커가 연결을 수락하는 방법을 정의하지만 커넥터는 클라이언트가 브로커에 연결하는 방법을 정의합니다.
브로커 자체가 클라이언트 역할을 할 때 커넥터가 브로커에 구성됩니다. 예를 들면 다음과 같습니다.
- 브로커가 다른 브로커에 연결될 때
- 브로커가 클러스터에 참여하는 경우
간단한 커넥터 구성은 다음과 같습니다.
<connectors> <connector name="example-connector">tcp://localhost:61617</connector> </connectors>
<connectors>
<connector name="example-connector">tcp://localhost:61617</connector>
</connectors>
2.4. 커넥터 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 커넥터를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. connector
요소에서새connector요소를 추가합니다. 프로토콜을 지정하고 브로커에 포트를 지정합니다. 예를 들면 다음과 같습니다.<connectors> <connector name="example-connector">tcp://localhost:61617</connector> </connectors>
<connectors> <connector name="example-connector">tcp://localhost:61617</connector> </connectors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 앞의 예제에서는 TCP 프로토콜에 대한 커넥터를 정의합니다. 클라이언트는 TCP 프로토콜을 사용하여 커넥터 구성을 사용하여 포트 61617의 브로커에 연결할 수 있습니다. 브로커 자체는 이 커넥터를 발신 연결에 사용할 수도 있습니다.
커넥터에 대해 정의된 URI에 키-값 쌍을 추가합니다. 여러 키-값 쌍을 분리하려면 ;(;)를 사용합니다.
예를 들면 다음과 같습니다.<connector name="example-connector">tcp://localhost:61616?tcpNoDelay=true</connector>
<connector name="example-connector">tcp://localhost:61616?tcpNoDelay=true</connector>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이제 구성에서
tcpNoDelay속성 값을true로 설정하는 커넥터를 정의합니다. 이 속성의 값을true로 설정하면 연결에 대한 Nagle 알고리즘이 해제됩니다. Nagle의 알고리즘은 작은 데이터 패킷의 전송을 지연시키고 이러한 패킷을 큰 패킷으로 통합함으로써 TCP 연결의 효율성을 개선하는 데 사용되는 알고리즘입니다.
추가 리소스
- 어셉터 및 커넥터에 사용 가능한 구성 옵션에 대한 자세한 내용은 부록 A. 어셉터 및 커넥터 구성 매개변수 을 참조하십시오.
- AMQ Core Protocol JMS 클라이언트에서 브로커 커넥터를 구성하는 방법을 알아보려면 AMQ Core Protocol JMS 문서에서 브로커 커넥터 구성 을 참조하십시오.
2.5. TCP 연결 구성 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker는 Netty를 사용하여 Java IO 또는 새로운 비차단 Java NIO 차단을 사용하도록 구성할 수 있는 기본 암호화되지 않은 TCP 기반 연결을 제공합니다. 많은 동시 연결을 통해 더 나은 확장성을 위해 Java NIO가 선호됩니다. 그러나 이전 IO를 사용하면 수천 개의 동시 연결을 지원하는 것에 대한 우려가 줄어들 때 NIO보다 더 나은 대기 시간을 제공할 수 있습니다.
신뢰할 수 없는 네트워크에서 연결을 실행하는 경우 TCP 네트워크 연결은 암호화되지 않습니다. 보안이 우선순위인 경우 SSL 또는 HTTPS 구성을 사용하여 이 연결을 통해 전송된 메시지를 암호화하는 것이 좋습니다. 자세한 내용은 5.1절. “연결 보안”를 참조하십시오.
TCP 연결을 사용하면 클라이언트가 모든 연결이 시작됩니다. 브로커는 클라이언트에 대한 연결을 시작하지 않습니다. 이는 방화벽 정책에서 제대로 작동하여 한 방향에서 연결을 강제로 시작합니다.
TCP 연결의 경우 커넥터 URI의 호스트 및 포트는 연결에 사용되는 주소를 정의합니다.
다음 예제에서는 TCP 연결을 구성하는 방법을 보여줍니다.
사전 요구 사항
어셉터 및 커넥터 구성에 대해 잘 알고 있어야 합니다. 자세한 내용은 다음을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 새 어셉터를 추가하거나 기존 작업자를 수정합니다. 연결 URI에서
tcp를 프로토콜로 지정합니다. IP 주소 또는 호스트 이름과 브로커의 포트를 모두 포함합니다. 예를 들면 다음과 같습니다.<acceptors> <acceptor name="tcp-acceptor">tcp://10.10.10.1:61617</acceptor> ... </acceptors>
<acceptors> <acceptor name="tcp-acceptor">tcp://10.10.10.1:61617</acceptor> ... </acceptors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 예제를 기반으로 브로커는 IP 주소
10.10.10.1에서 포트61617에 연결하는 클라이언트로부터 TCP 통신을 허용합니다.(선택 사항) 유사한 방식으로 커넥터를 구성할 수 있습니다. 예를 들면 다음과 같습니다.
<connectors> <connector name="tcp-connector">tcp://10.10.10.2:61617</connector> ... </connectors>
<connectors> <connector name="tcp-connector">tcp://10.10.10.2:61617</connector> ... </connectors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 예제의 커넥터는 지정된 IP 및 포트
10.10.10.2:61617에 TCP 연결을 수행할 때 클라이언트 또는 브로커 자체에서 참조합니다.
추가 리소스
- TCP 연결에 사용 가능한 구성 옵션에 대한 자세한 내용은 부록 A. 어셉터 및 커넥터 구성 매개변수 을 참조하십시오.
2.6. HTTP 연결 구성 링크 복사링크가 클립보드에 복사되었습니다!
HTTP 연결은 HTTP 프로토콜을 통해 패킷을 터널링하고 방화벽이 HTTP 트래픽만 허용하는 시나리오에서 유용합니다. AMQ Broker는 HTTP가 사용 중인지 자동으로 감지하므로 HTTP에 대한 네트워크 연결 구성은 TCP에 대한 연결을 구성하는 것과 동일합니다.
사전 요구 사항
어셉터 및 커넥터 구성에 대해 잘 알고 있어야 합니다. 자세한 내용은 다음을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 새 어셉터를 추가하거나 기존 작업자를 수정합니다. 연결 URI에서
tcp를 프로토콜로 지정합니다. IP 주소 또는 호스트 이름과 브로커의 포트를 모두 포함합니다. 예를 들면 다음과 같습니다.<acceptors> <acceptor name="http-acceptor">tcp://10.10.10.1:80</acceptor> ... </acceptors>
<acceptors> <acceptor name="http-acceptor">tcp://10.10.10.1:80</acceptor> ... </acceptors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 예제를 기반으로 브로커는 IP 주소
10.10.10.1에서 포트80에 연결하는 클라이언트로부터 HTTP 통신을 허용합니다. 브로커는 HTTP 프로토콜이 사용 중임을 자동으로 감지하고 그에 따라 클라이언트와 통신합니다.(선택 사항) 유사한 방식으로 커넥터를 구성할 수 있습니다. 예를 들면 다음과 같습니다.
<connectors> <connector name="http-connector">tcp://10.10.10.2:80</connector> ... </connectors>
<connectors> <connector name="http-connector">tcp://10.10.10.2:80</connector> ... </connectors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 예에 표시된 커넥터를 사용하여 브로커는 IP 주소
10.10.10.2의 포트80에 아웃바운드 HTTP 연결을 생성합니다.
추가 리소스
- HTTP 연결에서는 TCP와 동일한 구성 매개 변수를 사용하지만 일부 자체도 있습니다. HTTP 연결에 사용 가능한 모든 구성 옵션에 대한 자세한 내용은 부록 A. 어셉터 및 커넥터 구성 매개변수 을 참조하십시오.
-
HTTP 사용 방법을 보여주는 전체 작업 예제는 브로커 설치의 <
install_dir> /examples/features/standard/디렉터리에 있는http-transport예제를 참조하십시오.
2.7. 보안 네트워크 연결 구성 링크 복사링크가 클립보드에 복사되었습니다!
TLS/SSL을 사용하여 네트워크 연결을 보호할 수 있습니다. 자세한 내용은 5.1절. “연결 보안”의 내용을 참조하십시오.
2.8. VM 연결 구성 링크 복사링크가 클립보드에 복사되었습니다!
여러 브로커가 동일한 가상 머신에 공동 배치되는 경우 VM 내 연결을 사용할 수 있습니다(예: HA(고가용성) 구성의 일부로). VM 내 연결은 브로커와 동일한 JVM에서 실행되는 로컬 클라이언트에서도 사용할 수 있습니다.
사전 요구 사항
어셉터 및 커넥터 구성에 대해 잘 알고 있어야 합니다. 자세한 내용은 다음을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 새 어셉터를 추가하거나 기존 작업자를 수정합니다. 연결 URI에서
vm를 프로토콜로 지정합니다. 예를 들면 다음과 같습니다.<acceptors> <acceptor name="in-vm-acceptor">vm://0</acceptor> ... </acceptors>
<acceptors> <acceptor name="in-vm-acceptor">vm://0</acceptor> ... </acceptors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 예제의 어셉터에 따라 브로커는 ID가
0인 브로커의 연결을 허용합니다. 다른 브로커가 동일한 가상 머신에서 실행 중이어야 합니다.(선택 사항) 유사한 방식으로 커넥터를 구성할 수 있습니다. 예를 들면 다음과 같습니다.
<connectors> <connector name="in-vm-connector">vm://0</connector> ... </connectors>
<connectors> <connector name="in-vm-connector">vm://0</connector> ... </connectors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 예제의 커넥터는 클라이언트가 클라이언트와 동일한 가상 시스템에서 실행되는 ID가
0인 브로커에 대한 인-VM 연결을 설정하는 방법을 정의합니다. 클라이언트는 애플리케이션 또는 다른 브로커일 수 있습니다.
3장. 네트워크 연결에서 메시징 프로토콜 구성 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에는 플러그형 프로토콜이 있으므로 네트워크 연결에 대해 하나 이상의 프로토콜을 쉽게 활성화할 수 있습니다.
브로커는 다음 프로토콜을 지원합니다.
위의 프로토콜 외에도 브로커는 "Core"라는 자체 네이티브 프로토콜도 지원합니다. 이 프로토콜의 이전 버전은 "HornetQ"로 알려졌으며 Red Hat JBoss Enterprise Application Platform에서 사용되었습니다.
3.1. 메시징 프로토콜을 사용하도록 네트워크 연결 구성 링크 복사링크가 클립보드에 복사되었습니다!
프로토콜을 네트워크 연결과 연결하려면 먼저 프로토콜을 연결해야 합니다. (네트워크 연결 생성 및 구성 방법에 대한 자세한 내용은 2장. 네트워크 연결에서 어셉터 및 커넥터 구성 을 참조하십시오.) <broker _instance_dir> /etc/broker.xml 에 있는 기본 구성에는 이미 정의된 여러 연결이 포함되어 있습니다. 편의를 위해 AMQ Broker에는 지원되는 각 프로토콜에 대한 어셉터와 모든 프로토콜을 지원하는 기본 수락자가 포함됩니다.
기본 수락자 개요
다음은 broker.xml 구성 파일에 기본적으로 포함된 어셉터입니다.
지정된 네트워크 바인딩에서 프로토콜을 활성화하는 유일한 요구 사항은 수락자의 URI에 protocols 매개변수를 추가하는 것입니다. 매개변수 값은 쉼표로 구분된 프로토콜 이름 목록이어야 합니다. protocol 매개변수가 URI에서 생략되면 모든 프로토콜이 활성화됩니다.
예를 들어 AMQP 프로토콜을 사용하여 포트 3232에서 메시지를 수신하기 위한 어셉터를 생성하려면 다음 단계를 따르십시오.
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. -
<
acceptors> 스탠자에 다음 행을 추가합니다.
<acceptor name="ampq">tcp://0.0.0.0:3232?protocols=AMQP</acceptor>
<acceptor name="ampq">tcp://0.0.0.0:3232?protocols=AMQP</acceptor>
기본 어셉터의 추가 매개변수
최소 허용 구성에서는 프로토콜을 연결 URI의 일부로 지정합니다. 그러나 broker.xml 구성 파일의 기본 어셉터에는 몇 가지 추가 매개 변수가 구성됩니다. 다음 표에서는 기본 어셉터에 대해 구성된 추가 매개변수에 대해 자세히 설명합니다.
| acceptor(s) | 매개변수 | 설명 |
|---|---|---|
| All-protocols acceptor AMQP STOMP | tcpSendBufferSize |
TCP 전송 버퍼의 크기(바이트)입니다. 기본값은 |
| tcpReceiveBufferSize |
TCP 수신 버퍼의 크기(바이트)입니다. 기본값은 TCP 버퍼 크기는 네트워크의 대역폭 및 대기 시간에 따라 조정되어야 합니다. 요약하면 TCP 전송/수신 버퍼 크기는 다음과 같이 계산되어야 합니다. buffer_size = 대역폭 * RTT.
여기서 대역폭은 초당 바이트 수이고 RTT(네트워크 왕복 시간)는 초 단위입니다. RTT는 빠른 네트워크의 경우 기본값에서 버퍼 크기를 늘릴 수 있습니다. | |
| All-protocols acceptor AMQP STOMP HornetQ MQTT | useEpoll |
이를 지원하는 시스템(Linux)을 사용하는 경우 Netty epoll을 사용하십시오. Netty 네이티브 전송은 NIO 전송보다 우수한 성능을 제공합니다. 이 옵션의 기본값은 |
| All-protocols acceptor AMQP | amqpCredits |
총 메시지 크기에 관계없이 AMQP 생산자가 보낼 수 있는 최대 메시지 수입니다. 기본값은 AMQP 메시지를 차단하는 데 단위를 사용하는 방법에 대한 자세한 내용은 7.3.2절. “AMQP 생산자 차단” 을 참조하십시오. |
| All-protocols acceptor AMQP | amqpLowCredits |
브로커가 프로듀서 단위를 재정의하는 임계값을 낮춥니다. 기본값은 AMQP 메시지를 차단하는 데 단위를 사용하는 방법에 대한 자세한 내용은 7.3.2절. “AMQP 생산자 차단” 을 참조하십시오. |
| HornetQ 호환성 허용자 | anycastPrefix |
클라이언트가 클라이언트가 주소에 연결할 때 라우팅 유형을 지정할 수 있도록 접두사를 구성하는 방법에 대한 자세한 내용은 4.6절. “어셉터 구성에 라우팅 유형 추가” 을 참조하십시오. |
| multicastPrefix |
클라이언트가 클라이언트가 주소에 연결할 때 라우팅 유형을 지정할 수 있도록 접두사를 구성하는 방법에 대한 자세한 내용은 4.6절. “어셉터 구성에 라우팅 유형 추가” 을 참조하십시오. |
추가 리소스
- Netty 네트워크 연결에 대해 구성할 수 있는 다른 매개변수에 대한 자세한 내용은 부록 A. 어셉터 및 커넥터 구성 매개변수 을 참조하십시오.
3.2. 네트워크 연결에서 AMQP 사용 링크 복사링크가 클립보드에 복사되었습니다!
브로커는 AMQP 1.0 사양을 지원합니다. AMQP 링크는 소스와 대상, 즉 클라이언트와 브로커 간의 메시지에 대한 단방향 프로토콜입니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. -
다음 예와 같이 AMQP 값이 AMQP인
protocols매개변수를 포함하여AMQP클라이언트를 수신하도록어셉터를 추가하거나 구성합니다.
<acceptors> <acceptor name="amqp-acceptor">tcp://localhost:5672?protocols=AMQP</acceptor> ... </acceptors>
<acceptors>
<acceptor name="amqp-acceptor">tcp://localhost:5672?protocols=AMQP</acceptor>
...
</acceptors>
이전 예에서 브로커는 기본 AMQP 포트인 포트 5672에서 AMQP 1.0 클라이언트를 허용합니다.
AMQP 링크에는 발신자와 수신자라는 두 개의 엔드포인트가 있습니다. 발신자가 메시지를 전송하면 브로커는 메시지를 내부 형식으로 변환하므로 브로커의 대상으로 전달할 수 있습니다. 수신자는 브로커의 대상에 연결하고 메시지를 전달되기 전에 AMQP로 다시 변환합니다.
AMQP 링크가 동적이면 임시 대기열이 생성되고 원격 소스 또는 원격 대상 주소가 임시 대기열의 이름으로 설정됩니다. 링크가 동적이지 않은 경우 큐에 원격 대상 또는 소스의 주소가 사용됩니다. 원격 대상 또는 소스가 없으면 예외가 전송됩니다.
링크 대상은 기본 세션을 트랜잭션으로 처리하여 롤백하거나 커밋하는 데 사용되는 Coordinator일 수도 있습니다.
AMQP를 사용하면 세션당 여러 트랜잭션( Amqp:multi-txns-per-ssn )을 사용할 수 있지만 현재 AMQ Broker 버전은 세션당 단일 트랜잭션만 지원합니다.
AMQP 내의 분산 트랜잭션(XA) 세부 정보는 사양의 1.0 버전에서 제공되지 않습니다. 환경에서 분산 트랜잭션을 지원해야 하는 경우 AMQ Core Protocol JMS를 사용하는 것이 좋습니다.
프로토콜 및 해당 기능에 대한 자세한 내용은 AMQP 1.0 사양을 참조하십시오.
3.2.1. AMQP 링크를 주제로 사용 링크 복사링크가 클립보드에 복사되었습니다!
JMS와 달리 AMQP 프로토콜에는 주제가 포함되어 있지 않습니다. 하지만 아직 AMQP 소비자 또는 수신자를 대기열의 소비자만이 아닌 서브스크립션으로 처리할 수 있습니다. 기본적으로 jms.topic. 접두사가 있는 주소에 연결된 수신 링크는 서브스크립션으로 처리되고 서브스크립션 큐가 생성됩니다. 구독 큐는 다음 표에서 캡처된 대로 Terminus Durability가 구성된 방법에 따라 오래되거나 변동성으로 생성됩니다.
| 멀티 캐스트 전용 큐에 대해 이러한 종류의 서브스크립션을 생성하려면 다음을 수행합니다. | Terminus Durability를 이로 설정합니다. |
|---|---|
| 용어집 |
|
| 양도할 수 없음 |
|
영구성 대기열의 이름은 컨테이너 ID와 링크 이름(예: my-container-id:my-link-name )으로 구성됩니다.
AMQ Broker는 qpid-jms 클라이언트도 지원하며 해당 주소에 사용된 접두사와 관계없이 주제 사용을 준수합니다.
3.2.2. AMQP 보안 구성 링크 복사링크가 클립보드에 복사되었습니다!
브로커는 AMQP SASL 인증을 지원합니다. 브로커에서 SASL 기반 인증을 구성하는 방법에 대한 자세한 내용은 보안을 참조하십시오. ???
3.3. 네트워크 연결에서 MQTT 사용 링크 복사링크가 클립보드에 복사되었습니다!
브로커는 MQTT v3.1.1 및 v5.0 (이전 v3.1 코드 메시지 형식도 지원)을 지원합니다. MQTT는 경량의 클라이언트, 서버, 게시/구독 메시징 프로토콜입니다. MQTT는 메시징 오버헤드 및 네트워크 트래픽과 클라이언트의 코드 풋프린트를 줄입니다. 이러한 이유로 MQTT는 센서 및 작동기와 같은 제한된 장치에 이상적으로 적합하며, IoT(Internet of Things)의 사실상 표준 통신 프로토콜이 빠르게 되고 있습니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. - MQTT 프로토콜이 활성화된 어셉터를 추가합니다. 예를 들면 다음과 같습니다.
<acceptors> <acceptor name="mqtt">tcp://localhost:1883?protocols=MQTT</acceptor> ... </acceptors>
<acceptors>
<acceptor name="mqtt">tcp://localhost:1883?protocols=MQTT</acceptor>
...
</acceptors>
MQTT에는 다음과 같은 여러 유용한 기능이 제공됩니다.
- QoS (Quality of Service)
- 각 메시지는 연결된 서비스 품질을 정의할 수 있습니다. 브로커는 정의된 최고 수준의 서비스 수준에서 구독자에게 메시지를 전달하려고 합니다.
- 보존 메시지
특정 주소에 대해 메시지를 유지할 수 있습니다. 클라이언트가 연결되기 전에 보존 메시지가 전송된 경우에도 해당 주소에 대한 새 구독자는 다른 메시지보다 마지막 메시지보다 마지막 메시지보다 먼저 메시지를 수신합니다.
보존 메시지는
sys.mqtt.<topic name>이라는 큐에 저장되며 클라이언트가 보존 메시지를 삭제할 때까지 또는 메시지가 만료될 때까지 큐에 남아 있습니다. 큐가 비어 있으면 명시적으로 삭제할 때까지 큐가 제거되지 않습니다. 예를 들어 다음 구성은 큐를 삭제합니다.<address-setting match="$sys.mqtt.retain.#"> <auto-delete-queues>true</auto-delete-queues> <auto-delete-addresses>true</auto-delete-addresses> </address-setting>
<address-setting match="$sys.mqtt.retain.#"> <auto-delete-queues>true</auto-delete-queues> <auto-delete-addresses>true</auto-delete-addresses> </address-setting>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 와일드카드 서브스크립션
- MQTT 주소는 파일 시스템의 계층 구조와 유사합니다. 클라이언트는 특정 주제 또는 계층의 전체 분기를 구독할 수 있습니다.
- 메시지 표시
- 클라이언트는 연결 패킷의 일부로 "메시지"를 설정할 수 있습니다. 클라이언트가 비정상적으로 연결이 끊어지면 브로커는 메시지를 지정된 주소에 게시합니다. 다른 가입자는 메시지를 수신하고 그에 따라 대응할 수 있습니다.
MQTT 프로토콜에 대한 자세한 내용은 사양을 참조하십시오.
3.3.1. MQTT 속성 구성 링크 복사링크가 클립보드에 복사되었습니다!
MQTT 어셉터에 키-값 쌍을 추가하여 연결 속성을 구성할 수 있습니다. 예를 들면 다음과 같습니다.
<acceptors> <acceptor name="mqtt">tcp://localhost:1883?protocols=MQTT;receiveMaximum=50000;topicAliasMaximum=50000;maximumPacketSize;134217728; serverKeepAlive=30;closeMqttConnectionOnPublishAuthorizationFailure=false</acceptor> ... </acceptors>
<acceptors>
<acceptor name="mqtt">tcp://localhost:1883?protocols=MQTT;receiveMaximum=50000;topicAliasMaximum=50000;maximumPacketSize;134217728;
serverKeepAlive=30;closeMqttConnectionOnPublishAuthorizationFailure=false</acceptor>
...
</acceptors>
- receiveMaximum
-
브로커가 승인이 필요하기 전에 클라이언트에서 수신할 수 있는 최대 QoS 1 및 2 메시지 수를 지정하여 flow-control을 활성화합니다. 기본값은
65535입니다. 값-1은 클라이언트에서 브로커로의 흐름 제어를 비활성화합니다. 이 값은 값을 0으로 설정하는 것과 동일하지만 CONNACK 패킷의 크기를 줄입니다. - topicAliasMaximum
-
클라이언트가 브로커가 지원하는 최대 별칭 수를 지정합니다. 기본값은
65535입니다. 값 -1은 브로커가 주제 별칭 제한을 알릴 수 없습니다. 이 값은 값을 0으로 설정하는 것과 동일하지만 CONNACK 패킷의 크기를 줄입니다. - maximumPacketSize
-
브로커가 클라이언트에서 수락할 수 있는 최대 패킷 크기를 지정합니다. 기본값은
268435455입니다. 값 -1은 브로커가 최대 패킷 크기를 알릴 수 없으므로 들어오는 패킷 크기에 제한이 적용되지 않습니다. - serverKeepAlive
-
브로커가 비활성 클라이언트 연결을 열린 상태로 유지하는 기간을 지정합니다. 구성된 값은 클라이언트에 대해 구성된 keep-alive 값보다 작거나 클라이언트에 대해 구성된 값이 0인 경우에만 연결에 적용됩니다. 기본값은
60초입니다. 값-1은 브로커가 항상 클라이언트의 활성 값을 수락한다는 것을 의미합니다(해당 값이 0인 경우에도). - closeMqttConnectionOnPublishAuthorizationFailure
-
기본적으로 권한 부여 부족으로 인해 ECDHELISH 패킷이 실패하면 브로커는 네트워크 연결을 종료합니다. 브로커가 네트워크 연결을 닫는 대신 긍정적인 승인을 보내려면
closeMqttConnectionOnPublishAuthorizationFailure를false로 설정합니다.
브로커는 JMS 클라이언트가 브로커와 직접 통신할 수 있는 Open>-<re 프로토콜을 지원합니다. 이 프로토콜을 사용하여 이전 버전의 AMQ Broker와 통신합니다.
현재 AMQ Broker는 표준 JMS API만 사용하는 OpenECDHEre 클라이언트를 지원합니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 다음 예와 같이
OPENWIRE를protocol매개변수의 일부로 포함하도록어셉터를 추가하거나 수정합니다.<acceptors> <acceptor name="openwire-acceptor">tcp://localhost:61616?protocols=OPENWIRE</acceptor> ... </acceptors>
<acceptors> <acceptor name="openwire-acceptor">tcp://localhost:61616?protocols=OPENWIRE</acceptor> ... </acceptors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이전 예에서 브로커는 포트 61616에서 수신 대기하여 Open>-<re 명령을 수신 대기합니다.
자세한 내용은 < install_dir> /examples/protocols/openwire 에 있는 예제를 참조하십시오.
3.5. 네트워크 연결에서 STOMP 사용 링크 복사링크가 클립보드에 복사되었습니다!
STOMP 는 STOMP 클라이언트가 STOMP 브로커와 통신할 수 있는 텍스트 지향 전선 프로토콜입니다. 브로커는 STOMP 1.0, 1.1 및 1.2를 지원합니다. STOMP 클라이언트는 여러 언어와 플랫폼에서 사용할 수 있으므로 상호 운용성을 위해 선택하는 것이 좋습니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. -
기존 수용자를 구성하거나 새 작업자를 생성하고 아래와 같이 값이
STOMP인protocols매개변수를 포함합니다.
<acceptors> <acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP</acceptor> ... </acceptors>
<acceptors>
<acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP</acceptor>
...
</acceptors>
이전 예에서 브로커는 포트 61613 에서 기본값인 STOMP 연결을 허용합니다.
STOMP를 사용하여 브로커를 구성하는 방법에 대한 예는 < install_dir> /examples/protocols 아래에 있는 stomp 예제를 참조하십시오.
3.5.1. STOMP 제한 사항 링크 복사링크가 클립보드에 복사되었습니다!
STOMP를 사용하는 경우 다음과 같은 제한 사항이 적용됩니다.
-
브로커는 현재 가상 호스팅을 지원하지 않으므로
CONNECT프레임의호스트헤더가 무시됩니다. -
메시지 승인은 트랜잭션이 아닙니다.
ACK프레임은 트랜잭션의 일부일 수 없으며트랜잭션헤더가 설정된 경우 무시됩니다.
3.5.2. STOMP 메시지의 ID 제공 링크 복사링크가 클립보드에 복사되었습니다!
JMS 소비자 또는 QueueForwardedr를 통해 STOMP 메시지를 수신할 때 메시지에는 기본적으로 JMS 속성(예: JMSMessageID )이 포함되지 않습니다. 그러나 브로커 매개 변수를 사용하여 들어오는 STOMP 메시지마다 메시지 ID를 설정할 수 있습니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. -
다음 예와 같이 STOMP 연결에 사용되는
acceptor에 대해stompEnableMessageId매개변수를true로 설정합니다.
<acceptors> <acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP;stompEnableMessageId=true</acceptor> ... </acceptors>
<acceptors>
<acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP;stompEnableMessageId=true</acceptor>
...
</acceptors>
stompEnableMessageId 매개변수를 사용하면 이 acceptor를 사용하여 전송된 각 stomp 메시지에 추가 속성이 추가됩니다. 속성 키는 amq-message-id 이고 값은 다음 예와 같이 "STOMP" 접두사가 붙은 내부 메시지 id의 문자열 표현입니다.
amq-message-id : STOMP12345
amq-message-id : STOMP12345
stompEnableMessageId 가 구성에 지정되지 않은 경우 기본값은 false 입니다.
3.5.3. 라이브 연결 시간 설정 링크 복사링크가 클립보드에 복사되었습니다!
STOMP 클라이언트는 연결을 종료하기 전에 DISCONNECT 프레임을 보내야 합니다. 이를 통해 브로커는 세션 및 소비자와 같은 서버 측 리소스를 모두 닫을 수 있습니다. 그러나 STOMP 클라이언트가 DISCONNECT 프레임을 전송하지 않고 종료하거나 실패하는 경우 브로커는 클라이언트가 아직 활성 상태인지 여부를 즉시 알 수 없습니다. 따라서 STOMP 연결은 1분이라는 "Time to Live"(TTL)를 갖도록 구성됩니다. 브로커는 1분 이상 유휴 상태인 경우 STOMP 클라이언트에 대한 연결을 중지합니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. -
다음 예와 같이 STOMP 연결에 사용되는
acceptorURI에connectionTTL매개변수를 추가합니다.
<acceptors> <acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP;connectionTTL=20000</acceptor> ... </acceptors>
<acceptors>
<acceptor name="stomp-acceptor">tcp://localhost:61613?protocols=STOMP;connectionTTL=20000</acceptor>
...
</acceptors>
이전 예에서 stomp-acceptor 를 사용하는 모든 stomp 연결에는 TTL이 20초로 설정됩니다.
STOMP 프로토콜의 버전 1.0에는 하트비트 프레임이 포함되어 있지 않습니다. 따라서 connection-ttl 내에 데이터가 전송되었는지 확인하거나 브로커가 클라이언트가 종료되고 서버 측 리소스를 정리한다고 가정해야 하는 것은 사용자의 책임입니다. 버전 1.1을 사용하면 하트비트를 사용하여 stomp 연결의 라이프 사이클을 유지할 수 있습니다.
브로커의 기본 시간 재정의
앞서 언급했듯이 STOMP 연결의 기본 TTL은 1분입니다. 브로커 구성에 connection-ttl-override 특성을 추가하여 이 값을 덮어쓸 수 있습니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. -
connection-ttl-override특성을 추가하고 새 기본값에 대해 밀리초 단위 값을 제공합니다. 아래와 같이 <core> 스탠자 내부에 있습니다.
이전 예에서 STOMP 연결의 기본 Time to Live(TTL)는 30초, 30000 밀리초로 설정됩니다.
3.5.4. JMS에서 STOMP 메시지 전송 및 사용 링크 복사링크가 클립보드에 복사되었습니다!
STOMP는 주로 텍스트 지향 프로토콜입니다. JMS와 상호 운용하기 위해 STOMP 구현에서는 콘텐츠 길이 헤더가 있는지 확인하여 STOMP 메시지를 JMS에 매핑하는 방법을 결정합니다.
| STOMP 메시지가 …에 매핑되도록 하려면 | 메시지는…. |
|---|---|
| JMS textMessage |
|
| JMS BytesMessage |
|
JMS 메시지를 STOMP에 매핑할 때 동일한 논리가 적용됩니다. STOMP 클라이언트는 콘텐츠 길이 헤더가 있는지 확인하여 메시지 본문(문자열 또는 바이트)의 유형을 확인할 수 있습니다.
메시지 헤더에 대한 자세한 내용은 STOMP 사양을 참조하십시오.
3.5.5. AMQ Broker 주소 및 큐에 STOMP 대상 매핑 링크 복사링크가 클립보드에 복사되었습니다!
메시지와 구독을 보낼 때 STOMP 클라이언트는 일반적으로 대상 헤더를 포함합니다. 대상 이름은 브로커의 대상에 매핑되는 문자열 값입니다. AMQ Broker에서 이러한 대상은 주소 및 큐에 매핑됩니다. 대상 프레임에 대한 자세한 내용은 STOMP 사양을 참조하십시오.
예를 들어 다음 메시지를 전송하는 STOMP 클라이언트 (headers 및 body 포함):
SEND destination:/my/stomp/queue hello queue a ^@
SEND
destination:/my/stomp/queue
hello queue a
^@
이 경우 브로커는 메시지를 /my/stomp/queue 주소와 연결된 모든 큐로 전달합니다.
예를 들어 STOMP 클라이언트가 SEND 프레임을 사용하여 메시지를 보내는 경우 지정된 대상은 주소에 매핑됩니다.
클라이언트가 SUBSCRIBE 또는 UNSUBSCRIBE 프레임을 보낼 때 동일한 방식으로 작동하지만 AMQ Broker는 대상 을 큐에 매핑합니다.
SUBSCRIBE destination: /other/stomp/queue ack: client ^@
SUBSCRIBE
destination: /other/stomp/queue
ack: client
^@
이전 예에서 브로커는 대상 을 /other/stomp/queue 큐에 매핑합니다.
STOMP 대상을 JMS 대상에 매핑
JMS 대상은 브로커 주소 및 큐에도 매핑됩니다. STOMP를 사용하여 JMS 대상에 메시지를 보내려면 STOMP 대상은 동일한 규칙을 따라야 합니다.
jms.queue에 의해 큐 이름을 추가하여 JMS 대기열을 보내거나 구독합니다.예를 들어 메시지를주문JMS Queue에 보내려면 STOMP 클라이언트가 프레임을 보내야 합니다.SEND destination:jms.queue.orders hello queue orders ^@
SEND destination:jms.queue.orders hello queue orders ^@Copy to Clipboard Copied! Toggle word wrap Toggle overflow 주제 이름 앞에
jms.topic..를 추가하여 JMS 주제를 보내거나 구독하십시오. 예를 들어, 스톡스 JMS주제를구독하려면 STOMP 클라이언트는 다음과 유사한 프레임을 보내야 합니다.SUBSCRIBE destination:jms.topic.stocks ^@
SUBSCRIBE destination:jms.topic.stocks ^@Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4장. 주소 및 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
4.1. 주소, 큐 및 라우팅 유형 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에서 주소 지정 모델은 세 가지 주요 개념, 주소,대기열 및 라우팅 유형으로 구성됩니다.
주소는 메시징 끝점을 나타냅니다. 구성 내에서 일반적인 주소에는 고유한 이름, 하나 이상의 대기열 및 라우팅 유형이 지정됩니다.
큐 는 주소와 연결되어 있습니다. 주소당 대기열이 여러 개 있을 수 있습니다. 들어오는 메시지가 주소와 일치하면 구성된 라우팅 유형에 따라 메시지가 하나 이상의 큐로 전송됩니다. 대기열을 자동으로 생성하고 삭제하도록 구성할 수 있습니다. 또한 주소(및 관련 대기열)를 성형으로 구성할 수도 있습니다. 큐의 메시지도 지속되는 한 큐의 지속성은 충돌하거나 브로커를 다시 시작할 수 있습니다. 반면, 대기할 수 없는 큐의 메시지는 메시지 자체를 지속적인 경우에도 충돌하거나 브로커를 다시 시작하지 못합니다.
라우팅 유형 에서는 주소와 연결된 큐로 메시지를 전송하는 방법을 결정합니다. AMQ Broker에서는 표에 표시된 대로 두 가지 라우팅 유형으로 주소를 구성할 수 있습니다.
| 메시지를…으로 라우팅하려는 경우 | 이 라우팅 유형…을 사용합니다. |
|---|---|
| 일치하는 주소 내의 단일 큐(point-to-point) 방식 |
|
| 게시-서브스크립션 방식으로 일치하는 주소 내의 모든 대기열 |
|
주소에는 하나 이상의 라우팅 유형이 정의되어 있어야 합니다.
주소당 두 개 이상의 라우팅 유형을 정의할 수 있지만 권장되지는 않습니다.
주소에 두 라우팅 유형이 모두 정의되어 있고 클라이언트에 우선 순위가 표시되지 않으면 브로커의 기본값은 멀티 캐스트 라우팅 유형입니다.
추가 리소스
구성에 대한 자세한 내용은 다음을 참조하십시오.
-
anycast라우팅 유형을 사용하는 점대점 메시징은 다음을 참조하십시오. 4.3절. “지점 간 메시징에 대한 주소 구성” -
멀티 캐스트라우팅 유형을 사용하는 게시-구독 메시징, 참조 4.4절. “게시-서브스크립션 메시징을 위한 주소 설정”
-
4.1.1. 주소 및 큐 이름 지정 요구사항 링크 복사링크가 클립보드에 복사되었습니다!
주소 및 대기열을 구성할 때 다음 요구 사항을 유의하십시오.
클라이언트가 클라이언트가 사용하는 배선 프로토콜에 관계없이 클라이언트가 큐에 연결할 수 있도록 하려면 주소 및 큐 이름에 다음 문자가 포함되어 서는 안 됩니다.
&::,?>-
숫자 기호(
#) 및 별표(*) 문자는 와일드카드 표현식용으로 예약되어 있으며 주소 및 대기열 이름에 사용해서는 안 됩니다. 자세한 내용은 4.2.1절. “AMQ Broker 와일드카드 구문”의 내용을 참조하십시오. - 주소 및 큐 이름에는 공백이 포함되지 않아야 합니다.
-
주소 또는 큐 이름에서 단어를 분리하려면 구성된 구분 기호 문자를 사용합니다. 기본 구분 기호 문자는 마침표(
..)입니다. 자세한 내용은 4.2.1절. “AMQ Broker 와일드카드 구문”의 내용을 참조하십시오.
4.2. 주소 집합에 주소 설정 적용 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에서는 와일드카드 표현식을 사용하여 일치하는 주소 이름을 나타내는 방법으로 address-setting 요소에 지정된 구성을 주소 집합에 적용할 수 있습니다.
다음 섹션에서는 와일드카드 표현식을 사용하는 방법에 대해 설명합니다.
4.2.1. AMQ Broker 와일드카드 구문 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker는 주소 설정에서 와일드카드를 나타내는 데 특정 구문을 사용합니다. 또한 보안 설정과 소비자를 생성할 때 와일드카드를 사용할 수도 있습니다.
-
와일드카드 식에는 마침표(
..)로 구분된 단어가 포함됩니다. 숫자 기호(
#) 및 별표(*) 문자도 특별한 의미가 있으며 다음과 같이 단어 대신 사용할 수 있습니다.- 숫자 부호 문자는 "0개 이상의 단어 시퀀스와 일치"를 나타냅니다. 표현식의 끝에서 이를 사용합니다.
- 별표 문자는 "단일 단어와 일치"를 나타냅니다. 이 방법은 표현식 내에서 어디에서나 사용하십시오.
일치는 문자별로 수행되는 문자가 아니라 각 구분자 경계에서 수행됩니다. 예를 들어 이름에 있는 내 대기열과 일치하도록 구성된 address-setting 요소는 라는 큐와 일치하지 않습니다.
my queue
둘 이상의 address-setting 요소가 주소와 일치하는 경우 브로커는 가장 구체적인 구성을 기준선으로 사용하여 구성을 오버레이합니다. 리터럴 표현식은 와일드카드보다 더 구체적이며 별표(*)는 숫자 기호(#)보다 더 구체적입니다. 예를 들어 my.destination 과 my.* 둘 다 my.destination 주소와 일치합니다. 이 경우 브로커는 먼저 my.* 아래에 있는 구성을 적용합니다. 와일드카드 표현식은 리터럴보다 덜 구체적이기 때문입니다. 다음으로 브로커는 my.destination 주소 설정 요소의 구성을 오버레이하여 my.* 와 공유하는 모든 구성을 덮어씁니다. 예를 들어 다음 구성에 따라 my.destination 과 연결된 큐에 max-delivery-attempts 가 3 으로 설정되고 last-value-queue 가 false 로 설정됩니다.
다음 표의 예제에서는 주소 집합과 일치하도록 와일드카드를 사용하는 방법을 보여줍니다.
| 예제 | 설명 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
4.2.2. 브로커 와일드카드 구문 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 와일드카드 주소에 사용되는 구문을 사용자 지정하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 아래 예제
와 같이 <wildcard-addresses> 섹션을 구성에 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow enabled-
true로 설정하면 브로커가 사용자 정의 설정을 사용하도록 지시합니다. delimiter-
기본값 대신
구분자로 사용할 사용자 지정 문자를 제공합니다. any-words-
any-words의 값으로 제공되는 문자는 ''match any sequence of zero or more words' and will replace the default#. 표현식 끝에 이 문자를 사용합니다. single-word-
단일어의 값으로 제공되는 문자는 '
단일 단어'를 의미하고 기본값*을 대체하는 데 사용됩니다. 이 문자는 표현식 내에서 어디에서나 사용하십시오.
4.3. 지점 간 메시징에 대한 주소 구성 링크 복사링크가 클립보드에 복사되었습니다!
점대점 메시징은 프로듀서에서 보낸 메시지에 소비자는 한 개뿐인 일반적인 시나리오입니다. AMQP 및 JMS 메시지 생산자와 소비자는 예를 들어 포인트 간 메시징 큐를 사용할 수 있습니다. 주소와 연결된 큐가 지점 간 방식으로 메시지를 수신하도록 하려면 브로커 구성에서 지정된 주소 요소에 대한 임의의 캐스트 라우팅 유형을 정의합니다.
anycast 를 사용하여 메시지를 수신하면 브로커는 주소와 연결된 큐를 찾아 메시지를 해당 주소로 라우팅합니다. 그러면 소비자가 해당 큐의 메시지를 사용하도록 요청할 수 있습니다. 여러 소비자가 동일한 큐에 연결하면 소비자가 동일하게 처리할 수 있는 경우 메시지가 소비자 간에 동일하게 배포됩니다.
다음 그림은 점대점 메시징의 예를 보여줍니다.
4.3.1. 기본 지점 간 메시징 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 지점 간 메시징에 대해 단일 큐를 사용하여 주소를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 주소의 선택한.대기열요소에서anycast구성 요소를 래핑합니다address및queue요소에 대한name특성 값이 모두 같은지 확인합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.2. 여러 큐에 대한 점대점 메시징 구성 링크 복사링크가 클립보드에 복사되었습니다!
anycast 라우팅 유형을 사용하는 주소에서 두 개 이상의 큐를 정의할 수 있습니다. 브로커는 연결된 모든 큐에서 임의의 주소로 전송된 메시지를 균등하게 분배합니다. 완전한 QQN (Qualified Queue Name )을 지정하여 클라이언트를 특정 큐에 연결할 수 있습니다. 둘 이상의 소비자가 동일한 큐에 연결하면 브로커는 소비자 간에 메시지를 균등하게 분배합니다.
다음 그림은 두 개의 큐를 사용하여 점대점 메시징의 예를 보여줍니다.
다음 절차에서는 여러 큐가 있는 주소에 대한 지점 간 메시징을 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. address요소의큐요소에 대해anycast구성 요소를 래핑합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
위에 클러스터의 여러 브로커에 걸쳐 미러링된 것과 같은 구성이 있는 경우 클러스터는 생산자와 소비자에게 불투명한 방식으로 클러스터에서 분산 지점 간 메시징을 로드할 수 있습니다. 정확한 동작은 메시지 로드 밸런싱 정책이 클러스터에 대해 구성된 방법에 따라 달라집니다.
추가 리소스
다음에 대한 자세한 내용은 다음을 참조하십시오.
- 정규화된 대기열 이름 지정은 4.9절. “정규화된 큐 이름 지정” 을 참조하십시오.
- 브로커 클러스터에 대한 메시지 로드 밸런싱을 구성하는 방법은 14.1.1절. “브로커 클러스터의 메시지 로드 밸런싱 방법” 을 참조하십시오.
4.4. 게시-서브스크립션 메시징을 위한 주소 설정 링크 복사링크가 클립보드에 복사되었습니다!
게시-서브스크립션 시나리오에서는 메시지가 주소에 가입된 모든 소비자에게 전송됩니다. JMS 주제와 MQTT 서브스크립션은 게시 구독 메시지의 두 가지 예입니다. 주소와 연결된 큐가 게시-구독 방식으로 메시지를 수신하도록 하려면 브로커 구성에서 지정된 주소 요소에 대한 멀티 캐스트 라우팅 유형을 정의합니다.
메시지가 멀티 캐스트 라우팅 유형의 주소에 수신되면 브로커는 메시지 사본을 주소와 연결된 각 큐로 라우팅합니다. 복사 오버헤드를 줄이기 위해 각 큐는 전체 복사가 아닌 메시지에 대한 참조 만 전송됩니다.
다음 그림은 게시-구독 메시지의 예를 보여줍니다.
다음 절차에서는 게시-구독 메시징을 위해 주소를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 주소에 빈
멀티 캐스트구성 요소를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow (선택 사항) 주소에 하나 이상의
큐요소를 추가하고멀티 캐스트요소를 래핑합니다. 일반적으로 브로커가 클라이언트가 요청한 각 서브스크립션에 대해 대기열을 자동으로 생성하므로 이 단계가 필요하지 않습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5. 지점 간 메시징과 게시-구독 메시지의 주소 구성 링크 복사링크가 클립보드에 복사되었습니다!
점대점 및 게시-구독(publish-to-Subscribe) 의미론을 모두 사용하여 주소를 구성할 수도 있습니다.
일반적으로 포인트 대 포인트 및 게시 구독 의미 체계를 모두 사용하는 주소를 구성하는 것은 권장되지 않습니다. 그러나 예를 들어 orders 라는 JMS 대기열과 orders 라는 JMS 주제를 원하는 경우 유용할 수 있습니다. 서로 다른 라우팅 유형을 통해 클라이언트 연결에 대해 주소가 고유하게 표시됩니다. 이 경우 JMS 대기열 프로듀서가 보낸 메시지는 anycast 라우팅 유형을 사용합니다. JMS 주제 생산자가 보낸 메시지는 멀티 캐스트 라우팅 유형을 사용합니다. JMS 주제 소비자가 브로커에 연결하면 자체 서브스크립션 큐에 연결됩니다. 그러나 JMS 큐 소비자는 anycast 큐에 연결됩니다.
다음 그림은 함께 사용되는 포인트-투-포인트 및 게시-구독 메시지의 예를 보여줍니다.
다음 절차에서는 지점 간 메시지와 게시-구독 메시지의 주소를 구성하는 방법을 보여줍니다.
이 시나리오의 동작은 사용 중인 프로토콜에 따라 다릅니다. JMS의 경우 주제와 대기열 생산자와 소비자 사이에 명확한 차이점이 있으므로 논리를 쉽게 만들 수 있습니다. AMQP와 같은 다른 프로토콜에서는 이러한 구분을 수행하지 않습니다. AMQP를 통해 전송되는 메시지는 anycast 및 multicast 및 Consumer에 의해 기본적으로 anycast 로 라우팅됩니다. 자세한 내용은 3장. 네트워크 연결에서 메시징 프로토콜 구성의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. address요소의큐요소에 대해anycast구성 요소를 래핑합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 주소에 빈
멀티 캐스트구성 요소를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고일반적으로 브로커는 필요에 따라 서브스크립션 큐를 생성하므로
multicast요소 내부에 특정 큐 요소를 나열할 필요가 없습니다.
4.6. 어셉터 구성에 라우팅 유형 추가 링크 복사링크가 클립보드에 복사되었습니다!
일반적으로 anycast 및 멀티 캐스트 를 모두 사용하는 주소에 메시지를 수신하는 경우 anycast 대기열 중 하나와 모든 멀티 캐스트 대기열을 수신합니다. 그러나 클라이언트는 주소에 연결할 때 임의의 캐스트 또는 멀티 캐스트 를 사용하여 연결할지 여부를 지정할 때 특수 접두사를 지정할 수 있습니다. 접두사는 브로커 구성에 있는 어셉터 URL 내에서 anycastPrefix 및 multicastPrefix 매개변수를 사용하여 지정하는 사용자 지정 값입니다.
다음 절차에서는 지정된 수락자의 접두사를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 지정된 수락자의 경우
anycast접두사를 구성하려면 구성된 URL에anycastPrefix를 추가합니다. 사용자 지정 값을 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 구성에 따라 어셉터는
anycast접두사에anycast://를 사용하도록 구성됩니다. 클라이언트가을 지정할 수 있습니다.anycast대기열 중 하나에만 메시지를 보내야 하는 경우 클라이언트 코드는 anycast://<my.destination>/지정된 acceptor의 경우
멀티캐스트접두사를 구성하려면 구성된 URL에multicastPrefix를 추가합니다. 사용자 지정 값을 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 구성에 따라 멀티 캐스트 접두사에
를 사용하도록 어셉터가 구성됩니다. 클라이언트에 멀티 캐스트 큐로만 전송된 메시지가 필요한 경우 클라이언트 코드는multicast://을 지정할 수 있습니다.multicast://<my.destination>/
4.7. 서브스크립션 큐 구성 링크 복사링크가 클립보드에 복사되었습니다!
대부분의 경우 클라이언트가 주소를 처음 구독하도록 요청할 때 프로토콜 관리자가 자동으로 서브스크립션 대기열을 생성하므로 서브스크립션 대기열을 수동으로 생성할 필요가 없습니다. 자세한 내용은 4.8.3절. “프로토콜 관리자 및 주소”를 참조하십시오. 성형 서브스크립션의 경우 생성된 큐 이름은 일반적으로 클라이언트 ID와 주소의 연결입니다.
다음 섹션에서는 필요한 경우 서브스크립션 대기열을 수동으로 생성하는 방법을 보여줍니다.
4.7.1. 안정된 서브스크립션 큐 구성 링크 복사링크가 클립보드에 복사되었습니다!
큐가 안정된 서브스크립션으로 구성되면 브로커는 비활성 구독자에 대한 메시지를 저장하고 다시 연결할 때 구독자에게 전달합니다. 따라서 클라이언트는 구독한 후 큐로 전달되는 각 메시지를 수신해야 합니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 선택한 큐에 위치 구성 요소를 추가합니다.
true값을 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고미용성 요소를 포함하여 기본적으로 대기열은 장래하지 않기 때문에 값을
true로 설정하는 것은 지속성 큐를 만드는 데 엄격하게 필요하지 않습니다.그러나 명시적으로 요소를 포함하면 나중에 큐의 동작을 필요한 경우 취소할 수 없습니다.However, explicitly including the element enables you to later change the behavior of the queue to non-durable, if necessary.
4.7.3. 실행 불가능한 서브스크립션 큐 구성 링크 복사링크가 클립보드에 복사되었습니다!
일반적으로 적용할 수 없는 서브스크립션은 관련 프로토콜 관리자가 관리하므로 임시 대기열을 생성하고 삭제합니다.
그러나 불가능한 서브스크립션 큐와 같이 작동하는 큐를 수동으로 생성하려면 대기열에서 purge-on-no-consumers 특성을 사용할 수 있습니다. purge-on-no-consumers 가 true 로 설정되면 대기열은 소비자가 연결될 때까지 메시지 수신을 시작하지 않습니다. 또한 마지막 소비자가 대기열과 연결이 끊어지면 대기열이 제거됩니다 (즉, 해당 메시지는 제거됨). 새 소비자가 큐에 연결될 때까지 큐는 추가 메시지를 수신하지 않습니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 선택한 각 큐에
purge-on-no-consumers특성을 추가합니다.true값을 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.8. 주소 및 대기열 생성 및 삭제 링크 복사링크가 클립보드에 복사되었습니다!
주소와 큐를 자동으로 생성하고 더 이상 사용하지 않는 후 삭제할 브로커를 구성할 수 있습니다. 이렇게 하면 클라이언트가 연결하기 전에 각 주소를 미리 구성할 필요가 없습니다.
4.8.1. 자동 대기열 생성 및 삭제를 위한 구성 옵션 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에는 큐 및 주소를 자동으로 생성하고 삭제하도록 address-setting 요소를 구성할 때 사용할 수 있는 구성 요소가 나열되어 있습니다.
address-setting to… | 이 구성을 추가합니다.… |
|---|---|
| 클라이언트가 메시지를 보내거나 존재하지 않는 주소에 매핑된 큐의 메시지를 사용하려고 할 때 주소를 만듭니다. |
|
| 클라이언트가 큐에서 메시지를 보내거나 큐의 메시지를 사용하려고 하면 큐를 생성합니다. |
|
| 큐가 더 이상 없는 경우 자동으로 생성된 주소를 삭제합니다. |
|
| 큐에 0개의 소비자와 0개의 메시지가 있으면 자동으로 생성된 큐를 삭제합니다. |
|
| 클라이언트가 지정하지 않는 경우 특정 라우팅 유형을 사용합니다. |
|
4.8.2. 주소 및 큐 자동 생성 및 삭제 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 주소 및 큐의 자동 생성 및 삭제를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 자동 생성 및 삭제를 위한
address-setting을 구성합니다. 다음 예제에서는 이전 표에 언급된 모든 구성 요소를 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow address-setting-
address-setting요소의 구성은 와일드카드 주소activemq.#과 일치하는 주소 또는 큐에 적용됩니다. auto-create-addresses- 클라이언트가 아직 존재하지 않는 주소에 연결하도록 요청하면 브로커는 주소를 생성합니다.
auto-delete-addresses- 자동으로 생성된 주소는 더 이상 연결된 큐가 없는 경우 삭제됩니다.
auto-create-queues- 클라이언트가 아직 존재하지 않는 큐에 연결하도록 요청하면 브로커는 큐를 생성합니다.
auto-delete-queues- 자동 생성된 큐는 더 이상 소비자 또는 메시지가 없으면 삭제됩니다.
default-address-routing-type-
클라이언트가 연결할 때 라우팅 유형을 지정하지 않으면 브로커는 메시지를 주소에 전달할 때
ANYCAST를 사용합니다. 기본값은MULTICAST입니다.
추가 리소스
다음에 대한 자세한 내용은 다음을 참조하십시오.
- 주소를 구성할 때 사용할 수 있는 와일드카드 구문은 4.2절. “주소 집합에 주소 설정 적용” 을 참조하십시오.
- 라우팅 유형, 4.1절. “주소, 큐 및 라우팅 유형” 에서 참조하십시오.
4.8.3. 프로토콜 관리자 및 주소 링크 복사링크가 클립보드에 복사되었습니다!
프로토콜 관리자 라는 구성 요소는 AMQ Broker 주소 모델에 사용되는 개념에 프로토콜별 개념을 매핑합니다. 특정 상황에서는 프로토콜 관리자가 브로커에 대기열을 자동으로 생성할 수 있습니다.
예를 들어 클라이언트가 /house/room1/lights 및 /house/room2/lights 주소를 사용하여 MQTT 서브스크립션 패킷을 보내는 경우 MQTT 프로토콜 관리자는 두 주소에 멀티 캐스트 의미가 필요하다는 것을 이해합니다. 따라서 프로토콜 관리자는 먼저 멀티 캐스트 가 두 주소에 대해 활성화되어 있는지 확인합니다. 그렇지 않은 경우 동적으로 생성을 시도합니다. 프로토콜 관리자가 성공하면 클라이언트가 요청한 각 서브스크립션에 대해 특수 서브스크립션 대기열을 생성합니다.
각 프로토콜은 약간 다르게 작동합니다. 아래 표는 다양한 유형의 큐에 대한 구독 프레임이 요청될 때 일반적으로 수행되는 작업을 설명합니다.
| 큐가 이 유형인 경우... | 프로토콜 관리자의 일반적인 작업은…입니다. |
|---|---|
| 세분화된 서브스크립션 큐 |
적절한 주소를 찾아서 특수 이름을 사용하면 프로토콜 관리자가 필요한 클라이언트 서브스크립션 큐를 신속하게 식별할 수 있습니다. 클라이언트의 연결을 끊고 나중에 다시 연결해야 합니다. 클라이언트가 큐를 구독 취소하면 큐가 삭제됩니다. |
| 임시 서브스크립션 큐 |
적절한 주소를 찾아서 클라이언트의 연결이 끊어지면 큐가 삭제됩니다. |
| 점대점 대기열 |
적절한 주소를 찾고 대기열이 자동으로 생성되면 소비자가 없고 메시지가 없으면 자동으로 삭제됩니다. |
4.9. 정규화된 큐 이름 지정 링크 복사링크가 클립보드에 복사되었습니다!
내부에서 브로커는 주소에 대한 요청을 특정 큐에 매핑합니다. 브로커는 메시지를 보낼 대기열 또는 메시지를 수신할 대기열을 대신하여 결정합니다. 그러나 보다 고급 사용 사례에는 클라이언트가 큐 이름을 직접 지정해야 할 수 있습니다. 이러한 상황에서 클라이언트는 정규화된 큐 이름 (FQN)을 사용할 수 있습니다. FQQN에는 주소 이름과 큐 이름이 모두 포함되며, 다음과 같습니다.
다음 절차에서는 여러 큐가 있는 주소에 연결할 때 FQQN을 지정하는 방법을 보여줍니다.
사전 요구 사항
아래 예제와 같이 두 개 이상의 큐로 구성된 주소가 있습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
절차
클라이언트 코드에서 브로커로부터 연결을 요청할 때 주소 이름과 큐 이름을 모두 사용합니다. 두 개의 콜론(
::)을 사용하여 이름을 구분합니다. 예를 들면 다음과 같습니다.String FQQN = "my.address::q1"; Queue q1 session.createQueue(FQQN); MessageConsumer consumer = session.createConsumer(q1);
String FQQN = "my.address::q1"; Queue q1 session.createQueue(FQQN); MessageConsumer consumer = session.createConsumer(q1);Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.10. 분할된 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
부분 순서만 필요한 대기열에서 메시지 처리를 위한 일반적인 패턴은 큐 샤딩 을 사용하는 것입니다. 즉, 단일 논리 대기열 역할을 하지만 여러 기본 물리적 대기열에서 지원하는 모든 캐스트 주소를 정의합니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. address요소를 추가하고name특성을 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow anycast라우팅 유형을 추가하고 원하는 sharded 대기열 수를 포함합니다. 아래 예제에서 큐q1,q2,q3는anycast대상으로 추가됩니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
위의 구성에 따라 my.sharded.address 로 전송된 메시지는 q1,q2 및 에 동일하게 배포됩니다. 클라이언트는 완전한 정규화된 대기열 이름(FQN)을 사용할 때 특정 물리적 대기열에 직접 연결하고 해당 특정 큐로만 메시지를 수신할 수 있습니다.
q 3
특정 메시지를 특정 큐에 연결하기 위해 클라이언트는 각 메시지에 대해 메시지 그룹을 지정할 수 있습니다. 브로커는 그룹화된 메시지를 동일한 큐로 라우팅하고 한 소비자가 모두 처리합니다.
추가 리소스
다음에 대한 자세한 내용은 다음을 참조하십시오.
- 정규화된 대기열 이름, 참조 4.9절. “정규화된 큐 이름 지정”
- 메시지 그룹화는 AMQ Core Protocol JMS 문서에서 메시지 그룹 사용을 참조하십시오.
4.11. 마지막 값 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
마지막 값 큐 는 마지막 값 키 값이 있는 최신 메시지가 큐에 배치될 때 큐에서 메시지를 삭제하는 큐 유형입니다. 이 동작을 통해 마지막 값 큐는 동일한 키의 메시지에 대한 마지막 값만 유지합니다.
마지막 값 큐에 대한 간단한 사용 사례는 특정 스포지트의 최신 값만 관심 있는 SAP 가격을 모니터링하는 것입니다.
구성된 마지막 값 키가 없는 메시지가 마지막 값 큐로 전송되면 브로커는 이 메시지를 "일반" 메시지로 처리합니다. 이러한 메시지는 구성된 마지막 값 키가 도달한 새 메시지가 표시되면 대기열에서 제거되지 않습니다.
마지막 값 큐를 개별적으로 또는 주소 집합과 연결된 모든 큐에 대해 구성할 수 있습니다.
다음 절차에서는 이러한 방식으로 마지막 값 큐를 구성하는 방법을 보여줍니다.
4.11.1. 마지막 값 대기열을 개별적으로 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 마지막 값 큐를 개별적으로 구성하는 방법을 보여줍니다.
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 지정된 큐의 경우
last-value-key키를 추가하고 사용자 지정 값을 지정합니다. 예를 들면 다음과 같습니다.<address name="my.address"> <multicast> <queue name="prices1" last-value-key="stock_ticker"/> </multicast> </address><address name="my.address"> <multicast> <queue name="prices1" last-value-key="stock_ticker"/> </multicast> </address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 또는
_AMQ_LVQ_NAME의 기본 마지막 값 키 이름을 사용하는 마지막 값 큐를 구성할 수 있습니다. 이렇게 하려면 지정된 큐에마지막-값키를 추가합니다. 값을true로 설정합니다. 예를 들면 다음과 같습니다.<address name="my.address"> <multicast> <queue name="prices1" last-value="true"/> </multicast> </address><address name="my.address"> <multicast> <queue name="prices1" last-value="true"/> </multicast> </address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.11.2. 주소에 대한 마지막 값 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 주소 또는 주소 집합에 대한 마지막 값 대기열을 구성하는 방법을 보여줍니다.
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. address-setting요소에서 일치하는 주소에 대해default-last-value-key를 추가합니다. 사용자 지정 값을 지정합니다. 예를 들면 다음과 같습니다.<address-setting match="lastValue"> <default-last-value-key>stock_ticker</default-last-value-key> </address-setting>
<address-setting match="lastValue"> <default-last-value-key>stock_ticker</default-last-value-key> </address-setting>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 앞의 구성에 따라
lastValue주소와 연결된 모든 큐는 lost_ticker의 마지막 값 키를 사용합니다. 기본적으로default-last-value-key값은 설정되지 않습니다.주소 집합에 대한 마지막 값 대기열을 구성하려면 주소 와일드카드를 지정할 수 있습니다. 예를 들면 다음과 같습니다.
<address-setting match="lastValue.*"> <default-last-value-key>stock_ticker</default-last-value-key> </address-setting>
<address-setting match="lastValue.*"> <default-last-value-key>stock_ticker</default-last-value-key> </address-setting>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 또는
_AMQ_LVQ_NAME의 기본 마지막 값 키 이름을 사용하도록 주소 또는 주소 세트 와 연결된 모든 대기열을 구성할 수 있습니다. 이렇게 하려면default-last-value-key대신default-last-value-queue를 추가합니다. 값을true로 설정합니다. 예를 들면 다음과 같습니다.<address-setting match="lastValue"> <default-last-value-queue>true</default-last-value-queue> </address-setting>
<address-setting match="lastValue"> <default-last-value-queue>true</default-last-value-queue> </address-setting>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 리소스
- 주소를 구성할 때 사용할 수 있는 와일드카드 구문에 대한 자세한 내용은 4.2절. “주소 집합에 주소 설정 적용” 을 참조하십시오.
4.11.3. 마지막 값 대기열 동작 예 링크 복사링크가 클립보드에 복사되었습니다!
이 예제에서는 마지막 값 큐의 동작을 보여줍니다.
broker.xml 구성 파일에서 다음과 같은 구성이 추가되었다고 가정합니다.
<address name="my.address">
<multicast>
<queue name="prices1" last-value-key="stock_ticker"/>
</multicast>
</address>
<address name="my.address">
<multicast>
<queue name="prices1" last-value-key="stock_ticker"/>
</multicast>
</address>
앞의 구성에서는 price 1이라는 큐 를 만들고 마지막 값 키의 slice _ticker.
이제 클라이언트가 두 개의 메시지를 전송한다고 가정합니다. 각 메세지는 property rail _ticker에 대해 . 각 메시지에는 rail ATN 의 동일한 값을 갖습니다_ price 라는 속성에 대해 다른 값이 있습니다. 각 메시지는 동일한 큐, price 1로 전송됩니다.
TextMessage message = session.createTextMessage("First message with last value property set");
message.setStringProperty("stock_ticker", "ATN");
message.setStringProperty("stock_price", "36.83");
producer.send(message);
TextMessage message = session.createTextMessage("First message with last value property set");
message.setStringProperty("stock_ticker", "ATN");
message.setStringProperty("stock_price", "36.83");
producer.send(message);
TextMessage message = session.createTextMessage("Second message with last value property set");
message.setStringProperty("stock_ticker", "ATN");
message.setStringProperty("stock_price", "37.02");
producer.send(message);
TextMessage message = session.createTextMessage("Second message with last value property set");
message.setStringProperty("stock_ticker", "ATN");
message.setStringProperty("stock_price", "37.02");
producer.send(message);
Secur _ticker 의 마지막 값 키(이 경우 ATN)에 대해 동일한 값을 가진 두 개의 메시지가 price 1 큐에 도달하면 최신 메시지만 큐에 남아 있으며 첫 번째 메시지가 제거됩니다. 명령줄에서 다음 줄을 입력하여 이 동작을 검증할 수 있습니다.
TextMessage messageReceived = (TextMessage)messageConsumer.receive(5000);
System.out.format("Received message: %s\n", messageReceived.getText());
TextMessage messageReceived = (TextMessage)messageConsumer.receive(5000);
System.out.format("Received message: %s\n", messageReceived.getText());
이 예에서 두 메시지 모두 마지막 값 키에 대해 동일한 값을 사용하고 두 번째 메시지가 첫 번째 뒤에 큐에서 수신되었기 때문에 표시되는 출력은 두 번째 메시지입니다.
4.11.4. 마지막 값 큐에 대해 분할되지 않은 사용 적용 링크 복사링크가 클립보드에 복사되었습니다!
소비자가 큐에 연결하면 일반 동작은 해당 소비자에게 전송된 메시지가 소비자가 독점적으로 취득하는 것입니다. 소비자가 메시지 수신을 승인하면 브로커는 큐에서 메시지를 제거합니다.
일반 사용 동작 대신, 비차별 사용을 강제 적용하도록 대기열을 구성할 수 있습니다. 이 경우 큐가 소비자에게 메시지를 보낼 때 다른 소비자가 메시지를 계속 수신할 수 있습니다. 또한 메시지는 소비자가 사용한 경우에도 큐에 남아 있습니다. 이러한 무차별 사용 동작을 적용하면 소비자는 큐 브라우저 라고 합니다.
비차별 사용을 강제 적용하는 것은 대기열이 특정 마지막 값 키의 최신 값을 항상 보유하고 있는지 확인하기 때문에 마지막 값 큐에 유용한 구성입니다.
다음 절차에서는 마지막 값 큐에 대해 비 결정적인 소비를 적용하는 방법을 보여줍니다.
사전 요구 사항
마지막-값 대기열을 개별적으로 구성했거나 주소 또는 주소 집합 과 연결된 모든 큐에 대해 이미 구성하셨습니다. 자세한 내용은 다음을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 이전에 대기열을 마지막 값 큐로 개별적으로 구성한 경우 디
지드되지 않은 키를추가합니다. 값을true로 설정합니다. 예를 들면 다음과 같습니다.<address name="my.address"> <multicast> <queue name="orders1" last-value-key="stock_ticker" non-destructive="true" /> </multicast> </address><address name="my.address"> <multicast> <queue name="orders1" last-value-key="stock_ticker" non-destructive="true" /> </multicast> </address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전에 마지막 값 큐에 대한 주소 또는 주소 집합을 구성한 경우
default-non-destructive키를 추가합니다. 값을true로 설정합니다. 예를 들면 다음과 같습니다.<address-setting match="lastValue"> <default-last-value-key>stock_ticker </default-last-value-key> <default-non-destructive>true</default-non-destructive> </address-setting>
<address-setting match="lastValue"> <default-last-value-key>stock_ticker </default-last-value-key> <default-non-destructive>true</default-non-destructive> </address-setting>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고기본적으로
default-non-destructive의 값은false입니다.
4.12. 만료된 메시지를 만료 주소로 이동 링크 복사링크가 클립보드에 복사되었습니다!
마지막 값 큐 이외의 대기열의 경우 결함이 없는 소비자만 있는 경우 브로커는 대기열에서 메시지를 삭제하지 않으므로 큐 크기가 시간이 지남에 따라 큐 크기가 증가합니다. 큐 크기의 제약되지 않은 증가를 방지하기 위해 메시지가 만료되는 시기를 구성하고 브로커가 만료된 메시지를 이동하는 주소를 지정할 수 있습니다.
4.12.1. 메시지 만료 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 메시지 만료를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. core요소에서message-expiry-scan-period를 설정하여 브로커의 만료된 메시지를 스캔하는 빈도를 지정합니다.<configuration ...> <core ...> ... <message-expiry-scan-period>1000</message-expiry-scan-period> ...<configuration ...> <core ...> ... <message-expiry-scan-period>1000</message-expiry-scan-period> ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 위 구성에 따라 브로커는 1000밀리초 마다 만료된 메시지의 대기열을 스캔합니다.
일치하는 주소 또는 주소 집합에 대한
address-setting요소에서 만료 주소를 지정합니다. 메시지 만료 시간을 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow expiry-address-
일치하는 주소 또는 주소에 대한 만료 주소입니다. 이전 예에서 브로커는 자재 주소에 대한 만료된 메시지를
ExpiryAddress라는 만료 주소로 보냅니다. expiry-delay브로커가 기본 만료 시간을 사용하는 메시지에 적용되는 만료 시간(밀리초)입니다. 기본적으로 메시지는 만료 시간이
0이며, 이는 만료되지 않습니다. 기본값보다 만료 시간이 긴 메시지의 경우 expiration-delay는 적용되지 않습니다.예를 들어 앞의 예제와 같이 주소의 expiration
-delay를10으로 설정했다고 가정합니다. 기본 만료 시간이0인 메시지가 이 주소에서 큐에 도달하면 브로커는 메시지의 만료 시간을0에서10으로 변경합니다. 그러나 만료 시간을 사용 중인 다른 메시지가20개의 도달한 경우 만료 시간은 변경되지 않습니다. expiration-delay를-1로 설정하면 이 기능이 비활성화됩니다. 기본적으로 expiration-delay는-1로 설정됩니다.
또는 expiration
-delay의 값을 지정하는 대신 최소 및 최대 만료지연 값을 지정할 수 있습니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow min-expiry-delay- 브로커가 메시지에 적용되는 최소 만료 시간(밀리초)입니다.
max-expiry-delay브로커가 메시지에 적용되는 최대 만료 시간(밀리초)입니다.
브로커는 다음과 같이
min-expiry-delay및max-expiry-delay값을 적용합니다.-
기본 만료 시간이
0인 메시지의 경우 브로커는 만료 시간을max-expiry-delay의 지정된 값으로 설정합니다.max-expiry-delay의 값을 지정하지 않은 경우 브로커는 만료 시간을min-expiry-delay의 지정된 값으로 설정합니다.min-expiry-delay의 값을 지정하지 않은 경우 브로커는 메시지의 만료 시간을 변경하지 않습니다. -
max-expiry-delay값을 초과하는 만료 시간이 있는 메시지의 경우 브로커는 만료 시간을 지정된max-expiry-delay값으로 설정합니다. -
min-expiry-delay값이 있는 만료 시간이 있는 메시지의 경우 브로커는 만료 시간을min-expiry-delay의 지정된 값으로 설정합니다. -
min-expiry-delay및max-expiry-delay값 사이의 만료가 있는 메시지의 경우 브로커는 메시지의 만료 시간을 변경하지 않습니다. -
expiration
-delay(기본값-1)에 대한 값을 지정하면min-expiry-delay및max-expiry-delay에 대해 지정한 값을 덮어씁니다. -
min-expiry-delay및max-expiry-delay의 기본값은-1입니다(즉, 비활성화됨).
-
기본 만료 시간이
구성 파일의 address 요소에서 이전에 지정한 address를 expiration
-address에 대해구성합니다.이 주소에 큐를 정의합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 앞의 예제 구성은 만료 큐인
ExpiryQueue를 만료 주소ExpiryAddress와 연결합니다.
4.12.2. 만료 리소스 자동 생성 링크 복사링크가 클립보드에 복사되었습니다!
일반적인 사용 사례는 원래 주소에 따라 만료된 메시지를 분류하는 것입니다. 예를 들어 인증서라는 주소에서 EXP.itemss 라는 만료 큐로 만료된 메시지를 라우팅하도록 선택할 수 있습니다. 마찬가지로 orders 라는 주소에서 EXP.orders 라는 만료 큐로 만료된 메시지를 라우팅할 수 있습니다.
이러한 유형의 라우팅 패턴을 사용하면 만료된 메시지를 쉽게 추적, 검사 및 관리할 수 있습니다. 그러나 이와 같은 패턴은 자동으로 생성된 주소 및 큐를 주로 사용하는 환경에서 구현하기 어렵습니다. 이러한 유형의 환경에서 관리자는 만료된 메시지를 유지하기 위해 주소와 큐를 수동으로 생성하는 데 필요한 추가 노력을 원하지 않습니다.
솔루션은 지정된 주소 또는 주소 집합에 대해 만료된 메시지를 처리하도록 리소스(즉, 주소 및 대기열)를 자동으로 생성하도록 브로커를 구성할 수 있습니다. 다음 절차에서는 예제를 보여줍니다.
사전 요구 사항
- 지정된 주소 또는 주소 집합에 대한 만료 주소를 이미 구성했습니다. 자세한 내용은 4.12.1절. “메시지 만료 구성”의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 구성 파일에 이전에 추가한 &
lt;address-setting> 요소를 찾아 일치하는 주소 또는 주소 집합에 대한 만료 주소를 정의합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow <
address-setting> 요소에서 브로커가 만료 리소스(즉, 주소 및 대기열)를 자동으로 생성하도록 지시하는 구성 항목과 이러한 리소스의 이름을 지정하는 방법을 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow auto-create-expiry-resources브로커가 만료된 메시지를 수신하기 위해 만료 주소 및 큐를 자동으로 생성하는지 여부를 지정합니다. 기본값은
false입니다.매개변수 값이
true로 설정되면 브로커는 만료주소와관련 만료 큐를 정의하는 <address> 요소를 자동으로 생성합니다. 자동 생성 <address> 요소의name 값은 에<expiry-address>지정된 name 값과 일치합니다.자동 생성된 만료 큐에는
멀티 캐스트라우팅 유형이 있습니다. 기본적으로 브로커 이름은 만료된 메시지가 원래 전송된 주소와 일치하도록 만료 큐의 이름을 지정합니다(예: 스포지).브로커는
_AMQ_ORIG_ADDRESS속성을 사용하는 만료 큐에 대한 필터도 정의합니다. 이 필터를 사용하면 만료 큐가 해당 원래 주소로 전송된 메시지만 수신합니다.expiry-queue-prefix브로커가 자동으로 생성된 만료 큐의 이름에 적용되는 접두사입니다. 기본값은
EXP입니다.접두사 값을 정의하거나 기본값을 유지하는 경우 만료 큐의 이름은 접두사와 원래 주소(예:
EXP.>-<s)의 연결입니다.expiry-queue-suffix- 브로커가 자동으로 생성된 만료 큐의 이름에 적용되는 접미사입니다. 기본값은 정의되지 않습니다(즉 브로커는 접미사를 적용하지 않음).
자체(예: AMQ Broker Core Protocol JMS 클라이언트를 사용하는 경우) 대기열 이름을 사용하거나 정규화된 큐 이름(예: 다른 JMS 클라이언트를 사용하는 경우)을 사용하여 만료 대기열에 직접 액세스할 수 있습니다.
만료 주소 및 큐가 자동으로 생성되므로 자동 생성된 주소 및 큐 삭제와 관련된 주소 설정도 이러한 만료 리소스에 적용됩니다.
추가 리소스
- 자동 생성된 주소 및 큐 자동 삭제를 구성하는 데 사용되는 주소 설정에 대한 자세한 내용은 4.8.2절. “주소 및 큐 자동 생성 및 삭제 구성” 을 참조하십시오.
4.13. 미전송되지 않은 메시지를 배달 못 한 편지 주소로 이동 링크 복사링크가 클립보드에 복사되었습니다!
클라이언트에 메시지 전달이 실패하면 브로커가 메시지를 지속적으로 전달하려고 시도하지 않을 수 있습니다. 무한한 전달 시도를 방지하기 위해, dead letter 주소와 하나 이상의 상승된 dead letter 큐 를 정의할 수 있습니다. 지정된 수의 전송 시도 후 브로커는 원래 큐에서 전달되지 않은 메시지를 제거하고 구성된 dead letter 주소로 메시지를 보냅니다. 나중에 시스템 관리자는 배달 못 한 편지 대기열에서 전달되지 않은 메시지를 사용하여 메시지를 검사할 수 있습니다.
지정된 큐에 대해 배달 못 한 주소를 구성하지 않으면 브로커는 지정된 전달 시도 횟수 후에 큐에서 전달되지 않은 메시지를 영구적으로 제거합니다.
배달되지 않은 메시지는 dead letter 큐에서 소비되는 다음과 같은 속성을 갖습니다.
_AMQ_ORIG_ADDRESS- 메시지의 원래 주소를 지정하는 string 속성
_AMQ_ORIG_QUEUE- 메시지의 원래 큐를 지정하는 string 속성
4.13.1. 배달 못 한 문자 주소 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 dead letter 주소 및 관련 dead letter 큐를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 큐 이름과 일치하는 <
address-setting> 요소에서 dead letter address name 및 최대 전달 시도 수를 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow match-
브로커가 이
address-setting섹션의 구성을 적용하는 주소입니다. <address-setting> 요소의match속성에 와일드카드 표현식을 지정할 수 있습니다. 와일드카드 표현식을 사용하면 <address-setting> 요소에서 구성된 dead letter 설정을 일치하는 주소 세트 와 연결하려는 경우 유용합니다. dead-letter-address- dead letter 주소의 이름입니다. 이 예제에서 브로커는 큐 예제Queue 에서 전달되지 않은 메시지를 dead letter 주소 DLA 로 이동합니다.
max-delivery-attempts-
브로커가 구성된 배달되지 않은 메시지를 구성된 dead letter 주소로 이동하기 전에 최대 전달 시도 횟수입니다. 이 예에서 브로커는 실패한 전달 시도에 세 번 실패한 후 배달되지 않은 메시지를 배달 못 한 편지 주소로 이동합니다. 기본값은
10입니다. 브로커가 무제한의 재전송 시도 횟수를 만들려면 값-1을 지정합니다.
addresses섹션에서 dead letter 주소에 대한address요소 DLA 를 추가합니다. 배달 못 한 큐를 배달 못 한 편지 주소와 연결하려면큐의 이름 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
앞의 구성에서 DLQ 라는 dead letter 큐를 dead letter address DLA 와 연결합니다.
추가 리소스
- 주소 설정에서 와일드카드를 사용하는 방법에 대한 자세한 내용은 4.2절. “주소 집합에 주소 설정 적용” 을 참조하십시오.
4.13.2. 배달 못 한 문자 대기열 자동 생성 링크 복사링크가 클립보드에 복사되었습니다!
일반적인 사용 사례는 원래 주소에 따라 전달되지 않은 메시지를 분류하는 것입니다. 예를 들어, 줄임말 큐로 전달되지 않은 메시지를 라우팅하도록 선택할 수 있습니다. 마찬가지로 orders라는 주소에서 전달되지 않은 메시지를 스톡 이라는 주소에서 DLQ.products라고 하는 dead letter 큐가 있는 DLA.DLA. 라는 dead letter 주소로 라우팅할 수 있습니다.
orders
이러한 유형의 라우팅 패턴을 사용하면 전달되지 않은 메시지를 쉽게 추적, 검사 및 관리할 수 있습니다. 그러나 이와 같은 패턴은 자동으로 생성된 주소 및 큐를 주로 사용하는 환경에서 구현하기 어렵습니다. 이러한 유형의 환경에 대한 시스템 관리자는 전달되지 않은 메시지를 유지하기 위해 주소 및 대기열을 수동으로 생성하는 데 필요한 추가 노력을 원하지 않을 수 있습니다.
해결 방법으로 다음 절차에 표시된 것처럼 주소 및 큐를 자동으로 생성하여 전달되지 않은 메시지를 처리하도록 브로커를 구성할 수 있습니다.
사전 요구 사항
- 대기열 또는 큐 집합에 대해 이미 배달 못 한 주소를 구성했습니다. 자세한 내용은 4.13.1절. “배달 못 한 문자 주소 구성”의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 일치하는 큐 또는 큐 집합에 대한 dead letter
주소를 정의하기 위해 이전에 추가한 <address-setting> 요소를 찾습니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow <
address-setting> 요소에서 브로커가 종료된 문자 리소스(즉, 주소 및 대기열) 및 이러한 리소스의 이름을 지정하는 방법을 자동으로 생성하도록 지시하는 구성 항목을 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow auto-create-dead-letter-resources브로커가 배달되지 않은 메시지를 수신하기 위해 배달 못 한 주소와 큐를 자동으로 생성하는지 여부를 지정합니다. 기본값은
false입니다.auto-create-dead-letter-resources가true로 설정된 경우 브로커는 배달 못 한주소와연관된 dead letter 큐를 정의하는 <address> 요소를 자동으로 생성합니다. 자동 생성 된 <address> 요소의 이름은 <dead-letter-address>에 대해 지정한 name 값과 일치합니다.브로커가 자동으로 생성된 <
address> 요소에 정의하는 dead letter 큐는멀티캐스트라우팅 유형이 있습니다. 기본적으로 브로커는 배달되지 않은 메시지의 원래 주소와 일치하도록 dead letter 큐의 이름을 지정합니다(예: 스포지트).브로커는
_AMQ_ORIG_ADDRESS속성을 사용하는 dead letter 큐에 대한 필터도 정의합니다. 이 필터는 배달 못 한 큐가 해당 원래 주소로 전송된 메시지만 수신하도록 합니다.dead-letter-queue-prefix브로커가 자동으로 생성된 dead letter 큐의 이름에 적용되는 접두사입니다. 기본값은
DLQ입니다.접두사 값을 정의하거나 기본값을 유지하는 경우 dead letter 큐의 이름은 접두사와 원래 주소(예:
DLQ.>-<s)의 연결입니다.dead-letter-queue-suffix- 브로커가 자동 생성된 dead letter 큐에 적용되는 접미사입니다. 기본값은 정의되지 않습니다(즉 브로커는 접미사를 적용하지 않음).
4.14. 만료된 또는 전달되지 않은 AMQP 메시지의 주석 및 속성 링크 복사링크가 클립보드에 복사되었습니다!
브로커가 만료되거나 전달되지 않은 AMQP 메시지를 구성한 만료 또는 배달 해제된 큐로 이동하기 전에 브로커는 주석과 속성을 메시지에 적용합니다. 클라이언트는 이러한 속성 또는 주석을 기반으로 필터를 생성하여 만료 또는 배달 못 한 큐에서 사용할 특정 메시지를 선택할 수 있습니다.
브로커가 적용하는 속성은 내부 속성입니다. 이러한 속성은 정기적으로 사용하기 위해 클라이언트에 노출되지 않지만 필터의 클라이언트에서 지정 할 수 있습니다.
다음 표는 브로커가 만료된 또는 전달되지 않은 AMQP 메시지에 적용하는 주석 및 내부 속성을 보여줍니다.
| 주석 이름 | 내부 속성 이름 | 설명 |
|---|---|---|
| x-opt-ORIG-MESSAGE-ID | _AMQ_ORIG_MESSAGE_ID | 메시지가 만료 또는 배달 못 한 큐로 이동되기 전에 원본 메시지 ID입니다. |
| x-opt-ACTUAL-EXPIRY | _AMQ_ACTUAL_EXPIRY | 마지막 epoch가 시작된 이후 경과 시간(밀리초)으로 지정된 메시지 만료 시간입니다. |
| x-opt-ORIG-QUEUE | _AMQ_ORIG_QUEUE | 만료된 메시지 또는 전달되지 않은 메시지의 원래 큐 이름입니다. |
| x-opt-ORIG-ADDRESS | _AMQ_ORIG_ADDRESS | 만료된 메시지 또는 전달되지 않은 메시지의 원래 주소 이름입니다. |
추가 리소스
- 주석에 따라 AMQP 메시지를 필터링하도록 AMQP 클라이언트를 구성하는 예는 13.3절. “주석의 속성에 따라 AMQP 메시지 필터링” 를 참조하십시오.
4.15. 큐 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
브로커 구성에 큐를 수동으로 정의하면 큐가 기본적으로 활성화됩니다.
그러나 클라이언트가 구독할 수 있지만 메시지 라우팅에 큐를 사용할 준비가 되지 않도록 큐를 정의하려는 경우가 있을 수 있습니다. 또는 큐에 대한 메시지 흐름을 중지하려고 하지만 클라이언트를 큐에 바인딩하는 경우도 있을 수 있습니다. 이 경우 큐를 비활성화할 수 있습니다.
다음 예제에서는 브로커 구성에 정의된 큐를 비활성화하는 방법을 보여줍니다.
사전 요구 사항
- 브로커 구성에서 주소 및 관련 대기열을 정의하는 방법에 대해 잘 알고 있어야 합니다. 자세한 내용은 4장. 주소 및 대기열 구성의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 이전에 정의한 큐의 경우
enabled특성을 추가합니다. 큐를 비활성화하려면 이 속성의 값을false로 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow enabled속성의 기본값은true입니다. 값을false로 설정하면 큐에 대한 메시지 라우팅이 비활성화됩니다.
주소에서 모든 큐를 비활성화하면 해당 주소로 전송된 모든 메시지가 자동으로 삭제됩니다.
4.16. 큐에 연결된 소비자 수 제한 링크 복사링크가 클립보드에 복사되었습니다!
max-consumers 특성을 사용하여 특정 큐에 연결된 소비자 수를 제한합니다. max-consumers 플래그를 1 로 설정하여 전용 소비자를 생성합니다. 기본값은 -1 이며 무제한 소비자 수를 설정합니다.
다음 절차에서는 큐에 연결할 수 있는 소비자 수에 대한 제한을 설정하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 지정된 큐의 경우
max-consumers키를 추가하고 값을 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 앞의 구성에 따라 20명의 소비자만 대기열
q3에 동시에 연결할 수 있습니다.전용 소비자를 생성하려면
max-consumers를1로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 무제한 소비자를 허용하려면
max-consumers를-1로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.17. 전용 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
전용 큐는 모든 메시지를 한 번에 하나의 소비자로만 라우팅하는 특수 큐입니다. 이 구성은 모든 메시지를 동일한 소비자가 직렬로 처리하도록 할 때 유용합니다. 큐에 대해 여러 소비자가 있는 경우 하나의 소비자만 메시지를 수신합니다. 해당 소비자가 큐에서 연결이 끊어지면 다른 소비자가 선택됩니다.
4.17.1. 개별적으로 전용 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 지정된 큐를 독점적으로 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 지정된 큐에 대해
전용키를 추가합니다. 값을true로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.17.2. 주소에 대한 배타적 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 연결된 모든 큐가 독점적이 되도록 주소 또는 주소 집합을 구성하는 방법을 보여줍니다.
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. address-setting요소에서 일치하는 주소에 대해default-exclusive-queue키를 추가합니다. 값을true로 설정합니다.<address-setting match="myAddress"> <default-exclusive-queue>true</default-exclusive-queue> </address-setting><address-setting match="myAddress"> <default-exclusive-queue>true</default-exclusive-queue> </address-setting>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 앞의 구성에 따라
myAddress주소와 연결된 모든 대기열은 배타적입니다. 기본적으로default-exclusive-queue의 값은false입니다.주소 집합에 대해 배타적 대기열을 구성하려면 주소 와일드카드를 지정할 수 있습니다. 예를 들면 다음과 같습니다.
<address-setting match="myAddress.*"> <default-exclusive-queue>true</default-exclusive-queue> </address-setting><address-setting match="myAddress.*"> <default-exclusive-queue>true</default-exclusive-queue> </address-setting>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 리소스
- 주소를 구성할 때 사용할 수 있는 와일드카드 구문에 대한 자세한 내용은 4.2절. “주소 집합에 주소 설정 적용” 을 참조하십시오.
4.18. 임시 큐에 특정 주소 설정 적용 링크 복사링크가 클립보드에 복사되었습니다!
예를 들어 JMS를 사용하는 경우 브로커는 UUID(Universally unique identifier)를 주소 이름과 큐 이름 둘 다로 할당하여 임시 대기열 을 생성합니다.
기본 < address-setting match="#" >은 구성된 주소 설정을 임시 큐를 포함하여 모든 큐에 적용합니다. 임시 큐에만 특정 주소 설정을 적용하려면 아래에 설명된 대로 임시 대기열-네임 스페이스를 지정할 수 있습니다. 그런 다음 네임스페이스와 일치하는 주소 설정을 지정하고 브로커는 해당 설정을 모든 임시 큐에 적용할 수 있습니다.
임시 대기열이 생성되고 임시 큐 네임스페이스가 있는 경우 브로커는 temporary-queue-namespace 값보다 우선하고 구성된 구분 기호(기본값 . .)를 주소 이름에 추가합니다. 이를 사용하여 일치하는 주소 설정을 참조합니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. temporary-queue-namespace값을 추가합니다. 예를 들면 다음과 같습니다.<temporary-queue-namespace>temp-example</temporary-queue-namespace>
<temporary-queue-namespace>temp-example</temporary-queue-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 임시 대기열 네임스페이스에 해당하는
일치값이 있는address-setting요소를 추가합니다. 예를 들면 다음과 같습니다.<address-settings> <address-setting match="temp-example.#"> <enable-metrics>false</enable-metrics> </address-setting> </address-settings><address-settings> <address-setting match="temp-example.#"> <enable-metrics>false</enable-metrics> </address-setting> </address-settings>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 예제에서는 브로커가 생성한 모든 임시 큐에서 메트릭을 비활성화합니다.
참고임시 큐 네임스페이스를 지정하면 임시 큐에 영향을 미치지 않습니다. 예를 들어 네임스페이스는 임시 대기열의 이름을 변경하지 않습니다. 네임스페이스는 임시 대기열을 참조하는 데 사용됩니다.
추가 리소스
- 주소 설정에서 와일드카드를 사용하는 방법에 대한 자세한 내용은 4.2절. “주소 집합에 주소 설정 적용” 을 참조하십시오.
4.19. 링 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
일반적으로 AMQ Broker의 대기열은 first-in, first-out (FIFO) 의미 체계를 사용합니다. 즉, 브로커는 메시지를 큐의 테두리에 추가하고 헤드에서 제거합니다. 링 큐는 지정된 고정 메시지 수를 보유하는 특수한 유형의 큐입니다. 브로커는 새 메시지가 도착하지만 큐에 이미 지정된 메시지 수를 보유하면 큐의 헤드에서 메시지를 제거하여 고정된 대기열 크기를 유지합니다.
예를 들어, 크기 3 으로 구성된 링 대기열과 메시지 A,B,C, D 를 순차적으로 전송하는 생산자가 있다고 가정합니다. C 메시지가 큐에 도달하면 큐의 메시지 수가 구성된 링 크기에 도달했습니다. 이 시점에서 메시지 A 는 큐의 헤드에 있고, 메시지 C 는 tail에 있습니다. 메시지 D 가 큐에 도달하면 브로커는 메시지를 큐의 tail에 추가합니다. 고정된 큐 크기를 유지하기 위해 브로커는 큐의 헤드에 있는 메시지를 제거합니다(즉, 메시지 A). 이제 메시지 B 가 큐의 헤드에 있습니다.
4.19.1. 링 대기열 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 링 큐를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 명시적 링 크기 세트가 없는 일치하는 주소의 모든 큐에 대한 기본 링 크기를 정의하려면
address-setting요소에서default-ring-size의 값을 지정합니다. 예를 들면 다음과 같습니다.<address-settings> <address-setting match="ring.#"> <default-ring-size>3</default-ring-size> </address-setting> </address-settings><address-settings> <address-setting match="ring.#"> <default-ring-size>3</default-ring-size> </address-setting> </address-settings>Copy to Clipboard Copied! Toggle word wrap Toggle overflow default-ring-size매개변수는 자동 생성된 대기열의 기본 크기를 정의하는 데 특히 유용합니다.default-ring-size의 기본값은-1입니다(즉, 크기 제한 없음).특정 큐에서 링 크기를 정의하려면
queue요소에ring-size키를 추가합니다. 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
브로커가 실행되는 동안 ring-size 의 값을 업데이트할 수 있습니다. 브로커가 업데이트를 동적으로 적용합니다. 새 ring-size 값이 이전 값보다 작으면 브로커는 새 크기를 적용하기 위해 대기열의 헤드에서 메시지를 즉시 삭제하지 않습니다. 큐로 전송된 새 메시지는 이전 메시지의 삭제 작업을 계속 수행하지만 대기열은 클라이언트의 정상적인 메시지 사용을 통해 당연히 그렇게 할 때까지 큐가 새로운 크기에 도달하지 않습니다.
4.19.2. 링 대기열 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 링 큐의 동작이 구성과 다른 것으로 표시되는 상황을 설명합니다.
In-delivery messages and rollbacks
메시지가 소비자에게 전달 중일 때 메시지는 "중간" 상태에 있습니다. 여기서 메시지는 기술적으로 큐에서 더 이상 없지만 아직 승인되지 않았습니다. 메시지는 소비자가 승인할 때까지 전송 중 상태로 유지됩니다. in-delivery 상태에 남아 있는 메시지는 링 대기열에서 제거할 수 없습니다.
브로커가 전송 중인 메시지를 제거할 수 없기 때문에 클라이언트는 링 크기 구성에서 허용하는 것보다 링 큐에 더 많은 메시지를 보낼 수 있습니다. 예를 들어 다음 시나리오를 고려하십시오.
-
생산자는
ring-size="3"로 구성된 링 큐에 세 개의 메시지를 보냅니다. 모든 메시지는 즉시 소비자에게 전달됩니다.
이 시점에서
messageCount=3및deliveringCount=3입니다.생산자는 또 다른 메시지를 큐에 보냅니다. 그런 다음 메시지가 소비자에게 전달됩니다.
이제
messageCount=4및deliveringCount=4입니다.4의 메시지 수는 구성된 링 크기3보다 큽니다. 그러나 브로커는 큐에서 전달 중인 메시지를 제거할 수 없기 때문에 이러한 상황을 허용할 수 있습니다.이제 소비자가 메시지를 승인하지 않고 닫히고 있다고 가정합니다.
이 경우 인증되지 않은 4개의 메시지가 브로커에 다시 취소되고 사용된 반대 순서로 큐 헤드에 추가됩니다. 이 작업은 구성된 링 크기에 큐를 둡니다. 링 대기열은 헤드의 메시지 위에 있는 큐의 tail의 메시지를 선호하므로 대기열은 대기열의 헤드에 다시 추가된 마지막 메시지가기 때문에 큐에서 보낸 첫 번째 메시지를 삭제합니다. 트랜잭션 또는 코어 세션 롤백은 동일한 방식으로 처리됩니다.
코어 클라이언트를 직접 사용하거나 AMQ Core Protocol JMS 클라이언트를 사용하는 경우 consumerWindowSize 매개변수(1024 * 1024바이트)의 값을 줄임으로써 전달 중인 메시지 수를 최소화할 수 있습니다.
예약된 메시지
예약된 메시지가 큐로 전송되면 일반 메시지와 같이 큐의 tail에 메시지가 즉시 추가되지 않습니다. 대신 브로커는 예약된 메시지를 중간 버퍼에 보관하고 메시지의 세부 정보에 따라 큐의 헤드로 전달할 메시지를 예약합니다. 그러나 예약된 메시지는 여전히 대기열의 메시지 수에 반영됩니다. in-delivery 메시지와 마찬가지로 이 동작은 브로커가 링 대기열 크기를 적용하지 않는 것처럼 보일 수 있습니다. 예를 들어 다음 시나리오를 고려하십시오.
12:00에서 생산자는
ring-size="3"로 구성된 링 큐에A라는 메시지를 보냅니다. 메시지가 12:05에 대해 예정되어 있습니다.이 시점에서
messageCount=1및scheduledCount=1.12:01에서 생산자는 메시지
B를 동일한 링 대기열에 보냅니다.이제
messageCount=2및scheduledCount=1입니다.12:02에서 생산자는
C메시지를 동일한 링 대기열에 보냅니다.이제
messageCount=3및scheduledCount=1입니다.12:03에서 생산자는 메시지를 동일한 링 대기열에 보냅니다.
이제
messageCount=4및scheduledCount=1입니다.큐의 메시지 수는 이제 구성된 링 크기인
3개보다 1개 큰4입니다. 그러나 예약된 메시지는 아직 큐에 기술적으로 표시되지 않습니다(즉, 브로커에 있으며 대기열에 배치되도록 예약됨). 예약된 제공 시간인 12:05에서 브로커는 큐의 헤드에 메시지를 넣습니다. 그러나 링 큐가 이미 구성된 크기에 도달했기 때문에 예약된 메시지A가 즉시 제거됩니다.
페이징 메시지
예약된 메시지 및 전달 메시지와 유사하게 paged 메시지는 브로커가 시행하는 링 대기열 크기로 계산되지 않습니다. 메시지는 대기열 수준이 아닌 주소 수준에서 실제로 페이징되기 때문입니다. 호출된 메시지는 기술적으로 큐에 표시되지 않지만 큐의 messageCount 값에 반영됩니다.
링 큐가 있는 주소에는 페이징을 사용하지 않는 것이 좋습니다. 대신 전체 주소가 메모리에 적합할 수 있는지 확인합니다. 또는 address-full-policy 매개변수를 DROP,BLOCK 또는 FAIL 값으로 구성합니다.
추가 리소스
- 브로커는 소급 주소를 구성할 때 링 대기열의 내부 인스턴스를 생성합니다. 자세한 내용은 4.20절. “retroactive 주소 구성” 에서 참조하십시오.
4.20. retroactive 주소 구성 링크 복사링크가 클립보드에 복사되었습니다!
주소를 retroactive 로 구성하면 아직 주소에 바인딩된 큐가 없는 경우를 포함하여 해당 주소로 전송된 메시지를 보존할 수 있습니다. 나중에 큐가 생성되고 주소에 바인딩되면 브로커는 해당 큐에 메시지를 소급적으로 배포합니다. 주소가 retroactive로 구성되지 않고 아직 큐가 바인딩되지 않은 경우 브로커는 해당 주소로 전송된 메시지를 삭제합니다.
retroactive 주소를 구성하면 브로커는 링 큐로 알려진 큐 유형의 내부 인스턴스를 생성합니다. 링 큐는 지정된 고정 메시지 수를 보유하는 특수한 유형의 큐입니다. 큐가 지정된 크기에 도달하면 큐에 도달하는 다음 메시지가 큐에서 가장 오래된 메시지에서 강제 적용됩니다. 소급 주소를 구성할 때 내부 링 대기열의 크기를 간접적으로 지정합니다. 기본적으로 내부 큐는 멀티 캐스트 라우팅 유형을 사용합니다.
retroactive 주소에서 사용하는 내부 링 대기열은 관리 API를 통해 노출됩니다. 큐 비우기와 같은 메트릭을 검사하고 기타 일반적인 관리 작업을 수행할 수 있습니다. 링 큐는 또한 주소의 전체 메모리 사용량에 기여하여 메시지 페이징과 같은 동작에 영향을 미칩니다.
다음 절차에서는 주소를 retroactive로 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. address-setting요소에서retroactive-message-count매개변수 값을 지정합니다. 지정한 값은 브로커를 보존할 메시지 수를 정의합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고브로커가 실행되는 동안
broker.xml구성 파일 또는 관리 API에서retroactive-message-count값을 업데이트할 수 있습니다. 그러나 이 매개변수의 값을 줄이는 경우 링 큐를 통해 retroactive 주소가 구현되므로 추가 단계가 필요합니다.ring-size매개변수가 감소된 링 대기열은 새ring-size값을 달성하기 위해 대기열에서 메시지를 자동으로 삭제하지 않습니다. 이 동작은 의도하지 않은 메시지 손실을 방지합니다. 이 경우 관리 API를 사용하여 링 큐의 메시지 수를 수동으로 줄여야 합니다.
추가 리소스
- 링 큐에 대한 자세한 내용은 4.19절. “링 대기열 구성” 을 참조하십시오.
4.21. 내부적으로 관리되는 주소 및 큐에 대한 권고 메시지 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 AMQ Broker는 OpenForwardedre 클라이언트가 브로커에 연결되어 있을 때 주소 및 큐에 대한 권고 메시지를 생성합니다. 권고 메시지는 브로커가 생성한 내부 관리 주소로 전송됩니다. 이러한 주소는 사용자가 배포한 주소 및 대기열과 동일한 디스플레이 내의 AMQ 관리 콘솔에 표시됩니다. 이는 유용한 정보를 제공하지만 권고 메시지는 브로커가 많은 수의 대상을 관리할 때 바람직하지 않은 결과를 초래할 수 있습니다. 예를 들어, 메시지는 메모리 사용량을 늘리거나 연결 리소스가 손상될 수 있습니다. 또한 권고 메시지를 보내기 위해 생성된 모든 주소를 표시하려고 할 때 AMQ Management Console이 혼란스러울 수 있습니다. 이러한 상황을 방지하려면 다음 매개변수를 사용하여 브로커에 대한 권고 메시지 동작을 구성할 수 있습니다.
supportAdvisory-
권고 메시지 또는
false를 생성하여 비활성화하려면 이 옵션을true로 설정합니다. 기본값은true입니다. suppressInternalManagementObjects-
권고 메시지를 10.0.0.1 레지스트리 및 AMQ Management Console과 같은 관리 서비스에 노출하려면 이 옵션을
true로 설정하거나 이를 노출하지 않으려면false로 설정합니다. 기본값은true입니다.
다음 절차에서는 브로커에서 권고 메시지를 비활성화하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. Open>-<re 커넥터의 경우
supportAdvisory및suppressInternalManagementObjects매개변수를 구성된 URL에 추가합니다. 이 섹션의 앞부분에서 설명한 대로 값을 설정합니다. 예를 들면 다음과 같습니다.<acceptor name="artemis">tcp://127.0.0.1:61616?protocols=CORE,AMQP,OPENWIRE;supportAdvisory=false;suppressInternalManagementObjects=false</acceptor>
<acceptor name="artemis">tcp://127.0.0.1:61616?protocols=CORE,AMQP,OPENWIRE;supportAdvisory=false;suppressInternalManagementObjects=false</acceptor>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.22. 주소 및 대기열 페더링 링크 복사링크가 클립보드에 복사되었습니다!
페더레이션을 사용하면 브로커가 공통 클러스터에 있을 필요 없이 브로커 간에 메시지를 전송할 수 있습니다. 브로커는 독립 실행형 또는 별도의 클러스터에 있을 수 있습니다. 또한 소스 및 대상 브로커는 다른 관리 도메인에 있을 수 있으므로 브로커의 구성, 사용자 및 보안 설정이 다를 수 있습니다. 브로커는 다른 AMQ Broker 버전을 사용할 수도 있습니다.
예를 들어, 페더레이션은 한 클러스터에서 다른 클러스터로 메시지를 안정적으로 보내는 데 적합합니다. 이 전송은 WAN(Wide Area Network), 클라우드 인프라의 리전 또는 인터넷을 통해 발생할 수 있습니다. 소스 브로커에서 대상 브로커로의 연결이 끊어지면(예: 네트워크 장애로 인해) 대상 브로커가 온라인 상태가 될 때까지 연결을 다시 설정하려고 합니다. 대상 브로커가 다시 온라인 상태가 되면 메시지 전송이 재개됩니다.
관리자는 주소 및 대기열 정책을 사용하여 페더레이션을 관리할 수 있습니다. 정책 구성은 특정 주소 또는 큐와 일치하거나 정책에 주소 또는 큐 세트 와 구성과 일치하는 와일드카드 표현식을 포함할 수 있습니다. 따라서, 페더레이션은 큐 또는 주소가 일치 세트에 추가되거나 제거될 때 동적으로 적용될 수 있습니다. 정책에는 특정 주소 및 큐를 포함하거나 제외하는 여러 표현식이 포함될 수 있습니다. 또한 브로커 또는 브로커 클러스터에 여러 정책을 적용할 수 있습니다.
AMQ Broker에서 두 가지 주요 페더레이션 옵션은 주소 페더레이션 및 대기열 페더레이션 입니다. 이러한 옵션은 다음 섹션에 설명되어 있습니다.
브로커에는 페더레이션 및 로컬 전용 구성 요소에 대한 구성이 포함될 수 있습니다. 즉, 브로커에 페더레이션을 구성하면 해당 브로커의 모든 것을 페더레이션할 필요가 없습니다.
4.22.1. 주소 페더레이션 정보 링크 복사링크가 클립보드에 복사되었습니다!
주소 페더레이션은 연결된 브로커 간의 전체 멀티 캐스트 배포 패턴과 같습니다. 예를 들어 BrokerA 의 주소로 전송된 모든 메시지는 해당 브로커의 모든 큐에 전달됩니다. 또한 각 메시지는 BrokerB 및 여기에 연결된 모든 큐에 전달됩니다.
주소 페더레이션은 원격 브로커의 주소에 브로커를 동적으로 연결합니다. 예를 들어 로컬 브로커가 원격 브로커의 주소에서 메시지를 가져오려는 경우 원격 주소에 큐가 자동으로 생성됩니다. 그러면 원격 브로커의 메시지가 이 큐로 사용됩니다. 마지막으로 메시지는 원래 로컬 주소에 직접 게시 된 것처럼 로컬 브로커의 해당 주소에 복사됩니다.
원격 브로커는 페더레이션이 주소를 만들 수 있도록 재구성할 필요가 없습니다. 그러나 로컬 브로커에 원격 주소에 대한 권한을 부여해야 합니다.
4.22.2. 주소 페더레이션의 일반적인 토폴로지 링크 복사링크가 클립보드에 복사되었습니다!
주소 페더레이션 사용에 대한 몇 가지 일반적인 토폴로지는 아래에 설명되어 있습니다.
- 대칭 토폴로지
대칭 토폴로지에서 생산자와 소비자는 각 브로커에 연결됩니다. 대기열과 소비자는 생산자가 게시한 메시지를 수신할 수 있습니다. 다음은 대칭 토폴로지의 예입니다.
그림 4.1. 대칭 토폴로지의 주소 페더레이션
대칭 토폴로지에 대한 주소 페더레이션을 구성할 때 주소 정책의
max-hops속성 값을1로 설정하는 것이 중요합니다. 이렇게 하면 순환 복제를 방지하여 메시지가 한 번만 복사됩니다. 이 속성이 더 큰 값으로 설정된 경우 소비자는 동일한 메시지의 복사본을 여러 개 받습니다.- 전체 메시 토폴로지
전체 메시 토폴로지는 대칭 설정과 유사합니다. 3 개 이상의 브로커가 서로 대칭적으로 페더레이션되어 전체 메시를 생성합니다. 이 설정에서 생산자와 소비자는 각 브로커에 연결됩니다. 큐 및 소비자는 프로듀서에서 게시한 메시지를 수신할 수 있습니다. 이 토폴로지의 예는 다음과 같습니다.
그림 4.2. 전체 메시 토폴로지의 주소 페더레이션
대칭 설정과 마찬가지로 전체 메시 토폴로지에 대한 주소 페더레이션을 구성할 때 주소 정책의
max-hops속성 값을1로 설정하는 것이 중요합니다. 이렇게 하면 순환 복제를 방지하여 메시지가 한 번만 복사됩니다.- 링 토폴로지
브로커 링에서 각 페더레이션 주소는 링의 서로만 업스트림으로 지정됩니다. 이 토폴로지의 예는 다음과 같습니다.
그림 4.3. 링 토폴로지의 주소 페더레이션
순환 복제를 방지하기 위해 링 토폴로지에 대한 페더레이션을 구성할 때 주소 정책의
max-hops속성을n-1값으로 설정하는 것이 중요합니다. 여기서 n 은 링의 노드 수입니다. 예를 들어 위에 표시된 링 토폴로지에서max-hops값은5로 설정됩니다. 이렇게 하면 링의 모든 주소가 정확히 한 번 메시지를 볼 수 있습니다.링 토폴로지의 장점은 설정해야 하는 물리적 연결 수와 관련하여 설정 비용이 저렴합니다. 그러나 이러한 유형의 토폴로지의 단점은 단일 브로커가 실패하면 전체 링이 실패한다는 것입니다.
- 페인아웃 토폴로지
팬아웃 토폴로지에서는 단일 마스터 주소가 페더레이션 주소 트리에 의해 연결됩니다. 마스터 주소에 게시된 모든 메시지는 트리의 모든 브로커에 연결된 모든 소비자가 수신할 수 있습니다. 트리는 모든 깊이로 구성할 수 있습니다. 트리의 기존 브로커를 다시 구성할 필요 없이 트리를 확장할 수도 있습니다. 이 토폴로지의 예는 다음과 같습니다.
그림 4.4. 팬아웃 토폴로지의 페더레이션 주소
팬아웃 토폴로지에 대한 페더레이션을 구성할 때 주소 정책의
max-hops속성을n-1값으로 설정했는지 확인합니다. 여기서 n 은 트리의 수준 수입니다. 예를 들어 위에 표시된 팬아웃 토폴로지에서는max-hops값이2로 설정됩니다. 이렇게 하면 트리의 모든 주소가 메시지를 정확히 한 번 볼 수 있습니다.
4.22.3. 주소 페더레이션 구성에서의 반전 바인딩 지원 링크 복사링크가 클립보드에 복사되었습니다!
주소 페더레이션을 구성할 때 주소 정책 구성에서 반전 바인딩에 대한 지원을 추가할 수 있습니다. 이러한 지원을 추가하면 페더레이션이 원격 브로커의 지정된 주소에 대한 페더레이션 소비자를 생성하기 위해 일괄 바인딩에 응답할 수 있습니다.
예를 들어 test.federation.source 라는 주소가 주소 정책에 포함되어 있고 test.federation.target 이라는 다른 주소가 포함되어 있지 않다고 가정합니다. 일반적으로 test.federation.target 에서 큐 가 생성되면 주소가 주소 정책의 일부가 아니기 때문에 페더레이션 소비자가 생성되지 않습니다. 그러나 test.federation.source 가 소스 주소이고 test.federation.target 이 전달 주소입니다. 소스 주소는 여전히 멀티캐스트 라우팅 유형을 사용해야 하지만 대상 주소는 멀티 캐스트 또는 사용할 수 있습니다.
anycast 를
사용 사례의 예로는 JMS 주제(다중 주소)를 JMS 대기열(anycast 주소)으로 리디렉션하는 경우가 있습니다. 이를 통해 JMS 2.0 및 공유 서브스크립션을 지원하지 않는 레거시 소비자에 대한 메시지의 부하 분산이 가능합니다.
4.22.4. 브로커 클러스터의 페더레이션 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 섹션의 예제에서는 독립 실행형 로컬 브로커와 원격 브로커 간의 주소 및 대기열 통합을 구성하는 방법을 보여줍니다. 독립 실행형 브로커 간의 페더레이션의 경우 페더레이션 구성의 이름과 주소 및 대기열 정책의 이름은 로컬 및 원격 브로커 간에 고유해야 합니다.
그러나 클러스터에서 브로커에 대한 페더레이션을 구성하는 경우 추가 요구 사항이 있습니다. 클러스터형 브로커의 경우 페더레이션 구성의 이름과 해당 구성 내의 주소 및 대기열 정책의 이름은 해당 클러스터의 모든 브로커에 대해 동일해야 합니다.
동일한 클러스터의 브로커가 동일한 페더레이션 구성 및 주소 및 대기열 정책 이름을 사용하도록 하여 메시지 중복을 방지합니다. 예를 들어, 동일한 클러스터 내의 브로커에 페더레이션 구성 이름이 다른 경우 동일한 주소에 대해 다르게 이름이 지정된 전달 대기열이 여러 개 생성되어 다운스트림 소비자에게 메시지가 복제되는 상황이 발생할 수 있습니다. 반대로 동일한 클러스터의 브로커가 동일한 페더레이션 구성 이름을 사용하는 경우 기본적으로 다운스트림 소비자에게 부하 분산되는 복제된 클러스터형 전달 대기열을 생성합니다. 이렇게 하면 메시지 중복을 방지할 수 있습니다.
4.22.5. 업스트림 주소 페더레이션 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제는 독립 실행형 브로커 간에 업스트림 주소 페더레이션을 구성하는 방법을 보여줍니다. 이 예제에서는 로컬(즉, 다운스트림) 브로커에서 일부 원격(즉, 업스트림) 브로커로 페더레이션을 구성합니다.
사전 요구 사항
- 다음 예제에서는 독립 실행형 브로커 간 주소 통합을 구성하는 방법을 보여줍니다. 그러나 브로커 클러스터에 대한 페더레이션을 구성하기 위한 요구 사항도 잘 알고 있어야 합니다. 자세한 내용은 4.22.4절. “브로커 클러스터의 페더레이션 구성”의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
federation> 요소를 포함하는 새 <요소를 추가합니다. 예를 들면 다음과 같습니다.federations><federations> <federation name="eu-north-1" user="federation_username" password="32a10275cf4ab4e9"> </federation> </federations>
<federations> <federation name="eu-north-1" user="federation_username" password="32a10275cf4ab4e9"> </federation> </federations>Copy to Clipboard Copied! Toggle word wrap Toggle overflow name- 페더레이션 구성의 이름입니다. 이 예에서 name은 로컬 브로커의 이름에 해당합니다.
user- 업스트림 브로커에 연결하기 위한 공유 사용자 이름입니다.
암호- 업스트림 브로커에 연결하기 위한 공유 암호입니다.
참고원격 브로커에 대해 사용자 및 암호 인증 정보가 다른 경우 구성에 추가할 때 해당 브로커의 인증 정보를 별도로 지정할 수 있습니다. 이 내용은 이 절차의 뒷부분에서 설명합니다.
페더레이션요소 내에서 <address-policy> 요소를추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow name- 주소 정책의 이름입니다. 브로커에 구성된 모든 주소 정책에는 고유한 이름이 있어야 합니다.
auto-delete-
주소 페더레이션 중에 로컬 브로커는 원격 주소에 내재된 큐를 동적으로 생성합니다. 자동 삭제 속성 값은 로컬 브로커의 연결을 끊고
auto-delete-delay 및속성의 값도 연결되면 원격 큐를 삭제해야 하는지 여부를 지정합니다. 동적으로 생성된 대기열의 정리를 자동화하려는 경우 유용한 옵션입니다. 로컬 브로커가 오랫동안 연결이 끊어진 경우 원격 브로커의 메시지 빌드를 방지하려는 경우에도 유용한 옵션입니다. 그러나 연결이 끊긴 동안 메시지가 항상 로컬 브로커에 대해 대기 상태로 유지되도록 하려면 이 옵션을auto-delete-message-countfalse로 설정하여 로컬 브로커에서 메시지 손실을 방지할 수 있습니다. auto-delete-delay- 로컬 브로커의 연결이 끊어지면 이 속성의 값은 동적으로 생성된 원격 대기열을 자동으로 삭제할 수 있기 전에 시간(밀리초)을 지정합니다.
auto-delete-message-count- 로컬 브로커의 연결이 끊어진 후 이 속성의 값은 해당 큐가 자동으로 삭제되기 전에 동적으로 생성된 원격 큐에 계속 있을 수 있는 최대 메시지 수를 지정합니다.
enable-divert-bindings-
이 속성을
true로 설정하면 요청 발생 시 바인딩을 수신 대기할 수 있습니다. 주소 정책의 포함된 주소와 일치하는 주소가 있는 중단 바인딩이 있는 경우 변환 주소의 전달 주소와 일치하는 모든 큐 바인딩이 수요가 생성됩니다. 기본값은false입니다. max-hops- 페더레이션 중에 메시지가 만들 수 있는 최대 홉 수입니다. 특정 토폴로지에는 이 속성에 대한 특정 값이 필요합니다. 이러한 요구 사항에 대한 자세한 내용은 4.22.2절. “주소 페더레이션의 일반적인 토폴로지” 을 참조하십시오.
transformer-ref- 변환기 구성의 이름입니다. 페더레이션 메시지 전송 중에 메시지를 변환하려면 변환기 구성을 추가할 수 있습니다. Transformer 구성은 이 절차의 뒷부분에서 설명합니다.
<
;address-policy> 요소 내에 주소를 포함 및 제외할 address-matching 패턴을 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow include-
이 요소의
address-match속성 값은 주소 정책에 포함할 주소를 지정합니다. 정확한 주소를 지정할 수 있습니다(예:queue.bbc.new또는queue.usatoday). 또는 와일드카드 표현식을 사용하여 일치하는 주소 집합을 지정할 수 있습니다. 이전 예에서 주소 정책에는 문자열queue.news로 시작하는 모든 주소 이름도 포함됩니다. exclude-
이 요소의
address-match속성 값은 주소 정책에서 제외할 주소를 지정합니다. 정확한 주소 이름을 지정하거나 와일드카드 표현식을 사용하여 일치하는 주소 집합을 지정할 수 있습니다. 이전 예에서 address 정책은queue.news.sport문자열로 시작하는 모든 주소 이름을 제외합니다.
(선택 사항)
페더레이션요소에서 사용자 지정변환기구현을 참조하는 변환자 요소를 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow name-
변환기 구성의 이름입니다. 이 이름은 로컬 브로커에서 고유해야 합니다. 주소 정책의
transformer-ref속성 값으로 지정하는 이름입니다. class-nameorg.apache.activemq.artemis.core.server.transformer인터페이스를 구현하는 사용자 정의 클래스의 이름입니다.변환기의
transform()메서드는 메시지가 전송되기 전에 메시지와 함께 호출됩니다. 이렇게 하면 메시지 헤더 또는 본문이 페더레이션되기 전에 변환될 수 있습니다.속성- 특정 변환기 구성에 대해 키-값 쌍을 보유하는 데 사용됩니다.
페더레이션요소 내에서 하나 이상의업스트림요소를 추가합니다. 각업스트림요소는 원격 브로커에 대한 연결을 정의하고 해당 연결에 적용할 정책을 정의합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow static-connectors-
로컬 브로커의
broker.xml구성 파일의 다른 위치에서 정의된 커넥터 요소를 참조하는요소 목록이 포함되어 있습니다. 커넥터는 발신 연결에 사용할 전송(TCP, SSL, HTTP 등) 및 서버 연결 매개 변수(호스트, 포트 등)를 정의합니다. 이 절차의 다음 단계에서는connector-refstatic-connectors요소에서 참조되는 커넥터를 추가하는 방법을 보여줍니다. policy-ref- 업스트림 브로커에 적용되는 다운스트림 브로커에 구성된 주소 정책의 이름입니다.
업스트림요소에 대해 지정할 수 있는 추가 옵션은 다음과 같습니다.name-
업스트림 브로커 구성의 이름입니다. 이 예에서 이름은
eu-east-1및eu-west-1이라는 업스트림 브로커에 해당합니다. user-
업스트림 브로커에 대한 연결을 생성할 때 사용할 사용자 이름입니다. 지정하지 않으면
페더레이션요소의 구성에 지정된 공유 사용자 이름이 사용됩니다. 암호-
업스트림 브로커에 대한 연결을 생성할 때 사용할 암호입니다. 지정하지 않으면
페더레이션요소의 구성에 지정된 공유 암호가 사용됩니다. call-failover-timeout-
call-timeout과 유사하지만 페일오버 시도 중에 호출이 수행될 때 사용됩니다. 기본값은-1이며, 이는 시간 초과가 비활성화되어 있음을 의미합니다. call-timeout-
페더레이션 연결은 원격 브로커에서 차단 호출인 패킷을 전송할 때 응답을 대기하는 시간(밀리초)입니다. 이 시간이 지나면 연결이 예외를 발생시킵니다. 기본값은
30000입니다. check-period-
로컬 브로커가 원격 브로커에 전송하여 페더레이션 연결 상태를 확인하기 위해 연속 "유지 관리" 메시지 사이의 기간(밀리초)입니다. 페더레이션 연결이 정상이면 원격 브로커는 각 keep-alive 메시지에 응답합니다. 연결이 비정상적인 경우 다운스트림 브로커가 업스트림 브로커로부터 응답을 수신하지 못하면 회로 차단기 라는 메커니즘을 사용하여 페더레이션 소비자를 차단합니다. 자세한 내용은
circuit-breaker-timeout매개변수 설명을 참조하십시오.check-period매개변수의 기본값은30000입니다. circuit-breaker-timeout- 다운스트림과 업스트림 브로커 간의 단일 연결은 많은 페더레이션 대기열과 주소 소비자에 의해 공유될 수 있습니다. 브로커 간의 연결이 손실되면 페더레이션된 각 소비자가 동시에 다시 연결을 시도할 수 있습니다. 이를 방지하기 위해 회로 차단기 라는 메커니즘은 소비자를 차단합니다. 지정된 타임아웃 값이 경과하면 회로 차단기에서 연결을 다시 연결합니다. 성공하면 소비자가 차단 해제됩니다. 그렇지 않으면 회로 차단기가 다시 적용됩니다.
connection-ttl-
원격 브로커에서 메시지 수신을 중지하면 페더레이션 연결이 활성 상태로 유지됩니다. 기본값은
60000입니다. discovery-group-ref-
업스트림 브로커 연결에 대해 정적 커넥터를 정의하는 대신 이 요소를 사용하여
broker.xml구성 파일의 다른 위치에서 이미 구성된 검색 그룹을 지정할 수 있습니다. 특히 기존 검색 그룹을 이 요소의discovery-group-name속성 값으로 지정합니다. 검색 그룹에 대한 자세한 내용은 14.1.6절. “브로커 검색 방법” 을 참조하십시오. ha-
업스트림 브로커에 대한 연결에 high availability가 활성화되어 있는지 여부를 지정합니다. 이 매개변수의 값이
true로 설정된 경우 로컬 브로커는 업스트림 클러스터에서 사용 가능한 모든 브로커에 연결하고 라이브 업스트림 브로커가 종료되면 백업 브로커로 자동 실패할 수 있습니다. 기본값은false입니다. initial-connect-attempts-
다운스트림 브로커가 업스트림 브로커에 연결하기 위해 수행할 초기 시도 횟수입니다. 연결이 설정되지 않은 경우 업스트림 브로커는 영구적으로 오프라인으로 간주됩니다. 다운스트림 브로커는 더 이상 메시지를 업스트림 브로커로 라우팅하지 않습니다. 기본값은
-1이며 이는 제한이 없음을 의미합니다. max-retry-interval-
원격 브로커에 연결할 때 후속 재연결 시도 사이에 최대 시간(밀리초)입니다. 기본값은
2000입니다. reconnect-attempts-
연결이 실패하면 다운스트림 브로커가 업스트림 브로커에 다시 연결하는 횟수입니다. 연결을 다시 설정하지 않고 이 값에 도달하면 업스트림 브로커는 영구적으로 오프라인으로 간주됩니다. 다운스트림 브로커는 더 이상 메시지를 업스트림 브로커로 라우팅하지 않습니다. 기본값은
-1이며 이는 제한이 없음을 의미합니다. retry-interval-
원격 브로커 연결에 실패한 경우 후속 재연결 시도 사이에 마침표(밀리초)입니다. 기본값은
500입니다. retry-interval-multiplier-
retry-interval매개변수 값에 적용되는 요인을 곱합니다. 기본값은1입니다. share-connection-
동일한 브로커에 대해 다운스트림 및 업스트림 연결이 모두 구성된 경우 다운스트림 및 업스트림 구성 모두 이 매개변수 값을
true로 설정하는 한 동일한 연결이 공유됩니다. 기본값은false입니다.
로컬 브로커에서 원격 브로커에 커넥터를 추가합니다. 이러한 커넥터는 페더레이션 주소
구성의 정적연결 요소에서 참조됩니다. 예를 들면 다음과 같습니다.<connectors> <connector name="eu-west-1-connector">tcp://localhost:61616</connector> <connector name="eu-east-1-connector">tcp://localhost:61617</connector> </connectors>
<connectors> <connector name="eu-west-1-connector">tcp://localhost:61616</connector> <connector name="eu-east-1-connector">tcp://localhost:61617</connector> </connectors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.22.6. 다운스트림 주소 페더레이션 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제는 독립 실행형 브로커에 대한 다운스트림 주소 페더레이션을 구성하는 방법을 보여줍니다.
다운스트림 주소 페더레이션을 사용하면 하나 이상의 원격 브로커가 로컬 브로커에 다시 연결하는 데 사용하는 로컬 브로커에 구성을 추가할 수 있습니다. 이 접근 방식의 장점은 모든 페더레이션 구성을 단일 브로커에 유지할 수 있다는 점입니다. 예를 들어 hub-and-spoke 토폴로지에 유용한 접근 방식이 될 수 있습니다.
다운스트림 주소 페더레이션은 페더레이션 연결의 방향과 업스트림 주소 구성을 역전합니다. 따라서 구성에 원격 브로커를 추가하면 다운스트림 브로커로 간주됩니다. 다운스트림 브로커는 구성의 연결 정보를 사용하여 이제 업스트림으로 간주되는 로컬 브로커에 다시 연결합니다. 이 내용은 원격 브로커에 대한 구성을 추가할 때 이 예의 뒷부분에 설명되어 있습니다.
사전 요구 사항
- 업스트림 주소 페더레이션의 구성에 대해 잘 알고 있어야 합니다. 4.22.5절. “업스트림 주소 페더레이션 구성”을 참조하십시오.
- 다음 예제에서는 독립 실행형 브로커 간 주소 통합을 구성하는 방법을 보여줍니다. 그러나 브로커 클러스터에 대한 페더레이션을 구성하기 위한 요구 사항도 잘 알고 있어야 합니다. 자세한 내용은 4.22.4절. “브로커 클러스터의 페더레이션 구성”의 내용을 참조하십시오.
절차
-
로컬 브로커에서 <
broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
federation> 요소를 포함하는 <요소를 추가합니다. 예를 들면 다음과 같습니다.federations><federations> <federation name="eu-north-1" user="federation_username" password="32a10275cf4ab4e9"> </federation> </federations><federations> <federation name="eu-north-1" user="federation_username" password="32a10275cf4ab4e9"> </federation> </federations>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 주소 정책 구성을 추가합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 전송 전에 메시지를 변환하려면 변환기 구성을 추가합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 각 원격 브로커에 대해
downstream요소를 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 구성에 표시된 대로 원격 브로커는 이제 로컬 브로커의 다운스트림으로 간주됩니다. 다운스트림 브로커는 구성의 연결 정보를 사용하여 로컬(즉, 업스트림) 브로커에 다시 연결합니다.
로컬 브로커에서 로컬 및 원격 브로커가 사용하는 커넥터 및 어셉터를 추가하여 페더레이션 연결을 설정합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow connector name="netty-connector"- 로컬 브로커가 원격 브로커에 전송하는 커넥터 구성입니다. 원격 브로커는 이 구성을 사용하여 로컬 브로커에 다시 연결합니다.
connector name="eu-west-1-connector",connector name="eu-east-1-connector"- 원격 브로커에 대한 커넥터입니다. 로컬 브로커는 이러한 커넥터를 사용하여 원격 브로커에 연결하고 원격 브로커가 로컬 브로커에 다시 연결해야 하는 구성을 공유합니다.
acceptor name="netty-acceptor"- 로컬 브로커의 어셉터는 원격 브로커가 로컬 브로커에 다시 연결하는 데 사용하는 커넥터에 해당합니다.
4.22.7. 대기열 페더레이션 정보 링크 복사링크가 클립보드에 복사되었습니다!
대기열 페더레이션은 로컬 브로커에서 단일 대기열의 부하를 다른 원격 브로커 간에 균형을 유지하는 방법을 제공합니다.
부하 분산을 달성하기 위해 로컬 브로커는 로컬 소비자의 메시지 수요를 충족하기 위해 원격 대기열에서 메시지를 검색합니다. 예는 다음과 같습니다.
그림 4.5. 대칭 대기열 페더레이션
원격 대기열을 재구성할 필요는 없으며 동일한 브로커 또는 동일한 클러스터에 있을 필요가 없습니다. 원격 링크를 설정하는 데 필요한 모든 구성이 로컬 브로커에 있으며 페더레이션 대기열은 모두 로컬 브로커에 있습니다.
4.22.7.1. 대기열 페더레이션의 이점 링크 복사링크가 클립보드에 복사되었습니다!
아래에 설명된 내용은 대기열 페더레이션을 구성하기 위해 선택할 수 있는 몇 가지 이유입니다.
- 용량 증가
- 대기열 페더레이션은 많은 브로커에 걸쳐 분배되는 "과학적인" 대기열을 생성할 수 있습니다. 이 논리 분산 큐는 단일 브로커의 단일 대기열보다 용량이 훨씬 높습니다. 이 설정에서 가능한 한 많은 메시지가 원래 게시 된 브로커로부터 소비됩니다. 시스템은 부하 분산이 필요한 경우에만 페더레이션에서 메시지를 이동합니다.
- 다중 리전 설정 배포
다중 지역 설정에서는 한 리전 또는 지역에 메시지 생산자와 소비자가 있을 수 있습니다. 그러나 특정 지역의 생산자 및 소비자 연결을 로컬로 유지하는 것이 좋습니다. 이 경우 생산자와 소비자가 있는 각 지역에 브로커를 배포하고 대기열 페더레이션을 사용하여 지역 간에 WAN(Wide Area Network)을 통해 메시지를 이동할 수 있습니다. 예는 다음과 같습니다.
그림 4.6. 다중 지역 대기열 페더레이션
- 보안 엔터프라이즈 LAN과 DMZ 간의 통신
네트워킹 보안에서 DMZ(비밀도 영역 )는 엔터프라이즈의 외부 연결 서비스를 포함하며 일반적으로 인터넷과 같은 신뢰할 수 없는 네트워크에 공개하는 물리적 또는 논리적 서브네트워크입니다. 기업의 나머지 LAN(Local Area Network)은 방화벽 뒤에서 이 외부 네트워크와 격리되어 있습니다.
다수의 메시지 생산자가 DMZ에 있고 보안 엔터프라이즈 LAN의 여러 소비자에 있는 경우 생산자가 안전한 엔터프라이즈 LAN의 브로커에 연결하는 것이 적절하지 않을 수 있습니다. 이 경우 생산자가 메시지를 게시할 수 있는 브로커를 DMZ에 배포할 수 있습니다. 그런 다음 엔터프라이즈 LAN의 브로커는 DMZ의 브로커에 연결하고 페더레이션 대기열을 사용하여 DMZ의 브로커로부터 메시지를 수신할 수 있습니다.
4.22.8. 업스트림 대기열 페더레이션 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제는 독립 실행형 브로커에 대한 업스트림 대기열 페더레이션을 구성하는 방법을 보여줍니다. 이 예제에서는 로컬(즉, 다운스트림) 브로커에서 일부 원격(즉, 업스트림) 브로커로 페더레이션을 구성합니다.
사전 요구 사항
- 다음 예제에서는 독립 실행형 브로커 간 대기열 페더레이션을 구성하는 방법을 보여줍니다. 그러나 브로커 클러스터에 대한 페더레이션을 구성하기 위한 요구 사항도 잘 알고 있어야 합니다. 자세한 내용은 4.22.4절. “브로커 클러스터의 페더레이션 구성”의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 새 <
federations> 요소 내에서 <federation>요소를 추가합니다. 예를 들면 다음과 같습니다.<federations> <federation name="eu-north-1" user="federation_username" password="32a10275cf4ab4e9"> </federation> </federations>
<federations> <federation name="eu-north-1" user="federation_username" password="32a10275cf4ab4e9"> </federation> </federations>Copy to Clipboard Copied! Toggle word wrap Toggle overflow name- 페더레이션 구성의 이름입니다. 이 예에서 name은 다운스트림 브로커의 이름에 해당합니다.
user- 업스트림 브로커에 연결하기 위한 공유 사용자 이름입니다.
암호- 업스트림 브로커에 연결하기 위한 공유 암호입니다.
참고- 사용자 및 암호 인증 정보가 업스트림 브로커에 대해 다른 경우 구성에 추가할 때 해당 브로커의 인증 정보를 별도로 지정할 수 있습니다. 이 내용은 이 절차의 뒷부분에서 설명합니다.
페더레이션요소 내에 <queue-policy> 요소를추가합니다. <queue-policy> 요소의 속성 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow name- 대기열 정책의 이름입니다. 브로커에 구성된 모든 큐 정책에는 고유한 이름이 있어야 합니다.
include-federated이 속성의 값을
false로 설정하면 구성이 이미 손상된 소비자(즉, 페더레이션 큐의 소비자)를 다시 페더레이션하지 않습니다. 따라서 대칭 또는 클로즈 루프 토폴로지에서는 페더레이션되지 않은 소비자가 없으며 메시지가 시스템 전체에서 무한대로 순환되는 상황을 방지할 수 있습니다.closed-loop 토폴로지가 없는 경우 이 속성의 값을
true로 설정할 수 있습니다. 예를 들어BrokerA,BrokerB및BrokerC의 생산자와 BrokerC의 생산자와 함께 세 개의 브로커,BrokerA,BrokerC의 체인이 있다고 가정합니다. 이 경우BrokerB에서BrokerA에 소비자를 다시 주도록 합니다.priority-adjustment-
소비자가 큐에 연결하면 업스트림(즉 페더레이션된) 소비자가 생성될 때 우선순위가 사용됩니다. 페더레이션 소비자의 우선 순위는
priority-adjustment속성의 값으로 조정됩니다. 이 속성의 기본값은-1이며, 로드 밸런싱 중에 로컬 소비자가 페더레이션 소비자보다 우선 순위를 지정할 수 있습니다. 그러나 필요에 따라 우선순위 조정 값을 변경할 수 있습니다.
로컬 소비자에게 주어진 우선 순위에도 불구하고, 페더레이션 소비자는 너무 많은 메시지가 페더레이션 소비자로 이동하는 속도로 메시지를 소비하는 경우, 귀하는 연결된 소비자가 메시지를 소비하는 속도를 제한할 수 있습니다. 메시지 사용 속도를 제한하려면 페더레이션 소비자의 클라이언트 연결 URI에서 consumerMaxRate 흐름 제어 옵션을 구성합니다. 자세한 내용은 AMQ Core Protocol JMS Client 설명서의 흐름 제어 옵션을 참조하십시오.
transformer-ref변환기 구성의 이름입니다. 페더레이션 메시지 전송 중에 메시지를 변환하려면 변환기 구성을 추가할 수 있습니다. Transformer 구성은 이 절차의 뒷부분에서 설명합니다.
<
;queue-policy> 요소 내에 큐 정책에서 주소를 포함 및 제외하기 위해 address-matching 패턴을 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
include이 요소의
address-match속성 값은 큐 정책에 포함할 주소를 지정합니다. 정확한 주소를 지정할 수 있습니다(예:queue.bbc.new또는queue.usatoday). 또는 와일드카드 표현식을 사용하여 일치하는 주소 집합을 지정할 수 있습니다. 이전 예에서 큐 정책에는 문자열queue.news로 시작하는 모든 주소 이름도 포함됩니다.address-match속성과 함께queue-match속성을 사용하여 큐 정책의 해당 주소에 대한 특정 대기열을 포함할 수 있습니다.address-match속성과 마찬가지로 정확한 큐 이름을 지정하거나 와일드카드 표현식을 사용하여 대기열 세트를 지정할 수 있습니다. 앞의 예에서 숫자 기호(#) 와일드카드 문자는 각 주소 또는 주소 집합의 모든 대기열이 대기열 정책에 포함됨을 의미합니다.exclude이 요소의
address-match속성 값은 큐 정책에서 제외할 주소를 지정합니다. 정확한 주소를 지정하거나 와일드카드 표현식을 사용하여 일치하는 주소 집합을 지정할 수 있습니다. 이전 예에서 숫자 기호(#) 와일드카드 문자는 모든 주소의queue-match속성과 일치하는 모든 큐가 제외됨을 의미합니다. 이 경우 문자열.local로 끝나는 모든 큐는 제외됩니다. 이는 특정 대기열이 로컬 큐로 유지되고 페더레이션되지 않음을 나타냅니다.페더레이션요소 내에서 사용자 지정변환기구현을 참조하는 변환기 요소를 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
name-
변환기 구성의 이름입니다. 이 이름은 브로커에서 고유해야합니다. 이 이름을 주소 정책의
transformer-ref속성 값으로 지정합니다. class-nameorg.apache.activemq.artemis.core.server.transformer인터페이스를 구현하는 사용자 정의 클래스의 이름입니다.변환기의
transform()메서드는 메시지가 전송되기 전에 메시지와 함께 호출됩니다. 이렇게 하면 메시지 헤더 또는 본문이 페더레이션되기 전에 변환될 수 있습니다.속성특정 변환기 구성에 대해 키-값 쌍을 보유하는 데 사용됩니다.
페더레이션요소 내에서 하나 이상의업스트림요소를 추가합니다. 각업스트림요소는 업스트림 브로커 연결과 해당 연결에 적용할 정책을 정의합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow static-connectors-
로컬 브로커의
broker.xml구성 파일의 다른 위치에서 정의된 커넥터 요소를 참조하는요소 목록이 포함되어 있습니다. 커넥터는 발신 연결에 사용할 전송(TCP, SSL, HTTP 등) 및 서버 연결 매개 변수(호스트, 포트 등)를 정의합니다. 이 절차의 다음 단계에서는 페더레이션 큐 구성의connector-refstatic-connectors요소에서 참조하는 커넥터를 추가하는 방법을 보여줍니다. policy-ref- 업스트림 브로커에 적용되는 다운스트림 브로커에 구성된 대기열 정책의 이름입니다.
업스트림요소에 대해 지정할 수 있는 추가 옵션은 다음과 같습니다.
name-
업스트림 브로커 구성의 이름입니다. 이 예에서 이름은
eu-east-1및eu-west-1이라는 업스트림 브로커에 해당합니다. user-
업스트림 브로커에 대한 연결을 생성할 때 사용할 사용자 이름입니다. 지정하지 않으면
페더레이션요소의 구성에 지정된 공유 사용자 이름이 사용됩니다. 암호-
업스트림 브로커에 대한 연결을 생성할 때 사용할 암호입니다. 지정하지 않으면
페더레이션요소의 구성에 지정된 공유 암호가 사용됩니다. call-failover-timeout-
call-timeout과 유사하지만 페일오버 시도 중에 호출이 수행될 때 사용됩니다. 기본값은-1이며, 이는 시간 초과가 비활성화되어 있음을 의미합니다. call-timeout-
페더레이션 연결은 원격 브로커에서 차단 호출인 패킷을 전송할 때 응답을 대기하는 시간(밀리초)입니다. 이 시간이 지나면 연결이 예외를 발생시킵니다. 기본값은
30000입니다. check-period-
로컬 브로커가 원격 브로커에 전송하여 페더레이션 연결 상태를 확인하기 위해 연속 "유지 관리" 메시지 사이의 기간(밀리초)입니다. 페더레이션 연결이 정상이면 원격 브로커는 각 keep-alive 메시지에 응답합니다. 연결이 비정상적인 경우 다운스트림 브로커가 업스트림 브로커로부터 응답을 수신하지 못하면 회로 차단기 라는 메커니즘을 사용하여 페더레이션 소비자를 차단합니다. 자세한 내용은
circuit-breaker-timeout매개변수 설명을 참조하십시오.check-period매개변수의 기본값은30000입니다. circuit-breaker-timeout- 다운스트림과 업스트림 브로커 간의 단일 연결은 많은 페더레이션 대기열과 주소 소비자에 의해 공유될 수 있습니다. 브로커 간의 연결이 손실되면 페더레이션된 각 소비자가 동시에 다시 연결을 시도할 수 있습니다. 이를 방지하기 위해 회로 차단기 라는 메커니즘은 소비자를 차단합니다. 지정된 타임아웃 값이 경과하면 회로 차단기에서 연결을 다시 연결합니다. 성공하면 소비자가 차단 해제됩니다. 그렇지 않으면 회로 차단기가 다시 적용됩니다.
connection-ttl-
원격 브로커에서 메시지 수신을 중지하면 페더레이션 연결이 활성 상태로 유지됩니다. 기본값은
60000입니다. discovery-group-ref-
업스트림 브로커 연결에 대해 정적 커넥터를 정의하는 대신 이 요소를 사용하여
broker.xml구성 파일의 다른 위치에서 이미 구성된 검색 그룹을 지정할 수 있습니다. 특히 기존 검색 그룹을 이 요소의discovery-group-name속성 값으로 지정합니다. 검색 그룹에 대한 자세한 내용은 14.1.6절. “브로커 검색 방법” 을 참조하십시오. ha-
업스트림 브로커에 대한 연결에 high availability가 활성화되어 있는지 여부를 지정합니다. 이 매개변수의 값이
true로 설정된 경우 로컬 브로커는 업스트림 클러스터에서 사용 가능한 모든 브로커에 연결하고 라이브 업스트림 브로커가 종료되면 백업 브로커로 자동 실패할 수 있습니다. 기본값은false입니다. initial-connect-attempts-
다운스트림 브로커가 업스트림 브로커에 연결하기 위해 수행할 초기 시도 횟수입니다. 연결이 설정되지 않은 경우 업스트림 브로커는 영구적으로 오프라인으로 간주됩니다. 다운스트림 브로커는 더 이상 메시지를 업스트림 브로커로 라우팅하지 않습니다. 기본값은
-1이며 이는 제한이 없음을 의미합니다. max-retry-interval-
원격 브로커에 연결할 때 후속 재연결 시도 사이에 최대 시간(밀리초)입니다. 기본값은
2000입니다. reconnect-attempts-
연결이 실패하면 다운스트림 브로커가 업스트림 브로커에 다시 연결하는 횟수입니다. 연결을 다시 설정하지 않고 이 값에 도달하면 업스트림 브로커는 영구적으로 오프라인으로 간주됩니다. 다운스트림 브로커는 더 이상 메시지를 업스트림 브로커로 라우팅하지 않습니다. 기본값은
-1이며 이는 제한이 없음을 의미합니다. retry-interval-
원격 브로커 연결에 실패한 경우 후속 재연결 시도 사이에 마침표(밀리초)입니다. 기본값은
500입니다. retry-interval-multiplier-
retry-interval매개변수 값에 적용되는 요인을 곱합니다. 기본값은1입니다. share-connection동일한 브로커에 대해 다운스트림 및 업스트림 연결이 모두 구성된 경우 다운스트림 및 업스트림 구성 모두 이 매개변수 값을
true로 설정하는 한 동일한 연결이 공유됩니다. 기본값은false입니다.로컬 브로커에서 원격 브로커에 커넥터를 추가합니다. 이러한 커넥터는 페더레이션 주소
구성의 정적연결 요소에서 참조됩니다. 예를 들면 다음과 같습니다.<connectors> <connector name="eu-west-1-connector">tcp://localhost:61616</connector> <connector name="eu-east-1-connector">tcp://localhost:61617</connector> </connectors>
<connectors> <connector name="eu-west-1-connector">tcp://localhost:61616</connector> <connector name="eu-east-1-connector">tcp://localhost:61617</connector> </connectors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.22.9. 다운스트림 대기열 페더레이션 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 다운스트림 대기열 페더레이션을 구성하는 방법을 보여줍니다.
다운스트림 큐 페더레이션을 사용하면 하나 이상의 원격 브로커가 로컬 브로커에 다시 연결하는 데 사용하는 로컬 브로커에 구성을 추가할 수 있습니다. 이 접근 방식의 장점은 모든 페더레이션 구성을 단일 브로커에 유지할 수 있다는 점입니다. 예를 들어 hub-and-spoke 토폴로지에 유용한 접근 방식이 될 수 있습니다.
다운스트림 대기열 페더레이션은 페더레이션 연결의 방향과 업스트림 대기열 구성을 되돌립니다. 따라서 구성에 원격 브로커를 추가하면 다운스트림 브로커로 간주됩니다. 다운스트림 브로커는 구성의 연결 정보를 사용하여 이제 업스트림으로 간주되는 로컬 브로커에 다시 연결합니다. 이 내용은 원격 브로커에 대한 구성을 추가할 때 이 예의 뒷부분에 설명되어 있습니다.
사전 요구 사항
- 업스트림 대기열 페더레이션 구성에 대해 잘 알고 있어야 합니다. 4.22.8절. “업스트림 대기열 페더레이션 구성”을 참조하십시오.
- 다음 예제에서는 독립 실행형 브로커 간 대기열 페더레이션을 구성하는 방법을 보여줍니다. 그러나 브로커 클러스터에 대한 페더레이션을 구성하기 위한 요구 사항도 잘 알고 있어야 합니다. 자세한 내용은 4.22.4절. “브로커 클러스터의 페더레이션 구성”의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
federation> 요소를 포함하는 <요소를 추가합니다. 예를 들면 다음과 같습니다.federations><federations> <federation name="eu-north-1" user="federation_username" password="32a10275cf4ab4e9"> </federation> </federations>
<federations> <federation name="eu-north-1" user="federation_username" password="32a10275cf4ab4e9"> </federation> </federations>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 큐 정책 구성을 추가합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 전송 전에 메시지를 변환하려면 변환기 구성을 추가합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 각 원격 브로커에 대해
downstream요소를 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 구성에 표시된 대로 원격 브로커는 이제 로컬 브로커의 다운스트림으로 간주됩니다. 다운스트림 브로커는 구성의 연결 정보를 사용하여 로컬(즉, 업스트림) 브로커에 다시 연결합니다.
로컬 브로커에서 로컬 및 원격 브로커가 사용하는 커넥터 및 어셉터를 추가하여 페더레이션 연결을 설정합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow connector name="netty-connector"- 로컬 브로커가 원격 브로커에 전송하는 커넥터 구성입니다. 원격 브로커는 이 구성을 사용하여 로컬 브로커에 다시 연결합니다.
connector name="eu-west-1-connector",connector name="eu-east-1-connector"- 원격 브로커에 대한 커넥터입니다. 로컬 브로커는 이러한 커넥터를 사용하여 원격 브로커에 연결하고 원격 브로커가 로컬 브로커에 다시 연결해야 하는 구성을 공유합니다.
acceptor name="netty-acceptor"- 로컬 브로커의 어셉터는 원격 브로커가 로컬 브로커에 다시 연결하는 데 사용하는 커넥터에 해당합니다.
5장. 브로커 보안 링크 복사링크가 클립보드에 복사되었습니다!
5.1. 연결 보안 링크 복사링크가 클립보드에 복사되었습니다!
브로커가 메시징 클라이언트에 연결되거나 브로커가 다른 브로커에 연결되어 있으면 TLS(Transport Layer Security)를 사용하여 이러한 연결을 보호할 수 있습니다.
다음 두 가지 TLS 구성을 사용할 수 있습니다.
- 브로커만 인증서를 제공하는 단방향 TLS입니다. 가장 일반적인 구성입니다.
- 브로커와 클라이언트(또는 다른 브로커) 둘 다 인증서를 제공하는 양방향(또는 상호 상호) TLS입니다.
5.1.1. 단방향 TLS 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 단방향 TLS에 대해 지정된 어셉터를 구성하는 방법을 보여줍니다.
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 지정된 acceptor에
sslEnabled키를 추가하고 값을true로 설정합니다. 또한keyStorePath및keyStorePassword키를 추가합니다. 브로커 키 저장소에 해당하는 값을 설정합니다. 예를 들면 다음과 같습니다.<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=../etc/broker.keystore;keyStorePassword=1234!</acceptor>
<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=../etc/broker.keystore;keyStorePassword=1234!</acceptor>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.2. 양방향 TLS 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 양방향 TLS를 구성하는 방법을 보여줍니다.
사전 요구 사항
- 단방향 TLS에 대해 지정된 어셉터가 이미 구성되어 있어야 합니다. 자세한 내용은 5.1.1절. “단방향 TLS 구성”의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 이전에 단방향 TLS용으로 구성한 acceptor의 경우
needClientAuth키를 추가합니다. 값을true로 설정합니다. 예를 들면 다음과 같습니다.<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=../etc/broker.keystore;keyStorePassword=1234!;needClientAuth=true</acceptor>
<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=../etc/broker.keystore;keyStorePassword=1234!;needClientAuth=true</acceptor>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 단계의 구성은 클라이언트의 인증서가 신뢰할 수 있는 공급자가 서명했다고 가정합니다. 클라이언트의 인증서가 신뢰할 수 있는 공급자(예: 자체 서명)에서 서명 하지 않은 경우 브로커는 클라이언트의 인증서를 신뢰 저장소로 가져와야 합니다. 이 경우
trustStorePath및trustStorePassword키를 추가합니다. 브로커 신뢰 저장소에 해당하는 값을 설정합니다. 예를 들면 다음과 같습니다.<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=../etc/broker.keystore;keyStorePassword=1234!;needClientAuth=true;trustStorePath=../etc/client.truststore;trustStorePassword=5678!</acceptor>
<acceptor name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=../etc/broker.keystore;keyStorePassword=1234!;needClientAuth=true;trustStorePath=../etc/client.truststore;trustStorePassword=5678!</acceptor>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
AMQ Broker는 여러 프로토콜을 지원하며 각 프로토콜 및 플랫폼은 TLS 매개변수를 지정하는 다양한 방법이 있습니다. 그러나 Core Protocol( 브리지)를 사용하는 클라이언트의 경우 TLS 매개 변수는 브로커의 수락기와 유사하게 커넥터 URL에 구성됩니다.
자체 서명된 인증서가 Java 가상 머신(JVM) 신뢰 저장소에 신뢰할 수 있는 인증서로 표시되면 JVM은 인증서의 만료 날짜를 확인하지 않습니다. 프로덕션 환경에서는 인증 기관에서 서명한 인증서를 사용할 것을 권장합니다.
5.1.3. TLS 구성 옵션 링크 복사링크가 클립보드에 복사되었습니다!
다음 표는 사용 가능한 모든 TLS 구성 옵션을 보여줍니다.
| 옵션 | 참고 |
|---|---|
|
|
연결에 SSL이 활성화되어 있는지 여부를 지정합니다. TLS를 활성화하려면 |
|
| 어셉터에 사용되는 경우: 브로커 인증서를 보유한 브로커의 TLS 키 저장소에 대한 경로(자 자체 서명 또는 기관의 서명 여부)입니다.
커넥터에 사용되는 경우: 클라이언트 인증서를 보유한 클라이언트의 TLS 키 저장소에 대한 경로입니다. 이는 양방향 TLS를 사용하는 경우에만 커넥터와 관련이 있습니다. 브로커에서 이 값을 구성할 수 있지만 클라이언트가 다운로드하여 사용합니다. 클라이언트가 브로커에 설정된 것과 다른 경로를 사용해야 하는 경우 표준 |
|
| acceptor: 브로커의 키 저장소에 대한 암호입니다.
커넥터에 사용되는 경우: 클라이언트의 키 저장소에 대한 암호입니다. 이는 양방향 TLS를 사용하는 경우에만 커넥터와 관련이 있습니다. 브로커에서 이 값을 구성할 수 있지만 클라이언트가 다운로드하여 사용합니다. 클라이언트가 브로커에 설정된 암호와 다른 암호를 사용해야 하는 경우 표준 |
|
| 어셉터: 브로커가 신뢰하는 모든 클라이언트의 키를 보유한 브로커의 TLS 신뢰 저장소에 대한 경로. 이는 양방향 TLS를 사용하는 경우에만 어셉터와 관련이 있습니다.
커넥터에 사용되는 경우: 클라이언트가 신뢰하는 모든 브로커의 공개 키를 보유하는 클라이언트의 TLS 신뢰 저장소로 연결되는 경로입니다. 브로커에서 이 값을 구성할 수 있지만 클라이언트가 다운로드하여 사용합니다. 클라이언트가 서버에 설정된 것과 다른 경로를 사용해야 하는 경우 표준 |
|
| 어셉터에 사용되는 경우: 브로커의 신뢰 저장소에 대한 암호입니다. 이는 양방향 TLS를 사용하는 경우에만 어셉터와 관련이 있습니다.
커넥터에 사용되는 경우: 클라이언트의 신뢰 저장소에 대한 암호입니다. 브로커에서 이 값을 구성할 수 있지만 클라이언트가 다운로드하여 사용합니다. 클라이언트가 브로커에 설정된 암호와 다른 암호를 사용해야 하는 경우 표준 |
|
| 허용자 또는 커넥터 모두에 TLS 통신에 사용되는 쉼표로 구분된 암호화 제품군 목록입니다.
클라이언트 애플리케이션에서 지원하는 가장 안전한 암호화 제품군을 지정합니다. 브로커와 클라이언트에 공통되는 암호화 제품군의 쉼표로 구분된 목록을 지정하거나 암호화 모음을 지정하지 않는 경우 브로커와 클라이언트는 사용할 암호화 제품군을 서로 협상합니다. 지정할 암호화 모음을 모르는 경우 먼저 디버그 모드에서 실행 중인 클라이언트와 broker-client 연결을 설정하여 브로커와 클라이언트 모두에 공통된 암호화 제품군을 확인할 수 있습니다. 그런 다음 브로커에서
사용 가능한 암호화 제품군은 브로커 및 클라이언트에서 사용하는 TLS 프로토콜 버전에 따라 다릅니다. 브로커를 업그레이드한 후 기본 TLS 프로토콜 버전이 변경되면 브로커와 클라이언트가 공통 암호화 제품군을 사용할 수 있도록 이전 TLS 프로토콜 버전을 선택해야 할 수 있습니다. 자세한 내용은 |
|
| 어셉터 또는 커넥터에 사용하든 이는 TLS 통신에 사용되는 프로토콜의 쉼표로 구분된 목록입니다. TLS 프로토콜 버전을 지정하지 않으면 브로커는 JVM의 기본 버전을 사용합니다.
브로커가 JVM에 기본 TLS 프로토콜 버전을 사용하고 브로커를 업그레이드한 후 해당 버전이 변경되면 브로커 및 클라이언트에서 사용하는 TLS 프로토콜 버전이 호환되지 않을 수 있습니다. 이후 TLS 프로토콜 버전을 사용하는 것이 좋지만, |
|
|
이 속성은 수락자를 위한 것입니다. 클라이언트에게 양방향 TLS가 필요함을 알리는 메시지를 보냅니다. 유효한 값은 |
5.2. 클라이언트 인증 링크 복사링크가 클립보드에 복사되었습니다!
5.2.1. 클라이언트 인증 방법 링크 복사링크가 클립보드에 복사되었습니다!
브로커에서 클라이언트 인증을 구성하려면 다음 방법을 사용할 수 있습니다.
- 사용자 이름 및 암호 기반 인증
다음 옵션 중 하나를 사용하여 사용자 인증 정보를 직접 검증합니다.
- 브로커에 로컬로 저장된 속성 파일 집합에 대해 인증 정보를 확인합니다. 브로커에 대한 제한된 액세스 권한을 허용하고 로그인 모듈을 결합하여 더 복잡한 사용 사례를 지원하는 게스트 계정을 구성할 수도 있습니다.
- 중앙 X.500 디렉터리 서버에 저장된 사용자 데이터에 대해 클라이언트 자격 증명을 확인하도록 LDAP( Lightweight Directory Access Protocol ) 로그인 모듈을 구성합니다.
- 인증서 기반 인증
- 브로커와 클라이언트 모두 상호 인증을 위한 인증서를 제공하도록 양방향 전송 계층 보안 (TLS)을 구성합니다. 관리자는 승인된 클라이언트 사용자 및 역할을 정의하는 속성 파일도 구성해야 합니다. 이러한 속성 파일은 브로커에 저장됩니다.
- Kerberos 기반 인증
- SASL( Simple Authentication and Security Layer ) 프레임워크의 GSSAPI 메커니즘을 사용하여 클라이언트의 Kerberos 보안 자격 증명을 인증하도록 브로커를 구성합니다.
다음 섹션에서는 사용자 및 암호 기반 인증과 인증서 기반 인증을 모두 구성하는 방법을 설명합니다.
추가 리소스
LDAP 및 Kerberos에 대한 전체 인증 및 권한 부여 워크플로에 대한 자세한 내용은 다음을 참조하십시오.
5.2.2. 속성 파일을 기반으로 사용자 및 암호 인증 구성 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker는 주소를 기반으로 큐에 보안을 적용하기 위해 유연한 역할 기반 보안 모델을 지원합니다. 대기열은 일대일(점대점 메시징의 경우) 또는 다대일(게시-구독 메시지의 경우)을 처리하는 데 바인딩됩니다. 메시지가 주소로 전송되면 브로커는 해당 주소에 바인딩된 대기열 집합을 검색하고 메시지를 해당 큐 세트로 라우팅합니다.
기본 사용자 및 암호 인증이 필요한 경우 PropertiesLoginModule 을 사용하여 정의합니다. 이 로그인 모듈은 브로커에 로컬로 저장된 다음 구성 파일에 대해 사용자 인증 정보를 확인합니다.
artemis-users.properties- 사용자 및 해당 암호를 정의하는 데 사용
artemis-roles.properties- 역할을 정의하고 이러한 역할에 사용자를 할당하는 데 사용됩니다.
login.config- 사용자 및 암호 인증 및 게스트 액세스에 대해 로그인 모듈을 구성하는 데 사용됩니다.
artemis-users.properties 파일은 보안을 위해 해시된 암호를 포함할 수 있습니다.
다음 섹션에서는 구성 방법을 보여줍니다.
5.2.2.1. 기본 사용자 및 암호 인증 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 기본 사용자 및 암호 인증을 구성하는 방법을 보여줍니다.
절차
<
;broker_instance_dir> /etc/login.config구성 파일을 엽니다. 기본적으로 새로운 AMQ Broker 7.11 인스턴스의 이 파일에는 다음 행이 포함됩니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow activemq- 구성의 별칭입니다.
org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule- 구현 클래스입니다.
sufficientPropertiesLoginModule에 필요한 성공 수준을 지정하는 플래그입니다. 설정할 수 있는 값은 다음과 같습니다.-
필수: 성공하려면 로그인 모듈이 필요합니다. 인증은 성공 또는 실패와 관계없이 지정된 별칭에 구성된 로그인 모듈 목록을 계속 진행합니다. -
필수 사항: 성공하려면 로그인 모듈이 필요합니다. 실패는 즉시 제어를 애플리케이션으로 반환합니다. 인증은 지정된 별칭에 구성된 로그인 모듈 목록을 진행하지 않습니다. -
sufficient: 성공하려면 로그인 모듈이 필요하지 않습니다. 성공하면 제어가 애플리케이션으로 반환되고 인증이 계속 진행되지 않습니다. 실패하는 경우 인증 시도에서 지정된 별칭으로 구성된 로그인 모듈 목록을 진행합니다. -
선택 사항: 로그인 모듈이 성공하지 않아도 됩니다. 인증은 성공 또는 실패와 관계없이 지정된 별칭에 구성된 로그인 모듈 목록을 계속 종료합니다.
-
org.apache.activemq.jaas.properties.user- 로그인 모듈 구현에 대한 사용자 및 암호 집합을 정의하는 속성 파일을 지정합니다.
org.apache.activemq.jaas.properties.role- 로그인 모듈 구현에 대해 사용자를 정의된 역할에 매핑하는 속성 파일을 지정합니다.
-
<
;broker_instance_dir> /etc/artemis-users.properties구성 파일을 엽니다. 사용자를 추가하고 사용자에게 암호를 할당합니다. 예를 들면 다음과 같습니다.
user1=secret user2=access user3=myPassword
user1=secret user2=access user3=myPasswordCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
<
;broker_instance_dir> /etc/artemis-roles.properties구성 파일을 엽니다. 이전에
artemis-users.properties파일에 추가한 사용자에게 역할 이름을 할당합니다. 예를 들면 다음과 같습니다.admin=user1,user2 developer=user3
admin=user1,user2 developer=user3Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<
;broker_instance_dir> /etc/bootstrap.xml구성 파일을 엽니다. 필요한 경우 아래와 같이 보안 도메인 별칭(이 인스턴스에서 activemq)을 파일에 추가합니다.
<jaas-security domain="activemq"/>
<jaas-security domain="activemq"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.2.2. 게스트 액세스 구성 링크 복사링크가 클립보드에 복사되었습니다!
로그인 자격 증명이 없거나 인증 정보가 실패하는 사용자의 경우 게스트 계정을 사용하여 브로커에 대한 제한된 액세스 권한을 부여할 수 있습니다.
명령줄 스위치 --allow-anonymous (- require-login)를 사용하여 게스트 액세스가 활성화된 브로커 인스턴스를 생성할 수 있습니다.
다음 절차에서는 게스트 액세스를 구성하는 방법을 보여줍니다.
사전 요구 사항
- 이 절차에서는 기본 사용자 및 암호 인증이 이미 구성되어 있다고 가정합니다. 자세한 내용은 5.2.2.1절. “기본 사용자 및 암호 인증 구성” 에서 참조하십시오.
절차
-
이전에 기본 사용자 및 암호 인증을 위해 구성한 <
broker_instance_dir> /etc/login.config구성 파일을 엽니다. 이전에 추가한 속성 로그인 모듈 구성 후 게스트 로그인 모듈 구성을 추가합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow org.apache.activemq.artemis.spi.core.security.jaas.GuestLoginModule- 구현 클래스입니다.
org.apache.activemq.jaas.guest.user- 익명 사용자에게 할당된 사용자 이름입니다.
org.apache.activemq.jaas.guest.role- 익명 사용자에게 할당된 역할입니다.
위 구성에 따라 사용자가 자격 증명을 제공하는 경우 사용자 및 암호 인증 모듈이 활성화됩니다. 사용자가 인증 정보를 제공하지 않거나 제공된 인증 정보가 올바르지 않은 경우 게스트 인증이 활성화됩니다.
5.2.2.2.1. 게스트 액세스 예 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 인증 정보가 없는 사용자만 게스트로 로그인한 사용 사례에 대한 게스트 액세스 구성을 보여줍니다. 이 예에서는 로그인 모듈의 순서가 이전 구성 절차와 비교하여 반전되는 것을 관찰합니다. 또한 properties 로그인 모듈에 연결된 플래그는 필수 사항으로 변경됩니다.
앞의 구성에 따라 로그인 인증 정보가 제공되지 않으면 게스트 인증 모듈이 활성화됩니다.
이 사용 사례의 경우 게스트 로그인 모듈 구성에서 credentialsInvalidate 옵션을 true 로 설정해야 합니다.
인증 정보를 제공하는 경우 properties 로그인 모듈이 활성화됩니다. 자격 증명은 유효해야 합니다.
추가 리소스
-
JAAS( Java Authentication and Authorization Service )에 대한 자세한 내용은 Java 공급 업체의 설명서를 참조하십시오. 예를 들어
login.config구성에 대한 Oracle 튜토리얼은 Oracle Java 설명서에서 Login Configuration File 을 참조하십시오. - 클라이언트 인증 정보를 확인하도록 LDAP 로그인 모듈을 구성하는 방법을 알아보려면 5.4.1절. “클라이언트 인증을 위한 LDAP 구성” 를 참조하십시오.
- 구성 파일의 암호를 암호화하는 방법에 대한 자세한 내용은 5.9.2절. “구성 파일에서 암호 암호화” 을 참조하십시오.
5.2.3. 인증서 기반 인증 구성 링크 복사링크가 클립보드에 복사되었습니다!
JAAS( Java Authentication and Authorization Service ) 인증서 로그인 모듈은 TLS(Transport Layer Security)를 사용하는 클라이언트에 대한 인증 및 권한 부여를 처리합니다. 이 모듈에는 양방향 전송 계층 보안 (TLS)이 사용되고 클라이언트가 자체 인증서로 구성되어야 합니다. 인증은 CloudEvent 인증서 로그인 모듈에서 직접 아닌 TLS 핸드셰이크 중에 수행됩니다.
인증서 로그인 모듈의 역할은 다음과 같습니다.
- 허용 가능한 사용자 집합을 제한합니다. 관련 속성 파일에 명시적으로 나열된 사용자 Distinguished Names (DN)만 인증할 수 있습니다.
- 수신된 사용자 ID와 그룹 목록을 연결합니다. 이는 승인을 용이하게 합니다.
- 들어오는 클라이언트 인증서가 있어야 합니다(기본적으로 TLS 계층은 클라이언트 인증서의 존재를 선택 사항으로 처리하도록 구성됨).
인증서 로그인 모듈은 한 쌍의 플랫 텍스트 파일에 인증서 DN 컬렉션을 저장합니다. 파일은 사용자 이름 및 그룹 ID 목록을 각 DN과 연결합니다.
인증서 로그인 모듈은 org.apache.activemq.artemis.spi.core.security.jaas.knativeFileCertificateLoginModule 클래스에 의해 구현됩니다.
5.2.3.1. 인증서 기반 인증을 사용하도록 브로커 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 인증서 기반 인증을 사용하도록 브로커를 구성하는 방법을 보여줍니다.
사전 요구 사항
- 양방향 전송 계층 보안(TLS)을 사용하도록 브로커를 구성해야 합니다. 자세한 내용은 5.1.2절. “양방향 TLS 구성”의 내용을 참조하십시오.
절차
이전에 브로커 키 저장소로 가져온 사용자 인증서에서 Subject Distinguished Names (DN)를 가져옵니다.
키 저장소 파일에서 임시 파일로 인증서를 내보냅니다. 예를 들면 다음과 같습니다.
keytool -export -file <file_name> -alias broker-localhost -keystore broker.ks -storepass <password>
keytool -export -file <file_name> -alias broker-localhost -keystore broker.ks -storepass <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 내보낸 인증서의 내용을 출력합니다.
keytool -printcert -file <file_name>
keytool -printcert -file <file_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력은 아래 표시된 것과 유사합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Owner항목은 주체 DN입니다. 주체 DN을 입력하는 데 사용되는 형식은 플랫폼에 따라 다릅니다. 위의 문자열을 다음과 같이 나타낼 수도 있습니다.Owner: `CN=localhost,\ OU=broker,\ O=Unknown,\ L=Unknown,\ ST=Unknown,\ C=Unknown`
Owner: `CN=localhost,\ OU=broker,\ O=Unknown,\ L=Unknown,\ ST=Unknown,\ C=Unknown`Copy to Clipboard Copied! Toggle word wrap Toggle overflow
인증서 기반 인증을 구성합니다.
<
;broker_instance_dir> /etc/login.config구성 파일을 엽니다. 인증서 로그인 모듈을 추가하고 사용자 및 역할 속성 파일을 참조합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow org.apache.activemq.artemis.spi.core.security.jaas.TextFileCertificateLoginModule- 구현 클래스입니다.
org.apache.activemq.jaas.textfiledn.user- 로그인 모듈 구현에 대한 사용자 및 암호 집합을 정의하는 속성 파일을 지정합니다.
org.apache.activemq.jaas.textfiledn.role- 로그인 모듈 구현에 대해 사용자를 정의된 역할에 매핑하는 속성 파일을 지정합니다.
<
;broker_instance_dir> /etc/artemis-users.properties구성 파일을 엽니다. 사용자와 해당 DN은 이 파일에 정의되어 있습니다. 예를 들면 다음과 같습니다.system=CN=system,O=Progress,C=US user=CN=humble user,O=Progress,C=US guest=CN=anon,O=Progress,C=DE
system=CN=system,O=Progress,C=US user=CN=humble user,O=Progress,C=US guest=CN=anon,O=Progress,C=DECopy to Clipboard Copied! Toggle word wrap Toggle overflow 예를 들어, 이전 구성에 따라
system이라는 사용자가CN=system,O=Progress,C=USSubject DN에 매핑됩니다.<
;broker_instance_dir> /etc/artemis-roles.properties구성 파일을 엽니다. 사용 가능한 역할과 이러한 역할을 보유한 사용자는 이 파일에 정의됩니다. 예를 들면 다음과 같습니다.admins=system users=system,user guests=guest
admins=system users=system,user guests=guestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 앞의 구성에서
users역할의 경우 여러 사용자를 쉼표로 구분된 목록으로 나열합니다.다음과 같이
bootstrap.xml에서 보안 도메인 별칭(이 인스턴스의 activemq)을 참조해야 합니다.<jaas-security domain="activemq"/>
<jaas-security domain="activemq"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.3.2. AMQP 클라이언트에 대한 인증서 기반 인증 구성 링크 복사링크가 클립보드에 복사되었습니다!
브로커에 연결할 때 SASL( Simple Authentication and Security Layer ) EXTERNAL 메커니즘 구성 매개변수를 사용하여 인증서 기반 인증을 위해 AQMP 클라이언트를 구성합니다.
브로커는 모든 인증서를 인증하는 것과 동일한 방식으로 AMQP 클라이언트의 TLS( Transport Layer Security )/SSL(Secure Sockets Layer ) 인증서를 인증합니다.
- 브로커는 클라이언트의 TLS/SSL 인증서를 읽고 인증서 주체에서 ID를 가져옵니다.
- 인증서 주체는 인증서 로그인 모듈에 의해 브로커 ID에 매핑됩니다. 그런 다음 브로커는 역할에 따라 사용자에게 권한을 부여합니다.
다음 절차에서는 AMQP 클라이언트에 대한 인증서 기반 인증을 구성하는 방법을 보여줍니다. AMQP 클라이언트가 인증서 기반 인증을 사용할 수 있도록 하려면 클라이언트가 브로커에 연결하는 데 사용하는 URI에 구성 매개변수를 추가해야 합니다.
사전 요구 사항
다음을 구성해야 합니다.
- 양방향 TLS. 자세한 내용은 5.1.2절. “양방향 TLS 구성”의 내용을 참조하십시오.
- 인증 기반 인증을 사용하는 브로커입니다. 자세한 내용은 5.2.3.1절. “인증서 기반 인증을 사용하도록 브로커 구성”의 내용을 참조하십시오.
절차
편집할 URI가 포함된 리소스를 엽니다.
amqps://localhost:5500
amqps://localhost:5500Copy to Clipboard Copied! Toggle word wrap Toggle overflow 연결에 대해 TSL/SSL을 활성화하려면
sslEnabled=true매개변수를 추가합니다.amqps://localhost:5500?sslEnabled=true
amqps://localhost:5500?sslEnabled=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클라이언트 신뢰 저장소 및 키 저장소와 관련된 매개변수를 추가하여 TSL/SSL 인증서를 브로커와 교환할 수 있도록 합니다.
amqps://localhost:5500?sslEnabled=true&trustStorePath=<trust_store_path>&trustStorePassword=<trust_store_password>&keyStorePath=<key_store_path>&keyStorePassword=<key_store_password>
amqps://localhost:5500?sslEnabled=true&trustStorePath=<trust_store_path>&trustStorePassword=<trust_store_password>&keyStorePath=<key_store_path>&keyStorePassword=<key_store_password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow saslMechanisms=EXTERNAL매개 변수를 추가하여 TSL/SSL 인증서에 있는 ID를 사용하여 브로커가 클라이언트를 인증하도록 요청합니다.amqps://localhost:5500?sslEnabled=true&trustStorePath=<trust_store_path>&trustStorePassword=<trust_store_password>&keyStorePath=<key_store_path>&keyStorePassword=<key_store_password>&saslMechanisms=EXTERNAL
amqps://localhost:5500?sslEnabled=true&trustStorePath=<trust_store_path>&trustStorePassword=<trust_store_password>&keyStorePath=<key_store_path>&keyStorePassword=<key_store_password>&saslMechanisms=EXTERNALCopy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 리소스
- AMQ Broker의 인증서 기반 인증에 대한 자세한 내용은 5.2.3.1절. “인증서 기반 인증을 사용하도록 브로커 구성” 을 참조하십시오.
- AMQP 클라이언트 구성에 대한 자세한 내용은 Red Hat Customer Portal 에서 클라이언트와 관련된 제품 설명서를 참조하십시오.
5.3. 클라이언트 인증 링크 복사링크가 클립보드에 복사되었습니다!
5.3.1. 클라이언트 권한 부여 방법 링크 복사링크가 클립보드에 복사되었습니다!
주소 및 큐 생성 및 삭제, 메시지 전송 및 사용과 같은 브로커에서 작업을 수행하도록 클라이언트에 권한을 부여하려면 다음 방법을 사용할 수 있습니다.
- 사용자 및 역할 기반 권한
- 인증된 사용자 및 역할에 대한 브로커 보안 설정을 구성합니다.
- 클라이언트를 인증하도록 LDAP 설정
- 인증 및 권한 부여를 모두 처리하도록 LDAP( Lightweight Directory Access Protocol ) 로그인 모듈을 구성합니다. LDAP 로그인 모듈은 중앙 X.500 디렉터리 서버에 저장된 사용자 데이터에 대해 들어오는 자격 증명을 확인하고 사용자 역할을 기반으로 권한을 설정합니다.
- 클라이언트를 인증하도록 Kerberos 구성
-
Kerberos 인증 사용자를 AMQ Broker 역할에 매핑하는
PropertiesLoginModule또는LDAPLoginModule로그인 모듈에 인증 정보를 전달하도록 JVM( Java Authentication and Authorization Service )Krb5LoginModule로그인 모듈을 구성합니다.
5.3.2. 사용자 및 역할 기반 권한 부여 구성 링크 복사링크가 클립보드에 복사되었습니다!
5.3.2.1. 권한 설정 링크 복사링크가 클립보드에 복사되었습니다!
권한은 broker.xml 구성 파일의 < security-setting > 요소를 통해 해당 주소에 따라 큐에 대해 정의됩니다. 구성 파일의 < security- settings> 요소에서 여러 인스턴스를 < security-settings >에 정의할 수 있습니다. 정확한 주소 일치를 지정하거나 숫자 기호(#) 및 별표(*) 와일드카드 문자를 사용하여 와일드카드 일치 항목을 정의할 수 있습니다.
주소와 일치하는 대기열 집합에 다른 권한을 제공할 수 있습니다. 이러한 권한은 다음 표에 표시되어 있습니다.
| 사용자가…을 사용할 수 있도록 허용 | 이 매개변수를 사용합니다. |
|---|---|
| 주소 생성 |
|
| 주소 삭제 |
|
| 일치하는 주소 아래에 직렬화 대기열 생성 |
|
| 일치하는 주소 아래의 직렬화 대기열 삭제 |
|
| 일치하는 주소에 적용할 수 없는 큐 생성 |
|
| 일치하는 주소에서 정의할 수 없는 큐 삭제 |
|
| 일치하는 주소로 메시지 보내기 |
|
| 일치하는 주소에 바인딩된 큐의 메시지 사용 |
|
| 관리 주소로 관리 메시지를 보내 관리 작업 호출 |
|
| 일치하는 주소에 바인딩된 큐 검색 |
|
각 권한에 대해 권한이 부여된 역할 목록을 지정합니다. 지정된 사용자에게 역할이 있는 경우 해당 주소 집합에 대한 권한이 부여됩니다.
다음 섹션에는 권한에 대한 몇 가지 구성 예제가 표시되어 있습니다.
5.3.2.1.1. 단일 주소에 대한 메시지 프로덕션 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 단일 주소에 대한 메시지 프로덕션 권한을 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
security-요소를 추가합니다.settings> 요소에 단일 <security-setting>match키의 경우 주소를 지정합니다. 예를 들면 다음과 같습니다.<security-settings> <security-setting match="my.destination"> <permission type="send" roles="producer"/> </security-setting> </security-settings><security-settings> <security-setting match="my.destination"> <permission type="send" roles="producer"/> </security-setting> </security-settings>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 앞의 구성에 따라
생산자역할의 구성원은my.destination주소에 대한 권한을보냅니다.
5.3.2.1.2. 단일 주소에 대한 메시지 사용 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 단일 주소에 대한 메시지 소비 권한을 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
security-요소를 추가합니다.settings> 요소에 단일 <security-setting>match키의 경우 주소를 지정합니다. 예를 들면 다음과 같습니다.<security-settings> <security-setting match="my.destination"> <permission type="consume" roles="consumer"/> </security-setting> </security-settings><security-settings> <security-setting match="my.destination"> <permission type="consume" roles="consumer"/> </security-setting> </security-settings>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 앞의 구성에 따라
consumer역할의 멤버는 주소my.destination에 대한 사용 권한을 갖습니다.
5.3.2.1.3. 모든 주소에 대한 전체 액세스 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 모든 주소 및 관련 큐에 대한 전체 액세스를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
security-요소를 추가합니다.settings> 요소에 단일 <security-setting>일치키의 경우 모든 주소에 대한 액세스를 구성하려면 숫자 기호(#) 와일드카드 문자를 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 구성에 따라 모든 대기열에서 guest 역할의 멤버에게 모든 권한이 부여됩니다. 이는 익명 인증이 모든 사용자에게
게스트역할을 할당하도록 구성된 개발 시나리오에서 유용할 수 있습니다.
추가 리소스
- 복잡한 사용 사례 구성에 대한 자세한 내용은 5.3.2.1.4절. “다중 보안 설정 구성” 을 참조하십시오.
5.3.2.1.4. 다중 보안 설정 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제 절차에서는 일치하는 주소 집합에 대해 여러 보안 설정을 개별적으로 구성하는 방법을 보여줍니다. 이는 모든 주소에 대한 전체 액세스 권한을 부여하는 방법을 보여주는 이 섹션의 이전 예제와 대조됩니다.
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
security-요소를 추가합니다.settings> 요소에 단일 <security-setting>일치키의 경우 숫자 기호(#) 와일드카드 문자를 포함하여 일치하는 주소 집합에 설정을 적용합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow match=globalqueues.europe.#-
숫자 기호(
#) 와일드카드 문자는 브로커에 의해 "모든 단어 순서"로 해석됩니다. 마침표(..)로 구분됩니다. 이 예에서 보안 설정은 globalqueues.europe 문자열로 시작하는 모든 주소에 적용됩니다. permission type="createDurableQueue"-
관리자역할이 있는 사용자만 globalqueues.europe 문자열로 시작하는 주소에 바인딩된 내성 대기열을 생성하거나 삭제할 수 있습니다. permission type="createNonDurableQueue"-
admin,guest또는europe-users역할이 있는 모든 사용자는 globalqueues.europe 문자열로 시작하는 주소에 바인딩된 임시 대기열을 만들거나 삭제할 수 있습니다. permission type="send"-
역할
admin또는europe-users가 있는 모든 사용자는 globalqueues.europe 문자열로 시작하는 주소에 바인딩된 큐에 메시지를 보낼 수 있습니다. permission type="consume"-
역할
admin또는europe-users가 있는 모든 사용자는 globalqueues.europe 문자열로 시작하는 주소에 바인딩된 큐에서 메시지를 사용할 수 있습니다.
(선택 사항) 더 좁은 주소 집합에 다른 보안 설정을 적용하려면 <
security-setting> 요소를추가합니다.match키의 경우 더 구체적인 텍스트 문자열을 지정합니다. 예를 들면 다음과 같습니다.<security-setting match="globalqueues.europe.orders.#"> <permission type="send" roles="europe-users"/> <permission type="consume" roles="europe-users"/> </security-setting>
<security-setting match="globalqueues.europe.orders.#"> <permission type="send" roles="europe-users"/> <permission type="consume" roles="europe-users"/> </security-setting>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 두 번째
security-setting요소에서globalqueues.europe.orders.#일치는 첫 번째security-setting요소에 지정된글로벌 큐 큐.europe.#보다 더 구체적입니다.globalqueues.europe.orders.#와 일치하는 주소의 경우 권한createDurableQueue,deleteDurableQueue만들기NonDurableQueue,deleteNonDurableQueue는 파일의 첫 번째security-setting요소에서 상속 되지 않습니다. 예를 들어 주소globalqueues.europe.orders.plastics의 경우 존재하는 유일한 권한은 역할europe-users에 대해전송및소비됩니다.따라서 하나의 security-setting 블록에서 지정된 권한은 다른
security-setting블록에서 상속되지 않으므로 해당 권한을 지정하지 않고 보다 구체적인security-setting블록에서 권한을 효과적으로 거부할 수 있습니다.
5.3.2.1.5. 사용자로 큐 구성 링크 복사링크가 클립보드에 복사되었습니다!
큐가 자동으로 생성되면 연결된 클라이언트의 사용자 이름이 큐에 할당됩니다. 이 사용자 이름은 큐의 메타데이터로 포함됩니다. 이름은 CloudEvent 및 AMQ Broker 관리 콘솔에서 노출됩니다.
다음 절차에서는 브로커 구성에 수동으로 정의한 큐에 사용자 이름을 추가하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 지정된 큐의 경우
사용자키를 추가합니다. 값을 할당합니다. 예를 들면 다음과 같습니다.<address name="ExampleQueue"> <anycast> <queue name="ExampleQueue" user="admin"/> </anycast> </address><address name="ExampleQueue"> <anycast> <queue name="ExampleQueue" user="admin"/> </anycast> </address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 구성을 기반으로
admin사용자는 대기열예Queue에 할당됩니다.
- 큐에서 사용자를 구성해도 해당 큐의 보안 의미는 변경되지 않으며 해당 큐의 메타데이터에만 사용됩니다.
사용자 간 매핑과 보안 관리자 라는 구성 요소에서 처리하는 역할 간의 매핑입니다. 보안 관리자는 브로커에 저장된 속성 파일에서 사용자 자격 증명을 읽습니다. 기본적으로 AMQ Broker는
org.apache.activemq.artemis.spi.core.security.ActiveMQJAASSecurityManager보안 관리자를 사용합니다. 이 기본 보안 관리자는 10.0.0.1 및 Red Hat JBoss EAP(JBoss Enterprise Application Platform) 보안과의 통합을 제공합니다.사용자 정의 보안 관리자 사용 방법에 대한 자세한 내용은 5.6.2절. “사용자 정의 보안 관리자 지정” 을 참조하십시오.
5.3.2.2. 역할 기반 액세스 제어 구성 링크 복사링크가 클립보드에 복사되었습니다!
RBAC( 역할 기반 액세스 제어 )는 CloudEvents의 속성 및 메서드에 대한 액세스를 제한하는 데 사용됩니다. 관리자는 RBAC를 사용하면 역할에 따라 웹 콘솔, 관리 인터페이스, 코어 메시지 등과 같은 모든 사용자에게 올바른 수준의 액세스 권한을 부여할 수 있습니다.
5.3.2.2.1. 역할 기반 액세스 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제 절차에서는 역할을 특정 CloudEvents 및 해당 속성 및 메서드에 매핑하는 방법을 보여줍니다.
사전 요구 사항
- 먼저 사용자 및 역할을 정의해야 합니다. 자세한 내용은 5.2.2.1절. “기본 사용자 및 암호 인증 구성”의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/management.xml구성 파일을 엽니다. role-access요소를 검색하고 구성을 편집합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
이 경우 도메인 이름
org.apache.activemq.apache가 있는 모든 CloudEvent 속성에 일치가 적용됩니다. -
일치하는 10.0.0.1 속성에 대한
보기,업데이트또는amq역할에 대한 액세스는 역할을 추가하는list*,get*,is*,*액세스 메서드로 제어됩니다.method="*"(위드카드) 구문은 구성에 나열되지 않은 다른 모든 메서드를 지정하는 데 catch-all 방법으로 사용됩니다. 구성의 각 액세스 방법은 CloudEvent 메서드 호출로 변환됩니다. -
호출된 CloudEvent 메서드가 구성에 나열된 메서드와 일치합니다. 예를 들어
org.apache.activemq.artemis도메인을 사용하여listMessages라는 메서드를 호출하면 브로커는목록메서드의 구성에 정의된 역할에 대한 액세스를 다시 찾습니다. 전체 method name을 사용하여 액세스를 구성할 수도 있습니다. 예를 들면 다음과 같습니다.
<access method="listMessages" roles="view,update,amq"/>
<access method="listMessages" roles="view,update,amq"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
이 경우 도메인 이름
브로커를 시작하거나 다시 시작합니다.
-
Linux: <
;broker_instance_dir> /bin/artemis 실행 -
Windows에서 <
;broker_instance_dir> \bin\artemis-service.exe 시작
-
Linux: <
또한 CloudEvent 속성과 일치하는 키 특성을 추가하여 도메인 내에서 특정>-<s를 일치시킬 수도 있습니다.
5.3.2.2.2. 역할 기반 액세스 예 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 역할 기반 액세스 제어 적용의 다음 예를 보여줍니다.
다음 예제에서는 키 특성을 사용하여 지정된 도메인의 모든 큐에 역할을 매핑하는 방법을 보여줍니다.
다음 예제에서는 키 특성을 사용하여 이름이 지정된 큐에 역할을 매핑하는 방법을 보여줍니다. 이 예에서 이름이 지정된 큐는 예제Queue 입니다.
다음 예제에서는 이름에 지정된 접두사가 포함된 모든 큐에 역할을 매핑하는 방법을 보여줍니다. 이 예제에서는 별표(*) 와일드카드 연산자를 사용하여 접두사 예제로 시작하는 모든 대기열 이름을 일치시키는 데 사용됩니다.
동일한 특성 집합(예: 다른 대기열 세트)의 다양한 집합에 대해 역할을 다르게 매핑하려고 할 수 있습니다. 이 경우 구성 파일에 여러 일치 요소를 포함할 수 있습니다. 그러나 동일한 도메인에 일치하는 항목이 여러 개 있을 수 있습니다.
예를 들어 다음과 같이 구성된 두 개의 <match > 요소를 고려하십시오.
<match domain="org.apache.activemq.artemis" key="queue=example*">
<match domain="org.apache.activemq.artemis" key="queue=example*">
및
<match domain="org.apache.activemq.artemis" key="queue=example.sub*">
<match domain="org.apache.activemq.artemis" key="queue=example.sub*">
이 구성에 따라 org.apache.activemq.artemis 도메인의 example.sub.queue 라는 큐가 두 와일드카드 키 표현식과 일치합니다. 따라서 브로커는 우선 순위를 지정하여 큐에 매핑할 역할 집합, 첫 번째 일치 요소에 지정된 역할 집합 또는 두 번째 요소에 지정된 역할을 결정해야 합니다.
일치
동일한 도메인에 일치하는 항목이 여러 개 있는 경우 브로커는 역할을 매핑할 때 다음과 같은 우선 순위 지정 스키마를 사용합니다.
- 와일드카드 일치 항목보다 정확한 일치 우선 순위 지정
- 더 긴 와일드카드 일치는 더 짧은 와일드카드 일치에 우선 순위를 지정
이 예에서 긴 와일드카드 표현식이 example.sub.queue 의 큐 이름과 가장 근접하게 일치하므로 브로커는 두 번째 < match > 요소에 구성된 role-mapping을 적용합니다.
default-access 요소는 role-access 또는 허용 목록 구성을 사용하여 처리되지 않은 모든 메서드 호출에 대한 catch-all 요소입니다. default-access 및 role-access 요소는 일치하는 요소 의미 체계가 동일합니다.
5.3.2.2.3. 허용 목록 요소 구성 링크 복사링크가 클립보드에 복사되었습니다!
화이트리스트 는 사용자 인증이 필요하지 않은 사전 승인 도메인 또는 10.0.0.1s 집합입니다. 인증을 무시해야 하는 도메인 목록 또는 둘 다 목록을 제공할 수 있습니다. 예를 들어 허용 목록을 사용하여 AMQ Broker 관리 콘솔에서 실행하는 데 필요한 CloudEvents를 지정할 수 있습니다.
다음 예제 절차에서는 허용 목록 요소를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/management.xml구성 파일을 엽니다. 허용 목록요소를 검색하고 구성을 편집합니다.<whitelist> <entry domain="hawtio"/> </whitelist>
<whitelist> <entry domain="hawtio"/> </whitelist>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 예에서 도메인
hawtio가 있는 모든 10.0.0.1은 인증 없이 액세스가 허용됩니다. <entry domain="hawtio" key="type=*"/> 형식의 와일드카드 항목을 사용할 수도 있습니다.브로커를 시작하거나 다시 시작합니다.
-
Linux: <
;broker_instance_dir> /bin/artemis 실행 -
Windows에서 <
;broker_instance_dir> \bin\artemis-service.exe 시작
-
Linux: <
5.3.2.3. 리소스 제한 설정 링크 복사링크가 클립보드에 복사되었습니다!
경우에 따라 특정 사용자가 권한 부여 및 인증과 관련된 일반적인 보안 설정을 초과하여 수행할 수 있는 특정 제한을 설정하는 것이 유용합니다.
5.3.2.3.1. 연결 및 큐 제한 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제 절차에서는 사용자가 생성할 수 있는 연결 및 대기열 수를 제한하는 방법을 보여줍니다.
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. resource-limit-settings요소를 추가합니다.max-connections및max-queues의 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Max-connections-
일치하는 사용자가 브로커에서 생성할 수 있는 세션 수를 정의합니다. 기본값은
-1이며 이는 제한이 없음을 의미합니다. 세션 수를 제한하려면 AMQ Core Protocol JMS 클라이언트에서 브로커에 대한 각 연결이 두 개의 세션을 생성하는 경우를 고려하십시오. max-queues-
일치하는 사용자가 생성할 수 있는 대기열 수를 정의합니다. 기본값은
-1이며 이는 제한이 없음을 의미합니다.
브로커 구성의 address-setting 요소에서 지정할 수 있는 일치 문자열과 달리 resource-limit-settings 에서 지정하는 문자열은 와일드카드 구문을 사용할 수 없습니다. 대신 match 문자열은 리소스 제한 설정이 적용되는 특정 사용자를 정의합니다.
match
5.4. 인증 및 권한 부여에 LDAP 사용 링크 복사링크가 클립보드에 복사되었습니다!
LDAP 로그인 모듈은 중앙 X.500 디렉터리 서버에 저장된 사용자 데이터에 대해 들어오는 자격 증명을 확인하여 인증 및 권한 부여를 활성화합니다. 이는 org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule 에 의해 구현됩니다.
5.4.1. 클라이언트 인증을 위한 LDAP 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제 절차에서는 LDAP를 사용하여 클라이언트를 인증하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. security-settings요소 내에서security-setting요소를 추가하여 권한을 구성합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 구성은 모든 큐에 대한 특정 권한을
사용자역할의 멤버에게 할당합니다.-
<
broker_instance_dir>/etc/login.config파일을 엽니다. 사용 중인 디렉터리 서비스에 따라 LDAP 로그인 모듈을 구성합니다.
Microsoft Active Directory 디렉터리 서비스를 사용하는 경우 다음 예와 유사한 구성을 추가합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고Microsoft Active Directory를 사용하고 있고
connectionUsername의 속성에 대해 지정해야 하는 값에 공백(예:OU=System Accounts)을 포함하는 경우, 한 쌍의 따옴표("")로 값을 묶고 백슬래시(\)를 사용하여 쌍의 이중 인용을 이스케이프해야 합니다. 예를 들어connectionUsername="CN=Administrator,CN=Users,OU=\"System Accounts\",DC=example,DC=com"입니다.ApacheDS 디렉터리 서비스를 사용하는 경우 다음 예와 유사한 구성을 추가합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow debug-
디버깅을 끄십시오 (
true) off (false). 기본값은false입니다. initialContextFactory-
Must always be set to
com.sun.jndi.ldap.LdapCtxFactory connectionURL-
LDAP URL을 사용하는 디렉터리 서버의 위치, __<ldap://Host:Port>. 디렉터리 트리에 슬래시(
/)를 추가한 다음 디렉터리 트리에 특정 노드의 DN을 추가하여 선택적으로 이 URL의 자격을 부여할 수 있습니다. Apache DS의 기본 포트는 Microsoft AD의 경우10389이며 기본값은389입니다. connectionUsername-
디렉터리 서버에 대한 연결을 여는 사용자의 고유 이름(DN)입니다. 예:
uid=admin,ou=system. 일반적으로 디렉터리 서버는 연결을 열기 위해 클라이언트가 사용자 이름/암호 자격 증명을 제공해야 합니다. connectionPassword-
connectionUsername의 DN과 일치하는 암호입니다. 디렉터리 서버의 DIT( Directory Information Tree )에서 암호는 일반적으로 해당 디렉터리 항목에userPassword속성으로 저장됩니다. connectionProtocol- 모든 값은 지원되지만 효과적으로 사용되지 않습니다. 이 옵션은 기본값이 없기 때문에 명시적으로 설정해야 합니다.
connectionTimeout브로커가 디렉터리 서버에 연결하는 데 사용할 수 있는 최대 시간(밀리초)을 지정합니다. 브로커가 이 시간 내에 디렉터리 서버에 연결할 수 없는 경우 연결 시도를 중단합니다. 이 속성에 대해 0 이하의 값을 지정하면 기본 TCP 프로토콜의 시간 초과 값이 대신 사용됩니다. 값을 지정하지 않으면 브로커는 연결을 설정하기 위해 무기한 대기하거나 기본 네트워크 시간이 초과됩니다.
연결에 대한 연결 풀링이 요청되면 이 속성은 최대 풀 크기에 이미 도달하고 풀의 모든 연결이 사용 중인 경우 브로커가 연결을 대기하는 최대 시간을 지정합니다. 값을 0 이하로 지정하면 브로커가 연결을 사용할 수 있을 때까지 무기한 대기합니다. 그렇지 않으면 최대 대기 시간에 도달하면 브로커가 연결 시도를 중단합니다.
인증-
LDAP 서버에 바인딩할 때 사용되는 인증 방법을 지정합니다. 이 매개변수는
단순(사용자 이름 및 암호 필요) 또는없음(비명 액세스 허용)으로 설정할 수 있습니다. userBase-
사용자 항목을 검색하려면 DIT의 특정 하위 트리를 선택합니다. 하위 트리는 하위 트리의 기본 노드를 지정하는 DN에 의해 지정됩니다. 예를 들어 이 옵션을
로 설정하면 사용자 항목을 검색하면 ou=User,ou=ActiveMQ,ou=system 노드 아래에 있는 하위 트리로 제한됩니다.ou=User,ou=ActiveMQ,ou=system userSearchMatching-
userBase에서 선택한 하위 트리에 적용되는 LDAP 검색 필터를 지정합니다. 자세한 내용은 아래 5.4.1.1절. “일치하는 매개변수 검색” 섹션을 참조하십시오. userSearchSubtree-
userBase에 지정된 노드를 기준으로 사용자 항목에 대한 검색 깊이를 지정합니다. 이 옵션은 부울입니다.false값을 지정하면 검색이userBase노드의 하위 항목 중 하나(Javax.naming.directory.SearchControls.ONELEVEL_SCOPE에 매핑) 중 하나와 일치하려고 한다는 의미입니다.true값을 지정하면 검색이userBase노드의 하위 트리에 속하는 모든 항목을 찾습니다(Javax.naming.directory.SearchControls.SUBTREE_SCOPE). userRoleName- 사용자의 역할 이름 목록이 포함된 사용자 항목의 속성 이름입니다. 역할 이름은 브로커의 권한 부여 플러그인에서 그룹 이름으로 해석됩니다. 이 옵션을 생략하면 사용자 항목에서 역할 이름을 추출하지 않습니다.
readTimeout- 브로커가 디렉터리 서버에서 LDAP 요청으로 응답을 수신하기 위해 대기할 수 있는 최대 시간(밀리초)을 지정합니다. 브로커가 현재 디렉터리 서버에서 응답을 받지 못하면 브로커가 요청을 중단합니다. 값을 0 이하로 지정하거나 값을 지정하지 않으면 브로커는 디렉터리 서버에서 LDAP 요청으로의 응답을 무기한 대기합니다.
roleBase-
역할 데이터가 디렉터리 서버에 직접 저장되는 경우 역할 옵션(
roleBase,roleSearchMatching,roleSearchSubtree및roleName)의 조합으로userRoleName옵션을 지정하는 대안 (또는 그 외에)을 사용할 수 있습니다. 이 옵션은 역할/그룹 항목을 검색할 DIT의 특정 하위 트리를 선택합니다. 하위 트리는 하위 트리의 기본 노드를 지정하는 DN에 의해 지정됩니다. 예를 들어 이 옵션을로 설정하면 role/group 항목이 ou=Group,ou=ActiveMQ,ou=system 노드 아래에 있는 하위 트리로 제한됩니다.ou=Group,ou=ActiveMQ,ou=system roleName- role/group(예: C, O, OU 등)의 이름을 포함하는 역할 항목의 속성 유형입니다. 이 옵션을 생략하면 역할 검색 기능이 효과적으로 비활성화됩니다.
roleSearchMatching-
roleBase에서 선택한 하위 트리에 적용되는 LDAP 검색 필터를 지정합니다. 자세한 내용은 아래 5.4.1.1절. “일치하는 매개변수 검색” 섹션을 참조하십시오. roleSearchSubtreeroleBase에서 지정한 노드를 기준으로 역할 항목을 검색 깊이를 지정합니다.false(기본값)로 설정하면 검색이roleBase노드의 하위 항목 중 하나(Javax.naming.directory.SearchControls.ONELEVEL_SCOPE에 매핑) 중 하나와 일치하려고 합니다.true인 경우 roleBase 노드의 하위 트리에 속하는 모든 항목을 찾습니다(javax.naming.directory.SearchControls.SUBTREE_SCOPE).참고Apache DS는 DN 경로의
OID부분을 사용합니다. Microsoft Active Directory는CN부분을 사용합니다. 예를 들어 Apache DS에서는oid=ECDHE,dc=example,dc=com과 같은 DN 경로를 사용할 수 있지만 Microsoft Active Directory에서cn=ECDHE,dc=example,dc=com과 같은 DN 경로를 사용할 수 있습니다.
- 브로커를 시작하거나 다시 시작합니다(서비스 또는 프로세스).
5.4.1.1. 일치하는 매개변수 검색 링크 복사링크가 클립보드에 복사되었습니다!
userSearchMatchingLDAP 검색 작업에 전달하기 전에 이 구성 매개변수에 제공된 문자열 값에는
java.text.MessageFormat클래스에서 구현한 대로 문자열 대체가 적용됩니다.
즉, 특수 문자열
{0},은 들어오는 클라이언트 자격 증명에서 추출된 대로 사용자 이름으로 대체됩니다. 대체 후에는 문자열이 LDAP 검색 필터로 해석됩니다( syntax는 IETF 표준 RFC 2254에 의해 정의됨).
예를 들어 이 옵션이
(uid={0})로 설정되고 수신된 사용자 이름이jdoe인 경우 문자열 대체 후 검색 필터는(uid=jdoe)가 됩니다.
생성된 검색 필터가 사용자 base,
ou=User,ou=ActiveMQ,ou=system에서 선택한 하위 트리에 적용되는 경우uid=jdoe,ou=User,ou=ActiveMQ,ou=system와 일치합니다.
roleSearchMatching이는 두 개의 대체 문자열을 지원하는 경우를 제외하고
userSearchMatching옵션과 유사한 방식으로 작동합니다.
대체 문자열
{0}은 일치하는 사용자 항목의 전체 DN을 대체합니다(즉, 사용자 검색 결과). 예를 들어 사용자jdoe의 경우 대체 문자열은uid=jdoe,ou=User,ou=ActiveMQ,ou=system일 수 있습니다.
대체 문자열(
{1})은 수신된 사용자 이름을 대체합니다. 예를 들면jdoe입니다.
이 옵션이
(member=uid={1})로 설정되고 수신된 사용자 이름이jdoe인 경우 문자열 대체(ApacheDS 검색 필터 구문 가정) 이후 검색 필터는(member=uid=jdoe)가 됩니다.
결과 검색 필터가 역할 base,
ou=Group,ou=ActiveMQ,ou=system에서 선택한 하위 트리에 적용되는 경우uid=jdoe(구성멤버특성의 값이 DN임)와 같은멤버특성이 있는 모든 역할 항목과 일치합니다.
역할 검색에 기본값이 없으므로 이 옵션을 항상 설정해야 합니다. OpenLDAP를 사용하는 경우 검색 필터의 구문은
(member:=uid=jdoe)입니다.
추가 리소스
- 검색 필터 구문에 대한 간략한 소개는 Oracle JNDI 튜토리얼을 참조하십시오.
5.4.2. LDAP 권한 부여 구성 링크 복사링크가 클립보드에 복사되었습니다!
LegacyLDAPSecuritySettingPlugin 보안 설정 플러그인은 이전에 AMQ 6에서 LDAPAuthorizationMap 및 cachedLDAPAuthorizationMap 으로 이전에 처리한 보안 정보를 읽고 이 정보를 가능한 경우 AMQ 7 보안 설정으로 변환합니다.
AMQ 6 및 AMQ 7의 브로커에 대한 보안 구현이 정확히 일치하지 않습니다. 따라서 플러그인은 두 버전 간 일부 변환을 수행하여 거의 동등한 기능을 달성합니다.
다음 예제에서는 플러그인을 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. security-settings요소 내에서security-setting-plugin요소를 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow class-name-
구현은
org.apache.activemq.artemis.core.server.impl.LegacyLDAPSecuritySettingPlugin입니다. initialContextFactory-
LDAP에 연결하는 데 사용되는 초기 컨텍스트 팩토리입니다. 항상
com.sun.jndi.ldap.LdapCtxFactory(즉, 기본값)로 설정해야 합니다. connectionURL-
LDAP URL <ldap://Host:Port>을 사용하여 디렉터리 서버의 위치를 지정합니다. 디렉터리 트리에 특정 노드의 고유 이름(DN) 뒤에 슬래시(
/)를 추가하여 선택적으로 이 URL의 자격을 부여할 수 있습니다. 예:ldap://ldapserver:10389/ou=system. 기본값은ldap://localhost:1024입니다. connectionUsername-
디렉터리 서버에 대한 연결을 여는 사용자의 DN입니다. 예:
uid=admin,ou=system. 일반적으로 디렉터리 서버는 연결을 열기 위해 클라이언트가 사용자 이름/암호 자격 증명을 제공해야 합니다. connectionPassword-
connectionUsername의 DN과 일치하는 암호입니다. 디렉터리 서버의 DIT( Directory Information Tree )에서 암호는 일반적으로 해당 디렉터리 항목에userPassword속성으로 저장됩니다. connectionProtocol- 현재 사용되지 않습니다. 나중에 이 옵션을 사용하면 디렉터리 서버에 연결할 SSL(Secure Socket Layer)을 선택할 수 있습니다. 이 옵션은 기본값이 없기 때문에 명시적으로 설정해야 합니다.
인증LDAP 서버에 바인딩할 때 사용되는 인증 방법을 지정합니다. 이 매개변수의 유효한 값은
단순(사용자 이름 및 암호) 또는none(익명)입니다. 기본값은simple입니다.참고SASL(Simple Authentication and Security Layer) 인증은 지원되지 않습니다.
이전 구성 예에 표시되지 않는 다른 설정은 다음과 같습니다.
destinationBase-
자식이 모든 대상에 대한 권한을 제공하는 노드의 DN을 지정합니다. 이 경우 DN은 리터럴 값(즉, 속성 값에서 문자열 대체가 수행되지 않음)입니다. 예를 들어 이 속성의 일반적인 값은
ou=destinations,o=ActiveMQ,ou=system이며 기본값은ou=destinations,o=ActiveMQ,ou=system입니다. filter-
모든 종류의 대상에 대한 권한을 찾을 때 사용되는 LDAP 검색 필터를 지정합니다. 검색 필터는 큐 또는 주제 노드의 하위 또는 하위 항목 중 하나를 일치시킵니다. 기본값은
(cn=*)입니다. roleAttribute-
역할의 DN 값인
filter로 일치하는 노드의 속성을 지정합니다. 기본값은uniqueMember입니다. adminPermissionValue-
관리자권한과 일치하는 값을 지정합니다. 기본값은admin입니다. readPermissionValue-
읽기권한과 일치하는 값을 지정합니다. 기본값은read입니다. writePermissionValue-
쓰기권한과 일치하는 값을 지정합니다. 기본값은write입니다. enableListener-
LDAP 서버에서 자동으로 업데이트를 수신하고 브로커의 권한 부여 구성을 실시간으로 업데이트하는 리스너를 활성화할지 여부를 지정합니다. 기본값은
true입니다. mapAdminToManage레거시(즉, AMQ 6)
관리자권한을 AMQ 7관리권한에 매핑할지 여부를 지정합니다. 아래 표의 매핑 의미에 대한 세부 정보를 참조하십시오. 기본값은false입니다.LDAP에 정의된 대기열 또는 주제의 이름은 보안 설정의 "match" 역할을 하며, 권한 값은 AMQ 6 유형에서 AMQ 7 유형으로 매핑되며, 역할은 그대로 매핑됩니다. LDAP에 정의된 대기열 또는 주제 이름은 보안 설정에 대한 일치 항목으로 사용되므로 보안 설정이 JMS 대상에 예상대로 적용되지 않을 수 있습니다. AMQ 7은 필요에 따라 항상 "jms.queue" 또는 "jms.topic"로 JMS 대상 앞에 있기 때문입니다.
AMQ 6에는
읽기,쓰기및관리자의 세 가지 권한 유형이 있습니다. 이러한 권한 유형은 ActiveMQ 웹 사이트; 보안에 설명되어 있습니다.AMQ 7에는 다음과 같은 권한 유형이 있습니다.
-
createAddress -
deleteAddress -
createDurableQueue -
deleteDurableQueue -
createNonDurableQueue -
deleteNonDurableQueue -
send -
consume -
관리 찾아보기이 표는 보안 설정 플러그인에서 AMQ 6 권한 유형을 AMQ 7 권한 유형으로 매핑하는 방법을 보여줍니다.
Expand AMQ 6 권한 유형 AMQ 7 권한 유형 read
사용, 찾아보기
write
send
admin
createAddress, deleteAddress, createDurableQueue, deleteDurableQueue, createNonDurableQueue, deleteNonDurableQueue, manage (
mapAdminToManage가true로 설정된 경우)아래 설명과 같이 플러그인에서 동등성을 달성하기 위해 AMQ 6 및 AMQ 7 권한 유형 간에 일부 변환을 수행하는 몇 가지 사례가 있습니다.
-
AMQ 6에는 유사한 권한 유형이 없기 때문에 기본적으로 매핑에 AMQ 7
관리권한 유형이 포함되지 않습니다. 그러나mapAdminToManage가true로 설정된 경우 플러그인은 AMQ 6admin권한을 AMQ 7관리권한에 매핑합니다. -
AMQ 6의
admin권한 유형은 대상이 존재하지 않고 사용자가 메시지를 보내는 경우 브로커가 자동으로 대상을 생성하는지 여부를 결정합니다. AMQ 7을 사용하면 사용자가 대상에 메시지를 보낼 수 있는 권한이 있는 경우 자동으로 대상을 자동으로 생성할 수 있습니다. 따라서 플러그인은 레거시관리자권한을 위에 표시된 AMQ 7 권한에 매핑합니다.mapAdminToManage가true로 설정된 경우 플러그인은 AMQ 6admin권한을 AMQ 7관리권한에 매핑합니다.
-
AMQ 6에는 유사한 권한 유형이 없기 때문에 기본적으로 매핑에 AMQ 7
-
allowQueueAdminOnRead기존 읽기 권한을 createDurableQueue에 매핑할지 여부 및 deleteDurableQueue 권한을 생성하여 JMS 클라이언트가 관리자 권한 없이도 stage 및 non-durable Subscription을 생성할 수 있습니다. AMQ 6에서 이 작업이 허용됩니다. 기본값은 false입니다.
이 표는
allowQueueAdminOnRead가true인 경우 보안 설정 플러그인에서 AMQ 6 권한 유형을 AMQ 7 권한 유형에 매핑하는 방법을 보여줍니다.Expand AMQ 6 권한 유형 AMQ 7 권한 유형 read
consume, browse, createDurableQueue, createNonDurableQueue, deleteDurableQueue
write
send
admin
createAddress, deleteAddress, deleteNonDurableQueue, manage(
mapAdminToManage가true로 설정된 경우)
5.4.3. login.config 파일에서 암호 암호화 링크 복사링크가 클립보드에 복사되었습니다!
조직에서는 LDAP를 사용하여 데이터를 안전하게 저장하므로 login.config 파일에는 브로커가 조직의 LDAP 서버와 통신하는 데 필요한 구성이 포함될 수 있습니다. 이 설정 파일에는 일반적으로 LDAP 서버에 로그인할 수 있는 암호가 포함되어 있으므로 이 암호를 암호화해야 합니다.
사전 요구 사항
-
5.4.2절. “LDAP 권한 부여 구성” 에 설명된 대로
login.config파일을 수정하여 필요한 속성을 추가했는지 확인합니다.
절차
다음 절차에서는 < broker_instance_dir> /etc/login.config 파일에 있는 connectionPassword 매개 변수 값을 마스킹하는 방법을 보여줍니다.
명령 프롬프트에서
mask유틸리티를 사용하여 암호를 암호화합니다.<broker_instance_dir>/bin/artemis mask <password>
$ <broker_instance_dir>/bin/artemis mask <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow result: 3a34fd21b82bf2a822fa49a8d8fa115d
result: 3a34fd21b82bf2a822fa49a8d8fa115dCopy to Clipboard Copied! Toggle word wrap Toggle overflow <
broker_instance_dir>/etc/login.config파일을 엽니다.connectionPassword매개변수를 찾습니다.connectionPassword = <password>
connectionPassword = <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 일반 텍스트 암호를 암호화된 값으로 바꿉니다.
connectionPassword = 3a34fd21b82bf2a822fa49a8d8fa115d
connectionPassword = 3a34fd21b82bf2a822fa49a8d8fa115dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 암호화된 값을
"ENC()"식별자로 래핑합니다.connectionPassword = "ENC(3a34fd21b82bf2a822fa49a8d8fa115d)"
connectionPassword = "ENC(3a34fd21b82bf2a822fa49a8d8fa115d)"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
login.config 파일에 마스크된 암호가 포함되어 있습니다. 암호가 "ENC()" 식별자로 래핑되므로 AMQ Broker는 사용하기 전에 암호를 해독합니다.
추가 리소스
- AMQ Broker에 포함된 구성 파일에 대한 자세한 내용은 AMQ Broker 구성 파일 및 위치를 참조하십시오.
5.4.4. 외부 역할 매핑 링크 복사링크가 클립보드에 복사되었습니다!
LDAP와 같은 외부 인증 공급자의 역할을 브로커에서 내부적으로 사용하는 역할에 매핑할 수 있습니다.
외부 역할을 매핑하려면 broker.xml 구성 파일의 security-settings 요소에 role-mapping 항목을 생성합니다. 예를 들면 다음과 같습니다.
<security-settings>
...
<role-mapping from="cn=admins,ou=Group,ou=ActiveMQ,ou=system" to="my-admin-role"/>
<role-mapping from="cn=users,ou=Group,ou=ActiveMQ,ou=system" to="my-user-role"/>
</security-settings>
<security-settings>
...
<role-mapping from="cn=admins,ou=Group,ou=ActiveMQ,ou=system" to="my-admin-role"/>
<role-mapping from="cn=users,ou=Group,ou=ActiveMQ,ou=system" to="my-user-role"/>
</security-settings>
- 역할 매핑은 추가 기능입니다. 즉, 사용자는 원래 역할과 새로 할당된 역할을 유지합니다.
- 역할 매핑은 큐 액세스를 승인하는 역할에만 영향을 미치며 웹 콘솔 액세스를 활성화하는 방법은 제공하지 않습니다.
5.5. 인증 및 권한 부여에 Kerberos 사용 링크 복사링크가 클립보드에 복사되었습니다!
AMQP 프로토콜을 사용하여 메시지를 전송하고 수신할 때 클라이언트는 SASL( Simple Authentication and Security Layer ) 프레임워크에서 GSSAPI 메커니즘을 사용하여 AMQ Broker에서 인증하는 Kerberos 보안 자격 증명을 보낼 수 있습니다. Kerberos 자격 증명은 인증된 사용자를 LDAP 디렉터리 또는 텍스트 기반 속성 파일에 구성된 할당된 역할에 매핑하여 권한 부여에 사용할 수도 있습니다.
SASL을 TLS( Transport Layer Security )와 함께 사용하여 메시징 애플리케이션을 보호할 수 있습니다. SASL은 사용자 인증을 제공하며 TLS는 데이터 무결성을 제공합니다.
AMQ Broker가 Kerberos 자격 증명을 인증하고 인증하기 전에 Kerberos 인프라를 배포하고 구성해야 합니다. Kerberos 배포에 대한 자세한 내용은 운영 체제 설명서를 참조하십시오.
- RHEL 7의 경우 Kerberos 사용을 참조하십시오.
- Windows의 경우 Kerberos 인증 개요 를 참조하십시오.
- Oracle 또는 IBM JDK 사용자는 JCE(Java Cryptography Extension)를 설치해야 합니다. 자세한 내용은 Oracle 버전의 JCE 또는 IBM 버전의 JCE 설명서를 참조하십시오.
다음 절차에서는 인증 및 권한 부여를 위해 Kerberos를 구성하는 방법을 보여줍니다.
5.5.1. Kerberos를 사용하도록 네트워크 연결 구성 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker는 SASL( Simple Authentication and Security Layer ) 프레임워크의 GSSAPI 메커니즘을 사용하여 Kerberos 보안 자격 증명과 통합됩니다. AMQ Broker에서 Kerberos를 사용하려면 각 수락자가 GSSAPI 메커니즘을 사용하도록 Kerberos 자격 증명을 사용하는 클라이언트를 인증하거나 승인해야 합니다.
다음 절차에서는 Kerberos를 사용하도록 수락자를 구성하는 방법을 설명합니다.
사전 요구 사항
- AMQ Broker가 Kerberos 자격 증명을 인증하고 인증하기 전에 Kerberos 인프라를 배포하고 구성해야 합니다.
절차
브로커를 중지합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis stop
<broker_instance_dir>/bin/artemis stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe stop
<broker_instance_dir>\bin\artemis-service.exe stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 이름-값 쌍
saslMechanisms=GSSAPI를수락자URL의 쿼리 문자열에 추가합니다.<acceptor name="amqp"> tcp://0.0.0.0:5672?protocols=AMQP;saslMechanisms=GSSAPI </acceptor>
<acceptor name="amqp"> tcp://0.0.0.0:5672?protocols=AMQP;saslMechanisms=GSSAPI </acceptor>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 앞의 구성은 Kerberos 자격 증명을 인증할 때 수락자가 GSSAPI 메커니즘을 사용한다는 것을 의미합니다.
(선택 사항)
PLAIN및ANONYMOUSSASL 메커니즘도 지원됩니다. 여러 메커니즘을 지정하려면 쉼표로 구분된 목록을 사용합니다. 예를 들면 다음과 같습니다.<acceptor name="amqp"> tcp://0.0.0.0:5672?protocols=AMQP;saslMechanisms=GSSAPI,PLAIN </acceptor>
<acceptor name="amqp"> tcp://0.0.0.0:5672?protocols=AMQP;saslMechanisms=GSSAPI,PLAIN </acceptor>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 결과는
GSSAPI및PLAINSASL 메커니즘을 모두 사용하는 어셉터입니다.브로커를 시작합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis run
<broker_instance_dir>/bin/artemis runCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe start
<broker_instance_dir>\bin\artemis-service.exe startCopy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 리소스
- 수락자에 대한 자세한 내용은 2.1절. “수락자 정보” 을 참조하십시오.
5.5.2. Kerberos 자격 증명을 사용하여 클라이언트 인증 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker는 SASL( Simple Authentication and Security Layer ) 프레임워크의 GSSAPI 메커니즘을 사용하는 AMQP 연결의 Kerberos 인증을 지원합니다.
브로커는 JAAS( Java Authentication and Authorization Service )를 사용하여 Kerberos 어셉터 자격 증명을 취득합니다. Java 설치에 포함된 library는 Kerberos 자격 증명을 인증하는 로그인 모듈인 Krb5LoginModule 과 함께 패키지됩니다. Krb5LoginModule 에 대한 자세한 내용은 Java 벤더의 설명서를 참조하십시오. 예를 들어 Oracle에서는 Java 8 설명서 의 일부로 Krb5LoginModule 로그인 모듈에 대한 정보를 제공합니다.
사전 요구 사항
- Kerberos 보안 자격 증명을 사용하여 AMQP 연결을 인증하려면 먼저 수락자의 GSSAPI 메커니즘을 활성화해야 합니다. 자세한 내용은 5.5.1절. “Kerberos를 사용하도록 네트워크 연결 구성”의 내용을 참조하십시오.
절차
브로커를 중지합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis stop
<broker_instance_dir>/bin/artemis stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe stop
<broker_instance_dir>\bin\artemis-service.exe stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
<
;broker_instance_dir> /etc/login.config구성 파일을 엽니다. amqp-sasl-gssapi라는 구성 범위를 추가합니다. 다음 예제는 Oracle 및 OpenJDK 버전의 JDK에 있는Krb5LoginModule의 구성을 보여줍니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow amqp-sasl-gssapi-
기본적으로 브로커의 GSSAPI 메커니즘 구현은
amqp-sasl-gssapi라는 CloudEvent 구성 범위를 사용하여 Kerberos acceptor 자격 증명을 가져옵니다. Krb5LoginModule-
이
Krb5LoginModule버전은 Oracle 및 OpenJDK 버전의 JDK에서 제공합니다. Java 공급 업체의 설명서를 참조하여Krb5LoginModule의 정규화된 클래스 이름과 사용 가능한 옵션을 확인합니다. useKeyTab-
Krb5LoginModule은 보안 주체를 인증할 때 Kerberos 키 탭을 사용하도록 구성됩니다. 키탭은 Kerberos 환경에서 툴링을 사용하여 생성됩니다. Kerberos 키 탭 생성에 대한 자세한 내용은 공급 업체의 설명서를 참조하십시오. principal-
주체가
amqp/my_broker_host@example.com로 설정됩니다. 이 값은 Kerberos 환경에서 생성된 서비스 주체에 일치해야 합니다. 서비스 주체 생성에 대한 자세한 내용은 공급 업체의 설명서를 참조하십시오.
브로커를 시작합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis run
<broker_instance_dir>/bin/artemis runCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe start
<broker_instance_dir>\bin\artemis-service.exe startCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5.2.1. 대체 구성 범위 사용 링크 복사링크가 클립보드에 복사되었습니다!
AMQP 수용자의 URL에 saslLoginConfigScope 매개변수를 추가하여 대체 구성 범위를 지정할 수 있습니다. 다음 구성 예제에서 saslLoginConfigScope 매개 변수에 alternative-sasl-gssapi 값이 제공됩니다. 결과는 < broker_instance_dir> /etc/login.config 구성 파일에 선언된 alternative-sasl-gssapi 라는 대체 범위를 사용하는 어셉터입니다.
<acceptor name="amqp"> tcp://0.0.0.0:5672?protocols=AMQP;saslMechanisms=GSSAPI,PLAIN;saslLoginConfigScope=alternative-sasl-gssapi` </acceptor>
<acceptor name="amqp">
tcp://0.0.0.0:5672?protocols=AMQP;saslMechanisms=GSSAPI,PLAIN;saslLoginConfigScope=alternative-sasl-gssapi`
</acceptor>
5.5.3. Kerberos 자격 증명을 사용하여 클라이언트 인증 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에는 역할을 매핑할 때 다른 보안 모듈에서 사용할 수 있도록 CloudEvent Krb5LoginModule 로그인 모듈 구현이 포함되어 있습니다. 이 모듈에서는 Subject의 보안 주체에 AMQ Broker UserPrincipal로 Kerberos 인증 Peer Principal을 추가합니다. 그런 다음 Kerberos 인증 Peer Principal을 AMQ Broker 역할에 매핑하는 PropertiesLoginModule 또는 LDAPLoginModule 모듈에 인증 정보를 전달할 수 있습니다.
Kerberos Peer Principal은 역할 멤버로서만 브로커 사용자로 존재하지 않습니다.
사전 요구 사항
- Kerberos 보안 자격 증명을 사용하여 AMQP 연결에 권한을 부여하려면 먼저 수락자의 GSSAPI 메커니즘을 활성화해야 합니다.
절차
브로커를 중지합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis stop
<broker_instance_dir>/bin/artemis stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe stop
<broker_instance_dir>\bin\artemis-service.exe stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
<
;broker_instance_dir> /etc/login.config구성 파일을 엽니다. AMQ Broker
Krb5LoginModule및LDAPLoginModule에 대한 구성을 추가합니다. LDAP 공급자의 문서를 참조하여 구성 옵션을 확인합니다.구성 예는 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이전 예에 표시된
Krb5LoginModule버전은 AMQ Broker와 함께 배포되고 Kerberos ID를 역할 매핑을 위해 다른 AMQ 모듈에서 사용할 수 있는 브로커 ID로 변환합니다.브로커를 시작합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis run
<broker_instance_dir>/bin/artemis runCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe start
<broker_instance_dir>\bin\artemis-service.exe startCopy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 리소스
- AMQ Broker에서 GSSAPI 메커니즘 활성화에 대한 자세한 내용은 5.5.1절. “Kerberos를 사용하도록 네트워크 연결 구성” 을 참조하십시오.
-
PropertiesLoginModule에 대한 자세한 내용은 5.2.2.1절. “기본 사용자 및 암호 인증 구성” 을 참조하십시오. -
LDAPLoginModule에 대한 자세한 내용은 5.4.1절. “클라이언트 인증을 위한 LDAP 구성” 을 참조하십시오.
5.6. 보안 관리자 지정 링크 복사링크가 클립보드에 복사되었습니다!
브로커는 보안 관리자 라는 구성 요소를 사용하여 인증 및 권한 부여를 처리합니다.
AMQ Broker에는 다음 두 가지 보안 관리자가 포함됩니다.
-
ActiveMQJAASSecurityManager보안 관리자. 이 보안 관리자는 10.0.0.1 및 Red Hat JBoss EAP(JBoss Enterprise Application Platform) 보안과의 통합을 제공합니다. AMQ Broker에서 사용하는 기본 보안 관리자입니다. -
ActiveMQBasicSecurityManager보안 관리자. 이 기본 보안 관리자는 CloudEvent를 지원하지 않습니다. 대신 사용자 이름 및 암호 자격 증명을 통해 인증 및 권한 부여를 지원합니다. 이 보안 관리자는 관리 API를 사용하여 사용자 추가, 제거 및 업데이트를 지원합니다. 모든 사용자 및 역할 데이터는 브로커 바인딩 저널에 저장됩니다. 즉, 라이브 브로커에 대한 변경 사항도 백업 브로커에서 사용할 수 있습니다.
포함된 보안 관리자 대신 시스템 관리자가 브로커 보안 구현을 보다 잘 제어해야 할 수 있습니다. 이 경우 브로커 구성에 사용자 정의 보안 관리자를 지정 할 수도 있습니다. 사용자 지정 보안 관리자는 org.apache.activemq.artemis.spi.core.security.ActiveMQSecurityManager5 인터페이스를 구현하는 사용자 정의 클래스입니다.
다음 하위 섹션의 예제에서는 사용할 브로커를 구성하는 방법을 보여줍니다.
- 기본 보안 관리자 대신 기본 보안 관리자
- 사용자 정의 보안 관리자
5.6.1. 기본 보안 관리자 사용 링크 복사링크가 클립보드에 복사되었습니다!
기본 ActiveMQJAASSecurityManager 보안 관리자 외에도 AMQ Broker에는 ActiveMQBasicSecurityManager 보안 관리자도 포함되어 있습니다.
기본 보안 관리자를 사용하면 모든 사용자 및 역할 데이터가 바인딩 저널(또는 JDBC 지속성을 사용하는 경우 바인딩 테이블 )에 저장됩니다. 따라서 실시간 백업 브로커 그룹을 구성한 경우 라이브 브로커에서 생성하는 모든 사용자 관리는 장애 조치 시 백업 브로커에 자동으로 반영됩니다. 따라서 이 동작을 수행하는 대체 방법인 LDAP 서버를 별도로 관리할 필요가 없습니다.
기본 보안 관리자를 구성하고 사용하기 전에 다음 사항에 유의하십시오.
- 기본 보안 관리자는 기본 security manager와 같이 연결할 수 없습니다.
- 기본 보안 관리자는 CloudEvent를 지원하지 않습니다. 대신 사용자 이름 및 암호 자격 증명을 통해 인증 및 권한 부여만 지원합니다.
-
AMQ 관리 콘솔에는 CloudEvent가 필요합니다. 따라서 기본 보안 관리자를 사용하고 콘솔을 사용하려면 사용자 및 암호 인증에 대해
login.config구성 파일도 구성해야 합니다. 사용자 및 암호 인증 구성에 대한 자세한 내용은 5.2.2.1절. “기본 사용자 및 암호 인증 구성” 을 참조하십시오. - AMQ Broker에서는 브로커 관리 API에서 사용자 관리를 제공합니다. 이 관리에는 사용자와 역할을 추가, 나열, 업데이트, 제거하는 기능이 포함됩니다. CloudEvent, 관리 메시지, HTTP( Jolokia 또는 AMQ Management Console 사용) 및 AMQ Broker 명령줄 인터페이스를 사용하여 이러한 기능을 수행할 수 있습니다. 브로커가 이 데이터를 직접 저장하므로 사용자를 관리하려면 브로커가 실행 중이어야 합니다. 바인딩 데이터를 수동으로 수정할 수 없습니다.
- HTTP를 통한 모든 관리 액세스(예: Jolokia 또는 AMQ Management Console 사용)는 콘솔ECDHE 로그인 모듈에서 처리합니다. JConsole 또는 기타 원격 10.0.0.1 도구를 통한 액세스는 기본 보안 관리자에서 처리합니다. 관리 메시지는 기본 보안 관리자가 처리합니다.
5.6.1.1. 기본 보안 관리자 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 기본 보안 관리자를 사용하도록 브로커를 구성하는 방법을 설명합니다.
절차
-
<
;broker-instance-dir> /etc/boostrap.xml구성 파일을 엽니다. security-manager요소에서class-name속성에 대해 전체ActiveMQBasicSecurityManager클래스 이름을 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자 및 역할 데이터가 있는 바인딩 데이터를 수동으로 수정할 수 없으며 브로커를 사용자 관리를 위해 실행해야 하므로 처음 부팅할 때 브로커를 보호하는 것이 좋습니다. 이를 위해 인증 정보를 사용하여 다른 사용자를 추가할 수 있는 부트스트랩 사용자를 정의합니다.
security-manager요소에서bootstrapUser,bootstrapPassword,bootstrapRole속성을 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow bootstrapUser- 부트스트랩 사용자의 이름입니다.
bootstrapPassword- boostrap 사용자의 Passsword입니다. 암호화된 암호를 지정할 수도 있습니다.
bootstrapRoleboostrap 사용자의 역할.
참고구성에서 부트스트랩 사용자에 대한 이전 속성을 정의하면 브로커가 실행되는 동안 수행한 변경 사항에 관계없이 해당 인증 정보가 브로커를 시작할 때마다 설정됩니다.
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. broker.xml구성 파일에서activemq.management#주소에 대해 기본적으로 정의된address-setting요소를 찾습니다. 이러한 기본 주소 설정은 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 절차의 앞부분에서 지정한 부트스트랩 역할 이름에 대해
activemq.management#주소의 주소 설정 내에서 다음과 같은 필요한 권한을 추가합니다.-
createNonDurableQueue -
createAddress -
consume -
관리 -
send
예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
추가 리소스
-
ActiveMQBasicSecurityManager클래스에 대한 자세한 내용은 ActiveMQ Artemis Core API 설명서의 Class ActiveMQBasicSecurityManager 를 참조하십시오. - 구성 파일에서 암호를 암호화하는 방법은 5.9절. “구성 파일에서 암호 암호화” 을 참조하십시오.
5.6.2. 사용자 정의 보안 관리자 지정 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 브로커 구성에서 사용자 정의 보안 관리자를 지정하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/boostrap.xml구성 파일을 엽니다. security-manager요소에서class-name속성의 경우org.apache.activemq.artemis.spi.core.security.ActiveMQSecurityManager5인터페이스의 사용자 정의 구현인 클래스를 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 리소스
-
ActiveMQSecurityManager5인터페이스에 대한 자세한 내용은 ActiveMQ Artemis Core API 설명서의 Interface ActiveMQSecurityManager5 를 참조하십시오.
5.6.3. 사용자 정의 보안 관리자 예제 프로그램 실행 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에는 사용자 정의 보안 관리자를 구현하는 방법을 보여주는 예제 프로그램이 포함되어 있습니다. 이 예제에서 사용자 정의 보안 관리자는 인증 및 권한 부여에 대한 세부 정보를 로그한 다음 ActiveMQJAASSecurityManager 의 인스턴스(즉, 기본 보안 관리자)에 세부 정보를 전달합니다.
다음 절차에서는 사용자 정의 보안 관리자 예제 프로그램을 실행하는 방법을 보여줍니다.
사전 요구 사항
- AMQ Broker 예제 프로그램을 실행하도록 머신을 설정해야 합니다. 자세한 내용은 AMQ Broker 예제 실행을 참조하십시오.
절차
사용자 지정 보안 관리자 예제가 포함된 디렉터리로 이동합니다.
cd <install_dir>/examples/features/standard/security-manager
$ cd <install_dir>/examples/features/standard/security-managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 예제를 실행합니다.
mvn verify
$ mvn verifyCopy to Clipboard Copied! Toggle word wrap Toggle overflow
예제 프로그램을 실행할 때 브로커 인스턴스를 수동으로 생성 및 시작하려는 경우 이전 단계의 명령을 mvn -PnoServer 검증 으로 교체합니다.
추가 리소스
-
ActiveMQJAASSecurityManager클래스에 대한 자세한 내용은 ActiveMQ Artemis Core API 설명서의 Class ActiveMQJAASSecurityManager 를 참조하십시오.
5.7. 보안 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
보안은 기본적으로 활성화되어 있습니다. 다음 절차에서는 브로커 보안을 비활성화하는 방법을 설명합니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. core요소에서security-enabled값을false로 설정합니다.<security-enabled>false</security-enabled>
<security-enabled>false</security-enabled>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
필요한 경우
security-invalidation-interval에 새 값(밀리초)을 지정합니다. 이 속성의 값은 브로커가 정기적으로 보안 로그인을 무효화하는 시기를 지정합니다. 기본값은10000입니다.
5.8. 검증된 사용자의 메시지 추적 링크 복사링크가 클립보드에 복사되었습니다!
메시지의 출처를 추적하고 로깅할 수 있도록 (예: 보안 감사 목적으로) _AMQ_VALIDATED_USER 메시지 키를 사용할 수 있습니다.
broker.xml 구성 파일에서 populate-validated-user 옵션이 true 로 설정된 경우 브로커는 _AMQ_VALIDATED_USER 키를 사용하여 검증된 사용자의 이름을 메시지에 추가합니다. JMS 및 STOMP 클라이언트의 경우 이 메시지 키는 JMSXUserID 키에 매핑됩니다.
브로커는 AMQP JMS 클라이언트가 생성한 메시지에 검증된 사용자 이름을 추가할 수 없습니다. 클라이언트에서 AMQP 메시지를 보낸 후 AMQP 메시지의 속성을 수정하는 것은 AMQP 프로토콜을 위반하는 것입니다.
SSL 인증서를 기반으로 인증된 사용자의 경우 브로커에 의해 채워진 검증된 사용자 이름은 인증서의 Distinguished Name(DN)이 매핑되는 이름입니다.
broker.xml 구성 파일에서 security-enabled 가 false 이고 populate-validated-user 가 true 인 경우 브로커는 클라이언트가 제공하는 모든 사용자 이름을 채웁니다. populate-validated-user 옵션은 기본적으로 false 입니다.
메시지를 보낼 때 클라이언트가 이미 채워진 사용자 이름(즉, JMSXUserID 키)이 없는 메시지를 거부하도록 브로커를 구성할 수 있습니다. 브로커가 이러한 클라이언트가 보낸 메시지에 대해 검증된 사용자 이름 자체를 채울 수 없기 때문에 AMQP 클라이언트에 유용한 이 옵션을 찾을 수 있습니다.
클라이언트가 JMSXUserID 를 설정하지 않고 메시지를 거부하도록 브로커를 구성하려면 broker.xml 구성 파일에 다음 구성을 추가합니다.
<reject-empty-validated-user>true</reject-empty-validated-user>
<reject-empty-validated-user>true</reject-empty-validated-user>
기본적으로 reject-empty-validated-user 는 false 로 설정됩니다.
5.9. 구성 파일에서 암호 암호화 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 AMQ Broker는 구성 파일의 모든 암호를 일반 텍스트로 저장합니다. 권한이 없는 액세스를 방지하기 위해 모든 구성 파일을 올바른 권한으로 보호하십시오. 또한 일반 텍스트 암호를 암호화하거나 마스크 하여 원하지 않는 뷰어가 읽을 수 없도록 할 수 있습니다.
5.9.1. 암호화된 암호 정보 링크 복사링크가 클립보드에 복사되었습니다!
암호화되거나 마스킹된 password는 일반 텍스트 암호의 암호화된 버전입니다. 암호화된 버전은 AMQ Broker에서 제공하는 마스크 명령줄 유틸리티에 의해 생성됩니다. 마스크 유틸리티에 대한 자세한 내용은 명령줄 도움말 설명서를 참조하십시오.
<broker_instance_dir>/bin/artemis help mask
$ <broker_instance_dir>/bin/artemis help mask
암호를 마스킹하려면 일반 텍스트 값을 암호화된 값으로 바꿉니다. 마스킹된 암호는 실제 값이 필요할 때 암호를 해독하도록 식별자 ENC() 로 래핑해야 합니다.
다음 예에서 구성 파일 < broker_instance_dir> /etc/bootstrap.xml 에는 keyStorePassword 및 trustStorePassword 매개변수에 대한 마스크된 암호가 포함되어 있습니다.
<web bind="https://localhost:8443" path="web"
keyStorePassword="ENC(-342e71445830a32f95220e791dd51e82)"
trustStorePassword="ENC(32f94e9a68c45d89d962ee7dc68cb9d1)">
<app url="activemq-branding" war="activemq-branding.war"/>
</web>
<web bind="https://localhost:8443" path="web"
keyStorePassword="ENC(-342e71445830a32f95220e791dd51e82)"
trustStorePassword="ENC(32f94e9a68c45d89d962ee7dc68cb9d1)">
<app url="activemq-branding" war="activemq-branding.war"/>
</web>
다음 구성 파일에서 마스킹된 암호를 사용할 수 있습니다.
- broker.xml
- bootstrap.xml
- management.xml
- artemis-users.properties
-
login.config (
LDAPLoginModule과 함께 사용하는 경우)
구성 파일은 < broker_instance_dir> /etc 에서 찾을 수 있습니다.
Artemis-users.properties 는 해시된 암호만 지원합니다. 사용자가 브로커 생성 시 생성될 때 artemis-users.properties 에는 기본적으로 해시된 암호가 포함됩니다. 기본 PropertiesLoginModule 은 artemis-users.properties 파일에서 암호를 디코딩하지 않지만 입력을 해시하고 암호 확인을 위해 해시된 두 값을 비교합니다. 해시된 암호를 마스킹된 암호로 변경하면 AMQ Broker 관리 콘솔에 액세스할 수 없습니다.
broker.xml,bootstrap.xml,management.xml, login.config 는 마스킹되었지만 해시되지 않은 암호를 지원합니다.
5.9.2. 구성 파일에서 암호 암호화 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 broker.xml 구성 파일에서 cluster-password 의 값을 마스킹하는 방법을 보여줍니다.
절차
명령 프롬프트에서
마스크유틸리티를 사용하여 암호를 암호화합니다.<broker_instance_dir>/bin/artemis mask <password>
$ <broker_instance_dir>/bin/artemis mask <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow result: 3a34fd21b82bf2a822fa49a8d8fa115d
result: 3a34fd21b82bf2a822fa49a8d8fa115dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 마스킹할 일반 텍스트 암호가 포함된 <
broker_instance_dir> /etc/broker.xml구성 파일을 엽니다.<cluster-password> <password> </cluster-password>
<cluster-password> <password> </cluster-password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 일반 텍스트 암호를 암호화된 값으로 바꿉니다.
<cluster-password> 3a34fd21b82bf2a822fa49a8d8fa115d </cluster-password>
<cluster-password> 3a34fd21b82bf2a822fa49a8d8fa115d </cluster-password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ENC()식별자로 암호화된 값을 래핑합니다.<cluster-password> ENC(3a34fd21b82bf2a822fa49a8d8fa115d) </cluster-password>
<cluster-password> ENC(3a34fd21b82bf2a822fa49a8d8fa115d) </cluster-password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이제 설정 파일에 암호화된 암호가 포함됩니다. 암호가 ENC() 식별자로 래핑되므로 AMQ Broker가 사용하기 전에 암호를 해독합니다.
추가 리소스
- AMQ Broker에 포함된 구성 파일에 대한 자세한 내용은 1.1절. “AMQ Broker 구성 파일 및 위치” 을 참조하십시오.
5.9.3. 암호를 암호화하고 암호 해독하기 위해 codec 키 설정 링크 복사링크가 클립보드에 복사되었습니다!
암호를 암호화하고 해독하는 데 코드c가 필요합니다. 사용자 정의 코드c가 구성되지 않은 경우 mask 유틸리티는 기본 코드c를 사용하여 암호를 암호화하고 AMQ Broker는 동일한 기본 코드c를 사용하여 암호 해독을 수행합니다. codec는 암호를 암호화하고 해독하기 위해 기본 암호화 알고리즘에 제공하는 기본 키로 구성됩니다. 기본 키를 사용하면 악의적인 행위자가 키를 사용하여 암호 해독을 수행할 위험이 노출됩니다.
마스크 유틸리티를 사용하여 암호를 암호화하는 경우 기본 codec 키를 사용하지 않도록 고유한 키 문자열을 지정할 수 있습니다. 그런 다음 ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY 환경 변수에서 동일한 키 문자열을 설정해야 브로커가 암호를 해독할 수 있습니다. 환경 변수에서 키를 설정하면 구성 파일에 유지되지 않으므로 더 안전합니다. 또한 브로커를 시작하기 직전에 키를 설정하고 브로커가 시작된 직후에 설정을 해제할 수 있습니다.
절차
mask유틸리티를 사용하여 구성 파일의 각 암호를 암호화합니다.key매개변수에 대해 암호를 암호화할 문자 문자열을 지정합니다. 동일한 키 문자열을 사용하여 각 암호를 암호화합니다.<broker_instance_dir>/bin/artemis mask --key <key> <password>
$ <broker_instance_dir>/bin/artemis mask --key <key> <password>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 주의마스크유틸리티를 실행하여 암호를 암호화할 때 지정하는 키 문자열의 레코드를 보관해야 합니다. 브로커가 암호 해독을 허용하도록 환경 변수에 동일한 키 값을 구성해야 합니다.구성 파일의 암호를 암호화하는 방법에 대한 자세한 내용은 5.9.2절. “구성 파일에서 암호 암호화” 을 참조하십시오.
명령 프롬프트에서
ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY환경 변수를 각 암호를 암호화할 때 지정한 키 문자열로 설정합니다.export ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY= <key>
$ export ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY= <key>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 브로커를 시작합니다.
./artemis run
$ ./artemis runCopy to Clipboard Copied! Toggle word wrap Toggle overflow ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY환경 변수를 설정 해제합니다.unset ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY
$ unset ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEYCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고브로커를 시작한 후
ARTEMIS_DEFAULT_SENSITIVE_STRING_CODEC_KEY환경 변수를 설정 해제하는 경우 나중에 브로커를 시작하기 전에 동일한 키 문자열로 다시 설정해야 합니다.
5.10. 인증 및 권한 부여 캐싱 구성 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 AMQ Broker는 인증 및 권한 부여 응답에 대한 정보를 별도의 캐시에 저장합니다. 각 캐시에 허용되는 기본 항목 수와 캐시되는 항목의 기간을 변경할 수 있습니다.
-
<
;broker-instance-dir>/etc/broker.xml구성 파일을 엽니다. 각 캐시에 허용되는 기본 최대 항목 수(
1000)를 변경하려면authentication-cache-size및authorization-cache-size매개변수를 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고캐시가 제한 세트에 도달하면 최근 사용된 항목이 캐시에서 제거됩니다.
기본 기간,
10000밀리초의 항목을 캐시하려면security-invalidation-interval매개변수를 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고security-invalidation-interval매개변수를0으로 설정하면 인증 및 권한 부여 캐싱이 비활성화됩니다.
6장. 메시지 데이터 유지 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에는 유지(즉, 저장) 메시지 데이터를 위한 두 가지 옵션이 있습니다.
- 저널에 메시지 유지
- 이는 기본 옵션입니다. journalctl 기반 지속성은 파일 시스템의 저널에 메시지를 쓰는 고성능 옵션입니다.
- 데이터베이스에 메시지 유지
- 이 옵션은 JDBC( Java Database Connectivity ) 연결을 사용하여 선택한 데이터베이스에 대한 메시지를 유지합니다.
또는 메시지 데이터를 유지하지 않도록 브로커를 구성할 수도 있습니다. 자세한 내용은 6.3절. “지속성 비활성화”의 내용을 참조하십시오.
브로커는 메시지 저널 외부에서 큰 메시지를 유지하는 데 다른 솔루션을 사용합니다. 자세한 내용은 8장. 대용량 메시지 처리를 참조하십시오.
브로커는 메모리 부족 상황에서 디스크에 메시지를 페이징하도록 구성할 수도 있습니다. 자세한 내용은 7.1절. “메시지 페이징 구성”를 참조하십시오.
AMQ Broker에서 지원하는 데이터베이스 및 네트워크 파일 시스템에 대한 최신 정보는 Red Hat Customer Portal에서 Red Hat AMQ 7 지원 구성을 참조하십시오.
6.1. 저널에 메시지 데이터 유지 링크 복사링크가 클립보드에 복사되었습니다!
브로커 저널은 디스크의 추가 전용 파일 집합입니다. 각 파일은 고정된 크기로 미리 생성되며 처음에는 패딩으로 채워집니다. 메시징 작업이 브로커에서 수행되므로 레코드가 저널 끝에 추가됩니다. 레코드를 추가하면 브로커는 일반적으로 디스크에서 가장 느린 작업인 디스크 헤드 이동 및 임의 액세스 작업을 최소화할 수 있습니다. 하나의 저널 파일이 가득 차면 브로커는 새 파일을 생성합니다.
저널 파일 크기는 구성할 수 있으므로 각 파일에서 사용하는 디스크 순환기 수를 최소화합니다. 그러나 최신 디스크 토폴로지는 복잡하며 브로커는 파일이 매핑되는 사이클러를 제어할 수 없습니다. 따라서 저널 파일 크기를 정확하게 제어하기가 어렵습니다.
브로커가 사용하는 다른 지속성 관련 기능은 다음과 같습니다.
- 특정 저널 파일이 아직 사용 중인지 여부를 결정하는 가비지 수집 알고리즘입니다. 저널 파일을 더 이상 사용하지 않는 경우 브로커는 재사용할 파일을 회수할 수 있습니다.
- 저널에서 손상된 공간을 제거하고 데이터를 압축하는 압축 알고리즘입니다. 이렇게 하면 저널이 디스크에 있는 파일을 더 적게 사용합니다.
- 로컬 트랜잭션을 지원합니다.
- JMS 클라이언트를 사용할 때 XA(Extended Architecture) 트랜잭션을 지원합니다.
저널의 대부분은 Java로 작성됩니다. 그러나 연결 가능한 다른 구현을 사용할 수 있도록 실제 파일 시스템과의 상호 작용이 요약됩니다. AMQ Broker에는 다음과 같은 구현이 포함됩니다.
- NIO
- NIO(신규 I/O)는 파일 시스템과의 인터페이스에 표준 Java NIO를 사용합니다. 이는 매우 우수한 성능을 제공하며 Java 6 이상 런타임을 사용하는 모든 플랫폼에서 실행됩니다. Java NIO에 대한 자세한 내용은 Java NIO 를 참조하십시오.
- AIO
AIO(Aynshcronous I/O)는 씬 네이티브 래퍼를 사용하여 Linux 비동기 I/O 라이브러리(
libaio)와 통신합니다. AIO를 사용하면 브로커가 데이터가 디스크에 적용된 후 다시 호출되므로 명시적인 동기화를 방지할 수 있습니다. 기본적으로 브로커는 AIO 저널을 사용하려고 하며 AIO를 사용할 수 없는 경우 NIO를 사용하도록 대체합니다.AIO는 일반적으로 Java NIO보다 더 나은 성능을 제공합니다.
libaio설치 방법을 알아보려면 6.1.1절. “Linux 비동기 I/O 라이브러리 설치” 를 참조하십시오.
다음 하위 섹션의 절차에서는 저널 기반 지속성을 위해 브로커를 구성하는 방법을 보여줍니다.
6.1.1. Linux 비동기 I/O 라이브러리 설치 링크 복사링크가 클립보드에 복사되었습니다!
지속성 성능을 높이기 위해 AIO 저널(NIO 대신)을 사용하는 것이 좋습니다.
다른 운영 체제 또는 이전 버전의 Linux 커널과 함께 AIO 저널을 사용할 수 없습니다.
AIO 저널을 사용하려면 Linux 비동기 I/O 라이브러리(libaio)를 설치해야 합니다. libaio 를 설치하려면 아래와 같이 yum 명령을 사용합니다.
yum install libaio
yum install libaio
6.1.2. 저널 기반 지속성 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 브로커가 저널 기반 지속성에 사용하는 기본 구성을 검토하는 방법을 설명합니다. 필요에 따라 이 설명을 사용하여 구성을 조정할 수 있습니다.
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다.기본적으로 브로커는 아래와 같이 저널 기반 지속성을 사용하도록 구성됩니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow persistence-enabled-
이 매개변수의 값을
true로 설정하면 브로커는 메시지 지속성을 위해 파일 기반 저널을 사용합니다. journal-type-
사용할 저널 유형입니다.
ASYNCIO로 설정하면 브로커는 먼저 AIO를 사용하려고 시도합니다. AIO를 찾을 수 없는 경우 브로커는 NIO를 사용합니다. bindings-directory-
바인딩 저널의 파일 시스템 위치입니다. 기본값은 <
broker_instance_dir> 디렉터리를 기준으로합니다. journal-directory-
메시지 저널의 파일 시스템 위치입니다. 기본값은 <
broker_instance_dir> 디렉터리를 기준으로합니다. journal-datasync-
이 매개변수의 값을
true로 설정하면 브로커는fdatasync함수를 사용하여 디스크 쓰기를 확인합니다. journal-min-files- 브로커가 시작될 때 처음 생성할 저널 파일 수입니다.
journal-pool-files-
사용되지 않는 파일을 회수한 후 보존할 파일 수입니다. 기본값
-1은 정리 중에 파일이 삭제되지 않음을 의미합니다. journal-device-block-size- 스토리지 장치의 저널에 사용되는 데이터 블록의 최대 크기(바이트)입니다. 기본값은 4096바이트입니다.
journal-file-size- 지정된 저널 디렉터리에 있는 각 저널 파일의 최대 크기(바이트)입니다. 이 제한에 도달하면 브로커가 새 파일을 시작합니다. 이 매개변수는 바이트 표기법(예: K, M, G) 또는 동등한 바이너리(Ki, Mi, Gi)도 지원합니다. 구성에 이 매개 변수를 명시적으로 지정하지 않으면 기본값은 10485760바이트(10MiB)입니다.
journal-buffer-timeout- 나노초 단위로 브로커가 저널 버퍼를 플러시하는 빈도를 지정합니다. AIO는 일반적으로 NIO보다 높은 플러시 속도를 사용하므로 브로커는 NIO 및 AIO에 대해 다른 기본값을 유지합니다. 구성에 이 매개 변수가 명시적으로 지정되지 않은 경우 NIO의 기본값은 3333333 나노초(즉, 초당 300번)입니다. AIO의 기본값은 50000 나노초(즉, 초당 2000배)입니다.
journal-max-io한 번에 IO 큐에 있을 수 있는 최대 쓰기 요청 수입니다. 큐가 가득 차면 브로커는 공간을 사용할 수 있을 때까지 추가 쓰기를 차단합니다.
NIO를 사용하는 경우 이 값은 항상
1이어야 합니다. AIO 및this 매개 변수를 사용하는 경우 구성에 명시적으로 지정되지 않은 경우 기본값은500입니다.
- 이전 설명에 따라 스토리지 장치에 필요에 따라 지속성 구성을 조정합니다.
추가 리소스
- 저널 기반 지속성 구성에 사용할 수 있는 모든 매개변수에 대한 자세한 내용은 부록 E. 메시징 jert 구성 을 참조하십시오.
6.1.3. 바인딩 저널 정보 링크 복사링크가 클립보드에 복사되었습니다!
바인딩 저널은 브로커 및 해당 속성에 배포된 큐 세트와 같은 바인딩 관련 데이터를 저장하는 데 사용됩니다. ID 시퀀스 카운터와 같은 데이터도 저장합니다.
바인딩 저널은 일반적으로 메시지 저널에 비해 처리량이 낮기 때문에 항상 NIO를 사용합니다. 이 저널의 파일 앞에는 activemq-bindings 가 붙습니다. 또한 각 파일에는 .bindings 확장과 기본 크기가 1048576바이트입니다.
바인딩 저널을 구성하려면 <broker _instance_dir> /etc/broker.xml 구성 파일의 core 요소에 다음 매개 변수를 포함합니다.
bindings-directory-
바인딩 저널용 디렉터리입니다. 기본값은 <
broker_instance_dir>/data/bindings입니다. create-bindings-dir-
이 매개변수의 값이
true로 설정되면 브로커는 아직 존재하지 않는 경우bindings-directory에 지정된 위치에 바인딩 디렉터리를 자동으로 생성합니다. 기본값은true입니다.
6.1.4. JMS 저널 정보 링크 복사링크가 클립보드에 복사되었습니다!
JMS 저널은 JMS 대기열, 주제 및 연결 팩토리와 이러한 리소스에 대한 모든 JNDI 바인딩을 포함한 모든 JMS 관련 데이터를 저장합니다. 관리 API를 통해 생성된 모든 JMS 리소스는 이 저널에 유지되지만 구성 파일을 통해 구성된 리소스는 그렇지 않습니다. 브로커는 JMS가 사용 중인 경우에만 JMS 저널을 생성합니다.
JMS 저널의 파일 앞에는 activemq-jms 가 붙습니다. 또한 각 파일에는 .jms 의 확장과 기본 크기가 1048576바이트입니다.
JMS 저널은 바인딩 저널과 구성을 공유합니다.
추가 리소스
- 바인딩 저널에 대한 자세한 내용은 6.1.3절. “바인딩 저널 정보” 을 참조하십시오.
6.1.5. 저널 보존 구성 링크 복사링크가 클립보드에 복사되었습니다!
생성된 각 저널 파일의 사본을 유지하도록 AMQ 브로커를 구성할 수 있습니다. 저널 보존을 구성한 후 저널 파일 복사본의 메시지를 재생하여 브로커에 메시지를 보낼 수 있습니다.
6.1.5.1. 저널 보존 구성 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker를 구성하여 특정 기간 동안 또는 스토리지 제한에 도달할 때까지 또는 둘 다 저널 파일의 사본을 유지할 수 있습니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. -
core요소 내에서journal-retention-directory특성을 추가합니다. 저널 파일의 보존을 제어하려면마침표또는스토리지 제한또는 둘 모두를 지정합니다. 또한 저널 파일 복사본의 파일 시스템 위치를 지정합니다. 다음 예제에서는 AMQ Broker를 구성하여7일 동안 또는 파일에서 스토리지10GB를 사용할 때까지데이터/지정 디렉터리에 저널 파일 사본을 유지합니다.
기간- 저널 파일을 복사하는 기간입니다. 기간이 만료되면 AMQ Broker는 지정된 기간보다 오래된 파일을 제거합니다.
단위-
보존 기간에 적용할 측정 단위입니다. 기본값은
DAYS입니다. 다른 유효한 값은HOURS,MINUTES및 CloudEventONDS입니다. directory- 저널 파일 복사본의 파일 시스템 위치입니다. 지정된 디렉터리는 < broker_instance_dir> 디렉터리를 기준으로 합니다.
storage-limit- 모든 저널 파일 복사본에서 사용할 수 있는 최대 스토리지입니다. 스토리지 제한에 도달하면 브로커는 가장 오래된 저널 파일을 제거하여 새 저널 파일 사본을 위한 공간을 제공합니다. 스토리지 제한을 설정하는 것은 저널 파일 보존으로 인해 브로커가 디스크 공간이 부족하여 종료되지 않도록 하는 효과적인 방법입니다.
6.1.5.2. 브로커에 존재하는 주소에 대한 저널 파일 복사본에서 메시지 재생 링크 복사링크가 클립보드에 복사되었습니다!
저널 파일 복사본에서 재생하려는 메시지 주소가 AMQ Broker에 있는 경우 다음 절차를 사용하여 메시지를 재생합니다. 브로커의 원래 주소 또는 다른 주소로 메시지를 재생할 수 있습니다.
절차
- AMQ 관리 콘솔에 로그인합니다. 자세한 내용은 AMQ 관리 콘솔 액세스를 참조하십시오.
- 메인 메뉴에서 Artemis 를 클릭합니다.
- 폴더 트리에서 주소를 클릭하여 주소 목록을 표시합니다.
- 주소 탭을 클릭합니다.
- 메시지를 재생하려는 주소에 대한 Action 열에서 작업을 클릭합니다.
재생 작업을 선택합니다.
- 재생 작업에서 모든 저널 파일 복사본에서 재생할 메시지를 검색하려면 replay(String,String) 작업을 클릭합니다.
- 재생 작업에서 특정 기간 내에 생성된 저널 파일 복사본에서만 재생할 메시지를 검색하려면 replay(String,String, String,String) 작업을 선택합니다. startScanDate 및 endScanDate 필드에서 기간을 지정합니다.
재생 옵션을 지정합니다.
- 대상 필드에서 재생된 메시지를 보낼 브로커의 주소를 지정합니다. 이 필드를 비워 두면 브로커의 원래 주소로 메시지가 재생됩니다.
-
(선택 사항) 필터 필드에서 필터 문자열과 일치하는 메시지만 재생하는 문자열을 지정합니다. 예를 들어 메시지에 storeID 속성이 있는 경우
storeID="1000"필터를 사용하여 저장소 ID 값이 1000인 모든 메시지를 재생할 수 있습니다. 필터를 지정하지 않으면 검사된 저널 파일 복사본의 모든 메시지가 AMQ Broker에 재생됩니다.
- Execute 를 클릭합니다.
추가 리소스
- AMQ 관리 콘솔 사용에 대한 자세한 내용은 AMQ 관리 콘솔 사용을 참조하십시오.
6.1.5.3. 브로커에서 제거된 주소에 대한 저널 파일 복사본에서 메시지 재생 링크 복사링크가 클립보드에 복사되었습니다!
저널 파일 사본에서 재생하려는 메시지 주소가 AMQ Broker에서 제거된 경우 다음 절차를 사용하여 메시지를 브로커의 다른 주소로 재생합니다.
절차
- AMQ 관리 콘솔에 로그인합니다. 자세한 내용은 AMQ 관리 콘솔 액세스를 참조하십시오.
- 메인 메뉴에서 Artemis 를 클릭합니다.
- 폴더 트리에서 최상위 서버를 클릭합니다.
- Operations 탭을 클릭합니다.
재생 작업을 선택합니다.
- 재생 작업에서 모든 저널 파일 복사본에서 재생할 메시지를 검색하려면 replay(String,String,String,String) 작업을 클릭합니다.
- 재생 작업에서 특정 기간 내에 생성된 저널 파일 복사본에서만 재생할 메시지를 검색하려면 replay(String,String, String,String,String,String) 작업을 선택합니다. startScanDate 및 endScanDate 필드에서 기간을 지정합니다.
재생 옵션을 지정합니다.
- address 필드에서 재생할 메시지의 주소를 지정합니다.
- 대상 필드에서 재생된 메시지를 보낼 브로커의 주소를 지정합니다.
-
(선택 사항) 필터 필드에서 필터 문자열과 일치하는 메시지만 재생하는 문자열을 지정합니다. 예를 들어 메시지에 storeID 속성이 있는 경우
storeID="1000"필터를 사용하여 저장소 ID 값이 1000인 모든 메시지를 재생할 수 있습니다. 필터를 지정하지 않으면 검사된 저널 파일 복사본의 모든 메시지가 AMQ Broker에 재생됩니다.
- Execute 를 클릭합니다.
추가 리소스
- AMQ 관리 콘솔 사용에 대한 자세한 내용은 AMQ 관리 콘솔 사용을 참조하십시오.
6.1.6. 저널 파일 압축 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에는 저널에서 손상된 공간을 제거하고 디스크 공간을 적게 차지하도록 데이터를 압축하는 압축 알고리즘이 포함되어 있습니다.
다음 하위 섹션에서는 다음을 수행하는 방법을 보여줍니다.
6.1.6.1. 저널 파일 압축 구성 링크 복사링크가 클립보드에 복사되었습니다!
브로커는 다음 기준을 사용하여 압축을 시작할 시기를 결정합니다.
- 저널에 대해 생성된 파일 수입니다.
- 저널 파일의 라이브 데이터 백분율입니다.
이러한 기준 모두에 대해 구성된 값에 도달하면 압축 프로세스는 저널을 구문 분석하고 모든 실패한 레코드를 제거합니다. 결과적으로 저널은 더 적은 파일로 구성됩니다.
다음 절차에서는 저널 파일 압축을 위해 브로커를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. core요소 내에서journal-compact-min-files및journal-compact-percentage매개변수를 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow journal-compact-min-files-
압축을 시작하기 전에 브로커가 생성해야 하는 최소 저널 파일 수입니다. 기본값은
10입니다. 값을0으로 설정하면 압축이 비활성화됩니다. 압축을 비활성화할 때는 저널 크기가 무기한 증가할 수 있으므로 주의해야 합니다. journal-compact-percentage-
저널 파일의 라이브 데이터 백분율입니다. 이 백분율 미만이 라이브 데이터(및
journal-compact-min-file의 구성된 값에 도달)로 간주되면 압축이 시작됩니다. 기본값은30입니다.
6.1.6.2. 명령줄 인터페이스에서 압축 실행 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 CLI(명령줄 인터페이스)를 사용하여 저널 파일을 압축하는 방법을 보여줍니다.
절차
<
broker_instance_dir> 디렉터리의소유자로서 브로커를 중지합니다. 아래 예제에서는amq-broker사용자를 보여줍니다.su - amq-broker cd <broker_instance_dir>/bin $ ./artemis stop
su - amq-broker cd <broker_instance_dir>/bin $ ./artemis stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow (선택 사항) 다음 CLI 명령을 실행하여 데이터 툴의 전체 매개변수 목록을 가져옵니다. 기본적으로 이 툴에서는 <
broker_instance_dir> /etc/broker.xml에 있는 설정을 사용합니다../artemis help data compact.
$ ./artemis help data compact.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 CLI 명령을 실행하여 데이터를 압축합니다.
./artemis data compact.
$ ./artemis data compact.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 도구가 성공적으로 데이터를 압축한 후 브로커를 다시 시작합니다.
./artemis run
$ ./artemis runCopy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 리소스
- AMQ Broker에는 저널 파일을 관리하기 위한 여러 CLI 명령이 포함되어 있습니다. 자세한 내용은 부록의 명령줄 툴 을 참조하십시오.
6.1.7. 디스크 쓰기 캐시 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
대부분의 디스크에는 하드웨어 쓰기 캐시가 포함되어 있습니다. 쓰기 캐시는 나중에 디스크에 쓰기가 기록되기 때문에 디스크의 명확한 성능을 높일 수 있습니다. 기본적으로 많은 시스템에는 디스크 쓰기 캐시가 활성화되어 있습니다. 즉, 운영 체제에서 동기화한 후에도 데이터가 실제로 디스크로 설정되었음을 보장할 수 없습니다. 오류가 발생하면 중요한 데이터가 손실될 수 있습니다.
일부 더 고가의 디스크에는 오류가 발생할 때 데이터가 손실되지는 않지만 테스트해야합니다. 디스크에 이러한 기능이 없는 경우 쓰기 캐시가 비활성화되어 있는지 확인해야 합니다. 디스크 쓰기 캐시를 비활성화하면 성능에 부정적인 영향을 미칠 수 있습니다.
다음 절차에서는 Windows의 Linux에서 디스크 쓰기 캐시를 비활성화하는 방법을 설명합니다.
절차
-
Linux에서 디스크 쓰기 캐시 설정을 관리하려면 툴
hdparm( IDE 디스크용) 또는sdparm또는sginfo(Sginfo/SATA 디스크용)를 사용합니다. - Windows에서 디스크 작성기 캐시 설정을 관리하려면 디스크를 마우스 오른쪽 버튼으로 클릭합니다. 속성을 선택합니다.
6.2. 데이터베이스에 메시지 데이터 유지 링크 복사링크가 클립보드에 복사되었습니다!
메시지 데이터를 데이터베이스에 유지하는 경우 브로커는 JDBC( Java Database Connectivity ) 연결을 사용하여 메시지 및 바인딩 데이터를 데이터베이스 테이블에 저장합니다. 테이블의 데이터는 AMQ Broker 저널 인코딩을 사용하여 인코딩됩니다. 지원되는 데이터베이스에 대한 자세한 내용은 Red Hat 고객 포털에서 Red Hat AMQ 7 지원 구성을 참조하십시오.
관리자는 조직의 광범위한 IT 인프라의 요구 사항에 따라 메시지 데이터를 데이터베이스에 저장하도록 선택할 수 있습니다. 그러나 데이터베이스를 사용하면 메시징 시스템의 성능에 부정적인 영향을 미칠 수 있습니다. 특히 JDBC를 통해 데이터베이스 테이블에 메시징 데이터를 작성하면 브로커에 상당한 성능 오버헤드가 발생합니다.
6.2.1. JDBC 지속성 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 데이터베이스 테이블에 메시지 및 바인딩 데이터를 저장하도록 브로커를 구성하는 방법을 설명합니다.
절차
-
브로커 런타임에 적절한 JDBC 클라이언트 라이브러리를 추가합니다. 이렇게 하려면 관련
.jar파일을 <broker_instance_dir> /lib디렉터리에 추가합니다. -
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. core요소 내에서데이터베이스요소를 추가합니다.저장소요소를 포함하는 storeCopy to Clipboard Copied! Toggle word wrap Toggle overflow database-store요소 내에서 JDBC 지속성에 대한 구성 매개 변수를 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - jdbc-connection-url
- 데이터베이스 서버에 대한 JDBC 연결 URL입니다. 연결 URL에는 모든 구성 매개변수와 데이터베이스 이름이 포함되어야 합니다.
- jdbc-user
- 데이터베이스 서버의 암호화된 사용자 이름입니다. 구성 파일에 사용할 사용자 이름 및 암호를 암호화하는 방법에 대한 자세한 내용은 5.9절. “구성 파일에서 암호 암호화” 을 참조하십시오.
- jdbc-password
- 데이터베이스 서버의 암호화된 암호입니다. 구성 파일에 사용할 사용자 이름 및 암호를 암호화하는 방법에 대한 자세한 내용은 5.9절. “구성 파일에서 암호 암호화” 을 참조하십시오.
- bindings-table-name
- 데이터를 바인딩하는 테이블의 이름입니다. 테이블 이름을 지정하면 간섭 없이 여러 서버 간에 단일 데이터베이스를 공유할 수 있습니다.
- message-table-name
- 메시지 데이터가 저장되는 테이블의 이름입니다. 이 테이블 이름을 지정하면 간섭 없이 여러 서버 간에 단일 데이터베이스를 공유할 수 있습니다.
- large-message-table-name
- 큰 메시지 및 관련 데이터가 지속되는 테이블의 이름입니다. 또한 클라이언트가 청크로 큰 메시지를 스트리밍하면 청크가 이 테이블에 저장됩니다. 이 테이블 이름을 지정하면 간섭 없이 여러 서버 간에 단일 데이터베이스를 공유할 수 있습니다.
- page-store-table-name
- 디렉터리 정보를 페이징하는 테이블의 이름입니다. 이 테이블 이름을 지정하면 간섭 없이 여러 서버 간에 단일 데이터베이스를 공유할 수 있습니다.
- node-manager-store-table-name
- 라이브 및 백업 브로커 및 기타 HA 관련 데이터에 대한 공유 저장소 HA(고가용성) 잠금이 브로커 서버에 저장되는 테이블의 이름입니다. 이 테이블 이름을 지정하면 간섭 없이 여러 서버 간에 단일 데이터베이스를 공유할 수 있습니다. 공유 저장소 HA를 사용하는 각 라이브 백업 쌍은 동일한 테이블 이름을 사용해야 합니다. 동일한 테이블을 여러 개의 (및 관련이 없는) 라이브 백업 쌍 간에 공유할 수 없습니다.
- jdbc-driver-class-name
- JDBC 데이터베이스 드라이버의 정규화된 클래스 이름입니다. 지원되는 데이터베이스에 대한 자세한 내용은 Red Hat 고객 포털에서 Red Hat AMQ 7 지원 구성을 참조하십시오.
- jdbc-network-timeout
-
JDBC 네트워크 연결 시간(밀리초)입니다. 기본값은 10.0.0.1밀리초입니다. 공유 저장소 HA에 JDBC를 사용하는 경우 시간 제한을
jdbc-lock-expiration보다 작거나 같은 값으로 설정하는 것이 좋습니다. - jdbc-lock-renew-period
-
현재 JDBC 잠금의 갱신 기간의 길이(밀리초)입니다. 이 시간이 지나면 브로커가 잠금을 갱신할 수 있습니다.
jdbc-lock-expiration값보다 작은 값을 여러 번 설정하는 것이 좋습니다. 이를 통해 브로커는 임대를 연장하기에 충분한 시간을 제공하고 연결 문제가 발생한 경우 브로커에 잠금을 갱신하려고 할 수 있습니다. 기본값은 2000밀리초입니다. - jdbc-lock-expiration
jdbc-lock-renew-period값이 경과하더라도 현재 JDBC 잠금을 소유하는 것으로 간주되는 시간(밀리초)입니다.브로커는
jdbc-lock-renew-period값에 따라 소유한 잠금을 주기적으로 갱신하려고 합니다. 브로커가 잠금을 갱신 하지 못하는 경우 (예: 연결 문제로 인해) 잠금을 마지막으로 획득하거나 갱신한 이후jdbc-lock-expiration값이 통과될 때까지 브로커가 잠금을 갱신하려고 합니다.위에서 설명한 갱신 동작에 대한 예외는 다른 브로커가 잠금을 취득하는 경우입니다. DBMS(Database Management System)와 브로커 간에 시간 정렬이 있거나 가비지 수집에 대한 일시 중지가 있는 경우 발생할 수 있습니다. 이 경우 처음 잠금을 소유한 브로커는 잠금이 손실된 것으로 간주하고 갱신을 시도하지 않습니다.
만료 시간이 지나면 현재 이를 보유한 브로커에 의해 JDBC 잠금을 갱신하지 않은 경우 다른 브로커가 JDBC 잠금을 설정할 수 있습니다.
jdbc-lock-expiration의 기본값은 10.0.0.1밀리초입니다.- jdbc-journal-sync-period
- 브로커 저널이 JDBC와 동기화되는 기간(밀리초)입니다. 기본값은 5밀리초입니다.
- jdbc-max-page-size-bytes
-
AMQ Broker가 JDBC 데이터베이스에 메시지를 저장할 때 각 페이지 파일의 최대 크기(바이트)입니다. 기본값은
102400이며, 이는 100KB입니다. 지정한 값은 "K" "MB" 및 "GB"와 같은 바이트 표기법도 지원합니다.
6.2.2. JDBC 연결 풀링 구성 링크 복사링크가 클립보드에 복사되었습니다!
JDBC 지속성을 위해 브로커를 구성한 경우 브로커는 JDBC 연결을 사용하여 메시지 및 바인딩 데이터를 데이터베이스 테이블에 저장합니다.
JDBC 연결이 실패하는 경우 오류가 발생할 때 활성 연결 작업(예: 데이터베이스 읽기 또는 쓰기)이 없는 경우 브로커는 실행 상태를 유지하고 데이터베이스 연결을 다시 설정하려고 시도합니다. 이를 위해 AMQ Broker는 JDBC 연결 풀링 을 사용합니다.
일반적으로 연결 풀은 여러 애플리케이션 간에 공유할 수 있는 지정된 데이터베이스에 대한 열린 연결 집합을 제공합니다.In general, a connection pool provides a set of open connections to a specified database that can be shared between multiple applications. 브로커의 경우 브로커와 데이터베이스 간 연결이 실패하면 브로커는 풀의 다른 연결을 사용하여 데이터베이스에 다시 연결하려고 시도합니다. 이 풀은 브로커가 수신하기 전에 새 연결을 테스트합니다.
다음 예제에서는 JDBC 연결 풀링을 구성하는 방법을 보여줍니다.
JDBC 연결 풀링을 명시적으로 구성하지 않으면 브로커는 기본 구성으로 연결 풀링을 사용합니다. 기본 구성은 기존 JDBC 구성의 값을 사용합니다. 자세한 내용은 기본 연결 풀링 구성을 참조하십시오.
사전 요구 사항
- 이 예제에서는 JDBC 지속성 구성을 위한 예제를 기반으로 합니다. 참조 6.2.1절. “JDBC 지속성 구성”
연결 풀링을 활성화하기 위해 AMQ Broker는 Apache Commons DBCP 패키지를 사용합니다. 브로커에 대한 JDBC 연결 풀링을 구성하기 전에 이 패키지가 제공하는 기능에 대해 잘 알고 있어야 합니다. 자세한 내용은 다음을 참조하십시오.
절차
-
<
;broker-instance-dir> /etc/broker.xml구성 파일을 엽니다. JDBC 구성에 이전에 추가한
database-store요소에서jdbc-driver-class-name,jdbc-connection-url,jdbc-user,jdbc-password, 매개변수를 제거합니다. 이 절차의 뒷부분에서 이러한 매개변수를 해당 DBCP 구성 매개변수로 바꿉니다.참고이전 매개변수를 명시적으로 제거하지 않으면 이 절차의 뒷부분에서 추가하는 해당 DBCP 매개변수가 우선합니다.
database-store요소 내에서data-source-properties요소를 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새로운
data-source-properties요소 내에서 연결 풀링을 위한 DBCP 데이터 소스 속성을 추가합니다. 키-값 쌍을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow driverClassName- JDBC 데이터베이스 드라이버의 정규화된 클래스 이름입니다.
url- 데이터베이스 서버에 대한 JDBC 연결 URL입니다.
사용자 이름- 데이터베이스 서버의 암호화된 사용자 이름입니다. 이 값을 암호화되지 않은 일반 텍스트로 지정할 수도 있습니다. 구성 파일에 사용할 사용자 이름 및 암호를 암호화하는 방법에 대한 자세한 내용은 5.9절. “구성 파일에서 암호 암호화” 을 참조하십시오.
암호- 데이터베이스 서버의 암호화된 암호입니다. 이 값을 암호화되지 않은 일반 텍스트로 지정할 수도 있습니다. 구성 파일에 사용할 사용자 이름 및 암호를 암호화하는 방법에 대한 자세한 내용은 5.9절. “구성 파일에서 암호 암호화” 을 참조하십시오.
poolPreparedStatements-
이 매개 변수의 값을
true로 설정하면 풀에 캐시된 준비 문을 무제한으로 사용할 수 있습니다. 이렇게 하면 초기화 비용이 줄어듭니다. maxTotal-
풀의 최대 연결 수입니다. 이 매개변수의 값이
-1로 설정되면 제한이 없습니다.
JDBC 연결 풀링을 명시적으로 구성하지 않으면 브로커는 기본 구성으로 연결 풀링을 사용합니다. 기본 구성은 표에 설명되어 있습니다.
| DBCP 구성 매개변수 | 기본값 |
|---|---|
|
|
기존 |
|
|
기존 |
|
|
기존 |
|
|
기존 |
|
|
|
|
|
|
재연결은 클라이언트가 브로커에 적극적으로 메시지를 전송하지 않는 경우에만 작동합니다. 재연결 중에 데이터베이스 테이블에 쓰려는 시도가 있으면 브로커가 실패하고 종료합니다.
추가 리소스
- AMQ Broker에서 지원하는 데이터베이스에 대한 자세한 내용은 Red Hat 고객 포털에서 Red Hat AMQ 7 지원 구성을 참조하십시오.
- Apache Commons DBCP 패키지에서 사용 가능한 모든 구성 옵션에 대한 자세한 내용은 Apache Commons DBCP Configuration Parameters 를 참조하십시오.
6.3. 지속성 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
경우에 따라 메시징 시스템이 데이터를 저장하지 않는 것이 필요할 수 있습니다. 이러한 상황에서는 브로커의 지속성을 비활성화할 수 있습니다.
다음 절차에서는 지속성을 비활성화하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. core요소 내에서persistence-enabled매개변수 값을false로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 메시지 데이터, 바인딩 데이터, 대용량 메시지 데이터, 중복 ID 캐시 또는 페이징 데이터가 유지되지 않습니다.
7장. 주소에 대한 메모리 사용량 구성 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker는 브로커를 호스팅하는 머신이 제한된 메모리로 실행되는 경우에도 수백만 개의 메시지를 포함하는 대규모 큐를 투명하게 지원합니다.
이러한 상황에서는 한 번에 메모리에 모든 대기열을 저장할 수 없습니다. 과도한 메모리 소비를 방지하기 위해 브로커의 각 주소에 허용되는 최대 메모리 사용량을 구성할 수 있습니다. 또한 주소에 대한 메모리 사용량이 구성된 제한에 도달하면 다음 작업 중 하나를 수행하도록 브로커를 구성할 수 있습니다.
- 페이지 메시지
- 자동으로 메시지 삭제
- 메시지를 삭제하고 전송 고객에게 알립니다.
- 메시지 전송에서 차단 클라이언트
주소에 대한 최대 메모리 사용량에 도달할 때 브로커를 페이지 메시지로 구성하는 경우 특정 주소에 대한 제한을 다음과 같이 구성할 수 있습니다.
- 수신되는 메시지를 페이징하는 데 사용되는 디스크 공간 제한
- 클라이언트가 메시지를 사용할 준비가 되면 브로커가 디스크에서 메모리로 전송하는 페이징 메시지에 사용되는 메모리를 제한합니다.
구성된 모든 페이징 제한을 재정의하는 디스크 사용량 임계값을 설정할 수도 있습니다. 디스크 사용량 임계값에 도달하면 브로커는 페이징을 중지하고 들어오는 모든 메시지를 차단합니다.
트랜잭션을 사용할 때 브로커는 트랜잭션 일관성을 보장하기 위해 추가 메모리를 할당할 수 있습니다. 이 경우 브로커에 의해 보고된 메모리 사용량이 메모리에서 사용되는 총 바이트 수를 반영하지 못할 수 있습니다. 따라서 지정된 최대 메모리 사용량에 따라 브로커를 페이지, 드롭 또는 블록으로 구성하는 경우 트랜잭션도 사용해서는 안 됩니다.
7.1. 메시지 페이징 구성 링크 복사링크가 클립보드에 복사되었습니다!
최대 메모리 사용량 제한이 지정된 모든 주소에 대해 해당 사용량 제한에 도달할 때 브로커가 수행하는 작업을 지정할 수도 있습니다. 구성할 수 있는 옵션 중 하나는 페이징 입니다.
페이징 옵션을 구성하면 주소의 최대 크기에 도달하면 브로커는 해당 주소에 대한 메시지를 디스크에 저장하기 시작합니다. 각 페이지 파일에는 구성할 수 있는 최대 크기가 있습니다. 이러한 방식으로 구성하는 각 주소에는 페이지된 메시지를 저장할 파일 시스템에 전용 폴더가 있습니다.
큐 브라우저와 소비자 모두 큐의 메시지를 검사할 때 페이지 파일을 탐색할 수 있습니다. 그러나 매우 구체적인 필터를 사용하는 소비자는 큐의 기존 메시지가 먼저 소비될 때까지 페이지 파일에 저장된 메시지를 소비하지 못할 수 있습니다. 예를 들어 소비자 필터에 "color='red'" 와 같은 문자열 표현식이 포함되어 있다고 가정합니다. 이 조건을 충족하는 메시지가 "color='blue' 속성을 가진 100만 개의 메시지를 따르는 경우 "color=' 가 먼저 소비될 때까지 소비자는 메시지를 사용할 수 없습니다.
blue '
브로커는 클라이언트가 사용할 준비가 되었을 때 디스크에서 메모리로 메시지를 전송(즉, depages)합니다. 브로커는 해당 파일의 모든 메시지가 확인되면 디스크에서 페이지 파일을 제거합니다.
다음 절차에서는 메시지 페이징을 구성하는 방법을 보여줍니다.
7.1.1. 페이징 디렉터리 지정 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 페이징 디렉터리의 위치를 지정하는 방법을 설명합니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. core요소 내에서paging-directory요소를 추가합니다. 파일 시스템에서 페이징 디렉토리의 위치를 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이후에 페이징을 위해 구성하는 각 주소에 대해 브로커는 지정한 페이징 디렉터리에 전용 디렉터리를 추가합니다.
7.1.2. 페이징의 주소 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 페이징에 대한 주소를 구성하는 방법을 설명합니다.
사전 요구 사항
- 주소 및 주소 설정을 구성하는 방법에 대해 잘 알고 있어야 합니다. 자세한 내용은 4장. 주소 및 대기열 구성의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 일치하는 주소 또는 주소 집합에 대해 구성한
address-setting요소의 경우 구성 요소를 추가하여 최대 메모리 사용량을 지정하고 페이징 동작을 정의합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow max-size-bytes-
브로커가
address-full-policy특성에 지정된 작업을 실행하기 전에 주소에 허용되는 메모리의 최대 크기(바이트)입니다. 기본값은-1이며 이는 제한이 없음을 의미합니다. 지정한 값은 "K", "MB" 및 "GB"와 같은 바이트 표기법도 지원합니다. max-size-Forwarded-
브로커가
address-full-policy특성에 지정된 작업을 실행하기 전에 주소에 허용되는 최대 메시지 수입니다. 기본값은 -1이며, 이는 메시지 제한이 없음을 의미합니다. page-size-bytes-
페이징 시스템에 사용되는 각 페이지 파일의 크기(바이트)입니다. 기본값은
10485760(즉, 10MiB)입니다. 지정한 값은 "K", "MB" 및 "GB"와 같은 바이트 표기법도 지원합니다. address-full-policy주소의 최대 크기에 도달했을 때 브로커가 수행하는 작업입니다. 기본값은
PAGE입니다. 유효한 값은 다음과 같습니다.PAGE- 브로커는 디스크에 추가 메시지를 표시합니다.
DROP- 브로커는 추가 메시지를 자동으로 삭제합니다.
FAIL- 브로커는 추가 메시지를 삭제하고 클라이언트 메시지 생산자에 대한 예외를 발행합니다.
BLOCK- 클라이언트 메시지 생산자는 추가 메시지를 보내려고 할 때 차단됩니다.
max-size-
bytes 및속성에 대한 제한을 설정하면 브로커는 제한 중 하나에 도달할 때max-size-messageaddress-full-policy속성에 지정된 작업을 실행합니다. 이전 예제의 구성에서 브로커는 메모리의 전체 메시지가 20,000을 초과하거나 사용 가능한 메모리의 104857600 바이트를 사용하는 경우my.paged.address주소에 대한 페이징 메시지를 시작합니다.이전 예에서 표시되지 않는 추가 페이징 구성 요소는 다음과 같습니다.
page-sync-timeout-
주기적인 페이지 동기화 사이의 시간(nanoseconds)입니다. 비동기 IO 저널(즉,
journal-type이broker.xml구성 파일에서ASYNCIO로 설정되는 경우) 기본값은3333333입니다. 표준 Java NIO 저널(즉,journal-type이NIO로 설정된 경우 기본값은journal-buffer-timeout매개변수의 구성된 값입니다.
위 예에서 my.paged.address 주소로 전송된 메시지가 메모리의 104857600 바이트를 초과하면 브로커가 페이징을 시작합니다.
max-size-bytes 를 address-setting 요소에서 지정하는 경우 해당 값은 일치하는 각 주소에 적용됩니다. 이 값을 지정하면 일치하는 모든 주소의 총 크기가 max-size-bytes 값으로 제한되는 것은 아닙니다.
7.1.3. 글로벌 페이징 크기 구성 링크 복사링크가 클립보드에 복사되었습니다!
예를 들어, 주소당 메모리 제한을 구성하는 것은 실용적이지 않은 경우가 있습니다. 예를 들어 브로커가 사용 패턴이 다른 여러 주소를 관리하는 경우가 있습니다. 이러한 상황에서는 글로벌 메모리 제한을 지정할 수 있습니다. 글로벌 제한은 브로커가 모든 주소에 사용할 수 있는 총 메모리 양입니다. 이 메모리 제한에 도달하면 브로커는 들어오는 각 메시지에 연결된 주소의 address-full-policy 속성에 대해 지정된 작업을 실행합니다.
다음 절차에서는 글로벌 페이징 크기를 구성하는 방법을 설명합니다.
사전 요구 사항
- 페이징을 위해 주소를 구성하는 방법에 대해 잘 알고 있어야 합니다. 자세한 내용은 7.1.2절. “페이징의 주소 구성”의 내용을 참조하십시오.
절차
브로커를 중지합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis stop
<broker_instance_dir>/bin/artemis stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe stop
<broker_instance_dir>\bin\artemis-service.exe stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. core요소 내에서global-max-size요소를 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow global-max-size브로커가 모든 주소에 사용할 수 있는 총 메모리 크기(바이트)입니다. 이 제한에 도달하면 브로커는 들어오는 각 메시지와 연결된 주소의
address-full-policy속성에 대해 지정된 작업을 실행합니다.global-max-size의 기본값은 브로커를 호스팅하는 JVM(Java 가상 머신)에서 사용할 수 있는 최대 메모리의 절반입니다.global-max-size의 값은 바이트이지만 바이트 표기법(예: "K", "Mb", "GB")도 지원합니다.이전 예에서 브로커는 메시지를 처리할 때 사용 가능한 최대 1GB의 메모리를 사용하도록 구성됩니다.
global-max-messages모든 주소에 허용되는 총 메시지 수입니다. 이 제한에 도달하면 브로커는 들어오는 각 메시지와 연결된 주소의
address-full-policy속성에 대해 지정된 작업을 실행합니다. 기본값은 -1이며, 이는 메시지 제한이 없음을 의미합니다.global-max-
size 및Forwarded 속성에 대한 제한을 설정하면 브로커는 제한 중 하나에 도달할 때global-max-address-full-policy속성에 지정된 작업을 실행합니다. 이전 예제의 구성을 사용하면 메모리의 메시지 수가 900,000을 초과하면 브로커가 모든 주소에 대한 페이징 메시지를 시작하거나 1GB의 사용 가능한 메모리를 사용합니다.참고개별 주소에 대해 설정된 제한은
max-size-bytes또는max-size-message속성을 사용하여global-max-size또는global-max-knative 속성에 대해 설정된 제한 전에 해당 주소에 대한address-full-policy특성에 지정된 작업을 실행합니다.
브로커를 시작합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis run
<broker_instance_dir>/bin/artemis runCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe start
<broker_instance_dir>\bin\artemis-service.exe startCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.4. 특정 주소에 대한 페이징 중 디스크 사용량 제한 링크 복사링크가 클립보드에 복사되었습니다!
브로커가 개별 주소 또는 주소 집합에 대해 들어오는 메시지 페이징을 중지하기 전에 사용할 수 있는 디스크 공간의 양을 제한할 수 있습니다.
절차
브로커를 중지합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis stop
<broker_instance_dir>/bin/artemis stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe stop
<broker_instance_dir>\bin\artemis-service.exe stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. core요소 내에서 디스크 사용량 또는 메시지 수 또는 둘 다에 따라 페이징 제한을 지정하고 두 제한에 도달하면 수행할 작업을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow page-limit-bytes-
브로커가
page-full-policy속성에 지정된 작업을 실행하기 전에 주소로 들어오는 메시지를 페이징할 수 있는 디스크 공간의 최대 크기(바이트)입니다. 지정한 값은 "K", "MB" 및 "GB"와 같은 바이트 표기법을 지원합니다. 기본값은 -1이며 이는 제한이 없음을 의미합니다. page-limit-messages-
브로커가
page-full-policy속성에 지정된 작업을 실행하기 전에 주소에 대해 페이징할 수 있는 최대 수신 메시지 수입니다. 기본값은 -1이며, 이는 메시지 제한이 없음을 의미합니다. page-full-policy주소에 대해
page-limit-bytes또는page-limit-ECDHE 속성에 설정된 제한에도달하는 경우 브로커가 수행하는 작업입니다. 유효한 값은 다음과 같습니다.DROP 브로커는 추가 메시지를 자동으로 삭제합니다.
FAIL(실패) 브로커는 추가 메시지를 삭제하고 전송 클라이언트에 알리는 메시지를 표시합니다.
이전 예에서
my.paged.address주소에 대한 브로커 페이지 메시지는 페이징이 10GB의 디스크 공간을 사용하거나 총 1억 개의 메시지가 페이징될 때까지입니다.
브로커를 시작합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis run
<broker_instance_dir>/bin/artemis runCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe start
<broker_instance_dir>\bin\artemis-service.exe startCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.5. 메모리로 페이징 메시지의 흐름 제어 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker가 메시지를 디스크에 페이징하도록 구성된 경우 브로커는 페이징된 메시지를 읽고 클라이언트가 메시지를 사용할 준비가 되면 메시지를 메모리로 전송합니다. 메시지가 초과 메모리를 소비하지 않도록 하려면 브로커가 디스크에서 메모리로 전송하는 메시지에 대해 각 주소에서 사용하는 메모리를 제한할 수 있습니다.
클라이언트 애플리케이션이 승인 보류 중 메시지를 너무 많이 남겨 두면 브로커는 보류 중인 메시지가 승인될 때까지 페이지가 지정된 메시지를 읽지 않으므로 브로커에서 메시지 중단을 유발할 수 있습니다.
예를 들어, 페이지링된 메시지를 메모리로 전송하는 데 대한 제한이 기본적으로 20MB인 경우 브로커는 더 많은 메시지를 읽기 전에 클라이언트에서 승인을 기다립니다. 동시에 클라이언트가 브로커에 승인을 보내기 전에 충분한 메시지를 받기를 기다리는 경우 클라이언트가 사용하는 배치 크기에 따라 결정됩니다.
중단을 방지하기 위해 페이지링된 메시지를 메모리로 전송하거나 메시지 전달 수를 줄이는 브로커 제한을 늘립니다. 메시지를 더 빨리 커밋하거나 브로커에서 더 이상 메시지가 수신되지 않으면 시간 초과를 커밋하고 승인을 커밋하도록 하여 전송 메시지 수를 줄일 수 있습니다.
AMQ Management Console에서 큐의 제공 수 및 Delivering Cryostats 메트릭에서 메시지 전달 의 수와 크기를 확인할 수 있습니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. -
일치하는 주소 또는 주소 집합에 대해 구성한
address-settings요소의 경우 페이지 메시지의 메모리 전송에 대한 제한을 지정합니다. 예를 들면 다음과 같습니다.
max-read-page- >-< 브로커가 주소당 메모리에서 읽을 수 있는 최대 페이징 메시지 수입니다. 기본값은 -1이며 이는 제한이 적용되지 않음을 의미합니다.
max-read-page-bytes 는 브로커가 주소당 디스크에서 메모리로 읽을 수 있는 페이징 메시지의 바이트 단위의 최대 크기입니다. 기본값은 20MB입니다.
max-read-page -Forwarded 및 속성 모두에 대한 제한을 지정하면 두 제한에 도달하면 브로커는 메시지 읽기를 중지합니다.
max-read-page -bytes
7.1.6. 디스크 사용량 임계값 설정 링크 복사링크가 클립보드에 복사되었습니다!
디스크 사용량 임계값에 도달하면 브로커가 페이징을 중지하고 들어오는 모든 메시지를 차단할 수 있습니다.
절차
브로커를 중지합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis stop
<broker_instance_dir>/bin/artemis stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe stop
<broker_instance_dir>\bin\artemis-service.exe stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. core요소 내에서max-disk-usage구성 요소를 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow max-disk-usage브로커가 사용할 수 있는 사용 가능한 디스크 공간의 최대 백분율입니다. 이 제한에 도달하면 브로커는 들어오는 메시지를 차단합니다. 기본값은
90입니다.이전 예에서 브로커는 사용 가능한 디스크 공간의 8 %를 사용하도록 제한됩니다.
브로커를 시작합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis run
<broker_instance_dir>/bin/artemis runCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe start
<broker_instance_dir>\bin\artemis-service.exe startCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2. 메시지 삭제 구성 링크 복사링크가 클립보드에 복사되었습니다!
7.1.2절. “페이징의 주소 구성” 페이징을 위해 주소를 구성하는 방법을 보여줍니다. 해당 절차의 일부로 address-full-policy 값을 PAGE 로 설정합니다.
주소가 지정된 최대 크기에 도달하면 메시지를 드롭 하려면 address-full-policy 의 값을 다음 중 하나로 설정합니다.
DROP- 지정된 주소의 최대 크기에 도달하면 브로커는 추가 메시지를 자동으로 삭제합니다.
FAIL- 지정된 주소의 최대 크기에 도달하면 브로커는 추가 메시지를 삭제하고 생산자에 예외를 발행합니다.
7.3. 메시지 차단 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 지정된 주소가 지정된 최대 크기 제한에 도달하면 메시지 차단을 구성하는 방법을 보여줍니다.
Core, OpenECDHEre 및 AMQP 프로토콜에 만 메시지 차단을 구성할 수 있습니다.
7.3.1. Blocking Core 및 OpenECDHEre 생산자 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 지정된 주소가 지정한 최대 크기 제한에 도달하면 Core 및 OpenECDHEre 메시지 생산자에 대한 메시지 차단을 구성하는 방법을 보여줍니다.
사전 요구 사항
- 주소 및 주소 설정을 구성하는 방법에 대해 잘 알고 있어야 합니다. 자세한 내용은 4장. 주소 및 대기열 구성의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 일치하는 주소 또는 주소 집합에 대해 구성한
address-setting요소의 경우 구성 요소를 추가하여 메시지 차단 동작을 정의합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow max-size-bytes브로커가
address-full-policy에 지정된 정책을 실행하기 전에 주소에 허용되는 메모리의 최대 크기(바이트)입니다. 지정한 값은 "K", "MB" 및 "GB"와 같은 바이트 표기법도 지원합니다.참고max-size-bytes를address-setting요소에서 지정하는 경우 해당 값은 일치하는 각 주소에 적용됩니다. 이 값을 지정하면 일치하는 모든 주소의 총 크기가max-size-bytes값으로 제한되는 것은 아닙니다.address-full-policy- 브로커가 주소의 최대 크기에 도달했을 때 걸리는 작업입니다.
이전 예에서
my.blocking.address주소로 전송된 메시지가 메모리에서 300000 바이트를 초과하면 브로커는 Core 또는 OpenECDHEre 메시지 생산자의 추가 메시지를 차단하기 시작합니다.
7.3.2. AMQP 생산자 차단 링크 복사링크가 클립보드에 복사되었습니다!
Core 및 Open>-<re와 같은 프로토콜은 창 크기 흐름 제어 시스템을 사용합니다. 이 시스템에서 단위는 바이트를 나타내며 생산자에 할당됩니다. 프로듀서가 메시지를 보내려는 경우 생산자는 메시지 크기에 충분한 단위가 있을 때까지 기다려야 합니다.
반면 AMQP 흐름 제어 유효성은 바이트를 나타내지 않습니다. 대신 AMQP 점수는 메시지 크기에 관계없이 생산자가 전송할 수 있는 메시지의 수를 나타냅니다. 따라서 AMQP 생산자가 주소의 max-size-bytes 값을 크게 초과할 수 있는 경우도 있습니다.
따라서 AMQP 생산자를 차단하려면 다른 구성 요소인 max-size-bytes-reject-threshold 를 사용해야 합니다. 일치하는 주소 또는 주소 집합에 대해 이 요소는 메모리에 있는 모든 AMQP 메시지의 최대 크기(바이트)를 지정합니다. 메모리에 있는 모든 메시지의 총 크기가 지정된 제한에 도달하면 브로커는 AMQP 생산자가 추가 메시지를 보내는 것을 차단합니다.
다음 절차에서는 AMQP 메시지 생산자에 대한 메시지 차단을 구성하는 방법을 보여줍니다.
사전 요구 사항
- 주소 및 주소 설정을 구성하는 방법에 대해 잘 알고 있어야 합니다. 자세한 내용은 4장. 주소 및 대기열 구성의 내용을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 일치하는 주소 또는 주소 집합에 대해 구성한
address-setting요소의 경우 메모리에 있는 모든 AMQP 메시지의 최대 크기를 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow max-size-bytes-reject-threshold브로커가 AMQP 메시지를 더 차단하기 전에 주소에 허용된 메모리의 최대 크기(바이트)입니다. 지정한 값은 "K", "MB" 및 "GB"와 같은 바이트 표기법도 지원합니다. 기본적으로
max-size-bytes-reject-threshold는-1로 설정되며, 이는 최대 크기가 없음을 의미합니다.참고address-setting요소에서max-size-bytes-reject-threshold를 지정하면 해당 값이 일치하는 각 주소에 적용됩니다. 이 값을 지정하면 일치하는 모든 주소의 총 크기가max-size-bytes-reject-threshold값으로 제한되는 것은 아닙니다.
이전 예에서 my.amqp.blocking.address 주소로 전송된 메시지가 메모리에서 300000바이트를 초과하면 브로커가 AMQP 생산자의 추가 메시지를 차단하기 시작합니다.
7.4. 멀티 캐스트 주소의 메모리 사용량 이해 링크 복사링크가 클립보드에 복사되었습니다!
메시지가 멀티 캐스트 큐가 바인딩된 주소로 라우팅되면 메모리에 메시지 사본이 하나만 있습니다. 각 큐에는 메시지에 대한 참조 만 있습니다. 이로 인해 연결된 메모리는 메시지를 참조하는 모든 큐가 제공한 후에만 해제됩니다.
이러한 유형의 상황에서 사용자가 느린 경우 전체 주소가 성능에 부정적인 영향을 미칠 수 있습니다.
예를 들어 다음 시나리오를 고려하십시오.
- 주소에는 멀티 캐스트 라우팅 유형을 사용하는 큐가 10개 있습니다.
- 소비자 속도가 느리기 때문에 대기열 중 하나가 메시지를 전달하지 않습니다. 나머지 9개의 대기열은 계속 메시지를 전달하며 비어 있습니다.
- 메시지는 주소에 계속 도달합니다. 느린 소비자가 있는 큐는 메시지에 대한 참조를 계속 누적하여 브로커가 메모리에 메시지를 보관하도록 합니다.
- 주소의 최대 크기에 도달하면 브로커가 페이지 메시지로 시작합니다.
이 시나리오에서는 속도가 느린 단일 소비자로 인해 모든 대기열의 소비자가 페이지 시스템의 메시지를 소비하도록 강제되며 추가 IO가 필요합니다.
추가 리소스
- 브로커와 생산자와 소비자 간의 데이터 흐름을 규제하기 위해 흐름 제어를 구성하는 방법을 알아보려면 AMQ Core Protocol JMS 문서의 흐름 제어를 참조하십시오.
8장. 대용량 메시지 처리 링크 복사링크가 클립보드에 복사되었습니다!
클라이언트는 브로커의 내부 버퍼 크기를 초과할 수 있는 대용량 메시지를 보내 예기치 않은 오류가 발생할 수 있습니다. 이 상황을 방지하려면 메시지가 지정된 최소 값보다 클 때 메시지를 파일로 저장하도록 브로커를 구성할 수 있습니다. 이러한 방식으로 대용량 메시지를 처리한다는 것은 브로커가 메모리에 메시지를 보관하지 않음을 의미합니다. 대신 디스크 또는 브로커가 대용량 메시지 파일을 저장하는 데이터베이스 테이블에 디렉터리를 지정합니다.
브로커가 메시지를 큰 메시지로 저장하면 큐는 큰 메시지 디렉터리 또는 데이터베이스 테이블에 파일에 대한 참조를 유지합니다.
Core Protocol, AMQP, Open>-<re 및 STOMP 프로토콜에 대규모 메시지 처리를 사용할 수 있습니다.
코어 프로토콜 및 Open>-<re 프로토콜의 경우 클라이언트는 연결 구성에서 최소 큰 메시지 크기를 지정합니다. AMQP 및 STOMP 프로토콜의 경우 브로커 구성의 각 프로토콜에 대해 정의된 acceptor에 최소 큰 메시지 크기를 지정합니다.
대규모 메시지를 생성하고 사용하기 위해 다른 프로토콜을 사용하지 않는 것이 좋습니다. 이를 위해 브로커는 메시지의 여러 변환을 수행해야 할 수 있습니다. 예를 들어 AMQP 프로토콜을 사용하여 메시지를 보내고 Open>-<re를 사용하여 메시지를 수신하려고 한다고 가정해 보겠습니다. 이 상황에서 브로커는 먼저 큰 메시지의 전체 본문을 읽고 코어 프로토콜을 사용하도록 변환해야합니다. 그런 다음 브로커가 다른 변환을 수행해야하며, 이번에는 Open>-<re 프로토콜로 전환해야합니다. 이와 같은 메시지 변환은 브로커에서 상당한 처리 오버헤드를 유발합니다.
이전 프로토콜에 지정하는 최소 큰 메시지 크기는 사용 가능한 디스크 공간 및 메시지 크기와 같은 시스템 리소스의 영향을 받습니다. 여러 값을 사용하여 성능 테스트를 실행하여 적절한 크기를 결정하는 것이 좋습니다.
이 섹션의 절차에서는 다음을 수행하는 방법을 보여줍니다.
- 대규모 메시지를 저장하도록 브로커 구성
- 대규모 메시지 처리를 위해 AMQP 및 STOMP 프로토콜에 대한 수락자 구성
이 섹션에서는 대규모 메시지와 함께 작동하도록 AMQ OpenECDHEre JMS 클라이언트 구성에 대한 추가 리소스에도 연결합니다.
8.1. 대용량 메시지 처리를 위한 브로커 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 디스크에서 디렉터리를 지정하거나 브로커가 대용량 메시지 파일을 저장하는 데이터베이스 테이블을 지정하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 브로커가 대용량 메시지 파일을 저장할 위치를 지정합니다.
큰 메시지를 디스크에 저장하는 경우
core요소 내에large-ECDHE-directory매개변수를 추가하고 파일 시스템 위치를 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고large-ECDHE-directory의 값을 명시적으로 지정하지 않으면 브로커는 <broker_instance_dir> /data/large>-<의 기본값을 사용합니다.데이터베이스 테이블에 대규모 메시지를 저장하는 경우
large-message-table매개변수를database-store요소에 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고큰 메시지 테이블의 값을 명시적으로 지정하지 않으면 브로커는LARGE_MESSAGE_ECDHE 의 기본값을 사용합니다.
추가 리소스
- 데이터베이스 저장소 구성에 대한 자세한 내용은 6.2절. “데이터베이스에 메시지 데이터 유지” 을 참조하십시오.
8.2. 대규모 메시지 처리를 위한 AMQP 어셉터 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 AMQP 어셉터를 구성하여 지정된 크기보다 큰 AMQP 메시지를 큰 메시지로 처리하는 방법을 보여줍니다.
절차
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다.브로커 구성 파일의 기본 AMQP 어셉터는 다음과 같습니다.
<acceptors> ... <acceptor name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300</acceptor> ... </acceptors><acceptors> ... <acceptor name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300</acceptor> ... </acceptors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본 AMQP 어셉터(또는 구성한 다른 AMQP 어셉터)에서
amqpMinLargeMessageSize속성을 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.<acceptors> ... <acceptor name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpMinLargeMessageSize=204800</acceptor> ... </acceptors><acceptors> ... <acceptor name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpMinLargeMessageSize=204800</acceptor> ... </acceptors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 예에서 브로커는 포트 5672에서 AMQP 메시지를 수락하도록 구성됩니다.
amqpMinLargeMessageSize값에 따라 acceptor에서 204800바이트보다 크거나 같은 본문이 있는 AMQP 메시지를 수신하는 경우 브로커는 메시지를 큰 메시지로 저장합니다. 이 속성의 값을 명시적으로 지정하지 않으면 브로커는 기본값 102400(즉, 100KB)을 사용합니다.
-
amqpMinLargeMessageSize를 -1로 설정하면 AMQP 메시지에 대한 큰 메시지 처리가 비활성화됩니다. -
브로커가
mqpMinLargeMessageSize 값을 초과하지 않지만 메시징 저널 버퍼 크기(journal-buffer-size구성 매개변수를 사용하여 지정됨)를 초과하는 영구 AMQP 메시지를 수신하면 브로커는 메시지를 저널에 저장하기 전에 큰 코어 프로토콜 메시지로 변환합니다.
8.3. 대용량 메시지 처리를 위한 STOMP 수락자 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 STOMP 수락자를 구성하여 지정된 크기보다 큰 메시지보다 큰 STOMP 메시지를 처리하는 방법을 보여줍니다.
절차
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다.브로커 구성 파일의 기본 AMQP 어셉터는 다음과 같습니다.
<acceptors> ... <acceptor name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true</acceptor> ... </acceptors><acceptors> ... <acceptor name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true</acceptor> ... </acceptors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본 STOMP 수용자(또는 다른 STOMP 어셉터)에서
stompMinLargeMessageSize속성을 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.<acceptors> ... <acceptor name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true;stompMinLargeMessageSize=204800</acceptor> ... </acceptors><acceptors> ... <acceptor name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true;stompMinLargeMessageSize=204800</acceptor> ... </acceptors>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이전 예에서 브로커는 포트 61613에서 STOMP 메시지를 수락하도록 구성됩니다. stompMinLargeMessageSize 값에 따라 acceptor에서 204800바이트보다 크거나 같은 본문이 있는 STOMP 메시지를 수신하는 경우 브로커는 메시지를 큰 메시지로 저장합니다. 이 속성의 값을 명시적으로 지정하지 않으면 브로커는 기본값 102400(즉, 100KB)을 사용합니다.
STOMP 소비자에게 대규모 메시지를 전달하기 위해 브로커는 메시지를 클라이언트로 보내기 전에 큰 메시지에서 일반 메시지로 메시지를 자동으로 변환합니다. 큰 메시지가 압축되면 브로커는 STOMP 클라이언트로 보내기 전에 압축을 풉니다.
8.4. 대용량 메시지 및 Java 클라이언트 링크 복사링크가 클립보드에 복사되었습니다!
대규모 메시지를 사용하는 클라이언트를 작성하는 Java 개발자에게는 다음 두 가지 옵션을 사용할 수 있습니다.
한 가지 옵션은 InputStream 및 OutputStream 인스턴스를 사용하는 것입니다. 예를 들어 FileInputStream 을 사용하여 물리 디스크의 큰 파일에서 가져온 메시지를 보낼 수 있습니다. 그러면 수신자가 메시지를 로컬 파일 시스템의 위치로 스트리밍하는 데 사용할 수 있습니다.
또 다른 옵션은 JMS>-< sMessage 또는 StreamMessage 를 직접 스트리밍하는 것입니다. 예를 들면 다음과 같습니다.
추가 리소스
AMQ Core Protocol JMS 클라이언트에서 대용량 메시지 사용에 대한 자세한 내용은 다음을 참조하십시오.
AMQ OpenECDHEre JMS 클라이언트에서 대규모 메시지 작업에 대한 자세한 내용은 다음을 참조하십시오.
-
큰 메시지 작업 예를 보려면 AMQ Broker 설치의 <
install_dir> /examples/features/standard/디렉터리의large-message예제를 참조하십시오. 예제 프로그램 실행에 대한 자세한 내용은 AMQ Broker 예제 실행을 참조하십시오.
9장. 손상된 연결 감지 링크 복사링크가 클립보드에 복사되었습니다!
때때로 클라이언트는 예기치 않게 중지되고 리소스를 정리할 기회가 없습니다. 이 경우 리소스를 결함이 있는 상태로 두고 브로커가 메모리 또는 기타 시스템 리소스가 부족해질 수 있습니다. 브로커는 가비지 컬렉션 시 클라이언트 연결이 제대로 종료되지 않았음을 감지합니다. 연결이 닫히고 아래와 유사한 메시지가 로그에 기록됩니다. 로그는 클라이언트 세션이 인스턴스화된 정확한 코드 라인을 캡처합니다. 이를 통해 오류를 식별하고 수정할 수 있습니다.
- 1
- 연결이 인스턴스화된 클라이언트 코드의 행입니다.
9.1. 연결 Time-To-Live 링크 복사링크가 클립보드에 복사되었습니다!
클라이언트와 서버 간의 네트워크 연결이 실패하고 다시 온라인 상태가 될 수 있으므로 클라이언트가 다시 연결할 수 있으므로 AMQ Broker에서 비활성 서버 측 리소스를 정리할 때까지 기다립니다. 이러한 대기 기간을 TTL(Time-to-Live)이라고 합니다. 네트워크 기반 연결의 기본 TTL은 60000 밀리초(1분)입니다. in-VM 연결의 기본 TTL은 -1 이며, 이는 브로커가 브로커 측의 연결을 초과하지 않음을 의미합니다.
브로커에서 Time-To-Live 구성
클라이언트가 자체 연결 TTL을 지정하지 않도록 하려면 브로커 측에 글로벌 값을 설정할 수 있습니다. 이 작업은 브로커 구성에 connection-ttl-override 요소를 지정하여 수행할 수 있습니다.
connection-ttl-check-interval 요소에 의해 결정된 대로 TTL 위반에 대한 연결을 확인하는 논리가 브로커에서 주기적으로 실행됩니다.
절차
아래 예제와 같이
connection-ttl-override구성 요소를 추가하고 Time-to-live에 대한 값을 제공하여 <broker_instance_dir> /etc/broker.xml을 편집합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2. 비동기 연결 실행 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
브로커 측에서 수신된 대부분의 패킷은 remoting 스레드에서 실행됩니다. 이러한 패킷은 단기 실행 작업을 나타내며 성능상의 이유로 리모팅 스레드에서 항상 실행됩니다. 그러나 일부 패킷 유형은 remoting 스레드 대신 스레드 풀을 사용하여 실행되므로 네트워크 대기 시간이 약간 추가됩니다.
스레드 풀을 사용하는 패킷 유형은 아래 나열된 Java 클래스 내에서 구현됩니다. 클래스는 모두 org.apache.actiinvemq.artemis.core.protocol.core.impl.wireformat 패키지에서 찾을 수 있습니다.
- RollbackMessage
- SessionCloseMessage
- SessionCommitMessage
- SessionXACommitMessage
- SessionXAPrepareMessage
- SessionXARollbackMessage
절차
비동기 연결 실행을 비활성화하려면
async-connection-execution-enabled구성 요소를 <broker_instance_dir> /etc/broker.xml에 추가하고 아래 예제와 같이false로 설정합니다. 기본값은true입니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 리소스
- 장애가 발생한 연결을 감지하도록 AMQ Core Protocol JMS 클라이언트를 구성하는 방법을 알아보려면 AMQ Core Protocol JMS 문서에서 중단된 연결 탐지 를 참조하십시오.
- AMQ Core Protocol JMS 클라이언트에서 연결 time-to-live를 구성하는 방법을 알아보려면 AMQ Core Protocol JMS 문서에서 time-to-live 구성 을 참조하십시오.
10장. 중복 메시지 탐지 링크 복사링크가 클립보드에 복사되었습니다!
중복 메시지를 자동으로 탐지하고 필터링하도록 브로커를 구성할 수 있습니다. 즉, 자체 중복 감지 논리를 구현할 필요가 없습니다.
중복 탐지하지 않으면 예기치 않은 연결 오류가 발생하는 경우 클라이언트가 브로커로 보낸 메시지가 수신되었는지 여부를 확인할 수 없습니다. 이 경우 클라이언트는 브로커가 메시지를 수신하지 못했다고 가정하고 다시 보낼 수 있습니다. 그러면 중복 메시지가 생성됩니다.
예를 들어 클라이언트가 브로커에 메시지를 전송한다고 가정합니다. 브로커가 메시지를 수신하고 처리하기 전에 브로커 또는 연결이 실패하면 메시지가 해당 주소에 도달하지 않습니다. 실패로 인해 클라이언트가 브로커로부터 응답을 받지 못합니다. 브로커가 메시지를 수신하고 처리한 후 브로커 또는 연결이 실패하면 메시지가 올바르게 라우팅되지만 클라이언트는 여전히 응답을 수신하지 못합니다.
또한, 트랜잭션을 사용하여 성공을 결정하는 것이 이러한 경우에 반드시 도움이 되는 것은 아닙니다. 트랜잭션 커밋을 처리하는 동안 브로커 또는 연결이 실패하면 클라이언트는 메시지를 성공적으로 전송했는지 여부를 확인할 수 없습니다.
이러한 상황에서 가정된 오류를 수정하기 위해 클라이언트는 최신 메시지를 다시 보냅니다. 결과적으로 시스템에 부정적인 영향을 미치는 중복 메시지가 표시될 수 있습니다. 예를 들어, 주문 보관 시스템에서 브로커를 사용하는 경우 중복 메시지가 구매 발주서가 두 번 처리됨을 의미할 수 있습니다.
다음 절차에서는 이러한 유형의 상황에서 보호하기 위해 중복 메시지 탐지를 구성하는 방법을 보여줍니다.
10.1. 중복 ID 캐시 구성 링크 복사링크가 클립보드에 복사되었습니다!
브로커가 중복 메시지를 감지할 수 있도록 하려면 생산자는 각 메시지를 보낼 때 메시지 속성 _AMQ_DUPL_ID 에 고유한 값을 제공해야 합니다. 브로커는 _AMQ_DUPL_ID 속성의 수신된 값의 캐시를 유지 관리합니다. 브로커가 주소에서 새 메시지를 수신하면 해당 주소에 대한 캐시를 확인하여 이 속성에 대해 동일한 값으로 메시지를 이전에 처리하지 않았는지 확인합니다.
각 주소에는 자체 캐시가 있습니다. 각 캐시는 순환 및 크기가 고정되어 있습니다. 즉, 새 항목이 캐시 공간 요구 사항으로 가장 오래된 항목을 대체합니다.
다음 절차에서는 브로커의 각 주소가 사용하는 ID 캐시를 전역적으로 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. core요소 내에서id-cache-size및persist-id-cache속성을 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow id-cache-size캐시의 개별 항목 수로 지정된 ID 캐시의 최대 크기입니다. 기본값은 20,000 항목입니다. 이 예에서 캐시 크기는 5,000개 항목으로 설정됩니다.
참고캐시의 최대 크기에 도달하면 브로커가 중복 메시지 처리를 시작할 수 있습니다. 예를 들어 캐시 크기를
3000으로 설정했다고 가정합니다. 이전 메시지가_AMQ_DUPL_ID의 새 메시지가 도달하기 전에 3000개 이상의 메시지로 도달한 경우 브로커는 중복을 감지할 수 없습니다. 이로 인해 브로커가 두 메시지를 모두 처리합니다.persist-id-cache-
이 속성의 값이
true로 설정되면 브로커는 수신되는 대로 ID를 디스크에 유지합니다. 기본값은true입니다. 위의 예에서 값을false로 설정하여 지속성을 비활성화합니다.
추가 리소스
- AMQ Core Protocol JMS 클라이언트를 사용하여 중복 ID 메시지 속성을 설정하는 방법을 알아보려면 AMQ Core Protocol JMS 클라이언트 설명서에서 중복 메시지 탐지 사용을 참조하십시오.
10.2. 클러스터 연결에 대한 중복 탐지 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 연결을 구성하여 클러스터 전체에서 이동하는 각 메시지에 대해 중복 ID 헤더를 삽입할 수 있습니다.
사전 요구 사항
- 브로커 클러스터가 이미 구성되어 있어야 합니다. 자세한 내용은 다음을 참조하십시오. 14.2절. “브로커 클러스터 생성”
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 코어요소 내에서 지정된 클러스터 연결에 대해use-duplicate-detection속성을 추가하고 값을 지정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow use-duplicate-detection-
이 속성의 값을
true로 설정하면 클러스터 연결은 처리하는 각 메시지에 대해 중복 ID 헤더를 삽입합니다.
11장. 메시지 가로채기 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker를 사용하면 브로커를 입력하거나 종료하는 패킷을 인터셉트할 수 있으므로 패킷을 감사하거나 메시지를 필터링할 수 있습니다. 인터셉터는 가로채는 패킷을 변경할 수 있으므로 강력하고 잠재적으로 위험할 수 있습니다.
비즈니스 요구 사항에 맞게 인터셉터를 개발할 수 있습니다. 인터셉터는 프로토콜마다 다르며 적절한 인터페이스를 구현해야 합니다.
인터셉터는 부울 값을 반환하는 intercept() 메서드를 구현해야 합니다. 값이 true 이면 메시지 패킷은 계속됩니다. false 인 경우 프로세스가 중단되고 다른 인터셉터가 호출되지 않으며 메시지 패킷은 더 이상 처리되지 않습니다.
11.1. 인터셉터 생성 링크 복사링크가 클립보드에 복사되었습니다!
직접 들어오고 나가는 인터셉터를 만들 수 있습니다. 모든 인터셉터는 프로토콜별로 다르며 각각 서버를 입력하거나 종료하는 모든 패킷에 대해 호출됩니다. 이를 통해 인터셉터를 생성하여 패킷 감사와 같은 비즈니스 요구 사항을 충족할 수 있습니다. 인터셉터는 가로채는 패킷을 변경할 수 있습니다. 이렇게하면 잠재적으로 위험 할 수 있으므로 신중하게 사용하십시오.
인터셉터와 해당 종속 항목을 브로커의 Java 클래스 경로에 배치해야 합니다. 기본적으로 classpath의 일부이므로 < broker_instance_dir> /lib 디렉터리를 사용할 수 있습니다.
절차
다음 예제에서는 전달된 각 패킷의 크기를 확인하는 인터셉터를 생성하는 방법을 보여줍니다. 예제에서는 각 프로토콜에 대해 특정 인터페이스를 구현합니다.
적절한 인터페이스를 구현하고
intercept()메서드를 덮어씁니다.AMQP 프로토콜을 사용하는 경우
org.apache.activemq.artemis.protocol.amqp.broker.AmqpInterceptor인터페이스를 구현합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 코어 프로토콜을 사용하는 경우 인터셉터는
org.apache.artemis.activemq.api.core.Interceptor인터페이스를 구현해야 합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow MQTT 프로토콜을 사용하는 경우
org.apache.activemq.artemis.core.protocol.mqtt.MQTTInterceptor인터페이스를 구현합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow STOMP 프로토콜을 사용하는 경우
org.apache.activemq.artemis.core.protocol.stomp.StompInterceptor인터페이스를 구현합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.2. 인터셉터를 사용하도록 브로커 구성 링크 복사링크가 클립보드에 복사되었습니다!
인터셉터를 생성한 후에는 사용할 브로커를 구성해야 합니다.
사전 요구 사항
브로커가 사용할 수 있도록 인터셉터 클래스를 생성하고 브로커의 Java 클래스 경로에 (및 해당 종속 항목)를 추가해야 합니다. 기본적으로 classpath의 일부이므로 < broker_instance_dir> /lib 디렉터리를 사용할 수 있습니다.
절차
<broker
_instance_dir> /etc/broker.xml에 구성을 추가하여 인터셉터를 사용하도록 브로커를 구성합니다.인터셉터가 수신되는 메시지의 경우
클래스 이름을목록에 추가하십시오.remoting-incoming-interceptorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 인터셉터가 발신 메시지의 용도인 경우
클래스 이름을목록에 추가하십시오.remoting-outgoing-interceptorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 리소스
- AMQ Core Protocol JMS 클라이언트에서 인터셉터를 구성하는 방법을 알아보려면 AMQ Core Protocol JMS 문서의 메시지 인터셉터 사용을 참조하십시오.
12장. 메시지 분할 및 메시지 분리 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에서는 클라이언트 애플리케이션 논리를 변경하지 않고 메시지를 한 주소에서 다른 주소로 투명하게 전환할 수 있는 diverts 라는 오브젝트를 구성할 수 있습니다. 메시지 사본을 지정된 전달 주소로 전달하여 메시지 흐름을 효과적으로 분할하도록 할 수도 있습니다.
12.1. 메시지 일괄 처리 방법 링크 복사링크가 클립보드에 복사되었습니다!
diverts를 사용하면 클라이언트 애플리케이션 논리를 변경하지 않고 한 주소로 라우팅된 메시지를 다른 주소로 투명하게 전환할 수 있습니다. 브로커 서버의 회전 집합을 메시지의 라우팅 테이블 유형으로 고려해 보십시오.
반전은 배타적 일 수 있습니다. 즉, 메시지가 원래 주소로 이동하지 않고 지정된 전달 주소로 전환됩니다.
즉, 메시지는 원래 주소로 계속 이동하는 반면 브로커는 메시지 사본을 지정된 전달 주소로 보냅니다. 따라서 메시지 흐름을 분할하는 데 비독점(non-exclusive diverts)을 사용할 수 있습니다. 예를 들어 주문 큐로 전송된 모든 순서를 별도로 모니터링하려면 메시지 흐름을 분할할 수 있습니다.
단일 주소에 대해 다중 다각형을 구성할 수 있습니다. 주소에 exclusive 및 non-exclusive diverts가 모두 구성된 경우 브로커는 먼저 배타적인 diverts를 처리합니다. 특정 메시지가 이미 배타적인 일괄 처리로 전환된 경우 브로커는 해당 메시지에 대한 비독점(non-exclusive diverts)을 처리하지 않습니다. 이 경우 메시지는 원래 주소로 절대 이동하지 않습니다.
브로커가 메시지를 반전하면 브로커는 새 메시지 ID를 할당하고 메시지 주소를 새 전달 주소로 설정합니다. _AMQ_ORIG_ADDRESS (문자열 유형) 및 _AMQ_ORIG_MESSAGE_ID (long type) 메시지 속성을 통해 원본 메시지 ID 및 주소 값을 검색할 수 있습니다. Core API를 사용하는 경우 Message.HDR_ORIGINAL_ADDRESS 및 Message.HDR_ORIG_MESSAGE_ID 속성을 사용합니다.
메시지를 동일한 브로커 서버의 주소로만 전환할 수 있습니다. 다른 서버의 주소로 전환하려는 경우 공통 솔루션은 먼저 메시지를 로컬 저장소 및 전달 큐로 전환하는 것입니다. 그런 다음 해당 큐에서 사용하는 브릿지를 설정하고 메시지를 다른 브로커의 주소로 전달합니다. 가상 네트워크를 브리지와 결합하면 지리적으로 분산된 브로커 서버 간에 라우팅 연결의 분산 네트워크를 생성할 수 있습니다. 이러한 방식으로 글로벌 메시징 메시를 생성할 수 있습니다.
12.2. 메시지 변환 구성 링크 복사링크가 클립보드에 복사되었습니다!
브로커 인스턴스에서 반전을 구성하려면 broker.xml 구성 파일의 핵심 요소에 divert 요소를 추가합니다.
- divert
-
divert의 이름이 지정된 인스턴스입니다. 각
divert에 고유한 이름이 있는 한broker.xml구성 파일에 여러 개의 일괄 요소를 추가할 수 있습니다. - address
- 메시지를 반전 할 주소
- forwarding-address
- 메시지를 전달할 주소
- filter
- 선택적 메시지 필터입니다. 필터를 구성하면 필터 문자열과 일치하는 메시지만 반전됩니다. 필터를 지정하지 않으면 모든 메시지가 반전에서 일치하는 것으로 간주됩니다.
- routing-type
변환되는 메시지의 라우팅 유형입니다. 다음과 같이 불일치를 구성할 수 있습니다.
-
anycast또는멀티캐스트라우팅 유형을 메시지에 적용 - 스트립 (즉, 제거) 기존 라우팅 유형
- 기존 라우팅 유형을 통과 (즉, 보존)합니다.
-
라우팅 유형의 제어는 메시지에 라우팅 유형이 이미 설정되어 있는 경우 유용하지만 다른 라우팅 유형을 사용하는 주소로 메시지를 전환하려는 경우 유용합니다. 예를 들어 브로커는 anycast 라우팅 유형의 메시지를 MULTICAST 로 설정하는 경우를 제외하고 멀티 캐스트 를 사용하는 큐로 라우팅 할 수 없습니다. divert의 routing-type 매개변수에 유효한 값은 ANYCAST,MULTICAST,PASS, STRIP 입니다. 기본값은 STRIP 입니다.
- exclusive
-
divert is exclusive(속성 설정) 또는 비 배타적(속성 설정)
인지(유효한 속성을false로 설정)를 지정합니다.
다음 하위 섹션에서는 배타적 및 비독점에 대한 구성 예제를 보여줍니다.
12.2.1. 배타적인 일수 예 링크 복사링크가 클립보드에 복사되었습니다!
다음은 배타적인 부팅을 위한 구성의 예입니다. 배타적인 diverts는 원래 구성된 주소에서 새 주소로 일치하는 모든 메시지를 반전합니다. 일치하는 메시지가 원래 주소로 라우팅되지 않습니다.
앞의 예제에서는 priceForwarding이라는 주소 priceUpdates로 전송된 모든 메시지를 다른 로컬 주소인 priceForwarding으로 반전하는 divert를 정의합니다.In the preceding example, you define a divert called prices-divert that diverts sent to the address priceUpdates to another local address, priceForwarding. 메시지 필터 문자열도 지정합니다. 메시지 속성 사무실과 새부 값이 있는 메시지만 반전됩니다. 다른 모든 메시지는 원래 주소로 라우팅됩니다. 마지막으로, divert가 exclusive임을 지정합니다.
12.2.2. 비독점 다이버 예 링크 복사링크가 클립보드에 복사되었습니다!
다음은 제외되지 않은 일체에 대한 구성의 예입니다. 비독점에서 메시지는 원래 주소로 계속 이동하지만 브로커는 메시지 사본도 지정된 전달 주소로 보냅니다. 따라서, 비합리적 회전(non-exclusive divert)은 메시지 흐름을 분할하는 방법입니다.
<divert name="order-divert"> <address>orders</address> <forwarding-address>spyTopic</forwarding-address> <exclusive>false</exclusive> </divert>
<divert name="order-divert">
<address>orders</address>
<forwarding-address>spyTopic</forwarding-address>
<exclusive>false</exclusive>
</divert>
앞의 예제에서는 order-divert 라는 divert를 정의하여 주소 주문으로 전송된 모든 메시지의 사본을 가져와 spyTopic 이라는 로컬 주소로 보냅니다. 또한 반전이 포함되지 않음을 지정합니다.
추가 리소스
전용 및 비독점 일괄 처리를 모두 사용하여 다른 브로커로 메시지를 전달하는 브릿지에 대한 자세한 예제는 진단 예제 (외부)를 참조하십시오.
13장. 메시지 필터링 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker는 SQL 92 표현식 구문의 하위 집합을 기반으로 강력한 필터 언어를 제공합니다. 필터 언어는 JMS 선택기에 사용되는 것과 동일한 구문을 사용하지만 사전 정의된 식별자는 다릅니다. 아래 표에는 AMQ Broker 메시지에 적용되는 식별자가 나열되어 있습니다.
| 식별자 | 속성 |
|---|---|
| AMQPriority |
메시지의 우선 순위입니다. 메시지 우선순위는 |
| AMQExpiration | 메시지의 만료 시간입니다. 값은 long 정수입니다. |
| AMQDurable |
메시지가 안정적이지 않은지 여부입니다. 값은 문자열입니다. 유효한 값은 |
| AMQTimestamp | 메시지를 만들 때의 타임 스탬프입니다. 값은 long 정수입니다. |
| AMQSize |
메시지의 |
코어 필터 식에 사용되는 다른 모든 식별자는 메시지의 속성으로 간주됩니다. JMS 메시지의 선택기 구문에 대한 자세한 내용은 Java EE API 를 참조하십시오.
13.1. 필터를 사용하도록 큐 구성 링크 복사링크가 클립보드에 복사되었습니다!
<broker _instance_dir> /etc/broker.xml 에서 구성한 큐에 필터를 추가할 수 있습니다. 필터 표현식과 일치하는 메시지만 큐를 입력합니다.
절차
필터요소를 원하는큐에추가하고 해당 요소의 값으로 적용할 필터를 포함합니다. 아래 예제에서는NEWS=기술 필터가 대기열에 추가됩니다.기술QueueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.2. JMS Message 속성 필터링 링크 복사링크가 클립보드에 복사되었습니다!
JMS 사양에서는 선택기에서 사용할 때 String 속성을 숫자 유형으로 변환해서는 안 됩니다. 예를 들어 메시지에 age 속성이 String 값 21 로 설정된 경우 선택기 age > 18 이 일치하지 않아야 합니다. 이 제한은 STOMP 클라이언트가 String 속성으로만 메시지를 보낼 수 있기 때문에 제한됩니다.
문자열을 숫자로 변환하도록 필터 구성
String 속성을 숫자 유형으로 변환하려면 convert_string_expressions: 접두사를 필터 값에 추가합니다.
절차
접두사
convert_string을 편집합니다. 아래 예제에서는_expressions:를 원하는> /etc/broker.xml필터에적용하여 <broker_instance_dirage > 18에서convert_string_expressions:age > 18에서필터값을 편집합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.3. 주석의 속성에 따라 AMQP 메시지 필터링 링크 복사링크가 클립보드에 복사되었습니다!
브로커가 만료되거나 전달되지 않은 AMQP 메시지를 구성한 만료 또는 배달 해제된 큐로 이동하기 전에 브로커는 주석과 속성을 메시지에 적용합니다. 클라이언트는 만료 또는 배달 못 한 큐에서 사용할 특정 메시지를 선택하기 위해 속성 또는 주석을 기반으로 필터를 생성할 수 있습니다.
브로커가 적용하는 속성은 내부 속성입니다. 이러한 속성은 정기적으로 사용하기 위해 클라이언트에 노출되지 않지만 필터의 클라이언트에서 지정 할 수 있습니다.
다음은 메시지 속성 및 주석을 기반으로 하는 필터의 예입니다. 속성을 기반으로 필터링하는 것은 가능한 경우 브로커의 처리 횟수를 줄이기 때문에 권장되는 방법입니다.
메시지 속성을 기반으로 필터링
메시지 주석을 기반으로 필터링
주석 기반의 AMQP 메시지를 사용하는 경우 클라이언트는 이전 예에 표시된 대로 메시지 주석에 m. 접두사를 추가해야 합니다.
추가 리소스
- 브로커가 만료되거나 전달되지 않은 AMQP 메시지에 적용하는 주석 및 속성에 대한 자세한 내용은 4.14절. “만료된 또는 전달되지 않은 AMQP 메시지의 주석 및 속성” 을 참조하십시오.
13.4. XML 메시지 필터링 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker는 CloudEvent를 사용하여 XML 본문이 포함된 text 메시지를 필터링하는 방법을 제공합니다. CloudEvent(XML Path Language)는 XML 문서에서 노드를 선택하기 위한 쿼리 언어입니다.
문자 기반 메시지만 지원됩니다. 큰 메시지 필터링은 지원되지 않습니다.
텍스트 기반 메시지를 필터링하려면 XPATH '의 메시지 선택기를 생성해야 합니다{expressi}.
메시지의 예
<root>
<a key='first' num='1'/>
<b key='second' num='2'>b</b>
</root>
<root>
<a key='first' num='1'/>
<b key='second' num='2'>b</b>
</root>
CloudEvent 쿼리를 기반으로 하는 필터
PATH 'root/a'
PATH 'root/a'
CloudEvent는 메시지 본문에 적용되고 XML 구문 분석이 필요하므로 필터링은 일반 필터보다 훨씬 느릴 수 있습니다.
다음 프로토콜을 사용하여 생산자와 소비자 간에 또는 서로 간에 필터가 지원됩니다.
- OpenWire JMS
- 코어(및 코어 JMS)
- STOMP
- AMQP
XML Parser 구성
기본적으로 브로커에서 사용하는 XML Parser는 JDK에서 사용하는 플랫폼 기본 DocumentBuilderFactory 인스턴스입니다.
10.0.0.1 기본 구성에 사용되는 XML 구문 분석기에는 다음 설정이 포함됩니다.
그러나 구현별 문제를 처리하기 위해 artemis.profile 구성 파일에서 시스템 속성을 구성하여 기능을 사용자 지정할 수 있습니다.
org.apache.activemq.documentBuilderFactory.feature:prefix
기능 구성 예
-Dorg.apache.activemq.documentBuilderFactory.feature:http://xml.org/sax/features/external-general-entities=true
-Dorg.apache.activemq.documentBuilderFactory.feature:http://xml.org/sax/features/external-general-entities=true
14장. 브로커 클러스터 설정 링크 복사링크가 클립보드에 복사되었습니다!
클러스터는 함께 그룹화된 여러 브로커 인스턴스로 구성됩니다. 브로커 클러스터는 메시지 처리 부하를 여러 브로커에 분산하여 성능을 향상시킵니다. 또한 브로커 클러스터는 고가용성을 통해 다운타임을 최소화할 수 있습니다.
브로커를 다양한 클러스터 토폴로지에서 함께 연결할 수 있습니다. 클러스터 내에서 각 활성 브로커는 자체 메시지를 관리하고 자체 연결을 처리합니다.
클러스터 전체의 클라이언트 연결의 균형을 유지하고 메시지를 재배포하여 브로커 부족을 방지할 수도 있습니다.
14.1. 브로커 클러스터 이해 링크 복사링크가 클립보드에 복사되었습니다!
브로커 클러스터를 생성하기 전에 몇 가지 중요한 클러스터링 개념을 이해해야 합니다.
14.1.1. 브로커 클러스터의 메시지 로드 밸런싱 방법 링크 복사링크가 클립보드에 복사되었습니다!
브로커가 클러스터를 형성하기 위해 연결되면 AMQ Broker는 브로커 간 메시지 부하를 자동으로 분산합니다. 이렇게 하면 클러스터가 높은 메시지 처리량을 유지할 수 있습니다.
4 개의 브로커로 구성된 대칭 클러스터를 고려하십시오. 각 브로커는 OrderQueue 라는 큐로 구성됩니다. OrderProducer 클라이언트는 Broker1 에 연결하고 메시지를 OrderQueue 에 보냅니다. Broker1 은 라운드 로빈 방식으로 메시지를 다른 브로커로 전달합니다. 각 브로커에 연결된 OrderConsumer 클라이언트는 메시지를 사용합니다.
그림 14.1. 메시지 로드 밸런싱
메시지 부하 분산을 사용하지 않으면 Broker1 으로 전송된 메시지가 Broker1 에 남아 있으며 OrderConsumer1 만 사용할 수 있습니다.
AMQ Broker는 첫 번째 브로커에 첫 번째 메시지 그룹을 배포하고 두 번째 브로커에 두 번째 메시지 그룹에 메시지를 자동으로 로드 밸런싱합니다. 브로커가 시작된 순서는 브로커가 첫 번째, 두 번째 등의 브로커를 결정합니다.
다음을 구성할 수 있습니다.
- 일치하는 큐가 있는 브로커에 메시지를 로드 밸런싱하는 클러스터입니다.
- 활성 소비자와 일치하는 큐가 있는 브로커에 메시지를 로드 밸런싱하는 클러스터입니다.
- 클러스터는 부하 분산이 아니라 소비자가 있는 큐에 대한 소비자가 없는 대기열에서 메시지 재배포를 수행합니다.
- 소비자가 없는 큐의 메시지를 소비자가 있는 큐에 자동으로 재배포하는 주소입니다.
추가 리소스
-
메시지 로드 밸런싱 정책은 각 브로커의 클러스터 연결에서
message-load-balancing속성을 사용하여 구성됩니다. 자세한 내용은 부록 C. 클러스터 연결 구성 CloudEvent의 내용을 참조하십시오. - 메시지 재배포에 대한 자세한 내용은 14.4.2절. “메시지 재배포 구성” 을 참조하십시오.
14.1.2. 브로커 클러스터가 안정성을 개선하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
브로커 클러스터는 고가용성과 페일오버를 가능하게 하여 독립 실행형 브로커보다 더 안정적입니다. 고가용성을 구성하면 브로커가 실패 이벤트가 발생하더라도 클라이언트 애플리케이션이 메시지를 계속 보내고 받을 수 있는지 확인할 수 있습니다.
고가용성을 통해 클러스터의 브로커는 실시간 백업 그룹으로 그룹화됩니다. 실시간 백업 그룹은 클라이언트 요청에 서비스를 제공하는 라이브 브로커와 실패할 경우 라이브 브로커를 교체하기 위해 수동적으로 기다리는 하나 이상의 백업 브로커로 구성됩니다. 오류가 발생하면 백업 브로커는 라이브 백업 그룹의 라이브 브로커를 대체하고 클라이언트가 다시 연결 및 작업을 계속합니다.
14.1.3. 클러스터 제한 사항 링크 복사링크가 클립보드에 복사되었습니다!
다음 제한은 클러스터된 환경에서 AMQ 브로커를 사용하는 경우 적용됩니다.
- 임시 대기열
- 장애 조치 중에 클라이언트에 임시 큐를 사용하는 소비자가 있는 경우 이러한 대기열은 자동으로 다시 생성됩니다. 다시 생성된 큐 이름이 원래 큐 이름과 일치하지 않아 메시지 재배포가 실패하고 기존 임시 큐에 설정된 메시지를 유지할 수 있습니다. 클러스터에서 임시 대기열을 사용하지 않는 것이 좋습니다. 예를 들어 요청/응답 패턴을 사용하는 애플리케이션은 JMSReplyTo 주소에 고정 대기열을 사용해야 합니다.
14.1.4. 노드 ID 이해 링크 복사링크가 클립보드에 복사되었습니다!
브로커 노드 ID 는 브로커 인스턴스의 저널을 처음 생성하고 초기화할 때 프로그래밍 방식으로 생성된 GUID(Globally Unique Identifier)입니다. 노드 ID는 server.lock 파일에 저장됩니다. 노드 ID는 브로커가 독립 실행형 인스턴스인지 클러스터의 일부인지에 관계없이 브로커 인스턴스를 고유하게 식별하는 데 사용됩니다. Live-backup 브로커 쌍은 동일한 저널을 공유하므로 동일한 노드 ID를 공유합니다.
브로커 클러스터의 브로커 인스턴스(노드)는 서로 연결되고 브리지 및 내부 "store-and-forward" 대기열을 생성합니다. 이러한 내부 대기열의 이름은 다른 브로커 인스턴스의 노드 ID를 기반으로 합니다. 브로커 인스턴스는 자체와 일치하는 노드 ID에 대한 클러스터 브로드캐스트도 모니터링합니다. 브로커는 중복 ID를 식별하는 경우 로그에 경고 메시지를 생성합니다.
HA(복제 고가용성) 정책을 사용하는 경우 시작하고 check-for-live-server 가 true 로 설정된 마스터 브로커는 노드 ID를 사용하는 브로커를 true로 설정합니다. 마스터 브로커가 동일한 노드 ID를 사용하여 다른 브로커를 찾으면 시작되지 않거나 HA 구성에 따라 역백을 시작합니다.
노드 ID는 pacemaker 입니다. 즉, 브로커의 재시작이 유지됩니다. 그러나 브로커 인스턴스(일 저널 포함)를 삭제하면 노드 ID도 영구적으로 삭제됩니다.
추가 리소스
- 복제 HA 정책 구성에 대한 자세한 내용은 복제 고가용성 구성을 참조하십시오.
14.1.5. 공통 브로커 클러스터 토폴로지 링크 복사링크가 클립보드에 복사되었습니다!
브로커를 연결하여 대칭 또는 체인 클러스터 토폴로지를 구성할 수 있습니다. 구현하는 토폴로지는 환경 및 메시징 요구 사항에 따라 다릅니다.
대칭 클러스터
대칭 클러스터에서는 모든 브로커가 다른 모든 브로커에 연결됩니다. 즉, 모든 브로커는 다른 브로커에서 하나 이상의 홉 떨어져 있지 않습니다.
그림 14.2. 대칭 클러스터
대칭 클러스터의 각 브로커는 클러스터의 다른 모든 브로커와 해당 큐에서 청취하는 소비자에 존재하는 모든 큐를 알고 있습니다. 따라서 대칭 클러스터에서는 체인 클러스터보다 메시지를 더 최적으로 로드 밸런싱하고 재배포할 수 있습니다.
대칭 클러스터는 체인 클러스터보다 설정하기 쉽지만 네트워크 제한으로 인해 브로커가 직접 연결되지 않는 환경에서 사용하기 어려울 수 있습니다.
체인 클러스터
체인 클러스터에서 클러스터의 각 브로커는 클러스터의 모든 브로커에 직접 연결되지 않습니다. 대신 브로커는 체인의 각 끝에 브로커와 체인을 형성하고 다른 모든 브로커는 체인의 이전 브로커 및 다음 브로커에 연결하기 만합니다.
그림 14.3. 체인 클러스터
체인 클러스터는 대칭 클러스터보다 설정하기가 더 어렵지만 브로커가 별도의 네트워크에 있고 직접 연결할 수 없는 경우 유용할 수 있습니다. 체인 클러스터를 사용하면 중개 브로커는 두 브로커를 간접적으로 연결하여 두 브로커가 직접 연결되지 않은 경우에도 메시지 간에 전달될 수 있습니다.
14.1.6. 브로커 검색 방법 링크 복사링크가 클립보드에 복사되었습니다!
Discovery는 클러스터의 브로커가 연결 세부 정보를 서로 전파하는 메커니즘입니다. AMQ Broker는 동적 검색 및 정적 검색을 모두 지원합니다.
동적 검색
클러스터의 각 브로커는 UDP 멀티 캐스트 또는ECDHE를 통해 다른 멤버에 대한 연결 설정을 브로드캐스트합니다. 이 방법에서는 각 브로커가 다음을 사용합니다.
- 클러스터 연결에 대한 정보를 클러스터의 다른 잠재적 멤버에 푸시하는 브로드캐스트 그룹입니다.
- 클러스터의 다른 브로커에 대한 클러스터 연결 정보를 수신하고 저장하는 검색 그룹입니다.
정적 검색
네트워크에서 UDP 또는ECDHE를 사용할 수 없거나 클러스터의 각 멤버를 수동으로 지정하려면 정적 검색을 사용할 수 있습니다. 이 방법에서는 두 번째 브로커에 연결하고 연결 세부 정보를 전송하여 브로커가 클러스터에 "가져오기"합니다. 그런 다음 두 번째 브로커는 이러한 세부 사항을 클러스터의 다른 브로커에 전파합니다.
14.1.7. 클러스터 크기 조정 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
브로커 클러스터를 생성하기 전에 메시징 처리량, 토폴로지 및 고가용성 요구 사항을 고려하십시오. 이러한 요소는 클러스터에 포함할 브로커 수에 영향을 미칩니다.
클러스터를 생성한 후 브로커를 추가하고 제거하여 크기를 조정할 수 있습니다. 메시지를 손실하지 않고 브로커를 추가하고 제거할 수 있습니다.
메시징 처리량
클러스터에는 필요한 메시징 처리량을 제공하기에 충분한 브로커가 포함되어야 합니다. 클러스터에서 브로커가 많을수록 처리량이 증가합니다. 그러나 대규모 클러스터는 관리하기가 복잡할 수 있습니다.
토폴로지
대칭 클러스터 또는 체인 클러스터를 생성할 수 있습니다. 선택한 토폴로지 유형은 필요한 브로커 수에 영향을 미칩니다.
자세한 내용은 14.1.5절. “공통 브로커 클러스터 토폴로지”의 내용을 참조하십시오.
고가용성
HA(고가용성)가 필요한 경우 클러스터를 생성하기 전에 HA 정책을 선택하는 것이 좋습니다. 각 마스터 브로커에는 하나 이상의 슬레이브 브로커가 있어야 하므로 HA 정책은 클러스터 크기에 영향을 미칩니다.
자세한 내용은 14.3절. “고가용성 구현”의 내용을 참조하십시오.
14.2. 브로커 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에 참여해야 하는 각 브로커에 클러스터 연결을 구성하여 브로커 클러스터를 생성합니다. 클러스터 연결은 브로커가 다른 브로커에 연결하는 방법을 정의합니다.
정적 검색 또는 동적 검색을 사용하는 브로커 클러스터를 생성할 수 있습니다(UDP 멀티 캐스트 또는 iPXE).
사전 요구 사항
브로커 클러스터의 크기를 결정해야 합니다.
자세한 내용은 14.1.7절. “클러스터 크기 조정 고려 사항”의 내용을 참조하십시오.
14.2.1. 정적 검색을 사용하여 브로커 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
브로커의 정적 목록을 지정하여 브로커 클러스터를 생성할 수 있습니다. 네트워크에서 UDP 멀티 캐스트 또는 iPXE를 사용할 수 없는 경우 이 정적 검색 방법을 사용합니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
;core> 요소 내에 다음 커넥터를 추가합니다.- 다른 브로커가이 하나에 연결하는 방법을 정의하는 커넥터
- 이 브로커가 클러스터의 다른 브로커에 연결하는 방법을 정의하는 하나 이상의 커넥터
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 커넥터에 대한 자세한 내용은 2.3절. “커넥터 정보” 을 참조하십시오.
클러스터 연결을 추가하고 정적 검색을 사용하도록 구성합니다.
기본적으로 클러스터 연결은 대칭 토폴로지의 모든 주소에 대한 메시지를 로드 밸런싱합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-connection-
name특성을 사용하여 클러스터 연결의 이름을 지정합니다. connector-ref- 다른 브로커가 이 하나에 연결하는 방법을 정의하는 커넥터입니다.
static-connectors- 이 브로커가 클러스터의 다른 브로커에 초기 연결을 수행하는 데 사용할 수 있는 하나 이상의 커넥터입니다. 이 초기 연결을 수행한 후 브로커는 클러스터의 다른 브로커를 검색합니다. 클러스터가 정적 검색을 사용하는 경우에만 이 속성을 구성해야 합니다.
클러스터 연결에 대한 추가 속성을 구성합니다.
이러한 추가 클러스터 연결 속성에는 가장 일반적인 사용 사례에 적합한 기본값이 있습니다. 따라서 기본 동작을 원하지 않는 경우에만 이러한 속성을 구성해야 합니다. 자세한 내용은 부록 C. 클러스터 연결 구성 CloudEvent의 내용을 참조하십시오.
클러스터 사용자 및 암호를 생성합니다.
AMQ Broker에는 기본 클러스터 인증 정보가 제공되지만 권한이 없는 원격 클라이언트가 이러한 기본 인증 정보를 사용하여 브로커에 연결하지 못하도록 변경해야 합니다.
중요클러스터 암호는 클러스터의 모든 브로커에서 동일해야 합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 추가 브로커마다 이 절차를 반복합니다.
추가 브로커마다 클러스터 구성을 복사할 수 있습니다. 그러나 다른 AMQ Broker 데이터 파일(예: bindings, journal, large messages 디렉터리)은 복사하지 마십시오. 이러한 파일은 클러스터의 노드 중에서 고유해야 합니다. 클러스터가 올바르게 형성되지 않습니다.
추가 리소스
-
정적 검색을 사용하는 브로커 클러스터의 예는
clustered-static-discoveryAMQ Broker 예제 프로그램을 참조하십시오.
14.2.2. UDP 기반 동적 검색을 사용하여 브로커 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
브로커가 UDP 멀티 캐스트를 통해 동적으로 서로 검색하는 브로커 클러스터를 생성할 수 있습니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
core> 요소 내에서 커넥터를 추가합니다.이 커넥터는 다른 브로커가 이 하나에 연결하는 데 사용할 수 있는 연결 정보를 정의합니다. 이 정보는 검색 중에 클러스터의 다른 브로커로 전송됩니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow UDP 브로드캐스트 그룹을 추가합니다.
브로드캐스트 그룹을 사용하면 브로커가 클러스터 연결에 대한 정보를 클러스터의 다른 브로커에 푸시할 수 있습니다. 이 브로드캐스트 그룹은 UDP를 사용하여 연결 설정을 브로드캐스트합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 달리 명시되지 않는 한 다음 매개 변수는 필요합니다.
broadcast-group-
name속성을 사용하여 브로드캐스트 그룹의 고유 이름을 지정합니다. local-bind-address- UDP 소켓이 바인딩되는 주소입니다. 브로커에 네트워크 인터페이스가 여러 개인 경우 브로드캐스트에 사용할 네트워크 인터페이스를 지정해야 합니다. 이 속성을 지정하지 않으면 소켓은 운영 체제에서 선택한 IP 주소에 바인딩됩니다. UDP별 속성입니다.
local-bind-port-
데이터그램 소켓이 바인딩된 포트입니다. 대부분의 경우 익명 포트를 지정하는
-1의 기본값을 사용합니다. 이 매개변수는local-bind-address와 관련하여 사용됩니다. UDP별 속성입니다. group-address-
데이터를 전송할 멀티캐스트 주소입니다.
224.0.0.0-239.255.255.255범위에 있는 클래스 D IP 주소입니다. 주소224.0.0.0은 예약되어 있으며 사용할 수 없습니다. UDP별 속성입니다. group-port- 브로드캐스트에 사용되는 UDP 포트 번호입니다. UDP별 속성입니다.
broadcast-period(선택 사항)- 연속 브로드캐스트 사이의 간격(밀리초)입니다. 기본값은 2000밀리초입니다.
connector-ref- 브로드캐스트해야 하는 이전에 구성된 클러스터 커넥터입니다.
UDP 검색 그룹을 추가합니다.
검색 그룹은 이 브로커가 다른 브로커로부터 커넥터 정보를 수신하는 방법을 정의합니다. 브로커는 커넥터 목록(각 브로커당 하나의 항목)을 유지 관리합니다. 브로커에서 브로드캐스트를 수신하면 해당 항목을 업데이트합니다. 일정 기간 동안 브로커로부터 브로드캐스트를 수신하지 못하면 해당 항목이 제거됩니다.
이 검색 그룹은 UDP를 사용하여 클러스터에서 브로커를 검색합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 달리 명시되지 않는 한 다음 매개 변수는 필요합니다.
discovery-group-
name속성을 사용하여 검색 그룹의 고유 이름을 지정합니다. local-bind-address(선택 사항)- 브로커가 실행 중인 시스템에서 여러 네트워크 인터페이스를 사용하는 경우 검색 그룹에서 수신 대기해야 하는 네트워크 인터페이스를 지정할 수 있습니다. UDP별 속성입니다.
group-address-
수신 대기할 그룹의 멀티 캐스트 주소입니다. 수신 대기하려는 브로드캐스트 그룹의
group-address와 일치해야 합니다. UDP별 속성입니다. group-port-
멀티 캐스트 그룹의 UDP 포트 번호입니다. 수신 대기하려는 브로드캐스트 그룹의
group-port와 일치해야 합니다. UDP별 속성입니다. refresh-timeout(선택 사항)검색 그룹에서 해당 브로커의 커넥터 쌍 항목을 제거하기 전에 특정 브로커에서 마지막 브로드캐스트를 수신한 후 대기하는 시간(밀리초)입니다. 기본값은 10000밀리초(10초)입니다.
이 값을 브로드캐스트 그룹의
broadcast-period보다 훨씬 더 높은 값으로 설정합니다. 그렇지 않으면 브로커가 여전히 브로드캐스트 상태 있음에도 불구하고 목록에서 정기적으로 사라질 수 있습니다 (시간에 약간의 차이로 인해).
클러스터 연결을 생성하고 동적 검색을 사용하도록 구성합니다.
기본적으로 클러스터 연결은 대칭 토폴로지의 모든 주소에 대한 메시지를 로드 밸런싱합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-connection-
name특성을 사용하여 클러스터 연결의 이름을 지정합니다. connector-ref- 다른 브로커가 이 하나에 연결하는 방법을 정의하는 커넥터입니다.
discovery-group-ref- 이 브로커가 클러스터의 다른 멤버를 찾는 데 사용해야 하는 검색 그룹입니다. 클러스터가 동적 검색을 사용하는 경우에만 이 속성을 구성해야 합니다.
클러스터 연결에 대한 추가 속성을 구성합니다.
이러한 추가 클러스터 연결 속성에는 가장 일반적인 사용 사례에 적합한 기본값이 있습니다. 따라서 기본 동작을 원하지 않는 경우에만 이러한 속성을 구성해야 합니다. 자세한 내용은 부록 C. 클러스터 연결 구성 CloudEvent의 내용을 참조하십시오.
클러스터 사용자 및 암호를 생성합니다.
AMQ Broker에는 기본 클러스터 인증 정보가 제공되지만 권한이 없는 원격 클라이언트가 이러한 기본 인증 정보를 사용하여 브로커에 연결하지 못하도록 변경해야 합니다.
중요클러스터 암호는 클러스터의 모든 브로커에서 동일해야 합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 추가 브로커마다 이 절차를 반복합니다.
추가 브로커마다 클러스터 구성을 복사할 수 있습니다. 그러나 다른 AMQ Broker 데이터 파일(예: bindings, journal, large messages 디렉터리)은 복사하지 마십시오. 이러한 파일은 클러스터의 노드 중에서 고유해야 합니다. 클러스터가 올바르게 형성되지 않습니다.
추가 리소스
-
UDP와 함께 동적 검색을 사용하는 브로커 클러스터 구성의 예는
클러스터형 대기열AMQ Broker 예제 프로그램을 참조하십시오.
14.2.3. CloudEvent 기반 동적 검색을 사용하여 브로커 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
이미 사용자 환경에서 CloudEvent를 사용 중인 경우 이를 사용하여 브로커가 서로 동적으로 검색하는 브로커 클러스터를 생성할 수 있습니다.
사전 요구 사항
CloudEvent를 설치하고 구성해야 합니다.
CloudEvent 구성 파일의 예는
clustered-jgroupsAMQ Broker 예제 프로그램을 참조하십시오.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
core> 요소 내에서 커넥터를 추가합니다.이 커넥터는 다른 브로커가 이 하나에 연결하는 데 사용할 수 있는 연결 정보를 정의합니다. 이 정보는 검색 중에 클러스터의 다른 브로커로 전송됩니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <
;core> 요소 내에서 CloudEvent 브로드캐스트 그룹을 추가합니다.브로드캐스트 그룹을 사용하면 브로커가 클러스터 연결에 대한 정보를 클러스터의 다른 브로커에 푸시할 수 있습니다. 이 브로드캐스트 그룹은LoadBalancer를 사용하여 연결 설정을 브로드캐스트합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 달리 명시되지 않는 한 다음 매개 변수는 필요합니다.
broadcast-group-
name속성을 사용하여 브로드캐스트 그룹의 고유 이름을 지정합니다. jgroups-file- CloudEvent 채널을 초기화하는 CloudEvent 구성 파일의 이름입니다. 브로커가 로드할 수 있도록 파일이 Java 리소스 경로에 있어야 합니다.
jgroups-channel- 브로드캐스트를 위해 연결할 CloudEvent 채널의 이름입니다.
broadcast-period(선택 사항)- 연속 브로드캐스트 사이의 간격(밀리초)입니다. 기본값은 2000밀리초입니다.
connector-ref- 브로드캐스트해야 하는 이전에 구성된 클러스터 커넥터입니다.
CloudEvent 검색 그룹을 추가합니다.
검색 그룹은 커넥터 정보를 수신하는 방법을 정의합니다. 브로커는 커넥터 목록(각 브로커당 하나의 항목)을 유지 관리합니다. 브로커에서 브로드캐스트를 수신하면 해당 항목을 업데이트합니다. 일정 기간 동안 브로커로부터 브로드캐스트를 수신하지 못하면 해당 항목이 제거됩니다.
이 검색 그룹은 10.0.0.1을 사용하여 클러스터의 브로커를 검색합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 달리 명시되지 않는 한 다음 매개 변수는 필요합니다.
discovery-group-
name속성을 사용하여 검색 그룹의 고유 이름을 지정합니다. jgroups-file- CloudEvent 채널을 초기화하는 CloudEvent 구성 파일의 이름입니다. 브로커가 로드할 수 있도록 파일이 Java 리소스 경로에 있어야 합니다.
jgroups-channel- 브로드캐스트 수신을 위해 연결할 CloudEvent 채널의 이름입니다.
refresh-timeout(선택 사항)검색 그룹에서 해당 브로커의 커넥터 쌍 항목을 제거하기 전에 특정 브로커에서 마지막 브로드캐스트를 수신한 후 대기하는 시간(밀리초)입니다. 기본값은 10000밀리초(10초)입니다.
이 값을 브로드캐스트 그룹의
broadcast-period보다 훨씬 더 높은 값으로 설정합니다. 그렇지 않으면 브로커가 여전히 브로드캐스트 상태 있음에도 불구하고 목록에서 정기적으로 사라질 수 있습니다 (시간에 약간의 차이로 인해).
클러스터 연결을 생성하고 동적 검색을 사용하도록 구성합니다.
기본적으로 클러스터 연결은 대칭 토폴로지의 모든 주소에 대한 메시지를 로드 밸런싱합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-connection-
name특성을 사용하여 클러스터 연결의 이름을 지정합니다. connector-ref- 다른 브로커가 이 하나에 연결하는 방법을 정의하는 커넥터입니다.
discovery-group-ref- 이 브로커가 클러스터의 다른 멤버를 찾는 데 사용해야 하는 검색 그룹입니다. 클러스터가 동적 검색을 사용하는 경우에만 이 속성을 구성해야 합니다.
클러스터 연결에 대한 추가 속성을 구성합니다.
이러한 추가 클러스터 연결 속성에는 가장 일반적인 사용 사례에 적합한 기본값이 있습니다. 따라서 기본 동작을 원하지 않는 경우에만 이러한 속성을 구성해야 합니다. 자세한 내용은 부록 C. 클러스터 연결 구성 CloudEvent의 내용을 참조하십시오.
클러스터 사용자 및 암호를 생성합니다.
AMQ Broker에는 기본 클러스터 인증 정보가 제공되지만 권한이 없는 원격 클라이언트가 이러한 기본 인증 정보를 사용하여 브로커에 연결하지 못하도록 변경해야 합니다.
중요클러스터 암호는 클러스터의 모든 브로커에서 동일해야 합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 추가 브로커마다 이 절차를 반복합니다.
추가 브로커마다 클러스터 구성을 복사할 수 있습니다. 그러나 다른 AMQ Broker 데이터 파일(예: bindings, journal, large messages 디렉터리)은 복사하지 마십시오. 이러한 파일은 클러스터의 노드 중에서 고유해야 합니다. 클러스터가 올바르게 형성되지 않습니다.
추가 리소스
-
CloudEvent와 함께 동적 검색을 사용하는 브로커 클러스터의 예는
clustered-jgroupsAMQ Broker 예제 프로그램을 참조하십시오.
14.3. 고가용성 구현 링크 복사링크가 클립보드에 복사되었습니다!
HA(고가용성)를 구현하여 안정성을 향상시킬 수 있으며, 브로커 클러스터가 하나 이상의 브로커가 오프라인 상태가 되더라도 브로커 클러스터를 계속 작동할 수 있습니다.
HA 구현에는 몇 가지 단계가 포함됩니다.
- 14.2절. “브로커 클러스터 생성” 에 설명된 대로 HA 구현을 위해 브로커 클러스터를 구성합니다.
- 실시간 백업 그룹이 무엇인지 이해하고 요구 사항을 가장 잘 충족하는 HA 정책을 선택해야 합니다. AMQ Broker에서 HA가 작동하는 방법 이해를 참조하십시오.
적절한 HA 정책을 선택한 경우 클러스터의 각 브로커에 대해 HA 정책을 구성합니다. 다음 내용을 참조하십시오.
- 페일오버를 사용하도록 클라이언트 애플리케이션을 구성합니다.
고가용성을 위해 구성된 브로커 클러스터의 문제를 해결해야 하는 이후의 경우 클러스터에서 브로커를 실행하는 각 JVM(Java Virtual Machine) 인스턴스에 대해 Garbage Collection(GC) 로깅을 활성화하는 것이 좋습니다. JVM에서 GC 로그를 활성화하는 방법을 알아보려면 JVM에서 사용하는 JDK(Java Development Kit) 버전에 대한 공식 문서를 참조하십시오. AMQ Broker에서 지원하는 JVM 버전에 대한 자세한 내용은 Red Hat AMQ 7 지원 구성을 참조하십시오.
14.3.1. 고가용성 이해 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에서는 클러스터의 브로커를 실시간 백업 그룹으로 그룹화하여 HA(고가용성)를 구현합니다. 라이브 백업 그룹에서 라이브 브로커는 백업 브로커에 연결되어 있으며 실패할 경우 라이브 브로커를 대신할 수 있습니다. AMQ Broker는 Live-backup 그룹 내에서 페일오버( HA 정책라고 함)에 대한 몇 가지 다른 전략도 제공합니다.
14.3.1.1. Live-backup 그룹에서 고가용성을 제공하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에서는 클러스터의 브로커를 연결하여 라이브 백업 그룹을 구성하여 HA(고가용성)를 구현합니다. Live-backup 그룹은 장애 조치( failover )를 제공하므로 한 브로커가 실패하면 다른 브로커가 메시지 처리를 대신할 수 있습니다.
실시간 백업 그룹은 하나 이상의 백업 브로커(단일 슬레이브 브로커라고도 함)에 연결된 하나의 라이브 브로커( 마스터 브로커라고도 함)로 구성됩니다. 라이브 브로커는 클라이언트 요청에 서비스를 제공하고 백업 브로커는 패시브 모드로 대기합니다. 라이브 브로커가 실패하면 백업 브로커가 라이브 브로커를 대체하여 클라이언트가 다시 연결하고 작업을 계속할 수 있습니다.
14.3.1.2. 고가용성 정책 링크 복사링크가 클립보드에 복사되었습니다!
HA(고가용성) 정책은 라이브 백업 그룹에서 장애 조치가 발생하는 방법을 정의합니다. AMQ Broker는 다양한 HA 정책을 제공합니다.
- 공유 저장소(권장)
실시간 및 백업 브로커는 메시징 데이터를 공유 파일 시스템의 공통 디렉터리(일반적으로 SAN(Storage Area Network) 또는 NFS(Network File System) 서버)에 저장합니다. JDBC 기반 지속성을 구성한 경우 지정된 데이터베이스에 브로커 데이터를 저장할 수도 있습니다. 공유 저장소를 사용하면 라이브 브로커가 실패하면 백업 브로커는 공유 저장소에서 메시지 데이터를 로드하여 실패한 라이브 브로커를 대신합니다.
대부분의 경우 복제 대신 공유 저장소를 사용해야 합니다. 공유 저장소는 네트워크를 통해 데이터를 복제하지 않기 때문에 일반적으로 복제보다 성능이 향상됩니다. 또한 공유 저장소는 라이브 브로커와 백업이 동시에 유지되는 네트워크 분리 ( "스플릿 브레인"라고도 함) 문제를 방지할 수 있습니다.
- 복제
라이브 및 백업 브로커는 네트워크를 통해 메시징 데이터를 지속적으로 동기화합니다. 라이브 브로커가 실패하면 백업 브로커는 동기화된 데이터를 로드하여 실패한 라이브 브로커에 대해 작업을 수행합니다.
라이브 브로커와 백업 브로커 간의 데이터 동기화를 통해 라이브 브로커가 실패하면 메시징 데이터가 손실되지 않습니다. 실시간 및 백업 브로커가 처음 참여할 때 라이브 브로커는 기존 데이터를 네트워크를 통해 백업 브로커에 복제합니다. 이 초기 단계가 완료되면 라이브 브로커는 라이브 브로커가 받을 때 영구 데이터를 백업 브로커에 복제합니다. 즉, 라이브 브로커가 네트워크를 벗어나면 백업 브로커에 라이브 브로커가 수신한 모든 영구 데이터가 있습니다.
복제는 네트워크를 통해 데이터를 동기화하므로 네트워크 실패로 인해 라이브 브로커와 해당 백업이 동시에 유지되는 네트워크 분리가 발생할 수 있습니다.
- 라이브 전용(HA 제한)
라이브 브로커가 정상적으로 중지되면 메시지 및 트랜잭션 상태를 다른 라이브 브로커에 복사한 다음 종료합니다. 그러면 클라이언트가 다른 브로커에 다시 연결하여 메시지를 계속 전송 및 수신할 수 있습니다.
추가 리소스
- 라이브 백업 그룹의 브로커 간에 공유되는 영구 메시지 데이터에 대한 자세한 내용은 6.1절. “저널에 메시지 데이터 유지” 을 참조하십시오.
14.3.1.3. 복제 정책 제한 링크 복사링크가 클립보드에 복사되었습니다!
복제를 사용하여 고가용성을 제공할 때 실시간 브로커와 백업 브로커 모두 "스플릿 브레인"이라고 하는 동시에 활성화될 수 있는 위험이 존재합니다.
분할 브레인은 라이브 브로커와 백업의 연결이 끊어지면 발생할 수 있습니다. 이 경우 라이브 브로커와 해당 백업이 동시에 활성화될 수 있습니다. 이 상황에서 브로커 간에 메시지 복제가 없기 때문에 각 브로커는 클라이언트를 제공하고 다른 사람을 인식하지 않고 메시지를 처리합니다. 이 경우 각 브로커는 완전히 다른 저널을 가지고 있습니다. 이 상황에서 복구하는 것은 매우 어려울 수 있으며 경우에 따라 불가능합니다.
- 분할 브레인 의 가능성을 제거하려면 공유 저장소 HA 정책을 사용하십시오.
복제 HA 정책을 사용하는 경우 다음 단계를 수행하여 분할 브레인이 발생하는 위험을 줄입니다.
브로커가 ZooKeeper Coordination 서비스를 사용하여 브로커를 조정하려면 최소 3 개의 노드에 ZooKeeper를 배포하십시오. 브로커가 하나의 ZooKeeper 노드에 대한 연결이 끊어지면 3 개 이상의 노드를 사용하면 실시간 백업 브로커 쌍이 복제 중단이 발생할 때 브로커를 조정할 수 있습니다.
클러스터의 다른 사용 가능한 브로커를 사용하여 쿼럼을 제공하는 임베디드 브로커 조정을 사용하려면 3개 이상의 라이브 백업 쌍 을 사용하여 분할 브레인을 발생시킬 가능성을 줄일 수 있습니다. 3개 이상의 라이브 백업 쌍을 사용하면 실시간 백업 브로커 쌍이 복제 중단이 발생할 때 발생하는 쿼럼 투표에서 대부분의 결과를 얻을 수 있습니다.
복제 HA 정책을 사용할 때 몇 가지 추가 고려 사항은 다음과 같습니다.
- 라이브 브로커가 실패하고 백업이 라이브로 전환되면 새 백업 브로커가 라이브에 연결되거나 원래 라이브 브로커에 실패할 때까지 추가 복제가 수행되지 않습니다.
- Live-backup 그룹의 백업 브로커가 실패하면 라이브 브로커는 계속 메시지를 제공합니다. 그러나 다른 브로커가 백업으로 추가되거나 원래 백업 브로커가 다시 시작될 때까지 메시지가 복제되지 않습니다. 이 기간 동안 메시지는 라이브 브로커에만 유지됩니다.
- 브로커가 임베디드 브로커 조정을 사용하고 라이브 백업 쌍에서 두 브로커가 모두 종료된 경우 메시지 손실을 방지하기 위해 최근 활성 브로커를 먼저 다시 시작해야 합니다. 가장 최근의 활성 브로커가 백업 브로커인 경우 먼저 다시 시작할 수 있도록 이 브로커를 마스터 브로커로 수동으로 재구성해야 합니다.
14.3.3. 복제 고가용성 구성 링크 복사링크가 클립보드에 복사되었습니다!
복제 HA(고가용성) 정책을 사용하여 브로커 클러스터에 HA를 구현할 수 있습니다. 복제를 사용하면 라이브 및 백업 브로커 간에 영구 데이터가 동기화됩니다. 라이브 브로커에서 오류가 발생하면 메시지 데이터가 백업 브로커와 동기화되며 실패한 라이브 브로커에 대해 이 데이터가 사용됩니다.
공유 파일 시스템이 없는 경우 공유 저장소에 대한 대안으로 복제를 사용해야 합니다. 그러나 복제를 통해 라이브 브로커와 해당 백업이 동시에 활성화되는 시나리오가 발생할 수 있습니다.
라이브 및 백업 브로커는 네트워크를 통해 메시징 데이터를 동기화해야 하므로 복제는 성능 오버헤드를 추가합니다. 이 동기화 프로세스에서는 저널 작업을 차단하지만 클라이언트를 차단하지는 않습니다. 데이터 동기화를 위해 저널 작업을 차단할 수 있는 최대 시간을 구성할 수 있습니다.
실시간 백업 브로커 쌍 간 복제 연결이 중단되면 브로커는 라이브 브로커가 아직 활성화되어 있는지 또는 사용할 수 없는지와 백업 브로커에 대한 장애 조치가 필요한지 여부를 결정할 방법이 필요합니다. 이러한 조정을 제공하기 위해 다음 조정 방법 중 하나를 사용하도록 브로커를 구성할 수 있습니다.
- Apache ZooKeeper 조정 서비스
- 클러스터의 다른 브로커를 사용하여 쿼럼 선택을 제공하는 임베디드 브로커 조정.
14.3.3.1. 조정 방법 선택 링크 복사링크가 클립보드에 복사되었습니다!
Apache ZooKeeper 조정 서비스를 사용하여 브로커 활성화를 조정하는 것이 좋습니다. 조정 방법을 선택할 때 인프라 요구 사항의 차이점과 두 조정 방법 간의 데이터 일관성 관리를 이해하는 것이 유용합니다.
인프라 요구 사항
- ZooKeeper 조정 서비스를 사용하는 경우 단일 라이브 백업 브로커 쌍으로 작동할 수 있습니다. 그러나 브로커를 최소 3개의 Apache ZooKeeper 노드에 연결하여 브로커가 하나의 노드에 연결이 끊어지면 계속 작동할 수 있도록 해야 합니다. 브로커에 조정 서비스를 제공하기 위해 다른 애플리케이션에서 사용하는 기존 ZooKeeper 노드를 공유할 수 있습니다. Apache ZooKeeper 설정에 대한 자세한 내용은 Apache ZooKeeper 설명서를 참조하십시오.
- 클러스터의 다른 사용 가능한 브로커를 사용하여 쿼럼 선택을 제공하는 임베디드 브로커 조정을 사용하려면 3개 이상의 실시간 백업 브로커 쌍이 있어야 합니다. 3개 이상의 라이브 백업 쌍을 사용하면 실시간 백업 브로커 쌍이 복제 중단이 발생할 때 발생하는 쿼럼 투표에서 대부분의 결과를 얻을 수 있습니다.
데이터 일관성
- Apache ZooKeeper 조정 서비스를 사용하는 경우 ZooKeeper는 각 브로커의 데이터 버전을 추적하므로 복제 목적으로 브로커가 기본 또는 백업 브로커로 구성되어 있는지 여부와 관계없이 최신 저널 데이터가 있는 브로커만 활성화할 수 있습니다. 버전 추적을 사용하면 브로커가 최신 저널을 사용하여 활성화할 수 있고 클라이언트 서비스를 시작할 수 있습니다.
- 임베디드 브로커 조정을 사용하는 경우 각 브로커의 데이터 버전을 추적하는 메커니즘이 없으므로 가장 최신 저널이 있는 브로커만 라이브 브로커가 될 수 있습니다. 따라서 오래된 저널을 가진 브로커가 라이브가되고 클라이언트 서비스를 시작할 수 있으므로 저널에 차이가 발생할 수 있습니다.
14.3.3.2. 복제 중단 후 브로커의 조정 방법 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 복제 연결이 중단된 후 두 조정 방법이 모두 작동하는 방법을 설명합니다.
ZooKeeper 조정 서비스 사용
복제 중단을 관리하기 위해 ZooKeeper 조정 서비스를 사용하는 경우 두 브로커 모두 여러 Apache ZooKeeper 노드에 연결되어 있어야 합니다.
- 언제든지 라이브 브로커가 ZooKeeper 노드의 대부분에 대한 연결이 끊어지면 "스플릿 브레인"이 발생하는 위험을 피하기 위해 종료됩니다.
- 언제든지 백업 브로커가 대부분의 ZooKeeper 노드에 대한 연결이 끊어지면 복제 데이터 수신을 중지하고 백업 브로커 역할을 수행하기 전에 대부분의 ZooKeeper 노드에 연결할 수 있을 때까지 기다립니다. 연결이 ZooKeeper 노드의 대부분으로 복원되면 백업 브로커는 ZooKeeper를 사용하여 데이터를 버리고 복제할 라이브 브로커를 검색해야 하는지 또는 현재 데이터가 있는 라이브 브로커가 될 수 있는지 결정합니다.
zookeeper는 다음 제어 메커니즘을 사용하여 장애 조치 프로세스를 관리합니다.
- 언제든지 단일 라이브 브로커만 소유할 수 있는 공유 임대 잠금입니다.
- 최신 버전의 브로커 데이터를 추적하는 활성화 시퀀스 카운터입니다. 각 브로커는 해당 NodeID와 함께 서버 잠금 파일에 저장된 로컬 카운터에서 저널 데이터 버전을 추적합니다. 라이브 브로커는 ZooKeeper의 조정 활성화 시퀀스 카운터에서 버전을 공유합니다.
라이브 브로커와 백업 브로커 간의 복제 연결이 손실되면 라이브 브로커는 로컬 활성화 시퀀스 카운터 값과 ZooKeeper의 전환 활성화 시퀀스 카운터 값을 1 로 증가시켜 최신 데이터가 있음을 알립니다. 이제 백업 브로커의 데이터는 오래된 것으로 간주되며 복제 연결이 복원되고 최신 데이터가 동기화될 때까지 브로커는 라이브 브로커가 될 수 없습니다.
복제 연결이 손실되면 백업 브로커는 ZooKeeper 잠금이 라이브 브로커가 소유하고 ZooKeeper의 조정 활성화 시퀀스 카운터가 로컬 카운터 값과 일치하는지 확인합니다.
- 라이브 브로커에 의해 잠금을 소유하는 경우 백업 브로커는 복제 연결이 손실되었을 때 ZooKeeper의 활성화 시퀀스 카운터가 라이브 브로커에 의해 업데이트되었음을 감지합니다. 이는 백업 브로커가 장애 조치를 시도하지 않도록 라이브 브로커가 실행 중임을 나타냅니다.
- 잠금이 라이브 브로커에 의해 소유되지 않은 경우 라이브 브로커는 존재하지 않습니다. 백업 브로커의 활성화 시퀀스 카운터 값이 ZooKeeper의 조정된 활성화 시퀀스 카운터 값과 동일하면 백업 브로커에 최신 데이터가 있음을 나타내는 경우 백업 브로커는 장애 조치됩니다.If the value of the activation sequence counter on the backup broker is the same as the commitment activation sequence counter on ZooKeeper, which indicates that the backup broker has up-to-date data, the backup broker fails over.
- 잠금이 라이브 브로커에 의해 소유되지 않지만 백업 브로커의 활성화 순서 카운터 값이 ZooKeeper의 카운터 값보다 작으면 백업 브로커의 데이터가 최신 데이터가 아니며 백업 브로커는 실패할 수 없습니다.
임베디드 브로커 조정 사용
실시간 백업 브로커 쌍에서 포함된 브로커 조정을 사용하여 복제 중단을 조정하는 경우 다음 두 가지 유형의 쿼럼 투표가 시작될 수 있습니다.
| 투표 유형 | 설명 | 이니시에이터 | 필수 구성 | 참가자 | 투표 결과를 기반으로 한 동작 |
|---|---|---|---|---|---|
| 백업 투표 | 백업 브로커가 라이브 브로커에 대한 복제 연결을 손실하면 백업 브로커는 이 투표 결과에 따라 시작할지 여부를 결정합니다. | 백업 브로커 | 없음. 백업 투표는 백업 브로커가 복제 파트너에 대한 연결이 끊어지면 자동으로 수행됩니다. 그러나 이러한 매개변수에 대한 사용자 지정 값을 지정하여 백업 투표의 속성을 제어할 수 있습니다.
| 클러스터의 다른 라이브 브로커 | 백업 브로커는 클러스터의 다른 라이브 브로커에서 대다수(즉, 쿼럼)가 투표하여 복제 파트너를 더 이상 사용할 수 없음을 나타내는 경우 시작됩니다. |
| 라이브 투표 | 라이브 브로커가 복제 파트너에 대한 연결이 끊어지면 라이브 브로커는 이 투표에 따라 계속 실행할지 여부를 결정합니다. | 라이브 브로커 |
라이브 투표는 라이브 브로커가 복제 파트너에 대한 연결을 잃고 | 클러스터의 다른 라이브 브로커 | 클러스터 연결이 여전히 활성 상태임을 나타내는 클러스터 브로커에서 대다수의 투표가 수신 되지 않으면 라이브 브로커가 종료됩니다. |
다음은 브로커 클러스터 구성이 쿼럼 투표 동작에 미치는 영향에 대해 기록해야 하는 몇 가지 중요한 사항입니다.
- 쿼럼 투표가 성공하려면 클러스터 크기가 대부분의 결과를 얻을 수 있어야 합니다. 따라서 클러스터에 라이브 백업 브로커 쌍이 3개 이상 있어야 합니다.
- 클러스터에 추가하는 라이브 백업 브로커 쌍이 많을수록 클러스터의 전체 내결함성이 높아집니다. 예를 들어, 세 개의 Live-backup 쌍이 있다고 가정합니다. 전체 라이브 백업 쌍이 손실되면 나머지 두 개의 live-backup 쌍은 후속 쿼럼 투표에서 대부분의 결과를 얻을 수 없습니다. 이 경우 클러스터에서 추가 복제 중단으로 인해 라이브 브로커가 종료되고 백업 브로커가 시작되지 않을 수 있습니다. 예를 들어 5개의 브로커 쌍을 사용하여 클러스터를 구성하면 클러스터에 오류가 두 개 이상 발생할 수 있지만 쿼럼 투표에서 대다수의 결과를 보장할 수 있습니다.
- 클러스터에서 실시간 백업 브로커 쌍의 수를 의도적으로 줄이면 이전에 설정된 대부분의 투표 임계값이 자동으로 줄어들지 않습니다. 이 기간 동안 손실된 복제 연결에 의해 트리거되는 쿼럼 투표는 성공할 수 없으므로 클러스터의 스플릿 브레인에 더 취약해집니다. 클러스터가 쿼럼 투표에 대한 대부분의 임계값을 다시 계산하도록 하려면 먼저 클러스터에서 제거 중인 실시간 백업 쌍을 종료합니다. 그런 다음 클러스터에서 나머지 live-backup 쌍을 다시 시작합니다. 나머지 브로커를 모두 다시 시작하면 클러스터에서 쿼럼 투표 임계값을 다시 계산합니다.
14.3.3.3. ZooKeeper 조정 서비스를 사용하여 브로커 클러스터의 복제 구성 링크 복사링크가 클립보드에 복사되었습니다!
Apache ZooKeeper 조정 서비스를 사용하는 라이브 백업 쌍에서 두 브로커 모두에 대해 동일한 복제 구성을 지정해야 합니다. 그런 다음 브로커는 주 브로커이며 백업 브로커인 브로커를 결정합니다.
사전 요구 사항
- 한 노드에 대한 연결이 끊어지면 브로커가 계속 작동할 수 있도록 최소 3개의 Apache ZooKeeper 노드를 사용할 수 있습니다.
- 브로커 머신에는 유사한 하드웨어 사양이 있습니다. 즉, 시스템이 라이브 브로커를 실행하는 기본 설정이 없으며 언제든지 백업 브로커를 실행합니다.
- zookeeper는 일시 중지 시간이 ZooKeeper 서버 눈금 시간보다 훨씬 적은 수 있도록 충분한 리소스가 있어야 합니다. 브로커의 예상 로드에 따라 브로커와 ZooKeeper 노드가 동일한 노드를 공유할 수 있는지 신중하게 고려하십시오. 자세한 내용은 https://zookeeper.apache.org/ 에서 참조하십시오.
절차
-
live-backup 쌍의 두 브로커 모두 <
broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 쌍의 두 브로커에 대해 동일한 복제 구성을 구성합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow primary- 복제 유형을 primary로 구성하여 브로커 조정 결과에 따라 브로커가 주 브로커가 될 수 있음을 나타냅니다.
조정-id-
live-backup 쌍에서 두 브로커의 공통 문자열 값을 지정합니다. 동일한
Coordination-id문자열이 있는 브로커는 활성화를 함께 조정합니다. 조정 프로세스 중에 두 브로커는Coordination-id문자열을 Id 노드로 사용하고 ZooKeeper에서 잠금을 취득하려고 합니다. 잠금을 확보하고 최신 데이터가 있는 첫 번째 브로커는 라이브 브로커로 시작하며 다른 브로커는 백업이 됩니다. 속성ZooKeeper 노드에 대한 연결 세부 정보를 제공하기 위해 키-값 쌍 집합을 지정할 수 있는
속성요소를 지정합니다.Expand 키 현재의 connect-string
IP 주소 및 ZooKeeper 노드의 포트 번호를 쉼표로 구분한 목록을 지정합니다. 예를 들어
값="192.168.1.10:6666,192.168.2.10:6667,192.168.3.10:6668"입니다.session-ms
대부분의 ZooKeeper 노드에 대한 연결이 손실된 후 브로커가 종료되기 전에 브로커가 대기하는 시간입니다. 기본값은
18000ms입니다. 유효한 값은 ZooKeeper 서버 눈금 시간 2 회에서 20 배 사이입니다.참고ZooKeeper 하트비트가 안정적으로 작동할 수 있도록 가비지 컬렉션의 ZooKeeper 일시 중지 시간은
session-ms속성 값의 0.33 미만이어야 합니다. 일시 중지 시간이 이 제한보다 적다는 것을 보장할 수 없는 경우 각 브로커의session-ms속성 값을 늘리고 느린 장애 조치를 허용합니다.중요브로커 복제 파트너는 2초마다 "ping" 패킷을 자동으로 교환하여 파트너 브로커를 사용할 수 있는지 확인합니다. 백업 브로커가 라이브 브로커로부터 응답을 받지 못하면 브로커의 연결 시간-라이브(ttl)가 만료될 때까지 백업에서 응답을 기다립니다. 기본 connection-ttl은
60000ms이므로 백업 브로커가 60초 후에 장애 조치를 시도합니다. 더 빠른 장애 조치를 허용하려면 connection-ttl 값을session-ms속성 값과 유사한 값으로 설정하는 것이 좋습니다. 새 connection-ttl을 설정하려면connection-ttl-override속성을 구성합니다.네임스페이스 (선택 사항)
브로커가 ZooKeeper 노드를 다른 애플리케이션과 공유하는 경우, 브로커에 조정 서비스를 제공하는 파일을 저장하기 위해 ZooKeeper 네임스페이스를 만들 수 있습니다. 두 브로커 모두에 대해 라이브 백업 쌍에서 동일한 네임스페이스를 지정해야 합니다.
브로커에 대한 추가 HA 속성을 구성합니다.
이러한 추가 HA 속성에는 대부분의 일반적인 사용 사례에 적합한 기본값이 있습니다. 따라서 기본 동작을 원하지 않는 경우에만 이러한 속성을 구성해야 합니다. 자세한 내용은 부록 F. 추가 복제 고가용성 구성 ScanSetting의 내용을 참조하십시오.
- 1에서 3단계를 반복하여 클러스터의 각 추가 라이브 백업 브로커 쌍을 구성합니다.
추가 리소스
- HA에 복제를 사용하는 브로커 클러스터의 예는 HA 예제 프로그램을 참조하십시오.
- 노드 ID에 대한 자세한 내용은 노드 ID 이해를 참조하십시오.
14.3.3.4. 임베디드 브로커 조정을 사용하여 복제 고가용성을 위한 브로커 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
임베디드 브로커 조정을 사용하여 복제하려면 "스플릿 브레인"의 위험을 줄이기 위해 적어도 3 개의 라이브 백업 쌍이 필요합니다.
다음 절차에서는 6-broker 클러스터에 대한 복제 HA(고가용성)를 구성하는 방법을 설명합니다. 이 토폴로지에서 6개의 브로커는 세 개의 라이브 백업 쌍으로 그룹화됩니다. 세 개의 라이브 브로커는 각각 전용 백업 브로커와 연결됩니다.
사전 요구 사항
최소 6개의 브로커가 있는 브로커 클러스터가 있어야 합니다.
6개의 브로커는 세 개의 라이브 백업 쌍으로 구성됩니다. 클러스터에 브로커를 추가하는 방법에 대한 자세한 내용은 14장. 브로커 클러스터 설정 을 참조하십시오.
절차
클러스터의 브로커를 라이브 백업 그룹으로 그룹화합니다.
대부분의 경우 실시간 백업 그룹은 라이브 브로커와 백업 브로커의 두 가지 브로커로 구성되어야 합니다. 클러스터에 6개의 브로커가 있는 경우 3개의 라이브 백업 그룹이 필요합니다.
하나의 라이브 브로커와 하나의 백업 브로커로 구성된 첫 번째 라이브 백업 그룹을 생성합니다.
-
라이브 브로커의 <
broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. HA 정책에 복제를 사용하도록 라이브 브로커를 구성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow check-for-live-server라이브 브로커가 실패하면 이 속성은 클라이언트가 다시 시작할 때 클라이언트가 다시 실패해야 하는지 여부를 제어합니다.
이 속성을
true로 설정하면 이전 장애 조치 후 라이브 브로커가 다시 시작되면 동일한 노드 ID가 있는 클러스터에서 다른 브로커를 검색합니다. 라이브 브로커가 동일한 노드 ID가 있는 다른 브로커를 발견하면 라이브 브로커가 실패했을 때 백업 브로커가 성공적으로 시작되었음을 나타냅니다. 이 경우 라이브 브로커는 데이터를 백업 브로커와 동기화합니다. 그런 다음 라이브 브로커는 백업 브로커를 종료하도록 요청합니다. 백업 브로커가 장애백에 대해 구성된 경우 아래와 같이 종료됩니다. 그런 다음 라이브 브로커는 활성 역할을 다시 시작하고 클라이언트가 다시 연결합니다.주의라이브 브로커에서
check-for-live-server를true로 설정하지 않으면 이전 페일오버 후 라이브 브로커를 다시 시작할 때 중복 메시징 처리가 발생할 수 있습니다. 특히 이 속성이false로 설정된 라이브 브로커를 다시 시작하면 라이브 브로커는 데이터를 백업 브로커와 동기화하지 않습니다. 이 경우 라이브 브로커는 백업 브로커가 이미 처리한 것과 동일한 메시지를 처리하여 중복을 유발할 수 있습니다.group-name- 이 Live-backup 그룹의 이름입니다(선택 사항). 라이브 백업 그룹을 만들려면 동일한 그룹 이름으로 실시간 및 백업 브로커를 구성해야 합니다. 그룹 이름을 지정하지 않으면 백업 브로커는 라이브 브로커와 복제할 수 있습니다.
vote-on-replication-failure이 속성은 활성 브로커가 중단된 복제 연결 시 실시간 투표 라는 쿼럼을 시작할지 여부를 제어합니다.
실시간 투표는 라이브 브로커가 복제 연결 중단의 원인인지 여부를 결정하는 방법입니다. 투표 결과에 따라 라이브 브로커는 계속 실행 중이거나 종료됩니다.
중요쿼럼 투표가 성공하려면 클러스터 크기가 대부분의 결과를 얻을 수 있어야 합니다. 따라서 복제 HA 정책을 사용하면 클러스터에 3개 이상의 실시간 백업 브로커 쌍이 있어야 합니다.
클러스터에서 구성한 브로커 쌍이 많을수록 클러스터의 전체 내결함성이 증가할 수 있습니다. 예를 들어, 세 개의 라이브 백업 브로커 쌍이 있다고 가정합니다. 전체 라이브 백업 쌍에 대한 연결이 끊어지면 나머지 두 개의 live-backup 쌍은 더 이상 쿼럼 투표에서 대부분의 결과를 얻을 수 없습니다. 이는 이후의 복제 중단으로 인해 라이브 브로커가 종료되고 백업 브로커가 시작되지 않을 수 있음을 의미합니다. 예를 들어 5개의 브로커 쌍을 사용하여 클러스터를 구성하면 클러스터에 오류가 두 개 이상 발생할 수 있지만 쿼럼 투표에서 대다수의 결과를 보장할 수 있습니다.
라이브 브로커의 추가 HA 속성을 구성합니다.
이러한 추가 HA 속성에는 대부분의 일반적인 사용 사례에 적합한 기본값이 있습니다. 따라서 기본 동작을 원하지 않는 경우에만 이러한 속성을 구성해야 합니다. 자세한 내용은 부록 F. 추가 복제 고가용성 구성 ScanSetting의 내용을 참조하십시오.
-
백업 브로커의 <
broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. HA 정책에 복제를 사용하도록 백업 브로커를 구성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow allow-failback장애 조치가 발생하고 라이브 브로커에 대해 백업 브로커가 가져왔으면 이 속성은 다시 시작하고 클러스터에 다시 연결할 때 백업 브로커가 원래 라이브 브로커로 돌아가야 하는지 여부를 제어합니다.
참고failback은 실시간 백업 쌍(단일 백업 브로커와 페어링된 라이브 브로커)을 위한 것입니다. 라이브 브로커가 여러 백업으로 구성된 경우 failback이 발생하지 않습니다. 대신 장애 조치 이벤트가 발생하면 백업 브로커가 활성화되고 다음 백업이 백업이 됩니다. 원래 라이브 브로커가 다시 온라인 상태가 되면 현재 살고 있는 브로커에 이미 백업이 있기 때문에 역백을 시작할 수 없습니다.
group-name- 이 Live-backup 그룹의 이름입니다(선택 사항). 라이브 백업 그룹을 만들려면 동일한 그룹 이름으로 실시간 및 백업 브로커를 구성해야 합니다. 그룹 이름을 지정하지 않으면 백업 브로커는 라이브 브로커와 복제할 수 있습니다.
vote-on-replication-failure이 속성은 활성 브로커가 중단된 복제 연결 시 실시간 투표 라는 쿼럼을 시작할지 여부를 제어합니다. 활성 상태가 된 백업 브로커는 라이브 브로커로 간주되며 라이브 투표가 시작될 수 있습니다.
실시간 투표는 라이브 브로커가 복제 연결 중단의 원인인지 여부를 결정하는 방법입니다. 투표 결과에 따라 라이브 브로커는 계속 실행 중이거나 종료됩니다.
(선택 사항) 백업 브로커가 시작하는 쿼럼 투표의 속성을 구성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow vote-retries- 이 속성은 백업 브로커를 시작할 수 있는 대부분의 결과를 받기 위해 백업 브로커가 쿼럼을 다시 시도하는 횟수를 제어합니다.
vote-retry-wait- 이 속성은 쿼럼 투표의 각 재시도 사이에 백업 브로커가 대기하는 시간(밀리초)을 제어합니다.
백업 브로커의 추가 HA 속성을 구성합니다.
이러한 추가 HA 속성에는 대부분의 일반적인 사용 사례에 적합한 기본값이 있습니다. 따라서 기본 동작을 원하지 않는 경우에만 이러한 속성을 구성해야 합니다. 자세한 내용은 부록 F. 추가 복제 고가용성 구성 ScanSetting의 내용을 참조하십시오.
-
라이브 브로커의 <
클러스터의 추가 라이브 백업 그룹에 대해 2단계를 반복합니다.
클러스터에 6개의 브로커가 있는 경우 나머지 각 Live-backup 그룹에 대해 이 절차를 두 번 더 반복합니다.
추가 리소스
- HA에 복제를 사용하는 브로커 클러스터의 예는 HA 예제 프로그램을 참조하십시오.
- 노드 ID에 대한 자세한 내용은 노드 ID 이해를 참조하십시오.
14.3.4. 라이브 전용으로 제한된 고가용성 구성 링크 복사링크가 클립보드에 복사되었습니다!
실시간 전용 HA 정책을 사용하면 메시지를 손실하지 않고 클러스터의 브로커를 종료할 수 있습니다. 라이브 전용을 사용하면 라이브 브로커가 정상적으로 중지되면 해당 메시지 및 트랜잭션 상태를 다른 라이브 브로커에 복사한 다음 종료합니다. 그러면 클라이언트가 다른 브로커에 다시 연결하여 메시지를 계속 전송 및 수신할 수 있습니다.
라이브 전용 HA 정책은 브로커가 정상적으로 중지된 경우에만 사례를 처리합니다. 예기치 않은 브로커 오류를 처리하지 않습니다.
라이브 전용 HA는 메시지 손실을 방지하지만 메시지 순서를 보존하지 않을 수 있습니다. 실시간 전용 HA로 구성된 브로커가 중지되면 다른 브로커의 대기열 끝에 메시지가 추가됩니다.
브로커가 축소를 준비하면 클라이언트가 메시지를 처리할 준비가 되었는지 알려주기 전에 메시지를 전달합니다. 그러나 클라이언트는 초기 브로커의 축소를 완료한 후에만 새 브로커에 다시 연결해야 합니다. 이렇게 하면 클라이언트가 다시 연결할 때 대기열 또는 트랜잭션과 같은 모든 상태를 다른 브로커에서 사용할 수 있습니다. 일반 재연결 설정은 클라이언트가 다시 연결할 때 적용되므로 규모를 축소하는 데 필요한 시간을 처리할 수 있도록 충분히 높은 설정을 설정해야 합니다.
다음 절차에서는 축소하도록 클러스터의 각 브로커를 구성하는 방법을 설명합니다. 이 절차를 완료한 후 브로커가 정상적으로 중지될 때마다 해당 메시지와 트랜잭션 상태를 클러스터의 다른 브로커로 복사합니다.
절차
-
첫 번째 브로커의 <
broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 라이브 전용 HA 정책을 사용하도록 브로커를 구성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 브로커 클러스터를 축소하는 방법을 구성합니다.
이 브로커를 축소해야 하는 브로커 또는 브로커 그룹을 지정합니다.
Expand 를…으로 축소하려면 다음을 수행합니다. 이 작업을 수행합니다. 클러스터의 특정 브로커
축소할 브로커의 커넥터를 지정합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터의 모든 브로커
브로커 클러스터의 검색 그룹을 지정합니다.
<live-only> <scale-down> <discovery-group-ref discovery-group-name="my-discovery-group"/> </scale-down> </live-only><live-only> <scale-down> <discovery-group-ref discovery-group-name="my-discovery-group"/> </scale-down> </live-only>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 특정 브로커 그룹의 브로커
브로커 그룹을 지정합니다.
<live-only> <scale-down> <group-name>my-group-name</group-name> </scale-down> </live-only><live-only> <scale-down> <group-name>my-group-name</group-name> </scale-down> </live-only>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 클러스터의 나머지 각 브로커에 대해 이 절차를 반복합니다.
추가 리소스
- 라이브 전용을 사용하여 클러스터를 축소하는 브로커 클러스터의 예는 스케일 다운 예제 프로그램을 참조하십시오.
14.3.5. 일관된 백업으로 고가용성 구성 링크 복사링크가 클립보드에 복사되었습니다!
실시간 백업 그룹을 구성하는 대신 다른 라이브 브로커와 동일한 JVM에 백업 브로커를 공동 배치할 수 있습니다. 이 구성에서 각 라이브 브로커는 JVM에서 백업 브로커를 생성하고 시작하도록 다른 라이브 브로커를 요청하도록 구성됩니다.
그림 14.4. 공동 배치 라이브 및 백업 브로커
공유 저장소 또는 복제와 함께 HA(고가용성) 정책으로 colocation을 사용할 수 있습니다. 새 백업 브로커는 이를 생성하는 라이브 브로커의 구성을 상속합니다. 백업 이름은 co places_backup_n 으로 설정됩니다. 여기서 n 은 라이브 브로커가 생성한 백업 수입니다.
또한 백업 브로커는 해당 커넥터 및 어셉터를 생성하는 라이브 브로커의 구성을 상속합니다. 기본적으로 100의 포트 오프셋은 각각에 적용됩니다. 예를 들어 라이브 브로커에 포트 61616에 대한 어셉터가 있으면 생성된 첫 번째 백업 브로커가 포트 61716을 사용하는 경우 두 번째 백업은 61816을 사용하는 등의 작업을 수행합니다.
저널, 대용량 메시지 및 페이징의 디렉터리는 선택한 HA 정책에 따라 설정됩니다. 공유 저장소를 선택하는 경우 요청 브로커는 대상 브로커에 사용할 디렉터리를 알립니다. 복제를 선택하면 디렉터리가 생성 브로커에서 상속되고 새 백업의 이름이 추가됩니다.
이 절차에서는 클러스터의 각 브로커가 공유 저장소 HA를 사용하고 클러스터의 다른 브로커와 함께 생성 및 배치되도록 백업을 요청합니다.
절차
-
첫 번째 브로커의 <
broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. HA 정책 및 공동 할당을 사용하도록 브로커를 구성합니다.
이 예제에서 브로커는 공유 저장소 HA 및 공동 배치로 구성됩니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow request-backup-
이 속성을
true로 설정하면 이 브로커는 클러스터의 다른 라이브 브로커에 의해 백업 브로커를 생성할 것을 요청합니다. max-backups-
이 브로커가 생성할 수 있는 백업 브로커 수입니다. 이 속성을
0으로 설정하면 이 브로커는 클러스터의 다른 브로커의 백업 요청을 수락하지 않습니다. backup-request-retries-
이 브로커가 백업 브로커를 생성하도록 요청해야 하는 횟수입니다. 기본값은
-1이며 이는 무제한 시도를 의미합니다. backup-request-retry-interval-
브로커가 백업 브로커를 생성하는 요청을 재시도하기 전에 대기해야 하는 시간(밀리초)입니다. 기본값은
5000초 또는 5초입니다. backup-port-offset-
새 백업 브로커에 대한 어셉터 및 커넥터에 사용할 포트 오프셋입니다. 이 브로커가 클러스터의 다른 브로커에 대한 백업을 생성하는 요청을 수신하면 이 양에 따라 포트 오프셋으로 백업 브로커를 생성합니다. 기본값은
100입니다. 제외(선택 사항)-
백업 포트 오프셋에서 커넥터를 제외합니다. 백업 포트 오프셋에서 제외해야 하는 외부 브로커를 위한 커넥터를 구성한 경우 각 커넥터에 대해 <
connector-ref>를 추가합니다. master- 이 브로커의 공유 저장소 또는 복제 장애 조치 구성입니다.
slave- 이 브로커의 백업에 대한 공유 저장소 또는 복제 장애 조치 구성입니다.
- 클러스터의 나머지 각 브로커에 대해 이 절차를 반복합니다.
추가 리소스
- 공동 배치 백업을 사용하는 브로커 클러스터의 예는 HA 예제 프로그램을 참조하십시오.
14.3.6. 장애 조치(failover)를 수행하도록 클라이언트 구성 링크 복사링크가 클립보드에 복사되었습니다!
브로커 클러스터에서 고가용성을 구성한 후 페일오버하도록 클라이언트를 구성합니다. 클라이언트 장애 조치를 사용하면 브로커가 실패하면 연결된 클라이언트가 최소 다운 타임으로 클러스터의 다른 브로커에 다시 연결할 수 있습니다.
일시적인 네트워크 문제가 발생하는 경우 AMQ Broker는 동일한 브로커에 연결을 자동으로 다시 연결합니다. 이는 클라이언트가 동일한 브로커에 다시 연결하는 경우를 제외하고 장애 조치와 유사합니다.
두 가지 유형의 클라이언트 장애 조치를 구성할 수 있습니다.
- 자동 클라이언트 페일오버
- 클라이언트에서 처음 연결할 때 브로커 클러스터에 대한 정보를 받습니다. 연결된 브로커가 실패하면 클라이언트는 브로커의 백업에 자동으로 다시 연결하고 백업 브로커는 장애 조치 전에 각 연결에 존재하는 모든 세션과 소비자를 다시 만듭니다.
- 애플리케이션 수준 클라이언트 장애 조치
- 자동 클라이언트 장애 조치(Failover) 대신 실패 처리기에서 자체 사용자 지정 다시 연결 논리를 사용하여 클라이언트 애플리케이션을 코딩할 수 있습니다.As an alternative to automatic client failover, you can instead code your client applications with your own custom reconnection logic in a failure handler.
절차
AMQ Core Protocol JMS를 사용하여 자동 또는 애플리케이션 수준 페일오버로 클라이언트 애플리케이션을 구성합니다.
자세한 내용은 AMQ Core Protocol JMS Client 사용을 참조하십시오.
14.4. 메시지 재배포 활성화 링크 복사링크가 클립보드에 복사되었습니다!
브로커 클러스터가 ON_DEMAND 또는 OFF_WITH_REDISTRIBUTION 으로 설정된 메시지 로드 밸런싱 을 사용하여 구성된 경우 메시지를 사용하는 소비자가 없는 큐에서 메시지가 "최고"되지 않도록 메시지 재배포 를 구성할 수 있습니다.
이 섹션에는 다음에 대한 정보가 포함되어 있습니다.
14.4.1. 메시지 재배포 이해 링크 복사링크가 클립보드에 복사되었습니다!
브로커 클러스터는 로드 밸런싱을 사용하여 클러스터에 메시지 부하를 분산합니다. 클러스터 연결에서 로드 밸런싱을 구성할 때 다음 message-load-balancing 설정을 사용하여 재배포를 활성화할 수 있습니다.
-
ON_DEMAND- 부하 분산을 활성화하고 재배포를 허용합니다. -
OFF_WITH_REDISTRIBUTION- 부하 분산을 비활성화하지만 재배포 가능
두 경우 모두 브로커는 일치하는 소비자가있는 다른 브로커에게만 메시지를 전달합니다. 이 동작을 사용하면 메시지를 사용할 소비자가 없는 큐로 메시지가 이동되지 않습니다. 그러나 메시지가 브로커로 전달된 후 큐에 연결된 사용자가 닫히면 해당 메시지는 큐에서 "최고"되지 않습니다. 이 문제를 래비브레이팅(Vla vation )이라고 합니다.
메시지 재배포는 소비자가 일치하는 클러스터의 브로커에 대한 소비자가 없는 대기열에서 메시지를 자동으로 다시 배포하지 못하도록 합니다.
OFF_WITH_REDISTRIBUTION 을 사용하면 브로커는 활성 로컬 소비자가 없는 경우 일치하는 소비자를 가진 다른 브로커만 전달하여 소비자가 사용할 수 없을 때 대안을 제공하는 동시에 브로커에 우선 순위를 지정할 수 있습니다.
메시지 재배포는 필터의 사용을 지원합니다. 즉, 사용 가능한 로컬 소비자의 선택기와 일치하지 않을 때 메시지가 재배포됩니다.
추가 리소스
- 클러스터 로드 밸런싱에 대한 자세한 내용은 14.1.1절. “브로커 클러스터의 메시지 로드 밸런싱 방법” 을 참조하십시오.
14.4.2. 메시지 재배포 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 로드 밸런싱을 사용하여 메시지 재배포를 구성하는 방법을 설명합니다. 로드 밸런싱 없이 메시지를 재배포하려면 < message-load-balancing >을 OFF_WITH_REDISTRIBUTION 으로 설정합니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
cluster-connection> 요소에서 <message-load-balancing>이ON_DEMAND로 설정되어 있는지 확인합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow <
;address-settings> 요소 내에서 큐 또는 큐 집합에 대한 재분배 지연을 설정합니다.이 예에서는
my.queue에 밸런싱된 메시지가 마지막 소비자가 종료된 후 5000밀리초 후에 재배포됩니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow address-setting-
메시지를 재배포할 대기열의 이름으로
match속성을 설정합니다. 브로커 와일드카드 구문을 사용하여 큐 범위를 지정할 수 있습니다. 자세한 내용은 4.2절. “주소 집합에 주소 설정 적용”의 내용을 참조하십시오. redistribution-delay-
브로커가 클러스터의 다른 브로커에 메시지를 재배포하기 전에 이 큐의 최종 소비자가 종료한 후 대기해야 하는 시간(밀리초)입니다. 이 값을
0으로 설정하면 메시지가 즉시 재배포됩니다. 그러나 일반적으로 redistributing 전에 지연을 설정해야 합니다. 소비자가 종료되지만 다른 하나는 동일한 큐에서 신속하게 생성되는 것이 일반적입니다.
- 클러스터의 추가 브로커 각각에 대해 이 절차를 반복합니다.
추가 리소스
-
메시지를 재배포하는 브로커 클러스터 구성의 예는
queue-message-redistributionAMQ Broker 예제 프로그램을 참조하십시오.
14.5. 클러스터형 메시지 그룹화 구성 링크 복사링크가 클립보드에 복사되었습니다!
메시지 그룹을 사용하면 클라이언트가 특정 유형의 메시지 그룹을 동일한 소비자가 직렬로 처리할 수 있습니다. 클러스터의 각 브로커에 그룹화 처리기를 추가하면 클라이언트가 그룹화된 메시지를 클러스터의 모든 브로커에 보낼 수 있으며 동일한 소비자가 올바른 순서로 해당 메시지를 계속 사용할 수 있습니다.
그룹화 및 클러스터링 기술은 다음과 같이 요약할 수 있습니다.
- 메시지 그룹화는 메시지 사용에 순서를 적용합니다. 그룹에서는 다음 메시지를 진행하기 전에 각 메시지를 완전히 사용하고 승인해야 합니다. 이 방법론은 동시성이 옵션이 아닌 직렬 메시지 처리로 이어집니다.
- 클러스터링은 메시지 처리량을 높이기 위해 브로커를 수평으로 확장하는 것을 목표로 합니다. 수평 확장은 메시지를 동시에 처리할 수 있는 추가 소비자를 추가하여 달성됩니다.
이러한 기술은 서로 일치하지 않기 때문에 클러스터링 및 그룹화 사용을 피하십시오.
그룹화 핸들러에는 로컬 처리기와 원격 처리기 의 두 가지 유형이 있습니다. 이를 통해 브로커 클러스터는 특정 그룹의 모든 메시지를 적절한 큐로 라우팅하여 원하는 소비자가 올바른 순서로 사용할 수 있도록 합니다.
사전 요구 사항
클러스터의 각 브로커에 대해 한 명 이상의 소비자가 있어야 합니다.
메시지가 큐의 사용자에게 고정되면 동일한 그룹 ID가 있는 모든 메시지가 해당 큐로 라우팅됩니다. 소비자가 제거되면 소비자가 없는 경우에도 큐에서 메시지를 계속 수신합니다.
절차
클러스터의 한 브로커에서 로컬 처리기를 구성합니다.
고가용성을 사용하는 경우 마스터 브로커여야 합니다.
-
브로커의 <
broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
;core> 요소 내에서 로컬 처리기를 추가합니다.로컬 처리기는 원격 처리기의 중재자 역할을 합니다. 경로 정보를 저장하고 다른 브로커에 전달합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow grouping-handler-
name속성을 사용하여 그룹화 처리기의 고유한 이름을 지정합니다. type-
이 값을
LOCAL로 설정합니다. timeout메시지를 라우팅할 위치에 대한 결정이 내려질 때까지 대기하는 시간(밀리초)입니다. 기본값은 5000밀리초입니다. 라우팅 결정 전에 시간 초과에 도달하면 엄격한 메시지 순서를 보장하는 예외가 발생합니다.
브로커가 그룹 ID가 있는 메시지를 수신하면 소비자가 연결된 큐로의 경로를 청구합니다. 클러스터의 다른 브로커에서 그룹화 처리기에 의해 경로가 수락되면 경로가 설정됩니다. 클러스터의 모든 브로커는 이 그룹 ID를 사용하여 해당 큐로 메시지를 전달합니다. 브로커의 경로 제안이 거부되면 대체 경로를 제안하고 경로가 수락될 때까지 프로세스를 반복합니다.
-
브로커의 <
고가용성을 사용하는 경우 로컬 처리기 구성을 마스터 브로커의 슬레이브 브로커에 복사합니다.
로컬 처리기 구성을 슬레이브 브로커에 복사하면 로컬 처리기의 단일 장애 지점을 방지할 수 있습니다.
클러스터의 나머지 각 브로커에서 원격 처리기를 구성합니다.
-
브로커의 <
broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. <
;core> 요소 내에서 원격 처리기를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow grouping-handler-
name속성을 사용하여 그룹화 처리기의 고유한 이름을 지정합니다. type-
REMOTE로 설정합니다. timeout- 메시지를 라우팅할 위치에 대한 결정이 내려질 때까지 대기하는 시간(밀리초)입니다. 기본값은 5000밀리초입니다. 이 값을 로컬 처리기 값의 절반 이상으로 설정합니다.
-
브로커의 <
추가 리소스
-
메시지 그룹화용으로 구성된 브로커 클러스터의 예는
클러스터형AMQ Broker 예제 프로그램을 참조하십시오.
14.6. 브로커 클러스터에 클라이언트 연결 링크 복사링크가 클립보드에 복사되었습니다!
AMQ JMS 클라이언트를 사용하여 클러스터에 연결할 수 있습니다. JMS를 사용하면 메시징 클라이언트를 동적으로 또는 정적으로 브로커 목록을 검색하도록 구성할 수 있습니다. 클러스터 전체의 연결에서 생성된 클라이언트 세션을 배포하도록 클라이언트 측 부하 분산을 구성할 수도 있습니다.
절차
AMQ Core Protocol JMS를 사용하여 브로커 클러스터에 연결하도록 클라이언트 애플리케이션을 구성합니다.
자세한 내용은 AMQ Core Protocol JMS Client 사용을 참조하십시오.
14.7. 클라이언트 연결 파티셔닝 링크 복사링크가 클립보드에 복사되었습니다!
클라이언트 연결을 분할하려면 클라이언트가 연결을 시작할 때마다 개별 클라이언트에 대한 라우팅 연결이 포함됩니다.
클라이언트 연결 파티션의 두 가지 사용 사례는 다음과 같습니다.
- 의도하지 않은 서브스크립션의 클라이언트 파티셔닝을 통해 구독자가 항상 불안정한 구독자 큐가 있는 브로커에 연결할 수 있습니다.
- 데이터 중력이라고도 하는 데이터에 고객을 유치하여 데이터 이동의 필요성을 최소화합니다.
조정된 서브스크립션
장악한 서브스크립션은 브로커의 큐로 표현되며, 장엄한 구독자가 먼저 브로커에 연결될 때 생성됩니다. 이 큐는 브로커에 남아 있으며 클라이언트가 구독 해제될 때까지 메시지가 수신됩니다. 따라서 클라이언트가 동일한 브로커에 반복적으로 연결하여 구독자 큐에 있는 메시지를 소비합니다.
미지의 서브스크립션 대기열에 맞게 클라이언트를 분할하려면 클라이언트 연결에서 클라이언트 ID를 필터링할 수 있습니다.
데이터 중력
데이터 중력도 고려하지 않고 환경에서 브로커 수를 늘리는 경우 브로커 간에 메시지를 이동해야 하기 때문에 일부 성능 이점이 손실됩니다. 날짜 변동을 지원하려면 클라이언트 사용자가 사용해야 하는 메시지가 생성되는 브로커에 연결하도록 클라이언트 연결을 분할해야 합니다.
데이터 중요도를 지원하기 위해 클라이언트 연결을 분할하려면 클라이언트 연결의 다음 속성 중 하나를 필터링할 수 있습니다.
- 연결 사용자(ROLE_NAME)에 할당된 역할
- 사용자 이름 (USER_NAME)
- 클라이언트의 호스트 이름(SNI_HOST)
- 클라이언트의 IP 주소(SOURCE_IP)
14.7.1. Fluentd 서브스크립션을 지원하기 위해 클라이언트 연결 파티셔닝 링크 복사링크가 클립보드에 복사되었습니다!
미완성 서브스크립션을 위해 클라이언트를 분할하려면 일관된 해시 알고리즘 또는 정규식을 사용하여 들어오는 연결에서 클라이언트 ID를 필터링할 수 있습니다.
사전 요구 사항
클라이언트는 로드 밸런서를 사용하거나 모든 브로커 인스턴스를 연결 URL에 구성하여 클러스터의 모든 브로커에 연결할 수 있도록 구성됩니다. 클라이언트 세부 정보가 해당 브로커의 파티션 구성과 일치하지 않기 때문에 브로커가 연결을 거부하면 클라이언트는 클러스터의 다른 브로커에 연결하여 연결을 수락하는 브로커를 찾을 수 있어야 합니다.
14.7.1.1. 일관된 해시 알고리즘을 사용하여 클라이언트 ID 필터링 링크 복사링크가 클립보드에 복사되었습니다!
일관된 해시 알고리즘을 사용하여 각 클라이언트 연결에서 클라이언트 ID를 해시하도록 클러스터의 각 브로커를 구성할 수 있습니다. 브로커가 클라이언트 ID를 해시한 후 해시된 값에 대해 modulo 작업을 수행하여 클라이언트 연결에 대한 대상 브로커를 식별하는 정수 값을 반환합니다. 브로커는 반환된 정수 값을 브로커에 구성된 고유 값과 비교합니다. 일치 항목이 있는 경우 브로커는 연결을 허용합니다. 값이 일치하지 않으면 브로커는 연결을 거부합니다. 클러스터의 각 브로커에서 이 프로세스가 일치가 발견되고 브로커가 연결을 수락할 때까지 반복됩니다.
절차
-
첫 번째
브로커에 대해 <broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. connection-routers요소를 생성하고 일관된 해시 알고리즘을 사용하여 클라이언트 ID를 필터링할connection-route를 생성합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow connection-route-
connection-route name에게 이 연결 라우팅 구성에 대해 식별 문자열을 지정합니다. 일관된 해시 필터를 적용하려면 각 브로커 어셉터에 이 이름을 추가해야 합니다. key-
필터를 적용할 키 유형입니다. 클라이언트 ID를 필터링하려면
키필드에CLIENT_ID를 지정합니다. local-target-filter-
브로커가 modulo 작업에서 반환된 정수 값과 비교하여 일치 항목이 있고 브로커가 연결을 수락할 수 있는지 여부를 결정합니다. 이 예제의
NULL|0값은 클라이언트 ID (NULL)가 없는 연결과 modulo 작업에서 반환한 숫자가0인 연결에 대한 일치를 제공합니다. policy대상 브로커를 식별하기 위해 해시된 클라이언트 ID에서
modulo작업을 수행하는 modulo 속성 키를 수락합니다.modulo속성 키의 값은 클러스터의 브로커 수와 같아야 합니다.중요정책 이름은CONSISTENT_HASH_MODULO이어야 합니다.
-
두 번째
브로커의 <broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. connection-routers요소를 생성하고 일관된 해시 알고리즘을 사용하여 클라이언트 ID를 필터링하는연결 경로를 생성합니다.다음 예제에서
NULL|1의local-target-filter값은 클라이언트 ID(NULL)가 없는 연결과 modulo 작업에서 반환한 값이1인 연결에 대한 일치를 제공합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 클러스터의 각 추가 브로커에 대해 일관된 해시 필터를 생성하려면 이 절차를 반복합니다.
14.7.1.2. 정규식을 사용하여 클라이언트 ID 필터링 링크 복사링크가 클립보드에 복사되었습니다!
클라이언트 연결의 클라이언트 ID 부분에 정규식 필터를 적용하도록 브로커를 구성하여 클라이언트 연결을 분할할 수 있습니다. 브로커는 정규식 필터의 결과가 브로커에 대해 구성된 로컬 대상 필터와 일치하는 경우에만 연결을 수락합니다. 일치 항목이 없는 경우 브로커는 연결을 거부합니다. 클러스터의 각 브로커에서 이 프로세스가 일치가 발견되고 브로커가 연결을 수락할 때까지 반복됩니다.
사전 요구 사항
- 정규식으로 필터링할 수 있는 각 클라이언트 ID의 공통 문자열입니다.
절차
-
첫 번째
브로커에 대해 <broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. connection-routers요소를 생성하고 클라이언트 ID의 일부를 필터링할connection-route를 생성합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow connection-route-
connection-route name에게 이 라우팅 구성에 대한 식별 문자열을 지정합니다. 정규식 필터를 적용하려면 각 브로커 어셉터에 이 이름을 추가해야 합니다. key-
필터를 적용할 키입니다. 클라이언트 ID를 필터링하려면
키필드에CLIENT_ID를 지정합니다. key-filter키 값을 추출하기 위해 정규식이 적용되는 클라이언트 ID 문자열의 일부입니다. 위의 첫 번째 브로커 예제에서 브로커는 클라이언트 ID의 처음 3자인 키 값을 추출합니다. 예를 들어 클라이언트 ID 문자열이
CL100.consumer인 경우 브로커는CL1키 값을 추출합니다. 브로커가 키 값을 추출한 후 이를local-target-filter의 값과 비교합니다.들어오는 연결에 클라이언트 ID가 없거나 브로커가 키
-필터에 지정된 정규식을 사용하여 키 값을 추출할 수 없는 경우 키 값은 NULL로 설정됩니다.local-target-filter-
브로커가 키 값과 비교하여 일치 항목이 있고 브로커에서 연결을 수락할 수 있는지 확인하는 값입니다. 위의 첫 번째 브로커에 대한 예에 표시된 것처럼
NULL|CL1값은 클라이언트 ID(NULL)가 없거나 클라이언트 ID에CL1의 3자 접두사를 갖는 연결과 일치합니다.
-
두 번째
브로커의 <broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. connection-routers요소를 만들고 클라이언트 ID의 일부를 기반으로 연결을 필터링할 연결경로를 만듭니다.다음 필터 예제에서 브로커는 정규식을 사용하여 클라이언트 ID의 처음 3자인 키 값을 추출합니다. 브로커는
NULL및CL2의 값을 키 값과 비교하여 일치하는 항목이 있는지 확인하고 브로커가 연결을 수락할 수 있는지 확인합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 이 절차를 반복하고 클러스터의 각 추가 브로커에 대해 적절한 연결 라우팅 필터를 생성합니다.
14.7.2. 데이터 중력 지원을 위해 클라이언트 연결 파티셔닝 링크 복사링크가 클립보드에 복사되었습니다!
날짜 변동을 지원하기 위해 클라이언트 소비자가 소비해야 하는 메시지가 생성되는 브로커에 연결하도록 클라이언트 연결을 분할할 수 있습니다. 예를 들어 생산자 및 소비자 애플리케이션에서 사용하는 주소 집합이 있는 경우 특정 브로커에서 주소를 구성할 수 있습니다. 그런 다음 해당 주소를 사용하는 생산자와 소비자 모두 클라이언트 연결을 파티셔닝하여 해당 브로커에만 연결할 수 있습니다.
연결된 사용자에게 할당된 역할, 사용자의 사용자 이름 또는 클라이언트의 호스트 이름 또는 IP 주소와 같은 속성을 기반으로 클라이언트 연결을 분할할 수 있습니다. 이 섹션에서는 클라이언트 사용자에게 할당된 사용자 역할을 필터링하여 클라이언트 연결을 분할하는 방법의 예를 보여줍니다. 클라이언트가 브로커에 연결하기 위해 인증해야 하는 경우 역할 기준과 일치하는 사용자만 브로커에 연결할 수 있도록 클라이언트 사용자에게 역할을 할당하고 연결을 필터링할 수 있습니다.
사전 요구 사항
- 클라이언트는 로드 밸런서를 사용하거나 모든 브로커 인스턴스를 연결 URL에 구성하여 클러스터의 모든 브로커에 연결할 수 있도록 구성됩니다. 클라이언트가 해당 브로커에 대해 구성된 파티션 필터 기준과 일치하지 않기 때문에 브로커가 연결을 거부하면 클라이언트는 클러스터의 다른 브로커에 연결하여 연결을 수락하는 브로커를 찾을 수 있어야 합니다.
절차
-
첫 번째
브로커의 <broker_instance_dir> /etc/artemis-roles.properties파일을 엽니다.broker1users역할을 추가하고 역할에 사용자를 추가합니다. -
첫 번째
브로커에 대해 <broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. connection-routers요소를 만들고 사용자에게 할당된 역할에 따라 연결을 필터링할connection-route를 만듭니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow connection-route-
connection-route name에게 이 라우팅 구성에 대한 식별 문자열을 지정합니다. 역할 필터를 적용하려면 각 브로커 어셉터에 이 이름을 추가해야 합니다. key-
필터를 적용할 키입니다. 역할 기반 필터링을 구성하려면
키필드에ROLE_NAME을 지정합니다. key-filter-
브로커가 사용자 역할을 필터링하고 키 값을 추출하는 데 사용하는 문자열 또는 정규식입니다. 브로커가 일치하는 역할을 발견하면 키 값을 해당 역할로 설정합니다. 일치하는 역할을 찾지 못하면 브로커는 키 값을 NULL로 설정합니다. 위 예제에서 브로커는
broker1users필터를 클라이언트 사용자 역할에 적용합니다. 브로커가 키 값을 추출한 후 이를local-target-filter의 값과 비교합니다. local-target-filter-
브로커가 키 값과 비교하여 일치 항목이 있고 브로커에서 연결을 수락할 수 있는지 확인하는 값입니다. 이 예제에서 브로커는
broker1users의 값을 키 값과 비교합니다. 이는 사용자에게broker1users역할이 있고 브로커는 연결을 수락한다는 것을 의미합니다.
- 이 절차를 반복하고 필터에서 적절한 역할을 지정하여 클러스터의 다른 브로커의 클라이언트를 분할합니다.
14.7.3. 어셉터에 연결 경로 추가 링크 복사링크가 클립보드에 복사되었습니다!
브로커에서 연결 경로를 구성한 후 클라이언트 연결을 분할하기 위해 브로커의 어셉터 중 하나 이상에 경로를 추가해야 합니다. 연결 경로를 수락자에 추가한 후 브로커는 연결 경로에 구성된 필터를 수락자가 수신한 연결에 적용합니다.
절차
-
첫 번째
브로커에 대해 <broker_instance_dir> /etc/broker.xml구성 파일을 엽니다. 파티셔닝을 활성화하려는 각 어셉터에 대해
라우터키를 추가하고connection-route 이름을지정합니다. 다음 예에서는consistent-hash-routing의 connection-route 이름이artemisacceptor에 추가됩니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 클러스터의 각 브로커에 대해 적절한 연결 경로 필터를 지정하려면 이 절차를 반복합니다.
15장. Ceph를 사용하여 다중 사이트 내결함성 메시징 시스템 구성 링크 복사링크가 클립보드에 복사되었습니다!
대규모 엔터프라이즈 메시징 시스템에는 일반적으로 지리적으로 분산된 데이터 센터에 별도의 브로커 클러스터가 있습니다. 데이터 센터 중단이 발생하는 경우 시스템 관리자는 기존 메시징 데이터를 보존하고 클라이언트 애플리케이션이 메시지를 계속 생성하고 사용할 수 있는지 확인해야 할 수 있습니다. 특정 브로커 토폴로지 및 소프트웨어 정의 스토리지 플랫폼인 Red Hat Ceph Storage를 사용하여 데이터 센터 중단 시 메시징 시스템의 연속성을 보장할 수 있습니다. 이러한 유형의 솔루션을 내결함성의 다중 아키텍처 라고 합니다.
AMQP 프로토콜 지원만 필요한 경우 16장. 브로커 연결을 사용하여 다중 사이트 내결함성 메시징 시스템 구성 을 고려하십시오.
다음 섹션에서는 Red Hat Ceph Storage를 사용하여 데이터 센터 중단으로부터 메시징 시스템을 보호하는 방법을 설명합니다.
다중 사이트 내결함성은 데이터 센터 내에서 HA(고가용성) 브로커 중복을 대체하지 않습니다. 실시간 백업 그룹을 기반으로 하는 브로커 중복은 단일 클러스터 내의 단일 브로커 장애에 대한 자동 보호 기능을 제공합니다. 반면 다중 사이트 내결함성은 대규모 데이터 센터 중단으로부터 보호합니다.
Red Hat Ceph Storage를 사용하여 메시징 시스템의 연속성을 보장하려면 공유 저장소 HA(고가용성) 정책을 사용하도록 브로커를 구성해야 합니다. 복제 HA 정책을 사용하도록 브로커를 구성할 수 없습니다. 이러한 정책에 대한 자세한 내용은 고가용성을 참조하십시오.
15.1. Red Hat Ceph Storage 클러스터 작동 방식 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Ceph Storage는 클러스터된 오브젝트 스토리지 시스템입니다. Red Hat Ceph Storage는 개체 및 정책 기반 복제의 데이터 분할을 사용하여 데이터 무결성 및 시스템 가용성을 보장합니다.
Red Hat Ceph Storage는 CloudEvent(Controlled Replication Under Scalable Hashing)라는 알고리즘을 사용하여 데이터 스토리지 위치를 자동으로 컴퓨팅하여 데이터를 저장하고 검색하는 방법을 결정합니다. 클러스터 토폴로지를 자세히 설명하고 스토리지 클러스터 전체에서 데이터를 복제하는 방법을 지정하는 CloudEvent 맵 이라는 Ceph 항목을 구성합니다.
CloudEvent 맵에는 장치를 장애 도메인 계층 구조로 집계하기 위한 'buckets' 목록, Ceph 클러스터 풀에서 데이터를 복제해야 하는 규칙을 설명하는 OSD(Object Storage Devices) 목록이 포함되어 있습니다.
설치의 기본 물리적 조직을 반영하여 CloudEvent 맵을 모델링할 수 있으므로 물리적 근접성, 공유 전원 소스 및 공유 네트워크와 같은 관련 장치 실패의 잠재적 소스도 해결할 수 있습니다. 이 정보를 클러스터 맵으로 인코딩하면 CloudEvent는 다른 장애 도메인(예: 데이터 센터)에서 오브젝트 복제본을 분리하여 스토리지 클러스터 전체에서 데이터의 의사 무작위 배포를 유지 관리할 수 있습니다. 이를 통해 데이터 손실을 방지하고 클러스터의 성능이 저하된 상태로 작동할 수 있습니다.
Red Hat Ceph Storage 클러스터에 작동하려면 다수의 노드(실제 또는 가상)가 필요합니다. 클러스터에는 다음 유형의 노드가 포함되어야 합니다.
노드 모니터링
각 모니터(MON) 노드는 모니터 데몬(ceph-mon)을 실행하여 클러스터 맵의 마스터 복사본을 유지합니다. 클러스터 맵에는 클러스터 토폴로지가 포함됩니다. Ceph 클러스터에 연결하는 클라이언트는 모니터에서 클러스터 맵의 현재 사본을 검색하므로 클라이언트가 데이터를 읽고 클러스터에 데이터를 쓸 수 있습니다.
Red Hat Ceph Storage 클러스터는 하나의 Monitor 노드에서 실행할 수 있지만 프로덕션 클러스터에서 고가용성을 보장하기 위해 Red Hat은 3개 이상의 Monitor 노드가 있는 배포만 지원합니다. 최소 3개의 모니터 노드가 실패하거나 하나의 모니터를 사용할 수 없는 경우 클러스터의 나머지 모니터 노드에 새 리더를 선택하는 데 쿼럼이 존재합니다.
Manager 노드
각 Manager(MGR) 노드는 Ceph Manager 데몬(ceph-mgr)을 실행합니다. 이 데몬은 스토리지 사용률, 현재 성능 지표, 시스템 로드를 포함하여 런타임 지표 및 Ceph 클러스터의 현재 상태를 추적합니다. 일반적으로 Manager 노드는 Monitor 노드와 함께 배치됩니다(즉, 동일한 호스트 시스템에 있음).
Object Storage 장치 노드
각 OSD(Object Storage Device) 노드는 노드에 연결된 논리 디스크와 상호 작용하는 Ceph OSD 데몬(ceph-osd)을 실행합니다. Ceph는 OSD 노드에 데이터를 저장합니다. Ceph는 매우 적은 수의 OSD 노드(기본값: 3개)로 실행할 수 있지만 프로덕션 클러스터는 스토리지 클러스터에서 50개의 OSD를 사용하는 모드로 확장 가능한 성능을 실현합니다. 스토리지 클러스터에 여러 개의 OSD가 있으면 시스템 관리자가 CloudEvent 맵 내에서 격리된 장애 도메인을 정의할 수 있습니다.
metadata Server 노드
각 메타데이터 서버(MDS) 노드는 MDS 데몬(ceph-mds)을 실행하여 Ceph 파일 시스템(CephFS)에 저장된 파일과 관련된 메타데이터를 관리합니다. MDS 데몬은 공유 클러스터에 대한 액세스도 조정합니다.
추가 리소스
Red Hat Ceph Storage에 대한 자세한 내용은 What is Red Hat Ceph Storage?
15.2. Red Hat Ceph Storage 설치 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker 다중 사이트 내결함성 아키텍처에서는 Red Hat Ceph Storage 3을 사용합니다. Red Hat Ceph Storage 클러스터는 데이터 센터 간에 데이터를 복제함으로써 브로커가 별도의 데이터 센터에서 사용할 수 있는 공유 저장소를 효과적으로 생성합니다. 공유 저장소 HA(고가용성) 정책을 사용하고 Red Hat Ceph Storage 클러스터에 메시징 데이터를 저장하도록 브로커를 구성합니다.
프로덕션용 Red Hat Ceph Storage 클러스터에는 다음과 같은 최소 항목이 있어야 합니다.
- 모니터 노드 3개(MON)
- 3 관리자 (MGR) 노드
- 여러 OSD 데몬을 포함하는 OSD(Object Storage Device) 노드 세 개
- 3개의 메타데이터 서버(MDS) 노드
동일한 물리적 또는 가상 머신에서 OSD, MON, MGR 및 MDS 노드를 실행할 수 있습니다. 그러나 Red Hat Ceph Storage 클러스터 내에서 내결함성을 보장하기 위해 이러한 유형의 각 노드를 별도의 데이터 센터에 배포하는 것이 좋습니다. 특히 단일 데이터 센터 중단 시 스토리지 클러스터에 최소 두 개의 사용 가능한 MON 노드가 있는지 확인해야 합니다. 따라서 클러스터에 MON 노드가 3개인 경우 이러한 각 노드는 별도의 데이터 센터의 별도의 호스트 시스템에서 실행해야 합니다. 이 데이터 센터가 실패해도 MON 노드가 하나만 남아 있기 때문에 단일 데이터 센터에서 두 개의 MON 노드를 실행하지 마십시오. 이 경우 스토리지 클러스터가 더 이상 작동하지 않을 수 있습니다.
이 섹션에서는 MON, MGR, OSD 및 MDS 노드가 포함된 Red Hat Ceph Storage 3 클러스터를 설치하는 방법을 설명합니다.
사전 요구 사항
Red Hat Ceph Storage 설치 준비에 대한 자세한 내용은 다음을 참조하십시오.
절차
MON, MGR, OSD 및 MDS 노드가 포함된 Red Hat Ceph 3 스토리지 클러스터를 설치하는 방법을 보여주는 프로시저는 다음을 참조하십시오.
15.3. Red Hat Ceph Storage 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제 절차에서는 내결함성을 위해 Red Hat Ceph 스토리지 클러스터를 구성하는 방법을 설명합니다. OSD(Object Storage Device) 노드를 실제 물리적 설치를 반영하는 데이터 센터로 집계하기 위해 CloudEvent 버킷을 생성합니다. 또한 스토리지 풀에서 데이터를 복제하는 방법을 CloudEvent에 알리는 규칙을 생성합니다. 이 단계는 Ceph 설치에 의해 생성된 기본 CloudEvent 맵이 업데이트되었습니다.
사전 요구 사항
- Red Hat Ceph Storage 클러스터가 이미 설치되어 있습니다. 자세한 내용은 Red Hat Ceph Storage 설치를 참조하십시오.
- Red Hat Ceph Storage가 PG(배치 그룹)를 사용하여 풀에서 많은 수의 데이터 오브젝트를 구성하는 방법과 풀에서 사용할 PG 수를 계산하는 방법을 이해해야 합니다. 자세한 내용은 PG(배치 그룹)를 참조하십시오.
- 풀에서 오브젝트 복제본 수를 설정하는 방법을 이해해야 합니다. 자세한 내용은 오브젝트 복제본 수를 설정합니다.
절차
CloudEvent 버킷을 생성하여 OSD 노드를 구성합니다. 버킷은 데이터 센터와 같은 물리적 위치를 기반으로 하는 OSD 목록입니다. Ceph에서 이러한 물리적 위치를 장애 도메인 이라고 합니다.
ceph osd crush add-bucket dc1 datacenter ceph osd crush add-bucket dc2 datacenter
ceph osd crush add-bucket dc1 datacenter ceph osd crush add-bucket dc2 datacenterCopy to Clipboard Copied! Toggle word wrap Toggle overflow OSD 노드의 호스트 시스템을 사용자가 생성한 데이터 센터 CloudEvent 버킷으로 이동합니다. 호스트 이름
host1-host4를 호스트 시스템의 이름으로 바꿉니다.ceph osd crush move host1 datacenter=dc1 ceph osd crush move host2 datacenter=dc1 ceph osd crush move host3 datacenter=dc2 ceph osd crush move host4 datacenter=dc2
ceph osd crush move host1 datacenter=dc1 ceph osd crush move host2 datacenter=dc1 ceph osd crush move host3 datacenter=dc2 ceph osd crush move host4 datacenter=dc2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 생성한 CloudEvent 버킷이
기본CloudEvent 트리에 포함되어 있는지 확인합니다.ceph osd crush move dc1 root=default ceph osd crush move dc2 root=default
ceph osd crush move dc1 root=default ceph osd crush move dc2 root=defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 데이터 센터에서 스토리지 오브젝트 복제본을 매핑하는 규칙을 생성합니다. 이를 통해 데이터 손실을 방지하고 단일 데이터 센터 중단 시 클러스터가 계속 실행될 수 있습니다.
규칙을 생성하는 명령은 다음 구문을 사용합니다.
ceph osd crush 규칙 create-replicated <rule-name> <root> <failure-domain> <class>. 예는 다음과 같습니다.ceph osd crush rule create-replicated multi-dc default datacenter hdd
ceph osd crush rule create-replicated multi-dc default datacenter hddCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이전 명령에서 스토리지 클러스터가 SSD(솔리드 스테이트 드라이브)를 사용하는 경우
hdd(하드 디스크 드라이브) 대신ssd를 지정합니다.생성한 규칙을 사용하도록 Ceph 데이터 및 메타데이터 풀을 구성합니다. 처음에 이로 인해 CloudEvent 알고리즘에 의해 결정된 스토리지 대상에 데이터가 다시 입력될 수 있습니다.
ceph osd pool set cephfs_data crush_rule multi-dc ceph osd pool set cephfs_metadata crush_rule multi-dc
ceph osd pool set cephfs_data crush_rule multi-dc ceph osd pool set cephfs_metadata crush_rule multi-dcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 메타데이터 및 데이터 풀의 PG(배치 그룹) 및 PG(배치 그룹) 수를 지정합니다. PGP 값은 PG 값과 같아야 합니다.
ceph osd pool set cephfs_metadata pg_num 128 ceph osd pool set cephfs_metadata pgp_num 128 ceph osd pool set cephfs_data pg_num 128 ceph osd pool set cephfs_data pgp_num 128
ceph osd pool set cephfs_metadata pg_num 128 ceph osd pool set cephfs_metadata pgp_num 128 ceph osd pool set cephfs_data pg_num 128 ceph osd pool set cephfs_data pgp_num 128Copy to Clipboard Copied! Toggle word wrap Toggle overflow 데이터 및 메타데이터 풀에서 사용할 복제본 수를 지정합니다.
ceph osd pool set cephfs_data min_size 1 ceph osd pool set cephfs_metadata min_size 1 ceph osd pool set cephfs_data size 2 ceph osd pool set cephfs_metadata size 2
ceph osd pool set cephfs_data min_size 1 ceph osd pool set cephfs_metadata min_size 1 ceph osd pool set cephfs_data size 2 ceph osd pool set cephfs_metadata size 2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 그림은 이전 예제 프로시저에서 생성한 Red Hat Ceph Storage 클러스터를 보여줍니다. 스토리지 클러스터에는 데이터 센터에 해당하는 CloudEvent 버킷으로 구성된 OSD가 있습니다.
다음 그림은 브로커 서버를 포함하여 첫 번째 데이터 센터의 가능한 레이아웃을 보여줍니다. 특히 데이터 센터 호스트는 다음과 같습니다.
- 두 개의 라이브 백업 브로커 쌍의 서버
- 이전 절차의 첫 번째 데이터 센터에 할당한 OSD 노드
- 단일 메타데이터 서버, 모니터 및 관리자 노드. 모니터 노드와 Manager 노드는 일반적으로 동일한 시스템에 배치됩니다.
동일한 물리적 또는 가상 머신에서 OSD, MON, MGR 및 MDS 노드를 실행할 수 있습니다. 그러나 Red Hat Ceph Storage 클러스터 내에서 내결함성을 보장하기 위해 이러한 유형의 각 노드를 별도의 데이터 센터에 배포하는 것이 좋습니다. 특히 단일 데이터 센터 중단 시 최소 두 개의 사용 가능한 MON 노드가 있는지 확인해야 합니다. 따라서 클러스터에 MON 노드가 3개인 경우 이러한 각 노드는 별도의 데이터 센터의 별도의 호스트 시스템에서 실행해야 합니다.
다음 그림은 전체 예제 토폴로지를 보여줍니다. 스토리지 클러스터에서 내결함성을 보장하기 위해 MON, MGR 및 MDS 노드는 세 개의 별도의 데이터 센터에 배포됩니다.
브로커 서버와 동일한 데이터 센터에 있는 특정 OSD 노드의 호스트 시스템을 배치해도 특정 OSD 노드에 메시징 데이터를 저장하는 것은 아닙니다. 메시징 데이터를 Ceph 파일 시스템의 지정된 디렉터리에 저장하도록 브로커를 구성합니다. 그런 다음 클러스터의 메타데이터 서버 노드는 저장된 데이터를 데이터 센터에서 사용 가능한 모든 OSD에 배포하고 이 데이터의 복제를 처리하는 방법을 결정합니다. 다음 섹션에서는 Ceph 파일 시스템에 메시징 데이터를 저장하도록 브로커를 구성하는 방법을 보여줍니다.
아래 그림은 브로커 서버가 있는 두 데이터 센터 간 데이터 복제를 보여줍니다.
추가 리소스
다음에 대한 자세한 내용은 다음을 참조하십시오.
- Red Hat Ceph Storage 클러스터에 대한 ReadWriteMany를 관리하는 방법은 CloudEvent 관리 를 참조하십시오.
- 스토리지 풀에서 설정할 수 있는 전체 속성 세트는 풀 값을 참조하십시오.
15.4. 브로커 서버에 Ceph 파일 시스템 마운트 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Ceph Storage 클러스터에 메시징 데이터를 저장하도록 메시징 시스템에서 브로커를 구성하려면 먼저 Ceph 파일 시스템(CephFS)을 마운트해야 합니다.
이 섹션의 프로세스에는 브로커 서버에 CephFS를 마운트하는 방법을 보여줍니다.
사전 요구 사항
다음이 있습니다.
- Red Hat Ceph Storage 클러스터 설치 및 구성. 자세한 내용은 Red Hat Ceph Storage 클러스터 설치 및 구성을 참조하십시오.
-
3개 이상의 Ceph 메타데이터 서버 데몬(
ceph-mds)을 설치하고 구성합니다. 자세한 내용은 메타데이터 서버 설치 및 메타데이터 서버 데몬 구성을 참조하십시오. - 모니터 노드에서 Ceph 파일 시스템을 생성했습니다. 자세한 내용은 Ceph 파일 시스템 생성을 참조하십시오.
- 브로커 서버가 권한 있는 액세스에 사용할 수 있는 키가 있는 Ceph File System 클라이언트 사용자를 생성했습니다. 자세한 내용은 Ceph 파일 시스템 클라이언트 사용자 생성을 참조하십시오.
절차
브로커 서버에 Ceph 파일 시스템을 마운트하는 방법에 대한 자세한 내용은 Ceph 파일 시스템 마운트를 참조하십시오.
15.5. 다중 사이트 내결함성 메시징 시스템에서 브로커 구성 링크 복사링크가 클립보드에 복사되었습니다!
브로커를 다중 사이트 내결함성 메시징 시스템의 일부로 구성하려면 다음을 수행해야 합니다.
15.5.1. 백업 브로커 추가 링크 복사링크가 클립보드에 복사되었습니다!
각 데이터 센터 내에서 데이터 센터 중단 시 종료되는 라이브 마스터 슬레이브 브로커 그룹에서 인수할 수 있는 유휴 백업 브로커를 추가해야 합니다. 유휴 백업 브로커에서 라이브 마스터 브로커의 구성을 복제해야 합니다. 또한 기존 브로커와 동일한 방식으로 클라이언트 연결을 허용하도록 백업 브로커를 구성해야 합니다.
이후 절차에서는 기존 master-slave 브로커 그룹에 가입하도록 유휴 백업 브로커를 구성하는 방법을 확인할 수 있습니다. 별도의 데이터 센터에서 라이브 master-slave 브로커 그룹의 유휴 백업 브로커를 찾아야 합니다. 또한 유휴 백업 브로커를 데이터 센터 오류가 발생한 경우에만 수동으로 시작하는 것이 좋습니다.
다음 그림은 토폴로지 예제를 보여줍니다.
추가 리소스
- 추가 브로커 인스턴스를 생성하는 방법에 대한 자세한 내용은 독립 실행형 브로커 생성을 참조하십시오.
- 브로커 네트워크 연결 구성에 대한 자세한 내용은 2장. 네트워크 연결에서 어셉터 및 커넥터 구성 을 참조하십시오.
15.5.2. 브로커를 Ceph 클라이언트로 구성 링크 복사링크가 클립보드에 복사되었습니다!
내결함성 시스템에 필요한 백업 브로커를 추가한 경우 Ceph 클라이언트 역할을 사용하여 모든 브로커 서버를 구성해야 합니다. 클라이언트 역할을 통해 브로커는 Red Hat Ceph Storage 클러스터에 데이터를 저장할 수 있습니다.
Ceph 클라이언트 구성 방법을 알아보려면 Ceph 클라이언트 역할 설치를 참조하십시오.
15.6. 다중 사이트 내결함성 메시징 시스템에서 클라이언트 구성 링크 복사링크가 클립보드에 복사되었습니다!
내부 클라이언트 애플리케이션은 브로커 서버와 동일한 데이터 센터에 있는 시스템에서 실행 중인 애플리케이션입니다. 다음 그림은 이 토폴로지를 보여줍니다.
외부 클라이언트 애플리케이션은 브로커 데이터 센터 외부에 있는 시스템에서 실행 중인 애플리케이션입니다. 다음 그림은 이 토폴로지를 보여줍니다.
다음 하위 섹션에서는 데이터 센터 중단 시 다른 데이터 센터의 백업 브로커에 연결하도록 내부 및 외부 클라이언트 애플리케이션을 구성하는 예를 보여줍니다.
15.6.1. 내부 클라이언트 구성 링크 복사링크가 클립보드에 복사되었습니다!
데이터 센터 중단이 발생하면 브로커와 함께 내부 클라이언트 애플리케이션이 종료됩니다. 이러한 상황을 완화하려면 별도의 데이터 센터에서 다른 클라이언트 애플리케이션 인스턴스를 사용할 수 있어야 합니다. 데이터 센터 중단이 발생하면 수동으로 시작한 백업 브로커에 연결하기 위해 백업 클라이언트를 수동으로 시작합니다.
백업 클라이언트가 백업 브로커에 연결할 수 있도록 하려면 기본 데이터 센터의 클라이언트와 유사하게 클라이언트 연결을 구성해야 합니다.
예제
아래에는 AMQ Core Protocol JMS 클라이언트에 대한 master-slave 브로커 그룹에 대한 기본 연결 구성이 표시되어 있습니다. 이 예제에서 host1 및 host2 는 마스터 및 슬레이브 브로커의 호스트 서버입니다.
<ConnectionFactory connectionFactory = new ActiveMQConnectionFactory(“(tcp://host1:port,tcp://host2:port)?ha=true&retryInterval=100&retryIntervalMultiplier=1.0&reconnectAttempts=-1”);
<ConnectionFactory connectionFactory = new ActiveMQConnectionFactory(“(tcp://host1:port,tcp://host2:port)?ha=true&retryInterval=100&retryIntervalMultiplier=1.0&reconnectAttempts=-1”);
데이터 센터 중단 시 백업 브로커에 연결하도록 백업 클라이언트를 구성하려면 유사한 연결 구성을 사용하지만 백업 브로커 서버의 호스트 이름만 지정합니다. 이 예에서 백업 브로커 서버는 host3입니다.
<ConnectionFactory connectionFactory = new ActiveMQConnectionFactory(“(tcp://host3:port)?ha=true&retryInterval=100&retryIntervalMultiplier=1.0&reconnectAttempts=-1”);
<ConnectionFactory connectionFactory = new ActiveMQConnectionFactory(“(tcp://host3:port)?ha=true&retryInterval=100&retryIntervalMultiplier=1.0&reconnectAttempts=-1”);
추가 리소스
- 브로커 네트워크 연결 구성에 대한 자세한 내용은 2장. 네트워크 연결에서 어셉터 및 커넥터 구성 을 참조하십시오.
15.6.2. 외부 클라이언트 구성 링크 복사링크가 클립보드에 복사되었습니다!
외부 브로커 클라이언트가 데이터 센터 중단 시 메시징 데이터를 계속 생성하거나 소비할 수 있도록 하려면 다른 데이터 센터의 브로커에 장애 조치하도록 클라이언트를 구성해야 합니다. 다중 사이트 내결함성 시스템의 경우 중단 시 수동으로 시작하는 백업 브로커에 장애 조치하도록 클라이언트를 구성합니다.
예
다음은 기본 master-slave 그룹을 사용할 수 없는 경우 백업 브로커에 장애 조치하도록 AMQ Core Protocol JMS 및 AMQ JMS 클라이언트를 구성하는 예입니다. 이 예에서 host1 및 host2 는 기본 마스터 및 슬레이브 브로커의 호스트 서버이며, host3 은 데이터 센터 중단 시 수동으로 시작하는 백업 브로커의 호스트 서버입니다.
AMQ Core Protocol JMS 클라이언트를 구성하려면 클라이언트가 연결하려는 정렬된 브로커 목록에 백업 브로커를 포함합니다.
<ConnectionFactory connectionFactory = new ActiveMQConnectionFactory(“(tcp://host1:port,tcp://host2:port,tcp://host3:port)?ha=true&retryInterval=100&retryIntervalMultiplier=1.0&reconnectAttempts=-1”);
<ConnectionFactory connectionFactory = new ActiveMQConnectionFactory(“(tcp://host1:port,tcp://host2:port,tcp://host3:port)?ha=true&retryInterval=100&retryIntervalMultiplier=1.0&reconnectAttempts=-1”);Copy to Clipboard Copied! Toggle word wrap Toggle overflow AMQ JMS 클라이언트를 구성하려면 클라이언트에서 구성하는 장애 조치 URI에 백업 브로커를 포함합니다.
failover:(amqp://host1:port,amqp://host2:port,amqp://host3:port)?jms.clientID=myclient&failover.maxReconnectAttempts=20
failover:(amqp://host1:port,amqp://host2:port,amqp://host3:port)?jms.clientID=myclient&failover.maxReconnectAttempts=20Copy to Clipboard Copied! Toggle word wrap Toggle overflow
추가 리소스
장애 조치 구성에 대한 자세한 내용은 다음을 참조하십시오.
- AMQ Core Protocol JMS 클라이언트는 Reconnect and failover 를 참조하십시오.
- AMQ JMS 클라이언트의 경우 Cryostat 옵션을 참조하십시오.
- 기타 지원되는 클라이언트는 Red Hat AMQ Clients 제품 설명서의 클라이언트별 문서를 참조하십시오.
15.7. 데이터 센터 중단 중 스토리지 클러스터 상태 확인 링크 복사링크가 클립보드에 복사되었습니다!
내결함성을 위해 Red Hat Ceph Storage 클러스터를 구성하면 데이터 센터 중 하나가 실패하는 경우에도 클러스터가 데이터 손실 없이 성능이 저하된 상태로 계속 실행됩니다.
다음 절차에서는 성능이 저하된 상태로 실행되는 동안 클러스터 상태를 확인하는 방법을 설명합니다.
절차
Ceph 스토리지 클러스터의 상태를 확인하려면
상태 또는명령을 사용합니다.상태ceph health ceph status
# ceph health # ceph statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 명령줄에서 클러스터의 지속적인 이벤트를 보려면 새 터미널을 엽니다. 그런 다음 다음을 입력합니다.
ceph -w
# ceph -wCopy to Clipboard Copied! Toggle word wrap Toggle overflow
이전 명령을 실행하는 경우 스토리지 클러스터가 여전히 실행 중이지만 성능이 저하되었음을 나타내는 출력이 표시됩니다. 특히 다음과 유사한 경고가 표시됩니다.
health: HEALTH_WARN
2 osds down
Degraded data redundancy: 42/84 objects degraded (50.0%), 16 pgs unclean, 16 pgs degraded
health: HEALTH_WARN
2 osds down
Degraded data redundancy: 42/84 objects degraded (50.0%), 16 pgs unclean, 16 pgs degraded
추가 리소스
- Red Hat Ceph Storage 클러스터의 상태 모니터링에 대한 자세한 내용은 모니터링을 참조하십시오.
15.8. 데이터 센터 중단 시 메시징 지속성 유지 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 데이터 센터 중단 중에 클라이언트가 브로커 및 관련 메시징 데이터를 계속 사용할 수 있도록 하는 방법을 보여줍니다. 특히 데이터 센터가 실패하면 다음을 수행해야합니다.
- 실패한 데이터 센터의 브로커에서 인수하기 위해 생성한 유휴 백업 브로커를 수동으로 시작합니다.
- 내부 또는 외부 클라이언트를 새로운 활성 브로커에 연결합니다.
사전 요구 사항
다음이 있어야 합니다.
- Red Hat Ceph Storage 클러스터 설치 및 구성. 자세한 내용은 Red Hat Ceph Storage 클러스터 설치 및 구성을 참조하십시오.
- Ceph 파일 시스템을 마운트합니다. 자세한 내용은 브로커 서버에 Ceph 파일 시스템 마운트를 참조하십시오.
- 데이터 센터 오류가 발생할 경우 라이브 브로커에서 인수할 유휴 백업 브로커가 추가되었습니다. 자세한 내용은 백업 브로커 추가 를 참조하십시오.
- Ceph 클라이언트 역할을 사용하여 브로커 서버를 구성합니다. 자세한 내용은 브로커 구성을 Ceph 클라이언트로 참조하십시오.
- 각 브로커는 공유 저장소 HA(고가용성) 정책을 사용하도록 구성되며 각 브로커는 각 브로커가 메시징 데이터를 저장하는 위치를 지정합니다. 자세한 내용은 공유 저장소 고가용성 구성을 참조하십시오.
- 데이터 센터 중단 시 백업 브로커에 연결하도록 클라이언트를 구성합니다. 자세한 내용은 내결함성 메시징 시스템에서 클라이언트 구성을 참조하십시오.
절차
실패한 데이터 센터의 각 마스터 슬레이브 브로커 쌍에 대해 추가한 유휴 백업 브로커를 수동으로 시작합니다.
클라이언트 연결을 다시 설정합니다.
실패한 데이터 센터에서 내부 클라이언트를 사용하는 경우 생성한 백업 클라이언트를 수동으로 시작합니다. 다중 사이트 내결함성 메시징 시스템에서 클라이언트 구성에 설명된 대로 수동으로 시작한 백업 브로커에 연결하도록 클라이언트를 구성해야 합니다.
다음 그림은 새 토폴로지를 보여줍니다.
외부 클라이언트가 있는 경우 외부 클라이언트를 새 활성 브로커에 수동으로 연결하거나 클라이언트가 구성에 따라 새 활성 브로커로 자동 장애 조치합니다. 자세한 내용은 외부 클라이언트 구성을 참조하십시오.
다음 그림은 새 토폴로지를 보여줍니다.
15.9. 이전에 실패한 데이터 센터를 다시 시작 링크 복사링크가 클립보드에 복사되었습니다!
이전에 실패한 데이터 센터가 다시 온라인 상태가 되면 다음 단계에 따라 메시징 시스템의 원래 상태를 복원합니다.
- Red Hat Ceph Storage 클러스터의 노드를 호스팅하는 서버를 다시 시작합니다.
- 메시징 시스템에서 브로커를 다시 시작합니다.
- 클라이언트 애플리케이션에서 복원된 브로커로의 연결을 다시 설정
다음 하위 섹션은 다음 단계를 수행하는 방법을 보여줍니다.
15.9.1. 스토리지 클러스터 서버 다시 시작 링크 복사링크가 클립보드에 복사되었습니다!
이전에 실패한 데이터 센터에서 Monitor, Metadata Server, Manager 및 OSD(Object Storage Device) 노드를 재시작하면 Red Hat Ceph Storage 클러스터 자체 복구로 전체 데이터 중복성을 복원합니다. 이 프로세스 중에 Red Hat Ceph Storage는 필요에 따라 복원된 OSD 노드로 데이터를 자동으로 채웁니다.
스토리지 클러스터가 자동으로 자동 복구 및 전체 데이터 중복성 복원인지 확인하려면 데이터 센터 중단 중에 스토리지 클러스터 상태 확인에 표시된 명령을 사용합니다. 이러한 명령을 다시 실행하면 이전 HEALTH_WARN 메시지가 표시된 백분율이 100%로 반환될 때까지 개선되기 시작합니다.
15.9.2. 브로커 서버 다시 시작 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 스토리지 클러스터가 더 이상 성능이 저하된 상태에서 작동하지 않는 경우 브로커 서버를 다시 시작하는 방법을 보여줍니다.
절차
- 데이터 센터 중단이 발생했을 때 수동으로 시작한 백업 브로커에 연결된 클라이언트 애플리케이션을 중지합니다.
수동으로 시작한 백업 브로커를 중지합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis stop
<broker_instance_dir>/bin/artemis stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe stop
<broker_instance_dir>\bin\artemis-service.exe stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
이전에 실패한 데이터 센터에서 원래 마스터 및 슬레이브 브로커를 다시 시작합니다.
Linux의 경우:
<broker_instance_dir>/bin/artemis run
<broker_instance_dir>/bin/artemis runCopy to Clipboard Copied! Toggle word wrap Toggle overflow Windows에서 다음을 수행합니다.
<broker_instance_dir>\bin\artemis-service.exe start
<broker_instance_dir>\bin\artemis-service.exe startCopy to Clipboard Copied! Toggle word wrap Toggle overflow
원래 마스터 브로커는 다시 시작할 때 마스터로 자동으로 역할을 다시 시작합니다.
15.9.3. 클라이언트 연결 재설정 링크 복사링크가 클립보드에 복사되었습니다!
브로커 서버를 다시 시작하면 클라이언트 애플리케이션을 해당 브로커에 다시 연결합니다. 다음 하위 섹션에서는 내부 및 외부 클라이언트 애플리케이션을 다시 연결하는 방법을 설명합니다.
15.9.3.1. 내부 클라이언트 다시 연결 링크 복사링크가 클립보드에 복사되었습니다!
내부 클라이언트는 복원 브로커와 마찬가지로 이전에 실패한 데이터 센터로 실행 중인 클라이언트입니다. 내부 클라이언트를 다시 연결하려면 해당 클라이언트를 다시 시작합니다. 각 클라이언트 애플리케이션은 연결 구성에 지정된 복원된 마스터 브로커에 다시 연결합니다.
브로커 네트워크 연결 구성에 대한 자세한 내용은 2장. 네트워크 연결에서 어셉터 및 커넥터 구성 을 참조하십시오.
15.9.3.2. 외부 클라이언트 다시 연결 링크 복사링크가 클립보드에 복사되었습니다!
외부 클라이언트는 이전에 실패한 데이터 센터 외부에서 실행되는 클라이언트입니다. 클라이언트 유형 및 외부 브로커 클라이언트 구성의 정보에 따라 클라이언트가 백업 브로커에 자동으로 장애 조치하도록 구성 하거나 이 연결을 수동으로 설정했습니다. 이전에 실패한 데이터 센터를 복원할 때 아래에 설명된 것처럼 클라이언트에서 복원된 마스터 브로커로 연결을 다시 설정합니다.
- 백업 브로커로 자동 장애 조치하도록 외부 클라이언트를 구성한 경우 백업 브로커를 종료하고 원래 마스터 브로커를 다시 시작할 때 클라이언트가 원래 마스터 브로커로 자동으로 실패합니다.
- 데이터 센터 중단이 발생했을 때 외부 클라이언트를 백업 브로커에 수동으로 연결한 경우 다시 시작한 원래 마스터 브로커에 클라이언트를 수동으로 다시 연결해야 합니다.
16장. 브로커 연결을 사용하여 다중 사이트 내결함성 메시징 시스템 구성 링크 복사링크가 클립보드에 복사되었습니다!
대규모 엔터프라이즈 메시징 시스템에는 일반적으로 지리적으로 분산된 데이터 센터에 별도의 브로커 클러스터가 있습니다. 데이터 센터 중단이 발생하는 경우 시스템 관리자는 기존 메시징 데이터를 보존하고 클라이언트 애플리케이션이 메시지를 계속 생성하고 사용할 수 있는지 확인해야 할 수 있습니다. 브로커 연결을 사용하여 데이터 센터 중단 중에 메시징 시스템의 연속성을 보장할 수 있습니다. 이러한 유형의 솔루션을 내결함성의 다중 아키텍처 라고 합니다.
브로커 연결을 위한 브로커 간 통신에는 AMQP 프로토콜만 지원됩니다. 클라이언트는 지원되는 모든 프로토콜을 사용할 수 있습니다. 현재 메시지는 미러링 프로세스를 통해 AMQP로 변환됩니다.
다음 섹션에서는 브로커 연결을 사용하여 데이터 센터 중단으로부터 메시징 시스템을 보호하는 방법을 설명합니다.
다중 사이트 내결함성은 데이터 센터 내에서 HA(고가용성) 브로커 중복을 대체하지 않습니다. 실시간 백업 그룹을 기반으로 하는 브로커 중복은 단일 클러스터 내의 단일 브로커 장애에 대한 자동 보호 기능을 제공합니다. 반면 다중 사이트 내결함성은 대규모 데이터 센터 중단으로부터 보호합니다.
16.1. 브로커 연결 정보 링크 복사링크가 클립보드에 복사되었습니다!
브로커 연결을 사용하면 브로커가 다른 브로커에 대한 연결을 설정하고 해당 브로커와의 미러 메시지를 설정할 수 있습니다.
- AMQP 서버 연결
- 브로커 연결은 AMQP 프로토콜을 사용하여 다른 엔드포인트에 대한 연결을 시작할 수 있습니다. 즉, 브로커가 다른 AMQP 서버에 연결하고 이러한 연결에 요소를 생성할 수 있습니다.
AMQP 서버 연결에서 다음 유형의 작업이 지원됩니다.
- 미러 - 브로커는 다른 브로커에 AMQP 연결을 사용하고 메시지를 복제하고 전선을 통해 승인을 보냅니다.
- 발신자 - 특정 큐에서 수신된 메시지는 다른 브로커로 전송됩니다.
- 수신자 - 브로커는 다른 브로커의 메시지를 가져옵니다.
- 피어 - 브로커는 AMQ Interconnect 엔드포인트에서 발신자와 수신자를 모두 생성합니다.
이 장에서는 브로커 연결을 사용하여 내결함성 시스템을 생성하는 방법을 설명합니다. 발신자, 수신자 및 피어 옵션에 대한 정보는 17장. 브리징 브로커 을 참조하십시오.
다음 이벤트는 미러링을 통해 전송됩니다.
- 메시지 전송 - 하나의 브로커로 전송된 메시지는 대상 브로커로 "복제"됩니다.
- 메시지 승인 - 한 브로커에서 메시지를 제거하는 감사는 대상 브로커로 전송됩니다.
- 대기열 및 주소 생성.
- 대기열 및 주소 삭제.
대상 미러의 소비자에 대해 메시지가 보류 중인 경우 승인이 성공하지 못하고 두 브로커에서 메시지를 전달할 수 있습니다.
미러링은 작업을 차단하지 않으며 브로커의 성능에 영향을 미치지 않습니다.
브로커는 미러가 구성된 시점에서의 메시지만 미러링합니다. 이전 기존 메시지는 다른 브로커로 전달되지 않습니다.
16.2. 브로커 연결 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 브로커 간 메시지를 미러링하도록 브로커 연결을 구성하는 방법을 보여줍니다. 브로커 중 하나만 언제든지 활성화되어 있으며 모든 메시지는 다른 브로커에 미러링됩니다.
사전 요구 사항
- 두 개의 작업 브로커가 있습니다.
절차
첫 번째 브로커의
broker.xml파일에broker-connections요소를 생성합니다. 예를 들면 다음과 같습니다.<broker-connections> <amqp-connection uri="tcp://<hostname>:<port>" name="DC1"> <mirror/> </amqp-connection> </broker-connections><broker-connections> <amqp-connection uri="tcp://<hostname>:<port>" name="DC1"> <mirror/> </amqp-connection> </broker-connections>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <hostname>- 다른 브로커 인스턴스의 호스트 이름입니다.
<port>- 다른 호스트에서 브로커가 사용하는 포트입니다.
첫 번째 브로커의 모든 메시지는 두 번째 브로커에 미러링되지만 미러가 생성되기 전에 존재하는 메시지는 미러링되지 않습니다.
첫 번째 브로커가 메시지를 동기적으로 미러링하여 재해 복구를 위해 미러링된 브로커가 최신 상태인지 확인하려면 다음 예와 같이 브로커의
amqp-connection요소에sync=true특성을 설정합니다.동기 미러링을 사용하려면 브로커가 미러링된 브로커로 보낸 메시지를 두 브로커의 볼륨에 동시에 작성해야 합니다. 두 브로커 모두에서 쓰기 작업이 완료되면 소스 브로커는 쓰기 요청이 완료되고 제어가 클라이언트에 반환됩니다.
<broker-connections> <amqp-connection uri="tcp://<hostname>:<port>" name="DC2"> <mirror sync="true"/> </amqp-connection> </broker-connections><broker-connections> <amqp-connection uri="tcp://<hostname>:<port>" name="DC2"> <mirror sync="true"/> </amqp-connection> </broker-connections>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고예를 들어 미러링된 브로커에서 쓰기 요청을 완료할 수 없는 경우, 브로커를 사용할 수 없는 경우 가장 최근 쓰기 요청을 완료하는 데 미러를 사용할 수 있을 때까지 클라이언트 연결이 차단됩니다.
다음과 같은 추가 기능을 구성할 수도 있습니다.
-
queue-removal: 큐 또는 address-removal 이벤트가 전송되는지 여부를 지정합니다. 기본값은true입니다. -
message-acknowledgments: 메시지를 보낼지 여부를 지정합니다. 기본값은true입니다. -
queue-creation: 큐 생성 또는 주소 생성 이벤트가 전송되었는지 여부를 지정합니다. 기본값은true입니다.
참고예제의 브로커 연결 이름인
DC1은$ACTIVEMQ_ARTEMIS_MIRROR_mirror라는 큐를 생성하는 데 사용됩니다. 큐가 해당 브로커에 표시되지 않는 경우에도 해당 브로커가 해당 메시지를 수락하도록 구성되어 있는지 확인합니다.-
두 번째 브로커의
broker.xml파일에broker-connections요소를 생성합니다. 예를 들면 다음과 같습니다.<broker-connections> <amqp-connection uri="tcp://<hostname>:<port>" name="DC2"> <mirror/> </amqp-connection> </broker-connections><broker-connections> <amqp-connection uri="tcp://<hostname>:<port>" name="DC2"> <mirror/> </amqp-connection> </broker-connections>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 두 번째 브로커가 메시지를 동기적으로 미러링하려면 브로커의
amqp-connection요소에서sync=true특성을 설정합니다. 예를 들면 다음과 같습니다.<broker-connections> <amqp-connection uri="tcp://<hostname>:<port>" name="DC2"> <mirror sync="true"/> </amqp-connection> </broker-connections><broker-connections> <amqp-connection uri="tcp://<hostname>:<port>" name="DC2"> <mirror sync="true"/> </amqp-connection> </broker-connections>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 브로커 연결에서는 15.6절. “다중 사이트 내결함성 메시징 시스템에서 클라이언트 구성” 설명된 지침을 사용하여 클라이언트를 구성합니다. 공유 스토리지가 없습니다.
Red Hat은 미러 구성에서 두 브로커의 메시지를 사용하는 클라이언트 애플리케이션을 지원하지 않습니다. 클라이언트가 두 브로커 모두에서 메시지를 사용하지 않도록 하려면 브로커 중 하나에서 클라이언트 수락을 비활성화합니다.
17장. 브리징 브로커 링크 복사링크가 클립보드에 복사되었습니다!
브리지는 두 브로커를 연결하고 한 브로커에서 다른 브로커로 메시지를 전달하는 방법을 제공합니다.
다음 브릿지를 사용할 수 있습니다.
- 코어
-
한 브로커에 배포된 코어 브릿지를 보여줍니다. 이 브릿지는 로컬 대기열의 메시지를 사용하여 두 번째 브로커의 주소로 전달합니다. 브로커 설치의 <
install_dir> /examples/features/standard/디렉터리에 있는core-bridge예제를 참조하십시오. - 미러
- 참조 16장. 브로커 연결을 사용하여 다중 사이트 내결함성 메시징 시스템 구성
- 발신자 및 수신자
- 참조 17.1절. “브로커 연결에 대한 발신자 및 수신자 구성”
- peer
- 참조 17.2절. “브로커 연결에 대한 피어 구성”
Core 브릿지의 broker.xml 요소는 브리지 입니다. 다른 브리징 기술은 < broker-connection> 요소를 사용합니다.
17.1. 브로커 연결에 대한 발신자 및 수신자 구성 링크 복사링크가 클립보드에 복사되었습니다!
broker.xml 의 <broker -connections> 섹션에 발신자 또는 수신자 브로커 연결 요소를 생성하여 브로커 를 다른 브로커에 연결할 수 있습니다.
발신자 의 경우 브로커는 다른 브로커에 메시지를 보내는 큐에 메시지 소비자를 생성합니다.
수신자 의 경우 브로커는 다른 브로커의 메시지를 수신하는 주소에 메시지 생산자를 생성합니다.
두 요소 모두 메시지 브리지 역할을 합니다. 그러나 메시지를 처리하는 데 필요한 추가 오버헤드는 없습니다. 발신자 및 수신자는 브로커의 다른 소비자 또는 생산자처럼 작동합니다.
특정 대기열은 발신자 또는 수신자가 구성할 수 있습니다. 와일드카드 표현식을 사용하여 발신자 및 수신자를 특정 주소 또는 주소 집합 과 일치시킬 수 있습니다. 발신자 또는 수신자를 구성할 때 다음 속성을 설정할 수 있습니다.
-
address-match: 와일드카드 표현식을 사용하여 발신자 또는 수신자를 특정 주소 또는 주소 집합에 일치시킵니다. -
queue-name: 특정 큐의 발신자 또는 수신자를 구성합니다. 주소 표현식 사용:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 대기열 이름 사용:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
수신자는 이미 존재하는 로컬 큐와만 일치할 수 있습니다. 따라서 수신자가 사용 중인 경우 대기열이 로컬로 미리 생성되어 있는지 확인합니다. 그렇지 않으면 브로커가 원격 대기열 및 주소와 일치시킬 수 없습니다.
이 전송 및 수신 루프를 생성하므로 동일한 대상을 가진 발신자와 수신자를 생성하지 마십시오.
17.2. 브로커 연결에 대한 피어 구성 링크 복사링크가 클립보드에 복사되었습니다!
브로커는 AMQ Interconnect 인스턴스에 연결하고 브로커가 해당 라우터에 구성된 지정된 AMQP 방법 주소에 대한 저장 및 전달 대기열 역할을 하도록 지시하는 피어로 구성할 수 있습니다. 이 시나리오에서는 클라이언트가 경로 주소를 사용하여 메시지를 전송 및 수신하기 위해 라우터에 연결하고, 라우터는 이러한 메시지를 브로커의 큐로 또는 큐에서 라우팅합니다.
이 피어 구성은 브로커의 브로커 연결 구성에 일치하는 각 대상에 대한 발신자 및 수신자 쌍을 생성합니다. 이러한 쌍에는 라우터가 브로커와 협업할 수 있는 구성이 포함되어 있습니다. 이 기능을 사용하면 라우터에서 연결을 시작하고 자동 링크를 생성할 필요가 없습니다.
가능한 라우터 구성에 대한 자세한 내용은 AMQ Interconnect 라우터 사용을 참조하십시오.
피어 구성을 사용하면 발신자와 수신자가 있을 때와 동일한 속성이 있습니다. 예를 들어 대기열이 시작되는 큐가 있는 큐가 일치하는 라우터 waypoint 주소에 대한 스토리지 역할을 하는 구성은 다음과 같습니다.
라우터에 일치하는 주소 waypoint 구성이 있어야 합니다. 이렇게 하면 브로커가 연결되는 특정 라우터를 waypoints로 처리하도록 지시합니다. 예를 들어 다음 접두사 기반 라우터 주소 구성을 참조하십시오.
address {
prefix: queue
waypoint: yes
}
address {
prefix: queue
waypoint: yes
}
이 옵션에 대한 자세한 내용은 AMQ Interconnect 라우터 사용을 참조하십시오.
피어 옵션을 사용하여 다른 브로커에 직접 연결하지 마십시오. 이 옵션을 사용하여 다른 브로커에 연결하면 모든 메시지를 즉시 사용할 준비가 되어 전송 및 수신의 무한 에코를 생성합니다.
18장. 로깅 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker는 Apache Log4j 2 로깅 유틸리티를 사용하여 메시지 로깅을 제공합니다. 브로커를 설치할 때 < broker_instance_dir> /etc/log4j2.properties 파일에 기본 Log4j 2 구성이 있습니다. 기본 구성을 사용하면 로거는 콘솔과 파일에 모두 기록합니다.
AMQ Broker에서 사용할 수 있는 로거는 다음 표에 표시되어 있습니다.
| 로거 | 설명 |
|---|---|
| org.apache.activemq.artemis.core.server | 브로커 코어를 로그 |
| org.apache.activemq.artemis.journal | 로그 journal 호출 |
| org.apache.activemq.artemis.utils | 로그 유틸리티 호출 |
| org.apache.activemq.artemis.jms | 로그 JMS 호출 |
| org.apache.activemq.artemis.integration.bootstrap | 로그 부트스트랩 호출 |
| org.apache.activemq.audit.base | 모든 ScanSetting 오브젝트 방법에 대한 액세스를 기록합니다. |
| org.apache.activemq.audit.message | 메시지 프로덕션, 사용 및 메시지 검색과 같은 메시지 작업을 기록합니다. |
| org.apache.activemq.audit.resource | 관리 콘솔 또는 AMQ Broker 관리 콘솔에서 인증 이벤트, 브로커 리소스 생성 또는 삭제, 관리 콘솔에서 메시지 검색 |
18.1. 로깅 수준 변경 링크 복사링크가 클립보드에 복사되었습니다!
apache.activemq.artemis.core 행에서 각 로거에 대한 로깅 수준을 구성할 수 있습니다.
.server 로거예에 표시된 대로 로거 이름 뒤에 있는 < 로거 이름>.level
logger.artemis_server.name=org.apache.activemq.artemis.core.server logger.artemis_server.level=INFO
logger.artemis_server.name=org.apache.activemq.artemis.core.server
logger.artemis_server.level=INFO
감사 로거의 기본 로깅 수준은 OFF 이므로 로깅이 비활성화됩니다. AMQ Broker에서 사용할 수 있는 다른 로거의 기본 로깅 수준은 INFO 입니다. Log4j 2에서 사용 가능한 로깅 수준에 대한 자세한 내용은 Log4j 2 설명서를 참조하십시오.
18.2. 감사 로깅 활성화 링크 복사링크가 클립보드에 복사되었습니다!
활성화할 수 있는 감사 로거 세 개, 즉 기본 감사 로거, 메시지 감사 로거 및 리소스 감사 로거를 사용할 수 있습니다.
- 기본 감사 로거(org.apache.activemq.audit.base)
- 주소 및 큐의 생성 및 삭제와 같은 모든 ScanSetting 개체 메서드에 대한 액세스 를 기록합니다. 로그는 이러한 작업이 성공했는지 실패했는지를 나타내지 않습니다.
- 메시지 감사 로거(org.apache.activemq.audit.message)
- 프로덕션, 소비 또는 메시지 검색과 같은 메시지 관련 브로커 작업을 기록합니다.
- 리소스 감사 로거(org.apache.activemq.audit.resource)
- 클라이언트, 경로, AMQ Broker 관리 콘솔의 인증 성공 또는 실패를 기록합니다. 또한 작업 또는 관리 콘솔에서 큐 생성, 업데이트 또는 삭제를 로깅하고 관리 콘솔에서 메시지 검색도 기록합니다.
서로 독립적으로 각 감사 로거를 활성화할 수 있습니다. 기본적으로 로깅 수준은 OFF 로 설정됩니다. 즉, 각 감사 로거에 대해 로깅이 비활성화됩니다. 감사 로거 중 하나를 활성화하려면 로깅 수준을 OFF 에서 INFO 로 변경합니다. 예를 들면 다음과 같습니다.
logger.audit_base = INFO, audit_log_file
logger.audit_base = INFO, audit_log_file
INFO 는 logger.org.apache.activemq.audit.base,logger.org.apache.activemq.audit.message, logger.org.apache.activemq.audit.resource 감사 로거에 사용할 수 있는 유일한 로깅 수준입니다.
메시지 감사 로거는 브로커의 성능 집약적 경로에서 실행됩니다. 로거를 활성화하면 브로커가 높은 메시징 부하에서 실행되는 경우 특히 브로커의 성능에 부정적인 영향을 미칠 수 있습니다. 높은 처리량이 필요한 메시징 시스템에서 감사 로깅을 활성화하지 않는 것이 좋습니다.
18.3. 클라이언트 또는 임베디드 서버 로깅 링크 복사링크가 클립보드에 복사되었습니다!
클라이언트에서 로깅을 사용하도록 설정하려면 10.0.0.1F4J facade를 지원하는 애플리케이션에 로깅 구현을 포함해야 합니다. Maven을 사용하는 경우 Log4j 2에 대해 다음 종속 항목을 추가합니다.
classpath에 log4j2.properties 파일에 Log4j 2 구성을 제공할 수 있습니다. 또는 log4j2.configurationFile 시스템 속성을 사용하여 사용자 지정 구성 파일을 지정할 수 있습니다. 예를 들면 다음과 같습니다.
-Dlog4j2.configurationFile=file:///path/to/custom-log4j2-config.properties
-Dlog4j2.configurationFile=file:///path/to/custom-log4j2-config.properties
다음은 클라이언트의 log4j2.properties 파일의 예입니다.
18.4. AMQ Broker 플러그인 지원 링크 복사링크가 클립보드에 복사되었습니다!
AMQ는 사용자 정의 플러그인을 지원합니다. 플러그인을 사용하여 디버그 로그를 통해서만 사용할 수 있는 다양한 이벤트 유형에 대한 정보를 기록할 수 있습니다. 여러 플러그인을 함께 등록, 연결 및 실행할 수 있습니다. 플러그인은 등록 순서, 즉 등록된 첫 번째 플러그인이 항상 먼저 실행됩니다.
사용자 지정 플러그인을 생성하고 ActiveMQServerPlugin 인터페이스를 사용하여 구현할 수 있습니다. 이 인터페이스를 사용하면 플러그인이 classpath에 있고 브로커에 등록됩니다. 모든 인터페이스 메서드가 기본적으로 구현되므로 구현해야 하는 필수 동작만 추가해야 합니다.
18.4.1. 클래스 경로에 플러그인 추가 링크 복사링크가 클립보드에 복사되었습니다!
관련 .jar 파일을 <broker _instance_dir> /lib 디렉터리에 추가하여 사용자 정의 생성 브로커 플러그인을 브로커 런타임에 추가합니다.
임베디드 시스템을 사용하는 경우 포함된 애플리케이션의 일반 클래스 경로에 .jar 파일을 배치합니다.
18.4.2. 플러그인 등록 링크 복사링크가 클립보드에 복사되었습니다!
broker.xml 구성 파일에 broker-plugins 요소를 추가하여 플러그인을 등록해야 합니다. 속성 하위 요소를 사용하여 플러그인 구성 값을 지정할 수 있습니다. 이러한 속성은 플러그인이 인스턴스화된 후 플러그인의 init(Map<String, String>) 작업으로 읽고 전달됩니다.
18.4.3. 프로그래밍 방식으로 플러그인 등록 링크 복사링크가 클립보드에 복사되었습니다!
플러그인을 프로그래밍 방식으로 등록하려면 registerBrokerPlugin() 메서드를 사용하여 플러그인의 새 인스턴스를 전달합니다. 아래 예제에서는 UserPlugin 플러그인 등록을 보여줍니다.
Configuration config = new ConfigurationImpl(); config.registerBrokerPlugin(new UserPlugin());
Configuration config = new ConfigurationImpl();
config.registerBrokerPlugin(new UserPlugin());
18.4.4. 특정 이벤트 로깅 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 AMQ 브로커는 특정 브로커 이벤트를 기록하기 위해 LoggingActiveMQServerPlugin 플러그인을 제공합니다. LoggingActiveMQServerplugin 플러그인은 기본적으로 주석 처리되어 있으며 정보를 기록하지 않습니다.
다음 표에서는 각 플러그인 속성에 대해 설명합니다. 이벤트를 기록하려면 구성 속성 값을 true 로 설정합니다.
| 속성 | 설명 |
|
| 연결이 생성되거나 삭제될 때 정보를 기록합니다. |
|
| 세션을 만들거나 닫을 때 정보를 기록합니다. |
|
| 소비자가 생성 또는 닫을 때 정보를 기록합니다. |
|
| 메시지가 소비자에게 전달되고 메시지가 소비자가 승인할 때 정보를 기록합니다. |
|
| 메시지가 주소로 전송되었을 때 및 메시지가 브로커 내에서 라우팅될 때 정보를 기록합니다. |
|
| 큐가 생성 또는 삭제될 때, 메시지가 만료될 때, 브리지를 배포할 때, 중요한 오류가 발생할 때 정보를 기록합니다. |
|
| 위의 모든 이벤트에 대한 정보를 기록합니다. |
연결 이벤트를 기록하도록 LoggingActiveMQServerPlugin 플러그인을 구성하려면 broker.xml 구성 파일에서 < broker-plugins > 섹션의 주석을 제거합니다. 모든 이벤트의 값은 주석 처리된 기본 예제에서 true 로 설정됩니다.
< broker-plugins > 섹션 내에서 구성 매개변수를 변경하는 경우 브로커를 다시 시작하여 구성 업데이트를 다시 로드해야 합니다. 이러한 설정 변경 사항은 configuration-file-refresh-period 설정을 기반으로 다시 로드 되지 않습니다.
로그 수준이 INFO 로 설정되면 이벤트가 발생한 후 항목이 기록됩니다. 로그 수준이 DEBUG 로 설정된 경우 이벤트 전과 후에 모두 로그 항목이 생성됩니다(예: beforeCreateConsumer() 및 afterCreateConsumer ()). 로그 수준이 DEBUG 로 설정되면 로거는 가능한 경우 알림에 대한 자세한 정보를 기록합니다.
부록 A. 어셉터 및 커넥터 구성 매개변수 링크 복사링크가 클립보드에 복사되었습니다!
아래 표에는 Netty 네트워크 연결을 구성하는 데 사용되는 사용 가능한 일부 매개 변수가 자세히 설명되어 있습니다. 매개변수 및 해당 값은 연결 문자열의 URI에 추가됩니다. 자세한 내용은 네트워크 연결에서 어셉터 및 커넥터 구성을 참조하십시오. 각 표에는 어셉터 또는 커넥터와 함께 사용할 수 있는지 아니면 둘 다와 함께 사용할 수 있는지의 이름별 매개변수가 나열됩니다. 예를 들어 acceptors만 일부 매개변수를 사용할 수 있습니다.
모든 Netty 매개변수는 org.apache.activemq.artemis.core.remoting.impl.netty.TransportConstants 클래스에 정의되어 있습니다. 소스 코드는 고객 포털에서 다운로드할 수 있습니다.
| 매개변수 | with…을 사용합니다. | 설명 |
|---|---|---|
| batchDelay | 둘 다 |
수락자 또는 커넥터에 패킷을 쓰기 전에 브로커는 최대 |
| connectionsAllowed | 수락자 |
수락자가 허용하는 연결 수를 제한합니다. 이 제한에 도달하면 DEBUG 수준 메시지가 로그에 발행되고 연결이 거부됩니다. 사용 중인 클라이언트 유형에 따라 연결이 거부될 때 수행되는 작업이 결정됩니다. 기본값은 |
| directDeliver | 둘 다 |
메시지가 서버에 도착하고 대기 중인 소비자에게 전달되면 기본적으로 메시지가 도착한 것과 동일한 스레드에서 전달됩니다. 이로 인해 상대적으로 작은 메시지와 소수의 소비자가 있는 환경에서의 대기 시간을 단축하지만 전체 처리량과 확장성(특히 멀티 코어 머신에서)의 비용이 발생합니다. 가장 짧은 대기 시간과 처리량 감소를 원한다면 |
| handshake-timeout | 수락자 | 권한이 없는 클라이언트가 많은 수의 연결을 열고 열려 있도록 하는 것을 방지합니다. 각 연결에는 파일 처리가 필요하므로 다른 클라이언트에서 사용할 수 없는 리소스를 사용합니다. 이 제한 시간은 연결에서 인증하지 않고 리소스를 사용할 수 있는 시간을 제한합니다. 연결이 인증된 후 리소스 제한 설정을 사용하여 리소스 사용을 제한할 수 있습니다.
기본값은 시간 제한 값을 편집한 후 브로커를 다시 시작해야 합니다. |
| localAddress | 커넥터 | 원격 주소에 연결할 때 클라이언트가 사용할 로컬 주소를 지정합니다. 이는 일반적으로 애플리케이션 서버 또는 아웃바운드 연결에 사용되는 주소를 제어하기 위해 skopeo를 실행할 때 사용됩니다. local-address를 설정하지 않으면 커넥터에서 사용 가능한 로컬 주소를 사용합니다. |
| localPort | 커넥터 | 원격 주소에 연결할 때 클라이언트가 사용할 로컬 포트를 지정합니다. 일반적으로 Application Server 또는 아웃바운드 연결에 사용되는 포트를 제어하기 위해 skopeo를 실행할 때 사용됩니다. 기본값을 사용하는 경우 0인 경우 커넥터는 시스템에서 임시 포트를 선택하게 합니다. 유효한 포트는 0에서 65535 사이입니다. |
| nioRemotingThreads | 둘 다 |
NIO를 사용하도록 구성된 경우 브로커는 기본적으로 들어오는 패킷을 처리하기 위해 |
| tcpNoDelay | 둘 다 |
이것이 |
| tcpReceiveBufferSize | 둘 다 |
TCP 수신 버퍼의 크기(바이트)를 결정합니다. 기본값은 |
| tcpSendBufferSize | 둘 다 |
TCP 전송 버퍼의 크기를 바이트 단위로 결정합니다. 기본값은 TCP 버퍼 크기는 네트워크의 대역폭 및 대기 시간에 따라 조정되어야 합니다. 요약하면 TCP 전송/수신 버퍼 크기는 다음과 같이 계산되어야 합니다. buffer_size = 대역폭 * RTT.
여기서 대역폭은 초당 바이트 수이고 RTT(네트워크 왕복 시간)는 초 단위입니다. RTT는 빠른 네트워크의 경우 기본값에서 버퍼 크기를 늘릴 수 있습니다. |
| 매개변수 | with…을 사용합니다. | 설명 |
|---|---|---|
| httpClientIdleTime | 수락자 | 연결을 유지하기 위해 빈 HTTP 요청을 보내기 전에 클라이언트가 유휴 상태일 수 있는 시간입니다. |
| httpClientIdleScanPeriod | 수락자 | 유휴 상태의 클라이언트를 스캔하는 빈도(밀리초)입니다. |
| httpEnabled | 수락자 | 더 이상 필요하지 않습니다. 단일 포트가 지원되는 경우 브로커는 이제 HTTP가 사용되고 있는지 여부를 자동으로 탐지하고 구성합니다. |
| httpRequiresSessionId | 둘 다 |
|
| httpResponseTime | 수락자 | 연결을 유지하기 위해 빈 HTTP 응답을 보내기 전에 서버가 대기하는 시간입니다. |
| httpServerScanPeriod | 수락자 | 응답이 필요한 클라이언트를 스캔하는 빈도(밀리초)입니다. |
| 매개변수 | with…을 사용합니다. | 설명 |
|---|---|---|
| enabledCipherSuites | 둘 다 | SSL 통신에 사용되는 암호화 제품군의 쉼표로 구분된 목록입니다.
클라이언트 애플리케이션에서 지원하는 가장 안전한 암호화 제품군을 지정합니다. 브로커와 클라이언트에 공통되는 암호화 제품군의 쉼표로 구분된 목록을 지정하거나 암호화 모음을 지정하지 않는 경우 브로커와 클라이언트는 사용할 암호화 제품군을 서로 협상합니다. 지정할 암호화 모음을 모르는 경우 먼저 디버그 모드에서 실행 중인 클라이언트와 broker-client 연결을 설정하여 브로커와 클라이언트 모두에 공통된 암호화 제품군을 확인할 수 있습니다. 그런 다음 브로커에서
사용 가능한 암호화 제품군은 브로커 및 클라이언트에서 사용하는 TLS 프로토콜 버전에 따라 다릅니다. 브로커를 업그레이드한 후 기본 TLS 프로토콜 버전이 변경되면 브로커와 클라이언트가 공통 암호화 제품군을 사용할 수 있도록 이전 TLS 프로토콜 버전을 선택해야 할 수 있습니다. 자세한 내용은 |
| enabledProtocols | 둘 다 | SSL 통신에 사용되는 TLS 프로토콜 버전의 쉼표로 구분된 목록입니다. TLS 프로토콜 버전을 지정하지 않으면 브로커는 JVM의 기본 버전을 사용합니다.
브로커가 JVM의 기본 TLS 프로토콜 버전을 사용하고 브로커를 업그레이드한 후 해당 버전이 변경되면 브로커 및 클라이언트에서 사용하는 TLS 프로토콜 버전이 호환되지 않을 수 있습니다. 이후 TLS 프로토콜 버전을 사용하는 것이 좋지만, |
| forceSSLParameters | 커넥터 |
커넥터에서 매개변수로 설정된 SSL 설정을 JVM 시스템 속성(Java
유효한 값은 |
| keyStorePassword | 둘 다 | 수락자에서 사용하는 경우 이는 서버 측 키 저장소의 암호입니다.
커넥터에 사용하는 경우 클라이언트 측 키 저장소의 암호입니다. 이는 양방향 SSL(즉, 상호 인증)을 사용하는 경우에만 커넥터와 관련이 있습니다. 이 값은 서버에서 구성할 수 있지만 클라이언트에서 다운로드하여 사용합니다. 클라이언트가 서버에 설정된 암호와 다른 암호를 사용해야 하는 경우 사용자 지정 |
| keyStorePath | 둘 다 | 수락자에서 사용하는 경우 이 경로는 서버의 인증서를 보유한 서버의 SSL 키 저장소에 대한 경로입니다(자 자체 서명 또는 권한에 의해 서명됨).
커넥터에 사용되는 경우 클라이언트 인증서를 보유하는 클라이언트 측 SSL 키 저장소의 경로입니다. 이는 양방향 SSL(즉, 상호 인증)을 사용하는 경우에만 커넥터와 관련이 있습니다. 이 값은 서버에 구성되어 있지만 클라이언트가 다운로드하여 사용합니다. 클라이언트가 서버에 설정된 것과 다른 경로를 사용해야 하는 경우 사용자 지정 |
| keyStoreAlias | 둘 다 | 어셉터에 사용되는 경우 이 별칭은 키 저장소에서 연결할 때 클라이언트에 제공할 키의 별칭입니다. 커넥터에 사용되는 경우 클라이언트가 연결할 때 키 저장소의 키 별칭입니다. 이는 2방향 SSL, 즉 상호 인증을 사용하는 경우 커넥터에만 관련이 있습니다. |
| needClientAuth | 수락자 |
이 어셉터에 연결하는 클라이언트에게 양방향 SSL이 필요함을 알립니다. 유효한 값은 |
| sslEnabled | 둘 다 |
SSL을 활성화하려면 |
| trustManagerFactoryPlugin | 둘 다 |
이는
브로커의 Java 클래스 경로에 지정된 플러그인을 배치해야합니다. 기본적으로 classpath의 일부이므로 < |
| trustStorePassword | 둘 다 | 수락자에서 사용하는 경우 이는 서버 측 신뢰 저장소의 암호입니다. 이는 양방향 SSL(즉, 상호 인증)을 사용하는 경우에만 수락자와 관련이 있습니다.
커넥터에 사용하는 경우 클라이언트 측 트러스트 저장소의 암호입니다. 이 값은 서버에서 구성할 수 있지만 클라이언트에서 다운로드하여 사용합니다. 클라이언트가 서버에 설정된 것과 다른 암호를 사용해야 하는 경우 사용자 지정 |
| sniHost | 둘 다 |
수락자에서 사용하는 경우
들어오는 연결에
커넥터에 사용하면 SSL 연결의 |
| sslProvider | 둘 다 |
이 옵션은 OpenSSL을 통해 지원되지만 JDK 공급자를 통해 지원되지 않는 특수 암호화 통신 곡선 조합을 사용하려는 경우 유용할 수 있습니다. |
| trustStorePath | 둘 다 | 어셉터에 사용되는 경우 이는 서버가 신뢰하는 모든 클라이언트의 키를 보유하는 서버 측 SSL 키 저장소의 경로입니다. 이는 양방향 SSL(즉, 상호 인증)을 사용하는 경우에만 수락자와 관련이 있습니다.
커넥터에 사용되는 경우 클라이언트가 신뢰하는 모든 서버의 공개 키를 보유하는 클라이언트 측 SSL 키 저장소의 경로입니다. 이 값은 서버에서 구성할 수 있지만 클라이언트에서 다운로드하여 사용합니다. 클라이언트가 서버에 설정된 것과 다른 경로를 사용해야 하는 경우 사용자 지정 |
| useDefaultSslContext | 커넥터 |
커넥터가
이 매개 변수가 |
| verifyHost | 둘 다 | 커넥터에 사용하는 경우 서버의 SSL 인증서의 CN 또는 Subject Alternative Name 값이 연결되어 있는지 확인하기 위해 연결되는 호스트 이름과 비교됩니다. 이는 단방향과 양방향 SSL 모두에 유용합니다. 수락자에 사용되는 경우 연결 클라이언트의 SSL 인증서의 CN 또는 Subject Alternative Name 값이 해당 호스트 이름과 비교하여 일치하는지 확인합니다. 이는 양방향 SSL에만 유용합니다.
유효한 값은 |
| wantClientAuth | 수락자 |
이 어셉터에 연결하는 클라이언트에는 양방향 SSL이 요청되었지만 필수는 아닙니다. 유효한 값은
속성 |
부록 B. 주소 설정 Configurationknative 링크 복사링크가 클립보드에 복사되었습니다!
아래 표에는 address-setting 의 모든 구성 요소가 나열되어 있습니다. 일부 요소는 DEPRECATED로 표시됩니다. 잠재적인 문제를 방지하려면 제안된 교체를 사용하십시오.
| 이름 | 설명 |
|---|---|
| address-full-policy |
참고 BLOCK 정책은 flow control이 있기 때문에 AMQP, OpenECDHEre 및 Core Protocol 프로토콜에만 작동합니다. |
| auto-create-addresses |
클라이언트가 메시지를 보내거나 큐가 없는 주소에 매핑된 큐의 메시지를 사용하려고 할 때 주소를 자동으로 생성할지 여부입니다. 기본값은 |
| auto-create-dead-letter-resources |
브로커가 배달되지 않은 메시지를 수신하기 위해 배달 못 한 주소와 큐를 자동으로 생성하는지 여부를 지정합니다. 기본값은
매개 변수가 |
| auto-create-jms-queues |
DEPRECATED: 대신 |
| auto-create-jms-topics |
DEPRECATED: 대신 |
| auto-create-queues |
클라이언트가 메시지를 보낼 때 큐를 자동으로 만들지 아니면 대기열의 메시지를 사용하려고 할지 여부입니다. 기본값은 |
| auto-delete-addresses |
브로커에 더 이상 큐가 없는 경우 자동 생성된 주소를 삭제할지 여부입니다. 기본값은 |
| auto-delete-jms-queues |
DEPRECATED: 대신 |
| auto-delete-jms-topics |
DEPRECATED: 대신 |
| auto-delete-queues |
큐에 소비자와 메시지가 없는 경우 자동 생성된 큐를 삭제할지 여부입니다. 기본값은 |
| config-delete-addresses | 구성 파일이 다시 로드되면 이 설정은 구성 파일에서 삭제된 주소(및 해당 대기열)를 처리하는 방법을 지정합니다. 다음 값을 지정할 수 있습니다.
|
| config-delete-queues | 구성 파일이 다시 로드되면 이 설정은 구성 파일에서 삭제된 큐를 처리하는 방법을 지정합니다. 다음 값을 지정할 수 있습니다.
|
| dead-letter-address | 브로커가 dead 메시지를 보내는 주소입니다. |
| dead-letter-queue-prefix |
브로커가 자동으로 생성된 dead letter 큐의 이름에 적용되는 접두사입니다. 기본값은 |
| dead-letter-queue-suffix | 브로커가 자동 생성된 dead letter 큐에 적용되는 접미사입니다. 기본값은 정의되지 않습니다(즉 브로커는 접미사를 적용하지 않음). |
| default-address-routing-type |
자동 생성 주소에 사용되는 라우팅 유형입니다. 기본값은 |
| default-max-consumers |
이 큐에서 허용되는 최대 소비자 수입니다. 기본값은 |
| default-purge-on-no-consumers |
소비자가 없는 경우 큐의 콘텐츠를 제거할지 여부입니다. 기본값은 |
| default-queue-routing-type |
자동 생성 큐에 사용되는 라우팅 유형입니다. 기본값은 |
| enable-metrics |
Prometheus 플러그인과 같은 구성된 지표 플러그인에서 일치하는 주소 또는 주소 집합에 대한 지표를 수집하는지 여부를 지정합니다. 기본값은 |
| expiry-address | 만료된 메시지를 수신할 주소입니다. |
| expiry-delay |
기본 만료 시간을 사용하여 메시지에 사용할 만료 시간(밀리초)을 정의합니다. 기본값은 |
| last-value-queue |
큐에서 마지막 값만 사용하는지 여부입니다. 기본값은 |
| management-browse-page-size |
관리 리소스에서 검색할 수 있는 메시지 수입니다. 기본값은 |
| max-delivery-attempts |
How many times to attempt to send a message before sending to dead letter address. 기본값은 |
| max-redelivery-delay | redelivery-delay의 최대값(밀리초)입니다. |
| max-size-bytes |
이 주소의 최대 메모리 크기(바이트)입니다. |
| max-size-bytes-reject-threshold |
|
| message-counter-history-day-limit |
이 주소에 대한 메시지 카운터 기록을 유지하는 날짜입니다. 기본값은 |
| page-size-bytes |
페이지 크기(바이트)입니다. 또한 |
| redelivery-delay |
취소된 메시지를 다시 전달하기 전에 대기하는 시간(밀리초)입니다. 기본값은 |
| redelivery-delay-multiplier |
redelivery-delay 매개변수에 적용할 곱셈입니다. 기본값은 |
| redistribution-delay |
메시지를 재배포하기 전에 마지막 소비자가 대기열에서 종료 된 후 밀리초 동안 대기하는 시간을 정의합니다. 기본값은 |
| send-to-dla-on-no-route |
|
| slow-consumer-check-period |
느린 사용자의 수를 확인하는 빈도입니다. 기본값은 |
| slow-consumer-policy |
느린 소비자가 식별될 때 발생하는 상황을 결정합니다. 유효한 옵션은 |
| slow-consumer-threshold |
소비자가 느리기 전에 허용되는 메시지 소비의 최소 비율입니다. 초당 메시지로 측정합니다. 기본값은 |
부록 C. 클러스터 연결 구성 CloudEvent 링크 복사링크가 클립보드에 복사되었습니다!
아래 표에는 클러스터 연결 의 모든 구성 요소가 나열되어 있습니다.
| 이름 | 설명 |
|---|---|
| address |
각 클러스터 연결은
참고 동일한 메시지를 두 개 이상의 클러스터 연결 간에 분배하여 중복될 수 있기 때문에 중복되는 주소(예: "europe" 및 "europe.news")가 여러 클러스터 연결이 없어야 합니다. |
| call-failover-timeout |
장애 조치(failover) 시도 중에 호출될 때 사용합니다. 기본값은 |
| call-timeout |
클러스터 연결을 통해 패킷이 전송되고 차단 호출인 경우 |
| check-period |
클러스터 연결이 다른 브로커에서 ping을 수신하지 못한지 확인하기 위한 검사 간격(밀리초)입니다. 기본값은 |
| confirmation-window-size |
연결된 브로커에서 확인을 보내는 데 사용되는 창의 크기(바이트)입니다. 브로커가 |
| connector-ref |
올바른 클러스터 토폴로지를 갖도록 클러스터의 다른 브로커로 전송할 |
| connection-ttl |
클러스터의 특정 브로커에서 메시지 수신을 중지하면 클러스터 연결이 유지되는 시간을 결정합니다. 기본값은 |
| discovery-group-ref |
클러스터의 다른 브로커와 통신하는 데 사용할 |
| initial-connect-attempts |
시스템에서 처음에 클러스터의 브로커 연결을 시도하는 횟수를 설정합니다. max-retry가 달성되면 이 브로커는 영구적으로 중단된 것으로 간주되며 시스템은 이 브로커로 메시지를 라우팅하지 않습니다. 기본값은 |
| max-hops |
체인을 통해 다른 브로커와 간접적으로 연결할 수 있는 브로커에 메시지를 로드 밸런싱하도록 브로커를 구성합니다. 이를 통해 메시지 부하 분산을 계속 제공하는 동시에 더 복잡한 토폴로지를 사용할 수 있습니다. 기본값은 |
| max-retry-interval |
재시도 횟수(밀리초)의 최대 지연입니다. 기본값은 |
| message-load-balancing |
클러스터의 다른 브로커 간에 메시지를 분산할지 여부 및 방법을 결정합니다.
|
| min-large-message-size |
메시지 크기(바이트)가 |
| notification-attempts |
클러스터에 연결할 때 클러스터 연결이 자체적으로 브로드캐스트해야 하는 횟수를 설정합니다. 기본값은 |
| notification-interval |
클러스터에 연결할 때 클러스터 연결이 자체적으로 브로드캐스트해야 하는 빈도를 설정합니다. 기본값은 |
| producer-window-size |
생산자 흐름이 클러스터 연결을 제어하는 크기(바이트)입니다. 기본적으로 비활성화되어 있지만 클러스터에서 실제로 큰 메시지를 사용하는 경우 값을 설정할 수 있습니다. 값 |
| reconnect-attempts |
시스템이 클러스터의 브로커에 다시 연결하려고 하는 횟수를 설정합니다. max-retry가 달성되면 이 브로커는 영구적으로 중단된 것으로 간주되며 시스템은 이 브로커에 메시지 라우팅을 중지합니다. 기본값은 |
| retry-interval | 재시도 시도 사이의 간격(밀리초)을 결정합니다. 클러스터 연결이 생성되고 대상 브로커가 시작되지 않았거나 부팅 중인 경우 다른 브로커의 클러스터 연결은 백업될 때까지 대상에 연결을 다시 시도합니다. 이 매개변수는 선택 사항입니다. 기본값은 500밀리초입니다. |
| retry-interval-multiplier |
재연결 시도마다 |
| Use-duplicate-detection |
클러스터 연결은 브리지를 사용하여 브로커를 연결하고 브리지를 구성하여 전달되는 각 메시지에 중복 ID 속성을 추가할 수 있습니다. 브리지의 대상 브로커가 충돌하고 복구되면 메시지가 소스 브로커에서 다시 지정될 수 있습니다. |
부록 D. 명령줄 툴 링크 복사링크가 클립보드에 복사되었습니다!
AMQ Broker에는 메시징 저널을 관리할 수 있도록 CLI(명령줄 인터페이스) 도구 세트가 포함되어 있습니다. 아래 표에는 각 도구의 이름과 설명이 나열되어 있습니다.
| 툴 | 설명 |
|---|---|
| exp | 특수하고 독립적인 XML 형식을 사용하여 메시지 데이터를 내보냅니다. |
| imp |
|
| data | 저널 레코드에 대한 보고서를 출력하고 데이터를 압축합니다. |
| encode | String으로 인코딩된 저널의 내부 형식을 표시합니다. |
| decode | 인코인에서 내부 저널 형식을 가져옵니다. |
각 툴에 사용할 수 있는 전체 명령 목록은 help 매개변수 다음에 툴 이름을 사용합니다. 아래 예에서 CLI 출력에는 사용자가 ./artemis 도움말 데이터를 입력한 후 데이터 도구에 사용 가능한 모든 명령이 나열됩니다.
툴의 각 명령을 실행하는 방법에 대한 자세한 내용은 툴의 도움말을 사용할 수 있습니다. 예를 들어 CLI는 사용자가 ./artemis 도움말 명령에 대한 자세한 정보를 나열합니다.
데이터를 출력 한 후 data print
부록 E. 메시징 jert 구성 링크 복사링크가 클립보드에 복사되었습니다!
아래 표에는 AMQ Broker 메시징 저널과 관련된 모든 구성 요소가 나열되어 있습니다.
| 이름 | 설명 |
|---|---|
| journal-directory |
메시지 저널이 있는 디렉터리입니다. 기본값은 < 최상의 성능을 위해 저널은 디스크 헤드 이동을 최소화하기 위해 자체 물리 볼륨에 있어야 합니다. 저널이 다른 파일(예: 바인딩 저널, 데이터베이스 또는 트랜잭션 조정기)을 작성할 수 있는 다른 프로세스와 공유되는 볼륨에 있는 경우 디스크 헤드는 이러한 파일 간에 빠르게 이동할 수 있으므로 이러한 파일 간에 빠르게 이동할 수 있으므로 성능이 크게 저하될 수 있습니다. SAN을 사용할 때 각 저널 인스턴스에 자체 LUN(logical unit)이 지정되어야 합니다. |
| create-journal-dir |
|
| journal-type |
유효한 값은
|
| journal-sync-transactional |
|
| journal-sync-non-transactional |
|
| journal-file-size |
각 저널 파일의 크기(바이트)입니다. 기본값은 |
| journal-min-files | 브로커를 시작할 때 브로커를 사전 생성하는 최소 파일 수입니다. 파일은 기존 메시지 데이터가 없는 경우에만 미리 생성됩니다. 큐에 steady 상태가 포함될 것으로 예상되는 데이터의 양에 따라 예상되는 총 데이터 양과 일치하도록 이 파일 수를 조정해야 합니다. |
| journal-pool-files |
시스템은 필요한 만큼 파일을 생성합니다. 그러나 파일을 회수하면
기본값은 |
| journal-max-io | IO 큐에 있을 수 있는 최대 쓰기 요청 수를 한 번에 제어합니다. 큐가 가득 차면 공간이 확보될 때까지 쓰기가 차단됩니다.
NIO를 사용할 때 이 값은 항상 |
| journal-buffer-timeout | 버퍼가 플러시되는 시기에 대한 타임아웃을 제어합니다. AIO는 일반적으로 NIO보다 더 높은 플러쉬 비율로 유지될 수 있으므로 시스템은 NIO와 AIO 모두에 대해 다른 기본값을 유지합니다.
NIO의 기본값은 참고 시간 초과 값을 늘리면 기본값을 사용하여 처리량과 대기 시간 간에 균형을 맞추도록 선택되기 때문에 대기 시간 대신 시스템 처리량을 늘릴 수 있습니다. |
| journal-buffer-size |
AIO의 시간 초과 버퍼의 크기입니다. 기본값은 |
| journal-compact-min-files |
브로커가 저널을 압축하기 전에 필요한 최소 파일 수입니다. 압축 알고리즘은 적어도 참고
값을 |
| journal-compact-percentage |
압축을 시작할 임계값입니다. |
부록 F. 추가 복제 고가용성 구성 ScanSetting 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에는 복제 고가용성 구성 섹션에 설명되지 않은 추가 ha-policy 구성 요소가 나열되어 있습니다. 이러한 요소에는 대부분의 일반적인 사용 사례에 충분한 기본 설정이 있습니다.
| 이름 | 사용됨 | 설명 |
|---|---|---|
| check-for-live-server | 임베디드 브로커 조정 |
마스터 브로커로 구성된 브로커에만 적용됩니다. 원래 마스터 브로커가 시작할 때 자체 서버 ID를 사용하여 다른 라이브 브로커에 대해 클러스터를 확인할지 여부를 지정합니다. 원래 마스터 브로커로 돌아가려면 |
| cluster-name | 임베디드 브로커 및 ZooKeeper 조정 | 복제에 사용할 클러스터 구성의 이름입니다. 이 설정은 여러 클러스터 연결을 구성하는 경우에만 필요합니다. 구성된 경우 클러스터에 연결할 때 이 이름으로 클러스터 구성이 사용됩니다. 설정되지 않으면 구성에 정의된 첫 번째 클러스터 연결이 사용됩니다. |
| initial-replication-sync-timeout | 임베디드 브로커 및 ZooKeeper 조정 |
복제 브로커가 필요한 모든 데이터를 수신했음을 확인하기 위해 복제본이 초기 복제 프로세스가 완료될 때 대기하는 시간입니다. 이 속성의 기본값은 10.0.0.1 참고: 이 간격 동안 다른 저널 관련 작업이 차단됩니다. |
| max-saved-replicated-journals-size | 임베디드 브로커 및 ZooKeeper 조정 |
이는 백업 브로커에만 적용됩니다. 백업 브로커가 유지하는 백업 저널 파일 수를 지정합니다. 이 값에 도달하면 브로커는 가장 오래된 저널 파일을 삭제하여 각 새 백업 저널 파일을 만듭니다. 이 속성의 기본값은 |
부록 G. broker 속성 링크 복사링크가 클립보드에 복사되었습니다!
다음은 XML 구성을 사용하는 대신 내부 java 구성 빈에 직접 적용할 수 있는 AMQ Broker 속성 목록입니다.
criticalAnalyzerCheckPeriod
type: long
Default: 0
XML 이름: critical-analyzer-check-period
설명: 기간은 critical-analyzer-timeout의 절반으로 설정되고 런타임에 계산됩니다.
pageMaxConcurrentIO
type: int
기본값: 5
XML 이름: page-max-concurrent-io
설명: 페이징 중에 허용되는 최대 동시 읽기 수입니다.
messageCounterSamplePeriod
type: long
Default: 10000
XML 이름: message-counter-sample-period
설명: 메시지 카운터에 사용할 샘플 기간(ms)입니다.
networkCheckNIC
유형: 문자열
기본값:
XML 이름: network-check-nic
설명: 주소를 확인하는 데 사용할 네트워크 인터페이스 카드 이름입니다.
globalMaxSize
type: long
default: -1
XML 이름: global-max-size
설명: 크기(바이트)는 모든 주소가 생성되는 경우 전체 정책에 입력됩니다. "K", "Mb", "MiB", "GB" 등과 같은 바이트 표기법을 지원합니다.
journalFileSize
type: int
기본값: 10485760
XML 이름: journal-file-size
설명: 각 저널 파일의 크기(바이트 단위)입니다. 바이트 표기법을 지원합니다(예: "K", "Mb", "MiB", "GB").
configurationFileRefreshPeriod
type: long
Default: 5000
XML 이름: configuration-file-refresh-period
설명: 구성 파일의 수정 여부를 확인하는 빈도(ms)입니다.
diskScanPeriod
type: int
Default: 5000
XML name: disk-scan-period
Description: frequency, in milliseconds to scan the disks for full disks.
journalRetentionDirectory
유형: 문자열
기본값:
XML 이름: journal-retention-directory
설명: 저널 보존 메시지 및 보존 구성을 저장할 디렉터리입니다.
networkCheckPeriod
type: long
default: 10000
XML 이름: network-check-period
설명: 빈도(밀리초)는 네트워크가 up인지 확인합니다.
journalBufferSize_AIO
type: int
기본값: 501760
XML 이름: journal-buffer-size
설명: 저널의 내부 버퍼의 크기(바이트)입니다. 바이트 표기법을 지원합니다(예: "K", "Mb", "MiB", "GB").
NetworkCheckURLList
유형: 문자열
기본값:
XML 이름: network-check-URL-list
설명: 브로커를 계속 확인해야 하는지 확인하는 데 사용할 쉼표로 구분된 URL 목록입니다.
networkCheckTimeout
type: int
Default: 1000
XML name: network-check-timeout
설명: ping에 사용할 시간(밀리초)입니다.
pageSyncTimeout
type: int
기본값:
XML 이름: page-sync-timeout
설명: 페이지 동기화에 사용되는 시간(나노초)입니다. 정확한 기본값은 저널이 ASYNCIO인지 NIO인지에 따라 다릅니다.
journalPoolFiles
type: int
기본값: -1
XML 이름: journal-pool-files
설명: pre-create할 저널 파일의 수입니다.
criticalAnalyzer
type: boolean
Default: true
XML 이름: critical-analyzer
설명: 중요 경로에 대한 응답 시간을 분석하고 브로커 로그, 종료 또는 중지를 결정합니다.
readWholePage
type: boolean
Default: false
XML 이름: read-w plot-page
설명: 페이지 캐시가 제거된 후 메시지를 가져오는 동안 전체 페이지를 읽을지 여부를 지정합니다.
maxDiskUsage
type: int
기본값: 90
XML 이름: max-disk-usage
설명: 시스템 차단 또는 실패 전 디스크 사용량의 최대 백분율입니다.
globalMaxMessages
type: long
default: -1
XML 이름: global-max-ECDHE
설명: 모든 주소가 구성된 주소 전체 정책에 입력되기 전에 메시지 수를 입력합니다. 이 명령은 global-max-size와 함께 작동하며, 두 제한에 도달하면 구성된 주소 전체 정책이 실행됩니다.
internalNamingPrefix
유형: 문자열
기본값:
XML 이름: internal-naming-prefix
설명: Artemis는 내부 대기열과 주소를 사용하여 특정 동작을 구현합니다. 이러한 대기열 및 주소 앞에는 기본적으로 "$.activemq.internal"이 접두사로 지정되어 사용자 이름 보호를 사용하여 이름이 충돌하지 않도록 합니다. 이 값은 유효한 Artemis 주소로 설정하여 재정의할 수 있습니다.
journalFileOpenTimeout
type: int
기본값: 5
XML 이름: journal-file-open-timeout
설명: 시간(초)은 시간 초과 및 실패 전에 새 iPXE 파일을 열 때 대기하는 시간입니다.
journalCompactPercentage
type: int
기본값: 30
XML 이름: journal-compact-percentage
설명: 저널 압축을 고려할 라이브 데이터의 백분율입니다.
createBindingsDir
type: boolean
Default: true
XML 이름: create-bindings-dir
Description: true 값으로 인해 서버에서 시작 시 바인딩 디렉터리를 생성합니다.
suppressSessionNotifications
type: boolean
Default: false
XML 이름: suppress-session-notifications
설명: SESSION_CREATED 및 SESSION_CLOSED 알림을 억제할지 여부입니다. 알림 오버헤드를 줄이려면 true 로 설정합니다. 그러나 이러한 ID는 MQTT 클라이언트용 클러스터에서 고유한 클라이언트 ID 사용률을 적용하는 데 필요합니다.
journalBufferTimeout_AIO
type: int
기본값:
XML 이름: journal-buffer-timeout
설명: 저널의 내부 버퍼를 플러시하는 데 사용되는 시간 초과인 나노초입니다. 정확한 기본값은 저널이 ASYNCIO인지 NIO인지에 따라 다릅니다.
journalType
type: journalType
Default: ASYNCIO
XML 이름: journal-type
설명: 사용할 저널 유형입니다.
name
유형: 문자열
기본값:
XML 이름: 이름
설명: 노드 이름. 설정된 경우 토폴로지 알림에 사용됩니다.
networkCheckPingCommand
유형: 문자열
기본값:
XML 이름: network-check-ping-command
설명: IPV4 주소를 ping하는 데 사용되는 ping 명령입니다.
temporaryQueueNamespace
유형: 문자열
기본값:
XML 이름: temporary-queue-namespace
설명: 네임스페이스에서 임시 큐의 주소 설정을 검색하는 데 사용합니다.
pagingDirectory
type: String
Default: data/paging
XML 이름: paging-directory
Description: paged messages를 저장할 디렉터리입니다.
journalDirectory
유형: 문자열
기본값: data/journal
XML 이름: journal-directory
설명: 저널 파일을 저장하는 디렉터리입니다.
journalBufferSize_NIO
type: int
기본값: 501760
XML 이름: journal-buffer-size
설명: 저널의 내부 버퍼의 크기(바이트)입니다. 바이트 표기법을 지원합니다(예: "K", "Mb", "MiB", "GB").
journalDeviceBlockSize
type: Integer
기본값:
XML 이름: journal-device-block-size
설명: 장치에서 사용하는 크기(바이트)입니다. 일반적으로 fstat/st_blksize로 번역되며 이는 st_blksize로 반환된 값을 우회하는 방법입니다.
nodeManagerLockDirectory
유형: 문자열
기본값:
XML 이름: node-manager-lock-directory
설명: 노드 관리자 잠금 파일을 저장할 디렉터리입니다.
messageCounterMaxDayHistory
type: int
기본값: 10
XML 이름: message-counter-max-day-history
설명: 메시지 카운터 기록을 유지하는 일 수입니다.
largeMessagesDirectory
type: String
Default: data/largeECDHE
XML 이름: large-ECDHE-directory
설명: 대용량 메시지를 저장할 디렉터리입니다.
networkCheckPing6Command
유형: 문자열
기본값:
XML 이름: network-check-ping6-command
설명: IPV6 주소를 ping하는 데 사용되는 ping 명령.
memoryWarningThreshold
type: int
기본값: 25
XML 이름: memory-warning-threshold
설명: 경고가 생성되는 사용 가능한 메모리 백분율입니다.
mqttSessionScanInterval
type: long
default: 5000
XML 이름: mqtt-session-scan-interval
설명: 빈도(밀리초 단위)는 만료된 MQTT 세션을 스캔할 수 있습니다.
journalMaxAtticFiles
type: int
기본값:
XML 이름: journal-max-attic-files
설명:
journalSyncTransactional
type: boolean
Default: true
XML 이름: journal-sync-ECDHEal
설명: true 로 설정된 경우 클라이언트에 응답을 반환하기 전에 트랜잭션 데이터를 저널에 동기화할 때까지 기다립니다.
logJournalWriteRate
type: boolean
Default: false
XML 이름: log-journal-write-rate
설명: 저널 쓰기 비율과 관련된 메시지를 기록할지 여부를 지정합니다.
journalMaxIO_AIO
type: int
기본값:
XML 이름: journal-max-io
설명: 한 번에 AIO 큐에 있을 수 있는 최대 쓰기 요청 수입니다. AIO의 기본값은 500 이고 NIO의 경우 1 입니다.
messageExpiryScanPeriod
type: long
default: 30000
XML 이름: message-expiry-scan-period
설명: 빈도(밀리초)로, 만료된 메시지를 스캔합니다.
criticalAnalyzerTimeout
type: long
Default: 120000
XML 이름: critical-analyzer-timeout
설명: 중요한 경로의 타임아웃을 분석하는 데 사용되는 기본 시간 초과입니다.
messageCounterEnabled
type: boolean
Default: false
XML 이름: message-counter-enabled
Description: true 값은 메시지 카운터가 활성화됨을 의미합니다.
journalCompactMinFiles
type: int
기본값: 10
XML 이름: journal-compact-min-files
설명: 브로커가 압축을 시작하기 전에 데이터 파일의 최소 수입니다.
createJournalDir
type: boolean
Default: true
XML 이름: create-journal-dir
Description: true 값은 저널 디렉터리가 생성되었음을 의미합니다.
addressQueueScanPeriod
type: long
default: 30000
XML 이름: address-queue-scan-period
설명: 빈도(밀리초)를 입력하여 삭제해야 하는 주소 및 큐를 스캔합니다.
memoryMeasureInterval
type: long
Default: -1
XML name: memory-measure-interval
Description: 빈도(밀리초)에서 JVM 메모리를 샘플링합니다. 값 -1 은 메모리 샘플링을 비활성화합니다.
journalSyncNonTransactional
type: boolean
Default: true
XML 이름: journal-sync-non-ECDHEal
설명: true 인 경우 클라이언트에 응답을 반환하기 전에 비 트랜잭션 데이터가 저널에 동기화될 때까지 기다립니다.
connectionTtlCheckInterval
type: long
default: 2000
XML 이름: connection-ttl-check-interval
설명: 빈도(밀리초)를 사용하여 ttl 위반에 대한 연결을 확인합니다.
rejectEmptyValidatedUser
type: boolean
Default: false
XML 이름: reject-empty-validated-user
Description: true 인 경우 서버는 검증된 사용자가 없는 메시지를 허용하지 않습니다. JMS에서 이는 JMSXUserID 입니다.
journalMaxIO_NIO
type: int
기본값:
XML 이름: journal-max-io
설명: 한 번에 AIO 큐에 있을 수 있는 최대 쓰기 요청 수입니다. AIO의 기본값은 500 이고 NIO의 경우 1 입니다. 현재 broker 속성은 바이트 단위 정수 및 측정 방법만 지원합니다.
transactionTimeoutScanPeriod
type: long
Default: 1000
XML 이름: transaction-timeout-scan-period
설명: 빈도(밀리초)를 입력하여 시간 초과 트랜잭션을 스캔합니다.
systemPropertyPrefix
유형: 문자열
기본값:
XML 이름: system-property-prefix
설명: 구성에 대한 시스템 속성을 구문 분석하는 데 사용되는 접두사입니다.
transactionTimeout
type: long
default: 300000
XML 이름: transaction-timeout
설명: 생성 시간 후 트랜잭션이 리소스 관리자에서 제거되기 전의 기간(밀리초)입니다.
journalLockAcquisitionTimeout
type: long
default: -1
XML 이름: journal-lock-acquisition-timeout
설명: 빈도(밀리초)가 저널에서 파일 잠금을 받기를 기다릴 때까지 기다립니다.
journalBufferTimeout_NIO
type: int
기본값:
XML 이름: journal-buffer-timeout
설명: 저널의 내부 버퍼를 플러시하는 데 사용되는 시간 초과(나노초)입니다. 정확한 기본값은 저널이 ASYNCIO인지 NIO인지에 따라 다릅니다.
journalMinFiles
type: int
기본값: 2
XML 이름: journal-min-files
설명: 사전 생성할 저널 파일의 수입니다.
G.1. bridgeConfigurations 링크 복사링크가 클립보드에 복사되었습니다!
bridgeConfigurations.<name>.retryIntervalMultiplier
type: double
Default: 1
XML 이름: retry-interval-multiplier
설명: 연속 재시도 간격에 적용할 수 있습니다.
bridgeConfigurations.<name>.maxRetryInterval
type: long
default: 2000
XML 이름: max-retry-interval
설명: retry-interval-multiplier로 인해 재시도 간격 증가 제한.
bridgeConfigurations.<name>.filterString
유형: 문자열
기본값:
XML 이름: filter-string
설명:
bridgeConfigurations.<name>.connectionTTL
type: long
default: 60000
XML 이름: connection-ttl
설명: 클라이언트에서 데이터를 수신하지 않은 경우 연결을 유지하기 위한 기간입니다. 기간은 ping 기간보다 커야 합니다.
bridgeConfigurations.<name>.confirmationWindowSize
type: int
기본값: 1048576
XML 이름: confirmation-window-size
설명: 브리지가 확인 메시지를 보낸 후 수신된 바이트 수입니다. 바이트 표기법을 지원합니다(예: "K", "Mb", "MiB", "GB").
bridgeConfigurations.<name>.staticConnectors
type: List
기본값:
XML 이름: static-connectors
설명
bridgeConfigurations.<name>.reconnectAttemptsOnSameNode
type: int
기본값:
XML 이름: reconnect-attempts-on-same-node
설명
bridgeConfigurations.<name>.concurrency
type: int
기본값: 1
XML 이름: concurrency
설명: 동시 작업자 수 더 많은 작업자가 높은 대기 시간 네트워크에서 처리량을 높이는 데 도움이 될 수 있습니다. 기본값은 1입니다.
bridgeConfigurations.<name>.transformerConfiguration
유형: TransformerConfiguration
기본값:
XML 이름: transformer-configuration
설명
bridgeConfigurations.<name>.transformerConfiguration.className
유형: 문자열
기본값:
XML 이름: class-name
설명:
bridgeConfigurations.<name>.transformerConfiguration.properties
type: Map
기본:
XML 이름: 속성
설명: 변환기에 설정할 KEY/VALUE 쌍(예: properties.MY_PROPERTY=MY_VALUE)
bridgeConfigurations.<name>.password
유형: 문자열
기본값:
XML 이름: password
설명: 지정되지 않은 경우 cluster-password가 사용됩니다.
bridgeConfigurations.<name>.queueName
유형: 문자열
기본값:
XML 이름: queue-name
설명: 이 브리지가 사용하는 큐의 이름입니다.
bridgeConfigurations.<name>.forwardingAddress
유형: 문자열
기본값:
XML 이름: forwarding-address
설명: 전달할 주소. 생략하면 원래 주소가 사용됩니다.
bridgeConfigurations.<name>.routingType
type: ComponentConfigurationRoutingType
Default: PASS
XML name: routing-type
설명: 브리지 메시지의 라우팅 유형이 설정된 방법입니다.
bridgeConfigurations.<name>.name
유형: 문자열
기본값:
XML 이름: 이름
설명: 이 브릿지의 고유 이름입니다.
bridgeConfigurations.<name>.ha
type: boolean
Default: false
XML name: ha
Description: 이 브릿지에서 장애 조치(fail-over)를 지원하는지 여부를 지정합니다.
bridgeConfigurations.<name>.initialConnectAttempts
type: int
Default: -1
XML 이름: initial-connect-attempts
설명: 최대 초기 연결 시도 수 기본값 -1 은 제한이 없음을 의미합니다.
bridgeConfigurations.<name>.retryInterval
type: long
default: 2000
XML 이름: retry-interval
설명: 연속 재시도 간격(밀리초)입니다.
bridgeConfigurations.<name>.producerWindowSize
type: int
기본값: 1048576
XML 이름: producer-window-size
Description: Producer flow control. 바이트 표기법을 지원합니다(예: "K", "Mb", "MiB", "GB").
bridgeConfigurations.<name>.clientFailureCheckPeriod
type: long
Default: 30000
XML 이름: check-period
설명: 브릿지의 클라이언트가 서버에서 ping을 수신하지 못했는지 여부를 확인하는 간격(밀리초)입니다. 이 검사를 비활성화하려면 -1 값을 지정합니다.
bridgeConfigurations.<name>.discoveryGroupName
유형: 문자열
기본값:
XML 이름: discovery-group-ref
설명
bridgeConfigurations.<name>.user
유형: 문자열
기본값:
XML 이름: 사용자
설명: 사용자 이름. 지정하지 않으면 cluster-user가 사용됩니다.
bridgeConfigurations.<name>.useDuplicateDetection
type: boolean
Default: true
XML 이름: use-duplicate-detection
설명: 중복 탐지 헤더가 전달된 메시지에 삽입되는지 여부를 지정합니다.
bridgeConfigurations.<name>.minLargeMessageSize
type: int
Default: 102400
XML 이름: min-large-message-size
설명: 크기(바이트) 위의 경우 메시지가 큰 메시지로 간주됩니다. 큰 메시지는 여러 세그먼트에서 네트워크를 통해 전송됩니다. 바이트 표기법을 지원합니다(예: "K", "Mb", "MiB", "GB").
G.2. AMQPConnections 링크 복사링크가 클립보드에 복사되었습니다!
AMQPConnections.<name>.reconnectAttempts
type: int
Default: -1
XML 이름: reconnect-attempts
Description: 실패 후 재연결 시도 횟수
AMQPConnections.<name>.password
유형: 문자열
기본값:
XML 이름: password
설명: 연결에 사용되는 암호입니다. 지정하지 않으면 익명 연결이 시도됩니다.
AMQPConnections.<name>.retryInterval
type: int
Default: 5000
XML 이름: retry-interval
설명: 연속 재시도 간격(밀리초)입니다.
AMQPConnections.<name>.connectionElements
유형: AMQPMirrorBrokerConnectionanchor
기본값:
XML 이름: amqp-connection
설명: AMQP 브로커 연결에서 4 가지 유형: 1을 지원합니다. 미러 - 브로커는 다른 브로커에 AMQP 연결을 사용하고 메시지를 복제하고 전선을 통해 승인을 보냅니다. 2. 발신자 - 특정 큐에서 수신된 메시지가 다른 엔드포인트로 전송됩니다. 3. 수신자 - 브로커는 다른 끝점에서 메시지를 가져옵니다. 4. 피어 - 브로커는 메시지를 처리하는 방법을 알고있는 다른 끝점에 발신자와 수신자를 모두 만듭니다. 이는 현재 ApacheECDHE Dispatch에서 구현되고 있습니다. 현재는 미러 유형만 지원됩니다.
AMQPConnections.<name>.connectionElements.<name>.messageAcknowledgments
type: boolean
기본값:
XML 이름: message-acknowledgments
설명: true 인 경우 메시지 승인이 미러링됩니다.
AMQPConnections.<name>.connectionElements.<name>.queueRemoval
type: boolean
Default:
XML name: queue-removal
Description: 미러 큐가 주소 및 큐에 대한 이벤트를 삭제하는지 여부를 지정합니다.
AMQPConnections.<name>.connectionElements.<name>.addressFilter
유형: 문자열
기본값:
XML 이름: address-filter
설명: 미러가 소스 주소를 기반으로 대상 서버로 전달되는 이벤트를 결정하는 데 사용하는 필터를 지정합니다.
AMQPConnections.<name>.connectionElements.<name>.queueCreation
type: boolean
Default:
XML name: queue-creation
설명: 미러 큐가 주소 및 큐에 대한 이벤트를 생성하는지 여부를 지정합니다.
AMQPConnections.<name>.autostart
type: boolean
Default: true
XML 이름: 자동 시작
설명: 서버가 시작될 때 브로커 연결이 시작되었는지 여부를 지정합니다.
AMQPConnections.<이름>.user
유형: 문자열
기본값:
XML 이름: 사용자
설명: 연결에 사용되는 사용자 이름입니다. 지정하지 않으면 익명 연결이 시도됩니다.
AMQPConnections.<name>.uri
유형: 문자열
기본값:
XML 이름: uri
설명: AMQP 연결의 URI입니다.
G.3. divertConfiguration 링크 복사링크가 클립보드에 복사되었습니다!
divertConfiguration.transformerConfiguration
유형: TransformerConfiguration
기본값:
XML 이름: transformer-configuration
설명
divertConfiguration.transformerConfiguration.className
유형: 문자열
기본값:
XML 이름: class-name
설명:
divertConfiguration.transformerConfiguration.properties
type: Map
기본:
XML 이름: 속성
설명: 변환기에 설정할 KEY/VALUE 쌍(예: …properties.MY_PROPERTY=MY_VALUE)입니다.
divertConfiguration.filterString
유형: 문자열
기본값:
XML 이름: filter-string
설명:
divertConfiguration.routingName
type: String
Default:
XML name: routing-name
Description: the routing name for the divert.
divertConfiguration.address
type: String
Default:
XML name: address
Description: 이 주소가 변환될 주소입니다.
divertConfiguration.forwardingAddress
유형: 문자열
기본값:
XML 이름: forwarding-address
설명: 전달 주소
divertConfiguration.routingType
type: ComponentConfigurationRoutingType( MULTICAST ANYCAST STRIP PASS )
Default:
XML name: routing-type
Description: how the routing-type on the diverted messages.
divertConfiguration.exclusive
type: boolean
Default: false
XML name: exclusive
description: 이 값이 배타적인지 여부를 지정합니다.
G.4. addressSettings 링크 복사링크가 클립보드에 복사되었습니다!
addressSettings.<address>.configDeleteDiverts
type: DeletionPolicy( OFF FORCE )
Default:
XML name: config-delete-addresses
설명:
addressSettings.<address>.expiryQueuePrefix
유형: SimpleString
기본값:
XML 이름: expiry-queue-prefix
설명:
addressSettings.<address>.defaultConsumerWindowSize
type: int
기본값:
XML 이름: default-consumer-window-size
설명:
addressSettings.<address>.maxReadPageBytes
type: int
기본값:
XML 이름: max-read-page-bytes
설명:
addressSettings.<address>.deadLetterQueuePrefix
유형: SimpleString
기본값:
XML 이름: dead-letter-queue-prefix
설명:
addressSettings.<address>.defaultGroupRebalancePauseDispatch
type: boolean
기본값:
XML 이름: default-group-rebalance-pause-dispatch
설명:
addressSettings.<address>.autoCreateAddresses
type: 부울
기본값:
XML 이름: auto-create-addresses
설명
addressSettings.<address>.slowConsumerThreshold
type: long
기본값:
XML 이름: slow-consumer-threshold
설명:
addressSettings.<address>.managementMessageAttributeSizeLimit
type: int
기본값:
XML 이름: management-message-attribute-size-limit
설명:
addressSettings.<address>.autoCreateExpiryResources
type: boolean
기본값:
XML 이름: auto-create-expiry-resources
설명:
addressSettings.<address>.pageSizeBytes
type: int
기본값:
XML 이름: page-size-bytes
설명
addressSettings.<address>.minExpiryDelay
type: Long
기본값:
XML 이름: min-expiry-delay
설명
addressSettings.<address>.defaultConsumersBeforeDispatch
type: Integer
기본값:
XML 이름: default-consumers-before-dispatch
설명:
addressSettings.<address>.expiryQueueSuffix
유형: SimpleString
기본값:
XML 이름: expiry-queue-suffix
설명:
addressSettings.<address>.configDeleteQueues
type: DeletionPolicy( OFF FORCE )
Default:
XML name: config-delete-queues
설명:
addressSettings.<address>.enableIngressTimestamp
type: boolean
기본값:
XML 이름: enable-ingress-timestamp
설명:
addressSettings.<address>.autoDeleteCreatedQueues
type: 부울
기본값:
XML 이름: auto-delete-created-queues
설명:
addressSettings.<address>.expiryAddress
유형: SimpleString
기본값:
XML 이름: expiry-address
설명
addressSettings.<address>.managementBrowsePageSize
type: int
기본값:
XML 이름: management-browse-page-size
설명:
addressSettings.<address>.autoDeleteQueues
type: 부울
기본값:
XML 이름: auto-delete-queues
설명
addressSettings.<address>.retroactiveMessageCount
type: long
기본값:
XML 이름: retroactive-message-count
설명
addressSettings.<address>.maxExpiryDelay
type: Long
기본값:
XML 이름: max-expiry-delay
설명
addressSettings.<address>.maxDeliveryAttempts
type: int
기본값:
XML 이름: max-delivery-attempts
설명:
addressSettings.<address>.defaultGroupFirstKey
유형: SimpleString
기본값:
XML 이름: default-group-first-key
설명:
addressSettings.<address>.slowConsumerCheckPeriod
type: long
기본값:
XML 이름: slow-consumer-check-period
설명:
addressSettings.<address>.defaultPurgeOnNoConsumers
type: 부울
기본값:
XML 이름: default-purge-on-no-consumers
설명
addressSettings.<address>.defaultLastValueKey
type: SimpleString
기본값:
XML 이름: default-last-value-key
설명
addressSettings.<address>.autoCreateQueues
type: 부울
기본값:
XML 이름: auto-create-queues
설명:
addressSettings.<address>.defaultExclusiveQueue
type: 부울
기본값:
XML 이름: default-exclusive-queue
설명
addressSettings.<address>.defaultMaxConsumers
type: Integer
기본값:
XML 이름: default-max-consumers
설명:
addressSettings.<address>.defaultQueueRoutingType
type: RoutingType( MULTICAST ANYCAST )
기본값:
XML 이름: default-queue-routing-type
설명
addressSettings.<address>.messageCounterHistoryDayLimit
type: int
기본값:
XML 이름: message-counter-history-day-limit
설명
addressSettings.<address>.defaultGroupRebalance
type: boolean
기본값:
XML 이름: default-group-rebalance
설명
addressSettings.<address>.defaultAddressRoutingType
type: RoutingType( MULTICAST ANYCAST )
기본값:
XML 이름: default-address-routing-type
설명
addressSettings.<address>.maxSizeBytesRejectThreshold
type: long
기본값:
XML 이름: max-size-bytes-reject-threshold
설명:
addressSettings.<address>.pageCacheMaxSize
type: int
기본값:
XML 이름: page-cache-max-size
설명
addressSettings.<address>.autoCreateDeadLetterResources
type: boolean
Default:
XML name: auto-create-dead-letter-resources
설명:
addressSettings.<address>.maxRedeliveryDelay
type: long
기본값:
XML 이름: max-redelivery-delay
설명:
addressSettings.<address>.configDeleteAddresses
type: DeletionPolicy
Default:
XML name: config-delete-addresses
설명:
addressSettings.<address>.deadLetterAddress
유형: SimpleString
기본값:
XML 이름: dead-letter-address
설명
addressSettings.<address>.autoDeleteQueuesMessageCount
type: long
기본값:
XML 이름: auto-delete-queues-message-count
설명:
addressSettings.<address>.autoDeleteAddresses
type: 부울
기본값:
XML 이름: auto-delete-addresses
설명
addressSettings.<address>.addressFullMessagePolicy
type: AddressFullMessagePolicy
Default:
XML name: address-full-message-policy
설명:
addressSettings.<address>.maxSizeBytes
type: long
기본값:
XML 이름: max-size-bytes
설명
addressSettings.<address>.defaultDelayBeforeDispatch
type: Long
기본값:
XML 이름: default-delay-before-dispatch
설명:
addressSettings.<address>.redistributionDelay
type: long
기본값:
XML 이름: redistribution-delay
설명
addressSettings.<address>.maxSizeMessages
type: long
기본값:
XML 이름: max-size-ECDHE
설명:
addressSettings.<address>.redeliveryMultiplier
type: double
기본값:
XML 이름: redelivery-multiplier
설명
addressSettings.<address>.defaultRingSize
type: long
기본값:
XML 이름: default-ring-size
설명
addressSettings.<address>.defaultLastValueQueue
type: boolean
기본값:
XML 이름: default-last-value-queue
설명
addressSettings.<address>.slowConsumerPolicy
유형: SlowConsumerPolicy( KILL NOTIFY )
기본값:
XML 이름: slow-consumer-policy
설명:
addressSettings.<address>.redeliveryCollisionAvoidanceFactor
type: double
기본값:
XML 이름: redelivery-collision-avoidance-factor
설명
addressSettings.<address>.autoDeleteQueuesDelay
type: long
기본값:
XML 이름: auto-delete-queues-delay
설명:
addressSettings.<address>.autoDeleteAddressesDelay
type: long
기본값:
XML 이름: auto-delete-addresses-delay
설명:
addressSettings.<address>.expiryDelay
유형: Long
기본값:
XML 이름: expiration-delay
설명:
addressSettings.<address>.enableMetrics
type: boolean
기본값:
XML 이름: enable-metrics
설명
addressSettings.<address>.sendToDLAOnNoRoute
type: boolean
기본값:
XML 이름: send-to-l-a-on-no-route
설명
addressSettings.<address>.slowConsumerThresholdMeasurementUnit
유형: SlowConsumerThresholdMeasurementUnit( MESSAGES_PER_SECOND MESSAGES_PER_MINUTE MESSAGES_PER_PER_DAY )
기본값:
XML 이름: slow-consumer-threshold-measurement
설명:
addressSettings.<address>.redeliveryDelay
type: long
기본값:
XML 이름: redelivery-delay
설명
addressSettings.<address>.deadLetterQueueSuffix
유형: SimpleString
기본값:
XML 이름: dead-letter-queue-suffix
설명:
addressSettings.<address>.defaultNonDestructive
type: boolean
기본값:
XML 이름: default-non-destructive
설명
G.5. federationConfigurations 링크 복사링크가 클립보드에 복사되었습니다!
federationConfigurations.<name>.transformerConfigurations
유형: FederationTransformerConfiguration
기본값:
XML 이름: 변환기
설명: 선택적 변환기 구성.
federationConfigurations.<이름>.transformerConfigurations.<이름>.transformerConfiguration
type: TransformerConfiguration
기본값:
XML 이름: 변환기
설명: 사용자 지정 변환기를 추가하여 메시지를 수정할 수 있습니다.
federationConfigurations.<이름>.transformerConfigurations.<이름>.transformerConfiguration.<name>.className
유형: 문자열
기본값:
XML 이름: class-name
설명: 변환자 구현의 클래스 이름입니다.
federationConfigurations.<이름>.transformerConfigurations.<이름>.transformerConfiguration.<name>.properties
type: Map
기본:
XML 이름: 속성
설명: 변환기에 설정할 KEY/VALUE 쌍(예: …properties.MY_PROPERTY=MY_VALUE)입니다.
federationConfigurations.<name>.queuePolicies
type: FederationQueuePolicyConfiguration
기본값:
XML 이름: queue-policy
설명
federationConfigurations.<name>.queuePolicies.<name>.priorityAdjustment
type: Integer
Default:
XML name: priority-adjustment
설명: 소비자가 연결되면 우선 순위를 사용하여 업스트림 소비자를 생성하지만 로컬 소비자가 원격 소비자보다 먼저 부하를 분산하도록 조정됩니다.
federationConfigurations.<name>.queuePolicies.<name>.excludes
type: Matcher
Default:
XML name: exclude
Description: List of queue matches to exclude.
federationConfigurations.<이름>.queuePolicies.<이름>.excludes.<name>.queueMatch
유형: 문자열
기본값:
XML 이름: queue-match
설명: 적용할 큐 일치 패턴입니다. 없는 경우 모든 큐가 일치합니다.
federationConfigurations.<name>.queuePolicies.<name>.transformerRef
유형: 문자열
기본값:
XML 이름: transformer-ref
설명: 페더레이션 전송 시 메시지를 변환하도록 구성하려는 변환기의 참조 이름입니다.
federationConfigurations.<name>.queuePolicies.<name>.includes
type: Matcher
Default:
XML name: queue-match
설명:
federationConfigurations.<이름>.queuePolicies.<이름>.excludes.<name>.queueMatch
유형: 문자열
기본값:
XML 이름: queue-match
설명: 적용할 큐 일치 패턴입니다. 없는 경우 모든 큐가 일치합니다.
federationConfigurations.<name>.queuePolicies.<name>.includeFederated
type: boolean
Default:
XML name: include-federated
Description: 값을 false 로 설정하면 구성이 이미 손상된 소비자(즉, 페더레이션 큐의 소비자)를 다시 페더레이션하지 않습니다. 이렇게 하면 대칭 또는 클로즈 루프 토폴로지에서 페더레이션되지 않은 소비자 및 메시지가 시스템 전체에서 무한히 순환되는 상황을 방지할 수 있습니다.
federationConfigurations.<name>.upstreamConfigurations
유형: FederationUpstreamConfiguration
기본값:
XML 이름: 업스트림
설명:
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration
type: FederationConnectionConfiguration
기본값:
XML 이름: connection-configuration
설명: 스트림 연결 구성.
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.priorityAdjustment
type: int
기본값:
XML 이름: priority-adjustment
설명:
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.retryIntervalMultiplier
type: double
Default: 1
XML 이름: retry-interval-multiplier
설명: retry-interval에 적용할 곱셈입니다.
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.shareConnection
type: boolean
Default: false
XML 이름: share-connection
설명: true 로 설정하면 동일한 브로커에 대해 구성된 다운스트림 및 업스트림 연결이 있는 경우 동일한 연결이 공유됩니다.
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.maxRetryInterval
type: long
Default: 2000
XML 이름: max-retry-interval
Description: retry-interval의 최대 값입니다.
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.connectionTTL
type: long
기본값:
XML 이름: connection-t-t-l
설명
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.circuitBreakerTimeout
type: long
Default: 30000
XML 이름: circuit-breaker-timeout
설명: 이 연결에서 장애 조치(fail-over)를 지원하는지 여부를 지정합니다.
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.callTimeout
type: long
Default: 30000
XML name: call-timeout
Description: The duration to wait for a reply.
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.staticConnectors
type: List
기본값:
XML 이름: static-connectors
설명: 커넥터를 통해 구성된 커넥터 참조 목록입니다.
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.reconnectAttempts
type: int
Default: -1
XML 이름: reconnect-attempts
Description: 실패 후 재연결 시도 횟수
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.password
유형: 문자열
기본값:
XML 이름: password
설명. 지정하지 않으면 페더레이션 암호가 사용됩니다.
federationConfigurations.<name>.upstreamConfigurations.<name>.connectionConfiguration.callFailoverTimeout
type: long
default: -1
XML 이름: call-failover-timeout
설명: 장애 조치 중 응답을 대기하는 기간입니다. 값 -1 은 제한이 없음을 의미합니다.
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.hA
type: boolean
기본값:
XML 이름: h-a
설명:
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.initialConnectAttempts
type: int
Default: -1
XML 이름: initial-connect-attempts
설명: 연결 시도 횟수
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.retryInterval
type: long
default: 500
XML 이름: retry-interval
설명: 연속 재시도 간격(밀리초)입니다.
federationConfigurations.<name>.upstreamConfigurations.<name>.connectionConfiguration.clientFailureCheckPeriod
type: long
기본값:
XML 이름: client-failure-check-period
설명:
federationConfigurations.<이름>.upstreamConfigurations.<이름>.connectionConfiguration.username
유형: 문자열
기본값:
XML 이름: 사용자 이름
설명:
federationConfigurations.<name>.upstreamConfigurations.<name>.policyRefs
type: Collection
기본값:
XML 이름: policy-refs
설명:
federationConfigurations.<name>.upstreamConfigurations.<name>.staticConnectors
type: List
기본값:
XML 이름: static-connectors
설명: 커넥터를 통해 구성된 커넥터 참조 목록입니다.
federationConfigurations.<name>.downstreamConfigurations
type: FederationDownstreamConfiguration
기본값:
XML 이름: 다운스트림
설명
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration
type: FederationConnectionConfiguration
기본값:
XML 이름: connection-configuration
설명: 스트림 연결 구성.
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.priorityAdjustment
type: int
기본값:
XML 이름: priority-adjustment
설명:
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.retryIntervalMultiplier
type: double
Default: 1
XML 이름: retry-interval-multiplier
설명: retry-interval에 적용할 곱셈입니다.
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.shareConnection
type: boolean
Default: false
XML 이름: share-connection
설명: true 로 설정하면 동일한 브로커에 대해 구성된 다운스트림 및 업스트림 연결이 있는 경우 동일한 연결이 공유됩니다.
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.maxRetryInterval
type: long
Default: 2000
XML 이름: max-retry-interval
Description: retry-interval의 최대 값입니다.
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.connectionTTL
type: long
기본값:
XML 이름: connection-t-t-l
설명
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.circuitBreakerTimeout
type: long
Default: 30000
XML 이름: circuit-breaker-timeout
설명: 이 연결이 장애 조치 지원 여부를 지정합니다.
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.callTimeout
type: long
Default: 30000
XML name: call-timeout
Description: The duration to wait for a reply.
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.staticConnectors
type: List
기본값:
XML 이름: static-connectors
설명: 커넥터를 통해 구성된 커넥터 참조 목록입니다.
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.reconnectAttempts
type: int
Default: -1
XML 이름: reconnect-attempts
Description: 실패 후 재연결 시도 횟수
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.password
유형: 문자열
기본값:
XML 이름: password
설명. 지정하지 않으면 페더레이션 암호가 사용됩니다.
federationConfigurations.<name>.downstreamConfigurations.<name>.connectionConfiguration.callFailoverTimeout
type: long
default: -1
XML 이름: call-failover-timeout
설명: 장애 조치 중 응답을 대기하는 기간입니다. 값 -1 은 제한이 없음을 의미합니다.
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.hA
type: boolean
기본값:
XML 이름: h-a
설명:
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.initialConnectAttempts
type: int
Default: -1
XML 이름: initial-connect-attempts
설명: 연결 시도 횟수
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.retryInterval
type: long
default: 500
XML 이름: retry-interval
설명: 연속 재시도 사이의 기간(밀리초)입니다.
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.clientFailureCheckPeriod
type: long
기본값:
XML 이름: client-failure-check-period
설명:
federationConfigurations.<이름>.downstreamConfigurations.<이름>.connectionConfiguration.username
유형: 문자열
기본값:
XML 이름: 사용자 이름
설명:
federationConfigurations.<name>.downstreamConfigurations.<name>.policyRefs
type: Collection
기본값:
XML 이름: policy-refs
설명:
federationConfigurations.<이름>.downstreamConfigurations.<이름>.staticConnectors
type: List
기본값:
XML 이름: static-connectors
설명: 커넥터를 통해 구성된 커넥터 참조 목록입니다.
federationConfigurations.<name>.federationPolicys
type: FederationPolicy
기본값:
XML 이름: policy-set
설명:
federationConfigurations.<name>.addressPolicies
type: FederationAddressPolicyConfiguration
기본값:
XML 이름: address-policy
설명
federationConfigurations.<name>.addressPolicies.<name>.autoDeleteMessageCount
type: Long
기본값:
XML 이름: auto-delete-message-count설명: 해당 대기열을 자동으로 삭제하기 전에 동적으로 생성된 원격 큐에 계속 있을 수 있는 최대 메시지 수입니다.
federationConfigurations.<name>.addressPolicies.<name>.enableDivertBindings
type: 부울
기본값:
XML 이름: enable-divert-bindings
설명: true 로 설정하면 바인딩을 요청으로 수신 대기할 수 있습니다. 주소 정책의 포함된 주소와 일치하는 주소가 있는 중단 바인딩이 있는 경우 변환 주소의 전달 주소와 일치하는 모든 큐 바인딩이 수요가 생성됩니다. 기본값은 false입니다.
federationConfigurations.<이름>.addressPolicies.<이름>.includes.{NAME}.addressMatch
type: matcher
기본값:
XML 이름: include
설명:
federationConfigurations.<name>.addressPolicies.<name>.maxHops
type: int
기본값:
XML 이름: max-hops
설명: 메시지가 통합하는 홉 수입니다.
federationConfigurations.<name>.addressPolicies.<name>.transformerRef
유형: 문자열
기본값:
XML 이름: transformer-ref
설명: 페더레이션 전송 시 메시지를 변환하도록 구성하려는 변환기의 참조 이름입니다.
federationConfigurations.<name>.addressPolicies.<name>.autoDeleteDelay
type: Long
기본값:
XML 이름: auto-delete-delay
설명: 다운스트림 브로커의 연결이 끊어진 후 업스트림 큐를 자동으로 삭제할 수 있습니다.
federationConfigurations.<name>.addressPolicies.<name>.autoDelete
type: boolean
Default:
XML name: auto-delete
Description: 주소 페더레이션의 경우 다운스트림은 업스트림 주소에서 영구 대기열을 동적으로 생성합니다. 다운스트림 연결이 끊어지고 delay 및 message count 매개변수가 충족되면 업스트림 큐가 삭제되는지를 지정합니다.
federationConfigurations.<name>.addressPolicies.<name>.excludes.{NAME}.addressMatch
type: matcher
기본값:
XML 이름: include
설명:
G.6. clusterConfigurations 링크 복사링크가 클립보드에 복사되었습니다!
clusterConfigurations.<name>.retryIntervalMultiplier
type: double
Default: 1
XML 이름: retry-interval-multiplier
설명: retry-interval에 적용할 곱셈입니다.
clusterConfigurations.<name>.maxRetryInterval
type: long
Default: 2000
XML 이름: max-retry-interval
Description: retry-interval의 최대 값입니다.
clusterConfigurations.<name>.address
유형: 문자열
기본값:
XML 이름: 주소
설명: 이 클러스터 연결이 적용되는 주소의 이름입니다.
clusterConfigurations.<name>.maxHops
type: int
기본값: 1
XML 이름: max-hops
설명: 클러스터 토폴로지가 전파되는 최대 홉 수입니다.
clusterConfigurations.<name>.connectionTTL
type: long
default: 60000
XML 이름: connection-ttl
설명: 클라이언트에서 데이터를 수신하지 않은 경우 연결을 유지하기 위한 기간입니다.
clusterConfigurations.<name>.clusterNotificationInterval
type: long
Default: 1000
XML 이름: notification-interval
설명: 클러스터 연결이 클러스터에 존재를 알리는 간격입니다.
clusterConfigurations.<name>.confirmationWindowSize
type: int
기본값: 1048576
XML 이름: confirmation-window-size
설명: 서버에서 데이터를 확인하는 데 사용되는 창의 크기(바이트)입니다. 바이트 표기법을 지원합니다(예: "K", "Mb", "MiB", "GB").
clusterConfigurations.<name>.callTimeout
type: long
Default: 30000
XML name: call-timeout
Description: The duration to wait for a reply.
clusterConfigurations.<name>.staticConnectors
type: List
기본값:
XML 이름: static-connectors
설명: 커넥터 참조 이름 목록입니다.
clusterConfigurations.<name>.clusterNotificationAttempts
type: int
기본값: 2
XML 이름: notification-attempts
설명: 이 클러스터 연결이 클러스터에 존재 여부를 알리려는 횟수입니다.
clusterConfigurations.<name>.allowDirectConnectionsOnly
type: boolean
Default: false
XML 이름: allow-direct-connections-only
설명: 나열된 connector-refs에 클러스터 연결을 제한합니다.
clusterConfigurations.<name>.reconnectAttempts
type: int
Default: -1
XML 이름: reconnect-attempts
Description: 실패 후 재연결 시도 횟수
clusterConfigurations.<name>.duplicateDetection
type: boolean
Default: true
XML 이름: use-duplicate-detection
설명: 중복 탐지 헤더가 전달된 메시지에 삽입되는지를 지정합니다.
clusterConfigurations.<name>.callFailoverTimeout
type: long
default: -1
XML 이름: call-failover-timeout
설명: 장애 조치 중 응답을 대기하는 기간입니다. 값 -1 은 제한이 없음을 의미합니다.
clusterConfigurations.<name>.messageLoadBalancingType
유형: MessageLoadBalancingType( OFF STRICT ON_DEMAND OFF_WITH_REDISTRIBUTION )
기본값:
XML 이름: message-load-balancing-type
설명:
clusterConfigurations.<name>.initialConnectAttempts
type: int
Default: -1
XML 이름: initial-connect-attempts
설명: 연결 시도 횟수
clusterConfigurations.<name>.connectorName
유형: 문자열
기본값:
XML 이름: connector-ref
설명: 사용할 커넥터 참조의 이름입니다.
clusterConfigurations.<name>.retryInterval
type: long
default: 500
XML 이름: retry-interval
설명: 연속 재시도 간격(밀리초)입니다.
clusterConfigurations.<name>.producerWindowSize
type: int
기본값: 1048576
XML 이름: producer-window-size
Description: Producer flow control. 바이트 표기법을 지원합니다(예: "K", "Mb", "MiB", "GB").
clusterConfigurations.<name>.clientFailureCheckPeriod
type: long
기본값:
XML 이름: client-failure-check-period
설명:
clusterConfigurations.<name>.discoveryGroupName
유형: 문자열
기본값:
XML 이름: discovery-group-name
설명: 이 cluster-connection에서 사용하는 검색 그룹의 이름입니다.
clusterConfigurations.<name>.minLargeMessageSize
type: int
기본값:
XML 이름: min-large-message-size
설명: 크기(바이트) 위의 경우 메시지가 큰 메시지로 간주됩니다. 큰 메시지는 여러 세그먼트에서 네트워크를 통해 전송됩니다. 바이트 표기법을 지원합니다(예: "K", "Mb", "MiB", "GB").
G.7. connectionRouters 링크 복사링크가 클립보드에 복사되었습니다!
connectionRouters.<name>.cacheConfiguration
type: CacheConfiguration
기본값:
XML 이름: 캐시 항목이 지속되는지 및 캐시가 해당 항목을 제거하는 빈도를 제어합니다.
connectionRouters.<name>.cacheConfiguration.persisted
type: boolean
Default: false
XML name: persisted
Description: true 값은 캐시 항목이 유지됨을 의미합니다.
connectionRouters.<name>.cacheConfiguration.timeout
type: int
Default: -1
XML name: timeout
설명: 캐시 항목이 제거되기 전 시간(밀리초)입니다.
connectionRouters.<name>.keyFilter
유형: 문자열
기본값:
XML 이름: 키 필터
설명: 대상 키에 대한 필터입니다.
connectionRouters.<name>.keyType
type: KeyType(CLIENT_ID SNI_HOST SOURCE_IP SOURCE_NAME ROLE_NAME ROLE_NAME )
Default:
XML name: key-type
description: 선택 사항 대상 키.
connectionRouters.<name>.localTargetFilter
type: String
Default:
XML name: local-target-filter
Description: A filter to find the local target.
connectionRouters.<name>.poolConfiguration
type: PoolConfiguration
기본값:
XML 이름: 풀
설명: 풀 구성.
connectionRouters.<name>.poolConfiguration.quorumTimeout
type: int
Default: 3000
XML 이름: quorum-timeout
설명: 시간 초과(밀리초)를 사용하여 최소 준비 대상 수를 가져옵니다.
connectionRouters.<name>.poolConfiguration.password
유형: 문자열
기본값:
XML 이름: password
설명: 대상에 액세스할 암호입니다.
connectionRouters.<name>.poolConfiguration.localTargetEnabled
type: boolean
Default: false
XML 이름: local-target-enabled
Description: true 값은 로컬 대상이 활성화되었음을 의미합니다.
connectionRouters.<name>.poolConfiguration.checkPeriod
type: int
Default: 5000
XML 이름: check-period
설명: 대상이 준비되었는지 확인하는 데 사용되는 기간(밀리초)입니다.
connectionRouters.<name>.poolConfiguration.quorumSize
type: int
기본값: 1
XML 이름: quorum-size
설명: 준비된 대상의 최소 수입니다.
connectionRouters.<name>.poolConfiguration.staticConnectors
type: List
기본값:
XML 이름: static-connectors
설명: 커넥터를 통해 구성된 커넥터 참조 목록입니다.
connectionRouters.<name>.poolConfiguration.discoveryGroupName
유형: 문자열
기본값:
XML 이름: discovery-group-name
설명: 이 브릿지에서 사용하는 검색 그룹의 이름입니다.
connectionRouters.<name>.poolConfiguration.clusterConnection
유형: 문자열
기본값:
XML 이름: cluster-connection
설명: 클러스터 연결의 이름입니다.
connectionRouters.<name>.poolConfiguration.username
유형: 문자열
기본값:
XML 이름: 사용자 이름
설명: 대상에 액세스할 사용자 이름입니다.
connectionRouters.<name>.policyConfiguration
type: NamedPropertyConfiguration
기본값:
XML 이름: policy-configuration
설명
connectionRouters.<name>..properties.{PROPERTY}
type: Properties
Default:
XML name: property
Description: A set of Key value pairs specific to each named property.
2024-06-11에 최종 업데이트된 문서