JP4723925B2 - ボリューム活動に従ってストレージポリシーをコントロールするための方法 - Google Patents

Description

本発明は、一般的にはデータストレージシステムに関連し、詳しくはデータストレージシステム内でのデータ移行に関連する。

ストレージ管理システムに基づく現行のポリシーは、ユーザ（例：管理者）がデータ移行時点と移行対象の基準を指定したとしても、予測不能なデータ移行結果を招く可能性がある。この理由は、新装置の追加による新構成のような確かな現情報がユーザに不足することがあるからである。

現在の通常のデータ管理ソフトウェアは、データの使用特性とエンタープライズに対する情報価値に基づいてデータを管理して、データ移行実施の可否を決定する。このソフトウェアは、ユーザが定義したポリシーを長期間に亘って正しいという前提の下で、データを自動的に管理するが、管理者はシステム全体を知らずシステムの問題を発見できない為に、ポリシーは本来の状態とは乖離してしまうのである。ポリシーとは結果が改善されることを示すものである。ユーザ（例：管理者）はシステムの全体像を所有しておらず、ポリシーを変更させるシステムでの問題点に気づかない為に、ポリシーは時とともに現実に沿わなくなってしまう。この結果、データ移行の結果は適正なものとして誤って見られてしまう。

本発明においては、ストレージ仮想システムにおいて、複数のストレージデバイスと、前記ストレージデバイスで定義される一台以上の物理論理ユニットから成る複数の仮想論理ユニットを定義する仮想化コンポーネントと、各前記仮想論理ユニットに関連する入出力活動情報を前記物理ストレージデバイスから収集し、収集した前記入出力活動情報に基づいて、前記仮想論理ユニットごとの単位時間当たりのアクセス率を表す活動指数をそれぞれ算出するポリシーマネージャと、を備え、前記仮想論理ユニットは、所定の性能基準に従って複数の論理ユニットクラスにクラス分けされ、前記ポリマネージャには、前記仮想論理ユニットの活動指数に応じて推薦すべき、当該仮想論理ユニットに格納されたデータの移行先の前記仮想論理ユニットが属する前記論理ユニットクラスを予め規定した第一のポリシーが与えられ、前記ポリシーマネージャは、前記第一のポリシーに基づいて、一の仮想論理ユニットから他の仮想論理ユニットへのデータ移行を実行し、前記ポリシーマネージャは更に、前記入出力活動情報に基づいて、ユーザに推薦する新たな第一のポリシーでなる推薦ポリシーを生成する第一のステップと、前記推薦ポリシーをユーザに提示する第二のステップと、前記第一のポリシーを、前記推薦ポリシーか又は該推薦ポリシーとは異なるポリシーを表すユーザ選択情報のいずれかから決定される第二のポリシーで置き換える第三のステップとを有する処理を実行する、ことを特徴とする。

本発明の態様、便益と新規な機能は、以降の添付図面と共になされる本発明の説明によって、明確になる。

図２は、本発明の一実施例に基づく、ハードウェアコンポーネントとこれらコンポーネントの結合を示す。システム１は、好適な通信ネットワーク８によるデータ通信を行う、複数のホスト２（ホストａ、ホストｂ、ホストｃ）より成る。図示される本発明の具体的実施例では、ネットワーク８はＳＡＮ（Storage Area Network）である。各ホスト２は、ＣＰＵ（Central Processing Unit）、メモリ、ＦＣ（Fibre Channel）、ＨＢＡ（Host Bus Adapter）、及びディスクストレージより成る。各ホストは、Windows（登録商標）、Solaris、及びAIX等のＯＳ（Operating System）上で稼動する。

ネットワーク８はストレージ仮想化システム５とデータ通信する。第二の通信ネットワーク９は、ストレージ仮想化システム５を複数のストレージコンポーネント６に接続する。第二の通信ネットワーク９もＳＡＮである。

管理サーバシステム３は、通信ネットワーク１０を介してストレージ仮想化システム５に結合する。図２に示すように、ＬＡＮ（Local Area Network）は通信ネットワーク１０に好適な代表的なネットワークである。管理サーバシステム３はＣＰＵ、メモリ、及びディスクベースのストレージで成る。管理サーバシステム３は、Windows（登録商標）、Solaris、及びAIX等のＯＳ上で稼動する。以下で説明するように、管理サーバシステム３は本発明に従って稼動する。

システム管理者に代表されるユーザは、ＰＣ（Personal Computer）等の適切に構成されたコンソール４を使用して、通信ネットワーク１０に接続される。管理サーバシステム３とコンソール４は、ＴＣＰ／ＩＰベースのイーサネット（登録商標）、トークンリング、ＦＤＤＩ（Fibre Distributed Data Interface）等のプロトコルを使用して互いに通信する。

