JP2018129074A - ストレージシステム、計算機システム、およびストレージシステムの制御方法 - Google Patents

Abstract

【課題】オンプレミスのストレージ装置の容量の節約と、オンプレミスのストレージ装置の高アクセス性能と、オンプレミスのリソースに障害があったとき、クラウド上のデータを用いて、高速かつ正確に業務を再開することとを実現する。【解決手段】プロセッサは、仮想ボリュームである第一ボリュームを提供し、第一ボリュームと、他のストレージシステムにより提供される第二ボリュームとのコピーペアを設定する。第一ボリュームへのライトデータは、コピーペアに基づいて、ネットワークを介して第二ボリュームへ転送される。プロセッサは、第二ボリュームへ書き込まれるデータの一部をメモリへ書き込み、メモリへ書き込まれたデータを記憶デバイスへ書き込む。【選択図】図１

Description

本発明は、ストレージシステムに関する。

大規模なデータを扱う計算機システムは、ホスト計算機とは別個に設けられた大容量のストレージシステム（例えばクラウドストレージ）を用いてデータを管理している。クラウドストレージの活用形態の一つとして、顧客のデータセンタ（以後、オンプレミスと呼ぶ）に配置されているストレージがクラウドストレージへのデータの格納を制御するものがある。すなわち、ホスト計算機はクラウドストレージを意識しない。

更に、クラウド上の計算機や仮想マシンがクラウド上に格納されるデータを用いて業務を実行する場合もある。これにより、データの分析処理のように、一度に大量のリソースを使う業務を、低コストで実現できる。

特許文献１は、オンプレミスのストレージのデータの複製をクラウドに格納する技術を開示している。オンプレミスとクラウドの差分データを定期的にクラウドに格納する。また、この技術は、クラウドへの格納において、オンプレミス側で圧縮、暗号化などを行い、オンプレミスのストレージによって認識されるデータ構造を採用している。また、複数のクラウドにデータを格納することができる。

また、ストレージにおいて記憶デバイスを仮想化するデバイス仮想化機能（外部ストレージ接続機能）が知られている。デバイス仮想化機能は、外部ストレージの記憶デバイスを上位ストレージにマッピングし、上位ストレージのデータとしてホストへ提供する機能である。

米国特許出願公開第２０１４／０２４５０２６号明細書

特許文献１の技術は、オンプレミスのストレージに格納されるデータのコピーをバックアップとしてクラウドに格納する。このため、オンプレミスストレージのデータ量を削減による低コスト化を実現することはできない。

又、特許文献１の技術では、クラウド上のデータを用いて、クラウド側での業務の実行を前提としておらず、例えばクラウド上の仮想マシンから認識可能なデータ構造を採用していないためクラウド上の仮想マシンによる業務再開ができない。

さらに、オンプレミスのストレージからクラウドのストレージへ定期的に差分データのみを転送するため、障害時にクラウドストレージ側に反映されていないデータは失われる可能性がある。

一方、上述のデバイス仮想化機能を用いて、クラウド上のストレージを外部ストレージとしてオンプレのストレージにマッピングすることで、オンプレミスの容量を削減することができる。しかし、ホスト計算機から発行される全てのＩ／Ｏ処理のためにクラウド側へのアクセスが生じるために性能が著しく低下してしまう。

上記課題を解決するために、本発明の一態様であるストレージシステムは、ネットワークを介して他のストレージシステムに接続されるストレージシステムであって、メモリと、前記メモリに記憶されるプログラムを実行するプロセッサと、記憶デバイスと、を備える。前記プログラムの実行により前記プロセッサは、仮想ボリュームである第一ボリュームを提供し、前記プロセッサは、前記第一ボリュームと、前記他のストレージシステムにより提供される第二ボリュームとのコピーペアを設定し、前記第一ボリュームへのライトデータは、前記コピーペアに基づいて、前記ネットワークを介して前記第二ボリュームへ転送され、前記プロセッサは、前記第二ボリュームへ転送されるデータの一部を前記メモリへ書き込み、前記メモリへ書き込まれたデータを前記記憶デバイスへ書き込む。

オンプレミスのストレージ装置の容量の節約と、オンプレミスのストレージ装置の高アクセス性能と、オンプレミスのリソースに障害があったとき、クラウド上のデータを用いて、高速かつ正確に業務を再開することとを実現することができる。

実施例１に係る計算機システムの構成を示す。 ストレージシステム２００の構成を示す。 メモリユニット２２０の詳細の一例を示す。 仮想ボリューム２９３、容量プール２９０、プールボリューム２９１の関係を説明する図である。 プールテーブル２２４の一例を示す。 仮想ボリュームテーブル２２５の一例を示す。 キャッシュ管理テーブル２２６の一例を示す。 実施例１に係るライトプログラムのフローチャートの一例である。 実施例１に係るリードプログラムのフローチャートの一例である。 実施例１に係るデステージプログラム５１６のフローチャートの一例である。 実施例１に係るティアリングプログラムのフローチャートの一例である。 実施例１に係るデモーションプログラムのフローチャートの一例である。 実施例１に係るプロモーションプログラムのフローチャートの一例である。 実施例２に係る計算機システムの構成を示す。 非同期リモートコピーの一例を示す。 実施例２に係るライトプログラムのフローチャートの一例である。 実施例２に係るリードジャーナルプログラムのフローチャートの一例である。 実施例２に係るジャーナル転送プログラムのフローチャートの一例である。 実施例２に係るリストアプログラムのフローチャートの一例である。 実施例２に係るキャッシュパージプログラムのフローチャートの一例である。 実施例３に係る計算機システムの構成を示す。

以下、図面を参照して本発明の実施形態を説明する。

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

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

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

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

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

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

以下、実施例１の計算機システムの構成について説明する。

図１は、実施例１に係る計算機システムの構成を示す。

本実施例の計算機システムは、オンプレミス１０と、クラウド２０とを含む。オンプレミス１０とクラウド２０は、ネットワーク３０を介して接続されている。

オンプレミス１０は、ストレージシステム２００と、当該ストレージシステムにデータを保存するホスト１００とを含む。ホスト１００は、本番業務１１０を実行する。当該業務で使用されるデータがストレージシステム２００に格納される。ホスト１００とストレージシステム２００はネットワーク１２０で接続されている。ストレージシステム２００は、ストレージ装置と呼ばれることがある。

クラウド２０は、ストレージを提供するための仮想マシン３００（以後、ストレージ仮想マシンまたはストレージＶＭと呼ぶ）と、当該ストレージにアクセスするためのホスト仮想マシン４００（以後、ホストＶＭ）とを実行する。ホストＶＭ４００は、ホスト１００の業務と別の業務や、災害後にホスト１００の業務を引き継ぐＶＭである。ホストＶＭ４００の業務は、例えば、ストレージＶＭ３００によりクラウド２０内に格納されたデータの分析業務４１０である。なお、ストレージＶＭ３００は、物理的なストレージ装置や計算機、ストレージ機能を提供するコンテナであってもよい。ホストＶＭ４００は、物理的な計算機、コンテナであってもよい。ストレージＶＭ３００によって分析業務４１０などが実行されてもよい。すなわち、ストレージＶＭ３００とホストＶＭ４００が同一のＶＭであってもよい。

ストレージシステム２００は、物理記憶デバイスを用いて、仮想ボリューム２９３と容量プール２９０を作成する。容量プール２９０は、ストレージシステム２００に搭載されているＨＤＤ（Hard Disk Drive）などの物理記憶デバイスに対応付けられ、物理的な容量を有する。仮想ボリューム２９３は、仮想的なストレージ領域であるが、通常のボリュームと同等にホスト１００に提供される記憶領域である。ホスト１００は、仮想ボリューム２９３を、通常のボリュームと同等に扱うことができる。ストレージシステム２００は、ホスト１００から仮想ボリューム２９３へのライト要求を受け付けた時、容量プール２９０から領域を確保し、ライト要求に示されたアドレスと関連付ける。ライトデータ自体は、容量プール２９０に格納される。本実施例で、仮想ボリューム２９３にデータを格納するとは、仮想ボリューム２９３のデータとしてストレージシステム２００内のキャッシュにデータを格納すること、または、仮想ボリューム２９３に対応する容量プール２９０にデータを格納することを意味する。物理記憶デバイスを、記憶デバイスと呼ぶことがある。

本実施例の仮想ボリューム２９３に格納されるデータは、少なくともアクセス頻度が高いＨｏｔ Ｄａｔａおよびアクセス頻度がＨｏｔ Ｄａｔａより低いＣｏｌｄ Ｄａｔａとに分類される。その判断は例えば各データのアクセス頻度から判断する。ホスト１００に対してはＨｏｔ ＤａｔａおよびＣｏｌｄ Ｄａｔａが仮想ボリューム２９３を介して提供されているが、物理的にはＨｏｔ Ｄａｔａのみがストレージシステム２００の容量プール２９０に格納される。図の例では、Ｃｏｌｄ Ｄａｔａはクラウド２０上のストレージに格納される。つまり、クラウド上のボリューム３１０を仮想ボリューム２９３にマッピングすることで、クラウド上のストレージ領域を、オンプレミスのストレージの領域としてホスト計算機に提供している。当然、ホスト１００は、仮想ボリューム２９３へのアクセス要求によってＣｏｌｄ Ｄａｔａにもアクセスすることができる。Ｃｏｌｄ Ｄａｔａへのアクセス要求を受領したストレージシステム２００はネットワーク３０を介してクラウド２０内のＣｏｌｄ Ｄａｔａへアクセスし、ホスト１００へＣｏｌｄ Ｄａｔａを転送する。

ストレージシステム２００は、クラウド２０のストレージＶＭ３００とネットワーク３０で接続されている。Ｃｏｌｄ ＤａｔａはストレージＶＭ３００に格納される。

次に、クラウド２０のストレージＶＭ３００について説明する。ストレージＶＭ３００はクラウド２０上のＶＭまたはハイパーバイザーであり、ストレージの処理を実行するためのプログラムがインストールされている。

ストレージＶＭ３００は、クラウド２０内の物理記憶デバイスを用いてボリューム３１０を作成する。ストレージＶＭ３００は、仮想ボリューム２９３とボリューム３１０をペア関係４０（コピーペア）によって関連付ける。ストレージシステム２００およびストレージＶＭ３００の両方がペア関係を管理する。ボリューム３１０にはＨｏｔ ＤａｔａおよびＣｏｌｄ Ｄａｔａの両方が格納される。ボリューム３１０内のＨｏｔ Ｄａｔａは、仮想ボリューム２９３内のＨｏｔ Ｄａｔａの複製である。ボリューム３１０内のＣｏｌｄ Ｄａｔａは、仮想ボリューム２９３内のＣｏｌｄ Ｄａｔａに対応する。

また、図の例では、ストレージＶＭ３００は、仮想ボリュームではなく通常のボリューム３１０を作成する。なお、ストレージＶＭ３００のボリューム３１０も仮想ボリュームであってもよい。すなわち、ストレージＶＭ３００もストレージシステム２００と同様に、容量プールを有し、当該容量プールにＨｏｔ ＤａｔａとＣｏｌｄ Ｄａｔａの両方が格納されてもよい。この場合、ストレージＶＭ３００の仮想ボリュームは、容量プールのＨｏｔ ＤａｔａとＣｏｌｄ Ｄａｔａに対応する。

計算機システム全体としては、Ｈｏｔ Ｄａｔａはストレージシステム２００とストレージＶＭ３００の両方に格納され、Ｃｏｌｄ ＤａｔａはストレージＶＭ３００のみに格納される。

