- Amazon Linux
- t1.micro
を利用。以下の通り、クラスタ 3 台構成。
- RabbitMQ クラスタ HA 構成 3 パターン
- クラスタを構成
- それぞれ HA パターンを設定
- Ruby からキューの出し入れを行う
- HA パターンによるキューの出し入れに対する挙動をパターン別に確認する
- 以下の 3 つのパターン(モード)がある
ha-mode | ha-params | Result |
---|---|---|
all | 無し | キューはクラスタ内のすべてのノード間でミラーリングされる。新しいノードがクラスタに追加されるとキューはそのノードにミラーリングされる。 |
exactly | count | キューは count に指定した数のノードにミラーリングされる。但し、クラスタ内のノード数が count より>少ない場合には全てのノードにコピーされる。 |
nodes | node names | キューは node names に指定したノードにミラーリングされる。 |
ha-mode
はset_policy
でキューの名前をパターンマッチにて指定することでキュー毎に適用出来る- 以下の例では
'^.*'
としているので全てのキューに対して適用されることになるので注意 - キューパターンを
'^.*'
で指定した場合には後から指定したモードで上書きされてしまうので要注意
- 基本的な書式
rabbitmqctl set_policy ${ha-mode} ${queue_name_match_pattern} '{"ha-mode": "${ha-mode}","ha-params":${param},"ha-sync-mode":"${mode_pattern}"}'
- 設定
rabbitmqctl set_policy all '^.*' '{"ha-mode": "all"}'
- 設定
rabbitmqctl set_policy one "^.*" '{"ha-mode":"exactly","ha-params":1,"ha-sync-mode":"automatic"}'
- 設定
rabbitmqctl set_policy node_test "^.*" '{"ha-mode":"nodes","ha-params":["rabbit@ip-xxx-xxx-x-xxx"],"ha-sync-mode":"automatic"}'
ミラー対象となるノードを配列で渡す。
HA
構成に必要と思われる set_policy
とか clear_policy
とか list_policies
とか。ここ見よう。
rabbitmqctl set_policy all '^.*' '{"ha-mode": "all"}'
rabbitmqctl list_policies
以下のように出力される。
Listing policies ...
/ one ^.* {"ha-mode":"exactly","ha-params":1,"ha-sync-mode":"automatic"} 0
/ two ^.* {"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"} 0
...done.
rabbitmqctl clear_policy ${policy_name}
- キューの登録先は指定したホストに登録される
- 全てのノードにミラーリングされる
- 特定のノードからキューを削除してもミラー先にはミラーリングされたキューとメッセージは残っており、ミラーリングされたノードからキューメッセージは取り出せる
"ha-params":1
で試す- キューは登録したノードのみに存在するがクラスタ内のどこのノードからでもメッセージを取り出すことは出来る(クラスタノードが全て元気な場合)
- キューが登録されているノードがダウン(
stop_app
)した場合、メッセージは当然取り出せなくなる
"ha-params":2
で試す- キューは登録したノードのみに存在するがクラスタ内のどこのノードからでもメッセージを取り出すことは出来る(クラスタノードが全て元気な場合)
- キューが登録されているノードがダウン(
stop_app
)した場合でもメッセージは取り出すことが出来る - キューが登録されたノード、ミラーリングされたノード、全てのノードがダウンした場合には...残念ながらキューは喪失する
1
ノードへのみのミラーリング- キューは登録したノードとミラー先のノードに存在するがクラスタ内のどこのノードからでもメッセージを取り出すことは出来る(クラスタノードが全て元気な場合)
- キューを登録したノードを
stop_app
してもミラー先のキューからメッセージを取り出すことが出来る - ミラー先を
stop_app
するとキューが消えてしまいメッセージを取り出すことが出来ない
- 安全を考慮するなら
all
- 大量のキューが同時に発生するようなサービスの場合には
all
だとミラー(同期)に多くのリソースを持っていかれる可能性がある - ↑のような場合には
3
node 構成にしておいてexactly
の"ha-params":2
にしておくと良さそう
- How To Cluster Rabbit-MQ
- .erlang.cookie のコピーの仕方
- Deleting queues in rabbitmq
rabbitmqctl stop_app
→rabbitmqctl reset
→rabbitmqctl start_app
でノード上のキューは消える- 但し、
rabbitmqctl reset
を行った時点でクラスタノードだった場合にはクラスタから外れてしまうので注意する
- キューの HA モードを変更した場合にパターンにマッチするキューは手動でキューの同期を行う必要がある
上図は exactly
の "ha-params":1
からの all
に変更した状態。
気づいたこと
デフォルトの HA
構成モード暗黙のall
が効いてるっぽい安心だけどどのモードでも