JPWO2006040811A1 - リソース交換処理プログラムおよびリソース交換処理方法 - Google Patents

Abstract

ソフトウェアＲＭ（２３）およびネットワークＲＭ（２４）が、プール内のサーバに、予め、追加対象となるサーバグループに対応するソフトウェアのインストールや、ネットワーク設定をシステムリソースＤＢ（２６）の情報を読みとり、読みとった情報を利用して行う。そして、サーバグループに含まれるサーバが故障した場合や、サーバグループの負荷が大きくなった場合に、ソフトウェアやネットワークの設定を予め行ったサーバを、サーバグループに追加する。

Description

この発明は、複数のサーバによって構成される複数のサーバグループに、予備サーバを追加・交換するリソース交換処理プログラムおよびリソース交換処理方法に関し、特に、低コストかつ迅速にサーバグループを復旧させることが可能なリソース交換処理プログラムおよびリソース交換処理方法に関する。

従来から、複数のサーバを利用して、様々な業務を実行する情報処理システムを構成し、情報処理システムに含まれるサーバが故障した場合や、サーバに対する負荷が大きくなった場合には、故障したサーバの代わりや、サーバに対する負荷を分散させるために、予備のサーバを用意し、この予備のサーバを新たに追加している。

しかし、新たにサーバを追加する場合には、追加するサーバに、各種処理を行うためのソフトウェアのインストールや、種々の環境設定などを行う必要があり、新たにサーバを追加するまでにかなりの時間を要するという問題があった。

また、ソフトウェアのインストールや、種々の環境設定は、人手によって行われるために、作業ミスが起こった場合には、ソフトウェアのインストールや、環境設定が適切に行われず、追加したサーバが機能しないという問題もあった。

そこで、特許文献１では、運用中のサーバのタスククラスを、予備のサーバのタスククラスに動的に複写し、常に双方のタスククラスを同じに保つことによって、運用中のサーバに異常が発生した場合にでも、予備のサーバと運用中のサーバとを即座に入れ替え可能とする技術が公開されている。

特開平１１−８５５５５号公報

しかしながら、かかる従来の技術では、運用中のサーバが故障していない場合であっても、常に予備のサーバを稼動させ、運用中のサーバと同様の状態を保たなければならず、余分なコストがかかってしまうという問題があった。

したがって、常に予備のサーバを稼動させるのではなく、運用中のサーバが故障した場合や、負荷が大きくなった場合に、迅速に予備のサーバを追加・入れ替えすることが極めて重要な課題となっている。

本発明は、上記に鑑みてなされたものであって、余分なコストを抑え、運用中のサーバが故障した場合や、負荷が大きくなった場合に、迅速に予備のサーバを追加・入れ替えすることができるリソース交換処理プログラム、リソース交換処理方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、複数のサーバによって構成される複数のサーバグループに、予備サーバを追加・交換するリソース交換処理プログラムであって、前記サーバグループに対するソフトウェア、ネットワークおよびストレージの設定に係る情報である設定情報を取得し、該設定情報を基にして、前記サーバグループに対応する設定を、予め、前記予備サーバに対して行う設定処理手順と、前記サーバグループに異常が発生した場合や、前記サーバグループにかかる負荷が増大した場合に、前記設定処理手順において設定を行った予備サーバを、前記サーバグループに追加する追加処理手順と、をコンピュータに実行させることを特徴とする。

また、本発明は、複数のサーバによって構成される複数のサーバグループに、予備サーバを追加・交換するリソース交換処理方法であって、前記サーバグループに対するソフトウェア、ネットワークおよびストレージの設定に係る情報である設定情報を取得し、該設定情報を基にして、前記サーバグループに対応する設定を、予め、前記予備サーバに対して行う設定処理工程と、前記サーバグループに異常が発生した場合や、前記サーバグループにかかる負荷が増大した場合に、前記設定処理工程において設定を行った予備サーバを、前記サーバグループに追加する追加処理工程と、を含んだことを特徴とする。

本発明によれば、複数のサーバによって複数のサーバグループが構成され、該サーバグループに対するソフトウェア、ネットワークおよびストレージの設定に係る情報である設定情報を取得し、該設定情報を基にして、サーバグループに対応する設定を予め、予備サーバに対して行い、サーバグループに異常が発生した場合や、サーバグループにかかる負荷が増大した場合に、設定を行った予備サーバをサーバグループに追加するので、迅速にサーバグループを復旧させることができる。

図１は、本発明に係るリソース交換処理の概念を示す図（１）である。 図２は、本発明に係るリソース交換処理の概念を示す図（２）である。 図３は、本実施例に係るリソース交換処理システムの機能構成を示す図である。 図４は、本実施例に係るリソース交換処理の処理手順を示すフローチャートである。 図５は、運用管理サーバの情報を登録するサイトデータ３００の一例を示す図である。 図６は、ドメイン管理サーバ５０，６０の情報を登録するドメイン管理サーバデータ３１０の一例を示す図である。 図７は、管理対象となるサブネットの情報を登録する管理サブネットデータ３２０の一例を示す図である。 図８は、ミドルウェアと連携して各種処理を実行するためのコマンドを記憶したミドルウェア連携ＩＦデータ３３０の一例を示す図である。 図９は、サーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃ，１５０ａ〜１５０ｃが属するドメインであるサーバドメインに係る情報を記憶したサーバドメインデータ３４０の一例を示す図である。 図１０は、プールグループに係る情報を記憶したプールグループデータ３５０の一例を示す図である。 図１１は、ストレージドメインに係る情報を記憶したストレージドメインデータ３６０の一例を示す図である。 図１２は、ネットワークドメインおよびネットワークサブドメインを説明する説明図である。 図１３は、ネットワークサブドメインに係る情報を記憶したネットワークサブドメインデータ４７０の一例を示す図である。 図１４は、ネットワークドメインに係る情報を記憶したネットワークドメインデータ４８０の一例を示す図である。 図１５は、負荷分散装置に係る情報を記憶した負荷分散装置データ４９０の一例を示す図である。 図１６は、ネットワークサブグループの構成例を説明する説明図である。 図１７は、ネットワークサブグループに係る情報を記憶したネットワークサブグループデータ６６０の一例を示す図である。 図１８は、サーバドメイン間の対応関係に係る情報を記憶したサーバドメイン間リンクデータ６７０の一例を示す図である。 図１９は、サーバドメインとストレージドメインとの間の対応関係に係る情報を記憶したサーバ／ストレージドメイン間リンクデータ６８０の一例を示す図である。 図２０は、ネットワークブートがなされるサーバの情報を記憶したネットワークブートサーバデータ６９０の一例を示す図である。 図２１は、管理対象となるサーバのデータを記憶した管理対象サーバデータ７００の一例を示す図である。 図２２は、サーバが属するグループの情報を記憶したプロビジョニング構成データ７１０の一例を示す図である。 図２３は、結線状態が均一であるサーバとストレージ機器との結線の一例を示す図である。 図２４は、ＷＷＰＮに基づく結線の均一性チェック処理を説明する図である。 図２５は、ストレージテンプレートに係るデータを記憶したストレージテンプレートデータ８００の一例を示す図である。 図２６は、サーバグループに係る情報を記憶したサーバグループデータ８１０の一例を示す図である。 図２７は、サーバグループに対応するストレージグループの情報を記憶したサーバ／ストレージグループリンクデータ８２０の一例を示す図である。 図２８は、サーバグループ間の対応関係に係る情報を記憶したサーバグループ間リンクデータ８３０の一例を示す図である。 図２９は、負荷分散装置のグループ情報を記憶した負荷分散グループデータ８４０の一例を示す図である。 図３０は、ネットワークグループに係る情報を記憶したネットワークグループデータ８５０の一例を示す図である。 図３１は、論理ボリュームをＲＡＩＤ装置に設定する設定処理の処理手順を示すフローチャートである。 図３２は、論理ボリュームの設定画面の一例を示す図である。 図３３は、ＲＡＩＤレベルの設定情報を記憶したＲＡＩＤレベル設定データ９４０の一例を示す図である。 図３４は、ＲＡＩＤ装置に係る情報を記憶したＲＡＩＤ装置データ９５０の一例を示す図である。 図３５は、ストレージサブグループが設定されたプロビジョニング構成データ９６０の一例を示す図である。 図３６は、サーバに論理ボリュームを認識させる論理ボリュームの設定処理の処理手順を示すフローチャートである。 図３７は、ＲＡＩＤ装置に構築された論理ボリュームの設定処理を説明する説明図である。 図３８は、アフィニティグループに係る情報を記憶したアフィニティグループデータ１０１０の一例を示す図である。 図３９は、マルチパスの構成に係る情報を記憶したマルチパス構成データ１０２０の一例を示す図である。 図４０は、ミラーボリュームの構成に係る情報を記憶したミラーボリューム構成データ１０３０の一例を示す図である。 図４１は、サーバに割り当てられたＩＰアドレスに係る情報を記憶したＩＰアドレス管理データ１０４０の一例を示す図である。 図４２は、ソフトウェアイメージに係る情報を記憶したソフトウェアイメージ管理データ１０５０の一例を示す図である。 図４３は、ソフトウェア配布イメージに係る情報を記憶したソフトウェア配布イメージ管理データ１０６０の一例を示す図である。 図４４は、スナップショットに係る情報を記憶したスナップショット管理データ１０７０の一例を示す図である。 図４５は、サーバをサーバグループに追加する処理の処理手順を示すフローチャートである。 図４６は、ソフトウェア配布イメージの配布状況に係る情報を記憶した配布管理データ１０８０の一例を示す図である。 図４７は、サーバグループからサーバを削除するサーバ削除処理の処理手順を説明するフローチャートである。 図４８は、プール内のサーバにソフトウェアおよびネットワークなどの情報を事前に設定する処理手順を示すフローチャートである。 図４９は、プール内のサーバにソフトウェアおよびネットワークなどの情報を事前に設定する処理手順を具体的に示すフローチャートである。 図５０は、サーバ異常時や高負荷時に、サーバ資源を追加する処理手順を示すフローチャートである。 図５１は、サーバ異常時や高負荷時に、サーバ資源を追加する処理手順を具体的に示すフローチャートである。 図５２は、管理対象となるリソースの配置を示すリソース配置出力画面１０９０の一例を示す図である。 図５３は、リソースの配置に係る設定をユーザから受け付けるリソース配置設定画面１１４０の一例を示す図である。 図５４は、サーバドメインに属するサーバグループの一覧を出力するサーバグループ一覧画面１１５０の一例を示す図である。 図５５は、サーバグループに属するサーバの一覧を出力するサーバ一覧画面１１６０の一例を示す図である。 図５６は、ストレージグループに属するストレージの一覧を出力するストレージ一覧画面１１７０の一例を示す図である。 図５７は、図３に示したサイト管理サーバ２０となるコンピュータ１２００のハードウェア構成を示す図である。 図５８は、図３に示したドメイン管理サーバ２０となるコンピュータ１３００のハードウェア構成を示す図である。 図５９は、図３に示したサーバ１１０ａとなるコンピュータ１４００のハードウェア構成を示す図である。

符号の説明

１，２ 業務
３ プール
４ Ｗｅｂドメイン
４₁〜４₉ Ｗｅｂサーバ
５ ＡＰドメイン
５₁〜５₆ ＡＰサーバ
６ ＤＢドメイン
６₁〜６₃ ＤＢサーバ
７ ストレージドメイン
７₁〜７₉ ストレージ
１０ 運用管理クライアント
２０ サイト管理サーバ
２１ システムリソースマネージャ
２２ サーバＲＭ
２３ ソフトウェアＲＭ
２４ ネットワークＲＭ
２５ ストレージＲＭ
２６ システムリソースＤＢ
２７ ＡＰ管理統括部
３０，４０，９０，１２０ ＦＷ
５０，６０ ドメイン管理サーバ
５１ システムリソースドメインマネージャ
５２ サーバサブＲＭ
５３ ソフトウェアサブＲＭ
５４ ネットワークサブＲＭ
５５ ドメインリソースＤＢ
７０ インターネット
８０ ルータ
１００，１３０ ＳＬＢ
１１０ａ，１１０ｂ，１１０ｃ サーバ
１１１ａ リソースマネージャエージェント
１１２ａ サーバＲＭエージェント
１１３ａ ソフトウェアＲＭエージェント
１１４ａ ネットワークＲＭエージェント
１１５ａ ストレージＲＭエージェント
１１６ａ ＡＰ管理部
１４０ａ，１４０ｂ，１４０ｃ サーバ
１５０ａ，１５０ｂ，１５０ｃ サーバ
１６０ａ，１６０ｂ，１６０ｃ，１６０ｄ ストレージ
１７０ ＳＡＮ
１８０ エッジドメイン
１９０ Ｗｅｂドメイン
２００ ＡＰドメイン
２１０ ＤＢドメイン
３００ サイトデータ
３１０ ドメイン管理サーバデータ
３２０ 管理サブネットデータ
３３０ ミドルウェア連携ＩＦデータ
３４０ サーバドメインデータ
３５０ プールグループデータ
３６０ ストレージドメインデータ
３７０ Ｗｅｂドメイン
３８０ａ，３８０ｂ，３８０ｃ，３８０ｄ，３８０ｅ サーバ
３９０ ＡＰドメイン
４００ａ，４００ｂ，４００ｃ，４００ｄ，４００ｅ サーバ
４１０ Ｗｅｂ−ＡＰネットワークドメイン
４２０ Ｗｅｂ−Ｂａｃｋネットワークサブドメイン
４３０ａ，４３０ｂ スイッチ
４４０ ＡＰ−Ｆｒｏｎｔネットワークサブドメイン
４５０ａ，４５０ｂ スイッチ
４６０ａ，４６０ｂ ＳＬＢ
４７０ ネットワークサブドメインデータ
４８０ ネットワークドメインデータ
４９０ 負荷分散装置データ
５１０ Ｗｅｂドメイン
５２０ａ，５２０ｂ，５２０ｃ，５２０ｄ，５２０ｅ サーバ
５３０ サーバグループA_Web
５４０ サーバグループB_Web
５５０ ＡＰドメイン
５６０ａ，５６０ｂ，５６０ｃ，５６０ｄ，５６０ｅ サーバ
５７０ A_AP
５８０ B_AP
５９０，６１０ スイッチ
６００ａ，６００ｂ ＳＬＢ
６２０ ネットワークサブグループA_Web_Back
６３０ ネットワークサブグループB_Web_Back
６４０ ネットワークサブグループA_AP_Front
６５０ ネットワークサブグループB_AP_Front
６６０ ネットワークサブグループデータ
６７０ サーバドメイン間リンクデータ
６８０ サーバ／ストレージドメイン間リンクデータ
６９０ ネットワークブートサーバデータ
７００ 管理対象サーバデータ
７１０ プロビジョニング構成データ
７２０ サーバドメイン
７３０ａ，７３０ｂ，７９０ａ，７９０ｂ サーバ
７４０ ストレージドメイン
７５０ａ，７５０ｂ ＦＣスイッチ
７６０ａ，７６０ｂ ＲＡＩＤ装置
７７０ａ、７７０ｂ ＲＡＩＤ装置ＷＷＰＮデータ
７８０ａ，７８０ｂ ＦＣスイッチＷＷＰＮデータ
７９０ａ，７９０ｂ サーバＷＷＰＮデータ
８００ ストレージテンプレートデータ
８１０ サーバグループデータ
８２０ サーバ／ストレージグループリンクデータ
８３０ サーバグループ間リンクデータ
８４０ 負荷分散グループデータ
８５０ ネットワークグループデータ
８６０ 必要条件出力画面
８７０ａ，８７０ｂ，８７０ｃ 必要条件
８８０ 論理ボリューム構成出力画面
８９０ ＲＡＩＤ装置
９００ａ，９００ｂ，９００ｃ 必要条件
９１０ａ，９１０ｂ，９１０ｃ，９１０ｄ 論理ボリューム
９２０ａ，９２０ｂ，９２０ｃ，９２０ｄ，９２０ｅ 論理ボリューム
９３０ａ，９３０ｂ ＲＡＩＤグループ
９５０ ＲＡＩＤ装置データ
９６０ プロビジョニング構成データ
９７０ サーバグループ
９８０ ストレージプール
９９０ ストレージグループ
１０００ サーバ内ストレージ構成
１０１０ アフィニティグループデータ
１０２０ マルチパス構成データ
１０３０ ミラーボリューム構成データ
１０４０ ＩＰアドレス管理データ
１０５０ ソフトウェアイメージ管理データ
１０６０ ソフトウェア配布イメージ管理データ
１０７０ スナップショット管理データ
１０８０ 配布管理データ
１０９０ リソース配置出力画面
１１００ Ｗｅｂドメイン
１１１０ ＡＰドメイン
１１２０ ＤＢドメイン
１１３０ ストレージドメイン
１１４０ リソース配置設定画面
１１５０ サーバグループ一覧画面
１１６０ サーバ一覧画面
１１７０ ストレージ一覧画面

