JP7118108B2 - クラウドサーバ、ストレージシステム、及び計算機システム - Google Patents

Description

本発明は、クラウドの容量を削減し、セキュリティを向上させるクラウドサーバ、ストレージシステム、及び計算機システムに関する。

大規模なデータを扱う計算機システムは、ホスト計算機とは別個に設けられた大容量のストレージシステムを用いてデータを管理している。このストレージシステム（クラウドストレージ）をクラウド上に構成するクラウドシステムがある。このようなクラウドシステムでは、顧客のデータセンタ（以後、オンプレミスと呼ぶ）に配置されているストレージシステムがクラウドストレージへのデータの格納を制御し、クラウド上の計算機や仮想マシンがクラウド上に格納されるデータを用いて業務を実行する。これにより、データの分析処理のように、一度に大量のリソースを使う業務を、低コストで実現できる。

特許文献１の技術では、オンプレミスのストレージシステムの容量の節約と高アクセス性能等を提供することを目的とした技術が開示されている。

特許第６３１７５２４号

上記特許文献１のストレージシステムは、オンプレミス（１０）は、ストレージシステム（２００）と、当該ストレージシステムにデータを保存するホスト（１００）とを含む。ホスト（１００）は、本番業務を実行する。ストレージシステム（２００）はホスト（１００）に提供する仮想ボリューム（２９３）を有し、ホストの業務で使用されるデータがストレージシステム（２００）の仮想ボリューム（２９３）に格納される。オンプレミス（１０）が接続されるクラウド（２０）は、ボリューム（３１０）を構成するストレージＶＭ（３００）を有する。ストレージシステム（２００）は、ストレージシステム（２００）の仮想ボリューム（２９３）とクラウド（２０）のボリューム（３１０）でペアを構成する。これにより、クラウド（２０）のボリューム（３１０）に仮想ボリューム（２９３）の全データを格納する。また、計算機システム全体としては、Ｈｏｔ ＤａｔａはストレージシステムとストレージＶＭの両方に格納し、Ｃｏｌｄ ＤａｔａはストレージＶＭのみに格納することで、ストレージシステムの容量の節約と高アクセス性能を実現している。

しかしながら、特許文献１は、ホストが直接オンプレミスのストレージシステムにデータをライト、あるいは格納されたデータをリードする構成とし、Ｈｏｔ ＤａｔａとＣｏｌｄ Ｄａｔａの全てのデータをクラウドで格納するため、クラウドの容量が増加し、従量課金による運用コストの増大を招く恐れがある。

クラウドとオンプレミスを用いる計算機システムでは、クラウドの機能を利用可能で、オンプレミスには信頼できる全データを保存したいという要求があるが、上記特許文献１では、この要求を満足させる技術は開示されていない。たとえば、クラウドのボリュームを外部からアクセス可能とし、クラウドからオンプレミスのボリュームに直接書き込める構成におけるオンプレミスのボリュームのセキュリティの向上については、開示されていない。

そこで、本発明の目的は、クラウドの容量を削減し、セキュリティを向上させるクラウドサーバ、ストレージシステム、及び計算機システムを提供することにある。

上記目的を達成するため、本発明の計算機システムの一態様は、業務サービスに対し、データ記憶領域として提供される仮想ボリュームと、仮想ボリュームに格納されるデータの一部を格納する、複数のページを有するキャッシュプールと、キャッシュプールのページ毎に、仮想ボリュームへの割り当てを管理するキャッシュ管理情報を格納する記憶部とを有するクラウドサーバと、仮想ボリュームに対応する論理ボリュームを有するストレージシステムと、を有する。

クラウドサーバは、仮想ボリュームに対し、ライト要求を受領すると、ライト要求のライトデータをキャッシュプールに格納し、キャッシュ管理情報を、ライトデータが格納されたキャッシュプールのアドレスに基づいて更新し、更新されたキャッシュ管理情報に基づいて、作成されるライトデータ転送要求を、ストレージシステムに提供する。

ストレージシステムは、ライトデータ転送要求に従って、キャッシュプールからデータを読み出し、読み出したデータを、論理ボリュームにライトする。

本発明によれば、クラウドの容量を削減し、セキュリティを向上させることができる。

また、オンプレミスに格納されたデータの改変を防止し、セキュリティを向上させることができる。

実施例１の計算機システムの構成の一例を示す図である。 実施例１の計算機システムのボリューム構成の一例を示す図である。 実施例１の業務サーバの構成の一例を示す図である。 実施例１のクラウドサーバの構成の一例を示す図である。 実施例１のストレージシステムの一例を示す図である。 実施例１キャッシュプール管理テーブルの一例を示す図である。 実施例１のボリューム管理テーブルの一例を示す図である。 実施例１のアドレス 管理テーブルの一例を示す図である。 実施例１のキャッシュ管理テーブルの一例を示す図である。 実施例１のボリューム管理テーブル（特性）の一例を示す図である。 実施例１のデータ転送要求情報の一例を示す図である。 実施例１のデータ転送完了通知の一例を示す図である。 実施例１のキャッシュプールの生成手順の一例を示す図ある。 実施例１の仮想ボリュームの生成手順の一例を示す図である。 実施例１のライト動作フロー (同期) の一例を示す図である。 実施例１のライト動作フロー (非同期) の一例を示す図である。 実施例１のリード動作フローの一例を示す図である。 実施例２のハッシュ値を用いたライト動作フローの一例を示す図である。

以下、図面を参照しながら実施の形態を説明する。また、以下の説明では、「テーブル」等の表現にて各種情報を説明することがあるが、テーブル以外のデータ構造で表現されていてもよい。また、データ構造に依存しないことを示すために「テーブル」を「管理情報」と呼ぶことができる。

また、「プログラム」を主語として処理を説明する場合がある。そのプログラムは、処理部であるプロセッサ、例えば、ＭＰ（Micro Processor）やＣＰＵ（Central Processing Unit）によって実行され、定められた処理をするものである。尚、プロセッサは、適宜に記憶資源（例えばメモリ）及び通信インタフェース装置（例えば、通信ポート）を用いながら処理を行うため、処理の主語がプロセッサ、或いは処理部とされてもよい。プロセッサは、ＣＰＵの他に専用ハードウェアを有していてもよい。コンピュータプログラムは、プログラムソースから各コンピュータにインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアなどで提供されるものであってもよい。

また、本実施例の図及び説明において同一部分には同一符号を付与しているが、本発明が本実施例に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に限定しない限り、各構成要素は複数でも単数でも構わない。

＜システム構成＞
図１は、計算機システムの構成の一例を示す図である。

計算機システム１００は、顧客拠点１０のクライアントＰＣ１０１と、顧客データセンタ３０を構成する業務サーバ３１０、ストレージシステム３２０と、パブリックグラウト２０とをネットワーク４０を介して接続して構成されている。ネットワーク４００は、ｉＳＣＳＩを用いることができる。

