JPWO2006043309A1 - 運用管理プログラム、運用管理方法および運用管理装置 - Google Patents

運用管理プログラム、運用管理方法および運用管理装置 Download PDF

Info

Publication number
JPWO2006043309A1
JPWO2006043309A1 JP2006542128A JP2006542128A JPWO2006043309A1 JP WO2006043309 A1 JPWO2006043309 A1 JP WO2006043309A1 JP 2006542128 A JP2006542128 A JP 2006542128A JP 2006542128 A JP2006542128 A JP 2006542128A JP WO2006043309 A1 JPWO2006043309 A1 JP WO2006043309A1
Authority
JP
Japan
Prior art keywords
server
group
domain
information
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2006542128A
Other languages
English (en)
Other versions
JP4734259B2 (ja
Inventor
茂洋 吉川
茂洋 吉川
賢伸 日比
賢伸 日比
雅行 内藤
雅行 内藤
敏 伊與田
敏 伊與田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2006043309A1 publication Critical patent/JPWO2006043309A1/ja
Application granted granted Critical
Publication of JP4734259B2 publication Critical patent/JP4734259B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine

Abstract

サイト管理サーバ（２０）のシステムリソースマネージャ（２１）が、物理結線が均一なサーバの集まりとしてサーバドメインを登録し、登録したサーバドメインにおいて均一のソフトウェアを利用するサーバの集まりとしてサーバグループを登録し、登録したサーバグループに属するサーバにＳＡＮを介して接続されているＲＡＩＤ装置に用途別に記憶され、当該サーバにより利用されるソフトウェアの切り替えを制御することによりサーバの用途を変更する。

Description

本発明は、情報処理システムを構成するリソースの運用を管理する運用管理プログラム、運用管理方法および運用管理装置に関し、特に、サーバなどのリソースの数が多い大規模な情報処理システムにおいても、リソースの用途の変更を管理者が容易にかつ効率的に実行することができる運用管理プログラム、運用管理方法および運用管理装置に関するものである。
従来、サーバなどのリソースがネットワークを介して接続されることにより構成される情報処理システムにおいて、サーバを起動する際に、サーバに転送するソフトウェアを切り替えることによりサーバの用途を変更する技術が開発されている。
たとえば、特許文献１には、サーバの起動ごとに起動ディスクから転送される起動プログラムの内容を変更し、サーバをさまざまな環境で運用するシステムのマルチブート方法が開示されている。
特開２００３−２２１９０号公報
しかしながら、上述した特許文献１に代表される従来技術では、用途を変更して利用するサーバが複数ある場合に、それらの用途の切り替えを管理することが難しいという問題があった。
すなわち、それぞれのサーバに対してソフトウェアの切り替えを個々に実行する必要があり、情報処理システムの管理者に負担がかかるという問題があった。特に、情報処理システムの規模が大きくなって、サーバの数が多くなると、ソフトウェアの切り替え処理の実行がますます困難になってくる。
このようなことから、サーバの数が多い大規模な情報処理システムにおいて、サーバの用途の変更を管理者がいかに容易にかつ効率的に実行することができるかが重要な問題となっている。
本発明は、上記に鑑みてなされたものであって、サーバなどのリソースの数が多い大規模な情報処理システムにおいても、リソースの用途の変更を管理者が容易にかつ効率的に実行することができる運用管理プログラム、運用管理方法および運用管理装置を提供することを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、情報処理システムを構成するリソースの運用を管理する運用管理プログラムであって、均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録するグループ登録手順と、前記グループ登録手順により登録されたリソースグループに属するリソースが利用するソフトウェアの切り替えを制御することによりリソースの用途を変更する用途変更手順と、をコンピュータに実行させることを特徴とする。
また、本発明は、情報処理システムを構成するリソースの運用を管理する運用管理方法であって、均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録するグループ登録工程と、前記グループ登録工程により登録されたリソースグループに属するリソースが利用するソフトウェアの切り替えを制御することによりリソースの用途を変更する用途変更工程と、を含んだことを特徴とする。
また、本発明は、情報処理システムを構成するリソースの運用を管理する運用管理装置であって、均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録するグループ登録手段と、前記グループ登録手段により登録されたリソースグループに属するリソースが利用するソフトウェアの切り替えを制御することによりリソースの用途を変更する用途変更手段と、を備えたことを特徴とする。
本発明によれば、均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録し、登録したリソースグループに属するリソースが利用するソフトウェアの切り替えを制御することとしたので、リソースの数が多い大規模な情報処理システムにおいても、リソースをリソースグループ単位で管理することにより、リソースの用途の変更を管理者が容易にかつ効率的に実行することができるという効果を奏する。
図１は、リソースの運用管理の概念を示す図である。 図２は、本実施例に係るリパーパシング処理の概念を説明する図である。 図３は、本実施例に係るリソース運用管理システムの機能構成を示す図である。 図４は、業務へのサーバの割当処理の処理手順を示すフローチャートである。 図５は、運用管理サーバの情報を登録するサイトデータの一例を示す図である。 図６は、ドメイン管理サーバの情報を登録するドメイン管理サーバデータの一例を示す図である。 図７は、管理対象となるサブネットの情報を登録する管理サブネットデータの一例を示す図である。 図８は、ミドルウェアと連携して各種処理を実行するためのコマンドを記憶したミドルウェア連携ＩＦデータの一例を示す図である。 図９は、サーバが属するドメインであるサーバドメインに係る情報を記憶したサーバドメインデータの一例を示す図である。 図１０は、プールグループに係る情報を記憶したプールグループデータの一例を示す図である。 図１１は、ストレージドメインに係る情報を記憶したストレージドメインデータの一例を示す図である。 図１２は、ネットワークドメインおよびネットワークサブドメインを説明する説明図である。 図１３は、ネットワークサブドメインに係る情報を記憶したネットワークサブドメインデータの一例を示す図である。 図１４は、ネットワークドメインに係る情報を記憶したネットワークドメインデータの一例を示す図である。 図１５は、負荷分散装置に係る情報を記憶した負荷分散装置データの一例を示す図である。 図１６は、ネットワークサブグループの構成例を説明する説明図である。 図１７は、ネットワークサブグループに係る情報を記憶したネットワークサブグループデータの一例を示す図である。 図１８は、サーバドメイン間の対応関係に係る情報を記憶したサーバドメイン間リンクデータの一例を示す図である。 図１９は、サーバドメインとストレージドメインとの間の対応関係に係る情報を記憶したサーバ／ストレージドメイン間リンクデータの一例を示す図である。 図２０は、ネットワークブートがなされるサーバの情報を記憶したネットワークブートサーバデータの一例を示す図である。 図２１は、管理対象となるサーバのデータを記憶した管理対象サーバデータの一例を示す図である。 図２２は、サーバが属するグループの情報を記憶したプロビジョニング構成データの一例を示す図である。 図２３は、結線状態が均一であるサーバとストレージ機器との結線の一例を示す図である。 図２４は、ＷＷＰＮに基づく結線の均一性チェック処理を説明する図である。 図２５は、ストレージテンプレートに係るデータを記憶したストレージテンプレートデータの一例を示す図である。 図２６は、サーバグループに係る情報を記憶したサーバグループデータの一例を示す図である。 図２７は、サーバグループに対応するストレージグループの情報を記憶したサーバ／ストレージグループリンクデータの一例を示す図である。 図２８は、サーバグループ間の対応関係に係る情報を記憶したサーバグループ間リンクデータの一例を示す図である。 図２９は、負荷分散装置のグループ情報を記憶した負荷分散グループデータの一例を示す図である。 図３０は、ネットワークグループに係る情報を記憶したネットワークグループデータの一例を示す図である。 図３１は、論理ボリュームをＲＡＩＤ装置に設定する設定処理の処理手順を示すフローチャートである。 図３２は、論理ボリュームの設定画面の一例を示す図である。 図３３は、ＲＡＩＤレベルの設定情報を記憶したＲＡＩＤレベル設定データの一例を示す図である。 図３４は、ＲＡＩＤ装置に係る情報を記憶したＲＡＩＤ装置データの一例を示す図である。 図３５は、ストレージサブグループが設定されたプロビジョニング構成データの一例を示す図である。 図３６は、サーバに論理ボリュームを認識させる論理ボリュームの設定処理の処理手順を示すフローチャートである。 図３７は、ＲＡＩＤ装置に構築された論理ボリュームの設定処理を説明する説明図である。 図３８は、アフィニティグループに係る情報を記憶したアフィニティグループデータの一例を示す図である。 図３９は、マルチパスの構成に係る情報を記憶したマルチパス構成データの一例を示す図である。 図４０は、ミラーボリュームの構成に係る情報を記憶したミラーボリューム構成データの一例を示す図である。 図４１は、サーバに割り当てられたＩＰアドレスに係る情報を記憶したＩＰアドレス管理データの一例を示す図である。 図４２は、ソフトウェアイメージに係る情報を記憶したソフトウェアイメージ管理データの一例を示す図である。 図４３は、ソフトウェア配布イメージに係る情報を記憶したソフトウェア配布イメージ管理データの一例を示す図である。 図４４は、スナップショットに係る情報を記憶したスナップショット管理データの一例を示す図である。 図４５は、サーバをサーバグループに追加する処理の処理手順を示すフローチャートである。 図４６は、ソフトウェア配布イメージの配布状況に係る情報を記憶した配布管理データの一例を示す図である。 図４７は、リパーパシング処理に係る事前設定処理の処理手順を説明するフローチャートである。 図４８は、リパーパシング処理の処理手順を示すフローチャートである。 図４９は、リパーパシングの設定に係る情報を記憶したリパーパシング設定データの一例を示す図である。 図５０は、サーバの状態に係る情報を記憶したリパーパシング運用データの一例を示す図である。 図５１は、リパーパシング処理を実行するスケジュールに係る情報を記憶したスケジュール設定データの一例を示す図である。 図５２は、各状態に１つ以上のサーバグループを設定したリパーパシング設定データの一例を示す図である。 図５３は、図３に示したサイト管理サーバとなるコンピュータのハードウェア構成を示す図である。 図５４は、図３に示したドメイン管理サーバとなるコンピュータのハードウェア構成を示す図である。 図５５は、図３に示したサーバとなるコンピュータのハードウェア構成を示す図である。
符号の説明
１，２ 業務
３ プール
４ Ｗｅｂドメイン
４1〜４9 Ｗｅｂサーバ
５ ＡＰドメイン
５1〜５6 ＡＰサーバ
６ ＤＢドメイン
６1〜６3 ＤＢサーバ
７ ストレージドメイン
７1〜７9 ストレージ
８ａ ＤＢサーバグループ
８ｂ バッチサーバグループ
８ｃ プールグループ
８ａ1，８ａ2，８ｂ1，８ｂ2，８ｃ1，８ｃ2 サーバ
９ ストレージ
９ａ1，９ａ2 ＤＢサーバブートディスク
９ｂ1，９ｂ2 バッチサーバブートディスク
１０ 運用管理クライアント
２０ サイト管理サーバ
２１ システムリソースマネージャ
２２ サーバＲＭ
２３ ソフトウェアＲＭ
２４ ネットワークＲＭ
２５ ストレージＲＭ
２６ システムリソースＤＢ
２７ ＡＰ管理統括部
３０，４０，９０，１２０ ＦＷ
５０，６０ ドメイン管理サーバ
５１ システムリソースドメインマネージャ
５２ サーバサブＲＭ
５３ ソフトウェアサブＲＭ
５４ ネットワークサブＲＭ
５５ ドメインリソースＤＢ
７０ インターネット
８０ ルータ
１００，１３０ ＳＬＢ
１１０ａ，１１０ｂ，１１０ｃ サーバ
１１１ａ リソースマネージャエージェント
１１２ａ サーバＲＭエージェント
１１３ａ ソフトウェアＲＭエージェント
１１４ａ ネットワークＲＭエージェント
１１５ａ ストレージＲＭエージェント
１１６ａ ＡＰ管理部
１４０ａ，１４０ｂ，１４０ｃ サーバ
１５０ａ，１５０ｂ，１５０ｃ サーバ
１６０ａ，１６０ｂ，１６０ｃ，１６０ｄ ストレージ
１７０ ＳＡＮ
１８０ エッジドメイン
１９０ Ｗｅｂドメイン
２００ ＡＰドメイン
２１０ ＤＢドメイン
３００ サイトデータ
３１０ ドメイン管理サーバデータ
３２０ 管理サブネットデータ
３３０ ミドルウェア連携ＩＦデータ
３４０ サーバドメインデータ
３５０ プールグループデータ
３６０ ストレージドメインデータ
３７０ Ｗｅｂドメイン
３８０ａ，３８０ｂ，３８０ｃ，３８０ｄ，３８０ｅ サーバ
３９０ ＡＰドメイン
４００ａ，４００ｂ，４００ｃ，４００ｄ，４００ｅ サーバ
４１０ Ｗｅｂ−ＡＰネットワークドメイン
４２０ Ｗｅｂ−Ｂａｃｋネットワークサブドメイン
４３０ａ，４３０ｂ スイッチ
４４０ ＡＰ−Ｆｒｏｎｔネットワークサブドメイン
４５０ａ，４５０ｂ スイッチ
４６０ａ，４６０ｂ ＳＬＢ
４７０ ネットワークサブドメインデータ
４８０ ネットワークドメインデータ
４９０ 負荷分散装置データ
５１０ Ｗｅｂドメイン
５２０ａ，５２０ｂ，５２０ｃ，５２０ｄ，５２０ｅ サーバ
５３０ A_Webサーバグループ
５４０ B_Webサーバグループ
５５０ ＡＰドメイン
５６０ａ，５６０ｂ，５６０ｃ，５６０ｄ，５６０ｅ サーバ
５７０ A_APサーバグループ
５８０ B_APサーバグループ
５９０，６１０ スイッチ
６００ａ，６００ｂ ＳＬＢ
６２０ A_Web_Backネットワークサブグループ
６３０ B_Web_Backネットワークサブグループ
６４０ A_AP_Frontネットワークサブグループ
６５０ B_AP_Frontネットワークサブグループ
６６０ ネットワークサブグループデータ
６７０ サーバドメイン間リンクデータ
６８０ サーバ／ストレージドメイン間リンクデータ
６９０ ネットワークブートサーバデータ
７００ 管理対象サーバデータ
７１０ プロビジョニング構成データ
７２０ サーバドメイン
７３０ａ，７３０ｂ サーバ
７４０ ストレージドメイン
７５０ａ，７５０ｂ ＦＣスイッチ
７６０ａ，７６０ｂ ＲＡＩＤ装置
７７０ａ，７７０ｂ ＲＡＩＤ装置ＷＷＰＮデータ
７８０ａ，７８０ｂ ＦＣスイッチＷＷＰＮデータ
７９０ａ，７９０ｂ サーバＷＷＰＮデータ
８００ ストレージテンプレートデータ
８１０ サーバグループデータ
８２０ サーバ／ストレージグループリンクデータ
８３０ サーバグループ間リンクデータ
８４０ 負荷分散グループデータ
８５０ ネットワークグループデータ
８６０ 必要条件出力画面
８７０ａ，８７０ｂ，８７０ｃ 必要条件
８８０ 論理ボリューム構成出力画面
８９０ ＲＡＩＤ装置
９００ａ，９００ｂ，９００ｃ 必要条件
９１０ａ，９１０ｂ，９１０ｃ，９１０ｄ 論理ボリューム
９２０ａ，９２０ｂ，９２０ｃ，９２０ｄ，９２０ｅ 論理ボリューム
９３０ａ，９３０ｂ ＲＡＩＤグループ
９４０ ＲＡＩＤレベル設定データ
９５０ ＲＡＩＤ装置データ
９６０ プロビジョニング構成データ
９７０ サーバグループ
９８０ ストレージプール
９９０ ストレージグループ
１０００ サーバ内ストレージ構成
１０１０ アフィニティグループデータ
１０２０ マルチパス構成データ
１０３０ ミラーボリューム構成データ
１０４０ ＩＰアドレス管理データ
１０５０ ソフトウェアイメージ管理データ
１０６０ ソフトウェア配布イメージ管理データ
１０７０ スナップショット管理データ
１０８０ 配布管理データ
１０９０ リパーパシング設定データ
１１００ リパーパシング運用データ
１１１０ スケジュール設定データ
１１２０ リパーパシング設定データ
１２００ コンピュータ
１２１０ 入力装置
１２２０ モニタ
１２３０ 媒体読取り装置
１２４０ ＲＯＭ
１２５０ ネットワークインターフェース
１２６０ ＨＤＤ
１２６０ａ システムリソースデータ
１２６０ｂ システムリソース管理プログラム
１２６０ｃ ＡＰ管理統括プログラム
１２７０ ＲＡＭ
１２７０ａ システムリソースデータ
１２８０ ＣＰＵ
１２８０ａ システムリソース管理プロセス
１２８０ｂ ＡＰ管理統括プロセス
１２９０ バス
１３００ コンピュータ
１３１０ 入力装置
１３２０ モニタ
１３３０ 媒体読取り装置
１３４０ ＲＯＭ
１３５０ ネットワークインターフェース
１３６０ ＨＤＤ
１３６０ａ ドメインリソースデータ
１３６０ｂ ドメインリソース管理プログラム
１３７０ ＲＡＭ
１３７０ａ ドメインリソースデータ
１３８０ ＣＰＵ
１３８０ａ ドメインリソース管理プロセス
１３９０ バス
１４００ コンピュータ
１４１０ 入力装置
１４２０ モニタ
１４３０ 媒体読取り装置
１４４０ ＲＡＭ
１４５０ ＲＯＭ
１４６０ ネットワークインターフェース
１４７０ ＨＤＤ
１４７０ａ エージェントリソース管理プログラム
１４７０ｂ ＡＰ管理プログラム
１４８０ ＣＰＵ
１４８０ａ エージェントリソース管理プロセス
１４８０ｂ ＡＰ管理プロセス
１４９０ バス
以下に、本発明に係る運用管理プログラム、運用管理方法および運用管理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
まず、本実施例に係るサーバ運用管理の概念について説明する。図１は、サーバやストレージなどのリソースの運用管理の概念を示す図であり、図２は、本実施例に係るリパーパシング処理の概念を説明する図である。ここで、リパーパシング処理とは、サーバの用途を自動的に切り替える処理である。
図１には、各業務１，２においてＷｅｂサーバ４1〜４9やＡＰ（Application）サーバ５1〜５6、ＤＢ（Database）サーバ６1〜６3、ストレージ７1〜７9などの情報処理装置が利用される場合が示されている。
ここで、Ｗｅｂサーバ４1〜４9は、Ｗｅｂブラウザで閲覧されるコンテンツをインターネットを介してクライアント装置に提供するサーバ装置である。ＡＰサーバ５1〜５6は、ユーザによる情報処理要求を受け付けたＷｅｂサーバ４1〜４9から要求された情報処理の実行を引き継ぐサーバ装置である。
ＤＢサーバ６1〜６3は、ＡＰサーバ５1〜５6からデータベースへのアクセス要求を受け付けた場合に、データベースへのアクセスを管理するサーバ装置である。ストレージ７1〜７9は、ネットワークを介してＷｅｂサーバ４1〜４9やＡＰサーバ５1〜５6、データベースサーバ６1〜６3に接続され、ＳＡＮ（Storage Area Network）を構成する記憶装置である。
本発明に係るリソース運用管理処理では、ＬＡＮ（Local Area Network）やＳＡＮなどにおいて、他の装置との間の物理的な結線状態が互いに均一であるサーバやストレージなどのリソース群をドメインとして管理する。
たとえば、図１の場合には、業務１，２で利用されるサーバ群が、Ｗｅｂドメイン４、ＡＰドメイン５およびＤＢドメイン６として管理され、業務１，２で利用されるストレージ群が、ストレージドメイン７として管理されている。
この場合、Ｗｅｂドメイン４に属するＷｅｂサーバ４1〜４9の他の装置に対する結線状態は互いに均一であり、ＡＰドメイン５に属するＡＰサーバ５1〜５6の他の装置に対する結線状態は互いに均一であり、ＤＢドメイン６に属するＤＢサーバ６1〜６3の他の装置に対する結線状態は互いに均一であり、ストレージドメイン７に属するストレージ７1〜７9の他の装置に対する結線状態は互いに均一となっている。
そして、このリソース運用管理処理では、未使用のＷｅｂサーバ４1〜４9、ＡＰサーバ５1〜５6、ＤＢサーバ６1〜６3およびストレージ７1〜７9をドメインごとにプール３に登録しておき、必要に応じて各業務１，２にＷｅｂサーバ４1〜４9、ＡＰサーバ５1〜５6、ＤＢサーバ６1〜６3およびストレージ７1〜７9を割り当てる。
たとえば、図１では、業務１には、Ｗｅｂサーバ４2，４3、ＡＰサーバ５1、ＤＢサーバ６1、ストレージ７7が割り当てられ、業務２には、Ｗｅｂサーバ４9、ＡＰサーバ５2，５3、ＤＢサーバ６2、ストレージ７8，７9が割り当てられている。
そして、業務１，２に割り当てられたＷｅｂサーバ４2，４3，４9、ＡＰサーバ５1，５2，５3、ＤＢサーバ６1，６2の負荷が増大したり、ストレージ７7〜７9の記憶容量が不足したような場合に、プール３に登録されているＷｅｂサーバ４1，４4〜４8、ＡＰサーバ５4〜５6、ＤＢサーバ６3，ストレージ７1〜７6を業務で利用可能なサーバとして追加する。
具体的には、プール３に登録されているＷｅｂサーバ４1，４4〜４8、ＡＰサーバ５4〜５6，ＤＢサーバ６3に必要なソフトウェアを導入し、ネットワークの設定などを自動的におこなうことにより、Ｗｅｂサーバ４1，４4〜４8、ＡＰサーバ５4〜５6，ＤＢサーバ６3を業務で利用可能なサーバとして追加する。
また、ストレージ７1〜７6を追加する場合は、ストレージ７1〜７6に対して論理ボリュームの設定やネットワークの設定などを自動的におこなうことにより、当該ストレージ７1〜７6を業務で利用可能なストレージ７1〜７6として追加する。
たとえば、図１には、業務２のＷｅｂドメイン４において、プール３に登録されていたＷｅｂサーバ４4が新たに追加される場合が示されている。
さらに、このリソース運用管理処理では、業務１，２で利用されているＷｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3，ＤＢサーバ６1，６2またはストレージ７7〜７9が長期間使用されていないような場合に、Ｗｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3、ＤＢサーバ６1，６2、または、ストレージ７7〜７9を業務で利用可能なサーバから除外し、プール３に登録する処理がおこなわれる。
ここでプール３に登録されたＷｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3，ＤＢサーバ６1，６2，ストレージ７7〜７9は、別の業務１，２で利用されているＷｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3、ＤＢサーバ６1，６2の負荷が増大したり、ストレージ７7〜７9の記憶容量が不足したような場合に再利用される。
具体的には、Ｗｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3、ＤＢサーバ６1，６2に導入されているソフトウェアを削除し、ネットワークの設定の変更などを自動的におこなうことにより、Ｗｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3，ＤＢサーバ６1，６2が業務１，２で利用可能なサーバから除外され、プール３に登録される。
また、ストレージ７7〜７9を業務１，２で利用可能なストレージから除外してプール３に登録する場合には、ストレージ７7〜７9に対するネットワークの設定などを自動的におこなうことにより、当該ストレージ７7〜７9を業務で利用可能なストレージから除外し、プール３に登録する。
たとえば、図１には、業務２のＡＰドメイン５において、プール３に登録されていたＡＰサーバ５2が業務で利用可能なサーバから除外され、プール３に登録される場合が示されている。また、プール３に登録されたサーバ５4は、業務１で利用されているサーバ５1の負荷が増大したような場合に再利用され、業務１に新たに追加される。
そして、図２に示すように、リパーパシング処理においては、サーバの用途が時間帯によって自動的に切り替えられる。図２には、プールグループ８ｃに属するサーバ８ｃ1，８ｃ2が、平日昼間にはＤＢドメインに属するＤＢサーバグループ８ａに追加される。ここで、ＤＢサーバグループ８ａとは、ＤＢドメインにおいて、データをデータベースに記憶する処理をおこなうサーバのグループである。
ＤＢサーバグループ８ａに追加されたサーバ８ａ1，８ａ2は、ＤＢサーバ用のソフトウェアが記憶されたＤＢサーバブートディスク９ａ1，９ａ2からネットワークブートにより起動され、業務に提供される。
そして、ＤＢサーバグループ８ａに追加されたサーバ８ａ1，８ａ2は、夜間や休日になると、プールグループ８ｃに返却され、さらにバッチサーバグループ８ｂに追加される。ここで、バッチサーバグループ８ｂとは、ＤＢドメインにおいて、バッチ処理をおこなうサーバのグループである。
その際、バッチサーバグループ８ｂに追加されたサーバ８ｂ1，８ｂ2は、バッチサーバ用のソフトウェアが記憶されたバッチサーバブートディスク９ｂ1，９ｂ2からネットワークブートにより起動され、業務に提供される。
このように、リパーパシング処理においては、均一のソフトウェアを利用するサーバの集まりとしてサーバグループを登録し、登録したサーバグループに属するサーバが利用するソフトウェアの切り替えを制御することとしたので、サーバの数が多い大規模な情報処理システムにおいても、サーバをサーバグループ単位で管理することにより、サーバの用途の変更を管理者が容易にかつ効率的に実行することができる。
つぎに、本実施例に係るリソース運用管理システムの機能構成について説明する。図３は、本実施例に係るリソース運用管理システムの機能構成を示す図である。
図３に示すように、このリソース運用管理システムでは、運用管理クライアント１０と、サイト管理サーバ２０とが、ＦＷ（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）アーキテクチャの識別情報である。管理サブネット名は、図６に示した管理サブネット名と同様の情報である。
ステップＳ１０２においては、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作しておこなったサーバドメインおよびサーバアーキテクチャの設定に係る情報を受け付け、サーバドメインデータ３４０に登録する。このサーバドメインは、ステップＳ１０１において設定された管理サブネット単位で設定される。
また、ステップＳ１０２においては、システムリソースマネージャ２１は、各サーバドメインに属するサーバグループを設定し、サーバグループ間で共有されるプールグループおよび特定のサーバグループに専用のプールグループを設定する。
ここで、サーバグループとは、同一のサーバドメインに含まれるサーバを１つまたは複数のグループに分けたものである。また、プールグループとは、各サーバグループに割り当てられたサーバのプールである。
図１０は、プールグループに係る情報を記憶したプールグループデータ３５０の一例を示す図である。このプールグループデータ３５０には、プールグループ名、種別、サーバドメイン名の情報が記憶されている。
プールグループ名は、上述したサーバのプールの識別情報である。種別は、プールグループが複数のサーバグループに共用させるものか、特定のサーバグループにのみ利用を許可するものかを示す情報である。サーバドメイン名は、図９で説明したサーバドメイン名と同様の情報である。
ここで、システムリソースマネージャ２１は、各サーバドメインに対してプールグループを割り当てる。また、サーバドメインが、複数のサーバグループを有する場合に、システムリソースマネージャ２１は、それらのサーバグループ専用のプールグループを割り当てる。
その後、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したストレージドメインの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するストレージドメインデータ３６０として登録する。
図１１は、ストレージドメインに係る情報を記憶したストレージドメインデータ３６０の一例を示す図である。このストレージドメインデータ３６０は、ストレージドメイン名およびパスの多重度の情報を記憶している。ストレージドメイン名は、設定されたストレージドメインを識別する識別情報である。パスの多重度は、ＳＡＮにおけるデータ通信パスの多重度の情報である。
さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークサブドメインの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するネットワークサブドメインデータ４７０として登録する。
ここで、ネットワークサブドメインとは、異なるサーバドメインに属するサーバを接続する複数のネットワーク機器が属するネットワークドメインをさらに分割したサブドメインである。
図１２は、ネットワークドメインおよびネットワークサブドメインを説明する説明図である。図１２には、Ｗｅｂドメイン３７０に属するサーバ３８０ａ〜３８０ｅと、ＡＰドメイン３９０に属するサーバ４００ａ〜４００ｅとを接続するスイッチ４３０ａ，４３０ｂ，４５０ａ，４５０ｂ、および、ＳＬＢ４６０ａ，４６０ｂが示されている。
ここで、スイッチ４３０ａおよびスイッチ４３０ｂは、「Web-Back」ネットワークサブドメイン４２０を構成し、スイッチ４５０ａおよびスイッチ４５０ｂは、「AP-Front」ネットワークサブドメイン４４０を構成している。
また、「Web-Back」ネットワークサブドメイン４２０、「AP-Front」ネットワークサブドメイン４４０、ＳＬＢ４６０ａ、および、ＳＬＢ４６０ｂが「Web-AP」ネットワークドメイン４１０を構成している。
図１３は、ネットワークサブドメインに係る情報を記憶したネットワークサブドメインデータ４７０の一例を示す図である。このネットワークサブドメインデータ４７０は、ネットワークサブドメイン名、スイッチ機種およびスイッチ管理ＩＰの情報を記憶している。
ネットワークサブドメイン名は、図１２で説明したネットワークサブドメインを識別する情報である。スイッチ機種は、ネットワークサブドメインに属するスイッチの機種の情報である。スイッチ管理ＩＰは、管理用に各スイッチに割り当てられたＩＰアドレスの情報である。
また、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークドメインに係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するネットワークドメインデータ４８０として登録する。
図１４は、ネットワークドメインに係る情報を記憶したネットワークドメインデータ４８０の一例を示す図である。このネットワークドメインデータ４８０は、ネットワークドメイン名、フロントネットワークサブドメイン名、接続方式、機器名、バックネットワークサブドメイン名および冗長化方式の情報を記憶している。
ネットワークドメイン名は、図１２で説明したネットワークドメインを識別する識別情報である。フロントネットワークサブドメイン名は、図１２に示したように、ネットワークドメインがＳＬＢ４６０ａ，４６０ｂを境として２つのネットワークサブドメインに分割された場合に、インターネット７０に近い方のネットワークサブドメインを識別する識別情報である。
接続方式は、フロントネットワークサブドメインに属するスイッチ４３０ａ，４３０ｂなどのネットワーク機器と、後に説明するバックネットワークサブドメインに属するスイッチ４５０ａ，４５０ｂなどのネットワーク機器との間を接続する方式に係る情報である。たとえば、この方式には、ロードバランサにより接続する方式や、ファイアウォールにより接続する方式などがある。機器名は、ネットワーク機器を識別する識別情報である。
バックネットワークサブドメイン名は、図１２に示したように、ネットワークドメインがＳＬＢ４６０ａ，４６０ｂを境として２つのネットワークサブドメインに分割された場合に、インターネット７０に遠い方のネットワークサブドメインを識別する識別情報である。冗長化方式は、ネットワークドメインにおいてデータ通信経路が冗長化されている場合の冗長化の方式を示す情報である。
さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークサブドメインの接続機器に係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明する負荷分散装置データ４９０として登録する。ここで、ネットワークサブドメインの接続機器とは、図１２で説明したＳＬＢ４６０ａ，４６０ｂなどの機器のことである。
図１５は、負荷分散装置に係る情報を記憶した負荷分散装置データ４９０の一例を示す図である。この負荷分散装置データ４９０は、負荷分散装置名、管理ＩＰ、機種名、ＳＮＭＰコミュニティ名およびＩＤ／パスワードの情報を記憶している。
負荷分散装置名は、ネットワークサブドメインの接続機器を識別する名称である。管理ＩＰは、接続機器の管理用に各接続機器に割り当てられたＩＰアドレスの情報である。機種名は、接続機器の機種の識別情報である。
ＳＮＭＰ（Simple Network Management Protocol）コミュニティ名は、接続機器を管理するドメイン管理サーバ５０，６０およびサイト管理サーバ２０と接続機器とが属するＳＮＭＰコミュニティを特定する情報である。ＩＤ／パスワードは、接続機器にアクセスするために必要なＩＤおよびパスワードの情報である。
また、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークサブグループの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するネットワークサブグループデータ６６０として登録する。
ここで、ネットワークサブグループとは、サーバドメインに属するサーバにサーバグループが設定されている場合に、異なるサーバドメインに属するサーバグループ間を接続するネットワークを複数のネットワークに分割したものである。
図１６は、ネットワークサブグループの構成例を説明する説明図である。図１６には、Ｗｅｂドメイン５１０に属するサーバ５２０ａ〜５２０ｅと、ＡＰドメイン５５０に属するサーバ５６０ａ〜５６０ｅとを接続するスイッチ５９０，６１０、および、ＳＬＢ６００ａ，６００ｂが示されている。
ここで、サーバ５２０ａとサーバ５２０ｂとは、「A_Web」サーバグループ５３０を構成し、サーバ５２０ｃとサーバ５２０ｄとは、「B_Web」サーバグループ５４０を構成し、サーバ５６０ａとサーバ５６０ｂとは、「A_AP」サーバグループ５７０を構成し、サーバ５６０ｃとサーバ５６０ｄとは、「B_AP」サーバグループ５８０を構成している。
そして、「A_Web」サーバグループ５３０とＳＬＢ６００ａとを接続するネットワークが「A_Web_Back」ネットワークサブグループ６２０を構成し、「B_Web」サーバグループ５４０とＳＬＢ６００ｂとを接続するネットワークが「B_Web_Back」ネットワークサブグループ６３０を構成し、ＳＬＢ６００ａと「A_AP」サーバグループ５７０とを接続するネットワークが「A_AP_Front」ネットワークサブグループ６４０を構成し、ＳＬＢ６００ｂと「B_AP」サーバグループ５８０とを接続するネットワークが「B_AP_Front」ネットワークサブグループ６５０を構成している。
また、図１７は、ネットワークサブグループに係る情報を記憶したネットワークサブグループデータ６６０の一例を示す図である。このネットワークサブグループデータ６６０は、ネットワークサブグループ名、ネットワークサブドメイン名、サブネットおよび冗長化用サブネットの情報を記憶している。
ネットワークサブグループ名は、図１６で例を挙げて説明したようなネットワークサブグループを識別する識別情報である。ネットワークサブドメイン名は、ネットワークサブグループが属するネットワークサブドメインを識別する識別情報である。
サブネットは、ネットワークサブグループに割り当てられるネットワークアドレスおよびサブネットマスクの情報である。冗長化用サブネットは、ネットワークサブグループに属するネットワークが複数のデータ通信回線を用いて冗長化される場合に、余分に追加されたデータ通信回線からなるネットワークに割り当てられるネットワークアドレスおよびサブネットマスクの情報である。
その後、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサーバドメイン間の対応関係に係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバドメイン間リンクデータ６７０として登録する。
図１８は、サーバドメイン間の対応関係に係る情報を記憶したサーバドメイン間リンクデータ６７０の一例を示す図である。このサーバドメイン間リンクデータ６７０は、フロントサーバドメイン名、ネットワークドメイン名およびバックサーバドメイン名の情報を記憶している。
フロントサーバドメイン名は、図１２に示したようなネットワークドメインを挟むサーバドメインのうち、よりインターネット７０側にあるサーバドメインを識別する識別情報である。ネットワークドメイン名は、図１２で説明したネットワークドメインの識別情報である。バックサーバドメイン名は、図１２に示したようなネットワークドメインを挟むサーバドメインのうち、よりインターネット７０から遠い側にあるサーバドメインを示す情報である。
さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサーバドメインとストレージドメインとの間の対応関係に係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバ／ストレージドメイン間リンクデータ６８０として登録する。
図１９は、サーバドメインとストレージドメインとの間の対応関係に係る情報を記憶したサーバ／ストレージドメイン間リンクデータ６８０の一例を示す図である。このサーバ／ストレージドメイン間リンクデータ６８０は、サーバドメイン名およびストレージドメイン名の情報を記憶している。ここで、サーバドメイン名は、図９に示したサーバドメイン名と同様の情報である。ストレージドメイン名は、図１１に示したストレージドメイン名と同様の情報である。
図４の説明に戻ると、システムリソースマネージャ２１は、管理対象となるサーバリソースおよびストレージリソースの登録をおこなう（ステップＳ１０３）。以下に、ステップＳ１０３でおこなわれる処理をさらに詳細に説明する。
まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、サーバを登録する管理サブネットの選択をおこなった際、ユーザにより選択された管理サブネットの情報を受け付ける。
さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して入力した管理対象とするサーバの情報を運用管理クライアント１０から受け付け、その情報をドメイン管理サーバ５０のドメインリソースＤＢ５５に、以下に説明するネットワークブートサーバデータ６９０として記憶する。ここで登録されたサーバは、後にネットワークブートがおこなわれ、サーバの各種情報が取得された後、サーバリソースとして登録される。
図２０は、ネットワークブートがなされるサーバの情報を記憶したネットワークブートサーバデータ６９０の一例を示す図である。このネットワークブートサーバデータ６９０は、ＭＡＣアドレス、ＩＰアドレスおよびホスト名の情報を記憶している。
ＭＡＣアドレスは、サーバのＭＡＣアドレスの情報である。ＩＰアドレスは、サーバに割り当てられたＩＰアドレスの情報である。ホスト名は、サーバに割り当てられたホスト名の情報である。
ここで、システムリソースマネージャ２１は、ネットワークブートをおこなうサーバのユーザにより入力されたＭＡＣアドレスの情報を受け付けた場合に、そのＭＡＣアドレスに対応するサーバに、ＩＰアドレスとホスト名とを自動的に割り当てる。
そして、システムリソースマネージャ２１は、ドメイン管理サーバ５０のシステムリソースドメインマネージャ５１と連携し、ドメイン管理サーバ５０のドメインリソースＤＢ５５に記憶された仮のＯＳを用いて、ＩＰアドレスとホスト名とが割り当てられたサーバのネットワークブートをおこなう。
そして、サーバサブＲＭ５２、リソースマネージャエージェント１１１ａ、および、サーバＲＭエージェント１１２ａが連携することにより、サーバのハードウェアに係る情報を収集し、収集した情報をシステムリソースドメインマネージャ５１に送信する。
その後、システムリソースマネージャ２１は、システムリソースドメインマネージャ５１からサーバのハードウェアに係る情報を取得して、システムリソースＤＢ２６にその情報を、以下に説明する管理対象サーバデータ７００として記憶する。
また、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、ＳＡＮ１７０を介して接続されるストレージ１６０ａ〜１６０ｄからサーバを起動するＳＡＮブートをおこなうか否かの設定情報を入力した場合に、その設定情報を受け付け、その設定情報を管理対象サーバデータ７００に登録する。
図２１は、管理対象となるサーバのデータを記憶した管理対象サーバデータ７００の一例を示す図である。この管理対象サーバデータ７００は、サーバ名、ＩＰアドレス、ＭＡＣアドレス、サーバアーキテクチャ名、モデル名、ＳＡＮブートおよび状態の情報を記憶している。
サーバ名は、管理対象となるサーバを識別する名称である。ＩＰアドレスは、サーバに割り当てられたＩＰアドレスである。ＭＡＣアドレスは、サーバのＭＡＣアドレスである。サーバアーキテクチャ名は、サーバのＣＰＵアーキテクチャの識別情報である。モデル名は、サーバの型式を示す情報である。ＳＡＮブートは、ＳＡＮ１７０を介して接続されるストレージ１６０ａ〜１６０ｄからサーバを起動するＳＡＮブートをおこなうか否かの設定情報である。状態は、サーバに異常が発生しているか否かを示す情報である。
なお、ここでは、ユーザがＭＡＣアドレスを指定してネットワークブートをおこなうサーバを選択することとしているが、サーバの選択を自動的におこなうようにしてもよい。具体的には、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、自動的に選択をおこなうサーバの台数に係る情報を設定した場合に、その設定情報を運用管理クライアント１０から受け付ける。
そして、システムリソースマネージャ２１は、設定された台数分のサーバを選択し、選択したサーバのＩＰアドレスおよびホスト名の情報を、図２０に示したネットワークブートサーバデータ６９０に登録する。
そして、システムリソースマネージャ２１は、ドメイン管理サーバ５０のシステムリソースドメインマネージャ５１と連携し、ドメイン管理サーバ５０のドメインリソースＤＢ５５に記憶された仮のＯＳを用いて、ＩＰアドレスとホスト名とが割り当てられたサーバのネットワークブートをおこなう。
そして、サーバサブＲＭ５２、リソースマネージャエージェント１１１ａ、および、サーバＲＭエージェント１１２ａが連携することにより、各サーバのＭＡＣアドレス、サーバアーキテクチャ、モデル、状態の情報を収集し、収集した情報をシステムリソースドメインマネージャ５１に送信する。
その後、システムリソースマネージャ２１は、システムリソースドメインマネージャ５１から各サーバのＭＡＣアドレス、サーバアーキテクチャ、モデル、状態の情報を取得して、その情報をシステムリソースＤＢ２６に管理対象サーバデータ７００として記憶する。
続いて、システムリソースマネージャ２１は、管理対象となるストレージ機器の登録をおこなう。ここで、ストレージ機器とは、ＦＣ（Fiber Channel）スイッチやＲＡＩＤ装置などの機器である。
具体的には、システムリソースマネージャ２１は、管理対象として登録するストレージのＩＰアドレスの情報が、図７に示した管理サブネットごとにユーザにより入力された場合に、その情報を運用管理クライアント１０から受け付ける。そして、システムリソースマネージャ２１は、ＩＰアドレスに対応するストレージ機器の情報をシステムリソースＤＢ２６に記憶することによりストレージ機器を登録する。
その後、システムリソースマネージャ２１は、図２１の管理対象サーバデータ７００に登録されたサーバをサーバドメインに追加する処理をおこなう。具体的には、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作してサーバとそのサーバを追加するサーバドメインを指定した場合に、そのサーバおよびサーバドメインの情報を運用管理クライアント１０から受け付ける。
そして、システムリソースマネージャ２１は、図２１に示した管理対象サーバデータ７００を参照し、サーバのサーバアーキテクチャが、図９に示したサーバドメインデータ３４０に登録されているサーバアーキテクチャと一致することをチェックする。
また、システムリソースマネージャ２１は、図２１に示した管理対象サーバデータ７００を読み込み、サーバがＳＡＮブートをおこなうように設定されていることをチェックする。
さらに、システムリソースマネージャ２１は、サーバドメインに追加するサーバのネットワークの結線状態をチェックする。具体的には、システムリソースマネージャ２１は、図１８に示したサーバドメイン間リンクデータ６７０を読み込み、サーバドメインに対するフロントサーバドメインおよびバックサーバドメインの情報を取得する。
そして、システムリソースマネージャ２１は、図１４に示したネットワークドメインデータ４８０を読み込み、ネットワークドメインに対応するフロントサブドメインおよびバックサブドメインの情報を取得する。
その後、システムリソースマネージャ２１は、図１３に示したネットワークサブドメインデータ４７０を読み込み、フロントサブドメインおよびバックサブドメインに対応するスイッチを特定する。
そして、システムリソースマネージャ２１は、ネットワークＲＭ２４およびネットワークサブＲＭ５４に対して、サーバとスイッチ間の結線をチェックするよう要求する。さらに、ネットワークＲＭ２４およびネットワークサブＲＭ５４は、ネットワークＲＭエージェント１１４ａにサーバとスイッチとの間の結線をチェックするよう要求し、チェック結果を取得する。
そして、システムリソースマネージャ２１は、サーバとスイッチとの間の結線に問題がない場合、そのサーバに係る情報を図１０で説明したプールグループに対応付けて、以下に説明するプロビジョニング構成データ７１０としてシステムリソースＤＢ２６に記憶する。
図２２は、サーバが属するグループの情報を記憶したプロビジョニング構成データ７１０の一例を示す図である。このプロビジョニング構成データ７１０は、サーバ名、プールグループ名、サーバグループ名、ストレージサブグループ名、アクセス可否の情報を記憶する。
サーバ名は、図２１で説明したサーバ名と同様の情報である。プールグループ名は、図１０で説明したプールグループ名と同様の情報である。サーバグループ名は、同一のサーバドメインに含まれるサーバを１つまたは複数のグループに分けた場合のグループの識別情報である。この段階では、サーバグループ名の情報はまだ登録されない。
ストレージサブグループ名は、ストレージドメインに属するストレージを１つまたは複数のグループに分け、サーバグループに属する各サーバに割り当てた場合に、各サーバに割り当てたグループの識別情報である。この段階では、ストレージサブグループ名の情報はまだ登録されない。アクセス可否は、サーバによるストレージへのアクセスを許可するか否かを示す情報である。この段階では、アクセス可否の情報はまだ登録されない。
プロビジョニング構成データ７１０にサーバ名およびプールグループを登録した後、システムリソースマネージャ２１は、先に登録したストレージ機器をストレージドメインに登録する。
具体的には、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、ストレージドメインとストレージドメインに登録するストレージ機器とを指定した場合に、それらの情報を運用管理クライアント１０から受け付ける。
そして、システムリソースマネージャ２１は、図１９に示したサーバ／ストレージドメイン間リンクデータ６８０を読み込んで、ストレージドメインに対応するサーバドメインを特定する。
さらに、システムリソースマネージャ２１は、ストレージＲＭ２５およびストレージＲＭエージェント１１５ａと連携して、特定されたサーバドメインに属するサーバと、ストレージドメインに属するストレージ機器との間の結線の均一性をチェックする。
図２３は、結線状態が均一であるサーバとストレージ機器との結線の一例を示す図である。図２３に示すように、この例では、ストレージドメイン７４０に属するＦＣスイッチ７５０ａ、および、サーバドメイン７２０に属するサーバ７３０ａ，７３０ｂ間の結線状態と、ストレージドメイン７４０に属するＦＣスイッチ７５０ｂ、および、サーバ７３０ａ，７３０ｂ間の結線状態とが均一になっている。
また、ＦＣスイッチ７５０ａ，７５０ｂ、および、ストレージドメイン７４０に属するＲＡＩＤ装置７６０ａ間の結線状態と、ＦＣスイッチ７５０ａ，７５０ｂ、および、ストレージドメイン７４０に属するＲＡＩＤ装置７６０ｂ間の結線状態が均一になっている。
システムリソースマネージャ２１は、上記結線の均一性のチェックをＷＷＰＮ（World
Wide Port Name）の情報を基にしておこなう。その際、システムリソースマネージャ２１は、図１１に示したストレージドメインデータ３６０からストレージドメインのパスの多重度の情報を読み込み、冗長度のチェックも併せておこなう。図２４は、ＷＷＰＮに基づく結線の均一性チェック処理を説明する図である。
図２４には、図２３に示したＲＡＩＤ装置７６０ａ，７６０ｂが記憶しているＲＡＩＤ装置ＷＷＰＮデータ７７０ａ，７７０ｂと、ＦＣスイッチ７５０ａ，７５０ｂが記憶しているＦＣスイッチＷＷＰＮデータ７８０ａ，７８０ｂと、サーバ７３０ａ，７３０ｂが記憶しているサーバＷＷＰＮデータ７９０ａ，７９０ｂとが示されている。
ＲＡＩＤ装置ＷＷＰＮデータ７７０ａ，７７０ｂは、ＣＡ（Channel Adapter）およびＷＷＰＮの情報を記憶している。ＣＡは、ＲＡＩＤ装置７６０ａ，７６０ｂが有するチャネルアダプタの識別情報である。ＷＷＰＮは、ＲＡＩＤ装置７６０ａ，７６０ｂが有するチャネルアダプタに割り当てられているＷＷＰＮの情報である。
ＦＣスイッチＷＷＰＮデータ７８０ａ，７８０ｂは、ｐｏｒｔおよび相手先ＷＷＰＮの情報を記憶している。ｐｏｒｔは、ＦＣスイッチ７５０ａ，７５０ｂのポートの識別情報である。相手先ＷＷＰＮは、ＦＣスイッチ７５０ａ，７５０ｂのポートに接続されているＲＡＩＤ装置７６０ａ，７６０ｂのチャネルアダプタに割り当てられているＷＷＰＮの情報、または、ＦＣスイッチ７５０ａ，７５０ｂのポートに接続されているサーバ７３０ａ，７３０ｂのＨＢＡ（Host Bus Adapter）に割り当てられたＷＷＰＮの情報である。
サーバＷＷＰＮデータ７９０ａ，７９０ｂは、ＨＢＡおよびＷＷＰＮの情報を記憶している。ＨＢＡは、サーバ７３０ａ，７３０ｂが有するＨＢＡの識別情報である。ＷＷＰＮは、サーバ７３０ａ，７３０ｂが有するＨＢＡに割り当てられているＷＷＰＮの情報である。
システムリソースマネージャ２１は、ＲＡＩＤ装置ＷＷＰＮデータ７７０ａ，７７０ｂ、ＦＣスイッチＷＷＰＮデータ７８０ａ，７８０ｂ、および、サーバＷＷＰＮデータ７９０ａ，７９０ｂをＲＡＩＤ装置７６０ａ，７６０ｂ、ＦＣスイッチ７５０ａ，７５０ｂ、および、サーバ７３０ａ，７３０ｂから収集し、ＷＷＰＮの対応関係を調べることにより、各装置間の結線状態の均一性をチェックすることができる。
その後、システムリソースマネージャ２１は、あらかじめ設定されているＬＵＮ（Logical Unit）の記憶領域と、ＬＵＮが未設定の記憶領域とをプール用のストレージとして登録する。
続いて、システムリソースマネージャ２１は、サーバグループの作成処理をおこなう（ステップＳ１０４）。以下に、ステップＳ１０４でおこなわれる処理をさらに詳細に説明する。
まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したストレージテンプレートに係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するストレージテンプレートデータ８００として登録する。ここで、ストレージテンプレートとは、後に作成されるサーバグループ用のストレージの構成に係る設定情報である。
図２５は、ストレージテンプレートに係るデータを記憶したストレージテンプレートデータ８００の一例を示す図である。このストレージテンプレートデータ８００は、ストレージテンプレート名、ディスク種別、ディスク名、信頼性の必要度、負荷の度合い、ディスク容量およびブートディスクの情報を記憶している。
ストレージテンプレート名は、設定されたストレージテンプレートを識別する識別情報である。ディスク種別は、ストレージテンプレートに属するディスクの用途の種別を示す情報である。
たとえば、「root」は、そのディスクがシステムデータを記憶するために利用されることを示し、「local」は、そのディスクがサーバ個別のデータを記憶するために利用されることを示し、「shared」は、そのディスクがサーバ間で共有されるデータを記憶するために利用されることを示す。
ディスク名は、各ディスクに割り当てられたディスクを識別する名称である。信頼性の必要度は、ディスクに必要とされる信頼性の情報である。負荷の度合いは、ディスクにかかる負荷の度合いの情報である。ディスク容量は、ディスクの記憶容量である。ブートディスクは、そのディスクがシステムのブート用に利用されるものか否かを示す情報である。
続いて、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサーバグループの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバグループデータ８１０として記憶する。
図２６は、サーバグループに係る情報を記憶したサーバグループデータ８１０の一例を示す図である。このサーバグループデータ８１０は、サーバグループ名、サーバドメイン名、ソフトウェア配布イメージ名、版数、ストレージテンプレート名、ＳＡＮブートおよび自動リカバリの情報を記憶している。
サーバグループ名は、同一のサーバドメインに含まれるサーバを１つまたは複数のグループに分けた場合のグループの識別情報である。サーバドメイン名は、サーバグループが属するサーバドメインの識別情報である。ソフトウェア配布イメージ名は、サーバグループに属するサーバに配布するソフトウェアのイメージファイルを識別する情報である。
版数は、ソフトウェア配布イメージの版数の情報である。ストレージテンプレート名は、図２５で説明したストレージテンプレート名と同様の情報である。ＳＡＮブートは、サーバグループに属するサーバのＳＡＮブートをおこなうか否かを示す情報である。自動リカバリは、複数のサーバが連携して動作するスケールアウト構成のサーバが故障した場合に、自動的にサーバを追加する処理を実行するか否かを示す情報である。
その後、システムリソースマネージャ２１は、システムリソースＤＢ２６に、サーバグループに対応するストレージグループの情報を、以下に説明するサーバ／ストレージグループリンクデータ８２０として登録する。ここで、ストレージグループとは、同一のストレージドメインに含まれるストレージを１つまたは複数のグループに分けたものである。
図２７は、サーバグループに対応するストレージグループの情報を記憶したサーバ／ストレージグループリンクデータ８２０の一例を示す図である。このサーバ／ストレージグループリンクデータ８２０は、サーバグループ名、ストレージグループ名およびストレージドメイン名の情報を記憶している。
サーバグループ名は、図２６に示したサーバグループ名と同様の情報である。ストレージグループ名は、各サーバグループに対応して生成されたストレージグループの識別情報である。ストレージドメイン名は、ストレージグループが属するストレージドメインの識別情報である。
ストレージグループを生成する際には、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０から、サーバグループに対応付けられたストレージテンプレートの情報を読み込み、図２５に示したストレージテンプレートデータ８００からストレージテンプレートに対応するディスク種別の情報を読み込む。
そして、システムリソースマネージャ２１は、「root」や「local」、「shared」などのディスク種別ごとに、ストレージグループを各サーバグループに対して生成し、その情報をサーバ／ストレージグループリンクデータ８２０に登録する。
さらに、システムリソースマネージャ２１は、図１９に示したサーバ／ストレージドメイン間リンクデータから、サーバグループが属するサーバドメインに対応するストレージドメインの情報を読み込み、その情報をサーバ／ストレージグループリンクデータ８２０に登録する。
その後、システムリソースマネージャ２１は、サーバグループを追加したことをＡＰ管理部１１６ａに認識させるコマンドをＡＰ管理部１１６ａに送信する。具体的には、システムリソースマネージャ２１は、図８に示した「issvgrp add」をＡＰ管理部１１６ａに送信する。
続いて、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサーバグループ間の対応関係の情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバグループ間リンクデータ８３０として登録する。
図２８は、サーバグループ間の対応関係に係る情報を記憶したサーバグループ間リンクデータ８３０の一例を示す図である。このサーバグループ間リンクデータ８３０は、フロントサーバグループ名、ネットワークグループ名およびバックサーバグループ名の情報を記憶している。
フロントサーバグループ名は、ネットワークグループにより連結されるサーバグループのうち、よりインターネット７０側にあるサーバグループを識別する識別情報である。ここで、ネットワークグループとは、サーバグループ間を連結するよう図１６で説明したネットワークサブグループを結合したネットワークのグループである。
ネットワークグループ名は、上記ネットワークグループを識別する識別情報である。バックサーバグループ名は、ネットワークグループにより連結されるサーバグループのうち、インターネット７０から遠い側にあるサーバグループを識別する識別情報である。
その後、システムリソースマネージャ２１は、システムリソースＤＢ２６に、ネットワークグループに係る情報を、以下に説明するネットワークグループデータ８５０として記憶する。
具体的には、システムリソースマネージャ２１は、まず、図１８に示したサーバドメイン間リンクデータ６７０を読み込み、２つのサーバドメインに挟まれて設定されているネットワークドメインの情報を取得する。
そして、システムリソースマネージャ２１は、図１４に示したネットワークドメインデータ４８０を読み込み、ネットワークドメインに対応するフロントサブドメイン、バックサブドメインおよび機器の情報を取得する。
さらに、システムリソースマネージャ２１は、図１７に示したネットワークサブグループデータ６６０を読み込み、フロントサブドメイン、および、バックサブドメインに対応するネットワークサブドメインをネットワークサブグループデータ６６０から検索し、検索したネットワークサブドメインに対応するネットワークサブグループのうち、未使用のネットワークサブグループを抽出する。
続いて、システムリソースマネージャ２１は、図１４に示したネットワークドメインデータ４８０から読み込んだ機器の情報に該当するネットワーク機器を１つまたは複数のグループに分けて、システムリソースＤＢ２６にその情報を、以下に説明する負荷分散グループデータ８４０として記憶する。
図２９は、負荷分散装置のグループ情報を記憶した負荷分散グループデータ８４０の一例を示す図である。この負荷分散グループデータ８４０は、負荷分散グループ名、ロードバランサ名および代表ＩＰの情報を記憶している。
負荷分散グループ名は、ロードバランサを１つまたは複数のグループに分けた場合のグループを識別する情報である。ロードバランサ名は、ロードバランサを識別する名称である。代表ＩＰは、各負荷分散グループに割り当てられたＩＰアドレスの情報である。
その後、システムリソースマネージャ２１は、上記各ネットワークグループに属するネットワークドメインやネットワークサブグループ、負荷分散グループなどの対応関係の情報に基づいて、システムリソースＤＢ２６にその情報を、以下に説明するネットワークグループデータ８５０として記憶する。
図３０は、ネットワークグループに係る情報を記憶したネットワークグループデータ８５０の一例を示す図である。このネットワークグループデータ８５０は、ネットワークグループ名、ネットワークドメイン名、フロントネットワークサブグループ名、負荷分散グループ名およびバックネットワークサブグループ名の情報を記憶している。
ネットワークグループ名は、図２８で説明したネットワークグループと同様の情報である。ネットワークドメイン名は、図１８で説明したネットワークドメインと同様の情報である。
フロントネットワークサブグループ名は、図１７で説明したネットワークサブグループ名に対応するものであり、負荷分散グループを挟むネットワークサブグループのうち、よりインターネット７０側にあるネットワークサブグループを識別する識別情報である。
負荷分散グループ名は、図２９で説明した負荷分散グループ名と同様の情報である。バックネットワークサブグループ名は、図１７で説明したネットワークサブグループ名に対応するものであり、負荷分散グループを挟むネットワークサブグループのうち、よりインターネット７０から遠い側にあるネットワークサブグループを識別する識別情報である。
さらに、システムリソースマネージャ２１は、ネットワークＲＭ２４およびネットワークサブＲＭ５４と連携し、図１３のネットワークサブドメインデータ４７０に登録されたスイッチに対して、ネットワークサブグループのＶＬＡＮの設定をおこなう。
続いて、システムリソースマネージャ２１は、サーバグループに一台目のサーバを追加して、そのサーバに導入されたソフトウェアのソフトウェアイメージを作成する処理をおこなう（ステップＳ１０５）。以下に、ステップＳ１０５でおこなわれる処理をさらに詳細に説明する。
まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、サーバとそのサーバを登録するサーバグループを指定した場合に、サーバおよびサーバグループの情報を受け付け、サーバグループにサーバを登録する。
そして、システムリソースマネージャ２１は、図２６のサーバグループデータ８１０を読み込んでサーバグループに対応するストレージテンプレートを検索し、そのストレージテンプレートの設定条件を図２５のストレージテンプレートデータ８００から取得する。
さらに、ストレージＲＭ２５は、システムリソースマネージャ２１により取得されたストレージテンプレートの設定条件を満足するようプールされたストレージに論理ボリュームを設定し、論理ボリュームが設定されたストレージを上記サーバグループに割り当てる処理をおこなう。
図３１は、論理ボリュームをＲＡＩＤ装置に設定する設定処理の処理手順を示すフローチャートである。図３１に示すように、まず、システムリソースマネージャ２１は、論理ボリュームの必要条件の情報を取得する（ステップＳ２０１）。ここで、論理ボリュームの必要条件とは、図２５のストレージテンプレートデータ８００に記憶された信頼性の必要度、負荷の度合い、および、ディスク容量の情報である。
図３２は、論理ボリュームの設定画面の一例を示す図である。図３２には、システムリソースマネージャ２１が、運用管理クライアント１０に対して出力する論理ボリュームの必要条件を表示した必要条件出力画面８６０と、論理ボリューム設定後の論理ボリューム構成出力画面８８０とが示されている。
図３２の例では、３つの必要条件を満足する３つの論理ボリュームを作成するよう要求された場合が示されている。そして、必要条件出力画面８６０には、３つの必要条件８７０ａ〜８７０ｃが出力される。
図３１の説明に戻ると、システムリソースマネージャ２１は、信頼性の必要度および負荷の度合いに応じて、ＲＡＩＤ装置のＲＡＩＤレベルを決定する（ステップＳ２０２）。図３３は、ＲＡＩＤレベルの設定情報を記憶したＲＡＩＤレベル設定データ９４０の一例を示す図である。
このＲＡＩＤレベル設定データ９４０は、信頼性の必要度、負荷の度合いおよびＲＡＩＤレベルの情報を記憶している。信頼性の必要度は、図２５で説明した信頼性の必要度と同様の情報である。負荷の度合いは、図２５で説明した負荷の度合いと同様の情報である。ＲＡＩＤレベルは、信頼性の必要度および負荷の度合いにより決定されるＲＡＩＤレベルの情報である。
図３１の説明に戻ると、システムリソースマネージャ２１は、必要とされるディスク容量の合計値から、ＲＡＩＤ装置種を決定する（ステップＳ２０３）。図３４は、ＲＡＩＤ装置に係る情報を記憶したＲＡＩＤ装置データ９５０の一例を示す図である。
このＲＡＩＤ装置データ９５０は、必要な記憶容量合計値、ＲＡＩＤ装置の型名、データアクセススピード、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）およびＲＡＩＤグループの最大数の情報を記憶している。
必要な記憶容量合計値は、論理ボリュームに必要とされるディスク容量の合計値の情報である。ＲＡＩＤ装置の型名は、必要な記憶容量合計値を確保するのに適したＲＡＩＤ装置の型名の情報である。
データアクセススピードは、ＲＡＩＤ装置の型名により特定されるディスクドライブのデータのアクセススピードの情報である。このデータアクセススピードには、アクセススピードが速い順に、「一番目」、「二番目」、「三番目」の３つのディスクドライブ種の情報が記憶されている。
ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）は、ＲＡＩＤレベルがＲＡＩＤ０＋１の場合において、ＲＡＩＤグループを構成するディスクドライブの数の情報である。ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）は、ＲＡＩＤレベルがＲＡＩＤ５の場合において、ＲＡＩＤグループを構成するディスクドライブの数の情報である。ＲＡＩＤグループの最大数は、作成するＲＡＩＤグループの最大数の情報である。
図３１の説明に戻ると、システムリソースマネージャ２１は、図３４で説明したＲＡＩＤ装置データ９５０から、ＲＡＩＤ装置種ごとの特有情報を取得する（ステップＳ２０４）。
ここで、特有情報とは、データアクセススピードのうち、「一番目」に該当するディスクドライブ種、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）およびＲＡＩＤグループの最大数の情報である。
そして、ストレージＲＭ２５は、論理ボリュームを作成する（ステップＳ２０５）。具体的には、ストレージＲＭ２５は、論理ボリュームの各必要条件を満足する論理ボリュームを作成し、ＲＡＩＤ装置に論理ボリュームを設定する。
図３２に示した論理ボリューム構成出力画面８８０には、各必要条件９００ａ〜９００ｃを満足する論理ボリューム９１０ａ〜９１０ｄ，９２０ａ〜９２０ｅが、ＲＡＩＤ装置８９０に設定された状況が示されている。
図３１の説明に戻ると、ストレージＲＭ２５は、ＲＡＩＤレベルが同一である論理ボリュームをグループ化したＲＡＩＤグループを作成する（ステップＳ２０６）。そして、ストレージＲＭ２５は、作成したＲＡＩＤグループに論理ボリュームを割り当てる（ステップＳ２０７）。
図３２の例では、必要条件９００ａおよび必要条件９００ｂを満足する論理ボリューム９１０ａ〜９１０ｄは、ＲＡＩＤレベルがＲＡＩＤ０＋１で同じであるので、ＲＡＩＤグループ９３０ａにグループ化されている。また、必要条件９００ｃを満足する論理ボリューム９２０ａ〜９２０ｅは、ＲＡＩＤレベルがＲＡＩＤ５であるので、ＲＡＩＤグループ９３０ｂとしてグループ化されている。
ＲＡＩＤグループを作成する際には、ストレージＲＭ２５は、各ＲＡＩＤグループに属するディスクドライブを、図３４のＲＡＩＤ装置データ９５０のデータアクセススピードにより決定されるディスクドライブ種に設定する。
また、ストレージＲＭ２５は、ＲＡＩＤグループを構成するディスクドライブ数を、図３４のＲＡＩＤ装置データ９５０のＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）、または、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）により決定されるディスクドライブ数に設定する。
さらに、ストレージＲＭ２５は、ＲＡＩＤグループの数が図３４のＲＡＩＤ装置データ９５０のＲＡＩＤグループの最大数以下になるようＲＡＩＤグループを作成する。
図３２の論理ボリューム構成出力画面８８０では、必要条件９００ａ〜９００ｃを満足し、各ＲＡＩＤグループ９３０ａ，９３０ｂに割り当てられた論理ボリューム９１０ａ〜９１０ｄ，９２０ａ〜９２０ｅが、対応する必要条件９００ａ〜９００ｃと線で結合されて表示されている。
図３１の説明に戻ると、ストレージＲＭ２５は、図３２に示した論理ボリュームの構成をＲＡＩＤ装置に反映させるコマンドファイルを作成する（ステップＳ２０８）。そして、ストレージＲＭ２５は、そのコマンドファイルに基づいて、作成した論理ボリュームを実装置に反映させる（ステップＳ２０９）。
その後、システムリソースマネージャ２１は、各サーバが属するサーバグループに対応付けて、ＲＡＩＤ装置に設定された論理ボリュームをストレージサブグループとして登録し、サーバのストレージグループに対するアクセス権を設定する。具体的には、システムリソースマネージャ２１は、図２２に示したプロビジョニング構成データ７１０にサーバグループ名、ストレージサブグループ名およびアクセス可否の情報を記憶する。
図３５は、ストレージサブグループが設定されたプロビジョニング構成データ９６０の一例を示す図である。このプロビジョニング構成データ９６０には、図２２に示したプロビジョニング構成データ７１０にサーバグループ名、ストレージサブグループ名およびアクセス可否の情報が追加されている。
ＲＡＩＤ装置に構築された論理ボリュームをサーバに認識させ、ストレージサブグループとして登録する場合には、ストレージＲＭ２５は、以下のような手順で論理ボリュームの設定をおこなう。
図３６は、サーバに論理ボリュームを認識させる論理ボリュームの設定処理の処理手順を示すフローチャートである。図３６に示すように、まず、ストレージＲＭ２５は、ＲＡＩＤ装置の論理ボリュームをグループ化し、アフィニティグループを設定する（ステップＳ３０１）。
ここで、アフィニティグループとは、サーバが認識する論理ユニット番号（ＬＵＮ， Logical Unit Number）とＲＡＩＤ装置における論理ボリューム（ＬＶ， Logical Volume）番号との間の対応関係を示す情報である。
図３７は、ＲＡＩＤ装置に構築された論理ボリュームの設定処理を説明する説明図である。図３７には、サーバ「A」およびサーバ「B」から構成されるサーバグループ９７０と、論理ボリューム「LV0」、「LV1」、「LV2」、「LV3」が構築されたＲＡＩＤ装置「α」、および、論理ボリューム「LV10」、「LV11」、「LV12」、「LV13」が構築されたＲＡＩＤ装置「β」から構成されるストレージプール９８０とが示されている。
さらに、図３７には、ストレージプール９８０からＲＡＩＤ装置「α」の論理ボリューム「LV0」および「LV1」と、ＲＡＩＤ装置「β」の論理ボリューム「LV12」および「LV13」とが追加されたストレージグループ９９０が示されている。
ストレージグループ９９０に追加されたＲＡＩＤ装置「α」の論理ボリューム「LV0」および「LV1」は、アフィニティグループ「AG0」およびアフィニティグループ「AG1」に属するように設定されている。また、ＲＡＩＤ装置「β」の論理ボリューム「LV12」および「LV13」は、アフィニティグループ「AG10」およびアフィニティグループ「AG11」に属するように設定されている。
図３８は、アフィニティグループに係る情報を記憶したアフィニティグループデータ１０１０である。このアフィニティグループデータ１０１０は、ＲＡＩＤ装置名、アフィニティグループ名、ＬＵＮおよびＬＶの情報を記憶している。
ＲＡＩＤ装置名は、各ＲＡＩＤ装置を識別する識別情報である。アフィニティグループ名は、各ＲＡＩＤ装置において設定されたアフィニティグループの識別情報である。ＬＵＮは、サーバＡまたはサーバＢからアクセスする際に論理ボリュームを識別する識別情報である。ＬＶは、論理ボリュームを識別する識別情報である。
図３６の説明に戻ると、ストレージＲＭ２５は、サーバ「A」およびサーバ「B」と、論理ボリューム「LV0」，「LV1」，「LV12」，「LV13」との間の冗長パスをチェックし、パスを選択することによりアクセスパスを設定する（ステップＳ３０２）。
そして、ストレージＲＭ２５は、論理ユニットに対するマルチパスの設定をおこなう（ステップＳ３０３）。図３９は、マルチパスの構成に係る情報を記憶したマルチパス構成データ１０２０の一例を示す図である。
このマルチパス構成データ１０２０は、マルチパスインスタンス名およびＬＵＮの情報を記憶している。マルチパスインスタンス名は、設定されたマルチパスのインスタンスを識別する情報である。ＬＵＮは、設定されたマルチパスインスタンスに対応し、サーバ「A」またはサーバ「B」により認識される論理ユニットを識別する情報である。
そして、ストレージＲＭ２５は、設定したマルチパスインスタンスをミラーボリュームの構成要素としてクラスタリングをおこなうサーバのクラスタリソースに登録する（ステップＳ３０４）。その後、ストレージＲＭ２５は、クラスタリソースに登録されたマルチパスインスタンスを用いて異なるＲＡＩＤ装置のボリュームどうしをペアとするミラーボリュームグループを設定する（ステップＳ３０５）。
図３７には、サーバ「A」またはサーバ「B」において内部設定されるサーバ内ストレージ構成１０００が示されている。このストレージ構成１０００においては、マルチパスインスタンス「mplb0」およびマルチパスインスタンス「mplb2」とから構成されるミラーボリューム「M0」と、マルチパスインスタンス「mplb1」およびマルチパスインスタンス「mplb3」とから構成されるミラーボリューム「M1」とが設定されている。
図４０は、ミラーボリュームの構成に係る情報を記憶したミラーボリューム構成データ１０３０である。このミラーボリューム構成データ１０３０は、ミラーボリュームおよび構成ディスクの情報を記憶している。
ミラーボリュームは、設定されたミラーボリュームを識別する識別情報である。構成ディスクは、ミラーボリュームを構成する論理ユニットを識別する識別情報である。ここで、構成ディスクには、図３９に示したマルチパス構成データ１０２０におけるマルチパスインスタンスの情報が記憶されているが、マルチパス構成データ１０２０を参照することにより、ミラーボリュームに対応するＬＵＮを特定することができる。
図３８に示したアフィニティグループデータ１０１０は、ストレージＲＭ２５によりシステムリソースＤＢ２６およびＲＡＩＤ装置内に記憶される。また、図３９に示したマルチパス構成データ１０２０、および、図４０に示したミラーボリューム構成データ１０３０は、ストレージＲＭ２５によりシステムリソースＤＢ２６に記憶されるとともに、ストレージＲＭエージェント１１５ａにより管理対象であるサーバ内に記憶される。
図４に示すステップＳ１０５におけるソフトウェアイメージの作成処理の説明に戻ると、ネットワークＲＭ２４は、サーバグループに登録したサーバのネットワークの設定をつぎにおこなう。
具体的には、ネットワークＲＭ２４は、図２８に示したサーバグループ間リンクデータ８３０から、サーバを追加したサーバグループをフロントサーバグループおよびバックサーバグループとして有するネットワークグループの情報を読み込む。
さらに、ネットワークＲＭ２４は、図３０に示したネットワークグループデータ８５０を読み込み、ネットワークグループに対応するフロントネットワークサブグループおよびバックネットワークサブグループを抽出する。
その後、ネットワークＲＭ２４は、図１７に示したネットワークサブグループデータ６６０を読み込み、フロントネットワークサブグループおよびバックネットワークサブグループに対応するネットワークサブグループを検索し、ネットワークサブグループに割り当てられたサブネットの情報を基にして、サーバにＩＰアドレスを割り当てる。
図４１は、サーバに割り当てられたＩＰアドレスに係る情報を記憶したＩＰアドレス管理データ１０４０の一例を示す図である。このＩＰアドレス管理データ１０４０は、システムリソースマネージャ２１により、システムリソースＤＢ２６に記憶される。
このＩＰアドレス管理データ１０４０は、ＩＰアドレスおよび割当先の情報を記憶している。ＩＰアドレスは、サーバに割り当てられたＩＰアドレスの情報である。割当先は、ＩＰアドレスの割当先であるサーバを識別する情報である。
続いて、ネットワークＲＭ２４は、図２９に示した負荷分散グループデータ８４０および図３０に示したネットワークグループデータ８５０を基にして、サーバが追加されたサーバグループに対応するネットワークグループに代表ＩＰアドレスを有する負荷分散グループを割り当てる。なお、この時点では、ロードバランサの負荷分散機能は停止状態にある。
その後、ユーザは、サーバに導入するＯＳなどのソフトウェアを、サーバグループに追加するサーバに対応付けられたストレージサブグループにインストールする。このストレージサブグループは、ＳＡＮの技術を用いて構成されたものである。
そして、インストールの終了後、ソフトウェアサブＲＭ５３は、ソフトウェアＲＭ２３およびソフトウェアＲＭエージェント１１３ａと連携して、ＯＳ、デバイスドライバ、アプリケーションソフトウェアなどのソフトウェアの集合体から構成されるソフトウェアイメージを作成し、作成したソフトウェアイメージをドメインリソースＤＢ５５に記憶する。
具体的には、ソフトウェアＲＭ２３は、図８に示したミドルウェア連携ＩＦデータ３３０を読み込み、ソフトウェアＲＭエージェント１１３ａは、ミドルウェアにより実現される機能部であるＡＰ管理部１１６ａに対して、ソフトウェアイメージ採取前に実行が必要なコマンドを送信する。
すなわち、ソフトウェアＲＭエージェント１１３ａは、ＡＰ管理部１１６ａの機能を停止させるコマンドを送信し、ＡＰ管理部１１６ａの機能を停止させる。そして、ソフトウェアサブＲＭ５３は、サーバのシステムをシャットダウンする。さらに、ソフトウェアサブＲＭ５３は、サーバのドメイン管理サーバ５０のドメインリソースＤＢ５５に記憶された仮のＯＳを用いてサーバのネットワークブートをおこなう。
その後、ソフトウェアサブＲＭ５３は、起動したサーバに導入されているソフトウェアのソフトウェアイメージを作成する。そして、ソフトウェアＲＭ２３は、システムリソースＤＢ２６にソフトウェアイメージに係る情報を、以下に説明するソフトウェアイメージ管理データ１０５０として登録する。
図４２は、ソフトウェアイメージに係る情報を記憶したソフトウェアイメージ管理データ１０５０の一例を示す図である。このソフトウェアイメージ管理データ１０５０は、ソフトウェアイメージ名、形式、ＯＳ属性およびソフトウェア名の情報を記憶している。
ソフトウェアイメージ名は、ソフトウェアイメージの名称である。形式は、ソフトウェアイメージがアーカイブ形式で作成されたものであるのか、パッチ形式で作成されたものであるのかを示す情報である。ＯＳ属性は、ソフトウェアイメージが、ＯＳのソフトウェアイメージであるか否かを示す情報である。ソフトウェア名は、ソフトウェアイメージが作成されたソフトウェアの名称である。
さらに、ソフトウェアサブＲＭ５３は、作成したソフトウェアイメージを基にして、他のサーバ用に配布するソフトウェア配布イメージを作成する。具体的には、ソフトウェアサブＲＭ５３は、一台目のサーバ用にストレージに導入された複数のソフトウェアのソフトウェアイメージを組にしたソフトウェア配布イメージを作成する。
そして、システムリソースマネージャ２１は、システムリソースＤＢ２６にソフトウェア配布イメージに係る情報を、以下に説明するソフトウェア配布イメージ管理データ１０６０として記憶する。
図４３は、ソフトウェア配布イメージに係る情報を記憶したソフトウェア配布イメージ管理データ１０６０の一例を示す図である。このソフトウェア配布イメージ管理データ１０６０は、ソフトウェア配布イメージ名、版数、サーバアーキテクチャ名およびソフトウェアイメージ／スナップショット名の情報を記憶している。
ソフトウェア配布イメージ名は、ソフトウェア配布イメージの名称である。版数は、ソフトウェア配布イメージの版数である。サーバアーキテクチャ名は、ソフトウェア配布イメージの配布対象となるサーバのＣＰＵアーキテクチャを識別する識別情報である。ソフトウェアイメージ／スナップショット名は、ソフトウェア配布イメージに含まれるソフトウェアイメージまたはスナップショットを識別する識別情報である。
ここでスナップショットとは、ある特定の時点でサーバに導入されているソフトウェアのソフトウェアイメージである。システムリソースマネージャ２１は、システムリソースＤＢ２６にスナップショットに係る情報を、以下に説明するスナップショット管理データ１０７０として登録する。
図４４は、スナップショットに係る情報を記憶したスナップショット管理データ１０７０の一例を示す図である。このスナップショット管理データ１０７０は、スナップショット名およびソフトウェアイメージ名の情報を記憶している。スナップショット名は、スナップショットの名称である。ソフトウェアイメージ名は、スナップショットに含まれるソフトウェアイメージを識別する識別情報である。
その後、ソフトウェアＲＭ２３は、図８に示したミドルウェア連携ＩＦデータ３３０を読み込み、ソフトウェアＲＭエージェント１１３ａは、ミドルウェアにより実現される機能部であるＡＰ管理部１１６ａに対して、ソフトウェアイメージ採取後に実行が必要なコマンドを送信する。
具体的には、ソフトウェアＲＭエージェント１１３ａは、停止していたＡＰ管理部１１６ａを始動させるコマンドを送信し、ＡＰ管理部１１６ａを始動させる。そして、ネットワークＲＭ２４は、スイッチにＶＬＡＮの設定をおこなってサーバをＶＬＡＮに接続するとともに、ロードバランサの負荷分散機能を始動させ、負荷を分散させる対象サーバとして当該サーバを割り当てる。
その後、システムリソースマネージャ２１は、図８に示したミドルウェア連携ＩＦデータ３３０を読み込み、ミドルウェアにより実現される機能部であるＡＰ管理統括部２７に対して、サーバグループ作成後に実行が必要なコマンドを送信する。
具体的には、システムリソースマネージャ２１はＡＰ管理統括部２７に対して、サーバグループの追加を認識させるコマンドを送信する。そして、ＡＰ管理統括部２７は、ＡＰ管理部１１６ａと連携して、サーバに対してアプリケーションプログラムの導入および設定などをおこない、サーバを業務で利用可能な状態に設定する。
図４の説明に戻ると、システムリソースマネージャ２１は、二台目以降のサーバをサーバグループに追加する処理をおこなう（ステップＳ１０６）。以下に、ステップＳ１０６でおこなわれる処理をさらに詳細に説明する。
図４５は、サーバをサーバグループに追加する処理の処理手順を示すフローチャートである。図４５に示すように、まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、サーバとそのサーバを登録するサーバグループを指定した場合に、サーバおよびサーバグループの情報を受け付ける（ステップＳ４０１）。
そして、システムリソースマネージャ２１は、サーバグループにサーバを登録する（ステップＳ４０２）。続いて、システムリソースマネージャ２１は、図２１に示した管理対象サーバデータ７００および図４３に示したソフトウェア配布イメージ管理データ１０６０を読み込んで、サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものか否かを調べる（ステップＳ４０３）。サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものでない場合には（ステップＳ４０３，Ｎｏ）、当該サーバのサーバグループへの追加処理を終了する。
サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものである場合には（ステップＳ４０３，Ｙｅｓ）、ストレージＲＭ２５は、一台目のサーバにストレージを設定した場合と同様の方法で、サーバに対してストレージを設定する処理をおこなう（ステップＳ４０４）。具体的には、ストレージＲＭ２５は、図３１および図３６で説明した論理ボリュームの設定処理を当該サーバに対して実行する。
続いて、ネットワークＲＭ２４は、一台目のサーバにネットワークを設定した場合と同様の方法で、サーバグループに登録したサーバのネットワークブートを仮のＯＳを用いておこない、サーバのネットワークの設定をおこなう（ステップＳ４０５）。
その後、ソフトウェアサブＲＭ５３は、一台目のサーバに導入されたソフトウェアから作成されたソフトウェア配布イメージを二台目のサーバに対応付けられたストレージサブグループに展開し、展開されたソフトウェアを用いてサーバを再起動させる（ステップＳ４０６）。
ソフトウェア配布イメージをサーバに対応付けられたストレージサブグループに展開した場合には、ソフトウェアＲＭ２３は、システムリソースＤＢ２６に、配布したソフトウェア配布イメージに係る情報を記憶する。
図４６は、ソフトウェア配布イメージの配布状況に係る情報を記憶した配布管理データ１０８０の一例を示す図である。この配布管理データ１０８０は、サーバ名、ストレージサブグループ名、ソフトウェア配布イメージ名、版数および状態の情報を記憶している。
サーバ名は、ストレージサブグループが割り当てられているサーバを識別する情報である。ストレージサブグループ名は、ソフトウェア配布イメージが展開されるストレージサブグループを識別する情報である。ソフトウェア配布イメージ名は、ストレージサブグループに展開されたソフトウェア配布イメージを識別する情報である。版数は、配布されたソフトウェア配布イメージの版数の情報である。状態は、ソフトウェア配布イメージの配布状況を示す情報である。
図４５の説明に戻ると、システムリソースマネージャ２１は、ネットワークＲＭ２４およびＡＰ管理統括部２７と連携して、二台目のサーバを業務モードに移行させる処理をおこなう（ステップＳ４０７）。
具体的には、ネットワークＲＭ２４は、サーバの再起動時に、一台目のサーバが属するサブネットの情報に基づいて、二台目のサーバにＩＰアドレスを割り当てる。二台目のサーバに割り当てられたＩＰアドレスの情報は、システムリソースマネージャ２１により、図４１に示したＩＰアドレス管理データ１０４０に記憶される。
続いて、ネットワークＲＭ２４は、スイッチにＶＬＡＮの設定をおこなってサーバをＶＬＡＮに接続するとともに、ロードバランサに対して、負荷を分散させる対象サーバとして当該サーバを登録させる。
その後、システムリソースマネージャ２１は、ＡＰ管理統括部２７に対して、サーバのサーバグループの追加をＡＰ管理統括部２７に認識させるコマンドを送信する。そして、ＡＰ管理統括部２７は、ＡＰ管理部１１６ａと連携して、サーバに対してアプリケーションプログラムの導入および設定などをおこない、サーバを業務で利用可能な状態に設定する。
三台目以降のサーバをサーバグループに追加する場合には、図４５で説明したサーバの追加処理を繰り返す。
つぎに、図２で説明したリパーパシング処理の処理手順を図４７および図４８を用いて説明する。図４７は、リパーパシング処理に係る事前設定処理の処理手順を説明するフローチャートであり、図４８は、リパーパシング処理の処理手順を示すフローチャートである。
図４７に示すように、まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したリパーパシングの設定に係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するリパーパシング設定データ１０９０およびスケジュール設定データ１１１０として登録する（ステップＳ５０１）。
図４９は、リパーパシングの設定に係る情報を記憶したリパーパシング設定データ１０９０の一例を示す図である。このリパーパシング設定データ１０９０は、リパーパシング定義名、使用サーバ数、状態１、状態２および状態３の情報を記憶している。
リパーパシング定義名は、リパーパシングの各設定に対して付与されたリパーパシングの定義名の情報である。使用サーバ名は、リパーパシング処理に使用するサーバの台数の情報である。状態１、状態２および状態３は、リパーパシング処理において、用途が異なるサーバグループにサーバが属する状態が３つある場合に、それぞれの状態においてサーバがどのサーバグループに帰属するのかを識別する情報である。この状態１、状態２および状態３には、それぞれ状態において、サーバが帰属するサーバグループの識別情報が記憶される。
ここで、サーバが現在どのサーバグループに属しているかの状態に係る情報は、システムリソースマネージャ２１により、以下に説明するリパーパシング運用データ１１００としてシステムリソースＤＢ２６に登録されている。図５０は、サーバの状態に係る情報を記憶したリパーパシング運用データ１１００の一例を示す図である。
このリパーパシング運用データ１１００は、リパーパシング定義名および現在の状態の情報を記憶している。リパーパシング定義名は、図４９で説明したリパーパシング定義名と同様の情報である。現在の状態は、サーバが現在どのサーバグループに属しているかの状態を識別する情報である。この現在の状態には、図４９のリパーパシング設定データ１０９０の状態１、状態２または状態３のいずれかの状態に係る情報が記憶される。
図５１は、リパーパシング処理を実行するスケジュールに係る情報を記憶したスケジュール設定データ１１１０の一例を示す図である。このスケジュール設定データ１１１０は、リパーパシング定義名、日時および動作の情報を記憶している。
リパーパシング定義名は、図４９で説明したリパーパシング定義名と同様の情報である。日時は、リパーパシング処理を実行する日時の情報である。動作は、リパーパシング処理において、図４９で説明した状態を切り替える場合の切り替え元の状態および切り替え先の状態を識別する情報である。
なお、図４９に示したリパーパシング設定データ１０９０、図５０に示したリパーパシング運用データ１１００および図５１に示したスケジュール設定データ１１１０には、状態１、状態２または状態３の３つの状態に係る情報が記憶されるが、その数は３つに限定されるものではなく、任意の数の状態に係る情報を記憶することができる。以下では、簡略化のため、状態１および状態２の２つの状態を切り替えるリパーパシング処理をおこなう場合について説明することとする。
図４７の説明に戻ると、システムリソースマネージャ２１は、状態の切り替えをおこなうサーバグループが同一のサーバドメインに属するサーバグループに属すること、また、プールグループに管理対象となるサーバが図４９の使用サーバ数に設定された台数存在することをチェックする（ステップＳ５０２）。
具体的には、システムリソースマネージャ２１は、サーバグループのチェックを図２６に示したサーバグループデータ８１０を参照して実行する。また、システムリソースマネージャ２１は、プールグループのチェックを図２２に示したプロビジョニング構成データ７１０を参照して実行する。
そして、システムリソースマネージャ２１は、図４９に示した状態１に対応する切り替え用のサーバグループにサーバを登録する（ステップＳ５０３）。そして、システムリソースマネージャ２１は、ストレージＲＭ２５と連携して、サーバを登録したサーバグループに対するストレージサブグループを作成する（ステップＳ５０４）。
具体的には、システムリソースマネージャ２１は、ストレージＲＭ２５と連携することにより、ＲＡＩＤ装置に論理ボリュームを設定し、図２５に示したストレージテンプレートデータ８００および図２６に示したサーバグループデータ８１０を参照して、図３５に示したように、サーバグループに対応するストレージサブグループを作成する。さらに、システムリソースマネージャ２１は、作成したストレージサブグループに対するサーバからのアクセスを許可する。
続いて、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０を参照することにより、サーバを登録したサーバグループに配信すべきソフトウェア配布イメージを選択する。そして、ソフトウェアサブＲＭ５３は、サーバグループに対応するストレージサブグループにそのソフトウェア配布イメージを配信して展開する（ステップＳ５０５）。
その後、システムリソースマネージャ２１は、ネットワークサブＲＭ５４と連携して、ソフトウェア配布イメージを配信したストレージサブグループに対応するサーバからのストレージサブグループに対するアクセスを不許可に設定することにより、当該サーバをサーバグループから切り離す（ステップＳ５０６）。その際、システムリソースマネージャ２１は、ストレージサブグループの削除はおこなわず、保存しておく。
続いて、システムリソースマネージャ２１は、サーバグループから切り離されたサーバを、状態２に対応する切り替え用の別のサーバグループに登録する（ステップＳ５０７）。そして、システムリソースマネージャ２１は、ストレージＲＭ２５と連携して、サーバを登録したサーバグループに対するストレージサブグループを作成する（ステップＳ５０８）。
具体的には、システムリソースマネージャ２１は、ストレージＲＭ２５と連携することにより、ＲＡＩＤ装置に論理ボリュームを設定し、図２５に示したストレージテンプレートデータ８００および図２６に示したサーバグループデータ８１０を参照して、図３５に示したように、サーバグループに対応するストレージサブグループを作成する。さらに、システムリソースマネージャ２１は、作成したストレージサブグループに対するサーバからのアクセスを許可する。
その後、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０を参照することにより、サーバを登録したサーバグループに配信すべきソフトウェア配布イメージを選択する。そして、ソフトウェアサブＲＭ５３は、サーバグループに対応するストレージサブグループにそのソフトウェア配布イメージを配信して展開し（ステップＳ５０９）、この事前設定処理を終了する。
なお、状態数が３以上である場合には、ステップＳ５０９の後、サーバをサーバグループから切り離し、状態の数だけステップＳ５０７からステップＳ５０９の処理およびサーバをサーバグループから切り離す処理を繰り返し実行すればよい。
つぎに、図４８に示すように、リパーパシング処理においては、システムリソースマネージャ２１は、切り替え先のサーバグループの情報を、図４９に示したリパーパシング設定データ１０９０から取得する（ステップＳ６０１）。
そして、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０を参照して、サーバグループに対応するソフトウェア配布イメージの情報を取得し、さらに、図４６を参照して、そのソフトウェア配布イメージが配信済であることをチェックする（ステップＳ６０２）。
その後、システムリソースマネージャ２１は、ネットワークサブＲＭ５４と連携して、サーバからのストレージサブグループに対するアクセスを不許可に設定することにより、サーバが現在属するサーバグループから当該サーバを切り離し、プールグループに追加する（ステップＳ６０３）。その際、システムリソースマネージャ２１は、ストレージサブグループの削除はおこなわず、保存しておく。
続いて、システムリソースマネージャ２１は、プールグループに追加されたサーバを、切り替え先のサーバグループに登録し（ステップＳ６０４）、登録したサーバグループに対応するストレージサブグループに作成された論理ボリュームに対するサーバからのアクセスを許可する（ステップＳ６０５）。
そして、サーバＲＭ２２は、サーバサブＲＭ５２と連携して、アクセスが許可された論理ボリュームを起動ディスクとしてサーバを起動し（ステップＳ６０６）、このリパーパシング処理を終了する。
なお、上記リパーパシング処理では、図４９に示したように、各状態に対して１つのサーバグループを設定しているが、各状態に対して１つ以上のサーバグループを設定することとしてもよい。
図５２は、各状態に１つ以上のサーバグループを設定したリパーパシング設定データ１１２０の一例を示す図である。このリパーパシング設定データ１１２０は、リパーパシング定義名、使用サーバ名、状態１および状態２の情報を記憶している。
リパーパシング定義名は、図４９で説明したリパーパシング定義名と同様の情報である。使用サーバ数は、図４９で説明した使用サーバ数と同様の情報である。状態１および状態２は、リパーパシング処理において、用途の異なるサーバグループにサーバが属する状態が２つある場合に、それぞれの状態においてサーバがどのサーバグループに帰属するのか識別する情報である。この状態１および状態２には、それぞれ状態において、サーバが帰属するサーバグループの識別情報が記憶される。
ここで、図４９で説明したリパーパシング設定データ１０９０の状態１、状態２および状態３と異なる点は、１つのリパーパシング定義名に対して、各状態に１つ以上のサーバグループを設定して、サーバグループに属するサーバが利用するソフトウェアを別のソフトウェアに切り替え、サーバグループに属するサーバの用途を別の用途に変更する点である。
図５２の例では、状態１に対して、サーバグループ「A_DB」とサーバグループ「B_DB」とが登録され、状態２に対して、サーバグループ「A_Batch」が登録されている。そして、状態１から状態２へと状態が変更される場合には、サーバグループ「A_DB」とサーバグループ「B_DB」とに属するサーバの２つの用途から、サーバグループ「A_Batch」に属するサーバの１つの用途にサーバの用途が変更される。
また、状態２から状態１へと状態が変更される場合には、サーバグループ「A_Batch」に属するサーバの１つの用途から、サーバグループ「A_DB」とサーバグループ「B_DB」とに属するサーバの２つの用途にサーバの用途が変更される。また、状態１および状態２のそれぞれに複数のサーバグループが登録された場合には、各サーバグループに属するサーバの複数の用途から別の複数の用途にサーバの用途が変更される。
また、各サーバグループには、各サーバグループに割り当てるサーバ数を設定することとしてもよい。図５２の例では、状態１に対して、サーバグループ「A_DB」とサーバグループ「B_DB」とが登録され、使用サーバ数により指定される４台のサーバのうち、サーバグループ「A_DB」に対しては１台のサーバを、サーバグループ「B_DB」に対しては３台のサーバを割り当てるよう設定されている。状態２においては、サーバグループ「A_Batch」に対して、４台のサーバを割り当てるよう設定されている。
上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図５３から図５５を用いて、上記各種処理を実現するプログラムを実行するコンピュータの一例について説明する。
図５３は、図３に示したサイト管理サーバ２０となるコンピュータ１２００のハードウェア構成を示す図である。このコンピュータ１２００は、ユーザからのデータの入力を受け付ける入力装置１２１０、モニタ１２２０、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置１２３０、ＲＯＭ（Read Only Memory）１２４０、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース１２５０、ＨＤＤ（Hard Disk Drive）１２６０、ＲＡＭ（Random Access Memory）１２７０およびＣＰＵ（Central Processing Unit）１２８０をバス１２９０で接続して構成される。
そして、ＨＤＤ１２６０には、サイト管理サーバ２０の機能と同様の機能を発揮するプログラム、つまり、図５３に示すシステムリソース管理プログラム１２６０ｂおよびＡＰ管理統括プログラム１２６０ｃが記憶されている。
なお、システムリソース管理プログラム１２６０ｂおよびＡＰ管理統括プログラム１２６０ｃについては、適宜統合または分散して記憶することとしてもよい。
そして、ＣＰＵ１２８０が、システムリソース管理プログラム１２６０ｂおよびＡＰ管理統括プログラム１２６０ｃをＨＤＤ１２６０から読み出して実行することにより、システムリソース管理プロセス１２８０ａおよびＡＰ管理統括プロセス１２８０ｂとして機能するようになる。
このシステムリソース管理プロセス１２８０ａは、図３に示したシステムリソースマネージャ２１、サーバＲＭ２２、ソフトウェアＲＭ２３、ネットワークＲＭ２４、ストレージＲＭ２５に対応する。また、ＡＰ管理統括プロセス１２８０ｂは、図３に示したＡＰ管理統括部２７に対応する。
また、ＨＤＤ１２６０には、システムリソースデータ１２６０ａが記憶される。なお、このシステムリソースデータ１２６０ａは、図３に示したシステムリソースＤＢ２６に記憶される各種データに対応する。
そして、ＣＰＵ１２８０は、リソースの管理に係る各種データをシステムリソースデータ１２６０ａとして記憶するとともに、システムリソースデータ１２６０ａをＨＤＤ１２６０から読み出してＲＡＭ１２７０に格納し、ＲＡＭ１２７０に格納されたシステムリソースデータ１２７０ａに基づいて各種データ処理を実行する。
図５４は、図３に示したドメイン管理サーバ２０となるコンピュータ１３００のハードウェア構成を示す図である。このコンピュータ１３００は、ユーザからのデータの入力を受け付ける入力装置１３１０、モニタ１３２０、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置１３３０、ＲＯＭ１３４０、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース１３５０、ＨＤＤ１３６０、ＲＡＭ１３７０およびＣＰＵ１３８０をバス１３９０で接続して構成される。
そして、ＨＤＤ１３６０には、ドメイン管理サーバ５０，６０の機能と同様の機能を発揮するプログラム、つまり、図５４に示すドメインリソース管理プログラム１３６０ｂが記憶されている。なお、ドメインリソース管理プログラム１３６０ｂについては、適宜統合または分散して記憶することとしてもよい。
そして、ＣＰＵ１３８０が、ドメインリソース管理プログラム１３６０ｂをＨＤＤ１３６０から読み出して実行することにより、ドメインリソース管理プロセス１３８０ａとして機能するようになる。
このドメインリソース管理プロセス１３８０ａは、図３に示したシステムリソースドメインマネージャ５１、サーバサブＲＭ５２、ソフトウェアサブＲＭ５３、ネットワークサブＲＭ５４に対応する。
また、ＨＤＤ１３６０には、ドメインリソースデータ１３６０ａが記憶される。なお、このドメインリソースデータ１３６０ａは、図３に示したドメインリソースＤＢ５５に記憶される各種データに対応する。
そして、ＣＰＵ１３８０は、ドメインにおけるリソースの管理に係る各種データをドメインリソースデータ１３６０ａとして記憶するとともに、ドメインリソースデータ１３６０ａをＨＤＤ１３６０から読み出してＲＡＭ１３７０に格納し、ＲＡＭ１３７０に格納されたドメインリソースデータ１３７０ａに基づいて各種データ処理を実行する。
また、図５５は、図３に示したサーバ１１０ａとなるコンピュータ１４００のハードウェア構成を示す図である。このコンピュータ１４００は、ユーザからのデータの入力を受け付ける入力装置１４１０、モニタ１４２０、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置１４３０、ＲＡＭ１４４０、ＲＯＭ１４５０、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース１４６０、ＨＤＤ１４７０およびＣＰＵ１４８０をバス１４９０で接続して構成される。
そして、ＨＤＤ１４７０には、サーバ１１０ａの機能と同様の機能を発揮するプログラム、つまり、図５５に示すエージェントリソース管理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂが記憶されている。なお、エージェントリソース管理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂについては、適宜統合または分散して記憶することとしてもよい。
そして、ＣＰＵ１４８０が、エージェントリソース管理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂをＨＤＤ１４７０から読み出して実行することにより、エージェントリソース管理プロセス１４８０ａおよびＡＰ管理プロセス１４８０ｂとして機能するようになる。
このエージェントリソース管理プロセス１４８０ａは、図３に示したリソースマネージャエージェント１１１ａ、サーバＲＭエージェント１１２ａ、ソフトウェアＲＭエージェント１１３ａ、ネットワークＲＭエージェント１１４ａおよびストレージＲＭエージェント１１５ａに対応する。また、ＡＰ管理プロセス１４８０ｂは、図３に示したＡＰ管理部１１６ａに対応する。
ところで、システムリソース管理プログラム１２６０ｂ、ＡＰ管理統括プログラム１２６０ｃ、ドメインリソース管理プログラム１３６０ｂ、エージェントリソース管理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂについては、必ずしも最初からＨＤＤ１２６０、ＨＤＤ１３６０またはＨＤＤ１４７０に記憶させておく必要はない。
たとえば、コンピュータ１２００、１３００または１４００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、または、コンピュータの内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１２００、１３００または１４００に接続される「他のコンピュータ（またはサーバ）」などに各プログラムを記憶しておき、コンピュータ１２００、１３００または１４００がこれらから各プログラムを読み出して実行するようにしてもよい。
上述してきたように、本実施例では、システムリソースマネージャ２１が、均一のソフトウェアを利用するサーバの集まりとしてサーバグループを登録し、登録したサーバグループに属するサーバが利用するソフトウェアの切り替えを制御することとしたので、サーバの数が多い大規模な情報処理システムにおいても、サーバをサーバグループ単位で管理することにより、サーバの用途の変更を管理者が容易にかつ効率的に実行することができる。
また、本実施例では、システムリソースマネージャ２１が、物理結線が均一なサーバの集まりとしてサーバドメインを登録し、登録したサーバドメインにおいて均一のソフトウェアを利用するサーバの集まりとしてサーバグループを登録することとしたので、物理結線の均一性が保証された各サーバドメインにおいて、用途を切り替えるサーバが属するサーバグループを登録することにより、用途を変更して利用するサーバのサーバグループを管理者が容易に構築し、構築したサーバグループに属するサーバの用途の変更を容易にかつ効率的におこなうことができる。
また、本実施例では、システムリソースマネージャ２１が、サーバグループに属するサーバにＳＡＮを介して接続されたＲＡＩＤ装置に記憶されているソフトウェアに対するサーバからのアクセスを制御することによりサーバが利用するソフトウェアの切り替えを制御することとしたので、ソフトウェアの切り替えを容易に実行し、サーバ群の用途変更処理を効率的におこなうことができる。
また、本実施例では、システムリソースマネージャ２１が、スケジュール設定データ１１１０に基づいて、サーバグループに属するサーバが利用するソフトウェアの切り替えを制御することとしたので、サーバの用途の切り替えを計画的におこなうことができる。
また、本実施例では、システムリソースマネージャ２１が、リパーパシング設定データ１１２０に基づいて、複数のサーバグループに属する複数のサーバがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、１つのサーバグループに属する複数のサーバが利用するソフトウェアを別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のサーバの１つまたは複数の用途を別の用途に変更することとしたので、サーバの用途の変更を柔軟かつ効率的におこなうことができる。
また、本実施例では、システムリソースマネージャ２１が、リパーパシング設定データ１１２０に基づいて、複数のリソースグループに属する指定された数のリソースがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、１つのリソースグループに属するリソースが利用するソフトウェアを指定された数のリソースごとに別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のリソースの１つまたは複数の用途を別の用途に変更することとしたので、各用途に対して必要な数のサーバを分配することができる。
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、請求の範囲に記載した技術的思想の範囲内において種々の異なる実施例にて実施されてもよいものである。
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。
この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
以上のように、本発明にかかる運用管理プログラム、運用管理方法および運用管理装置は、情報処理システムを構成するリソースの運用を管理する運用管理システムに有用であり、特に、サーバなどのリソースの数が多い大規模な情報処理システムにおいても、リソースの用途の変更を管理者が容易にかつ効率的に実行することが必要な運用管理システムに適している。
本発明は、情報処理システムを構成するリソースの運用を管理する運用管理プログラム、運用管理方法および運用管理装置に関し、特に、サーバなどのリソースの数が多い大規模な情報処理システムにおいても、リソースの用途の変更を管理者が容易にかつ効率的に実行することができる運用管理プログラム、運用管理方法および運用管理装置に関するものである。
従来、サーバなどのリソースがネットワークを介して接続されることにより構成される情報処理システムにおいて、サーバを起動する際に、サーバに転送するソフトウェアを切り替えることによりサーバの用途を変更する技術が開発されている。
たとえば、特許文献１には、サーバの起動ごとに起動ディスクから転送される起動プログラムの内容を変更し、サーバをさまざまな環境で運用するシステムのマルチブート方法が開示されている。
特開２００３−２２１９０号公報
しかしながら、上述した特許文献１に代表される従来技術では、用途を変更して利用するサーバが複数ある場合に、それらの用途の切り替えを管理することが難しいという問題があった。
すなわち、それぞれのサーバに対してソフトウェアの切り替えを個々に実行する必要があり、情報処理システムの管理者に負担がかかるという問題があった。特に、情報処理システムの規模が大きくなって、サーバの数が多くなると、ソフトウェアの切り替え処理の実行がますます困難になってくる。
このようなことから、サーバの数が多い大規模な情報処理システムにおいて、サーバの用途の変更を管理者がいかに容易にかつ効率的に実行することができるかが重要な問題となっている。
本発明は、上記に鑑みてなされたものであって、サーバなどのリソースの数が多い大規模な情報処理システムにおいても、リソースの用途の変更を管理者が容易にかつ効率的に実行することができる運用管理プログラム、運用管理方法および運用管理装置を提供することを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、情報処理システムを構成するリソースの運用を管理する運用管理プログラムであって、均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録するグループ登録手順と、前記グループ登録手順により登録されたリソースグループに属するリソースが利用するソフトウェアの切り替えを制御することによりリソースの用途を変更する用途変更手順と、をコンピュータに実行させることを特徴とする。
また、本発明は、情報処理システムを構成するリソースの運用を管理する運用管理方法であって、均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録するグループ登録工程と、前記グループ登録工程により登録されたリソースグループに属するリソースが利用するソフトウェアの切り替えを制御することによりリソースの用途を変更する用途変更工程と、を含んだことを特徴とする。
また、本発明は、情報処理システムを構成するリソースの運用を管理する運用管理装置であって、均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録するグループ登録手段と、前記グループ登録手段により登録されたリソースグループに属するリソースが利用するソフトウェアの切り替えを制御することによりリソースの用途を変更する用途変更手段と、を備えたことを特徴とする。
本発明によれば、均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録し、登録したリソースグループに属するリソースが利用するソフトウェアの切り替えを制御することとしたので、リソースの数が多い大規模な情報処理システムにおいても、リソースをリソースグループ単位で管理することにより、リソースの用途の変更を管理者が容易にかつ効率的に実行することができるという効果を奏する。
以下に、本発明に係る運用管理プログラム、運用管理方法および運用管理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
まず、本実施例に係るサーバ運用管理の概念について説明する。図１は、サーバやストレージなどのリソースの運用管理の概念を示す図であり、図２は、本実施例に係るリパーパシング処理の概念を説明する図である。ここで、リパーパシング処理とは、サーバの用途を自動的に切り替える処理である。
図１には、各業務１，２においてＷｅｂサーバ４1〜４9やＡＰ（Application）サーバ５1〜５6、ＤＢ（Database）サーバ６1〜６3、ストレージ７1〜７9などの情報処理装置が利用される場合が示されている。
ここで、Ｗｅｂサーバ４1〜４9は、Ｗｅｂブラウザで閲覧されるコンテンツをインターネットを介してクライアント装置に提供するサーバ装置である。ＡＰサーバ５1〜５6は、ユーザによる情報処理要求を受け付けたＷｅｂサーバ４1〜４9から要求された情報処理の実行を引き継ぐサーバ装置である。
ＤＢサーバ６1〜６3は、ＡＰサーバ５1〜５6からデータベースへのアクセス要求を受け付けた場合に、データベースへのアクセスを管理するサーバ装置である。ストレージ７1〜７9は、ネットワークを介してＷｅｂサーバ４1〜４9やＡＰサーバ５1〜５6、データベースサーバ６1〜６3に接続され、ＳＡＮ（Storage Area Network）を構成する記憶装置である。
本発明に係るリソース運用管理処理では、ＬＡＮ（Local Area Network）やＳＡＮなどにおいて、他の装置との間の物理的な結線状態が互いに均一であるサーバやストレージなどのリソース群をドメインとして管理する。
たとえば、図１の場合には、業務１，２で利用されるサーバ群が、Ｗｅｂドメイン４、ＡＰドメイン５およびＤＢドメイン６として管理され、業務１，２で利用されるストレージ群が、ストレージドメイン７として管理されている。
この場合、Ｗｅｂドメイン４に属するＷｅｂサーバ４1〜４9の他の装置に対する結線状態は互いに均一であり、ＡＰドメイン５に属するＡＰサーバ５1〜５6の他の装置に対する結線状態は互いに均一であり、ＤＢドメイン６に属するＤＢサーバ６1〜６3の他の装置に対する結線状態は互いに均一であり、ストレージドメイン７に属するストレージ７1〜７9の他の装置に対する結線状態は互いに均一となっている。
そして、このリソース運用管理処理では、未使用のＷｅｂサーバ４1〜４9、ＡＰサーバ５1〜５6、ＤＢサーバ６1〜６3およびストレージ７1〜７9をドメインごとにプール３に登録しておき、必要に応じて各業務１，２にＷｅｂサーバ４1〜４9、ＡＰサーバ５1〜５6、ＤＢサーバ６1〜６3およびストレージ７1〜７9を割り当てる。
たとえば、図１では、業務１には、Ｗｅｂサーバ４2，４3、ＡＰサーバ５1、ＤＢサーバ６1、ストレージ７7が割り当てられ、業務２には、Ｗｅｂサーバ４9、ＡＰサーバ５2，５3、ＤＢサーバ６2、ストレージ７8，７9が割り当てられている。
そして、業務１，２に割り当てられたＷｅｂサーバ４2，４3，４9、ＡＰサーバ５1，５2，５3、ＤＢサーバ６1，６2の負荷が増大したり、ストレージ７7〜７9の記憶容量が不足したような場合に、プール３に登録されているＷｅｂサーバ４1，４4〜４8、ＡＰサーバ５4〜５6、ＤＢサーバ６3，ストレージ７1〜７6を業務で利用可能なサーバとして追加する。
具体的には、プール３に登録されているＷｅｂサーバ４1，４4〜４8、ＡＰサーバ５4〜５6，ＤＢサーバ６3に必要なソフトウェアを導入し、ネットワークの設定などを自動的におこなうことにより、Ｗｅｂサーバ４1，４4〜４8、ＡＰサーバ５4〜５6，ＤＢサーバ６3を業務で利用可能なサーバとして追加する。
また、ストレージ７1〜７6を追加する場合は、ストレージ７1〜７6に対して論理ボリュームの設定やネットワークの設定などを自動的におこなうことにより、当該ストレージ７1〜７6を業務で利用可能なストレージ７1〜７6として追加する。
たとえば、図１には、業務２のＷｅｂドメイン４において、プール３に登録されていたＷｅｂサーバ４4が新たに追加される場合が示されている。
さらに、このリソース運用管理処理では、業務１，２で利用されているＷｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3，ＤＢサーバ６1，６2またはストレージ７7〜７9が長期間使用されていないような場合に、Ｗｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3、ＤＢサーバ６1，６2、または、ストレージ７7〜７9を業務で利用可能なサーバから除外し、プール３に登録する処理がおこなわれる。
ここでプール３に登録されたＷｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3，ＤＢサーバ６1，６2，ストレージ７7〜７9は、別の業務１，２で利用されているＷｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3、ＤＢサーバ６1，６2の負荷が増大したり、ストレージ７7〜７9の記憶容量が不足したような場合に再利用される。
具体的には、Ｗｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3、ＤＢサーバ６1，６2に導入されているソフトウェアを削除し、ネットワークの設定の変更などを自動的におこなうことにより、Ｗｅｂサーバ４2，４3，４9、ＡＰサーバ５1〜５3，ＤＢサーバ６1，６2が業務１，２で利用可能なサーバから除外され、プール３に登録される。
また、ストレージ７7〜７9を業務１，２で利用可能なストレージから除外してプール３に登録する場合には、ストレージ７7〜７9に対するネットワークの設定などを自動的におこなうことにより、当該ストレージ７7〜７9を業務で利用可能なストレージから除外し、プール３に登録する。
たとえば、図１には、業務２のＡＰドメイン５において、プール３に登録されていたＡＰサーバ５2が業務で利用可能なサーバから除外され、プール３に登録される場合が示されている。また、プール３に登録されたサーバ５4は、業務１で利用されているサーバ５1の負荷が増大したような場合に再利用され、業務１に新たに追加される。
そして、図２に示すように、リパーパシング処理においては、サーバの用途が時間帯によって自動的に切り替えられる。図２には、プールグループ８ｃに属するサーバ８ｃ1，８ｃ2が、平日昼間にはＤＢドメインに属するＤＢサーバグループ８ａに追加される。ここで、ＤＢサーバグループ８ａとは、ＤＢドメインにおいて、データをデータベースに記憶する処理をおこなうサーバのグループである。
ＤＢサーバグループ８ａに追加されたサーバ８ａ1，８ａ2は、ＤＢサーバ用のソフトウェアが記憶されたＤＢサーバブートディスク９ａ1，９ａ2からネットワークブートにより起動され、業務に提供される。
そして、ＤＢサーバグループ８ａに追加されたサーバ８ａ1，８ａ2は、夜間や休日になると、プールグループ８ｃに返却され、さらにバッチサーバグループ８ｂに追加される。ここで、バッチサーバグループ８ｂとは、ＤＢドメインにおいて、バッチ処理をおこなうサーバのグループである。
その際、バッチサーバグループ８ｂに追加されたサーバ８ｂ1，８ｂ2は、バッチサーバ用のソフトウェアが記憶されたバッチサーバブートディスク９ｂ1，９ｂ2からネットワークブートにより起動され、業務に提供される。
このように、リパーパシング処理においては、均一のソフトウェアを利用するサーバの集まりとしてサーバグループを登録し、登録したサーバグループに属するサーバが利用するソフトウェアの切り替えを制御することとしたので、サーバの数が多い大規模な情報処理システムにおいても、サーバをサーバグループ単位で管理することにより、サーバの用途の変更を管理者が容易にかつ効率的に実行することができる。
つぎに、本実施例に係るリソース運用管理システムの機能構成について説明する。図３は、本実施例に係るリソース運用管理システムの機能構成を示す図である。
図３に示すように、このリソース運用管理システムでは、運用管理クライアント１０と、サイト管理サーバ２０とが、ＦＷ（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）アーキテクチャの識別情報である。管理サブネット名は、図６に示した管理サブネット名と同様の情報である。
ステップＳ１０２においては、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作しておこなったサーバドメインおよびサーバアーキテクチャの設定に係る情報を受け付け、サーバドメインデータ３４０に登録する。このサーバドメインは、ステップＳ１０１において設定された管理サブネット単位で設定される。
また、ステップＳ１０２においては、システムリソースマネージャ２１は、各サーバドメインに属するサーバグループを設定し、サーバグループ間で共有されるプールグループおよび特定のサーバグループに専用のプールグループを設定する。
ここで、サーバグループとは、同一のサーバドメインに含まれるサーバを１つまたは複数のグループに分けたものである。また、プールグループとは、各サーバグループに割り当てられたサーバのプールである。
図１０は、プールグループに係る情報を記憶したプールグループデータ３５０の一例を示す図である。このプールグループデータ３５０には、プールグループ名、種別、サーバドメイン名の情報が記憶されている。
プールグループ名は、上述したサーバのプールの識別情報である。種別は、プールグループが複数のサーバグループに共用させるものか、特定のサーバグループにのみ利用を許可するものかを示す情報である。サーバドメイン名は、図９で説明したサーバドメイン名と同様の情報である。
ここで、システムリソースマネージャ２１は、各サーバドメインに対してプールグループを割り当てる。また、サーバドメインが、複数のサーバグループを有する場合に、システムリソースマネージャ２１は、それらのサーバグループ専用のプールグループを割り当てる。
その後、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したストレージドメインの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するストレージドメインデータ３６０として登録する。
図１１は、ストレージドメインに係る情報を記憶したストレージドメインデータ３６０の一例を示す図である。このストレージドメインデータ３６０は、ストレージドメイン名およびパスの多重度の情報を記憶している。ストレージドメイン名は、設定されたストレージドメインを識別する識別情報である。パスの多重度は、ＳＡＮにおけるデータ通信パスの多重度の情報である。
さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークサブドメインの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するネットワークサブドメインデータ４７０として登録する。
ここで、ネットワークサブドメインとは、異なるサーバドメインに属するサーバを接続する複数のネットワーク機器が属するネットワークドメインをさらに分割したサブドメインである。
図１２は、ネットワークドメインおよびネットワークサブドメインを説明する説明図である。図１２には、Ｗｅｂドメイン３７０に属するサーバ３８０ａ〜３８０ｅと、ＡＰドメイン３９０に属するサーバ４００ａ〜４００ｅとを接続するスイッチ４３０ａ，４３０ｂ，４５０ａ，４５０ｂ、および、ＳＬＢ４６０ａ，４６０ｂが示されている。
ここで、スイッチ４３０ａおよびスイッチ４３０ｂは、「Web-Back」ネットワークサブドメイン４２０を構成し、スイッチ４５０ａおよびスイッチ４５０ｂは、「AP-Front」ネットワークサブドメイン４４０を構成している。
また、「Web-Back」ネットワークサブドメイン４２０、「AP-Front」ネットワークサブドメイン４４０、ＳＬＢ４６０ａ、および、ＳＬＢ４６０ｂが「Web-AP」ネットワークドメイン４１０を構成している。
図１３は、ネットワークサブドメインに係る情報を記憶したネットワークサブドメインデータ４７０の一例を示す図である。このネットワークサブドメインデータ４７０は、ネットワークサブドメイン名、スイッチ機種およびスイッチ管理ＩＰの情報を記憶している。
ネットワークサブドメイン名は、図１２で説明したネットワークサブドメインを識別する情報である。スイッチ機種は、ネットワークサブドメインに属するスイッチの機種の情報である。スイッチ管理ＩＰは、管理用に各スイッチに割り当てられたＩＰアドレスの情報である。
また、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークドメインに係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するネットワークドメインデータ４８０として登録する。
図１４は、ネットワークドメインに係る情報を記憶したネットワークドメインデータ４８０の一例を示す図である。このネットワークドメインデータ４８０は、ネットワークドメイン名、フロントネットワークサブドメイン名、接続方式、機器名、バックネットワークサブドメイン名および冗長化方式の情報を記憶している。
ネットワークドメイン名は、図１２で説明したネットワークドメインを識別する識別情報である。フロントネットワークサブドメイン名は、図１２に示したように、ネットワークドメインがＳＬＢ４６０ａ，４６０ｂを境として２つのネットワークサブドメインに分割された場合に、インターネット７０に近い方のネットワークサブドメインを識別する識別情報である。
接続方式は、フロントネットワークサブドメインに属するスイッチ４３０ａ，４３０ｂなどのネットワーク機器と、後に説明するバックネットワークサブドメインに属するスイッチ４５０ａ，４５０ｂなどのネットワーク機器との間を接続する方式に係る情報である。たとえば、この方式には、ロードバランサにより接続する方式や、ファイアウォールにより接続する方式などがある。機器名は、ネットワーク機器を識別する識別情報である。
バックネットワークサブドメイン名は、図１２に示したように、ネットワークドメインがＳＬＢ４６０ａ，４６０ｂを境として２つのネットワークサブドメインに分割された場合に、インターネット７０に遠い方のネットワークサブドメインを識別する識別情報である。冗長化方式は、ネットワークドメインにおいてデータ通信経路が冗長化されている場合の冗長化の方式を示す情報である。
さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークサブドメインの接続機器に係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明する負荷分散装置データ４９０として登録する。ここで、ネットワークサブドメインの接続機器とは、図１２で説明したＳＬＢ４６０ａ，４６０ｂなどの機器のことである。
図１５は、負荷分散装置に係る情報を記憶した負荷分散装置データ４９０の一例を示す図である。この負荷分散装置データ４９０は、負荷分散装置名、管理ＩＰ、機種名、ＳＮＭＰコミュニティ名およびＩＤ／パスワードの情報を記憶している。
負荷分散装置名は、ネットワークサブドメインの接続機器を識別する名称である。管理ＩＰは、接続機器の管理用に各接続機器に割り当てられたＩＰアドレスの情報である。機種名は、接続機器の機種の識別情報である。
ＳＮＭＰ（Simple Network Management Protocol）コミュニティ名は、接続機器を管理するドメイン管理サーバ５０，６０およびサイト管理サーバ２０と接続機器とが属するＳＮＭＰコミュニティを特定する情報である。ＩＤ／パスワードは、接続機器にアクセスするために必要なＩＤおよびパスワードの情報である。
また、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したネットワークサブグループの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するネットワークサブグループデータ６６０として登録する。
ここで、ネットワークサブグループとは、サーバドメインに属するサーバにサーバグループが設定されている場合に、異なるサーバドメインに属するサーバグループ間を接続するネットワークを複数のネットワークに分割したものである。
図１６は、ネットワークサブグループの構成例を説明する説明図である。図１６には、Ｗｅｂドメイン５１０に属するサーバ５２０ａ〜５２０ｅと、ＡＰドメイン５５０に属するサーバ５６０ａ〜５６０ｅとを接続するスイッチ５９０，６１０、および、ＳＬＢ６００ａ，６００ｂが示されている。
ここで、サーバ５２０ａとサーバ５２０ｂとは、「A_Web」サーバグループ５３０を構成し、サーバ５２０ｃとサーバ５２０ｄとは、「B_Web」サーバグループ５４０を構成し、サーバ５６０ａとサーバ５６０ｂとは、「A_AP」サーバグループ５７０を構成し、サーバ５６０ｃとサーバ５６０ｄとは、「B_AP」サーバグループ５８０を構成している。
そして、「A_Web」サーバグループ５３０とＳＬＢ６００ａとを接続するネットワークが「A_Web_Back」ネットワークサブグループ６２０を構成し、「B_Web」サーバグループ５４０とＳＬＢ６００ｂとを接続するネットワークが「B_Web_Back」ネットワークサブグループ６３０を構成し、ＳＬＢ６００ａと「A_AP」サーバグループ５７０とを接続するネットワークが「A_AP_Front」ネットワークサブグループ６４０を構成し、ＳＬＢ６００ｂと「B_AP」サーバグループ５８０とを接続するネットワークが「B_AP_Front」ネットワークサブグループ６５０を構成している。
また、図１７は、ネットワークサブグループに係る情報を記憶したネットワークサブグループデータ６６０の一例を示す図である。このネットワークサブグループデータ６６０は、ネットワークサブグループ名、ネットワークサブドメイン名、サブネットおよび冗長化用サブネットの情報を記憶している。
ネットワークサブグループ名は、図１６で例を挙げて説明したようなネットワークサブグループを識別する識別情報である。ネットワークサブドメイン名は、ネットワークサブグループが属するネットワークサブドメインを識別する識別情報である。
サブネットは、ネットワークサブグループに割り当てられるネットワークアドレスおよびサブネットマスクの情報である。冗長化用サブネットは、ネットワークサブグループに属するネットワークが複数のデータ通信回線を用いて冗長化される場合に、余分に追加されたデータ通信回線からなるネットワークに割り当てられるネットワークアドレスおよびサブネットマスクの情報である。
その後、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサーバドメイン間の対応関係に係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバドメイン間リンクデータ６７０として登録する。
図１８は、サーバドメイン間の対応関係に係る情報を記憶したサーバドメイン間リンクデータ６７０の一例を示す図である。このサーバドメイン間リンクデータ６７０は、フロントサーバドメイン名、ネットワークドメイン名およびバックサーバドメイン名の情報を記憶している。
フロントサーバドメイン名は、図１２に示したようなネットワークドメインを挟むサーバドメインのうち、よりインターネット７０側にあるサーバドメインを識別する識別情報である。ネットワークドメイン名は、図１２で説明したネットワークドメインの識別情報である。バックサーバドメイン名は、図１２に示したようなネットワークドメインを挟むサーバドメインのうち、よりインターネット７０から遠い側にあるサーバドメインを示す情報である。
さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサーバドメインとストレージドメインとの間の対応関係に係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバ／ストレージドメイン間リンクデータ６８０として登録する。
図１９は、サーバドメインとストレージドメインとの間の対応関係に係る情報を記憶したサーバ／ストレージドメイン間リンクデータ６８０の一例を示す図である。このサーバ／ストレージドメイン間リンクデータ６８０は、サーバドメイン名およびストレージドメイン名の情報を記憶している。ここで、サーバドメイン名は、図９に示したサーバドメイン名と同様の情報である。ストレージドメイン名は、図１１に示したストレージドメイン名と同様の情報である。
図４の説明に戻ると、システムリソースマネージャ２１は、管理対象となるサーバリソースおよびストレージリソースの登録をおこなう（ステップＳ１０３）。以下に、ステップＳ１０３でおこなわれる処理をさらに詳細に説明する。
まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、サーバを登録する管理サブネットの選択をおこなった際、ユーザにより選択された管理サブネットの情報を受け付ける。
さらに、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して入力した管理対象とするサーバの情報を運用管理クライアント１０から受け付け、その情報をドメイン管理サーバ５０のドメインリソースＤＢ５５に、以下に説明するネットワークブートサーバデータ６９０として記憶する。ここで登録されたサーバは、後にネットワークブートがおこなわれ、サーバの各種情報が取得された後、サーバリソースとして登録される。
図２０は、ネットワークブートがなされるサーバの情報を記憶したネットワークブートサーバデータ６９０の一例を示す図である。このネットワークブートサーバデータ６９０は、ＭＡＣアドレス、ＩＰアドレスおよびホスト名の情報を記憶している。
ＭＡＣアドレスは、サーバのＭＡＣアドレスの情報である。ＩＰアドレスは、サーバに割り当てられたＩＰアドレスの情報である。ホスト名は、サーバに割り当てられたホスト名の情報である。
ここで、システムリソースマネージャ２１は、ネットワークブートをおこなうサーバのユーザにより入力されたＭＡＣアドレスの情報を受け付けた場合に、そのＭＡＣアドレスに対応するサーバに、ＩＰアドレスとホスト名とを自動的に割り当てる。
そして、システムリソースマネージャ２１は、ドメイン管理サーバ５０のシステムリソースドメインマネージャ５１と連携し、ドメイン管理サーバ５０のドメインリソースＤＢ５５に記憶された仮のＯＳを用いて、ＩＰアドレスとホスト名とが割り当てられたサーバのネットワークブートをおこなう。
そして、サーバサブＲＭ５２、リソースマネージャエージェント１１１ａ、および、サーバＲＭエージェント１１２ａが連携することにより、サーバのハードウェアに係る情報を収集し、収集した情報をシステムリソースドメインマネージャ５１に送信する。
その後、システムリソースマネージャ２１は、システムリソースドメインマネージャ５１からサーバのハードウェアに係る情報を取得して、システムリソースＤＢ２６にその情報を、以下に説明する管理対象サーバデータ７００として記憶する。
また、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、ＳＡＮ１７０を介して接続されるストレージ１６０ａ〜１６０ｄからサーバを起動するＳＡＮブートをおこなうか否かの設定情報を入力した場合に、その設定情報を受け付け、その設定情報を管理対象サーバデータ７００に登録する。
図２１は、管理対象となるサーバのデータを記憶した管理対象サーバデータ７００の一例を示す図である。この管理対象サーバデータ７００は、サーバ名、ＩＰアドレス、ＭＡＣアドレス、サーバアーキテクチャ名、モデル名、ＳＡＮブートおよび状態の情報を記憶している。
サーバ名は、管理対象となるサーバを識別する名称である。ＩＰアドレスは、サーバに割り当てられたＩＰアドレスである。ＭＡＣアドレスは、サーバのＭＡＣアドレスである。サーバアーキテクチャ名は、サーバのＣＰＵアーキテクチャの識別情報である。モデル名は、サーバの型式を示す情報である。ＳＡＮブートは、ＳＡＮ１７０を介して接続されるストレージ１６０ａ〜１６０ｄからサーバを起動するＳＡＮブートをおこなうか否かの設定情報である。状態は、サーバに異常が発生しているか否かを示す情報である。
なお、ここでは、ユーザがＭＡＣアドレスを指定してネットワークブートをおこなうサーバを選択することとしているが、サーバの選択を自動的におこなうようにしてもよい。具体的には、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、自動的に選択をおこなうサーバの台数に係る情報を設定した場合に、その設定情報を運用管理クライアント１０から受け付ける。
そして、システムリソースマネージャ２１は、設定された台数分のサーバを選択し、選択したサーバのＩＰアドレスおよびホスト名の情報を、図２０に示したネットワークブートサーバデータ６９０に登録する。
そして、システムリソースマネージャ２１は、ドメイン管理サーバ５０のシステムリソースドメインマネージャ５１と連携し、ドメイン管理サーバ５０のドメインリソースＤＢ５５に記憶された仮のＯＳを用いて、ＩＰアドレスとホスト名とが割り当てられたサーバのネットワークブートをおこなう。
そして、サーバサブＲＭ５２、リソースマネージャエージェント１１１ａ、および、サーバＲＭエージェント１１２ａが連携することにより、各サーバのＭＡＣアドレス、サーバアーキテクチャ、モデル、状態の情報を収集し、収集した情報をシステムリソースドメインマネージャ５１に送信する。
その後、システムリソースマネージャ２１は、システムリソースドメインマネージャ５１から各サーバのＭＡＣアドレス、サーバアーキテクチャ、モデル、状態の情報を取得して、その情報をシステムリソースＤＢ２６に管理対象サーバデータ７００として記憶する。
続いて、システムリソースマネージャ２１は、管理対象となるストレージ機器の登録をおこなう。ここで、ストレージ機器とは、ＦＣ（Fiber Channel）スイッチやＲＡＩＤ装置などの機器である。
具体的には、システムリソースマネージャ２１は、管理対象として登録するストレージのＩＰアドレスの情報が、図７に示した管理サブネットごとにユーザにより入力された場合に、その情報を運用管理クライアント１０から受け付ける。そして、システムリソースマネージャ２１は、ＩＰアドレスに対応するストレージ機器の情報をシステムリソースＤＢ２６に記憶することによりストレージ機器を登録する。
その後、システムリソースマネージャ２１は、図２１の管理対象サーバデータ７００に登録されたサーバをサーバドメインに追加する処理をおこなう。具体的には、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作してサーバとそのサーバを追加するサーバドメインを指定した場合に、そのサーバおよびサーバドメインの情報を運用管理クライアント１０から受け付ける。
そして、システムリソースマネージャ２１は、図２１に示した管理対象サーバデータ７００を参照し、サーバのサーバアーキテクチャが、図９に示したサーバドメインデータ３４０に登録されているサーバアーキテクチャと一致することをチェックする。
また、システムリソースマネージャ２１は、図２１に示した管理対象サーバデータ７００を読み込み、サーバがＳＡＮブートをおこなうように設定されていることをチェックする。
さらに、システムリソースマネージャ２１は、サーバドメインに追加するサーバのネットワークの結線状態をチェックする。具体的には、システムリソースマネージャ２１は、図１８に示したサーバドメイン間リンクデータ６７０を読み込み、サーバドメインに対するフロントサーバドメインおよびバックサーバドメインの情報を取得する。
そして、システムリソースマネージャ２１は、図１４に示したネットワークドメインデータ４８０を読み込み、ネットワークドメインに対応するフロントサブドメインおよびバックサブドメインの情報を取得する。
その後、システムリソースマネージャ２１は、図１３に示したネットワークサブドメインデータ４７０を読み込み、フロントサブドメインおよびバックサブドメインに対応するスイッチを特定する。
そして、システムリソースマネージャ２１は、ネットワークＲＭ２４およびネットワークサブＲＭ５４に対して、サーバとスイッチ間の結線をチェックするよう要求する。さらに、ネットワークＲＭ２４およびネットワークサブＲＭ５４は、ネットワークＲＭエージェント１１４ａにサーバとスイッチとの間の結線をチェックするよう要求し、チェック結果を取得する。
そして、システムリソースマネージャ２１は、サーバとスイッチとの間の結線に問題がない場合、そのサーバに係る情報を図１０で説明したプールグループに対応付けて、以下に説明するプロビジョニング構成データ７１０としてシステムリソースＤＢ２６に記憶する。
図２２は、サーバが属するグループの情報を記憶したプロビジョニング構成データ７１０の一例を示す図である。このプロビジョニング構成データ７１０は、サーバ名、プールグループ名、サーバグループ名、ストレージサブグループ名、アクセス可否の情報を記憶する。
サーバ名は、図２１で説明したサーバ名と同様の情報である。プールグループ名は、図１０で説明したプールグループ名と同様の情報である。サーバグループ名は、同一のサーバドメインに含まれるサーバを１つまたは複数のグループに分けた場合のグループの識別情報である。この段階では、サーバグループ名の情報はまだ登録されない。
ストレージサブグループ名は、ストレージドメインに属するストレージを１つまたは複数のグループに分け、サーバグループに属する各サーバに割り当てた場合に、各サーバに割り当てたグループの識別情報である。この段階では、ストレージサブグループ名の情報はまだ登録されない。アクセス可否は、サーバによるストレージへのアクセスを許可するか否かを示す情報である。この段階では、アクセス可否の情報はまだ登録されない。
プロビジョニング構成データ７１０にサーバ名およびプールグループを登録した後、システムリソースマネージャ２１は、先に登録したストレージ機器をストレージドメインに登録する。
具体的には、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、ストレージドメインとストレージドメインに登録するストレージ機器とを指定した場合に、それらの情報を運用管理クライアント１０から受け付ける。
そして、システムリソースマネージャ２１は、図１９に示したサーバ／ストレージドメイン間リンクデータ６８０を読み込んで、ストレージドメインに対応するサーバドメインを特定する。
さらに、システムリソースマネージャ２１は、ストレージＲＭ２５およびストレージＲＭエージェント１１５ａと連携して、特定されたサーバドメインに属するサーバと、ストレージドメインに属するストレージ機器との間の結線の均一性をチェックする。
図２３は、結線状態が均一であるサーバとストレージ機器との結線の一例を示す図である。図２３に示すように、この例では、ストレージドメイン７４０に属するＦＣスイッチ７５０ａ、および、サーバドメイン７２０に属するサーバ７３０ａ，７３０ｂ間の結線状態と、ストレージドメイン７４０に属するＦＣスイッチ７５０ｂ、および、サーバ７３０ａ，７３０ｂ間の結線状態とが均一になっている。
また、ＦＣスイッチ７５０ａ，７５０ｂ、および、ストレージドメイン７４０に属するＲＡＩＤ装置７６０ａ間の結線状態と、ＦＣスイッチ７５０ａ，７５０ｂ、および、ストレージドメイン７４０に属するＲＡＩＤ装置７６０ｂ間の結線状態が均一になっている。
システムリソースマネージャ２１は、上記結線の均一性のチェックをＷＷＰＮ（World Wide Port Name）の情報を基にしておこなう。その際、システムリソースマネージャ２１は、図１１に示したストレージドメインデータ３６０からストレージドメインのパスの多重度の情報を読み込み、冗長度のチェックも併せておこなう。図２４は、ＷＷＰＮに基づく結線の均一性チェック処理を説明する図である。
図２４には、図２３に示したＲＡＩＤ装置７６０ａ，７６０ｂが記憶しているＲＡＩＤ装置ＷＷＰＮデータ７７０ａ，７７０ｂと、ＦＣスイッチ７５０ａ，７５０ｂが記憶しているＦＣスイッチＷＷＰＮデータ７８０ａ，７８０ｂと、サーバ７３０ａ，７３０ｂが記憶しているサーバＷＷＰＮデータ７９０ａ，７９０ｂとが示されている。
ＲＡＩＤ装置ＷＷＰＮデータ７７０ａ，７７０ｂは、ＣＡ（Channel Adapter）およびＷＷＰＮの情報を記憶している。ＣＡは、ＲＡＩＤ装置７６０ａ，７６０ｂが有するチャネルアダプタの識別情報である。ＷＷＰＮは、ＲＡＩＤ装置７６０ａ，７６０ｂが有するチャネルアダプタに割り当てられているＷＷＰＮの情報である。
ＦＣスイッチＷＷＰＮデータ７８０ａ，７８０ｂは、ｐｏｒｔおよび相手先ＷＷＰＮの情報を記憶している。ｐｏｒｔは、ＦＣスイッチ７５０ａ，７５０ｂのポートの識別情報である。相手先ＷＷＰＮは、ＦＣスイッチ７５０ａ，７５０ｂのポートに接続されているＲＡＩＤ装置７６０ａ，７６０ｂのチャネルアダプタに割り当てられているＷＷＰＮの情報、または、ＦＣスイッチ７５０ａ，７５０ｂのポートに接続されているサーバ７３０ａ，７３０ｂのＨＢＡ（Host Bus Adapter）に割り当てられたＷＷＰＮの情報である。
サーバＷＷＰＮデータ７９０ａ，７９０ｂは、ＨＢＡおよびＷＷＰＮの情報を記憶している。ＨＢＡは、サーバ７３０ａ，７３０ｂが有するＨＢＡの識別情報である。ＷＷＰＮは、サーバ７３０ａ，７３０ｂが有するＨＢＡに割り当てられているＷＷＰＮの情報である。
システムリソースマネージャ２１は、ＲＡＩＤ装置ＷＷＰＮデータ７７０ａ，７７０ｂ、ＦＣスイッチＷＷＰＮデータ７８０ａ，７８０ｂ、および、サーバＷＷＰＮデータ７９０ａ，７９０ｂをＲＡＩＤ装置７６０ａ，７６０ｂ、ＦＣスイッチ７５０ａ，７５０ｂ、および、サーバ７３０ａ，７３０ｂから収集し、ＷＷＰＮの対応関係を調べることにより、各装置間の結線状態の均一性をチェックすることができる。
その後、システムリソースマネージャ２１は、あらかじめ設定されているＬＵＮ（Logical Unit）の記憶領域と、ＬＵＮが未設定の記憶領域とをプール用のストレージとして登録する。
続いて、システムリソースマネージャ２１は、サーバグループの作成処理をおこなう（ステップＳ１０４）。以下に、ステップＳ１０４でおこなわれる処理をさらに詳細に説明する。
まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したストレージテンプレートに係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するストレージテンプレートデータ８００として登録する。ここで、ストレージテンプレートとは、後に作成されるサーバグループ用のストレージの構成に係る設定情報である。
図２５は、ストレージテンプレートに係るデータを記憶したストレージテンプレートデータ８００の一例を示す図である。このストレージテンプレートデータ８００は、ストレージテンプレート名、ディスク種別、ディスク名、信頼性の必要度、負荷の度合い、ディスク容量およびブートディスクの情報を記憶している。
ストレージテンプレート名は、設定されたストレージテンプレートを識別する識別情報である。ディスク種別は、ストレージテンプレートに属するディスクの用途の種別を示す情報である。
たとえば、「root」は、そのディスクがシステムデータを記憶するために利用されることを示し、「local」は、そのディスクがサーバ個別のデータを記憶するために利用されることを示し、「shared」は、そのディスクがサーバ間で共有されるデータを記憶するために利用されることを示す。
ディスク名は、各ディスクに割り当てられたディスクを識別する名称である。信頼性の必要度は、ディスクに必要とされる信頼性の情報である。負荷の度合いは、ディスクにかかる負荷の度合いの情報である。ディスク容量は、ディスクの記憶容量である。ブートディスクは、そのディスクがシステムのブート用に利用されるものか否かを示す情報である。
続いて、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサーバグループの情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバグループデータ８１０として記憶する。
図２６は、サーバグループに係る情報を記憶したサーバグループデータ８１０の一例を示す図である。このサーバグループデータ８１０は、サーバグループ名、サーバドメイン名、ソフトウェア配布イメージ名、版数、ストレージテンプレート名、ＳＡＮブートおよび自動リカバリの情報を記憶している。
サーバグループ名は、同一のサーバドメインに含まれるサーバを１つまたは複数のグループに分けた場合のグループの識別情報である。サーバドメイン名は、サーバグループが属するサーバドメインの識別情報である。ソフトウェア配布イメージ名は、サーバグループに属するサーバに配布するソフトウェアのイメージファイルを識別する情報である。
版数は、ソフトウェア配布イメージの版数の情報である。ストレージテンプレート名は、図２５で説明したストレージテンプレート名と同様の情報である。ＳＡＮブートは、サーバグループに属するサーバのＳＡＮブートをおこなうか否かを示す情報である。自動リカバリは、複数のサーバが連携して動作するスケールアウト構成のサーバが故障した場合に、自動的にサーバを追加する処理を実行するか否かを示す情報である。
その後、システムリソースマネージャ２１は、システムリソースＤＢ２６に、サーバグループに対応するストレージグループの情報を、以下に説明するサーバ／ストレージグループリンクデータ８２０として登録する。ここで、ストレージグループとは、同一のストレージドメインに含まれるストレージを１つまたは複数のグループに分けたものである。
図２７は、サーバグループに対応するストレージグループの情報を記憶したサーバ／ストレージグループリンクデータ８２０の一例を示す図である。このサーバ／ストレージグループリンクデータ８２０は、サーバグループ名、ストレージグループ名およびストレージドメイン名の情報を記憶している。
サーバグループ名は、図２６に示したサーバグループ名と同様の情報である。ストレージグループ名は、各サーバグループに対応して生成されたストレージグループの識別情報である。ストレージドメイン名は、ストレージグループが属するストレージドメインの識別情報である。
ストレージグループを生成する際には、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０から、サーバグループに対応付けられたストレージテンプレートの情報を読み込み、図２５に示したストレージテンプレートデータ８００からストレージテンプレートに対応するディスク種別の情報を読み込む。
そして、システムリソースマネージャ２１は、「root」や「local」、「shared」などのディスク種別ごとに、ストレージグループを各サーバグループに対して生成し、その情報をサーバ／ストレージグループリンクデータ８２０に登録する。
さらに、システムリソースマネージャ２１は、図１９に示したサーバ／ストレージドメイン間リンクデータから、サーバグループが属するサーバドメインに対応するストレージドメインの情報を読み込み、その情報をサーバ／ストレージグループリンクデータ８２０に登録する。
その後、システムリソースマネージャ２１は、サーバグループを追加したことをＡＰ管理部１１６ａに認識させるコマンドをＡＰ管理部１１６ａに送信する。具体的には、システムリソースマネージャ２１は、図８に示した「issvgrp add」をＡＰ管理部１１６ａに送信する。
続いて、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したサーバグループ間の対応関係の情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するサーバグループ間リンクデータ８３０として登録する。
図２８は、サーバグループ間の対応関係に係る情報を記憶したサーバグループ間リンクデータ８３０の一例を示す図である。このサーバグループ間リンクデータ８３０は、フロントサーバグループ名、ネットワークグループ名およびバックサーバグループ名の情報を記憶している。
フロントサーバグループ名は、ネットワークグループにより連結されるサーバグループのうち、よりインターネット７０側にあるサーバグループを識別する識別情報である。ここで、ネットワークグループとは、サーバグループ間を連結するよう図１６で説明したネットワークサブグループを結合したネットワークのグループである。
ネットワークグループ名は、上記ネットワークグループを識別する識別情報である。バックサーバグループ名は、ネットワークグループにより連結されるサーバグループのうち、インターネット７０から遠い側にあるサーバグループを識別する識別情報である。
その後、システムリソースマネージャ２１は、システムリソースＤＢ２６に、ネットワークグループに係る情報を、以下に説明するネットワークグループデータ８５０として記憶する。
具体的には、システムリソースマネージャ２１は、まず、図１８に示したサーバドメイン間リンクデータ６７０を読み込み、２つのサーバドメインに挟まれて設定されているネットワークドメインの情報を取得する。
そして、システムリソースマネージャ２１は、図１４に示したネットワークドメインデータ４８０を読み込み、ネットワークドメインに対応するフロントサブドメイン、バックサブドメインおよび機器の情報を取得する。
さらに、システムリソースマネージャ２１は、図１７に示したネットワークサブグループデータ６６０を読み込み、フロントサブドメイン、および、バックサブドメインに対応するネットワークサブドメインをネットワークサブグループデータ６６０から検索し、検索したネットワークサブドメインに対応するネットワークサブグループのうち、未使用のネットワークサブグループを抽出する。
続いて、システムリソースマネージャ２１は、図１４に示したネットワークドメインデータ４８０から読み込んだ機器の情報に該当するネットワーク機器を１つまたは複数のグループに分けて、システムリソースＤＢ２６にその情報を、以下に説明する負荷分散グループデータ８４０として記憶する。
図２９は、負荷分散装置のグループ情報を記憶した負荷分散グループデータ８４０の一例を示す図である。この負荷分散グループデータ８４０は、負荷分散グループ名、ロードバランサ名および代表ＩＰの情報を記憶している。
負荷分散グループ名は、ロードバランサを１つまたは複数のグループに分けた場合のグループを識別する情報である。ロードバランサ名は、ロードバランサを識別する名称である。代表ＩＰは、各負荷分散グループに割り当てられたＩＰアドレスの情報である。
その後、システムリソースマネージャ２１は、上記各ネットワークグループに属するネットワークドメインやネットワークサブグループ、負荷分散グループなどの対応関係の情報に基づいて、システムリソースＤＢ２６にその情報を、以下に説明するネットワークグループデータ８５０として記憶する。
図３０は、ネットワークグループに係る情報を記憶したネットワークグループデータ８５０の一例を示す図である。このネットワークグループデータ８５０は、ネットワークグループ名、ネットワークドメイン名、フロントネットワークサブグループ名、負荷分散グループ名およびバックネットワークサブグループ名の情報を記憶している。
ネットワークグループ名は、図２８で説明したネットワークグループと同様の情報である。ネットワークドメイン名は、図１８で説明したネットワークドメインと同様の情報である。
フロントネットワークサブグループ名は、図１７で説明したネットワークサブグループ名に対応するものであり、負荷分散グループを挟むネットワークサブグループのうち、よりインターネット７０側にあるネットワークサブグループを識別する識別情報である。
負荷分散グループ名は、図２９で説明した負荷分散グループ名と同様の情報である。バックネットワークサブグループ名は、図１７で説明したネットワークサブグループ名に対応するものであり、負荷分散グループを挟むネットワークサブグループのうち、よりインターネット７０から遠い側にあるネットワークサブグループを識別する識別情報である。
さらに、システムリソースマネージャ２１は、ネットワークＲＭ２４およびネットワークサブＲＭ５４と連携し、図１３のネットワークサブドメインデータ４７０に登録されたスイッチに対して、ネットワークサブグループのＶＬＡＮの設定をおこなう。
続いて、システムリソースマネージャ２１は、サーバグループに一台目のサーバを追加して、そのサーバに導入されたソフトウェアのソフトウェアイメージを作成する処理をおこなう（ステップＳ１０５）。以下に、ステップＳ１０５でおこなわれる処理をさらに詳細に説明する。
まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、サーバとそのサーバを登録するサーバグループを指定した場合に、サーバおよびサーバグループの情報を受け付け、サーバグループにサーバを登録する。
そして、システムリソースマネージャ２１は、図２６のサーバグループデータ８１０を読み込んでサーバグループに対応するストレージテンプレートを検索し、そのストレージテンプレートの設定条件を図２５のストレージテンプレートデータ８００から取得する。
さらに、ストレージＲＭ２５は、システムリソースマネージャ２１により取得されたストレージテンプレートの設定条件を満足するようプールされたストレージに論理ボリュームを設定し、論理ボリュームが設定されたストレージを上記サーバグループに割り当てる処理をおこなう。
図３１は、論理ボリュームをＲＡＩＤ装置に設定する設定処理の処理手順を示すフローチャートである。図３１に示すように、まず、システムリソースマネージャ２１は、論理ボリュームの必要条件の情報を取得する（ステップＳ２０１）。ここで、論理ボリュームの必要条件とは、図２５のストレージテンプレートデータ８００に記憶された信頼性の必要度、負荷の度合い、および、ディスク容量の情報である。
図３２は、論理ボリュームの設定画面の一例を示す図である。図３２には、システムリソースマネージャ２１が、運用管理クライアント１０に対して出力する論理ボリュームの必要条件を表示した必要条件出力画面８６０と、論理ボリューム設定後の論理ボリューム構成出力画面８８０とが示されている。
図３２の例では、３つの必要条件を満足する３つの論理ボリュームを作成するよう要求された場合が示されている。そして、必要条件出力画面８６０には、３つの必要条件８７０ａ〜８７０ｃが出力される。
図３１の説明に戻ると、システムリソースマネージャ２１は、信頼性の必要度および負荷の度合いに応じて、ＲＡＩＤ装置のＲＡＩＤレベルを決定する（ステップＳ２０２）。図３３は、ＲＡＩＤレベルの設定情報を記憶したＲＡＩＤレベル設定データ９４０の一例を示す図である。
このＲＡＩＤレベル設定データ９４０は、信頼性の必要度、負荷の度合いおよびＲＡＩＤレベルの情報を記憶している。信頼性の必要度は、図２５で説明した信頼性の必要度と同様の情報である。負荷の度合いは、図２５で説明した負荷の度合いと同様の情報である。ＲＡＩＤレベルは、信頼性の必要度および負荷の度合いにより決定されるＲＡＩＤレベルの情報である。
図３１の説明に戻ると、システムリソースマネージャ２１は、必要とされるディスク容量の合計値から、ＲＡＩＤ装置種を決定する（ステップＳ２０３）。図３４は、ＲＡＩＤ装置に係る情報を記憶したＲＡＩＤ装置データ９５０の一例を示す図である。
このＲＡＩＤ装置データ９５０は、必要な記憶容量合計値、ＲＡＩＤ装置の型名、データアクセススピード、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）およびＲＡＩＤグループの最大数の情報を記憶している。
必要な記憶容量合計値は、論理ボリュームに必要とされるディスク容量の合計値の情報である。ＲＡＩＤ装置の型名は、必要な記憶容量合計値を確保するのに適したＲＡＩＤ装置の型名の情報である。
データアクセススピードは、ＲＡＩＤ装置の型名により特定されるディスクドライブのデータのアクセススピードの情報である。このデータアクセススピードには、アクセススピードが速い順に、「一番目」、「二番目」、「三番目」の３つのディスクドライブ種の情報が記憶されている。
ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）は、ＲＡＩＤレベルがＲＡＩＤ０＋１の場合において、ＲＡＩＤグループを構成するディスクドライブの数の情報である。ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）は、ＲＡＩＤレベルがＲＡＩＤ５の場合において、ＲＡＩＤグループを構成するディスクドライブの数の情報である。ＲＡＩＤグループの最大数は、作成するＲＡＩＤグループの最大数の情報である。
図３１の説明に戻ると、システムリソースマネージャ２１は、図３４で説明したＲＡＩＤ装置データ９５０から、ＲＡＩＤ装置種ごとの特有情報を取得する（ステップＳ２０４）。
ここで、特有情報とは、データアクセススピードのうち、「一番目」に該当するディスクドライブ種、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）およびＲＡＩＤグループの最大数の情報である。
そして、ストレージＲＭ２５は、論理ボリュームを作成する（ステップＳ２０５）。具体的には、ストレージＲＭ２５は、論理ボリュームの各必要条件を満足する論理ボリュームを作成し、ＲＡＩＤ装置に論理ボリュームを設定する。
図３２に示した論理ボリューム構成出力画面８８０には、各必要条件９００ａ〜９００ｃを満足する論理ボリューム９１０ａ〜９１０ｄ，９２０ａ〜９２０ｅが、ＲＡＩＤ装置８９０に設定された状況が示されている。
図３１の説明に戻ると、ストレージＲＭ２５は、ＲＡＩＤレベルが同一である論理ボリュームをグループ化したＲＡＩＤグループを作成する（ステップＳ２０６）。そして、ストレージＲＭ２５は、作成したＲＡＩＤグループに論理ボリュームを割り当てる（ステップＳ２０７）。
図３２の例では、必要条件９００ａおよび必要条件９００ｂを満足する論理ボリューム９１０ａ〜９１０ｄは、ＲＡＩＤレベルがＲＡＩＤ０＋１で同じであるので、ＲＡＩＤグループ９３０ａにグループ化されている。また、必要条件９００ｃを満足する論理ボリューム９２０ａ〜９２０ｅは、ＲＡＩＤレベルがＲＡＩＤ５であるので、ＲＡＩＤグループ９３０ｂとしてグループ化されている。
ＲＡＩＤグループを作成する際には、ストレージＲＭ２５は、各ＲＡＩＤグループに属するディスクドライブを、図３４のＲＡＩＤ装置データ９５０のデータアクセススピードにより決定されるディスクドライブ種に設定する。
また、ストレージＲＭ２５は、ＲＡＩＤグループを構成するディスクドライブ数を、図３４のＲＡＩＤ装置データ９５０のＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ０＋１の場合）、または、ＲＡＩＤグループを構成するディスクドライブ数（ＲＡＩＤ５の場合）により決定されるディスクドライブ数に設定する。
さらに、ストレージＲＭ２５は、ＲＡＩＤグループの数が図３４のＲＡＩＤ装置データ９５０のＲＡＩＤグループの最大数以下になるようＲＡＩＤグループを作成する。
図３２の論理ボリューム構成出力画面８８０では、必要条件９００ａ〜９００ｃを満足し、各ＲＡＩＤグループ９３０ａ，９３０ｂに割り当てられた論理ボリューム９１０ａ〜９１０ｄ，９２０ａ〜９２０ｅが、対応する必要条件９００ａ〜９００ｃと線で結合されて表示されている。
図３１の説明に戻ると、ストレージＲＭ２５は、図３２に示した論理ボリュームの構成をＲＡＩＤ装置に反映させるコマンドファイルを作成する（ステップＳ２０８）。そして、ストレージＲＭ２５は、そのコマンドファイルに基づいて、作成した論理ボリュームを実装置に反映させる（ステップＳ２０９）。
その後、システムリソースマネージャ２１は、各サーバが属するサーバグループに対応付けて、ＲＡＩＤ装置に設定された論理ボリュームをストレージサブグループとして登録し、サーバのストレージグループに対するアクセス権を設定する。具体的には、システムリソースマネージャ２１は、図２２に示したプロビジョニング構成データ７１０にサーバグループ名、ストレージサブグループ名およびアクセス可否の情報を記憶する。
図３５は、ストレージサブグループが設定されたプロビジョニング構成データ９６０の一例を示す図である。このプロビジョニング構成データ９６０には、図２２に示したプロビジョニング構成データ７１０にサーバグループ名、ストレージサブグループ名およびアクセス可否の情報が追加されている。
ＲＡＩＤ装置に構築された論理ボリュームをサーバに認識させ、ストレージサブグループとして登録する場合には、ストレージＲＭ２５は、以下のような手順で論理ボリュームの設定をおこなう。
図３６は、サーバに論理ボリュームを認識させる論理ボリュームの設定処理の処理手順を示すフローチャートである。図３６に示すように、まず、ストレージＲＭ２５は、ＲＡＩＤ装置の論理ボリュームをグループ化し、アフィニティグループを設定する（ステップＳ３０１）。
ここで、アフィニティグループとは、サーバが認識する論理ユニット番号（ＬＵＮ， Logical Unit Number）とＲＡＩＤ装置における論理ボリューム（ＬＶ， Logical Volume）番号との間の対応関係を示す情報である。
図３７は、ＲＡＩＤ装置に構築された論理ボリュームの設定処理を説明する説明図である。図３７には、サーバ「A」およびサーバ「B」から構成されるサーバグループ９７０と、論理ボリューム「LV0」、「LV1」、「LV2」、「LV3」が構築されたＲＡＩＤ装置「α」、および、論理ボリューム「LV10」、「LV11」、「LV12」、「LV13」が構築されたＲＡＩＤ装置「β」から構成されるストレージプール９８０とが示されている。
さらに、図３７には、ストレージプール９８０からＲＡＩＤ装置「α」の論理ボリューム「LV0」および「LV1」と、ＲＡＩＤ装置「β」の論理ボリューム「LV12」および「LV13」とが追加されたストレージグループ９９０が示されている。
ストレージグループ９９０に追加されたＲＡＩＤ装置「α」の論理ボリューム「LV0」および「LV1」は、アフィニティグループ「AG0」およびアフィニティグループ「AG1」に属するように設定されている。また、ＲＡＩＤ装置「β」の論理ボリューム「LV12」および「LV13」は、アフィニティグループ「AG10」およびアフィニティグループ「AG11」に属するように設定されている。
図３８は、アフィニティグループに係る情報を記憶したアフィニティグループデータ１０１０である。このアフィニティグループデータ１０１０は、ＲＡＩＤ装置名、アフィニティグループ名、ＬＵＮおよびＬＶの情報を記憶している。
ＲＡＩＤ装置名は、各ＲＡＩＤ装置を識別する識別情報である。アフィニティグループ名は、各ＲＡＩＤ装置において設定されたアフィニティグループの識別情報である。ＬＵＮは、サーバＡまたはサーバＢからアクセスする際に論理ボリュームを識別する識別情報である。ＬＶは、論理ボリュームを識別する識別情報である。
図３６の説明に戻ると、ストレージＲＭ２５は、サーバ「A」およびサーバ「B」と、論理ボリューム「LV0」，「LV1」，「LV12」，「LV13」との間の冗長パスをチェックし、パスを選択することによりアクセスパスを設定する（ステップＳ３０２）。
そして、ストレージＲＭ２５は、論理ユニットに対するマルチパスの設定をおこなう（ステップＳ３０３）。図３９は、マルチパスの構成に係る情報を記憶したマルチパス構成データ１０２０の一例を示す図である。
このマルチパス構成データ１０２０は、マルチパスインスタンス名およびＬＵＮの情報を記憶している。マルチパスインスタンス名は、設定されたマルチパスのインスタンスを識別する情報である。ＬＵＮは、設定されたマルチパスインスタンスに対応し、サーバ「A」またはサーバ「B」により認識される論理ユニットを識別する情報である。
そして、ストレージＲＭ２５は、設定したマルチパスインスタンスをミラーボリュームの構成要素としてクラスタリングをおこなうサーバのクラスタリソースに登録する（ステップＳ３０４）。その後、ストレージＲＭ２５は、クラスタリソースに登録されたマルチパスインスタンスを用いて異なるＲＡＩＤ装置のボリュームどうしをペアとするミラーボリュームグループを設定する（ステップＳ３０５）。
図３７には、サーバ「A」またはサーバ「B」において内部設定されるサーバ内ストレージ構成１０００が示されている。このストレージ構成１０００においては、マルチパスインスタンス「mplb0」およびマルチパスインスタンス「mplb2」とから構成されるミラーボリューム「M0」と、マルチパスインスタンス「mplb1」およびマルチパスインスタンス「mplb3」とから構成されるミラーボリューム「M1」とが設定されている。
図４０は、ミラーボリュームの構成に係る情報を記憶したミラーボリューム構成データ１０３０である。このミラーボリューム構成データ１０３０は、ミラーボリュームおよび構成ディスクの情報を記憶している。
ミラーボリュームは、設定されたミラーボリュームを識別する識別情報である。構成ディスクは、ミラーボリュームを構成する論理ユニットを識別する識別情報である。ここで、構成ディスクには、図３９に示したマルチパス構成データ１０２０におけるマルチパスインスタンスの情報が記憶されているが、マルチパス構成データ１０２０を参照することにより、ミラーボリュームに対応するＬＵＮを特定することができる。
図３８に示したアフィニティグループデータ１０１０は、ストレージＲＭ２５によりシステムリソースＤＢ２６およびＲＡＩＤ装置内に記憶される。また、図３９に示したマルチパス構成データ１０２０、および、図４０に示したミラーボリューム構成データ１０３０は、ストレージＲＭ２５によりシステムリソースＤＢ２６に記憶されるとともに、ストレージＲＭエージェント１１５ａにより管理対象であるサーバ内に記憶される。
図４に示すステップＳ１０５におけるソフトウェアイメージの作成処理の説明に戻ると、ネットワークＲＭ２４は、サーバグループに登録したサーバのネットワークの設定をつぎにおこなう。
具体的には、ネットワークＲＭ２４は、図２８に示したサーバグループ間リンクデータ８３０から、サーバを追加したサーバグループをフロントサーバグループおよびバックサーバグループとして有するネットワークグループの情報を読み込む。
さらに、ネットワークＲＭ２４は、図３０に示したネットワークグループデータ８５０を読み込み、ネットワークグループに対応するフロントネットワークサブグループおよびバックネットワークサブグループを抽出する。
その後、ネットワークＲＭ２４は、図１７に示したネットワークサブグループデータ６６０を読み込み、フロントネットワークサブグループおよびバックネットワークサブグループに対応するネットワークサブグループを検索し、ネットワークサブグループに割り当てられたサブネットの情報を基にして、サーバにＩＰアドレスを割り当てる。
図４１は、サーバに割り当てられたＩＰアドレスに係る情報を記憶したＩＰアドレス管理データ１０４０の一例を示す図である。このＩＰアドレス管理データ１０４０は、システムリソースマネージャ２１により、システムリソースＤＢ２６に記憶される。
このＩＰアドレス管理データ１０４０は、ＩＰアドレスおよび割当先の情報を記憶している。ＩＰアドレスは、サーバに割り当てられたＩＰアドレスの情報である。割当先は、ＩＰアドレスの割当先であるサーバを識別する情報である。
続いて、ネットワークＲＭ２４は、図２９に示した負荷分散グループデータ８４０および図３０に示したネットワークグループデータ８５０を基にして、サーバが追加されたサーバグループに対応するネットワークグループに代表ＩＰアドレスを有する負荷分散グループを割り当てる。なお、この時点では、ロードバランサの負荷分散機能は停止状態にある。
その後、ユーザは、サーバに導入するＯＳなどのソフトウェアを、サーバグループに追加するサーバに対応付けられたストレージサブグループにインストールする。このストレージサブグループは、ＳＡＮの技術を用いて構成されたものである。
そして、インストールの終了後、ソフトウェアサブＲＭ５３は、ソフトウェアＲＭ２３およびソフトウェアＲＭエージェント１１３ａと連携して、ＯＳ、デバイスドライバ、アプリケーションソフトウェアなどのソフトウェアの集合体から構成されるソフトウェアイメージを作成し、作成したソフトウェアイメージをドメインリソースＤＢ５５に記憶する。
具体的には、ソフトウェアＲＭ２３は、図８に示したミドルウェア連携ＩＦデータ３３０を読み込み、ソフトウェアＲＭエージェント１１３ａは、ミドルウェアにより実現される機能部であるＡＰ管理部１１６ａに対して、ソフトウェアイメージ採取前に実行が必要なコマンドを送信する。
すなわち、ソフトウェアＲＭエージェント１１３ａは、ＡＰ管理部１１６ａの機能を停止させるコマンドを送信し、ＡＰ管理部１１６ａの機能を停止させる。そして、ソフトウェアサブＲＭ５３は、サーバのシステムをシャットダウンする。さらに、ソフトウェアサブＲＭ５３は、サーバのドメイン管理サーバ５０のドメインリソースＤＢ５５に記憶された仮のＯＳを用いてサーバのネットワークブートをおこなう。
その後、ソフトウェアサブＲＭ５３は、起動したサーバに導入されているソフトウェアのソフトウェアイメージを作成する。そして、ソフトウェアＲＭ２３は、システムリソースＤＢ２６にソフトウェアイメージに係る情報を、以下に説明するソフトウェアイメージ管理データ１０５０として登録する。
図４２は、ソフトウェアイメージに係る情報を記憶したソフトウェアイメージ管理データ１０５０の一例を示す図である。このソフトウェアイメージ管理データ１０５０は、ソフトウェアイメージ名、形式、ＯＳ属性およびソフトウェア名の情報を記憶している。
ソフトウェアイメージ名は、ソフトウェアイメージの名称である。形式は、ソフトウェアイメージがアーカイブ形式で作成されたものであるのか、パッチ形式で作成されたものであるのかを示す情報である。ＯＳ属性は、ソフトウェアイメージが、ＯＳのソフトウェアイメージであるか否かを示す情報である。ソフトウェア名は、ソフトウェアイメージが作成されたソフトウェアの名称である。
さらに、ソフトウェアサブＲＭ５３は、作成したソフトウェアイメージを基にして、他のサーバ用に配布するソフトウェア配布イメージを作成する。具体的には、ソフトウェアサブＲＭ５３は、一台目のサーバ用にストレージに導入された複数のソフトウェアのソフトウェアイメージを組にしたソフトウェア配布イメージを作成する。
そして、システムリソースマネージャ２１は、システムリソースＤＢ２６にソフトウェア配布イメージに係る情報を、以下に説明するソフトウェア配布イメージ管理データ１０６０として記憶する。
図４３は、ソフトウェア配布イメージに係る情報を記憶したソフトウェア配布イメージ管理データ１０６０の一例を示す図である。このソフトウェア配布イメージ管理データ１０６０は、ソフトウェア配布イメージ名、版数、サーバアーキテクチャ名およびソフトウェアイメージ／スナップショット名の情報を記憶している。
ソフトウェア配布イメージ名は、ソフトウェア配布イメージの名称である。版数は、ソフトウェア配布イメージの版数である。サーバアーキテクチャ名は、ソフトウェア配布イメージの配布対象となるサーバのＣＰＵアーキテクチャを識別する識別情報である。ソフトウェアイメージ／スナップショット名は、ソフトウェア配布イメージに含まれるソフトウェアイメージまたはスナップショットを識別する識別情報である。
ここでスナップショットとは、ある特定の時点でサーバに導入されているソフトウェアのソフトウェアイメージである。システムリソースマネージャ２１は、システムリソースＤＢ２６にスナップショットに係る情報を、以下に説明するスナップショット管理データ１０７０として登録する。
図４４は、スナップショットに係る情報を記憶したスナップショット管理データ１０７０の一例を示す図である。このスナップショット管理データ１０７０は、スナップショット名およびソフトウェアイメージ名の情報を記憶している。スナップショット名は、スナップショットの名称である。ソフトウェアイメージ名は、スナップショットに含まれるソフトウェアイメージを識別する識別情報である。
その後、ソフトウェアＲＭ２３は、図８に示したミドルウェア連携ＩＦデータ３３０を読み込み、ソフトウェアＲＭエージェント１１３ａは、ミドルウェアにより実現される機能部であるＡＰ管理部１１６ａに対して、ソフトウェアイメージ採取後に実行が必要なコマンドを送信する。
具体的には、ソフトウェアＲＭエージェント１１３ａは、停止していたＡＰ管理部１１６ａを始動させるコマンドを送信し、ＡＰ管理部１１６ａを始動させる。そして、ネットワークＲＭ２４は、スイッチにＶＬＡＮの設定をおこなってサーバをＶＬＡＮに接続するとともに、ロードバランサの負荷分散機能を始動させ、負荷を分散させる対象サーバとして当該サーバを割り当てる。
その後、システムリソースマネージャ２１は、図８に示したミドルウェア連携ＩＦデータ３３０を読み込み、ミドルウェアにより実現される機能部であるＡＰ管理統括部２７に対して、サーバグループ作成後に実行が必要なコマンドを送信する。
具体的には、システムリソースマネージャ２１はＡＰ管理統括部２７に対して、サーバグループの追加を認識させるコマンドを送信する。そして、ＡＰ管理統括部２７は、ＡＰ管理部１１６ａと連携して、サーバに対してアプリケーションプログラムの導入および設定などをおこない、サーバを業務で利用可能な状態に設定する。
図４の説明に戻ると、システムリソースマネージャ２１は、二台目以降のサーバをサーバグループに追加する処理をおこなう（ステップＳ１０６）。以下に、ステップＳ１０６でおこなわれる処理をさらに詳細に説明する。
図４５は、サーバをサーバグループに追加する処理の処理手順を示すフローチャートである。図４５に示すように、まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して、サーバとそのサーバを登録するサーバグループを指定した場合に、サーバおよびサーバグループの情報を受け付ける（ステップＳ４０１）。
そして、システムリソースマネージャ２１は、サーバグループにサーバを登録する（ステップＳ４０２）。続いて、システムリソースマネージャ２１は、図２１に示した管理対象サーバデータ７００および図４３に示したソフトウェア配布イメージ管理データ１０６０を読み込んで、サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものか否かを調べる（ステップＳ４０３）。サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものでない場合には（ステップＳ４０３，Ｎｏ）、当該サーバのサーバグループへの追加処理を終了する。
サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものである場合には（ステップＳ４０３，Ｙｅｓ）、ストレージＲＭ２５は、一台目のサーバにストレージを設定した場合と同様の方法で、サーバに対してストレージを設定する処理をおこなう（ステップＳ４０４）。具体的には、ストレージＲＭ２５は、図３１および図３６で説明した論理ボリュームの設定処理を当該サーバに対して実行する。
続いて、ネットワークＲＭ２４は、一台目のサーバにネットワークを設定した場合と同様の方法で、サーバグループに登録したサーバのネットワークブートを仮のＯＳを用いておこない、サーバのネットワークの設定をおこなう（ステップＳ４０５）。
その後、ソフトウェアサブＲＭ５３は、一台目のサーバに導入されたソフトウェアから作成されたソフトウェア配布イメージを二台目のサーバに対応付けられたストレージサブグループに展開し、展開されたソフトウェアを用いてサーバを再起動させる（ステップＳ４０６）。
ソフトウェア配布イメージをサーバに対応付けられたストレージサブグループに展開した場合には、ソフトウェアＲＭ２３は、システムリソースＤＢ２６に、配布したソフトウェア配布イメージに係る情報を記憶する。
図４６は、ソフトウェア配布イメージの配布状況に係る情報を記憶した配布管理データ１０８０の一例を示す図である。この配布管理データ１０８０は、サーバ名、ストレージサブグループ名、ソフトウェア配布イメージ名、版数および状態の情報を記憶している。
サーバ名は、ストレージサブグループが割り当てられているサーバを識別する情報である。ストレージサブグループ名は、ソフトウェア配布イメージが展開されるストレージサブグループを識別する情報である。ソフトウェア配布イメージ名は、ストレージサブグループに展開されたソフトウェア配布イメージを識別する情報である。版数は、配布されたソフトウェア配布イメージの版数の情報である。状態は、ソフトウェア配布イメージの配布状況を示す情報である。
図４５の説明に戻ると、システムリソースマネージャ２１は、ネットワークＲＭ２４およびＡＰ管理統括部２７と連携して、二台目のサーバを業務モードに移行させる処理をおこなう（ステップＳ４０７）。
具体的には、ネットワークＲＭ２４は、サーバの再起動時に、一台目のサーバが属するサブネットの情報に基づいて、二台目のサーバにＩＰアドレスを割り当てる。二台目のサーバに割り当てられたＩＰアドレスの情報は、システムリソースマネージャ２１により、図４１に示したＩＰアドレス管理データ１０４０に記憶される。
続いて、ネットワークＲＭ２４は、スイッチにＶＬＡＮの設定をおこなってサーバをＶＬＡＮに接続するとともに、ロードバランサに対して、負荷を分散させる対象サーバとして当該サーバを登録させる。
その後、システムリソースマネージャ２１は、ＡＰ管理統括部２７に対して、サーバのサーバグループの追加をＡＰ管理統括部２７に認識させるコマンドを送信する。そして、ＡＰ管理統括部２７は、ＡＰ管理部１１６ａと連携して、サーバに対してアプリケーションプログラムの導入および設定などをおこない、サーバを業務で利用可能な状態に設定する。
三台目以降のサーバをサーバグループに追加する場合には、図４５で説明したサーバの追加処理を繰り返す。
つぎに、図２で説明したリパーパシング処理の処理手順を図４７および図４８を用いて説明する。図４７は、リパーパシング処理に係る事前設定処理の処理手順を説明するフローチャートであり、図４８は、リパーパシング処理の処理手順を示すフローチャートである。
図４７に示すように、まず、システムリソースマネージャ２１は、ユーザが運用管理クライアント１０を操作して設定したリパーパシングの設定に係る情報を受け付け、システムリソースＤＢ２６にその情報を、以下に説明するリパーパシング設定データ１０９０およびスケジュール設定データ１１１０として登録する（ステップＳ５０１）。
図４９は、リパーパシングの設定に係る情報を記憶したリパーパシング設定データ１０９０の一例を示す図である。このリパーパシング設定データ１０９０は、リパーパシング定義名、使用サーバ数、状態１、状態２および状態３の情報を記憶している。
リパーパシング定義名は、リパーパシングの各設定に対して付与されたリパーパシングの定義名の情報である。使用サーバ名は、リパーパシング処理に使用するサーバの台数の情報である。状態１、状態２および状態３は、リパーパシング処理において、用途が異なるサーバグループにサーバが属する状態が３つある場合に、それぞれの状態においてサーバがどのサーバグループに帰属するのかを識別する情報である。この状態１、状態２および状態３には、それぞれ状態において、サーバが帰属するサーバグループの識別情報が記憶される。
ここで、サーバが現在どのサーバグループに属しているかの状態に係る情報は、システムリソースマネージャ２１により、以下に説明するリパーパシング運用データ１１００としてシステムリソースＤＢ２６に登録されている。図５０は、サーバの状態に係る情報を記憶したリパーパシング運用データ１１００の一例を示す図である。
このリパーパシング運用データ１１００は、リパーパシング定義名および現在の状態の情報を記憶している。リパーパシング定義名は、図４９で説明したリパーパシング定義名と同様の情報である。現在の状態は、サーバが現在どのサーバグループに属しているかの状態を識別する情報である。この現在の状態には、図４９のリパーパシング設定データ１０９０の状態１、状態２または状態３のいずれかの状態に係る情報が記憶される。
図５１は、リパーパシング処理を実行するスケジュールに係る情報を記憶したスケジュール設定データ１１１０の一例を示す図である。このスケジュール設定データ１１１０は、リパーパシング定義名、日時および動作の情報を記憶している。
リパーパシング定義名は、図４９で説明したリパーパシング定義名と同様の情報である。日時は、リパーパシング処理を実行する日時の情報である。動作は、リパーパシング処理において、図４９で説明した状態を切り替える場合の切り替え元の状態および切り替え先の状態を識別する情報である。
なお、図４９に示したリパーパシング設定データ１０９０、図５０に示したリパーパシング運用データ１１００および図５１に示したスケジュール設定データ１１１０には、状態１、状態２または状態３の３つの状態に係る情報が記憶されるが、その数は３つに限定されるものではなく、任意の数の状態に係る情報を記憶することができる。以下では、簡略化のため、状態１および状態２の２つの状態を切り替えるリパーパシング処理をおこなう場合について説明することとする。
図４７の説明に戻ると、システムリソースマネージャ２１は、状態の切り替えをおこなうサーバグループが同一のサーバドメインに属するサーバグループに属すること、また、プールグループに管理対象となるサーバが図４９の使用サーバ数に設定された台数存在することをチェックする（ステップＳ５０２）。
具体的には、システムリソースマネージャ２１は、サーバグループのチェックを図２６に示したサーバグループデータ８１０を参照して実行する。また、システムリソースマネージャ２１は、プールグループのチェックを図２２に示したプロビジョニング構成データ７１０を参照して実行する。
そして、システムリソースマネージャ２１は、図４９に示した状態１に対応する切り替え用のサーバグループにサーバを登録する（ステップＳ５０３）。そして、システムリソースマネージャ２１は、ストレージＲＭ２５と連携して、サーバを登録したサーバグループに対するストレージサブグループを作成する（ステップＳ５０４）。
具体的には、システムリソースマネージャ２１は、ストレージＲＭ２５と連携することにより、ＲＡＩＤ装置に論理ボリュームを設定し、図２５に示したストレージテンプレートデータ８００および図２６に示したサーバグループデータ８１０を参照して、図３５に示したように、サーバグループに対応するストレージサブグループを作成する。さらに、システムリソースマネージャ２１は、作成したストレージサブグループに対するサーバからのアクセスを許可する。
続いて、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０を参照することにより、サーバを登録したサーバグループに配信すべきソフトウェア配布イメージを選択する。そして、ソフトウェアサブＲＭ５３は、サーバグループに対応するストレージサブグループにそのソフトウェア配布イメージを配信して展開する（ステップＳ５０５）。
その後、システムリソースマネージャ２１は、ネットワークサブＲＭ５４と連携して、ソフトウェア配布イメージを配信したストレージサブグループに対応するサーバからのストレージサブグループに対するアクセスを不許可に設定することにより、当該サーバをサーバグループから切り離す（ステップＳ５０６）。その際、システムリソースマネージャ２１は、ストレージサブグループの削除はおこなわず、保存しておく。
続いて、システムリソースマネージャ２１は、サーバグループから切り離されたサーバを、状態２に対応する切り替え用の別のサーバグループに登録する（ステップＳ５０７）。そして、システムリソースマネージャ２１は、ストレージＲＭ２５と連携して、サーバを登録したサーバグループに対するストレージサブグループを作成する（ステップＳ５０８）。
具体的には、システムリソースマネージャ２１は、ストレージＲＭ２５と連携することにより、ＲＡＩＤ装置に論理ボリュームを設定し、図２５に示したストレージテンプレートデータ８００および図２６に示したサーバグループデータ８１０を参照して、図３５に示したように、サーバグループに対応するストレージサブグループを作成する。さらに、システムリソースマネージャ２１は、作成したストレージサブグループに対するサーバからのアクセスを許可する。
その後、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０を参照することにより、サーバを登録したサーバグループに配信すべきソフトウェア配布イメージを選択する。そして、ソフトウェアサブＲＭ５３は、サーバグループに対応するストレージサブグループにそのソフトウェア配布イメージを配信して展開し（ステップＳ５０９）、この事前設定処理を終了する。
なお、状態数が３以上である場合には、ステップＳ５０９の後、サーバをサーバグループから切り離し、状態の数だけステップＳ５０７からステップＳ５０９の処理およびサーバをサーバグループから切り離す処理を繰り返し実行すればよい。
つぎに、図４８に示すように、リパーパシング処理においては、システムリソースマネージャ２１は、切り替え先のサーバグループの情報を、図４９に示したリパーパシング設定データ１０９０から取得する（ステップＳ６０１）。
そして、システムリソースマネージャ２１は、図２６に示したサーバグループデータ８１０を参照して、サーバグループに対応するソフトウェア配布イメージの情報を取得し、さらに、図４６を参照して、そのソフトウェア配布イメージが配信済であることをチェックする（ステップＳ６０２）。
その後、システムリソースマネージャ２１は、ネットワークサブＲＭ５４と連携して、サーバからのストレージサブグループに対するアクセスを不許可に設定することにより、サーバが現在属するサーバグループから当該サーバを切り離し、プールグループに追加する（ステップＳ６０３）。その際、システムリソースマネージャ２１は、ストレージサブグループの削除はおこなわず、保存しておく。
続いて、システムリソースマネージャ２１は、プールグループに追加されたサーバを、切り替え先のサーバグループに登録し（ステップＳ６０４）、登録したサーバグループに対応するストレージサブグループに作成された論理ボリュームに対するサーバからのアクセスを許可する（ステップＳ６０５）。
そして、サーバＲＭ２２は、サーバサブＲＭ５２と連携して、アクセスが許可された論理ボリュームを起動ディスクとしてサーバを起動し（ステップＳ６０６）、このリパーパシング処理を終了する。
なお、上記リパーパシング処理では、図４９に示したように、各状態に対して１つのサーバグループを設定しているが、各状態に対して１つ以上のサーバグループを設定することとしてもよい。
図５２は、各状態に１つ以上のサーバグループを設定したリパーパシング設定データ１１２０の一例を示す図である。このリパーパシング設定データ１１２０は、リパーパシング定義名、使用サーバ名、状態１および状態２の情報を記憶している。
リパーパシング定義名は、図４９で説明したリパーパシング定義名と同様の情報である。使用サーバ数は、図４９で説明した使用サーバ数と同様の情報である。状態１および状態２は、リパーパシング処理において、用途の異なるサーバグループにサーバが属する状態が２つある場合に、それぞれの状態においてサーバがどのサーバグループに帰属するのか識別する情報である。この状態１および状態２には、それぞれ状態において、サーバが帰属するサーバグループの識別情報が記憶される。
ここで、図４９で説明したリパーパシング設定データ１０９０の状態１、状態２および状態３と異なる点は、１つのリパーパシング定義名に対して、各状態に１つ以上のサーバグループを設定して、サーバグループに属するサーバが利用するソフトウェアを別のソフトウェアに切り替え、サーバグループに属するサーバの用途を別の用途に変更する点である。
図５２の例では、状態１に対して、サーバグループ「A_DB」とサーバグループ「B_DB」とが登録され、状態２に対して、サーバグループ「A_Batch」が登録されている。そして、状態１から状態２へと状態が変更される場合には、サーバグループ「A_DB」とサーバグループ「B_DB」とに属するサーバの２つの用途から、サーバグループ「A_Batch」に属するサーバの１つの用途にサーバの用途が変更される。
また、状態２から状態１へと状態が変更される場合には、サーバグループ「A_Batch」に属するサーバの１つの用途から、サーバグループ「A_DB」とサーバグループ「B_DB」とに属するサーバの２つの用途にサーバの用途が変更される。また、状態１および状態２のそれぞれに複数のサーバグループが登録された場合には、各サーバグループに属するサーバの複数の用途から別の複数の用途にサーバの用途が変更される。
また、各サーバグループには、各サーバグループに割り当てるサーバ数を設定することとしてもよい。図５２の例では、状態１に対して、サーバグループ「A_DB」とサーバグループ「B_DB」とが登録され、使用サーバ数により指定される４台のサーバのうち、サーバグループ「A_DB」に対しては１台のサーバを、サーバグループ「B_DB」に対しては３台のサーバを割り当てるよう設定されている。状態２においては、サーバグループ「A_Batch」に対して、４台のサーバを割り当てるよう設定されている。
上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図５３から図５５を用いて、上記各種処理を実現するプログラムを実行するコンピュータの一例について説明する。
図５３は、図３に示したサイト管理サーバ２０となるコンピュータ１２００のハードウェア構成を示す図である。このコンピュータ１２００は、ユーザからのデータの入力を受け付ける入力装置１２１０、モニタ１２２０、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置１２３０、ＲＯＭ（Read Only Memory）１２４０、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース１２５０、ＨＤＤ（Hard Disk Drive）１２６０、ＲＡＭ（Random Access Memory）１２７０およびＣＰＵ（Central Processing Unit）１２８０をバス１２９０で接続して構成される。
そして、ＨＤＤ１２６０には、サイト管理サーバ２０の機能と同様の機能を発揮するプログラム、つまり、図５３に示すシステムリソース管理プログラム１２６０ｂおよびＡＰ管理統括プログラム１２６０ｃが記憶されている。
なお、システムリソース管理プログラム１２６０ｂおよびＡＰ管理統括プログラム１２６０ｃについては、適宜統合または分散して記憶することとしてもよい。
そして、ＣＰＵ１２８０が、システムリソース管理プログラム１２６０ｂおよびＡＰ管理統括プログラム１２６０ｃをＨＤＤ１２６０から読み出して実行することにより、システムリソース管理プロセス１２８０ａおよびＡＰ管理統括プロセス１２８０ｂとして機能するようになる。
このシステムリソース管理プロセス１２８０ａは、図３に示したシステムリソースマネージャ２１、サーバＲＭ２２、ソフトウェアＲＭ２３、ネットワークＲＭ２４、ストレージＲＭ２５に対応する。また、ＡＰ管理統括プロセス１２８０ｂは、図３に示したＡＰ管理統括部２７に対応する。
また、ＨＤＤ１２６０には、システムリソースデータ１２６０ａが記憶される。なお、このシステムリソースデータ１２６０ａは、図３に示したシステムリソースＤＢ２６に記憶される各種データに対応する。
そして、ＣＰＵ１２８０は、リソースの管理に係る各種データをシステムリソースデータ１２６０ａとして記憶するとともに、システムリソースデータ１２６０ａをＨＤＤ１２６０から読み出してＲＡＭ１２７０に格納し、ＲＡＭ１２７０に格納されたシステムリソースデータ１２７０ａに基づいて各種データ処理を実行する。
図５４は、図３に示したドメイン管理サーバ２０となるコンピュータ１３００のハードウェア構成を示す図である。このコンピュータ１３００は、ユーザからのデータの入力を受け付ける入力装置１３１０、モニタ１３２０、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置１３３０、ＲＯＭ１３４０、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース１３５０、ＨＤＤ１３６０、ＲＡＭ１３７０およびＣＰＵ１３８０をバス１３９０で接続して構成される。
そして、ＨＤＤ１３６０には、ドメイン管理サーバ５０，６０の機能と同様の機能を発揮するプログラム、つまり、図５４に示すドメインリソース管理プログラム１３６０ｂが記憶されている。なお、ドメインリソース管理プログラム１３６０ｂについては、適宜統合または分散して記憶することとしてもよい。
そして、ＣＰＵ１３８０が、ドメインリソース管理プログラム１３６０ｂをＨＤＤ１３６０から読み出して実行することにより、ドメインリソース管理プロセス１３８０ａとして機能するようになる。
このドメインリソース管理プロセス１３８０ａは、図３に示したシステムリソースドメインマネージャ５１、サーバサブＲＭ５２、ソフトウェアサブＲＭ５３、ネットワークサブＲＭ５４に対応する。
また、ＨＤＤ１３６０には、ドメインリソースデータ１３６０ａが記憶される。なお、このドメインリソースデータ１３６０ａは、図３に示したドメインリソースＤＢ５５に記憶される各種データに対応する。
そして、ＣＰＵ１３８０は、ドメインにおけるリソースの管理に係る各種データをドメインリソースデータ１３６０ａとして記憶するとともに、ドメインリソースデータ１３６０ａをＨＤＤ１３６０から読み出してＲＡＭ１３７０に格納し、ＲＡＭ１３７０に格納されたドメインリソースデータ１３７０ａに基づいて各種データ処理を実行する。
また、図５５は、図３に示したサーバ１１０ａとなるコンピュータ１４００のハードウェア構成を示す図である。このコンピュータ１４００は、ユーザからのデータの入力を受け付ける入力装置１４１０、モニタ１４２０、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置１４３０、ＲＡＭ１４４０、ＲＯＭ１４５０、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース１４６０、ＨＤＤ１４７０およびＣＰＵ１４８０をバス１４９０で接続して構成される。
そして、ＨＤＤ１４７０には、サーバ１１０ａの機能と同様の機能を発揮するプログラム、つまり、図５５に示すエージェントリソース管理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂが記憶されている。なお、エージェントリソース管理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂについては、適宜統合または分散して記憶することとしてもよい。
そして、ＣＰＵ１４８０が、エージェントリソース管理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂをＨＤＤ１４７０から読み出して実行することにより、エージェントリソース管理プロセス１４８０ａおよびＡＰ管理プロセス１４８０ｂとして機能するようになる。
このエージェントリソース管理プロセス１４８０ａは、図３に示したリソースマネージャエージェント１１１ａ、サーバＲＭエージェント１１２ａ、ソフトウェアＲＭエージェント１１３ａ、ネットワークＲＭエージェント１１４ａおよびストレージＲＭエージェント１１５ａに対応する。また、ＡＰ管理プロセス１４８０ｂは、図３に示したＡＰ管理部１１６ａに対応する。
ところで、システムリソース管理プログラム１２６０ｂ、ＡＰ管理統括プログラム１２６０ｃ、ドメインリソース管理プログラム１３６０ｂ、エージェントリソース管理プログラム１４７０ａおよびＡＰ管理プログラム１４７０ｂについては、必ずしも最初からＨＤＤ１２６０、ＨＤＤ１３６０またはＨＤＤ１４７０に記憶させておく必要はない。
たとえば、コンピュータ１２００、１３００または１４００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、または、コンピュータの内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１２００、１３００または１４００に接続される「他のコンピュータ（またはサーバ）」などに各プログラムを記憶しておき、コンピュータ１２００、１３００または１４００がこれらから各プログラムを読み出して実行するようにしてもよい。
上述してきたように、本実施例では、システムリソースマネージャ２１が、均一のソフトウェアを利用するサーバの集まりとしてサーバグループを登録し、登録したサーバグループに属するサーバが利用するソフトウェアの切り替えを制御することとしたので、サーバの数が多い大規模な情報処理システムにおいても、サーバをサーバグループ単位で管理することにより、サーバの用途の変更を管理者が容易にかつ効率的に実行することができる。
また、本実施例では、システムリソースマネージャ２１が、物理結線が均一なサーバの集まりとしてサーバドメインを登録し、登録したサーバドメインにおいて均一のソフトウェアを利用するサーバの集まりとしてサーバグループを登録することとしたので、物理結線の均一性が保証された各サーバドメインにおいて、用途を切り替えるサーバが属するサーバグループを登録することにより、用途を変更して利用するサーバのサーバグループを管理者が容易に構築し、構築したサーバグループに属するサーバの用途の変更を容易にかつ効率的におこなうことができる。
また、本実施例では、システムリソースマネージャ２１が、サーバグループに属するサーバにＳＡＮを介して接続されたＲＡＩＤ装置に記憶されているソフトウェアに対するサーバからのアクセスを制御することによりサーバが利用するソフトウェアの切り替えを制御することとしたので、ソフトウェアの切り替えを容易に実行し、サーバ群の用途変更処理を効率的におこなうことができる。
また、本実施例では、システムリソースマネージャ２１が、スケジュール設定データ１１１０に基づいて、サーバグループに属するサーバが利用するソフトウェアの切り替えを制御することとしたので、サーバの用途の切り替えを計画的におこなうことができる。
また、本実施例では、システムリソースマネージャ２１が、リパーパシング設定データ１１２０に基づいて、複数のサーバグループに属する複数のサーバがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、１つのサーバグループに属する複数のサーバが利用するソフトウェアを別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のサーバの１つまたは複数の用途を別の用途に変更することとしたので、サーバの用途の変更を柔軟かつ効率的におこなうことができる。
また、本実施例では、システムリソースマネージャ２１が、リパーパシング設定データ１１２０に基づいて、複数のリソースグループに属する指定された数のリソースがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、１つのリソースグループに属するリソースが利用するソフトウェアを指定された数のリソースごとに別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のリソースの１つまたは複数の用途を別の用途に変更することとしたので、各用途に対して必要な数のサーバを分配することができる。
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、請求の範囲に記載した技術的思想の範囲内において種々の異なる実施例にて実施されてもよいものである。
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。
この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
以上のように、本発明にかかる運用管理プログラム、運用管理方法および運用管理装置は、情報処理システムを構成するリソースの運用を管理する運用管理システムに有用であり、特に、サーバなどのリソースの数が多い大規模な情報処理システムにおいても、リソースの用途の変更を管理者が容易にかつ効率的に実行することが必要な運用管理システムに適している。
図１は、リソースの運用管理の概念を示す図である。 図２は、本実施例に係るリパーパシング処理の概念を説明する図である。 図３は、本実施例に係るリソース運用管理システムの機能構成を示す図である。 図４は、業務へのサーバの割当処理の処理手順を示すフローチャートである。 図５は、運用管理サーバの情報を登録するサイトデータの一例を示す図である。 図６は、ドメイン管理サーバの情報を登録するドメイン管理サーバデータの一例を示す図である。 図７は、管理対象となるサブネットの情報を登録する管理サブネットデータの一例を示す図である。 図８は、ミドルウェアと連携して各種処理を実行するためのコマンドを記憶したミドルウェア連携ＩＦデータの一例を示す図である。 図９は、サーバが属するドメインであるサーバドメインに係る情報を記憶したサーバドメインデータの一例を示す図である。 図１０は、プールグループに係る情報を記憶したプールグループデータの一例を示す図である。 図１１は、ストレージドメインに係る情報を記憶したストレージドメインデータの一例を示す図である。 図１２は、ネットワークドメインおよびネットワークサブドメインを説明する説明図である。 図１３は、ネットワークサブドメインに係る情報を記憶したネットワークサブドメインデータの一例を示す図である。 図１４は、ネットワークドメインに係る情報を記憶したネットワークドメインデータの一例を示す図である。 図１５は、負荷分散装置に係る情報を記憶した負荷分散装置データの一例を示す図である。 図１６は、ネットワークサブグループの構成例を説明する説明図である。 図１７は、ネットワークサブグループに係る情報を記憶したネットワークサブグループデータの一例を示す図である。 図１８は、サーバドメイン間の対応関係に係る情報を記憶したサーバドメイン間リンクデータの一例を示す図である。 図１９は、サーバドメインとストレージドメインとの間の対応関係に係る情報を記憶したサーバ／ストレージドメイン間リンクデータの一例を示す図である。 図２０は、ネットワークブートがなされるサーバの情報を記憶したネットワークブートサーバデータの一例を示す図である。 図２１は、管理対象となるサーバのデータを記憶した管理対象サーバデータの一例を示す図である。 図２２は、サーバが属するグループの情報を記憶したプロビジョニング構成データの一例を示す図である。 図２３は、結線状態が均一であるサーバとストレージ機器との結線の一例を示す図である。 図２４は、ＷＷＰＮに基づく結線の均一性チェック処理を説明する図である。 図２５は、ストレージテンプレートに係るデータを記憶したストレージテンプレートデータの一例を示す図である。 図２６は、サーバグループに係る情報を記憶したサーバグループデータの一例を示す図である。 図２７は、サーバグループに対応するストレージグループの情報を記憶したサーバ／ストレージグループリンクデータの一例を示す図である。 図２８は、サーバグループ間の対応関係に係る情報を記憶したサーバグループ間リンクデータの一例を示す図である。 図２９は、負荷分散装置のグループ情報を記憶した負荷分散グループデータの一例を示す図である。 図３０は、ネットワークグループに係る情報を記憶したネットワークグループデータの一例を示す図である。 図３１は、論理ボリュームをＲＡＩＤ装置に設定する設定処理の処理手順を示すフローチャートである。 図３２は、論理ボリュームの設定画面の一例を示す図である。 図３３は、ＲＡＩＤレベルの設定情報を記憶したＲＡＩＤレベル設定データの一例を示す図である。 図３４は、ＲＡＩＤ装置に係る情報を記憶したＲＡＩＤ装置データの一例を示す図である。 図３５は、ストレージサブグループが設定されたプロビジョニング構成データの一例を示す図である。 図３６は、サーバに論理ボリュームを認識させる論理ボリュームの設定処理の処理手順を示すフローチャートである。 図３７は、ＲＡＩＤ装置に構築された論理ボリュームの設定処理を説明する説明図である。 図３８は、アフィニティグループに係る情報を記憶したアフィニティグループデータの一例を示す図である。 図３９は、マルチパスの構成に係る情報を記憶したマルチパス構成データの一例を示す図である。 図４０は、ミラーボリュームの構成に係る情報を記憶したミラーボリューム構成データの一例を示す図である。 図４１は、サーバに割り当てられたＩＰアドレスに係る情報を記憶したＩＰアドレス管理データの一例を示す図である。 図４２は、ソフトウェアイメージに係る情報を記憶したソフトウェアイメージ管理データの一例を示す図である。 図４３は、ソフトウェア配布イメージに係る情報を記憶したソフトウェア配布イメージ管理データの一例を示す図である。 図４４は、スナップショットに係る情報を記憶したスナップショット管理データの一例を示す図である。 図４５は、サーバをサーバグループに追加する処理の処理手順を示すフローチャートである。 図４６は、ソフトウェア配布イメージの配布状況に係る情報を記憶した配布管理データの一例を示す図である。 図４７は、リパーパシング処理に係る事前設定処理の処理手順を説明するフローチャートである。 図４８は、リパーパシング処理の処理手順を示すフローチャートである。 図４９は、リパーパシングの設定に係る情報を記憶したリパーパシング設定データの一例を示す図である。 図５０は、サーバの状態に係る情報を記憶したリパーパシング運用データの一例を示す図である。 図５１は、リパーパシング処理を実行するスケジュールに係る情報を記憶したスケジュール設定データの一例を示す図である。 図５２は、各状態に１つ以上のサーバグループを設定したリパーパシング設定データの一例を示す図である。 図５３は、図３に示したサイト管理サーバとなるコンピュータのハードウェア構成を示す図である。 図５４は、図３に示したドメイン管理サーバとなるコンピュータのハードウェア構成を示す図である。 図５５は、図３に示したサーバとなるコンピュータのハードウェア構成を示す図である。
符号の説明
１，２ 業務
３ プール
４ Ｗｅｂドメイン
４1〜４9 Ｗｅｂサーバ
５ ＡＰドメイン
５1〜５6 ＡＰサーバ
６ ＤＢドメイン
６1〜６3 ＤＢサーバ
７ ストレージドメイン
７1〜７9 ストレージ
８ａ ＤＢサーバグループ
８ｂ バッチサーバグループ
８ｃ プールグループ
８ａ1，８ａ2，８ｂ1，８ｂ2，８ｃ1，８ｃ2 サーバ
９ ストレージ
９ａ1，９ａ2 ＤＢサーバブートディスク
９ｂ1，９ｂ2 バッチサーバブートディスク
１０ 運用管理クライアント
２０ サイト管理サーバ
２１ システムリソースマネージャ
２２ サーバＲＭ
２３ ソフトウェアＲＭ
２４ ネットワークＲＭ
２５ ストレージＲＭ
２６ システムリソースＤＢ
２７ ＡＰ管理統括部
３０，４０，９０，１２０ ＦＷ
５０，６０ ドメイン管理サーバ
５１ システムリソースドメインマネージャ
５２ サーバサブＲＭ
５３ ソフトウェアサブＲＭ
５４ ネットワークサブＲＭ
５５ ドメインリソースＤＢ
７０ インターネット
８０ ルータ
１００，１３０ ＳＬＢ
１１０ａ，１１０ｂ，１１０ｃ サーバ
１１１ａ リソースマネージャエージェント
１１２ａ サーバＲＭエージェント
１１３ａ ソフトウェアＲＭエージェント
１１４ａ ネットワークＲＭエージェント
１１５ａ ストレージＲＭエージェント
１１６ａ ＡＰ管理部
１４０ａ，１４０ｂ，１４０ｃ サーバ
１５０ａ，１５０ｂ，１５０ｃ サーバ
１６０ａ，１６０ｂ，１６０ｃ，１６０ｄ ストレージ
１７０ ＳＡＮ
１８０ エッジドメイン
１９０ Ｗｅｂドメイン
２００ ＡＰドメイン
２１０ ＤＢドメイン
３００ サイトデータ
３１０ ドメイン管理サーバデータ
３２０ 管理サブネットデータ
３３０ ミドルウェア連携ＩＦデータ
３４０ サーバドメインデータ
３５０ プールグループデータ
３６０ ストレージドメインデータ
３７０ Ｗｅｂドメイン
３８０ａ，３８０ｂ，３８０ｃ，３８０ｄ，３８０ｅ サーバ
３９０ ＡＰドメイン
４００ａ，４００ｂ，４００ｃ，４００ｄ，４００ｅ サーバ
４１０ Ｗｅｂ−ＡＰネットワークドメイン
４２０ Ｗｅｂ−Ｂａｃｋネットワークサブドメイン
４３０ａ，４３０ｂ スイッチ
４４０ ＡＰ−Ｆｒｏｎｔネットワークサブドメイン
４５０ａ，４５０ｂ スイッチ
４６０ａ，４６０ｂ ＳＬＢ
４７０ ネットワークサブドメインデータ
４８０ ネットワークドメインデータ
４９０ 負荷分散装置データ
５１０ Ｗｅｂドメイン
５２０ａ，５２０ｂ，５２０ｃ，５２０ｄ，５２０ｅ サーバ
５３０ A_Webサーバグループ
５４０ B_Webサーバグループ
５５０ ＡＰドメイン
５６０ａ，５６０ｂ，５６０ｃ，５６０ｄ，５６０ｅ サーバ
５７０ A_APサーバグループ
５８０ B_APサーバグループ
５９０，６１０ スイッチ
６００ａ，６００ｂ ＳＬＢ
６２０ A_Web_Backネットワークサブグループ
６３０ B_Web_Backネットワークサブグループ
６４０ A_AP_Frontネットワークサブグループ
６５０ B_AP_Frontネットワークサブグループ
６６０ ネットワークサブグループデータ
６７０ サーバドメイン間リンクデータ
６８０ サーバ／ストレージドメイン間リンクデータ
６９０ ネットワークブートサーバデータ
７００ 管理対象サーバデータ
７１０ プロビジョニング構成データ
７２０ サーバドメイン
７３０ａ，７３０ｂ サーバ
７４０ ストレージドメイン
７５０ａ，７５０ｂ ＦＣスイッチ
７６０ａ，７６０ｂ ＲＡＩＤ装置
７７０ａ，７７０ｂ ＲＡＩＤ装置ＷＷＰＮデータ
７８０ａ，７８０ｂ ＦＣスイッチＷＷＰＮデータ
７９０ａ，７９０ｂ サーバＷＷＰＮデータ
８００ ストレージテンプレートデータ
８１０ サーバグループデータ
８２０ サーバ／ストレージグループリンクデータ
８３０ サーバグループ間リンクデータ
８４０ 負荷分散グループデータ
８５０ ネットワークグループデータ
８６０ 必要条件出力画面
８７０ａ，８７０ｂ，８７０ｃ 必要条件
８８０ 論理ボリューム構成出力画面
８９０ ＲＡＩＤ装置
９００ａ，９００ｂ，９００ｃ 必要条件
９１０ａ，９１０ｂ，９１０ｃ，９１０ｄ 論理ボリューム
９２０ａ，９２０ｂ，９２０ｃ，９２０ｄ，９２０ｅ 論理ボリューム
９３０ａ，９３０ｂ ＲＡＩＤグループ
９４０ ＲＡＩＤレベル設定データ
９５０ ＲＡＩＤ装置データ
９６０ プロビジョニング構成データ
９７０ サーバグループ
９８０ ストレージプール
９９０ ストレージグループ
１０００ サーバ内ストレージ構成
１０１０ アフィニティグループデータ
１０２０ マルチパス構成データ
１０３０ ミラーボリューム構成データ
１０４０ ＩＰアドレス管理データ
１０５０ ソフトウェアイメージ管理データ
１０６０ ソフトウェア配布イメージ管理データ
１０７０ スナップショット管理データ
１０８０ 配布管理データ
１０９０ リパーパシング設定データ
１１００ リパーパシング運用データ
１１１０ スケジュール設定データ
１１２０ リパーパシング設定データ
１２００ コンピュータ
１２１０ 入力装置
１２２０ モニタ
１２３０ 媒体読取り装置
１２４０ ＲＯＭ
１２５０ ネットワークインターフェース
１２６０ ＨＤＤ
１２６０ａ システムリソースデータ
１２６０ｂ システムリソース管理プログラム
１２６０ｃ ＡＰ管理統括プログラム
１２７０ ＲＡＭ
１２７０ａ システムリソースデータ
１２８０ ＣＰＵ
１２８０ａ システムリソース管理プロセス
１２８０ｂ ＡＰ管理統括プロセス
１２９０ バス
１３００ コンピュータ
１３１０ 入力装置
１３２０ モニタ
１３３０ 媒体読取り装置
１３４０ ＲＯＭ
１３５０ ネットワークインターフェース
１３６０ ＨＤＤ
１３６０ａ ドメインリソースデータ
１３６０ｂ ドメインリソース管理プログラム
１３７０ ＲＡＭ
１３７０ａ ドメインリソースデータ
１３８０ ＣＰＵ
１３８０ａ ドメインリソース管理プロセス
１３９０ バス
１４００ コンピュータ
１４１０ 入力装置
１４２０ モニタ
１４３０ 媒体読取り装置
１４４０ ＲＡＭ
１４５０ ＲＯＭ
１４６０ ネットワークインターフェース
１４７０ ＨＤＤ
１４７０ａ エージェントリソース管理プログラム
１４７０ｂ ＡＰ管理プログラム
１４８０ ＣＰＵ
１４８０ａ エージェントリソース管理プロセス
１４８０ｂ ＡＰ管理プロセス
１４９０ バス

Claims (18)

  1. 情報処理システムを構成するリソースの運用を管理する運用管理プログラムであって、
    均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録するグループ登録手順と、
    前記グループ登録手順により登録されたリソースグループに属するリソースが利用するソフトウェアの切り替えを制御することによりリソースの用途を変更する用途変更手順と、
    をコンピュータに実行させることを特徴とする運用管理プログラム。
  2. 物理結線が均一なリソースの集まりとしてリソースドメインを登録するドメイン登録手順をさらにコンピュータに実行させ、前記グループ登録手順は、前記ドメイン登録手順により登録されたリソースドメインにおいて均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録することを特徴とする請求項１に記載の運用管理プログラム。
  3. 前記用途変更手順は、リソースグループに属するリソースにネットワークを介して接続された記憶装置に記憶されているソフトウェアに対するリソースからのアクセスを制御することによりリソースが利用するソフトウェアの切り替えを制御することを特徴とする請求項１に記載の運用管理プログラム。
  4. 前記用途変更手順は、あらかじめ定められたスケジュールに基づいて、リソースグループに属するリソースが利用するソフトウェアの切り替えを制御することを特徴とする請求項１に記載の運用管理プログラム。
  5. 前記用途変更手順は、複数のリソースグループに属する複数のリソースがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、１つのリソースグループに属する複数のリソースが利用するソフトウェアを別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のリソースの１つまたは複数の用途を別の用途に変更することを特徴とする請求項１に記載の運用管理プログラム。
  6. 前記用途変更手順は、ソフトウェアの切り替えをおこなうリソースの数に係るあらかじめ定められた情報に基づいて、複数のリソースグループに属する指定された数のリソースがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、１つのリソースグループに属するリソースが利用するソフトウェアを指定された数のリソースごとに別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のリソースの１つまたは複数の用途を別の用途に変更することを特徴とする請求項５に記載の運用管理プログラム。
  7. 情報処理システムを構成するリソースの運用を管理する運用管理方法であって、
    均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録するグループ登録工程と、
    前記グループ登録工程により登録されたリソースグループに属するリソースが利用する
    ソフトウェアの切り替えを制御することによりリソースの用途を変更する用途変更工程と、
    を含んだことを特徴とする運用管理方法。
  8. 物理結線が均一なリソースの集まりとしてリソースドメインを登録するドメイン登録工程をさらに含み、前記グループ登録工程は、前記ドメイン登録工程により登録されたリソースドメインにおいて均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録することを特徴とする請求項７に記載の運用管理方法。
  9. 前記用途変更工程は、リソースグループに属するリソースにネットワークを介して接続された記憶装置に記憶されているソフトウェアに対するリソースからのアクセスを制御することによりリソースが利用するソフトウェアの切り替えを制御することを特徴とする請求項７に記載の運用管理方法。
  10. 前記用途変更工程は、あらかじめ定められたスケジュールに基づいて、リソースグループに属するリソースが利用するソフトウェアの切り替えを制御することを特徴とする請求項７に記載の運用管理方法。
  11. 前記用途変更工程は、複数のリソースグループに属する複数のリソースがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、１つのリソースグループに属する複数のリソースが利用するソフトウェアを別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のリソースの１つまたは複数の用途を別の用途に変更することを特徴とする請求項７に記載の運用管理方法。
  12. 前記用途変更工程は、ソフトウェアの切り替えをおこなうリソースの数に係るあらかじめ定められた情報に基づいて、複数のリソースグループに属する指定された数のリソースがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、１つのリソースグループに属するリソースが利用するソフトウェアを指定された数のリソースごとに別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のリソースの１つまたは複数の用途を別の用途に変更することを特徴とする請求項１１に記載の運用管理方法。
  13. 情報処理システムを構成するリソースの運用を管理する運用管理装置であって、
    均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録するグループ登録手段と、
    前記グループ登録手段により登録されたリソースグループに属するリソースが利用するソフトウェアの切り替えを制御することによりリソースの用途を変更する用途変更手段と、
    を備えたことを特徴とする運用管理装置。
  14. 物理結線が均一なリソースの集まりとしてリソースドメインを登録するドメイン登録手段をさらに備え、前記グループ登録手段は、前記ドメイン登録手段により登録されたリソースドメインにおいて均一のソフトウェアを利用するリソースの集まりとしてリソースグループを登録することを特徴とする請求項１３に記載の運用管理装置。
  15. 前記用途変更手段は、リソースグループに属するリソースにネットワークを介して接続された記憶装置に記憶されているソフトウェアに対するリソースからのアクセスを制御することによりリソースが利用するソフトウェアの切り替えを制御することを特徴とする請求項１３に記載の運用管理装置。
  16. 前記用途変更手段は、あらかじめ定められたスケジュールに基づいて、リソースグループに属するリソースが利用するソフトウェアの切り替えを制御することを特徴とする請求項１３に記載の運用管理装置。
  17. 前記用途変更手段は、複数のリソースグループに属する複数のリソースがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、１つのリソースグループに属する複数のリソースが利用するソフトウェアを別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のリソースの１つまたは複数の用途を別の用途に変更することを特徴とする請求項１３に記載の運用管理装置。
  18. 前記用途変更手段は、ソフトウェアの切り替えをおこなうリソースの数に係るあらかじめ定められた情報に基づいて、複数のリソースグループに属する指定された数のリソースがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、１つのリソースグループに属するリソースが利用するソフトウェアを指定された数のリソースごとに別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のリソースの１つまたは複数の用途を別の用途に変更することを特徴とする請求項１７に記載の運用管理装置。
JP2006542128A 2004-10-18 2004-10-18 運用管理プログラム、運用管理方法および運用管理装置 Expired - Fee Related JP4734259B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2004/015384 WO2006043309A1 (ja) 2004-10-18 2004-10-18 運用管理プログラム、運用管理方法および運用管理装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2010255363A Division JP5182350B2 (ja) 2010-11-15 2010-11-15 運用管理プログラム、運用管理方法および運用管理装置

Publications (2)

Publication Number Publication Date
JPWO2006043309A1 true JPWO2006043309A1 (ja) 2008-05-22
JP4734259B2 JP4734259B2 (ja) 2011-07-27

Family

ID=36202734

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006542128A Expired - Fee Related JP4734259B2 (ja) 2004-10-18 2004-10-18 運用管理プログラム、運用管理方法および運用管理装置

Country Status (4)

Country Link
US (2) US8224941B2 (ja)
EP (1) EP1811376A4 (ja)
JP (1) JP4734259B2 (ja)
WO (1) WO2006043309A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10330596A1 (de) * 2003-07-07 2005-02-03 Siemens Ag Zuordnung von Stationsadressen zu Kommunikationsteilnehmern in einem Bussystem
DE602004027424D1 (de) 2004-10-18 2010-07-08 Fujitsu Ltd Operationsverwaltungsprogramm, operationsverwaltun
JP4734258B2 (ja) * 2004-10-18 2011-07-27 富士通株式会社 運用管理プログラム、運用管理方法および運用管理装置
KR100677145B1 (ko) * 2004-10-28 2007-02-02 삼성전자주식회사 네트워크 주소를 자동으로 설정하는 방법 및 장치
US7797288B2 (en) * 2004-12-27 2010-09-14 Brocade Communications Systems, Inc. Use of server instances and processing elements to define a server
US7873946B2 (en) * 2006-03-23 2011-01-18 Oracle America, Inc. Scalable vector graphics, tree and tab as drag and drop objects
US9922198B2 (en) * 2006-09-07 2018-03-20 Hewlett Packard Enterprise Development Lp Methods, apparatus and computer systems that enable hardware module use rights owned by one server to be claimed for use by another server in a common share group
US8005014B2 (en) * 2007-04-27 2011-08-23 Hewlett-Packard Development Company, L.P. Method of choosing nodes in a multi-network
JP5050118B1 (ja) * 2011-06-30 2012-10-17 株式会社東芝 情報処理装置、情報処理方法およびプログラム
US9917905B2 (en) * 2013-05-13 2018-03-13 International Business Machines Corporation Location-based domain name system service discovery
JP6273866B2 (ja) * 2014-01-29 2018-02-07 富士通株式会社 制御プログラム、制御装置および制御方法
US9928149B2 (en) 2014-08-29 2018-03-27 Cynny Space Srl Systems and methods to maintain data integrity and redundancy in a computing system having multiple computers
US10114664B1 (en) * 2015-09-21 2018-10-30 Veritas Technologies Llc Systems and methods for automated delivery and identification of virtual drives

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004508616A (ja) * 2000-06-20 2004-03-18 テラスプリング・インコーポレーテッド 拡張可能コンピューティングシステムの制御方法および装置
JP2004110791A (ja) * 2002-09-16 2004-04-08 Hewlett-Packard Development Co Lp ブレードアーキテクチャのための動的適応サーバプロビジョニング

Family Cites Families (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07107680B2 (ja) 1986-10-22 1995-11-15 株式会社日立製作所 並列プロセッサのプロセッサ間データ転送装置
JPH05160876A (ja) 1991-12-09 1993-06-25 Oki Electric Ind Co Ltd 通信制御プロセッサの管理方法
US5400325A (en) * 1993-06-29 1995-03-21 Synoptics Communications, Inc. Method and apparatus providing for hunt groups in an ATM network of the like
JPH07121395A (ja) 1993-10-27 1995-05-12 Nippon Telegr & Teleph Corp <Ntt> 予備装置優先選択方法
US5675723A (en) * 1995-05-19 1997-10-07 Compaq Computer Corporation Multi-server fault tolerance using in-band signalling
JPH0916521A (ja) 1995-06-30 1997-01-17 N T T Data Tsushin Kk 並列バッチ処理方式
JPH09297692A (ja) 1996-05-07 1997-11-18 Pfu Ltd 多重化システム
US5996086A (en) * 1997-10-14 1999-11-30 Lsi Logic Corporation Context-based failover architecture for redundant servers
US6163856A (en) * 1998-05-29 2000-12-19 Sun Microsystems, Inc. Method and apparatus for file system disaster recovery
DE69927223T2 (de) 1998-09-08 2006-07-13 Fujitsu Services Ltd. Ausfallsicherheit eines Mehrrechnersystems
US6453426B1 (en) * 1999-03-26 2002-09-17 Microsoft Corporation Separately storing core boot data and cluster configuration data in a server cluster
JP3252832B2 (ja) 1999-06-09 2002-02-04 日本電気株式会社 通信システムおよび方法
US6535998B1 (en) * 1999-07-26 2003-03-18 Microsoft Corporation System recovery by restoring hardware state on non-identical systems
US6597956B1 (en) 1999-08-23 2003-07-22 Terraspring, Inc. Method and apparatus for controlling an extensible computing system
WO2001080524A2 (en) * 2000-04-17 2001-10-25 Circadence Corporation Method and system for overcoming denial of service attacks
JP2002007174A (ja) 2000-06-27 2002-01-11 Hitachi Ltd 記憶装置のデータ管理システム
US7844513B2 (en) * 2000-07-17 2010-11-30 Galactic Computing Corporation Bvi/Bc Method and system for operating a commissioned e-commerce service prover
AU2001273047A1 (en) * 2000-07-17 2002-01-30 Galactic Computing Corporation Method and system for providing dynamic hosted service management
US6907395B1 (en) * 2000-10-24 2005-06-14 Microsoft Corporation System and method for designing a logical model of a distributed computer system and deploying physical resources according to the logical model
US7313614B2 (en) * 2000-11-02 2007-12-25 Sun Microsystems, Inc. Switching system
JP3693938B2 (ja) * 2000-11-07 2005-09-14 信佳 酒谷 情報配信システム、広告配信システム、情報配信プログラム、サーバ、情報配信サーバ、広告情報配信方法、およびセーバページ表示方法
US6901446B2 (en) * 2001-02-28 2005-05-31 Microsoft Corp. System and method for describing and automatically managing resources
JP4828709B2 (ja) * 2001-03-19 2011-11-30 株式会社東芝 自動ｏｓインストール方法及び計算機ネットワークシステム
US20030130832A1 (en) * 2002-01-04 2003-07-10 Peter Schulter Virtual networking system and method in a processing system
US6898705B2 (en) * 2001-05-31 2005-05-24 International Business Machines Corporation Automatic appliance server re-provision/re-purposing method
US6687733B2 (en) * 2001-06-01 2004-02-03 Intergenix Method and system for automatically configuring a client-server network
US8126959B2 (en) * 2001-06-28 2012-02-28 International Business Machines Corporation Method and system for dynamic redistribution of remote computer boot service in a network containing multiple boot servers
JP2003022190A (ja) 2001-07-09 2003-01-24 Hitachi Ltd 計算機システムのマルチブート方法、および、マルチブートプログラム
JP2003067351A (ja) * 2001-08-28 2003-03-07 Nec System Technologies Ltd 分散型コンピュータの構成制御システム
JP4199444B2 (ja) 2001-08-30 2008-12-17 日本電気株式会社 パーティション構成変更方式、パーティション構成変更方法およびパーティション構成変更用プログラム
US7093124B2 (en) * 2001-10-30 2006-08-15 Intel Corporation Mechanism to improve authentication for remote management of a computer system
US7213065B2 (en) * 2001-11-08 2007-05-01 Racemi, Inc. System and method for dynamic server allocation and provisioning
CA2363411A1 (en) * 2001-11-21 2003-05-21 Platespin Canada Inc. System and method for provisioning software
US20030126242A1 (en) * 2001-12-28 2003-07-03 Chang Albert H. Network boot system and method using remotely-stored, client-specific boot images created from shared, base snapshot image
JP2003271429A (ja) * 2002-03-15 2003-09-26 Hitachi Ltd 記憶装置資源管理方法、記憶資源管理プログラム、該プログラムを記録した記録媒体、及び記憶資源管理装置
GB0213073D0 (en) * 2002-06-07 2002-07-17 Hewlett Packard Co Method of maintaining availability of requested network resources
US7822810B2 (en) * 2002-09-17 2010-10-26 Hewlett-Packard Development Company, L.P. Method and system for peer to peer common channel collaboration
US7124322B1 (en) * 2002-09-24 2006-10-17 Novell, Inc. System and method for disaster recovery for a computer network
US20040068667A1 (en) * 2002-10-03 2004-04-08 International Business Machines Corporation Method and apparatus for securing and managing cluster computing in a network data processing system
US7870241B2 (en) * 2002-11-27 2011-01-11 International Business Machines Corporation Automated power control policies based on application-specific redundancy characteristics
JP3737810B2 (ja) * 2003-05-09 2006-01-25 株式会社東芝 計算機システム及び故障計算機代替制御プログラム
US7093120B2 (en) * 2003-05-29 2006-08-15 International Business Machines Corporation Method, apparatus, and program for performing boot, maintenance, or install operations on a storage area network
US7287186B2 (en) * 2003-06-02 2007-10-23 Surgient Inc. Shared nothing virtual cluster
US20050015471A1 (en) * 2003-07-18 2005-01-20 Zhang Pu Paul Secure cluster configuration data set transfer protocol
US7389411B2 (en) * 2003-08-29 2008-06-17 Sun Microsystems, Inc. Secure transfer of host identities
DE102004005128B3 (de) * 2004-02-02 2005-01-05 Fujitsu Siemens Computers Gmbh Anordnung mehrerer Rechner und Verfahren zum Betreiben einer Anordnung mehrerer Rechner bei einem Rechnerausfall
US7478275B1 (en) * 2004-03-29 2009-01-13 Symantec Operating Corporation Method and apparatus for performing backup storage of checkpoint data within a server cluster
US7930377B2 (en) * 2004-04-23 2011-04-19 Qlogic, Corporation Method and system for using boot servers in networks
US7325156B1 (en) * 2004-10-07 2008-01-29 Hewlett-Packard Development Company, L.P. Methods and apparatus for backing up data in a data center
WO2006040810A1 (ja) * 2004-10-12 2006-04-20 Fujitsu Limited ソフトウェア更新プログラム、ソフトウェア更新装置およびソフトウェア更新方法
WO2006040812A1 (ja) * 2004-10-12 2006-04-20 Fujitsu Limited 運用管理プログラム、運用管理方法および運用管理装置
JP4734258B2 (ja) * 2004-10-18 2011-07-27 富士通株式会社 運用管理プログラム、運用管理方法および運用管理装置
DE602004027424D1 (de) * 2004-10-18 2010-07-08 Fujitsu Ltd Operationsverwaltungsprogramm, operationsverwaltun
JP4462024B2 (ja) * 2004-12-09 2010-05-12 株式会社日立製作所 ディスク引き継ぎによるフェイルオーバ方法
US7797288B2 (en) * 2004-12-27 2010-09-14 Brocade Communications Systems, Inc. Use of server instances and processing elements to define a server
US7363514B1 (en) * 2005-02-01 2008-04-22 Sun Microsystems, Inc. Storage area network(SAN) booting method
JP4544146B2 (ja) * 2005-11-29 2010-09-15 株式会社日立製作所 障害回復方法
JP4923990B2 (ja) * 2006-12-04 2012-04-25 株式会社日立製作所 フェイルオーバ方法、およびその計算機システム。

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004508616A (ja) * 2000-06-20 2004-03-18 テラスプリング・インコーポレーテッド 拡張可能コンピューティングシステムの制御方法および装置
JP2004110791A (ja) * 2002-09-16 2004-04-08 Hewlett-Packard Development Co Lp ブレードアーキテクチャのための動的適応サーバプロビジョニング

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CSNG200401049005, 吉村裕、外４名, "Ｗｅｂアクセス集中に対応したサーバ自動割当制御", 電子情報通信学会論文誌, 20020901, 第Ｊ８５−Ｄ−Ｉ巻，第９号, ｐｐ．８６６−８７６, JP, 社団法人電子情報通信学会 *
JPN6008042538, 吉村裕、外４名, "Ｗｅｂアクセス集中に対応したサーバ自動割当制御", 電子情報通信学会論文誌, 20020901, 第Ｊ８５−Ｄ−Ｉ巻，第９号, ｐｐ．８６６−８７６, JP, 社団法人電子情報通信学会 *
JPN6010034523, Ａｋｉｒａ Ｔｓｕｎｅｙａ, "Ｎｅｗ Ｍａｎａｇｅｍｅｎｔ Ｔｅｃｈｎｏｌｏｇｉｅｓ ｆｏｒ Ｂｌａｄｅ Ｓｅｒｖｅｒｓ", ＦＵＪＩＴＳＵ ＳＣＩＥＮＴＩＦＩＣ ＆ ＴＥＣＨＮＩＣＡＬ ＪＯＵＲＮＡＬ, 200406, Ｖｏｌ．４０， Ｎｏ．１, ｐｐ．１４１−１５０, ＦＵＪＩＴＳＵ ＬＩＭＩＴＥＤ *

Also Published As

Publication number Publication date
EP1811376A1 (en) 2007-07-25
US20070233872A1 (en) 2007-10-04
EP1811376A4 (en) 2007-12-26
US8224941B2 (en) 2012-07-17
US20120233305A1 (en) 2012-09-13
WO2006043309A1 (ja) 2006-04-27
JP4734259B2 (ja) 2011-07-27

Similar Documents

Publication Publication Date Title
EP1806657B1 (en) Operation management program, operation management method, and operation management device
JPWO2007077600A1 (ja) 運用管理プログラム、運用管理方法および運用管理装置
JP4462024B2 (ja) ディスク引き継ぎによるフェイルオーバ方法
JP5976842B2 (ja) 計算機システム、及び、計算機システムの仮想サーバ移行制御方法
JP4414961B2 (ja) 管理サーバによる管理方法、管理サーバ、計算機システムおよび管理プログラム
US7203730B1 (en) Method and apparatus for identifying storage devices
US8706859B2 (en) Method and apparatus of data center file system
US8224941B2 (en) Method, apparatus, and computer product for managing operation
US8387013B2 (en) Method, apparatus, and computer product for managing operation
JP2009122963A (ja) デプロイ方法およびシステム
JP2006195703A (ja) ディスクレス計算機の運用管理システム
US20070237162A1 (en) Method, apparatus, and computer product for processing resource change
JP2010257274A (ja) 仮想化環境におけるストレージ管理システム及びストレージ管理方法
JP5182350B2 (ja) 運用管理プログラム、運用管理方法および運用管理装置
JP5267544B2 (ja) ディスク引き継ぎによるフェイルオーバ方法
JP4877368B2 (ja) ディスク引き継ぎによるフェイルオーバ方法
Guide VMware, Inc.
Free Visit PassLeader and Download Full Version 70-417 Exam Dumps
Beichter et al. IBM System z I/O discovery and autoconfiguration

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100622

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100823

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100914

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101115

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20101214

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110314

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20110322

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110419

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110425

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140428

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4734259

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees