JP2012027656A

JP2012027656A - ディザスタリカバリシステムのための管理装置、方法及びプログラム

Info

Publication number: JP2012027656A
Application number: JP2010165159A
Authority: JP
Inventors: Kenichi Kanayama; 健一金山; Tomohiko Kusuda; 友彦楠田; Masaki Iida; 正樹飯田; Masakazu Hori; 雅和堀
Original assignee: Intec Inc Japan
Current assignee: Intec Inc Japan
Priority date: 2010-07-22
Filing date: 2010-07-22
Publication date: 2012-02-09
Anticipated expiration: 2030-07-22
Also published as: JP5512442B2

Abstract

【課題】バックアップリソースを共用として低コストを実現しつつ、地域に依存した災害等の障害発生時におけるユーザシステムに対するディザスタリカバリ機能を確実に提供する。
【解決手段】本システム１の管理装置４は、複数のデータセンターの各々の現在のリソース量を記憶している。この管理装置４は、ユーザシステムが必要とするリソース量が入力されると、ユーザシステムを配置した平常時のデータセンターが属する地域で障害が発生したと仮定して、該障害の影響が及ばない地域に属するデータセンターにユーザシステムを配置できるだけのリソース量を、バックアップリソースとして確保しておけるか否かを判断する。バックアップリソース確保可能と判断されると、ユーザシステムの平常時の配置先となるデータセンター及び該データセンターにおいて該ユーザシステムに割り当てられるべきプライマリリソース量を特定する情報を出力する。
【選択図】図１

Description

本発明は、例えば地震や洪水等の災害が起きた場合でも、情報通信システムによるサービスを継続できるよう、障害の生じたサービスを、災害の影響が及ばなかった場所にある設備により復旧させる、いわゆる「ディザスタリカバリ」の要請に対応するための技術に関する。

従来のディザスタリカバリ対応では、サービスを行うユーザシステム毎に、専用のバックアップ設備を用意することが一般的であり、障害時にのみ運用するバックアップシステムとして、平常時に運用するプライマリシステムと同等のサーバシステムを用意することになる。

このため、設備コストが、ディザスタリカバリ対応をしない場合と比較して、およそ２倍となってしまい、この導入コストの高さが、ディザスタリカバリ対応を進める上で大きな障害となっていた。

近年、サーバ仮想化技術の発達により、仮想化サーバに障害が発生した場合に、その仮想化サーバ上で動作する仮想マシンを、必要容量の空きリソースを有する他の（障害が発生していない）仮想化サーバ上で起動することが可能となってきている。このような技術の例として、非特許文献１に示される「ＶＭｗａｒｅＨｉｇｈＡｖａｉｌａｂｉｌｉｔｙ（ＨＡ）」が挙げられる。

また、非特許文献１には、「ＶＭｗａｒｅＳｉｔｅＲｅｃｏｖｅｒｙＭａｎａｇｅｒ（ＳＲＭ）」という技術も開示されている。これは、平常時に運用するプライマリシステムを動作させる「プロテクテッドサイト」とは別に、障害時に運用するバックアップシステムを動作させる「リカバリサイト」を設けて、「リカバリ・プラン」を実行することにより、簡単な操作で災害対策を行えるようにしたものである。

ヴイエムウェア株式会社著「ＶＭｗａｒｅ徹底入門」、２００８年１１月１２日、株式会社翔泳社発行

上記の「ＶＭｗａｒｅＳＲＭ」では、平常時の「リカバリサイト」において、災害対策の対象となるユーザシステム以外の仮想マシンを稼働させて、リソースを有効に活用することが可能である。また、一つの「リカバリサイト」のリソースを、複数の「プロテクテッドサイト」の共用のバックアップリソースとして利用することも可能であり、設備コストの高さという問題を解消できる可能性は、出てきている。

しかしながら、バックアップリソースを共用とする場合、同時期に障害の影響下にあるユーザシステムの数や使用するリソース量によって、バックアップリソースが足りないという事態が起こり得る。これに対し、各ユーザシステムにバックアップ優先度を設けて、優先度の高いユーザシステムはリカバリできるようにしておくという対策も考えられるが、どのユーザシステムにいつ障害が発生してもリカバリできるような確実なディザスタリカバリ対応が求められる場合には、不十分である。

また、実際の運用においては、仮想化サーバを収容するデータセンターが、地理的に広い範囲に分散して設置されることが一般的であるため、ユーザシステムを稼働させるデータセンターを、その中から自由に選択したいというユーザ（サービス提供者）の意向がある。しかし、上記の「ＶＭｗａｒｅＳＲＭ」のような技術では、一つの「リカバリサイト」と、そのリソースを共用する複数の「プロテクテッドサイト」との関係が、固定されているため、選択の自由度に乏しい。

本発明は、以上のような事情を考慮し、複数のデータセンターが地域的に分散しているという環境を活用して、バックアップリソースを共用として低コストを実現しつつ、地域に依存した災害等の障害発生時におけるユーザシステムに対するディザスタリカバリ機能を、確実に提供できるよう、また、ユーザシステムを稼働させるデータセンターの選択に自由度を付与できるよう、ユーザシステムの配置及びデータセンターのリソース量を管理する機構を実現することを目的とする。

本発明の原理に従って、複数のデータセンターのうちの一つにユーザシステムを配置するための管理装置が設けられる。ここで、各データセンターは、少なくとも一つの仮想化サーバを含み、前記仮想化サーバは、該仮想化サーバで動作する少なくとも一つの仮想マシンにより、配置されたユーザシステムを動作させることが可能なものであり、各データセンターが有すリソースは、ユーザシステムが平常時に使用するプライマリリソースとして割り当てられるという用途と、障害時のためのバックアップリソースとして確保されるという用途の、いずれに供することも可能なものである。

前記管理装置は、前記複数のデータセンターの各々の現在のリソース量に関する第１の情報を記憶する記憶手段と、ユーザシステムの配置要求として、該ユーザシステムが必要とするリソース量を示す第２の情報を入力する入力手段と、前記ユーザシステムを配置した平常時のデータセンターが属する地域で障害が発生したと仮定して、該障害の影響が及ばない地域に属するデータセンターに前記ユーザシステムを配置できるだけのリソース量を、バックアップリソースとして確保しておけるか否かを、前記第１の情報及び前記第２の情報に基づいて、判断する判断手段と、前記判断手段によるバックアップリソース確保可能の判断に応じて、前記ユーザシステムの平常時の配置先となるデータセンター及び該データセンターにおいて該ユーザシステムに割り当てられるべきプライマリリソース量を特定する情報を出力し、前記判断手段によるバックアップリソース確保不能の判断に応じて、前記ユーザシステムの配置要求を拒否する出力手段とを備える。

上記の構成により、いつ、どの地域で、障害が発生しても、障害発生地域のユーザシステムが別の地域で復旧稼働できるだけのバックアップリソースが確保されている状態を保つことが可能になり、確実なディザスタリカバリ対応を提供することが可能となる。また、各地域のバックアップリソースが、他の地域間で共用されるため、その分の設備コストを節約することが可能になる。さらに、各データセンターが有するリソースのうち、プライマリリソースとして使用される分とバックアップリソースとして確保される分とを、所望の割合に配分可能にできるため、データシステムの配置先となるデータセンターの選択に自由度を付与することが可能になる。

前記管理装置の判断手段は、前記第１の情報に基づき、前記複数のデータセンター全体においてプライマリリソースとしての使用を許可するリソース量であるトータルプライマリリソース容量を定め、前記第２の情報が示す前記ユーザシステムが必要とするリソース量が、前記トータルプライマリリソース容量の範囲内で割り当て可能であるか否かを判断する手段を含むものとしてもよい。

この構成により、複数の地域のデータセンター間全体でユーザシステムを平常時に稼働させるために使用できるリソース量の上限値が定まり、その残りのリソースが共用のバックアップリソースとして確保された状態にすることができる。

上記の構成において、ある地域で障害が発生したと仮定して、該障害の影響が及ばない地域に属するデータセンターが有するリソースの容量を合計する処理を、複数の地域について行うことにより、複数の合計リソース容量を得、これら合計リソース容量のうち最も小さいものを、前記トータルプライマリリソース容量として定めるようにしてもよい。

これにより、複数の地域のデータセンター間全体でユーザシステムを平常時に稼働させるために使用できるリソース量の上限値を、どの地域で障害が発生しても、他の地域で障害復旧が可能なだけのバックアップリソースが確保されるように、算出することができる。これは、同時期に障害の影響を受けるのは一つの地域だけであるという特性を活かし、どの地域で障害が発生するかによってバックアップリソースが余ることはあっても、足りないことはないということを保証できる範囲でのみ、プライマリリソースの割り当てを許可するものである。

前記管理装置の判断手段は、前記第１の情報に基づき、前記ユーザシステムの平常時の配置先となるデータセンターにおいてプライマリリソースとしての使用を許可するリソース量である個別プライマリリソース容量を定め、前記第２の情報が示す前記ユーザシステムが必要とするリソース量が、前記個別プライマリリソース容量の範囲内で割り当て可能であるか否かを判断する手段を含むものとしてもよい。

この構成により、複数の地域のデータセンター間全体で共用のバックアップリソースが確保された状態で、配置要求のあったユーザシステムの平常時の配置先をどのデータセンターにするかを決めることが可能になる。

上記の構成において、所定の基準により選択されたデータセンターを、前記ユーザシステムの平常時の配置先となるデータセンターの候補として、前記判断手段における判断を行うようにしてもよい。

これにより、ユーザ（サービス提供者）の意向を反映させて、ユーザシステムの平常時の配置先となるデータセンターを決めることが可能になる。所定の基準としては、例えば、クライアントへの通信の遅延が少ない地域を優先する、自治体等の地域に関連する情報を同一地域のデータセンターに保存できるようにする、データセンター間で各種リソース間の使用量のバランスが取れるようにする、等があり得る。

前記管理装置は、前記ユーザシステムを配置した平常時のデータセンターが属する地域で障害が発生した場合に前記ユーザシステムが配置される障害時のデータセンターを、前記障害の影響が及ばない地域に属するデータセンターの中から選定する選定手段をさらに備えてもよい。

この構成により、複数の地域のデータセンター間全体で確保された共用のバックアップリソースから、障害の発生したユーザシステムを復旧稼働するためのリソースを、どのデータセンターにおいて割り当てるか決めることが可能になる。

