JP5987104B2 - 計算機システム、ストレージシステムの管理システム及び管理方法 - Google Patents

Description

本発明は、複数のマイクロプロセッサを有するストレージシステムの管理に関する。

一般に、ストレージシステムは、論理記憶デバイスを生成し、生成した論理記憶デバイスをホスト計算機に提供する。ホスト計算機では、その論理記憶デバイスが論理ボリュームとして認識される。論理ボリュームに対してデータのＩ／Ｏ（Input/Output）が生じると、その論理ボリュームに対応した論理記憶デバイスを指定したＩ／Ｏ要求がホスト計算機からストレージシステムに送信される。ストレージシステムは、そのＩ／Ｏ要求を受信し、そのＩ／Ｏ要求で指定されている論理記憶デバイスに対するＩ／Ｏを行う。

一般的に、論理記憶デバイスに対するＩ／Ｏは、マイクロプロセッサ（ＭＰ）によって実行される。

特許文献１では、ホスト計算機に記憶されているアプリケーションプログラム（以下、アプリケーション）が認識している論理ボリュームと、ストレージシステムが管理している論理記憶デバイスとが、１対１で対応付けられている。また、特許文献１では、論理記憶デバイス毎に、Ｉ／Ｏを行う担当のＭＰが予め設定されている。すなわち、特許文献１では、ホスト計算機から或る論理記憶デバイスに対するＩ／Ｏ要求をストレージシステムが受信した場合には、その論理記憶デバイスを担当するＭＰが、そのＩ／Ｏ要求を処理する。

米国特許出願公開第２００８／０２６３１９０号明細書

近年、ストレージシステムでは、データが最終的に記憶される記憶デバイスとして、Ｉ／Ｏ性能の高い記憶デバイス、例えばＳＳＤ（Solid State Drive）のようなフラッシュメモリデバイスが採用されている。しかし、論理記憶デバイスが、Ｉ／Ｏ性能の高い記憶デバイスに基づいて作成されていても、その論理記憶デバイスを担当するＭＰの性能が原因で高いＩ／Ｏ性能が発揮されないことがあり得る。

この問題を避ける方法として、１つの論理記憶デバイスを複数のＭＰが担当する方法が考えられる。しかし、その方法を採用すると、論理記憶デバイスに対するＩ／Ｏ処理の一貫性を保つことが困難になる、又は、ＭＰの切り替えによるオーバーヘッドが生じるといった別の問題が生じ得る。

管理システムは、アプリケーションに提供される論理ボリュームを構成する、２以上の論理記憶デバイスを決定する。管理システムは、２以上の論理記憶デバイスに対する処理をそれぞれ担当する２以上のＭＰを決定する。管理システムは、１つの論理記憶デバイスに１つのＭＰが割り当てられるように、決定した２以上の論理記憶デバイスに決定した２以上のＭＰを割り当てる。管理システムは、例えば、１又は複数の計算機で構成されてよい。また、管理システムは、ストレージシステムの中にあっても外にあってもよいし、ホスト計算機の中にあっても外にあってもよい。

ストレージシステムが１つの論理記憶デバイスを１つのＭＰで担当するようになっていても、要求性能を発揮することが期待される論理ボリュームをホスト計算機のアプリケーションプログラムに提供することができる。

図１は、実施例１に係る計算機システムの構成図である。 図２は、実施例１に係る管理計算機３００の構成図である。 図３は、実施例１に係るＣＭ−ＰＫ２４０の構成図である。 図４は、実施例１に係るホスト計算機１００の構成図である。 図５は、実施例１に係る静的情報テーブル３１０４の構成の一例を示す。 図６は、実施例１に係るパリティグループ情報テーブル３１０５の構成の一例を示す。 図７は、実施例１に係る最大性能利用量テーブル３１０６の構成の一例を示す。 図８は、実施例１に係る入力情報テーブル３１０７の構成の一例を示す。 図９は、実施例１に係るオーナー権テーブル２４１３の構成の一例を示す。 図１０は、実施例１に係るＭＰ構成情報テーブル２４１５の一例を示す。 図１１は、実施例１に係るＰＧ構成情報テーブル２４１６の一例を示す。 図１２は、実施例１に係るＬＶＭ・ＬＤＥＶ番号対応テーブル１１０７の一例を示す。 図１３は、実施例１に係るボリューム作成処理の一例を示すフローチャートである。 図１４は、実施例１に係るＬＤＥＶ数決定処理の一例を示すフローチャートである。 図１５は、実施例１に係るＭＰ割当て処理の一例を示すフローチャートである。 図１６は、実施例２に係る管理計算機３００の構成図である。 図１７は、実施例２に係る動的情報テーブル３１０８の構成の一例を示す。 図１８は、実施例２に係るＭＰ割当て処理の一例を示すフローチャートである。 図１９は、実施例３に係る管理計算機３００の構成図である。 図２０は、実施例３に係る論理ボリューム再構成処理を含んだ処理の一例を示すフローチャートである。 図２１は、実施例４に係るＭＰ余剰性能テーブル３１１１の一例を示す。 図２２は、実施例４に係るボリューム作成中止処理の一例を示すフローチャートである。

以下、図面を用いて幾つかの実施例を説明する。

なお、以下に説明する実施例は特許請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

また、以下の説明では、「ａａａテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ａａａテーブル」を「ａａａ情報」と呼ぶことができる。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit）或いはＭＰ（Micro Processor））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インタフェースデバイス（例えばポート）を用いながら行うため、処理の主語がプログラムとされてもよい。プログラムを主語として説明された処理は、プロセッサ或いはそのプロセッサを有する計算機（例えば、管理計算機、ホスト計算機、ストレージ装置）が行う処理としてもよい。また、プロセッサは、プロセッサが行う処理の一部又は全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから各コントローラにインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであってもよい。

図１は、実施例１に係る計算機システムの構成図である。

計算機システムは、ストレージシステムと、ストレージシステムのホスト計算機１００と、管理計算機３００、とを有する。ホスト計算機１００は、１台でもよいし複数台であってもよい。ストレージシステムは、１以上のストレージ装置２００で構成されている。ストレージシステムは、１以上のストレージ装置２００が統合された１台の仮想的なストレージシステムでもよい。

ストレージ装置２００は、論理的な記憶デバイスであるＬＤＥＶ（Logical Device）をホスト計算機１００に対して提供する。ホスト計算機１００は、ＬＤＥＶを指定したＩ／Ｏ（Input/Output）要求（ライト要求又はリード要求）をストレージ装置２００に送信することで、ＬＤＥＶに対してデータの書き込み又は読み出しを行う。管理計算機３００は、ホスト計算機１００及びストレージ装置２００を管理する。

ホスト計算機１００とストレージ装置２００とは、ストレージネットワーク５００を介して接続される。ストレージネットワーク５００は、例えば、ＳＡＮ（Storage Area Network）である。ストレージネットワーク５００に代えて、他種の通信媒体（例えば、他種の通信ネットワーク、或いは、バス（例えばＰＣＩｅ（Peripheral Components Interconnect Express））が採用されてもよい。

また、ホスト計算機１００とストレージ装置２００は、管理ネットワーク４００を介して管理計算機３００と接続される。管理ネットワーク４００は、例えば、ＬＡＮ（Local Area Network）でもよいし専用回線でもよい。管理ネットワーク４００に代えて、他種の通信媒体（例えば、他種の通信ネットワーク、或いは、バス）が採用されてもよい。また、管理ネットワーク４００とストレージネットワーク５００は同一の通信媒体であってもよい。

ストレージシステムは、ホスト計算機１００との第１の通信インタフェースデバイスと、管理計算機３００との第２の通信インタフェースデバイスと、複数のＭＰ（Microprocessor）と、複数のＬＤＥＶとを有する。ＭＰは、ホスト計算機１００からのＩ／Ｏ要求から特定されたＬＤＥＶに対するデータのＩ／Ｏを行う。ＬＤＥＶは、実体的なＬＤＥＶであってもよいし、仮想的なＬＤＥＶであってもよい。実体的なＬＤＥＶは、１又は複数のＰＤＥＶ（Physical Device）に基づくＬＤＥＶであり、仮想的なＬＤＥＶは、Thin Provisioningに従うＬＤＥＶであってもよいし、ストレージ仮想化技術に従い外部のストレージリソースが仮想化されることにより生成されたＬＤＥＶであってもよい。本実施例では、いずれのＬＤＥＶも実体的なＬＤＥＶであるとする。

