JP5732893B2 - リソース管理装置 - Google Patents

Description

本発明は、リソース管理装置に関する。

近年、大規模な情報処理システムとして、顧客のサーバ装置等を管理する大規模なデータセンタ（リソース共用管理センタシステム）等においては、データセンタ側のサーバ装置を含む様々な種類のデータセンタ側のリソースを一括集中管理させ、顧客側のサーバ装置等で構成される複数のシステムに対しては、これらのデータセンタ側のリソースを共有リソースとして共用させるリソース共有型情報処理システムが普及しつつある。
ここで、データセンタ側のリソースとは、データセンタ側のサーバ装置を構成するＣＰＵ機器、メモリ機器、ディスク機器、及びネットワーク機器（インタフェースを含む）等のことであるが、これらの機器群で構成されるデータセンタ側のサーバ機器自体も該リソースの範疇に含まれるものとする。

従って、顧客側のサーバ装置等を管理する大規模なデータセンタ等では、これら複数のリソースを有しており、これにより、顧客側のサーバ装置等を含めて構成される複数のシステムを運行していることになる。
なお、これらの複数のシステムを構成するデータセンタ側のサーバ群の中には、可用性の技術を応用してシステムの継続使用可能なクラスタ構成（可用性の用語としてホットスタンバイ、コールドスタンバイ）を備えたものも開発されている。この場合、該クラスタを構成するサーバ装置の一部のリソースが故障すると、該故障したリソースを構成するサーバ装置をシステムから切り離して修理することが必要な場合も生じるので、この解決も本発明に際しての課題の１つであった。

また、このように、データセンタ側では、システムから切り離されたサーバ装置等を手動で管理する必要も生じるので、この解決も本発明に際しての課題の１つであった。
また、データセンタ側で稼働中のサーバ装置等に代わるリソースを、代替サーバ装置等としてデータセンタ側で予めプーリングしておき、障害発生時には該稼働中のサーバ装置等をシステムから切り離すと共に、この代替サーバ装置等をリアルタイムで補充して稼働させる必要が生じる。従って、このような技術を提供することも本発明に際しての課題の１つであった。

さらに、データセンタ管理者から、新しいサーバ装置等の構成要求が出された際に備えて、該新しいサーバ装置等の構成要件に対応できるリソースを一括管理の下で予めプーリングしておき、新しいサーバ装置等の構成要求が出された際には、該構成要件にあったサーバ装置等を結線まで含めて自動で実装することも、本発明に際しての課題の１つであった。

この分野の公知技術として、例えば、特許文献１には、高可用性クラスタ・ネットワーク構成中の資源グループを定義する「自動」機構を提供する技術が開示されている。具体的には、管理者は、所与のアプリケーションをその時に実行しているコンピュータで故障が発生した場合に、単に、そのアプリケーションと並置しなければならない資源のセットを識別するだけで良い。この場合、資源グループが、１組のコロケーション「制約」または規則を使用して自動的に生成する。第１のコロケーション制約は、所与のアプリケーションについて任意のユーザ定義コロケーションを実施することが好ましいとしており、第２の制約は、同一の物理ディスク上に常駐するディスク区画資源を並置するものとしている。

また、例えば、特許文献２には、管理者が、ノード毎のリソース使用状況を把握して管理することを可能とし、クラスタ構成の記憶システムの管理コストの削減を図る技術を開示している。具体的には、管理サーバは、各ノードのデータ物理位置情報を統合して有し、クラスタ構成記憶システムの構成及び各ノードの構成と関連付けて提示する手段を備える。ノードは、処理に際し使用するリソースの量や負荷を取得する手段を備え、管理サーバは、各リソースの使用状況を各サーバから収集して集計する手段と、リソース使用状況と前記データ情報と前記構成情報とを関連付けて、階層を設けて提示する手段を備える。さらに、論理ボリュームをノード間においてホストコンピュータには透過に移動する手段を備える。管理サーバは、情報表示により移動元データと移動先物理位置との選択を支援する手段と、前記移動の指示を受領し、前記クラスタ構成記憶システムに移動を指示する手段を備えるものとしている。