上記の構成において、所定の基準により選択されたデータセンターを、前記ユーザシステムの障害時の配置先となるデータセンターの候補として、前記選定手段における選定を行うようにしてもよい。

これにより、ユーザ（サービス提供者）の意向を反映させて、ユーザシステムの障害時の配置先となるデータセンターを決めることが可能になる。所定の基準としては、例えば、クライアントへの通信の遅延が少ない地域を優先する、自治体等の地域に関連する情報を同一地域のデータセンターに保存できるようにする、データセンター間で各種リソース間の使用量のバランスが取れるようにする、等があり得る。障害時の配置先を決めるための基準と、平常時の配置先を決めるための基準は、同一であっても異なるものであってもよい。

上記の構成において、前記選定手段は、前記第１の情報に基づき、前記ユーザシステムの障害時の配置先となるデータセンターにおいてバックアップリソースとして使用可能なリソース量である個別バックアップリソース容量を定め、前記第２の情報が示す前記ユーザシステムが必要とするリソース量が、前記個別バックアップリソース容量の範囲内で割り当て可能であるか否かを判断する手段を含むものであってもよい。

これにより、ユーザシステムの障害時の配置先として、そのユーザシステムを復旧稼働するためのリソースを割り当て可能なデータセンターを選ぶことが可能になる。

上記の構成において、前記判断手段による判断を行う際に、前記選定手段による選定を行い、前記出力手段は、前記ユーザシステムの平常時の配置先となるデータセンターを特定する情報の出力に加えて、前記ユーザシステムの障害時の配置先となるデータセンターを特定する情報の出力を行うものであり、前記選定手段において前記ユーザシステムの障害時の配置先となるデータセンターが選定できなかった場合には、前記ユーザシステムの配置要求を拒否するようにしてもよい。

これにより、配置要求のあったユーザシステムの平常時の配置先データセンターを決める際に、そのユーザシステムの障害時の配置先データセンターも決めておくことができる。この選定タイミングは、例えば、後述する最小分割リソース量による制御を行う方式において、特に有用である。また、後述するバックアップリソース容量固定方式においても、有用である。

上記の構成において、前記障害が発生した際に、前記選定手段により選定を行い、前記ユーザシステムの障害時の配置先となるデータセンター及び該データセンターにおいて該ユーザシステムに割り当てられるべきバックアップリソース量を特定する情報を出力する追加出力手段をさらに備えるようにしてもよい。

これにより、障害が発生した際に、障害の発生したユーザシステムを復旧させる配置先データセンターを決めることができる。この選定タイミングは、例えば、後述するバックアップリソース容量非固定方式において、特に最小分割リソース量による制御を行わない場合に、有用である。また、最小分割リソース量による制御を行わないバックアップリソース容量固定方式においても、有用である。

上記の構成において、前記判断手段は、前記ユーザシステムの平常時の配置先となるデータセンターが有するリソースの容量までのリソース量が、プライマリリソースとしての使用が許可されているものとして、該データセンターにおいて前記ユーザシステムが必要とするリソース量が割り当て可能であるか否かを判断する手段を含み、前記選定手段は、前記ユーザシステムの障害時の配置先となるデータセンターが有するリソースの容量から、現在使用されているリソース量を除いた容量の範囲内で、該データセンターにおいて前記ユーザシステムが必要とするリソース量が割り当て可能であるか否かを判断する手段を含むようにしてもよい。

これが、バックアップリソース容量非固定方式であり、この方式によれば、各データセンターで固定的にバックアップリソース容量を予め確保しておくことはしないため、ユーザシステムの平常時の配置先データセンターを選ぶ際の自由度を高くすることが可能である。

バックアップリソース容量非固定方式の場合、前記管理装置が、前記ユーザシステムの平常時の配置先となるデータセンターを障害時の配置先とする他のユーザシステムが、該データセンターにおいて必要とするリソース量が、割り当て可能であるか否かを判断し、割り当て可能でない場合には、該他のユーザシステムの障害時の配置先となるデータセンターの選定をし直す再選定手段をさらに備えるようにしてもよい。

この再選定手段は、配置要求のあったユーザシステムの平常時の配置先データセンターを決める際に、そのユーザシステムの障害時の配置先データセンターも決めておく場合に、特に有用である。バックアップリソース容量非固定方式の場合、ユーザシステムを平常時の配置先データセンターで稼働させると、そのデータセンターにおけるバックアップリソース容量が減少するためである。なお、障害が発生した際に、障害の発生したユーザシステムを復旧させる配置先データセンターを決める場合には、この再選定手段はなくてよい。

代替的に、上記の構成において、前記判断手段は、前記ユーザシステムの平常時の配置先となるデータセンターが有するリソースの容量から、該データセンターにおいてバックアップリソースとして予め確保されているバックアップリソース容量を除いた容量までのリソース量が、プライマリリソースとしての使用が許可されているものとして、該データセンターにおいて前記ユーザシステムが必要とするリソース量が割り当て可能であるか否かを判断する手段を含み、前記選定手段は、前記ユーザシステムの障害時の配置先となるデータセンターにおいてバックアップリソースとして予め確保されているバックアップリソース容量の範囲内で、該データセンターにおいて前記ユーザシステムが必要とするリソース量が割り当て可能であるか否かを判断する手段を含むようにしてもよい。

これが、バックアップリソース容量固定方式であり、この方式によれば、各データセンターで固定的にバックアップリソース容量を予め確保しておくため、各ユーザシステムについて一度、障害時の配置先となるデータセンターを選定すればよく、再選定を不要とすることが可能である。

バックアップリソース容量固定方式の場合、前記複数のデータセンター全体においてバックアップリソースとして確保されるリソース量であるトータルバックアップリソース容量を、複数のデータセンターに割り振ることにより、各データセンターにおいてバックアップリソースとして予め確保される前記バックアップリソース容量が定められているようにしてもよい。

トータルバックアップリソース容量をどのような比率で複数のデータセンターに割り振るかは、各データセンターの特質や各ユーザ（サービス提供者）の意向等を考慮して、管理者が決めればよい。

前記管理装置は、前記ユーザシステムが平常時に配置されるデータセンターとして、二つ以上のデータセンターを選定し、前記ユーザシステムが必要とするリソース量を該二つ以上のデータセンターに割り振ることにより、プライマリリソース量の割り当てを可能とする分割手段をさらに備えてもよい。

この構成により、ユーザシステムを平常時に配置するデータセンターを決める際、複数のデータセンター全体としてのプライマリリソースは足りているのに、その中のどれか一つのデータセンターへユーザシステムを配置しようとすると容量が収まる先がないという事態になっても、ユーザシステムを分割して二つ以上のデータセンターに配置することによって、ユーザシステムの配置要求に肯定的に応えることが可能になる。

前記管理装置は、前記ユーザシステムが障害時に配置されるデータセンターとして、二つ以上のデータセンターを選定し、前記ユーザシステムが必要とするリソース量を該二つ以上のデータセンターに割り振ることにより、前記障害が発生した際のバックアップリソース量の割り当てを可能とする分割手段をさらに備えてもよい。

この構成により、ユーザシステムを障害時に配置するデータセンターを決める際、複数のデータセンター全体としてのバックアップリソースは足りているのに、その中のどれか一つのデータセンターへユーザシステムを配置しようとすると容量が収まる先がないという事態になっても、ユーザシステムを分割して二つ以上のデータセンターに配置することによって、ユーザシステムの配置要求に肯定的に応えることが可能になる。特に、障害が発生した時にユーザシステムの復旧を行う配置先データセンターを決める方式では、どこかのデータセンターでユーザシステムの障害復旧ができるという前提で、平常時の配置を行って配置要求を受け付けているのであるから、分割をしてでも障害時の配置を実現することが望ましい。

上記の構成において、前記第２の情報は、前記ユーザシステムが必要とするリソース量を二つ以上のデータセンターに割り振る場合に、各データセンターで最低限割り当てられるべき、最小分割リソース量を示す情報を含み、前記分割手段は、前記第２の情報を参照してリソース量の割り振りを行う手段を含むようにしてもよい。

この最小分割リソース量に従って、ユーザシステムの分割を行うことにより、ユーザシステムを過度に小さく分割してしまうと動作に支障が出る可能性があるところ、そのような事態を回避することが可能になる。

上記の構成において、前記出力手段は、前記ユーザシステムの平常時の配置先となるデータセンターを特定する情報の出力に加えて、前記ユーザシステムの障害時の配置先となるデータセンターを特定する情報の出力を行うものであり、前記管理装置が、前記分割手段において前記最小分割リソース量に従った割り振りができなかった場合には、他のユーザシステムの障害時の配置先となるデータセンターの選定をし直す再選定手段をさらに備えるようにしてもよい。

最小分割リソース量による制御を行う方式では、複数のデータセンター全体としてのプライマリリソースは足りているのに、最小分割リソース量以上の使用可能なリソース容量が残っているデータセンターがなく、障害時にユーザシステムを復旧させる配置先がないという事態が起こり得る。これを防ぐには、配置要求のあったユーザシステムの平常時の配置先データセンターを決める際に、そのユーザシステムの障害時の配置先データセンターも決めておくようにし、障害時の配置先を決めることができないならば、バックアップリソース確保不能であると判断して、ユーザシステムの配置要求を拒否することが望ましい。また、他のユーザシステムの障害時の配置先となるデータセンターの選定をし直して、配置要求のあったユーザシステムの障害時の配置先を決めることができる可能性を高くするようにしてもよい。

上記の構成において、前記ユーザシステムが必要とするリソース量を二つ以上の障害時の配置先となるデータセンターに割り振る場合の最小分割リソース量の条件が、平常時の配置先となるデータセンターに割り振る場合の条件よりも、緩和して設定されていてもよい。

これにより、ユーザシステムを小さく分割すると動作が遅くなる等の不利益を被る可能性があるところ、平常時は動作の快適性等を重視してなるべく大きく分割するようにし、障害時は配置先データセンターが見つかる可能性を重視して小さく分割することを許容するという、細かい制御が可能になる。

上述したユーザシステムは、少なくとも一つのアプリケーションサーバと、該アプリケーションサーバをネットワーク経由でクライアントからアクセス可能とするための手段（例えば、ゲートウェイ等の中継装置）とを含み、前記アプリケーションサーバは、前記仮想マシンにより実現されるものであってもよい。アプリケーションサーバがサービス処理に用いるデータは、アプリケーションサーバ内に格納してもよいし、別のサーバに格納してそのサーバにアクセスするためのゲートウェイをユーザシステムがさらに含むようにしてもよい。

