JP2015170251A - 冗長処理方法、冗長処理システム及び情報処理装置 - Google Patents

Abstract

【課題】冗長化のため確保されたリソースを早期に解放する。【解決手段】本方法は、第１のシステムにおける第１の情報処理装置によって実行され、（Ａ）第１のシステムの異常時に第１のシステムに代わって第１の処理を行う第２のシステムを特定し、（Ｂ）第２のシステムにおける第２の情報処理装置に対して、第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、（Ｃ）第２のシステムの異常を検出すると、第２のシステム以外の第３のシステムを特定し、（Ｄ）第３のシステムにおける第３の情報処理装置に対して、第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、（Ｅ）第２のシステムの復帰を検出すると、第２のシステムにおける第２の情報処理装置に対して、第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する処理を含む。【選択図】図１２

Description

本発明は、システムの冗長化技術に関する。

ある文献には、複数のクラウドを連携させるシステムが開示されている。より具体的には、各クラウドにクラウド連携サーバを設け、正系クラウドのクラウド連携サーバは、副系クラウドのクラウド連携サーバに、前もって、正系システムのリソースに関する管理情報を送信しておく。そして、正系システムがダウンした際には、副系クラウドのクラウド連携サーバが、既に受信されている管理情報に基づきリソースを確保した上で、副系クラウドにおいて副系システムを起動させる。

この文献では、単純な系の切り替えのみについて触れており、正系クラウドで正系システムが動作中に、副系クラウドに異常が発生した場合や、副系クラウドにおける副系システムに系の切り替えを行った後に正系クラウドが復帰する場合などを想定していない。このようなケースを想定していないので、システムの可用性は高まったとしても、余分なリソースを無駄に確保したままになる現象が発生する恐れがある。

国際公開第２０１２／１７６３３７号パンフレット

従って、本発明の目的は、一側面によれば、冗長化のため確保されたリソースを早期に解放するための技術を提供することである。

本発明の第１の態様に係る冗長処理方法は、第１のシステムにおける第１の情報処理装置によって実行され、（Ａ）第１のシステムの異常時に第１のシステムに代わって第１の処理を行う第２のシステムを特定し、（Ｂ）第２のシステムにおける第２の情報処理装置に対して、第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、（Ｃ）第２のシステムの異常を検出すると、第２のシステム以外の第３のシステムを特定し、（Ｄ）第３のシステムにおける第３の情報処理装置に対して、第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、（Ｅ）第２のシステムの復帰を検出すると、第２のシステムにおける第２の情報処理装置に対して、第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する処理を含む。

本発明の第２の態様に係る冗長処理方法は、（Ａ）第１のシステムにおける第１の情報処理装置が、第１のシステムの異常時に第１のシステムに代わって第１の処理を行う第２のシステムを特定し、（Ｂ）第１の情報処理装置が、第２のシステムにおける第２の情報処理装置に対して、第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、（Ｃ）第２の情報処理装置が、第１のシステムの異常を検出した後、第２のシステムの異常時に第１及び第２のシステムに代わって第１の処理を行う第３のシステムを特定し、（Ｄ）第２の情報処理装置が、第３のシステムにおける第３の情報処理装置に対して、第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、（Ｅ）第１のシステムが復帰して第１の処理を第１のシステムに切り戻す場合には、第２の情報処理装置が、第３のシステムにおける第３の情報処理装置に対して、第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する処理を含む。

一側面によれば、冗長化のため確保されたリソースを早期に解放できるようになる。

図１は、実施の形態に係るシステムの概要を示す図である。 図２は、クラウド連携サーバの機能ブロック図である。 図３は、管理情報格納部に格納される第１の管理情報の一例を示す図である。 図４は、管理情報格納部に格納される第２の管理情報の一例を示す図である。 図５は、ストレージ管理サーバの機能ブロック図である。 図６は、ストレージ管理サーバにおけるリソースデータ格納部に格納されるデータのフォーマット例を示す図である。 図７は、ネットワーク管理サーバの機能ブロック図である。 図８は、ネットワーク管理サーバにおけるリソースデータ格納部に格納されるデータのフォーマット例を示す図である。 図９は、管理情報格納部に格納されるリソースデータの一例を示す図である。 図１０は、第１の副系クラウドシステムの構成を示す図である。 図１１は、第２の副系クラウドシステムの構成を示す図である。 図１２は、第１の実施の形態に係る処理の概要を説明するための図である。 図１３は、第１の実施の形態に係る処理の概要を説明するための図である。 図１４は、第１の実施の形態に係る処理の処理フローを示す図である。 図１５は、第１の実施の形態に係る処理の処理フローを示す図である。 図１６は、リソース確保処理の処理フローを示す図である。 図１７は、第１の実施の形態に係る処理の処理フローを示す図である。 図１８は、管理情報格納部に格納される第１の管理情報の変更後における例を示す図である。 図１９は、第１の実施の形態に係る処理の処理フローを示す図である。 図２０は、復帰対応処理の処理フローを示す図である。 図２１は、リソース解放処理の処理フローを示す図である。 図２２は、第２の実施の形態に係る処理の概要を説明するための図である。 図２３は、第２の実施の形態に係る処理の概要を説明するための図である。 図２４は、第２の実施の形態に係る処理の処理フローを示す図である。 図２５は、第２の実施の形態に係る処理の処理フローを示す図である。 図２６は、第２の副系クラウドシステムのクラウド連携サーバにおける管理情報格納部に格納される第１の管理情報の一例を示す図である。 図２７は、第２の実施の形態に係る処理の処理フローを示す図である。 図２８は、第２の実施の形態に係る処理の処理フローを示す図である。 図２９は、第２の実施の形態に係る処理の処理フローを示す図である。 図３０は、第２の実施の形態に係る処理の処理フローを示す図である。 図３１は、コンピュータの機能ブロック図である。

［実施の形態１］
図１に本実施の形態に係るシステムの概要を示す。

本実施の形態では、例えばインターネットなどのネットワーク５００に、正系クラウドシステム１００と、第１の副系クラウドシステム２００と、第２の副系クラウドシステム３００と、正系クラウドシステム１００においてシステムを構築しているユーザのユーザ端末４００とが接続している。

ユーザ端末４００を操作するユーザにとっては、正系クラウドシステム１００が正系であって、他のユーザにとっては副系クラウドシステム２００又は３００が正系となる場合もある。

正系クラウドシステム１００は、ストレージ管理サーバ（ＤＣ−ＯＰＳ：Data Center Operation Systemとも呼ぶ）１５０と、ネットワーク管理サーバ（ＮＷ−ＯＰＳ：Network Operation Systemとも呼ぶ）１６０と、クラウド連携サーバ（ＩＣＳ：Inter Cloud Server）１１０と、各種リソースとを有する。各種リソースは、ＣＰＵ（Central Processing Unit）リソース及びストレージリソース（以下、ＤＣリソースとも呼ぶ）、回線種別や帯域などを含むネットワークリソース（以下、ＮＷリソースとも呼ぶ）とを含む。

同様に、副系クラウドシステム２００も、ストレージ管理サーバ（ＤＣ−ＯＰＳ：Data Center Operation Systemとも呼ぶ）２５０と、ネットワーク管理サーバ（ＮＷ−ＯＰＳ：Network Operation Systemとも呼ぶ）２６０と、クラウド連携サーバ（ＩＣＳ：Inter Cloud Server）２１０と、各種リソースとを有する。

さらに、副系クラウドシステム３００も、ストレージ管理サーバ（ＤＣ−ＯＰＳ：Data Center Operation Systemとも呼ぶ）３５０と、ネットワーク管理サーバ（ＮＷ−ＯＰＳ：Network Operation Systemとも呼ぶ）３６０と、クラウド連携サーバ（ＩＣＳ：Inter Cloud Server）３１０と、各種リソースとを有する。

上でも述べたように、正系クラウドシステム１００も、副系クラウドシステムとして動作する場合もあれば、副系クラウドシステム２００及び３００も、正系クラウドシステムとして動作する場合もある。従って、基本的に、いずれのクラウドシステムにおけるクラウド連携サーバも同様の構成を有しており、いずれのクラウドシステムにおけるストレージ管理サーバも同様の構成を有しており、いずれのクラウドシステムにおけるネットワーク管理サーバも同様の構成を有している。

そこで正系クラウドシステム１００におけるクラウド連携サーバ１１０の構成例を図２を用いて説明する。

クラウド連携サーバ１１０は、管理情報格納部１１１と、管理部１１２と、権限委譲処理部１１３と、バックアップ処理部１１４と、リカバリ処理部１１５と、解放処理部１１６と、復帰処理部１１７とを有する。

管理情報格納部１１１は、自クラウドシステムにおいて構築されている正系システムに関する第１の管理情報と、他クラウドからリカバリ開始の権限委譲を受けた副系システムに関する第２の管理情報とを格納している。

正系クラウドシステム１００におけるクラウド連携サーバ１１０の管理情報格納部１１１によって格納される第１の管理情報の一例を図３に示す。図３の例では、正系システムのユーザを表す委譲元ユーザのユーザＩＤと、権限委譲先の副クラウドシステムのクラウド連携サーバを表す委譲先ＩＣＳのＩＤと、委譲先アドレスと、権限委譲要求に対する応答の有無を表す更新結果（更新日時を含む）と、委譲先のサービス提供状況（待機中／サービス提供中など）と、副系クラウドシステムでリカバリを実施した場合に通知されるリカバリ実施時刻と、副系クラウドシステムにおいて確保すべきリソースと、リカバリ開始の権限委譲先の候補リストとを含む。

確保すべきリソースについては、例えばユーザ端末４００のユーザによってＤＣリソースと、ＮＷリソースとが別に設定される。

リカバリ開始の権限委譲先の候補リストは、例えば正系クラウドシステムを最上位に設定し、リカバリを行うのに適した副系クラウドシステムを好ましい順に列挙したものである。ここでは１番目がＩＣＳ１、すなわち正系クラウドシステム１００が正系であり、２番目が、ＩＣＳ２、すなわち副系クラウドシステム２００であり、３番目が、ＩＣＳ３、すなわち副系クラウドシステム３００である。このようなリストではなく、リカバリ開始の権限委譲先の副系クラウドシステムを特定するためのルールなどであっても良い。

リカバリ実施時刻は、リカバリを行った副クラウドシステムから通知される。

一方、副系クラウドシステム２００におけるクラウド連携サーバ２１０の管理情報格納部によって格納される第２の管理情報の一例を図４に示す。図４の例では、リカバリ開始の権限委譲元であるクラウドシステムを表す委譲元ＩＣＳのＩＤと、委譲元ユーザのＩＤと、委譲元アドレスと、管理情報の定期的な取得ができたか否かを表す定期取得結果と、確保すべきリソースと、リカバリ開始の権限委譲先の候補リストとを含む。

以下で述べるように、管理情報は、権限委譲元のクラウドシステムにおけるクラウド連携サーバから、定期的に送信されてくることになっている。よって、定期的に管理情報を取得できれば、定期取得結果が「ＯＫ」となり、できなければ「ＮＧ」となる。リソース及び委譲先候補については、基本的には権限委譲元のクラウド連携サーバから受信したものである。

図３及び図４のようなデータについても、正系クラウドシステム及び副系クラウドシステムのいずれでも保持されている。

また、ストレージ管理サーバ１５０は、図５に示すように、収集部１５１と、確保部１５２と、解放部１５３と、リソースデータ格納部１５４とを有する。収集部１５１は、クラウドシステムに構築されたシステムで使用されているＤＣリソースのデータを収集し、リソースデータ格納部１５４に格納する。また、収集部１５１は、ユーザ毎に使用中のＤＣリソースのデータも収集して、クラウド連携サーバ１１０に送信する。

確保部１５２は、クラウド連携サーバ１１０からの要求に応じて、ＤＣリソースを確保するための処理を実行する。なお、本実施の形態では、確保部１５２は、バックアップ処理等も行うものとする。さらに、解放部１５３は、クラウド連携サーバ１１０からの要求に応じて、確保済みのＤＣリソースを解放するための処理を実行する。

リソースデータ格納部１５４に格納されるデータのフォーマット例を、図６に示す。図６の例では、接続先のＩＣＳ名（すなわち識別子）と、使用されているＤＣリソースのデータ（ストレージ、ＣＰＵリソース量など）とが格納されるようになっている。正系クラウドシステム１００であっても、他のクラウドシステムに対してリソースを提供する場合もあるので、接続ＩＣＳ毎にデータを保持するようになっている。但し、ユーザ毎にＤＣリソースのデータを保持するようにしても良い。

また、ネットワーク管理サーバ１６０は、図７に示すように、収集部１６１と、確保部１６２と、解放部１６３と、リソースデータ格納部１６４とを有する。収集部１６１は、クラウドシステムに構築されたシステムで使用されているＮＷリソースのデータを収集し、リソースデータ格納部１６４に格納する。また、収集部１６１は、ユーザ毎にＮＷリソースのデータも収集して、クラウド連携サーバ１１０に送信する。

確保部１６２は、クラウド連携サーバ１１０からの要求に応じて、ＮＷリソースを確保するための処理を実行する。さらに、解放部１６３は、クラウド連携サーバ１１０からの要求に応じて、確保済みのＮＷリソースを解放するための処理を実行する。

リソースデータ格納部１６４に格納されるデータのフォーマット例を、図８に示す。図８の例では、接続先のＩＣＳ名（すなわち識別子）と、使用されているＮＷリソースのデータ（回線種別、帯域など）とが格納されるようになっている。正系クラウドシステム１００であっても、他のクラウドシステムに対してリソースを提供する場合もあるので、接続ＩＣＳ毎にデータを保持するようになっている。但し、ユーザ毎にＮＷリソースを保持するようにしても良い。

ストレージ管理サーバ１５０の収集部１５１及びネットワーク管理サーバ１６０の収集部１６１によって収集されたリソースのデータは、クラウド連携サーバ１１０の管理部１１２に送信される。そして、管理情報格納部１１１に、図９に示すようなフォーマットでリソースデータが格納される。図９の例では、接続先（ユーザ名（すなわちユーザ識別子））と、使用されているＮＷリソース及び使用されているＤＣリソースのデータとが含まれる。これによって、例えば他のクラウドシステムにバックアップを行う際に確保すべきリソースなどを特定できるようになる。

なお、以下の説明では、副系クラウドシステム２００及び３００における構成要素についても述べることになるので、区別するために、図１０及び図１１に示すような参照番号を付すことにする。

すなわち、クラウド連携サーバ２１０は、管理情報格納部２１１と、管理部２１２と、権限委譲処理部２１３と、バックアップ処理部２１４と、リカバリ処理部２１５と、解放処理部２１６と、復帰処理部２１７とを有する。ストレージ管理サーバ２５０は、収集部２５１と、確保部２５２と、解放部２５３と、リソースデータ格納部２５４とを有する。さらに、ネットワーク管理サーバ２６０は、収集部２６１と、確保部２６２と、解放部２６３と、リソースデータ格納部２６４とを有する。

また、クラウド連携サーバ３１０は、管理情報格納部３１１と、管理部３１２と、権限委譲処理部３１３と、バックアップ処理部３１４と、リカバリ処理部３１５と、解放処理部３１６と、復帰処理部３１７とを有する。ストレージ管理サーバ３５０は、収集部３５１と、確保部３５２と、解放部３５３と、リソースデータ格納部３５４とを有する。さらに、ネットワーク管理サーバ３６０は、収集部３６１と、確保部３６２と、解放部３６３と、リソースデータ格納部３６４とを有する。

次に、図１２及び図１３を用いて、本実施の形態に係る処理の概要を説明する。まず、あるユーザ（図３のＩＣＳ１Ｕｓｅｒ０１）のシステムについてリカバリ開始の権限委譲先として副系クラウドシステム２００（ＩＣＳ２）が特定されているものとする。そうすると、正系クラウドシステム１００のクラウド連携サーバ１１０は、委譲元ＩＣＳのＩＤ（識別子）と委譲元ユーザＩＤと確保すべきリソースのデータと委譲先候補リストとを含む管理情報を含む権限委譲要求を、副系クラウドシステム２００のクラウド連携サーバ２１０に送信する。副系クラウドシステム２００に異常がなければ、副系クラウドシステム２００のクラウド連携サーバ２１０は、権限委譲要求に含まれる管理情報を管理情報格納部２１１に格納し、権限委譲要求に対して権限委譲応答を、正系クラウドシステム１００のクラウド連携サーバ１１０へ返信する。

このようなやりとりが１回以上行われた後、クラウド連携サーバ１１０が、権限委譲要求をクラウド連携サーバ２１０へ送信しても（ステップ（１））、クラウド連携サーバ２１０が、権限委譲応答を返信しなくなったものとする（ステップ（２））。

そうすると、クラウド連携サーバ１１０は、副系クラウドシステム２００に障害などが発生したものと判断して、権限委譲先候補リストにおいて次の順位に指定されている副系クラウドシステム３００のクラウド連携サーバ３１０へ、権限委譲要求を送信する（ステップ（３））。

これに対して正常に動作している副系クラウドシステム３００のクラウド連携サーバ３１０は、権限委譲要求に含まれる管理情報を管理情報格納部３１１に格納し、権限委譲応答を返信する（ステップ（４））。この後、正系クラウドシステム１００のクラウド連携サーバ１１０は、バックアップ開始要求を、副系クラウドシステム３００のクラウド連携サーバ３１０に送信して、バックアップを行わせる。

