JP2010198383A - ストレージ装置、ソフトウェア更新方法およびソフトウェア更新プログラム - Google Patents

Abstract

【課題】短い運用停止時間でコンテンツ管理ソフトウェアをバージョンアップすることができるストレージ装置、ソフトウェア更新方法およびソフトウェア更新プログラムを提供すること。
【解決手段】コンテンツ管理ソフトウェアがバージョンアップされる場合に、構成定義テーブルを更新せず、現にインストールされているコンテンツ管理ソフトウェアを残したままにして、新バージョンのコンテンツ管理ソフトウェアをインストールし、既存のコンテンツが新バージョンによって管理されるように、運用中に徐々に構成定義テーブルを更新する。
【選択図】図１

Description

本発明は、ストレージ装置、ソフトウェア更新方法およびソフトウェア更新プログラムに関する。

近年、改変しないデータ（「フィックスコンテンツ」と呼ばれる）を長期的に保存することに適したオブジェクトアクセス型ストレージ（以下、「ＣＡＳ：Content Aware Storage」という）と呼ばれるストレージ装置がある。ＣＡＳは、ＳＡＮ（Storage Area Network）や、ＮＡＳ（Network Attached Storage）と異なるアクセス方式を採用する。

図１１を用いて具体的に説明する。図１１は、ＣＡＳのアクセス方式を説明するための図である。図１１に示すように、ＳＡＮは、ブロックアクセス型のアクセス方式によりデータアクセスを行い、ＮＡＳは、ファイルアクセス型のアクセス方式によりデータアクセスを行う。一方、ＣＡＳは、コンテンツオブジェクトアクセス型のアクセス方式を採用しており、コンテンツと呼ばれる単位でデータアクセスを行う。

コンテンツとは、データ（例えば、画像データ等）と、かかるデータの属性（例えば、サイズや更新日時等）とをパッケージ化した情報である。ＣＡＳは、各コンテンツにＩＤ（以下、「コンテンツＩＤ」という）を付与して、コンテンツＩＤを用いて各コンテンツにアクセスを行う。

ここで、従来のＣＡＳの構成について説明する。図１２は、従来のＣＡＳの構成を示す図である。図１２に示すように、従来のＣＡＳ９００は、記憶装置９１０と、コンテンツ管理ソフトウェア９２０とを有する。記憶装置９１０は、コンテンツを記憶する装置であり、図１２に示した例では、磁気ディスク９１１と、磁気テープ９１２ａおよび９１２ｂとを有する。

コンテンツ管理ソフトウェア９２０は、記憶装置９１０へのアクセス制御を行い、構成定義記憶部９３０と、コンテンツ管理サービス９４０とを有する。構成定義記憶部９３０は、コンテンツの構成に関する各種情報を記憶する記憶デバイスであり、コンテンツ管理テーブル９３１と、業務ポリシーテーブル９３２と、ＩＤ用シリアルナンバ９３３とを有する。コンテンツ管理テーブル９３１は、コンテンツＩＤに対応付けて、コンテンツの業務ポリシーを特定するための業務ポリシーＩＤや、格納位置、格納日時、所有者名等を記憶する。なお、ここで言う「業務ポリシー」とは、コンテンツの管理条件などを示し、例えば、コンテンツを二重化して記憶装置９１０に記憶させるか否かといった情報である。業務ポリシーテーブル９３２は、業務ポリシーＩＤに対応付けて、業務ポリシーを記憶する。ＩＤ用シリアルナンバ９３３は、新たなコンテンツにコンテンツＩＤを割り振る番号を記憶する。

コンテンツ管理サービス９４０は、上位装置である業務サーバ１０内のＡＰＩ（Application Program Interface）１１から、リード要求やライト要求を受け付けた場合に、記憶装置９１０に対するアクセス制御を行う。例えば、コンテンツ管理サービス９４０は、リード要求を受け付けた場合、リード要求に含まれるコンテンツＩＤと、構成定義記憶部９３０に記憶されている各種情報を用いて、記憶装置９１０からコンテンツを取得し、取得したコンテンツを業務サーバ１０へ送信する。

このように、従来のＣＡＳは、コンテンツＩＤを用いてコンテンツを管理する。このため、ＣＡＳは、プラットフォームへの依存性を小さくしており、コンテンツを長期的に保存することに適している。

特開２００４−１９９２４７号公報 特開２００５−２２２３９２号公報

ところで、ＣＡＳは、長期的に用いられるストレージ装置であるため、運用後に、新しい規格のディスク媒体を追加するといった機能追加が行われる場合がある。このような機能追加が発生した場合、新機能に対応するためにコンテンツ管理ソフトウェアをバージョンアップすることが多い。

しかしながら、上述した従来のＣＡＳには、コンテンツ管理ソフトウェアをバージョンアップする場合に、業務サーバやＣＡＳを長時間停止させる場合があるという問題があった。かかる問題点を明確にするために、図１２に示したＣＡＳ９００を例に挙げて、コンテンツ管理ソフトウェア９２０をバージョンアップする手順について説明する。

コンテンツ管理ソフトウェア９２０をバージョンアップする場合、まず、業務サーバ１０の運用を停止する。続いて、ＣＡＳ９００のコンテンツ管理サービス９４０を停止する。続いて、現にインストールされているコンテンツ管理ソフトウェア９２０をアンインストールした後に、新バージョンのコンテンツ管理ソフトウェアをインストールする。続いて、コンテンツ管理テーブル９３１と業務ポリシーテーブル９３２とを、新バージョンのコンテンツ管理ソフトウェアに対応する形式に更新する。そして、コンテンツ管理サービスを起動した後に、業務サーバ１０の運用を再開する。これにより、ＣＡＳ９００は、業務サーバ１０に対して、新バージョンのコンテンツ管理ソフトウェアを用いたサービスを提供することが可能になる。

このように、コンテンツ管理ソフトウェアをバージョンアップする場合に、ＣＡＳ９００を用いた運用が停止してしまっていた。また、上述したバージョンアップ作業において、コンテンツ管理テーブル９３１等を更新する処理は、長時間要することが多かった。これは、近年のストレージ装置は大容量化しており多数のコンテンツを記憶するため、コンテンツ管理テーブル９３１のサイズも大きくなっているからである。このため、コンテンツ管理ソフトウェアをバージョンアップする場合、運用停止時間が長くなっていた。

開示の技術は、上述した従来技術による問題点を解消するためになされたものであり、短い運用停止時間でコンテンツ管理ソフトウェアをバージョンアップすることができるストレージ装置、ソフトウェア更新方法およびソフトウェア更新プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本願に開示するストレージ装置は、記憶装置へのアクセス制御を行うソフトウェアのバージョン毎に、前記記憶装置に記憶されているデータに関する属性情報を異なるメタ情報テーブルに保持し、前記ソフトウェアをバージョン毎に保持するソフトウェア保持部と、既にインストールされているソフトウェアである現ソフトウェアと異なるバージョンのソフトウェアである他のソフトウェアをインストールする旨の操作を受け付けた場合に、前記現ソフトウェアを残したままにして、前記他のソフトウェアをインストールするための処理を実行するソフトウェア更新手段と、前記ソフトウェア更新手段によって前記他のソフトウェアがインストールされた場合に、当該のストレージ装置の運用中に、前記現ソフトウェアのバージョンに対応するメタ情報テーブルを、前記他のソフトウェアのバージョンに対応するメタ情報テーブルの形式に更新するテーブル更新手段とを備えたことを要件とする。

