JP5736047B2 - 計算機システム、及び、その制御方法 - Google Patents

Description

本発明は計算機システムに係り、特に、ストレージシステムのリソースを分割し、そして、ストレージリソースのグループを複数のユーザに割当てるための計算機システム、及び、その制御方法に関するものである。

ストレージシステムに、複数の企業等複数ユーザのデータが混在する環境においては、ユーザ毎にストレージシステムの運用や管理を行うこと、即ち、マルチテナンシーに対するニーズが高まってきている。このマルチテナンシー環境により、ストレージリソースの効率的運用と、その管理の容易化が達成される。

マルチテナンシー環境には、各企業のストレージシステム管理者が、他の企業のデータ（ボリューム）を壊さない、データが他の企業に漏洩しない、他の企業のストレージシステム管理者の操作に影響を及ぼさない、等のセキュリティに関する仕組みが必要となる。

このマルチテナンシー環境を実現するために、ストレージリソースを論理的に分割して、複数のストレージリソースグループを実現するシステムが知られている。このシステムによれば、論理的に分割された、ストレージリソースのグループが個々の企業に割当てられることによって、既述のマルチテナンシー環境が実現される。なお、以下、ストレージリソースを、リソース、と略し、ストレージリソースグループを、リソースグループ（ＲＳＧ）、と略す。

リソースグループを形成する機能には、キャッシュ分割機能とリソース分割機能が必要となる。キャッシュ分割機能は、ストレージシステム内のキャッシュを論理的に分割する。分割された仮想キャッシュは［ＣＬＰＲ］と呼ばれている。リソース分割機能は、ストレージシステム内のリソース（ポート、ＣＬＰＲ、パリティグループ、ＬＤＥＶなど）を論理的に分割する。分割されたリソースは［ＳＬＰＲ］と呼ばれている。

従来のリソースグループを実現するためのシステムは、ＣＬＰＲ番号・ＳＬＰＲ番号に基づいてリソースグループを作成する。ストレージシステムの管理者が各リソースグループをホスト計算機に割当てることによって、あるホスト計算機のＩ／Ｏ処理が他のホスト計算機に影響せず、ホスト計算機間でのセキュリティが確保されたシステムが実現される。

既述のリソース分割機能によって、ストレージシステム全体の管理者(全体管理者)は、目的別、用途別に分割されたリソースグループに対しても管理者（分割管理者）を設定できる。リソース分割機能に関する従来技術として、例えば、特開２００６−１８５３８６号公報に記載のものが存在する。

特開平２００６−１８５３８６号公報

一つの企業内に複数の管理者ユーザを設けて、企業に属するリソースの管理を複数ユーザで実施させようとした形態では、全体管理のユーザに対する権限、分割管理のユーザに対する権限、そして、複数のユーザに対する、リソースグループの割当てが適切に運用されないと、複数のユーザ間でリソースの割当てに不均衡が生じたり、複数のユーザ間で情報のセキュリティが保たれないといった課題が生じていた。

そこで、本発明は、ストレージシステムの管理を複数のユーザに広範に行わせる場合でも、複数のユーザ間でリソースの割当てを均衡して行い、かつ、複数のユーザ間の情報セキュリティを確保できる計算機システム及びその制御方法を提供することを目的とするものである。

前記目的を達成するために、本発明は、ホスト計算機からのストレージデバイスに対するリードアクセス又はライトアクセスを制御するストレージシステムと、前記ストレージシスムの複数のリソースと前記ストレージシステムを共用する複数のユーザとを管理する管理装置と、を備え、前記ストレージシステムは、前記複数のリソースがグループ化されることによって定義される複数のリソースグループと、当該複数のリソースグループの管理情報と、当該複数のリソースと前記複数のリソースグループとの対応情報と、を格納する記憶領域と、前記複数のユーザがグループ化されることによって定義され、それぞれ前記複数のリソースグループの少なくとも一つに割り当てられる複数のユーザグループと、を備え、前記管理装置は、前記複数のユーザの少なくとも一のユーザのログインに基づいて、当該ユーザが属する前記ユーザグループに付与された権限で許容される操作を、前記ストレージシステムに、前記ユーザグループに割り当てられた前記リソースグループに対して実行させる、計算機システムであって、前記ストレージシステムが複数の仮想ストレージシステムに分割され、当該複数の仮想ストレージシステムのそれぞれに前記複数のユーザが設定され、前記複数の仮想ストレージシステムのそれぞれは、同一のリソースグループに論理リソースと物理リソースとが共存しないように、前記ストレージシステムから割当てられた論理リソースのみからなる第１のリソースグループと、物理リソースを有する第２のリソースグループと、に分割され、前記第１のリソースグループの前記論理リソースは前記第２のリソースグループから取り出し物理リソースから設定され、前記複数のユーザグループのうち、第１のユーザグループが前記第１のリソースグループに割当てられ、第２のユーザグループが前記第１のリソースグループと前記第２のリソースグループに割当てられて、論理リソース及び物理リソースを複数のユーザグループ間で共有させることを特徴とする。

したがって、本発明によれば、管理ユーザに対して実行可能とする操作範囲を、ユーザが属するユーザグループに付与された権限と、ユーザグループに割当てられたリソースグループと、によって決まるようにしたため、複数のユーザ間でのリソースの割当てを均衡して行い、かつ、ユーザ間の情報セキュリティを確保することができる。

本発明によれば、ストレージシステムの管理を複数のユーザに広範に行わせる場合でも、複数のユーザ間でのリソースの割当てを均衡して行い、かつ、ユーザ間の情報セキュリティを確保できる計算機システム及びその制御方法を提供することができる。

計算機システムの実施形態のハードウエアブロック図である。 計算機システムのユーザグループ・リソースグループ管理機能を実現する機能ブロック図の一例である。 リソースグループが設定される前のストレージシステムのブロック構成図である。 ストレージシステムに一つのリソースグループが設定された状態のストレージシステムのブロック構成図である。 論理ボリューム（ＬＤＥＶ）のＩＤと所属するリソースグループＩＤとの対応関係を示す管理テーブルであり、ストレージシステムにリソースグループが設定される前の管理テーブルの一例である。 ストレージシステムにリソースグループが設定された後の論理ボリュームの管理テーブルの一例である。 ストレージシステムにリソースグループが設定される前のパリティグループの管理テーブルの一例である。 ストレージシステムにリソースグループが設定された後のパリティグループの管理テーブルの一例である。 ストレージシステムにリソースグループが設定される前のホストグループの管理テーブルの一例である。 ストレージシステムにリソースグループが設定された後のホストグループの管理テーブルの一例である。 ストレージシステムにリソースグループが設定される前のポートの管理テーブルの一例である。 ストレージシステムにリソースグループが設定された後のポートの管理テーブルの一例である。 リソースグループＩＤを管理するテーブルの一例である。 ストレージシステムのリソースが分割され、複数の仮想プライベートストレージシステムに向けてグループ化された状態でのストレージシステムのブロック図である。 ユーザの外部管理端末にログインする処理の一例のフローチャートである。 ユーザが属するユーザグループの特定をビットマップによって管理するユーザグループＩＤビットマップテーブルである。 ユーザグループの権限をビットマップによって管理する権限ビットマップテーブルである。 権限ビットマップと権限との対応関係の一例を示すテーブルである。 権限毎に管理ユーザがストレージシステム対して実行可能な操作を対応させたテーブルである。 ユーザグループに割り当てられているリソースグループをビットマップによって管理するリソースグループＩＤビットマップテーブルである。 ユーザのログインセッションを管理するセッション管理テーブルの一例である。 ストレージシステムを複数の企業毎のシステムに論理的に分割するフローチャートの一例である。 ストレージシステムが複数の仮想システムに分割された後でのＬＤＥＶ構成情報テーブルの一例である。 ストレージシステムが複数の仮想システムに分割された後でのパリティグループ構成情報テーブルの一例である。 ストレージシステムが複数の仮想システムに分割された後でのホストグループ構成情報テーブルの一例である。 ストレージシステムが複数の仮想システムに分割された後でのポート構成情報テーブルの一例である。 ストレージシステムから企業の仮想プライベートストレージシステムに割当てられたリソースグループがさらに分割され、分割されたリソースグループが企業の管理ユーザグループに割当てられている状態を示す仮想プライベートストレージシステムのブロック図である。 ストレージシステムから企業の仮想プライベートストレージシステムに割当てられたリソースグループがさらに分割され、分割されたリソースグループがストレージシステムの全体管理用のユーザグループに割当てられている状態を示す仮想プライベートストレージシステムのブロック図である。 論理リソースのリソースグループが仮想プライベートストレージに設定される前における、運用前の仮想プライベートストレージのブロック図である。 ユーザグループに権限を割り当てるための処理の一例を説明するフローチャートである。 企業の仮想プライベートストレージシステムにリソースグループを作成し、これを企業内のユーザグループへ割り当てる処理に相当するフローチャートである。 企業内仮想プライベートストレージシステムにおける複数のリソースグループの構成形態の第２の例に係るブロック図である。 企業内仮想プライベートストレージシステムにおける複数のリソースグループの構成形態の不適切な例に係るブロック図である。 企業内仮想プライベートストレージシステムに複数のリソースグループが形成された形態（図２３）でのＬＤＥＶの構成情報の一例を表す管理テーブルである。 企業内仮想プライベートストレージシステムに複数のリソースグループが形成された形態(図２３)でのパリティグループの構成情報の一例を表す管理テーブルである。 企業内仮想プライベートストレージシステムに複数のリソースグループが形成された形態(図２３)でのホストグループの構成情報の一例を表す管理テーブルである。 企業内仮想プライベートストレージシステムに複数のリソースグループが形成された形態（図２３）でのポートの構成情報の一例を表す管理テーブルである。 企業内仮想プライベートストレージシステムに複数のリソースグループが形成された形態（図２８）でのＬＤＥＶの構成情報の一例を表す管理テーブルである。 企業内仮想プライベートストレージシステムに複数のリソースグループが形成された形態(図２８)でのパリティグループの構成情報の一例を表す管理テーブルである。 企業内仮想プライベートストレージシステムに複数のリソースグループが形成された形態(図２８)でのホストグループの構成情報の一例を表す管理テーブルである。 企業内仮想プライベートストレージシステムに複数のリソースグループが形成された形態（図２８）でのポートの構成情報の一例を表す管理テーブルである。 企業内仮想プライベートストレージシステムに複数のリソースグループが形成された形態（図２８）でのユーザグループとリソースグループとの対応をビットマップ管理するビットマップテーブルである。 ＬＤＥＶとプロビジョニングタイプとの関係を規定する管理テーブルの一例である。 物理リソースのリソースグループから論理リソースを切り出して、これを論理リソースのリソースグループに設定する処理の一例を説明するフローチャートである。 計算機システムの動作における第１の処理に係るフローチャートである。 第１の処理に続く第２の処理に係るフローチャートである。 第２の処理に続く第３の処理に係るフローチャートである。 第３の処理に続く第４の処理に係るフローチャートである。 図１８のステップ１８２０において、外部管理端末が表示するＧＵＩの画面である。 図２６のステップ２６０４において、外部管理端末が表示するＧＵＩの画面である。