パブリッククラウド２０は、業務サービス２１０、仮想ボリュームサービス２２０、クラウドストレージサービス２４０等の各サービスを提供する。パブリッククラウド２０は、クラウド上の複数の計算機やクラウド上の複数の計算機のリソースを用いた仮想計算機によって構成されても良い。パブリッククラウド２０は、クラウドシステムと称することができる。

顧客データセンタ３０は、パブリッククラウド２０に対し、いわゆるオンプレミスと称することができる。

図２は、実施例１の計算機システムのボリューム構成の一例を示す図である。

仮想ボリュームサービス２２０は、少なくとも一つの仮想ボリューム２２６をデータ格納領域として業務サービス２１０に提供する。計算機システム１００では、仮想ボリューム２２６は、業務サービス等のホストからデータの格納先のボリュームとして見える。また、計算機システム１００では、仮想ボリューム２２６を、データの格納先アドレスとして管理し、実際のデータである実データはオンプレミスの論理ボリューム３２４２とキャッシュプール２４１に格納する。

仮想ボリューム２２６は、仮想的な容量を持つ空のボリュームであり、業務サービス等のホストによって仮想ボリューム２２６へデータがライトされると、キャッシュプール２４１から仮想ボリューム上の当該ＬＢＡ領域へページ単位で実体を割当てる。より具体的には、仮想ボリュームサービス２２０は、仮想ボリューム２２６のＬＢＡとキャッシュプール２４１のＬＢＡとの対応関係をページ単位で管理するキャッシュ管理テーブル５３０(図８参照)を持ち、この情報を更新する。キャッシュプール２４１は、ページと呼ばれる、例えば、数ＭＢで区切られた固定長単位で管理される。

キャッシュプール２４１は、仮想ボリューム２２６のデータの内、直近にアクセスされたデータやアクセス頻度の高いデータを格納するストレージボリュームである。業務サービス２１０が仮想ボリューム２２６のデータをリードする場合、当該データがキャッシュプール２４１に格納されている場合、オンプレミス３０のストレージシステム３２０からデータを読み出す必要がないため、業務サービス２１０に高速にデータを送信することができる。一つの仮想ボリューム２２６に割り当てられるキャッシュプール２４１の容量を設定することができ、仮想ボリューム２２６の容量より小さな容量を設定することができる。キャッシュプール２４１は、一つであっても複数であってもかまわない。一つの仮想ボリュームが複数のキャッシュプールに対応していても良い。以下の実施例１の説明では、一つの仮想ボリューム２２６は、一つのキャッシュプールと対応付けられていることを前提として説明する。

ストレージシステム３２０のそれぞれの論理ボリューム３２４２は、仮想ボリュームサービス２２０の仮想ボリューム２２６の一つに対応しており、論理ボリューム３２４２は、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）技術により、複数のＨＤＤやＳＳＤによって構成されても良い。

図３は、実施例１の業務サービスを提供する業務サーバの構成を示したものである。業務サービス２１０を提供するサーバを業務サーバとして説明する。

業務サーバ２１０は、一般の計算機と同様、ネットワークインタフェース２１３と、メモリ２１２と、処理部となるＣＰＵ２１１と、ＨＤＤやＳＳＤ等の記憶装置２１４と、メモリ２１２、ＣＰＵ２１１、記憶装置２１４とネットワークインタフェース２１３とを接続するバスのような接続装置２１５とを有する。

メモリ２１２は、データ解析等の業務サービスを構成するプログラムを格納する。図３では、理解を容易にするため、業務サービス部２１２１と機能的に記載したが、ＣＰＵ２１１が、メモリ２１２に格納されたプログラムを実行して、業務サービス部２１２１の機能を実現する。

尚、業務サーバ３１０は、業務サーバ２１０と基本的構成が共通するため、詳細な説明は省略する。また、業務サーバ３１０は、Software Defined Storage(SDS)によって構成されても良い。

図４は、実施例１の仮想ボリュームサービス２２０あるいは、クラウドストレージサービス２４０を提供するクラウドサーバ２３０の構成を示したものである。

クラウドサーバ２３０は、一般の計算機と同様、ネットワークインタフェース２２３と、メモリ２２２と、処理部となるＣＰＵ２２１と、ＨＤＤやＳＳＤ等の記憶装置２２４と、ネットワークインタフェース２２３と、メモリ２２２、ＣＰＵ２２１、記憶装置２２４とネットワークインタフェース２２３とを接続するバスのような接続装置２２５とを有する。

メモリ２２２は、キャッシュプール管理部２２２１、仮想ボリューム作成部２２２２、Ｉ／Ｏ処理部２２２３、データ転送要求部２２２４、オンプレ通信処理部２２２５を構成するプログラムを格納する領域を有する。図４では、理解を容易にするため、キャッシュプール管理部２２２１、仮想ボリューム作成部２２２２、Ｉ／Ｏ処理部２２２３、データ転送要求部２２２４、オンプレ通信処理部２２２５と機能的に記載したが、これらの機能は、ＣＰＵ２２１が、メモリ２２２に格納されたプログラムを実行して、キャッシュプール管理部２２２１、仮想ボリューム作成部２２２２、Ｉ／Ｏ処理部２２２３、データ転送要求部２２２４、オンプレ通信処理部２２２５等の機能を実現する。キャッシュプール管理部２２２１、仮想ボリューム作成部２２２２、Ｉ／Ｏ処理部２２２３、データ転送要求部２２２４、オンプレ通信処理部２２２５を総称してクラウドサーバ処理部と称することがある。

キャッシュプール管理部２２２１、仮想ボリューム作成部２２２２、Ｉ／Ｏ処理部２２２３、データ転送要求部２２２４、オンプレ通信処理部２２２５は、クラウドサーバ２３０の処理部となる。

記憶装置２２４は、各種管理データを記憶するための管理テーブル２２４１を格納する。また、キャッシュプール２４１としてストレージボリュームを構成する。

尚、図４では、クラウドサーバ２３０を便宜上一台の計算機で構成される例を示したが、クラウド上の複数の計算機やクラウド上の複数の計算機のリソースを用いた仮想計算機によって構成されても良い。

図５は、実施例１のストレージシステム構成の一例を示す図である。

ストレージシステム３２０は、ネットワークインタフェース３２３と、メモリ３２２と、処理部となるＣＰＵ３２１と、ＨＤＤやＳＳＤ等の記憶装置３２４と、ネットワークインタフェース３２３と、メモリ３２２、ＣＰＵ３２１、記憶装置３２４とネットワークインタフェース３２３とを接続するバスのような接続装置３２５とを有する。

メモリ３２２は、データ転送要求処理部３２２１、キャッシュプールＩ／Ｏ処理部３２２２、論理ボリュームＩ／Ｏ処理部３２２３、論理ボリューム管理部３２２４を構成するプログラムを格納する領域を有する。図５では、理解を容易にするため、データ転送要求処理部３２２１、キャッシュプールＩ／Ｏ処理部３２２２、論理ボリュームＩ／Ｏ処理部３２２３、論理ボリューム作成部論理ボリューム作成部と機能的に記載したが、これらの機能は、ＣＰＵ３２１が、メモリ３２２に格納されたプログラムを実行して、データ転送要求処理部３２２１、キャッシュプールＩ／Ｏ処理部３２２２、論理ボリュームＩ／Ｏ処理部３２２３、論理ボリューム管理部３２２４の機能を実現する。データ転送要求処理部３２２１、キャッシュプールＩ／Ｏ処理部３２２２、論理ボリュームＩ／Ｏ処理部３２２３、論理ボリューム管理部３２２４をストレージシステム処理部と称することがある。

