JP2005309748A - ストレージシステム及びストレージシステムの障害解消方法 - Google Patents

Abstract

【課題】 ストレージシステムの構成を実際に変更する前に、ストレージシステムの各要素の状態に基づいてボトルネックの発生を検出し、このボトルネックを解消するための対策を提示する。
【解決手段】 ホストの要素Ｎ１は、要素Ｎ３、要素Ｎ６、要素Ｎ８を介して、ストレージ装置内の要素Ｎ１０に接続されている（Ｓ１）。要素Ｎ１は、例えば、デバイスファイル等である。要素Ｎ１０は、例えば、論理ボリューム等である。中間の要素Ｎ８にボトルネックが発生した場合（Ｓ２）、ストレージシステムの各要素に関して収集された情報に基づいて（Ｓ３）、このボトルネックが検出される（Ｓ４）。このボトルネック解消に有効な対策が検討され、選択される（Ｓ５，Ｓ６）。この対策は、経路上の両端に位置する要素Ｎ１，Ｎ２またはＮ９，Ｎ１０のいずれかを操作するものである。
【選択図】 図１

Description

本発明は、ストレージシステム及びストレージシステムの障害解消方法に関する。

ストレージシステムは、例えば、複数のホストコンピュータ（サーバ等）によって利用される１台以上のストレージ装置を備えている。各ホストコンピュータとストレージ装置とは、ファイバチャネルスイッチやハブ等の中継装置を介して接続される。

ストレージ装置は、例えば、ディスクアレイ装置等とも呼ばれるもので、多数のディスクドライブをアレイ状に配設して構成される。ストレージ装置は、例えば、RAID（Redundant Array of Independent Inexpensive Disks）に基づく記憶領域を提供する。各ディスクドライブが有する物理的な記憶領域上には、論理的な記憶領域である論理ボリューム（論理デバイス）が形成されている。そして、サーバ等のようなホストコンピュータは、ストレージ装置に対して所定形式のライトコマンド又はリードコマンドを発行することにより、所望のデータの読み書きを行うことができる。

各ホストコンピュータは、所定の経路を介して、割り当てられた論理ボリュームにアクセスし、データの読み書きを行う。システム管理者等は、負荷の均等配分に考慮して、論理ボリュームの割当てを行うことができる。ストレージシステムに新たに追加されたホストコンピュータに対し、最も低負荷の論理ボリュームを割当てるようにした技術も知られている（特許文献１）。

また、予め複数の通信経路を設定しておき、電源障害等が発生した場合は、代替経路を介してデータを転送するようにした技術も知られている（特許文献２）。
特開平１０−３２０１２６号公報 特表２００４−５０３９５６号公報

前者の特許文献では、各論理ボリュームの負荷状態を検出して論理ボリュームの最適な割当てを図っている。しかし、ストレージシステムは、ストレージ装置のみで構成されるわけではなく、複数のホストコンピュータやファイバチャネルスイッチ等の複数種類の要素から構成されるものである。前者の公知技術では、ストレージ装置以外の他の要素の負荷状態を考慮することができず、ストレージシステム全体の状況に基づいて、負荷分散等を行うことができない。

後者の特許文献では、通信経路がダウンした場合に代替経路を介してデータ転送を行うものに過ぎず、ストレージシステム全体の負荷状況を考慮可能なものではない。

ストレージシステムは、例えば、ホストコンピュータやファイバチャネルスイッチ、ストレージ装置等の複数種類の要素によって構成される複雑なシステムであり、その時々の使用状況等によってシステム全体の負荷状態が変動する。ストレージシステム内で負荷の遍在が発生し、運用に支障を来したような場合、例えば、システム管理者が自己の経験等に基づいて、ディスクを追加したり、論理ボリュームの割当てを変更する。しかし、その構成変更が負荷の遍在解消に有効である保証は無い。また、２４時間３６５日の連続稼働が要求されるストレージシステムの負荷状況は、時々刻々と変化するので、この頻繁で不規則な状況変化に対し、適切かつ速やかに対応するのは困難である。

そこで、本発明の一つの目的は、実際に構成変更を行う前に、ストレージシステムを構成する各要素の性能状態を考慮して、性能改善上の障害を解消する対策を発見可能としたストレージシステム及びストレージシステムの障害解消方法を提供することにある。本発明の一つの目的は、ホストコンピュータとストレージ装置との間の中間に位置する要素の状況を考慮しつつ、この中間の要素の構成を直接変更するのではなく、通信経路上の両端に位置するホストコンピュータ及びストレージ装置側の構成変更で対応可能としたストレージシステム及びストレージシステムの障害解消方法を提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。

上記課題を解決すべく、本発明のストレージシステムは、複数の論理ボリュームを有するストレージ装置と、このストレージ装置に接続され、各論理ボリュームにアクセスするためのアクセス処理部を有するホストコンピュータと、ストレージ装置及びホストコンピュータにそれぞれ接続された管理用コンピュータと、を備える。さらに、本発明では、ホストコンピュータからストレージ装置までの通信経路上に存在する各要素の性能に関する性能情報をそれぞれ収集する性能情報収集部と、収集された各要素の性能情報に基づいて、性能改善上の障害を有する障害要素を検出する障害要素検出部と、検出された障害要素の障害内容に基づいて対策を検討し、障害に有効な対策を選択する検討部と、を備え、検討部により検討される対策は、障害要素に関連する論理ボリューム及びアクセス処理部の少なくともいずれか一方を、他の論理ボリュームまたは他のアクセス処理部に変更させるようになっている。

ここで、「アクセス処理部」とは、例えば、ホストコンピュータに実装されたアプリケーションプログラムからのデータアクセス要求を処理するための機能または構造を意味し、ファイルシステムやデバイスファイル等を挙げることができる。「通信経路上に存在する各要素」としては、例えば、論理ボリュームと、アクセス処理部と、スイッチやハブ等のような中継装置等を挙げることができる。「ホストコンピュータ」は、例えば、サーバやメインフレーム等のようなコンピュータであり、例えば、クライアント端末からの要求に応じてデータ処理を行う。「管理用コンピュータ」は、ストレージシステムの管理を行うためのコンピュータである。機能上、ホストコンピュータと管理用コンピュータとは区別されるが、例えば、物理的に同一のコンピュータ内にアプリケーションサーバと管理用サーバとを併存させる構成でもよい。

「性能情報」とは、例えば、応答性等のような各要素の性能に関連する情報を意味し、例えば、単位時間あたりのＩ／Ｏ量（入出力要求量等を挙げることができる。「性能改善上の障害」とは、各要素の性能を低下させている事象を意味する。例えば、特定の要素に負荷が集中しているために応答性が低下している場合、負荷の集中が「性能改善上の障害」に相当する。

検討部により選択された対策をユーザに提示する提示部を備えることもできる。提示部は、例えば、端末画面や音声合成装置等のユーザインターフェースを介して、検討部により選択された対策をユーザに提示することができる。システム管理者等のユーザは、提示された対策を採用するか否かを判断することができる。提示された対策を採用する場合、ユーザは、管理用コンピュータ等を介して、ストレージシステムの構成変更を行う。

検討部は、予め用意された複数の対策の全部または一部について障害に対する有効性を評価することにより、障害に有効な対策を選択することができる。例えば、第１の対策，第２の対策、第３の対策等のように、予め複数の対策を用意しておき、これら複数の対策の全部または一部について、障害に対する有効性を評価することができる。各対策には、それぞれ複数のサブ対策を含めることができる。そして、検討部は、例えば、最も有効性の高い対策を選択することができる。あるいは、検討部は、障害改善効果と障害改善に要する各種コストとを比較し、費用対効果の優れた対策を選択することもできる。

それぞれ異なる優先度を有する複数の対策を予め記憶する記憶部を設け、検討部は、複数の対策のうち優先度の高い対策から順番に、障害に対する有効性を評価し、障害に有効な対策を発見した場合は、この対策を選択することもできる。

例えば、第１の対策，第２の対策，第３の対策の順番で高い優先度が設定されている場合、検討部は、第１の対策から順番に有効性を評価していく。そして、有効な対策を発見した場合、検討部は、残りの対策についての評価を行わず、有効であると最初に判断された対策を選択する。例えば、最も優先度の高い第１の対策が所定の有効性を有すると判断された場合、検討部は、第２の対策及び第３の対策についての有効性評価を行わず、第１の対策を選択する。これにより、障害に有効な対策を早期に選択することができる。