このようなストレージシステムは、例えば、前述したように、１又は複数のストレージ装置２００で構成される。

ストレージ装置２００は、ＦＥ−ＰＫ（Frontend package）２１０と、ＭＰ−ＰＫ（Microprocessor package）２２０と、ＢＥ−ＰＫ（Backend package）２３０と、ＣＭ−ＰＫ（Cachememory package）２４０と、内部ネットワーク２５０と、ＰＤＥＶユニット２６０と、を有する。

ＦＥ−ＰＫ２１０は、第１の通信インタフェースデバイスの一例であり、複数のＩ／Ｆ（Interface）２１１を有する。Ｉ／Ｆ２１１は、ホスト計算機１００との通信を行う。

ＭＰ−ＰＫ２２０は、複数のＭＰ２２１を有する。各ＭＰ２２１は、内部ネットワーク２５０を介してＦＥ−ＰＫ２１０、ＢＥ−ＰＫ２３０、及びＣＭ−ＰＫ２４０のいずれに対しても通信可能となっており、ＬＤＥＶに対するデータの入出力処理等を行う。

ＢＥ−ＰＫ２３０は、ＰＤＥＶユニット２６０と接続される複数のＩ／Ｆ２３１を有する。Ｉ／Ｆ２３１は、ＰＤＥＶユニット２６０との通信を行う。

ＣＭ−ＰＫ２４０は、共有メモリ２４１、及びキャッシュメモリ２４２を有する。共有メモリ２４１は、複数のＭＰ２２１から参照される管理情報（例えば、後述のテーブル）を記憶するメモリである。また、キャッシュメモリ２４２は、ＰＤＥＶユニット２６０から読み出されたデータ、及び、ＰＤＥＶユニット２６０へ書き込まれるデータを一時的に記憶するメモリである。共有メモリ２４１及びキャッシュメモリ２４２は、互いに独立したメモリであってもよいし、同一のメモリ上に設けられたそれぞれの記憶領域であってもよい。

内部ネットワーク２５０は、ＦＥ−ＰＫ２１０、ＭＰ−ＰＫ２２０、ＢＥ−ＰＫ２３０、及びＣＭ−ＰＫ２４０をそれぞれ相互に接続するネットワーク（例えば、クロスバスイッチのようなスイッチデバイス）である。

ＰＤＥＶユニット２６０は、複数のＰＤＥＶ２６１を有する。ＰＤＥＶ２６１は、物理的な記憶デバイスであり、例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）である。

本実施例では、ＬＤＥＶは、前述したように、１以上のＰＤＥＶ２６１に基づく実体的なＬＤＥＶであるが、より具体的には、パリティグループに基づくＬＤＥＶである。パリティグループは、複数のＰＤＥＶ２６１で構成されており、所定ＲＡＩＤレベルでデータを記憶する。パリティグループの記憶空間に基づいて、ＬＤＥＶが形成され、ホスト計算機１００に提供される。

図２は、実施例１に係る管理計算機３００の構成図である。

管理計算機３００は、インタフェースデバイス、記憶デバイス及びそれらに接続されたプロセッサを有する計算機の一例である。記憶デバイスの一例として、メモリ３１０があり、プロセッサの一例として、ＣＰＵ（Central Processing Unit）３２０があり、インタフェースデバイスの一例として、ＮＩＣ（Network Interface Card）３３０及び入出力Ｉ／Ｆ３４０がある。

入出力Ｉ／Ｆ３４０には、例えば、キーボード等の入力デバイス３５０、及びディスプレイ等の出力デバイス３６０が接続されてよい。入力デバイス３５０及び出力デバイス３６０は、一体でもよいし、管理計算機３００に接続された遠隔の入出力コンソールであってもよい。

管理計算機３００のメモリ３１０には、運用管理プログラム３１０１、ＬＤＥＶ数判断プログラム３１０３、及びＭＰ割当てプログラム３１０２といったコンピュータプログラムが記憶される。また、メモリ３１０には、静的情報テーブル３１０４、パリティグループ情報テーブル３１０５、最大性能利用量テーブル３１０６、及び入力情報テーブル３１０７といった情報が記憶される。ＣＰＵ３２０が、メモリ３１０に記憶されている各種プログラム（３１０１〜３１０３）を実行することにより、各種機能が実現される。

運用管理プログラム３１０１は、計算機システムの運用管理をするプログラムである。ＬＤＥＶ数判断プログラム３１０３は、入力デバイス３５０を介して指定された要求性能の論理ボリュームに対するＩ／ＯのＩ／Ｏ要求を処理するＭＰを決定するプログラムである。本実施例では、ＭＰの決定とは、ＭＰの数の決定である。決定されたＭＰ数と同数のＬＤＥＶが、入力デバイス３５０を介して指定された要求性能の論理ボリュームを構成するＬＤＥＶとなる。ＭＰ割当てプログラム３１０２は、ＬＤＥＶにＭＰを割り当てるプログラムである。

図３は、実施例１に係るＣＭ−ＰＫ２４０の構成図である。

ＣＭ−ＰＫ２４０は、前述したように、共有メモリ２４１、及びキャッシュメモリ２４２を有する。

共有メモリ２４１には、ＬＤＥＶ作成プログラム２４１１、ＬＤＥＶオーナー権プログラム２４１２、及び構成管理プログラム２４１４といったコンピュータプログラムが記憶される。共有メモリ２４１には、また、オーナー権テーブル２４１３、ＭＰ構成情報テーブル２４１５、及びパリティグループ構成情報テーブル２４１６といった情報が記憶される。キャッシュメモリ２４２には、前述したように、ＰＤＥＶユニット２６０から読み出されたデータ、及び、ＰＤＥＶユニット２６０へ書き込まれるデータが一時的に格納される。

ＬＤＥＶ作成プログラム２４１１は、パリティグループからＬＤＥＶを形成するプログラムである。ＬＤＥＶオーナー権割り当てプログラム（以下、オーナー権プログラム）２４１２は、作成されたＬＤＥＶにＭＰを割り当てるプログラムである。構成情報管理プログラム（以下、構成管理プログラム）２４１４は、パリティグループ構成情報テーブル２４１６を作成するプログラムである。なお、以下の説明において、ＰＧという略語を使用する場合があるが、これは、パリティグループを示す。

図４は、実施例１に係るホスト計算機１００の構成図である。

ホスト計算機１００は、インタフェースデバイス、記憶デバイス及びそれらに接続されたプロセッサを有する計算機の一例である。記憶デバイスの一例として、メモリ１１０があり、プロセッサの一例として、ＣＰＵ１２０があり、インタフェースデバイスの一例として、Ｉ／Ｆ１３０、及びＮＩＣ１４０がある。

Ｉ／Ｆ１３０は、ストレージネットワーク５００を介してストレージ装置２００と通信する。また、ＮＩＣ１４０は、管理ネットワーク４００を介して管理計算機３００と通信する。

メモリ１１０には、ＬＶＭ（Logical Volume Manager）管理プログラム１１０５及びアプリケーションプログラム１１０６といったコンピュータプログラムが記憶される。メモリ１１０には、また、ＬＶＭ・ＬＤＥＶ番号対応テーブル１１０７といった情報が記憶される。なお、図示は省略したが、メモリ１１０には、ＯＳ（Operating System）が記憶されており、ＯＳ上でアプリケーションプログラム１１０６が実行される。ＣＰＵ１２０が、メモリ１１０に記憶されている各種プログラムを実行する。ＬＶＭ管理プログラム１１０５が、ストレージシステム（１以上のストレージ装置２００）から提供された複数のＬＤＥＶを１つの論理ボリュームとしてアプリケーションプログラム１１０６に提供する。アプリケーションプログラム１１０６は、この論理ボリュームに対して、データのＩ／Ｏ（ライト／リード）を行う。この場合、Ｉ／Ｏ先のＬＤＥＶ（論理ボリュームにおけるＩ／Ｏ先に対応したＬＤＥＶ）を指定したＩ／Ｏ要求が、ホスト計算機１００から、Ｉ／Ｏ先のＬＤＥＶを提供するストレージ装置２００に送信される。