データ転送要求処理部３２２１、キャッシュプールＩ／Ｏ処理部３２２２、論理ボリュームＩ／Ｏ処理部３２２３、論理ボリューム管理部３２２４は、ストレージシステム３２０の処理部となる。

記憶装置３２４は、その記憶領域を用いて少なくとも一つの論理ボリューム３２４２を構成する。

＜管理テーブル＞
図６は、図３のクラウドサーバ２３０の管理テーブル２２４１に格納される管理データの内のキャッシュプール管理テーブル５１０を示した図である。

キャッシュプール管理テーブル５１０は、キャッシュプールとして使用するクラウド上のストレージボリュームの情報を管理するテーブルであり、キャッシュプールＩＤ５１１、ＮｉｃｋＮａｍｅ５１２、ｉＳＣＳＩアドレス５１３、容量５１４、使用容量５１５を対応付けて管理する。

キャッシュプールＩＤ５１１は、複数のキャッシュプールのそれぞれを識別するための情報である。キャッシュプールが一つの場合には、キャッシュプールＩＤ５１１を省略しても良い。ＮｉｃｋＮａｍｅ５１２は、キャッシュプールに割り当てられた名称である。ｉＳＣＳＩアドレス５１３は、ｉＳＣＳＩによってキャッシュプールＩＤ５１１のキャッシュプールにアクセスするためのアドレスである。容量５１４は、キャッシュプールの容量である。使用容量５１５は、キャッシュプールの使用容量である。

例えば、キャッシュプールＩＤ５１１「１」は、ＮｉｃｋＮａｍｅ５１２「ＣＰ１」、ｉＳＣＳＩアドレス５１３「xxx.xxx.xx1」、容量５１４「１Ｔ」、使用容量５１５「５００Ｇ」であることを示している。

キャッシュプール管理テーブル５１０の各エントリは、キャッシュプールが作成されたタイミングで登録され、キャッシュプールが削除されたタイミングで削除される。また、キャッシュプールの容量が変更されたときに、容量５１４の値が変更される。

図７Ａは、図３のクラウドサーバ２３０の管理テーブル２２４１に格納される管理データの内のボリューム管理テーブル５２０を示した図である。

ボリューム管理テーブル５２０は、クラウド上の仮想ボリューム２２６とストレージシステム３２０の論理ボリューム３２４２の対応付けを管理するテーブルであり、ＶＯＬ ＩＤ５２１、仮想ＶＯＬ ＩＤ５２２、ストレージ製番５２３、論理ＶＯＬ ＩＤ５２4を対応付けて管理する。

ＶＯＬ ＩＤ５２１は仮想ＶＯＬと論理ＶＯＬとの対応関係を識別する情報である。仮想ＶＯＬ ＩＤ５２２は仮想ＶＯＬを識別する情報であり、ストレージ製番５２３はストレージシステム３２０の内のストレージ装置を識別するための情報であり、論理ＶＯＬ ＩＤ５２4はストレージ製番５２３で識別されたストレージ装置における論理ボリュームを識別する情報である。このように、ボリューム管理テーブル５２０はストレージ製番５２３を含む情報であり、ストレージシステム３２０は、一つのストレージ装置で構成されるほか、複数のストレージ装置により構成されても良い。

ボリューム管理テーブル５２０において、例えば、ＶＯＬ ＩＤ５２１が「１」に対し、仮想ＶＯＬ ＩＤ５２２「0001」、ストレージ製番５２３「880000111111」、論理ＶＯＬ ＩＤ５２4「0x01」が対応付けて管理されている。

ボリューム管理テーブル５２０のエントリは、仮想ＶＯＬを作成したタイミングで追加され、仮想ＶＯＬを削除したタイミングで削除される。

図７Ｂは、図３のクラウドサーバ２３０の管理テーブル２２４１に格納される管理データの内のアドレス管理テーブル５２５を示した図である。

アドレス管理テーブル５２５は、仮想ＶＯＬ２２６のアドレスと論理ＶＯＬ３２４２のアドレスの対応を管理し、ＶＯＬ ＩＤ５２６、仮想ＶＯＬ ＩＡＤ５２７、論理ＶＯＬ ＡＤ５２８とを対応付けて管理する。

ＶＯＬ ＩＤ５２６は仮想ＶＯＬと論理ＶＯＬとの対応関係を識別する情報であり、ボリューム管理テーブル５２０のＶＯＬ ＩＤ５２１に対応する情報である。仮想ＶＯＬ ＩＡＤ５２７は仮想ＶＯＬのアドレスを示す情報であり、論理ＶＯＬ ＡＤ５２８は論理ＶＯＬのアドレスを示す情報である。

アドレス管理テーブル５２５において、例えば、ＶＯＬ ＩＤ５２６「１」に対し、仮想ＶＯＬ ＩＡＤ５２７「0010」、論理ＶＯＬ ＡＤ５２８「0010」が対応付けて管理されている。図７Ｂでは、仮想ＶＯＬ ＩＡＤ５２７と論理ＶＯＬ ＡＤ５２８に同じ値のアドレスが含まれている状態を示しているが、これらの情報は同じ値である必要がないことは言うまでもない。

図７Ａと図７Ｂは二つのテーブルで管理したが、一つのテーブルで管理しても良い。また、仮想ＶＯＬのＡＤと論理ＶＯＬのＡＤが一対一で対応する場合には、仮想ＶＯＬのＡＤを論理ＶＯＬのＡＤとして使用することや、仮想ＶＯＬのＡＤから論理ＶＯＬのＡＤを計算で求めることができるため、図７Ｂの情報を省略することができる。

図８は、図３のクラウドサーバ２３０の管理テーブル２２４１に格納される管理データの内のキャッシュ管理テーブル５３０を示した図である。キャッシュ管理テーブル５３０は、キャッシュプールに格納されている情報を、ページ単位で管理する情報であり、ページＩＤ５３１、キャッシュプールＡＤ５３２、仮想ＶＯＬ ＩＤ５３３、仮想ＶＯＬ ＡＤ５３４、最終アクセス時間５３５、アクセス頻度５３６、格納データのハッシュ値５３７と、を対応付けて管理する。

ページＩＤ５３１は、ページを識別する情報で、一つのキャッシュプール分のレコードが存在する。キャッシュプールＡＤ５３２はキャッシュプールにおけるアドレス情報を示し、仮想ＶＯＬ ＩＤ５３３はキャッシュプールのページが割り当てられる仮想ＶＯＬを識別する情報であり、仮想ＶＯＬ ＡＤ５３４はキャッシュプールのページが割り当てられる仮想ボリュームのアドレスを示す情報であり、最終アクセス時間５３５は当該ページのデータに直近にアクセスした時間を示し、アクセス頻度５３６は仮想ＶＯＬのアドレスに格納されるデータのアクセス頻度を示し、格納データのハッシュ値５３７はデータのハッシュ値を示す。

