(57)【要約】【課題】  小規模ユーザを対象にディザスタリカバリシステムを提供する。【解決手段】  クラウドサービス提供基盤とクラウド管理基盤とから構成されるクラウドサービスプロバイダを複数備えるディザスタリカバリシステムであって、  クラウド管理基盤は、サービスの稼働管理情報を監視する監視サーバと、サービスを実行する装置の機器管理情報と予め定めた複数のクラウドサービスプロバイダ間での移行条件情報を含む管理情報を管理する構成管理サーバとを含み、  第１のクラウドサービスプロバイダは、サービスに発生した障害情報と第１の稼働管理情報に基づき障害となる障害区画の情報を取得し、構成管理サーバにより障害情報および第１の管理情報に基づいて、第２のクラウドサービスプロバイダへ移行要求を送信する。【選択図】  図１
2018055518.tif 000002
【特許請求の範囲】
【請求項１】
クラウドサービスを提供するクラウドサービス提供基盤と前記クラウドサービスの実行に関する管理情報を管理するクラウド管理基盤と、から構成されるクラウドサービスプロバイダを複数備えるディザスタリカバリシステムであって、
前記クラウド管理基盤は、前記クラウドサービスの稼働管理情報を監視する監視サーバと、前記クラウドサービスを実行する装置の機器管理情報と予め定めた前記複数のクラウドサービスプロバイダ間での移行条件情報を含む前記管理情報を管理する構成管理サーバとを含み、
第１のクラウドサービスプロバイダは、
前記監視サーバにより前記クラウドサービスに発生した障害情報と第１の稼働管理情報に基づき前記障害となる障害区画の情報を取得し、
前記構成管理サーバにより前記障害情報および第１の管理情報に基づいて、前記第１のクラウドサービスプロバイダから第２のクラウドサービスプロバイダへ前記クラウドサービスの移行の要否を判断し、
前記第２のクラウドサービスプロバイダへ前記クラウドサービスを移行する場合、前記第１の管理情報に基づき、前記第２のクラウドサービスプロバイダへ移行要求を送信することを特徴とするディザスタリカバリシステム。
【請求項２】
請求項１に記載のディザスタリカバリシステムであって、
前記第２のクラウドサービスプロバイダは、
前記第１のクラウドサービスプロバイダから前記移行要求を受信すると、前記移行要求と前記第２のクラウドサービスプロバイダが管理する第２の管理情報に基づき、前記移行を受け入れるか否かを判断し、前記移行を受け入れる場合は、前記第２の管理情報の移行条件情報に基づき、前記移行に必要な情報を作成し、前記第１のクラウドサービスプロバイダへ送信し、
前記移行を受け入れない場合は、前記第１のクラウドサービスプロバイダへ移行不可を示す情報を送信することを特徴とするディザスタリカバリシステム。
【請求項３】
請求項２に記載のディザスタリカバリシステムであって、
前記第１のクラウドサービスプロバイダは、
前記移行不可を受信すると、前記移行条件情報を修正し、修正した移行要求を前記第２のクラウドサービスプロバイダへ送信することを特徴とするディザスタリカバリシステム。
【請求項４】
請求項２に記載のディザスタリカバリシステムであって、
前記第１のクラウドサービスプロバイダは、
前記移行不可を受信すると、前記移行要求を第３のクラウドサービスプロバイダへ送信することを特徴とするディザスタリカバリシステム。
【請求項５】
請求項２に記載のディザスタリカバリシステムであって、
前記移行に必要な情報は、前記クラウドサービスを実行するために前記第１のクラウドサービスプロバイダで利用する第１のリソース量と、前記第２のクラウドサービスプロバイダで移行する前記クラウドサービスを実行するために必要な第２のリソース量と、前記第２のリソース量を利用するための料金情報と、前記第１のクラウドサービスプロバイダと前記第２のクラウドサービスプロバイダとのサービス提供形態の差異を示す差異情報を少なくとも含み、
前記第２のクラウドサービスプロバイダは、前記移行に必要な情報を用いて、前記クラウドサービスの移行で発生する費用を算出することを特徴とするディザスタリカバリシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウドシステムにおける仮想サーバに関し、異なるクラウドサービスプロバイダ間におけるディザスタリカバリに関する。
【背景技術】
【０００２】
現在、顧客がコンピュータシステムを保有してアプリケーションを搭載し業務を行なうよりも、サーバ、ネットワーク装置、ストレージ等の計算資源を仮想的な資源としてデータセンタに配置しネットワークで接続されたコンピュータシステムを利用するケースが増えてきている。これを複数のユーザに提供するサービスをクラウドシステムと呼ぶ。クラウドシステムではユーザの契約している仮想計算資源毎に利用料を課金する。
【０００３】
事業継続性に関するユーザ意識が高まる中、クラウドサービスのニーズも増えてはいるが障害時の耐障害性を向上させたサービスの提供が必要であり、そのための技術としてディザスタリカバリシステムがある。ディザスタリカバリシステムでは、業務システムが稼働するサイトを２か所以上用意し、通常時に稼働させる第一のサイトをメインサイト、災害発生時にメインサイトが被災した場合に、メインサイトの代わりに処理を行わせる第２のサイトをリカバリサイトと呼ぶ。
【０００４】
オンプレミス環境（顧客が自らサーバ、ネットワーク機器、ストレージ機器を調達し運用する）ではディザスタリカバリシステムを自ら準備していた。メインサイトが被災した場合の業務復旧用にリカバリサイトを準備し、速やかに切替えを行い、業務継続を図る構成としている。メインサイトをクラウドシテムに移行しているケースでは、リカバリサイトもクラウドサービスでの提供を要望するケースが増えてきている。このケースではユーザでシステム機器を準備する必要がなくより短期間にシステムを構築することが可能になる。
【０００５】
なお、本発明の背景技術として、例えば、特開２０１２−２２１０４９号公報（特許文献１）がある。この特許文献１は「データセンタ間、アプリケーションシステムの構成要素間の通信状況等を考慮した構成要素の移動を可能とする。」データシステムが開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１２−２２１０４９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
一般的にはディザスタリカバリシステムを実現する為には、メインサイトと同等規模のリソースが必要であり、常に準備しておき被災時には速やかに稼働させることが必要になる。しかし、その準備の為のコストがサービス利用価格に転嫁されてしまうためサービス提供価格が高価となり、契約するのはある程度の規模のユーザに限られることになる。その為、小規模ユーザに対してはディザスタリカバリシステムを提供できないという問題があった。
【０００８】
従来は、単独のクラウドサービスプロバイダにおいて、当該ベンダの保有する複数のデータセンタによるサイトにより、メインサイトとリカバリサイトを構成してディザスタリカバリサービスを提供してきた。しかし、自前でメインサイトとリカバリサイトの全てのリソースを準備しておくことはクラウドサービスプロバイダの経済的負担を大きくしてきた。
【０００９】
そこで本発明は、小規模ユーザを対象にディザスタリカバリシステムを提供するシステムの提供を目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するために代表的な本発明のディザスタリカバリシステムの１つは、クラウドサービスを提供するクラウドサービス提供基盤とクラウドサービスを実行に関する管理情報を管理するクラウド管理基盤とから構成されるクラウドサービスプロバイダを複数備えるディザスタリカバリシステムであって、クラウド管理基盤は、クラウドサービスの稼働管理情報を監視する監視サーバと、クラウドサービスを実行する装置の機器管理情報と予め定めた複数のクラウドサービスプロバイダ間での移行条件情報を含む管理情報を管理する構成管理サーバとを含み、第１のクラウドサービスプロバイダは、監視サーバによりクラウドサービスに発生した障害情報と第１の稼働管理情報に基づき障害となる障害区画の情報を取得し、構成管理サーバにより障害情報および第１の管理情報に基づいて、第１のクラウドサービスプロバイダから第２のクラウドサービスプロバイダへクラウドサービスの移行の要否を判断し、第２のクラウドサービスプロバイダへクラウドサービスを移行する場合、第１の管理情報に基づき、第２のクラウドサービスプロバイダへ移行要求を送信するものである。
【発明の効果】
【００１１】
本発明によれば、高額となっていた小規模のディザスタリカバリサービスが安価に提供出来る。また、パートナークラウドとしての付加価値を上げる事が出来、ブランドイメージの向上が期待できる。ユーザにとってもパートナークラウドとしてのサービスを享受できることによってビジネスの継続性を確保できる。クラウドベンダーにとっても空きリソースの効率的な運用が行なえコスト低減が図れる。
【００１２】
上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施形態によるクラウドシステムのシステム構成を示す図である。
【図２】クラウドシステムの１要素であるクラウド提供基盤の構成概要図である。
【図３】本発明におけるクラウド管理基盤の構成概要図である。
【図４】クラウドシステムにおいてユーザが使用する仮想サーバの構成概念図である。
【図５】クラウドシステムにおいて、ユーザが使用する仮想サーバ及びクラウド監理基盤の仮想サーバが動作する物理サーバのハードウェア及びソフトウェア構成を示す図である。
【図６】構成管理サーバの仮想ハードウェア及びソフトウェアの構成を示す図である。
【図７】監視サーバの仮想ハードウェア及びソフトウェアの構成を示す図である。
【図８】稼働管理サーバの仮想ハードウェア及びソフトウェアの構成を示す図である。
【図９】コンバート用サーバの仮想ハードウェア及びソフトウェアの構成を示す図である。
【図１０】振替管理サーバの仮想ハードウェア及びソフトウェアの構成を示す図である。
【図１１】クラウド管理プログラムの一例を示す図である。
【図１２】リソース管理用テーブルの一例を示す図である。
【図１３】機器構成管理テーブルの一例を示す図である。
【図１４】契約管理テーブルの一例を示す図である。
【図１５】サービスカタログの一例を示す図である。
【図１６】移行性管理テーブルの一例を示す図である。
【図１７】パートナークラウド管理テーブルの一例を示す図である。
【図１８】移行先選定テーブルの一例を示す図である。
【図１９】障害管理テーブルの一例を示す図である。
【図２０】パートナークラウド価値判断テーブルの一例を示す図である。
【図２１】仮想サーバの振替実施の判断手順の一例を示す図である。
【図２２】仮想サーバの振替先を決定する手順の一例を示す図である。
【図２３】仮想サーバを振替た後にクラウドサービスプロバイダ間で振替える手順の一例を示す図である。
【図２４】振替ルールの合意決定に至る手順の一例を示す図である。
【図２５】精算テーブルの登録を行なう手順の一例を示す図である。
【図２６】仮想サーバの振替実施の判断から精算までの手順の一例を示す図である。
【図２７】被災時の障害範囲を特定する手順の一例を示す図である。
【図２８】他のクラウドサービスプロバイダへの振替実施判断を行なう手順の一例を示す図である。
【図２９】振替先を選択する手順の一例を示す図である。
【図３０】振替を依頼する手順の一例を示す図である。
【図３１】振替を実行する手順の一例を示す図である。
【図３２】精算を行なう為の手順の一例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための形態である実施例を図面に従い説明する。
【００１５】
以後の説明では「ＡＡＡテーブル」、「ＡＡＡリスト」、「ＡＡＡＤＢ」、「ＡＡＡキュー」等の表現にて本発明の情報を説明するが、これら情報はテーブル、リスト、ＤＢ又はキュー等のデータ構造以外で表現されていてもよい。
【００１６】
また各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」及び「番号」という表現を用いるが、これらの表現は装置や部品などの物理的な存在に限らず、論理的な存在についても区別をつけるために割り当てられているものであるため、お互いに置換が可能である。
【００１７】
以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることによって定められた処理をメモリ及びインタフェースを用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。
また、各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。
【００１８】
なお、以降で示す実施例ならびに図面は実施するための形態の一つであって、同様の処理が可能な他の構成・形態への適用を制限するものではない。
【実施例１】
【００１９】
本実施例は、クラウドサービスを提供する複数のクラウドサービスプロバイダにおける、災害復旧を支援するディザスタリカバリサービスを対象とし、第一のクラウドサービスプロバイダが被災した場合に、第二のクラウドサービスプロバイダに対して、ディザスタリカバリの振替先として受け入れを依頼する手順、方法について記載する。
【００２０】
図１は、本実施例を構成するシステム１００の全体構成を示している。第一のクラウドサービスプロバイダ１は、第二のクラウドサービスプロバイダ２と第三のクラウドサービスプロバイダ３と、通信ネットワークを介して接続されている。ネットワークは専用回線であっても、インターネットであってもよい。
【００２１】
クラウドサービスプロバイダ１は、ユーザにクラウドとして提供する計算機、ネットワーク、ストレージなどから構成されるクラウド提供基盤１０１と、クラウド提供基盤１０１を管理するクラウド管理基盤１０２と、他のクラウドサービスプロバイダのクラウドと接続されるネットワークから構成される。なお、クラウドサービスプロバイダ２、およびクラウドサービスプロバイダ３についてもクラウドサービスプロバイダ１と同様の構成を備えているものとする。
【００２２】
図２は、クラウドプロバイダ１が有するクラウド提供基板１０１の詳細について説明をする構成概要図である。
【００２３】
クラウド提供基盤１０１は、ユーザに対して情報処理システムを構成するための計算資源として、ファイアウォール装置２０１、負荷分散装置２０２、計算資源同士を通信するために接続するルータやスイッチなどのネットワーク機器２０３と、ユーザに計算処理の機能を提供する計算機である仮想サーバや物理サーバ、そして計算するために必要となるデータやプログラムを格納するための物理ストレージ２０７から構成される。
【００２４】
クラウドサービスプロバイダ１は、これらの計算資源をユーザに対して必要な時期、必要な量を提供することでクラウドサービスを実現している。各装置については、既に公知のものであるため、説明を省略する。
【００２５】
図３は、クラウドプロバイダ１が有するクラウド管理基板１０２の詳細について説明をする構成概要図である。
【００２６】
クラウド管理基盤１０２は、クラウド提供基盤１０１をユーザに提供するための管理基盤である。クラウド管理基板１０２は、物理サーバ３０６と物理ストレージ３０８を備え、物理サーバ上で複数の仮想サーバを実行している。
【００２７】
クラウド管理基板１０２は、仮想サーバとしてクラウド提供基盤１０１が保有するリソースとリソース間の構成を保持する構成管理サーバ３０１、クラウド提供基盤１０１の計算資源を性能や稼働状態を監視するための監視サーバ３０２、クラウド提供基盤１０１上で稼働する計算資源の稼働状態を保持する稼働管理サーバ３０３、あるクラウドサービスプロバイダから他のクラウドサービスプロバイダへ仮想サーバなどを移行するために必要となる変換処理を行うコンバート用サーバ３０４、本発明において、あるクラウドサービスプロバイダから他のクラウドサービスプロバイダへディザスタリカバリの振替の受け入れを依頼、交渉した上で振替先を決定し、振替にかかる費用を算出する振替管理サーバ３０５を備えている。
【００２８】
本実施例では、複数のクラウドサービスプロバイダのクラウド管理基盤が、被災時に互いにディザスタリカバリの振替処理の依頼メッセージのやりとりを行うことで、複数クラウドサービスプロバイダ間でのディザスタリカバリサービスを実現する。振替処理の詳細については図２１、２２、２３にて記載する。
【００２９】
図４は一般的な計算処理を提供する計算ノードである仮想サーバの構成を示したものである。仮想サーバは、アプリケーションプログラム４０１やデータなどを格納する記憶部、アプリケーションプログラムなどのプログラムを実行するためのＣＰＵなどのプロセッサを意味する制御部、計算結果などを表示する表示部、ユーザからの入力を受け付ける入力部、外部の計算資源と通信するためのネットワークインタフェース部、これらを接続するデータパスから構成される。
【００３０】
なお、図４にて説明した本構成は計算ノードとしての構成を限定するものではない。
【００３１】
図５は一般的な計算処理を提供する計算ノードである物理サーバ上で、仮想サーバを稼働させた場合の構成を示している。基本構成は図４の仮想サーバ２０４と同様であるが、内部で1台以上の仮想サーバを稼働させるため、記憶部において図４で示した仮想サーバ２０４の実行環境データ一式（実行イメージ）と保持するデータ一式を記憶部に持ち、仮想化プログラム５０１にてこれらを制御することで、仮想サーバとして独立した計算機環境を実現、提供している。
【００３２】
物理サーバを単体でユーザに提供する場合には、仮想化プログラム５０１や仮想サーバ２０４のための実行環境データ一式やデータ一式は構成として不要となる。なお、物理サーバ２０５の制御部、表示部、入力部、ネットワークインタフェース部、データパスの動作は、図４にて説明した構成と同様の処理をするものであるため説明を省略する。また図６以降についても制御部、表示部、入力部、ネットワークインタフェース部については説明を省略する。
【００３３】
図６はクラウド管理基盤１０２において、クラウド提供基盤１０１内の計算機資源の構成を管理する構成管理サーバ２０４を示したものである。
【００３４】
構成管理サーバ２０４は、記憶部に現在のクラウド提供基盤１０１上においてユーザに提供する計算機資源に関する情報を管理するリソース管理テーブル６０１、クラウド内の物理機器全般について管理する機器構成管理テーブル６０２、ユーザの契約情報を管理する契約管理テーブル６０３、クラウドサービスとして提供しているサービスメニューなどを示すサービスカタログ６０４、クラウドサービスプロバイダ間のサービス仕様や提供リソースの種別、仮想化基盤の種類、提供サイトの機能面、性能・可用性・信頼性などの非機能面の観点で評価する情報を格納する移行性管理テーブル６０５、各クラウドサービスプロバイダの提供しているサービスカタログにもとづく課金情報を保持するパートナークラウド管理テーブル６０６、これらの管理テーブルを元に、クラウド提供基盤１０１の管理、他クラウドサービスプロバイダへのディザスタリカバリ処理の振替処理を管理するクラウド管理プログラム６０７とを有している。各テーブルの詳細については後述する。
【００３５】
図７はクラウド管理基盤１０２において、クラウド提供基盤１０１およびクラウド管理基盤１０２自体の稼働状態などを監視する監視サーバ３０２の構成を示したものである。
【００３６】
監視サーバ３０２は、記憶部にクラウド提供基盤１０１の計算資源や、クラウド管理基盤１０２自体の稼働状態を監視するための監視プログラム７０１を有する。監視サーバ３０２は、監視プログラム７０１を制御部で実行し、ネットワークインタフェース部を介して、外部の監視対象装置の稼働状態の情報を取得し、あるいは、監視対象装置からの通信を受信することで、監視を実現する。その他の構成は仮想サーバ２０４あるいは物理サーバ２０５の構成と同じであるため説明を省略する。
【００３７】
図８は、クラウド管理基盤１０２において、クラウド提供基盤１０１上の計算資源の稼働状態を管理する稼働管理サーバ３０３の構成を示している。稼働管理サーバ３０３は、記憶部に稼働管理プログラム８０１を有する。稼働管理サーバ３０３は、制御部で稼働管理プログラム８０１を実行することで、クラウド提供基盤１０１上で稼働している仮想サーバ２０４および物理サーバ２０５の台数と動作状態、使用されているＣＰＵ、メモリ、ディスク容量などの利用情報、通信ネットワークの帯域利用状況、クラウド提供基盤で現在提供されているサービスの一覧などの情報を取得して保持する。その他の構成は仮想サーバ２０４あるいは物理サーバ２０５の構成と同じであるため説明を省略する。
【００３８】
図９は、クラウド管理基盤１０２において、自らのクラウド提供基盤１０１から別のクラウドサービスプロバイダのクラウド提供基盤１０１へとリソースを移行させるために必要となるコンバート用サーバ３０４を説明する図である。
【００３９】
コンバート用サーバ３０４は、実行環境のデータ一式の形式を移行先の実行環境のデータ一式の形式に変換するコンバータプログラム９０１を記憶部に有する。コンバート用サーバ３０４は、コンバータプログラムを制御部で実行することで、実行環境のデータ形式の相違を吸収し、ディザスタリカバリ時におけるリソースの移行を実現する。
【００４０】
なお、変換処理自体は公知の技術をであるため説明を省略する。また、その他の構成は仮想サーバ２０４あるいは物理サーバ２０５の構成と同じであるため説明を省略する。
【００４１】
図１０は、災害等により被害を受けたクラウド提供基板１０１を別のクラウド提供基板１０１へ処理を代替えさせるための管理を行う振替管理サーバ３０５の構成を説明する図である。
【００４２】
振替管理サーバ３０５は、クラウド管理基盤１０２において、災害発生により当該クラウドサービスプロバイダのクラウド提供基盤１０１のサイトが被災した場合に、処理を代替えするための復旧移行先であるリカバリサイトとして他のクラウドサービスプロバイダに、ディザスタリカバリのリカバリサイトの受け入れを依頼するための依頼メッセージを作成するためのパートナークラウド価値判断テーブル１００１と、パートナークラウド価値判断テーブル１００１にもとづいて依頼する場合に提示する振替の代金を計算するための振替料金精算プログラム１００２と、を記憶部に有する。
【００４３】
振替管理サーバ３０５は振替料金精算プログラム１００２を制御部にて実行することにより、他のクラウドサービスプロバイダに対して、被災したリソースの振替処理を受け入れてもらうための依頼通知と、依頼の応答に対して依頼内容を調整して再依頼する、または別のクラウドサービスプロバイダに依頼するなどの処理を行い、ディザスタリカバリの受け入れ先を決定する処理と、受け入れ先のクラウドサービスプロバイダへのリソースの移行処理を実現する。また、その他の構成は仮想サーバ２０４あるいは物理サーバ２０５の構成と同じであるため説明を省略する。
【００４４】
図１１は構成管理サーバ２０４に含まれるクラウド管理プログラム６０７を説明する図である。クラウド管理プログラム６０７では障害部位を特定するの障害部位特定機能１１０１を有し、当該機能を実行することで障害発生時にどこの部位で発生したかを検出する。また、さらに移行対象区画判定機能１１０２を実行することでどの部位の仮想サーバ２０４を移行対象とするかの特定をすることが出来る。また、移行先選定機能１１０３は、移行先選定テーブル６０８の情報を用いることで、どのパートナークラウドに移行するかの選定を提供することができる。
【００４５】
図１２は、リソース管理テーブル６０１の構成を説明する図である。リソース管理テーブル６０１は、提供している仮想サーバのリソース（ＶＭ名１２０１、ＣＰＵ１２０２、メモリ１２０３、ＤＩＳＫ１２０４、ＮＷ帯域１２０５、搭載物理サーバ名１２０６、搭載物理ストレージ名１２０７）の状態を管理している。リソース管理サーバ６０１は、各仮想サーバに対するＣＰＵやメモリなどのサーバ資源割当て情報を管理し、移行する際の必要リソースの計算に使用する。
【００４６】
図１３はクラウド提供基盤１０１の物理構成を管理し、障害が発生した時の部位の特定や影響範囲の特定などに活用する機器構成管理テーブル６０２を説明する図である。機器構成管理テーブル６０２は、また、パートナークラウドとのハード構成の比較をする際にも使用する。さらには、移行時の配置先選定にも活用する。そのため、サーバやストレージなどクラウドサービスを提供する為の全ての機器が網羅されている必要があり、クラウド環境を構成するものの全部又は一部の物理的な配置情報も含む。
【００４７】
図１３では、搭載物理サーバ名１３０１、ＣＰＵ種別１３０２、ＣＰＵ１３０３、メモリ１３０４、ラック番号１３０５をそれぞれ対応づけたエントリと、ストレージ名１３０６、ストレージ種別１３０７、キャッシュ容量１３０８、ＦＣ（Ｆｉｂｅｒ  Ｃｈａｎｎｅｌ）ポート数１３０９、ＩＯＰＳ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｐｅｒ  Ｓｅｃｏｎｄ）１３１０、ラック番号１３１１をそれぞれ対応付けたエントリを備えている。当然、上記する以外の情報を備えていてもよい。
【００４８】
図１４は、クラウドサービスを契約している仮想サーバ２０４の情報を管理している契約管理テーブル６０３である。契約管理テーブル６０３は、テナントＩＤ１４０１、ＶＭ名１４０２、オプションサービス１４０３、提供価格１４０４、値引き情報１４０５、契約期間１４０６がそれぞれ対応づけて記憶されている。契約管理テーブル６０３は、テナントＩＤ１４０１に含まれる契約ＶＭ数やオプションサービスの契約情報からその契約期間と課金情報としての値引率などの情報も管理するテーブルである。また、被災時の移行では精算ルールテーブル１００２と掛け合わせることで実際の振替金額を算出する際にも利用する。
【００４９】
図１５は、クラウドサービスのサービスカタログ６０４をテーブルとして管理する事を示す図である。サービスカタログ６０４は、サービス商品名１５０１、サービス商品１５０２、スペック１５０３、価格１５０４、課金方法１５０５、納期１５０６等がそれぞれ対応づけて記憶されている。サービスカタログ６０４は、商品名や商品内容スペックなどの情報を管理し、移行先に移行する際の課金情報に活用するテーブルである。
【００５０】
図１６は被災時の仮想サーバの移行容易性を管理する移行性管理テーブル６０５を示し図である。移行性管理テーブル６０５は、クラウドサービスプロバイダ１６０１毎の仮想化基盤１６０２やデータセンタ設置場所１６０４、また移行時間に関係するＮＷ帯域１６０３の情報、また実際にコンバートする方式１６０５を管理している。この情報から振替する際のクラウドサービスプロバイダの選定に利用する。
【００５１】
図１７は各パートナークラウドプロバイダーの提供するサービスの違いを管理するパートナークラウド管理テーブル６０６を説明する図である。例えば、パートナークラウド管理テーブル６０６は、サービス内容１７０１、ＣＰＵ、メモリ、ＤＩＳＫ容量などのリソース情報１７０２、リソースの空き状況１７０３、提供価格１７０４などが対応づけてい記憶されている。即ち、サービス内容にはサーバのスペックやリソースの空き情報が含まれ提供価格も本テーブルで纏められる。パートナークラウド管理テーブル６０６に記憶される情報は移行先として選定候補の対象となるパートナークラウドプロバイダー全ての情報が含まれる。
【００５２】
図１８は被災時の移行先を選定する際に利用される移行先選定テーブル６０８を説明する図である。移行先選定テーブル６０８は、移行対象ＶＭ数１８０１、テナントＩＤ１８０２、提供価格１８０３、移行対象ＣＰＵ数１８０４などを対応づけて記憶している。移行先選定テーブル６０８は、移行対象となるリソース量や契約金額を特定しており、これをベースとして担保するパートナークラウドベンダを振替先として選定する機能に利用される。
【００５３】
図１９はクラウドシステムでの障害が発生した際の復旧手順などを管理する障害管理テーブル６０９を示す図である。この障害管理テーブル６０８は、障害内容１９０１、発生した障害部位１９０２を管理し、復旧手順１９０３とその復旧時間１９０４などを対応づけて記憶している。障害発生時に障害管理テーブル６０９を参照することで、障害内容から復旧時間の推定が可能となる。
【００５４】
図２０は費用の精算に活用するパートナークラウドプロバイダーとの振替ルールテーブル１００１を説明する図である。振替ルールテーブル１００１に含まれる項目は、サーバ稼働率２００１、市場シェア２００２、ユーザ満足度２００３、第三者機関による評価２００４、サポート力２００５、等が対応づけられている、サーバ稼働率２００１などのサービス提供情報やユーザ満足度２００３などの客観的な情報だけではなく、顧客の主観による判断基準も含むとしてもよい。
【００５５】
図２１は振替ルールによってパートナークラウドプロバイダーとの精算レートを決定した情報を管理する精算ルールテーブル１００２を説明する図である。精算ルールテーブル１００２は、クラウドサービスプロバイダ３００１、サーバブレード変換レート３００２、ストレージ変換レート３００３などが対応づけられて記憶されている。本精算ルールテーブル１００２に従って、振替後の費用をプロバイダー間で精算することができる。
【００５６】
図２２では被災する前の平常時に行なう精算ルールテーブル１００２を作成する手順を説明するフローチャートである。災害時のディザスタリカバリを実行するためにはパートナークラウドプロバイダーとの間で振替に関するルールを事前に取り決めておく必要がある。精算ルールテーブル１００２を作成するフローはＳ１０1〜Ｓ１０３から構成されるが、各ステップについての詳細は図２３〜図２５を用いて説明をする。
【００５７】
図２３は精算テーブル作成フローＳ１００の中の振替ルール交渉フローＳ１０１説明をする図である。Ｓ１００では振替ルールテーブル１００１に登録する検討項目を交渉する。自社クラウドサービスとパートナークラウドプロバイダーとの比較検討項目を作成し、両者間にてこれを合意する。その上で、検討項目に登録される各社の値の決定方法を合意する。具体的には、図２０に示す振替ルールテーブル１００１から移行元（自社クラウド）と移行先（パートナークラウド）を比較するための項目を選び（サーバ稼働率、市場シェアなど）、その数値（例えば、サーバ稼働率９９・９％）の選び方を合意する。
【００５８】
図２４は精算テーブル作成フローＳ１００の中の振替ルール合意決定フローＳ１０２の詳細について説明をする図である。Ｓ１０２では、振替ルール交渉フローＳ１０１において決定した振替ルールの方法に従い、比較検討項目のそれぞれの値について合意する。両者間の決定した値を相対的に判断し決定する方法を合意する。具体的には、図２０示す振替ルールテーブル１００１のエントリ（例えば、＃１、＃２）のいずれかを選択することについて合意する。
【００５９】
図２５は精算テーブル作成フローＳ１００の中の精算ルールへの登録フローＳ１０３の詳細について説明をする図である。Ｓ１０３では、振替ルール合意決定フローＳ１０２において決定した両者間の決定した値を相対的に判断し決定する方法に従い、精算ルールテーブル１００２を作成する。作成した精算ルールをクラウド管理基盤１０２の振替管理サーバ３０５に登録する。例えば、振替ルールテーブル１００１のエントリ＃１とする場合に、自社クラウドサービスとパートナークラウドサービスを比較し、精算ルールテーブル１００２のエントリ（例えば＃１に対応する値であるサーバブレード変換レート「０．８」など）を登録する。
【００６０】
図２６は被災時の振替精算フローＳ２００を説明する図である。まず始めに、被災によって発せいする障害範囲の特定Ｓ２０１を行う。特定された障害の範囲から、次に振替実施の判断Ｓ２０２を実施し、振替が必要と判断した場合、振替先選択Ｓ２０３を行なう。次にＳ２０３にて選択された振替先に振替依頼処理Ｓ２０４を実施する。ここでパートナークラウドプロバイダーとの間で振替依頼が受け入れられない場合には、振替先選択Ｓ２０３に戻り再度振替先選択を実施する。パートナークラウドプロバイダーで受け入れられれば、振替実行Ｓ２０５を行なう。最後に費用について精算処理Ｓ２０６を行なう。
【００６１】
図２７は被災時の振替精算フローＳ２００の中の障害範囲特定フローＳ２０１を説明する図である。被災によりクラウド提供基盤１０１のある部分での障害が発生した場合、クラウド管理基盤１０２の監視サーバ３０２で障害が発生していることを検知する。クラウド管理基板１０２の構成管理サーバ３０１は機器構成管理テーブル３０２を参照することで、クラウド提供基盤１０１のどの部分で発生した障害かを特定する。
【００６２】
図２８は被災時の振替精算フローＳ２００の中の振替実施判断フローＳ２０２を説明スする図である。機器構成管理サーバ３０１は障害範囲特定フローＳ２０１から特定した障害発生部位とリソース管理テーブル６０１から障害による影響を受ける仮想サーバを特定する。次に機器構成管理サーバ３０１はクラウド管理プログラム６０７にて障害管理テーブル６０９から振替要否を判断する。具体的には、障害管理テーブル６０９の復旧時間から障害が復旧するまでユーザが待てるかどうかを判断し、耐えられる場合にはそのまま状態を維持し復旧を待つ。復旧まで待てない場合に構成管理サーバ３０１のクラウド管理プログラム６０７にて振替先選定の処理を行なう。
【００６３】
図２９は被災時の振替精算フローＳ２００の中の振替先選択フローＳ２０３を説明するする図である。機器構成管理サーバ３０１は、リソース管理テーブル６０１と契約管理テーブル６０３を参照し、振替を実行するために必要なクラウドサービスリソース量を含む情報を確認する。次に、機器構成管理サーバ３０１は、移行性管理テーブル６０５を参照し、振替先のパートナークラウドプロバイダーの候補を洗い出し、パートナークラウド管理テーブル６０６を参照し、クラウドサービスを実行するための具体的な振替先を決定する。
【００６４】
図３０は被災時の振替精算フローＳ２００の中の振替依頼フローＳ２０４を説明する図である。機器構成管理サーバ３０１は、振替先選択フローＳ２０３で決定した振替依頼先パートナークラウドプロバイダーに振替を依頼する。振替先パートナークラウドで受入れ可否を検討し、検討結果を受領する。
【００６５】
図３１は被災時の振替精算フローＳ２００の中の振替実行フローＳ２０５を説明する図である。振替依頼フローＳ２０４で決定したパートナークラウドプロバイダーの保有する振替先コンバート用サーバ３０４に対して、振替対象データを転送する。転送が完了すると、パートナークラウドプロバイダーの振替先コンバート用サーバ３０４にあるコンバータプログラム９０１で対象仮想サーバの振替を実行する。
【００６６】
図３２は被災時の振替精算フローＳ２００の中の精算処理フローＳ２０６を説明する図である。精算テーブルへの登録フローＳ１０３で登録した精算テーブルに従い精算依頼をパートナークラウドに依頼する。それを受けて、振替先パートナークラウドプロバイダーで精算可否を判断するが、この検討結果が否である場合には、再度精算ルールテーブル作成フローＳ１００に戻る。振替先パートナークラウドプロバイダーで精算依頼を受けるまで繰り返し、精算処理実行を行なう。
【００６７】
以上により、本実施例の構成を備えることで、従来まで高額となっていた小規模のディザスタリカバリサービスが安価に提供することができる。また、パートナークラウドとしての付加価値を上げる事ができ、ブランドイメージの向上が期待できる。さらに、ユーザにとってもパートナークラウドとしてのサービスを享受できることによって、ビジネスの継続性を確保できる。また、クラウドベンダーにとっても空きリソースの効率的な運用が行なえコスト低減を図ることができる。
【符号の説明】
【００６８】
１，２，３・・・クラウドプロバイダ、１０１・・・クラウド提供基盤、１０２・・・クラウド管理基盤、２０１・・・ファイアウォール装置、２０２・・・負荷分散装置、２０３・・・ネットワーク機器、２０４・・・仮想サーバ、２０５、２０６・・・物理サーバ、２０７・・・物理ストレージ、３０１・・・構成機器管理サーバ、３０２・・・監視サーバ、３０３・・・稼働管理サーバ、３０４・・・コンバート用サーバ、３０５・・・振替管理サーバ、３０６・・・物理サーバ、３０８・・・物理ストレージ、４０１・・・アプリケーションプログラム、５０１・・・仮想化プログラム、６０１・・・リソース管理テーブル、６０２・・・機器構成管理テーブル、６０３・・・契約管理テーブル、６０４・・サービスカタログ、６０５・・・移行性管理テーブル、６０６・・・パートナークラウド管理テーブル、６０７・・・クラウド管理プログラム、６０８・・・移行先選定テーブル、６０９・・・障害管理テーブル、７０１・・・監視プログラム、８０１・・・稼働管理プログラム、９０１・・・コンバータプログラム、１００１・・・振替ルールテーブル、１００２・・・振替精算プログラム、１００３・・・精算ルールテーブル、１１０１・・・障害部位特定機能、１１０２・・・移行対象区画判定機能、１１０３・・・移行先選定機能
【図１】
2018055518.tif 000003
【図２】
2018055518.tif 000004
【図３】
2018055518.tif 000005
【図４】
2018055518.tif 000006
【図５】
2018055518.tif 000007
【図６】
2018055518.tif 000008
【図７】
2018055518.tif 000009
【図８】
2018055518.tif 000010
【図９】
2018055518.tif 000011
【図１０】
2018055518.tif 000012
【図１１】
2018055518.tif 000013
【図１２】
2018055518.tif 000014
【図１３】
2018055518.tif 000015
【図１４】
2018055518.tif 000016
【図１５】
2018055518.tif 000017
【図１６】
2018055518.tif 000018
【図１７】
2018055518.tif 000019
【図１８】
2018055518.tif 000020
【図１９】
2018055518.tif 000021
【図２０】
2018055518.tif 000022
【図２１】
2018055518.tif 000023
【図２２】
2018055518.tif 000024
【図２３】
2018055518.tif 000025
【図２４】
2018055518.tif 000026
【図２５】
2018055518.tif 000027
【図２６】
2018055518.tif 000028
【図２７】
2018055518.tif 000029
【図２８】
2018055518.tif 000030
【図２９】
2018055518.tif 000031
【図３０】
2018055518.tif 000032
【図３１】
2018055518.tif 000033
【図３２】
2018055518.tif 000034