以下、各図を参照して本発明の実施形態について説明する。図１は本実施形態に係る計算機システムの全体的なハードウエアを示している。計算機システムは、ストレージシステム１０と、複数のホスト計算機１２（１２Ａ，１２Ｂ）とを備えている。ストレージシステム１０はストレージコントローラ１６とストレージ駆動装置１８とを備えている。外部接続ストレージ１４がストレージシステム１０に接続されていてもよい。ストレージコントローラ１６とストレージ駆動装置１８とは同一筐体にあるものの他、別筐体になっていて、ネットワークによって接続されているものでもよい。

ストレージ駆動装置１８としては、ハードディスクドライブ、ソリッドステートドライブ、光ディスクドライブなどがある。ストレージコントローラ１６は、ホスト計算機１２から受信したコマンドに従って、ストレージ駆動装置１８に対するデータのリード・ライト処理、そして、ホスト計算機１２からのコマンドを受信して、ストレージシステムの構成情報の設定、変更などの各種処理を行う。

ホスト計算機１２は、ＣＰＵやメモリ等を備えたコンピュータ装置である。例えば、サーバ、ワークステーション、或いはメインフレームコンピュータ等の上位装置であり、銀行の自動預金預け払いシステムや、航空機の座席予約システム等の大規模データ管理システムに利用される。異なるユーザが各々のホスト計算機１２を利用して、ストレージシステムを運用する。ユーザとは、例えば、企業、又は、企業内の各部署である。

ホスト計算機１２は、例えばＳＡＮ２２を介してストレージシステム１０に接続されている。ＳＡＮ２２は、ストレージ駆動装置１８が提供する記憶資源におけるデータの管理単位であるブロックを単位として、ホスト計算機１２との間でデータの授受を行うためのネットワークである。ＳＡＮ２２を介して、ホスト計算機１２とストレージシステム１０との間で行われる通信プロトコルには、例えば、ファイバチャネルプロトコルがある。ホスト計算機１２とストレージシステム１０との間は、例えば、ＬＡＮを介して接続されていてもよく、或いは、ネットワークを介さずに直接に接続されていてもよい。外部接続ストレージ装置１４とストレージシステム１０との間と、外部管理端末２０とＳＶＰ１０８との間は、それぞれＬＡＮ１４０を介して接続されている。

ストレージ駆動装置としての複数のハードディスクドライブ１８は複数のパリティグループ（ＲＡＩＤグループともいう。）を構成しており、各パリティグループの論理記憶領域が分割されて論理ボリューム（ＬＤＥＶ）が構成されている。

ストレージコントローラ１６は、チャネル制御モジュール１００、メモリモジュール１０２、プロセッサモジュール１０４、そして、ディスク制御モジュール１０６を備え、さらに、ＳＶＰ（Service Processor）１０８と呼ばれる管理端末と接続している。さらに、ストレージコントローラ１６は、チャネル制御モジュール１００等を内部ＬＡＮによって相互に接続して、データやコマンドの受け渡しを行うためのスイッチ制御モジュール１１０を備えている。スイッチ制御モジュール１１０は例えばクロスバスイッチからなる。

チャネル制御モジュール１００はＳＡＮ２２を介してホスト計算機１２に接続している。チャネル制御モジュール１００のＳＡＮ２２と接続するポートには、コマンドを受領する属性のターゲットポートと、コマンドを発行する属性のエクスターナルポート又はイニシエータポートとがある。チャネル制御モジュール１００は、ホスト計算機１２と通信を行うための通信インタフェース（ホストＩ／Ｆ）を備え、ホスト計算機１２との間でデータやコマンド等の授受を実行する機能を備えている。

プロセッサモジュール１０４は、論理ボリュームに対する（データ）リードや（データ）ライトなどホストＩ／Ｏに対する処理を実行する。プロセッサモジュール１０４は複数のマイクロプロセッサ（ＭＰ）１０４ＡとＭＰのマイクロプログラムや制御用データを記録するローカルメモリ（ＬＭ）１０４Ｂを備えている。

ディスク制御モジュール１０６は、データを記憶する複数のハードディスクドライブ（ＨＤＤ）１８との通信インタフェース（ディスクＩ／Ｆ）を有し、ＨＤＤ１８との間でコマンドやデータの入出力を実行する。なお、チャネル制御モジュール１００、プロセッサモジュール１０４、ディスク制御モジュール１０６はチップ化され、それぞれ、各モジュールの複数のチップが冗長性の観点からストレージコントローラ１６に実装されている。

メモリモジュール１０２は、共有メモリモジュール１０２Ａとキャッシュメモリモジュール１０２Ｂとをそれぞれ複数備えている。共有メモリモジュール１０２Ａとキャッシュメモリモジュール１０２Ｂはそれぞれチャネル制御モジュール１００、プロセッサモジュール１０４、ディスク制御モジュール１０６に共用される。共有メモリモジュール１０２Ａは、制御情報やコマンド等を記憶するために利用され、キャッシュメモリモジュール１０２Ｂは、データを一時記憶するために利用される。

ＳＶＰ１０８は、ストレージシステム１０を保守、管理するための制御手段であり、外部管理端末２０とＬＡＮ１４０を介して接続している。全体管理のユーザは、外部管理端末２０のＧＵＩを経由して、ＳＶＰ１０８のストレージ管理プログラムにアクセスすることによりストレージシステム１０の全体のリソースを管理する。分割管理のユーザも自身のクライアント計算機を経由して外部管理端末２０のＧＵＩにアクセスし、管理対象のリソースにアクセスする。ＳＶＰ１０８を経由したアウトオブバント方式ではなく、ユーザが、ホスト計算機としての管理サーバを経由してストレージシステムにアクセスするインバンド方式によって、リソースを管理するようにしてもよい。なお、符号１２０はＳＶＰ１０８とスイッチ制御モジュールとを接続する内部ＬＡＮである。

リソースには物理リソースと論理リソースがある。さらに、リソースには、データ記憶用のストレージリソースと、制御用のリソースがある。リソースの例は次のとおりである。チャネル制御モジュール１００のポート、複数のＨＤＤからなるパリティグループ、キャッシュメモリ（ＣＬＰＲ）、マイクロプロセッサのオーナ権などは物理リソースの例である。ポートの属性、ポートに付属するホストグループ、論理ボリュームなどは論理リソースの例である。リソースに対する管理とは、ユーザのリソースに対する権限に基づいて、リソースを分割してリソースグループを設定すること、リソースの属性の設定、或いは、変更、リソースの新規作成、リソースの割当て、その変更などリソースに対する各種操作を行うことである。

全体管理のユーザには、ストレージシステムのリソースを全体的に管理できる権限が与えられている。分割管理のユーザには、自身に割り当てられたリソースグループの範囲内でリソースを管理できる権限が与えられている。既述のストレージシステム１０は、リソースグループに対する管理を複数のユーザに可能にさせるために、複数のユーザグループが設定される。例えば、ある企業において、全体管理のユーザグループと、企業の各部門における管理のユーザグループである。各ユーザグループにリソースグループが設定されるだけでなく、リソースグループに対する権限が与えられる。ユーザグループの権限の内容と割り当てられているリソースグループのリソースの種類、範囲、容量、そして数等、リソースの特性に応じて、ユーザグループがリソースに対して実行可能な処理内容が定まることにある。例えば、あるユーザグループには、物理リソースのグループと論理リソースのグループとが割当てられている一方、他のユーザグループには論理リソースのグループのみが割り当てられている等である。システムの保守側での管理が期待されるユーザには、システムの保守を実行するための広範な操作を可能にする権限と、物理リソースグループと論理リソースグループとが割り当てられている。一方、システムの運用や利用のための管理が期待されるユーザには、システムの利用・運用を実行する程度の権限と、論理リソースグループとが割り当てられている。

図２は、計算機システムのユーザグループ・リソースグループ管理機能を実現する機能ブロック図の一例である。ＳＶＰ１０８にはストレージ管理ソフトウェア２００が実装され、外部管理端末２０にはストレージ管理ソフトウェアに対する入出力用のＧＵＩが稼働している。ストレージ管理ソフトウェア２００は、ユーザのアクセス権限チェック２００Ａと、ユーザグループのビットマップによる管理２００Ｂと、ユーザグループの権限管理２００Ｃと、リソースグループＩＤのビットマップによる管理２００Ｄとを実行する。さらに、ストレージシステム１０のプロセッサモジュールのマイクロプログラムは、リソースグループの制御２０２を実現する。リソースグループ制御２０２には、リソースグループＩＤ管理テーブル２０２Ａとリソースグループ構成情報テーブル２０２Ｂが適用される。さらに、ストレージシステム１０は、ユーザのログインセッションの管理を実行する。セッション管理２０４にはセッション管理テーブル２０４１が適用される。そして、ストレージシステム１０はセッションの排他制御２０６を実行する。

計算機システムは、ストレージシステム１０のリソースを複数の仮想システムに分割し、さらに、仮想システムのリソースを複数のユーザグループに割当て、ユーザグループの権限にリソースグループを委ねることを特徴とする。この一連の過程を図面に基づいて説明する。

