수 많은 우문은 현답을 만든다

RabbitMQ Cluster 구성 본문

개발지식/RabbitMq

RabbitMQ Cluster 구성

aiden.jo 2022. 7. 6. 19:06

안녕하세요~ 조영호입니다.

오늘은 Rabbitmq의 고가용성을 보장하기 위해서 클러스터를 구성한 경험을 공유하겠습니다.

Rabbitmq Cluster는 Active-StandBy 구성입니다. Active 큐의 내용을 StandBy가 복제받는 형태입니다.
 

클러스터는 아래 스펙의 3대 서버로 구성 해보겠습니다.

OS : Ubuntu-18.04-KEP
SPEC : vCPU: 4개, Memory: 16GB
Volume : 50GB

 

1.  Rabbitmq 설치

sudo apt-get install -y rabbitmq-server

sudo rabbitmq-plugins enable rabbitmq_management

(삭제는 apt purge -y rabbitmq-server 를 수행한다. remove는 설정파일이 그대로 남는다.)

-> 이대로 설치하면 구 버전이 깔립니다.
필자의 경우 apt-get intall 하면 최신버전이 깔리겠거리 하는 안일한 생각 덕분에 클러스터를 구성해놓고 재 구성하는 일이 발생했습니다.
여러분도 조심하시기 바랍니다. (욕 먹어서 배가 아주 부릅니다.)

 

1-1. Erlang 설치

Erlang 은 동시성 및 분산 시스템을 개발하는데 사용되는 프로그래밍 언어입니다.
erlang에는 분산처리기능이 내장되어 있어서 이 기능으로 서로 다른 서버의 rabbitmq 간에도 요청을 주고받을 수 있습니다.

설치 방법은 공식문서에서 확인할 수 있고 필자는 우분투를 기준으로 설치하겠습니다.

sudo apt-get install erlang

 

1-2. Rabbitmq 최신버전 설치

최신 버전 역시 OS 별로 공식문서에서 설치할 수 있고 필자는 우분투를 기준으로 설치하겠습니다.

더보기 
#!/usr/bin/sh

sudo apt-get install curl gnupg apt-transport-https -y

## Team RabbitMQ's main signing key
curl -1sLf "https://keys.openpgp.org/vks/v1/by-fingerprint/0A9AF2115F4687BD29803A206B73A36E6026DFCA" | sudo gpg --dearmor | sudo tee /usr/share/keyrings/com.rabbitmq.team.gpg > /dev/null
## Launchpad PPA that provides modern Erlang releases
curl -1sLf "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xf77f1eda57ebb1cc" | sudo gpg --dearmor | sudo tee /usr/share/keyrings/net.launchpad.ppa.rabbitmq.erlang.gpg > /dev/null
## PackageCloud RabbitMQ repository
curl -1sLf "https://packagecloud.io/rabbitmq/rabbitmq-server/gpgkey" | sudo gpg --dearmor | sudo tee /usr/share/keyrings/io.packagecloud.rabbitmq.gpg > /dev/null

## Add apt repositories maintained by Team RabbitMQ
sudo tee /etc/apt/sources.list.d/rabbitmq.list <<EOF
## Provides modern Erlang/OTP releases
##
## "bionic" as distribution name should work for any reasonably recent Ubuntu or Debian release.
## See the release to distribution mapping table in RabbitMQ doc guides to learn more.
deb [signed-by=/usr/share/keyrings/net.launchpad.ppa.rabbitmq.erlang.gpg] http://ppa.launchpad.net/rabbitmq/rabbitmq-erlang/ubuntu bionic main
deb-src [signed-by=/usr/share/keyrings/net.launchpad.ppa.rabbitmq.erlang.gpg] http://ppa.launchpad.net/rabbitmq/rabbitmq-erlang/ubuntu bionic main

## Provides RabbitMQ
##
## "bionic" as distribution name should work for any reasonably recent Ubuntu or Debian release.
## See the release to distribution mapping table in RabbitMQ doc guides to learn more.
deb [signed-by=/usr/share/keyrings/io.packagecloud.rabbitmq.gpg] https://packagecloud.io/rabbitmq/rabbitmq-server/ubuntu/ bionic main
deb-src [signed-by=/usr/share/keyrings/io.packagecloud.rabbitmq.gpg] https://packagecloud.io/rabbitmq/rabbitmq-server/ubuntu/ bionic main
EOF

