JP2007047986A - ストレージシステムの構成管理装置及び構成管理方法 - Google Patents

Abstract

【課題】 ストレージシステムの構成変更を一元的に管理し、リソースを最適に配置させることができるようにする。
【解決手段】 サーバ１は仮想サーバ１Ａ，１Ｂに、スイッチ２はゾーン２Ａ，２Ｂに、ストレージ装置３は仮想ストレージ装置３Ａ，３Ｂに、それぞれ論理的に分割される。各論理的な装置は、それぞれの管理部１Ｃ，２Ｃ，３Ｃによって管理される。これら各管理部１Ｃ，２Ｃ，３Ｃは、管理用ネットワーク７を介して管理装置４に接続される。管理装置４は、ストレージシステム内の各リソース１Ｄ，２Ｄ，３Ｄの負荷状態に基づいて、アプリケーションプログラム単位で、リソースを再配置させる。
【選択図】 図１

Description

本発明は、ストレージシステムの構成管理装置及び構成管理方法に関する。

ストレージシステムは、ホストコンピュータに対して大容量かつ高性能のストレージサービスを提供可能である。ストレージシステムでは、例えば、多数のディスクドライブをアレイ状に配設し、RAID（Redundant Array of Independent Disks）に基づく記憶領域を構築している。各ディスクドライブが有する物理的な記憶領域上には、論理的な記憶領域である論理ボリュームが形成されている。論理ボリュームには、LUN（Logical Unit Number）が予め対応付けられている。ホストコンピュータは、LUNやブロックアドレス等を特定してライトコマンドやリードコマンドを発行する。これにより、ホストコンピュータは、ストレージシステムに対して所望のデータの読み書きを行うことができる。

ストレージシステムの使用状況は、時々刻々と変化するため、ストレージ装置の内部構成を動的に変更させる技術も提案されている（特許文献１）。
特開２００３−３３７７２１号公報

上述の文献に記載の技術では、予め設定されたスケジュールに基づいて、ストレージ装置内の構成を変化させる。しかし、前記文献記載の技術は、ストレージ装置の構成のみを変化させるもので、ストレージシステム全体の構成変更を行うものではない。また、前記文献に記載の技術は、論理的に分割された装置について考慮されていないため、ストレージシステムの論理的な構成を把握するのが難しく、さらに、論理的な構成の履歴を管理することができないため、使い勝手が低い。

そこで、本発明の目的は、論理的に分割された装置における資源配置を管理して、再配置させることができるストレージシステムの構成管理装置及び構成管理方法を提供することにある。本発明の他の目的は、論理的に分割された各装置の資源を、アプリケーションプログラム毎に再配置させることができ、履歴を管理することができるストレージシステムの構成管理装置及び構成管理方法を提供することにある。本発明の他の目的は、後述する実施形態の記載から明らかになるであろう。

上記課題を解決すべく、本発明の一つの側面に従うストレージシステムの構成管理装置は、上位装置と、この上位装置に記憶領域を提供するためのストレージ装置とを備えたストレージシステムの構成を管理する構成管理装置であって、上位装置を複数の論理的上位装置に分割し、これら各論理的上位装置に上位装置の有する資源のうち所定の資源をそれぞれ分配する第１管理部と、ストレージ装置を複数の論理的ストレージ装置に分割し、これら各論理的ストレージ装置にストレージ装置の有する資源のうち所定の資源をそれぞれ分配する第２管理部と、各論理的上位装置及び各論理的ストレージ装置に関する所定情報を、第１管理部及び第２管理部を介して、それぞれ取得する情報収集部と、収集された各所定情報に基づいて、各論理的上位装置上でそれぞれ実行される各アプリケーションプログラムにより使用される所定の資源に過不足が生じたか否かをそれぞれ判定し、過不足が発生していると判定された場合、各管理部のうち過不足に係る所定の資源を管理する管理部に構成変更要求を発行することにより、過不足が解消するように所定の資源を再配置させる配置管理部と、各所定情報の履歴をそれぞれ保存して管理する履歴管理部と、履歴管理部により管理される各所定情報の履歴を出力するユーザインターフェース部と、を備えている。

第１管理部は、上位装置を複数の論理的上位装置に分割し、各論理的上位装置に所定の資源をそれぞれ割り当てる。所定の資源としては、例えば、CPU等のデータ処理資源、メモリ等の記憶資源、通信インターフェース等の通信資源を挙げることができる。同様に、第２管理部は、ストレージ装置を複数の論理的ストレージ装置に分割し、各論理的ストレージ装置に所定の資源をそれぞれ割り当てる。従って、例えば、物理的な視点では、一つの上位装置と一つのストレージ装置のみからなる場合であっても、論理的な視点では、複数の論理的上位装置と複数の論理的ストレージ装置を備えたストレージシステムが構成される。そして、各論理的上位装置では、少なくとも一つのアプリケーションプログラムを実行させることができる。アプリケーションプログラムとしては、例えば、顧客管理プログラム、電子メール管理プログラム、売り上げ管理プログラム等の種々のものを例示することができる。

情報収集部は、各論理的装置（論理的に分割された各種装置を総称して「論理的装置」と呼ぶ）から所定情報をそれぞれ収集して管理する。所定情報としては、例えば、論理的装置の負荷状態、論理的装置に割り当てられている所定の資源の配置等を挙げることができる。配置管理部は、所定情報に基づいて、各アプリケーションプログラム毎に、所定の資源に過不足が生じているか否かを判定する。そして、配置管理部は、構成変更要求を発行することにより、各アプリケーションプログラム毎に所定の資源を再配置させる。また、各所定情報の履歴は、履歴管理部によって管理されており、この履歴はユーザインターフェース部から出力させることができる。出力方法としては、例えば、画面出力、印刷出力、音声出力等を挙げることができる。

一つの実施形態では、上位装置とストレージ装置とを接続するための中継装置を複数の論理的中継装置に分割し、これら各論理的中継装置に中継装置の有する資源のうち所定の資源をそれぞれ分配する第３管理部をさらに備えている。そして、情報収集部により収集される所定情報には、各論理的中継装置に関する所定情報も含まれる。中継装置としては、例えば、スイッチ、ルータ等を挙げることができる。これにより、配置管理部は、各アプリケーションプログラム毎に、論理的上位装置、論理的中継装置及び論理的ストレージ装置の資源配置をそれぞれ制御することができる。

一つの実施形態では、ユーザインターフェース部は、各論理的上位装置と各論理的ストレージ装置の論理的な接続構成を出力可能である。これに加えて、ユーザインターフェース部は、物理的な接続構成を出力することもできる。さらに、ユーザインターフェース部は、各アプリケーションプログラム毎の資源使用状況を出力することもできる。

一つの実施形態では、配置管理部は、一方のアプリケーションプログラムに関する所定の資源の配置を変更させた場合、一方のアプリケーションプログラムに対応する他方のアプリケーションプログラムに関する所定の資源を、一方のアプリケーションプログラムについての資源配置と同一構成となるように、再配置させる。例えば、高可用性（High Availability）のために、あるいは、負荷分散（Load Balancing）のために、同一種類のアプリケーションプログラムをクラスタリングして、それぞれ別々の論理的上位装置上で稼働させることがある。高可用性クラスタの場合、一方のアプリケーションプログラムがデータ処理サービスを提供し、他方のアプリケーションプログラムは、障害発生に備えて待機している。負荷分散クラスタの場合、データ処理サービスの要求を各アプリケーションプログラムがそれぞれ分担して処理することにより、応答性を高める。一方のアプリケーションプログラムについて所定の資源の再配置を行った場合、他方のアプリケーションプログラムについても同様の再配置を行う。

一つの実施形態では、配置管理部は、ストレージシステムの冗長度を考慮して、過不足を生じた所定の資源を再配置させる。例えば、配置管理部は、冗長度が向上するように、所定の資源を再配置させることができる。また、例えば、配置管理部は、冗長度が低下しないように、所定の資源を再配置させることができる。冗長度が低下する場合でも、ユーザが承認を与えた場合は、冗長度を低下させて資源の再配置を行うこともできる。このような冗長度に関連する所定資源としては、例えば、パスやポートのような通信資源を挙げることができる。

一つの実施形態では、未使用の所定の資源を管理するための資源プールを備え、配置管理部は、所定の資源のうち所定の下限値以下の利用率を有する所定の資源を資源プールに戻し、所定の資源のうち所定の上限値以上の利用率を有する所定の資源については、同種の資源を資源プールから選択して追加させる。所定の資源の種類毎にそれぞれの資源プールを用意することができ、未使用の資源をその種類毎にそれぞれ管理できる。これにより、配置管理部は、資源プールとの関係を考慮するだけで、所定の資源の配置を行うことができ、比較的簡単な構成で資源を管理することができる。

一つの実施形態では、履歴管理部は、予め設定された所定の期間単位で各所定情報の履歴を管理する。例えば、システム管理者等のユーザは、各アプリケーションプログラムの性質に応じて、所定の期間を設定可能である。履歴管理部は、所定の期間単位で、そのアプリケーションプログラムに関する所定情報を収集し、管理することができる。各アプリケーションプログラムは、そのデータ処理の性質（アプリケーションプログラムの種類等）に応じて、データ入出力（I/O）のピークが発生する周期がそれぞれ異なる。あるアプリケーションプログラムでは、例えば、一ヶ月周期でI/Oのピークが発生し、他のアプリケーションプログラムでは、例えば、３ヶ月周期でI/Oのピークが発生する。従って、I/Oのピークを検出できるように、I/Oピークの発生周期と所定情報の収集期間とを略一致させるか、または、I/Oピークの発生周期よりも長い期間だけ所定情報を収集することにより、所定情報の履歴を管理する。これにより、I/Oのピークを考慮して所定の資源を再配置することができる。

本発明の他の観点に従うストレージシステムの構成管理方法は、上位装置と、この上位装置に記憶領域を提供するためのストレージ装置とを備えたストレージシステムの構成を管理するための構成管理方法であって、上位装置を複数の論理的上位装置に分割し、これら各論理的上位装置に上位装置の有する資源のうち所定の資源をそれぞれ分配する第１管理部から、各論理的上位装置に関する所定情報をそれぞれ収集して管理するステップと、ストレージ装置を複数の論理的ストレージ装置に分割し、これら各論理的ストレージ装置にストレージ装置の有する資源のうち所定の資源をそれぞれ分配する第２管理部から、各論理的ストレージ装置に関する所定情報をそれぞれ収集して管理するステップと、再配置の実行が指示されたか否かを判定するステップと、再配置の実行が指示された場合、再配置の実行指示に関係するアプリケーションプログラムを特定するステップと、収集された各所定情報に基づいて、特定されたアプリケーションプログラムにより使用される所定の資源に過不足が発生したか否かを判定するステップと、過不足が発生していると判定された場合、各管理部のうち過不足に係る所定の資源を管理する管理部に構成変更要求を発行することにより、過不足が解消するように所定の資源を再配置させるステップと、各所定情報の履歴をそれぞれ保存して管理するステップと、各所定情報の履歴を出力するステップと、を含んでいる。

本発明の機能、手段、ステップの全部または一部は、所定のコンピュータプログラムをコンピュータに読み込ませて実行させることにより、実現できる場合がある。このコンピュータプログラムは、例えば、光ディスク、ハードディスク、半導体メモリのような記録媒体に固定して配布等することができる。また、このコンピュータプログラムは、例えば、インターネットのような通信ネットワークを介して配信することもできる。

以下、図面に基づき、本発明の実施の形態を説明する。本実施形態では、後述のように、複数の論理的な装置を接続して構成されたストレージシステムにおいて、各アプリケーションプログラム単位での資源の利用状況に基づいて、資源を再配置（再分配）するようになっている。また、本実施形態では、後述のように、ストレージシステムの物理的構成のみならず、ストレージシステムの論理的構成や、各アプリケーションプログラムから見た構成も解析して出力できるようになっている。

図１は、本発明の全体概念を示す説明図である。このストレージシステムは、複数のサーバ１と、複数のスイッチ２と、複数のストレージ装置３と、一つの管理装置４とを備えている。これら各サーバ１，スイッチ２及びストレージ装置３は、それぞれ物理的な実体である。各サーバ１と各スイッチ２とはネットワーク５を介して接続されており、各スイッチ２と各ストレージ装置３とは、他のネットワーク６を介して接続されている。また、各サーバ１，各スイッチ２及び各ストレージ装置３は、管理用ネットワーク７を介して、管理装置４にそれぞれ接続されている。ここで、ネットワーク５，６は、例えば、ファイバチャネルSAN（Storage Area Network）のように構成することができ、管理用ネットワーク７は、例えば、LAN（Local Area Network）やWAN（Wide Area Network）のように構成可能である。

各サーバ１は、複数の仮想サーバ１Ａ，１Ｂと、サーバ管理部１Ｃと、リソース１Ｄとをそれぞれ備えている。仮想サーバ１Ａ，１Ｂは、サーバ１内に構築された仮想的な存在である。仮想サーバ１Ａ，１Ｂは、サーバ１を論理的に分割することにより生成することができる。仮想サーバ１Ａ，１Ｂには、サーバ１の有するリソース１Ｄがそれぞれ分配されている。リソース１Ｄとしては、例えば、CPU資源、メモリ資源、通信インターフェース資源等を挙げることができる。各仮想サーバ１Ａ，１Ｂ上では、それぞれアプリケーションプログラムが稼働している（図３参照）。サーバ管理部１Ｃは、サーバ１内に生成される各仮想サーバ１Ａ，１Ｂの構成（リソースの配置や接続等）を管理し、また、各仮想サーバ１Ａ，１Ｂの状態（負荷状態等）を監視して、積極的にまたは消極的に管理装置４に報告する。

各スイッチ２は、複数のゾーン２Ａ，２Ｂと、スイッチ管理部２Ｃと、リソース２Ｄとを備えている。ゾーン２Ａ，２Ｂは、スイッチ２内に構築された仮想的な存在であり、仮想スイッチと呼ぶこともできる。各ゾーン２Ａ，２Ｂには、スイッチ２の有するリソース２Ｄをそれぞれ分配されている。このリソースとしては、ポート資源、メモリ資源、CPU資源等を挙げることができる。スイッチ管理部２Ｃは、各ゾーン２Ａ，２Ｂの構成を管理し、また、各ゾーン２Ａ，２Ｂの状態を監視して、積極的にまたは消極的に管理装置４に報告する。

