ベースHAProxy + keepalivedのビルドRabbitMQの高可用性クラスタ

クラスタはじめに

1.1クラスタアーキテクチャ

単一のメッセージの処理能力がRabbitMQのサーバのボトルネックに到達すると、この時間は、スループット向上の目的を達成するように、RabbitMQのクラスタによって拡張することができます。RabbitMQのクラスタは、1つまたは複数のノードの論理的なグループ、クラスタ内の各ノードであるピアは、すべてのユーザが共有する各ノード、仮想ホスト、キュー、スイッチ、結合関係、及び分布の他の実行時パラメータステータスを入力します。高可用性、負荷分散のRabbitMQクラスタアーキテクチャは、次のようになります。

ここでは、クラスタアーキテクチャについての上記の説明を行うには：

まず、基本のRabbitMQクラスタは、クラスタキューを共有しますが、デフォルトでは、メッセージがキュー上のノードの条件に適合するようにルーティングされ、他のノード上の同じキューに同期されませんが、高可用性ではありません。メッセージは私のキューキューノード1、ノード1にルーティングされたが、突然ダウンしていると仮定すると、メッセージが失われる、この問題を解決したい、あなたはキューのミラーを開く必要があり、ミラーを互いにクラスタキューに、この時点でのメッセージそれは鏡の中の同じパケット内のすべてのキューにコピーされます。

第二のRabbitMQクラスタ自体は、3ノードクラスタのためと言うことです負荷分散機能を提供していない、各ノードは、経由でソフトウェアまたはハードウェアの負荷をロードバランシングのバランスをとることができ、この問題を解決しようとすると、同じではありませんロードすることができここでは、他の負荷分散ミドルウェア、などLVSなどなどを使用することももちろん可能のHAProxyロードバランシングを、使用することを選択しました。それは接続の非常に高い数をサポートよく作られたことができるようにHAProxyは、4と7のロードバランシング、および単一のプロセスに基づいてイベント駆動型モデルの両方をサポートしています。

そして、それは、障害の明白な単一点であり、我々は唯一のHAProxyを使用することを想定し、それは少なくとも2 HAProxyを必要とし、また、これら二つのHAProxyの間で自動的にフェイルオーバーできるようにする必要があり、通常のソリューションはkeepalivedのです。通常、2つのノードのグループによって調製される障害の問題単一点を解決するために、VRRP（仮想ルータ冗長プロトコル、仮想ルータ冗長プロトコル）を使用してkeepalivedの、唯一のマスタノードは、同じ時間内に外部サービスを提供し、同時に提供します仮想IPアドレス（仮想インターネットプロトコルアドレス、VIPと呼ばれます）。プライマリノードに障害が発生した場合、バックアップノードは自動的にVIPを引き継ぎ、元のプライマリノードの復旧まで新しいマスターノードになります。

最後に、任意のクライアントは、例えば、どのようなクラスタアーキテクチャを気にせず、唯一の仮想IPに接続する必要があるのRabbitMQクラスタに接続したいです。

ConnectionFactory factory = new ConnectionFactory();
// 假设虚拟ip为 192.168.0.200
factory.setHost("192.168.0.200");
复制代码

1.2展開

次のようにここでは、ビルドに始まり、ここで私は、それぞれ3つのホストプレゼンテーション、ホスト名、および003、hadoop001,002を使用し、その機能が割り当てられています。

• hadoop001サーバー：展開のRabbitMQ + HAProxy + keepalivedの。
• hadoop002サーバー：展開のRabbitMQ + HAProxy + keepalivedの。
• hadoop003サーバー：展開のRabbitMQ

：私はへのRabbitMQのインストール手順については、以上の3つのホスト上のRabbitMQをインストールして参照することができますRabbitMQのビルドスタンドアロン環境

二、RabbitMQのクラスター構造

RabbitMQのクラスタを構築されるまず、次の手順を実行します。

クッキーの2.1コピー