以下に添付図面を参照して、この発明に係るリソース交換処理プログラム、リソース交換処理方法の好適な実施の形態を詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

まず、本発明に係るリソース交換処理の概念について説明する。図１及び図２は、本発明に係るリソース交換処理の概念を示す図である。図１には、各業務１，２においてＷｅｂサーバ４₁〜４₉やＡＰ（Application）サーバ５₁〜５₆，ＤＢ（Database）サーバ６₁〜６₃、ストレージ７₁〜７₉などの情報処理装置が利用される場合が示されている。

ここで、Ｗｅｂサーバ４₁〜４₉は、Ｗｅｂブラウザで閲覧されるコンテンツを、インターネットを介してクライアント装置に提供するサーバ装置である。ＡＰサーバ５₁〜５₆は、ユーザによる情報処理要求を受け付けたＷｅｂサーバ４₁〜４₉から要求された情報処理の実行を引き継ぐサーバ装置である。

ＤＢサーバ６₁〜６₃は、ＡＰサーバ５₁〜５₆からデータベースへのアクセス要求を受け付けた場合に、データベースへのアクセスを管理するサーバ装置である。ストレージ７₁〜７₉は、ＳＡＮ（Storage Area Network）によりＷｅｂサーバ４₁〜４₉やＡＰサーバ５₁〜５₆，ＤＢサーバ６₁〜６₃に接続される記憶装置である。

本発明に係るリソース交換処理では、ＬＡＮ（Local Area Network）やＳＡＮなどにおいて、他の装置との間の物理的な結線状態が互いに均一であるサーバやストレージなどのリソース群をドメインとして管理する。

たとえば、図１の場合には、業務１，２で利用されるサーバ群が、Ｗｅｂドメイン４、ＡＰドメイン５およびＤＢドメイン６として管理され、業務１，２で利用されるストレージ群が、ストレージドメイン７として管理されている。

この場合、Ｗｅｂドメイン４に属するＷｅｂサーバ４₁〜４₉の他の装置に対する結線状態は互いに均一であり、ＡＰドメイン５に属するＡＰサーバ５₁〜５₆の他の装置に対する結線状態は互いに均一であり、ＤＢドメイン６に属するＤＢサーバ６₁〜６₃の他の装置に対する結線状態は互いに均一であり、ストレージドメイン７に属するストレージ７₁〜７₉の他の装置に対する結線状態は互いに均一となっている。

そして、このリソース交換処理では、未使用のＷｅｂサーバ４₁〜４₉、ＡＰサーバ５₁〜５₆，ＤＢサーバ６₁〜６₃およびストレージ７₁〜７₉をドメインごとにプール３に登録しておき、必要に応じて各業務１，２にＷｅｂサーバ４₁〜４₉、ＡＰサーバ５₁〜５₆，ＤＢサーバ６₁〜６₃およびストレージ７₁〜７₉を割り当てる。

たとえば、図１では、業務１には、Ｗｅｂサーバ４₂，４₃、ＡＰサーバ５₁、ＤＢサーバ６₁、ストレージ７₇が割り当てられ、業務２には、Ｗｅｂサーバ４₉、ＡＰサーバ５₂，５₃、ＤＢサーバ６₂、ストレージ７₈，７₉が割り当てられている。

そして、業務１，２に割り当てられたＷｅｂサーバ４₂，４₃，４₉、ＡＰサーバ５₁，５₂，５₃、ＤＢサーバ６₁，６₃の負荷が増大した場合や、ストレージ７₇〜７₉の記憶容量が不足したような場合に、プール３に登録されているＷｅｂサーバ４₁，４₄〜４₈、ＡＰサーバ５₄〜５₆，ＤＢサーバ６₃またはストレージ７₁〜７₆を業務で利用可能なサーバとして追加する。

具体的には、プール３に登録されているＷｅｂサーバ４₁，４₄〜４₈、ＡＰサーバ５₄〜５₆，ＤＢサーバ６₃に必要なソフトウェアを導入し、ネットワークの設定などを自動的におこなうことにより、Ｗｅｂサーバ４₁，４₄〜４₈、ＡＰサーバ５₄〜５₆，ＤＢサーバ６₃を業務で利用可能なサーバとして追加する。

また、ストレージ７₁〜７₉を追加する場合は、ストレージ７₁〜７₉に対して論理ボリュームの設定やネットワークの設定などを自動的におこなうことにより、当該ストレージ７₁〜７₉を業務で利用可能なストレージ７₁〜７₉として追加する。

たとえば、図１には、業務２のＷｅｂドメイン４において、プール３に登録されていたＷｅｂサーバ４₄が新たに追加される場合が示されている。

また、本実施例では、図２に示すように、各サーバを業務で利用可能なサーバとして追加する場合に、予め、プールに登録されているサーバを、一旦、対応するサーバ群に組み込み、必要なソフトウェアやネットワーク設定等を行った後、プールに戻す。そして、サーバの負荷が増加した場合や、サーバが故障した場合に、プールに登録されたサーバを組み込むことで、高速にサーバ故障や高負荷などに対応することができる。

さらに、このリソース交換処理では、業務１，２で利用されているＷｅｂサーバ４₂，４₃，４₉、ＡＰサーバ５₁〜５₃，ＤＢサーバ６₁，６₂またはストレージ７₇〜７₉が長期間使用されていないような場合に、Ｗｅｂサーバ４₂，４₃，４₉、ＡＰサーバ５₁〜５₃、ＤＢサーバ６₁，６₂、または、ストレージ７₇〜７₉を業務で利用可能なサーバから除外し、プール３に登録する処理がおこなわれる。

ここでプール３に登録されたＷｅｂサーバ４₂，４₃，４₉、ＡＰサーバ５₁〜５₃，ＤＢサーバ６₁，６₂，ストレージ７₇〜７₉は、別の業務１，２で利用されているＷｅｂサーバ４₂，４₃，４₉、ＡＰサーバ５₁〜５₃、ＤＢサーバ６₁，６₂の負荷が増大したり、ストレージ７₇〜７₉の記憶容量が不足したような場合に再利用される。

具体的には、Ｗｅｂサーバ４₂，４₃，４₉、ＡＰサーバ５₁〜５₃、ＤＢサーバ６₁，６₂に導入されているソフトウェアを削除し、ネットワークの設定の変更などを自動的におこなうことにより、Ｗｅｂサーバ４₂，４₃，４₉、ＡＰサーバ５₁〜５₃，ＤＢサーバ６₁，６₂が業務１，２で利用可能なサーバから除外され、プール３に登録される。

また、ストレージ７₇〜７₉を業務１，２で利用可能なストレージから除外してプール３に登録する場合には、ストレージ７₇〜７₉に対するネットワークの設定などを自動的におこなうことにより、当該ストレージ７₇〜７₉を業務で利用可能なストレージから除外し、プール３に登録する。

たとえば、図１には、業務２のＡＰドメイン５において、プール３に登録されていたＡＰサーバ５₂が業務で利用可能なサーバから除外され、プール３に登録される場合が示されている。また、プール３に登録されたサーバ５₄は、業務１で利用されているサーバ５₁の負荷が増大したような場合に再利用され、業務１に新たに追加される。

つぎに、本実施例に係るリソース交換処理システムの機能構成について説明する。図３は、本実施例に係るリソース交換処理システムの機能構成を示す図である。

図３に示すように、このリソース交換処理システムでは、運用管理クライアント１０と、サイト管理サーバ２０とが、ＦＷ（Firewall）３０経由でネットワークを介して接続されている。また、サイト管理サーバ２０とドメイン管理サーバ５０，６０とが、ＦＷ４０経由でネットワークを介して接続されている。

また、サイト管理サーバ２０と、エッジドメイン１８０に属するルータ８０とが、ＦＷ４０経由でネットワークを介して接続されている。さらに、サイト管理サーバ２０と、ストレージドメイン２２０に属するストレージ１６０ａ〜１６０ｃ、および、プールされているストレージ１６０ｄとが、ＦＷ４０経由でネットワークを介して接続されている。

ドメイン管理サーバ５０は、ＦＷ９０、ＳＬＢ（Server Load Balancer）１００およびＷｅｂドメイン１９０に属するサーバ１１０ａ〜１１０ｃに、ネットワークを介して接続されている。

また、ドメイン管理サーバ６０は、ＦＷ１２０、ＳＬＢ１３０、ＡＰドメイン２００に属するサーバ１４０ａ〜１４０ｃ、および、ＤＢドメイン２１０に属するサーバ１５０ａ〜１５０ｃに、ネットワークを介して接続されている。

さらに、ストレージドメイン２２０に属するストレージ１６０ａ〜１６０ｃ、および、プールされているストレージ１６０ｄは、Ｗｅｂドメイン１９０に属するサーバ１１０ａ〜１１０ｃ、ＡＰドメイン２００に属するサーバ１４０ａ〜１４０ｃ、および、ＤＢドメイン２１０に属するサーバ１５０ａ〜１５０ｃに、ＳＡＮ１７０を介して接続されている。

ここで、運用管理クライアント１０は、リソース交換処理に係るさまざまな設定をユーザから受け付けて、その設定情報をサイト管理サーバ２０に送信するとともに、サイト管理サーバ２０からさまざまな出力結果を受け付けて、モニタ等に表示するクライアント装置である。

サイト管理サーバ２０は、図１及び図２で説明したようなリソース交換処理を、ドメイン管理サーバ５０，６０と連携して実行するサーバ装置である。このサイト管理サーバ２０は、システムリソースマネージャ２１、サーバＲＭ（Resource Manager）２２、ソフトウェアＲＭ（Resource Manager）２３、ネットワークＲＭ（Resource Manager）２４、ストレージＲＭ（Resource Manager）２５、システムリソースＤＢ（Database）２６およびＡＰ（Application）管理統括部２７の各機能部を有する。

システムリソースマネージャ２１は、運用管理クライアント１０からリソース交換処理に係るさまざまな設定情報を受け付けるとともに、サーバＲＭ２２、ソフトウェアＲＭ２３、ネットワークＲＭ２４、ストレージＲＭ２５と連携してリソースの設定処理を実行する管理部である。また、このシステムリソースマネージャ２１は、ドメイン管理サーバ５０，６０との間のデータの授受を司る。

サーバＲＭ２２は、各サーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃおよび１５０ａ〜１５０ｃの起動、停止、ハードウェアに係る情報の収集、設定などをおこなう管理部である。このサーバＲＭ２２は、ドメイン管理サーバ５０のサーバサブＲＭ（Resource Manager）５２およびサーバ１１０ａのサーバＲＭエージェント１１２ａと連携して上記処理を実行する。

ソフトウェアＲＭ２３は、各サーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃおよび１５０ａ〜１５０ｃに対するソフトウェアのインストール、設定、ソフトウェアに係る情報の収集などをおこなう管理部である。このソフトウェアＲＭ２３は、ドメイン管理サーバ５０のソフトウェアサブＲＭ（Resource Manager）５３およびサーバ１１０ａのソフトウェアＲＭエージェント１１３ａと連携して上記処理を実行する。

ネットワークＲＭ２４は、ネットワークに係る情報の収集や設定などをおこなう管理部である。このネットワークＲＭ２４は、ドメイン管理サーバ５０のネットワークサブＲＭ（Resource Manager）５４およびサーバ１１０ａのネットワークＲＭエージェント１４ａと連携して上記処理を実行する。

ストレージＲＭ２５は、ストレージドメイン２２０に属するストレージ１６０ａ〜１６０ｃ、および、プールされているストレージ１６０ｄに係る情報の収集や設定などをおこなう管理部である。ここでは、ストレージＲＭ２５は、ドメイン管理サーバ５０，６０を介することなく、ストレージ１６０ａ〜１６０ｃ、および、プールされているストレージ１６０ｄを管理する。

システムリソースＤＢ（Database）２６は、システムリソースマネージャ２１、サーバＲＭ２２、ソフトウェアＲＭ２３、ネットワークＲＭ２４およびストレージＲＭ２５が管理するさまざまなリソースの情報を記憶するデータベースである。ここに記憶される具体的なデータについては、後に詳細に説明する。

ＡＰ管理統括部２７は、ＡＰ（Application）管理部１１６ａを統括管理する処理部である。具体的には、ＡＰ管理部１１６ａにアプリケーションの組み込み処理や設定処理の実行要求をおこなう。このＡＰ管理統括部２７の機能は、サイト管理サーバ２０に導入されたミドルウェアが実行されることにより実現されるものである。

ドメイン管理サーバ５０，６０は、１つまたは複数のドメイン内のリソースを管理するサーバ装置である。ドメイン管理サーバ５０は、システムリソースドメインマネージャ５１、サーバサブＲＭ５２、ソフトウェアサブＲＭ５３、ネットワークサブＲＭ５４およびドメインリソースＤＢ（Database）５５の各機能部を有する。

なお、ドメイン管理サーバ６０は、ドメイン管理サーバ５０の各機能部と同様の機能部を有しているため、図３ではドメイン管理サーバ６０の各機能部の図示および説明を省略する。

システムリソースドメインマネージャ５１は、サーバサブＲＭ５２、ソフトウェアサブＲＭ５３、ネットワークサブＲＭ５４と連携して各ドメインに属するリソースの情報収集や設定処理などを実行させる管理部である。

また、このシステムリソースドメインマネージャ５１は、サイト管理サーバ２０、および、ＦＷ９０やＳＬＢ１００などのネットワーク機器、また、リソースの管理対象であるサーバ１１０ａ〜１１０ｃとの間のデータの授受を司る。

サーバサブＲＭ５２は、サーバＲＭ２２およびサーバＲＭエージェント１１２ａと連携して、各サーバ１１０ａ〜１１０ｃの起動、停止、ハードウェアに係る情報の収集、設定などをおこなう管理部である。

ソフトウェアサブＲＭ５３は、ソフトウェアＲＭ２３およびソフトウェアＲＭエージェント１１３ａと連携して、各サーバ１１０ａ〜１１０ｃに対するソフトウェアのインストール、設定、ソフトウェアに係る情報の収集などをおこなう管理部である。

ネットワークサブＲＭ５４は、ネットワークＲＭ２４およびネットワークＲＭエージェント１１４ａと連携して、ネットワークに係る情報の収集や設定などをおこなう管理部である。

ドメインリソースＤＢ５５は、サーバサブＲＭ５２、ソフトウェアサブＲＭ５３、ネットワークサブＲＭ５４が管理対象であるサーバ１１０ａ〜１１０ｃの各種情報の収集や設定をおこなう場合に、サーバ１１０ａ〜１１０ｃから取得した情報や、システムリソースＤＢ２６から取得したデータを記憶するデータベースである。また、ドメインリソースＤＢ５５は、サーバ１１０ａ〜１１０ｃのネットワークブートをおこなう場合に用いる仮のＯＳ（Operating
System）を記憶する。