Ｃｏｌｄ Ｄａｔａはアクセス頻度の低いデータである。このため、この構成によれば、本番業務１１０の性能を維持しつつ、Ｃｏｌｄ Ｄａｔａをクラウド２０へ格納することによりコストを削減できる。また、クラウド２０にＨｏｔ ＤａｔａおよびＣｏｌｄ Ｄａｔａの両方を格納することにより、迅速にクラウド２０で別業務を実行することができ、災害時に業務を復旧することができる。

図２は、ストレージシステム２００の構成を示す。

ストレージシステム２００は、１以上のマイクロプロセッサパッケージ（ＭＰＰＫ）２１０と、メモリユニット２２０と、バックエンドパッケージ（ＢＥパッケージ）２３０と、フロントエンドパッケージ（ＦＥパッケージ）２６０とを有する。ＭＰＰＫ２１０と、メモリユニット２２０と、ＢＥパッケージ２３０と、ＦＥパッケージ２６０とは、内部バス２８０を介して互いに接続されており、コントローラと呼ばれることがある。メモリユニット２２０は、メモリと呼ばれることがある。

ＦＥパッケージ２６０は、ポート２６１と、メモリ２６２とを有する。ポート２６１は、ネットワーク１２０を介して、ホスト１００と接続され、ホスト１００との間の通信を仲介する。さらに、ポート２６１は、ネットワーク３０を介して、ストレージＶＭ３００と接続され、ストレージＶＭ３００との間の通信を仲介する。本実施例では、ホスト１００とストレージＶＭ３００は、異なるポート２６１に接続されているが、スイッチなどを用いて同一のポート２６１に接続されてもよい。メモリ２６２は、ＦＥパッケージ２６０の処理に必要な各種データを記憶する。たとえば、メモリ２６２は、ホスト１００から転送されたデータや、ホスト１００へ転送するデータを一時的に格納するために使用される。メモリ２６２は、同様にストレージＶＭ３００へ転送するデータやストレージＶＭ３００から転送されたデータを格納するためにも使用され得る。

メモリユニット２２０は、例えば、１以上のメモリデバイスにより構成され、制御情報を記憶する制御情報部２２１と、プログラムを記憶するプログラム部２２２と、データをキャッシュするキャッシュメモリの一例としてのキャッシュ部２２３とを有する。なお、キャッシュ部２２３の容量は、一般的には、ボリューム２５０の容量よりも小さくなっている。キャッシュ部２２３を、キャッシュやキャッシュメモリと呼ぶことがある。

ＭＰＰＫ２１０は、プロセッサ２１１と、ローカルメモリ２１２と、保守ポート２１３とを有する。プロセッサ２１１と、ローカルメモリ２１２と、保守ポート２１３とは、内部バス２１４を介して接続されている。ローカルメモリ２１２は、ＭＰＰＫ２１０において必要な各種データを記憶する。保守ポート２１３は、保守端末２７０との通信を仲介する。プロセッサ２１１は、各種処理を実行する。プロセッサ２１１は、メモリユニット２２０のプログラム部２２２に格納された各種プログラムを実行することにより各種処理を実行する。また、プロセッサ２１１は、メモリユニット２２０の制御情報部２２１に格納されている各種情報を用いて各種処理を実行する。

ＢＥパッケージ２３０は、ポート２３１と、メモリ２３２とを有する。ポート２３１は、１以上の物理記憶デバイス２４０の一例としてのＨＤＤに、バス２８３を介して接続されている。例えば、データを管理するボリューム２５０には、１以上の物理記憶デバイス２４０内の記憶領域が割り当てられる。なお、物理記憶デバイスとしては、ＨＤＤに限らず、例えば、ＳＳＤ（Solid State Drive）、ＤＶＤ、ＳＣＭ（Storage Class Memory）などであってもよい。また、１つ以上の物理記憶デバイス２４０をパリティグループという単位でまとめて、ＲＡＩＤ（Redundant Arrays of Independent Disks）のような高信頼化技術を使用してもよい。

ストレージシステム２００には、例えば、バス２８０を介して、ストレージシステム２００を保守するための保守端末２７０が接続される。保守端末２７０は、ＣＰＵ２７１と、メモリ２７２と、入出力部２７４と、保守ポート２７５とを有する。メモリ２７２は、保守用のプログラム（保守プログラム）２７３を記憶する。ＣＰＵ２７１は、保守プログラム２７３を実行することにより保守処理を実行する。入出力部２７４は、例えば、マウス、キーボード、ディスプレイ等により構成され、保守を行うオペレータによる各種指示入力を受け付けるとともに、各種情報をディスプレイに表示させる。保守ポート２７５は、ストレージシステム２００との間の通信を仲介する。計算機システムは、保守端末２７０の代わりに、ネットワークを介してストレージシステムに接続される管理サーバを含んでもよい。

なお、本実施例のストレージシステム２００は、一般的なサーバなどにストレージの処理を実行するためのプログラムをインストールしたものであってもよい。ストレージの処理とは、リード要求やライト要求、上述したＲＡＩＤなどを制御する処理である。

ストレージＶＭ３００の構成について説明する。クラウド２０は、少なくとも一つの計算機を含む。計算機の代わりにストレージシステム２００と同様のシステムが用いられてもよい。計算機は、プロセッサと、プロセッサに接続されるメモリと、プロセッサに接続される物理記憶デバイスとを含む。プロセッサは、ストレージＶＭ３００やホストＶＭ４００を実行する。ストレージＶＭ３００は、ストレージシステム２００の構成と同様の構成を有している。一般的に、クラウドベンダが提供するＶＭはプロセッサ資源、メモリ資源、通信用ポートを含んでいる。また、ストレージＶＭ３００の機能はサービスとして提供される可能性があるが、ホストＶＭ４００に対して関連付けられ、ホストＶＭ４００の記憶デバイスとして使用できる。すなわち、バックエンドパッケージおよびＨＤＤがストレージサービスに置き換えられる。また、ストレージＶＭ３００やホストＶＭ４００等のＶＭの各種資源は、仮想的に提供される可能性がある。

図３は、メモリユニット２２０の詳細の一例を示す。

メモリユニット２２０の制御情報部２２１には、プールテーブル２２４、仮想ボリュームテーブル２２５、キャッシュ管理テーブル２２６、ペアテーブル２２７が格納される。ペアテーブル２２７の詳細については、公知のリモートコピーシステムにおいてペアを管理するテーブルと同様であるため、省略する。

メモリユニット２２０のプログラム部２２２には、ティアリングプログラム５１１、プロモーションプログラム５１２、デモーションプログラム５１３、リードプログラム５１４、ライトプログラム５１５、デステージプログラム５１６、ジャーナル転送プログラム５２１、キャッシュパージプログラム５２２が格納されている。なお、実施例１のプログラム部２２２は、ジャーナル転送プログラム５２１、キャッシュパージプログラム５２２を格納しなくてもよい。

図４は、仮想ボリューム２９３、容量プール２９０、プールボリューム２９１の関係を説明する図である。

ストレージシステム２００は、複数の物理記憶デバイス２４０の物理記憶領域からプールボリューム２９１を作成する。容量プール２９０は、一つ以上のプールボリューム２９１を含む。プールボリューム２９１には、仮想ボリューム２９３への割当単位となる物理記憶領域であるページ２９２が含まれる。ページ２９２の容量は、例えば、数ＫＢ〜数十ＭＢである。

仮想ボリューム２９３内の仮想記憶領域に対して、データの書き込みがあると、ストレージシステム２００は、その仮想記憶領域に対して、プールボリューム２９１内のページ２９２を割当てる。すなわち、仮想ボリューム２９３の使用されていない領域については、ページ２９２が割り当てられていないので、物理記憶デバイス２４０の物理記憶領域は消費されない。

図５は、プールテーブル２２４の一例を示す。

プールテーブル２２４は、容量プール２９０における各ページ２９２を管理するテーブルであり、例えば、メモリユニット２２０の制御情報部２２１に格納される。

プールテーブル２２４は、ページ番号２２４ａと、開始アドレス２２４ｂと、終了アドレス２２４ｃと、状態２２４ｄと、割当先２２４ｅとのフィールドを対応付けたレコード（エントリ）を管理する。ページ番号２２４ａには、容量プール２９０におけるページ２９２を識別するページ番号を格納する。ページ２９２の領域を識別するために、開始アドレス２２４ｂと終了アドレス２２４ｃが用いられる。このアドレスは、容量プール２９０全体を管理するアドレスである。当然、ページ２９２の領域は、プールボリューム番号およびプールボリューム内アドレスによって管理されてもよい。ページサイズが固定長であれば、終了アドレス２２４ｃを必要としない。

開始アドレス２２４ｂには、対応するページ２９２の開始アドレスが格納される。終了アドレス２２４ｃには、対応するページ２９２の終了アドレスが格納される。状態２２４ｄには、対応するページ２９２が仮想ボリューム２９３に割当て済みか、未割当てかを示す情報が格納される。割当先２２４ｅには、対応するページ２９２が割当てられた仮想ボリューム番号が格納される。プールテーブル２２４の一番上のレコードによると、ページ番号が“１”であるページは、開始アドレスが“０”であり、終了アドレスが“９９”であり、仮想ボリューム番号が“１”である仮想ボリュームに割当て済みであることがわかる。未割当のページ番号を管理するテーブルなどを有してもよい。その場合、高速に未割当ページを検索することが可能となる。

図６は、仮想ボリュームテーブル２２５の一例を示す。

仮想ボリュームテーブル２２５は、仮想ボリューム２９３に対するページ２９２の割当てを管理するテーブルであり、例えば、メモリユニット２２０の制御情報部２２１に格納される。

仮想ボリュームテーブル２２５は、仮想ボリューム番号２２５ａと、アドレス２２５ｂと、ページ割当て状態２２５ｃと、ページ番号２２５ｄと、リード頻度（回／ｈｒ）２２５ｅと、ライト頻度（回／ｈｒ）２２５ｆのフィールドを含むレコードを管理する。仮想ボリューム２９３内のアドレス範囲は、ページ２９２と同じ大きさの仮想記憶領域に分割されている。一つのレコードは、一つの仮想記憶領域を示す。この仮想記憶領域は、仮想ページとも呼ばれてもよい。

仮想ボリューム番号２２５ａには、仮想ボリューム２９３を識別する仮想ボリューム番号が格納される。アドレス２２５ｂには、対応する仮想ボリューム２９３内のアドレスの範囲が格納される。ページ割当て状態２２５ｃには、対応するアドレスの範囲で示された仮想記憶領域に対してページが割当て済みか否かを示す情報が格納される。ここで、仮想記憶領域に割り当てられるページは、容量プール２９０内のページ２９２に対応する場合と、容量プール２９０内のページ２９２に対応しない場合とがある。ページ番号２２５ｄには、当該仮想記憶領域に割当てられたページのページ番号、または当該仮想記憶領域に割当てられたページが容量プール２９０内のページ２９２に対応しないことを示す識別子が格納される。当該仮想記憶領域に格納されるデータがＨｏｔ Ｄａｔａである場合、そのデータは物理的には容量プール２９０に格納されている。当該仮想記憶領域に格納されるデータがＣｏｌｄ Ｄａｔａである場合、そのデータは物理的には容量プール２９０に格納されておらず、クラウド２０のボリューム３１０に格納されている。この場合、ページ番号２２５ｄには、容量プール２９０内のページ２９２ではなく、クラウド２０を示す情報、例えば“Ｃｌｏｕｄ”が格納されるものとする。