## Update package indices
sudo apt-get update -y

## Install Erlang packages
sudo apt-get install -y erlang-base \
                        erlang-asn1 erlang-crypto erlang-eldap erlang-ftp erlang-inets \
                        erlang-mnesia erlang-os-mon erlang-parsetools erlang-public-key \
                        erlang-runtime-tools erlang-snmp erlang-ssl \
                        erlang-syntax-tools erlang-tftp erlang-tools erlang-xmerl

## Install rabbitmq-server and its dependencies
sudo apt-get install rabbitmq-server -y --fix-missing

위 스크립트대로 실행하시면 설치가 완료됩니다.

 

잘 설치되었나 버전을 확인해볼까요?

sudo rabbitmqctl version
> 3.10.7

 

* 주의사항 *

사용하시는 VM 마다 보안 설정의 정도가 다르겠지만, 필자가 사용하는 VM 같은 경우 아래 설정들이 필요했습니다.

1. curl을 쏘기 위한 외부로의 통신을 위한 보안 정책 설정

2. 리눅스 전역에 프록시 설정

3. apt-get 커맨드에 대한 프록시 설정

 

 

 

2. 호스트 등록

설치 외에 가장 먼저 해야 할 단계는 호스트 등록 입니다.

말 그대로 각 서버(또는 VM)이 서로를 인식할 수 있도록 host를 등록 해 줘야 합니다.

cat /etc/hosts
127.0.0.1               localhost.localdomain  localhost
10.182.95.x1 rabbitmq1.com rabbitmq1

sudo vi /etc/hosts
127.0.0.1               localhost.localdomain  localhost
10.182.95.x1 rabbitmq-1.com rabbitmq-1
10.182.94.x2 rabbitmq-2.com rabbitmq-2
10.182.94.x3 rabbitmq-3.com rabbitmq-3

 

변경 후에는 서버(또는 VM)를 재부팅해서 hosts 파일의 변경사항을 반영할 수 있습니다.

서로간에 호스트 등록을 하지 않으면 아래의 에러가 뜨는데, 필자는 이 스텝을 누락해서 하루넘게 고통을 맛보았습니다..

 

반영이 잘 되었는지 확인해보겠습니다.

cat /etc/hosts
127.0.0.1               localhost.localdomain  localhost
10.182.95.x1 rabbitmq-1.kep.k9d.in rabbitmq-1
10.182.94.x2 rabbitmq-2.kep.k9d.in rabbitmq-2
10.182.94.x3 rabbitmq-3.kep.k9d.in rabbitmq-3

 

 

 

3.  얼랭 쿠키 값 통일

각 서버들은 서로 통신하기 위해서 Rabbitmq의 비밀 키인 Erlang cookie 를 공유해야 합니다.
리눅스에서는 보통 /var/lib/rabbitmq/.erlang.cookie 에 존재합니다. 우리는 하나의 서버를 특정하고 그 서버의 쿠키 값을 다른 서버들에도 복사해 주도록 하겠습니다.

값을 통일하는 방법으로는 4가지 정도가 있습니다.

1. vi 에디터 사용

2. git repository 로 복사

3. scp 로 직접 복사

4. File Storage 로 공유

 

필자가 위 다양한 케이스를 시도한 이유는, 아래 오류를 만나면서 쿠키 값이 잘못되었다고 생각했기 때문이었습니다.

물론 시행착오를 겪고 결국 통일해서 아래 오류는 해결했지만 결국에는 호스트간에 인식을 못했던 문제가 남아있었습니다.

 

위 오류의 원인은 쿠키 파일에 설정된 권한 때문인데, 얼랭쿠키 파일은 항상 읽기 전용이어야합니다. 그래서 수정할때 강제로 w!를 사용해서 쿠키 값을 덮어쓰지말고, 쓰기 권한을 임시로 풀었다가 수정 후에 읽기 전용으로 원복하는 방법을 사용하면 되겠습니다.

sudo chmod 755 /var/lib/rabbitmq/.erlang.cookie

cat /var/lib/rabbitmq/.erlang.cookie
-> 1번 MQ의 쿠키값을 복사합니다. QTBDECOBVSLXLMHYAHFA

