図面 (/)

技術 電子的な保護対象に要求される保護能力で該保護対象を保護する記憶制御装置

出願人 株式会社日立製作所
発明者 阿知和恭介
出願日 2006年12月20日 (14年5ヶ月経過) 出願番号 2006-342279
公開日 2008年7月3日 (12年11ヶ月経過) 公開番号 2008-152695
状態 未査定
技術分野 エラー時の再試行 ハードウェアの冗長性 外部記憶装置との入出力 検索装置 計算機におけるファイル管理
主要キーワード チェック処理プログラム 設定制御プログラム ファイル要素 閉塞処理 消費容量 サブエントリ ディレクトリ管理テーブル ディスク型記憶装置
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2008年7月3日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

ストレージシステムに備えられる複数のストレージデバイス保護能力がそれぞれ異なっていても、電子的な保護対象に要求される保護能力で該保護対象を保護する。

解決手段

記憶制御装置に、保護制御部を備え、記憶制御装置の記憶資源に、保護能力の異なる複数のストレージデバイスにそれぞれ関連付けられた複数の異なる保護能力値を含んだ情報であるストレージデバイス管理情報を記憶させる。保護制御部は、記憶資源に記憶されているストレージデバイス管理情報を用いて、電子的な保護対象に要求される保護能力である要求保護能力値を満たすように、該保護対象を前記複数のストレージデバイスのうちの一以上のストレージデバイスに格納する。

概要

背景

複数のストレージデバイスを備えるストレージシステムとして、例えば、特許文献1及び2に開示のシステムが知られている。特許文献1には、それぞれ仮想プールを有する複数のCAS(Content
Addressable Storage)システムがあり、仮想プールへのI/Oの割り振りに関する技術が開示されている。特許文献2には、改竄防止期限内にデータ移行を行うことが開示されている。

米国公開特許明細書2006/0031653号
特開2006−293864号公報

概要

ストレージシステムに備えられる複数のストレージデバイスの保護能力がそれぞれ異なっていても、電子的な保護対象に要求される保護能力で該保護対象を保護する。記憶制御装置に、保護制御部を備え、記憶制御装置の記憶資源に、保護能力の異なる複数のストレージデバイスにそれぞれ関連付けられた複数の異なる保護能力値を含んだ情報であるストレージデバイス管理情報を記憶させる。保護制御部は、記憶資源に記憶されているストレージデバイス管理情報を用いて、電子的な保護対象に要求される保護能力である要求保護能力値を満たすように、該保護対象を前記複数のストレージデバイスのうちの一以上のストレージデバイスに格納する。

目的

従って、本発明の一つの目的は、ストレージシステムに備えられる複数のストレージデバイスの保護能力がそれぞれ異なっていても、電子的な保護対象に要求される保護能力で該保護対象を保護することにある。

効果

実績

技術文献被引用数
0件
牽制数
1件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

保護能力の異なる複数のストレージデバイスにそれぞれ関連付けられた複数の異なる保護能力値を含んだ情報であるストレージデバイス管理情報を記憶する記憶資源と、前記記憶資源に記憶されているストレージデバイス管理情報を用いて、電子的な保護対象に要求される保護能力である要求保護能力値を満たすように、該保護対象を前記複数のストレージデバイスのうちの一以上のストレージデバイスに格納する保護制御部とを備える記憶制御装置

請求項2

前記一以上のストレージデバイスは、前記保護対象の要求保護能力値以上になる合計となる一以上の保護能力値にそれぞれ対応している、請求項1記載の記憶制御装置。

請求項3

ストレージデバイスの指定と該ストレージデバイスに関連付ける保護能力値の指定とを、前記記憶制御装置の外部の端末である外部端末から受け付け、前記ストレージデバイス管理情報に、該外部端末から指定されたストレージデバイスに関連付ける保護能力値を含める保護能力値設定部を更に備える、請求項1記載の記憶制御装置。

請求項4

前記複数のストレージデバイスの少なくとも一つに記憶されている保護対象の指定と該保護対象に関連付ける要求保護能力値の指定とを、前記記憶制御装置の外部の端末である外部端末から受け付け、該外部端末から指定された保護対象に前記指定された要求保護能力値を関連付ける要求保護能力値設定部を更に備える、請求項1記載の記憶制御装置。

請求項5

前記保護制御部は、保護対象の要求保護能力値とストレージデバイスの保護能力値とのいずれかが変更された場合、要求される保護能力値が満たされなくなった保護対象の有無を判断し、要求される保護能力値を満たさなくなった保護対象を検出したならば、該保護対象に要求される保護能力値を満たすように、該保護対象を、前記複数のストレージデバイスのうちの別のストレージデバイスにコピーする、請求項1記載の記憶制御装置。

請求項6

前記変更された場合とは、ストレージデバイスの保護能力値が0にされた場合である、請求項5記載の記憶制御装置。

請求項7

前記保護制御部は、要求される保護能力値を満たさなくなった全ての保護対象についてコピーが完了した場合、コピー完了を表す情報を、前記記憶制御装置の外部の端末である外部端末に送信する、請求項6記載の記憶制御装置。

請求項8

前記ストレージデバイス管理情報は、前記複数のストレージデバイスのうちのどの二以上のストレージデバイスにより排他グループが構成されているかを表す情報要素を含み、前記保護制御部は、要求される保護能力値を満たさなくなった保護対象のコピー先として、該保護対象を記憶しているストレージデバイスを含んだ排他グループ内のストレージデバイスとは異なる別のストレージデバイスを選択し、選択した別のストレージデバイスに該保護対象をコピーする、請求項5記載の記憶制御装置。

請求項9

前記複数のストレージデバイスのうちのどの二以上のストレージデバイスの指定と排他グループ作成指示とを、前記記憶制御装置の外部の端末である外部端末から受け付け、該外部端末からのグループ作成指示に従って、指定された二以上のストレージデバイスで構成された排他グループを表す情報要素を前記ストレージデバイス管理情報に含める排他グループ作成部を更に備える、請求項8記載の記憶制御装置。

請求項10

前記複数のストレージデバイスの各々は、一以上の物理的なストレージデバイスを基に提供される論理的なストレージデバイスであり、前記排他グループは、複数の物理的なストレージデバイスを備えたストレージシステム内の複数の論理的なストレージデバイスで構成されたグループ、或いは、RAIDグループにより提供される複数の論理的なストレージデバイスで構成されたグループであり、前記RAIDグループは、複数の物理的なストレージデバイスのうちの二以上の物理的なストレージデバイスによりRAIDで構成されたグループである、請求項8記載の記憶制御装置。

請求項11

前記保護対象は、ファイル及びディレクトリのうちの少なくとも一方であり、前記要求保護能力値は、ファイル、ディレクトリ、或いはそのグループ単位で関連付けられる、請求項1記載の記憶制御装置。

請求項12

前記保護制御部が、上位装置から送信されたファイルを受信し、該ファイルに要求保護能力値が関連付けられていない場合、ライト先のディレクトリの要求保護能力値を、該ファイルに関連付ける、請求項11記載の記憶制御装置。

請求項13

前記保護制御部は、第一のケースの場合には、多くのストレージデバイスに同一の保護対象を格納し、第二のケースの場合には、第一のケースに比して少ない数のストレージデバイスに同一の保護対象を格納する、請求項1記載の記憶制御装置。

請求項14

前記第一のケースとは、消費記憶容量の節約よりも冗長性重視することであり、第二のケースとは、冗長性よりも消費記憶容量の節約を重視することである、請求項13記載の記憶制御装置。

請求項15

前記保護制御部は、保護対象の要求保護能力値とストレージデバイスの保護能力値とのいずれかが変更された場合、該保護対象を記憶している二以上のストレージデバイスのうちの少なくとも一つから該保護対象を消去しても該保護対象の要求保護能力値を満たす記憶が維持できるならば、該少なくとも一つのストレージデバイスから該保護対象を消去する、請求項1記載の記憶制御装置。

請求項16

前記記憶制御装置は、複数のノード、或いは、複数のノードと複数のストレージデバイスとを備えたストレージシステムである、請求項1記載の記憶制御装置。

請求項17

前記ストレージデバイス管理情報は、前記複数のストレージデバイスのうちのどの二以上のストレージデバイスにより排他グループが構成されているかを表す情報要素を含み、前記保護制御部は、上位装置から送信された保護対象を受信し、該保護対象の要求保護能力値以上になる合計となる二以上の保護能力値にそれぞれ対応し前記排他グループの被らない二以上のストレージデバイスに、該保護対象をライトし、該保護対象の要求保護能力値とストレージデバイスの保護能力値とのいずれかが変更された場合、要求される保護能力値が満たされなくなった保護対象の有無を判断し、要求される保護能力値を満たさなくなった保護対象を検出したならば、該保護対象に要求される保護能力値を満たすように、該保護対象を、前記複数のストレージデバイスのうちの、該保護対象を記憶しているストレージデバイスと前記排他グループの被らない別のストレージデバイスにコピーする、請求項1記載の記憶制御装置。

請求項18

保護能力の異なる複数のストレージデバイスにそれぞれ関連付けられた複数の異なる保護能力値を含んだ情報であるストレージデバイス管理情報から、各ストレージデバイスの各保護能力値を識別し、電子的な保護対象に要求される保護能力である要求保護能力値を満たすように、該保護対象を前記複数のストレージデバイスのうちの一以上のストレージデバイスに格納する、記憶制御方法

請求項19

保護対象の要求保護能力値とストレージデバイスの保護能力値とのいずれかを変更し、要求される保護能力値が満たされなくなった保護対象の有無を判断し、要求される保護能力値を満たさなくなった保護対象を検出したならば、該保護対象に要求される保護能力値を満たすように、該保護対象を、前記複数のストレージデバイスのうちの別のストレージデバイスにコピーする、請求項18の記憶制御方法。

請求項20

保護対象の要求保護能力値とストレージデバイスの保護能力値とのいずれかの変更では、リプレース対象のストレージデバイスの保護能力値を0に変更する、請求項19記載の記憶制御方法。

技術分野

0001

本発明は、データなどの電子的な保護対象を保護するための記憶制御に関する。

背景技術

0002

複数のストレージデバイスを備えるストレージシステムとして、例えば、特許文献1及び2に開示のシステムが知られている。特許文献1には、それぞれ仮想プールを有する複数のCAS(Content
Addressable Storage)システムがあり、仮想プールへのI/Oの割り振りに関する技術が開示されている。特許文献2には、改竄防止期限内にデータ移行を行うことが開示されている。

0003

米国公開特許明細書2006/0031653号
特開2006−293864号公報

発明が解決しようとする課題

0004

ところで、例えば、RAIN(Redundant Array of Independent Nodes)型のストレージシステムが知られている。この種のストレージシステム(以下、RAINシステム)は、複数のノードで構成され、各ノードには、ディスク型記憶装置(例えばハードディスクドライブ)が内蔵されている。ノードに対するホストからのファイルレベルのデータ(例えばファイル或いはディレクトリ)は、複数のノードのうちのk個のノードにそれぞれ内蔵されているk個のディスク型記憶装置(以下、ディスク装置)に記憶される(kは2以上の整数で一定の値)。言い換えれば、データの多重度がkになる。或るノードが壊れた場合、その或るノードが保持していたデータの多重度がkより低くなってしまうが、RAINシステムでは、冗長度の下がってしまったデータが、そのデータを記憶している別のノードからまた別のノードにコピーされ、それにより、RAINシステムに記憶されているデータの多重度をkに戻すことができる。

0005

RAINシステムでは、複数のノードにそれぞれ内蔵されている複数のディスク装置の種類は同じであることが多い。なぜなら、それら複数のディスク装置の種類が異なっていると、一定の多重度nでデータを記憶しても、データがどのノードのディスク装置に記憶されるかによって、データ保護信頼性に差が出てしまうおそれがあるからである。言い換えれば、RAINシステムの課題の一つとして、複数のディスク装置の種類が異なると、要求される保護能力でデータを保護することが必ずしもできないということがある。

0006

従って、本発明の一つの目的は、ストレージシステムに備えられる複数のストレージデバイスの保護能力がそれぞれ異なっていても、電子的な保護対象に要求される保護能力で該保護対象を保護することにある。

0007

本発明の他の目的は、後述の説明から明らかになるであろう。

課題を解決するための手段

0008

記憶制御装置に、保護制御部を備え、記憶制御装置の記憶資源に、保護能力の異なる複数のストレージデバイスにそれぞれ関連付けられた複数の異なる保護能力値を含んだ情報であるストレージデバイス管理情報を記憶させる。保護制御部は、記憶資源に記憶されているストレージデバイス管理情報を用いて、電子的な保護対象に要求される保護能力である要求保護能力値を満たすように、該保護対象を前記複数のストレージデバイスのうちの一以上のストレージデバイスに格納する。

発明を実施するための最良の形態

0009

本発明の幾つかの実施形態を説明する。その幾つかの実施形態を詳細に説明する前に、概要を記載する。

0010

記憶制御装置に備えられた保護制御部は、例えば、後述のホストライ処理プログラム、ノードライト処理プログラム及びプロテクトチェック処理プログラムを実行するプロセッサとすることができる。保護制御部は、保護対象A1の要求保護能力値以上になる合計となる二以上の保護能力値にそれぞれ対応している複数のストレージデバイスに、保護対象A1を格納する。これにより、保護対象A1が一以上のストレージデバイスに格納される(例えば多重化される)ことになる。

0011

記憶制御装置に、保護能力設定部を更に備えることができる。保護能力設定部は、ストレージデバイスの指定と該ストレージデバイスに関連付ける保護能力値の指定とを、記憶制御装置の外部の端末である外部端末から受け付け、ストレージデバイス管理情報に、該外部端末から指定されたストレージデバイスに関連付ける保護能力値を含めることができる。外部端末としては、ホスト、管理端末(management console)などとすることができる。

0012

記憶制御装置に、要求保護能力値設定部を更に備えることができる。要求保護能力値設定部は、複数のストレージデバイスの少なくとも一つに記憶されている保護対象の指定と該保護対象に関連付ける要求保護能力値の指定とを、外部端末から受け付け、該外部端末から指定された保護対象に該指定された要求保護能力値を関連付けることができる。

0013

保護制御部は、保護対象の要求保護能力値とストレージデバイスの保護能力値とのいずれかが変更された場合、要求される保護能力値が満たされなくなった保護対象の有無を判断し、要求される保護能力値を満たさなくなった保護対象を検出したならば、該保護対象A2に要求される保護能力値を満たすように、該保護対象A2を、該保護対象A2を既に記憶しているストレージデバイスA1とは別のストレージデバイスA2にコピーすることができる。なお、ここで、上記変更された場合とは、ストレージデバイスの保護能力値が0にされた場合である。具体的には、例えば、リプレース対象のストレージデバイスの保護能力値が0にされる。保護能力値“0”は、外部端末から指定されても良いし、外部端末からリプレース対象(例えば、ストレージサブシステムRAIDグループなど)が指定された場合に、該リプレース対象に属するストレージデバイスを判別し、判別されたストレージデバイスの保護能力値を“0”に変更しても良い。保護制御部は、要求される保護能力値を満たさなくなった全ての保護対象についてコピーが完了した場合、コピー完了を表す情報を外部端末に送信することができる。外部端末が、コピー完了を表示することができる。

0014

