JP2010055509A - 障害復旧システム、方法及びプログラム、並びにクラスタシステム - Google Patents

Abstract

【課題】アプリケーション障害発生を早期に検出し、ｃｏｒｅファイルを確実に取得しながら、障害発生からクラスタ切り替えまでの時間を短くすることができるクラスタシステムを提供する。
【解決手段】本発明の障害復旧システムは、障害発生時にエラー情報を記憶手段に保存するアプリケーションプロセスを生成起動させるプロセス生成起動手段と、記憶手段に記憶されるエラー情報の保存の有無を監視するエラー情報監視手段と、エラー情報監視手段によりエラー情報の保存が検出されると、当該アプリケーションプロセスの障害を検出するプロセス障害検出手段と、プロセス障害検出手段によりアプリケーションプロセスの障害が検出されると、当該障害の復旧処理を行う障害復旧手段とを備えることを特徴とする。
【選択図】 図１

Description

本発明は、障害復旧システム、方法及びプログラム、並びにクラスタシステムに関し、例えば、稼動系サーバに生じた障害を早期に検出し、待機系サーバに早期に切り替える障害復旧システム、方法及びプログラム、並びにクラスタシステムに適用し得るものである。

近年、継続的にサービスを提供するためにクラスタシステムが広く普及している。クラスタシステムの方式としては種々の方式があるが、複数のサーバを使用して冗長化し、システムの停止時間を最小限に抑え、業務の可用性を向上させる方式としてＨＡ（High Availability）クラスタシステムがある。

このＨＡクラスタシステムは、現用系（以下、稼動系ともいう）サーバで障害を検知すると待機系サーバに切り替え、業務のダウンタイムを短くすることでサーバの信頼性を向上させるシステムである。

そのため、業務の可用性を向上させるためには、稼動系から待機系への切り替え時間を最小限に抑えることが強く望まれており、このような課題を解決する技術として特許文献１に記載の技術がある。特許文献１に記載の技術は、切り替えポリシー定義ファイルを用いて、サービスの利用率に応じたタイミングで切り替える技術である。

ところで、従来のＨＡクラスタシステムにおけるクラスタ切り替え動作は、図２に示すような動作を行う。

図２（Ａ）では、サーバ１Ａは稼動系として動作し、サーバ１Ｂは稼動系として動作し、両サーバ１Ａ及び１Ｂは相互に死活監視を行っている。この死活監視の方法として、例えば、サーバ間でハートビート通信を行うことで相互の生存を確認する方法を適用できる。

そして、稼動系サーバ１Ａに障害が生じると、稼動系サーバ１Ａからのハートビート応答がなくなる。これにより、待機系サーバ１Ｂは稼動系サーバ１Ａの障害を検出し（図２（Ｂ）参照）、サーバ１Ｂが稼動系に切り替えられる（図２（Ｃ）参照）。

図３は、稼動系サーバにおいてＨＡクラスタプロセスがアプリケーションプロセスを監視する動作を説明する説明図である。

例えば、ＵＮＩＸ（登録商標）／Ｌｉｎｕｘ（登録商標）ＯＳ上で、ＨＡクラスタシステムを動作させる場合、ＨＡクラスタシステムプロセスが親プロセスとなり、子プロセスのアプリケーションプロセスを生成・起動し、監視を行うのが一般的である。

図３において、ＨＡクラスタプロセス２が、アプリケーションプロセス３の生成・起動を行い（ステップＳ１）、アプリケーションプロセス３の状態を監視する。

そして、アプリケーションプロセス３に障害が発生し、アプリケーションプロセス３が終了すると、プロセスの終了を知らせるＳＩＧＣＨＩＬＤが通知され（ステップＳ２）、ＨＡクラスタプロセス２は稼動系サーバの切り替え処理を実施する（ステップＳ３）。

特開２００６−２７７６９０号公報

上述したように、システムに致命的な障害が生じると、稼動系サーバのＨＡクラスタプロセスは、アプリケーションプロセスが動作できないことを認識して、待機系への切り替えを行う。

