Thirdware Linux-HA による HULFT7 のクラスタリング
ー RHEL 5.7 でアクティブ・スタンバイ・クラスタとして動作を確認 ー
HULFT7 は基幹業務システムで他のコンピュータとの間でデータを連携するために 幅広く使われているソフトウェアで、日本におけるデファクト・スタンダードの製品と なっている。アクティブ・スタンバイ構成の HA クラスタ構成にも対応しているため、 Thirdware Linux-HA と組み合わせた動作の検証試験を実施した。1 検証試験の目的
今回の検証試験では、以下の項目についての検証・評価を実施した。 1. HA クラスタ環境に対して HULFT7 を正常にインストールして環境設定できること 2. Thirdware Linux-HA によるクラスタ環境で HULFT7 が稼働すること3. さまざまな障害に対して HULFT7 がフェールオーバし、サービスの可用性を維持できること
2 検証試験環境
2.1 機器構成、ソフトウェア構成
今回の検証試験には、以下の仮想マシン環境を使用した。 • ホスト OS: KVM (Red Hat Enterprise Linux 6.1) • ゲスト OS: Red Hat Enterprise Linux 5.7 (2 台) • メインメモリ(ゲスト OS): 512MB
• HULFT7 for Linux-EX Ver.07.02.00.A
2.2 ネットワーク構成
Thirdware Linux-HA は、アクティブ・スタンバイ構成の HA クラスタシステムの場合、次のような 3 つのネットワー クインタフェースを用意することを推奨している。 • クライアントなどと通信するためのネットワーク • DRBD のデータレプリケーション用ならびにクラスタのハートビート通信用ネットワーク • ハートビート通信用ネットワーク この原則を踏まえて、2 台のゲスト OS と 3 つの仮想ネットワークを用意して、下図のようなネットワーク構成を用意 して、検証を実施した。3 検証結果
3.1 ソフトウェアのインストール
• Red Hat Enterprise Linux 5.7 は最小構成でインストールし、最新バージョンにアップデートした。 • Thirdware Linux-HA を構成するパッケージ(DRBD、Heartbeat、Pacemaker)は LINBIT 社の認定バイナ
リをダウンロードしてインストールした。各ソフトウェアのバージョンは以下のとおり。 ◦ DRBD 8.3.12 ◦ Heartbeat 3.0.5 ◦ Pacemaker 1.0.11 ◦ Resource Agents 1.0.4 • HA クラスタとして動作させるためのディスク設定など(後述)を実施した後、セゾン情報システムから支 給された HULFT7 for Linux-EX をインストールした。インストールは「HULFT7 UNIX/Linux 導入マニュ アル」の説明のとおりに実施した。ただし、HULFT 実行モジュール格納ディレクトリ(HULEXEP)はデフォ ルト値のままを指定したが、HA クラスタ環境へのインストールであるため、HULFT 環境設定ファイル格 納ディレクトリ(HULPATH)については、DRBD で冗長化した共有ディスク領域(/h/HULFT)を指定した。
3.2 Thirdware Linux-HA による共有ディスクの取り扱い
Thirdware Linux-HA に含まれる DRBD は、2 台のクラスタ構成ノードのディスク領域をネットワーク越しにリアル タイムで同期させることによって、外付け共有ディスク装置と同等に取り扱える共有ディスク領域を実現する。同 一データが 2 台のクラスタ構成ノードのディスクに同時に書き込まれるため、ハードディスクのクラッシュなどの障 害でデータを喪失するリスクが極めて低くなる。 このような DRBD のメリットを実現するため、ゲスト OS (RHEL 65.7)をインストールするときに、8GB 用意した仮 想ディスクを次のようなパーティションに分割した(fdisk -l コマンド出力結果)。[root@hulft1 bin]# fdisk -l
Disk /dev/vda: 8388 MB, 8388608000 bytes 255 heads, 63 sectors/track, 1019 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes
デバイス Boot Start End Blocks Id System /dev/vda1 * 1 14 112423+ 83 Linux /dev/vda2 15 525 4104607+ 83 Linux
/dev/vda3 526 590 522112+ 82 Linux swap / Solaris /dev/vda4 591 1019 3445942+ 83 Linux
/dev/vda1 は/boot に、/dev/vda2 はルート(/)にマウントし、2 台の/dev/vda4 同士を DRBD で冗長化するように設定 した。DRBD によるレプリケーションの初期化が完了した後、このレプリケーション領域はアクティブノード側で/h
ディレクトリにマウントして利用することとした。
3.3 HA クラスタ設定
Thirdware Linux-HA では、Heartbeat および Pacemaker を使って HA クラスタを構成する。HULFT7 の場合、クラ スタ設定手順は以下のようなステップで構成される。 1. Heartbeat の動作パラメータを設定する。これは 2 台のクラスタ構成ノードでまったく同一でなければなら ない。 2. Heartbeat を起動して、初期状態のクラスタを起動する。この時点では、HULFT7 を含めて、一切のクラス タリソースは動作していない。 3. DRBD を「両方のノードで動作してアクティブノード側ではプライマリ、スタンバイノード側ではセカンダリ として動作するリソース」として定義する。プライマリ側では DRBD を経由してディスクにデータを書き込 めるば、セカンダリ側 DRBD はプライマリ DRBD から受け取ったデータをディスクに書き込むだけの役 割として動作する。この役割分担により、同時書き込みアクセスによるファイルシステム破壊を防止でき る。DRBD の管理には、開発元 LINBIT 社が提供している drbd リソースエージェントがそのまま利用で きる。 4. HULFT7 がサービスを提供するための仮想 IP アドレス、HULFT 環境設定ファイル格納ディレクトリ (HULPATH)にアクセスするための DRBD レプリケーション領域のマウント、そして HULFT7 デーモン (hulsndd、hulrcvd、hulobsd)をリソースとして定義する。仮想 IP アドレスの管理には IPaddr2、マウントの管 理には Filesystem という Resource Agent に含まれるプログラムがそのまま利用できる。HULFT7 の管理 には別途スクリプトが必要になるため、hulft という名前のスクリプトを作成して利用した。
5. DRBD プライマリ側で HULFT7 が動作するよう、リソースの依存関係を正しく定義する。
3.3.1 hulft スクリプト
hulft スクリプトは、Red Hat Enterprise Linux に含まれている各種サービスの起動スクリプト(/etc/rc.d/init.d ディレ クトリ内に置かれているスクリプト群)に類似したスクリプトで、以下のように動作する。
• start を指定して実行すると、HULFT7 を構成するデーモン(hulsndd、hulrcvd、hulobsd)を起動する。 • stop を指定して実行すると、HULFT7 の実行を終了する。
• status を指定して実行すると、HULFT の動作状態をメッセージならびにリターンコードで報告する。実行 中ならばリターンコードは 0、停止中なら 3 となる。
構築した HA クラスタシステムのクラスタ制御の設定は以下のようになった(オプションパラメータなどは省略)。 primitive res_drbd_r0 ocf:linbit:drbd \
params drbd_resource="r0" primitive res_hulft lsb:hulft
primitive res_ip ocf:heartbeat:IPaddr2 \
params ip="<IP アドレス>" cidr_netmask="<ネットマスク>" \ primitive res_mount ocf:heartbeat:Filesystem \
params device="/dev/drbd0" fstype="ext3" directory="/h" options="noatime" group hulft res_mount res_ip res_hulft
meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" \ notify="true"
colocation c_hulft inf: hulft ms_drbd_r0:Master order o_hulft inf: ms_drbd_r0:promote hulft:start property default-resource-stickiness="200" \ no-quorum-policy="ignore" \ stonith-enabled="false"
3.4 HA クラスタの動作確認
3.4.1 クラスタ開始時の動作
クラスタを構成する 2 台のノードをともに停止状態から起動すると、約 2 分後にクラスタ 1 号機(hulft1)がアクティ ブな状態になり、HULFT7 サービスが利用可能になった。 DRBD に関しては、1 号機ではプライマリ状態、2 号機(hulft1)ではセカンダリ状態になり、アクティブ側の HULFT7 がディスクに書き込んだ情報はリアルタイムに 2 号機にもレプリケートされていることを確認した。 Pacemaker に付属のクラスタ動作状況確認コマンド(crm_mon)の出力は次のようになった。Online: [ hulft2 hulft1 ]
Resource Group: hulft
res_mount (ocf::heartbeat:Filesystem): Started hulft1 res_ip (ocf::heartbeat:IPaddr2): Started hulft1 res_hulft (lsb:hulft): Started hulft1
Master/Slave Set: ms_drbd_r0 Masters: [ hulft1 ] Slaves: [ hulft2 ] この出力は以下のように解釈できる。 • クラスタは hulft1 と hulft2 の 2 台のサーバで構成され、両方がオンライン状態にある。 • DRBD は正常に動作していて、hulft1 がマスター、hulft2 はスレーブ状態になっている。マスター側には HULFT7 が状態などのデータを書き込めるが、スレーブ側はそれを忠実にリアルタイムにレプリケートし ている。 • hulft1 上で HULFT7 が動作している。
3.4.2 手動操作によるリソース移動(スイッチオーバ)
クラスタ構成ノードのメンテナンスのために、アクティブノードを移動させることがある。Thirdware Linux-HA では migrate (または move)コマンドでこのようなスイッチオーバを管理できる。HULFT7 を hulft1 と hulft2 の間で何度 か移動させ、正常に動作することを確認した。Online: [ hulft2 hulft1 ]
Resource Group: hulft
res_mount (ocf::heartbeat:Filesystem): Started hulft2 res_ip (ocf::heartbeat:IPaddr2): Started hulft2 res_hulft (lsb:hulft): Started hulft2
Master/Slave Set: ms_drbd_r0 Masters: [ hulft2 ] Slaves: [ hulft1 ] 初期状態と比較するとホスト名が入れ替わっていることが確認できる。すなわち、HULFT7 は hulft2 上で動作し ていることがわかる。
3.4.3 アクティブノード側クラスタを停止したときの動作
アクティブノード側(hulft1)の Heartbeat をコマンドによって終了させると、2 号機(hulft2)がアクティブ状態に遷移し、 HULFT7 のサービスは２号機で継続された。このときの切り替えに要する時間は約 10 秒であった。
DRBD に関しては、当初は hultft1 がプライマリであったが、hulft2 がアクティブに遷移するのに伴って hulft2 がプ ライマリになり、共有ディスクへのアクセスが正常に切り替わることが確認できた。
hulft1 を停止したときの crm_mon の出力を下記に示す。
Online: [ hulft2.3ware.co.jp ] OFFLINE: [ hulft1.3ware.co.jp ]
Resource Group: hulft
res_mount (ocf::heartbeat:Filesystem): Started hulft2.3ware.co.jp res_ip (ocf::heartbeat:IPaddr2): Started hulft2.3ware.co.jp res_hulft (lsb:hulft): Started hulft2.3ware.co.jp
Master/Slave Set: ms_drbd_r0 Masters: [ hulft2.3ware.co.jp ] Stopped: [ res_drbd_r0:1 ]
3.4.4 アクティブノード障害時の動作
アクティブ状態の hulft1 に対して仮想マシンマネージャーから「電源オフを強制」を実行して電源障害をシミュ レートした。約 30 秒後に Linux-HA クラスタは障害を検出し、hulft2 にすべてのリソースがフェールオーバし、約 40 秒のダウンタイムでサービスが継続できることが確認できた。 なお、何も起こらない 30 秒という時間は、Heartbeat のデフォルト設定値である。パケットロスや高負荷などによっ てハートビート信号が欠落したことによって誤ってノード障害と判断してしまう「フォールス・ポジティブ(誤検知)」 を避けるための安全側に振った推奨値とされている。ネットワーク品質が高く負荷も高くない環境では、小さい値 を指定してダウンタイムをさらに短縮できる可能性がある。実際に 10 秒に設定したところ、アクティブノードダウン 後約 10 秒でフェールオーバが開始した。3.4.5 サービスダウン時の動作
正常運用時の HULFT7 関連デーモンの動作状態は次のようになっている。 [root@hulft1]# ps ax|grep hul
18680 ? S 0:00 /usr/local/HULFT/bin/hulsndd 18686 ? S 0:00 /usr/local/HULFT/bin/hulrcvd 18692 ? S 0:00 /usr/local/HULFT/bin/hulobsd 18694 ? S 0:00 /usr/local/HULFT/bin/hulobsd 操作ミスその他の偶発的な理由でいくつかのデーモンが終了してしまった場合、再起動を試みて成功した場合 にはそのまま運用を続けるという立場がある。このような運用が可能か、検証を行った。 動作中のデーモンを kill コマンドで強制終了させる試験をさまざまなパターンで実施した。その結果、クラスタは 異常を検出し、HULFT7 を再起動した。再起動後の状況は、たとえば以下のようになる。
[root@hulft1]# ps ax|grep hul
23405 ? S 0:00 /usr/local/HULFT/bin/hulsndd 23411 ? S 0:00 /usr/local/HULFT/bin/hulrcvd 23417 ? S 0:00 /usr/local/HULFT/bin/hulobsd 23419 ? S 0:00 /usr/local/HULFT/bin/hulobsd 左端の数字(プロセス ID)が変化しているが、これはクラスタが HULFT7 を再起動したことを表している。 なお、1 回でもデーモンが異常終了したらフェールオーバさせたいという運用ポリシーを立てることもありえる。こ のような場合には、リソース定義に migration-threshold=1 というオプションパラメータを追加すればよい。実際に、 このパラメータを指定した場合には、どれかのデーモンの異常終了によってフェールオーバが起きることも確認し た。
4 結論
Thirdware Linux-HA 環境で HULFT7 の運用の可能性を検証した。その結果、Linux-HA クラスタは HULFT7 を HA クラスタとして正しく運用できることが確認できた。具体的に得られた知見は以下のとおりである。
1. あらかじめ DRBD などの Thirdware Linux-HA 用の設定を行っておけば、HULFT7 に付属するインス トールマニュアルの手順に従って HULFT7 をインストールできることが確認できた。 2. DRBD によるリアルタイムレプリケーション環境に HULFT 環境設定ファイル格納ディレクトリ (HULPATH)を置いて HULFT7 が正常に動作することを確認できた。 3. 手動操作によって HULFT7 を他のノードに移動できることを確認した。 4. アクティブノードのハードウェア障害によってフェールオーバが生じることを確認できた。また、障害発生 からフェールオーバ開始までの時間をパラメータによって調整できることを確認できた。 5. 偶発的なデーモンの異常終了に対して、再起動を試みる動作モードとただちにフェールオーバを生じる 動作モードが選べること、いずれも設定のとおりに動作することを確認できた。