また、例えば、特許文献３には、ネットワークにより接続されたサーバ、ストレージ及びネットワーク装置から構成される自律制御システムで、制御要件（ポリシー）に応じて柔軟な自律制御を行う技術を開示している。具体的には、ポリシーＤＢなどに各種ポリシーを記憶し、システムを構成する各ノードが他のノードと連携すると共に、ポリシーに基づいて自律制御を行う。また、予備のリソースを共有プール、ベアメタルプール及びスタンバイプールを用いて管理し、障害時や性能劣化時にワークグループシステムリソースマネジャがスタンバイプール、ベアメタルプールの順に予備のリソースを選択するものとしている。

また、例えば、特許文献４には、既に他の情報処理システムが稼動中である場合にも影響を与えないリソースを求め、業務サービスの継続的な実行と共有リソースを有効活用できる手段を開示している。具体的には、業務アプリケーション毎に、各業務アプリケーションを実行するコンピュータシステムを識別する情報、及び各コンピュータシステムを構成するリソースの利用率を含むリソース利用率情報を格納した記憶部と、業務アプリケーションが、新たにコンピュータシステムのリソースの使用を要求する場合に、リソース利用率情報を用いて、変更後の当該コンピュータシステムを構成する各リソースの利用率を集計して出力する影響範囲調査部と、を備えるリソース管理システムである。

さらに、例えば、特許文献５には、ソフトウェア・リソースを動的に提供する技術を開示している。具体的には、オペレーティング・システム、アプリケーション・プログラム、及びソフトウェア・ドライバといったソフトウェア・リソースを動的に提供する技術である。

特開２００１−１０９６３９号公報 特開２００３−２９６０３９号公報 特開２００５−３４６２０４号公報 特開２００８−０３３８５２号公報 特表２００８−５０２９６７号公報

ところで、上記背景技術で述べた従来の共用リソース管理システムにおいては、前述のとおり、顧客のサーバ等を含めて構築される複数のシステムを管理する大規模なデータセンタ等に前記の複数のリソースを備えて管理する構成をとっている。また、各システムを構成するデータセンタ側のサーバ群の中には、可用性の技術を応用したクラスタ構成を有するものも存在する。
また、前述のとおり、このクラスタ構成を成すサーバの一部のリソースが故障した際には、故障したリソースで構成されるサーバをシステムから切り離して手動で管理し、場合によっては修理する必要も有るが、従来のリソース共有型情報処理システムステムでは、このような管理や修理の実施に対応できていないという問題点が有る。

また、データセンタ側では、稼働中のサーバ装置等に代わるリソースを、代替サーバ装置等として予めプーリングしておき、障害発生時等には該稼働中のサーバ装置等をシステムから切り離すと共に、この代替サーバ装置等をリアルタイムで補充して稼働させる必要が生じる。しかしながら、従来のリソース共有型情報処理システムでは、このような代替サーバ装置を事前にプーリングしておいて、該装置を障害発生時等に補充することまでは考慮されていないという問題点が有る。

さらに、従来のリソース共有型情報処理システムステムでは、一括管理の下で予めプーリングしていたリソースの内から、データセンタの管理者が具体的に要求する新しいシステム（サーバ装置等）の構成要件に合致したリソースを摘出すると共に、該リソースを障害発生時等に補充することまでは考慮されていないという問題点が有る。
よって、本発明に際しては、システムを構成するリソースに障害が発生した場合にも、サービスの提供を中止しなくても済むシステム（即ち、より可用性が重視されたシステム）を構築することが重点的な課題であった。

ちなみに、近年、仮想環境等を実現する技術は、物理機器の保守費や運用費の削減する必要や、技術的な観点により、急速に進展しており、このため、機器等の物理的なリソースを有効利用することや、オペレータの作業を簡易化すること等により、システム管理費用の削減や運用費の削減を図ることが重要課題となってきている。
また、仮想技術に対する技術の複雑化を緩和するための可視化技術を取り入れることにより、システム環境のリソース全体の稼働率を高めることや、センタ運用管理者の作業軽減を提供することも重要課題となってきている。