同様に、各ストレージ装置３は、複数の仮想ストレージ装置３Ａ，３Ｂと、ストレージ管理部３Ｃと、リソース３Ｄとを備えている。仮想ストレージ装置３Ａ，３Ｂは、ストレージ装置３内に構築された仮想的な存在である。仮想ストレージ装置３Ａ，３Ｂは、ストレージ装置３を論理的に分割することにより生成されており、リソース３Ｄがそれぞれ分配されている。リソース３Ｄとしては、例えば、CPU資源、メモリ資源、ディスク資源、ポート資源等を挙げることができる。ストレージ管理部３Ｃは、各仮想ストレージ装置３Ａ，３Ｂの構成を管理する。また、ストレージ管理部３Ｃは、各仮想ストレージ装置３Ａ，３Ｂの状態を監視して、積極的にまたは消極的に管理装置４に報告する。

管理装置４は、例えば、情報収集部４Ａと、配置管理部４Ｂと、履歴管理部４Ｃと、出力部４Ｄと、入力部４Ｅと、管理データベース４Ｆと、履歴データベース４Ｇとを備えている。また、出力部４Ｄと入力部４Ｅとによって、ユーザインターフェース部４Ｈが構成されている。

情報収集部４Ａは、定期的にまたは不定期に、各サーバ管理部１Ｃ、各スイッチ管理部２Ｃ及び各ストレージ管理部３Ｃから、情報を収集する。収集する情報としては、例えば、負荷状態を示す情報、リソースの分配状況を示す情報、物理的または論理的な各要素の接続関係を示す情報等を挙げることができる。

配置管理部４Ｂは、自動的にまたは手動指示により、各管理部１Ｃ，２Ｃ，３Ｃにそれぞれリソースの再配置を要求することができる。どのリソースを削除するか（割当て解除するか）、どのリソースを追加するか（新規に割当てるか）等は、情報収集部４Ａによって収集された情報に基づいて、決定することができる。管理データベース４Ｆには、再配置のポリシや各種リソースの管理テーブル等が記憶されている。配置管理部４Ｂは、収集された情報と管理データベース４Ｆの記憶内容とに基づいて、リソースの再配置計画を立案し、その実行を各管理部１Ｃ，２Ｃ，３Ｃにそれぞれ指示することができる。

履歴管理部４Ｃは、収集された情報の履歴をその種類毎にそれぞれ管理する。履歴を管理する期間は、例えば、システム管理者等のユーザが任意に指定可能である。ユーザは、例えば、アプリケーションプログラムにI/Oのピークが発生する周期に合わせて、履歴を管理するように、予め設定することができる。各情報の履歴は、履歴データベース４Ｇにそれぞれ記憶される。

ユーザインターフェース部４Ｈは、ユーザからの入力操作を受け付け、また、ユーザへ情報を提供するものである。出力部４Ｄは、例えば、ディスプレイやプリンタ等の出力機器を介して、性能表示や構成表示を行う。性能表示部４Ｄ１は、各論理的装置（仮想サーバ１Ａ，１Ｂ、各ゾーン２Ａ，２Ｂ、各仮想ストレージ装置３Ａ，３Ｂ）の性能情報を出力するためのものである。性能情報とは、どの程度の性能が発揮されているかを示す情報であり、例えば、負荷状態を示す情報である。構成表示部４Ｄ２は、例えば、ストレージシステムの物理的構成及び論理的構成をそれぞれ出力するためのものである。入力部４Ｅは、ユーザからの入力操作を受け付けるものである。ユーザは、例えば、再配置のトリガとなる条件（閾値）を設定したり、再配置対象となるアプリケーションプログラムを指定することができる。

次に、ストレージシステムの全体動作を説明する。各仮想サーバ１Ａ，１Ｂ上で稼働するアプリケーションプログラムは、各スイッチ２の各ゾーン２Ａ，２Ｂのうち、使用が許可されたゾーンを介して、各ストレージ装置３の各仮想ストレージ装置３Ａ，３Ｂのうち、使用が許可された仮想ストレージ装置にアクセスする。

仮想サーバ１Ａ，１Ｂからリードコマンドが発行されると、仮想ストレージ装置３Ａ，３Ｂは、要求されたデータをキャッシュメモリまたはディスクドライブから読み出して、仮想サーバ１Ａ，１Ｂに送信する。仮想サーバ１Ａ，１Ｂからライトコマンドが発行されると、仮想ストレージ装置３Ａ，３Ｂは、ライトデータをキャッシュメモリまたはディスクドライブに記憶させる。

アプリケーションプログラムの稼働に応じて、ストレージシステム内では、データが送受信される。各論理的装置（１Ａ，１Ｂ，２Ａ，２Ｃ，３Ａ，３Ｂ）の負荷状態は、状況に応じて種々変化する。この負荷状態の変化は、各管理部１Ｃ，２Ｃ，３Ｃによってそれぞれ監視されており、管理装置４に報告される。

配置管理部４Ｂは、各管理部１Ｃ，２Ｃ，３Ｃからのアラートを受けた場合や、ユーザから手動で指示された場合に、リソースの再配置計画を立案し、この計画を実現させるための指示（再配置要求）を発行する。配置管理部４Ｂからの指示を受領した各管理部１Ｃ，２Ｃ，３Ｃは、それぞれの管理下にあるリソースを再分配する。これにより、論理的装置の構成が変化する。この構成変化及び負荷状態の変化は、履歴管理部４Ｃによってそれぞれ管理されている。従って、ユーザは、構成変化や負荷状態の変化の履歴を容易に確認することができる。

このように、本実施形態では、管理装置４によって、ストレージシステム全体のリソース分配を一元的に管理することができる。従って、ストレージシステムの構成が複雑である場合でも、システム全体として調和のとれたリソース配置が可能となる。

本実施形態では、アプリケーションプログラム毎に、各アプリケーションプログラムの利用するリソースを再配置することができる。従って、ストレージシステムの構成が複雑な場合でも、アプリケーションプログラムの性能を劣化させないように、リソースを最適配置することが可能となる。

本実施形態では、ストレージシステムの論理的構成をユーザインターフェース部に出力することができる。従って、ストレージシステムの物理的構成や論理的構成が複雑な場合でも、ユーザは、ストレージシステムの構成を比較的容易に把握することができ、使い勝手が向上する。

本実施形態では、ストレージシステムの論理的構成や負荷状態等の履歴を管理することができる。従って、ユーザは、比較的容易に、ストレージシステムの負荷状態の変化や構成の変化を確認することができ、使い勝手が向上する。

ユーザの使用するアプリケーションプログラムは種々雑多であり、I/Oのピークが発生する時期もそれぞれ相違する。また、ユーザが保有するデータ量は、年々増大する一方であり、ストレージシステムの性能を維持するために装置の増強等が行われる。このように、ストレージシステムの構成は、ユーザからの要求に応じて、動的に変化していき、その構成は複雑化していく。このような複雑な大規模ストレージシステムになればなるほど、その構成を明確に把握するのは難しくなる。物理的構成の場合は、結線図等から特定することもできるが、目に見えない論理的構成を把握するのは難しい。また、各アプリケーションプログラムの種類によって、より多くのリソースを必要する時期、少ないリソースで足りる時期はそれぞれ異なるが、複雑化したストレージシステム内において、各アプリケーションプログラムのリソース使用状況を適切に把握し、これに応じたリソース配置を行うのは難しい。

これに対し、本実施形態では、複雑化した大規模ストレージシステムであっても、各アプリケーションプログラムの性質に応じて、リソースを最適に再配置させることが可能であり、使い勝手が向上する。なお、本実施形態は、大規模ストレージシステムになるほど有用であるが、小規模ストレージシステムにも適用することができる。以下、本実施形態をより詳細に説明する。

図２は、ストレージシステムの全体構成を模式的に示す説明図である。このストレージシステムは、複数のサーバ１０と、複数のスイッチ２０と、複数のストレージ装置３０と、管理端末４０とを含んで構成することができる。各サーバ１０は、ネットワーク５０を介して、各スイッチ２０にそれぞれ接続されている。各スイッチ２０は、他のネットワーク６０を介して、各ストレージ装置３０にそれぞれ接続されている。管理端末４０は、管理用ネットワーク７０を介して、各サーバ１０，各スイッチ２０及び各ストレージ装置３０にそれぞれ接続されている。図１との対応関係を示すと、サーバ１０は図１中のサーバ１に、スイッチ２０は図１中のスイッチ２に、ストレージ装置３０は図１中のストレージ装置３に、管理端末４０は図１中の管理装置４に、ネットワーク５０は図１中のネットワーク５に、ネットワーク６０は図１中のネットワーク６に、管理用ネットワーク７０は図１中の管理用ネットワーク７に、それぞれ対応する。

各サーバ１０には、複数の論理分割サーバ１１がそれぞれ設けられている。これら各論理分割サーバ１１は、図１中の仮想サーバ１Ａ，１Ｂに対応するもので、サーバ１の有するリソースを分割することにより形成されている。

各スイッチ２０には、複数のゾーン２１がそれぞれ設けられている。各ゾーン２１は、図１中のゾーン２Ａ，２Ｂに対応するもので、スイッチ２０の有するリソースを分割することにより形成されている。

各ストレージ装置３０には、複数の論理分割ストレージ装置３１がそれぞれ設けられている。各論理分割ストレージ装置３１は、図１中の仮想ストレージ装置３Ａ，３Ｂに対応する。これら各論理分割ストレージ装置３１は、ストレージ装置３０の有するリソースを分割することにより形成されている。以下の説明では、論理的に分割された装置をLPRと称する場合がある。

図３は、ストレージシステムのリソース分配の様子を模式的に示す説明図である。最初にサーバ１０に着目すると、各論理分割サーバ１１上では、それぞれアプリケーションプログラム１０１が稼働している。アプリケーションプログラム１０１としては、例えば、顧客管理プログラム、売り上げ管理プログラム、電子メール管理プログラム、給与計算プログラム、口座管理プログラム等を挙げることができる。

サーバ１０は、複数種類のリソースＲ１１，Ｒ１２，Ｒ１３を備えている。データ処理リソースＲ１１は、例えば、CPU等のデータ処理回路のリソースである。メモリリソースＲ１２は、例えば、ROM（Read Only Memory）やRAM（Random Access Memory）等のメモリ回路やローカルディスク等のリソースである。通信ポートリソースＲ１３は、例えば、HBA（Host Bus Adapter）等の通信回路のリソースである。

これら各種のリソースＲ１１，Ｒ１２，Ｒ１３は、それぞれの少なくとも一部が、各論理分割サーバ１１に割り当てられている。各リソースＲ１１，Ｒ１２，Ｒ１３のうち、いずれの論理分割サーバ１１にも割り当てられていないものは、未使用リソースとしてプールされている。新たにリソースを追加する場合は、未使用リソースのプールの中からリソースが選択され、論理分割サーバ１１に割り当てられる。逆に、不要となったリソースは、論理分割サーバ１１への割当てが解除され、プールに戻される。

スイッチ２０に着目すると、スイッチ２０の通信パスリソースＲ２１は、各論理分割サーバ１１にそれぞれ割り当てられている。未使用のリソースＲ２１は、未使用リソースとしてプールされる。

ストレージ装置３０に着目すると、ストレージ装置３０のリソースＲ３１，Ｒ３２，Ｒ３３，Ｒ３４は、少なくともその一部が各論理分割ストレージ装置３１にそれぞれ割り当てられている。データ処理リソースＲ３１は、例えば、CPU等のデータ処理回路のリソースである。メモリリソースＲ３２は、例えば、キャッシュメモリや共有メモリ等のメモリ回路のリソースである。通信ポートリソースＲ３３は、例えば、通信ポート等の通信回路のリソースである。ディスクリソースＲ３４は、例えば、ハードディスクドライブや光ディスクドライブあるいは半導体メモリドライブ等のリソースである。

このように、各サーバ１０，各スイッチ２０及び各ストレージ装置３０の有する各リソースを分割することにより、一つの筐体内に複数の論理的な装置を構築できる。そして、各論理的な装置の結合によって、アプリケーションプログラム１０１の実行に必要なデータ入出力をそれぞれ個別に行うことができる。

図４は、ストレージシステムのハードウェア構成を説明するブロック図である。図３，図４では、サーバ１０，スイッチ２０及びストレージ装置３０をそれぞれ１つずつ示しているが、図２と共に説明したように、ストレージシステムは、複数のサーバ１０，複数のスイッチ２０及び複数のストレージ装置３０を含んで構成可能である。

サーバ１０は、例えば、プロセッサ１１０と、メモリ１２０と、キーボードスイッチ１３０と、ディスプレイ１４０と、ディスクインターフェース（図中、インターフェースを「I／F」と略記）１５０と、ローカルディスク１６０と、LANインターフェース１７０とを備えることができる。これらの各要素のうち、例えば、プロセッサ２１０，メモリ１２０，ディスクインターフェース１５０，ローカルディスク１６０を論理的に分割して使用することにより、論理分割サーバ１１を構成することができる。

スイッチ２０は、例えば、プロセッサ２１０と、メモリ２２０と、インターフェース２３０，２４０と、接続回路２５０と、LANインターフェース２６０とを備えることができる。これら各要素のうち、例えば、インターフェース２３０，２４０を分割するだけで各ゾーン２１を構築することができる。さらに、インターフェース２３０，２４０に加えて、プロセッサ２１０，メモリ２２０も論理的に分割することにより、仮想的なスイッチを構築することもできる。

ストレージ装置３０は、例えば、サービスプロセッサ（SVP）３１０と、チャネルアダプタ（CHA）３２０と、ディスクアダプタ（DKA）３３０と、キャッシュメモリ（CM）３４０と、共有メモリ（SM）３５０と、接続部３６０，３７０と、ディスクドライブ３８０と、LANインターフェース３９０とを備えて構成することができる。

SVP３１０は、ストレージ装置３０内の各種情報を収集し、収集した情報を管理端末４０に送信する。また、SVP３１０は、管理端末４０からの指示に基づいて、ストレージ装置３０内の構成を変化させる。

CHA３２０は、サーバ１０とのデータ通信を行う制御回路である。CHA３２０は、それぞれ複数のポート及びプロセッサを備えており、複数のサーバ１０とそれぞれ個別にデータ通信を行うことができる。DKA３３０は、各ディスクドライブ３８０とのデータ通信を行う制御回路である。DKA３３０は、論理ブロックアドレス（LBA）とディスクドライブ３８０の物理アドレスとの変換処理等を行う。CHA３２０とDKA３３０とは、それぞれ別々の専用制御基板として構成することもできるし、同一の基板上に混在させて多機能制御基板として構成することもできる。

キャッシュメモリ３４０は、例えば、複数の揮発性または不揮発性メモリ基板から構成されており、サーバ１０から受信したデータやディスクドライブ３８０から読出したデータ等を記憶する。共有メモリ３５０は、例えば、複数の不揮発性のメモリ基板から構成されており、ストレージ装置３０の構成情報や制御情報等を記憶する。キャッシュメモリ３４０と共有メモリ３５０とは、それぞれ別々のメモリ基板として構成することもできるし、同一の基板上に混在させることもできる。