その後、図１３に示すように、副系クラウドシステム２００が復帰して、そのクラウド連携システム２１０は、ハートビートなどによって、正系クラウドシステム１００のクラウド連携サーバ１１０へ、復帰を通知する（ステップ（５））。

しかしながら、既に副系クラウドシステム３００へ権限委譲要求を行って、権限委譲応答も受信しているので、副系クラウドシステム２００がリカバリを行うことはない状態にある。そこで、正系クラウドシステム１００のクラウド連携サーバ１１０は、リソース解放要求を、副系クラウドシステム２００のクラウド連携サーバ２１０へ送信する（ステップ（６））。このように、早期に副系クラウドシステム２００においてリソースを解放させることで、副系クラウドシステム２００のリソースを有効活用できるようになる。なお、管理情報も削除する。これによって、システム全体として処理の不整合が発生するのを防止する。

なお、クラウド連携サーバ１１０は、副系クラウドシステム３００のクラウド連携サーバ３１０へ、権限委譲要求を送信する動作は継続する（ステップ（７））。

この権限委譲要求に応答して、正常に動作している副系クラウドシステム３００のクラウド連携サーバ３１０は、権限委譲応答を返信する（ステップ（８））。

以下、このような動作パターンの処理内容について詳細を図１４乃至図２１を用いて説明する。

まず、正系クラウドシステム１００のクラウド連携サーバ１１０（ＩＣＳ１）における権限委譲処理部１１３は、管理情報格納部１１１に格納されているデータに基づき、あるユーザのシステムについて権限委譲先候補リストから自クラウドシステム以外の上位のクラウドシステムを選択することで、権限委譲先を特定する（図１４：ステップＳ１）。図３の例では、まず、副系クラウドシステム２００が特定される。

また、権限委譲処理部１１３は、管理情報格納部１１１から、権限委譲要求に付加する管理情報を読み出す（ステップＳ３）。上でも述べたように、管理情報は、委譲元ＩＣＳのＩＤ（識別子）と委譲元ユーザＩＤと確保すべきリソースのデータと委譲先候補リストとを含む。

そして、権限委譲処理部１１３は、管理情報を含む権限委譲要求を、副系クラウドシステム２００のクラウド連携サーバ２００（ＩＣＳ２）へ送信する（ステップＳ５）。これに対して、クラウド連携サーバ２００（ＩＣＳ２）の権限委譲処理部２１３は、正系クラウドシステム１００から、管理情報を含む権限委譲要求を受信し（ステップＳ７）、受信した管理情報を、管理情報格納部２１１に登録する（ステップＳ９）。図４に示したようなデータが格納される。なお、定期取得結果は、現状ではＯＫとなる。

そして、クラウド連携サーバ２００（ＩＣＳ２）の権限委譲処理部２１３は、正系クラウドシステム１００のクラウド連携サーバ１１０へ権限委譲応答を送信する（ステップＳ１１）。

これに対して、クラウド連携サーバ１１０の権限委譲処理部１１３は、副系クラウドシステム２００のクラウド連携サーバ２１０から権限委譲応答を受信する（ステップＳ１３）。そうすると、図３に示すように、管理情報格納部１１１において、委譲先ＩＣＳのＩＤ及び委譲先アドレスとして副系クラウドシステム２００のデータを設定し、更新結果としてＯＫ及び権限委譲応答の受信時刻を設定し、サービス提供状態として待機中を設定する。そして処理は端子Ａ及びＢを介して図１５の処理に移行する。

なお、ステップＳ５乃至Ｓ１３は、例えば定期的に行われるが、クラウド連携サーバ２１０では、管理情報が更新された場合に、管理情報格納部２１１に格納されているデータを更新する。

図１５の処理の説明に移行して、次に、クラウド連携サーバ１１０のバックアップ処理部１１４は、管理情報格納部１１１に格納されているリソースデータ（図９）から、バックアップに用いられるリソースを特定する（ステップＳ１５）。例えば、現在使用中のストレージ量から、バックアップで確保すべきストレージ量を特定する。さらに、例えばバックアップを行う際に一般的に用いられるＣＰＵ量及びネットワークリソースを特定する。

そして、バックアップ処理部１１４は、バックアップのために確保すべきリソースのデータを含むバックアップ開始要求を、副系クラウドシステム２００のクラウド連携サーバ２１０に送信する（ステップＳ１７）。

これに対して、副系クラウドシステム２００のクラウド連携サーバ２１０におけるバックアップ処理部２１４は、正系クラウドシステム１００のクラウド連携サーバ１１０から、確保すべきリソースのデータを含むバックアップ開始要求を受信する（ステップＳ１９）。

そうすると、副系クラウドシステム２００は、バックアップのためのリソース確保処理を実行する（ステップＳ２１）。このリソース確保処理については、図１６を用いて説明する。

クラウド連携サーバ２１０のバックアップ処理部２１４は、受信したバックアップ開始要求に含まれるリソースのデータから、ストレージ管理サーバ２５０に対してバックアップで確保すべきＤＣリソースの確認要求を生成して送信し、さらに、ネットワーク管理サーバ２６０に対してバックアップで確保すべきＮＷリソースの確認要求を生成して送信する（ステップＳ３１）。

これに対して、ストレージ管理サーバ２５０の確保部２５２は、ＤＣリソースの確認要求を受信し（ステップＳ３３）、空きリソースの確認処理を実行する（ステップＳ３５）。空きリソース量が、要求リソース量以上であれば問題ないが、この処理は従来と同じで本実施の形態の主旨ではないので、これ以上の説明は省略する。なお、空きリソース量が、要求リソース量より少ない場合には、代替リソースを、例えば他のクラウドシステムから確保することになるが、このような代替リソースの調達についても、従来と同じで本実施の形態の主旨ではないので、これ以上の説明は省略する。そして、確保部２５２は、バックアップで確保すべきＤＣリソースが確保できる旨の確認応答を、クラウド連携サーバ２１０のバックアップ処理部２１４に送信する（ステップＳ３７）。

同様に、ネットワーク管理サーバ２６０の確保部２６２は、ＮＷリソースの確認要求を受信し（ステップＳ３９）、空きリソースの確認処理を実行する（ステップＳ４１）。空きリソース量が、要求リソース量以上であれば問題ないが、この処理は従来と同じで本実施の形態の主旨ではないので、これ以上の説明は省略する。なお、空きリソース量が、要求リソース量より少ない場合には、代替リソースを、例えば他のクラウドシステムから確保することになるが、このような代替リソースの調達についても、従来と同じで本実施の形態の主旨ではないので、これ以上の説明は省略する。そして、確保部２６２は、バックアップで確保すべきＮＷリソースが確保できる旨の確保応答を、クラウド連携サーバ２１０のバックアップ処理部２１４に送信する（ステップＳ４３）。

クラウド連携サーバ２１０のバックアップ処理部２１４は、ストレージ管理サーバ２５０及びネットワーク管理サーバ２６０から確認応答を受信すると（ステップＳ４５）、バックアップで確保すべきＤＣリソースの確保要求をストレージ管理サーバ２５０に送信し、バックアップで確保すべきＮＷリソースの確保要求をネットワーク管理サーバ２６０に送信する（ステップＳ４７）。

これに対して、ストレージ管理サーバ２５０の確保部２５２は、ＤＣリソースの確保要求を受信し（ステップＳ４９）、要求リソースの確保処理を実行する（ステップＳ５１）。要求リソースの確保処理については、従来と同じであり本実施の形態の主旨ではないので、これ以上の説明は省略する。そして、確保部２５２は、バックアップで確保すべきＤＣリソースが確保できた旨の確保応答を、クラウド連携サーバ２１０のバックアップ処理部２１４に送信する（ステップＳ５３）。

同様に、ネットワーク管理サーバ２６０の確保部２６２は、ＮＷリソースの確保要求を受信し（ステップＳ５５）、要求リソースの確保処理を実行する（ステップＳ５５）。この要求リソースの確保処理についても、従来と同じであり本実施の形態の主旨ではないので、これ以上の説明は省略する。そして、確保部２６２は、バックアップで確保すべきＮＷリソースが確保できた旨の確保応答を、クラウド連携サーバ２１０のバックアップ処理部２１４に送信する（ステップＳ５９）。

クラウド連携サーバ２１０のバックアップ処理部２１４は、ストレージ管理サーバ２５０及びネットワーク管理サーバ２６０から確保応答を受信する（ステップＳ６１）。これにて、リソースの確保が完了したことになる。

なお、リカバリのためにリソースを確保する場合には、リカバリ処理部２１５がリソース確保処理を、ストレージ管理サーバ２５０及びネットワーク管理サーバ２６０に実行させる。