それぞれ異なる優先度を有する複数の対策のそれぞれについて、その対策により影響を受ける要素の範囲を予め関連付けておき、検討部は、複数の対策のうち優先度の高い対策から順番に、その対策に予め関連付けられた要素の範囲内で障害に対する有効性を評価し、障害に有効な対策を発見した場合は、この対策を選択することもできる。

対策の種類によって、その対策が実施された場合の影響範囲は、それぞれ異なる場合がある。ある一つの対策は特定の範囲内の要素に対して影響を及ぼし、別の一つの対策は他の範囲内の要素に対して影響を及ぼす場合がある。即ち、ある一つの対策は、ある一つまたは複数の要素に対して有効であり、別の一つの対策は、他の一つまたは複数の要素に対して有効な場合がある。このような場合に、検討部は、その対策が有効な範囲内で、障害への有効性を評価する。これにより、無駄な有効性評価が行われるのを防止して、効率的に有効性を評価することができる。

本発明の他の観点に従うストレージシステムの障害解消方法は、複数の論理ボリュームを有するストレージ装置と、このストレージ装置に接続され、各論理ボリュームにアクセスするためのアクセス処理部を有するホストコンピュータと、ストレージ装置及びホストコンピュータにそれぞれ接続された管理用コンピュータと、を備えたストレージシステムの障害を解消するための方法であって、ホストコンピュータからストレージ装置までの通信経路上に存在する各要素の性能に関する性能情報をそれぞれ収集するステップと、収集された各要素の性能情報に基づいて、性能改善上の障害を有する障害要素を検出するステップと、検出された障害要素の障害内容に基づいて、障害要素に関連する論理ボリューム及びアクセス処理部の少なくともいずれか一方を他の論理ボリュームまたは他のアクセス処理部に変更させる対策を選択するステップと、選択された対策をユーザに提示するステップと、を含む。

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

以下、図面に基づき、本発明の実施の形態を説明する。本実施形態のストレージシステムは、データを格納する複数のデータ格納先要素（例えば、論理ボリューム）と、これら各データ格納先要素に格納されるデータにアクセスする複数のデータ利用元要素（例えば、デバイスファイル）と、各データ格納先要素と各データ利用元要素との間に設けられる少なくとも一つ以上の中継要素（例えば、スイッチ）と、各データ利用元要素から中継要素を介して各データ格納先要素に至る経路とを含む情報処理システムである。

そして、このストレージシステムは、性能情報収集部と、障害要素検出部と、検討部と、提示部とを備えることができる。性能情報収集部は、例えば、負荷情報等のような各要素の性能に関する情報をそれぞれ収集する。障害要素検出部は、収集された性能に関する情報に基づいて、例えば、性能上のボトルネック等のような性能改善上の障害を有する障害要素を検出する。検討部は、検出された障害要素の障害内容を検討し、各データ利用元要素及び各データ格納先要素のうち障害要素に関連するデータ利用元要素またはデータ格納先要素の少なくともいずれか一方を他のデータ利用元要素または他のデータ格納先要素に変更させる対策を少なくとも一つ以上シミュレートすることにより、障害に有効な対策を選択する。提示部は、選択された対策を提示する。

図１は、本実施形態の全体概念を模式的に示す説明図である。このストレージシステムは、少なくとも一つ以上のホストコンピュータ及びストレージ装置を備える。ストレージシステムは、複数の要素Ｎ１〜Ｎ１０を備えている。

これらの要素Ｎ１〜Ｎ１０は、その情報処理経路上の位置に応じて、幾つかのグループに分類可能である。幾つかの要素Ｎ１，Ｎ２は、情報処理経路上の一方の端点であるホストコンピュータに属する。他の幾つかの要素Ｎ９，Ｎ１０は、情報処理経路上の他方の端点であるストレージ装置に属する。残りの要素Ｎ３〜Ｎ８は、情報処理経路上の中間に位置し、ホストコンピュータとストレージ装置との間に介在する。

ここで、ホストコンピュータに属する要素Ｎ１，Ｎ２は、例えば、ファイルシステムやデバイスファイル等であり、データ利用元の要素である。ストレージ装置に属する要素Ｎ９，Ｎ１０は、例えば、論理ボリュームやパリティグループ等であり、データ格納先の要素である。中間に位置する要素Ｎ３〜Ｎ８は、例えば、スイッチやハブ等であり、中継要素である。

Ｓ１に示すように、一方の端点に位置する要素Ｎ１と他方の端点に位置する要素Ｎ１０とは、所定の経路を介して接続されている。即ち、要素Ｎ１は、Ｎ３からＮ６及びＮ８を介して、Ｎ１０に接続されている（Ｎ１→Ｎ３→Ｎ６→Ｎ８→Ｎ１０）。例えば、図外のアプリケーションプログラムが、ファイルシステム（図示せず）を介して、デバイスファイル（Ｎ１）にアクセス要求を発行した場合、このアクセス要求は、Ｎ３、Ｎ６，Ｎ８を介して、論理ボリューム（Ｎ１０）に到達する。

Ｓ２に示すように、ある時点で、要素Ｎ１と要素Ｎ１０との経路上に位置する要素Ｎ８に、ボトルネックが発生したとする。例えば、他のデータ処理のために要素Ｎ８が使用されており、要素Ｎ８に過大な負荷が発生しているような場合、要素Ｎ８の応答性等が低下して、ボトルネックとなる。

本実施形態のストレージシステムは、各要素Ｎ１〜Ｎ１０の性能に関する情報を定期的に収集している（Ｓ３）。そして、ストレージシステムは、各要素Ｎ１〜Ｎ１０の最新の状態に基づいて、ボトルネック（図示の例では、Ｎ８）を検出する（Ｓ４）。ストレージシステムは、このボトルネックを解消するための対策を一つまたは複数検討し、ボトルネック解消に有効と判断される対策を選択する（Ｓ５）。

ストレージシステムは、要素Ｎ１が利用している要素Ｎ１０を別の要素Ｎ９に変更させることにより、結果的に要素Ｎ８を回避する新たな経路を設定する。ホストコンピュータ側の要素Ｎ１は、要素Ｎ３から要素Ｎ５及び要素Ｎ７を介して、ストレージ装置側の要素Ｎ９にアクセスする（Ｎ１→Ｎ３→Ｎ５→Ｎ７→Ｎ９）。即ち、本実施形態では、ボトルネックとなる要素Ｎ８を直接回避する対策を検討するのではなく、情報処理経路の両端にそれぞれ位置する要素Ｎ１，Ｎ２及びＮ９，Ｎ１０を変更させることで、結果的にボトルネックを解消するようになっている。

図２は、ストレージシステムの全体構成を示すブロック図である。このストレージシステムは、それぞれ後述するように、複数のアプリケーションサーバ１０（以下、「サーバ」）と、一つのストレージ装置２０と、複数のファイバチャネルスイッチ（以下、「スイッチ」）３０と、一つの監視サーバ４０と、一つの管理サーバ５０と、複数のクライアント端末６０とを備えている。

各サーバ１０は、一つまたは複数のアプリケーションプログラム（「アプリケーション」と略記）１１と、一つまたは複数のファイルシステム１２と、一つまたは複数のデバイスファイル１３と、HBA（Host Bus Adapter）等の通信ポート１４と、ホスト情報収集部１５とを、それぞれ備えている。各サーバ１０は、例えば、CPU（Central Processing Unit）やROM（Read Only Memory）、RAM（Random Access Memory）、各種ドライバソフトウェア等のコンピュータ資源をそれぞれ備えたコンピュータである。

アプリケーションプログラム１１は、ファイルシステム１２を介して、デバイスファイル１３にアクセスする。ファイルシステム１２は、ファイル単位でデータの入出力を管理するためのプログラムである。デバイスファイル１３は、OS（Operating System）のカーネルに組み込まれたデバイスドライバを呼び出すためのプログラムである。通信ポート１４は、例えば、ファイバチャネルプロトコル等の所定のプロトコルに基づいて、データ通信を行うものである。

アプリケーションプログラム１１がデバイスファイル１３にアクセスすると、デバイスドライバが起動される。これにより、アプリケーションプログラム１１は、通信ポート１４を介してストレージ装置２０にアクセスし、データの読み書きを行う。

ホスト情報収集部１５は、サーバ１０の性能に関する情報を定期的に収集し、この収集した性能情報を管理サーバ５０に送信するためのプログラムである。サーバ１０の性能に関する情報の一例として、ホスト情報収集部１５は、デバイスファイル１３の単位時間当たりのＩ／Ｏ量を定期的に収集する。

