(57)【要約】  書換寿命のあるストレージ記憶媒体を用いてプールを構成し、ホストに仮想容量を持つ論理ボリュームを提供するストレージ装置において、前記ストレージ装置は、容量プールの残書換寿命が、前記ストレージ装置の稼働期間において不足するか否かを監視し、前記残書換寿命が不足すると判断した場合、不足を賄うに必要な書換寿命をドライブ容量に換算して提示する、もしくは、既存プール容量を減少させることにより提示し、装置保守を要求する。前記提示を契機に、プールへの容量を追加することで寿命の延命を実施し、前記延命以外の追加容量については有償保守相当とする保守方式を提供する。
2016046977.tif 000002
【特許請求の範囲】
【請求項１】
ホスト計算機と接続して記憶領域を提供するストレージ装置において、
前記ストレージ装置は、
前記ホスト計算機からのデータを記憶する記憶ドライブを１つ以上有する記憶部と、
前記記憶ドライブの記憶領域を管理する制御部と
を備え、
前記記憶ドライブの内、所定のデータ書換可能量を有する不揮発メモリ記憶ドライブを複数用いてＲＡＩＤグループを構成し、当該ＲＡＩＤグループを１つ以上使用して構成されるプールを１つ以上備え、
前記制御部は、
前記プールを所定のサイズに分割した記憶領域を前記ホスト計算機へ提供し、
前記ホスト計算機から前記プールへのデータ書換量を算出し、
前記算出されたデータ書換量を前記プールでの書換可能量から減算して当該プールの残書換可能量を算出する
ことを特徴とするストレージ装置。
【請求項２】
請求項１記載のストレージ装置であって、前記制御部は、
前記不揮発メモリ記憶ドライブ毎のデータ書換量から、当該不揮発メモリ記憶ドライブの残書換可能量を算出し、
前記ＲＡＩＤグループを構成する不揮発メモリ記憶ドライブの残書換可能量から、ＲＡＩＤグループの残書換可能量を算出し、
前記プールを構成するＲＡＩＤグループの残書換可能量から当該プールの残書換可能量を算出する
ことを特徴とするストレージ装置。
【請求項３】
請求項２記載のストレージ装置であって、前記制御部は、
前記不揮発メモリ記憶ドライブでのデータ書換可能量と、予め設定され格納された前記ストレージ装置の製品寿命年数とに基づき、製品使用年数に対するプールの残書換可能量の想定曲線を生成し、
製品使用年数と、製品使用年数に対するプールの残書換可能量の推移に基づき、当該製品使用年数に対するプールの残書換可能量の実績曲線を生成し、
製品寿命到達時点でのプールの残書換可能量を、前記製品使用年数に対するプールの残書換可能量の実績曲線に基づき算出し、
前記プールの残書換可能量の実績曲線が想定曲線を下回り、前記製品寿命到達時点でのプールの残書換可能量が０を下回るときに、前記プールへ前記不揮発メモリ記憶ドライブの追加または、複数の不揮発メモリ記憶ドライブで構成されるＲＡＩＤグループの追加で、前記プールの書換可能量を増加させる
ことを特徴とするストレージ装置。
【請求項４】
請求項３記載のストレージ装置であって、前記制御部は、前記プールへの前記不揮発メモリ記憶ドライブ追加の代わりに、前記ホスト計算機へ提供していない未使用の記憶領域を、当該ホスト計算機へ提供せず書換可能量の追加として使用し、残書換可能量を増加させる
ことを特徴とするストレージ装置。
【請求項５】
請求項４記載のストレージ装置であって、前記ストレージ装置を管理する管理端末が当該ストレージ装置に接続し、当該ストレージ装置及び当該管理端末を管理する管理サーバが当該管理端末に接続し、
前記管理端末及び前記管理サーバは、それぞれ情報を表示する表示部を備え、
前記ストレージ装置は、前記算出したプールの残書換可能量、不揮発メモリ記憶ドライブの残書換可能量、プールの残書換可能量の想定曲線、プールの残書換可能量の実績曲線、追加または確保するプールの書換可能量のいずれかの１つ以上の情報を前記管理端末または前記管理サーバに送信し、
前記管理端末または前記管理サーバは、受信した情報を表示部に表示させる
ことを特徴とするストレージ装置。
【請求項６】
請求項５記載のストレージ装置であって、
前記プールの残書換可能量の実績曲線が想定曲線を下回った場合か、前記製品寿命到達時点でのプールの残書換可能量が０を下回る場合か、前記プールの残書換可能量が予め前記ストレージ装置に格納された警告閾値の量より下回った場合かのいずれかである場合、前記制御部が警告を前記管理端末または前記管理サーバに通知する
ことを特徴とするストレージ装置。
【請求項７】
請求項３記載のストレージ装置であって、前記不揮発メモリ記憶ドライブまたは前記プールまたは前記ＲＡＩＤ毎に、書換可能量及び残書換可能量が管理され、当該書換可能量及び当該残書換可能量に基づき算出された健全性が管理される
ことを特徴とするストレージ装置。
【請求項８】
請求項５記載のストレージ装置であって、前記管理サーバは、
前記受信した情報に基づき、前記ストレージ装置にプール容量を追加するか否かを判断し、
追加が必要であると判断された場合、追加が必要なプール容量及びＲＡＩＤグループ構成を算出して、前記管理端末または前記ストレージ装置に送信する
ことを特徴とするストレージ装置。
【請求項９】
請求項８記載のストレージ装置であって、前記管理サーバは、
前記算出した追加が必要プール容量及びＲＡＩＤグループ構成から必要な保守費用を算出して、当該保守費用の情報を前記管理端末または前記ストレージ装置に送信する
ことを特徴とするストレージ装置。
【請求項１０】
ホスト計算機と接続して記憶領域を提供するストレージ装置の保守運用方式において、
前記ストレージ装置は、
前記ホスト計算機からのデータを記憶する記憶ドライブを１つ以上有する記憶部と、
前記記憶ドライブの記憶領域を管理する制御部と
を備え、
前記記憶ドライブの内、所定のデータ書換可能量を有する不揮発メモリ記憶ドライブを複数用いてＲＡＩＤグループを構成し、当該ＲＡＩＤグループを１つ以上使用して構成されるプールを１つ以上備え、
前記制御部は、
前記プールを所定のサイズに分割した記憶領域を前記ホスト計算機へ提供し、
前記ホスト計算機から前記プールへのデータ書換量を算出し、
前記算出されたデータ書換量を前記プールでの書換可能量から減算して当該プールの残書換可能量を算出する
ことを特徴とするストレージ装置の保守運用方式。
【請求項１１】
請求項１０記載のストレージ装置の保守運用方式であって、前記制御部は、
前記不揮発メモリ記憶ドライブ毎のデータ書換量から、当該不揮発メモリ記憶ドライブの残書換可能量を算出し、
前記ＲＡＩＤグループを構成する不揮発メモリ記憶ドライブの残書換可能量から、ＲＡＩＤグループの残書換可能量を算出し、
前記プールを構成するＲＡＩＤグループの残書換可能量から当該プールの残書換可能量を算出する
ことを特徴とするストレージ装置の保守運用方式。
【請求項１２】
請求項１１記載のストレージ装置の保守運用方式であって、前記制御部は、
前記不揮発メモリ記憶ドライブでのデータ書換可能量と、予め設定され格納された前記ストレージ装置の製品寿命年数とに基づき、製品使用年数に対するプールの残書換可能量の想定曲線を生成し、
製品使用年数と、製品使用年数に対するプールの残書換可能量の推移に基づき、当該製品使用年数に対するプールの残書換可能量の実績曲線を生成し、
製品寿命到達時点でのプールの残書換可能量を、前記製品使用年数に対するプールの残書換可能量の実績曲線に基づき算出し、
前記プールの残書換可能量の実績曲線が想定曲線を下回り、前記製品寿命到達時点でのプールの残書換可能量が０を下回るときに、前記プールへ前記不揮発メモリ記憶ドライブの追加または、複数の不揮発メモリ記憶ドライブで構成されるＲＡＩＤグループの追加で、前記プールの書換可能量を増加させる
ことを特徴とするストレージ装置の保守運用方式。
【請求項１３】
請求項１２記載のストレージ装置の保守運用方式であって、前記ストレージ装置を管理する管理端末が当該ストレージ装置に接続し、当該ストレージ装置及び当該管理端末を管理する管理サーバが当該管理端末に接続し、
前記管理端末及び前記管理サーバは、それぞれ情報を表示する表示部を備え、
前記ストレージ装置は、前記算出したプールの残書換可能量、不揮発メモリ記憶ドライブの残書換可能量、プールの残書換可能量の想定曲線、プールの残書換可能量の実績曲線、追加または確保するプールの書換可能量のいずれかの１つ以上の情報を前記管理端末または前記管理サーバに送信し、
前記管理端末または前記管理サーバは、受信した情報を表示部に表示させる
ことを特徴とするストレージ装置の保守運用方式。
【請求項１４】
請求項１３記載のストレージ装置の保守運用方式であって、
前記プールの残書換可能量の実績曲線が想定曲線を下回った場合か、前記製品寿命到達時点でのプールの残書換可能量が０を下回る場合か、前記プールの残書換可能量が予め前記ストレージ装置に格納された警告閾値の量より下回った場合かのいずれかである場合、前記制御部が警告を前記管理端末または前記管理サーバに通知する
ことを特徴とするストレージ装置の保守運用方式。
【請求項１５】
請求項１４記載のストレージ装置の保守運用方式であって、前記管理サーバは、
前記受信した情報に基づき、前記ストレージ装置にプール容量を追加するか否かを判断し、
追加が必要であると判断された場合、追加が必要なプール容量及びＲＡＩＤグループ構成を算出して、前記管理端末または前記ストレージ装置に送信するとともに、
前記算出した追加が必要プール容量及びＲＡＩＤグループ構成から必要な保守費用を算出して、当該保守費用の情報を前記管理端末または前記ストレージ装置に送信する
ことを特徴とするストレージ装置の保守運用方式。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、書換寿命のある半導体記憶媒体を搭載するストレージ装置及びその保守運用方式に関する。
【背景技術】
【０００２】
近年、計算機やストレージシステムでは、ＨＤＤ（Hard  Disk  Drive）よりも高速にI/Oアクセスできる半導体記憶媒体が利用されている。例えば、ＮＡＮＤタイプのフラッシュメモリを用いたＳＳＤ（Solid  State  Drive）はその代表である。フラッシュメモリは、絶縁膜で遮られた浮遊ゲートに、高い電圧をかけて電子を出し入れすることでデータを記録する。絶縁膜は強制的な電子の通過によって損耗するため、データの書換回数には制限がある。プロセス微細化に伴って、この書換可能回数は減少してきている。従い、ＳＳＤなどのフラッシュメモリを用いたストレージでは、容量の管理に加えて、書換寿命も意識した運用が必要となる。【０００３】
このため、製品の経年寿命（例えば、エンタープライズ製品であれば５年）よりも先に書換寿命が来てしまうような場合、ユーザは次のいずれかの方法で対処しなければならなかった。
１つは、故障交換を待つことである。一般にストレージ装置ではＲＡＩＤ（Redundant  Array  of  Independent/Inexpensive  Disks）技術等によって冗長化がなされているので、故障してもすぐにデータ損失には繋がらない。そこで、寿命に到達したドライブは、故障扱いとして閉塞し、新たなドライブと交換することで延命する方法である。閉塞した場合、ＲＡＩＤは新たなドライブを用いてリビルド処理を行うので、終了するまでの間の処理性能の低下や可用性の低下を許容しなければならない。このため、故障前にデータをスペアにコピーして予防的に保守する技術が特許文献１として知られている。しかしながら、寿命に対する対処の考え方としては故障交換と同じである。【０００４】
もう１つは、更にフラッシュメモリドライブないし、複数のフラッシュメモリドライブで構成したＲＡＩＤ構成グループを追加し、書換量を負荷分散させて延命する方法である。一般にフラッシュメモリドライブ内では、内部に実装するフラッシュチップを偏りなく使うためのウェアレベリングの技術があるが、同様に複数のフラッシュメモリドライブ（FMパッケージ）間で書換回数（消去回数）を平準化する技術が、例えば特許文献２に記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平０５−１０００８０１号公報
【特許文献２】ＷＯ２０１１／０１０３４４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、以上の先行技術には２つの課題がある。第１の方法は、交換頻度である。ＲＡＩＤグループに対するライトデータは、構成する全てのドライブにストライプされて書かれるため、同一ＲＡＩＤグループ中のドライブ群は概ね同時期に寿命到達する。このため、１台ずつの交換であったとしても、結局のところ次々とドライブ交換が発生する。また、交換の際にはリビルドや別ドライブへのコピーが発生しシステム性能に影響を与えるものの、ユーザは能動的に対処することができない。また、交換が装置寿命（例えば５年間）近くで起きた場合、保守では無用に寿命があるドライブと交換することになる。【０００７】
そのような状況を避けたい場合には２つ目の方法があるが、どれだけ追加すれば適切な延命が可能となるか判断する指標がない。このため、ドライブ追加する保守事業者は妥当性が判断できない。また、運用管理者にとっては、突然全体の容量が増加してしまうため、容量管理上でも問題が生じる可能性がある。【０００８】
本発明は上記に鑑みて成されたものであり、本発明の目的は、寿命不足を解消するために必要な容量を分かるようにし、保守事業者が無駄の少ない保守交換を可能にする装置および保守情報を提供することである。また、本発明の別の目的は、運用管理者が既存の容量運用管理で、書換寿命も管理できるようにすることである。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明の一実施形態のストレージ装置では、１以上のストレージコントローラと複数のＮＶＭ（Non-Volatile  Memory）ドライブを備え、前記ストレージコントローラは、前記ＮＶＭドライブを用いて記憶容量プールを構成する手段と、前記構成された容量プールの残書換可能容量を算出し、前記残書換可能容量に基づき、前記ストレージ装置の稼働期間において残書換寿命が不足するか否か判断し、前記寿命が不足すると判断した場合、寿命不足分を補うために必要となるプールに追加するドライブ容量を算出する。
【発明の効果】
【００１０】
本発明によれば、不揮発性記憶媒体の寿命の不足解消に必要なプールへの追加必要量を定量的に知ることができるので、必要最小限の容量で寿命を保守することが可能になる。また、寿命の不足がプール容量の減少に反映されるので、運用管理者は、容量と寿命を一元的に管理することが可能となる。前述以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【００１１】
【図１】図１は、本発明の実施形態におけるストレージ装置の構成を表すブロック図である。
【図２】図２は、本発明の実施形態におけるストレージ装置の外観を表す図である。
【図３】図３は、本発明の実施形態における仮想論理ボリューム、容量プール、ＲＡＩＤグループ、ドライブの関係を表す模式図である。
【図４】図４は、本発明の実施形態におけるストレージ装置のプール容量の管理画面を示す図である。
【図５】図５は、本発明の実施形態における、ドライブの管理情報テーブルを示す図である。
【図６】図６は、本発明の実施形態における、ＲＡＩＤグループ管理情報テーブルを示す図である。
【図７】図７は、本発明の実施形態における、プール管理情報テーブルを示す図である。
【図８】図８は、本発明の実施形態における、経年寿命と書換寿命、及び残書換可能容量との関係を表す図である。
【図９】図９は、本発明の実施形態１におけるストレージ装置がプール寿命を管理するための監視制御フローを示したフローチャートである。
【図１０】図１０は、保守作業のフローチャートである。
【図１１】図１１は、ストレージ装置が構成可能なＲＡＩＤグループと書換可能容量（保守ドライブ容量）との対応を示すＲＧ管理テーブルである。
【図１２】図１２は、本実施形態におけるストレージ装置１がプールの寿命管理を行う際の動作を示したフローチャートである。
【図１３】図１３は、本実施形態におけるストレージ装置１が運用管理端末３１を通じて提供する、容量プール空き容量の推移を示したＧＵＩの一例である。
【図１４】図１４は、本実施形態における保守方法の形態を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、図面を参照しながら実施の形態を説明するが、実施例で部分変更によって実施できる形態は、各実施例内で変形例として記述する。また、以下の説明では、「管理テーブル」等の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。また、データ構造に依存しないことを示すために「管理テーブル」を「管理情報」と呼ぶことができる。
【００１３】
また、「プログラム」を主語として処理を説明する場合がある。そのプログラムは、プロセッサ、例えば、ＭＰ（Micro  Processor）やＣＰＵ（Central  Processing  Unit）によって実行されるもので、定められた処理をするものである。なお、プロセッサは、適宜に記憶資源（例えばメモリ）及び通信インターフェース装置（例えば、通信ポート）を用いながら処理を行うため、処理の主語がプロセッサとされてもよい。プロセッサは、ＣＰＵの他に専用ハードウェアを有していてもよい。コンピュータプログラムは、プログラムソースから各コンピュータにインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアなどで提供されるものであってもよい。
【００１４】
また、各要素、例えば、コントローラは番号などで識別可能であるが、各要素を識別可能な情報であれば、名前など他種の識別情報が用いられてもよい。本実施例の図及び説明において同一部分には同一符号を付与しているが、本発明が本実施例に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に限定しない限り、各構成要素は複数でも単数でも構わない。
【００１５】
＜実施例１＞
実施例１について、図１〜図９を用いて説明する。
図１は本実施形態における、書換回数に制約のある不揮発メモリドライブ（ＮＶＭドライブ）を搭載したストレージシステムの構成を示すブロック図である。ＮＶＭドライブＤ０〜Ｄｎは、例えばＳＳＤや、アドインカードや独自の形態を持つモジュールである。ストレージ装置１は、コントローラ筐体５０とドライブ筐体５１から構成される。ただし、ストレージ装置１が汎用的なサーバ機器によって実現されるような場合、各筐体は区別されないこともある。ストレージ装置１は管理用ネットワーク３０を通じて運用管理端末３１と接続されており、装置の設定や情報の取得はこの運用管理端末３１を通じて実施することができる。運用管理端末３１はストレージ装置１の一部として含まれていてもよい。
【００１６】
また、ストレージ装置１はストレージネットワーク４０を通じてホスト計算機２０Ａ〜２０Ｃと接続されている。ストレージネットワーク４０や、Ｆｉｂｒｅ  ＣｈａｎｎｅｌやＥｔｈｅｒｎｅｔ（登録商標）ネットワーク、あるいはＰＣＩ−Ｅｘｐｒｅｓｓ（登録商標）によって実現される。ホスト計算機２０Ａ〜２０Ｃではオペレーティングシステムおよびその上で動作するアプリケーションが動作し、ストレージ装置１に対してＩ／Ｏを発行する。なお、ストレージ装置が汎用的なサーバ機器によって実現されるような場合、ホスト計算機とストレージ装置は物理的に同一の場合もあり、その際ストレージネットワーク４０は省略されることがある。また、ホスト計算機は仮想マシンのようにソフトウェア的に実現される形態である場合がある。
【００１７】
ＮＶＭドライブＤ０〜Ｄｎは、ドライブ筐体５１に設けられたバックエンド接続機構５００、およびバックエンド接続配線５１０、および、コントローラ筐体５０内に設けられたＩ／Ｆカード９０Ａ、９０Ｂを通じてストレージコントローラパッケージ７０Ａ、７０Ｂと接続される。バックエンド相互接続機構５００は、例えばＳＡＳ（Serial  Attached  SCSI）エクスパンダやＰＣＩ−Ｅｘｐｒｅｓｓスイッチであり、バックエンド接続配線５１０は、例えばＳＡＳケーブルやＰＣＩ−Ｅｘｐｒｅｓｓケーブルなどである。また、Ｉ／Ｆカード９０Ａ、９０Ｂは例えばＳＡＳプロトコルチップを搭載したＨＢＡ（Host  Bus  Adapter）や、ＰＣＩ−ＥｘｐｒｅｓｓのＥｘｔｅｎｔｉｏｎボード等である。
【００１８】
コントローラ筐体５０には、ストレージ制御プログラムが動作するストレージコントローラパッケージ７０Ａ、７０Ｂ、前述のドライブ接続用Ｉ／Ｆカード９０Ａ、９０Ｂ、およびホスト計算機２０Ａ〜２０Ｃと接続するためのＩ／Ｆカード８０Ａ、８１Ａ、８０Ｂ、８１Ｂが設けられている。両コントローラは相互のデータ転送するために、複数の内部データ転送パス６１、６２で接続されている。
【００１９】
なお、本実施形態では各パッケージはＡ系、Ｂ系の２系統で示したが、２以上のパッケージが設けられ、互いに接続されていても構わないし、あるいは、Ｉ／Ｆカード（例えば、９１Ａまたは９１Ｂ）を通じて複数ストレージコントローラ筐体５０同士が結合されていてもよい。あるいは、Ａ系のみで構成されていてもよい。
【００２０】
運用管理端末３１またはストレージ装置１は、ネットワーク９５を介し保守センタ９９の管理サーバに接続される。これにより、後述するＮＶＭドライブで構成されたプールの残書換容量や残寿命などの情報を取得し、ストレージ装置１の状態を監視・管理することができる。また、管理サーバ９９１は、保守センタからのリモート保守作業や保守費用請求情報の運用管理端末３１への送信も行うことができる。なお、管理サーバ９９１を直接ストレージ装置１に接続してもよい。
【００２１】
図２は、本実施形態におけるストレージ装置の理解を助けるために示した外観図である。
ストレージ装置１のコントローラ筐体５０は図に示すラックの下部に搭載されており、その上にドライブ筐体５１、５２、５８が示されている。図に表れていないが、背面には先に示したバックエンド接続配線５１０やストレージネットワーク４０を構成するためのケーブルが配線される。
【００２２】
図３は、本実施形態におけるストレージ装置１がホスト計算機２０Ａ〜２０Ｃに提供する仮想論理ボリューム１２０Ａ〜１２０Ｃと容量プール１１０、ページ群１１５、ＲＡＩＤグループ群１００、及びＮＶＭドライブＤｎ（Ｄ０〜Ｄ３等）との関係を示した図である。
【００２３】
本実施形態におけるストレージ装置１は、仮想的論理ボリューム１２０をホスト計算機２０に提供し、アクセスされた部分だけ実際の容量を割り当てていく、いわゆるＴｈｉｎ Ｐｒｏｖｉｓｉｏｎｉｎｇと呼ばれる技術を用いる。
【００２４】
ストレージ装置１は、何台かのＮＶＭドライブＤｎを用いてＲＡＩＤを構成する。これをＲＡＩＤグループと呼ぶ。例えば、ＲＡＩＤグループ１００Ａは、Ｄ０、Ｄ１、Ｄ２、Ｄ３の４台のドライブを用いて３Ｄ＋１Ｐが構成される。
【００２５】
容量プール１００は、１つ以上のＲＡＩＤグループから構成される。容量プール１１０は、任意の時点でＲＡＩＤグループを追加することが可能であり、これによりプールの容量を増加させることができる。また、容量プール１１０は、ページ１１５と呼ばれる数ＫＢないし数ＭＢで区切られた固定長単位で管理される。
【００２６】
ホスト計算機２０Ａ〜２０Ｃは、ストレージ装置１が提供する仮想論理ボリューム１２０Ａ〜１２０Ｃを用いてアクセスする。仮想論理ボリューム１２０Ａ〜１０２Ｃは、仮想的な容量を持つ空のボリュームである。ホスト計算機２０によって仮想論理ボリューム１２０へデータがライトされると、ストレージ装置１は、容量プール１１０から仮想論理ボリューム１２０上の当該ＬＢＡ領域へページ１１５単位で実体を割当てる。より具体的には、ストレージ装置１は、仮想論理ボリュームのＬＢＡと容量プールのＬＢＡとの対応関係をページ単位で管理するページマッピング情報を持ち、この情報を更新する（図示せず）。
【００２７】
なお、ストレージ装置１は、割当てるページを決定する際、複数のＲＡＩＤグループに負荷分散するようページを選択するほか、書換回数の平準化を図るよう選択する。
【００２８】
容量プール１１０はページ１１５単位で管理されているので、割当済みページ数は、容量プールの使用済み容量とほぼ同義であり、未割当かつ利用可能なページ数が空きプール容量と同義である。
【００２９】
図４は、本発明の実施形態のストレージ装置１が運用管理端末３１を通じて提供する、容量プール空き容量の推移を示したＧＵＩ（Graphic  User  Interface）の一例である。画面２００の横軸は容量プールの運用を開始してからの使用経過時間（例えば日数や月数）を表し、縦軸はプールの空き容量を示している。実線２１１は、プール容量の変動推移を示しており、例えば時点（Ａ）は、プールへの容量追加が行われ、空き容量が回復している様子を表している。
【００３０】
点線２１５は、空き容量枯渇を防ぐ為の閾値を示すラインである。空き容量の推移２１１が本閾値（例えば、全プール容量の２０％以下）に達すると、ストレージ装置１は、運用管理端末３１や装置ＳＮＭＰ（Simple  Network  Management  Protocol）によって運用管理者にプールへの容量追加（ＲＡＩＤグループの追加）が必要であることを通知（あるいは警告）する。
【００３１】
図５は、本発明の実施形態におけるストレージ装置１が運用管理端末３１を通じて運用管理者に提供する、ＮＶＭドライブ管理テーブルの一例である。ＮＶＭドライブ管理テーブル２５０は、ＮＶＭドライブ毎の容量、稼働時間及び残寿命時間などを管理するテーブルである。ＮＶＭドライブ管理テーブル２５０では、例えば番号２のドライブは、容量１.６ＴＢ、ＲＡＩＤグループ（ＲＧ）０に属しており、ドライブの書換寿命消費率（消費寿命）は８５％、ドライブ稼働時間が３４、２７８時間、書換可能容量である規定ＢＷ（Bite  Written）は１２ＰＢであることが分かる。
【００３２】
図６は、本実施例におけるストレージ装置１が運用管理端末３１を通じて提供するＲＡＩＤグループの管理情報テーブル（ＲＧ管理情報テーブル２６０）の一例である。ＲＧ管理情報テーブル２６０は、ＲＧ毎の容量、残書換可能容量、ＮＶＭドライブの健全性状態（「良」：健全性高・劣化小、「警告」：健全性低・劣化大）などを管理するテーブルである。ＲＧ管理情報テーブル２６０では、例えば、ＲＡＩＤグループ０（ＲＧ０）は、容量４.８ＴＢで、容量プールＰＶＯＬ０に所属しており、残り書換可能容量（残ＢＷ）は３.２ＰＢであり、健全性状態は「良」であることを示している。なお、図示はしていないが、ＮＶＭドライブ管理テーブル２５０と同じくＲＧ毎の規定ＢＷ（ＲＧを構成するＮＶＭドライブ１台当たりの規定ＢＷ）を管理してもよい。また、健全性状態は、残ＢＷの容量の絶対値で判断してもよく、また、規定ＢＷに対する残ＢＷの割合（％）という相対値で判断してもよい。
【００３３】
図７は、図６と同様にプールの管理情報テーブルの一例である。プール管理テーブル２８０は、プール毎の容量、残書換可能容量、フラッシュメモリの劣化状態（劣化小：「良」、劣化大：「警告」）などを管理するテーブルである。例えばプールＰＶＯＬ０の容量は１９.２ＴＢ、残書換可能容量（残ＢＷ）１５．０ＰＢで、２４ＰＢの対寿命不足容量が見込まれ、ＮＶＭドライブの状態は「警告」となっていることが分かる。なお、本例では、状態が「良」か「警告」かのみを示しているが、「良」と「警告」との中間の「要注意」などの状態を設けてもよい。また、図示はしていないが、ＮＶＭドライブ管理テーブル２５０と同じくプール毎の規定ＢＷ（プールに属するＲＧの規定ＢＷの合計）を管理してもよい。なお、健全性状態は、残ＢＷの容量の絶対値で判断してもよく、また、規定ＢＷに対する残ＢＷの割合（％）という相対値で判断してもよい。
【００３４】
図８は、ＮＶＭドライブの経年寿命（製品寿命）と、ＮＶＭドライブへのライト量等によって変動する書換寿命との関係を模式的に示したものである。なお、書換寿命は、ライトの間隔やパターン、温度によっても変化するが、説明の本質ではないため、割愛する。また、なお、図８（１）、図８（２）ではドライブを例に示すが、ＲＡＩＤグループやプールに置き換えても、考え方は同様である。また、図８と同様の情報を、運用管理端末３１や運用管理サーバ８１が表示できるようにしてもよい。
【００３５】
ＮＶＭドライブは、設計時に規定された書換可能容量（規定ＢＷ）があり、想定より書換が多く行われれば経年寿命より先に書換寿命に達し（図８（１））、一方、想定より書換が少なく行われれば、ＮＶＭドライブは、経年寿命（製品寿命）を全うする（図８（２））。経年寿命とは、いわば製品の賞味期限に相当し、エンタープライズ製品の場合、例えば使用開始後５年である。
【００３６】
書換寿命が経年寿命より先に訪れるか否かは、書換寿命と経年寿命が等しく達するとして均一利用を想定したラインとの大小関係によって、ある程度把握することができる。
【００３７】
図８（１）は、想定より多く書き込まれた（すなわち残書換容量の減少が速い）ケースを表している。想定ライン３１０は、書換寿命が経年寿命とほぼ等しくなるように均一のペースで利用された場合の減少を表すラインである。実際の推移３２０は名の通りであり、その傾きで利用され続けた場合の外挿を点線で示している。点（ａ）および（ｂ）の差分３３０は、現時点３５０において想定よりも消費してしまっている書換容量を表している。このペースで利用され続けた場合、この図のドライブは横軸と交差する点３６０で書換寿命を迎える。また、点（ｃ）と（ｄ）の差分３４０は、経年寿命を全うするために不足する書換容量の期待値を表す。
【００３８】
図８（２）は、図８（１）とは逆に想定よりも書込が少なかったケースを表している。差分３３１は、現時点３５０において、想定よりも余っている書換容量を表している。このペースで利用され続けた場合、想定に対する余剰は徐々に拡大していく。差分３４１は、経年寿命を迎えた際に余剰となる書換容量である。
【００３９】
図８（１）と図８（２）で示される２つのドライブ間で書換負荷を平準化する場合を考える。差分３３０と差分３３１で示される時点では、不足を示す差分３３０の方が、余剰を表す差分３３１より大きいので、平準化しても想定ラインを下回る。すなわち、経年寿命を満たせないと判断される。
【００４０】
一方、現時点では不足すると判断された場合でも、経年寿命時点で比較すると余剰を表す差分３４１の方が差分３４０より大きいので、平準化すれば想定ラインを上回る。すなわち、経年寿命を満たすと判断される。
【００４１】
以上のように、現時点で不足するからといって必ずしも、将来不足するとは限らない。また、現時点における過不足は取得値の単純な比較によって求められるので、計算コストは小さいが、将来の過不足は期待値を求める為に、値の推移を統計処理する必要があり、計算コストは大きい。これを踏まえて、図９にて本ストレージ装置１での寿命管理について説明する。
【００４２】
図９は、本実施形態におけるストレージ装置１がプール寿命を管理するための監視制御フローを示したフローチャートである。本フローチャートの処理は、ストレージ装置１のストレージコントローラ７０によってある一定時間ごと、あるいはプールへの容量追加など、ある契機に基づいて実行される。
【００４３】
ストレージ装置１は、初めにプールに含まれる各ドライブの残書換可能容量を、ＳＭＡＲＴ（Self-Monitoring  Analysis  and  Reporting  Technology）やＬＯＧ  ＳＥＮＳＥコマンドなどの手段を用いて取得する（Ｓ１０００）。残書換可能容量が直接取得できない場合には、ストレージ装置１はドライブの寿命消費率の推移や、ＷＡ（Write  Amplification）比率、あるいはエラーブロック数等、ストレージコントローラが取得できる情報に基づいて残書き換え可能容量を推論する。なお、ストレージ装置１は、累計デステージ容量等から各ドライブの残書換可能容量を求めてもよい。
【００４４】
そして、ストレージ装置１は、当該ドライブの仕様から算出される想定ラインとの差から現時点における書換寿命の過不足を算出する（Ｓ１２００）。
【００４５】
次にストレージ装置１は、ドライブ毎の書換寿命過不足からＲＡＩＤグループの書換寿命過不足を求める（Ｓ１３００）。具体的にはＲＡＩＤグループ中で最も寿命が不足するドライブの値を、当該ＲＡＩＤグループの値とする。なぜならば、ＲＡＩＤグループは１台が故障すると縮退してしまうためである。なお、縮退ではなく閉塞を契機として寿命を求めてもよい。
【００４６】
複数のＲＡＩＤグループに書き込みが平準化される場合、プールの寿命過不足は、ＲＡＩＤグループの過不足の総和と考えてよい。そこで、ストレージ装置１は、各ＲＡＩＤグループの書換寿命過不足の総和を算出して、プールの書換寿命過不足を求める（Ｓ１４００）。
そして、プールの書換寿命が現時点で不足しているか、すなわちプール書換寿命の過不足の総和が負となるか否かを判断する（Ｓ１５００）。なお、Ｓ１５００の後に、後述するＳ２０００またはＳ２０５０のような「プール状態の警告／要注意の通知」等をおこなってもよい。
現時点でのプールの書換寿命の不足がないと判断された場合（Ｓ１５００：Ｎｏ）、ストレージ装置１は監視の結果をプール管理テーブル２８０に「良」として更新し（Ｓ１６５０）、処理を終了する
【００４７】
一方、不足すると判断された場合（Ｓ１５００：Ｙｅｓ）、ストレージ装置１は、装置リプレースまでの期間でプールの書換寿命容量がどれだけ不足するか、各ドライブの期待値を求める処理（Ｓ１６００からの処理）に入る。なお、ここで求めるべきは装置リプレース時点での不足量であり、各ドライブの経年寿命到達時でない点に注意されたい。運用の途中で追加されたドライブは経年寿命を待たずにストレージ装置全体がリプレースされるからである。なお、ストレージ装置１の導入からリプレースまでの期間、すなわち、ストレージ装置の製品寿命年数は、特に指定がなければ、標準の装置保証期間（例えば５年）と同じに設定される。
【００４８】
ストレージ装置１は、過去の統計情報から、各ドライブの書換容量の減少傾きをそれぞれ求める。そして、装置自身のリプレース時期における当該書込み必要容量を外挿法（補外法：ある既知の数値データを基にして、そのデータの範囲の外側で予想される数値を求める手法）によって求める。そして想定ラインとの差から、ドライブ毎の書換容量の過不足量を算出する（Ｓ１６００）。
次にストレージ装置１は、Ｓ１３００と同様の方法で各ＲＡＩＤグループの過不足を算出する（Ｓ１７００）。そして、最終的にプールの過不足総量を求める（Ｓ１８００）。なお、前述のようにドライブ毎の書換可能容量の想定ラインと書換実績による残書換可能容量を、ＲＧ毎またはプール毎に設定及び算出することで、マクロ視点での記憶容量管理も可能とできる。
【００４９】
不足すると判断された場合（Ｓ１９００：Ｙｅｓ）、ストレージ装置１は、当該容量プールは現時点においても書換寿命が不足しており、将来的にも不足する見通しであると判断する。そこでストレージ装置１は、前記容量プールへのドライブ追加を促すため、プール管理テーブル２８０において、当該プールの状態を「警告」とし、対寿命不足書換容量としてＳ１４００で求めた値を表示する（Ｓ２０００）。
【００５０】
一方、装置リプレースまで不足しないと判断された場合（Ｓ１９００：Ｎｏ）、現時点では不足しているものの、ストレージ装置１に今すぐドライブを追加する必要性は低いとストレージ装置１は、判断する。そこで、プール管理テーブル２８０において、当該プールの状態を「要注意」とし（Ｓ２０５０）、ストレージ装置１は、処理を終了する。なお、図８（２）のように、書換寿命が製品寿命より長くなるケースがあるので、予め少ないプール容量でストレージ装置１の使用を開始して、上述の処理を適宜実行してプール容量の追加を実行する運用を用いてもよい。
【００５１】
図１０及び図１１を用いて、本実施形態におけるストレージ装置において、プール寿命が「警告」となった際の保守について説明する。図１０は保守作業のフローチャートであり、図１１は、本ストレージ装置が構成可能なＲＡＩＤグループと書換可能容量（保守ドライブ容量）との対応を示すＲＧ管理テーブル６００である。なお、ストレージ装置の運用管理者は、別途ストレージ装置の保守提供者と保守サービス契約を締結していることを前提に説明する。
【００５２】
プール寿命が「警告」となった場合、運用管理者は随時ないし計画的なタイミングで保守事業者へ保守作業を依頼する。そのため、保守作業の依頼を運用管理端末３１に入力し、運用管理端末３１は、保守作業の依頼情報を受け付け保守センタ９０の保守管理サーバ９９１に送信する（Ｓ５０００）。保守管理サーバ９９１（保守提供者側）は、図７に示すプール管理テーブル２８０、または、それに相当する保守専用画面の情報を参照して、プールの対寿命不足書換容量を算出する（Ｓ５１００）。そして保守事業者は、保守用ドライブの規定書換可能容量（規定ＢＷ）と、図構成可能なＲＡＩＤグループ構成から、不足容量を満たす構成を求める（Ｓ５２００）。
【００５３】
例えば、図７に示すように対寿命不足容量が２４ＰＢであったとする。今回用いる保守用ドライブＡの規定ＢＷが１２ＰＢであった場合、「２４ＰＢ÷１２ＰＢ＝２」より２台以上のデータドライブを持つＲＡＩＤグループを追加すれば不足を解消できる。図１１の一覧表６００より、当該容量を持つ構成はＮｏ.１の３Ｄ＋１Ｐか、Ｎｏ.１０の３Ｄ＋２Ｐであることが分かる。そこで、保守管理サーバ９９１（保守提供者側）は、保守サービス契約の締結内容に応じて、追加するデータドライブ（ＮＶＭドライブ）を持つＲＡＩＤ構成を決定する。例えば、保守管理サーバ９９１により追加するデータドライブを持つＲＡＩＤ構成がＮｏ.１の３Ｄ＋１Ｐ（容量３６ＰＢ＝１２ＰＢ／ドライブ×３データドライブ）に決定されたとする。
【００５４】
保守提供者は、必要となる台数の保守ドライブをストレージ装置１に装填し、保守作業用の端末または運用管理端末３１からＲＡＩＤグループ（ここでは、３Ｄ＋１Ｐ）を構成する。そして、保守提供者は、構成したＲＡＩＤグループのＮＶＭドライブを「警告」となっているプールへ追加する。ストレージ装置１は、追加されたＲＡＩＤグループに関する情報を受け付ける（Ｓ５３００）。
【００５５】
ＲＡＩＤグループが追加されると、ストレージ装置１では、図９に示される監視フローが実行され、再びプールの状態が診断される。追加前のプールの対寿命不足容量は２４ＰＢであり、今回３６ＰＢの書換寿命をもつＲＡＩＤグループが追加されたので、プールの過不足総和は、負（−）の−２４ＰＢから正（＋）の＋１２ＰＢとなる。そのため、ストレージ装置１は、運用管理端末３１での「警告」表示を消す。
保守提供者は、当該プールの状態が「警告」でなくなったことを確認して保守を終える（Ｓ５４００）。
【００５６】
以上によれば、本発明の実施形態におけるストレージ装置１は、現時点の取得値に基づいて過不足を少ない計算量で判断した後に、必要に応じて将来的な過不足を判断し、その容量を定量的に示す事ができるので、プールに追加すべき容量が分かり、必要最小限の容量で保守することが可能になる。
【００５７】
＜実施例１の変形例１＞
実施例１では、保守管理サーバ９９１（保守作業者側）は、保守ドライブの書換可能容量と構成可能なＲＡＩＤグループのＲＧ管理テーブル６００から、ＲＡＩＤ構成を決定していた。しかしながら、保守管理サーバ９９１の代わりにストレージ装置１自体がこれらを判断し、プール管理テーブル２８０に追加すべき構成を提示するようにしてもよい。この場合、保守作業者によるオペレーションミスを減らすことができ、より確実な保守が可能となる。
【００５８】
＜実施例１の変形例２＞
実施例１では、ＲＡＩＤを構成してからプールに追加するストレージ装置の構成を示したが、あらかじめＲＡＩＤグループを構成することなく、ドライブ単位でプールに追加できるストレージ装置がある。このような装置の場合、ストレージ装置１は、プール管理テーブル２８０に、対寿命不足書換可能容量に代わり、不足ドライブ容量もしくは不足ドライブ台数の情報を格納し、運用管理端末３１や保守管理サーバ９９１に通知してもよい。この場合、ＲＡＩＤグループ構成の制約を受けないため、更に無駄の少ない保守が可能となる。また、保守作業者によるオペレーションミスを減らすことができ、より確実な保守が可能となる。なお、保守作業者によるＮＶＭドライブの追加ではなく、予めストレージ装置１にＲＧ追加用のＮＶＭドライブを搭載して、それを自動的にＲＧ構成してプールに追加するようにしてもよい。
【００５９】
＜実施例２＞
実施例１では、装置の稼働期間中に必要なプール寿命不足分を、不足書換容量として提示し、保守する方法について述べた。しかし、運用管理者は、依然として寿命視点での管理（図７）と容量利用視点での管理（図４）とを個別に行わなければならない。そこで実施例２では、プール寿命の不足分を図４の画面２００に示すようなプール容量推移に反映することで、容量管理のみで寿命も管理できるようにする。本実施例における装置の構成形態は実施例１に同じであるが、寿命不足時の処理と通知方法が異なるため、その差分についてのみ記述する。
【００６０】
図１２は、本実施形態におけるストレージ装置１がプールの寿命管理を行う際の動作を示したフローチャートである。なお、Ｓ１０００（各ドライブの残書換可能容量の取得）〜Ｓ１４００（プールの書換寿命過不足の算出）については、実施例１（図９）に同じであるため、説明を省略する。
【００６１】
プールの書換寿命が不足と判断した場合（Ｓ１５００：Ｙｅｓ）、ストレージ装置１は書換寿命不足分を賄うのに必要なストレージ容量を算出し、当該容量を利用不可、すなわちプール容量から減少させる処理を行う。これにより、実施例１にて保守追加していた容量を、保守に先んじて既存プールから確保する。なお、以下の説明ではプールに含まれるＲＡＩＤグループの利用は平準化されていることを前提とする。
【００６２】
ストレージ装置１は、プールに含まれるＲＡＩＤグループの容量比率に応じて、書換容量不足分を各ＲＡＩＤグループへ按分する（Ｓ３０００）。例えば、図６において、プールＰＶＯＬ０はＲＡＩＤグループ ＲＧ０、ＲＧ１、ＲＧ２から構成されており、各ＲＡＩＤグループの容量は４.８ＴＢ、４.８ＴＢ、９.６ＴＢであるから、書換容量不足分は１：１：２で按分される。  
【００６３】
次に、ストレージ装置１は、当該ＲＡＩＤグループの残書換可能容量を決定しているドライブを特定し、按分された不足書換容量に、当該ドライブの容量と規定書換可能容量（規定ＢＷ）との比を乗じ、不足をカバーするために当該ＲＡＩＤグループで使用不可とすべき容量を求める。すなわち「按分された不足書換量×（ドライブ容量÷ドライブ規定ＢＷ）」として求める（Ｓ３１００）。
【００６４】
例えば、ＲＧ０において按分された不足書換量が６ＰＢとする。図５よりＲＧ０を構成するドライブの容量はいずれも１.６ＴＢであり、規定ＢＷは１２ＰＢである。従い、「６ＰＢ×（１.６ＴＢ÷１２ＰＢ）＝０.８ＴＢ」であるからＲＧ０は、ＲＧ容量０.８ＴＢを無効とすればよいことが分かる。
【００６５】
ストレージ装置１は、求められた容量に応じ、当該ＲＡＩＤグループに所属するページ１１５を何ページ無効にすべきか（利用不可にすべきか）を求める（Ｓ３２００）。例えば、ページ１１５のサイズが４０ＭＢであった場合、ＲＧ０では０.８ＴＢ／４０ＭＢ＝２０Ｋページを無効にする必要があることが分かる。このようにして各ＲＡＩＤグループにおいて求めたページ数を有効ページから削減する（Ｓ３３００）。
そして、ストレージ装置１は、定期的な監視によってプール容量の推移画面の更新を行い、処理を終了する（Ｓ３４００）。
【００６６】
前述の通り、未使用の有効ページ数はプールの空き容量と同義であるから、以上の処理によって、プール寿命の不足分に相当する有効ページ数を削減することは、利用可能なプールの容量を減少させることに等しい。
【００６７】
図１３は、本実施形態におけるストレージ装置１が運用管理端末３１を通じて提供する、容量プール空き容量の推移を示したＧＵＩの一例である。画面４００では、仮想論理ボリュームへのページ割当による容量プールの推移を表している点線２１１に加え、寿命不足分を反映した線４１１が示されている。寿命の不足が全くない状況下では、点線２１１と線４１１は一致する。一方、寿命の不足が発生しはじめた状況下で、既存のページに対してデータ更新が行われた場合、新たなページの消費は発生しないので点線２１１は変化しないが、書換による寿命の消費(不足分)は増大するので、線４１１は以前よりも減少した位置を示すようになる。従い、運用管理者は、画面４００のようなプール容量の推移を管理しさえすれば、寿命も合わせて管理することができる。
【００６８】
図１４は、本実施形態における保守方法の形態を示すフローチャートである。実施例１との違いは、プール残量の低下であり、保守契機が寿命とは限らないことである。すなわち、単に仮想論理ボリューム１２０への容量割当によりプール残量が減った場合もある。
【００６９】
以下の説明では、実施例１と同様に、運用管理者は保守提供者と保守サービス契約を締結しており、寿命保守分にあたる容量については無償保守とする。一方、仮想論理ボリューム割当の為の容量追加は有償（プールの購入）となるものとする。
【００７０】
運用管理者は、プール残量が減少してきた場合、計画的な保守によってプールへの容量追加を行うため、保守を依頼する。そのため、保守作業の依頼を運用管理端末３１に入力し、運用管理端末３１は、保守作業の依頼情を受け付け保守センタ９０の保守管理サーバ９９１に送信する（Ｓ６０００）。あるいは、運用管理者が運用管理端末３１に設定したルールに基づいて、運用管理端末３１が自動的に保守を依頼するようにしてもよい。
【００７１】
保守管理サーバ９９１（保守提供者側）は、図１３の画面４００ないしそれに相当する保守用管理情報を取得（確認）し、プールの減少状況と寿命での減少分とを算出（確認）する（Ｓ６１００）。
【００７２】
そこで、保守管理サーバ９９１（保守提供者側）は、保守契約の締結内容、または、運用管理者が定める保守手順書等の情報に基づいて、プールに追加する容量やＲＡＩＤグループ構成を決定する（Ｓ６２００）。そして、保守提供者は、決定したＲＡＩＤグループ構成をストレージ装置１のプールに追加する。ストレージ装置１は、追加されたＲＡＩＤグループに関する情報を受け付ける（Ｓ６３００）。
【００７３】
保守管理サーバ９９１（保守提供者側）は、追加した容量が無事空き容量プールとして反映された結果を取得（確認）する。そして、保守管理サーバ９９１（保守提供者側）は、追加したプール容量のうち、寿命解消分にあたる容量分の保守費用を割り引いて容量追加の有償保守費用を算出して、運用管理端末３１（運用管理者側）へ保守費用の請求情報を送信する。運用管理端末３１（運用管理者側）は、保守管理サーバ９９１（保守提供者側）からの保守費用の請求情報を受信する（Ｓ６４００）。以上で運用管理端末３１を含むストレージ装置１と、保守センタ９９の保守管理サーバ９９１での処理を終了する。
【００７４】
以上の実施形態によれば、運用管理者は、プールの寿命と、プールの純粋な利用による容量変動とを個別に管理することなく、容量の変動のみの監視で運用することができるので、運用の簡素化を図る事ができる。また、保守提供者は、寿命保守と容量保守とを区別することなく、プールへの容量追加として一本化することができるので、費用的無駄の少ない保守が可能となる。また、無償範囲となる容量がストレージ装置によって明示されているので、適切な費用を運用管理者に請求することができる。
【００７５】
＜実施例２の変形例１＞
実施例２の画面１３では、寿命による減少分と仮想論理ボリュームへの容量割当分とを分けて示したが、運用管理者はもはや寿命そのものを考慮する必要がなくなるので、寿命分をあえて表示しないようにしてもよい（すなわち線４１１だけとする）。
この場合、従来のＨＤＤのみ搭載したストレージ装置と同様の運用が可能となる。
また、保守提供者は、書込み量に応じた容量追加の保守費用を運用管理者へ請求できるので、高Ｉ／Ｏで利用するユーザ（寿命不足が大きいユーザ）に対しても、低Ｉ／Ｏで利用するユーザ（寿命不足が小さいまたは無いユーザ）に対しても、公平な保守サービスを提供することができる。
【００７６】
以上本発明の実施形態では、従来のＮＶＭドライブ交換に比べ、少ない回数及び費用で保守を行うことも可能となる。例えば、３Ｄ＋１Ｐで１ＲＧを構成し、３ＲＧで構成されるプールにおいて、製品寿命の1年前に保守交換となった場合、従来では、計１２台のドライブ（４ドライブ／ＲＧ×３ＲＧ）の交換と、最低４回の保守作業（１ＲＧ毎に、１回につき１台のドライブ交換しかできない）が必要となっていた。
【００７７】
一方、本発明の実施形態では、（３データドライブ×３ＲＧ）÷（５年寿命／ドライブ）で計算される追加プール容量を追加すればよい。上記を計算すると約２ドライブなので、保守作業では高々１ＲＧ分（４ドライブ）を１回だけ追加すればよい。そのため、従来に比べ保守作業工数・時間・費用（人件費及び材料費（ドライブ代金など））を、最低約７割低減できるという効果がある。また、ＲＧ単位でドライブを追加することで、アクセス負荷がプールでリバランスされる（負荷分散）ので、上位装置からのアクセス性能の向上も望める。
【００７８】
更に、本発明の実施形態では、ＮＶＭドライブの寿命不足に対し、プール容量の追加で賄えるため、運用の変化に対しても柔軟に対応可能となる。このため、導入段階における書換量の見積もりや、使用条件に応じたドライブのモデル選択（高耐久モデル/リードインテンシブモデル等）が不要となり、事前設計の簡素化と、運用開始までのリードタイムを短縮することができる。加えて、ＮＶＭドライブも、複数モデルを設ける必要がないため、１品種大量製品の製造が見込めコストダウン・製品原価の低減が可能となる。更に、ストレージ装置の製品としての寿命が尽きた時、まだ使用可能な（余剰となる）ＮＶＭドライブの容量を低減できるので、廃棄する資源量も少なくでき環境に優しい製品を提供できる。
【００７９】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。
【００８０】
各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ等の記録装置、または、IＣカード、SDカード、DVD等の記録媒体に置いてもよい。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【００８１】
１：ストレージ装置、３１：運用管理端末、７０：ストレージコントローラ、１００：ＲＡＩＤグループ、１１０：容量プール、１１５：ページ（容量プール管理単位）、１２０：仮想論理ボリューム、２００：プール空き容量管理画面、Ｄ０〜Ｄｎ：ＮＶＭドライブ、９９１：保守管理サーバ
【図１】
2016046977.tif 000003
【図２】
2016046977.tif 000004
【図３】
2016046977.tif 000005
【図４】
2016046977.tif 000006
【図５】
2016046977.tif 000007
【図６】
2016046977.tif 000008
【図７】
2016046977.tif 000009
【図８】
2016046977.tif 000010
【図９】
2016046977.tif 000011
【図１０】
2016046977.tif 000012
【図１１】
2016046977.tif 000013
【図１２】
2016046977.tif 000014
【図１３】
2016046977.tif 000015
【図１４】
2016046977.tif 000016
【国際調査報告】
2016046977.tif 000017
2016046977.tif 000018