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 つの仮想ネットワークを用意して 下図のようなネットワーク構成を用意して 検証を実施した 1
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 2
ディレクトリにマウントして利用することとした 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 ms ms_drbd_r0 res_drbd_r0 \ 3
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 の間で何度か移動させ 正常に動作することを確認した スイッチオーバ後 crm_mon コマンドの出力は以下のように変化した 4
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 のサービスは 2 号機で継続された このときの切り替えに要する時間は約 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 秒でフェールオーバが開始した 5
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. 偶発的なデーモンの異常終了に対して 再起動を試みる動作モードとただちにフェールオーバを生じる動作モードが選べること いずれも設定のとおりに動作することを確認できた 6