より具体的には、例えば、以下の流れで、ストレージデバイスをリプレースすることにより、保護対象A2の要求保護能力値を維持することができる。ここでは、記憶制御装置は、複数のノードで構成されているとする。
・人間が、新たなストレージデバイスを古いストレージデバイスが接続されているノードAに接続する。
・人間が、外部端末を用いて、古いストレージデバイスの保護能力値を0に設定する。
・そうなると、古いストレージデバイスに格納されている保護対象A2の要求保護能力値が満たされなくなる。そのため、ノードAが、セルフヒーリング処理を行う。具体的には、ノードAが、古いストレージデバイス内の保護対象をリードし、新しいストレージデバイス(又は、他のノード)にコピーする。
・セルフヒーリング処理が完了したならば、該完了を検知したノードが、外部端末に、完了を通知し、外部端末が、完了を表示する。これにより、人間は、セルフヒーリング処理の終了を知ることができる。その後に、人間が、古いストレージデバイスを外す。

0015

さて、前述したストレージデバイス管理情報は、複数のストレージデバイスのうちのどの二以上のストレージデバイスにより排他グループが構成されているかを表す情報要素を含む。保護制御部は、要求される保護能力値を満たさなくなった保護対象のコピー先として、該保護対象を記憶しているストレージデバイスを含んだ排他グループ内のストレージデバイスとは異なる別のストレージデバイスを選択し、選択した別のストレージデバイスに該保護対象をコピーすることができる。

0016

記憶制御装置は、排他グループ作成部を更に備えることができる。排他グループ作成部は、複数のストレージデバイスのうちのどの一以上のストレージデバイスの指定と排他グループ作成指示とを、前記記憶制御装置の外部の端末である外部端末から受け付け、該外部端末からのグループ作成指示に従って、指定された一以上のストレージデバイスで構成された排他グループを表す情報要素を前記ストレージデバイス管理情報に含めることができる。

0017

複数のストレージデバイスの各々は、一以上の物理的なストレージデバイスを基に提供される論理的なストレージデバイスとすることができる。排他グループは、複数の物理的なストレージデバイスを備えたストレージシステム内の複数の論理的なストレージデバイスで構成されたグループ、或いは、RAIDグループにより提供される複数の論理的なストレージデバイスで構成されたグループとすることができる。RAIDグループは、複数の物理的なストレージデバイスのうちの二以上の物理的なストレージデバイスによりRAIDで構成されたグループである。

0018

保護対象は、ファイル及びディレクトリのうちの少なくとも一方であり、要求保護能力値は、ファイル、ディレクトリ、或いはそのグループ単位で関連付けられるとすることができる。保護制御部が、上位装置から送信されたファイルを受信し、該ファイルに要求保護能力値が関連付けられていない場合、ライト先のディレクトリの要求保護能力値を、該ファイルに関連付けることができる。

0019

保護制御部は、第一のケースの場合には、多くのストレージデバイスに同一の保護対象を格納し、第二のケースの場合には、第一のケースに比して少ない数のストレージデバイスに同一の保護対象を格納することができる。例えば、第一のケースとは、消費記憶容量の節約よりも冗長性(redundancy)を重視することであり、第二のケースとは、冗長性よりも消費記憶容量の節約を重視することである。

0020

また、保護制御部は、保護対象の要求保護能力値とストレージデバイスの保護能力値とのいずれかが変更された場合、該保護対象を記憶している二以上のストレージデバイスのうちの少なくとも一つから該保護対象を消去しても該保護対象の要求保護能力値を満たす記憶が維持できるならば、該少なくとも一つのストレージデバイスから該保護対象を消去することができる。

0021

記憶制御装置は、複数のノード、或いは、複数のノードと複数のストレージデバイスとを備えたストレージシステムとすることができる。

0022

上述した各部は、ハードウェアコンピュータプログラム又はそれらの組み合わせ(例えば一部をコンピュータプログラムにより実現し残りをハードウェアで実現すること)により構築することができる。コンピュータプログラムは、所定のプロセッサに読み込まれて実行される。また、コンピュータプログラムがプロセッサに読み込まれて行われる情報処理の際、適宜に、メモリ等のハードウェア資源上に存在する記憶域が使用されてもよい。また、コンピュータプログラムは、CD−ROM等の記録媒体から計算機インストールされてもよいし、通信ネットワークを介して計算機にダウンロードされてもよい。また、ストレージデバイスは、物理的であっても論理的であっても良い。物理的なストレージデバイスとしては、例えば、ハードディスク磁気ディスク光ディスク磁気テープ、或いは半導体メモリであっても良い。論理的なストレージデバイスとしては、論理ボリュームとすることができる。

0023

以下、図面を参照して、本発明の幾つかの実施形態を詳細に説明する。

0024

<第一の実施形態>。

0025

図1は、本発明の第一の実施形態に係るコンピュータシステムの構成例を示す。

0026

LAN(Local Area Network)105に、ホストコンピュータ(以下、単に「ホスト」と言う)101と、管理端末103と、ストレージシステム107とが接続されている。ストレージシステム107には、複数のノード109と、複数のストレージサブシステム111とが備えられている。複数のノード109と複数のストレージサブシステム107がSAN(Storage Area Network)113に接続されている。また、複数のノード109は、それぞれ、フロントエンドで、LAN105に接続されており、バックエンドで、別のLAN115に接続されている。以下、LAN105と区別するために、LAN115を「バックエンドLAN115」と称する。

0027

複数のストレージサブシステム107は、それぞれ、一又は複数の論理的な記憶デバイス(以下、「LDEV」と略記する)を複数のノード109に提供する。LDEVは、LU(Logical Unit)或いは論理ボリュームと呼ばれても良い。本実施形態では、全てのノード109から全てのストレージサブシステム107の全てのLDEVが見える(認識される)が、それに限らず、どのノード109にどのストレージサブシステム107のどのLDEVを見せるかが制限されても良い。

0028

複数のノード109は、それぞれ、パーソナルコンピュータ等の計算機である。各ノード109は、他のノード109とバックエンドLAN115を介して通信することができる。また、複数のノード109は、いずれも、ホスト101に対して同じファイルシステムを見せることができる。具体的には、例えば、各ノード109は、ホスト101に対してNFS(Network File System)サーバとして機能することができる。この場合、ホスト101はNFSクライアントとして機能することができる。NFSに代えて、CIFS(Common Interface File
System)サーバなど他種のファイルサーバとして機能しても良い。

0029

ホスト101は、電子的な保護対象(例えばファイル或いはディレクトリ)のライト或いはリードをストレージシステム107に要求する。具体的には、例えば、ホスト101は、ファイルレベルのI/O要求ライトコマンド或いはリードコマンド)を、複数のノード109のうちのいずれかのノード109に送信する。

0030

管理端末103は、ストレージシステム107を管理する計算機である。具体的には、例えば、管理端末103は、LAN105を介して、各ノード109が保持している情報を収集し記憶することができる。また、管理端末103は、ホスト101から格納したストレージシステム107への保護対象に、保持期限(retention period)を設定することができる。これにより、ホスト101或いはストレージシステム107によって、保持期限に達していない保護対象が上書き或いは削除されてしまうことを防ぐことができる。

0031

以上が、本実施形態に係るコンピュータシステムの構成例である。なお、上記説明において、例えば、LAN105、LAN115及びSAN113のうちの少なくとも一つは、他種の通信ネットワークが採用されても良い。また、例えば、LAN115とSAN113は共通の通信ネットワークであっても良い。また、例えば、図1には、一つのホスト101を示したが、ホスト101は複数台あっても良い。また、例えば、ストレージシステム107は、アーカイブ用のストレージシステム、具体的には、例えば、WORM(Write Once Read Many)タイプのストレージシステムであってもよい。

0032

図2は、ノードとLDEVとの論理的な関係の一例を示す図である。

0033

各ノード109には、複数のストレージサブシステムにおける複数のLDEVのうち、管理対象になっているLDEVとそうでないLDEVとがある。この図2では、ノード109とそれの管理対象となっているLDEVとの関係を、実線矢印で表している。ノードAを代表的に例に採って説明すると、ノードAは、複数のLDEV
A〜Fが見えるものの、ストレージサブシステムA内のLDEV Aと、ストレージサブシステムB内のLDEV Cとを管理しており、他のLDEV B、D、E及びFを管理していない。LDEV A及びCの記憶容量がそれぞれ200GB(ギガバイト)の場合、ノードAは、合計400GBを所有していることになる。ノードAは、ファイルレベルのI/O要求をホスト101から受信した場合、該ファイルレベルのI/O要求に従うI/O先となるLDEVが、自分(自ノード(own node))の管理対象であれば(LDEV
A又はCであれば)、ブロックレベルのI/O要求(例えば、SCSI(Small Computer System Interface)に従うライトコマンド或いはリードコマンド)を該LDEVに送信する。一方、ノードAは、該ファイルレベルのI/O要求に従うI/O先となるLDEVが、自分の管理対象でなければ(例えば、LDEV
Bであれば)、そのLDEVを管理対象としている別のノード109(例えばノードB)に、I/Oを要求する。この場合、該別のノード109が、その要求に従って、そのLDEVにブロックレベルのI/O要求を発行する。

0034

各LDEVには、プロテクトポイントが関連付けられる(図では、プロテクトポイントは“PP”と略記されている)。「プロテクトポイント」とは、LDEVに記憶されているデータの失われにくさを表す。このため、プロテクトポイントが高ければ高いほど、データが失われにくいことになる。本実施形態では、LDEVに関連付けられるプロテクトポイントは、そのLDEVがどんなRAID(Redundant Array of Independent (or Inexpensive) Disks)レベルのRAIDグループに設けられているかに基づいて決定される。具体的には、例えば、RAID構成が採られていないディスク装置に設けられるLDEVには、プロテクトポイント“1”が関連付けられ、RAID5のRAIDグループに設けられたLDEVには、プロテクトポイント“2”が関連付けられ、RAID1のRAIDグループに設けられたLDEVには、プロテクトポイント“3”が関連付けられ、RAID6のRAIDグループに設けられたLDEVには、プロテクトポイント“4”が関連付けられる(“”内の値は、プロテクトポイントとしての値を意味する)。プロテクトポイントは、例えば、管理端末103を使用する管理者によって決定される。プロテクトポイントは、整数である必要は無く、小数或いは分数などで表されても良い。また、各LDEVのプロテクトポイントは、ホスト101、管理端末103或いはノード109によって、ストレージデバイス情報を基に自動で決定されても良い。ストレージデバイス情報には、例えば、どのLDEVがどのRAIDレベルのRAIDグループを基に形成され、該RAIDグループを構成する各ストレージデバイスがどんな種類であるかが記録されている。この場合、ホスト101、管理端末103或いはノード109が、LDEVが属するRAIDグループのRAIDレベルと、該LDEVが属するストレージデバイスの種類との少なくとも一方を基に、該LDEVのプロテクトポイントを決定しても良い。ストレージデバイスの種類としては、例えば、ディスク型ストレージデバイス(ハードディスクドライブ、DVD(Digital Versatile Disk)ドライブ)やフラッシュメモリデバイスなどであってもよいし、ディスク型ストレージデバイスについては、FC(Fibre Channel)、SATA(Serial ATA)などがあってもよい。

0035

また、本実施形態では、排他プロテクトグループ、という概念が用意される。排他プロテクトグループとは、同時に壊れる可能性のある(或いは、同時にリプレースされる可能性のある)LDEVの論理的なグループである。具体的には、例えば、同一のRAIDグループから形成された複数のLDEVのグループである。排他プロテクトグループ内の複数のLDEV間で(つまり、排他プロテクトグループ内で)、データのコピーが行われないよう制御される。具体的には、例えば、排他プロテクトグループA内にあるLDEV
Aから、同一の排他プロテクトグループA内にあるLDEV Bには、データのコピーが行われないよう制御される。

0036

この実施形態では、保護対象に要求されるプロテクトポイント(以下、要求プロテクトポイント)を満たすように保護対象を記憶することが、各ノード109が有する機能により実現される。保護対象(例えばファイル或いはディレクトリ)の要求プロテクトポイントは、ホスト101で設定されても良いし、管理端末103から設定されてもよい。

0037

図3は、ノード109によって実行される記憶制御の一例の概要を示す。

0038

例えば、ノードAによって、要求プロテクトポイント“4”の保護対象953が、プロテクトポイント“2”のLDEV
Aにライトされたとする。しかし、それだけでは、要求プロテクトポイント“4”を満たす記憶にはならない。なぜなら、格納先LDEV
Aのプロテクトポイント“2”が要求プロテクトポイント“4”未満だからである。

0039

そこで、ノードAは、LDEVAにライトする保護対象953を、別のLDEVにコピーする。LDEV Aのプロテクトポイント“2”とコピー先LDEVのプロテクトポイントとの合計が、保護対象953の要求プロテクトポイント“4”以上であれば、該要求プロテクトポイントを満たす記憶が完了したことになる。具体的には、例えば、ノードAは、保護対象953を、プロテクトポイント“3”であるLDEV
CにLDEV Aからコピーする。この場合、LDEV
AとLDEV Cのプロテクトポイントの合計が“5”になり、要求プロテクトポイント“4”以上であるので、要求プロテクトポイント“4”を満たす記憶が完了したことになる。なお、ノードAは、コピー先として、LDEV
Aが属する排他プロテクトグループA内のLDEV Bを選択しないようにする。これにより、LDEV A及びBが同時に壊れることにより保護対象953が同時に無くなってしまうことを防ぐことができる。

0040

もし、LDEVAのプロテクトポイント“2”とコピー先LDEVのプロテクトポイントとの合計が、要求プロテクトポイント“4”以上でなければ、要求プロテクトポイント“4”を満たす記憶が完了していないので、ノードAは、また別のLDEVに保護対象953をコピーする。このような処理は、LDEV
Aのプロテクトポイント“2”と、一以上のコピー先のLDEVにそれぞれ関連付けられている一以上のプロテクトポイントとの合計が、要求プロテクトポイント“4”以上になるまで行われる。

0041

要するに、各ノード109は、要求プロテクトポイント“n”の保護対象を、該保護対象を記憶する一以上のLDEVのそれぞれの一以上のプロテクトポイントの合計が要求プロテクトポイント“n”以上になるような記憶制御を実行する。

0042

このような記憶制御は、例えば、LDEVのプロテクトポイントが変更された場合、保護対象の要求プロテクトポイントが変更された場合、LDEV有効化処理が実行された場合、及びLDEV無効化処理が実行された場合のうちの少なくとも一つの場合に実行される(それぞれの場合については後に詳述する)。その際、各ノード109は、ライト先のLDEVが自分の管理対象ではない場合には、該ライト先のLDEVを管理対象とする他のノード109に、保護対象のライトを依頼する。また、各ノード109は、前述したように、保護対象のコピー先とするLDEVとして、該保護対象を記憶するLDEVが属する排他プロテクトグループに属しないLDEVを選択する。また、各ノード109は、或るLDEVにライトする保護対象を二以上の別のLDEVにコピーする場合、或るLDEVを共通のコピー元として二以上の別のLDEVにそれぞれコピーしても良いし(つまり、いわゆるマルチターゲット方式でコピーしても良いし)、或るLDEVから或る別のLDEVにコピーし該或る別のLDEVからまた別のLDEVにコピーしても良い(つまり、いわゆるマルチホップ方式でコピーしても良い)。