図３は、リソースグループ（ＲＳＧ）が設定される前のストレージシステムのブロック構成を示すものである。この状態では、全ユーザが全ＲＳＧを操作可能であるため、十分なセキュリティや性能を確保できない。ストレージシステムにはダイナミックプロビジョニングが実装されている。即ち、プール３０６にパリティグループ３０８から論理ボリューム(ＬＤＥＶ：プールボリューム)３０７が割り当てられ、プール３０６から容量仮想化論理ボリューム（ＬＤＥＶ：ＤＰボリューム）３０４に記憶領域がホスト計算機１２からのライトアクセスに応じて割り当てられる。ストレージシステム１０は、ホスト計算機１２との間のパスが形成される物理ポート３００を備え、そして、ポートにはホストグループ３０２が対応付けられる。一つの論理モジュールを複数サーバから参照する場合、その複数サーバをグループとして定義する。これがホストグループである。物理リソースとしては、ポート３００、パリティグループ３０８がある。一方、論理リソースには、プールボリューム３０７、プール３０６、ＤＰボリューム３０２、そして、ホストグループ３０４がある。

全体管理ユーザが、管理端末にアクセスしてストレージシステムにおけるＲＳＧの設定を有効化すると、図４に示すように、全てのリソース４００は、一時的に、特定のリソースグループＩＤ（ＩＤ＝０ｘ００００）を持つリソースグループ（リソースグループ名：ＲＳＧ０）に所属する。各リソースとリソースグループとの対応関係は、後述の構成情報テーブルにおいて説明する。図４において、ＵＧ０は全体管理ユーザが属するユーザグループであり、ＵＧ０にはストレージシステムの全体の管理権限が与えられている。

ストレージシステム１０の全リソースが同一のリソースグループ（ＲＳＧ０）に属している状態では、複数のユーザが全リソースを参照できる得る状況となり、セキュリティが確保できない。そこで、計算機システム１０では、セキュリティを確保する、そして、ストレージシステムの運用を的確に実行させるという観点から、ストレージシステムのリソースの複数のＲＳＧへのグルーピングは、特定の権限（システム権限）を持った全体管理のユーザグループ（ＵＧ０）に属するユーザによって実行されるとした。なお、分割管理ユーザの権限には複数あり、後述する。権限は、既述のとおり、ユーザ自体ではなく、ユーザグループ（以下、「ＵＧ」と略称することもある。）に与えられ、ユーザがどのＵＧに属するかによってユーザの権限が定まることになる。

次に各リソースグループ（ＲＳＧ）の構成情報テーブル(図２：２０２Ｂ)を説明する。この説明に際して、ストレージシステム１０にＲＳＧが設定される前とその後でのテーブルの変化を説明する。図５Ａは、論理ボリューム（ＬＤＥＶ）のＩＤと所属するリソースグループＩＤとの対応関係を示すものであり、ストレージシステムにリソースグループ（ＲＳＧ０）が設定される前のテーブルである。図５Ｂはその後のテーブルである。有効フラグは、ＲＳＧの設定状態を管理するためのものであり、ＲＳＧが設定されると、有効フラグが［０（無効）］から［１（有効）］に変化する。既述のとおり、全てのリソースはＲＳＧ０に設定されるために、全ての有効フラグが［１］に設定される。テーブルの有効フラグが変更された時点で、全てのリソース（ＬＤＥＶ）がＲＳＧ０（ID=0x0000）に所属することになる。このリソースグループ構成情報テーブルはストレージシステム１０の共有メモリ１０２Ａ内に保存されている。ＬＤＥＶには、既述のとおり、プールボリュームと仮想ボリュームとが含まれる。

図６Ａ、図６Ｂはパリティグループに関するテーブルであり、図７Ａ、図７Ｂは、ホストグループに関するテーブルであり、図８Ａ，図８Ｂはポートグループに関するテーブルである。[Ａ]と[Ｂ]の区別は、図５Ａ，図５Ｂと同じである。リソースグループＩＤと各リソースとの対応関係、及び、有効フラグの変化も同様である。

既述のリソースグループ構成情報テーブル(図５Ａ，Ｂ)と併せて、図９のリソースグループＩＤ管理テーブル２０２Ａがストレージシステムの共有メモリ１０２Ａに保持されている。リソースグループＩＤ管理テーブルは、リソースグループＩＤとリソースグループ名とを対応させるものであり、さらに、リソースグループＩＤ管理テーブル２０２Ａの［ロックしているログインセッションＩＤ］は、あるユーザが操作中のＲＳＧ（リソースグループ）を他のログインユーザが操作しないようにするためのものである。あるユーザのログインに［セッションＩＤ］を与えて、他のユーザのログインからこれをロックする際に設定される。図９は、あるユーザが［セッションＩＤ＝０１０１」でＲＳＧ１−ＲＳＧ３、ＲＳＧ１１，ＲＳＧ１２に接続して、これらを操作中であることを示している。ＲＳＧ０以外のＲＳＧの構成については後述する。

ストレージシステムのリソースがＲＳＧ０に設定された後、全体管理ユーザは、図１０に示すように、ストレージシステムを複数の仮想ストレージシステムに分割する。例えば、ストレージシステム１０をデータセンタ１００６の管理ユーザ（ＵＧ０に所属）が管理し、ストレージシステム１０を複数の仮想（プライベート）ストレージシステムに分割し、それぞれを別々の企業に割り当てる。例えば、ＲＳＧ２は企業Ａ(１０００)に割当てられ、同様に、ＲＳＧ５は企業Ｂ(１００２)に割り当てられている。

ＵＧ０には、ストレージシステム１０の全リソースを管理できる権限（セキュリティ権限）が割り当てられていることにより、ＵＧ０に属する管理ユーザは、ストレージシステムのＲＳＧ０からＲＳＧ２，ＲＳＧ５を切り出し、図１０のように、ストレージシステム１０に各企業向けの複数の仮想（プライベート）ストレージシステムを定義することができる。ＲＳＧ２からなる仮想ストレージシステムが企業Ａ向けとなり、ＲＳＧ５からなる仮想ストレージシステムが企業Ｂ向けとなる。ＵＧ０には、ＲＳＧ２，ＲＳＧ５，ＲＳＧ０が、ＲＳＧ２などに対する管理の実現のために、割当てられている。なお、ホストグループ３０２、仮想ボリューム３０４、プール３０６などの論理リソースは、仮想システムの使用者ユーザ（企業Ａのユーザ、企業Ｂのユーザ)によって定義、設定されてもよい。

この際、リソース構成情報テーブル(図５Ａ、Ｂ〜図８Ａ，Ｂ)のリソースＩＤに対する［（リソースが）所属するリソースグループのＩＤ］は、図４の形態から図１０の形態への変化に合わせて変更されている。すなわち、ＵＧ０の管理ユーザが外部管理端末２０とＳＶＰ１０８を介して共有メモリ１０２Ａのリソースグループ構成情報テーブル２０２Ｂを変更すると、ストレージシステム１０は、テーブルの変化に合わせて、リソースグループの構成を変更する。ＲＳＧ２とＲＳＧ５がＲＳＧ０から切り出された残りのリソースは、ＲＳＧ０に残ることになる。なお、ＲＳＧ０にリソースがない状態は、一つの管理状態として許容される。ストレージシステムに追加される物理リソースは、一旦ＲＳＧ０に属し、ＲＳＧ０から、ＵＧ０の権限の管理下で、各仮想ストレージシステムのＲＳＧに移動、或いは、分配される。

ストレージシステムから仮想ストレージシステムを分割する、既述の一連の処理は、ＳＶＰ１０８のストレージ管理ソフトウェア２００とストレージシステム１０のマイクロプログラムの協同によって実現される。図１１は、ユーザのログインを処理するフローチャートである。

全体管理ユーザが外部管理端末２０のＧＵＩにユーザＩＤとパスワードを入力すると（１１００）、入力情報はＳＶＰ１０８のストレージ管理ソフトウェア２００に送信され、ＳＶＰはユーザ認証を行う(１１０２)。ユーザ認証の判定(１１０４)がログインユーザを登録済みユーザではないとするものである場合には、ＳＶＰは外部管理端末のＧＵＩにエラー報告を行う。この判定が登録済みユーザであるとするものである場合、ＳＶＰはログインにセッションＩＤを設定し、ログイン時刻と、ログイン元情報をセッション管理テーブルに登録する（１１０５）。セッション管理テーブルについては後述する。ログイン元情報には、ユーザＩＤ、パスワード、ＩＰアドレスなどが含まれる。

次に、ＳＶＰはログインユーザがどのＲＳＧに対してどのような権限を有するかの判定のために必要な情報を取得する。先ず、必要情報として、ＳＶＰは、ログインユーザのユーザＩＤから、当該ユーザが所属する全てのＵＧを、図１２のユーザグループＩＤビットマップテーブル１２００を参照して取得する(１１０６)。ユーザグループＩＤビットマップテーブル１２００は、ユーザグループＩＤビットマップ管理２００Ｂ（図２）のために、全体管理ユーザがユーザ登録時に作成し、ＳＶＰ１０８のメモリ領域に登録する。ユーザグループＩＤビットマップテーブルは、ユーザ毎にユーザが属するユーザグループをビットマップによって管理するものであり、ビットマップの各ビットが個々のユーザグループに対応している。ユーザはユーザＩＤとユーザ名によって特定される。

例えば、ユーザ名が［Ｕｓｅｒ２］のユーザは、ユーザグループＩＤビットマップの３番目の位置のビットが［１］であることから、ＵＧ２（ユーザグループＩＤ＝０ｘ０２）に所属する。一人のユーザが複数のＵＧに所属する場合は、複数のユーザグループのＩＤに対応した複数の位置のビットに［１］が設定される。例えば、Ｕｓｅｒ２０は、［１］が設定されているビットの位置から、３つのユーザグループ（ユーザグループＩＤ＝０ｘ０ａ、０ｘ０ｂ、０ｘ１０）に所属する。

次に、ＳＶＰは、ログインユーザのユーザグループを決定すると、当該ユーザグループに割当てられた権限の情報とリソースグループの情報を取得する(１１０８)。権限の情報の取得には、図１３の権限ビットマップテーブル１３００が参照される。権限ビットマップテーブル１３００は、ユーザグループ権限管理２００Ｃ（図２）を実行するためのものであり、ユーザグループ毎に権限を設定し、権限はビットマップ形式にしたがって登録されている。権限ビットマップテーブル１３００はＳＶＰ１０８のメモリに記録されている。