リード頻度（回／ｈｒ）２２５ｅは、対応する領域に対して、単位時間あたりに発行されたリードの回数が格納される。ライト頻度（回／ｈｒ）２２５ｆは、対応する領域に対して、単位時間あたりに発行されたライトの回数が格納される。本例では、単位時間を１時間としたが、１日でも、１分でも、１秒でもよい。ストレージシステム２００は、各仮想記憶領域のアクセス頻度（リード頻度およびライト頻度）を測定し、仮想ボリュームテーブル２２５を更新する。

仮想ボリュームテーブル２２５の一番上のレコードによると、仮想ボリューム番号が“１”の仮想ボリュームの０〜９９のアドレスの領域には、ページ番号“２”のページ２９２が割当てられており、リード頻度、ライト頻度が他のアドレスに比べて高いことがわかる。

図７は、キャッシュ管理テーブル２２６の一例を示す。

キャッシュ管理テーブル２２６は、ボリューム番号２２６ａ、ボリュームアドレス２２６ｂ、キャッシュアドレス２２６ｃ、ダーティ２２６ｄ、常駐Ｂｉｔ２２６ｅ、最大ＳＥＱ ＩＤ２２６ｆのフィールドを有するレコードを管理する。本実施例におけるキャッシュ管理テーブル２２６は、常駐Ｂｉｔ２２６ｅ、最大ＳＥＱ ＩＤ２２６ｆを含まなくてもよい。

ボリューム番号２２６ａは、ボリュームの識別番号である。ボリュームアドレス２２６ｂはボリューム番号によって識別されるボリュームのアドレスを管理している。キャッシュアドレス２２６ｃは、ボリュームアドレスによって特定される領域のキャッシュデータが格納されているキャッシュ部のアドレスを管理する。ダーティ２２６ｄは、キャッシュされているデータがダーティキャッシュであるかクリーンキャッシュであるかを管理している。“ＯＮ”はダーティ、“ＯＦＦ”はクリーンを意味する。常駐Ｂｉｔ２２６ｅ、最大ＳＥＱ ＩＤ２２６ｆについては、実施例２で説明する。ダーティとはキャッシュには書き込まれているが、ＨＤＤに書き込まれていないキャッシュデータのことである。ライト要求によってダーティキャッシュが発生する。一方、クリーンとは、キャッシュのデータとＨＤＤのデータが一致していることを意味する。リード要求によってクリーンキャッシュが発生する。

ストレージシステム２００は、キャッシュされていない領域に対してライトデータまたはリードデータをキャッシュに格納すると、キャッシュ管理テーブル２２６の一つのレコードを作成する。キャッシュ領域が解放された時に、対象となるレコードが削除される。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

以下、各プログラムの動作について説明する。

図８は、実施例１に係るライトプログラムのフローチャートの一例である。

ライトプログラム５１５は、ホスト１００から仮想ボリューム２９３へのライト要求を受領し、ライトデータをストレージシステム２００内のボリュームに格納する。

最初に、ライトプログラム５１５はホスト１００からライト要求を受領する（Ｓ１０００）。ライト要求は、ライトデータ、ライト対象ボリューム番号（本実施例の場合、仮想ボリューム番号）、ライトアドレス、ライト長などの情報を含む。

次に、ライトプログラム５１５は、仮想ボリュームテーブル２２５にアクセスし、ライト対象アドレスに、ページ２９２が割り当てられているか否かを判定する（Ｓ１００１）。ページ２９２が割り当てられている場合、ライトプログラム５１５は、Ｓ１００２へ進む。ページ２９２が割り当てられていない場合、ライトプログラム５１５は、Ｓ１００３へ進む。

Ｓ１００２で、ライトプログラム５１５は、仮想ボリュームテーブル２２５のページ番号の値をチェックし、ページ２９２がオンプレミス１０のストレージシステム２００か、クラウド２０のストレージＶＭ３００のどちらに格納されているかを判定する（Ｓ１００２）。ページ２９２がオンプレミス１０にある場合、Ｓ１００５へ進み、キャッシュにライトデータを格納する（Ｓ１００５）。

一方で、ページがクラウドにある場合、ライトプログラム５１５は、Ｓ１００５をスキップし、クラウド２０に対してライト要求を発行する（Ｓ１００６）。

ページ２９２が割り当てられておらず、Ｓ１００３へ進んだ場合、ライトプログラム５１５は、容量プール２９０に空きページがあるかどうかをチェックする（Ｓ１００３）。これは、プールテーブル２２４の状態をチェックすることで実現される。空きページが存在しない場合、ライトプログラム５１５はＳ１００６へ進み、クラウド２０にライト要求を発行する（Ｓ１００６）。一方、空きページが存在する場合、ライトプログラム５１５は、ライト対象アドレスを含む領域にページ２９２を割り当て（Ｓ１００４）、キャッシュにライトデータを格納する（Ｓ１００５）。ページ割り当ての処理は、プールテーブル２２４の状態２２４ｄ、割当先２２４ｅの更新と、仮想ボリュームテーブル２２５のページ割当て状態２２５ｃ、ページ番号２２５ｄを更新することである。

Ｓ１００６において、ライトプログラム５１５は、クラウド２０のボリューム３１０へライト要求を発行し、クラウド２０からの完了報告を待つ（Ｓ１００６）。具体的には、ライトプログラム５１５は、制御情報部２２１内の、仮想ボリューム２９３とボリューム３１０のペア関係を管理するペアテーブル２２７へアクセスし、ボリューム３１０の情報と、ボリューム３１０が格納されるストレージＶＭ３００の情報とを取得する。ライトプログラム５１５は、取得したストレージＶＭ３００の情報と、ボリューム３１０の情報と、ライト要求に含まれていたライトアドレス、ライトデータをライト要求としてストレージＶＭ３００へ送信する。例えば、仮想ボリューム３１０内のアドレスは、ボリューム３１０内のアドレスに対応付けられている。

次に、ライトプログラム５１５はクラウド２０からのライト要求の完了報告を受領し（Ｓ１００７）、Ｓ１００１で“Ｎｏ”と判定された場合に仮想ボリュームテーブル２２５を更新する（Ｓ１００８）。具体的には、Ｓ１００３で“Ｎｏ”と判定された場合、ライトプログラム５１５は、書き込みアドレスに対応するレコードのページ割り当て状態２２５ｃを“済み”に更新し、さらに、ページ番号２２５ｄを“Ｃｌｏｕｄ”に更新する。また、Ｓ１００３で“Ｙｅｓ”と判定された場合、ライトプログラム５１５は、書き込みアドレスに対応するレコードのページ割り当て状態２２５ｃを“済み”に更新し、さらに、ページ番号２２５ｄをＳ１００４で割り当てられたページのページ番号に更新する。

最後に、ライトプログラム５１５は、ホスト１００へライト完了を報告し、処理を終了する（Ｓ１００９）。

ストレージシステム２００は、ページ２９２のアクセス頻度に応じて、ページをＨｏｔ Ｄａｔａ、Ｃｏｌｄ Ｄａｔａへ分類する。このため、ライトプログラム５１５およびリードプログラム５１４はＩＯ頻度を算出するための情報も更新する。これらは、ストレージ階層制御の技術として公知であるため、処理ステップ他は省略する。

なお、Ｓ１００５において、ライトプログラム５１５は、ライトデータをキャッシュに格納せずに、物理記憶デバイス２４０に格納してもよい。

ライトプログラム５１５によれば、Ｈｏｔ Ｄａｔａへライト要求が発行された場合、ステップＳ１００５でオンプレのデータが更新され、ステップＳ１００６でクラウド上のデータが更新される。すなわち、ライトデータは二重化される。一方、Ｃｏｌｄ Ｄａｔａへライト要求が発行された場合、ステップＳ１００６でクラウド上のデータのみが更新される。

また、ライト要求により指定されたライト領域に対応する仮想記憶領域に、オンプレミス側の物理記憶デバイスから第一記憶領域が割り当てられている場合、ライトデータをオンプレミス１０内の物理記憶デバイスへ書き込む。ライト対象領域に、クラウド側の記憶領域である第二記憶領域が割り当てられている場合、ライトデータをオンプレミス１０内の物理記憶デバイスに書き込むことなく、クラウドへ転送する。第一記憶領域は例えば、容量プール２９０に関連付けられたページである。第二記憶領域は例えば、容量プール２９０に関連付けられていないページである。これにより、ストレージシステム２００は、Ｈｏｔ Ｄａｔａだけをオンプレミス１０に格納することができる。

また、ライト対象領域に第一記憶領域と第二記憶領域の何れも割り当てられていない場合、ストレージシステム２００は、第一記憶領域を優先してライト対象領域に割り当てる。これにより、ストレージシステム２００は、容量プール２９０内のページをライト対象領域に割り当てることが可能であれば、新規のデータをＨｏｔ Ｄａｔａとして扱うことができる。このように、図８の例では、ページが未割当の領域が更新されたとき、空ページがあれば当該ページをＨｏｔ Ｄａｔａ同様に処理した。ページが未割当領域へのライト要求の場合、当該ライト要求がライト対象領域に発行された最初のＩ／Ｏ要求と考えられるため、ページが未割当領域へのライト要求を、Ｃｏｌｄ Ｄａｔａ同様に処理してもよい。具体的には、ステップＳ１００３の結果が“Ｙｅｓ”の場合、ステップＳ１００６へ進むことで実現される。

図９は、実施例１に係るリードプログラムのフローチャートの一例である。

リードプログラム５１４は、ホスト１００から仮想ボリューム２９３へのリード要求を受領し、リードデータをホスト１００へ返す。

最初に、リードプログラム５１４はホスト１００からリード要求を受領する（Ｓ２０００）。リード要求は、リード対象ボリューム番号（本実施例の場合仮想ボリューム番号）、リードアドレス、リード長などの情報を含む。

次に、リードプログラム５１４は仮想ボリュームテーブル２２５にアクセスし、リード対象アドレスに、ページ２９２が割り当てられているか否かを判定する（Ｓ２００１）。ページ２９２の割り当てがない場合、リード対象アドレスは未割当領域であるため、リードプログラム５１４は、Ｓ２００７でゼロデータをホスト１００へ転送し、処理を終了する（Ｓ２００７）。ここでリードプログラム５１４は、ゼロデータの代わりにエラーをホスト１００へ返してもよい。

一方で、ページ２９２が割り当てられている場合、リードプログラム５１４はリード対象データがキャッシュ上にあるか否かをキャッシュ管理テーブル２２６を参照して判定する（Ｓ２００２）。リード対象データがキャッシュ上にある場合、リードプログラム５１４は、キャッシュからホスト１００へデータを転送し、処理を終了する（Ｓ２００７）。

リード対象データがキャッシュ上にない場合、リードプログラム５１４はリード対象アドレスに対応するページ２９２がオンプレミス１０のストレージシステム２００か、クラウド２０のストレージＶＭ３００のどちらに格納されているかを判定する（Ｓ２００３）。ページ２９２がオンプレミス１０にある場合、リードプログラム５１４は、プールボリューム２９１へアクセスし、リード対象データをキャッシュへ格納した後（Ｓ２００６）、キャッシュからホスト１００へデータを転送する（Ｓ２００７）。ここでは、物理的にデータが格納されている位置が物理記憶デバイス２４０であるため、ステップＳ２００６では、プールボリューム２９１に対応する物理記憶デバイス２４０からデータがキャッシュへ転送される。

ページ２９２がクラウド２０にある場合、リードプログラム５１４は、クラウド２０のボリューム３１０へリード要求を発行し、クラウド２０からの完了報告を待つ（Ｓ２００４）。ここでリードプログラム５１４は、ライト要求同様に、ペアテーブル２２７から、リード要求発行先となるストレージＶＭ３００の情報とボリューム３１０の情報とを取得する。

