WO2016163025A1

WO2016163025A1 - データ量削減機能に関する課金額を算出する方法及び管理システム

Info

Publication number: WO2016163025A1
Application number: PCT/JP2015/061227
Authority: WO
Inventors: 堀　幸一; 哲西本; 太羽賀
Original assignee: 株式会社日立製作所
Priority date: 2015-04-10
Filing date: 2015-04-10
Publication date: 2016-10-13
Also published as: US20170359221A1

Abstract

　ストレージシステムからサービスユーザのホストシステムに論理ボリューム（ＶＯＬ）が提供される。ＶＯＬに格納されるデータに対してデータ量削減機能によりデータ量削減処理が施される。管理システムは、提供総容量（１以上のサービスユーザに提供された１以上のＶＯＬの総容量）とユーザ使用総量（１以上のＶＯＬに格納されるデータ量削減処理前の１以上のデータの総量）とのうちの少なくとも１つが、保有量（ストレージシステムがサービスプロバイダについて保有しデータが格納される記憶空間の容量の上限）を超えているか否かを判断する。その判断の結果が肯定の場合、管理システムは、第１の超過容量（ユーザ使用総量と保有量との差分）と、第２の超過容量（提供総容量と保有量との差分）と、第１及び第２の超過容量のうちの少なくとも１つに関わると定義されたサービスユーザに対応した金額とのうちの少なくとも１つに基づく課金額を算出する。

Description

データ量削減機能に関する課金額を算出する方法及び管理システム

　本発明は、概して、課金額を算出するコンピュータ技術に関する。

　近年、ストレージシステムに格納されるデータ量は増加の一途をたどっている。サービスプロバイダ（例えば、クラウドサービスのサービスプロバイダ）がストレージベンダから購入した又は借りたストレージ装置が、データが格納される記憶空間を有する。以下、その記憶空間を、「保有空間」と言い、保有空間の容量（データが格納される記憶空間の容量の上限）を、「保有量」と言う。保有空間に基づく記憶空間（例えば論理ボリューム）が、サービスプロバイダのサービスとして（又は、サービスの使用を可能にするために）、サービスユーザのホストシステムに提供される。ホストシステムが、提供された記憶空間を指定したライト要求を送信する。そのライト要求に従うデータが、指定された記憶空間の基になっている保有空間に格納される。

　保有空間は、ＨＤＤ（Hard　Disk　Drive）又はＳＳＤ（Solid　State　Drive）のような記憶デバイスに基づく空間である。サービスプロバイダは、ＨＤＤ又はＳＳＤのような記憶デバイスを購入する等によって、保有量を増やし続ける必要がある。そのため、そのコストはサービスプロバイダにとって大きな負担である。

　そこで、圧縮や重複排除のようなデータ量削減機能が注目される（例えば特許文献１）。

US8,161,211

　しかし、データ量削減機能により削減できるデータ量は、データ属性（例えばデータパターン）に依存するため、一律ではない。このため、データ量削減効果が低い（削減できたデータ量が小さい）ことがあり得る。

　また、データ量が削減されることで保有量のうちの空き容量が増えても、その空き容量が利用されないこともあり得る。そのため、増えた空き容量ベースで課金額を決定することが好ましいとは必ずしも言えないと考えられる。

　これらの場合、データ量削減機能の価格に対してサービスプロバイダにとってのメリットを見出すことは難しい。

　データ量削減機能に関してサービスプロバイダにリーズナブルな課金をすることは、コンピュータを導入したとしても困難である。なぜなら、上述したように、データ量削減機能により削減できるデータ量は一律で無いことは依然として残るためである。

　本明細書において、「サービスプロバイダにリーズナブルな課金をする」とは、少なくともサービスプロバイダにとって妥当だと考えられる課金をすることであり、その観点として、必ずしも課金額の高低である必要はなく、課金額の高低に代えて又は加えて、課金のタイミング及び課金額の算出根拠のうちの少なくとも１つがある。ストレージシステムからサービスユーザのホストシステムに論理ボリュームが提供され、論理ボリュームに格納されるデータに対してデータ量削減機能によりデータ量削減処理が施されるような環境において、以下の処理が行われる。すなわち、管理システム又はストレージシステムが、提供総容量（１以上のサービスユーザに提供された１以上の論理ボリュームの総容量）とユーザ使用総量（１以上の論理ボリュームに格納されるデータ量削減処理前の１以上のデータの総量）とのうちの少なくとも１つが、保有量（ストレージシステムがサービスプロバイダについて保有する記憶空間でありデータが格納される記憶空間の容量の上限）を超えているか否かを判断する。その判断の結果が肯定の場合、管理システム又はストレージシステムは、第１の超過容量（ユーザ使用総量と保有量との差分）と、第２の超過容量（提供総容量と保有量との差分）と、第１及び第２の超過容量のうちの少なくとも１つに関わると定義されたサービスユーザに対応した金額とのうちの少なくとも１つに基づく課金額を算出する。

　データ量削減機能に関してサービスプロバイダにリーズナブルな課金額を算出することができる。

実施形態に係る情報システムの概要の一例を示す。実施形態の概要の一例を示す。実施形態の具体例の第１の部分を示す。実施形態の具体例の第２の部分を示す。実施形態の具体例の第３の部分を示す。実施形態に係る情報システムのハードウェア構成の一例を示す。物理ストレージ装置内の共有メモリが記憶するプログラム及び情報の一例を示す。管理システム内のメモリが記憶するプログラム及び情報の一例を示す。サービス管理テーブルの構成の一例を示す。運用開始と運用開始後の定期データ収集とを含んだフローの一例を示す。貸出量追加ＧＵＩの一例を示す。貸出量追加フローの一例を示す。閾値チェックフローの概要の一例を示す。閾値チェックフローの詳細の一例を示す。閾値チェックフローの詳細の別の一例を示す。追加／マイグレーションＧＵＩの一例を示す。圧縮ＧＵＩの一例を示す。容量超過後に実使用金額に加えて超過容量金額が課金されることを示す。課金額算出フローの一例の第１の部分を示す。課金額算出フローの一例の第２の部分（超過容量金額のベースがユーザ使用総量ΣＵ_Ｕの場合）を示す。課金額算出フローの一例の第３の部分（超過容量金額のベースが貸出総量ΣＵ_Ｔの場合）を示す。算出結果ＧＵＩの第１の例を示す。契約解除（又は新規サービスユーザの追加）が生じた場合のユーザ使用量（又は貸出量）の契約順に沿った並びの一例を示す。算出結果ＧＵＩの第２の例を示す。契約解除（又は新規サービスユーザの追加）が生じた場合のユーザ使用量（又は貸出量）の並びの複数のパターンの一例を示す。算出結果ＧＵＩの第３の例を示す。複数のパターンにそれぞれ対応した複数のユーザリストの各々の一例を示す。契約中のサービスユーザの使用量Ｕ_Ｕの増加又は減少に伴う課金対象決定の一例を示す。ＶＶＯＬ（仮想ボリューム）については超過容量金額のベースにΣＵ_Ｔが採用されないことの理由の一例の説明図である。ＶＶＯＬについては超過容量金額のベースにΣＵ_Ｕが採用されることの理由の一例の説明図である。

　以下、一実施形態を説明する。

　以下の説明では、「×××テーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「×××テーブル」を「×××情報」と呼ぶことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。

　また、以下の説明では、要素の識別情報として、ＩＤ又は名前が使用されるが、それに代えて又は加えて他種の識別情報が使用されてもよい。

　また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号又は参照符号における共通番号を使用し、同種の要素を区別して説明する場合は、その要素の参照符号を使用又は参照符号に代えてその要素に割り振られたＩＤを使用することがある。

　また、以下の説明では、Ｉ／Ｏ（Input/Output）要求は、ライト要求又はリード要求であり、アクセス要求と呼ばれてもよい。

　また、以下の説明では、「記憶部」は、メモリを含んだ１以上の記憶デバイスでよい。例えば、記憶部は、主記憶デバイス（典型的には揮発性のメモリ）及び補助記憶デバイス（典型的には不揮発性の記憶デバイス）のうちの少なくとも主記憶デバイスでよい。また、記憶部は、キャッシュ領域（例えばキャッシュメモリ又はその一部領域）とバッファ領域（例えばバッファメモリ又はその一部領域）とのうちの少なくとも１つを含んでもよい。

　また、以下の説明では、「ＰＤＥＶ」は、物理的な記憶デバイスを示し、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）でよい。ＰＤＥＶは、例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive)でよい。

　また、以下の説明では、「ＲＡＩＤ」は、Redundant　Array　of　Independent　(or　Inexpensive)　Disksの略である。ＲＡＩＤグループは、複数のＰＤＥＶで構成され、そのＲＡＩＤグループに関連付けられたＲＡＩＤレベルに従いデータを記憶する。ＲＡＩＤグループは、パリティグループと呼ばれてもよい。パリティグループは、例えば、パリティを格納するＲＡＩＤグループのことでよい。

　また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central　Processing　Unit））によって実行されることで、定められた処理を、適宜に記憶部（例えばメモリ）及び／又はインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置又はシステムが行う処理としてもよい。また、プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ（例えばＣＰＵ）と記憶部を含み、記憶部はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布してよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

　また、以下の説明では、管理システムは、一以上の計算機で構成されてよい。具体的には、例えば、管理計算機が情報を表示する場合（具体的には、例えば、管理計算機が自分の表示デバイスに情報を表示する、或いは、管理計算機が表示用情報を遠隔の表示用計算機に送信する場合）、管理計算機が管理システムである。また、例えば、複数の計算機で管理計算機と同等の機能が実現されている場合は、当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機を含んでよい）が、管理システムである。管理計算機（例えば管理システム）は、表示システムを含むＩ／Ｏシステムに接続されたインターフェースデバイスと、記憶部（例えばメモリ）と、インターフェースデバイス及び記憶部に接続されたプロセッサとを有してよい。表示システムは、管理計算機が有する表示デバイスでもよいし、管理計算機に接続された表示用計算機でもよい。Ｉ／Ｏシステムは、管理計算機が有するＩ／Ｏデバイス（例えばキーボード及びポインティングデバイス、タッチパネル）でもよいし、管理計算機に接続された表示用計算機又は別の計算機でもよい。管理計算機が「表示用情報を表示する」ことは、表示システムに表示用情報を表示することであり、これは、管理計算機が有する表示デバイスに表示用情報を表示することであってもよいし、管理計算機が表示用計算機に表示用情報を送信することであってもよい（後者の場合は表示用計算機によって表示用情報が表示される）。また、管理計算機が情報を入出力するとは、管理計算機が有するＩ／Ｏデバイスとの間で情報の入出力を行うことであってもよいし、管理計算機に接続された遠隔の計算機（例えば表示用計算機）との間で情報の入出力を行うことであってもよい。情報の出力は、情報の表示であってもよい。

　また、以下の説明では、「ＶＯＬ」は、論理ボリュームの略である。サービスユーザに提供されるＶＯＬは、実体的なＶＯＬ（ＲＶＯＬ）と、仮想的なＶＯＬ（ＶＶＯＬ）とのうちのいずれでもよいが、本実施形態では、ストレージシステムは、ＲＶＯＬとＶＶＯＬの両方を提供できる。「ＲＶＯＬ」は、そのＲＶＯＬを有するストレージシステムが有する物理的な記憶部（例えば、１以上のＲＡＩＤグループ）に基づくＶＯＬである。「ＶＶＯＬ」は、典型的には、容量拡張ＶＯＬ（ＴＰＶＯＬ）である。ＴＰＶＯＬは、複数の仮想領域（仮想的な記憶領域）で構成されており容量仮想化技術（典型的にはThin　Provisioning）に従うＶＯＬである。ストレージコントローラ２１が、ホスト計算機からライト要求を受領した場合に、ライト要求が指定するアドレスが属する仮想領域（ＶＶＯＬ（ＴＰＶＯＬ）の仮想領域）に実領域（実体的な記憶領域）が割り当てられていない場合、当該仮想領域にプールから実領域を割り当て、割り当てられた実領域に、そのライト要求に付随するライト対象データを書き込む。「プール」は、複数の実領域で構成された記憶領域でよい。具体的には、例えば、プールは、１以上のプールＶＯＬの集合でよい。「プールＶＯＬ」は、プールの構成要素となるＶＯＬでよい。プールＶＯＬは、ＲＡＩＤグループに基づくＶＯＬ（ＲＶＯＬ）であってもよいし、外部のストレージ装置の記憶資源（例えばＶＯＬ）に基づく仮想的なＶＯＬであってもよい。

　図１は、実施形態に係る情報システムの概要の一例を示す。

　本実施形態では、ストレージベンダ、複数（又は１）のクラウドサービスプロバイダ（以下、ＣＳＰ）、複数（又は１）のサービスユーザが存在する。１つのＣＳＰにつき、１以上のサービスユーザが存在する。ＣＳＰは、サービスプロバイダの一例である。

　ストレージベンダは、ストレージ装置１２１（又は記憶容量）をＣＳＰに提供し（例えば販売し又は貸し出し）、ＣＳＰ（又はサービスユーザ）から指定された容量の記憶空間（例えばＶＯＬ）をサービスユーザに提供するエンティティである。ストレージベンダは、ストレージシステム１２０と管理システム１３０とを管理する。ストレージシステム１２０は、ストレージベンダにより製造された、又は、ストレージベンダによりＣＳＰに対して販売、貸出し又は使用が許可されたシステムでよい。ストレージシステム１２０は、第１の通信ネットワーク（例えばＳＡＮ（Storage　Area　Network）又はＷＡＮ（Wide　Area　Network））１６０及び第２の通信ネットワーク（例えばインターネットのようなＩＰ（Internet　Protocol）ネットワーク）１５０に接続されてよい。第１及び第２の通信ネットワーク１５０及び１６０に代えて１つの通信ネットワークが採用されてもよい。ストレージシステム１２０は、複数（又は１）のストレージ装置１２１を含む。ストレージ装置１２１は、ＣＳＰに提供される（例えば販売又は貸し出される）単位でよい。複数のストレージ装置１２１は、複数の物理的なストレージ装置であってもよいし、複数の仮想的なストレージ装置であってもよいし、１以上の物理的なストレージ装置と１以上の仮想的なストレージ装置との混在であってもよい。仮想的なストレージ装置は、物理的なストレージ装置のリソースが割り当てられたストレージＬＰＡＲ（Logical　Partitioning）でよい。本実施形態では、１つのストレージ装置１２１が複数のＣＳＰにより共有されることは無いが、それに限られないでよい。管理システム１３０は、第２の通信ネットワーク１５０に接続されてよく、また、ストレージ管理者の計算機を含んでよい。

