特許第6811739号(P6811739)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧
特許6811739ストレージシステム、およびストレージシステムの制御方法
<>
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000002
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000003
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000004
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000005
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000006
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000007
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000008
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000009
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000010
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000011
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000012
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000013
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000014
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000015
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000016
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000017
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000018
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000019
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000020
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000021
  • 特許6811739-ストレージシステム、およびストレージシステムの制御方法 図000022
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6811739
(24)【登録日】2020年12月17日
(45)【発行日】2021年1月13日
(54)【発明の名称】ストレージシステム、およびストレージシステムの制御方法
(51)【国際特許分類】
   G06F 3/06 20060101AFI20201228BHJP
   G06F 13/10 20060101ALI20201228BHJP
   G06F 16/13 20190101ALI20201228BHJP
【FI】
   G06F3/06 304F
   G06F13/10 340A
   G06F3/06 301M
   G06F3/06 301X
   G06F16/13 100
【請求項の数】11
【全頁数】34
(21)【出願番号】特願2018-64354(P2018-64354)
(22)【出願日】2018年3月29日
(62)【分割の表示】特願2017-511367(P2017-511367)の分割
【原出願日】2015年9月15日
(65)【公開番号】特開2018-129074(P2018-129074A)
(43)【公開日】2018年8月16日
【審査請求日】2018年9月13日
【前置審査】
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110000279
【氏名又は名称】特許業務法人ウィルフォート国際特許事務所
(72)【発明者】
【氏名】出口 彰
(72)【発明者】
【氏名】川口 智大
【審査官】 三坂 敏夫
(56)【参考文献】
【文献】 特開2014−089747(JP,A)
【文献】 国際公開第2013/076872(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 3/06
G06F 13/10
G06F 16/13
(57)【特許請求の範囲】
【請求項1】
ネットワークを介して他のストレージシステムに接続されるストレージシステムであって、
メモリと、プログラムを実行するプロセッサと、データを記憶する記憶デバイスと、を備え、
外部装置に提供する第1のボリュームと、前記他のストレージシステムに転送するデータを格納するジャーナルボリュームとを有し、
前記プロセッサは、
前記外部装置から、前記第1のボリュームへのライト要求にかかるライトデータを受信し、
受信した前記ライトデータを前記ストレージシステム内に保持するとともに、前記ライトデータとメタデータとを含むジャーナルを作成して前記ジャーナルボリュームに格納して、前記外部装置にライト要求の応答を行い、
前記他のストレージシステムからジャーナル転送要求を受信した場合に、前記ジャーナルボリュームに格納したジャーナルを転送し、
前記他のストレージシステムが前記ライトデータを格納した後に、前記ストレージシステムが保持したライトデータのうち、前記ストレージシステムへの格納対象となっていないライトデータを削除する
ことを特徴とするストレージシステム。
【請求項2】
請求項1において、
前記第1のボリュームは、前記ストレージシステムの記憶デバイスへの格納対象となっているライトデータを格納する領域と、前記ストレージシステムの記憶デバイスへの格納対象となっていないライトデータを格納する領域と、を有する
ことを特徴とするストレージシステム。
【請求項3】
請求項1において、
前記ライトデータへのアクセス頻度に基づいて、前記ストレージシステムの記憶デバイスを格納先とするかを判断する
ことを特徴とするストレージシステム。
【請求項4】
請求項1において、
前記受信したライトデータを、前記メモリに格納し、
前記ライトデータが、前記ストレージシステムの記憶デバイス及び他のストレージシステムに格納するデータである場合、前記記憶デバイスに格納した場合に前記メモリから削除可能にし、
前記ライトデータが、前記他のストレージシステムに格納し前記ストレージシステムの記憶デバイスには格納しないデータである場合、前記メモリに格納したライトデータを、前記他のストレージシステムが格納するまで前記メモリで維持する
ことを特徴とするストレージシステム。
【請求項5】
請求項1において、
前記メタデータには、前記ライトデータを外部装置から受信した順序にかかるライト順序情報が含まれていることを特徴とするストレージシステム。
【請求項6】
請求項5において、
前記ジャーナル転送要求には、前記他のストレージシステムに格納したライトデータにかかるライト順序情報が含まれており、
前記プロセッサは、前記ジャーナルのライト順序情報と、前記ジャーナル転送要求のライト順序情報とを比較することにより、前記ストレージシステム内に保持したライトデータを削除可能か判断する
ことを特徴とするストレージシステム。
【請求項7】
請求項1において、
前記プロセッサは、
外部装置から前記第1のボリュームへのリード要求を受信し、
受信した前記リード要求にかかるライトデータが前記ストレージシステム内に保持されている場合、当該保持されたライトデータを前記外部装置に送信し、前記リード要求にかかるライトデータが前記ストレージシステム内に保持されていない場合、前記他のストレージシステムから前記ライトデータを取得して前記外部装置に送信する
ことを特徴とするストレージシステム。
【請求項8】
請求項7において、
前記第1のボリュームは、前記記憶デバイスにマッピングされた第1の記憶領域と、第2の記憶領域と、を有し、
前記第1のボリュームの第2の記憶領域と、前記他のストレージシステムのボリュームと、にマッピングした第2のボリュームを有し、
前記第1のボリュームの第2の記憶領域にアクセスすることで、前記他のストレージシステムのライトデータを取得する
ことを特徴とするストレージシステム。
【請求項9】
請求項1において、
前記ライトデータは、前記記憶デバイス及び前記他のストレージシステムに格納される第1のグループと、前記記憶デバイスに格納されず前記他のストレージシステムに格納される第2のグループと、に分類され、
前記第1のグループから前記第2のグループへ変更されたライトデータは、前記記憶デバイスから削除される
ことを特徴とするストレージシステム。
【請求項10】
請求項1において、
前記ライトデータは、前記記憶デバイス及び前記他のストレージシステムに格納される第1のグループと、前記記憶デバイスに格納されず前記他のストレージシステムに格納される第2のグループと、に分類され、
前記他のストレージシステムに格納された第1のグループ及び第2のグループのライトデータは、前記他のストレージシステムにより分析業務に提供される
ことを特徴とするストレージシステム。
【請求項11】
ネットワークを介して他のストレージシステムに接続されるストレージシステムの制御方法であって、
前記ストレージシステムは、
メモリと、プログラムを実行するプロセッサと、データを記憶する記憶デバイスと、を備え、
外部装置に提供する第1のボリュームと、前記他のストレージシステムに提供するジャーナルボリュームとを提供し、
前記プロセッサは、
前記外部装置から、前記第1のボリュームへのライト要求にかかるライトデータを受信し、
受信した前記ライトデータを前記ストレージシステム内に保持するとともに、前記ライトデータとメタデータとを含むジャーナルを作成して前記ジャーナルボリュームに格納して、前記外部装置にライト要求の応答を行い、
前記他のストレージシステムからジャーナル転送要求を受信した場合に、前記ジャーナルボリュームに格納したジャーナルを転送し、
前記他のストレージシステムが前記ライトデータを格納した後に、前記ストレージシステムが保持したライトデータのうち、前記ストレージシステムへの格納対象となっていないライトデータを削除する
ことを特徴とするストレージシステムの制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ストレージシステムに関する。
【背景技術】
【0002】
大規模なデータを扱う計算機システムは、ホスト計算機とは別個に設けられた大容量のストレージシステム(例えばクラウドストレージ)を用いてデータを管理している。クラウドストレージの活用形態の一つとして、顧客のデータセンタ(以後、オンプレミスと呼ぶ)に配置されているストレージがクラウドストレージへのデータの格納を制御するものがある。すなわち、ホスト計算機はクラウドストレージを意識しない。
【0003】
更に、クラウド上の計算機や仮想マシンがクラウド上に格納されるデータを用いて業務を実行する場合もある。これにより、データの分析処理のように、一度に大量のリソースを使う業務を、低コストで実現できる。
【0004】
特許文献1は、オンプレミスのストレージのデータの複製をクラウドに格納する技術を開示している。オンプレミスとクラウドの差分データを定期的にクラウドに格納する。また、この技術は、クラウドへの格納において、オンプレミス側で圧縮、暗号化などを行い、オンプレミスのストレージによって認識されるデータ構造を採用している。また、複数のクラウドにデータを格納することができる。
【0005】
また、ストレージにおいて記憶デバイスを仮想化するデバイス仮想化機能(外部ストレージ接続機能)が知られている。デバイス仮想化機能は、外部ストレージの記憶デバイスを上位ストレージにマッピングし、上位ストレージのデータとしてホストへ提供する機能である。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】米国特許出願公開第2014/0245026号明細書
【発明の概要】
【発明が解決しようとする課題】
【0007】
特許文献1の技術は、オンプレミスのストレージに格納されるデータのコピーをバックアップとしてクラウドに格納する。このため、オンプレミスストレージのデータ量を削減による低コスト化を実現することはできない。
【0008】
又、特許文献1の技術では、クラウド上のデータを用いて、クラウド側での業務の実行を前提としておらず、例えばクラウド上の仮想マシンから認識可能なデータ構造を採用していないためクラウド上の仮想マシンによる業務再開ができない。
【0009】
さらに、オンプレミスのストレージからクラウドのストレージへ定期的に差分データのみを転送するため、障害時にクラウドストレージ側に反映されていないデータは失われる可能性がある。
【0010】
一方、上述のデバイス仮想化機能を用いて、クラウド上のストレージを外部ストレージとしてオンプレのストレージにマッピングすることで、オンプレミスの容量を削減することができる。しかし、ホスト計算機から発行される全てのI/O処理のためにクラウド側へのアクセスが生じるために性能が著しく低下してしまう。
【課題を解決するための手段】
【0011】
上記課題を解決するために、本発明の一態様であるストレージシステムは、ネットワークを介して他のストレージシステムに接続されるストレージシステムであって、メモリと、前記メモリに記憶されるプログラムを実行するプロセッサと、記憶デバイスと、を備える。前記プログラムの実行により前記プロセッサは、仮想ボリュームである第一ボリュームを提供し、前記プロセッサは、前記第一ボリュームと、前記他のストレージシステムにより提供される第二ボリュームとのコピーペアを設定し、前記第一ボリュームへのライトデータは、前記コピーペアに基づいて、前記ネットワークを介して前記第二ボリュームへ転送され、前記プロセッサは、前記第二ボリュームへ転送されるデータの一部を前記メモリへ書き込み、前記メモリへ書き込まれたデータを前記記憶デバイスへ書き込む。
【発明の効果】
【0012】
オンプレミスのストレージ装置の容量の節約と、オンプレミスのストレージ装置の高アクセス性能と、オンプレミスのリソースに障害があったとき、クラウド上のデータを用いて、高速かつ正確に業務を再開することとを実現することができる。
【図面の簡単な説明】
【0013】
図1】実施例1に係る計算機システムの構成を示す。
図2】ストレージシステム200の構成を示す。
図3】メモリユニット220の詳細の一例を示す。
図4】仮想ボリューム293、容量プール290、プールボリューム291の関係を説明する図である。
図5】プールテーブル224の一例を示す。
図6】仮想ボリュームテーブル225の一例を示す。
図7】キャッシュ管理テーブル226の一例を示す。
図8】実施例1に係るライトプログラムのフローチャートの一例である。
図9】実施例1に係るリードプログラムのフローチャートの一例である。
図10】実施例1に係るデステージプログラム516のフローチャートの一例である。
図11】実施例1に係るティアリングプログラムのフローチャートの一例である。
図12】実施例1に係るデモーションプログラムのフローチャートの一例である。
図13】実施例1に係るプロモーションプログラムのフローチャートの一例である。
図14】実施例2に係る計算機システムの構成を示す。
図15】非同期リモートコピーの一例を示す。
図16】実施例2に係るライトプログラムのフローチャートの一例である。
図17】実施例2に係るリードジャーナルプログラムのフローチャートの一例である。
図18】実施例2に係るジャーナル転送プログラムのフローチャートの一例である。
図19】実施例2に係るリストアプログラムのフローチャートの一例である。
図20】実施例2に係るキャッシュパージプログラムのフローチャートの一例である。
図21】実施例3に係る計算機システムの構成を示す。
【発明を実施するための形態】
【0014】
以下、図面を参照して本発明の実施形態を説明する。
【0015】
以下の説明では、「×××テーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「×××テーブル」を「×××情報」と呼ぶことができる。また、以下の説明において、各テーブルの構成は一例であり、1つのテーブルは、2以上のテーブルに分割されてもよいし、2以上のテーブルの全部又は一部が1つのテーブルであってもよい。
【0016】
また、以下の説明では、要素の識別情報として、IDが使用されるが、それに代えて又は加えて他種の識別情報が使用されてもよい。
【0017】
また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号又は参照符号における共通番号を使用し、同種の要素を区別して説明する場合は、その要素の参照符号を使用又は参照符号に代えてその要素に割り振られたIDを使用することがある。
【0018】
また、以下の説明では、I/O(Input/Output)要求は、ライト要求又はリード要求であり、アクセス要求と呼ばれてもよい。
【0019】
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ(例えばCPU(Central Processing Unit))によって実行されることで、定められた処理を、適宜に記憶資源(例えばメモリ)及び/又はインターフェースデバイス(例えば通信ポート)等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理又はシステムとしてもよい。また、プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ(例えばCPU)と記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布してよい。また、以下の説明において、2以上のプログラムが1つのプログラムとして実現されてもよいし、1つのプログラムが2以上のプログラムとして実現されてもよい。
【0020】
また、以下の説明では、管理システムは、一以上の計算機で構成されてよい。具体的には、例えば、管理計算機が情報を表示する場合(具体的には、例えば、管理計算機が自分の表示デバイスに情報を表示する、或いは、管理計算機が表示用情報を遠隔の表示用計算機に送信する場合)、管理計算機が管理システムである。また、例えば、複数の計算機で管理計算機と同等の機能が実現されている場合は、当該複数の計算機(表示を表示用計算機が行う場合は表示用計算機を含んでよい)が、管理システムである。管理計算機(例えば管理システム)は、表示システムを含むI/Oシステムに接続されたインタフェースデバイスと、記憶資源(例えばメモリ)と、インタフェースデバイス及び記憶資源に接続されたプロセッサとを有してよい。表示システムは、管理計算機が有する表示デバイスでもよいし、管理計算機に接続された表示用計算機でもよい。I/Oシステムは、管理計算機が有するI/Oデバイス(例えばキーボード及びポインティングデバイス、タッチパネル)でもよいし、管理計算機に接続された表示用計算機又は別の計算機でもよい。管理計算機が「表示用情報を表示する」ことは、表示システムに表示用情報を表示することであり、これは、管理計算機が有する表示デバイスに表示用情報を表示することであってもよいし、管理計算機が表示用計算機に表示用情報を送信することであってもよい(後者の場合は表示用計算機によって表示用情報が表示される)。また、管理計算機が情報を入出力するとは、管理計算機が有するI/Oデバイスとの間で情報の入出力を行うことであってもよいし、管理計算機に接続された遠隔の計算機(例えば表示用計算機)との間で情報の入出力を行うことであってもよい。情報の出力は、情報の表示であってもよい。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
【実施例1】
【0021】
以下、実施例1の計算機システムの構成について説明する。
【0022】
図1は、実施例1に係る計算機システムの構成を示す。
【0023】
本実施例の計算機システムは、オンプレミス10と、クラウド20とを含む。オンプレミス10とクラウド20は、ネットワーク30を介して接続されている。
【0024】
オンプレミス10は、ストレージシステム200と、当該ストレージシステムにデータを保存するホスト100とを含む。ホスト100は、本番業務110を実行する。当該業務で使用されるデータがストレージシステム200に格納される。ホスト100とストレージシステム200はネットワーク120で接続されている。ストレージシステム200は、ストレージ装置と呼ばれることがある。
【0025】
クラウド20は、ストレージを提供するための仮想マシン300(以後、ストレージ仮想マシンまたはストレージVMと呼ぶ)と、当該ストレージにアクセスするためのホスト仮想マシン400(以後、ホストVM)とを実行する。ホストVM400は、ホスト100の業務と別の業務や、災害後にホスト100の業務を引き継ぐVMである。ホストVM400の業務は、例えば、ストレージVM300によりクラウド20内に格納されたデータの分析業務410である。なお、ストレージVM300は、物理的なストレージ装置や計算機、ストレージ機能を提供するコンテナであってもよい。ホストVM400は、物理的な計算機、コンテナであってもよい。ストレージVM300によって分析業務410などが実行されてもよい。すなわち、ストレージVM300とホストVM400が同一のVMであってもよい。
【0026】
ストレージシステム200は、物理記憶デバイスを用いて、仮想ボリューム293と容量プール290を作成する。容量プール290は、ストレージシステム200に搭載されているHDD(Hard Disk Drive)などの物理記憶デバイスに対応付けられ、物理的な容量を有する。仮想ボリューム293は、仮想的なストレージ領域であるが、通常のボリュームと同等にホスト100に提供される記憶領域である。ホスト100は、仮想ボリューム293を、通常のボリュームと同等に扱うことができる。ストレージシステム200は、ホスト100から仮想ボリューム293へのライト要求を受け付けた時、容量プール290から領域を確保し、ライト要求に示されたアドレスと関連付ける。ライトデータ自体は、容量プール290に格納される。本実施例で、仮想ボリューム293にデータを格納するとは、仮想ボリューム293のデータとしてストレージシステム200内のキャッシュにデータを格納すること、または、仮想ボリューム293に対応する容量プール290にデータを格納することを意味する。物理記憶デバイスを、記憶デバイスと呼ぶことがある。
【0027】
本実施例の仮想ボリューム293に格納されるデータは、少なくともアクセス頻度が高いHot Dataおよびアクセス頻度がHot Dataより低いCold Dataとに分類される。その判断は例えば各データのアクセス頻度から判断する。ホスト100に対してはHot DataおよびCold Dataが仮想ボリューム293を介して提供されているが、物理的にはHot Dataのみがストレージシステム200の容量プール290に格納される。図の例では、Cold Dataはクラウド20上のストレージに格納される。つまり、クラウド上のボリューム310を仮想ボリューム293にマッピングすることで、クラウド上のストレージ領域を、オンプレミスのストレージの領域としてホスト計算機に提供している。当然、ホスト100は、仮想ボリューム293へのアクセス要求によってCold Dataにもアクセスすることができる。Cold Dataへのアクセス要求を受領したストレージシステム200はネットワーク30を介してクラウド20内のCold Dataへアクセスし、ホスト100へCold Dataを転送する。
【0028】
ストレージシステム200は、クラウド20のストレージVM300とネットワーク30で接続されている。Cold DataはストレージVM300に格納される。
【0029】
次に、クラウド20のストレージVM300について説明する。ストレージVM300はクラウド20上のVMまたはハイパーバイザーであり、ストレージの処理を実行するためのプログラムがインストールされている。
【0030】
ストレージVM300は、クラウド20内の物理記憶デバイスを用いてボリューム310を作成する。ストレージVM300は、仮想ボリューム293とボリューム310をペア関係40(コピーペア)によって関連付ける。ストレージシステム200およびストレージVM300の両方がペア関係を管理する。ボリューム310にはHot DataおよびCold Dataの両方が格納される。ボリューム310内のHot Dataは、仮想ボリューム293内のHot Dataの複製である。ボリューム310内のCold Dataは、仮想ボリューム293内のCold Dataに対応する。
【0031】
また、図の例では、ストレージVM300は、仮想ボリュームではなく通常のボリューム310を作成する。なお、ストレージVM300のボリューム310も仮想ボリュームであってもよい。すなわち、ストレージVM300もストレージシステム200と同様に、容量プールを有し、当該容量プールにHot DataとCold Dataの両方が格納されてもよい。この場合、ストレージVM300の仮想ボリュームは、容量プールのHot DataとCold Dataに対応する。
【0032】
計算機システム全体としては、Hot Dataはストレージシステム200とストレージVM300の両方に格納され、Cold DataはストレージVM300のみに格納される。
【0033】
Cold Dataはアクセス頻度の低いデータである。このため、この構成によれば、本番業務110の性能を維持しつつ、Cold Dataをクラウド20へ格納することによりコストを削減できる。また、クラウド20にHot DataおよびCold Dataの両方を格納することにより、迅速にクラウド20で別業務を実行することができ、災害時に業務を復旧することができる。
【0034】
図2は、ストレージシステム200の構成を示す。
【0035】
ストレージシステム200は、1以上のマイクロプロセッサパッケージ(MPPK)210と、メモリユニット220と、バックエンドパッケージ(BEパッケージ)230と、フロントエンドパッケージ(FEパッケージ)260とを有する。MPPK210と、メモリユニット220と、BEパッケージ230と、FEパッケージ260とは、内部バス280を介して互いに接続されており、コントローラと呼ばれることがある。メモリユニット220は、メモリと呼ばれることがある。
【0036】
FEパッケージ260は、ポート261と、メモリ262とを有する。ポート261は、ネットワーク120を介して、ホスト100と接続され、ホスト100との間の通信を仲介する。さらに、ポート261は、ネットワーク30を介して、ストレージVM300と接続され、ストレージVM300との間の通信を仲介する。本実施例では、ホスト100とストレージVM300は、異なるポート261に接続されているが、スイッチなどを用いて同一のポート261に接続されてもよい。メモリ262は、FEパッケージ260の処理に必要な各種データを記憶する。たとえば、メモリ262は、ホスト100から転送されたデータや、ホスト100へ転送するデータを一時的に格納するために使用される。メモリ262は、同様にストレージVM300へ転送するデータやストレージVM300から転送されたデータを格納するためにも使用され得る。
【0037】
メモリユニット220は、例えば、1以上のメモリデバイスにより構成され、制御情報を記憶する制御情報部221と、プログラムを記憶するプログラム部222と、データをキャッシュするキャッシュメモリの一例としてのキャッシュ部223とを有する。なお、キャッシュ部223の容量は、一般的には、ボリューム250の容量よりも小さくなっている。キャッシュ部223を、キャッシュやキャッシュメモリと呼ぶことがある。
【0038】
MPPK210は、プロセッサ211と、ローカルメモリ212と、保守ポート213とを有する。プロセッサ211と、ローカルメモリ212と、保守ポート213とは、内部バス214を介して接続されている。ローカルメモリ212は、MPPK210において必要な各種データを記憶する。保守ポート213は、保守端末270との通信を仲介する。プロセッサ211は、各種処理を実行する。プロセッサ211は、メモリユニット220のプログラム部222に格納された各種プログラムを実行することにより各種処理を実行する。また、プロセッサ211は、メモリユニット220の制御情報部221に格納されている各種情報を用いて各種処理を実行する。
【0039】
BEパッケージ230は、ポート231と、メモリ232とを有する。ポート231は、1以上の物理記憶デバイス240の一例としてのHDDに、バス283を介して接続されている。例えば、データを管理するボリューム250には、1以上の物理記憶デバイス240内の記憶領域が割り当てられる。なお、物理記憶デバイスとしては、HDDに限らず、例えば、SSD(Solid State Drive)、DVD、SCM(Storage Class Memory)などであってもよい。また、1つ以上の物理記憶デバイス240をパリティグループという単位でまとめて、RAID(Redundant Arrays of Independent Disks)のような高信頼化技術を使用してもよい。
【0040】
ストレージシステム200には、例えば、バス280を介して、ストレージシステム200を保守するための保守端末270が接続される。保守端末270は、CPU271と、メモリ272と、入出力部274と、保守ポート275とを有する。メモリ272は、保守用のプログラム(保守プログラム)273を記憶する。CPU271は、保守プログラム273を実行することにより保守処理を実行する。入出力部274は、例えば、マウス、キーボード、ディスプレイ等により構成され、保守を行うオペレータによる各種指示入力を受け付けるとともに、各種情報をディスプレイに表示させる。保守ポート275は、ストレージシステム200との間の通信を仲介する。計算機システムは、保守端末270の代わりに、ネットワークを介してストレージシステムに接続される管理サーバを含んでもよい。
【0041】
なお、本実施例のストレージシステム200は、一般的なサーバなどにストレージの処理を実行するためのプログラムをインストールしたものであってもよい。ストレージの処理とは、リード要求やライト要求、上述したRAIDなどを制御する処理である。
【0042】
ストレージVM300の構成について説明する。クラウド20は、少なくとも一つの計算機を含む。計算機の代わりにストレージシステム200と同様のシステムが用いられてもよい。計算機は、プロセッサと、プロセッサに接続されるメモリと、プロセッサに接続される物理記憶デバイスとを含む。プロセッサは、ストレージVM300やホストVM400を実行する。ストレージVM300は、ストレージシステム200の構成と同様の構成を有している。一般的に、クラウドベンダが提供するVMはプロセッサ資源、メモリ資源、通信用ポートを含んでいる。また、ストレージVM300の機能はサービスとして提供される可能性があるが、ホストVM400に対して関連付けられ、ホストVM400の記憶デバイスとして使用できる。すなわち、バックエンドパッケージおよびHDDがストレージサービスに置き換えられる。また、ストレージVM300やホストVM400等のVMの各種資源は、仮想的に提供される可能性がある。
【0043】
図3は、メモリユニット220の詳細の一例を示す。
【0044】
メモリユニット220の制御情報部221には、プールテーブル224、仮想ボリュームテーブル225、キャッシュ管理テーブル226、ペアテーブル227が格納される。ペアテーブル227の詳細については、公知のリモートコピーシステムにおいてペアを管理するテーブルと同様であるため、省略する。
【0045】
メモリユニット220のプログラム部222には、ティアリングプログラム511、プロモーションプログラム512、デモーションプログラム513、リードプログラム514、ライトプログラム515、デステージプログラム516、ジャーナル転送プログラム521、キャッシュパージプログラム522が格納されている。なお、実施例1のプログラム部222は、ジャーナル転送プログラム521、キャッシュパージプログラム522を格納しなくてもよい。
【0046】
図4は、仮想ボリューム293、容量プール290、プールボリューム291の関係を説明する図である。
【0047】
ストレージシステム200は、複数の物理記憶デバイス240の物理記憶領域からプールボリューム291を作成する。容量プール290は、一つ以上のプールボリューム291を含む。プールボリューム291には、仮想ボリューム293への割当単位となる物理記憶領域であるページ292が含まれる。ページ292の容量は、例えば、数KB〜数十MBである。
【0048】
仮想ボリューム293内の仮想記憶領域に対して、データの書き込みがあると、ストレージシステム200は、その仮想記憶領域に対して、プールボリューム291内のページ292を割当てる。すなわち、仮想ボリューム293の使用されていない領域については、ページ292が割り当てられていないので、物理記憶デバイス240の物理記憶領域は消費されない。
【0049】
図5は、プールテーブル224の一例を示す。
【0050】
プールテーブル224は、容量プール290における各ページ292を管理するテーブルであり、例えば、メモリユニット220の制御情報部221に格納される。
【0051】
プールテーブル224は、ページ番号224aと、開始アドレス224bと、終了アドレス224cと、状態224dと、割当先224eとのフィールドを対応付けたレコード(エントリ)を管理する。ページ番号224aには、容量プール290におけるページ292を識別するページ番号を格納する。ページ292の領域を識別するために、開始アドレス224bと終了アドレス224cが用いられる。このアドレスは、容量プール290全体を管理するアドレスである。当然、ページ292の領域は、プールボリューム番号およびプールボリューム内アドレスによって管理されてもよい。ページサイズが固定長であれば、終了アドレス224cを必要としない。
【0052】
開始アドレス224bには、対応するページ292の開始アドレスが格納される。終了アドレス224cには、対応するページ292の終了アドレスが格納される。状態224dには、対応するページ292が仮想ボリューム293に割当て済みか、未割当てかを示す情報が格納される。割当先224eには、対応するページ292が割当てられた仮想ボリューム番号が格納される。プールテーブル224の一番上のレコードによると、ページ番号が“1”であるページは、開始アドレスが“0”であり、終了アドレスが“99”であり、仮想ボリューム番号が“1”である仮想ボリュームに割当て済みであることがわかる。未割当のページ番号を管理するテーブルなどを有してもよい。その場合、高速に未割当ページを検索することが可能となる。
【0053】
図6は、仮想ボリュームテーブル225の一例を示す。
【0054】
仮想ボリュームテーブル225は、仮想ボリューム293に対するページ292の割当てを管理するテーブルであり、例えば、メモリユニット220の制御情報部221に格納される。
【0055】
仮想ボリュームテーブル225は、仮想ボリューム番号225aと、アドレス225bと、ページ割当て状態225cと、ページ番号225dと、リード頻度(回/hr)225eと、ライト頻度(回/hr)225fのフィールドを含むレコードを管理する。仮想ボリューム293内のアドレス範囲は、ページ292と同じ大きさの仮想記憶領域に分割されている。一つのレコードは、一つの仮想記憶領域を示す。この仮想記憶領域は、仮想ページとも呼ばれてもよい。
【0056】
仮想ボリューム番号225aには、仮想ボリューム293を識別する仮想ボリューム番号が格納される。アドレス225bには、対応する仮想ボリューム293内のアドレスの範囲が格納される。ページ割当て状態225cには、対応するアドレスの範囲で示された仮想記憶領域に対してページが割当て済みか否かを示す情報が格納される。ここで、仮想記憶領域に割り当てられるページは、容量プール290内のページ292に対応する場合と、容量プール290内のページ292に対応しない場合とがある。ページ番号225dには、当該仮想記憶領域に割当てられたページのページ番号、または当該仮想記憶領域に割当てられたページが容量プール290内のページ292に対応しないことを示す識別子が格納される。当該仮想記憶領域に格納されるデータがHot Dataである場合、そのデータは物理的には容量プール290に格納されている。当該仮想記憶領域に格納されるデータがCold Dataである場合、そのデータは物理的には容量プール290に格納されておらず、クラウド20のボリューム310に格納されている。この場合、ページ番号225dには、容量プール290内のページ292ではなく、クラウド20を示す情報、例えば“Cloud”が格納されるものとする。
【0057】
リード頻度(回/hr)225eは、対応する領域に対して、単位時間あたりに発行されたリードの回数が格納される。ライト頻度(回/hr)225fは、対応する領域に対して、単位時間あたりに発行されたライトの回数が格納される。本例では、単位時間を1時間としたが、1日でも、1分でも、1秒でもよい。ストレージシステム200は、各仮想記憶領域のアクセス頻度(リード頻度およびライト頻度)を測定し、仮想ボリュームテーブル225を更新する。
【0058】
仮想ボリュームテーブル225の一番上のレコードによると、仮想ボリューム番号が“1”の仮想ボリュームの0〜99のアドレスの領域には、ページ番号“2”のページ292が割当てられており、リード頻度、ライト頻度が他のアドレスに比べて高いことがわかる。
【0059】
図7は、キャッシュ管理テーブル226の一例を示す。
【0060】
キャッシュ管理テーブル226は、ボリューム番号226a、ボリュームアドレス226b、キャッシュアドレス226c、ダーティ226d、常駐Bit226e、最大SEQ ID226fのフィールドを有するレコードを管理する。本実施例におけるキャッシュ管理テーブル226は、常駐Bit226e、最大SEQ ID226fを含まなくてもよい。
【0061】
ボリューム番号226aは、ボリュームの識別番号である。ボリュームアドレス226bはボリューム番号によって識別されるボリュームのアドレスを管理している。キャッシュアドレス226cは、ボリュームアドレスによって特定される領域のキャッシュデータが格納されているキャッシュ部のアドレスを管理する。ダーティ226dは、キャッシュされているデータがダーティキャッシュであるかクリーンキャッシュであるかを管理している。“ON”はダーティ、“OFF”はクリーンを意味する。常駐Bit226e、最大SEQ ID226fについては、実施例2で説明する。ダーティとはキャッシュには書き込まれているが、HDDに書き込まれていないキャッシュデータのことである。ライト要求によってダーティキャッシュが発生する。一方、クリーンとは、キャッシュのデータとHDDのデータが一致していることを意味する。リード要求によってクリーンキャッシュが発生する。
【0062】
ストレージシステム200は、キャッシュされていない領域に対してライトデータまたはリードデータをキャッシュに格納すると、キャッシュ管理テーブル226の一つのレコードを作成する。キャッシュ領域が解放された時に、対象となるレコードが削除される。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
【0063】
以下、各プログラムの動作について説明する。
【0064】
図8は、実施例1に係るライトプログラムのフローチャートの一例である。
【0065】
ライトプログラム515は、ホスト100から仮想ボリューム293へのライト要求を受領し、ライトデータをストレージシステム200内のボリュームに格納する。
【0066】
最初に、ライトプログラム515はホスト100からライト要求を受領する(S1000)。ライト要求は、ライトデータ、ライト対象ボリューム番号(本実施例の場合、仮想ボリューム番号)、ライトアドレス、ライト長などの情報を含む。
【0067】
次に、ライトプログラム515は、仮想ボリュームテーブル225にアクセスし、ライト対象アドレスに、ページ292が割り当てられているか否かを判定する(S1001)。ページ292が割り当てられている場合、ライトプログラム515は、S1002へ進む。ページ292が割り当てられていない場合、ライトプログラム515は、S1003へ進む。
【0068】
S1002で、ライトプログラム515は、仮想ボリュームテーブル225のページ番号の値をチェックし、ページ292がオンプレミス10のストレージシステム200か、クラウド20のストレージVM300のどちらに格納されているかを判定する(S1002)。ページ292がオンプレミス10にある場合、S1005へ進み、キャッシュにライトデータを格納する(S1005)。
【0069】
一方で、ページがクラウドにある場合、ライトプログラム515は、S1005をスキップし、クラウド20に対してライト要求を発行する(S1006)。
【0070】
ページ292が割り当てられておらず、S1003へ進んだ場合、ライトプログラム515は、容量プール290に空きページがあるかどうかをチェックする(S1003)。これは、プールテーブル224の状態をチェックすることで実現される。空きページが存在しない場合、ライトプログラム515はS1006へ進み、クラウド20にライト要求を発行する(S1006)。一方、空きページが存在する場合、ライトプログラム515は、ライト対象アドレスを含む領域にページ292を割り当て(S1004)、キャッシュにライトデータを格納する(S1005)。ページ割り当ての処理は、プールテーブル224の状態224d、割当先224eの更新と、仮想ボリュームテーブル225のページ割当て状態225c、ページ番号225dを更新することである。
【0071】
S1006において、ライトプログラム515は、クラウド20のボリューム310へライト要求を発行し、クラウド20からの完了報告を待つ(S1006)。具体的には、ライトプログラム515は、制御情報部221内の、仮想ボリューム293とボリューム310のペア関係を管理するペアテーブル227へアクセスし、ボリューム310の情報と、ボリューム310が格納されるストレージVM300の情報とを取得する。ライトプログラム515は、取得したストレージVM300の情報と、ボリューム310の情報と、ライト要求に含まれていたライトアドレス、ライトデータをライト要求としてストレージVM300へ送信する。例えば、仮想ボリューム310内のアドレスは、ボリューム310内のアドレスに対応付けられている。
【0072】
次に、ライトプログラム515はクラウド20からのライト要求の完了報告を受領し(S1007)、S1001で“No”と判定された場合に仮想ボリュームテーブル225を更新する(S1008)。具体的には、S1003で“No”と判定された場合、ライトプログラム515は、書き込みアドレスに対応するレコードのページ割り当て状態225cを“済み”に更新し、さらに、ページ番号225dを“Cloud”に更新する。また、S1003で“Yes”と判定された場合、ライトプログラム515は、書き込みアドレスに対応するレコードのページ割り当て状態225cを“済み”に更新し、さらに、ページ番号225dをS1004で割り当てられたページのページ番号に更新する。
【0073】
最後に、ライトプログラム515は、ホスト100へライト完了を報告し、処理を終了する(S1009)。
【0074】
ストレージシステム200は、ページ292のアクセス頻度に応じて、ページをHot Data、Cold Dataへ分類する。このため、ライトプログラム515およびリードプログラム514はIO頻度を算出するための情報も更新する。これらは、ストレージ階層制御の技術として公知であるため、処理ステップ他は省略する。
【0075】
なお、S1005において、ライトプログラム515は、ライトデータをキャッシュに格納せずに、物理記憶デバイス240に格納してもよい。
【0076】
ライトプログラム515によれば、Hot Dataへライト要求が発行された場合、ステップS1005でオンプレのデータが更新され、ステップS1006でクラウド上のデータが更新される。すなわち、ライトデータは二重化される。一方、Cold Dataへライト要求が発行された場合、ステップS1006でクラウド上のデータのみが更新される。
【0077】
また、ライト要求により指定されたライト領域に対応する仮想記憶領域に、オンプレミス側の物理記憶デバイスから第一記憶領域が割り当てられている場合、ライトデータをオンプレミス10内の物理記憶デバイスへ書き込む。ライト対象領域に、クラウド側の記憶領域である第二記憶領域が割り当てられている場合、ライトデータをオンプレミス10内の物理記憶デバイスに書き込むことなく、クラウドへ転送する。第一記憶領域は例えば、容量プール290に関連付けられたページである。第二記憶領域は例えば、容量プール290に関連付けられていないページである。これにより、ストレージシステム200は、Hot Dataだけをオンプレミス10に格納することができる。
【0078】
また、ライト対象領域に第一記憶領域と第二記憶領域の何れも割り当てられていない場合、ストレージシステム200は、第一記憶領域を優先してライト対象領域に割り当てる。これにより、ストレージシステム200は、容量プール290内のページをライト対象領域に割り当てることが可能であれば、新規のデータをHot Dataとして扱うことができる。このように、図8の例では、ページが未割当の領域が更新されたとき、空ページがあれば当該ページをHot Data同様に処理した。ページが未割当領域へのライト要求の場合、当該ライト要求がライト対象領域に発行された最初のI/O要求と考えられるため、ページが未割当領域へのライト要求を、Cold Data同様に処理してもよい。具体的には、ステップS1003の結果が“Yes”の場合、ステップS1006へ進むことで実現される。
【0079】
図9は、実施例1に係るリードプログラムのフローチャートの一例である。
【0080】
リードプログラム514は、ホスト100から仮想ボリューム293へのリード要求を受領し、リードデータをホスト100へ返す。
【0081】
最初に、リードプログラム514はホスト100からリード要求を受領する(S2000)。リード要求は、リード対象ボリューム番号(本実施例の場合仮想ボリューム番号)、リードアドレス、リード長などの情報を含む。
【0082】
次に、リードプログラム514は仮想ボリュームテーブル225にアクセスし、リード対象アドレスに、ページ292が割り当てられているか否かを判定する(S2001)。ページ292の割り当てがない場合、リード対象アドレスは未割当領域であるため、リードプログラム514は、S2007でゼロデータをホスト100へ転送し、処理を終了する(S2007)。ここでリードプログラム514は、ゼロデータの代わりにエラーをホスト100へ返してもよい。
【0083】
一方で、ページ292が割り当てられている場合、リードプログラム514はリード対象データがキャッシュ上にあるか否かをキャッシュ管理テーブル226を参照して判定する(S2002)。リード対象データがキャッシュ上にある場合、リードプログラム514は、キャッシュからホスト100へデータを転送し、処理を終了する(S2007)。
【0084】
リード対象データがキャッシュ上にない場合、リードプログラム514はリード対象アドレスに対応するページ292がオンプレミス10のストレージシステム200か、クラウド20のストレージVM300のどちらに格納されているかを判定する(S2003)。ページ292がオンプレミス10にある場合、リードプログラム514は、プールボリューム291へアクセスし、リード対象データをキャッシュへ格納した後(S2006)、キャッシュからホスト100へデータを転送する(S2007)。ここでは、物理的にデータが格納されている位置が物理記憶デバイス240であるため、ステップS2006では、プールボリューム291に対応する物理記憶デバイス240からデータがキャッシュへ転送される。
【0085】
ページ292がクラウド20にある場合、リードプログラム514は、クラウド20のボリューム310へリード要求を発行し、クラウド20からの完了報告を待つ(S2004)。ここでリードプログラム514は、ライト要求同様に、ペアテーブル227から、リード要求発行先となるストレージVM300の情報とボリューム310の情報とを取得する。
【0086】
次に、リードプログラム514は、クラウド20からリード対象データを受領し(S2005)、最後にホスト100へ、受領したリードデータを転送する(S2007)。ストレージシステム200がクラウド20からリード対象データを受領してから、ホスト100へ転送するまでの間、リード対象データはFEパッケージ260のメモリ262や、キャッシュ等に一時的に格納される。
【0087】
リードプログラム514によれば、ストレージシステム200は、リード要求により指定された仮想記憶領域であるリード対象領域に、キャッシュが関連付けられていると判定した場合、キャッシュからリードデータを読み出す。これにより、ストレージシステム200は、ホスト100に対して高速に応答することができる。ストレージシステム200は、リード対象領域にキャッシュが関連付けられていないと判定し、かつ、リード対象領域に容量プール290が関連付けられたページが割り当てられていると判定した場合、容量プール290からリードデータを読み出す。ストレージシステム200は、リード対象領域にキャッシュが関連付けられていないと判定し、かつ、リード対象領域に容量プール290が関連付けられていないページが割り当てられていると判定した場合、クラウド20からリードデータを読み出す。これにより、ストレージシステム200は、キャッシュ上にないHot Dataをオンプレミス10から読み出し、キャッシュ上にないCold Dataをクラウド20から読み出すことができる。
【0088】
上述のように、本願発明によれば全データをクラウド側に保持しつつ、アクセス頻度の高いデータについてはオンプレ側にも保持することが可能となる。
【0089】
従来のリモートコピーにより単にデータ2重化するのでは2倍の記憶領域を消費する。
また、オンプレ側の使用容量低減のために、オンプレ側で仮想ボリュームを提示して、全てのデータをクラウド側に格納する場合、ホスト計算機から発行される全てのI/O処理のためにクラウドのアクセスが発生し性能低下が起きうる。又、オンプレ側ストレージ装置とクラウド側のストレージとの間でデータのアクセス頻度に応じた階層制御を更に組み合わせることも考えられるが、アクセス頻度の高いデータがクラウド側に格納されず、クラウド側での業務ができない上に、オンプレ側の障害時の復旧ができない。更に、クラウド上のストレージに格納されるデータをオンプレのストレージシステムのキャッシュ領域にキャッシュするI/O性能改善方法が考えられる。しかし、オンプレミスのホスト計算機障害で業務をクラウド側で再開する前に、キャッシュデータをクラウドへ書き出す必要が生じ、迅速な業務再開ができない。さらに、オンプレミスのストレージシステムに障害が発生した場合には、一部のデータが失われる可能性がある。
【0090】
一方、本実施例によれば、Hot Dataはオンプレのストレージシステムのアクセスのみで実現でき、高いI/O性能を実現できる。さらに、ライト要求に同期してライトデータをクラウドに書き込むことから、オンプレミスに障害が発生しても、クラウド20内のデータを用いて業務を迅速に再開することができる。
【0091】
ここで、実施例1の変形例について説明する。
【0092】
上述したライトプログラム515およびリードプログラム514の処理では、Cold Dataがライトまたはリードされたときに、ストレージシステム200のキャッシュにデータはキャッシュされない。例えば、ライトプログラム515は、S1002においてクラウド20にデータがある場合、データをキャッシュに格納するS1005をスキップし、S1006に進み、クラウド20へのライト要求を発行する。リードプログラム514は、S2005でクラウド20からデータを受領し、ホスト100へ転送している。すなわち、ストレージシステム200のキャッシュにクラウドからリードしたデータをキャッシュデータとして残していない。
【0093】
変形例として、Cold Dataがライトまたはリードされたときに、ストレージシステム200は、キャッシュに仮想ボリューム293のデータとしてキャッシュすることもできる。この動作を以下に説明する。
【0094】
ライトプログラム515は、S1002で“No”と判定された場合またはS1003で“No”と判定された場合、S1006へ進むのではなくS1005へ進み仮想ボリューム293のキャッシュデータとしてキャッシュ上にライトデータを格納する。これにより、リードプログラム514のS2002でキャッシュヒットする(キャッシュ上にデータがある)ことが期待される。
【0095】
リードプログラム514は、S2005の直後に、S2005で受領したデータを、仮想ボリューム293のデータとしてキャッシュ上に格納する処理を実行する。これにより、以降に発行されるリード要求において、リードプログラム514のS2002でキャッシュヒットする(キャッシュ上にデータがある)ことが期待される。
【0096】
仮想ボリューム293のデータとしてキャッシュするとは、仮想ボリューム293のアドレス(ライト、リードでアクセスされたアドレス)とデータが格納されているキャッシュのアドレスを対応付けたキャッシュ管理テーブル226で管理することで実現される。
【0097】
変形例において、Cold Dataをストレージシステム200のキャッシュ部にキャッシュする場合、デステージ処理の変更が必要となる。デステージ処理とは、ライトデータによってキャッシュに書き込まれたデータを物理記憶デバイス240に書き込む処理である。Cold Dataはプールボリューム291に対応付けられていないため、書き込み先となる物理記憶デバイス240が存在しない。これは従来の仮想ボリュームには存在しない状態である。上記状態に対応するデステージプログラム516について説明する。
【0098】
図10は、実施例1に係るデステージプログラム516のフローチャートの一例である。
【0099】
本プログラムは他のプログラムからコールされる。例えば、デステージプログラム516は、キャッシュのダーティ量を監視しているプログラムからコールされ得るし、IO時に割り当てるキャッシュが不足している場合にはIOを処理するプログラムからもコールされ得る。
【0100】
最初に、デステージプログラム516は、キャッシュデータの中からダーティキャッシュを探す(S300)。
【0101】
次に、デステージプログラム516は、キャッシュされている領域に対応するページ292を特定する(S301)。具体的には、デステージプログラム516は、キャッシュデータに対応する仮想ボリューム293のアドレスを得る。これは、キャッシュ管理テーブル226によって取得されることができる。次に、デステージプログラム516は、仮想ボリュームテーブル225を参照し、得られた仮想ボリューム293のアドレスに対応するページ番号を特定する。
【0102】
そして、デステージプログラム516は、特定されたページがプールボリューム291に対応するか否かを判定する(S302)。プールボリューム291に対応する場合、キャッシュデータに対応する物理記憶デバイス240はストレージシステム200内にあるため、デステージプログラム516は、デステージを実行する(S303)。すなわち、デステージプログラム516は、物理記憶デバイス240にキャッシュデータを書き込む。最後に、デステージプログラム516は、キャッシュを解放して処理を終了する(S304)。
【0103】
一方で、プールボリューム291に対応しない場合、キャッシュデータに対応する物理記憶デバイス240はストレージシステム200内にないため、デステージプログラム516は、キャッシュを解放し、処理を終了する(S304)。すなわち、対象となるCold Dataはクラウド20のボリューム310に格納されているため、デステージプログラム516は、単純にキャッシュを解放してもよい。
【0104】
また、ライトプログラム515は、S1002で“No”と判定される場合またはS1003で“No”と判定される場合に、S1005でデータをクリーンキャッシュとしてキャッシュしてもよい。クリーンキャッシュは物理記憶デバイス240の同一のデータであり、物理記憶デバイス240に書き込まれることなく解放される。対象となるCold Dataはクラウド20のボリューム310に格納されているため、デステージプログラム516は、単純にキャッシュを解放してもよい。よって、ライトプログラム515がクラウド20へのライトデータをクリーンキャッシュとして扱うことで、既存のデステージプログラム516からの変更は不要となる。さらに、一般的にダーティキャッシュは二重化されるがクリーンキャッシュは二重化する必要がない。よって、キャッシュ消費量を減らすことができる。
【0105】
なお、S301、S302のために、ストレージシステム200は、キャッシュ管理テーブル226により、キャッシュに対応するHDDが存在するかどうかを管理してもよい。
【0106】
デステージプログラム516によれば、ストレージシステム200は、キャッシュ上のデータのうち、容量プール290に関連付けられていないデータを破棄する。これにより、ストレージシステム200は、Cold Dataを物理記憶デバイス240へ書き出すことなく、キャッシュを解放することができる。
【0107】
本実施例の計算機システムは、IO頻度情報を用いて、データをHot DataとCold Dataへ分類し、オンプレミス10のストレージシステム200にHot Dataのみを格納、クラウド20のストレージVM300にHot DataとCold Dataを格納する。IO頻度に変化が生じた場合、Hot DataからCold Dataへの変化、Cold DataからHot Dataの変化が発生する。この変化に基づいて、データの格納場所を変更する必要がある。
【0108】
図11は、実施例1に係るティアリングプログラムのフローチャートの一例である。
【0109】
ティアリングプログラム511は、IO頻度情報の変化に基づき、最適なデータの格納レイアウトを算出し、実際にデータの配置を変更するデモーションプログラム513、および、プロモーションプログラム512を起動する。なお、Hot DataからCold Dataへの変化に伴い、データ格納場所を変更することをデモーションと呼ぶ。更に、Cold DataからHot Dataへの変更に伴い、データ格納場所を変更することをプロモーションと呼ぶ。ティアリングプログラム511は、ストレージシステム200内で定期的に実行される。例えば、データ配置の見直し頻度が1時間に1回であれば、ティアリングプログラム511は、1時間に1回起動される。データ配置の見直し頻度は、保守端末270や管理サーバなどを介してユーザやストレージ管理者から設定され得る。
【0110】
最初に、ティアリングプログラム511は、仮想ボリュームの各領域のIO頻度情報を仮想ボリュームテーブル225から取得し(S3000)、IO頻度情報を用いてデータの最適な配置を算出する(S3001)。次に、ティアリングプログラム511は、最適な配置と現状の配置を比較し、プロモーションすべきデータおよび、デモーションすべきデータを決定する(S3002、S3003)。
【0111】
配置決定の一例として、ティアリングプログラム511は、仮想ボリュームの各領域をIO頻度の高いものから順に並べる。次に、ティアリングプログラム511は、オンプレミス10の容量プール290の容量から、Hot DataとCold Dataを判定するIO頻度閾値を導き、どの領域のデータをHot Dataとしてオンプレミス10の容量プールに格納すべきかを決定する。
【0112】
そして、ティアリングプログラム511は、既に容量プール290に格納済みのデータを除いて、プロモーション対象となるデータを特定する。同様に、ティアリングプログラム511は、既に容量プール290に格納されているデータのうち、容量プール290に入れられないものをデモーション対象として特定する。
【0113】
以下に、ティアリングプログラム511のS3004以降を説明する。ティアリングプログラム511は、デモーション対象を指定して、デモーションプログラム513をコールする(S3004)。最後に、ティアリングプログラム511は、プロモーション対象を指定して、プロモーションプログラム512をコールし、処理を終了する(S3005)。ストレージシステム200の物理記憶デバイスの容量は、ストレージVM300の物理記憶デバイスの容量より小さいことが多い。容量プール290に空きページを作成するために、ティアリングプログラム511は、基本的にデモーションプログラム513を先に実行する。複数データをプロモーション、デモーションする場合は、デモーション、プロモーションを交互に実行することでHot Data格納用領域を有効利用できる。
【0114】
ティアリングプログラム511によれば、ストレージシステム200は、各仮想記憶領域のアクセス頻度に基づいて、各仮想記憶領域を第一グループと第二グループの何れか一つに分類し、第一グループに分類された仮想記憶領域に対し、容量プール290に関連付けられたページを割り当て、第二グループに分類された仮想記憶領域に対し、容量プール290に関連付けられていないページを割り当てる。第一グループは例えば、Hot Dataに対応する仮想記憶領域である。第二グループは例えば、Cold Dataに対応する仮想記憶領域である。これにより、オンプレミス10の性能の低下を防ぐと共に、オンプレミス10の物理記憶デバイス240の容量を節約することができる。
【0115】
図12は、実施例1に係るデモーションプログラムのフローチャートの一例である。
【0116】
デモーションプログラム513は、ティアリングプログラム511からコールされ、ストレージシステム200で実行される。
【0117】
最初に、デモーションプログラム513は、デモーション指示を受領する(S4000)。このとき、デモーションプログラム513は、デモーション対象である一つ以上の仮想ボリューム293内の領域(仮想ボリューム番号と仮想ボリューム内のアドレスによって特定される領域)を、パラメタとして受領する。
【0118】
本実施例では、デモーションプログラム513が複数の領域情報を受領し、複数の領域に対して処理を行うものとした。しかし、デモーションプログラム513は一つの領域のデモーションを実施する機能とし、ティアリングプログラム511が複数回デモーションプログラム513をコールするようにしてもよい。
【0119】
次に、デモーションプログラム513は、デモーション対象の中から未処理の領域を一つ選択し(S4001)、当該領域を使用している仮想ボリューム293の仮想ボリュームテーブル225を更新する(S4002)。具体的には、デモーションプログラム513は、ページ番号を“Cloud”へ変更する。変更後、デモーションプログラム513はHot Dataを格納していた容量プール290の領域を解放する(S4003)。
【0120】
次に、デモーションプログラム513は、指示された全ての領域を処理したか否かをチェックする(S4004)。指示された全ての領域を処理している場合、デモーションプログラム513は、処理を終了する(S4005)。
【0121】
一方、未処理の領域が残っている場合、デモーションプログラム513はS4001へ戻り、次の未処理の領域に対して、S4002からS4003までを実行する。
【0122】
デモーションプログラム513によれば、ストレージシステム200は、仮想記憶領域のデモーションを実行する場合、デモーション対象領域に割り当てられている、容量プール290に関連付けられたページを、容量プール290に関連付けられていないページに変更する。これにより、ストレージシステム200は、容量プール290からのデータの読み出しと、クラウド20へのデータを書き込みとを実行することなく、デモーションを実行することができる。
【0123】
図13は、実施例1に係るプロモーションプログラムのフローチャートの一例である。
【0124】
プロモーションプログラム512は、ティアリングプログラム511からコールされ、ストレージシステム200で実行される。
【0125】
最初に、プロモーションプログラム512は、プロモーション指示を受領する(S5000)。このとき、プロモーションプログラム512は、プロモーション対象である一つ以上の仮想ボリューム内の領域(仮想ボリューム番号と、仮想ボリューム内のアドレスによって特定される領域)を、パラメタとして受領する。
【0126】
次に、プロモーションプログラム512は、プロモーション対象の中から未処理の領域を一つ選択し(S5001)、当該領域を格納するための容量プール290の領域を確保する(S5002)。具体的には、プロモーションプログラム512は、プールテーブル224の状態224d、割当先224eを更新する。また、プロモーションプログラム512は、仮想ボリュームテーブル225のページ番号225dを更新する。この処理によって、デステージプログラム516のS302の結果が変わる。
【0127】
続けて、プロモーションプログラム512は、選択した領域のデータがキャッシュされているか否かをチェックする(S5003)。この処理は、キャッシュ管理テーブル226を参照することで実現される。
【0128】
データがキャッシュされている場合、プロモーションプログラム512は、S5004、S5005をスキップしてS5006へ進む。
【0129】
一方、データがキャッシュされていない場合、プロモーションプログラム512はストレージVM300にリード要求を発行し、ストレージVM300からの応答を待つ(S5004)。そして、プロモーションプログラム512は、ストレージVM300からプロモーション対象のデータを受領し、ダーティとしてキャッシュに格納する(S5005)。
【0130】
この時点で、プロモーション対象のデータがキャッシュ上に格納された状態となる。さらに、仮想ボリュームテーブル225のページ番号225dには、プールボリューム291のページ番号が格納されている。このデータは、デステージプログラム516によってストレージシステム200が搭載する物理記憶デバイス240へ書き込まれることになる。
【0131】
なお、ストレージシステム200がCold Dataをリードまたはライトしたときにキャッシュしない場合、S5003は不要となる。このとき、S5004、S5005は必要である。
【0132】
また、ストレージシステム200がCold Dataをリードまたはライトしたときにクリーンとしてキャッシュする場合、デステージプログラム516によって物理記憶デバイス240に書き込まれない。これを回避するための方法が二つある。一つ目は、ステップS5003で“Yes”となった場合、キャッシュの属性をクリーンからダーティに変更する。二つ目は、ステップS5003で“Yes”となった場合、クリーンのキャッシュを一旦は解放し、ステップS5004、S5005を実行する。
【0133】
次に、プロモーションプログラム512は、指示された全ての領域を処理したか否かをチェックする(S5006)。指示された全ての領域を処理している場合、プロモーションプログラム512は、処理を終了する(S5007)。
【0134】
一方、未処理の領域が残っている場合、プロモーションプログラム512はS5001へ戻り、次の未処理の領域に対して、S5002からS5005までを実行する。
【0135】
本実施例のストレージシステム200は、ページ割当て状態225cおよびページ番号225dを用いてリード要求、ライト要求の処理を分岐させた。具体的には、ストレージシステム200は、“ページ割り当てなし”が未割当状態である(状態A)と判定し処理する。また、ストレージシステム200は、“ページ割り当てあり+ページ番号有効(数値)”が、ページ割り当て済みであり且つデータがオンプレミス10およびクラウド20に格納されている(状態B)、と判定し処理する。また、ストレージシステム200は、“ページ割り当てあり+ページ番号無効(“Cloud”)“が、ページ割り当て済みであり且つデータがクラウド20のみに格納されている(状態C)、と判定し処理する。
【0136】
ページ割り当て状態のみでも本実施例と同様の動作を実現することができる。
【0137】
まず、ストレージシステム200は、“ページ割り当てあり”が、オンプレミス10のページが割り当て済みであり且つデータがオンプレミス10およびクラウド20に格納されている、と判定し処理する。すなわち、この処理は、上述の状態Bと同様の処理となる。
【0138】
次に、“ページ割り当てなし”の時に、上述の状態A、Cと同等の結果を返す方法を説明する。
【0139】
まず、リードプログラムは、クラウド20にリード要求を発行する。対象の領域がホスト100からライトが書き込まれていない領域であれば、クラウド20からストレージシステム200へゼロデータが返される。すなわち、未割当であった場合と同様の結果となる。次に、ホスト100から当該領域へライトが書き込まれていた場合は、クラウド20に格納されているリード対象データがストレージシステム200へ返される。すなわち、正しいリード対象データが返される。
【0140】
次に、ライトプログラムは、クラウド20にライト要求を発行し、クラウド20にライトデータを格納する。これにより問題なくIO処理を実現することができる。また、ライトプログラムは、オンプレミス10に空きページがあれば対象の領域へ割り当ててもよい。その場合、ライトプログラムは、割り当てられページとクラウド20との両方にライトを書き込む。
【0141】
これにより、対象の領域に対してオンプレミス10及びクラウド20の物理記憶領域が未割当だった場合に、クラウド20と通信してしまうが、IOとしては正しい結果を返すことができる。
【0142】
以上のリードプログラム514、ライトプログラム515では、オンプレミス10の仮想ボリューム293がIO要求を受領する方式を説明した。
【0143】
異なるストレージに配備される二つのボリュームのデータをボリューム間で二重化し、さらに当該二つのボリュームに対してストレージ間でユニークな仮想的なIDを割り当て、ホスト100に対して、あたかも一つのボリュームのように見せるHA(High Availability)機能が知られている。この機能を用いることにより、ホスト100は、どちらのストレージに対してもIO要求を発行することができる。
【0144】
本実施例のストレージシステム200とストレージVM300は、この機能と同様にして仮想ボリューム293とボリューム310を一つのボリュームとしてホストへ提供してもよい。ホスト100は、オンプレミス10のストレージシステム200、クラウド20のストレージVM300の両方に発行することができる。たとえば、ホスト100が仮想マシンであり、クラウド20へホストVM400としてマイグレーションされた時に、ストレージVM300のボリューム310に対してIOを継続することができる。さらに、ストレージVM300とストレージシステム200が近距離に配置されている場合、ホスト100は両方のボリュームへIO要求を発行してもよい。この場合、ホスト100からストレージVM300へのパスが設定されているものとする。ホスト100は、複数パスを使うことで、パス性能向上、パス障害に対する信頼性の向上が期待できる。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
【実施例2】
【0145】
一般に、クラウド20のアクセスレイテンシは悪い(レイテンシが大きい)。高頻度でアクセスされるHot Dataのアクセスにおいて、IOに同期したクラウド20のアクセスを回避したい。IOに同期したクラウド20のアクセスを回避するため、クラウド20へのライト要求発行を非同期に実施する。非同期にライトを転送するための技術として非同期リモートコピーがある。
【0146】
図14は、実施例2に係る計算機システムの構成を示す。
【0147】
本実施例の計算機システムは、仮想ボリューム293、ボリューム310に代えて、PVOL(Primary Volume)700、SVOL(Secondary Volume)703、JVOL(Journal Volume)701、JVOL702を作成する。PVOL700はオンプレミス10内のストレージシステム200の仮想ボリュームであり、ホスト100が使用するデータが格納される。SVOL703は、クラウド20内のストレージVM300のボリュームであり、PVOL700に書き込まれたデータのコピーを格納する。
【0148】
JVOL701は、オンプレミス10内のストレージシステム200のボリュームであり、SVOL703へ転送するデータを一時的に格納する。JVOL702は、ストレージVM300のボリュームであり、オンプレミス10内のストレージシステム200から転送されたデータを一時的に格納する。なお、JVOL701、702も仮想ボリュームあってもよい。本実施例では、JVOLはボリュームとしたが、一時的にデータを格納することができる領域であれば何でもよい。例えば、キャッシュを使用する方法などが考えられる。
【0149】
上記のJVOL701からJVOL702へ転送されるデータのことをジャーナル(Journal)と呼ぶ。ジャーナルはライトデータ(Journal Data)とライトデータに対するメタデータ(JNCB:Journal Control Block)から構成される。JNCBには、ライトアドレスや、コピー先のボリューム番号、コピー先ストレージの識別番号、ホストから書き込まれた順序を示す情報(SEQ ID)などが含まれる。
【0150】
以下に、ホスト100から非同期リモートコピーのPVOL700にライトが発行されたときのフローを説明する。本発明へ非同期リモートコピーが適用された場合の処理は、図16以降に説明する。
【0151】
ストレージシステム200は、ホスト100からライト要求704を受領すると、ライトデータをPVOL700に書き込む。続けて、ストレージシステム200は、ライト要求に対してジャーナル705(SEQ IDを含む)を作成しJVOL701へ格納し、ホスト100へライト完了を報告する。ストレージシステム200及びストレージVM300は、ライト完了の報告とは非同期のタイミングでJVOL701のデータをJVOL702へ転送する。最後に、ストレージVM300は、JVOL702のジャーナルからライトデータを取り出し、SEQ IDの順でSVOL703に書き込む。この処理を、JNLのリストアと呼ぶ。
【0152】
なお、JVOL701は複数のボリュームにより構成されていてもよく、また、複数のPVOL700に対するジャーナルを格納するようにしてもよい。JVOL702も同様である。
【0153】
図15は、ストレージシステム200からストレージVM300へのデータ転送に非同期リモートコピーを適用した場合に発生する課題の一例である。
【0154】
まず、ストレージシステム200が、ホスト100からライト要求800を受領し、当該ライト要求に対してジャーナル801を作成した状態であるとする。図中の“New”は、新たに書き込まれたデータを意味する。“Old”は、“New”が書き込まれたアドレスに、“New”ライト前に格納されていた値を意味する。
【0155】
ライトデータ“New”を含むジャーナル801がJVOL701またはJVOL702に格納されている間に、ホスト100からライト要求と同じアドレスに対するリード要求802が発行される可能性がある。
【0156】
対象アドレスのデータがCold Dataである場合、実施例1のリードプログラム514によれば、クラウド20のSVOL703からデータを読み出し、ホストへ転送する。しかし、クラウド20には未だ“Old”が格納されているため、ストレージシステム200は、この古いデータをホスト100へ転送してしまうる。
【0157】
以降、上記課題を解決するためのテーブル構造および処理フローを説明する。
【0158】
上記問題を解決するために、本実施例のストレージシステム200は、ジャーナルのSVOL703へのリストアが完了するまで、ストレージシステム200のキャッシュ上にライトデータを常駐させる。これにより、リード要求802に応じてストレージシステム200は、キャッシュに格納されている“New”にアクセスするため、“Old”をリードする問題は解決される。
【0159】
本実施例のキャッシュ管理テーブル226は、常駐Bit226e、最大SEQ ID226fを含む。
【0160】
常駐Bit226eは、キャッシュデータをキャッシュ部に常駐させる必要があるか否かを管理する。“ON”は常駐が必要であることを意味する。“OFF”は常駐が不要であることを意味する。リストアが完了するまで常駐BitをONすることによって、旧データがリードされる問題を回避する。
【0161】
最大SEQ ID226fは、当該キャッシュに格納されているライトデータに対して割り当てられたSEQ IDのうち最大のSEQ IDを管理する。ストレージシステム200は、この最大SEQ IDとSVOL703へのリストアが完了したジャーナルのSEQ IDを比較することで、キャッシュ解放の要否を判定する。
【0162】
ここで、最大SEQ IDを用いる理由について説明する。同一のアドレスに対して、複数のライト要求が発行された場合、キャッシュデータは上書きされる。この時、最初のライト要求に対するジャーナルがSVOLに書き込まれた時点でストレージシステム200がキャッシュを解放してしまうと、後続のライト要求でキャッシュされたデータも同時に解放されることになる。これを回避するために、ストレージシステム200は、最大SEQ IDを管理する。
【0163】
ストレージシステム200のプログラム部222は、実施例1のプログラムに加えて、ジャーナル転送プログラム521、キャッシュパージプログラム522を格納する。
【0164】
クラウド20は、リードジャーナルプログラム、リストアプログラムを格納する。ストレージVM300は、これらのプログラムを実行する。
【0165】
図16は、実施例2に係るライトプログラムのフローチャートの一例である。
【0166】
本実施例のライトプログラムをライトプログラム515bと記す。本実施例のライトプログラム515bにおけるS1000からS1004は、実施例1のライトプログラム515と同じである。S1002の結果が“No”となる場合、または、S1003の結果が“No”となる場合、ライトプログラム515bはキャッシュにライトデータを格納する(S6005)。この時、ライトプログラム515bは、キャッシュ管理テーブル226の常駐Bit226eを“ON”する。
【0167】
このケースは、クラウド20のストレージVM300にのみデータを格納する分岐であるため、ライトデータをキャッシュ上に常駐させる必要がある。これを実現するため、ライトプログラム515bは、キャッシュ管理テーブル226の常駐Bit226eを“ON”する。
【0168】
ここで、ライトプログラム515bは、キャッシュ管理テーブル226の最大SEQ ID226fに、SEQ IDが取り得る値の上限である上限値を格納する。なぜならば、SEQ IDの割り当てステップは後のS6008であり、ライト要求に対しては未だSEQ IDが取得されていないからである。SEQ IDが確定するまでの間、キャッシュの解放が回避できれば何でもよい。ライトプログラム515bは、上限値の代わりに無効値を格納し、無効値の場合はキャッシュを解放しないとしてもよい。
【0169】
また、キャッシュにライトデータを格納するS6005またはS6006以前にSEQ IDを取得するようにしてもよい。その場合は、取得済みのSEQ IDを最大SEQ ID226fの値と比較し、取得したSEQ IDが大きければ、取得したSEQ IDをキャッシュ管理テーブル226の最大SEQ ID226fへ格納する。
【0170】
S1002が“Yes”となる場合、または、S1003が“Yes”となる場合、ライトプログラム515bはキャッシュにライトデータを格納する(S6006)。このとき、キャッシュ管理テーブル226の常駐Bit226eは“OFF”である。なぜならば、容量プール290の領域が割り当てられており、キャッシュが解放されたとしても、リード要求に対して容量プール290から最新のデータを転送することができるからである。この時、ライトプログラム515bは、最大SEQ ID226fに何も格納しない。図示したキャッシュ管理テーブル226の例は、この時の最大SEQ ID226fを“−”で示している。
【0171】
S6005とS6006の後、ライトプログラム515bは、仮想ボリュームテーブル225を更新する(S6007)。この処理は、実施例1のS1008と同じである。
【0172】
次に、ライトプログラム515bは、SEQ ID管理テーブルからSEQ IDを取得し(S6008)、当該SEQ IDを含むジャーナルを作成し、JVOL701へ格納する(S6009)。
【0173】
ライトプログラム515bは、ジャーナルを格納した後、取得したSEQ IDを、キャッシュ管理テーブル226の最大SEQ ID226fに格納する(S6010)。
【0174】
最後に、ライトプログラム515bはホスト100へライト完了を報告し、処理を終了する(S6011)。
【0175】
SEQ IDはホスト100からストレージシステム200に書き込まれたライトデータの順序を示すための情報である。SEQ ID管理テーブルは、番号を管理しており、取得要求に対して管理している番号を割り当て、番号をインクリメントする。すなわち、次の取得要求に対しては+1の番号が割り当てられる。SEQ ID管理テーブルは制御情報部221に記録される。
【0176】
順序保証が必要な少なくとも一つのPVOLを含むPVOLグループに対し、一連のSEQ IDが管理される。このグループのことを一般にコンシステンシグループと呼ぶ。
【0177】
さて、常駐BitがONでストレージシステム200にキャッシュされたデータを削除するためには、SVOL703へのリストアが完了したジャーナルのSEQ IDが必要である。このSEQ IDをリストア済みSEQ IDと呼ぶ。リストア済みSEQ IDは、SVOL703を有するクラウド20のストレージVM300にて生成される。このため、リストア済みSEQ IDをオンプレミス10のストレージシステム200へ通知する必要がある。リストア済みSEQ IDは制御情報部221に記録される。ストレージシステム200およびストレージVM300の両方の制御情報部221に記録される。ストレージVM300では、後述する処理によって生成されるリストア済みSEQ IDが記録される。そして、ストレージシステム200では、ストレージVM300から転送されたリストア済みSEQ IDが記録される。
【0178】
非同期リモートコピーの処理の説明にあわせて、リストア済みSEQ IDの転送について説明する。
【0179】
図17は、実施例2に係るリードジャーナルプログラムのフローチャートの一例である。
【0180】
リードジャーナルプログラムは、非同期リモートコピーのコピー先であるストレージVM300で実行されるプログラムである。リードジャーナルプログラムは、リードジャーナルコマンドをコピー元であるストレージシステム200に対して発行し、JVOL701に格納されているジャーナルを、JVOL702へ転送するためのプログラムである。リードジャーナルプログラムは、多重動作してもよい。
【0181】
最初に、リードジャーナルプログラムは、コピー先のストレージVM300に格納されているリストア済みSEQ IDを取得する(S7000)。リストア済みSEQ IDは、後述するリストアプログラムによって、リストア処理の進捗に合わせて更新される。
【0182】
次に、リードジャーナルプログラムは、コピー元のストレージシステム200へリードジャーナルコマンドを発行し(S7001)、コピー元のストレージシステム200からの応答を待つ(S7002)。このコマンドにはS7000で取得したリストア済みSEQ IDが含まれている。
【0183】
リードジャーナルプログラムは、コピー元のストレージシステム200からジャーナルを受領する(S7003)。ストレージシステム200は、一つのリードジャーナルコマンドに対し、複数のジャーナルを転送することができる。
【0184】
最後に、リードジャーナルプログラムは、ジャーナルに含まれるSEQ IDをチェックし、到着済みSEQ IDビットマップを更新する(S7004)。到着済みSEQ IDビットマップは、どのSEQ IDがコピー先のストレージVM300へ到着しているかを示す制御情報であり、リストアプログラムがリストアできるジャーナルを決定するために使用される。到着済みSEQ IDは制御情報部221に記録される。
【0185】
リードジャーナルプログラムはS7004の後、S7000に戻りリードジャーナルコマンドを発行し、他のジャーナルの転送を実行する。なお、コピー元のストレージシステム200からジャーナルが無いことを報告された場合、S7004の後に一定時間スリープする処理を追加してもよい。さらに、同時に実行されるリードジャーナルプログラムの多重度を下げてもよい。
【0186】
図18は、実施例2に係るジャーナル転送プログラム521のフローチャートの一例である。
【0187】
ジャーナル転送プログラム521は、非同期リモートコピーのコピー元であるストレージシステム200で実行されるプログラムである。ジャーナル転送プログラム521は、コピー先であるストレージVM300からリードジャーナルコマンドを受領し、JVOL701から転送するジャーナルをコピー先であるストレージVM300へ送信するプログラムである。
【0188】
最初に、ジャーナル転送プログラム521はリードジャーナルコマンドを受領すると(S800)、転送するジャーナルを決定する(S8001)。
【0189】
次に、ジャーナル転送プログラム521は、決定したジャーナルをJVOL701から読み出し、コピー先のストレージへ送信する(S8002)。
【0190】
最後に、ジャーナル転送プログラム521は、リードジャーナルプログラムによって通知されたリストア済みSEQ IDをコピー元のストレージシステム200に記録する(S8003)。このコピー元のストレージシステム200に記録されたリストア済みSEQ IDは、後述するキャッシュパージプログラムによって使用される。リストア済みSEQ IDは制御情報部221に記録される。
【0191】
なお、本実施例では、コピー先のストレージVM300がコピー元のストレージシステム200に対してリード要求を発行することによって、非同期リモートコピーを行う方式を説明した。当然、ストレージシステム200がストレージVM300にライト要求を発行することによって、非同期リモートコピーを行うこともできる。この場合、ストレージVM300は、リストア済みSEQ IDを、ライト要求の戻り値としてストレージシステム200に通知することができる。また、ストレージVM300が定期的にリストア済みSEQ IDをストレージシステム200に通知するなどの方式でも実現され得る。
【0192】
図19は、実施例2に係るリストアプログラムのフローチャートの一例である。
【0193】
リストアプログラムは、非同期リモートコピーのコピー先であるストレージVM300で実行されるプログラムである。リストアプログラムは、JVOL702からSVOLへジャーナルをリストアするプログラムである。
【0194】
最初に、リストアプログラムは、到着済みSEQ IDビットマップをチェックし、SEQ IDが隙間なく連続している範囲を特定する(S9000)。すなわち、当該範囲のジャーナルは全てストレージVM300に到着している。
【0195】
次に、リストアプログラムは、決定した範囲のジャーナルをSEQ IDの順にSVOLへリストアする(S9001)。具体的には、リストアプログラムは、ジャーナルに含まれるデータをSVOLへ書き込む。書き込み先となるSVOLやSVOL内のアドレス情報はジャーナルに含まれるJNCBに格納されており、JNCBを参照しながら処理する。
【0196】
最後に、リストア済みSEQ IDを更新する(S9002)。これは、最後にリストアしたジャーナルのSEQ IDを、ストレージVM300の制御情報部にあるリストア済みSEQ IDに書き込むことを意味する。
【0197】
S9002の実行後、リストアプログラムはS9000へ戻り、次のジャーナルのリストアを行う。
【0198】
図20は、実施例2に係るキャッシュパージプログラムのフローチャートの一例である。
【0199】
キャッシュパージプログラム522は、非同期リモートコピーのコピー元であるストレージシステム200で実行されるプログラムである。キャッシュパージプログラム522は、常駐Bit226eがONのキャッシュが破棄可能となったか否かを判定し、当該キャッシュが破棄可能である場合には破棄するプログラムである。
【0200】
最初に、キャッシュパージプログラム522は、クラウド20へリモートコピーしているPVOL700を特定する(S10000)。次に、キャッシュパージプログラム522は、特定したPVOL700のキャッシュの中から、常駐Bit226eがONであるダーティキャッシュを探す(S10001)。キャッシュパージプログラム522は、見つけられたキャッシュに対して、キャッシュ管理テーブル226を参照し、最大SEQ IDを取得し(S10002)、最大SEQ IDをリストア済みSEQ IDと比較する(S10003)。
【0201】
最大SEQ IDがリストア済みSEQ ID以下の場合、キャッシュパージプログラム522は、キャッシュを解放し(S10004)、キャッシュ管理テーブル226を更新する(S10005)。ここでキャッシュパージプログラム522は、キャッシュ管理テーブル226から当該キャッシュを管理するレコードを削除し、キャッシュアドレスをフリー状態にする。
【0202】
一方で、最大SEQ IDがリストア済みSEQ IDより大きい場合、キャッシュパージプログラム522は、当該キャッシュを解放することはできないため、S10004およびS10005をスキップする。
【0203】
S10005の後、またはS10003で“No”となった場合、キャッシュパージプログラム522はS10000へ戻り他のキャッシュデータに対してS10001からの処理を実行する。
【0204】
図20の例では、キャッシュパージプログラム522を定期的に実行することでキャッシュを解放する。しかし、デステージプログラムから常駐BitがONのダーティキャッシュを発見したときに、キャッシュパージプログラムをコールし、ステップS10002からS10005を実行するようにしてもよい。
【0205】
本実施例によれば、ストレージシステム200及びストレージVM300は、非同期リモートコピーを実行することにより、PVOL700へ書き込まれる全てのデータをSVOL703へ格納することができる。ストレージシステム200は、ストレージVM300によりSVOL703へ反映されたジャーナルの順序を示す完了情報を、ストレージVM300から受信し、完了情報に基づいて、キャッシュ上のデータのうち、SVOL703に反映されていないデータを維持する。これにより、ストレージシステム200は、クラウド20から更新前のデータを読み出すことを防ぐことができる。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
【実施例3】
【0206】
外部ストレージ接続機能は、外部ストレージ内のボリュームを上位ストレージへマッピングし、上位ストレージの仮想ボリュームとして使用する機能である。上位ストレージへマッピングされたボリュームは、上位ストレージによりホストへ提供され得る。上位ストレージでは、物理記憶デバイスの容量は消費されない。上位ストレージがホストからのIO要求を受けると、上位ストレージが外部ストレージへ対してIO要求を発行することでIO要求を実現する。一般に、上位ストレージのキャッシュを活用することは可能である。本実施例のストレージシステム200は、上位ストレージとして外部ストレージ接続機能を用いる。
【0207】
図21は、実施例3に係る計算機システムの構成を示す。
【0208】
本実施例のストレージシステム200は、クラウド20内のストレージVM300のボリューム703を、オンプレミス10内のストレージシステム200の外部VOL900としてマッピングし、いわゆる外部ストレージ接続機能(デバイス仮想化機能とも呼ばれる)を用いている。
【0209】
本実施例のストレージシステム200によるリード要求およびライト要求の処理方式について説明する。
【0210】
ライト要求の処理方式は、実施例2のライトプログラム515bと同様である。リード要求の処理方式は、実施例1のリードプログラム514において、クラウド20内のボリューム310に対してリード要求を発行するS2004、S2005の処理を、外部VOLに対してリード要求を発行する処理に置き換える。PVOL700に対してIO要求が発行されているため、ストレージシステム200は、PVOL700のアドレスを外部VOL900のアドレスに置き換え、リード要求を処理する。ストレージシステム200が外部ストレージ接続機能のリード処理を動作させることで、クラウドのボリューム703からデータを読み出すことができる。このように、ストレージシステム200は、外部ストレージ接続機能を用いてリード要求を実現することができる。
【0211】
なお、本実施例の計算機システムは、実施例1のような同期リモートコピーを用いてもよい。
【0212】
以上の各実施例では、クラウド20上にHot DataおよびCold Dataの両方が格納されている。上述したとおり、コピー元のストレージシステム200がホスト100から受領したライトを、継続してクラウド20へ送り続ける。さらに、ストレージVM300は、コピー元のストレージシステム200が受領したライトの順序に従い、SVOL703にライトデータを書き込んでいる。すなわち、SVOL703は常に一貫性を保った状態である。よって、オンプレミス10のストレージシステム200が障害になった場合には、クラウド20のストレージVM300を用いて、即座に業務を継続することができる。
【0213】
以上の各実施例の計算機システムは、オンプレミス10からクラウド20へライトデータを継続して送っているため、災害によって失われるデータは非常に少ない(RPO(Recovery Point Objective)が良い)。公知技術のように、定期的にコピー元ストレージのスナップショットイメージをクラウドに転送する場合、災害によって失われるデータが非常に多くなる(RPOが悪い)。さらに、定期的な差分コピーによってクラウドのデータを上書きする場合、差分コピー中の障害によって、クラウドのデータは不整合となり業務を復旧することができない。また、差分コピーでクラウドのデータを上書きしない場合は、別領域に差分コピーする必要があり、追加でクラウドに容量が必要となってしまう。
【0214】
以上の各実施例によれば、クラウド20上のホストVM400で別の業務を実行することができる。例えば、クラウド上で分析処理や、テスト・開発業務などが考えられる。
【0215】
クラウドのSVOLに対してスナップショットを適用し、静止化イメージを取得する。スナップショットデータに対して別の業務を実行することができる。
【0216】
本発明の他のユースケースとして、ROBO(Remote Office and Branch Office)が考えられる。オンプレミス10がRemote OfficeまたはBranch Officeとなり、クラウド20がコアデータセンタとなる。クラウド20のストレージVM300は複数のRemote OfficeまたはBranch Officeのデータを一元的に管理する。Remote OfficeまたはBranch Officeのコスト削減が実現される。さらに、クラウド上で実行される分析業務では、複数のオフィスのデータを用いた分析などが考えられる。POSシステムもROBO同様にユースケケースとなり得る。
【0217】
以上の各実施例では、オンプレミス10のデータのコピー先をクラウド20のストレージVM300としたが、コピー先はストレージシステム200と同様の物理的なストレージシステムであってもよい。又、オンプレ側のストレージシステムもコピー先と同じ、又は、異なるクラウド上に構成されるストレージVM300でもよい。
【0218】
以上の各実施例によれば、オンプレミス10のストレージシステム200は、ホスト100に対して仮想ボリュームを提供し、ホスト100からライト要求を受領した際、ライト対象アドレスが含まれる領域が高頻度アクセスの領域である場合、オンプレミス10内の物理記憶領域およびクラウド20内の物理記憶領域の両方を更新し、低頻度アクセスの領域である場合、クラウド20の物理記憶領域のみを更新する。
【0219】
これにより、オンプレミス10で実行される業務への性能を維持しつつ、オンプレミス10に格納されるデータ量の削減によるストレージコストの削減と、クラウド20に格納されたデータを用いる業務を実現する。
【0220】
ストレージシステムは、ストレージシステム200等であってもよい。他のストレージシステムは、クラウド20やストレージVM300等であってもよい。プロセッサは、プロセッサ211等であってもよい。メモリは、メモリユニット220等であってもよい。記憶デバイスは、物理記憶デバイス240等であってもよい。第一ボリュームは、仮想ボリューム293やPVOL700等であってもよい。第二ボリュームは、ボリューム310やSVOL703等であってもよい。第一ストレージシステムは、ストレージシステム200等であってもよい。第二ストレージシステムは、クラウド20やストレージVM300等であってもよい。
【0221】
以上、本発明の実施例を説明したが、本発明は、この実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【符号の説明】
【0222】
10…オンプレミス、 20…クラウド、 30…ネットワーク、 100…ホスト、 110…本番業務、 120…ネットワーク、 200…ストレージシステム、 211…プロセッサ、 220…メモリユニット、 240…物理記憶デバイス、 270…保守端末、 290…容量プール、 291…プールボリューム、 293…仮想ボリューム、 300…ストレージ仮想マシン、 310…ボリューム、 400…ホスト仮想マシン、 410…分析業務
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21