ストレージ装置２０は、一つまたは複数の通信ポート２１と、一つまたは複数のパリティグループ２２と、一つまたは複数の論理ボリューム２３とを備えている。図中では１台のみ示しているが、ストレージ装置２０は、複数設けることもできる。各通信ポート２１は、例えば、ファイバチャネルプロトコル等の所定のプロトコルに基づいて、各サーバ１０とのデータ通信をそれぞれ行うものである。各パリティグループ２２は、複数のディスクドライブをそれぞれグループ化したものである。各パリティグループ２２により提供される物理的な記憶領域上には、少なくとも一つ以上のLDEV２３をそれぞれ構築することができる。各LDEV２３は、論理的な記憶デバイス（論理ボリューム）である。ストレージ装置２０の構成については、さらに後述する。

各スイッチ３０は、それぞれ複数のポート３１を備えている。図中では、「スイッチ」を「ＳＷ」と略記している。ストレージ装置２０と各サーバ１０とは、スイッチ３０にそれぞれファブリック接続されている。スイッチ３０とサーバ１０との間は、ファイバチャネルプロトコルに従う通信ネットワークＣＮ２によって接続されている。また、スイッチ３０とストレージ装置２０との間も、ファイバチャネルプロトコルに従う通信ネットワークＣＮ２により接続されている。

監視サーバ４０は、各スイッチ３０やストレージ装置２０の状況を監視し、監視結果を管理サーバ５０に報告するものである。監視サーバ４０は、スイッチ３０の性能情報を収集するためのスイッチ情報収集部４１と、ストレージ装置２０の性能情報を収集するためのストレージ情報収集部４２とを備えている。スイッチ情報収集部４１は、各スイッチ３０の各ポート３１の単位時間あたりのＩ／Ｏ量を収集する。ストレージ情報収集部４２は、ストレージ装置２０の各ポート２１、各パリティグループ２２及び各LDEV２３の単位時間当たりのＩ／Ｏ量をそれぞれ収集する。なお、性能情報の一例として、Ｉ／Ｏ量（データ入出力要求量）を挙げているが、これに限らず、例えば、応答時間等のような他の情報を採用することもできる。また、監視サーバ４０は、管理サーバ５０と一体化することもできる。あるいは、サーバ１０のいずれかに監視機能を設けてもよい。

管理サーバ５０は、ボトルネック検出部５１と、検討部５２と、対策提示部５３と、性能情報データベース５４とを備えている。詳細は後述するが、管理サーバ５０は、各ホスト情報収集部１５とスイッチ情報収集部４１とストレージ情報収集部４２とから、それぞれ性能情報を定期的に収集する。そして、管理サーバ５０は、ストレージシステム内のボトルネックを検出し、このボトルネックを解消するための対策を検討する。管理サーバ５０は、検討結果をユーザに提示する。

図３は、管理サーバ５０の機能構成を示す説明図である。性能情報データベース５４には、それぞれ後述するように、ホスト性能情報Ｔ１と、スイッチ性能情報Ｔ２と、ストレージポート性能情報Ｔ３と、パリティグループ性能情報Ｔ４と、LDEV性能情報Ｔ５と、経路情報Ｔ６と、対策情報Ｔ７と、閾値情報Ｔ８とを記憶させることができる。これらの各情報Ｔ１〜Ｔ８は、同一のデータベース５４内に存在させる必要性はなく、異なる複数のデータベースに分散して記憶させる構成でもよい。

ボトルネック検出部５１は、ストレージシステムを構成する各要素（例えば、デバイスファイル１３，スイッチポート３１，ストレージポート２１，パリティグループ２２，LDEV２３）について、性能上のボトルネックが発生しているか否かを検出する。ここで、性能上のボトルネックは顕在化している必要はなく、将来ボトルネックとなり得る状態も含ませることができる。即ち、後述の閾値の設定等によっても異なるが、実際にボトルネックとして顕在化する前の状態を、ボトルネックとして検出可能である。

検討部５２は、データ量算出部５２Ａと、シミュレーション対象設定部５２Ｂと、シミュレーション部５２Ｃとを備えることができる。データ量算出部５２Ａは、ボトルネックとなった要素にＩ／Ｏを発生させているデバイスファイルを特定し、このボトルネックの原因となっているデバイスファイルのＩ／Ｏ量を算出するものである。シミュレーション対象設定部５２Ｂは、ボトルネック解消用の対策をシミュレーションする対象を抽出するものである。シミュレーション部５２Ｃは、抽出された対象について所定のシミュレーションを行い、その結果を評価するものである。このように、検討部５２は、ボトルネックが検出された場合に、このボトルネックを解消するための対策を一つまたは複数シミュレートし、有効な対策の発見を試みる。検討部５２は、有効な対策が発見された場合、この対策を選択する。

対策提示部５３は、検討部５２によって選択された対策をユーザに提示する。対策提示部５３は、例えば、端末画面からの表示出力や音声合成装置からの音声出力等によって、有効と判断された対策を提示する。ユーザは、提示された対策を検討し、この提案を受け入れるか否かを判断することができる。提案を受け入れる場合、ユーザは、例えば、管理サーバ５０を介して、ストレージシステムの構成変更を行うことができる。なお、場合によっては、ユーザへの提示を省略し、ストレージシステムの構成変更を直接実行する構成でもよい。この場合、対策提示部５３は、「対策実行指示部」と呼ぶことができる。

図４は、ストレージ装置２０の機能構成を示す説明図である。ストレージ装置２０は、通信ネットワークＣＮ２を介して、複数のサーバ１０と双方向通信可能にそれぞれ接続されている。

通信ネットワークとしては、例えば、LAN（Local Area Network）、SAN（System Area Network）、インターネットあるいは専用回線等を採用可能である。LANを用いる場合、各サーバ１０とストレージ装置２０との間のデータ転送は、TCP/IPに従って行われる。SANを用いる場合、各サーバ１０とストレージ装置２０とは、ファイバチャネルプロトコルに従ってデータ転送を行う。また、サーバ１０に替えてメインフレームマシンを用いる場合は、例えば、FICON（Fibre Connection：登録商標）、ESCON（Enterprise System Connection：登録商標）、ACONARC（Advanced Connection Architecture：登録商標）、FIBARC（Fibre Connection Architecture：登録商標）等の通信プロトコルに従ってデータ転送が行われる。

本実施例では、各サーバ１０とストレージ装置２０とをSANによって接続し、各サーバ１０と監視サーバ４０及び管理サーバ５０とをLANによって接続する。また、ストレージ装置２０がLANポートを備えている場合は、LANを介してストレージ装置２０と管理サーバ５０等とを接続することもできる。あるいは、通常のデータ転送と管理情報の転送とをSANを介して行うこともできる。

ストレージ装置２０は、それぞれ後述するように、ディスクドライブ１００と、チャネルアダプタ（以下、「CHA」）１１０と、ディスクアダプタ（以下、「DKA」）１２０と、キャッシュメモリ１３０と、共有メモリ１４０と、スイッチ部１５０と、サービスプロセッサ（以下、「SVP」）１６０とを備えている。

各ディスクドライブ１００は、例えば、ハードディスクドライブ（ＨＤＤ）や半導体メモリ装置等として実現することができる。ディスクドライブ１００は、物理的な記憶デバイスである。RAID構成等によっても相違するが、例えば、３個１組あるいは４個１組等のような複数個のディスクドライブ１００が、パリティグループ（RAIDグループとも呼ぶ）を構成している。そして、各パリティグループが提供する記憶領域上には、LDEV２３が構築される。図中では、２個のパリティグループ２２のそれぞれに２個ずつのLDEV２３を構成する様子を示しているが、これに限らず、３個以上のパリティグループ２２を設けることもでき、LDEV２２も適宜設定することができる。なお、ストレージ装置２０が各サーバ１０に提供する記憶資源は、全てストレージ装置２０内に設けられている必要はない。ストレージ装置２０は、ストレージ装置２０の外部に存在する記憶資源を、あたかも自己の記憶資源であるかのように取り込んで、利用することもできる。

各CHA１１０は、各サーバ１０との間のデータ転送を制御するもので、複数のポート２１を備えている。ストレージ装置２０には、例えば３２個等のような複数のCHA１１０を設けることができる。CHA１１０は、例えば、オープン系用CHA、メインフレーム系用CHA等のように、サーバ１０の種類に応じて用意される。なお、１個のCHA１１０で複数のプロトコルをサポート可能に構成してもよい。各CHA１１０は、それぞれに接続されたサーバ１０から、データの読み書きを要求するコマンド及びデータを受信し、サーバ１０から受信したコマンドに従って動作する。