例えば、ページＩＤ５３１「１」に対し、キャッシュプールＡＤ５３２「0001」、仮想ＶＯＬ ＩＤ５３３「１」、仮想ＶＯＬ ＡＤ５３４「0010」、最終アクセス時間５３５「01/01 00:00」、アクセス頻度５３６「10」、格納データのハッシュ値５３７「Yvh0251」が対応して管理されている。

尚、キャッシュプール２４１が複数の場合、キャッシュ管理テーブル５３０は、キャッシュプール２４１毎に設けられ、キャッシュプール２４１を識別する情報、例えば、ｉＳＣＳＩアドレス等をキャッシュ管理テーブルに追加する。

図９は、図３のクラウドサーバ２３０の管理テーブル２２４１に格納される管理データの内のボリューム管理テーブル（特性）６２０を示した図である。

ボリューム管理テーブル（特性）６２０は、仮想ボリューム単位でボリュームの詳細情報、特に、仮想ＶＯＬの特性を管理し、仮想ＶＯＬ ＩＤ６１１、容量６１１、割り当て可能容量６１３、優先度６１４、キャッシュヒット率６１５、データ転送要求数リード時６１６、データ転送要求数ライト時６１７、平均転送時間６１８等と、を対応付けて管理する。

ボリューム管理テーブル（特性）６２０は、仮想ボリュームに対して、処理の優先度や特性を設定するために用いられる。たとえば、ある仮想ボリュームの優先度６１４が「High」の場合、当該仮想ボリュームに割り当てられるクラウド上のキャッシュプール２４１の容量（割り当て可能容量６１３）を大きくする。キャッシュヒット率６１５、データ転送要求数リード時６１６、データ転送要求数ライト時６１７、平均転送時間６１８は、クラウドサーバ２３０が稼働状態における各種計測値である。

ボリューム管理テーブル(特性)６２０は、仮想ボリュームが作成されるとエントリを追加し、仮想ボリュームが削除されるとエントリを削除する。また、キャッシュヒット率６１５、データ転送要求数リード時６１６、データ転送要求数ライト時６１７、平均転送時間６１８は、仮想ボリュームに対するリードライトのタイミングや一定の時間間隔で更新される。

図１０Ａは、データ転送要求情報を示した図である。データ転送要求情報は、クラウドサーバ２３０からオンプレミスのストレージシステム３２０にデータ転送をするために必要となる情報であり、要求ＩＤ９０１、種別９０２、論理ＶＯＬ ＩＤ９０３、論理ＶＯＬ ＡＤ９０４、キャッシュプールＡＤ９０５、データハッシュ値９０６を含む。即ち、データ転送要求情報９０は、データ転送要求の際に用いるデータフォーマットと理解することができる。尚、データハッシュ値９０６は、実施例２で利用する情報であり、要求ＩＤによって特定されるライトデータのハッシュ値である。

要求ＩＤ９０１は、データ転送要求を識別するための情報であり、要求ＩＤ９０１に対し、種別９０２はデータ転送要求がライト要求であるかリード要求であるかを示す。論理ＶＯＬ ＩＤ９０３は、要求ＩＤ９０１で識別されるデータ転送要求先の論理ＶＯＬ３２４２を識別する情報であり、論理ＶＯＬ ＡＤ９０４は要求ＩＤ９０１で識別されるデータ転送要求先の論理ボリュームのアドレス情報である。キャッシュプールＡＤ９０５はデータ転送要求のデータを格納するキャッシュプールのアドレスを示し、データハッシュ値９０６は、データ転送要求のデータのハッシュ値を示す。

尚、図１０Ａに示したデータ転送要求情報９０は、キャッシュプールが一つの場合を前提とした情報であり、キャッシュプールが一複数の場合には要求ＩＤのエントリにキャッシュプールを識別する情報、例えば、ｉＳＣＳＩアドレスやキャッシュプールＩＤを付与すればよい。

図１０Ｂは、データ転送完了通知の情報を示した図である。データ転送完了通知９１は、要求ＩＤ９１１、種別９１２、ステータス９１３、データハッシュ値９１４を含む。データ転送完了通知９１は、データ転送完了通知の際に用いるデータフォーマットと理解することができる。

例えば、要求ＩＤ９１１はデータ転送要求を識別する情報である。種別９１２はデータ転送要求の種別を示す情報であり、データ転送要求がライトかリードかを示す。ステータス９１３はデータ転送要求の状況を示す情報であり、例えば完了を示す「Ｃｏｍｐｌｅｔｅｄ」が含まれる。データハッシュ値９１４はデータ転送要求にかかるデータのハッシュ値である。

＜キャッシュプールの生成手順＞
図１１は、クラウド２０で、クラウドサーバ２３０のキャッシュプール管理部２２２１が処理するキャッシュプールの生成手順の一例を示す図ある。

管理端末(図示せず)から、クラウドサーバ２３０がキャッシュプール生成の命令を受信すると処理を開始する（Ｓ１１１）。クラウドサーバ２３０がキャッシュプール生成の命令を受信するとクラウドサーバ２３０の記憶装置を用いてキャッシュプール２４１としてストレージボリュームを作成する（Ｓ１１２）。

ステップＳ１１２で作成したストレージボリュームをキャッシュプール２４１として、キャッシュプール管理テーブル５１０に登録する（Ｓ１１３）。ステップＳ１１３では、キャッシュプールＩＤ５１１、ＮｉｃｋＮａｍｅ５１２、ｉＳＣＳＩアドレス５１３、容量５１４が登録される。尚、キャッシュプールとして作成されるストレージボリュームは、ＡＷＳ（登録商標）、Ａｚｕｒｅ（登録商標）等で一般的にクラウド上の汎用的なボリュームである。

＜仮想ボリュームの生成手順＞
図１２は、計算機システム１００における仮想ボリュームの生成手順を示したものである。より詳しくは、図１２は、クラウドサーバ２３０の仮想ボリューム作成部２２２２が処理する仮想ボリュームの作成手順と、ストレージシステム３２０の論理ボリューム管理部３２２４が処理する論理ボリューム３２４２の作成処理の一例を示す図である。図１２においては、左側に示したクラウド２０の処理を仮想ボリューム作成部２２２２が実行し、右側に示したオンプレ３０の処理を論理ボリューム管理部３２２４が実行する。

クラウド２０において、クラウドサーバ２３０の仮想ボリューム作成部２２２２は、管理端末から仮想ボリュームの作成指示を受領する（Ｓ１２１）。

仮想ボリューム作成部２２２２は、オンプレミス３０のストレージシステム３２０に対し、論理ボリューム作成要求を行う（Ｓ１２２）。

