CentOs7.3 RabbitMQ 3.6 Clusterクラスタの構築サービスと使用

CentOs7.3 RabbitMQ 3.6 Clusterクラスタの構築サービスと使用
RabbitMQの概要
RabbitMQはオープンソースのAMQPで実現され、サーバー側はErlang言語で作成され、Python、Ruby、など多くのクライアントをサポートする.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMPなど、AJAX対応.分散システムに転送メッセージを格納するために使用され、使いやすさ、拡張性、高可用性などの面で俗っぽく表現されています.
AMQP、すなわちAdvanced message Queuing Protocolは、アプリケーション層プロトコルのオープンスタンダードであり、メッセージ向けミドルウェアのために設計されている.メッセージミドルウェアは主にコンポーネント間のデカップリングに用いられ、メッセージの送信者はメッセージ使用者の存在を知る必要はなく、逆も同様である.
AMQPの主な特徴は、メッセージ、キュー、ルーティング(ポイント・ツー・ポイントおよびパブリケーション/サブスクリプションを含む)、信頼性、セキュリティである.
クラスタの概要
RabbitMQクラスタは、Erlangの分散特性(magic cookie認証ノードを介して)によって行われ、各RabbitMQサービスはピアノード、すなわち各ノードはクライアント接続にサービスを提供し、メッセージ送信と受信を行う.
これらのノードは、RabbitMQ HAキュー(ミラーキュー)によってメッセージキュー構造の複製を行う.本方式では3つのノードを構築し,いずれもディスクノード(すべてのノードの状態が一致し,ノードが完全に対等である)であり,いずれかのノードが動作可能であればRabbitMQクラスタは対外的にサービスを提供できる.
環境

VMwareバージョン番号:12.0.0

CentOSバージョン:CentOS 7.3.1611

RabbitMQバージョン:RabbitMQ 3.6

仮想マシン(IP):192.168.252.101,192.168.252.102,192.168.252.103

RabbitMQのインストール
スタンドアロンマウント
まず、3台のホストにErlangをインストールRabbitMQ Serverをインストールします.
私のもう一つのCentos 7を参考にしてください.3 RabbitMQ 3.6を取り付ける
クラスタの構成
hostnameの変更
一時有効hostname
コマンドフォーマット

hostname 

3台の機械で以下の命令を実行する

192.168.252.101 $ hostname node1
192.168.252.102 $ hostname node2
192.168.252.103 $ hostname node3

変更後のhostnameの表示

$ hostname

起動クラスタを一時的に変更するのは少し問題があるようで、

はお勧めしません.
永久変更hostname
参照:linuxホスト名の変更
hostsの変更/etc/hostsファイルを編集し、3台のマシンの/etc/hostsに以下の内容を追加します.

$ vi /etc/hosts

192.168.252.101 node1
192.168.252.102 node2
192.168.252.103 node3

に注意
3台のホストに取り付けられたRabbitMQはすべて正常に起動することを保証して、やっと以下の操作を行うことができます
RabbitMQサービスの停止

$ service rabbitmq-server stop
Redirecting to /bin/systemctl stop  rabbitmq-server.service

Erlang Cookieの設定
異なるノード間で同一認証のErlang Cookieを設定する
ここでnode 1のファイルをnode 2、node 3にコピーする.このファイル権限は400が転送しやすいため、先に権限を変更し、操作しなければならないわけではないので、node 2、node 3のファイル権限を777に変更する必要がある.

$ chmod 777 /var/lib/rabbitmq/.erlang.cookie

$ scp /var/lib/rabbitmq/.erlang.cookie node2:/var/lib/rabbitmq/
$ scp /var/lib/rabbitmq/.erlang.cookie node3:/var/lib/rabbitmq/

その後、node 1のファイルをnode 2、node 3にコピーし、最後に権限と所属ユーザ/グループを

に変更する.

$ chmod 400 /var/lib/rabbitmq/.erlang.cookie
$ chown rabbitmq /var/lib/rabbitmq/.erlang.cookie
$ chgrp rabbitmq /var/lib/rabbitmq/.erlang.cookie

yesとパスワードの入力を求められます
注意事項
クッキーはすべてのノードで完全に同じでなければなりません.同期するときは注意してください.Erlangはホスト名でサービスに接続されており、各ホスト名間でpingが通じることを保証する必要があります./etc/hostsを編集することで、ホスト名とIP対応関係を手動で追加できます.ホスト名pingが通じない場合、rabbitmqサービスの起動に失敗します.
各ノードの実行

$ rabbitmqctl stop
$ rabbitmq-server -detached 

クラスタの構成
これは実行せずにノードサーバで直接下のスクリプトを実行することもできますが、このrabbitmqサービスが正常に起動していることを保証しなければなりません.

node1 $ rabbitmqctl stop_app 

先にnode2node3を順番に実行

node2 $ rabbitmqctl stop_app            #   rabbitmq  
node2 $ rabbitmqctl join_cluster rabbit@node1    # node2 node1    , node2     node1    ping 
node2 $ rabbitmqctl start_app            #   rabbitmq  
      
node3 $ rabbitmqctl stop_app            #   rabbitmq  
node3 $ rabbitmqctl join_cluster rabbit@node1    # node3 node1    , node2     node1    ping 
node3 $ rabbitmqctl start_app            #   rabbitmq  

