このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。

設定(前ページからの続き)

Ultra Monkey 解説のはじめに「RedHat Enterprise Linux 4 と Fedora Core 5 で検証した」と書いた。しかし残念ながら heartbeat については実験に供する 2台目の Fedora Core 5 マシンの持ちあわせがないため、ここからの内容は RHEL4 でのみ検証したものであることをお断りしておかなければならない。よって、heartbeat のバージョンも 1.x が話題の中心となる (Fedora Core 5 でインストールされるのはバージョン 2.x)。

heartbeat

Linux-HA プロジェクトのオフィシャルドキュメントサイトに、"Getting Started with Linux-HA (Heartbeat)" をはじめ、優れた HOWTO がたくさんある。そちらも読むべし。

ここで目指すかたち

いよいよ ldirectord の二重化と httpd の負荷分散を組み合わせる仕上げの行程だ。一方の ldirectorサーバ (当例では実サーバマシンに取り込んでしまっている) に障害が起こってももう一台が LVS管理業務を肩代わりしてくれるように、その時アクティブであるべきサーバ上でのみ heartbeat が ldirectord を起動するようにする。クラスタのマスタメンバーは webserver1 の方とする。

前ページで、webserver1 には ldirectord を配備した。ここから先へ読み進む前に、webserver2 にも配備しておいてほしい。その際、今度は ldirectord が webserver2 でも動くわけなので、 ARP応答仕様の修正で述べた「IPフォワードの設定」は webserver2 にも施さなくてはいけない。

また、ホスト名がリゾルブできること (この例で言うと webserver1 => 192.168.1.1, webserver2 => 192.168.1.2) が動作の大前提となるので、この 2台の他に内部 DNSサーバも立てておく必要がある。djbdns を使えば至って簡単で占有リソースも少ない。

heartbeat どうしが互いの状態を通信し合う経路は、必ず 2本以上用意しなければならない。図のシリアルと LAN のように、種類の異なるものを併用すれば確実性が高まる。また、LAN ハートビートは、ネットワークカードが余分に用意できるなら、クロスケーブルでマシンどうしを直結したハートビート専用経路も仕掛けておくとさらに確実だ。

heartbeat の設定に関わるファイルは 3つで、いずれも /etc/ha.d/ にある。

ha.cf

/etc/ha.d/ha.cf

logfacility local0
debug 0
keepalive 2
deadtime 10
warntime 5
initdead 120
mcast eth0 225.0.0.1 694 1 0
serial /dev/ttyS1
auto_failback off
node webserver1
node webserver2
ping 192.168.1.253
respawn hacluster /usr/lib/heartbeat/ipfail

主なディレクティブの解説

deadtimeチューニング

下記は heartbeat のソースに付属している doc/faqntips.html に挙げられている FAQ "How to tune heartbeat on heavily loaded system to avoid split-brain" (高負荷なシステムでスプリットブレインを防止するためのチューニング方法) を訳したもの。同ドキュメントは、heartbeat を RPM でインストールした場合には /usr/share/doc/heartbeat-X.X.X/ 下にコピーされているはずだ。スプリットブレインおよびネットワークパーティションとは、クラスタメンバーの中の複数のマシンが死活確認方法を失い、互いの状態が分からなくなってリソースを同時に活性化させてしまったり同時に止めてしまう現象を言う。

シリアル通信のテスト方法

1. 片方のマシンで (ちなみに tailf などではダメ)
   root# cat /dev/ttyS1
2. もう片方のマシンで
   root# echo "hello host" >/dev/ttyS1
3. 1台目のマシンに hello host と表示されているはず。

haresources

このファイルの内容はクラスタの全ノードで同一でなければならない。

/etc/ha.d/haresources

webserver1 \
    ldirectord::ldirectord.cf \
    LVSSyncDaemonSwap::master \
    IPaddr2::192.168.1.250/24/eth0/192.168.1.255

各行末にバックスラッシュがあることから分かるように、文言は 1行から成っている。(ワープロ的な意味での) 2行目以降はインデントしてあるが、そうしなければならないという規則は特にない。

各パラメータの説明

※ この点により、IPaddr2 で発生された仮想IPアドレスは ifconfig コマンドでは表示されないことがある。確実に表示させるには iproute2 のコマンドを使用して、

root# ip addr show

とする。

authkeys