図５は、実施例１に係る静的情報テーブル３１０４の構成の一例を示す。

静的情報テーブル３１０４は、ストレージ装置２００の性能に関する静的な情報（以下、静的な情報）を格納するテーブルである。静的な情報とは、ストレージ装置２００の負荷に応じて動的に変わることの無い固定の情報であり、図５の例でいえば、少なくともＭＰ数５０２及び性能５０４が静的な情報である。静的情報テーブル３１０４に記憶されている各情報は、ＭＰ構成情報テーブル２４１５から取得された情報である。具体的には、管理計算機３００の運用管理プログラム３１０１が、ストレージ装置２００の構成管理プログラム２４１４に問い合わせ、その問合せに応答して、構成管理プログラム２４１４がＭＰ構成情報テーブル２４１５から情報を取得し、取得した情報を管理計算機３００の運用管理プログラム３１０１に返す。返された情報が、静的情報テーブル３１０４に格納される情報である。

静的情報テーブル３１０４は、ストレージ装置２００毎に、ストレージ装置＃５０１、ＭＰ数５０２、ＭＰ＃５０３及び性能５０４を関連付けて記憶する。

ストレージ装置＃５０１は、ストレージ装置２００を識別するための情報（例えば番号）である。ＭＰ数５０２は、ストレージ装置２００が有しているＭＰの数を示す情報である。ＭＰ＃５０３は、ＭＰを識別するための情報である。性能５０４は、ＭＰの性能（例えば、ＭＰのＩ／Ｏ性能であるＩＯＰＳ（Input Output Per Second））を示す情報である。本実施例では、ＭＰのＩ／Ｏ性能は、単位時間当たりに処理可能なＩ／Ｏ要求の数（例えば最大数）であるが、それに代えて又は加えて、レスポンスタイム（Ｉ／Ｏ要求を受けてから応答を返すまでの時間長）であってもよい。

以下のテーブル等の説明において「性能」という表現を用いるが、これはＩＯＰＳを示すものとする。従って「＊＊性能」とは、「＊＊」のＩＯＰＳを示す。なお「性能」は、前述の通り、ＩＯＰＳに限定されない。

図６は、実施例１に係るＰＧ情報テーブル３１０５の構成の一例を示す。

ＰＧ情報テーブル３１０５は、ＰＧの性能（典型的にはＩ／Ｏ性能）に関する情報を記憶するテーブルである。ＰＧ情報テーブル３１０５は、ＰＧ毎に、ＰＧ＃６０１、ＰＧタイプ６０２、及び性能６０３を関連付けて記憶する。

ＰＧ＃６０１は、ＰＧを識別するための情報（例えば番号）である。

ＰＧタイプ６０２は、ＰＧを構成するＰＤＥＶ２６１の種類と、ＰＧのＲＡＩＤ構成（例えば、ＰＧのＲＡＩＤレベル、及びＰＧを構成するＰＤＥＶ２６１の数）を示す情報である。

ＰＧ＃及びＰＧタイプは、それぞれ、ＰＧが新規作成される際に、ＣＭ−ＰＫ２４０の構成管理プログラム２４１４によって、ＰＧ構成情報テーブル２４１６に記憶される。そして、運用管理プログラム３１０１が、構成管理プログラム２４１４に問い合わせることで、ＰＧ構成管理テーブル２４１６からＰＧ＃及びＰＧタイプが取得され、それぞれ、ＰＧ＃６０１、ＰＧタイプ６０２としてＰＧ情報テーブル３１０５に記憶される。

性能６０３は、ＰＧの性能を示す情報である。性能は、ＰＧタイプ６０２によって決まる値である。性能６０３は、例えば、運用管理プログラム３１０１が、構成管理プログラム２４１４から取得したＰＧタイプ６０２を基に計算された結果（値）でよい。

なお、図では、１つのＰＤＥＶユニット２６０で複数のＰＧが構成されていることが示されている（つまり、１つのＰＤＥＶユニット２６０が複数種類のＰＤＥＶ２６１を有している）が、１つのＰＤＥＶユニット２６０で１つのＰＧが構成されてもよい。

図７は、実施例１に係る最大性能利用量テーブル３１０６の構成の一例を示す。

最大性能利用量テーブル３１０６は、各ＭＰ２２１の最大性能利用量を記憶するテーブルである。最大性能利用量については後述する。

最大性能利用量テーブル３１０６は、ＭＰ毎に、ＭＰ＃７０１、対応ＬＤＥＶ７０２、ＬＤＥＶ性能７０３、及び最大性能利用量７０４を関連付けて記憶する。

ＭＰ＃７０１は、ＭＰ−ＰＫ２２０が有するＭＰ２２１を識別するための情報（例えば番号）である。運用管理プログラム３１０１は、構成管理プログラム２４１４を通して、ＭＰ構成情報テーブル２４１５からＭＰ＃１００２を取得し、取得したＭＰ＃１００２をＭＰ＃７０１として最大性能利用量テーブル３１０６に記憶する。

ここで、本実施例では、１つのＬＤＥＶに対するデータのＩ／Ｏ処理を担当することのできるＭＰ２２１の数は１つという制限がある。本実施例では、ＬＤＥＶのＩ／Ｏ処理を担当することのできるＭＰ２２１の権利を「オーナー権」と呼んでいる。

対応ＬＤＥＶ７０２は、ＭＰ２２１がオーナー権を持つＬＤＥＶを識別するための情報である。どのＭＰ２２１がどのＬＤＥＶのオーナー権を持っているかの情報は、オーナー権テーブル２４１３に記憶されている。運用管理プログラム３１０１は、構成管理プログラム２４１４を通して各ＭＰ２２１が、どのＬＤＥＶを担当しているかを、オーナー権テーブル２４１３から、取得し、対応ＬＤＥＶ７０２として記憶する。

ＬＤＥＶ性能７０３は、ＬＤＥＶの性能（典型的にはＩ／Ｏ性能）を示す情報である。ＬＤＥＶ性能７０３は、そのＬＤＥＶが属するＰＧ性能と実質的に等価であり、運用管理プログラム３１０１がＰＧ情報テーブル３１０５より取得する。

最大性能利用量７０４は、ＭＰ２２１がオーナー権を持つＬＤＥＶのＬＤＥＶ性能７０３の合計値を示す情報である。運用管理プログラム３１０１は、ＭＰ２２１毎に、ＭＰ２２１がオーナー件を有するＬＤＥＶ性能７０３を加算し、加算した値を最大性能利用量７０４として最大性能利用量テーブル３１０６に格納する。

図８は、実施例１に係る入力情報テーブル３１０７の構成の一例を示す。

入力情報テーブル３１０７は、論理ボリューム作成に関する条件を記憶するテーブルである。

項目８０１として、ユーザが作成したい論理ボリュームの数である「ボリューム数」、論理ボリュームに要求する性能である「要求性能」、論理ボリュームに要求する容量である「ボリューム容量」等の入力項目がある。項目８０１における各入力項目に対して値８０２が関連付けられる。それぞれの値８０２は、入力デバイス３５０を介して入力された値である。少なくとも１つの値がデフォルトで固定値であってもよい。なお、入力情報テーブル３１０７に記憶されている情報は、運用管理プログラム３１０１がストレージ装置２００に対して、管理ネットワーク４００を介して送信することができる。

図９は、実施例１に係るオーナー権テーブル２４１３の構成の一例を示す。

オーナー権テーブル２４１３は、ＬＤＥＶとそのオーナー権を持つＭＰ２２１の対応を示すテーブルである。オーナー権テーブル２４１３は、ＬＤＥＶ毎に、ＬＤＥＶ＃９０１、及びオーナー権９０２を関連付けて記憶する。

ＬＤＥＶ＃９０１は、ＬＤＥＶを識別するための情報（例えば番号）である。ＬＤＥＶ＃９０１は、ＬＤＥＶが作成されたときに、構成管理プログラム２４１４によって、そのＬＤＥＶを識別する情報として、オーナー権テーブル２４１３に記憶されてよい。

オーナー権９０２は、ＬＤＥＶを担当するＭＰ２２１を識別するための情報である。オーナー権９０２は、ＬＤＥＶが作成されたときに、構成管理プログラム２４１４によって、そのＬＤＥＶを担当するＭＰを識別する情報として、オーナー権テーブル２４１３に記憶されてよい。