hadoop001上の.erlang.cookie他の二つのホストにファイルをコピーします。クッキーファイルには、そうでない場合、プロセスがで設定される交換相互認証トークンを取得するためのキー、同じキートークンを持っているために、同じクラスタを必要としているすべてのノードへのキートークン、RabbitMQのクラスタノードで必要と等価です認証失敗エラー。

VMは自動的にクッキーファイルを作成しますアーランRabbitMQの場合は、サービスを開始すると、デフォルトのストレージ・パス/var/lib/rabbitmq/.erlang.cookieまたは$HOME/.erlang.cookieファイルは隠しファイルである、あなたが使用する必要があるls -alコマンドを。私は、ここでは$ HOMEディレクトリが、rootアカウントです/ rootディレクトリを使用して、以下のように対応するコマンドがあるコピーです。

scp /root/.erlang.cookie root@hadoop002:/root/
scp /root/.erlang.cookie root@hadoop003:/root/
复制代码

あなたは、3つの異なるホストオペレーティングアカウントに使用する場合がありますので、以下のように、回避問題に順番に権威の欠如は、後に、ここではオリジナルの400 777へのアクセス権のクッキーファイルに推奨される、コマンドは次のとおりです。

chmod  777 /root/.erlang.cookie
复制代码

注：クッキーの内容がラインランダムな文字列である、あなたはcatコマンドを使用することができます。

2.2サービスの開始

RabbitMQのサービスを開始し、3つのすべてのホスト上で次のコマンドを実行します。

rabbitmq-server start -detached
复制代码

ここでは説明を事前に：このコマンドは、RabbitMQの間、Erlangの仮想マシンとアプリケーションのサービスを開始します。その後、テキストが使用rabbitmqctl start_appのみRabbitMQのアプリケーションサービスを開始し、rabbitmqctl stop_app唯一のRabbitMQサービスを停止します。

2.3クラスタのセットアップ

RabbitMQのクラスター構造は、徐々に他のノードに加え、基準としてのノードのいずれかを選択する必要があります。ここでは、基準ノード、およびhadoop002のhadoop003クラスタとしてhadoop001。hadoop002とhadoop003で次のコマンドを実行します。

# 1.停止服务
rabbitmqctl stop_app
# 2.重置状态
rabbitmqctl reset
# 3.节点加入
rabbitmqctl join_cluster --ram rabbit@hadoop001
# 4.启动服务
rabbitmqctl start_app
复制代码

join_clusterコマンドは、オプションのパラメータを持って--ram、このパラメータは、新しいノードがメモリノード、デフォルトのディスクノードに追加さを表します。ノードは、ディスク上に格納され、ディスクの場合はメモリノードた場合は、すべてのキュー、スイッチ、結合関係、ユーザー、アクセス許可とメタデータのバーチャルホストは、メモリに保存されます。メモリノードは、より高い性能を持っていますが、その後に再起動し、すべての設定情報が失われることができますので、RabbitMQのディスクは、クラスタ内の少なくとも一つのノードを必要とし、他のノードは、メモリノードすることができます。メモリ・ノードがクラスタを離れるとき、それは少なくとも一つのディスクノードへの変更を通知することができ、それが再起動し、その後、ディスクノードに接続されている場合、メタデータ情報を取得します。RabbitMQのない限り、超低遅延RPCのシーンのためのこの必要性はあるか、ほとんどの場合、RabbitMQの性能は使用することができ、デフォルトのディスクノードの形で、十分です。この、hadoop002 Iセットメモリノードを証明するために。

ノードは、フォームのディスクノードに追加された場合また、あなたは使用する必要がありますreset、それは既存のクラスタノードのリセットがノード上のすべての歴史的資源やデータ存在を削除し参加することができます前にリセットするコマンドを。メモリノードを使用しての形で追加されたときは、スキップすることができreset、メモリ自体のデータは永続的ではないため、このステップ。

2.4チェッククラスタの状態

ビュー1.コマンドライン

設定hadoop002及び003に上記のコマンドを実行した後、クラスタが正常に、この時間は、任意のノードで使用することができるされているrabbitmqctl cluster_statusクラスタの状態を表示するため、次のように出力されます。

