カテゴリー「rabbitmq」

rabbitmqでクラスターを組む際、

クラスターに参加するノードすべてが名前解決によって、

他ノードに接続する仕様となっている。

hostsファイルやdnsmasqなどの簡易DNSを立てるのが簡単ではあるが、

クラウド環境を使っていると、hostsファイルやresolve.confファイルなどが、

再起動等で書き換えられしまうケースもある。

そこで、独自に名前解決を行う必要があるのだが、

erlangの名前解決手法が意外にハマったので、

クラスターの構築手順と合わせて備忘録を残しておく。

 

[バージョン]

os:centos7.2

rabbitmq:3.6.10(rpmで入れた)

 

[前提]

各ノードの情報は以下の通り。

  • 192.168.15.11(ホスト名はbroker01)
  • 192.168.15.12(ホスト名はbroker02)
  • 192.168.15.13(ホスト名はbroker03)

 

[クラスターの構築手順]

1.インストールしたら、とりあえずbroker01,02,03の全台で起動

# systemctl start rabbitmq

この時点では各ノードが個別に動いている状態である。

 

2.broker01,02,03に/etc/rabbitmq/hostsというファイルを以下内容で配備

192.168.15.11 broker01
192.168.15.12 broker02
192.168.15.13 broker03

 

3.brker01,02,03に/etc/rabbitmq/erl_inetrcというファイルを以下内容で配備

{hosts_file, "/etc/rabbitmq/hosts"}.
{lookup, [file,native]}.

 

4.broker01に/etc/rabbitmq/rabbitmq-env.confというファイルを以下内容で配備

export ERL_INETRC=/etc/rabbitmq/erl_inetrc

RABBITMQ_NODENAME=rabbit@broker01
# ↓の設定は、独自です。なければ、デフォルトが適用されます。
RABBITMQ_LOGS=/var/log/rabbitmq/rabbitmq.log
RABBITMQ_SASL_LOGS=/var/log/rabbitmq/rabbitmq-sasl.log
RABBITMQ_PID_FILE=/var/run/rabbitmq/rabbitmq.pid
RABBITMQ_NODE_IP_ADDRESS=0.0.0.0
RABBITMQ_NODE_PORT=5672
RABBITMQ_DIST_PORT=5675

 

5.broker02に/etc/rabbitmq/rabbitmq-env.confというファイルを以下内容で配備
export ERL_INETRC=/etc/rabbitmq/erl_inetrc

RABBITMQ_NODENAME=rabbit@broker02
# ↓の設定は、独自です。なければ、デフォルトが適用されます。
RABBITMQ_LOGS=/var/log/rabbitmq/rabbitmq.log
RABBITMQ_SASL_LOGS=/var/log/rabbitmq/rabbitmq-sasl.log
RABBITMQ_PID_FILE=/var/run/rabbitmq/rabbitmq.pid
RABBITMQ_NODE_IP_ADDRESS=0.0.0.0
RABBITMQ_NODE_PORT=5672
RABBITMQ_DIST_PORT=5675

6.broker03に/etc/rabbitmq/rabbitmq-env.confというファイルを以下内容で配備
export ERL_INETRC=/etc/rabbitmq/erl_inetrc

RABBITMQ_NODENAME=rabbit@broker03
# ↓の設定は、独自です。なければ、デフォルトが適用されます。
RABBITMQ_LOGS=/var/log/rabbitmq/rabbitmq.log
RABBITMQ_SASL_LOGS=/var/log/rabbitmq/rabbitmq-sasl.log
RABBITMQ_PID_FILE=/var/run/rabbitmq/rabbitmq.pid
RABBITMQ_NODE_IP_ADDRESS=0.0.0.0
RABBITMQ_NODE_PORT=5672
RABBITMQ_DIST_PORT=5675

 

7.broker01,02,03に/etc/rabbitmq/rabbitmq.configというファイルを以下内容で配備

[
  {rabbit,
    [
      {loopback_users, []},
      {tcp_listen_options,
        [
          {backlog, 1024},
          {nodelay, true},
          {exit_on_close, false}
        ]
      },
      {vm_memory_high_watermark, 0.4},
      {disk_free_limit, "2GB"},
      {cluster_partition_handling, pause_minority}
    ]
  },
  {rabbitmq_management,
    [
      {listener, [{port, 5676}]}
    ]
  }
].

上記はあくまで一例で、ノード分断の際の生き残り戦略として、小数をダウンさせるという設定にしてます。

 

8.broker01,02,03の/var/lib/rabbitmq/.erlang.cookieファイルの内容を同じにする。
ここで、同ファイルの所有者はrabbitmq:rabbitmqで、権限は0400とする。

 

上記状態で、全ノードを再起動することで、

クラスター状態が完成する。

 

あと、rabbitmq-server.serviceファイルはちょっと変更して以下のようにしている。

デフォルトだと、nofile,noprocあたりがなかったような気がする。。

[Unit]
Description=RabbitMQ broker
After=syslog.target network.target

[Service]
Type=notify
User=rabbitmq
Group=rabbitmq
WorkingDirectory=/var/lib/rabbitmq
ExecStart=/usr/sbin/rabbitmq-server
ExecStop=/usr/sbin/rabbitmqctl stop
NotifyAccess=all
TimeoutStartSec=3600
LimitNOFILE=65536
LimitNPROC=65536

[Install]
WantedBy=multi-user.target

 

公式のドキュメントにだいたい書いてある通りですが。。

気になるのは、hugepageとか、OSレベルのIOのスケジューリングとかかな。

あとは、負荷テストやるのみ。。

また、負荷テストやったら書こうと思います。

 

以上

投稿日時:2017年06月24日 22:50   カテゴリー:rabbitmq   [コメントがあればどうぞ]

信頼性の高いメッセージキューを使って、

遅延処理を行うケースの重要性について最近考えるようになった。

そのため、AMQPとか調べていて、rabbitmqを使ってみようかと考えた。

 

とはいえ、rabbitmqはAMQP0.9をベースとしており、

AMQP1.0をベースにしていないなどの点において、

採用候補としては迷うところである。

ActiveMQとかの方がいいかもね、という考えもある。

AMQPではないが、kafkaなどもよさげではあるが、

簡単に調べて、rabbitmqが良さげな点としては、

  • 貧弱サーバでもある程度動く(と思っている)
  • クラスター機能が単体で存在している

といったところでしょうか。

riakを検証しててなんとなくわかったのですが、

開発言語であるerlangはそれほど大きなメモリを使わず、

マルチコアの利用も上手な印象であったため、

他サーバへの相乗り等、縮小することも考えると、悪くないかなーといった具合で検証を進めるてみることにしたというわけです。

ActiveMQやkafkaだと、貧弱サーバで動かすのは厳しい感じがしてます。。

 

で、簡単ながら、検証してみたことろ、メッセージの信頼性の度合はプログラムに依存するような印象を持ってます。

rabbitmq本体に、キューのタイプなどを定義できるのかなーと思っていたが、

特段相違そのような設定などは見られなったため、

プログラムの書き手が信頼性の確保処理の速度について理解しておく必要があるという点が、

中々やっかいでもある反面、融通も効きやすい感じである。

また、諸々検証したら続きを書いてみようと思う。

 

以上

 

投稿日時:2017年06月11日 23:37   カテゴリー:rabbitmq   [コメントがあればどうぞ]