0043

以下、本実施形態についてより詳細に説明する。

0044

図4Aは、管理端末103のハードウェア構成例を示す。

0045

管理端末103は、CPU173、記憶資源177、表示装置175、入力装置179及びLAN
I/F181を備える。記憶資源177は、例えば、メモリ及びディスク装置の少なくとも一方で構成することができるが、それに限らず、他種の記憶媒体により構成されても良い。LAN
I/F181は、LAN105を介して通信するためのインタフェース装置である。

0046

記憶資源177には、CPU173で実行される複数のコンピュータプログラムが記憶される。具体的には、例えば、記憶資源177には、図5に例示するように、管理ソフトウェア513が記憶される。管理ソフトウェア513は、例えば、設定制御プログラム501、排他プロテクトグループ設定プログラム503、プロテクトポイント管理プログラム505、LDEV有効化プログラム507、LDEV無効化プログラム509、及び要求プロテクトポイント管理プログラム511がある。各コンピュータプログラムについては後述する。

0047

図4Bは、ストレージサブシステム111のハードウェア構成例を示す。

0048

ストレージサブシステム111は、コントローラ307と、複数のディスク装置303とを備える。コントローラ307は、例えば、SAN
I/F332、CPU333、メモリ334、ディスクI/F336及び転送制御回路341を備える。SAN
I/F332は、SAN113を介した通信(例えばファイバチャネル(FC)のプロトコルに従う通信)を実行するためのインタフェース装置である。メモリ334は、例えば、ノード109とディスク装置303との間でやり取りされるブロックレベルのデータを一時的に記憶するキャッシュメモリとして利用される。ディスクI/F336は、各ディスク装置303との通信(例えばFCのプロトコルに従う通信)を実行するためのインタフェース装置である。転送制御回路341は、SAN
I/F332、CPU333、メモリ334及びディスクI/F336間の接続を制御するLSI(Large Scale Integration)である。

0049

複数のディスク装置303のうちの二以上のディスク装置303により、RAIDグループを構成することができる。RAIDグループは、複数個備えられる。図4Cに例示するように、RAIDグループにより提供される記憶空間を区切ることで、一つのRAIDグループから一又は複数のLDEVを形成することができる。なお、複数のディスク装置303のうちの少なくとも一つが、フラッシュメモリデバイスなど、他種のストレージデバイスが採用されても良い。

0050

図4Dは、ノード109のハードウェア構成例を示す。

0051

ノード109は、CPU273、記憶資源277、表示装置275、入力装置279、LAN
I/F281及びSAN I/F283を備える。記憶資源277は、例えば、メモリ及びディスク装置の少なくとも一方で構成することができるが、それに限らず、他種の記憶媒体により構成されても良い。LAN
I/F281は、LAN105及びバックエンドLAN115を介して通信するためのインタフェース装置である。SAN
I/F283は、SAN113を介した通信を実行するためのインタフェース装置である。

0052

記憶資源277には、CPU273で実行される複数のコンピュータプログラムや、種々の情報が記憶される。複数のコンピュータプログラムとして、例えば、図6に例示するように、ホストライト処理プログラム401、ノードライト処理プログラム403、ホストリード処理プログラム405、ノードリード処理プログラム407、管理通信プログラム409、プロテクトチェック処理プログラム411、グループ作成処理プログラム413、グループ消去処理プログラム415、プロテクトポイント変更処理プログラム417、要求プロテクトポイント変更処理プログラム419、LDEV有効化処理プログラム421、LDEV無効化処理プログラム423、LDEV発見処理プログラム425及び空き容量率計算処理プログラム427がある。また、種々の情報として、例えば、図6に例示するように、LDEV管理テーブル429、ディレクトリ管理テーブル431、ファイル管理テーブル433、ファイルデータ管理テーブル435及びLDEV空きブロックビットマップ437がある。

0053

以下、各種情報について説明する。まず、LDEV管理テーブル429について説明する。

0054

図7Aは、LDEV管理テーブル429の構成例を示す。

0055

LDEV管理テーブル429は、ストレージシステム107内のLDEVを管理するためのテーブルである。全てのノード109が、同じ内容のLDEV管理テーブル429を記憶する。

0056

LDEV管理テーブル429を構成する複数のエントリ領域の各々は、一つのLDEVに対応し、LDEV通番(図では、0、1、…、n…、)から識別することができる。以下、各エントリを「LDEV管理エントリ」と呼ぶ。LDEV通番とは、ストレージシステム107において一意のLDEVの番号である。LDEV通番は、LDEV管理エントリ番号と読み替えられても良い。

0057

一つのLDEV管理エントリに登録される複数種類の情報要素として、例えば、使用フラグ、サブシステムID、LDEV番号、管理ノードID、排他プロテクトグループID、プロテクトポイント、容量及び空き容量率がある。以下、図7Aの説明において、一つのLDEV管理エントリに対応するLDEVを「対象LDEV」と言う。

0058

使用フラグは、対象LDEVの使用状態を表す。具体的には、例えば、使用フラグ“1”という値が、ストレージシステム107内で使用中(例えば、対象LDEVにI/Oが発生し得る状態)であることを意味する。使用フラグ“0”という値が、ストレージシステム107内で未使用(例えば、対象LDEVにI/Oが発生し得ない状態)であることを意味する。使用フラグ“−1”という値が、このLDEV管理エントリが無効(対象LDEVがしない状態であること)であることを意味する。

0059

サブシステムIDは、対象LDEVを有するストレージサブシステム111の識別子である。

0060

LDEV番号は、そのストレージサブシステム111内で管理されているLDEV番号(対象LDEVの番号)であり、ストレージシステム107内で一意であるLDEV通番とは異なる。

0061

管理ノードIDは、対象LDEVを管理対象としているノード109の識別子である。もし、対象LDEVを管理対象とするノードが存在しなければ、管理ノードIDとして、そのことを意味する値(例えば“−1”)が設定される。対象LDEVにつき管理ノードは一つである。これにより、対象LDEV内のデータが他のノードによって誤ってアップデートされてしまうといったことを防ぐことができる。一つの対象LDEVに複数の管理ノードがあってもよい。管理ノードは、所定の照会コマンド(例えば、SCSIでサポートされているinquiryコマンド)を対象LDEVに対して送信することで、サブシステムID及びLDEV番号を、対象LDEVを有するストレージサブシステム111から取得することができる。

0062

排他プロテクトグループIDは、対象LDEVを構成要素としている排他プロテクトグループの識別子である。対象LDEVを構成要素としている排他プロテクトグループが存在しなければ(例えば、同時に障害の生じる単位が対象LDEVのみであれば)、排他プロテクトグループIDとして、そのことを意味する値(“−1”)が設定される。

0063

プロテクトポイントは、対象LDEVに関連付けられるプロテクトポイントである。プロテクトポイントは、LDEV毎に代えて又は加えて、例えば、ストレージサブシステム毎、RAIDグループ毎、或いは、ディスク装置毎に設定することが可能である。しかし、いずれの単位で設定されても、設定されたプロテクトポイントは、LDEVに反映される。具体的には、例えば、或るストレージサブシステム111、或いは、或るRAIDグループに或るプロテクトポイントが指定された場合、該ストレージサブシステム111にある全LDEV、或いは、該RAIDグループに属する全LDEVに、指定されたプロテクトポイントが関連付けられる。

0064

容量は、対象LDEVの記憶容量である。

0065

空き容量率は、対象LDEVの記憶容量を100%とした場合の未使用の記憶容量の比率(%)である。空き容量率は、後述する空き容量率計算処理で計算され設定される。

0066

以上が、LDEV管理テーブル429についての説明である。次に、ディレクトリ管理テーブル431について説明する。

0067

図7Bは、ディレクトリ管理テーブル431の構成例を示す。

0068

ディレクトリ管理テーブル431は、ストレージシステム107内のディレクトリを管理するためのテーブルである。全てのノード109が、同じ内容のディレクトリ管理テーブル431を記憶する。

0069

ディレクトリ管理テーブル431を構成する複数のエントリの各々は、一つのディレクトリに対応し、ディレクトリ通番(図では、0、1、…、n…、)から識別することができる。以下、各エントリを「ディレクトリエントリ」と呼ぶ。ディレクトリ通番とは、ストレージシステム107において一意のディレクトリの番号である。ディレクトリ通番は、ディレクトリエントリ番号と読み替えられても良い。

0070

一つのディレクトリエントリに登録される複数種類の情報要素として、例えば、ディレクトリ名、親ディレクトリ(parent directory)番号、子ディレクトリ(cub directory)番号リスト、排他プロテクトグループID、要求プロテクトポイント、保持期限、生成日時(creation time)及びファイル番号リストがある。以下、図7Bの説明において、一つのディレクトリエントリに対応するディレクトリを「対象ディレクトリ」と言う。

0071

ディレクトリ名は、対象ディレクトリの名称である。このディレクトリエントリが無効(対象ディレクトリが存在しない状態であること)である場合には、ディレクトリ名として、無効を示す値(例えば“−1”)が設定される。

0072

親ディレクトリ番号は、対象ディレクトリにとっての親ディレクトリ(対象ディレクトリの直近且つ上位のディレクトリ)のディレクトリ通番である。対象ディレクトリがルートディレクトリの場合、親ディレクトリ番号として、そのことを意味する値(例えば“−1”)が設定される。

0073

子ディレクトリ番号リストは、対象ディレクトリにとっての全ての子ディレクトリ(対象ディレクトリの下位のディレクトリ)のディレクトリ通番のリストである。

0074

要求プロテクトポイントは、対象ディレクトリに関連付けられた要求プロテクトポイントである。この要求プロテクトポイントは、対象ディレクトリ内にライトされるファイルに対応した要求プロテクトポイントや、対象ディレクトリの子ディレクトリに対応した要求プロテクトポイントのそれぞれのデフォルト値となる。すなわち、例えば、図31Aに例示するように、要求プロテクトポイントの設定されていないファイルが、要求プロテクトポイント“j”の対象ディレクトリにライトされる場合、該ファイルの要求プロテクトポイントは“j”に設定される(j≧0)。ちなみに、例えば、図31Bに例示するように、要求プロテクトポイント“p”のファイルが、要求プロテクトポイント“q”の対象ディレクトリにライトされる場合、該ファイルの要求プロテクトポイントは“p”のままである(p≧0、q≧0)。要するに、要求プロテクトポイントが設定されていないファイルがディレクトリにライトされる場合には、該ディレクトリの要求プロテクトポイントが該ファイルに関連付けられ、要求プロテクトポイントが設定されているファイルがディレクトリにライトされる場合には、該ディレクトリに要求プロテクトポイントに関わらず、該ファイルの要求プロテクトポイントが維持される。

0075

保持期限は、対象ディレクトリの保持期限である。例えば、対象ディレクトリを管理しているノード109は、該対象ディレクトリの削除をホスト101から要求された場合、要求を受けた日時が保持期限を過ぎてなければ、対象ディレクトリを削除せず、要求を受けた日時が保持期限を過ぎていれば、該要求通りに対象ディレクトリを削除することができる。なお、保持期限は、ディレクトリに代えて又は加えて、ファイルにも関連付けることができるが、ディレクトリの保持期限とファイルの保持期限との関係は、ディレクトリの要求プロテクトポイントとファイルの要求プロテクトポイントとの関係と同じにすることができる。具体的には、例えば、ディレクトリに保持期限が設定された場合、該ディレクトリ内の複数のファイルのうち、保持期限の設定されていないファイルには、該ディレクトリの保持期限がファイルの保持期限とされて、保持期限の設定されているファイルには、該ディレクトリの保持期限に関わらず該ファイルの保持期限が維持されても良い。

0076

生成日時は、対象ディレクトリがストレージシステム107に生成された日時である。

0077

ファイル番号リストは、対象ディレクトリ内に存在する0個以上のファイルのファイル通番のリストである(ファイル通番については後述する)。

0078

以上が、ディレクトリ管理テーブル431についての説明である。なお、ファイル或いはディレクトリ等の保護対象に関連付けられる要求プロテクトポイントは、例えば、図29Aに例示するように、該保護対象の属性を基に、ノード109(例えばホストライト処理プログラム401)によって自動的に決定されても良い。また、例えば、図29Bに例示するように、ファイルに要求プロテクトポイントが設定されている場合、ファイルの要求プロテクトポイントと該ファイルのライト先のディレクトリの要求プロテクトポイントとのうちのどちらを優先するかが、所定の方法で(例えば、予め設定されたモードに従って、或いは、ファイル又はディレクトリの属性を基に)、ノード109(例えばホストライト処理プログラム401)によって自動的に選択されても良い。ディレクトリの要求プロテクトポイントが優先された場合、ファイルの要求プロテクトポイントが該ディレクトリの要求プロテクトポイントに変更され、ファイルの要求プロテクトポイントが優先された場合、ファイルの要求プロテクトポイントが維持されて良い。ここで、保護対象の属性として、例えば、保護対象の種類(例えば、ファイル、ディレクトリ)がある。ファイルの属性としては、例えば、ファイルの名称、識別子、保持期限などを採用することができる。また、ディレクトリの属性としては、例えば、ディレクトリの名称、生成日時、保持期限などを採用することができる。

0079

次に、ファイル管理テーブル433について説明する。

0080

図8Aは、ファイル管理テーブル433の構成例を示す。

0081

ファイル管理テーブル433は、ストレージシステム107内のファイルを管理するためのテーブルである。全てのノード109が、同じ内容のファイル管理テーブル433を記憶する。

0082

ファイル管理テーブル433を構成する複数のエントリの各々は、一つのファイルに対応し、ファイル通番(図では、0、1、…、n…、)から識別することができる。以下、各エントリを「ファイルエントリ」と呼ぶ。ファイル通番とは、ストレージシステム107において一意のファイルの番号である。ファイル通番は、ファイルエントリ番号と読み替えられても良い。

0083

一つのファイルエントリに登録される複数種類の情報要素として、例えば、ファイル名、サイズ、生成日時、要求プロテクトポイント、保持期限及び格納位置リストがある。以下、図8Aの説明において、一つのファイルエントリに対応するファイルを「対象ファイル」と言う。

0084

ファイル名は、対象ファイルの名称である。このファイルエントリが無効(対象ファイルが存在せず新規に種々の情報要素をライトすることが可能な状態であること)である場合には、ファイル名として、無効を示す値(例えば“−1”)が設定される。

0085

サイズは、対象ファイルのデータサイズである。

0086

生成日時は、対象ファイルがストレージシステム107内に生成された日時(例えば、ホスト101からライトされた日時)である。

0087

要求プロテクトポイントは、対象ファイルに関連付けられた要求プロテクトポイントである。

0088

保持期限は、対象ファイルに関連付けられた保持期限である。

0089

格納位置リストは、対象ファイルに対応した複数のブロックデータがそれぞれ存在する複数の位置の情報のリストである。具体的には、例えば、格納位置リストは、複数のサブエントリで構成され、各サブエントリには、ブロックデータが格納されている位置に関する情報要素として、例えば、格納LDEV通番と、ファイルデータ管理テーブルエントリ番号とが記録される。格納LDEV通番は、ブロックデータを格納しているLDEVに対応したLDEV通番である。そのようなLDEVが存在しない場合、格納LDEV通番として、そのことを意味する無効値(例えば“−1”)が設定される。ファイルデータ管理テーブルエントリ番号とは、該LDEVに対応したファイルデータ管理テーブルのエントリ番号である。