ユーザシステムが複数のアプリケーションサーバを含む場合、各アプリケーションサーバに目安として割り当てられるリソース量の比率を予め定めておいてもよい。この比率を、そのユーザシステムを大規模なリソースにより稼働する必要が生じた際に、同じユーザシステムをコピーして複数配置することによって拡張が可能なように定めておくと、各ユーザシステムを最小リソース構成で登録しておき、それを必要に応じて拡張して大規模化するという運用が、可能になる。

前記管理装置が、前記ネットワークにおける名前解決サーバに、前記ユーザシステムのサービス公開用の名前と、前記ユーザシステムが配置されたデータセンターを前記ネットワークにおいて特定可能なアドレスとの対応を、登録することにより、前記クライアントからのアクセスを可能とする手段をさらに備えるようにしてもよい。

これにより、平常時の配置先データセンターでユーザシステムが稼働している間は、ユーザシステムの名前を基に問い合わせると、平常時の配置先データセンターのアドレスが得られ、障害が発生して障害時の配置先データセンターでユーザシステムが復旧稼働するようになると、登録内容が書き換わるため、同じユーザシステムの名前を基に問い合わせれば、障害時の配置先データセンターのアドレスが得られる。また、ユーザシステムを分割して配置する場合には、一つの名前に複数のアドレスが対応して登録され、負荷分散等の機構を用いて、いずれか一つのアドレスを得ることが可能になる。

上述した管理装置が、一つの地域で発生した障害が一つ以上の異なる地域に属するデータセンターに影響を与える可能性がある場合の、障害発生地域とその影響が及ぶデータセンターとの関係を示す第３の情報を記憶する記憶手段をさらに備え、前記判断手段は、前記第３の情報を参照して判断を行う手段を含むものとしてもよい。

この構成により、災害が発生すると各データセンターに影響を与える可能性のある各区域間に重複があるような場合でも、いつ、どの地域で、障害が発生しても、障害発生地域のユーザシステムが別の地域で復旧稼働できるだけのバックアップリソースが確保されている状態を保つことが可能になる。

代替的に、前記複数のデータセンターは、あるグループで発生した障害が他のグループのデータセンターには影響を与えないように、地域毎にグループ分けされており、各グループ内のデータセンターが有するリソースの合計容量のうち最も大きいものを、前記複数のデータセンター全体が有するリソースの容量から減算した容量を、前記複数のデータセンター全体においてプライマリリソースとしての使用を許可するリソース量としてもよい。

この構成によれば、災害が発生すると各データセンターに影響を与える可能性のある各区域間に重複がないようにできるため、いつ、どの地域で、障害が発生しても、障害発生地域のユーザシステムが別の地域で復旧稼働できるだけのバックアップリソースを、複数のデータセンター全体で確保するためのトータルプライマリリソース容量を、簡単に求めることが可能である。

以上に管理装置として記述した各発明は、複数のデータセンターのうちの一つにユーザシステムを配置するための管理方法の発明としても、コンピュータを上記の管理装置として動作させるための管理プログラムの発明としても、該管理プログラムを記憶した記憶媒体の発明としても、成立するものである。

以上のように、本発明によれば、複数のデータセンターが地域的に分散しているという環境を活用して、バックアップリソースを共用として低コストを実現しつつ、地域に依存した災害等の障害発生時におけるユーザシステムに対するディザスタリカバリ機能を、確実に提供することが可能になる。また、ユーザシステムを稼働させるデータセンターの選択に自由度を付与することも可能になる。

本発明の実施の形態における管理装置を備えるシステム（本システム）の説明図データセンター間（ＤＣ間）のデータ同期の説明図各リソース量（キャパシティ、プライマリリソース、バックアップリソース）の説明図各リソース量の関係を示す説明図（ａ）リソースユニット（ＲＵ）の一例を示す図（ｂ）各ＤＣ（ＤＣ１とＤＣ２）のリソース量の算出の一例を示す図データセンター関連の管理情報の一例を示す図ユーザシステム関連の管理情報の一例を示す図バックアップＤＣ選定のタイミングの説明図非固定方式で、最小分割リソース量の保証がない場合の処理フローの説明図非固定方式で、最小分割リソース量の保証がある場合の処理フローの説明図固定方式の場合の処理フローの説明図エリアの定義の一例を示す図災害発生エリアとその影響のあるＤＣの関係を示す図各ＤＣのリソース量の一例（ＴＰの計算の具体例）を示す図トータルプライマリリソース容量ＴＰの計算結果の一例を示す図単純なモデルの場合のトータルプライマリリソース容量ＴＰの計算の説明図プライマリＤＣの選定条件の一例を示す図バックアップＤＣの満たすべき条件の一例を示す図災害発生エリアと影響のあるＤＣの関係の一例を示す図ユーザシステムの構成の説明図ユーザシステムの管理情報と値の一例を示す図配置先のＤＣに応じて決定する設定項目と値の一例を示す図リソース利用効率が向上するような配置先ＤＣの選択の説明図バックアップリソース共有の効果の説明図各地域のリソースのメイン用途とバックアップ用途の割り当ての例を示す図

（本システムの構成）
以下、本発明の一つの実施の形態の管理装置について、図面を用いて説明する。ここでは、管理装置を備えるシステム（以下、本システムという）を例示して説明する。図１は、本システムの構成を示す説明図である。図１に示すように、本システム１は、複数の地域（大阪、東京、富山など）に分散して配置された複数のデータセンター２を備えている。この例では、大阪に２つのデータセンター２（図では、ＤＣ−１、２）が設置され、東京に２つのデータセンター２（ＤＣ−３、４）が設置され、富山に２つのデータセンター２（ＤＣ−５、６）が設置されている。

各データセンター２では、それぞれユーザシステム３が稼働されている。例えば、ＤＣ−１では、ユーザシステム−１、２が稼働されており、ＤＣ−２では、ユーザシステム−３が稼働されている。また、ＤＣ−３では、ユーザシステム−４、５が稼働されており、ＤＣ−４では、ユーザシステム−６、７が稼働されている。さらに、ＤＣ−５では、ユーザシステム−８が稼働されており、ＤＣ−６では、ユーザシステム−９が稼働されている。

管理装置４は、各データセンター２とネットワーク接続されており、各データセンター２との間で情報通信をすることができる。この管理装置４は、コンピュータ装置などで構成されており、メモリやＨＤＤなどで構成される記憶部５と、キーボードやマウスなどで構成される入力部６と、ＭＰＵやＣＰＵなどで構成される処理部７と、液晶ディスプレイなどで構成される表示部８を備えている。そして、この管理装置４は、後述するように、障害発生時におけるユーザシステム３に対するディザスタリカバリ機能を提供するための各種の機能を備えている。これらの機能は、管理装置４のＨＤＤやメモリ等に格納されたプログラムによって実現することができる。

（本システムの機能）
本システム１は、次の３つの機能を備えている。第１の機能は「地域規模の障害発生に確実に対応する機能」である。この機能により、「いつ」「どの地域」で障害が発生しても、障害発生地域のすべてのユーザシステム３が別地域で復旧稼働できるだけのバックアップリソースが常に確保されていることを保証することができ、障害時に迅速に復旧を行うことができるようになる。

第２の機能は「地域間のバックアップリソースの共用により、必要バックアップリソース量を最小限化できる機能」である。各地域のバックアップリソースをその他の地域間で共用することにより、そのような共有をしない場合と比較して、全体として必要なバックアップリソース量を削減することができる。

第３の機能は「ユーザシステムの配置先のデータセンターを自由に選択できる機能」である。例えば、通信遅延がなるべく少ない地域のデータセンター２にシステムを配置したい場合、地域に関連する情報処理（自治体の情報処理など）を同一地域のデータセンター２で実施したい場合、データセンター間で各種リソース（ＣＰＵ、メモリ、ネットワーク等）間の使用量のバランスをとりながらデータセンター２を追加したい場合などに、この機能は有効である。

本システム１では、各データセンター２のリソースプールのうち、定常利用のプライマリリソースとその残りのバックアップリソースとして確保する量の配分を、第１の機能と第２の機能を実現できるような範囲で自由に設定することができるので、第３の機能を実現すること、すなわち、３つの機能をすべて実現することができる。

（本システムの特徴）
本システム１は、上記の３つの機能をすべて実現することができるように、以下の２つの特徴を備えているともいえる。第１の特徴は「全データセンターでのバックアップリソースの統合管理」である。各地域で必要なバックアップリソースの確保を個別に行ったのでは、地域間のバックアップリソースの共有を効果的に行うことはできない。そのため、本システム１では、まず「各地域のデータセンター間全体」でユーザシステム３を平常時に稼働させるために使用できるリソース量の上限値（トータルプライマリリソース容量）を算出し、その残りのリソースを共有バックアップリソースとして確保している。この上限値は、どの地域で障害が発生しても、その他の地域で障害復旧が可能なだけのバックアップリソースが確保されるように算出される。したがって、本システム１では、上記のデータセンター間全体の上限値を超えない範囲で、ユーザシステム３を、希望する地域のデータセンター２へ自由に配置することができる。

第２の特徴は「ユーザシステムの分散配置対応」である。ある程度以上のリソース量を必要とするユーザシステム３では、データセンター全体としてのプライマリリソース、あるいは、バックアップリソースは足りていても、個々のデータセンター２へ配置する際には容量が収まる先がないケースが発生するおそれがある。そのため、本システム１では、各ユーザシステム３を最小リソース構成で登録し、それを拡張技術（クラスタ化）によって、必要に応じて大規模リソースによる稼働にも展開可能としている。さらに、本システム１では、個別のデータセンターレベルでリソースが不足する場合には、複数のデータセンター上で合計値が必要なリソース量となるようにユーザシステム３を稼働し、それをＤＮＳ等の名前解決技術との連携によって、ユーザからは一つのシステムとして利用することができる。