なお、本願に開示するストレージ装置の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも、他の態様として有効である。

本願に開示したストレージ装置によれば、短い運用停止時間でコンテンツ管理ソフトウェアをバージョンアップすることができるという効果を奏する。

図１は、実施例に係るストレージ装置の構成を示す図である。 図２は、サービスバージョン対応テーブルの一例を示す図である。 図３は、ＩＤテーブルの一例を示す図である。 図４は、業務ポリシーテーブルの一例を示す図である。 図５−１は、コンテンツメタ情報テーブルの一例を示す図である。 図５−２は、コンテンツメタ情報テーブルの一例を示す図である。 図６は、コンテンツメタ情報テーブルの一例を示す図である。 図７は、コンテンツメタ情報テーブルの一例を示す図である。 図８は、実施例に係るストレージ装置によるコンテンツ管理ソフトウェアのメンテナンス手順を示すフローチャートである。 図９は、実施例に係るストレージ装置によるリード処理手順を示すフローチャートである。 図１０は、実施例に係るストレージ装置によるライト処理手順を示すフローチャートである。 図１１は、ＣＡＳのアクセス方式を説明するための図である。 図１２は、従来のＣＡＳの構成を示す図である。

以下に、本願に開示するストレージ装置、ソフトウェア更新方法およびソフトウェア更新プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例により本願に開示するストレージ装置、ソフトウェア更新方法およびソフトウェア更新プログラムが限定されるものではない。なお、以下の実施例では、ストレージ装置としてＣＡＳを例に挙げて説明するが、本願に開示するストレージ装置、ソフトウェア更新方法およびソフトウェア更新プログラムは、コンテンツ管理ソフトウェアを用いてコンテンツを管理する他のストレージ装置にも適用することができる。

まず、本実施例に係るストレージ装置１００について説明する。本実施例に係るストレージ装置１００は、ＣＡＳであるものとする。ストレージ装置１００は、複数のバージョンのコンテンツ管理ソフトウェアを保持することが可能である。そして、ストレージ装置１００は、複数のバージョンのコンテンツ管理ソフトウェアによって実現されるサービスを提供する。なお、ここで言う「コンテンツ管理ソフトウェアによって実現されるサービス」とは、例えば、業務サーバから受け付けたリード要求やライト要求に応答して、リード処理やライト処理を行い、処理結果を業務サーバへ送信することを示す。

すなわち、ストレージ装置１００は、例えば、バージョンＶ１１のコンテンツ管理ソフトウェアによって実現されるサービスを提供したり、バージョンＶ１２のコンテンツ管理ソフトウェアによって実現されるサービスを提供したりすることができる。以下では、「コンテンツ管理ソフトウェアによって実現されるサービス」を単に「サービス」と呼ぶことがある。また、以下では、バージョンＮのコンテンツ管理ソフトウェアによって実現されるサービスを単に「バージョンＮのサービス」と呼ぶことがある。

また、ストレージ装置１００は、コンテンツに関する各種情報を記憶する構成定義テーブルを保持する。構成定義テーブルは、コンテンツの属性や、コンテンツが管理されているコンテンツ管理ソフトウェアのバージョン等を記憶する。

そして、本実施例におけるストレージ装置１００は、構成定義テーブルを複数のテーブルに分けて保持する。具体的には、ストレージ装置１００は、構成定義テーブルを、バージョンアップによって更新を要するテーブルと、バージョンアップによって更新を要しないテーブルとに分けて保持する。このように構成定義テーブルを分けて保持する理由は、１個の構成定義テーブルのサイズを小さくすることにより、後述する構成定義テーブル更新処理を短い時間で終了させるためである。

また、ストレージ装置１００は、バージョンアップによって更新を要するテーブルを、少なくともバージョン毎に分けて保持する。このようにテーブルを分けて保持する理由は、上述した理由と同様に構成定義テーブル更新処理に係る時間を短くするためである。また、他の理由として、コンテンツ管理ソフトウェアのバージョンによって、扱う項目が異なる場合があるからである。例えば、バージョンＶ１１のコンテンツ管理ソフトウェアでは扱わなかった項目であっても、新しいバージョンＶ１２では、機能追加に伴って新しい項目を扱う場合がある。すなわち、ストレージ装置１００は、例えば、バージョンＶ１１とＶ１２のコンテンツ管理ソフトウェアを保持している場合、構成定義テーブルを、バージョンＶ１１に対応する構成定義テーブルと、バージョンＶ１２に対応する構成定義テーブルとに分けて保持する。

このような構成の下、ストレージ装置１００は、コンテンツ管理ソフトウェアをバージョンアップする旨の操作を受け付けた場合に、現にインストールされているコンテンツ管理ソフトウェアを残したままにして、新しいバージョンのコンテンツ管理ソフトウェアを所定の記憶部に記憶させる。

このとき、ストレージ装置１００は、旧バージョンのコンテンツ管理ソフトウェアに対応する構成定義テーブルを更新しない。本来、新バージョンのコンテンツ管理ソフトウェアがインストールされた場合、既存のコンテンツを最新バージョンのコンテンツ管理ソフトウェアによって管理させるために、構成定義テーブルを更新する。しかし、本実施例におけるストレージ装置１００は、コンテンツ管理ソフトウェアがインストールされたタイミングでは構成定義テーブルを更新せずに、運用中に、構成定義テーブル更新処理を行う。

具体的には、ストレージ装置１００は、運用中に、業務サーバからリード要求を受け付けた場合に、リード対象のコンテンツが管理されているコンテンツ管理ソフトウェアのバージョンを特定する。そして、ストレージ装置１００は、特定したバージョンのサービスによってコンテンツを読み出し、読み出したコンテンツを業務サーバへ送信する。

このとき、ストレージ装置１００は、読み出したコンテンツが最新バージョン以外の旧バージョンのコンテンツ管理ソフトウェアによって管理されている場合に、かかるコンテンツに関する情報を記憶する構成定義テーブルを、最新バージョンに対応する構成定義テーブルに更新する。上述したように、ストレージ装置１００は、構成定義テーブルを細分化して保持しているので、かかる構成定義テーブルの更新処理を短時間で終了させることができる。

また、ストレージ装置１００は、業務サーバからコンテンツを書き込むライト要求を受け付けた場合に、最新バージョンのサービスによってライト処理を行う。具体的には、ストレージ装置１００は、最新バージョンのコンテンツ管理ソフトウェアに対応する構成定義テーブルに、受け付けたコンテンツに関する各種情報を記憶させる。そして、ストレージ装置１００は、受け付けたコンテンツを記憶装置に記憶させる。

このように、本実施例に係るストレージ装置１００は、コンテンツ管理ソフトウェアがバージョンアップされる場合に、現にインストールされているコンテンツ管理ソフトウェアを残したままにして、複数のバージョンのコンテンツ管理ソフトウェアを保持する。また、本実施例に係るストレージ装置１００は、コンテンツ管理ソフトウェアがインストールされる場合に、構成定義テーブルを更新する処理を行わない。これにより、本実施例に係るストレージ装置１００は、コンテンツ管理ソフトウェアのバージョンアップにかかる時間を短くすることができる。

