実施例について、図面を参照して説明する。なお、以下に説明する実施例は特許請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。
なお、以後の説明では「aaaテーブル」等の表現にて本発明の情報を説明する場合があるが、これら情報は、テーブル等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「aaaテーブル」等について「aaa情報」と呼ぶことがある。
まず、第1実施例の概要について説明する。
1台のストレージシステムのCPUの処理以上に、処理可能な高速デバイスの出現により、高速デバイスのリソースを有効に利用できない問題がある。これに対して、第1実施例に係る計算機システムでは、複数のストレージシステムで、1台のデバイスユニットを共有するようにする。具体的には、1台のデバイスユニット内の記憶領域を分割し、分割した記憶領域(デバイス割当領域)を各ストレージシステムへ割り当てることで、各ストレージシステムがデバイスユニットを共有できるようにする。ここで、共有するデバイスユニットへ接続されている各ストレージシステムにおいて、そのストレージシステムのシステム限界性能以上の負荷が掛かった状況では、ストレージシステムが性能ネックとなってしまい、デバイスユニットのリソースを有効に利用することができない。これに対して、第1実施例に係る計算機システムでは、ストレージシステム毎及びデバイス割当領域毎に性能モニタリング情報を採取し、その性能モニタリング情報を基に、デバイス割当領域を割当てるストレージシステムを変更することで、各ストレージシステムへの性能負荷の平準化を実施する。また、第1実施例に係る計算機システムでは、各ストレージシステムがデバイス割当領域の割当管理情報を保持するので、新規装置を設置する必要がなく、コスト増大を防ぐことができる。
以下、第1実施例に係る計算機システムの詳細を説明する。
図1は、第1実施例に係る計算機システムの構成図である。
計算機システムは、1以上のホストコンピュータ10と、管理サーバ14と、複数のストレージシステム18(18A、18B、18C等)と、共有デバイスユニット34とを含む。ホストコンピュータ10、管理サーバ14、及びストレージシステム18は、ネットワーク26を介して接続されている。
ホストコンピュータ10はI/F12を介してネットワーク26に接続されている。ホストコンピュータ10は、ブロックプロトコルによって、ネットワーク26に接続されているストレージシステム18と通信を行う。
管理サーバ14は、計算機システムの全構成情報を保持している。また、管理サーバ14は、I/F16を介してネットワーク26に接続されている。管理サーバ14は、ネットワーク26を介して、ストレージシステム18や、ホストコンピュータ10と通信を行う。
ストレージシステム18は、管理サーバ14からのコマンドに従って、記憶領域内の論理ユニット(LU)の構成等のパラメータを変更したり、性能モニタリング情報を収集したりする。ストレージシステム18は、共有デバイスユニット34及び/又は専有デバイスユニット36の記憶媒体によって実現される記憶領域を管理し、ネットワーク26に接続されたホストコンピュータ10からのコマンドに従って、記憶領域に対するデータ(ユーザデータ)のリード・ライトを実行する。
ストレージシステム18は、ストレージコントローラ28(28A、28B、28C等)を有する。ストレージコントローラ28は、ストレージシステム18の制御処理を実行する。ストレージコントローラ28は、FEPK(Front End Package)32とBEPK(Back End Package)30とを有する。FEPK32は、ホストコンピュータ10や管理サーバ14と通信するためのインタフェースである。FEPK32は、ネットワークケーブル44を介してネットワーク26に接続されている。
また、FEPK32は、イニシエータとしてのネットワークケーブル22と、ターゲットとしてのネットワークケーブル24を介してネットワーク26に接続されている。ネットワークケーブル22、ネットワークケーブル24、及びネットワーク26は、他のストレージシステム18と通信するためのパスとなる。なお、他のストレージシステム18と通信するパスの構成はこれに限られず、イニシエータもしくはターゲットとして設定変更可能なネットワークケーブルを用いる場合であれば、ネットワークケーブル22とネットワークケーブル24とを一本のネットワークケーブルとしても良く、ネットワークケーブル22とネットワークケーブル24とネットワークケーブル44を一本のネットワークケーブルとしても良い。BEPK30は、共有デバイスユニット34や専有デバイスユニット36と接続するためのインタフェースである。
ストレージシステム18は、例えば、ストレージシステム18B及び18Cのように内部に専有デバイスユニット36を備えていても良いし、ストレージシステム18Aのように内部に専有デバイスユニット36を備えていなくても良い。専有デバイスユニット36は、スイッチ(SW)38と、デバイス40とを含む。専有デバイスユニット36のスイッチ38は、専用デバイスユニット36が属するストレージシステム18のストレージコントローラ28のBEPK30と接続されており、そのストレージコントローラ28のみがデバイス40にアクセス可能となっている。
共有デバイスユニット(デバイスユニット#0という場合もある)34は、スイッチ(SW)38と、デバイス40とを含む。デバイス40は、記憶領域を有する。共有デバイスユニット34のスイッチ38は、ケーブル42を介して、複数のストレージシステム18のストレージコントローラ28(具体的には、ストレージコントローラ18のBEPK30)に接続されている。図1に示す例では、スイッチ38は、ケーブル42を介して、ストレージコントローラ18A、18B、18Cに接続されている。ケーブル42は、例えば、SASケーブルやPCIeケーブルなどで良い。このような構成により、共有デバイスユニット34のデバイス40の記憶領域に対して、複数のストレージシステム18がアクセスすることができる。
図2は、第1実施例に係るデバイスの構成図である。
デバイス40は、1以上の記憶媒体50を含む。記憶媒体50は、ケーブル52を介して、スイッチ38に接続されている。記憶媒体50は、SATAディスクやSASディスク等のHDDでも、SSDやフラッシュドライブ等の高速な記憶媒体でも良い。
図3は、第1実施例に係るデバイス割当単位を説明する図である。
パリティグループ300は、複数の記憶媒体50の記憶領域により構成される。パリティグループ300は、障害に備えたデータの冗長性を考えて、所定のRAID(Redundant Array of Independent Disks)レベルのRAID構成となっている。ただし、パリティグループ300を構成する記憶媒体は、同一デバイスユニットに格納されている必要がある。
パリティグループ300は、1以上の論理ユニット(LU)302(図3では、302A、302B、302C)で構成される。LU302は、所定のデータ単位であるチャンク306単位で分割されている。なお、LU302において、チャンク306をさらに分割したデータ単位であるページ304(304C)に分割するようにしても良い。なお、共有デバイスユニット34及び専有デバイスユニット36が、ストレージシステム18に割り当てるデータ単位は、パリティグループ300単位でも、LU302単位でも、チャンク306単位でも、ページ304単位でも良い。ただし、ホストコンピュータ10からは、データ割当単位はLU302として認識されるため、後述する性能負荷分散を考慮したデータ割当配置変更においては、LU302単位で実施することが望ましい。なお、以降においては、ストレージシステム18へのデータ割当単位をLU302とした場合を例に説明する。
図4は、第1実施例に係る管理サーバの構成図である。
管理サーバ14は、CPU60と、メモリ64と、I/F16とを含む。CPU60と、メモリ64と、I/F62とは内部ケーブル62を介して接続されている。CPU60は、メモリ64に格納されたプログラムや、データを用いて各種処理を実行する。I/F16は、ネットワーク26に接続するためのインタフェースである。メモリ64は、計算機システムの構成情報70、性能モニタリング情報管理テーブル68、キャッシュ領域66、及びアプリケーションプログラム80を含む。構成情報70は、ホストコンピュータ割当管理テーブル72、LUN管理テーブル74、デバイス管理テーブル76、及び共有デバイスユニット管理テーブル78を含む。
図5は、第1実施例に係るホストコンピュータ割当管理テーブルの構成図である。
ホストコンピュータ割当管理テーブル72は、各ホストコンピュータ10に割り当てられた記憶領域を管理するための管理情報90(90A、90B、90C等)を格納する。図5においては、管理情報90Aがホストコンピュータ#0についての管理情報であり、管理情報90Bがホストコンピュータ#1についての管理情報であり、管理情報90Cがホストコンピュータ#2についての管理情報である。
管理情報90は、デフォルト・ストレージシステム番号(#)98(98A、98B、98C等)を保持するとともに、ホストLUN92(92A、92B、92C等)と、オーナストレージシステム番号(#)94(94A、94B、94C等)と、サイズ96(96A、96B、96C等)とを保持する。デフォルト・ストレージシステム番号98は、ホストコンピュータ10によるI/O処理を担当するデフォルトのストレージシステム(デフォルト・ストレージシステム)を識別するストレージシステム番号(デフォルト・ストレージシステム番号)である。ホストLUN92は、ホストコンピュータ10から認識されるLUの識別番号である。オーナストレージシステム番号94は、ホストLUN92に対応するLUの処理を担当するストレージシステムの番号である。オーナストレージシステム番号94は、新規でLUが割当られた際は、各ホストコンピュータ10のデフォルト・ストレージシステム番号98に設定されるが、後述する性能負荷分散処理(図28参照)を実行した場合には、変更される場合もある。サイズ96は、ホストLUN92に対応するLUのサイズである。
図6は、第1実施例に係るLUN管理テーブルの構成図である。
LUN管理テーブル74は、各ストレージシステムに関するストレージシステム割当管理情報100(100A、100B等)と、1以上の共有LUN管理テーブル102(102A等)とを含む。共有LUN管理テーブル102は、共有デバイスユニット34に格納されているLUのLUN情報を管理する。計算機システムに共有デバイスユニット34が複数個存在する場合は、LUN管理テーブル74には、それぞれの共有デバイスユニット34に対して1つの共有LUN管理テーブル102が管理される。
共有LUN管理テーブル102は、ホストLUN102aと、内部LUN102bと、サイズ102cと、パリティグループ番号(#)102dと、RAIDレベル102e、先頭物理アドレス102f、及びオーナストレージシステム番号102gを含む。
ホストLUN102aは、ホストコンピュータ10から認識されるLUの識別番号である。内部LUN102bは、ストレージシステム18で認識されるLUの識別番号(内部LUN)である。内部LUNは、例えば、ストレージシステムの内部処理等で用いられる。サイズ102cは、ホストLUN102aに対応するLUのサイズである。パリティグループ番号102dは、ホストLUN102aに対応するLUが所属するパリティグループの番号である。RAIDレベル102eは、パリティグループ番号102dのパリティグループのRAIDレベルである。先頭物理アドレス102fは、ホストLUN102aに対応するLUのデータが格納されているデバイスにおける物理的なデータ格納場所の先頭を示す先頭物理アドレスである。オーナストレージシステム番号102gは、ホストLUN102aに対応するLUを処理するストレージシステムの番号である。
図7は、第1実施例に係るストレージシステム割当管理情報の構成図である。なお、図7は、ストレージシステム#1のストレージシステム割当管理情報100Bを示している。なお、他のストレージシステムのストレージシステム割当管理情報も同様な構成となっている。
ストレージシステム割当管理情報100Bは、ストレージシステム18が専有するデバイスユニット36におけるデータの割当てを管理するための情報であり、例えば、専有デバイスユニット管理テーブル110を含む。専有デバイスユニット管理テーブル110は、ストレージシステム18に割当られたホストLUN110aに関する情報を管理している。
専有デバイスユニット管理テーブル110は、ホストLUN110a、内部LUN110b、サイズ110c、パリティグループ番号110d、RAIDレベル110e、先頭物理アドレス110f、及びデバイスユニット番号(#)110gを含む。
ホストLUN110aは、ホストコンピュータ10から認識されるLUの識別番号である。内部LUN110bは、ストレージシステムで認識されるLUの識別番号(内部LUN)である。内部LUNは、例えば、ストレージシステムの内部処理等で用いられる。サイズ110cは、ホストLUN110aに対応するLUのサイズである。パリティグループ番号110dは、ホストLUN110aに対応するLUが所属するパリティグループの番号である。RAIDレベル110eは、パリティグループ番号110dのパリティグループのRAIDレベルである。先頭物理アドレス110fは、ホストLUN110aに対応するLUのデータが格納されているデバイスにおける物理的なデータ格納場所の先頭を示す先頭物理アドレスである。デバイスユニット番号110gは、ホストLUN110aに対応するLUを格納するデバイスユニットの番号である。
図8は、第1実施例に係るデバイス管理テーブルの構成図である。
デバイス管理テーブル76は、各デバイスユニット単位でデバイスユニット管理テーブル160(160A、160B等)を格納する。デバイスユニット管理テーブル160は、デバイスユニット(34,36等)の構成情報が格納される。
デバイスユニット管理テーブル160は、パリティグループ番号160a、RAIDレベル160b、デバイスID160c、及びサイズ160dを含む。パリティグループ番号160aは、パリティグループの番号である。RAIDレベル160bは、パリティグループ番号160aのパリティグループのRAIDレベルである。デバイスID160cは、パリティグループを構成する記憶媒体50の識別番号である。サイズ160dは、パリティグループのサイズである。
図9は、第1実施例に係る共有デバイスユニット管理テーブルの構成図である。
共有デバイスユニット管理テーブル78は、共有判定情報180(図10参照)と、構成管理テーブル182(図11参照)とを含む。
図10は、第1実施例に係る共有判定情報の構成図である。
共有判定情報180は、共有判定管理テーブル194と、共有デバイスユニット使用可能管理キュー196とを含む。
共有判定管理テーブル194は、計算機システムを構成する全デバイスユニットについて、当該デバイスユニットを複数のストレージシステムが共有しているか否かの情報を管理するテーブルであり、各デバイスユニットについて、デバイスユニット番号194aと、共有ビット194bとを格納する。
デバイスユニット番号194aは、デバイスユニットを識別する識別番号である。共有ビット194bは、デバイスユニット番号194aのデバイスユニットが複数のストレージシステムにより共有されているか否かを示すビットであり、例えば、デバイスユニットが共有されている場合には、「1」が設定され、デバイスユニットが共有されていない場合には、「0」が設定される。計算機システムが、図1に示す構成である場合には、デバイスユニット番号194aが「0」に対して、共有ビット194bが「1」が設定される。
共有デバイスユニット使用可能管理キュー196は、共有判定管理テーブル194で共有ビット194bが「1」のデバイスユニット番号194aの内、共有デバイスユニットとして使用可能なものを管理する。共有デバイスユニット使用可能管理キュー196は、FDKUQ198を作成し、使用可能な共有デバイスユニットを示すエントリ(例えば、デバイスユニット番号を示すエントリ)を、FDKUQ198に接続する。図10の例では、FDKUQ198には、「0」が含まれたエントリ199が接続されている。エントリ199は、デバイスユニット番号0のデバイスユニット(共有デバイスユニット34)が使用可能であることを示している。
図11は、第1実施例に係る構成管理テーブルの構成図である。
構成管理テーブル182は、共有デバイスユニット毎に共有デバイスユニット管理テーブル200を保持する。共有デバイスユニット管理テーブル200は、共有デバイスユニットの構成管理情報(図12参照)202及び空き領域管理キュー204(図13参照)を含む。
図12は、第1実施例に係る構成管理情報の構成図である。
構成管理情報202は、内部LUN202aと、ストレージシステム番号(#)202bとを含む。内部LUN202aは、共有デバイスユニット34内のストレージシステム18で認識されるLUの識別番号(内部LUN)である。ストレージシステム番号202bは、内部LUN202aに対応するLUに対して処理を実行するストレージシステム18の番号である。
図13は、第1実施例に係る空き領域管理キューの構成図である。
空き領域管理キュー204は、1台の共有デバイスユニット34に対して1セット作成され、共有デバイスユニット34における空き領域となっているLUを管理するキューである。空き領域管理キュー204は、先頭エントリ220に、空き領域となっている内部LUを示すエントリ222、224、226等を接続する。図13に示す例では、デバイスユニット#0のデバイスユニット(共有デバイスユニット34)について、空き領域管理キューの先頭エントリ220が作成され、先頭エントリ220に対して、内部LUN「5」を示すエントリ222が接続され、その次に、内部LUN「6」を示すエントリ224が接続され、更に、内部LUN「7」を示すエントリ226が接続されている。この空き領域管理キュー204によると、内部LUN「5」、「6」及び「7」が空き領域であることがわかる。
空き領域管理キュー204は、次のように管理される。すなわち、ホストLUNの削除が発生した場合は、管理サーバ14は、当該ホストLUNに対応する内部LUNのLUを格納する共有デバイスユニットの空き領域管理キュー204に、この内部LUNに対応するエントリを追加する。また、ホストLUNが新たに設定された場合は、管理サーバ14は、空き領域管理キュー204を見て、割当て可能なLUを示す内部LUNを判別し、当該内部LUNのエントリを空き領域管理キュー204から削除する。
図14は、第1実施例に係る性能モニタリング情報管理テーブルの構成図である。
性能モニタリング情報管理テーブル68は、ストレージシステム別性能モニタリング情報230と、ストレージシステム内の性能モニタリング情報を管理する内訳性能モニタリング情報232(図15参照)とを含む。ストレージシステム別性能モニタリング情報230は、ストレージシステム毎の性能負荷を管理するテーブルであり、ストレージシステム番号(#)230aと、性能負荷230bとを管理する。ストレージシステム番号230aは、ストレージシステム18を識別する識別番号である。性能負荷230bは、例えば、ストレージシステム番号230aのストレージシステム18のCPU260(図17参照)の負荷である。本実施例では、CPU260の負荷として、例えば、CPU260が処理したI/Oの1秒あたりの数(平均I/O数)としている。
図15は、第1実施例に係る内訳性能モニタリング情報の構成図である。
内訳性能モニタリング情報232は、ストレージシステム18のそれぞれに対するストレージシステム毎性能モニタリング情報240(240A、240B等)を含む。ストレージシステム毎性能モニタリング情報240は、内部LUN240aと、性能負荷240bとを含む。内部LUN240aは、ストレージシステム毎性能モニタリング情報240に対応するストレージシステム18が処理を担当しているLUの内部LUNである。性能負荷240bは、内部LUN240aに対応するLUに対する性能負荷である。
図16は、第1実施例に係るホストコンピュータの構成図である。なお、図16は、ホストコンピュータ#0の構成を示しているが、他のホストコンピュータの構成も同様である。
ホストコンピュータ10(10A)は、CPU252と、I/F12と、メモリ254とを含む。CPU252と、メモリ254と、I/F12とは、内部ケーブル250を介して接続されている。
CPU252は、メモリ254に格納されたプログラムを実行することにより、各種処理を実行する。メモリ254は、構成情報258と、キャッシュ領域256とを含む。構成情報258は、当該ホストコンピュータ10に割当られた領域を管理するホストコンピュータ割当管理テーブル257を含む。ホストコンピュータ割当管理テーブル257は、管理サーバ14が保持しているホストコンピュータ割当管理テーブル72内の当該ホストコンピュータ10に対応するホストコンピュータ割当管理情報90と同等な情報を記憶する。図16の例では、ホストコンピュータ割当管理テーブル257は、図5のホストコンピュータ#0に対応するホストコンピュータ割当管理テーブル90Aと同等な情報を記憶している。
図17は、第1実施例に係るストレージコントローラの構成図である。図17は、ストレージシステム18A(ストレージシステム#0)のストレージコントローラ28Aを例に示している。なお、他のストージコントローラの構成も同様な構成となっている。
ストレージコントローラ28は、CPU260と、FEPK32と、BEPK30と、メモリ266とを含む。CPU260、FEPK32、BEPK30、及びメモリ266は、内部ネットワーク262を介して接続されている。
CPU260は、メモリ266に格納されたプログラムを実行することにより各種処理を実行する。メモリ266は、構成情報268と、性能モニタリング情報バッファ領域270と、キャッシュ領域272と、キャッシュ管理テーブル274(図19参照)と、ストレージ制御プログラム276とを格納する。
構成情報268は、ストレージシステムに割当られた領域(割当領域)を管理するためのストレージシステム割当管理テーブル277と、計算機システムにおける共有デバイスユニット34内の領域を管理するための集約共有デバイスユニット管理テーブル278(図18参照)とを含む。ストレージシステム割当管理テーブル277は、管理サーバ14が保持しているLUN管理テーブル74のストレージシステム割当管理情報100と同等な情報を格納する。
性能モニタリング情報バッファ領域270は、ストレージシステム18で採取した性能モニタリング情報を管理サーバ14へある程度纏めて送信するために、一時的に性能モニタリング情報を溜めておくバッファ領域である。ストレージ制御プログラム276は、ストレージシステムにおける各種処理を実行するためのプログラムである。キャッシュ領域272は、デバイスユニットに書き込むデータ、又はデバイスユニットから読み出されたデータを一時的に格納する領域である。
図18は、第1実施例に係る集約共有デバイスユニット管理テーブルの構成図である。図18の例では、ストレージコントローラ28A内の集約共有デバイスユニット管理テーブル278(278A)を示している。
集約共有デバイスユニット管理テーブル278は、計算機システムのストレージコントローラ28毎に管理されている。集約共有デバイスユニット管理テーブル278は、計算機システムに存在する共有デバイスユニット34毎の情報を管理する集約共有管理テーブル279(270A等)を含む。計算機システムに複数台の共有デバイスユニット34が存在する場合は、複数個の集約共有管理テーブル279がストレージシステム毎の集約共有デバイスユニット管理テーブル278に格納される。
集約共有管理テーブル279は、管理サーバ14に格納されている共有LUN管理テーブル102とほぼ同内容の情報を格納する。集約共有管理テーブル279は、ホストLUN279a、内部LUN279b、サイズ279c、パリティグループ番号279d、RAIDレベル279e、先頭物理アドレス279f、及びオーナビット279gを含む。ホストLUN279a、内部LUN279b、サイズ279c、パリティグループ番号279d、RAIDレベル279e、及び先頭物理アドレス279fは、管理サーバ14に格納されている共有LUN管理テーブル102の同名の情報と同内容である。
オーナビット279gは、当該ストレージコントローラ28を含むストレージシステム18が、ホストLUN279aのLUを処理するストレージシステム18であるか否かを示すビットであり、ホストLUN279aのLUを処理するストレージシステム18である場合には、ON(例えば、「1」)が設定され、ホストLUN279aのLUを処理するストレージシステムでない場合には、OFF(例えば、「0」)が設定される。
図19は、第1実施例に係るキャッシュ管理テーブルの構成図である。
キャッシュ管理テーブル274は、キャッシュの管理単位の状態を管理するためのテーブルであり、キャッシュの管理単位毎にキャッシュ管理エントリ282を格納する。キャッシュ管理エントリ282には、キャッシュアドレス284、格納データ識別情報286、ダーティフラグ288、及びデステージ許可フラグ290が格納される。キャッシュアドレス284は、キャッシュされているデータのアドレスである。格納データ識別情報286は、キャッシュされているデータ(格納データ)を識別する識別情報である。ダーティフラグ288は、キャッシュされているデータがダーティデータ(すなわち、記憶媒体50に反映されていないデータ)であるか否かを示すフラグである。デステージ許可フラグ290は、キャッシュされているデータを記憶媒体50にデステージ可能であるか否かを示すフラグである。
図20は、第1実施例に係るストレージシステムへ割り当てた領域を説明する図である。
共有デバイスユニット34のスイッチ38には、SAS/PCIeなどのケーブル42を介して、複数台のストレージシステム18が接続されている。デバイス40の記憶領域は、論理的な空間で管理されており、この論理空間は、ストレージシステム#0(ストレージシステム18A)に割り当てられた割当領域310と、ストレージシステム#1(ストレージシステム18B)に割り当てられた割当領域312と、ストレージシステム#2(ストレージシステム18C)に割り当てられた割当領域314とに分けられて管理されており、各ストレージシステム18がアクセス可能な領域が限定されるように管理されている。
次に、第1実施例に係る計算機システムにおける処理動作について説明する。
まず、共有デバイスユニットをストレージシステムへ新規登録する共有デバイスユニット新規登録処理について説明する。
図21は、第1実施例に係る共有デバイスユニット新規登録処理のフローチャートである。
管理サーバ14は、新規登録するデバイスユニットの指定を計算機システムの管理ユーザから受け付け、共有判定管理テーブル194に、指定されたデバイスユニットのデバイスユニット番号194aの行を追加し、当該行の共有ビット194bを「1」に設定する(ステップ320)。なお、共有判定管理テーブル194に、指定されたデバイスユニットのデバイスユニット番号194aの行が存在する場合は、行の追加作業を行う必要はなく、対応する行の共有ビット194bを「1」に設定する。
次に、管理サーバ14は、指定されたデバイスユニット内の論理構成(RAIDグループ、LU等)の作成を、代表のストレージシステム18へ指示する(ステップ322)。ここで、代表のストレージシステム18とは、論理構成を作成したりする処理を主導するストレージシステム18を指し、計算機システムにおいて1台あれば良く、予めいずれかのストレージシステム18に決定しておいても良いし、任意のストレージシステム18を選択するようにしても良い。
次に、ステップ324において、管理サーバ14から指示された代表のストレージシステム18は、当該デバイスユニット34内の複数の記憶媒体50から、パリティグループ300を作成し、そのパリティグループ300からLU302を作成する。その際、ストレージシステム18は、内部LUNとホストLUNとの設定も実施する。作成するパリティグループ300やLU302の構成に関しては、予めデフォルト値を管理サーバ14が代表ストレージシステム18に設定していても良いし、ステップ322において、管理サーバ14が代表ストレージシステム18へ構成を指示しても良い。LU302の作成後、管理サーバ14は、LUN管理テーブル74の共有LUN管理テーブル102を作成し、新規作成したLU302の管理情報を登録する。
次に、ステップ326において、管理サーバ14は、新規登録したLU302について、ストレージシステム18への新規割当を実施するか判定する。
この結果、新規登録したLU302について、ストレージシステムへの新規割当を実施する場合(ステップ326:Yes)は、ステップ328において、管理サーバ14は、新規作成したLU302にストレージシステム番号を振り、当該ストレージシステム番号を、LUN管理テーブル74の共有LUN管理テーブル102のオーナストレージシステム番号102gとして登録する。ここで、ストレージシステム番号の振り方は、当該共有デバイスユニット34に接続されている全ストレージシステムに対し、ラウンド・ロビン方式等で均等に割り振っても良いし、1つのストレージシステムに固定して割り振っても良い。ただし、性能面を考慮すると、ラウンド・ロビン方式の方が実用的である。
一方、新規登録したLU302について、ストレージシステムへの新規割当を実施しない場合(ステップ326:No)、又はステップ328の終了後、ステップ330において、管理サーバ14は、更新したLUN管理テーブル74の共有LUN管理テーブル102の情報を、当該共有デバイスユニット34に接続されている全ストレージシステム18のストレージコントローラ28内の集約共有デバイスユニット管理テーブル278へ反映する。その際、管理サーバ14は、集約共有デバイスユニット管理テーブル278の中の集約共有管理テーブル279のそのストレージシステム18が処理を担当するLUのホストLUN279aに対応する行のオーナビット279gを「1」に設定する。
次に、ステップ332において、管理サーバ14は、ストレージシステム18が未割当の新規作成したLUNがあるか否かを確認する。
この結果、ストレージシステムが未割当の新規作成したLUNがある場合(ステップ332:Yes)は、ステップ334において、管理サーバ14は、未割当の新規作成したLUNに対応するエントリを、共有デバイスユニット管理テーブル78の当該共有デバイスユニット管理テーブル200の空き領域管理キュー204に追加する。
次に、ステップ336において、管理サーバ14は、当該共有デバイスユニット34のデバイスユニット番号に対応するエントリを共有デバイスユニット使用可能管理キュー196に追加し、共有デバイスユニット新規登録処理を終了する。なお、ストレージシステム18が未割当の新規作成したLUNがない場合(ステップ332:No)は、共有デバイスユニット新規登録処理を終了する。
次に、共有デバイスユニット34の新規領域を割り当てる新規領域割当処理を説明する。
図22は、第1実施例に係る新規領域割当処理のフローチャートである。
新規領域割当処理は、例えば、図21のステップ326において、ストレージシステムへ新規割当を実施しなかった場合や、共有デバイスユニット34内のLU302をストレージコントローラ28から削除した場合に実行される処理であり、例えば、管理サーバ14やホストコンピュータ10からの領域の割当て要求に基づいて実行が開始される。
最初に、ステップ340において、管理サーバ14は、使用可能な共有デバイスユニット34があるか否かを、共有デバイスユニット管理テーブル78の共有デバイスユニット使用可能管理キュー196にエントリがあるか否かを確認することにより判定する。
この結果、使用可能な共有デバイスユニット34がないと判定した場合(ステップ340:No)は、管理サーバ14は、新規領域割当可能な共有デバイスユニット34が存在しない旨を、ホストコンピュータ10又はストレージシステム18を構築する別の管理サーバ14に通知し、新規領域割当処理を終了する。
一方、使用可能な共有デバイスユニット34があると判定した場合(ステップ340:Yes)は、ステップ342において、管理サーバ14は、共有デバイスユニット使用可能管理キュー196の先頭のエントリ199が示す共有デバイスユニット番号に対応する共有デバイスユニット34が使用可能であると考え、当該共有デバイスユニット34に対応する共有デバイスユニット構成管理テーブル200の空き領域管理キュー204にエントリがあるか判定する。
この結果、共有デバイスユニット34に対応する共有デバイスユニット構成管理テーブル200の空き領域管理キュー204にエントリがない場合(ステップ342:No)は、ステップ346において、管理サーバ14は、共有デバイスユニット使用可能管理キュー196において、当該共有デバイスユニット34に対応する共有デバイスユニット番号のエントリを削除し、処理をステップ340へ進める。
一方、共有デバイスユニット34に対応する共有デバイスユニット構成管理テーブル200の空き領域管理キュー204にエントリがある場合(ステップ342:Yes)は、管理サーバ14は、ステップ348において、当該共有デバイスユニット構成管理テーブル200の空き領域管理キュー204の先頭のエントリが示すLUNのLUが使用可能(割当可能)であると考え、当該LUを割当領域と決定し、割当領域確定処理(図23参照)を実施する。
次に、ステップ350において、管理サーバ14は、空き領域管理キュー204を更新する空き領域管理キュー更新処理(図24参照)を実施し、新規領域割当処理を終了する。
図23は、第1実施例に係る割当領域確定処理のフローチャートである。
割当領域確定処理は、図22のステップ348の処理に対応する。
最初に、ステップ360において、管理サーバ14は、割当領域が決定された共有デバイスユニット34に対応する共有デバイスユニット構成管理テーブル200の構成管理情報202における、割当可能なLUに対応する内部LUN202aに対応するストレージシステム番号202bを更新する。オーナストレージシステム番号202bは、デフォルト値としても良いし、ストレージシステム18の中の最小の番号を設定するようにしても良い。
次に、ステップ362において、管理サーバ14は、共有デバイスユニット34のLUN管理テーブル74の共有LUN管理テーブル102に関し、割当可能なLUのLUNに対応するオーナストレージシステム番号102gを、ステップ360で更新したオーナストレージシステム番号202bに更新する。
次に、ステップ364において、管理サーバ14は、ステップ360で更新したオーナストレージシステム番号202bに対応するストレージシステム18の共有デバイスユニット管理テーブル278における、割当対象の共有デバイスユニット34に対応する集約共有管理テーブル279へアクセスする。次に、管理サーバ14は、集約共有管理テーブル279において、LUのLUNに対応するオーナビット279gをON(「1」)に更新する。
次に、ステップ366において、管理サーバ14は、ホストコンピュータ割当管理テーブル72の割当先のホストコンピュータ10に対応する管理情報90にアクセスする。管理サーバ14は、割当先のホストコンピュータ10に対応する管理情報90において、割当可能なLUに対応するホストLUN92に対応するオーナストレージシステム番号94を、ステップ360で更新したストレージシステム番号202bに更新する。
最後に、管理サーバ14は、割当先のホストコンピュータ10に格納されているホストコンピュータ割当管理テーブル257にアクセスし、ステップ366と同様に、割当可能なLUに対応するホストLUNに対応するオーナストレージシステム番号を、ステップ360で更新したオーナストレージシステム番号202bに更新し、割当領域確定処理を終了する。
図24は、第1実施例に係る空き領域管理キュー更新処理のフローチャートである。
空き領域管理キュー更新処理は、図22のステップ350の処理に対応する。
最初に、ステップ361において、管理サーバ14は、新規に割り当てたLU302のLUNを示すエントリを割当対象の共有デバイスユニット34の構成管理テーブル182の空き領域管理キュー204から削除する。次に、ステップ363において、管理サーバ14は、ステップ361でアクセスした空き領域管理キュー204にエントリが存在するか判定する。
この結果、ステップ361でアクセスした空き領域管理キュー204にエントリが存在する場合(ステップ363:Yes)は、管理サーバ14は、空き領域管理キュー更新処理を終了する。
一方、ステップ361でアクセスした空き領域管理キュー204にエントリが存在しない場合(ステップ363:No)は、ステップ365において、管理サーバ14は、共有デバイスユニット管理テーブル78の共有判定情報180の共有デバイスユニット使用可能管理キュー196から、当該共有デバイスユニット34のデバイスユニット番号を示すエントリ(例えば、エントリ199)を削除して、空き領域管理キュー更新処理を終了する。
次に、ホストコンピュータ10からI/O処理要求を受け付けた際に実行されるI/O処理要求処理について説明する。I/O処理要求は、例えば、I/O処理対象のホストLUNの情報などを含むコマンドとして発行される。
図25は、第1実施例に係るI/O処理要求処理のフローチャートである。
最初に、ステップ370において、ホストコンピュータ10は、I/O処理要求元のホストコンピュータ10に格納されているホストコンピュータ割当管理テーブル257にアクセスし、I/O処理要求の対象となるLU(図25の処理の説明において対象LUという)を処理するストレージシステム18に対応するオーナストレージシステム番号を確認する。
次に、ステップ372において、ストレージシステム18は、ステップ370で確認したストレージシステム番号に対応するストレージシステム18のストレージシステムコントローラ28にアクセスし、構成情報268を参照し、対象LUのホストLUNに対応する内部LUN(110b、279b)を確認する。
次に、ステップ373において、ストレージシステム18は構成情報268の対象LUNに対応するオーナビット279gがON、つまり当該ストレージシステム18が処理可能なLUなのか判定する。
結果、ストレージシステム18が処理不可能なLUの場合(ステップ373:No)、当該LUを処理担当するストレージシステム18が変更となっているため、ステップ461において、それに伴うホストコンピュータ10の設定変更の処理を実施する。ステップ461の処理内容の詳細は、図31Bで説明する。
また、ストレージシステム18が処理可能なLUの場合(ステップ373:Yes)や、ステップ461を終了した場合は、次に、ステップ374において、ストレージシステム18は、当該内部LUNに対応する記憶媒体50へアクセスし、当該内部LUNに対応する先頭物理アドレスのデータ領域に対し、I/O処理を実施する。
最後に、ステップ376において、ストレージシステム18は、ステップ370で確認したストレージシステム番号に対応するストレージシステム18のストレージコントローラ28にアクセスし、性能モニタリング情報バッファ領域270へ当該I/O処理のIOPS性能に関する情報を格納し、I/O処理要求処理を終了する。
次に、割当領域の担当ストレージシステムを変更する処理の概要を説明する。
図26は、第1実施例に係る或る時点における性能負荷状況を示す概念図である。図27は、第1実施例に係る担当ストレージシステムを変更した後の割当領域の状況を示す概念図である。
或る時点においては、図26に示すように、割当領域310がストレージシステム#0(ストレージシステム18A)に割り当てられ、LUN#0の管理情報384は、ストレージシステム#0(ストレージシステム18A)に格納されているとする。また、ストレージシステム#0(ストレージシステム18A)が性能負荷大であり、ストレージシステム#1(ストレージシステム18B)が性能負荷小であり、複数のストレージシステム18間で性能負荷のバランシングが取れていない状態とする。ストレージシステム#0は、ケーブル386及びスイッチ38を介して、LUN#0のLU(割当領域310)にアクセスする。
このような状況において、管理サーバ14は、図27に示すように割当領域の担当ストレージシステム18を変更する。すなわち、管理サーバ14は、複数ストレージシステム18間の性能負荷のバランシングを平準化し、共有デバイスユニット34のリソースを効果的に利用するために、LUN#0のLU(割当領域310)のオーナストレージシステム(担当ストレージシステム)を、性能負荷が大きいストレージシステム#0(ストレージシステム18A)から、性能負荷が小さいストレージシステム#1(ストレージシステム18B)へ変更する。具体的な方法としては、管理サーバ14は、ストレージシステム#0(ストレージシステム18A)に格納していたLUN#0の管理情報384を、ストレージシステム#1(ストレージシステム18B)に格納するように、管理情報更新処理392を実行すれば良く、ユーザデータのデバイスレベルでの移動は不要である。
次に、割当領域の担当ストレージシステムを変更することにより性能負荷を分散させる性能負荷分散処理を説明する。
図28は、第1実施例に係る性能負荷分散処理のフローチャートである。
性能負荷分散処理の概要は、図26及び図27で説明した通りである。
最初に、ステップ400において、各ストレージシステム18は、自ストレージシステム18の性能モニタリング情報バッファ領域270に格納している性能負荷に関する情報(性能負荷情報)を管理サーバ14へ送信する。性能負荷情報の送信のタイミングは、例えば、一定時間毎の周期的なタイミングであっても良く、このタイミングは、管理サーバ14からストレージシステム18へ性能負荷情報送信要求コマンドを送信することにより制御しても良いし、ストレージシステム18内のストレージ制御プログラム278が制御しても良い。
次に、ステップ402において、管理サーバ14は、ステップ400で受信した性能負荷情報を、性能モニタリング情報管理テーブル68に反映させて、性能モニタリング情報管理テーブル68を更新する。
次に、ステップ404において、管理サーバ14は、ストレージシステム18間の性能負荷分散判定モードが「ON」か否かを判定する。例えば、性能負荷分散判定モードは、管理サーバ14のアプリケーションプログラム80により設定される。
この結果、性能負荷分散判定モードが「ON」となっていない場合(ステップ404:No)は、管理サーバ14は、性能負荷分散処理を終了する。例えば、管理ユーザが手動でストレージシステム18間の性能負荷を調整したい場合や、LU302を処理するストレージシステム18を固定したい場合などには、このような処理の流れとなる。
一方、性能負荷分散判定モードが「ON」となっている場合(ステップ404:Yes)は、ステップ406において、管理サーバ14は、性能負荷分散判定処理(図29参照)を実施する。
次に、ステップ408において、管理サーバ14は、ステップ406の結果より、ストレージシステム18間で性能負荷分散を実施する必要があるか否かを判定する。
この結果、性能負荷分散を実施する必要がないと判定した場合(ステップ408:No)は、管理サーバ14は、性能負荷分散処理を終了する。
一方、性能負荷分散を実施する必要があると判定した場合(ステップ408:Yes)は、ステップ410において、管理サーバ14は、ストレージシステム18間の性能負荷分散実施処理(図30参照)を実施し、その後、性能負荷分散処理を終了する。
図29は、第1実施例に係る性能負荷分散判定処理のフローチャートである。
性能負荷分散判定処理は、図28のステップ406の処理に対応する。なお、図29では、一例をあげて説明する。
最初に、ステップ420において、管理サーバ14は、性能モニタリング情報管理テーブル68のストレージシステム別性能モニタリング情報230を参照し、最大の性能負荷230bのストレージシステム番号230aと、最小の性能負荷230bのストレージシステム番号230aとを確認する。その際、最小の性能負荷230bであるストレージシステム18のCPU260の使用率が一定値、例えば85%、を超えている場合は、最小の性能負荷のストレージシステム18の対象から外す。このようにする理由は、例えば、性能負荷230bをIOPS性能値とした場合、ストレージシステム18によってシステム限界性能値が異なるため、既にCPU260の使用率が高いストレージシステム18に新たな性能負荷を発生させないためである。同様の理由により、最大の性能負荷230bであるストレージシステム18のCPU260の使用率が一定値、例えば95%、を下回っている場合は、最大の性能負荷のストレージシステム18の対象から外す。
次に、ステップ422において、管理サーバ14は、ステップ420で確認した最大及び最小の性能負荷230bが存在するか否かを判定する。
この結果、最大及び最小の性能負荷230bが存在しない場合(ステップ422:No)は、ステップ426において、管理サーバ14は、性能負荷分散の実施が不要であると判定し、性能負荷分散判定処理を終了する。
一方、最大及び最小の性能負荷230bが存在する場合(ステップ422:Yes)は、ステップ424において、管理サーバ14は、性能負荷分散の実施が必要であると判定する。次に、ステップ428において、管理サーバ14は、性能負荷230bが最大のストレージシステム18を移行元に決定し、性能負荷230bが最小のストレージシステム18を移行先に決定し、性能負荷分散判定処理を終了する。
図30は、第1実施例に係る性能負荷分散実施処理のフローチャートである。
性能負荷分散実施処理は、図28のステップ410の処理に対応する。なお、本実施例では、性能負荷分散実施処理の実行中は、図28のステップ400の処理を実施しないようにしている。
最初に、ステップ430において、管理サーバ14は、アプリケーションプログラム80がストレージシステム18の自動最適配置を実施可能なモード(自動最適配置モード)が「ON」であるか否かを判定する。
この結果、自動最適配置モードが「ON」でない場合(ステップ430:No)は、管理サーバ14は、ストレージシステム18の最適配置を実行しても良いか否かを管理ユーザに問い合わせる。このステップは、管理ユーザの判断で、ストレージシステム18の最適配置を実施するか否かを決定する場合を想定している。
この結果、最適配置を実行してはいけない場合(ステップ440:否)は、管理サーバ14は、性能負荷分散実施処理を終了する。
一方、自動最適配置モードが「ON」である場合(ステップ430:Yes)、又は、最適配置を実行して良い場合(ステップ440:可)は、ステップ432において、管理サーバ14は、移行すべき性能負荷を算出する。
ここで、移行すべき性能負荷の算出方法の一例を説明する。移行先ストレージシステム18のシステム限界性能値90%と、最小の性能負荷230bとの差分を最小差分と定義し、移行元ストレージシステム18のシステム限界性能値90%と、最大の性能負荷230bとの差分を最大差分と定義する。そして、最小差分と最大差分との値を比較し、これらの内のより小さい方の値を移行すべき性能負荷の値とする。このような算出方法の他にも、計算機システムを構成する全ストレージシステム18のシステム性能限界値の平均値を閾値とする方法も考えられる。
次に、ステップ434において、管理サーバ14は、内訳性能モニタリング情報232の移行元ストレージシステム18に関する管理情報240にアクセスし、ステップ432の算出結果を基に、移行対象とするLUに対応する内部LUN240aを決定する。
次に、ステップ438において、管理サーバ14は、移行元から移行先ストレージシステム18へ制御情報を移行する制御情報移行処理(図31参照)を実施する。このステップの処理は、図27に示す管理情報更新処理392に対応する。
最後に、ステップ436において、管理サーバ14は、性能モニタリング情報管理テーブル68を更新する性能モニタリング情報更新処理を実行し、性能負荷分散実施処理を終了する。
図31Aは、第1実施例に係る制御情報移行処理のフローチャートである。
制御情報移行処理は、図30のステップ438の処理に対応する。
最初に、ステップ450において、管理サーバ14は、移行元ストレージシステム18におけるネットワークケーブル22が接続されているFEPK32のポートをイニシエータと設定する。同様に、移行先ストレージシステム18におけるネットワークケーブル24が接続されているFEPK32のポートをターゲットと設定する。図1でも説明した通り、ネットワークケーブル22とネットワークケーブル24とは1本に纏まっていても構わない。
次に、ステップ452において、ストレージシステム18は、移行元ストレージシステム18のキャッシュ領域272に格納されている、移行対象のLU(移行対象LU)に関連するデータに対する処理(移行元キャッシュデータ処理)を実行する。移行元キャッシュデータ処理は、移行元キャッシュディレクトリ・クリーン化処理(図32参照)と、移行先キャッシュディレクトリ・ダーティ化処理(図33参照)とを含む。
次に、ステップ454において、管理サーバ14は、LUN管理テーブル74の共有LUN管理テーブル102に関し、移行対象LUの内部LUN240aに対応するオーナストレージシステム番号94を移行元ストレージシステムのストレージシステム番号から移行先ストレージシステムのストレージシステム番号へ更新する。
次に、ステップ456において、管理サーバ14は、ステップ454の結果を基に、移行元ストレージシステム18及び移行先ストレージシステム18の集約共有デバイスユニット管理テーブル278にアクセスし、移行対象LUの内部LUNに対応するオーナビット279gを更新する。具体的には、管理サーバ14は、移行先ストレージシステム18の集約共有デバイスユニット管理テーブル278のオーナビット279gをOFF(つまり0)に更新し、移行元ストレージシステム18の集約共有デバイスユニット管理テーブル278のオーナビット279gをON(つまり1)に更新する。
次に、ステップ458において、管理サーバ14は、移行先ストレージシステム18からホストコンピュータ10へ至るネットワークケーブル44が接続されているFEPK32のポートと、移行対象LU(例えば、割当領域310)とのマッピングを設定する。このマッピングの設定は、パス交換ソフトウェア等を用いて実現しても良い。
次に、ステップ460において、管理サーバ14及びストレージシステム18の少なくとも一方が、移行対象LUにアクセスしていたホストコンピュータ10へ当該LUを移行したことを通知する。
ストレージシステム18が通知する場合、一例として、以下のような方法がある。ホストコンピュータ10から移行したLUへアクセス処理が発生した場合、ホストコンピュータ10の構成情報70の当該オーナストレージシステム番号94は未更新のため、移行元LUを処理するストレージシステム18にアクセスする。しかし、ストレージシステム18の構成情報268の当該オーナビット289gはOFFとなっているため、移行元LUを処理するストレージシステム18は、ホストコンピュータ10に対しエラー等を通知し、ホストコンピュータ10はLUが移行されたことを認識する。
最後に、ステップ461において、ホストコンピュータ10は、LU移行に伴うホストコンピュータ10の設定の変更処理を実施し、処理は完了する。ステップ461の詳細については、図31Bで説明する。
図31Bは、第1実施例に係るLU移行に伴うホストコンピュータ設定変更処理のフローチャートである。ホストコンピュータ設定処理変更は、図31Aのステップ461に対応する。
まず、ステップ462において、管理サーバ14は、移行元LUのFEPK32のマッピング設定を解除するか否かを判定する。
この結果、FEPK32のマッピング設定を解除する場合(ステップ462:Yes)は、ステップ466において、管理サーバ14は、移行元LU310のFEPK32のマッピング設定を解除する。
次に、ステップ468において、管理サーバ14は、移行元ストレージシステム18の共有デバイスユニットに関する集約共有デバイスユニット管理テーブル278にアクセスし、移行元LUに対応するオーナビット279gをOFF(つまり0)に更新する。
一方、FEPK32のマッピング設定を解除しない場合(ステップ462:No)は、FEPK32に接続されてしまう場合、ホストコンピュータ10は、移行元LUへも移行先LUへもアクセス可能となるため、ステップ464において、管理サーバ14は、移行先LU(図27の割当領域310´)へ優先的にアクセスするように移行元LUをアクセスしていたホストコンピュータ10へ通知するか否かを判定する。優先的にアクセスするとは、ホストコンピュータ10が当該LUにアクセスする際、移行先LUへアクセスするようにし、移行元LUへアクセスしない処理の過程を意味する。
この結果、ホストコンピュータ10へ通知しないと判定した場合(ステップ464:No)は、ステップ472において、ホストコンピュータ10が移行元LU(例えば、割当領域310)へアクセスした際、内部ネットワーク26を経由して、移行先LU(例えば、割当領域310´)へアクセスするよう移行元ストレージシステム18が設定する。設定の一例として、移行元LUの当該集約共有管理テーブル279のオーナビット279gに、移行先ストレージシステム18のID番号等の識別子を記入することで、ホストコンピュータ10は移行元ストレージシステム18を経由し移行先ストレージシステム18へアクセス可能となり、処理を完了する。よって、ホストコンピュータ10側の管理情報を更新せずに、移行先ストレージシステムへアクセスし、移行元ストレージシステムがLUの更新や読み込みを実施することを防止出来る。
一方、ホストコンピュータ10へ通知すると判定した場合(ステップ464:Yes)は、ステップ470において、管理サーバ14は、ホストコンピュータ10へ優先アクセス先を移行先LU(例えば、割当領域310´)とする旨通知する。
ステップ470又はステップ468の処理後、ステップ474において、管理サーバ14は、ホストコンピュータ割当管理テーブル72の移行元LUのアクセス元のホストコンピュータ10に関するホストコンピュータ割当管理テーブル90において、ホストLUNに対応するオーナストレージシステム番号94を、移行先LUを担当するストレージシステムのストレージシステム番号に更新して、制御情報移行処理を終了する。
図32は、第1実施例に係る移行元キャッシュディレクトリ・クリーン化処理のフローチャートである。
移行元キャッシュディレクトリ・クリーン化処理は、図31Aのステップ452の移行元キャッシュデータ処理の一部に対応する。
最初に、ステップ480において、ストレージシステム18は、移行元LUに関連する、移行元ストレージシステム18のキャッシュ領域272に格納しているデータを記憶媒体50へデステージする。なお、ステップ480の処理以降、このデータの移行が完了するまで、移行元LUへのアクセス時に、移行元ストレージシステム18のキャッシュ領域272を使用しない。
次に、ステップ482において、管理サーバ14は、移行元LUに関連する、移行元ストレージシステム18のキャッシュ領域272のディレクトリをクリーン化し、キャッシュ管理テーブル274のダーティフラグ288をダーティデータでないことを示すように更新するとともに、デステージ許可フラグ290を、デステージを許可しないことを示すように更新し、移行元キャッシュディレクトリ・クリーン化処理を終了する。
図33は、第1実施例に係る移行先キャッシュディレクトリ・ダーティ化処理のフローチャートである。
移行先キャッシュディレクトリ・ダーティ化処理は、図31Aのステップ452の移行元キャッシュデータ処理の一部に対応する。
最初に、ステップ490において、管理サーバ14は、移行元LUに関連する、移行元ストレージシステム18のキャッシュ領域272に格納されているデータを、ネットワーク26を介して移行先ストレージシステム18のキャッシュ領域272へコピーする。この際のネットワークケーブルは、図31Aのステップ450における設定によって、イニシエータ及びターゲットに設定されている。なお、ステップ490の処理以降、コピー対象のデータの移行が完了するまで、当該移行元LUへのアクセス時に、移行元ストレージシステム18のキャッシュ領域272を使用しない。
次に、ステップ492において、管理サーバ14は、コピーが完了した移行先ストレージシステム18のキャッシュ領域272のディレクトリをダーティ化するために、キャッシュ管理テーブル274のダーティフラグ288をダーティデータであることを示すように更新するとともに、デステージ許可フラグ290を、デステージを許可することを示すように更新し、移行先キャッシュディレクトリ・ダーティ化処理を終了する。
図34は、第1実施例に係るデバイス割当領域削除処理のフローチャートである。
デバイス割当領域削除処理は、ホストLUNの情報を削除し、ホストコンピュータ10がホストLUNを認識不可の状態にする処理である。ホストLUNに対応するLU302を完全に削除する場合は、デバイス割当領域削除処理の後に、通常通りホストLUNに対応する内部LUNを削除すればよい。
最初に、ステップ500において、管理サーバ14は、ホストコンピュータ割当管理テーブル72において、割当領域削除対象のホストLUN92と、そのホストLUN92に対応するオーナストレージシステム番号94を確認する。
次に、ステップ502において、管理サーバ14は、割当領域削除対象のLUNが複数のストレージシステム18からアクセス可能となっているか否かを確認する。具体的には、管理サーバ14は、共有LUN管理テーブル102Aにおいて,ホストLUN102aとホストLUN92が一致し、かつオーナストレージシステム#102gとオーナストレージ番号94が一致する場合、このホストLUNに対応するオーナストレージシステム番号94が複数のストレージシステム番号となっていないかを確認する。
この結果、割当領域削除対象のホストLUNが複数のストレージシステムからアクセス可能となっていない場合(ステップ502:No)は、ステップ504において、管理サーバ14は、全ストレージシステム18に対し、当該ホストLUN92とFEPK32とのマッピングを削除する。
一方、割当領域削除対象のホストLUNが複数のストレージシステムからアクセス可能となっている場合(ステップ502:Yes)は、ステップ506において、管理サーバ14は、ステップ500で確認したオーナストレージシステム番号94に対応するストレージシステム18における、割当領域削除対象のホストLUN92と、FEPK32とのマッピングを削除する。
ステップ504又はステップ506の処理後、ステップ508において、管理サーバ14は、LUN管理テーブル74の割当領域削除対象のホストLUNの管理情報を削除する。具体的には、管理サーバ14は、専有デバイスユニット管理テーブル110及び共有LUN管理テーブル102における割当領域削除対象のホストLUNに関するエントリを削除する。
次に、ステップ510において、管理サーバ14は、各ストレージシステム18のストレージシステム割当管理テーブル277又は集約共有デバイスユニット管理テーブル278において、割当領域削除対象のホストLUNの管理情報を削除する。
次に、ステップ512において、管理サーバ14は、削除対象の割当領域が共有デバイスユニット34にあるか否かを判定する。
この結果、削除対象の割当領域が共有デバイスユニット34にある場合(ステップ512:Yes)は、管理サーバ14は、共有デバイスユニット管理テーブル78のこの共有デバイスユニット34に関する構成管理情報202において、割当領域削除対象の内部LUNに対応するストレージシステム番号202bをnullに変更する。さらに、管理サーバ14は、空き領域管理キュー204において、割当領域削除対象の内部LUNを示すエントリを追加する。この段階において、FAQ220に対してエントリがない場合には、共有判定情報180の共有デバイスユニット使用可能管理キュー196にこの共有デバイスユニット34の番号を示すエントリを追加する。
一方、削除対象の割当領域が共有デバイスユニット34にない場合(ステップ512:No)、又は、ステップ514の処理後、ステップ516において、管理サーバ14は、ホストコンピュータ割当管理テーブル72中の割当領域削除対象のホストLUNにアクセスするホストコンピュータ10のホストコンピュータ割当管理テーブル90において、割当領域削除対象のホストLUNに関する情報を削除して、デバイス割当領域削除処理を終了する。
次に、第3実施例について説明する。
まず、第3実施例に係る計算機システムの概要について、第1実施例に係る計算機システムとの差異を説明する。第1実施例に係る計算機システムでは、共有デバイスユニット34内の記憶媒体50の種別を特に限定していなかったが、第3実施例に係る計算機システムでは、記憶媒体50をフラッシュドライブ550としている。なお、記憶媒体50をフラッシュドライブ550としても、第1実施例及び第2実施例と同様の構成及び制御を行うことは可能であるが、第3実施例では、フラッシュドライブ550のフラッシュストレージ552を利用することで可能となる第1実施例及び第2実施例と異なる構成制御方法を行う。以下、第3実施例に係る計算機システムの詳細を説明する。
図37は、第3実施例に係るデバイスユニットの構成図である。なお、図2に示す第1実施例に係るデバイスユニットと同様な構成には、同一の符号を付すこととする。
共有デバイスユニット34は、スイッチ38と、複数のフラッシュドライブ550を含むデバイス40とを有する。フラッシュドライブ550と、スイッチ38とは、ケーブルによって接続されている。フラッシュドライブ550は、フラッシュストレージ552を含む。
図38Aは、第3実施例に係るフラッシュストレージの構成図である。
フラッシュストレージ552は、FEIF(Front End IF)570、CPU578、メモリ560、BEIF(Back End IF)574、1以上のフラッシュメモリ(FM)チップ576、及びデータ転送制御部572を含む。FEIF(Front End IF)570、CPU578、メモリ560、及びBEIF(Back End IF)574は、データ転送制御部572を介して接続されている。
FEIF570は、ケーブルを介してスイッチ38に接続される。CPU578は、複数のマイクロプログラム(MP)580を格納し、I/O処理等を並列に実施することができる。
メモリ560は、構成情報562、性能モニタリング情報管理テーブル68、I/O優先・非優先キュー564、フラッシュストレージ制御プログラム566、キャッシング領域568、及び性能モニタリング情報バッファ領域582を格納する。I/O優先・非優先キュー564については、図39で詳細を説明する。構成情報562は、LUN管理テーブル74、共有デバイスユニット管理テーブル78、及び論理物理変換情報584を格納する。論理物理変換情報584は、フラッシュストレージ552内でユニークな論理アドレスと、FMチップ576の物理層の対応関係を管理する。論理物理変換情報584の詳細については、後述する。フラッシュストレージ制御プログラム566は、フラッシュストレージを制御する各種処理を実行するためのプログラムである。キャッシング領域568は、データのキャッシングに利用するための領域である。性能モニタリング情報バッファ領域582は、性能モニタリング情報を一時的に格納するためのバッファ領域である。BEIF574は、FMチップ576を接続するためのインタフェースであり、複数のFMチップ576が接続されている。FMチップ576は、ユーザデータ等を格納する。
図38Bは、第3実施例に係る論理物理変換情報の構成図である。
フラッシュドライブ500では、データはブロック単位で制御され、また、データはブロックをより小さい単位に分割したページ単位で管理されている。論理物理変換情報584は、ブロックの論理アドレス(ブロック論理アドレス)の情報を管理するテーブルである。論理物理変換情報584は、ブロック内ページ毎に、ブロック番号(#)2068、FMチップ番号(#)2070、FMチップブロック番号(#)2071、ページ番号(#)2072,及びオフセットアドレス2074を格納する。
ブロック論理アドレス2068は、ストレージシステム内でデータにブロック単位でアクセスする際の論理アドレスである。FMチップ番号2070は、ブロック論理アドレス2068が格納されているFMチップ576の番号である。FMチップブロック番号2072は、FMチップ576内を一定のブロックサイズで区切った場合の1つブロックに付随している番号であり、ブロック論理アドレス2068に該当する番号が格納してある。ページ番号1072は、FMチップ576のブロックをさらに小さい単位で分割したものである。オフセットアドレス2074は、各ページに割り当てられている物理アドレスのオフセットアドレスである。ストレージシステムへ未割当のページに対応するオフセットアドレス2074には、「null」が設定される。
図39は、第3実施例に係るI/O優先・非優先キューの構成図である。
I/O優先・非優先キュー564は、I/O処理の優先度を管理するためのキューである。例えば、ホストコンピュータ10からのRead要求等のI/O処理は、ホストレスポンスを良くするため、早めに処理をしたい(=処理の優先度が高い)。一方、バックグラウンドでデータコピーを実施するアプリケーション処理等に関わるI/O処理は、多少処理が遅れても構わない(=処理の優先度が低い)。さらに、ホストコンピュータ10からWrite要求を受けた場合、ホストレスポンスを良くするため、ストレージシステムのメモリにWriteデータを格納しホストコンピュータ10へWrite処理完了通知を出した後、非同期にWriteデータをデバイスに書き込む。Writeデータをデバイスに書き込む処理負荷は高いが、さらに、非同期のWriteデータ書き込み処理の効率を良くするため、ある程度Writeデータを溜めた上でデバイスに書き込む場合(まとめ書きと呼ぶ)もあり、この場合1回の処理負荷は高い。通常は、I/O優先・非優先キュー564は各ストレージコントローラ28で管理しているが、本実施例のように1つの共有デバイスユニット34に複数のストレージシステム18が接続されている場合、あるストレージシステム18がまとめ書きの指示を出したが、別のストレージシステム18がホストコンピュータ10からのRead処理等優先度の高い処理の指示を出した場合、デバイスユニットでは処理の優先度を判断することが出来ず、まとめ書きの処理を先に実行し、Read処理のホストレスポンスが悪化する恐れがある。そこで、本実施例では、フラッシュストレージ552に基づいたI/O優先・非優先キュー564により、I/O処理の順番を優先度毎に管理することで、効率的にI/O処理を実施するようにしている。I/O優先・非優先キュー564の管理単位は、フラッシュストレージ552毎でも良いし、FMチップ毎でも良いし、CPU毎でも良いし、MP毎でも良い。図39では、一例としてフラッシュストレージ552内のMP毎に、I/O優先・非優先キュー564を管理する場合を説明する。
I/O優先・非優先キュー564は、CPU578のMP580毎にそれぞれ個別I/O優先・非優先キュー590(590A、590B等)が割り当てられる。例えば、MP#0(MP580A)には、個別I/O優先・非優先キュー590Aが割り当てられ、MP#1(MP580B)には、個別I/O優先・非優先キュー590Bが割り当てられる。
個別I/O優先・非優先キュー590は、優先キュー(PRQ)592と、非優先キュー(NPRQ)596とを格納する。優先キュー592には、優先度が高いI/O処理を示すエントリが管理され、非優先キュー596には、優先度が低いI/O処理を示すエントリが管理される。図39に示す例では、優先キュー592には、優先度が高いI/O番号0を示すエントリ594Aと、I/O番号4を示すエントリ594Bとが接続されている。また、非優先キュー596には、優先度が低いI/O番号1のエントリ598Aと、I/O番号2のエントリ598Bと、I/O番号3のエントリ598Cとが接続されている。各I/O処理の優先度は、例えば、各ストレージシステム18のストレージ制御プログラム276が付与する。I/O優先・非優先キュー564を用いた具体的な処理については、図43を用いて後述する。
図40は、第3実施例に係るストレージコントローラの構成図である。なお、図17に示す第1実施例に係るストレージコントローラと同様な部分には、同一符号を付している。
第3実施例に係るストレージコントローラ28は、構成情報268として、ストレージシステム割当管理テーブル100’(100A‘)のみを格納する。
図41は、第3実施例に係るストレージシステム割当管理情報の構成図である。
ストレージシステム割当管理情報100’は、図7に示す第1実施例に係るストレージシステム割当管理情報100とほぼ同じ構成であるが、専有デバイスユニット管理テーブル110のみ格納されているのではなく、共有デバイスユニット34のうち、当該ストレージシステム18に割り当てられているホストLUN92の管理情報も含む。また、ストレージシステム割当管理情報100’は、ストレージシステム割当管理情報100の先頭物理アドレス110fに代えて、先頭フラッシュドライブ論理アドレス110hを格納する。
ホストLUN110aは、専有デバイスユニット36から割当てられているLUに対応するホストLUNだけでなく、共有デバイスユニット34から割当てられているLUに対応するホストLUNである場合がある。例えば、図41に示すストレージシステム割当管理情報100’を参照すると、ホストLUN110a「2」に対応するLUは、デバイスユニット番号110g「0」のデバイスユニット、すなわち、共有デバイスユニット34から割当てられていることがわかる。ここで、共有デバイスユニット34がフラッシュドライブ550で構成されている場合は、フラッシュドライブ550にフラッシュストレージ552が搭載されているため、ストレージシステム18へ割り当てられている領域のみを見せることが可能となる。よって、第1実施例の図18に示すような共有デバイスユニット管理テーブル278により、全ストレージシステム18に割り当てられた全領域の管理情報をストレージシステム18毎に格納しなくてよい。
先頭フラッシュドライブ論理アドレス110hは、内部LUN110bに対応するLUのフラッシュドライブ550における先頭の論理アドレスである。先頭フラッシュドライブ論理アドレス110hを、ブロック内ページサイズで割ることにより、LUについてのブロック内ページ番号を算出することができる。
次に、第3実施例に係る計算機システムの処理について説明する。なお、第1実施例に係る計算機システムの処理との差異を中心に説明する。
図42は、第3実施例に係る共有デバイスユニット新規登録処理のフローチャートである。なお、図21に示す第1実施例に係る共有デバイスユニット新規登録処理と同様な部分には、同一符号を付し、詳細な説明は省略する。
最初に、ステップ320において、管理サーバ14が、共有判定管理テーブル180へ新規登録の共有デバイスユニット34を登録する。
次に、ステップ1000において、フラッシュストレージ552(例えば、共有デバイスユニット34内の複数のフラッシュストレージ552のうち或るストレージコントローラから所定の指示を受けた1以上のフラッシュストレージ552の各々)が、当該共有デバイスユニット34内の複数のフラッシュドライブ550から、パリティグループ300を作成し、さらにパリティグループ300に基づいてLU302を作成する。その際、フラッシュストレージ552は、内部LUNとホストLUNとの設定も実施する。作成するパリティグループ300やLU302の構成に関しては、予めデフォルト値を管理サーバ14に設定していても良いし、ステップ322において、管理サーバ14がフラッシュストレージ552へ構成を指示しても良い。LU302の作成後、フラッシュストレージ552は、LUN管理テーブル74の共有LUN管理テーブル102を作成し、新規作成したLU302の管理情報を登録する。
その後、第1実施例の図21と同様にステップ326へ処理を進め、ステップ326でYesの場合は、ステップ328の処理を実行する。次に、ステップ1002において、フラッシュストレージ552が、各ストレージシステム18のストレージシステム割当管理テーブル100’へ、当該ストレージシステム18に割り当てられた新規LU302の登録情報のみを反映する。
一方、ステップ326でNoの場合、又はステップ1002の処理後、フラッシュストレージ552は、ステップ332へ処理を進め、後続の処理を実行し、共有デバイスユニット新規登録処理を終了する。
図43は、第3実施例に係るI/O処理要求処理のフローチャートである。なお、図25に示す第1実施例に係るI/O処理要求処理と同様な部分には、同一符号を付し、詳細な説明は省略する。
最初に、ステップ370において、ホストコンピュータ10は、I/O処理要求元のホストコンピュータ10に格納されているホストコンピュータ割当管理テーブル257にアクセスし、I/O処理要求の対象となるLUに対応するホストLUNと、当該LUを処理するストレージシステム18に対応するオーナストレージシステム番号とを確認する。
次に、ステップ372において、ストレージシステム18は、ステップ370で確認したストレージシステム番号に対応するストレージシステム18のストレージコントローラ28にアクセスし、構成情報268を参照し、対象LUのホストLUNに対応する内部LUN(110b)を確認する。
次に、ステップ373において、ストレージシステム18は構成情報268の対象LUNに対応するオーナビット279gがON、つまり当該ストレージシステム18が処理可能なLUなのか判定する。
結果、ストレージシステム18が処理不可能なLUの場合(ステップ373:No)、当該LUを処理担当するストレージシステム18が変更となっているため、ステップ461において、それに伴うホストコンピュータ10の設定変更の処理を実施する。
最後に、ストレージシステム18が処理可能なLUの場合(ステップ373:Yes)や、ステップ461終了した場合は、ステップ1020において、ストレージコントローラ28は、データI/O処理(図44参照)を実施し、I/O処理要求処理を終了する。
図44は、第3実施例に係るデータI/O処理のフローチャートである。
データI/O処理は、図43のステップ1020の処理に対応する。
最初に、ステップ1030において、ストレージシステム18のストレージコントローラ28が、I/O種別に応じて、I/O処理の優先・非優先を判断し、I/O処理命令に優先又は非優先のタグ付けをする。このI/O処理命令は、I/O対象のフラッシュドライブ550に送信される。
次に、ステップ1032において、ストレージシステム18からフラッシュドライブ550へI/O処理命令が到達した時、フラッシュドライブ550のフラッシュストレージ552が、当該I/O処理命令に優先タグが付いているか否かを判定する。
この結果、I/O処理命令に優先タグが付いている場合(ステップ1032:Yes)は、ステップ1034において、フラッシュストレージ552は、処理を実行するMP580に対応する優先キュー592へ、当該I/O処理命令の番号を示すエントリを追加する。
一方、I/O処理命令に優先タグが付いていない場合(ステップ1032:No)は、ステップ1036において、フラッシュストレージ552は、処理を実行するMP580に対応する非優先キュー596へ、当該I/O処理命令の番号を示すエントリを追加する。
ステップ1034、又はステップ1036の終了後、ステップ1038において、フラッシュストレージ552は、フラッシュストレージ552内の性能モニタリング情報バッファ領域582へ、I/O処理命令の処理対象となるLUの性能負荷に関する情報を格納する。
最後にステップ1040において、フラッシュストレージ552は、FMチップ576へのリード又はライト等のI/O処理を実行し、データI/O処理を終了する。
図45は、第3実施例に係る性能負荷分散処理のフローチャートである。なお、図28に示す第1実施例に係る性能負荷分散処理と同様な部分には、同一符号を付し、詳細な説明は省略する。
最初に、ステップ1050において、各ストレージシステム18は、一定時間毎に、性能負荷の全情報を管理している性能モニタリング管理テーブル68へ、各フラッシュストレージ552の性能モニタリング情報バッファ領域582に格納されている性能負荷の情報を送信する。
ステップ402以降の処理は、図28に示す第1実施例に係る性能負荷分散処理と同じである。
次に、第4実施例について説明する。
まず、第4実施例に係る計算機システムの概要を説明する。第4実施例では、計算機システムが、シン・プロビジョニング機能及びストレージ階層仮想化機能を利用することを想定する。
プール1062は、例えば、共有デバイスユニット34や専有デバイスユニット36の記憶領域を混在して構成される。プール1062は、Tier1060(1060A、1060B、1060C)と呼ばれる複数の階層で管理される。ここで、Tierとは、LUに割り当てる領域を、その領域を提供する記憶媒体50の特性に基づいて分けた階層である。本実施例では、Tier1(Tier1060A)は、高速な記憶媒体で構成された領域の階層を示し、Tier3(1060C)は、低速な記憶媒体で構成された領域の階層を示す。ストレージ階層仮想化機能では、プール1062がページ304というデータ単位で分割されて管理され、ホストコンピュータ10に対しては、仮想LU302’として領域を見せることで、データが実際に格納されている領域のみにプール1062のページ304を割当てることにより、使用されている領域の容量削減を実現する。ストレージ階層仮想化機能では、ページのアクセス頻度に応じて、Tier間でページ移動(具体的には、ページに格納されているデータの移動)を実施することで、最適なページ配置とし、I/O処理の性能向上へつながる。ページに対するアクセス頻度は、例えば、管理サーバ14で一括管理する。
デバイスユニット34、36の領域の割当単位は、ページ304又はページ304の集合であるチャンク306となるが、本実施例では、性能負荷分散処理のストレージシステム間での移動単位はLU302とする。性能モニタリング情報等は、例えば、共有デバイスユニット34にフラッシュドライブ550を備えている場合には、フラッシュドライブ550のフラッシュストレージ552に保管しても良い。また、共有デバイスユニット34に、フラッシュドライブ550以外のSSD、SASディスク、又はSATAディスクを備えている場合は、性能モニタリング情報は管理サーバ14で保管しても良い。
以下、第4実施例に係る計算機システムの詳細を説明する。
図46は、第4実施例に係るデバイス割当の概要を示す図である。
プール1062は、各デバイスユニット34、36のパリティグループ300から構成され、複数のTier1060で管理されている。図46においては、共有デバイスユニット34のパリティグループ300がTier1に該当している例を示しているが、これに限られず、パリティグループ300がどのTierなのかは、パリティグループ300を構成するデバイスユニットのデバイスの種別によって決定される。また、図46においては、Tierを3階層としているが、Tierの階層数はこれに限られず、任意の階層数としても良い。
図47は、第4実施例に係る管理サーバの構成図である。なお、図4に示す第1実施例に係る管理サーバと同様な部分には、同一符号を付すこととする。
第4実施例に係る管理サーバ14は、第1実施例に係る管理サーバ14に対して、仮想論理変換テーブル1076、及びパリティグループモニタテーブル1080を構成情報70にさらに格納するとともに、ページ毎のI/O回数をモニタリングした情報を管理する細粒度モニタテーブル1061と、ページの再配置を実施するための再配置プログラム1063とを更に格納する。
図48は、第4実施例に係るLUN管理テーブルの構成図である。なお、図6に示す第1実施例に係るLUN管理テーブルと同様な部分には、同一符号を付すこととする。
第4実施例に係るLUN管理テーブル74’は、ホストLUN102a、内部LUN102b、サイズ102c、及びオーナストレージシステム番号102gを管理し、第1実施例に係るLUN管理テーブル74の共有LUN管理テーブル102で管理していたパリティグループ番号102d、RAIDレベル102e、及び先頭物理アドレス102fについては、別で管理するため、管理していない。第4実施例に係るLUN管理テーブル74’は、共有デバイスユニット34と、専有デバイスユニット36とのいずれのLUに対応するLUNであっても区別なく管理する。
図49は、第4実施例に係る仮想論理変換テーブルの構成図である。
仮想論理変換テーブル1076は、ページ番号(#)1076a、内部LUN1076b、仮想アドレス1076c、プール番号(#)1076d、パリティグループ番号(#)1076e、及び物理アドレス1076fを管理する。ページ番号1076aは、ページを識別する番号である。内部LUN1076bは、ページ番号1076aに対応するページが属する内部LUNの識別番号である。仮想アドレス1076cは、ホストコンピュータから認識されるページに対応する仮想アドレスである。プール番号1076dは、ページが提供されるプールの識別番号である。パリティグループ番号1076eは、ページが属するパリティグループの番号である。物理アドレス1076fは、ページのデータが格納されるデバイスにおける物理的なデータ格納場所を示す物理アドレスである。なお、データが格納されるデバイスがフラッシュドライブ550である場合には、物理アドレス1076fには、フラッシュドライブ550における論理アドレスが格納される。
図50は、第4実施例に係る細粒度モニタテーブルの構成図である。
細粒度モニタテーブル1061は、ページ再配置を判定するために使用されるモニタ情報を管理するテーブルである。細粒度モニタテーブル1061は、ページ番号(#)1061a、内部LUN1061b、仮想アドレス1061c、及びI/O回数1061dを管理する。ページ番号1061aは、ページを識別する番号である。内部LUN1061bは、ページ番号1061aに対応するページが属する内部LUNの識別番号である。仮想アドレス1061cは、ホストコンピュータから認識されるページに対応する仮想アドレスである。I/O回数1061dは、ページに対して発行されたI/O処理要求の回数である。
図51は、第4実施例に係るストレージコントローラの構成図である。なお、図17に示す第1実施例に係るストレージコントローラと同様な部分には、同一符号を付すこととする。
第4実施例に係るストレージコントローラ28は、第1実施例に係るストレージコントローラ28に対して、仮想論理変換テーブル1076、LUN管理テーブル1086、及びパリティグループモニタテーブル1080が構成情報268に追加されている。また、第4実施例に係るストレージコントローラ28は、第1実施例に係るストレージコントローラ28におけるストレージ制御プログラム274に代えて、ストレージ制御プログラム1082を格納するとともに、マッピング変更情報バッファ領域1084を更に格納する。
ストレージコントローラ28は、仮想論理変換テーブル1076の内容が変更された時の変更情報を、他のストレージシステム18の仮想論理変換テーブル1076にもアップデートする処理を行う。ここで、内容が変更された度に、アップデータの処理を行うこととなると負荷が高くなってしまう、基本的には、ストレージコントローラ28自身が使用する管理情報に誤りがなければ良いので、ストレージコントローラ28は、マッピング変更情報バッファ領域1084に、変更内容をバッファリングしておき、一定時間毎に管理サーバ14及び各ストレージシステム18へ変更内容を通知する。なお、新規ページ割当時は、別途用意した空きページ割当てるように管理しているため、既に別のストレージシステム18で確保済みの領域を誤って確保する恐れはなく、このように変更内容を通知するようにしても問題がない。空きページの管理については、図55を用いて後述する。
図52は、第4実施例に係るLUN管理テーブルの構成図である。
LUN管理テーブル1086は、ストレージシステム18毎に、どのLUの処理が自身に割当られているかを管理するテーブルである。LUN管理テーブル1086は、ホストLUN1086a、内部LUN1086b、及びサイズ1086cを管理する。ホストLUN1086aは、ホストコンピュータ10から認識されるLUの識別番号である。内部LUN1086bは、ストレージシステム18で認識されるLUの識別番号である。サイズ1086cは、ホストLUN1086cに対応するLUのサイズである。
図53は、第4実施例に係るパリティグループモニタテーブルの構成図である。
パリティグループモニタテーブル1080は、パリティグループがどのTierとして認識されているかを管理するテーブルである。パリティグループモニタテーブル1080は、パリティグループ番号1080a、Tier1080b、及びプール番号1080cを管理する。パリティグループ番号1080aは、パリティグループの番号である。Tier1080bは、Tierの階層を示す情報である。プール番号1080cは、パリティグループが属するプールの識別番号である。
図54は、第4実施例に係る構成管理情報の構成図である。
構成情報202’は、Tier毎の割当てを管理する各Tier構成管理情報1090(1090A、1090B等)を含む。各Tier構成管理情報1090は、パリティグループ番号(#)1090aと、ページ番号(#)1090bとを管理する。パリティグループ番号1090aは、パリティグループの番号である。ページ番号1090bは、パリティグループのページの番号である。
図55は、第4実施例に係る空き領域管理キューの構成図である。
空き領域管理キュー204は、図13に示す第1実施例に係る空き領域管理キュー204と同等であるが、Tier毎に空き領域を管理する各Tier空き領域管理キュー1092(1092A、1092B等)を備え、空き領域を管理するエントリの単位をページ単位としている。図55に示す例では、Tier1の各Tier空き領域管理キュー1092Aの先頭220’には、ページ「5」を示すエントリ222’が接続され、その次に、ページ「6」を示すエントリ224’が接続され、更に、ページ「7」を示すエントリ226’が接続されている。この各Tier空き領域管理キュー1092Aによると、ページ「5」、「6」及び「7」が空き領域であることがわかる。
図56は、第4実施例に係るPool設定処理のフローチャートである。
最初に、ステップ2000において、管理サーバ14は、Poolに加えるパリティグループの選択を受け付ける。次に、ステップ2002において、管理サーバ14は、追加するパリティグループの情報を基に、Tier毎に割当てる容量を算出する。
最後に、ステップ2004において、管理サーバ14は、各Tier容量をPoolにアクセス可能なストレージシステム18の数で割り、各Tierの容量基準を設定する。ストレージ階層仮想化機能では、ページ再配置実施を判定する契機として、Tierのデータ格納可能容量が上限を超える場合、又は、Tierがサポート可能な性能値の上限を超える場合が考えられる。容量基準とは、前者に当たり、データ格納可能容量の上限を定める基準である。
なお、新規割当に関しては、一般的なシン・プロビジョニング機能と同様に、必要に応じてページを割り当てる。ページに関しては、Poolの定義をしておけば従来と同様な方法で割当可能である。
図57は、第4実施例に係る性能基準設定処理のフローチャートである。
性能基準設定処理は、Tierがサポート可能な性能値を決定する処理である。
最初に、ステップ2010において、管理サーバ14は、Tier毎の性能モニタリング情報を集計する。この性能モニタリング情報は、性能モニタリング情報管理テーブル68の情報を利用する。
次に、ステップ2012において、管理サーバ14は、Tier毎の限界性能を算出する。限界性能は、ステップ2010で集計した値と、CPUの使用率等から算出できる。限界性能の算出方法は、例えば、国際公開第2011/001775号に開示されている。
最後に、ステップ2014において、管理サーバ14は、各Tierの性能基準を設定し、性能基準設定処理を終了する。
図58は、第4実施例に係る性能負荷分散実施処理のフローチャートである。なお、図30に示す第1実施例に係る性能負荷分散実施処理と同様な部分には、同一符号を付すこととする。
第4実施例に係る性能負荷分散実施処理においては、第1実施例に係る性能負荷分散実施処理のステップ438に代えて、ステップ2020に示すLU移行処理(図59参照)を実行する。
図59は、第4実施例に係るLU移行処理のフローチャートである。
LU移行処理は、図58のステップ2020に対応する処理である。
最初に、ステップ2030において、管理サーバ14は、移行元LUに割り当てられたページで、専有デバイスユニット36に格納されているものがあるか否かを判定する。
この結果、移行元LUに割り当てられたページで、専有デバイスユニット36に格納されているものがある場合(ステップ2030:Yes)は、ステップ2032において、管理サーバ14は、当該ページのデータをストレージシステム間でコピーするコピー処理(図60参照)を実行する。
一方、移行元LUに割り当てられたページで、専有デバイスユニット36に格納されているものがない場合(ステップ2030:No)、又はステップ2032の終了後、ステップ2034において、管理サーバ14は、移行元LUに割り当てられたページで共有デバイスユニット34に格納されているものがあるか否かを判定する。
この結果、移行元LUに割り当てられたページで共有デバイスユニット34に格納されているものがない場合(ステップ2034:No)は、ステップ2038において、移行先ストレージシステムのLUN管理テーブルを更新し、ステップ2036において、ホストパスの設定を行うホストパス設定処理(図61参照)を実行し、LU移行処理を終了する。
一方、移行元LUに割り当てられたページで共有デバイスユニット34に格納されているものがある場合(ステップ2034:Yes)は、ステップ438において、移行元から移行先ストレージシステムへの制御情報移行処理を実施し、LU移行処理を終了する。ステップ438における制御情報移行処理は、基本的には、図31に示した通りであるが、移行先ストレージシステムのLUN管理テーブルには、移行元LUNは存在しない。よって、移行先ストレージシステムのLUN管理テーブルにおいて、当該LUNの管理情報を追加する必要がある。
図60は、第4実施例に係るコピー処理のフローチャートである。
コピー処理は、図59のステップ2032に対応する処理である。
最初に、ステップ452において、管理サーバ14は、移行元キャッシュデータ処理を実施する。移行元キャッシュデータ処理は、第1実施例に係る図31のステップ452と同様な処理であり、具体的には、移行元キャッシュデータ処理は、移行元キャッシュディレクトリ・クリーン化処理(図32参照)と、移行先キャッシュディレクトリ・ダーティ化処理(図33参照)とを含む。
次に、ステップ2052において、管理サーバ14は、当該ページのデータ移行先は共有デバイスユニット34であるか否かを判定する。
この結果、当該ページのデータ移行先が共有デバイスユニット34である場合(ステップ2052:Yes)は、ステップ2058において、管理サーバ14は、ストレージコントローラ28のBEPK30経由でデータをコピーする。
一方、当該ページのデータ移行先が共有デバイスユニット34でない場合(ステップ2052:No)は、ステップ2054において、管理サーバ14は、FEPK32のイニシエータポートとターゲットポートとの設定をする。次に、ステップ2056において、管理サーバ14は、FEPK32からネットワーク26経由でデータをコピーする。
最後に、ステップ2058の終了後、又はステップ2056の終了後、ステップ2040において、管理サーバ14は、ページ移動が発生したため、ページ移動に応じた内容に仮想論理変換テーブル1076を更新し、コピー処理を終了する。
図61は、第4実施例に係るホストパス設定処理のフローチャートである。
ホストパス設定処理は、図31に示す第1実施例に係る制御情報移行処理のステップ462以降と同様な処理である。
以上、幾つかの実施例を説明したが、これらは、本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。すなわち、本発明は、他の種々の形態でも実施する事が可能である。例えば、各ストレージシステム18が、共有デバイスユニット34のスイッチ38に接続されるスイッチ38を有していても良い。これにより、コネクティビティの向上が期待できる。