DevOpsナレッジハブ
DevOpsナレッジハブ

RabbitMQアクティブ-パッシブクラスター構築のステップバイステップガイド

高可用性を実現するための堅牢なRabbitMQアクティブ-パッシブクラスターの構成方法を学びましょう。このガイドでは、事前準備、必須のErlangクッキー同期、クラスターノードの結合、そしてアクティブノードがダウンした際にデータの一貫性とシームレスなサービスフェイルオーバーを確保するためのミラーリングポリシー (`ha-mode:all`) の適用について解説します。

42 ビュー

RabbitMQ アクティブ/パッシブ・クラスター展開のためのステップバイステップ・ガイド

ミッションクリティカルなメッセージングサービスに高可用性（HA）を実装するには、堅牢な冗長性が必要です。RabbitMQのアクティブ/パッシブ・クラスター設定は、これを実現するための古典的なアプローチであり、アクティブノードがダウンした場合に、指定されたパッシブノードが迅速に引き継ぐことでダウンタイムを最小限に抑えることができます。本ガイドでは、前提条件、ノード設定、シームレスなフェイルオーバー機能の確保を網羅した、このようなデプロイメントを構成するための包括的なステップバイステップのプロセスを提供します。

このデプロイメントパターンは、標準的なRabbitMQクラスタリングと、障害発生時のIPアドレス引き継ぎを管理するための外部メカニズム（Pacemakerやシンプルなスクリプトなど）に依存しています。本ガイドでは、HAセットアップの基盤となるRabbitMQクラスタリングの側面に焦点を当てます。

アクティブ/パッシブ・クラスターの前提条件

設定を開始する前に、意図するすべてのクラスターノード（ノードA - アクティブ、ノードB - パッシブ）で以下の前提条件が満たされていることを確認してください。

  1. 同一のソフトウェア・バージョン: すべてのノードで、RabbitMQ ServerとErlang/OTPのバージョンが完全に一致している必要があります。
  2. ネットワーク到達性: すべてのノードが、必要なポート（AMQPのデフォルトは5672、クラスタリングは25672）を介して相互に通信できる必要があります。
  3. ホスト解決: すべてのノードで/etc/hostsファイル（またはDNS）を設定し、各ノードが他のすべてのノードのホスト名を確実に解決できるようにします。
  4. Cookieの一貫性: Erlangの「マジッククッキー」がすべてのノードで同一でなければなりません。これは、ノードがクラスタリングのために相互に信頼するために不可欠です。

Erlangクッキーは、ノードが安全に通信できるかどうかを決定します。これは、最初に初期化されたノードから他のすべてのノードにコピーする必要があります。

ノードA（最初のノード）で実行:

クッキーファイル（通常はインストール方法により /var/lib/rabbitmq/.erlang.cookie または ~/.erlang.cookie）を見つけ、その内容をコピーします。

ノードB（およびそれ以降のノード）で実行:

  1. RabbitMQサービスを停止します。
    bash sudo systemctl stop rabbitmq-server
  2. 既存のクッキーファイルを、ノードAからコピーした内容で置き換え、適切なパーミッション（通常は400）を確保します。
    bash # echoを使用した例（必要に応じて内容を置き換えてください） echo "YOUR_LONG_COOKIE_STRING" | sudo tee /var/lib/rabbitmq/.erlang.cookie sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie
  3. ノードBでサービスを開始します。
    bash sudo systemctl start rabbitmq-server

ステップ1: ホスト名とネットワーキングの設定

ノードAとノードBの両方で、ホストファイルがホスト名を正しくマッピングしていることを確認します。

/etc/hostsの例（両方のサーバーで）:

192.168.1.10   rabbitmq-node-a
192.168.1.11   rabbitmq-node-b

ステップ2: 最初のクラスターノード（アクティブ）の初期化

ノードAが、クラスターが最初に確立される初期プライマリノードになります。

  1. ノードAでサービスを開始します（まだ実行されていない場合）。
    bash sudo systemctl start rabbitmq-server
  2. ステータスの確認: ノードが正しく実行されていることを確認します。
    bash rabbitmqctl status

ステップ3: 2番目のノード（パッシブ）をクラスターに参加させる

次に、ノードBにノードAがリードするクラスターに参加するように指示します。

  1. ノードBでサービスを停止します（実行中の場合）。
    bash sudo systemctl stop rabbitmq-server

  2. 参加コマンド: ノードBで参加コマンドを実行し、ノードAのホスト名をピアとして指定します。
    bash rabbitmqctl join_cluster rabbit@rabbitmq-node-a
    ヒント: /etc/hostsで定義したホスト名を使用します。

  3. ノードBでサービスを開始します:
    bash sudo systemctl start rabbitmq-server

ステップ4: クラスター形成の検証

ノードAにログインし、両方のノードがお互いを認識していることを確認します。

rabbitmqctl cluster_status

期待される出力スニペット:

running_nodesの下にrabbitmq-node-aとrabbitmq-node-bの両方がリストされているはずです。

Cluster status of node rabbit@rabbitmq-node-a ...
[{nodes,[{disc,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]}]},
 {running_nodes,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]},
 ...
]

ステップ5: 高可用性（キューのクラスタリング）の設定

標準的なRabbitMQクラスタリングでは、ノードはメタデータ（ユーザー、エクスチェンジ）を共有できますが、キュー内のメッセージは、特定のHAポリシーが適用されない限り、通常自動的には複製されません。真のActive-Passiveフェイルオーバーのためには、ミラー化されたキューを使用する必要があります。

ポリシーの定義

ポリシーは、キューに一致するパターンに適用され、キューがクラスター全体でいくつ存在し、どこで昇格されるかを定義します。

クラスター全体でミラーリングを強制するために、いずれかのノードでrabbitmqctl set_policyコマンドを使用します（パターンは"^"）。

```bash

'ha-all'という名前のポリシーを設定し、任意の名前（"^"）に一致するキューを

クラスター内のすべてのノード（合計3ノード）にミラーリングし、'promote'動作を設定します。

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"'