なお、特許文献１に記載の技術は、所与のアプリケーションを実行するコンピュータに故障が発生した場合に、該アプリケーションと並置すべきリソースのセットを管理者が識別するだけで、後は、資源グループが、１組のコロケーション「制約」または規則を使用して自動的に生成するものであり、本発明のように、障害情報まで収集して、障害が発生したリソースの機能を他のリソースに割り振って代替させたり、障害が発生したリソースであっても、該リソースを構成する機器の内、他のシステムの構成が可能な機器については、できるだけ該機器を活用しようとするものではない。

また、特許文献２に記載の技術は、クラスタ構成の記憶システムの管理コストの削減を図ることに限定されており、よって、リソースとしては記憶システムだけが意識されており、本発明のように、サーバや、該サーバを構成するＣＰＵ装置、メモリ装置、ディスク装置、ネットワーク機器（インターフェースを含む）までをリソースとして見なして扱うものではない。

また、特許文献３に記載の技術は、Front 層、Web 層、AP層、DB層といった層により、サービスのポリシーを定義し、各層での障害時の層毎のポリシーによってサーバ群の増設や切換えを実施するものである。しかし、本発明では、 Web層、AP層等の上位のサーバがそこで何を動かしているかを意識しない。即ち、本発明では、層を意識していないため、層のサービスといったものではなく、ハードウェアレベルのリソース（例えば、ＣＰＵ装置、メモリ装置、ディスク装置、ネットワーク機器（インターフェースを含む））をシステムの構成要素としている。

また、特許文献４に記載の技術は、業務アプリケーションを業務構成オブジェクトとする定義を行っているが、本発明では、業務構成オブジェクトとリソースのプーリングとは結び付けていない。さらに、本発明では、障害発生時の迅速な代替リソースの提供を特徴としているが、構成要件の障害対策・復旧機能は、各サブシステムに任せ、管理サーバは各サブシステムの構成及びプーリングされたリソースの管理とを分けて管理している。

さらに、特許文献５に記載の技術は、主としてソフトウェア面での対策であり、特に、オペレーティング・システム、アプリケーション・プログラム、及びソフトウェア・ドライバの動的な提供をするものである。従って、本発明の課題であったハードリソースを柔軟に動的に構成変更して提供するという課題を解決するものではない。

即ち、本発明は、他のシステム群とでリソースを共有し、障害時等の場合に自動的にリソースを変更する手段において、集中管理センタ（管理サーバ）が障害の起きたリソースの状態情報を収集し、顧客（センタ管理者）が要求する他のシステムの業務カタログ（構成カタログ、要件）に対し、予め統合的に管理されているリソースの蓄積（プーリング）情報と照合し、代替が可能なリソースが有る場合は、該リソースを組み込んで前記顧客が要求する他のシステムを構築することを骨子としている。

本発明の目的は、上述した課題を解決するリソース管理装置を提供することにある。

上記課題を解決するために、本発明の第１の形態によると、リソース管理装置であって、複数のリソースの状態情報及び障害情報を収集する収集部と、収集部が収集した状態情報及び障害情報を格納する第１格納部と、要求されるシステムのリソースの構成要件が記載されたカタログ情報を格納する第２格納部と、リソースの組み替え処理及び実装処理を行う処理部とを備え、複数のリソースのうちのクラスタ構成にある現用系の第１リソースに障害が発生したときには、当該第１リソースにて実現されていた第１機能を、複数のリソースのうちのクラスタ構成にない第２リソースに移管してもよいことが、第２格納部に格納されているカタログ情報に記載されている場合、処理部は、第１格納部に格納されている情報を参照して、第２リソースが動作可能であるか否かを検証し、第２リソースが動作可能であれば、第１機能を第２リソースに移管すべく、各リソースの組み替え処理及び実装処理を行う。

以上説明したように、本発明によれば、リソースを予め統合的に管理・蓄積（プーリング）しておき、ネットワークを介して構成される複数のシステムに共有されるリソースの一部に障害が発生した場合に、システム管理者によって要求される新しいサーバ要件と、該管理・蓄積情報とを照合し、代替が可能なリソースが有る場合は、該リソースを使用してシステムを再構成すると共に、該システムに対応するサーバ装置等のハードウェアを、配線まで含めて実装することができるので、共用リソースを配備する情報処理センタの可用性を向上させることができる。

