Home > まめ知識 | 開発裏話 > KeepAlivedのススメ2

KeepAlivedのススメ2

前回は、KeepAlivedはなんぞや?ということを中心に書きましたので、今回は、インストールから設定までを書いてみたいと思います。

KeepAlivedのインストール

大体は前回書いたのですが、今回は概念よりも実際の作業内容を書いてみます。

作業の大まかな流れ

  • 1.KeepAlivedのソースを取得
  • 2.ソースを一旦解凍して、specファイルを取り出す
  • 3.ソースとspecファイルを配置
  • 4.RPM化
  • 5.レポジトリに追加
  • 6.ipvsadmもレポジトリに追加
  • 7.yumでインストール
  • 8.確認

ざっとこんな感じです。

1.KeepAlivedのソースを取得

ソースはここから取得します。2010/12/14現在で最新は1.2.1です。tar.gz形式で置いてあります。

2.ソースを一旦解凍して、specファイルを取り出す

RPMの作成に必要な指示書であるspecファイルがkeepalived.spec.inとして中にあります。これを取り出してください。

# tar xzvf keepalived-1.2.1.tar.gz
# cd keepalived-1.2.1
# cp keepalived.spec.in ./../
# cd ..
# rm -rf keepalived-1.2.1

こんな感じです。解凍したものは、取り出した後は不要なので、削除しておきます。

3.ソースとspecファイルを配置

前々回までの投稿内容のようにRPM作成環境があることを前提とします。

# mv ./keepalived.spec.in /home/navi/mkrpm/SPECS/keepalived.spec
# mv ./keepalived-1.2.1.tar.gz /home/navi/mkrpm/SOURCES/
# chown navi:navi  /home/navi/mkrpm/SPECS/keepalived.spec.in
# chown navi:navi  /home/navi/mkrpm/SOURCES/keepalived-1.2.1.tar.gz

最後のふたつは、navi以外の所有者にてここまでの動作を行った場合は実行してください。naviにてすべてを行っていたら必要ありません。

4.RPM化

naviで、rpmbuildします。

# su navi
# cd /home/navi/mkrpm/SPECS
# rpmbuild -ba keepalived.spec

5.レポジトリに追加

レポジトリフォルダは、適宜読みかえてください。

# cp /home/navi/mkrpm/RPMS/x86_64/keepalived-1.2.1-5.x86_64.rpm (apacheの公開ディレクトリ内の、レポジトリフォルダ)
# rpm --addsign (apacheの公開ディレクトリ内の、レポジトリフォルダ)/keepalived-1.2.1-5.x86_64.rpm
# createrepo (apacheの公開ディレクトリ内の、レポジトリフォルダ)

6.ipvsadmもレポジトリに追加

Centであれば、ここにipvsadm-1.24のrpmがあります。

これをダウンロードして、次のように追加します。

# mv ./ipvsadm-1.24-10.x86_64.rpm (apacheの公開ディレクトリ内の、レポジトリフォルダ)
# rpm --resign (apacheの公開ディレクトリ内の、レポジトリフォルダ)/ipvsadm-1.24-10.x86_64.rpm
# createrepo (apacheの公開ディレクトリ内の、レポジトリフォルダ)

7.yumでインストール

あとは、該当機にて、

# yum install ipvsadm keepalived (デフォルトenabled=0なら、--enablerepo=***)

を行えば、インストールは完了です。あとは、configをいじって、

# service keepalived start

を行えば、起動完了!。さらに、再起動時に初期起動させるために

# chkconfig keepalived on

をしておくといいかもです。

KeepAlivedの設定について

上記のインストール方法でインストールを行うと、「/etc/keepalived/keepalived.conf」に、コンフィグファイルのデフォルトが入っているはずです。大きく分けて

  • 「global_defs (アラートメール等の設定箇所)」
  • 「vrrp_instance(vrrpによる自機の冗長化の設定箇所)」
  • 「virtual_server(ロードバランサとしてのLVSラッパの設定箇所)」

の3つに区分されます。他にも、「vrrp_sync_group(複数のvrrpグループを束ねる)」もありますが、これは後で説明します。

簡単に書くと次のようなconfigファイルになります。

! Configuration File for keepalived

global_defs {
# アラートメールの設定
}

vrrp_instance [好きな名前]{
# VRRPによる自機の冗長化設定
}

virtual_server [仮想IP] [ポート番号]{
# LVSによるロードバランサの設定
}


gloval_defsの設定内容

! Configuration File for keepalived
# フェイルオーバーした際のalertメールを送るための設定(無くても可)
global_defs {
    # メールの送り先
    notification_email {
        test@test.local
    }
    # メールの送信元アドレスと、メールサーバー
    notification_email_from KeepAlived@test.local
    smtp_server 127.0.0.1
    smtp_connect_timeout 30
    # 機器名をつけておくと、メールの内容がわかりやすくなる。
    router_id test_mast
}

こんな感じです。

vrrp_instanceの設定内容

vrrp_instance [好きな名前]と書いて始めます。名前は、vrrpを組むグループを複数作れるので、その一意性を持たせるためのものです。