また、本実施例に係るストレージ装置１００は、旧バージョンのコンテンツ管理ソフトウェアによって管理されているコンテンツに対するリード要求を受け付けた場合に、かかるコンテンツに関する各種情報が記憶されている構成定義テーブルを、最新バージョンに対応する構成定義テーブルに更新する。これにより、ストレージ装置１００は、既存のコンテンツを、徐々に最新バージョンのコンテンツ管理ソフトウェアによって管理させることができる。

また、本実施例に係るストレージ装置１００は、構成定義テーブルを、バージョンアップによって更新を要するテーブルと、バージョンアップによって更新を要しないテーブルとに分け、さらに、各テーブルをバージョン毎に分けて保持する。これにより、ストレージ装置１００は、前述した構成定義テーブルの更新処理を短時間で終了させることができる。その結果、ストレージ装置１００は、運用中に構成定義テーブルの更新処理を行う場合であっても、かかる更新処理に用いられるＣＰＵやメモリの資源を低減することができる。

また、本実施例に係るストレージ装置１００は、ライト要求を受け付けた場合、最新バージョンのサービスによってライト処理を行う。これにより、ストレージ装置１００は、新規コンテンツを最新バージョンのコンテンツ管理ソフトウェアによって管理させることができる。

以上のように、本実施例に係るストレージ装置１００は、短い運用停止時間でコンテンツ管理ソフトウェアをバージョンアップすることができるとともに、保持するコンテンツを徐々に最新バージョンのコンテンツ管理ソフトウェアに対応させることができる。その結果、ストレージ装置１００は、コンテンツ管理ソフトウェアのバージョンアップ時における運用への影響を低減することができる。

次に、本実施例に係るストレージ装置１００の構成について説明する。図１は、本実施例に係るストレージ装置１００の構成を示す図である。図１に示すように、ストレージ装置１００は、記憶装置９１０と、コンテンツ管理ソフトウェア１２０とを有する。記憶装置９１０は、図１２に示した記憶装置９１０と同様である。

コンテンツ管理ソフトウェア１２０は、記憶装置９１０へのアクセスに関するサービスを提供する。具体的には、コンテンツ管理ソフトウェア１２０は、バージョンの異なるサービスを提供することができ、プロキシサービス１２１と、構成定義記憶部１３０と、コンテンツ管理サービス１４０とを有する。

プロキシサービス１２１は、上位装置である業務サーバ１０内のＡＰＩ１１から、データのリード要求やライト要求を受け付けた場合に、かかる要求を所定のバッファに格納して、バッファに格納した要求をコンテンツ管理サービス１４０へ送信する。

具体的には、プロキシサービス１２１は、コンテンツ管理サービス１４０が起動中である場合、バッファに格納した要求をコンテンツ管理サービス１４０へ送信する。一方、プロキシサービス１２１は、コンテンツ管理サービス１４０が停止中である場合、バッファに格納した要求をコンテンツ管理サービス１４０へ送信しない。そして、プロキシサービス１２１は、コンテンツ管理サービス１４０が起動した後に、バッファから要求をキューイングしてコンテンツ管理サービス１４０へ送信する。

構成定義記憶部１３０は、コンテンツの構成に関する各種情報を記憶する記憶デバイスである。構成定義記憶部１３０が有する各テーブルは、サービスバージョン対応テーブル１３０ａと、コアテーブル群１３１と、コンテンツメタ情報テーブル群１３２とに分けられる。

サービスバージョン対応テーブル１３０ａは、ストレージ装置１００が提供可能なサービスと、かかるサービスのバージョンとを対応付けて記憶する。サービスバージョン対応テーブル１３０ａの一例を図２に示す。図２に示すように、サービスバージョン対応テーブル１３０ａは、サービスＩＤ、バージョンといった項目を有する。「サービスＩＤ」は、サービスを識別するための識別情報を示す。「バージョン」は、対応するサービスＩＤによって示されるサービスのバージョンを示す。

すなわち、図２に示したサービスバージョン対応テーブル１３０ａの１行目は、サービスＩＤ「００１」によって示されるサービスのバージョンが「３．００」であることを示している。また、図２に示したサービスバージョン対応テーブル１３０ａの２行目は、サービスＩＤ「００２」によって示されるサービスのバージョンが「２．２０」であることを示している。なお、図２では、上の行に示したサービスほど、新しいバージョンであることを示している。すなわち、図２の例では、ストレージ装置１００が提供可能なサービスのうち、最新バージョンのサービスが「３．００」であることを示している。

なお、以下の説明において、最新のバージョンは「３．００」であり、最新のバージョンより１世代前のバージョンは「２．２０」であり、最新のバージョンより２世代前のバージョンは「２．１０」であるものとする。

コアテーブル群１３１は、コンテンツ管理ソフトウェアがバージョンアップされる場合に更新を要しないテーブル群である。図１に示した例では、コアテーブル群１３１は、ＩＤテーブル１３１ａと、業務ポリシーテーブル１３１ｂとを含む。

ＩＤテーブル１３１ａは、コンテンツをコンテンツＩＤによって管理するための情報を記憶する。ＩＤテーブル１３１ａの一例を図３に示す。図３に示すように、ＩＤテーブル１３１ａは、コンテンツＩＤ、業務ポリシーＩＤ、格納位置といった項目を有する。

「コンテンツＩＤ」は、コンテンツを識別するための識別情報を示す。「業務ポリシーＩＤ」は、対応するコンテンツＩＤによって示されるコンテンツの業務ポリシーを識別するための識別情報を示す。「格納位置」は、対応するコンテンツＩＤによって示されるコンテンツが格納されている位置（デバイス名やパス名等）を示す。

すなわち、図３に示したＩＤテーブル１３１ａの１行目は、コンテンツＩＤ「Ａ２００８１２０１１１１１１１Ｇ０１」によって示されるコンテンツの業務ポリシーＩＤが「Ｇ０１」であり、かかるコンテンツが「／ＡＡＡ／ａａａ」に格納されていることを示している。また、図３に示したＩＤテーブル１３１ａの４行目は、コンテンツＩＤ「Ｂ２００８１２０４４４４４４４Ｇ０３」によって示されるコンテンツの業務ポリシーＩＤが「Ｇ０３」であり、かかるコンテンツが「／ＢＢＢ／ｂｂｂ」に格納されていることを示している。

なお、コンテンツＩＤは、少なくとも「業務サーバ識別子」と、「コンテンツ格納日付」と、「業務ポリシーＩＤ」とに関する情報を含むように命名されることが好ましい。業務サーバ識別子とは、コンテンツを格納するように要求した業務サーバを識別するための識別情報である。また、コンテンツ格納日付とは、コンテンツが記憶装置９１０に格納された日時（年月日時分秒）である。例えば、図３の１行目に示したコンテンツＩＤ「Ａ２００８１２０１１１１１１１Ｇ０１」は、業務サーバ識別子「Ａ」と、コンテンツ格納日「２００８１２０１１１１１１１」と、業務ポリシーＩＤ「Ｇ０１」との組合せによって命名されている。コンテンツＩＤがこのように命名される理由については、後に説明する。

業務ポリシーテーブル１３１ｂは、業務ポリシーＩＤ毎に、コンテンツの業務ポリシー（管理条件）に関する各種情報を記憶する。業務ポリシーテーブル１３１ｂの一例を図４に示す。図４に示すように、業務ポリシーテーブル１３１ｂは、業務ポリシーＩＤ、削除不可期間、コピーフラグ、コピータイミング、管理者アドレス、通知イベントといった項目を有する。