[root@hadoop001 ~]# rabbitmqctl cluster_status
Cluster status of node rabbit@hadoop001 ...
[{nodes,[{disc,[rabbit@hadoop001,rabbit@hadoop003]},{ram,[rabbit@hadoop002]}]},
{running_nodes,[rabbit@hadoop003,rabbit@hadoop002,rabbit@hadoop001]},
{cluster_name,<<"rabbit@hadoop001">>},
{partitions,[]},
{alarms,[{rabbit@hadoop003,[]},{rabbit@hadoop002,[]},{rabbit@hadoop001,[]}]}]
复制代码

ノードは、全ノードの表示情報を見ることができ、そしてその上にhadoop001 hadoop003ノードは、ディスクタイプ、ディスクノードであり、RAM上のノードとしてhadoop002、ノードのすなわちメモリ。このとき、クラスタを代表して、あなたが変更したい場合は、次のコマンドを使用することができ、正常hadoop001 @ cluster_nameのウサギのデフォルト名を設定されています。

rabbitmqctl set_cluster_name my_rabbitmq_cluster
复制代码

ビュー2. UIインターフェース

コマンドラインを使用するが、次のように任意のノードは、表示するためのUIインターフェースを開くために使用することができることに加えて：

2.5構成のミラーキュー

1.画像キュー

次のようにここでは、コンフィギュレーションミラーリングすべてのキューに入れ、その構文は次のとおりです。

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'
复制代码

2.コピー係数

すべての我々は、HAモードを指定する上記の値では、同じメッセージの代わりに、キュー内のすべてのノードに同期されます。ここでは、唯一の3つのノードので、なぜこのような構成な理由を持っているので、私たち自身のパフォーマンス・オーバーヘッドのコピー操作は比較的小さいです。クラスタ・ノードの多くを持っている場合は、パフォーマンス上のオーバーヘッドのコピーが比較的大きい場合、適切な複製因子を選択する必要があります。典型的には半分はノードの数のためのものであるn個のクラスタという原則に従うことができるよりも、書き込みのみN / 2 + 1のノードに同期される必要があります。このとき、ミラー必要が正確に戦略を変更し、コピー係数HA-のparamsを指定するには、サンプルコマンドは、次のとおりです。

rabbitmqctl set_policy ha-two "^" '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}'
复制代码

また、RabbitMQのは、例えば、フィルタに操作キューの必要性をミラーリング正規表現をサポートしています。

rabbitmqctl set_policy ha-all "^ha\." '{"ha-mode":"all"}'
复制代码

この時点でキューヘクタールミラーリングの始まりに過ぎません。：その他のキューの設定手順をミラーリング、あなたは、公式ドキュメントを参照することができます高可用性（ミラー）キュー

3.ビューミラーのステータス

設定後、ミラーは、キューのいずれかの状態で見ることができるWeb UIには、次のように：

2.6ノードのオフライン

上記のクラスタセットアッププロセスは、サービスの拡大の過程で、あなたがノードクラスタを解消したい減容サービスを実行したい場合は、2つのオプションがあります。

最初：あなたが最初に使用できるrabbitmqctl stopノード上でストップサービスをして、他のノード上で実行forget_cluster_nodeコマンド。ここでhadoop003上でサービスを排除するために、例えば、あなたはhadoop001または002で次のコマンドを実行することができます。

rabbitmqctl forget_cluster_node rabbit@hadoop003
复制代码

第二の方法：最初の使用のrabbitmqctl stop後、停止、そのノード上のサービス、および実行するrabbitmqctl resetノード上のすべての履歴データが消去されますことを、クラスタ内の他のノードに通知するためのイニシアチブをとるには、クラスタを残すことがあります。

2.7シャットダウンと再起動のクラスタ

いいえ、直接コマンドは、クラスタ全体をシャットダウンすることはできません、あなたは一つ一つをシャットダウンする必要があります。しかし、再起動時に、最初のノードの最後の閉鎖が活性化されることを確認する必要があります。ノードが最初のスタートの最後のクローズされていない場合、そのノードが起動に失敗するまで、まだ待っていない場合、ノードは、ノードが開始され、30秒間に10回のデフォルト接続試行のタイムアウトの最終閉鎖を待ちます。