次に、リードプログラム５１４は、クラウド２０からリード対象データを受領し（Ｓ２００５）、最後にホスト１００へ、受領したリードデータを転送する（Ｓ２００７）。ストレージシステム２００がクラウド２０からリード対象データを受領してから、ホスト１００へ転送するまでの間、リード対象データはＦＥパッケージ２６０のメモリ２６２や、キャッシュ等に一時的に格納される。

リードプログラム５１４によれば、ストレージシステム２００は、リード要求により指定された仮想記憶領域であるリード対象領域に、キャッシュが関連付けられていると判定した場合、キャッシュからリードデータを読み出す。これにより、ストレージシステム２００は、ホスト１００に対して高速に応答することができる。ストレージシステム２００は、リード対象領域にキャッシュが関連付けられていないと判定し、かつ、リード対象領域に容量プール２９０が関連付けられたページが割り当てられていると判定した場合、容量プール２９０からリードデータを読み出す。ストレージシステム２００は、リード対象領域にキャッシュが関連付けられていないと判定し、かつ、リード対象領域に容量プール２９０が関連付けられていないページが割り当てられていると判定した場合、クラウド２０からリードデータを読み出す。これにより、ストレージシステム２００は、キャッシュ上にないＨｏｔ Ｄａｔａをオンプレミス１０から読み出し、キャッシュ上にないＣｏｌｄ Ｄａｔａをクラウド２０から読み出すことができる。

上述のように、本願発明によれば全データをクラウド側に保持しつつ、アクセス頻度の高いデータについてはオンプレ側にも保持することが可能となる。

従来のリモートコピーにより単にデータ２重化するのでは２倍の記憶領域を消費する。
また、オンプレ側の使用容量低減のために、オンプレ側で仮想ボリュームを提示して、全てのデータをクラウド側に格納する場合、ホスト計算機から発行される全てのＩ／Ｏ処理のためにクラウドのアクセスが発生し性能低下が起きうる。又、オンプレ側ストレージ装置とクラウド側のストレージとの間でデータのアクセス頻度に応じた階層制御を更に組み合わせることも考えられるが、アクセス頻度の高いデータがクラウド側に格納されず、クラウド側での業務ができない上に、オンプレ側の障害時の復旧ができない。更に、クラウド上のストレージに格納されるデータをオンプレのストレージシステムのキャッシュ領域にキャッシュするＩ／Ｏ性能改善方法が考えられる。しかし、オンプレミスのホスト計算機障害で業務をクラウド側で再開する前に、キャッシュデータをクラウドへ書き出す必要が生じ、迅速な業務再開ができない。さらに、オンプレミスのストレージシステムに障害が発生した場合には、一部のデータが失われる可能性がある。

一方、本実施例によれば、Ｈｏｔ Ｄａｔａはオンプレのストレージシステムのアクセスのみで実現でき、高いＩ／Ｏ性能を実現できる。さらに、ライト要求に同期してライトデータをクラウドに書き込むことから、オンプレミスに障害が発生しても、クラウド２０内のデータを用いて業務を迅速に再開することができる。

ここで、実施例１の変形例について説明する。

上述したライトプログラム５１５およびリードプログラム５１４の処理では、Ｃｏｌｄ Ｄａｔａがライトまたはリードされたときに、ストレージシステム２００のキャッシュにデータはキャッシュされない。例えば、ライトプログラム５１５は、Ｓ１００２においてクラウド２０にデータがある場合、データをキャッシュに格納するＳ１００５をスキップし、Ｓ１００６に進み、クラウド２０へのライト要求を発行する。リードプログラム５１４は、Ｓ２００５でクラウド２０からデータを受領し、ホスト１００へ転送している。すなわち、ストレージシステム２００のキャッシュにクラウドからリードしたデータをキャッシュデータとして残していない。

変形例として、Ｃｏｌｄ Ｄａｔａがライトまたはリードされたときに、ストレージシステム２００は、キャッシュに仮想ボリューム２９３のデータとしてキャッシュすることもできる。この動作を以下に説明する。

ライトプログラム５１５は、Ｓ１００２で“Ｎｏ”と判定された場合またはＳ１００３で“Ｎｏ”と判定された場合、Ｓ１００６へ進むのではなくＳ１００５へ進み仮想ボリューム２９３のキャッシュデータとしてキャッシュ上にライトデータを格納する。これにより、リードプログラム５１４のＳ２００２でキャッシュヒットする（キャッシュ上にデータがある）ことが期待される。

リードプログラム５１４は、Ｓ２００５の直後に、Ｓ２００５で受領したデータを、仮想ボリューム２９３のデータとしてキャッシュ上に格納する処理を実行する。これにより、以降に発行されるリード要求において、リードプログラム５１４のＳ２００２でキャッシュヒットする（キャッシュ上にデータがある）ことが期待される。

仮想ボリューム２９３のデータとしてキャッシュするとは、仮想ボリューム２９３のアドレス（ライト、リードでアクセスされたアドレス）とデータが格納されているキャッシュのアドレスを対応付けたキャッシュ管理テーブル２２６で管理することで実現される。

変形例において、Ｃｏｌｄ Ｄａｔａをストレージシステム２００のキャッシュ部にキャッシュする場合、デステージ処理の変更が必要となる。デステージ処理とは、ライトデータによってキャッシュに書き込まれたデータを物理記憶デバイス２４０に書き込む処理である。Ｃｏｌｄ Ｄａｔａはプールボリューム２９１に対応付けられていないため、書き込み先となる物理記憶デバイス２４０が存在しない。これは従来の仮想ボリュームには存在しない状態である。上記状態に対応するデステージプログラム５１６について説明する。

図１０は、実施例１に係るデステージプログラム５１６のフローチャートの一例である。

本プログラムは他のプログラムからコールされる。例えば、デステージプログラム５１６は、キャッシュのダーティ量を監視しているプログラムからコールされ得るし、ＩＯ時に割り当てるキャッシュが不足している場合にはＩＯを処理するプログラムからもコールされ得る。

最初に、デステージプログラム５１６は、キャッシュデータの中からダーティキャッシュを探す（Ｓ３００）。

次に、デステージプログラム５１６は、キャッシュされている領域に対応するページ２９２を特定する（Ｓ３０１）。具体的には、デステージプログラム５１６は、キャッシュデータに対応する仮想ボリューム２９３のアドレスを得る。これは、キャッシュ管理テーブル２２６によって取得されることができる。次に、デステージプログラム５１６は、仮想ボリュームテーブル２２５を参照し、得られた仮想ボリューム２９３のアドレスに対応するページ番号を特定する。

そして、デステージプログラム５１６は、特定されたページがプールボリューム２９１に対応するか否かを判定する（Ｓ３０２）。プールボリューム２９１に対応する場合、キャッシュデータに対応する物理記憶デバイス２４０はストレージシステム２００内にあるため、デステージプログラム５１６は、デステージを実行する（Ｓ３０３）。すなわち、デステージプログラム５１６は、物理記憶デバイス２４０にキャッシュデータを書き込む。最後に、デステージプログラム５１６は、キャッシュを解放して処理を終了する（Ｓ３０４）。

一方で、プールボリューム２９１に対応しない場合、キャッシュデータに対応する物理記憶デバイス２４０はストレージシステム２００内にないため、デステージプログラム５１６は、キャッシュを解放し、処理を終了する（Ｓ３０４）。すなわち、対象となるＣｏｌｄ Ｄａｔａはクラウド２０のボリューム３１０に格納されているため、デステージプログラム５１６は、単純にキャッシュを解放してもよい。

また、ライトプログラム５１５は、Ｓ１００２で“Ｎｏ”と判定される場合またはＳ１００３で“Ｎｏ”と判定される場合に、Ｓ１００５でデータをクリーンキャッシュとしてキャッシュしてもよい。クリーンキャッシュは物理記憶デバイス２４０の同一のデータであり、物理記憶デバイス２４０に書き込まれることなく解放される。対象となるＣｏｌｄ Ｄａｔａはクラウド２０のボリューム３１０に格納されているため、デステージプログラム５１６は、単純にキャッシュを解放してもよい。よって、ライトプログラム５１５がクラウド２０へのライトデータをクリーンキャッシュとして扱うことで、既存のデステージプログラム５１６からの変更は不要となる。さらに、一般的にダーティキャッシュは二重化されるがクリーンキャッシュは二重化する必要がない。よって、キャッシュ消費量を減らすことができる。

なお、Ｓ３０１、Ｓ３０２のために、ストレージシステム２００は、キャッシュ管理テーブル２２６により、キャッシュに対応するＨＤＤが存在するかどうかを管理してもよい。

デステージプログラム５１６によれば、ストレージシステム２００は、キャッシュ上のデータのうち、容量プール２９０に関連付けられていないデータを破棄する。これにより、ストレージシステム２００は、Ｃｏｌｄ Ｄａｔａを物理記憶デバイス２４０へ書き出すことなく、キャッシュを解放することができる。

本実施例の計算機システムは、ＩＯ頻度情報を用いて、データをＨｏｔ ＤａｔａとＣｏｌｄ Ｄａｔａへ分類し、オンプレミス１０のストレージシステム２００にＨｏｔ Ｄａｔａのみを格納、クラウド２０のストレージＶＭ３００にＨｏｔ ＤａｔａとＣｏｌｄ Ｄａｔａを格納する。ＩＯ頻度に変化が生じた場合、Ｈｏｔ ＤａｔａからＣｏｌｄ Ｄａｔａへの変化、Ｃｏｌｄ ＤａｔａからＨｏｔ Ｄａｔａの変化が発生する。この変化に基づいて、データの格納場所を変更する必要がある。

図１１は、実施例１に係るティアリングプログラムのフローチャートの一例である。

ティアリングプログラム５１１は、ＩＯ頻度情報の変化に基づき、最適なデータの格納レイアウトを算出し、実際にデータの配置を変更するデモーションプログラム５１３、および、プロモーションプログラム５１２を起動する。なお、Ｈｏｔ ＤａｔａからＣｏｌｄ Ｄａｔａへの変化に伴い、データ格納場所を変更することをデモーションと呼ぶ。更に、Ｃｏｌｄ ＤａｔａからＨｏｔ Ｄａｔａへの変更に伴い、データ格納場所を変更することをプロモーションと呼ぶ。ティアリングプログラム５１１は、ストレージシステム２００内で定期的に実行される。例えば、データ配置の見直し頻度が１時間に１回であれば、ティアリングプログラム５１１は、１時間に１回起動される。データ配置の見直し頻度は、保守端末２７０や管理サーバなどを介してユーザやストレージ管理者から設定され得る。

最初に、ティアリングプログラム５１１は、仮想ボリュームの各領域のＩＯ頻度情報を仮想ボリュームテーブル２２５から取得し（Ｓ３０００）、ＩＯ頻度情報を用いてデータの最適な配置を算出する（Ｓ３００１）。次に、ティアリングプログラム５１１は、最適な配置と現状の配置を比較し、プロモーションすべきデータおよび、デモーションすべきデータを決定する（Ｓ３００２、Ｓ３００３）。

配置決定の一例として、ティアリングプログラム５１１は、仮想ボリュームの各領域をＩＯ頻度の高いものから順に並べる。次に、ティアリングプログラム５１１は、オンプレミス１０の容量プール２９０の容量から、Ｈｏｔ ＤａｔａとＣｏｌｄ Ｄａｔａを判定するＩＯ頻度閾値を導き、どの領域のデータをＨｏｔ Ｄａｔａとしてオンプレミス１０の容量プールに格納すべきかを決定する。