ストレージシステム３２０の論理ボリューム管理部３２２４は、クラウド２０から論理ボリューム作成指示を受領する（Ｓ１２３）。ステップＳ１２４で、作成要求があるか否かを判定し（Ｓ１２４）、なければ、ステップＳ１２３に戻り、作成要求があればステップＳ１２５に進む。尚、ステップＳ１２２において、仮想ボリューム作成部２２２２が論理ボリューム作成要求をタスクとしてオンプレ通信処理部２２２５に登録し、ステップＳ１２３において、論理ボリューム管理部３２２４が、オンプレ通信処理部２２２５のタスクをポーリングしても良い。

ステップＳ１２５で、論理ボリューム管理部３２２４は、ストレージシステム３２０の記憶装置３２４を用いて論理ボリューム３２４２を作成する。

ステップＳ１２６で、作成した論理ボリューム３２４２を、クラウドサーバ２３０のキャッシュプール３４１にｉＳＣＳＩにより接続する。これにより、ストレージシステム３２０からキャッシュプール３４１に格納されたデータに対し、リード及びライトを行うことができる状態となる。

ステップＳ１２７で、論理ボリューム３２４２の作成が完了したら、クラウドサーバ２３０に対し、完了報告を行う。

クラウドサーバ２３０の処理部（仮想ボリューム作成部２２２２）は、オンプレミス３０のストレージシステム３２０から論理ボリューム作成完了報告を受領すると（Ｓ１２８）、作成した論理ボリューム３２４２に対応する仮想ボリューム２２６を作成する（Ｓ１２９）。仮想ボリューム作成部２２２２は、作成した論理ボリューム３２４２と仮想ボリューム２２６の情報を、ボリューム管理テーブル５２０、アドレス管理テーブル５２５に登録することで、管理テーブルを更新する（Ｓ１２１０）。

ボリューム管理テーブル５２０には、ＶＯＬ ＩＤ５２１、仮想ＶＯＬ ＩＤ５２２、ストレージ製番５２３、論理ＶＯＬ ＩＤ５２4の各エントリが登録され、アドレス管理テーブル５２５にはＶＯＬ ＩＤ５２６、仮想ＶＯＬ ＩＡＤ５２７、論理ＶＯＬ ＡＤ５２８のエントリが登録される。これにより、仮想ボリュームと論理ボリュームとの対応、仮想ボリュームと論理ボリュームのアドレスの対応関係が管理される。

＜ライト動作フロー (同期)＞
図１３は、計算機システム１００におけるライト動作フロー (同期)の処理手順を示したものである。より詳しくは、図１３は、クラウドサーバ２３０のＩ／Ｏ処理部２２２３が処理する仮想ボリューム２２６に対するライト動作処理手順と、ストレージシステム３２０の論理ボリュームＩ／Ｏ処理部３２２３か処理する論理ボリューム３２４２に対するライト動作処理手順の一例を示す図である。図１３においては、左側に示したクラウド２０の処理をクラウドサーバの処理部が実行し、右側に示したオンプレ３０の処理をストレージシステムの処理部が実行する。したがって、クラウド２０側の処理には、ストレージシステム３２０にライト要求を転送するデータ転送要求を行うデータ転送要求部２２２４の処理と、ストレージシステム側でデータ転送処理を受けるデータ転送要求処理部３２２１の処理も含まれる。

クラウド２０側のクラウドサーバ２３０のＩ／Ｏ処理部２２２３が、業務サービス２１０やクライアントＰＣ１０１等から仮想ボリューム２２６に対するライト要求を受領する（Ｓ１３１）。ライト要求には、仮想ボリュームを識別する仮想ＶＯＬ ＩＤと、仮想ボリュームのライト先アドレスを示す仮想ＶＯＬ ＡＤと、ライトデータが含まれている。

Ｉ／Ｏ処理部２２２３は、キャッシュ管理テーブル５３０を参照し、キャッシュプール２４１にライトデータをライトする（Ｓ１３３）。ここで、ライト要求に含まれる仮想ＶＯＬ ＩＤと、仮想ＶＯＬ ＡＤが、キャッシュ管理テーブル５３０に登録されていれていれば、対応するキャッシュページＩＤにライトデータをライトし、キャッシュ管理テーブル５３０の最終アクセス時間５３５、アクセス頻度５３６、ライトデータ（格納データ）のハッシュ値５３７のエントリを更新する。登録されていなければ、仮想ＶＯＬ ＩＤと、仮想ＶＯＬ ＡＤが割り当てられていないキャッシュプールのページＩＤに対応するエントリに、ライト要求に含まれる仮想ＶＯＬ ＩＤと仮想ＶＯＬ ＡＤの情報を登録し、最終アクセス時間５３５、アクセス頻度５３６、ライトデータ（格納データ）のハッシュ値５３７のエントリを更新する（Ｓ１３４）。

データ転送要求部２２２４は、キャッシュ管理テーブル５３０に基づいて、ライトデータ転送要求を作成する（Ｓ１３５）。作成したライトデータ転送要求は、クラウドサーバ２３０からストレージシステム３２０に提供される。ライトデータ転送要求は、図１０Ａに示したデータ転送要求情報９０の種別９０２が「ライト」で示された情報を有する。

ライトデータ転送要求は、要求ＩＤ９０１に識別番号を付し、種別９０２を「ライト」とする。さらに、論理ＶＯＬ ＩＤ９０３は、ボリューム管理テーブル５２０を参照し、ライト要求に含まれる仮想ボリュームＩＤに対応する論理ＶＯＬ ＩＤの値とする。論理ＶＯＬ ＡＤ９０４は、アドレス 管理テーブル５２５を参照し、ライト要求に含まれる仮想ＶＯＬ ＡＤに対応する論理ＶＯＬ ＡＤの値とする。キャッシュプールＡＤ９０５は、キャッシュ管理テーブル５３０のライト要求に含まれる仮想ＶＯＬ ＩＤと、仮想ＶＯＬ ＡＤに対応するキャッシュプールＡＤ５３２の値とし、ライトデータを格納するキャッシュプールのアドレスの情報が示される。データハッシュ値９０６は、ライトデータのハッシュ値とする。

ステップＳ１３６で、オンプレミス３０において、ストレージシステム３２０のデータ転送要求処理部３２２１は、ライトデータ転送要求を取得する（Ｓ１３６）。尚、ステップＳ１３５において、データ転送要求は、クラウド２０からオンプレミス３０に送信しても良く、あるいは、データ転送要求部２２２４がデータ転送要求をタスクとしてオンプレ通信処理部２２２５に登録し、ステップＳ１３６において、データ転送要求処理部３２２１が、オンプレ通信処理部２２２５のタスクをポーリングしても良い。

ステップＳ１３７で、要求があるかを判定し、あれば、ステップＳ１３８に進み、なければ、ステップＳ１３６に戻る。

ステップＳ１３８では、ストレージシステム３２０のキャッシュプールＩ／Ｏ処理部３２２２は、ライトデータ転送要求のキャッシュプールＡＤ９０５からデータをリードする。

ステップＳ１３９では、論理ボリュームＩ／Ｏ処理部３２２３がキャッシュプール２４１からリードしたデータを、データ転送要求情報９０の論理ＶＯＬ ＩＤ、論理ＶＯＬ ＡＤに従って、論理ボリューム３２４２に書き込む。

