4.11. 고가용성 및 메시지 마이그레이션

4.11.1. 고가용성

고가용성 이라는 용어는 해당 시스템의 일부가 실패하거나 종료된 경우에도 계속 작동할 수 있는 시스템을 나타냅니다. OpenShift Container Platform의 AMQ Broker의 경우 브로커 Pod가 실패하는 경우 메시징 데이터의 무결성 및 가용성을 보장하거나 배포의 의도적 축소로 인해 종료됩니다.

OpenShift Container Platform에서 AMQ Broker에 대한 고가용성을 허용하려면 브로커 클러스터에서 여러 브로커 Pod를 실행합니다. 각 브로커 Pod는 PVC(영구 볼륨 클레임)와 함께 사용하도록 요청하는 사용 가능한 PV(영구 볼륨)에 메시지 데이터를 씁니다. 브로커 Pod가 실패하거나 종료되면 PV에 저장된 메시지 데이터가 브로커 클러스터에서 사용 가능한 다른 브로커 Pod로 마이그레이션됩니다. 다른 브로커 Pod는 메시지 데이터를 자체 PV에 저장합니다.

다음 그림은 StatefulSet 기반 브로커 배포를 보여줍니다. 이 경우 브로커 클러스터의 두 브로커 Pod가 여전히 실행되고 있습니다.

Ah ocp pod draining

브로커 Pod가 종료되면 AMQ Broker Operator는 브로커 클러스터에서 계속 실행 중인 다른 브로커 Pod로 메시지 마이그레이션을 수행하는 스케일다운 컨트롤러를 자동으로 시작합니다. 이 메시지 마이그레이션 프로세스는 Pod 드레이닝 이라고도 합니다. 다음 섹션에서는 메시지 마이그레이션을 설명합니다.

4.11.2. 메시지 마이그레이션

메시지 마이그레이션은 배포의 의도적인 축소로 인해 클러스터형 배포의 브로커가 종료될 때 메시징 데이터의 무결성을 보장하는 방법입니다. Pod 드레이닝 이라고도 하는 이 프로세스는 종료된 브로커 Pod에서 메시지 제거 및 재배포를 참조합니다.

참고
  • 메시지 마이그레이션을 수행하는 스케일다운 컨트롤러는 단일 OpenShift 프로젝트 내에서만 작동할 수 있습니다. 컨트롤러는 별도의 프로젝트에서 브로커 간에 메시지를 마이그레이션할 수 없습니다.
  • 메시지 마이그레이션을 사용하려면 배포에 최소 두 개의 브로커가 있어야 합니다. 두 개 이상의 브로커가 있는 브로커는 기본적으로 클러스터됩니다.

Operator 기반 브로커 배포의 경우 배포에 대한 기본 브로커 사용자 정의 리소스에서 messageMigrationtrue 로 설정하여 메시지 마이그레이션을 활성화합니다.

메시지 마이그레이션 프로세스는 다음 단계를 따릅니다.

  1. 배포의 의도적인 스케일 다운으로 인해 배포의 브로커 Pod가 종료되면 Operator는 축소 컨트롤러를 자동으로 시작하여 메시지 마이그레이션을 준비합니다. 스케일다운 컨트롤러는 브로커 클러스터와 동일한 OpenShift 프로젝트 이름으로 실행됩니다.
  2. 스케일다운 컨트롤러는 자체적으로 등록하고 프로젝트의 PVC(영구 볼륨 클레임)와 관련된 Kubernetes 이벤트를 수신 대기합니다.
  3. 분리된 PV(영구 볼륨)를 확인하려면 축소 컨트롤러에서 볼륨 클레임의 오디널을 확인합니다. 컨트롤러는 볼륨 클레임의 오디널을 프로젝트의 StatefulSet (즉, 브로커 클러스터)에서 실행 중인 브로커 Pod의 항목과 비교합니다.

    볼륨 클레임의 오디널이 브로커 클러스터에서 실행 중인 브로커 Pod의 서수보다 많은 경우 축소 컨트롤러는 해당 ordinal의 브로커 Pod가 종료되고 메시징 데이터를 다른 브로커 Pod로 마이그레이션해야 함을 결정합니다.

  4. scaledown 컨트롤러는 drainer Pod를 시작합니다. drainer Pod는 브로커를 실행하고 메시지 마이그레이션을 실행합니다. 그런 다음 drainer Pod는 고립된 메시지를 마이그레이션할 수 있는 대체 브로커 Pod를 식별합니다.

    참고

    메시지 마이그레이션이 수행되려면 배포에 하나 이상의 브로커 Pod가 실행 중이어야 합니다.

다음 그림은 스케일다운 컨트롤러(레이닝 컨트롤러라고도 함)가 실행 중인 브로커 Pod로 메시지를 마이그레이션하는 방법을 보여줍니다.

Ah ocp pod draining 3

메시지가 작동 브로커 Pod로 성공적으로 마이그레이션되면 드레이닝기 Pod가 종료되고 축소 컨트롤러에서 고립된 PV의 PVC를 제거합니다. PV가 "Released" 상태로 돌아갑니다.

참고