　ＣＳＰは、ストレージ装置１２１（又は記憶容量）をストレージベンダから購入し（又は借り）、契約したサービスユーザに容量（典型的にはＶＯＬ）を貸し出す（又は販売する）クラウドサービスを提供するエンティティである。サービスユーザから要求された容量の記憶空間が、購入したストレージ装置１２１から、そのサービスユーザのホストシステム１１０に提供される。ＣＳＰが購入した（又は借りた）ストレージ装置１２１が、データが格納される記憶空間を有する。本実施形態において、その記憶空間を、「保有空間」と言い、保有空間の容量（データが格納される記憶空間の容量の上限）を、「保有量」と言う。ＣＳＰは、ＣＳＰシステム１４０を管理する。ＣＳＰシステム１４０は、ＣＳＰの計算機システム（例えば、ＣＳＰにより管理されるコンピュータ）であり、プロバイダシステムの一例である。ＣＳＰシステム１４０は、第２の通信ネットワーク１５０に接続されてよい。ＣＳＰシステム１４０は、１以上の計算機を含んでよい。その１以上の計算機は、クラウドサービスを提供するサーバと、そのサーバを管理するＣＳＰ管理者の計算機とを含んでよい。ＣＳＰシステム１４０は、ストレージシステム１２０、管理システム１３０及びホストシステム１１０のうちの少なくとも管理システム１３０と通信する。

　サービスユーザは、ＣＳＰからクラウドサービスを受ける（つまりＣＳＰから容量を借りる（又は購入する））エンティティである。サービスユーザは、ホストシステム１１０を管理する。ホストシステム１１０は、サービスユーザがＣＳＰから借りた容量の記憶空間の提供をストレージシステム１２０から受ける。その記憶空間は、例えば、ファイルシステム空間のようなＶＯＬであり、ホストシステム１１０は、その提供された記憶空間を指定したＩ／Ｏ要求を送信する。ホストシステム１１０は、１以上の計算機を含んでよい。その１以上の計算機は、提供された記憶空間を指定したＩ／Ｏ要求を送信するサーバと、そのサーバを管理するユーザ管理者の計算機とを含んでよい。

　図２は、実施形態の概要の一例を示す。

　本実施形態ではストレージ装置１２１がデータ量削減機能２１０を有する。ＣＳＰが、ストレージ装置１２１を購入する又は借りる（或いは、データ量削減機能２１０をオプションとして購入又は借りる）等により、ＣＳＰがサービスユーザに貸し出した容量を有する記憶空間を指定したライト要求に従うデータに対して、データ量削減機能２１０によるデータ量削減処理が施されることになる。

　上述したように、コンピュータを導入したとしても、データ量削減機能２１０に関してサービスプロバイダにリーズナブルな課金をすることは困難である。データ量削減機能２１０により削減できるデータ量は一律で無いことは依然として残るからである。

　そこで、本実施形態では、ＣＳＰシステム１４０及びストレージシステム１２０と通信可能な管理システム１３０に、ユーザ使用総量（ΣＵ_Ｕ）及び貸出総量（ΣＵ_Ｔ）のうちの少なくとも１つを特定するための第１の情報と、保有量（Ｔ_S）を特定するための第２の情報とをＣＳＰシステム１４０及びストレージシステム１２０のうちの少なくとも１つから受け付けるインターフェースが設けられる。ΣＵ_Ｕは、１以上のサービスユーザにそれぞれ対応した１以上のユーザ使用量（Ｕ_Ｕ）の総量である。サービスユーザに対応したＵ_Ｕは、データ量削減処理前の１以上のデータでありそのサービスユーザのホストシステム１１０から記憶空間に書き込まれる１以上のデータの量である。ΣＵ_Ｔは、１以上のサービスユーザにそれぞれ対応した１以上の貸出量（Ｕ_Ｔ）の総量である。貸出総量（ΣＵ_Ｔ）は、提供総容量の一例であり、貸出量（Ｕ_Ｔ）は、提供容量の一例である。サービスユーザに対応したＵ_Ｔは、そのサービスユーザに貸し出された容量（そのサービスユーザのホストシステム１１０に提供された記憶空間の容量）である。第１の情報は、ΣＵ_Ｕ及びΣＵ_Ｔのうちの少なくとも１つ（例えばストレージシステム１２０によって算出されたΣＵ_Ｕ及びΣＵ_Ｔのうちの少なくとも１つ）であってもよいし、ΣＵ_Ｕ及びΣＵ_Ｔのうちの少なくとも１つの算出に必要な要素（例えば、前回受信した値との差分、或いは、サービスユーザ毎のＵ_Ｕ及びＵ_Ｔのうちの少なくとも１つ）であってもよい。第２の情報は、Ｔ_Ｓであってもよいし、Ｔ_Ｓの算出に必要な要素（例えば前回受信した値との差分）であってもよい。

　管理システム１３０は、受け付けた情報を用いて、ΣＵ_Ｕ及びΣＵ_Ｔのうちの少なくとも１つが、Ｔ_Ｓを超えているか否かを判断する。その判断の結果が肯定の場合、管理システム１３０は、ΣＵ_ＵとＴ_Ｓとの差分である第１の超過容量（ΣＵ_Ｕ－Ｔ_S）と、ΣＵ_ＴとＴ_Sとの差分である第２の超過容量（ΣＵ_Ｔ－Ｔ_S）とのうちの少なくとも１つに基づく金額である超過容量金額を考慮した課金額を算出する。「超過容量金額を考慮した課金額」とは、超過容量金額それ自体であってもよいし、超過容量金額と他の何らかの金額とを含んだ課金額であってもよい。

　ＣＳＰは、サービスユーザと契約して容量を貸し出すことでサービスユーザから対価を受け取るというビジネスを行っている（なお、このビジネス形態は一例であり、容量の販売等、容量の貸出し以外の形態が採用されてもよい）。ストレージ装置１２１に格納するデータの量をデータ量削減機能２１０により削減できるため、ΣＵ_ＵがＴ_Ｓを超えてもよい。このため、ＣＳＰは、ΣＵ_ＴがＴ_Sを超えるような容量貸出しをできる。すなわち、図２に示すように、１以上のサービスユーザに貸し出される１以上の記憶空間（典型的にはＶＯＬ）の集合２２０の総容量ΣＵ_ＴがＴ_Sを超えてもよい。このように、ＣＳＰは、Ｔ_Sを増やすこと無しに、既存のサービスユーザに貸し出す容量を増やしたり、新規のサービスユーザに容量を貸し出したりできる。結果として、ＣＳＰの利益を増やすことができる。

　このような観点から、上述したように、管理システム１３０は、ΣＵ_Ｕ及びΣＵ_Ｔのうちの少なくとも１つがＴ_Ｓを超えたことを、データ量削減効果（データ量削減機能２１０の効果）でありＣＳＰが得られた利益として関連付ける。そして、管理システム１３０は、（ΣＵ_Ｕ－Ｔ_S）と（ΣＵ_Ｔ－Ｔ_S）とのうちの少なくとも１つに基づく金額である超過容量金額を含んだ課金額を算出する。

　これにより、ＣＳＰにとっては、データ量削減機能２１０の恩恵を受けた場合に、その恩恵に基づいて算出された金額をデータ量削減機能２１０の対価としてストレージベンダに支払えばよい。つまり、データ量削減機能２１０に関してＣＳＰにとってリーズナブルな課金を実現できる。また、ストレージベンダにとっては、ストレージ装置１２１が購入された時だけでなくストレージ装置１２１の運用中も継続して収入を得ることが期待できる。

　なお、リーズナブルな課金額を算出する一比較例として、データ量削減効果（削減率）を課金額のベースとすることが考えられる。しかし、データが更新されるとデータパターン（又は他のデータ属性）が変わり、結果として、データ量削減効果が変わる可能性がある。そうすると、課金額のベースとして採用するデータ量削減効果をどのタイミングで決めてよいかを決定するのが困難である。従って、本実施形態に係る課金額算出方法がより有効であると考えられる。

　また、データ量削減機能２１０に関しＣＳＰにとってリーズナブルな課金をすることは、データ量削減機能２１０の利用の促進の期待につながる。データ量削減機能２１０に関しリーズナブルな課金をすることは、１つの観点でいえば、機能を評価する技術の向上である。データ量削減機能２１０の利用の促進は、１つの観点でいえば、同一の保有量でより多くの容量を貸し出せる（より多くのデータ量を格納できる）ためクラウドサービス提供又は資源節約の促進である。従って、本実施形態によれば、機能評価技術の向上を通じてクラウドサービス提供又は資源節約という他の技術を向上することが期待できる。

　なお、課金をするタイミング、課金額の算出の根拠となる対象について、幾つかのバリエーションがあるが、それらのバリエーションは後述する。

　また、保有量Ｔ_Ｓを有する保有空間は、例えば、１以上のＰＤＥＶ（典型的にはＲＡＩＤグループ）に基づく論理記憶空間であり、その論理記憶空間に基づくＶＯＬがホストシステム１１０に提供されたり、その論理記憶空間がプールとして管理されプールに関連付けられたＶＶＯＬがホストシステム１１０に提供されたりする。Ｔ_Sを超えた容量貸出しが可能なので、サービスユーザから見れば空き容量が残っているにも関わらず、データを新たに格納できない（例えば、実使用総量（ΣＵ_Ｒ）が保有量Ｔ_Ｓに達してしまう）といったことが生じ得る（なお、ΣＵ_Ｒは、１以上のサービスユーザにそれぞれ対応した１以上の実使用量（Ｕ_Ｒ）の総量であり、サービスユーザに対応したＵ_Ｒは、データ量削減処理後の１以上のデータでありストレージシステム１２０に実際に書き込まれた１以上のデータの量である）。ＣＳＰにとって、サービスユーザがデータを書き込めなくなるというのは問題である。ＣＳＰはサービスユーザに容量を貸し出しているという前提があるため、ＣＳＰが自分のためにストレージ装置１２１を使うよりも、データを書き込める状態をサービスユーザに対して保証するという責任は大きい。このため、ΣＵ_Ｔ（又はΣＵ_Ｕ）がＴ_Ｓをどの程度超えてもよいかを判断することはＣＳＰにとって難しい。そのため、ΣＵ_Ｔ（又はΣＵ_Ｕ）がＴ_Ｓを超える貸出しが積極的に行われず、結果として、データ量削減機能２１０のメリットが十分に出ないことになり得る。

　そこで、本実施形態では、ΣＵ_ＲがＴ_Ｓに達してしまうことを回避するために、ΣＵ_Ｒに関して１以上の閾値が設けられ、１以上の閾値に基づく閾値チェック機能及び閾値対策機能も設けられる。このような閾値があるために、ＣＳＰはΣＵ_Ｔ（又はΣＵ_Ｕ）がＴ_Ｓを超えるような容量貸出しを安心して行える。これにより、データ量削減機能２１０のメリットとしてＣＳＰが得られる利益（サービスユーザから得られる金額）を増やすことができ、リーズナブルな課金をＣＳＰに対して行うことができる。閾値チェック機能及び閾値対策機能についても後述する。

　また、本実施形態では、管理システム１３０に設けられるインターフェースは、ΣＵ_Ｒを特定するための第３の情報をストレージシステム１２０から受け付けることと、第３の情報（又は第３の情報から特定されたΣＵ_Ｒ）をＣＳＰシステム１４０に提供することとのうちの少なくとも１つを行うことができる。第３の情報は、ΣＵ_Ｒ（例えばストレージシステム１２０によって算出されたΣＵ_Ｒ）であってもよいし、ΣＵ_Ｒの算出に必要な要素（例えば、前回受信した値との差分、或いは、サービスユーザ毎のＵ_Ｒ）であってもよい。ＣＳＰシステム１４０（ＣＳＰシステム１４０が含む表示デバイス）に、ΣＵ_ＲとΣＵ_Ｕ（又は、ΣＵ_ＲとΣＵ_Ｕとに基づいて算出されたデータ量削減効果）が表示される。これにより、ＣＳＰ管理者は、ΣＵ_ＲとΣＵ_Ｕとに基づくデータ量削減効果から、追加量ｂ_A（既存サービスユーザへの貸出量に追加する容量及び新規サービスユーザへの貸出量のうちの少なくとも１つを含んだ容量）を決定し易い。管理システム１３０のインターフェースは、ＣＳＰ管理者により決定された追加量ｂ_AをＣＳＰシステム１４０から受け付けてもよい。管理システム１３０は、受け付けた追加量ｂ_Aに基づいて課金額を決定できる。

　管理システム１３０の機能は、管理システム１３０以外の少なくとも１つのシステムに集中して又は分散して設けられてもよい。例えば、管理システム１３０の機能がストレージシステム１２０に設けられている場合、ＣＳＰシステム１４０とストレージシステム１２０が通信可能に接続されてもよい。また、Ｔ_S、ΣＵ_Ｔ、ΣＵ_Ｕ及びΣＵ_Ｒのうちの少なくとも１つは、ストレージシステム１２０、管理システム１３０及びＣＳＰシステム１４０のうちのいずれで算出されてもよい。例えば、管理システム１３０は、定期的に、Ｔ_S（又は前回受信した値との差分）と、サービスユーザ毎の値セット（Ｕ_Ｔ、Ｕ_Ｕ及びＵ_Ｒ）とを受信し、受信した情報を用いて、Ｔ_S、ΣＵ_Ｔ、ΣＵ_Ｕ及びΣＵ_Ｒの各々を算出してもよい。或いは、管理システム１３０は、定期的に、Ｔ_S、ΣＵ_Ｔ、ΣＵ_Ｕ及びΣＵ_Ｒの各々をストレージシステム１２０及びＣＳＰシステム１４０のうちの少なくとも１つから受信し、受信したＴ_S、ΣＵ_Ｔ、ΣＵ_Ｕ及びΣＵ_Ｒの各々を記憶してもよい。以下、説明を分かり易くするために、管理システム１３０は、Ｔ_Sを特定するための情報として、Ｔ_Sそれ自体を、ストレージシステム１２０（又はＣＳＰシステム１４０）から受信するとする。また、管理システム１３０は、ΣＵ_Ｔを特定するための情報として、ΣＵ_Ｔそれ自体と、１以上のサービスユーザにそれぞれ対応した１以上の貸出量（Ｕ_Ｔ）とを、ストレージシステム１２０（又はＣＳＰシステム１４０）から受信することとする。また、管理システム１３０は、ΣＵ_Ｕを特定するための情報として、ΣＵ_Ｕそれ自体と、１以上のサービスユーザにそれぞれ対応した１以上のユーザ使用量（Ｕ_Ｕ）とを、ストレージシステム１２０から受信することとする。また、管理システム１３０は、ΣＵ_Ｒを特定するための情報として、ΣＵ_Ｒそれ自体と、１以上のサービスユーザにそれぞれ対応した１以上の実使用量（Ｕ_Ｒ）とを、ストレージシステム１２０から受信することとする。

