JP6193373B2 - 複合型ストレージシステム及び記憶制御方法 - Google Patents

Description

本発明は、複数のストレージシステムを有するシステムである複合型ストレージシステム（例えばスケールアウト型のストレージシステム）での記憶制御に関する。

近年、ＳＳＤ（Solid State Drive）やフラッシュドライブなどの高速な記憶デバイスの開発が進んでいる。ストレージシステムにおいても、ＳＡＴＡ(Serial-ATA）ディスクやＳＡＳ（Serial Attached SCSI）ディスクなどのＨＤＤ（Hard Disk Drive）に加えて、高速なデバイスを搭載する構成が普及しつつある。今後もデバイスの開発は進み、デバイス１台当たりの処理性能も上昇する傾向にある。

例えば、フラッシュドライブのような非常に高速なデバイスをストレージシステムへ搭載した場合、ストレージシステム１台におけるＣＰＵ処理性能がフラッシュドライブの処理性能に追いつかず、ストレージシステムのＣＰＵ性能がネックとなり、フラッシュドライブのリソースを充分に利用することができない可能性がある。高速なデバイスは、一般に、ＨＤＤに比べ高価であり、リソースを充分に利用できないとなると運用コストの面でも問題である。

特許文献１は、複数のディスク制御装置と複数のディスク駆動装置とをネットワークまたはスイッチで接続した構成において、ディスク制御装置の負荷に応じてディスク制御装置間で管理するボリュームを交代させる技術を開示している。

特開平１１−２９６３１３号公報

特許文献１に開示された技術を利用することで、高速な記憶デバイスを用いて作成したボリュームを管理するストレージ制御装置を、ストレージ制御装置の負荷に応じてストレージ制御装置間で交代させることが可能である。高速な記憶デバイスの領域を複数のディスク制御装置間で融通し合って割り当てることは、経路制御装置或いはホストコンピュータといった管理元装置からの制御により行われる。

しかし、管理元装置として、ホストコンピュータから送信されるＩ／Ｏ（Input/Output）コマンドが経由するノードのような経路制御装置や、Ｉ／Ｏコマンドを発行するホストコンピュータが使用されると、Ｉ／Ｏコマンドの発行或いは流れにおいて管理元装置がボトルネックとなり得る。

このような問題は、複数のストレージシステム（例えばディスク制御装置）が共有するデバイスユニット（共有デバイスユニット）内の記憶デバイスが、高速な記憶デバイスではなく低速な記憶デバイス（例えば、一般的なＨＤＤ）である場合にもあり得る。

さらに、運用の一つとして考えられるストレージシステムに対し複数のホストが接続されている構成において、特許文献１の技術も用いると、ユーザがアクセス権のない記憶デバイス領域もシステム上で見ることが出来、ユーザビリティの面で問題である。

複数のストレージシステムに、記憶デバイスを有する共有デバイスユニットが接続される。共有記憶デバイスが、記憶デバイスに基づく複数の記憶領域を、複数のストレージシステムに提供する。各ストレージシステムが、複数の記憶領域のうち少なくとも自分に提供されている記憶領域のＩＤを含んだ割当管理情報を記憶し、割当管理情報に含まれているＩＤに対応した記憶領域を、複数のホスト計算機のうち自分に接続されているホスト計算機に提供する。

本発明によると、１つのデバイスユニットのリソースを複数のストレージシステムで有効に共有することができる。

図１は、第１実施例に係る計算機システムの構成図である。 図２は、第１実施例に係るデバイスの構成図である。 図３は、第１実施例に係るデバイス割当単位を説明する図である。 図４は、第１実施例に係る管理サーバの構成図である。 図５は、第１実施例に係るホストコンピュータ割当管理テーブルの構成図である。 図６は、第１実施例に係るＬＵＮ管理テーブルの構成図である。 図７は、第１実施例に係るストレージシステム割当管理情報の構成図である。 図８は、第１実施例に係るデバイス管理テーブルの構成図である。 図９は、第１実施例に係る共有デバイスユニット管理テーブルの構成図である。 図１０は、第１実施例に係る共有判定情報の構成図である。 図１１は、第１実施例に係る構成管理テーブルの構成図である。 図１２は、第１実施例に係る構成管理情報の構成図である。 図１３は、第１実施例に係る空き領域管理キューの構成図である。 図１４は、第１実施例に係る性能モニタリング情報管理テーブルの構成図である。 図１５は、第１実施例に係る内訳性能モニタリング情報の構成図である。 図１６は、第１実施例に係るホストコンピュータの構成図である。 図１７は、第１実施例に係るストレージコントローラの構成図である。 図１８は、第１実施例に係る集約共有デバイスユニット管理テーブルの構成図である。 図１９は、第１実施例に係るキャッシュ管理テーブルの構成図である。 図２０は、第１実施例に係るストレージシステムへ割り当てた領域を説明する図である。 図２１は、第１実施例に係る共有デバイスユニット新規登録処理のフローチャートである。 図２２は、第１実施例に係る新規領域割当処理のフローチャートである。 図２３は、第１実施例に係る割当領域確定処理のフローチャートである。 図２４は、第１実施例に係る空き領域管理キュー更新処理のフローチャートである。 図２５は、第１実施例に係るＩ／Ｏ処理要求処理のフローチャートである。 図２６は、第１実施例に係る或る時点の性能負荷状況を示す概念図である。 図２７は、第１実施例に係る担当ストレージシステムの変更後の割当領域の状況を示す概念図である。 図２８は、第１実施例に係る性能負荷分散処理のフローチャートである。 図２９は、第１実施例に係る性能負荷分散判定処理のフローチャートである。 図３０は、第１実施例に係る性能負荷分散実施処理のフローチャートである。 図３１Ａは、第１実施例に係る制御情報移行処理のフローチャートである。 図３１Ｂは、第１実施例に係るＬＵ移行に伴うホストコンピュータ設定変更処理のフローチャートである。 図３２は、第１実施例に係る移行元キャッシュディレクトリ・クリーン化処理のフローチャートである。 図３３は、第１実施例に係る移行先キャッシュディレクトリ・ダーティ化処理のフローチャートである。 図３４は、第１実施例に係るデバイス割当領域削除処理のフローチャートである。 図３５は、第２実施例に係るストレージコントローラの構成図である。 図３６は、第２実施例に係る共有デバイスユニット新規登録処理のフローチャートである。 図３７は、第３実施例に係るデバイスユニットの構成図である。 図３８Ａは、第３実施例に係るフラッシュストレージの構成図である。 図３８Ｂは、第３実施例に係る論理物理変換情報の構成図である。 図３９は、第３実施例に係るＩ／Ｏ優先・非優先キューの構成図である。 図４０は、第３実施例に係るストレージコントローラの構成図である。 図４１は、第３実施例に係るストレージシステム割当管理情報の構成図である。 図４２は、第３実施例に係る共有デバイスユニット新規登録処理のフローチャートである。 図４３は、第３実施例に係るＩ／Ｏ処理要求処理のフローチャートである。 図４４は、第３実施例に係るデータＩ／Ｏ処理のフローチャートである。 図４５は、第３実施例に係る性能負荷分散処理のフローチャートである。 図４６は、第４実施例に係るデバイス割当の概要を示す図である。 図４７は、第４実施例に係る管理サーバの構成図である。 図４８は、第４実施例に係るＬＵＮ管理テーブルの構成図である。 図４９は、第４実施例に係る仮想論理変換テーブルの構成図である。 図５０は、第４実施例に係る細粒度モニタテーブルの構成図である。 図５１は、第４実施例に係るストレージコントローラの構成図である。 図５２は、第４実施例に係るＬＵＮ管理テーブルの構成図である。 図５３は、第４実施例に係るパリティグループモニタテーブルの構成図である。 図５４は、第４実施例に係る構成管理情報の構成図である。 図５５は、第４実施例に係る空き領域管理キューの構成図である。 図５６は、第４実施例に係るＰｏｏｌ設定処理のフローチャートである。 図５７は、第４実施例に係る性能基準設定処理のフローチャートである。 図５８は、第４実施例に係る性能負荷分散実施処理のフローチャートである。 図５９は、第４実施例に係るＬＵ移行処理のフローチャートである。 図６０は、第４実施例に係るコピー処理のフローチャートである。 図６１は、第４実施例に係るホストパス設定処理のフローチャートである。

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

なお、以後の説明では「ａａａテーブル」等の表現にて本発明の情報を説明する場合があるが、これら情報は、テーブル等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」等について「ａａａ情報」と呼ぶことがある。

また、各情報の内容を説明する際に、「番号」という表現を用いるが、識別情報、識別子、名、名前等と置換可能である。

まず、第１実施例の概要について説明する。

１台のストレージシステムのＣＰＵの処理以上に、処理可能な高速デバイスの出現により、高速デバイスのリソースを有効に利用できない問題がある。これに対して、第１実施例に係る計算機システムでは、複数のストレージシステムで、１台のデバイスユニットを共有するようにする。具体的には、１台のデバイスユニット内の記憶領域を分割し、分割した記憶領域（デバイス割当領域）を各ストレージシステムへ割り当てることで、各ストレージシステムがデバイスユニットを共有できるようにする。ここで、共有するデバイスユニットへ接続されている各ストレージシステムにおいて、そのストレージシステムのシステム限界性能以上の負荷が掛かった状況では、ストレージシステムが性能ネックとなってしまい、デバイスユニットのリソースを有効に利用することができない。これに対して、第１実施例に係る計算機システムでは、ストレージシステム毎及びデバイス割当領域毎に性能モニタリング情報を採取し、その性能モニタリング情報を基に、デバイス割当領域を割当てるストレージシステムを変更することで、各ストレージシステムへの性能負荷の平準化を実施する。また、第１実施例に係る計算機システムでは、各ストレージシステムがデバイス割当領域の割当管理情報を保持するので、新規装置を設置する必要がなく、コスト増大を防ぐことができる。

以下、第１実施例に係る計算機システムの詳細を説明する。

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

計算機システムは、１以上のホストコンピュータ１０と、管理サーバ１４と、複数のストレージシステム１８（１８Ａ、１８Ｂ、１８Ｃ等）と、共有デバイスユニット３４とを含む。ホストコンピュータ１０、管理サーバ１４、及びストレージシステム１８は、ネットワーク２６を介して接続されている。

ホストコンピュータ１０はＩ／Ｆ１２を介してネットワーク２６に接続されている。ホストコンピュータ１０は、ブロックプロトコルによって、ネットワーク２６に接続されているストレージシステム１８と通信を行う。

管理サーバ１４は、計算機システムの全構成情報を保持している。また、管理サーバ１４は、Ｉ／Ｆ１６を介してネットワーク２６に接続されている。管理サーバ１４は、ネットワーク２６を介して、ストレージシステム１８や、ホストコンピュータ１０と通信を行う。

ストレージシステム１８は、管理サーバ１４からのコマンドに従って、記憶領域内の論理ユニット（ＬＵ）の構成等のパラメータを変更したり、性能モニタリング情報を収集したりする。ストレージシステム１８は、共有デバイスユニット３４及び／又は専有デバイスユニット３６の記憶媒体によって実現される記憶領域を管理し、ネットワーク２６に接続されたホストコンピュータ１０からのコマンドに従って、記憶領域に対するデータ（ユーザデータ）のリード・ライトを実行する。

ストレージシステム１８は、ストレージコントローラ２８（２８Ａ、２８Ｂ、２８Ｃ等）を有する。ストレージコントローラ２８は、ストレージシステム１８の制御処理を実行する。ストレージコントローラ２８は、ＦＥＰＫ（Front End Package）３２とＢＥＰＫ（Back End Package）３０とを有する。ＦＥＰＫ３２は、ホストコンピュータ１０や管理サーバ１４と通信するためのインタフェースである。ＦＥＰＫ３２は、ネットワークケーブル４４を介してネットワーク２６に接続されている。

また、ＦＥＰＫ３２は、イニシエータとしてのネットワークケーブル２２と、ターゲットとしてのネットワークケーブル２４を介してネットワーク２６に接続されている。ネットワークケーブル２２、ネットワークケーブル２４、及びネットワーク２６は、他のストレージシステム１８と通信するためのパスとなる。なお、他のストレージシステム１８と通信するパスの構成はこれに限られず、イニシエータもしくはターゲットとして設定変更可能なネットワークケーブルを用いる場合であれば、ネットワークケーブル２２とネットワークケーブル２４とを一本のネットワークケーブルとしても良く、ネットワークケーブル２２とネットワークケーブル２４とネットワークケーブル４４を一本のネットワークケーブルとしても良い。ＢＥＰＫ３０は、共有デバイスユニット３４や専有デバイスユニット３６と接続するためのインタフェースである。

ストレージシステム１８は、例えば、ストレージシステム１８Ｂ及び１８Ｃのように内部に専有デバイスユニット３６を備えていても良いし、ストレージシステム１８Ａのように内部に専有デバイスユニット３６を備えていなくても良い。専有デバイスユニット３６は、スイッチ（ＳＷ）３８と、デバイス４０とを含む。専有デバイスユニット３６のスイッチ３８は、専用デバイスユニット３６が属するストレージシステム１８のストレージコントローラ２８のＢＥＰＫ３０と接続されており、そのストレージコントローラ２８のみがデバイス４０にアクセス可能となっている。

共有デバイスユニット（デバイスユニット＃０という場合もある）３４は、スイッチ（ＳＷ）３８と、デバイス４０とを含む。デバイス４０は、記憶領域を有する。共有デバイスユニット３４のスイッチ３８は、ケーブル４２を介して、複数のストレージシステム１８のストレージコントローラ２８（具体的には、ストレージコントローラ１８のＢＥＰＫ３０）に接続されている。図１に示す例では、スイッチ３８は、ケーブル４２を介して、ストレージコントローラ１８Ａ、１８Ｂ、１８Ｃに接続されている。ケーブル４２は、例えば、ＳＡＳケーブルやＰＣＩｅケーブルなどで良い。このような構成により、共有デバイスユニット３４のデバイス４０の記憶領域に対して、複数のストレージシステム１８がアクセスすることができる。

図２は、第１実施例に係るデバイスの構成図である。

デバイス４０は、１以上の記憶媒体５０を含む。記憶媒体５０は、ケーブル５２を介して、スイッチ３８に接続されている。記憶媒体５０は、ＳＡＴＡディスクやＳＡＳディスク等のＨＤＤでも、ＳＳＤやフラッシュドライブ等の高速な記憶媒体でも良い。

図３は、第１実施例に係るデバイス割当単位を説明する図である。

パリティグループ３００は、複数の記憶媒体５０の記憶領域により構成される。パリティグループ３００は、障害に備えたデータの冗長性を考えて、所定のＲＡＩＤ（Redundant Array of Independent Disks）レベルのＲＡＩＤ構成となっている。ただし、パリティグループ３００を構成する記憶媒体は、同一デバイスユニットに格納されている必要がある。

パリティグループ３００は、１以上の論理ユニット（ＬＵ）３０２（図３では、３０２Ａ、３０２Ｂ、３０２Ｃ）で構成される。ＬＵ３０２は、所定のデータ単位であるチャンク３０６単位で分割されている。なお、ＬＵ３０２において、チャンク３０６をさらに分割したデータ単位であるページ３０４（３０４Ｃ）に分割するようにしても良い。なお、共有デバイスユニット３４及び専有デバイスユニット３６が、ストレージシステム１８に割り当てるデータ単位は、パリティグループ３００単位でも、ＬＵ３０２単位でも、チャンク３０６単位でも、ページ３０４単位でも良い。ただし、ホストコンピュータ１０からは、データ割当単位はＬＵ３０２として認識されるため、後述する性能負荷分散を考慮したデータ割当配置変更においては、ＬＵ３０２単位で実施することが望ましい。なお、以降においては、ストレージシステム１８へのデータ割当単位をＬＵ３０２とした場合を例に説明する。

図４は、第１実施例に係る管理サーバの構成図である。

管理サーバ１４は、ＣＰＵ６０と、メモリ６４と、Ｉ／Ｆ１６とを含む。ＣＰＵ６０と、メモリ６４と、Ｉ／Ｆ６２とは内部ケーブル６２を介して接続されている。ＣＰＵ６０は、メモリ６４に格納されたプログラムや、データを用いて各種処理を実行する。Ｉ／Ｆ１６は、ネットワーク２６に接続するためのインタフェースである。メモリ６４は、計算機システムの構成情報７０、性能モニタリング情報管理テーブル６８、キャッシュ領域６６、及びアプリケーションプログラム８０を含む。構成情報７０は、ホストコンピュータ割当管理テーブル７２、ＬＵＮ管理テーブル７４、デバイス管理テーブル７６、及び共有デバイスユニット管理テーブル７８を含む。

図５は、第１実施例に係るホストコンピュータ割当管理テーブルの構成図である。

ホストコンピュータ割当管理テーブル７２は、各ホストコンピュータ１０に割り当てられた記憶領域を管理するための管理情報９０（９０Ａ、９０Ｂ、９０Ｃ等）を格納する。図５においては、管理情報９０Ａがホストコンピュータ＃０についての管理情報であり、管理情報９０Ｂがホストコンピュータ＃１についての管理情報であり、管理情報９０Ｃがホストコンピュータ＃２についての管理情報である。

管理情報９０は、デフォルト・ストレージシステム番号（＃）９８（９８Ａ、９８Ｂ、９８Ｃ等）を保持するとともに、ホストＬＵＮ９２（９２Ａ、９２Ｂ、９２Ｃ等）と、オーナストレージシステム番号（＃）９４（９４Ａ、９４Ｂ、９４Ｃ等）と、サイズ９６（９６Ａ、９６Ｂ、９６Ｃ等）とを保持する。デフォルト・ストレージシステム番号９８は、ホストコンピュータ１０によるＩ／Ｏ処理を担当するデフォルトのストレージシステム（デフォルト・ストレージシステム）を識別するストレージシステム番号（デフォルト・ストレージシステム番号）である。ホストＬＵＮ９２は、ホストコンピュータ１０から認識されるＬＵの識別番号である。オーナストレージシステム番号９４は、ホストＬＵＮ９２に対応するＬＵの処理を担当するストレージシステムの番号である。オーナストレージシステム番号９４は、新規でＬＵが割当られた際は、各ホストコンピュータ１０のデフォルト・ストレージシステム番号９８に設定されるが、後述する性能負荷分散処理（図２８参照）を実行した場合には、変更される場合もある。サイズ９６は、ホストＬＵＮ９２に対応するＬＵのサイズである。

図６は、第１実施例に係るＬＵＮ管理テーブルの構成図である。

ＬＵＮ管理テーブル７４は、各ストレージシステムに関するストレージシステム割当管理情報１００（１００Ａ、１００Ｂ等）と、１以上の共有ＬＵＮ管理テーブル１０２（１０２Ａ等）とを含む。共有ＬＵＮ管理テーブル１０２は、共有デバイスユニット３４に格納されているＬＵのＬＵＮ情報を管理する。計算機システムに共有デバイスユニット３４が複数個存在する場合は、ＬＵＮ管理テーブル７４には、それぞれの共有デバイスユニット３４に対して１つの共有ＬＵＮ管理テーブル１０２が管理される。

共有ＬＵＮ管理テーブル１０２は、ホストＬＵＮ１０２ａと、内部ＬＵＮ１０２ｂと、サイズ１０２ｃと、パリティグループ番号（＃）１０２ｄと、ＲＡＩＤレベル１０２ｅ、先頭物理アドレス１０２ｆ、及びオーナストレージシステム番号１０２ｇを含む。

ホストＬＵＮ１０２ａは、ホストコンピュータ１０から認識されるＬＵの識別番号である。内部ＬＵＮ１０２ｂは、ストレージシステム１８で認識されるＬＵの識別番号（内部ＬＵＮ）である。内部ＬＵＮは、例えば、ストレージシステムの内部処理等で用いられる。サイズ１０２ｃは、ホストＬＵＮ１０２ａに対応するＬＵのサイズである。パリティグループ番号１０２ｄは、ホストＬＵＮ１０２ａに対応するＬＵが所属するパリティグループの番号である。ＲＡＩＤレベル１０２ｅは、パリティグループ番号１０２ｄのパリティグループのＲＡＩＤレベルである。先頭物理アドレス１０２ｆは、ホストＬＵＮ１０２ａに対応するＬＵのデータが格納されているデバイスにおける物理的なデータ格納場所の先頭を示す先頭物理アドレスである。オーナストレージシステム番号１０２ｇは、ホストＬＵＮ１０２ａに対応するＬＵを処理するストレージシステムの番号である。

図７は、第１実施例に係るストレージシステム割当管理情報の構成図である。なお、図７は、ストレージシステム＃１のストレージシステム割当管理情報１００Ｂを示している。なお、他のストレージシステムのストレージシステム割当管理情報も同様な構成となっている。

ストレージシステム割当管理情報１００Ｂは、ストレージシステム１８が専有するデバイスユニット３６におけるデータの割当てを管理するための情報であり、例えば、専有デバイスユニット管理テーブル１１０を含む。専有デバイスユニット管理テーブル１１０は、ストレージシステム１８に割当られたホストＬＵＮ１１０ａに関する情報を管理している。

専有デバイスユニット管理テーブル１１０は、ホストＬＵＮ１１０ａ、内部ＬＵＮ１１０ｂ、サイズ１１０ｃ、パリティグループ番号１１０ｄ、ＲＡＩＤレベル１１０ｅ、先頭物理アドレス１１０ｆ、及びデバイスユニット番号（＃）１１０ｇを含む。

ホストＬＵＮ１１０ａは、ホストコンピュータ１０から認識されるＬＵの識別番号である。内部ＬＵＮ１１０ｂは、ストレージシステムで認識されるＬＵの識別番号（内部ＬＵＮ）である。内部ＬＵＮは、例えば、ストレージシステムの内部処理等で用いられる。サイズ１１０ｃは、ホストＬＵＮ１１０ａに対応するＬＵのサイズである。パリティグループ番号１１０ｄは、ホストＬＵＮ１１０ａに対応するＬＵが所属するパリティグループの番号である。ＲＡＩＤレベル１１０ｅは、パリティグループ番号１１０ｄのパリティグループのＲＡＩＤレベルである。先頭物理アドレス１１０ｆは、ホストＬＵＮ１１０ａに対応するＬＵのデータが格納されているデバイスにおける物理的なデータ格納場所の先頭を示す先頭物理アドレスである。デバイスユニット番号１１０ｇは、ホストＬＵＮ１１０ａに対応するＬＵを格納するデバイスユニットの番号である。

図８は、第１実施例に係るデバイス管理テーブルの構成図である。

デバイス管理テーブル７６は、各デバイスユニット単位でデバイスユニット管理テーブル１６０（１６０Ａ、１６０Ｂ等）を格納する。デバイスユニット管理テーブル１６０は、デバイスユニット（３４，３６等）の構成情報が格納される。

デバイスユニット管理テーブル１６０は、パリティグループ番号１６０ａ、ＲＡＩＤレベル１６０ｂ、デバイスＩＤ１６０ｃ、及びサイズ１６０ｄを含む。パリティグループ番号１６０ａは、パリティグループの番号である。ＲＡＩＤレベル１６０ｂは、パリティグループ番号１６０ａのパリティグループのＲＡＩＤレベルである。デバイスＩＤ１６０ｃは、パリティグループを構成する記憶媒体５０の識別番号である。サイズ１６０ｄは、パリティグループのサイズである。

図９は、第１実施例に係る共有デバイスユニット管理テーブルの構成図である。

共有デバイスユニット管理テーブル７８は、共有判定情報１８０（図１０参照）と、構成管理テーブル１８２（図１１参照）とを含む。

図１０は、第１実施例に係る共有判定情報の構成図である。

共有判定情報１８０は、共有判定管理テーブル１９４と、共有デバイスユニット使用可能管理キュー１９６とを含む。

共有判定管理テーブル１９４は、計算機システムを構成する全デバイスユニットについて、当該デバイスユニットを複数のストレージシステムが共有しているか否かの情報を管理するテーブルであり、各デバイスユニットについて、デバイスユニット番号１９４ａと、共有ビット１９４ｂとを格納する。

デバイスユニット番号１９４ａは、デバイスユニットを識別する識別番号である。共有ビット１９４ｂは、デバイスユニット番号１９４ａのデバイスユニットが複数のストレージシステムにより共有されているか否かを示すビットであり、例えば、デバイスユニットが共有されている場合には、「１」が設定され、デバイスユニットが共有されていない場合には、「０」が設定される。計算機システムが、図１に示す構成である場合には、デバイスユニット番号１９４ａが「０」に対して、共有ビット１９４ｂが「１」が設定される。

共有デバイスユニット使用可能管理キュー１９６は、共有判定管理テーブル１９４で共有ビット１９４ｂが「１」のデバイスユニット番号１９４ａの内、共有デバイスユニットとして使用可能なものを管理する。共有デバイスユニット使用可能管理キュー１９６は、ＦＤＫＵＱ１９８を作成し、使用可能な共有デバイスユニットを示すエントリ（例えば、デバイスユニット番号を示すエントリ）を、ＦＤＫＵＱ１９８に接続する。図１０の例では、ＦＤＫＵＱ１９８には、「０」が含まれたエントリ１９９が接続されている。エントリ１９９は、デバイスユニット番号０のデバイスユニット（共有デバイスユニット３４）が使用可能であることを示している。

図１１は、第１実施例に係る構成管理テーブルの構成図である。

構成管理テーブル１８２は、共有デバイスユニット毎に共有デバイスユニット管理テーブル２００を保持する。共有デバイスユニット管理テーブル２００は、共有デバイスユニットの構成管理情報（図１２参照）２０２及び空き領域管理キュー２０４（図１３参照）を含む。

図１２は、第１実施例に係る構成管理情報の構成図である。

構成管理情報２０２は、内部ＬＵＮ２０２ａと、ストレージシステム番号（＃）２０２ｂとを含む。内部ＬＵＮ２０２ａは、共有デバイスユニット３４内のストレージシステム１８で認識されるＬＵの識別番号（内部ＬＵＮ）である。ストレージシステム番号２０２ｂは、内部ＬＵＮ２０２ａに対応するＬＵに対して処理を実行するストレージシステム１８の番号である。

図１３は、第１実施例に係る空き領域管理キューの構成図である。

空き領域管理キュー２０４は、１台の共有デバイスユニット３４に対して１セット作成され、共有デバイスユニット３４における空き領域となっているＬＵを管理するキューである。空き領域管理キュー２０４は、先頭エントリ２２０に、空き領域となっている内部ＬＵを示すエントリ２２２、２２４、２２６等を接続する。図１３に示す例では、デバイスユニット＃０のデバイスユニット（共有デバイスユニット３４）について、空き領域管理キューの先頭エントリ２２０が作成され、先頭エントリ２２０に対して、内部ＬＵＮ「５」を示すエントリ２２２が接続され、その次に、内部ＬＵＮ「６」を示すエントリ２２４が接続され、更に、内部ＬＵＮ「７」を示すエントリ２２６が接続されている。この空き領域管理キュー２０４によると、内部ＬＵＮ「５」、「６」及び「７」が空き領域であることがわかる。

空き領域管理キュー２０４は、次のように管理される。すなわち、ホストＬＵＮの削除が発生した場合は、管理サーバ１４は、当該ホストＬＵＮに対応する内部ＬＵＮのＬＵを格納する共有デバイスユニットの空き領域管理キュー２０４に、この内部ＬＵＮに対応するエントリを追加する。また、ホストＬＵＮが新たに設定された場合は、管理サーバ１４は、空き領域管理キュー２０４を見て、割当て可能なＬＵを示す内部ＬＵＮを判別し、当該内部ＬＵＮのエントリを空き領域管理キュー２０４から削除する。

図１４は、第１実施例に係る性能モニタリング情報管理テーブルの構成図である。

性能モニタリング情報管理テーブル６８は、ストレージシステム別性能モニタリング情報２３０と、ストレージシステム内の性能モニタリング情報を管理する内訳性能モニタリング情報２３２（図１５参照）とを含む。ストレージシステム別性能モニタリング情報２３０は、ストレージシステム毎の性能負荷を管理するテーブルであり、ストレージシステム番号（＃）２３０ａと、性能負荷２３０ｂとを管理する。ストレージシステム番号２３０ａは、ストレージシステム１８を識別する識別番号である。性能負荷２３０ｂは、例えば、ストレージシステム番号２３０ａのストレージシステム１８のＣＰＵ２６０（図１７参照）の負荷である。本実施例では、ＣＰＵ２６０の負荷として、例えば、ＣＰＵ２６０が処理したＩ／Ｏの１秒あたりの数（平均Ｉ／Ｏ数）としている。

図１５は、第１実施例に係る内訳性能モニタリング情報の構成図である。

内訳性能モニタリング情報２３２は、ストレージシステム１８のそれぞれに対するストレージシステム毎性能モニタリング情報２４０（２４０Ａ、２４０Ｂ等）を含む。ストレージシステム毎性能モニタリング情報２４０は、内部ＬＵＮ２４０ａと、性能負荷２４０ｂとを含む。内部ＬＵＮ２４０ａは、ストレージシステム毎性能モニタリング情報２４０に対応するストレージシステム１８が処理を担当しているＬＵの内部ＬＵＮである。性能負荷２４０ｂは、内部ＬＵＮ２４０ａに対応するＬＵに対する性能負荷である。

図１６は、第１実施例に係るホストコンピュータの構成図である。なお、図１６は、ホストコンピュータ＃０の構成を示しているが、他のホストコンピュータの構成も同様である。

ホストコンピュータ１０（１０Ａ）は、ＣＰＵ２５２と、Ｉ／Ｆ１２と、メモリ２５４とを含む。ＣＰＵ２５２と、メモリ２５４と、Ｉ／Ｆ１２とは、内部ケーブル２５０を介して接続されている。

ＣＰＵ２５２は、メモリ２５４に格納されたプログラムを実行することにより、各種処理を実行する。メモリ２５４は、構成情報２５８と、キャッシュ領域２５６とを含む。構成情報２５８は、当該ホストコンピュータ１０に割当られた領域を管理するホストコンピュータ割当管理テーブル２５７を含む。ホストコンピュータ割当管理テーブル２５７は、管理サーバ１４が保持しているホストコンピュータ割当管理テーブル７２内の当該ホストコンピュータ１０に対応するホストコンピュータ割当管理情報９０と同等な情報を記憶する。図１６の例では、ホストコンピュータ割当管理テーブル２５７は、図５のホストコンピュータ＃０に対応するホストコンピュータ割当管理テーブル９０Ａと同等な情報を記憶している。

図１７は、第１実施例に係るストレージコントローラの構成図である。図１７は、ストレージシステム１８Ａ（ストレージシステム＃０）のストレージコントローラ２８Ａを例に示している。なお、他のストージコントローラの構成も同様な構成となっている。

ストレージコントローラ２８は、ＣＰＵ２６０と、ＦＥＰＫ３２と、ＢＥＰＫ３０と、メモリ２６６とを含む。ＣＰＵ２６０、ＦＥＰＫ３２、ＢＥＰＫ３０、及びメモリ２６６は、内部ネットワーク２６２を介して接続されている。

ＣＰＵ２６０は、メモリ２６６に格納されたプログラムを実行することにより各種処理を実行する。メモリ２６６は、構成情報２６８と、性能モニタリング情報バッファ領域２７０と、キャッシュ領域２７２と、キャッシュ管理テーブル２７４（図１９参照）と、ストレージ制御プログラム２７６とを格納する。

構成情報２６８は、ストレージシステムに割当られた領域（割当領域）を管理するためのストレージシステム割当管理テーブル２７７と、計算機システムにおける共有デバイスユニット３４内の領域を管理するための集約共有デバイスユニット管理テーブル２７８（図１８参照）とを含む。ストレージシステム割当管理テーブル２７７は、管理サーバ１４が保持しているＬＵＮ管理テーブル７４のストレージシステム割当管理情報１００と同等な情報を格納する。

性能モニタリング情報バッファ領域２７０は、ストレージシステム１８で採取した性能モニタリング情報を管理サーバ１４へある程度纏めて送信するために、一時的に性能モニタリング情報を溜めておくバッファ領域である。ストレージ制御プログラム２７６は、ストレージシステムにおける各種処理を実行するためのプログラムである。キャッシュ領域２７２は、デバイスユニットに書き込むデータ、又はデバイスユニットから読み出されたデータを一時的に格納する領域である。

図１８は、第１実施例に係る集約共有デバイスユニット管理テーブルの構成図である。図１８の例では、ストレージコントローラ２８Ａ内の集約共有デバイスユニット管理テーブル２７８（２７８Ａ）を示している。

集約共有デバイスユニット管理テーブル２７８は、計算機システムのストレージコントローラ２８毎に管理されている。集約共有デバイスユニット管理テーブル２７８は、計算機システムに存在する共有デバイスユニット３４毎の情報を管理する集約共有管理テーブル２７９（２７０Ａ等）を含む。計算機システムに複数台の共有デバイスユニット３４が存在する場合は、複数個の集約共有管理テーブル２７９がストレージシステム毎の集約共有デバイスユニット管理テーブル２７８に格納される。

集約共有管理テーブル２７９は、管理サーバ１４に格納されている共有ＬＵＮ管理テーブル１０２とほぼ同内容の情報を格納する。集約共有管理テーブル２７９は、ホストＬＵＮ２７９ａ、内部ＬＵＮ２７９ｂ、サイズ２７９ｃ、パリティグループ番号２７９ｄ、ＲＡＩＤレベル２７９ｅ、先頭物理アドレス２７９ｆ、及びオーナビット２７９ｇを含む。ホストＬＵＮ２７９ａ、内部ＬＵＮ２７９ｂ、サイズ２７９ｃ、パリティグループ番号２７９ｄ、ＲＡＩＤレベル２７９ｅ、及び先頭物理アドレス２７９ｆは、管理サーバ１４に格納されている共有ＬＵＮ管理テーブル１０２の同名の情報と同内容である。

オーナビット２７９ｇは、当該ストレージコントローラ２８を含むストレージシステム１８が、ホストＬＵＮ２７９ａのＬＵを処理するストレージシステム１８であるか否かを示すビットであり、ホストＬＵＮ２７９ａのＬＵを処理するストレージシステム１８である場合には、ＯＮ（例えば、「１」）が設定され、ホストＬＵＮ２７９ａのＬＵを処理するストレージシステムでない場合には、ＯＦＦ（例えば、「０」）が設定される。

図１９は、第１実施例に係るキャッシュ管理テーブルの構成図である。

キャッシュ管理テーブル２７４は、キャッシュの管理単位の状態を管理するためのテーブルであり、キャッシュの管理単位毎にキャッシュ管理エントリ２８２を格納する。キャッシュ管理エントリ２８２には、キャッシュアドレス２８４、格納データ識別情報２８６、ダーティフラグ２８８、及びデステージ許可フラグ２９０が格納される。キャッシュアドレス２８４は、キャッシュされているデータのアドレスである。格納データ識別情報２８６は、キャッシュされているデータ（格納データ）を識別する識別情報である。ダーティフラグ２８８は、キャッシュされているデータがダーティデータ（すなわち、記憶媒体５０に反映されていないデータ）であるか否かを示すフラグである。デステージ許可フラグ２９０は、キャッシュされているデータを記憶媒体５０にデステージ可能であるか否かを示すフラグである。

図２０は、第１実施例に係るストレージシステムへ割り当てた領域を説明する図である。

共有デバイスユニット３４のスイッチ３８には、ＳＡＳ／ＰＣＩｅなどのケーブル４２を介して、複数台のストレージシステム１８が接続されている。デバイス４０の記憶領域は、論理的な空間で管理されており、この論理空間は、ストレージシステム＃０（ストレージシステム１８Ａ）に割り当てられた割当領域３１０と、ストレージシステム＃１（ストレージシステム１８Ｂ）に割り当てられた割当領域３１２と、ストレージシステム＃２（ストレージシステム１８Ｃ）に割り当てられた割当領域３１４とに分けられて管理されており、各ストレージシステム１８がアクセス可能な領域が限定されるように管理されている。

次に、第１実施例に係る計算機システムにおける処理動作について説明する。

まず、共有デバイスユニットをストレージシステムへ新規登録する共有デバイスユニット新規登録処理について説明する。

図２１は、第１実施例に係る共有デバイスユニット新規登録処理のフローチャートである。

管理サーバ１４は、新規登録するデバイスユニットの指定を計算機システムの管理ユーザから受け付け、共有判定管理テーブル１９４に、指定されたデバイスユニットのデバイスユニット番号１９４ａの行を追加し、当該行の共有ビット１９４ｂを「１」に設定する（ステップ３２０）。なお、共有判定管理テーブル１９４に、指定されたデバイスユニットのデバイスユニット番号１９４ａの行が存在する場合は、行の追加作業を行う必要はなく、対応する行の共有ビット１９４ｂを「１」に設定する。

次に、管理サーバ１４は、指定されたデバイスユニット内の論理構成（ＲＡＩＤグループ、ＬＵ等）の作成を、代表のストレージシステム１８へ指示する（ステップ３２２）。ここで、代表のストレージシステム１８とは、論理構成を作成したりする処理を主導するストレージシステム１８を指し、計算機システムにおいて１台あれば良く、予めいずれかのストレージシステム１８に決定しておいても良いし、任意のストレージシステム１８を選択するようにしても良い。

次に、ステップ３２４において、管理サーバ１４から指示された代表のストレージシステム１８は、当該デバイスユニット３４内の複数の記憶媒体５０から、パリティグループ３００を作成し、そのパリティグループ３００からＬＵ３０２を作成する。その際、ストレージシステム１８は、内部ＬＵＮとホストＬＵＮとの設定も実施する。作成するパリティグループ３００やＬＵ３０２の構成に関しては、予めデフォルト値を管理サーバ１４が代表ストレージシステム１８に設定していても良いし、ステップ３２２において、管理サーバ１４が代表ストレージシステム１８へ構成を指示しても良い。ＬＵ３０２の作成後、管理サーバ１４は、ＬＵＮ管理テーブル７４の共有ＬＵＮ管理テーブル１０２を作成し、新規作成したＬＵ３０２の管理情報を登録する。

次に、ステップ３２６において、管理サーバ１４は、新規登録したＬＵ３０２について、ストレージシステム１８への新規割当を実施するか判定する。

この結果、新規登録したＬＵ３０２について、ストレージシステムへの新規割当を実施する場合（ステップ３２６：Ｙｅｓ）は、ステップ３２８において、管理サーバ１４は、新規作成したＬＵ３０２にストレージシステム番号を振り、当該ストレージシステム番号を、ＬＵＮ管理テーブル７４の共有ＬＵＮ管理テーブル１０２のオーナストレージシステム番号１０２ｇとして登録する。ここで、ストレージシステム番号の振り方は、当該共有デバイスユニット３４に接続されている全ストレージシステムに対し、ラウンド・ロビン方式等で均等に割り振っても良いし、１つのストレージシステムに固定して割り振っても良い。ただし、性能面を考慮すると、ラウンド・ロビン方式の方が実用的である。

一方、新規登録したＬＵ３０２について、ストレージシステムへの新規割当を実施しない場合（ステップ３２６：Ｎｏ）、又はステップ３２８の終了後、ステップ３３０において、管理サーバ１４は、更新したＬＵＮ管理テーブル７４の共有ＬＵＮ管理テーブル１０２の情報を、当該共有デバイスユニット３４に接続されている全ストレージシステム１８のストレージコントローラ２８内の集約共有デバイスユニット管理テーブル２７８へ反映する。その際、管理サーバ１４は、集約共有デバイスユニット管理テーブル２７８の中の集約共有管理テーブル２７９のそのストレージシステム１８が処理を担当するＬＵのホストＬＵＮ２７９ａに対応する行のオーナビット２７９ｇを「１」に設定する。

次に、ステップ３３２において、管理サーバ１４は、ストレージシステム１８が未割当の新規作成したＬＵＮがあるか否かを確認する。

この結果、ストレージシステムが未割当の新規作成したＬＵＮがある場合（ステップ３３２：Ｙｅｓ）は、ステップ３３４において、管理サーバ１４は、未割当の新規作成したＬＵＮに対応するエントリを、共有デバイスユニット管理テーブル７８の当該共有デバイスユニット管理テーブル２００の空き領域管理キュー２０４に追加する。

次に、ステップ３３６において、管理サーバ１４は、当該共有デバイスユニット３４のデバイスユニット番号に対応するエントリを共有デバイスユニット使用可能管理キュー１９６に追加し、共有デバイスユニット新規登録処理を終了する。なお、ストレージシステム１８が未割当の新規作成したＬＵＮがない場合（ステップ３３２：Ｎｏ）は、共有デバイスユニット新規登録処理を終了する。

次に、共有デバイスユニット３４の新規領域を割り当てる新規領域割当処理を説明する。

図２２は、第１実施例に係る新規領域割当処理のフローチャートである。

新規領域割当処理は、例えば、図２１のステップ３２６において、ストレージシステムへ新規割当を実施しなかった場合や、共有デバイスユニット３４内のＬＵ３０２をストレージコントローラ２８から削除した場合に実行される処理であり、例えば、管理サーバ１４やホストコンピュータ１０からの領域の割当て要求に基づいて実行が開始される。

最初に、ステップ３４０において、管理サーバ１４は、使用可能な共有デバイスユニット３４があるか否かを、共有デバイスユニット管理テーブル７８の共有デバイスユニット使用可能管理キュー１９６にエントリがあるか否かを確認することにより判定する。

この結果、使用可能な共有デバイスユニット３４がないと判定した場合（ステップ３４０：Ｎｏ）は、管理サーバ１４は、新規領域割当可能な共有デバイスユニット３４が存在しない旨を、ホストコンピュータ１０又はストレージシステム１８を構築する別の管理サーバ１４に通知し、新規領域割当処理を終了する。

一方、使用可能な共有デバイスユニット３４があると判定した場合（ステップ３４０：Ｙｅｓ）は、ステップ３４２において、管理サーバ１４は、共有デバイスユニット使用可能管理キュー１９６の先頭のエントリ１９９が示す共有デバイスユニット番号に対応する共有デバイスユニット３４が使用可能であると考え、当該共有デバイスユニット３４に対応する共有デバイスユニット構成管理テーブル２００の空き領域管理キュー２０４にエントリがあるか判定する。

この結果、共有デバイスユニット３４に対応する共有デバイスユニット構成管理テーブル２００の空き領域管理キュー２０４にエントリがない場合（ステップ３４２：Ｎｏ）は、ステップ３４６において、管理サーバ１４は、共有デバイスユニット使用可能管理キュー１９６において、当該共有デバイスユニット３４に対応する共有デバイスユニット番号のエントリを削除し、処理をステップ３４０へ進める。

一方、共有デバイスユニット３４に対応する共有デバイスユニット構成管理テーブル２００の空き領域管理キュー２０４にエントリがある場合（ステップ３４２：Ｙｅｓ）は、管理サーバ１４は、ステップ３４８において、当該共有デバイスユニット構成管理テーブル２００の空き領域管理キュー２０４の先頭のエントリが示すＬＵＮのＬＵが使用可能（割当可能）であると考え、当該ＬＵを割当領域と決定し、割当領域確定処理（図２３参照）を実施する。

次に、ステップ３５０において、管理サーバ１４は、空き領域管理キュー２０４を更新する空き領域管理キュー更新処理（図２４参照）を実施し、新規領域割当処理を終了する。

図２３は、第１実施例に係る割当領域確定処理のフローチャートである。

割当領域確定処理は、図２２のステップ３４８の処理に対応する。

最初に、ステップ３６０において、管理サーバ１４は、割当領域が決定された共有デバイスユニット３４に対応する共有デバイスユニット構成管理テーブル２００の構成管理情報２０２における、割当可能なＬＵに対応する内部ＬＵＮ２０２ａに対応するストレージシステム番号２０２ｂを更新する。オーナストレージシステム番号２０２ｂは、デフォルト値としても良いし、ストレージシステム１８の中の最小の番号を設定するようにしても良い。

次に、ステップ３６２において、管理サーバ１４は、共有デバイスユニット３４のＬＵＮ管理テーブル７４の共有ＬＵＮ管理テーブル１０２に関し、割当可能なＬＵのＬＵＮに対応するオーナストレージシステム番号１０２ｇを、ステップ３６０で更新したオーナストレージシステム番号２０２ｂに更新する。

次に、ステップ３６４において、管理サーバ１４は、ステップ３６０で更新したオーナストレージシステム番号２０２ｂに対応するストレージシステム１８の共有デバイスユニット管理テーブル２７８における、割当対象の共有デバイスユニット３４に対応する集約共有管理テーブル２７９へアクセスする。次に、管理サーバ１４は、集約共有管理テーブル２７９において、ＬＵのＬＵＮに対応するオーナビット２７９ｇをＯＮ（「１」）に更新する。

次に、ステップ３６６において、管理サーバ１４は、ホストコンピュータ割当管理テーブル７２の割当先のホストコンピュータ１０に対応する管理情報９０にアクセスする。管理サーバ１４は、割当先のホストコンピュータ１０に対応する管理情報９０において、割当可能なＬＵに対応するホストＬＵＮ９２に対応するオーナストレージシステム番号９４を、ステップ３６０で更新したストレージシステム番号２０２ｂに更新する。

最後に、管理サーバ１４は、割当先のホストコンピュータ１０に格納されているホストコンピュータ割当管理テーブル２５７にアクセスし、ステップ３６６と同様に、割当可能なＬＵに対応するホストＬＵＮに対応するオーナストレージシステム番号を、ステップ３６０で更新したオーナストレージシステム番号２０２ｂに更新し、割当領域確定処理を終了する。

図２４は、第１実施例に係る空き領域管理キュー更新処理のフローチャートである。

空き領域管理キュー更新処理は、図２２のステップ３５０の処理に対応する。

最初に、ステップ３６１において、管理サーバ１４は、新規に割り当てたＬＵ３０２のＬＵＮを示すエントリを割当対象の共有デバイスユニット３４の構成管理テーブル１８２の空き領域管理キュー２０４から削除する。次に、ステップ３６３において、管理サーバ１４は、ステップ３６１でアクセスした空き領域管理キュー２０４にエントリが存在するか判定する。

この結果、ステップ３６１でアクセスした空き領域管理キュー２０４にエントリが存在する場合（ステップ３６３：Ｙｅｓ）は、管理サーバ１４は、空き領域管理キュー更新処理を終了する。

一方、ステップ３６１でアクセスした空き領域管理キュー２０４にエントリが存在しない場合（ステップ３６３：Ｎｏ）は、ステップ３６５において、管理サーバ１４は、共有デバイスユニット管理テーブル７８の共有判定情報１８０の共有デバイスユニット使用可能管理キュー１９６から、当該共有デバイスユニット３４のデバイスユニット番号を示すエントリ（例えば、エントリ１９９）を削除して、空き領域管理キュー更新処理を終了する。

次に、ホストコンピュータ１０からＩ／Ｏ処理要求を受け付けた際に実行されるＩ／Ｏ処理要求処理について説明する。Ｉ／Ｏ処理要求は、例えば、Ｉ／Ｏ処理対象のホストＬＵＮの情報などを含むコマンドとして発行される。

図２５は、第１実施例に係るＩ／Ｏ処理要求処理のフローチャートである。

最初に、ステップ３７０において、ホストコンピュータ１０は、Ｉ／Ｏ処理要求元のホストコンピュータ１０に格納されているホストコンピュータ割当管理テーブル２５７にアクセスし、Ｉ／Ｏ処理要求の対象となるＬＵ（図２５の処理の説明において対象ＬＵという）を処理するストレージシステム１８に対応するオーナストレージシステム番号を確認する。

次に、ステップ３７２において、ストレージシステム１８は、ステップ３７０で確認したストレージシステム番号に対応するストレージシステム１８のストレージシステムコントローラ２８にアクセスし、構成情報２６８を参照し、対象ＬＵのホストＬＵＮに対応する内部ＬＵＮ（１１０ｂ、２７９ｂ）を確認する。

次に、ステップ３７３において、ストレージシステム１８は構成情報２６８の対象ＬＵＮに対応するオーナビット２７９ｇがＯＮ、つまり当該ストレージシステム１８が処理可能なＬＵなのか判定する。

結果、ストレージシステム１８が処理不可能なＬＵの場合（ステップ３７３：Ｎｏ）、当該ＬＵを処理担当するストレージシステム１８が変更となっているため、ステップ４６１において、それに伴うホストコンピュータ１０の設定変更の処理を実施する。ステップ４６１の処理内容の詳細は、図３１Ｂで説明する。

また、ストレージシステム１８が処理可能なＬＵの場合（ステップ３７３：Ｙｅｓ）や、ステップ４６１を終了した場合は、次に、ステップ３７４において、ストレージシステム１８は、当該内部ＬＵＮに対応する記憶媒体５０へアクセスし、当該内部ＬＵＮに対応する先頭物理アドレスのデータ領域に対し、Ｉ／Ｏ処理を実施する。

最後に、ステップ３７６において、ストレージシステム１８は、ステップ３７０で確認したストレージシステム番号に対応するストレージシステム１８のストレージコントローラ２８にアクセスし、性能モニタリング情報バッファ領域２７０へ当該Ｉ／Ｏ処理のＩＯＰＳ性能に関する情報を格納し、Ｉ／Ｏ処理要求処理を終了する。

次に、割当領域の担当ストレージシステムを変更する処理の概要を説明する。

図２６は、第１実施例に係る或る時点における性能負荷状況を示す概念図である。図２７は、第１実施例に係る担当ストレージシステムを変更した後の割当領域の状況を示す概念図である。

或る時点においては、図２６に示すように、割当領域３１０がストレージシステム＃０（ストレージシステム１８Ａ）に割り当てられ、ＬＵＮ＃０の管理情報３８４は、ストレージシステム＃０（ストレージシステム１８Ａ）に格納されているとする。また、ストレージシステム＃０（ストレージシステム１８Ａ）が性能負荷大であり、ストレージシステム＃１（ストレージシステム１８Ｂ）が性能負荷小であり、複数のストレージシステム１８間で性能負荷のバランシングが取れていない状態とする。ストレージシステム＃０は、ケーブル３８６及びスイッチ３８を介して、ＬＵＮ＃０のＬＵ（割当領域３１０）にアクセスする。

このような状況において、管理サーバ１４は、図２７に示すように割当領域の担当ストレージシステム１８を変更する。すなわち、管理サーバ１４は、複数ストレージシステム１８間の性能負荷のバランシングを平準化し、共有デバイスユニット３４のリソースを効果的に利用するために、ＬＵＮ＃０のＬＵ（割当領域３１０）のオーナストレージシステム（担当ストレージシステム）を、性能負荷が大きいストレージシステム＃０（ストレージシステム１８Ａ）から、性能負荷が小さいストレージシステム＃１（ストレージシステム１８Ｂ）へ変更する。具体的な方法としては、管理サーバ１４は、ストレージシステム＃０（ストレージシステム１８Ａ）に格納していたＬＵＮ＃０の管理情報３８４を、ストレージシステム＃１（ストレージシステム１８Ｂ）に格納するように、管理情報更新処理３９２を実行すれば良く、ユーザデータのデバイスレベルでの移動は不要である。

次に、割当領域の担当ストレージシステムを変更することにより性能負荷を分散させる性能負荷分散処理を説明する。

図２８は、第１実施例に係る性能負荷分散処理のフローチャートである。

性能負荷分散処理の概要は、図２６及び図２７で説明した通りである。

最初に、ステップ４００において、各ストレージシステム１８は、自ストレージシステム１８の性能モニタリング情報バッファ領域２７０に格納している性能負荷に関する情報（性能負荷情報）を管理サーバ１４へ送信する。性能負荷情報の送信のタイミングは、例えば、一定時間毎の周期的なタイミングであっても良く、このタイミングは、管理サーバ１４からストレージシステム１８へ性能負荷情報送信要求コマンドを送信することにより制御しても良いし、ストレージシステム１８内のストレージ制御プログラム２７８が制御しても良い。

次に、ステップ４０２において、管理サーバ１４は、ステップ４００で受信した性能負荷情報を、性能モニタリング情報管理テーブル６８に反映させて、性能モニタリング情報管理テーブル６８を更新する。

次に、ステップ４０４において、管理サーバ１４は、ストレージシステム１８間の性能負荷分散判定モードが「ＯＮ」か否かを判定する。例えば、性能負荷分散判定モードは、管理サーバ１４のアプリケーションプログラム８０により設定される。

この結果、性能負荷分散判定モードが「ＯＮ」となっていない場合（ステップ４０４：Ｎｏ）は、管理サーバ１４は、性能負荷分散処理を終了する。例えば、管理ユーザが手動でストレージシステム１８間の性能負荷を調整したい場合や、ＬＵ３０２を処理するストレージシステム１８を固定したい場合などには、このような処理の流れとなる。

一方、性能負荷分散判定モードが「ＯＮ」となっている場合（ステップ４０４：Ｙｅｓ）は、ステップ４０６において、管理サーバ１４は、性能負荷分散判定処理（図２９参照）を実施する。

次に、ステップ４０８において、管理サーバ１４は、ステップ４０６の結果より、ストレージシステム１８間で性能負荷分散を実施する必要があるか否かを判定する。

この結果、性能負荷分散を実施する必要がないと判定した場合（ステップ４０８：Ｎｏ）は、管理サーバ１４は、性能負荷分散処理を終了する。

一方、性能負荷分散を実施する必要があると判定した場合（ステップ４０８：Ｙｅｓ）は、ステップ４１０において、管理サーバ１４は、ストレージシステム１８間の性能負荷分散実施処理（図３０参照）を実施し、その後、性能負荷分散処理を終了する。

図２９は、第１実施例に係る性能負荷分散判定処理のフローチャートである。

性能負荷分散判定処理は、図２８のステップ４０６の処理に対応する。なお、図２９では、一例をあげて説明する。

最初に、ステップ４２０において、管理サーバ１４は、性能モニタリング情報管理テーブル６８のストレージシステム別性能モニタリング情報２３０を参照し、最大の性能負荷２３０ｂのストレージシステム番号２３０ａと、最小の性能負荷２３０ｂのストレージシステム番号２３０ａとを確認する。その際、最小の性能負荷２３０ｂであるストレージシステム１８のＣＰＵ２６０の使用率が一定値、例えば８５％、を超えている場合は、最小の性能負荷のストレージシステム１８の対象から外す。このようにする理由は、例えば、性能負荷２３０ｂをＩＯＰＳ性能値とした場合、ストレージシステム１８によってシステム限界性能値が異なるため、既にＣＰＵ２６０の使用率が高いストレージシステム１８に新たな性能負荷を発生させないためである。同様の理由により、最大の性能負荷２３０ｂであるストレージシステム１８のＣＰＵ２６０の使用率が一定値、例えば９５％、を下回っている場合は、最大の性能負荷のストレージシステム１８の対象から外す。

次に、ステップ４２２において、管理サーバ１４は、ステップ４２０で確認した最大及び最小の性能負荷２３０ｂが存在するか否かを判定する。

この結果、最大及び最小の性能負荷２３０ｂが存在しない場合（ステップ４２２：Ｎｏ）は、ステップ４２６において、管理サーバ１４は、性能負荷分散の実施が不要であると判定し、性能負荷分散判定処理を終了する。

一方、最大及び最小の性能負荷２３０ｂが存在する場合（ステップ４２２：Ｙｅｓ）は、ステップ４２４において、管理サーバ１４は、性能負荷分散の実施が必要であると判定する。次に、ステップ４２８において、管理サーバ１４は、性能負荷２３０ｂが最大のストレージシステム１８を移行元に決定し、性能負荷２３０ｂが最小のストレージシステム１８を移行先に決定し、性能負荷分散判定処理を終了する。

図３０は、第１実施例に係る性能負荷分散実施処理のフローチャートである。

性能負荷分散実施処理は、図２８のステップ４１０の処理に対応する。なお、本実施例では、性能負荷分散実施処理の実行中は、図２８のステップ４００の処理を実施しないようにしている。

最初に、ステップ４３０において、管理サーバ１４は、アプリケーションプログラム８０がストレージシステム１８の自動最適配置を実施可能なモード（自動最適配置モード）が「ＯＮ」であるか否かを判定する。

この結果、自動最適配置モードが「ＯＮ」でない場合（ステップ４３０：Ｎｏ）は、管理サーバ１４は、ストレージシステム１８の最適配置を実行しても良いか否かを管理ユーザに問い合わせる。このステップは、管理ユーザの判断で、ストレージシステム１８の最適配置を実施するか否かを決定する場合を想定している。

この結果、最適配置を実行してはいけない場合（ステップ４４０：否）は、管理サーバ１４は、性能負荷分散実施処理を終了する。

一方、自動最適配置モードが「ＯＮ」である場合（ステップ４３０：Ｙｅｓ）、又は、最適配置を実行して良い場合（ステップ４４０：可）は、ステップ４３２において、管理サーバ１４は、移行すべき性能負荷を算出する。

ここで、移行すべき性能負荷の算出方法の一例を説明する。移行先ストレージシステム１８のシステム限界性能値９０％と、最小の性能負荷２３０ｂとの差分を最小差分と定義し、移行元ストレージシステム１８のシステム限界性能値９０％と、最大の性能負荷２３０ｂとの差分を最大差分と定義する。そして、最小差分と最大差分との値を比較し、これらの内のより小さい方の値を移行すべき性能負荷の値とする。このような算出方法の他にも、計算機システムを構成する全ストレージシステム１８のシステム性能限界値の平均値を閾値とする方法も考えられる。

次に、ステップ４３４において、管理サーバ１４は、内訳性能モニタリング情報２３２の移行元ストレージシステム１８に関する管理情報２４０にアクセスし、ステップ４３２の算出結果を基に、移行対象とするＬＵに対応する内部ＬＵＮ２４０ａを決定する。

次に、ステップ４３８において、管理サーバ１４は、移行元から移行先ストレージシステム１８へ制御情報を移行する制御情報移行処理（図３１参照）を実施する。このステップの処理は、図２７に示す管理情報更新処理３９２に対応する。

最後に、ステップ４３６において、管理サーバ１４は、性能モニタリング情報管理テーブル６８を更新する性能モニタリング情報更新処理を実行し、性能負荷分散実施処理を終了する。

図３１Ａは、第１実施例に係る制御情報移行処理のフローチャートである。

制御情報移行処理は、図３０のステップ４３８の処理に対応する。

最初に、ステップ４５０において、管理サーバ１４は、移行元ストレージシステム１８におけるネットワークケーブル２２が接続されているＦＥＰＫ３２のポートをイニシエータと設定する。同様に、移行先ストレージシステム１８におけるネットワークケーブル２４が接続されているＦＥＰＫ３２のポートをターゲットと設定する。図１でも説明した通り、ネットワークケーブル２２とネットワークケーブル２４とは１本に纏まっていても構わない。

次に、ステップ４５２において、ストレージシステム１８は、移行元ストレージシステム１８のキャッシュ領域２７２に格納されている、移行対象のＬＵ（移行対象ＬＵ）に関連するデータに対する処理（移行元キャッシュデータ処理）を実行する。移行元キャッシュデータ処理は、移行元キャッシュディレクトリ・クリーン化処理（図３２参照）と、移行先キャッシュディレクトリ・ダーティ化処理（図３３参照）とを含む。

次に、ステップ４５４において、管理サーバ１４は、ＬＵＮ管理テーブル７４の共有ＬＵＮ管理テーブル１０２に関し、移行対象ＬＵの内部ＬＵＮ２４０ａに対応するオーナストレージシステム番号９４を移行元ストレージシステムのストレージシステム番号から移行先ストレージシステムのストレージシステム番号へ更新する。

次に、ステップ４５６において、管理サーバ１４は、ステップ４５４の結果を基に、移行元ストレージシステム１８及び移行先ストレージシステム１８の集約共有デバイスユニット管理テーブル２７８にアクセスし、移行対象ＬＵの内部ＬＵＮに対応するオーナビット２７９ｇをＯＮ（つまり１）に更新する。

次に、ステップ４５８において、管理サーバ１４は、移行先ストレージシステム１８からホストコンピュータ１０へ至るネットワークケーブル４４が接続されているＦＥＰＫ３２のポートと、移行対象ＬＵ（例えば、割当領域３１０）とのマッピングを設定する。このマッピングの設定は、パス交換ソフトウェア等を用いて実現しても良い。

次に、ステップ４６０において、管理サーバ１４及びストレージシステム１８の少なくとも一方が、移行対象ＬＵにアクセスしていたホストコンピュータ１０へ当該ＬＵを移行したことを通知する。

ストレージシステム１８が通知する場合、一例として、以下のような方法がある。ホストコンピュータ１０から移行したＬＵへアクセス処理が発生した場合、ホストコンピュータ１０の構成情報７０の当該オーナストレージシステム番号９４は未更新のため、移行元ＬＵを処理するストレージシステム１８にアクセスする。しかし、ストレージシステム１８の構成情報２６８の当該オーナビット２８９ｇはＯＦＦとなっているため、移行元ＬＵを処理するストレージシステム１８は、ホストコンピュータ１０に対しエラー等を通知し、ホストコンピュータ１０はＬＵが移行されたことを認識する。

最後に、ステップ４６１において、ホストコンピュータ１０は、ＬＵ移行に伴うホストコンピュータ１０の設定の変更処理を実施し、処理は完了する。ステップ４６１の詳細については、図３１Ｂで説明する。

図３１Ｂは、第１実施例に係るＬＵ移行に伴うホストコンピュータ設定変更処理のフローチャートである。ホストコンピュータ設定処理変更は、図３１Ａのステップ４６１に対応する。

まず、ステップ４６２において、管理サーバ１４は、移行元ＬＵのＦＥＰＫ３２のマッピング設定を解除するか否かを判定する。

この結果、ＦＥＰＫ３２のマッピング設定を解除する場合（ステップ４６２：Ｙｅｓ）は、ステップ４６６において、管理サーバ１４は、移行元ＬＵ３１０のＦＥＰＫ３２のマッピング設定を解除する。

次に、ステップ４６８において、管理サーバ１４は、移行元ストレージシステム１８の共有デバイスユニットに関する集約共有デバイスユニット管理テーブル２７８にアクセスし、移行元ＬＵに対応するオーナビット２７９ｇをＯＦＦ（つまり０）に更新する。

一方、ＦＥＰＫ３２のマッピング設定を解除しない場合（ステップ４６２：Ｎｏ）は、ＦＥＰＫ３２に接続されてしまう場合、ホストコンピュータ１０は、移行元ＬＵへも移行先ＬＵへもアクセス可能となるため、ステップ４６４において、管理サーバ１４は、移行先ＬＵ（図２７の割当領域３１０´）へ優先的にアクセスするように移行元ＬＵをアクセスしていたホストコンピュータ１０へ通知するか否かを判定する。優先的にアクセスするとは、ホストコンピュータ１０が当該ＬＵにアクセスする際、移行先ＬＵへアクセスするようにし、移行元ＬＵへアクセスしない処理の過程を意味する。

この結果、ホストコンピュータ１０へ通知しないと判定した場合（ステップ４６４：Ｎｏ）は、ステップ４７２において、ホストコンピュータ１０が移行元ＬＵ（例えば、割当領域３１０）へアクセスした際、内部ネットワーク２６を経由して、移行先ＬＵ（例えば、割当領域３１０´）へアクセスするよう移行元ストレージシステム１８が設定する。設定の一例として、移行元ＬＵの当該集約共有管理テーブル２７９のオーナビット２７９ｇに、移行先ストレージシステム１８のＩＤ番号等の識別子を記入することで、ホストコンピュータ１０は移行元ストレージシステム１８を経由し移行先ストレージシステム１８へアクセス可能となり、処理を完了する。よって、ホストコンピュータ１０側の管理情報を更新せずに、移行先ストレージシステムへアクセスし、移行元ストレージシステムがＬＵの更新や読み込みを実施することを防止出来る。

一方、ホストコンピュータ１０へ通知すると判定した場合（ステップ４６４：Ｙｅｓ）は、ステップ４７０において、管理サーバ１４は、ホストコンピュータ１０へ優先アクセス先を移行先ＬＵ（例えば、割当領域３１０´）とする旨通知する。ステップ４７０の後、ステップ４６８に進む。

ステップ４６８の処理後、ステップ４７４において、管理サーバ１４は、ホストコンピュータ割当管理テーブル７２の移行元ＬＵのアクセス元のホストコンピュータ１０に関するホストコンピュータ割当管理テーブル９０において、ホストＬＵＮに対応するオーナストレージシステム番号９４を、移行先ＬＵを担当するストレージシステムのストレージシステム番号に更新して、制御情報移行処理を終了する。

図３２は、第１実施例に係る移行元キャッシュディレクトリ・クリーン化処理のフローチャートである。

移行元キャッシュディレクトリ・クリーン化処理は、図３１Ａのステップ４５２の移行元キャッシュデータ処理の一部に対応する。

最初に、ステップ４８０において、ストレージシステム１８は、移行元ＬＵに関連する、移行元ストレージシステム１８のキャッシュ領域２７２に格納しているデータを記憶媒体５０へデステージする。なお、ステップ４８０の処理以降、このデータの移行が完了するまで、移行元ＬＵへのアクセス時に、移行元ストレージシステム１８のキャッシュ領域２７２を使用しない。

次に、ステップ４８２において、管理サーバ１４は、移行元ＬＵに関連する、移行元ストレージシステム１８のキャッシュ領域２７２のディレクトリをクリーン化し、キャッシュ管理テーブル２７４のダーティフラグ２８８をダーティデータでないことを示すように更新するとともに、デステージ許可フラグ２９０を、デステージを許可しないことを示すように更新し、移行元キャッシュディレクトリ・クリーン化処理を終了する。

図３３は、第１実施例に係る移行先キャッシュディレクトリ・ダーティ化処理のフローチャートである。

移行先キャッシュディレクトリ・ダーティ化処理は、図３１Ａのステップ４５２の移行元キャッシュデータ処理の一部に対応する。

最初に、ステップ４９０において、管理サーバ１４は、移行元ＬＵに関連する、移行元ストレージシステム１８のキャッシュ領域２７２に格納されているデータを、ネットワーク２６を介して移行先ストレージシステム１８のキャッシュ領域２７２へコピーする。この際のネットワークケーブルは、図３１Ａのステップ４５０における設定によって、イニシエータ及びターゲットに設定されている。なお、ステップ４９０の処理以降、コピー対象のデータの移行が完了するまで、当該移行元ＬＵへのアクセス時に、移行元ストレージシステム１８のキャッシュ領域２７２を使用しない。

次に、ステップ４９２において、管理サーバ１４は、コピーが完了した移行先ストレージシステム１８のキャッシュ領域２７２のディレクトリをダーティ化するために、キャッシュ管理テーブル２７４のダーティフラグ２８８をダーティデータであることを示すように更新するとともに、デステージ許可フラグ２９０を、デステージを許可することを示すように更新し、移行先キャッシュディレクトリ・ダーティ化処理を終了する。

図３４は、第１実施例に係るデバイス割当領域削除処理のフローチャートである。

デバイス割当領域削除処理は、ホストＬＵＮの情報を削除し、ホストコンピュータ１０がホストＬＵＮを認識不可の状態にする処理である。ホストＬＵＮに対応するＬＵ３０２を完全に削除する場合は、デバイス割当領域削除処理の後に、通常通りホストＬＵＮに対応する内部ＬＵＮを削除すればよい。

最初に、ステップ５００において、管理サーバ１４は、ホストコンピュータ割当管理テーブル７２において、割当領域削除対象のホストＬＵＮ９２と、そのホストＬＵＮ９２に対応するオーナストレージシステム番号９４を確認する。

次に、ステップ５０２において、管理サーバ１４は、割当領域削除対象のＬＵＮが複数のストレージシステム１８からアクセス可能となっているか否かを確認する。具体的には、管理サーバ１４は、共有ＬＵＮ管理テーブル１０２Ａにおいて，ホストＬＵＮ１０２ａとホストＬＵＮ９２が一致し、かつオーナストレージシステム＃１０２ｇとオーナストレージ番号９４が一致する場合、このホストＬＵＮに対応するオーナストレージシステム番号９４が複数のストレージシステム番号となっていないかを確認する。

この結果、割当領域削除対象のホストＬＵＮが複数のストレージシステムからアクセス可能となっていない場合（ステップ５０２：Ｎｏ）は、ステップ５０４において、管理サーバ１４は、全ストレージシステム１８に対し、当該ホストＬＵＮ９２とＦＥＰＫ３２とのマッピングを削除する。

一方、割当領域削除対象のホストＬＵＮが複数のストレージシステムからアクセス可能となっている場合（ステップ５０２：Ｙｅｓ）は、ステップ５０６において、管理サーバ１４は、ステップ５００で確認したオーナストレージシステム番号９４に対応するストレージシステム１８における、割当領域削除対象のホストＬＵＮ９２と、ＦＥＰＫ３２とのマッピングを削除する。

ステップ５０４又はステップ５０６の処理後、ステップ５０８において、管理サーバ１４は、ＬＵＮ管理テーブル７４の割当領域削除対象のホストＬＵＮの管理情報を削除する。具体的には、管理サーバ１４は、専有デバイスユニット管理テーブル１１０及び共有ＬＵＮ管理テーブル１０２における割当領域削除対象のホストＬＵＮに関するエントリを削除する。

次に、ステップ５１０において、管理サーバ１４は、各ストレージシステム１８のストレージシステム割当管理テーブル２７７又は集約共有デバイスユニット管理テーブル２７８において、割当領域削除対象のホストＬＵＮの管理情報を削除する。

次に、ステップ５１２において、管理サーバ１４は、削除対象の割当領域が共有デバイスユニット３４にあるか否かを判定する。

この結果、削除対象の割当領域が共有デバイスユニット３４にある場合（ステップ５１２：Ｙｅｓ）は、管理サーバ１４は、共有デバイスユニット管理テーブル７８のこの共有デバイスユニット３４に関する構成管理情報２０２において、割当領域削除対象の内部ＬＵＮに対応するストレージシステム番号２０２ｂをｎｕｌｌに変更する。さらに、管理サーバ１４は、空き領域管理キュー２０４において、割当領域削除対象の内部ＬＵＮを示すエントリを追加する。この段階において、ＦＡＱ２２０に対してエントリがない場合には、共有判定情報１８０の共有デバイスユニット使用可能管理キュー１９６にこの共有デバイスユニット３４の番号を示すエントリを追加する。

一方、削除対象の割当領域が共有デバイスユニット３４にない場合（ステップ５１２：Ｎｏ）、又は、ステップ５１４の処理後、ステップ５１６において、管理サーバ１４は、ホストコンピュータ割当管理テーブル７２中の割当領域削除対象のホストＬＵＮにアクセスするホストコンピュータ１０のホストコンピュータ割当管理テーブル９０において、割当領域削除対象のホストＬＵＮに関する情報を削除して、デバイス割当領域削除処理を終了する。

次に、第２実施例について説明する。

まず、第２実施例に係る計算機システムの概要について、第１実施例に係る計算機システムとの差異を説明する。第１実施例に係る計算機システムでは、新規領域割当等の各種処理を管理サーバ１４が制御していたが、第２実施例に係る計算機システムでは、複数のストレージシステム１８が連携することにより各種処理を実施する。以下に、第２実施例に係る計算機システムの詳細を説明する。

図３５は、第２実施例に係るストレージコントローラの構成図である。なお、図１７に示す第１実施例に係るストレージコントローラと同様な部分には、同一符号を付している。

第２実施例に係るストレージコントローラは、第１実施例に係るストレージコントローラとは、以下の２点が異なっている。

１点目は、複数のストレージコントローラ２８の中のいずれかのストレージコントローラが代表として定義されている点である。図３５に示す例では、ストレージコントローラ＃０が代表として定義されている。なお、代表のストレージコントローラ２８を、代表ストレージコントローラ５２０という。

複数のストレージシステム１８間で連携するためには、共有デバイスユニット３４をストレージシステム１８へ新規登録する作業命令等を、ストレージシステム１８が発行しなければならない。このような新規登録する作業命令等を発行するストレージシステム１８のストレージコントローラ２８が、代表ストレージコントローラ５２０である。

２点目は、ストレージコントローラ２８の構成情報２６８として、ＬＵＮ管理テーブル７４が格納されている点である。構成情報２６８としてＬＵＮ管理テーブル７４を格納するストレージコントローラ２８のパターンとしては、代表ストレージコントローラ５２０のみがＬＵＮ管理テーブル７４を格納するパターンと、全ストレージコントローラ２８がＬＵＮ管理テーブル７４を格納するパターンとが考えられる。前者のパターンでは、新規領域割当処理等の処理を代表ストレージコントローラ５２０が実施する。後者のパターンでは、新規領域割当処理等の処理を、管理サーバ１４上の制御情報を確認しつつ、各ストレージコントローラ２８が実施し、ＬＵＮ管理テーブル７４の更新情報を全ストレージシステム１８へ通知することとなる。この処理は、図２３のステップ３６２と同様である。

次に、第２実施例に係る計算機システムの処理の動作について説明する。ここでは、第１実施例に係る計算機システムの処理と異なる点を中心に説明する。

図３６は、第２実施例に係る共有デバイスユニット新規登録処理のフローチャートである。なお、図２１に示す共有デバイスユニット新規登録処理と同様なステップについては、同一符号を付すこととする。

最初に、ステップ３２０において、代表ストレージコントローラ５２０は、新規登録するデバイスユニットの指定を計算機システムの管理ユーザから受け付け、共有判定管理テーブル１９４に、指定されたデバイスユニットのデバイスユニット番号１９４ａの行を追加し、当該行の共有ビット１９４ｂを「１」に設定する（ステップ３２０）。なお、共有判定管理テーブル１９４に、指定されたデバイスユニットのデバイスユニット番号１９４ａの行が存在する場合は、行の追加作業を行う必要はなく、対応する行の共有ビット１９４ｂを「１」に設定する。

次に、ステップ５３０において、代表ストレージコントローラ５２０は、デバイスユニット（３４、３６）の複数の記憶媒体５０から、パリティグループ３００を作成し、更に、パリティグループ３００にＬＵ３０２を作成する。その際、代表ストレージコントローラ５２０は、内部ＬＵＮとホストＬＵＮとの設定も実施する。作成するパリティグループ３００やＬＵ３０２の構成に関しては、予めデフォルト値を代表ストレージコントローラ５２０に設定していても良いし、ステップ３２２において、管理サーバ１４が代表ストレージコントローラ５２０へ構成を指示しても良い。

次に、ステップ５３１において、ＬＵ３０２の作成後、代表ストレージコントローラ５２０は、ＬＵＮ管理テーブル７４の共有ＬＵＮ管理テーブル１０２を作成し、新規作成したＬＵ３０２の管理情報を登録する。

次に、ステップ３２６において、代表ストレージコントローラ５２０は、新規登録したＬＵ３０２について、ストレージシステムへの新規割当を実施するか判定する。

この結果、新規登録したＬＵ３０２について、ストレージシステムへの新規割当を実施する場合（ステップ３２６：Ｙｅｓ）は、ステップ３２８において、代表ストレージコントローラ５２０は、新規作成したＬＵ３０２にストレージシステム番号を振り、当該ストレージシステム番号を、ＬＵＮ管理テーブル７４の共有ＬＵＮ管理テーブル１０２のオーナストレージシステム番号１０２ｇとして登録する。ここで、ストレージシステム番号の振り方は、当該共有デバイスユニット３４に接続されている全ストレージシステムに対し、ラウンド・ロビン方式等で均等に割り振っても良いし、１つのストレージシステムに固定して割り振っても良い。ただし、性能面を考慮すると、ラウンド・ロビン方式の方が実用的である。

一方、新規登録したＬＵ３０２について、ストレージシステムへの新規割当てを実施しない場合（ステップ３２６：Ｎｏ）、又はステップ３２８の終了後、ステップ３３０において、代表ストレージコントローラ５２０は、更新したＬＵＮ管理テーブル７４の共有ＬＵＮ管理テーブル１０２の情報を、当該共有デバイスユニット３４に接続されている全ストレージシステム１８のストレージコントローラ２８の統合共有デバイスユニット管理テーブル２７８へ反映する。その際、代表ストレージコントローラ５２０からの指示を受けたストレージコントローラ２８は、集約共有管理テーブル２７９のそのストレージシステム１８が処理を担当するＬＵのホストＬＵＮ２７９ａに対応する行のオーナビット２７９ｇを「１」に設定する。

次に、ステップ３３２において、代表ストレージコントローラ５２０は、ストレージシステムが未割当の新規作成したＬＵ３０２があるか否かを確認する。

この結果、ストレージシステムが未割当の新規作成したＬＵ３０２がある場合（ステップ３３２：Ｙｅｓ）は、ステップ３３４において、代表ストレージコントローラ５２０は、未割当の新規作成したＬＵ３０２に対応するエントリを、共有デバイスユニット管理テーブル７８の当該共有デバイスユニット管理テーブル２００の空き領域管理キュー２０４に追加する。

次に、ステップ３３６において、代表ストレージコントローラ５２０は、当該共有デバイスユニット３４のデバイスユニット番号に対応するエントリを共有デバイスユニット使用可能管理キュー１９６に追加し、共有デバイスユニット新規登録処理を終了する。なお、ストレージシステムが未割当の新規作成したＬＵ３０２がない場合（ステップ３３２：Ｎｏ）は、共有デバイスユニット新規登録処理を終了する。

以上説明したように、第２実施例に係る計算機システムにおいては、複数のストレージコントローラ２８が連携して、共有デバイスユニットをストレージシステムへ新規登録することができる。

次に、第３実施例について説明する。

まず、第３実施例に係る計算機システムの概要について、第１実施例に係る計算機システムとの差異を説明する。第１実施例に係る計算機システムでは、共有デバイスユニット３４内の記憶媒体５０の種別を特に限定していなかったが、第３実施例に係る計算機システムでは、記憶媒体５０をフラッシュドライブ５５０としている。なお、記憶媒体５０をフラッシュドライブ５５０としても、第１実施例及び第２実施例と同様の構成及び制御を行うことは可能であるが、第３実施例では、フラッシュドライブ５５０のフラッシュストレージ５５２を利用することで可能となる第１実施例及び第２実施例と異なる構成制御方法を行う。以下、第３実施例に係る計算機システムの詳細を説明する。

図３７は、第３実施例に係るデバイスユニットの構成図である。なお、図２に示す第１実施例に係るデバイスユニットと同様な構成には、同一の符号を付すこととする。

共有デバイスユニット３４は、スイッチ３８と、複数のフラッシュドライブ５５０を含むデバイス４０とを有する。フラッシュドライブ５５０と、スイッチ３８とは、ケーブルによって接続されている。フラッシュドライブ５５０は、フラッシュストレージ５５２を含む。

図３８Ａは、第３実施例に係るフラッシュストレージの構成図である。

フラッシュストレージ５５２は、ＦＥＩＦ（Front End IF）５７０、ＣＰＵ５７８、メモリ５６０、ＢＥＩＦ(Back End IF)５７４、１以上のフラッシュメモリ（ＦＭ）チップ５７６、及びデータ転送制御部５７２を含む。ＦＥＩＦ（Front End IF）５７０、ＣＰＵ５７８、メモリ５６０、及びＢＥＩＦ(Back End IF)５７４は、データ転送制御部５７２を介して接続されている。

ＦＥＩＦ５７０は、ケーブルを介してスイッチ３８に接続される。ＣＰＵ５７８は、複数のマイクロプログラム（ＭＰ）５８０を格納し、Ｉ／Ｏ処理等を並列に実施することができる。

メモリ５６０は、構成情報５６２、性能モニタリング情報管理テーブル６８、Ｉ／Ｏ優先・非優先キュー５６４、フラッシュストレージ制御プログラム５６６、キャッシング領域５６８、及び性能モニタリング情報バッファ領域５８２を格納する。Ｉ／Ｏ優先・非優先キュー５６４については、図３９で詳細を説明する。構成情報５６２は、ＬＵＮ管理テーブル７４、共有デバイスユニット管理テーブル７８、及び論理物理変換情報５８４を格納する。論理物理変換情報５８４は、フラッシュストレージ５５２内でユニークな論理アドレスと、ＦＭチップ５７６の物理層の対応関係を管理する。論理物理変換情報５８４の詳細については、後述する。フラッシュストレージ制御プログラム５６６は、フラッシュストレージを制御する各種処理を実行するためのプログラムである。キャッシング領域５６８は、データのキャッシングに利用するための領域である。性能モニタリング情報バッファ領域５８２は、性能モニタリング情報を一時的に格納するためのバッファ領域である。ＢＥＩＦ５７４は、ＦＭチップ５７６を接続するためのインタフェースであり、複数のＦＭチップ５７６が接続されている。ＦＭチップ５７６は、ユーザデータ等を格納する。

図３８Ｂは、第３実施例に係る論理物理変換情報の構成図である。

フラッシュドライブ５００では、データはブロック単位で制御され、また、データはブロックをより小さい単位に分割したページ単位で管理されている。論理物理変換情報５８４は、ブロックの論理アドレス（ブロック論理アドレス）の情報を管理するテーブルである。論理物理変換情報５８４は、ブロック内ページ毎に、ブロック番号（＃）２０６８、ＦＭチップ番号（＃）２０７０、ＦＭチップブロック番号（＃）２０７１、ページ番号（＃）２０７２，及びオフセットアドレス２０７４を格納する。

ブロック論理アドレス２０６８は、ストレージシステム内でデータにブロック単位でアクセスする際の論理アドレスである。ＦＭチップ番号２０７０は、ブロック論理アドレス２０６８が格納されているＦＭチップ５７６の番号である。ＦＭチップブロック番号２０７２は、ＦＭチップ５７６内を一定のブロックサイズで区切った場合の１つブロックに付随している番号であり、ブロック論理アドレス２０６８に該当する番号が格納してある。ページ番号１０７２は、ＦＭチップ５７６のブロックをさらに小さい単位で分割したものである。オフセットアドレス２０７４は、各ページに割り当てられている物理アドレスのオフセットアドレスである。ストレージシステムへ未割当のページに対応するオフセットアドレス２０７４には、「null」が設定される。

図３９は、第３実施例に係るＩ／Ｏ優先・非優先キューの構成図である。

Ｉ／Ｏ優先・非優先キュー５６４は、Ｉ／Ｏ処理の優先度を管理するためのキューである。例えば、ホストコンピュータ１０からのＲｅａｄ要求等のＩ／Ｏ処理は、ホストレスポンスを良くするため、早めに処理をしたい（＝処理の優先度が高い）。一方、バックグラウンドでデータコピーを実施するアプリケーション処理等に関わるＩ／Ｏ処理は、多少処理が遅れても構わない（＝処理の優先度が低い）。さらに、ホストコンピュータ１０からＷｒｉｔｅ要求を受けた場合、ホストレスポンスを良くするため、ストレージシステムのメモリにＷｒｉｔｅデータを格納しホストコンピュータ１０へＷｒｉｔｅ処理完了通知を出した後、非同期にＷｒｉｔｅデータをデバイスに書き込む。Ｗｒｉｔｅデータをデバイスに書き込む処理負荷は高いが、さらに、非同期のＷｒｉｔｅデータ書き込み処理の効率を良くするため、ある程度Ｗｒｉｔｅデータを溜めた上でデバイスに書き込む場合（まとめ書きと呼ぶ）もあり、この場合１回の処理負荷は高い。通常は、Ｉ／Ｏ優先・非優先キュー５６４は各ストレージコントローラ２８で管理しているが、本実施例のように１つの共有デバイスユニット３４に複数のストレージシステム１８が接続されている場合、あるストレージシステム１８がまとめ書きの指示を出したが、別のストレージシステム１８がホストコンピュータ１０からのＲｅａｄ処理等優先度の高い処理の指示を出した場合、デバイスユニットでは処理の優先度を判断することが出来ず、まとめ書きの処理を先に実行し、Ｒｅａｄ処理のホストレスポンスが悪化する恐れがある。そこで、本実施例では、フラッシュストレージ５５２に基づいたＩ／Ｏ優先・非優先キュー５６４により、Ｉ／Ｏ処理の順番を優先度毎に管理することで、効率的にＩ／Ｏ処理を実施するようにしている。Ｉ／Ｏ優先・非優先キュー５６４の管理単位は、フラッシュストレージ５５２毎でも良いし、ＦＭチップ毎でも良いし、ＣＰＵ毎でも良いし、ＭＰ毎でも良い。図３９では、一例としてフラッシュストレージ５５２内のＭＰ毎に、Ｉ／Ｏ優先・非優先キュー５６４を管理する場合を説明する。

Ｉ／Ｏ優先・非優先キュー５６４は、ＣＰＵ５７８のＭＰ５８０毎にそれぞれ個別Ｉ／Ｏ優先・非優先キュー５９０（５９０Ａ、５９０Ｂ等）が割り当てられる。例えば、ＭＰ＃０（ＭＰ５８０Ａ）には、個別Ｉ／Ｏ優先・非優先キュー５９０Ａが割り当てられ、ＭＰ＃１（ＭＰ５８０Ｂ）には、個別Ｉ／Ｏ優先・非優先キュー５９０Ｂが割り当てられる。

個別Ｉ／Ｏ優先・非優先キュー５９０は、優先キュー（ＰＲＱ）５９２と、非優先キュー（ＮＰＲＱ）５９６とを格納する。優先キュー５９２には、優先度が高いＩ／Ｏ処理を示すエントリが管理され、非優先キュー５９６には、優先度が低いＩ／Ｏ処理を示すエントリが管理される。図３９に示す例では、優先キュー５９２には、優先度が高いＩ／Ｏ番号０を示すエントリ５９４Ａと、Ｉ／Ｏ番号４を示すエントリ５９４Ｂとが接続されている。また、非優先キュー５９６には、優先度が低いＩ／Ｏ番号１のエントリ５９８Ａと、Ｉ／Ｏ番号２のエントリ５９８Ｂと、Ｉ／Ｏ番号３のエントリ５９８Ｃとが接続されている。各Ｉ／Ｏ処理の優先度は、例えば、各ストレージシステム１８のストレージ制御プログラム２７６が付与する。Ｉ／Ｏ優先・非優先キュー５６４を用いた具体的な処理については、図４３を用いて後述する。

図４０は、第３実施例に係るストレージコントローラの構成図である。なお、図１７に示す第１実施例に係るストレージコントローラと同様な部分には、同一符号を付している。

第３実施例に係るストレージコントローラ２８は、構成情報２６８として、ストレージシステム割当管理テーブル１００’（１００Ａ‘）のみを格納する。

図４１は、第３実施例に係るストレージシステム割当管理情報の構成図である。

ストレージシステム割当管理情報１００’は、図７に示す第１実施例に係るストレージシステム割当管理情報１００とほぼ同じ構成であるが、専有デバイスユニット管理テーブル１１０のみ格納されているのではなく、共有デバイスユニット３４のうち、当該ストレージシステム１８に割り当てられているホストＬＵＮ９２の管理情報も含む。また、ストレージシステム割当管理情報１００’は、ストレージシステム割当管理情報１００の先頭物理アドレス１１０ｆに代えて、先頭フラッシュドライブ論理アドレス１１０ｈを格納する。

ホストＬＵＮ１１０ａは、専有デバイスユニット３６から割当てられているＬＵに対応するホストＬＵＮだけでなく、共有デバイスユニット３４から割当てられているＬＵに対応するホストＬＵＮである場合がある。例えば、図４１に示すストレージシステム割当管理情報１００’を参照すると、ホストＬＵＮ１１０ａ「２」に対応するＬＵは、デバイスユニット番号１１０ｇ「０」のデバイスユニット、すなわち、共有デバイスユニット３４から割当てられていることがわかる。ここで、共有デバイスユニット３４がフラッシュドライブ５５０で構成されている場合は、フラッシュドライブ５５０にフラッシュストレージ５５２が搭載されているため、ストレージシステム１８へ割り当てられている領域のみを見せることが可能となる。よって、第１実施例の図１８に示すような共有デバイスユニット管理テーブル２７８により、全ストレージシステム１８に割り当てられた全領域の管理情報をストレージシステム１８毎に格納しなくてよい。

先頭フラッシュドライブ論理アドレス１１０ｈは、内部ＬＵＮ１１０ｂに対応するＬＵのフラッシュドライブ５５０における先頭の論理アドレスである。先頭フラッシュドライブ論理アドレス１１０ｈを、ブロック内ページサイズで割ることにより、ＬＵについてのブロック内ページ番号を算出することができる。

次に、第３実施例に係る計算機システムの処理について説明する。なお、第１実施例に係る計算機システムの処理との差異を中心に説明する。

図４２は、第３実施例に係る共有デバイスユニット新規登録処理のフローチャートである。なお、図２１に示す第１実施例に係る共有デバイスユニット新規登録処理と同様な部分には、同一符号を付し、詳細な説明は省略する。

最初に、ステップ３２０において、管理サーバ１４が、共有判定管理テーブル１８０へ新規登録の共有デバイスユニット３４を登録する。

次に、ステップ１０００において、フラッシュストレージ５５２（例えば、共有デバイスユニット３４内の複数のフラッシュストレージ５５２のうち或るストレージコントローラから所定の指示を受けた１以上のフラッシュストレージ５５２の各々）が、当該共有デバイスユニット３４内の複数のフラッシュドライブ５５０から、パリティグループ３００を作成し、さらにパリティグループ３００に基づいてＬＵ３０２を作成する。その際、フラッシュストレージ５５２は、内部ＬＵＮとホストＬＵＮとの設定も実施する。作成するパリティグループ３００やＬＵ３０２の構成に関しては、予めデフォルト値を管理サーバ１４に設定していても良いし、ステップ３２２において、管理サーバ１４がフラッシュストレージ５５２へ構成を指示しても良い。ＬＵ３０２の作成後、フラッシュストレージ５５２は、ＬＵＮ管理テーブル７４の共有ＬＵＮ管理テーブル１０２を作成し、新規作成したＬＵ３０２の管理情報を登録する。

その後、第１実施例の図２１と同様にステップ３２６へ処理を進め、ステップ３２６でＹｅｓの場合は、ステップ３２８の処理を実行する。次に、ステップ１００２において、フラッシュストレージ５５２が、各ストレージシステム１８のストレージシステム割当管理テーブル１００’へ、当該ストレージシステム１８に割り当てられた新規ＬＵ３０２の登録情報のみを反映する。

一方、ステップ３２６でＮｏの場合、又はステップ１００２の処理後、フラッシュストレージ５５２は、ステップ３３２へ処理を進め、後続の処理を実行し、共有デバイスユニット新規登録処理を終了する。

図４３は、第３実施例に係るＩ／Ｏ処理要求処理のフローチャートである。なお、図２５に示す第１実施例に係るＩ／Ｏ処理要求処理と同様な部分には、同一符号を付し、詳細な説明は省略する。

最初に、ステップ３７０において、ホストコンピュータ１０は、Ｉ／Ｏ処理要求元のホストコンピュータ１０に格納されているホストコンピュータ割当管理テーブル２５７にアクセスし、Ｉ／Ｏ処理要求の対象となるＬＵに対応するホストＬＵＮと、当該ＬＵを処理するストレージシステム１８に対応するオーナストレージシステム番号とを確認する。

次に、ステップ３７２において、ストレージシステム１８は、ステップ３７０で確認したストレージシステム番号に対応するストレージシステム１８のストレージコントローラ２８にアクセスし、構成情報２６８を参照し、対象ＬＵのホストＬＵＮに対応する内部ＬＵＮ（１１０ｂ）を確認する。

次に、ステップ３７３において、ストレージシステム１８は構成情報２６８の対象ＬＵＮに対応するオーナビット２７９ｇがＯＮ、つまり当該ストレージシステム１８が処理可能なＬＵなのか判定する。

結果、ストレージシステム１８が処理不可能なＬＵの場合（ステップ３７３：Ｎｏ）、当該ＬＵを処理担当するストレージシステム１８が変更となっているため、ステップ４６１において、それに伴うホストコンピュータ１０の設定変更の処理を実施する。

最後に、ストレージシステム１８が処理可能なＬＵの場合（ステップ３７３：Ｙｅｓ）や、ステップ４６１終了した場合は、ステップ１０２０において、ストレージコントローラ２８は、データＩ／Ｏ処理（図４４参照）を実施し、Ｉ／Ｏ処理要求処理を終了する。

図４４は、第３実施例に係るデータＩ／Ｏ処理のフローチャートである。

データＩ／Ｏ処理は、図４３のステップ１０２０の処理に対応する。

最初に、ステップ１０３０において、ストレージシステム１８のストレージコントローラ２８が、Ｉ／Ｏ種別に応じて、Ｉ／Ｏ処理の優先・非優先を判断し、Ｉ／Ｏ処理命令に優先又は非優先のタグ付けをする。このＩ／Ｏ処理命令は、Ｉ／Ｏ対象のフラッシュドライブ５５０に送信される。

次に、ステップ１０３２において、ストレージシステム１８からフラッシュドライブ５５０へＩ／Ｏ処理命令が到達した時、フラッシュドライブ５５０のフラッシュストレージ５５２が、当該Ｉ／Ｏ処理命令に優先タグが付いているか否かを判定する。

この結果、Ｉ／Ｏ処理命令に優先タグが付いている場合（ステップ１０３２：Ｙｅｓ）は、ステップ１０３４において、フラッシュストレージ５５２は、処理を実行するＭＰ５８０に対応する優先キュー５９２へ、当該Ｉ／Ｏ処理命令の番号を示すエントリを追加する。

一方、Ｉ／Ｏ処理命令に優先タグが付いていない場合（ステップ１０３２：Ｎｏ）は、ステップ１０３６において、フラッシュストレージ５５２は、処理を実行するＭＰ５８０に対応する非優先キュー５９６へ、当該Ｉ／Ｏ処理命令の番号を示すエントリを追加する。

ステップ１０３４、又はステップ１０３６の終了後、ステップ１０３８において、フラッシュストレージ５５２は、フラッシュストレージ５５２内の性能モニタリング情報バッファ領域５８２へ、Ｉ／Ｏ処理命令の処理対象となるＬＵの性能負荷に関する情報を格納する。

最後にステップ１０４０において、フラッシュストレージ５５２は、ＦＭチップ５７６へのリード又はライト等のＩ／Ｏ処理を実行し、データＩ／Ｏ処理を終了する。

図４５は、第３実施例に係る性能負荷分散処理のフローチャートである。なお、図２８に示す第１実施例に係る性能負荷分散処理と同様な部分には、同一符号を付し、詳細な説明は省略する。

最初に、ステップ１０５０において、各ストレージシステム１８は、一定時間毎に、性能負荷の全情報を管理している性能モニタリング管理テーブル６８へ、各フラッシュストレージ５５２の性能モニタリング情報バッファ領域５８２に格納されている性能負荷の情報を送信する。

ステップ４０２以降の処理は、図２８に示す第１実施例に係る性能負荷分散処理と同じである。

次に、第４実施例について説明する。

まず、第４実施例に係る計算機システムの概要を説明する。第４実施例では、計算機システムが、シン・プロビジョニング機能及びストレージ階層仮想化機能を利用することを想定する。

プール１０６２は、例えば、共有デバイスユニット３４や専有デバイスユニット３６の記憶領域を混在して構成される。プール１０６２は、Ｔｉｅｒ１０６０（１０６０Ａ、１０６０Ｂ、１０６０Ｃ）と呼ばれる複数の階層で管理される。ここで、Ｔｉｅｒとは、ＬＵに割り当てる領域を、その領域を提供する記憶媒体５０の特性に基づいて分けた階層である。本実施例では、Ｔｉｅｒ１（Ｔｉｅｒ１０６０Ａ）は、高速な記憶媒体で構成された領域の階層を示し、Ｔｉｅｒ３（１０６０Ｃ）は、低速な記憶媒体で構成された領域の階層を示す。ストレージ階層仮想化機能では、プール１０６２がページ３０４というデータ単位で分割されて管理され、ホストコンピュータ１０に対しては、仮想ＬＵ３０２’として領域を見せることで、データが実際に格納されている領域のみにプール１０６２のページ３０４を割当てることにより、使用されている領域の容量削減を実現する。ストレージ階層仮想化機能では、ページのアクセス頻度に応じて、Ｔｉｅｒ間でページ移動（具体的には、ページに格納されているデータの移動）を実施することで、最適なページ配置とし、Ｉ／Ｏ処理の性能向上へつながる。ページに対するアクセス頻度は、例えば、管理サーバ１４で一括管理する。

デバイスユニット３４、３６の領域の割当単位は、ページ３０４又はページ３０４の集合であるチャンク３０６となるが、本実施例では、性能負荷分散処理のストレージシステム間での移動単位はＬＵ３０２とする。性能モニタリング情報等は、例えば、共有デバイスユニット３４にフラッシュドライブ５５０を備えている場合には、フラッシュドライブ５５０のフラッシュストレージ５５２に保管しても良い。また、共有デバイスユニット３４に、フラッシュドライブ５５０以外のＳＳＤ、ＳＡＳディスク、又はＳＡＴＡディスクを備えている場合は、性能モニタリング情報は管理サーバ１４で保管しても良い。

以下、第４実施例に係る計算機システムの詳細を説明する。

図４６は、第４実施例に係るデバイス割当の概要を示す図である。

プール１０６２は、各デバイスユニット３４、３６のパリティグループ３００から構成され、複数のＴｉｅｒ１０６０で管理されている。図４６においては、共有デバイスユニット３４のパリティグループ３００がＴｉｅｒ１に該当している例を示しているが、これに限られず、パリティグループ３００がどのＴｉｅｒなのかは、パリティグループ３００を構成するデバイスユニットのデバイスの種別によって決定される。また、図４６においては、Ｔｉｅｒを３階層としているが、Ｔｉｅｒの階層数はこれに限られず、任意の階層数としても良い。

図４７は、第４実施例に係る管理サーバの構成図である。なお、図４に示す第１実施例に係る管理サーバと同様な部分には、同一符号を付すこととする。

第４実施例に係る管理サーバ１４は、第１実施例に係る管理サーバ１４に対して、仮想論理変換テーブル１０７６、及びパリティグループモニタテーブル１０８０を構成情報７０にさらに格納するとともに、ページ毎のＩ／Ｏ回数をモニタリングした情報を管理する細粒度モニタテーブル１０６１と、ページの再配置を実施するための再配置プログラム１０６３とを更に格納する。

図４８は、第４実施例に係るＬＵＮ管理テーブルの構成図である。なお、図６に示す第１実施例に係るＬＵＮ管理テーブルと同様な部分には、同一符号を付すこととする。

第４実施例に係るＬＵＮ管理テーブル７４’は、ホストＬＵＮ１０２ａ、内部ＬＵＮ１０２ｂ、サイズ１０２ｃ、及びオーナストレージシステム番号１０２ｇを管理し、第１実施例に係るＬＵＮ管理テーブル７４の共有ＬＵＮ管理テーブル１０２で管理していたパリティグループ番号１０２ｄ、ＲＡＩＤレベル１０２ｅ、及び先頭物理アドレス１０２ｆについては、別で管理するため、管理していない。第４実施例に係るＬＵＮ管理テーブル７４’は、共有デバイスユニット３４と、専有デバイスユニット３６とのいずれのＬＵに対応するＬＵＮであっても区別なく管理する。

図４９は、第４実施例に係る仮想論理変換テーブルの構成図である。

仮想論理変換テーブル１０７６は、ページ番号（＃）１０７６ａ、内部ＬＵＮ１０７６ｂ、仮想アドレス１０７６ｃ、プール番号（＃）１０７６ｄ、パリティグループ番号（＃）１０７６ｅ、及び物理アドレス１０７６ｆを管理する。ページ番号１０７６ａは、ページを識別する番号である。内部ＬＵＮ１０７６ｂは、ページ番号１０７６ａに対応するページが属する内部ＬＵＮの識別番号である。仮想アドレス１０７６ｃは、ホストコンピュータから認識されるページに対応する仮想アドレスである。プール番号１０７６ｄは、ページが提供されるプールの識別番号である。パリティグループ番号１０７６ｅは、ページが属するパリティグループの番号である。物理アドレス１０７６ｆは、ページのデータが格納されるデバイスにおける物理的なデータ格納場所を示す物理アドレスである。なお、データが格納されるデバイスがフラッシュドライブ５５０である場合には、物理アドレス１０７６ｆには、フラッシュドライブ５５０における論理アドレスが格納される。

図５０は、第４実施例に係る細粒度モニタテーブルの構成図である。

細粒度モニタテーブル１０６１は、ページ再配置を判定するために使用されるモニタ情報を管理するテーブルである。細粒度モニタテーブル１０６１は、ページ番号（＃）１０６１ａ、内部ＬＵＮ１０６１ｂ、仮想アドレス１０６１ｃ、及びＩ／Ｏ回数１０６１ｄを管理する。ページ番号１０６１ａは、ページを識別する番号である。内部ＬＵＮ１０６１ｂは、ページ番号１０６１ａに対応するページが属する内部ＬＵＮの識別番号である。仮想アドレス１０６１ｃは、ホストコンピュータから認識されるページに対応する仮想アドレスである。Ｉ／Ｏ回数１０６１ｄは、ページに対して発行されたＩ／Ｏ処理要求の回数である。

図５１は、第４実施例に係るストレージコントローラの構成図である。なお、図１７に示す第１実施例に係るストレージコントローラと同様な部分には、同一符号を付すこととする。

第４実施例に係るストレージコントローラ２８は、第１実施例に係るストレージコントローラ２８に対して、仮想論理変換テーブル１０７６、ＬＵＮ管理テーブル１０８６、及びパリティグループモニタテーブル１０８０が構成情報２６８に追加されている。また、第４実施例に係るストレージコントローラ２８は、第１実施例に係るストレージコントローラ２８におけるストレージ制御プログラム２７４に代えて、ストレージ制御プログラム１０８２を格納するとともに、マッピング変更情報バッファ領域１０８４を更に格納する。

ストレージコントローラ２８は、仮想論理変換テーブル１０７６の内容が変更された時の変更情報を、他のストレージシステム１８の仮想論理変換テーブル１０７６にもアップデートする処理を行う。ここで、内容が変更された度に、アップデータの処理を行うこととなると負荷が高くなってしまう、基本的には、ストレージコントローラ２８自身が使用する管理情報に誤りがなければ良いので、ストレージコントローラ２８は、マッピング変更情報バッファ領域１０８４に、変更内容をバッファリングしておき、一定時間毎に管理サーバ１４及び各ストレージシステム１８へ変更内容を通知する。なお、新規ページ割当時は、別途用意した空きページ割当てるように管理しているため、既に別のストレージシステム１８で確保済みの領域を誤って確保する恐れはなく、このように変更内容を通知するようにしても問題がない。空きページの管理については、図５５を用いて後述する。

図５２は、第４実施例に係るＬＵＮ管理テーブルの構成図である。

ＬＵＮ管理テーブル１０８６は、ストレージシステム１８毎に、どのＬＵの処理が自身に割当られているかを管理するテーブルである。ＬＵＮ管理テーブル１０８６は、ホストＬＵＮ１０８６ａ、内部ＬＵＮ１０８６ｂ、及びサイズ１０８６ｃを管理する。ホストＬＵＮ１０８６ａは、ホストコンピュータ１０から認識されるＬＵの識別番号である。内部ＬＵＮ１０８６ｂは、ストレージシステム１８で認識されるＬＵの識別番号である。サイズ１０８６ｃは、ホストＬＵＮ１０８６ｃに対応するＬＵのサイズである。

図５３は、第４実施例に係るパリティグループモニタテーブルの構成図である。

パリティグループモニタテーブル１０８０は、パリティグループがどのＴｉｅｒとして認識されているかを管理するテーブルである。パリティグループモニタテーブル１０８０は、パリティグループ番号１０８０ａ、Ｔｉｅｒ１０８０ｂ、及びプール番号１０８０ｃを管理する。パリティグループ番号１０８０ａは、パリティグループの番号である。Ｔｉｅｒ１０８０ｂは、Ｔｉｅｒの階層を示す情報である。プール番号１０８０ｃは、パリティグループが属するプールの識別番号である。

図５４は、第４実施例に係る構成管理情報の構成図である。

構成情報２０２’は、Ｔｉｅｒ毎の割当てを管理する各Ｔｉｅｒ構成管理情報１０９０（１０９０Ａ、１０９０Ｂ等）を含む。各Ｔｉｅｒ構成管理情報１０９０は、パリティグループ番号（＃）１０９０ａと、ページ番号（＃）１０９０ｂとを管理する。パリティグループ番号１０９０ａは、パリティグループの番号である。ページ番号１０９０ｂは、パリティグループのページの番号である。

図５５は、第４実施例に係る空き領域管理キューの構成図である。

空き領域管理キュー２０４は、図１３に示す第１実施例に係る空き領域管理キュー２０４と同等であるが、Ｔｉｅｒ毎に空き領域を管理する各Ｔｉｅｒ空き領域管理キュー１０９２（１０９２Ａ、１０９２Ｂ等）を備え、空き領域を管理するエントリの単位をページ単位としている。図５５に示す例では、Ｔｉｅｒ１の各Ｔｉｅｒ空き領域管理キュー１０９２Ａの先頭２２０’には、ページ「５」を示すエントリ２２２’が接続され、その次に、ページ「６」を示すエントリ２２４’が接続され、更に、ページ「７」を示すエントリ２２６’が接続されている。この各Ｔｉｅｒ空き領域管理キュー１０９２Ａによると、ページ「５」、「６」及び「７」が空き領域であることがわかる。

図５６は、第４実施例に係るＰｏｏｌ設定処理のフローチャートである。

最初に、ステップ２０００において、管理サーバ１４は、Ｐｏｏｌに加えるパリティグループの選択を受け付ける。次に、ステップ２００２において、管理サーバ１４は、追加するパリティグループの情報を基に、Ｔｉｅｒ毎に割当てる容量を算出する。

最後に、ステップ２００４において、管理サーバ１４は、各Ｔｉｅｒ容量をＰｏｏｌにアクセス可能なストレージシステム１８の数で割り、各Ｔｉｅｒの容量基準を設定する。ストレージ階層仮想化機能では、ページ再配置実施を判定する契機として、Ｔｉｅｒのデータ格納可能容量が上限を超える場合、又は、Ｔｉｅｒがサポート可能な性能値の上限を超える場合が考えられる。容量基準とは、前者に当たり、データ格納可能容量の上限を定める基準である。

なお、新規割当に関しては、一般的なシン・プロビジョニング機能と同様に、必要に応じてページを割り当てる。ページに関しては、Ｐｏｏｌの定義をしておけば従来と同様な方法で割当可能である。

図５７は、第４実施例に係る性能基準設定処理のフローチャートである。

性能基準設定処理は、Ｔｉｅｒがサポート可能な性能値を決定する処理である。

最初に、ステップ２０１０において、管理サーバ１４は、Ｔｉｅｒ毎の性能モニタリング情報を集計する。この性能モニタリング情報は、性能モニタリング情報管理テーブル６８の情報を利用する。

次に、ステップ２０１２において、管理サーバ１４は、Ｔｉｅｒ毎の限界性能を算出する。限界性能は、ステップ２０１０で集計した値と、ＣＰＵの使用率等から算出できる。限界性能の算出方法は、例えば、国際公開第２０１１／００１７７５号に開示されている。

最後に、ステップ２０１４において、管理サーバ１４は、各Ｔｉｅｒの性能基準を設定し、性能基準設定処理を終了する。

図５８は、第４実施例に係る性能負荷分散実施処理のフローチャートである。なお、図３０に示す第１実施例に係る性能負荷分散実施処理と同様な部分には、同一符号を付すこととする。

第４実施例に係る性能負荷分散実施処理においては、第１実施例に係る性能負荷分散実施処理のステップ４３８に代えて、ステップ２０２０に示すＬＵ移行処理（図５９参照）を実行する。

図５９は、第４実施例に係るＬＵ移行処理のフローチャートである。

ＬＵ移行処理は、図５８のステップ２０２０に対応する処理である。

最初に、ステップ２０３０において、管理サーバ１４は、移行元ＬＵに割り当てられたページで、専有デバイスユニット３６に格納されているものがあるか否かを判定する。

この結果、移行元ＬＵに割り当てられたページで、専有デバイスユニット３６に格納されているものがある場合（ステップ２０３０：Ｙｅｓ）は、ステップ２０３２において、管理サーバ１４は、当該ページのデータをストレージシステム間でコピーするコピー処理（図６０参照）を実行する。

一方、移行元ＬＵに割り当てられたページで、専有デバイスユニット３６に格納されているものがない場合（ステップ２０３０：Ｎｏ）、又はステップ２０３２の終了後、ステップ２０３４において、管理サーバ１４は、移行元ＬＵに割り当てられたページで共有デバイスユニット３４に格納されているものがあるか否かを判定する。

この結果、移行元ＬＵに割り当てられたページで共有デバイスユニット３４に格納されているものがない場合（ステップ２０３４：Ｎｏ）は、ステップ２０３８において、移行先ストレージシステムのＬＵＮ管理テーブルを更新し、ステップ２０３６において、ホストパスの設定を行うホストパス設定処理（図６１参照）を実行し、ＬＵ移行処理を終了する。

一方、移行元ＬＵに割り当てられたページで共有デバイスユニット３４に格納されているものがある場合（ステップ２０３４：Ｙｅｓ）は、ステップ４３８において、移行元から移行先ストレージシステムへの制御情報移行処理を実施し、ＬＵ移行処理を終了する。ステップ４３８における制御情報移行処理は、基本的には、図３１に示した通りであるが、移行先ストレージシステムのＬＵＮ管理テーブルには、移行元ＬＵＮは存在しない。よって、移行先ストレージシステムのＬＵＮ管理テーブルにおいて、当該ＬＵＮの管理情報を追加する必要がある。

図６０は、第４実施例に係るコピー処理のフローチャートである。

コピー処理は、図５９のステップ２０３２に対応する処理である。

最初に、ステップ４５２において、管理サーバ１４は、移行元キャッシュデータ処理を実施する。移行元キャッシュデータ処理は、第１実施例に係る図３１のステップ４５２と同様な処理であり、具体的には、移行元キャッシュデータ処理は、移行元キャッシュディレクトリ・クリーン化処理（図３２参照）と、移行先キャッシュディレクトリ・ダーティ化処理（図３３参照）とを含む。

次に、ステップ２０５２において、管理サーバ１４は、当該ページのデータ移行先は共有デバイスユニット３４であるか否かを判定する。

この結果、当該ページのデータ移行先が共有デバイスユニット３４である場合（ステップ２０５２：Ｙｅｓ）は、ステップ２０５８において、管理サーバ１４は、ストレージコントローラ２８のＢＥＰＫ３０経由でデータをコピーする。

一方、当該ページのデータ移行先が共有デバイスユニット３４でない場合（ステップ２０５２：Ｎｏ）は、ステップ２０５４において、管理サーバ１４は、ＦＥＰＫ３２のイニシエータポートとターゲットポートとの設定をする。次に、ステップ２０５６において、管理サーバ１４は、ＦＥＰＫ３２からネットワーク２６経由でデータをコピーする。

最後に、ステップ２０５８の終了後、又はステップ２０５６の終了後、ステップ２０４０において、管理サーバ１４は、ページ移動が発生したため、ページ移動に応じた内容に仮想論理変換テーブル１０７６を更新し、コピー処理を終了する。

図６１は、第４実施例に係るホストパス設定処理のフローチャートである。

ホストパス設定処理は、図３１に示す第１実施例に係る制御情報移行処理のステップ４６２以降と同様な処理である。

以上、幾つかの実施例を説明したが、これらは、本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。すなわち、本発明は、他の種々の形態でも実施する事が可能である。例えば、各ストレージシステム１８が、共有デバイスユニット３４のスイッチ３８に接続されるスイッチ３８を有していても良い。これにより、コネクティビティの向上が期待できる。

１４：管理サーバ、 １８，１８Ａ，１８Ｂ，１８Ｃ：ストレージシステム、 ３４：共有デバイスユニット

Claims (16)

1. 複数のホスト計算機が接続された複数のストレージコントローラをそれぞれ有する複数のストレージシステムと、
   前記複数のストレージシステムに提供される複数の記憶領域の基になる１以上の記憶媒体を含んだ記憶デバイスを有する共有デバイスユニットと、
   を有し、
   前記複数のストレージコントローラの各々は、前記１以上の記憶媒体に基づく前記複数の記憶領域を作成することができるようになっており、
   前記共有デバイスユニットは、前記記憶デバイスが有する前記１以上の記憶媒体が接続されたスイッチを有し、
   前記複数のストレージコントローラの各々は、
   前記共有デバイスユニットが有する前記スイッチに接続されており、
   前記記憶デバイスを有する前記共有デバイスユニットから提供された前記複数の記憶領域のうち少なくとも自分に提供されている記憶領域のＩＤを含んだ割当管理情報を記憶し、前記割当管理情報に含まれているＩＤに対応した記憶領域を、前記複数のホスト計算機のうち自分に接続されているホスト計算機に提供し、
   Ｉ／Ｏ先を指定したＩ／Ｏコマンドを受信した場合に、前記受信したＩ／ＯコマンドのＩ／Ｏ先に従う記憶領域に対してデータのＩ／Ｏを行うためのＩ／Ｏ要求を、前記記憶デバイスに送信するようになっており、
   前記複数の記憶領域は、前記複数のストレージシステムの負荷に基づき前記複数のストレージシステムに提供されており、
   前記記憶デバイスを有する前記共有デバイスユニットから提供された前記複数の記憶領域のうちの一の記憶領域である第１の記憶領域が、前記複数のストレージシステムのうちの一のストレージシステムである第１のストレージシステムに提供されており、
   前記記憶デバイスを有する前記共有デバイスユニットから提供された前記複数の記憶領域のうちの前記第１の記憶領域以外の一の記憶領域である第２の記憶領域が、前記複数のストレージシステムのうちの前記第１のストレージシステム以外の一のストレージシステムである第２のストレージシステムに提供されている、
   複合型ストレージシステム。
2. 前記複数のストレージシステムの各々が、プロセッサを有し、
   前記共有デバイスユニットの前記記憶デバイスは、各ストレージシステムのプロセッサの処理以上に処理可能な高速記憶デバイスである、
   請求項１記載の複合型ストレージシステム。
3. 前記共有デバイスユニットの前記記憶デバイスは、
   前記１以上の記憶媒体としての複数のフラッシュメモリチップと、
   前記複数のフラッシュメモリチップに対するデータのＩ／Ｏ（Input/Output）を制御するプロセッサである記憶デバイス内プロセッサと
   を有し、
   前記記憶デバイス内プロセッサが、
   各ストレージシステムの負荷を測定し、
   各ストレージシステムの負荷に基づいて、前記複数のストレージシステムから移行元のストレージシステムと移行先のストレージシステムとを選択し、且つ、前記移行元のストレージシステムに提供されている一以上の記憶領域から移行対象の記憶領域を選択し、
   前記移行対象の記憶領域が前記移行元のストレージシステムに代えて前記移行先のストレージシステムに提供されるための制御を行う、
   請求項２記載の複合型ストレージシステム。
4. 前記複数のストレージシステムに接続された管理計算機を有し、
   前記管理計算機が、前記複数のストレージシステムに代えて又は加えて、前記複数のストレージシステムが記憶する複数の割当管理情報を記憶する、
   請求項１又は２記載の複合型ストレージシステム。
5. 各割当管理情報が、記憶領域毎に、その割当管理情報を記憶しているストレージシステムがアクセス可能か否かを表すアクセス情報を含み、
   各ストレージシステムが、自分が記憶している割当管理情報におけるアクセス情報を基に、自分に提供されている記憶領域に対するアクセスの可否を判断する、
   請求項１又は２記載の複合型ストレージシステム。
6. 前記複数の記憶領域と前記複数のストレージシステムの関係を制御する領域制御装置を有し、
   前記複数のストレージシステムの各々は、Ｉ／Ｏ（Input/Output）先を指定したＩ／Ｏコマンドを受信することができるようになっており、前記Ｉ／Ｏコマンドを受信したストレージシステムは、前記Ｉ／Ｏコマンドの処理において、前記受信したＩ／ＯコマンドのＩ／Ｏ先に従う記憶領域に対してデータのＩ／Ｏを行うためのＩ／Ｏ要求を前記記憶デバイスに送信するようになっており、
   （Ａ）前記領域制御装置が、各ストレージシステムの負荷を測定し、
   （Ｂ）前記領域制御装置が、各ストレージシステムの負荷に基づいて、前記複数のストレージシステムから移行元のストレージシステムと移行先のストレージシステムとを選択し、且つ、前記移行元のストレージシステムに提供されている一以上の記憶領域から移行対象の記憶領域を選択し、
   （Ｃ）前記領域制御装置が、前記移行対象の記憶領域が前記移行元のストレージシステムに代えて前記移行先のストレージシステムに提供されるための制御を行う、
   請求項１又は２記載の複合型ストレージシステム。
7. 前記領域制御装置は、前記共有デバイスユニットに含まれている、
   請求項６記載の複合型ストレージシステム。
8. 前記記憶デバイスは、
   前記１以上の記憶媒体と、
   前記１以上の記憶媒体に接続されており前記記憶媒体に対するデータのＩ／Ｏを制御するコントローラである媒体コントローラと
   を有し、
   前記領域制御装置は、前記媒体コントローラである、
   請求項７記載の複合型ストレージシステム。
9. 前記移行先のストレージシステムが、前記移行対象の記憶領域のＩＤを前記移行先のストレージシステムの割当管理情報に書き込み、
   前記媒体コントローラが、提供先のストレージシステムのＩＤと記憶領域の負荷とを記憶領域毎に表す領域管理情報を記憶しており、
   前記移行対象の記憶領域は、負荷が最も高い記憶領域であり、
   前記移行先のストレージシステムは、測定された負荷が前記複数のストレージシステムのうち最も負荷の低いストレージシステムであり、
   前記（Ｃ）で、前記媒体コントローラが、前記領域管理情報における、前記移行対象の記憶領域に対応したＩＤを、前記移行先のストレージシステムのＩＤに変更し、
   前記移行元のストレージシステムが、前記領域管理情報の更新の後に、前記移行対象の記憶領域のＩＤを前記移行元のストレージシステムの割当管理情報から削除する、
   請求項８記載の複合型ストレージシステム。
10. 各ストレージシステムが、提供された記憶領域に書き込まれるデータを一時的に記憶するキャッシュメモリを有しており、
    前記移行元のストレージシステムが、前記移行先のストレージシステムの割当管理情報の更新の後に、デステージ処理を行い、前記デステージ処理において、前記キャッシュメモリに記憶されており前記記憶デバイスの記憶領域に書き込まれていないデータのうち、前記移行対象の記憶領域が書き込み先のデータを、前記移行対象の記憶領域に書き込み、
    前記デステージ処理の後に、前記（Ｃ）が行われる、
    請求項９記載の複合型ストレージシステム。
11. 前記デステージ処理において、前記移行元のストレージシステムが、前記移行対象の記憶領域がＩ／Ｏ先となるＩ／Ｏコマンドをホスト装置から受信し、受信したＩ／Ｏコマンドを、前記移行先のストレージシステムに転送し、前記移行先のストレージシステムが、前記移行元のストレージシステムからのＩ／Ｏコマンドを処理する、
    請求項１０記載の複合型ストレージシステム。
12. 前記媒体コントローラが、前記複数のストレージシステムのいずれかから領域割当要求を受け、前記領域割当要求に応答して、前記複数の記憶領域のうち、前記複数のストレージシステムのいずれにも割り当てられていない記憶領域を特定し、前記特定した記憶領域を、前記領域割当要求の送信元のストレージシステムに提供する、
    請求項８記載の複合型ストレージシステム。
13. 各ストレージシステムは、前記媒体コントローラに送信するＩ／ＯコマンドにそのＩ／ＯコマンドのＩ／Ｏ処理の優先度を関連付けるようになっており、
    前記媒体コントローラが、Ｉ／ＯコマンドのＩ／Ｏ処理の複数の優先度にそれぞれ対応した複数のキューを有しており、
    前記媒体コントローラが、受信したＩ／Ｏコマンドを、その受信したＩ／Ｏコマンドに関連付けられている優先度に応じたキューに振り分け、
    前記媒体コントローラが、前記複数のキューに関連付けられているＩ／Ｏコマンドを、前記複数のキューにそれぞれ対応した複数の優先度に応じて処理する、
    請求項８記載の複合型ストレージシステム。
14. 前記複数のストレージシステムのうちの少なくとも１つが、前記共有デバイスユニット内の記憶デバイスよりも低速の記憶デバイスである専用記憶デバイスを有しており、
    前記複数のストレージシステムのうちの少なくとも１つが、複数の仮想領域で構成された仮想的な論理ボリュームを提供し、書き込み先の仮想領域に、複数のティアで構成されたプールから記憶領域を割り当てるようになっており、
    各ティアは、同様のＩ／Ｏ性能を有する２以上の記憶領域で構成されており、
    前記プールには、前記専用記憶デバイスに基づく記憶領域と、前記共有デバイスユニット内の前記記憶デバイスに基づく記憶領域とが混在しており、
    前記共有デバイスユニット内の前記記憶デバイスに基づく記憶領域を含むティアは、前記専用記憶デバイスに基づく記憶領域を含むティアよりもＩ／Ｏ性能が高いティアである、
    請求項１乃至１３のうちのいずれか１項に記載の複合型ストレージシステム。
15. 前記領域制御装置は、前記複数のストレージシステムのうちの１つのストレージシステム、又は、前記複数のストレージシステムに接続された管理計算機である、
    請求項６記載の複合型ストレージシステム。
16. １以上の記憶媒体を含んだ記憶デバイスを有する共有デバイスユニットが、前記１以上の記憶媒体に基づく複数の記憶領域を、複数のホスト計算機が接続された複数のストレージコントローラをそれぞれ有する複数のストレージシステムに提供し、前記複数の記憶領域は、前記複数のストレージシステムの負荷に基づき前記複数のストレージシステムに提供されており、この結果、
    前記記憶デバイスを有する前記共有デバイスユニットから提供された前記複数の記憶領域のうちの一の記憶領域である第１の記憶領域が、前記複数のストレージシステムのうちの一のストレージシステムである第１のストレージシステムに提供されており、
    前記記憶デバイスを有する前記共有デバイスユニットから提供された前記複数の記憶領域のうちの前記第１の記憶領域以外の一の記憶領域である第２の記憶領域が、前記複数のストレージシステムのうちの前記第１のストレージシステム以外の一のストレージシステムである第２のストレージシステムに提供されており、
    前記複数のストレージコントローラの各々が、前記記憶デバイスを有する前記共有デバイスユニットから提供された前記複数の記憶領域のうち少なくとも自分に提供されている記憶領域のＩＤを含んだ割当管理情報を記憶し、前記割当管理情報に含まれているＩＤに対応した前記記憶領域を、前記複数のホスト計算機のうち自分に接続されているホスト計算機に提供し、
    前記複数のストレージコントローラの各々は、前記１以上の記憶媒体に基づく前記複数の記憶領域を作成することができるようになっており、
    前記共有デバイスユニットは、前記記憶デバイスが有する前記１以上の記憶媒体が接続されたスイッチを有し、
    前記複数のストレージコントローラの各々は、
    前記共有デバイスユニットが有する前記スイッチに接続されており、
    Ｉ／Ｏ先を指定したＩ／Ｏコマンドを受信した場合に、前記受信したＩ／ＯコマンドのＩ／Ｏ先に従う記憶領域に対してデータのＩ／Ｏを行うためのＩ／Ｏ要求を、前記記憶デバイスに送信するようになっている、
    記憶制御方法。

Images