以下に、開示するリソース管理サーバ、リソース管理システム、リソース管理方法及びリソース管理プログラムの実施例について、図面に基づいて詳細に説明する。なお、本実施例により開示する発明が限定されるものではない。各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
図1は、実施例1に係るインタークラウドサーバの構成の一例を示す図である。インタークラウドサーバ100は、リソース管理サーバとも称する。図1に示す例では、インタークラウドサーバ100に加えて、管理装置200とユーザ端末300とリソース400とを併せて示した。なお、以下では、管理装置200により管理されるリソース400が、ユーザ端末300に割り当てられる場合を用いて説明する。
リソース400は、管理装置200及びユーザ端末300と接続される。リソース400は、管理装置200によりユーザに割り当てられる。リソース400は、例えば、サーバのリソースや、ネットワークのリソースなどが該当する。
管理装置200は、インタークラウドサーバ100及びリソース400と接続される。管理装置200は、リソース400を管理する。図1に示す例では、管理装置200は、割当部201を有する。割当部201は、リソース400をユーザ端末300に割り当てたり、ユーザ端末300に割り当てられたリソース400を回収したりする。複数ある管理装置200各々は、それぞれ独自のリソース400を管理し、独自に管理するリソース400をユーザに割り当てる。
なお、以下では、異なる種類のリソースを提供する各々のクラウドシステムが、それぞれ異なる管理装置200を用いてリソース400を管理する場合を用いて説明する。すなわち、管理装置200各々が、それぞれ異なるクラウドシステムについてのリソース400を管理する場合を用いて説明する。ただし、これに限定されるものではなく、管理装置200は、異なるクラウドシステムにより提供されるリソース400各々が、1つの管理装置200により管理されても良い。例えば、管理装置「A」が、クラウドシステム「A」により提供されるリソース及びクラウドシステム「B」により提供されるリソースを管理しても良い。
なお、ここで、管理装置200は、複数のサーバのリソース400が集合したデータセンタ単位でリソース400を管理しても良い。また、同様に、あるクラウドシステムが複数のネットワークのリソース400を提供する場合に、ネットワークのリソース400毎に管理装置200を用いても良く、クラウドシステム毎に管理装置200を設けても良い。
また、管理装置200は、リソース400の空き状況を示す空きリソース情報をインタークラウドサーバ100に送信したり、リソース400の利用状況を示す利用状況情報をインタークラウドサーバ100に送信したりする。
ユーザ端末300は、インタークラウドサーバ100及びリソース400と接続される。ユーザ端末300は、管理装置200により管理されるリソース400を利用するユーザにより用いられる。ユーザ端末300は、リソースの新規割当を要求する新規割当要求をインタークラウドサーバ100に送信する。また、ユーザ端末300は、リソースの割当の解消を要求する割当廃止要求をインタークラウドサーバ100に送信する。また、ユーザ端末300は、リソース割当に関する制約条件を割り当てられたリソース400が満たしているかを判定する旨の判定指示をインタークラウドサーバ100に送信する。
図2は、実施例1における管理装置とリソースとユーザ端末との関係の一例を示す図である。図2に示す例では、サーバのリソース400となるサーバ401−1〜サーバ401−9と、ネットワークのリソース400となるネットワーク402−1〜ネットワーク402−3とがある場合を示した。なお、図2に示す例では、記載の便宜上、ユーザ端末300とインタークラウドサーバ100とが接続してない場合を示したが、これに限定されるものではない。例えば、ユーザ端末300とインタークラウドサーバ100とが接続されても良い。
また、図2に示す例では、管理装置200−1〜管理装置200−3が、それぞれ、サーバのリソース400として、サーバ401−1〜サーバ401−3、サーバ401−4〜サーバ401−6、サーバ401−7〜サーバ401−9を管理する場合を示した。また、図2に示す例では、管理装置200−4〜管理装置200−6が、それぞれ、ネットワークのリソース400として、ネットワーク402−1、ネットワーク402−2、ネットワーク402−3を管理する場合を示した。
また、図2に示す例では、ユーザ端末300−1が、ネットワーク402−1とサーバ401−7とを利用している場合を示した。また、図2に示す例では、ユーザ端末300−2が、ネットワーク402−2とサーバ401−5及びサーバ401−9とを利用している場合を示した。また、図2に示す例では、ユーザ端末300−3が、ネットワーク402−3とサーバ401−1及びサーバ401−6とを利用している場合を示した。
ここで、インタークラウドサーバ100は、以下に詳細に説明するように、異なるクラウドシステムにより割り当てられるリソース400各々について、リソースの空き状況を示す空きリソース情報とリソース400の利用状況を示す利用状況情報とを収集する。そして、インタークラウドサーバ100は、異なる種類のリソース各々について収集した利用状況情報をくくりつけて解析することで、既に割り当てられているリソースの過不足を判定し、過不足を解消する割り当てを決定する。そして、インタークラウドサーバ100は、決定したリソースの割当を管理装置200に出力する。
すなわち、以下に詳細に説明するように、インタークラウドサーバ100が、提供元が異なるリソース400各々について、クラウドシステムをまたがってリソース400の状況を収集し、収集した情報に基づいてリソースの割当を決定する。この結果、提供元が異なるリソース400を簡単に組み合わせて利用することが可能となる。
なお、図2に示した構成は一例であり、これに限定されるものではない。例えば、図2に示す例では、管理装置200が6つあり、サーバのリソース400が9つあり、ネットワークのリソース400が3つある場合を示したが、これに限定されるものではなく、任意の数であって良い。
図1の説明に戻り、インタークラウドサーバ100の構成について説明する。図1に示す例では、インタークラウドサーバ100は、通信部101と、記憶部110と、制御部120とを有する。通信部101は、管理装置200やユーザ端末300からの情報を受信し、受信した情報を制御部120に送信する。また、通信部101は、制御部120から受信した情報を管理装置200やユーザ端末300に送信する。なお、通信部101により送受信される情報の詳細については、後述するため、ここでは説明を省略する。
記憶部110は、制御部120と接続される。記憶部110は、制御部120による各種処理に用いるデータを記憶する。記憶部110は、例えば、RAM(Random Access Memory)やフラッシュメモリ(Flash Memory)などの半導体メモリ素子、又は、ハードディスクや光ディスクなどが該当する。図1に示す例では、記憶部110は、制約条件テーブル111を有する。
制約条件テーブル111は、ユーザを識別するユーザID(Identifier)と、リソースの割当に関する制約条件とを対応付けて記憶する。図3は、実施例1における制約条件テーブルに記憶された情報の一例を示す図である。図3に示すように、制約条件テーブル111は、ユーザIDと対応付けて制約条件を記憶する。例えば、図3に示す例では、制約条件テーブル111は、ユーザID「USER0001」やユーザID「USER0002」などについて制約条件を記憶する。
また、図3に示す例では、制約条件テーブル111は、制約条件の一例として、「料金の上限値」と「リソースの属性」と「リソースの上限値」と「リソースの下限値」とを記憶する場合を示した。「料金の上限値」は、ユーザが許容する料金の上限値を示す。「リソースの属性」は、ユーザが割当可能とするリソース400の属性を示す。リソース400の属性とは、例えば、リソースの所在地が該当する。「リソースの上限値」と「リソースの下限値」とは、それぞれ、ユーザが割当可能とするリソース400のリソース量の範囲を示す。
図3に示す例では、制約条件テーブル111は、ユーザID「USER0001」に対応付けて、料金の上限値「100万円/月」と、リソース400の属性「サーバの所在地:東京」と、リソース400の上限値「100Mbps」と、リソース400の下限値「10Mbps」とを記憶する。すなわち、制約条件テーブル111は、ユーザID「USER0001」により識別されるユーザが許容する料金の上限値が「100万円/月」であり、東京にあるサーバのリソース400を割当可能とすることを記憶する。また、制約条件テーブル111は、ユーザID「USER0001」により識別されるユーザに対して、「100Mbps」から「10Mbps」の範囲に収まるリソース400を割当可能とすることを記憶する。
なお、制約条件テーブル111に記憶される情報は、ユーザ端末300により送信された新規割当要求に含まれる。すなわち、ユーザ端末300が、ユーザIDと制約条件とを含む新規割当要求をインタークラウドサーバ100に送信すると、インタークラウドサーバ100は、受信した新規割当要求に含まれるユーザIDと制約条件とを対応付けて制約条件テーブル111に格納する。
制御部120は、通信部101及び記憶部110と接続される。制御部120は、各種の処理手順などを規定したプログラムを記憶する内部メモリを有し、種々の処理を制御する。制御部120は、例えば、ASIC(Application Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)、CPU(Central Processing Unit)、MPU(Micro Processing Unit)などが該当する。図1に示す例では、制御部120は、受信部121と、収集部122と、過不足判定部123と、決定部124と、割当出力部125と、制約条件判定部126と、判定結果出力部127とを有する。
受信部121は、新規割当要求や割当廃止要求、判定指示を受信する。ここで、受信部121は、新規割当要求を受信すると、受信した新規割当要求に含まれる制約条件を制約条件テーブル111に格納する。例えば、受信部121は、ユーザID「USER0001」により送信された新規割当要求を受信した場合には、ユーザID「USER0001」と制約条件との対応付けを制約条件テーブル111に格納する。
また、受信部121は、割当廃止要求を受信すると、割当廃止要求の送信元となるユーザについての制約条件を制約条件テーブル111から削除する。例えば、受信部121は、ユーザID「USER0003」から新規割当要求を受信すると、ユーザID「USER0003」に対応付けられた制約条件を制約条件テーブル111から削除する。
収集部122は、異なる種類のリソースを提供する各々の管理装置200について、リソース400の状況を示す情報を収集する。例えば、収集部122は、管理装置200各々から、空きリソース情報とユーザごとの利用状況情報を収集する。つまり、異なる種類のリソースを提供する各々のクラウドシステムについて、リソース400の状況を示す情報を収集する。
例えば、収集部122は、異なる事業者により割り当てられるリソース400各々について、リソース400の状況を示す情報を収集する。また、例えば、収集部122は、異なる種類のリソース400各々について、リソース400の状況を示す情報を収集する。
図2に示す例では、収集部122は、管理装置200−1〜管理装置200−6各々にアクセスし、管理装置200−1〜管理装置200−6各々により管理されるリソース400各々についての空きリソース情報や利用状況情報を収集する。
例えば、収集部122は、空きリソース情報として、リソース400の総量と、割り当てられていないリソース400についての情報とを収集する。また、例えば、収集部122は、リソース400についての情報として、リソース400の利用料金の値や、リソース400の属性などを収集する。また、例えば、収集部122は、利用状況情報として、割り当てられたリソース400のうち、実際に利用されているリソース400についての情報と、利用されていないリソース400についての情報とを収集する。
ネットワークのリソース400について収集する場合を用いて、更に詳細な一例をあげて説明する。収集部122は、空きリソース情報として、ネットワークの確保済帯域と未確保帯域と総帯域とを収集したり、ネットワークの遅延値を収集したりする。また、収集部122は、利用状況情報として、ネットワークの利用帯域と未利用帯域と総帯域とを収集したり、ネットワークの遅延値を収集したりする。
サーバのリソース400について収集する場合を用いて、更に詳細な一例をあげて説明する。収集部122は、空きリソース情報として、サーバのCPU、メモリ並びにディスクの割当状況と未割当状況と総量とを収集する。また、収集部122は、利用状況情報として、サーバのCPU、メモリ並びにディスクの利用状況と未利用状況と総量とを収集する。
なお、収集部122は、任意のタイミングにて、空きリソース情報や利用状況情報を収集する。例えば、利用者によって予め設定されたタイミングにて、空きリソース情報や利用状況情報を収集する。また、収集部122は、受信部121によって新規割当要求が受信されると、空きリソース情報を収集する。また、収集部122は、受信部121によって割当廃止要求が受信されると、利用状況情報を収集する。また、収集部122は、受信部121によって判定指示が受信されると、利用状況情報を収集する。
過不足判定部123は、収集部122により異なる種類のリソース各々について収集された利用状況情報をくくりつけて解析することで、既に割り当てられているリソース400の過不足を判定する。例えば、過不足判定部123は、ネットワークのリソース400についての利用状況情報と、サーバのリソース400についての利用状況情報とをくくりつけた上で解析することで、異なるリソース400各々についてのユーザ毎の過不足を判定する。また、過不足判定部123は、利用状況情報に加えて、制約条件テーブル111に格納された制約条件を用いて過不足を判定する。
例えば、過不足判定部123は、利用状況情報を解析することで、割り当てられたリソース400において利用されていないリソース400が占める割合を識別し、識別した割合が所定の割合以下になった場合に、不足していると判定する。また、同様に、過不足判定部123は、利用状況情報を解析することで、割り当てられたリソース400において利用されていないリソース400が占める割合を識別し、識別した割合が所定の割合以上になった場合に、余っていると判定する。
また、ネットワークのリソース400を例に、制約条件を併せて用いて過不足を判定する場合について説明する。例えば、過不足判定部123は、制約条件テーブル111から、リソース400の上限値「100Mbps」と、リソース400の下限値「10Mbps」とを制約条件として読み出した場合を用いて更に説明する。また、「50Mbps」のネットワークのリソース400が割り当てられており、「50Mbps」のネットワークのリソース400すべてが利用されている場合を用いて説明する。この場合、過不足判定部123は、割り当てられたすべてのリソース400が利用されており、割り当てられているリソース量がリソース400の上限値「100Mbps」に達していないので、不足していると判定する。
なお、上述した過不足判定部123による判定処理は一例であり、任意の手法を用いて判定して良い。例えば、上述した説明では、利用されていないリソース400が占める割合に基づいて過不足を判定する場合について説明したが、これに限定されるものではなく、任意の手法を用いて判定して良い。
決定部124は、リソース400の割当を決定する。具体的には、以下に説明するように、受信部121により新規割当要求又は割当廃止要求が受信された場合や、過不足判定部123により不足していると判定されたり余っていると判定されたりした場合に、リソース400の割当を決定する。
例えば、決定部124は、受信部121により新規割当要求が受信された場合には、新規割当要求により示されるリソース400を割り当てるリソースの割当を決定する。また、例えば、決定部124は、受信部121により割当廃止要求が受信された場合には、割当廃止要求により示されるリソース割当を解消するリソースの割当を決定する。
受信部121により新規割当要求が受信された場合について、より詳細な一例をあげて説明する。上述したように、受信部121は、新規割当要求を受信すると、受信した新規割当要求に含まれる制約条件を制約条件テーブル111に格納する。この場合、決定部124は、受信部121によって新たな制約条件が制約条件テーブル111に格納されると、新たに格納された制約条件を満たすリソース400を割り当てるリソース割当を決定する。
受信部121により割当廃止当要求が受信された場合について、より詳細な一例をあげて説明する。上述したように、受信部121は、割当廃止要求を受信すると、受信した割当廃止要求に含まれる制約条件を制約条件テーブル111から削除する。この場合、決定部124は、受信部121によって制約条件が制約条件テーブル111から削除されると、削除された制約条件についての割り当てを開放するリソース割当を決定する。
また、決定部124は、過不足判定部123によりリソース400が不足していると判定された場合には、空きリソース情報により示される空きリソース400を追加するリソースの割当を決定する。具体的には、決定部124は、空き状況情報により示される異なる種類の空きリソース400をくくりつけ、くくりつけた中からリソース割当を決定する。また、決定部124は、過不足判定部123によりリソース400が余っていると判定された場合には、利用状況情報により示される利用中のリソース400を開放するリソース割当を決定する。
ここで、決定部124により割り当てられるリソース400について更に説明する。決定部124は、制約条件を満たすリソースの割当を決定する。言い換えると、決定部124は、空きリソース情報により示される空きリソース400のうち、制約条件を満たす任意の空きリソースを割り当てる割り当てを決定する。
また、決定部124は、ユーザ毎のリソース割当を決定する。言い換えると、例えば、決定部124は、割り当てを決定する対象となるユーザについての制約条件を制約条件テーブル111から取得し、空きリソース情報により示される空きリソース400のうち、制約条件を満たす任意のリソース400を割り当てるリソース割当を決定する。
また、決定部124により開放されるリソース400について更に説明する。決定部124は、例えば、制約条件を満たすリソースの割当を決定する。言い換えると、決定部124は、利用状況情報により示される利用中のリソース400のうち、任意のリソース400を開放する。
割当出力部125は、決定部124により決定されたリソース割当を出力する。具体的には、割当出力部125は、ユーザ毎のリソース割当を出力する。また、割当出力部125は、リソース400を管理する管理装置200にリソース割当を通知することで、決定部124により決定されたリソースの割当を管理装置200に実行させる。
制約条件判定部126は、収集部122により収集された利用状況情報を解析することで、既に割り当てられているリソース400が制約条件を満たしているか否かを判定する。具体的には、制約条件判定部126は、利用状況情報に含まれる情報各々について、制約条件を満たしているか否かを判定する。
例えば、収集部122により収集されたユーザ「USER0001」についての利用状況情報に、ネットワーク帯域「30Mbps」が含まれている場合を用いて説明する。この場合、制約条件判定部126は、制約条件テーブル111からユーザID「USER0001」に対応付けられた制約条件として、リソースの上限値「100Nbps」とリソースの下限値「10Mbps」とを取得する。そして、制約条件判定部126は、利用状況情報を解析することでリソース量を識別し、識別したリソース量が「100Nbps」から「10Mbps」との間にあるか否かを判定する。ここで、制約条件判定部126は、例えば、識別したリソース量が「30Mbps」であり、制約条件を満たしていると判定する。
なお、制約条件判定部126は、任意のタイミングにて判定処理を実行する。例えば、受信部121によって判定指示が受信され、収集部122によって利用状況情報が収集されると、制約条件判定部126は、判定処理を実行する。また、例えば、制約条件判定部126は、判定処理を受信部121が受信したか否かに関係なく、任意のタイミングにて判定処理を実行する。
判定結果出力部127は、制約条件判定部126による判定結果を出力する。具体的には、判定結果出力部127は、リソースの過不足を判定するための情報として判定結果を過不足判定部123に出力する。その後、過不足判定部123は、判定結果出力部127により出力された判定結果を用いて、過不足を判定することになる。
また、例えば、判定結果出力部127は、判定結果をユーザ端末300に出力する。より詳細な一例をあげて説明すると、判定結果出力部127は、制約条件判定部126により満たしていると判定されると、満たしている旨の判定結果をユーザ端末300に出力し、制約条件判定部126により満たしていないと判定されると、満たしていない旨の判定結果をユーザ端末300に出力する。ここで、判定結果出力部127は、例えば、判定結果を、判定の対象となったリソース400の割当先となるユーザにより用いられるユーザ端末300に出力する。
なお、上述したインタークラウドサーバ100や管理装置200は、例えば、任意のサーバが該当する。また、ユーザ端末300は、例えば、パーソナルコンピュータやPDA(Personal Data Assistance)、あるいは携帯電話やPHSの如き移動体通信端末などが該当する。例えば、インタークラウドサーバ100は、任意のサーバに対して、図1に示した記憶部110や制御部120などの各機能を搭載することによって実現される。
[インタークラウドサーバによる割当処理]
図4は、実施例1に係るインタークラウドサーバによる割当処理の流れの一例を示すフローチャートである。以下では、収集部122が、任意のタイミングにて、空きリソース情報と利用状況情報とを収集した場合における処理の流れの一例について説明する。
図4に示すように、収集部122は、任意のタイミングとなると(ステップS101肯定)、収集部122は、異なる事業者により割り当てられるリソース400各々について、リソース400の状況を示す情報を収集する(ステップS102)。例えば、収集部122は、リソース400を管理する管理装置200各々から、それぞれ、空きリソース情報や利用状況情報を収集する。
そして、過不足判定部123は、収集部122により収集された利用状況情報を解析することで、既に割り当てられているリソース400の過不足を判定する(ステップS103)。例えば、過不足判定部123は、利用状況情報を解析することで、割り当てられたリソース400において利用されていないリソース400が占める割合を識別し、識別した割合が所定の割合以下になった場合に不足していると判定する。
そして、決定部124は、リソース400の割当を決定する(ステップS104)。例えば、決定部124は、割り当てを決定する対象となるユーザについての制約条件を制約条件テーブル111から取得し、空きリソース情報により示される空きリソース400のうち、制約条件を満たす任意のリソース400を割り当てるリソース割当を決定する。
そして、割当出力部125は、決定部124により決定されたリソース割当を出力する(ステップS105)。つまり、割当出力部125は、リソース400を管理する管理装置200にリソース割当を通知することで、決定部124により決定されたリソースの割当を管理装置200に実行させる。
なお、新規割当要求を受信した場合や、割当廃止要求を受信した場合には、インタークラウドサーバ100では、上述したステップS103を実行することなく、収集部122がリソース400の状況を示す情報を収集し、決定部124がリソース400の割当を決定し、割当出力部125がリソース割当を出力する。
[インタークラウドサーバによる判定処理]
図5は、実施例1に係るインタークラウドサーバによる判定処理の流れの一例を示すフローチャートである。以下では、制約条件判定部126が、受信部121によって判定指示が受信されると判定処理を実行する場合を用いて説明する。
図5に示すように、受信部121が判定指示を受信すると(ステップS201肯定)、収集部122は、利用状況情報を収集する(ステップS202)。そして、制約条件判定部126は、収集部122により収集された利用状況情報を解析することで、既に割り当てられているリソース400が制約条件を満たしているか否かを判定する(ステップS203)。例えば、制約条件として、リソースの上限値「100Nbps」とリソースの下限値「10Mbps」とがある場合を用いて説明する。この場合、制約条件判定部126は、利用状況情報を解析することでリソース400のリソース量を識別し、識別したリソース400のリソース量が「100Nbps」から「10Mbps」との間にあるか否かを判定する。
そして、判定結果出力部127は、制約条件判定部126による判定結果を出力する(ステップS204)。例えば、判定結果出力部127は、制約条件判定部126により満たしていると判定されると、満たしている旨の判定結果をユーザ端末300に出力し、制約条件判定部126により満たしていないと判定されると、満たしていない旨の判定結果をユーザ端末300に出力する。
[実施例1の効果]
上述したように、実施例1によれば、インタークラウドサーバ100は、リソース400を提供する異なる管理装置各々について、空き状況情報と利用状況情報とを収集し、異なる種類のリソース各々について収集された利用状況情報をくくりつけて解析することで、既に割り当てられているリソース400の過不足を判定する。そして、インタークラウドサーバ100は、リソース400が不足していると判定された場合には、空きリソース情報により示される異なる種類の空きリソース400をくくりつけて、その中からリソースを追加するリソース割当を決定し、リソース400が余っていると判定された場合には、利用状況情報により示される利用中のリソース400を開放するリソースの割当を決定する。そして、インタークラウドサーバ100は、決定したリソース割当を管理装置200各々に出力する。この結果、異なる事業者により提供されるリソースを簡単に組み合わせて利用可能となる。また、この結果、異なる種類のリソースを提供するクラウド全体の品質を効率よく維持することが可能である。
また、実施例1によれば、インタークラウドサーバ100は、新規割当要求及び割当廃止要求を受信する。また、インタークラウドサーバ100は、新規割当要求が受信された場合には、新規割当要求により示されるリソース400を割り当てるリソース割当を決定する。また、インタークラウドサーバ100は、割当廃止要求が受信された場合には、割当廃止要求により示されるリソース割当を解消するリソース割当を決定する。この結果、ユーザは、異なる事業者により提供されるリソース400の割当を簡単に新設したり廃止したりすることが可能となる。
また、実施例1によれば、インタークラウドサーバ100は、制約条件を含む新規割当要求を受信し、制約条件を満たすリソース割当を決定する。この結果、ユーザは、制約条件をインタークラウドサーバ100に入力することで、異なる事業者により提供されるリソース400各々から、それぞれ制約条件を満たすリソース400を簡単に利用することが可能である。
また、実施例1によれば、インタークラウドサーバ100は、収集された利用状況情報を解析することで、既に割り当てられているリソース400が制約条件を満たしているか否かを判定し、リソースの過不足を判定するための情報として判定結果を過不足判定部123に出力する。この結果、ユーザに割り当てられているリソースが制約条件を満たさなくなった場合に、適宜過不足が判定され、リソース割当が決定されることになり、ユーザに制約条件を満たすリソースを適切に割り当てることが可能である。また、判定結果をユーザに出力することで、異なる事業者により提供されたリソース400各々について、制約条件をみたしているかをユーザが簡単に確認可能である。
また、実施例1によれば、インタークラウドサーバ100は、ユーザ毎の利用状況情報を収集し、ユーザ毎のリソース400の過不足を判定し、ユーザ毎のリソース割当を決定し、ユーザ毎のリソース割当を出力する。この結果、複数いるユーザ毎に、異なる事業者により提供されるリソース400各々を簡単に割当可能である。
実施例2では、インタークラウドサーバの詳細について更に説明する。実施例2では、インタークラウドサーバ500にインストールされたプログラムが一連の処理を実行することで、異なるクラウドシステムにより提供されるリソースを割り当てる場合を用いて説明する。より詳細には、インタークラウドサーバ500が、ネットワークのリソースと、データセンタのリソースとを割り当てる場合を用いて説明する。
なお、以下では、クラウドシステムにより提供されるリソースが、ASP(Application Service Provider)運用者に割り当てられ、ASP運用者により提供されるサービスをユーザが利用する場合を用いて説明する。
図6は、実施例2に係るインタークラウドサーバの全体像について示す図である。実施例2に係るインタークラウドサーバ500は、データセンタのリソースやネットワークのリソースを提供するクラウドシステム各々について、リソースの状況を示す情報を収集し、異なるクラウドシステムに属するリソース各々をASP運用者に割り当てる。例えば、実施例2に係るインタークラウドサーバ500は、異なるクラウドシステムにより提供されるリソースを組み合わせて提供することで、スケールアウト等のマイグレーションを支援する。
図6に示す例では、インタークラウドサーバ500に加えて、オペレータ端末601と、ASP端末602と、DC−OPS(Data Center−Operation System)603と、NW−OPS(Network−Operation System)604と、DC(Data Center、データセンタ)605と、R(Router、ルータ)606と、ユーザ端末607とを併せて示した。
オペレータ端末601は、インタークラウドサーバ500と接続される。オペレータ端末601は、インタークラウドサーバ500を管理するオペレータにより用いられる。オペレータ端末601は、Webブラウザを有する。例えば、オペレータ端末601は、インタークラウドサーバ500の設定や運用、管理等を行うためのインタフェースをWebブラウザ上に表示する。
ASP端末602は、インタークラウドサーバ500と接続される。ASP端末602は、クラウドシステムにより提供されるリソースを用いてサービスを提供するASP運用者により用いられる。ASP端末602は、Webブラウザを有する。例えば、ASP端末602は、インタークラウドサーバ500の設定や運用、管理等を行うためのインタフェースをWebブラウザ上に表示する。
R606は、NW−OPS604及びDC605、ユーザ端末607と接続される。R606は、ネットワーク装置であり、例えば、ルータである。R606は、ネットワークを形成する。なお、R606により形成されるネットワーク608により、DC605とユーザ端末607とが接続され、複数あるDC605各々が接続される。R606は、NW−OPS604により管理される。
DC605は、DC−OPS603及びR606と接続される。DC605は、仮想マシンサービスを提供する。DC605は、DC−OPS603により管理される。なお、仮想マシン(VM、Virtual Machine))とは、ソフトウェアによって提供される仮想的なPCを示す。
DC−OPS603は、インタークラウドサーバ500及びDC605と接続される。DC−OPS603は、DC605のリソースを管理する管理装置である。具体的には、DC−OPS603は、DC605の利用状況情報をASP運用者毎に把握し、DC605各々の空きリソース情報を把握する。例えば、DC−OPS603は、1つ又は複数のDC605を管理する。
NW−OPS604は、インタークラウドサーバ500及びR606と接続される。NW−OPS604は、R606を管理する管理装置である。具体的には、NW−OPS604は、R606により形成されるネットワーク608各々について、ネットワーク608の利用状況情報をASP運用者毎に把握し、R606により形成されるネットワーク608各々について空きリソース情報を把握する。例えば、NW−OPS604は、1つ又は複数のR606を管理する。
なお、図6に示す例では、説明の便宜上、オペレータ端末601が1つあり、ASP端末602が1つあり、DC−OPS603が4つあり、NW−OPS604が4つあり、DC605が4つあり、R606が4つあり、ユーザ端末607が3つある場合を示した。ただし、これに限定されるものではなく、各装置の数は任意であって良い。例えば、ASP端末602が2つ以上あっても良く、DC−OPS603やNW−OPS604、DC605、R606などが3つ以下でも良く、5つ以上でも良い。
また、図6に示す例では、オペレータ端末601と、ASP端末602と、ユーザ端末607とが別装置である場合を例に示したが、これに限定されるものではない。例えば、オペレータ端末601と、ASP端末602と、ユーザ端末607とのうち、任意の装置を組み合わせて1つの装置としても良い。
インタークラウドサーバ500は、各種のハードウェアを有し、OSやミドルウェアなどの各種プログラムが予めインストールされる。具体的には、インタークラウドサーバ500は、詳細については後述するように、インタークラウドサーバ500が有する各種のハードウェアにより実行されるプログラムとして、ICSソフトウェア501と、RAF(リソース要件推定アルゴリズム)502とを実行する。
なお、ICSソフトウェア501は、実施例1における制御部120の各部により実行される処理を実行する。また、RAF502は、ASP運用者に割り当てられているリソースについての利用状況情報と制約条件とに基づいて、ASP運用者に割り当てることが推奨されるリソースのリソース要件を推定する。例えば、RAF502は、利用状況情報を解析することで、ASP運用者が必要とするリソース量を推定し、制約条件に合致して推定したリソース量を満たすリソース要件を推定する。なお、RAF502による推定処理は、任意の手法を用いて良い。
また、実施例2におけるICSソフトウェア501は、後述するように、過不足しているリソースの要件を判定する場合に、RAF502により推定されたリソース要件と、利用状況情報により示される利用中のリソースとを比較する。そして、実施例2におけるICSソフトウェア501は、後述するように、RAF502により推定されたリソース要件と、利用状況情報により示される利用中のリソースとの差分について、空きリソースのうち制約条件を満たす任意のリソースを新たに追加するリソース割当を決定したり、利用状況情報により示される利用中のリソースのうち任意のリソースを開放するリソース割当を決定したりする。
なお、以下では、RAF502が、ICSソフトウェア501と同一のコンピュータにインストールされたプログラムである場合を用いて説明する。ただし、RAF502は、これに限定されるものではなく、ICSソフトウェア501とは別のコンピュータにインストールされても良く、インタークラウドサーバ500とは別の装置としても良い。
[実施例2に係るインタークラウドサーバによるリソース割当処理の動作概要]
実施例2に係るインタークラウドサーバ500によるリソース割当処理の動作概要について説明する。具体的には、リソース割当処理の動作概要として、ASP運用者に新規にリソースを割り当てられる新設時における動作概要と、ASP運用者に割り当てられたリソースのリソース量を増減する増設・減設時における動作概要と、ASP運用者に割り当てられたリソースを開放する廃止時における動作概要とを順に説明する。
[新設時における動作概要]
図7は、実施例2におけるASP運用者に新規にリソースを割り当てられる新設時における動作概要を示す図である。図7に示すように、インタークラウドサーバ500は、制約条件DB511と、管理情報DB512とを有する。なお、図7のNW608−1は、NW−OPS604−1により管理されるR606により形成されるネットワーク608である。
制約条件DB511は、クラウドシステムにより提供されるリソースが割り当てられるASP運用者を識別するユーザ識別情報と制約条件とを対応付けて記憶する。言い換えると、制約条件DB511は、ASP運用者毎の制約条件を記憶する。制約条件とは、例えば、ASP運用者に割り当てるリソースの上限値や下限値、ASP運用者に割り当てるリソースの属性などが該当する。
なお、制約条件DB511に記憶された情報は、例えば、ASP運用者によって入力され、リソースを割り当てる際に用いられる。実施例2における制約条件DB511に記憶される情報の詳細な一例については、後述する。
管理情報DB512は、リソースを管理する管理装置についての管理情報を記憶する。具体的には、DC−OPS603についての管理情報を記憶し、NW−OPS604についての管理情報を記憶する。管理情報とは、例えば、管理装置の識別名や管理装置にアクセスする際に用いられるURL、管理装置にアクセスする際に用いられるパスワードなどが該当する。
なお、管理情報DB512に記憶された情報は、例えば、オペレータによってインタークラウドサーバ500に入力され、インタークラウドサーバ500が管理装置にアクセスする際に用いられる。実施例2における管理情報DB512に記憶される管理情報の詳細な一例については、後述する。
リソースの新設時には、ASP端末602は、ASP運用者から制約条件を受け付け、新規割当要求をインタークラウドサーバ500に送信する。ここで、ASP端末602により送信される新規割当要求には、ASP運用者から受け付けた制約条件が含まれる。
すると、図7の(1)に示すように、インタークラウドサーバ500では、制約条件を含む新規割当要求をASP端末602から受信する。そして、ICSソフトウェア501は、受信した制約条件を制約条件DB511に格納する。また、図7の(2)に示すように、ICSソフトウェア501は、リソースの空き状況を示す空きリソース情報を管理装置に要求する。図7に示す例では、ICSソフトウェア501は、管理情報DB512からDC−OPS603やNW−OPS604の管理情報を読み出し、読み出した管理情報を用いて空きリソース情報をDC−OPS603−1に要求する。また、同様に、ICSソフトウェア501は、空きリソース情報をDC−OPS603−2に要求し、空きリソース情報をNW−OPS604−1に要求する。すなわち、ICSソフトウェア501は、異なるクラウドシステムにより割り当てられるリソース各々について、空きリソース情報を収集する。なお、実施例2における空きリソース情報の詳細な一例については、後述する。
そして、図7(3)に示すように、ICSソフトウェア501は、所定のアルゴリズムに基づいて、リソース配分計算を実行する。すなわち、ICSソフトウェア501は、空きリソース情報により示される空きリソースから、新規割当要求に含まれる制約条件を満たす任意のリソースを選択し、選択した任意のリソースを割り当てるリソース割当を決定する。
そして、図7の(4)に示すように、ICSソフトウェア501は、決定したリソース割当を管理装置に出力する。図7の(4)に示す例では、ICSソフトウェア501は、管理情報DB512からDC−OPS603−1についての管理情報を読み出す。そして、ICSソフトウェア501は、読み出した管理情報を用いて、DC605−1のリソースを割り当てるリソース割当をDC−OPS603−1に出力する。つまり、ICSソフトウェア501は、リソース配分計算により決定されたリソースの配分を出力する。また、同様にICSソフトウェア501は、DC−OPS603−2にリソース割当を出力し、NW−OPS604−1にリソース割当を出力する。
その後、各管理装置は、受信したリソース割当に従ってリソースを割り当てる。例えば、DC605−2のリソースとNW(ネットワーク)608−1のリソースがASP運用者「A」に割り当てられた場合を用いて説明する。この結果、例えば、ユーザAは、ASP運用者「A」により提供されるサービスを、ネットワーク608−1を介してDC605−2から提供される。
[増設・減設時における動作概要]
図8は、実施例2におけるASP運用者に割り当てられたリソースのリソース量を増減する増設・減設時における動作概要を示す図である。以下に説明するように、ICSソフトウェア501は、既にリソースを利用しているASP運用者のリソースの利用状況を収集する。そして、ICSソフトウェア501は、RAF502による推測により、リソースの既存の割り当てが妥当ではなくなったASP運用者について、リソースを追加したり削減したりする。なお、ICSソフトウェア501は、以下に説明する一連の処理を任意のタイミングにて実行する。例えば、ICSソフトウェア501は、利用者によって予め設定された時間間隔毎に実行する。
図8の(1)に示すように、ICSソフトウェア501は、ASP運用者毎の利用状況情報を管理装置に要求する。図8に示す例では、ICSソフトウェア501は、DC−OPS603やNW−OPS604の管理情報を管理情報DB512から読み出し、読み出した管理情報を用いてDC−OPS603やNW−OPS604に利用状況情報を要求する。すなわち、ICSソフトウェア501は、異なるクラウドシステム各々について、ASP運用者毎の利用状況情報を収集する。
そして、図8の(2)に示すように、ICSソフトウェア501は、制約条件DB511から制約条件を読み出し、収集した利用状況情報と読み出した制約条件とをRAF502に出力する。すなわち、ICSソフトウェア501は、RAF502に、ASP運用者に割り当てられているリソースの過不足の判定を依頼する。
ここで、RAF502は、ICSソフトウェア501により収集された利用状況情報と制約条件とを解析することで、ASP運用者に既に割り当てられているリソースの過不足をASP運用者毎に判定する。言い換えると、RAF502は、割り当てられているリソースにユーザが満足しているかを利用状況情報と制約条件とに基づいて判定し、ユーザが満足するリソースの要件を利用状況情報と制約条件とに基づいて推定する。
RAF502は、過不足していると判定したASP運用者については、過不足しているリソースのリソース要件を判定する。例えば、RAF502は、不足しているリソースのリソース量を判定したり、余っているリソースのリソース量を判定したりする。そして、図8の(3)に示すように、RAF502は、判定結果となるリソース要件をICSソフトウェア501に出力する。なお、RAF502による判定処理は、任意の手法を用いて良い。
そして、図8の(4)に示すように、ICSソフトウェア501は、図7の(2)と同様に、空きリソース情報を管理装置に要求する。そして、図8の(5)に示すように、ICSソフトウェア501は、所定のアルゴリズムに基づいて、リソース配分計算を実行する。すなわち、ICSソフトウェア501は、RAF502によりリソースが不足していると判定されたASP運用者に対して、空き状況情報により示される異なる種類の空きリソースのうち、制約条件を満たす任意のリソースを割り当てるリソース割当を決定する。また、ここで、ICSソフトウェア501が割り当てるリソースは、RAF502による判定結果となるリソース要件を満たすリソースとなる。また、同様に、ICSソフトウェア501は、RAF502によりリソースが余っていると判定されたASP運用者に対して、利用状況情報により示される利用中のリソースのうち、RAF502による判定結果となるリソース要件を満たすリソース分、任意のリソースを開放するリソース割当を決定する。
そして、図8の(6)に示すように、ICSソフトウェア501は、図7の(4)と同様に、決定したリソース割当を管理装置に出力する。
[廃止時における動作概要]
図9は、実施例2におけるASP運用者に割り当てられたリソースを開放する廃止時における動作概要を示す図である。リソースの割当をASP運用者が終了する時には、ASP端末602は、ASP運用者から廃止する旨の指示を受け付け、割当廃止要求をインタークラウドサーバ500に送信する。
すると、図9の(1)に示すように、ICSソフトウェア501は、割当廃止要求をASP端末602から受信する。そして、図9の(2)に示すように、ICSソフトウェア501は、図8の(1)と同様に、ASP運用者毎の利用状況情報を管理装置に要求する。つまり、異なるクラウドシステム各々について、ASP運用者毎の利用状況情報を収集する。言い換えると、ASP運用者に割り当てられたリソースの利用状況を確認する。
そして、図9の(3)に示すように、ICSソフトウェア501は、ASP運用者に割り当てられているリソースを開放するリソース割当を決定し、決定したリソース割当を管理装置に出力する。
[実施例2に係るインタークラウドサーバのユースケース]
図10は、実施例2に係るインタークラウドサーバのユースケースの一例を示す図である。以下では、図10を用いて、オペレータ端末601を用いるインタークラウドサーバ500のオペレータや、ASP端末602を用いるASP運用者により、インタークラウドサーバ500がどのように用いられるかの一例を示す。
なお、図10では、説明の便宜上、インタークラウドサーバ500に加えて、オペレータ端末601と、ASP端末602と、DC−OPS603と、NW−OPS604とを併せて示した。
以下では、インタークラウドサーバ500のユースケースの一例として、7つのユースケースを順に説明する。具体的には、システム情報を登録する場面と、リソース配分を行う場面と、新設を実行する場面と、廃止を実行する場面と、制約条件を登録する場面と、クラウドサービス利用中のASP運用者の削除する場面と、利用状況を確認する場面とについて、順に説明する。
[システム情報を登録する場面]
図10の(1)に示すように、システム情報を登録する場面について説明する。具体的には、インタークラウドサーバ500が各種の処理を実行する上で用いられる各種設定の登録を行う場面について説明する。図10の(1)に示すように、システム情報を登録する場面については、ICS運用者により利用される。
この場合、インタークラウドサーバ500の運用者は、リソース配分計算にて用いるアルゴリズムをオペレータ端末601から、インタークラウドサーバ500に登録する。また、インタークラウドサーバ500のオペレータは、オペレータ端末601から、管理情報を管理情報DB512に格納したり、管理情報を更新したりする。また、インタークラウドサーバ500のオペレータは、DC−OPS603についての管理情報を管理情報DB512に格納したり、NW−OPS604についての管理情報を管理情報DB512に格納したり、管理情報に変更があった場合に管理情報DB512を更新したりする。
[リソース配分を行う場面]
図10の(2)に示すように、リソースを配分する場面について説明する。具体的には、ICSソフトウェア501が、リソースを増設したり減設したりする場面について説明する。図10の(2)に示すように、リソースを配分する場面については、ICS運用者により利用される。なお、図10の(2)に示すリソースを配分する場面については、クラウドシステムを利用しているASP運用者が存在することが前提となる。
この場合、例えば、ICSソフトウェア501は、ASP運用者各々についての利用状況情報をオペレータ端末601から受信すると、DC−OPS603やNW−OPS604各々から、全ASP運用者について利用状況情報を収集する。そして、ICSソフトウェア501は、収集した利用状況情報をオペレータ端末601に出力する。
そして、ICSソフトウェア501は、RAF502にリソース要件を要求する指示をオペレータ端末601から受信すると、全ASP運用者についての利用状況情報と制約条件とをRAF502に出力し、RAF502にリソース要件を要求する。
そして、RAF502は、ICSソフトウェア501から受信した利用状況情報と制約条件とに基づいてASP運用者毎のリソース要件を推定し、推定結果となるASP運用者毎のリソース要件をICSソフトウェア501に出力する。そして、ICSソフトウェア501は、RAF502からASP運用者毎のリソース要件を受信すると、オペレータ端末601に出力する。
ここで、ICS運用者は、ASP運用者毎のリソース要件を確認し、増設・減設が必要なASP運用者を1人選択し、オペレータ端末601からICSソフトウェア501に出力する。なお、増設・減設が必要なASP運用者がいない場合には、処理終了となる。
そして、ICSソフトウェア501は、DC−OPS603とNW−OPS604とから空きリソース情報を収集し、ICS運用者により選択されたASP運用者についての利用状況情報と空きリソース情報とをオペレータ端末601に出力する。
ここで、ICS運用者は、オペレータ端末601に出力された情報を確認し、任意のリソース配分計算を実行するアルゴリズムを選択し、オペレータ端末601からICSソフトウェア501にリソース配分計算を行う指示を出力する。
そして、ICSソフトウェア501は、ICS運用者により選択されたアルゴリズムを用いて、リソース配分計算を行い、リソース配分計算により得られたリソース割当をオペレータ端末601に出力する。
そして、ICS運用者は、オペレータ端末601に出力されたリソース割当を確認し、リソース割当を実行する指示をオペレータ端末601からICSソフトウェア501に出力する。
そして、ICSソフトウェア501は、ICS運用者により指示されたリソース割当をDC−OPS603とNW−OPS604に出力する。また、その後、ICSソフトウェア501は、DC−OPS603とNW−OPS604とから処理結果を受信し、受信した処理結果をオペレータ端末601に出力する。その後、ICS運用者は、オペレータ端末601に出力された処理結果を確認する。
なお、上述の説明では、ICSソフトウェア501が、ICS運用者から指示や情報を受信すると処理を実行する場合を用いて説明した。ただし、これに限定されるものではなく、ICSソフトウェア501は、ICS運用者による指示を待つことなく、一連の処理を自動的に実行しても良い。例えば、ICSソフトウェア501は、任意のタイミングにて、上述した一連の処理を自律的に実行しても良い。また、上述した説明では、ICS運用者が、増設・減設が必要なASP運用者を選択する場合を用いて説明したが、これに限定されるものではない。例えば、ICSソフトウェア501が、増設・減設が必要なASP運用者を識別し、識別したASP運用者各々について一連の処理を実行しても良い。
[新設を実行する場面]
図10の(3)に示すように、新設を実行する場面について説明する。具体的には、ICSソフトウェア501が、新たなASP運用者に新規にリソースを割り当てる場面について説明する。図10の(3)に示すように、新設を実行する場合については、ICS運用者により利用される。なお、図10の(3)に示す新設を実行する場面については、ASP運用者により制約条件が制約条件DB511に登録された後、新設が実行されていないことを前提として説明する。言い換えると、新設処理待ちのASP運用者がある場合を用いて説明する。
この場合、ICSソフトウェア501は、ICS運用者により、新設処理待ちのASP運用者の一覧を要求されると、要求された一覧をオペレータ端末601に出力する。
ここで、ICS運用者は、新設処理待ちのASP運用者一覧から、新設を実行するASP運用者を選択し、オペレータ端末601からICSソフトウェア501に出力する。なお、新設処理待ちのASP運用者がいない場合には、処理が終了することになる。
そして、ICSソフトウェア501は、DC−OPS603とNW−OPS604とから空きリソース情報を収集し、収集した空きリソース情報をオペレータ端末601に出力する。
そして、ICS運用者は、オペレータ端末601に出力された空きリソース情報を確認し、リソース配分計算を実行するアルゴリズムを選択し、オペレータ端末601からICSソフトウェア501にリソース配分計算を行う指示を送信する。
そして、ICSソフトウェア501は、ICS運用者により選択されたASP運用者について、ICS運用者により選択されたアルゴリズムを用いてリソース配分計算を行い、計算結果となるリソース割当をオペレータ端末601に出力する。
ここで、ICS運用者は、オペレータ端末601に出力されたリソース割当を確認し、リソース割当を実行する指示をオペレータ端末601からICSソフトウェア501に出力する。その後、ICSソフトウェア501は、DC−OPS603とNW−OPS604とにリソース割当を出力し、DC−OPS603とNW−OPS604とから処理結果を受信し、受信した処理結果をオペレータ端末601に出力する。そして、ICS運用者は、オペレータ端末601に出力された処理結果を確認する。
なお、上述の説明では、ICSソフトウェア501が、ICS運用者から指示や情報を受信すると処理を実行する場合を用いて説明した。ただし、これに限定されるものではなく、ICSソフトウェア501は、ICS運用者による指示を待つことなく、一連の処理を自動的に実行しても良い。例えば、ICSソフトウェア501は、任意のタイミングにて、上述した一連の処理を自律的に実行しても良い。また、上述した説明では、ICS運用者が、新設が必要なASP運用者を選択する場合を用いて説明したが、これに限定されるものではない。例えば、ICSソフトウェア501が、新規割当要求を受信すると、新設することを要求されたASP運用者について自動的に一連の処理を実行しても良い。
[廃止を実行する場面]
図10の(4)に示すように、廃止を実行する場面について説明する。具体的には、ICSソフトウェア501が、ASP運用者に新規にリソースを割り当てる場面について説明する。図10の(3)に示すように、新設を実行する場合については、ICS運用者により利用される。なお、図10の(3)に示す新設を実行する場面については、ASP運用者により、ASP運用者廃止が登録されているが、未だ廃止されていない場合を前提として説明する。言い換えると、廃止待ちのASP運用者がある場合を用いて説明する。
この場合、ICSソフトウェア501は、ICS運用者により、廃止処理待ちのASP運用者の一覧を要求されると、要求された一覧をオペレータ端末601に出力する。
ここで、ICS運用者は、廃止処理待ちのASP運用者の一覧から、廃止を実行するASP運用者を選択し、オペレータ端末601からICSソフトウェア501に出力する。なお、廃止処理待ちのASP運用者がいない場合には、処理が終了することになる。
そして、ICSソフトウェア501は、廃止するASP運用者についての利用状況情報をDC−OPS603やNW−OPS604から収集し、収集した利用状況情報をオペレータ端末601に出力する。
そして、ICS運用者は、オペレータ端末601に出力された利用状況情報を確認し、廃止を実行するリソース割当を実行する指示をオペレータ端末601からICSソフトウェア501に出力する。
そして、ICSソフトウェア501は、ICS運用者により選択されたリソース割当を
DC−OPS603やNW−OPS604に出力し、DC−OPS603とNW−OPS604とから処理結果を受信し、受信した処理結果をオペレータ端末601に出力する。その後、ICS運用者は、オペレータ端末601に出力された処理結果を確認する。
なお、上述の説明では、ICSソフトウェア501が、ICS運用者から指示や情報を受信すると処理を実行する場合を用いて説明した。ただし、これに限定されるものではなく、ICSソフトウェア501は、ICS運用者による指示を待つことなく、一連の処理を自動的に実行しても良い。例えば、ICSソフトウェア501は、任意のタイミングにて、上述した一連の処理を自律的に実行しても良い。また、上述した説明では、ICS運用者が、廃止が必要なASP運用者を選択する場合を用いて説明したが、これに限定されるものではない。例えば、ICSソフトウェア501が、割当廃止要求を受信すると、廃止することが要求されたASP運用者について自動的に一連の処理を実行しても良い。
[制約条件を登録する場面]
図10の(5)に示すように、制約条件を登録する場面について説明する。具体的には、ICSソフトウェア501の制約条件DB511に、ASP運用者毎の制約条件を格納する場面について説明する。図10の(5)に示すように、制約条件を登録する場面については、ASP運用者により利用される。
この場合、ICSソフトウェア501は、ASP運用者により用いられるASP端末602から、制約条件を含む新規割当要求を受信する。ここで、ICSソフトウェア501は、例えば、受信した制約条件を制約条件DB511に格納すると共に、受信した旨の返信をASP端末602に出力する。その後、例えば、ASP運用者は、ASP端末602に出力された返信を確認する。
また、ここで、例えば、ASP運用者は、ASP運用者により用いられるASP端末602から、登録済みのASP運用者の一覧をICSソフトウェア501に要求する。すると、ICSソフトウェア501は、登録済みのASP運用者の一覧をASP端末602に出力する。
そして、ASP運用者は、ASP端末602に出力された登録済みのASP運用者一覧を確認し、制約条件を登録したASP運用者を選択し、利用状況情報の確認をICSソフトウェア501に要求する。すると、ICSソフトウェア501は、選択されたASP運用者についての利用状況情報を収集し、収集した利用状況情報をASP端末602に出力する。
その後、ASP運用者は、ASP端末602に出力された利用状況情報を確認し、選択したASP運用者にリソースが割り当てられていれば完了となる。一方、ASP運用者は、割り当てられていなかった場合には、再度一連の処理を実行する。
[ASP運用者を削除する場面]
図10の(6)に示すように、クラウドサービス利用中のASP運用者を削除する場面について説明する。言い換えると、制約条件が制約条件DB501に東独されているASP運用者のユーザIDを削除する場合について説明する。図10の(6)に示すように、ASP運用者の削除する場面については、ASP運用者により利用される。なお、図10の(6)に示す場面については、クラウドシステムにより提供されるリソースを利用しているASP運用者がある場合を前提として説明する。
この場合、例えば、ICSソフトウェア501は、ASP運用者により用いられるASP端末602から、クラウドシステムにより提供されるリソースを利用中のASP運用者の一覧が要求されると、制約条件DB511に制約条件が登録されたASP運用者の一覧を出力する。
すると、ASP運用者は、ASP端末602に出力されたASP運用者の一覧を確認し、ASP運用者を1人選択して廃止する旨の指示をASP端末602からICSソフトウェア501に出力する。
そして、ICSソフトウェア501は、ASP端末602から廃止する旨の指示を受信すると、受信した旨を返信するとともに、廃止対象となるASP運用者についての制約条件を制約条件DB511から削除する。その後、ASP運用者は、ASP端末602に出力された返信を確認する。
また、ここで、例えば、ASP運用者は、ASP運用者により用いられるASP端末602から、登録済みのASP運用者の一覧をICSソフトウェア501に要求する。すると、ICSソフトウェア501は、登録済みのASP運用者の一覧をASP端末602に出力する。そして、ASP運用者は、ASP端末602に出力された登録済みのASP運用者一覧を確認し、廃止したASP運用者がなくなっていることを確認する。
[利用状況を確認する場面]
図10の(7)に示すように、利用状況を確認する場面について説明する。図10の(7)に示すように、利用状況を確認する場面については、ASP運用者やICS運用者により利用される。なお、図10の(7)に示す場面については、クラウドシステムにより提供されるリソースを利用しているASP運用者がある場合を前提として説明する。
この場合、ICSソフトウェア501は、ICS運用者により用いられるオペレータ端末601から、ASP運用者の一覧が要求されると、制約条件DB511に制約条件が登録されたASP運用者の一覧をオペレータ端末601に出力する。
そして、ICS運用者は、オペレータ端末601に出力されたASP運用者の一覧からASP運用者を1人選択し、選択したASP運用者についての利用状況情報をICSソフトウェア501に要求する。
すると、ICSソフトウェア501は、ICS運用者により選択されたASP運用者について、RAF502にリソース要件の判定を依頼し、RAF502による処理結果をオペレータ端末601に出力する。その後、ICS運用者は、オペレータ端末601に出力されたリソース要件を確認する。
なお、上述の説明では、ICS運用者を例に説明したが、ASP運用者が実行する場合であっても同様である。また、上述の説明では、ICSソフトウェア501が、RAF502にリソース要件の判定を依頼し、RAF502による処理結果となるリソース要件を出力する場合を用いて説明したが、これに限定されるものではない。例えば、ICSソフトウェア501は、割り当てられているリソースすべてが制約条件を満たしているかを確認し、確認結果をオペレータ端末601に出力しても良く、任意の情報を出力して良い。
[実施例2におけるインタークラウドサーバによる処理の流れ]
以下では、シーケンス図を用いて、実施例2におけるインタークラウドサーバ500による処理の流れの一例について説明する。具体的には、新設時における処理の流れと、リソースの増設・減設時における処理の流れと、リソースの廃止時における処理の流れとを順に説明する。なお、以下に説明する各処理の流れは、図7〜図9を用いて説明した動作概要に対応する。
[新設時における処理の流れ]
図11は、実施例2における新設時における処理の流れの一例を示すシーケンス図である。図11に示す例では、説明の便宜上、インタークラウドサーバ500のICSソフトウェア501に加えて、1つのASP端末602と、2つのDC−OPS603と、2つのNW−OPS604とを用いて説明する。
図11に示すように、ASP運用者がASP端末602からICSソフトウェア501に制約条件を入力すると(ステップS301)、ICSソフトウェア501は、受け付け完了をASP端末602に出力する(ステップS302)。つまり、ICSソフトウェア501は、制約条件を受け付けた旨をASP端末602に出力する。
そして、ICSソフトウェア501は、図11の「Loop.1」に示すように、全DC−OPS603について空きリソース情報を収集する。例えば、ICSソフトウェア501は、DC−OPS603−1に対して、DC−OPS603−1により管理されるDC605の空きリソース情報を要求する(ステップS303)。そして、ICSソフトウェア501は、DC−OPS603−1から空きリソース情報を収集する(ステップS304)。また、同様に、ICSソフトウェア501は、DC−OPS603−2に対して、DC−OPS603−2により管理されるDC605の空きリソース情報を要求する(ステップS305)。そして、ICSソフトウェア501は、DC−OPS603−2から空きリソース情報を収集する(ステップS306)。
また、ICSソフトウェア501は、図11の「Loop.2」に示すように、全NW−OPS604について空きリソース情報を収集する。具体的には、ICSソフトウェア501は、NW−OPS604−1に対して、NW−OPS604−1により管理されるNW608の空きリソース情報を要求する(ステップS307)。そして、ICSソフトウェア501は、NW−OPS604−1から空きリソース情報を収集する(ステップS308)。また、同様に、ICSソフトウェア501は、NW−OPS604−2に対して、NW−OPS604−2により管理されるNW608の空きリソース情報を要求する(ステップS309)。そして、ICSソフトウェア501は、NW−OPS604−2から空きリソース情報を収集する(ステップS310)。
そして、ICSソフトウェア501は、ASP運用者各々について、リソース分散計算を行う(ステップS311)。つまり、ICSソフトウェア501は、所定のアルゴリズムに基づいて、リソースの過不足を解消するリソース割当を決定する。例えば、ICSソフトウェア501は、空きリソース情報により示される空きリソースから、新規割当要求に含まれる制約条件を満たす任意のリソースを選択し、選択した任意のリソースを割り当てるリソース割当を決定する。
そして、ICSソフトウェア501は、図11の「Loop.3」に示すように、配分が必要な全DC−OPS603に対して、リソース割当を出力する。例えば、ICSソフトウェア501は、DC−OPS603−1にリソース割当を出力し(ステップS312)、DC−OPS603−1から結果を取得する(ステップS313)。つまり、ICSソフトウェア501は、DC−OPS603−1にリソース割当を実行させ、実行結果を取得する。また、同様に、ICSソフトウェア501は、DC−OPS603−2にリソース割当を出力し(ステップS314)、DC−OPS603−2から結果を取得する(ステップS315)。
また、ICSソフトウェア501は、図11の「Loop.4」に示すように、配分が必要な全NW−OPS604に対して、リソース割当を出力する。例えば、ICSソフトウェア501は、NW−OPS604−1にリソース割当を出力し(ステップS316)、NW−OPS604−1から結果を取得する(ステップS317)。つまり、ICSソフトウェア501は、NW−OPS604−1にリソース割当を実行させ、実行結果を取得する。また、同様に、ICSソフトウェア501は、NW−OPS604−2にリソース割当を出力し(ステップS318)、NW−OPS604−2から結果を取得する(ステップS319)。
[増設・減設時における処理の流れ]
図12は、実施例2における増設・減設時における処理の流れの一例を示すシーケンス図である。図12に示す例では、説明の便宜上、インタークラウドサーバ500のICSソフトウェア501とRAF502とに加えて、2つのDC−OPS603と、2つのNW−OPS604とを用いて説明する。
ICSソフトウェア501は、図12の「Loop.1」に示すように、全DC−OPS603について、ASP運用者毎の利用状況情報を収集する。具体的には、図12の「Loop.2」に示すように、ICSソフトウェア501は、DC−OPS603−1に対して、ASP運用者毎の利用状況情報を要求する(ステップS401)。そして、ICSソフトウェア501は、DC−OPS603−1からASP運用者毎の利用状況情報を収集する(ステップS402)。また、同様に、図12の「Loop.3」に示すように、ICSソフトウェア501は、DC−OPS603−2に対して、ASP運用者毎の利用状況情報を要求する(ステップS403)。そして、ICSソフトウェア501は、DC−OPS603−2からASP運用者毎の利用状況情報を収集する(ステップS404)。
また、ICSソフトウェア501は、図12の「Loop.4」に示すように、全NW−OPS604について、ASP運用者毎の利用状況情報を収集する。具体的には、図12の「Loop.5」に示すように、ICSソフトウェア501は、NW−OPS604−1に対して、ASP運用者毎の利用状況情報を要求する(ステップS405)。そして、ICSソフトウェア501は、NW−OPS604−1からASP運用者毎の利用状況情報を収集する(ステップS406)。また、同様に、図12の「Loop.6」に示すように、ICSソフトウェア501は、NW−OPS604−2に対して、ASP運用者毎の利用状況情報を要求する(ステップS407)。そして、ICSソフトウェア501は、NW−OPS604−2からASP運用者毎の利用状況情報を収集する(ステップS408)。
そして、ICSソフトウェア501は、図12の「Loop.7」に示すように、全ASP運用者について、RAF502にリソース要件を推定させる。具体的には、ICSソフトウェア501は、ASP運用者毎の利用状況情報と制約条件とをRAF502に出力する(ステップS409)。その後、RAF502は、ASP運用者に割り当てられているリソースについての利用状況情報と制約条件とに基づいて、ASP運用者に割り当てることが推奨されるリソースのリソース要件を推定する(ステップS410)。例えば、RAF502は、利用状況情報を解析することで、ASP運用者が必要とするリソース量を推定し、制約条件に合致して推定したリソース量を満たすリソース要件を推定する。その後、RAF502は、推定結果となるリソース要件の計算結果をICSソフトウェア501に出力する。
その後、ICSソフトウェア501は、図12の「Loop.8」に示すように、リソースの増設や減設が必要となった全ASP運用者について、リソース割当を決定し、DC−OPS603やNW−OPS604に出力する。すなわち、RAF502による計算結果となるリソース要件と、利用状況情報により示される利用中のリソースとの間に過不足があるASP運用者各々について、過不足を解消するリソース割当を決定し、決定したリソース割当をリソースの管理装置に出力する。
具体的には、図12の「Loop.9」に示すように、ICSソフトウェア501は、全DC−OPS603について空きリソース情報を収集する。例えば、ICSソフトウェア501は、DC−OPS603−1に対して、DC−OPS603−1により管理されるDC605の空きリソース情報を要求する(ステップS411)。そして、ICSソフトウェア501は、DC−OPS603−1から空きリソース情報を収集する(ステップS412)。また、同様に、ICSソフトウェア501は、DC−OPS603−2に対して、DC−OPS603−2により管理されるDC605の空きリソース情報を要求する(ステップS413)。そして、ICSソフトウェア501は、DC−OPS603−2から空きリソース情報を収集する(ステップS414)。
また、図12の「Loop.10」に示すように、ICSソフトウェア501は、全NW−OPS604について空きリソース情報を収集する。具体的には、ICSソフトウェア501は、NW−OPS604−1に対して、NW−OPS604−1により管理されるNW608の空きリソース情報を要求する(ステップS415)。そして、ICSソフトウェア501は、NW−OPS604−1から空きリソース情報を収集する(ステップS416)。また、同様に、ICSソフトウェア501は、NW−OPS604−2に対して、NW−OPS604−2により管理されるNW608の空きリソース情報を要求する(ステップS417)。そして、ICSソフトウェア501は、NW−OPS604−2から空きリソース情報を収集する(ステップS418)。
そして、ICSソフトウェア501は、ソースの増設や減設が必要となった全ASP運用者について、リソース分散計算を行う(ステップS419)。
そして、ICSソフトウェア501は、図12の「Loop.11」に示すように、配分が必要な全DC−OPS603に対して、リソース割当を出力する。つまり、リソースを再配分する。例えば、ICSソフトウェア501は、DC−OPS603−1にリソース割当を出力し(ステップS420)、DC−OPS603−1から結果を取得する(ステップS421)。つまり、ICSソフトウェア501は、DC−OPS603−1にリソース割当を実行させ、実行結果を取得する。また、同様に、ICSソフトウェア501は、DC−OPS603−2にリソース割当を出力し(ステップS422)、DC−OPS603−2から結果を取得する(ステップS423)。
また、ICSソフトウェア501は、図12の「Loop.12」に示すように、配分が必要な全NW−OPS604に対して、リソース割当を出力する。つまり、リソースを再配分する。例えば、ICSソフトウェア501は、NW−OPS604−1にリソース割当を出力し(ステップS424)、NW−OPS604−1から結果を取得する(ステップS425)。つまり、ICSソフトウェア501は、NW−OPS604−1にリソース割当を実行させ、実行結果を取得する。また、同様に、ICSソフトウェア501は、NW−OPS604−2にリソース割当を出力し(ステップS426)、NW−OPS604−2から結果を取得する(ステップS427)。
[廃止時における処理の流れ]
図13は、実施例2における廃止時における処理の流れの一例を示すシーケンス図である。図13に示す例では、説明の便宜上、インタークラウドサーバ500のICSソフトウェア501に加えて、1つのASP端末602と、2つのDC−OPS603と、2つのNW−OPS604とを用いて説明する。
図13に示すように、ASP運用者がASP端末602からICSソフトウェア501に割当廃止要求を入力すると(ステップS501)、ICSソフトウェア501は、受け付け完了をASP端末602に出力する(ステップS502)。つまり、ICSソフトウェア501は、割当廃止要求を受け付けた旨をASP端末602に出力する。
そして、ICSソフトウェア501は、図13の「Loop.1」に示すように、全DC−OPS603について、ASP運用者毎の利用状況情報を収集する。具体的には、ICSソフトウェア501は、割当廃止要求による廃止の対象となるASP運用者について、ASP運用者毎の利用状況情報を収集する。例えば、ICSソフトウェア501は、DC−OPS603−1に対して、ASP運用者毎の利用状況情報を要求する(ステップS503)。そして、ICSソフトウェア501は、DC−OPS603−1からASP運用者毎の利用状況情報を収集する(ステップS504)。また、同様に、ICSソフトウェア501は、DC−OPS603−2に対して、ASP運用者毎の利用状況情報を要求する(ステップS505)。そして、ICSソフトウェア501は、DC−OPS603−2からASP運用者毎の利用状況情報を収集する(ステップS506)。
そして、ICSソフトウェア501は、図13の「Loop.2」に示すように、全NW−OPS604について、ASP運用者毎の利用状況情報を収集する。具体的には、ICSソフトウェア501は、割当廃止要求による廃止の対象となるASP運用者について、ASP運用者毎の利用状況情報を収集する。例えば、ICSソフトウェア501は、NW−OPS604−1に対して、ASP運用者毎の利用状況情報を要求する(ステップS507)。そして、ICSソフトウェア501は、NW−OPS604−1からASP運用者毎の利用状況情報を収集する(ステップS508)。また、同様に、ICSソフトウェア501は、NW−OPS604−2に対して、ASP運用者毎の利用状況情報を要求する(ステップS509)。そして、ICSソフトウェア501は、NW−OPS604−2からASP運用者毎の利用状況情報を収集する(ステップS510)。
そして、ICSソフトウェア501は、図13の「Loop.3」に示すように、指定ASP運用者が使用中の全DC−OPS603について、リソースの割当を廃止するリソース割当を出力する。言い換えると、ICSソフトウェア501は、割当廃止要求による廃止の対象となるASP運用者にリソースを割り当てているDC−OPS603各々に対して、リソースの割当を廃止するリソース割当を出力する。例えば、ICSソフトウェア501は、DC−OPS603−1にリソース割当を出力し(ステップS511)、DC−OPS603−1から結果を取得する(ステップS512)。つまり、ICSソフトウェア501は、DC−OPS603−1にリソースの割当を廃止するリソース割当を実行させ、実行結果を取得する。また、同様に、ICSソフトウェア501は、DC−OPS603−2にリソース割当を出力し(ステップS513)、DC−OPS603−2から結果を取得する(ステップS514)。
また、ICSソフトウェア501は、図13の「Loop.4」に示すように、指定ASP運用者が使用中の全NW−OPS604について、リソースの割当を廃止するリソース割当を出力する。言い換えると、ICSソフトウェア501は、割当廃止要求による廃止の対象となるASP運用者にリソースを割り当てているNW−OPS604各々に対して、リソースの割当を廃止するリソース割当を出力する。例えば、ICSソフトウェア501は、NW−OPS604−1にリソース割当を出力し(ステップS515)、NW−OPS604−1から結果を取得する(ステップS516)。つまり、ICSソフトウェア501は、NW−OPS604−1にリソースの割当を廃止するリソース割当を実行させ、実行結果を取得する。また、同様に、ICSソフトウェア501は、NW−OPS604−2にリソース割当を出力し(ステップS517)、NW−OPS604−2から結果を取得する(ステップS518)。
[実施例2において用いられる各種データのデータ構造の一例]
実施例2において用いられる各種データのデータ構造の一例について説明する。以下では、管理情報の一例と、制約条件の一例と、DCについての利用状況情報の一例と、DCについての空きリソース情報の一例と、DCについてのリソース割当の一例と、NWについての利用状況情報の一例と、NWについての空きリソース情報の一例と、NWについてのリソース割当の一例とを順に説明する。
なお、実施例2において用いられる各種データのデータ構造の一例について説明する際には、データ構造に含まれるテーブル各々を識別する「テーブル番号」と、テーブルに含まれる要素を示す「要素」と、テーブルに要素がいくつあるかを示す「個数」と、要素についての説明となる「備考」とを用いて説明する。
[管理情報]
図14及び図15を用いて、実施例2における管理情報DB512に記憶される管理情報の詳細な一例を示す。管理情報DB512は、以下に説明するように、DC−OPS603についての管理情報を記憶し、NW−OPS604についての管理情報を記憶する。
図14は、実施例2におけるDC−OPSについての管理情報の一例を示す図である。図14のテーブル番号「1」に示すように、管理情報DB512は、DC−OPS管理情報リストを記憶する。ここで、DC−OPS管理情報リストには、DC−OPS603についての管理情報であるDC−OPS管理情報が複数含まれる。すなわち、DC−OPS管理情報リストには、DC−OPS603とDC605との対応表が複数含まれる。DC−OPS管理情報は、例えば、ICSソフトウェア501の初期設定として入力される。
DC−OPS管理情報の詳細な一例について説明する。図14のテーブル番号「2」に示すように、DC−OPS管理情報は、例えば、1つの「DC−OPS名」と、1つの「DC−OPSのURL」と、1つの「アクセスID」と、1つの「パスワード」と、1つの「コメント」と、1つの「フラグ」とを含む。
ここで、「DC−OPS名」は、DC−OPSの識別名である。「DC−OPSのURL」は、DC−OPS603にアクセスするためのURLである。「アクセスID」は、DC−OPS603にアクセスするためのアクセスIDである。「パスワード」は、DC−OPS603にアクセスするためのパスワードである。「コメント」は、DC−OPS603の注釈等情報である。「フラグ」は、DC−OPS603の有効、無効などの情報である。
例えば、DC−OPS管理情報は、DC−OPS名「N社の管理装置」と、DC−OPSのURL「www.123〜」と、アクセスID「USER0001」と、パスワード「sakura」と、コメント「使い勝手が良い」と、フラグ「有効」を含む。この場合、DC−OPS管理情報には、例えば、N社の管理装置というDC−OPSについて、URLが「www.123〜」であることが含まれ、アクセスする際にはアクセスID「USE0001」とパスワード「sakura」とを用いることが含まれ、「使い勝手が良い」というコメントが含まれ、「有効」であるというフラグが含まれる。
図15は、実施例2におけるNW−OPSについての管理情報の一例を示す図である。図15のテーブル番号「3」に示すように、管理情報DB512は、NW−OPS管理情報リストを記憶する。ここで、NW−OPS管理情報リストには、NW−OPS604についての管理情報であるNW−OPS管理情報が複数含まれる。すなわち、NW−OPS管理情報リストには、NW−OPS604とNW608との対応表が複数含まれる。NW−OPS管理情報は、例えば、ICSソフトウェア501の初期設定として入力される。
NW−OPS管理情報の詳細な一例ついて説明する。図14のテーブル番号「4」に示すように、NW−OPS管理情報は、例えば、1つの「NW−OPS名」と、1つの「NW−OPSのURL」と、1つの「アクセスID」と、1つの「パスワード」と、1つの「コメント」と、1つの「フラグ」とを含む。
[制約条件]
図16は、実施例2における制約条件DBに記憶された制約条件の一例を示す図である。図16のテーブル番号「5」に示すように、制約条件DB511は、制約条件リストを記憶する。ここで、制約条件リストには、ASP運用者毎の制約条件となる制約条件テーブルが複数含まれる。制約条件リストは、例えば、ASP運用者によって入力される。
制約条件テーブルの詳細な一例について説明する。図16のテーブル番号「6」に示すように、制約条件テーブルは、例えば、1つの「ユーザID」と、1つ又は複数の「VMリスト」と、1つ又は複数の「ユーザ所在地」と、1つの「NW帯域」と、1つの「NW遅延」と、1つの「料金上限」と、1つ又は複数の「DC地域指定」と、1つ又は複数の「セキュリティ」と、1つの「DC稼働率」とを含む。
ここで、「ユーザID」は、ASP運用者を識別するユーザIDである。「VMリスト」は、ASP運用者により要求されたVMのリストを示す。なお、VMリストの詳細については、後述する。「ユーザ所在地」は、リソースの割当を要求したユーザの所在地を示す。「NW帯域」は、要求されたネットワークの帯域を示す。「料金上限」は、ユーザが許容する料金の上限値を示す。「DC地域指定」は、割り当て可能となるDC605の地域についての情報を示す。「セキュリティ」は、リソースに備えられたセキュリティについての情報を示す。「DC稼働率」は、割当可能となるDC605の許容最低稼働率を示す。「NW遅延」は、ネットワークの遅延量として許容される値を示す。
例えば、制約条件テーブルは、ユーザID「USER0001」と、VMリスト「A」と「B」と、ユーザ所在地「東京」「大阪」と、NW帯域「各ユーザ−DCまでの帯域は100Mbps」と、NW遅延「1sec」と、料金上限「月額200万以下」と、DC地域指定「日本国内」と、セキュリティ「特になし」と、DC稼働率「99.99%」を含む。この場合、制約条件テーブルは、ユーザID「USER0001」についての制約条件を含む。具体的には、制約条件テーブルは、制約条件として、「USER0001」にVMリスト「A」と「B」とにより識別されるVMが要求されることと、「各ユーザ−DCまでの帯域は100Mbps」であることを含む。また、制約条件テーブルは、制約条件として、NW遅延「1sec」以内となることと、料金上限が「月額200万以下」となることと、「日本国内」にあるDCであることと、DC稼働率が「99.99%」であることとを含む。
[DCについての利用状況情報]
図17は、実施例2におけるDCについての利用状況情報の一例を示す図である。図17のテーブル番号「7」に示すように、DC605についての利用状況情報には、DC605の利用状況を示すDC利用状況テーブルが複数含まれる。
DC利用状況テーブルの詳細な一例について説明する。図17のテーブル番号「8」に示すように、DC利用状況テーブルは、1つの「ユーザID」と、1つ又は複数の「DCリソース」と、1つの「利用料金」とを含む。ここで、「DCリソース」は、DC605のリソースを示す。なお、DC利用状況テーブルに含まれるDCリソースは、ユーザIDにより識別されるASP運用者により利用されているDC605のリソースを示す。「DCリソース」の詳細については、後述する。
例えば、DC利用状況テーブルは、ユーザID「USER0001」と、利用料金「合計で24万/月」を含む。この場合、DC利用状況テーブルは、「USER0001」により利用されている「DCリソース」と、「USER0001」により利用されているDC605のリソースの料金が「合計で24万/月」であることを含む。
[DCについての空きリソース情報]
図18は、実施例2におけるDCについての空きリソース情報の一例を示す図である。図18のテーブル番号「9」に示すように、DC605についての空きリソース情報であるDC空きリソース情報は、DCリソースを複数含む。
図19は、実施例2におけるDCリソース情報の一例を示す図である。図19のテーブル番号「10」に示すように、DCリソースには、DC605を識別する「DC名」が1つ含まれ、DC605の所在地を示す「DC所在地」が1つ含まれ、DC605を管理するDC−OPS603の「DC−OPS名」が1つ含まれ、DC605により提供されるリソースを示す「VMリスト」が複数含まれる。
VMリストの詳細な一例について説明する。図19のテーブル番号「11」に示すように、VMリストは、VMのタイプを示す「VMタイプ」が1つ含まれ、VMの数を示す「VM数」が1つ含まれ、VMの使用率を示す「使用率」が1つ含まれる。例えば、VMリストは、VMタイプ「Type1」とVM数「10台」と使用率「50%」とを含む。この場合、VMリストには、Type1のVMが10台あり、そのうちの50%のVMが使用されていることが含まれる。
VMタイプの詳細な一例について説明する。図19のテーブル番号「12」に示すように、VMタイプは、VMタイプのタイプ名を示す「VMタイプ名」と、VMのコア数を示す「コア数」と、VMのメモリ容量を示す「メモリ」と、VMのHDD容量を示す「HDD」と、VMの料金を示す「料金」を1つ含む。すなわち、VMタイプは、DC605により提要されるVMについての詳細を含む。
[DCについてのリソース割当]
図20は、実施例2におけるDCについてのリソース割当の一例を示す図である。図20に示す例では、ASP運用者毎のリソース割当を例として示した。図20のテーブル番号「13」に示すように、DCのリソース割当には、リソースの割当の対象となるASP運用者を示す「ユーザID」が1つ含まれる。また、割り当てられるリソースを示す「VM割当」が複数含まれる。
ここで、「VM割当」各々には、リソース割当が実行されるDC605を示す「DC名」が1つと、VMのタイプ毎の割当を示す「タイプ別VM割当」を複数含む。「タイプ別VM割当」は、VMのタイプ毎に、リソース割当前の「VMリスト」と、リソース割当後の「VMリスト」とが含まれる。図20に示すリソース割当では、ASP運用者毎に、複数のDCに対して、複数のVMの割り当てが行えるようになっている。
[NWについての利用状況情報]
図21は、実施例2におけるNWについての利用状況情報の一例を示す図である。図21のテーブル番号「14」に示すように、NW608についての利用状況情報には、NW608の利用状況を示すNW利用状況テーブルが複数含まれる。
NW利用状況テーブルの詳細な一例について説明する。図21のテーブル番号「15」に示すように、NW利用状況テーブルは、1つの「ユーザID」と、1つ又は複数の「NWリソース」と、1つの「利用料金」とを含む。ここで、「NWリソース」は、NW608のリソースを示す。なお、NW利用状況テーブルに含まれるNWリソースは、ユーザIDにより識別されるASP運用者により利用されているNW608のリソースを示す。「NWリソース」の詳細については、後述する。
[NWについての空きリソース情報]
図22は、実施例2におけるNWについての空きリソース情報の一例を示す図である。図22のテーブル番号「16」に示すように、NW608についての空きリソース情報であるNW空きリソース情報は、NWリソースを複数含む。
図23は、実施例2におけるNWリソース情報の一例を示す図である。図23のテーブル番号「17」に示すように、NWリソースには、NW608を識別する「NW名」が1つと、NW608を管理するNW−OPS604の「NW−OPS名」が1つと、NW608により提供されるリソースを示す複数の「NWリスト」とが含まれる。
なお、図23に示す例では、NW名として、どこからどこまでのネットワークであるかを示す名称を用いる場合を示した。例えば、NW名「End−to−End」は、DC605とユーザ端末607との間のネットワークと、DC605間のNWとの両方を含むネットワークを示す。
NWリストの詳細な一例について説明する。図23のテーブル番号「18」に示すように、NWリストは、ネットワークの始点を示す「始点」が1つと、ネットワークの終点を示す「終点」が1つと、ネットワークのタイプを示す「NWタイプ」が1つと、ネットワークの数を示す「NW数」が1つと、ネットワークの使用率を示す「使用率」を1つ含む。なお、図23のテーブル番号「18」における「NW数」と「使用率」とは、「NWタイプ」のネットワークの数と使用率とを示す。
NWタイプの詳細な一例について説明する。図23のテーブル番号「19」に示すように、NWタイプは、ネットワークのタイプ名を示す「NWタイプ名」が1つと、ネットワークの帯域を示す「回線帯域」が1つと、ネットワークの遅延を示す「回線遅延」が1つと、ネットワークの料金である「料金」を1つ含む。
[NWについてのリソース割当]
図24は、実施例2におけるNWについてのリソース割当の一例を示す図である。図24に示す例では、ASP運用者毎のリソース割当を例として示した。図24のテーブル番号「20」に示すように、NWのリソース割当には、リソースの割当の対象となるASP運用者を示す「ユーザID」が1つ含まれる。また、割り当てられるリソースを示す「NW割当」が複数含まれる。
ここで、「NW割当」各々には、リソース割当が実行されるNW608を示す「NW名」が1つと、NWのタイプ毎の割当を示す「タイプ別NW割当」を複数含む。「タイプ別NW割当」は、NWのタイプ毎に、リソース割当後の「NWリスト」が含まれる。図24に示すリソース割当では、ASP運用者毎に、複数のNWに対して、複数のNWの割り当てが行えるようになっている。