JP5420585B2 - コンテナ型もしくはモジュール型データセンターからなる分散データセンター - Google Patents

Description

本発明は、データセンターの技術に関し、特に、遠隔地に分散して配置された複数の可搬型データセンターからなる分散データセンターに適用して有効な技術に関するものである。

近年、企業等によるＩＴ技術の利用の進展により、業務上利用する情報処理システムに係るサーバ等のコンピュータ機器やネットワーク機器などの多数のＩＴ機器をデータセンターに集約して配置し、一元的に運用管理を行う形態がとられる場合が多い。これらの形態には、例えば、自社で独自に運用管理を行う形態や、ＩＴベンダー等に運用管理を委託する形態、ＩＴベンダー等が保有して運用管理するＩＴリソースを必要に応じてユーザに提供するクラウドコンピューティングサービスの形態などがある。また、データセンターについても、自社で保有する形態や、ＩＴベンダー等が保有して運用管理するデータセンターに間借り等する形態などがある。

上記のような各種形態で利用されるデータセンターには、主に、多数のＩＴ機器を安定して稼動させるための各種ファシリティ（例えば、冗長化された電源設備や、ネットワーク回線、空調等の冷却・排熱設備、機器配置に適したフロア構造、耐震構造、セキュリティ設備など）を保有する専用の大型の施設が利用されている。このようなデータセンターでは、一般的に、稼動しているＩＴ機器の動作状況や、施設のファシリティの状況を専用の監視ルームや監視センター等で一元的、集中的に監視し、運用を行う仕組みがとられている。

これに関する技術としては、例えば、ファシリティの状況の監視について、特開２０１０−５２７４９１号公報（特許文献１）には、データセンターオペレータが、データセンター内に新たな機器を設置する助けとなるよう、データセンターの特定の区域および筐体で利用可能な電力および冷却のようなデータセンター資源を特定できるようにし、データセンター資源の要件を求めて、データセンター資源に係るシステムの性能を監視するための技術が記載されている。

一方で、データセンターをより簡易的に迅速に設置したいというニーズに応えるものとして、輸送用のコンテナ等を利用したいわゆるコンテナ型（もしくはモジュール型）データセンターなどの小型・可搬型のデータセンターの利用が広がりつつある。例えば、米国特許第７２７８２７３号明細書（特許文献２）には、輸送用のコンテナに複数のコンピュータを搭載した１つ以上のモジュールと冷却用の空調システムからなるモジュール型データセンターが記載されている。

このような可搬型データセンターは、短期間で容易・迅速に構築可能で低コストであり、また、可搬性があって設置場所等の制約も少ないという利点を有する。さらに、複数のコンテナを組み合わせるビルディングブロック方式をとることにより、コンテナ単位での増設や撤去が容易であり、無駄な投資を回避しつつ拡張性・柔軟性を向上させるという利点も有する。また、コンテナを多数組み合わせることで大規模なデータセンターを構築することも可能である。

例えば、特開２０１１−１２４０７号公報（特許文献３）には、電子計算機等が収納された複数のユニットを収容するデータセンター用建物であって、ユニット配置部を上下に複数段備えるフレーム型構造物と、フレーム型構造物に隣接して配置された搬送装置とを備え、搬送装置は、ユニットを水平を保ちつつ上下左右に移動させてユニット配置部の前面に移動させたのち、当該ユニットをユニット配置部内に送り込むことが可能に構成されていることにより、設置のための用地が限られているような場合であっても、多数のユニットを安全に配置することを可能とする技術が記載されている。

特開２０１０−５２７４９１号公報 米国特許第７２７８２７３号明細書 特開２０１１−１２４０７号公報

上述したように、コンテナ型などの可搬型データセンターは、多数組み合わせることで大型・大規模のデータセンターの構築にも利用可能である一方で、可搬性があり、設置場所の制約が少なく容易に構築が可能であることから、主に中小の企業等が自社用のデータセンターをそれぞれ構築するために用いられる場合も多いと考えられる。この場合、各地に小型・小規模のデータセンターが複数設置され、主にこれらを保有する企業等がそれぞれ独自に運用管理を行うことになる。

しかしながら、これらの企業等が人的・技術的なリソースを有しておらず、運用管理を独自に適切に行うことができない場合も多い。また、これらのデータセンターをそれぞれ個別に運用管理することは、人的リソースやＩＴリソースの効率的な活用という面で無駄が生じる場合もあり、コスト面で大きな負担となって可搬型データセンターの利用価値を減殺する場合も生じ得る。また、このような可搬型データセンターを、企業等のメインのデータセンターに対する災害対策等のためのバックアップのデータセンターとして利用するという形態も想定され、通常運用時の余剰リソースの有効利用を図りたいというニーズも想定される。