全体管理ユーザは、ユーザグループ（ＵＧ）を定義する際に、権限ビットマップを権限ビットマップテーブル１３００に登録する。ビットマップのうち、［１］が設定されているビットに対応する権限がユーザグループに対して設定されている。ユーザが複数のユーザグループに所属する場合は、各ユーザグループに割り当てられた権限ビットを論理和した権限がユーザに与えられることになる。

また、権限ビットマップの各ビットに対応する、ストレージシステムに関する諸権限の対応は図１４に示すとおりである。さらに、それぞれの権限の下、全体或いは一部管理ユーザがストレージシステムに対して実行可能な操作内容は図１５に示すとおりである。例えば、ユーザ名（Ｕｓｅｒ０）のユーザは、図１２に基づいて、ユーザグループ（ＵＧ０）に属する。次いで、このユーザグループに対応する権限は、権限ビットマップテーブル（図１３）からその権限ビットマップの３番目のビットが立っていることから、図１４により、ユーザ名が［Ｕｓｅｒ０］のユーザには［セキュリティ］の権限が与えられている。権限ビットマップのビットマップと権限情報との対応、権限情報に対して許容される操作内容の対応に係る制御情報は、全体管理ユーザ（ＵＧ０）によって予めＳＶＰ１０８のメモリに設定されている。インバンド処理の場合は、インバンドからのログイン時にサーバからストレージ装置を介してＳＶＰにアクセスし、ログインユーザに関連するリソースグループ情報や権限情報を取得し、サーバ上で動作するソフトウェア上に一時的に保持する。この情報を元に、構成変更の可否を判定する。

ユーザグループ（ＵＧ）に割当てられたＲＳＧの情報の取得には、図１６のリソースグループＩＤビットマップテーブル１６００が参照される。このリソースグループＩＤビットマップテーブル１６００は、リソースグループＩＤビットマップ管理２００Ｄ（図２）のため、ユーザグループ毎にリソースグループの割当てを管理するものである。ユーザが複数のユーザグループに所属する場合は、各ユーザグループに割り当てられたリソースグループＩＤビットマップのビットを論理和して得られたビット列に対応するリソースグループが、ログインユーザのアクセスを許容するリソースグループとなる。例えば、ログインユーザが複数のユーザグループ（ＵＧ１１，ＵＧ１２）に所属する場合、それぞれのユーザグループに割り当てられているリソースグループ（ＲＳＧ）は図１６より、［0001 0000 0000 0000 0100 ...］と［0001 0000 0000 0000 0010 ...］によって特定されているために、ログインユーザはこれらを論理和した［0001 0000 0000 0000 0110 ...］したビット列に対応するＲＳＧ、すなわち、３つのＲＳＧ（ＲＳＧ ＩＤ＝０ｘ０３，０ｘ１１,０ｘ１２）にアクセスして、当該ＲＳＧを操作できることになる。リソースグループＩＤビットマップテーブル１６００も、ユーザの登録時に全体管理ユーザによってＳＶＰ１０８のメモリに設定される。

ＳＶＰ１０８がログインユーザに割当てられている権限情報（権限ビットマップ）とＲＳＧ情報（リソースグループＩＤビットマップ）の取得を完了すると、これをユーザログイン時に生成したセッションＩＤと共にセッション管理２０４のためのセッション管理テーブル１７００（図１７）に更新登録する(図１１：１１０７、１１１０)。例えば、セッションＩＤが［０１０１］のセッションはＵｓｅｒ０のログインに基づくものである。セッション管理テーブル１７００には、セッションＩＤ毎に、当該セッションＩＤが設定されたログインユーザに割当てられたリソースグループＩＤビットマップと権限ビットマップとが登録されている。ＳＶＰ１０８はセッション管理テーブル１７００をストレージシステム１０に送信し、ストレージシステム１０は共有メモリ１０２Ａにセッション管理テーブルを更新登録する。ＳＶＰ１０８はストレージシステムのプロセッサ１０４から完了通知を受けると、ログインを完了させる(１１１２)。ＳＶＰ１０８が、ユーザログイン時に生成されるセッションＩＤと共に、当該ユーザが持つ権限と管理対象であるＲＳＧの情報をセッション管理テーブル１７００に登録し、この登録をストレージシステムに通知することによって、ログインユーザに対する各種リソースとそれらの操作の可否や権限をストレージシステム側でもチェックできるようにしている。

ストレージシステムのリソースを複数の仮想ストレージシステムに分割した後でも、ストレージシステムの全リソースの管理を行う統合管理ユーザが必要である。そこで、ＳＶＰは、複数の仮想ストレージシステムの設定後でもセキュリティ権限を有しているＵＧ０に全てのリソースに対するアクセス権限を継続させることとした。ＳＶＰは、既存のリソースグループに対するビット［１］を維持しつつ、新規リソースグループがストレージシステムに設定或いは追加された場合も、当該新規リソースグループに［１］を自動的設定する。こうすることによって、ＲＳＧの作成、設定の都度、統合管理ユーザがＵＧ０に逐一新規ＲＳＧを割り当てる必要がなくなる。ＵＧ０が全てのリソースグループに対してアクセスできることは、図１６においてＵＧ０にリソースグループＩＤビットマップの全ビットが[１]であることによって説明できる。

次に、ストレージシステム１０に、リソースグループが有効化された後、全体管理ユーザは既述の図１０のように、ストレージシステムを複数の企業毎のシステムに論理的に分割する。この処理を図１８のフローチャートに基づいて説明する。Ｕｓｅｒ０（ＵＧ０）がストレージ管理ソフトへのログインに成功すると、ＳＶＰ１０８にはセッション管理テーブルが登録されている(図１７)。ＳＶＰ１０８は、外部管理端末２０の要求にもとづいて、セッション管理テーブルからログインユーザの権限ビットマップとリソースグループＩＤビットマップとを取得し、これを外部管理端末２０に送信する（１８０６）。

外部管理端末２０はログインユーザが全体管理の権限であるセキュリティ権限があるかを判定する。ログインユーザ（Ｕｓｅｒ０）はセキュリティ権限を有し、ストレージシステムの全リソースに対するアクセス権があるためＳＶＰ１０８にストレージシステムに存在するユーザグループ及びストレージグループの一覧を要求する(１８０８)。ＳＶＰがこの要求を受けると、ユーザグループＩＤビットマップテーブル１２００（図１２）とリソースグループＩＤビットマップテーブル１６００(図１６)とを参照して、ビットが設定されているユーザグループの一覧とビットが設定されているリソースグループの一覧を外部管理端末２０に送信する(１８１０)。ユーザグループの一覧はユーザＩＤ、ユーザ名、ユーザグループＩＤとの対応情報を含むものであり、ユーザグループＩＤビットマップか或いはこれに相当するものである。リソースグループリストは、各リソースＩＤと当該リソースが所属するリソースグループＩＤとの対応情報を含むものであり、既述のリソースＩＤとリソースグループＩＤとの関係を表す構成情報テーブルか或いはこれに相当するものである。ログインユーザが、セキュリティ権限以外を有する場合には、ステップ１８０８以降が行われることなく、セキュリティ権限以外の操作が実行される。

外部管理端末のＧＵＩは、ユーザーグループ一覧情報とリソースグループ一覧情報とを表示する。ログインユーザは、目的とする仮想ストレージシステムの形態、即ち、図１０に示すように、企業Ａ、企業Ｂについてそれぞれ仮想ストレージシステムを実現するように、一覧情報について、関係するリソースＩＤに新たなリソースグループＩＤを設定入力する(１８１２)。入力が終了すると、外部管理端末２０は、ＳＶＰ１０８に入力データを送信する。この入力データを受けたＳＶＰは、仮想ストレージシステムを構成するために設定あるいは更新されたリソースグループが適正なものか否かを判定する。すなわち、これらリソースグループについて、仮想ストレージシステムを構成するための最低限のリソースが存在するか否かを判定する。最低限のリソースとは物理リソースであり、例えば、パリティグループと、ターゲットポートである。これらリソースがリソースグループに存在していないと、ホスト計算機に対するデータ記憶システムを実現できないことになる。

前記判定には、例えば、下記の判定（１）と判定（２）とがある。仮想ストレージシステムに割当てられたリソースグループについて、判定（１）と判定（２）の何れかが肯定された場合には、リソースグループは適正なものと判定される。

判定（１）：リソースグループが、ターゲットポート、ホストグループ、ＬＤＥＶ、そして、パリティグループの各リソースを少なくとも一つ含んでいること。この判定（１）は仮想ストレージシステムが既に運用されている場合を想定した際の基準である。

判定（２）：リソースグループが、ターゲットポートとパリティグループの各リソースを少なくとも一つ含んでいること。この判定（２）は仮想ストレージシステムの運用前を想定した際の基準である。なお、図１０では、ＲＳＧ２及びＲＳＧ５とも物理リソースを備えているため、[ＲＳＧは適正]と判断される。

ＳＶＰ１０８がＲＳＧを適正でないと判定すると、外部管理端末２０のＧＵＩにエラーメッセージを送信する。ＧＵＩはエラー表示を行い、ログインユーザに再入力を促す。エラー表示には、例えば、リソースグループに不足しているリソースの種類を表示することが含まれる。ＧＵＩは、リソースグループに対して未設定なリソース、リソースグループに設定が推薦されるリソースを識別表示してもよい。

ＳＶＰが判定を肯定すると、ストレージシステムのスイッチ制御モジュール１１０に入力情報を送信する(１８１２)。プロセッサモジュール１０４はこの入力情報を元に共有メモリ１０２Ａにあるリソースグループ構成情報テーブル（図５Ａ，Ｂ〜図８Ａ，Ｂ）と、リソースグループＩＤ管理テーブル（図９）とを、ＲＳＧの設定内容になるように更新登録し(１８１４)、次いで、当該更新後情報を、スイッチ制御モジュール１１０を介してＳＶＰ１０８に送信する。ＳＶＰ１０８は、更新したリソースグループ構成情報テーブルの受信情報に基づいてリソースグループＩＤビットマップ(図１６)を構成する（１８１６）。外部管理端末のＧＵＩはリソースグループＩＤビットマップの更新情報に基づいて、リソースグループＩＤとこれに対応するユーザグループとの関係（リソースグループＩＤビットマップテーブル）をＧＵＩに表示する（１８２０）。リソースグループに対してユーザグループが割当てられていない場合には、ユーザグループＩＤ及びユーザグループ名が空欄になる。ステップ１８２０において、外部管理端末が表示するＧＵＩの画面を図４５に示す。管理ユーザがＧＵＩ画面左側でＵＧを選択すると、そのＵＧ毎に画面右側が切り替わることになる。

以上の処理の実行後での各リソース構成状態は、図１０のブロック図に対応するものになり、各リソース構成情報テーブルは、図１９−図２２に示すようになる。このうち、図１９はＬＤＥＶの構成情報テーブル１９００、図２０はパリティグループの構成情報テーブル２０００、図２１はホストグループの構成情報テーブル２１００、図２２はポートの構成情報テーブル２２００である。なお、ストレージシステムが一企業に占有される場合には、複数の仮想システムを設定するためのストレージシステムの分割の処理は不要となる。

このようにして、ストレージシステムが仮想ストレージシステムに分割されると、仮想ストレージシステムが割当てられた企業内の複数の管理ユーザに対して、仮想ストレージシステムのリソースはさらに分割されて、企業内での運用、既述の例では、ダイナミックプロビジョニングの運用に供される。図２３は、企業Ａに割当てられたリソースグループ（ＲＳＧ２）がさらに分割され、分割されたリソースグループが企業Ａの複数の管理ユーザに割当てられていることを示している。

全体管理用のユーザグループ（ＵＧ０）は、ＲＳＧ２を分割して、ＲＳＧ１、ＲＳＧ３、ＲＳＧ１１、ＲＳＧ１２を企業Ａ用の仮想ストレージシステムに対して設定する。ＵＧ０はＲＳＧ２から物理リソース（ポート）を取り出し、これをＲＳＧ１に割当てる。さらに、論理リソースとして、論理的な記憶領域からなるプール３０６と、プールに割当てられる複数のプールボリューム３０７とからなるＲＳＧ３と、それぞれ、ホストグループ３０２と仮想ボリューム３０４とからなるＲＳＧ１１、ＲＳＧ１２とを設定する。

さらに、ＵＧ０は、企業Ａの複数の管理ユーザ用のユーザグループを設定する。ユーザグループＵＧ２は、企業Ａ用の全リソースグループに対してアクセス権限を有している。このアクセス権限は、Ｐｒｏｖ（プロビジョニング権限）とＳｙｓｔｅｍ（システム権限）である。この権限の詳細な内容は図１５に示されている。プロビジョニング権限とは、ダイナミックプロビジョニングのために必要な操作を実行できる地位であって、ＬＤＥＶの作成／削除、プール／プールボリュームの作成・削除、ＤＰ−ＶＯＬ（仮想ボリューム）の作成／削除、ホスト計算機がアクセスするＬＵ（論理モジュール）の作成／削除、ホストグループの作成／削除、ホストの追加／削除を含む。

システム権限は、ストレージシステムのシステム構成にアクセスできる権限であって、ストレージシステムのシステム構成情報の参照、ＣＬＰＲ（キャッシュメモリの分割された領域）の作成／削除、マイクロプロセッサのオーナ権の設定、ポート属性の変更である。３００はターゲットポートを示し、３００Ａはイニシエータポートを示し、３００Ｂはエクスターナルポートを示す。マイクロプロセッサへのオーナ権の設定とは、ＬＤＥＶに対する、ホスト計算機からのＩ／Ｏの処理を特定のマイクロプロセッサに専有させることである。

ＵＧ１１、ＵＧ１２はそれぞれ論理リソースからなるＲＳＧ（ＲＳＧ１１，ＲＳＧ１２，ＲＳＧ３）に割当てられている。ＵＧ１１及びＵＧ１２は、それぞれ業務サーバの管理者のユーザグループであると想定すればよい。ＲＳＧ１１はＵＧ１１に専用して割当てられている。ＲＳＧ１１は業務サーバＡ用の論理領域である。同様にＲＳＧ１２はＵＧ１２に専用して割当らてれている。ＲＳＧ１２は業務サーバＢ用の論理領域である。

ＵＧ１１及びＵＧ１２とも、プロビジョニング権限と、ローカルコピー（ＬＣ）権限と、リモートコピー（ＲＣ）権限と、を有している。各権限の詳細については、図１５を参照されたい。なお、図１５におけるペアとは、コピー元ボリュームとコピー先ボリュームとのペアであり、ローカルコピーでは、両ボリュームとも同じストレージシステム内に設定される。リモートコピーでは、コピー元ボリュームはプライマリストレージシステムに設定され、コピー先ボリュームは、プライマリストレージシステムから遠方のセカンダリストレージシステム内に設定される。

ＵＧ２と、ＵＧ１１及びＵＧ１２との権限の相違は、前者はシステム権限を有し、後者はシステム権限を有していないことにある。そして、複数のＵＧの権限が同じでも、ユーザグループにどのようなリソースが割り当てられているかによって、ＵＧが実行可能な操作が異なって来る。ＵＧ２に属するユーザは、パリティグループ３０８からプールボリューム３０７を切り出して、これをプールに割当てることができるのに対して、ＵＧ１１又はＵＧ１２に属するユーザは、プロビジョニング権限を有しているためＬＤＥＶの作成が許容されていても、ＲＳＧ２にアクセスできないため、実際には、パリティグループからプールボリュームを切り出すことができない。このようにしたのは、ＵＧ１１とＵＧ１２との間で、パリティグループのリソース確保の競合が生じるのを避けるためである。そこで、既述のように、ストレージシステム１０は、ＲＳＧ２をＵＧ１１とＵＧ１２に割当てることなく、一方、ＵＧ２にＲＳＧ２を割当てた。ＵＧ２、ＵＧ１１、ＵＧ１２がそれぞれ、同じプロビジョニング権限を持つＵＧであっても、ＲＳＧ２をＵＧ２のみに割り当てたことによって、ＵＧＩＩとＵＧ１２との間での論理リソースの競合を回避することができる。さらに、ホストグループはポートに割当てられる属性であり、ＵＧ１１及びＵＧ１２にはＲＳＧ１が割当てられていないこと、そして、ＵＧ１１及びＵＧ１２はシステム権限を有していないことから、ＵＧ１１又はＵＧ１２に属するユーザは、ホストグループを定義、設定する際に制限を受けることがある。例えば、ＵＧ１１又はＵＧ１２に属するユーザは、ホストグループを定義、設定できないようにしてもよい。あるいは、ポートに対してホストグループが作成・ホストの登録がされる際、ホストグループＩＤの設定はＵＧ２のみに認められており、ＵＧ１１やＵＧ１２のプロビジョニング権限はこのＩＤにホストグループ名を付与することができるに過ぎない。このように各ユーザグループに割当てられるリソースグループの種別（物理リソースのグループか、論理リソースのグループか、或いは、両方か）、権限の種類によって、ユーザグループが実行可能な操作の実際の形態が決まって来る。

仮想ストレージシステムでは、ポート（ＲＳＧ１）やパリティグループ（ＲＳＧ２）の物理リソース、そして論理実ボリューム（プールボリューム（ＲＳＧ３））を複数のユーザグループ間で共有させることにより、ポートやボリューム容量の余剰を最小限に抑え効率よく利用し、コストを抑えた運用が可能になる。さらに、ダイナミックプロビジョニングのプール機能を利用することによって、容量の仮想化・容量追加の容易化も実現できる。

企業内の各部署への割り当て等が想定されるＲＳＧ１１やＲＳＧ１２について、これらを管理するＵＧ１１やＵＧ１２は互いに干渉しない専用のリソースを確保・運用することができる。また、ＲＳＧ１１及びＲＳＧ１２をそれぞれ論理リソースのみからなるようにすることで、プールへの容量追加やパリティグループの性能管理を特定ユーザグループ（ＵＧ２）に委ねることにより、システムに精通していないユーザ（ＵＧ１１，ＵＧ１２）でも管理業務を行うことができるようになる。

ストレージシステム内に仮想のシステムが複数分割された既述の形態では、物理リソースを持つストレージグループはストレージシステム全体で共用されるのではなく、仮想システム内（一企業内）のユーザによっての共用に制限される。このように一部のユーザ間(企業Ａ内のユーザ間、企業Ｂ内のユーザ間)でリソースが共有される点が従来のリソース分割技術（ＳＬＰＲ）と異なる。さらに、従来のＳＬＰＲでは、ストレージシステムのフロントエンド（ポート）とバックエンド（パリティグループ）までを縦断する仮想ストレージシステムを構築できるのみであったが、本実施形態のシステムでは、ホストグループと論理ボリュームのリソースグループ、プールと論理ボリュームのリソースグループ、パリティグループのリソースグループなど、リソースを横断的に自由にグルーピングが可能になり、リソースの余剰を抑えた効率的な利用が達成できる。

仮想ストレージシステム内でリソースグループを作成することは、セキュリティ権限を有する、ストレージシステムの全体管理ユーザグループ（ＵＧ０）が実行する（図２４）参照）。企業Ａのユーザ（ＵＧ２）にセキュリティ権限を与え、企業ＡのＲＳＧを作成させることも可能ではあるが、そうすると、企業Ａ用のリソースに留まらず、企業Ｂのリソースも参照できることになってしまい、セキュリティの問題が生じる。そこで、各企業向けにリソースを分割した後も、ＵＧ０が企業用のＲＳＧの作成、削除、ＲＳＧへの物理リソースの追加・削除を行う。したがって、図２５に示すように、運用開始前のストレージシステムであって、物理リソースのグループ（ＲＳＧ１，ＲＳＧ２）が存在するものの、論理リソースがリソースグループ（ＲＳＧ３．ＲＳＧ１１，ＲＳＧ１２）に未設定のシステムにおいて、ＵＧ０のユーザは、企業Ａの運用計画や企業Ａに提案した運用に基づいて、リソースグループに論理リソースを定義・設定して、既述の仮想ストレージシステムを完成することができる。なお、外部管理端末２０は、ストレージシステムの全体管理ユーザグループ（ＵＧ０）が論理リソースのグループにアクセスするのを制限してもよい。なお、企業ＡあるいはＢだけに有効な、つまり「任意のリソースグループ」を対象とするセキュリティ権限が設定されるユーザグループがあってもよい。