この1つの問題は、ノード1が一時的にできない障害が原因で回復する場合は、ノード1、ノード2、ノード3の閉じた順序の中で3ノードクラスタを想定し、それをされ、そしてこの時点ではノード2のノード3は起動しません。この問題を解決したい、それが第1ノードnode1の、次のコマンドを削除することができます：

rabbitmqctl forget_cluster_node rabbit@node1 -offline
复制代码

追加するには、この場合必要で-offline、それはノード自体を許可する場合のパラメータを他のノードが取り出され、活性化されません。

三、ビルドにHAProxy環境

3.1をダウンロード

HAProxy公式ダウンロードアドレスは次のとおりです。www.haproxy.org/#down、サイトにアクセスするだけでなく、からではない場合src.fedoraproject.org/repo/pkgs/h ...上でダウンロード。ここで私は、ダウンロード後に解凍され、バージョン2.xをダウンロード：

tar -zxvf haproxy-2.0.3.tar.gz
复制代码

3.2コンパイラ

コンパイルには、次のコマンドを実行し、解凍したルートディレクトリを入力します。

make TARGET=linux-glibc  PREFIX=/usr/app/haproxy-2.0.3
make install PREFIX=/usr/app/haproxy-2.0.3
复制代码

3.3設定環境変数

設定の環境変数：

vim /etc/profile
复制代码

export HAPROXY_HOME=/usr/app/haproxy-2.0.3
export PATH=$PATH:$HAPROXY_HOME/sbin
复制代码

これは、環境変数の設定はすぐに反映させるになります：

source /etc/profile
复制代码

3.4負荷分散の構成

新しいプロファイルを作成しhaproxy.cfg、ここに私の新しいポジションで次のように/etc/haproxy/haproxy.cfg、文書が読み取ります。

# 全局配置
global
    # 日志输出配置、所有日志都记录在本机，通过 local0 进行输出
    log 127.0.0.1 local0 info
    # 最大连接数
    maxconn 4096
    # 改变当前的工作目录
    chroot /usr/app/haproxy-2.0.3
    # 以指定的 UID 运行 haproxy 进程
    uid 99
    # 以指定的 GID 运行 haproxy 进程
    gid 99
    # 以守护进行的方式运行
    daemon
    # 当前进程的 pid 文件存放位置
    pidfile /usr/app/haproxy-2.0.3/haproxy.pid

# 默认配置
defaults
    # 应用全局的日志配置
    log global
    # 使用4层代理模式，7层代理模式则为"http"
    mode tcp
    # 日志类别
    option tcplog
    # 不记录健康检查的日志信息
    option dontlognull
    # 3次失败则认为服务不可用
    retries 3
    # 每个进程可用的最大连接数
    maxconn 2000
    # 连接超时
    timeout connect 5s
    # 客户端超时
    timeout client 120s
    # 服务端超时
    timeout server 120s

# 绑定配置
listen rabbitmq_cluster
    bind :5671
    # 配置TCP模式
    mode tcp
    # 采用加权轮询的机制进行负载均衡
    balance roundrobin
    # RabbitMQ 集群节点配置
    server node1 hadoop001:5672 check inter 5000 rise 2 fall 3 weight 1
    server node2 hadoop002:5672 check inter 5000 rise 2 fall 3 weight 1
    server node3 hadoop003:5672 check inter 5000 rise 2 fall 3 weight 1

# 配置监控页面
listen monitor
    bind :8100
    mode http
    option httplog
    stats enable
    stats uri /stats
    stats refresh 5s
复制代码

メインロードバランシング設定listen rabbitmq_cluster良いヘルスチェックメカニズムの定義ながらやり方が負荷分散を指定したが、ここではラウンドロビン加重です。

server node1 hadoop001:5672 check inter 5000 rise 2 fall 3 weight 1
复制代码