そこで本発明の目的は、分散配置された複数の可搬型（コンテナ型もしくはモジュール型）データセンターに対して、これらを遠隔地から一元的に運用管理する中央管理センターを有する分散データセンターを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による分散データセンターは、地理的に離れた複数の拠点に、１つ以上の可搬型データセンターがそれぞれ分散配置されており、各拠点の前記各可搬型データセンターが通信ネットワークを介して相互に接続されている構成を有する分散データセンターであって、以下の特徴を有するものである。

すなわち、分散データセンターは、各拠点の前記可搬型データセンターの運用管理を遠隔から行うことが可能な中央管理センターを有し、また、各拠点には、それぞれの拠点に設置された前記可搬型データセンターが保有する各ＩＴリソースの状況を保持するリソース管理テーブルを有して前記可搬型データセンターの運用管理を行うローカル管理センターを有し、前記中央管理センターを介して、第１の拠点の第１のローカル管理センターが運用管理する前記可搬型データセンターが保有するＩＴリソースを、第２の拠点の第２のローカル管理センターから利用させることを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、分散配置された複数の可搬型データセンターに対して、これらを遠隔地から一元的に運用管理する中央管理センターを有する分散データセンターを実現することが可能となる。

本発明の一実施の形態である分散データセンターの構成例について概要を示した図である。 本発明の一実施の形態におけるローカルリソース管理テーブルのデータ構成と具体的なデータの例を示した図である。 本発明の一実施の形態における中央リソース管理テーブルのデータ構成と具体的なデータの例を示した図である。 本発明の一実施の形態における他の拠点のコンテナ型データセンターからリソースを調達する処理の流れの例について概要を示した図である。 本発明の一実施の形態における他の拠点のコンテナ型データセンターから調達したリソースを返却する処理の流れの例について概要を示した図である。 本発明の一実施の形態における複数拠点のコンテナ型データセンターを統合管理する処理の流れの例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

＜概要＞
本発明の一実施の形態である分散データセンターは、地理的に離れた複数の拠点に、１つ以上のコンテナ型データセンターもしくはモジュール型データセンターなどの可搬型データセンター（以下では単に“コンテナ型データセンター”と記載する場合がある）がそれぞれ分散配置されており、各拠点のデータセンターが通信ネットワークを介して接続されている構成を有する。また、これらのデータセンターの運用管理等を遠隔から集中的に行うことが可能な中央管理センターを有する。一方、各拠点では、自身のコンテナ型データセンターの運用管理等を行うことが可能なローカル管理センターを有する。

ここで利用されるコンテナ型データセンターは、例えば、２０〜３０ｍ^２程度の面積で高さが３ｍ前後のコンテナや間仕切りによって囲まれた区域の中に、サーバ等のコンピュータ機器やネットワーク機器等のＩＴ機器を配置し、これらを原則として無停止で稼働させることができるデータセンターである。

当該コンテナ型データセンターは、ＩＴ機器を安定稼働させるためのファシリティとして、例えば、ＩＴ機器が動作するために必要となる電力や通信回線について外部から供給を受けるための接続点を有する。また、ＩＴ機器の稼働条件を満たすための温度・湿度調節機構や空調設備、電力の瞬断の際にＩＴ機器の動作を継続させるための無停電電源装置、地震による転倒等を回避するための耐震装置や免震装置、区域内を監視するための監視カメラ、入退室管理装置、その他火災・煙検知、消防・消化設備などを有する。また、ＩＴ機器やファシリティの監視、操作等の運用管理を遠隔地から行えるようにするための管理システムを有する。

＜システム構成＞
図１は、本発明の一実施の形態である分散データセンターの構成例について概要を示した図である。上述したように、分散データセンター１は、地理的に離れた複数の拠点にデータセンターが分散配置された構成を有し、各拠点では、ＬＡＮ（Local Area Network）等のローカルネットワーク２２を介して、ビルディングブロック方式により組み合わされて配置された１つ以上のコンテナ型データセンター（ＤＣ）２１と、これらの運用管理を各拠点で自律して行うことが可能なローカル管理センター２０を有する。

各拠点では、コンテナ型ＤＣ２１によってデータセンターを構築するため、データセンター専用のビル等の施設が不要であり、短期間で容易・迅速に構築可能なため低コストであるという特徴を有する。また、ビルディングブロック方式をとることによりコンテナ単位での増設や撤去が容易であり、無駄な投資を回避しつつ拡張性・柔軟性を向上させるという利点も有する。

各拠点のコンテナ型ＤＣ２１およびローカル管理センター２０は、ネットワーク３０を介して相互に接続される構成となっている。ネットワーク３０は、例えば、インターネット等の公衆通信網や、ＷＡＮ（Wide Area Network）、ＶＰＮ（Virtual Private Network）等の一般公衆回線を一部に用いた通信網などを適宜利用することができる。