（本システムの前提）
本システム１は、データセンター間（ＤＣ間）のデータ同期による機能の利用を前提としている。まず、ＤＣ間のデータ同期について、図２を参照しながら説明する。図２は、ＤＣ間のデータ同期の説明図である。図２に示すように、データセンター２は、ゲートウェイサーバ９とＤＮＳサーバ１０と仮想化サーバ１１とデータベースサーバ１２とストレージサーバ１３を備えている。仮想化サーバ１１としては、例えば「ＶＭｗａｒｅＳｅｒｖｅｒ」や「ＶＭｗａｒｅＥＳＸ」等を利用することができる。各データセンター２のデータベースサーバ１２とストレージサーバ１３は、データ同期回線（専用線、ＶＰＮ回線等）で接続されており、データが同期されている。ここでは、各ＤＣ間のデータ同期の方法や方式の詳細については特に言及しないが、例えば、既知のストレージ間のレプリケーション機能を利用することができる。各ＤＣ間でデータ同期されると、あるＤＣ及びそのＤＣのストレージに障害が発生しても、同じユーザシステム３を再起動するのに必要なデータを別のＤＣのストレージから得ることができる。

本システム１のディザスタリカバリ機能は、各ＤＣ間のデータ同期による２つの機能が利用可能であることを前提としている。１つ目の機能は「全ＤＣにおける各ユーザシステムのアプリケーションサーバを起動する機能」である。この機能により、各アプリケーションサーバ１４の起動イメージは、ＤＣ間でデータ同期が行われるストレージサーバ１３上に保存され、いずれのＤＣのストレージからでも起動することができるようになる。２つ目の機能は「全ＤＣにおける各ユーザシステム３のアプリケーションデータへアクセスする機能」である。この機能により、アプリケーションデータは、ＤＣ間でデータ同期が行われているストレージまたはデータベースサーバ１２上に保存され、いずれのＤＣにおいても、ユーザシステム３は、そのストレージまたはデータベースサーバ１２からアプリケーションデータへアクセスすることができるようになる。

つぎに、各ＤＣのリソース量の考え方について、図２〜図５を参照しながら説明する。図３は、各リソース量（キャパシティ、プライマリリソース、バックアップリソース）の説明図である。図３に示すように、各ＤＣのリソース量には、ｎ番目（ｎ＝１、２・・・）のデータセンター２（ＤＣ−ｎ）の持つリソース全体の容量である「キャパシティＣ_n」と、ＤＣ−ｎのプライマリリソース（ユーザシステム３により平常時に使用されるリソース）として使用可能な容量である「プライマリリソースＰ_n」と、ＤＣ−ｎのバックアップリソース（平常時に使用されないリソース）としての容量である「バックアップリソースＢ_n」が含まれる。

図４は、各リソース量の関係を示す説明図である。図４に示すように、各ＤＣのリソース量（キャパシティＣ_n、プライマリリソースＰ_n、バックアップリソースＢ_n）の関係は、以下の式（１）で表すことができる。

ＤＣのリソースには、ＣＰＵ、メモリ、ネットワークなど複数の種類のものが含まれる。したがって、ＤＣのリソース量は、種類ごとに値を持ち、複数次元的である。これを処理の単純化等のために、次のように一次元化してもよい。

まず、各種リソースをひとまとめにして取り扱うための最小単位（リソースユニット、ＲＵ）を決定する。リソースユニットは、ユーザシステム３に対して割り当て量を保証する各リソース（ＣＰＵ、メモリ、ネットワーク等）の最小単位の集合として任意に定めることができる。図５（ａ）には、リソースユニット（ＲＵ）の一例が示されている。この例では、ＣＰＵについては２．０ＧＨｚを１ＲＵとし、メモリについては２．０ＧＢを１ＲＵとし、ネットワークについては１．０Ｍｂｐｓを１ＲＵとしている。

なお、ここでの最小単位（ＲＵ）は、ユーザシステム３に対する割り当て量であるため、ユーザシステム３には常に整数［ＲＵ］が割り当てられるが、ユーザシステム３が複数のアプリケーションサーバ１４を含む場合には、各アプリケーションサーバ１４に小数［ＲＵ］が割り当てられることも許容される。

次に、このようなリソースユニットという単位を用いて、各ＤＣのリソース量を算出する。具体的には、リソース種別ごとに何ＲＵ分に相当するかを計算し、その中で最も値の小さなものを、そのＤＣのリソース量とする。図５（ｂ）には、各ＤＣ（ＤＣ−１とＤＣ−２）のリソース量の算出の一例が示されている。この例では、ＤＣ−１について、ＣＰＵのリソース量が３５０ＲＵと換算され、メモリのリソース量が４００ＲＵと換算され、ネットワークのリソース量が４００ＲＵと換算されるので、その中の最小値である３５０ＲＵが、ＤＣ−１のリソース量として算出される。また、ＤＣ−２については、ＣＰＵのリソース量が３００ＲＵと換算され、メモリのリソース量が２５０ＲＵと換算され、ネットワークのリソース量が３００ＲＵと換算されるので、その中の最小値である２５０ＲＵが、ＤＣ−２のリソース量として算出される。

なお、他の例として、全てのリソース種別は考慮せず、選択された種別のリソースのみに着目し、その種別のリソースの量をＲＵ単位のリソース量としてもよい。例えば、図５（ｂ）の例において、ＣＰＵのリソースのみに着目し、ＤＣ−１のリソース量を３５０ＲＵ（そのまま）とし、ＤＣ−２のリソース量を３００ＲＵとしてもよい。

（管理情報）
続いて、本システム１で用いられる管理情報について、図６と図７を参照して説明する。本システム１の管理情報には、データセンター関連の管理情報とユーザシステム関連の管理情報が含まれる。図６は、データセンター関連の管理情報の一例を示す図である。図６に示すように、データセンター関連の管理情報は、個々のデータセンター２（ＤＣ_n）に関する個別ＤＣ関連の管理情報と、ＤＣ全体の管理情報とに大別される。

個別ＤＣ関連の管理情報には、ＤＣの各リソース（ＣＰＵ、メモリ、ネットワーク）の容量を示す「各種リソース容量Ｃ_n」と、ＤＣのプライマリ用の各リソース（ＣＰＵ、メモリ、ネットワーク）の容量を示す「プライマリリソース容量Ｐ_n」と、ＤＣのバックアップ用の各リソース（ＣＰＵ、メモリ、ネットワーク）の容量を示す「バックアップリソース容量Ｂ_n」と、ＤＣのプライマリ用の各リソース（ＣＰＵ、メモリ、ネットワーク）の使用量を示す「プライマリリソース使用量Ｕ_n」が含まれる。また、個別ＤＣ関連の管理情報には、ユーザシステム３のＤＣ配置時に用いられる「ユーザシステム用ＩＰアドレスリスト」と「ユーザシステム用ＶＬＡＮＩＤリスト」の情報が含まれる。

ＤＣ全体の管理情報には、ＤＣ全体のプライマリリソース容量を示す「トータルプライマリリソース容量ＴＰ」と、ＤＣ全体のバックアップリソース容量を示す「トータルバックアップリソース容量ＴＢ」の情報が含まれる。なお、「トータルプライマリリソース容量ＴＰ」と「トータルバックアップリソース容量ＴＢ」の算出方法については後述する。

個別ＤＣ関連の管理情報は、データセンター２の管理者の申告に基づいて登録される。例えば、「各種リソース容量Ｃ_n」と「ユーザシステム用ＩＰアドレスリスト」と「ユーザシステム用ＶＬＡＮＩＤリスト」については、データセンター２の管理者が申告した値が登録される。なお、「プライマリリソース容量Ｐ_n」と「バックアップリソース容量Ｂ_n」については、本システム１の管理装置４で算出または決定された値が登録される。「プライマリリソース使用量Ｕ_n」は、ユーザシステムの追加による使用量の増加にあわせて、本システム１の管理装置４により更新することができる。

図７は、ユーザシステム関連の管理情報の一例を示す図である。図７に示すように、ユーザシステム関連の管理情報は、各ユーザシステム（Ｓｍ）に関するユーザシステム構成関連の管理情報と、ユーザシステム配置先ＤＣ関連の管理情報とに大別される。

ユーザシステム構成関連の管理情報には、ユーザシステム３が必要とするリソース量を示す「必要リソース量Ｒ_m」と、ユーザシステム３をＤＣ分散配置する場合に分割された各ユーザシステム３に最低限割り当てるべきリソース量を示す「最小分割リソース量Ｒｍｉｎ_m」が含まれる。なお、ユーザシステム３をＤＣ分散配置する場合は、合計値として割り当てるべきリソース量が「必要リソース量Ｒ_m」となる。また、ユーザシステム構成関連の管理情報には、各種の構成情報が含まれる。構成情報には、サービス公開用ホスト名、サービス公開用プロトコル、サービスのヘルスチェック用プロトコル、アプリケーションサーバ関連などの情報が含まれる。アプリケーションサーバ関連の情報には、ＯＳ起動イメージ名や割当てリソース割合（ＡＰ１：８０％、ＡＰ２：２０％）などの情報が含まれる。

ユーザシステム配置先ＤＣ関連の管理情報には、プライマリデータセンターの管理情報と、バックアップデータセンターの管理情報が含まれる。プライマリデータセンターの管理情報には、プライマリとして配置先のデータセンター２の情報や、ＤＣ配置時のサービスフロント用ＩＰアドレスが含まれる。バックアップデータセンターの管理情報には、障害時の配置先のデータセンター２の情報や、ＤＣ配置時のサービスフロント用ＩＰアドレスの情報が含まれる。

なお、最小分割リソース量は、プライマリＤＣ配置用とバックアップＤＣ配置用で別々の値を設定できるようにしてもよい。例えば、緊急時用のバックアップＤＣ選定の条件を緩めるために、バックアップ配置用の値をプライマリ配置用の値よりも小さく設定してもよい。

最小分割リソース量を大きく設定すれば、ユーザシステム３の動作環境が良好になる（例えば動作が速くなる）。一方、最小分割リソース量を小さく設定すれば、リソース利用効率が向上する（ユーザシステム３の配置要求が受け入れられる可能性が高まる）。また、最小分割リソース量を決める際に、そのユーザシステム３におけるアプリケーションサーバ１４の割当てリソース割合を考慮してもよい。例えば、割合が小さい方に割り当てられるリソース量が過度に少なくならないようにしてもよい。

ユーザシステム構成関連の情報は、各ユーザシステム３を運営するユーザ（サービス提供者）の申告に基づいて登録される。また、ユーザシステム配置先ＤＣ関連の情報は、本システム１の管理装置４で決定された情報が登録される。