上記の構成はhadoop001表し対処するために2つの連続した検査結果が正常であれば、5秒ごとに一度健康診断のノード1ノード5672を、それはノードが利用可能であると考えられる、この場合は、クライアントノードへのポーリング要求であってもよいです三つの連続試験結果が正常でない場合、ノードが利用不可能であると考えられます。ポーリング処理における重みの重みは、ノードの重みを指定しました。

3.5サービスの開始

hadoop001と同じhadoop002の段差の上に建てられ、完成した構造は、次のコマンドを使用してサービスを開始します。

haproxy -f /etc/haproxy/haproxy.cfg
复制代码

：完全なアドレスの設定、監視、ページビュー、ポート8100を起動した後に行うことができる8100 /統計：HTTP：// hadoop001次のようにページ：

すべてのノードは、ノードの健康状態を表す、緑色です。この時点で、HAProxyビルドが成功を収めた、とRabbitMQのクラスタは、監視する必要があります。

四、ビルドにkeepalivedの環境

その後、我々は問題HAProxyのフェイルオーバーを解決するためにkeepalivedのを構築することができます。次のようにここでIおよびhadoop001 hadoop002 keepalivedの上に取り付けられ、二つのホスト上のステップ構造は、同一であるが、構成のわずかに異なる部分。

4.1をダウンロード

目的のバージョンから直接公式ダウンロードをkeepalivedの、私は2.xバージョンはこちらでダウンロード。解凍ダウンロードした後：

wget https://www.keepalived.org/software/keepalived-2.0.18.tar.gz
tar -zxvf keepalived-2.0.18.tar.gz
复制代码

4.2コンパイラ

依存関係のインストール後にコンパイルされました：

# 安装依赖
yum -y install libnl libnl-devel
# 编译安装
./configure --prefix=/usr/app/keepalived-2.0.18
make && make install
复制代码

4.3環境設定

代わりにyumをインストールを使用して、代わりに圧縮されたパッケージを使用する方法がインストールされているので、その後、環境設定の必要性は、次の通り：

keepalivedのデフォルト/etc/keepalived/keepalived.confの設定ファイルのパスを読んで、設定ファイルがパスにコピーされてインストールする必要があります：

mkdir /etc/keepalived
cp /usr/app/keepalived-2.0.18/etc/keepalived/keepalived.conf /etc/keepalived/
复制代码

すべてのkeepalivedのスクリプトは/etc/init.d/のディレクトリにコピー：

# 编译目录中的脚本
cp /usr/software/keepalived-2.0.18/keepalived/etc/init.d/keepalived /etc/init.d/
# 安装目录中的脚本
cp /usr/app/keepalived-2.0.18/etc/sysconfig/keepalived /etc/sysconfig/
cp /usr/app/keepalived-2.0.18/sbin/keepalived /usr/sbin/
复制代码

最初からセットのブート：

chmod +x /etc/init.d/keepalived
chkconfig --add keepalived
systemctl enable keepalived.service
复制代码

4.4コンフィギュレーションチェックHAProxy

：次のようにここでは、hadoop001変更コンフィギュレーションファイルにkeepalived.confの最初の完全な

global_defs {
   # 路由id,主备节点不能相同
   router_id node1
}

# 自定义监控脚本
vrrp_script chk_haproxy {
    # 脚本位置
    script "/etc/keepalived/haproxy_check.sh" 
    # 脚本执行的时间间隔
    interval 5 
    weight 10
}

vrrp_instance VI_1 {
    # Keepalived的角色，MASTER 表示主节点，BACKUP 表示备份节点
    state MASTER  
    # 指定监测的网卡，可以使用 ifconfig 进行查看
    interface enp0s8
    # 虚拟路由的id，主备节点需要设置为相同
    virtual_router_id 1
    # 优先级，主节点的优先级需要设置比备份节点高
    priority 100 
    # 设置主备之间的检查时间，单位为秒 
    advert_int 1 
    # 定义验证类型和密码
    authentication { 
        auth_type PASS
        auth_pass 123456
    }

    # 调用上面自定义的监控脚本
    track_script {
        chk_haproxy
    }

    virtual_ipaddress {
        # 虚拟IP地址，可以设置多个
        192.168.0.200  
    }
}
复制代码