0090

以上が、ファイル管理テーブル433についての説明である。次に、ファイルデータ管理テーブル435について説明する。

0091

図8Bは、ファイルデータ管理テーブル435の構成例を示す。

0092

ファイルデータ管理テーブル435は、ファイルに対応したブロックデータが対象LDEV内のどこにあるかを管理するためのテーブルである。ファイルデータ管理テーブル435は、LDEV毎に用意される。すなわち、この図8Bの説明において用いる「対象LDEV」とは、ファイルデータ管理テーブル435に対応したLDEVを意味する。ノード109には、そのノード109が管理しているLDEVに対応したファイルデータ管理テーブル435が記憶され、そのノード109が管理していないLDEVに対応したファイルデータ管理テーブル435は記憶されない。

0093

ファイルデータ管理テーブル435を構成する複数のエントリの各々は、一つのファイルに対応し、ファイルデータ管理テーブルエントリ番号(図では、0、1、…、n…、)から識別することができる。一つのファイルデータ管理テーブルエントリには、該エントリに対応するファイル(以下、対象ファイル)のブロックデータが対象LDEVのどこに記憶されているかが記録される。具体的には、例えば、対象ファイルに対応した一以上のブロックデータをそれぞれ格納している一以上のブロック(対象LDEVを構成するブロック(論理的な記憶領域))の番号のリストが記録される。以下、そのリストを「ブロックリスト」と呼ぶ。

0094

以上が、ファイルデータ管理テーブル435についての説明である。次に、LDEV空きブロックビットマップ437について説明する。

0095

図8Cは、LDEV空きブロックビットマップ437の構成例を示す。

0096

LDEV空きブロックビットマップ437は、対象LDEVにおけるどのブロックが空きであるかを管理するためのテーブルである。LDEV空きブロックビットマップ437は、LDEV毎に用意される。すなわち、この図8Cの説明において用いる「対象LDEV」とは、LDEV空きブロックビットマップ437に対応したLDEVを意味する。ノード109には、そのノード109が管理しているLDEVに対応したLDEV空きブロックビットマップ437が記憶され、そのノード109が管理していないLDEVに対応したLDEV空きブロックビットマップ437は記憶されない。LDEV空きブロックビットマップ437を構成する各ビットは、対象LDEVを構成する複数のブロックの各々に対応している。“1”という値が空きのブロック(データが記憶されていないブロック)であることを意味する。

0097

以上が、LDEV空きブロックビットマップ437についての説明である。

0098

以下、本実施形態で行われる各種処理を説明する。

0099

図9は、ホストライト処理の流れの一例を示す。図では、「ステップ」という言葉を「S」と略記している。

0100

この図に示すホストライト処理は、ノード109がホストからライト要求を受信した時にそのノード109によって実行される。具体的には、そのノード109におけるホストライト処理プログラム401によって実行される。以下、コンピュータプログラムが主語になる場合は、実際にはそのコンピュータプログラムを実行するCPUによって処理が行われるものとする。また、ライト要求で指定されているライト対象のファイルを「ライトファイル」と言う。

0101

ステップ101で、ホストライト処理プログラム401は、ディレクトリ管理テーブル431をたどって、ライト要求で指定されているディレクトリに対応したディレクトリエントリを識別する。以下、この図9の説明において、そのディレクトリエントリを「当該ディレクトリエントリ」と呼ぶ。

0102

ステップ102で、ホストライト処理プログラム401は、ファイル管理テーブル433から無効ファイルエントリ(ファイル名として“−1”が設定されているファイルエントリ)を選択する。以下、このファイルエントリを、図9の説明において「当該ファイルエントリ」と呼ぶ。

0103

ステップ103で、ホストライト処理プログラム401は、当該ディレクトリエントリのファイル番号リストに、当該ファイルエントリに対応したファイル通番を追記する。

0104

ステップ104で、ホストライト処理プログラム401は、ライトファイルのファイル名、サイズ及び生成日時を、当該ファイルエントリに記録する。

0105

ステップ105で、ホストライト処理プログラム401は、上記ライト先ディレクトリの要求プロテクトポイント及び保持期限を、当該ファイルエントリに記録する。すなわち、ライトファイルの要求プロテクトポイント及び保持期限として、上記ライト先ディレクトリの要求プロテクトポイント及び保持期限が設定される。なお、このステップ105では、例えば、図29A或いは図29Bを参照して説明した処理が実行されても良い。すなわち、ホストライト処理プログラム401は、ライトファイルのファイル属性に基づいてライトファイルの要求プロテクトポイントを決定しても良いし、ライトファイルに要求プロテクトポイントが関連付けられているか否かを判断し、関連付けられていると判断した場合には(例えば、ライトファイルに要求プロテクトポイントが埋め込まれていると判断した場合には)、ライトファイルとライト先ディレクトリのどちらの要求プロテクトポイントを優先するかを選択しても良い。

0106

ステップ106で、ホストライト処理プログラム401は、X=ライトファイルの要求プロテクトポイントとする(例えば、記憶資源277に設定する)。

0107

ステップ107で、ホストライト処理プログラム401は、未選択且つ排他プロテクトグループの被らない使用中のLDEVであって、最も空き容量率の高いLDEVを選択する。このステップ107で選択されたLDEVを「選択LDEV」と言う。ここで、「未選択のLDEV」とは、ライトファイルのライト先として未だ選択されていないLDEVである。そのライトファイルを初めてライトするのであれば、どのLDEVも未選択LDEVであるが、例えば、後述のステップ118でYesとなった場合には、ステップ107で一旦選択されたLDEVは、未選択のLDEVではなく、選択済みのLDEVである。「排他プロテクトグループの被らないLDEV」とは、選択済みのLDEVを有する排他プロテクトグループに無いLDEVである。この条件を満たすLDEVをライト先とすることで、排他プロテクトグループ内で保護対象(ファイル或いはディレクトリ)をコピーしてしまい後に同時にその保護対象を失ってしまうおそれを防ぐことができる。「使用中のLDEV」とは、使用フラグとして使用中を表す値が設定されているLDEV管理エントリに対応したLDEVである。「最も空き容量率の高いLDEV」とは、未選択且つ排他プロテクトグループの被らない使用中のLDEVに該当する一以上のLDEVにそれぞれ対応した一以上のLDEV管理エントリのうち、最も空き容量率の高いLDEV管理エントリに対応したLDEVである。

0108

ステップ108で、ホストライト処理プログラム401は、選択LDEVに対応した管理ノードを取得する。具体的には、ホストライト処理プログラム401は、選択LDEVに対応したLDEV管理エントリに記録されている管理ノードIDを取得する。

0109

ステップ109で、ホストライト処理プログラム401は、取得した管理ノードが、自ノードであるか否か、すなわち、そのホストライト処理プログラム401を実行している管理ノードであるか否かを判断する。自ノードと判断した場合には、ステップ110に進み、自ノードではないと判断した場合には、ステップ111に進む。

0110

ステップ110で、ホストライト処理プログラム401は、ノードライト処理プログラム403をコールする。これにより、ノードライト処理が行われる。ノードライト処理については、図10を参照して後述する。

0111

ステップ111で、ホストライト処理プログラム401は、上記取得した管理ノードに、ライトファイルのライトを要求するライト要求を送信する。そのライト要求には、選択LDEVに対応したLDEV通番と、ライトファイルのサイズとが記録される。このライト要求により、ライト要求の送信先の管理ノードで、ノードライト処理プログラム403がコールされる。

0112

ステップ112で、ホストライト処理プログラム401は、終了待ちとなる。この間に、ホストライト処理プログラム401は、ライト要求の送信先管理ノードから、ライト要求の終了報告を受ける。正常終了報告を受ける場合、ホストライト処理プログラム401は、ファイルデータ管理テーブルエントリ番号を受ける。

0113

ステップ113で、ホストライト処理プログラム401は、ノードライト処理の終了が正常終了と異常終了のどちらであるか(例えば、受けた終了報告が正常終了報告であるか異常終了報告であるか)を判断する。正常終了と判断した場合、ステップ114に進み、異常終了と判断した場合、ステップ118に進む。

0114

ステップ114で、ホストライト処理プログラム401は、当該ファイルエントリの格納位置リストのサブエントリに、選択LDEVに対応したLDEV通番(格納LDEV通番)と、受けたファイルデータ管理テーブルエントリ番号とを記録する。

0115

ステップ115で、ホストライト処理プログラム401は、X=X−選択LDEVのプロテクトポイント(選択LDEVに対応したLDEV管理エントリに設定されているプロテクトポイント)、を計算する。つまり、Xがアップデートされる。

0116

ステップ116で、ホストライト処理プログラム401は、アップデート後のXが0以下か否かを判断する。アップデート後のXが0以下であるということは、ライトファイルの要求プロテクトポイントを満たす記憶制御が実行されたこと、すなわち、要求プロテクトポイント“n”のライトファイルを、該ライトファイルを記憶する一以上のLDEVのそれぞれの一以上のプロテクトポイントの合計が要求プロテクトポイント“n”以上になるような記憶制御が実行されたことを意味する。アップデート後のXが0以下であれば、ステップ117に進み、アップデート後のXが0を超えていれば、ステップ118に進む。

0117

ステップ117で、ホストライト処理プログラム401は、全ての他ノード109に、当該ディレクトリエントリと当該ファイルエントリとのアップデートを指示する。その指示の際に、例えば、当該ディレクトリエントリに対応したディレクトリ通番と、アップデート後の当該ディレクトリエントリに記録されている各種情報要素と、当該ファイルエントリに対応したファイル通番と、アップデート後の当該ファイルエントリに記録されている各種情報要素とが通知される。これにより、全ての他ノード109では、該指示に従って、ディレクトリ管理テーブル431における当該ディレクトリエントリと、ファイル管理テーブル433における当該ファイルエントリとが、それぞれ、通知されたディレクトリ番号及びファイル番号からそれぞれ識別されて、通知された情報要素を基にアップデートされ、その結果、全ノード109において、ディレクトリ管理テーブル431やファイル管理テーブル433が同じ内容となる。その後、ホストライト処理プログラム401は、ライト要求の送信元ホスト101に、正常報告を送信する。

0118

ステップ118で、ホストライト処理プログラム401は、未だ所定種類のLDEVがあるかどうかを判断する。ここで言う「所定種類のLDEV」とは、未選択且つ排他プロテクトグループの被らない使用中のLDEVである。あるとの判断になれば、ステップ107に戻り、無いとの判断になれば、ホストライト処理プログラム401は、ライト要求の送信元ホスト101に、異常報告を送信する。

0119

以上が、ホストライト処理の説明である。なお、この図9における点線枠内の処理、すなわち、ステップ107〜ステップ118の処理が、プロテクトチェック処理図13参照)の「当該ファイルのデータライト」というステップ194で実行される。

0120

図10は、ノードライト処理の流れの一例を示す。

0121

この図に示すノードライト処理は、ファイルに対応したブロックデータを実際にLDEVにライトする処理である。前述したホストライト処理において、管理ノードが、ホストライト処理を実行しているノード(自ノード)であれば、その自ノードにおいてホストライト処理の一部として実行され、管理ノードが自ノードではないノード(つまり他ノード)であれば、自ノードからのライト要求に応答して該他のノードで実行される。具体的には、自ノード或いは他ノードにおけるノードライト処理プログラム403によって実行される。

0122

ステップ121で、ノードライト処理プログラム403は、ブロックリストが空き(例えばヌル)のファイルデータ管理テーブルエントリを選択する。以下、選択されたエントリを、この図10の説明において、「選択エントリ」と呼ぶ(図では、“D”というアルファベットで表す)。

0123

ステップ122で、ノードライト処理プログラム403は、選択LDEV(図9のステップ107で選択されたLDEV)に対応したLDEV空きブロックビットマップ437を取得する。

0124

ステップ123で、ノードライト処理プログラム403は、ライトファイルを構成するブロックデータをライトできるだけの空きが選択LDEVにあるかどうかを判断する。具体的には、例えば、ノードライト処理プログラム403は、上記取得されたLDEV空きブロックビットマップ437から把握される空きサイズが、ライトファイルのサイズ以上であるか否かを判断する。ライトできるだけの空きがあると判断されれば、ステップ124に進み、そのような空きが無いと判断されれば、ステップ131に進む。

0125

ステップ124で、ノードライト処理プログラム403は、選択ブロックから空きブロックを選択する。そして、ノードライト処理プログラム403は、選択した空きブロックに、ライトファイルのブロックデータをライトし(ステップ125)、選択エントリに、該空きブロックの番号を記録し(ステップ126)、該空きブロックに対応したビット(LDEV空きブロックビットマップ437上のビット)を、データが書かれたことを意味する値(例えば“0”)にする(ステップ127)。ライトファイルを構成する全てのブロックデータについて、ステップ124乃至127を実行し(ステップ128でNo)、終了すれば(ステップ128でYes)、ステップ129に進む。

0126

ステップ129で、ノードライト処理プログラム403は、他のノード(ホストライト処理プログラム401を実行しているノード)からのライト要求に従って実行されているか否かを判断する。他のノードからのライト要求に従って実行されている場合には(ステップ129でYes)、ノードライト処理プログラム403は、選択エントリのファイルデータ管理テーブルエントリ番号を該他のノードに返し、正常終了報告を、該他のノードに送信し(ステップ130)、正常終了となる。一方、ノードライト処理プログラム403が上記他のノードからのライト要求で実行されているのではない場合には、ノードライト処理プログラム403は、ステップ130を行うことなく正常終了となる。

0127

ステップ131で、ノードライト処理プログラム403は、他のノード(ホストライト処理プログラム401を実行しているノード)からのライト要求に従って実行されているか否かを判断する。他のノードからのライト要求に従って実行されている場合には(ステップ131でYes)、ノードライト処理プログラム403は、異常終了報告を、該他のノードに送信し(ステップ132)、異常終了となる。一方、ノードライト処理プログラム403が上記他のノードからのライト要求で実行されているのではない場合には、ノードライト処理プログラム403は、ステップ132を行うことなく異常終了となる。

0128

図11は、ホストリード処理の流れの一例を示す。

0129

この図に示すホストリード処理は、ノード109がホストからリード要求を受信した時にそのノード109によって実行される。具体的には、そのノード109におけるホストリード処理プログラム405によって実行される。以下、リード要求で指定されているリード対象のファイルを「リードファイル」と言う。

0130

ステップ141で、ホストリード処理プログラム405は、ディレクトリ管理テーブル431をたどって、リード要求で指定されているディレクトリに対応したディレクトリエントリを識別する。以下、この図11の説明において、そのディレクトリエントリを「当該ディレクトリエントリ」と呼ぶ。

0131

ステップ142で、ホストリード処理プログラム405は、当該ディレクトリエントリのファイル番号リストにある一以上のファイル通番にそれぞれ対応した一以上のファイルエントリから、リードファイルのファイル名が記録されているファイルエントリを検索する。該フェイルエントリが見つかれば(ステップ143でYes)、ステップ144に進み、該ファイルエントリが見つからなければ(ステップ143でNo)、ステップ153に進む。

0132