本発明の実施形態に係る共用リソース管理システムの全体構成を示す構成図である。 本発明の実施形態の共用リソース管理システムで、サーバ３０００のリソースの一部であるネットワークＩ／Ｆ３１００に障害が発生したことを示す説明図である。 サーバ３０００のリソースの一部であるネットワークＩ／Ｆ３１００に障害が発生した場合の動作例を示す説明図である。 サーバ３０００のリソースの一部であるネットワークＩ／Ｆ３１００に障害が発生した場合の、他の動作例を示す説明図である。 本発明の実施形態に係る共用リソース管理システムの動作順序の１例を示すシーケンス図である。

本発明の共用リソース管理システムは、顧客側のサーバ装置等を管理する大規模なデータセンタ等において、前記顧客側のサーバ装置等を含めて構成される複数のシステムに対して、該システムを構成するデータセンタ側配備のリソースの状態を管理して共用できるようにすることを特徴とする。
ここで、データセンタ側配備のリソースとは、システムを構築するために充当されるハードウェア資源のことであり、例えば、データセンタ側のサーバ装置を構成するＣＰＵ機器、メモリ機器、ディスク機器、及びネットワーク機器（ネットワークとのインタフェース機能を担う）のことである。但し、本発明では、前記の機器群で構成されるサーバ装置自体も前記リソースの範疇に入るものと見なしている。

また、本発明は、現在使用されていないリソースも含めてプーリングしておき、一括管理することを特徴とする。
ここで、プーリングとは、リソースの一定数を保持することを意味するものとする。
さらに、本発明は、前記プーリングされたリソースを使用して、データセンタの管理者が要求する新しいサーバ装置等の構成要件に合致したシステムを構成し、該システムの構成を自動で構築する（結線等を含めてハードウェアとして実装する）機能を具備することを特徴とする。

本発明では、様々なリソースを使用して、所与のシステム構成を有するシステムのハードウェアを構築するが、該リソースの中には運用上の都合や、構成上の都合、または障害発生に起因して、使用されずに置き去りにされるリソースも存在していて良い。
本発明の共用リソース管理システムは、このようなリソースも含めて、全てのリソースの状態を管理し、プーリングされているリソースの内から、センタ管理者によって指定された新しいサーバ要件に適合するリソースを摘出し、該リソースが有効（動作可能か否かの検証も含む）と判断できれば、該リソースを使用するシステムを構成すると共に、該システムに対応するサーバ装置等のハードウェアを構築（即ち、結線まで含めて実装）することを特徴とする。

以下、本発明のリソース共用管理センタシステム及びリソース管理サーバ装置の実施形態について、図面を参照して詳細に説明する。
図１は、本発明の実施形態に係る共用リソース管理システムの全体構成を示す構成図である。
同図において、本実施形態の共用リソース管理システムは、複数のリソースを管理するサーバ装置であるリソース管理サーバ１００（本発明の実施形態に係るリソース管理サーバ装置）と、リソースとして提供されてプログラムを実行するサーバ装置であるサーバ１０００〜５０００と、を備える。
なお、サーバ５０００は、現在、実際には稼動していないサーバ装置（計画段階のサーバ装置）であるものとする。

リソース管理サーバ１００は、データを格納するデータベース１１０と、後述するリソース（ハードウェア資源）の状態情報及び障害情報を収集する機能を有する機能モジュール１２０と、リソースの組み替え及び実装を担う機能モジュール１３０と、センタ管理者が要求するシステムの構成要件をサーバ装置等の具体的なリソースを含めて記載した構成カタログ１４０と、を備える。

サーバ（１０００〜５０００）は、リソースの状態情報及び障害情報をリソース管理サーバ１００に送出する機能を有する機能モジュール１５０を共通に備えるが、この他に、ネットワークとのインタフェース機能を担うネットワークＩ／Ｆ（１１００〜５１００）及びネットワークＩ／Ｆ（１２００，３１００，３２００）と、ディスク記憶装置（符号は省略）等のリソースを備える。