브로커 배포를 0(zero)으로 축소하면 메시징 데이터를 마이그레이션할 수 있는 실행 중인 브로커 Pod가 없기 때문에 메시지 마이그레이션이 발생하지 않습니다. 그러나 배포를 0으로 축소한 다음 원래 배포보다 작은 크기로 백업하면 종료된 브로커에 대해 드레인더 Pod가 시작됩니다.

추가 리소스

4.11.3. 스케일 다운 시 메시지 마이그레이션

브로커 배포의 축소 시 메시지를 마이그레이션하려면 주요 브로커 CR(사용자 정의 리소스)을 사용하여 메시지 마이그레이션을 활성화합니다. AMQ Broker Operator는 클러스터형 브로커 배포를 축소할 때 메시지 마이그레이션을 실행하도록 전용 스케일다운 컨트롤러를 자동으로 실행합니다.

메시지 마이그레이션이 활성화되면 Operator 내의 스케일다운 컨트롤러에서 브로커 Pod의 종료를 감지하고 드레인러 Pod를 시작하여 메시지 마이그레이션을 실행합니다. drainer Pod는 클러스터의 다른 라이브 브로커 Pod 중 하나에 연결하고 해당 라이브 브로커 Pod로 메시지를 마이그레이션합니다. 마이그레이션이 완료되면 스케일다운 컨트롤러가 종료됩니다.

참고
  • 스케일다운 컨트롤러는 단일 OpenShift 프로젝트 내에서만 작동합니다. 컨트롤러는 별도의 프로젝트에서 브로커 간에 메시지를 마이그레이션할 수 없습니다.
  • 브로커 배포를 0(zero)으로 축소하면 메시징 데이터를 마이그레이션할 수 있는 실행 중인 브로커 Pod가 없기 때문에 메시지 마이그레이션이 수행되지 않습니다. 그러나 배포를 0 브로커로 축소한 다음 원래 배포에 있는 브로커 중 일부만 지원하는 경우, 종료된 브로커의 경우 드레이너 포드가 시작됩니다.

다음 예제 절차에서는 축소 컨트롤러의 동작을 보여줍니다.

사전 요구 사항

절차

  1. 원래 다운로드 및 추출한 Operator 리포지토리의 deploy/crs 디렉터리에서 주요 브로커 CR, broker_activemqartemis_cr.yaml 을 엽니다.
  2. 메인 브로커 CR에서 messageMigrationpersistenceEnabledtrue 로 설정합니다.

    이러한 설정은 나중에 클러스터형 브로커 배포 크기를 축소할 때 Operator는 축소 컨트롤러를 자동으로 시작하고 계속 실행 중인 브로커 Pod로 메시지를 마이그레이션합니다.

  3. 기존 브로커 배포에서 실행 중인 Pod를 확인합니다.

    $ oc get pods

    다음과 같은 출력이 표시됩니다.

    activemq-artemis-operator-8566d9bf58-9g25l   1/1   Running   0   3m38s
    ex-aao-ss-0                                  1/1   Running   0   112s
    ex-aao-ss-1                                  1/1   Running   0   8s

    앞의 출력에서는 3개의 Pod가 실행 중임을 보여줍니다. 하나는 브로커 Operator 자체와 배포의 각 브로커에 대해 별도의 Pod입니다.

  4. 각 포드에 로그인하여 일부 메시지를 각 브로커에 보냅니다.

    1. 해당 Pod ex-aao-ss-0 에 클러스터 IP 주소가 172.17.0.6 이고 다음 명령을 실행합니다.

      $ /opt/amq/bin/artemis producer --url tcp://172.17.0.6:61616 --user admin --password admin
    2. 해당 Pod ex-aao-ss-1 에 클러스터 IP 주소가 172.17.0.7 이고 다음 명령을 실행합니다.

      $ /opt/amq/bin/artemis producer --url tcp://172.17.0.7:61616 --user admin --password admin

      이전 명령은 각 브로커에 TEST 라는 큐를 생성하고 각 큐에 1000개의 메시지를 추가합니다.

  5. 클러스터를 두 브로커에서 1개로 축소합니다.

    1. 주요 브로커 CR, broker_activemqartemis_cr.yaml 을 엽니다.
    2. CR에서 deploymentPlan.size1 로 설정합니다.
    3. 명령줄에서 변경 사항을 적용합니다.

      $ oc apply -f deploy/crs/broker_activemqartemis_cr.yaml

      ex-aao-s-1 Pod가 종료되기 시작하는 것을 확인할 수 있습니다. scaledown 컨트롤러는 동일한 이름의 새 드레인러 Pod를 시작합니다. 이 드레이너 Pod는 브로커 포드 ex-aao-ss-1 의 모든 메시지를 클러스터의 다른 브로커 Pod인 ex-aao-s-0 으로 마이그레이션한 후에도 종료됩니다.

  6. drainer Pod가 종료되면 브로커 Pod ex-aao-ss-0TEST 대기열에서 메시지 수를 확인합니다. 대기열의 메시지 수가 2000개이며, 드레이너 Pod가 종료된 브로커 Pod에서 1000개의 메시지를 마이그레이션했음을 나타냅니다.