（本システムの処理フロー）
次に、本システム１の処理フローについて説明する。本システム１の処理フローは、各ＤＣのバックアップ容量の指定方式によって異なる。したがって、ここでは、まず、バックアップ容量の指定方式について説明する。バックアップ容量の指定方式は、各ＤＣのバックアップリソース容量を固定的に指定しない「非固定方式」と、各ＤＣのバックアップリソース容量を固定的に指定する「固定方式」に分けられる。

非固定方式は、各ＤＣのバックアップ容量が非固定（全ＤＣ間全体で一定の容量があればよい）のため、ユーザシステム３のプライマリ配置先のＤＣの選択の自由度が高い。ただし、非固定方式では、各ＤＣのバックアップ容量が、ユーザシステム３の追加とともに変更される。そのため、ユーザシステム３が追加されると、その都度、リソース使用状況の変化に応じて、他のユーザシステム３のバックアップＤＣの選定結果が変わる可能性がある。

一方、固定方式は、バックアップＤＣは、プライマリＤＣ選定時もしくは障害発生時等に一度選択するだけでよい。ただし、固定方式では、各ＤＣのバックアップ容量がユーザシステム３の運用開始前に固定的に指定され、各ＤＣは常のその分のリソースを空けておく必要がある。そのため、ユーザシステム３のプライマリ配置先のＤＣの選択の自由度は、非固定方式に比べて低い。

本システム１の処理フローは、最小分割リソース容量を担保するかどうかによっても異なる。具体的には、バックアップＤＣ選定のタイミングが、最小分割リソース容量を担保するかどうかによって異なる。したがって、ここで、バックアップＤＣ選定のタイミングについて説明しておく。

図８は、バックアップＤＣ選定のタイミングの説明図である。図８に示すように、最小分割リソース量を担保する場合は、バックアップＤＣの選定時にＮＧ判定（選択可能なＤＣがない）となる可能性があるため、プライマリＤＣの選択時に同時に選定を行うのが好ましい。最小分割リソース容量を担保しない場合には、非固定方式であるか固定方式であるかによって、バックアップＤＣ選定のタイミングが異なる。非固定方式の場合には、障害発生時に選定するのが好ましい。一方、固定方式の場合には、いずれのタイミングでも構わない。

次に、本システム１の処理フローについて説明する。ここでは、非固定方式と固定方式のどちらの方式か、最小分割リソース容量を担保するかどうか、によって、場合分けして説明する。

図９は、非固定方式で、最小分割リソース量の保証がない場合の処理フローの説明図である。図９に示すように、まず、本システム１の運用開始準備の段階では、各ＤＣの各種リソース容量を登録する処理を行う（Ｓ１）。具体的には、各ＤＣについて、個別ＤＣ関連の管理情報ＤＣ_nのうち、各種リソース容量Ｃ_nとユーザシステム用ＩＰアドレスの登録を行う。その後、全ＤＣのプライマリリソース容量（トータルプライマリリソース容量ＴＰ）を算出する（Ｓ２）。なお、トータルプライマリリソース容量ＴＰの算出方法については後で詳しく説明する。

本システム１が定常運用されている段階では、まず、ユーザシステム情報の登録が行われる（Ｓ３）。具体的には、ユーザシステム構成関連の情報Ｓ_mが登録される。つぎに、プライマリＤＣの選定が行われる（Ｓ４）。プライマリＤＣの選定方法については後で詳しく説明する。そして、プライマリＤＣの選定ができた場合には、ユーザシステム３のプライマリＤＣへの配置が行われる（Ｓ５）。ユーザシステム３のＤＣ配置方法についても後で詳しく説明する。一方、プライマリＤＣの選定ができなかった場合には、そこで処理が終了される（Ｓ６）。

ある地域で障害が発生した場合、まず、定常監視によって障害が検出される（Ｓ７）。具体的には、プライマリＤＣ上で稼働するユーザシステム３に対してヘルスチェックを行い、正常な応答が得られない場合に、障害発生とみなす。この場合、ヘルスチェックの対象ＩＰアドレスは、ユーザシステム配置先ＤＣ関連の情報（プライマリデータセンターのＤＣ配置時のサービスフロント用ＩＰアドレス）から取得できる。また、ヘルスチェックの方法は、ユーザシステム構成関連の情報Ｓ_m（サービスのヘルスチェック用プロトコル）から決定できる。

本システム１では、つぎに、バックアップＤＣの選定が行われる（Ｓ８）。バックアップＤＣの選定方法については後で詳しく説明する。そして、バックアップＤＣの選定が完了すると、ユーザシステム３のバックアップＤＣへの配置が行われる（Ｓ９）。配置先のＤＣは、ユーザシステム配置先ＤＣ関連の情報（障害時の配置先のデータセンター２）に基づいて決定される。

なお、図９の例では、バックアップＤＣの選定の処理を、障害検出時に実行しているが、各ＤＣのプライマリリソースの使用状況の変化に応じた選定が随時可能であれば、その他のタイミングで行ってもよい。例えば、毎日、ユーザシステム３の追加がない夜間に、バッチ処理によって全ユーザシステム３のバックアップＤＣ選定を行ってもよい。

図１０は、非固定方式で、最小分割リソース量の保証がある場合の処理フローの説明図である。図１０に示すように、まず、本システム１の運用開始準備の段階では、図９の場合と同様に、各ＤＣの各種リソース容量を登録する処理を行い（Ｓ１）、全ＤＣのプライマリリソース容量（トータルプライマリリソース容量ＴＰ）を算出する処理を行う（Ｓ２）。

つぎに、本システム１が定常運用されている段階では、ユーザシステム情報の登録が行われ（Ｓ３）、プライマリＤＣの選定が行われる（Ｓ４）。この場合、最小分割リソース量の保証があるため、ユーザシステム３の追加時にプライマリＤＣの選択とともにバックアップＤＣの選定をしておく必要がある。ただし、各ＤＣのバックアップリソース容量は非固定のため、ユーザシステム３の追加によるプライマリリソース使用量の増加が、その他のエリアのＤＣをプライマリとする他のユーザシステム３からのバックアップＤＣとしての利用に影響を与える可能性がある。（Ｂ_n＝Ｃ_n−Ｐ_nであるため、プライマリリソース使用量が増加すると、バックアップリソースとしての容量が減少する。）そのため、図１０のフローでは、プライマリＤＣ選定後に、そのＤＣをバックアップＤＣとして選定している他のすべてのユーザシステム３に関してバックアップＤＣの再選定を実行する（Ｓ１０）。このバックアップＤＣの再選定ができなかった場合には、そこで処理が終了される（Ｓ６）。

一方、他のすべてのユーザシステム３に関してバックアップＤＣの再選定ができた場合には、ステップＳ４でプライマリＤＣの選定を行ったユーザシステム３についてバックアップＤＣの選定が行われる（Ｓ８）。そして、バックアップＤＣの選定ができた場合には、ユーザシステム３のプライマリＤＣへの配置が行われる（Ｓ５）。そして、ある地域で障害が発生した場合には、定常監視によって障害が検出され（Ｓ７）、ユーザシステム３のバックアップＤＣへの配置が行われる（Ｓ９）。

図１１は、固定方式の場合の処理フローの説明図である。図１１に示すように、まず、本システム１の運用開始準備の段階では、各ＤＣの各種リソース容量を登録する処理を行った後（Ｓ１）、トータルバックアップリソース容量ＴＢに基づいて、各ＤＣのバックアップリソース容量を算出する処理を行う（Ｓ２）。なお、トータルバックアップリソース容量ＴＢの算出方法については後で詳しく説明する。

つぎに、本システム１が定常運用されている段階では、ユーザシステム情報の登録が行われ（Ｓ３）、プライマリＤＣの選定が行われる（Ｓ４）。プライマリＤＣの選定ができた場合には、バックアップＤＣの選定が行われ（Ｓ８）、ユーザシステム３のプライマリＤＣへの配置が行われる（Ｓ５）。最小分割リソース量の保証がある場合は、バックアップＤＣの選定ができずに処理終了となる場合がある。そして、ある地域で障害が発生した場合には、定常監視によって障害が検出され（Ｓ７）、ユーザシステム３のバックアップＤＣへの配置が行われる（Ｓ９）。なお、最小分割リソース量の保証がない場合には、バックアップＤＣの選定の処理を、障害発生時に行ってもよい。

（トータルプライマリ容量およびトータルバックアップ容量の算出）
ここで、トータルプライマリ容量ＴＰとトータルバックアップ容量ＴＢの算出方法について説明する。まず、前処理として、地域災害発生の各ＤＣへの影響という視点からエリアを定義する。より具体的には、ＤＣごとに地域災害発生時に影響を受ける可能性のある地理的範囲を「リージョン」と定め、そのリージョンの境界線で区切られる各区域を「エリア」と定める。

図１２は、エリアの定義の一例を示す図である。図１２の例で説明すると、ＤＣ−１については、地域災害発生時にＤＣ−１に影響を与える可能性のある範囲が「リージョン」と定められる。この場合、ＤＣ−１のリージョンは、他のリージョンと重複する部分がないので、ＤＣ−１のリージョンの境界線で区切られる区域が「エリアＡ₁」と定められる。

ＤＣ−２についても、地域災害発生時にＤＣ−２に影響を与える可能性のある範囲が「リージョン」と定められる。この場合、ＤＣ−２のリージョンは、ＤＣ−３のリージョンとも重複しているので、ＤＣ−２のリージョンのうちＤＣ−３のリージョンと重複しない区域が「エリアＡ₂」と定められ、ＤＣ−２のリージョンとＤＣ−３のリージョンが重複する区域が「エリアＡ_2-3」と定められる。すなわち、リージョンが重複する部分は、それぞれ個別のエリアとなる。

図１３は、災害が発生したエリアとその影響のあるＤＣの関係を示す図である。図１３では、エリアＡ₁で災害が発生したときには、ＤＣ−１に影響を与える可能性があることが示されている。また、エリアＡ_2-3で災害が発生したときには、ＤＣ−２とＤＣ−３に影響を与える可能性があること示されている。