次に、仮想ストレージシステム内でのリソースグループの設定についての関連する各種処理をフローチャートに基づいて説明する。図２６は、ユーザグループに権限を割り当てるためのフローチャートである。この設定はＵＧ０のユーザに許容されている。ユーザがログインしてから、外部管理端末２０がＳＶＰからユーザグループの一覧を受け取るのまでの処理(１８００〜１８１０)は、既述のフローチャート(図１８)と同じである。ログインユーザは、ストレージ管理ソフトのＧＵＩ上で、新規にユーザグループを設定・選択して、当該ユーザグループに権限を設定し、また、既存のユーザグループの権限を更新するか、既存のユーザグループに権限を新たに設定しＳＶＰに入力データを送信する(２６００)。ＳＶＰはＧＵＩで選択或いは設定されたユーザグループを権限ビットマップテーブル(図１３)から探して、権限が設定或いは更新されたビットに［１］を設定する（２６０２）。なお、ユーザグループが新たに設定された時点では、権限ビットマップの各ビットは［０］である。

ＳＶＰ１０８は、既に権限が設定されているユーザグループについて、既存の権限と整合しない権限が設定された場合には、管理端末に警告メッセージを送信する。例えば、論理リソースに対する権限が設定されているユーザグループに物理リソースに対する権限が設定される場合である。具体的に説明すると、ＵＧ１１又はＵＧ１２にシステム権限が設定されようとしている場合である。また、ユーザグループに割当てられているリソースに、設定されようとしている権限が整合しない場合も同様である。例えば、リソースグループに物理リソースが存在しないにも拘わらず、システムに関する権限が割当てられようとしている場合である。更に、具体的に説明する。既述のＬＣ権限のみを持つＵＧが物理リソースを操作するシステム権限を持つことは相応しくない。但し、リモートコピーにおける正副のＬＤＥＶにオーナ権が設定されようとする場面があるとすると、システム権限が必要となる。この場合、正副のＬＤＥＶのユーザは、図２３に即して説明すると、ＵＧ２にオーナ権の設定を依頼することになる。ただし、ＵＧ１１やＵＧ１２は、そういう操作ができるだけのストレージの知識と管理知識が乏しいこともあり、これらユーザグループへ割り当てるリソースグループが制限されている。警告メッセージとしては、「当該ＵＧはは○○ができるようになるが、本当にその権限が必要か？」と問うものになり、このメッセージを受けたユーザがイエス／ノーで回答して、処理を進めるか否かを選択させるようにする。

ＳＶＰ１０８側で最終的に権限情報が更新されると、当該情報が管理端末２０に送信されて、ＧＵＩに権限の設定情報を表示してユーザの確認を求め、ユーザがこれを確認すると権限が確定する（２６０４）。ステップ２６０４において、外部管理端末が表示するＧＵＩの画面を図４６に示す。管理ユーザがＧＵＩ画面左側でＵＧを選択すると、そのＵＧ毎に画面右側が切り替わることになる。

ユーザログインに対する処理が終了すると、次は、企業の仮想プライベートストレージシステムにＲＳＧを作成し、これをユーザグループへ割り当る処理が必要になる。この処理を図２７のフローチャートに示す。ＲＳＧの作成であるので、ログインユーザはセキュリティ権限があるユーザグループ（ＵＧ０）に属する者でなければならない。ユーザが外部管理端末２０にログインした後、ストレージ管理ソフトウェアがＳＶＰからリソースグループ及びユーザグループの一覧を受け取るまでの工程（１８００〜１８１０）は、既述の図１８の処理と同じである。

次に、ログインユーザ（ＵＧ０）は、ＧＵＩ上で、既存のＲＳＧ２から新たなＲＳＧ（ＲＳＧ１，ＲＳＧ３、ＲＳＧ１１，ＲＳＧ１２）へリソースを配分することによって設定し、ＳＶＰ１０８に入力情報を送信してＲＳＧの設定等を要求する（２７００）。

ＳＶＰ１０８はこの要求を受けると、当該要求が適切なものか否かを判定する。この判定は次の判定Ａ、判定Ｂ、そして、判定Ｃからなる。判定Ａでは、設定しようとしているＲＳＧについて、物理リソースと論理リソースとが独立しているか否かを判定する。同じＲＳＧに物理リソースと論理リソースとを共存させることは、通常は不適切である。論理リソースの複数のユーザグループ（ＵＧ１１，ＵＧ１２）に物理リソースへのアクセスを許すと、これら複数ユーザ間で物理リソースの競合が生じる。但し、例えば、ポートがストレージシステムに潤沢に実装されている場合は、ＲＳＧ１１やＲＳＧ１２にポートを含めることもでき、他のＲＳＧ／ＵＧの組によるＩ／Ｏの影響をまったく受けないような構成とすることも可能である。

判定Ｂでは、ＲＳＧの分割・作成後に、物理リソースの設定変更や物理リソースから論理リソースを定義し、これを論理リソースからなるＲＳＧに割り当てる必要があるため、仮想ストレージシステムについて全体管理権限、即ち、物理リソースに対する権限（システム権限）と論理リソースに対する権限（プロビジョニング権限）を有するユーザグループ（ＵＧ２）に全てのＲＳＧ（ＲＳＧ１，ＲＳＧ２，ＲＳＧ３，ＲＳＧ１１，ＲＳＧ１２）が割り当てられることを確認する。同じ権限を有する複数のＵＧで権限を分散させてもよい。

判定Ｃでは、論理リソースからなるリソースグループの設定形態の適性を判定する。既述の図２４は適正であることは勿論であるが、さらに、図２８のように、プール３０６及びプールボリューム３０７を、それぞれＲＳＧ１１及びＲＳＧ１２にそれぞれ専有させるようにしてもよい。

一方、図２９はリソースグループの設定が仮想プライベートストレージシステム内において適切に行われていないものの例を示す。すなわち、プール３０６及びプールボリューム３０７からなる論理リソースが特定のユーザグループ（ＵＧ１１）が専有する論理リソースグループＲＳＧ１１に所属しており、かつ、ＲＳＧ１２の仮想ボリューム３０４Ａはプール３０６に割当てられているために、ＵＧ１２(図２３)がＲＳＧ１２の論理リソースを運用するためには、ＲＳＧ１１のプール３０６・プールボリューム３０７を参照する必要からＲＳＧ１１のホストグループ３０２などの論理リソースの情報を参照できてしまいセキュリティ上問題が発生するためである。

したがって、判定Ｃ(２７０６)では、ＵＧ１１とＵＧ１２とがそれぞれ専有する論理リソースのリソースグループを備えている形態（図２８）、ＵＧ１１とＵＧ１２とがそれぞれ専有する論理リソースのリソースグループと、ＵＧ１１とＵＧ１２とが共用する論理リソースのリソースグループを備えている形態（図２４）は、この判定Ｃについて肯定される。なお、図２８の形態では、運用中に最も頻繁に発生することが想定される容量不足に対し、プールボリューム３０７の作成先のＲＳＧが複数存在することとなり（ＲＳＧ１１，ＲＳＧ１２）、ＵＧ２が実行する管理が煩雑になる懸念がある。

図２３の形態に対応する各リソースのリソースグループ構成情報テーブルは、それぞれ図３０から図３３の如くである。また、リソースグループＩＤビットマップは、既述の図１６のとおりである。一方、図２８に対応する各リソースのリソースグループ構成情報テーブルは図３４から図３７の如くである。また、リソースグループＩＤビットマップは図３８の如くである。

図２３の形態のリソースグループビットマップ(図１６)と図２８の形態のリソースグループビットマップ（図３８）との違いは、ＵＧ１１とＵＧ１２とがリソースグループＩＤビットマップの４番目のビット、すなわちＲＳＧ３を共有するかしないかである。また、図２３の形態と図２８の形態の相違はＬＤＥＶの共有の有無についても存在する。前者では、プールボリュームを共有している。前者の形態は、図１６からＵＧ１１とＵＧ１２とでＲＳＧ３を共有しており、図３０からＲＳＧ３にはＬＤＥＶ ＩＤ（=0x000004〜0x000007）が含まれる。このＬＤＥＶ ＩＤは、図３９よりプールボリュームである。以上より、ＵＧ１１とＵＧ１２は、プールボリュームであるＬＤＥＶ ＩＤ（=0x000004〜0x000007）をＲＳＧ３で共有できていると判定できる。

図２８の形態では仮想ボリュームとプールボリュームがユーザグループに専有されている。図３８から、ＵＧ１１とＵＧ１２はそれぞれＲＳＧ１１とＲＳＧ１２を占有しており、図３４からＲＳＧ１１にはＬＤＥＶ ＩＤ（=0x000000, 0x000001, 0x000004, 0x000005）が、ＲＳＧ１２には ＬＤＥＶ ＩＤ（=0x000002, 0x000003, 0x000006, 0x000007）が含まれる。図３９より、ＲＳＧ１１とＲＳＧ１２には仮想ボリュームもプールボリュームも含まれている。以上より、ＵＧ１１とＵＧ１２は、いずれも仮想ボリュームとプールボリュームとを専有している。なお、図３９において、ＤＰＶＯＬは実容量を有しない論理ボリュームであり、ベーシックＶＯＬは実容量からなる論理ボリュームであり、属性がなしとは、仮想ボリュームであることを示し、属性がプールボリュームであるとは、実容量を有する論理ボリュームがプールに容量を追加するためのものであることを示している。

図２７において、ステップ２７０６以降の処理は、図１８のステップ１８１４〜１８２２と同じである。

図２７によってＲＳＧ２から複数のリソースグループへの分割の処理の最中あるいは当該処理が完了した後に、論理リソースの作成・割り当てや各種設定が必要となる。既述のとおり、ＵＧ２には、プロビジョニング権限・システム権限・リモートコピー権限が与えられている。ＵＧ２への権限とリソースグループの割り当ては、セキュリティ権限を有するＵＧ０が図２６と図２７に従って行う。ＵＧ０により権限とリソースグループが与えられたＵＧ２は、ターゲットポート３００配下にホストグループ３０２という論理リソースを定義し、これをＲＳＧ１１やＲＳＧ１２に割り当てる。加えて、仮想ボリューム３０４をＲＳＧ１１とＲＳＧ１２に割り当てる。そして、実論理ボリューム(プールボリューム)を物理リソースのあるＲＳＧ２から切り出してＲＳＧ３に割り当てる。この一連の過程に係るフローチャートを図４０に示す。なお、外部ストレージ装置への接続やリモートコピーのためには、ポートの属性変更が必要であり、これもシステム権限を持つＵＧ２によって実行される。

図４０のフローチャートにおいて、ユーザログインから、外部管理端末がログインユーザの権限とログインユーザの管理下のリソースグループの情報を受領するまでの処理（ステップ１８００〜ステップ１８０６）は図１８と同じである。外部管理端末２０のストレージ管理ソフトウェアが、論理リソースの作成を可能とするプロビジョニング権限を確認すると、外部管理端末２０はＳＶＰ１０８のストレージ管理ソフトウェアにユーザグループとリソースグループの一覧を要求し（４０００）、ＳＶＰからその返却を受ける。この処理の詳細は、図１８のステップ１８０８とステップ１８１０と同様である。次いで、ログインユーザは、物理リソースから論理リソースを定義し、これを論理リソースグループに割当てのための入力をＧＵＩに対して行う（４００４）。外部管理端末２０は入力情報をＳＶＰ１０８に送信する。

この送信を受けたＳＶＰは、入力データが適切なものかを、判定Ｄ〜判定Ｇを行うことによって確認する。判定Ｄ（４００６）は、ログインユーザが属するユーザグループの権限と割り当てられたリソースグループによって論理リソースの作成が可能かということに関する判定であり、判定Ｅ（４００８）は、論理リソースを物理リソースから切り出す上で、物理リソースの使用に偏りがあるかないかの判定であり、判定Ｆ（４０１０）は、論理リソースが物理リソースのリソースグループに割当てられないことの判定であり、判定Ｇ（４０１２）は仮想ストレージシステムの形態が不正なもの（例えば、図２９の形態）でないことの判定である。判定後の処理は、図１８、図２７のフローチャートと同じである。以下、各判定についての詳細を説明する。

判定Ｄ
ＵＧ２は、図１６のリソースグループＩＤビットマップより、ＲＳＧ１、ＲＳＧ２、ＲＳＧ３、ＲＳＧ１１、ＲＳＧ１２に対して操作権を有する。物理リソースであるＲＳＧ２(パリティグループを所有)がＵＧ２に割り当てられていることから論理リソースである論理ボリューム(ＬＤＥＶ)の作成が可能であり、さらに、ＲＳＧ１(ターゲットポートを所有)が割り当てられていることから、同じく論理リソースであるホストグループが ホストグループを作成することができる。ログインユーザがＵＧ２に属する場合には、判定Ｄが肯定される。

ＵＧ１１、ＵＧ１２もプロビジョニング権限を持つため、権限の観点からはＬＤＥＶやホストグループなどの論理リソースを作成する操作は許容されている。しかしながら、図１６のリソースグループＩＤビットマップから、物理リソースであるＲＳＧ１やＲＳＧ２がＵＧ１１とＵＧ１２に割り当てられていないため、実際には論理リソースを作成することができない。したがって、ログインユーザがＵＧ１１、又はＵＧ１２に属すると、判定Ｄは否定される。

ＵＧ１１やＵＧ１２の操作において、ＧＵＩにＵＧ／ＲＳＧが取得された時点でＲＳＧ１やＲＳＧ２の物理リソースを表示しないことにより、ＬＤＥＶやホストグループを作成しようとするＧＵＩ操作を当初から抑止してもよい。ただし、ＧＵＩのみならず、ログインユーザがＣＬＩ(コマンドラインインタフェース)を使用して各種リソースを作成することができる場合は、外部管理端末やストレージシステムでその可否をチェックする必要がある)。この場合には、ＳＶＰにおける判定Ｄのステップは省略される。

判定Ｅ
例えば、複数のターゲットポートがあるにも関わらず、特定のポートばかりにホストグループが設定されると、当該ポートに負荷が集中し、他のポートとの負荷分散が達成されない。また、複数のパリティグループがあるにも拘わらず、特定のパリティグループにのみからＬＤＥＶが作成されていても同様である。判定Ｅはこのような偏りが無いことを確かめている。この判定には、ＳＶＰ１０８が、共有メモリ１０２にある、ターゲットポートやパリティグループの稼働率等の性能情報を参照することが利用される。また、これらの性能情報は、ストレージ管理ソフトウェアのＧＵＩでも確認できるため、ＧＵＩで適切なリソースを選択してもよい。この場合における判定はログインユーザである、ＵＧ２に属するユーザによって行われる。

判定Ｆ
ログインユーザが、物理リソースのグループであるＲＳＧ２(パリティグループを所有)から論理ボリュームを定義し、これを同じくＲＳＧ２に所属させることもできるが、論理リソースのみを扱うＵＧ１１やＵＧ１２はＲＳＧ２を割り当てられていないため、論理ボリュームを使用することができなくなる。従って、このような論理リソースの設定要求は、不可能である。

判定Ｇ
次の（１）又は（２）のいずれかの成立を判定する。（１）ＵＧ１１とＵＧ１２が、それぞれ専有する論理リソースのＲＳＧのみを持つ場合、それぞれのＲＳＧにホストグループ、仮想ボリューム、プールボリュームが割当てられている。（２）ＵＧ１１とＵＧ１２が、それぞれ専有する論理リソースのＲＳＧと、互いに共用する、論理リソースのＲＳＧとを有する場合、前者にはホストグループと、仮想ボリュームが割当てられ、後者にはプールボリュームが割当てられていること。（１）及び（２）によれば、ＵＧ１１及びＵＧ１２に、ダイナミックプロビジョニングを可能にしつつ、セキュリティを確保させることができる。

ＲＳＧの分割とリソースの割り当てが完了すると、ログインユーザ（ＵＧ２）は、ＳＶＰ１０８を介して、ホスト計算機の登録、そして、ＬＵ（ロジカルユニット）とホスト計算機との間のパス定義を行い、次いで、企業Ａ用の仮想ストレージシステムを運用状態に移行する。ＵＧ１１とＵＧ１２も、それぞれプロビジョニング権限を有するため、権限の範囲内でホスト計算機の登録・ＬＵ（ロジカルユニット）のパス定義が可能である。この時、ログインユーザは、仮想ボリュームが使用するプールをＲＳＧ３から選択する（図２４）。これにより、ＲＳＧ１１及びＲＳＧ１２はホスト計算機からのリード・ライトＩ／Ｏを受け付けることができる。

ＵＧ１１とＵＧ１２は、ローカルコピー権限で自身のＲＳＧ内でのローカルコピーを実施することができる。リモートコピーについては、リモートコピーペアの作成等、異なるストレージシステム間を跨る諸設定は全体管理のためのユーザグループ（ＵＧ０）によって実行される。コピー処理の開始・終了指示だけは、ＵＧ１１及びＵＧ１２がリモートコピー権限にて許容されている。

既述の実施形態では、リソースグループの作成の際、管理ユーザは外部管理端末２０のＧＵＩを介して、複数の設定情報を順次入力したが、ＳＶＰ１０８がリソースグループの構成に関するポリシーを既述したファイルを予め登録しておき、ユーザの入力の適否をポリシーファイルに基づいて判定してもよい。

以下にポリシーファイルの例を示す。
（Ａ）図２４のリソースルグル―プを実現するためのポリシー
（１）物理リソース（パリティグループ）：複数ユーザ（ユーザグループ）間で共有する。
（２）物理リソース（ポート）：複数ユーザ間で共有する。
（３）論理リソース（ホストグループ）：該当するユーザが専有する。
（４）論理リソース（ＬＤＥＶ）
仮想ボリューム：使用する。
：該当するユーザが専有する。
プールボリューム（プール）：複数ユーザ間で共有する。

（Ｂ）図２８のリソースルグル―プを実現するためのポリシー
（１）物理リソース（パリティグループ）：複数ユーザ（ユーザグループ）間で共有する。
（２）物理リソース（ポート）：複数ユーザ間で共有する。
（３）論理リソース（ホストグループ）：ユーザの専有。
（４）論理リソース（ＬＤＥＶ）
仮想ボリューム：使用する。
：ユーザの専有。
プールボリューム（プール）：ユーザの専有。

次に、図１に示す計算機システムの動作を図４１から図４４のフローチャートに基づいて説明する。既述のフローチャートは図２３の形態に対応するのに対して、図４１から図４４は、図２３以外の形態にも適用可能な汎用的なフローチャートである。これらのフローチャートは連続する処理を示している。ユーザのログインセッション５０００に基づいてＳＶＰ１０８がログインセッションからリクエストを取得する（４１００）。ここでリクエストとは、権限毎に許容された操作のことである。このリクエストを受けたＳＶＰの管理ソフトウェアはログインユーザの実行権限のチェック（４１０２）を行い、このチェックを否定するとフローチャートを終了し（４００４）、このチェックを許容すると、次の処理に進む。このチェックは次のようにして行われる。ＳＶＰは、図１５の権限テーブルを参照して、リクエストの操作内容から対応する権限を抽出する（４１０６）。ＳＶＰ１０８はログインユーザに割当てられた権限ビットマップ（図１３）を参照して、リクエストに対応権限が含まれているか確認する（４１０２）。ＳＶＰは、含まれていれば実行権限ありと判断してリソースグループアクセスチェックに移行する。なければ、図４３のフローチャート（４３００）にジャンプする。

リソースグループアクセスチェック処理（４１０８）において、先ず、ＳＶＰはリクエストに含まれるリソースを抽出し（４１０６）、リソースが抽出されると、当該リソースが所属するリソースグループＩＤを，ＳＶＰにキャッシュされている情報から特定する。ＳＶＰがこの情報をキャッシュしていない場合には、リソースグループＩＤの通知をストレージシステムに要求する（４１１０）。ストレージシステムはこの要求を取得すると（４１１２）、共有メモリ１０２Ａの構成情報テーブル２０２Ｂを参照して、リソースグループＩＤを取得してこれをＳＶＰに通知する（４１１４）。ＳＶＰはリソースグループＩＤを取得して（４１１６）、このリソースグループに対して権限があるか否かを判定し（４１１８）、これを肯定判定すると、図４２排他制御処理に進む。これを否定判定すると処理を終了する（４１２０）。

