(57)【要約】【課題】データを管理するサーバが複数台で構成されるクラスタシステムにおいて、運用系のサーバで異常が発生した場合にフェイルオーバー処理によって運用系と待機系の双方が稼働し、同一データを複数台で更新してしまう課題がある。【解決手段】サービスの稼働状況を監視する監視サービスを設け、各サービスを提供するサーバは、監視サービスへ定期的に生存通知を行う。生存通知が失敗した場合は、自サービスを制限状態とし、データ更新を行わないことで、運用系と待機系の双方が同一データ更新する事を防ぐ。【選択図】  図１
2011138225.tif 000002
【特許請求の範囲】
【請求項１】
サービスの稼働状況を監視する監視装置に接続された、データを管理するサービスを提供するデータ管理装置であって、
自らが提供するサービスの状態を管理する状態管理手段と、
定期的に前記サービスの状態を前記監視装置に通知する通知手段と、
前記サービスを提供されるアプリケーションからのリクエストを受け付ける受付手段と、
前記受付手段にて受け付けた前記リクエストがデータの更新である場合に、前記状態管理手段にて管理している当該サービスの更新に係る状態が制限状態だった場合は更新のリクエストを拒否する拒否手段と
を有し、
前記状態管理手段は、
前記通知手段による通知が失敗した場合は、当該サービスの更新に係る状態を制限状態に遷移させ、
前記通知手段による通知が成功した場合は、当該サービスの更新に係る状態を更新のリクエストが拒否されない通常状態に遷移させる
ことを特徴とするデータ管理装置。
【請求項２】
データを複製するサービスを提供する複製装置に更に接続され、
管理するデータを更新する更新手段と、
更新内容を記憶する記憶領域を記憶に係る状態として設定する記憶領域設定手段と、
前記更新手段による更新に際して、更新内容を前記記憶領域設定手段による設定に基づいて前記複製装置が有する第一の記憶領域に記憶する第一の記憶手段と、
前記更新手段による更新に際して、更新内容を前記記憶領域設定手段による設定に基づいて前記データ管理装置が有する第二の記憶領域に記憶する第二の記憶手段と、
前記第一の記憶手段が、前記第一の記憶領域に記憶できたか否かを判定する第一の記憶成否判定手段と、
を更に有し、
前記記憶領域設定手段は、
前記第一の記憶成否判定手段にて、前記第一の記憶領域に記憶できなかったと判定された場合、当該サービスの記憶に係る状態を、当該更新内容を前記第二の記憶領域へ記憶する記憶状態に遷移させること
を特徴とする請求項１に記載のデータ管理装置。
【請求項３】
前記更新手段による更新に際して、前記サービスがいずれの記憶領域へ記憶する記憶状態であるか否かを確認する記憶状態確認手段と、
前記第二の記憶領域へ記憶する記憶状態であった場合に、前記第一の記憶領域へ記憶可能か否かを判定する第二の記憶成否判定手段と、
を有し、
前記第二の記憶成否判定手段にて前記第一の記憶領域へ記憶不可であった場合、前記第二の記憶手段は、前記第二の記憶領域へ更新内容を記憶し、
前記第二の記憶成否判定手段にて前記第一の記憶領域へ記憶可能であった場合、前記第一の記憶手段は、前記第二の記憶領域へ記憶している更新内容を前記第一の記憶領域へ記憶する
ことを特徴とする請求項２に記載のデータ管理装置。
【請求項４】
前記通知手段は、前記監視装置へ前記サービスの状態の通知の際に、前記サービスの記憶に係る状態が前記第一の記憶領域へ記憶する記憶状態であるか、前記第二の記憶領域へ記憶する記憶状態であるかを併せて通知することを特徴とする請求項３に記載のデータ管理装置。
【請求項５】
接続されたデータ管理装置が提供するサービスの稼働状況を監視する監視装置であって、
監視する前記サービスの稼働に係る状態を接続された装置からの通知に基づいて管理する管理手段と、
前記管理手段にて保持している前記サービスの稼働に係る状態が稼働から中止へ遷移したか否かを判定する判定手段と、
稼働に係る状態が稼働から中止へ遷移したと判定されたサービスに対し、フェイルオーバーに係る状態が禁止か否かを判定するフェイルオーバー判定手段と、
前記フェイルオーバー判定手段にてフェイルオーバーが禁止であると判定された場合、稼働に係る状態が中止へ遷移した当該サービスを中止する中止手段と
を有する監視装置。
【請求項６】
前記フェイルオーバー判定手段は、前記サービスに対し、記憶に係る状態が第二の記憶領域への記憶状態である場合にフェイルオーバーを禁止とすることを特徴とする請求項５に記載の監視装置。
【請求項７】
前記フェイルオーバー判定手段は、前記サービスが管理するデータがフェイルオーバー禁止の状態である場合に、フェイルオーバーを禁止とすることを特徴とする請求項５に記載の監視装置。
【請求項８】
接続された複製装置が提供する複製サービスの稼働状況を監視する監視装置であって、
監視する前記複製サービスの稼働に係る状態を接続された前記複製装置からの通知に基づいて管理する管理手段と、
前記管理手段にて保持している前記監視している第一の複製サービスの稼働に係る状態が稼働から中止へ遷移したか否かを判定する判定手段と、
稼働に係る状態が待機である第二の複製サービスが存在するか否かを確認する待機サービス確認手段と、
前記第二の複製サービスが存在しない場合に、前記第一の複製サービスが複製対象とするデータに対し、フェイルオーバーに係る状態を禁止の状態とし、さらに前記管理手段は、前記第一の複製サービスの稼働に係る状態を中止とする中止手段と、
前記第二の複製サービスが存在する場合に、前記第一の複製サービスから前記第二の複製サービスへのフェイルオーバー処理を行い、さらに前記管理手段は、前記第一の複製サービスの稼働に係る状態を停止とする停止手段と
を有する監視装置。
【請求項９】
サービスの稼働状況を監視する監視装置及びデータを管理するデータ管理装置に接続され、前記データを複製するサービスを提供する複製装置であって、
自らが提供するサービスの状態を管理する状態管理手段と、
定期的にサービスの稼働に係る状態を前記監視装置に通知する通知手段と、
当該サービスの更新に係る状態が通常状態である場合に、前記データ管理装置が有する第二の記憶領域に記憶されている更新内容を、前記複製装置が有する第一の記憶領域に記憶されているデータに反映する反映手段と、
を有し、
前記状態管理手段は、
前記通知手段による通知が失敗した場合は、当該サービスの更新に係る状態を制限状態に遷移させ、
前記通知手段による通知が成功した場合は、当該サービスの更新に係る状態を更新のリクエストが拒否されない通常状態に遷移させることを特徴とする複製装置。
【請求項１０】
複数のデータ管理装置と複数の複製装置と監視装置とを備えたクラスタシステムであって、
前記データ管理装置は、
自らが提供するサービスの状態を管理する状態管理手段と、
定期的に前記サービスの状態を前記監視装置に通知する通知手段と、
前記サービスを提供されるアプリケーションからのリクエストを受け付ける受付手段と、
前記受付手段にて受け付けた前記リクエストがデータの更新である場合に、前記状態管理手段にて管理している当該サービスの更新に係る状態が制限状態だった場合は更新のリクエストを拒否する拒否手段と、
を有し、
前記状態管理手段は、
前記通知手段による通知が失敗した場合は、当該サービスの更新に係る状態を制限状態に遷移させ、
前記通知手段による通知が成功した場合は、当該サービスの更新に係る状態を更新のリクエストが拒否されない通常状態に遷移させ、
前記複製装置は、
自らが提供するサービスの状態を管理する状態管理手段と、
定期的にサービスの稼働に係る状態を前記監視装置に通知する通知手段と、
当該サービスの更新に係る状態が通常状態である場合に、前記データ管理装置が有する第二の記憶領域に記憶されている更新内容を、前記複製装置が有する第一の記憶領域に記憶されているデータに反映する反映手段と、
を有し、
前記監視装置は、
監視する前記サービスの稼働に係る状態を接続された装置からの通知に基づいて管理する管理手段と、
前記管理手段にて保持している前記サービスの稼働に係る状態が稼働から中止へ遷移したか否かを判定する判定手段と、
稼働に係る状態が稼働から中止へ遷移したと判定されたサービスに対し、フェイルオーバーに係る状態が禁止か否かを判定するフェイルオーバー判定手段と、
前記フェイルオーバー判定手段にてフェイルオーバーが禁止であると判定された場合、稼働に係る状態が中止へ遷移した当該サービスを中止する中止手段と
を有することを特徴とするクラスタシステム。
【請求項１１】
サービスの稼働状況を監視する監視装置に接続されたデータを管理するサービスを提供するデータ管理装置の制御方法であって、
前記データ管理装置の状態管理手段が、自らが提供するサービスの状態を管理する状態管理工程と、
前記データ管理装置の通知手段が、定期的に前記サービスの状態を前記監視装置に通知する通知工程と、
前記データ管理装置の受付手段が、前記サービスを提供されるアプリケーションからのリクエストを受け付ける受付工程と、
前記データ管理装置の拒否手段が、前記受付工程にて受け付けた前記リクエストがデータの更新である場合に、前記状態管理工程にて管理している当該サービスの更新に係る状態が制限状態だった場合は更新のリクエストを拒否する拒否工程と
を有し、
前記状態管理工程では、
前記通知工程による通知が失敗した場合は、当該サービスの更新に係る状態を制限状態に遷移させ、
前記通知工程による通知が成功した場合は、当該サービスの更新に係る状態を更新のリクエストが拒否されない通常状態に遷移させる
ことを特徴とするデータ管理方法。
【請求項１２】
サービスの稼働状況を監視する監視装置及びデータを管理するデータ管理装置に接続され、前記データを複製するサービスを提供する複製装置の制御方法であって、
前記複製装置の状態管理手段が、自らが提供するサービスの状態を管理する状態管理工程と、
前記複製装置の通知手段が、定期的にサービスの稼働に係る状態を前記監視装置に通知する通知工程と、
前記複製装置の反映手段が、当該サービスの更新に係る状態が通常状態である場合に、前記データ管理装置が有する第二の記憶領域に記憶されている更新内容を、前記複製装置が有する第一の記憶領域に記憶されているデータに反映する反映工程と、
を有し、
前記状態管理工程では、
前記通知工程による通知が失敗した場合は、当該サービスの更新に係る状態を制限状態に遷移させ、
前記通知工程による通知が成功した場合は、当該サービスの更新に係る状態を更新のリクエストが拒否されない通常状態に遷移させることを特徴とする複製方法。
【請求項１３】
接続されたデータ管理装置が提供するサービスの稼働状況を監視する監視装置の制御方法であって、
前記監視装置の管理手段が、監視する前記サービスの稼働に係る状態を接続された前記装置からの通知に基づいて管理する管理工程と、
前記監視装置の判定手段が、前記管理工程にて保持している前記サービスの稼働に係る状態が稼働から中止へ遷移したか否かを判定する判定工程と、
前記監視装置のフェイルオーバー判定手段が、稼働に係る状態が稼働から中止へ遷移したと判定されたサービスに対し、フェイルオーバーに係る状態が禁止か否かを判定するフェイルオーバー判定工程と、
前記監視装置の中止手段が、前記フェイルオーバー判定工程にてフェイルオーバーが禁止であると判定された場合、稼働に係る状態が中止へ遷移した当該サービスを中止する中止工程と
を有する監視方法。
【請求項１４】
コンピュータを、
自らが提供するサービスの状態を管理する状態管理手段と、
定期的に前記サービスの状態を監視装置に通知する通知手段と、
前記サービスを提供されるアプリケーションからのリクエストを受け付ける受付手段と、
前記受付手段にて受け付けた前記リクエストがデータの更新である場合に、前記状態管理手段にて管理している当該サービスの更新に係る状態が制限状態だった場合は更新のリクエストを拒否する拒否手段と
して機能させ、
前記状態管理手段は、
前記通知手段による通知が失敗した場合は、当該サービスの更新に係る状態を制限状態に遷移させ、
前記通知手段による通知が成功した場合は、当該サービスの更新に係る状態を更新のリクエストが拒否されない通常状態に遷移させる
ことを特徴とするプログラム。
【請求項１５】
コンピュータを、
自らが提供するサービスの状態を管理する状態管理手段と、
定期的にサービスの稼働に係る状態を監視装置に通知する通知手段と、
当該サービスの更新に係る状態が通常状態である場合に、データ管理装置が有する第二の記憶領域に記憶されている更新内容を、複製装置が有する第一の記憶領域に記憶されているデータに反映する反映手段と、
して機能させ、
前記状態管理手段は、
前記通知手段による通知が失敗した場合は、当該サービスの更新に係る状態を制限状態に遷移させ、
前記通知手段による通知が成功した場合は、当該サービスの更新に係る状態を更新のリクエストが拒否されない通常状態に遷移させる
ことを特徴とするプログラム。
【請求項１６】
コンピュータを、
監視するサービスの稼働に係る状態を接続された装置からの通知に基づいて管理する管理手段と、
前記管理手段にて保持している前記サービスの稼働に係る状態が稼働から中止へ遷移したか否かを判定する判定手段と、
稼働に係る状態が稼働から中止へ遷移したと判定されたサービスに対し、フェイルオーバーに係る状態が禁止か否かを判定するフェイルオーバー判定手段と、
前記フェイルオーバー判定手段にてフェイルオーバーが禁止であると判定された場合、稼働に係る状態が中止へ遷移した当該サービスを中止する中止手段と
して機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、運用系および待機系の冗長化構成の情報処理装置、制御方法、及びプログラムを備えるクラスタシステムに関する。特に複数のノードでデータを分散管理しているクラスタシステムにおける冗長化構成の制御方法に関する。
【背景技術】
【０００２】
従来、複数のノードに負荷分散したクラスタシステムにおいて、運用系とは別に予備機として待機系のノードを備え、運用系がダウンした場合に待機系に対してフェイルオーバー処理を実現し、システムの稼働を継続するシステムが知られている。例えば、特許文献１では、負荷分散装置管理サーバにて運用系のノードへアクセスするための接続情報を管理し、各クライアントは接続情報を元に運用系のノードを特定しアクセスする。そして、負荷分散装置管理サーバは運用系のノードの状態を監視し、リソースが不足する場合は待機系のノードを運用系に切り替え接続情報を更新する事でフェイルオーバーを実現している。
【０００３】
一方、静的データ（以後、データベース）を保持するノードにおいて、フェイルオーバーを実現するための方法が知られている。例えば、特許文献２では、運用系ノードのデータベースのバックアップを待機系ノードで保持し、運用系ノードのデータベースの変更を随時待機系ノードに送信する。そして、運用系ノードの電源断等の障害が発生したときに、待機系のバックアップから復旧することでフェイルオーバーを実現している。
【０００４】
また、これらフェイルオーバーを実現するための構成において、システムの状況によっては運用系と待機系が双方とも運用系として稼働してしまう事が課題として知られている。この課題を解決するために、例えば、特許文献３では、運用系と待機系の相互通信のほかに、他のノードに対する通信も試みて自身が孤立しているか確認し、孤立でないと判断した場合にのみ接続を有効化することで課題解決している。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−２３５８３７号公報
【特許文献２】特開平０５−１９１４０９号公報
【特許文献３】特開２００４−１７１３７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来の技術では以下の二つの状況において容易にフェイルオーバー構成を実現できない課題がある。一に、運用系が複数台構成されている環境においては、待機系との相互通信が多岐にわたるため管理が困難である。また、台数が増える事によりネットワークも複雑になり、他のノードに対する通信のみでは、他のノード自体が孤立である場合などにより、自身を孤立であると判断する事が困難である。そのため、運用系と待機系が双方とも稼働してしまう可能性がある。特に、各ノードがデータを管理している場合は、運用系と待機系の双方から同一データの更新が行われ、データの一貫性が損なわれる可能性がある。二に、バックアップを保持している待機系と運用系との通信リンクが切断した場合はバックアップデータの更新ができず、フェイルオーバーを実施するとデータが失われ、データの一貫性が保たれないという課題がある。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、本発明は以下の構成を有する。複数のデータ管理装置と複数の複製装置と監視装置とを備えたクラスタシステムであって、前記データ管理装置は、自らが提供するサービスの状態を管理する状態管理手段と、定期的に前記サービスの状態を前記監視装置に通知する通知手段と、前記サービスを提供されるアプリケーションからのリクエストを受け付ける受付手段と、前記受付手段にて受け付けた前記リクエストがデータの更新である場合に、前記状態管理手段にて管理している当該サービスの更新に係る状態が制限状態だった場合は更新のリクエストを拒否する拒否手段とを有し、前記状態管理手段は、前記通知手段による通知が失敗した場合は、当該サービスの更新に係る状態を制限状態に遷移させ、前記通知手段による通知が成功した場合は、当該サービスの更新に係る状態を更新のリクエストが拒否されない通常状態に遷移させ、前記複製装置は、自らが提供するサービスの状態を管理する状態管理手段と、定期的にサービスの稼働に係る状態を前記監視装置に通知する通知手段と、当該サービスの更新に係る状態が通常状態である場合に、前記データ管理装置が有する第二の記憶領域に記憶されている更新内容を、前記複製装置が有する第一の記憶領域に記憶されているデータに反映する反映手段とを有し、前記監視装置は、監視する前記サービスの稼働に係る状態を接続された装置からの通知に基づいて管理する管理手段と、前記管理手段にて保持している前記サービスの稼働に係る状態が稼働から中止へ遷移したか否かを判定する判定手段と、稼働に係る状態が稼働から中止へ遷移したと判定されたサービスに対し、フェイルオーバーに係る状態が禁止か否かを判定するフェイルオーバー判定手段と、前記フェイルオーバー判定手段にてフェイルオーバーが禁止であると判定された場合、稼働に係る状態が中止へ遷移した当該サービスを中止する中止手段とを有する。
【発明の効果】
【０００８】
本発明によれば、以下の二つの状況においても容易にフェイルオーバー構成を実現することができる。一に、運用系が複数台で構成されるクラスタシステムにおいても、単一の監視サーバによる制御のみで運用系と待機系の双方が同一データを更新する状況を回避したフェイルオーバー処理を実現できる。二に、バックアップを保持しているサーバとの通信リンクが切断した場合に、フェイルオーバーが実行されてデータが失われてしまう事を回避する事ができる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態に係るネットワーク構成を示す図。
【図２】本実施形態に係るハードウェア構成を示す図。
【図３】本実施形態に係るＷｅｂブラウザ、Ｗｅｂサーバモジュールの構成を示す図。
【図４】本実施形態に係る文書管理サービスモジュールの構成を示す図。
【図５】本実施形態に係る監視サービスモジュールの構成を示す図。
【図６】本実施形態に係るレプリカサービスモジュールの構成を示す図。
【図７】本実施形態に係る管理表を示す図。
【図８】本実施形態に係るＷｅｂブラウザからのログイン処理のフローチャートの図。
【図９】本実施形態に係る文書操作処理のフローチャートの図。
【図１０】本実施形態に係る文書管理サービスにおける処理のフローチャートの図。
【図１１】本実施形態に係るレプリカサービスにおける処理のフローチャートの図。
【図１２】本実施形態に係る監視サービスにおける処理のフローチャートの図。
【図１３】本実施形態に係るフェイルオーバー処理のシーケンス図。
【発明を実施するための形態】
【００１０】
［システム構成］
以下、本発明を実施するための最良の形態について図面を用いて説明する。図１は、本発明の実施形態のシステム構成を示すブロック図である。図１中、ネットワーク１０は各構成要素を接続する。クライアント１１Ａ、１１ＢはＷｅｂサーバに対してリクエストを発行する。Ｗｅｂサーバ１２Ａ、１２Ｂはクライアントからのリクエストを受け付ける。また、文書管理サーバ１３Ａ、１３ＢはＷｅｂサーバで受け付けたリクエストを処理する稼働系のデータ管理装置であり、また文書管理サーバ１３Ｃは文書管理サーバ１３Ａ、１３Ｂに異常が発生した場合に処理を引き継ぐ待機系の文書管理サーバである。なお、それぞれの構成要素を包括的に表現する場合には、クライアント１１、Ｗｅｂサーバ１２、文書管理サーバ１３と記載する。また、ここではデータ管理装置にて管理するデータを文書データとして述べることとする。
【００１１】
また、監視サーバ１４は各サービスの稼働状況を監視し、後述するフェイルオーバー処理を行う。また、レプリカサーバ１５は各文書サーバが管理するデータベースのレプリカ（複製）を生成する。また、上記各構成要素はネットワーク１０により通信可能に接続されており、通信手段としては、ＨＴＴＰや、ＨＴＴＰ上のＳＯＡＰ、つまりＷｅｂサービスが用いられる他、ＴＣＰ／ＩＰによる相互通信を用いて行われる。
【００１２】
図２は、図１のクライアント１１、Ｗｅｂサーバ１２、文書管理サーバ１３、監視サーバ１４、あるいはレプリカサーバ１５のハードウェア構成を示すブロック図である。図２中、ＣＰＵ２１は内部バスで接続される各デバイス（後述のＲＯＭ２２、ＲＡＭ２３他）を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行する。ＲＯＭ２２には例えばＢＩＯＳ等のデータが格納してある。ＲＡＭ２３はＣＰＵ２１のワーク領域として利用されたり、本発明を実現するためのソフトウェアモジュールをロードするための一時記憶のための記憶領域として利用されたりする。ＨＤＤ２４は基本ソフトウェアであるＯＳやソフトウェアモジュールが記憶されているＨＤＤ（ハードディスクドライブ）、もしくはＳＳＤ（ソリッドステートドライブ）などの間接記憶装置である。入力装置２５はキーボードやポインティングデバイス（不図示）などを示す。出力装置２６はディスプレイ等を示している。Ｉ／Ｆ２７はネットワーク１０に接続するためのＩ／Ｆである。
【００１３】
これらハードウェアにおいて、起動後に、ＣＰＵ２１によりＲＯＭ２２に格納されているＢＩＯＳが実行され、ＯＳがＨＤＤ２４からＲＡＭ２３に実行可能にロードされる。ＣＰＵ２１はＯＳの動作に従って各種ソフトウェアモジュールをＨＤＤ２４からＲＡＭ２３に随時、実行可能にロードする。各種ソフトウェアモジュールは上記各デバイスの連携によりＣＰＵ２１によって実行され動作する。また、Ｉ／Ｆ２７はネットワーク１０に接続されており、ＯＳの動作に従ってＣＰＵ２１により制御され、上述した通信手段による通信を実現している。
【００１４】
［モジュール構成］
図３は、クライアント１１、およびＷｅｂサーバ１２上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図２で示したＨＤＤ２４に記憶されており、前述したようにＣＰＵ２１によってＲＡＭ２３にロードされ実行される。
【００１５】
ロードバランサ３０はクライアント１１からのリクエストを、複数のＷｅｂサーバ１２Ａ、１２Ｂに対して振り分け処理の負荷分散を実現する。クライアント１１、Ｗｅｂサーバ１２はこのロードバランサ３０を中継してネットワーク１０により相互通信可能に接続されている。クライアント１１はユーザインタフェースアプリケーションとしてＷｅｂブラウザ３１を備えている。また、Ｗｅｂサーバ１２はＷｅｂアプリケーションサーバ３２を備え、Ｗｅｂアプリケーションサーバ３２には、文書モニタアプリケーション３３がそれぞれデプロイされている。この文書モニタアプリケーション３３は、Ｗｅｂアプリケーションサーバ３２上でいわゆるＷｅｂアプリケーションとして構成されており、クライアント１１はＷｅｂブラウザ３１を介してアクセスする事が出来る。
【００１６】
文書モニタアプリケーション３３はＷｅｂブラウザ３１からのリクエストに対してユーザインタフェース情報を返答する。Ｗｅｂブラウザ３１は文書モニタアプリケーション３３から得られたユーザインタフェース情報をレンダリングし表示する。表示されたユーザインタフェース情報には、例えば、文書管理サービスが管理する文書情報一覧や、文書の操作をリクエストするためのインタフェース等が含まれている。文書モニタアプリケーション３３は、文書管理サービスに対して文書情報一覧の取得や、Ｗｅｂブラウザ３１からリクエストされた文書の操作をリクエストする。これら処理の詳細については後述する。
【００１７】
図４は、文書管理サーバ１３上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図２で示したＨＤＤ２４に記憶されており、前述したようにＣＰＵ２１によってＲＡＭ２３にロードされ実行される。文書管理サーバ１３は、文書管理に関する文書管理サービスを提供する。文書管理サービス４０は上述した文書モニタアプリケーション３３から各種処理に関するリクエストを受け付け、文書に対する各種処理を実行する。これにより、受付手段を実現する。文書管理サービス４０は、他のサービスとの通信を処理するインタフェース部４１０、受け付けたリクエストに従って処理を実行するロジック部４１１、文書データに対する処理を実行するデータ管理部４１２、自身が生存していることを定期的に通知するためのトリガである生存通知部４１３、および自身のサービス状態を管理する状態管理部４１４にて構成される。文書管理サービス４０はこれら各構成要素の連携により処理を実行する。
【００１８】
また、インタフェース部４１０は文書モニタアプリケーション３３および、監視サーバ１４と通信する。これにより、また、データ管理部４１２はレプリカサーバ１５と通信する。これら通信は、各ソフトウェアモジュールからの命令をＯＳが受け、ＯＳの動作に従って、図２におけるＣＰＵ２１によりＩ／Ｆ２７を介して実行される。また、データベース４２は文書データの情報を格納し、図２で示したＨＤＤ２４に記憶されている。
【００１９】
図５は、監視サーバ１４上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図２で示したＨＤＤ２４に記憶されており、前述したようにＣＰＵ２１によってＲＡＭ２３にロードされ実行される。監視サーバ１４は、装置内外のアプリケーションに対する稼働状況の監視に関する監視サービスを提供する。監視サービス５０は、文書管理サービス４０および、レプリカサーバ１５の稼働状態を監視し、各サービスの稼働状態によってフェイルオーバー等の処理を実行する。また監視サービス５０は、文書モニタアプリケーション３３からのリクエストを受け付け、文書管理サービス４０への接続情報を返答する。監視サービス５０は、他のサービスとの通信を処理するインタフェース部５１０、受け付けたリクエストに従って処理を実行するロジック部５１１、後述する各種管理表に対する処理を実行する表管理部５１２、および各サービスの生存状態を定期的に監視するためのトリガである生存監視部５１３にて構成される。監視サービス５０はこれら各構成要素の連携により処理を実行する。
【００２０】
また、インタフェース部５１０は上述した文書モニタアプリケーション３３、文書モニタアプリケーション３３、および後述するレプリカサーバ１５と通信する。これら通信は、各ソフトウェアモジュールからの命令をＯＳが受け、ＯＳの動作に従って、図２におけるＣＰＵ２１によりＩ／Ｆ２７を介して実行される。また、接続管理表５２は文書モニタアプリケーション３３が文書管理サービス４０との通信するための接続情報が格納されている。また、状態管理表５３は各サービスの状態が格納されている。これら管理表は図２で示したＨＤＤ２４に記憶されている。
【００２１】
図６は、レプリカサーバ１５上で動作するソフトウェアモジュールの構成図である。なお各ソフトウェアモジュールは図２で示したＨＤＤ２４に記憶されており、前述したようにＣＰＵ２１によってＲＡＭ２３にロードされ実行される。レプリカサーバ１５は、各種データの複製に関する複製サービスの提供を行う。レプリカサービス６０は、文書管理サービス４０で管理しているデータベース４２のレプリカを生成する。生成されたレプリカは後述するフェイルオーバー処理時に利用される。レプリカサービス６０は、監視サービス５０との通信を処理するインタフェース部６１０を備える。この通信は、インタフェース部６１０からの命令をＯＳが受け、ＯＳの動作に従って、図２におけるＣＰＵ２１によりＩ／Ｆ２７を介して実行される。また、監視サービス５０は受け付けたリクエストを処理するロジック部６１１、後述するレプリカ中間データおよびレプリカデータベースに対する処理を実行するデータ管理部６１２、自身が生存していることを定期的に通知するためのトリガである生存通知部６１３、および自身のサービス状態を管理する状態管理部６１４にて構成される。レプリカサービス６０はこれら各構成要素の連携により処理を実行する。
【００２２】
また、レプリカデータベース６２は文書管理サービス４０で管理しているデータベース４２のレプリカである。また、レプリカ中間データ６３はレプリカデータベース６２に反映されるまでのレプリカの中間データである。より具体的には、文書管理サーバ１３の文書管理サービス４０におけるデータ管理部４１２にて、データベース４２に対して行う処理がコマンドとして記録されている。このレプリカ中間データ６３は、ＯＳに仕組みにより他のサーバと共有可能な共有ファイル形式でＨＤＤ２４に記憶されており、文書管理サービス４０およびレプリカサービス６０の双方からアクセス可能に構成される。
【００２３】
［管理表］
図７（Ａ）は接続管理表５２のデータ構造を示す図である。接続管理表５２は、サービス情報７００および、データベース情報７１０によって構成される。サービス情報７００は、文書管理サービス４０およびレプリカサービス６０の情報が格納され管理される。サービス情報７００は、一例として、サービスの識別子であるサービスＩＤ７０１、サービスの種類を示すサービス種別７０２、サービスへの接続アドレスが格納される接続アドレス７０３、サービスへの接続ポート番号が格納される接続ポート７０４、およびサービスが管理するデータベースの格納パスであるローカルデータベース格納パス７０５で構成される。サービス種別７０２は、文書管理サービス４０か、もしくはレプリカサービス６０かを区別するための領域である。また、接続アドレス７０３は、たとえばＩＰアドレスやＦＱＤＮといった、サービスが稼働しているサーバをネットワーク１０内で一意に識別可能な情報が格納される。
【００２４】
データベース情報７１０は、データベースおよび該データベースのレプリカ情報が格納され管理される。データベース情報７１０は、データベースの識別子であるデータベースＩＤ７１１、該データベースを管理するサービスの識別子であるサービスＩＤ７１２、該データベースのレプリカを生成するレプリカサービスの識別子であるレプリカサービスＩＤ７１３、該データベースのレプリカ中間データを格納するパスであるレプリカ中間データ格納パス７１４、該データベースのレプリカが生成されるレプリカデータベース格納パス、および後述するフェイルオーバーの可否を示す状態を格納するフェイルオーバーモード７１６から構成される。また、サービスＩＤ７１２およびレプリカサービスＩＤ７１３は、サービス情報７００のサービスＩＤとリレーションしている。なお、ここで示した接続管理表の構成は一例であり、他の構成要素を有していてもよい。
【００２５】
図７（Ｂ）は状態管理表５３のデータ構造を示す図である。状態管理表５３は、上述したサービス情報７００および、ステータス情報８００によって構成される。ステータス情報８００は、文書管理サービス４０およびレプリカサービス６０の生存状況やステータスが格納され管理される。ステータス情報８００は、一例として、サービスの識別子であるサービスＩＤ８０１、サービスからの最新の生存通知を受け付けた日時を格納する最新通知日時８０２、サービスの稼働のステータス（状態）を格納する状態８０３、後述するレプリカをローカルに行っているか、もしくはリモートに行っているか、を格納するレプリカモード８０４から構成される。状態８０３には、運用中であることを示す「稼働」、待機系である事を示す「待機」、異常によってダウンした場合で、かつフェイルオーバーしていない事を示す「中止」、異常によってダウンし、フェイルオーバーされている事を示す「停止」、およびフェイルオーバー処理中で、稼働状態が遷移中である事を示す「処理中」、「稼働待ち」が存在する。各稼働状態の遷移については後述する。また、サービスＩＤ８０１はサービス情報７００のサービスＩＤとリレーションしている。なお、ここで示した状態管理表５３の構成は一例であり、他の構成要素を有してもよい。また、状態８０３にて示すステータス（状態）は上記に定義したものに限定されず、必要に応じて、追加／削除してもよい。
【００２６】
また、本実施形態において、様々な“状態”を扱うため、便宜上、更新に係るサービスの状態（通常モード、制御モード）を“サービス状態”、サービスの稼働に係る状態（稼働、中止等）を“稼働状態”、記憶（複製）に係る状態（ローカルレプリカモード、リモートレプリカモード）を“記憶状態”、フェイルオーバーに係る状態（フェイルオーバー許可、禁止）を“フェイルオーバー状態”と記載する。
【００２７】
［ログイン処理］
以下、本発明の各ソフトウェアモジュールにおける処理フローについてフローチャートを用いて説明する。図８は、Ｗｅｂサーバ１２における文書モニタアプリケーション３３が、クライアント１１におけるＷｅｂブラウザ３１からログインリクエストを受け付けたときの処理を示したフローチャートである。文書モニタアプリケーション３３は、Ｗｅｂサーバ１２のＲＡＭ２３にロードされ、ＣＰＵ２１により実行される事で、以下の各フローの処理が実行される。
【００２８】
文書モニタアプリケーション３３はＳ９０１にてＷｅｂブラウザ３１よりログインリクエストを受け付ける。ログイン方法としては、Ｆｏｒｍ認証、Ｂａｓｉｃ認証やＫｅｒｂｅｒｏｓ認証といったＷｅｂ標準の認証方式や独自方式の認証方法等、特に手段は問わない。次に、Ｓ９０２において、ログイン処理を行う。その際、ＬＤＡＰサーバ（不図示）等のディレクトリサーバへ問い合わせる方法や、独自のユーザ管理方式による承認を行ってもよい。次に、文書モニタアプリケーション３３は、Ｓ９０３にてログイン処理の成否を判定する。ログイン処理は、例えば管理されていないユーザのアクセスや、パスワードが不正な場合等では“失敗”となり、Ｓ９０４にてログイン失敗の旨をＷｅｂブラウザ３１へ応答し、処理を終了する。
【００２９】
ログイン処理が成功した場合は、Ｓ９０５にてデータベースＩＤ特定処理を行う。このデータベースＩＤ特定処理は、ログインしたユーザが参照可能な文書データが、どのデータベースにて管理されているか、を特定する処理である。方法としては、例えば、ユーザＩＤとデータベースＩＤの対応表を管理し関連付ける方法や、ユーザＩＤのハッシュ値とデータベースＩＤのハッシュ値をサークル上にマッピングし、値が最も近いデータベースＩＤにて管理する方法等が考えられる。これら方法は、どのようにデータベースを分割するか、によって変化する。本発明では、データベースは一まとまりのユーザ単位で分割され、ユーザＩＤのハッシュ値とデータベースＩＤのハッシュ値がサークル上にマッピングされている、つまりＣｏｎｓｉｓｔｅｎｔ  Ｈａｓｈ法によりマッピングされているものとする。なお、この方法に限定するものではなく、必要に応じて上記以外の方法を用いてもよい。
【００３０】
データベースＩＤが特定されたら、文書モニタアプリケーション３３はＳ９０６にて、監視サービス５０より、接続管理表５２が取得済みかを判定し、未取得の場合はＳ９０７にて監視サービス５０より接続管理表５２を取得する。次に文書モニタアプリケーション３３はＳ９０８にて特定したデータベースＩＤと取得した接続管理表５２とにより、情報を管理しているサービスを特定する。より具体的には、データベース情報７１０のデータベースＩＤ７１１より、サービスＩＤ７１２を特定し、サービスＩＤにてリレーションされているサービス情報７００の接続アドレス７０３、接続ポート７０４を取得する。次に、文書モニタアプリケーション３３はＳ９０９にて特定した文書管理サービスへ文書情報の参照をリクエストし、リクエスト結果をＳ９１０にて判定する。
【００３１】
リクエストが成功すると、Ｓ９１１にてログイン成功の旨と合わせて、参照した文書情報をＷｅｂブラウザ３１へ返却し処理を終了する。文書情報には例えば、文書を一意に特定する文書ＩＤ、文書名、文書の作成者、作成日付等の情報が含まれる。リクエストが失敗であった場合は、Ｓ９１２にて再度、監視サービス５０から接続管理表５２を取得する。これは、後述するフェイルオーバー処理や、文書管理サービス４０のダウン等を理由に、接続管理表５２が更新されている可能性があるためである。Ｓ９１３にて再取得した接続管理表５２に更新があったかを判定し、更新があった場合は、Ｓ９０８から同じ処理を繰り返し実行する。更新がない場合は、Ｓ９１４にてＷｅｂブラウザ３１にてログイン成功の旨と合わせて、文書参照失敗の旨をＷｅｂブラウザ３１に返答し処理を終了する。この際、所定の回数を定義しておき、Ｓ９０８からのフローを繰り返すリトライ処理を実行する事も可能である。以上の処理により、文書モニタアプリケーション３３はＷｅｂブラウザ３１からのログイン処理を実行する。
【００３２】
［文書操作処理］
図９は文書モニタアプリケーション３３から文書管理サービス４０に対して文書データの更新リクエストをした場合のフローチャートである。本フローチャートは、図８で説明したログイン処理はすでに行われている状態である。なお、文書モニタアプリケーション３３は、Ｗｅｂサーバ１２のＲＡＭ２３にロードされ、ＣＰＵ２１により実行される事で、以下の各フローの処理が実行される。また、文書モニタアプリケーション３３は、文書管理サーバ１３のＲＡＭ２３にロードされ、ＣＰＵ２１により実行される事で、以下の各フローの処理が実行される。なお、図９における破線の矢印は、文書モニタアプリケーション３３と文書管理サービス４０との間のリクエスト／レスポンスの送受信を示している。
【００３３】
文書モニタアプリケーション３３は、Ｓ１００１にてＷｅｂブラウザ３１からの文書更新のリクエストを受け付ける。リクエストには、文書を一意に特定する文書ＩＤおよび変更内容が含まれる。次にＳ１００２にてデータベースＩＤの特定処理行う。この処理は図８で説明したＳ９０５同様である。次に、文書モニタアプリケーション３３は、Ｓ１００３〜Ｓ１００９にて文書管理サービス４０に対するリクエスト処理を行う。これら処理は図８で説明したＳ９０８〜Ｓ９１４の処理のリクエスト内容および、Ｗｅｂブラウザ３１への応答内容が違うのみであり、処理ロジックは同等であるため説明は省略する。
【００３４】
次に、文書管理サービス４０にて、文書モニタアプリケーション３３より文書データの更新リクエストを受け付けた場合の処理について説明する。文書管理サービス４０はＳ１０１０にて文書モニタアプリケーション３３から文書データ更新リクエストを受け付ける。このリクエストには、文書を一意に特定する文書ＩＤ、更新内容、およびユーザＩＤが含まれる。次に、Ｓ１０１１にてデータベースＩＤ確認処理を行う。この処理は図８のＳ９０５のデータベース特定処理と同様の処理を行い、リクエストされたユーザＩＤに対応するデータを管理しているかを確認する。Ｓ１０１２にて確認結果を判定し、失敗した場合は、自身が保持しているデータベース情報７１０が古い可能性があるため、Ｓ１０１３にて監視サービス５０から最新の接続管理表５２を取得する。次に、取得した接続管理表５２が更新されている場合はＳ１０１１の処理を繰り返す。取得した接続管理表５２に更新がない場合は、リクエスト先が間違っているため、Ｓ１０１５にてリクエストの拒否を文書モニタアプリケーション３３に応答し、処理を終了する。
【００３５】
文書管理サービス４０はＳ１０１２にて確認結果が成功だった場合は、Ｓ１０１６にて自サービスのサービス状態を状態管理部４１４に確認する。ここでのサービス状態としては、「通常モード」で動作しているか「制限モード」で動作しているかが判定される。ここでの「通常モード」とは、各サービス等が制限なく動作可能である通常状態のモードを指し、「制限モード」とは、データベースの更新リクエストを受け付けない制限状態のモードを指す。Ｓ１０１６にて、「制限モード」だった場合は、更新系のリクエストは受け付けられないため、Ｓ１０１５に遷移する。一方、「通常モード」だった場合は、Ｓ１０１７にて文書データ更新のリクエストを受理し、文書データを更新する処理を行う。そして、文書管理サービス４０はＳ１０１８にて自サービスの記憶状態を確認する。これにより、記憶状態確認手段を実現する。ここでの記憶状態としては、レプリカサービス６０における記憶領域にレプリケーションを行っている「リモートレプリカモード」と自サービスが管理している記憶領域にレプリケーションを行っている「ローカルレプリカモード」がある。確認の結果、「リモートレプリカモード」だった場合、Ｓ１０１９にて接続管理表５２のレプリカ中間データ格納パス７１４を元に、中間データファイルに対して文書データを更新する内容を書き込む。Ｓ１０２０にて書き込み結果を判定し、成功した場合は、Ｓ１０２１にてデータベースの文書データの更新を実行し、文書モニタアプリケーション３３にリクエスト成功を応答して処理を終了する。中間データの書き込みに失敗した場合は、Ｓ１０２２にて自サービスの記憶状態を「ローカルレプリカモード」に遷移し、Ｓ１０２３にてローカル領域に中間データを記録し、Ｓ１０２１を実行する。
【００３６】
文書管理サービス４０がＳ１０１８にて、記憶状態の確認の結果、「ローカルレプリカモード」だった場合、Ｓ１０２４にて接続管理表５２のレプリカ中間データ格納パス７１４を元に、中間データファイルに対してアクセスを試みる。その結果、失敗した場合（リモートのレプリカサービスに記憶不可の場合）はＳ１０２３を実行する。成功した場合（リモートのレプリカサービスに記憶可能の場合）は、Ｓ１０２５にて今までローカル領域に記憶していたレプリカ中間データをリモートの中間データファイルにマージする。次に、Ｓ１０２６にて自サービスの記憶状態を「リモートレプリカモード」に遷移し、Ｓ１０２０を実行する。以降の処理については、すでに述べたとおりである。なお、記憶状態を遷移させて、レプリカモードとしての記憶状態を設定することにより、記憶領域設定手段を実現する。また、リモートレプリカモード時にレプリカサーバの記憶領域に記憶できたか否かの判定（Ｓ１０２０）を行うことにより、第一の記憶成否判定手段を実現する。更にローカルレプリカモード時にレプリカサーバの記憶領域に記憶できるか否かの判定（Ｓ１０２４）を行うことにより、第二の記憶成否判定手段を実現する。また、便宜上、レプリカサーバが有する記憶領域を第一の記憶領域、文書管理サーバが有する記憶領域を第二の記憶領域とも呼ぶ。
【００３７】
以上の処理により文書モニタアプリケーション３３から文書管理サービス４０に対して文書データの更新リクエストがあった場合に、条件によって、文書データの更新およびレプリカ中間データの記録が行われる。また、データベースのバックアップ先であるリモート領域との通信が失敗した場合においても、ローカル領域にレプリケーションすることで処理を継続する事が可能となる。ただし、ローカル領域にレプリケーションしている状況でフェイルオーバー処理が発生するとデータが消失する可能性がある。そのため、監視サービス５０は文書管理サービス４０の状態を把握してフェイルオーバー処理の実行可否を判定する。このフェイルオーバー処理の詳細については後述する。
【００３８】
［文書管理処理］
図１０は文書管理サービス４０から監視サービス５０への生存通知および、通知状況による状態遷移について説明したフローチャートである。なお、図９と同様に文書管理サービス４０は、文書管理サーバ１３のＲＡＭ２３にロードされ、ＣＰＵ２１により実行される事で、以下の各フローの処理が実行される。
【００３９】
文書管理サービス４０は定期的に起動するタイマーが設定されており、Ｓ１１０１における該タイマー起動をトリガに以下のフローを実行する。Ｓ１１０２において、監視サービス５０へ自サービスの生存通知を試みる。この際、自サービスの記憶状態を通知する。より具体的には、「リモートレプリカモード」であるか、「ローカルレプリカモード」であるか、が通知される。Ｓ１１０３にて該生存通知の成否によって処理を分岐する。生存通知が失敗した場合は、Ｓ１１０４にて、状態管理部４１４にて管理している自サービスのサービス状態を「制限モード」に遷移し、処理を終了する。生存通知が成功した場合は、Ｓ１１０５にて生存通知の応答として最新の接続管理表５２を監視サービス５０から取得する。また生存通知を受けた監視サービス５０は、ステータス情報８００の最新通知日時８０２に通知を受けた日時を記録する。次に、文書管理サービス４０はＳ１１０６にて、自サービスのサービス状態が「通常モード」なのか、「制限モード」なのかを判定し、「通常モード」である場合は処理を終了する。
【００４０】
「制限モード」だった場合は、Ｓ１１０７にて、状態管理部４１４にて管理している自サービスのサービス状態を「通常モード」に遷移する。次に、文書管理サービス４０は、Ｓ１１０８にて自サービスの記憶状態が「リモートレプリカモード」であるか、「ローカルレプリカモード」であるかを判定し、「リモートレプリカモード」である場合は処理を終了する。「ローカルレプリカモード」である場合は、Ｓ１１０９にて、Ｓ１１０５にて取得した最新の接続管理表５２を確認し、自サービスが管理していたデータベースが他のサービスにフェイルオーバーされているか、を確認する。フェイルオーバーされている場合は異常系であるため、Ｓ１１１０にてローカル領域に記憶しているレプリカ中間データを破棄し、処理を終了する。フェイルオーバーされていない場合は、Ｓ１１１１にてローカル領域に記憶しているレプリカ中間データをリモートの中間データファイルにマージし、Ｓ１１１２にて自サービスの記憶状態を「リモートレプリカモード」に遷移し処理を終了する。
【００４１】
以上の処理によって、文書管理サービス４０は、監視サービス５０に生存状態を通知し、通知状況によって自サービスの状態を遷移する。生存通知に失敗した場合は、自サービスを「制限モード」に遷移させ、管理しているデータベースの更新処理を受け付けないため、フェイルオーバー処理によって運用系と待機系の双方が運用系としてデータ更新を行ってしまう事を防ぐことができる。
【００４２】
［レプリカサービス処理］
図１１はレプリカサービス６０におけるレプリカ生成処理、および監視サービス５０への生存通知処理を示したフローチャートである。なお、レプリカサービス６０は、レプリカサーバ１５のＲＡＭ２３にロードされ、ＣＰＵ２１により実行される事で、以下の各フローの処理が実行される。レプリカサービス６０には定期的に起動するタイマーが設定されており、Ｓ１２０１における該タイマー起動をトリガに以下のフローを実行する。Ｓ１２０２にて、レプリカサービス６０は、自サービスのサービス状態が「通常モード」なのか「制限モード」なのかを状態管理部６１４に確認し、判定する。「制限モード」だった場合は処理を終了する。「通常モード」だった場合、Ｓ１２０３にて接続管理表５２を取得済みであるかを確認し、取得していない場合はＳ１２０４にて監視サービス５０から取得する。次に、Ｓ１２０５にて、レプリカを生成する対象のデータベースを特定する。より具体的には、取得した接続管理表５２のデータベース情報７１０におけるレプリカサービスＩＤ７１３と、自サービスのサービスＩＤが一致するデータベースＩＤを特定する。
【００４３】
次に、レプリカサービス６０はＳ１２０６にて特定したデータベースＩＤのレプリカ中間データ格納パス７１４およびレプリカデータベース格納パス７１５を取得する。そして、Ｓ１２０７にて、レプリカ中間データでレプリカデータベースを更新する。より具体的には、レプリカ中間データには文書管理サービス４０にてデータベースに対して実行されるコマンドが格納されており、レプリカサービス６０は、該コマンドをレプリカデータベースに実行する事でレプリケーションを行う。また、Ｓ１２１１に示すように、レプリカサービス６０は、監視サービス５０からのリクエストに応じてＳ１２０６の処理を実行する事が可能である。その際、リクエストにはデータベースＩＤが含まれている。Ｓ１２１１にて監視サービス５０からリクエストを受け付けた後、Ｓ１２０６に遷移し、以降の処理を実行する。
【００４４】
さらに、レプリカサービス６０には定期的に起動するタイマーが設定されており、Ｓ１２２１における該タイマー起動をトリガに以下のフローを実行する。このタイマーはＳ１２０１において利用されたタイマーと共用する構成も可能であるし、別タイマーとして構成する事も可能である。Ｓ１２２２にて、レプリカサービス６０は、監視サービス５０に生存通知を試みる。そしてＳ１２２３にて該生存通知の成否によって処理を分岐する。生存通知が成功した場合は、Ｓ１２２４にて、状態管理部６１４にて管理している自サービスの状態を「通常モード」に遷移し、処理を終了する。ここで生存通知を受けた監視サービス５０は、ステータス情報８００の最新通知日時８０２に通知を受けた日時を記録する。生存通知が失敗した場合は、Ｓ１２２５にて、状態管理部６１４にて管理している自サービスのサービス状態を「制限モード」に遷移し、処理を終了する。
【００４５】
以上の処理によりレプリカサービス６０は、監視サービス５０に生存状態を通知し、通知状況によって自サービスの状態を遷移する。生存通知に失敗した場合は、自サービスを「制限モード」に遷移させ、管理しているレプリカデータベースを更新しないため、フェイルオーバー処理によって運用系と待機系の双方が運用系としてレプリカデータの更新を行ってしまう事を防ぐことができる。
【００４６】
［監視サービス処理］
図１２は監視サービス５０における各サービスの状態管理のフローチャートである。監視サービス５０には定期的に起動するタイマーが設定されており、Ｓ１３０１における該タイマー起動をトリガに以下のフローを実行する。なお、監視サービス５０は、監視サーバ１４のＲＡＭ２３にロードされ、ＣＰＵ２１により実行される事で、以下の各フローの処理が実行される。
【００４７】
監視サービス５０は、Ｓ１３０２において状態管理表５３を確認する。そしてＳ１３０３においてサービスの状態遷移を確認し、以下の処理を実行する。稼働状態が「稼働」から「稼働」に遷移の場合（Ｓ１３０４）、より具体的には、状態管理表５３の状態８０３が「稼働」であって、最新通知日時８０２の日時が一定期間内である場合は処理を終了する。
【００４８】
サービスの稼働状態が「稼働」から「中止」に遷移した場合（Ｓ１３０５）、より具体的には、状態管理表５３の状態８０３が「稼働」であって、最新通知日時８０２の日時が一定期間を超えている場合は、Ｓ１３０６からＳ１３１２の処理を実行する。また、稼働状態が「中止」から「稼働」に遷移の場合（Ｓ１３２１）、より具体的には、状態管理表５３の状態８０３が「中止」であって、最新通知日時８０２の日時が一定時間内である場合は、Ｓ１３２２からＳ１３２６の処理を実行する。
【００４９】
続いて、状態管理表５３におけるサービスの稼働状態が「稼働」から「中止」に遷移した場合について説明する。監視サービス５０は、Ｓ１３０６において、中止に遷移したサービスがフェイルオーバー可能かを判定する。より具体的には、以下の二つの処理により判定する。一に、ＩＤにマッピングされている全てのデータベースのフェイルオーバー状態が、「フェイルオーバー禁止」であるか、「フェイルオーバー許可」であるか、を確認する。これにより、フェイルオーバー判定手段を実現する。より具体的には、データベース情報７１０のフェイルオーバーモード７１６を確認する。二に、中止に遷移したサービスのステータス情報８００におけるレプリカモード８０４を確認し、「ローカルレプリカモード」である場合は、「フェイルオーバー禁止」と判定する。該サービスが、「フェイルオーバー禁止」であるデータベースを管理している場合は、Ｓ１３１２において該サービスの稼働状態を「中止」に遷移し、処理を終了する。
【００５０】
該サービスが管理しているデータベースがすべて「フェイルオーバー許可」である場合は、Ｓ１３０７にて、同一サービス種別で、かつ、状態管理表５３において稼働状態が「待機」であるサービスが存在するかを判定する。これにより、待機サービス確認手段を実現する。「待機」サービスがある場合は、監視サービス５０はＳ１３０８にて後述するフェイルオーバー処理を実行し、Ｓ１３０９にて該サービスの稼働状態を「停止」に遷移し処理を終了する。すなわち、中止となったサービスから別の待機サービスへのフェイルオーバーが行われることとなる。なお、便宜上、稼働状態が「中止」に遷移したサービスを第一のサービス（例えば、第一の複製サービス）、稼働状態が「待機」であったサービスを第二のサービス（例えば、第二の複製サービス）とも呼ぶ。
【００５１】
「待機」サービスがない場合は、Ｓ１３１０にて該サービスのサービス種別がレプリカサービス６０であるかを判定し、レプリカサービスでない場合は、Ｓ１３１２にて該サービスの稼働状態を「中止」に遷移し処理を終了する。一方、該サービスのサービス種別がレプリカサービス６０であった場合は、Ｓ１３１１にて、レプリカサービス６０がマッピングされているデータベース（複製対象のデータベース）のフェイルオーバーモードを「フェイルオーバー禁止」に設定する。そして、Ｓ１３１２にてレプリカサービス６０に対する状態管理表５３の状態８０３を「中止」に遷移し処理を終了する。
【００５２】
続いて、状態管理表５３における状態８０３が「中止」から「稼働」に遷移した場合について説明する。監視サービス５０は、Ｓ１３２２にて該サービスの稼働状態を「稼働」に遷移する。続いて、Ｓ１３２３にて該サービスのサービス種別がレプリカサービス６０であるかを判定し、レプリカサービス６０でない場合は処理を終了する。該サービスがレプリカサービス６０である場合は、Ｓ１３２４にて、該レプリカサービスにマッピングされているデータベースのフェイルオーバーモードを「フェイルオーバー許可」に設定する。ここで、Ｓ１３２５にて「フェイルオーバー許可」に変更されたことによって、フェイルオーバー処理が発生するかを判定し、発生しない場合は処理を終了する。フェイルオーバー処理が発生する場合は、Ｓ１３２６にて後述するフェイルオーバー処理を実行し、処理を終了する。
【００５３】
以上の処理により、監視サービス５０はフェイルオーバー可能か判定し、ローカル領域にレプリケーションしている状況でフェイルオーバー処理が発生しデータが消失する課題を解決する。
【００５４】
［フェイルオーバー処理］
図１３は監視サービス５０にて行われるフェイルオーバー処理のシーケンスを示す図である。なお、各シーケンスにおける処理は各サービスが各サーバのＲＡＭ２３にロードされ、ＣＰＵ２１により実行される。なお、図１３で示したシーケンスは、監視サービス５０において、図１２におけるフローチャートのＳ１３０１〜Ｓ１３０７まで処理が実行された場合のＳ１３０８の処理を示している。
【００５５】
監視サービス５０は、シーケンスＳ１４０１にて状態管理表５３を確認する。これは、図１２におけるＳ１３０２の処理と同一処理である。結果、文書管理サービス４０Ａが「稼働」から「中止」に遷移し、待機サービスである文書管理サービス４０Ｂが存在するため、図１２におけるＳ１３０８のフェイルオーバー処理が実行される。監視サービス５０は、シーケンスＳ１４０２において、文書管理サービス４０Ａの稼働状態を「稼働」から「処理中」に遷移し、かつ、文書管理サービス４０Ｂの稼働状態を「待機」から「処理中」に遷移する。
【００５６】
続いて、監視サービス５０は、シーケンスＳ１４０３において、文書管理サービス４０Ａが管理するデータベースＩＤ指定で、レプリカサービス６０にレプリカデータベースの更新をリクエストする。レプリカサービス６０は、シーケンスＳ１４０４にて監視サービス５０からＩＤ指定を受け付け、レプリカデータベース６２を更新する。この処理は、図１１におけるＳ１２１１、Ｓ１２０６、Ｓ１２０７に対応する。
【００５７】
次に、Ｓ１４０５にて監視サービス５０は、更新されたレプリカデータベース６２を文書管理サービス４０Ｂが管理するデータベースへコピーする。続いて、監視サービス５０は、シーケンスＳ１４０６にて、文書管理サービス４０Ｂの稼働状態を「処理中」から「稼働待ち」に遷移し、シーケンスＳ１４０７にて文書管理サービス４０Ｂに対してサービスの開始をリクエストする。監視サービス５０から開始を指示された文書管理サービス４０Ｂは、起動処理を実行し、サービスの開始準備が整ったら監視サービス５０に対して生存通知を行う。この生存通知は、図１０におけるＳ１１０２での処理にあたる。
【００５８】
文書管理サービス４０Ｂから生存通知を受けた監視サービス５０は、シーケンスＳ１４０９にて文書管理サービス４０Ｂの稼働状態を「稼働待ち」から「稼働」へ変更する。さらに接続管理表５２のデータベース情報７１０のサービスＩＤを、文書管理サービス４０ＡのサービスＩＤから文書管理サービス４０ＢのサービスＩＤに変更する。変更後、文書管理サービス４０Ａの稼働状態を「処理中」から「停止」へ変更する。この処理は図１２でのＳ１３０９の処理にあたる。続いて監視サービス５０は、文書管理サービス４０Ｂに対し、生存通知の応答として最新の接続管理表を通知する。
【００５９】
以上の処理により、監視サービス５０は、フェイルオーバー処理を実行する。その後、文書モニタアプリケーション３３におけるＳ１４１１からＳ１４１７の処理が実行されるが、これは図８におけるＳ９０５乃至Ｓ９１４、および図９におけるＳ１００２乃至Ｓ１００９に対応する。
【００６０】
以上により、運用系が複数台で構成されるクラスタシステムにおいても、単一の監視サーバによる制御のみで運用系と待機系の双方が同一データを更新する状況を回避したフェイルオーバー処理を実現できる。また、バックアップを保持しているサーバとの通信リンクが切断した場合に、フェイルオーバーが実行されてデータが失われてしまう事を回避する事ができる。
【００６１】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2011138225.tif 000003
【図２】
2011138225.tif 000004
【図３】
2011138225.tif 000005
【図４】
2011138225.tif 000006
【図５】
2011138225.tif 000007
【図６】
2011138225.tif 000008
【図７】
2011138225.tif 000009
【図８】
2011138225.tif 000010
【図９】
2011138225.tif 000011
【図１０】
2011138225.tif 000012
【図１１】
2011138225.tif 000013
【図１２】
2011138225.tif 000014
【図１３】
2011138225.tif 000015