また、分散データセンター１は、各拠点のコンテナ型ＤＣ２１の運用管理を遠隔から集中的に行うことが可能な中央管理センター１０を有する。なお、中央管理センター１０や各ローカル管理センター２０は、一般的なデータセンター等におけるＩＴ機器の運用管理を行う仕組み（例えば、各機器やソフトウェアの起動・停止や、障害監視、リソース使用率や使用量の管理、パフォーマンスの監視等を行う運用管理システムなど）を有している。

＜リソース管理テーブル＞
各拠点のローカル管理センター２０は、自身が管理するコンテナ型ＤＣ２１内のＩＴリソース（以下では単に“リソース”と記載する場合がある）を管理するため、ローカルリソース管理テーブルをそれぞれ保持する。図２は、ローカルリソース管理テーブルのデータ構成と具体的なデータの例を示した図である。ローカルリソース管理テーブル２３は、各ローカル管理センター２０が運用管理するコンテナ型ＤＣ２１が有するリソースの状況を保持するテーブルであり、例えば、“リソースＩＤ”、“リソース種別”、“容量”、“管理元”、“アクセスＩＤ”などの項目を有する。

“リソースＩＤ”の項目は、管理対象の各リソースを識別するＩＤの情報を保持する。“リソース種別”の項目は、対象のリソースの種別（例えば、ＣＰＵ（Central Processing Unit）やストレージ、入出力装置、ネットワーク帯域など）を識別する名称やＩＤ等の情報を保持する。“容量”の項目は、対象のリソースの容量に係る情報（例えば、ＣＰＵパワーやストレージの容量など）を保持する。“管理元”の項目は、対象のリソースを運用管理している管理センターを識別する名称等の情報を保持する。各リソースは、後述するように、通常はローカル管理センター２０もしくは中央管理センター１０のいずれかによって運用管理されるが、一時的に“空き”という状態をとる場合もある。“アクセスＩＤ”の項目は、対象のリソースに対するアクセス権限を有するユーザＩＤの情報を有する。

一方、中央管理センター１０は、後述するように、各コンテナ型ＤＣ２１の運用管理等を遠隔から集中的に行うことが可能であり、また、各コンテナ型ＤＣ２１が保有するリソースを調達して他の拠点に融通することができるという特徴を有する。このため、中央管理センター１０自身が管理するコンテナ型ＤＣ２１のリソースを管理するため、中央リソース管理テーブルを有する。図３は、中央リソース管理テーブルのデータ構成と具体的なデータの例を示した図である。中央リソース管理テーブル１１は、中央管理センター１０が集中的に運用管理するリソースの状況を保持するテーブルであり、例えば、“保有ＤＣ”、“リソースＩＤ”、“リソース種別”、“容量”、“利用ＤＣ”、“アクセスＩＤ”などの項目を有する。

“リソースＩＤ”、“リソース種別”、“容量”、“アクセスＩＤ”の各項目については、図２のローカルリソース管理テーブル２３における内容と同様なので、再度の説明は省略する。“保有ＤＣ”の項目は、対象のリソースを物理的に保有するコンテナ型ＤＣ２１を識別する名称やＩＤ等の情報を保持する。“利用ＤＣ”の項目は、対象のリソースを実際に利用しているコンテナ型ＤＣ２１（もしくは拠点）を識別する名称やＩＤ等の情報を保持する。

拠点のコンテナ型ＤＣ２１が保有しかつ利用しているリソースの運用管理を中央管理センター１０が集中的に行っている場合は、“保有ＤＣ”と“利用ＤＣ”には同一のコンテナ型ＤＣ２１の値が保持される。また、後述するように、拠点のコンテナ型ＤＣ２１が保有するリソースを調達して、中央管理センター１０が他の拠点に融通している場合は、“保有ＤＣ”と“利用ＤＣ”には異なるコンテナ型ＤＣ２１の値が保持される。

なお、上述の図２、図３で示した各テーブルは、例えば、データベースやファイルテーブルなどの各種手段によって構成することができる。また、これらのテーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。

＜リソースの相互調達処理＞
本実施の形態の分散データセンター１では、地理的に離れた拠点間でリソースを融通し合うことが可能である。通常は、各拠点においてローカル管理センター２０がそれぞれ自身が運用管理するコンテナ型ＤＣ２１におけるリソースの利用状況をローカルリソース管理テーブル２３によって管理している。ここで、例えば、ある拠点のコンテナ型ＤＣ２１において新たに仮想サーバを構築する際に、当該コンテナ型ＤＣ２１が十分なリソースを保有していない場合には、他の拠点のコンテナ型ＤＣ２１が保有する空きリソースを調達して利用することを可能とする。