つまり、ＨＡクラスタプロセスは、子プロセスであるアプリケーションプロセスからＳＩＧＣＨＩＬＤを受けた後に、待機系への切り替え処理を行うようにしている。

ところで、例えば、ＵＮＩＸ（登録商標）／Ｌｉｎｕｘ（登録商標）ＯＳ上において、アプリケーションプロセスが異常終了すると、ｃｏｒｅファイルが生成させることができる。

このｃｏｒｅファイルはプロセスのメモリイメージを保存したものであり、アプリケーションプロセス障害時にｃｏｒｅファイルをＨＤＤから出力させることは、アプリケーションの障害解析を行う点で有効である。

図４を用いて、アプリケーションプロセスにおけるｃｏｒｅファイルの出力動作について説明する。

図４において、アプリケーションプロセス３に障害が発生すると、アプロケーションプロセス３は、ｃｏｒｅファイルをＨＤＤへ出力し（ステップＳ４）、出力が終了してから（ステップＳ５）、ＳＩＧＣＨＩＬＤを通知する（ステップＳ２）。

アプリケーションプロセスのプロセスサイズが大きく、メモリを多量に使用している場合、アプリケーションプロセス障害時に出力されるｃｏｒｅファイルのサイズも大きくなる。

そのため、ｃｏｒｅファイルサイズが大きいと、ｃｏｒｅファイルを出力する時間も長くなるため、障害発生から稼動系サーバの切り替え処理までの時間も長くなり、アプリケーションが提供するサービスの中断時間も長くなるという問題が生じ得る。

サービスを早期に復旧させるために、ｃｏｒｅファイルの出力を強制的に停止し、アプリケーションプロセスを再起動させる方法も考えられるが、アプリケーションの障害解析を行うためにｃｏｒｅファイルが必要である。

また、ＨＡクラスタシステムは、アプリケーション障害発生時に早期にサービス復旧を行い、確実にｃｏｒｅファイルを取得できるようにすることが望まれる。

そのため、アプリケーション障害発生を早期に検出し、ｃｏｒｅファイルを確実に取得しながら、障害発生からクラスタ切り替えまでの時間を短くすることができる障害復旧システム、方法及びプログラム、並びにクラスタシステムが求められている。

かかる課題を解決するために、第１の本発明の障害復旧システムは、（１）障害発生時にエラー情報を記憶手段に保存するアプリケーションプロセスを生成起動させるプロセス生成起動手段と、（２）記憶手段に記憶されるエラー情報の保存の有無を監視するエラー情報監視手段と、（３）エラー情報監視手段によりエラー情報の保存が検出されると、当該アプリケーションプロセスの障害を検出するプロセス障害検出手段と、（４）プロセス障害検出手段によりアプリケーションプロセスの障害が検出されると、当該障害の復旧処理を行う障害復旧手段とを備えることを特徴とする。

第２の本発明の障害復旧方法は、障害復旧システムの障害復旧方法において、（１）プロセス生成起動手段が、障害発生時にエラー情報を記憶手段に保存するアプリケーションプロセスを生成起動させるプロセス生成起動工程と、（２）エラー情報監視手段が、記憶手段に記憶されるエラー情報の保存の有無を監視するエラー情報監視工程と、（３）プロセス障害検出手段が、エラー情報監視手段によりエラー情報の保存が検出されると、当該アプリケーションプロセスの障害を検出するプロセス障害検出工程と、（４）障害復旧手段が、プロセス障害検出手段によりアプリケーションプロセスの障害が検出されると、当該障害の復旧処理を行う障害復旧工程とを有することを特徴とする。

第３の本発明の障害復旧プログラムは、コンピュータを、（１）障害発生時にエラー情報を記憶手段に保存するアプリケーションプロセスを生成起動させるプロセス生成起動手段、（２）記憶手段に記憶されるエラー情報の保存の有無を監視するエラー情報監視手段、（３）エラー情報監視手段によりエラー情報の保存が検出されると、当該アプリケーションプロセスの障害を検出するプロセス障害検出手段、（４）プロセス障害検出手段によりアプリケーションプロセスの障害が検出されると、当該障害の復旧処理を行う障害復旧手段として機能させることを特徴とする。

第４の本発明のクラスタシステムは、稼動系サーバ装置と少なくとも１以上の待機系サーバ装置とを有して構成されるクラスタシステムにおいて、各サーバ装置が第１の本発明の障害復旧システムを備えることを特徴とする。

本発明によれば、ｃｏｒｅファイルを確実に取得しながら、アプリケーション障害発生を早期に検出することができるので、障害発生からクラスタ切り替えまでの復旧時間を短くすることができる。

（Ａ）第１の実施形態
以下では、本発明の障害復旧システム、方法及びプログラム、並びにクラスタシステムの第１の実施形態を図面を参照しながら説明する。

第１の実施形態では、２台のサーバからなるＨＡクラスタシステムに、本発明を適用した場合を例示して説明する。

（Ａ−１）第１の実施形態の構成
図５は、第１の実施形態のクラスタシステム５０の構成及びサーバの機能構成を示す構成図である。なお、図５は、クラスタ構成の一例であり、共有ディスクタイプのクラスタ構成を例示するが、ミラーリングタイプのクラスタ構成であってもよい。

図５において、クラスタシステム５０は、２台のサーバ１０Ａ及び１０Ｂと、共有ディスク２０とを有して構成されるものである。

サーバ１０Ａ及び１０Ｂは、様々なサービスを提供するものであり、例えば種々の業務サービスを提供するサーバが該当する。また、サーバ１０Ａ及び１０Ｂのハードウェア構成は、一般的な情報処理装置と同じ構成を有しており、ソフトウェア構成としては、例えば、ＵＮＩＸ（登録商標）／Ｌｉｎｕｘ（登録商標）をＯＳとするものが該当する。

さらに、サーバ１０Ａ及び１０Ｂは、ＨＡクラスタシステムの構成サーバであるから、双方とも同じ機能を備えるものであり、稼動系に障害が生じた場合には、後述するクラスタ制御部１７Ａ及び１７Ｂの制御により、待機系への切替処理が行われる。

なお、図５では、サーバ１０Ａが稼動系であり、サーバ１０Ｂが待機系である場合を示す。

図５に示すように、サーバ１０Ａ及び１０Ｂは、その主な機能として、アプリケーション１１Ａ及び１１Ｂ、ＨＡクラスタ制御部１７Ａ及び１７Ｂを有する。

アプリケーション１１Ａ及び１１Ｂは、種々の業務アプリケーションサービスを提供するものである。障害発生したアプリケーション１１Ａ及び１１Ｂのプロセスは、ＨＤＤ２０に保存されたｃｏｒｅファイルを出力するようにし、ｃｏｒｅファイルの出力が完了すると、異常終了により業務サービスの提供が終了したことを示すＳＩＧＣＨＩＬＤをＨＡクラスタ制御部プロセスに通知するものである。

ここで、アプリケーションプロセスの障害の具体例としては、例えば、アクセス違反等のプログラム異常などが該当する。

ＨＡクラスタ制御部１７Ａ及び１７Ｂは、稼動系サーバにおけるクラスタリング処理を制御するものである。また、ＨＡクラスタ制御部１７Ａ及び１７Ｂは、主な機能として、プロセス生成起動部１２Ａ及び１２Ｂ、ｃｏｒｅファイル監視部１３Ａ及び１３Ｂ、クラスタ切替制御部１５Ａ及び１５Ｂ、ハードビート制御部１６Ａ及び１６Ｂを有する。

プロセス生成起動部１２Ａ及び１２Ｂは、図示しないクライアントから要求されたアプリケーション１１Ａ及び１１Ｂを、子プロセスとして生成し起動させるものである。