図１５の処理の説明に戻って、クラウド連携サーバ２１０のバックアップ処理部２１４は、バックアップ開始要求に対する応答を、クラウド連携サーバ１１０のバックアップ処理部１１４に送信する（ステップＳ２３）。クラウド連携サーバ１１０のバックアップ処理部１１４は、副系クラウドシステム２００のクラウド連携サーバ２１０から、バックアップ開始要求に対応する応答を受信する（ステップＳ２５）。そうすると、バックアップ処理部１１４は、ストレージ管理サーバ１５０にバックアップの開始を指示して、ストレージ管理サーバ１５０は、副系クラウドシステム２００におけるストレージ管理サーバ２５０と共にバックアップ処理を実行する（ステップＳ２７及びＳ２８）。バックアップ処理の具体的内容は、従来と同じであり、本実施の形態の主旨ではないので、これ以上の説明は省略する。その後処理は端子Ｃを介して図１７の処理に移行する。

図１７の処理の説明に移行して、正系クラウドシステム１００のクラウド連携サーバ１１０（ＩＣＳ１）における権限委譲処理部１１３は、管理情報格納部１１１からデータを読み出して、権限委譲要求に付加する管理情報を取得する（ステップＳ７１）。

そして、権限委譲処理部１１３は、管理情報を含む権限委譲要求を、リカバリ開始の権限委譲先である副系クラウドシステム２００のクラウド連携サーバ２１０（ＩＣＳ２）へ送信する（ステップＳ７３）。

ここで、副系クラウドシステム２００に障害が発生して、権限委譲要求に応答できないものとする。

そうすると、クラウド連携サーバ１１０の権限委譲処理部１１３は、例えば権限委譲要求送信後一定時間内に権限委譲応答を受信できなくなる。なお、権限委譲処理部１１３が、副系クラウドシステム２００のクラウド連携サーバ２１０から権限委譲応答を受信できた場合には（ステップＳ７５：Ｙｅｓルート）、バックアップ処理部１１４が、バックアップのための処理（例えばステップＳ１７乃至Ｓ２８）を実行する（ステップＳ７７）。ここで、送信した管理情報に更新がある場合にのみバックアップのための処理を行うようにしても良いし、権限委譲要求送信毎にバックアップのための処理を実行するようにしても良い。

一方、上で述べた前提どおり、権限委譲応答を一定時間内に受信できなければ（ステップＳ７５：Ｎｏルート）、クラウド連携サーバ１１０の権限委譲処理部１１３は、解放処理部１１６による復帰対応処理を起動させる（ステップＳ７９）。この処理は、これまで権限委譲先となっていた副系クラウドシステム２００が復帰するまで待機して、実際に復帰した際に対応するものである。従って、後に説明する。なお、この段階で、管理情報格納部１１１において、管理情報の更新結果が「ＮＧ」となる。また、サービス提供状態をダウンにする場合もある。

また、権限委譲処理部１１３は、管理情報格納部１１１に格納されているデータに基づき、あるユーザのシステムについて権限委譲先候補リストから、副系クラウドシステム２００の次の優先順位のクラウドシステムを選択することで、権限委譲先を特定する（ステップＳ８１）。図３の例では、副系クラウドシステム３００が特定される。

また、権限委譲処理部１１３は、管理情報格納部１１１から、権限委譲要求に付加する管理情報を読み出す（ステップＳ８３）。

そして、権限委譲処理部１１３は、管理情報を含む権限委譲要求を、副系クラウドシステム３００のクラウド連携サーバ３１０（ＩＣＳ３）へ送信する（ステップＳ８５）。これに対して、クラウド連携サーバ３１０（ＩＣＳ３）の権限委譲処理部３１３は、正系クラウドシステム１００から、管理情報を含む権限委譲要求を受信し（ステップＳ８７）、受信した管理情報を、管理情報格納部３１１に登録する（ステップＳ８９）。図４に示したようなデータが格納される。なお、定期取得結果は、現状ではＯＫとなる。

そして、クラウド連携サーバ３１０（ＩＣＳ３）の権限委譲処理部３１３は、正系クラウドシステム１００のクラウド連携サーバ１１０へ権限委譲応答を送信する（ステップＳ９１）。

これに対して、クラウド連携サーバ１１０の権限委譲処理部１１３は、副系クラウドシステム３００のクラウド連携サーバ３１０から権限委譲応答を受信する（ステップＳ１０１）。そうすると、図１８に示すように、管理情報格納部１１１において、委譲先ＩＣＳのＩＤ及び委譲先アドレスとして副系クラウドシステム３００のデータを設定し、管理情報更新結果としてＯＫ及び権限委譲応答の受信時刻を設定し、サービス提供状態として待機中を設定する。そして処理は端子Ｄ及びＥを介して図１９の処理に移行する。

図１９の処理の説明に移行して、次に、クラウド連携サーバ１１０のバックアップ処理部１１４は、管理情報格納部１１１に格納されているリソースデータ（図９）から、バックアップに用いられるリソースを特定する（ステップＳ１０３）。本ステップは、ステップＳ１５と同様である。

そして、バックアップ処理部１１４は、バックアップのために確保すべきリソースのデータを含むバックアップ開始要求を、副系クラウドシステム３００のクラウド連携サーバ３１０に送信する（ステップＳ１０５）。

これに対して、副系クラウドシステム３００のクラウド連携サーバ３１０におけるバックアップ処理部３１４は、正系クラウドシステム１００のクラウド連携サーバ１１０から、確保すべきリソースのデータを含むバックアップ開始要求を受信する（ステップＳ１０７）。

そうすると、副系クラウドシステム３００は、バックアップのためのリソース確保処理を実行する（ステップＳ１０７）。このリソース確保処理については、図１６を用いて説明したものと同様である。但し、実施主体は、副系クラウドシステム２００ではなく、副系クラウドシステム３００である。

その後、クラウド連携サーバ３１０のバックアップ処理部３１４は、バックアップ開始要求に対する応答を、クラウド連携サーバ１１０のバックアップ処理部１１４に送信する（ステップＳ１０９）。クラウド連携サーバ１１０のバックアップ処理部１１４は、副系クラウドシステム３００のクラウド連携サーバ３１０から、バックアップ開始要求に対応する応答を受信する（ステップＳ１１１）。そうすると、バックアップ処理部１１４は、ストレージ管理サーバ１５０にバックアップの開始を指示して、ストレージ管理サーバ１５０は、副系クラウドシステム３００におけるストレージ管理サーバ３５０と共にバックアップ処理を実行する（ステップＳ１１３及びＳ１１４）。バックアップ処理の具体的内容は、従来と同じであり、本実施の形態の主旨ではないので、これ以上の説明は省略する。

このようにして、副系クラウドシステム３００においても、リカバリ開始の準備が整う。

次に、図２０を用いて復帰対応処理について説明する。

本実施の形態では、システムが障害から復帰した場合には、例えば管理情報格納部に格納されているデータから、権限委譲元のデータを読み出して、系復帰通知を送信するものとする。但し、クラウド連携サーバ間で、ハートビート等によって自システムが稼働中であることを通知するような機構を採用することで、系復帰が通知されるようにしても良い。

よって、副系クラウドシステム２００から権限委譲応答が返信されてこないため、正系クラウドシステム１００のクラウド連携サーバ１１０における解放処理部１１６は、副系クラウドシステム２００の系復帰通知の受信を待つ（ステップＳ１２１）。

そして、副系クラウドシステム２００が復帰すると、副系クラウドシステム２００のクラウド連携サーバ２１０における例えば権限委譲処理部２１３は、系復帰通知を、権限委譲元である正系クラウドシステム１００のクラウド連携サーバ１１０へ送信する（ステップＳ１２３）。

これに対して、正系クラウドシステム１００のクラウド連携サーバ１１０における解放処理部１１６は、副系クラウドシステム２００のクラウド連携サーバ２１０から、系復帰通知を受信する（ステップＳ１２５）。そして、解放処理部１１６は、系復帰通知から、復帰したシステムを特定する（ステップＳ１２７）。ここでは、副系クラウドシステム２００であることが特定される。なお、ここで管理情報格納部１１１におけるデータから（例えば図１８）、副系クラウドシステム２００に権限委譲したにも拘わらずダウンして影響を受けたユーザを特定するようにしても良い。

そうすると、解放処理部１１６は、副系クラウドシステム２００のクラウド連携サーバ２１０に対して、正系クラウドシステム１００について確保されているリソースを解放するためのリソース解放要求を送信する（ステップＳ１２９）。これに対して、副系クラウドシステム２００のクラウド連携サーバ２１０における解放処理部２１６は、正系クラウドシステム１００からリソース解放要求を受信する（ステップＳ１３１）。

そして、解放処理部２１６は、リソース解放処理を実行する（ステップＳ１３３）。このリソース解放処理については、図２１を用いて説明する。

解放処理部２１６は、管理情報格納部２１１に格納されているデータ（例えば図９）から、リソース解放要求元の正系クラウドシステム１００のために確保されているＤＣリソース及びＮＷリソースを特定する（ステップＳ１４１）。