図４は、他の拠点のコンテナ型ＤＣ２１からリソースを調達する処理の流れの例について概要を示した図である。まず、初期状態として、各拠点では通常運用として、コンテナ型ＤＣ２１の全てのリソースの運用管理は、対応するローカル管理センター２０がそれぞれ行っているものとする。従って、各ローカル管理センター２０におけるローカルリソース管理テーブル２３では、各リソースの“管理元”は全てローカル管理センター２０であることを示す値（図２の例では“ローカル”）となっているものとする。

ここで、リソースの調達を希望する拠点のローカル管理センター２０である、要求元ローカル管理センター２０ａは、中央管理センター１０に対してリソースの要求を行う（Ｓ０１）。リソースの要求には、例えば、必要なリソースの種別と容量の情報などが含まれる。

リソースの要求を受けた中央管理センター１０は、調達先となる拠点を選定する（Ｓ０２）。調達先を選定する手法としては種々のものが考えられるが、特に限定されない。例えば、地理的な距離が近い拠点から優先的に選択してもよいし、対象のリソースの種別について、保有リソースや未割り当てリソースの多いコンテナ型ＤＣ２１を有する拠点から優先的に選択してもよい。また、選定処理についても、中央管理センター１０においてシステム的に行ってもよいし、管理者等が選定した結果を指定するようにしてもよい。

次に、中央管理センター１０は、選定した拠点のローカル管理センター２０である、調達先ローカル管理センター２０ｂに対して、必要なリソースの情報を提示する（Ｓ０３）。必要なリソースの情報には、例えば、必要なリソースの種別と容量の情報が含まれる。必要なリソースの情報の提示を受けた調達先ローカル管理センター２０ｂでは、提供可能な１つ以上のリソースの情報を抽出して中央管理センター１０に報告する（Ｓ０４）。このとき、提供可能なリソースについては、調達先ローカル管理センター２０ｂにおけるローカルリソース管理テーブル２３の“管理元”の値を、どの管理センターにも管理されていない空き状態であることを示す値（図２の例では“空き”）に更新することで、当該リソースを“仮押さえ”する。

提供可能なリソースを得る手法としては種々のものが考えられるが、特に限定されない。例えば、自身が運用管理するコンテナ型ＤＣ２１のリソース（例えば、図２の例ではローカルリソース管理テーブル２３の“管理元”の値が“ローカル”であるリソース）のうち、未割り当て（未使用）もしくは利用率の少ないリソースを抽出するようにしてもよい。また、このような手法によって得られる提供可否の情報を、予めローカルリソース管理テーブル２３にリソース毎に保持しておくようにしてもよい。なお、提供可能なリソースの情報には、例えば、リソースＩＤや容量の情報などが含まれる。

調達先ローカル管理センター２０ｂから提供可能なリソースの情報を受けた中央管理センター１０は、調達先ローカル管理センター２０ｂから提供された提供可能リソースの情報から、提供を受ける（調達する）リソースを選定し、その情報を調達先ローカル管理センター２０ｂに提示する（Ｓ０５）。提供を受けるリソースの情報には、例えば、対象のリソースのリソースＩＤなどの情報が含まれる。

提供を受けるリソースの提示を受けた調達先ローカル管理センター２０ｂは、提供するリソースについて、ローカルリソース管理テーブル２３の“管理元”の値を、中央管理センター１０を示す値（図２の例では“中央”）に更新するとともに、提供するリソースに係る情報を中央管理センター１０に報告する（Ｓ０６）。このとき、提供しなかったリソースについては、ローカルリソース管理テーブル２３の“管理元”の値を、調達先ローカル管理センター２０ｂを示す値（図２の例では“ローカル”）に戻し、運用管理を継続もしくは再開する。提供するリソースに係る情報には、例えば、対象のリソースＩＤやリソース種別、容量、さらにアクセスに係る情報として、アクセスＩＤやアクセス権限、アクセス先のアドレスやホスト名等の情報などが含まれる。

提供するリソースの情報の報告を受けた中央管理センター１０は、調達先ローカル管理センター２０ｂから調達した当該リソースに係る情報を、要求元ローカル管理センター２０ａに提供する（Ｓ０７）。調達したリソースに係る情報には、例えば、リソースＩＤやリソース種別、容量、さらに対象のリソースへのアクセスに係る情報などが含まれる。

調達したリソースに係る情報の提供を受けた要求元ローカル管理センター２０ａは、当該情報に基づいて、調達先ローカル管理センター２０ｂが運用管理するコンテナ型ＤＣ２１が保有する対象のリソースにアクセスしてこれを利用する（Ｓ０８）。本実施の形態では、当該リソースについての障害監視等の運用管理は中央管理センター１０が行うものとしているが、要求元ローカル管理センター２０ａが行うように構成することも可能である。