ｃｏｒｅファイル監視部１３Ａ及び１３Ｂは、常時又は定期的にＨＤＤ２０を監視し、起動させたアプリケーション１１Ａ及び１１Ｂのプロセスについてｃｏｒｅファイルが存在するかどうかを監視するものである。

ハートビート制御部１６Ａ及び１６Ｂは、相互のサーバ１０Ａ及び１０Ｂ間でインターコネクト通信をするものである。ハートビート制御部１６Ａ及び１６Ｂは、ｃｏｒｅファイル監視部１３Ａ及び１３Ｂによりｃｏｒｅファイルが検出されると、ハートビート通信を停止させるものである。このようにすることで、従来のようにＳＩＧＣＨＩＬＤの通知前に、擬似的に障害検出することができる。また、ハートビートを停止させることで、待機系サーバに対して稼動系サーバの異常発生を認識させることができ、早期に待機系へのサーバ切り替えができる。

また、待機系から稼動系に切り替えされると、ハートビート制御部１６Ａ及び１６Ｂは、ハートビート通信の再開を行うものである。

クラスタ切替制御部１５Ａ及び１５Ｂは、アプリケーション１１Ａ及び１１ＢからＳＩＧＣＨＩＬＤが通知されると、ｃｏｒｅファイルの出力完了を認識し、自サーバを待機系とし、またハートビート制御部１７Ａ及び１７Ｂに対してハートビート通信の再開を指示するものである。

（Ａ−２）第１の実施形態の動作
次に、第１の実施形態のクラスタ切替処理の動作について図１を参照しながら説明する。

図１は、アプリケーションプロセスに障害が生じた場合のクラスタ切替処理を説明する説明図である。

なお、図１の左側のシーケンスは稼動系のＨＡクラスタプロセス及びアプリケーションプロセスの動作を示し、右側は、シーケンスに対応したサーバ切り替え動作を示す。

まず、稼動系サーバ１０Ａにおいて、ＨＡクラスタプロセス４は、アプリケーションプロセス５を生成し起動させる（ステップＳ１０１）。このとき、両サーバ１０Ａ及び１０Ｂ間のハードビート通信が行われ、相互の死活監視を行っている（図５（Ａ）参照）。

また、ＨＡクラスタプロセス４は、定期的にＨＤＤ２０を監視し、起動させたアプリケーションプロセス５についてのｃｏｒｅファイルが生成されたか否かを監視する（ステップＳ１０２）。

このとき、ＨＡクラスタプロセス４は、ｃｏｒｅファイルが保存されているか否かをＯＳ毎に監視する。なお、待機系でのｃｏｒｅファイル監視は、待機系ではアプリケーションがホットスタンバイで動作するような場合は、待機系でのアプリケーション障害の早期検出となる。

その後、アプリケーションプロセス５に障害が発生すると、アプリケーションプロセス５はシグナルを受けて、ｃｏｒｅファイルをＨＤＤ２０に生成する。また、アプリケーションプロセス５は、生成したｃｏｒｅファイルをＨＤＤ２０から出力し始める（ステップＳ１０３）。

一方、ＨＡクラスタプロセス４は、ＨＤＤ２０上のｃｏｒｅファイルを監視しているので、アプリケーションプロセス５についてのｃｏｒｅファイルの検出を契機に（ステップＳ１０４）、ハートビート通信を停止し（ステップＳ１０５）、擬似的な故障を発生させる。

このハートビート通信の停止により、サーバ１０Ｂはサーバ１０Ａの異常を認識し、稼動系への切り替えを行う（図５（Ｂ）参照）。これにより、サーバ１０Ｂは、稼動系として動作を開始する。

その後、アプリケーションプロセス５によるｃｏｒｅファイルの出力が終了すると、アプリケーションプロセス５は、アプリケーション動作を終了して、ＳＩＧＣＨＩＬＤをＨＡクラスタプロセス４に通知する。