論理ボリューム３２４２へのライトが完了すると、クラウドサーバ２３０に対して転送完了報告を行う（Ｓ１３１０）。尚、転送完了報告は、データ転送完了通知 ９１のデータフォーマットで行う。

クラウドサーバ２３０では、転送完了報告を受領すると（Ｓ１３１１）、ライト要求の送信元である業務サービス２１０やクライアントＰＣ１０１に対しライト完了報告を行い（Ｓ１３１２）、処理を終了する。

以上のライト処理によれば、ストレージシステムは、ライト処理において、クラウド上のキャッシュプールからリードしたデータを論理ボリュームにライトする。つまり、オンプレミスであるストレージシステムの論理ボリュームに対し、クラウド側からの直接ライト処理を行うことない。

信頼性を担保できないクラウド側からのライト処理により、オンプレミスのデータの改変を防止することができるため、クラウドを利用しながら、オンプレミスのデータは、常に、信頼できるデータであることを保証することができる。

＜ライト動作フロー (非同期)＞
図１４は、計算機システム１００におけるライト動作フロー (非同期)の処理手順を示したものである。より詳しくは、図１３に示したライト動作処理手順が同期処理を示したものに対し、図１４は、非同期処理である点が異なる。図１４においても、図１３と同様、左側に示したクラウド２０の処理をクラウドサーバの処理部が実行し、右側に示したオンプレ３０の処理をストレージシステムの処理部が実行する。

同期処理とは、ライト要求を送信した業務サービス２１０等に対するライト完了報告を、ライトデータが論理ボリュームに格納された後に行う処理である。一方、非同期処理とは、ライト要求を送信した業務サービス２１０に対するライト完了報告を、ライトデータを論理ボリュームに格納する前、例えば、ライトデータをキャッシュプール２４１にライトした後や、ライトデータをクラウドサーバ２３０のメモリ２２２に一時的に格納したタイミングで行う処理である。

図１４では、ステップＳ１３３で、キャッシュプール２４１へライトデータを格納した後に、ステップＳ１４１で業務サービス２１０にライト完了報告を行っている例を示している。

以上のライト処理によれば、ストレージシステムは、ライト処理において、クラウド上のキャッシュプールからリードしたデータを論理ボリュームにライトする。つまり、オンプレミスであるストレージシステムの論理ボリュームに対し、クラウド側からのライト処理を行うことなく、論理ボリュームにデータを格納するため、オンプレミスのストレージシステムのデータがクラウド側から直接ライトされることがない。

信頼性を担保できないクラウド側からのライト処理により、オンプレミスのデータの改変を防止することができるため、クラウドを利用しながら、オンプレミスのデータは、常に、信頼できるデータであることを保証することができる。

＜リード動作フロー＞
図１５は、計算機システム１００におけるリード動作処理手順を示したものである。図１５においては、左側に示したクラウド２０の処理をクラウドサーバの処理部が実行し、右側に示したオンプレ３０の処理をストレージシステムの処理部が実行する。図１５は、クラウド２０において、クラウドサーバ２３０のＩ／Ｏ処理部２２２３が処理する仮想ボリュームに対するリード動作処理手順、オンプレミス３０においてストレージシステム３２０のキャッシュプールＩ／Ｏ処理部３２２２および論理ボリュームＩ／Ｏ処理部３２２３の処理手順の一例を示す図である。したがって、クラウド２０側の処理には、ストレージシステム３２０にライト要求を転送するデータ転送要求を行うデータ転送要求部２２２４の処理と、ストレージシステム側でデータ転送処理を受けるデータ転送要求処理部３２２１の処理も含まれる。

クラウドサーバ２３０は、業務サービス２１０等から仮想ボリューム２２６に対し、リード要求を受領する（Ｓ１５１）。尚、リード要求には、データを読み出すために、仮想ボリュームの仮想ＶＯＬ ＩＤと仮想ＶＯＬ ＡＤが含まれている。

クラウドサーバ２３０は、キャッシュ管理テーブル５３０を参照し（Ｓ１５２）、リード要求に含まれる仮想ＶＯＬ ＩＤと仮想ＶＯＬ ＡＤが、キャッシュ管理テーブル５３０に格納されているか、すなわちキャッシュヒットの判定を行う（Ｓ１５３）。キャッシュ管理テーブル５３０に仮想ＶＯＬ ＩＤと仮想ＶＯＬ ＡＤのエントリが格納されていればキャッシュヒットと判定する。キャッシュヒットすればステップＳ１５１０進み、キャッシュヒットしなければステップＳ１５４に進む。

ステップＳ１５４で、キャッシュ管理テーブル５３０の仮想ＶＯＬ ＩＤと仮想ＶＯＬ ＡＤが割り当てられていないキャッシュプールＡＤに対して、リード要求に含まれる仮想ＶＯＬ ＩＤと仮想ＶＯＬ ＡＤを格納し、最終アクセス時間５３５、アクセス頻度５３６を更新する。これにより、キャッシュプールＡＤと仮想ＶＯＬ ＩＤと仮想ＶＯＬ ＡＤとの対応が管理される。

ステップ１５５で、クラウドサーバ２３０のデータ転送要求部２２２４は、キャッシュ管理テーブル５３０の情報に基づいて、リードデータ転送要求を作成する。リードデータ転送要求は、キャッシュ管理テーブルの仮想ＶＯＬ ＩＤと仮想ＶＯＬ ＡＤとボリューム管理テーブル５２０、アドレス管理テーブル５２５に基づいて作成される。リードデータ転送要求は、図１０Ａのデータ転送要求情報９０の種別９０２に「リード」で示した「論理ＶＯＬ ＩＤ」と「論理ＶＯＬ ＡＤ」、「キャッシュプールＡＤ」を含む。キャッシュプールＡＤは、ステップＳ１５４にて、リード要求に含まれる仮想ＶＯＬ ＩＤと仮想ＶＯＬ ＡＤに対応するキャッシュ管理テーブルのキャッシュプールＡＤ５３２の情報である。尚、キャッシュプールが複数の場合には、キャッシュプールを識別する情報も含まれる。作成したリードデータ転送要求は、クラウド２０のクラウドサーバ２３０からオンプレミス３０のストレージシステム３２０に提供される。

ストレージシステム３２０のデータ転送要求処理部３２２１では、クラウドサーバ２３０からリードデータ転送要求を取得する（Ｓ１５６）。データ転送要求処理部３２２１は、リード要求があるか判定し、ある場合にはステップＳ１５８に進む。なければ、ステップＳ１５６に戻る。尚、ステップＳ１５５において、クラウド２０からオンプレミス３０に対して、リードデータ転送要求を送信しても、Ｉ／Ｏ処理部２２２３がＩ／Ｏ処理要求をタスクとしてオンプレ通信処理部２２２５に登録し、ステップＳ１５６において、データ転送要求処理部３２２１が、オンプレ通信処理部２２２５のタスクをポーリングしても良い。