「業務ポリシーＩＤ」は、図３に示した業務ポリシーＩＤに対応し、業務ポリシーを識別するための識別情報を示す。「削除不可期間」は、コンテンツを記憶装置９１０に保持する期間を示す。なお、図４に示した例では、削除不可期間の単位は日数であるものとする。「コピーフラグ」は、コンテンツを二重化して格納するか否かを示す。なお、図４において、コピーフラグが「０」である場合、コンテンツを二重化して格納しないことを示し、コピーフラグが「１」である場合、コンテンツを二重化して格納することを示すものとする。

「コピータイミング」は、コンテンツを格納するタイミングと同期して二重化するか否かを示す。なお、図４において、コピータイミングが「０」である場合、コンテンツを格納するタイミングと非同期に二重化することを示し、コピータイミングが「１」である場合、コンテンツを格納するタイミングと同期して二重化することを示すものとする。

「管理者アドレス」は、コンテンツの管理者への連絡先を示し、例えば、メールアドレスである。なお、ここで言う「コンテンツの管理者」とは、例えば、コンテンツを格納することを要求した業務サーバの管理者である。「通知イベント」は、ストレージ装置１００において各種イベント（コンテンツの格納エラーや、システム停止予告など）が発生した場合に、コンテンツの管理者に対してイベント内容を通知するか否かを示す。なお、図４において、通知イベントが「０」である場合、管理者に対してイベント内容を通知しないことを示し、通知イベントが「１」である場合、管理者に対してイベント内容を通知することを示すものとする。

すなわち、図４に示した業務ポリシーテーブル１３１ｂの１行目は、業務ポリシーＩＤ「Ｇ０１」によって示される業務ポリシーでは、コンテンツを保持する期間が「４０００日」であることを示している。さらに、図４に示した業務ポリシーテーブル１３１ｂの１行目は、コンテンツを格納するタイミングと同期して二重化処理を行い、ストレージ装置１００において各種イベントが発生した場合には、管理者に対してイベント内容を通知することを示している。

コンテンツメタ情報テーブル群１３２は、コンテンツ管理ソフトウェアがバージョンアップされる場合に更新を要するテーブル群である。図１に示した例では、コンテンツメタ情報テーブル群１３２は、コンテンツメタ情報テーブル１３２−０、１３２−１、・・・、１３２−ｎを含む。

コンテンツメタ情報テーブル１３２−０、１３２−１、・・・、１３２−ｎは、少なくともバージョン毎に異なるテーブルに分別され、コンテンツに関するメタ情報（ユーザ情報などの属性）を記憶する。図１に示した例では、コンテンツメタ情報テーブル１３２−０は、ストレージ装置１００にインストールされているコンテンツ管理ソフトウェアの最新バージョン（本実施例では、バージョン「３．００」）に対応するテーブルであるものとする。また、コンテンツメタ情報テーブル１３２−１は、ストレージ装置１００にインストールされているコンテンツ管理ソフトウェアのうち、最新バージョンより１世代前のバージョン（本実施例では、バージョン「２．２０」）に対応するテーブルであるものとする。また、コンテンツメタ情報テーブル１３２−ｎは、ストレージ装置１００にインストールされているコンテンツ管理ソフトウェアのうち、最新バージョンよりｎ世代前のバージョンに対応するテーブルであるものとする。

また、それぞれのコンテンツメタ情報テーブル１３２−０、１３２−１、・・・、１３２−ｎは、所定の単位にさらに分別される。例えば、コンテンツメタ情報テーブル１３２−０、１３２−１、・・・、１３２−ｎは、コンテンツを格納した年月毎に分別されたり、コンテンツを格納した業務サーバ毎に分別されたり、コンテンツの業務ポリシー毎に分別されたりする。また、例えば、コンテンツメタ情報テーブル１３２−０、１３２−１、・・・、１３２−ｎは、前述したコンテンツ格納年月と、業務サーバと、業務ポリシーとの組合せ毎に分別されたりする。なお、以下の説明では、ストレージ装置１００は、コンテンツメタ情報テーブル１３２−０等を、コンテンツを格納した年月毎に分別して保持するものとする。

図５−１、図５−２、図６および図７を用いて、コンテンツメタ情報テーブル１３２−０、１３２−１、・・・、１３２−ｎについて具体的に説明する。図５−１および図５−２は、コンテンツメタ情報テーブル１３２−０の一例を示す図である。すなわち、図５−１および図５−２は、ストレージ装置１００にインストールされているコンテンツ管理ソフトウェアの最新バージョン（本実施例では、バージョン「３．００」）に対応するコンテンツメタ情報テーブルである。図５−１と図５−２との違いは、コンテンツ格納日である。具体的には、図５−１に示したコンテンツメタ情報テーブル１３２−０は、２００８年１２月に格納されたコンテンツに関するメタ情報を記憶し、図５−２に示したコンテンツメタ情報テーブル１３２−０は、２００８年１１月に格納されたコンテンツに関するメタ情報を記憶する。

図５−１および図５−２に示すように、コンテンツメタ情報テーブル１３２−０は、コンテンツＩＤ、バージョン、格納日時、業務サーバ名、所有者名、分類、ハッシュ値といった項目を有する。「コンテンツＩＤ」は、図３に示したコンテンツＩＤに対応する。「バージョン」は、図２に示したバージョンに対応する。「格納日時」は、対応するコンテンツＩＤによって示されるコンテンツが記憶装置９１０に格納された日時（年月日時分秒）を示す。

「業務サーバ名」は、コンテンツを格納するように要求した業務サーバの名称を示す。「所有者名」は、コンテンツの所有者の名称を示す。「分類」は、コンテンツの種類を示し、例えば、音声ファイルを示す「ｍｐ３」や、動画ファイルを示す「ｍｐｅｇ」といった情報に該当する。「ハッシュ値」は、コンテンツのハッシュ値を示す。なお、かかるハッシュ値は、例えば、ストレージ装置１００によって同一のコンテンツを記憶装置９１０に記憶させない制御が行われる場合などに用いられる。

図５−１および図５−２に示したように、ストレージ装置１００は、同一のバージョンに対応するコンテンツメタ情報テーブルであっても、コンテンツが格納された年月などによって別のテーブルに分けて管理する。

図６は、コンテンツメタ情報テーブル１３２−１の一例を示す図である。すなわち、図６は、１世代前のバージョン（本実施例では、バージョン「２．２０」）に対応するコンテンツメタ情報テーブルである。図６に例示したコンテンツメタ情報テーブル１３２−１は、図５−１および図５−２に示したコンテンツメタ情報テーブル１３２−０と比較して、項目「ハッシュ値」を有しない。

これは、バージョン「２．２０」までのサービスでは、コンテンツのハッシュ値を管理しないが、バージョン「３．００」のサービスでは、コンテンツのハッシュ値を管理することを意味している。すなわち、バージョン「３．００」のサービスに、上述したような同一のコンテンツを格納させないための制御を行う機能が追加されたことを意味している。このように、バージョンアップされることによりサービスに機能追加がなされると、管理情報も変わる可能性がある。

図７は、コンテンツメタ情報テーブル１３２−ｎの一例を示す図である。すなわち、図７は、ｎ世代前のバージョン（本実施例では、バージョン「１．００」）に対応するコンテンツメタ情報テーブルである。図７に例示したコンテンツメタ情報テーブル１３２−ｎは、図６に示したコンテンツメタ情報テーブル１３２−１と比較して、項目「分類」を有しない。