これを受けて、ＨＡクラスタプロセス４は、ハートビート通信を再開し、待機系サーバとして稼動する（ステップＳ１０８）。これにより、図５（Ｃ）に示すように、サーバ１０Ａ及び１０Ｂの間で監視しながら、サーバ１０Ｂが稼動系として動作する。

上記のように、ＨＡクラスタプロセスにおいて、アプリケーション障害発生時に発生するｃｏｒｅファイルの存在を定期的に監視し、ｃｏｒｅファイル検出時にインターコネクト通信を停止させることで、擬似的な故障を発生させることにより、早期にサービスの復旧が可能となる。

また、アプリケーションプロセス終了を契機に待機系サーバとして稼動させることで確実にｃｏｒｅファイルの取得が可能となる。

（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、アプリケーションプロセスが出力するｃｏｒｅファイルをＨＡクラスタシステムにて定期的に監視することで、早期にアプリケーションの障害を検出することができる。

また、第１の実施形態によれば、ＨＡクラスタシステムにおいて、アプリケーション障害検出を契機にハードビート通信を停止することにより、待機系サーバに障害を検出させることができるからクラスタ切替を実行させ、サービス復旧を行うことができる。

さらに、第１の実施形態によれば、アプリケーションのｃｏｒｅファイル出力完了後に、ＨＡクラスタプロセスを待機系サーバに復旧することにより、確実にｃｏｒｅファイルを収集させることができる。

（Ｂ）第２の実施形態
次に、本発明の障害復旧システム、方法及びプログラム、並びにクラスタシステムの第２の実施形態について説明する。

（Ｂ−１）第２の実施形態の構成及び動作
第１の実施形態では、ＨＡクラスタプロセス４が、ｃｏｒｅファイル出力を契機にハートビート通信を停止する場合の実施形態を説明した。

これに対して、第２の実施形態は、ＨＡクラスタプロセスが、ｃｏｒｅファイル出力を契機に別プロセスのアプリケーションを生成・起動するものである。

第２の実施形態の構成は、第１の実施形態の構成に対応するから図５を用いて説明する。

第２の実施形態のプロセス生成起動部１２Ａ及び１２Ｂは、別のプロセスを起動可能なものである。プロセス生成起動部１２Ａ及び１２Ｂは、ｃｏｒｅファイル監視部１３Ａ及び１３Ｂによりｃｏｒｅファイルが検出されると、別のプロセスとしてアプリケーションを生成し、起動するものである。

これにより、クラスタシステムでない場合にも、アプリケーションプロセスを別プロセスとして生成し起動させることができるので、早期にサービスを復旧させることができる。

また、プロセス生成起動部１２Ａ及び１３Ｂは、アプリケーションプロセスからＳＩＧＣＨＩＬＤを受け取ると、ＨＡクラスタプロセスにて無視するようにする。

（Ｂ−２）第２の実施形態の効果
以上のように、第２の実施形態によれば、クラスタシステム構成でない場合にも、第１の実施形態と同様に、アプリケーション障害の早期検出、早期サービス復旧、確実なｃｏｒｅファイルの収集を行うことができる。

（Ｃ）他の実施形態
第１及び第２の実施形態で説明した各サーバ１０Ａ及び１０Ｂのクラスタシステムの機能は、ソフトウェア処理により実現されるものである。つまり、各サーバのハードウェア構成として、例えばＣＰＵ、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ等を有して構成されるものであり、ＣＰＵが、ＲＯＭに格納される処理プログラムを実行することにより第１及び第２の実施形態で説明した機能を実現することができる。

第１及び第２の実施形態では、２台のサーバからなるシステムにおいて、稼動系サーバのみがアプリケーション障害検出処理を実施する場合を例示したが、３台以上のクラスタシステムにも広く適用することができる。

本発明は、様々なクラスタシステムのタイプに適用することができ、例えば、共有ディスクタイプやデータミラータイプのいずれにも適用することができる。