接続部３６０は、CHA３２０，DKA３３０，キャッシュメモリ３４０，共有メモリ３５０を相互に接続させるもので、例えば、クロスバスイッチとして構成される。他の接続部３７０は、各ディスクドライブ３８０とDKA３３０とを相互に接続させるスイッチ回路である。

ディスクドライブ３８０は、例えば、ハードディスク、光ディスク、半導体メモリ、磁気テープ等の各種記憶デバイスから構成可能である。各ディスクドライブ３８０の有する物理的な記憶領域が複数個結合することにより、RAIDレベルに応じた論理的な記憶領域が構成される。

管理端末４０は、例えば、プロセッサ４１０と、メモリ４２０と、キーボードスイッチ４３０と、ディスプレイ４４０と、ローカルディスク４５０及びLANインターフェース４６０とを備えることができる。

図５は、ストレージシステムの動的な構成変更に関して、サーバ１０，スイッチ２０及びストレージ装置３０のソフトウェア構成を模式的に示す説明図である。サーバ１０は、例えば、性能管理モジュール１１１と、リソース管理モジュール１１２と、アプリケーション管理モジュール１１３と、接続管理モジュール１１４及び通信制御モジュール１１５を備えることができる。

性能管理モジュール１１１は、性能管理情報Ｄ１１を管理するモジュールである。リソース管理モジュール１１２は、リソース管理情報Ｄ１２を管理するモジュールである。アプリケーション管理モジュール１１３は、アプリケーション管理情報Ｄ１３を管理するモジュールである。接続管理モジュール１１４は、接続構成管理情報Ｄ１４を管理するモジュールである。これら各情報Ｄ１１〜Ｄ１４の内容については後述する。

スイッチ２０は、例えば、性能管理モジュール２１１と、リソース管理モジュール２１２及び接続管理モジュール２１３を備えることができる。性能管理モジュール２１１は性能管理情報Ｄ２１を管理する。リソース管理モジュール２１２は、リソース管理情報Ｄ２２を管理する。接続管理モジュール２１２は、接続構成管理情報Ｄ２３を管理する。

ストレージ装置３０は、例えば、性能管理モジュール３１１と、リソース管理モジュール３１２と、接続管理モジュール３１３とを備えることができる。性能管理モジュール３１１は、性能管理情報Ｄ３１を管理する。リソース管理モジュール３１２は、リソース管理情報Ｄ３２を管理する。接続管理モジュール３１３は、接続構成管理情報Ｄ３３を管理する。

図６は、管理端末４０のソフトウェア構成を示す説明図である。管理端末４０は、例えば、総合管理モジュール４１１と、性能管理モジュール４１２と、アプリケーション管理モジュール４１３と、リソース管理モジュール４１４と、接続管理モジュール４１５と、ユーザ入力モジュール４１６と、ユーザ出力モジュール４１７と、再配置指示モジュール４１８と、通信制御モジュール４１９とを備えることができる。

また、管理端末４０のデータベースＤ４０には、例えば、再配置定義テーブルＤ４１と、業務管理テーブルＤ４２と、性能情報設定値管理テーブルＤ４３と、性能情報履歴テーブルＤ４４と、リソース管理テーブルＤ４５と、アプリケーション管理テーブルＤ４６と、接続構成管理テーブルＤ４７とを設けることができる。

各モジュールの働きは後述するが、総合管理モジュール４１１は、ストレージシステムの構成管理の全体を制御する。性能管理モジュール４１２は、ストレージシステム内の性能管理情報を管理する。アプリケーション管理モジュール４１３は、サーバ１０上で稼働するアプリケーションプログラムの情報を管理する。リソース管理モジュール４１４は、ストレージシステム内の各リソースの割当て状況を管理する。接続管理モジュール４１５は、ストレージシステム内の物理的接続及び論理的接続を管理する。

ユーザ入力モジュール４１６及びユーザ出力モジュール４１７は、ユーザインターフェースを構成する。ユーザ入力モジュール４１６は、ユーザによりキーボードスイッチ４３０等を介して入力される情報を総合管理モジュール４１１に出力する。ユーザから入力される情報としては、例えば、各種設定値（閾値等）、履歴表示範囲、メニュー操作等を挙げることができる。

ユーザ出力モジュール４１７は、総合管理モジュール４１１から入力された情報を、ディスプレイ４４０等を介して出力させる。ディスプレイ４４０等に出力される情報としては、ストレージシステムの現在または過去の構成を示す情報、ストレージシステムの現在または過去の使用状況（負荷状態）を示す情報等を挙げることができる。

再配置指示モジュール４１８は、各サーバ１０，各スイッチ２０，各ストレージ装置３０のうち所定の装置に再配置要求を発行することにより、ストレージシステム内の資源を再配置させるものである。

通信制御モジュール４１９は、各サーバ１０の通信制御モジュール１１５，各スイッチ２０の通信制御モジュール２１４，各ストレージ装置３０の通信制御モジュール３１４との間で、情報の送受信を行うモジュールである。

図７は、サーバ１０で保持される性能管理情報Ｄ１１の構成を示す説明図である。性能管理情報Ｄ１１は、サーバ１０内の各種資源について、その性能に関する各種情報を管理するためのものである。性能管理情報Ｄ１１は、例えば、管理部位と、性能情報と、性能最大値と、上限閾値と、下限閾値と、監視周期とを対応づけることにより構成することができる。

「管理部位」とは、管理対象となる各リソースを特定するための識別情報である。管理部位は、再配置の対象となり得るリソースであることを意味する。管理部位は、例えば、「プロセッサ１」、「プロセッサ２」、「メモリ１」、「メモリ２」等のように、そのリソースの種別及び識別番号を含んで構成可能である。サーバ１０では、プロセッサ１１０，メモリ１２０，ディスクインターフェース１５０が管理対象の部位となっている。

「性能情報」とは、その管理部位の現在の性能値を示す情報であり、負荷状態（あるいは使用率）を示す。「性能最大値」とは、その管理部位の有する最大の性能値を示す情報である。性能情報が百分率で表記される場合、性能最大値の値は１００％となる。性能情報及び性能最大値は、百分率で表記してもよいし、または、MBやIOPS（Input Output Per Second）のように、絶対値で表記してもよい。

「上限閾値」とは、その管理部位の性能情報の値の上限値を示す。上限閾値は、ユーザが設定することができる。ユーザが設定しない場合、初期上限値が設定される。管理部位の性能情報が上限閾値に達した場合、その管理部位に新たなリソースの割当てが必要であることを示す。「下限閾値」とは、その管理部位の性能情報の下限値を示す。下限閾値は、ユーザが設定可能である。ユーザが設定しない場合、初期下限値が設定される。管理部位の性能情報が下限閾値に達した場合、その管理部位は効果的に利用されていないことを意味し、論理分割サーバ１１への割当てを解除可能であることを示す。

「監視周期」とは、その管理部位の性能情報を検出する周期を示す。監視周期は、ユーザが設定することができる。ユーザが設定しない場合、初期周期が設定される。

図８は、サーバ１０によって保持されるリソース管理情報Ｄ１２の構成を示す説明図である。このリソース管理情報Ｄ１２は、サーバ１０内の各リソースの割当て状況を管理するためのものである。リソース管理情報Ｄ１２は、例えば、管理部位と、割当て情報とを対応づけることにより構成可能である。「割当て情報」とは、その管理部位がどの論理分割サーバ１１に割り当てられているかを示す情報である。割当て情報には、論理分割サーバ１１を識別するための情報（図中の「LPR1」，「LPR2」）、または、いずれの論理分割サーバ１１にも割り当てられていないことを示す情報のいずれかが設定される。

図９は、サーバ１０で保持されるアプリケーション管理情報Ｄ１３の構成を示す説明図である。アプリケーション管理情報Ｄ１３は、サーバ１０上で実行される各アプリケーションプログラム１０１を管理するための情報である。アプリケーション管理情報Ｄ１３は、例えば、アプリケーション名と、割当て情報と、パス名と、クラスタ名とを対応づけることにより構成可能である。

「アプリケーション名」とは、アプリケーションプログラム１０１を識別するための情報であり、例えば、アプリケーションプログラムの種類及び識別番号を含んで構成することができる。「割当て情報」とは、そのアプリケーションプログラム１０１が割り当てられている論理分割サーバ１１を特定するための情報である。「パス名」とは、パス管理ソフトウェアにのみ設定される情報である。パス名には、そのパス管理ソフトウェアが管理するパスを特定するための情報が設定される。「クラスタ名」とは、クラスタを管理するためのクラスタソフトウェアにのみ設定される情報である。クラスタ名には、そのクラスタを識別するための情報が設定される。

図１０は、サーバ１０によって保持される接続構成管理情報Ｄ１４の構成を示す説明図である。接続構成管理情報Ｄ１４は、そのサーバ１０の物理的な接続構成を示す。接続構成管理情報Ｄ１４は、例えば、ディスクインターフェース名と、接続先とを対応づけることにより構成可能である。「ディスクインターフェース名」とは、ディスクインターフェース１５０を識別するための情報である。「接続先」とは、そのディスクインターフェース１５０が接続されるストレージ装置３０のポートを特定するための情報である。

図１１は、ストレージ装置３０によって保持される性能管理情報Ｄ３１の構成を示す説明図である。この性能管理情報Ｄ３１は、ストレージ装置３０の各種リソースの性能状態を管理するための情報である。性能管理情報Ｄ３１は、性能管理情報Ｄ１１と同様に、例えば、管理部位と、性能情報と、性能最大値と、上限閾値と、下限閾値と、監視周期とを対応づけることにより構成することができる。管理部位としては、例えば、プロセッサ、ホストインターフェース、共有メモリ３５０、キャッシュメモリ３４０、ディスク制御部（DKA）３３０、物理ディスク３８０を挙げることができる。プロセッサ及びホストインターフェースは、例えば、CHA３２０の有するリソースである。

図１２は、ストレージ装置３０によって保持されるリソース管理情報Ｄ３２の構成を示す説明図である。リソース管理情報Ｄ３２は、ストレージ装置３０内の各リソースがどの論理分割ストレージ装置３１に割り当てられているかを示す情報である。リソース管理情報Ｄ３２は、リソース管理情報Ｄ１２と同様に、管理部位と割当て情報とを対応づけることにより構成することができる。

ストレージ装置３０によって保持される接続構成管理情報Ｄ３３は、上述した接続構成管理情報Ｄ１４と同様に、ホストインターフェース名と接続先とを対応づけることにより構成可能である。従って、接続構成管理情報Ｄ３３の図示を省略する。

また、スイッチ２０によって保持される性能管理情報Ｄ２１、リソース管理情報Ｄ２２、接続構成管理情報Ｄ２３は、それぞれ上述した性能管理情報Ｄ１１、リソース管理情報Ｄ１２、接続構成管理情報Ｄ１４とほぼ同様に構成可能である。従って、これら各情報Ｄ２１〜Ｄ２３の図示を省略する。

図１３は、管理端末４０によって保持される再配置定義テーブルＤ４１の構成を示す説明図である。再配置定義テーブルＤ４１は、各アプリケーションプログラム毎にそれぞれ用意され、各アプリケーションプログラムが利用する各リソースの再配置条件を予め定義した情報である。

再配置定義テーブルＤ４１は、例えば、再配置ポリシＤ４１Ａと、カスタム定義Ｄ４１Ｂとを含んで構成可能である。再配置ポリシＤ４１Ａには、再配置ポリシテーブルＤ４１１に登録されている複数のポリシの中からいずれか一つのポリシを選択するための情報が設定される。再配置ポリシテーブルＤ４１１は、例えば、タイプ名と、各タイプ毎のポリシとが対応づけられている。

例えば、「タイプ１」では、自動再配置を行う旨が定義されている。「タイプ２」では、自動再配置を行わない旨が定義されている。「タイプ３」では、カスタム定義されたリソースについては自動再配置を行う旨が定義されている。「タイプ４」では、カスタム定義されたリソース以外のリソースについて自動再配置を行う旨が定義されている。自動再配置とは、リソースの性能情報が閾値に達した場合に、そのリソースに関係するアプリケーションプログラムが利用する各リソースを自動的に配置し直すことを意味する。カスタム定義とは、ユーザが、一つまたは複数のリソースについて再配置の順位を個別に指定することを意味する。

再配置定義テーブルＤ４１内のカスタム定義Ｄ４１Ｂでは、例えば、「サーバ１のLPR１に割り当てられている全プロセッサ」、「サーバ２の有する全リソース」等のように、ユーザが個別に定義した再配置条件が登録される。そして順位の高いカスタム定義が優先して実行される。

上述のように、再配置定義テーブルＤ４１は、例えば、勘定系プログラム用、人事系プログラム用、社内電子メール系プログラム用、社外電子メール系プログラム用等のように、各アプリケーションプログラム毎にそれぞれ用意することができる。

図１４は、管理端末４０によって保持される業務管理テーブルＤ４２の構成を示す説明図である。業務管理テーブルＤ４２は、ユーザによって定義された各業務の構成等を管理するためのものである。業務管理テーブルＤ４２は、例えば、業務名と、サーバ名と、LPR情報と、アプリケーション名と、業務周期とを対応づけることにより構成することができる。

「業務名」とは、そのアプリケーションプログラムに設定された名称である。例えば、売り上げ管理用のデータベースプログラムについて、ユーザは「勘定系処理」等のような名称を自由に設定することができる。また、電子メール管理プログラムの処理対象が社内の電子メールである場合、ユーザは、そのアプリケーションプログラムに「社内メール処理」等の名称を自由に設定することができる。

「サーバ名」とは、その業務、即ち、そのアプリケーションプログラムが実行されるサーバ１０を特定するための情報である。「LPR情報」とは、そのアプリケーションプログラムが実行される論理分割サーバ１１を特定するための情報である。「アプリケーション名」とは、アプリケーションプログラムを特定するための情報である。

「業務周期」とは、そのアプリケーションプログラムのI/Oピークの発生周期を示す情報である。各アプリケーションプログラムは、その性質に応じて、所定のI/Oパターンを示すことがある。例えば、勘定系処理の場合、入出金が集中的に行われる時期は、ほぼ定まっているため、その時期のI/O量は増大し、それ以外の時期のI/O量は低下する。また、メール処理では、例えば、電子メールのアーカイブを一週間毎に作成するとした場合、アーカイブを作成するタイミングでI/O量が増大する。このように、各アプリケーションプログラムは、その性質に応じてバッチ処理を実行するタイミング等がそれぞれ異なり、I/Oのピークを迎える周期が相違することがある。そこで、「業務周期」の欄では、各アプリケーションプログラムのI/Oピークが発生する周期をユーザが指定する。なお、既に述べた、あるいはこれから述べる他のユーザ入力項目でも同様であるが、履歴情報を解析することにより、自動的に設定値を算出する構成でもよい。また、自動的に算出された設定値を初期値として格納し、ユーザが自由に変更できるように構成してもよい。