なお、各管理センターにおける上記の処理やメッセージの送受信は、これらの一部または全部を、例えば、各管理センターのオペレータや管理者等による端末の操作によって実行されるようにしてもよいし、システム的なイベント（メッセージの受信等）などをトリガとした自動処理により実行されるように構成することも可能である。

また、図４の例では、ステップＳ０２において、調達先の拠点（調達先ローカル管理センター２０ｂ）を１つ選定してリソースの調達を行う場合を例として説明したが、要求元ローカル管理センター２０ａからの１つもしくは複数のリソースの要求に対して、中央管理センター１０が調達先の拠点を複数選定してリソースの調達を行うように構成することも可能である。このとき、中央管理センター１０は、例えば、選定された各拠点のローカル管理センター２０に対してステップＳ０３〜Ｓ０７の一連の処理を連続的に行って逐次的に複数のリソースの調達を行ってもよいし、選定された各拠点に対してステップＳ０３において同報的に必要リソースの提示を行って同時並行的に複数のリソースの調達を行ってもよい。

図５は、他の拠点のコンテナ型ＤＣ２１から調達したリソースを返却する処理の流れの例について概要を示した図である。ここでは、図４に示した処理フローによって調達先ローカル管理センター２０ｂが運用管理するコンテナ型ＤＣ２１から調達したリソースを、調達先ローカル管理センター２０ｂ、もしくは要求元ローカル管理センター２０ａからの要求に基づいて返却することを可能とする。

例えば、調達先ローカル管理センター２０ｂの拠点において提供しているリソースを返して欲しいと希望する場合など、調達先ローカル管理センター２０ｂからの要求に基づいてリソースを返却する場合は、まず、調達先ローカル管理センター２０ｂは、中央管理センター１０に対して提供しているリソースの返却の要求を行う（Ｓ１１）。リソースの返却の要求には、例えば、返却対象のリソースのリソースＩＤの情報などが含まれる。返却対象のリソースは、例えば、ローカルリソース管理テーブル２３の“管理元”の値が中央管理センター１０を示す値（図２の例では“中央”）になっているものの中から任意の手法で選定する。

リソース返却要求を受けた中央管理センター１０は、中央リソース管理テーブル１１を参照して対象のリソースを利用しているコンテナ型ＤＣ２１を特定し、当該コンテナ型ＤＣ２１を運用管理している要求元ローカル管理センター２０ａに対してリソース返却の指示を行う（Ｓ１２）。リソース返却の指示には、例えば、返却対象のリソースのリソースＩＤの情報などが含まれる。

リソース返却の指示を受けた要求元ローカル管理センター２０ａは、対象のリソースの利用を停止し（Ｓ１３）、停止が完了すると、中央管理センター１０に対してリソース利用停止の報告を行う（Ｓ１４）。リソース利用停止の報告には、例えば、停止した返却対象のリソースのリソースＩＤの情報などが含まれる。

リソース利用停止の報告を受けた中央管理センター１０は、調達先ローカル管理センター２０ｂに対して対象のリソースの返却を報告する（Ｓ１５）。リソースの返却の報告には、例えば、返却対象のリソースのリソースＩＤの情報などが含まれる。このとき、中央管理センター１０は、自身が対象のリソースの運用管理を行っていた場合はこれを停止するようにしてもよい。

リソースの返却報告を受けた調達先ローカル管理センター２０ｂは、対象のリソースを回収して利用や運用管理を再開する（Ｓ１６）。このとき、ローカルリソース管理テーブル２３の“管理元”の値をローカル管理センター２０であることを示す値（図２の例では“ローカル”）に更新する。

なお、例えば、要求元ローカル管理センター２０ａの拠点において利用しているリソースが不要になった場合など、要求元ローカル管理センター２０ａからの要求に基づいてリソースを返却する場合は、ステップＳ１３から処理を開始し、ステップＳ１３において要求元ローカル管理センター２０ａが返却対象のリソースを任意の手法で選定し、当該リソースの利用を停止するようにすればよい。また、図４の例と同様に、各管理センターにおける上記の処理やメッセージの送受信は、これらの一部または全部を、例えば、各管理センターのオペレータや管理者等による端末の操作によって実行されるようにしてもよいし、システム的なイベント（メッセージの受信等）などをトリガとした自動処理により実行されるように構成することも可能である。

以上に説明したように、本実施の形態の分散データセンター１によれば、地理的に離れた拠点間で、中央管理センター１０を介して、コンテナ型ＤＣ２１が有するリソースを融通し合うことが可能である。

