JP4141875B2 - リカバリ処理方法及びその実施システム並びにその処理プログラム - Google Patents
リカバリ処理方法及びその実施システム並びにその処理プログラム Download PDFInfo
- Publication number
- JP4141875B2 JP4141875B2 JP2003086897A JP2003086897A JP4141875B2 JP 4141875 B2 JP4141875 B2 JP 4141875B2 JP 2003086897 A JP2003086897 A JP 2003086897A JP 2003086897 A JP2003086897 A JP 2003086897A JP 4141875 B2 JP4141875 B2 JP 4141875B2
- Authority
- JP
- Japan
- Prior art keywords
- information processing
- recovery
- processing center
- center
- data
- 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 - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
- G06F11/1662—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit the resynchronized component or unit being a persistent storage device
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
Description
【０００１】
【発明の属する技術分野】
本発明はある情報処理センタで障害が発生した場合に他の情報処理センタでその処理をリカバリするリカバリ処理システムに適用して有効な技術に関するものである。
【０００２】
【従来の技術】
従来のリカバリシステム（システム回復の考慮されたリカバリシステム）では、金融機関のオンラインシステムの様に、データの更新時に同期してバックアップを取ることによってデータロスの無い、若しくは少ないリカバリ（システム回復）を行うものであった。
【０００３】
その一方、バックアップの取得を定期的（例えば１日に１回等）に行い、障害時にバックアップが取られていないデータについては（例えば手作業によって）別途入力することで回復すれば良いという比較的ルーズなリカバリシステムに対するニーズがある。例えば自治体の住民票データの様な、危急性が少なく更新頻度が低いデータを扱う場合がこれに相当し、従来技術ではこの様な場合にリカバリを行うシステム構成の決定等については手動で行っていた。
【０００４】
また従来のリカバリ処理において、コンピュータ作業負荷の高速リカバリおよび自動化を可能にする方法およびシステムについて、コンピュータ・システムと、関連するネットワーキングおよび周辺装置との要件を表現するステップと、カスタマがリカバリ命令を指定することを許容するステップと、リカバリ・サイトで前記リカバリ命令を処理するステップと、前記リカバリ命令を処理し、前記リカバリ・サイトで資源を割当てて前記コンピュータ・システムを再構成するためにコンピュータを使用するステップとを含むものが提案されており、システムの要件と利用可能な資産のマッチングを取ることで、自動的にリカバリ処理を行うことを実現している（例えば特許文献１参照）。
【０００５】
【特許文献１】
特開２００１−２６５７２６号公報
【０００６】
【発明が解決しようとする課題】
前記の様にリカバリシステムに対するニーズの中には比較的ルーズなものがあるが、従来のリカバリシステムはデータロスの無いリカバリを行うものである為、比較的ルーズなニーズを満たす場合であっても、データロスが無くコストの高いリカバリシステムを採用しなければならないという問題がある。
本発明の目的は上記問題を解決し、障害時にバックアップが取られていないデータについては別途入力することで回復すれば良いという比較的ルーズなリカバリに対するニーズに対応することが可能な技術を提供することにある。
【０００７】
【課題を解決するための手段】
本発明は、ある情報処理センタで障害が発生した場合に他の情報処理センタでその処理をリカバリするリカバリ処理システムにおいて、未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置によりリカバリ処理を行うものである。
【０００８】
本発明のリカバリ処理システムでは、まず、エンドユーザによって通常利用されている第１の情報処理センタのデータを所定の時間間隔で第２の情報処理センタで受信して前記データのバックアップを第２の情報処理センタに作成する処理を継続して行う。
【０００９】
そして、第１の情報処理センタで障害が発生し、エンドユーザによるアプリケーションの利用が第１の情報処理センタで行えなくなった場合には、未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置を第２の情報処理センタの情報処理装置の中から選択する。
【００１０】
前記の様にして第２の情報処理センタの情報処理装置の中から特定の情報処理装置が選択されると、その選択された情報処理装置に前記第１の情報処理センタで利用されていたアプリケーションをデプロイすると共に、第２の情報処理センタに作成されているバックアップデータを用いて前記第１の情報処理センタのデータをその選択された特定の情報処理装置に復元し、第２の情報処理センタで第１の情報処理センタの処理をリカバリする。
【００１１】
以上の様に本発明のリカバリ処理システムによれば、未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置によりリカバリ処理を行うので、障害時にバックアップが取られていないデータについては別途入力することで回復すれば良いという比較的ルーズなリカバリに対するニーズに対応することが可能である。
【００１２】
【発明の実施の形態】
以下にあるデータセンタ（ＤＣ）で障害が発生した場合に他のＤＣでその処理をリカバリする一実施形態のリカバリ処理システムについて説明する。
【００１３】
図１は本実施形態の東京ＤＣで障害が発生する前の通常時の運用を示す図である。図１に示す様に本実施形態のリカバリ処理システムでは、エンドユーザの用いる情報処理装置と、そのエンドユーザの情報処理装置によって通常利用される第１の情報処理センタである東京ＤＣと、東京ＤＣの障害時にそのリカバリを行う第２の情報処理センタである大阪ＤＣとをネットワークで接続しており、通常時にエンドユーザは東京ＤＣにおけるアプリケーション１１１及び１１２を利用している。
【００１４】
図２は本実施形態のＤＣ管理サーバ１４０の概略構成を示す図である。図２に示す様に本実施形態のＤＣ管理サーバ１４０は、ＣＰＵ２０１と、メモリ２０２と、磁気ディスク装置２０３と、入力装置２０４と、出力装置２０５と、ＣＤ−ＲＯＭ装置２０６と、通信装置２０７と、アプリケーション情報テーブル２０８と、サーバ一覧テーブル２０９と、ユーザ優先度テーブル２１０とを有している。
【００１５】
ＣＰＵ２０１は、ＤＣ管理サーバ１４０全体の動作を制御する装置である。メモリ２０２は、ＤＣ管理サーバ１４０全体の動作を制御する際にその為の各種処理プログラムやデータをロードする記憶装置である。
【００１６】
磁気ディスク装置２０３は、前記各種処理プログラムやデータを格納しておく記憶装置である。入力装置２０４は、東京ＤＣのリカバリを行う為の各種入力を行う装置である。出力装置２０５は、東京ＤＣのリカバリに伴う各種出力を行う装置である。
【００１７】
ＣＤ−ＲＯＭ装置２０６は、前記各種処理プログラムを記録したＣＤ−ＲＯＭの内容を読み出す装置である。通信装置２０７は、インターネットやイントラネット等のネットワークを介して東京ＤＣやエンドユーザ等の他の処理装置との通信を行う装置である。
【００１８】
アプリケーション情報テーブル２０８は、エンドユーザが利用するアプリケーションに関する情報を格納するテーブルである。サーバ一覧テーブル２０９は、リカバリに利用可能なサーバの一覧を格納したテーブルである。ユーザ優先度テーブル２１０は、ユーザの優先度を示す情報を格納するテーブルである。
【００１９】
またＤＣ管理サーバ１４０は、バックアップ作成処理部２１１と、サーバ選択処理部２１２と、復旧処理部２１３とを有している。
バックアップ作成処理部２１１は、エンドユーザによって通常利用される東京ＤＣのアプリケーションデータ１３０を所定の時間間隔で受信してアプリケーションデータ１３０のバックアップであるバックアップデータ１７０を大阪ＤＣに作成する処理部であり、後述する所要復旧時間が所定の復旧時間の要件を満たす様に前記バックアップの時間間隔を調整する処理部である。
【００２０】
サーバ選択処理部２１２は、東京ＤＣで障害が発生した場合に、前記東京ＤＣで利用されていたアプリケーション１１１及び１１２と同一のアプリケーションソフトウェアであるアプリケーション１５１及び１５２の大阪ＤＣでのデプロイに必要な時間と、大阪ＤＣでのバックアップデータ１７０によるデータの復元に必要な時間と、未バックアップデータの大阪ＤＣへの入力に必要な時間とを含む所要復旧時間が所定の復旧時間の要件を満たしているサーバを大阪ＤＣのサーバ１６１〜１６３の中から選択する情報処理装置選択処理部である。
【００２１】
復旧処理部２１３は、前記東京ＤＣで利用されていたアプリケーション１１１及び１１２と同一のアプリケーション１５１及び１５２を前記選択されたサーバにデプロイし、前記東京ＤＣのアプリケーションデータ１３０をバックアップデータ１７０から前記選択されたサーバに復元する処理部である。
【００２２】
ＤＣ管理サーバ１４０をバックアップ作成処理部２１１、サーバ選択処理部２１２及び復旧処理部２１３として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
なお、東京ＤＣがバックアップとなる場合には東京ＤＣのＤＣ管理サーバ１００がＤＣ管理サーバ１４０と同様の処理を行うものとする。
【００２３】
図３は本実施形態の通常時の東京ＤＣと大阪ＤＣの間のバックアップデータの転送を示す図である。図３に示す様にＤＣ管理サーバ１４０のバックアップ作成処理部２１１は、エンドユーザによって通常利用される東京ＤＣのアプリケーションデータ１３０を所定のデータ転送間隔で大阪ＤＣで受信してアプリケーションデータ１３０のバックアップであるバックアップデータ１７０を大阪ＤＣに作成する処理を行う。この際、大阪ＤＣにおけるＤＣ管理サーバ１４０のバックアップ作成処理部２１１は、東京ＤＣのＤＣ管理サーバ１００へ前記所定のデータ転送間隔でアプリケーションデータ１３０の転送要求を行うものとするが、前記所要復旧時間がアプリケーション情報テーブル２０８中の復旧時間の要件を満たす様に前記バックアップのデータ転送間隔を調整するものとしても良い。
【００２４】
図４は本実施形態の東京ＤＣで障害が発生したときの、大阪ＤＣでのリカバリ用サーバの選択、アプリケーションのデプロイ、バックアップデータによる復元の概要を示す図である。図４に示す様に本実施形態のリカバリ処理システムでは、東京ＤＣで障害が発生すると、大阪ＤＣでのサーバ１６１〜１６３からのリカバリ用サーバの選択、アプリケーション１５１及び１５２のデプロイ、バックアップデータ１７０によるアプリケーションデータ１３０の復元を行う。
【００２５】
図５は本実施形態のバックアップデータのリカバリ後の未バックアップデータの入力を示す図である。図５に示す様に本実施形態のリカバリ処理システムでは、東京ＤＣで障害が発生し、大阪ＤＣでバックアップデータ１７０によるアプリケーションデータ１３０の復元が行われた後、前回のバックアップから障害発生時までの間に東京ＤＣへ入力された未バックアップデータについて、エンドユーザの情報処理装置から大阪ＤＣへの入力が行われるものとしている。
【００２６】
図６は本実施形態のリカバリ完了後、エンドユーザが大阪ＤＣにシステムを切り替えて運用を続行する処理の概要を示す図である。図６に示す様に本実施形態のリカバリ処理システムでは、エンドユーザの情報処理装置から大阪ＤＣへの未バックアップデータの入力が終了し、大阪ＤＣでのリカバリが完了すると、エンドユーザの情報処理装置によるアプリケーションの利用を東京ＤＣから大阪ＤＣに切り替えてそのアプリケーションによる運用を続行する。
【００２７】
図７は本実施形態のリカバリに用いるサーバを選択する処理の処理手順を示すフローチャートである。図７に示す様にＤＣ管理サーバ１４０のサーバ選択処理部２１２は、東京ＤＣで障害が発生した場合に、前記東京ＤＣで利用されていたアプリケーション１１１及び１１２と同一のアプリケーションソフトウェアであるアプリケーション１５１及び１５２の大阪ＤＣでのデプロイに必要な時間と、大阪ＤＣでのバックアップデータ１７０によるデータの復元に必要な時間と、未バックアップデータの大阪ＤＣへの入力に必要な時間とを含む所要復旧時間が所定の復旧時間の要件を満たしているサーバを大阪ＤＣのサーバ１６１〜１６３の中から選択する処理を行う。
【００２８】
そしてＤＣ管理サーバ１４０の復旧処理部２１３は、前記東京ＤＣで利用されていたアプリケーション１１１及び１１２と同一のアプリケーション１５１及び１５２を前記選択されたサーバにデプロイし、前記東京ＤＣのアプリケーションデータ１３０をバックアップデータ１７０から前記選択されたサーバに復元する処理を行う。
【００２９】
図１の様にエンドユーザは、通常は東京ＤＣを利用しており、図３の様に東京ＤＣと大阪ＤＣの間ではバックアップとして所定の時間間隔でデータを転送している。その際、図４の様に東京ＤＣで障害が発生した場合、大阪ＤＣではリカバリに利用可能なサーバを選択してアプリケーションをデプロイし、バックアップからデータを復元する。
【００３０】
すなわち、まずステップ７０１でＤＣ管理サーバ１４０のサーバ選択処理部２１２は、アプリケーション情報テーブル２０８を参照し、東京ＤＣで利用されていたアプリケーションに対応するデータ発生頻度及びデータ転送間隔を読み出した後、それらの積を変数Ａに代入する。
【００３１】
図８は本実施形態のアプリケーション情報テーブル２０８の一例を示す図である。図８に示す様にアプリケーション情報テーブル２０８は、エンドユーザが利用するアプリケーションに関する情報を格納している。
【００３２】
図８において、入力時間はそのアプリケーションのデータ１件をエンドユーザの情報処理装置から入力するのに必要な時間であり、データ転送間隔は当該アプリケーションのアプリケーションデータ１３０のバックアップを作成する為のデータ転送の時間間隔、データ発生頻度は当該アプリケーションを利用する際に発生する単位時間当たりの更新データの件数、デプロイ時間はデプロイ時間比（後述）「１」の標準サーバにおいて当該アプリケーションをデプロイするのにかかる時間である。
【００３３】
また復旧時間の要件は障害発生からアプリケーション処理の復旧完了までにエンドユーザが許容可能な時間であり、サーバ選択処理部２１２は、アプリケーション処理の再開までに許容可能な時間の指定を当該アプリケーションのエンドユーザの情報処理装置から受け付けて、その受け付けた時間を前記復旧時間の要件としてアプリケーション情報テーブル２０８に設定しているものとする。
【００３４】
また優先度はそのエンドユーザが利用している複数のアプリケーションにおける各アプリケーションの優先度を示している。この他に任意の数の追加項目を持たせることも可能であり、例えば稼働中のアプリケーションが要求するサーバの性能情報等を持たせ、東京ＤＣの障害時にその性能情報を満たすサーバを選択するものとしても良い。
【００３５】
次にステップ７０２でサーバ選択処理部２１２は、アプリケーション情報テーブル２０８を参照し、東京ＤＣで利用されていたアプリケーションに対応するデータの入力時間を読み出して、その値を変数Ｂに代入する。
【００３６】
ステップ７０３では、サーバ一覧テーブル２０９を参照し、東京ＤＣで利用されていたアプリケーションを実行可能なサーバ、すなわち、サーバ一覧テーブル２０９中の用途に東京ＤＣで利用されていたアプリケーションの名称が示されているサーバのレコードを検索する。
【００３７】
図９は本実施形態のサーバ一覧テーブル２０９の一例を示す図である。図９に示す様にアプリケーション情報テーブル２０８は、そのＤＣでのリカバリ処理に利用可能なサーバ１６１〜１６３の一覧を格納している。
【００３８】
図９において、ＩＤはサーバ１６１〜１６３を識別する為のＤＣ内で一意な名前であり、用途は当該サーバで動作可能なアプリケーションのリストで、複数指定することが出来るものとする。
【００３９】
またデプロイ時間比は、アプリケーションをデプロイするのに必要な時間の標準サーバに対する相対値であり、アプリケーション情報テーブル２０８中の標準サーバのデプロイ時間にこの値を乗じたものが実際にそのサーバでアプリケーションをデプロイするのにかかる時間になる。
【００４０】
データ復元時間比は、バックアップデータ１７０を元にデータを復元するのに必要な時間の標準サーバに対する相対値であり、復元するバックアップデータ１７０のサイズに標準サーバの単位サイズ当たりの復元時間とこの値を乗じたものが実際にそのサーバでバックアップデータ１７０を復元するのにかかる時間になる。この他に任意の数の追加項目を持たせることも可能であり、例えばアプリケーション実行時のそのサーバの性能情報等を持たせ、東京ＤＣの障害時にアプリケーションの要求する性能情報を満たすサーバを選択する際の指標としても良い。
【００４１】
次にステップ７０４でサーバ選択処理部２１２は、アプリケーション情報テーブル２０８を参照し、東京ＤＣで利用されていたアプリケーションのデプロイ時間を読み出した後、ステップ７０３で検索されたサーバについて、そのデプロイ時間比をサーバ一覧テーブル２０９から読み出し、前記デプロイ時間とデプロイ時間比の積を変数Ｃに代入する。
【００４２】
ステップ７０５では、バックアップデータ１７０にアクセスして前記アプリケーションのバックアップデータサイズを取得した後、ステップ７０３で検索されたサーバのデータ復元時間比をサーバ一覧テーブル２０９から読み出し、前記バックアップデータサイズと標準サーバの単位サイズ当たりの復元時間とデータ復元時間比との積を変数Ｄに代入する。
【００４３】
ステップ７０６では、アプリケーション情報テーブル２０８を参照し、東京ＤＣで利用されていたアプリケーションに対応する復旧時間の要件を読み出した後、変数Ａの値と変数Ｂの値との積に変数Ｃの値と変数Ｄの値を加算した結果と、前記読み出した復旧時間の要件の値とを比較する。
【００４４】
ここで、変数Ａの値と変数Ｂの値との積は、データ転送間隔中に発生するデータを未バックアップデータとした場合に、その未バックアップデータを大阪ＤＣへ入力するのに必要な時間を表しており、変数Ｃの値は前記アプリケーションをそのサーバでデプロイするのに必要な時間、変数Ｄの値は前記アプリケーションのバックアップデータをそのサーバで復元するのに必要な時間を示している。なお、ステップ７０１で変数Ａの値を算出する際にデータ転送間隔の代わりに、前回のバックアップ実施時刻からの経過時間を用い、前回のバックアップからの経過時間中に発生するデータを未バックアップデータとしても良い。
【００４５】
ステップ７０６で調べた結果、前記加算結果が復旧時間の要件の値よりも小さい場合には、ステップ７０３で検索されたサーバを大阪ＤＣでのリカバリに用いるサーバとして選択して当該アプリケーションに対するサーバの選択処理を終了し、そうでない場合にはステップ７０３に戻って他のサーバを検索する。
【００４６】
また、東京ＤＣで利用されていたアプリケーションが複数である場合には、同様にステップ７０１からステップ７０６までの処理を繰り返し、前記選択されたサーバを除くサーバの中からリカバリに用いるサーバを選択する。
【００４７】
その後、前記の様にして選択されたサーバにアプリケーションをデプロイし、バックアップからデータを復元した後、図５の様に未バックアップデータを入力し、図６の様にエンドユーザは大阪ＤＣに切り替えて運用を続ける。
【００４８】
前記の様に本実施形態では、バックアップの作成されていない未バックアップデータの入力に必要な時間を見込んだ所要復旧時間が所定の復旧時間の要件を満たしているサーバを選択してリカバリ処理を行うので、例えば自治体の住民票データの様な危急性が少なく更新頻度が低いデータを扱う場合等、障害時にバックアップが取られていないデータについては、手作業等によって別途入力することで回復すれば良いという比較的ルーズなリカバリ処理に対応することが可能であり、コストの低いリカバリサービスを提供することができる。
【００４９】
次に、本実施形態のリカバリ処理システムにおいて、前記エンドユーザが複数である場合に、アプリケーションの優先度またはエンドユーザの優先度の高いものから順に前記大阪ＤＣのサーバ１６１〜１６３の選択を行う処理について説明する。
【００５０】
図１０は本実施形態の複数エンドユーザが東京ＤＣを利用している場合の通常時の運用を示す図である。図１０に示す場合では、エンドユーザＡ及びＢの用いる各情報処理装置と、東京ＤＣと、大阪ＤＣとをネットワークで接続している。エンドユーザＡ及びＢは、通常、東京ＤＣにおける複数のアプリケーションを利用しており、大阪ＤＣにバックアップデータを所定の時間間隔で転送している。
【００５１】
この際、東京ＤＣで障害が発生すると、大阪ＤＣのサーバ選択処理部２１２は、東京ＤＣで利用されていた複数のアプリケーション間の優先度の違いを計算する。その際の計算のパラメータとして、アプリケーション情報テーブル２０８中の優先度（あるエンドユーザの利用しているアプリケーションの優先度）及びユーザ優先度テーブル２１０中の優先度（ＤＣを利用しているエンドユーザの優先度）を用いることで、ＤＣ内でリカバリする際の各アプリケーションの優先順位を決定する。
【００５２】
図１１は本実施形態のユーザ優先度テーブル２１０の一例を示す図である。図１１に示す様にユーザ優先度テーブル２１０は、そのユーザの優先度を示す情報を格納しており、このテーブルの優先度の値と、アプリケーション情報テーブル２０８中の優先度の値を用いることで、ＤＣ内での各アプリケーションの優先順位を決定する。
【００５３】
例えば「エンドユーザの利用しているアプリケーションの優先度×そのエンドユーザの優先度」によってそのアプリケーションを大阪ＤＣでリカバリする際の優先順位を決定することが出来るが、それ以外の計算方法もあり得る。また、サーバ一覧テーブル２０９を用いず、各ユーザのアプリケーション情報テーブル２０８の優先度に、ＤＣ内でリカバリする際の各アプリケーションの優先度を直接格納する方法もあり得る。
【００５４】
そして、前記決定した優先度の高いものから順に、図７のサーバの選択処理を実行することで、優先度付きのディザスタリカバリを実現することが出来る。この様にして、実際にリカバリを行った場合の結果例を図１２に示す。
【００５５】
図１２は本実施形態の複数エンドユーザが東京ＤＣを利用しており、東京ＤＣで障害が発生した場合に大阪ＤＣでリカバリを行った際の結果例を示す図である。図１２では、エンドユーザＡよりもエンドユーザＢの方が優先度が高く、またエンドユーザＡの利用するアプリケーションＡ１の方がアプリケーションＡ２よりも優先度が高い場合の例を表しており、これらの優先度の為、サーバが足りない大阪ＤＣではアプリケーションＡ２がリカバリされていない。
【００５６】
前記の様に本実施形態のリカバリ処理システムでは、障害時には優先度の低いアプリケーションについてはリカバリせず、障害の発生した東京ＤＣの復旧を待つといった比較的ルーズなリカバリに対するニーズに対応することが可能である。
【００５７】
また本実施形態のリカバリ処理システムにおいて、前記の様にしてリカバリされないアプリケーションが発生した場合に、そのアプリケーションの情報を他のＤＣへ通知して、リカバリ可能であるかをそのＤＣのＤＣ管理サーバに問い合わせ、リカバリ可能である場合には、そのＤＣへ当該アプリケーションのバックアップデータを転送してリカバリを行うものとしても良い。
【００５８】
以上説明した様に本実施形態のリカバリ処理システムによれば、未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置によりリカバリ処理を行うので、障害時にバックアップが取られていないデータについては別途入力することで回復すれば良いという比較的ルーズなリカバリに対するニーズに対応することが可能である。
【００５９】
【発明の効果】
本発明によれば未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置によりリカバリ処理を行うので、障害時にバックアップが取られていないデータについては別途入力することで回復すれば良いという比較的ルーズなリカバリに対するニーズに対応することが可能である。
【図面の簡単な説明】
【図１】本実施形態の東京ＤＣで障害が発生する前の通常時の運用を示す図である。
【図２】本実施形態のＤＣ管理サーバ１４０の概略構成を示す図である。
【図３】本実施形態の通常時の東京ＤＣと大阪ＤＣの間のバックアップデータの転送を示す図である。
【図４】本実施形態の東京ＤＣで障害が発生したときの、大阪ＤＣでのリカバリ用サーバの選択、アプリケーションのデプロイ、バックアップデータによる復元の概要を示す図である。
【図５】本実施形態のバックアップデータのリカバリ後の未バックアップデータの入力を示す図である。
【図６】本実施形態のリカバリ完了後、エンドユーザが大阪ＤＣにシステムを切り替えて運用を続行する処理の概要を示す図である。
【図７】本実施形態のリカバリに用いるサーバを選択する処理の処理手順を示すフローチャートである。
【図８】本実施形態のアプリケーション情報テーブル２０８の一例を示す図である。
【図９】本実施形態のサーバ一覧テーブル２０９の一例を示す図である。
【図１０】本実施形態の複数エンドユーザが東京ＤＣを利用している場合の通常時の運用を示す図である。
【図１１】本実施形態のユーザ優先度テーブル２１０の一例を示す図である。
【図１２】本実施形態の複数エンドユーザが東京ＤＣを利用しており、東京ＤＣで障害が発生した場合に大阪ＤＣでリカバリを行った際の結果例を示す図である。
【符号の説明】
１００…ＤＣ管理サーバ、１１０…リポジトリ、１１１及び１１２…アプリケーション、１２１〜１２３…サーバ、１３０…アプリケーションデータ、１４０…ＤＣ管理サーバ、１５０…リポジトリ、１５１及び１５２…アプリケーション、１６１〜１６３…サーバ、１７０…バックアップデータ、２０１…ＣＰＵ、２０２…メモリ、２０３…磁気ディスク装置、２０４…入力装置、２０５…出力装置、２０６…ＣＤ−ＲＯＭ装置、２０７…通信装置、２０８…アプリケーション情報テーブル、２０９…サーバ一覧テーブル、２１０…ユーザ優先度テーブル、２１１…バックアップ作成処理部、２１２…サーバ選択処理部、２１３…復旧処理部。
【発明の属する技術分野】
本発明はある情報処理センタで障害が発生した場合に他の情報処理センタでその処理をリカバリするリカバリ処理システムに適用して有効な技術に関するものである。
【０００２】
【従来の技術】
従来のリカバリシステム（システム回復の考慮されたリカバリシステム）では、金融機関のオンラインシステムの様に、データの更新時に同期してバックアップを取ることによってデータロスの無い、若しくは少ないリカバリ（システム回復）を行うものであった。
【０００３】
その一方、バックアップの取得を定期的（例えば１日に１回等）に行い、障害時にバックアップが取られていないデータについては（例えば手作業によって）別途入力することで回復すれば良いという比較的ルーズなリカバリシステムに対するニーズがある。例えば自治体の住民票データの様な、危急性が少なく更新頻度が低いデータを扱う場合がこれに相当し、従来技術ではこの様な場合にリカバリを行うシステム構成の決定等については手動で行っていた。
【０００４】
また従来のリカバリ処理において、コンピュータ作業負荷の高速リカバリおよび自動化を可能にする方法およびシステムについて、コンピュータ・システムと、関連するネットワーキングおよび周辺装置との要件を表現するステップと、カスタマがリカバリ命令を指定することを許容するステップと、リカバリ・サイトで前記リカバリ命令を処理するステップと、前記リカバリ命令を処理し、前記リカバリ・サイトで資源を割当てて前記コンピュータ・システムを再構成するためにコンピュータを使用するステップとを含むものが提案されており、システムの要件と利用可能な資産のマッチングを取ることで、自動的にリカバリ処理を行うことを実現している（例えば特許文献１参照）。
【０００５】
【特許文献１】
特開２００１−２６５７２６号公報
【０００６】
【発明が解決しようとする課題】
前記の様にリカバリシステムに対するニーズの中には比較的ルーズなものがあるが、従来のリカバリシステムはデータロスの無いリカバリを行うものである為、比較的ルーズなニーズを満たす場合であっても、データロスが無くコストの高いリカバリシステムを採用しなければならないという問題がある。
本発明の目的は上記問題を解決し、障害時にバックアップが取られていないデータについては別途入力することで回復すれば良いという比較的ルーズなリカバリに対するニーズに対応することが可能な技術を提供することにある。
【０００７】
【課題を解決するための手段】
本発明は、ある情報処理センタで障害が発生した場合に他の情報処理センタでその処理をリカバリするリカバリ処理システムにおいて、未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置によりリカバリ処理を行うものである。
【０００８】
本発明のリカバリ処理システムでは、まず、エンドユーザによって通常利用されている第１の情報処理センタのデータを所定の時間間隔で第２の情報処理センタで受信して前記データのバックアップを第２の情報処理センタに作成する処理を継続して行う。
【０００９】
そして、第１の情報処理センタで障害が発生し、エンドユーザによるアプリケーションの利用が第１の情報処理センタで行えなくなった場合には、未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置を第２の情報処理センタの情報処理装置の中から選択する。
【００１０】
前記の様にして第２の情報処理センタの情報処理装置の中から特定の情報処理装置が選択されると、その選択された情報処理装置に前記第１の情報処理センタで利用されていたアプリケーションをデプロイすると共に、第２の情報処理センタに作成されているバックアップデータを用いて前記第１の情報処理センタのデータをその選択された特定の情報処理装置に復元し、第２の情報処理センタで第１の情報処理センタの処理をリカバリする。
【００１１】
以上の様に本発明のリカバリ処理システムによれば、未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置によりリカバリ処理を行うので、障害時にバックアップが取られていないデータについては別途入力することで回復すれば良いという比較的ルーズなリカバリに対するニーズに対応することが可能である。
【００１２】
【発明の実施の形態】
以下にあるデータセンタ（ＤＣ）で障害が発生した場合に他のＤＣでその処理をリカバリする一実施形態のリカバリ処理システムについて説明する。
【００１３】
図１は本実施形態の東京ＤＣで障害が発生する前の通常時の運用を示す図である。図１に示す様に本実施形態のリカバリ処理システムでは、エンドユーザの用いる情報処理装置と、そのエンドユーザの情報処理装置によって通常利用される第１の情報処理センタである東京ＤＣと、東京ＤＣの障害時にそのリカバリを行う第２の情報処理センタである大阪ＤＣとをネットワークで接続しており、通常時にエンドユーザは東京ＤＣにおけるアプリケーション１１１及び１１２を利用している。
【００１４】
図２は本実施形態のＤＣ管理サーバ１４０の概略構成を示す図である。図２に示す様に本実施形態のＤＣ管理サーバ１４０は、ＣＰＵ２０１と、メモリ２０２と、磁気ディスク装置２０３と、入力装置２０４と、出力装置２０５と、ＣＤ−ＲＯＭ装置２０６と、通信装置２０７と、アプリケーション情報テーブル２０８と、サーバ一覧テーブル２０９と、ユーザ優先度テーブル２１０とを有している。
【００１５】
ＣＰＵ２０１は、ＤＣ管理サーバ１４０全体の動作を制御する装置である。メモリ２０２は、ＤＣ管理サーバ１４０全体の動作を制御する際にその為の各種処理プログラムやデータをロードする記憶装置である。
【００１６】
磁気ディスク装置２０３は、前記各種処理プログラムやデータを格納しておく記憶装置である。入力装置２０４は、東京ＤＣのリカバリを行う為の各種入力を行う装置である。出力装置２０５は、東京ＤＣのリカバリに伴う各種出力を行う装置である。
【００１７】
ＣＤ−ＲＯＭ装置２０６は、前記各種処理プログラムを記録したＣＤ−ＲＯＭの内容を読み出す装置である。通信装置２０７は、インターネットやイントラネット等のネットワークを介して東京ＤＣやエンドユーザ等の他の処理装置との通信を行う装置である。
【００１８】
アプリケーション情報テーブル２０８は、エンドユーザが利用するアプリケーションに関する情報を格納するテーブルである。サーバ一覧テーブル２０９は、リカバリに利用可能なサーバの一覧を格納したテーブルである。ユーザ優先度テーブル２１０は、ユーザの優先度を示す情報を格納するテーブルである。
【００１９】
またＤＣ管理サーバ１４０は、バックアップ作成処理部２１１と、サーバ選択処理部２１２と、復旧処理部２１３とを有している。
バックアップ作成処理部２１１は、エンドユーザによって通常利用される東京ＤＣのアプリケーションデータ１３０を所定の時間間隔で受信してアプリケーションデータ１３０のバックアップであるバックアップデータ１７０を大阪ＤＣに作成する処理部であり、後述する所要復旧時間が所定の復旧時間の要件を満たす様に前記バックアップの時間間隔を調整する処理部である。
【００２０】
サーバ選択処理部２１２は、東京ＤＣで障害が発生した場合に、前記東京ＤＣで利用されていたアプリケーション１１１及び１１２と同一のアプリケーションソフトウェアであるアプリケーション１５１及び１５２の大阪ＤＣでのデプロイに必要な時間と、大阪ＤＣでのバックアップデータ１７０によるデータの復元に必要な時間と、未バックアップデータの大阪ＤＣへの入力に必要な時間とを含む所要復旧時間が所定の復旧時間の要件を満たしているサーバを大阪ＤＣのサーバ１６１〜１６３の中から選択する情報処理装置選択処理部である。
【００２１】
復旧処理部２１３は、前記東京ＤＣで利用されていたアプリケーション１１１及び１１２と同一のアプリケーション１５１及び１５２を前記選択されたサーバにデプロイし、前記東京ＤＣのアプリケーションデータ１３０をバックアップデータ１７０から前記選択されたサーバに復元する処理部である。
【００２２】
ＤＣ管理サーバ１４０をバックアップ作成処理部２１１、サーバ選択処理部２１２及び復旧処理部２１３として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
なお、東京ＤＣがバックアップとなる場合には東京ＤＣのＤＣ管理サーバ１００がＤＣ管理サーバ１４０と同様の処理を行うものとする。
【００２３】
図３は本実施形態の通常時の東京ＤＣと大阪ＤＣの間のバックアップデータの転送を示す図である。図３に示す様にＤＣ管理サーバ１４０のバックアップ作成処理部２１１は、エンドユーザによって通常利用される東京ＤＣのアプリケーションデータ１３０を所定のデータ転送間隔で大阪ＤＣで受信してアプリケーションデータ１３０のバックアップであるバックアップデータ１７０を大阪ＤＣに作成する処理を行う。この際、大阪ＤＣにおけるＤＣ管理サーバ１４０のバックアップ作成処理部２１１は、東京ＤＣのＤＣ管理サーバ１００へ前記所定のデータ転送間隔でアプリケーションデータ１３０の転送要求を行うものとするが、前記所要復旧時間がアプリケーション情報テーブル２０８中の復旧時間の要件を満たす様に前記バックアップのデータ転送間隔を調整するものとしても良い。
【００２４】
図４は本実施形態の東京ＤＣで障害が発生したときの、大阪ＤＣでのリカバリ用サーバの選択、アプリケーションのデプロイ、バックアップデータによる復元の概要を示す図である。図４に示す様に本実施形態のリカバリ処理システムでは、東京ＤＣで障害が発生すると、大阪ＤＣでのサーバ１６１〜１６３からのリカバリ用サーバの選択、アプリケーション１５１及び１５２のデプロイ、バックアップデータ１７０によるアプリケーションデータ１３０の復元を行う。
【００２５】
図５は本実施形態のバックアップデータのリカバリ後の未バックアップデータの入力を示す図である。図５に示す様に本実施形態のリカバリ処理システムでは、東京ＤＣで障害が発生し、大阪ＤＣでバックアップデータ１７０によるアプリケーションデータ１３０の復元が行われた後、前回のバックアップから障害発生時までの間に東京ＤＣへ入力された未バックアップデータについて、エンドユーザの情報処理装置から大阪ＤＣへの入力が行われるものとしている。
【００２６】
図６は本実施形態のリカバリ完了後、エンドユーザが大阪ＤＣにシステムを切り替えて運用を続行する処理の概要を示す図である。図６に示す様に本実施形態のリカバリ処理システムでは、エンドユーザの情報処理装置から大阪ＤＣへの未バックアップデータの入力が終了し、大阪ＤＣでのリカバリが完了すると、エンドユーザの情報処理装置によるアプリケーションの利用を東京ＤＣから大阪ＤＣに切り替えてそのアプリケーションによる運用を続行する。
【００２７】
図７は本実施形態のリカバリに用いるサーバを選択する処理の処理手順を示すフローチャートである。図７に示す様にＤＣ管理サーバ１４０のサーバ選択処理部２１２は、東京ＤＣで障害が発生した場合に、前記東京ＤＣで利用されていたアプリケーション１１１及び１１２と同一のアプリケーションソフトウェアであるアプリケーション１５１及び１５２の大阪ＤＣでのデプロイに必要な時間と、大阪ＤＣでのバックアップデータ１７０によるデータの復元に必要な時間と、未バックアップデータの大阪ＤＣへの入力に必要な時間とを含む所要復旧時間が所定の復旧時間の要件を満たしているサーバを大阪ＤＣのサーバ１６１〜１６３の中から選択する処理を行う。
【００２８】
そしてＤＣ管理サーバ１４０の復旧処理部２１３は、前記東京ＤＣで利用されていたアプリケーション１１１及び１１２と同一のアプリケーション１５１及び１５２を前記選択されたサーバにデプロイし、前記東京ＤＣのアプリケーションデータ１３０をバックアップデータ１７０から前記選択されたサーバに復元する処理を行う。
【００２９】
図１の様にエンドユーザは、通常は東京ＤＣを利用しており、図３の様に東京ＤＣと大阪ＤＣの間ではバックアップとして所定の時間間隔でデータを転送している。その際、図４の様に東京ＤＣで障害が発生した場合、大阪ＤＣではリカバリに利用可能なサーバを選択してアプリケーションをデプロイし、バックアップからデータを復元する。
【００３０】
すなわち、まずステップ７０１でＤＣ管理サーバ１４０のサーバ選択処理部２１２は、アプリケーション情報テーブル２０８を参照し、東京ＤＣで利用されていたアプリケーションに対応するデータ発生頻度及びデータ転送間隔を読み出した後、それらの積を変数Ａに代入する。
【００３１】
図８は本実施形態のアプリケーション情報テーブル２０８の一例を示す図である。図８に示す様にアプリケーション情報テーブル２０８は、エンドユーザが利用するアプリケーションに関する情報を格納している。
【００３２】
図８において、入力時間はそのアプリケーションのデータ１件をエンドユーザの情報処理装置から入力するのに必要な時間であり、データ転送間隔は当該アプリケーションのアプリケーションデータ１３０のバックアップを作成する為のデータ転送の時間間隔、データ発生頻度は当該アプリケーションを利用する際に発生する単位時間当たりの更新データの件数、デプロイ時間はデプロイ時間比（後述）「１」の標準サーバにおいて当該アプリケーションをデプロイするのにかかる時間である。
【００３３】
また復旧時間の要件は障害発生からアプリケーション処理の復旧完了までにエンドユーザが許容可能な時間であり、サーバ選択処理部２１２は、アプリケーション処理の再開までに許容可能な時間の指定を当該アプリケーションのエンドユーザの情報処理装置から受け付けて、その受け付けた時間を前記復旧時間の要件としてアプリケーション情報テーブル２０８に設定しているものとする。
【００３４】
また優先度はそのエンドユーザが利用している複数のアプリケーションにおける各アプリケーションの優先度を示している。この他に任意の数の追加項目を持たせることも可能であり、例えば稼働中のアプリケーションが要求するサーバの性能情報等を持たせ、東京ＤＣの障害時にその性能情報を満たすサーバを選択するものとしても良い。
【００３５】
次にステップ７０２でサーバ選択処理部２１２は、アプリケーション情報テーブル２０８を参照し、東京ＤＣで利用されていたアプリケーションに対応するデータの入力時間を読み出して、その値を変数Ｂに代入する。
【００３６】
ステップ７０３では、サーバ一覧テーブル２０９を参照し、東京ＤＣで利用されていたアプリケーションを実行可能なサーバ、すなわち、サーバ一覧テーブル２０９中の用途に東京ＤＣで利用されていたアプリケーションの名称が示されているサーバのレコードを検索する。
【００３７】
図９は本実施形態のサーバ一覧テーブル２０９の一例を示す図である。図９に示す様にアプリケーション情報テーブル２０８は、そのＤＣでのリカバリ処理に利用可能なサーバ１６１〜１６３の一覧を格納している。
【００３８】
図９において、ＩＤはサーバ１６１〜１６３を識別する為のＤＣ内で一意な名前であり、用途は当該サーバで動作可能なアプリケーションのリストで、複数指定することが出来るものとする。
【００３９】
またデプロイ時間比は、アプリケーションをデプロイするのに必要な時間の標準サーバに対する相対値であり、アプリケーション情報テーブル２０８中の標準サーバのデプロイ時間にこの値を乗じたものが実際にそのサーバでアプリケーションをデプロイするのにかかる時間になる。
【００４０】
データ復元時間比は、バックアップデータ１７０を元にデータを復元するのに必要な時間の標準サーバに対する相対値であり、復元するバックアップデータ１７０のサイズに標準サーバの単位サイズ当たりの復元時間とこの値を乗じたものが実際にそのサーバでバックアップデータ１７０を復元するのにかかる時間になる。この他に任意の数の追加項目を持たせることも可能であり、例えばアプリケーション実行時のそのサーバの性能情報等を持たせ、東京ＤＣの障害時にアプリケーションの要求する性能情報を満たすサーバを選択する際の指標としても良い。
【００４１】
次にステップ７０４でサーバ選択処理部２１２は、アプリケーション情報テーブル２０８を参照し、東京ＤＣで利用されていたアプリケーションのデプロイ時間を読み出した後、ステップ７０３で検索されたサーバについて、そのデプロイ時間比をサーバ一覧テーブル２０９から読み出し、前記デプロイ時間とデプロイ時間比の積を変数Ｃに代入する。
【００４２】
ステップ７０５では、バックアップデータ１７０にアクセスして前記アプリケーションのバックアップデータサイズを取得した後、ステップ７０３で検索されたサーバのデータ復元時間比をサーバ一覧テーブル２０９から読み出し、前記バックアップデータサイズと標準サーバの単位サイズ当たりの復元時間とデータ復元時間比との積を変数Ｄに代入する。
【００４３】
ステップ７０６では、アプリケーション情報テーブル２０８を参照し、東京ＤＣで利用されていたアプリケーションに対応する復旧時間の要件を読み出した後、変数Ａの値と変数Ｂの値との積に変数Ｃの値と変数Ｄの値を加算した結果と、前記読み出した復旧時間の要件の値とを比較する。
【００４４】
ここで、変数Ａの値と変数Ｂの値との積は、データ転送間隔中に発生するデータを未バックアップデータとした場合に、その未バックアップデータを大阪ＤＣへ入力するのに必要な時間を表しており、変数Ｃの値は前記アプリケーションをそのサーバでデプロイするのに必要な時間、変数Ｄの値は前記アプリケーションのバックアップデータをそのサーバで復元するのに必要な時間を示している。なお、ステップ７０１で変数Ａの値を算出する際にデータ転送間隔の代わりに、前回のバックアップ実施時刻からの経過時間を用い、前回のバックアップからの経過時間中に発生するデータを未バックアップデータとしても良い。
【００４５】
ステップ７０６で調べた結果、前記加算結果が復旧時間の要件の値よりも小さい場合には、ステップ７０３で検索されたサーバを大阪ＤＣでのリカバリに用いるサーバとして選択して当該アプリケーションに対するサーバの選択処理を終了し、そうでない場合にはステップ７０３に戻って他のサーバを検索する。
【００４６】
また、東京ＤＣで利用されていたアプリケーションが複数である場合には、同様にステップ７０１からステップ７０６までの処理を繰り返し、前記選択されたサーバを除くサーバの中からリカバリに用いるサーバを選択する。
【００４７】
その後、前記の様にして選択されたサーバにアプリケーションをデプロイし、バックアップからデータを復元した後、図５の様に未バックアップデータを入力し、図６の様にエンドユーザは大阪ＤＣに切り替えて運用を続ける。
【００４８】
前記の様に本実施形態では、バックアップの作成されていない未バックアップデータの入力に必要な時間を見込んだ所要復旧時間が所定の復旧時間の要件を満たしているサーバを選択してリカバリ処理を行うので、例えば自治体の住民票データの様な危急性が少なく更新頻度が低いデータを扱う場合等、障害時にバックアップが取られていないデータについては、手作業等によって別途入力することで回復すれば良いという比較的ルーズなリカバリ処理に対応することが可能であり、コストの低いリカバリサービスを提供することができる。
【００４９】
次に、本実施形態のリカバリ処理システムにおいて、前記エンドユーザが複数である場合に、アプリケーションの優先度またはエンドユーザの優先度の高いものから順に前記大阪ＤＣのサーバ１６１〜１６３の選択を行う処理について説明する。
【００５０】
図１０は本実施形態の複数エンドユーザが東京ＤＣを利用している場合の通常時の運用を示す図である。図１０に示す場合では、エンドユーザＡ及びＢの用いる各情報処理装置と、東京ＤＣと、大阪ＤＣとをネットワークで接続している。エンドユーザＡ及びＢは、通常、東京ＤＣにおける複数のアプリケーションを利用しており、大阪ＤＣにバックアップデータを所定の時間間隔で転送している。
【００５１】
この際、東京ＤＣで障害が発生すると、大阪ＤＣのサーバ選択処理部２１２は、東京ＤＣで利用されていた複数のアプリケーション間の優先度の違いを計算する。その際の計算のパラメータとして、アプリケーション情報テーブル２０８中の優先度（あるエンドユーザの利用しているアプリケーションの優先度）及びユーザ優先度テーブル２１０中の優先度（ＤＣを利用しているエンドユーザの優先度）を用いることで、ＤＣ内でリカバリする際の各アプリケーションの優先順位を決定する。
【００５２】
図１１は本実施形態のユーザ優先度テーブル２１０の一例を示す図である。図１１に示す様にユーザ優先度テーブル２１０は、そのユーザの優先度を示す情報を格納しており、このテーブルの優先度の値と、アプリケーション情報テーブル２０８中の優先度の値を用いることで、ＤＣ内での各アプリケーションの優先順位を決定する。
【００５３】
例えば「エンドユーザの利用しているアプリケーションの優先度×そのエンドユーザの優先度」によってそのアプリケーションを大阪ＤＣでリカバリする際の優先順位を決定することが出来るが、それ以外の計算方法もあり得る。また、サーバ一覧テーブル２０９を用いず、各ユーザのアプリケーション情報テーブル２０８の優先度に、ＤＣ内でリカバリする際の各アプリケーションの優先度を直接格納する方法もあり得る。
【００５４】
そして、前記決定した優先度の高いものから順に、図７のサーバの選択処理を実行することで、優先度付きのディザスタリカバリを実現することが出来る。この様にして、実際にリカバリを行った場合の結果例を図１２に示す。
【００５５】
図１２は本実施形態の複数エンドユーザが東京ＤＣを利用しており、東京ＤＣで障害が発生した場合に大阪ＤＣでリカバリを行った際の結果例を示す図である。図１２では、エンドユーザＡよりもエンドユーザＢの方が優先度が高く、またエンドユーザＡの利用するアプリケーションＡ１の方がアプリケーションＡ２よりも優先度が高い場合の例を表しており、これらの優先度の為、サーバが足りない大阪ＤＣではアプリケーションＡ２がリカバリされていない。
【００５６】
前記の様に本実施形態のリカバリ処理システムでは、障害時には優先度の低いアプリケーションについてはリカバリせず、障害の発生した東京ＤＣの復旧を待つといった比較的ルーズなリカバリに対するニーズに対応することが可能である。
【００５７】
また本実施形態のリカバリ処理システムにおいて、前記の様にしてリカバリされないアプリケーションが発生した場合に、そのアプリケーションの情報を他のＤＣへ通知して、リカバリ可能であるかをそのＤＣのＤＣ管理サーバに問い合わせ、リカバリ可能である場合には、そのＤＣへ当該アプリケーションのバックアップデータを転送してリカバリを行うものとしても良い。
【００５８】
以上説明した様に本実施形態のリカバリ処理システムによれば、未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置によりリカバリ処理を行うので、障害時にバックアップが取られていないデータについては別途入力することで回復すれば良いという比較的ルーズなリカバリに対するニーズに対応することが可能である。
【００５９】
【発明の効果】
本発明によれば未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置によりリカバリ処理を行うので、障害時にバックアップが取られていないデータについては別途入力することで回復すれば良いという比較的ルーズなリカバリに対するニーズに対応することが可能である。
【図面の簡単な説明】
【図１】本実施形態の東京ＤＣで障害が発生する前の通常時の運用を示す図である。
【図２】本実施形態のＤＣ管理サーバ１４０の概略構成を示す図である。
【図３】本実施形態の通常時の東京ＤＣと大阪ＤＣの間のバックアップデータの転送を示す図である。
【図４】本実施形態の東京ＤＣで障害が発生したときの、大阪ＤＣでのリカバリ用サーバの選択、アプリケーションのデプロイ、バックアップデータによる復元の概要を示す図である。
【図５】本実施形態のバックアップデータのリカバリ後の未バックアップデータの入力を示す図である。
【図６】本実施形態のリカバリ完了後、エンドユーザが大阪ＤＣにシステムを切り替えて運用を続行する処理の概要を示す図である。
【図７】本実施形態のリカバリに用いるサーバを選択する処理の処理手順を示すフローチャートである。
【図８】本実施形態のアプリケーション情報テーブル２０８の一例を示す図である。
【図９】本実施形態のサーバ一覧テーブル２０９の一例を示す図である。
【図１０】本実施形態の複数エンドユーザが東京ＤＣを利用している場合の通常時の運用を示す図である。
【図１１】本実施形態のユーザ優先度テーブル２１０の一例を示す図である。
【図１２】本実施形態の複数エンドユーザが東京ＤＣを利用しており、東京ＤＣで障害が発生した場合に大阪ＤＣでリカバリを行った際の結果例を示す図である。
【符号の説明】
１００…ＤＣ管理サーバ、１１０…リポジトリ、１１１及び１１２…アプリケーション、１２１〜１２３…サーバ、１３０…アプリケーションデータ、１４０…ＤＣ管理サーバ、１５０…リポジトリ、１５１及び１５２…アプリケーション、１６１〜１６３…サーバ、１７０…バックアップデータ、２０１…ＣＰＵ、２０２…メモリ、２０３…磁気ディスク装置、２０４…入力装置、２０５…出力装置、２０６…ＣＤ−ＲＯＭ装置、２０７…通信装置、２０８…アプリケーション情報テーブル、２０９…サーバ一覧テーブル、２１０…ユーザ優先度テーブル、２１１…バックアップ作成処理部、２１２…サーバ選択処理部、２１３…復旧処理部。
Claims (11)
- 第１の情報処理センタで障害が発生した場合に第２の情報処理センタでその処理をリカバリするリカバリ処理方法において、
第２の情報処理センタが、エンドユーザによって通常利用される第１の情報処理センタのデータを所定の時間間隔で第２の情報処理センタで受信して前記データのバックアップを第２の情報処理センタに作成するステップと、
第２の情報処理センタが、第１の情報処理センタで障害が発生した場合に、未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置を第２の情報処理センタの情報処理装置の中から選択するステップと、
第２の情報処理センタが、前記第１の情報処理センタで利用されていたアプリケーションを前記選択された情報処理装置にデプロイし、前記第１の情報処理センタのデータを前記バックアップから前記選択された情報処理装置に復元するステップとを有することを特徴とするリカバリ処理方法。 - 第２の情報処理センタは、アプリケーション処理の再開までに許容可能な時間の指定を当該アプリケーションのエンドユーザから受け付け、その受け付けた時間を前記所定の復旧時間の要件として設定することを特徴とする請求項１に記載されたリカバリ処理方法。
- 第２の情報処理センタは、前記所要復旧時間が所定の復旧時間の要件を満たす様に前記バックアップの時間間隔を調整することを特徴とする請求項１または請求項２のいずれかに記載されたリカバリ処理方法。
- 第２の情報処理センタは、前記エンドユーザが複数である場合に、アプリケーションの優先度またはエンドユーザの優先度の高いものから順に前記第２の情報処理センタの情報処理装置の選択を行うことを特徴とする請求項１乃至請求項３のいずれか１項に記載されたリカバリ処理方法。
- 第２の情報処理センタは、前記第２の情報処理センタの情報処理装置が選択されなかったアプリケーションが存在する場合に、他の情報処理センタでリカバリ可能であるかを問い合わせることを特徴とする請求項１乃至請求項４のいずれか１項に記載されたリカバリ処理方法。
- ある情報処理センタで障害が発生した場合に他の情報処理センタでその処理をリカバリするリカバリ処理システムにおいて、
エンドユーザによって通常利用される第１の情報処理センタのデータを所定の時間間隔で第２の情報処理センタで受信して前記データのバックアップを第２の情報処理センタに作成するバックアップ作成処理部と、
第１の情報処理センタで障害が発生した場合に、未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置を第２の情報処理センタの情報処理装置の中から選択する情報処理装置選択処理部と、
前記第１の情報処理センタで利用されていたアプリケーションを前記選択された情報処理装置にデプロイし、前記第１の情報処理センタのデータを前記バックアップから前記選択された情報処理装置に復元する復旧処理部とを備えることを特徴とするリカバリ処理システム。 - 前記情報処理装置選択処理部は、アプリケーション処理の再開までに許容可能な時間の指定を当該アプリケーションのエンドユーザから受け付け、その受け付けた時間を前記所定の復旧時間の要件として設定するものであることを特徴とする請求項６に記載されたリカバリ処理システム。
- 前記バックアップ作成処理部は、前記所要復旧時間が所定の復旧時間の要件を満たす様に前記バックアップの時間間隔を調整するものであることを特徴とする請求項６または請求項７のいずれかに記載されたリカバリ処理システム。
- 前記情報処理装置選択処理部は、前記エンドユーザが複数である場合に、アプリケーションの優先度またはエンドユーザの優先度の高いものから順に前記第２の情報処理センタの情報処理装置の選択を行うものであることを特徴とする請求項６乃至請求項８のいずれか１項に記載されたリカバリ処理システム。
- 前記情報処理装置選択処理部は、前記第２の情報処理センタの情報処理装置が選択されなかったアプリケーションが存在する場合に、他の情報処理センタでリカバリ可能であるかを問い合わせるものであることを特徴とする請求項６乃至請求項９のいずれか１項に記載されたリカバリ処理システム。
- ある情報処理センタで障害が発生した場合に他の情報処理センタでその処理をリカバリするリカバリ処理システムとしてコンピュータを機能させる為のプログラムにおいて、
エンドユーザによって通常利用される第１の情報処理センタのデータを所定の時間間隔で第２の情報処理センタで受信して前記データのバックアップを第２の情報処理センタに作成するバックアップ作成処理部と、
第１の情報処理センタで障害が発生した場合に、未バックアップデータの入力に必要な時間を含む所要復旧時間が所定の復旧時間の要件を満たしている情報処理装置を第２の情報処理センタの情報処理装置の中から選択する情報処理装置選択処理部と、
前記第１の情報処理センタで利用されていたアプリケーションを前記選択された情報処理装置にデプロイし、前記第１の情報処理センタのデータを前記バックアップから前記選択された情報処理装置に復元する復旧処理部としてコンピュータを機能させることを特徴とするプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003086897A JP4141875B2 (ja) | 2003-03-27 | 2003-03-27 | リカバリ処理方法及びその実施システム並びにその処理プログラム |
| US10/649,748 US6990605B2 (en) | 2003-03-27 | 2003-08-28 | Methods and apparatus for recovering work of one computer by another computers |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003086897A JP4141875B2 (ja) | 2003-03-27 | 2003-03-27 | リカバリ処理方法及びその実施システム並びにその処理プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004295462A JP2004295462A (ja) | 2004-10-21 |
| JP4141875B2 true JP4141875B2 (ja) | 2008-08-27 |
Family
ID=33127236
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003086897A Expired - Fee Related JP4141875B2 (ja) | 2003-03-27 | 2003-03-27 | リカバリ処理方法及びその実施システム並びにその処理プログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6990605B2 (ja) |
| JP (1) | JP4141875B2 (ja) |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3951835B2 (ja) | 2002-07-03 | 2007-08-01 | 株式会社日立製作所 | 業務管理方法及び業務処理システム |
| GB0308708D0 (en) * | 2003-04-15 | 2003-05-21 | British Telecomm | A computer system |
| DE102004005128B3 (de) * | 2004-02-02 | 2005-01-05 | Fujitsu Siemens Computers Gmbh | Anordnung mehrerer Rechner und Verfahren zum Betreiben einer Anordnung mehrerer Rechner bei einem Rechnerausfall |
| US20060074993A1 (en) * | 2004-10-04 | 2006-04-06 | Chandrasekhar Pulamarasetti | System and method for management of recovery time objectives of business continuity/disaster recovery IT solutions |
| JP4516458B2 (ja) * | 2005-03-18 | 2010-08-04 | 株式会社日立製作所 | フェイルオーバークラスタシステム及びフェイルオーバー方法 |
| JP4831599B2 (ja) | 2005-06-28 | 2011-12-07 | ルネサスエレクトロニクス株式会社 | 処理装置 |
| US7934116B2 (en) * | 2005-09-30 | 2011-04-26 | Lockheed Martin Corporation | Disaster recover/continuity of business adaptive solution framework |
| JP4920391B2 (ja) * | 2006-01-06 | 2012-04-18 | 株式会社日立製作所 | 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム |
| JP4856955B2 (ja) * | 2006-01-17 | 2012-01-18 | 株式会社日立製作所 | Ｎａｓシステム及びリモートコピー方法 |
| US8135135B2 (en) * | 2006-12-08 | 2012-03-13 | Microsoft Corporation | Secure data protection during disasters |
| US8984326B2 (en) * | 2007-10-31 | 2015-03-17 | Hewlett-Packard Development Company, L.P. | Testing disaster recovery elements |
| JP5011073B2 (ja) * | 2007-11-22 | 2012-08-29 | 株式会社日立製作所 | サーバ切り替え方法、およびサーバシステム |
| JP5209293B2 (ja) * | 2007-12-21 | 2013-06-12 | 株式会社野村総合研究所 | 業務継続システム |
| JP5104619B2 (ja) * | 2008-07-24 | 2012-12-19 | 富士通株式会社 | 情報処理装置、情報処理方法、およびプログラム |
| TW201022930A (en) * | 2008-11-20 | 2010-06-16 | Ibm | Method to improve recovery time of mirrored disks when read stability is in doubt |
| JP5026480B2 (ja) * | 2009-08-19 | 2012-09-12 | 日本電信電話株式会社 | 情報処理装置、方法、システム、およびプログラム |
| US8117493B1 (en) * | 2009-10-30 | 2012-02-14 | Netapp, Inc. | Fast recovery in data mirroring techniques |
| US9047247B2 (en) | 2012-10-30 | 2015-06-02 | Hitachi, Ltd. | Storage system and data processing method |
| JP6269199B2 (ja) * | 2014-03-13 | 2018-01-31 | 日本電気株式会社 | 管理サーバおよび障害復旧方法、並びにコンピュータ・プログラム |
| CN105162560A (zh) * | 2015-08-24 | 2015-12-16 | 浪潮(北京)电子信息产业有限公司 | 一种数据处理方法和系统 |
| JP6926870B2 (ja) * | 2017-09-14 | 2021-08-25 | 日本電気株式会社 | 情報処理装置、情報処理方法、及びプログラム |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5404508A (en) | 1992-12-03 | 1995-04-04 | Unisys Corporation | Data base backup and recovery system and method |
| JPH06250906A (ja) | 1993-02-26 | 1994-09-09 | Fujitsu Ltd | 主記憶装置に展開されたデータのバックアップ・リカバリ方式 |
| US5513314A (en) * | 1995-01-27 | 1996-04-30 | Auspex Systems, Inc. | Fault tolerant NFS server system and mirroring protocol |
| US5796934A (en) | 1996-05-31 | 1998-08-18 | Oracle Corporation | Fault tolerant client server system |
| US5758359A (en) | 1996-10-24 | 1998-05-26 | Digital Equipment Corporation | Method and apparatus for performing retroactive backups in a computer system |
| US5966730A (en) * | 1996-10-30 | 1999-10-12 | Dantz Development Corporation | Backup system for computer network incorporating opportunistic backup by prioritizing least recently backed up computer or computer storage medium |
| US5930824A (en) | 1997-02-04 | 1999-07-27 | International Business Machines Corporation | System and method for demand-base data recovery |
| US6363497B1 (en) * | 1997-05-13 | 2002-03-26 | Micron Technology, Inc. | System for clustering software applications |
| WO1999012098A1 (en) | 1997-08-29 | 1999-03-11 | Hewlett-Packard Company | Data backup and recovery systems |
| US6182086B1 (en) * | 1998-03-02 | 2001-01-30 | Microsoft Corporation | Client-server computer system with application recovery of server applications and client applications |
| US6163856A (en) * | 1998-05-29 | 2000-12-19 | Sun Microsystems, Inc. | Method and apparatus for file system disaster recovery |
| US6266784B1 (en) * | 1998-09-15 | 2001-07-24 | International Business Machines Corporation | Direct storage of recovery plan file on remote server for disaster recovery and storage management thereof |
| US6247141B1 (en) | 1998-09-24 | 2001-06-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Protocol for providing replicated servers in a client-server system |
| US6636988B1 (en) * | 2000-03-03 | 2003-10-21 | International Business Machines Corporation | Application of automation and procedures to enable high-speed recovery and relocation of computer workloads |
| US6820217B2 (en) | 2001-10-29 | 2004-11-16 | International Business Machines Corporation | Method and apparatus for data recovery optimization in a logically partitioned computer system |
| US6728898B2 (en) * | 2002-03-06 | 2004-04-27 | Marathon Technologies Corporation | Producing a mirrored copy using incremental-divergence |
| US8386362B2 (en) | 2002-06-05 | 2013-02-26 | The Nasdaq Omx Group, Inc. | Information distribution process and method |
| JP3951835B2 (ja) | 2002-07-03 | 2007-08-01 | 株式会社日立製作所 | 業務管理方法及び業務処理システム |
-
2003
- 2003-03-27 JP JP2003086897A patent/JP4141875B2/ja not_active Expired - Fee Related
- 2003-08-28 US US10/649,748 patent/US6990605B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004295462A (ja) | 2004-10-21 |
| US20040205382A1 (en) | 2004-10-14 |
| US6990605B2 (en) | 2006-01-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4141875B2 (ja) | リカバリ処理方法及びその実施システム並びにその処理プログラム | |
| US6694345B1 (en) | External job scheduling within a distributed processing system having a local job control system | |
| US8370802B2 (en) | Specifying an order for changing an operational state of software application components | |
| US9934107B1 (en) | Designating backup nodes and backing up in parallel in a high-availability environment | |
| US7496783B1 (en) | Merging cluster nodes during a restore | |
| US7974949B2 (en) | Computer system and automatic data backup method | |
| US7536603B2 (en) | Maintaining functionality during component failures | |
| JP5243851B2 (ja) | データをバックアップする方法 | |
| US20040098426A1 (en) | Backup system, backup method, program for backup, and backup service provision system | |
| US20020059306A1 (en) | Method and system for advanced restart of application servers processing time-critical requests | |
| US20060259594A1 (en) | Progressive deployment and maintenance of applications on a set of peer nodes | |
| US8862547B2 (en) | Centralizing data backup records from multiple servers onto a central server | |
| US10055307B2 (en) | Workflows for series of snapshots | |
| US9043781B2 (en) | Algorithm for automated enterprise deployments | |
| JP5348129B2 (ja) | 統合構成管理装置、異種構成管理装置、バックアップデータ管理システム | |
| US7668938B1 (en) | Method and system for dynamically purposing a computing device | |
| CN107391303B (zh) | 数据处理方法、装置、系统、服务器及计算机存储介质 | |
| US6892320B1 (en) | Method and apparatus for providing multiple-version support for highly available objects | |
| US10728326B2 (en) | Method and system for high availability topology for master-slave data systems with low write traffic | |
| JP4804653B2 (ja) | 処理要求復旧システム | |
| US20040010490A1 (en) | Data transfer method | |
| JP2001034595A (ja) | 複数システム間業務統合方法および装置 | |
| US20230161733A1 (en) | Change block tracking for transfer of data for backups | |
| JP2004302630A (ja) | メッセージ処理方法及びその実施装置並びにその処理プログラム | |
| CN117762557A (zh) | 虚拟机创建方法、装置、电子设备及可读存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060221 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080318 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080516 |
|
| 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: 20080610 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080611 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110620 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110620 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120620 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120620 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130620 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |