반응형

클러스터 구성이 전부 rabbitmqctl 명령어 만으로 가능하다.


1, 2, 3번 vm에다가 rabbitMQ instance를 하나씩 띄워서 테스트를 진행하였다.


선행작업으로 erlang의 cookie를 각 노드에 동일하게 맞춰주어야 한다.

vagrant로 똑같은 이미지를 사용해서 vm구성을 해서 그런지 모르겠지만, 본인 같은 경우 모두 같아서 작업을 진행하지 않았지만,

다른 경우 ~/.erlang.cookie 나 /var/lib/rabbitmq/.erlang.cookie 둘중에 하나는 있을 것이므로,

하나를 열어서 다른 머신에도 동일하게 맞춰준다.


선행작업이 완료되었으면, 클러스터 구성을 위한 모든 준비가 끝났다.

cluster join시 ip따위 지원하지 않기 때문에, 각 노드의 hostname을 /etc/hosts에 명시해두도록 한다.

hosts파일에 지정될 hostname은 cli에서 hostname이라고 나오는 hostname이 기준이 되어야 하고, 

cluster_join시에 지정될 hostname은 아래 명령어를 통해 확인을 한다.

node-1$ ./rabbitmqctl cluster_status

기본적으로 rabbit@node-1과 같이 앞에 rabbit@이 추가로 붙게 된다.


2번 노드를 1번 노드와 묶어보도록 한다.

일단 stop_app으로 source node를 죽이고 시작을 하는게 안전하다.

node-2$ ./rabbitmqctl stop_app


2번 노드를 1번 노드와 join하여 클러스터 구성을 한다. (옵션으로 --ram, --disc을 지원하는데, 해당 노드에 들어가는 데이터가 메모리만으로 동작을 할지, 디스크에서 동작을 할지를 결정한다.)

node-2$ ./rabbitmqctl join_cluster --ram rabbit@node-1


성공했으면, 2번 노드를 다시 시작하고, cluster_status를 해보면, 1번 노드와 클러스터 구성이 된 것을 확인할 수 있다.

node-2$ ./rabbitmqctl start_app

node-2$ ./rabbitmqctl cluster_status


3번 노드도 마찬가지로, 같이 묶어준다. 


클러스터 구성 시 주의할 점이 하나 있는데, 3개 노드가 전부 ram으로 동작을 하면,

미러링 구성을 한 경우, 한 대가 내려가면 모든 데이터가 날아가버리는 현상이 발생을 하기 때문에, 

disc로 동작하는 노드가 하나 존재 하도록 구성하는걸 권장한다고 한다.


위에 작성한 내용처럼 진행을 하면, 보통 1번 노드는 disc형태로 동작을 하기 때문에, 별로 신경쓰지 않아도 될 것 같다.


하지만, cluster_status로 확인 시에 모두 ram으로 돌아가고 있다면, 아래 명령어로 노드 하나는 type을 disc로 변경을 해주어야 한다.

모든 변경 작업은 stop_app 이후에 하는 게 안전하다.

node-1$ ./rabbitmqctl stop_app

node-1$ ./rabbitmqctl change_cluster_node_type disc

node-1$ ./rabbitmqctl start_app


클러스터 구성을 3대를 해두었는데, 부하량이 생각보다 적어서 하나를 제거할 경우에는, 해당 노드에 들어가서, reset을 해버리면 된다.

node-3$ ./rabbitmqctl stop_app

node-3$ ./rabbitmqctl reset


클러스터 구성이 완료되고, 이제 서로 다른 노드에 저장된 데이터들도 공유가 되게 되었다.

하지만, 노드 하나가 죽어버리면 해당 노드에 있던 데이터가 그냥 날라가버리므로 장애가 발생을 한다.


이럴 경우를 대비하여 미러링 정책 설정을 하여, 모든 노드에 데이터를 중복 저장할 수 있도록 해주는 것을 권장한다. 

test- 로 시작하는 모든 queue, exchange에 대하여 미러링 구성을 한다.

어떤 이유에서인지는 잘 모르겠지만, test-*부분을 *로 그냥 바꿔버리면, syntax가 잘못되었다고 경고메시지를 발생시킨다.

한 번에 너무 많은 처리가 이루어지는 것을 막은 것 같기도 하다.

node-1$ ./rabbitmqctl set_policy ha-all "test-*" '{"ha-mode":"all"}'


이 구성은 web admin페이지에서 admin - policy에 들어가서 더 쉽게 설정을 할 수 있다.


이제 RabbitMQ는 서비스할 수 있는 환경이 만들어지긴 했는데,

클러스터 구성이 되었다고 해서, failover같은 장애복구를 해주진 않는다.


HAProxy같은 LoadBalancer를 앞단에 두어, failover처리를 할 것을 권장한다.

다음 포스트에서는 HAProxy를 이용해 각 노드간의 load balancing을 구성해보도록 할 예정이다.

반응형

'개발 > AMQP' 카테고리의 다른 글

[RabbitMQ] CentOS RabbitMQ 3.5.3 설치  (0) 2016.06.11
[RabbitMQ] rabbitmq_management for WebAdmin  (0) 2016.06.11
,