図１０は、実施例１に係るＭＰ構成情報テーブル２４１５の一例を示す。

ＭＰ構成情報テーブル２４１５は、ＭＰ数１００１、ＭＰ＃１００２、及びＭＰ性能１００３を有する。このテーブル２４１５は、１つのストレージ装置２００につき１つでもよいし、１つのＭＰ−ＰＫ２２０につき１つでもよい。

ＭＰ数１００１は、ストレージ装置２００が有するＭＰ２２１の数を示す情報である。ＭＰ＃１００２は、ＭＰ２２１を識別するための情報である。ＭＰ性能１００３は、ＭＰ２２１の性能を示す情報である。

ＭＰ数１００１、ＭＰ＃１００２、及びＭＰ性能１００３は、設計段階で規定された数値であり、ＭＰ−ＰＫ２２０の構成変更が行われない限りが変更されることはない。

図１１は、実施例１に係るＰＧ構成情報テーブル２４１６の一例を示す。

ＰＧ構成情報テーブル２４１６は、ＰＤＥＶユニット２６０毎に、ＰＧ数１１０１、ＰＧ＃１１０２、ＰＧタイプ１１０３、及びＬＤＥＶ＃１１０４を有する。

ＰＧ数１１０１は、ＰＤＥＶユニット２６０が有するＰＧの数を示す情報である。ＰＧ＃１１０２は、ＰＧを識別するための情報（例えば番号）である。ＰＧタイプ１１０３は、ＰＧのＲＡＩＤ構成（例えば、ＰＤＥｓＶ２６１の種類、ＲＡＩＤレベル、及びＰＧを構成するＰＤＥＶ２６１の数）を示す情報である。ＬＤＥＶ＃１１０４は、ＰＧに基づいて生成されたＬＤＥＶを識別するための情報である。

図１２は、実施例１に係るＬＶＭ・ＬＤＥＶ番号対応テーブル１１０７の一例を示す。

ＬＶＭ・ＬＤＥＶ番号対応テーブル１１０７は、ＬＤＥＶ毎に、ＬＤＥＶ＃１２０１、デバイス名１２０２、及びＬＶ（Logical Volume）名１２０３を関連付けて記憶する。

ＬＤＥＶ＃１２０１は、ＬＤＥＶを識別するための情報である。デバイス名１２０２は、ストレージ装置２００から提供されたＬＤＥＶをホスト計算機１００が識別するための情報である。ＬＶ名１２０３は、複数のＬＤＥＶにより構成された論理ボリュームを識別するための情報である。

ホスト計算機１００のＬＶＭ管理プログラム１１０５は、運用管理プログラム３１０１から提供されたＬＤＥＶ＃をＬＤＥＶ＃１２０１として記憶する。次に、ＯＳは、ＬＤＥＶ＃１２０１に対して、任意のデバイス１２０２名、例えば「／ｄｅｖ／ｓｄａ」を付与する。そして、ＬＶＭ管理プログラム１１０５は、ＬＤＥＶ＃１２０１に記憶されているＬＤＥＶのデバイス名１２０２をＯＳから取得し、デバイス名１２０２が示す１又は複数のＬＤＥＶで論理ボリュームを構成し、構成した論理ボリュームを識別する情報をＬＶ名１２０３としてテーブル１１０７に記憶する。

なお、どのＬＤＥＶにより論理ボリュームを構成するか（例えば論理ボリュームを構成するＬＤＥＶのＬＤＥＶ＃のリスト）を表す情報は、運用管理プログラム３１０１からＬＶＭ管理プログラム１１０５に送信されてよい。ＬＶＭ管理プログラム１１０５は、その情報を受けて、その情報から特定される複数のＬＤＥＶで論理ボリュームを構成してよい。具体的には、ＬＶＭ管理プログラム１１０５は、同じ論理ボリュームを構成するＬＤＥＶ１２０１＃（デバイス名１２０２）に対して、同じＬＶ名を付与して、付与したＬＶ名をＬＶ名１２０３としてテーブル１１０７に記憶する。

アプリケーションプログラム１１０６は、ＬＶ名１２０３が示す論理ボリュームに対するＩ／Ｏを行うが、ホスト計算機１００は、ＬＶＭ・ＬＤＥＶ番号対応テーブル１１０７を参照することにより、論理ボリュームにおけるＩ／Ｏ先がどのＬＤＥＶと関連付いているかを判断することができる。

次に、ユーザから論理ボリューム作成指示を受けてから論理ボリュームが作成されるまでの処理の一例を説明する。

図１３は、実施例１に係るボリューム作成処理の一例を示すフローチャートである。

まず、ユーザが、入力デバイス３５１０を用いて、作成したい論理ボリュームの情報（例えば、論理ボリュームの数、論理ボリュームの容量、及び論理ボリュームに対する要求性能）等を入力する。
次に、運用管理プログラム３１０１が、入力された情報を受け付け、その情報を入力情報テーブル３１０７に格納する（Ｓ１０１０）。

次に、ＬＤＥＶ数判断プログラム３１０３が、入力情報テーブル３１０７から情報を取得し、作成するＬＤＥＶの数等を決定する（Ｓ１０２０）。決定されるＬＤＥＶ数は、１以上であればよく、例えば、取得した情報により予め決められた値であってもよいし、取得した情報に基づいて算出された値であってもよい。Ｓ１０２０の詳細については、後述する。

次に、ＭＰ割当てプログラム３１０２が、作成する各ＬＤＥＶに対するＭＰの割り当て（オーナー権）を決定する（Ｓ１０４０）。各ＬＤＥＶに対してＭＰを割り当てる処理については、後述する。

ＬＤＥＶ数判断プログラム３１０３は、決定したＬＤＥＶ数、及びＭＰ割当てに関する情報を、管理ネットワーク４００を介してストレージ装置２００に送信する（Ｓ１０５０）。

ストレージ装置２００は、ＬＤＥＶ数判断プログラム３１０３から送信された、ＬＤＥＶ数、及びＭＰ割当てに関する情報を受信する（Ｓ１０６０）。

次に、ストレージ装置２００では、ＬＤＥＶ作成プログラム２４１１が、Ｓ１０６０で受信した情報に基づき、ＬＤＥＶを作成し（Ｓ１０７０）、ＬＤＥＶオーナー権プログラム２４１２が、作成したＬＤＥＶに対しＭＰを割り当てる（オーナー権を設定する）（Ｓ１０８０）。

ここで、ストレージ装置２００（例えば、ＬＤＥＶ作成プログラム２４１１又はＬＤＥＶオーナー権プログラム２４１２）は、作業が完了したことの完了報告、及び作成した複数のＬＤＥＶにそれぞれ対応した複数のＬＤＥＶ＃を管理計算機３００に送信する（Ｓ１０９０）。

管理計算機３００は、Ｓ１０９０でストレージ装置２００から送信された情報（完了報告、及び、複数のＬＤＥＶ＃）を受信する（Ｓ１１００）。管理計算機３００（例えば運用管理プログラム３１０１）は、論理ボリューム提供指示を、ホスト計算機１００に送信する（Ｓ１１１０）。その指示は、Ｓ１１００で受信した複数のＬＤＥＶ＃が関連付けられる。

ホスト計算機１００は、Ｓ１１１０で管理計算機３００から送信された指示を受信する（Ｓ１１２０）。

ホスト計算機１００では、ＬＶＭ管理プログラム１１０５が、受信した指示が有する情報（複数のＬＤＥＶ＃）をＬＶＭ・ＬＤＥＶ番号対応テーブル１１０７に格納し、且つ、アプリケーションプログラム１１０６に対して提供する論理ボリュームのＬＶ名１２０３を決定する（Ｓ１１３０）。そのＬＶ名１２０３に、受信した指示が有する複数のＬＤＥＶ＃が関連付けられる。

次に、ホスト計算機１００では、ＬＶＭ管理プログラム１１０５が、ＬＶＭ・ＬＤＥＶ番号対応テーブル１１０７の情報を基に、上記受信した複数のＬＤＥＶ＃にそれぞれ対応した複数のＬＤＥＶを１つの論理ボリュームとしてアプリケーションプログラム１１０６に提供する（Ｓ１１４０）。