そして、ティアリングプログラム５１１は、既に容量プール２９０に格納済みのデータを除いて、プロモーション対象となるデータを特定する。同様に、ティアリングプログラム５１１は、既に容量プール２９０に格納されているデータのうち、容量プール２９０に入れられないものをデモーション対象として特定する。

以下に、ティアリングプログラム５１１のＳ３００４以降を説明する。ティアリングプログラム５１１は、デモーション対象を指定して、デモーションプログラム５１３をコールする（Ｓ３００４）。最後に、ティアリングプログラム５１１は、プロモーション対象を指定して、プロモーションプログラム５１２をコールし、処理を終了する（Ｓ３００５）。ストレージシステム２００の物理記憶デバイスの容量は、ストレージＶＭ３００の物理記憶デバイスの容量より小さいことが多い。容量プール２９０に空きページを作成するために、ティアリングプログラム５１１は、基本的にデモーションプログラム５１３を先に実行する。複数データをプロモーション、デモーションする場合は、デモーション、プロモーションを交互に実行することでＨｏｔ Ｄａｔａ格納用領域を有効利用できる。

ティアリングプログラム５１１によれば、ストレージシステム２００は、各仮想記憶領域のアクセス頻度に基づいて、各仮想記憶領域を第一グループと第二グループの何れか一つに分類し、第一グループに分類された仮想記憶領域に対し、容量プール２９０に関連付けられたページを割り当て、第二グループに分類された仮想記憶領域に対し、容量プール２９０に関連付けられていないページを割り当てる。第一グループは例えば、Ｈｏｔ Ｄａｔａに対応する仮想記憶領域である。第二グループは例えば、Ｃｏｌｄ Ｄａｔａに対応する仮想記憶領域である。これにより、オンプレミス１０の性能の低下を防ぐと共に、オンプレミス１０の物理記憶デバイス２４０の容量を節約することができる。

図１２は、実施例１に係るデモーションプログラムのフローチャートの一例である。

デモーションプログラム５１３は、ティアリングプログラム５１１からコールされ、ストレージシステム２００で実行される。

最初に、デモーションプログラム５１３は、デモーション指示を受領する（Ｓ４０００）。このとき、デモーションプログラム５１３は、デモーション対象である一つ以上の仮想ボリューム２９３内の領域（仮想ボリューム番号と仮想ボリューム内のアドレスによって特定される領域）を、パラメタとして受領する。

本実施例では、デモーションプログラム５１３が複数の領域情報を受領し、複数の領域に対して処理を行うものとした。しかし、デモーションプログラム５１３は一つの領域のデモーションを実施する機能とし、ティアリングプログラム５１１が複数回デモーションプログラム５１３をコールするようにしてもよい。

次に、デモーションプログラム５１３は、デモーション対象の中から未処理の領域を一つ選択し（Ｓ４００１）、当該領域を使用している仮想ボリューム２９３の仮想ボリュームテーブル２２５を更新する（Ｓ４００２）。具体的には、デモーションプログラム５１３は、ページ番号を“Ｃｌｏｕｄ”へ変更する。変更後、デモーションプログラム５１３はＨｏｔ Ｄａｔａを格納していた容量プール２９０の領域を解放する（Ｓ４００３）。

次に、デモーションプログラム５１３は、指示された全ての領域を処理したか否かをチェックする（Ｓ４００４）。指示された全ての領域を処理している場合、デモーションプログラム５１３は、処理を終了する（Ｓ４００５）。

一方、未処理の領域が残っている場合、デモーションプログラム５１３はＳ４００１へ戻り、次の未処理の領域に対して、Ｓ４００２からＳ４００３までを実行する。

デモーションプログラム５１３によれば、ストレージシステム２００は、仮想記憶領域のデモーションを実行する場合、デモーション対象領域に割り当てられている、容量プール２９０に関連付けられたページを、容量プール２９０に関連付けられていないページに変更する。これにより、ストレージシステム２００は、容量プール２９０からのデータの読み出しと、クラウド２０へのデータを書き込みとを実行することなく、デモーションを実行することができる。

図１３は、実施例１に係るプロモーションプログラムのフローチャートの一例である。

プロモーションプログラム５１２は、ティアリングプログラム５１１からコールされ、ストレージシステム２００で実行される。

最初に、プロモーションプログラム５１２は、プロモーション指示を受領する（Ｓ５０００）。このとき、プロモーションプログラム５１２は、プロモーション対象である一つ以上の仮想ボリューム内の領域（仮想ボリューム番号と、仮想ボリューム内のアドレスによって特定される領域）を、パラメタとして受領する。

次に、プロモーションプログラム５１２は、プロモーション対象の中から未処理の領域を一つ選択し（Ｓ５００１）、当該領域を格納するための容量プール２９０の領域を確保する（Ｓ５００２）。具体的には、プロモーションプログラム５１２は、プールテーブル２２４の状態２２４ｄ、割当先２２４ｅを更新する。また、プロモーションプログラム５１２は、仮想ボリュームテーブル２２５のページ番号２２５ｄを更新する。この処理によって、デステージプログラム５１６のＳ３０２の結果が変わる。

続けて、プロモーションプログラム５１２は、選択した領域のデータがキャッシュされているか否かをチェックする（Ｓ５００３）。この処理は、キャッシュ管理テーブル２２６を参照することで実現される。

データがキャッシュされている場合、プロモーションプログラム５１２は、Ｓ５００４、Ｓ５００５をスキップしてＳ５００６へ進む。

一方、データがキャッシュされていない場合、プロモーションプログラム５１２はストレージＶＭ３００にリード要求を発行し、ストレージＶＭ３００からの応答を待つ（Ｓ５００４）。そして、プロモーションプログラム５１２は、ストレージＶＭ３００からプロモーション対象のデータを受領し、ダーティとしてキャッシュに格納する（Ｓ５００５）。

この時点で、プロモーション対象のデータがキャッシュ上に格納された状態となる。さらに、仮想ボリュームテーブル２２５のページ番号２２５ｄには、プールボリューム２９１のページ番号が格納されている。このデータは、デステージプログラム５１６によってストレージシステム２００が搭載する物理記憶デバイス２４０へ書き込まれることになる。

なお、ストレージシステム２００がＣｏｌｄ Ｄａｔａをリードまたはライトしたときにキャッシュしない場合、Ｓ５００３は不要となる。このとき、Ｓ５００４、Ｓ５００５は必要である。

また、ストレージシステム２００がＣｏｌｄ Ｄａｔａをリードまたはライトしたときにクリーンとしてキャッシュする場合、デステージプログラム５１６によって物理記憶デバイス２４０に書き込まれない。これを回避するための方法が二つある。一つ目は、ステップＳ５００３で“Ｙｅｓ”となった場合、キャッシュの属性をクリーンからダーティに変更する。二つ目は、ステップＳ５００３で“Ｙｅｓ”となった場合、クリーンのキャッシュを一旦は解放し、ステップＳ５００４、Ｓ５００５を実行する。

次に、プロモーションプログラム５１２は、指示された全ての領域を処理したか否かをチェックする（Ｓ５００６）。指示された全ての領域を処理している場合、プロモーションプログラム５１２は、処理を終了する（Ｓ５００７）。

一方、未処理の領域が残っている場合、プロモーションプログラム５１２はＳ５００１へ戻り、次の未処理の領域に対して、Ｓ５００２からＳ５００５までを実行する。

本実施例のストレージシステム２００は、ページ割当て状態２２５ｃおよびページ番号２２５ｄを用いてリード要求、ライト要求の処理を分岐させた。具体的には、ストレージシステム２００は、“ページ割り当てなし”が未割当状態である（状態Ａ）と判定し処理する。また、ストレージシステム２００は、“ページ割り当てあり＋ページ番号有効（数値）”が、ページ割り当て済みであり且つデータがオンプレミス１０およびクラウド２０に格納されている（状態Ｂ）、と判定し処理する。また、ストレージシステム２００は、“ページ割り当てあり＋ページ番号無効（“Ｃｌｏｕｄ”）“が、ページ割り当て済みであり且つデータがクラウド２０のみに格納されている（状態Ｃ）、と判定し処理する。

ページ割り当て状態のみでも本実施例と同様の動作を実現することができる。

まず、ストレージシステム２００は、“ページ割り当てあり”が、オンプレミス１０のページが割り当て済みであり且つデータがオンプレミス１０およびクラウド２０に格納されている、と判定し処理する。すなわち、この処理は、上述の状態Ｂと同様の処理となる。

次に、“ページ割り当てなし”の時に、上述の状態Ａ、Ｃと同等の結果を返す方法を説明する。

まず、リードプログラムは、クラウド２０にリード要求を発行する。対象の領域がホスト１００からライトが書き込まれていない領域であれば、クラウド２０からストレージシステム２００へゼロデータが返される。すなわち、未割当であった場合と同様の結果となる。次に、ホスト１００から当該領域へライトが書き込まれていた場合は、クラウド２０に格納されているリード対象データがストレージシステム２００へ返される。すなわち、正しいリード対象データが返される。

次に、ライトプログラムは、クラウド２０にライト要求を発行し、クラウド２０にライトデータを格納する。これにより問題なくＩＯ処理を実現することができる。また、ライトプログラムは、オンプレミス１０に空きページがあれば対象の領域へ割り当ててもよい。その場合、ライトプログラムは、割り当てられページとクラウド２０との両方にライトを書き込む。

これにより、対象の領域に対してオンプレミス１０及びクラウド２０の物理記憶領域が未割当だった場合に、クラウド２０と通信してしまうが、ＩＯとしては正しい結果を返すことができる。

以上のリードプログラム５１４、ライトプログラム５１５では、オンプレミス１０の仮想ボリューム２９３がＩＯ要求を受領する方式を説明した。

異なるストレージに配備される二つのボリュームのデータをボリューム間で二重化し、さらに当該二つのボリュームに対してストレージ間でユニークな仮想的なＩＤを割り当て、ホスト１００に対して、あたかも一つのボリュームのように見せるＨＡ（High Availability）機能が知られている。この機能を用いることにより、ホスト１００は、どちらのストレージに対してもＩＯ要求を発行することができる。

本実施例のストレージシステム２００とストレージＶＭ３００は、この機能と同様にして仮想ボリューム２９３とボリューム３１０を一つのボリュームとしてホストへ提供してもよい。ホスト１００は、オンプレミス１０のストレージシステム２００、クラウド２０のストレージＶＭ３００の両方に発行することができる。たとえば、ホスト１００が仮想マシンであり、クラウド２０へホストＶＭ４００としてマイグレーションされた時に、ストレージＶＭ３００のボリューム３１０に対してＩＯを継続することができる。さらに、ストレージＶＭ３００とストレージシステム２００が近距離に配置されている場合、ホスト１００は両方のボリュームへＩＯ要求を発行してもよい。この場合、ホスト１００からストレージＶＭ３００へのパスが設定されているものとする。ホスト１００は、複数パスを使うことで、パス性能向上、パス障害に対する信頼性の向上が期待できる。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

一般に、クラウド２０のアクセスレイテンシは悪い（レイテンシが大きい）。高頻度でアクセスされるＨｏｔ Ｄａｔａのアクセスにおいて、ＩＯに同期したクラウド２０のアクセスを回避したい。ＩＯに同期したクラウド２０のアクセスを回避するため、クラウド２０へのライト要求発行を非同期に実施する。非同期にライトを転送するための技術として非同期リモートコピーがある。

図１４は、実施例２に係る計算機システムの構成を示す。

本実施例の計算機システムは、仮想ボリューム２９３、ボリューム３１０に代えて、ＰＶＯＬ（Primary Volume）７００、ＳＶＯＬ（Secondary Volume）７０３、ＪＶＯＬ（Journal Volume）７０１、ＪＶＯＬ７０２を作成する。ＰＶＯＬ７００はオンプレミス１０内のストレージシステム２００の仮想ボリュームであり、ホスト１００が使用するデータが格納される。ＳＶＯＬ７０３は、クラウド２０内のストレージＶＭ３００のボリュームであり、ＰＶＯＬ７００に書き込まれたデータのコピーを格納する。

ＪＶＯＬ７０１は、オンプレミス１０内のストレージシステム２００のボリュームであり、ＳＶＯＬ７０３へ転送するデータを一時的に格納する。ＪＶＯＬ７０２は、ストレージＶＭ３００のボリュームであり、オンプレミス１０内のストレージシステム２００から転送されたデータを一時的に格納する。なお、ＪＶＯＬ７０１、７０２も仮想ボリュームあってもよい。本実施例では、ＪＶＯＬはボリュームとしたが、一時的にデータを格納することができる領域であれば何でもよい。例えば、キャッシュを使用する方法などが考えられる。

上記のＪＶＯＬ７０１からＪＶＯＬ７０２へ転送されるデータのことをジャーナル（Journal）と呼ぶ。ジャーナルはライトデータ（Journal Data）とライトデータに対するメタデータ（ＪＮＣＢ：Journal Control Block）から構成される。ＪＮＣＢには、ライトアドレスや、コピー先のボリューム番号、コピー先ストレージの識別番号、ホストから書き込まれた順序を示す情報（ＳＥＱ ＩＤ）などが含まれる。

以下に、ホスト１００から非同期リモートコピーのＰＶＯＬ７００にライトが発行されたときのフローを説明する。本発明へ非同期リモートコピーが適用された場合の処理は、図１６以降に説明する。

ストレージシステム２００は、ホスト１００からライト要求７０４を受領すると、ライトデータをＰＶＯＬ７００に書き込む。続けて、ストレージシステム２００は、ライト要求に対してジャーナル７０５（ＳＥＱ ＩＤを含む）を作成しＪＶＯＬ７０１へ格納し、ホスト１００へライト完了を報告する。ストレージシステム２００及びストレージＶＭ３００は、ライト完了の報告とは非同期のタイミングでＪＶＯＬ７０１のデータをＪＶＯＬ７０２へ転送する。最後に、ストレージＶＭ３００は、ＪＶＯＬ７０２のジャーナルからライトデータを取り出し、ＳＥＱ ＩＤの順でＳＶＯＬ７０３に書き込む。この処理を、ＪＮＬのリストアと呼ぶ。

なお、ＪＶＯＬ７０１は複数のボリュームにより構成されていてもよく、また、複数のＰＶＯＬ７００に対するジャーナルを格納するようにしてもよい。ＪＶＯＬ７０２も同様である。

図１５は、ストレージシステム２００からストレージＶＭ３００へのデータ転送に非同期リモートコピーを適用した場合に発生する課題の一例である。

まず、ストレージシステム２００が、ホスト１００からライト要求８００を受領し、当該ライト要求に対してジャーナル８０１を作成した状態であるとする。図中の“Ｎｅｗ”は、新たに書き込まれたデータを意味する。“Ｏｌｄ”は、“Ｎｅｗ”が書き込まれたアドレスに、“Ｎｅｗ”ライト前に格納されていた値を意味する。

ライトデータ“Ｎｅｗ”を含むジャーナル８０１がＪＶＯＬ７０１またはＪＶＯＬ７０２に格納されている間に、ホスト１００からライト要求と同じアドレスに対するリード要求８０２が発行される可能性がある。

対象アドレスのデータがＣｏｌｄ Ｄａｔａである場合、実施例１のリードプログラム５１４によれば、クラウド２０のＳＶＯＬ７０３からデータを読み出し、ホストへ転送する。しかし、クラウド２０には未だ“Ｏｌｄ”が格納されているため、ストレージシステム２００は、この古いデータをホスト１００へ転送してしまうる。

以降、上記課題を解決するためのテーブル構造および処理フローを説明する。

上記問題を解決するために、本実施例のストレージシステム２００は、ジャーナルのＳＶＯＬ７０３へのリストアが完了するまで、ストレージシステム２００のキャッシュ上にライトデータを常駐させる。これにより、リード要求８０２に応じてストレージシステム２００は、キャッシュに格納されている“Ｎｅｗ”にアクセスするため、“Ｏｌｄ”をリードする問題は解決される。

本実施例のキャッシュ管理テーブル２２６は、常駐Ｂｉｔ２２６ｅ、最大ＳＥＱ ＩＤ２２６ｆを含む。

常駐Ｂｉｔ２２６ｅは、キャッシュデータをキャッシュ部に常駐させる必要があるか否かを管理する。“ＯＮ”は常駐が必要であることを意味する。“ＯＦＦ”は常駐が不要であることを意味する。リストアが完了するまで常駐ＢｉｔをＯＮすることによって、旧データがリードされる問題を回避する。

最大ＳＥＱ ＩＤ２２６ｆは、当該キャッシュに格納されているライトデータに対して割り当てられたＳＥＱ ＩＤのうち最大のＳＥＱ ＩＤを管理する。ストレージシステム２００は、この最大ＳＥＱ ＩＤとＳＶＯＬ７０３へのリストアが完了したジャーナルのＳＥＱ ＩＤを比較することで、キャッシュ解放の要否を判定する。

ここで、最大ＳＥＱ ＩＤを用いる理由について説明する。同一のアドレスに対して、複数のライト要求が発行された場合、キャッシュデータは上書きされる。この時、最初のライト要求に対するジャーナルがＳＶＯＬに書き込まれた時点でストレージシステム２００がキャッシュを解放してしまうと、後続のライト要求でキャッシュされたデータも同時に解放されることになる。これを回避するために、ストレージシステム２００は、最大ＳＥＱ ＩＤを管理する。

ストレージシステム２００のプログラム部２２２は、実施例１のプログラムに加えて、ジャーナル転送プログラム５２１、キャッシュパージプログラム５２２を格納する。

クラウド２０は、リードジャーナルプログラム、リストアプログラムを格納する。ストレージＶＭ３００は、これらのプログラムを実行する。

図１６は、実施例２に係るライトプログラムのフローチャートの一例である。

本実施例のライトプログラムをライトプログラム５１５ｂと記す。本実施例のライトプログラム５１５ｂにおけるＳ１０００からＳ１００４は、実施例１のライトプログラム５１５と同じである。Ｓ１００２の結果が“Ｎｏ”となる場合、または、Ｓ１００３の結果が“Ｎｏ”となる場合、ライトプログラム５１５ｂはキャッシュにライトデータを格納する（Ｓ６００５）。この時、ライトプログラム５１５ｂは、キャッシュ管理テーブル２２６の常駐Ｂｉｔ２２６ｅを“ＯＮ”する。

このケースは、クラウド２０のストレージＶＭ３００にのみデータを格納する分岐であるため、ライトデータをキャッシュ上に常駐させる必要がある。これを実現するため、ライトプログラム５１５ｂは、キャッシュ管理テーブル２２６の常駐Ｂｉｔ２２６ｅを“ＯＮ”する。

ここで、ライトプログラム５１５ｂは、キャッシュ管理テーブル２２６の最大ＳＥＱ ＩＤ２２６ｆに、ＳＥＱ ＩＤが取り得る値の上限である上限値を格納する。なぜならば、ＳＥＱ ＩＤの割り当てステップは後のＳ６００８であり、ライト要求に対しては未だＳＥＱ ＩＤが取得されていないからである。ＳＥＱ ＩＤが確定するまでの間、キャッシュの解放が回避できれば何でもよい。ライトプログラム５１５ｂは、上限値の代わりに無効値を格納し、無効値の場合はキャッシュを解放しないとしてもよい。

また、キャッシュにライトデータを格納するＳ６００５またはＳ６００６以前にＳＥＱ ＩＤを取得するようにしてもよい。その場合は、取得済みのＳＥＱ ＩＤを最大ＳＥＱ ＩＤ２２６ｆの値と比較し、取得したＳＥＱ ＩＤが大きければ、取得したＳＥＱ ＩＤをキャッシュ管理テーブル２２６の最大ＳＥＱ ＩＤ２２６ｆへ格納する。

Ｓ１００２が“Ｙｅｓ”となる場合、または、Ｓ１００３が“Ｙｅｓ”となる場合、ライトプログラム５１５ｂはキャッシュにライトデータを格納する（Ｓ６００６）。このとき、キャッシュ管理テーブル２２６の常駐Ｂｉｔ２２６ｅは“ＯＦＦ”である。なぜならば、容量プール２９０の領域が割り当てられており、キャッシュが解放されたとしても、リード要求に対して容量プール２９０から最新のデータを転送することができるからである。この時、ライトプログラム５１５ｂは、最大ＳＥＱ ＩＤ２２６ｆに何も格納しない。図示したキャッシュ管理テーブル２２６の例は、この時の最大ＳＥＱ ＩＤ２２６ｆを“−”で示している。

Ｓ６００５とＳ６００６の後、ライトプログラム５１５ｂは、仮想ボリュームテーブル２２５を更新する（Ｓ６００７）。この処理は、実施例１のＳ１００８と同じである。

次に、ライトプログラム５１５ｂは、ＳＥＱ ＩＤ管理テーブルからＳＥＱ ＩＤを取得し（Ｓ６００８）、当該ＳＥＱ ＩＤを含むジャーナルを作成し、ＪＶＯＬ７０１へ格納する（Ｓ６００９）。

ライトプログラム５１５ｂは、ジャーナルを格納した後、取得したＳＥＱ ＩＤを、キャッシュ管理テーブル２２６の最大ＳＥＱ ＩＤ２２６ｆに格納する（Ｓ６０１０）。

最後に、ライトプログラム５１５ｂはホスト１００へライト完了を報告し、処理を終了する（Ｓ６０１１）。

ＳＥＱ ＩＤはホスト１００からストレージシステム２００に書き込まれたライトデータの順序を示すための情報である。ＳＥＱ ＩＤ管理テーブルは、番号を管理しており、取得要求に対して管理している番号を割り当て、番号をインクリメントする。すなわち、次の取得要求に対しては＋１の番号が割り当てられる。ＳＥＱ ＩＤ管理テーブルは制御情報部２２１に記録される。

順序保証が必要な少なくとも一つのＰＶＯＬを含むＰＶＯＬグループに対し、一連のＳＥＱ ＩＤが管理される。このグループのことを一般にコンシステンシグループと呼ぶ。

さて、常駐ＢｉｔがＯＮでストレージシステム２００にキャッシュされたデータを削除するためには、ＳＶＯＬ７０３へのリストアが完了したジャーナルのＳＥＱ ＩＤが必要である。このＳＥＱ ＩＤをリストア済みＳＥＱ ＩＤと呼ぶ。リストア済みＳＥＱ ＩＤは、ＳＶＯＬ７０３を有するクラウド２０のストレージＶＭ３００にて生成される。このため、リストア済みＳＥＱ ＩＤをオンプレミス１０のストレージシステム２００へ通知する必要がある。リストア済みＳＥＱ ＩＤは制御情報部２２１に記録される。ストレージシステム２００およびストレージＶＭ３００の両方の制御情報部２２１に記録される。ストレージＶＭ３００では、後述する処理によって生成されるリストア済みＳＥＱ ＩＤが記録される。そして、ストレージシステム２００では、ストレージＶＭ３００から転送されたリストア済みＳＥＱ ＩＤが記録される。

非同期リモートコピーの処理の説明にあわせて、リストア済みＳＥＱ ＩＤの転送について説明する。

図１７は、実施例２に係るリードジャーナルプログラムのフローチャートの一例である。

リードジャーナルプログラムは、非同期リモートコピーのコピー先であるストレージＶＭ３００で実行されるプログラムである。リードジャーナルプログラムは、リードジャーナルコマンドをコピー元であるストレージシステム２００に対して発行し、ＪＶＯＬ７０１に格納されているジャーナルを、ＪＶＯＬ７０２へ転送するためのプログラムである。リードジャーナルプログラムは、多重動作してもよい。

最初に、リードジャーナルプログラムは、コピー先のストレージＶＭ３００に格納されているリストア済みＳＥＱ ＩＤを取得する（Ｓ７０００）。リストア済みＳＥＱ ＩＤは、後述するリストアプログラムによって、リストア処理の進捗に合わせて更新される。

次に、リードジャーナルプログラムは、コピー元のストレージシステム２００へリードジャーナルコマンドを発行し（Ｓ７００１）、コピー元のストレージシステム２００からの応答を待つ（Ｓ７００２）。このコマンドにはＳ７０００で取得したリストア済みＳＥＱ ＩＤが含まれている。

リードジャーナルプログラムは、コピー元のストレージシステム２００からジャーナルを受領する（Ｓ７００３）。ストレージシステム２００は、一つのリードジャーナルコマンドに対し、複数のジャーナルを転送することができる。

最後に、リードジャーナルプログラムは、ジャーナルに含まれるＳＥＱ ＩＤをチェックし、到着済みＳＥＱ ＩＤビットマップを更新する（Ｓ７００４）。到着済みＳＥＱ ＩＤビットマップは、どのＳＥＱ ＩＤがコピー先のストレージＶＭ３００へ到着しているかを示す制御情報であり、リストアプログラムがリストアできるジャーナルを決定するために使用される。到着済みＳＥＱ ＩＤは制御情報部２２１に記録される。

リードジャーナルプログラムはＳ７００４の後、Ｓ７０００に戻りリードジャーナルコマンドを発行し、他のジャーナルの転送を実行する。なお、コピー元のストレージシステム２００からジャーナルが無いことを報告された場合、Ｓ７００４の後に一定時間スリープする処理を追加してもよい。さらに、同時に実行されるリードジャーナルプログラムの多重度を下げてもよい。

図１８は、実施例２に係るジャーナル転送プログラム５２１のフローチャートの一例である。

ジャーナル転送プログラム５２１は、非同期リモートコピーのコピー元であるストレージシステム２００で実行されるプログラムである。ジャーナル転送プログラム５２１は、コピー先であるストレージＶＭ３００からリードジャーナルコマンドを受領し、ＪＶＯＬ７０１から転送するジャーナルをコピー先であるストレージＶＭ３００へ送信するプログラムである。

最初に、ジャーナル転送プログラム５２１はリードジャーナルコマンドを受領すると（Ｓ８００）、転送するジャーナルを決定する（Ｓ８００１）。

次に、ジャーナル転送プログラム５２１は、決定したジャーナルをＪＶＯＬ７０１から読み出し、コピー先のストレージへ送信する（Ｓ８００２）。

最後に、ジャーナル転送プログラム５２１は、リードジャーナルプログラムによって通知されたリストア済みＳＥＱ ＩＤをコピー元のストレージシステム２００に記録する（Ｓ８００３）。このコピー元のストレージシステム２００に記録されたリストア済みＳＥＱ ＩＤは、後述するキャッシュパージプログラムによって使用される。リストア済みＳＥＱ ＩＤは制御情報部２２１に記録される。

なお、本実施例では、コピー先のストレージＶＭ３００がコピー元のストレージシステム２００に対してリード要求を発行することによって、非同期リモートコピーを行う方式を説明した。当然、ストレージシステム２００がストレージＶＭ３００にライト要求を発行することによって、非同期リモートコピーを行うこともできる。この場合、ストレージＶＭ３００は、リストア済みＳＥＱ ＩＤを、ライト要求の戻り値としてストレージシステム２００に通知することができる。また、ストレージＶＭ３００が定期的にリストア済みＳＥＱ ＩＤをストレージシステム２００に通知するなどの方式でも実現され得る。

図１９は、実施例２に係るリストアプログラムのフローチャートの一例である。

リストアプログラムは、非同期リモートコピーのコピー先であるストレージＶＭ３００で実行されるプログラムである。リストアプログラムは、ＪＶＯＬ７０２からＳＶＯＬへジャーナルをリストアするプログラムである。

最初に、リストアプログラムは、到着済みＳＥＱ ＩＤビットマップをチェックし、ＳＥＱ ＩＤが隙間なく連続している範囲を特定する（Ｓ９０００）。すなわち、当該範囲のジャーナルは全てストレージＶＭ３００に到着している。

次に、リストアプログラムは、決定した範囲のジャーナルをＳＥＱ ＩＤの順にＳＶＯＬへリストアする（Ｓ９００１）。具体的には、リストアプログラムは、ジャーナルに含まれるデータをＳＶＯＬへ書き込む。書き込み先となるＳＶＯＬやＳＶＯＬ内のアドレス情報はジャーナルに含まれるＪＮＣＢに格納されており、ＪＮＣＢを参照しながら処理する。

最後に、リストア済みＳＥＱ ＩＤを更新する（Ｓ９００２）。これは、最後にリストアしたジャーナルのＳＥＱ ＩＤを、ストレージＶＭ３００の制御情報部にあるリストア済みＳＥＱ ＩＤに書き込むことを意味する。

Ｓ９００２の実行後、リストアプログラムはＳ９０００へ戻り、次のジャーナルのリストアを行う。

図２０は、実施例２に係るキャッシュパージプログラムのフローチャートの一例である。

キャッシュパージプログラム５２２は、非同期リモートコピーのコピー元であるストレージシステム２００で実行されるプログラムである。キャッシュパージプログラム５２２は、常駐Ｂｉｔ２２６ｅがＯＮのキャッシュが破棄可能となったか否かを判定し、当該キャッシュが破棄可能である場合には破棄するプログラムである。

最初に、キャッシュパージプログラム５２２は、クラウド２０へリモートコピーしているＰＶＯＬ７００を特定する（Ｓ１００００）。次に、キャッシュパージプログラム５２２は、特定したＰＶＯＬ７００のキャッシュの中から、常駐Ｂｉｔ２２６ｅがＯＮであるダーティキャッシュを探す（Ｓ１０００１）。キャッシュパージプログラム５２２は、見つけられたキャッシュに対して、キャッシュ管理テーブル２２６を参照し、最大ＳＥＱ ＩＤを取得し（Ｓ１０００２）、最大ＳＥＱ ＩＤをリストア済みＳＥＱ ＩＤと比較する（Ｓ１０００３）。

最大ＳＥＱ ＩＤがリストア済みＳＥＱ ＩＤ以下の場合、キャッシュパージプログラム５２２は、キャッシュを解放し（Ｓ１０００４）、キャッシュ管理テーブル２２６を更新する（Ｓ１０００５）。ここでキャッシュパージプログラム５２２は、キャッシュ管理テーブル２２６から当該キャッシュを管理するレコードを削除し、キャッシュアドレスをフリー状態にする。

一方で、最大ＳＥＱ ＩＤがリストア済みＳＥＱ ＩＤより大きい場合、キャッシュパージプログラム５２２は、当該キャッシュを解放することはできないため、Ｓ１０００４およびＳ１０００５をスキップする。

Ｓ１０００５の後、またはＳ１０００３で“Ｎｏ”となった場合、キャッシュパージプログラム５２２はＳ１００００へ戻り他のキャッシュデータに対してＳ１０００１からの処理を実行する。

図２０の例では、キャッシュパージプログラム５２２を定期的に実行することでキャッシュを解放する。しかし、デステージプログラムから常駐ＢｉｔがＯＮのダーティキャッシュを発見したときに、キャッシュパージプログラムをコールし、ステップＳ１０００２からＳ１０００５を実行するようにしてもよい。

本実施例によれば、ストレージシステム２００及びストレージＶＭ３００は、非同期リモートコピーを実行することにより、ＰＶＯＬ７００へ書き込まれる全てのデータをＳＶＯＬ７０３へ格納することができる。ストレージシステム２００は、ストレージＶＭ３００によりＳＶＯＬ７０３へ反映されたジャーナルの順序を示す完了情報を、ストレージＶＭ３００から受信し、完了情報に基づいて、キャッシュ上のデータのうち、ＳＶＯＬ７０３に反映されていないデータを維持する。これにより、ストレージシステム２００は、クラウド２０から更新前のデータを読み出すことを防ぐことができる。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

外部ストレージ接続機能は、外部ストレージ内のボリュームを上位ストレージへマッピングし、上位ストレージの仮想ボリュームとして使用する機能である。上位ストレージへマッピングされたボリュームは、上位ストレージによりホストへ提供され得る。上位ストレージでは、物理記憶デバイスの容量は消費されない。上位ストレージがホストからのＩＯ要求を受けると、上位ストレージが外部ストレージへ対してＩＯ要求を発行することでＩＯ要求を実現する。一般に、上位ストレージのキャッシュを活用することは可能である。本実施例のストレージシステム２００は、上位ストレージとして外部ストレージ接続機能を用いる。

図２１は、実施例３に係る計算機システムの構成を示す。

本実施例のストレージシステム２００は、クラウド２０内のストレージＶＭ３００のボリューム７０３を、オンプレミス１０内のストレージシステム２００の外部ＶＯＬ９００としてマッピングし、いわゆる外部ストレージ接続機能（デバイス仮想化機能とも呼ばれる）を用いている。

本実施例のストレージシステム２００によるリード要求およびライト要求の処理方式について説明する。

ライト要求の処理方式は、実施例２のライトプログラム５１５ｂと同様である。リード要求の処理方式は、実施例１のリードプログラム５１４において、クラウド２０内のボリューム３１０に対してリード要求を発行するＳ２００４、Ｓ２００５の処理を、外部ＶＯＬに対してリード要求を発行する処理に置き換える。ＰＶＯＬ７００に対してＩＯ要求が発行されているため、ストレージシステム２００は、ＰＶＯＬ７００のアドレスを外部ＶＯＬ９００のアドレスに置き換え、リード要求を処理する。ストレージシステム２００が外部ストレージ接続機能のリード処理を動作させることで、クラウドのボリューム７０３からデータを読み出すことができる。このように、ストレージシステム２００は、外部ストレージ接続機能を用いてリード要求を実現することができる。

なお、本実施例の計算機システムは、実施例１のような同期リモートコピーを用いてもよい。

以上の各実施例では、クラウド２０上にＨｏｔ ＤａｔａおよびＣｏｌｄ Ｄａｔａの両方が格納されている。上述したとおり、コピー元のストレージシステム２００がホスト１００から受領したライトを、継続してクラウド２０へ送り続ける。さらに、ストレージＶＭ３００は、コピー元のストレージシステム２００が受領したライトの順序に従い、ＳＶＯＬ７０３にライトデータを書き込んでいる。すなわち、ＳＶＯＬ７０３は常に一貫性を保った状態である。よって、オンプレミス１０のストレージシステム２００が障害になった場合には、クラウド２０のストレージＶＭ３００を用いて、即座に業務を継続することができる。

以上の各実施例の計算機システムは、オンプレミス１０からクラウド２０へライトデータを継続して送っているため、災害によって失われるデータは非常に少ない（ＲＰＯ（Recovery Point Objective）が良い）。公知技術のように、定期的にコピー元ストレージのスナップショットイメージをクラウドに転送する場合、災害によって失われるデータが非常に多くなる（ＲＰＯが悪い）。さらに、定期的な差分コピーによってクラウドのデータを上書きする場合、差分コピー中の障害によって、クラウドのデータは不整合となり業務を復旧することができない。また、差分コピーでクラウドのデータを上書きしない場合は、別領域に差分コピーする必要があり、追加でクラウドに容量が必要となってしまう。