上記の構成は、マスタノードとしてhadoop001にkeepalivedのノードを定義し、仮想IP 192.168.0.200にサービスを提供するように設定します。また、最も重要なのは、によって定義されhaproxy_check.sh、以下のように、必要となるスクリプトを監視するためにHAProxyの私たち自身の作成が読み取ります。

#!/bin/bash

# 判断haproxy是否已经启动
if [ ${ps -C haproxy --no-header |wc -l} -eq 0 ] ; then
    #如果没有启动，则启动
    haproxy -f /etc/haproxy/haproxy.cfg
fi

#睡眠3秒以便haproxy完全启动
sleep 3

#如果haproxy还是没有启动，此时需要将本机的keepalived服务停掉，以便让VIP自动漂移到另外一台haproxy
if [ ${ps -C haproxy --no-header |wc -l} -eq 0 ] ; then
    systemctl stop keepalived
fi
复制代码

：あなたは、実行権限を割り当てる作成した後

chmod +x /etc/keepalived/haproxy_check.sh
复制代码

このスクリプトは、主にHAProxyサービスを決定するために使用されていることは、あなたは、マシンkeepalivedのをオフにする必要があり、通常、そうでない場合は正常であり、起動することはできませんので、バックアップノードに仮想IPドリフト。バックアップノードと実質的に同一の構成マスタノードが、そのBACKUP状態の修正を必要とする優先度よりも低い優先度は、マスタノードを必要とします。次のように完全な構成は以下のとおりです。

global_defs {
   # 路由id,主备节点不能相同    
   router_id node2  

}

vrrp_script chk_haproxy {
    script "/etc/keepalived/haproxy_check.sh" 
    interval 5 
    weight 10
}

vrrp_instance VI_1 {
    # BACKUP 表示备份节点
    state BACKUP 
    interface enp0s8
    virtual_router_id 1
    # 优先级，备份节点要比主节点低
    priority 50 
    advert_int 1 
    authentication { 
        auth_type PASS
        auth_pass 123456
    }
    
    track_script {
        chk_haproxy
    }

    virtual_ipaddress {
        192.168.0.200  
    }
}
复制代码

4.5サービスの開始

keepalivedのサービスがhadoop001とhadoop002に開始された次のように、コマンドは次のとおりです。

systemctl start  keepalived
复制代码

今回hadoop001マスターノードを起動した後、hadoop001上で使用することができるip aの仮想IPを表示するためのコマンド：

この時点でのみhadoop001仮想IPが存在し、hadoop002ではありません。

4.6フェイルオーバーを検証します

私たちの上記検出スクリプトによると、keepalivedのサービスがここで我々が直接keepalivedのサービスを停止するには、次のコマンドを使用し、HAProxyが停止した場合は停止し、再起動することはできませんので、ここでは、フェールオーバーの検証します：

systemctl stop keepalived
复制代码

この際、再利用のip a観点、それぞれ、VIP上で見つけることができ、次のように、hadoop002に漂流してきたhadoop001：

この時点でVIP外国サービスは、我々が正常にフェイルオーバーに代わって行われてきた、まだ使用可能です。クラスタが正常に設定されています。この時点で、任意のクライアントサービスのニーズが送信またはメッセージのみが、たとえば、VIP缶に接続する必要が受信します：

ConnectionFactory factory = new ConnectionFactory();
factory.setHost("192.168.0.200");
复制代码

参考資料

1. ZHU忠華。RabbitMQの実用的なガイドの電子出版業界。2017年11月1日
2. RabbitMQの公式ドキュメント-クラスターガイド：www.rabbitmq.com/clustering ....
3. RabbitMQの公式ドキュメント-高可用性ミラーリングキュー：www.rabbitmq.com/ha.html
4. マニュアルHAProxy公式設定：cbonte.github.io/haproxy-dco ...
5. keepalivedの公式設定マニュアル：www.keepalived.org/manpage.htm ...

より多くの記事については、してください訪問[エンジニアハンドブックフルスタック]、GitHubの住所：github.com/heibaiying / ...