ここで、ホスト計算機１００では、ＬＶＭ管理プログラム１１０５が、作業が完了した報告、及び作成したＬＶのＬＶ名１２０３等を管理計算機３００に送信する（Ｓ１１５０）。

管理計算機３００は、Ｓ１１５０でホスト計算機１００から送信された情報を受信し（Ｓ１１６０）、受信した情報を出力デバイス３６０に表示する（Ｓ１１７０）。

以上の処理により、ユーザの要求する性能が発揮されることが期待される論理ボリュームを、それぞれが１つのＭＰによって担当される複数のＬＤＥＶで構成することができる。

図１４は、実施例１に係るＬＤＥＶ数決定処理（図１３のＳ１０２０）の一例を示すフローチャートである。

ＬＤＥＶ数判断プログラム３１０３は、入力情報テーブル３１０７から、論理ボリュームの数、論理ボリュームに対する要求性能等の値を取得する（Ｓ２０１０）。

次に、ＬＤＥＶ数判断プログラム３１０３は、ユーザが論理ボリュームに対して要求する性能（以下、要求性能）を満たすために必要なＭＰ数（以下、必要なＭＰ数）を計算する（Ｓ２０２０）。

具体的に、例えば、Ｓ２０２０では、ＬＤＥＶ数判断プログラム３１０３は、必要なＭＰ数を、要求性能をＭＰの性能（静的情報テーブル３１０４の性能５０４）で割り算したものを切り上げた数とすることができる。

例えば、ＬＤＥＶ数判断プログラム３１０３が、ユーザ要求性能として１５０Ｋ（ＩＯＰＳ）という情報を受信した場合、まず、ＬＤＥＶ数判断プログラム３１０３は、静的情報テーブル３１０４の性能５０４を参照して、ストレージ装置２００が有するＭＰの性能に関する情報を取得する。ここで、ＬＤＥＶ数判断プログラム３１０３は、ＭＰ−ＰＫ２２０が有している各ＭＰの性能が５０Ｋ（ＩＯＰＳ）であるという情報を取得する。

次に、ＬＤＥＶ数判断プログラム３１０３は、ユーザ要求性能「１５０Ｋ」をＭＰの性能「５０Ｋ」で割り算する。そして、ＬＤＥＶ数判断プログラム３１０３は、必要なＭＰ数として「３」を得る。

次に、ＬＤＥＶ数判断プログラム３１０３は、必要なＭＰ数がストレージ装置２００に搭載されているＭＰ数より少ないかどうかを判断する（Ｓ２０３０）。具体的に、Ｓ２０３０で、ＬＤＥＶ数判断プログラム３１０３は、静的情報テーブル３１０４のＭＰ数５０２を参照して、ＭＰ数５０２（つまり、搭載されているＭＰ２２１の数である搭載ＭＰ数）が、Ｓ２０２０で計算した必要なＭＰ数より少ないかどうかを判断する。

必要なＭＰ数が搭載ＭＰ数よりも少なければ（Ｓ２０３０：ＹＥＳ）、ＬＤＥＶ数判断プログラム３１０３は、必要なＭＰ数を、作成するＬＤＥＶの数とする（Ｓ２０５０）。

必要なＭＰ数が搭載ＭＰ数以上であれば（Ｓ２０３０：ＮＯ）、ＬＤＥＶ数判断プログラム３１０３は、搭載ＭＰ数を、作成するＬＤＥＶの数とする（Ｓ２０４０）。

以上の処理により、要求性能を満たすためのＭＰ数とＬＤＥＶ数が決定される。なお、本実施例では、１つのストレージ装置２００において、複数のＭＰのそれぞれの性能は同じであり、図１４は、１つのストレージ装置２００から必要ＭＰ数を決定する例を示している。ストレージ装置２００によってＭＰの性能が異なっている場合、要求性能を満たすためのＭＰは、ＭＰの性能を基に異なるストレージ装置２００から選ばれてもよい。

ＬＤＥＶの数の決定方法としては、例えば、予め、論理ボリュームを構成するＬＤＥＶの容量を所定容量に設定しておき、ユーザから要求された論理ボリュームの容量と、設定された所定容量に基づいて、論理ボリュームを構成するＬＤＥＶの数を決定することができる。具体的には、例えば、ユーザから要求された論理ボリュームの容量を、設定された所定容量で割って得られる数を、論理ボリュームを構成するＬＤＥＶの数とすることができる。この場合、作成したＬＤＥＶに対して複数のＭＰからラウンドロビンでＭＰを割り当てることもできるし、負荷の少ないＭＰから順に割り当てることもできる。

また、さらに別のＬＤＥＶの数の決定方法としては、例えば、作成するＬＤＥＶ数をストレージ装置２００が持つＭＰの数とすることもできる。この場合、作成した各ＬＤＥＶに対して１つずつＭＰを割り当てることが好ましい。

以上２つのＬＤＥＶの数の決定方法は、図５の静的情報テーブルにおいて、１つのストレージ装置２００が有する複数のＭＰの各性能が異なっている場合にも採用することができる

また、ＭＰ数の決定において、どのＭＰを、作成対象の論理ボリュームに割り当てるかも決定されてよい。その際、静的な負荷（最大性能利用量）が小さいＭＰほど優先的に選ばれてもよい。

また、ＬＤＥＶの数の決定では、どの性能のＰＧに基づくＬＤＥＶとするかも決定されてよい。また、決定されるＬＤＥＶの性能は、決定されたＭＰの性能に基づいて決定されてよい。例えば、性能の低いＭＰが決定された場合、そのＭＰによって担当されるＬＤＥＶとして性能が低いＬＤＥＶが決定されてよいし、性能の高いＭＰが決定された場合、そのＭＰによって担当されるＬＤＥＶとして性能が高いＬＤＥＶが決定されてよい。このような観点から、どんな性能のＬＤＥＶを幾つ作成するかを決定し、ＬＤＥＶ数に関する情報に、決定された情報（どんな性能のＬＤＥＶを幾つ作成するかを表す情報）が含まれてもよい。ＬＤＥＶ数に関する情報は、管理計算機３００からストレージ装置２００に送信され、その情報を基に、ストレージ装置２００によって、ＬＤＥＶが作成されてよい。

また、それぞれのＬＤＥＶの容量は同じであり、論理ボリュームの容量はＬＤＥＶの倍数でよい。ユーザから、条件として、論理ボリュームの容量が入力され、ＬＤＥＶ数は、その容量に基づいて決定されてよい。ＬＤＥＶによってＬＤＥＶの容量は異なっていてもよい。論理ボリュームについて指定されたボリューム容量を基に、ＬＤＥＶ数が決定されてもよい。

図１５は、実施例１に係るＭＰ割当て処理（図１３のＳ１０４０）の一例を示すフローチャートである。

ＭＰ割当てプログラム３１０２は、最大性能利用量テーブル３１０６より各ＭＰの最大性能利用量７０４を取得する（Ｓ３０１０）。

次に、ＭＰ割当てプログラム３１０２は、ＬＤＥＶ数判断プログラム３１０３より「作成するＬＤＥＶ数」に関する情報を受け取る（Ｓ３０２０）。作成するＬＤＥＶ数とは、図１４のフローにより決定されたＬＤＥＶ数である。なお、その情報は、どんな性能のＬＤＥＶを幾つ取得するかを表す情報が含まれていてもよい。

次に、ＭＰ割当てプログラム３１０２は、Ｓ３０１０で取得した最大性能利用量７０４に基づき、最大性能利用量７０４が最小のＭＰ＃７０１を検索し、検索したＭＰ＃７０１に１つのＬＤＥＶを割り当てる（Ｓ３０３０）。ここで、ＭＰ割当てプログラム３１０２は、割り当てるＬＤＥＶを、ＰＧテーブル３１０５に基づき最も性能の高いＰＧから作成してもよいし、ユーザにより、予め選択されたＰＧから作成してもよい。

次に、ＭＰ割当てプログラム３１０２は、ＬＤＥＶを割り当てたＭＰ２２１の最大性能利用量７０４の値に、Ｓ３０３０で割り当てたＬＤＥＶの性能の値を加える（Ｓ３０４０）。