ステップＳ１５８では、ストレージシステム３２０の論理ボリュームＩ／Ｏ処理部３２２３は、リードデータ転送要求の論理ＶＯＬ ＩＤと論理ＶＯＬ ＡＤに従って、データを読み出し、読み出したデータをリードデータ転送要求のキャッシュプールＡＤに、ライトするようライト要求を作成し、クラウドサーバ２３０に送信する（Ｓ１５８）。キャッシュプールが複数の場合には、このライト要求には、キャッシュプールを識別するキャッシュプールＩＤが含まれる必要があることは言うまでもない。

クラウドサーバ２３０では、ストレージシステムからのライト要求を受信し、ライト要求に従って、キャッシュプールにデータをライトする（Ｓ１５９）。このように、クラウドサーバ２３０は、キャッシュプールに格納していないデータをキャッシュプールに格納することで、リード要求に応答することができる。

ステップＳ１５１０では、業務サービス２１０からのリード要求に対し、キャッシュ管理テーブル５３０に基づいて、キャッシュプールからデータを読み出し、要求元の業務サービス２１０に転送する。

以上のように、クラウドサーバ２３０の仮想ボリューム２２６に対するリード要求に対し、キャッシュプール２４１にデータを格納していない場合、ストレージシステムからキャッシュプールにデータをライトすることにより、キャッシュプールにリード対象データを格納する。つまり、クラウドサーバ２３０は、仮想ボリュームのデータの全てをキャッシュプールに格納することなく、リード要求を処理することができる。そのため、クラウド上の容量を削減することができ、従量制課金の費用を抑えることができる。

＜ハッシュ値を用いたライト動作フロー＞
実施例１においては、クラウドサーバ２３０は、業務サービス２１０からライト要求を受領すると、ストレージシステムは、クラウド上のキャッシュプールからデータをリードし、リードしたデータを論理ボリュームにライトする例を示した。実施例２では、さらに、ストレージシステム３２０がデータを論理ボリュームにライトする際に、データの検証を行うことで、よりセキュリティレベルを向上したライト動作フローに関する。

実施例１のライト動作フローとの相違は、ステップＳ１６１－Ｓ１６５である。

つまり、ステップＳ１３３の後、クラウドサーバ２３０のＩ／Ｏ処理部２２２３は、受領したライト要求のライトデータからハッシュ値を算出する（Ｓ１６１）。

次に、キャッシュ管理テーブルにページＩＤ５３１、キャッシュプールＡＤ５３２、仮想ＶＯＬ ＩＤ５３３、仮想ＶＯＬ ＡＤ５３４、最終アクセス時間５３５、アクセス頻度５３６の他、ステップＳ１６１で計算したハッシュ値５３７を格納する（Ｓ１６２）。

次に、ステップＳ１６３で、ライトデータ転送要求にハッシュ値を含めて、ライトデータ転送要求を作成する。

ストレージシステムでは、ステップＳ１３６－１３８は、実施例１と同様の処理を行い、ステップＳ１６４で、キャッシュプール２４１から読み出したデータのハッシュ値を計算する。

ステップＳ１６５で、ステップＳ１６３で算出したハッシュ値と、ステップＳ１６４で算出したハッシュ値とを比較する。

ハッシュ値が一致していれば、ステップＳ１３９に進み、一致しなければライト処理を終了する。一致しない場合、エラーを通知しても良い。

一致していれば、ストレージシステムの論理ボリュームにライトデータ転送要求に従って、ライトデータを格納する（Ｓ１３９）。

尚、図１６のライト動作は、同期処理のライト動作を示したが、非同期処理のライト動作にも適応できる。

以上の通り、実施例２では、実施例１のオンプレミスのストレージシステムのデータがクラウド側から直接ライトされることがないことに加え、ストレージシステムの論理ボリュームにデータを格納する前に、クラウドから受け取ったライトデータと、クラウド上に格納されているライトデータが一致するかを確認した後で、オンプレミス側のストレージシステムの論理ボリュームにデータを格納することができる。

これにより、クラウド側から受信するライトデータが改変されている場合、あるいは、キャッシュプール上のデータが改変されている場合には、オンプレミスの論理ボリュームにデータをライトされることがなく、オンプレミスのデータの改変を防止することができる。

信頼性を担保できないクラウド側からのライト処理により、オンプレミスのデータの改変を防止することができるため、クラウドを利用しながら、オンプレミスのデータは、常に、信頼できるデータであることを保証することができる。

クラウドとオンプレミスを用いる計算機システムでは、クラウドの機能を利用可能で、オンプレミスには信頼できる全データを保存したいという要求がある。つまり、クラウドのボリュームを外部からアクセス可能とし、クラウドからオンプレミスのボリュームに直接書き込む構成であっても、オンプレミスのボリュームのセキュリティを向上することができる。そのため、オンプレミスに信頼できる全データを保存しながら、クラウドの仮想ボリュームに対するデータライトを伴うデータ解析を行うことができる。

１０：顧客拠点
１００：計算機システム
１０１：クライアントＰＣ
２０：パブリッククラウド
２１０：業務サービス
２１１：ＣＰＵ
２１２：メモリ
２２０：仮想ボリュームサービス
２２１：ＣＰＵ
２２２：メモリ
２２２１:キャッシュプール管理部
２２２２：仮想ボリューム作成部
２２２３：Ｉ／Ｏ処理部
２２２４：データ転送要求部
２２２５：オンプレ通信処理部
２２６：仮想ボリューム
２４１：ストレージボリューム（キャッシュプール）
２３０：クラウドサービス
３０：顧客データセンタ
３１０：業務サーバ
３２０：ストレージシステム
３２１：ＣＰＵ
３２２：メモリ
３２２１：データ転送要求処理部
３２２２：キャッシュプールＩ／Ｏ処理部
３２２３：論理ボリュームＩ／Ｏ処理部
３２２４：論理ボリューム管理部
３２４２：論理ボリューム
４０：ネットワーク

Claims (11)

1. 業務サービスに対し、データ記憶領域として提供される仮想ボリュームと、
   前記仮想ボリュームに格納されるデータの一部を格納する、複数のページを有するキャッシュプールと、
   前記キャッシュプールのページ毎に、前記仮想ボリュームへの割り当てを管理するキャッシュ管理情報を格納する記憶部と、
   処理部と、を有し、
   前記処理部は、
   前記仮想ボリュームに対し、ライト要求を受領すると、ライト要求のライトデータを前記キャッシュプールに格納し、
   前記記憶部のキャッシュ管理情報を、ライトデータが格納された前記キャッシュプールのアドレスに基づいて、更新し、
   更新されたキャッシュ管理情報に基づいて、作成されるライトデータ転送要求を、前記仮想ボリュームに対応する論理ボリュームを有するストレージシステムに提供するものであり、
   前記仮想ボリュームに対するリード要求に含まれる前記仮想ボリュームのアドレスが前記キャッシュ管理情報に格納されていなければ、リード要求に基づいて前記キャッシュ管理情報を更新し、
   更新されたキャッシュ管理情報に基づいて、リードデータ転送要求を作成して前記ストレージシステムに提供し、
   前記ストレージシステムが前記リードデータ転送要求に基づいて作成するライト要求に従って、前記キャッシュプールにデータを書込み、
   前記キャッシュプールにライトされたデータをリードする、ことを特徴とするクラウドサーバ。
   することを特徴とするクラウドサーバ。