そして、解放処理部２１６は、解放すべきＤＣリソースのデータを含むＤＣリソースの解放要求をストレージ管理サーバ２５０に送信し、解放すべきＮＷリソースのデータを含むＮＷリソースの解放要求をネットワーク管理サーバ２６０に送信する（ステップＳ１４３）。

ストレージ管理サーバ２５０の解放部２５３は、クラウド連携サーバ２１０からＤＣリソースの解放要求を受信すると（ステップＳ１４５）、解放すべきＤＣリソースに対してリソース解放処理を実行する（ステップＳ１４７）。この処理の具体的内容は従来と同じであり、本実施の形態の主旨ではないので、これ以上の説明は省略する。そして、解放部２５３は、解放応答を、クラウド連携サーバ２１０に送信する（ステップＳ１４９）。

また、ネットワーク管理サーバ２６０の解放部２６３は、クラウド連携サーバ２１０からＮＷリソースの解放要求を受信すると（ステップＳ１５１）、解放すべきＮＷリソースに対してリソース解放処理を実行する（ステップＳ１５３）。この処理の具体的内容は従来と同じであり、本実施の形態の主旨ではないので、これ以上の説明は省略する。そして、解放部２６３は、解放応答を、クラウド連携サーバ２１０に送信する（ステップＳ１５５）。

クラウド連携サーバ２１０の解放処理部２１６は、ストレージ管理サーバ２５０及びネットワーク管理サーバ２６０から、解放応答を受信する（ステップＳ１５７）。

これによって、重複して確保されたことになった副系クラウドシステム２００のリソースを早期に解放でき、リソースの有効活用が図られるようになる。

図２０の処理の説明に戻り、その後、副系クラウドシステム２００のクラウド連携サーバ２１０における解放処理部２１６は、解放したリソースに係る正系クラウドシステム１００からの権限委譲要求に含まれていた管理情報を、管理情報格納部２１１から削除する（ステップＳ１３４）。管理情報を削除しないと、副系クラウドシステム２００に権限委譲要求が送信されなくなっているので、副系クラウドシステム２００でリカバリ処理が実行されてしまう可能性がある。このように管理情報を削除することで、このような整合性のない動作を回避することができるようになる。

そして、解放処理部２１６は、リソース解放応答を正系クラウドシステム１００のクラウド連携サーバ１１０へ送信する（ステップＳ１３５）。

正系クラウドシステム１００のクラウド連携サーバ１１０の解放処理部１１６は、副系クラウドシステム２００のクラウド連携サーバ２１０から、リソース解放応答を受信する（ステップＳ１３７）。このリソース解放応答に応じて、例えば管理情報格納部１１１において、副系クラウドシステム２００において解放されたリソースに係るシステム（ここでは委譲先が副系クラウドシステム２００）のデータを削除する。例えば、図１８の例では１つ目のレコードを削除することになる。

以上のような処理を実行することで、元の権限委譲先である副系クラウドシステム２００が復帰したとしても、既に正常な権限委譲先が存在する場合には、副系クラウドシステム２００において確保されたリソースが早期に解放されるようになる。

［実施の形態２］
本実施の形態の処理の概要を、図２２及び図２３を用いて説明する。まず、前提として、正系クラウドシステム１００が障害などでダウンしているものとする。そうすると、副系クラウドシステム２００においてリカバリが行われて、正系クラウドシステム１００において稼働していたシステムの少なくとも一部は、副系クラウドシステム２００において起動されるようになる。

そうすると、副系クラウドシステム２００のクラウド連携サーバ２１０は、管理情報格納部２１１に格納されたデータに基づき、次の優先順位の副系クラウドシステムを特定し、当該副系クラウドシステム３００のクラウド連携サーバ３１０に対して権限委譲要求を送信する（ステップ（１１））。

そうすると、副系クラウドシステム３００のクラウド連携サーバ３１０は、正常に動作していれば、権限委譲要求を受信して管理情報格納部３１１に格納し、権限委譲応答を、副系クラウドシステム２００のクラウド連携サーバ２１０に送信する（ステップ（１２））。

この後、副系クラウドシステム２００で保持しているデータを、副系クラウドシステム３００にバックアップする処理を行う。

その後、図２３に示すように、正系クラウドシステム１００が復帰すると、正系クラウドシステム１００は、リカバリ開始の権限委譲先である副系クラウドシステム２００のクラウド連携サーバ２１０に対して、系復帰通知を送信する（ステップ（１３））。これに対して、副系クラウドシステム２００のクラウド連携サーバ２１０は、リカバリ実施通知を、正系クラウドシステム１００のクラウド連携サーバ１１０へ返信する（ステップ（１４））。

そうすると、正系クラウドシステム１００のクラウド連携サーバ１１０は、正系クラウドシステム１００で再度システムを稼働させるため、切り戻し要求を副系クラウドシステム２００のクラウド連携サーバ２１０へ送信する（ステップ（１５））。

正系クラウドシステム１００において再度システムを稼働させると、副系クラウドシステム３００で確保されているリソースは用いられなくなる。そこで、副系クラウドシステム２００のクラウド連携サーバ２１０は、副系クラウドシステム３００のクラウド連携サーバ３１０へ、リソース解放要求を送信する（ステップ（１６））。これによって、重複して確保されることになったリソースが、副系クラウドシステム３００において解放され、さらに、関連する管理情報が管理情報格納部３１１から削除される。

このように正系クラウドシステム１００において切り戻しを行う場合においても、早期に重複するリソースを解放でき、リソースの有効活用が図られる。

このような処理を、より具体的に図２４乃至図３０を用いて説明する。

まず、正系クラウドシステム１００に障害等が発生して、クラウド連携サーバ１１０から、権限委譲要求が副系クラウドシステム２００のクラウド連携サーバ２１０へ送信されなくなるところから説明する。

正系クラウドシステム１００から権限委譲要求を一定時間以上受信していない場合には、副系クラウドシステム２００のクラウド連携サーバ２１０における権限委譲処理部２１３は、リカバリ実行事象を検出し（図２４：ステップＳ２０１）、管理情報格納部２１１において、委譲元が正系クラウドシステム１００に係るデータについて、例えば定期取得結果として「ＮＧ」を格納する。

そして、クラウド連携サーバ２１０におけるリカバリ処理部２１５は、管理情報格納部２１１から、権限委譲要求を送ってこない正系クラウドシステム１００に係る管理情報を読み出し（ステップＳ２０３）、リカバリ用リソースを特定する（ステップＳ２０５）。管理情報格納部２１１に格納されているデータ（図４）のうち、例えばリソースのデータをそのまま採用する。

そして、リカバリ処理部２１５は、リカバリのためのリソース確保処理を実行する（ステップＳ２０７）。処理内容としては、図１６に示したリソース確保処理と同様であるが、クラウド連携サーバ２１０における実行主体がリカバリ処理部２１５になり、確保されるリソースが異なる。

そうすると、クラウド連携サーバ２１０のリカバリ処理部２１５は、ユーザ端末４００に対してリカバリ準備完了通知を送信する（ステップＳ２０９）。ユーザ端末４００は、副系クラウドシステム２００のクラウド連携サーバ２１０から、リカバリ準備完了通知を受信すると（ステップＳ２１１）、例えば表示装置に表示して、ユーザに確認させる。ユーザは、確認の上、ユーザ端末４００を操作して、リカバリ実行指示を入力する。そうすると、ユーザ端末４００は、リカバリ実行指示を受け付けて、リカバリ実行指示を副系クラウドシステム２００のクラウド連携サーバ２１０に送信する（ステップＳ２１３）。

そうすると、副系クラウドシステム２００のクラウド連携サーバ２１０におけるリカバリ処理部２１５は、リカバリ実行指示を受信し、リカバリ処理を実行する（ステップＳ２１５）。リカバリ処理自体は、従来と同じであり、本実施の形態の主旨ではないので、これ以上の説明は省略する。これによって、副系クラウドシステム２００において、システムが稼働される。この時、リカバリ実施時刻を管理情報格納部２１１に格納しておく。処理は、端子Ｆを介して図２５の処理に移行する。

図２５の処理の説明に移行して、副系クラウドシステム２００のクラウド連携サーバ２１０（ＩＣＳ２）における権限委譲処理部２１３は、管理情報格納部２１１に格納されているデータに基づき、権限委譲先候補リストから自クラウドシステムの次の優先順位のクラウドシステムを選択することで、権限委譲先を特定する（ステップＳ２１７）。図３の例では、副系クラウドシステム３００が特定される。

また、権限委譲処理部２１３は、管理情報格納部２１１から、権限委譲要求に付加する管理情報を読み出す（ステップＳ２１９）。上でも述べたように、管理情報は、委譲元ＩＣＳのＩＤ（識別子）と委譲元ユーザＩＤと確保すべきリソースのデータと委譲先候補リストとを含む。