図１４の下側にも示すように、業務管理テーブルＤ４２は、その作成年月日（時分秒も含めることができる）と関連付けられて、保存される。即ち、業務管理テーブルＤ４２の変更履歴は管理される。

図１５は、管理端末４０によって保持される性能情報設定値管理テーブル（以下、「設定値管理テーブル」とも呼ぶ）Ｄ４３の構成を示す説明図である。設定値管理テーブルＤ４３は、ストレージシステム内の各リソースについて、その性能に関する各設定値を管理するためのものである。設定値管理テーブルＤ４３は、例えば、各サーバ１０，各スイッチ２０及び各ストレージ装置３０毎にそれぞれ用意される。ある装置に関する設定値管理テーブルＤ４３は、例えば、管理部位と、性能閾値と、上限閾値と、下限閾値と、監視周期とを対応づけることにより構成可能である。

ここで、「性能閾値」とは、そのリソースを使用可能な上限を示す閾値である。これに対し、「上限閾値」は、そのリソースに関するアプリケーションプログラムが利用する各リソースの再配置を行わせるためのトリガである。

図１６は、管理端末４０によって保持される性能情報履歴管理テーブル（以下、「履歴管理テーブル」とも呼ぶ）Ｄ４４の構成を示す説明図である。履歴管理テーブルＤ４４は、各リソースの性能情報の推移を管理する。履歴管理テーブルＤ４４は、管理対象の各リソース毎にそれぞれ用意される。履歴管理テーブルＤ４４は、例えば、性能情報を取得した年月日に関する情報（時分秒も含めることができる）と、そのとき取得された性能情報とを対応づけることにより構成可能である。

図１７は、管理端末４０によって保持されるリソース管理テーブルＤ４５の構成を示す説明図である。このリソース管理テーブルＤ４５は、管理対象の各リソースがどの論理分割装置（LPR）に割り当てられているかを管理するためのものである。リソース管理テーブルＤ４５は、例えば、管理部位と、割当て情報（LPR情報）と、性能最大値とを対応づけることにより構成することができる。リソース管理テーブルＤ４５は、各サーバ１０，各スイッチ２０，各ストレージ装置３０毎にそれぞれ用意され、かつ、その履歴がそれぞれ管理される。

図１８は、管理端末４０によって保持されるアプリケーション管理テーブルＤ４６の構成を示す説明図である。アプリケーション管理テーブルＤ４６は、各アプリケーションプログラム１０１の構成を管理するためのものである。アプリケーション管理テーブルＤ４６は、各サーバ１０毎にそれぞれ用意され、かつ、その履歴が管理される。

図１９は、管理端末４０によって保持される接続構成管理テーブルＤ４７の構成を示す説明図である。接続構成管理テーブルＤ４７は、各サーバ１０，各スイッチ２０，各ストレージ装置３０毎にそれぞれ用意することができる。図１９では、サーバ１０に関するテーブルを示す。このテーブルＤ４７は、例えば、インターフェース名（ポート名）と、接続先とを対応づけることにより構成可能である。なお、図中では、接続先として、最終目的地であるストレージ装置のポート番号（ホストインターフェース番号）を記載しているが、これに代えて、どのスイッチ２０のどのポートを介して、どのストレージ装置３０に接続されているかを記録することもできる。

以上、主要なテーブルの構成を説明した。ここで、図５を再び参照する。管理対象機器であるサーバ１０，スイッチ２０，ストレージ装置３０がそれぞれ保持する性能管理情報Ｄ１１，Ｄ２１，Ｄ３１と、管理端末４０の保持する設定値管理テーブルＤ４３及び履歴テーブルＤ４４とは関連づけられている。各管理対象機器の保持するリソース管理情報Ｄ１２，Ｄ２２，Ｄ３２と、管理端末４０の保持するリソース管理テーブルＤ４５とは関連付けられている。各サーバ１０の保持するアプリケーション管理情報Ｄ１３と、管理端末４０の保持するアプリケーション管理テーブルＤ４６とは関連付けられている。各管理対象機器の保持する接続構成管理情報Ｄ１４，Ｄ２３，Ｄ３３と、管理端末４０の保持する接続構成管理テーブルＤ４７とは関連付けられている。

次に、管理端末４０のユーザインターフェースによって提供される各種入力画面及び出力画面の一例を説明する。

図２０は、アプリケーションプログラムと業務とを対応づけるための入力画面Ｇ１を示す説明図である。この入力画面には、複数のタブメニューＧ１１，Ｇ１２，Ｇ１３，Ｇ１４が表示される。第１のタブメニューＧ１１をユーザが選択すると、アプリケーションプログラム１０１と業務とをマッピングさせるための画面Ｇ１が表示される。

マッピング画面Ｇ１１には、例えば、管理対象の機器を選択するための選択欄Ｇ１１Ａと、論理的に分割された単位（LPR）を選択するための選択欄Ｇ１１Ｂと、アプリケーションプログラム毎にそれぞれ業務名（サービス名）を設定するための名称記入欄Ｇ１１Ｃとを含めることができる。ユーザは、選択欄Ｇ１１Ａ，Ｇ１１Ｂを介して、所望の論理分割サーバ１１（LPR）を選択する。これにより、選択された論理分割サーバ１１上で実行される各アプリケーションプログラムの名称が、名称記入欄Ｇ１１Ｃに表示される。ユーザは、各アプリケーションプログラム毎にそれぞれ自由な業務名称を設定する。ユーザが保存ボタンＢ１を操作すると、入力内容が業務管理テーブルＤ４２に登録される。ユーザが終了ボタンＢ２を操作すると、画面Ｇ１が閉じる。

図２１は、業務情報を入力するための画面Ｇ２を示す説明図である。ユーザがタブメニューＧ１２を選択すると、この画面Ｇ２が表示される。画面Ｇ２には、例えば、業務名を選択するための選択欄Ｇ１２Ａと、業務周期を設定するための設定欄Ｇ１２Ｂとを含めることができる。ユーザは、選択欄Ｇ１２Ａを介して、業務周期を設定するための業務名を選択する。そして、ユーザは、設定欄Ｇ１２Ｂを介して、その選択された業務名について業務周期を設定する。業務周期とは、上述の通り、その業務（アプリケーションプログラム）のI/Oピークの発生周期であり、換言すれば、性能情報を監視する期間を示す。ユーザが保存ボタンＢ１を操作すると、画面Ｇ２への入力内容が業務管理テーブルＤ４２に登録される。

図２２は、リソース管理情報を入力するための画面Ｇ３を示す説明図である。ユーザがタブメニューＧ１３を操作すると、この画面Ｇ３が表示される。画面Ｇ３には、例えば、管理対象機器を選択するための選択欄Ｇ１３Ａと、閾値等を設定するための設定欄Ｇ１３Ｂとを含めることができる。ユーザは、選択欄Ｇ１３Ａを介して、いずれか一つの管理対象機器を選択する。これにより、設定欄Ｇ１３Ｂには、その選択された機器の有するリソースが一覧表示される。ユーザは、表示された各リソースについて、どの論理分割サーバ１１に割り当てるのか（割当て情報）、性能閾値、上限閾値、下限閾値、監視周期をそれぞれ設定することができる。

図２３は、再配置の条件を定義するための画面Ｇ４を示す説明図である。ユーザがタブメニューＧ１４を操作すると、画面Ｇ４が管理端末４０に表示される。画面Ｇ４には、例えば、対象とする業務名を選択するための選択欄Ｇ１４Ａと、再配置ポリシを選択するための選択欄Ｇ１４Ｂと、カスタム定義を行うための設定欄Ｇ１４Ｃと、カスタム定義の具体的内容を表示する表示欄Ｇ１４Ｄと、保存ボタンＢ１と、終了ボタンＢ２と、選択したリソースの自動再配置を行わせるためのボタンＢ３と、全リソースの自動再配置を行わせるためのボタンＢ４と、追加ボタンＢ５及び削除ボタンＢ６を含めることができる。

ユーザは、選択欄Ｇ１４Ａを介して、対象とする業務名を選択することができる。ユーザは、選択欄Ｇ１４Ｂを介して、選択した業務に適用する再配置ポリシをいずれか一つ選択する。カスタム定義を行う場合、ユーザは、設定欄Ｇ１４Ｃを介して、各装置の各リソース毎に再配置の条件を個別に設定可能である。カスタム定義の条件を追加登録する場合、ユーザは、追加ボタンＢ５を操作する。登録済のカスタム定義条件を削除する場合、ユーザは、削除ボタンＢ６を操作する。保存ボタンＢ１をユーザが操作すると、画面Ｇ４に入力された内容は、再配置定義テーブルＤ４１に反映される。

ユーザは、ボタンＢ３を操作することにより、選択欄Ｇ１４Ａで選択された業務に関する全てのリソースを自動的に再配置させることができる。即ち、その選択された業務に対応づけられているアプリケーションプログラム１０１が利用する全てのリソースを、再配置対象リソースとして、自動的な再配置を実行させることができる。また、ユーザは、ボタンＢ４を操作することにより、ストレージシステム内の全リソースの自動的な再配置を実行させることもできる。

次に、ユーザに提供される出力画面について説明する。図２４は、ストレージシステムの物理的構成を表示させる画面Ｇ５を示す説明図である。この画面Ｇ５は、タブメニューＧ２１をユーザが操作すると表示される。画面Ｇ５には、例えば、日時を選択するための選択欄Ｇ２１Ａと、表示欄Ｇ２１Ｂとを含めることができる。ユーザは、選択欄Ｇ２１Ａを介して、所望の日時を選択することができる。表示欄Ｇ２１Ｂには、選択された日時におけるストレージシステムの物理的な構成が表示される。

図２５は、ストレージシステムの論理的構成を表示させるための画面Ｇ６を示す説明図である。画面Ｇ６は、ユーザがタブメニューＧ２２を操作することにより表示される。この画面Ｇ６には、例えば、日時を選択するための選択欄Ｇ２２Ａと、表示欄Ｇ２２Ｂとを含めることができる。ユーザは、選択欄Ｇ２２Ａを介して、所望の日時を選択することができる。これにより、選択された時点におけるストレージシステムの論理的構成が、表示欄Ｇ２２Ｂに表示される。論理的構成とは、論理的に分割された各単位（LPR）の接続関係等を意味する。

図２６は、ストレージシステムをアプリケーションプログラムの視点（業務視点）から見た場合の構成を表示させる画面Ｇ７を示す。この画面Ｇ７は、ユーザがタブメニューＧ２３を操作することにより表示される。画面Ｇ７には、例えば、日時を選択するための選択欄Ｇ２３Ａと、表示欄Ｇ２３Ｂとを含めることができる。表示欄Ｇ２３Ｂには、論理的分割単位を利用するアプリケーションプログラムの業務名が関連付けて表示される。従って、ユーザは、どのアプリケーションプログラムがどのLPRを利用しているかを簡単に把握することができる。

図２７は、性能情報の推移を表示するための画面Ｇ８を示す説明図である。この画面Ｇ８は、ユーザがタブメニューＧ２４を操作すると表示される。画面Ｇ８には、例えば、対象の業務名を選択するための選択欄Ｇ２４Ａと、開始日時を選択するための選択欄Ｇ２４Ｂと、終了日時を選択するための選択欄Ｇ２４Ｃとを含めることができる。また、画面Ｇ８の下側は表示欄となっており、ここに性能情報の時間的変化がグラフ表示される。

ユーザは、選択欄Ｇ２４Ａを介して、対象とする業務名を選択する。また、ユーザは、各選択欄Ｇ２４Ｂ，Ｇ２４Ｃを介して、性能情報の履歴を表示させる始期及び終期をそれぞれ選択する。これにより、画面Ｇ８には、選択された業務に関するリソースの性能情報の時間的変化がグラフ表示される。

図２７では、説明の便宜上、一つのリソースについて折線グラフを表示させているが、各リソースについてそれぞれ折線グラフを表示させることができる。この場合、各リソース毎にそれぞれ線種や表示色を変えることができる。また、各折線グラフの近傍に、対応するリソース名を表示させることができる。これに代えて、一つまたは複数のリソースを選択するための選択欄を設け、選択されたリソースに関する折線グラフだけを表示させるようにしてもよい。

グラフについて、さらに説明する。一つのリソースの性能情報の時間的変化は、実線グラフL1で示されている。このリソースの負荷が増大して上限閾値に到達すると、そのリソースに関する業務についてリソース配置が見直される。この結果、新たに同種のリソースが追加される。この追加されたリソースの性能情報の時間的変化は、点線グラフL2で示されている。新たなリソースの追加によって、元のリソースの負荷は減少する。そして、元のリソースの負荷が減少して下限閾値に到達すると、このリソースは削除されて、未使用プールに戻される。即ち、割当てを解除されたリソースのステータスは、「未使用」となる。この結果、残されたリソースの負荷は増大する（L2）。

図２８は、リソースの遷移を表示するための画面Ｇ９を示す説明図である。この画面Ｇ９は、ユーザがタブメニューＧ２５を操作すると表示される。画面Ｇ９には、例えば、対象の機器を選択するための選択欄Ｇ２５Ａと、履歴表示の始期を選択するための選択欄Ｇ２５Ｂと、履歴表示の終期を選択するための選択欄Ｇ２５Ｃとを含めることができる。また、画面Ｇ９の下側は表示欄となっており、ここにリソースの割当て状態の時間的変化が棒グラフ等で表示される。この画面Ｇ９では、対象の機器の各論理分割単位（LPR）に、どのリソースがどれだけ割り当てられてきたかの履歴が示される。説明の便宜上、図中では、一つの論理分割単位に関するリソース割当ての推移を示している。これに代えて、その機器に存在する全ての論理分割単位について、リソース割当ての推移を同時に表示させることもできるし、あるいは、選択された論理分割単位に関してのみ表示させることもできる。図中では、一つの論理分割単位について、そこに割り当てられている各リソースの種類毎に、それぞれ形状や表示色を変えた棒グラフが表示されている。

次に、ストレージシステムの構成を動的に変更させるための各処理について、それぞれ説明する。図２９は、管理端末４０が各管理対象機器から性能管理情報を取得して管理するための処理を示すフローチャートである。なお、以下の各フローチャートも同様であるが、各フローチャートは動作の概要を示しており、実際のプログラムとは相違する。