DKA１２０の動作も含めて先に説明すると、CHA１１０は、サーバ１０からリードコマンドを受信すると、このリードコマンドを共有メモリ１４０に記憶させる。DKA１２０は、共有メモリ１４０を随時参照しており、未処理のリードコマンドを発見すると、ディスクドライブ１００からデータを読み出し、キャッシュメモリ１３０に記憶させる。CHA１１０は、キャッシュメモリ１３０に移されたデータを読み出し、サーバ１０に送信する。

一方、CHA１１０は、サーバ１０からライトコマンドを受信すると、このライトコマンドを共有メモリ１４０に記憶させる。また、CHA１１０は、受信したデータ（ユーザデータ）をキャッシュメモリ１３０に記憶させる。CHA１１０は、キャッシュメモリ１３０にデータを記憶した後、サーバ１０に書込み完了を報告する。DKA１２０は、共有メモリ１４０に記憶されたライトコマンドに従って、キャッシュメモリ１３０に記憶されたデータを読出し、所定のディスクドライブ１００に記憶させる。

各DKA１２０は、ストレージ装置２０内に例えば４個や８個等のように複数個設けることができる。各DKA１２０は、各ディスクドライブ１００との間のデータ通信をそれぞれ制御する。各DKA１２０と各ディスクドライブ１００とは、例えば、SAN等の通信ネットワークＣＮ１２を介して接続され、ファイバチャネルプロトコルに従ってブロック単位のデータ転送を行う。各DKA１２０は、各ディスクドライブ１００の状態を随時監視しており、この監視結果は、LAN等の内部ネットワークＣＮ１１を介して、SVP２８に送信される。

各CHA１１０及び各DKA１２０は、例えば、プロセッサやメモリ等が実装されたプリント基板と、メモリに格納された制御プログラム（いずれも不図示）とをそれぞれ備えており、これらのハードウェアとソフトウェアとの協働作業によって、それぞれ所定の機能を実現するようになっている。

キャッシュメモリ１３０は、例えば、ユーザデータ等を記憶するものである。キャッシュメモリ１３０は、例えば不揮発メモリから構成される。

共有メモリ（あるいは制御メモリ）１４０は、例えば不揮発メモリから構成される。共有メモリ１４０には、例えば、制御情報や管理情報等が記憶される。これらの制御情報等の情報は、複数の共有メモリ１４０により多重管理することができる。共有メモリ１４０及びキャッシュメモリ１３０は、それぞれ複数個設けることができる。

ここで、同一のメモリ基板にキャッシュメモリ１３０と共有メモリ１４０とを混在させて実装することもできる。あるいは、メモリの一部をキャッシュ領域として使用し、他の一部を制御領域として使用することもできる。

スイッチ部１５０は、各CHA１１０と、各DKA１２０と、キャッシュメモリ１３０と、共有メモリ１４０とをそれぞれ接続するものである。これにより、全てのCHA１１０，DKA１２０は、キャッシュメモリ１３０及び共有メモリ１４０にそれぞれアクセス可能である。スイッチ部１５０は、例えば超高速クロスバスイッチ等として構成することができる。

SVP２８は、内部ネットワークＣＮ１１を介して、各CHA１１０及び各DKA１２０とそれぞれ接続されている。SVP２８は、例えば、CHA１１０を経由して、共有メモリ１４０にアクセス可能である。また、SVP２８は、通信ネットワークＣＮ１を介して、監視サーバ４０及び管理サーバ５０に接続されている。SVP２８は、ストレージ装置２０内部の各種状態を収集し、監視サーバ４０または管理サーバ５０に送信する。なお、SVP２８は、ストレージ装置２０の筐体内に設けられている必要はなく、筐体外に設けることもできる。

次に、図５〜図１１に基づいて、各情報Ｔ１〜Ｔ８の一例を説明する。図５（ａ）には、ホスト性能情報Ｔ１の構成が示されている。ホスト性能情報Ｔ１は、例えば、各サーバ１０の名称（ホスト名）と、デバイスファイル名と、性能情報収集時刻と、単位時間当たりのＩ／Ｏ量とを対応付けることにより構成可能である。ホスト名「H1」で特定されるサーバ１０は、２個のデバイスファイル「/dev/dsk/xxx」，「/dev/dsk/yyy」を備えており、これら各デバイスファイル毎に、それぞれ１０分間隔で単位時間あたりのＩ／Ｏ量が収集され、記憶される。

例えば、一方のデバイスファイル「/dev/dsk/xxx」では、時刻１０：００（２４時間表記）において、１秒間に５０００バイトのＩ／Ｏが発生している。また、同デバイスファイルの単位時間当たりのＩ／Ｏ量は、その１０分後に１０００バイト増加し、６０００（バイト／秒）となっている。他方のデバイスファイル「dev/dsk/yyy」では、時刻１０：００において、１秒間に１０００バイトのＩ／Ｏが発生している。また、同デバイスファイルの単位時間当たりのＩ／Ｏ量は、その１０分後も変化していない。

図５（ｂ）に示すスイッチ性能情報Ｔ２は、例えば、スイッチ名と、ポート名と、性能情報収集時刻と、単位時間当たりのＩ／Ｏ量とを対応付けることにより構成可能である。図２に示すように、スイッチ名「SW-A」で特定されるスイッチ３０において、ポート名「Ａ１」で特定されるポートには、２個のデバイスファイル１３がそれぞれ接続されている。このポート「Ａ１」には、２個のデバイスファイル１３からのアクセス要求がそれぞれ流入する。従って、時刻１０：００において、ポート「Ａ１」の単位時間当たりのＩ／Ｏ量は、６０００（バイト／秒）となる。

図６（ａ）には、ストレージポート性能情報Ｔ３の構成が示されている。ストレージポート性能情報Ｔ３は、例えば、ストレージ装置名と、ストレージポート名と、性能情報収集時刻と、Ｉ／Ｏ量とを対応付けることにより構成することができる。図１に示すように、ストレージ装置名「ＳＳ１」で特定されるストレージ装置２０において、ポート名「CL0-A」で特定されるストレージポート２１には、パリティグループ「１−１」に属する２個のLDEV「０：１０」及び「０：２０」が接続されている。

ここで、一方のデバイスファイル「/dev/dsk/xxx」は一方のLDEV「０：１０」にアクセスし、他方のデバイスファイル「/dev/dsk/yyy」は他方のLDEV「０：２０」にアクセスしているものとする。従って、ストレージポート「CL0-A」には、両方のデバイスファイルからのアクセスが流入するため、時刻１０：００における単位時間当たりのＩ／Ｏ量は、６０００バイトとなっている。

図６（ｂ）には、パリティグループ性能情報Ｔ４の構成が示されている。パリティグループ性能情報Ｔ４は、例えば、ストレージ装置名と、パリティグループ名と、性能情報収集時刻と、単位時間当たりのＩ／Ｏ量とを対応付けることにより構成可能である。例えば、パリティグループ名「１−１」で特定されるパリティグループ２２は、２個のLDEV「０：１０」及び「０：２０」を有している。従って、このパリティグループ「１−１」の時刻１０：００における単位時間当たりのＩ／Ｏ量は、６０００バイトとなる。

図７には、LDEV性能情報Ｔ５の構成が示されている。LDEV性能情報Ｔ５は、例えば、ストレージ装置名と、LDEV名と、性能情報収集時刻と、単位時間当たりのＩ／Ｏ量とを対応付けることにより構成することができる。例えば、デバイスファイル「/dev/dsk/xxx」により使用されるLDEV「０：１０」では、時刻１０：００において、５０００（バイト／秒）のＩ／Ｏが発生している。また、デバイスファイル「/dev/dsk/yyy」により使用されるLDEV「０：２０」は、時刻１０：００において、１０００（バイト／秒）のＩ／Ｏを発生させている。

図８には、経路情報Ｔ６の構成が示されている。経路情報Ｔ６は、ストレージシステム内の各経路の構成を記憶するものである。経路情報Ｔ６は、例えば、ホスト名と、デバイスファイル名と、送信側のスイッチのポート名と、受信側のスイッチのポート名と、ストレージ装置名と、パリティグループ名と、ストレージ装置２０のポート名と、LDEV名とを対応付けることにより構成することができる。