以上の各実施例によれば、クラウド２０上のホストＶＭ４００で別の業務を実行することができる。例えば、クラウド上で分析処理や、テスト・開発業務などが考えられる。

クラウドのＳＶＯＬに対してスナップショットを適用し、静止化イメージを取得する。スナップショットデータに対して別の業務を実行することができる。

本発明の他のユースケースとして、ＲＯＢＯ（Remote Office and Branch Office）が考えられる。オンプレミス１０がRemote OfficeまたはBranch Officeとなり、クラウド２０がコアデータセンタとなる。クラウド２０のストレージＶＭ３００は複数のRemote OfficeまたはBranch Officeのデータを一元的に管理する。Remote OfficeまたはBranch Officeのコスト削減が実現される。さらに、クラウド上で実行される分析業務では、複数のオフィスのデータを用いた分析などが考えられる。ＰＯＳシステムもＲＯＢＯ同様にユースケケースとなり得る。

以上の各実施例では、オンプレミス１０のデータのコピー先をクラウド２０のストレージＶＭ３００としたが、コピー先はストレージシステム２００と同様の物理的なストレージシステムであってもよい。又、オンプレ側のストレージシステムもコピー先と同じ、又は、異なるクラウド上に構成されるストレージＶＭ３００でもよい。

以上の各実施例によれば、オンプレミス１０のストレージシステム２００は、ホスト１００に対して仮想ボリュームを提供し、ホスト１００からライト要求を受領した際、ライト対象アドレスが含まれる領域が高頻度アクセスの領域である場合、オンプレミス１０内の物理記憶領域およびクラウド２０内の物理記憶領域の両方を更新し、低頻度アクセスの領域である場合、クラウド２０の物理記憶領域のみを更新する。

これにより、オンプレミス１０で実行される業務への性能を維持しつつ、オンプレミス１０に格納されるデータ量の削減によるストレージコストの削減と、クラウド２０に格納されたデータを用いる業務を実現する。

ストレージシステムは、ストレージシステム２００等であってもよい。他のストレージシステムは、クラウド２０やストレージＶＭ３００等であってもよい。プロセッサは、プロセッサ２１１等であってもよい。メモリは、メモリユニット２２０等であってもよい。記憶デバイスは、物理記憶デバイス２４０等であってもよい。第一ボリュームは、仮想ボリューム２９３やＰＶＯＬ７００等であってもよい。第二ボリュームは、ボリューム３１０やＳＶＯＬ７０３等であってもよい。第一ストレージシステムは、ストレージシステム２００等であってもよい。第二ストレージシステムは、クラウド２０やストレージＶＭ３００等であってもよい。

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

１０…オンプレミス、 ２０…クラウド、 ３０…ネットワーク、 １００…ホスト、 １１０…本番業務、 １２０…ネットワーク、 ２００…ストレージシステム、 ２１１…プロセッサ、 ２２０…メモリユニット、 ２４０…物理記憶デバイス、 ２７０…保守端末、 ２９０…容量プール、 ２９１…プールボリューム、 ２９３…仮想ボリューム、 ３００…ストレージ仮想マシン、 ３１０…ボリューム、 ４００…ホスト仮想マシン、 ４１０…分析業務

Claims (15)

1. ネットワークを介して他のストレージシステムに接続されるストレージシステムであって、
   メモリと、前記メモリに記憶されるプログラムを実行するプロセッサと、記憶デバイスと、を備え、
   前記プログラムの実行により前記プロセッサは、仮想ボリュームである第一ボリュームを提供し、
   前記プロセッサは、前記第一ボリュームと、前記他のストレージシステムにより提供される第二ボリュームとのコピーペアを設定し、
   前記第一ボリュームへのライトデータは、前記コピーペアに基づいて、前記ネットワークを介して前記第二ボリュームへ転送され、
   前記プロセッサは、前記第二ボリュームへ転送されるデータの一部を前記メモリへ書き込み、前記メモリへ書き込まれたデータを前記記憶デバイスへ書き込む、
   ストレージシステム。
2. 前記仮想ボリュームは、複数の仮想記憶領域を含み、
   ライト要求により指定されたライト対象領域に関連づけられる仮想記憶領域に、前記記憶デバイスの記憶領域が割り当てられている場合、前記プロセッサは、前記ライトデータを前記メモリへ書き込み、前記メモリへ書き込まれたデータを前記記憶デバイスへ書き込む、
   請求項１に記載のストレージシステム。
3. 前記プロセッサは、前記複数の仮想記憶領域のそれぞれのアクセス頻度に基づいて各仮想記憶領域に格納されるデータを、第一グループと、前記第一グループのアクセス頻度より低いアクセス頻度を有する第二グループとの何れか一つに分類し、
   前記プロセッサは、前記第一グループに分類されたデータが前記記憶デバイスに格納されていない場合には、前記第一グループに分類されたデータを格納する仮想記憶領域に、前記第一グループに分類されたデータを格納するための記憶領域を前記記憶デバイスから割り当てる、
   請求項２に記載のストレージシステム。
4. 前記プロセッサは、前記複数の仮想記憶領域のそれぞれのアクセス頻度に基づいて各仮想記憶領域に格納されるデータを、第一グループと、前記第一グループのアクセス頻度より低いアクセス頻度を有する第二グループとの何れか一つに分類し、
   前記プロセッサは、前記第二グループに分類されたデータが前記記憶デバイスに格納されている場合には、前記記憶デバイスに格納されているデータを読み出すことなく、前記第二グループに分類されたデータを格納する仮想記憶領域への割り当てを、前記第二グループに分類されたデータを格納している前記他のストレージシステムの記憶領域に変更する、
   請求項２に記載のストレージシステム。
5. 前記ライト要求により指定されたライト対象領域に関連付けられる前記仮想記憶領域に、前記記憶デバイスの記憶領域が割り当てられていない場合、前記プロセッサは、前記記憶デバイスの記憶領域の空き領域を前記仮想記憶領域に割り当てることが可能であるか否かを判定し、
   前記空き領域を前記仮想記憶領域に割り当てることが可能であると判定された場合、前記プロセッサは、空き領域を前記仮想記憶領域に割り当て、
   前記空き領域を前記仮想記憶領域に割り当てることが不可能であると判定された場合、前記プロセッサは、前記他のストレージシステムの記憶領域を前記仮想記憶領域に割り当てる、
   請求項３に記載のストレージシステム。
6. 前記プロセッサは、前記第一ボリュームに対するリード要求を受け付け、
   前記プロセッサは、受け付けたリード要求のリード対象領域のデータが前記メモリに格納されているか否かを判定し、
   前記リード対象領域のデータが前記メモリに格納されていると判定された場合、前記プロセッサは、前記リード対象領域のデータを前記メモリからリードデータとして読み出す、
   請求項１に記載のストレージシステム。
7. 前記リード対象領域のデータが前記メモリに格納されていないと判定された場合、前記プロセッサは、前記リード対象領域に関連づけられる仮想記憶領域に、前記記憶デバイスの記憶領域及び前記他のストレージシステムの記憶領域の何れが割り当てられているかを判定し、
   前記リード対象領域に前記記憶デバイスの記憶領域が割り当てられていると判定された場合、前記プロセッサは、前記リード対象領域に割り当てられた前記記憶デバイスの記憶領域内のデータを前記リードデータとして読み出し、
   前記リード対象領域に前記他のストレージシステムの記憶領域が割り当てられていると判定された場合、前記プロセッサは、前記他のストレージシステムに前記リード対象領域のデータの読み出しを指示する、
   請求項６に記載のストレージシステム。
8. 前記プロセッサは、前記記憶デバイスに書き込まれるデータ以外のデータを、キャッシュデータとしては前記メモリに格納しない、
   請求項１記載のストレージシステム。
9. 前記プロセッサは、前記第二ボリュームに転送するライトデータを前記メモリへ書き込み、
   前記プロセッサは、前記メモリに格納されたライトデータのうち、前記他のストレージシステムの記憶デバイスの記憶領域が割り当てられる前記仮想記憶領域のデータを、前記記憶デバイスへ書き込むことなく破棄する、
   請求項３に記載のストレージシステム。
10. 前記プロセッサは、前記第一ボリュームへの前記ライトデータを前記メモリへ書き込み、
    前記プロセッサは、前記ライト要求と、前記ライト要求の順序を示す順序情報とを含むジャーナルを作成し、
    前記プロセッサは、前記作成されたジャーナルを前記他のストレージシステムへ転送することで、前記他のストレージシステムに、前記転送されたジャーナルを前記第二ボリュームへ反映させる、
    請求項１に記載のストレージシステム。
11. 前記プロセッサは、前記他のストレージシステムにより前記第二ボリュームへ反映されたジャーナルの順序を示す完了情報を、前記他のストレージシステムから受信し、
    前記プロセッサは、前記完了情報に基づいて、前記メモリに格納されたライトデータのうち前記第二ボリュームへ反映されていないデータを維持する、
    請求項１０に記載のストレージシステム。
12. 前記プロセッサは、前記第二ボリューム内のアドレスを前記第一ボリューム内のアドレスにマッピングし、
    前記プロセッサは、前記第一ボリュームに対するリード要求を受け付け、
    前記プロセッサは、前記リード要求のリード対象領域に前記他のストレージシステムの記憶デバイスの記憶領域が割り当てられている場合、前記マッピングに基づいて、前記リード要求により指定されたアドレスを、前記第二ボリューム内のアドレスに変換し、
    前記プロセッサは、前記変換されたアドレスを用いて、前記第二ボリュームから前記リード対象領域のデータを読み出す、
    請求項１に記載のストレージシステム。
13. 第一ストレージシステムと、
    ネットワークを介して前記第一ストレージシステムに接続される第二ストレージシステムと、
    を備え、
    前記第一ストレージシステムは、仮想ボリュームである第一ボリュームを提供し、
    前記第二ストレージシステムは、第二ボリュームを提供し、
    前記第一ストレージシステムは、前記第一ボリュームと前記第二ボリュームとのコピーペアを設定し、
    前記第一ボリュームへのライトデータは、前記コピーペアに基づいて、前記ネットワークを介して前記第二ボリュームへ転送され、
    前記第一ストレージシステムは、前記第二ボリュームへ転送されるデータの一部を前記第一ストレージシステム内のメモリへ書き込み、前記メモリへ書き込まれたデータを前記第一ストレージシステム内の記憶デバイスへ書き込む、
    計算機システム。
14. ストレージシステムの制御方法であって、
    仮想ボリュームである第一ボリュームを提供し、
    前記第一ボリュームと、ネットワークを介して前記ストレージシステムに接続される他のストレージシステムにより提供される第二ボリュームとのコピーペアを設定し、前記第一ボリュームへのライトデータは、前記コピーペアに基づいて、前記ネットワークを介して前記第二ボリュームへ転送され、
    前記第二ボリュームへ転送されるデータの一部を前記ストレージシステム内のメモリへ書き込み、前記メモリへ書き込まれたデータを前記ストレージシステム内の記憶デバイスへ書き込む、
    ことを備える制御方法。
15. 前記仮想ボリュームは、複数の仮想記憶領域を含み、
    ライト要求により指定されたライト対象領域に関連づけられる仮想記憶領域に、前記記憶デバイスの記憶領域が割り当てられている場合、前記ライトデータを前記メモリへ書き込み、前記メモリへ書き込まれたデータを前記記憶デバイスへ書き込むことを更に備える、
    請求項１４に記載の制御方法。

Images