管理端末４０の性能管理モジュール４１２は、性能情報の問合せ時期が到来したか否かを判定し（Ｓ１０）、問合せ時期が到来した場合（S10:YES）、各管理対象機器に性能管理情報をそれぞれ問い合わせる（Ｓ１１）。管理対象機器の通信制御モジュールは、管理端末４０からの問合せ要求を受領すると（Ｓ１２）、所定のモジュールに、即ち、性能管理モジュールに対して問合せ要求を通知する（Ｓ１３）。性能管理モジュールは、問合せ要求を受領すると（Ｓ１４）、性能管理情報を読出し（Ｓ１５）、この読出した性能管理情報を通信制御モジュールに送信する（Ｓ１６）。

通信制御モジュールは、性能管理情報を受領すると（Ｓ１７）、この性能管理情報を管理端末４０に送信する（Ｓ１８）。管理端末４０は、性能管理情報を取得して記憶する（Ｓ１９）。以上の処理は、管理端末４０と各サーバ１０，各スイッチ２０及び各ストレージ装置３０との間で、それぞれ並列的に行うことができる。あるいは、各サーバ１０から性能管理情報を取得した後で、各スイッチ２０から性能管理情報を取得し、最後に各ストレージ装置３０から性能管理情報を取得するように、段階的に性能管理情報を取得する構成でもよい。

図３０は、管理端末４０が各管理対象機器からリソース管理情報をそれぞれ取得するための処理を示すフローチャートである。管理端末４０のリソース管理モジュール４１４は、各管理対象機器にリソース管理情報の送信をそれぞれ要求する（Ｓ２０）。管理対象機器の通信制御モジュールは、この問合せ要求を受領すると（Ｓ２１）、所定のモジュールに、即ち、リソース管理モジュールにリソース管理情報の送信を要求する（Ｓ２２）。リソース管理モジュールは、この要求を受領すると（Ｓ２３）、リソース管理情報を読み出して（Ｓ２４）、通信制御モジュールに送信する（Ｓ２５）。通信制御モジュールは、リソース管理情報を受け取ると（Ｓ２６）、管理端末４０に送信する（Ｓ２７）。管理端末４０は、各管理対象機器から送信されたリソース管理情報をそれぞれ受信して記憶する（Ｓ２８）。

図３１は、管理端末４０が各サーバ１０からアプリケーション管理情報をそれぞれ取得するための処理を示すフローチャートである。管理端末４０のアプリケーション管理モジュール４１３は、各サーバ１０にアプリケーション管理情報をそれぞれ問い合わせる（Ｓ３０）。サーバ１０の通信制御モジュール１１５は、管理端末４０からの要求を受領すると（Ｓ３１）、アプリケーション管理モジュール１１３にアプリケーション管理情報の送信を要求する（Ｓ３２）。アプリケーション管理モジュール１１３は、この要求を受領すると（Ｓ３３）、アプリケーション管理情報Ｄ１３を読み出して（Ｓ３４）、通信制御モジュール１１５に送信する（Ｓ３５）。通信制御モジュール１１５は、アプリケーション管理情報Ｄ１３を受領すると（Ｓ３６）、管理端末４０に送信する（Ｓ３７）。管理端末４０のアプリケーション管理モジュール４１３は、アプリケーション管理情報Ｄ１３を受信して記憶する（Ｓ３８）。

図３２は、管理端末４０が各管理対象機器から接続構成管理情報をそれぞれ取得するための処理を示すフローチャートである。管理端末４０の接続管理モジュール４１５は、各管理対象機器に接続構成情報をそれぞれ問い合わせる（Ｓ４０）。管理対象機器の通信制御モジュールは、この問合せ要求を受領すると（Ｓ４１）、接続管理モジュールに接続構成情報の送信を要求する（Ｓ４２）。接続管理モジュールは、この要求を受領すると（Ｓ４３）、接続構成管理情報を読み出して（Ｓ４４）、通信制御モジュールに送信する（Ｓ４５）。通信制御モジュールは、接続構成管理情報を受信すると（Ｓ４６）、管理端末４０に送信する（Ｓ４７）。管理端末４０は、各管理対象機器からそれぞれ接続構成情報を受信し、記憶する（Ｓ４８）。

図３３は、管理端末４０が管理対象機器に対して性能情報に関する閾値を変更させる処理を示すフローチャートである。管理端末４０は、管理対象機器に閾値の変更を要求する（Ｓ５０）。管理対象機器の通信制御モジュールは、閾値の変更要求を受領すると（Ｓ５１）、所定モジュールに、即ち、この場合は、性能管理モジュールに変更要求を通知する（Ｓ５２）。性能管理モジュールは、変更要求を受領すると（Ｓ５３）、性能管理情報に記憶されている閾値を変更し（Ｓ５４）、閾値の変更が完了した旨を通信制御モジュールに通知する（Ｓ５５）。通信制御モジュールは、変更完了通知を受領すると（Ｓ５６）、管理端末４０に報告する（Ｓ５７）。管理端末４０は、変更完了通知を受領して、閾値の変更が正常に完了した旨を確認する（Ｓ５８）。

図３４は、管理端末４０が管理対象機器に性能情報の監視周期を変更させる処理を示すフローチャートである。管理端末４０は、管理対象機器に監視周期の変更を要求する（Ｓ６０）。管理対象機器の通信制御モジュールは、監視周期の変更要求を受領すると（Ｓ６１）、所定のモジュールに、即ち性能管理モジュールに監視周期の変更を要求する（Ｓ６２）。性能管理モジュールは、この変更要求を受領すると（Ｓ６３）、性能管理情報に記憶されている監視周期を変更し（Ｓ６４）、変更が完了した旨を通信制御モジュールに通知する（Ｓ６５）。通信制御モジュールは、変更完了通知を受領すると（Ｓ６６）、これを管理端末４０に伝達する（Ｓ６７）。管理端末４０は、管理対象機器から変更完了通知を受領し、監視周期の変更が正常に完了したことを確認する（Ｓ６８）。

図３５は、管理端末が管理対象機器に管理部位の変更を要求するための処理を示すフローチャートである。管理端末４０は、管理部位の変更を要求する（Ｓ７０）。例えば、メモリを追加実装した場合やディスクドライブを取り外した場合等のように、管理対象機器の物理的構成が変化した場合、管理端末４０は、管理部位の変更を要求する。管理対象機器の通信制御モジュールは、変更要求を受領すると（Ｓ７１）、性能管理モジュールに管理部位の変更を要求する（Ｓ７２）。性能管理モジュールは、変更要求を受領すると（Ｓ７３）、性能管理情報に記憶されている管理部位を変更し（Ｓ７４）、変更が完了した旨を通信制御モジュールに通知する（Ｓ７５）。通信制御モジュールは、変更完了通知を受領すると（Ｓ７６）、管理端末４０に変更完了を通知する（Ｓ７７）。管理端末４０は、変更完了通知を受領し（Ｓ７８）、管理部位の変更が正常に完了したことを確認する（Ｓ７９）。

図３６は、管理端末４０が管理対象機器にリソース割当ての変更を要求する処理を示すフローチャートである。管理端末４０は、リソースの割当先を変更させる場合に、変更要求を発行する（Ｓ８０）。管理対象機器の通信制御モジュールは、この変更要求を受領すると（Ｓ８１）、所定のモジュールに、即ちリソース管理モジュールに、リソース割当ての変更を要求する（Ｓ８２）。リソース管理モジュールは、変更要求を受領すると（Ｓ８３）、リソース管理情報に記憶されている割当先の情報を変更し（Ｓ８４）、変更が完了した旨を通信制御モジュールに通知する（Ｓ８５）。通信制御モジュールは、変更完了通知を受領すると（Ｓ８６）、管理端末４０に変更完了を報告する（Ｓ８７）。管理端末４０は、変更完了通知を受領し（Ｓ８８）、リソースの割当てが正常に変更されたことを確認する（Ｓ８９）。

図３７は、管理端末４０が管理対象機器に接続構成の変更を要求する処理を示すフローチャートである。管理端末４０は、パスの構成を変化させる場合に、接続構成の変更を要求する（Ｓ９０）。管理対象機器の通信制御モジュールは、この変更要求を受領すると（Ｓ９１）、接続管理モジュールに接続構成の変更を要求する（Ｓ９２）。接続管理モジュールは、この変更要求を受領すると（Ｓ９３）、接続構成管理情報に記憶されている内容を書き換えて接続構成を変更し（Ｓ９４）、変更が完了した旨を通信制御モジュールに通知する（Ｓ９５）。通信制御モジュールは、変更完了通知を受領すると（Ｓ９６）、これを管理端末４０に通知する（Ｓ９７）。管理端末４０は、変更完了通知を受領し（Ｓ９８）、接続構成の変更が正常に完了したことを確認する。

図３８は、管理対象機器の有するリソースが閾値以上の過負荷（または閾値以下の低負荷）になった場合に、管理端末４０に警告する処理を示すフローチャートである。管理対象機器の性能管理モジュールは、管理対象の各リソースについて、性能情報の値（負荷状態）を監視している（Ｓ１００）。性能管理モジュールは、各リソースの性能情報の値が所定の上限閾値（または下限閾値）に達したか否かをそれぞれ判定し（Ｓ１０１）、閾値に達したリソースを発見した場合（S101:YES）、アラートを発行する（Ｓ１０２）。通信制御モジュールは、このアラートを受領すると（Ｓ１０３）、管理端末４０にアラートを送信する（Ｓ１０４）。管理端末４０は、管理対象機器からのアラートを受領し（Ｓ１０５）、後述する再配置処理を行う。

図３９〜図５８に基づいて、管理端末４０により実行される処理を説明する。図３９は、総合管理モジュール４１１が、管理端末４０内の性能管理モジュール４１２からストレージシステム内の各性能情報を取得する処理を示すフローチャートである。総合管理モジュール４１１は、性能情報の取得を要求するか否かを判定する（Ｓ１１０）。総合管理モジュール４１１は、定期的にまたは不定期に、性能情報を取得することができる。総合管理モジュール４１１は、性能情報の取得を決定すると（S110:YES）、性能管理モジュール４１２に性能情報の送信を要求する（Ｓ１１１）。性能管理モジュール４１２は、この要求を受領すると（Ｓ１１２）、性能情報履歴テーブルＤ４４を参照して（Ｓ１１３）、要求された性能情報を読み出し（Ｓ１１４）、この性能情報を総合管理モジュール４１１に送信する（Ｓ１１５）。総合管理モジュール４１１は、性能管理モジュール４１２から送信された性能情報を受領する（Ｓ１１６）。上述のように、性能管理モジュール４１２は、管理対象機器の各リソースに関する性能情報を定期的にまたは不定期に収集して管理するため、総合管理モジュール４１１は、性能管理モジュール４１２に問い合わせるだけで、ストレージシステム内の各リソースに関する性能情報を得ることができる。

図４０は、総合管理モジュール４１１が、性能管理モジュール４１２から設定値を取得する処理を示すフローチャートである。総合管理モジュール４１１は、設定値の取得を要求するか否かを判定する（Ｓ１２０）。設定値の取得を決定した場合（S120:YES）、総合管理モジュール４１１は、性能管理モジュール４１２に設定値の送信を要求する（Ｓ１２１）。性能管理モジュール４１２は、この要求を受領すると（Ｓ１２２）、設定値管理テーブルＤ４３を参照して（Ｓ１２３）、要求された設定値を読み出し（Ｓ１２４）、総合管理モジュール４１１に送信する（Ｓ１２５）。総合管理モジュール４１１は、性能情報に関する設定値を受領する（Ｓ１２６）。ストレージシステム内の各リソースに関する性能情報の設定値は、管理端末４０内の性能管理モジュール４１２によって管理されている。従って、総合管理モジュール４１１は、性能管理モジュール４１２に問い合わせるだけで、ストレージシステム内の各リソースの各設定値を取得可能である。

図４１は、総合管理モジュール４１１が、リソース管理モジュール４１４からストレージシステム内のリソース管理情報を取得する処理を示すフローチャートである。総合管理モジュール４１１は、リソース管理情報の取得を決定すると（S130:YES）、リソース管理モジュール４１４にリソース管理情報の送信を要求する（Ｓ１３１）。リソース管理モジュール４１４は、この要求を受領すると（Ｓ１３２）、リソース管理テーブルＤ４５を参照して（Ｓ１３３）、要求されたリソース管理情報を読出し（Ｓ１３４）、読出したリソース管理情報を総合管理モジュール４１１に送信する（Ｓ１３５）。総合管理モジュール４１１は、このリソース管理情報を受領する（Ｓ１３６）。なお、上述の処理及び後述の処理でも同様であるが、総合管理モジュール４１１は、ストレージシステム内の全リソースまたは所定の一部のリソースについて、情報の取得及び情報の変更を要求することができる。

図４２は、総合管理モジュール４１１が、リソース管理モジュール４１４に管理部位の変更を要求する処理を示すフローチャートである。総合管理モジュール４１１は、管理部位の変更を決定すると（S140:YES）、リソース管理モジュール４１４に管理部位の変更を要求する（Ｓ１４１）。リソース管理モジュール４１４は、この要求を受領すると（Ｓ１４２）、総合管理モジュール４１１の要求に基づいてリソース管理テーブルＤ４５の記憶内容を更新する（Ｓ１４３）。そして、リソース管理モジュール４１４は、変更された管理部位に係る管理対象機器のリソース管理モジュールに、管理部位の変更要求を発行する（Ｓ１４４）。リソース管理モジュール４１４は、管理対象機器のリソース管理モジュールが管理部位の変更を完了したことを確認すると（Ｓ１４５）、変更が完了した旨を総合管理モジュール４１１に通知する（Ｓ１４６）。総合管理モジュール４１１は、この通知を受領する（Ｓ１４７）。

図４３は、総合管理モジュール４１１が、接続管理モジュール４１５から接続構成管理情報を取得する処理を示すフローチャートである。総合管理モジュール４１１は、接続構成管理情報の取得を決定すると（S150:YES）、接続管理モジュール４１５に管理情報を要求する（Ｓ１５１）。接続管理モジュール４１５は、この要求を受領すると（Ｓ１５２）、接続構成管理テーブルＤ４７を参照し（Ｓ１５３）、この管理テーブルＤ４７の記憶内容が最新の内容であるか否かを各管理対象機器の接続管理モジュールにそれぞれ問い合わせる（Ｓ１５４）。この問合せには、その管理対象機器に関する現在の接続構成の内容（テーブルＤ４７の記憶内容の一部）が含まれている。

管理対象機器の接続管理モジュールは、管理端末４０からの問合せを受領すると（Ｓ１５５）、接続構成管理情報を参照し（Ｓ１５６）、管理端末４０に保持されている接続構成管理情報が最新の内容であるか否かを判定する（Ｓ１５７）。最新内容ではない場合（S157:NO）、管理対象機器の接続管理モジュールは、最新の接続構成管理情報を管理端末４０の接続管理モジュール４１５に送信する（Ｓ１５８）。管理端末４０に保持されている接続構成管理情報が最新の内容である場合（S157:YES）、管理対象機器の接続管理モジュールは、管理端末４０の接続管理モジュール４１５に対し、最新の内容である旨を通知する（Ｓ１５９）。