そして、権限委譲処理部２１３は、管理情報を含む権限委譲要求を、副系クラウドシステム３００のクラウド連携サーバ３１０（ＩＣＳ３）へ送信する（ステップＳ２２１）。これに対して、クラウド連携サーバ３１０（ＩＣＳ３）の権限委譲処理部３１３は、副系クラウドシステム２００から、管理情報を含む権限委譲要求を受信し（ステップＳ２２３）、受信した管理情報を、管理情報格納部３１１に登録する（ステップＳ２２５）。おおよそ図４に示したようなデータが格納される。但し、委譲元ＩＣＳ及び委譲元アドレスについては、副系クラウドシステム２００のデータを合せて保持するようにする。なお、定期取得結果は、現状ではＯＫとなる。

そして、クラウド連携サーバ３１０（ＩＣＳ３）の権限委譲処理部３１３は、副系クラウドシステム２００のクラウド連携サーバ２１０へ権限委譲応答を送信する（ステップＳ２２７）。

これに対して、クラウド連携サーバ２１０の権限委譲処理部２１３は、副系クラウドシステム３００のクラウド連携サーバ３１０から権限委譲応答を受信する（ステップＳ２２９）。そうすると、図２６に示すように、管理情報格納部２１１において、委譲先ＩＣＳのＩＤ及び委譲先アドレスとして副系クラウドシステム３００のデータを設定し、管理情報の更新結果としてＯＫ及び権限委譲の応答受信時刻を設定し、サービス提供状態として待機中を設定する。そして処理は端子Ｇ及びＨを介して図２７の処理に移行する。

なお、ステップＳ２２１乃至Ｓ２２９は、例えば定期的に行われるが、クラウド連携サーバ３１０では、管理情報が更新された場合に、管理情報格納部３１１に格納されているデータを更新する。

図２７の処理の説明に移行して、次に、クラウド連携サーバ２１０のバックアップ処理部２１４は、管理情報格納部２１１に格納されているリソースデータ（図９）から、バックアップに用いられるリソースを特定する（ステップＳ２３１）。例えば、現在使用中のストレージ量から、バックアップで確保すべきストレージ量を特定する。さらに、例えばバックアップを行う際に一般的に用いられるＣＰＵ量及びネットワークリソースを特定する。

そして、バックアップ処理部２１４は、バックアップのために確保すべきリソースのデータを含むバックアップ開始要求を、副系クラウドシステム３００のクラウド連携サーバ３１０に送信する（ステップＳ２３３）。

これに対して、副系クラウドシステム３００のクラウド連携サーバ３１０におけるバックアップ処理部３１４は、副系クラウドシステム２００のクラウド連携サーバ２１０から、確保すべきリソースのデータを含むバックアップ開始要求を受信する（ステップＳ２３５）。

そうすると、副系クラウドシステム３００は、バックアップのためのリソース確保処理を実行する（ステップＳ２３７）。このリソース確保処理については、図１６と同様である。なお、実行主体が、副系クラウドシステム２００ではなく副系クラウドシステム３００となる。

その後、クラウド連携サーバ３１０のバックアップ処理部３１４は、バックアップ開始要求に対する応答を、クラウド連携サーバ２１０のバックアップ処理部２１４に送信する（ステップＳ２３９）。クラウド連携サーバ２１０のバックアップ処理部２１４は、副系クラウドシステム３００のクラウド連携サーバ３１０から、バックアップ開始要求に対応する応答を受信する（ステップＳ２４１）。そうすると、バックアップ処理部２１４は、ストレージ管理サーバ２５０にバックアップの開始を指示して、ストレージ管理サーバ２５０は、副系クラウドシステム３００におけるストレージ管理サーバ３５０と共にバックアップ処理を実行する（ステップＳ２４３及びＳ２４４）。バックアップ処理の具体的内容は、従来と同じであり、本実施の形態の主旨ではないので、これ以上の説明は省略する。その後処理は端子Ｉを介して図２８の処理に移行する。なお、上でも述べたように、例えば定期的に、権限委譲要求を、副系クラウドシステム２００から副系クラウドシステム３００に送信する。

図２８の処理の説明に移行して、ここで正系クラウドシステム１００が正常に動作するようになったものとする。

本実施の形態では、システムが障害から復帰した場合には、例えば管理情報格納部に格納されているデータから、権限委譲先のデータを読み出して、系復帰通知を送信するものとする。但し、クラウド連携サーバ間で、ハートビート等によって自システムが稼働中であることを通知するような機構を採用することで、系復帰が通知されるようにしても良い。

ここでは、正系クラウドシステム１００のクラウド連携サーバ１１０における復帰処理部１１７は、系復帰通知を、副系クラウドシステム２００のクラウド連携サーバ２１０に送信する（ステップＳ２４５）。

これに対して、副系クラウドシステム２００のクラウド連携サーバ２１０における復帰処理部２１７は、系復帰通知を、正系クラウドシステム１００のクラウド連携サーバ１１０から受信する（ステップＳ２４７）。そうすると、復帰処理部２１７は、復帰したクラウドシステムに関するデータを管理情報格納部２１１においてチェックする（ステップＳ２４９）。ここで、権限委譲元が正系クラウドシステム１００となっている管理情報及びリカバリ実施時刻のデータを読み出す。ここではリカバリを実行しているのでリカバリ実施時刻が読み出されるが、リカバリを実施していなければ、リカバリ実施時刻は読み出されない。

そして、クラウド連携サーバ２１０の復帰処理部２１７は、リカバリ実施時刻を含むリカバリ実施通知を、正系クラウドシステム１００のクラウド連携サーバ１１０へ送信する（ステップＳ２５１）。これに対して、クラウド連携サーバ１００の復帰処理部１１７は、クラウド連携サーバ２１０の復帰処理部２１７から、リカバリ実施時刻を含むリカバリ実施通知を受信すると（ステップＳ２５３）、管理情報格納部１１１にリカバリ実施時刻を格納する。

さらに、クラウド連携サーバ１１０の復帰処理部１１７は、正系クラウドシステム１００においてシステムを再稼働させるため、切り戻し要求を、副系クラウドシステム２００のクラウド連携サーバ２１０に送信する（ステップＳ２５５）。副系クラウドシステム２００のクラウド連携サーバ２１０の復帰処理部２１７は、正系クラウドシステム１００のクラウド連携サーバ１１０から、切り戻し要求を受信する（ステップＳ２５７）。そうすると、正系クラウドシステム１００のダウンに関連して別途権限委譲要求の送信先に確保しているリソースを解放するために、復帰処理部２１７は、上記権限委譲要求に係るリソースを解放させるためのリソース解放要求を、副系クラウドシステム３００のクラウド連携サーバ３１０へ送信する（ステップＳ２５９）。

副系クラウドシステム３００のクラウド連携サーバ３１０における解放処理部３１６は、副系クラウドシステム２００のクラウド連携サーバ２１０から、上記権限委譲要求に係るリソースを解放させるためのリソース解放要求を受信する（ステップＳ２６１）。そうすると、副系クラウドシステム３００は、リソース解放処理を実行する（ステップＳ２６３）。リソース解放処理については、図２１を用いて説明したとおりであるから、説明を省略する。但し、実行主体は異なる。

リソース解放処理が終了すると、クラウド連携サーバ３１０の解放処理部３１６は、上記権限委譲要求に含まれており且つ管理情報格納部３１１に格納された管理情報を、管理情報格納部３１１から削除する（ステップＳ２６４）。これによって、権限委譲要求が副系クラウドシステム２００から副系クラウドシステム３００へ送信されなくなっても、リカバリ処理を実行するような事態を回避できる。

さらに、解放処理部３１６は、リソース解放応答を、副系クラウドシステム２００のクラウド連携サーバ２１０へ送信する（ステップＳ２６５）。副系クラウドシステム２００のクラウド連携サーバ２１０における復帰処理部２１７は、副系クラウドシステム３００のクラウド連携サーバ３１０から、リソース解放応答を受信する（ステップＳ２６７）。このリソース解放応答に応じて、例えば管理情報格納部２１１において、副系クラウドシステム３００において解放されたリソースに係るシステムのデータを削除する。例えば、図２６の例では１つ目のレコードを削除することになる。処理は、端子Ｊ及びＫを介して図２９の処理に移行する。

以上のような処理を実行することで、正系クラウドシステム１００が復帰して切り戻しを行うと重複確保されたことになる、副系クラウドシステム３００のリソースが早期に解放されるようになる。

図２９の処理の説明に移行して、ステップＳ２６７の後に又はステップＳ２５９乃至Ｓ２６７に並行して、副系クラウドシステム２００のクラウド連携サーバ２１０におけるバックアップ処理部２１４は、管理情報格納部２１１に格納されているリソースデータ（図９）から、バックアップに用いられるリソースを特定する（ステップＳ２７９）。例えば、現在使用中のストレージ量から、バックアップで確保すべきストレージ量を特定する。さらに、例えばバックアップを行う際に一般的に用いられるＣＰＵ量及びネットワークリソースを特定する。