2. 請求項１に記載のクラウドサーバにおいて、
   前記記憶部は、
   前記キャッシュ管理情報を、前記キャッシュプールのページ毎に、前記仮想ボリュームの識別情報、前記仮想ボリュームのアドレス情報と、を対応付けて記憶すること特徴とするクラウドサーバ。
3. 請求項２に記載のクラウドサーバにおいて、
   前記記憶部は、
   前記仮想ボリュームのアドレスと、前記論理ボリュームのアドレスとの対応関係を管理するアドレス管理情報を記憶し、
   前記ライトデータ転送要求に、ライト要求のライトデータを格納する前記キャッシュプールのアドレスに加え、前記アドレス管理情報に基づいて、ライト要求に含まれる前記仮想ボリュームのアドレスから特定される前記論理ボリュームのアドレスを加えて、前記ストレージシステムに提供することを特徴とするクラウドサーバ。
4. 請求項３に記載のクラウドサーバにおいて、
   前記処理部は、
   前記仮想ボリュームに対するリード要求を受領すると、リード要求に含まれる前記仮想ボリュームのアドレスが前記キャッシュ管理情報に格納されていれば、前記キャッシュ管理情報に従って前記キャッシュプールからデータをリードすることを特徴とするクラウドサーバ。
5. 業務サービスに対し、データ記憶領域として提供される仮想ボリュームと、前記仮想ボリュームに格納されるデータの一部を格納する、複数のページを有するキャッシュプールと、前記キャッシュプールのページ毎に、前記仮想ボリュームへの割り当てを管理するキャッシュ管理情報を格納するクラウドシステムと接続されるストレージシステムであって、
   前記ストレージシステムは、
   データを格納する記憶装置と、
   前記記憶装置を用いて、前記仮想ボリュームに対応する論理ボリュームを作成する処理部と、を有し、
   前記処理部は、
   前記クラウドシステムから、ライトデータ転送要求を受領し、
   ライトデータ転送要求に従って、前記キャッシュプールからデータをリードし、
   前記キャッシュプールからリードしたデータを、ライトデータ転送要求に従って、前記論理ボリュームに格納するものであり、
   前記クラウドシステムから、ライトデータの第１のハッシュ値を含むライトデータ転送要求を受領し、
   ライトデータ転送要求に従って、前記キャッシュプールからデータをリードし、
   前記キャッシュプールからリードしたデータから第２のハッシュ値を生成し、
   前記第１のハッシュ値と前記第２のハッシュ値が一致する場合、ライトデータ転送要求に従って、前記論理ボリュームに格納することを特徴とするストレージシステム。
   することを特徴とするストレージシステム。
6. 請求項５に記載のストレージシステムにおいて、
   前記ライトデータ転送要求は、ライトデータを格納する前記キャッシュプールのアドレスに加え、前記論理ボリュームにライトデータを格納するアドレスを含む、ことを特徴とするストレージシステム。
7. 業務サービスに対し、データ記憶領域として提供される仮想ボリュームと有するクラウドサーバと、
   前記仮想ボリュームに対応する論理ボリュームを有するストレージシステムと、を有し、
   前記クラウドサーバは、
   前記仮想ボリュームに格納されるデータの一部を格納する、複数のページを有するキャッシュプールと、
   前記キャッシュプールのページ毎に、前記仮想ボリュームへの割り当てを管理するキャッシュ管理情報を格納する記憶部と、を有し、
   前記仮想ボリュームに対し、ライト要求を受領すると、ライト要求のライトデータを前記キャッシュプールに格納し、
   キャッシュ管理情報を、ライトデータが格納された前記キャッシュプールのアドレスと、ライト要求に含まれる前記仮想ボリュームのアドレスに基づいて、更新し、
   更新されたキャッシュ管理情報に基づいて作成されるライトデータ転送要求を、前記ストレージシステムに提供し、
   前記ストレージシステムは、
   ライトデータ転送要求に従って、前記キャッシュプールからライト要求のライトデータをリードし、
   リードしたライトデータを、前記論理ボリュームにライトするものであり、
   前記クラウドサーバは、
   前記仮想ボリュームに対するリード要求に含まれる前記仮想ボリュームのアドレスが前記キャッシュ管理情報に格納されていなければ、リード要求に基づいて前記キャッシュ管理情報を更新し、
   更新されたキャッシュ管理情報に基づいて、リードデータ転送要求を作成して前記ストレージシステムに提供し、
   前記ストレージシステムは、
   リードデータ転送要求に従って、前記論理ボリュームからデータをリードし、リードしたデータを前記キャッシュプールに書き込むライト要求を前記クラウドサーバに送信し、
   前記クラウドサーバは、
   前記ストレージシステムから前記ライト要求に従って、前記キャッシュプールにデータを書込み、
   前記キャッシュプールにライトされたデータをリードする、
   ことを特徴とする計算機システム。
   することを特徴とする計算機システム。
8. 請求項７に記載の計算機システムにおいて、
   前記クラウドサーバは、
   前記キャッシュ管理情報を、前記キャッシュプールのページ毎に、前記仮想ボリュームの識別情報と、前記仮想ボリュームのアドレス情報と、を対応付けて管理すること特徴とする計算機システム。
9. 請求項８に記載の計算機システムにおいて、
   前記クラウドサーバは、
   前記仮想ボリュームと前記論理ボリュームのアドレスの対応関係を管理するアドレス管理情報を有し、
   前記ライトデータ転送要求は、ライト要求のライトデータを格納する前記キャッシュプールのアドレスに加え、前記アドレス管理情報に基づいてライト要求に含まれる前記仮想ボリュームのアドレスから特定される前記論理ボリュームのアドレスを含む、ことを特徴とする計算機システム。
10. 請求項９に記載の計算機システムにおいて、
    前記クラウドサーバは、
    前記仮想ボリュームに対するリード要求を受領すると、リード要求に含まれる前記仮想ボリュームのアドレスが前記キャッシュ管理情報に格納されていれば、前記キャッシュ管理情報に従って前記キャッシュプールからデータをリードすることを特徴とする計算機システム。
11. 請求項７に記載の計算機システムにおいて、
    前記クラウドサーバは、
    前記仮想ボリュームに対し、ライト要求を受領すると、ライトデータから第１のハッシュ値を生成し、
    前記第１のハッシュ値を含むライトデータ転送要求を前記ストレージシステムに提供し、
    前記ストレージシステムは、
    ライトデータ転送要求に従って、前記キャッシュプールからデータをリードし、
    前記キャッシュプールからリードしたデータから第２のハッシュ値を生成し、
    前記第１のハッシュ値と前記第２のハッシュ値が一致する場合、ライトデータ転送要求に従って、前記論理ボリュームにライトデータを格納することを特徴とする計算機システ
    ム。

Images