高可用性RabbitMQクラスターの構築と主成分分析

序文

スタンドアロン展開のみの場合、パフォーマンスには常に上限RabbitMQがありますが、例外ではありません。RabbitMQメッセージを処理する単一のサービスがボトルネックに達した場合、高可用性と負荷分散クラスターによって実現できます。

RabbitMQクラスターについてどのくらい知っていますか

通常、各クラスターには、クラスター内にノードと呼ばれるサービスRabbitMQがあり、ノードタイプは次の2つのタイプに分けることができます。

• メモリノード：メタデータはメモリに保存されます。再起動後にデータを同期するために、メモリノードはディスクノードのアドレスをディスクに保存します。さらに、メッセージが持続する場合、メモリノードは読み取りと書き込みが高速であるため、メッセージもディスクに保存されます。および一般顧客エンドはメモリノードに接続します。
• ディスクノード：メタデータはディスクに保存され（デフォルトのノードタイプ）、少なくとも1つのディスクノードを保証する必要があります。そうしないと、一度ダウンするとデータを復元できず、クラスターの高可用性の目的を達成できません。 。

PS：メタデータは、キュー名属性、スイッチタイプ名属性、バインディング情報、vhostなどの基本情報を指します。キュー内のメッセージデータは含まれません。

RabbitMQ クラスターには、通常のクラスターモードとミラーキューモードの2つの主要なモードがあります。

通常のクラスターモード

通常のクラスターモードでは、クラスター内の各ノードはメタデータを相互に同期するだけです。つまり、メッセージデータは同期されません。したがって、問題は、Aノードに接続されているBかどうかということですが、メッセージはノードに保存されており、それをどのように行うのですか？

プロデューサーであるかコンシューマーであるかに関係なく、接続されたノードがキューデータを格納しない場合、ストレージ用のキューデータを格納しているノードに内部的に転送されます。内部で転送することはできますが、メッセージは1つのノードにしか保存されないため、ノードがダウンした場合、メッセージは消えますか？この問題は存在するため、この共通クラスターモードでは高可用性の目的は達成されません。

ミラーキューモード

ミラーキューモードでは、メタデータがノード間で同期されるだけでなく、メッセージコンテンツもミラーノード間で同期され、可用性が高くなります。このソリューションは可用性を向上させますが、同期されたデータ間のネットワークオーバーヘッドももたらし、パフォーマンスにある程度影響します。

RabbitMQクラスターの構築

一緒にRabbitMQクラスターを構築してみましょう。

1. スタンドアロンバージョンより前に起動する必要がある場合は、古いデータをrm -rf /var/lib/rabbitmq/mnesia削除するか、ディレクトリ内のインストールを削除しますvar/lib/rabbitmq/mnesia。私のマシンはインストールディレクトリにインストールされ、コマンドが実行されrm -rf /usr/local/rabbitmq_server-3.8.4/var/lib/rabbitmq/mnesia/ます。

2. 次に、次の3つのコマンドを開始して、3つの異なるポート番号のRabbitMQサービスを開始RabbitMQする必要があります。また、サービスポートで追加のポートバックオフィスシステムを指定する必要がある場合を指定する必要があります。またnode、クラスターノードの名前であるため、プレフィックス名を指定する必要があります。は通信するため、ノード名は一意である必要があります。デフォルトのノード名はですrabbit@hostname。次のコマンドは、プレフィックスが指定されていることを示します。

RABBITMQ_NODE_PORT=5672 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15672}]" RABBITMQ_NODENAME=rabbit1 rabbitmq-server -detached
RABBITMQ_NODE_PORT=5673 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15673}]" RABBITMQ_NODENAME=rabbit2 rabbitmq-server -detached
RABBITMQ_NODE_PORT=5674 RABBITMQ_SERVER_START_ARGS="-rabbitmq_management listener [{port,15674}]" RABBITMQ_NODENAME=rabbit3 rabbitmq-server -detached

/usr/local/rabbitmq_server-3.8.4/var/lib/rabbitmq/mnesia/カタログの入力を開始したら、3ノード情報の作成を見つけます。

また、ps -ef | grep rabbit3つのサービスプロセスが開始されていることもわかります。

3. 開始された3つのサービスは相互に接続されていません。次に、ノードの1つをマスターノードとして使用し、他の2つのノードをマスターノードに参加させてクラスターサービスを形成する必要があります。クラスターに参加するには、リセットする必要があります。ノード情報、つまりデータのあるノードはクラスターに参加できません。

//rabbit2 节点重置后加入集群
rabbitmqctl -n rabbit2 stop_app
rabbitmqctl -n rabbit2 reset
rabbitmqctl -n rabbit2 join_cluster --ram rabbit1@`hostname -s` //--ram 表示这是一个内存节点
rabbitmqctl -n rabbit2 start_app

