RabbitMQの高可用性クラスターの構築

RabbitMQクラスターはerlangクラスターに依存しており、クラスターは.erlang.cookieによって認証された部分を通信するerlang であるため、RabbitMQクラスターは.erlang.cookieファイルを構成するだけで使用できます。以下は、C#を使用してRabbtiMQクラスターを駆動するだけの小さなクリを備えた、RabbitMQ高可用性クラスターの構築の簡単なデモです。

1 RabbitMQ高可用性クラスターを構築する

  まず、3つのデバイスを準備します。3台のCentos7の仮想マシンは、各仮想マシンがお互いにpingを実行できるかどうかをテストするために、ここで使用されている。彼らはお互いにpingを実行できる場合は、各仮想マシン上でのRabbitMQをインストールしてください。あなたはを参照することができます最初の記事インストール方法

手順1ホスト構成を変更する

   マシン間の相互アクセスを容易にするために、3つすべてのcentosがvim / etc / hostsを実行し、次の構成を追加します(自分のデバイスのIPを変更するように注意してください)。

192.168.70.129 rabbitmq1
192.168.70.131 rabbitmq2
192.168.70.133 rabbitmq3

  一般に、hostsファイルの内容は次のとおりです。

ステップ2:.erlang.cookieファイルを変更する

  3つのデバイスの.erlang.cookieのキーを変更して、一貫性を持たせます。以前のインストール方法を使用している場合、.erlang.cookieの場所は/var/lib/rabbitmq/.erlang.cookieです(他のインストール方法でファイルが見つからない場合は、コマンドfind / -name'.erlang.cookieを使用できます'ファイルの場所を探します)。ここでの3つの仮想マシンのキーはすべて、192.168.70.129のキーを使用します(値はCRRQPKHDXEEIUJUOGYKN)。他の2つのデバイスで、vim /var/lib/rabbitmq/.erlang.cookieコマンドを実行し、ファイルの内容をCRRQPKHDXEEIUJUOGYKNに変更します。変更中に権限の問題が発生した場合は、コマンドchmod 600 /var/lib/rabbitmq/.erlang.cookieを実行して、ファイルの権限を書き込み可能に変更します。変更が完了したら、コマンドchmod 400 / var / lib / rabbitmq /を実行します。 erlang.cookieはファイルを再び読み取り専用に変更します。

  上記の2つの手順を完了すると、erlangクラスターがセットアップされ、すべてのデバイスを再起動できます。rabbitmq1ノードの仮想マシンでコマンドrabbitmqctl cluster_statusを実行して、クラスターのステータスを表示します。

 ステップ3:ノードを追加/削除する

ノードを追加

  rabbitmq2ノードをクラスターに追加するには、rabbitmq2ノードで次のコマンドを実行します。

rabbitmqctl stop_app
rabbitmqctlリセット
rabbitmqctl join_cluster rabbit @ rabbit1
rabbitmqctl start_app

  実行が完了したら、クラスターのステータスを確認し、次のようにrabbitmq2がすでにクラスター内にあることを確認します。

  上記の手順を繰り返してrabbitmq3をクラスターに追加し、rabbitmq3ノードで次のコマンドを実行します。
rabbitmqctl stop_app
rabbitmqctlリセット
rabbitmqctl join_cluster rabbit @ rabbit2
rabbitmqctl start_app
  次のように、クラスターのステータスを確認します。rabbitmq3もクラスター内にあります。  

  この時点で、任意のノードのWeb管理インターフェースを開くと、表示は次のようになり、クラスターが構成されています。


  ノードの削除 theクラスタからノードを削除するのは非常に簡単です。ノードをリセットするだけです。rabbitmq3ノードを削除する場合は、rabbitmq3で次のコマンドを実行します。