このときnode 2とnode 3も自動的に接続されます
メモリノードの設定
このうち–ramとはメモリノードを指し、ディスクノードにしたい場合は–ramというパラメータを付けなくてもよい
メモリノードクラスタへの追加

node2 # rabbitmqctl join_cluster --ram rabbit@node1

ノードリストにそれ自体が含まれている限り、ディスクノードになります.
RabbitMQクラスタには、少なくとも1つのディスクノードが存在する必要があります.
ノードのプロパティの変更

node2 $ rabbitmqctl stop_app  #   rabbitmq  

node2 $ rabbitmqctl change_cluster_node_type ram #          
Turning rabbit@node2 into a ram node

node2 $ rabbitmqctl change_cluster_node_type disc #          
Turning rabbit@node2 into a disc node

node2 $ rabbitmqctl start_app #   rabbitmq  

クラスタのステータスの表示
実行が完了したら、各マシンでノードのステータスを表示します.

[root@node1 ~]# rabbitmqctl cluster_status
Cluster status of node rabbit@node1
[{nodes,[{disc,[rabbit@node1,rabbit@node2,rabbit@node3]}]},
 {alarms,[{rabbit@node2,[]},{rabbit@node3,[]}]}]

[root@node2 ~]# rabbitmqctl cluster_status
Cluster status of node rabbit@node2
[{nodes,[{disc,[rabbit@node1,rabbit@node2,rabbit@node3]}]},
 {running_nodes,[rabbit@node3,rabbit@node2]},
 {cluster_name,<>},
 {partitions,[]},
 {alarms,[{rabbit@node3,[]},{rabbit@node2,[]}]}]

 [root@node3 ~]# rabbitmqctl cluster_status
Cluster status of node rabbit@node3
[{nodes,[{disc,[rabbit@node1,rabbit@node2,rabbit@node3]}]},
 {running_nodes,[rabbit@node2,rabbit@node3]},
 {cluster_name,<>},
 {partitions,[]},
 {alarms,[{rabbit@node2,[]},{rabbit@node3,[]}]}]

最初の行はクラスタ内のノードメンバーであり、discはこれらがディスクノードであることを示します.
2行目は実行中のノードメンバーです
ログインバックグラウンド
RabbitMQのデフォルトのクラスタモードを構成していますが、キューの高可用性は保証されていません.スイッチ、バインドはクラスタ内のいずれかのノードにコピーできますが、キューの内容はコピーされません.このモードはノードの圧力の一部を解決しますが、キューノードのダウンタイムは直接キューが使用できなくなり、再起動を待つしかありません.したがって、キューノードがダウンタイムしたり、障害が発生したりしても正常に使用できるようにするには、クラスタ内の各ノードにキューの内容をコピーするには、ミラーキューを作成する必要があります.
ミラーキューの概念
ミラーキューはqueueとmessageを同期でき、プライマリqueueがオフの場合、queueからプライマリqueueに変更されて作業を引き継ぐことができます.
ミラーキューは通常のクラスタモードに基づいているので、ミラーキューを設定するには、通常のクラスタを構成する必要があります.
ミラーキューが設定されると、1つのプライマリノードと複数のスレーブノードが分割され、プライマリノードがダウンタイムになると、スレーブノードにプライマリノードが選択され、元のプライマリノードが立ち上がるとスレーブノードになります.
Queueとmessageは、すべてのミラーキューに存在するが、クライアントは、物理的に接続されたプライマリノードからもプライマリノードからもデータを読み出し、プライマリノードはqueueとmessageの状態をスレーブノードに同期するため、複数のクライアント接続が異なるミラーキューでは、同じmessageが複数回受け入れられることはない.
ミラーキューポリシーの設定
通常のクラスタ内の任意のノードでポリシーを有効にすると、ポリシーはクラスタノードに自動的に同期します.
コマンドフォーマット

set_policy [-p vhostpath] {name} {pattern} {definition} [priority]

任意のノードで実行

[root@node1 ~]# rabbitmqctl set_policy -p / ha-allqueue "^message" '{"ha-mode":"all"}'
Setting policy "ha-allqueue" for pattern "^message" to "{\"ha-mode\":\"all\"}" with priority "0"

注意:「^message」というルールは、「message」の先頭にあるキュー名を同期させ、構成時に使用するすべてのキューに適用するため、式は「^」です.
クラスタ再起動
クラスタが再起動されると、最後に削除されたノードは最初に再起動する必要があります.特殊な理由(例えば、同時に電源が切れるなど)で、どのノードが最後に削除されたか分かりません.次の方法で再起動できます.
まず1つのノードで実行

$ rabbitmqctl force_boot

$ service rabbitmq-server start

他のノードで実行

$ service rabbitmq-server start

clusterステータスが正常かどうかを確認します(すべてのノードでクエリーします).

$ rabbitmqctl cluster_status

おすすめ読書
CentOs7.3 RabbitMQ 3.6スタンドアロンサービスの構築
Contact

作者:鵬磊

出典:http://www.ymq.io

Email:[email protected]

著作権は作者の所有に帰して、転載して出典

を明記してください

Wechat:公衆番号に注目し、クラウドライブラリを検索し、開発技術の研究と知識の共有に専念する