JP4112191B2 - 分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体 - Google Patents
分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体 Download PDFInfo
- Publication number
- JP4112191B2 JP4112191B2 JP2001143756A JP2001143756A JP4112191B2 JP 4112191 B2 JP4112191 B2 JP 4112191B2 JP 2001143756 A JP2001143756 A JP 2001143756A JP 2001143756 A JP2001143756 A JP 2001143756A JP 4112191 B2 JP4112191 B2 JP 4112191B2
- Authority
- JP
- Japan
- Prior art keywords
- failure
- domain
- restart
- server
- apl
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Retry When Errors Occur (AREA)
- Hardware Redundancy (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数の汎用サーバにより構成された分散構成のサーバシステムにおいて、ソフト障害、もしくはハード障害を検出し、関連するプロセスの再起動、プロセスの正常な汎用サーバでの再起動、再度運転状態への復帰を行う分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体に関する。
【０００２】
【従来の技術】
図１３は、従来からの高信頼性を実現するサーバクライアント型のシステム構成を示すブロック図である。センタ装置１０１は、複数のクライアント１０７〜１０９とＤＣＮ１０６を介して接続可能であり、ＬＡＮ１０５に接続した複数のサーバ１０２〜１０４により構成されている。サーバ上に動作する複数のプロセス１１１〜１１３の連携によりサービス１１０を提供する。このような構成において、サービスの中断となる要因は、ソフト障害とハード障害とである。
【０００３】
ソフト障害としては、サーバ上で動作するプロセスのメモリ操作違反によるプロセスの異常停止が挙げられる。ソフト障害を救済する方法として、ソフト障害を検出した場合、当該プロセスを初期化再起動し、サービスを継続する方法が取られる。しかしながら、プロセスの特性により、複数のサービスに共用されるプロセスの場合、障害が発生したプロセスのみの救済では、システムとして安定したサービスの再開が行える保証が無く、まとまった単位でプロセスを初期化再起動しサービスを救済する方法が必要である。
【０００４】
また、ハード障害としては、構成するサーバのＣＰＵやボードの故障によるプロセスの異常停止が挙げられる。ハード障害を救済する方法は、運用サーバ上のプロセスを救済するための待機サーバを用意する方法により３つに分類される。Ｎ台の運用サーバに対して同じ数の待機サーバを用意する２Ｎ台構成、Ｎ台の運用サーバに対して１台の待機サーバを用意するＮ＋１台構成、Ｎ台の運用サーバに対して待機サーバを用意せず、正常な運用サーバにおいて故障したサーバ上のプロセスを救済するＮ台構成がある。何れの構成においても、サーバが故障した場合、他のサーバにおいて、故障したサーバ上のプロセスを再起動し、サービスを継続する方法が取られる。加えて、ハード障害の場合、当該ハードで動作するプロセスのソフト障害と考えられるため、ソフト障害の救済方法も適用する必要がある。
【０００５】
【発明が解決しようとする課題】
ところで、上述した従来技術では、ソフト障害の場合、故障した当該プロセスの特性を分類し、プロセス種別にあわせた救済方法を実施し、ハード障害の場合、当該サーバ上で動作する全てのプロセスを他のサーバで救済する際、障害サーバ上で動作していたプロセスにあわせた救済方法も実施する必要がある。
【０００６】
分散サーバ構成において動作するプロセスは、分散構成を意識しないで動作するＡＰＬプロセスと、分散構成をＡＰＬプロセスに意識させないための機能を持ち、複数のＡＰＬプロセスの情報を管理する共用プロセスとに分類できる。図１４に共用プロセスとＡＰＬプロセスとの関係を示す。
【０００７】
サービスＡは、ＡＰＬプロセスＡ１〜Ａ４の連携により提供される。共用プロセスＥ１、Ｅ２は、サービスＡの各プロセスの連携状態を管理する。同様にサービスＢも、ＡＰＬプロセスＢ１〜Ｂ４の連携により提供される。共用プロセスＥ１、Ｅ２は、サービスＢの各プロセスの連携状態も管理する。
【０００８】
いずれかのＡＰＬプロセスが停止した場合には、当該ＡＰＬプロセスを再起動するのみで、サービスの再開が可能となる。これに対して、いずれかの共用プロセスが停止した場合には、分散サーバ上のプロセス間の情報を管理するため、管理下のプロセスと共用プロセス間の情報の一貫性が崩れる可能性がある。
【０００９】
そのため、共用プロセスの再起動のみでは、システムの安定的なサービスの復旧ができないという問題がある。そこで、この問題を解決する方法として、早急な回復手段である共用プロセスの管理下のプロセス全てを再開する手法を用いることが考えられる。しかしながら、全てのプロセスを再開することにより、再開完了までの期間、全てのサービスが停止してしまうという問題がある。
【００１０】
また、交換機のように、主メモリの同期運転を行っていないサーバを活用する場合、ＯＳの起動時間や再開するプロセスの数により再開時間が余儀なく長期化するという問題がある。
【００１１】
この発明は上述した事情に鑑みてなされたもので、ソフト障害、ハード障害に対し、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化することができ、また、サービスの中断時間を短縮することができる分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上述した問題点を解決するために、請求項１記載の発明では、システムを複数のサーバにより構成する分散サーバシステムにおいて、システム障害が発生した場合、その障害を検出し、故障部位を特定する故障部位特定手段と、前記故障部位特定手段により、ソフト障害と特定された場合、そのソフト障害が発生したプロセスの種別に基づいて復旧手順を決定し、決定した復旧手順に従って前記プロセスを再起動させる再開手段と、前記故障部位特定手段により、ハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動するサーバ切替え手段とを具備し、前記複数のサーバは、該複数のサーバをＮ台としたとき、Ｌ（＞１）個のサーバ群からなるドメインに分割され、前記再開手段は、前記プロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定することを特徴とし、前記再開手段は、ソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行い、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させることを特徴とし、前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとは、それぞれ異なったドメイン内に起動され、前記再開手段は、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させることを特徴とする。
【００１５】
また、請求項２記載の発明では、請求項１に記載の分散サーバシステムにおいて、ソフト障害またはハード障害の発生後、前記運用状態プロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻す状態復帰手段を具備することを特徴とする。
【００１６】
また、上述した問題点を解決するために、請求項３記載の発明では、複数のサーバにより構成される分散サーバシステム上で生じた障害を復旧させる障害復旧方法において、前記複数のサーバをＮ台としたとき、該Ｎ台のサーバをＬ（＞１）個のサーバ群からなるドメインに分割し、システム障害が発生した場合、当該システム障害に対応するプロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定することを特徴とし、システム障害が発生した場合、該システム障害を検出して故障部位を特定し、故障部位がソフト障害であった場合に、このソフト障害の発生したプロセスの種別がが、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記分割されたドメイン単位で前記プロセスを再起動させ、故障部位がハード障害であった場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させ、ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させることを特徴とし、前記プロセスを、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成し、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動し、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させることを特徴とする。
【００２０】
また、請求項４記載の発明では、請求項３に記載の障害復旧方法において、ソフト障害またはハード障害の発生後、前記運用状態プロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻すことを特徴とする。
【００２１】
また、上述した問題点を解決するために、請求項５記載の発明では、分散サーバシステムを構成する複数のサーバをＮ台としたとき、該Ｎ台のサーバをＬ（＞１）個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理するステップと、前記分散サーバシステム上でシステム障害が発生した場合、前記分割されたドメイン単位に再開範囲を限定し、前記特定された故障部位に基づいて、当該システム障害が生じたプロセスを再起動させるステップと、システム障害が発生した場合、その障害を検出して故障部位を特定するステップと、故障部位がソフト障害と特定した場合に、そのソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記プロセスを再起動させるステップと、故障部位がハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるステップと、ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させるステップと、前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動するステップと、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させるステップとをコンピュータに実行させることを特徴とする。
【００２４】
また、請求項６記載の発明では、請求項５に記載の障害復旧プログラムにおいて、ソフト障害またはハード障害の発生後、運用状態のプロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻すステップをコンピュータに実行させることを特徴とする。
【００２５】
また、上述した問題点を解決するために、請求項７記載の発明では、分散サーバシステムを構成する複数のサーバをＮ台としたとき、該Ｎ台のサーバをＬ（＞１）個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理するステップと、前記分散サーバシステム上でシステム障害が発生した場合、前記分割されたドメイン単位に再開範囲を限定し、前記特定された故障部位に基づいて、当該システム障害が生じたプロセスを再起動させるステップと、システム障害が発生した場合、その障害を検出して故障部位を特定するステップと、故障部位がソフト障害と特定した場合に、そのソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記プロセスを再起動させるステップと、故障部位がハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるステップと、ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させるステップと、前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動するステップと、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させるステップとをコンピュータに実行させるための障害復旧プログラムを記録したことを特徴とする。
【００２７】
この発明では、前記複数のサーバをＮ台としたとき、Ｌ（＞１）個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理する。システム障害が発生した場合、故障部位特定手段により、その障害を検出して故障部位を特定し、ソフト障害と特定された場合には、再開手段により、そのソフト障害が発生したプロセスの種別に基づいて復旧手順を決定し、決定した復旧手順に従って前記プロセスを再起動させる。このとき、前記再開手段は、前記プロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定する。一方、ハード障害と特定された場合、サーバ切替え手段により、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させる。したがって、ソフト障害、ハード障害に対し、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化することが可能となり、また、サービスの中断時間を短縮することが可能となる。
【００２８】
【発明の実施の形態】
以下、図面を用いて本発明の実施の形態を説明する。
Ａ．ドメインおよびサーバ構成
本実施形態では、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化するドメイン分割再開方式として、以下の機能により影響範囲の局在化を図る。論理的なシステムとしてドメインを定義し、Ｘ番目の運用ドメインを構成するサーバ数を運用数Ｍａ（Ｘ）とし、Ｘ番目の待機ドメインを構成するサーバ数を待機数Ｍｗ（Ｘ）とする。１つのサーバシステムにおいて必要な運用ドメインをＫ（≧１）個、待機ドメインをＬ（≧０）個とする。待機ドメインＬが０個の場合、ハード障害時、他の正常な運用ドメインに縮退する構成とする。１つのシステムに必要な運用サーバ数Ｎａは数式１、待機サーバ数Ｎｗは数式２によって表わされる。
【００２９】
【数１】
【００３０】
【数２】
【００３１】
なお、ハード障害等により、ドメインを切替えた場合、負荷が偏ってしまう可能性があるため、システム構築において、同一性能のサーバを用い、各ドメインを構成するサーバ数を同数とすることが好ましい。
【００３２】
図１は、待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成におけるＡＰＬプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。なお、共用プロセスの停止は、ドメインの停止となるため、ドメイン毎に同一サーバを用いることが好ましい。ドメイン３０１のサーバ３０５、ドメイン３０２のサーバ３０８の各々に共用プロセスＥ１，Ｅ２を配置し、ドメイン内のプロセスの情報を管理する。
【００３３】
サーバシステムにサービスＡ〜Ｄの４つのサービスがある場合、それぞれのサービスを２個のドメイン３０１，３０２において負荷分散により起動する。ドメイン３０１のサーバ３０３にサービスＡのＡＰＬプロセスＡ１，Ａ２を、サーバ３０４にサービスＢのＡＰＬプロセスＢ１，Ｂ２を起動し、ドメイン３０２のサーバ３０６にサービスＣのＡＰＬプロセスＣ１，Ｃ２を、サーバ３０７にサービスＤのＡＰＬプロセスＤ１，Ｄ２を起動する。この場合、待機サーバが無いため、運用サーバの縮退により、サービスの救済を行う。
【００３４】
図２は、待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成におけるＡＰＬプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。運用ドメインには、待機ドメインが無い場合と同様に、ＡＰＬプロセスを負荷分散起動する。障害時の救済先として待機系のドメイン４０１であるサーバ４０２〜４０４を追加する。
【００３５】
本システムは、ソフト障害、もしくはハード障害を検出する故障部位特定機能と、該故障部位特定機能により特定された要因として、ソフト障害の場合に、関連するプロセスを再起動する再開機能と、ハード障害の場合に、故障したサーバ上のプロセスを他の正常な汎用サーバに再起動するサーバ切替え機能と、ドメインＡＰＬ再開やサーバ閉塞／閉塞解除によって、運用ＡＰＬプロセスが起動するサーバが偏った場合には、再度運転状態へ戻す状態復帰機能を具備する。
【００３６】
障害が発生した場合、故障部位特定機能により、ソフト障害、もしくはハード障害に分類する。ソフト障害の場合には、そのソフト障害が発生したプロセスの種別に基づいて再開フェーズ（復旧手順）を決定し、決定した再開フェーズに従って再開機能により、関連するプロセスのメモリを初期化し、同プロセスを再起動して再開する。ハード障害の場合には、障害が生じたサーバ上で共用プロセスが起動されていなければ、サーバ切替え機能により、故障したサーバ上のプロセスを他の正常な汎用サーバ上で再起動する一方、共用プロセスが起動されていた場合には、ソフト障害と同様に、障害を起こしたプロセス種別から再開範囲を決定し、その範囲内のプロセスを再開する。また、ドメインＡＰＬ再開やサーバ閉塞／閉塞解除によって、運用ＡＰＬプロセスが起動するサーバが偏った場合には、状態復帰機能により再度運転状態へ戻す。
【００３７】
本実施形態では、上記故障部位特定機能、再開機能、サーバ切替え機能、状態復帰機能を、図１または図２に示す構成において、各ドメインの共用プロセスＥ１，Ｅ２に設けるようにしているが、これに限定されることなく、これら機能（各機能の一部を含む）をＡＰＬプロセスに分散するようにしてもよい。
【００３８】
また、上記故障部位特定機能、再開機能、サーバ切替え機能、状態復帰機能は、図示しない記憶部に記憶されたプログラムを実行することで実現するようになっている。記憶部は、フレキシブルディスク、ハードディスク装置や光磁気ディスク装置、フラッシュメモリ等の不揮発性メモリやＲＡＭ（Random Access Memory）のような揮発性のメモリ、あるいはこれらの組み合わせにより構成されるものとする。また、上記記憶部とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含む。
【００３９】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワークや電話回線等の通信回線のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、上述した処理の一部を実現するためのものであってもよい。さらに、上述した処理をサーバに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【００４０】
Ｂ．実施形態の動作
次に、本実施形態の動作について詳細に説明する。
ここで、図３は、故障部位特定機能によりソフト障害、またはハード障害を特定した後における動作を説明するフローチャートである。正常運転中のシステム状態を常時監視し、異常が発生した場合、ソフト障害、もしくはハード障害の特定を行う（ステップＳ５０１）。ソフト障害と判定した場合には、障害を起こしたプロセス種別から再開範囲を決定し、その範囲内のプロセスを再開する（ステップＳ５０２）。そして、再開したプロセスが正常状態に復旧すると（ステップＳ５０３）、再び、システム状態の常時監視を行う（ステップＳ５０１）。
【００４１】
また、ハード障害と判定した場合には、故障したサーバ上で共用プロセスが起動されていたか否かを判断する（ステップＳ５０４）。そして、共用プロセスが起動されていない場合、すなわちＡＰＬプロセスのみが起動されていた場合には、故障したサーバ上のプロセスの救済を行うため、故障したハード上のプロセスの起動先サーバを決定後、当該起動先サーバへプロセスの切替えを実施する（ステップＳ５０５）。正常にプロセスの切替えが完了し、システムが正常状態に復旧すると（ステップＳ５０６）、再び、システム状態の常時監視を行う（ステップＳ５０１）。
【００４２】
一方、故障したサーバ上で共用プロセスが起動されていた場合には、ソフト障害と同様に、障害を起こしたプロセス種別から再開範囲を決定し、その範囲内のプロセスを再開する（ステップＳ５０７）。そして、再開したプロセスが正常状態に復旧すると（ステップＳ５０８）、再び、システム状態の常時監視を行う（ステップＳ５０１）。
【００４３】
次に、図４は、ソフト障害が発生したプロセス種別とそれに対応した再開種別とを示す概念図である。プロセス種別としてＡＰＬプロセス、共用プロセスＰ１、共用プロセスＰ２（共用プロセスを２つに分類）の３つに分類する。
【００４４】
ＡＰＬプロセスがソフト障害の場合には、個別再開を実施する。すなわち、個別再開と当該プロセスのみの再開とによりプロセスを復旧する。この場合、個別再開実施中、当該プロセスが関係するサービスが停止するのみで、プロセス復旧後、再度サービスを開始することが可能となる。図１または図２に示すＡＰＬプロセスＡ１，Ａ２、Ｂ１，Ｂ２、Ｃ１，Ｃ２、Ｄ１，Ｄ２のソフト障害は全て個別再開により復旧可能である。
【００４５】
共用プロセスがソフト障害の場合には、再開範囲をドメイン内とする。共用プロセスは、分散サーバ上のプロセス間の情報を管理するため、管理下のプロセスと共用プロセス間の情報の一貫性が崩れる可能性がある。そのため、共用プロセスを利用するドメイン内の全プロセスの再開が必要となる。そこで、共用プロセスの種別により、同時に再開させるプロセスの種別範囲としてドメイン全再開とドメインＡＰＬ再開との２種類に分類する。
【００４６】
メモリの受け渡し等によりＯＳのカーネルに関連のあるプロセスやＯＳに付随するデーモンプロセスなどの共用プロセスＰ１の場合には、ドメイン内のＯＳから全て（共用プロセスＰ１，Ｐ２とＡＰＬプロセスを含む）再開するドメイン全再開を行う。一方、ＯＳとの関連のない共用プロセスＰ２の場合には、ドメイン内の全てのＡＰＬプロセスと共用プロセスＰ２を再開するドメインＡＰＬ再開を行う。例えば、図１に示す共用プロセスＥ１を共用プロセスＰ１、共用プロセスＥ２を共用プロセスＰ２とした場合、共用プロセスＥ１のソフト障害に対しては、ドメイン全再開を実施し、共用プロセスＥ２のソフト障害に対しては、ドメインＡＰＬ再開を実施する。
【００４７】
そして、適用した再開フェーズではシステムが正常に復旧しない場合には、適用した再開フェーズの範囲ではないプロセスにおいてプロセス間の矛盾が発生していると判断して、上位の再開フェーズにエスカレーションする。システム全体の全再開は、ドメイン全再開からのエスカレーションに限られるため、システム全体のサービス停止になる確率が低いと言える。
【００４８】
ここで、図５は、再開フェーズの発生・復旧と再開エスカレーションとの方向を示す概念図である。正常状態７０１において、ＡＰＬプロセス７０６、共用プロセス７０７、共用プロセス７０８にソフト障害が発生した場合には、障害時の状態変化方向である個別再開７０２、ドメインＡＰＬ再開７０３、ドメイン全再開７０４に状態変化を実施し、復旧すれば正常状態７０１に戻る。そして、当該の再開が失敗した場合には、個別再開７０２、ドメインＡＰＬ再開７０３、ドメイン全再開７０４、全再開７０５の順にエスカレーションを実施する。
【００４９】
ドメインＡＰＬ再開やドメイン全再開は、システムに起動するプロセス数やハード／ＯＳ固有の起動時間によって起動時間に差異が生じる。そこで、プロセスの実行環境が整っている正常な他のサーバにおいて、故障したプロセスを救済する。プロセスを正常なサーバによって救済するドメイン間サービス救済方式として、以下の機能によりサービスの救済の高速化を図る。
【００５０】
ここで、図６は、ＡＰＬプロセスを起動してサービスを提供可能になるまでの起動処理を示す概念図である。ＡＰＬプロセスの起動処理により、運用状態８０１と待機状態８０２との２種類の状態を持たせる。運用状態のＡＰＬプロセス（運用ＡＰＬプロセス）では、メモリの獲得８０３、初期設定８０４を実施し、サービスを提供可能となる。一方、待機状態のＡＰＬプロセス（待機ＡＰＬプロセス）では、メモリの獲得８０３のみを行った状態とする。運用ＡＰＬプロセスのソフト障害時には、待機ＡＰＬプロセスに対して初期設定８０４のみを実施することで、運用・待機の切替えが可能となる。すなわち、迅速に運用・待機を切替えることができる。１つのプロセスを起動する際、運用プロセスと待機プロセスとを常に一組となるように異なるドメインに起動する。
【００５１】
ここで、図７は、図１に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成における運用プロセスと待機プロセスとの起動状態を示すブロック図である。ドメイン３０１のサーバ３０２にサービスＡ（運用）の運用ＡＰＬプロセスＡ１，Ａ２、サーバ３０３にサービスＢ（運用）の運用ＡＰＬプロセスＢ１，Ｂ２を分散起動する。これに対して、ドメイン３０５のサーバ３０６にサービスＡの待機プロセスＡ’１，Ａ’２、サーバ３０７にサービスＢの待機プロセスＢ’１，Ｂ’２を分散起動する。同様にドメイン３０５のサーバ３０６においてサービスＣの運用プロセスＣ１，Ｃ２、サーバ３０７においてサービスＤの運用プロセスＤ１，Ｄ２を起動し、ドメイン３０１のサーバ３０２に待機プロセスＣ’１，Ｃ’２、サーバ３０３に待機プロセスＤ’１，Ｄ’２を分散起動する。共用プロセスＥ１，Ｅ２は、各ドメイン３０１，３０５のサーバ３０４，３０８に起動される。ドメイン３０１の共用プロセスＥ１，Ｅ２は、ドメイン３０１内の全てのＡＰＬプロセスに共用され、他のドメインのＡＰＬプロセスには共用されない。
【００５２】
次に、図８は、図７に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成においてドメイン３０５のドメインＡＰＬ再開を実施した際のシステムの状態変化を示す遷移図である。運転状態（状態１００１：図５の正常状態に相当）において、ドメイン３０５のドメインＡＰＬ再開を実施した場合、ドメイン再開状態（状態１００２）として、ドメイン３０５側の運用ＡＰＬプロセスＣ１，Ｃ２、Ｄ１，Ｄ２の停止と、ドメイン３０１側の待機ＡＰＬプロセスＣ’１，Ｃ’２、Ｄ’１，Ｄ’２に対する初期設定とを行い、運用ＡＰＬプロセスへの切替えを実施する。ドメイン３０５からドメイン３０１へ運用ＡＰＬを切替える時間がサービス停止期間となる。ドメインＡＰＬ再開の場合、サービスの切替え時に共用プロセスＰ２（Ｅ２）の再開を実施する。
【００５３】
ドメイン全再開の場合、サービスの切替え時にＯＳを含めた共用プロセスＰ１（Ｅ１）、共用プロセスＰ２（Ｅ２）の再開を実施する。ドメイン３０５の復旧状態（状態１００３：図５の正常状態に相当）として、再開を実施したドメイン３０５において、ドメイン３０１の運用ＡＰＬプロセスＡ１，Ａ２、Ｂ１，Ｂ２、Ｃ１，Ｃ２、Ｄ１，Ｄ２に対する待機ＡＰＬプロセスＡ’１，Ａ’２、Ｂ’１，Ｂ’２、Ｃ’１，Ｃ’２、Ｄ’１，Ｄ’２を再起動する。ドメイン全再開も同様である。
【００５４】
次に、図９は、図２に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成における運用プロセスと待機プロセスとの起動状態を示すブロック図である。ドメイン３０１のサーバ３０２にサービスＡ（運用）の運用ＡＰＬプロセスＡ１，Ａ２、サーバ３０３にサービスＢ（運用）の運用ＡＰＬプロセスＢ１，Ｂ２、ドメイン３０５のサーバ３０６においてサービスＣの運用プロセスＣ１，Ｃ２、サーバ３０７においてサービスＤの運用プロセスＤ１，Ｄ２を負荷分散起動する。これら全ての運用ＡＰＬプロセスに対して待機ドメイン４０１のサーバ４０２，４０３に待機ＡＰＬプロセスＡ’１，Ａ’２、Ｂ’１，Ｂ’２、Ｃ’１，Ｃ’２、Ｄ’１，Ｄ’２を分散起動する。各ドメイン３０１，３０５，４０１の共用プロセスＥ１，Ｅ２は、ドメイン３０１，３０５，４０１内の全てのＡＰＬプロセスに共用され、他のドメインのＡＰＬプロセスには共用されない。
【００５５】
図１０は、図９に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成において、ドメイン３０５のドメインＡＰＬ再開を実施した際のシステムの状態変化を示す遷移図である。運転状態（状態１２０１：図５の正常状態に相当）において、ドメイン３０５のドメインＡＰＬ再開を実施した場合、ドメイン再開状態（状態１２０２）として、ドメイン３０５側の運用ＡＰＬプロセスＣ１，Ｃ２、Ｄ１，Ｄ２の停止と、ドメイン４０１側の待機ＡＰＬプロセスＣ’１，Ｃ’２、Ｄ’１，Ｄ’２に対する初期設定とを行い、運用ＡＰＬプロセスへの切替えを実施する。ドメイン３０５からドメイン４０１（待機ドメイン）へ運用ＡＰＬを切替える時間がサービス停止期間となる。
【００５６】
ドメインＡＰＬ再開の場合、サービスの切替え時に共用プロセスＰ２の再開を実施する。ドメイン全再開の場合、サービスの切替え時にＯＳを含めた共用プロセスＰ１、共用プロセスＰ２の再開を実施する。ドメイン３０５の復旧状態（状態１２０３：図５の正常状態に相当）として、再開を実施したドメイン３０５において、ドメイン４０１の運用ＡＰＬプロセスＣ１，Ｃ２、Ｄ１，Ｄ２に対する待機ＡＰＬプロセスＣ’１，Ｃ’２、Ｄ’１，Ｄ’２を再起動する。ドメイン全再開も同様である。
【００５７】
次に、図１１は、図７に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成においてドメイン３０１側のサーバ３０３を閉塞（故障／保守）した際のシステム状態変化を示すブロック図である。運転状態（状態１３０１：図５の正常状態に相当）において、ドメイン３０１側のサーバ３０３を閉塞（故障／保守）した場合、ドメイン３０１のサーバ３０３の閉塞状態（状態１３０２）として、ドメイン３０１のサーバ３０３上の運用ＡＰＬプロセスＢ１，Ｂ２と待機プロセスＤ’１，Ｄ’２との停止と、ドメイン３０５のサーバ３０７の待機ＡＰＬプロセスＢ’１，Ｂ’２に対する初期設定とを行い、運用ＡＰＬプロセスへの切替えを実施する。このとき、ドメイン３０１からドメイン３０５へ運用ＡＰＬプロセスを切替える時間がサービス停止期間となる。必ずドメイン間で運用系と待機系とが一組となるようにするため、ドメイン３０１のサーバ３０３において停止した待機ＡＰＬプロセスＤ’１，Ｄ’２をドメイン３０１のサーバ３０２において待機ＡＰＬプロセスとして起動する。
【００５８】
次に、図１２は、図９に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成においてドメイン３０１側のサーバ３０３を閉塞（故障／保守）した際のシステム状態変化を示す遷移図である。運転状態（状態１４０１：図５の正常状態に相当）において、ドメイン３０１側のサーバ３０３を閉塞（故障／保守）した場合、ドメイン３０１のサーバ３０３閉塞状態（状態１４０２）として、ドメイン３０１のサーバ３０３上の運用ＡＰＬプロセスＢ１，Ｂ２の停止と、ドメイン４０１のサーバ４０３の待機ＡＰＬプロセスＢ’１，Ｂ’２に対する初期設定とを行い、運用ＡＰＬプロセスへの切替えを実施する。ドメイン３０１からドメイン４０１へ運用ＡＰＬプロセスを切替える時間がサービス停止期間となる。必ずドメイン間で運用系と待機系が一組となるようするため、ドメイン３０１のサーバ３０３において停止した待機ＡＰＬプロセスＤ’１，Ｄ’２をドメイン３０１のサーバ３０２において待機ＡＰＬプロセスとして起動する。
【００５９】
また、本実施形態においては、ドメインＡＰＬ再開やサーバ閉塞／閉塞解除によって、運用ＡＰＬプロセスが起動するサーバに偏りが生じた場合には、前述したように、再度、運転状態へ戻す状態復帰機能により、図８、図１０においては、ドメイン３０５を復旧状態（状態１００３、状態１２０３：図５の正常状態に相当）から運転状態（状態１００１、状態１２０１：図５の正常状態に相当）へ復旧させる。同様に図１１、図１２においては、ドメイン３０１のサーバ３０３の閉塞状態（状態１３０２、状態１４０２）から運転状態（状態１３０１、状態１４０１：図５の正常状態に相当）へ復旧させる。
【００６０】
なお、上述した実施形態においては、２種類の共有プロセスＥ１，Ｅ２のみを示しているが、これに限定されることなく、３つ以上であってもよい。また、共有プロセスが起動されているサーバ上でＡＰＬプロセスが起動されていてもよい。
【００６１】
【発明の効果】
以上説明したように、本発明によれば、前記複数のサーバをＮ台としたとき、Ｌ（＞１）個のサーバ群からなるドメインに分割し、システム障害が発生した場合、故障部位特定手段により、その障害を検出して故障部位を特定し、ソフト障害と特定された場合には、再開手段により、そのソフト障害が発生したプロセスの種別に基づいて復旧手順を決定し、再開範囲を前記分割されたドメイン単位に限定して、決定した復旧手順に従って前記プロセスを再起動させ、一方、ハード障害と特定された場合には、サーバ切替え手段により、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるようにしたので、ソフト障害、ハード障害に対し、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化することができ、また、サービスの中断時間を短縮することができるという利点が得られる。
【図面の簡単な説明】
【図１】 本発明の実施形態による、待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成におけるＡＰＬプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。
【図２】 待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成におけるＡＰＬプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。
【図３】 故障部位特定機能によりソフト障害、またはハード障害を特定した後における動作を説明するフローチャートである。
【図４】 ソフト障害が発生したプロセス種別とそれに対応した再開種別とを示す概念図である。
【図５】 再開フェーズの発生・復旧と再開エスカレーションとの方向を示す概念図である。
【図６】 ＡＰＬプロセスを起動してサービスを提供可能になるまでの起動処理を示す概念図である。
【図７】 図１に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成における運用プロセスと待機プロセスの起動状態とを示すブロック図である。
【図８】 図７に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成においてドメイン３０５のドメインＡＰＬ再開を実施した際のシステムの状態変化を示す遷移図である。
【図９】 図２に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成における運用プロセスと待機プロセスとの起動状態を示すブロック図である。
【図１０】 図９に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成において、ドメイン３０５のドメインＡＰＬ再開を実施した際のシステムの状態変化を示す遷移図である。
【図１１】 図７に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成においてドメイン３０１側のサーバ３０３を閉塞（故障／保守）した際のシステム状態変化を示すブロック図である。
【図１２】 図９に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成においてドメイン３０１側のサーバ３０３を閉塞（故障／保守）した際のシステム状態変化を示す遷移図である。
【図１３】 従来からのサーバクライアント型のシステム構成を示すブロック図である。
【図１４】 従来技術による共用プロセスとＡＰＬプロセスの関係を示す概念図である。
【符号の説明】
３０１，３０５ 運用ドメイン
４０１ 待機ドメイン
３０２ サーバ
３０３ サーバ
３０４ サーバ（故障部位特定手段、再開手段、サーバ切替え手段、状態復帰手段）
３０６ サーバ
３０７ サーバ
３０８ サーバ（故障部位特定手段、再開手段、サーバ切替え手段、状態復帰手段）
４０２ サーバ
４０３ サーバ
４０４ サーバ（故障部位特定手段、再開手段、サーバ切替え手段、状態復帰手段）
【発明の属する技術分野】
本発明は、複数の汎用サーバにより構成された分散構成のサーバシステムにおいて、ソフト障害、もしくはハード障害を検出し、関連するプロセスの再起動、プロセスの正常な汎用サーバでの再起動、再度運転状態への復帰を行う分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体に関する。
【０００２】
【従来の技術】
図１３は、従来からの高信頼性を実現するサーバクライアント型のシステム構成を示すブロック図である。センタ装置１０１は、複数のクライアント１０７〜１０９とＤＣＮ１０６を介して接続可能であり、ＬＡＮ１０５に接続した複数のサーバ１０２〜１０４により構成されている。サーバ上に動作する複数のプロセス１１１〜１１３の連携によりサービス１１０を提供する。このような構成において、サービスの中断となる要因は、ソフト障害とハード障害とである。
【０００３】
ソフト障害としては、サーバ上で動作するプロセスのメモリ操作違反によるプロセスの異常停止が挙げられる。ソフト障害を救済する方法として、ソフト障害を検出した場合、当該プロセスを初期化再起動し、サービスを継続する方法が取られる。しかしながら、プロセスの特性により、複数のサービスに共用されるプロセスの場合、障害が発生したプロセスのみの救済では、システムとして安定したサービスの再開が行える保証が無く、まとまった単位でプロセスを初期化再起動しサービスを救済する方法が必要である。
【０００４】
また、ハード障害としては、構成するサーバのＣＰＵやボードの故障によるプロセスの異常停止が挙げられる。ハード障害を救済する方法は、運用サーバ上のプロセスを救済するための待機サーバを用意する方法により３つに分類される。Ｎ台の運用サーバに対して同じ数の待機サーバを用意する２Ｎ台構成、Ｎ台の運用サーバに対して１台の待機サーバを用意するＮ＋１台構成、Ｎ台の運用サーバに対して待機サーバを用意せず、正常な運用サーバにおいて故障したサーバ上のプロセスを救済するＮ台構成がある。何れの構成においても、サーバが故障した場合、他のサーバにおいて、故障したサーバ上のプロセスを再起動し、サービスを継続する方法が取られる。加えて、ハード障害の場合、当該ハードで動作するプロセスのソフト障害と考えられるため、ソフト障害の救済方法も適用する必要がある。
【０００５】
【発明が解決しようとする課題】
ところで、上述した従来技術では、ソフト障害の場合、故障した当該プロセスの特性を分類し、プロセス種別にあわせた救済方法を実施し、ハード障害の場合、当該サーバ上で動作する全てのプロセスを他のサーバで救済する際、障害サーバ上で動作していたプロセスにあわせた救済方法も実施する必要がある。
【０００６】
分散サーバ構成において動作するプロセスは、分散構成を意識しないで動作するＡＰＬプロセスと、分散構成をＡＰＬプロセスに意識させないための機能を持ち、複数のＡＰＬプロセスの情報を管理する共用プロセスとに分類できる。図１４に共用プロセスとＡＰＬプロセスとの関係を示す。
【０００７】
サービスＡは、ＡＰＬプロセスＡ１〜Ａ４の連携により提供される。共用プロセスＥ１、Ｅ２は、サービスＡの各プロセスの連携状態を管理する。同様にサービスＢも、ＡＰＬプロセスＢ１〜Ｂ４の連携により提供される。共用プロセスＥ１、Ｅ２は、サービスＢの各プロセスの連携状態も管理する。
【０００８】
いずれかのＡＰＬプロセスが停止した場合には、当該ＡＰＬプロセスを再起動するのみで、サービスの再開が可能となる。これに対して、いずれかの共用プロセスが停止した場合には、分散サーバ上のプロセス間の情報を管理するため、管理下のプロセスと共用プロセス間の情報の一貫性が崩れる可能性がある。
【０００９】
そのため、共用プロセスの再起動のみでは、システムの安定的なサービスの復旧ができないという問題がある。そこで、この問題を解決する方法として、早急な回復手段である共用プロセスの管理下のプロセス全てを再開する手法を用いることが考えられる。しかしながら、全てのプロセスを再開することにより、再開完了までの期間、全てのサービスが停止してしまうという問題がある。
【００１０】
また、交換機のように、主メモリの同期運転を行っていないサーバを活用する場合、ＯＳの起動時間や再開するプロセスの数により再開時間が余儀なく長期化するという問題がある。
【００１１】
この発明は上述した事情に鑑みてなされたもので、ソフト障害、ハード障害に対し、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化することができ、また、サービスの中断時間を短縮することができる分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上述した問題点を解決するために、請求項１記載の発明では、システムを複数のサーバにより構成する分散サーバシステムにおいて、システム障害が発生した場合、その障害を検出し、故障部位を特定する故障部位特定手段と、前記故障部位特定手段により、ソフト障害と特定された場合、そのソフト障害が発生したプロセスの種別に基づいて復旧手順を決定し、決定した復旧手順に従って前記プロセスを再起動させる再開手段と、前記故障部位特定手段により、ハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動するサーバ切替え手段とを具備し、前記複数のサーバは、該複数のサーバをＮ台としたとき、Ｌ（＞１）個のサーバ群からなるドメインに分割され、前記再開手段は、前記プロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定することを特徴とし、前記再開手段は、ソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行い、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させることを特徴とし、前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとは、それぞれ異なったドメイン内に起動され、前記再開手段は、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させることを特徴とする。
【００１５】
また、請求項２記載の発明では、請求項１に記載の分散サーバシステムにおいて、ソフト障害またはハード障害の発生後、前記運用状態プロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻す状態復帰手段を具備することを特徴とする。
【００１６】
また、上述した問題点を解決するために、請求項３記載の発明では、複数のサーバにより構成される分散サーバシステム上で生じた障害を復旧させる障害復旧方法において、前記複数のサーバをＮ台としたとき、該Ｎ台のサーバをＬ（＞１）個のサーバ群からなるドメインに分割し、システム障害が発生した場合、当該システム障害に対応するプロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定することを特徴とし、システム障害が発生した場合、該システム障害を検出して故障部位を特定し、故障部位がソフト障害であった場合に、このソフト障害の発生したプロセスの種別がが、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記分割されたドメイン単位で前記プロセスを再起動させ、故障部位がハード障害であった場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させ、ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させることを特徴とし、前記プロセスを、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成し、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動し、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させることを特徴とする。
【００２０】
また、請求項４記載の発明では、請求項３に記載の障害復旧方法において、ソフト障害またはハード障害の発生後、前記運用状態プロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻すことを特徴とする。
【００２１】
また、上述した問題点を解決するために、請求項５記載の発明では、分散サーバシステムを構成する複数のサーバをＮ台としたとき、該Ｎ台のサーバをＬ（＞１）個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理するステップと、前記分散サーバシステム上でシステム障害が発生した場合、前記分割されたドメイン単位に再開範囲を限定し、前記特定された故障部位に基づいて、当該システム障害が生じたプロセスを再起動させるステップと、システム障害が発生した場合、その障害を検出して故障部位を特定するステップと、故障部位がソフト障害と特定した場合に、そのソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記プロセスを再起動させるステップと、故障部位がハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるステップと、ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させるステップと、前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動するステップと、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させるステップとをコンピュータに実行させることを特徴とする。
【００２４】
また、請求項６記載の発明では、請求項５に記載の障害復旧プログラムにおいて、ソフト障害またはハード障害の発生後、運用状態のプロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻すステップをコンピュータに実行させることを特徴とする。
【００２５】
また、上述した問題点を解決するために、請求項７記載の発明では、分散サーバシステムを構成する複数のサーバをＮ台としたとき、該Ｎ台のサーバをＬ（＞１）個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理するステップと、前記分散サーバシステム上でシステム障害が発生した場合、前記分割されたドメイン単位に再開範囲を限定し、前記特定された故障部位に基づいて、当該システム障害が生じたプロセスを再起動させるステップと、システム障害が発生した場合、その障害を検出して故障部位を特定するステップと、故障部位がソフト障害と特定した場合に、そのソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記プロセスを再起動させるステップと、故障部位がハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるステップと、ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させるステップと、前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動するステップと、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させるステップとをコンピュータに実行させるための障害復旧プログラムを記録したことを特徴とする。
【００２７】
この発明では、前記複数のサーバをＮ台としたとき、Ｌ（＞１）個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理する。システム障害が発生した場合、故障部位特定手段により、その障害を検出して故障部位を特定し、ソフト障害と特定された場合には、再開手段により、そのソフト障害が発生したプロセスの種別に基づいて復旧手順を決定し、決定した復旧手順に従って前記プロセスを再起動させる。このとき、前記再開手段は、前記プロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定する。一方、ハード障害と特定された場合、サーバ切替え手段により、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させる。したがって、ソフト障害、ハード障害に対し、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化することが可能となり、また、サービスの中断時間を短縮することが可能となる。
【００２８】
【発明の実施の形態】
以下、図面を用いて本発明の実施の形態を説明する。
Ａ．ドメインおよびサーバ構成
本実施形態では、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化するドメイン分割再開方式として、以下の機能により影響範囲の局在化を図る。論理的なシステムとしてドメインを定義し、Ｘ番目の運用ドメインを構成するサーバ数を運用数Ｍａ（Ｘ）とし、Ｘ番目の待機ドメインを構成するサーバ数を待機数Ｍｗ（Ｘ）とする。１つのサーバシステムにおいて必要な運用ドメインをＫ（≧１）個、待機ドメインをＬ（≧０）個とする。待機ドメインＬが０個の場合、ハード障害時、他の正常な運用ドメインに縮退する構成とする。１つのシステムに必要な運用サーバ数Ｎａは数式１、待機サーバ数Ｎｗは数式２によって表わされる。
【００２９】
【数１】
【数２】
なお、ハード障害等により、ドメインを切替えた場合、負荷が偏ってしまう可能性があるため、システム構築において、同一性能のサーバを用い、各ドメインを構成するサーバ数を同数とすることが好ましい。
【００３２】
図１は、待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成におけるＡＰＬプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。なお、共用プロセスの停止は、ドメインの停止となるため、ドメイン毎に同一サーバを用いることが好ましい。ドメイン３０１のサーバ３０５、ドメイン３０２のサーバ３０８の各々に共用プロセスＥ１，Ｅ２を配置し、ドメイン内のプロセスの情報を管理する。
【００３３】
サーバシステムにサービスＡ〜Ｄの４つのサービスがある場合、それぞれのサービスを２個のドメイン３０１，３０２において負荷分散により起動する。ドメイン３０１のサーバ３０３にサービスＡのＡＰＬプロセスＡ１，Ａ２を、サーバ３０４にサービスＢのＡＰＬプロセスＢ１，Ｂ２を起動し、ドメイン３０２のサーバ３０６にサービスＣのＡＰＬプロセスＣ１，Ｃ２を、サーバ３０７にサービスＤのＡＰＬプロセスＤ１，Ｄ２を起動する。この場合、待機サーバが無いため、運用サーバの縮退により、サービスの救済を行う。
【００３４】
図２は、待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成におけるＡＰＬプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。運用ドメインには、待機ドメインが無い場合と同様に、ＡＰＬプロセスを負荷分散起動する。障害時の救済先として待機系のドメイン４０１であるサーバ４０２〜４０４を追加する。
【００３５】
本システムは、ソフト障害、もしくはハード障害を検出する故障部位特定機能と、該故障部位特定機能により特定された要因として、ソフト障害の場合に、関連するプロセスを再起動する再開機能と、ハード障害の場合に、故障したサーバ上のプロセスを他の正常な汎用サーバに再起動するサーバ切替え機能と、ドメインＡＰＬ再開やサーバ閉塞／閉塞解除によって、運用ＡＰＬプロセスが起動するサーバが偏った場合には、再度運転状態へ戻す状態復帰機能を具備する。
【００３６】
障害が発生した場合、故障部位特定機能により、ソフト障害、もしくはハード障害に分類する。ソフト障害の場合には、そのソフト障害が発生したプロセスの種別に基づいて再開フェーズ（復旧手順）を決定し、決定した再開フェーズに従って再開機能により、関連するプロセスのメモリを初期化し、同プロセスを再起動して再開する。ハード障害の場合には、障害が生じたサーバ上で共用プロセスが起動されていなければ、サーバ切替え機能により、故障したサーバ上のプロセスを他の正常な汎用サーバ上で再起動する一方、共用プロセスが起動されていた場合には、ソフト障害と同様に、障害を起こしたプロセス種別から再開範囲を決定し、その範囲内のプロセスを再開する。また、ドメインＡＰＬ再開やサーバ閉塞／閉塞解除によって、運用ＡＰＬプロセスが起動するサーバが偏った場合には、状態復帰機能により再度運転状態へ戻す。
【００３７】
本実施形態では、上記故障部位特定機能、再開機能、サーバ切替え機能、状態復帰機能を、図１または図２に示す構成において、各ドメインの共用プロセスＥ１，Ｅ２に設けるようにしているが、これに限定されることなく、これら機能（各機能の一部を含む）をＡＰＬプロセスに分散するようにしてもよい。
【００３８】
また、上記故障部位特定機能、再開機能、サーバ切替え機能、状態復帰機能は、図示しない記憶部に記憶されたプログラムを実行することで実現するようになっている。記憶部は、フレキシブルディスク、ハードディスク装置や光磁気ディスク装置、フラッシュメモリ等の不揮発性メモリやＲＡＭ（Random Access Memory）のような揮発性のメモリ、あるいはこれらの組み合わせにより構成されるものとする。また、上記記憶部とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含む。
【００３９】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワークや電話回線等の通信回線のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、上述した処理の一部を実現するためのものであってもよい。さらに、上述した処理をサーバに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【００４０】
Ｂ．実施形態の動作
次に、本実施形態の動作について詳細に説明する。
ここで、図３は、故障部位特定機能によりソフト障害、またはハード障害を特定した後における動作を説明するフローチャートである。正常運転中のシステム状態を常時監視し、異常が発生した場合、ソフト障害、もしくはハード障害の特定を行う（ステップＳ５０１）。ソフト障害と判定した場合には、障害を起こしたプロセス種別から再開範囲を決定し、その範囲内のプロセスを再開する（ステップＳ５０２）。そして、再開したプロセスが正常状態に復旧すると（ステップＳ５０３）、再び、システム状態の常時監視を行う（ステップＳ５０１）。
【００４１】
また、ハード障害と判定した場合には、故障したサーバ上で共用プロセスが起動されていたか否かを判断する（ステップＳ５０４）。そして、共用プロセスが起動されていない場合、すなわちＡＰＬプロセスのみが起動されていた場合には、故障したサーバ上のプロセスの救済を行うため、故障したハード上のプロセスの起動先サーバを決定後、当該起動先サーバへプロセスの切替えを実施する（ステップＳ５０５）。正常にプロセスの切替えが完了し、システムが正常状態に復旧すると（ステップＳ５０６）、再び、システム状態の常時監視を行う（ステップＳ５０１）。
【００４２】
一方、故障したサーバ上で共用プロセスが起動されていた場合には、ソフト障害と同様に、障害を起こしたプロセス種別から再開範囲を決定し、その範囲内のプロセスを再開する（ステップＳ５０７）。そして、再開したプロセスが正常状態に復旧すると（ステップＳ５０８）、再び、システム状態の常時監視を行う（ステップＳ５０１）。
【００４３】
次に、図４は、ソフト障害が発生したプロセス種別とそれに対応した再開種別とを示す概念図である。プロセス種別としてＡＰＬプロセス、共用プロセスＰ１、共用プロセスＰ２（共用プロセスを２つに分類）の３つに分類する。
【００４４】
ＡＰＬプロセスがソフト障害の場合には、個別再開を実施する。すなわち、個別再開と当該プロセスのみの再開とによりプロセスを復旧する。この場合、個別再開実施中、当該プロセスが関係するサービスが停止するのみで、プロセス復旧後、再度サービスを開始することが可能となる。図１または図２に示すＡＰＬプロセスＡ１，Ａ２、Ｂ１，Ｂ２、Ｃ１，Ｃ２、Ｄ１，Ｄ２のソフト障害は全て個別再開により復旧可能である。
【００４５】
共用プロセスがソフト障害の場合には、再開範囲をドメイン内とする。共用プロセスは、分散サーバ上のプロセス間の情報を管理するため、管理下のプロセスと共用プロセス間の情報の一貫性が崩れる可能性がある。そのため、共用プロセスを利用するドメイン内の全プロセスの再開が必要となる。そこで、共用プロセスの種別により、同時に再開させるプロセスの種別範囲としてドメイン全再開とドメインＡＰＬ再開との２種類に分類する。
【００４６】
メモリの受け渡し等によりＯＳのカーネルに関連のあるプロセスやＯＳに付随するデーモンプロセスなどの共用プロセスＰ１の場合には、ドメイン内のＯＳから全て（共用プロセスＰ１，Ｐ２とＡＰＬプロセスを含む）再開するドメイン全再開を行う。一方、ＯＳとの関連のない共用プロセスＰ２の場合には、ドメイン内の全てのＡＰＬプロセスと共用プロセスＰ２を再開するドメインＡＰＬ再開を行う。例えば、図１に示す共用プロセスＥ１を共用プロセスＰ１、共用プロセスＥ２を共用プロセスＰ２とした場合、共用プロセスＥ１のソフト障害に対しては、ドメイン全再開を実施し、共用プロセスＥ２のソフト障害に対しては、ドメインＡＰＬ再開を実施する。
【００４７】
そして、適用した再開フェーズではシステムが正常に復旧しない場合には、適用した再開フェーズの範囲ではないプロセスにおいてプロセス間の矛盾が発生していると判断して、上位の再開フェーズにエスカレーションする。システム全体の全再開は、ドメイン全再開からのエスカレーションに限られるため、システム全体のサービス停止になる確率が低いと言える。
【００４８】
ここで、図５は、再開フェーズの発生・復旧と再開エスカレーションとの方向を示す概念図である。正常状態７０１において、ＡＰＬプロセス７０６、共用プロセス７０７、共用プロセス７０８にソフト障害が発生した場合には、障害時の状態変化方向である個別再開７０２、ドメインＡＰＬ再開７０３、ドメイン全再開７０４に状態変化を実施し、復旧すれば正常状態７０１に戻る。そして、当該の再開が失敗した場合には、個別再開７０２、ドメインＡＰＬ再開７０３、ドメイン全再開７０４、全再開７０５の順にエスカレーションを実施する。
【００４９】
ドメインＡＰＬ再開やドメイン全再開は、システムに起動するプロセス数やハード／ＯＳ固有の起動時間によって起動時間に差異が生じる。そこで、プロセスの実行環境が整っている正常な他のサーバにおいて、故障したプロセスを救済する。プロセスを正常なサーバによって救済するドメイン間サービス救済方式として、以下の機能によりサービスの救済の高速化を図る。
【００５０】
ここで、図６は、ＡＰＬプロセスを起動してサービスを提供可能になるまでの起動処理を示す概念図である。ＡＰＬプロセスの起動処理により、運用状態８０１と待機状態８０２との２種類の状態を持たせる。運用状態のＡＰＬプロセス（運用ＡＰＬプロセス）では、メモリの獲得８０３、初期設定８０４を実施し、サービスを提供可能となる。一方、待機状態のＡＰＬプロセス（待機ＡＰＬプロセス）では、メモリの獲得８０３のみを行った状態とする。運用ＡＰＬプロセスのソフト障害時には、待機ＡＰＬプロセスに対して初期設定８０４のみを実施することで、運用・待機の切替えが可能となる。すなわち、迅速に運用・待機を切替えることができる。１つのプロセスを起動する際、運用プロセスと待機プロセスとを常に一組となるように異なるドメインに起動する。
【００５１】
ここで、図７は、図１に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成における運用プロセスと待機プロセスとの起動状態を示すブロック図である。ドメイン３０１のサーバ３０２にサービスＡ（運用）の運用ＡＰＬプロセスＡ１，Ａ２、サーバ３０３にサービスＢ（運用）の運用ＡＰＬプロセスＢ１，Ｂ２を分散起動する。これに対して、ドメイン３０５のサーバ３０６にサービスＡの待機プロセスＡ’１，Ａ’２、サーバ３０７にサービスＢの待機プロセスＢ’１，Ｂ’２を分散起動する。同様にドメイン３０５のサーバ３０６においてサービスＣの運用プロセスＣ１，Ｃ２、サーバ３０７においてサービスＤの運用プロセスＤ１，Ｄ２を起動し、ドメイン３０１のサーバ３０２に待機プロセスＣ’１，Ｃ’２、サーバ３０３に待機プロセスＤ’１，Ｄ’２を分散起動する。共用プロセスＥ１，Ｅ２は、各ドメイン３０１，３０５のサーバ３０４，３０８に起動される。ドメイン３０１の共用プロセスＥ１，Ｅ２は、ドメイン３０１内の全てのＡＰＬプロセスに共用され、他のドメインのＡＰＬプロセスには共用されない。
【００５２】
次に、図８は、図７に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成においてドメイン３０５のドメインＡＰＬ再開を実施した際のシステムの状態変化を示す遷移図である。運転状態（状態１００１：図５の正常状態に相当）において、ドメイン３０５のドメインＡＰＬ再開を実施した場合、ドメイン再開状態（状態１００２）として、ドメイン３０５側の運用ＡＰＬプロセスＣ１，Ｃ２、Ｄ１，Ｄ２の停止と、ドメイン３０１側の待機ＡＰＬプロセスＣ’１，Ｃ’２、Ｄ’１，Ｄ’２に対する初期設定とを行い、運用ＡＰＬプロセスへの切替えを実施する。ドメイン３０５からドメイン３０１へ運用ＡＰＬを切替える時間がサービス停止期間となる。ドメインＡＰＬ再開の場合、サービスの切替え時に共用プロセスＰ２（Ｅ２）の再開を実施する。
【００５３】
ドメイン全再開の場合、サービスの切替え時にＯＳを含めた共用プロセスＰ１（Ｅ１）、共用プロセスＰ２（Ｅ２）の再開を実施する。ドメイン３０５の復旧状態（状態１００３：図５の正常状態に相当）として、再開を実施したドメイン３０５において、ドメイン３０１の運用ＡＰＬプロセスＡ１，Ａ２、Ｂ１，Ｂ２、Ｃ１，Ｃ２、Ｄ１，Ｄ２に対する待機ＡＰＬプロセスＡ’１，Ａ’２、Ｂ’１，Ｂ’２、Ｃ’１，Ｃ’２、Ｄ’１，Ｄ’２を再起動する。ドメイン全再開も同様である。
【００５４】
次に、図９は、図２に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成における運用プロセスと待機プロセスとの起動状態を示すブロック図である。ドメイン３０１のサーバ３０２にサービスＡ（運用）の運用ＡＰＬプロセスＡ１，Ａ２、サーバ３０３にサービスＢ（運用）の運用ＡＰＬプロセスＢ１，Ｂ２、ドメイン３０５のサーバ３０６においてサービスＣの運用プロセスＣ１，Ｃ２、サーバ３０７においてサービスＤの運用プロセスＤ１，Ｄ２を負荷分散起動する。これら全ての運用ＡＰＬプロセスに対して待機ドメイン４０１のサーバ４０２，４０３に待機ＡＰＬプロセスＡ’１，Ａ’２、Ｂ’１，Ｂ’２、Ｃ’１，Ｃ’２、Ｄ’１，Ｄ’２を分散起動する。各ドメイン３０１，３０５，４０１の共用プロセスＥ１，Ｅ２は、ドメイン３０１，３０５，４０１内の全てのＡＰＬプロセスに共用され、他のドメインのＡＰＬプロセスには共用されない。
【００５５】
図１０は、図９に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成において、ドメイン３０５のドメインＡＰＬ再開を実施した際のシステムの状態変化を示す遷移図である。運転状態（状態１２０１：図５の正常状態に相当）において、ドメイン３０５のドメインＡＰＬ再開を実施した場合、ドメイン再開状態（状態１２０２）として、ドメイン３０５側の運用ＡＰＬプロセスＣ１，Ｃ２、Ｄ１，Ｄ２の停止と、ドメイン４０１側の待機ＡＰＬプロセスＣ’１，Ｃ’２、Ｄ’１，Ｄ’２に対する初期設定とを行い、運用ＡＰＬプロセスへの切替えを実施する。ドメイン３０５からドメイン４０１（待機ドメイン）へ運用ＡＰＬを切替える時間がサービス停止期間となる。
【００５６】
ドメインＡＰＬ再開の場合、サービスの切替え時に共用プロセスＰ２の再開を実施する。ドメイン全再開の場合、サービスの切替え時にＯＳを含めた共用プロセスＰ１、共用プロセスＰ２の再開を実施する。ドメイン３０５の復旧状態（状態１２０３：図５の正常状態に相当）として、再開を実施したドメイン３０５において、ドメイン４０１の運用ＡＰＬプロセスＣ１，Ｃ２、Ｄ１，Ｄ２に対する待機ＡＰＬプロセスＣ’１，Ｃ’２、Ｄ’１，Ｄ’２を再起動する。ドメイン全再開も同様である。
【００５７】
次に、図１１は、図７に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成においてドメイン３０１側のサーバ３０３を閉塞（故障／保守）した際のシステム状態変化を示すブロック図である。運転状態（状態１３０１：図５の正常状態に相当）において、ドメイン３０１側のサーバ３０３を閉塞（故障／保守）した場合、ドメイン３０１のサーバ３０３の閉塞状態（状態１３０２）として、ドメイン３０１のサーバ３０３上の運用ＡＰＬプロセスＢ１，Ｂ２と待機プロセスＤ’１，Ｄ’２との停止と、ドメイン３０５のサーバ３０７の待機ＡＰＬプロセスＢ’１，Ｂ’２に対する初期設定とを行い、運用ＡＰＬプロセスへの切替えを実施する。このとき、ドメイン３０１からドメイン３０５へ運用ＡＰＬプロセスを切替える時間がサービス停止期間となる。必ずドメイン間で運用系と待機系とが一組となるようにするため、ドメイン３０１のサーバ３０３において停止した待機ＡＰＬプロセスＤ’１，Ｄ’２をドメイン３０１のサーバ３０２において待機ＡＰＬプロセスとして起動する。
【００５８】
次に、図１２は、図９に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成においてドメイン３０１側のサーバ３０３を閉塞（故障／保守）した際のシステム状態変化を示す遷移図である。運転状態（状態１４０１：図５の正常状態に相当）において、ドメイン３０１側のサーバ３０３を閉塞（故障／保守）した場合、ドメイン３０１のサーバ３０３閉塞状態（状態１４０２）として、ドメイン３０１のサーバ３０３上の運用ＡＰＬプロセスＢ１，Ｂ２の停止と、ドメイン４０１のサーバ４０３の待機ＡＰＬプロセスＢ’１，Ｂ’２に対する初期設定とを行い、運用ＡＰＬプロセスへの切替えを実施する。ドメイン３０１からドメイン４０１へ運用ＡＰＬプロセスを切替える時間がサービス停止期間となる。必ずドメイン間で運用系と待機系が一組となるようするため、ドメイン３０１のサーバ３０３において停止した待機ＡＰＬプロセスＤ’１，Ｄ’２をドメイン３０１のサーバ３０２において待機ＡＰＬプロセスとして起動する。
【００５９】
また、本実施形態においては、ドメインＡＰＬ再開やサーバ閉塞／閉塞解除によって、運用ＡＰＬプロセスが起動するサーバに偏りが生じた場合には、前述したように、再度、運転状態へ戻す状態復帰機能により、図８、図１０においては、ドメイン３０５を復旧状態（状態１００３、状態１２０３：図５の正常状態に相当）から運転状態（状態１００１、状態１２０１：図５の正常状態に相当）へ復旧させる。同様に図１１、図１２においては、ドメイン３０１のサーバ３０３の閉塞状態（状態１３０２、状態１４０２）から運転状態（状態１３０１、状態１４０１：図５の正常状態に相当）へ復旧させる。
【００６０】
なお、上述した実施形態においては、２種類の共有プロセスＥ１，Ｅ２のみを示しているが、これに限定されることなく、３つ以上であってもよい。また、共有プロセスが起動されているサーバ上でＡＰＬプロセスが起動されていてもよい。
【００６１】
【発明の効果】
以上説明したように、本発明によれば、前記複数のサーバをＮ台としたとき、Ｌ（＞１）個のサーバ群からなるドメインに分割し、システム障害が発生した場合、故障部位特定手段により、その障害を検出して故障部位を特定し、ソフト障害と特定された場合には、再開手段により、そのソフト障害が発生したプロセスの種別に基づいて復旧手順を決定し、再開範囲を前記分割されたドメイン単位に限定して、決定した復旧手順に従って前記プロセスを再起動させ、一方、ハード障害と特定された場合には、サーバ切替え手段により、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるようにしたので、ソフト障害、ハード障害に対し、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化することができ、また、サービスの中断時間を短縮することができるという利点が得られる。
【図面の簡単な説明】
【図１】 本発明の実施形態による、待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成におけるＡＰＬプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。
【図２】 待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成におけるＡＰＬプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。
【図３】 故障部位特定機能によりソフト障害、またはハード障害を特定した後における動作を説明するフローチャートである。
【図４】 ソフト障害が発生したプロセス種別とそれに対応した再開種別とを示す概念図である。
【図５】 再開フェーズの発生・復旧と再開エスカレーションとの方向を示す概念図である。
【図６】 ＡＰＬプロセスを起動してサービスを提供可能になるまでの起動処理を示す概念図である。
【図７】 図１に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成における運用プロセスと待機プロセスの起動状態とを示すブロック図である。
【図８】 図７に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成においてドメイン３０５のドメインＡＰＬ再開を実施した際のシステムの状態変化を示す遷移図である。
【図９】 図２に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成における運用プロセスと待機プロセスとの起動状態を示すブロック図である。
【図１０】 図９に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成において、ドメイン３０５のドメインＡＰＬ再開を実施した際のシステムの状態変化を示す遷移図である。
【図１１】 図７に示す待機ドメイン無し（Ｌ＝０）、運用ドメインが２つ（Ｋ＝２）、各運用ドメインのサーバ数が３つという構成においてドメイン３０１側のサーバ３０３を閉塞（故障／保守）した際のシステム状態変化を示すブロック図である。
【図１２】 図９に示す待機ドメイン有り（Ｌ＝１：１つ）、運用ドメインが２つ（Ｋ＝２）、各運用・待機ドメインのサーバ数が３つという構成においてドメイン３０１側のサーバ３０３を閉塞（故障／保守）した際のシステム状態変化を示す遷移図である。
【図１３】 従来からのサーバクライアント型のシステム構成を示すブロック図である。
【図１４】 従来技術による共用プロセスとＡＰＬプロセスの関係を示す概念図である。
【符号の説明】
３０１，３０５ 運用ドメイン
４０１ 待機ドメイン
３０２ サーバ
３０３ サーバ
３０４ サーバ（故障部位特定手段、再開手段、サーバ切替え手段、状態復帰手段）
３０６ サーバ
３０７ サーバ
３０８ サーバ（故障部位特定手段、再開手段、サーバ切替え手段、状態復帰手段）
４０２ サーバ
４０３ サーバ
４０４ サーバ（故障部位特定手段、再開手段、サーバ切替え手段、状態復帰手段）
Claims (7)
- システムを複数のサーバにより構成する分散サーバシステムにおいて、
システム障害が発生した場合、その障害を検出し、故障部位を特定する故障部位特定手段と、
前記故障部位特定手段により、ソフト障害と特定された場合、そのソフト障害が発生したプロセスの種別に基づいて復旧手順を決定し、決定した復旧手順に従って前記プロセスを再起動させる再開手段と、
前記故障部位特定手段により、ハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動するサーバ切替え手段と
を具備し、
前記複数のサーバは、該複数のサーバをＮ台としたとき、Ｌ（＞１）個のサーバ群からなるドメインに分割され、
前記再開手段は、前記プロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定することを特徴とし、プロセス種別ごとに、そのプロセスが障害時に適用する再開種別、再開対象とするプロセス種別、再開するサーバの範囲の情報を保持し、ソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行い、個別再開が失敗した場合は上記情報に基づいてドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させることを特徴とし、
前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、
前記運用状態プロセスと前記待機状態プロセスとは、それぞれ異なったドメイン内に起動され、
前記再開手段は、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させることを特徴とする分散サーバシステム。 - ソフト障害またはハード障害の発生後、前記運用状態プロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻す状態復帰手段を具備することを特徴とする請求項１に記載の分散サーバシステム。
- 複数のサーバにより構成される分散サーバシステム上で生じた障害を復旧させる障害復旧方法において、
前記複数のサーバをＮ台としたとき、該Ｎ台のサーバをＬ（＞１）個のサーバ群からなるドメインに分割し、
システム障害が発生した場合、当該システム障害に対応するプロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定することを特徴とし、プロセス種別ごとに、そのプロセスが障害時に適用する再開種別、再開対象とするプロセス種別、再開するサーバの範囲の情報を保持し、
システム障害が発生した場合、該システム障害を検出して故障部位を特定し、
故障部位がソフト障害であった場合に、このソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、
当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記分割されたドメイン単位で前記プロセスを再起動させ、
故障部位がハード障害であった場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させ、
ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合は上記情報に基づいてドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させることを特徴とし、
前記プロセスを、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成し、
前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動し、
前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させることを特徴とする障害復旧方法。 - ソフト障害またはハード障害の発生後、前記運用状態プロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻すことを特徴とする請求項３に記載の障害復旧方法。
- 分散サーバシステムを構成する複数のサーバをＮ台としたとき、該Ｎ台のサーバをＬ（＞１）個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理するステップと、
前記分散サーバシステム上でシステム障害が発生した場合、前記分割されたドメイン単位に再開範囲を限定し、プロセス種別ごとに、そのプロセスが障害時に適用する再開種別、再開対象とするプロセス種別、再開するサーバの範囲の情報を保持するステップと、前記特定された故障部位に基づいて、当該システム障害が生じたプロセスを再起動させるステップと、
システム障害が発生した場合、その障害を検出して故障部位を特定するステップと、
故障部位がソフト障害と特定した場合に、そのソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセ
スの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記プロセスを再起動させるステップと、
故障部位がハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるステップと、
ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合は上記情報に基づいてドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させるステップと、
前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動するステップと、
前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させるステップと
をコンピュータに実行させることを特徴とする障害復旧プログラム。 - ソフト障害またはハード障害の発生後、運用状態のプロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻すステップをコンピュータに実行させることを特徴とする請求項５に記載の障害復旧プログラム。
- 分散サーバシステムを構成する複数のサーバをＮ台としたとき、該Ｎ台のサーバをＬ（＞１）個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理するステップと、
前記分散サーバシステム上でシステム障害が発生した場合、前記分割されたドメイン単位に再開範囲を限定し、プロセス種別ごとに、そのプロセスが障害時に適用する再開種別、再開対象とするプロセス種別、再開するサーバの範囲の情報を保持するステップと、
前記特定された故障部位に基づいて、当該システム障害が生じたプロセスを再起動させるステップと、
システム障害が発生した場合、その障害を検出して故障部位を特定するステップと、
故障部位がソフト障害と特定した場合に、そのソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するＡＰＬプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のＡＰＬプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のＡＰＬプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのＡＰＬプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、ＡＰＬプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記プロセスを再起動させるステップと、
故障部位がハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるステップと、
ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合は上記情報に基づいてドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させるステップと、
前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動するステップと、
前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させるステップと
をコンピュータに実行させるための障害復旧プログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001143756A JP4112191B2 (ja) | 2001-05-14 | 2001-05-14 | 分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001143756A JP4112191B2 (ja) | 2001-05-14 | 2001-05-14 | 分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002342107A JP2002342107A (ja) | 2002-11-29 |
| JP4112191B2 true JP4112191B2 (ja) | 2008-07-02 |
Family
ID=18989842
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001143756A Expired - Lifetime JP4112191B2 (ja) | 2001-05-14 | 2001-05-14 | 分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4112191B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101618836B (zh) * | 2009-07-28 | 2012-05-23 | 中国水电顾问集团华东勘测设计研究院 | 一种交叉缆机布置结构 |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4558740B2 (ja) | 2004-10-20 | 2010-10-06 | 富士通株式会社 | アプリケーション管理プログラム、アプリケーション管理方法、およびアプリケーション管理装置 |
| WO2011083687A1 (ja) | 2010-01-08 | 2011-07-14 | 日本電気株式会社 | 運用管理装置、運用管理方法、及びプログラム記憶媒体 |
| FR2956543B1 (fr) * | 2010-02-17 | 2012-02-03 | Evidian | Procede et dispositif de propagation d'evenements de gestion de session. |
| KR101864126B1 (ko) * | 2016-02-23 | 2018-06-04 | 국방과학연구소 | 지속적인 서비스 제공을 위한 정상상태 모델 기반의 침입감내 시스템 및 그 제어방법 |
-
2001
- 2001-05-14 JP JP2001143756A patent/JP4112191B2/ja not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101618836B (zh) * | 2009-07-28 | 2012-05-23 | 中国水电顾问集团华东勘测设计研究院 | 一种交叉缆机布置结构 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002342107A (ja) | 2002-11-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11194679B2 (en) | Method and apparatus for redundancy in active-active cluster system | |
| JP3844621B2 (ja) | アプリケーション実現方法及びアプリケーション実現装置 | |
| CN110071821B (zh) | 确定事务日志的状态的方法，节点和存储介质 | |
| US8984330B2 (en) | Fault-tolerant replication architecture | |
| WO2019085875A1 (zh) | 存储集群的配置修改方法、存储集群及计算机系统 | |
| US6363497B1 (en) | System for clustering software applications | |
| JP4659062B2 (ja) | フェイルオーバ方法、プログラム、管理サーバおよびフェイルオーバシステム | |
| US20140289554A1 (en) | Implementing failover processes between storage stamps | |
| JP2006004434A (ja) | 分散障害許容型コンピューティングシステムにおける効率のよいレプリカセットの変更 | |
| JP2014532921A (ja) | 高可用性クラスタにおけるスプリット・ブレイン耐性フェイルオーバ | |
| JP2005209201A (ja) | 高可用性クラスタにおけるノード管理 | |
| US6629260B1 (en) | Automatic reconnection of partner software processes in a fault-tolerant computer system | |
| JP5948933B2 (ja) | ジョブ継続管理装置、ジョブ継続管理方法、及び、ジョブ継続管理プログラム | |
| US9582386B2 (en) | System and method for maintaining a copy of a cloud-based computing environment and restoration thereof | |
| CN113612614B (zh) | 基于区块链网络的共识容灾方法、装置、设备和存储介质 | |
| US8015432B1 (en) | Method and apparatus for providing computer failover to a virtualized environment | |
| JP2009129409A (ja) | 障害回復方法、計算機、クラスタシステム、管理計算機及び障害回復プログラム | |
| JP4112191B2 (ja) | 分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体 | |
| JP5285045B2 (ja) | 仮想環境における故障復旧方法及びサーバ及びプログラム | |
| US11036530B2 (en) | Application continuous high availability solution | |
| JPH07183891A (ja) | 計算機システム | |
| JP6856574B2 (ja) | サービス継続システムおよびサービス継続方法 | |
| JP6107159B2 (ja) | データベースシステム及びデータベースシステムの制御方法 | |
| JP5277228B2 (ja) | クラスタシステム復旧方法、サーバ及びソフトウェア | |
| US20210073091A1 (en) | Method of fault management in a network of nodes and associated part of network of nodes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040209 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20040220 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060621 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060704 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060904 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070123 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070323 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20071002 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071129 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20071106 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20080107 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080401 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080409 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4112191 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110418 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110418 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120418 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120418 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130418 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140418 Year of fee payment: 6 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313117 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| EXPY | Cancellation because of completion of term |