なお、図示することを省略したが、本実施例におけるストレージ装置１００は、コンテンツメタ情報テーブル１３２−１および１３２−ｎについても、コンテンツメタ情報テーブル１３２−０と同様に、コンテンツが格納された年月毎に異なるテーブルに分けて保持する。

図１の説明に戻って、コンテンツ管理サービス１４０は、プロキシサービス１２１からリード要求やライト要求を受け付けた場合に、記憶装置９１０に対するアクセス制御を行う。具体的には、コンテンツ管理サービス１４０は、統合用サービス１４１と、バージョンサービス１４２−０、１４２−１、・・・、１４２−ｎといったサービスによってアクセス制御を行う。

統合用サービス１４１は、プロキシサービス１２１からリード要求やライト要求を受け付けて、バージョンサービス１４２−０、１４２−１、・・・、１４２−ｎに対して、アクセス制御を行わせる。ここで、リード要求を受け付けた場合と、ライト要求を受け付けた場合とに分けて、統合用サービス１４１による処理について説明する。

まず、リード要求を受け付けた場合における統合用サービス１４１による処理について説明する。統合用サービス１４１は、プロキシサービス１２１からリード要求を受け付けた場合、コンテンツＩＤに含まれる「コンテンツ格納年月日」などの情報に基づいて、リード対象のコンテンツに関する情報が記憶されているコンテンツメタ情報テーブルを絞り込む。

続いて、統合用サービス１４１は、絞り込んだコンテンツメタ情報テーブルから、リード対象のコンテンツに対応するバージョンを取得する。続いて、統合用サービス１４１は、取得したバージョンに対応するサービスＩＤをサービスバージョン対応テーブル１３０ａから取得する。そして、統合用サービス１４１は、取得したサービスＩＤによって示されるバージョンサービス１４２−０、１４２−１、・・・、１４２−ｎのいずれかのサービスに対して、リード処理を行うように指示する。

続いて、統合用サービス１４１は、サービスバージョン対応テーブル１３０ａから取得したバージョンが最新バージョンであるか否かを判定する。バージョンが最新でない場合、統合用サービス１４１は、コンテンツメタ情報テーブル更新処理を行う。具体的には、統合用サービス１４１は、リード対象のコンテンツに関する情報を記憶するコンテンツメタ情報テーブル１３２−１、・・・、１３２−ｎのいずれかを、最新バージョンに対応するコンテンツメタ情報テーブル１３２−０に更新する。

このとき、統合用サービス１４１は、移行先のコンテンツメタ情報テーブル１３２−０が存在しない場合、コンテンツメタ情報テーブル１３２−０を新たに生成する。このようなケースが発生する例としては、移行元のコンテンツの格納年月に対応するコンテンツメタ情報テーブル１３２−０が存在しない場合などである。一方、統合用サービス１４１は、移行先のコンテンツメタ情報テーブル１３２−０が存在する場合、かかるコンテンツメタ情報テーブル１３２−０に、移行元のコンテンツメタ情報テーブル（１３２−１など）に記憶されている各種情報を移行する。

また、統合用サービス１４１は、移行先のコンテンツメタ情報テーブル１３２−０が、移行元のコンテンツメタ情報テーブル（１３２−１等）と異なる項目を有する場合、かかる項目に記憶させる情報を生成する。例えば、コンテンツメタ情報テーブル１３２−１に記憶されている情報を、コンテンツメタ情報テーブル１３２−０に移行する場合、統合用サービス１４１は、各コンテンツのハッシュ値を算出した上で、移行処理を行う。

なお、ストレージ装置１００は、バージョン間で異なる項目を所定の記憶部に保持しておいてもよい。例えば、ストレージ装置１００は、バージョン「２．２０」と「３．００」との項目差が「ハッシュ値」であり、バージョン「１．００」と「３．００」との項目差が「ハッシュ値」および「分類」であるといった情報を保持してもよい。これにより、統合用サービス１４１は、コンテンツメタ情報テーブル更新処理を行う場合に、生成すべき項目を認識することができる。

そして、統合用サービス１４１は、コンテンツメタ情報テーブル更新処理によって、旧バージョンに対応するコンテンツメタ情報テーブルに記憶される情報が存在しなくなった場合、かかる旧バージョンのコンテンツ管理ソフトウェアをアンインストール（削除）する。

上述した統合用サービス１４１による処理について、２個の例を挙げて説明する。以下に示す例において、サービスバージョン対応テーブル１３０ａは、図２に示した状態であるものとする。また、コンテンツメタ情報テーブル１３２−０、１３２−１および１３２−ｎは、それぞれ図５−１、図５−２、図６および図７に示した状態であるものとする。

まず、１個目の例として、統合用サービス１４１が、コンテンツＩＤ「Ａ２００８１２０１１１１１１１Ｇ０１」を含むリード要求を受け付けた場合について説明する。かかる場合、統合用サービス１４１は、コンテンツＩＤからコンテンツ格納年月「２００８１２」を抽出する。続いて、統合用サービス１４１は、検索対象のテーブルを、２００８年１２月に格納されたコンテンツを管理するコンテンツメタ情報テーブル１３２−０（図５−１）に絞り込む。そして、統合用サービス１４１は、コンテンツメタ情報テーブル１３２−０から、コンテンツＩＤ「Ａ２００８１２０１１１１１１１Ｇ０１」に対応するバージョン「３．００」を取得する。

このように、コンテンツＩＤが、「業務サーバ識別子」や「コンテンツ格納日付」等の情報を含むように命名されることにより、統合用サービス１４１は、コンテンツＩＤに含まれる情報に基づいて、検索対象のコンテンツメタ情報テーブルを絞り込むことができる。その結果、統合用サービス１４１は、検索対象のコンテンツメタ情報テーブルを絞り込む処理を高速に行うことができる。

なお、コンテンツメタ情報テーブル１３２−０等が、業務サーバや、業務ポリシー毎に分けられている場合、統合用サービス１４１は、コンテンツＩＤに含まれる「業務サーバ識別子」や「業務ポリシーＩＤ」に基づいて、検索対象のコンテンツメタ情報テーブルを絞り込む。

続いて、統合用サービス１４１は、サービスバージョン対応テーブル１３０ａから、バージョン「３．００」に対応するサービスＩＤ「００１」を取得する。続いて、統合用サービス１４１は、取得したサービスＩＤ「００１」によって示されるバージョンサービス１４２−０に対して、リード処理を行うように指示する。そして、統合用サービス１４１は、サービスバージョン対応テーブル１３０ａから取得したバージョン「３．００」が最新バージョンであるので処理を終了する。

次に、２個目の例として、統合用サービス１４１が、コンテンツＩＤ「Ａ２００８１００１１１１１１１Ｇ０１」を含むリード要求を受け付けた場合について説明する。かかる場合、統合用サービス１４１は、コンテンツＩＤからコンテンツ格納年月「２００８１０」を抽出し、検索対象のテーブルを、図６に示したコンテンツメタ情報テーブル１３２−１に絞り込む。そして、統合用サービス１４１は、コンテンツメタ情報テーブル１３２−１から、コンテンツＩＤ「Ａ２００８１００１１１１１１１Ｇ０１」に対応するバージョン「２．２０」を取得する。