ストレージ仮想化システム５の例は、シスコシステム社により製造販売されているMDS9000シリーズの多層スイッチである。ストレージ仮想化システムのもう一つの例は、FalconStor Softwareにより製造販売されている、IPStor（R）エンタープライズ版ソフトウェアに基づく、エンタープライズＰＣサーバシステムである。

図２で分るように、ストレージ仮想化システム５を構成するハードウェアは、各々、ＦＣ（Fibre Channel）ポートを持つ複数の入出力プロセッサより成る。ＦＣポートは、ホスト２とストレージコンポーネント６に結合される。ＦＣポートは、ＦＣファブリック内で各要素に固有な識別子をアサインする為に、ＦＣ仕様で慣用的に使用されるＷＷＮ（World Wide Name）で識別される。

ストレージ仮想化システム５は更に、仮想化システムを管理する為に、一式以上の管理プロセッサを持つ。内部バスがストレージ仮想化システム５の内部コンポーネントを結合する。管理プロセッサは、ホスト２に複数の仮想ＬＵ（論理ユニット）のビューを提供するのに必要な処理を実行する。各仮想ボリュームは、ストレージコンポーネント６のストレージサブシステム７で提供される一台以上のＬＵの部分より成る。ストレージコンポーネント６との通信は、ＳＣＳＩ（Small Computer System Interface）−２かＳＣＳＩ−３のコマンドセットに基づいて行われる。

図３によると、仮想ＬＵ５９は５ＧＢの容量を持っている。仮想ＬＵ５９は、２台以上の物理デバイス７（図２）により提供されるＬＵより成る。第一の物理デバイスは容量２ＧＢの第一のＬＵ５３を提供する。第二の物理デバイスは容量３ＧＢのもう一つのＬＵ５６を提供する。ストレージ仮想化システム５の管理プロセッサは、ストレージコンポーネント６で提供される個別のＬＵを管理し、ホスト２に複数の仮想ＬＵを定義する。本件については後に更に詳しく説明する。

各ストレージコンポーネント６は、複数のストレージサブシステム７と入出力コントローラより成る。入出力コントローラは、ＲＡＩＤ（Redundant Array of Inexpensive Disks）構成等のストレージを用いるストレージコンポーネント６のストレージデバイスの間にＬＵを定義する。

ストレージコンポーネント６の各入出力コントローラは、コントロールプロセッサ、メモリ、及びイーサネット（登録商標）ボード又はＦＣポート等のＮＩＣ（ネットワークインターフェースカード）を備える。図示した構成では、ＮＩＣはＳＡＮ９に接続する為のＦＣポートである。コントロールプロセッサは、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）を持つ。コントロールプロセッサは、データをＮＶＲＡＭに保持して、例えば電源障害に備える。

図２Ａは図２に代わる構成図である。ここでは、ストレージコンポーネント６はストレージ仮想化システム５に直接接続されている。図２、２Ａ及び以下に展開される説明から、その他のストレージ構成が可能であることを理解願いたい。

図４は、図２で示すハードウェアシステムに対して、ソフトウェアコンポーネントとそれらの接続関係を示す図である。図４に於いて、実線は現在のデータアクセスの方向を示し、破線はソース仮想ＬＵから対象仮想ＬＵへのデータ移行中のデータの方向を示す。

各ホスト２は、生成され、アクセスされ或いは、ユーザアプリケーション（Ａｐｐ、例えば、ホスト上で稼動するデータベースサーバが該当）で操作されるファイルを保存する為の、ファイルシステム（ＦＳ）を持つ。この図は各ホストの更なる詳細を示し、ホスト２が、ストレージ仮想化システムから提供される、仮想ＬＵへの読み書き要求することを可能にする（例えば、ＳＣＳＩ−２又はＳＣＳＩ−３のコマンドセットを使用する）ＳＣＳＩインターフェースが存在する。ＳＣＳＩインターフェースを使用して通信するには、ホスト２で稼動するＯＳにはドライバソフトウェアが必要である、ことを理解願いたい。

管理サーバ３は、ストレージ仮想化システム５に対する管理を実行する。管理サーバ３は、ポリシーマネージャ３０１とこのポリシーマネージャを管理するＧＵＩ生成器３０２を備える。ポリシーマネージャは、ストレージ仮想化システム５から仮想ＬＵに関する活動情報を収集する。例えば、データアクセス率等の統計情報が各仮想ＬＵに対して集積される。ポリシーマネージャ３０１は、仮想ＬＵの統計に基づいて候補仮想ＬＵを決める移行ポリシーを実装し、ソース仮想ＬＵからデータを移行する可能な対象としてこの候補仮想ＬＵを管理者に提示して推薦する。ポリシーマネージャ３０１は、候補仮想ＬＵを選択するのに限界値ベースのポリシーを実装することが出来る。収集した統計から新限界値を決定し、これにより、ポリシーを更新する。ポリシーマネージャ３０１はデータ移行を開始する。本発明の本態様については以降に更に詳細に述べる。ＧＵＩ生成器３０２は、コンソール４に表示する適切なインターフェース（例：ＧＵＩ（Graphical User Interface：図的なユーザインターフェース））を生成する。ＧＵＩを生成するのに好適な言語としては、ＨＴＭＬ（HyperText Markup Language）やＪａｖａ（登録商標）が存在する。