ルータ８０は、インターネット７０を介したデータ通信においてデータパケットのルーティングをおこなうネットワーク機器である。ＦＷ３０，４０，９０，１２０は、各種サーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃ，１５０ａ〜１５０ｃへの不正アクセスを防止するためのネットワーク機器である。

ＳＬＢ１００，１３０は、サーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃに対する情報処理要求を複数のサーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃに分散して転送する負荷分散装置である。なお、ＳＬＢ１００，１３０の前後には、さらにスイッチが接続されているが、図３ではスイッチの図示を省略している。

サーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃ，１５０ａ〜１５０ｃは、さまざまな情報処理を実行するサーバ装置である。サーバ装置１１０ａは、リソースマネージャエージェント１１１ａ、サーバＲＭエージェント１１２ａ、ソフトウェアＲＭエージェント１１３ａ、ネットワークＲＭエージェント１１４ａ、ストレージＲＭエージェント１１５ａおよびＡＰ管理部１１６ａの各機能部を有する。

なお、サーバ１１０ｂ，１４０ａ，１４０ｂ，１５０ａ，１５０ｂは、サーバ１１０ａの各機能部と同様の機能部を有しているため、図３ではサーバ１１０ｂ，１４０ａ，１４０ｂ，１５０ａ，１５０ｂの各機能部の図示および説明を省略する。

また、サーバ１１０ｃ，１４０ｃ，１５０ｃは、プールされているサーバであり、これ
らのサーバには、上記各機能部は存在しない。これらのサーバ１１０ｃ，１４０ｃ，１５０ｃにおいては、業務に利用可能なサーバとして設定される場合に、各機能部を実現するコンピュータプログラムがサーバ１１０ｃ，１４０ｃ，１５０ｃに導入され実行されることにより各機能部が実現される。

リソースマネージャエージェント１１１ａは、ドメイン管理サーバ５０のシステムリソースドメインマネージャ５１からサーバ１１０ａの情報収集処理や設定処理などの実行要求を受け付け、それらの処理をサーバＲＭエージェント１１２ａ、ソフトウェアＲＭエージェント１１３ａ、ネットワークＲＭエージェント１１４ａ、ストレージＲＭエージェント１１５ａと連携して実行するエージェントである。

サーバＲＭエージェント１１２ａは、サーバ１１０ａの起動、停止、ハードウェアに係る情報の収集、設定などを実行するエージェントである。ソフトウェアＲＭエージェント１１４ｂは、サーバ１１０ａに対するソフトウェアの導入、設定およびソフトウェアに係る情報収集などをおこなうエージェントである。

ネットワークＲＭエージェント１１４ａは、サーバ１１０ａが接続されているネットワークの情報収集および設定などを実行するエージェントである。ストレージＲＭエージェント１１５ａは、サーバ１１０ａに接続されたストレージの情報収集や設定などをおこなうエージェントである。

ストレージ１６０ａ〜１６０ｃは、Ｗｅｂドメイン１９０に属するサーバ１１０ａ〜１１０ｃ、ＡＰドメイン２００に属するサーバ１４０ａ〜１４０ｃ、ＤＢドメイン２１０に属するサーバ１５０ａ〜１５０ｃにより利用されるストレージであり、ＲＡＩＤ装置により構成される。ストレージ１６０ｄは、プールされているストレージである。

なお、Ｗｅｂドメイン１９０に属するサーバ１１０ａ〜１１０ｃ、ＡＰドメイン２００に属するサーバ１４０ａ〜１４０ｃ、および、ＤＢドメイン２１０に属するサーバ１５０ａ〜１５０ｃ間を接続するネットワークにはＶＬＡＮ（Virtual Local Area Network）を設定することもできる。

つぎに、本実施例に係るリソース交換処理の処理手順について説明する。図４は、本実施例に係るリソース交換処理の処理手順を示すフローチャートである。

ここで、サイト管理サーバ２０には、システムリソースマネージャ２１、サーバＲＭ２２、ソフトウェアＲＭ２３、ネットワークＲＭ２４、ストレージＲＭ２５、ＡＰ管理統括部２７の各機能をコンピュータに実行させるプログラムを、ドメイン管理サーバ５０，６０には、システムリソースドメインマネージャ５１、サーバサブＲＭ５２、ソフトウェアサブＲＭ５３、ネットワークサブＲＭ５４の各機能をコンピュータに実行させるプログラムを、各サーバ１１０ａ，１１０ｂ，１４０ａ，１４０ｂ，１５０ａ，１５０ｂには、リソースマネージャエージェント１１１ａ，サーバＲＭエージェント１１２ａ、ソフトウェアＲＭエージェント１１３ａ、ネットワークＲＭエージェント１１４ａ、ストレージＲＭエージェント１１５ａ、ＡＰ管理部１１６ａの各機能をコンピュータに実行させるプログラムを、あらかじめ導入しておくこととする。

図４に示すように、まず、サイト管理サーバ２０のシステムリソースマネージャ２１は、運用管理サーバおよび管理ＬＡＮの登録処理をおこなう（ステップＳ１０１）。ここで、運用管理サーバおよび管理ＬＡＮとは、サーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃ，１５０ａ〜１５０ｃやＳＡＮ１７０などの管理対象となるリソースを管理するために用いられるサーバおよびＬＡＮのことである。

以下に、ステップＳ１０１でおこなわれる処理をさらに詳細に説明する。図５は、運用管理サーバの情報を登録するサイトデータ３００の一例を示す図である。このサイトデータ３００は、サイト、サイト管理サーバおよびドメイン管理サーバの情報を記憶している。

サイトは、管理対象となるリソースがあるサイトの識別情報である。サイト管理サーバは、そのサイトを管理するよう設定されたサイト管理サーバ２０の情報である。ドメイン管理サーバは、そのサイトに設定されたドメインを管理するよう設定されたドメイン管理サーバ５０，６０の情報である。

また、図６は、ドメイン管理サーバ５０，６０の情報を登録するドメイン管理サーバデータ３１０の一例を示す図である。このドメイン管理サーバデータ３１０は、ドメイン管理サーバおよび管理サブネットの情報を記憶している。

ドメイン管理サーバは、図５で説明したドメイン管理サーバと同様の情報である。管理サブネットは、ドメイン管理サーバによりリソースが管理されるサブネット（管理サブネット）の情報である。

また、図７は、管理対象となるサブネットの情報を登録する管理サブネットデータ３２０の一例を示す図である。この管理サブネットデータ３２０は、管理サブネット、ネットワークアドレス、ネットマスクおよびデフォルトゲートウェイの情報を記憶している。

管理サブネットは、図６で説明した管理サブネットと同様の情報である。ネットワークアドレスは、管理サブネットを識別するためのネットワークアドレスである。ネットマスクは、ＩＰアドレスの何ビット目をネットワークアドレスとして使用するかを定義するために用いられるネットマスクである。デフォルトゲートウェイは、管理サブネット外にデータを送信する場合に用いられるデフォルトゲートウェイを特定するＩＰアドレスの情報である。

ステップＳ１０１において、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサイト、サイト管理サーバおよびドメイン管理サーバの情報を受け付け、その情報を図５に示したサイトデータ３００に登録する。

また、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したドメイン管理サーバおよび管理サブネットの情報を受け付け、その情報を図６に示したドメイン管理サーバデータ３１０に登録する。

続いて、システムリソースマネージャ２１は、図６で説明した管理サブネットに対応するネットワークアドレス、ネットマスクおよびデフォルトゲートウェイの情報を、図７の管理サブネットデータ３２０に登録する。

さらに、システムリソースマネージャ２１は、ミドルウェアによりその機能が実現されるＡＰ管理統括部２７に、サーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃ，１５０ａ〜１５０ｃの追加や削除などのイベントの発生を通知し、ＡＰ管理統括部２７と連携して各種処理を実行するためのコマンドを設定する。

図８は、ミドルウェアと連携して各種処理を実行するためのコマンドを記憶したミドルウェア連携ＩＦデータ３３０の一例を示す図である。このミドルウェア連携ＩＦデータ３３０は、ミドルウェア名、対象イベント、タイミング、場所、実行コマンドの情報を記憶している。

ミドルウェア名は、システムリソースマネージャ２１が連携して処理をおこなうミドルウェアの情報である。対象イベントは、システムリソースマネージャ２１がミドルウェアに実行要求をおこなうイベントの情報である。タイミングは、システムリソースマネージャ２１がミドルウェアに処理の実行要求を送信するタイミング（対象イベントの処理の前後）の情報である。

場所は、ミドルウェアのコマンドを実行する場所（ManagerあるいはAgent）の情報である。「Manager」は、管理サイトサーバ２０上でコマンドを実行する場合を示し、「Agent」は、管理対象となるサーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃ，１５０ａ〜１５０ｃ上でコマンドを実行する場合を示している。実行コマンドは、ミドルウェアに対して各種イベントの発生を通知するコマンドの情報である。

図４の説明に戻ると、システムリソースマネージャ２１は、ドメインの作成処理および作成したドメイン間のリンク処理をおこなう（ステップＳ１０２）。以下に、ステップＳ１０２でおこなわれる処理をさらに詳細に説明する。

図９は、サーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃ，１５０ａ〜１５０ｃが属するドメインであるサーバドメインに係る情報を記憶したサーバドメインデータ３４０の一例を示す図である。

このサーバドメインデータ３４０は、サーバドメイン、サーバアーキテクチャおよび管理サブネットの情報を記憶している。サーバドメインは、管理対象となるサーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃ，１５０ａ〜１５０ｃが属するドメインの情報である。

サーバアーキテクチャは、各サーバドメインに属するサーバ１１０ａ〜１１０ｃ，１４０ａ〜１４０ｃ，１５０ａ〜１５０ｃのＣＰＵ（Central Processing Unit）アーキテクチャの情報である。管理サブネットは、図６に示した管理サブネットと同様の情報である。

ステップＳ１０２においては、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作しておこなったサーバドメインおよびサーバアーキテクチャの設定に係る情報を受け付け、サーバドメインデータ３４０に登録する。このサーバドメインは、ステップＳ１０１において設定された管理サブネット単位で設定される。

また、ステップＳ１０２においては、システムリソースマネージャ２１は、各サーバドメインに属するサーバグループを設定し、サーバグループ間で共有されるプールグループおよび特定のサーバグループに専用のプールグループを設定する。

ここで、サーバグループとは、同一のサーバドメインに含まれるサーバを１つまたは複数のグループに分けたものである。また、プールグループとは、各サーバグループに割り当てられたサーバのプールである。

図１０は、プールグループに係る情報を記憶したプールグループデータ３５０の一例を示す図である。このプールグループデータ３５０には、プールグループ、種別、サーバドメインの情報が記憶されている。

プールグループは、上述したサーバのプールの識別情報である。種別は、プールグループが複数のサーバグループに共用させるものか、特定のサーバグループにのみ利用を許可するものかを示す情報である。サーバドメインは、図９で説明したサーバドメインと同様の情報である。

ここで、システムリソースマネージャ２１は、各サーバドメインに対してプールグループを１つずつ割り当てる。また、サーバドメインが、複数のサーバグループを有する場合に、システムリソースマネージャ２１は、それらのサーバグループ専用のプールグループを割り当てる。

その後、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したストレージドメインの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するストレージドメインデータ３６０として登録する。

図１１は、ストレージドメインに係る情報を記憶したストレージドメインデータ３６０の一例を示す図である。このストレージドメインデータ３６０は、ストレージドメインおよびパスの多重度の情報を記憶している。ストレージドメインは、設定されたストレージドメインを識別する識別情報である。パスの多重度は、ＳＡＮにおけるデータ通信パスの多重度の情報である。

さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークサブドメインの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するネットワークサブドメインデータ４７０として登録する。

ここで、ネットワークサブドメインとは、異なるサーバドメインに属するサーバを接続する複数のネットワーク機器が属するネットワークドメインをさらに分割したサブドメインである。

図１２は、ネットワークドメインおよびネットワークサブドメインを説明する説明図である。図１２には、Ｗｅｂドメイン３７０に属するサーバ３８０ａ〜３８０ｅと、ＡＰドメイン３９０に属するサーバ４００ａ〜４００ｅとを接続するスイッチ４３０ａ，４３０ｂ，４５０ａ，４５０ｂ、および、ＳＬＢ４６０ａ，４６０ｂが示されている。

ここで、スイッチ４３０ａおよびスイッチ４３０ｂは、Ｗｅｂ−Ｂａｃｋサブドメイン４２０を構成し、スイッチ４５０ａおよびスイッチ４５０ｂは、ＡＰ−Ｆｒｏｎｔサブドメイン４４０を構成している。また、Ｗｅｂ−Ｂａｃｋサブドメイン４２０、ＡＰ−Ｆｒｏｎｔサブドメイン４４０、ＳＬＢ４６０ａ、および、ＳＬＢ４６０ｂがＷｅｂ−ＡＰネットワークドメイン４１０を構成している。

図１３は、ネットワークサブドメインに係る情報を記憶したネットワークサブドメインデータ４７０の一例を示す図である。このネットワークサブドメインデータ４７０は、ネットワークサブドメイン、スイッチ機種およびスイッチ管理ＩＰの情報を記憶している。

ネットワークサブドメインは、図１２で説明したネットワークサブドメインを識別する情報である。スイッチ機種は、ネットワークサブドメインに属するスイッチの機種の情報である。スイッチ管理ＩＰは、管理用に各スイッチに割り当てられたＩＰアドレスの情報である。

また、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークドメインに係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するネットワークドメインデータ４８０として登録する。

図１４は、ネットワークドメインに係る情報を記憶したネットワークドメインデータ４８０の一例を示す図である。このネットワークドメインデータ４８０は、ネットワークドメイン、フロントサブドメイン、接続方式、機器、バックサブドメインおよび冗長化方式の情報を記憶している。

ネットワークドメインは、図１２で説明したネットワークドメインを識別する識別情報である。フロントサブドメインは、図１２に示したように、ネットワークドメインがＳＬＢ４６０ａ，４６０ｂを境として２つのサブドメインに分割された場合に、インターネット７０に近い方のサブドメインを識別する識別情報である。

接続方式は、フロントサブドメインに属するスイッチ４３０ａ，４３０ｂなどのネットワーク機器と、後に説明するバックサブドメインに属するスイッチ４５０ａ，４５０ｂなどのネットワーク機器との間を接続する方式に係る情報である。たとえば、この方式には、ロードバランサにより接続する方式や、ファイアウォールにより接続する方式などがある。

バックサブドメインは、図１２に示したように、ネットワークドメインがＳＬＢ４６０ａ，４６０ｂを境として２つのサブドメインに分割された場合に、インターネット７０に通い方のサブドメインを識別する識別情報である。冗長化方式は、ネットワークドメインにおいてデータ通信経路が冗長化されている場合の冗長化の方式を示す情報である。

さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークサブドメインの接続機器に係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明する負荷分散装置データ４９０として登録する。ここで、ネットワークサブドメインの接続機器とは、図１２で説明したＳＬＢ４６０ａ，４６０ｂなどの機器のことである。

図１５は、負荷分散装置に係る情報を記憶した負荷分散装置データ４９０の一例を示す図である。この負荷分散装置データ４９０は、負荷分散装置名、管理ＩＰ、機種、ＳＮＭＰコミュニティおよびＩＤ／パスワードの情報を記憶している。

負荷分散装置名は、ネットワークサブドメインの接続機器を識別する名称である。管理ＩＰは、接続機器の管理用に各接続機器に割り当てられたＩＰアドレスの情報である。機種は、接続機器の機種の情報である。

ＳＮＭＰ（Simple Network Management Protocol）コミュニティは、接続機器を管理するドメイン管理サーバ５０，６０およびサイト管理サーバ２０と接続機器とが属するＳＮＭＰコミュニティを特定する情報である。ＩＤ／パスワードは、接続機器にアクセスするために必要なＩＤおよびパスワードの情報である。