＜統合運用と自律運用の切り替え＞
また、本実施の形態の分散データセンター１では、複数の拠点のコンテナ型ＤＣ２１を統合的に運用管理する場合と、各拠点において自律的に運用管理する場合の２種類の運用管理手法を有する。通常は、上述したように、各拠点のローカル管理センター２０が、自身が運用管理するコンテナ型ＤＣ２１のリソースの空き状況（提供可能なリソース）を管理している。しかしながら、運用状況によっては、分散データセンター１における一部または全部の拠点のリソースを中央管理センター１０において一元的に統合管理する必要が生じる場合がある。

図６は、複数拠点のコンテナ型ＤＣ２１を統合管理する処理の流れの例について概要を示した図である。まず、中央管理センター１０において、統合管理とする対象の拠点を選定する（Ｓ２１）。ここでは、例えば、中央リソース管理テーブル１１を参照する等により、オペレータや管理者等の操作によって、統合管理とする対象の拠点（ローカル管理センター２０）を選定する。なお、どの拠点を統合管理の対象とすべきかは運用状況によって異なり得る。全ての拠点を統合管理の対象とすることも当然ながら可能である。

次に、中央管理センター１０は、統合管理対象の各拠点のローカル管理センター２０（図６の例では統合対象ローカル管理センター２０ｃ、ｄ）に対して、それぞれが運用管理するコンテナ型ＤＣ２１が保有する全てのリソースを要求する（Ｓ２２）。全リソースの要求を受けた各統合対象ローカル管理センター２０ｃ、ｄは、管理する各リソースの管理状況を中央管理センター１０に対して報告する（Ｓ２３）。この管理状況の報告には、例えば、各リソースのリソースＩＤや、リソース種別、容量、現在の管理元の情報などが含まれる。なお、ここでは、図４の例のステップＳ０４と異なり、拠点の全てのリソースを統合管理することから、リソースを“仮押さえ”する必要がないため、ローカルリソース管理テーブル２３の“管理元”の値は変更しないようにしてもよい。

各統合対象ローカル管理センター２０ｃ、ｄからリソースの管理状況の報告を受けた中央管理センター１０は、各統合対象ローカル管理センター２０ｃ、ｄに対して、提供を受ける（統合管理する）リソースを提示する（Ｓ２４）。ここでは、原則として対象の統合対象ローカル管理センター２０ｃ、ｄが運用管理するコンテナ型ＤＣ２１の全リソースが対象となる。なお、中央リソース管理テーブル１１上で既に中央管理センター１０が運用管理している状態となっているリソースについては、提示するリソースの対象から除外するようにしてもよい。提示するリソースの情報には、例えば、対象のリソースのリソースＩＤ（全てのリソースを対象とする場合はその旨の指定でもよい）などの情報が含まれる。

提供を受けるリソースの提示を受けた各統合対象ローカル管理センター２０ｃ、ｄは、提供するリソース（原則として全て）について、ローカルリソース管理テーブル２３の“管理元”の値を、中央管理センター１０を示す値（図２の例では“中央”）に更新するとともに、提供するリソースに係る情報を中央管理センター１０に報告する（Ｓ２５）。提供するリソースに係る情報には、例えば、対象のリソースＩＤやリソース種別、容量、さらにアクセスに係る情報として、アクセスＩＤやアクセス権限、アクセス先のアドレスやホスト名等の情報などが含まれる。

提供するリソースの情報の報告を受けた中央管理センター１０は、当該情報に基づいて、各統合対象ローカル管理センター２０ｃ、ｄが運用管理するコンテナ型ＤＣ２１が保有する対象のリソースにアクセスして運用管理を開始する（Ｓ２６）。

なお、統合的な運用管理から自律的な運用管理に戻す、すなわち中央管理センター１０から各統合対象ローカル管理センター２０ｃ、ｄに対してリソースを返却する処理については、例えば、中央管理センター１０が対象のリソース（もしくは全リソース）の運用管理を停止した後、図５の例のステップＳ１５、Ｓ１６と同様の処理を実行すればよい。また、図４の例と同様に、各管理センターにおける上記の処理やメッセージの送受信は、これらの一部または全部を、例えば、各管理センターのオペレータや管理者等による端末の操作によって実行されるようにしてもよいし、システム的なイベント（メッセージの受信等）などをトリガとした自動処理により実行されるように構成することも可能である。

また、図６の例では、ステップＳ２２やＳ２４において、中央管理センター１０から各統合対象ローカル管理センター２０ｃ、ｄに対して同報的に全リソースの要求を行って同時並行的に処理を行っているが、各統合対象ローカル管理センター２０ｃ、ｄに対してステップＳ２２〜Ｓ２６の一連の処理を連続的に行って逐次的に処理を行ってもよい。

以上に説明したように、本実施の形態の分散データセンター１によれば、複数の拠点のコンテナ型ＤＣ２１を統合的に運用管理する場合と、各拠点において自律的に運用管理する場合の２種類の運用管理手法を適宜切り替えて利用することができる。