vrrp_instance VI_1 {
    # マスタサーバーかバックアップサーバーか。(後述)
    state (MASTER | BACKUP)
    #今起動しているのがなければ、マスタになり、マスタがいれば、スレーブ。
    nopreempt
    # VRRP信号を送出するNIC(監視側みたいなもの)
    interface eth0
    # ネットワークが混雑していて、スイッチがARP信号を処理できない場合は、ARPを少し送らせて送信する設定。
    # 無くても動く。動作が変な場合(VIPを引き継いだのに、外部から認識できない現象が出たら、こいつを設定。)
    # 弊害として、VIPの引継完了が遅くなる。(デフォルトは引き継いだら即ARP信号の送信。)
#    garp_master_delay 1
    # 仮想ルーターのID(VRRP信号を共有する他サーバーのインスタンス間で共通にする。)
    virtual_router_id 51
    # 優先度(MasterはBACKUPよりも高く設定。)
    priority 101
    # VRRP信号を送出するインターバル(間隔)。下記設定では、1秒おき。
    advert_int 1
    # VRRP信号を受け取る際のパスワード等(同じvirtual_router_idならば、同じにする。)
    authentication {
        auth_type AH
        auth_pass pass@la
    }
    # このインスタンスで管理するVIP(同じvirtual_router_idなら、同じにする。※NICは同じ必要ない。)複数設定可能
    virtual_ipaddress {
        192.168.100.12/28 dev eth0
#      192.168.100.13/28 dev eth0
    }
    #フェイルオーバー時にメール通知する場合は、次を追加。
    smtp_alert

    # マスタノードに昇格した(もしくは、マスタノードとして起動した)際に実行するスクリプト。
#    notify_master "/usr/local/tekitou/tekitou.sh"
    # バックアップノードに落ちた(もしくは、バックアップノードとして起動した)際に実行するスクリプト。
#    notify_master "/usr/local/tekitou/tekitou.sh"
}

特に重要なのは、「state」です。フェイルバック時の挙動をここで変更します。例えば、2台構成(機器1・2)で、機器1が初め、masterノードとして働いていたケースを考えます。機器1が故障によりダウンした場合、機器2が仮想IPを振り替えてマスタに昇格します。この後、機器1が故障から復旧した場合、「機器1がマスタに戻ってほしい」場合と「機器2がマスタのままで、機器1はバックアップになってほしい」場合があります。前者は、管理上、機器1が常にマスタの方が好ましいと判断する場合であり、後者は、フェイルバック時にダウンタイムが発生してほしくない場合です。KeepAlivedでは、「state」の設定により、いずれかを選択することができます。

機器2からのフェイルバック時の動作 機器1 機器2 共通
機器1がマスタに戻る MASTER BACKUP
機器1はバックアップとして戻る BACKUP BACKUP nopreempt

また、両方共BACKUPとして設定したとき、どちらが初めのMASTERとなるかですが、これは、「先に起動していた方」となります。さらに、どちらがマスタかわからない場合は、virtual_ipaddressが設定されているのを確認すれば一目瞭然です。

# ip addr show

とかで、ipアドレスを確認してください。

virtual_serverの設定内容

DSRとNATについては、別の回のブログに記載しています。(ちょっと読みにくいようですが・・)

virtual_server 192.168.100.12 3306 {
    #バックエンドの監視を行うインターバル
    delay_loop 3
    #rrラウンドロビン、他のは後述
    lb_algo rr
    #DR:DSR構成、NAT:なっと(別の回のブログに記載)
    lvs_method DR
    protocol TCP
    #バックエンドは3台構成。
    real_server 192.168.100.20 3306 {
        weight 10
        TCP_CHECK {
            connect_port 3306
            connect_timeout 30
        }
        #もしこのサーバーが止まったときに呼び出される処理。
#        notify_down "/usr/local/test/testdown1.sh"
    }

    real_server 192.168.100.21 3306 {
        weight 10
        TCP_CHECK {
            connect_port 3306
            #普通はあまり使わないが、別のIPで監視もできる(同じIPのときは不要)
#         bindto 192.168.100.30
            connect_timeout 30
        }
    }

    real_server 192.168.100.22 3306 {
        weight 10
        TCP_CHECK {
            connect_port 3306
            connect_timeout 30
        }
    }

    #リアルサーバが全滅したときにパケットが転送されるサーバ
    sorry_server 192.168.100.23 3306
}

あれ?、と気づいた方もおられるかな、と思います。3306ポート、有名なMySQLのデフォルトポートです。次回、詳しくは書こうと思うのですが、上記ですと例えば、「sorry_serverはレプリケーションマスタ、バックエンドはそれぞれレプリケーションスレーブ」として、192.168.100.12:3306が、参照系クエリの受付アドレス、みたいな感じです。参照系の負荷分散ですね。checkの方法はまだまだたくさんあるのですが、最も良く使うのがTCPチェックです。単にコネクションが確立できるかどうかをチェックします。タイムアウトは30秒ですが、大抵瞬間でバックエンドの停止を見つけてくれます。(上記設定では、インターバル3秒なので、タイムアウト待つ間もなくコネクション不可がかえってくるようです。)HTTPサーバーの冗長化のときは、HTTP_GETとかSSL_GETとかもあります。(ただし、当然これは負荷も高そうです。)

lb_argo(以前はlvs_schedでした)のアルゴリズムは、次のようなものがあります。(他にもあるのですが、よっぽどでない限り、下記以外ほとんど使わないと思います。)

rr
ラウンドロビン、順番にバックエンドに割り振っていく。weightは無視。
wrr
重み(weight)を加味したラウンドロビン。weightが高いものほど多く振る。
lc
コネクション数がもっとも少ないサーバを選択する。
wlc
重みとコネクション数によるサーバー選択をおこなう。

最後に

こんな感じで、設定完了です。あとは、

# service keepalived start

で、動くとうれしいですね!。

次回は、いよいよkeepalivedを使ったMySQLの冗長化にいってみたいと思います。

Comments:0

Comment Form

Trackbacks:0

Trackback URL for this entry
http://dev.tapweb.co.jp/2010/12/294/trackback
Listed below are links to weblogs that reference
KeepAlivedのススメ2 from tap dev blog

Home > まめ知識 | 開発裏話 > KeepAlivedのススメ2

Search
Feeds

Return to page top