発信する heatbeat通信パケットにサインするための秘密キーを定義するファイル。内容は、クラスタに属する全ノードで同じでなくてはならない。ファイルパーミションは必ず root:root 600 とすること。

auth 1
1 sha1 thisIsMySecret

普遍化すると；

auth {key_number}
{key_number} {auth_method} {key}

• key_number は上記 1行目と 2行目を対応させる。
• key_number は 1 以上、15 以下。
• auth_method は (今のところ) - 弱い順に - crc, md5, sha1 から選択できる。
• sha1 はクラックされにくいが、計算に多くの CPU時間を消費する。バランス的に言って、非力なマシンでは md5 が良好。
• crc (クラックされやすいので非推奨) の場合は key は不要。
• key は、一度設定してしまえば人がタイプする機会は皆無なので、覚えやすいものにする理由は全くない。key の最大長は 32 バイト(？)。

公開用仮想IPアドレスの削除

前ページでテスト用に公開用VIP を手動作成した場合は、それをを削除しておく；

root# ip addr del 192.168.1.250/32 dev eth0

また、前ページで ifcfg-eth0:0 を作ったままの人はそれも無効にしなくてはいけない；

root# ifdown eth0\:0
root# rm /etc/sysconfig/network-scripts/ifcfg-eth0\:0

スタートアップサービスへの登録と稼働

当ページの実装法では、ldirectord は heartbeat によって適宜起動されるのでスタートアップ起動されてはいけない。両 webserver とも；

root# chkconfig --del ldirectord
root# chkconfig --add heartbeat
root# chkconfig heartbeat on   (念のため)

実際に稼働させる。これも両ノードで。

root# service ldirectord stop  (両ノードでやってから下行へ)
root# service heartbeat start  (先に webserver1, 次に webserver2 で行う)

稼働確認

いろいろな状態確認コマンドとその出力の抜粋を以下に示す。

root# ip addr show  (webserver1上にて)
  <現在マスターなので、VIP 192.168.1.250 が eth0 の副IP になっている>
  2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
     link/ether 00:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
     inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0
     inet 192.168.1.250/24 brd 192.168.1.255 scope global secondary eth0
root# ip addr show  (webserver2上にて)
  <現在マスターではないので、VIP 192.168.1.250 がループバックのエイリアスになっている>
  1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
     inet 192.168.1.250/32 brd 192.168.1.255 scope global lo:0

root# ldirectord /etc/ha.d/ldirectord.cf status (webserver1上にて)
  ldirectord for /etc/ha.d/ldirectord.cf is running with pid: xxx
root# ldirectord /etc/ha.d/ldirectord.cf status (webserver2上にて)
  ldirectord is stopped for /etc/ha.d/ldirectord.cf

root# ipvsadm -L -n      (webserver1上にて)
  <ldirectord が活性化され管理ノードになっているのでロードバランステーブルが表示される>
  IP Virtual Server version 1.x.x (size=4096)
  Prot LocalAddress:Port Scheduler Flags
    -> RemoteAddress:Port Forward Weight ActiveConn InActConn
  TCP 192.168.1.250:80 wrr persistent 600
    -> 192.168.1.2:80     Route    1     0     0
    -> 192.168.1.1:80     Local    1     0     0
root# ipvsadm -L -n      (webserver2上にて)
  <ldirectord が非活性であり管理ノードではないのでロードバランステーブルは空>
  IP Virtual Server version 1.x.x (size=4096)
  Prot LocalAddress:Port Scheduler Flags
    -> RemoteAddress:Port Forward Weight ActiveConn InActConn

root# /etc/ha.d/resource.d/LVSSyncDaemonSwap master status (webserver1上にて)
  master running
  (ipvs_syncmaster pid: xxxx)
root# /etc/ha.d/resource.d/LVSSyncDaemonSwap master status (webserver2上にて)
  master stopped

運用しだしたら、通常の確認は ipvsadm -L -n だけでいいだろう。また、前ページで紹介した cluster スクリプトも、heartbeat を実装した今なら満足に働いてくれる。ただし、cluster スクリプトは、

• ipvsadm と同様、その時 ldirectord の活性化している (つまりクラスタ管理ノードになっている) サーバ上でないとコマンドはほとんど無意味。
• コマンド `ldirectord ... status' と `LVSSyncDaemonSwap master status' はログエントリを発生させる。cluster スクリプトにはこれらが含まれているので、あまり多用するとログが汚くなる。

という点に注意して使って頂きたい。