続いて、統合用サービス１４１は、サービスバージョン対応テーブル１３０ａから、バージョン「２．２０」に対応するサービスＩＤ「００２」を取得する。続いて、統合用サービス１４１は、取得したサービスＩＤ「００２」によって示されるバージョンサービス１４２−１に対して、リード処理を行うように指示する。

続いて、統合用サービス１４１は、サービスバージョン対応テーブル１３０ａから取得したバージョン「２．２０」が最新バージョンではないので、コンテンツメタ情報テーブル１３２−１を、最新バージョンに対応するコンテンツメタ情報テーブルに更新する。ここで、本実施例では、コンテンツメタ情報テーブルは、格納年月毎に分別される。また、図５−１、図５−２および図６に示すように、コンテンツメタ情報テーブル１３２−０の格納年月と、コンテンツメタ情報テーブル１３２−１の格納年月とは異なる。したがって、統合用サービス１４１は、コンテンツメタ情報テーブル１３２−１に記憶されている情報を、既存のコンテンツメタ情報テーブル１３２−０に移行することはできない。

そこで、統合用サービス１４１は、コンテンツメタ情報テーブル１３２−０を新たに生成する。続いて、統合用サービス１４１は、コンテンツメタ情報テーブル１３２−１に記憶されているコンテンツのハッシュ値を算出する。そして、統合用サービス１４１は、算出したハッシュ値とともに、コンテンツメタ情報テーブル１３２−１に記憶されている各種情報を、新たに生成したコンテンツメタ情報テーブル１３２−０へ移行する。

続いて、統合用サービス１４１は、バージョン「２．２０」に対応するコンテンツメタ情報テーブル１３２−１に記憶されている情報が存在するか否かを判定する。コンテンツメタ情報テーブル１３２−１に記憶されている情報が存在しない場合、バージョン「２．２０」のサービスが用いられることはなくなるので、統合用サービス１４１は、バージョン「２．２０」のコンテンツ管理ソフトウェアをアンインストール（削除）する。

次に、ライト要求を受け付けた場合における統合用サービス１４１による処理について説明する。統合用サービス１４１は、プロキシサービス１２１からライト要求を受け付けた場合、バージョンが最新であるバージョンサービス１４２−０に対して、ライト処理を行うように指示する。

バージョンサービス１４２−０、１４２−１、・・・、１４２−ｎは、統合用サービス１４１からの指示に従って、リード処理やライト処理を実行するサービスを提供する。なお、図１に示した例では、バージョンサービス１４２−０は、最新バージョンのサービスであり、バージョンサービス１４２−１は、最新バージョンより１世代前のバージョンのサービスであり、バージョンサービス１４２−ｎは、最新バージョンよりｎ世代前のバージョンのサービスであるものとする。

ここで、バージョンサービス１４２−０、１４２−１、・・・、１４２−ｎ（以下、「バージョンサービス１４２−０等」と呼ぶ）による処理について、リード処理と、ライト処理とに分けて具体的に説明する。

まず、バージョンサービス１４２−０等によるリード処理について説明する。バージョンサービス１４２−０等は、統合用サービス１４１からリード処理を実行する旨の指示を受け付けた場合に、ＩＤテーブル１３１ａから、リード要求に含まれるコンテンツＩＤに対応付けて記憶されている業務ポリシーＩＤと格納位置とを取得する。

続いて、バージョンサービス１４２−０等は、取得した業務ポリシーＩＤをキーにして、業務ポリシーテーブル１３１ｂから削除不可期間等の各種情報を取得する。バージョンサービス１４２−０等は、取得した情報に基づいて、例えば、イベントが発生した場合に管理者へ通知する処理を行うか否かを判断したりする。

続いて、バージョンサービス１４２−０等は、リード要求に含まれるコンテンツＩＤをキーにして、コンテンツメタ情報テーブル１３２−０、１３２−１、・・・、１３２−ｎから業務サーバ名等のメタ情報を取得する。このとき、バージョンサービス１４２−０等は、それぞれ対応するコンテンツメタ情報テーブル１３２−０、１３２−１、・・・、１３２−ｎから各種情報を取得する。例えば、最新バージョンのバージョンサービス１４２−０は、最新バージョンに対応するコンテンツメタ情報テーブル１３２−０からメタ情報を取得する。また、例えば、１世代前のバージョンサービス１４２−１は、１世代前のバージョンに対応するコンテンツメタ情報テーブル１３２−１からメタ情報を取得する。

バージョンサービス１４２−０等は、コンテンツメタ情報テーブル１３２−０等から取得したメタ情報に基づいて、所定の処理を行う。ここで言う「所定の処理」とは、例えば、所有者名を用いてアクセス権限があるか否かを確認する処理などである。なお、このような処理は、バージョンサービス１４２−０等のバージョンによって異なる可能性がある。例えば、バージョンサービス１４２−０は、ハッシュ値を用いた各種制御を行う場合があるが、バージョンサービス１４２−１は、ハッシュ値を用いた制御を行わない場合がある。

そして、バージョンサービス１４２−０等は、ＩＤテーブル１３１ａから取得した格納位置に基づいて、記憶装置９１０からコンテンツを取得し、取得したコンテンツを業務サーバ１０へ送信する。

次に、バージョンサービス１４２−０等によるライト処理について説明する。バージョンサービス１４２−０、１４２−１、・・・、１４２−ｎのうち、ライト処理を行うのは、バージョンサービス１４２−０である。これは、統合用サービス１４１が、最新バージョンのバージョンサービス１４２−０に対して、ライト処理を実行するように指示するからである。

バージョンサービス１４２−０は、ライト処理を実行する旨の指示を受け付けた場合に、ライト要求に含まれるコンテンツを記憶装置９１０に記憶させる。続いて、バージョンサービス１４２−０は、格納したコンテンツにコンテンツＩＤを払い出す。具体的には、バージョンサービス１４２−０は、上述したように、少なくとも「業務サーバ識別子」「コンテンツ格納日付」「業務ポリシーＩＤ」を含むコンテンツＩＤを払い出す。

続いて、バージョンサービス１４２−０は、ライト要求に含まれるコンテンツに関するメタ情報をコンテンツメタ情報テーブル１３２−０に記憶させる。なお、本実施例のようにコンテンツメタ情報テーブル１３２−０が格納月別に分けられている場合、バージョンサービス１４２−０は、コンテンツを格納する年月に対応するコンテンツメタ情報テーブル１３２−０にメタ情報を記憶させる。

そして、バージョンサービス１４２−０は、払い出したコンテンツＩＤと、格納したコンテンツの業務ポリシーＩＤと、コンテンツを格納した位置とをＩＤテーブル１３１ａに記憶させるとともに、コンテンツＩＤを業務サーバ１０へ送信する。

次に、図８を用いて、上述してきたストレージ装置１００に対してコンテンツ管理ソフトウェアをインストールする手順について説明する。図８は、本実施例に係るストレージ装置１００によるコンテンツ管理ソフトウェアのメンテナンス手順を示すフローチャートである。

図８に示すように、ストレージ装置１００は、コンテンツ管理ソフトウェアをインストールする旨の操作を受け付けた場合（ステップＳ１０１肯定）、コンテンツ管理サービス１４０を停止させる（ステップＳ１０２）。