ポリシーマネージャ３０１の機能は、ストレージ仮想化システム５の中でも実現できることを理解願いたい。外部コンピュータシステム（例：コンソール４）は、ＬＡＮ１０を通してこの機能にアクセスできる。

ストレージ仮想化システム５はボリュームマネージャ５０１、統計マネージャ５０２、及び移行機能５０３を持つ。既に述べたように、ストレージ仮想化システム５は、ストレージサブシステム7で定義されるＬＵより成る仮想ＬＵを生成（定義）する。ストレージサブシステム7上のＬＵは、ＲＡＩＤの基準（例：ＲＡＩＤ０、ＲＡＩＤ１、ＲＡＩＤ５など）標準に基づいて構成できる。

ボリュームマネージャ５０１は仮想ＬＵを生成（定義）する。ボリュームマネージャは、ストレージサブシステム７のＬＵに対して、アドレスマッピング機能を提供する。このことが例えば図３に示される。既に述べたように、この図は、ストレージサブシステムＡで提供される２ＧＢの“リアル”（物理）ＬＵ及びストレージサブシステムＢで提供される３ＧＢの“リアル”ＬＵを示す。ボリュームマネージャは、２ＧＢのＬＵと３ＧＢのＬＵを結合して、仮想ＬＵとして単一のボリュームを定義することが出来る。“リアル”なる用語は、ストレージサブシステム7の物理ストレージで定義されたＬＵを仮想ＬＵと区別するために使用される。各リアルＬＵは、このＬＵが構成する仮想ＬＵをサポートするために、下記の情報と関連する。

・ヘッダ情報５１、５４：ヘッダ情報はボリュームマネージャ５０１に構成するリアルＬＵの各々の性質を伝える。各リアルＬＵのヘッダは、５１２バイトのデータコンポーネントであり、ＬＵのアドレススペースであるＬＢＡ（Logical Block Address）を含む。ヘッダ情報は更に、リアルＬＵのサイズ、関連する仮想ＬＵ（ポートとポート上でのＬＵＮ）、これの構成（連結関係、ＲＡＩＤ０／１／５等）、及び仮想ＬＵ内での順序番号を持つ。例えば、２ＧＢのＬＵは仮想ＬＵ５０の第一の部分であり、この順序番号は“１”（最初の順序番号）となる。３ＧＢのＬＵは仮想ＬＵ５０の第二の部分で、この順序番号は“２”（二番目の順序番号）となる。この番号付けはリアルＬＵが追加される度に順番に継続する。
・データスペース５２、５５：各リアルＬＵのデータスペースのサイズは、ＬＵの全スペースからヘッダサイズ（この場合は５１２）を引いた値である。

仮想ＬＵ５０のＬＢＡ０は、第一順序のＬＵ５３のデータスペース５２の開始点である。仮想ＬＵでのデータスペースは、第二順序のＬＵ５６のデータスペース５５に継続する。この情報はボリュームマネージャ５０１で維持され、仮想ＬＵ５０のストレージアドレススペースをそれを構成するリアルＬＵのアドレススペースに対応させることが出来る。

ボリューム移行機能５０３は、オンラインデータを“ソース”仮想ＬＵから“対象”仮想ＬＵに移行（移動）するタスクを実行する。“ソース”及び“対象”仮想ＬＵを構成するリアルＬＵのロケーションは、同じストレージサブシステム７内に存在しても、別のストレージサブシステムに存在しても良い。

統計マネージャ５０２は、各仮想ＬＵにおける入出力活動に関するデータを収集する。例えば、統計マネージャは、ある期間の入出力動作の回数を計測して入出力動作の率を生成する。

図４に示す本発明の実施例では、ボリュームマネージャ５０１、統計マネージャ５０２、及びボリューム移行機能５０３は、ストレージ仮想化システム５上で稼動するプロセスである。別の実施例としては、これらの機能は、ストレージ仮想化システムのハードウェアとは分離した、ホストデバイス上で稼動する管理ソフトウェアが提供しても良い。そのような実施例では、ストレージ仮想化システムのハードウェアは単純なＦＣスイッチングファブリック構成となり、仮想ＬＵ機能を実現する為にホストデバイス上で稼動する管理ソフトウェアと協働することになる。