次に、ＭＰ割当てプログラム３１０２は、ＬＤＥＶの割り当てが完了したかどうかを判断する（Ｓ３０５０）。ここで、ＭＰ割当てプログラム３１０２は、図１４のフローにより決定された「作成するＬＤＥＶ数」の全てのＬＤＥＶに対して、ＭＰの割り当てが済んだと判断した場合（Ｓ３０５０：ＹＥＳ）、ＭＰ割当てプログラム３１０２は、処理を終了する。一方、全てのＬＤＥＶに対して、ＭＰの割り当てが済んでいないと判断した場合（Ｓ３０５０：ＮＯ）、ＭＰ割当てプログラム３１０２は、再度、Ｓ３０３０の処理をする。

以上、実施例１では、静的な情報を用いて、１つの論理ボリュームの作成指示に対して、要求性能が１つのＭＰでは満たせない場合には、１つの論理ボリュームを２以上のＬＤＥＶで構成することでＭＰの負荷を分散させることができる。更に、本実施例では、決定した各ＬＤＥＶに対して、負荷が少ないＭＰ２２１を割り当てることができる。すなわち、論理ボリュームが、実質的に負荷の少ないＭＰ２２１が割り当てられているＬＤＥＶにより構成される。これにより、論理ボリュームに対するアプリケーションプログラム１１０６からのＩ／Ｏの負荷が複数のＭＰ（論理ボリュームを構成している複数のＬＤＥＶにそれぞれ対応した複数のＭＰ）に分散される。それ故、１つのＭＰに負荷が集中することを避けることができ、以って、論理ボリュームに対する要求性能を発揮することが期待される。

以下、実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。

実施例２では、ＬＤＥＶにＭＰを割り当てる際に参照されるＭＰ負荷として、最大性能利用量のような静的な負荷に代えて（又は加えて）、ＭＰの稼働状況によって変化する動的な負荷が使用される。

具体的には、実施例１では、ＭＰ割当て処理（Ｓ１０４０）が、静的な情報である最大性能利用量テーブル３１０６を用いて行われる。実施例２では、ＭＰ割当て処理が、動的情報テーブル３１０８を用いて行われる。なお、実施例２においても、ＬＤＥＶ数を決定する処理（Ｓ１０２０）では、実施例１と同様に、静的な情報が用いられる。

図１６は、実施例２に係る管理計算機３００の構成図である。

実施例２の管理計算機３００が実施例１の管理計算機３００と異なる部分は、メモリ３１０に動的情報テーブル３１０８が記憶されている点である。それ以外の構成は、実施例１の管理計算機３００と実質的に同じであるため、説明を省略する。

図１７は、実施例２に係る動的情報テーブル３１０８の構成の一例を示す。

動的情報テーブル３１０８は、ストレージ装置２００が有しているＭＰ２２１毎に、ＭＰ＃１５０１、平均負荷１５０２、及びフラグ１５０３を関連付けて記憶する。

ＭＰ＃１５０１は、ＭＰ−ＰＫ２２０が有するＭＰ２２１を識別するための情報である。

平均負荷１５０２は、ＭＰ２２１に掛かっている負荷の平均を示す情報である。ここで、平均負荷１５０２とは、或る時刻から現在の時刻までの或る期間のＭＰの負荷（使用率）の平均値である。平均負荷１５０２は、一定期間毎に更新されてよい。また、動的な負荷として、平均負荷１５０２に代えて、他種の統計に従う負荷、例えば最大負荷でもよいし最小負荷でもよい。

平均負荷１５０２は、ストレージ装置２００が有する機能によって取得される。また、ある一定期間とは、１分や１時間といった時間を基準に設定されてもよいし、或いはＭＰ２２１の処理サイクル数（例えば、１００万サイクルや１０００万サイクルといったサイクル数）を基準に設定されてもよい。

フラグ１５０３は、ＭＰ２２１の平均負荷１５０２が所定の閾値（例えば９０％）以上か否かを示す情報である。平均負荷１５０２が閾値以上の場合、フラグ１５０３は「０」となり、平均負荷１５０２が閾値より低い場合、フラグ１５０３は「１」となる。なお、閾値は、例えば、ユーザからの入力または出荷時に決められた値としてもよい。

図１８は、実施例２に係るＭＰ割当て処理の一例を示すフローチャートである。

ＭＰ割当てプログラム３１０２は、動的情報テーブル３１０８より平均負荷１５０２に関する情報を取得する（Ｓ４０１０）。

次に、ＭＰ割当てプログラム３１０２は、平均負荷１５０２が閾値以上（つまり、フラグ１５０３が「０」）のＭＰを除外する（Ｓ４０２０）。

次に、ＭＰ割当てプログラム３１０２は、フラグ１５０３が「１」のＭＰを平均負荷１５０２が示す値が低い順にソートし（Ｓ４０３０）、平均負荷１５０２が低いＭＰから順に、例えばラウンドロビンで、ＬＤＥＶにＭＰを割り当てる（Ｓ４０４０）。

ＭＰ割当て処理（Ｓ１０４０）以外の処理は、図１３に示すフローチャートと実質的に同様であるため説明を省略する。

以上が実施例２である。実施例２によれば、例えば、第１のホスト計算機１００の第１のアプリケーションプログラムに提供する第１の論理ボリュームを生成する場合に、第２（又は第１）のホスト計算機１００で第２のアプリケーションプログラムが実行されているが故にストレージシステムに対してＩ／Ｏ要求が発行されており１又は複数のＭＰが稼働中である場合に、ＭＰの動的負荷に基づいて、第１の論理ボリュームについて、ＬＤＥＶに割り当てるＭＰを決定することができる。

以上の処理により、ＭＰの動的な負荷を基に、ＬＤＥＶにＭＰを割り当てることができる。これにより、実施例１に示した最大性能利用量テーブル３１０６（静的な情報）を用いた場合と同様に、論理ボリュームを構成している各ＬＤＥＶに割り当てられたＭＰ間で、適切に負荷分散をすることが可能となる。

なお、ＭＰ割当てプログラム３１０２は、静的負荷（最大性能利用量）が同じＭＰのうち、ＭＰの動的負荷（平均負荷）がより小さいＭＰを、ＬＤＥＶに優先的に割り当ててよい。或いは、ＭＰ割当てプログラム３１０２は、動的負荷が同じＭＰのうち、静的負荷がより小さいＭＰを、ＬＤＥＶに優先的に割り当ててよい。

以下、実施例３を説明する。その際、実施例１及び２との相違点を主に説明し、実施例１及び２との共通点については説明を省略或いは簡略する。

作成済の論理ボリュームを構成するＬＤＥＶの数、及びＬＤＥＶに対するＭＰ割当て、のうちの少なくとも一方を変更できることが望ましい。実施例３では、例えば、論理ボリュームを構成する複数のＬＤＥＶにそれぞれ対応した複数のＭＰで負荷が上手に分散されていない等の原因により論理ボリュームの負荷が閾値以上に高くなった場合に、論理ボリュームを再構成することができる。なお、実施例３においても、ＭＰ割当て処理は、静的情報を用いた処理でもよいし（図１５参照）、動的情報を用いた処理（図１８参照）でもよい。

図１９は、実施例３に係る管理計算機３００の構成図である。

実施例２の管理計算機３００が実施例１の管理計算機３００と異なる部分は、メモリ３１０に動的情報テーブル３１０８、及び稼働中ＬＥＤＶ分割プログラム（以下、稼働中プログラム）３１０９が記憶されている点である。それ以外の構成は、実施例１の管理計算機３００と実質的に同じであるため、説明を省略する。

動的情報テーブル３１０８は、実施例２で説明した動的情報テーブル３１０８と構成は実質的に同じであるが、平均負荷１５０２が、何れかのアプリケーションが稼働しているときに掛かっている各ＭＰ２２１の負荷となる。実施例２で説明した平均負荷１５０２は、アプリケーションが稼働していないときに掛かっている各ＭＰ２２１の負荷である。

稼働中ＬＤＥＶ数判断プログラム（以下、稼働プログラム）３１０９は、アプリケーションプログラムが稼働しているときに、設定したＬＤＥＶ数、及び各ＬＤＥＶに対するＭＰの割り当てを、再設定するプログラムである。

図２０は、実施例３に係る論理ボリューム再構成処理を含んだ処理の一例を示すフローチャートである。

まず、ユーザが、稼働プログラム３１０９を起動する（Ｓ５０１０）。