図４２は排他制御処理を説明するフローチャートである。この排他制御処理とは、リソースグループアクセスチェックの際に抽出した、リクエストに含まれるリソースが所属するリソースグループ全てに対して、リクエスト送信者のログインセッションＩＤをオーナのログインセッションＩＤとして認識することによってロック状態にする（図９参照）。そこで、ＳＶＰは排他制御要求を形成し（４２００）、この要求をストレージシステム１０に送信する（４２０２）。ストレージシステムがこの要求を受信すると（４２０４）、排他制御要求の対象であるリソースグループに対して排他制御処理を試み（４２０６）、その結果をＳＶＰに通知する（４２０８）。ＳＶＰは排他制御処理結果を受信すると（４２１０）、排他制御処理結果が正常化否かを判定する（４２１２）。排他制御処理すべき複数のリソースグループの全てをロックできなければエラーと判定する。エラー判定があると、ＳＶＰはフローチャートを終了する。

図４３はコミット処理及び排他制御のアンロック処理のフローチャートである。ロック処理が完了すると、ＳＶＰは既述のポリシー設定に従ってリクエストに判定ロジックを適用する。この判定を肯定するとリクエストをコミットして（４３００）、ストレージシステムにリクエストを送信する。次いで、ストレージシステムがリクエストを受信して（４３０２）、リクエストに基づいて制御処理を実行し（４３０４）、実行結果をＳＶＰに通知する（４３０６）。ＳＶＰはこの通知を受信すると（４３０８）、ロック状態としたリソースグループのアンロックをストレージシステムに要求する（４３１０）。ストレージシステムはこの要求を受信すると（４３１２）、アンロック処理を行い（４３１４）、その結果をＳＶＰに通知する（４３１６）。ＳＶＰはアンロック処理の結果を受信する（４３１８）。

次に、ＳＶＰはストレージシステムからの実行結果に含まれる戻り値についてフィルタリング処理を行う。すなわち、ＳＶＰは、戻り値に含まれるリソースを抽出し（４４００）、リソースがあると判定すると（４４０２）、当該リソースが所属するリソースグループＩＤをストレージシステムに要求する（４４０４）。リソースが無いと判定するとフローチャートを終了する（４４０３）。ストレージシステムはこの要求を受信すると（４４０６）、リソース構成情報テーブル２０２Ｂを参照してリソースグループＩＤを通知する（４４０８）。ＳＶＰはリソースグループＩＤを受信すると（４４１０）、このリソースに対してアクセス権限があるか否かを判定し（４４１２）、リソースグループＩＤがリソースグループＩＤビットマップ（図１６）に含まれているか確認し、含まれていればリソースグループＩＤを表示リストに加えて（４４１６）、実行結果を外部管理端末のＧＵＩに通知し、含まれていなければリソースは表示されない（４４１４）。

既述の説明において、ユーザがその権限と割当てられているリソースグループとによってストレージシステムに実行できる操作として、ダイナミックプロビジョニング（ＬＤＥＶの作成など）、ローカルコピー、リモートコピーについて説明したが、これにかぎられない。例えば、データの最適配置がある。すなわち、例えば、仮想プライベートストレージは、オンラインボリュームのリソースグループ、アーカイブボリュームのリソースグループ、オンラインボリューム用の高品質のハードディスクドライブ（ＦＣドライブ）のリソースグループ、アーカイブ用のハードディスクドライブ（ＡＴＡドライブ、ＳＡＴＡドライブなど）のリソースグループを備えていなければならず、また、データの最適配置の権限を有するユーザグループには、アーカイブ用のリソースグループを備えていなければならない。この権限があっても、関連するリソースグループを備えていなければアーカイブ用データをアーカイブ用ボリュームにオンラインボリュームからマイグレーションすることができない。

１０ ストレージシステム
１２Ａ，１２Ｂ ホスト計算機
１６ ストレージコントローラ
１８ ストレージドライブ
２０ 外部管理端末
１０８ ＳＶＰ
３０２ ホストグループ
３０４ 仮想ボリューム
３０６ プール
３０７ プールボリューム
３０８ パリティグループ

Claims (8)

1. ホスト計算機からのストレージデバイスに対するリードアクセス又はライトアクセスを制御するストレージシステムと、前記ストレージシステムの複数のリソースと前記ストレージシステムを共用する複数のユーザとを管理する管理装置と、を備え、
   前記ストレージシステムは、
   前記複数のリソースがグループ化されることによって定義される複数のリソースグループと、
   当該複数のリソースグループの管理情報と、当該複数のリソースと前記複数のリソースグループとの対応情報と、を格納する記憶領域と、
   前記複数のユーザがグループ化されることによって定義され、それぞれ前記複数のリソースグループの少なくとも一つに割り当てられる複数のユーザグループと、を備え、
   前記管理装置は、前記複数のユーザの少なくとも一のユーザのログインに基づいて、当該ユーザが属する前記ユーザグループに付与された権限で許容される操作を、前記ストレージシステムに、前記ユーザグループに割り当てられた前記リソースグループに対して実行させる、計算機システムであって、
   前記ストレージシステムが複数の仮想ストレージシステムに分割され、
   当該複数の仮想ストレージシステムのそれぞれに前記複数のユーザが設定され、
   前記複数の仮想ストレージシステムのそれぞれは、同一のリソースグループに論理リソースと物理リソースとが共存しないように、前記ストレージシステムから割当てられた論理リソースのみからなる第１のリソースグループと、物理リソースを有する第２のリソースグループと、に分割され、
   前記第１のリソースグループの前記論理リソースは前記第２のリソースグループから取り出し物理リソースから設定され、
   前記複数のユーザグループのうち、第１のユーザグループが前記第１のリソースグループに割当てられ、
   第２のユーザグループが前記第１のリソースグループと前記第２のリソースグループに割当てられて、論理リソース及び物理リソースを複数のユーザグループ間で共有させる、計算機システム。
2. 前記第１のリソースグループは前記論理リソースからなり、
   前記第２のリソースグループは前記物理リソースからなり、
   前記第１のユーザグループと前記第２のユーザグループには前記論理リソースを作成する権限が付与され、
   前記第１のリソースグループへ追加される新たな論理リソースは、前記第２のリソースグループの前記物理リソースから設定される、請求項１記載の計算機システム。
3. 前記複数の仮想ストレージシステムのそれぞれは、少なくとも、物理リソースからなるリソースグループを備え、当該物理リソースには、前記ホスト計算機に対するポート、前記ストレージデバイスのメモリリソースが含まれている、請求項１記載の計算機システム。
4. 前記第１のリソースグループは、それぞれ前記論理リソースとして、
   記憶容量が仮想化され、前記ホスト計算機からアクセスされる仮想ボリュームと、
   前記仮想ボリュームの記憶領域を構成するプールと、
   前記ストレージデバイスの記憶領域から前記プールに割当てられるプールボリュームと、
   を有し、
   前記第１のユーザグループは前記第２のリソースグループに割当てられていない、請求項１記載の計算機システム。
5. 前記第１のリソースグループは、
   請求項４記載の仮想ボリュームを有する第３のリソースグループと、
   請求項４記載の前記プール及び前記プールボリュームを有する第４のリソースグループを有し、
   前記第４のリソースグループは前記第１のユーザグループと第３のユーザグループとに割当てられている、請求項２記載の計算機システム。
6. 前記複数のユーザグループの一つとして、前記ストレージシステムに管理権限を有する第１のユーザグループが存在し、
   前記第１のユーザグループは、前記ストレージシステムのリソースグループを分割して、分割したそれぞれのリソースグループに前記仮想ストレージシステムを設定する権限と、当該仮想ストレージシステムのリソースグループをさらに複数のリソースグループに分割する権限とを有し、当該仮想ストレージシステムの当該複数のリソースグループに割り当てられている、請求項１記載の計算機システム。
7. 前記複数の仮想ストレージシステムのそれぞれにおいて、前記リソースグループの全てが同一の前記ユーザグループに割当てられ、当該ユーザグループに前記全てのリソースグループに対する前記権限が設定されている、請求項１記載の計算機システム。
8. ホスト計算機からのストレージデバイスに対するリードアクセス又はライトアクセスを制御するストレージシステムと、前記ストレージシステムの複数のリソースと前記ストレージシステムを共用する複数のユーザとを管理する管理装置と、を備え、
   前記ストレージシステムが複数の仮想ストレージシステムに分割され、
   当該複数の仮想ストレージシステムのそれぞれに前記複数のユーザが設定され、
   前記複数の仮想ストレージシステムのそれぞれは、同一のリソースグループに論理リソースと物理リソースとが共存しないように、前記ストレージシステムから割当てられた論理リソースのみからなる第１のリソースグループと、物理リソースを有する第２のリソースグループと、に分割され、
   前記第１のリソースグループの前記論理リソースは前記第２のリソースグループから取り出し物理リソースから設定され、
   前記複数のユーザグループのうち、第１のユーザグループが前記第１のリソースグループに割当てられ、
   第２のユーザグループが前記第１のリソースグループと前記第２のリソースグループに割当てられて、論理リソース及び物理リソースを複数のユーザグループ間で共有させる計算機システムの制御方法であって、
   前記管理装置は、
   前記複数のリソースをグループ化して複数のリソースグループを設定し、
   当該複数のリソースグループの管理情報と、当該複数のリソースと前記複数のリソースグループとの対応情報と、を前記ストレージシステムに登録し、
   前記ユーザに対するユーザグループを定義して、当該ユーザグループに権限を設定し、
   前記ユーザグループに前記複数のリソースグループの中から少なくとも一つのリソースグループを割り当て、
   前記管理装置にログインしたユーザは、当該ユーザが属するユーザグループの前記権限に許容された操作を前記ユーザグループに割当てられた前記リソースグループに対して実行する、計算機システムの制御方法。