- 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だとミラー（同期）に多くのリソースを持っていかれる可能性がある - ↑のような場合には
3node 構成にしておいて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が効いてるっぽい安心だけどどのモードでも