　図３～図５を参照して、実施形態の具体例を説明する。なお、図３～図５のグラフにおいて、横軸は、基準日（例えばＣＳＰとストレージベンダの契約日）からの経過時間（例えば単位は「月」））を示し、縦軸は、容量（例えば単位は「ＧＢ（ギガバイト）」）である。図３～図５のグラフを含んだ情報が、管理システム１３０によってＣＳＰシステム１４０に表示されてよい。また、その情報が、サービスユーザへの貸出量の入力ＵＩ（ユーザインターフェース）を含んでもよい。

　図３によれば、１ヶ月目において、Ｔ_S＝ΣＵ_Ｔ＝５００ＧＢである。つまり、Ｔ_Sの全てが１以上のサービスユーザに貸し出されている。ΣＵ_Ｕ＝１５０ＧＢであり、ΣＵ_Ｒ＝５０ＧＢである。すなわち、ΣＵ_Ｒは、ΣＵ_Ｕの１／３であり、故に、データ量削減効果は、３倍である。従って、ＣＳＰ管理者は、Ｔ_Sに対して３倍の容量である１５００ＧＢをΣＵ_Ｔの上限と試算できる。

　２ヶ月目において、ＣＳＰ管理者は、新規サービスユーザに１００ＧＢの容量を貸し出した。このため、ΣＵ_Ｔ＝５００ＧＢ＋１００ＧＢ＝６００ＧＢとなり、ΣＵ_ＴがＴ_Sを超えた。１サービスユーザが追加されても、データ量削減効果は３倍のままである。３ヶ月目までのΣＵ_Ｒの遷移によれば、ΣＵ_Ｒは、６ヶ月目でＴ_Sの６０％、８ヶ月目でＴ_Sの８０％になると、ＣＳＰ管理者は試算できる。なお、この具体例では、ΣＵ_Ｒに関する閾値として、第１の閾値Ｔｈ１と第２の閾値Ｔｈ２が管理システム１３０に設定されるとする。Ｔｈ１＜Ｔｈ２である。本実施形態では、Ｔｈ１及びＴｈ２の各々は、Ｔ_Sに対する比率であり、この具体例では、Ｔｈ１＝Ｔ_Sの６０％、Ｔｈ２＝Ｔ_Sの８０％であるとする。

　図４によれば、４ヶ月目において、ΣＵ_Ｒは、データ量削減効果（３倍）のためＴ_S未満であるが、ΣＵ_Ｕは、５１０ＧＢとなり、Ｔ_S（５００ＧＢ）を超過した。この超過分を、ＣＳＰの事業拡大分（利益分）とみなし、その超過分に基づく課金額が管理システム１３０により算出された。

　図５によれば、５ヶ月目において、４ヶ月間の傾向から、ΣＵ_Ｔが１３００ＧＢに拡大された。一方、データ量削減効果が、２．６倍に下がった。そのため、Ｔ_S（５００ＧＢ）＊データ量削減効果（２．６）＝１３００ＧＢとなり、ΣＵ_Ｔが１３００ＧＢであることは、容量枯渇が生じる（ΣＵ_Ｕが１３００ＧＢになる前にΣＵ_Ｒが５００ＧＢ（Ｔ_S）に達してしまう）可能性がある。

　６ヶ月目において、データ削減効果は更に悪化した（２．４倍に下がった）。このため、Ｔ_S（５００ＧＢ）に対してΣＵ_Ｕの上限は１２００ＧＢであるが、これは、ΣＵ_Ｔ（１３００ＧＢ）未満である。故に、容量枯渇の可能性が更に高まった。この２ヶ月間の傾向から、既に、実使用割合（Ｔ_Sに対するΣＵ_Ｒの割合）が、Ｔｈ１（Ｔ_Sの６０％）に到達した。そして、この先２ヶ月間において、実使用割合は、Ｔｈ２（Ｔ_Sの８０％）に到達すると試算される。そこで、ＣＳＰ管理者は、空き容量（書込み可能な容量）を確保する何かしらの対策が必要と判断できる。

　以上の具体例によれば、管理システム１３０が、ストレージシステム１２０及びＣＳＰシステム１４０から繰り返し（例えば定期的に）データを収集することで、複数の時点（例えば複数の月）の各々について、保有量（Ｔ_S）、ユーザ使用総量（ΣＵ_Ｕ）（１以上のサービスユーザにそれぞれ対応した１以上のユーザ使用量（Ｕ_Ｕ）の合計）、貸出総量（ΣＵ_Ｔ）（１以上のサービスユーザにそれぞれ対応した１以上の貸出量（Ｕ_Ｔ）の合計）、及び、実使用総量（ΣＵ_Ｒ）（１以上のサービスユーザにそれぞれ対応した１以上の実使用量（Ｕ_Ｒ）の合計）の各々の値を記憶する。複数の時点のΣＵ_Ｕ及びΣＵ_Ｒから、データ量削減効果の傾向がわかる。本実施形態によれば、管理システム１３０からΣＵ_Ｒ（又は１以上のＵ_Ｒ）がＣＳＰシステム１４０に送信されるので、ＣＳＰ管理者は、データ量削減効果の傾向を知ることができる。これにより、ＣＳＰ管理者は、その傾向を基に、Ｔ_Sを増やすこと無しに増やす貸出量を決定し易い。また、Ｔ_Sより大きな総容量を貸し出せるため、容量が枯渇する（ΣＵ_ＲがＴ_Sに達する）おそれがあるが、上記のようにΣＵ_Ｒの傾向がわかるので、容量枯渇の時期を予測できる。また、ΣＵ_Ｒに関する１以上の閾値の設定により、容量枯渇のおそれを検出できる。

　以下、本実施形態を詳細に説明する。

　図６は、実施形態に係る情報システムのハードウェア構成の一例を示す。

　ストレージシステム１２０は、１以上の物理ストレージ装置２０を含む。物理ストレージ装置２０は、複数のＰＤＥＶ２８、及び、それらに接続されたストレージコントローラ２１を有する。複数のＰＤＥＶ２８により１以上のＲＡＩＤグループが構成されてよい。

　ストレージコントローラ２１は、キャッシュメモリ２３、共有メモリ２５、Ｆ－Ｉ／Ｆ（フロントエンドインターフェースデバイス）２２、Ｂ－Ｉ／Ｆ（バックエンドインターフェースデバイス）２７、Ｍ－Ｉ／Ｆ（管理インターフェースデバイス）２６、及びそれらに接続されたＳ－ＣＰＵ２４を有する（「Ｓ－ＣＰＵ」は、ストレージコントローラ２１内のＣＰＵということを意味する表記である）。

　Ｆ－Ｉ／Ｆ２２は、第１の通信ネットワークを通じてホストシステム１１０に接続されるインターフェースデバイスである。Ｂ－Ｉ／Ｆ２７は、ＰＤＥＶ２８に接続されるインターフェースデバイスである。Ｍ－Ｉ／Ｆ２６は、第２の通信ネットワークを通じてＣＳＰシステム１４０及び管理システム１３０に接続されるインターフェースデバイスである。

　キャッシュメモリ２３は、ＰＤＥＶ２８に入出力されるデータを一時的に記憶する。

　共有メモリ２５は、プログラム及び情報を記憶する。例えば、共有メモリ２５は、図７に示すように、重複排除処理を行うための重複排除プログラム２１１と、圧縮処理（及び伸張処理）を行うための圧縮プログラム２１２と、その他の制御を行なうための制御プログラム２１３とを記憶してよい。これらのプログラムがＳ－ＣＰＵ２４により実行されることで発揮される機能が、データ量削減機能２１０である。しかし、それに限らず、重複排除処理や圧縮処理のようなデータ量削減処理は、プログラムがＳ－ＣＰＵ２４により実行されることで行われることに代えて又は加えて、ハードウェア回路により行われてもよいし、ストレージコントローラ２１により行われることに代えて又は加えて、ＰＤＥＶ２８により行われてもよい。例えば、ストレージコントローラ２１が、プログラムを実行することにより又はハードウェア回路により、重複排除処理を行い、ＰＤＥＶ２８が、プログラムを実行することにより又はハードウェア回路により、圧縮処理を行ってもよい。ＰＤＥＶ２８が、圧縮処理又は重複排除処理のようなデータ量削減処理を行う場合、そのＰＤＥＶ２８は、データ量削減処理後のデータ量をストレージコントローラ２１に通知し、ストレージコントローラ２１が、通知されたデータ量を基に、ＶＯＬ毎のＵ_Ｒを管理してもよい。

　また、共有メモリ２５は、ストレージシステム１２０の構成に関する情報を含んだテーブルである構成テーブル２２１を記憶してよい。構成テーブル２２１は、例えば、１以上のホストシステム１１０にそれぞれ提供される１以上のＶＯＬ（記憶空間）の各々について、ＶＯＬのＩＤ、ＶＯＬの提供先のホストシステム１１０のＩＤ、ＶＯＬの容量（貸出量Ｕ_Ｔ）、ＶＯＬのユーザ使用量Ｕ_Ｕ、ＶＯＬの実使用量Ｕ_Ｒ、及び、ＶＯＬに対応した物理領域アドレス（例えばＰＤＥＶ２８のＩＤとアドレス）を含んでよい。また、構成テーブル２２１は、データ量削減処理前後のデータ量とデータ属性（例えばデータパターン又はファイル識別子）との関係を表す情報を含んでもよい。

　Ｓ－ＣＰＵ２４は、例えば、共有メモリ２５内のコンピュータプログラムを実行することにより、ＶＯＬをホストシステム１１０に提供する、ホストシステム１１０からのＩ／Ｏ（Input/Output）要求で指定されているアドレス（例えばＶＯＬのＩＤとＬＢＡ（Logical　Block　Address））に基づくＰＤＥＶ２８を特定する、特定したＰＤＥＶ２８に対してデータのＩ／Ｏを行う等の処理を行う。また、Ｓ－ＣＰＵ２４は、ストレージ管理情報内の情報（例えばＶＯＬ毎のＩＤ、Ｕ_Ｔ、Ｕ_Ｕ及びＵ_Ｒ）を、管理システム１３０からの問い合わせに応答して（又はその問い合わせ無しに）、管理システム１３０に送信する。また、Ｓ－ＣＰＵ２４は、上述したように、重複排除処理や圧縮処理のようなデータ量削減処理を行う。Ｓ－ＣＰＵ２４は、データ量削減処理前後のデータ量とデータ属性（例えばデータパターン又はファイル識別子）との関係を表す情報を構成テーブル２２１に格納してもよい。

　管理システム１３０は、Ｉ／Ｆ（インターフェースデバイス）３３と、メモリ（記憶部の一例）３２と、それらに接続されたＭ－ＣＰＵ（プロセッサの一例）３１とを有する（「Ｍ－ＣＰＵ」は、管理システム１３０内のＣＰＵということを意味する表記である）。メモリ３２は、プログラム及び情報を記憶する。例えば、図８に示すように、メモリ３２は、管理プログラム２３１と、サービス管理テーブル２３２とを記憶する。管理プログラム２３１がＭ－ＣＰＵ３１に実行されることにより、管理システム１３０が上述及び後述の処理を行う。サービス管理テーブル２３２は、管理システム１３０が保持する管理情報に含まれる情報の一例である。サービス管理テーブル２３２は、クラウドサービスに関する情報の管理テーブルであり、ＣＳＰ毎に存在する。

　図９は、サービス管理テーブル２３２の構成の一例を示す。

　サービス管理テーブル２３２は、ＣＳＰ情報と、サービスユーザ毎のユーザ情報と、複数時点の使用状況の履歴とを含む。

　ＣＳＰ情報は、ＣＳＰに関する情報であり、例えば、ＣＳＰの名前、ＣＳＰシステム１４０との通信に必要な情報（例えばＩＰアドレス）、ＣＳＰが購入（又は借りた）ストレージ装置１２１のＩＤ、及び、課金パターンＩＤを含む（符号５０１を参照）。課金パターンＩＤは、採用されている課金パターンのＩＤである。課金パターンＩＤ「１」、「２」、「３－１」、「３－２」、「４－１」及び「４－２」のうちのいずれかのＩＤが設定されている。ＩＤ「１」は、超過容量金額のベースがΣＵ_Ｕであり、課金額算出に契約中ユーザを意識しないパターンに該当する。ＩＤ「２」は、超過容量金額のベースがΣＵ_Ｔであり、課金額算出に契約中ユーザを意識しないパターンに該当する。ＩＤ「３－１」は、超過容量金額のベースがΣＵ_Ｔであり、課金額算出に契約中ユーザを意識し、積み替えが行われないパターンに該当する。ＩＤ「３－２」は、超過容量金額のベースがΣＵ_Ｔであり、課金額算出に契約中ユーザを意識し、積み替えが行われるパターンに該当する。ＩＤ「４－１」は、超過容量金額のベースがΣＵ_Ｕであり、課金額算出に契約中ユーザを意識し、積み替えが行われないパターンに該当する。ＩＤ「４－２」は、超過容量金額のベースがΣＵ_Ｕであり、課金額算出に契約中ユーザを意識し、積み替えが行われるパターンに該当する。

　サービスユーザ毎のユーザ情報については、一のサービスユーザであるＵｓｅｒ１を例に取り説明する。Ｕｓｅｒ１のユーザ情報は、Ｕｓｅｒ１に関する情報であり、例えば、Ｕｓｅｒ１の名前、利用開始日（Ｕｓｅｒ１に初めて容量が貸し出された日（又はＵｓｅｒ１と契約が締結された日））、契約解除日（Ｕｓｅｒ１がサービスの利用契約を解除した日（又は契約解除の効力が発生した日）、課金対象フラグ（Ｕｓｅｒ１が課金対象であるか否かを示すフラグ）、ＶＯＬ　ＩＤ（Ｕｓｅｒ１のホストシステム１１０に提供されたＶＯＬのＩＤ）等を含む（符号５０２を参照）。