次に、稼働プログラム３１０９が、動的情報テーブル３１０８より、動的負荷の高いＭＰ（フラグ１５０３が「０」であるＭＰのＭＰ＃１５０１）を特定し、さらにオーナー権テーブル２４１３よりそのＭＰ＃１５０１が示すＭＰが担当するＬＤＥＶのＬＤＥＶ＃９０１を特定する（Ｓ５０２０）。

次に、稼働プログラム３１０９が、特定したＬＤＥＶのＬＤＥＶ＃をホスト計算機１００に送信する（Ｓ５０３０）。

ホスト計算機１００は、特定したＬＤＥＶ＃を受信し、ＬＶＭ・ＬＤＥＶ番号対応テーブル１１０７に基づいて、負荷が閾値以上である論理ボリュームのＬＶを特定する（Ｓ５０４０）。ここで、「負荷が閾値以上である論理ボリューム」とは、例えば、論理ボリュームを構成するＬＤＥＶ数に対する、Ｓ５０４０で受信したＬＤＥＶ＃に対応したＬＤＥＶの数が、所定比率以上である論理ボリュームでよい。

ホスト計算機１００は、負荷の高い論理ボリューム（負荷が閾値以上である論理ボリューム（旧論理ボリューム））を利用しているアプリケーションプログラムを停止する（Ｓ５０５０）。この停止はユーザの指示に応答して行われてよい。そして、ホスト計算機１００は、ユーザの指示に応答して、作業続行の指示を管理計算機３００に送信する（Ｓ５０６０）。作業続行の指示は、ホスト計算機１００上の例えばＯＳがアプリケーションプログラムの停止を検知した後に管理計算機３００に送信されてもよいし、ユーザから入力デバイス３５０を用いて行われた指示に応答して管理計算機３００に送信されてもよい。

管理計算機３００が作業続行の指示を受信すると（Ｓ５０７０）、管理計算機３００、ストレージ装置２００、及びホスト計算機１００が、図１３のＳ１０２０からＳ１１７０までの対応する処理と実質的に同様の処理を行い（論理ボリューム再構成処理）、ユーザ要求性能を満たす論理ボリューム（新論理ボリューム）を作成する（ステップＳ５０８０）。

次に、ホスト計算機１００上でＬＶＭ管理プログラム１１０５が、例えば新論理ボリュームをマウントし、旧論理ボリュームから新しい論理ボリュームへとデータのコピーを行い、その後（Ｓ５０９０）、旧論理ボリュームをアンマウントする（Ｓ５１００）。

データのコピーは、ホスト計算機１００が持つコピー機能により行われてもよいし（すなわち、旧論理ボリュームからデータを読み出し新論理ボリュームにそのデータを書き込んでもよいし）、ストレージ装置２００が持つコピー機能により行われてもよい（すなわち、ホスト計算機１００を経由することなく、旧論理ボリュームを構成する複数のＬＤＥＶから新論理ボリュームを構成する複数のＬＤＥＶへのデータコピーが行われてもよい）。

ホスト計算機１００は、コピー完了の報告を管理計算機３００に送信する（Ｓ５１１０）。管理計算機３００は、ホスト計算機１００からコピー完了報告を受信し、出力デバイス３６０でユーザに対して、作業が完了したことを伝える（Ｓ５１２０）。

最後に、論理ボリュームの切り替えが完了したことを受けて、ホスト計算機１００を利用しているユーザがアプリケーションを起動する（Ｓ５１３０）。

以上の処理により、ユーザからの要求性能を満たす論理ボリュームを再構成することができる。これにより、例えば、アプリケーションの特性が変動した場合、ＬＤＥＶ数やＭＰ割当てを、アプリケーションの特性に合わせて再設定し、要求性能を満たす論理ボリュームを再構成することが可能となる。

以下、実施例４を説明する。論理ボリュームの作成に当たり、ユーザが、論理ボリュームに要求する性能である「要求性能」を指定する。ユーザは、指定した要求性能を満たすボリュームが作成されることを期待するため、作成されるボリュームについては、要求性能が達成されることを期待する。

本実施例では、少なくとも、もし明らかに要求性能を達成できる論理ボリュームを作成できる見込みがない場合には、事前にその旨がユーザに知らされ、論理ボリュームの作成を中止することができる。以下で、その方法の一例を示す。

図２１は、実施例４に係るＭＰ余剰性能テーブル３１１１の一例を示す。

ＭＰ余剰性能テーブル３１１１は、管理計算機３００のメモリ３１０上に記憶される。ＭＰ余剰性能テーブル３１１１は、ストレージ装置２００毎に、ＭＰ性能合計値１７０１、割当て性能合計値１７０２、及び余剰性能合計値１７０３を有する。

ＭＰ性能合計値１７０１は、ストレージ装置２００（ＭＰ−ＰＫ２２０）が有する全てのＭＰ２２１の性能値の合計値を示す。割当て性能合計値１７０２は、これまでに行われた論理ボリューム作成において、ユーザにより指定されたＭＰに対する要求性能の合計値を示す。余剰性能合計値１７０３は、ＭＰ性能合計値１７０１から割当て性能合計値１７０２を減算した減算値（つまり、現在割り当て可能な余剰性能）を示す。

ＭＰ性能合計値１７０１は、運用管理プログラム３１０１が、ストレージ装置２００毎に、静的情報テーブル３１０４から性能５０４を取得し、取得した性能を加算することにより、計算される。割当て性能合計１７０２は、運用管理プログラム３１０１が、論理ボリュームの作成毎に、その時にユーザから指定された要求性能の値を現在の割り当て性能合計１７０２に加算することにより計算される。また、余剰性能合計１７０３は、運用管理プログラム３１０１が、ＭＰ性能合計値１７０１から割当て性能合計値１７０２を減算することにより計算される。

図２２は、実施例４に係るボリューム作成続行または中止決定の一例を示すフローチャートである。

運用管理プログラム３１０１は、入力情報テーブル３１０７から、論理ボリュームの数、論理ボリュームに対する要求性能等の値を取得する（Ｓ６０１０）。

次に、運用管理プログラム３１０１は、ＭＰ余剰性能テーブル３１１１を参照し、ＭＰ余剰性能合計値１７０３が、ユーザが論理ボリュームに対して要求する要求性能よりも多いか否かを判断する（Ｓ６０２０）。つまり、Ｓ６０２０では、ユーザが要求する要求性能を満たす論理ボリュームが作成できる見込みがあるか否かが判断される。

余剰性能合計値１７０３が要求性能以上であれば（Ｓ６０２０：ＹＥＳ）、運用管理プログラム３１０１は、論理ボリュームの作成を続行する（Ｓ６０５０）。

余剰性能合計１７０３が要求性能よりも少なければ（Ｓ６０２０：ＮＯ）、運用管理プログラム３１０１は、出力デバイス３６０を通してユーザに対してエラーを出力する（Ｓ６０３０）。エラー出力は、要求性能が達成できない可能性があることをユーザに示唆し、それでもボリューム作成を続行するか、それともボリューム作成を中止するかをユーザに判断させるものであればよいので、例えば、ディスプレイ等の出力デバイス３６０を用いることができる。

ユーザが論理ボリュームの作成を続行すると判断した場合（Ｓ６０４０：ＹＥＳ）、運用管理プログラム３１０１は、論理ボリュームの作成を続行する（Ｓ６０５０）。一方、ユーザが論理ボリュームの作成を中止すると判断した場合（Ｓ６０４０：ＮＯ）、運用管理プログラム３１０１は、論理ボリュームの作成を中止する（Ｓ６０６０）。

以上の処理により、要求性能を明らかに達成できないと分かっている論理ボリュームを、ユーザが気づかないうちに作成されてしまうことを避けることが可能となる。なお、本実施例は、実施例１及び実施例２のうち少なくとも１つと組み合わせることもできる。具体的に、例えば、図１３のＳ１０１０の後に、図２２の処理を含めてもよい。これにより、実施例１または実施例２においても、要求性能を満たさない論理ボリュームが作成されてしまうのを避けることが可能となる。

以上、幾つかの実施例を説明したが、本発明は、それらの実施例に限定されない。