ステップ144で、ホストリード処理プログラム405は、見つかったファイルエントリの格納位置リストにおける先頭のサブエントリ(格納位置1)を選択する。

0133

ステップ145で、ホストリード処理プログラム405は、選択したサブエントリ(格納位置1)に記録されている格納LDEV通番に対応したLDEVエントリを取得し、該LDEVエントリから、管理ノードIDを取得する。

0134

ステップ146で、ホストリード処理プログラム405は、取得した管理ノードIDに対応した管理ノードが、自ノードであるか否か(すなわち、そのホストリード処理プログラム405を実行している管理ノードであるか否か)を判断する。自ノードと判断した場合には、ステップ147に進み、自ノードではないと判断した場合には、ステップ148に進む。

0135

ステップ147で、ホストリード処理プログラム405は、ノードリード処理プログラム407をコールする。これにより、ノードリード処理が行われる。ノードリード処理については、図12を参照して後述する。

0136

ステップ148で、ホストリード処理プログラム405は、上記取得した管理ノードIDに対応したノードに、リードファイルのリードを要求するリード要求を送信する。そのリード要求には、上記選択したサブエントリに記録されている格納LDEV通番及びファイルデータ管理テーブルエントリ番号と、リードサイズとが記録される。このリード要求に応答して、リード要求の送信先の管理ノードでノードリード処理が行われ、それにより、リードファイルを構成するブロックデータが読み出される。

0137

ステップ149で、ホストリード処理プログラム405は、終了待ちとなる。この間に、ホストリード処理プログラム405は、リード要求の送信先管理ノードから、リード要求の終了報告を受ける。正常終了報告を受ける場合、ホストリード処理プログラム405は、リードファイルを構成するブロックデータを受ける。

0138

ステップ150で、ホストリード処理プログラム405は、ノードリード処理の終了が正常終了と異常終了のどちらであるか(例えば、受けた終了報告が正常終了報告であるか異常終了報告であるか)を判断する。正常終了と判断した場合、ステップ154に進み、異常終了と判断した場合、ステップ151に進む。

0139

ステップ151で、ホストリード処理プログラム405は、格納位置リストに、このホストリード処理で未選択の次のサブエントリ(格納位置)があるか否かを判断する。あれば、次のサブエントリを選択して(ステップ152)、再びステップ145を実行し、無ければ、ステップ154に進む。

0140

ステップ153で、ホストリード処理プログラム405は、ホスト101に、異常終了を報告する。

0141

ステップ154で、ホストリード処理プログラム405は、ホスト101に、リードされたブロックデータで構成されるリードファイルを送信する。

0142

以上が、ホストリード処理の説明である。なお、この図11における点線枠内の処理、すなわち、ステップ145〜ステップ152の処理が、プロテクトチェック処理(図13参照)の「当該ファイルのデータリード」というステップ192で実行される。

0143

図12は、ノードリード処理の流れの一例を示す。

0144

この図に示すノードリード処理は、ファイルに対応したブロックデータを実際にLDEVからリードする処理である。前述したホストリード処理において、管理ノードが、ホストリード処理を実行しているノード(自ノード)であれば、その自ノードにおいてホストリード処理の一部として実行され、管理ノードが自ノードではないノード(つまり他ノード)であれば、自ノードからのリード要求に応答して該他のノードで実行される。具体的には、自ノード或いは他ノードにおけるノードリード処理プログラム407によって実行される。

0145

ステップ171で、ノードリード処理プログラム407は、ホストリード処理において指定された格納LDEV通番に対応するファイルデータ管理テーブルの、指定されたファイルデータ管理テーブルエントリを、ファイル管理テーブル433から識別する。

0146

ステップ172で、ノードリード処理プログラム407は、識別されたファイルデータ管理テーブルエントリにあるブロックリストから、上記指定された格納LDEV通番に対応するLDEVにおいてブロックデータの記憶されている一以上のブロックを識別する。ノードリード処理プログラム407は、識別された一以上のブロックから、ブロックデータをリードする。

0147

ステップ173で、ノードリード処理プログラム407は、正常終了か否かを判断する。正常終了と判断した場合、ステップ174に進み、正常終了ではないと判断した場合、ステップ176に進む。例えば、リードされた一以上のブロックデータの合計サイズが、指定されたリードサイズ以上であれば、正常終了と判断し、そうでなければ、異常終了と判断する。

0148

ステップ174で、ノードリード処理プログラム407は、他のノード(ホストリード処理プログラム405を実行しているノード)からのリード要求に従って実行されているか否かを判断する。他のノードからのリード要求に従って実行されている場合には、ノードリード処理プログラム407は、正常終了報告と、リードされたブロックデータとを、該他のノードに送信し(ステップ175)、正常終了となる。一方、ノードリード処理プログラム407が上記他のノードからのリード要求で実行されているのではない場合には、ノードリード処理プログラム407は、ステップ175を行うことなく正常終了となる。

0149

ステップ176で、ノードリード処理プログラム407は、他のノード(ホストリード処理プログラム405を実行しているノード)からのリード要求に従って実行されているか否かを判断する。他のノードからのリード要求に従って実行されている場合には、ノードリード処理プログラム407は、異常終了報告を、該他のノードに送信し(ステップ177)、異常終了となる。一方、ノードリード処理プログラム407が上記他のノードからのリード要求で実行されたのではない場合には、ノードリード処理プログラム407は、ステップ177を行うことなく異常終了となる。

0150

図13は、プロテクトチェック処理の流れの一例を示す。

0151

プロテクトチェック処理とは、ストレージシステム107に格納されている全てのファイルに対して、要求プロテクトポイントが満たされているかどうかを判定し、満たされていなければデータのコピーを行って満たすようにする処理である。プロテクトチェック処理は、プロテクトチェック処理プログラム411によって実行される。

0152

プロテクトチェック処理プログラム411は、ディレクトリ管理テーブル431におけるディレクトリエントリをルートから辿る(ステップ181)。すなわち、プロテクトチェック処理プログラム411は、ルートディレクトリのディレクトリエントリに記録されている子ディレクトリ番号リストを用いて、ディレクトリエントリを辿る。

0153

その結果、このプロテクトチェック処理において未選択のディレクトリエントリがあれば(ステップ182でYes)、プロテクトチェック処理プログラム411は、該ディレクトリエントリを選択する(ステップ183)。

0154

プロテクトチェック処理プログラム411は、ステップ183で選択したディレクトリエントリのファイル番号リストにおいて、このプロテクトチェック処理において一以上の未選択のファイル通番があれば(ステップ184でYes)、その一以上のファイル通番から一つのファイル通番を選択する(ステップ185)。

0155

ステップ186で、プロテクトチェック処理プログラム411は、ステップ185で選択したファイル通番に対応したファイルエントリを識別する。

0156

ステップ187で、プロテクトチェック処理プログラム411は、X=識別されたファイルエントリに対応したファイルの要求プロテクトポイントとする(例えば、記憶資源277に設定する)。以下、そのファイルを、この図13の説明において「当該ファイル」と呼ぶ。

0157

プロテクトチェック処理プログラム411は、当該ファイルに対応したファイルエントリの格納位置リストに、このプロテクトチェック処理において一以上の未選択のサブエントリ(格納位置)があれば(ステップ188でYes)、一以上の未選択のサブエントリから一つのサブエントリを選択し、そのサブエントリにある格納LDEV通番に対応したLDEVエントリを識別する(ステップ189)。

0158

ステップ190で、プロテクトチェック処理プログラム411は、X=X−当該LDEVのプロテクトポイント(識別されたLDEVエントリに記録されているプロテクトポイント)を計算する。つまり、Xのアップデートが行われる。

0159

プロテクトチェック処理プログラム411は、アップデート後のXが0を超えていれば、ステップ192以降に進む。つまり、要求プロテクトポイントが満たされていないので、当該ファイルをリードすることと、リードされた当該ファイルを、当該ファイルが未だ格納されていないLDEVにライトすることとが行われる(つまり当該ファイルのコピーが行われる)。

0160

具体的には、プロテクトチェック処理プログラム411が、ホストリード処理プログラム405をコールし、ホストリード処理プログラム405により、ステップ192、すなわち、当該ファイルのデータリード(図11において点線枠で囲まれたステップ)が実行される(プロテクトチェック処理プログラム411自身がステップ192を実行しても良い)。当該ファイルのデータリードが異常終了となれば(ステップ193でYes)、ステップ184に進み、正常終了となれば(ステップ193でNo)、プロテクトチェック処理プログラム411が、ホストライト処理プログラム401をコールし、ホストライト処理プログラム401が、当該ファイルのデータライト(図9において点線枠で囲まれたステップ)を実行する(プロテクトチェック処理プログラム411自身がステップ194を実行しても良い)。

0161

開始されたプロテクトチェック処理は、ルートディレクトリに属する全ファイルについて実行される。

0162

以上のプロテクトチェック処理により、当該ファイルを記憶する一以上のLDEVのプロテクトポイントの合計値が当該ファイルの要求プロテクトポイントに満たない場合には、当該ファイルのコピーが、その合計値がその要求プロテクトポイント以上になるまで実行される。これにより、要求プロテクトポイントを満たす当該ファイルの保護を行うことができる。なお、当該ファイルのコピー中の場合(例えばステップ192を開始した場合)、プロテクトチェック処理プログラム411は、コピー中を管理端末103に通知し、管理端末103が、コピー中を意味する画面(例えば図27C)を表示しても良い。また、そのコピーが完了した場合(例えばステップ194を終えた場合、或いは、プロテクトチェック処理を完了した場合)、プロテクトチェック処理プログラム411は、コピー完了を管理端末103に通知し、管理端末103が、コピー完了を意味する画面(例えば図27D)を表示しても良い。

0163

図14は、排他プロテクトグループの設定の流れの一例を示す。

0164

この流れは、例えば、管理者が管理端末103に対して排他プロテクトグループ設定を指示した場合に開始される。具体的には、例えば、管理者が管理端末103の入力装置179を用いて管理ソフトウェア513を起動した場合に、設定制御プログラム501が、図26Aに例示する管理メニュー画面を表示装置175に表示する。設定制御プログラム501が、管理メニュー画面における“排他プロテクトグループ設定”の選択の入力を管理者から受けた場合、排他プロテクトグループ設定プログラム503をコールする。

0165

ステップ201で、管理端末103において、排他プロテクトグループ設定プログラム503が、LDEV情報取得指示(使用中のLDEVに関する情報の取得指示)を、複数のノード109のうちのいずれかのノード109(例えば所定のノード109)に送信する。以下、図14図15A及び図15Bの説明において、LDEV情報取得指示の送信先ノードを「対象ノード」と呼ぶ。

0166

ステップ202で、対象ノード109において、管理通信プログラム409が、LDEV情報取得指示を受け、該LDEV情報取得指示に従って、使用フラグが使用中を表しているLDEVエントリ(以下、使用中LDEVエントリ)を識別し、識別された一以上の使用中LDEVエントリにそれぞれ対応した一以上の情報群(一つの情報群を「LDEV情報群」と呼ぶ)を、管理端末103に送信する。LDEV情報群には、LDEVエントリに対応したLDEV通番や、LDEVエントリに記録されている情報要素(以下、LDEV情報要素)が含まれている。管理通信プログラム409が、管理端末103との通信のためのエージェントプログラムとして用意されて良い。

0167