続いて、ストレージ装置１００は、旧バージョンのコンテンツ管理ソフトウェアを残したままにして、新バージョンのコンテンツ管理ソフトウェアをインストールする（ステップＳ１０３）。続いて、ストレージ装置１００は、サービスバージョン対応テーブル１３０ａを更新する（ステップＳ１０４）。例えば、バージョン「４．００」のコンテンツ管理ソフトウェアがインストールされる場合、ストレージ装置１００は、サービスバージョン対応テーブル１３０ａに、所定のサービスＩＤとバージョン「４．００」との組合せのレコードを追加する。

続いて、ストレージ装置１００は、インストールしたコンテンツ管理ソフトウェアに対応するコンテンツメタ情報テーブルを生成する（ステップＳ１０５）。ここで生成されるコンテンツメタ情報テーブルには、レコードが存在しない。これは、本実施例に係るストレージ装置１００は、コンテンツ管理ソフトウェアのインストール時に、コンテンツメタ情報テーブルを更新する処理を行わないからである。

そして、ストレージ装置１００は、コンテンツ管理サービス１４０を起動させる（ステップＳ１０６）。このように、本実施例に係るストレージ装置１００は、コンテンツメタ情報テーブルを更新することなく、新バージョンのコンテンツ管理ソフトウェアをインストールするので、インストール処理にかかる時間を短くすることができる。さらに、本実施例に係るストレージ装置１００は、コンテンツ管理ソフトウェアのインストール中であっても、プロキシサービス１２１によって、業務サーバ１０からのリード要求やライト要求を受け付けるので、ストレージ装置１００を用いた運用を停止させないことができる。

次に、本実施例に係るストレージ装置１００によるリード処理手順について説明する。図９は、本実施例に係るストレージ装置１００によるリード処理手順を示すフローチャートである。

図９に示すように、プロキシサービス１２１によってリード要求が受け付けられた場合（ステップＳ２０１肯定）、統合用サービス１４１は、リード要求に含まれるコンテンツＩＤによって示されるコンテンツを管理しているサービスのバージョンを特定する（ステップＳ２０２）。具体的には、統合用サービス１４１は、コンテンツＩＤを用いて、コンテンツメタ情報テーブル１３２−０、１３２−１、・・・、１３２−ｎから、バージョンを取得する。

続いて、統合用サービス１４１は、サービスバージョン対応テーブル１３０ａから、ステップＳ２０２において特定したバージョンに対応付けて記憶されているサービスＩＤを取得する。そして、統合用サービス１４１は、取得したサービスＩＤによって示されるバージョンサービス１４２−０、１４２−１、・・・、１４２−ｎのいずれかのサービスに対して、リード処理を実行するように指示する。

統合用サービス１４１から指示を受け付けたバージョンサービス１４２−０等は、ＩＤテーブル１３１ａから、コンテンツＩＤに対応付けて記憶されている業務ポリシーＩＤと格納位置とを取得する。続いて、バージョンサービス１４２−０等は、業務ポリシーテーブル１３１ｂから、取得した業務ポリシーＩＤに対応付けて記憶されている各種情報を取得する（ステップＳ２０３）。

続いて、バージョンサービス１４２−０等は、コンテンツメタ情報テーブル１３２−０、１３２−１、・・・、１３２−ｎから、コンテンツＩＤに対応付けて記憶されているメタ情報を取得する（ステップＳ２０４）。バージョンサービス１４２−０等は、取得したメタ情報に基づいて、アクセス権限チェック等の処理を行う。

続いて、バージョンサービス１４２−０等は、コンテンツＩＤに対応付けてＩＤテーブル１３１ａに記憶されている格納位置に基づいて、記憶装置９１０からコンテンツを取得し、取得したコンテンツを業務サーバ１０へ送信する（ステップＳ２０５）。

続いて、統合用サービス１４１は、ステップＳ２０２において特定したバージョンが最新バージョンでない場合（ステップＳ２０６肯定）、コンテンツメタ情報テーブル更新処理を行う（ステップＳ２０７）。例えば、リード要求に含まれるコンテンツＩＤが「Ａ２００８１００１１１１１１１Ｇ０１」である場合、バージョンサービス１４２−０等は、図６に例示したコンテンツメタ情報テーブル１３２−１から各種情報を取得する。かかる場合、統合用サービス１４１は、コンテンツメタ情報テーブル１３２−１を、図５−１または図５−２に示したような最新バージョンに対応するコンテンツメタ情報テーブルの形式に更新する。このとき、統合用サービス１４１は、更新後のコンテンツメタ情報テーブルのバージョンを、最新バージョン（本実施例では「３．００」）の情報に更新する。

そして、統合用サービス１４１は、コンテンツメタ情報テーブル更新処理によって、所定の旧バージョンに対応するコンテンツメタ情報テーブルが存在しなくなった場合、かかる所定の旧バージョンのコンテンツ管理ソフトウェアをアンインストールする。

次に、本実施例に係るストレージ装置１００によるライト処理手順について説明する。図１０は、本実施例に係るストレージ装置１００によるライト処理手順を示すフローチャートである。

図１０に示すように、プロキシサービス１２１によってライト要求が受け付けられた場合（ステップＳ３０１肯定）、統合用サービス１４１は、バージョンが最新であるバージョンサービス１４２−０に対して、ライト処理を実行するように指示する。

統合用サービス１４１から指示を受け付けたバージョンサービス１４２−０は、ライト要求に含まれるコンテンツを記憶装置９１０に記憶させる（ステップＳ３０２）。続いて、バージョンサービス１４２−０は、格納したコンテンツにコンテンツＩＤを払い出す（ステップＳ３０３）。続いて、バージョンサービス１４２−０は、コンテンツに関するメタ情報をコンテンツメタ情報テーブル１３２−０に記憶させる（ステップＳ３０４）。

そして、バージョンサービス１４２−０は、払い出したコンテンツＩＤを用いてＩＤテーブル１３１ａにレコードを追加するとともに、コンテンツＩＤを業務サーバ１０へ送信する（ステップＳ３０５）。

上述してきたように、本実施例に係るストレージ装置１００は、コンテンツ管理ソフトウェアがバージョンアップされる場合に、現にインストールされているコンテンツ管理ソフトウェアを残したままにして、複数のバージョンのコンテンツ管理ソフトウェアを保持する。また、本実施例に係るストレージ装置１００は、コンテンツ管理ソフトウェアがインストールされる場合に、構成定義テーブルを更新する処理を行わない。また、本実施例に係るストレージ装置１００は、旧バージョンのコンテンツ管理ソフトウェアによって管理されているコンテンツに対するリード要求を受け付けた場合に、かかるコンテンツに関するメタ情報が記憶されているコンテンツメタ情報テーブルを、最新バージョンに対応するコンテンツメタ情報テーブルに更新する。

このようなことから、本実施例に係るストレージ装置１００は、短い運用停止時間でコンテンツ管理ソフトウェアをバージョンアップすることができるとともに、保持するコンテンツを徐々に最新バージョンのコンテンツ管理ソフトウェアに対応させることができる。

なお、上記実施例では、コンテンツ管理ソフトウェアがインストールされたタイミングではコンテンツメタ情報テーブルを更新せず、リード要求を受け付けた場合に更新処理を行う例を示した。しかし、ストレージ装置１００は、コンテンツ管理ソフトウェアがインストールされたタイミングで、特定のコンテンツメタ情報テーブルについては更新してもよい。