なお、ここでは、リソース管理サーバ１００にはネットワークＩ／Ｆを配備していないが、本発明では、一般に、リソース管理サーバ１００にも、ネットワークＩ／Ｆを備えることが可能である。
一般に、サーバ（１０００〜５０００）は、ネットワークＩ／Ｆ（１１００〜５１００）や、ネットワークＩ／Ｆ（１２００〜３２００）が備える通信プロトコルにより、ネットワーク（インターネット網等）を介して、ユーザの情報処理装置と接続されている。
ここで、上記のリソースとは、システムを構築するのに必要なハードウェア資源一般を示すものであり、例えば、ＣＰＵ装置、メモリ装置、内蔵ディスク装置、及びネットワークＩ／Ｆなどが範疇に含まれるものとする。

以下、図１を参照して、本実施形態の共用リソース管理システムの機能について説明する。
本発明に係る共用リソース管理システム（図１）は、顧客のサーバ等を管理する大規模なデータセンタ等に存在する複数のリソースを、１つのサーバで管理し、複数のシステム間で共用できるようにする。
即ち、クラスタ構成を有するサーバ装置のリソースの内、障害になった一部のサーバのリソースの状態情報、及び単一のサーバ装置で発生したリソースの障害状況を示す障害情報も、リアルタイムにリソースを管理するリソース管理サーバ１００に通知する。
また、センタ管理者が要求するシステムの新しい構成要件に対し、統合的に管理されているリソースのプーリング情報を照合して該新しいシステムを構成すると共に、該システムを構成するハードウェアとしての実装を行う。

図１において、リソース管理サーバ１００は、サーバ（１０００〜５０００）を含む前述の各リソースを管理し、該管理しているリソースを用いて構築されているシステムの構成を変更する機能を有するサーバ装置である。
このソースを管理するリソース管理サーバ１００は、前述のとおり、データを格納するデータベース１１０と、リソースの状態情報及び障害情報を収集する機能を有する機能モジュール１２０と、リソースの組み替え及び実装を担う機能モジュール１３０と、から構成される。

ここでは、データベース１１０が格納するデータを、前記リソースの状態情報及び障害情報と、センタ管理者が要求するシステムの構成要件をサーバ装置等のリソースでもって記載した構成カタログ１４０との２種類としている。しかし、本発明では、一般に、前記リソースの状態情報及び障害情報と、構成カタログ１４０とは、それぞれ異なるデータベースに格納することも可能である。
なお、構成カタログ１４０とは、各システムが必要とするリソース（即ち、システムの構築に必要なリソースの名称及び結線）が掲載されている構成カタログのことであり、センタ管理者は、適当な入力手段により、その内容を更新することができる。

機能モジュール１５０は、リソース管理サーバ１００の管理下の各サーバを構成している各リソースの状態情報及び障害情報を機能モジュール１２０に通知する。
機能モジュール１５０は、この状態情報及び障害情報を、リソース管理サーバ１００の管理下の各サーバ（即ち、サーバ（１０００〜５０００））を構成している各リソースから得る。
機能モジュール１２０は、機能モジュール１５０から通知された状態情報及び障害情報を収集し、データベース１１０に保存する。
機能モジュール１３０は、前記状態情報及び障害情報を参照しながら、リソース管理サーバ１００の管理下の各サーバ装置、及び該各サーバ装置を構成しているリソースを組み替えて、構成カタログ１４０に要求されたシステムを構築するための計算を行うと共に、結線も含めて該システムを構成するハードウェアの実装を行う。

より具体的には、該システムを構成するサーバ装置、及び該サーバ装置を構成するために必要なリソース（例えば、ＣＰＵ装置、メモリ装置、内蔵ディスク装置、及びネットワークＩ／Ｆ）を組み立てると共に、適切なドメインにネットワークケーブルの結線を行うものである。
また、内蔵ディスク装置等のディスク機器に対しては、必要とする機器類（例えば、コントローラ、エンクロージャ、キャッシュメモリ、ディスク等）と、管理ケーブル（ネットワーク）及びコントローラケーブル(Fibre Channel)との間の結線を行う。
さらに、ネットワーク機器に対しては、IP設定、ポート設定、及びVLAN設定を行うと共に、適切なドメインにネットワークケーブルの結線（接続）を行う。

