RabbitMQ 3.1の導入とCluster構成を検証する
RabbitMQ 3.1の導入と冗長化の検証をしたのでメモ。 検証のための構成はフロントのAPサーバー、RabbitMQが動作するキューサーバー、ワーカーそれぞれ二台づつ。キューサーバーが片方死んでも全体が動作し続けられる事、両方がダウンしたとしてもデータは損失しない事が確認できれば良い。要するに単一障害点にならないようにRabbitMQを使いたい。 サーバーの準備 仮想マシン6台はVagrantを使えば一発で用意できる、メモリ16GB積んでてよかった。ホスト名を後でいじるとrabbitmqctlで停止・再起動がうまくいかなくなった。ホスト名周りはEC2で使う時に面倒な事になりそうだ。 各サーバーの /etc/hosts にrabbit1とrabbit2は追加しておく。 RabbitMQ 3.1 のインストール 起動確認 vagrant@rabbit1:~$ sudo rabbitmq-s
RabbitMQ(2.8向け)のHAクラスタ構成
RabbitMQ Highly Available Queues and Clustering using Amazon EC2 という AWS 環境での RabbitMQ クラスタ構築に関する面白い記事を見かけた。 知識の再確認のため、以下をメモ。 RabbitMQ のクラスタの構築 HA:Active-Standby(Shared Nothing) HA:Active-Standby(Shared Storage) HA:Active-Active(Mirrored Queue) RabbitMQ のクラスタリングの特徴 Erlang/OTPの 分散フレームワークをベースにしている。 ノード間でCookie(/var/lib/rabbitmq/.erlang.cookie)を同じにする ノード名(デフォルトはホスト名)をクラスタ間で重複しないようにする キューのメタ情報とキューが管理さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