管理端末４０の接続管理モジュール４１５は、管理対象機器からの回答を受領すると（Ｓ１６０）、接続構成管理テーブルＤ４７の記憶内容が最新であるか否かを判定する（Ｓ１６１）。最新の内容ではなかった場合（S161:NO）、接続管理モジュール４１５は、この管理テーブルＤ４７の記憶内容を最新の内容に更新してから（Ｓ１６２）、管理テーブルＤ４７の記憶内容を総合管理モジュール４１１に送信する（Ｓ１６３）。もしも、接続構成管理テーブルＤ４７の記憶内容が最新である場合（S161:YES）、接続管理モジュール４１５は、管理テーブルＤ４７の記憶内容を総合管理モジュール４１１に送信する（Ｓ１６３）。総合管理モジュール４１１は、接続管理モジュール４１５から接続構成管理情報を受領する（Ｓ１６４）。

図４４は、総合管理モジュール４１１が、アプリケーション管理モジュール４１３からアプリケーション管理情報を取得する処理を示すフローチャートである。総合管理モジュール４１１は、アプリケーション管理情報の取得を決定すると（S170:YES）、アプリケーション管理モジュール４１３に対し、アプリケーション管理情報の送信を要求する（Ｓ１７１）。アプリケーション管理モジュール４１３は、この要求を受領すると（Ｓ１７２）、アプリケーション管理テーブルＤ４６を参照し（Ｓ１７３）、このテーブルＤ４６の記憶内容が最新であるか否かを、各サーバ１０のアプリケーション管理モジュール１１３に問い合わせる（Ｓ１７４）。

サーバ１０のアプリケーション管理モジュール１１３は、管理端末４０からの問合せを受領すると（Ｓ１７５）、アプリケーション管理情報Ｄ１３を参照し（Ｓ１７６）、管理端末４０で保持されているアプリケーション管理情報が最新の内容であるか否かを判定する（Ｓ１７７）。管理端末４０で保持されている内容が古い場合（S177:NO）、アプリケーション管理モジュール１１３は、最新のアプリケーション管理情報を管理端末４０のアプリケーション管理モジュール４１３に送信する（Ｓ１７８）。サーバ１０のアプリケーション管理モジュール１１３は、管理端末４０で保持されている内容が最新の場合（S177:YES）、その旨を通知する（Ｓ１７９）。

管理端末４０のアプリケーション管理モジュール４１３は、サーバ１０からの回答を受領すると（Ｓ１８０）、アプリケーション管理テーブルＤ４６の記憶内容が最新の内容であったか否かを判定する（Ｓ１８１）。最新内容でない場合（S181:NO）、アプリケーション管理モジュール４１３は、アプリケーション管理テーブルＤ４６の記憶内容を最新の内容に更新し（Ｓ１８２）、更新された管理テーブルＤ４６の記憶内容を総合管理モジュール４１１に送信する（Ｓ１８３）。逆に、管理テーブルＤ４６の記憶内容が最新内容である場合（S181:YES）、アプリケーション管理モジュールＤ４６を更新させることなく、現在の記憶内容を総合管理モジュール４１１に送信する（Ｓ１８４）。

図４５は、各管理対象機器から発行されたアラートによってリソースの再配置実行が指示される処理を示すフローチャートである。上述の通り、各管理対象機器の性能管理モジュールは、その管理下にある各リソースの負荷状態をそれぞれ監視し、所定の場合にアラートを発行する。このアラートは、その管理対象機器の通信制御モジュールによって受信される（Ｓ１９０）。管理対象機器の通信制御モジュールは、アラートを管理端末４０の再配置指示モジュール４１８に送信する（Ｓ１９１）。

再配置指示モジュール４１８は、管理対象機器から発行されたアラートを受領すると（Ｓ１９２）、総合管理モジュール４１１にリソースの再配置を要求する（Ｓ１９３）。総合管理モジュール４１１は、再配置要求を受領すると（Ｓ１９４）、後述の再配置処理を実行する（Ｓ１９５）。

次に、再配置処理の詳細を説明する前に、ユーザインターフェースに関する処理を先に説明する。ユーザインターフェースに関する画面の一例は、既に述べた通りである。図４６は、業務名とアプリケーションプログラムとを対応づけるための処理を示すフローチャートである。

総合管理モジュール４１１は、ユーザ入力モジュール４１６を介してユーザが行った操作に基づき、業務名とアプリケーションプログラムとをマッピングさせる画面Ｇ１を、ユーザ出力モジュール４１７に表示させる。ユーザは、管理対象機器を選択し（Ｓ２０１）、論理分割単位である論理分割サーバ１１を選択する（Ｓ２０２）。総合管理モジュール４１１は、アプリケーションプログラム管理テーブルＤ４６を参照し（Ｓ２０３）、アプリケーションプログラムの一覧を取得する（Ｓ２０４）。また、総合管理モジュール４１１は、業務管理テーブルＤ４２を参照する（Ｓ２０５）。

総合管理モジュール４１１は、画面Ｇ１に、アプリケーションプログラムの一覧を表示させると共に、既に設定されている業務名を表示させる（Ｓ２０６）。総合管理モジュール４１１は、ユーザによって業務名が入力されたか否かを監視する（Ｓ２０７）。ユーザにより業務名が入力されない場合（S207:NO）、総合管理モジュール４１１は、終了ボタンＢ２が操作されたか否かを判定する（Ｓ２０８）。ユーザによって業務名が入力されると（S207:YES）、総合管理モジュール４１１は、入力された業務名とアプリケーションプログラムとを関連付けて、業務管理テーブルＤ４２を更新させる（Ｓ２０９）。

図４７は、業務情報を入力するための処理を示すフローチャートである。総合管理モジュール４１１は、ユーザの操作に基づいて画面Ｇ２を表示させる（Ｓ２１０）。対象とする業務名をユーザが選択すると（Ｓ２１１）、総合管理モジュール４１１は、業務管理テーブルＤ４２を参照し（Ｓ２１２）、既に登録されている業務周期を読み出して、この値を画面Ｇ２に表示させる（Ｓ２１３）。総合管理モジュール４１１は、ユーザによって業務周期が入力されたか否か（Ｓ２１４）、及び、終了ボタンＢ２がユーザによって操作されたか否か（Ｓ２１５）を、それぞれ監視する。ユーザが業務周期を画面Ｇ２に入力すると（S214:YES）、総合管理モジュール４１１は、業務管理テーブルＤ４２を更新させる（Ｓ２１６）。

図４８は、リソース管理情報を入力する処理を示すフローチャートである。総合管理モジュール４１１は、ユーザの操作に基づいて、画面Ｇ３を表示させる（Ｓ２２０）。ユーザによって管理対象機器が選択されると（Ｓ２２１）、総合管理モジュール４１１は、リソース管理モジュール４１４を介して、選択された機器に関するリソース管理情報を取得し、これを画面Ｇ３に表示させる（Ｓ２２２）。また、総合管理モジュール４１１は、性能管理モジュール４１２を介して、選択された機器の各リソースについて性能情報設定値をそれぞれ取得し、これを画面Ｇ３に表示させる（Ｓ２２３）。

総合管理モジュール４１１は、ユーザによって設定値が入力されたか否か（Ｓ２２４）、及び、ユーザによって終了ボタンＢ２が操作されたか否か（Ｓ２２５）を、それぞれ監視する。ユーザによって設定値が入力されると（S224:YES）、総合管理モジュール４１１は、リソース管理モジュール４１４を介して、リソース管理テーブルＤ４５を更新させる（Ｓ２２６）。これにより、選択された管理対象機器に保持されているリソース管理情報も、リソース管理モジュール４１４からの指示に基づいて更新される（Ｓ２２７）。さらに、総合管理モジュール４１１は、性能管理モジュール４１２を介して、設定値管理テーブルＤ４３を更新させる（Ｓ２２８）。これにより、選択された管理対象機器に保持されている性能管理情報は、性能管理モジュール４１２からの指示に基づいて更新される（Ｓ２２９）。

図４９は、再配置条件を定義するための処理を示すフローチャートである。総合管理モジュール４１１は、ユーザの操作に基づいて、画面Ｇ４を表示させる（Ｓ２３０）。対象とする業務名がユーザによって選択されると（Ｓ２３１）、総合管理モジュール４１１は、その選択された業務に関連する定義内容を再配置定義テーブルＤ４１から読み出して、画面Ｇ４に表示させる（Ｓ２３２）。総合管理モジュール４１１は、ユーザによって再配置条件が入力されたか否か（Ｓ２３３）、及び、ユーザによって終了ボタンＢ２が操作されたか否か（Ｓ２３４）を、それぞれ監視する。ユーザが再配置の条件を入力すると（S233:YES）、再配置定義テーブルＤ４１を更新させる（Ｓ２３５）。

図５０は、ストレージシステムの物理的構成を表示させる処理を示すフローチャートである。総合管理モジュール４１１は、ユーザの操作に基づいて、画面Ｇ５を表示させる（Ｓ２４０）。表示対象の日時がユーザによって選択されると（Ｓ２４１）、総合管理モジュール４１１は、接続管理モジュール４１５を介して、接続構成管理テーブルＤ４７を参照する（Ｓ２４２）。総合管理モジュール４１１は、取得した接続構成に基づいて、物理的な接続状態を表示させる（Ｓ２４３）。この際、総合管理モジュール４１１は、サーバ１０からスイッチ２０へ、スイッチ２０からストレージ装置３０へと経路を順番に辿ることにより、ストレージシステムの物理的な構成を把握する。

また、総合管理モジュール４１１は、アプリケーション管理モジュール４１３を介して、アプリケーション管理テーブルＤ４６を参照し（Ｓ２４４）、物理的な装置とアプリケーションプログラムとを対応づけて、画面Ｇ５に表示させる（Ｓ２４５）。

図５１は、ストレージシステムの論理的な構成を表示させる処理を示すフローチャートである。総合管理モジュール４１１は、ユーザの操作に基づいて、画面Ｇ６を表示させる（Ｓ２５０）。表示対象の日時をユーザが選択すると（Ｓ２５１）、総合管理モジュール４１１は、リソース管理モジュール４１４を介して、リソース管理テーブルＤ４５を参照する（Ｓ２５２）。また、総合管理モジュール４１１は、接続管理モジュール４１５を介して、接続構成管理テーブルＤ４７を参照する（Ｓ２５３）。そして、総合管理モジュール４１１は、各論理的分割単位にそれぞれどのようなリソースがどれだけ割り当てられているか、各論理的分割単位がどのように接続されているかを解析し、ストレージシステムの論理的構成を表示させる（Ｓ２５４）。この際、総合管理モジュール４１１は、サーバ１０、スイッチ２０，ストレージ装置３０へと順番に経路を辿ることにより、ストレージシステムの論理的な構成を把握する。

図５２は、各業務の視点からストレージシステムを見た場合の構成を表示させる処理を示すフローチャートである。総合管理モジュール４１１は、ユーザの操作に基づいて、画面Ｇ７を表示させる（Ｓ２６０）。対象とする日時をユーザが選択すると（Ｓ２６１）、総合管理モジュール４１１は、業務管理テーブルＤ４２を参照し、各業務に係るアプリケーションプログラムが使用している装置名及びリソース名を検出する（Ｓ２６２）。

総合管理モジュール４１１は、リソース管理モジュール４１４を介して、リソース管理テーブルＤ４５を参照する（Ｓ２６３）。また、総合管理モジュール４１１は、接続管理モジュール４１５を介して、接続構成管理テーブルＤ４７を参照する（Ｓ２６４）。さらに、総合管理モジュール４１１は、アプリケーション管理モジュール４１３を介して、アプリケーション管理テーブルＤ４６を参照する（Ｓ２６５）。そして、総合管理モジュール４１１は、各業務毎に、リソースの割当て状態及び接続状態をそれぞれ解析し、各業務単位毎の論理的な構成を画面Ｇ７に表示させる（Ｓ２６６）。

図５３は、性能情報の推移を表示させる処理を示すフローチャートである。総合管理モジュール４１１は、ユーザの操作に基づいて、画面Ｇ８を表示させる（Ｓ２７０）。表示対象の期間をユーザが選択すると（Ｓ２７１）、総合管理モジュール４１１は、性能管理モジュール４１２を介して、性能情報履歴テーブルＤ４４を参照する（Ｓ２７２）。総合管理モジュール４１１は、選択された期間内の各性能情報の値をそれぞれ取得し、これを画面Ｇ８にグラフ表示させる（Ｓ２７３）。

図５４は、リソースの遷移を表示させる処理を示すフローチャートである。総合管理モジュール４１１は、ユーザの操作に基づいて、画面Ｇ９を表示させる（Ｓ２８０）。表示対象の期間をユーザが選択すると（Ｓ２８１）、総合管理モジュール４１１は、リソース管理モジュール４１４を介して、リソース管理テーブルＤ４５を参照し（Ｓ２８２）、選択された期間内の情報をそれぞれ取得する。そして、総合管理モジュール４１１は、選択された期間におけるリソース割当て状況の変化を、グラフ化して画面Ｇ９に表示させる（Ｓ２８３）。

次に、総合管理モジュール４１１によるリソース再配置方法を説明する。図５５は、リソース再配置処理の全体概要を示すフローチャートである。再配置の実行指示は、自動的にまたは手動操作で、行うことができる。

総合管理モジュール４１１は、再配置処理の呼出元がどこからされたかを判定する（Ｓ２９０）。管理対象機器からのアラートに基づいて再配置処理の開始が要求された場合、総合管理モジュール４１１は、アラート発行元の管理対象機器にアクセスし（Ｓ２９１）、このアラートに関わるサーバ１０及びLPR（論理分割サーバ１１）をそれぞれ特定する（Ｓ２９２）。総合管理モジュール４１１は、アラート発行に係る論理分割サーバ１１上で実行されるアプリケーションプログラムを特定し（Ｓ２９３）、業務単位の再配置処理を実行する（Ｓ２９４）。この処理については、さらに後述する。そして、総合管理モジュール４１１は、再配置対象となる全ての業務について、リソースの再配置を終了したか否かを判定し（Ｓ２９５）、アラート発行に関連する論理分割サーバ１１で稼働する全てのアプリケーションプログラムについてリソースを再配置するまで、Ｓ２９４を繰り返し実行する。