　複数時点の使用状況の履歴は、例えば、ストレージベンダとＣＳＰとの契約が有効になってから現在月までの各々の月での使用状況である。使用状況は、ＣＳＰについて言えば、Ｔ_S、ΣＵ_Ｔ、ΣＵ_Ｕ、ΣＵ_Ｒ、Ｔｈ１及びＴｈ２の各々の値である。Ｔｈ１及びＴｈ２の各々は、上述したように、実使用割合（（ΣＵ_Ｒ／Ｔ_S）＊１００％）と比較される閾値である。また、使用状況は、サービスユーザについて言えば、Ｔ_S、Ｕ_Ｔ、Ｕ_Ｕ、Ｕ_Ｒ、及び圧縮フラグの各々の値である。圧縮フラグは、圧縮機能（圧縮プログラム２１２の実行）が有効か否かを示すフラグである。Ｊヶ月目（Ｊは、１以上の整数）のＴ_S、ΣＵ_Ｔ、ΣＵ_Ｕ、ΣＵ_Ｒ、Ｔｈ１、Ｔｈ２、Ｕ_Ｔ、Ｕ_Ｕ、Ｕ_Ｒを、それぞれ、Ｔ_S(J)、ΣＵ_Ｔ(J)、ΣＵ_Ｕ(J)、ΣＵ_Ｒ(J)、Ｔｈ１_(J)、Ｔｈ２_(J)、Ｕ_Ｔ(J)、Ｕ_Ｕ(J)、Ｕ_Ｒ(J)と表記できる。上述した例によれば、管理システム１３０は、各種演算コマンドをストレージシステム１２０に発行し、ストレージシステム１２０から結果（Ｔ_S(J)、ΣＵ_Ｔ(J)、ΣＵ_Ｕ(J)、ΣＵ_Ｒ(J)、Ｔｈ１_(J)、Ｔｈ２_(J)、Ｕ_Ｔ(J)、Ｕ_Ｕ(J)及びＵ_Ｒ(J)）を受信し、受信した結果をサービス管理テーブル２３２における対応するカラムに登録したり、受信した結果に基づく情報を表示したりできる。しかし、それは一例であり、例えば、管理システム１３０は、サービスユーザ毎のＵ_Ｔ(J)、Ｕ_Ｕ(J)及びＵ_Ｒ(J)等を受信し、受信した情報を基にΣＵ_Ｔ(J)、ΣＵ_Ｕ(J)及びΣＵ_Ｒ(J)等を算出し、算出したΣＵ_Ｔ(J)、ΣＵ_Ｕ(J)及びΣＵ_Ｒ(J)等をサービス管理テーブル２３２における対応するカラムに登録したり、算出したΣＵ_Ｔ(J)、ΣＵ_Ｕ(J)及びΣＵ_Ｒ(J)等に基づく情報を表示したりしてもよい。なお、以下、「現在のａａａ」（「ａａａ」は、例えば、Ｔ_S、ΣＵ_Ｔ、ΣＵ_Ｕ、ΣＵ_Ｒ、Ｔｈ１、Ｔｈ２、Ｕ_Ｔ、Ｕ_Ｕ、又はＵ_Ｒ）のような表現を使用することがあるが、「ａａａ」は、サービス管理テーブル２３２における現在月（又は最新月）に対応するカラムから取得された値でもよいし、ストレージシステム１２０及びＣＳＰシステム１４０のうちの少なくとも１つから最近受信した情報が表す値でもよい。

　本実施形態では、重複排除機能はデフォルトであり（つまり常にオン（有効）であり）、圧縮機能はオプションである（つまり選択的にオン（有効）となる）。本実施形態において圧縮機能がオプションであることは、以下の少なくとも１つの利点があると考えられる。（１）ＣＳＰのクラウドサービスの提供に従い提供されたＶＯＬのリード性能の低下を抑えることができる。なぜなら、ＶＯＬに書き込まれるデータが圧縮されなければそのＶＯＬから読み出されるデータの伸長が不要となるからである。（２）実使用割合がＴｈ１及びＴｈ２のうちの少なくとも１つを超えてもＴ_Sを増やすこと無しに空き容量を増やすことが期待できる。なぜなら、１以上の非圧縮ユーザ（圧縮フラグがオフである１以上のサービスユーザ）から選択された非圧縮ユーザに対応した圧縮フラグがオンにされたことによりその選択された非圧縮ユーザに対応したＶＯＬに格納されているデータが圧縮されれば、更なるデータ量削減が期待できるからである。

　また、本実施形態では、圧縮フラグがサービスユーザ毎に設けられているので、サービスユーザ毎に圧縮フラグのオン／オフをＣＳＰ管理者が制御できる。このため、ＣＳＰは、サービスユーザに対する課金額を、そのサービスユーザの圧縮フラグがオンであるかオフであるかを基に決定することもできる。つまり、ＣＳＰのサービスユーザに対する課金額をよりリーズナブルにすることが期待でき、以って、ＣＳＰと契約するサービスユーザの増加も期待できる。また、ＣＳＰのサービスユーザに対する課金額をよりリーズナブルにすることが期待できるため、ＣＳＰが得られる利益に基づき算出される超過容量金額（ＣＳＰに対する課金額の少なくとも一部）もよりリーズナブルにすることが期待できる。なお、圧縮フラグは、本実施形態ではサービスユーザ毎に用意されるが、ＶＯＬ毎、或いは、ＶＯＬ部分（例えばＬＢＡ範囲）毎など、別の単位で用意されてもよい。

　図１０は、運用開始と運用開始後の定期データ収集とを含んだフローの一例を示す。このフローは、ＣＳＰ毎に行われる。以下、１つのＣＳＰを例に取る。なお、例としての１つのＣＳＰを指す場合、以下、「対象ＣＳＰ」と言うことがある。

　運用開始において、Ｓ６０１及びＳ６０２が行われる。

　具体的には、Ｓ６０１において、管理プログラム２３１が、サービスユーザ毎の貸出量の指定をＣＳＰシステム１４０から受信する。管理プログラム２３１は、指定された貸出容量のＶＯＬ（記憶空間）をサービスユーザのホストシステム１１０に提供することを各サービスユーザについてストレージシステム１２０に指示する。これにより、ストレージシステム１２０のうちＣＳＰにより購入されたストレージ装置１２１から、各サービスユーザのホストシステム１１０に、指定された貸出量のＶＯＬが提供される。管理プログラム２３１は、対象ＣＳＰのサービス管理テーブル２３２に、各サービスユーザについて、ユーザ情報（ユーザ名、利用開始日、契約解除日、課金対象フラグ、提供されたＶＯＬのＩＤ）を登録する。また、管理プログラム２３１は、対象ＣＳＰのサービス管理テーブル２３２のカラム（例えば「１ヶ月目」に対応したカラム）に、各サービスユーザについて、圧縮フラグとして「０」（オフ）を登録する。

　次に、Ｓ６０２において、管理プログラム２３１が、Ｔｈ１及びＴｈ２の入力を、例えばＣＳＰシステム１４０に表示したＵＩを通じて受け、入力されたＴｈ１及びＴｈ２を、対象ＣＳＰのサービス管理テーブル２３２（例えば「１ヶ月目」に対応したカラム）に登録する。Ｔｈ１及びＴｈ２は、ストレージシステム１２０に登録されていて、ＣＳＰシステム１４０に代えて、ストレージシステム１２０から入力されてもよい。

　運用開始後、定期的に、データ収集が行われる（Ｓ６０３及びＳ６０４）。すなわち、定期的に、管理プログラム２３１が、ストレージシステム１２０及びＣＳＰシステム１４０のうちの少なくとも１つから、Ｔ_S(J)、ΣＵ_Ｔ(J)、ΣＵ_Ｕ(J)、ΣＵ_Ｒ(J)、Ｔｈ１_(J)、Ｔｈ２_(J)、Ｕ_Ｔ(J)、Ｕ_Ｕ(J)及びＵ_Ｒ(J)を受信し、受信した結果を、対象ＣＳＰのサービス管理テーブル２３２における対応するカラムに登録する。

　運用開始後、ＣＳＰは、貸出量を追加できる。貸出量の追加は、既存サービスユーザへの貸出量に更なる容量を追加することと、新規サービスユーザへ容量を貸し出すこととのうちのいずれでもよい。ＣＳＰは、貸出量追加ＧＵＩ（Graphical　User　Interface）を介して貸出量追加を指示できる。

　図１１は、貸出量追加ＧＵＩの一例を示す。

　貸出量追加ＧＵＩ１１００は、管理プログラム２３１（又はＣＳＰシステム１４０）によってＣＳＰシステム１４０に表示される。貸出量追加ＧＵＩ１１００の少なくとも一部に入力された情報は管理プログラム２３１に送信され、貸出量追加ＧＵＩ１１００の少なくとも一部に表示の情報は管理プログラム２３１により出力された情報である。

　貸出量追加ＧＵＩ１１００は、ユーザ名入力ＵＩ１１０１、容量入力ＵＩ１１０２、ユーザ使用量入力ＵＩ１１０３、削減効果入力ＵＩ１１０４、予測指示ＵＩ１１０５、予測結果表示１１０６、追加実行ＵＩ１１０７及び追加キャンセルＵＩ１１０８を有する。

　ユーザ名入力ＵＩ１１０１は、追加される貸出量の提供先ユーザの名前を入力するためのＵＩ（例えばプルダウンメニュー）である。容量入力ＵＩ１１０２は、追加される貸出量（ｂ）を入力するためのＵＩ（例えばプルダウンメニュー）である。ユーザ使用量入力ＵＩ１１０３は、上記提供先ユーザのユーザ使用量の目安を入力するためのＵＩである。具体的には、例えば、ユーザ使用量入力ＵＩ１１０３には、上記追加される貸出量を使用し切るのに期待される期間（例えばｆヶ月）が入力される。削減効果入力ＵＩ１１０４は、データ量削減効果の目安を入力するためのＵＩである。データ量削減効果の目安として、例えば、倍率が入力されてもよいし、データ属性（例えばファイル識別子）が入力されてもよい。

　予測指示ＵＩ１１０５は、ＵＩ１１０２～１１０４に入力された情報に基づき今後（貸出量追加後）の実使用総量を予測することの指示である予測指示のためのＵＩ（例えばボタン）である。予測結果表示１１０６は、予測指示に応答して行われた予測の結果を表示するためのＵＩ（例えばウィンドウ）である。管理プログラム２３１は、予測指示に応答して、ＵＩ１１０２に入力された貸出量（ｂ）、ＵＩ１１０３に入力された期間（ｆ）、及び、ＵＩ１１０４に入力された情報を基に特定されたデータ量削減効果（ｋ）から、今後一定期間における実使用総量の変化（増加量）を予測し、その変化と、現在の実使用量ΣＵ_Ｒとを加算する。その結果が、今後一定期間における実使用総量の予測の結果である。なお、追加される貸出量（ｂ）を使用し切るのに期待される期間（ｆ）に代えて、単位期間（例えば１ヶ月）当たりの使用容量（ｖ）が入力されてよい。管理プログラム２３１が、単位期間当たりの使用容量（ｖ）と貸出量（ｂ）とを基に、貸出量（ｂ）を使用し切るのに期待される期間（ｆ）を算出し、算出した期間（ｆ）を基に、今後一定期間における実使用総量の変化（増加量）を予測してよい。また、サービス管理テーブル２３２には、現在のΣＵ_Ｒの内訳（例えば、対象ＣＳＰに購入されたストレージ装置１２１毎の現在の実使用量）が登録されていて、管理プログラム２３１は、ストレージ装置１２１毎の現在の実使用量を基に、ストレージ装置１２１毎に今後一定期間における実使用量を予測し予測の結果を予測結果表示１１０６に表示してもよい。各ストレージ装置１２１についての現在の第１の閾値（Ｘ_ＴＨ）及び第２の閾値（Ｙ_ＴＨ）は、それぞれ、現在のＴｈ１及びＴｈ２と同じ値でよい。Ｔｈ１及びＴｈ２の少なくとも１つは、ストレージ装置１２１毎に異なっていてよく、サービス管理テーブル２３２は、１つのＣＳＰについて、そのＣＳＰが保有するストレージ装置毎に存在してよい。Ｘ_ＴＨ及びＹ_ＴＨは、それぞれ、ストレージ装置１２１の容量に対する割合でよい。

　図１１の例によれば、ＣＳＰ管理者は、Storage2というストレージ装置１２１から貸出量（ｂ）の記憶空間を提供することが好ましいと判断できる。なお、管理プログラム２３１は、ストレージシステム１２０から、対象ＣＳＰに購入されたストレージ装置１２１毎の詳細情報（例えば装置状態）を取得し、取得した詳細情報をサービス管理テーブル２３２に登録したり、貸出量追加ＧＵＩ１１００に、各ストレージ装置１２１の詳細情報を表示したりしてもよい。例えば、Storage2について「装置リプレース中」といった状態が表示されている場合、ＣＳＰ管理者は、Storage2以外のストレージ装置１２１から容量を貸し出すことを選択することもできる。

　このように、管理プログラム２３１（或いは、ストレージシステム１２０又はＣＳＰシステム１４０）は、入力されたユーザ使用総量変化（例えば上記（ｂ）及び（ｆ）から算出される変化）と、入力されたデータ量削減効果（ｋ）（又は入力された削減効果属性から算出された（ｋ））とに基づき、将来の実使用割合とＴｈ１及びＴｈ２のうちの少なくとも１つとの関係を予測し、予測された関係を表示する。これにより、ＣＳＰ管理者は、貸出量（ｂ）を決定し易い。また、将来の実使用割合とＴｈ１及びＴｈ２のうちの少なくとも１つとの関係の予測は、ＣＳＰが購入したストレージ装置１２１毎に行われる。これにより、ＣＳＰ管理者は、貸出量（ｂ）のＶＯＬの提供元となるストレージ装置１２１を選択し易い。