ここで本発明に従ったプロセスについて説明する。ある初期化ステップに於いて、ボリュームマネージャ５０１は、仮想ＬＵの組を定義する為に、ストレージサブシステム７で定義されたリアルＬＵを構成する。ポリシーマネージャ３０１は、ストレージ仮想化システム５と交信して仮想ＬＵを検出する。本発明では、二種類の仮想ＬＵ即ち、不使用（ＦＲＥＥ）仮想ＬＵと使用中（ＩＮ−ＵＳＥ）（データの為に使用されている）仮想ＬＵが存在する。

検出された仮想ＬＵは、ポリシーマネージャ３０１が維持するデータ構造の中で管理される。不使用仮想ＬＵの為に一組のテーブルが、使用中仮想ＬＵの為にもう一組のテーブルが用意される。図５は使用中仮想ＬＵの為のテーブルを示す。情報は便宜の為にテーブル形式で示される。各使用中仮想ＬＵに対して一行が使用される。各使用中仮想ＬＵは物理ポートに関連する。物理ポートフィールド１１は、使用中仮想ＬＵに関連する物理ポートの識別子を持つ。ＷＷＮフィールド１２は、各物理ポートにアサインされたＷＷＮ（World Wide Name）を保存する。仮想ＬＵフィールド１３は仮想ＬＵを番号で識別する。

クラスフィールド１４は、当該仮想ＬＵが属するストレージの“クラス”を識別する。本発明の本実施例では、仮想ＬＵは一つの性能基準に従ってクラス分けされる。例えば、本実施例ではオンライン、ニアライン、及びオフラインの３種類のクラスを定義する。その他のクラス分け及びクラス分け基準が存在することは勿論である。オンラインクラスは高性能ストレージデバイスより成る仮想ＬＵのクラスを示す。ニアラインクラスはより低い性能のストレージデバイスより成る仮想ＬＵのクラスを示す。オフラインクラスは、かなり低速なリモートストレージデバイスより成る仮想ＬＵのクラスを示す。このクラス名はそのロケーションを暗示するようにつけられているが、もっと総称的な層−１、層−２、層−３のような名前でも構わない。

システムの通常時の動作で活動情報が収集される。図５のテーブルにはアクセス率フィールド１５と入出力回数フィールド１６が示されている。アクセス率フィールド１５にはパーセント単位の活動指数を保持する。具体的には、この活動指数はある期間で発生した入出力動作で計測される。この図で示す説明の実施例では、この期間は一時間である。このアクセス率フィールド１５は、一つの期間から次の期間までの入出力動作のアクセス率の変化を示し、入出力動作の理論的な最高値に対するパーセントで表現される。本件については後に更に詳細に説明する。

入出力動作の理論的な最高値は、当該仮想ＬＵを構成する各種ハードウェアコンポーネントに関する性能データから決定できる。例えば、理論的な最高値は単純に、仮想ＬＵを構成する各物理ストレージデバイスの最高入出力動作の平均値でも良い。入出力活動の理論的な最高値を取得する多数の方法があるが、その目的とするところは、実際の入出力動作数（単位時間当たりの）が比較出来る何か普遍的な指数を用いることである。

入出力回数フィールド１６は、前回の入出力動作の回数を示し、アクセス率フィールド１５を更新する時間に同期して更新される。以下に説明する様式で使用する変化値を決定する為に、各時間毎に、入出力回数フィールド１６の値を現在の入出力回数値から減算する。現在の入出力回数値は次いで入出力回数フィールド１６に保存され、次の時間の為に使用される。

図６を参照して不使用仮想ＬＵテーブルを説明する。情報は便宜の為にテーブル形式で示される。各不使用仮想ＬＵに対して一行が使用される。各行はロケーションフィールド４１を伴う。各不使用仮想ＬＵは物理ポートに関連する。ロケーションフィールド４１は、当該仮想ＬＵに関連する物理ポートの識別子を保存する。ロケーションフィールド４１は更に、この物理ポートにアサインされたＷＷＮを保存するＷＷＮフィールドを持つ。各行に対応する仮想ＬＵは、ロケーションフィールド４１に保存される番号で識別される。クラスフィールド４２は当該仮想ＬＵのクラスを表示する。サイズフィールド４３は当該仮想ＬＵのデータ容量を示す。

検出プロセスでは、図５、図６で示すテーブルの一部を満たすのみである。ユーザ（例：システム管理者）は、定義されたクラスに各不使用と使用中仮想ＬＵをアサインする。本発明の本実施例で定義されるクラスはオンライン、ニアライン、及びオフラインである。かくして、クラスフィールド１４と４２は満たされる。