rabbitmqctl -n rabbit3 stop_app
rabbitmqctl -n rabbit3 reset
rabbitmqctl -n rabbit3 join_cluster --disc rabbit1@`hostname -s` //--disc表示磁盘节点（默认也是磁盘节点）
rabbitmqctl -n rabbit3 start_app

4. 成功した後、コマンドrabbitmqctl cluster_statusクエリノードrabbit1ステータスを実行すると、次の図が表示されます。2つのディスクノードがメモリノードです。

5. ここで開始されたクラスターは、デフォルトの通常のクラスターにすぎないことに注意してください。ミラーリングされたクラスターを構成する場合は、次のコマンドを実行する必要があります。

rabbitmqctl -n rabbit1 set_policy ha-all "^" '{"ha-mode":"all"}'

ここでRabbitMQは、ビルドが完了していてもクラスターですが、これはスタンドアロンバージョンであるため.erlang.cookie、ファイルの整合性を考慮しないでください。

HAProxy + Keepalivedに基づく高可用性クラスター

RabbitMQクラスタの場合、複数のメモリノードがあり、ノードが接続されている場所で行う必要がありますか？この選択戦略をクライアント側で行うと、大きなデメリットがあります。最も深刻なのは、クラスターを拡張するたびにクライアントコードを変更する必要があることです。したがって、この方法はあまり望ましくないため、デプロイしています。クラスター。中間プロキシコンポーネントが必要な場合、このコンポーネントRedisは、Sentinel（センチネル）クラスターモードなどのサービスの監視と転送を有効にするために、センチネルRedisノードとフェイルオーバーを監視できます。

ではRabbitMQ、クラスタによってKeepalivedおよびHAProxy部品2の高可用性と負荷分散クラスタを実現しています。

HAProxy

HAProxyまた、負荷分散ソフトウェアとして使用することができ、オープンソースの高性能負荷分散ソフトウェア、であるnginx、lvsなど レイヤーの負荷分散とレイヤーの負荷分散をHAproxyサポートします。74

負荷分散

以下に示す、モデルの目的のためのいわゆる7レイヤーロードバランシングと4レイヤーロードバランシングOSIは、OSI通信モデルです。

上の図を見ると、最初の7層はアプリケーション層に4対応し、2番目の層はトランスポート層に対応しています。負荷分散ソフトウェアとして一般的に使用されるのは、通常nginx、第17層で機能し、lvs通常は第1層で機能します（Linux Virtual Server）4。

• 4 レイヤーロード：

4レイヤーロードは、NAT（ネットワークアドレス変換）テクノロジー、つまりネットワークアドレス変換を使用します。クライアント要求を受信するときは、データパッケージのソースIPとポートを変更してから、対応するターゲットサーバーにパケットを転送します。4レイヤーロードバランシングは、メッセージ内の宛先アドレスと送信元アドレスに基づいてのみ要求を転送でき、要求されたリソースの特定のタイプを決定または変更することはできません。

• 7 レイヤーロード：

クライアントから要求されたリソースパスに従って、別のターゲットサーバーに転送されます。

高可用性HAProxy

HAProxy負荷分散は実現されていますが、1つしか導入されていない場合HAProxy、ダウンタイムのリスクがあります。一度HAProxyダウンし、それは我々がする必要があるので、クラスタ全体が、使用できない原因となりますHAProxyまた、クラスタを実装する場合、HAProxyまた、クラスタを実現し、クライアントがどのサービスに接続する必要がありますか？問題は最初に戻っているようで、無限ループに陥っています...

キープアライブ

HAProxy高可用性を実現するために、Keepalivedコンポーネントを導入する必要があります。Keepalivedコンポーネントには、主に次の特性があります。

• ロード機能により、クラスター内のノードの状態を監視できます。クラスター内のノードがダウンした場合、フェイルオーバーを実現できます。
• クラスター自体も実現できますが、masterノードは1つだけです。
• master外部ノードは仮想IPアプリケーション側を提供し、これを回線に接続するだけで済みますIP。クラスタHAProxyノードは仮想をめぐって競合することも理解できます。仮想はIP、どのノードが競合に参加し、ノードがサービスを提供します。

VRRPプロトコル

VRRPプロトコルは、仮想ルーター冗長プロトコル（仮想ルーター冗長プロトコル）です。Keepalived仮想IPメカニズムがに属しているVRRP場合、フォールトトレラントプロトコルルーターの単一障害点の出現を回避するためです。

総括する

このホワイトペーパーでは、RaabbitMQ関連するナレッジクラスターについて説明し、通常のクラスターとクラスターミラーの違いを比較し、最後にRabbitMQクラスターを構築するための実践を通じて、一般的なクラスターHAProxyとKeepalivedコンポーネントを組み合わせて真の高可用性分散クラスターサービスを実現できるいくつかの欠点を紹介します。