　なお、貸出量追加ＧＵＩ１１００には、図３～図５に示した経過グラフ（Ｔ_S、ΣＵ_Ｔ、ΣＵ_Ｕ、ΣＵ_Ｒ、Ｔｈ１及びＴｈ２のうちの少なくともΣＵ_Ｕ及びΣＵ_Ｒの履歴を示すグラフ）又はその経過グラフの表示を指示するためのＵＩ１１２０が表示されてもよい。これにより、ＣＳＰ管理者は、貸出量（ｂ）を決定し易い。

　追加キャンセルＵＩ１１０８は、ＵＩ１１０１～１１０４に入力された情報をキャンセルするためのＵＩ（例えば「キャンセル」ボタン）である。追加実行ＵＩ１１０７は、容量入力ＵＩ１１０２に入力された容量をユーザ名入力ＵＩ１１０１に入力されたユーザに貸し出す（提供する）ことを実行するためのＵＩ（例えば「ＯＫ」ボタン）である。なお、追加実行ＵＩ１１０７が押された場合、管理プログラム２３１は、閾値対策をするか否かを問い合わせるＧＵＩ（例えばダイアログボックス）１１１０を表示する。例えば、管理プログラム２３１は、予測の結果として、基準日（例えば本日）から一定期間（１０か月）以内に実使用割合が少なくともＸ_ＴＨを超えてしまうストレージ装置を検出した場合、検出したストレージ装置のＩＤと、Ｘ_ＴＨを超えてしまうおそれのある時期とに基づく問合せメッセージ（例えば、「Ｓｔｏｒａｇｅ１では２ヶ月後にＸ_ＴＨに達することが予測されており、これを現段階で対策して、Ｘ_ＴＨ超過を先延ばししますか？」）をＧＵＩ１１１０に表示してよい。そのＧＵＩ１１１０上のＮｏボタン１１１２が押された場合（閾値対策不要を指定された場合）、管理プログラム２３１は、閾値対策フローを実行すること無しに、貸出量（ｂ）をユーザに貸し出すことを実行する。一方、ＧＵＩ１１１０上のＹｅｓボタン１１１１が押された場合（閾値対策要を指定された場合）、管理プログラム２３１は、閾値対策フローを実行した上で、貸出量（ｂ）をユーザに貸し出すことを実行する。

　図１２は、貸出量追加フローの一例を示す。

　管理プログラム２３１は、貸出量（ｂ）の入力を受け付ける（Ｓ７０１）。管理プログラム２３１は、貸出量（ｂ）と現在のΣＵ_Ｔとの合計が現在のＴ_Ｓ以下であるか否かを判断する（Ｓ７０２）。Ｓ７０２の判断結果が肯定の場合（Ｓ７０２：Ｙｅｓ）、管理プログラム２３１は、貸出量（ｂ）のＶＯＬを指定されたサービスユーザのホストシステム１１０に提供することをストレージシステム１２０に指示する（Ｓ７０８）。

　Ｓ７０２の判断結果が否定の場合（Ｓ７０２：Ｎｏ）、管理プログラム２３１は、ユーザ使用量の目安（貸出量（ｂ）を使用し切るのに期待される期間）（ｆ）を受け付け（Ｓ７０３）、また、データ量削減効果の目安（ｋ）を受け付ける（Ｓ７０４）。管理プログラム２３１は、貸出量（ｂ）と、ユーザ使用量の目安（ｆ）と、データ量削減効果の目安（ｋ）と、現在のΣＵ_Ｒとを基に、今後一定期間における実使用総量の予測の結果（グラフ）を表示する（Ｓ７０５）。

　閾値対策要の指定を受けた場合（Ｓ７０６：Ｙｅｓ）、管理プログラム２３１は、少なくとも１つの閾値対策フローを実行した上で（Ｓ７０７）、Ｓ７０８を実行する。一方、閾値対策不要の指定を受けた場合（Ｓ７０６：Ｎｏ）、管理プログラム２３１は、Ｓ７０７無しに、Ｓ７０８を実行する。

　図１３は、閾値チェックフローの概要の一例を示す。なお、閾値チェックフローは、上述した閾値チェック機能に相当し、閾値対策フローは、上述した閾値対策機能に相当する。

　閾値チェックフローは、ストレージシステム１２０内でのデータ収集が行われたことを契機にストレージシステム１２０（制御プログラム２１３）により開始されてもよいし、データ収集（図１０のＳ６０３）が行われたことを契機に管理プログラム２３１により開始されてもよいし、管理プログラム２３１がＣＳＰシステム１４０（ＣＳＰ管理者）から所定のコマンドを受信したことを契機に開始されてもよい。管理プログラム２３１（又はストレージシステム１２０）が、現在の実使用割合（現在のＴ_Ｓに対する現在のΣＵ_Ｒの割合）が現在のＴｈ１を超えたか否かを判断する（Ｓ９０１）。Ｓ９０１の判断結果が肯定の場合（Ｓ９０１：Ｙｅｓ）、管理プログラム２３１（又はストレージシステム１２０）は、閾値対策するか否かを判断する（Ｓ９０２）。この判断は、予めメモリ等に記憶されているポリシーのような情報を参照して行われてもよいし、閾値対策要／不要の指定をＣＳＰ管理者から受け付けることにより行われてもよい。Ｓ９０２の判断結果が肯定の場合（Ｓ９０２：Ｙｅｓ）、管理プログラム２３１は、少なくとも１つの閾値対策フローを実行する（Ｓ９０３）。

　図１４は、閾値チェックフローの詳細の一例を示す。

　この例によれば、ストレージシステム１２０（制御プログラム２１３）が、閾値チェックを行う。具体的には次の通りである。

　すなわち、ストレージシステム１２０が、定期的にデータ（例えば、現在のＴ_S、ΣＵ_Ｔ、ΣＵ_Ｕ、ΣＵ_Ｒ、Ｔｈ１及びＴｈ２）を収集する（Ｓ１０）。データ収集を契機に、又は、管理システム１３０（管理プログラム２３１）からの閾値チェックコマンドを契機に（Ｓ１１）、ストレージシステム１２０が、現在の実容量割合（＝（現在のΣＵ_Ｒ／現在のＴ_S）＊１００）を算出する（Ｓ１２）。なお、閾値チェックコマンドは、管理プログラム２３１により定期的に発行されてもよいし、ＣＳＰ管理者（又はストレージ管理者）からの指示に応答して発行されてもよい。

　ストレージシステム１２０が、現在の実容量割合が現在のＴｈ１未満か否かを判断する（Ｓ１３）。Ｓ１３の判断結果が肯定の場合（Ｓ１３：Ｙｅｓ）、処理が終了する。

　Ｓ１３の判断結果が否定の場合（Ｓ１３：Ｎｏ）、ストレージシステム１２０が、アラート（通知）を、管理システム１３０及びＣＳＰシステム１４０の少なくとも１つ（ここでは両方）に出す（Ｓ１４）。アラートは、管理システム１３０を通じてＣＳＰシステム１４０に送られてもよい。

　アラート（例えば容量枯渇のおそれありを意味するメッセージ）を受けた管理システム１３０が、そのアラートを表示する（Ｓ１５）。管理システム１３０は、容量枯渇回避をする場合（Ｓ１６：Ｙｅｓ）、閾値対策フローを実行する（Ｓ１９）。なお、「容量枯渇回避をする場合」とは、ストレージ管理者から容量枯渇回避の指示を受け付けた場合でもよいし、現在のＲが現在のＴｈ１以上であることが原因で発行されたアラートを受けたら容量枯渇回避を行うことを定義したポリシーがある場合でもよい。

　ＣＳＰシステム１４０でも同様の処理が行われてよい。すなわち、アラートを受けたＣＳＰシステム１４０が、そのアラートを表示する（Ｓ１７）。ＣＳＰシステム１４０は、容量枯渇回避をする場合（Ｓ１８：Ｙｅｓ）、閾値対策フローの実行を管理システム１３０に指示する。その指示に応答して、閾値対策フローが実行される。

　図１５は、閾値チェックフローの詳細の別の一例を示す。

　この例によれば、管理システム１３０（管理プログラム２３１）が、閾値チェックを行う。具体的には次の通りである。

　管理システム１３０（管理プログラム２３１）が、データ取得コマンドをストレージシステム１２０に発行する（Ｓ２１）。データ取得コマンドは、管理プログラム２３１により定期的に発行されてもよいし、ＣＳＰ管理者（又はストレージ管理者）からの指示に応答して発行されてもよい。

　ストレージシステム１２０が、データ取得コマンドに応答して、サービス管理テーブル２３２の少なくとも現在のＴ_S、ΣＵ_Ｒ及びＴｈ１（例えばテーブルの全情報）を管理システム１３０に送信する（Ｓ２２）。

　管理プログラム２３１が、現在の実容量割合Ｒを算出し（Ｓ２３）、現在のＲと現在のＴｈ１を表示する（Ｓ２４）。

　現在のＲが現在のＴｈ１以上の場合（Ｓ２５：Ｎｏ）、管理プログラム２３１が、アラート（例えば容量枯渇のおそれありを意味するメッセージ）をＣＳＰシステム１４０に表示する（Ｓ２６）。ＣＳＰシステム１４０は、容量枯渇回避をする場合（Ｓ２７：Ｙｅｓ）、閾値対策フローの実行を管理システム１３０に指示する。その指示に応答して、閾値対策フローが実行される。

　以上が、閾値チェックフローの詳細の幾つかの例である。なお、いずれの例においても、一連の処理は、ＣＳＰにより購入されたストレージ装置１２１毎に行われてもよい。その場合、図１４及び図１５の説明における「現在の実容量割合Ｒ」は、（（ストレージ装置１２１の現在の実使用総量）／（ストレージ装置１２１の容量））＊１００であってもよい。保有量Ｔ_Sは、ＣＳＰが購入した１以上のストレージ装置１２１にそれぞれ対応した１以上の容量の合計であってもよい。Ｔｈ１（及びＴｈ２）は、ストレージ装置１２１の容量に対する割合（％）であってもよい。

　次に、閾値対策フローを説明する。

　閾値対策フローとは、ストレージシステム１２０（又は指定されたストレージ装置１２１単体）の実使用割合を下げる処理のフローである。閾値対策フローとして、容量追加フロー、マイグレーションフロー、及び圧縮フローがある。

　容量追加フロー及びマイグレーションフローの少なくとも１つ（ここでは両方）では、例えば図１６に示す追加／マイグレーションＧＵＩ１４００が表示され、そのＧＵＩ１４００を通じて入力された指示に応答して、容量追加又はマイグレーションが行われる。「容量追加フロー」は、保有量Ｔ_S（ストレージ装置１２１の容量）を増やすことで実使用割合を下げるフローである。容量の追加として、例えば、いずれかの（又は指定された）ストレージ装置１２１にＰＤＥＶ２８を追加する、又はストレージ装置１２１を追加購入する等が行われる。「マイグレーションフロー」は、指定されたストレージ装置１２１から別のストレージ装置１２１にデータをマイグレーションすることにより指定されたストレージ装置１２１の実使用割合を下げるフローである。

　追加／マイグレーションＧＵＩ１４００は、管理プログラム２３１により、管理システム１３０又はＣＳＰシステム１４０に表示されてよい。従って、追加／マイグレーションＧＵＩ１４００に対する入力（ユーザ操作）は、ストレージ管理者又はＣＳＰ管理者によって行われてよい。以下、ＣＳＰ管理者及びストレージ管理者等を特に区別しない場合、単に「管理者」と言うことがある。

　図１６の例によれば、追加／マイグレーションＧＵＩ１４００には、一ストレージ装置１２１の実使用割合の数直線（インジケータ）１４０１が表示される。また、数直線１４０１上に（現在のＴｈ１に対応した位置）に、現在のＴｈ１を表すオブジェクトであるＴｈ１オブジェクト１４０２が表示される。また、数直線１４０１上に（現在のＴｈ２に対応した位置）に、現在のＴｈ２を表すオブジェクトであるＴｈ２オブジェクト１４０３が表示される。また、数直線１４０１上に（現在の実使用割合に対応した位置）に、現在の実使用割合を表すオブジェクトである実使用オブジェクト１４０４が表示される。オブジェクト１４０２～１４０４のうちの少なくとも１つは、例えばマウスドラッグ等により数直線１４０１に沿って移動可能なスライダー（ＵＩの一例）である。

　容量追加フロー及びマイグレーションフローのいずれであっても、管理者は、実使用オブジェクト１４０４の位置を変更する（又は数値を入力する）ことにより、所望の実使用割合を追加／マイグレーションＧＵＩ１４００に入力する。管理プログラム２３１は、その所望の実使用割合の入力に応答して、追加容量とマイグレーション候補とを表示する。

　追加容量の表示は、例えば次のようにして行われる。すなわち、管理プログラム２３１は、入力された実使用割合Ｒ´と、現在の保有量Ｔ_S（又はストレージ装置１２１の現在の容量）とを基に、追加しなければならない容量（ＰＤＥＶ２８又はストレージ装置１２１の容量）Ｗを算出する。算出された容量Ｗは、（ΣＵ_Ｒ／（Ｔ_Ｓ＋Ｗ））＊１００＝Ｒ´、という式に従い算出される。管理プログラム２３１は、算出した容量を表示する。容量追加が指示された場合（ＧＵＩ１４００の「追加」ボタン１４０５が管理者により押された場合）、管理プログラム２３１は、表示された容量を追加する処理を行う。ここまでが、容量追加フローである。

　マイグレーション候補の表示は、例えば次のようにして行われる。すなわち、管理プログラム２３１は、入力された実使用割合を基に、１以上のマイグレーション候補を選択し、選択されたマイグレーション候補を表示する。ここで、「マイグレーション候補」とは、データのマイグレーション元になり得るＶＯＬ又はそれに対応した対象（ここではサービスユーザ）である。本実施形態では、特に、所定値以上のデータ量削減効果（Ｕ_Ｒ／Ｕ_Ｕ）に対応したサービスユーザが「マイグレーション候補」として表示される。そのような１以上のマイグレーション候補の中から、マイグレーション候補が、管理プログラム２３１又は管理者により選択される（図１６では、チェックマークが、選択されたマイグレーション候補を意味する）。マイグレーションが指示された場合（ＧＵＩ１４００の「マイグレーション」ボタン１４０６が押された場合）、管理プログラム２３１は、選択されたマイグレーション候補に対応したデータをストレージ装置１２１（実使用割合が少なくともＴｈ１を超えているストレージ装置１２１）から別のストレージ装置１２１にマイグレーションすることをストレージシステム１２０に指示する。ここまでが、マイグレーションフローである。なお、データがストレージ装置１２１間でマイグレーションされることにより、ストレージ装置１２１の現在の実使用割合が下がる。また、マイグレーション候補がゼロ又は不足の場合（入力された実使用割合を実現できる程のマイグレーション可能なデータが無い場合）、マイグレーション候補の表示に代えて又は加えて、追加容量の表示がされてもよい。

