RabbitMQ를 Kubernetes로 원활하게 마이그레이션

RabbitMQ는 Erlang으로 작성된 메시지 브로커로, 각 노드가 읽기 및 쓰기 요청을 처리할 수 있는 여러 노드에 걸쳐 전체 데이터 복제를 통해 장애 조치 클러스터를 구성할 수 있습니다. 프로덕션 작업에 많은 Kubernetes 클러스터가 있기 때문에 우리는 다수의 RabbitMQ 설치를 지원하고 가동 중지 시간 없이 한 클러스터에서 다른 클러스터로 데이터를 마이그레이션해야 하는 필요성에 직면했습니다.

최소한 두 가지 경우에 이 작업이 필요했습니다.

1. Kubernetes에 없는 RabbitMQ 클러스터에서 이미 "kubernetized"(즉, K8s 포드에서 작동 중인) 새 클러스터로 데이터를 전송합니다.
2. Kubernetes 내의 RabbitMQ를 한 네임스페이스에서 다른 네임스페이스로 마이그레이션합니다(예를 들어 회로가 네임스페이스로 구분된 경우 한 회로에서 다른 회로로 인프라를 전송하는 경우).

기사에서 제안된 레시피는 이미 K3s 또는 일부 오래된 서버에 위치한 오래된 RabbitMQ 클러스터(예: 8개 노드)가 있는 상황(그러나 이에 국한되지는 않음)에 초점을 맞추고 있습니다. Kubernetes(이미 존재하거나 향후에 있을)에서 호스팅되는 애플리케이션은 다음과 같이 작동합니다.

...그리고 우리는 이를 Kubernetes의 새로운 프로덕션으로 마이그레이션하는 작업에 직면했습니다.

먼저, 마이그레이션 자체에 대한 일반적인 접근 방식을 설명한 다음 구현에 대한 기술적 세부 사항을 설명합니다.

마이그레이션 알고리즘

어떤 조치를 취하기 전 첫 번째 예비 단계는 이전 RabbitMQ 설치에서 고가용성 모드가 활성화되어 있는지 확인하는 것입니다(HA). 그 이유는 분명합니다. 우리는 어떤 데이터도 잃고 싶지 않습니다. 이 확인을 수행하려면 RabbitMQ 관리 패널로 이동하여 관리 → 정책 탭에서 값이 설정되어 있는지 확인하세요. ha-mode: all:

다음 단계는 Kubernetes 포드에서 새 RabbitMQ 클러스터를 생성하는 것입니다(예를 들어, 3개의 노드로 구성되지만 개수는 다를 수 있음).

그런 다음 이전 RabbitMQ 클러스터와 새 RabbitMQ 클러스터를 병합하여 단일 클러스터(6개 노드)를 얻습니다.

이전 RabbitMQ 클러스터와 새 RabbitMQ 클러스터 간의 데이터 동기화 프로세스가 시작됩니다. 클러스터의 모든 노드 간에 모든 데이터가 동기화되면 새 클러스터를 사용하도록 애플리케이션을 전환할 수 있습니다.

이러한 작업 후에 RabbitMQ 클러스터에서 이전 노드를 제거하면 충분하며 이동이 완료된 것으로 간주될 수 있습니다.

우리는 생산 과정에서 이 방식을 여러 번 사용해 왔습니다. 그러나 우리는 편의를 위해 여러 Kubernetes 클러스터에 표준 RMQ 구성을 배포하는 특수 시스템 내에서 이를 구현했습니다. (궁금하신 분들을 위해: 우리는 애드온 연산자우리에 대해 방금 최근에 말했어). 아래에서는 제안된 솔루션을 실제로 시도하기 위해 누구나 설치에 적용할 수 있는 개별 지침을 제시합니다.

실제로 해보자

요구 사항

세부 사항은 매우 간단합니다.

1. Kubernetes 클러스터(minikube도 작동함)
2. RabbitMQ 클러스터(베어메탈에 배포할 수 있으며 공식 Helm 차트에서 Kubernetes의 일반 클러스터처럼 만들 수 있음)

아래 예에서는 RMQ를 Kubernetes에 배포하고 이를 호출했습니다. rmq-old.

스탠드 준비

1. Helm 차트를 다운로드하고 약간 편집합니다.

helm fetch --untar stable/rabbitmq-ha

편의상 비밀번호를 설정해 놓았습니다. ErlangCookie 그리고 정치를 해라 ha-all기본적으로 대기열은 RMQ 클러스터의 모든 노드 간에 동기화됩니다.

rabbitmqPassword: guest
rabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we
definitions:
policies: |-
  {
    "name": "ha-all",
    "pattern": ".*",
    "vhost": "/",
    "definition": {
      "ha-mode": "all",
      "ha-sync-mode": "automatic",
      "ha-sync-batch-size": 81920
    }
  }