例えば、デバイスファイル「/dev/dsk/xxx」から出されたアクセス要求は、スイッチ「SW-A」のポート「Ａ１」に入力されてポート「Ａ２」から出力される。このアクセス要求は、ポート「Ａ２」からスイッチ「SW-B」のポート「Ｂ１」に入力され、ポート「Ｂ２」から出力される。ポート「Ｂ２」から出力されたアクセス要求は、ストレージ装置２０のストレージポート「CL0-A」に入力され、LDEV「０：１０」に到達する。一方、他のデバイスファイル「/dev/dsk/yyy」も同様に、ポート「Ａ１」、ポート「Ａ２」、ポート「Ｂ１」、ポート「Ｂ２」、ストレージポート「CL0-A」を介して、LDEV「０：２０」に接続されている。

図９には、対策情報Ｔ７の構成が示されている。対策情報Ｔ７は、例えば、項番と、対策名と、影響範囲と、優先度とを対応付けることにより構成可能である。ここで、「影響範囲」とは、その対策による影響が及ぶ範囲を意味し、その対策を実施した場合にボトルネック解消効果が見込まれる範囲を示す情報である。即ち、本実施例の場合、「影響範囲」には、その対策を実施した場合に、単位時間当たりのＩ／Ｏ量が変化する可能性のある要素名が登録されている。

「対策名」とは、予め用意された複数の対策を識別するための情報である。詳細は後述するが、対策としては、例えば、「アプリケーションプログラム１１が使用するLDEVの変更」、「アプリケーションプログラム１１が稼働するホストの変更」、「アプリケーションプログラム１１が使用するLDEVの所属先パリティグループの変更」等を挙げることができる。対策情報Ｔ７に記憶されている各対策は、取り得る対策の種類を示すもので、具体的な対策内容は示されていない。例えば、「アプリケーションプログラム１１が使用するLDEVを変更する」という対策は、LDEVの変更によってボトルネックを解消する可能性があることを示すのみで、具体的にどのLDEV２３をどのLDEV２３に変更するか等の情報を含んでいない。従って、対策情報Ｔ７に記憶される各対策は、例えば、「対策案」、「対策種別」、「対策方針」等と呼ぶこともできる。以下の説明では、説明の便宜上、上述の各対策を「LDEV変更」、「ホスト変更」、「パリティグループ変更」とそれぞれ略記する。

「優先度」とは、各対策の検討順序を示す情報である。優先度の数字が小さいほど、高い優先順位を有する。例えば、「LDEV変更」には優先度「１」が、「ホスト変更」には優先度「２」が、「パリティグループ変更」には優先度「３」が設定されている。検討部５２は、ボトルネックの解消に際して、高い優先度を有する対策から順番に有効性を検討していく。従って、ボトルネックの発生箇所等によっても相違するが、高い優先度を有する対策であるほど、実施される可能性が高い。

各対策による影響範囲について簡単に述べると、「LDEV変更」は、スイッチポート３１と、ストレージポート２１と、パリティグループ２２と、LDEV２３とに、この順番で影響を与える可能性がある。但し、この順序で影響度合が弱まるとは限らない。また、本実施例は、この順序に制限されるものではない。「ホスト変更」は、これらに加えて、デバイスファイル１３にも影響を与える可能性がある。「パリティグループ変更」は、「LDEV変更」と同様の要素に影響を与える可能性がある。

図１０及び図１１は、閾値情報Ｔ８の構成を示す。閾値情報Ｔ８は、各要素毎にそれぞれ用意することができる。ボトルネック発生前の状態を検出できるように、各要素の閾値を設定すれば、ボトルネックが実際に発生するよりも前に、ボトルネック発生の可能性を予測することができる。

図１０（ａ）に示すように、ホスト閾値情報Ｔ８（１）は、例えば、ホスト名と、デバイスファイル名と、閾値とを対応付けることにより構成することができる。各デバイスファイル１３に共通の閾値を設定することもできるし、それぞれ異なる閾値を設定することもできる。

図１０（ｂ）に示すように、スイッチ閾値情報Ｔ８（２）は、例えば、スイッチ名と、ポート名と、閾値とを対応付けることにより構成可能である。前記同様に、各スイッチポートに共通の閾値を設定してもよいし、それぞれ異なる閾値を設定してもよい。

図１０（ｃ）に示すように、ストレージポート閾値情報Ｔ８（３）は、例えば、ストレージ装置名と、ポート名と、閾値とを対応付けることにより構成可能である。各ストレージポートに共通の閾値を設定することもできるし、それぞれ異なる閾値を設定することもできる。

図１１（ａ）に示すように、パリティグループ閾値情報Ｔ８（４）は、例えば、ストレージ装置名と、パリティグループ名と、閾値とを対応付けることにより構成することができる。前記同様に、各パリティグループに共通の閾値を設定してもよいし、それぞれ異なる閾値を設定してもよい。

図１１（ｂ）に示すように、LDEV閾値情報Ｔ８（５）は、例えば、ストレージ装置名と、LDEV名（LDEV番号）と、閾値とを対応付けることにより構成可能である。各LDEVに共通の閾値を設定してもよいし、それぞれ異なる閾値を設定してもよい。

図１２は、管理サーバ５０により実行されるボトルネック検出処理の概要を示すフローチャートである。ボトルネック検出処理を実行する前の前提として、管理サーバ５０は、各要素の負荷状態（単位時間当たりのＩ／Ｏ量）を所定周期でそれぞれ収集し、データベース５４に登録している。ボトルネック検出処理は、性能情報の収集サイクルに合わせて実行することができる。

管理サーバ５０は、まず最初に、データベース５４から最新のホスト性能情報Ｔ１を読込み（Ｓ１１）、各デバイスファイル１３の単位時間当たりのＩ／Ｏ量が所定の閾値以上であるか否かを判定する（Ｓ１２）。所定の閾値以上のデバイスファイル１３が検出された場合（S12：YES）、管理サーバ５０は、その高負荷状態のデバイスファイル１３について、ボトルネック検出フラグをセットする（Ｓ１３）。ボトルネック検出フラグとは、その要素が現在ボトルネックである状態、またはボトルネックとなる可能性がある状態を示す情報である。

ホスト性能情報Ｔ１について検査を終えた後、管理サーバ５０は、データベース５４から最新のスイッチ性能情報Ｔ２を読込み（Ｓ１４）、各スイッチポート３１の単位時間当たりのＩ／Ｏ量が所定の閾値以上になったか否かを判定する（Ｓ１５）。所定の閾値以上のスイッチポート３１が検出された場合（S15：YES）、管理サーバ５０は、そのスイッチポート３１について、ボトルネック検出フラグをセットする（Ｓ１６）。

スイッチ性能情報Ｔ２について検査を終えた後、管理サーバ５０は、データベース５４から最新のストレージポート性能情報Ｔ３を読み込む（Ｓ１７）。管理サーバ５０は、各ストレージポート２１の単位時間当たりのＩ／Ｏ量が所定の閾値以上であるか否かを判定する（Ｓ１８）。所定の閾値以上のＩ／Ｏ量が発生しているストレージポート２１を検出した場合（S18：YES）、管理サーバ５０は、このストレージポート２１にボトルネック検出フラグをセットする（Ｓ１９）。

管理サーバ５０は、データベース５４から最新のパリティグループ性能情報Ｔ４を読込み（Ｓ２０）、単位時間当たりのＩ／Ｏ量が所定の閾値以上となっているパリティグループ２２が存在するか否かを判定する（Ｓ２１）。所定の閾値以上のパリティグループ２２が検出された場合（S21：YES）、管理サーバ５０は、このパリティグループ２２について、ボトルネック検出フラグをセットする（Ｓ２２）。

管理サーバ５０は、最新のLDEV性能情報Ｔ５を読込み（Ｓ２３）、単位時間当たりのＩ／Ｏ量が所定の閾値以上となっているLDEV２３が存在するか否かを判定する（Ｓ２４）。所定の閾値以上のLDEV２３が検出された場合（S24：YES）、管理サーバ５０は、このLDEV２３について、ボトルネック検出フラグをセットする（Ｓ２５）。

以上のように、管理サーバ５０は、各要素の最新の性能情報に基づいて、各監視対象の要素にボトルネックが存在するか否かを判定し、ボトルネックとなっている要素を検出する。各要素から収集される性能情報が更新された場合、管理サーバ５０は、図１２に示すボトルネック検出処理を改めて実行することができる。

図１３は、管理サーバ５０によるボトルネックの解析処理（対策検討処理）の概要を示すフローチャートである。この解析処理は、ボトルネック検出処理の完了に合わせて実行することができる。