また、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークサブグループの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するネットワークサブグループデータ６６０として登録する。

ここで、ネットワークサブグループとは、サーバドメインに属するサーバにサーバグループが設定されている場合に、異なるサーバドメインに属するサーバグループ間を接続するネットワークを複数のネットワークに分割したものである。

図１６は、ネットワークサブグループの構成例を説明する説明図である。図１６には、Ｗｅｂドメイン５１０に属するサーバ５２０ａ〜５２０ｅと、ＡＰドメイン５５０に属するサーバ５６０ａ〜５６０ｅとを接続するスイッチ５９０，６１０、および、ＳＬＢ６００ａ，６００ｂが示されている。

ここで、サーバ５２０ａとサーバ５２０ｂとは、サーバグループＡ＿Ｗｅｂ５３０を構成し、サーバ５２０ｃとサーバ５２０ｄとは、サーバグループＢ＿Ｗｅｂ５４０を構成し、サーバ５６０ａとサーバ５６０ｂとは、サーバグループＡ＿ＡＰ５７０を構成し、サーバ５６０ｃとサーバ５６０ｄとは、サーバグループＢ＿ＡＰ５８０を構成している。

そして、サーバグループＡ＿Ｗｅｂ５３０とＳＬＢ６００ａとを接続するネットワークがネットワークサブグループＡ＿Ｗｅｂ＿Ｂａｃｋ６２０を構成し、サーバグループＢ＿Ｗｅｂ５４０とＳＬＢ６００ｂとを接続するネットワークがネットワークサブグループＢ＿Ｗｅｂ＿Ｂａｃｋ６３０を構成し、ＳＬＢ６００ａとサーバグループＡ＿ＡＰ５７０とを接続するネットワークがネットワークサブグループＡ＿ＡＰ＿Ｆｒｏｎｔ６４０を構成し、ＳＬＢ６００ｂとサーバグループＢ＿ＡＰ５８０とを接続するネットワークがネットワークサブグループＢ＿ＡＰ＿Ｆｒｏｎｔ６５０を構成している。

また、図１７は、ネットワークサブグループに係る情報を記憶したネットワークサブグループデータ６６０の一例を示す図である。このネットワークサブグループデータ６６０は、ネットワークサブグループ、ネットワークサブドメイン、サブネットおよび冗長化用サブネットの情報を記憶している。

ネットワークサブグループは、図１６で例を挙げて説明したようなネットワークサブグループを識別する名称である。ネットワークサブドメインは、ネットワークサブグループが属するネットワークサブドメインの情報である。

サブネットは、ネットワークサブグループに割り当てられるネットワークアドレスおよびサブネットマスクの情報である。冗長化用サブネットは、ネットワークサブグループに属するネットワークが複数のデータ通信回線を用いて冗長化される場合に、余分に追加されたデータ通信回線からなるネットワークに割り当てられるネットワークアドレスおよびサブネットマスクの情報である。

その後、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサーバドメイン間の対応関係に係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバドメイン間リンクデータ６７０として登録する。

図１８は、サーバドメイン間の対応関係に係る情報を記憶したサーバドメイン間リンクデータ６７０の一例を示す図である。このサーバドメイン間リンクデータ６７０は、フロントサーバドメイン、ネットワークドメインおよびバックサーバドメインの情報を記憶している。

フロントサーバドメインは、図１２に示したようなネットワークドメインを挟むサーバドメインのうち、よりインターネット７０側にあるサーバドメインを示す情報である。ネットワークドメインは、図１２で説明したネットワークドメインの識別情報である。バックサーバドメインは、図１２に示したようなネットワークドメインを挟むサーバドメインのうち、よりインターネット７０から遠い側にあるサーバドメインを示す情報である。

さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサーバドメインとストレージドメインとの間の対応関係に係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバ／ストレージドメ
イン間リンクデータ６８０として登録する。

図１９は、サーバドメインとストレージドメインとの間の対応関係に係る情報を記憶したサーバ／ストレージドメイン間リンクデータ６８０の一例を示す図である。このサーバ／ストレージドメイン間リンクデータ６８０は、サーバドメインおよびストレージドメインの情報を記憶している。ここで、サーバドメインは、図９に示したサーバドメインと同様の情報である。ストレージドメインは、図１１に示したストレージドメインと同様の情報である。

図４の説明に戻ると、システムリソースマネージャ２１は、管理対象となるサーバリソースおよびストレージリソースの登録をおこなう（ステップＳ１０３）。以下に、ステップＳ１０３でおこなわれる処理をさらに詳細に説明する。

まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、サーバを登録する管理サブネットの選択をおこなった際、ユーザにより選択された管理サブネットの情報を受け付ける。

さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して入力した管理対象とするサーバの情報を運用管理クライアント１０から受け付け、その情報をドメイン管理サーバ５０のドメインリソースＤＢ２６に、以下に説明するネットワークブートサーバデータ６９０として記憶する。ここで登録されたサーバは、後にネットワークブートがおこなわれ、サーバの各種情報が取得された後、サーバリソースとして登録される。

図２０は、ネットワークブートがなされるサーバの情報を記憶したネットワークブートサーバデータ６９０の一例を示す図である。このネットワークブートサーバデータ６９０は、ＭＡＣアドレス、ＩＰアドレスおよびホスト名の情報を記憶している。

ＭＡＣアドレスは、サーバのＭＡＣアドレスの情報である。ＩＰアドレスは、サーバに割り当てられたＩＰアドレスの情報である。ホスト名は、サーバに割り当てられたホスト名の情報である。

ここで、システムリソースマネージャ２１は、ネットワークブートをおこなうサーバのユーザにより入力されたＭＡＣアドレスの情報を受け付けた場合に、そのＭＡＣアドレスに対応するサーバに、ＩＰアドレスとホスト名とを自動的に割り当てる。

そして、システムリソースマネージャ２１は、ドメイン管理サーバ５０のシステムリソースドメインマネージャ５１と連携し、ドメイン管理サーバ５０のドメインリソースＤＢ５５に記憶された仮のＯＳを用いて、ＩＰアドレスとホスト名とが割り当てられたサーバのネットワークブートをおこなう。

そして、サーバサブＲＭ５２、リソースマネージャエージェント１１１ａ、および、サーバＲＭエージェント１１２ａが連携することにより、サーバのハードウェアに係る情報を収集し、収集した情報をシステムリソースドメインマネージャ５１に送信する。

その後、システムリソースマネージャ２１は、システムリソースドメインマネージャ５１からサーバのハードウェアに係る情報を取得して、システムリソースＤＢ２６にその情報を、以下に説明する管理対象サーバデータ７００として記憶する。

また、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作
して、ＳＡＮ１７０を介して接続されるストレージ１６０ａ〜１６０ｄからサーバを起動するＳＡＮブートをおこなうか否かの設定情報を入力した場合に、その設定情報を受け付け、その設定情報を管理対象サーバデータ７００に登録する。

図２１は、管理対象となるサーバのデータを記憶した管理対象サーバデータ７００の一例を示す図である。この管理対象サーバデータ７００は、サーバ名、ＩＰアドレス、ＭＡＣアドレス、サーバアーキテクチャ、モデル、ＳＡＮブートおよび状態の情報を記憶している。

サーバ名は、管理対象となるサーバを識別する名称である。ＩＰアドレスは、サーバに割り当てられたＩＰアドレスである。ＭＡＣアドレスは、サーバのＭＡＣアドレスである。サーバアーキテクチャは、サーバのＣＰＵアーキテクチャの情報である。モデルは、サーバの型式である。ＳＡＮブートは、ＳＡＮ１７０を介して接続されるストレージ１６０ａ〜１６０ｄからサーバを起動するＳＡＮブートをおこなうか否かの設定情報である。状態は、サーバに異常が発生しているか否かを示す情報である。

なお、ここでは、ユーザがＭＡＣアドレスを指定してネットワークブートをおこなうサーバを選択することとしているが、サーバの選択を自動的におこなうようにしてもよい。具体的には、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、自動的に選択をおこなうサーバの台数に係る情報を設定した場合に、その設定情報を運用管理クライアント１０から受け付ける。

そして、システムリソースマネージャ２１は、設定された台数分のサーバを選択し、選択したサーバのＩＰアドレスおよびホスト名の情報を、図２０に示したネットワークブートサーバデータ６９０に登録する。

そして、システムリソースマネージャ２１は、ドメイン管理サーバ５０のシステムリソースドメインマネージャ５１と連携し、ドメイン管理サーバ５０のドメインリソースＤＢ５５に記憶された仮のＯＳを用いて、ＩＰアドレスとホスト名とが割り当てられたサーバのネットワークブートをおこなう。

そして、サーバサブＲＭ５２、リソースマネージャエージェント１１１ａ、および、サーバＲＭエージェント１１２ａが連携することにより、各サーバのＭＡＣアドレス、サーバアーキテクチャ、モデル、状態の情報を収集し、収集した情報をシステムリソースドメインマネージャ５１に送信する。

その後、システムリソースマネージャ２１は、システムリソースドメインマネージャ５１から各サーバのＭＡＣアドレス、サーバアーキテクチャ、モデル、状態の情報を取得して、その情報をシステムリソースＤＢ２６に管理対象サーバデータ７００として記憶する。

続いて、システムリソースマネージャ２１は、管理対象となるストレージ機器の登録をおこなう。ここで、ストレージ機器とは、ＦＣスイッチやＲＡＩＤ装置などの機器である。

具体的には、システムリソースマネージャ２１は、管理対象として登録するストレージのＩＰアドレスの情報が、図７に示した管理サブネットごとにユーザにより入力された場合に、その情報を運用管理クライアント１０から受け付ける。そして、システムリソースマネージャ２１は、ＩＰアドレスに対応するストレージ機器の情報をシステムリソースＤＢ２６に記憶することによりストレージ機器を登録する。

その後、システムリソースマネージャ２１は、図２１の管理対象サーバデータ７００に登録されたサーバをサーバドメインに追加する処理をおこなう。具体的には、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作してサーバとそのサーバを追加するサーバドメインを指定した場合に、そのサーバおよびサーバドメインの情報を運用管理クライアント１０から受け付ける。

そして、システムリソースマネージャ２１は、図２１に示した管理対象サーバデータ７００を参照し、サーバのサーバアーキテクチャが、図９に示したサーバドメインデータ３４０に登録されているサーバアーキテクチャと一致することをチェックする。

また、システムリソースマネージャ２１は、図２１に示した管理対象サーバデータ７００を読み込み、サーバがＳＡＮブートをおこなうように設定されていることをチェックする。

さらに、システムリソースマネージャ２１は、サーバドメインに追加するサーバのネットワークの結線状態をチェックする。具体的には、システムリソースマネージャ２１は、図１８に示したサーバドメイン間リンクデータ６７０を読み込み、サーバドメインに対するフロントサーバドメインおよびバックサーバドメインの情報を取得する。

そして、システムリソースマネージャ２１は、図１４に示したネットワークドメインデータ４８０を読み込み、ネットワークドメインに対応するフロントサブドメインおよびバックサブドメインの情報を取得する。

その後、システムリソースマネージャ２１は、図１３に示したネットワークサブドメインデータ４７０を読み込み、フロントサブドメインおよびバックサブドメインに対応するスイッチを特定する。

そして、システムリソースマネージャ２１は、ネットワークＲＭ２４およびネットワークサブＲＭ５４に対して、サーバとスイッチ間の結線をチェックするよう要求する。さらに、ネットワークＲＭ２４およびネットワークサブＲＭ５４は、ネットワークＲＭエージェント１１４ａにサーバとスイッチとの間の結線をチェックするよう要求し、チェック結果を取得する。

そして、システムリソースマネージャ２１は、サーバとスイッチとの間の結線に問題がない場合、そのサーバに係る情報を図１０で説明したプールグループに対応付けて、以下に説明するプロビジョニング構成データ７１０としてシステムリソースＤＢ２６に記憶する。

図２２は、プールグループに属するサーバの情報を記憶したプロビジョニング構成データ７１０の一例を示す図である。このプロビジョニング構成データ７１０は、サーバ名、プールグループ、サーバグループ、ストレージサブグループ、アクセス可否の情報を記憶する。

サーバ名は、図２１で説明したサーバ名と同様の情報である。プールグループ名は、図１０で説明したプールグループと同様の情報である。サーバグループは、同一のサーバドメインに含まれるサーバを１つまたは複数のグループに分けた場合のグループの識別情報である。この段階では、サーバグループの情報はまだ登録されない。

ストレージサブグループ名は、ストレージドメインに属するストレージを１つまたは複
数のグループに分け、サーバグループに属する各サーバに割り当てた場合に、各サーバに割り当てたグループの識別情報である。この段階では、ストレージサブグループの情報はまだ登録されない。アクセス可否は、サーバによるストレージへのアクセスを許可するか否かを示す情報である。この段階では、アクセス可否の情報はまだ登録されない。

プロビジョニング構成データ７１０にサーバ名およびプールグループ名を登録した後、システムリソースマネージャ２１は、先に登録したストレージ機器をストレージドメインに登録する。

具体的には、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、ストレージドメインとストレージドメインに登録するストレージ機器とを指定した場合に、それらの情報を運用管理クライアント１０から受け付ける。

そして、システムリソースマネージャ２１は、図１９に示したサーバ／ストレージドメイン間リンクデータ６８０を読み込んで、ストレージドメインに対応するサーバドメインを特定する。

さらに、システムリソースマネージャ２１は、ストレージＲＭ２５およびストレージＲＭエージェント１１５ａと連携して、特定されたサーバドメインに属するサーバと、ストレージドメインに属するストレージ機器との間の結線の均一性をチェックする。

図２３は、結線状態が均一であるサーバとストレージ機器との結線の一例を示す図である。図２３に示すように、この例では、ストレージドメイン７４０に属するＦＣ（Fiber
Channel）スイッチ７５０ａ、および、サーバドメイン７２０に属するサーバ７３０ａ，７３０ｂ間の結線状態と、ストレージドメイン７４０に属するＦＣスイッチ７５０ｂ、および、サーバ７３０ａ，７３０ｂ間の結線状態とが均一になっている。

また、ＦＣスイッチ７５０ａ，７５０ｂ、および、ストレージドメイン７４０に属するＲＡＩＤ装置７６０ａ間の結線状態と、ＦＣスイッチ７５０ａ，７５０ｂ、および、ストレージドメイン７４０に属するＲＡＩＤ装置７６０ｂ間の結線状態が均一になっている。

システムリソースマネージャ２１は、上記結線の均一性のチェックをＷＷＰＮ（World Wide Port Name）の情報を基にしておこなう。その際、システムリソースマネージャ２１は、図１１に示したストレージドメインデータ３６０からストレージドメインのパスの多重度の情報を読み込み、冗長度のチェックも併せておこなう。図２４は、ＷＷＰＮに基づく結線の均一性チェック処理を説明する図である。

図２４には、図２３に示したＲＡＩＤ装置７６０ａ，７６０ｂが記憶しているＲＡＩＤ装置ＷＷＰＮデータ７７０ａ，７７０ｂと、ＦＣスイッチ７５０ａ，７５０ｂが記憶しているＦＣスイッチＷＷＰＮデータ７８０ａ，７８０ｂと、サーバ７３０ａ，７３０ｂが記憶しているサーバＷＷＰＮデータ７９０ａ，７９０ｂとが示されている。

ＲＡＩＤ装置ＷＷＰＮデータ７７０ａ，７７０ｂは、ＣＡ（Channel Adapter）およびＷＷＰＮの情報を記憶している。ＣＡは、ＲＡＩＤ装置７６０ａ，７６０ｂが有するチャネルアダプタの識別情報である。ＷＷＰＮは、ＲＡＩＤ装置７６０ａ，７６０ｂが有するチャネルアダプタに割り当てられているＷＷＰＮの情報である。