2. 차트를 설치합니다.

helm install . --name rmq-old --namespace rmq-old

3. RabbitMQ 관리 패널로 이동하여 새 대기열을 생성하고 여러 메시지를 추가합니다. 마이그레이션 후 모든 데이터가 보존되고 아무것도 손실되지 않았는지 확인하는 데 필요합니다.

테스트 벤치가 준비되었습니다. 전송해야 할 데이터가 있는 "이전" RabbitMQ가 있습니다.

RabbitMQ 클러스터 마이그레이션

1. 먼저 새로운 RabbitMQ를 배포해 보겠습니다. другом 네임스페이스 같은 ErlangCookie 및 사용자의 비밀번호. 이를 위해 위에서 설명한 작업을 수행하고 RMQ 설치를 위한 최종 명령을 다음과 같이 변경합니다.

helm install . --name rmq-new --namespace rmq-new

2. 이제 새 클러스터를 이전 클러스터와 병합해야 합니다. 이렇게 하려면 각 포드로 이동하세요. 새로운 RabbitMQ를 실행하고 다음 명령을 실행합니다.

export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && 
  rabbitmqctl stop_app && 
  rabbitmqctl join_cluster $OLD_RMQ && 
  rabbitmqctl start_app

변수에서 OLD_RMQ 노드 중 하나의 주소를 찾았습니다. 오래된 RMQ 클러스터.

이 명령은 현재 노드를 중지합니다. 새로운 RMQ 클러스터를 이전 클러스터에 연결하고 다시 시작합니다.

3. 6개 노드의 RMQ 클러스터가 준비되었습니다.

모든 노드 간에 메시지가 동기화되는 동안 기다려야 합니다. 메시지 동기화 시간은 클러스터가 배포된 하드웨어의 용량과 메시지 수에 따라 다르다는 것을 추측하는 것은 어렵지 않습니다. 설명된 시나리오에서는 그 중 10개만 있으므로 데이터가 즉시 동기화되었지만 메시지 수가 충분히 많으면 동기화가 몇 시간 동안 지속될 수 있습니다.

따라서 동기화 상태는 다음과 같습니다.

여기에 +5 메시지가 이미 있음을 의미합니다. 더 많은 5개 노드(필드에 표시된 항목 제외) Node). 이렇게 동기화가 성공했습니다.

4. 남은 것은 애플리케이션의 RMQ 주소를 새 클러스터로 전환하는 것뿐입니다(여기서 구체적인 작업은 사용 중인 기술 스택 및 기타 애플리케이션 세부 사항에 따라 다름). 그 후에는 이전 클러스터에 작별 인사를 할 수 있습니다.

마지막 작업의 경우(즉, 이미 후 애플리케이션을 새 클러스터로 전환) 각 노드로 이동 오래된 클러스터링하고 다음 명령을 실행합니다.

rabbitmqctl stop_app
rabbitmqctl reset

클러스터가 이전 노드를 "잊었습니다". 이전 RMQ를 삭제하면 이동이 완료됩니다.

주의: 인증서와 함께 RMQ를 사용하는 경우 근본적으로 변경되는 사항은 없습니다. 이동 프로세스는 정확히 동일하게 수행됩니다.

조사 결과

설명된 체계는 RabbitMQ를 마이그레이션하거나 단순히 새 클러스터로 이동해야 하는 거의 모든 경우에 적합합니다.

우리의 경우 RMQ가 여러 곳에서 액세스되는 경우 단 한 번만 어려움이 발생했으며 모든 곳에서 RMQ 주소를 새 주소로 변경할 기회가 없었습니다. 그런 다음 기존 서비스 및 Ingress에 속하도록 동일한 레이블을 사용하여 동일한 네임스페이스에서 새 RMQ를 시작했으며, 포드를 시작할 때 레이블을 수동으로 조작하여 요청이 해당 경로에 포함되지 않도록 처음에 레이블을 제거했습니다. RMQ를 비우고 메시지가 동기화된 후 다시 추가합니다.

RabbitMQ를 구성이 변경된 새 버전으로 업데이트할 때 동일한 전략을 사용했습니다. 모든 것이 시계처럼 작동했습니다.

PS

이 자료의 논리적 연속으로 우리는 MongoDB(하드웨어 서버에서 Kubernetes로 마이그레이션) 및 MySQL(Kubernetes 내부에서 이 DBMS를 준비하는 방법)에 대한 기사를 준비하고 있습니다. 그들은 앞으로 몇 달 안에 출판될 것입니다.

PPS

블로그에서도 읽어보세요.

• «데이터베이스 및 Kubernetes(개요 및 동영상 보고서)";
• «K8s 팁과 요령: 대규모 데이터베이스의 부트스트랩 속도 향상".

출처 : habr.com