例えば、複数のＬＤＥＶを１つの論理ボリュームとしてアプリケーションプログラムに提供するＬＶＭ管理プログラム１１０５は、ホスト計算機１００以外の装置、例えば、ストレージシステムによって実行されてもよいし、ストレージシステムとホスト計算機１００の間に介在する装置（例えばスイッチ装置）によって実行されてもよい。

また、例えば、管理計算機３００は、静的負荷及び動的負荷のうちの少なくとも一方が小さいＭＰを、生成対象の論理ボリュームを構成するＬＤＥＶを担当するＭＰとして優先的に決定してよい。

また、決定されるＬＤＥＶ数は、決定されるＭＰ数より多くてもよい。

１００…ホスト計算機、２００…ストレージ装置、３００…管理計算機、４００…管理ネットワーク、５００…ストレージネットワーク、２１０…ＦＥ−ＰＫ、２２０…ＭＰ−ＰＫ、２３０…ＢＥ−ＰＫ、２４０…ＣＭ−ＰＫ、２５０…内部ネットワーク、２６０…ＰＤＥＶユニット、２１１…ホストＩ／Ｆ、２２１…ＭＰ、２３１…ストレージＩ／Ｆ、２４１…共有メモリ、２４２…キャッシュメモリ、２６１…ＰＤＥＶ

Claims (14)

1. アプリケーションを実行するホスト計算機に接続され、複数のマイクロプロセッサ（ＭＰ）を有するストレージシステムと、
   前記ホスト計算機及び前記ストレージシステムのうちの少なくとも前記ストレージシステムを管理する管理システムと
   を有し、
   前記ストレージシステムは、複数のマイクロプロセッサ（ＭＰ）と、複数の論理記憶デバイスを提供する少なくとも１の記憶装置を有し、
   各論理記憶デバイスを担当するＭＰが前記複数のＭＰから割り当てられ、前記１つの論理記憶デバイスに対するＩ／Ｏ（Input/Output）は、その論理記憶デバイスを担当するＭＰで行うようになっており、
   前記管理システムが、
   （Ａ）前記複数のＭＰのそれぞれの性能を表す情報である性能管理情報と、前記アプリケーションに提供される論理ボリュームに要求される性能である要求性能とに基づいて、決定される２以上のＭＰの性能と前記要求性能との関係が所定の条件を満たすように、前記アプリケーションに提供される論理ボリュームを構成する２以上の論理記憶デバイスと、前記２以上の論理記憶デバイスに対する処理をそれぞれ担当する２以上のＭＰとを決定し、
   （Ｂ）前記決定した２以上の論理記憶デバイスに前記決定した２以上のＭＰを割り当てる、
   計算機システム。
2. 前記管理システムは、
   前記論理記憶デバイスに割り当てられていないＭＰの性能値の合計値である余剰性能合計値を管理し、
   前記要求性能と前記余剰性能合計値とを比較し、
   前記要求性能の方が高い場合には、前記要求性能の方が前記余剰性能合計値よりも高いことを示す情報を出力する、
   請求項１記載の計算機システム。
3. 前記管理システムは、前記（Ａ）において、予め設定される所定の容量と前記論理ボリュームの容量に基づいて、前記２以上の論理記憶デバイスを決定する、
   請求項１又は２記載の計算機システム。
4. 前記管理システムが、前記（Ａ）において、ＭＰが担当している１以上の論理記憶デバイスの性能に基づく値である静的負荷が小さいＭＰを優先的に、前記決定された論理記憶デバイスの処理を担当するＭＰとして決定する、
   請求項１乃至３のうちのいずれか１項に記載の計算機システム。
5. 前記管理システムが、前記（Ａ）において、前記静的負荷が同じＭＰのうち、ＭＰの稼働状況に応じて変化する値である動的負荷が小さいＭＰを優先的に、前記決定された論理記憶デバイスの処理を担当するＭＰとして決定する、
   請求項４記載の計算機システム。
6. 前記管理システムが、前記（Ａ）において、ＭＰの稼働状況に応じて変化する値である動的負荷が小さいＭＰを優先的に、前記決定された論理記憶デバイスの処理を担当するＭＰとして決定する、
   請求項１乃至５のうちのいずれか1項に記載の計算機システム。
7. 前記管理システムが、前記（Ａ）において、前記動的負荷が同じＭＰのうち、ＭＰが担当する１以上の論理記憶デバイスの性能に基づく値である静的負荷が小さいＭＰを優先的に、前記決定された論理記憶デバイスの処理を担当させるＭＰとして決定する、
   請求項６記載の計算機システム。
8. 前記所定の条件は、前記決定される２以上のＭＰの性能の合計値が前記要求性能以上になることである、
   請求項１乃至７のうちのいずれか1項に記載の計算機システム。
9. 前記管理システムは、前記決定した２以上の論理記憶デバイスと前記決定した２以上のＭＰとに関する割当て情報を前記ストレージシステムに送信し、前記ストレージシステムが、前記割当て情報を基に、２以上の論理記憶デバイスを生成し、１つの論理記憶デバイスに１つのＭＰが担当として割り当てられるように前記決定した２以上の論理記憶デバイスに前記決定した２以上のＭＰを割り当て、前記生成された２以上の論理記憶デバイスのそれぞれのデバイス識別情報を前記管理システムに送信し、
   前記管理システムは、前記生成された２以上の論理記憶デバイスのそれぞれのデバイス識別情報を前記ホスト計算機に送信し、
   前記ホスト計算機は、前記生成された２以上の論理記憶デバイスのそれぞれのデバイス識別情報を関連付け、前記アプリケーションプログラムに提供する前記論理ボリュームを生成する、
   請求項１乃至８のうちのいずれか１項に記載の計算機システム。
10. 前記管理システムが、前記アプリケーションプログラムに提供されている第１の論理ボリューム代わりに前記アプリケーションプログラムに提供される第２の論理ボリュームが構築されるよう前記（Ａ）及び（Ｂ）を行う、
    請求項１乃至９のうちのいずれか１項に記載の計算機システム。
11. 前記第１の論理ボリュームは、負荷が高い論理ボリュームである、
    請求項１０記載の計算機システム。
12. 前記ホスト計算機が、前記第２の論理ボリュームをマウントし、前記第１の論理ボリュームから前記第２の論理ボリュームにデータをコピーし、前記第１の論理ボリュームをアンマウントする、
    請求項１０又は１１記載の計算機システム。
13. アプリケーションを実行するホスト計算機に接続され複数のマイクロプロセッサ（ＭＰ）を有し、論理記憶デバイスを生成し、各論理記憶デバイスを担当するＭＰが前記複数のＭＰから割り当てられ、前記１つの論理記憶デバイスに対するＩ／Ｏ（Input/Output）は、その論理記憶デバイスを担当するＭＰで行うようになっているストレージシステムと通信するインタフェースデバイスと、
    前記インタフェースデバイスに接続されたプロセッサと
    を有し、
    前記プロセッサが、
    （Ａ）前記複数のＭＰのそれぞれの性能を表す情報である性能管理情報と、前記アプリケーションに提供される論理ボリュームに要求される性能である要求性能とに基づいて、決定される２以上のＭＰの性能と前記要求性能との関係が所定の条件を満たすように、前記アプリケーションに提供される論理ボリュームを構成する２以上の論理記憶デバイスと、前記２以上の論理記憶デバイスに対する処理をそれぞれ担当する２以上のＭＰとを決定し、
    （Ｂ）前記決定した２以上の論理記憶デバイスに前記決定した２以上のＭＰを割り当てる、
    管理システム。
14. アプリケーションを実行するホスト計算機に接続され複数のマイクロプロセッサ（ＭＰ）を有し、論理記憶デバイスを生成し、各論理記憶デバイスを担当するＭＰが前記複数のＭＰから割り当てられ、前記１つの論理記憶デバイスに対するＩ／Ｏ（Input/Output）は、その論理記憶デバイスを担当するＭＰで行うようになっているストレージシステム、を管理する方法であって、
    前記アプリケーションに提供される論理ボリュームを構成する、２以上の論理記憶デバイスを決定し、
    前記２以上の論理記憶デバイスに対する処理をそれぞれ担当する２以上のＭＰを決定し、
    １つの論理記憶デバイスに１つのＭＰが割り当てられるように、前記決定した２以上の論理記憶デバイスに前記決定した２以上のＭＰを割り当てる、
    管理方法。

Images