ＦＣスイッチＷＷＰＮデータ７８０ａ，７８０ｂは、ｐｏｒｔおよび相手先ＷＷＰＮの情報を記憶している。ｐｏｒｔは、ＦＣスイッチ７５０ａ，７５０ｂのポートの識別情報である。相手先ＷＷＰＮは、ＦＣスイッチ７５０ａ，７５０ｂのポートに接続されているＲＡＩＤ装置７６０ａ，７６０ｂのチャネルアダプタに割り当てられているＷＷＰＮの情報、または、ＦＣスイッチ７５０ａ，７５０ｂのポートに接続されているサーバ７３０ａ，７３０ｂのＨＢＡ（Host Bus Adapter）に割り当てられたＷＷＰＮの情報である。

サーバＷＷＰＮデータ７９０ａ，７９０ｂは、ＨＢＡおよびＷＷＰＮの情報を記憶している。ＨＢＡは、サーバ７３０ａ，７３０ｂが有するＨＢＡの識別情報である。ＷＷＰＮは、サーバ７３０ａ，７３０ｂが有するＨＢＡに割り当てられているＷＷＰＮの情報である。

システムリソースマネージャ２１は、ＲＡＩＤ装置ＷＷＰＮデータ７７０ａ，７７０ｂ、ＦＣスイッチＷＷＰＮデータ７８０ａ，７８０ｂ、および、サーバＷＷＰＮデータ７９０ａ，７９０ｂをＲＡＩＤ装置７６０ａ，７６０ｂ、ＦＣスイッチ７５０ａ，７５０ｂ、および、サーバ７３０ａ，７３０ｂから収集し、ＷＷＰＮの対応関係を調べることにより、各装置間の結線状態の均一性をチェックすることができる。

その後、システムリソースマネージャ２１は、あらかじめ設定されているＬＵＮ（Logical Unit）の記憶領域と、ＬＵＮが未設定の記憶領域とをプール用のストレージとして登録する。

続いて、システムリソースマネージャ２１は、サーバグループの作成処理をおこなう（ステップＳ１０４）。以下に、ステップＳ１０４でおこなわれる処理をさらに詳細に説明する。

まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したストレージテンプレートに係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するストレージテンプレートデータ８００として登録する。ここで、ストレージテンプレートとは、後に作成されるサーバグループ用のストレージの構成に係る設定情報である。

図２５は、ストレージテンプレートに係るデータを記憶したストレージテンプレートデータ８００の一例を示す図である。このストレージテンプレートデータ８００は、ストレージテンプレート、ディスク種別、ディスク名、信頼性の必要度、負荷の度合い、ディスク容量およびブートディスクの情報を記憶している。

ストレージテンプレートは、設定されたストレージテンプレートを識別する識別情報である。ディスク種別は、ストレージテンプレートに属するディスクの用途の種別を示す情報である。

たとえば、「ｒｏｏｔ」は、そのディスクがシステムデータを記憶するために利用されることを示し、「ｌｏｃａｌ」は、そのディスクがサーバ個別のデータを記憶するために利用されることを示し、「ｓｈａｒｅｄ」は、そのディスクがサーバ間で共有されるデータを記憶するために利用されることを示す。

ディスク名は、各ディスクに割り当てられたディスクを識別する名称である。信頼性の必要度は、ディスクに必要とされる信頼性の情報である。負荷の度合いは、ディスクにかかる負荷の度合いの情報である。ディスク容量は、ディスクの記憶容量である。ブートディスクは、そのディスクがシステムのブート用に利用されるものか否かを示す情報である。

続いて、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操
作して設定したサーバグループの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバグループデータ８１０として記憶する。

図２６は、サーバグループに係る情報を記憶したサーバグループデータ８１０の一例を示す図である。このサーバグループデータ８１０は、サーバグループ、サーバドメイン、ソフト配布イメージ、版数、ストレージテンプレート、ＳＡＮブートおよび自動リカバリの情報を記憶している。

サーバグループは、同一のサーバドメインに含まれるサーバを１つまたは複数のグループに分けた場合のグループの識別情報である。サーバドメインは、サーバグループが属するサーバドメインの情報である。ソフトウェア配布イメージは、サーバグループに属するサーバに配布するソフトウェアのイメージファイルを識別する情報である。

版数は、ソフトウェア配布イメージの版数の情報である。ストレージテンプレートは、図２５で説明したストレージテンプレートと同様の情報である。ＳＡＮブートは、サーバグループに属するサーバのＳＡＮブートをおこなうか否かを示す情報である。自動リカバリは、複数のサーバが連携して動作するスケールアウト構成のサーバが故障した場合に、自動的にサーバを追加する処理を実行するか否かを示す情報である。

その後、システムリソースマネージャ２１は、システムリソースＤＢ２６に、サーバグループに対応するストレージグループの情報をサーバ／ストレージグループリンクデータ８２０として登録する。ここで、ストレージグループとは、同一のストレージドメインに含まれるストレージを１つまたは複数のグループに分けたものである。

図２７は、サーバグループに対応するストレージグループの情報を記憶したサーバ／ストレージグループリンクデータ８２０の一例を示す図である。このサーバ／ストレージグループリンクデータ８２０は、サーバグループ、ストレージグループおよびストレージドメインの情報を記憶している。

サーバグループは、図２６に示したサーバグループと同様の情報である。ストレージグループは、各サーバグループに対応して生成されたストレージグループの識別情報である。ストレージドメインは、ストレージグループが属するストレージドメインの識別情報である。

ストレージグループを生成する際には、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０から、サーバグループに対応付けられたストレージテンプレートの情報を読み込み、図２５に示したストレージテンプレートデータ８００からストレージテンプレートに対応するディスク種別の情報を読み込む。

そして、システムリソースマネージャ２１は、「ｒｏｏｔ」や「ｌｏｃａｌ」、「ｓｈａｒｅｄ」などのディスク種別ごとに、ストレージグループを各サーバグループに対して生成し、その情報をサーバ／ストレージグループリンクデータ８２０に登録する。

さらに、システムリソースマネージャ２１は、図１９に示したサーバ／ストレージドメイン間リンクデータから、サーバグループが属するサーバドメインに対応するストレージドメインの情報を読み込み、その情報をサーバ／ストレージグループリンクデータ８２０に登録する。

その後、システムリソースマネージャ２１は、サーバグループを追加したことをＡＰ管理部１１６ａに認識させるコマンドをＡＰ管理部１１６ａに送信する。具体的には、シス
テムリソースマネージャ２１は、図８に示した「ｉｓｓｖｇｒｐ ａｄｄ」をＡＰ管理部１１６ａに送信する。

続いて、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサーバグループ間の対応関係の情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバグループ間リンクデータ８３０として登録する。

図２８は、サーバグループ間の対応関係に係る情報を記憶したサーバグループ間リンクデータ８３０の一例を示す図である。このサーバグループ間リンクデータ８３０は、フロントサーバグループ、ネットワークグループおよびバックサーバグループの情報を記憶している。

フロントサーバグループは、ネットワークグループにより連結されるサーバグループのうち、よりインターネット７０側にあるサーバグループを示す情報である。ここで、ネットワークグループとは、サーバグループ間を連結するよう図１６で説明したネットワークサブグループを結合したネットワークのグループである。

ネットワークグループは、上記ネットワークグループを識別する識別情報である。バックサーバグループは、ネットワークグループにより連結されるサーバグループのうち、インターネット７０から遠い側にあるサーバグループを示す情報である。

その後、システムリソースマネージャ２１は、システムリソースＤＢ２６に、ネットワークグループに係る情報を、以下に説明するネットワークグループデータ８５０として記憶する。

具体的には、システムリソースマネージャ２１は、まず、図１８に示したサーバドメイン間リンクデータ６７０を読み込み、２つのサーバドメインに挟まれて設定されているネットワークドメインの情報を取得する。

そして、システムリソースマネージャ２１は、図１４に示したネットワークドメインデータ４８０を読み込み、ネットワークドメインに対応するフロントサブドメイン、バックサブドメインおよび機器の情報を取得する。

さらに、システムリソースマネージャ２１は、図１７に示したネットワークサブグループデータ６６０を読み込み、フロントサブドメイン、および、バックサブドメインに対応するネットワークサブドメインをネットワークサブグループデータ６６０から検索し、検索したネットワークサブドメインに対応するネットワークサブグループのうち、未使用のネットワークサブグループを抽出する。

続いて、システムリソースマネージャ２１は、図１４に示したネットワークドメインデータ４８０から読み込んだ機器の情報に該当するネットワーク機器を１つまたは複数のグループに分けて、システムリソースＤＢ２６にその情報を、以下に説明する負荷分散グループデータ８４０として記憶する。

図２９は、負荷分散装置のグループ情報を記憶した負荷分散グループデータ８４０の一例を示す図である。この負荷分散グループデータ８４０は、負荷分散グループ、ロードバランサ名および代表ＩＰの情報を記憶している。

負荷分散グループは、ロードバランサを１つまたは複数のグループに分けた場合のグループを識別する情報である。ロードバランサ名は、ロードバランサを識別する名称である。代表ＩＰは、各負荷分散グループに割り当てられたＩＰアドレスの情報である。

その後、システムリソースマネージャ２１は、上記各ネットワークグループに属するネットワークドメインやネットワークサブグループ、負荷分散グループなどの構成の情報に基づいて、それらの間の対応関係の情報を生成し、システムリソースＤＢ２６にその情報を、以下に説明するネットワークグループデータ８５０として記憶する。

図３０は、ネットワークグループに係る情報を記憶したネットワークグループデータ８５０の一例を示す図である。このネットワークグループデータ８５０は、ネットワークグループ、ネットワークドメイン、フロントネットワークサブグループ、負荷分散グループおよびバックネットワークサブグループの情報を記憶している。

ネットワークグループは、図２８で説明したネットワークグループと同様の情報である。ネットワークドメインは、図１８で説明したネットワークドメインと同様の情報である。

フロントネットワークサブグループは、図１７で説明したネットワークサブグループに対応するものであり、負荷分散グループを挟むネットワークサブグループのうち、よりインターネット７０側にあるネットワークサブグループを示す情報である。

負荷分散グループは、図２９で説明した負荷分散グループと同様の情報である。バックネットワークサブグループは、図１７で説明したネットワークサブグループに対応するものであり、負荷分散グループを挟むネットワークサブグループのうち、よりインターネット７０から遠い側にあるネットワークサブグループを示す情報である。

さらに、システムリソースマネージャ２１は、ネットワークＲＭ２４およびネットワークサブＲＭ５４と連携し、図１３のネットワークサブドメインデータ４７０に登録されたスイッチに対して、ネットワークサブグループのＶＬＡＮの設定をおこなう。

続いて、システムリソースマネージャ２１は、サーバグループに一台目のサーバを追加して、そのサーバに導入されたソフトウェアのソフトウェアイメージを作成する処理をおこなう（ステップＳ１０５）。以下に、ステップＳ１０５でおこなわれる処理をさらに詳細に説明する。

まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、サーバとそのサーバを登録するサーバグループを指定した場合に、サーバおよびサーバグループの情報を受け付け、サーバグループにサーバを登録する。

そして、システムリソースマネージャ２１は、図２６のサーバグループデータ８１０を読み込んでサーバグループに対応するストレージテンプレートを検索し、そのストレージテンプレートの設定条件を図２５のストレージテンプレートデータ８００から取得する。

さらに、ストレージＲＭ２５は、システムリソースマネージャ２１により取得されたストレージテンプレートの設定条件を満足するようプールされたストレージに論理ボリュームを設定し、論理ボリュームが設定されたストレージを上記サーバグループに割り当てる処理をおこなう。

図３１は、論理ボリュームをＲＡＩＤ装置に設定する設定処理の処理手順を示すフローチャートである。図３１に示すように、まず、システムリソースマネージャ２１は、論理ボリュームの必要条件の情報を取得する（ステップＳ２０１）。ここで、論理ボリューム
の必要条件とは、図２５のストレージテンプレートデータ８００に記憶された信頼性の必要度、負荷の度合い、および、ディスク容量の情報である。

図３２は、論理ボリュームの設定画面の一例を示す図である。図３２には、システムリソースマネージャ２１が、運用管理クライアント１０に対して出力する論理ボリュームの必要条件を表示した必要条件出力画面８６０と、論理ボリューム設定後の論理ボリューム構成出力画面８８０とが示されている。

図３２の例では、３つの必要条件を満足する３つの論理ボリュームを作成するよう要求された場合が示されている。そして、必要条件出力画面８６０には、３つの必要条件８７０ａ〜８７０ｃが出力される。

図３１の説明に戻ると、システムリソースマネージャ２１は、信頼性の必要度および負荷の度合いに応じて、ＲＡＩＤ装置のＲＡＩＤレベルを決定する（ステップＳ２０２）。図３３は、ＲＡＩＤレベルの設定情報を記憶したＲＡＩＤレベル設定データ９４０の一例を示す図である。

このＲＡＩＤレベル設定データ９４０は、信頼性の必要度、負荷の度合いおよびＲＡＩＤレベルの情報を記憶している。信頼性の必要度は、図２５で説明した信頼性の必要度と同様の情報である。負荷の度合いは、図２５で説明した負荷の度合いと同様の情報である。ＲＡＩＤレベルは、信頼性の必要度および負荷の度合いにより決定されるＲＡＩＤレベルの情報である。

図３１の説明に戻ると、システムリソースマネージャ２１は、必要とされるディスク容量の合計値から、ＲＡＩＤ装置種を決定する（ステップＳ２０３）。図３４は、ＲＡＩＤ装置に係る情報を記憶したＲＡＩＤ装置データ９５０の一例を示す図である。

このＲＡＩＤ装置データ９５０は、必要な記憶容量合計値、ＲＡＩＤ装置の型名、データアクセススピード、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）およびＲＡＩＤグループの最大数の情報を記憶している。

必要な記憶容量合計値は、論理ボリュームに必要とされるディスク容量の合計値の情報である。ＲＡＩＤ装置の型名は、必要な記憶容量合計値を確保するのに適したＲＡＩＤ装置の型名の情報である。

データアクセススピードは、ＲＡＩＤ装置の型名により特定されるディスクドライブのデータのアクセススピードの情報である。このデータアクセススピードには、アクセススピードが速い順に、「一番目」、「二番目」、「三番目」の３つのディスクドライブ種の情報が記憶されている。

ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）は、ＲＡＩＤレベルがＲＡＩＤ０＋１の場合において、ＲＡＩＤグループを構成するディスクドライブの数の情報である。ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）は、ＲＡＩＤレベルがＲＡＩＤ５の場合において、ＲＡＩＤグループを構成するディスクドライブの数の情報である。ＲＡＩＤグループの最大数は、作成するＲＡＩＤグループの最大数の情報である。

図３１の説明に戻ると、システムリソースマネージャ２１は、図３４で説明したＲＡＩＤ装置データ９５０から、ＲＡＩＤ装置種ごとの特有情報を取得する（ステップＳ２０４）。

ここで、特有情報とは、データアクセススピードのうち、「一番目」に該当するディスクドライブ種、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）およびＲＡＩＤグループの最大数の情報である。

そして、ストレージＲＭ２５は、論理ボリュームを作成する（ステップＳ２０５）。具体的には、ストレージＲＭ２５は、論理ボリュームの各必要条件を満足する論理ボリュームを作成し、ＲＡＩＤ装置に論理ボリュームを設定する。

図３２に示した論理ボリューム構成出力画面８８０には、各必要条件９００ａ〜９００ｃを満足する論理ボリューム９１０ａ〜９１０ｄ，９２０ａ〜９２０ｅが、ＲＡＩＤ装置８９０に設定された状況が示されている。