図１Ａを参照して、本発明の一態様の一実施例に基づく、データ移行の為の処理ループ１００を説明する。ステップ１０１にて、ポリシーマネージャ３０１は使用中仮想ＬＵの為の図５のテーブルを定期的に更新する。ポリシーマネージャ３０１は、使用中仮想ＬＵの入出力活動に関連する統計情報を定期的に収集し、収集されたデータを図５の使用中仮想ＬＵテーブルに格納する。

ある時期に於いて、管理者としてのユーザは、仮想ＬＵの一組以上のデータ移行を保守上の義務として実施する。ステップ１０２にて、データ移行を実行する準備として、管理者はポリシーマネージャ３０１を起動する。ポリシーマネージャ３０１は、各使用中仮想ＬＵに対して対象仮想ＬＵを候補として推薦する。このことは、データ移行が必要との決定の基準となる活動指数を生成して、推薦候補を指定することを含む。以下に説明するように、この候補は仮想ＬＵの一つのクラスを指定する。ユーザは対象仮想ＬＵに対する自らの選択を示す（ステップ１０３）。ユーザが推薦を選択したら、対象仮想ＬＵが推薦された候補クラスをベースに選択される（ステップ１０５）。ユーザが推薦に反対したら、ユーザが選択した対象仮想ＬＵのクラスが採用される（ステップ１０６）。データ移行は選択された対象仮想ＬＵに対して実行される（ステップ１０４）。

別の実施例として、ポリシーマネージャ３０１は、ユーザの介入なしでデータ移行を自動的に実施することが出来る。この場合には、上記したユーザとの交渉は必要ない。ポリシーマネージャ３０１は、幾つかの数の自動データ移行を実施し、次いでユーザを含めた対話的データ移行を実施しても良い。そのような方法では、ユーザによる随時の“監視”付自動データ移行を実施することになる。この為の典型的ステップは、以下より成る。
・仮想化システムから、入出力活動等の各仮想ＬＵの統計情報を集め、
・新ロケーションの推薦を計算し、
・仮想ＬＵの推薦された新ロケーションを決定し、
・次いでデータ移行を実行する。

図１と図７により、ステップ１０２で決定した選択オプションを提示するのにＧＵＩ（Graphical User Interface）を使用することが出来る。ＧＵＩではポートフィールド２１、仮想ＬＵフィールド２２、クラスフィールド２３、アクセス率フィールド２４、推薦クラスフィールド２５、及びユーザ選択フィールド２６を表示する。この情報は、グラフィック上の垂直スクロールバー２８を持つ慣用的なＧＵＩウィンドウで示される。スクロールバーは、仮想ＬＵのリストをウィンドウ内でスクロールする為に使用される。

各使用中仮想ＬＵは、情報２７の行の仮想ＬＵフィールド２２により識別される。仮想ＬＵが関連するポ−トはポートフィールド２１に示される。仮想ＬＵが属する現在のクラスはクラスフィールド２３に示される。既に述べたように、本発明のここに示す実施例で定義されるクラスはオンライン、ニアライン、及びオフラインの三クラスである。アクセス率フィールド２４は、各仮想ＬＵの現在の活動レベルを表す指数を表示する。この指数は、図５のアクセス率フィールド１５より得られる。推薦クラスフィールド２５は、以下に説明するポリシーに基づいて、仮想ＬＵの現在のクラスを置き換える推薦クラスを表示する。

本実施例で使用するクラス分けは、仮想ＬＵを構成するデバイスの性能に基づくが、大ざっぱにはこのデバイスのロケーションに関連する。例えば、オンラインクラスはオンサイトのデバイスを示す。名前が暗示するように、ニアラインクラスは他の建物に存在するデバイスを示し、オフラインクラスは遠く離れて、結果として最も遅い性能を持つデバイスを示す。

ユーザ選択フィールド２６では、推薦クラスフィールド２５での推薦をユーザが覆すことが出来る。ユーザ選択フィールドは、使用中仮想ＬＵの移行先となるその他のクラスのリストをユーザに提示するグラフィックのドロップダウンメニュー２９を持つことが出来る。別の実施例として、別のウィンドウが“ポップアップ”してユーザにクラスリストを提示しても良い。

ＧＵＩを使用することにより、ユーザは各使用中仮想ＬＵに対する、移行動作の対象としての対象仮想ＬＵクラスを選択することが出来る。ユーザが、仮想ＬＵに対する移行動作の実行を拒否する、“移行なし”オプションをドロップダウンメニュー２９に加えても良い。