ユーザの指示によって再配置処理を開始する場合は、さらに、二通りに分けることができる。その一つは、ユーザが指定した特定の一つまたは複数の業務（アプリケーションプログラム）についてのみ、リソースを再配置させる場合である。他の一つは、ユーザによって全業務のリソース再配置が指示された場合である。このように、個別業務モードと全業務モードとのいずれかを、ユーザは選択可能である。

ユーザが特定の業務を指定する場合、その指定された業務についてリソースの再配置処理が行われる（Ｓ２９６）。これに対し、全業務についてリソースの再配置が指示された場合、総合管理モジュール４１１は、業務管理テーブルＤ４２を参照し（Ｓ２９７）、そこに登録されている全ての業務をそれぞれ検出する（Ｓ２９８）。そして、総合管理モジュール４１１は、ストレージシステム内の全業務について、それぞれのリソースを再配置させる（Ｓ２９９，Ｓ３００）。

図５６は、業務単位でリソースを再配置させる処理を示すフローチャートである。総合管理モジュール４１１は、業務管理テーブルＤ４２を参照し（Ｓ３１０）、その業務が使用している装置名及びLPRをそれぞれ特定する（Ｓ３１１）。総合管理モジュール４１１は、リソース管理テーブルＤ４５（Ｓ３１２）と、接続構成管理テーブルＤ４７（Ｓ３１３）と、アプリケーション管理テーブルＤ４６（Ｓ３１４）とをそれぞれ参照し、その業務に関係する全てのリソースを検出する（Ｓ３１５）。

また、総合管理モジュール４１１は、その業務が実行されるLPRに接続された他のLPRに関する情報を検出し（Ｓ３１６）、これにより、その業務に関するクラスタ構成を検出する（Ｓ３１７）。つまり、総合管理モジュール４１１は、リソースが再配置される業務に関連する他の業務の存在を予め検出する。クラスタ構成を意識したリソースの再配置については、さらに後述する。

そして、総合管理モジュール４１１は、再配置対象となる全リソースを決定して、再配置対象のリソースリストを作成し（Ｓ３１８）、再配置実施処理を行う（Ｓ３１９）。この処理については後述する。

図５７は、再配置実施処理を示すフローチャートである。まず最初に、総合管理モジュール４１１は、再配置対象のリソースリストに基づいて、作業管理テーブルＤ５０を作成する（Ｓ３２０）。作業管理テーブルＤ５０の一例を図５９に示す。作業管理テーブルＤ５０は、例えば、リソースの所属先装置名と、リソース名と、そのリソースのタイプと、再配置ステータスとを対応づけることにより構成することができる。再配置のステータスとしては、例えば、「再配置完了」と「未実施」とを挙げることができる。「再配置完了」ステータスは、そのリソースの再配置が完了したことを示す。「未実施」ステータスは、そのリソースの再配置が行われていないことを示す。なお、これ以外のステータスを採用することもできる。

図５７に戻る。総合管理モジュール４１１は、作業管理テーブルＤ５０を参照し、「未実施」ステータスを有するレコードを検出する（Ｓ３２１）。「未実施」のステータスを有するレコードが一つも発見できない場合（S322:NO）、総合管理モジュール４１１は、本処理を終了する。

「未実施」ステータスを有するレコードが検出された場合（S322:YES）、総合管理モジュール４１１は、そのレコードに登録されているリソースのタイプを判別し（Ｓ３２３）、そのリソースと同一の機器内に存在する同一タイプのリソースを、再配置対象のリソースとして選択する（Ｓ３２４）。即ち、ある一つのプロセッサが作業管理テーブルＤ５０に登録されており、そのステータスが「未実施」である場合、そのプロセッサと同一の機器内に存在する他の全てのプロセッサも、再配置の対象として選択される。

総合管理モジュール４１１は、業務管理テーブルＤ４２を参照し、リソース再配置に係る業務に設定された業務周期を取得する（Ｓ３２５）。総合管理モジュール４１１は、設定値管理テーブルＤ４３を参照し、再配置対象としてＳ３２４で選択された各リソースの設定値をそれぞれ取得する（Ｓ３２６）。そして、総合管理モジュール４１１は、性能情報履歴テーブルＤ４４を参照し、各リソースの性能情報の変化を業務周期の分だけそれぞれ取得する（Ｓ３２７）。

総合管理モジュール４１１は、業務周期内における各リソースの性能情報の変化に基づいて、所定の過負荷となっているリソースが存在するか否か（Ｓ３２８）、及び、所定の低負荷となっているリソースが存在するか否か（Ｓ３２９）をそれぞれ判定する。過負荷のリソースとは、その性能情報の値が上限閾値以上となったリソースである。低負荷のリソースとは、その性能情報の値が下限閾値以下となったリソースである。

過負荷のリソースまたは低負荷のリソースが発見された場合（S328:YES，S329:YES）、総合管理モジュール４１１は、再配置定義テーブルＤ４１を参照し（Ｓ３３０）、そのリソースを再配置可能であるか否かを判定する（Ｓ３３１）。既に述べた通り、ユーザは、特定のリソースまたはリソース群について、再配置の許可または禁止を事前に設定しておくことができるためである。

その過負荷リソースまたは低負荷のリソースについて再配置が禁止されている場合（S331:NO）、総合管理モジュール４１１は、Ｓ３２１に戻り、「未実施」ステータスを有する次のレコードを検出する。これに対し、過負荷リソースまたは低負荷リソースについて再配置が許可されている場合（S331:YES）、結合子１を介して、図５８に示すフローチャートに移動する。

図５８は、図５７に続くフローチャートである。総合管理モジュール４１１は、そのリソースがインターフェースであるか否かを判定する（Ｓ３３２）。インターフェース以外のリソースである場合、総合管理モジュール４１１は、リソースを追加するか否かを判定する（Ｓ３３３）。過負荷のリソースに同種のリソースを追加する場合、総合管理モジュール４１１は、そのリソースのプールの中から、まだどこにも割り当てられていない未使用のリソースを検索して、その未使用リソースを新たに割り当てる（Ｓ３３４）。逆に、低負荷のリソースの割当てを削除する場合、総合管理モジュール４１１は、その低負荷リソースの割当てを解除して、プールに戻す（Ｓ３３５）。プールに戻されたリソースのステータスは、「未使用」となる。

総合管理モジュール４１１は、リソース管理モジュール４１４を介して、管理対象機器のリソース管理モジュールに対し、リソースの割当て変更（追加または削除）を要求する（Ｓ３３６）。また、総合管理モジュール４１１は、性能管理モジュール４１２を介して、管理対象機器の性能管理モジュールに対し、管理部位の変更（追加または削除）を要求する（Ｓ３３７）。そして、総合管理モジュール４１１は、作業管理テーブルＤ５０にアクセスし、再配置の完了したレコードのステータスを「未実施」から「再配置完了」に変更させる（Ｓ３３８）。

一方、再配置対象のリソースがインターフェースである場合、即ち、パスの構成を変化させる場合、総合管理モジュール４１１は、接続管理モジュール４１５を介して、接続構成管理テーブルＤ４７を参照する（Ｓ３３９）。総合管理モジュール４１１は、インターフェースを追加するか削除するかを判断する（Ｓ３４１）。インターフェースを追加する場合、総合管理モジュール４１１は、インターフェースのプールの中から、未使用かつ接続可能なインターフェースを選択し、これを新たに割り当てる（Ｓ３４１）。インターフェースの割当てを削除する場合、総合管理モジュール４１１は、そのインターフェースの割当てを解除してプールに戻す。プールに戻されたインターフェースのステータスは、「未使用」となる。

このように、本実施例によれば、管理端末４０によって、ストレージシステム全体のリソース分配を一元的に管理することができる。従って、ストレージシステムの構成が複雑である場合でも、システム全体として調和のとれたリソース配置が可能となる。

本実施例では、アプリケーションプログラム毎に、各アプリケーションプログラムの利用するリソースを再配置することができる。従って、ストレージシステムの構成が複雑な場合でも、アプリケーションプログラムの性能を劣化させないように、リソースを最適配置することが可能となる。

本実施例では、ストレージシステムの論理的構成をユーザインターフェース部に出力することができる。従って、ストレージシステムの物理的構成や論理的構成が複雑な場合でも、ユーザは、ストレージシステムの構成を比較的容易に把握することができ、使い勝手が向上する。

本実施例では、ストレージシステムの論理的構成や負荷状態等の履歴を管理することができる。従って、ユーザは、比較的容易に、ストレージシステムの負荷状態の変化や構成の変化を確認することができ、使い勝手が向上する。

次に、図６０，図６１に基づいて第２実施例を説明する。以下に述べる各実施例は、第１実施例の変形例に該当する。本実施例では、リソースを物理的単位で分配するのではなく、論理的な単位で分配する。

図６０は、サーバ１０で保持される性能管理情報Ｄ１１Ａを示す説明図である。性能管理情報Ｄ１１Ａは、各プロセッサやメモリをその使用可能率で分配している。例えば、「プロセッサ１」は、その40%が一方の論理分割サーバ１１に割り当てられ、残りの60%が他方の論理分割サーバ１１に割り当てられている。同様に、「メモリ１」は、その40%が一方の論理分割サーバ１１に割り当てられ、残りの60%が他方の論理分割サーバ１１に割り当てられている。

図６１は、サーバ１０で保持されているリソース管理情報Ｄ１２Ａを示す説明図であって、「プロセッサ１」は、その40%が一方の論理分割サーバ１１（LPR１）に割り当てられ、残りの60%が他方の論理分割サーバ１１（LPR２）に割り当てられている。このように、物理的な単位ではなく、論理的に各リソースを分割して、各論理的分割単位にそれぞれ割り当てることもできる。これにより、物理的なリソースの数を超えた論理的装置を仮想的に構築することができる。

図６２に基づいて第３実施例を説明する。本実施例では、接続可能なインターフェースを選択する処理の詳細が示されている。図６２は、インターフェース（パス）を追加する処理を示すフローチャートであって、図５８中のＳ３４１に対応する。

まず、総合管理モジュール４１１は、未割当てのインターフェースが存在するか否かを判定する（Ｓ３５０）。未割当てのインターフェースが一つも存在しない場合（S350:NO）、インターフェースを追加することができないため、総合管理モジュール４１１は、エラー処理を行う（Ｓ３５１）。このエラー処理では、例えば、ユーザ出力モジュール４１７を介して、ユーザに所定のエラーメッセージを通知する。

未割当てのインターフェースが存在する場合（S350:YES）、総合管理モジュール４１１は、その未割当てのインターフェースが、目的とするストレージ装置３０の論理分割ストレージ装置３１に接続済であるか否かを判定する（Ｓ３５２）。その未割当てのインターフェース、即ち、未使用のインターフェースが、目的の論理分割ストレージ装置３１に既に接続されている場合（S352:YES）、総合管理モジュール４１１は、その未割当てインターフェースを選択し、新たに割り当てる（Ｓ３５３）。

その未割当てのインターフェースが、目的の論理分割ストレージ装置３１に接続されていない場合（S352:NO）、総合管理モジュール４１１は、その未割当てインターフェースを目的の論理分割ストレージ装置３１に接続可能か否かを判定する（Ｓ３５４）。その未割当てのインターフェースを論理分割ストレージ装置３１に接続できない場合（S354:NO）、総合管理モジュール４１１は、エラー処理を行う（Ｓ３５５）。このエラー処理では、Ｓ３５１と同様に、例えば、「利用可能なインターフェース（パス）が存在しません。」等のエラーメッセージをユーザに通知する。

その未割当てのインターフェースを目的の論理分割ストレージ装置３１に接続可能な場合（S354:YES）、総合管理モジュール４１１は、ユーザ出力モジュール４１７を介して、パスの物理的な接続を行うようにユーザに指示する（Ｓ３５６）。ユーザは、この通知を受けて、ケーブルの接続作業を行う。未割当てのインターフェースが目的の論理分割ストレージ装置３１に接続されると（S357:YES）、総合管理モジュール４１１は、その接続されたインターフェースを新たに割り当てる（Ｓ３５８）。

図６３に基づいて第４実施例を説明する。図６４は、上述した図５８に示す処理の変形例を示すフローチャートである。本実施例では、インターフェースを追加する場合に、サーバ１０にパス管理ソフトウェアが実装されているか否かを判定する（Ｓ３６０）。サーバ１０にパス管理ソフトウェアが設けられていない場合（S360:NO）、たとえ物理的にパスを追加しても、パスの切り替え管理等を容易に行うことができないため、総合管理モジュール４１１は、エラー処理を行う（Ｓ３６１）。このエラー処理では、例えば、「パス管理ソフトウェアをサーバ１０にインストールする必要があります。」等のエラーメッセージをユーザに通知する。これにより、サーバ１０でのパス管理が可能な場合にのみ、インターフェースの追加または削除を行うことができ、使い勝手が向上する。

図６４に基づいて第５実施例を説明する。図６５は、上述した図５５に示す処理の変形例を示すフローチャートである。本実施例では、管理対象機器からのアラートに基づいてリソースを自動的に再配置する前に、総合管理モジュール４１１は、再配置処理の開始をユーザに事前に通知する（Ｓ３７０）。これにより、ユーザの知らない間に、リソースが自動的に再配置されるのを防止することができ、使い勝手が向上する。

図６５，図６６に基づいて第６実施例を説明する。本実施例では、クラスタ構成を意識してリソースの再配置を行う。図６５は、再配置ポリシテーブルＤ４１１Ａの構成を示す説明図である。再配置ポリシとして、例えば、「自動再配置あり、クラスタ連携モードあり」（タイプ５）と、「自動再配置なし、クラスタ連携モードあり」との２つを新たに追加することができる。クラスタ連携モードは、一方のアプリケーションプログラムと他方のアプリケーションプログラムとが、例えば、フェイルオーバクラスタや負荷分散クラスタのように、クラスタを構成し、互いに関連している場合に適用される。

図６６は、上述した図５５の処理の変形例を示すフローチャートである。クラスタ連携モードが予め選択されている場合（S380:YES）、総合管理モジュール４１１は、一方のアプリケーションプログラムについて実行されたリソース再配置を、クラスタを構成する他方のアプリケーションプログラムについても同様に実行する（Ｓ３８１）。これにより、クラスタを構成する各アプリケーションプログラムがそれぞれ利用するリソースの構成は、互いに等しくなる。

本実施例によれば、クラスタの構成を考慮してリソースを再配置できるため、使い勝手が向上する。例えば、現在使用されている運用系のアプリケーションプログラムにおいて、リソースが新たに追加された場合、バックアップとして待機しているアプリケーションプログラムにも同様にリソースが追加される。従って、運用系から待機系にフェイルオーバが実行された場合でも、切り替え前と同様のリソース配置で、データ処理サービスを続行することができる。これに対し、もしもクラスタ内でのリソース配置を調和させない場合、待機系のアプリケーションプログラムに関するリソースは、殆ど使用されないため、リソースが追加されることはなく、運用系アプリケーションプログラムに関するリソースの配置との差異が次第に増加する。

