반응형
반응형

https://www.rabbitmq.com/download.html 

위 링크의 공식홈에서 rabbitMQ tar ball을 받아서 압축만 풀면 설치는 끝난다.


RabbitMQ가 Erlang이라는 language기반으로 동작하기 때문에, 사전에 Erlang을 설치해주어야 한다.


소스설치가 베스트하긴 하지만, 뭔가 설치해야 될게 엄청나게 많아보여서 yum으로 설치를 진행하였다.


아래 명령어로 yum repository에 erlang repository를 등록을 해준다.


$ wget -O /etc/yum.repos.d/epel-erlang.repo http://repos.fedorapeople.org/repos/peter/erlang/epel-erlang.repo

$ yum install erlang


vagrant로 설치한 기본 vm기준으로 위 install명령으로 106개의 어플리케이션이 설치가 된다...

그렇기 때문에, RabbitMQ만을 위해 erlang을 설치하는 경우는 yum으로 패키지 설치를 추천한다.


압축을 풀어둔 RabbitMQ 폴더 기준으로 sbin 경로에 실행파일들이 몰려있다.


실행 방법은 ./rabbitmq-server를 실행하면 기본 포트 5672로 데몬이 실행이 된다. (25672는 클러스터용 포트인데 같이 뜬다.)

반응형

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

[RabbitMQ] rabbitmq_management for WebAdmin  (0) 2016.06.11
[RabbitMQ] Cluster 구성 및 설정  (0) 2016.06.11
,
반응형

AMQP를 지원하는 솔루션들은 WebAdmin 페이지를 별도로 제공을 해준다.


ActiveMQ같은 경우는 기본으로 제공을 해주고, RabbitMQ는 기본 제공은 아니고

플러그인 형태로 설치를 하면 접근이 가능하다.


아래와 같이 rabbitmq_management 플러그인을 활성화 시킨 후, 데몬을 재시작해준다.

$ /sbin/rabbitmq-plugins enable rabbitmq_management


그러면 15672포트로 admin 페이지 접근이 가능해진다.

http://localhost:15672


기본 ID/ Password는 guest / guest로 지정이 되어 있는데,

특정 버전부터 localhost에서만 접근이 가능하기 때문에, 

서버가 원격지나 VM에 있다면, 별도로 계정을 생성해서 admin권한을 넣어주어야 한다.


유저 ID가 jss, 패스워드가 1234인 유저를 추가해주고,

$ /sbin/rabbitmqctl add_user jss 1234


administrator권한을 지급한다.

$ /sbin/rabbitmqctl set_user_tags jss administrator


이후에 접근을 하면 로그인이 되면서, 모니터링 및 관리를 할 수 있는 페이지를 볼 수 있다.


RabbitMQ 기본 포트 (5672)에 커넥션을 맺을때도, admin 페이지 로그인과 마찬가지로 localhost가 아니면 접근이 되질 않기 때문에,

커넥션 정보에 username, password를 포함해주어야 한다.


추가로, virtual hosts에 대한 access권한을 필요로 하는데, 아래 화면을 참고한다.

 

admin 페이지 상단의 admin탭을 눌러서 user를 클릭하면 아래와 같은 화면이 나오는데,

여기서 access권한을 줄 수가 있다.

 


드디어, 원격지 서버에서 RabbitMQ로의 접근이 가능하게 되었다.


접근은 잘 되는데, 임의의 QueueName을 지정하여, 데이터를 Send하니 Queue가 존재하지 않는다는 메시지가 발생해서..

Admin페이지의 Queues로 들어가서 지정했던 QueueName에 해당하는 Queue를 만들어주니 Send, Recv가 정상적으로 이루어진다.

반응형

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

[RabbitMQ] CentOS RabbitMQ 3.5.3 설치  (0) 2016.06.11
[RabbitMQ] Cluster 구성 및 설정  (0) 2016.06.11
,
반응형

클러스터 구성이 전부 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
,
반응형