なお、以上の説明では、1つの例として、各ＤＣの地理座標を中心として、災害発生時に影響を受ける可能性のある距離を半径とした円形のリージョンを重ねることによってエリアを定めたが、本発明の範囲はこれに限定されるものではない。すなわち、想定する災害や地理状況によっては、必ずしも各リージョンは円形であるとは限らない。また、以上の説明では、各リージョンの形状や面積が同じである場合を例示したが、本発明の範囲はこれに限定されるものではなく、各リージョンの形状や面積は異なってもよい。

上記のようにして前処理（各エリアの定義）が完了したら、全ＤＣ間でユーザシステム３のプライマリ稼働に使用可能なリソース量（トータルプライマリリソース容量ＴＰ）を算出する（ＴＰは、全ＤＣのプライマリリソースの合計とも表現できる。下記の式（２）参照）。トータルプライマリリソース容量ＴＰは、どのエリアで地域災害が発生してそのエリアのＤＣ全てに障害が発生しても、その他のエリアで復旧用のバックアップリソースが確保されるように算出する。また、トータルプライマリリソース容量ＴＰの残りを、全ＤＣ間のバックアップ用リソースとして確保するリソースの容量（トータルバックアップ容量ＴＢ）として算出する。

より具体的に説明すると、トータルプライマリリソース容量ＴＰの計算では、どの地域で障害が発生しても、障害の影響を受けないその他の地域でのバックアップリソースが確保されるために、前処理で定めた全エリアに対して、下記の式（３）の条件を満たす必要がある。

上記の式（３）は、下記の式（４）と等価である。

上記の式（４）において、左辺は式（２）の定義からＴＰと同意である。ここで、全エリアに関する上記式の右辺の計算結果のうち最も小さい値が、すべてのエリアの条件を満たし、かつ最大の値であり、ここで求めるＴＰの値となる。

トータルバックアップリソース容量ＴＢは、全ＤＣのキャパシティ合計からトータルプライマリリソース容量ＴＰを減算することにより算出される（下記の式（５）参照）。

トータルプライマリリソース容量ＴＰの計算を具体例を挙げて説明する。図１４は、各ＤＣのリソース量の一例（ＴＰの計算の具体例）を示す図であり、図１５は、この具体例におけるトータルプライマリリソース容量ＴＰの計算結果を示す図である。図１４と図１５の例では、トータルプライマリリソース容量ＴＰの計算結果として、６００ＲＵ（全エリアの最小値）が算出される。また、この場合、トータルバックアップリソース容量ＴＢは、４００ＲＵ（＝１０００ＲＵ−６００ＲＵ）として算出される。

なお、従来のバックアップリソース非共有の場合は、全体リソースに対して、プライマリリソースは半分までしか使用できないが、本システム１では、半分以上の使用が可能である。例えば、図１４と図１５の場合には、全体リソースに対して６割の使用が可能である。

また、図１２のように、ＤＣが密集していなければ、さらに高い割合でプライマリリソースを使用することが可能である。例えば、各ＤＣ間の距離が離れていて、複数のリージョンが重複するエリアが存在しないモデル（単純なモデル）であれば、図１５のＡ１〜Ａ５の中で最も値が小さい６５０ＲＵが、トータルプライマリリソース容量ＴＰとして算出される。

なお、そのような単純なモデルの場合には、以下のようにトータルプライマリリソース容量ＴＰを算出することも可能である。

まず、前処理として、全データセンター２を地域ごとにグループ分けする。そして、各地域グループのリソース量の合計を算出し、値の大きい地域から順番に並べる（図１６参照）。このときＮ番目の地域グループ（地域Ｎグループ）のリソース量の合計をＣ_Nとする。

この場合、トータルプライマリリソース容量ＴＰは、下記の式（６）を用いて算出することができる。また、トータルバックアップリソース容量ＴＢは、下記の式（７）を用いて算出することができる。

なお、トータルプライマリリソース容量ＴＰを可能な範囲の最大値とする場合（最も保守的な場合）には、ＴＢ＝Ｃ₁となる。図１５の例では、ＤＣ−１〜ＤＣ−５のうち、最大のリソース量を有するＤＣ−１のリソース量３５０ＲＵが、トータルバックアップリソース容量ＴＢとして求められる。これを、全ＤＣのリソース量の合計１０００ＲＵから減算すると、トータルプライマリリソース容量ＴＰが、６５０ＲＵ（＝１０００ＲＵ−３５０ＲＵ）として求められる。

（ユーザシステムの配置先ＤＣの選定方法）
つぎに、ユーザシステム３の配置先ＤＣの選定方法について説明する。図１７は、プライマリＤＣの選定条件の一例を示す図である。ユーザシステム３のプライマリＤＣ選定では、図１７の４つの条件（条件ア〜エ）をすべて満たさなければならない。プライマリＤＣの候補とするＤＣの中に条件を満たすものがない場合は、ユーザシステム３の追加はＮＧとなる。なお、条件アは、非固定方式の場合のみ判定が必要であり、条件エは、最小分割リソース容量を保証する場合のみ判定が必要である。

以下、これらの４つの条件（条件ア〜エ）について具体的に説明する。条件アは、全ＤＣのリソース使用量の合計が、トータルプライマリリソース容量を超えないことであり、下記の式（８）によって表すことができる。

条件イは、配置先ＤＣのリソース使用量がプライマリリソース容量を超えないことであり、下記の式（９）によって表すことができる。ここで、Ｒ_m（ＤＣ_n）は、Ｓ_mの必要リソース量のうち、ＤＣ_nから割り当てを受けるリソース量である。

なお、プライマリリソース容量は、非固定方式の場合には下記の式（１０）により求められ、固定方式の場合には下記の式（１１）により求められる。

条件ウは、ユーザシステム３の必要リソース量の条件を満たすことであり、具体的には、配置先ＤＣからの割り当てリソース量（分散配置の場合は各ＤＣからの合計）が、必要リソース量と同値であることである。例えば、配置先ＤＣが１つ（ＤＣ_n1）の場合には、下記の式（１２）より表され、配置先ＤＣが２つ（ＤＣ_n1、ＤＣ_n2）の場合には、下記の式（１３）により表される。

条件エは、ユーザシステム３の最小分割リソース量の条件を満たすことであり、例えば、配置先ＤＣが２つ（ＤＣ_n1、ＤＣ_n2）の場合には、下記の式（１４）および（１５）により表される。

図１８は、バックアップＤＣの満たすべき条件の一例を示す図である。ユーザシステム３のバックアップＤＣ選定では、図１８の４つの条件（条件オ〜ク）をすべて満たさなければならない。なお、条件クは、最小分割リソース容量を保証する場合のみ判定が必要である。また、前述のとおり、ユーザシステム３の最小分割リソース量を保証する場合は、条件を満たすＤＣがない可能性がある。そのため、バックアップＤＣの選定は、ユーザシステム３の追加時に行い、バックアップＤＣとしての条件を満たすものがない場合は、ユーザシステム３の追加はＮＧとなる。

以下、これらの４つの条件（条件オ〜ク）について具体的に説明する。条件オは、配置先ＤＣがプライマリＤＣ災害時にも影響がないことである。より具体的には、プライマリＤＣに災害発生の影響のあるエリアの集合（Ａ_p）とバックアップＤＣに災害発生の影響のあるエリアの集合（Ａ_b）の積集合が空集合となることであり、下記の式（１６）によって表すことができる。

図１９は、災害発生エリアと影響のあるＤＣの関係の一例を示す図である。図１９の例では、プライマリＤＣがＤＣ−５のとき、上記の条件オを満たすバックアップＤＣ候補は、ＤＣ−１とＤＣ−２である。

条件カは、配置先ＤＣのリソース予約量がバックアップリソース容量を超えないことである。具体的には、プライマリＤＣが災害発生の影響を受けるすべてのエリアに関して、追加ユーザシステム３を含めた災害発生の影響を受けるＤＣをプライマリＤＣとしている各ユーザシステム３の集合（Ｓ_p）と、追加ユーザシステム３を含め対象ＤＣをバックアップＤＣとしている各ユーザシステム３の集合（Ｓ_b）の積集合（Ｓ_p&b）の要素である各ユーザシステム３の必要リソース量の合計が、対象ＤＣのバックアップリソース容量（Ｂ_n）を超えないことであり、各エリアに関して満たすべき条件は、下記の式（１７）によって表すことができる。

なお、対象ＤＣのバックアップリソース容量（Ｂ_n）は、非固定方式の場合には下記の式（１８）で表され、固定方式の場合には下記の式（１９）で表される。

条件キは、ユーザシステム３の必要リソース量の条件を満たすことであり、条件ウと同じであるので、ここでは説明を省略する。また、条件クは、ユーザシステム３の最小分割リソース量の条件を満たすことであり、条件エと同じである。なお、最小分割リソース量として、プライマリＤＣ用とバックアップＤＣ用で別々の値を指定している場合は、バックアップＤＣ用の値を使用する。

（ユーザシステムのＤＣ配置方法）
まず、ユーザシステム３の構成について説明する。図２０は、ユーザシステム３の構成の説明図である。図２０に示すように、ユーザシステム３は、複数のアプリケーションサーバ１４によって構成され、各アプリケーションサーバ１４は、相互に通信可能な状態になっている（矢印（ｉ）参照）。ユーザシステム３は、ユーザシステム３ごとにデータアクセスゲートウェイ１５を備えており、データアクセスゲートウェイ１５は、各アプリケーションサーバ１４から共用のデータベースサーバ１２、ストレージサーバ１３内の所有データへのアクセスを転送する（矢印（ｉｉ）参照）。このユーザシステム３は、ユーザシステム３ごとにサービスゲートウェイ１６を備えており、サービスゲートウェイ１６は、提供サービスの利用者からのアクセスを、サービスフロントサーバとして指定されたアプリケーションサーバ１４へ転送する（矢印（ｉｉｉ）参照）。また、ユーザシステム３では、セキュリティ確保の観点から、各サービスゲートウェイ１６とデータアクセスゲートウェイ１５は、ユーザシステム３をまたがる通信を遮断する（矢印（ｉｖ）参照）。さらに、このユーザシステム３では、ＤＮＳサーバ１０にユーザシステム３のサービス公開用のホスト名とサービスゲートウェイ１６のＩＰアドレスのマッチング情報を登録する（矢印（ｖ）参照）。

サービスゲートウェイ１６は、ユーザシステム３の配置の際に動的に提供される必要があるため、実際には仮想的な機能として必要に応じて構成する方法が好ましい。サービスフロントサーバが、複数台で構成されるクラスタ構成をとる場合、サービスゲートウェイ１６は、サービスフロントサーバへの転送を負荷分散するロードバランサとして機能してもよい。