管理サーバ５０は、ボトルネックが検出されたか否かを判定する（Ｓ３１）。ボトルネック検出フラグがセットされている場合は、ストレージシステム内でボトルネックが検出されたことを示している。

ボトルネックが検出された場合（S31：YES）、管理サーバ５０は、経路情報Ｔ６を参照することにより、ボトルネックとなっている要素にＩ／Ｏを発生させているデバイスファイル１３を特定する（Ｓ３２）。上述のように、経路情報Ｔ６には、ストレージシステム内の各経路毎に、各要素の接続関係がそれぞれ記録されている。なお、デバイスファイル１３自体がボトルネックとなっている場合は、このデバイスファイル１３がボトルネック発生原因のデバイスファイルとして特定される。

管理サーバ５０は、ボトルネックを発生させているデバイスファイル１３の最新の単位時間当たりのＩ／Ｏ量を確認する（Ｓ３３）。次に、管理サーバ５０は、高い優先度を有する対策から順番に、シミュレートする。本実施例では、「LDEV変更」に最も高い優先度が与えられているため、管理サーバ５０は、まず最初に、「LDEV変更」を選択する（Ｓ３４）。管理サーバ５０は、LDEV２３の変更による対策がボトルネックの解消に有効であるか否かをシミュレートする（Ｓ３５）。このシミュレーション処理については、さらに後述する。

管理サーバ５０は、「LDEV変更」対策を実施することによりボトルネックが解消されるか否かを判定する（Ｓ３６）。ボトルネックが解消されると判断した場合（S36：YES）、管理サーバ５０は、この「LDEV変更」の具体的な変更方法について、ユーザに提示する（Ｓ３７）。システム管理者等のユーザは、管理サーバ５０から提案された具体的な対策内容を検討することができる。管理サーバ５０から提案された具体的対策を採用する場合、ユーザは、所定のタイミングを見計らって、ストレージシステムの構成を変更することができる。

例えば、管理サーバ５０によって検出されたボトルネックが一時的、過渡的なものに過ぎず、放置しても特に問題が無いような場合、ユーザは、管理サーバ５０からの提案を無視することができる。これとは逆に、例えば、管理サーバ５０によって検出されたボトルネックが長期的、定常的なものであり、ストレージシステムの性能に悪影響を及ぼすような場合、ユーザは、直ちにまたは所望のタイミングで、ストレージシステムの構成を変更することができる。

「LDEV変更」対策によってボトルネックを解消できない場合（S36：NO）、管理サーバ５０は、次に優先度の高い対策を選択する（Ｓ３８）。本実施例では、「ホスト変更」対策の有効性が検討される（Ｓ３９）。Ｓ３９のシミュレーション処理については、さらに後述する。管理サーバ５０は、この第２の対策でボトルネックを解消可能か否かを判定する（Ｓ４０）。「ホスト変更」対策によってボトルネックを解消可能な場合（S40：YES）、管理サーバ５０は、具体的な対策内容をユーザに提案する（Ｓ４１）。この提案には、例えば、アプリケーションプログラム１１を実行させるサーバをどのサーバ１０に移すべきか等の情報を含めることができる。前記同様に、ユーザは、管理サーバ５０からの具体的な提案を検討し、この提案を採用する場合は、所定のタイミングを見計らって実行に移すことができる。

第２の対策もボトルネック解消に有効でないと判断された場合（S40：NO）、管理サーバ４０は、対策情報Ｔ７に予め登録されている全ての対策を検討したか否かを判定する（Ｓ４２）。本実施例では、第３の対策として「パリティグループ変更」を用意しているので、次に、「パリティグループ変更」対策が選択され（S42：NO，S38）、前記同様にシミュレーション等が行われる（Ｓ３９〜Ｓ４１）。

第３の対策をシミュレーションした結果、「パリティグループ変更」対策もボトルネック解消に有効ではないと判断された場合（S40：NO）、管理サーバ５０は、予め用意された全ての対策について検討を終えたことになる（S42：YES）。そこで、管理サーバ５０は、ボトルネックの検出のみをユーザに通知する（Ｓ４３）。この通知を受けたユーザは、ストレージ装置の増設や新製品への置換等を検討することができる。

図１４〜図１６に基づき、各対策のシミュレーション方法を説明する。図１４は、「LDEV変更」対策のシミュレーション処理を示すフローチャートである。管理サーバ５０は、Ｉ／Ｏ発生元のデバイスファイル１３（大元のデバイスファイル１３または原因発生元デバイスファイル１３と呼ぶ）により使用されているLDEVを移動可能な全てのLDEV２３を検出する（Ｓ５１）。移動可能なLDEV２３としては、例えば、（１）別のサーバ１０やアプリケーションプログラム１１によりアクセスロックが設定されていないこと、（２）大元のデバイスファイル１３のＩ／Ｏ量が加わっても支障を生じないこと等の条件を満たすLDEV２３を挙げることができる。

管理サーバ５０は、リストアップされた全ての移動先候補LDEVのうち、第１番目の移動先候補LDEVを選択する（Ｓ５２）。次に、管理サーバ５０は、経路情報Ｔ６を参照し、第１の移動先候補LDEVと大元のデバイスファイル１３との間の経路を検索する（Ｓ５３）。即ち、大元のデバイスファイル１３のアクセス先LDEVを第１の移動先候補LDEVに移動させた場合の経路を検索する。以下、ボトルネックとなっているLDEV２３と大元のデバイスファイル１３との間の現在の経路に対し、移動先候補LDEV２３と大元のデバイスファイル１３との間の経路を新経路と呼ぶ。

管理サーバ５０は、スイッチ性能情報Ｔ２〜LDEV性能情報Ｔ５の４つのテーブルをコピーすることにより、シミュレーション用テーブルを生成する（Ｓ５４）。ここで、ホスト性能情報Ｔ１のコピーは用意する必要はない。図９と共に述べたように、「LDEV変更」対策は、デバイスファイル１３の性能に影響を与えないため、デバイスファイル１３についてのシミュレーションは省略される。つまり、管理サーバ５０は、その対策が影響を及ぼす範囲内でシミュレーションを行うために、事前準備をする。以下のシミュレーションは、コピーされたテーブル上でＩ／Ｏ量を加減算することにより行われる。

管理サーバ５０は、現在の経路上に位置する各要素から、移動予定のＩ／Ｏ量をそれぞれ減算する（Ｓ５５）。移動予定のＩ／Ｏ量とは、大元のデバイスファイル１３によって発生している現在のＩ／Ｏ量である。次に、管理サーバ５０は、減算したＩ／Ｏ量を、新経路上に位置する各要素にそれぞれ加算する（Ｓ５６）。

管理サーバ５０は、現在の経路上に存在するボトルネックが解消するか否かを判定する（Ｓ５７）。ボトルネックが解消すると判断した場合（S57：YES）、管理サーバ５０は、新たにＩ／Ｏ量が加算される各要素に新たなボトルネックが発生したか否かを判定する（Ｓ５８）。

新経路上の要素に新たなボトルネックが発生しない場合（S58：NO）、管理サーバ５０は、この移動先候補LDEV２３を「LDEV変更」対策に使用するLDEVとして決定する（Ｓ５９）。

一方、現在のＩ／Ｏ量を移動先候補LDEV２３に移し替えても、現在発生しているボトルネックが解消しない場合（S57：NO）、他の移動先候補LDEV２３について検討する必要がある。また、Ｉ／Ｏ量を移動させることにより新たなボトルネックが発生した場合（S58：YES）も、他の移動先候補LDEV２３について検討する必要がある。

管理サーバ５０は、Ｓ５１で抽出された全ての移動先候補LDEV２３について、シミュレート済であるか否かを判定する（Ｓ６０）。未検討の移動先候補LDEV２３が残っている場合（S60：NO）、管理サーバ５０は、検討対象の移動先候補LDEV２３を切り替えて（Ｓ６１）、Ｓ５３に戻る。

このようにして、管理サーバ５０は、リストアップされた移動先候補LDEV２３について、シミュレーションを繰り返す。現在発生中のボトルネックが解消され、かつ、新たなボトルネックが発生しないと判断された場合、管理サーバ５０は、その移動先候補LDEV２３を選択する。

リストアップされた全ての移動先候補LDEV２３についてシミュレーションを完了した場合でも、適切な移動先候補LDEV２３を検出できないときは（S60：YES）、このLDEV変更シミュレーションを終了し、図１３に示す処理に戻る。この場合、管理サーバ５０は、別の対策についてシミュレーションを行うことになる。