図１Ａに戻って、ステップ１０１にて、使用中仮想ＬＵのデータがストレージ仮想化システム５より定期的に集められる。例えば、図示した実施例では期間は１時間毎である。ストレージ仮想化システム５の統計マネージャ５０２は、各仮想ＬＵの入出力動作の回数を計測することが出来る。統計マネージャは、この計測情報を、ＳＮＭＰ（Simple Network Management Protocol）やＣＩＭＯＭ（Common Information Model Object Manager）等の既知プロトコルによって、ポリシーマネージャ３０１に提供することが出来る。ポリシーマネージャ３０１は、この情報を仮想ＬＵの為にＳＮＭＰやＣＩＭＯＭプロトコルを用いて集めて、図５の使用中仮想ＬＵのテーブル中に各仮想ＬＵ毎に格納することができる。具体的には、情報は入出力回数フィールド１６に納められる。或は又、入出力回数フィールド１６の情報は公知のＳＣＳＩコマンドを使用して取得することも出来る。例えば、scsiTargetStatsGroup内のscsiTgtPortInCommandオブジェクトをＳＣＳＩデバイス内に保存された情報にアクセスする為に使用することが出来る。入出力回数フィールド１６が既に保存された値を持っておれば、変化値は、以前の値と取得された値の差分により計算することが出来る。取得された値は、次いで入出力回数フィールド１６に格納される。

変化値に対しては正規化処理がなされる。例えば、データ収集間隔は（図５に示す通り）一時間とする。更に、一ＬＵの理論的な入出力スループットは、４０，０００ＩＯＰＳ（入出力回数／秒）とする。従って、一時間当りの理論的な最高入出力回数は、１４４，０００，０００となる。ある仮想ＬＵの与えられた一時間での入出力回数が、その前の一時間に比べて、１４，４００，０００回増加した（即ち変化値が１４，４００，０００）とする。活動率は、一時間当りの理論的最高値に対するパーセントで表した一時間当りの変化分である。この結果は約１０％である。この結果は、図５に示すテーブルのアクセス率フィールド１５に保存される。

図８を参照して、推薦（図１Ａのステップ１０２）用の候補を選択する為に使用する、ポリシー３１０に関する説明を行う。本発明の実施例に於いては、次のポリシーに従って各使用中仮想ＬＵに対して候補を表示する。ステップ３１１にて、仮想ＬＵに於ける活動指数（アクセス率フィールド１５）が第一の規定の限界値Ｍ以上であれば、ステップ３１３にてオンラインクラスを推薦する。指数が限界値Ｍよりも小で第二の限界値Ｌ以上ならステップ３１４にてニアラインクラスを推薦する。活動指数がＬよりも小であったら、ステップ３１５にてオフラインクラスを推薦する。本発明の一実施例では、Ｌは２０に、Ｍは６０にセットされる。

仮想ＬＵのクラスが推薦され、こうして現在の使用中仮想ＬＵに保存されているデータを移行する対象として可能性ある仮想ＬＵの組が指定されることに注意願いたい。移行対象の候補としての仮想ＬＵを特定するには、追加の処理があることに注意願いたい。このような特定の為の処理は、本発明の実施例に従って、実際上、後の時点で実施され、このことは後に説明する。

以上のステップは、各使用中仮想ＬＵについて繰り返される（ステップ３０６）。

仮想ＬＵの使用パターンが時と共に如何に変わってきたかを、管理者が認識するのを助ける為にステップ３０７で結果アクセス指数が生成され、図７のＧＵＩの結果アクセスフィールド３０に表示される。仮想ＬＵの使用パターンの変動は、使用中仮想ＬＵの各々の現在の所属クラス（クラスフィールド２３）を対応する推薦クラス（推薦クラスフィールド２５）と比較することにより、判定することが出来る。推薦欄での設定は、所定の期間で集められた性能情報に基づいたポリシー３０１での提案された変更を反映している。

かくして、ステップ３０７にて、比較の為に数的表示を行う為の指数が計算される。多様な計算が可能である。“Ｎ”は使用中仮想ＬＵの全数、“Ｍ”は現在の所属クラス（クラスフィールド２３）が推薦されたクラス（推薦クラスフィールド２５）と等しい仮想ＬＵの数とする。結果アクセスフィールド３０に示される指数の単純な例としては、差“Ｎ−Ｍ”である。もう一つの指数の例は、ＭのＮに対するパーセント、即ち、（（Ｍ／Ｎ）×１００）％である。更に他の指数の例は、ＭとＮの差のＮに対するパーセント、即ち、（（（Ｎ−Ｍ）／Ｎ）×１００）％である。

ステップ３０８にて、例えば図７のＧＵＩ表示により、以上のステップでの結果をユーザに提示する。

図８に示す前述のポリシー３１０は、本発明の一実施例に従って実装されるものである。推薦候補を生成する為に図に示されたポリシー３１０に代わって、他の任意のポリシーが使用できることに注意願いたい。使用される具体的ポリシーに拘わらず、結果アクセスは計算可能である。本発明の本態様によれば、ユーザが推薦を如何に頻繁に選択したか又はしなかったかに基づいて、如何によくポリシーが実行されたかを示す表示がユーザに提供される。

