HAクラスタ構築に便利な豆知識：Heartbeatでかんたんクラスタリング（5）（2/3 ページ）

[花島タケシ，VA Linux Systems Japan株式会社]

Heartbeatのビルド

　Heartbeatから提供されるソースコードは下記のとおりです。

種類	ソースコード
デーモン	heartbeat、ha_logd、ccm、lrmd、ldirectord
ライブラリ	libccmclient、libhbclient、libclplumbほか
管理ツール	ha_logger、hb_report、ciblintなど
その他	v1設定用RA、v2設定用RA、STONITH RA

　Heartbeatのビルド時の注意点は、以下のとおりとなります。

1. 現時点ではsnmp_subagentのソースコードが含まれていますが、今後はPacemakerから提供されるようですので、configure時に、明示的に--disable-snmp-subagentオプションを渡した方がよいでしょう。--disable-snmp-subagentオプションを渡した方がよいでしょう。
2. v1設定からv2設定への移行ツール「haresources2cib.py」が提供されていますが、これはPacemakerからも提供されるため、Heartbeatのものは削除します。

Pacemakerのビルド

　Pacemakerからは下表のものが提供されます。

種類	ソースコード
デーモン	attrd、cib、crmd、pingd、pengine、tengine
ライブラリ	libcib、libcrmcluster、libcrmcommon
管理ツール	crm_mon、cibadminなど、デーモン、ライブラリに付随したもの

　Pacemakerのビルド時の注意点は、以下のとおりとなります。

1. snmp_subagentを有効にする場合、Heartbeatとは逆に、configure時に--enable-snmp-subagentオプションを明示的に与えた方がよいでしょう。--enable-snmp-subagentオプションを明示的に与えた方がよいでしょう。
2. OpenAISのサポートを無効にするため、--without-ais-supportオプションを与えます。--without-ais-supportオプションを与えます。

Pacemaker Python GUIのビルド

　特に問題はありません。ただし、これまでとは異なり、Heartbeat側がデフォルトでmgmtdをサポートしなくなったため、Pacemaker Python GUIのインストール後、ha.cfに、

apiauth	mgmtd	uid=root
respawn	root	/usr/lib/heartbeat/mgmtd -v

と追加して、Heartbeatサービスを起動しなくてはならなくなりました（注1）。Pacemaker Python GUIでは主に、GUIクライアントのほか、HeartbeatとGUIクライアントのインターフェイスとなるライブラリとデーモン（mgmtd）が提供されます。

【注1】　http://www.clusterlabs.org/mw/FAQ#How_Do_I_Enable_the_GUI.3Fを参照

それでも遭遇するかもしれない冗長化時のトラブル

　Heartbeatは冗長化構成を行うためのソフトウェアですが、残念ながら冗長化構成は完全ではあり得ません。ハードウェアを複数台構成にしたとしても同時に故障に見舞われる可能性もありますし、Heartbeatのバグなどで無事にフェイルオーバーしないこともあるかもしれません。

　こういったトラブルを避けるためには、

1. 設計に問題ないか吟味する。なるべくシンプルな構成で実現できるか考慮する。
2. たとえRAID構成であっても問題は発生することを念頭に置き、データ部は必ず冗長化する。特に、安価な製品やソフトウェアRAIDを用いる構成では、故障したHDDを交換した後の作業を確立しておく。
3. データのバックアップはまめに行う。

といった心得が挙げられると思います。

　特に、2でのRAID構成についてもう一度注意しておきましょう。

　最近は、安価なRAID製品が市場に出回っています。しかしながら、それらは必ずしも復旧時のことまでケアした製品ばかりではありませんし、操作画面を見てもGUIではなく、テキストベースの英語インターフェイスのみの提供となっていることがほとんどです。もし、こうした環境で復旧時の手順を誤ってしまうとデータはすべて消失してしまいます。事前に復旧手順をテストし、確立しておくべきであることはいうまでもありません。

　また、3のデータのバックアップにも注意が必要です。現在のように、1台のHDDの容量が1Tbytesを超える時代では、速度の面を考慮しても、テープドライブやDVDなどのメディアにバックアップを行うのは現実的でなくなりつつあります。そこで、「Amanda」のようなバックアップツールを用いて、別途用意した専用サーバにバックアップを行うといった方法が考えられます。

Heartbeatのログ出力を効率的に

　この連載ではあまり深く触れませんでしたが、簡単にHeartbeatのログ出力について解説します。

　第2回「インストールとApache用の設定方法」で、Heartbeatの設定ファイル「ha.cf」について簡単に説明し、その中でlogfileとlogfacilityというディレクティブを紹介しました。これらはログ出力に関する設定項目です。ha.cfのサンプル（/usr/share/doc/heartbeat-2.1.3/以下にあります）には、それ以外にさらに、debugfile、use_logdというディレクティブも記述されています。

　Heartbeatでは、各プロセスから個別にログファイルに出力を行うこともできますが、ログ出力用デーモン（ha_logd）経由で出力を行うこともできます。プロセスから直接出力する場合、ログ出力が膨大になったときに、heartbeatやほかの各プロセスがHAクラスタとしての本来の機能にリソースを割くことができなくなる可能性がありますが、ha_logd経由で出力を行うと、そうしたケースを回避できます。

　ha_logdを使用するには、ha.cfにおいて

use_logd	yes

を追加します。デフォルト値はnoです。そして、logd.cfという設定ファイル（サンプルは同様に/usr/share/doc/heartbeat-2.1.3/以下にあります）を/etcに置き、Heartbeatサービスを開始します。このとき、ha.cfに記述したlogfacility、logfile、debugfileの設定は基本的には無視されることになります。

　実際に運用している方はお気付きでしょうが、Heartbeatはかなり大量のログを出力します。これをシステムログにそのまま出力すると、ほかのサービスやシステムのログとの切り分けが困難になってきます。そういった場合に、システムログへの出力を抑止するには、ha.cf（ha_logdを使用する場合は、logd.cf）に、

logfacility	none

と記述します。この場合、logfileかdebugfileを指定し、ほかのファイルに対しログ出力を行うようにします。

種類	use_logdがyesの場合	use_logdが未定義もしくはnoの場合
ログ出力方式	ha_logd経由での出力	各プロセスからの直接出力
設定ファイル	/etc/logd.cf	/etc/ha.d/ha.cf
パフォーマンス	○	△