例えば、ストレージ装置１００は、コンテンツ管理ソフトウェアのインストール時に、直近にアクセスされたコンテンツメタ情報テーブルを、最新バージョンに対応するコンテンツメタ情報テーブルに更新してもよい。これは、直近にアクセスされたコンテンツは、再度アクセスされる可能性が高いからである。これにより、直近にアクセスされたコンテンツメタ情報テーブルについては、運用中に更新処理を行わないようにすることができるとともに、コンテンツメタ情報テーブルの更新処理を、コンテンツ管理ソフトウェアのインストール時と、運用時とに分散させることができる。

また、上記実施例では、リード要求に含まれるコンテンツＩＤが記憶されているコンテンツメタ情報テーブルを、最新バージョンに対応するコンテンツメタ情報テーブルに更新する例を示した。しかし、ストレージ装置１００は、他のコンテンツメタ情報テーブルも同時に更新してもよい。

例えば、コンテンツＣ１１のメタ情報がコンテンツメタ情報テーブルＭ１１に記憶されており、コンテンツＣ１２のメタ情報がコンテンツメタ情報テーブルＭ１２に記憶されているものとする。そして、コンテンツＣ１１とコンテンツＣ１２との間には密接な関係があるものとする。ここで言う「密接な関係」とは、例えば、コンテンツＣ１１とコンテンツＣ１２と相互に関連するコンテンツであり、コンテンツＣ１１に対するリード要求を受け付けた場合には、コンテンツＣ１２に対するリード要求も受け付ける可能性が高い場合などを示す。このような場合、ストレージ装置１００は、コンテンツＣ１１に対するリード要求を受け付けた場合に、コンテンツメタ情報テーブルＭ１１だけでなく、コンテンツメタ情報テーブルＭ１２についても、最新バージョンに対応するコンテンツメタ情報テーブルに更新してもよい。

また、上記実施例では、コンテンツメタ情報テーブルから情報を検索する処理効率を向上させるために、コンテンツＩＤに、少なくとも「業務サーバ識別子」と、「コンテンツ格納日付」と、「業務ポリシーＩＤ」とに関する情報を含む例を示した。しかし、コンテンツＩＤは、コンテンツを一意に識別できる情報であればよく、上記「業務サーバ識別子」等の情報を含まなくてもよい。コンテンツＩＤに「業務サーバ識別子」等の情報を含めない場合、統合用サービス１４１は、検索対象のコンテンツメタ情報テーブルを絞り込むことなく、バージョンを取得する。また、かかる場合、ストレージ装置１００は、一意に識別できるコンテンツＩＤを払い出すために、図１２に示したようなＩＤ用シリアルナンバ９３３を保持する。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

また、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

１０ 業務サーバ
１１ ＡＰＩ
１００ ストレージ装置
１２０ コンテンツ管理ソフトウェア
１２１ プロキシサービス
１３０ 構成定義記憶部
１３０ａ サービスバージョン対応テーブル
１３１ コアテーブル群
１３１ａ ＩＤテーブル
１３１ｂ 業務ポリシーテーブル
１３２ コンテンツメタ情報テーブル群
１３２−０〜１３２−ｎ コンテンツメタ情報テーブル
１４０ コンテンツ管理サービス
１４１ 統合用サービス
１４２−０〜１４２−ｎ バージョンサービス
９１０ 記憶装置
９１１ 磁気ディスク
９１２ａ、９１２ｂ 磁気テープ
９３１ コンテンツ管理テーブル
９３２ 業務ポリシーテーブル
９３３ ＩＤ用シリアルナンバ
９４０ コンテンツ管理サービス

Claims (6)

1. 記憶装置へのアクセス制御を行うソフトウェアのバージョン毎に、前記記憶装置に記憶されているデータに関する属性情報を異なるメタ情報テーブルに保持し、
   前記ソフトウェアをバージョン毎に保持するソフトウェア保持部と、
   既にインストールされているソフトウェアである現ソフトウェアと異なるバージョンのソフトウェアである他のソフトウェアをインストールする旨の操作を受け付けた場合に、前記現ソフトウェアを残したままにして、前記他のソフトウェアをインストールするための処理を実行するソフトウェア更新手段と、
   前記ソフトウェア更新手段によって前記他のソフトウェアがインストールされた場合に、当該のストレージ装置の運用中に、前記現ソフトウェアのバージョンに対応するメタ情報テーブルを、前記他のソフトウェアのバージョンに対応するメタ情報テーブルの形式に更新するテーブル更新手段と
   を備えたことを特徴とするストレージ装置。
2. 上位装置から前記記憶装置に対するリード要求を受け付けた場合に、リード対象のデータを管理するソフトウェアのバージョンを特定する特定手段と、
   前記ソフトウェア保持部に保持されているソフトウェアのうち、前記特定手段によって特定されたバージョンに対応するソフトウェアを用いて、前記リード要求によって要求されているデータを前記記憶装置から取得するリード手段とをさらに備え、
   前記テーブル更新手段は、前記特定手段によって特定されたバージョンが最新のバージョンでない場合に、前記リード手段によって取得されたデータに関する属性情報を記憶するメタ情報テーブルを、最新のバージョンのソフトウェアに対応するメタ情報テーブルの形式に更新することを特徴とする請求項１に記載のストレージ装置。
3. 前記テーブル更新手段によってデータメタ情報テーブルが更新されることにより、対応するメタ情報テーブルが存在しなくなったバージョンのソフトウェアを削除する削除手段をさらに備えたことを特徴とする請求項２に記載のストレージ装置。
4. 前記上位装置から前記記憶装置に対するライト要求を受け付けた場合に、前記ソフトウェア保持部に保持されているソフトウェアのうち、最新のバージョンに対応するソフトウェアを用いて、前記ライト要求に含まれるデータを前記記憶装置に記憶させるライト手段をさらに備えたことを特徴とする請求項１〜３のいずれか一つに記載のストレージ装置。
5. 記憶装置へのアクセス制御を行うソフトウェアを有するストレージ装置による前記ソフトウェアを更新するソフトウェア更新方法であって、
   前記ストレージ装置が、
   既にインストールされているソフトウェアである現ソフトウェアと異なるバージョンのソフトウェアである他のソフトウェアをインストールする旨の操作を受け付けた場合に、前記現ソフトウェアを残したままにして、前記他のソフトウェアをインストールするための処理を実行するソフトウェア更新工程と、
   前記ソフトウェア更新工程によって前記他のソフトウェアがインストールされた場合に、前記ストレージ装置の運用中に、前記ソフトウェアのバージョン毎にデータの属性情報を記憶するメタ情報テーブルを、前記他のソフトウェアのバージョンに対応するメタ情報テーブルの形式に更新するテーブル更新工程と
   を含んだことを特徴とするソフトウェア更新方法。
6. 記憶装置へのアクセス制御を行うソフトウェアを有するストレージ装置による前記ソフトウェアを更新するソフトウェア更新プログラムであって、
   既にインストールされているソフトウェアである現ソフトウェアと異なるバージョンのソフトウェアである他のソフトウェアをインストールする旨の操作を受け付けた場合に、前記現ソフトウェアを残したままにして、前記他のソフトウェアをインストールするための処理を実行するソフトウェア更新手順と、
   前記ソフトウェア更新手順によって前記他のソフトウェアがインストールされた場合に、前記ストレージ装置の運用中に、前記ソフトウェアのバージョン毎にデータの属性情報を記憶するメタ情報テーブルを、前記他のソフトウェアのバージョンに対応するメタ情報テーブルの形式に更新するテーブル更新手順と
   を含んだことを特徴とするソフトウェア更新プログラム。

Images