図３１の説明に戻ると、ストレージＲＭ２５は、ＲＡＩＤレベルが同一である論理ボリュームをグループ化したＲＡＩＤグループを作成する（ステップＳ２０６）。そして、ストレージＲＭ２５は、作成したＲＡＩＤグループに論理ボリュームを割り当てる（ステップＳ２０７）。

図３２の例では、必要条件９００ａおよび必要条件９００ｂを満足する論理ボリューム９１０ａ〜９１０ｄは、ＲＡＩＤレベルがＲＡＩＤ０＋１で同じであるので、ＲＡＩＤグループ９３０ａにグループ化されている。また、必要条件９００ｃを満足する論理ボリューム９２０ａ〜９２０ｅは、ＲＡＩＤレベルがＲＡＩＤ５であるので、ＲＡＩＤグループ９３０ｂとしてグループ化されている。

ＲＡＩＤグループを作成する際には、ストレージＲＭ２５は、各ＲＡＩＤグループに属するディスクドライブを、図３４のＲＡＩＤ装置データ９５０のデータアクセススピードにより決定されるディスクドライブ種に設定する。

また、ストレージＲＭ２５は、ＲＡＩＤグループを構成するディスクドライブ数を、図３４のＲＡＩＤ装置データ９５０のＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）、または、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）により決定されるディスクドライブ数に設定する。

さらに、ストレージＲＭ２５は、ＲＡＩＤグループの数が図３４のＲＡＩＤ装置データ９５０のＲＡＩＤグループの最大数以下になるようＲＡＩＤグループを作成する。

図３２の論理ボリューム構成出力画面８８０では、必要条件９００ａ〜９００ｃを満足し、各ＲＡＩＤグループ９３０，９４０に割り当てられた論理ボリューム９１０ａ〜９１０ｄ，９２０ａ〜９２０ｅが、対応する必要条件９００ａ〜９００ｃと線で結合されて表示されている。

図３１の説明に戻ると、ストレージＲＭ２５は、図３２に示した論理ボリュームの構成をＲＡＩＤ装置に反映させるコマンドファイルを作成する（ステップＳ２０８）。そして、ストレージＲＭ２５は、そのコマンドファイルに基づいて、作成した論理ボリュームを実装置に反映させる（ステップＳ２０９）。

その後、システムリソースマネージャ２１は、各サーバが属するサーバグループに対応付けて、ＲＡＩＤ装置に設定された論理ボリュームをストレージサブグループとして登録し、サーバのストレージグループに対するアクセス権を設定する。具体的には、システムリソースマネージャ２１は、図２２に示したプロビジョニング構成データ７１０にサーバグループ、ストレージサブグループおよびアクセス可否の情報を記憶する。

図３５は、ストレージサブグループが設定されたプロビジョニング構成データ９６０の一例を示す図である。このプロビジョニング構成データ９６０には、図２２に示したプロビジョニング構成データ７１０にサーバグループ、ストレージサブグループおよびアクセス可否の情報が追加されている。

ＲＡＩＤ装置に構築された論理ボリュームをサーバに認識させ、ストレージサブグループとして登録する場合には、ストレージＲＭ２５は、以下のような手順で論理ボリュームの設定をおこなう。

図３６は、サーバに論理ボリュームを認識させる論理ボリュームの設定処理の処理手順を示すフローチャートである。図３６に示すように、まず、ストレージＲＭ２５は、ＲＡＩＤ装置の論理ボリュームをグループ化し、アフィニティグループを設定する（ステップＳ３０１）。

ここで、アフィニティグループとは、サーバが認識する論理ユニット番号（ＬＵＮ， Logical Unit Number）とＲＡＩＤ装置における論理ボリューム（ＬＶ， Logical Volume）番号との間の対応関係を示す情報である。

図３７は、ＲＡＩＤ装置に構築された論理ボリュームの設定処理を説明する説明図である。図３７には、サーバＡおよびサーバＢから構成されるサーバグループ９７０と、論理ボリュームＬＶ０、ＬＶ１、ＬＶ２、ＬＶ３が構築されたＲＡＩＤ装置α、および、論理ボリュームＬＶ１０、ＬＶ１１、ＬＶ１２、ＬＶ１３が構築されたＲＡＩＤ装置βから構成されるストレージプール９８０とが示されている。

さらに、図３７には、ストレージプール９８０からＲＡＩＤ装置αの論理ボリュームＬＶ０およびＬＶ１と、ＲＡＩＤ装置βの論理ボリュームＬＶ１２およびＬＶ１３とが追加されたストレージグループ９９０が示されている。

ストレージグループ９９０に追加されたＲＡＩＤ装置αの論理ボリュームＬＶ０およびＬＶ１は、アフィニティグループ０およびアフィニティグループ１に属するように設定されている。また、ＲＡＩＤ装置βの論理ボリュームＬＶ１２およびＬＶ１３は、アフィニティグループ１０およびアフィニティグループ１１に属するように設定されている。

図３８は、アフィニティグループに係る情報を記憶したアフィニティグループデータ１０１０の一例を示す図である。このアフィニティグループデータ１０１０は、ＲＡＩＤ装置名、アフィニティグループ名、ＬＵＮおよびＬＶの情報を記憶している。

ＲＡＩＤ装置は、各ＲＡＩＤ装置を識別する識別情報である。アフィニティグループは、各ＲＡＩＤ装置において設定されたアフィニティグループの情報である。ＬＵＮは、サーバＡまたはサーバＢからアクセスする際に論理ボリュームを識別する識別情報である。ＬＶは、論理ボリュームを識別する識別情報である。

図３６の説明に戻ると、ストレージＲＭ２５は、サーバＡおよびサーバＢと、論理ボリュームＬＶ０，ＬＶ１，ＬＶ１２，ＬＶ１３との間の冗長パスをチェックし、パスを選択することによりアクセスパスを設定する（ステップＳ３０２）。

そして、ストレージＲＭ２５は、論理ユニットに対するマルチパスの設定をおこなう（ステップＳ３０３）。図３９は、マルチパスの構成に係る情報を記憶したマルチパス構成データ１０２０の一例を示す図である。

このマルチパス構成データ１０２０は、マルチパスインスタンスおよびＬＵＮの情報を記憶している。マルチパスインスタンスは、設定されたマルチパスのインスタンスを識別する情報である。ＬＵＮは、設定されたマルチパスインスタンスに対応し、サーバＡまたはサーバＢにより認識される論理ユニットを識別する情報である。

そして、ストレージＲＭ２５は、設定したマルチパスインスタンスをミラーボリュームの構成要素としてクラスタリングをおこなうサーバのクラスタリソースに登録する（ステップＳ３０４）。その後、ストレージＲＭ２５は、クラスタリソースに登録されたマルチパスインスタンスを用いて異なるＲＡＩＤ装置のボリュームどうしをペアとするミラーボリュームグループを設定する（ステップＳ３０５）。

図３７には、サーバ「Ａ」またはサーバ「Ｂ」において内部設定されるサーバ内ストレージ構成１０００が示されている。このストレージ構成１０００においては、マルチパスインスタンスｍｐｌｂ０およびマルチパスインスタンスｍｐｌｂ２とから構成されるミラーボリュームＭ０と、マルチパスインスタンスｍｐｌｂ１およびマルチパスインスタンスｍｐｌｂ３とから構成されるミラーボリュームＭ１とが設定されている。

図４０は、ミラーボリュームの構成に係る情報を記憶したミラーボリューム構成データ１０３０の一例を示す図である。このミラーボリューム構成データ１０３０は、ミラーボリュームおよび構成ディスクの情報を記憶している。

ミラーボリュームは、設定されたミラーボリュームを識別する識別情報である。構成ディスクは、ミラーボリュームを構成する論理ユニットを識別する識別情報である。ここで、構成ディスクには、図３９に示したマルチパス構成データ１０２０におけるマルチパスインスタンスの情報が記憶されているが、マルチパス構成データ１０２０を参照することにより、ミラーボリュームに対応するＬＵＮを特定することができる。

図３８に示したアフィニティグループデータ１０１０は、ストレージＲＭ２５によりシステムリソースＤＢ２６およびＲＡＩＤ装置内に記憶される。また、図３９に示したマルチパス構成データ１０２０、および、図４０に示したミラーボリューム構成データ１０３０は、ストレージＲＭ２５によりシステムリソースＤＢ２６に記憶されるとともに、ストレージＲＭエージェント１１５ａにより管理対象であるサーバ内に記憶される。

図４に示すステップＳ１０５におけるソフトウェアイメージの作成処理の説明に戻ると、ネットワークＲＭ２４は、サーバグループに登録したサーバのネットワークの設定をつぎにおこなう。

具体的には、ネットワークＲＭ２４は、図２８に示したサーバグループ間リンクデータ８３０から、サーバを追加したサーバグループをフロントサーバグループおよびバックサーバグループとして有するネットワークグループの情報を読み込む。

さらに、ネットワークＲＭ２４は、図３０に示したネットワークグループデータ８５０を読み込み、ネットワークグループに対応するフロントネットワークサブグループおよびバックネットワークサブグループを抽出する。

その後、ネットワークＲＭ２４は、図１７に示したネットワークサブグループデータ６
６０を読み込み、フロントネットワークサブグループおよびバックネットワークサブグループに対応するネットワークサブグループを検索し、ネットワークサブグループに割り当てられたサブネットの情報を基にして、サーバにＩＰアドレスを割り当てる。

図４１は、サーバに割り当てられたＩＰアドレスに係る情報を記憶したＩＰアドレス管理データ１０４０の一例を示す図である。このＩＰアドレス管理データ１０４０は、システムリソースマネージャ２１により、システムリソースＤＢ２６に記憶される。

このＩＰアドレス管理データ１０４０は、ＩＰアドレスおよび割当先の情報を記憶している。ＩＰアドレスは、サーバに割り当てられたＩＰアドレスの情報である。割当先は、ＩＰアドレスの割当先であるサーバを識別する情報である。

続いて、ネットワークＲＭ２４は、図２９に示した負荷分散グループデータ８４０および図３０に示したネットワークグループデータ８５０を基にして、サーバが追加されたサーバグループに対応するネットワークグループに代表ＩＰアドレスを有する負荷分散グループを割り当てる。なお、この時点では、ロードバランサの負荷分散機能は停止状態にある。

その後、ユーザは、サーバに導入するＯＳなどのソフトウェアを、サーバグループに追加するサーバに対応付けられたストレージサブグループにインストールする。このストレージサブグループは、ＳＡＮの技術を用いて構成されたものである。

そして、インストールの終了後、ソフトウェアサブＲＭ５３は、ソフトウェアＲＭ２３およびソフトウェアＲＭエージェント１１３ａと連携して、ＯＳ、デバイスドライバ、アプリケーションソフトウェアなどのソフトウェアの集合体から構成されるソフトウェアイメージを作成し、作成したソフトウェアイメージをドメインリソースＤＢ５５に記憶する。

具体的には、ソフトウェアＲＭ２３は、図８に示したミドルウェア連携ＩＦデータ３３０を読み込み、ソフトウェアＲＭエージェント１１３ａは、ミドルウェアにより実現される機能部であるＡＰ管理部１１６ａに対して、ソフトウェアイメージ採取前に実行が必要なコマンドを送信する。

すなわち、ソフトウェアＲＭエージェント１１３ａは、ＡＰ管理部１１６ａの機能を停止させるコマンドを送信し、ＡＰ管理部１１６ａの機能を停止させる。そして、ソフトウェアサブＲＭ５３は、サーバのシステムをシャットダウンする。さらに、ソフトウェアサブＲＭ５３は、サーバのドメイン管理サーバ５０のドメインリソースＤＢ５５に記憶された仮のＯＳを用いてサーバのネットワークブートをおこなう。

その後、ソフトウェアサブＲＭ５３は、起動したサーバに導入されているソフトウェアのソフトウェアイメージを作成する。そして、ソフトウェアＲＭ２３は、システムリソースＤＢ２６にソフトウェアイメージに係る情報を、以下に説明するソフトウェアイメージ管理データ１０５０として登録する。

図４２は、ソフトウェアイメージに係る情報を記憶したソフトウェアイメージ管理データ１０５０の一例を示す図である。このソフトウェアイメージ管理データ１０５０は、ソフトウェアイメージ名、形式、ＯＳ属性およびソフトウェア名の情報を記憶している。

ソフトウェアイメージ名は、ソフトウェアイメージの名称である。形式は、ソフトウェアイメージがアーカイブ形式で作成されたものであるのか、パッチ形式で作成されたもの
であるのかを示す情報である。ＯＳ属性は、ソフトウェアイメージが、ＯＳのソフトウェアイメージであるか否かを示す情報である。ソフトウェア名は、ソフトウェアイメージが作成されたソフトウェアの名称である。

さらに、ソフトウェアサブＲＭ５３は、作成したソフトウェアイメージを基にして、他のサーバ用に配布するソフトウェア配布イメージを作成する。具体的には、ソフトウェアサブＲＭ５３は、一台目のサーバ用にストレージに導入された複数のソフトウェアのソフトウェアイメージを組にしたソフトウェア配布イメージを作成する。

そして、システムリソースマネージャ２１は、システムリソースＤＢ２６にソフトウェア配布イメージに係る情報を、以下に説明するソフトウェア配布イメージ管理データ１０６０として記憶する。

図４３は、ソフトウェア配布イメージに係る情報を記憶したソフトウェア配布イメージ管理データ１０６０の一例を示す図である。このソフトウェア配布イメージ管理データ１０６０は、ソフトウェア配布イメージ名、版数、サーバアーキテクチャおよびソフトウェアイメージ／スナップショットの情報を記憶している。

ソフトウェア配布イメージ名は、ソフトウェア配布イメージの名称である。版数は、ソフトウェア配布イメージの版数である。サーバアーキテクチャは、ソフトウェア配布イメージの配布対象となるサーバのＣＰＵアーキテクチャである。ソフトウェアイメージ／スナップショットは、ソフトウェア配布イメージに含まれるソフトウェアイメージまたはスナップショットを示す情報である。

ここでスナップショットとは、ある特定の時点でサーバに導入されているソフトウェアのソフトウェアイメージである。システムリソースマネージャ２１は、システムリソースＤＢ２６にスナップショットに係る情報を、以下に説明するスナップショット管理データ１０７０として登録する。

図４４は、スナップショットに係る情報を記憶したスナップショット管理データ１０７０の一例を示す図である。このスナップショット管理データ１０７０は、スナップショット名およびソフトウェアイメージの情報を記憶している。スナップショット名は、スナップショットの名称である。ソフトウェアイメージは、スナップショットに含まれるソフトウェアイメージの情報である。

その後、ソフトウェアＲＭ２３は、図８に示したミドルウェア連携ＩＦデータ３３０を読み込み、ソフトウェアＲＭエージェント１１３ａは、ミドルウェアにより実現される機能部であるＡＰ管理部１１６ａに対して、ソフトウェアイメージ採取後に実行が必要なコマンドを送信する。

具体的には、ソフトウェアＲＭエージェント１１３ａは、停止していたＡＰ管理部１１６ａを始動させるコマンドを送信し、ＡＰ管理部１１６ａを始動させる。そして、ネットワークＲＭ２４は、スイッチにＶＬＡＮの設定をおこなってサーバをＶＬＡＮに接続するとともに、ロードバランサの負荷分散機能を始動させ、負荷を分散させる対象サーバとして当該サーバを割り当てる。

その後、システムリソースマネージャ２１は、図８に示したミドルウェア連携ＩＦデータ３３０を読み込み、ミドルウェアにより実現される機能部であるＡＰ管理統括部２７に対して、サーバグループ作成後に実行が必要なコマンドを送信する。

具体的には、システムリソースマネージャ２１はＡＰ管理統括部２７に対して、サーバグループの追加を認識させるコマンドを送信する。そして、ＡＰ管理統括部２７は、ＡＰ管理部１１６ａと連携して、サーバに対してアプリケーションプログラムの導入および設定などをおこない、サーバを業務で利用可能な状態に設定する。