以下、本実施形態の共用リソース管理システムの動作をケース毎に説明する。
図２は、本発明の実施形態の共用リソース管理システムで、サーバ３０００のリソースの一部であるネットワークＩ／Ｆ３１００に障害が発生したことを示す説明図である。
図２において、サーバ１０００、サーバ２０００、及びサーバ３０００は、クラスタ構成であり、ネットワークＩ／Ｆ３１００に障害が発生したことを示している。
この場合、サーバ３０００上でのプログラムが動作不可能であるとクラスタが判断し、プログラムの実行をサーバ１０００へ切換えることになる。

図３は、サーバ３０００のリソースの一部であるネットワークＩ／Ｆ３１００に障害が発生した場合の動作例を示す説明図である。
ネットワークＩ／Ｆ３１００に障害が発生した（図２）ので、サーバ１０００、サーバ２０００、及びサーバ３０００のクラスタ構成から、サーバ３０００が外され、単体のサーバ３０００として起動する。
この状態と、ネットワークＩ／Ｆ３１００の障害情報とを、機能モジュール１５０が収集し、状態・障害情報を収集する機能モジュール１２０に該情報を送出し、機能モジュール１２０は、データベース１１０に該情報を格納する。

他方、一般ユーザの要求に基づいてセンタ管理者が、新しいシステムを構成するために必要な構成要件（一般にはサーバ装置を含む）を作成し、データベース１１０の構成カタログ１４０に新規登録する。
機能モジュール１３０は、データベース１１０に格納されている構成カタログ１４０が更新されたことにより、新しいシステムを構成するために、自己が管理しているリソースを再計算する。
より具体的には、データベース１１０が格納する状態・障害情報を参照しながら、構成カタログ１４０に記載された新しいシステムを構成する複数のリソース（サーバ装置を含む）の各々について、現在、障害を持たずに動作可能であるか否かを再検証する。

図３に示すケースでは、前記新しいシステムの構成要求を満たすリソースが、構成カタログ１４０の内で、サーバ１０００として存在している。
よって、機能モジュール１３０は、サーバ１０００でもって、前記新しいシステムを構成し、結線まで含めたハードウェアの実装を行う。

図４は、サーバ３０００のリソースの一部であるネットワークＩ／Ｆ３１００に障害が発生した場合の、他の動作例を示す説明図である。このケースでも、図３のケースと同様に、ネットワークＩ／Ｆ３１００に障害が発生しているケースであるが、機能モジュール１３０は、ネットワークＩ／Ｆ３２００を介して実現されていたシステム機能については、サーバ１０００に移管せずに、カタログ構成要件に合致したサーバ５０００に移すものである。これにより、システム機能が分散できるので、負荷の集中が緩和される効果が得られる。

この場合、機能モジュール１３０は、サーバ３０００が担っていたシステム機能の内、ネットワークＩ／Ｆ３１００を介して実現されていたシステム機能のみをサーバ１０００に担わせるように結線まで含めたハードウェアの実装を行うと共に、ネットワークＩ／Ｆ３２００を介して実現されていたシステム機能については、新たにサーバ５０００を充当して該機能を担わせるシステムを構成し、同じく結線まで含めたハードウェアの実装を行う。この新しく構築されたサーバ５０００のリソースの状況情報についても、機能モジュール１５０から機能モジュール１２０に通知され、機能モジュール１２０は、該情報をリソースデータベース１１０に登録する。

図５は、本発明の実施形態に係る共用リソース管理システムの動作順序の１例を示すシーケンス図である。
同図において、サーバ１０００、サーバ２０００、及びサーバ３０００は、クラスタ構成を成すサーバ装置群であるものとする。但し、サーバ１０００は待機系のサーバ装置であり、サーバ２０００及びサーバ３０００は、現用系のサーバ装置とする。
また、サーバ５０００は、シングルサーバ装置であるものとする。