図９を参照して、移行動作の実施に際して、ステップ１０４に対して下記の処理が実行される。ステップ４０１にて、ポリシーマネージャ３０１は、移行モジュール５０３に、対象仮想ＬＵのクラスを指定して、指定したソース仮想ＬＵから対象仮想ＬＵにデータを移行することを指示する。ステップ４０２にて、移行モジュール５０３は、図６に示す不使用仮想ＬＵテーブルを調べて適切な対象仮想ＬＵを取得する。移行モジュール５０３は、指定されたクラスの仮想ＬＵのみを対象として、少なくともソース仮想ＬＵと同等以上の容量を持つ仮想ＬＵを選択する。該当ＬＵが見つからなければ、適切なエラー処理が実施される。

ステップ４０３にて、移行モジュール５０３は、ソース仮想ＬＵと対象仮想ＬＵで成るペアを生成する。次いで、ステップ４０４にて、ソース仮想ＬＵのデータが対象仮想ＬＵにミラーされる。ステップ４０５にて、ミラー化動作が完了したら、移行モジュール５０３はソース仮想ＬＵと対象仮想ＬＵのペアを停止する。これにより、ソース仮想ＬＵに接続されているホストからの入出力動作を抑止することが出来る。ステップ４０６にて、移行モジュール５０３は、ホストからのデータパスを再構成して対象仮想ＬＵがホストとデータ通信できるようにする。

ペアはステップ４０７にて破棄される。図５に示す使用中テーブルにエントリが生成され、対象仮想ＬＵの情報が保存される。対象仮想ＬＵでの入出力動作が回復し、ホストにて抑止されていた入出力も回復し、対象仮想ＬＵとの間でのデータ通信が開始される。ステップ４０８にて、移行モジュール５０３は、図６の不使用テーブルにエントリを生成してソース仮想ＬＵをこの不使用テーブルに戻す。

本発明のもう一つの態様について、図１Ｂを参照すると、ポリシーマネージャ３０１は、現ポリシーを新ポリシーに交代するのに必要な時期を決定する。ポリシーマネージャ３０１は、現ポリシーに関する情報を提供して、ストレージ仮想化システム５から得られた活動情報を基にして交代ポリシーを推薦する。管理者を含むユーザは、現ポリシーを変更する為にポリシーマネージャ３０１に介入することができる。

ステップ１０１にて、ポリシーマネージャ３０１は、図５に示す使用中仮想ＬＵテーブルを定期的に更新する。ポリシーマネージャ３０１は、使用中仮想ＬＵの入出力活動に関する統計情報を定期的に収集し、収集データを図５の使用中仮想ＬＵテーブルに保存する。これは図１Ａと同じ処理である。

ステップ１０２´にて、ポリシーマネージャ３０１は、各使用中仮想ＬＵに対して、移行を推薦するかどうか、更に現ポリシーに代わる新ポリシーを推薦するかどうか、を決定する。この為に、データ移行が必要とされ新ポリシーを推薦する根拠として、活動指数を生成する。このステップについては以降にてより詳しく説明する。

ステップ１０３´にて、ユーザが推薦ポリシーを選択したら、ステップ１０４´にて、新ポリシーによる図１Ａに示すデータ移行プロセスループ１００が開始する。ユーザが新ポリシーを拒否したら、プロセス１００´は単純に終了する。

ポリシーマネージャ３０１は、ステップ１０１で収集した統計情報に基づいて、新ポリシーを推薦する。本発明の本態様の例では、仮想ＬＵの測定された入出力率とクラス率を用いて、ポリシーマネージャ３０１は新ポリシーを下記のように生成することができる。新ポリシーは、図８で使用されたＭとＬの新しい値で構成される。
・図５の使用中テーブルより、各使用中仮想ＬＵに対して、最高入出力率（Ｘ％）を取得する。
・各クラス毎の仮想ＬＵ数を取得する。かくして、各クラス（即ち、オンライン、ニアライン、及びオフライン）毎の不使用と使用中の仮想ＬＵ数が合計される。
・クラス率を計算する。例えば、
オンライン（仮想ＬＵの合計値をａとする）：ａ/（ａ＋ｂ＋ｃ）％
ニアライン（仮想ＬＵの合計値をｂとする）：ｂ/（ａ＋ｂ＋ｃ）％
オフライン（仮想ＬＵの合計値をｃとする）：ｃ/（ａ＋ｂ＋ｃ）％
・新ポリシーの推薦を作成する。例えば、ポリシーマネージャ３０１は、最高の入出力パーセントを上記の率で修正する。
Ｌ＝Ｘ×（１−ａ/（ａ＋ｂ＋ｃ））％
Ｍ＝Ｘ×（１−ａ/（ａ＋ｂ＋ｃ）―ｂ/（ａ＋ｂ＋ｃ））％
・新ポリシーの結果を表示する。