第１の実施形態のクラスタ切替処理を説明する説明図である。 従来のクラスタ切替処理を説明する説明図である。 従来の稼動系サーバにおいてＨＡクラスタプロセスがアプリケーションプロセスを監視する動作を説明する説明図である。 従来のアプリケーションプロセスにおけるｃｏｒｅファイルの出力動作について説明する説明図である。 第１の実施形態のクラスタシステムの構成及びサーバの機能構成を示す構成図である。

符号の説明

１０Ａ…サーバ（稼動系）、１０Ｂ…サーバ（待機系）、４…ＨＡクラスタプロセス、５…アプリケーションプロセス、１１Ａ及び１１Ｂ…アプリケーション部、１２Ａ及び１２Ｂ…プロセス生成起動部、１３Ａ及び１３Ｂ…ｃｏｒｅファイル監視部、１５Ａ及び１５Ｂ…クラスタ切替制御部、１６Ａ及び１６Ｂ…ハートビート制御部、５０…クラスタシステム。

Claims (7)

1. 障害発生時にエラー情報を記憶手段に保存するアプリケーションプロセスを生成起動させるプロセス生成起動手段と、
   上記記憶手段に記憶される上記エラー情報の保存の有無を監視するエラー情報監視手段と、
   上記エラー情報監視手段により上記エラー情報の保存が検出されると、当該アプリケーションプロセスの障害を検出するプロセス障害検出手段と、
   上記プロセス障害検出手段により上記アプリケーションプロセスの障害が検出されると、当該障害の復旧処理を行う障害復旧手段と
   を備えることを特徴とする障害復旧システム。
2. 上記障害復旧手段が、他のサーバとの間で定期的に生存確認通信を行うものであって、上記プロセス障害検出手段により上記アプリケーションプロセスの障害が検出されると、他のサーバとの間の上記生存確認通信を停止させる生存確認通信部を有することを特徴とする請求項１に記載の障害復旧システム。
3. 上記障害復旧手段が、上記記憶手段から上記エラー情報の取得完了後に、稼動系から待機系への切り替えを行うクラスタ切替部をさらに備える請求項２に記載に障害復旧システム。
4. 上記プロセス生成起動手段が、上記プロセス障害検出手段により上記アプリケーションプロセスの障害が検出されると、当該アプリケーションプロセスを別プロセスとして生成起動するものであることを特徴とする請求項１に記載の障害復旧システム。
5. 障害復旧システムの障害復旧方法において、
   プロセス生成起動手段が、障害発生時にエラー情報を記憶手段に保存するアプリケーションプロセスを生成起動させるプロセス生成起動工程と、
   エラー情報監視手段が、上記記憶手段に記憶される上記エラー情報の保存の有無を監視するエラー情報監視工程と、
   プロセス障害検出手段が、上記エラー情報監視手段により上記エラー情報の保存が検出されると、当該アプリケーションプロセスの障害を検出するプロセス障害検出工程と、
   障害復旧手段が、上記プロセス障害検出手段により上記アプリケーションプロセスの障害が検出されると、当該障害の復旧処理を行う障害復旧工程と
   を有することを特徴とする障害復旧方法。
6. コンピュータを、
   障害発生時にエラー情報を記憶手段に保存するアプリケーションプロセスを生成起動させるプロセス生成起動手段、
   上記記憶手段に記憶される上記エラー情報の保存の有無を監視するエラー情報監視手段、
   上記エラー情報監視手段により上記エラー情報の保存が検出されると、当該アプリケーションプロセスの障害を検出するプロセス障害検出手段、
   上記プロセス障害検出手段により上記アプリケーションプロセスの障害が検出されると、当該障害の復旧処理を行う障害復旧手段
   として機能させることを特徴とする障害復旧プログラム。
7. 稼動系サーバ装置と少なくとも１以上の待機系サーバ装置とを有して構成されるクラスタシステムにおいて、上記各サーバ装置が請求項１〜４のいずれかに記載の障害復旧システムを備えることを特徴とするクラスタシステム。

Images