図６７に基づいて第７実施例を説明する。図６７は、上述した図６２の処理の変形例を示すフローチャートである。本実施例では、インターフェースを追加する場合に、総合管理モジュール４１１は、冗長度が高まるか否かを判定する（Ｓ３９０）。総合管理モジュール４１１は、冗長度が高まる場合（S390:YES）、その未割当てのインターフェースを選択して、新たに追加する（Ｓ３５３）。冗長度が高まる場合とは、その追加されたインターフェースによって形成されるパスが、既存のパスとは物理的に異なる装置（ホストインターフェースやスイッチ等）を使用しており、耐障害性が向上する場合である。

これに対し、その未割当てのインターフェースを選択しても冗長度が向上しない場合（S390:NO）、総合管理モジュール４１１は、ユーザの承認を求め（Ｓ３９１）、ユーザの承認を得られた場合にのみ（S391:YES）、その未割当てのインターフェースを選択して、追加する。これにより、ストレージシステムのパスの冗長度を改善しながら、リソースを再配置することができ、ストレージシステムの信頼性を向上させることができる。

図６８に基づいて第８実施例を説明する。図６８は、上述した図５８の処理の変形例を示すフローチャートである。本実施例では、インターフェースを削除する場合、総合管理モジュール４１１は、冗長度の低下について、ユーザの承認を求める（Ｓ４００）。ユーザの承認が得られた場合（S400:YES）、総合管理モジュール４１１は、そのインターフェースの割当てを解除し、未使用プールに戻す（Ｓ３４２）。これにより、ユーザは、耐障害性を意識してストレージシステムを運用可能であり、使い勝手が向上する。

図６９に基づいて第９実施例を説明する。図６９は、上述した図５５の処理の変形例を示すフローチャートである。本実施例では、コピー連携モードを採用する。コピー連携モードとは、クラスタ連携モードと同様に、コピー元のアプリケーションプログラムに関するリソース配置とコピー先のアプリケーションプログラムに関するリソース配置とを同期させるモードである。

コピー連携モードが予め選択されている場合（S410:YES）、総合管理モジュール４１１は、コピー先のアプリケーションプログラムに関するリソース配置を、コピー元のアプリケーションプログラムに関するリソース配置に一致させる（Ｓ４１１）。クラスタ連携モードと同様に、コピー先のアプリケーションプログラムに関するリソースの負荷状態を問わずに、コピー元のアプリケーションプログラムにおけるリソース配置が自動的に反映される。これにより、使い勝手が向上する。

なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、データ転送能力が十分にあるパスが複数存在する場合、スイッチ内の他のリソース（メモリ等）に余力があり、ボトルネックとなりにくいパスを優先して選択することもできる。

本発明の全体概念を示す説明図である。 ストレージシステムの概略構成を模式的に示す説明図である。 論理的に分割された各装置の関係を示す説明図である。 ストレージシステムの物理的構成を示すブロック図である。 サーバ、スイッチ及びストレージ装置のソフトウェア構成を示す説明図である。 管理端末のソフトウェア構成を示す説明図である。 性能管理情報の構成を示す説明図である。 リソース管理情報の構成を示す説明図である。 アプリケーション管理情報の構成を示す説明図である。 接続構成管理情報の構成を示す説明図である。 性能管理情報の構成を示す説明図である。 リソース割当て管理情報の構成を示す説明図である。 再配置定義テーブルの構成を示す説明図である。 業務管理テーブルの構成を示す説明図である。 性能情報設定値管理テーブルの構成を示す説明図である。 性能情報履歴管理テーブルの構成を示す説明図である。 リソース管理テーブルの構成を示す説明図である。 アプリケーション管理テーブルの構成を示す説明図である。 接続構成管理テーブルの構成を示す説明図である。 アプリケーションプログラムと業務とを対応づける画面を示す説明図である。 業務情報を入力する画面を示す説明図である。 リソース管理情報を入力する画面を示す説明図である。 再配置条件を入力する画面を示す説明図である。 ストレージシステムの物理的構成を表示させる画面を示す説明図である。 ストレージシステムの論理的構成を表示させる画面を示す説明図である。 ストレージシステムの論理的構成を各アプリケーションプログラムの視点から表示させる画面を示す説明図である。 各アプリケーションプログラム毎に、そのリソースの負荷状態の推移を表示させる画面を示す説明図である。 リソース構成の推移を各管理対象機器毎に表示させる画面を示す説明図である。 各機器から性能管理情報を収集する処理を示すフローチャートである。 各機器からリソース管理情報を収集する処理を示すフローチャートである。 各機器からアプリケーション管理情報を収集する処理を示すフローチャートである。 各機器から接続構成管理情報を収集する処理を示すフローチャートである。 各機器に閾値を変更させる処理を示すフローチャートである。 各機器に監視周期を変更させる処理を示すフローチャートである。 各機器に管理部位を変更させる処理を示すフローチャートである。 各機器にリソース割当てを変更させる処理を示すフローチャートである。 各機器に接続構成を変更させる処理を示すフローチャートである。 各機器からのアラートを受信する処理を示すフローチャートである。 総合管理モジュールが性能管理情報を取得する処理を示すフローチャートである。 総合管理モジュールが設定値の変更を要求する処理を示すフローチャートである。 総合管理モジュールがリソース管理情報を取得する処理を示すフローチャートである。 総合管理モジュールが管理部位の変更を要求する処理を示すフローチャートである。 総合管理モジュールが接続構成管理情報を取得する処理を示すフローチャートである。 総合管理モジュールがアプリケーション管理情報を取得する処理を示すフローチャートである。 管理対象機器からのアラートによってリソースの再配置が指示される処理を示すフローチャートである。 業務名とアプリケーションプログラムとを対応づけるための処理を示すフローチャートである。 業務周期を設定するための処理を示すフローチャートである。 リソース管理情報を設定するための処理を示すフローチャートである。 再配置条件を設定するための処理を示すフローチャートである。 ストレージシステムの物理的構成を表示させる処理を示すフローチャートである。 ストレージシステムの論理的構成を表示させる処理を示すフローチャートである。 ストレージシステムの論理的構成を各アプリケーションプログラムの視点から表示させる処理を示すフローチャートである。 各リソースの性能情報の推移を表示させる処理を示すフローチャートである。 リソースの推移を表示させる処理を示すフローチャートである。 リソースを再配置させる処理の全体概要を示すフローチャートである。 業務単位でリソースを再配置させる処理を示すフローチャートである。 図５６中のＳ３１９の詳細を示すフローチャートである。 図５７に続くフローチャートである。 作業管理テーブルの構成を示す説明図である。 第２実施例に係るストレージシステムで使用される性能管理情報の構成を示す説明図である。 第２実施例に係るストレージシステムで使用されるリソース管理情報の構成を示す説明図である。 第３実施例に係るストレージシステムで実行されるパス追加処理を示すフローチャートである。 第４実施例に係るストレージシステムで実行される再配置実施処理を示すフローチャートである。 第５実施例に係るストレージシステムで実行される再配置処理の全体概要を示すフローチャートである。 第６実施例に係るストレージシステムで使用される再配置ポリシテーブルの構成を示す説明図である。 第６実施例に係るストレージシステムで実行される再配置処理の全体概要を示すフローチャートである。 第７実施例に係るストレージシステムで実行されるパス追加処理を示すフローチャートである。 第８実施例に係るストレージシステムで実行される再配置実施処理を示すフローチャートである。 第９実施例に係るストレージシステムで実行される再配置処理の全体概要を示すフローチャートである。

符号の説明

１…サーバ、１Ａ，１Ｂ…仮想サーバ、１Ｃ…サーバ管理部、１Ｄ…リソース、２…スイッチ、２Ａ，２Ｂ…ゾーン、２Ｃ…スイッチ管理部、２Ｄ…リソース、３…ストレージ装置、３Ａ，３Ｂ…仮想ストレージ装置、３Ｃ…ストレージ管理部、３Ｄ…リソース、４…管理装置、４Ａ…情報収集部、４Ｂ…配置管理部、４Ｃ…履歴管理部、４Ｄ…出力部、４Ｄ１…性能表示部、４Ｄ２…構成表示部、４Ｅ…入力部、４Ｆ…管理データベース、４Ｇ…履歴データベース、４Ｈ…ユーザインターフェース部、５，６…ネットワーク、７…管理用ネットワーク、１０…サーバ、１１…論理分割サーバ、２０…スイッチ、２１…ゾーン、３０…ストレージ装置、３１…論理分割ストレージ装置、４０…管理端末、５０，６０…ネットワーク、７０…管理用ネットワーク、１０１…アプリケーションプログラム、１１０…プロセッサ、１１１…性能管理モジュール、１１２…リソース管理モジュール、１１３…アプリケーション管理モジュール、１１４…接続管理モジュール、１１５…通信制御モジュール、１２０…メモリ、１３０…キーボードスイッチ、１４０…ディスプレイ、１５０…ディスクインターフェース、１６０…ローカルディスク、１７０…LANインターフェース、２１０…プロセッサ、２１１…性能管理モジュール、２１２…リソース管理モジュール、２１２…リソース管理モジュール、２１３…接続管理モジュール、２１４…通信制御モジュール、２２０…メモリ、２３０，２４０ インターフェース、２５０…接続回路、２６０…LANインターフェース、３１０…サービスプロセッサ（SVP）、３１１…性能管理モジュール、３１２…リソース管理モジュール、３１３…接続管理モジュール、３１４…通信制御モジュール、３２０…チャネルアダプタ（CHA）、３３０…ディスクアダプタ（DKA）、３４０…キャッシュメモリ、３５０…共有メモリ、３６０，３７０…接続部、３８０…ディスクドライブ、３９０…LANインターフェース、４１０…プロセッサ、４１１…総合管理モジュール、４１２…性能管理モジュール、４１３…アプリケーション管理モジュール、４１４…リソース管理モジュール、４１５…接続管理モジュール、４１６…ユーザ入力モジュール、４１７…ユーザ出力モジュール、４１８…再配置指示モジュール、４１９…通信制御モジュール、４２０…メモリ、４３０…キーボードスイッチ、４４０…ディスプレイ、４５０…ローカルディスク、４６０…LANインターフェース。

Claims (8)

1. 上位装置と、この上位装置に記憶領域を提供するためのストレージ装置とを備えたストレージシステムの構成を管理する構成管理装置であって、
   前記上位装置を複数の論理的上位装置に分割し、これら各論理的上位装置に前記上位装置の有する資源のうち所定の資源をそれぞれ分配する第１管理部と、
   前記ストレージ装置を複数の論理的ストレージ装置に分割し、これら各論理的ストレージ装置に前記ストレージ装置の有する資源のうち所定の資源をそれぞれ分配する第２管理部と、
   前記各論理的上位装置及び前記各論理的ストレージ装置に関する所定情報を、前記第１管理部及び前記第２管理部を介して、それぞれ取得する情報収集部と、
   収集された前記各所定情報に基づいて、前記各論理的上位装置上でそれぞれ実行される各アプリケーションプログラムにより使用される前記所定の資源に過不足が生じたか否かをそれぞれ判定し、前記過不足が発生していると判定された場合、前記各管理部のうち前記過不足に係る所定の資源を管理する管理部に構成変更要求を発行することにより、前記過不足が解消するように前記所定の資源を再配置させる配置管理部と、
   前記各所定情報の履歴をそれぞれ保存して管理する履歴管理部と、
   前記履歴管理部により管理される前記各所定情報の履歴を出力するユーザインターフェース部と、
   を備えたストレージシステムの構成管理装置。
2. 前記上位装置と前記ストレージ装置とを接続するための中継装置を複数の論理的中継装置に分割し、これら各論理的中継装置に前記中継装置の有する資源のうち所定の資源をそれぞれ分配する第３管理部をさらに備え、
   前記情報収集部により収集される前記所定情報には、前記各論理的中継装置に関する所定情報も含まれる請求項１に記載のストレージシステムの構成管理装置。
3. 前記ユーザインターフェース部は、前記各論理的上位装置と前記各論理的ストレージ装置の論理的な接続構成を出力可能である請求項１に記載のストレージシステムの構成管理装置。
4. 前記配置管理部は、一方のアプリケーションプログラムに関する前記所定の資源の配置を変更させた場合、前記一方のアプリケーションプログラムに対応する他方のアプリケーションプログラムに関する前記所定の資源を、前記一方のアプリケーションプログラムについての資源配置と同一構成となるように、再配置させる請求項１に記載のストレージシステムの構成管理装置。
5. 前記配置管理部は、ストレージシステムの冗長度を考慮して、前記過不足を生じた所定の資源を再配置させる請求項１に記載のストレージシステムの構成管理装置。
6. 未使用の前記所定の資源を管理するための資源プールを備え、
   前記配置管理部は、前記所定の資源のうち所定の下限値以下の利用率を有する所定の資源を前記資源プールに戻し、前記所定の資源のうち所定の上限値以上の利用率を有する所定の資源については、同種の資源を前記資源プールから選択して追加させる請求項１に記載のストレージシステムの構成管理装置。
7. 前記履歴管理部は、予め設定された所定の期間単位で前記各所定情報の履歴を管理する請求項１に記載のストレージシステムの構成管理装置。
8. 上位装置と、この上位装置に記憶領域を提供するためのストレージ装置とを備えたストレージシステムの構成を管理するための構成管理方法であって、
   前記上位装置を複数の論理的上位装置に分割し、これら各論理的上位装置に前記上位装置の有する資源のうち所定の資源をそれぞれ分配する第１管理部から、前記各論理的上位装置に関する所定情報をそれぞれ収集して管理するステップと、
   前記ストレージ装置を複数の論理的ストレージ装置に分割し、これら各論理的ストレージ装置に前記ストレージ装置の有する資源のうち所定の資源をそれぞれ分配する第２管理部から、前記各論理的ストレージ装置に関する所定情報をそれぞれ収集して管理するステップと、
   再配置の実行が指示されたか否かを判定するステップと、
   前記再配置の実行が指示された場合、前記再配置の実行指示に関係するアプリケーションプログラムを特定するステップと、
   前記収集された各所定情報に基づいて、前記特定されたアプリケーションプログラムにより使用される前記所定の資源に過不足が発生したか否かを判定するステップと、
   前記過不足が発生していると判定された場合、前記各管理部のうち前記過不足に係る所定の資源を管理する管理部に構成変更要求を発行することにより、前記過不足が解消するように前記所定の資源を再配置させるステップと、
   前記各所定情報の履歴をそれぞれ保存して管理するステップと、
   前記各所定情報の履歴を出力するステップと、
   を含んだストレージシステムの構成管理方法。
   

Images