15장. 고가용성 구현
다음 방법 중 하나를 사용하여 AMQ Broker에 대한 고가용성 솔루션을 구현할 수 있습니다.
클러스터에 있는 브로커를 기본 백업 그룹으로 그룹화합니다.
primary-backup 그룹에서 기본 브로커는 백업 브로커에 연결됩니다. 기본 브로커는 클라이언트 요청을 제공하며 백업 브로커는 패시브 모드로 대기합니다. 기본 브로커가 실패하면 백업 브로커가 기본 브로커를 활성 브로커로 대체합니다. AMQ Broker는 primary-backup 그룹 내의 장애 조치(HA 정책)를 위한 몇 가지 다른 전략을 제공합니다.
클러스터에 없는 브로커에 대한 리더 후속 구성을 생성합니다.
리더 지원 구성에서 비클러스터형 브로커는 JDBC 데이터베이스 또는 저널 파일일 수 있는 공유 메시지 저장소를 사용합니다. 두 브로커는 피어로 경쟁하여 메시지 저장소에 대한 잠금을 확보합니다. 잠금을 획득하는 브로커는 클라이언트 요청을 제공하는 리더 브로커가 됩니다. 잠금을 얻을 수 없는 브로커는 팔로워가 됩니다. follower는 현재 리더를 사용할 수 없는 경우 활성 브로커가 될 수 있도록 지속적으로 잠금을 취득하려고하는 패시브 브로커입니다.
primary-backup 그룹에서는 하나의 브로커를 기본 및 다른 브로커를 백업으로 구성합니다. leader-follower 구성에서 두 브로커에 대해 동일한 구성을 지정합니다.
15.1. 고가용성을 위해 기본 백업 그룹 구성 링크 복사링크가 클립보드에 복사되었습니다!
HA 정책 이라는 여러 가지 전략을 사용하여 기본 백업 그룹 내에서 페일오버를 구성할 수 있습니다.
15.1.1. 고가용성 정책 링크 복사링크가 클립보드에 복사되었습니다!
HA(고가용성) 정책은 기본 백업 그룹에서 장애 조치가 수행되는 방법을 정의합니다. AMQ Broker는 다음과 같은 몇 가지 HA 정책을 제공합니다.
- 공유 저장소(권장)
기본 및 백업 브로커는 메시징 데이터를 공유 파일 시스템의 공통 디렉터리에 저장합니다. 일반적으로 SAN(Storage Area Network) 또는 NFS(Network File System) 서버. JDBC 기반 지속성을 구성한 경우 브로커 데이터를 지정된 데이터베이스에 저장할 수도 있습니다. 공유 저장소를 사용하면 기본 브로커가 실패하면 백업 브로커가 공유 저장소에서 메시지 데이터를 로드하고 활성 브로커로 가져옵니다.
대부분의 경우 복제 대신 공유 저장소를 사용해야 합니다. 공유 저장소는 네트워크를 통해 데이터를 복제하지 않으므로 일반적으로 복제보다 성능이 향상됩니다.Because shared store does not replicate data over the network, it typically provides better performance than replication. 공유 저장소는 또한 기본 브로커와 백업이 동시에 활성화되는 네트워크 격리('스플릿'라고도 함) 문제를 방지합니다.
그림 15.1. 공유 저장소 고가용성
리더 지원 구성에서 브로커를 구성하여 공유 저장소를 사용하는 대체 고가용성 솔루션을 구현할 수 있습니다. 리더-추어 구성에서 브로커는 클러스터링되지 않고 피어로 경쟁하여 어떤 브로커가 활성화되고 클라이언트 요청을 제공하는지 결정하고 활성 브로커를 더 이상 사용할 수 없을 때까지 수동적으로 남아 있습니다. 자세한 내용은 15.2절. “고가용성을 위해 leader-follower 브로커 구성”의 내용을 참조하십시오.
- 복제
기본 및 백업 브로커는 네트워크를 통해 메시징 데이터를 지속적으로 동기화합니다. 기본 브로커가 실패하면 백업 브로커가 동기화된 데이터를 로드하고 활성 브로커로 가져옵니다.
기본 브로커와 백업 브로커 간의 데이터 동기화를 통해 기본 브로커가 실패하면 메시징 데이터가 손실되지 않습니다. 기본 및 백업 브로커가 처음에 결합되면 기본 브로커는 모든 기존 데이터를 네트워크를 통해 백업 브로커에 복제합니다. 이 초기 단계가 완료되면 기본 브로커가 수신할 때 기본 브로커는 영구 데이터를 백업 브로커에 복제합니다. 즉, 기본 브로커가 네트워크를 삭제하면 백업 브로커에 기본 브로커가 해당 시점까지 수신한 모든 영구 데이터가 있습니다.
복제는 네트워크를 통해 데이터를 동기화하므로 네트워크 오류로 인해 기본 브로커와 백업이 동시에 활성화되는 네트워크 격리가 발생할 수 있습니다.
그림 15.2. 복제 고가용성
- 기본 전용(제한 HA)
기본 브로커가 정상적으로 중지되면 해당 메시지와 트랜잭션 상태를 다른 활성 브로커에 복사한 다음 종료합니다. 그러면 클라이언트가 다른 브로커에 다시 연결하여 메시지를 계속 보내고 받을 수 있습니다.
그림 15.3. 기본 전용 고가용성
추가 리소스
- primary-backup 그룹의 브로커 간에 공유되는 영구 메시지 데이터에 대한 자세한 내용은 6.1절. “저널에 메시지 데이터 유지” 을 참조하십시오.
15.1.2. 복제 정책 제한 사항 링크 복사링크가 클립보드에 복사되었습니다!
복제를 사용하여 고가용성을 제공할 때 기본 브로커와 백업 브로커 둘 다 동시에 활성화될 수 있는 위험이 있습니다.
분할 뇌는 기본 브로커와 백업이 연결이 끊어지면 발생할 수 있습니다. 이 경우 기본 브로커와 백업이 동시에 활성화될 수 있습니다. 이 상황에서 브로커 간에 메시지 복제가 없기 때문에 서로 알 필요 없이 각각 클라이언트와 메시지를 처리합니다. 이 경우 각 브로커는 완전히 다른 저널을 갖습니다. 이 상황에서 복구하는 것은 매우 어려울 수 있으며 경우에 따라 불가능합니다.
- 분할 뇌의 가능성을 제거하려면 공유 저장소 HA 정책을 사용하십시오.
복제 HA 정책을 사용하는 경우 다음 단계를 수행하여 분할 뇌가 발생할 위험을 줄입니다.
브로커가 Zoo Cryostat 코디네이션 서비스를 사용하여 브로커를 조정하려면 최소 3개의 노드에 Zoo Cryostat를 배포합니다. 브로커가 하나의 Zoo Cryostat 노드에 대한 연결이 끊어지면 3 개 이상의 노드를 사용하면 기본 백업 브로커 쌍에 복제 중단이 발생할 때 브로커를 조정할 수 있습니다.
클러스터에서 사용 가능한 다른 브로커를 사용하여 쿼럼 투표를 제공하는 임베디드 브로커 조정을 사용하려면 3개 이상의 기본 백업 쌍을 사용하여 분할 뇌가 발생할 가능성을 줄일 수 있습니다. 3개 이상의 기본 백업 쌍을 사용하면 백업 브로커 쌍에 복제 중단이 발생할 때 발생하는 쿼럼 투표에서 대부분의 결과를 얻을 수 있습니다.
복제 HA 정책을 사용할 때 고려해야 할 몇 가지 추가 고려 사항은 다음과 같습니다.
- 기본 브로커가 실패하고 백업 브로커가 활성 상태가 되면 새 백업 브로커가 활성 브로커에 연결되거나 원래 기본 브로커에 실패할 때까지 추가 복제가 수행되지 않습니다.
- 기본 백업 그룹의 백업 브로커가 실패하면 기본 브로커는 계속 메시지를 제공합니다. 그러나 다른 브로커가 백업으로 추가되거나 원래 백업 브로커가 다시 시작될 때까지 메시지가 복제되지 않습니다. 이 기간 동안 메시지는 기본 브로커에만 유지됩니다.
- 브로커가 포함된 브로커 조정을 사용하고 메시지 손실을 방지하기 위해 기본 백업 쌍의 두 브로커가 종료되는 경우 가장 최근의 활성 브로커를 먼저 다시 시작해야 합니다. 가장 최근에 활성 브로커가 백업 브로커인 경우 이 브로커를 먼저 다시 시작하기 위해 이 브로커를 기본 브로커로 수동으로 재구성해야 합니다.
15.1.4. 복제 고가용성 구성 링크 복사링크가 클립보드에 복사되었습니다!
HA(복제 고가용성) 정책을 사용하여 브로커 클러스터에서 HA를 구현할 수 있습니다. 복제를 사용하면 기본 브로커와 백업 브로커 간에 영구 데이터가 동기화됩니다. 기본 브로커가 오류가 발생하면 메시지 데이터가 백업 브로커에 동기화되고 실패한 기본 브로커를 대신 수행합니다.
공유 파일 시스템이 없는 경우 복제를 공유 저장소의 대안으로 사용해야 합니다. 그러나 복제로 인해 기본 브로커와 백업이 동시에 활성화됩니다.
기본 및 백업 브로커는 네트워크를 통해 메시징 데이터를 동기화해야 하므로 복제에는 성능 오버헤드가 추가됩니다. 이 동기화 프로세스는 저널 작업을 차단하지만 클라이언트를 차단하지는 않습니다. 데이터 동기화에 대해 저널 작업을 차단할 수 있는 최대 시간을 구성할 수 있습니다.
primary-backup 브로커 쌍 간의 복제 연결이 중단된 경우 브로커는 주 브로커가 여전히 활성화되어 있는지 또는 백업 브로커에 대한 장애 조치(failover)가 필요한지 여부를 결정하기 위해 조정할 방법이 필요합니다. 이러한 조정을 제공하기 위해 다음 조정 방법 중 하나를 사용하도록 브로커를 구성할 수 있습니다.
- Apache Zoo Cryostat 조정 서비스입니다.
- 클러스터의 다른 브로커를 사용하여 쿼럼 투표를 제공하는 임베디드 브로커 조정.
15.1.4.1. 조정 방법 선택 링크 복사링크가 클립보드에 복사되었습니다!
Apache Zoo Cryostat 조정 서비스를 사용하여 브로커 활성화를 조정하는 것이 좋습니다. 조정 방법을 선택할 때 인프라 요구 사항의 차이점과 두 조정 방법 간의 데이터 일관성 관리를 이해하는 것이 유용합니다.
인프라 요구사항
- Zoo Cryostat 조정 서비스를 사용하는 경우 단일 primary-backup 브로커 쌍으로 작동할 수 있습니다. 그러나 한 노드에 연결이 끊어지면 브로커가 계속 작동 할 수 있도록 브로커를 3 개 이상의 Apache Zoo Cryostat 노드에 연결해야 합니다. 브로커에 조정 서비스를 제공하기 위해 다른 애플리케이션에서 사용하는 기존 Zoo Cryostat 노드를 공유할 수 있습니다. Apache Zoo Cryostat 설정에 대한 자세한 내용은 Apache Zoo Cryostat 설명서를 참조하십시오.
- 클러스터에서 사용 가능한 다른 브로커를 사용하여 쿼럼 투표를 제공하는 임베디드 브로커 조정을 사용하려면 3개 이상의 primary-backup 브로커 쌍이 있어야 합니다. 3개 이상의 기본 백업 쌍을 사용하면 백업 브로커 쌍에 복제 중단이 발생할 때 발생하는 쿼럼 투표에서 대부분의 결과를 얻을 수 있습니다.
데이터 일관성
- Apache Zoo Cryostat 조정 서비스를 사용하는 경우, Zoo Cryostat는 각 브로커에서 데이터의 버전을 추적하므로 가장 최신 저널 데이터를 가진 브로커만 복제 목적으로 브로커가 기본 또는 백업 브로커로 구성되어 있는지 여부에 관계없이 활성 상태가 될 수 있습니다. 버전 추적은 브로커가 최신 저널로 활성화되고 클라이언트를 제공할 수 있는 가능성을 제거합니다.
- 포함된 브로커 조정을 사용하는 경우 각 브로커의 데이터 버전을 추적하여 가장 최신 저널이 있는 브로커만 활성화할 수 있도록 메커니즘이 존재하지 않습니다. 따라서 최신 저널이 있는 브로커가 활성 상태가 되고 고객에게 서비스를 제공할 수 있으므로 저널에서 다양한 상황이 발생할 수 있습니다.
15.1.4.2. 복제 중단 후 브로커가 조정하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 복제 연결이 중단된 후 두 가지 조정 방법이 어떻게 작동하는지 설명합니다.
Zoo Cryostat 조정 서비스 사용
복제 중단을 관리하기 위해 Zoo Cryostat 조정 서비스를 사용하는 경우 두 브로커 모두 여러 Apache Zoo Cryostat 노드에 연결되어 있어야 합니다.
- 언제든지 활성 브로커가 대부분의 Zoo Cryostat 노드에 대한 연결을 끊으면 "플릿 브레인"의 위험을 방지하기 위해 종료됩니다.
- 언제든지 백업 브로커가 대부분의 Zoo Cryostat 노드에 대한 연결을 끊으면 복제 데이터 수신을 중지하고 대부분의 Zoo Cryostat 노드에 다시 연결하기 전에 다시 연결할 수 있을 때까지 기다립니다. 연결이 대부분의 Zoo Cryostat 노드로 복원되면 백업 브로커는 데이터를 삭제하고 복제할 활성 브로커를 검색하거나 현재 데이터로 활성 브로커가 될 수 있는지 여부를 결정하는 데 사용합니다.
Zookeeper는 다음 제어 메커니즘을 사용하여 장애 조치 프로세스를 관리합니다.
- 언제든지 단일 활성 브로커가 소유할 수 있는 공유 리스 잠금입니다.
- 브로커 데이터의 최신 버전을 추적하는 활성화 순서 카운터입니다. 각 브로커는 NodeID와 함께 서버 잠금 파일에 저장된 로컬 카운터에서 저널 데이터의 버전을 추적합니다. 또한 활성 브로커는 Zoo Cryostat의 조정된 활성화 시퀀스 카운터로 버전을 공유합니다.
활성 브로커와 백업 브로커 간의 복제 연결이 손실되면 활성 브로커는 로컬 활성화 시퀀스 카운터 값과 Zoo Cryostat의 조정된 활성화 시퀀스 카운터 값을 1
로 늘려 최신 데이터가 있음을 알립니다. 이제 백업 브로커의 데이터가 오래된 것으로 간주되며 복제 연결이 복원되고 최신 데이터가 동기화될 때까지 브로커가 활성 브로커가 될 수 없습니다.
복제 연결이 손실된 후 백업 브로커는 활성 브로커가 Zoo Cryostat 잠금을 소유하고 있고 Zoo Cryostat의 조정된 활성화 시퀀스 카운터가 로컬 카운터 값과 일치하는지 확인합니다.
- 활성 브로커가 잠금을 소유하고 있는 경우 백업 브로커는 복제 연결이 손실되었을 때 Zoo Cryostat의 활성화 시퀀스 카운터가 활성 브로커에 의해 업데이트되었음을 감지합니다. 이는 백업 브로커가 장애 조치를 시도하지 않도록 활성 브로커가 실행 중임을 나타냅니다.
- 활성 브로커가 잠금을 소유하지 않은 경우 활성 브로커는 활성 상태가 아닙니다. 백업 브로커의 활성화 시퀀스 카운터 값이 Zoo Cryostat의 조정된 활성화 순서 카운터 값과 동일하면 백업 브로커에 최신 데이터가 있음을 나타냅니다.
- 활성 브로커가 잠금을 소유하고 있지 않지만 백업 브로커의 활성화 순서 카운터 값이 Zoo Cryostat의 카운터 값보다 작으면 백업 브로커의 데이터는 최신 상태가 아니며 백업 브로커가 장애 조치할 수 없습니다.
포함된 브로커 조정 사용
기본 백업 브로커 쌍에서 포함된 브로커 조정을 사용하여 복제 중단을 조정하는 경우 다음 두 가지 유형의 쿼럼 투표를 시작할 수 있습니다.
투표 유형 | 설명 | 이니시에이터 | 필수 구성 | 참가자 | 투표 결과에 따른 조치 |
---|---|---|---|---|---|
수동 투표 | 패시브 브로커가 활성 브로커에 대한 복제 연결을 끊으면 수동 브로커는 이 투표 결과에 따라 시작할지 여부를 결정합니다. | 패시브 브로커 | 없음. 수동 투표는 수동 브로커가 복제 파트너에 대한 연결이 끊어지면 자동으로 수행됩니다. 그러나 다음 매개변수에 사용자 지정 값을 지정하여 수동 투표 속성을 제어할 수 있습니다.
| 클러스터의 기타 활성 브로커 | 패시브 브로커는 클러스터의 다른 활성 브로커에서 대다수(즉, 쿼럼) 투표를 수신하여 복제 파트너를 더 이상 사용할 수 없음을 나타내는 경우 시작됩니다. |
활성 투표 | 활성 브로커가 복제 파트너에 대한 연결이 끊어지면 활성 브로커는 이 투표를 기반으로 계속 실행할지 여부를 결정합니다. | 활성 브로커 |
투표는 오류가 발생한 백업으로 구성된 브로커일 수 있는 활성 브로커가 복제 파트너에 대한 연결이 끊어지고 | 클러스터의 기타 활성 브로커 | 클러스터의 다른 활성 브로커에서 투표를 수신하지 않으면 활성 브로커가 종료되며 클러스터 연결이 여전히 활성화되어 있음을 나타냅니다. |
다음은 브로커 클러스터의 구성에 쿼럼 투표 동작에 미치는 영향에 대해 알아야 할 몇 가지 중요한 사항입니다.
- 쿼럼 투표가 성공하려면 클러스터 크기가 대부분의 결과를 얻을 수 있어야 합니다. 따라서 클러스터에 3개 이상의 기본 백업 브로커 쌍이 있어야 합니다.
- 클러스터에 추가하는 primary-backup 브로커 쌍이 많을수록 클러스터의 전반적인 내결함성을 높일 수 있습니다. 예를 들어, primary-backup 쌍이 세 개 있다고 가정합니다. 전체 primary-backup 쌍을 손실하면 나머지 두 개의 primary-backup 쌍이 대부분의 경우 후속 쿼럼 투표를 수행할 수 없습니다. 이 경우 클러스터의 추가 복제 중단으로 인해 기본 브로커가 종료되고 백업 브로커가 시작되지 않을 수 있습니다. 클러스터(예: 5개의 브로커 쌍)를 사용하여 클러스터를 구성하면 클러스터에 두 개 이상의 오류가 발생할 수 있으며 대부분의 경우 쿼럼 투표로 인한 결과가 발생합니다.
- 클러스터에서 기본 백업 브로커 쌍의 수를 의도적으로 줄이는 경우, 대다수의 투표에 대해 이전에 설정된 임계값이 자동으로 감소되지 않습니다. 이 기간 동안 복제 연결 손실에 의해 트리거되는 쿼럼 투표는 성공할 수 없으므로 클러스터가 뇌를 분할하는 데 더 취약해집니다. 클러스터에서 쿼럼 투표의 최대 임계값을 다시 계산하도록 하려면 먼저 클러스터에서 제거할 기본 백업 쌍을 종료합니다. 그런 다음 클러스터에서 나머지 primary-backup 쌍을 다시 시작합니다. 나머지 브로커를 모두 다시 시작하면 클러스터에서 쿼럼 투표 임계값을 다시 계산합니다.
15.1.4.3. Zoo Cryostat 조정 서비스를 사용하여 브로커 클러스터의 복제 구성 링크 복사링크가 클립보드에 복사되었습니다!
Apache Zoo Cryostat 조정 서비스를 사용하는 한 쌍의 두 브로커에 대해 동일한 복제 구성을 지정해야 합니다. 그런 다음 브로커는 활성 브로커이고 패시브 백업 브로커인 브로커를 결정하도록 조정합니다.
사전 요구 사항
- 하나의 노드에 대한 연결이 끊어지면 브로커가 계속 작동 할 수 있도록 3 개 이상의 Apache Zoo Cryostat 노드.
- 브로커 시스템에는 유사한 하드웨어 사양이 있습니다. 즉, 시스템이 활성 브로커를 실행하고 언제든지 수동 백업 브로커를 실행하는 기본 설정이 없습니다.
- Zookeeper에는 일시 중지 시간이 Zoo Cryostat 서버 틱 시간보다 훨씬 적도록 충분한 리소스가 있어야 합니다. 브로커의 예상 로드에 따라 브로커와 Zoo Cryostat 노드가 동일한 노드를 공유할 수 있는지 신중하게 고려하십시오. 자세한 내용은 https://zookeeper.apache.org/ 을 참조하십시오.
프로세스
-
쌍의
두 브로커 모두에 대해 <broker_instance_dir> /etc/broker.xml
구성 파일을 엽니다. 쌍의 두 브로커에 대해 동일한 복제 구성을 구성합니다. 예를 들면 다음과 같습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본 설정
- 브로커 조정 결과에 따라 브로커 중 하나가 기본 브로커일 수 있음을 나타내도록 복제 유형을 primary로 구성합니다.
reconcile-id
-
두 브로커 모두에 공통 문자열 값을 지정합니다. 동일한
Coordination-id
문자열을 사용하는 브로커와 함께 활성화를 조정합니다. 조정 프로세스 중에 두 브로커는Coordination-id
문자열을 노드 Id로 사용하고 Zoo Cryostat에서 잠금을 가져옵니다. 잠금을 확보하고 최신 데이터가 있는 첫 번째 브로커는 활성 브로커로 시작되고 다른 브로커는 수동 백업이 됩니다. 속성
Zoo Cryostat 노드에 대한 연결 세부 정보를 제공하기 위해 키-값 쌍 세트를 지정할 수 있는
속성
요소를 지정합니다.Expand 표 15.2. Zookeeper 연결 세부 정보 키 현재의 연결 문자열
Zoo Cryostat 노드의 IP 주소 및 포트 번호의 쉼표로 구분된 목록을 지정합니다. 예를 들어
value="192.168.1.10:6666,192.168.2.10:6667,192.168.3.10:6668"
.session-ms
대다수의 Zoo Cryostat 노드에 대한 연결이 끊어진 후 브로커가 종료되기 전에 대기하는 기간입니다. 기본값은
18000
ms입니다. 유효한 값은 2회에서 20배 사이입니다. Zoo Cryostat 서버의 틱 시간.참고가비지 컬렉션에 대한 Zoo Cryostat 일시 중지 시간은 Zoo Cryostat 하트비트가 안정적으로 작동할 수 있도록
세션-ms
속성 값의 0.33 미만이어야 합니다. 일시 중지 시간이 이 제한보다 작도록 할 수 없는 경우 각 브로커에 대한session-ms
속성 값을 늘리고 느린 페일오버를 수락합니다.중요브로커 복제 파트너는 2초마다 자동으로 "핑" 패킷을 교환하여 파트너 브로커가 사용 가능한지 확인합니다. 백업 브로커가 활성 브로커로부터 응답을 받지 못하면 백업은 브로커의 연결 시간-투-라이브(ttl)가 만료될 때까지 응답을 기다립니다. 기본 connection-ttl은
60000
ms이므로 백업 브로커가 60초 후에 장애 조치를 시도합니다. 더 빠른 장애 조치를 허용하려면 connection-ttl 값을session-ms
속성 값과 유사한 값으로 설정하는 것이 좋습니다. 새 connection-ttl을 설정하려면connection-ttl-override
속성을 구성합니다.네임스페이스(선택 사항)
브로커가 다른 애플리케이션과 Zoo Cryostat 노드를 공유하는 경우, 브로커에 조정 서비스를 제공하는 파일을 저장하기 위해 Zoo Cryostat 네임스페이스를 만들 수 있습니다. 두 브로커 모두에 동일한 네임스페이스를 지정해야 합니다.
브로커에 대한 추가 HA 속성을 구성합니다.
이러한 추가 HA 속성에는 대부분의 일반적인 사용 사례에 적합한 기본값이 있습니다. 따라서 기본 동작을 원하지 않는 경우에만 이러한 속성을 구성해야 합니다. 자세한 내용은 부록 F. 추가 복제 고가용성 구성입니다.의 내용을 참조하십시오.
- 1~3단계를 반복하여 클러스터의 각 추가 브로커 쌍을 구성합니다.
추가 리소스
- HA에 복제를 사용하는 브로커 클러스터의 예는 HA 예제 를 참조하십시오.
- 노드 ID에 대한 자세한 내용은 노드 ID 이해를 참조하십시오.
15.1.4.4. 포함된 브로커 조정을 사용하여 복제 고가용성을 위해 브로커 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
임베디드 브로커 조정을 사용하는 복제에는 "split brain"의 위험을 줄이지만 제거하는 데 최소 3 개의 기본 백업 쌍이 필요합니다.
다음 절차에서는 6브로커 클러스터에 대해 HA(복제 고가용성)를 구성하는 방법을 설명합니다. 이 토폴로지에서 6개의 브로커는 세 개의 기본 백업 쌍으로 그룹화됩니다. 세 개의 기본 브로커는 각각 전용 백업 브로커와 연결됩니다.
사전 요구 사항
브로커가 6개 이상인 브로커 클러스터가 있어야 합니다.
6개의 브로커는 세 개의 기본 백업 쌍으로 구성됩니다. 클러스터에 브로커를 추가하는 방법에 대한 자세한 내용은 14장. 브로커 클러스터 설정 을 참조하십시오.
프로세스
클러스터의 브로커를 기본 백업 그룹으로 그룹화합니다.
대부분의 경우 primary-backup 그룹은 두 브로커(기본 브로커와 백업 브로커)로 구성되어야 합니다. 클러스터에 6개의 브로커가 있는 경우 3개의 primary-backup 그룹이 필요합니다.
하나의 기본 브로커와 하나의 백업 브로커로 구성된 첫 번째 primary-backup 그룹을 생성합니다.
-
기본 브로커의 <
broker_instance_dir> /etc/broker.xml
구성 파일을 엽니다. HA 정책에 복제를 사용하도록 기본 브로커를 구성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow check-for-active-server
기본 브로커가 실패하면 이 속성은 클라이언트가 다시 시작될 때 실패해야 하는지 여부를 제어합니다.
이 속성을
true
로 설정하면 이전 장애 조치 후 기본 브로커가 다시 시작되면 동일한 노드 ID가 있는 클러스터에서 다른 브로커를 검색합니다. 기본 브로커가 동일한 노드 ID를 가진 다른 브로커를 발견하면 기본 브로커가 실패할 때 백업 브로커가 성공적으로 시작되었음을 나타냅니다. 이 경우 기본 브로커는 해당 데이터를 백업 브로커와 동기화합니다. 그런 다음 기본 브로커는 백업 브로커를 종료하도록 요청합니다. 백업 브로커가 실패에 대해 구성된 경우 아래와 같이 백업 브로커가 종료됩니다. 그런 다음 기본 브로커는 활성 역할을 재개하고 클라이언트는 다시 연결합니다.주의기본 브로커에서
check-for-active-server
를true
로 설정하지 않으면 이전 장애 조치 후 기본 브로커를 다시 시작할 때 중복 메시징 처리가 발생할 수 있습니다. 특히 이 속성이false
로 설정된 기본 브로커를 다시 시작하면 기본 브로커는 백업 브로커와 데이터를 동기화하지 않습니다. 이 경우 기본 브로커는 백업 브로커가 이미 처리한 것과 동일한 메시지를 처리하여 중복을 유발할 수 있습니다.group-name
- 이 primary-backup 그룹의 이름(선택 사항). 기본 백업 그룹을 만들려면 기본 및 백업 브로커를 동일한 그룹 이름으로 구성해야 합니다. 그룹 이름을 지정하지 않으면 백업 브로커는 기본 브로커와 복제할 수 있습니다.
vote-on-replication-failure
이 속성은 기본 브로커가 중단된 복제 연결의 경우 기본 투표라는 쿼럼 투표를 시작하는지 여부를 제어합니다.
기본 투표는 기본 브로커가 중단된 복제 연결의 원인인지 여부를 결정하는 방법입니다. 투표 결과에 따라 주요 브로커는 실행 중이거나 종료됩니다.
중요쿼럼 투표가 성공하려면 클러스터 크기가 대부분의 결과를 얻을 수 있어야 합니다. 따라서 복제 HA 정책을 사용하는 경우 클러스터에 3개 이상의 primary-backup 브로커 쌍이 있어야 합니다.
클러스터에서 더 많은 브로커 쌍을 구성할수록 클러스터의 전반적인 내결함성을 높일 수 있습니다. 예를 들어, 3개의 primary-backup 브로커 쌍이 있다고 가정합니다. 전체 primary-backup 쌍에 대한 연결이 끊어지면 나머지 두 primary-backup 쌍은 더 이상 쿼럼 투표를 통해 대부분의 결과를 얻을 수 없습니다. 이 경우 후속 복제 중단으로 인해 기본 브로커가 종료되고 백업 브로커가 시작되지 않을 수 있습니다. 클러스터(예: 5개의 브로커 쌍)를 사용하여 클러스터를 구성하면 클러스터에 두 개 이상의 오류가 발생할 수 있으며 대부분의 경우 쿼럼 투표로 인한 결과가 발생합니다.
기본 브로커에 대한 추가 HA 속성을 구성합니다.
이러한 추가 HA 속성에는 대부분의 일반적인 사용 사례에 적합한 기본값이 있습니다. 따라서 기본 동작을 원하지 않는 경우에만 이러한 속성을 구성해야 합니다. 자세한 내용은 부록 F. 추가 복제 고가용성 구성입니다.의 내용을 참조하십시오.
-
백업 브로커의 <
broker_instance_dir> /etc/broker.xml
구성 파일을 엽니다. HA 정책에 복제를 사용하도록 백업 브로커를 구성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow allow-failback
장애 조치가 발생했으며 백업 브로커가 기본 브로커에 대해 이 속성을 사용하면 백업 브로커가 다시 시작되고 클러스터에 다시 연결할 때 백업 브로커가 원래 기본 브로커로 돌아가야 하는지 여부를 제어합니다.
참고failback은 기본 백업 쌍(단 하나의 백업 브로커와 페어링된 기본 브로커)을 위한 것입니다. 기본 브로커가 여러 백업으로 구성된 경우 failback이 발생하지 않습니다. 대신 장애 조치(failover) 이벤트가 발생하면 백업 브로커가 활성 상태가 되고 다음 백업이 백업이 됩니다. 기본 브로커가 다시 온라인 상태가 되면 현재 활성 상태인 브로커에 백업이 있기 때문에 failback을 시작할 수 없습니다.
group-name
- 이 primary-backup 그룹의 이름(선택 사항). 기본 백업 그룹을 만들려면 기본 및 백업 브로커를 동일한 그룹 이름으로 구성해야 합니다. 그룹 이름을 지정하지 않으면 백업 브로커는 기본 브로커와 복제할 수 있습니다.
vote-on-replication-failure
이 속성은 활성 상태의 백업 브로커가 중단된 복제 연결 시 주 투표라는 쿼럼 투표를 시작할 수 있는지 여부를 제어합니다.
기본 투표는 기본 브로커가 중단된 복제 연결의 원인인지 여부를 결정하는 방법입니다. 투표 결과에 따라 주요 브로커는 실행 중이거나 종료됩니다.
(선택 사항) 백업 브로커가 시작하는 쿼럼 투표를 구성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow vote-retries
- 이 속성은 백업 브로커가 백업 브로커를 시작할 수 있는 대부분의 결과를 수신하기 위해 백업 브로커가 쿼럼 투표를 재시도하는 횟수를 제어합니다.
vote-retry-wait
- 이 속성은 쿼럼 투표의 각 재시도 사이에 백업 브로커가 대기하는 데 걸리는 시간(밀리초)을 제어합니다.
백업 브로커에 대한 추가 HA 속성을 구성합니다.
이러한 추가 HA 속성에는 대부분의 일반적인 사용 사례에 적합한 기본값이 있습니다. 따라서 기본 동작을 원하지 않는 경우에만 이러한 속성을 구성해야 합니다. 자세한 내용은 부록 F. 추가 복제 고가용성 구성입니다.의 내용을 참조하십시오.
-
기본 브로커의 <
클러스터의 추가 기본 백업 그룹에 대해 2단계를 반복합니다.
클러스터에 6개의 브로커가 있는 경우 이 절차를 두 번 더 반복합니다. 나머지 primary-backup 그룹에 대해 한 번 더 반복합니다.
추가 리소스
- HA에 복제를 사용하는 브로커 클러스터의 예는 HA 예제 를 참조하십시오.
- 노드 ID에 대한 자세한 내용은 노드 ID 이해를 참조하십시오.
15.1.5. 기본 전용으로 제한된 고가용성 구성 링크 복사링크가 클립보드에 복사되었습니다!
기본 전용 HA 정책을 사용하면 메시지를 손실하지 않고 클러스터에서 브로커를 종료할 수 있습니다. 기본 전용을 사용하면 활성 브로커가 정상적으로 중지되면 해당 메시지와 트랜잭션 상태를 다른 활성 브로커에 복사한 다음 종료합니다. 그러면 클라이언트가 다른 브로커에 다시 연결하여 메시지를 계속 보내고 받을 수 있습니다.
기본 전용 HA 정책은 브로커가 정상적으로 중지된 경우에만 케이스를 처리합니다. 예기치 않은 브로커 오류를 처리하지 않습니다.
기본 전용 HA는 메시지 손실을 방지하지만 메시지 순서를 유지하지 못할 수 있습니다. 기본 전용 HA로 구성된 브로커가 중지되면 다른 브로커의 대기열 끝에 메시지가 추가됩니다.
브로커가 축소할 준비가 되면 새 브로커가 메시지를 처리할 준비가 되어 있는지 알리는 연결을 해제하기 전에 클라이언트에 메시지를 보냅니다. 그러나 클라이언트는 초기 브로커가 축소된 후에만 새 브로커에 다시 연결해야 합니다. 이렇게 하면 클라이언트가 다시 연결할 때 큐 또는 트랜잭션과 같은 모든 상태를 다른 브로커에서 사용할 수 있습니다. 일반적인 재연결 설정은 클라이언트가 다시 연결할 때 적용되므로 축소하는 데 필요한 시간을 처리할 수 있을 만큼 이러한 높은 설정을 설정해야 합니다.
다음 절차에서는 축소를 위해 클러스터의 각 브로커를 구성하는 방법을 설명합니다. 이 절차를 완료하면 브로커가 정상적으로 중지될 때마다 메시지와 트랜잭션 상태를 클러스터의 다른 브로커에 복사합니다.
프로세스
-
첫 번째 브로커의 <
broker_instance_dir> /etc/broker.xml
구성 파일을 엽니다. 기본 전용 HA 정책을 사용하도록 브로커를 구성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 브로커 클러스터를 축소하는 방법을 구성합니다.
이 브로커를 축소해야 하는 브로커 또는 브로커 그룹을 지정합니다.
Expand 표 15.3. 브로커 클러스터를 축소하는 방법 축소를…로 축소하려면 다음을 수행합니다. 이 작업을 수행… 클러스터의 특정 브로커
축소할 브로커의 커넥터를 지정합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터의 브로커
브로커 클러스터의 검색 그룹을 지정합니다.
<primary-only> <scale-down> <discovery-group-ref discovery-group-name="my-discovery-group"/> </scale-down> </primary-only>
<primary-only> <scale-down> <discovery-group-ref discovery-group-name="my-discovery-group"/> </scale-down> </primary-only>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 특정 브로커 그룹의 브로커
브로커 그룹을 지정합니다.
<primary-only> <scale-down> <group-name>my-group-name</group-name> </scale-down> </primary-only>
<primary-only> <scale-down> <group-name>my-group-name</group-name> </scale-down> </primary-only>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 클러스터의 나머지 브로커에 대해 이 절차를 반복합니다.
추가 리소스
-
클러스터를 축소하기 위해 기본 전용을 사용하는 브로커 클러스터의 예는
스케일 다운
예제 를 참조하십시오.
15.1.6. 배치된 백업을 사용하여 고가용성 구성 링크 복사링크가 클립보드에 복사되었습니다!
primary-backup 그룹을 구성하는 대신 다른 기본 브로커와 동일한 JVM에 백업 브로커를 배치할 수 있습니다. 이 구성에서 각 기본 브로커는 다른 기본 브로커를 요청하여 JVM에서 백업 브로커를 생성하고 시작하도록 구성됩니다.
그림 15.4. 공동 배치된 기본 및 백업 브로커
공유 저장소 또는 복제와 함께 HA(고가용성) 정책으로 colocation을 사용할 수 있습니다. 새 백업 브로커는 이를 생성하는 기본 브로커의 구성을 상속합니다. 백업 이름은 colocated_backup_n
으로 설정됩니다. 여기서 n
은 기본 브로커가 생성한 백업 수입니다.
또한 백업 브로커는 이를 생성하는 기본 브로커의 커넥터 및 어셉터에 대한 구성을 상속합니다. 기본적으로 포트 오프셋 100은 각각에 적용됩니다. 예를 들어 기본 브로커에 포트 616에 대한 허용자가 있는 경우 생성된 첫 번째 백업 브로커는 포트 61716을 사용하면 두 번째 백업은 61816을 사용합니다.
저널, 대용량 메시지 및 페이징의 디렉터리는 선택한 HA 정책에 따라 설정됩니다. 공유 저장소를 선택하는 경우 요청 브로커는 대상 브로커에 사용할 디렉터리를 알립니다. 복제를 선택하면 디렉터리는 생성 브로커에서 상속되고 새 백업의 이름이 추가됩니다.
이 절차에서는 클러스터의 각 브로커가 공유 저장소 HA를 사용하고 클러스터에 있는 다른 브로커와 생성 및 배치되도록 백업을 요청합니다.
프로세스
-
첫 번째 브로커의 <
broker_instance_dir> /etc/broker.xml
구성 파일을 엽니다. HA 정책 및 공동 배치를 사용하도록 브로커를 구성합니다.
이 예에서 브로커는 공유 저장소 HA 및 colocation으로 구성됩니다.
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
입니다. excludes
(선택 사항)-
백업 포트 오프셋에서 커넥터를 제외합니다. 백업 포트 오프셋에서 제외해야 하는 외부 브로커에 대한 커넥터를 구성한 경우 각 커넥터에 대해 <
connector-ref
>를 추가합니다. 기본 설정
- 이 브로커의 공유 저장소 또는 복제 페일오버 구성입니다.
Backup
- 이 브로커의 백업에 대한 공유 저장소 또는 복제 페일오버 구성입니다.
- 클러스터의 나머지 브로커에 대해 이 절차를 반복합니다.
추가 리소스
- 배치된 백업을 사용하는 브로커 클러스터의 예는 HA 예제 를 참조하십시오.