＜リソースの予約および自動追加＞
また、本実施の形態の分散データセンター１では、ローカル管理センター２０のローカルリソース管理テーブル２３を利用して、予めリソースを予約しておくことができる。このため、例えば、各拠点において、コンテナ型ＤＣ２１にビルディングブロック方式により他のコンテナ型ＤＣ２１を増設して拡張する際に、運用する構成を自動追加することが可能である。

通常、コンテナ型ＤＣ２１は、設置から稼働までを短期間で容易に行えるようにするため、保有するサーバ機器やネットワーク機器、ストレージ等の構成について標準構成を予め定義しておき、原則として当該標準構成によって各コンテナ型ＤＣ２１を設置するということが行われる。このため、新規に設置する未使用のコンテナ型ＤＣ２１が保有する空きリソース量は原則として一定で既知である。従って、新規に設置するコンテナ型ＤＣ２１については、ローカルリソース管理テーブル２３を予め用意しておくことができる。

これにより、例えば、新規に拠点を構築する際に、新規に設置するコンテナ型ＤＣ２１についてのローカルリソース管理テーブル２３を予め作成しておき、ローカル管理センター２０に反映させておくことで、未使用で初期状態のコンテナ型ＤＣ２１の運用管理を迅速かつ容易に行うことが可能となる。また、稼働中の拠点に対してコンテナ型ＤＣ２１を増設する際に、自動的に当該コンテナ型ＤＣ２１の各リソースをローカルリソース管理テーブル２３に追加登録することで、増設するコンテナ型ＤＣ２１の運用管理を迅速かつ容易に行うことが可能となる。

また、ローカルリソース管理テーブル２３を予め用意しておくことが可能であることから、ローカルリソース管理テーブル２３に登録されている設置予定のリソースの“管理元”の値を、予め中央管理センター１０を示す値（図２の例では“中央”）に更新しておくことで、新規に設置予定のコンテナ型ＤＣ２１のリソースの中で、中央管理センター１０が一元的に運用管理もしくは利用する（他の拠点に融通するものも含む）予定であるリソース量を予約しておくことができ、迅速かつ柔軟なデータセンターの構築や運用が可能となる。

以上に説明したように、本発明の一実施の形態である分散データセンター１によれば、分散配置された複数のコンテナ型ＤＣ２１などの可搬型データセンターに対して、これらを遠隔地から一元的に運用管理する中央管理センター１０を有する分散データセンターを実現することができる。本実施の形態の分散データセンター１では、各管理センターがリソース管理テーブルによってコンテナ型ＤＣ２１が有するリソースを管理しており、これを利用して、例えば、地理的に離れた拠点間でコンテナ型ＤＣ２１が有するリソースを融通し合うことが可能である。また、複数の拠点のコンテナ型ＤＣ２１を統合的に運用管理する場合と、各拠点において自律的に運用管理する場合の２種類の運用管理手法を適宜切り替えて利用することが可能である。

また、ローカルリソース管理テーブル２３を利用して、予めコンテナ型ＤＣ２１のリソースを予約しておくことができる。従って、コンテナ型ＤＣ２１の新規設置や増設の際に、運用する構成を自動追加することが可能となり、また中央管理センター１０が運用管理するリソース量を予約しておくことも可能となる。これらにより、簡易的に迅速に構築可能であるというコンテナ型ＤＣ２１の特徴を活かしつつ、より高い拡張性と柔軟性を有するデータセンターの構築や運用が可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、遠隔地に分散して配置された複数の可搬型データセンターからなる分散データセンターに利用可能である。

１…分散データセンター、
１０…中央管理センター、１１…中央リソース管理テーブル、
２０…ローカル管理センター、２０ａ…要求元ローカル管理センター、２０ｂ…調達先ローカル管理センター、２０ｃ、ｄ…統合対象ローカル管理センター、２１…コンテナ型データセンター（ＤＣ）、２２…ローカルネットワーク、２３…ローカルリソース管理テーブル、
３０…ネットワーク。

Claims (6)