rabbitmqctl stop_app
rabbitmqctlリセット
rabbitmqctl start_app

  実行が完了したら、次のようにクラスターのステータスを確認します。

   現在構築されているクラスタはデフォルトの通常のクラスタです。通常のクラスタ内のノードは、クラスタ内の交換、ルーティングキー、およびキューを共有できますが、キュー内のメッセージは、キューが最初に宣言されたノードにのみ保存されます。任意のノードのコンシューマーは、他のノードからのメッセージを消費できます。たとえば、rabbitmq1ノード(コードで接続が確立されたときに使用されるrabbitmq1のIP)に接続するコンシューマーは、ノードrabbitmq2のキューmyqueue2内のメッセージを消費できます。メッセージ送信プロセスは、 :Rabbitmq2はmyqueue2のメッセージをrabbtimq1に送信し、次にrabbitmq1ノードがメッセージをコンシューマーに送信します。キュー内のメッセージは、キューが最初に宣言されたノードにのみ保存されるため、ノードに障害が発生した場合、ノードが再接続してノード内のメッセージの処理を続行することしかできません(設定されていない場合)永続化の場合、メッセージはノードがハングアップした直後に失われます。次の図に示すように、rabbitmq1ノードがハングアップすると、myqueueキューがダウンしてアクセスできなくなります。

  上記の質問に答えて、次のように考えるかもしれません:rabbitmqのノードをredisクラスターのノードのように作成できる場合、各ノードはすべてのメッセージを保存します。たとえば、rabbitmq1は自身のキューmyqueueのメッセージを保存するだけでなく、他のノードのメッセージも保存しますキューmyqueue2とmyqueue3のメッセージは、rabbitmq2ノードとrabbitmq3ノードで同じであるため、ダウンタイムを心配する必要はありません。rabbitmqもそのような機能を提供します:ミラーキュー。ミラーキューはマスターと複数のスレーブで構成され、ミラーキュー内のメッセージは、コンシューマがデータをフェッチするときに一時的にプルされるのではなく、ミラーノード間で自動的に同期されます。

手順4:ミラーキューを構成する

  rabbitmqでミラーキューを構成するのは非常に簡単です。任意のノードノードで次のコマンドを実行して、ミラーキューの構成を完了できます(もちろん、Web管理インターフェイスでポリシーを追加することもできます)。

コードをコピー

rabbitmqctl set_policy ha-all "^ my" '{"ha-mode": "all"、 "ha-sync-mode": "automatic"}'ha-all:戦略の名前です。^ my:一致する文字です。1つだけの^はすべてに一致することを意味します。^ abcは名前がabcで始まるキューまたは交換です。ha-mode:同期モードです。合計3つのモードがあります。
#①all-all(すべてのノードがメッセージを同期します)、
#②ノード数を正確に指定(ha-paramsパラメーターを構成する必要があります。このパラメーターは2などのintタイプで、クラスター内の2つのノード同期メッセージをランダムに抽出します)
#③nodes-特定のノードを指定します(ha-paramsパラメーターを構成する必要があります。このパラメーターは["rabbit @ rabbitmq1"、 "rabbit @ rabbitmq2"]のような配列タイプです。これらの2つのノードで同期メッセージを明確に指定してください)。

コードをコピー

  Web管理インターフェイスを開きます。次のような効果がある場合は、ミラーリングキューが構成されていることを意味します。myqueueの現在のマスターノードはrabbitmq1です。

  初めてキューを宣言するノード(マスター)がハングした場合、他のノードは自動的にマスターになります。上の図に示すように、myqueueのマスターはrabbitmq1です。rabbtmq1を停止すると、次のような結果になります:rabbitmq2がマスターになります。

 

  rabbitmq1ノードが電話を切ると、rabbitmq2が自動的にmyqueueのノードになります。myqueueはダウンせず、メッセージは通常どおり追加/削除/取得できます。これにより、通常のクラスターのダウンタイムの問題が解決されます。ミラーリングされたキューを使用すると、各ノードがメッセージを同期する必要があるため、リソースが消費されます。通常、ミラーリングされたキューは、信頼性の高いシナリオで使用されます。

他の戦略のミラーキューを構成することもでき、構成は1行のコマンドで完了することができます。他のいくつかの同期モード:

#戦略名はha-tweで、「my」で始まるキューまたは交換に一致し、クラスター内のミラーノードをランダムに選択します。同期されるノードの数は2です。
rabbitmqctl set_policy ha-two "^ my" '{"ha-mode": "exactly"、 "ha-params":2、 "ha-sync-mode": "automatic"}'
#ポリシー名はha-nodesであり、「my」で始まるキューまたは交換に一致し、rabbit @ rabbitmq2およびrabbit @ rabbitmq3を同期ノードとして指定します
rabbitmqctl set_policy ha-nodes "^ my" \ '{"ha-mode": "nodes"、 "ha-params":["rabbit @ rabbitmq2"、 "rabbit @ rabbitmq3"]}'

おすすめ

転載: blog.csdn.net/u014748504/article/details/108535344