図４の説明に戻ると、システムリソースマネージャ２１は、二台目以降のサーバをサーバグループに追加する処理をおこなう（ステップＳ１０６）。以下に、ステップＳ１０６でおこなわれる処理をさらに詳細に説明する。

図４５は、サーバをサーバグループに追加する処理の処理手順を示すフローチャートである。図４５に示すように、まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、サーバとそのサーバを登録するサーバグループを指定した場合に、サーバおよびサーバグループの情報を受け付ける（ステップＳ４０１）。

そして、システムリソースマネージャ２１は、サーバグループにサーバを登録する（ステップＳ４０２）。続いて、システムリソースマネージャ２１は、図２１に示した管理対象サーバデータ７００および図４３に示したソフトウェア配布イメージ管理データ１０６０を読み込んで、サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものか否かを調べる（ステップＳ４０３）。サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものでない場合には（ステップＳ４０３，Ｎｏ）、当該サーバのサーバグループへの追加処理を終了する。

サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものである場合には（ステップＳ４０３，Ｙｅｓ）、ストレージＲＭ２５は、一台目のサーバにストレージを設定した場合と同様の方法で、サーバに対してストレージを設定する処理をおこなう（ステップＳ４０４）。具体的には、ストレージＲＭ２５は、図３１および図３６で説明した論理ボリュームの設定処理を当該サーバに対して実行する。

続いて、ネットワークＲＭ２４は、一台目のサーバにネットワークを設定した場合と同様の方法で、サーバグループに登録したサーバのネットワークブートを仮のＯＳを用いておこない、サーバのネットワークの設定をおこなう（ステップＳ４０５）。

その後、ソフトウェアサブＲＭ５３は、一台目のサーバに導入されたソフトウェアから作成されたソフトウェア配布イメージを二台目のサーバに対応付けられたストレージサブグループに展開し、展開されたソフトウェアを用いてサーバを再起動させる（ステップＳ４０６）。

ソフトウェア配布イメージをサーバに対応付けられたストレージサブグループに展開した場合には、ソフトウェアＲＭ２３は、システムリソースＤＢ２６に、配布したソフトウェア配布イメージに係る情報を記憶する。

図４６は、ソフトウェア配布イメージの配布状況に係る情報を記憶した配布管理データ１０８０の一例を示す図である。この配布管理データ１０８０は、サーバ、ストレージサブグループ、ソフトウェア配布イメージ、版数および状態の情報を記憶している。

サーバは、ストレージサブグループが割当てられているサーバを識別する情報である。ストレージサブグループは、ソフトウェア配布イメージが展開されるストレージサブグループを識別する情報である。ソフトウェア配布イメージは、ストレージサブグループに展開されたソフトウェア配布イメージの情報である。状態は、ソフトウェア配布イメージの配布状況を示す情報である。

図４５の説明に戻ると、システムリソースマネージャ２１は、ネットワークＲＭ２４およびＡＰ管理統括部２７と連携して、二台目のサーバを業務モードに移行させる処理をおこなう（ステップＳ４０７）。

具体的には、ネットワークＲＭ２４は、サーバの再起動時に、一台目のサーバが属するサブネットの情報に基づいて、二台目のサーバにＩＰアドレスを割り当てる。二台目のサーバに割り当てられたＩＰアドレスの情報は、システムリソースマネージャ２１により、図４１に示したＩＰアドレス管理データ１０４０に記憶される。

続いて、ネットワークＲＭ２４は、スイッチにＶＬＡＮの設定をおこなってサーバをＶＬＡＮに接続するとともに、ロードバランサに対して、負荷を分散させる対象サーバとして当該サーバを登録させる。

その後、システムリソースマネージャ２１は、ＡＰ管理統括部２７に対して、サーバのサーバグループの追加をＡＰ管理統括部２７に認識させるコマンドを送信する。そして、ＡＰ管理統括部２７は、ＡＰ管理部１１６ａと連携して、サーバに対してアプリケーションプログラムの導入および設定などをおこない、サーバを業務で利用可能な状態に設定する。

三台目以降のサーバをサーバグループに追加する場合には、図４５で説明したサーバの追加処理を繰り返す。

つぎに、サーバグループに追加されたサーバをサーバグループから削除する処理について説明する。図４７は、サーバグループからサーバを削除するサーバ削除処理の処理手順を説明するフローチャートである。

図４７に示すように、まず、ネットワークＲＭ２４は、ネットワークサブＲＭ５４と連携して、サーバに設定されたＶＬＡＮを切断する（ステップＳ５０１）。そして、ネットワークＲＭ２４は、ネットワークサブＲＭ５４と連携して、ロードバランサの設定を変更し、負荷を分散させる対象サーバから当該サーバを除外する（ステップＳ５０２）。

続いて、ネットワークＲＭ２４は、サーバに割り当てられたＩＰアドレスを返却する（ステップＳ５０３）。さらに、ソフトウェアサブＲＭ５３は、ドメイン管理サーバ５０のドメインリソースＤＢ５５に記憶された仮のＯＳを用いて、ネットワークブートによりサーバの再起動をおこなう（ステップＳ５０４）。

そして、ストレージＲＭ２５は、サーバグループから削除するサーバに割り当てられたディスクを削除する（ステップＳ５０５）。その後、ストレージＲＭ２５は、サーバに対して設定されたサーバとストレージとの間の論理的な接続関係であるＳＡＮゾーニングを変更し、当該サーバを除外したサーバとストレージとの間のＳＡＮゾーニングを設定する（ステップＳ５０６）。

つぎに、サーバ異常時や高負荷時に、サーバ資源の追加を高速で行うため、プール内のサーバにソフトウェアおよびネットワークなどの情報を事前に設定する処理について説明する。

図４８は、プール内のサーバにソフトウェアおよびネットワークなどの情報を事前に設定する処理手順を示すフローチャートである。図４８に示すように、システムリソースマネージャ２１は、追加するサーバおよび追加対象となるサーバグループの情報を運用管理クライアント１０から受付け、サーバを対応するサーバグループに移行する（登録する）（ステップＳ６０１）。

そして、システムリソースマネージャ２１は、図２７に示したサーバ／ストレージグループリンクデータ８２０を読み込んで、サーバグループのストレージグループの情報を取得し（ステップＳ６０２）、取得したストレージグループの情報を基にストレージサブグループ名を作成し、作成したストレージサブグループ名を図３５に示したプロビジョニング構成データ９６０に登録する（ステップＳ６０３）。

続いて、システムリソースマネージャ２１は、図４６に示した配布管理データ１０８０を読み込んで、追加するサーバに配信されているソフトウェアの情報を取得する（ステップＳ６０４）。そして、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０を読み込んで、追加するサーバに配信すべきソフトウェアを判別し（ステップＳ６０５）、判別したソフトウェアを、ソフトウェアＲＭ２３が、追加するサーバにインストールし（ステップＳ６０６）、図４６に示した配布管理データ１０８０を更新する（ステップＳ６０７）。

そして、ネットワークＲＭ２４が、サーバのネットワーク設定を行い（ステップＳ６０８）、サーバＲＭ２２が、サーバを起動させ（ステップＳ６０９）、システムリソースマネージャ２１はサーバをプールに移行する（ステップＳ６１０）。

そして、サーバＲＭ２２が、サーバを停止させ（ステップＳ６１１）、ネットワークＲＭがサーバをネットワークらから切り離し（ステップＳ６１２）、サーバを次のサーバグループに移行させる場合には（ステップＳ６１３，ＹＥＳ）、システムリソースマネージャ２１はサーバを次のサーバグループに移行させ（ステップＳ６１４）、ステップＳ６０２に移行する。一方、サーバを次のサーバグループに移行させない場合には（ステップＳ６１３，Ｎｏ）、処理を終了する。

つぎに、図４８で示したフローチャートを具体的に説明する。図４９は、プール内のサーバにソフトウェアおよびネットワークなどの情報を事前に設定する処理手順を具体的に示すフローチャートである。なお、図４９では一例として、追加するサーバのサーバ名を「host５」、追加対象となるサーバグループを「A_Web」および「B_Web」とする。

図４９に示すように、システムリソースマネージャ２１は、追加するサーバ（以下、図４９の説明において、追加するサーバをhost５と表記する）および追加対象となるサーバグループA_Webの情報を運用管理クライアント１０から受付け、host５をサーバグループA_Webに移行する（登録する）（ステップＳ７０１）。

そして、システムリソースマネージャ２１は、図２７に示したサーバ／ストレージグループリンクデータ８２０を読み込んで、サーバグループA_Webのストレージグループの情報を取得（サーバグループA_Webの起動用のストレージグループがA_Web_rootdiskである旨の情報を取得）し（ステップＳ７０２）、取得したストレージグループの情報を基に、ストレージサブグループ名「A_Web_rootdisk_host5」を作成し、作成したストレージサブグループ名を図３５に示したプロビジョニング構成データ９６０に登録する（ステップＳ７０３）。

続いて、システムリソースマネージャ２１は、図４６に示した配布管理データ１０８０を読み込んで、host５に配信されているソフトウェアの情報を取得する（図４６に示した配布管理データ１０８０は、配信後のものであり、この時点では、host５には何も配信されていない）（ステップＳ７０４）。

そして、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０を読み込んで、host５に配信すべきソフトウェア「A_OS_Web_image 版数1.0」を判別し（ステップＳ７０５）、図４３に示したソフトウェア配布イメージ管理データ１０６０を基に、判別したソフトウェア「A_OS_Web_image 版数1.0」に対応するソフトイメージ「apimg_snap_1」を、ソフトウェアＲＭ２３が、host５にインストールし（ステップＳ７０６）、図４６に示した配布管理データ１０８０を更新する（ステップＳ７０７）。

そして、ネットワークＲＭ２４が、host５のネットワーク設定を行い（ステップＳ７０８）、サーバＲＭ２２が、host５を起動させ（ステップＳ７０９）、システムリソースマネージャ２１はhost５をプールに移行する（ステップＳ７１０）。

そして、サーバＲＭ２２が、host５を停止させ（ステップＳ７１１）、ネットワークＲＭ２４がhost５をネットワークらから切り離し（ステップＳ７１２）、システムリソースマネージャ２１が、host５をサーバグループB_Webに移行する（ステップＳ７１３）。

そして、システムリソースマネージャ２１は、図２７に示したサーバ／ストレージグループリンクデータ８２０を読み込んで、サーバグループB_Webのストレージグループの情報を取得（サーバグループB_Webの起動用のストレージグループがB_Web_rootdiskである旨の情報を取得）し（ステップＳ７１４）、取得したストレージグループの情報を基に、ストレージサブグループ名「B_Web_rootdisk host5」を作成し、作成したストレージサブグループ名を図３５に示したプロビジョニング構成データ９６０に登録する（ステップＳ７１５）。

続いて、システムリソースマネージャ２１は、図４６に示した配布管理データ１０８０を読み込んで、host５に配信されているソフトウェアの情報を取得する（ステップＳ７１６）。

そして、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０を読み込んで、host５に配信すべきソフトウェア「B_OS_Web_image 版数1.1」を判別し（ステップＳ７１７）、図４３に示したソフトウェア配布イメージ管理データ１０６０を基に、判別したソフトウェア「B_OS_Web_image 版数1.1」に対応するソフトイメージ「B_OSServer，A_Software_W」を、ソフトウェアＲＭ２３が、host５にインストールし（ステップＳ７１８）、図４６に示した配布管理データ１０８０を更新する（ステップＳ７１９）。

そして、ネットワークＲＭ２４が、host５のネットワーク設定を行い（ステップＳ７２０）、サーバＲＭ２２が、host５を起動させ（ステップＳ７２１）、システムリソースマネージャ２１はhost５をプールに移行し（ステップＳ７２２）、サーバＲＭ２２が、host５を停止させ（ステップＳ７２３）、ネットワークＲＭ２４がhost５をネットワークらから切り離す（ステップＳ７２４）。

つぎに、サーバ異常時や高負荷時に、サーバ資源を追加する処理について説明する。図５０は、サーバ異常時や高負荷時に、サーバ資源を追加する処理手順を示すフローチャートである。システムリソースマネージャ２１が、サーバグループの負荷が所定値を上回った旨の情報を受付け（ステップＳ８０１）、追加するサーバを対応するサーバグループに移行する（ステップＳ８０２）。

そして、システムリソースマネージャ２１は、図２７に示したサーバ／ストレージグループリンクデータ８２０を読み込み、サーバグループのストレージグループの情報を取得
し（ステップＳ８０３）、図４６に示した配布管理データ１０８０を読み込んで、追加するサーバに配信されているソフトウェアの情報を取得する（ステップＳ８０４）。

そして、図２６に示したサーバグループデータ８１０を読み込んで、対応するサーバグループのソフトウェアが更新されている場合には（ステップＳ８０５）、ネットワークＲＭ２４は、ロードバランサのサーバへの振り分けを停止させ（ステップＳ８０６）、ソフトウェアＲＭ２３が、パッチを適応し（ステップＳ８０７）、ネットワークＲＭ２４がサーバをネットワークに接続する（ステップＳ８０８）。一方、ソフトウェアが更新されていない場合には（ステップＳ８０５，Ｎｏ）、そのままステップＳ８０８に移行する。

そして、ネットワークＲＭ２４は、ロードバランサのサーバへの振り分けを再開させ（ステップＳ８０９）、サーバＲＭ２２は、サーバを起動させる（ステップＳ８１０）。なお、図５０では、一例としてシステムリソースマネージャ２１が、サーバグループの負荷が所定値を上回った旨の情報を受付けた場合に、サーバ資源をサーバグループに追加する処理を示したが、サーバが故障した場合や、運用管理クライアント１０からサーバを移行する旨の命令を受付けた場合にも同様の処理を行う。

つぎに、図５０に示したサーバ異常時や高負荷時に、サーバ資源を追加する処理を具体的に説明する。図５１は、サーバ異常時や高負荷時に、サーバ資源を追加する処理手順を具体的に示すフローチャートである。なお、図５１では一例として、サーバグループA_Webに高負荷がかかり、サーバ（サーバ名をhost５とする）を追加する場合を示す。

図５１に示すように、システムリソースマネージャ２１が、サーバグループA_Webの負荷が所定値を上回った旨の情報を受付け（ステップＳ９０１）、host５をサーバグループA_Webに移行する（ステップＳ９０２）。

そして、システムリソースマネージャ２１は、図２７に示したサーバ／ストレージグループリンクデータ８２０を読み込み、サーバグループのストレージグループの情報を取得（サーバグループA_Webの起動用のストレージグループがA_Web_rootdiskである旨の情報を取得）し（ステップＳ９０３）、図４６に示した配布管理データ１０８０を読み込んで、host５に配信されているソフトウェアの情報を取得（host５にA_OS_Web_imaga 版数1.0が配信されている旨の情報を取得）する（ステップＳ９０４）。

そして、サーバグループデータ８１０を読み込んで、サーバグループA_Webのソフトウェアの情報を取得する（このフローチャートでは、サーバグループA_WebのソフトウェアがA_OS_Web_image 版数1.1である旨を取得した場合を示す）（ステップＳ９０５）。

サーバグループA_Webのソフトウェアが版数1.0から版数1.1に更新されているため、ネットワークＲＭ２４は、ロードバランサのhost５への振り分けを停止させ（ステップＳ９０６）、システムリソースマネージャ２１が、図４３に示したソフトウェア配布イメージ管理データ１０６０を読み込み、ソフトウェアＲＭ２３が、「patch_a」をhost５に適応する（ステップＳ９０７）。

そして、ネットワークＲＭ２４がhost５をネットワークに接続し（ステップＳ９０８）、ロードバランサのサーバへの振り分けを再開させ（ステップＳ９０９）、サーバＲＭ２２は、サーバを起動させる（ステップＳ９１０）。