　圧縮フローは、例えば図１７に示す圧縮ＧＵＩ１５００が表示され、そのＧＵＩ１５００を通じて入力された指示に応答して、圧縮処理が行われる。「圧縮フロー」は、圧縮されていないデータを圧縮することで実使用割合を下げるフローである。圧縮ＧＵＩ１５００は、管理プログラム２３１により、管理システム１３０又はＣＳＰシステム１４０に表示されてよい。

　図１７の例によれば、圧縮ＧＵＩ１５００には、ストレージシステム１２０の実使用割合の数直線１５０１（インジケータ）が表示される。その数直線１５０１上には、図１６と同様に、Ｔｈ１オブジェクト１５０２、Ｔｈ２オブジェクト１５０３及び実使用オブジェクト１５０４が表示される。実使用オブジェクト１５０４は、現在のΣＵ_Ｒに対応した位置に表示される。また、圧縮ＧＵＩ１５００には、圧縮フラグ「オフ」に対応したサービスユーザ（サービス管理テーブル２３２から管理プログラム２３１により特定されたサービスユーザ）のリスト１５０６が表示される。

　圧縮フローでは、例えば次の処理が行われる。すなわち、（Ｃ１）管理者が、リストからサービスユーザを選択し（チェックマークを記入し）、圧縮を指示する（「圧縮」ボタン１５０７を押す）。（Ｃ２）管理プログラム２３１が、サービス管理テーブル２３２から、選択されたサービスユーザに対応したＶＯＬを特定し、特定したＶＯＬを指定した圧縮指示をストレージシステム１２０に送信する。（Ｃ３）ストレージシステム１２０が、圧縮指示に応答して、圧縮指示で指定されているＶＯＬ内のデータを圧縮し、圧縮後のΣＵ_Ｒ（又はＶＯＬについて圧縮後のデータ量）を、管理システム１３０に返す。（Ｃ４）管理プログラム２３１が、圧縮後の実使用割合（例えば、圧縮後のΣＵ_Ｒ（回答されたΣＵ_Ｒ、又は、回答されたデータ容量を現在のΣＵ_Ｒから減算した値）に基づいて算出された実使用割合）を、圧縮ＧＵＩ１５００に表示する（例えば、実使用オブジェクト１５０４を、圧縮後の実使用割合に対応した位置に移動する）。このような（Ｃ１）～（Ｃ４）が、管理者所望の圧縮後の実使用割合が得られるまで繰り返される。なお、管理者所望の圧縮後の実使用割合が得られなければ、圧縮フローに代えて、容量追加フロー（又はマイグレーションフロー）が行われてもよい。また、「圧縮後のΣＵ_Ｒ（又はＶＯＬについて圧縮後のデータ量）」は、実際に圧縮された後の値に代えて又は加えて、圧縮したと仮定した場合の期待される値であってもよい。「圧縮したと仮定した場合の期待される値」は、例えば以下の（１）及び（２）の少なくともいずれかの方法により算出可能である。
（１）管理プログラム２３１が、入力画面（例えばＧＵＩ）を介して、ＶＯＬ（以下、この段落において「指定ＶＯＬ」）の主な用途の入力を受け付ける。管理プログラム２３１が、入力された用途と同じ用途で利用されている他のＶＯＬを特定する（例えば、ＶＯＬと用途の関係を表す管理テーブルを参照することで特定する）。管理プログラム２３１が、特定した他のＶＯＬの圧縮率を用いて、圧縮後のΣＵ_Ｒ（又は指定ＶＯＬについて圧縮後のデータ量）の予測値を算出する。「用途」の具体例としては、テキストデータ用、画像データ用、データベース用等がある。
（２）管理プログラム２３１が、圧縮実行済みのＶＯＬの圧縮率の平均値（又は、プール内又はストレージシステム内の圧縮率の平均値）を用いて、圧縮後のΣＵ_Ｒ（又は指定ＶＯＬについて圧縮後のデータ量）の予測値を算出する。

　いずれの閾値対策フローでも、実使用割合とＴｈ１及びＴｈ２のうちの少なくとも１つとの関係が表示される。また、所望の実使用割合に低減するために必要な対策処理（例えば容量追加又はマイグレーション）と、実行可能な対策処理（例えば圧縮）を実行した場合の期待される実使用割合とのうちの少なくとも一方が表示される。これにより、管理者は、実使用割合をどの程度下げるべきか、或いは実使用割合を下げるためにどのような閾値対策フローを選択すべきかを判断できる。

　容量追加フロー、マイグレーションフロー及び圧縮フローのいずれの閾値対策フローを選択するかは、例えば以下の観点から決定されてよい。すなわち、容量追加（例えばＰＤＥＶ２８の追加）は、物理的なスペースがないとできない。容量追加では、ＰＤＥＶ２８を搭載可能な筐体を新たに追加することも必要なことがあり、その場合には、設置面積も必要になる。また、マイグレーションは、マイグレーション対象のデータを格納できるだけの空き容量のある別のストレージ装置１２１が無いとできない。一方、圧縮は、ストレージ装置１２１内で行われるので、通常、物理的なスペース、設置面積又は別のストレージ装置１２１が必要になることは無い。このため、まずは圧縮で実使用割合を減らし、その後、将来の閾値超過に備えて（実使用割合が少なくともＴｈ１を超えることに備えて）、ＰＤＥＶ２８又はストレージ装置１２１の追加の検討を行うことができる。なお、圧縮には様々な圧縮方式（アルゴリズム）があり、圧縮率の低い圧縮方式が優先的に採用されてもよい。また、データ属性（例えばデータパターン）により圧縮率の高低が異なるので、管理プログラム２３１は、データ属性毎に、圧縮率の高い圧縮方式を自動学習してもよい（例えば、データ属性、圧縮率、及び、使用した圧縮方式の組の履歴を蓄積し、その履歴から、各データ属性について、圧縮率が最も高い圧縮方式を選択してもよい）。

　以上が、閾値チェックとその対策の説明である。

　次に、課金額算出処理を説明する。なお、上記の説明では、ＣＳＰはストレージ装置１２１を購入し、その後、ΣＵ_Ｕ及びΣＵ_Ｔのうちの少なくとも１つがＴ_Ｓを超えている場合には、超過容量金額が課金される。以下の説明では、ＣＳＰは無償でストレージ装置１２１を購入し、そのため、図１８に示すように、ストレージ装置１２１購入分の課金額が、実使用総量ΣＵ_Ｒに基づいて算出されることとする。以下、ΣＵ_Ｒに基づいて算出された金額を、「実使用金額」と言うことがある。そして、ΣＵ_Ｕ及びΣＵ_Ｔのうちの少なくとも１つがＴ_Ｓを超えている場合には、実使用金額と超過容量金額の両方が課金されることとする。実使用金額及び超過容量金額のうちの少なくとも１つが、ビットコストＢ_Ｃ（単位容量当たりの価格）に基づいて算出されるとする。Ｂ_Ｃは、ＣＳＰとストレージベンダ間の契約等に基づいて決められてよく、サービスユーザ毎に異なっていてもよいし、ＣＳＰの全てのサービスユーザについて同じ値であってもよい。前者の場合、例えば、サービスユーザ毎のユーザ情報（サービス管理テーブル２３２に登録されるユーザ情報）に、そのサービスユーザに対応したビットコスト（Ｂ_ＣＵ）が含まれてよく（この場合、Ｂ_Ｃは、１以上のＢ_ＣＵの平均値等でよい）。後者の場合、サービス管理テーブル２３２に登録されるＣＳＰ情報に、Ｂ_Ｃが含まれてよい。Ｂ_Ｃは、単価に影響する一要素の一例でよい。なお、ストレージ装置１２１が有償で購入された場合は、実使用金額の算出はスキップされてもよいし、或いは、実使用金額が算出されるとしてもその金額はストレージ装置１２１が無償である場合に比べて低額であってもよい。これは、ＣＳＰとストレージベンダ間の契約等に基づいて柔軟に決められてよい。

　また、上記の説明では、ΣＵ_Ｕ及びΣＵ_Ｔのうちの少なくとも１つがＴ_Ｓを超えた場合に超過容量金額が算出されるが、以下の説明では、ΣＵ_Ｕ及びΣＵ_ＴのどちらがＴ_Ｓと比較されるか（超過容量金額についての課金タイミングを、ΣＵ_Ｕ及びΣＵ_ＴのどちらがＴ_Ｓを超えたときとするか）は、ＣＳＰとストレージベンダ間の契約に基づいて予め決められているとする。

　課金額は、繰り返し（例えば定期的に）算出される。本実施形態では、課金額算出が毎月行われる。そして、Ｊヶ月目の課金額算出で使用されるＴ_S(J)、ΣＵ_Ｒ(J)、ΣＵ_Ｔ(J)及びΣＵ_Ｕ(J))の各々は、Ｊヶ月目に属する期間における一時点での値であってもよいし、Ｊヶ月目に属する期間における複数の時点にそれぞれ対応した複数の値を基に決定された値（例えば最大値、最小値又は平均値）でもよい。

　図１９～図２１は、課金額算出フローの一例を示す。課金額算出フローは、例えば、毎月所定日の所定時刻に開始される。以下、Ｊヶ月目に開始された課金額算出フローを例に取る。

　管理プログラム２３１が、使用状況を取得する（Ｓ１７０１）。使用状況の取得とは、Ｔ_S(J)、ΣＵ_Ｒ(J)、ΣＵ_Ｔ(J)及びΣＵ_Ｕ(J)の取得である。これらの値は、サービス管理テーブル２３２から取得される（或いは、ストレージシステム１２０及びＣＳＰシステム１４０のうちの少なくとも１つから取得され、それらの値がサービス管理テーブル２３２に登録されてもよい）。

　管理プログラム２３１は、超過容量金額のベースがΣＵ_ＴであるかΣＵ_Ｕであるかを判断する（Ｓ１７０２）。別の言い方をすれば、管理プログラム２３１は、課金タイミングが、「ΣＵ_Ｔ（Ｊ）がＴ_Ｓ（Ｊ）を超えたこと」であるか、或いは、「ΣＵ_Ｕ（Ｊ）がＴ_Ｓ（Ｊ）を超えたこと」であるかを判断する。例えば、サービス管理テーブル２３２内のＣＳＰ情報中の課金パターンＩＤの値を基に、Ｓ１７０２の判断が行われる。

　超過容量金額のベースがΣＵ_Ｕの場合（課金パターンＩＤが「１」、「４－１」又は「４－２」の場合）（Ｓ１７０２：Ｎｏ）、図２０の処理が行われる。超過容量金額のベースがΣＵ_Ｔの場合（課金パターンＩＤが「２」、「３－１」又は「３－２」の場合）（Ｓ１７０２：Ｙｅｓ）、図２１の処理が行われる。

　超過容量金額のベースをΣＵ_ＴとするかΣＵ_Ｕとするかは、例えば以下の観点に基づいて決定されてよい。
（観点１）超過容量金額のベースがΣＵ_Ｔの場合、ＣＳＰに対する超過容量金額は、超過容量金額のベースがΣＵ_Ｕであることに比べて高額になる傾向にある。なぜなら、典型的には、ΣＵ_Ｔ（Ｊ）はΣＵ_Ｕ（Ｊ）より大きく、故に、（ΣＵ_Ｔ（Ｊ）－Ｔ_Ｓ（Ｊ））は、（ΣＵ_Ｔ（Ｊ）－Ｔ_Ｓ（Ｊ））より大きくなるからである（ΣＵ_Ｔ＝ΣＵ_Ｕになることもある）。このため、超過容量金額のベースがΣＵ_Ｕの場合、ＣＳＰに対する超過容量金額は、超過容量金額のベースがΣＵ_Ｔであることに比べて低額になる傾向にある。
（観点２）超過容量金額のベースがΣＵ_Ｔの場合、ＣＳＰは、超過容量金額が課金されるタイミングがわかる。なぜなら、貸し出される容量は、ＣＳＰが決める容量であり、故に、いつΣＵ_Ｔ（Ｊ）がＴ_Ｓ（Ｊ）を超えたかをＣＳＰはわかるからである。一方、超過容量金額のベースがΣＵ_Ｕの場合、ＣＳＰは、超過容量金額が課金されるタイミングがわからない（予測しづらい）。なぜなら、ΣＵ_Ｕ（Ｊ）は、各サービスユーザが格納するデータの量によって決まり、いつΣＵ_Ｕ（Ｊ）がＴ_Ｓ（Ｊ）を超えるかをＣＳＰはわからない（予測しづらい）からである。
（観点３）１以上のサービスユーザに提供される１以上のＶＯＬに、１つでもＶＶＯＬが含まれるのであれば、少なくともＶＶＯＬについて、超過容量金額のベースは、ΣＵ_Ｕであり、ΣＵ_Ｔは採用されない。なぜなら、１つのプールについて、提供可能な１以上のＶＶＯＬの総容量は、最大予約量（プールの容量（Ｐ_Ｓ）と最大予約率（例えば、１００％より大きな値（％））との積）以下であればよく、データ削減効果に依存しないためである。具体的には、例えば図２９に示すように、データ削減効果がゼロ（無し）でも、プール容量を超えた容量を貸し出すことができるためである。別の言い方をすれば、例えば図３０に示すように、Ｐ_Ｓを超えたΣＵ_Ｕがデータ削減機能によりＰ_Ｓ以下の実使用総量（ΣＵ_Ｒ）とされた場合に、データ削減機能の効果が明確だからである。なお、少なくともＶＶＯＬについて、保有量Ｔ_Ｓは、プールの容量（Ｐ_Ｓ）である。複数のプール（例えば、プール１、プール２、…）がある場合、プール容量は、プール毎に存在する（Ｐ１_Ｓ、Ｐ２_Ｓ、…）。ＶＶＯＬにプールが関連付けられており、ＶＶＯＬの仮想領域には、そのＶＶＯＬが関連付けられているプールから実領域が割り当てられるようになっていてよい。