機能モジュール１２０は、リソース管理サーバ１００の制御下において、前記サーバ装置群を構成する各サーバ、及び該サーバを構成しているリソースから、機能モジュール１５０を介して通知される状態情報及び障害情報を収集し、データベース１１０に該情報を保存する。
ここでは、サーバ３０００のリソースの一部であるネットワークＩ／Ｆ３１００に障害が発生した場合を説明する。
サーバ１０００、サーバ２０００、及びサーバ３０００はクラスタ構成を成すサーバ装置群であるので、ネットワークＩ／Ｆ３１００が障害になったことで、サーバ３０００上でのプログラムが実行不可能になったとクラスタが判断し、サーバ１０００へのプログラムの実行の切換えを行うことになる。

まず、タイミングＴ１で、ネットワークＩ／Ｆ３１００に障害が発生したので、サーバ１０００、サーバ２０００、及びサーバ３０００のクラスタ構成から、サーバ３０００が外され、単体のサーバ装置であるサーバ３０００として起動する。この状態を示す情報と、ネットワークＩ／Ｆ３１００の障害情報とを、機能モジュール１５０が収集する。
タイミングＴ２で、機能モジュール１５０は、機能モジュール１２０に対して該状態・障害情報を送出する。
タイミングＴ３で、機能モジュール１２０は、該状態・障害情報をデータベース１１０に格納する。

その後、タイミングＴ４で、センタ管理者が、一般ユーザのシステム要求を継続するには新しいリソース（一般にはサーバ装置を含む）が必要となるため、該構成を示す新しい構成カタログをデータベース１１０に登録する（即ち構成カタログ１４０を更新する）。
タイミングＴ５では、データベース１１０の（構成カタログ１４０）の内容が更新されたので、機能モジュール１３０（リソース配備を計算する機能モジュール）が、データベース１１０の障害情報等を参照しながら、構成カタログ１４０に示されているリソースの内、動作可能で構成可能なリソースが有るか否かを検証する。

ここでは、構成カタログ１４０に掲載されたリソースの内、要求された新しいシステムを構成するためには、ネットワークＩ／Ｆ３１００が使用不可能であるが、ネットワークＩ／Ｆ３２００は使用可能であり、かつネットワークＩ／Ｆ３２００を介して実現されていたシステム機能に対応するシステム構成は、障害発生前に、サーバ３０００を含む構成においてプログラムの実行を可能にしていた構成カタログの条件とも一致するので、該カタログ構成の要件に合ったサーバ５０００を実装可能なリソースと判断する。
この判断は、構成カタログに記載のリソースと、サーバ装置を含めて要求される新しいリソースの構成要件（ＣＰＵ装置、メモリ装置、内蔵ディスク装置、及びネットワークＩ／Ｆ）を照合することで行われる。

ＣＰＵ装置の場合、上記の実装可能か否かの判断要素となるのは、動作周波数と、コア数（リソース要求を満たすか否か）である。
また、メモリ装置の場合は、上記の実装可能か否かを判断する判断基準は、メモリ容量がリソース要件を満たすか否かである。
また、内蔵ディスク装置の場合は、上記の実装可能か否かを判断する判断要素は、ディスク容量と、ＲＡＩＤ構成（リソース要件を満たすか否か）である。

さらに、ネットワークＩ／Ｆの場合は、上記の実装可能か否かを判断する判断要素は、転送レートと、ネットワークＩ／Ｆの数（リソース要件を満たすか否か）である。
なお、ネットワークケーブルの結線は手作業では行う必要がない。最初からネットワークＩ／Ｆに全て差し込まれており、データリンク層以上の接続で、 Switch のポートVLANと, タグ VLAN とを使用して行う。適切なドメインに接続を行えるか否かの判断は、リソース要件を満たすか否かによるものとする。

タイミングＴ６で、機能モジュール１３０は、サーバ５０００を実装可能と判断し、構成カタログ１４０の新たな構成情報を基にして、前述の新たなリソースを構成し、サーバ５０００を実装する。
ここで、「実装する」とは、実際にサーバに必要なＣＰＵ装置、メモリ装置、内蔵ディスク装置、ネットワークＩ／Ｆ等のリソースを物理的に動かすことなく、要求された新しいシステムに対応するハードウェアを、リソース間の結線の変更だけで再構成することであるものとする。

