TOP
＞
比較データ
＞ LifeKeeperにおける障害監視と検知
徹底比較!!クラスタソフトウェア
第３回：GUI操作だけでHAクラスタが構成できる「LifeKeeper」
著者：
サイオステクノロジー 小野寺 章
2005/11/30
前のページ
1
2
3
4
次のページ
LifeKeeperにおける障害監視と検知
LifeKeeperが検出可能な障害は、ノード障害、ネットワーク障害、アプリケーションの障害、共有ディスクへのアクセス障害がある。
ノード障害の監視
ノード監視はハートビートと呼ばれるデータの定期的な交換によって相互の死活を監視している。これを行うのが表2で説明したLCMである。ハートビートラインとして設定できるメディアはTCPとTTYである。TCPハートビートは最大98まで設定することが可能である。
TTYとはシリアルラインを指しているがTTYハートビートは2ノード間では最大1つ設定可能となっている。設定したハートビートラインは常にLCMにより相互に状態が監視されており、設定されているハートビートラインのうち１つでも不通となった場合は、GUI上のサーバアイコンが緑から黄色に変わりオペレータに注意をうながす仕組みとなっている（図3）。
図3：ハートビートラインの監視
このハートビートラインはコミュニケーションパスとも呼ばれ、LCDI経由で更新されたサービスの状態をほかのノードのLCDに反映させるための通信経路としても使用される。LifeKeeperにおけるノード障害はすべてのハートビートが不通となった場合を指す。
ネットワーク障害
ネットワークの監視と障害の検知は、仮想IP（IPリソース）を定義したNICに対してIPリソースの監視という形で定期的に行われる。非常にシンプルかつ確実な実装となっており、LifeKeeperにおける仮想IPの定義はLinuxのIPエイリアス機能によって実現している。
図4は図1のサーバAとサーバBに対してクライアントからのアクセスをIP-Cで行う構成例である。
図4：クラスタ構成例
サーバAのeth0は実IP（IP-A）を持ち、サーバBのeth0は実IP（IP-B）を持っている。LifeKeeperはIPリソースをActiveとするサーバ側で以下のコマンドを実行するのである。
ifconfig eth0:1
IP-C
そしてLCD内に保持しているIPリソースの情報からIP-Cが定義されているNICはサーバAのeth0とサーバBのeth0であることを得て、定期的なリソースの監視としてIP-AとIP-B間でpingを実行するのである。この監視において相手ノードからの応答がない場合、ネットワークに対してBroadcast pingを送出し応答があれば自ノードのNICおよびケーブルは正常でネットワークへのアクセスができていると判断する。
アプリケーションの障害
アプリケーション（サービス）の監視はARKによって行われる。LifeKeeperはアプリケーションごとのARKが用意されており、各ARKによって監視する項目は異なる。
今回は代表的な例としてOracle ARKが行う監視を説明する。
Oracle ARKはOracle 9i SE/EE、Oracle 10g SE/SE One/EEに対応している。監視はpsコマンドでpmonの存在チェックを行うとともに、oracle管理ユーザの権限でsqlplusを起動し、以下のコマンドを発行して実際のアクセスが可能かどうかを監視している。
connect / as sysdba
select * from dba_data_files;
チェックに失敗した場合、ローカルノードでのデータベースの再起動処理が実行される。そして、再度pmonのチェックと表への問い合わせを行って起動の確認をする。起動に失敗した場合はフェイルオーバが実行される。ローカルノードでのサービスの再起動処理をローカルリカバリと呼ぶ。ローカルリカバリはフェイルオーバを最終手段とし、システム全体の可用性をできるだけ高めるためのポリシーで、すべてのARKは基本的にこのポリシーが組み込まれている。
共有ディスクへのアクセス障害
共有ディスクの監視は、マウントポイント／ファイルシステム／ディスクから構成され、ファイルシステムリソースが定義されると開始される。
図5はファイルシステムリソースのリソース階層を表している。
図5：リソース階層
LifeKeeperは、LUNレベルでロックするSCSI-2のReservationによりアクセス制御を実現しており、ファイルシステムリソースがActiveとなっているノード以外からは絶対にディスクにアクセスできない仕組みとなっている。この方式は、どんな状況においても両ノードから同時マウントしてしまうことに起因するファイルシステムの破壊が起こらないという利点がある。
両系マウントが起きる可能性として最も多いのが、スプリットブレイン時である。quorum方式を採用しているクラスタソフトウェアの場合、タイミングによっては両系が同時にquorumへのアクセスが可能となりオーナーを取得してしまうことがある。また、オペレーターが誤って手動でマウントを実行してしまう場合もある。このようなミスオペレーションもLifeKeeperは阻止することが可能である。
LUNレベルで稼動系からロックされた共有ディスクは定期的にロック状況の確認とマウント状況の確認が実行される。ロック状況の確認はSCSIレベルのコマンド発行により確認を行う。マウント状況の確認は、"/etc/mtab"の情報から、正しくマウントされているかや空き容量のチェックなどを行っている。
前のページ
1
2
3
4
次のページ
著者プロフィール
サイオステクノロジー株式会社 小野寺 章
インフラストラクチャービジネスユニット
エンタープライズソリューション部 部長
国産汎用機メーカに入社し、汎用機のSEを10数年担当、1994年頃からオープン・ダウンサイジングブームの到来とともにUNIX系OSを担当し、Solaris、HP/UXでSun Cluster、Veritas Cluster、MC/ServiceGuardなどを使用した、多数のミッションクリティカルシステムのHAシステム構築に従事。2001年ノーザンライツコンピュータ（現サイオステクノロジー）へ入社後、SteelEye LifeKeeperの総責任者としての国内での販売・サポート業務に従事。
INDEX
第3回：GUI操作だけでHAクラスタが構成できる「LifeKeeper」
LifeKeeper for Linuxの概要
LifeKeeperのアーキテクチャ
LifeKeeperにおける障害監視と検知
スプリットブレイン時の動作