　図２０は、超過容量金額のベースがΣＵ_Ｕの場合に行われる処理のフローの一例を示す。

　管理プログラム２３１が、まず、ΣＵ_Ｒ（Ｊ）に基づいて実使用金額を算出する（Ｓ２２０１）。実使用金額は、例えば、Ｂ_Ｃ＊（ΣＵ_Ｒ（Ｊ）－ΣＵ_{Ｒ（Ｊ－１）}）であり、０以上である。つまり、Ｊヶ月目の実使用金額は、先月までの実使用総量と今月（Ｊヶ月目）の実使用総量との差分と、ビットコストとに基づいて算出される。実使用金額は、他の方法で算出されてもよい。例えば、実使用金額として、毎月、Ｂ_Ｃ＊ΣＵ_Ｒ（Ｊ）が算出されてもよい。

　管理プログラム２３１が、超過容量金額の算出にユーザ順序（契約中ユーザの並び順）を考慮するか否かを判断する（Ｓ２２０３）。この判断は、例えば、サービス管理テーブル２３２内のＣＳＰ情報中の課金パターンＩＤの値を基に行われる。

　Ｓ２２０３の判断結果が否定の場合（課金パターンＩＤが「１」の場合）（Ｓ２２０３：Ｎｏ）、管理プログラム２３１が、ΣＵ_Ｕ（Ｊ）がＴ_Ｓ（Ｊ）を超えているか否かを判断する（Ｓ２２０４）。Ｓ２２０４の判断結果が肯定の場合（Ｓ２２０４：Ｙｅｓ）、管理プログラム２３１は、以下の処理（Ｓ２２０５－１）～（Ｓ２２０５－２）のうちの少なくとも１つを行う（Ｓ２２０５）。
（Ｓ２２０５－１）管理プログラム２３１は、超過容量金額を算出する。超過容量金額は、ΣＵ_Ｕ（Ｊ）－Ｔ_Ｓ（Ｊ）に基づく値（例えば、（ΣＵ_Ｕ（Ｊ）－Ｔ_Ｓ（Ｊ））とＢ_Ｃとに基づく値）である。具体的には、例えば、超過容量金額は、（ΣＵ_Ｕ（Ｊ）－Ｔ_Ｓ（Ｊ））＊Ｂ_Ｃ＊Ｎ_Ｐである。Ｎ_Ｐは、課金率であり、例えば、０＜Ｎ_Ｐ＜１でよい。ΣＵ_Ｕ（Ｊ）は、契約中のサービスユーザのＵ_Ｕ（Ｊ）の合計である。
（Ｓ２２０５－２）管理プログラム２３１は、算出された実使用金額及び超過容量金額を用いて最終的な課金額を算出し、その算出結果を示す算出結果ＧＵＩ２４００を表示する。図２２に、表示される算出結果ＧＵＩ２４００の一例を示す。この算出結果ＧＵＩ２４００が示す算出結果は、課金額合計、その内訳（例えば、実使用金額、超過容量金額）、課金額算出に使用された要素（例えば、Ｔ_S(J)、ΣＵ_Ｒ(J)、ΣＵ_Ｕ(J)、Ｂ_Ｃ及びＮ_Ｐのうちの少なくとも１つ）を含む。ＧＵＩ上の「レポート」ボタンが押された場合、管理プログラム２３１が、算出結果ＧＵＩ２４００が表示する課金額の請求書発行のための処理を行ったり、算出結果ＧＵＩ２４００の表示内容を記載したレポートを印刷エンジン又は別の計算機等に送信したりしてよい。或いは、管理プログラム２３１は、算出結果ＧＵＩ２４００の表示内容を記載したレポートをＣＳＰに対して発行し、ＣＳＰが、そのレポートの内容で支払う旨の宣言をストレージベンダに対して行なってもよい。

　Ｓ２２０３の判断結果が肯定の場合（課金パターンＩＤが「４－１」又は「４－２」の場合）（Ｓ２２０３：Ｙｅｓ）、管理プログラム２３１が、積み替えを行うか否かを判断する（Ｓ２２１３）。「積み替え」とは、Ｕ_Ｕ（Ｊ）の並び順を変更することである。デフォルトは、その並び順は、ユーザ情報内の利用開始日が古い順（契約順）である。

　Ｓ２２１３の判断結果が否定の場合（課金パターンＩＤが「４－１」の場合）（Ｓ２２１３：Ｎｏ）、つまり、積み替えがされない場合、管理プログラム２３１は、以下の処理（Ｓ２２１４－１）～（Ｓ２２１４－５）のうちの少なくとも１つを行う（Ｓ２２１４）。
（Ｓ２２１４－１）管理プログラム２３１は、契約中のサービスユーザに対応したＵ_Ｕ（Ｊ）を、契約順に並べる。具体的には、例えば、管理プログラム２３１は、サービスユーザ毎に、現在時刻と、そのサービスユーザに対応したユーザ情報内の利用開始日及び契約解除日とから、そのサービスユーザが契約中（契約後契約解除されていない）か否かを判断し、契約中と判断されたサービスユーザについて、Ｕ_Ｕ（Ｊ）を、契約順に並べる。
（Ｓ２２１４－２）管理プログラム２３１は、課金対象フラグを更新する。管理プログラム２３１は、ΣＵ_Ｕ（Ｊ）＞Ｔ_Ｓ（Ｊ）か否かを判断し、図２８に例示するように、Month(J)においてＴ_Ｓ（Ｊ）を超えた部分に対応するサービスユーザの課金対象フラグのみを「オン」にする。「Ｔ_Ｓ（Ｊ）を超えた部分に対応するサービスユーザ」とは、Ｔ_Ｓ（Ｊ）を超えた部分の少なくとも一部を含んだＵ_Ｕ（Ｊ）に対応するサービスユーザである。例えば、図２８のMonth(J)の状態では、白色の円を含んだボックスに対応するＵｓｅｒ１とＵｓｅｒ２が、課金対象とされるサービスユーザである。尚、月が、Month(J)からMonth(J+1)に変化した時に、Ｔ_Ｓ（Ｊ）を超えなくなったサービスユーザの課金対象フラグは「オフ」にされる。
（Ｓ２２１４－３）管理プログラム２３１は、課金対象フラグ「オン」のサービスユーザのリストを表示する。リストは、各サービスユーザのユーザ情報のうちの少なくとも一部（例えばユーザ名）を含む。リストでは、サービスユーザが契約順に並んでいる。
（Ｓ２２１４－４）管理プログラム２３１は、超過容量金額を算出する。超過容量金額は、ΣＵ_Ｕ（Ｊ）－Ｔ_Ｓ（Ｊ）に基づく値（例えば、（ΣＵ_Ｕ（Ｊ）－Ｔ_Ｓ（Ｊ））とＢ_Ｃ´とに基づく値）である。具体的には、例えば、超過容量金額は、（ΣＵ_Ｕ（Ｊ）－Ｔ_Ｓ（Ｊ））＊Ｂ_Ｃ´＊Ｎ_Ｐである。ただし、Ｂ_Ｃ´は、ΣＵ_Ｕ（Ｊ）のうち、Ｔ_Ｓ（Ｊ）を超えた部分に対応する１以上のサービスユーザにそれぞれ対応した１以上のビットコスト（Ｂ_ＣＵ）に基づく値（例えば平均値）である（（Ｂ_Ｃ´＝Ｂ_Ｃでもよい）。図２３によれば、契約解除が生じる前は、Ｔ_Ｓ（Ｊ）を超えた部分に対応するサービスユーザは、Ｕｓｅｒ１及びＵｓｅｒ２であったが、契約解除が生じた後の（Ｓ２２１４－１）及び（Ｓ２２１４－２）の結果、Ｔ_Ｓ（Ｊ）を超えた部分に対応するサービスユーザは、Ｕｓｅｒ１のみとなった。図２３（及び後の図２５）では、白色の円を含んだボックスに対応するサービスユーザが、課金対象とされるサービスユーザである。なお、図２３の説明では、契約解除を例に取ったが、契約解除に代えて又は加えて、新規契約（新規サービスユーザの追加）があってもよいし、契約中のサービスユーザの使用量Ｕ_Ｕの増加又は減少があってもよい（例えば図２８）。
（Ｓ２２１４－５）管理プログラム２３１は、算出された実使用金額及び超過容量金額を用いて最終的な課金額を算出し、その算出結果を示す算出結果ＧＵＩ２６００を表示する。図２４に、表示される算出結果ＧＵＩ２６００の一例を示す。図２２との相違点は、表示されるビットコストが、上述のＢ_Ｃ´になり得る点でよい。Ｔ_Ｓ（Ｊ）を超えた部分に対応するサービスユーザのユーザ名等も、算出結果ＧＵＩ２６００に表示されてよい。

　Ｓ２２１３の判断結果が肯定の場合（課金パターンＩＤが「４－２」の場合）（Ｓ２２１３：Ｙｅｓ）、つまり、積み替えがされる場合、管理プログラム２３１は、全てにサービスユーザの課金対象フラグを「オフ」にする（Ｓ２２１２）。そして、管理プログラム２３１は、以下の処理（Ｓ２２１５－１）～（Ｓ２２１５－３）のうちの少なくとも１つを行う（Ｓ２２１５）。
（Ｓ２２１５－１）管理プログラム２３１は、ΣＵ_Ｕ（Ｊ）＞Ｔ_Ｓ（Ｊ）か否かを判断する。
（Ｓ２２１５－２）Ｓ２２１５－１の判断結果が肯定の場合、管理プログラム２３１は、契約中ユーザのＵ_Ｕ（Ｊ）の積み替え（並び替え）を行う。これにより、典型的には、複数のパターン、すなわち、複数通りの並び（Ｕ_Ｕ（Ｊ）の並び）ができる。図２５の例によれば、４つのパターン２７００－１～２７００－４ができる。管理プログラム２３１は、パターン毎に、課金対象フラグを更新する（具体的には、Ｔ_Ｓ（Ｊ）を超えた部分に対応するサービスユーザの課金対象フラグのみを「オン」にする）。この結果、例えばパターン２７００－３によれば、課金対象ユーザはＵｓｅｒ３のみである。また、管理プログラム２３１は、パターン毎に、超過容量金額を算出し、算出された実使用金額及び超過容量金額を用いて最終的な課金額を算出する。超過容量金額は、ΣＵ_Ｕ（Ｊ）－Ｔ_Ｓ（Ｊ）に基づく値、具体的には、例えば、超過容量金額は、（ΣＵ_Ｕ（Ｊ）－Ｔ_Ｓ（Ｊ））＊Ｑ＊Ｎ_Ｐである。Ｑは、１以上の課金対象ユーザにそれぞれ対応した１以上のビットコスト（Ｂ_ＣＵ）に基づく値（例えば平均値）である（Ｑ＝Ｂ_Ｃでもよい）。なお、Ｕ_Ｕ（Ｊ）の積み替え（並び替え）は、図２０のフローが示すように、契約解除に代えて又は加えて、新規サービスユーザの追加があった場合にも行われる。
（Ｓ２２１５－３）管理プログラム２３１は、課金額算出結果を示す算出結果ＧＵＩ２８００を表示する。図２６に、表示される算出結果ＧＵＩ２８００の一例を示す。図２４との相違点は、課金対象ユーザのＵＩ２８０１が設けられており、そのＵＩ２８０１を操作することで、図２７に示すように、パターン毎のユーザリストが管理プログラム２３１により表示される点である。図２７の例では、表示されているユーザリストは、１つの表示対象パターン「Ｃａｓｅ１」に対応するユーザリスト２９００－１であり、切替えボタン２９０１又は２９０２が押されると、表示対象パターンが切り替わる（全てのパターンのユーザリストが一ＧＵＩに表示されてもよい）。パターン毎のユーザリスト（２９００－１、２９００－２、２９００－３、…）では、そのパターンに対応した並び順に従ってＵ_Ｕ（Ｊ）が並んでおり、そのリストにおいて、課金対象ユーザの情報（例えばユーザ名を含んだ行）が強調表示されている。各ユーザリストには、各サービスユーザのＢ_ＣＵも表示されてもよい。算出結果ＧＵＩ２８００（図２２、図２４及び図２６の少なくとも１つ）、又は、パターン毎のユーザリストには、算出された課金額の根拠が表示される。根拠は、ストレージベンダとＣＳＰ間の契約に従う情報（例えばビットコスト（Ｂ_Ｃ））と、ＣＳＰとサービスユーザ間の契約に従う情報（例えばサービスユーザに対応したビットコスト（Ｂ_ＣＵ））とのうちの少なくとも一方であってよい。これにより、ＣＳＰ管理者は、課金額のチェックに際して、ＣＳＰとストレージベンダ又はサービスユーザ間の契約内容の一部をチェックできる。管理プログラム２３１は、複数のパターンの中から選択されたパターンに対応した課金額等を最終的に算出結果ＧＵＩ２８００に表示する。選択されたパターンは、ＣＳＰ管理者により手動で選択されたパターンでもよいし、管理プログラム２３１により自動で選択されたパターンでもよい。選択されたパターンは、複数のパターンにそれぞれ対応した複数の課金額のうち最も低い課金額に対応したパターンでよい。これにより、ＣＳＰにとって最もリーズナブルな課金がされることになると考えられる。なお、パターンに対応した課金額の高低は、サービスユーザ（Ｕ_Ｕ（Ｊ））の並び順だけでなく、単価（サービスユーザに対応したビットコスト（Ｂ_ＣＵ））に依存する。単価は、サービスユーザに対応したビットコスト（Ｂ_ＣＵ）に代えて又は加えて、サービスユーザの優先度等に依存してもよい。

　図２１は、超過容量金額のベースがΣＵ_Ｔの場合に行われる処理のフローの一例を示す。