そして、バックアップ処理部２１４は、バックアップのために確保すべきリソースのデータを含むバックアップ開始要求を、正系クラウドシステム１００のクラウド連携サーバ１１０に送信する（ステップＳ２８１）。

これに対して、正系クラウドシステム１００のクラウド連携サーバ１１０におけるバックアップ処理部１１４は、副系クラウドシステム２００のクラウド連携サーバ２１０から、確保すべきリソースのデータを含むバックアップ開始要求を受信する（ステップＳ２８３）。

そうすると、正系クラウドシステム１００は、バックアップのためのリソース確保処理を実行する（ステップＳ２８５）。このリソース確保処理については、図１６と同様である。なお、実行主体が、副系クラウドシステム２００ではなく正系クラウドシステム１００となる。

その後、クラウド連携サーバ１１０のバックアップ処理部１１４は、バックアップ開始要求に対する応答を、クラウド連携サーバ２１０のバックアップ処理部２１４に送信する（ステップＳ２８７）。クラウド連携サーバ２１０のバックアップ処理部２１４は、正系クラウドシステム１００のクラウド連携サーバ１１０から、バックアップ開始要求に対応する応答を受信する（ステップＳ２８９）。そうすると、バックアップ処理部２１４は、ストレージ管理サーバ２５０にバックアップの開始を指示して、ストレージ管理サーバ２５０は、正系クラウドシステム１００におけるストレージ管理サーバ１５０と共にバックアップ処理を実行する（ステップＳ２９１及びＳ２９２）。バックアップ処理の具体的内容は、従来と同じであり、本実施の形態の主旨ではないので、これ以上の説明は省略する。

バックアップ処理が完了すると、副系クラウドシステム２００のクラウド連携サーバ２１０における復帰処理部２１７は、切り戻し応答を、正系クラウドシステム１００のクラウド連携サーバ１１０に送信する（ステップＳ２９３）。そうすると、正系クラウドシステム１００のクラウド連携サーバ１００における復帰処理部１１７は、副系クラウドシステム２００のクラウド連携サーバ２１０から、切り戻し応答を受信する（ステップＳ２９５）。処理は端子Ｌを介して図３０の処理に移行する。

図３０の処理の説明に移行して、復帰処理部１１７は、この切り戻しに係る管理情報を、管理情報格納部１１１から読み出し（ステップＳ２９７）、切り戻し用のリソースを特定する（ステップＳ２９９）。例えば管理情報に含まれるリソースのデータをそのまま採用しても良い。そして、正系クラウドシステム１００は、切り戻し用のリソースを確保するためのリソース確保処理を実行する（ステップＳ３０１）。このリソース確保処理は、図１６と同様である。但し、実施主体が、正系クラウドシステム１００であり、切り戻し用のリソースを確保する点で異なる。

リソース確保処理が完了すると、復帰処理部１１７は、ユーザ端末４００に対して、切り戻し準備完了通知を送信する（ステップＳ３０３）。ユーザ端末４００は、正系クラウドシステム１００のクラウド連携サーバ１１０から、切り戻し準備完了通知を受信し（ステップＳ３０５）、例えば表示装置に表示して、ユーザに確認させる。ユーザは、確認の上、ユーザ端末４００を操作して、切り戻し実行指示を入力する。そうすると、ユーザ端末４００は、切り戻し実行指示を受け付けて、切り戻し実行指示を正系クラウドシステム１００のクラウド連携サーバ１１０に送信する（ステップＳ３０７）。

そうすると、正系クラウドシステム１００のクラウド連携サーバ１１０における復帰処理部１１７は、切り戻し実行指示を受信し、切り戻し処理を実行する（ステップＳ３０９）。切り戻し処理自体は、従来と同じであり、本実施の形態の主旨ではないので、これ以上の説明は省略する。これによって、正系クラウドシステム１００において、システムが再稼働される。

以上のような処理を実行すれば、正系クラウドシステム１００が復帰する場合に用いられなくなる副系クラウドシステム３００で確保されたリソースを、早期に解放できるようになる。

以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、クラウド連携サーバ、ストレージ管理サーバ及びネットワーク管理サーバの機能ブロック構成は、プログラムモジュール構成と一致しない場合もある。

また、処理フローについても、処理結果が変わらない限り、ステップの実行順番を入れ替えたり、複数ステップの実行を並列に行うようにしても良い。

また、クラウド連携サーバ、ストレージ管理サーバ及びネットワーク管理サーバ並びにクラウドシステムに含まれる物理マシンは、コンピュータ装置であって、図３１に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本実施の形態をまとめると、以下のようになる。

本実施の形態の第１の態様に係る冗長処理方法は、第１のシステムにおける第１の情報処理装置によって実行され、（Ａ）第１のシステムの異常時に第１のシステムに代わって第１の処理を行う第２のシステムを特定し、（Ｂ）第２のシステムにおける第２の情報処理装置に対して、第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、（Ｃ）第２のシステムの異常を検出すると、第２のシステム以外の第３のシステムを特定し、（Ｄ）第３のシステムにおける第３の情報処理装置に対して、第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、（Ｅ）第２のシステムの復帰を検出すると、第２のシステムにおける第２の情報処理装置に対して、第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する処理を含む。

副系システムとなる第２のシステムがダウンしてしまった後に復帰しても、第２のシステムにおいて重複して確保されたリソースを早期に解放できるようになる。

また、上で述べた第２のシステムの異常を、第２の情報処理装置から、繰り返し送信される第１の要求に対する応答を所定時間内に受信しないことで検出するようにしても良い。他にも、ハートビートなどの既存の方法を用いるようにしても良い。

さらに、本冗長処理方法は、第２の情報処理装置から第１の要求に対する応答を受信した後、第１の処理に用いられるデータのバックアップを要求する第４の要求を、第２の情報処理装置に送信する処理をさらに含むようにしても良い。これによって、リカバリ処理を短時間で行うことができるようになる。

さらに、上で述べた第３の要求が、第１の要求に含まれるデータを削除する要求を含むようにしても良い。これによって、第２のシステムにおける第２の情報処理装置が、第１の要求に含まれるデータを用いて処理を行うことが無くなり、処理の不整合を回避できるようになる。

本実施の形態の第２の態様に係る冗長処理方法は、（Ａ）第１のシステムにおける第１の情報処理装置が、第１のシステムの異常時に第１のシステムに代わって第１の処理を行う第２のシステムを特定し、（Ｂ）第１の情報処理装置が、第２のシステムにおける第２の情報処理装置に対して、第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、（Ｃ）第２の情報処理装置が、第１のシステムの異常を検出した後、第２のシステムの異常時に第１及び第２のシステムに代わって第１の処理を行う第３のシステムを特定し、（Ｄ）第２の情報処理装置が、第３のシステムにおける第３の情報処理装置に対して、第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、（Ｅ）第１のシステムが復帰して第１の処理を第１のシステムに切り戻す場合には、第２の情報処理装置が、第３のシステムにおける第３の情報処理装置に対して、第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する処理を含む。

正系システムとなる第１のシステムがダウンしたことによって確保された第３のシステムにおけるリソースを、第１のシステムが復帰して切り戻しを行う場合には、早期に解放できるようになる。

なお、本冗長処理方法は、（Ｆ）第２の情報処理装置が、第１の処理に用いられるデータのバックアップを要求する第４の要求を、第３の情報処理装置に送信する処理をさらに含むようにしても良い。これによって、第３のシステムにおけるリカバリ処理が早期に行われるようになる。

さらに、上で述べた第３の要求が、第２の要求に含まれるデータを削除する要求を含むようにしても良い。これによって、第３のシステムにおける第３の情報処理装置が、第２の要求に含まれるデータに基づき無駄な処理を行わなくなり、処理の不整合を回避できるようになる。

なお、上で述べたような処理をプロセッサ又はコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭなどの光ディスク、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
第１のシステムにおける第１の情報処理装置が実行する冗長処理方法であって、
前記第１のシステムの異常時に前記第１のシステムに代わって第１の処理を行う第２のシステムを特定し、
前記第２のシステムにおける第２の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、
前記第２のシステムの異常を検出すると、前記第２のシステム以外の第３のシステムを特定し、
前記第３のシステムにおける第３の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、
前記第２のシステムの復帰を検出すると、前記第２のシステムにおける前記第２の情報処理装置に対して、前記第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する
処理を含む冗長処理方法。

（付記２）
前記第２のシステムの異常を、前記第２の情報処理装置から、繰り返し送信される第１の要求に対する応答を所定時間内に受信しないことで検出する
付記１記載の冗長処理方法。

（付記３）
前記第２の情報処理装置から前記第１の要求に対する応答を受信した後、前記第１の処理に用いられるデータのバックアップを要求する第４の要求を、前記第２の情報処理装置に送信する
処理をさらに含む付記１又は２記載の冗長処理方法。