次に、図１５は、「ホスト変更」対策のシミュレーション処理を示すフローチャートである。このシミュレーション処理は、図１４の処理と基本構造は同一である。主な相違点は、シミュレーション対象が「デバイスファイル」となっている点等である。

管理サーバ５０は、移動先候補ホスト（移動先候補のデバイスファイル）を全て検出する（Ｓ７１）。管理サーバ５０は、ボトルネックの発生原因となっている現在のデバイスファイル１３の代わりに、使用可能な別のデバイスファイル１３を全て抽出する。例えば、どのアプリケーションプログラム１１からも使用されていないデバイスファイル１３等が検出される。

管理サーバ５０は、リストアップされた移動先候補ホストのうち、リストの先頭に位置する第１の移動先候補ホストを選択する（Ｓ７２）。管理サーバ５０は、経路情報Ｔ６を参照することにより、移動先候補ホストと目標LDEV２３とを結ぶ新たな経路を検索する（Ｓ７３）。目標LDEV２３とは、ボトルネック原因のＩ／Ｏを発生させている現在のデバイスファイル１３（大元のデバイスファイル１３）が現在利用しているLDEV２３を示す。

管理サーバ５０は、シミュレーション用のテーブルを用意する（Ｓ７４）。ここで、図９に示すように、「ホスト変更」対策の影響は、デバイスファイル１３，スイッチポート３１，ストレージポート２１，パリティグループ２２及びLDEV２３に及ぶ。従って、管理サーバ５０は、ホスト性能情報Ｔ１，スイッチ性能情報Ｔ２，ストレージポート性能情報Ｔ３，パリティグループ性能情報Ｔ４，LDEV性能情報Ｔ５のそれぞれについてコピーを生成し、シミュレーションの準備を整える。

以下、前記同様に、シミュレーション用の各テーブル上でＩ／Ｏ量を加減算することにより、シミュレーションを実行する。まず、管理サーバ５０は、現在の経路上に位置する各要素から、移動予定のＩ／Ｏ量（大元のデバイスファイル１３が発生させている単位時間当たりのＩ／Ｏ量）をそれぞれ減算する（Ｓ７５）。次に、管理サーバ５０は、Ｓ７３で検索された新経路上に位置する各要素について、移動予定のＩ／Ｏ量をそれぞれ加算する（Ｓ７６）。

そして、管理サーバ５０は、現在発生しているボトルネックが解消するか否かを判定する（Ｓ７７）。現在のボトルネックが解消すると判断した場合（S77：YES）、管理サーバ５０は、新経路上に位置する各要素に、新たなボトルネックが発生するか否かを判定する（Ｓ７８）。新経路上の各要素に新たなボトルネックが発生しないと判定した場合（S78：NO）、管理サーバ５０は、この移動先候補ホストを適切なホストとして選択する（Ｓ７９）。

これに対し、ホスト（デバイスファイル１３）を変更しても現在のボトルネックが解消されない場合（S77：NO）は、別の移動先候補ホストについてシミュレーションを行う必要がある。また、ホストを変更すると、別の新たなボトルネックを生じる場合（S78：YES）も、別の移動先候補ホストについてシミュレーションを行う必要がある。

そこで、管理サーバ５０は、全ての移動先候補ホストについてシミュレート済みであるか否かを判定する（Ｓ８０）。未検討の移動先候補ホストが存在する場合（S80：NO）、管理サーバ５０は、シミュレーション対象のホストを切り替えて（Ｓ８１）、Ｓ７３に戻り、上述の処理を繰り返す。全ての移動先候補ホストについてシミュレートした結果、適切なホストが検出されなかった場合（S80：YES）、管理サーバ５０は、図１３に示す処理に戻る。

図１６は、「パリティグループ変更」対策のシミュレーション処理を示すフローチャートである。図中では、パリティグループを「ＰＧ」と略記する。本実施例では、「パリティグループ変更」の優先度を最も低く設定している。従って、「LDEV変更」対策や「ホスト変更」対策によってボトルネック解消法が発見されなかった場合に、「パリティグループ変更」対策の有効性が検討される。

「パリティグループ変更」対策のシミュレーション処理は、図１４に示す「LDEV変更」対策のシミュレーション処理と基本構造は同一である。相違点は、シミュレーション対象が「LDEV２３」から「パリティグループ２２」に変更されている点にある。

まず、管理サーバ５０は、移動先候補のパリティグループ２２を全て検出し（Ｓ９１）、第１の移動先候補パリティグループ２２を選択する（Ｓ９２）。管理サーバ５０は、ボトルネック発生原因となったＩ／Ｏを発生させている大元のデバイスファイル１３と移動先候補パリティグループ２２との間の新経路を検出する（Ｓ９３）。

管理サーバ５０は、情報Ｔ２〜Ｔ５をそれぞれコピーすることにより、シミュレーション用のテーブルを作成する（Ｓ９４）。管理サーバ５０は、前記各処理と同様に、現在の経路上に位置する各要素の最新のＩ／Ｏ量から、移動予定のＩ／Ｏ量をそれぞれ減算する（Ｓ９５）。そして、管理サーバ５０は、新経路上に位置する各要素の最新のＩ／Ｏ量に、移動予定のＩ／Ｏ量をそれぞれ加算する（Ｓ９６）。

大元のデバイスファイル１３に関連するＩ／Ｏ量を移動させた後、管理サーバ５０は、現在発生しているボトルネックが解消されたか否かを判定する（Ｓ９７）。続いて、管理サーバ５０は、新経路上の各要素に新たなボトルネックが発生したか否かを判定する（Ｓ９８）。

現在のボトルネックが解消され（S97：YES）、かつ、新たなボトルネックが発生しない場合（S98：NO）、管理サーバ５０は、この移動先候補パリティグループ２２を、移動先として適切なパリティグループ２２であると判断し、選択する（Ｓ９９）。

現在のボトルネックが解消されない場合（S97：NO）または新たなボトルネックが発生する場合（S98：YES）のいずれかの場合、管理サーバ５０は、未検討の移動先候補パリティグループ２２を全て検討するまで、Ｓ９３〜Ｓ９８の処理を繰り返す（Ｓ１００，Ｓ１０１）。

図１７は、シミュレーション用テーブルを用いたシミュレーション方法の一部を示す説明図である。図１７では、「LDEV変更」対策のシミュレーション処理を例に挙げて説明する。図７も適宜参照しながら説明する。

図１７（ａ）は、大元のデバイスファイル１３に関連するＩ／Ｏ量を減算した様子を示している。ここでは、デバイスファイル（/dev/dsk/xxx）がボトルネック要因のＩ／Ｏを発生させているものとする。図７に示すように、この大元のデバイスファイル（/dev/dsk/xxx）は、時刻１０：１０において、LDEV（０：１０）に対し、１秒間あたり６０００バイトのＩ／Ｏを発生させている。

図１７（ａ）に示すように、LDEV（０：１０）の変更を検討するに際し、管理サーバ５０は、大元のデバイスファイルが発生させているＩ／Ｏ量（６０００バイト／秒）を、移動元LDEV（０：１０）から減算する。従って、移動元LDEV（０：１０）のＩ／Ｏ量は、「０」となる。

移動先候補LDEVをLDEV（０：２０）とする。図１７（ｂ）に示すように、管理サーバ５０は、移動予定のＩ／Ｏ量（６０００バイト／秒）を、移動先候補LDEV（０：２０）の最新のＩ／Ｏ量（１０００バイト／秒）に加算する。従って、移動先候補LDEV（０：２０）の予想Ｉ／Ｏ量は、７０００バイト／秒となる。この予想Ｉ／Ｏ量が、移動先候補LDEV（０：２０）に設定されている閾値を超えない場合は、LDEV（０：１０）からLDEV（０：２０）への変更が許容される。予想Ｉ／Ｏ量がLDEV（０：２０）の閾値を超える場合は、このLDEV変更は許可されない。

本実施例は上述のように構成されるので、以下の効果を奏する。本実施例では、ストレージシステムを構成する各要素の性能状態を監視してボトルネックを検出し、このボトルネックを解消するための対策を発見できる構成とした。従って、ストレージシステム全体の状況を考慮して適切な対策を立案することができる。

本実施例では、情報処理経路上の両端に位置する各要素（デバイスファイル１３，LDEV２３，パリティグループ２２）を他の要素に変更させることにより、ボトルネックを解消する構成とした。即ち、情報処理経路上の中間でボトルネックが発生した場合でも、経路の中間部分の構成を直接変更するのではなく、経路の両端の構成を変更することにより、ボトルネックを解消する構成とした。従って、比較的簡単な操作で、ボトルネックを解消可能である。