タイミングＴ７では、機能モジュール１２０が、新しく構築されたサーバ５０００のリソース状態についても、機能モジュール１５０を介してリソース管理サーバ１００に通知する。
タイミングＴ８では、機能モジュール１２０が、新しく構築されたサーバ５０００のリソース状態についても、リソースデータベース１１０に登録する。

本発明の実施形態に係る共用リソース管理システムによれば、障害が起きたリソースの状態を収集し、リソースデータベース１１０にリソースの状態情報を蓄積するので、他のシステムの業務カタログで動作可能な業務が無いか否かをシステムで検証し、確認することができる効果が有る。
また、障害が起きたリソースが存在する場合は、予備等の他のシステムの一部のリソースに切り替えることで、該障害が起きたリソースで構成されるシステムの機能の一部を、該他のシステムの一部に自動で切り替えることができる効果が有る。
また、特に、複数のサーバ装置が現用で１つのサーバ装置が待機用であるクラスタ構成の場合には、システム切換えの条件として、本発明を適用することができる効果が有る。

また、PaaS(Platform as a Service)のように、ソフトウェアを構築し、かつ稼動させるための土台となるプラットフォームにも応用して、システム間でリソースを他のシステムと共有できる効果が得られる。
また、クラウド・コンピューティングシステムを運営する集中管理センタ（コンピュータやスイッチを設置するための専用のセンタ) においても、この発明を採用することにより、システム間でリソースを他のシステムと共有できる効果が有る。

さらに、グリッド・コンピューティングシステム（インターネットなどの広域のネットワーク上にある複数の計算資源（ＣＰＵ装置などの計算機能や、ハードディスク装置などの情報格納領域）を結び付け、１つの複合したコンピュータシステムとしてのサービスを提供するシステム) においても、本発明を適用することにより、複数のコンピュータの計算モジュール間で、個々のリソースを共有できる効果が有る。

１００ リソース管理サーバ（管理用）
１１０ データベース
１２０，１３０，１５０ 機能モジュール
１４０ 構成カタログ
１０００〜５０００ サーバ（リソース用）
１１００〜５１００ ネットワークＩ／Ｆ（インタフェース）
３１００，３２００ ネットワークＩ／Ｆ

Claims (2)

1. 複数のリソースの状態情報及び障害情報を収集する収集部と、
   前記収集部が収集した状態情報及び障害情報を格納する第１格納部と、
   要求されるシステムのリソースの構成要件が記載されたカタログ情報を格納する第２格納部と、
   前記リソースの組み替え処理及び実装処理を行う処理部と
   を備え、
   前記複数のリソースのうちのクラスタ構成にある現用系の第１リソースに障害が発生したときには、当該第１リソースにて実現されていた第１機能を、前記複数のリソースのうちの前記クラスタ構成にない第２リソースに移管してもよいことが、前記第２格納部に格納されているカタログ情報に記載されている場合、前記処理部は、前記第１格納部に格納されている情報を参照して、前記第２リソースが動作可能であるか否かを検証し、前記第２リソースが動作可能であれば、前記第１機能を前記第２リソースに移管すべく、各リソースの組み替え処理及び実装処理を行う
   ことを特徴とするリソース管理装置。
2. 前記複数のリソースのうちのクラスタ構成にある現用系の第１リソースに障害が発生したときには、当該第１リソースにて実現されていた第１機能を、前記複数のリソースのうちの前記クラスタ構成にない第２リソースに移管してもよいことが、前記第２格納部に格納されているカタログ情報に記載されている場合、前記処理部は、前記第１格納部に格納されている情報を参照して、前記第２リソースが動作可能であるか否かを検証し、前記第２リソースが動作可能であれば、前記第１機能を前記第２リソースに移管すると共に、前記第１リソースにて実現されていた前記第１機能以外の機能を、前記複数のリソースのうちの前記クラスタ構成にある待機系の第３リソースに移管すべく、各リソースの組み替え処理及び実装処理を行う
   ことを特徴とする請求項１に記載のリソース管理装置。

Images