このように、プール内のサーバに対して予め、追加対象となるサーバグループに対応するソフトウェアやネットワーク設定などを行っているため、サーバ異常時や高負荷時に、プール内のサーバを迅速に追加することができ、サーバクループの運用を即座に復旧させることができる。

つぎに、システムリソースマネージャ２１が、リソース割当管理処理において、運用管理クライアント１０に出力する各種出力画面について説明する。図５２は、管理対象となるリソースの配置を示すリソース配置出力画面１０９０の一例を示す図である。

図５２に示すように、このリソース配置出力画面１０９０は、Ｗｅｂドメイン１１００、ＡＰドメイン１１１０、ＤＢドメイン１１２０に属する各種サーバと、ストレージドメイン１１３０に属するストレージとがどのように接続されているかをユーザが一目で把握できるように構成されている。

図５３は、リソースの配置に係る設定をユーザから受け付けるリソース配置設定画面１１４０の一例を示す図である。このリソース配置設定画面１１４０では、部品パレット１１４０ａが出力され、この部品パレットにあるドメインやサーバ、ストレージなどの各種アイコンをユーザがマウス等を操作して配置していくことにより、各種リソースの配置を決定することができる。

図５４は、サーバドメインに属するサーバグループの一覧を出力するサーバグループ一覧画面１１５０の一例を示す図である。このサーバグループ一覧画面１１５０では、ユーザによるマウス等の操作により、サーバドメインが指定されると、そのサーバドメインに属するサーバグループおよびサーバグループに追加可能な、プールされたサーバの一覧が出力される。

図５５は、サーバグループに属するサーバの一覧を出力するサーバ一覧画面１１６０の一例を示す図である。このサーバ一覧画面１１６０では、ユーザによるマウス等の操作により、サーバグループが指定されると、そのサーバグループに属するサーバおよびサーバグループに追加可能な、プールされたサーバの一覧が出力される。

さらに、このサーバ一覧画面１１６０では、ユーザによるマウス等の操作により、プールされたサーバが指定され、追加ボタンがクリックされると、指定されたサーバをサーバグループに追加する処理の実行要求がシステムリソースマネージャ２１に送信され、当該サーバの追加処理が実行される。

また、このサーバ一覧画面１１６０では、ユーザによるマウス等の操作により、サーバグループに属するサーバが指定され、削除ボタンがクリックされると、指定されたサーバをサーバグループから削除する処理の実行要求がシステムリソースマネージャ２１に送信され、当該サーバの削除処理が実行される。

図５６は、ストレージグループに属するストレージの一覧を出力するストレージ一覧画面１１７０の一例を示す図である。このストレージ一覧画面１１７０においても、図５５に示したサーバ一覧画面１１６０と同様、ユーザによるマウス等の操作により、ストレージグループが指定されると、そのストレージグループに属するストレージおよびストレージグループに追加可能な、プールされたストレージの一覧が出力される。

そして、ストレージ一覧画面１１７０では、ユーザによるマウス等の操作により、プールされたストレージが指定され、追加ボタンがクリックされると、指定されたストレージをストレージグループに追加する処理の実行要求がシステムリソースマネージャ２１に送信され、当該ストレージの追加処理が実行される。

また、このストレージ一覧画面１１７０では、ユーザによるマウス等の操作により、ス
トレージグループに属するストレージが指定され、削除ボタンがクリックされると、指定されたストレージをストレージグループから削除する処理の実行要求がシステムリソースマネージャ２１に送信され、当該ストレージの削除処理が実行される。

上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図５７から図５９を用いて、リソース交換処理プログラムを実行するコンピュータの一例を説明する。

図５７は、図３に示したサイト管理サーバ２０となるコンピュータ１２００のハードウェア構成を示す図である。このコンピュータ１２００は、ユーザからのデータの入力を受け付ける入力装置１２１０、モニタ１２２０、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置１２３０、ＲＯＭ（Read Only Memory）１２４０、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース１２５０、ＨＤＤ（Hard Disk Drive）１２６０、ＲＡＭ（Random Access Memory）１２７０およびＣＰＵ（Central Processing Unit）１２８０をバス１２９０で接続して構成される。

そして、ＨＤＤ１２６０には、サイト管理サーバ２０の機能と同様の機能を発揮するプログラム、つまり、図５７に示すシステムリソース交換処理プログラム１２６０ｂおよびＡＰ管理統括プログラム１２６０ｃが記憶されている。

なお、システムリソース交換処理プログラム１２６０ｂおよびＡＰ管理統括プログラム１２６０ｃについては、適宜統合または分散して記憶することとしてもよい。

そして、ＣＰＵ１２８０が、システムリソース交換処理プログラム１２６０ｂおよびＡＰ管理統括プログラム１２６０ｃをＨＤＤ１２６０から読み出して実行することにより、システムリソース交換処理プロセス１２８０ａおよびＡＰ管理統括プロセス１２８０ｂとして機能するようになる。

このシステムリソース交換処理プロセス１２８０ａは、図３に示したシステムリソースマネージャ２１、サーバＲＭ２２、ソフトウェアＲＭ２３、ネットワークＲＭ２４、ストレージＲＭ２５に対応する。また、ＡＰ管理統括プロセス１２８０ｂは、図３に示したＡＰ管理統括部２７に対応する。

また、ＨＤＤ１２６０には、システムリソースデータ１２６０ａが記憶される。なお、このシステムリソースデータ１２６０ａは、図３に示したシステムリソースＤＢ２６に記憶される各種データに対応する。

そして、ＣＰＵ１２８０は、リソースの管理に係る各種データをシステムリソースデータ１２６０ａとして記憶するとともに、システムリソースデータ１２６０ａをＨＤＤ１２６０から読み出してＲＡＭ１２７０に格納し、ＲＡＭ１２７０に格納されたシステムリソースデータ１２７０ａに基づいて各種データ処理を実行する。

図５８は、図３に示したドメイン管理サーバ２０となるコンピュータ１３００のハードウェア構成を示す図である。このコンピュータ１３００は、ユーザからのデータの入力を受け付ける入力装置１３１０、モニタ１３２０、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置１３３０、ＲＯＭ１３４０、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース１３５０、ＨＤＤ１３６０、ＲＡＭ１３７０およびＣＰＵ１３８０をバス１３９０で接続して構成される。

そして、ＨＤＤ１３６０には、ドメイン管理サーバ５０，６０の機能と同様の機能を発揮するプログラム、つまり、図５７に示すドメインリソース交換処理プログラム１３６０ｂが記憶されている。なお、ドメインリソース交換処理プログラム１２６０ｂについては、適宜統合または分散して記憶することとしてもよい。

そして、ＣＰＵ１３８０が、ドメインリソース交換処理プログラム１３６０ｂをＨＤＤ１３６０から読み出して実行することにより、ドメインリソース交換処理プロセス１３８０ａとして機能するようになる。

このドメインリソース交換処理プロセス１３８０ａは、図３に示したシステムリソースドメインマネージャ５１、サーバサブＲＭ５２、ソフトウェアサブＲＭ５３、ネットワークサブＲＭ５４に対応する。

また、ＨＤＤ１３６０には、ドメインリソースデータ１３６０ａが記憶される。なお、このドメインリソースデータ１３６０ａは、図３に示したドメインリソースＤＢ５５に記憶される各種データに対応する。

そして、ＣＰＵ１３８０は、ドメインにおけるリソースの管理に係る各種データをドメインリソースデータ１３６０ａとして記憶するとともに、ドメインリソースデータ１３６０ａをＨＤＤ１３６０から読み出してＲＡＭ１３７０に格納し、ＲＡＭ１３７０に格納されたドメインリソースデータ１３７０ａに基づいて各種データ処理を実行する。

また、図５９は、図３に示したサーバ１１０ａとなるコンピュータ１４００のハードウェア構成を示す図である。このコンピュータ１４００は、ユーザからのデータの入力を受け付ける入力装置１４１０、モニタ１４２０、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置１４３０、ＲＡＭ１４４０、ＲＯＭ１４５０、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース１４６０、ＨＤＤ１４７０およびＣＰＵ１４８０をバス１４９０で接続して構成される。

そして、ＨＤＤ１４７０には、サーバ１１０ａの機能と同様の機能を発揮するプログラム、つまり、図５９に示すエージェントリソース交換処理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂが記憶されている。なお、エージェントリソース交換処理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂについては、適宜統合または分散して記憶することとしてもよい。

そして、ＣＰＵ１４８０が、エージェントリソース交換処理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂをＨＤＤ１４７０から読み出して実行することにより、エージェントリソース交換処理プロセス１４８０ａおよびＡＰ管理プロセス１４８０ｂとして機能するようになる。

このエージェントリソース交換処理プロセス１４８０ａは、図３に示したリソースマネージャエージェント１１１ａ、サーバＲＭエージェント１１２ａ、ソフトウェアＲＭエージェント１１３ａ、ネットワークＲＭエージェント１１４ａおよびストレージＲＭエージェント１１５ａに対応する。また、ＡＰ管理プロセス１４８０ｂは、図３に示したＡＰ管理部１１６ａに対応する。

ところで、システムリソース交換処理プログラム１２６０ｂ、ＡＰ管理統括プログラム１２６０ｃ、ドメインリソース交換処理プログラム１３６０ｂ、エージェントリソース交
換処理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂについては、必ずしも最初からＨＤＤ１２６０、ＨＤＤ１３６０またはＨＤＤ１４７０に記憶させておく必要はない。

たとえば、コンピュータ１２００、１３００または１４００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、または、コンピュータの内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１２００、１３００または１４００に接続される「他のコンピュータ（またはサーバ）」などに各プログラムを記憶しておき、コンピュータ１２００、１３００または１４００がこれらから各プログラムを読み出して実行するようにしてもよい。

上述してきたように、本実施例では、ソフトウェアＲＭ２３やネットワークＲＭ２４が、プール内のサーバに、予め、追加対象となるサーバグループに対応するソフトウェアのインストールや、ネットワーク設定をシステムリソースＤＢ２６の情報を利用して行う。そして、サーバグループに含まれるサーバが故障した場合や、サーバグループの負荷が大きくなった場合に、ソフトウェアやネットワークの設定を予め行ったサーバを、サーバグループに追加することによって、低コストかつ迅速にサーバグループを復旧させることができる。

以上のように、本発明にかかるリソース交換処理プログラムおよびリソース交換処理方法は、複数のサーバから構成され、種々の業務を実行する情報処理システムに有用であり、特に、サーバの故障に対して迅速な復旧が必要な情報処理システムに適している。

Claims (12)

1. 複数のサーバによって構成される複数のサーバグループに、予備サーバを追加・交換するリソース交換処理プログラムであって、
   前記サーバグループに対するソフトウェア、ネットワークおよびストレージの設定に係る情報である設定情報を取得し、該設定情報を基にして、前記サーバグループに対応する設定を、予め、前記予備サーバに対して行う設定処理手順と、
   前記サーバグループに異常が発生した場合や、前記サーバグループにかかる負荷が増大した場合に、前記設定処理手順において設定を行った予備サーバを、前記サーバグループに追加する追加処理手順と、
   をコンピュータに実行させることを特徴とするリソース交換処理プログラム。
2. 前記設定処理手順は、前記複数のサーバグループの前記設定情報をそれぞれ取得し、前記予備サーバに対する設定を、前記複数のサーバグループそれぞれに対応するように設定し、前記追加処理手順は、前記複数のサーバグループのいずれに対しても前記予備サーバを追加可能とすることを特徴とする請求項１に記載のリソース交換処理プログラム。
3. 前記設定処理手順は、前記予備サーバを前記サーバグループに一旦組み込む組込手順と、前記設定情報を基にして、前記予備サーバに対して、前記サーバグループに対応する設定を行う設定手順と、前記サーバグループに組み込まれた前記予備サーバを、前記サーバグループから切り離す切断手順とをコンピュータに実行させることを特徴とする請求項１または２に記載のリソース交換処理プログラム。
4. 前記組込手順は、前記切断手順によって前記サーバグループから切り離された前記予備サーバを、前記複数のサーバグループの内、未組込のサーバグループに組み込み、前記設定手順は、該組み込んだサーバグループの設定情報を基にして、前記予備サーバに対して、組み込んだサーバグループに対応する設定を行うことを特徴とする請求項３に記載のリソース交換処理プログラム。
5. 前記追加処理手順において、前記予備サーバを前記サーバグループに追加する際、前記サーバグループの設定情報が更新されているか否かを判定する更新判定手順と、前記更新判定手順において前記サーバグループの設定情報が更新されていると判定された場合に、更新された設定情報を基にして、前記予備サーバを再設定する再設定手順とを更にコンピュータに実行させることを特徴とする請求項１に記載のリソース交換処理プログラム。
6. 複数のサーバによって構成される複数のサーバグループに、予備サーバを追加・交換するリソース交換処理方法であって、
   前記サーバグループに対するソフトウェア、ネットワークおよびストレージの設定に係る情報である設定情報を取得し、該設定情報を基にして、前記サーバグループに対応する設定を、予め、前記予備サーバに対して行う設定処理工程と、
   前記サーバグループに異常が発生した場合や、前記サーバグループにかかる負荷が増大した場合に、前記設定処理工程において設定を行った予備サーバを、前記サーバグループに追加する追加処理工程と、
   を含んだことを特徴とするリソース交換処理方法。
7. 前記設定処理工程は、前記複数のサーバグループの前記設定情報をそれぞれ取得し、前記予備サーバに対する設定を、前記複数のサーバグループそれぞれに対応するように設定し、前記追加処理工程は、前記複数のサーバグループのいずれに対しても前記予備サーバを追加可能とすることを特徴とする請求項６に記載のリソース交換処理方法。
8. 前記設定処理工程は、前記予備サーバを前記サーバグループに一旦組み込む組込工程と、前記設定情報を基にして、前記予備サーバに対して、前記サーバグループに対応する設定を行う設定工程と、前記サーバグループに組み込まれた前記予備サーバを、前記サーバグループから切り離す切断工程とを含んだことを特徴とする請求項６または７に記載のリソース交換処理方法。
9. 前記組込工程は、前記切断工程によって前記サーバグループから切り離された前記予備サーバを、前記複数のサーバグループの内、未組込のサーバグループに組み込み、前記設定工程は、該組み込んだサーバグループの設定情報を基にして、前記予備サーバに対して、組み込んだサーバグループに対応する設定を行うことを特徴とする請求項８に記載のリソース交換処理方法。
10. 前記追加処理工程において、前記予備サーバを前記サーバグループに追加する際、前記サーバグループの設定情報が更新されているか否かを判定する更新判定工程と、前記更新判定工程において前記サーバグループの設定情報が更新されていると判定された場合に、更新された設定情報を基にして、前記予備サーバを再設定する再設定工程とを更に含んだことを特徴とする請求項６に記載のリソース交換処理方法。
11. 複数のサーバによって構成される複数のサーバグループに、予備サーバを追加・交換するリソース交換処理装置であって、
    前記サーバグループに対するソフトウェア、ネットワークおよびストレージの設定に係る情報である設定情報を取得し、該設定情報を基にして、前記サーバグループに対応する設定を、予め、前記予備サーバに対して行う設定処理手段と、
    前記サーバグループに異常が発生した場合や、前記サーバグループにかかる負荷が増大した場合に、前記設定処理手段において設定を行った予備サーバを、前記サーバグループに追加する追加処理手段と、
    を備えたことを特徴とするリソース交換処理装置。
12. 前記設定処理手段は、前記予備サーバを前記サーバグループに一旦組み込む組込手段と、前記設定情報を基にして、前記予備サーバに対して、前記サーバグループに対応する設定を行う設定手段と、前記サーバグループに組み込まれた前記予備サーバを、前記サーバグループから切り離す切断手段とを備えたことを特徴とする請求項１１に記載のリソース交換処理装置。

Images