本実施例では、ストレージシステムの構成変更を行う前に、ボトルネック（ボトルネックの可能性）を検出し、このボトルネックを解消するための対策をシミュレートする構成とした。従って、ディスク増設やストレージ装置のリプレース等を実際に行う前に、このような構成変更がボトルネック解消に及ぼす効果を事前に評価可能である。即ち、新規増設予定のディスクやストレージ装置に関する新たな要素（デバイスファイル、LDEV、ストレージポート、スイッチポート、パリティグループ等）を、シミュレーション用の各テーブルに仮想的に登録することで、実際の増設やリプレース等を行わずに、性能改善効果を評価可能である。

なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、各実施例を適宜組み合わせることができる。

例えば、ストレージシステムを構成する個別の要素をそれぞれ監視するのではなく、各要素を種類別に分類してグループ化し、各グループ単位で監視する構成でもよい。即ち、サーバ内の各要素やストレージ装置内の各要素についてそれぞれ個別に監視するのではなく、例えば、サーバ全体の性能状態、スイッチ群（ファブリック）全体の性能状態、ストレージ装置全体の性能状態を、サマリーデータとしてそれぞれ検出することができる。例えば、サーバのサマリーデータ（サーバ全体の単位時間当たりのＩ／Ｏ量）は、各デバイスファイルのＩ／Ｏ量の総和として求めることができる。このように、グループ単位で管理することにより、ストレージシステム全体の状況をより大きな視点で速やかに把握することができる。

本発明の実施形態の概念を示す説明図である。 ストレージシステムの全体構成を示すブロック図である。 管理サーバの構成を示すブロック図である。 ストレージ装置の構成を示すブロック図である。 （ａ）はホスト性能情報の構成を、（ｂ）はスイッチ性能情報の構成をそれぞれ示す説明図である。 （ａ）はストレージポート性能情報の構成を、（ｂ）はパリティグループ性能情報の構成をそれぞれ示す説明図である。 LDEV性能情報の構成を示す説明図である。 経路情報の構成を示す説明図である。 対策情報の構成を示す説明図である。 （ａ）はホスト閾値情報の構成を、（ｂ）はスイッチ閾値情報の構成を、（ｃ）はストレージポート閾値情報の構成をそれぞれ示す説明図である。 （ａ）はパリティグループ閾値情報の構成を、（ｂ）はLDEV閾値情報の構成をそれぞれ示す説明図である。 ボトルネック検出処理を示すフローチャートである。 解析処理を示すフローチャートである。 LDEV変更対策のシミュレーション処理を示すフローチャートである。 ホスト変更対策のシミュレーション処理を示すフローチャートである。 パリティグループ変更対策のシミュレーション処理を示すフローチャートである。 テーブル操作によってシミュレーションを行う様子を部分的に示す説明図である。

符号の説明

Ｎ１〜Ｎ１０…要素、１０…アプリケーションサーバ、１１…アプリケーションプログラム、１２…ファイルシステム、１３…デバイスファイル、１４…通信ポート、１５…ホスト情報収集部、２０…ストレージ装置、２１…ストレージポート、２２…パリティグループ、２３…LDEV（論理ボリューム）、３０…スイッチ、３１…スイッチポート、４０…監視サーバ、４１…スイッチ情報収集部、４２…ストレージ情報収集部、５０…管理サーバ、５１…ボトルネック検出部、５２…検討部、５２Ａ…データ量算出部、５２Ｂ…シミュレーション対象設定部、５２Ｃ…シミュレーション部、５３…対策提示部、５４…性能情報データベース、６０…クライアント端末、１００…ディスクドライブ、１１０…チャネルアダプタ、１２０…ディスクアダプタ、１３０…キャッシュメモリ、１４０…共有メモリ、１５０…スイッチ部、１６０…サービスプロセッサ、ＣＮ…通信ネットワーク、Ｔ１…ホスト性能情報、Ｔ２…スイッチ性能情報、Ｔ３…ストレージポート性能情報、Ｔ４…パリティグループ性能情報、Ｔ５…LDEV性能情報、Ｔ６…経路情報、Ｔ７…対策情報、Ｔ８…閾値情報

Claims (8)

1. 複数の論理ボリュームを有するストレージ装置と、このストレージ装置に接続され、前記各論理ボリュームにアクセスするためのアクセス処理部を有するホストコンピュータと、前記ストレージ装置及び前記ホストコンピュータにそれぞれ接続された管理用コンピュータと、を備えたストレージシステムにおいて、
   前記ホストコンピュータから前記ストレージ装置までの通信経路上に存在する各要素の性能に関する性能情報をそれぞれ収集する性能情報収集部と、
   前記収集された前記各要素の性能情報に基づいて、性能改善上の障害を有する障害要素を検出する障害要素検出部と、
   前記検出された障害要素の障害内容に基づいて対策を検討し、前記障害に有効な対策を選択する検討部と、
   を備え、
   前記検討部により検討される対策は、前記障害要素に関連する前記論理ボリューム及び前記アクセス処理部の少なくともいずれか一方を、他の論理ボリュームまたは他のアクセス処理部に変更させるものであるストレージシステム。
2. 前記検討部により選択された対策をユーザに提示する提示部を備えた請求項１に記載のストレージシステム。
3. 前記検討部は、予め用意された複数の対策の全部または一部について前記障害に対する有効性を評価することにより、前記障害に有効な対策を選択する請求項１に記載のストレージシステム。
4. それぞれ異なる優先度を有する複数の対策を予め記憶する記憶部を設け、
   前記検討部は、前記複数の対策のうち優先度の高い対策から順番に、前記障害に対する有効性を評価し、前記障害に有効な対策を発見した場合は、この対策を選択する請求項１に記載のストレージシステム。
5. それぞれ異なる優先度を有する複数の対策のそれぞれについて、その対策により影響を受ける要素の範囲を予め関連付けておき、
   前記検討部は、前記複数の対策のうち優先度の高い対策から順番に、その対策に予め関連付けられた前記要素の範囲内で前記障害に対する有効性を評価し、前記障害に有効な対策を発見した場合は、この対策を選択する請求項１に記載のストレージシステム。
6. 前記通信経路上に存在する各要素には、前記論理ボリュームと、前記アクセス処理部と、前記ストレージ装置と前記ホストコンピュータとの間のデータを中継する中継装置とが含まれている請求項１に記載のストレージシステム。
7. 複数の論理ボリュームを有するストレージ装置と、このストレージ装置に接続され、前記各論理ボリュームにアクセスするためのアクセス処理部を有するホストコンピュータと、前記ストレージ装置及び前記ホストコンピュータにそれぞれ接続された管理用コンピュータと、を備えたストレージシステムの障害を解消するための方法であって、
   前記ホストコンピュータから前記ストレージ装置までの通信経路上に存在する各要素の性能に関する性能情報をそれぞれ収集するステップと、
   前記収集された前記各要素の性能情報に基づいて、性能改善上の障害を有する障害要素を検出するステップと、
   前記検出された障害要素の障害内容に基づいて、前記障害要素に関連する前記論理ボリューム及び前記アクセス処理部の少なくともいずれか一方を他の論理ボリュームまたは他のアクセス処理部に変更させる対策を選択するステップと、
   前記選択された対策をユーザに提示するステップと、
   を含むストレージシステムの障害解消方法。
8. データを格納する複数のデータ格納先要素と、これら各データ格納先要素に格納されるデータにアクセスする複数のデータ利用元要素と、前記各データ格納先要素と前記各データ利用元要素との間に設けられる少なくとも一つ以上の中継要素と、前記各データ利用元要素から前記中継要素を介して前記各データ格納先要素に至る経路とを含む情報処理システムであって、
   前記各要素の性能に関する情報をそれぞれ収集する性能情報収集部と、
   前記収集された性能に関する情報に基づいて、性能改善上の障害を有する障害要素を検出する障害要素検出部と、
   前記検出された障害要素の障害内容を検討し、前記各データ利用元要素及び前記各データ格納先要素のうち前記障害要素に関連するデータ利用元要素またはデータ格納先要素の少なくともいずれか一方を他のデータ利用元要素または他のデータ格納先要素に変更させる対策を少なくとも一つ以上シミュレートすることにより、前記障害に有効な対策を選択する検討部と、
   前記選択された対策を提示する提示部と、
   を備えた情報処理システム。

Images