データアクセスゲートウェイ１５は、ユーザシステム３の配置の際に動的に提供される必要があるため、実際には仮想的な機能として必要に応じて構成する方法が望ましい。また、データアクセスゲートウェイ１５は、データセキュリティの観点から、あるユーザシステム３が他のユーザシステム３のデータにアクセス不可となるようにアクセス制限がかけられることが望ましい。なお、ユーザシステム３が用いるデータをアプリケーションサーバ１４内に格納するなどして、データアクセスゲートウェイ１５を有さない構成とすることも可能である。

フロントエンドＶＬＡＮは、各アプリケーションサーバ１４の相互通信（矢印（ｉ）参照）および利用者からのアクセスのアプリケーションサーバ１４への転送（矢印（ｉｉｉ）参照）のために使用される。このフロントエンドＶＬＡＮは、配置先ＤＣの対象ユーザシステム内のみで通信できるように構成されている。

バックエンドＶＬＡＮは、各アプリケーションサーバ１４からデータベースサーバ１２やストレージサーバ１３へのアクセス転送（矢印（ｉｉ）参照）のために使用される。このバックエンドＶＬＡＮは、配置先ＤＣの対象ユーザシステム内のみで通信できるように構成されている。

アプリケーションサーバ１４は、ユーザシステム３を構成するサーバである。このアプリケーションサーバ１４は、複数台のサーバで構成することが可能である。サービスフロントサーバは、ユーザシステム３が提供するサービスの利用者からのアクセスの窓口となるサーバである。サービスフロントサーバは、基本的には、各ユーザシステム３につき１台である。

つぎに、ユーザシステム３のＤＣ配置方法について説明する。以下、ユーザシステム３を配置先のＤＣ（１つのＤＣ）に配置する手順を例示して説明する。なお、ユーザシステム３を２つ以上のＤＣに配置する場合も、それぞれのＤＣについて同様の手順をとることでユーザシステム３を配置することができる。

まず「各ＶＬＡＮの設定」を行う。具体的には、フロントエンドＶＬＡＮとバックエンドＶＬＡＮを設定する。各ＶＬＡＮのＩＤは、各ＤＣのユーザシステム用ＶＬＡＮＩＤリストの中から非使用のものを選定する。

つぎに「サービスゲートウェイの構成」を行う。ここでは、ユーザシステム個別のサービスゲートウェイ１６を構成する。具体的には、サービスゲートウェイ１６を共用のインターネット接続ＬＡＮとフロントエンドＶＬＡＮに接続する。そして、サービスゲートウェイ１６のインターネット接続ＬＡＮに接続するＩＦにサービス公開用ＩＰアドレスを設定する。サービス公開用ＩＰアドレスは、各ＤＣのユーザシステム用ＩＰアドレスリストの中から非使用のものを選定する。

続いて「データアクセスゲートウェイの構成」を行う。この場合、ユーザシステム個別のデータアクセスゲートウェイ１５を構成する。そして、データアクセスゲートウェイ１５を、共用のバックエンドＶＬＡＮとデータ転送ＬＡＮに接続する。

つぎに「アプリケーションサーバの構成」を行う。具体的には、ユーザシステム３に割当てられたリソース内で各アプリケーションサーバ１４を、それぞれの割当リソース量を目安に起動イメージから仮想マシンとして起動する。ここで、各アプリケーションサーバ１４の割当リソース量は、以下の式で表すことができる。
各アプリケーションサーバの割当リソース量
＝ユーザシステムの割当リソース量×各アプリケーションサーバの割当リソース割合

その後、各アプリケーションサーバ１４を、フロントエンドＶＬＡＮとバックエンドＶＬＡＮに接続する。各アプリケーションサーバ１４のフロントエンドＶＬＡＮ側のＩＦには、各アプリケーションサーバ１４のＩＰアドレスを設定する。なお、仮想化サーバ技術においては、割当リソース量は目安であり、各アプリケーションサーバ１４が動作中に、アプリケーションサーバ間でリソースを融通し合うことが可能である。また、ユーザシステム間でもリソースを融通し合うようにしてもよい。

最後に「ＤＮＳの設定」を行う。具体的には、サービス公開用ホスト名とサービス公開用ＩＰアドレスのマッチング情報を、ＤＮＳに登録する。なお、２つのＤＣに配置する場合は、１つのサービス公開用ホスト名に２つのＩＰアドレスが登録され、ＤＮＳが利用者からのアクセスを負荷分散して誘導する。

このようにして、ユーザシステム３のＤＣ配置が行われる。図２１は、ＤＣ配置されたユーザシステム３の管理情報と値の一例を示す図であり、図２２は、配置先のＤＣに応じて決定する設定項目と値の一例を示す図である。

このような本システム１によれば、配置先ＤＣの選択の自由度が高いので、リソース利用効率が向上するように配置先ＤＣを選択することができる。図２３は、リソース利用効率が向上するような配置先ＤＣの選択の説明図である。図２３に示すように、本システム１では、例えば、時間帯によるリソース使用量のばらつきを抑えるように、配置先ＤＣを選択することができる。また、リソースごとの使用量のばらつきを抑えるように、配置先ＤＣを選択することができる。

また、本システム１によれば、バックアップリソースの共有が可能になる。従来、いつ発生するか分からない障害時に迅速にサービス復旧するためには、必要量のバックアップリソースが常時用意されている必要がある（障害発生後に準備開始では遅い）と考えられていた。したがって、２つの地域間での１対１のディザスタリカバリ対応を可能にするには、基本的に各ユーザシステム３に対してメインリソースと同量のバックアップリソースが必要であった。

それに対して、本システム１では、３つ以上の地域間で障害時のバックアップリソースを共有利用することができる。図２４は、バックアップリソース共有の効果の説明図である。図２４に示すように、３つ以上の地域間でのバックアップリソース共用によるディザスタリカバリでは、メインリソースに対するバックアップリソースの割合が減少し、設備コストを削減することができる。また、異なる地域で同時に障害が発生するケースへは非対応と仮定すると、同じメインリソース量でも、２地域構成よりも３地域構成のバックアップ共有利用の方がバックアップリソースを少なくすることができる。

さらに、本システム１によれば、ユーザシステム３をある程度自由な地域やデータセンター２に配置することができる。図２５は、各地域のリソースのメイン用途とバックアップ用途の割り当ての例を示す図である。図２５に示すように、仮に、ある地域をバックアップ用途限定してしまうと、利用者が何らかの理由（例えば、地理的に近い地域Ａの方がその他の地域に配置するよりも、システムの応答速度が速いことが期待されるため、地域Ａに配置したいなどの理由）で、その地域にシステムを配置したい場合に対応できない。本システム１では、そのようなユーザの要望にも柔軟に対応することができる。

以上、本発明の実施の形態を例示により説明したが、本発明の範囲はこれらに限定されるものではなく、請求項に記載された範囲内において目的に応じて変更・変形することが可能である。

以上のように、本発明にかかる管理装置は、地域に依存した災害等の障害発生時におけるユーザシステムに対するディザスタリカバリ機能を確実に提供できるという効果を有し、有用である。

１本システム
２データセンター
３ユーザシステム
４管理装置
５記憶部
６入力部
７処理部
８表示部
９ゲートウェイサーバ
１０ＤＮＳサーバ
１１仮想化サーバ
１２データベースサーバ
１３ストレージサーバ
１４アプリケーションサーバ
１５データアクセスゲートウェイ
１６サービスゲートウェイ

Claims