　図２１のフローは、図２０のフローと実質的に同じである。具体的には、図２１のフローの説明は、図２０のフローの説明における「ユーザ使用総量（ΣＵ_Ｕ（Ｊ））」を「貸出総量（ΣＵ_Ｔ（Ｊ））」に読み替えたものに相当する。従って、図２１のＳ２３０１、Ｓ２３０３～Ｓ２３０５は、図２０のＳ２２０１、Ｓ２２０３～Ｓ２２０５にそれぞれ対応し、図２１のＳ２３１２～Ｓ２３１５は、図２０のＳ２２１２～Ｓ２２１５にそれぞれ対応する。但し、下記の点で相違がある。
（相違１）少なくともＶＶＯＬについて、超過容量金額のベースは、ΣＵ_Ｕであり、ΣＵ_Ｔは採用されない。
（相違２）Ｓ２２１４－２に対応するＳ２３１４－２は、例えば以下の通りである。すなわち、管理プログラム２３１は、ΣＵ_Ｔ（Ｊ）＞Ｔ_Ｓ（Ｊ）か否かを判断し、Ｔ_Ｓ（Ｊ）を超えた部分に対応するサービスユーザの課金対象フラグのみを「オン」にする。そして、月が変わって、課金対象フラグ「オン」に対応したサービスユーザのＵ_Ｔの全体が、Ｔ_Ｓ（Ｊ）を超えない部分に移動したとしても、課金対象フラグは「オン」に維持される（「オフ」にされてもよい）。Ｔ_Ｓ（Ｊ）を超えなくなったサービスユーザの課金対象フラグが「オン」のままとされることは、例えば次の観点に従う。すなわち、一旦ΣＵ_Ｔ（Ｊ）＞Ｔ_Ｓ（Ｊ）となったということは、ＣＳＰはデータ量削減機能２１０のメリットを受けた（ＣＳＰのビジネス拡大の１つの結果である）ことになる。このようなメリットを受けた場合には、以後のΣＵ_Ｔの変化に関わらず、Ｔ_Ｓ（Ｊ）を超えた部分に対応するサービスユーザを、データ量削減機能２１０によりＣＳＰが受けたメリットに基づく超過容量金額としての一要素とすることが維持される。

　上述したように、少なくともＶＶＯＬについて、超過容量金額のベースは、ΣＵ_Ｕであり、ΣＵ_Ｔは採用されない。ＣＳＰがサービスユーザに対して提供するＶＯＬがＶＶＯＬのみの場合、そのＣＳＰについて、例えば、図１０（データ収集）において、ΣＵ_Ｔは収集されないでよい。また、ＣＳＰがサービスユーザに対して提供するＶＯＬがＶＶＯＬのみの場合、図９のサービス管理テーブルでは、保有量（Ｔ_Ｓ（Ｊ））の一例としてプール毎のプール容量（Ｐ_Ｓ（Ｊ））が採用されて、貸出総量及び貸出量のエントリが無くて、課金パターンＩＤはΣＵ_Ｕに対応したＩＤのみ（「１」、「４－１」又は「４－２」）でよい。ＣＳＰがサービスユーザに対して提供するＶＯＬがＲＶＯＬとＶＶＯＬの両方の場合、そのＣＳＰについて、ＲＶＯＬ用のサービス管理テーブル（例えば図９のテーブル）と、ＶＶＯＬ用のサービス管理テーブル（例えば、図９のテーブルの変更版（例えば保有量をプール容量に変更））が用意されてもよいし、１つのサービス管理テーブルにおいて、保有量とその内訳（例えば、保有量に対するプール容量の割合））が管理されてもよい。

　以上、実施形態を説明したが、本発明は、この実施形態に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

　また、例えば、管理プログラム２３１は、ＣＳＰ管理者のニーズを受け付けて、選択可能な課金パターンを提示し、提示した課金パターンの選択をＣＳＰ管理者から受け付けてもよい。具体的には、例えば、課金パターンＩＤとして、上述したように、「１」、「２」、「３－１」、「３－２」、「４－１」及び「４－２」があるが、管理プログラム２３１は、ニーズとして「ＶＶＯＬの提供」を受け付けた場合、少なくともＶＶＯＬについて、貸出総量ΣＵ_Ｔをベースとした課金パターンＩＤ「２」、「３－１」及び「３－２」を、選択不可能とし、選択可能な課金パターンＩＤとして、「１」「４－１」及び「４－２」のみを提示してもよい。

１１０：ホストシステム、１２０：ストレージシステム、１３０：管理システム、１４０：ＣＳＰ（クラウドサービスプロバイダ）システム

Claims

　サービスプロバイダのサービスとして又はサービスの使用のためにストレージシステムからサービスユーザのホストシステムに論理ボリュームが提供され、その論理ボリュームに格納されるデータに対してデータ量削減機能によりデータ量削減処理が施される環境におけるサービスプロバイダへの課金額を算出する方法であって、
　（Ａ）第１の情報と第２の情報とを、プロバイダシステムと前記ストレージシステムとのうちの少なくとも１つから受信し、
　　　　　前記第１の情報は、提供総容量とユーザ使用総量とのうちの少なくとも１つを特定するための情報であり、
　　　　　前記提供総容量は、１以上のサービスユーザに提供された１以上の論理ボリュームの総容量であり、
　　　　　前記ユーザ使用総量は、前記１以上の論理ボリュームに格納されるデータ量削減処理前の１以上のデータの総量であり、
　　　　　前記第２の情報は、保有量を特定するための情報であり、
　　　　　前記保有量は、前記ストレージシステムが前記サービスプロバイダについて保有する記憶空間でありデータが格納される記憶空間の容量の上限であり、
　　　　　前記プロバイダシステムは、前記サービスプロバイダの計算機システムであり、
　（Ｂ）前記受信した第１及び第２情報を基に、前記ユーザ使用総量及び前記提供総容量のうちの少なくとも１つが、前記保有量を超えているか否かを判断し、
　（Ｃ）（Ｂ）の判断の結果が肯定の場合、前記ユーザ使用総量と前記保有量との差分である第１の超過容量と、前記提供総容量と前記保有量との差分である第２の超過容量と、前記第１及び第２の超過容量のうちの少なくとも１つに関わると定義されたサービスユーザに対応した金額とのうちの少なくとも１つに基づく課金額を算出する、
方法。
　（Ｄ）複数の課金方式から選択された課金方式とサービスプロバイダとを関連付けた第３の情報を参照することにより、前記サービスプロバイダについて選択されている課金方式を特定し、
　（Ｄ）において特定された課金方式が、ユーザ使用総量ベースを含む場合、（Ｂ）において前記ユーザ使用総量を前記保有量と比較し、（Ｃ）において前記第１の超過容量と前記第１の超過容量に関わると定義されたサービスユーザに対応した金額とのうちの少なくとも１つに基づき課金額を算出し、
　（Ｄ）において特定された課金方式が、提供総容量ベースを含む場合、（Ｂ）において前記提供総容量を前記保有量と比較し、（Ｃ）において前記第２の超過容量と前記第２の超過容量に関わると定義されたサービスユーザに対応した金額とのうちの少なくとも１つに基づき課金額を算出する、
請求項１記載の方法。
　（Ｄ）において特定された課金方式が、提供総容量ベースであることと、契約中サービスユーザの並び順を固定とすることとを含む場合、それぞれの一連の処理において、
　　（Ｂ）の判断結果が肯定の場合、前記第２の超過容量に関わると定義されたサービスユーザを、課金対象ユーザとして管理し、
　　（Ｂ）の判断結果が否定であっても、課金対象ユーザとして管理されているサービスユーザがいる場合、そのサービスユーザに関しての金額を含んだ課金額を算出する、
請求項２記載の方法。
　（Ｄ）において特定された課金方式が、ユーザ使用総量ベースであることと、契約中サービスユーザの並び順を可変とすることとを含む場合、それぞれの一連の処理において、
　　（Ｂ）の判断結果が肯定の場合、１以上の契約中サービスユーザにそれぞれ対応した１以上のユーザ使用量の複数通りの並び順を特定し、
　　単位容量当たりの金額に基づく単価をサービスユーザ毎に関連付けた第４の情報を参照することにより、特定された複数通りの並び順にそれぞれ対応する複数通りの課金額のうちの一の課金額を算出し、前記複数通りの課金額の各々は、その課金額に対応した並び順において前記第１の超過容量に関わるサービスユーザに対応した単価に基づく課金額であり、
　（Ｄ）において特定された課金方式が、提供総容量ベースであることと、契約中サービスユーザの並び順を可変とすることとを含む場合、それぞれの一連の処理において、
　　（Ｂ）の判断結果が肯定の場合、１以上の契約中サービスユーザにそれぞれ対応した１以上の提供容量の複数通りの並び順を特定し、
　　前記第４の情報を参照することにより、特定された複数通りの並び順にそれぞれ対応する複数通りの課金額のうちの一の課金額を算出し、前記複数通りの課金額の各々は、その課金額に対応した並び順において前記第２の超過容量に関わるサービスユーザに対応した単価に基づく課金額である、
請求項２記載の方法。
　前記１以上の論理ボリュームが、前記ホストシステムからのライト要求に応答してプールから記憶領域が割り当てられる仮想的な論理ボリュームである仮想ボリュームを含む場合、少なくとも前記仮想ボリュームについて、前記課金方式として提供総容量ベースの選択を不可能に制御し、
　少なくとも前記仮想ボリュームについて、保有量は、プールの容量である、
請求項２記載の方法。
　（Ｂ）の判断結果が肯定の場合、前記第１の超過容量に関わると定義されたサービスユーザを、課金対象ユーザとして管理し、
　（Ｂ）の判断結果が否定であっても、課金対象ユーザとして管理されているサービスユーザがいる場合、そのサービスユーザに関しての金額を含んだ課金額を算出する、
請求項１記載の方法。
　（Ｂ）の判断結果が肯定の場合、１以上の契約中サービスユーザにそれぞれ対応した１以上のユーザ使用量又は提供容量の複数通りの並び順を特定し、
　単位容量当たりの金額に基づく単価をサービスユーザ毎に関連付けた第４の情報を参照することにより、特定された複数通りの並び順にそれぞれ対応する複数通りの課金額のうちの一の課金額を算出し、前記複数通りの課金額の各々は、その課金額に対応した並び順において前記第１又は第２の超過容量に関わるサービスユーザに対応した単価に基づく課金額である、
請求項１記載の方法。
　前記決定された課金額と、その課金額の少なくとも１つの根拠とを示す情報を含んだ情報である課金結果情報を表示し、
　前記課金結果情報に、前記決定された課金額の根拠を示す情報が関連付けられている、
請求項１記載の方法。
　データ量削減処理後の１以上のデータの総量に従う実使用総量を前記ストレージシステムから特定し、
　以下の（Ｘ）及び（Ｙ）を表示し、
　　（Ｘ）前記実使用総量及び前記ユーザ使用総量と、前記ユーザ使用総量及び前記実使用総量に基づき算出されるデータ量削減効果とのうちの少なくとも１つを示す情報、
　　（Ｙ）既存のサービスユーザに提供されている論理ボリュームの容量に追加される容量と新規のサービスユーザに提供する論理ボリュームの容量とのうちの少なくとも１つの容量のための入力ＵＩ（ユーザインターフェース）、
　前記提供総容量は、前記入力ＵＩを通じて入力された容量を含む、
請求項１記載の方法。
　データ量削減処理後の１以上のデータの総量に従う実使用総量を前記ストレージシステムから特定し、
　既存又は新規のサービスユーザについて期待されるユーザ使用総量変化のための第１の入力ＵＩと、期待されるデータ量削減効果又はデータ量削減効果に影響する属性のための第２の入力ＵＩとを表示し、
　前記実使用総量と、前記第１の入力ＵＩを通じて入力されたユーザ使用総量変化と、前記第２の入力ＵＩを通じて入力されたデータ量削減効果又は属性とに基づき、前記保有量に対する将来の実使用総量の割合と、その割合の１以上の閾値との関係を予測し、予測された関係を表示する、
請求項１記載の方法。
　前記ストレージシステムが有する１以上のストレージ装置のうち前記サービスプロバイダに提供されるストレージ装置毎に、そのストレージ装置での実使用総量と、前記入力されたユーザ使用量と、前記入力されたデータ量削減効果又は属性とに基づき、将来の実使用総量と、実使用総量に関する１以上の閾値との関係を予測する、
請求項１０記載の方法。
　データ量削減処理後の１以上のデータの総量に従う実使用総量を前記ストレージシステムから特定し、
　前記保有量に対する前記実使用総量の割合である実使用割合と、前記実使用割合の１以上の閾値との関係を表示し、
　前記サービスプロバイダ所望の実使用割合に低減するために必要な対策処理と、実行可能な対策処理を実行した場合の期待される実使用割合とのうちの少なくとも１つを表示する、
請求項１記載の方法。
　前記データ量削減機能は、重複排除機能と、圧縮機能とを含み、
　前記重複排除機能が、デフォルトの機能であり、
　前記圧縮機能が、サービスユーザ毎にオプショナルの機能であり、
　前記期待される実使用割合は、圧縮機能がオンにされたサービスユーザに対応する論理ボリュームに格納されているデータが実際に圧縮された場合と圧縮されたと仮定した場合とのうちの少なくとも１つの場合に期待される実使用割合である、
請求項１２記載の方法。
　前記ストレージシステムは、ストレージベンダにより製造された、又は、前記ストレージベンダにより前記サービスプロバイダに対し販売、貸出し又は使用が許可されたシステムである、
請求項１記載の方法。
　サービスプロバイダの計算機システムであるプロバイダシステムと、ストレージシステムとに接続されたインターフェースデバイスと、
　前記インターフェースデバイスに接続されたプロセッサと
を有し、
　前記インターフェースデバイスが、第１の情報と第２の情報とを前記プロバイダシステムと前記ストレージシステムとのうちの少なくとも１つから受信し、
　前記第１の情報は、提供総容量とユーザ使用総量とのうちの少なくとも１つを特定するための情報であり、
　前記提供総容量は、１以上のサービスユーザに提供された１以上の論理ボリュームの総容量であり、
　前記ユーザ使用総量は、前記１以上の論理ボリュームに格納されデータ量削減機能によるデータ量削減処理前の１以上のデータの総量であり、
　前記第２の情報は、保有量を特定するための情報であり、
　前記保有量は、前記ストレージシステムが前記サービスプロバイダについて保有する記憶空間でありデータが格納される記憶空間の容量の上限であり、
　前記プロセッサが、
　　前記第１の情報から特定されたユーザ使用総量及び提供総容量のうちの少なくとも１つが、前記第２の情報から特定された保有量を超えているか否かを判断し、
　　その判断の結果が肯定の場合、前記ユーザ使用総量と前記保有量との差分である第１の超過容量と、前記提供総容量と前記保有量との差分である第２の超過容量と、前記第１及び第２の超過容量のうちの少なくとも１つに関わると定義されたサービスユーザに対応した金額とのうちの少なくとも１つに基づく課金額を算出する、
管理システム。