ステップ203で、管理端末103において、排他プロテクトグループ設定プログラム503が、対象ノード109から受信した一以上のLDEV情報群を基に、LDEV情報要素を排他プロテクトグループに分けて一覧表示する。排他プロテクトグループ設定プログラム503は、上記受信した一以上のLDEV情報群を基に、図26Bに例示する使用中LDEV情報要素一覧画面を作成して表示することができる。すなわち、一以上のLDEV情報群にそれぞれ対応した一以上のLDEVの各々について、排他プロテクトグループに属しているか否か、属しているのであればどの排他プロテクトグループに属しているか等を、上記受信した一以上のLDEV情報群から識別して、上述の使用中LDEV情報要素一覧画面を作成することができる(例えば、プロテクトポイント(PP)、サブシステムID(SS
ID)及びLDEV番号(LDEV#)が表示される)。排他プロテクトグループ設定プログラム503は、排他プロテクトグループを作成或いは消去することを管理者から受け付けることができる。排他プロテクトグループの作成では、例えば、どの排他プロテクトグループにも属していない複数のLDEVの指定と、グループ作成の指示とを受ける。排他プロテクトグループの消去では、排他プロテクトグループの指定と、グループ消去の指示とを受ける。

0168

管理端末103において、排他プロテクトグループ設定プログラム503は、排他プロテクトグループの作成を管理者から受け付けた場合(ステップ204でYes)、その一つの排他プロテクトグループに含める複数のLDEVにそれぞれ対応した複数のLDEV通番を含んだグループ作成指示を作成し、該作成したグループ作成指示を、対象ノード109に送信する。それら複数のLDEVの各々は、例えば、使用中LDEV情報要素一覧画面上で管理者から指定されたLDEVである。

0169

対象ノード109において、管理通信プログラム409が、グループ作成指示に応答して、グループ作成処理プログラム413をコールする。グループ作成処理プログラム413が、グループ作成処理を実行する(ステップ205)。グループ作成処理プログラム413は、グループ作成処理を終えたならば、管理報告を管理端末103に送信する。

0170

管理端末103において、排他プロテクトグループ設定プログラム503は、排他プロテクトグループの消去を管理者から受け付けた場合(ステップ206でYes)、消去対象の排他プロテクトグループのIDを含んだグループ消去指示を作成し、該グループ消去指示を、対象ノード109に送信する。消去対象の排他プロテクトグループは、例えば、使用中LDEV情報要素一覧画面上で管理者から指定された排他プロテクトグループである。

0171

対象ノード109において、管理通信プログラム409が、グループ消去指示に応答して、グループ消去処理プログラム415をコールする。グループ消去処理プログラム415が、グループ消去処理を実行する(ステップ207)。グループ消去処理プログラム415は、グループ消去処理を終えたならば、完了報告を管理端末103に送信する。

0172

管理端末103において、排他プロテクトグループ設定プログラム503は、終了を管理者から受け付けた場合(ステップ208でYes)、終了となる。

0173

図15Aは、グループ作成処理の流れの一例を示す。

0174

グループ作成処理プログラム413が、未使用の排他プロテクトグループID(例えば番号)を生成する(ステップ211)。使用済みの排他プロテクトグループIDが何であるかは、例えば、LDEV管理テーブル429の全LDEVエントリを参照することで、把握することができるので、把握された使用済みの排他プロテクトグループID以外のIDを生成することができる。

0175

グループ作成処理プログラム413が、上記グループ作成指示に含まれている複数のLDEV通番のうちの一つを選択し(ステップ212)、選択したLDEV通番に対応したLDEVエントリを識別し(ステップ213)、識別したLDEVエントリに、上記生成された未使用の排他プロテクトグループIDを登録する。

0176

ステップ212乃至ステップ214についての処理が、上記グループ作成指示に含まれている複数のLDEV通番の各々について実行される(ステップ215でNo)。それら複数のLDEV通番の全てについて、ステップ212乃至ステップ214が行われた場合(ステップ215でYes)、ステップ216が実行される。すなわち、グループ作成処理プログラム413は、対象ノード以外の全ての他のノードに対して、アップデートされた全てのLDEVエントリの各々に対応したLDEVエントリのアップデートを指示する。具体的には、例えば、グループ作成処理プログラム413は、アップデートされた全てのLDEVエントリの各々についてのLDEV通番とアップデート後の排他プロテクトグループIDとのセットと共にアップデート指示を送信する。これにより、全ての他のノード109が、LDEV通番及びアップデート後の排他プロテクトグループIDのセットを受信し、アップデート指示に応答して、受信したLDEV通番に対応したLDEVエントリに、該LDEV通番に対応したアップデート後の排他プロテクトグループIDを記録する。このため、全てのノード109において、LDEV管理テーブル429の内容が同じになる。

0177

図15Bは、グループ消去処理の流れの一例を示す。

0178

グループ消去処理プログラム415が、LDEV管理テーブル429を上から辿る(先頭から最後尾にかけて順次に辿る)(ステップ221)。

0179

グループ消去処理プログラム415が、このグループ消去処理において未選択のLDEVエントリを選択し(ステップ222)、そのLDEVエントリに記録されている排他プロテクトグループIDが、グループ消去指示に記録されている排他プロテクトグループIDと同じがどうかを判断する(ステップ223)。同じであると判断になれば(ステップ223でYes)、ステップ224に進み、違うとの判断になれば(ステップ223でNo)、ステップ225に進む。

0180

ステップ224で、グループ消去処理プログラム415は、そのLDEVエントリに記録されている排他プロテクトグループIDを、無効を意味する値(例えば“−1”)にアップデートする。

0181

ステップ225で、グループ消去処理プログラム415は、このグループ消去処理において未選択のLDEVエントリが未だ残っているかどうかを判断する。残っているとの判断になれば(ステップ225でYes)、ステップ222に戻り、残っていないとの判断になれば(ステップ225でNo)、ステップ226に進む。

0182

ステップ226で、グループ消去処理プログラム415は、対象ノード以外の全ての他のノードに対して、アップデートされた全てのLDEVエントリの各々に対応したLDEVエントリのアップデートを指示する。具体的には、例えば、グループ消去処理プログラム415は、アップデートされた全てのLDEVエントリの各々についてのLDEV通番とアップデート後の排他プロテクトグループID(無効値)とのセットと共にアップデート指示を送信する。これにより、全ての他のノード109が、LDEV通番及びアップデート後の排他プロテクトグループID(無効値)のセットを受信し、アップデート指示に応答して、受信したLDEV通番に対応したLDEVエントリに、該LDEV通番に対応したアップデート後の排他プロテクトグループID(無効値)を記録する。このため、全てのノード109において、LDEV管理テーブル429の内容が同じになる。なお、アップデート後の排他プロテクトグループID(無効値)を送信することに代えて、例えば、送信したLDEV通番に対応したLDEVエントリの排他プロテクトグループIDを無効値にアップデートする指示が送信されても良い。

0183

図16は、プロテクトポイントの変更の流れの一例を示す。

0184

この流れは、例えば、管理者が管理端末103に対して排他プロテクトグループ設定を指示した場合に開始される。具体的には、例えば、設定制御プログラム501が、図26Aに例示する管理メニュー画面における“プロテクトポイント設定/変更/確認”の選択の入力を管理者から受けた場合、プロテクトポイント管理プログラム505をコールする。

0185

ステップ231で、管理端末103において、プロテクトポイント管理プログラム505が、LDEV情報取得指示(使用中のLDEVに関する情報の取得指示)を、複数のノード109のうちのいずれかのノード109(例えば所定のノード109)に送信する。以下、図16及び図17の説明において、LDEV情報取得指示の送信先ノードを「対象ノード」と呼ぶ。

0186

ステップ232で、対象ノード109において、管理通信プログラム409が、LDEV情報取得指示を受け、該LDEV情報取得指示に従って、使用中LDEVエントリを識別し、識別された一以上の使用中LDEVエントリにそれぞれ対応した一以上のLDEV情報群を、管理端末103に送信する。

0187

ステップ233で、管理端末103において、プロテクトポイント管理プログラム505が、対象ノード109から受信した一以上のLDEV情報群を基に、LDEV情報要素を一覧表示する。例えば、図26Cに例示する使用中LDEV情報要素一覧画面を作成して表示することができる。プロテクトポイント管理プログラム505は、プロテクトポイントの変更対象のLDEVの指定と変更後のプロテクトポイントとを、管理者から受け付けることができる。

0188

管理端末103において、プロテクトポイント管理プログラム505は、プロテクトポイントの変更対象のLDEVの指定と変更後のプロテクトポイントとを管理者から受け付けた場合(ステップ234でYes)、変更後のプロテクトポイントと指定されたLDEVに対応したLDEV通番とを含むプロテクトポイント変更指示を作成し、該プロテクトポイント変更指示を対象ノード109に送信する。変更後のプロテクトポイントと指定されたLDEVのLDEV通番とのセットが複数個ある場合には、それら複数のセットがプロテクトポイント変更指示に含められる。

0189

対象ノード109において、管理通信プログラム409が、プロテクトポイント変更指示に応答して、プロテクトポイント変更処理プログラム417をコールする。プロテクトポイント変更処理プログラム417が、プロテクトポイント変更処理を実行する(ステップ235)。プロテクトポイント変更処理プログラム417は、プロテクトポイント変更処理を終えたならば、完了報告を管理端末103に送信する(ステップ236)。

0190

管理端末103において、プロテクトポイント管理プログラム505は、終了を管理者から受け付けた場合(ステップ237でYes)、終了となる。

0191

以上の処理において、例えば、管理者は、ストレージサブシステム111のリプレースを行う場合、ステップ234において、ストレージサブシステム111のリプレースに先立って、そのストレージサブシステム111が持つ全てのLDEVについて、変更後のプロテクトポイントとして“0”を指定する。この場合、対象ノード109において、後述するプロテクトポイント変更処理が実行され、プロテクトポイント変更処理では、前述したプロテクトチェック処理も実行される。このため、リプレース対象のストレージサブシステムにある全てのLDEV内のデータが、別のストレージサブシステム内のLDEVにコピーされる。その後に、そのリプレース対象のストレージサブシステム111を外すことで、保護対象(ファイルやディレクトリ)に要求される要求プロテクトポイントを満たすことを維持したままストレージサブシステム111のリプレースを行うことができる。

0192

図17は、プロテクトポイント変更処理の流れの一例を示す。

0193

プロテクトポイント変更処理プログラム417は、プロテクトポイント変更指示に含まれている一以上のLDEV通番から一つのLDEV通番を選択し(ステップ241)、選択したLDEV通番に対応したLDEVエントリを識別し(ステップ242)、識別したLDEVエントリに、該選択したLDEV通番に対応する変更後のプロテクトポイントを登録する(ステップ243)。

0194

ステップ241乃至ステップ243についての処理が、上記プロテクトポイント変更指示に含まれている複数のLDEV通番の各々について実行される(ステップ244でNo)。それら複数のLDEV通番の全てについて、ステップ241乃至ステップ243が行われた場合(ステップ244でYes)、ステップ245が実行される。すなわち、プロテクトポイント変更処理プログラム417は、対象ノード以外の全ての他のノードに対して、アップデートされた全てのLDEVエントリの各々に対応したLDEVエントリのアップデートを指示する。具体的には、例えば、プロテクトポイント変更処理プログラム417は、アップデートされた全てのLDEVエントリの各々についてのLDEV通番とアップデート後のプロテクトポイントとのセットと共にアップデート指示を送信する。これにより、全ての他のノード109が、LDEV通番及びアップデート後のプロテクトポイントのセットを受信し、アップデート指示に応答して、受信したLDEV通番に対応したLDEVエントリに、該LDEV通番に対応したアップデート後のプロテクトポイントを記録する。このため、全てのノード109において、LDEV管理テーブル429の内容が同じになる。

0195

その後、プロテクトポイント変更処理プログラム417は、プロテクトチェック処理プログラム411をコールする。コールする契機としては、例えば、全ての他のノードからアップデート完了の報告を受けた契機とすることができる。プロテクトチェック処理プログラム411が、プロテクトチェック処理(図13参照)を実行する。

0196

LDEVのプロテクトポイントが変更されると、該LDEVに記憶されている保護対象(ファイル或いはディレクトリ)の要求プロテクトポイントを満たさなくなるおそれがあるが、プロテクトポイントの変更が行われた場合には、プロテクトチェック処理が実行される。それにより、要求プロテクトポイントを満たさない保護対象がある場合には該保護対象が検出され、該保護対象が別のLDEVにコピーされるので、該保護対象について、要求プロテクトポイントを満たす保護を行うことができる。

0197

図18は、LDEV発見処理の流れの一例を示す。

0198

LDEV発見処理は、発見されたLDEVに関する情報要素を、そのLDEVを有するストレージサブシステム111から取得し、取得した情報要素をLDEV管理テーブル429に登録する処理である。LDEV発見処理は、例えば、新たなLDEVを見つけたノード109においてLDEV発見処理プログラム425が実行する。なお、新たなLDEVは、例えば、ノード109が、各ストレージサブシステム111に所定の問合せコマンド(例えばSCSIのREPORT_LUNSというコマンド)を送信することで、発見することができる。

0199

LDEV発見処理プログラム425は、見つかったLDEV(この図18説明において「対象LDEV」と呼ぶ)に対して、所定の照会コマンド(例えば、SCSIでサポートされているinquiryコマンド及びREAD_CAPACITY)を送信する(ステップ251)。LDEV発見処理プログラム425は、対象LDEVを有するストレージサブシステムのサブシステムIDと、該ストレージサブシステムで管理されているLDEV番号(対象LDEVに対応したLDEV番号)とを含んだレスポンスを、対象LDEVを有するストレージサブシステム111から受信し、該レスポンスから、サブシステムID、LDEV番号及び容量を取得する(ステップ252)。サブシステムID、LDEV番号及び容量の取得は、これに代えて、例えば、管理ソフトウェア513に問合せを出し該問合せに対する応答から取得したり、SCSI mode senseコマンドを利用して取得したり、後に管理者が管理端末513から設定したりしてもよい。

0200

LDEV発見処理プログラム425は、取得したサブシステムID及びLDEV番号がLDEV管理テーブル429に登録済みか否かを判断する(ステップ253)。登録済みとの判断であれば(ステップ253Yes)、終了になり、登録済みではないとの判断であれば(ステップ253でNo)、ステップ254に進む。

0201

LDEV発見処理プログラム425は、使用フラグが無効(例えば“−1”)のLDEVエントリを選択し(ステップ254)、選択したLDEVエントリに、使用フラグとして未使用を意味する値(例えば“0”)を設定する(ステップ255)。また、LDEV発見処理プログラム425は、上記選択したLDEVエントリに、上記取得したサブシステムID、LDEV番号及び容量を登録する(ステップ256)。また、LDEV発見処理プログラム425は、上記選択したLDEVエントリにおいて、管理ノードID及び排他プロテクグループIDとしてそれぞれ無効値(例えば“−1”)を設定し(ステップ257)、プロテクトポイントとして“1”を仮設定し(ステップ258)、空き容量率を“100%”に仮設定する(ステップ259)。なお、例えば、LDEV発見処理プログラム425は、各ストレージサブシステム111に、所定の照会コマンド(例えばInquiryコマンド)を送信することで、各ストレージサブシステム111から、各LDEVに関する情報(例えば、プロテクトポイント、RAIDレベル、空き容量率)を取得し、取得した情報を、上記選択したLDEVエントリに設定しても良い。また、各LDEVのプロテクトポイントについては、例えば、取得した情報に含まれるRAIDレベルなどを基に、LDEV発見処理プログラム425が決定して設定してもよい。

0202

ステップ260で、LDEV発見処理プログラム425は、このLDEV発見処理を行っているノード以外の全ての他のノードに対して、アップデートされた全てのLDEVエントリの各々に対応したLDEVエントリのアップデートを指示する。具体的には、例えば、LDEV発見処理プログラム425は、アップデートされた全てのLDEVエントリの各々についてのLDEV通番とアップデート後の情報要素とのセットと共にアップデート指示を送信する。これにより、全ての他のノード109が、LDEV通番及びアップデート後の情報要素のセットを受信し、アップデート指示に応答して、受信したLDEV通番に対応したLDEVエントリに、該LDEV通番に対応したアップデート後の情報要素(例えば、使用フラグ“0”、サブシステムID、LDEV番号、容量、管理ノードID“−1”、排他プロテクトグループID“−1”、プロテクトポイント“1”、空き容量率“100%”)を記録する。

0203

図19は、LDEV有効化の流れの一例を示す。

0204

この流れは、例えば、管理者が管理端末103に対してLDEV有効化を指示した場合に開始される。具体的には、例えば、設定制御プログラム501が、図26Aに例示する管理メニュー画面における“LDEV有効化”の選択の入力を管理者から受けた場合、LDEV有効化プログラム507をコールする。

0205

ステップ271で、管理端末103において、LDEV有効化プログラム507が、LDEV情報取得指示(未使用のLDEVに関する情報の取得指示)を、複数のノード109のうちのいずれかのノード109(例えば任意のノード109)に送信する。以下、図19及び図20の説明において、LDEV情報取得指示の送信先ノードを「対象ノード」と呼ぶ。

0206

ステップ272で、対象ノード109において、管理通信プログラム409が、LDEV情報取得指示を受け、該LDEV情報取得指示に従って、未使用LDEVエントリを識別し、識別された一以上の未使用LDEVエントリにそれぞれ対応した一以上のLDEV情報群を、管理端末103に送信する。

0207

ステップ273で、管理端末103において、LDEV有効化プログラム507が、対象ノード109から受信した一以上のLDEV情報群を基に、LDEV情報要素を一覧表示する。例えば、図26Dに例示する未使用LDEV情報要素一覧画面を作成して表示することができる。LDEV有効化プログラム507は、有効とする未使用LDEVの指定と該LDEVに関連付けるプロテクトポイントとを、管理者から受け付けることができる。

0208

管理端末103において、LDEV有効化プログラム507は、有効とする未使用LDEVの指定と該LDEVに関連付けるプロテクトポイントとを管理者から受け付けた場合(ステップ274でYes)、該未使用LDEVに対応するLDEV情報群から管理ノードIDを取得する(ステップ275)。そして、LDEV有効化プログラム507は、プロテクトポイントと未使用LDEVのLDEV通番とを含むLDEV有効化指示を作成し、該取得した管理ノードIDに対応した管理ノードに、該作成したLDEV有効化指示を送信する。なお、例えば、LDEV有効化プログラム507は、所定の照会コマンド(例えばInquiryコマンド)に応答してプロテクトポイントがストレージサブシステム111から取得できた場合には、LDEV有効化指示にプロテクトポイントが含まれなくて良い。

0209

対象ノード109において、管理通信プログラム409が、LDEV有効化指示に応答して、LDEV有効化処理プログラム421をコールする。LDEV有効化処理プログラム421が、LDEV有効化処理を実行する(ステップ277)。LDEV有効化処理プログラム421は、LDEV有効化処理を終えたならば、完了報告を管理端末103に送信する(ステップ278)。

0210

管理端末103において、LDEV有効化プログラム507は、終了を管理者から受け付けた場合(ステップ279でYes)、終了となる。

0211

図20は、LDEV有効化処理の流れの一例を示す。

0212

LDEV有効化処理プログラム421が、LDEV有効化指示に含まれているLDEV通番に対応したLDEVエントリを識別し(ステップ281)、該LDEVエントリにおいて、使用中フラグとして使用中を表す値(例えば“1”)を設定する(ステップ282)。また、LDEV有効化処理プログラム421は、該LDEVエントリにおいて、管理ノードIDとして、対象ノード109(このLDEV有効化処理プログラム421を実行している自ノード)のIDを設定する(ステップ283)。また、LDEV有効化処理プログラム421は、LDEV有効化指示に含まれているLDEV通番に対応したファイルデータ管理テーブル435及びLDEV空きブロックビットマップ437を初期化する(ステップ284)。

0213

LDEV有効化処理プログラム421は、対象ノード以外の全ての他のノードに対して、アップデートされた全てのLDEVエントリの各々に対応したLDEVエントリのアップデートを指示する(ステップ285)。具体的には、例えば、LDEV有効化処理プログラム421は、アップデートされた全てのLDEVエントリの各々についてのLDEV通番とアップデート後の情報要素とのセットと共にアップデート指示を送信する(該アップデート指示を受けた他のノードで実行される処理については既に説明済みなので、ここでは省略する)。

0214

その後、プロテクトポイント変更処理プログラム417は、プロテクトチェック処理プログラム411をコールする。コールする契機としては、例えば、全ての他のノードからアップデート完了の報告を受けた契機とすることができる。プロテクトチェック処理プログラム411が、プロテクトチェック処理(図13参照)を実行する。なお、LDEV有効化処理において、必ずしもプロテクトチェック処理は行われなくても良い。

0215

図21は、LDEV無効化の流れの一例を示す。

0216

この流れは、例えば、管理者が管理端末103に対してLDEV無効化を指示した場合に開始される。具体的には、例えば、設定制御プログラム501が、図26Aに例示する管理メニュー画面における“LDEV無効化”の選択の入力を管理者から受けた場合、LDEV無効化プログラム509をコールする。

0217

ステップ291で、管理端末103において、LDEV無効化プログラム509が、LDEV情報取得指示(使用中のLDEVに関する情報の取得指示)を、複数のノード109のうちのいずれかのノード109(例えば任意のノード109)に送信する。以下、図21及び図22の説明において、LDEV情報取得指示の送信先ノードを「対象ノード」と呼ぶ。

0218

ステップ292で、対象ノード109において、管理通信プログラム409が、LDEV情報取得指示を受け、該LDEV情報取得指示に従って、使用中LDEVエントリを識別し、識別された一以上の使用中LDEVエントリにそれぞれ対応した一以上のLDEV情報群を、管理端末103に送信する。

0219

ステップ293で、管理端末103において、LDEV無効化プログラム509が、対象ノード109から受信した一以上のLDEV情報群を基に、LDEV情報要素を一覧表示する。例えば、図27Aに例示する使用中LDEV情報要素一覧画面を作成して表示することができる。LDEV無効化プログラム509は、無効とする未使用LDEVの指定を、管理者から受け付けることができる(プロテクトポイントの指定も受けても良い)。

0220

管理端末103において、LDEV無効化プログラム507は、無効とする使用中LDEVの指定を管理者から受け付けた場合(ステップ294でYes)、該使用中LDEVに対応するLDEV情報群から管理ノードIDを取得する(ステップ295)。そして、LDEV無効化プログラム507は、使用中LDEVのLDEV通番を含むLDEV無効化指示を作成し、該取得した管理ノードIDに対応した管理ノードに、該作成したLDEV無効化指示を送信する。

0221

対象ノード109において、管理通信プログラム409が、LDEV無効化指示に応答して、LDEV無効化処理プログラム423をコールする。LDEV無効化処理プログラム423が、LDEV無効化処理を実行する(ステップ297)。LDEV無効化処理プログラム423は、LDEV無効化処理を終えたならば、完了報告を管理端末103に送信する(ステップ298)。

0222

管理端末103において、LDEV無効化プログラム509は、終了を管理者から受け付けた場合(ステップ299でYes)、終了となる。

0223

図22は、LDEV無効化処理の流れの一例を示す。

0224

LDEV無効化処理とは、指定されたLDEV内のデータを無効にするための処理である。

0225

LDEV無効化処理プログラム423は、LDEV無効化指示に含まれているLDEV通番に対応したLDEVエントリを識別し(ステップ301)、該LDEVエントリにおいて、使用中フラグとして未使用を表す値(例えば“0”)を設定する(ステップ302)。

0226

LDEV無効化処理プログラム423は、ディレクトリ管理テーブル431におけるディレクトリエントリをルートから辿る(ステップ303)。

0227

その結果、このLDEV無効化処理において未選択のディレクトリエントリがあれば(ステップ304でYes)、LDEV無効化処理プログラム423は、該ディレクトリエントリを選択する(ステップ305)。

0228

LDEV無効化処理プログラム423は、ステップ305で選択したディレクトリエントリのファイル番号リストにおいて、このLDEV無効化処理において一以上の未選択のファイル通番があれば(ステップ306でYes)、その一以上のファイル通番から一つのファイル通番を選択し(ステップ307)、選択したファイル通番に対応したファイルエントリを識別する(ステップ308)。

0229

LDEV無効化処理プログラム423は、そのファイルエントリの格納位置リストに、このLDEV無効化処理において一以上の未選択のサブエントリ(格納位置)があれば(ステップ309でYes)、一以上の未選択のサブエントリから一つのサブエントリを選択し、そのサブエントリにある格納LDEV通番に対応したLDEVエントリを識別する(ステップ310)。そして、LDEV無効化処理プログラム423は、その識別されたLDEVエントリが使用中LDEVエントリであれば(ステップ311でYes)、ステップ309に戻り、未使用LDEVエントリであれば(ステップ311でNo)、当該格納位置(上記選択したサブエントリ)を削除して(ステップ312)、ステップ309に戻る。ステップ312により、削除されたサブエントリの次以降のサブエントリが一つずつ上にずれる。具体的には、例えば、削除対象のサブエントリに記録されている情報に、そのサブエントリの次のサブエントリに記録されている情報が上書きされる。

0230

ステップ308で識別されたファイルエントリの格納位置に、このLDEV無効化処理において未選択のサブエントリ(格納位置)がなくなるまで、ステップ309〜ステップ312の処理が繰り返され、なくなったら、ステップ306に戻る。ステップ306でYesになれば、ステップ307が実行され、ステップ306でNoになれば、ステップ304に戻る。そして、ステップ304でYesとなれば、ステップ305が実行されるが、ステップ306でNoとなれば、ステップ313に進む。

0231

ステップ313では、LDEV無効化処理プログラム423は、LDEV無効化指示に含まれているLDEV通番に対応したファイルデータ管理テーブル435及びLDEV空きブロックビットマップ437を初期化する。

0232

ステップ314で、LDEV無効化処理プログラム423は、対象ノード以外の全ての他のノードに対して、アップデートされた全てのLDEVエントリ及びファイルエントリの各々に対応したLDEVエントリ及びファイルエントリのアップデートを指示する。

0233

要するに、このLDEV無効化処理では、LDEVエントリの使用中フラグが使用中から未使用に変更されたLDEVに記憶されているデータに関して管理されている情報が破棄される。その後に、LDEV無効化処理プログラム423は、プロテクトチェック処理プログラム411をコールする。コールする契機としては、例えば、全ての他のノードからアップデート完了の報告を受けた契機とすることができる。プロテクトチェック処理プログラム411が、プロテクトチェック処理(図13参照)を実行する。

0234

LDEVが無効にされると、該LDEVに記憶されている保護対象(ファイル或いはディレクトリ)の要求プロテクトポイントを満たさなくなるおそれがあるが、LDEV無効化処理が行われた場合には、プロテクトチェック処理が実行される。それにより、要求プロテクトポイントを満たさない保護対象がある場合には該保護対象が検出され、該保護対象が別のLDEVにコピーされるので、該保護対象について、要求プロテクトポイントを満たす保護を行うことができる。

0235

図23は、要求プロテクトポイントの変更の流れの一例を示す。

0236

この流れは、例えば、管理者が管理端末103に対して要求プロテクトグループ変更を指示した場合に開始される。具体的には、例えば、設定制御プログラム501が、図26Aに例示する管理メニュー画面における“要求プロテクトポイント設定/変更/確認”の選択の入力を管理者から受けた場合、要求プロテクトポイント管理プログラム511をコールする。

0237

ステップ321で、管理端末103において、要求プロテクトポイント管理プログラム511が、ディレクトリ・ファイル情報取得指示を、複数のノード109のうちのいずれかのノード109(例えば任意のノード109)に送信する。以下、図23及び図24の説明において、ディレクトリ管理テーブル取得指示の送信先ノードを「対象ノード」と呼ぶ。

0238

ステップ322で、対象ノード109において、管理通信プログラム409が、ディレクトリ・ファイル情報取得指示を受け、該指示に従って、ディレクトリ・ファイル情報(ディレクトリ管理テーブル431の全ディレクトリエントリに記録されている全ての情報要素と、ファイル管理テーブル433の全てのファイルエントリに記録されている全ての情報要素)を、管理端末103に送信する。

0239

ステップ323で、管理端末103において、要求プロテクトポイント管理プログラム511が、対象ノード109からディレクトリ・ファイル要素を基に、各ディレクトリと各ファイルの関係(どのディレクトリにどのファイルが格納されているか)や、各ディレクトリ及び各ファイルの要求プロテクトポイントを把握し、ディレクトリ及びファイルとそれぞれの要求プロテクトポイントをツリー表示する。ツリー表示の画面の一例として、図27Bに例示する画面がある。この画面が、要求プロテクトポイント管理プログラム511によって生成されて表示される。ツリー表示とは、ディレクトリ及びファイルの関係をツリー構造で示し、且つ、ディレクトリ及びファイルを表すそれぞれのマークの中(或いはその傍)に、要求プロテクトポイントを示した表示である。ツリー表示に代えて、どのディレクトリにどのファイルが格納されていて各ディレクトリや各ファイルの要求プロテクトポイントが何であるかが示された他種の表示が採用されても良い。また、図27Bの例では、見易くするために、ディレクトリ及びファイルのそれぞれのマークや、各マークの中に示される文字(例えば、ディレクトリ名或いはファイル名と要求プロテクトポイント)を大きく記載し、故に、ツリー構造における狭い範囲しか示されていないが、実際には、一画面でより広範囲を示すことが可能である(この点は、例えば、前述した使用中LDEV或いは未使用LDEVに関する情報要素一覧の表示でも同様とすることができる)。

0240

管理端末103において、要求プロテクトポイント管理プログラム511は、要求プロテクトポイントの変更対象のディレクトリ或いはファイルの指定と変更後の要求プロテクトポイントとを管理者から受け付けた場合(ステップ324でYes)、変更後の要求プロテクトポイントと指定されたディレクトリ或いはファイルに対応したディレクトリ通番或いはファイル通番とを含む要求プロテクトポイント変更指示を作成し、該要求プロテクトポイント変更指示を対象ノード109に送信する。変更後の要求プロテクトポイントと指定されたディレクトリ或いはファイルのディレクトリ通番或いはファイル通番とのセットが複数個ある場合には、それら複数のセットが要求プロテクトポイント変更指示に含められてもよい。

0241

対象ノード109において、管理通信プログラム409が、要求プロテクトポイント変更指示に応答して、要求プロテクトポイント変更処理プログラム419をコールする。要求プロテクトポイント変更処理プログラム419が、要求プロテクトポイント変更処理を実行する(ステップ325)。要求プロテクトポイント変更処理プログラム419は、要求プロテクトポイント変更処理を終えたならば、完了報告を管理端末103に送信する(ステップ326)。

0242

管理端末103において、要求プロテクトポイント管理プログラム511は、終了を管理者から受け付けた場合(ステップ327でYes)、終了となる。

0243

図24は、要求プロテクトポイント変更処理の流れの一例を示す。

0244

要求プロテクトポイント変更処理プログラム419は、要求プロテクトポイント変更指示に含まれている通番がディレクトリ通番であるかファイル通番であるかを判断する(ステップ331)。該通番がディレクトリ通番であるかファイル通番であるかは、例えば、管理端末103において、要求プロテクトポイント管理プログラム511が、要求プロテクトポイント変更指示に、通番がディレクトリ通番であるかファイル通番であるかを意味する情報を含めれば、要求プロテクトポイント変更処理プログラム419が、その情報を解析することで、判断することができる。ファイル通番であるとの判断になれば(ステップ331でYes)、ステップ332にすすみ、ディレクトリ通番であるとの判断になれば(ステップ331でNo)、ステップ333にすすむ。

0245

ステップ332で、要求プロテクトポイント変更処理プログラム419は、ファイル通番に対応するファイルエントリを識別する。一方、ステップ333では、要求プロテクトポイント変更処理プログラム419は、ディレクトリ通番に対応するディレクトリエントリを識別する。

0246

ステップ334で、要求プロテクトポイント変更処理プログラム419は、識別されたファイルエントリ或いはディレクトリエントリにおける要求プロテクトポイントを指定値に設定する。つまり、該要求プロテクトポイントに、上記要求プロテクトポイント変更指示に含まれている変更後の要求プロテクトポイントを上書きする。

0247

ステップ335で、要求プロテクトポイント変更処理プログラム419は、対象ノード以外の全ての他のノードに対して、アップデートされたファイルエントリ或いはディレクトリエントリの各々に対応したファイルエントリ或いはディレクトリエントリのアップデートを指示する。

0248

上記要求プロテクトポイント変更指示に、変更後の要求プロテクトポイントと指定されたディレクトリ或いはファイルのディレクトリ通番或いはファイル通番とのセットが複数個含まれている場合には、各セットについて、上述したステップ331〜ステップ335の処理が実行されて良い。

0249

ステップ335の後に、要求プロテクトポイント変更処理プログラム419は、プロテクトチェック処理プログラム411をコールする。コールする契機としては、例えば、全ての他のノードからアップデート完了の報告を受けた契機とすることができる。プロテクトチェック処理プログラム411が、プロテクトチェック処理(図13参照)を実行する。

0250

要求プロテクトポイントが変更されると、LDEVに記憶されている保護対象(ファイル或いはディレクトリ)の要求プロテクトポイントを満たさなくなるおそれがあるが、要求プロテクトポイント変更処理が行われた場合には、プロテクトチェック処理が実行される。それにより、要求プロテクトポイントを満たさない保護対象がある場合には該保護対象が検出され、該保護対象が別のLDEVにコピーされるので、該保護対象について、要求プロテクトポイントを満たす保護を行うことができる。

0251

図25は、空き容量率計算処理の流れの一例を示す。

0252

空き容量率計算処理とは、ノード109において、該ノード109が管理しているLDEVの空き容量率を計算し、該LDEVに対応したLDEVエントリにおける空き容量率を、算出された空き容量率にアップデートする処理である。空き容量率計算処理は、空き容量率計算処理プログラム427により、定期的に又は不定期的に(例えば30分毎に)実行される。

0253

空き容量率計算処理プログラム427は、LDEV管理テーブル429を上から辿る(先頭から最後尾にかけて順次に辿る)(ステップ341)。

0254

空き容量率計算処理プログラム427が、この空き容量率計算処理において未選択のLDEVエントリを選択し(ステップ342)、そのLDEVエントリに記録されている使用中フラグ及び管理ノードIDから、該LDEVエントリに対応したLDEV(以下、当該LDEV)は使用中LDEVであって、当該LDEVを管理しているノード109が自ノード(この空き容量率計算処理プログラム427を実行しているノード)であるか否かを判断する(ステップ343)。使用中LDEV且つ自ノードとの判断になれば(ステップ343でYes)、ステップ344に進み、そのような判断にならなければ(ステップ343でNo)、ステップ347に進む。

0255

ステップ344で、空き容量率計算処理プログラム427は、当該LDEVに対応するLDEV空きブロックビットマップ437を識別する。ステップ345で、空き容量率計算処理プログラム427は、識別したLDEV空きブロックビットマップ437の全ビット数に対する値“1”(空きを意味する値)の数の割合(空き容量率(%))を計算する。ステップ346で、空き容量率計算処理プログラム427は、算出された空き容量率を、当該LDEVに対応するLDEVエントリのける空き容量率に上書きする。

0256

ステップ347で、空き容量率計算処理プログラム427は、この空き容量率計算処理において未選択のLDEVエントリが未だ残っているかどうかを判断する。残っているとの判断であれば(ステップ347でYes)、ステップ342に戻り、残っていないとの判断になれば(ステップ347でNo)、ステップ348にすすむ。

0257

ステップ348で、空き容量率計算処理プログラム427は、自ノード以外の全ての他のノードに対して、アップデートされたLDEVエントリに対応したLDEVエントリのアップデートを指示する。

0258

以上が、第一の実施形態の説明である。

0259

<第二の実施形態>。

0260

以下、本発明の第二の実施形態を説明する。その際、第一の実施形態との相違点を主に説明し、共通点については、説明を省略或いは簡略する。このことは、後述の第三及び第四の実施形態の説明でも同様である。

0261

図28は、本発明の第二実施形態におけるストレージシステムの構成例を示す。

0262

ストレージシステム107´は、コントローラ307´と複数のディスク装置303を備えたディスクアレイ装置として構成することができる。

0263

コントローラ307´は、例えば、NAS(Network Attached Storage)としてのサービスを提供するためのチャネルアダプタNAS(以下、E−NAS(Embedded NAS))627を複数個と、ディスクアダプタ(DKA)622を複数個と、サービスプロセッサSVP)623と、キャッシュメモリ624と、共有メモリ625と、接続部626とを備えている。

0264

各E−NAS627は、各ノード109と同様の機能を有することができる。E−NAS627は、例えば、CPUやメモリ等を備えたマイクロコンピュータシステム(例えば回路基板)として構成されており、ホスト101から受信した各種コマンドを解釈して実行することができる。E−NAS627は、ホスト101からファイルレベルでのI/Oコマンド(例えば、ファイル名と、そのファイル名を持つファイルをリード又はライトする命令とを含んだコマンド、以下、「ファイルI/Oコマンド」と言う)を受けて、そのファイルI/OコマンドをブロックレベルのI/Oコマンドに変換して、DKA622に送信することができる。

0265

DKA622は、CPUやメモリ等を備えたマイクロコンピュータシステム(例えば回路基板)として構成することができる。DKA622は、E−NAS627からブロックレベルのI/Oコマンドを受信し、該I/Oコマンドを用いて、複数のディスク装置303上のLDEVにアクセスすることができる。

0266

SVP623は、例えば、入出力コンソール制御コンソールとを備えた装置(例えばパーソナルコンピュータ)であっても良いし、入出力コンソールを管理端末103とし管理端末103に接続された制御コンソール(例えばいわゆるマザーボード)であっても良い。SVP23は、E−NAS627及びDKA622に、種々の命令を送信することにより、E−NAS627及びDKA622を制御することができる。また、SVP623は、ストレージシステム107´内の障害発生監視してコンソール(例えば管理端末13が備える表示装置175)に表示させたり、コンソールからの指令に基づいてディスク装置の閉塞処理等を指示したりすることができる。

0267

キャッシュメモリ624は、ホスト101から受信したデータや、LDEVから読み出されたデータを一時的に記憶するためのものである。共有メモリ625は、複数のE−NAS627及び複数のDKA622に共有される。共有メモリ625には、前述した複数種類のテーブルのうち、全E−NAS627(ノード109)で同じ内容となる種類のテーブル、すなわち、LDEV管理テーブル429、ディレクトリ管理テーブル431、ファイル管理テーブル433が記憶されて良い。そして、各E−NAS627のメモリに、そのE−NAS627の管理対象のLDEVに対応したファイルデータ管理テーブル435及びLDEV空きブロックビットマップ437が記憶されて良い。勿論、そのテーブル435及びビットマップ437も、共有メモリ625に記憶されて良いし、逆に、各テーブル429、431及び433が、各E−NAS627のメモリに記憶されても良い。また、キャッシュメモリ624及び共有メモリ625は、必ずしも物理的に別々のメモリである必要は無い。

0268

接続部626は、E−NAS627、DKA622、キャッシュメモリ624、及び共有メモリ625を相互に接続させる。接続部626は、例えば、高速スイッチング動作によってデータ伝送を行う超高速クロスバスイッチ等のような高速バスとして構成することができる。

0269

<第三の実施形態>。

0270

第三の実施形態では、保護対象の要求プロテクトポイントに比して過剰な保護がされている場合には、保護対象のマイグレーション、或いは保護対象の削除を実行することで、保護の過剰度合いを低くし、以って、消費記憶容量を節約することができる。

0271

例えば、プロテクトポイント変更処理或いは、要求プロテクトポイント変更処理において、図30Aに例示するように、図17のステップ245の後、又は、図24のステップ335の後に、保護対象Xを記憶する一以上のLDEVのプロテクトポイント合計(PP合計)と保護対象Xの要求プロテクトポイントとの差がより大になったか否かが判断される。例えば、プロテクトポイントが低くされた場合、或いは、要求プロテクトポイントが高くされた場合に、差はより大となる。差がより大と判断されなかった場合、プロテクトチェック処理が実行され、差がより大と判断された場合、消費容量節約処理が実行される。消費容量節約処理は、例えば、図30Bに例示するように、消費容量節約処理プログラム431によって実行される。このプログラム431は、例えば、ノード109の記憶資源277に記憶され、ノード109のCPU273で実行される。

0272

消費容量節約処理プログラム431は、LDEV管理テーブル428やファイル管理テーブル433などを用いて、保護対象Xの削除が可能か否かを判断する(ステップ411)。具体的には、例えば、複数の保護対象Xをそれぞれ記憶する複数のLDEVのうちの少なくとも一つから保護対象Xを削除しても、保護対象Xの要求プロテクトポイントを満たす保護を維持することが可能か否かを判断する。可能との判断になれば、ステップ412に進み、不可能との判断になれば、ステップ413に進む。

0273

ステップ412では、消費容量節約処理プログラム431は、それら複数のLDEVのうち、プロテクトポイント合計が要求プロテクトポイント未満とならない範囲でのプロテクトポイントに対応したLDEV(例えば、その範囲で最もプロテクトポイントの高いLDEV)から、保護対象Xを削除する。これにより、保護対象Xについての消費記憶容量を節約することができる。

0274

ステップ413では、消費容量節約処理プログラム431は、保護対象Xのマイグレーションが可能か否かを判断する。具体的には、例えば、以下の(1)乃至(3)の条件を満たすLDEV
Y、
(1)保護対象Xのサイズ以上の空き記憶量を有する、
(2)保護対象 Xを記憶しているLDEV Xよりも低いプロテクトポイントが関連付けられている、
(3)LDEV Xからの保護対象Aのマイグレーション先となっても、プロテクトポイント合計が保護対象Xの要求プロテクトポイント以上のままである、
の有無を、判断する。有れば、消費容量節約処理プログラム431は、保護対象XをLDEV
Xから上述した条件(1)乃至(3)を満たすLDEV Yにマイグレーションする。これにより、プロテクトポイントが高いLDEV Xの消費記憶容量を節約することができる。

0275

<第四の実施形態>
第四の実施形態では、図32に例示するように、冗長性と消費記憶容量節約とのうちのどちらを重視するかによって、保護対象の記憶制御を違えることができる。この記憶制御は、例えば、ホストライト処理やプロテクトチェック処理において実行することができる。

0276

例えば、冗長性重視であれば、保護対象Xが、なるべく多くのLDEVに格納される。具体的には、例えば、ホストライト処理プログラム401或いはプロテクトチェック処理プログラム411は、保護対象Xの要求プロテクトポイント以上のプロテクトポイントが関連付けられているLDEV
Xがあっても、そのLDEV Xではなく、そのLDEV Xよりもプロテクトポイントが低い複数のLDEVをそれぞれ保護対象Xのライト先とする(勿論、この場合は、プロテクトポイント合計が要求プロテクトポイント以上になるライト先を決定する)。これにより、保護対象Xを記憶するLDEVに障害が生じてそのLDEVから保護対象Xが消えてしまっても、なるべく多くのLDEVに保護対象Xを残すことができる。

0277

一方、例えば、消費記憶容量節約重視であれば、保護対象Xが、なるべく少ないLDEVに格納される。具体的には、例えば、ホストライト処理プログラム401或いはプロテクトチェック処理プログラム411は、保護対象Xの要求プロテクトポイント以上のプロテクトポイントが関連付けられている一つのLDEV
Xがあるならば、そのLDEV Xよりもプロテクトポイントが低い複数のLDEVをそれぞれ保護対象Xのライト先とすることで、プロテクトポイント合計が要求プロテクトポイント以上になる記憶制御を行えたとしても、LDEV
Xに保護対象Xをライトする。これにより、保護対象Xについての消費記憶容量を節約することができる。なお、消費記憶容量節約重視であれば、例えば、上記第三の実施形態で説明した消費記憶容量節約処理が実行されても良い。

0278

冗長性と消費記憶容量節約とのうちのどちらを重視するかは、予め管理者によって設定されたポリシーから判断されても良いし、保護対象の属性を基にコンピュータプログラム(例えばホストライト処理プログラム401或いはプロテクトチェック処理プログラム411)によって決定されても良い。

0279

以上、本発明の幾つかの好適な実施形態を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

0280

例えば、前述した実施形態では、排他プロテクトグループに含める二以上のLDEVを管理者が決めることができるが、それに代えて、排他プロテクトグループに含まれる二以上のLDEVは自動で決定されても良い。例えば、同一のRAIDグループに属する二以上のLDEVが自動的に排他プロテクトグループに属する二以上のLDEVとされても良い。

0281

また、例えば、プロテクトチェック処理において、コピー完了は、コピー先のLDEVにデータが格納されたときに代えて、コピー先のLDEVにデータを格納するノード109が記憶したとき、としてもよい。具体的には、例えば、LDEV
AをノードAが管理し、LDEV BをノードBが管理し、LDEV A内のコピー対象データコピー対象の保護対象を構成するブロックデータ)をLDEV Bにコピーする場合には、ノードAが、コピー対象データをLDEV Aから読出し読み出したコピー対象データをノードBに転送し、ノードBが、ノードAからのコピー対象データを記憶資源277で一時的に記憶し、一時的に記憶したコピー対象データをLDEV
Bに書込むことができるが、この一連のコピーにおいて、コピー対象データをLDEV
Bに書込んだときを、コピー完了としても良いし、コピー対象データをノードBが一時的に記憶したときを、コピー完了としても良い。

