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
【発明の属する技術分野】
本発明は、複数の汎用サーバにより構成された分散構成のサーバシステムにおいて、ソフト障害、もしくはハード障害を検出し、関連するプロセスの再起動、プロセスの正常な汎用サーバでの再起動、再度運転状態への復帰を行う分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体に関する。
【0002】
【従来の技術】
図13は、従来からの高信頼性を実現するサーバクライアント型のシステム構成を示すブロック図である。センタ装置101は、複数のクライアント107〜109とDCN106を介して接続可能であり、LAN105に接続した複数のサーバ102〜104により構成されている。サーバ上に動作する複数のプロセス111〜113の連携によりサービス110を提供する。このような構成において、サービスの中断となる要因は、ソフト障害とハード障害とである。
【0003】
ソフト障害としては、サーバ上で動作するプロセスのメモリ操作違反によるプロセスの異常停止が挙げられる。ソフト障害を救済する方法として、ソフト障害を検出した場合、当該プロセスを初期化再起動し、サービスを継続する方法が取られる。しかしながら、プロセスの特性により、複数のサービスに共用されるプロセスの場合、障害が発生したプロセスのみの救済では、システムとして安定したサービスの再開が行える保証が無く、まとまった単位でプロセスを初期化再起動しサービスを救済する方法が必要である。
【0004】
また、ハード障害としては、構成するサーバのCPUやボードの故障によるプロセスの異常停止が挙げられる。ハード障害を救済する方法は、運用サーバ上のプロセスを救済するための待機サーバを用意する方法により3つに分類される。N台の運用サーバに対して同じ数の待機サーバを用意する2N台構成、N台の運用サーバに対して1台の待機サーバを用意するN+1台構成、N台の運用サーバに対して待機サーバを用意せず、正常な運用サーバにおいて故障したサーバ上のプロセスを救済するN台構成がある。何れの構成においても、サーバが故障した場合、他のサーバにおいて、故障したサーバ上のプロセスを再起動し、サービスを継続する方法が取られる。加えて、ハード障害の場合、当該ハードで動作するプロセスのソフト障害と考えられるため、ソフト障害の救済方法も適用する必要がある。
【0005】
【発明が解決しようとする課題】
ところで、上述した従来技術では、ソフト障害の場合、故障した当該プロセスの特性を分類し、プロセス種別にあわせた救済方法を実施し、ハード障害の場合、当該サーバ上で動作する全てのプロセスを他のサーバで救済する際、障害サーバ上で動作していたプロセスにあわせた救済方法も実施する必要がある。
【0006】
分散サーバ構成において動作するプロセスは、分散構成を意識しないで動作するAPLプロセスと、分散構成をAPLプロセスに意識させないための機能を持ち、複数のAPLプロセスの情報を管理する共用プロセスとに分類できる。図14に共用プロセスとAPLプロセスとの関係を示す。
【0007】
サービスAは、APLプロセスA1〜A4の連携により提供される。共用プロセスE1、E2は、サービスAの各プロセスの連携状態を管理する。同様にサービスBも、APLプロセスB1〜B4の連携により提供される。共用プロセスE1、E2は、サービスBの各プロセスの連携状態も管理する。
【0008】
いずれかのAPLプロセスが停止した場合には、当該APLプロセスを再起動するのみで、サービスの再開が可能となる。これに対して、いずれかの共用プロセスが停止した場合には、分散サーバ上のプロセス間の情報を管理するため、管理下のプロセスと共用プロセス間の情報の一貫性が崩れる可能性がある。
【0009】
そのため、共用プロセスの再起動のみでは、システムの安定的なサービスの復旧ができないという問題がある。そこで、この問題を解決する方法として、早急な回復手段である共用プロセスの管理下のプロセス全てを再開する手法を用いることが考えられる。しかしながら、全てのプロセスを再開することにより、再開完了までの期間、全てのサービスが停止してしまうという問題がある。
【0010】
また、交換機のように、主メモリの同期運転を行っていないサーバを活用する場合、OSの起動時間や再開するプロセスの数により再開時間が余儀なく長期化するという問題がある。
【0011】
この発明は上述した事情に鑑みてなされたもので、ソフト障害、ハード障害に対し、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化することができ、また、サービスの中断時間を短縮することができる分散サーバシステム、障害復旧方法、障害復旧プログラムおよび記録媒体を提供することを目的とする。
【0012】
【課題を解決するための手段】
上述した問題点を解決するために、請求項1記載の発明では、システムを複数のサーバにより構成する分散サーバシステムにおいて、システム障害が発生した場合、その障害を検出し、故障部位を特定する故障部位特定手段と、前記故障部位特定手段により、ソフト障害と特定された場合、そのソフト障害が発生したプロセスの種別に基づいて復旧手順を決定し、決定した復旧手順に従って前記プロセスを再起動させる再開手段と、前記故障部位特定手段により、ハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動するサーバ切替え手段とを具備し、前記複数のサーバは、該複数のサーバをN台としたとき、L(>1)個のサーバ群からなるドメインに分割され、前記再開手段は、前記プロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定することを特徴とし、前記再開手段は、ソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するAPLプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のAPLプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のAPLプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのAPLプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、APLプロセス、及び、共用プロセスを再開するドメイン全再開を行い、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させることを特徴とし、前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとは、それぞれ異なったドメイン内に起動され、前記再開手段は、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させることを特徴とする。
【0015】
また、請求項2記載の発明では、請求項1に記載の分散サーバシステムにおいて、ソフト障害またはハード障害の発生後、前記運用状態プロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻す状態復帰手段を具備することを特徴とする。
【0016】
また、上述した問題点を解決するために、請求項3記載の発明では、複数のサーバにより構成される分散サーバシステム上で生じた障害を復旧させる障害復旧方法において、前記複数のサーバをN台としたとき、該N台のサーバをL(>1)個のサーバ群からなるドメインに分割し、システム障害が発生した場合、当該システム障害に対応するプロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定することを特徴とし、システム障害が発生した場合、該システム障害を検出して故障部位を特定し、故障部位がソフト障害であった場合に、このソフト障害の発生したプロセスの種別がが、分散構成を意識しないで動作するAPLプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のAPLプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のAPLプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのAPLプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、APLプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記分割されたドメイン単位で前記プロセスを再起動させ、故障部位がハード障害であった場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させ、ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させることを特徴とし、前記プロセスを、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成し、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動し、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させることを特徴とする。
【0020】
また、請求項4記載の発明では、請求項3に記載の障害復旧方法において、ソフト障害またはハード障害の発生後、前記運用状態プロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻すことを特徴とする。
【0021】
また、上述した問題点を解決するために、請求項5記載の発明では、分散サーバシステムを構成する複数のサーバをN台としたとき、該N台のサーバをL(>1)個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理するステップと、前記分散サーバシステム上でシステム障害が発生した場合、前記分割されたドメイン単位に再開範囲を限定し、前記特定された故障部位に基づいて、当該システム障害が生じたプロセスを再起動させるステップと、システム障害が発生した場合、その障害を検出して故障部位を特定するステップと、故障部位がソフト障害と特定した場合に、そのソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するAPLプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のAPLプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のAPLプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのAPLプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、APLプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記プロセスを再起動させるステップと、故障部位がハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるステップと、ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させるステップと、前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動するステップと、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させるステップとをコンピュータに実行させることを特徴とする。
【0024】
また、請求項6記載の発明では、請求項5に記載の障害復旧プログラムにおいて、ソフト障害またはハード障害の発生後、運用状態のプロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻すステップをコンピュータに実行させることを特徴とする。
【0025】
また、上述した問題点を解決するために、請求項7記載の発明では、分散サーバシステムを構成する複数のサーバをN台としたとき、該N台のサーバをL(>1)個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理するステップと、前記分散サーバシステム上でシステム障害が発生した場合、前記分割されたドメイン単位に再開範囲を限定し、前記特定された故障部位に基づいて、当該システム障害が生じたプロセスを再起動させるステップと、システム障害が発生した場合、その障害を検出して故障部位を特定するステップと、故障部位がソフト障害と特定した場合に、そのソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するAPLプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のAPLプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のAPLプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのAPLプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、APLプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記プロセスを再起動させるステップと、故障部位がハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるステップと、ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合はドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させるステップと、前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動するステップと、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させるステップとをコンピュータに実行させるための障害復旧プログラムを記録したことを特徴とする。
【0027】
この発明では、前記複数のサーバをN台としたとき、L(>1)個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理する。システム障害が発生した場合、故障部位特定手段により、その障害を検出して故障部位を特定し、ソフト障害と特定された場合には、再開手段により、そのソフト障害が発生したプロセスの種別に基づいて復旧手順を決定し、決定した復旧手順に従って前記プロセスを再起動させる。このとき、前記再開手段は、前記プロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定する。一方、ハード障害と特定された場合、サーバ切替え手段により、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させる。したがって、ソフト障害、ハード障害に対し、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化することが可能となり、また、サービスの中断時間を短縮することが可能となる。
【0028】
【発明の実施の形態】
以下、図面を用いて本発明の実施の形態を説明する。
A.ドメインおよびサーバ構成
本実施形態では、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化するドメイン分割再開方式として、以下の機能により影響範囲の局在化を図る。論理的なシステムとしてドメインを定義し、X番目の運用ドメインを構成するサーバ数を運用数Ma(X)とし、X番目の待機ドメインを構成するサーバ数を待機数Mw(X)とする。1つのサーバシステムにおいて必要な運用ドメインをK(≧1)個、待機ドメインをL(≧0)個とする。待機ドメインLが0個の場合、ハード障害時、他の正常な運用ドメインに縮退する構成とする。1つのシステムに必要な運用サーバ数Naは数式1、待機サーバ数Nwは数式2によって表わされる。
【0029】
【数1】
【0030】
【数2】
【0031】
なお、ハード障害等により、ドメインを切替えた場合、負荷が偏ってしまう可能性があるため、システム構築において、同一性能のサーバを用い、各ドメインを構成するサーバ数を同数とすることが好ましい。
【0032】
図1は、待機ドメイン無し(L=0)、運用ドメインが2つ(K=2)、各運用ドメインのサーバ数が3つという構成におけるAPLプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。なお、共用プロセスの停止は、ドメインの停止となるため、ドメイン毎に同一サーバを用いることが好ましい。ドメイン301のサーバ305、ドメイン302のサーバ308の各々に共用プロセスE1,E2を配置し、ドメイン内のプロセスの情報を管理する。
【0033】
サーバシステムにサービスA〜Dの4つのサービスがある場合、それぞれのサービスを2個のドメイン301,302において負荷分散により起動する。ドメイン301のサーバ303にサービスAのAPLプロセスA1,A2を、サーバ304にサービスBのAPLプロセスB1,B2を起動し、ドメイン302のサーバ306にサービスCのAPLプロセスC1,C2を、サーバ307にサービスDのAPLプロセスD1,D2を起動する。この場合、待機サーバが無いため、運用サーバの縮退により、サービスの救済を行う。
【0034】
図2は、待機ドメイン有り(L=1:1つ)、運用ドメインが2つ(K=2)、各運用・待機ドメインのサーバ数が3つという構成におけるAPLプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。運用ドメインには、待機ドメインが無い場合と同様に、APLプロセスを負荷分散起動する。障害時の救済先として待機系のドメイン401であるサーバ402〜404を追加する。
【0035】
本システムは、ソフト障害、もしくはハード障害を検出する故障部位特定機能と、該故障部位特定機能により特定された要因として、ソフト障害の場合に、関連するプロセスを再起動する再開機能と、ハード障害の場合に、故障したサーバ上のプロセスを他の正常な汎用サーバに再起動するサーバ切替え機能と、ドメインAPL再開やサーバ閉塞/閉塞解除によって、運用APLプロセスが起動するサーバが偏った場合には、再度運転状態へ戻す状態復帰機能を具備する。
【0036】
障害が発生した場合、故障部位特定機能により、ソフト障害、もしくはハード障害に分類する。ソフト障害の場合には、そのソフト障害が発生したプロセスの種別に基づいて再開フェーズ(復旧手順)を決定し、決定した再開フェーズに従って再開機能により、関連するプロセスのメモリを初期化し、同プロセスを再起動して再開する。ハード障害の場合には、障害が生じたサーバ上で共用プロセスが起動されていなければ、サーバ切替え機能により、故障したサーバ上のプロセスを他の正常な汎用サーバ上で再起動する一方、共用プロセスが起動されていた場合には、ソフト障害と同様に、障害を起こしたプロセス種別から再開範囲を決定し、その範囲内のプロセスを再開する。また、ドメインAPL再開やサーバ閉塞/閉塞解除によって、運用APLプロセスが起動するサーバが偏った場合には、状態復帰機能により再度運転状態へ戻す。
【0037】
本実施形態では、上記故障部位特定機能、再開機能、サーバ切替え機能、状態復帰機能を、図1または図2に示す構成において、各ドメインの共用プロセスE1,E2に設けるようにしているが、これに限定されることなく、これら機能(各機能の一部を含む)をAPLプロセスに分散するようにしてもよい。
【0038】
また、上記故障部位特定機能、再開機能、サーバ切替え機能、状態復帰機能は、図示しない記憶部に記憶されたプログラムを実行することで実現するようになっている。記憶部は、フレキシブルディスク、ハードディスク装置や光磁気ディスク装置、フラッシュメモリ等の不揮発性メモリやRAM(Random Access Memory)のような揮発性のメモリ、あるいはこれらの組み合わせにより構成されるものとする。また、上記記憶部とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ(RAM)のように、一定時間プログラムを保持しているものも含む。
【0039】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワークや電話回線等の通信回線のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、上述した処理の一部を実現するためのものであってもよい。さらに、上述した処理をサーバに既に記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよい。
【0040】
B.実施形態の動作
次に、本実施形態の動作について詳細に説明する。
ここで、図3は、故障部位特定機能によりソフト障害、またはハード障害を特定した後における動作を説明するフローチャートである。正常運転中のシステム状態を常時監視し、異常が発生した場合、ソフト障害、もしくはハード障害の特定を行う(ステップS501)。ソフト障害と判定した場合には、障害を起こしたプロセス種別から再開範囲を決定し、その範囲内のプロセスを再開する(ステップS502)。そして、再開したプロセスが正常状態に復旧すると(ステップS503)、再び、システム状態の常時監視を行う(ステップS501)。
【0041】
また、ハード障害と判定した場合には、故障したサーバ上で共用プロセスが起動されていたか否かを判断する(ステップS504)。そして、共用プロセスが起動されていない場合、すなわちAPLプロセスのみが起動されていた場合には、故障したサーバ上のプロセスの救済を行うため、故障したハード上のプロセスの起動先サーバを決定後、当該起動先サーバへプロセスの切替えを実施する(ステップS505)。正常にプロセスの切替えが完了し、システムが正常状態に復旧すると(ステップS506)、再び、システム状態の常時監視を行う(ステップS501)。
【0042】
一方、故障したサーバ上で共用プロセスが起動されていた場合には、ソフト障害と同様に、障害を起こしたプロセス種別から再開範囲を決定し、その範囲内のプロセスを再開する(ステップS507)。そして、再開したプロセスが正常状態に復旧すると(ステップS508)、再び、システム状態の常時監視を行う(ステップS501)。
【0043】
次に、図4は、ソフト障害が発生したプロセス種別とそれに対応した再開種別とを示す概念図である。プロセス種別としてAPLプロセス、共用プロセスP1、共用プロセスP2(共用プロセスを2つに分類)の3つに分類する。
【0044】
APLプロセスがソフト障害の場合には、個別再開を実施する。すなわち、個別再開と当該プロセスのみの再開とによりプロセスを復旧する。この場合、個別再開実施中、当該プロセスが関係するサービスが停止するのみで、プロセス復旧後、再度サービスを開始することが可能となる。図1または図2に示すAPLプロセスA1,A2、B1,B2、C1,C2、D1,D2のソフト障害は全て個別再開により復旧可能である。
【0045】
共用プロセスがソフト障害の場合には、再開範囲をドメイン内とする。共用プロセスは、分散サーバ上のプロセス間の情報を管理するため、管理下のプロセスと共用プロセス間の情報の一貫性が崩れる可能性がある。そのため、共用プロセスを利用するドメイン内の全プロセスの再開が必要となる。そこで、共用プロセスの種別により、同時に再開させるプロセスの種別範囲としてドメイン全再開とドメインAPL再開との2種類に分類する。
【0046】
メモリの受け渡し等によりOSのカーネルに関連のあるプロセスやOSに付随するデーモンプロセスなどの共用プロセスP1の場合には、ドメイン内のOSから全て(共用プロセスP1,P2とAPLプロセスを含む)再開するドメイン全再開を行う。一方、OSとの関連のない共用プロセスP2の場合には、ドメイン内の全てのAPLプロセスと共用プロセスP2を再開するドメインAPL再開を行う。例えば、図1に示す共用プロセスE1を共用プロセスP1、共用プロセスE2を共用プロセスP2とした場合、共用プロセスE1のソフト障害に対しては、ドメイン全再開を実施し、共用プロセスE2のソフト障害に対しては、ドメインAPL再開を実施する。
【0047】
そして、適用した再開フェーズではシステムが正常に復旧しない場合には、適用した再開フェーズの範囲ではないプロセスにおいてプロセス間の矛盾が発生していると判断して、上位の再開フェーズにエスカレーションする。システム全体の全再開は、ドメイン全再開からのエスカレーションに限られるため、システム全体のサービス停止になる確率が低いと言える。
【0048】
ここで、図5は、再開フェーズの発生・復旧と再開エスカレーションとの方向を示す概念図である。正常状態701において、APLプロセス706、共用プロセス707、共用プロセス708にソフト障害が発生した場合には、障害時の状態変化方向である個別再開702、ドメインAPL再開703、ドメイン全再開704に状態変化を実施し、復旧すれば正常状態701に戻る。そして、当該の再開が失敗した場合には、個別再開702、ドメインAPL再開703、ドメイン全再開704、全再開705の順にエスカレーションを実施する。
【0049】
ドメインAPL再開やドメイン全再開は、システムに起動するプロセス数やハード/OS固有の起動時間によって起動時間に差異が生じる。そこで、プロセスの実行環境が整っている正常な他のサーバにおいて、故障したプロセスを救済する。プロセスを正常なサーバによって救済するドメイン間サービス救済方式として、以下の機能によりサービスの救済の高速化を図る。
【0050】
ここで、図6は、APLプロセスを起動してサービスを提供可能になるまでの起動処理を示す概念図である。APLプロセスの起動処理により、運用状態801と待機状態802との2種類の状態を持たせる。運用状態のAPLプロセス(運用APLプロセス)では、メモリの獲得803、初期設定804を実施し、サービスを提供可能となる。一方、待機状態のAPLプロセス(待機APLプロセス)では、メモリの獲得803のみを行った状態とする。運用APLプロセスのソフト障害時には、待機APLプロセスに対して初期設定804のみを実施することで、運用・待機の切替えが可能となる。すなわち、迅速に運用・待機を切替えることができる。1つのプロセスを起動する際、運用プロセスと待機プロセスとを常に一組となるように異なるドメインに起動する。
【0051】
ここで、図7は、図1に示す待機ドメイン無し(L=0)、運用ドメインが2つ(K=2)、各運用ドメインのサーバ数が3つという構成における運用プロセスと待機プロセスとの起動状態を示すブロック図である。ドメイン301のサーバ302にサービスA(運用)の運用APLプロセスA1,A2、サーバ303にサービスB(運用)の運用APLプロセスB1,B2を分散起動する。これに対して、ドメイン305のサーバ306にサービスAの待機プロセスA’1,A’2、サーバ307にサービスBの待機プロセスB’1,B’2を分散起動する。同様にドメイン305のサーバ306においてサービスCの運用プロセスC1,C2、サーバ307においてサービスDの運用プロセスD1,D2を起動し、ドメイン301のサーバ302に待機プロセスC’1,C’2、サーバ303に待機プロセスD’1,D’2を分散起動する。共用プロセスE1,E2は、各ドメイン301,305のサーバ304,308に起動される。ドメイン301の共用プロセスE1,E2は、ドメイン301内の全てのAPLプロセスに共用され、他のドメインのAPLプロセスには共用されない。
【0052】
次に、図8は、図7に示す待機ドメイン無し(L=0)、運用ドメインが2つ(K=2)、各運用ドメインのサーバ数が3つという構成においてドメイン305のドメインAPL再開を実施した際のシステムの状態変化を示す遷移図である。運転状態(状態1001:図5の正常状態に相当)において、ドメイン305のドメインAPL再開を実施した場合、ドメイン再開状態(状態1002)として、ドメイン305側の運用APLプロセスC1,C2、D1,D2の停止と、ドメイン301側の待機APLプロセスC’1,C’2、D’1,D’2に対する初期設定とを行い、運用APLプロセスへの切替えを実施する。ドメイン305からドメイン301へ運用APLを切替える時間がサービス停止期間となる。ドメインAPL再開の場合、サービスの切替え時に共用プロセスP2(E2)の再開を実施する。
【0053】
ドメイン全再開の場合、サービスの切替え時にOSを含めた共用プロセスP1(E1)、共用プロセスP2(E2)の再開を実施する。ドメイン305の復旧状態(状態1003:図5の正常状態に相当)として、再開を実施したドメイン305において、ドメイン301の運用APLプロセスA1,A2、B1,B2、C1,C2、D1,D2に対する待機APLプロセスA’1,A’2、B’1,B’2、C’1,C’2、D’1,D’2を再起動する。ドメイン全再開も同様である。
【0054】
次に、図9は、図2に示す待機ドメイン有り(L=1:1つ)、運用ドメインが2つ(K=2)、各運用・待機ドメインのサーバ数が3つという構成における運用プロセスと待機プロセスとの起動状態を示すブロック図である。ドメイン301のサーバ302にサービスA(運用)の運用APLプロセスA1,A2、サーバ303にサービスB(運用)の運用APLプロセスB1,B2、ドメイン305のサーバ306においてサービスCの運用プロセスC1,C2、サーバ307においてサービスDの運用プロセスD1,D2を負荷分散起動する。これら全ての運用APLプロセスに対して待機ドメイン401のサーバ402,403に待機APLプロセスA’1,A’2、B’1,B’2、C’1,C’2、D’1,D’2を分散起動する。各ドメイン301,305,401の共用プロセスE1,E2は、ドメイン301,305,401内の全てのAPLプロセスに共用され、他のドメインのAPLプロセスには共用されない。
【0055】
図10は、図9に示す待機ドメイン有り(L=1:1つ)、運用ドメインが2つ(K=2)、各運用・待機ドメインのサーバ数が3つという構成において、ドメイン305のドメインAPL再開を実施した際のシステムの状態変化を示す遷移図である。運転状態(状態1201:図5の正常状態に相当)において、ドメイン305のドメインAPL再開を実施した場合、ドメイン再開状態(状態1202)として、ドメイン305側の運用APLプロセスC1,C2、D1,D2の停止と、ドメイン401側の待機APLプロセスC’1,C’2、D’1,D’2に対する初期設定とを行い、運用APLプロセスへの切替えを実施する。ドメイン305からドメイン401(待機ドメイン)へ運用APLを切替える時間がサービス停止期間となる。
【0056】
ドメインAPL再開の場合、サービスの切替え時に共用プロセスP2の再開を実施する。ドメイン全再開の場合、サービスの切替え時にOSを含めた共用プロセスP1、共用プロセスP2の再開を実施する。ドメイン305の復旧状態(状態1203:図5の正常状態に相当)として、再開を実施したドメイン305において、ドメイン401の運用APLプロセスC1,C2、D1,D2に対する待機APLプロセスC’1,C’2、D’1,D’2を再起動する。ドメイン全再開も同様である。
【0057】
次に、図11は、図7に示す待機ドメイン無し(L=0)、運用ドメインが2つ(K=2)、各運用ドメインのサーバ数が3つという構成においてドメイン301側のサーバ303を閉塞(故障/保守)した際のシステム状態変化を示すブロック図である。運転状態(状態1301:図5の正常状態に相当)において、ドメイン301側のサーバ303を閉塞(故障/保守)した場合、ドメイン301のサーバ303の閉塞状態(状態1302)として、ドメイン301のサーバ303上の運用APLプロセスB1,B2と待機プロセスD’1,D’2との停止と、ドメイン305のサーバ307の待機APLプロセスB’1,B’2に対する初期設定とを行い、運用APLプロセスへの切替えを実施する。このとき、ドメイン301からドメイン305へ運用APLプロセスを切替える時間がサービス停止期間となる。必ずドメイン間で運用系と待機系とが一組となるようにするため、ドメイン301のサーバ303において停止した待機APLプロセスD’1,D’2をドメイン301のサーバ302において待機APLプロセスとして起動する。
【0058】
次に、図12は、図9に示す待機ドメイン有り(L=1:1つ)、運用ドメインが2つ(K=2)、各運用・待機ドメインのサーバ数が3つという構成においてドメイン301側のサーバ303を閉塞(故障/保守)した際のシステム状態変化を示す遷移図である。運転状態(状態1401:図5の正常状態に相当)において、ドメイン301側のサーバ303を閉塞(故障/保守)した場合、ドメイン301のサーバ303閉塞状態(状態1402)として、ドメイン301のサーバ303上の運用APLプロセスB1,B2の停止と、ドメイン401のサーバ403の待機APLプロセスB’1,B’2に対する初期設定とを行い、運用APLプロセスへの切替えを実施する。ドメイン301からドメイン401へ運用APLプロセスを切替える時間がサービス停止期間となる。必ずドメイン間で運用系と待機系が一組となるようするため、ドメイン301のサーバ303において停止した待機APLプロセスD’1,D’2をドメイン301のサーバ302において待機APLプロセスとして起動する。
【0059】
また、本実施形態においては、ドメインAPL再開やサーバ閉塞/閉塞解除によって、運用APLプロセスが起動するサーバに偏りが生じた場合には、前述したように、再度、運転状態へ戻す状態復帰機能により、図8、図10においては、ドメイン305を復旧状態(状態1003、状態1203:図5の正常状態に相当)から運転状態(状態1001、状態1201:図5の正常状態に相当)へ復旧させる。同様に図11、図12においては、ドメイン301のサーバ303の閉塞状態(状態1302、状態1402)から運転状態(状態1301、状態1401:図5の正常状態に相当)へ復旧させる。
【0060】
なお、上述した実施形態においては、2種類の共有プロセスE1,E2のみを示しているが、これに限定されることなく、3つ以上であってもよい。また、共有プロセスが起動されているサーバ上でAPLプロセスが起動されていてもよい。
【0061】
【発明の効果】
以上説明したように、本発明によれば、前記複数のサーバをN台としたとき、L(>1)個のサーバ群からなるドメインに分割し、システム障害が発生した場合、故障部位特定手段により、その障害を検出して故障部位を特定し、ソフト障害と特定された場合には、再開手段により、そのソフト障害が発生したプロセスの種別に基づいて復旧手順を決定し、再開範囲を前記分割されたドメイン単位に限定して、決定した復旧手順に従って前記プロセスを再起動させ、一方、ハード障害と特定された場合には、サーバ切替え手段により、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるようにしたので、ソフト障害、ハード障害に対し、プロセスの初期化を行う再開範囲を狭くし、再開の影響範囲を局在化することができ、また、サービスの中断時間を短縮することができるという利点が得られる。
【図面の簡単な説明】
【図1】 本発明の実施形態による、待機ドメイン無し(L=0)、運用ドメインが2つ(K=2)、各運用ドメインのサーバ数が3つという構成におけるAPLプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。
【図2】 待機ドメイン有り(L=1:1つ)、運用ドメインが2つ(K=2)、各運用・待機ドメインのサーバ数が3つという構成におけるAPLプロセスと共用プロセスとを負荷分散起動した例を示すブロック図である。
【図3】 故障部位特定機能によりソフト障害、またはハード障害を特定した後における動作を説明するフローチャートである。
【図4】 ソフト障害が発生したプロセス種別とそれに対応した再開種別とを示す概念図である。
【図5】 再開フェーズの発生・復旧と再開エスカレーションとの方向を示す概念図である。
【図6】 APLプロセスを起動してサービスを提供可能になるまでの起動処理を示す概念図である。
【図7】 図1に示す待機ドメイン無し(L=0)、運用ドメインが2つ(K=2)、各運用ドメインのサーバ数が3つという構成における運用プロセスと待機プロセスの起動状態とを示すブロック図である。
【図8】 図7に示す待機ドメイン無し(L=0)、運用ドメインが2つ(K=2)、各運用ドメインのサーバ数が3つという構成においてドメイン305のドメインAPL再開を実施した際のシステムの状態変化を示す遷移図である。
【図9】 図2に示す待機ドメイン有り(L=1:1つ)、運用ドメインが2つ(K=2)、各運用・待機ドメインのサーバ数が3つという構成における運用プロセスと待機プロセスとの起動状態を示すブロック図である。
【図10】 図9に示す待機ドメイン有り(L=1:1つ)、運用ドメインが2つ(K=2)、各運用・待機ドメインのサーバ数が3つという構成において、ドメイン305のドメインAPL再開を実施した際のシステムの状態変化を示す遷移図である。
【図11】 図7に示す待機ドメイン無し(L=0)、運用ドメインが2つ(K=2)、各運用ドメインのサーバ数が3つという構成においてドメイン301側のサーバ303を閉塞(故障/保守)した際のシステム状態変化を示すブロック図である。
【図12】 図9に示す待機ドメイン有り(L=1:1つ)、運用ドメインが2つ(K=2)、各運用・待機ドメインのサーバ数が3つという構成においてドメイン301側のサーバ303を閉塞(故障/保守)した際のシステム状態変化を示す遷移図である。
【図13】 従来からのサーバクライアント型のシステム構成を示すブロック図である。
【図14】 従来技術による共用プロセスとAPLプロセスの関係を示す概念図である。
【符号の説明】
301,305 運用ドメイン
401 待機ドメイン
302 サーバ
303 サーバ
304 サーバ(故障部位特定手段、再開手段、サーバ切替え手段、状態復帰手段)
306 サーバ
307 サーバ
308 サーバ(故障部位特定手段、再開手段、サーバ切替え手段、状態復帰手段)
402 サーバ
403 サーバ
404 サーバ(故障部位特定手段、再開手段、サーバ切替え手段、状態復帰手段)
Claims (7)
- システムを複数のサーバにより構成する分散サーバシステムにおいて、
システム障害が発生した場合、その障害を検出し、故障部位を特定する故障部位特定手段と、
前記故障部位特定手段により、ソフト障害と特定された場合、そのソフト障害が発生したプロセスの種別に基づいて復旧手順を決定し、決定した復旧手順に従って前記プロセスを再起動させる再開手段と、
前記故障部位特定手段により、ハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動するサーバ切替え手段と
を具備し、
前記複数のサーバは、該複数のサーバをN台としたとき、L(>1)個のサーバ群からなるドメインに分割され、
前記再開手段は、前記プロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定することを特徴とし、プロセス種別ごとに、そのプロセスが障害時に適用する再開種別、再開対象とするプロセス種別、再開するサーバの範囲の情報を保持し、ソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するAPLプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のAPLプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のAPLプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのAPLプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、APLプロセス、及び、共用プロセスを再開するドメイン全再開を行い、個別再開が失敗した場合は上記情報に基づいてドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させることを特徴とし、
前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、
前記運用状態プロセスと前記待機状態プロセスとは、それぞれ異なったドメイン内に起動され、
前記再開手段は、前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させることを特徴とする分散サーバシステム。 - ソフト障害またはハード障害の発生後、前記運用状態プロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻す状態復帰手段を具備することを特徴とする請求項1に記載の分散サーバシステム。
- 複数のサーバにより構成される分散サーバシステム上で生じた障害を復旧させる障害復旧方法において、
前記複数のサーバをN台としたとき、該N台のサーバをL(>1)個のサーバ群からなるドメインに分割し、
システム障害が発生した場合、当該システム障害に対応するプロセスを再起動させる際に、再開範囲を前記分割されたドメイン単位に限定することを特徴とし、プロセス種別ごとに、そのプロセスが障害時に適用する再開種別、再開対象とするプロセス種別、再開するサーバの範囲の情報を保持し、
システム障害が発生した場合、該システム障害を検出して故障部位を特定し、
故障部位がソフト障害であった場合に、このソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するAPLプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のAPLプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のAPLプロセスの情報を管理する共用プロセスであり、
当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのAPLプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、APLプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記分割されたドメイン単位で前記プロセスを再起動させ、
故障部位がハード障害であった場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させ、
ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合は上記情報に基づいてドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させることを特徴とし、
前記プロセスを、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成し、
前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動し、
前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させることを特徴とする障害復旧方法。 - ソフト障害またはハード障害の発生後、前記運用状態プロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻すことを特徴とする請求項3に記載の障害復旧方法。
- 分散サーバシステムを構成する複数のサーバをN台としたとき、該N台のサーバをL(>1)個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理するステップと、
前記分散サーバシステム上でシステム障害が発生した場合、前記分割されたドメイン単位に再開範囲を限定し、プロセス種別ごとに、そのプロセスが障害時に適用する再開種別、再開対象とするプロセス種別、再開するサーバの範囲の情報を保持するステップと、前記特定された故障部位に基づいて、当該システム障害が生じたプロセスを再起動させるステップと、
システム障害が発生した場合、その障害を検出して故障部位を特定するステップと、
故障部位がソフト障害と特定した場合に、そのソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するAPLプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のAPLプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のAPLプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのAPLプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセ
スの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、APLプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記プロセスを再起動させるステップと、
故障部位がハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるステップと、
ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合は上記情報に基づいてドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させるステップと、
前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動するステップと、
前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させるステップと
をコンピュータに実行させることを特徴とする障害復旧プログラム。 - ソフト障害またはハード障害の発生後、運用状態のプロセスがいずれかのサーバに偏った場合、障害個所の復旧後、正常時のプロセス起動状態に戻すステップをコンピュータに実行させることを特徴とする請求項5に記載の障害復旧プログラム。
- 分散サーバシステムを構成する複数のサーバをN台としたとき、該N台のサーバをL(>1)個のサーバ群からなるドメインに分割し、それぞれのドメイン内のプロセスを管理するステップと、
前記分散サーバシステム上でシステム障害が発生した場合、前記分割されたドメイン単位に再開範囲を限定し、プロセス種別ごとに、そのプロセスが障害時に適用する再開種別、再開対象とするプロセス種別、再開するサーバの範囲の情報を保持するステップと、
前記特定された故障部位に基づいて、当該システム障害が生じたプロセスを再起動させるステップと、
システム障害が発生した場合、その障害を検出して故障部位を特定するステップと、
故障部位がソフト障害と特定した場合に、そのソフト障害の発生したプロセスの種別が、分散構成を意識しないで動作するAPLプロセスである場合は、ソフト障害の発生したサーバの当該ソフト障害のAPLプロセスのみを再開する個別再開を行い、ソフト障害の発生したプロセスの種別が、複数のAPLプロセスの情報を管理する共用プロセスであり、当該共用プロセスがオペレーションシステムに関連しない場合は、このソフト障害が発生したドメイン内の全てのサーバのAPLプロセスと、オペレーションシステムに関与しない共用プロセスとを再開するドメインアプリ再開を行い、ソフト障害の発生したプロセスの種別が共用プロセスであり、当該共用プロセスがオペレーションシステムに関連する場合は、このソフト障害が発生したドメインの全サーバのオペレーションシステム、APLプロセス、及び、共用プロセスを再開するドメイン全再開を行って、前記プロセスを再起動させるステップと、
故障部位がハード障害と特定した場合、故障したサーバ上のプロセスを他の正常なサーバ上で再起動させるステップと、
ソフト障害が発生したプロセスの種別に基づいて決定した復旧手順に従って前記プロセスを再起動させた際、個別再開が失敗した場合は上記情報に基づいてドメインアプリ再開により、ドメインアプリ再開が失敗した場合はドメイン全再開により、ドメイン全再開が失敗した場合は全再開により前記プロセスを再起動させるステップと、
前記プロセスは、メモリの確保および初期設定を行った運用状態プロセスと、メモリの確保までを行った待機状態プロセスとを一組として構成され、前記運用状態プロセスと前記待機状態プロセスとをそれぞれ異なったドメインに起動するステップと、
前記運用状態プロセスが停止した場合、前記待機状態プロセスに対して初期設定を行うことにより、前記プロセスを再起動させるステップと
をコンピュータに実行させるための障害復旧プログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
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 |