この結果は、図１０に示すように、コンソールからＧＵＩの形で提示される。このＧＵＩは、ポリシー名フィールド３２、ポリシールールフィールド３３、現限界値フィールド３４、推薦限界値フィールド３５、及びユーザ選択フィールド３６より成る。各ポリシーの名前はポリシー名フィールド３２で与えられる。このポリシーの具体的なルールはポリシールールフィールド３３で示される。ポリシーを構成するルールとして現在有効な限界値は現限界値フィールド３４に示される。新ポリシーを構成する推薦限界値は推薦限界値フィールド３５に示される。ユーザ選択フィールド３６は推薦限界値フィールド３５で提示された推薦限界値を用いる代わりにユーザ自身が選択する限界値を手動で入力できるようにする。

ユーザがポリシーを選択後、ポリシーマネージャ３０１は旧ポリシーを新ポリシーで置き換える。本実施例では、この更新はＭとＬの値を更新することより成る。次いで、ステップ１０４´にて、データ移行は新ポリシーで実施される。

図１Ａは、本発明の一態様によってなされる処理を説明するフローチャートである。 図１Ｂは、本発明のもう一つの態様によってなされる処理を説明するフローチャートである。 図２は、本発明の一実施例に基づくシステムの一般的なブロック図である。 図２Ａは、図２のもう一つの構成を示す。 図３は、物理ストレージ上で定義される一台以上のＬＵより成る仮想ＬＵを示す。 図４は、ソフトウェアコンポーネントとその相互結合を示す、図２の論理構成である。 図５は、使用中仮想ＬＵに関する情報を維持するテーブルを示す。 図６は、不使用仮想ＬＵに関する情報を維持するテーブルを示す。 図７は、ユーザ指定対象と推薦された候補仮想ＬＵの何れかをユーザが選択する為に、ユーザに提示されるＧＵＩの一例を示す。 図８は、候補対象を指定するフローチャートである。 図９は、データ移行動作を示すフローチャートである。 図１０は、新ポリシーを提示するＧＵＩの一例を示す。

符号の説明

２……ホスト、５……ストレージ仮想化システム、６……ストレージコンポーネント、７……ストレージサブシステム、５９……仮想ＬＵ。

Claims (5)

1. 複数のストレージデバイスと、
   前記ストレージデバイスで定義される一台以上の物理論理ユニットから成る複数の仮想論理ユニットを定義する仮想化コンポーネントと、
   各前記仮想論理ユニットに関連する入出力活動情報を前記物理ストレージデバイスから収集し、収集した前記入出力活動情報に基づいて、前記仮想論理ユニットごとの単位時間当たりのアクセス率を表す活動指数をそれぞれ算出するポリシーマネージャと、
   を備え、
   前記仮想論理ユニットは、所定の性能基準に従って複数の論理ユニットクラスにクラス分けされ、
   前記ポリマネージャには、前記仮想論理ユニットの活動指数に応じて推薦すべき、当該仮想論理ユニットに格納されたデータの移行先の前記仮想論理ユニットが属する前記論理ユニットクラスを予め規定した第一のポリシーが与えられ、
   前記ポリシーマネージャは、前記第一のポリシーに基づいて、一の仮想論理ユニットから他の仮想論理ユニットへのデータ移行を実行し、
   前記ポリシーマネージャは更に、
   前記入出力活動情報に基づいて、ユーザに推薦する新たな第一のポリシーでなる推薦ポリシーを生成する第一のステップと、
   前記推薦ポリシーをユーザに提示する第二のステップと、
   前記第一のポリシーを、前記推薦ポリシーか又は該推薦ポリシーとは異なるポリシーを表すユーザ選択情報のいずれかから決定される第二のポリシーで置き換える第三のステップとを有する処理を実行する、
   ことを特徴とするストレージ仮想化システム。
2. 前記ポリシーマネージャは更に、前記第三のステップを、前記ユーザからの入力に応じて実行する、
   ことを特徴とする請求項１のシステム。
3. 前記入出力活動情報は、ＳＮＭＰ（Simple Network Management Protocol）プロトコルを使用して収集される、
   ことを特徴とする請求項１のシステム。
4. 前記入出力活動情報は、ＣＩＭＯＭ（Common Information Model Object Manager）プロトコルを使用して収集される、ことを特徴とする請求項１のシステム。
5. 前記ストレージデバイスはＳＣＳＩ（Small Computer System Interface）デバイスで、前記入出力活動情報はＳＣＳＩコマンドを用いて収集される、
   ことを特徴とする請求項１のシステム。