1. 地理的に離れた複数の拠点に、１つ以上の可搬型データセンターがそれぞれ分散配置されており、各拠点の前記各可搬型データセンターが通信ネットワークを介して相互に接続されている構成を有する分散データセンターであって、
   各拠点の前記可搬型データセンターの運用管理を遠隔から行うことが可能な中央管理センターを有し、
   また、各拠点には、それぞれの拠点に設置された前記可搬型データセンターが保有する各ＩＴリソースの状況を保持するリソース管理テーブルを有して前記可搬型データセンターの運用管理を行うローカル管理センターを有し、
   前記中央管理センターを介して、第１の拠点の第１のローカル管理センターが運用管理する前記可搬型データセンターが保有するＩＴリソースを、第２の拠点の第２のローカル管理センターから利用させる際に、
   前記第２のローカル管理センターからの要求に基づいて、前記中央管理センターが、前記第１のローカル管理センターに対して必要なＩＴリソースを提示し、
   前記必要なＩＴリソースの提示を受けた前記第１のローカル管理センターが、前記第１のローカル管理センターの前記リソース管理テーブルに基づいて、提供可能なＩＴリソースを前記中央管理センターに対して報告し、
   前記提供可能なＩＴリソースの報告を受けた前記中央管理センターが、提供を受けるＩＴリソースを前記第１のローカル管理センターに対して提示し、
   前記提供を受けるＩＴリソースの提示を受けた前記第１のローカル管理センターが、前記第１のローカル管理センターの前記リソース管理テーブルにおいて、提供するＩＴリソースが前記中央管理センターによって管理される旨に更新するとともに、前記提供するＩＴリソースへのアクセスに係る情報を含む、前記提供するＩＴリソースに係る情報を前記中央管理センターに報告し、
   前記提供するＩＴリソースに係る情報の報告を受けた前記中央管理センターが、前記提供するＩＴリソースに係る情報を、前記第２のローカル管理センターに提供し、
   前記提供するＩＴリソースに係る情報を受けた前記第２のローカル管理センターが、前記提供するＩＴリソースに係る情報に基づいて、前記第１のローカル管理センターが運用管理する前記可搬型データセンターが保有する、前記提供を受けるＩＴリソースにアクセスすることを特徴とする分散データセンター。
2. 請求項１に記載の分散データセンターにおいて、
   前記中央管理センターから、前記必要なＩＴリソースの提示を受けた前記第１のローカル管理センターが、前記第１のローカル管理センターの前記リソース管理テーブルに基づいて、前記提供可能なＩＴリソースを前記中央管理センターに対して報告する際に、
   前記第１のローカル管理センターは、前記第１のローカル管理センターの前記リソース管理テーブルにおいて、前記提供可能なＩＴリソースの管理状態が空き状態である旨に更新することを特徴とする分散データセンター。
3. 請求項１または２に記載の分散データセンターにおいて、
   各拠点の前記ローカル管理センターが、それぞれの拠点に設置された前記可搬型データセンターの運用管理を自律的に行う場合と、前記中央管理センターが、一部または全部の拠点に設置された全ての前記可搬型データセンターの運用管理を統合的に行う場合とを切り替えることが可能であることを特徴とする分散データセンター。
4. 請求項３に記載の分散データセンターにおいて、
   前記ローカル管理センターが自律的に運用管理を行っている前記可搬型データセンターを、前記中央管理センターが統合的に運用管理するよう切り替える際に、
   前記中央管理センターが、前記ローカル管理センターに対して全てのＩＴリソースを要求し、
   前記全てのＩＴリソースの要求を受けた前記ローカル管理センターが、前記ローカル管理センターの前記リソース管理テーブルに基づいて、各ＩＴリソースの管理状況を前記中央管理センターに対して報告し、
   前記各ＩＴリソースの管理状況の報告を受けた前記中央管理センターが、提供を受ける全てのＩＴリソースを前記ローカル管理センターに対して提示し、
   前記提供を受ける全てのＩＴリソースの提示を受けた前記ローカル管理センターが、前記ローカル管理センターの前記リソース管理テーブルにおいて、提供する全てのＩＴリソースが前記中央管理センターによって管理される旨に更新するとともに、前記提供する全てのＩＴリソースへのアクセスに係る情報を含む、前記提供する全てのＩＴリソースに係る情報を前記中央管理センターに報告し、
   前記提供する全てのＩＴリソースに係る情報の報告を受けた前記中央管理センターが、前記提供する全てのＩＴリソースに係る情報に基づいて、前記提供を受ける全てのＩＴリソースの運用管理を行うことを特徴とする分散データセンター。
5. 請求項１〜４のいずれか１項に記載の分散データセンターにおいて、
   各拠点に設置される前記可搬型データセンターは、予め定義された標準的な構成を有し、
   各拠点において前記可搬型データセンターを増設する際に、当該拠点の前記ローカル管理センターにおける前記リソース管理テーブルに、前記標準的な構成に基づくＩＴリソースを予め登録しておくことを特徴とする分散データセンター。
6. 請求項５に記載の分散データセンターにおいて、
   前記リソース管理テーブルに予め登録しておく前記標準的な構成に基づくＩＴリソースのうち、前記中央管理センターによって運用管理を行う予定のＩＴリソースについては、予め、前記中央管理センターによって管理される旨に更新しておくことを特徴とする分散データセンター。

Images