複数のデータセンターのうちの一つにユーザシステムを配置するための管理装置であって、
各データセンターは、少なくとも一つの仮想化サーバを含み、
前記仮想化サーバは、該仮想化サーバで動作する少なくとも一つの仮想マシンにより、配置されたユーザシステムを動作させることが可能なものであり、
各データセンターが有すリソースは、ユーザシステムが平常時に使用するプライマリリソースとして割り当てられるという用途と、障害時のためのバックアップリソースとして確保されるという用途の、いずれに供することも可能なものであり、
前記管理装置は、
前記複数のデータセンターの各々の現在のリソース量に関する第１の情報を記憶する記憶手段と、
ユーザシステムの配置要求として、該ユーザシステムが必要とするリソース量を示す第２の情報を入力する入力手段と、
前記ユーザシステムを配置した平常時のデータセンターが属する地域で障害が発生したと仮定して、該障害の影響が及ばない地域に属するデータセンターに前記ユーザシステムを配置できるだけのリソース量を、バックアップリソースとして確保しておけるか否かを、前記第１の情報及び前記第２の情報に基づいて、判断する判断手段と、
前記判断手段によるバックアップリソース確保可能の判断に応じて、前記ユーザシステムの平常時の配置先となるデータセンター及び該データセンターにおいて該ユーザシステムに割り当てられるべきプライマリリソース量を特定する情報を出力し、前記判断手段によるバックアップリソース確保不能の判断に応じて、前記ユーザシステムの配置要求を拒否する出力手段と
を備えることを特徴とする管理装置。
前記判断手段は、前記第１の情報に基づき、前記複数のデータセンター全体においてプライマリリソースとしての使用を許可するリソース量であるトータルプライマリリソース容量を定め、前記第２の情報が示す前記ユーザシステムが必要とするリソース量が、前記トータルプライマリリソース容量の範囲内で割り当て可能であるか否かを判断する手段を含むことを特徴とする請求項１記載の管理装置。
ある地域で障害が発生したと仮定して、該障害の影響が及ばない地域に属するデータセンターが有するリソースの容量を合計する処理を、複数の地域について行うことにより、複数の合計リソース容量を得、これら合計リソース容量のうち最も小さいものを、前記トータルプライマリリソース容量として定めることを特徴とする請求項２記載の管理装置。
前記判断手段は、前記第１の情報に基づき、前記ユーザシステムの平常時の配置先となるデータセンターにおいてプライマリリソースとしての使用を許可するリソース量である個別プライマリリソース容量を定め、前記第２の情報が示す前記ユーザシステムが必要とするリソース量が、前記個別プライマリリソース容量の範囲内で割り当て可能であるか否かを判断する手段を含むことを特徴とする請求項１〜３のいずれか１項記載の管理装置。
所定の基準により選択されたデータセンターを、前記ユーザシステムの平常時の配置先となるデータセンターの候補として、前記判断手段における判断を行うことを特徴とする請求項４記載の管理装置。
前記ユーザシステムを配置した平常時のデータセンターが属する地域で障害が発生した場合に前記ユーザシステムが配置される障害時のデータセンターを、前記障害の影響が及ばない地域に属するデータセンターの中から選定する選定手段をさらに備えることを特徴とする請求項１〜５のいずれか１項記載の管理装置。
所定の基準により選択されたデータセンターを、前記ユーザシステムの障害時の配置先となるデータセンターの候補として、前記選定手段における選定を行うことを特徴とする請求項６記載の管理装置。
前記選定手段は、前記第１の情報に基づき、前記ユーザシステムの障害時の配置先となるデータセンターにおいてバックアップリソースとして使用可能なリソース量である個別バックアップリソース容量を定め、前記第２の情報が示す前記ユーザシステムが必要とするリソース量が、前記個別バックアップリソース容量の範囲内で割り当て可能であるか否かを判断する手段を含むことを特徴とする請求項６又は７記載の管理装置。
前記判断手段による判断を行う際に、前記選定手段による選定を行い、
前記出力手段は、前記ユーザシステムの平常時の配置先となるデータセンターを特定する情報の出力に加えて、前記ユーザシステムの障害時の配置先となるデータセンターを特定する情報の出力を行うものであり、前記選定手段において前記ユーザシステムの障害時の配置先となるデータセンターが選定できなかった場合には、前記ユーザシステムの配置要求を拒否するものであることを特徴とする請求項６〜８のいずれか１項記載の管理装置。
前記障害が発生した際に、前記選定手段により選定を行い、
前記ユーザシステムの障害時の配置先となるデータセンター及び該データセンターにおいて該ユーザシステムに割り当てられるべきバックアップリソース量を特定する情報を出力する追加出力手段をさらに備えることを特徴とする請求項６〜８のいずれか１項記載の管理装置。
前記判断手段は、前記ユーザシステムの平常時の配置先となるデータセンターが有するリソースの容量までのリソース量が、プライマリリソースとしての使用が許可されているものとして、該データセンターにおいて前記ユーザシステムが必要とするリソース量が割り当て可能であるか否かを判断する手段を含み、
前記選定手段は、前記ユーザシステムの障害時の配置先となるデータセンターが有するリソースの容量から、現在使用されているリソース量を除いた容量の範囲内で、該データセンターにおいて前記ユーザシステムが必要とするリソース量が割り当て可能であるか否かを判断する手段を含むことを特徴とする請求項６〜１０のいずれか１項記載の管理装置。
前記ユーザシステムの平常時の配置先となるデータセンターを障害時の配置先とする他のユーザシステムが、該データセンターにおいて必要とするリソース量が、割り当て可能であるか否かを判断し、割り当て可能でない場合には、該他のユーザシステムの障害時の配置先となるデータセンターの選定をし直す再選定手段をさらに備えることを特徴とする請求項１１記載の管理装置。
前記判断手段は、前記ユーザシステムの平常時の配置先となるデータセンターが有するリソースの容量から、該データセンターにおいてバックアップリソースとして予め確保されているバックアップリソース容量を除いた容量までのリソース量が、プライマリリソースとしての使用が許可されているものとして、該データセンターにおいて前記ユーザシステムが必要とするリソース量が割り当て可能であるか否かを判断する手段を含み、
前記選定手段は、前記ユーザシステムの障害時の配置先となるデータセンターにおいてバックアップリソースとして予め確保されているバックアップリソース容量の範囲内で、該データセンターにおいて前記ユーザシステムが必要とするリソース量が割り当て可能であるか否かを判断する手段を含むことを特徴とする請求項６〜１０のいずれか１項記載の管理装置。
前記複数のデータセンター全体においてバックアップリソースとして確保されるリソース量であるトータルバックアップリソース容量を、複数のデータセンターに割り振ることにより、各データセンターにおいてバックアップリソースとして予め確保される前記バックアップリソース容量が定められていることを特徴とする請求項１３記載の管理装置。
前記ユーザシステムが平常時に配置されるデータセンターとして、二つ以上のデータセンターを選定し、前記ユーザシステムが必要とするリソース量を該二つ以上のデータセンターに割り振ることにより、プライマリリソース量の割り当てを可能とする分割手段をさらに備えることを特徴とする請求項１〜１４のいずれか１項記載の管理装置。
前記ユーザシステムが障害時に配置されるデータセンターとして、二つ以上のデータセンターを選定し、前記ユーザシステムが必要とするリソース量を該二つ以上のデータセンターに割り振ることにより、前記障害が発生した際のバックアップリソース量の割り当てを可能とする分割手段をさらに備えることを特徴とする請求項１〜１４のいずれか１項記載の管理装置。
前記第２の情報は、前記ユーザシステムが必要とするリソース量を二つ以上のデータセンターに割り振る場合に、各データセンターで最低限割り当てられるべき、最小分割リソース量を示す情報を含み、
前記分割手段は、前記第２の情報を参照してリソース量の割り振りを行う手段を含むことを特徴とする請求項１５又は１６記載の管理装置。
前記出力手段は、前記ユーザシステムの平常時の配置先となるデータセンターを特定する情報の出力に加えて、前記ユーザシステムの障害時の配置先となるデータセンターを特定する情報の出力を行うものであり、
前記分割手段において前記最小分割リソース量に従った割り振りができなかった場合には、他のユーザシステムの障害時の配置先となるデータセンターの選定をし直す再選定手段をさらに備えることを特徴とする請求項１７記載の管理装置。
前記ユーザシステムが必要とするリソース量を二つ以上の障害時の配置先となるデータセンターに割り振る場合の最小分割リソース量の条件が、平常時の配置先となるデータセンターに割り振る場合の条件よりも、緩和して設定されていることを特徴とする請求項１７記載の管理装置。
前記ユーザシステムは、少なくとも一つのアプリケーションサーバと、該アプリケーションサーバをネットワーク経由でクライアントからアクセス可能とするための手段とを含むものであり、
前記アプリケーションサーバは、前記仮想マシンにより実現されるものであることを特徴とする請求項１〜１９のいずれか１項記載の管理装置。
前記ネットワークにおける名前解決サーバに、前記ユーザシステムのサービス公開用の名前と、前記ユーザシステムが配置されたデータセンターを前記ネットワークにおいて特定可能なアドレスとの対応を、登録することにより、前記クライアントからのアクセスを可能とする手段をさらに備えることを特徴とする請求項２０記載の管理装置。
一つの地域で発生した障害が一つ以上の異なる地域に属するデータセンターに影響を与える可能性がある場合の、障害発生地域とその影響が及ぶデータセンターとの関係を示す第３の情報を記憶する記憶手段をさらに備え、
前記判断手段は、前記第３の情報を参照して判断を行う手段を含むことを特徴とする請求項１〜２１のいずれか１項記載の管理装置。
前記複数のデータセンターは、あるグループで発生した障害が他のグループのデータセンターには影響を与えないように、地域毎にグループ分けされており、
各グループ内のデータセンターが有するリソースの合計容量のうち最も大きいものを、前記複数のデータセンター全体が有するリソースの容量から減算した容量を、前記複数のデータセンター全体においてプライマリリソースとしての使用を許可するリソース量とすることを特徴とする請求項１〜２１のいずれか１項記載の管理装置。
複数のデータセンターのうちの一つにユーザシステムを配置するための管理方法であって、
各データセンターは、少なくとも一つの仮想化サーバを含み、
前記仮想化サーバは、該仮想化サーバで動作する少なくとも一つの仮想マシンにより、配置されたユーザシステムを動作させることが可能なものであり、
各データセンターが有すリソースは、ユーザシステムが平常時に使用するプライマリリソースとして割り当てられるという用途と、障害時のためのバックアップリソースとして確保されるという用途の、いずれに供することも可能なものであり、
前記管理方法は、
前記複数のデータセンターの各々の現在のリソース量に関する第１の情報を記憶し、
ユーザシステムの配置要求として、該ユーザシステムが必要とするリソース量を示す第２の情報を入力し、
前記ユーザシステムを配置した平常時のデータセンターが属する地域で障害が発生したと仮定して、該障害の影響が及ばない地域に属するデータセンターに前記ユーザシステムを配置できるだけのリソース量を、バックアップリソースとして確保しておけるか否かを、前記第１の情報及び前記第２の情報に基づいて、判断し、
バックアップリソース確保可能の判断に応じて、前記ユーザシステムの平常時の配置先となるデータセンター及び該データセンターにおいて該ユーザシステムに割り当てられるべきプライマリリソース量を特定する情報を出力し、バックアップリソース確保不能の判断に応じて、前記ユーザシステムの配置要求を拒否する
ことを特徴とする管理方法。
コンピュータを、複数のデータセンターのうちの一つにユーザシステムを配置するための管理装置として動作させるための、管理プログラムであって、
各データセンターは、少なくとも一つの仮想化サーバを含み、
前記仮想化サーバは、該仮想化サーバで動作する少なくとも一つの仮想マシンにより、配置されたユーザシステムを動作させることが可能なものであり、
各データセンターが有すリソースは、ユーザシステムが平常時に使用するプライマリリソースとして割り当てられるという用途と、障害時のためのバックアップリソースとして確保されるという用途の、いずれに供することも可能なものであり、
前記管理装置は、
前記複数のデータセンターの各々の現在のリソース量に関する第１の情報を記憶する記憶手段と、
ユーザシステムの配置要求として、該ユーザシステムが必要とするリソース量を示す第２の情報を入力する入力手段と、
前記ユーザシステムを配置した平常時のデータセンターが属する地域で障害が発生したと仮定して、該障害の影響が及ばない地域に属するデータセンターに前記ユーザシステムを配置できるだけのリソース量を、バックアップリソースとして確保しておけるか否かを、前記第１の情報及び前記第２の情報に基づいて、判断する判断手段と、
前記判断手段によるバックアップリソース確保可能の判断に応じて、前記ユーザシステムの平常時の配置先となるデータセンター及び該データセンターにおいて該ユーザシステムに割り当てられるべきプライマリリソース量を特定する情報を出力し、前記判断手段によるバックアップリソース確保不能の判断に応じて、前記ユーザシステムの配置要求を拒否する出力手段と
を備えるものであることを特徴とする管理プログラム。