図面の簡単な説明

0282

図1は、本発明の第一の実施形態に係るコンピュータシステムの構成例を示す。
図2は、ノードとLDEVとの論理的な関係の一例を示す図である。
図3は、ノードによって実行される記憶制御の一例の概要を示す。
図4Aは、管理端末のハードウェア構成例を示す。図4Bは、ストレージサブシステム111のハードウェア構成例を示す。図4Cは、RAIDグループとLDEVとの関係例を示す。図4Dは、ノードのハードウェア構成例を示す。
図5は、管理端末の記憶資源に記憶される管理ソフトウェアを示す。
図6は、ノードの記憶資源に記憶されるコンピュータプログラムや情報を示す。
図7Aは、LDEV管理テーブルの構成例を示す。図7Bは、ディレクトリ管理テーブルの構成例を示す。
図8Aは、ファイル管理テーブルの構成例を示す。図8Bは、ファイルデータ管理テーブルの構成例を示す。図8Cは、LDEV空きブロックビットマップの構成例を示す。
図9は、ホストライト処理の流れの一例を示す。
図10は、ノードライト処理の流れの一例を示す。
図11は、ホストリード処理の流れの一例を示す。
図12は、ノードリード処理の流れの一例を示す。
図13は、プロテクトチェック処理の流れの一例を示す。
図14は、排他プロテクトグループの設定の流れの一例を示す。
図15Aは、グループ作成処理の流れの一例を示す。図15Bは、グループ消去処理の流れの一例を示す。
図16は、プロテクトポイントの変更の流れの一例を示す。
図17は、プロテクトポイント変更処理の流れの一例を示す。
図18は、LDEV発見処理の流れの一例を示す。
図19は、LDEV有効化の流れの一例を示す。
図20は、LDEV有効化処理の流れの一例を示す。
図21は、LDEV無効化の流れの一例を示す。
図22は、LDEV無効化処理の流れの一例を示す。
図23は、要求プロテクトポイントの変更の流れの一例を示す。
図24は、要求プロテクトポイント変更処理の流れの一例を示す。
図25は、空き容量率計算処理の流れの一例を示す。
図26Aは、管理メニュー画面の一例を示す。図26Bは、排他プロテクトグループの設定の流れにおいて表示される使用中LDEV情報要素一覧画面の一例を示す。図26Cは、プロテクトポイントの変更の流れにおいて表示される使用中LDEV情報要素一覧画面の一例を示す。図26Dは、LDEV有効化の流れにおいて表示される未使用LDEV情報要素一覧画面の一例を示す。
図27Aは、LDEV無効化の流れにおいて表示される使用中LDEV情報要素一覧画面の一例を示す。図27Bは、ディレクトリ・ファイルの構造を表示した画面の一例を示す。図27Cは、コピー中であること意味する画面の一例である。図27Dは、コピーが完了したことを意味する画面の一例である。
図28は、本発明の第二実施形態におけるストレージシステムの構成例を示す。
図29Aは、保護対象に要求プロテクトポイントを設定する方法の一例の説明図である。図29Bは、ファイルの要求プロテクトポイントを制御する方法の一例の説明図である。
図30Aは、本発明の第三の実施形態においてプロテクトチェック処理と消費記憶容量節約処理とのいずれを行うかを決定する処理の説明図である。図30Bは、消費記憶容量節約処理の説明図である。
図31Aは、ファイルに要求プロテクトポイントが設定されていない場合にはディレクトリの要求プロテクトポイントが該ファイルに反映されることを表す図である。図31Bは、ファイルに要求プロテクトポイントが設定されている場合にはディレクトリの要求プロテクトポイントに関わらず該ファイルの要求プロテクトポイントが維持されることを表す図である。
図32は、本発明の第四の実施形態において、冗長性と消費記憶容量節約とのうちのどちらを重視するかによって保護対象の記憶制御が異なることの説明図である。

符号の説明

0283

101…ホストコンピュータ103…管理端末107…ストレージシステム109…ノード111…ストレージサブシステム

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