（付記４）
前記第３の要求が、前記第１の要求に含まれる前記データを削除する要求を含む
付記１乃至３のいずれか１つ記載の冗長処理方法。

（付記５）
第１のシステムにおける第１の情報処理装置は、前記第１のシステムの異常時に前記第１のシステムに代わって第１の処理を行う第２のシステムを特定し、
前記第１の情報処理装置は、前記第２のシステムにおける第２の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、
前記第２の情報処理装置は、前記第１のシステムの異常を検出した後、前記第２のシステムの異常時に前記第１及び第２のシステムに代わって前記第１の処理を行う第３のシステムを特定し、
前記第２の情報処理装置は、前記第３のシステムにおける第３の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、
前記第１のシステムが復帰して前記第１の処理を前記第１のシステムに切り戻す場合には、前記第２の情報処理装置は、前記第３のシステムにおける前記第３の情報処理装置に対して、前記第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する
処理を含む冗長処理方法。

（付記６）
前記第２の情報処理装置は、前記第１の処理に用いられるデータのバックアップを要求する第４の要求を、前記第３の情報処理装置に送信する
処理をさらに含む付記５記載の冗長処理方法。

（付記７）
前記第３の要求が、前記第２の要求に含まれる前記データを削除する要求を含む
付記５又は６記載の冗長処理方法。

（付記８）
第１の情報処理装置を含む第１のシステムと、
第２の情報処理装置を含む第２のシステムと、
第３の情報処理装置を含む第３のシステムと、
を有し、
前記第１の情報処理装置は、
前記第１のシステムの異常時に前記第１のシステムに代わって第１の処理を行う前記第２のシステムを特定し、
前記第２のシステムにおける第２の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、
前記第２の情報処理装置は、
前記第１の要求を受信すると、当該第１の要求に含まれる前記データを格納し、
前記第１の情報処理装置は、
前記第２のシステムの異常を検出すると、前記第２のシステム以外の前記第３のシステムを特定し、
前記第３のシステムにおける第３の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、
前記第３の情報処理装置は、
前記第２の要求を受信すると、当該第２の要求に含まれる前記データを格納し、
前記第１の情報処理装置は、
前記第２のシステムの復帰を検出すると、前記第２のシステムにおける前記第２の情報処理装置に対して、前記第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する
冗長処理システム。

（付記９）
第１のシステムのための情報処理装置であって、
前記第１のシステムの異常時に前記第１のシステムに代わって第１の処理を行う第２のシステムを特定し、前記第２のシステムにおける第２の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、前記第２のシステムの異常を検出すると、前記第２のシステム以外の第３のシステムを特定し、前記第３のシステムにおける第３の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信する第１の処理部と、
前記第２のシステムの復帰を検出すると、前記第２のシステムにおける前記第２の情報処理装置に対して、前記第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する第２の処理部と、
を有する情報処理装置。

（付記１０）
第１の情報処理装置を含む第１のシステムと、
第２の情報処理装置を含む第２のシステムと、
を有し、
前記第１の情報処理装置は、
前記第１のシステムの異常時に前記第１のシステムに代わって第１の処理を行う第２のシステムを特定し、
前記第２のシステムにおける第２の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、
前記第２の情報処理装置は、
前記第１のシステムの異常を検出した後、前記第２のシステムの異常時に前記第１及び第２のシステムに代わって前記第１の処理を行う第３のシステムを特定し、
前記第３のシステムにおける第３の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、
前記第１のシステムが復帰して前記第１の処理を前記第１のシステムに切り戻す場合には、前記第３のシステムにおける前記第３の情報処理装置に対して、前記第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する
冗長処理システム。

１００ 正系クラウドシステム
１１０ クラウド連携サーバ
１５０ ストレージ管理サーバ
１６０ ネットワーク管理サーバ
２００，３００ 副系クラウドシステム
２１０，３１０ クラウド連携サーバ
２５０，３５０ ストレージ管理サーバ
２６０，３６０ ネットワーク管理サーバ
４００ ユーザ端末

Claims (10)

1. 第１のシステムにおける第１の情報処理装置が実行する冗長処理方法であって、
   前記第１のシステムの異常時に前記第１のシステムに代わって第１の処理を行う第２のシステムを特定し、
   前記第２のシステムにおける第２の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、
   前記第２のシステムの異常を検出すると、前記第２のシステム以外の第３のシステムを特定し、
   前記第３のシステムにおける第３の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、
   前記第２のシステムの復帰を検出すると、前記第２のシステムにおける前記第２の情報処理装置に対して、前記第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する
   処理を含む冗長処理方法。
2. 前記第２のシステムの異常を、前記第２の情報処理装置から、繰り返し送信される第１の要求に対する応答を所定時間内に受信しないことで検出する
   請求項１記載の冗長処理方法。
3. 前記第２の情報処理装置から前記第１の要求に対する応答を受信した後、前記第１の処理に用いられるデータのバックアップを要求する第４の要求を、前記第２の情報処理装置に送信する
   処理をさらに含む請求項１又は２記載の冗長処理方法。
4. 前記第３の要求が、前記第１の要求に含まれる前記データを削除する要求を含む
   請求項１乃至３のいずれか１つ記載の冗長処理方法。
5. 第１のシステムにおける第１の情報処理装置は、前記第１のシステムの異常時に前記第１のシステムに代わって第１の処理を行う第２のシステムを特定し、
   前記第１の情報処理装置は、前記第２のシステムにおける第２の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、
   前記第２の情報処理装置は、前記第１のシステムの異常を検出した後、前記第２のシステムの異常時に前記第１及び第２のシステムに代わって前記第１の処理を行う第３のシステムを特定し、
   前記第２の情報処理装置は、前記第３のシステムにおける第３の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、
   前記第１のシステムが復帰して前記第１の処理を前記第１のシステムに切り戻す場合には、前記第２の情報処理装置は、前記第３のシステムにおける前記第３の情報処理装置に対して、前記第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する
   処理を含む冗長処理方法。
6. 前記第２の情報処理装置は、前記第１の処理に用いられるデータのバックアップを要求する第４の要求を、前記第３の情報処理装置に送信する
   処理をさらに含む請求項５記載の冗長処理方法。
7. 前記第３の要求が、前記第２の要求に含まれる前記データを削除する要求を含む
   請求項５又は６記載の冗長処理方法。
8. 第１の情報処理装置を含む第１のシステムと、
   第２の情報処理装置を含む第２のシステムと、
   第３の情報処理装置を含む第３のシステムと、
   を有し、
   前記第１の情報処理装置は、
   前記第１のシステムの異常時に前記第１のシステムに代わって第１の処理を行う前記第２のシステムを特定し、
   前記第２のシステムにおける第２の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、
   前記第２の情報処理装置は、
   前記第１の要求を受信すると、当該第１の要求に含まれる前記データを格納し、
   前記第１の情報処理装置は、
   前記第２のシステムの異常を検出すると、前記第２のシステム以外の前記第３のシステムを特定し、
   前記第３のシステムにおける第３の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、
   前記第３の情報処理装置は、
   前記第２の要求を受信すると、当該第２の要求に含まれる前記データを格納し、
   前記第１の情報処理装置は、
   前記第２のシステムの復帰を検出すると、前記第２のシステムにおける前記第２の情報処理装置に対して、前記第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する
   冗長処理システム。
9. 第１のシステムのための情報処理装置であって、
   前記第１のシステムの異常時に前記第１のシステムに代わって第１の処理を行う第２のシステムを特定し、前記第２のシステムにおける第２の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、前記第２のシステムの異常を検出すると、前記第２のシステム以外の第３のシステムを特定し、前記第３のシステムにおける第３の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信する第１の処理部と、
   前記第２のシステムの復帰を検出すると、前記第２のシステムにおける前記第２の情報処理装置に対して、前記第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する第２の処理部と、
   を有する情報処理装置。
10. 第１の情報処理装置を含む第１のシステムと、
    第２の情報処理装置を含む第２のシステムと、
    を有し、
    前記第１の情報処理装置は、
    前記第１のシステムの異常時に前記第１のシステムに代わって第１の処理を行う第２のシステムを特定し、
    前記第２のシステムにおける第２の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第１の要求を送信し、
    前記第２の情報処理装置は、
    前記第１のシステムの異常を検出した後、前記第２のシステムの異常時に前記第１及び第２のシステムに代わって前記第１の処理を行う第３のシステムを特定し、
    前記第３のシステムにおける第３の情報処理装置に対して、前記第１の処理を行うために用いられるリソースに関するデータを含む第２の要求を送信し、
    前記第１のシステムが復帰して前記第１の処理を前記第１のシステムに切り戻す場合には、前記第３のシステムにおける前記第３の情報処理装置に対して、前記第１のシステムのために確保されたリソースを解放させるための第３の要求を送信する
    冗長処理システム。

Images