sudo vi /var/lib/rabbitmq/.erlang.cookie
-> 2번, 3번 MQ의 쿠키값에 위 값을 덮어 씌우고 저장합니다.

sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie

cd /var/lib/rabbitmq && ll | grep .erlang
-> 권한이 -rwxr-xr-x 에서 다시 -r-------- 로 변경됨을 확인할 수 있습니다.

 

얼랭쿠기 값을 맞춘 다음에는 반드시 rabbitmq-server를 재부팅을 해줘야합니다.
sudo systemctl restart rabbitmq-server

sudo systemctl status rabbitmq-server
Active: active (running)

 

 

4.  클러스터 구성하기

이제 본격적으로 클러스터를 구성해보고자 합니다.

1번 MQ에 2번, 3번 MQ를 붙이도록 할 예정입니다. 우선 rabbitmq-1과 rabbitmq-2 두 대의 VM을 연결해보겠습니다.

 

연결은 staging-rabbitmq-2 -> staging-rabbitmq-1 방향으로 클러스터에 참여하는 형태로 진행해야합니다.

단, 이 때 각 노드들은 4369, 25672 포트로 서로 TCP 연결이 가능한 상태여야 합니다.

- 4369 : 노드가 서로의 호스트를 확인할 때 사용됩니다.

- 5672, 5671 : AMQP 로 TLS가 필요할땐 5671을 사용합니다.

- 15672 : HTTP API 클라이언트 및 rabbitmqadmin 을 사용할때 필요합니다.

- 25672 : 노드간 통신에 필요한 포트입니다.

 

# 포트확인
netstat -nlp | grep -e 4369 -e 25672 | grep -v tcp6
tcp        0      0 0.0.0.0:25672           0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:4369            0.0.0.0:*               LISTEN      -                   

# 2번 노드 중지
sudo rabbitmqctl stop_app

# 2번 노드 다시 세팅
sudo rabbitmqctl reset

# 1번 노드의 정보 확인
sudo rabbitmqctl cluster_status
Cluster status of node 'rabbit@rabbitmq1'
[{nodes,[{disc,['rabbit@rabbitmq1']}]},
 {running_nodes,['rabbit@rabbitmq1']},
 {cluster_name,<<"rabbit@rabbitmq1.com">>},
 {partitions,[]},
 {alarms,[{'rabbit@rabbitmq1',[]}]}]
 
# 2번->1번 클러스터 조인
# cluster_name이 아닌 nodes 값을 붙여줘야합니다.
# 참고로 클러스터링을 할때는 방화벽에서 80(http) 443(https) 포트를 열어줘야합니다. 
# VM 간 호출이 되어야 하기 때문이죠! (방화벽이 막혀있으면 nodedown 오류메세지가 납니다)
sudo rabbitmqctl join_cluster rabbit@rabbitmq1

# 노드 시작
sudo rabbitmqctl start_app

# 클러스터 상태 확인
sudo rabbitmqctl cluster_status
Cluster status of node 'rabbit@rabbitmq2'
[{nodes,[{disc,['rabbit@rabbitmq1','rabbit@rabbitmq2',
                'rabbit@rabbitmq3']}]},
 {running_nodes,['rabbit@rabbitmq1','rabbit@rabbitmq3',
                 'rabbit@rabbitmq2']},
 {cluster_name,<<"rabbit@rabbitmq1.com">>},
 {partitions,[]},
 {alarms,[{'rabbit@rabbitmq1',[]},
          {'rabbit@rabbitmq3',[]},
          {'rabbit@rabbitmq2',[]}]}]

3번 노드는 이미 클러스터가 구성된 상태이기 때문에 1번 또는 2번 아무데나 연결해도 됩니다.

 

 

5.  클러스터 노드 타입 변경

RabbitMQ의 노드 종류로는 RAM, Disk 두 가지 타입이 있습니다.

타 블로그들을 보면 속도 향상을 위해 1개 Disk와 2개 RAM으로 구성한다는 글들이 있었고 아래 몇 가지 궁금함이 들었습니다.

 

5-1. RAM 노드는 메모리를 쓰니까 rabbitmq의 속도를 향상시킬까요?

공식 문서를 읽어보면 RAM 노드는 메모리를 사용한다고 해서 Rabbitmq의 높은 처리율이나 더 빠른 속도를 제공하는게 아닙니다. 단지 메타데이터를 RAM에 저장하기 때문에 queue/exchange/binding의 변동이 많을때 클러스터의 성능 자체를 개선시킬 수 있다고 합니다. 이 말은 메세지, 메세지 인덱스, 대기열 인덱스 등의 정보가 RAM에는 저장되지 않는다는 이야기와 같습니다.

 

5-2. 그럼 유일한 1개의 DISK 노드가 죽으면 데이터 손실은 없을까요? 

RAM 노드는 시작시 DISK 노드에서 동기화를 받아야하기 때문에, 메세지 정보나 persistent queue 등의 데이터를 저장하고 있는 DISK가 죽으면  등의 DISK가 저장했던 내용들을 RAM 노드가 동기화 받을 수 없습니다. 실제로 마지막 남은 DISK 노드는 수동으로 지울 수 없습니다. 

 

1.  RAM 타입 :
노드들의 상태(state)를 메모리에 저장하기 때문에 변동이 많은 클러스터링 구성시 성능 향상을 기대할 수 있습니다.

하지만, 클러스터가 정전 등으로 다운되면 데이터가 모두 유실되어 복구가 어렵습니다. 그래서 공식문서에서는 클러스터에는 최소한 1개의 Disk 노드가 있어야 한다고 명시되어 있습니다. 참고로 메세지 유실에 대비하기 위한 Durable Queue 는 예외적으로 Disk에 안전하게 저장됩니다.

 

2. Disk 타입 :

Disk 타입은 노드들의 상태를 메모리와 디스크에 가지고있습니다.
RAM모드 보다는 성능이 떨어지지만 클러스터의 상태를 안전하게 저장해 복구에 용이하다는 장점이 있습니다.

 

우리는 1개의 Disk, 2개의 RAM 노드로 클러스터를 구성하도록 하겠습니다.

변경 : 3개 모두 Disk 노드로 구성하며 3중화 Replication 용도로 사용하기로 했습니다. (2022.08.23)

# 2, 3번 노드 중지
sudo rabbitmqctl stop_app

# 2, 3번 노드 타입 변경
sudo rabbitmqctl change_cluster_node_type ram

# 노드 시작
sudo rabbitmqctl start_app

# 상태 확인
sudo rabbitmqctl cluster_status
[{nodes,[{disc,['rabbit@rabbitmq1','rabbit@rabbitmq3']},
         {ram,['rabbit@rabbitmq2']}]},

 


6.  클러스터 빠져나오기

클러스터를 구성하다보면 관계가 꼬이거나 오류가 날 때가 있습니다.

그럴때는 각 노드에서 stop, reset을 해주면 클러스터에서 빠지게 되는데, 클러스터링 기준이 되었던 노드 (여기서는 1번 노드) 에는 문제가 생긴 노드 정보가 그대로 남아있습니다. 이 경우에는 기준이 되는 노드에서도 문제가 생긴 노드를 제외시켜줘야 합니다.

# 3번 서버를 클러스터에서 제거
sudo rabbitmqctl stop_app
Stopping node rabbit@rabbit3 ...done.

sudo rabbitmqctl reset
Resetting node rabbit@rabbit3 ...done.

sudo rabbitmqctl start_app
Starting node rabbit@rabbit3 ...done.

# 클러스터 기준이되는 1번노드에서 3번노드를 제거하기.
sudo rabbitmqctl forget_cluster_node rabbit@rabbit3
Removing node rabbit@rabbit1 from cluster ...done.

 

 

 

7.  미러링(Mirroring) 구성 - HA

노드들은 서로 Exchange와 Binding 은 기본적으로 공유를 하지만 Queue는 각각 가지기 때문에 만약 특정 노드가 다운 되면 해당 노드의 데이터들은 유실을 피할 수 없습니다. 미러링 설정은 하나의 마스터와 여러 미러 노드로 구성되어 모든 요청은 마스터 노드가 우선 처리하고 미러 노드로 복사 전파하는 방식으로 고가용성(HA)을 제공합니다. 미러링을 구성하면 Consumer는 노드의 구분 없이 모든 노드를 통해 메시지를 가져올 수 있습니다. 예를 들어, 미러 노드로 메시지가 들어온 경우에는 미러 노드가 마스터 노드에게 이 사실을 전달합니다.

 

자바 애플리케이션에서는 아래와 같이 메세지큐들의 호스트명을 나열해서 등록해줄 수 있습니다.

# application.yml
rabbitmq:
    addresses: bizmsg-staging-rabbitmq-1.kep.k9d.in:5672,bizmsg-staging-rabbitmq-2.kep.k9d.in:5672,bizmsg-staging-rabbitmq-3.kep.k9d.in:5672
    
# MqConfig.java
@Primary
@Bean("connectionFactory")
CachingConnectionFactory connectionFactory(@Value("${spring.rabbitmq.username}") String username,
                                           @Value("${spring.rabbitmq.password}") String password,
                                           @Value("${spring.rabbitmq.addresses}") String addresses,
                                           @Value("${env.grp}") String grpId) {
    CachingConnectionFactory connectionFactory = new CachingConnectionFactory();
    connectionFactory.setVirtualHost(grpId);
    connectionFactory.setPassword(password);
    connectionFactory.setUsername(username);
    connectionFactory.setAddresses(addresses);
    return connectionFactory;
}

 

자 이제는 다시 서버환경으로 돌아와서 클러스터에 미러링을 구성해보겠습니다.

# 클러스터 모든 노드의 Queue를 미러링하기.
#여기서 .* 패턴은 큐의 이름을 대상으로, 해당하는 큐들에 ha-all 정책을 걸겠다는 의미이다.
$ rabbitmqctl set_policy ha-all ".*" '{"ha-mode":"all"}'

# 지정한 개수의 리플리카만 생성
$ rabbitmqctl set_policy ha-two "^two\\." '{"ha-mode":"exactly", "ha-params": 2, "ha-sync-mode": "automatic"}'

# 지정한 이름의 노드만 미러링
$ rabbitmqctl set_policy ha-nodes "^nodes\\." '{"ha-mode": "nodes", "ha-params": ["rabbit@nodeA", "rabbit@nodeB"]}'

필자는 모든 노드의 HA가 필요하기 때문에 첫 번째 방식을 사용했습니다.

 

 

 

8. 한 걸음 더 나아가기

미러링 된 Rabbitmq Cluster 구조는 아래와 같습니다.

 

1. 미러링(HA)이 구성된 상태라면 Client Application에서는 하나의 노드에만 연결하면 될까?

-> 아닙니다. 만약 해당 노드가 죽게되면 다른 노드와 연결할 수 있도록 Application에서 설정을 하거나 앞에 Load Balancer를 두어야합니다. 필자는 LB를 두는 대신 Springboot 자체에서 여러개의 주소를 등록해서 쓸 수 있는 설정을 사용했습니다.

 

2. 미러링을 많이 할 수록 메세지 처리량이 떨어질까?

-> 그렇습니다. Master Queue와 Slave Queue 사이의 Mirroring은 기본적으로 Sync 방식입니다. 즉 Producer가 Mirroring된 Queue에게 Message를 전송하면 RabbitMQ는 받은 Message를 Master Queue에만 넣고 Producer에게 ACK를 보내는 것이 아니라, 모든 Slave Queue와 Mirroring이 완료된 후에야 Producer에게 ACK를 보냅니다다. 따라서 Slave Queue의 개수가 많아질 수록 오히려 Message 처리량이 떨어지게 됩니다. 

 

3. 미러링을 해서 메세지가 꼬일수도 있지 않은가?

-> 아닙니다. Slave Queue가 있어도 Producer의 모든 Message는 오직 Master Queue로만 전달되고, Consumer에게 전달되는 Message는 오직 Master Queue로부터 전송되는 Message입니다. Slave Queue는 오직 Master Queue와 Mirroring하는 동작만을 수행하기 때문에 Slave Queue의 개수를 늘려도 Message 처리량은 분산되지 않습니다. 언제나 Master Queue가 기준이 되기 때문에 Producer가 보낸 Message 순서대로 Consumer에게 전달되는 것을 알 수 있습니다.

 

4. 한 개 Disk, 두 개 Ram 의 HA 구조에서 Disk(Master Queue)가 죽으면 통신 불가상태가 되는것 아닌가?
-> 아닙니다. Master Queue가 있는 RabbitMQ가 죽으면 일반적으로 Slave Queue 중에서 가장 오래된 Slave Queue가 Master Queue로 승격됩니다(대단해~!). 이때 RabbitMQ는 기본적으로 Unsynchronised Slave Queue(기존 HA 외 새로운 큐)를 승격 대상에서 제외시키게 되는데, 만약 모든 Slave Queue가 Unsynchronised 상태에서 Master Queue의 RabbitMQ가 죽는다면 Master Queue의 RabbitMQ가 복구될때까지 해당 Queue는 이용하지 못하고 메세지 유실이 발생할 것 입니다. 이때는 메세지를 다시 보낼 수 있도록 에러 메세지 처리를 잘 해야합니다.

 새로 생성된 Slave Queue는 Master의 데이터들을 기본적으로 가지고 있지 않습니다. 보통은 시간이 지남에 따라서 Master가 계속 Message들을 전달하기 때문에 Unsynchronised Slave Queue는 결국에는 Synchronised Slave Queue가 됩니다. 이에 대해서 대안으로 ha-sync-mode를 설정할 수도 있지만, 이 설정을 키게되면 Sync하는 동안 해당 Queue가 무응답 상태가 되기 때문에 가용성에 좋지않은 영향을 줄 수 있습니다. 때문에 자연스럽게 소비되어 Sync되게 하는게 좋다고 생각합니다.

 

 

9. 접속방법

우선 rabbitmq management를 활성화 시켜야합니다. (필자는 첫번째 설치 단계에서 플러그인을 활성화 했습니다.)

rabbitmq-plugins enable rabbitmq_management

 

 

브라우저로 접속을 합니다

http://rabbitmq-1.com:15672/

 

접속하려면 사용자가 있어야겠지요! 유저를 추가하겠습니다.

sudo rabbitmqctl add_user test test

sudo rabbitmqctl set_user_tags test administrator

sudo rabbitmqctl set_permissions -p / test ".*" ".*" ".*"

sudo rabbitmqctl list_permissions
  Listing permissions in vhost "/"
  test .* .* .*
  guest .* .* .*

 

 

10. 결과물

1번, 2번, 3번 Node 가 하나의 클러스터로 묶인것을 확인할 수 있습니다.

 

 

11. 미러링 결과 확인

* 22.08.04, Rabbitmq Management에 들어가서 각 Queue Details 정보를 보면 Mirrors 정보가 없다는 질문이 들어왔다.

 

실제로 다른 블로그들을 아래와같이 미러링 정보가 있었다.

 

그런데 내가 구성한 클러스터에는 이 정보가 비어있었다.

내가볼땐 Rabbitmq Management 마다 버전이 상이해서 좀 다를 수도 있다고 생각이 들었지만 확인을 해보기로 했다.

각 Rabbitmq 서버에 접속해서 sudo rabbitmqctl list_queues 를 때려보면 아래와같이 모든 큐가 복제되어 쓰고있는 것을 볼 수 있다.

 

 

12. Rabbitmq 오프라인 설치

금융권  프로젝트나 네트워크가 제한된 환경에서는 소프트웨어를 오프라인으로 설치해야할 때가 있다.

방법은 주로 인가된 CD나 USB등을 사용할 수 있는데, 위에서 알아본 Rabbitmq의 오프라인 설치 방법을 공유하고자한다.

우선 rabbitmq 를 수동설치 하기 위해서는 elang 디펜던시들과 rabbitmq-server 패키지가 있어야한다.

 

STEP 1. 이미 Rabbitmq가 설치된 서버에서 필요한 패키지들을 USB로 옮긴다.

- 로컬로 반출 : scp -r deploy@hostname:/var/cache/apt/archives/ /Users/

 

STEP 2. 반출된 목록을 확인한다.

- ubuntu, erlang, gpg, gnupg, rabbitmq 등의 .deb 파일들이 들어있다.

 

STEP 3. 신규 서버로 복사한다.

-  scp -r /Users/archives deploy@newHostname:/var/cache/apt/archives
* /var에 접근 권한이 제공되지 않는 경우, 우선 루트로 복사한다음 cp한다.

 

STEP 4. Rabbitmq 설치

- sudo dpkg -i *

 

13. 클러스터 상태 확인

클러스터의 정보는 rabbitmqctl 커맨드 또는 rabbitmq-management UI에서 확인할 수 있다.

 

1. 런타임, 플러그인, 데이터/설정/로그파일 저장 위치, 자원사용량 등을 확인

$ sudo rabbitmqctl status

더보기

Runtime

OS PID: 22328
OS: Linux
Uptime (seconds): 5413065
RabbitMQ version: 3.10.7
Node name: rabbit@bizmsg-staging-rabbitmq-1
Erlang processes: 74575 used, 1048576 limit
Scheduler run queue: 1
Cluster heartbeat timeout (net_ticktime): 60

Plugins

Enabled plugin file: /etc/rabbitmq/enabled_plugins
Enabled plugins:

 * rabbitmq_management
 * rabbitmq_management_agent

Data directory

Node data directory: /var/lib/rabbitmq/mnesia/rabbit@bizmsg-staging-rabbitmq-1
Raft data directory: /var/lib/rabbitmq/mnesia/rabbit@bizmsg-staging-rabbitmq-1/quorum/rabbit@bizmsg-staging-rabbitmq-1

Log file(s)

 * /var/log/rabbitmq/rabbit@bizmsg-staging-rabbitmq-1.log
 * /var/log/rabbitmq/rabbit@bizmsg-staging-rabbitmq-1_upgrade.log
 

Memory

Total memory used: 2.0676 gb
Memory high watermark setting: 0.4 of available memory, computed to: 6.7277 gb

reserved_unallocated: 0.4866 gb (23.53 %)
connection_other: 0.4384 gb (21.2 %)
allocated_unused: 0.2541 gb (12.29 %)
queue_procs: 0.2243 gb (10.85 %)
...


File Descriptors

Total: 129, limit: 32671
Sockets: 42, limit: 29401

Free Disk Space

Low free disk space watermark: 0.05 gb
Free disk space: 96.6405 gb

Totals

Connection count: 42
Queue count: 6260
Virtual host count: 2

Listeners

Interface: [::], port: 25672, protocol: clustering, purpose: inter-node and CLI tool communication
Interface: [::], port: 15672, protocol: http, purpose: HTTP API
Interface: [::], port: 5672, protocol: amqp, purpose: AMQP 0-9-1 and AMQP 1.0

 

2. 연결정보 확인

더보기

Listing connections ...
user peer_host peer_port state


bizmsg 10.182.62.251 55668 running
bizmsg 10.182.61.209 53930 running
bizmsg 10.182.61.209 34200 running
bizmsg 10.182.61.209 35248 running
bizmsg 10.182.60.204 38524 running
bizmsg 10.182.60.204 42126 running
bizmsg 10.182.61.209 42410 running
bizmsg 10.182.60.204 49404 running
bizmsg 10.182.60.204 37122 running

 

3. 그 외 유용한 정보 확인

sudo rabbitmqctl list_permissions
sudo rabbitmqctl list_bindings
sudo rabbitmqctl list_consumers
sudo rabbitmqctl list_exchanges
sudo rabbitmqctl list_queues
sudo rabbitmqctl schema_info
sudo rabbitmqctl environment


* 메세지 데이터 위치 : /var/lib/rabbitmq/mnesia/rabbit@rabbitmq-1/msg_stores/vhosts/9Z4DK158J4S8Y2U409YVE1G6K/msg_store_persistent

 

 

감사합니다.

 

 

 

 

참고

https://jonnung.dev/rabbitmq/2019/08/08/rabbitmq-cluster/

https://teragoon.wordpress.com/2012/02/24/rabbitmq-cluster-%EA%B5%AC%EC%84%B1%ED%95%98%EA%B8%B0/

https://teragoon.wordpress.com/2012/01/26/message-durability%EB%A9%94%EC%8B%9C%EC%A7%80-%EC%9E%83%EC%96%B4%EB%B2%84%EB%A6%AC%EC%A7%80-%EC%95%8A%EA%B8%B0-durabletrue-propspersistent_text_plain-2/

http://abh0518.net/tok/?p=411 

https://ssup2.github.io/theory_analysis/RabbitMQ_Clustering_Mirroring/