JP2023069701A - データ制御装置、ストレージシステム、及びデータ制御方法 - Google Patents

Abstract

【課題】他拠点にあるデータ単位を使用するアプリケーションを適切に処理できるようにする。【解決手段】アプリケーションで使用するファイルをアクセス可能に管理する分散ファイル・オブジェクトストレージ３２０を管理する管理ノード１００において、分散ファイル・オブジェクトストレージ３２０は、他拠点のストレージで管理されているファイルに対してアクセス可能であり、管理ノード１００は、プロセッサを有し、プロセッサを、アプリケーションによるファイルに関するアクセス状況を特定し、アクセス状況に基づいて、アプリケーションの実行前において、アプリケーションで使用される他拠点のストレージで管理されているファイルについての自拠点の分散ファイル・オブジェクトストレージ３２０によるキャッシュを制御するように構成する。【選択図】図１

Description

本発明は、アプリケーションに使用する他の拠点にあるデータ単位の読み出しを制御する技術等に関する。

ハイブリッドクラウドやＥｄｇｅ－Ｃｏｒｅ連携のような拠点間でのデータ利活用へのニーズが高まっている。こうした背景から、拠点間のデータ共有のためにファイル仮想化機能を有するファイルストレージシステムに対する関心が高まっている。

ファイル仮想化機能は、他拠点にあるファイルと対応するスタブファイルを自拠点に作成し、あたかも自拠点にファイルがあるかのように見せる機能である。アプリケーションがスタブファイルへリードアクセスを行うと、スタブファイルのリード対象部分のデータが他拠点から取得される。このように、データの拠点間転送が発生することとなるので、アプリケーションの性能低下が発生する虞がある。

例えば、データをキャッシュする技術として、特許文献１には、メディア再生アプリケーションにおいて、再生可能性のあるメディアファイルの先頭部分のデータをメディアサーバからキャッシュし、メディアの再生ビットレートと、ネットワークの転送スループットに基づいてキャッシュデータ量を決定する技術が開示されている。

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

しかし、特許文献１に開示された技術は、再生ビットレートが決まっているメディアファイルを対象とする技術であり、メディア再生アプリケーション以外には適用することができない。

本発明は、上記事情に鑑みなされたものであり、その目的は、他拠点にあるデータ単位を使用するアプリケーションを適切に処理することのできる技術を提供することにある。

上記目的を達成するため、一観点に係るデータ制御装置は、アプリケーションで使用するデータ単位をアクセス可能に管理するストレージ装置を制御するデータ制御装置であって、前記ストレージ装置は、自拠点とは別の他拠点のストレージ装置で管理されているデータ単位に対してアクセス可能であり、前記データ制御装置は、プロセッサを有し、前記プロセッサは、前記アプリケーションによる前記データ単位に関するアクセス状況を特定し、前記アクセス状況に基づいて、前記アプリケーションの実行前において、前記アプリケーションで使用される前記他拠点のストレージ装置で管理されているデータ単位についての前記自拠点のストレージ装置によるキャッシュを制御する。

本発明によれば、他拠点にあるデータ単位を使用するアプリケーションを適切に処理することができる。

図１は、一実施形態に係る計算機システムの全体構成図である。 図２は、一実施形態に係る計算機システムの拠点システムのハードウェア構成図である。 図３は、一実施形態に係る計算機システムの拠点システムの構成図である。 図４は、一実施形態に係る計算機システムの各拠点のファイルシステムが管理するファイル間の関係の一例を示す図である。 図５は、一実施形態に係る管理情報ファイルの構成図である。 図６は、一実施形態に係るメタデータデータベースの構成図である。 図７は、一実施形態に係るオペレーションログの構成図である。 図８は、一実施形態に係る拠点間ネットワーク帯域管理表の構成図である。 図９は、一実施形態に係るアプリケーションモデル管理表の構成図である。 図１０は、一実施形態に係る性能モデルの概要を示す図である。 図１１は、一実施形態に係るアクセスパターンモデルを説明する図である。 図１２は、一実施形態に係るアプリケーションモデル作成処理のフローチャートである。 図１３は、一実施形態に係る拠点間横断メタデータ検索処理のフローチャートである。 図１４は、一実施形態に係る拠点内メタデータ検索処理のフローチャートである。 図１５は、一実施形態に係る拠点間横断メタデータ検索結果の構成図である。 図１６は、一実施形態に係るアプリケーションデプロイ処理のフローチャートである。 図１７は、一実施形態に係る実行プラン作成処理のフローチャートである。 図１８は、一実施形態に係るアプリケーション管理表の構成図である。 図１９は、一実施形態に係るアプリケーション実行要求画面の一例を示す図である。 図２０は、一実施形態に係るアプリケーション実行プラン表の構成図である。 図２１は、一実施形態に係るデプロイ前キャッシュデータ量算出方法を説明する図である。 図２２は、一実施形態に係るデプロイ前キャッシュ部分決定方法を説明する図である。 図２３は、一実施形態に係るスタブ作成処理のフローチャートである。 図２４は、一実施形態に係るリコール処理のフローチャートである。 図２５は、一実施形態に係るデプロイ後キャッシュ取得処理のフローチャートである。 図２６は、一実施形態に係るデプロイ後キャッシュ部分決定方法を説明する図である。 図２７は、一実施形態に係るリード処理のフローチャートである。

実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

なお、以下の説明では、「ＡＡＡファイル」、「ＡＡＡ表」、「ＡＡＡデータベース」「ＡＡＡログ」等の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ＡＡＡファイル」、「ＡＡＡ表」、「ＡＡＡデータベース」「ＡＡＡログ」を「ＡＡＡ情報」と呼ぶことができる。

また、以下の説明では、プログラムを動作の主体として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ）によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インターフェースデバイス（例えばＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ））を用いながら行うため、処理の主体がプロセッサとされてもよい。プログラムを動作の主体として説明された処理は、プロセッサ或いはそのプロセッサを有する計算機（システム）が行う処理としてもよい。

また、以下の説明において、同種の要素を区別しないで説明する場合には、参照符号（又は、参照符号のうちの共通符号）を使用し、同種の要素を区別して説明する場合は、要素の識別番号（又は参照符号）を使用することがある。

図１は、一実施形態に係る計算機システムの全体構成図である。

計算機システム１０は、拠点１の拠点システム２０（２０－１）と、拠点２の拠点システム２０（２０－２）と、拠点３の拠点システム２０（２０－３）とを有する。なお、計算機システム１０における拠点の数は、３つに限られず、任意の数でよい。拠点システム２０－１と、拠点システム２０－２と、拠点システム２０－３とは、拠点間ネットワーク１１を介して接続されている。拠点間ネットワーク１１は、例えば、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）である。

拠点システム２０（２０－１，２０－２，２０－３）は、ストレージシステムの一例であり、管理ノード１００と、複数のコンピュートノード２００と、複数のストレージノード３００と、１以上のクライアントノード４００とを含む。管理ノード１００と、コンピュートノード２００と、ストレージノード３００と、クライアントノード４００とは、拠点内ネットワーク１２を介して接続されている。拠点内ネットワーク１２は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）である。

管理ノード１００は、データ制御装置の一例であり、拠点システム２０の各装置を管理する。コンピュートノード２００は、計算装置の一例であり、アプリケーションを実行するエンティティ（例えば、コンテナ、仮想計算機（ＶＭ）、プロセス）を構成して、アプリケーションの処理を実行する。ストレージノード３００は、拠点内の他のストレージノード３００とで、ファイルやオブジェクト（データ単位）を分散して管理する分散ストレージを構成する。クライアントノード４００は、アプリケーションを利用するユーザにより使用される計算機であり、ユーザによる指示を管理ノード１００に送信したり、各種処理結果を表示したりする。

図２は、一実施形態に係る計算機システムの拠点システムのハードウェア構成図である。

拠点システム２０は、管理ノード１００と、コンピュートノード２００と、ストレージノード３００と、クライアントノード４００とを含む。

管理ノード１００は、プロセッサの一例としてのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１と、メモリ１０２と、ディスク１０３と、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｆａｃｅ Ｃａｒｄ）１０４と、これらの構成部を接続するバス１０５とを含む。

ＮＩＣ１０４は、例えば、有線ＬＡＮカードや無線ＬＡＮカードなどのインターフェースであり、拠点内ネットワーク１２を介して拠点内の他の装置と通信し、拠点内ネットワーク１２及び拠点間ネットワーク１１を介して他拠点の装置と通信する。

ＣＰＵ１０１は、メモリ１０２及び／又はディスク１０３に格納されているプログラムに従って各種処理を実行する。

メモリ１０２は、例えば、ＲＡＭ（ＲＡＮＤＯＭ ＡＣＣＥＳＳ ＭＥＭＯＲＹ）であり、ＣＰＵ１０１で実行されるプログラムや、必要な情報を記憶する。

ディスク１０３は、例えば、ハードディスクやＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｉｓｋ）などであり、ＣＰＵ１０１で実行されるプログラムや、ＣＰＵ１０１に利用されるデータを記憶する。

コンピュートノード２００は、ＣＰＵ２０１と、メモリ２０２と、ディスク２０３と、ＮＩＣ２０４と、これらの構成部を接続するバス２０５とを含む。コンピュートノード２００の各構成部は、管理ノード１００の同名の構成部と同様である。

ストレージノード３００は、ＣＰＵ３０１と、メモリ３０２と、ディスク３０３と、ＮＩＣ３０４と、これらの構成部を接続するバス３０５とを含む。ストレージノード３００の各構成部は、管理ノード１００の同名の構成部と同様である。

クライアントノード４００は、ＣＰＵ４０１と、メモリ４０２と、ディスク４０３と、ＮＩＣ４０４と、これらの構成部を接続するバス４０５とを含む。クライアントノード４００の各構成部は、管理ノード１００の同名の構成部と同様である。

図３は、一実施形態に係る計算機システムの拠点システムの構成図である。

クライアントノード４００は、クライアントプログラム４２０を格納し、実行する。クライアントプログラム４２０は、ユーザに指示に基づく各種要求（例えば、アプリケーションのデプロイ要求）を管理ノード１００に送信し、管理ノード１００からの各種情報を表示出力する。

管理ノード１００は、ＱｏＳ（Ｑｕａｌｉｔｙ Ｏｆ Ｓｅｒｖｉｃｅ）制御プログラム１２０と、アプリケーション管理プログラム１６０と、ストレージ管理プログラム１８０とを格納し、実行する。

ＱｏＳ制御プログラム１２０は、デプロイ要求受付プログラム１２５と、リソース割当管理プログラム１３０と、モデル管理プログラム１３５とを含む。

デプロイ要求受付プログラム１２５は、クライアントノード４００からのデプロイ要求を受け付け、要求に基づいて処理を行う。リソース割当管理プログラム１３０は、アプリケーションモデルに基づいて、アプリケーションを実行するコンテナへのリソース割当量を算出する。リソース割当管理プログラム１３０は、拠点間ネットワーク帯域管理表９００を格納する。モデル管理プログラム１３５は、アプリケーションモデルの管理や作成の処理を行う。モデル管理プログラム１３５は、アプリケーションモデル管理表１０００を格納する。

アプリケーション管理プログラム１６０は、アプリケーションを管理する処理を行う。アプリケーション管理プログラム１６０は、例えば、アプリケーションのデプロイ指示を後述するアプリケーション実行基盤２２０に送信する。

ストレージ管理プログラム１８０は、ストレージノード３００で構成される分散ファイル・オブジェクトストレージ３２０の管理処理を行う。具体的には、ストレージ管理プログラム１８０は、分散ファイル・オブジェクトストレージ３２０に管理されているデータの操作、ファイルについてのメタデータの検索用のＵＩのクライアントノード４００への提供、メタデータの検索の分散ファイル・オブジェクトストレージ３２０への指示等を行う。

コンピュートノード２００は、実行基盤プログラム２２７と、リソース割当制御プログラム２４０とを格納し、実行する。

リソース割当制御プログラム２４０は、アプリケーションへのリソースの割り当てを制御する。

実行基盤プログラム２２７は、他のコンピュートノード２００（本実施形態では、同一の拠点内のコンピュートノード２００）の実行基盤プログラム２２７と共働することにより、アプリケーション実行基盤２２０を構成する。

アプリケーション実行基盤２２０においては、アプリケーションを実行する１以上のコンテナが構成される。図３においては、アプリケーション２２１－Ａ（アプリケーションＡ）とアプリケーション２２１－Ｂ（アプリケーションＢ）とのコンテナが構成された例を示している。

また、アプリケーション実行基盤２２０には、アプリケーション管理表１４００と、ＩＯ解析プログラム２２５が格納される。アプリケーション管理表１４００は、アプリケーション実行基盤２２０においてデプロイできるアプリケーションの情報を格納する。ＩＯ解析プログラム２２５は、アプリケーション実行時のオペレーションログ８００を作成し、管理する。

ストレージノード３００は、実行基盤プログラム３２３と、リソース割当制御プログラム３４０とを格納し、実行する。

リソース割当制御プログラム３４０は、後述する分散ファイル・オブジェクトストレージ３２０に対するリソースの割り当てを制御する。

実行基盤プログラム３２３は、他のストレージノード３００（本実施形態では、同一の拠点内のストレージノード３００）の実行基盤プログラム３２３と共働することにより、分散ファイル・オブジェクトストレージ３２０を構成する。分散ファイル・オブジェクトストレージ３２０は、ストレージ装置の一例である。

分散ファイル・オブジェクトストレージ３２０は、ファイル、オブジェクト等のデータ単位を分散して管理する処理を行う。分散ファイル・オブジェクトストレージ３２０は、ファイル・オブジェクト仮想化プログラム３２１と、ＱｏＳ制御プログラム３２２と、メタデータＤＢ（データベース）プログラム７５０と、管理情報ファイル６００と、ユーザファイル５００とを含む。

ファイル・オブジェクト仮想化プログラム３２１は、他の拠点にあるユーザファイルを自拠点にあるように見えるようにする仮想化処理を行う。例えば、ファイル・オブジェクト仮想化プログラム３２１は、スタブファイル（スタブオブジェクト）のデータのキャッシュ状況や、ファイルのレプリケーションの状況を管理する。ＱｏＳ制御プログラム３２２は、アプリケーションに割り当てるＩＯ制御を行う。

メタデータＤＢプログラム７５０は、メタデータＤＢ７００を管理し、検索クエリに基づいて、自拠点のメタデータＤＢ７００を検索し、検索結果を、要求元に送信する。メタデータＤＢ７００は、分散ファイル・オブジェクトストレージ３２０に管理されているユーザファイルのメタデータを格納する。管理情報ファイル６００は、ファイル・オブジェクト仮想化プログラム３２１が使用する管理情報を格納する。ユーザファイル５００は、分散ファイル・オブジェクトストレージ３２０のユーザが利用するファイル（ユーザファイル）である。

図４は、一実施形態に係る計算機システムの各拠点のファイルシステムが管理するファイル間の関係の一例を示す図である。

本実施形態においては、ファイルシステムで取り扱うファイルの種類は、オリジナルのファイル（オリジナルファイル：図中ではｏｒｉｇｉｎａｌ）と、スタブ化されたファイル（スタブファイル：図中では、ｓｔｕｂ）と、キャッシュ化されたファイル（キャッシュファイル：図中では、ｃａｃｈｅ）と、レプリケーションされたファイル（レプリカファイル：図中では、ｒｅｐｌｉｃａ）とのいずれかとなる。スタブファイル、キャッシュファイル、レプリカファイルは、ファイル・オブジェクト仮想化プログラム３２１により生成される。

ここで、オリジナルファイルは、その拠点において作成されて管理され、ファイルの実データを含むファイルであり、スタブファイルは、他拠点のオリジナルファイルのデータを参照するために生成されるファイルであり、キャッシュファイルは、スタブファイルの中でファイル内の全データがキャッシュされたファイルであり、レプリカファイルは、バックアップなどを目的として他拠点のオリジナルファイルを複製したファイルである。なお、本実施形態に係るファイルシステムでは、或るオリジナルファイルに対応するスタブファイル、キャッシュファイル、レプリカファイルのＵＵＩＤは、オリジナルファイルのＵＵＩＤと同じである。

拠点１のファイルシステム（分散ファイル・オブジェクトストレージ３２０により管理されているファイルシステム）は、ルートディレクトリ５５０－１０、ディレクトリ５５０－１１、５５０－１２、５５０－１３を有する。

ディレクトリ５５０－１１には、ファイル５００－１１、５００－１２が格納されている。ファイルシステムにおいて、各ファイル５００は、複数の拠点の分散ファイル・オブジェクトストレージ３２０において一意であるＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）により特定することができる。本実施形態では、各ファイルについては、さらにバージョン管理がされており、特定のバージョンのファイルは、ＵＵＩＤ及びバージョン番号により特定可能である。

ファイル５００－１１は、ファイル名Ｆｉｌｅ１であり、ＵＵＩＤはＡＡＡＡであり、バージョン番号はｖｅｒ．１であるオリジナルファイルである。ファイル５００－１２は、ファイル５００－１１の更新版のファイルであり、バージョン番号がｖｅｒ．２に更新されている。

ディレクトリ５５０－１２には、ファイル５００－２１が格納されている。ファイル５００－２１は、拠点２に格納されているファイル５００－５１をオリジナルファイルとするスタブファイルである。

ディレクトリ５５０－１３には、ファイル５００－３１が格納されている。ファイル５００－３１は、拠点３に格納されているファイル５００－７１をレプリケーションしたレプリカファイルである。

拠点２のファイルシステムは、ルートディレクトリ５５０－２０、ディレクトリ５５０－２４、５５０－２５を有する。

ディレクトリ５５０－２４には、ファイル５００－４１が格納されている。ファイル５００－４１は、拠点１のファイル５００－１１に対応するキャッシュファイルである。ディレクトリ５５０－２５には、ファイル５００－５１が格納されている。ファイル５００－５１については、対応するスタブファイル５００－２１が拠点１に格納されている。

拠点３のファイルシステムは、ルートディレクトリ５５０－３０、ディレクトリ５５０－３６、５５０－３７を有する。

ディレクトリ５５０－３６には、ファイル５００－６１が格納されている。ファイル５００－６１は、拠点１のファイル５００－１１をレプリケーションしたファイルである。ディレクトリ５５０－３７には、ファイル５００－７１、５００－８１が格納されている。ファイル５００－７１をレプリケーションしたファイル５００－２１は、拠点１に格納されている。

次に、管理情報ファイル６００について説明する。

図５は、一実施形態に係る管理情報ファイルの構成図である。なお、図５における管理情報ファイルは、例えば、図４のファイル５００－１２に対応している。

管理情報ファイル６００は、ユーザファイル５００毎に生成される。管理情報ファイル６００は、ユーザファイル管理情報６１０と、部分管理情報６５０とを含む。

ユーザファイル管理情報６１０は、ＵＵＩＤ６１１、バージョン６１２、仮想パス６１３、ファイル状態６１４、参照先拠点６１５、参照元拠点６１６、レプリケーション先拠点６１７、レプリケーション元拠点６１８、及びメタデータ登録済みフラグ６１９のフィールドを含む。

ＵＵＩＤ６１１には、管理情報ファイル６００に対応するユーザファイル５００（図５の説明において対応ユーザファイルという）のＵＵＩＤが格納される。バージョン６１２には、対応ユーザファイル５００のバージョン番号が格納される。仮想パス６１３には、拠点におけるファイルシステムでの対応ユーザファイルの格納先を示すファイルパスが格納される。ファイル状態６１４には、対応ユーザファイルの状態が格納される。ファイルの状態としては、オリジナル（Ｏｒｉｇｉｎａｌ）、スタブ（Ｓｔｕｂ）、キャッシュ（Ｃｈａｃｈｅ）、複写（Ｒｅｐｌｉｃａ）のいずれかがある。

参照先拠点６１５には、対応ユーザファイルがスタブファイルである場合において、このファイルに対応するオリジナルファイルが格納されている拠点（参照先拠点）の拠点名が格納される。参照元拠点６１６には、対応ユーザファイルに対応するスタブファイルが格納されている拠点（参照元拠点）の拠点名が格納される。レプリケーション先拠点６１７には、対応ユーザファイルのレプリカファイルが格納されている拠点（レプリケーション先拠点）の拠点名が格納される。レプリケーション元拠点６１８には、対応ユーザファイルがレプリカファイルである場合に、このファイルに対応するオリジナルファイルが格納されている拠点（レプリケーション元拠点）の拠点名が格納される。メタデータ登録済みフラグ６１９には、対応ユーザファイルのメタデータがメタデータＤＢ７００に登録されたか否かのフラグが格納される。メタデータ登録済みフラグ６１９には、メタデータが登録されている場合には、Ｔｒｕｅが設定され、登録されていない場合には、Ｆａｌｓｅが設定される。

部分管理情報６５０は、対応ユーザファイルの各部分に対応するエントリを含む。部分管理情報６５０のエントリは、オフセット６５１、サイズ６５２、及び部分状態６５３のフィールドを含む。

オフセット６５１には、エントリに対応する部分の対応ユーザファイルにおける先頭位置を示すオフセット値が格納される。サイズ６５２には、エントリに対応する部分のデータサイズが格納される。部分状態６５３には、エントリに対応する部分の状態が格納される。部分の状態としては、Ｃａｃｈｅ、Ｄｉｒｔｙ、Ｓｔｕｂがある。Ｃａｃｈｅは、エントリに対応する部分の実データを持っており、実データをレプリケーション先拠点にレプリケーション済みであることを示し、Ｄｉｒｔｙは、エントリに対応する部分の実データを持っており、実データをレプリケーション先拠点にレプリケーションしていないことを示し、Ｓｔｕｂは、エントリに対応する部分の実データを持っていないこと、すなわち、この部分に対するアクセス要求があった場合に、実データを他拠点からデータ取得（リコール）することが必要であることを示している。

次に、メタデータＤＢ７００について説明する。

図６は、一実施形態に係るメタデータデータベースの構成図である。なお、図６におけるメタデータＤＢ７００は、図４の拠点１のメタデータＤＢ７００に対応している。

メタデータＤＢ７００は、各拠点でそれぞれ設けられており、その拠点におけるファイル毎のエントリを格納する。メタデータＤＢ７００のエントリは、ＵＵＩＤ７０１、バージョン７０２、仮想パス７０３、ファイル状態７０４、ファイル種別７０５、及びキーワード７０６のフィールドを含む。なお、ファイルに対して複数のバージョンが存在する場合には、１つのＵＵＩＤ７０１に対して、複数の組（バージョン７０２、仮想パス７０３、ファイル状態７０４、ファイル種別７０５、及びキーワード７０６）が対応付けられる。

ＵＵＩＤ７０１には、エントリに対応するユーザファイル５００（図６の説明において対応ユーザファイルという）のＵＵＩＤが格納される。バージョン７０２には、対応ユーザファイル５００における各バージョンに対応するバージョン番号が格納される。仮想パス７０３には、拠点におけるファイルシステムでの対応ユーザファイル（バージョンがあれば各バージョン）の格納先を示すファイルパスが格納される。ファイル状態７０４には、対応ユーザファイルの状態が格納される。ファイルの状態としては、オリジナル（Ｏｒｉｇｉｎａｌ）、スタブ（Ｓｔｕｂ）、キャッシュ（Ｃｈａｃｈｅ）、複写（Ｒｅｐｌｉｃａ）のいずれかがある。ファイル種別７０５には、対応ユーザファイル５００のファイル種別が格納される。キーワード７０６には、対応ユーザファイルに関するキーワードが格納される。

次に、オペレーションログ８００について説明する。

図７は、一実施形態に係るオペレーションログの構成図である。

オペレーションログ８００は、各拠点でそれぞれにおいて、アプリケーション毎に作成されて管理されている。オペレーションログ８００は、後述するアクセスパターンモデル学習データ１２２０（図１１参照）を生成するために使用される。オペレーションログ８００は、オペレーション毎のエントリを格納する。

オペレーションログ８００のエントリは、アプリＩＤ８０１、コンテナＩＤ８０２、オペレーション８１１、ＵＵＩＤ８１２、バージョン８１３、パス８１４、タイプ８１５、オフセット８１６、サイズ８１７、及びタイムスタンプ８１８のフィールドを含む。

アプリＩＤ８０１には、エントリに対応するアプリケーションの識別子（アプリＩＤ）が格納される。コンテナＩＤ８０２には、エントリに対応するアプリケーションを実行する実体（エンティティ）であるコンテナの識別子（コンテナＩＤ）が格納される。なお、アプリケーション実行基盤２２０において、アプリケーションを実行するエンティティが、仮想計算機（ＶＭ）や、プロセスである場合には、コンテナＩＤ８０２には、そのエンティティの識別子を格納すればよい。オペレーション８１１には、エントリに対応するオペレーション（操作内容）の種別が格納される。オペレーションとしては、例えば、リード（Ｒｅａｄ）、ライト（Ｗｒｉｔｅ）、生成（Ｃｒｅａｔｅ）等がある。ＵＵＩＤ８１２には、エントリに対応するオペレーションの対象としたユーザファイルやディレクトリのＵＵＩＤが格納される。バージョン８１３には、エントリに対応するオペレーションの対象としたユーザファイルのバージョン番号が格納される。パス８１４には、エントリに対応するオペレーションの対象としたユーザファイルやディレクトリについてのパスが格納される。タイプ８１５には、エントリに対応するオペレーションが対象としたユーザファイル又はディレクトリのタイプが格納される。オフセット８１６には、エントリに対応するオペレーションが対象としたユーザファイルのデータの先頭を示すオフセット値が格納される。サイズ８１７には、エントリに対応するオペレーションが対象としたユーザファイルのデータのサイズが格納される。タイムスタンプ８１８には、エントリに対応するオペレーションが実行された時刻を示すタイムスタンプが格納される。

次に、拠点間ネットワーク帯域管理表９００について説明する。

図８は、一実施形態に係る拠点間ネットワーク帯域管理表の構成図である。

拠点間ネットワーク帯域管理表９００は、各拠点間のネットワーク帯域を管理する。拠点間ネットワーク帯域管理表９００の左端の列は、送信元の拠点（送信元拠点）のそれぞれを示し、上端の行は、送信先の拠点（送信先拠点）のそれぞれを示し、それらに対応するフィールド（送信元拠点の行と、送信先拠点の列とが交差するフィールド）には、その送信元拠点と送信先拠点との間のネットワーク帯域が格納される。

次に、アプリケーションモデル管理表１０００について説明する。

図９は、一実施形態に係るアプリケーションモデル管理表の構成図である。

アプリケーションモデル管理表１０００は、アプリケーション毎のエントリを格納する。アプリケーションモデル管理表１０００のエントリは、アプリケーション１００１、性能モデル情報１０１０と、アクセスパターンモデル情報１０２０と、許容リードレイテンシ１００２とのフィールドを含む。

アプリケーション１００１には、エントリに対応するアプリケーションのアプリケーション名が格納される。性能モデル情報１０１０には、エントリに対応するアプリケーションについての性能モデルの情報が格納される。性能モデル情報１０１０は、ＩＯオペレーション１０１１と、性能モデル式１０１２とのフィールドを含む。ＩＯオペレーション１０１１には、エントリに対応するアプリケーションにおけるＩＯオペレーションが格納される。性能モデル式１０１２には、エントリに対応するアプリケーションのＩＯオペレーションにおける性能モデルを示す式（性能モデル式）が格納される。

アクセスパターンモデル情報１０２０には、エントリに対応するアプリケーションについてのアクセスパターンモデルの情報が格納される。アクセスパターンモデル情報１０２０は、アクセスパターンモデル格納パス１０２１のフィールドを含む。アクセスパターンモデル格納パス１０２１には、エントリに対応するアプリケーションのアクセスパターンモデルの格納位置を示すパスが格納される。

許容リードレイテンシ１００２には、エントリに対応するアプリケーションで許容されるリードレイテンシ（許容リードレイテンシ）が格納される。ここで、許容リードレイテンシとしては、アプリケーションがタイムアウトしてしまったり、著しく性能が低下してしまったりするリードレイテンシとしてもよい。なお、図９の例では、許容リードレイテンシ１００２には、リードレイテンシの値を格納するようにしているが、本発明はこれに限られず、例えば、許容リードレイテンシを推定できるリードレイテンシモデルの情報を格納するようにしてもよい。

次に、性能モデル１１００について説明する。

図１０は、一実施形態に係る性能モデルの概要を示す図である。

性能モデル１１００の作成は、例えば、アプリケーションのＩＯ性能（アクセス性能、アクセス状況の一例）を変化させて、その際のアプリケーション性能（アプリケーションの処理性能）を測定することを繰り返し実行して、図１０に示すようなＩＯ性能の変化に対するアプリケーション性能のグラフを作成し、グラフの近似曲線の式、ｙ＝ｇ（ｘ）を性能モデルとしてもよい。この性能モデルが、アプリケーションモデル管理表１０００の対応するアプリケーションの性能モデル式１０１２に格納される。性能モデルの作成におけるグラフの作成及び近似曲線式の導出は、既存の表計算ソフトウェアやプログラム等を用いることにより実現できる。なお、性能モデルは、近似曲線として保持することに限られず、例えば、機械学習モデルとして保持してもよい。ここで、アプリケーション性能としては、例えば、アプリケーションにおける単位時間当たりのデータ処理量としてもよく、アプリケーションによる単位時間当たりの要求に対する処理数や、単位時間当たりの処理ファイル数であってもよい。

また、１つのアプリケーションについて複数の性能モデルを作成するようにしてもよい。例えば、アプリケーションにおいて複数のアルゴリズムから選択して実行させることができる場合には、実行するアルゴリズムごとに性能モデルを作成してもよい。また、アプリケーションにおける分析対象のデータ種別により性能が変化する場合には、分析対象のデータ種別毎に性能モデルを作成してもよい。また、アプリケーションのＩＯオペレーション毎に性能モデルを作成してもよい。

次に、アクセスパターンモデル１２００について説明する。

図１１は、一実施形態に係るアクセスパターンモデルを説明する図である。

アクセスパターンモデル１２００は、アプリケーション毎に生成される。アクセスパターンモデル１２００は、機械学習モデル（深層学習モデルを含む）等の形式により保存されてもよい。

アクセスパターンモデル１２００は、アクセスパターンモデル入力１２４０を入力すると、入力に基づいて予測されるアプリケーションのアクセスパターン（アクセス状況の一例）を推論し、推論結果としてアクセスパターンモデル出力１２６０を出力する。

アクセスパターンモデル入力１２４０は、処理対象ファイル数１２４１と、リード回数１２４２とを含む。処理対象ファイル数１２４１は、アプリケーションで処理対象とするファイルの数である。リード回数１２４２は、アプリケーションにおけるアクセスパターンを判定したいリードの順番（リード回数）である。

アクセスパターンモデル出力１２６０は、パス１２６１と、オフセット１２６２と、サイズ１２６３と、スコア１２６４とを含む。パス１２６１には、アクセスが推定されるファイルへのパスである。オフセット１２６２は、アクセスが推定されるファイルの部分を示すオフセットである。サイズ１２６３は、アクセスが推定されるファイルの部分のサイズである。スコア１２６４は、推論結果の確かさを示すスコアである。

アクセスパターンモデル１２００は、アクセスパターンモデル学習データ１２２０を用いて学習される。アクセスパターンモデル学習データ１２２０は、アクセスパターンモデル１２００の対象とするアプリケーションにおけるリード毎のエントリを格納する。アクセスパターンモデル学習データ１２２０のエントリは、処理対象ファイル数１２２１と、リード回数１２２２と、パス１２２３と、オフセット１２２４と、サイズ１２２５とのフィールドを含む。処理対象ファイル数１２２１には、アプリケーションが処理対象とするファイルの総数が格納される。リード回数１２２２には、エントリに対応するリードの順番（リード回数）が格納される。パス１２２３には、エントリに対応するリードが対象としたファイルのパスが格納される。オフセット１２２４には、エントリに対応するリードが対象としたファイルの部分を示すオフセットが格納される。サイズ１２２５には、エントリに対応するリードが読み出したデータのサイズが格納される。アクセスパターンモデル学習データ１２２０のエントリは、オペレーションログ８００から必要な情報を抽出することにより作成することができる。

なお、図１１では、アクセスパターンモデル１２００に対する入出力情報の一例を記載しているが、アクセスパターンモデル１２００に対する入出力は図示例に限定されない。例えば、一例として、直前複数回のリードアクセス情報に対応するアクセスパターンモデルを入力し、直後の複数回のリードアクセスを予測して出力するようにしてもよい。また、アクセスパターンモデル１２００に対してファイルパスや親ディレクトリのＵＵＩＤを入力するようにしたり、出力するようにしたりしてもよい。また、アクセスパターンモデル１２００の具体的な構成については特段の限定はなく、機械学習（含む深層学習）に用いられる公知の学習モデルであってもよい。

次に、計算機システム１における処理動作について説明する。

図１２は、一実施形態に係るアプリケーションモデル作成処理のフローチャートである。

本実施形態のアプリケーションモデル作成処理では、アプリケーションモデル（性能モデル及びアクセスパターンモデル）を、アプリケーション毎に作成する。アプリケーションモデル作成処理は、例えば、新規アプリケーションを登録する際に管理ノード１００により実行される。

管理ノード１００のモデル管理プログラム１３５（厳密には、モデル管理プログラム１３５を実行するＣＰＵ１０１）は、新たに登録するアプリケーションを実行する指示をアプリケーション実行基盤２２０に行うことにより、アプリケーションを実行させる（ステップＳ１０１）。

モデル管理プログラム１３５は、実行中のアプリケーションのＩＯオペレーションのオペレーションログ８００及びアプリケーション性能を取得する（ステップＳ１０２）。ここで、アプリケーション性能は、処理対象のデータのサイズと、処理時間とに基づいて取得してもよく、例えば、アプリケーションにおける単位時間当たりのデータ処理量としてもよく、アプリケーションによる単位時間当たりの要求に対する処理数や、単位時間当たりの処理ファイル数であってもよい。

次いで、モデル管理プログラム１３５は、アプリケーション（アプリケーションのエンティティ）に割り当てるＩＯ性能を変更し（ステップＳ１０３）、アプリケーション実行基盤２２０にアプリケーションを実行させ、ＩＯオペレーションのオペレーションログ８００及びアプリケーション性能を取得する（ステップＳ１０４）。この処理により、性能モデル１１００を作成するための、アプリケーション性能と、ＩＯ性能との対応関係を示す１つのデータが得られる。

次に、モデル管理プログラム１３５は、アプリケーションの性能モデル１１００を作成可能か否か、具体的には、性能モデル１１００を作成するために必要な回数の性能測定を行ったか否かを判断する（ステップＳ１０５）。

この結果、性能モデルの作成に必要な回数の測定を行っていない場合（ステップＳ１０５：Ｎｏ）には、モデル管理プログラム１３５は、処理をステップＳ１０３に進め、ＩＯ性能の変更と、アプリケーション性能測定とを繰り返す。なお、性能モデル１１００を作成するために性能測定を行う回数と、性能測定ごとに変更するＩＯ性能の変化量とは、予め決められている。

一方、性能モデルの作成に必要な回数の測定を行っている場合（ステップＳ１０５：Ｙｅｓ）には、モデル管理プログラム１３５は、複数の測定結果に基づいて性能モデル１１００を作成する（ステップＳ１０６）。

次いで、モデル管理プログラム１３５は、アプリケーション実行時に取得したオペレーションログ８００からアクセスパターンモデル学習データ１２２０を作成し、アクセスパターンモデル学習データ１２２０を用いてアクセスパターンモデル１２００を生成し（学習させ）（ステップＳ１０７）、作成した性能モデル１１００とアクセスパターンモデル１２００をアプリケーションモデル管理表１０００に登録し（ステップＳ１０９）、処理を終了する。

このアプリケーションモデル作成処理によると、アプリケーションに対応する性能モデルとアクセスパターンモデルを適切に作成することができる。

次に、ユーザが所望のファイルを検索するために、クライアントノード４００によって検索要求を送信したことに起因して実行される拠点間横断メタデータ検索処理及び拠点内メタデータ検索処理について説明する。

図１３は、一実施形態に係る拠点間横断メタデータ検索処理のフローチャートである。

拠点間横断メタデータ検索処理Ｓ２００は、ストレージノード３００がクライアントノード４００からのファイル検索要求を受領したときに実行が開始される。

まず、メタデータＤＢプログラム７５０は、ファイル検索要求を受領すると、自拠点及び他拠点のメタデータＤＢプログラム７５０に対して、ファイル検索要求に対応した検索クエリを発行する（ステップＳ２０１）。この結果、各拠点のメタデータＤＢプログラム７５０は、拠点内メタデータ検索処理Ｓ２５０を実行し、検索結果を要求元のメタデータＤＢプログラム７５０に送信することとなる。

次いで、メタデータＤＢプログラム７５０は、検索クエリの応答である検索結果を各拠点から受領する（ステップＳ２０２）。次いで、メタデータＤＢプログラム７５０は、受領した各拠点の検索結果を集約することにより、拠点間横断メタデータ検索結果１３００（図１５参照）を作成し、ファイル検索要求をしたクライアントノード４００に応答する、すなわち、拠点間横断メタデータ検索結果１３００を送信する（ステップＳ２０３）。

図１４は、一実施形態に係る拠点内メタデータ検索処理のフローチャートである。

拠点内メタデータ検索処理Ｓ２５０は、ステップＳ２０１で発行された検索クエリをメタデータＤＢプログラム７５０が受領した場合に開始される。

まず、メタデータＤＢプログラム７５０は、検索クエリを受領すると、メタデータＤＢ７００から検索クエリの条件に該当するレコードを抽出する（ステップＳ２５１）。次いで、メタデータＤＢプログラム７００は、抽出したレコードから、メタデータへのアクセス権がないレコードを削除する（ステップＳ２５２）。次いで、メタデータＤＢプログラム７００は、残ったレコードを検索結果として検索クエリを発行したメタデータＤＢプログラム７５０に応答する（ステップＳ２５３）。

図１５は、一実施形態に係る拠点間横断メタデータ検索結果の構成図である。

図１５に示す例は、クライアントノード４００により「教育」に関するファイルの検索要求が送信された場合における拠点間横断メタデータ検索結果を示している。

拠点間横断メタデータ検索結果１３００は、検索されたファイルに対応するエントリを含む。拠点間横断メタデータ検索結果１３００のエントリは、ＵＵＩＤ１３０１、バージョン１３０２、拠点１３０３、仮想パス１３０４、ファイル状態１３０５、ファイル種別１３０６、及びキーワード１３０７のフィールドを含む。

ＵＵＩＤ１３０１には、検索結果のユーザファイル５００のＵＵＩＤが格納される。バージョン１３０２には、検索結果のユーザファイル５００のパージョン番号が格納される。拠点１３０３には、検索結果のユーザファイル５００が格納されている拠点の拠点名が格納される。仮想パス１３０４には、検索結果のユーザファイル５００が格納されている拠点内の位置を示すファイルパスが格納される。ファイル状態１３０５には、検索結果のユーザファイル５００の状態が格納される。ファイルの状態は、オリジナル（Ｏｒｉｇｉｎａｌ）、スタブ（Ｓｔｕｂ）、キャッシュ（Ｃｈａｃｈｅ）、複写（Ｒｅｐｌｉｃａ）のいずれかである。ファイル種別１３０６には、検索結果のユーザファイル５００の種別が格納される。ファイル種別としては、ドキュメント、画像等がある。キーワード１３０７には、検索結果のユーザファイル５００に関するキーワードが格納される。

次に、アプリケーションデプロイ処理を説明する。

図１６は、一実施形態に係るアプリケーションデプロイ処理のフローチャートである。

アプリケーションデプロイ処理は、クライアントノード４００においてユーザからアプリケーションの実行要求があった場合に実行される。

クライアントノード４００のクライアントプログラム４２０（クライアントプログラム４２０を実行するＣＰＵ４０１）は、例えば、アプリケーション実行要求画面１５００（図１９参照）等を介して、ユーザからアプリケーションの実行要求（アプリケーション実行要求）を受け付けた場合には、実行要求に従ってアプリケーションをデプロイさせる要求（アプリケーションデプロイ要求）を作成し（ステップＳ３０１）、アプリケーションデプロイ要求を管理ノード１００に送信する（ステップＳ３０２）。

管理ノード１００のデプロイ要求受付プログラム１２５は、アプリケーションデプロイ要求を受け付け、ＱｏＳ制御プログラム１２０は、実行プラン作成処理（Ｓ４００：図１７参照）を実行することにより、アプリケーション実行プラン表１６００（図２０参照）を作成し、ＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ）を満たすアプリケーション実行プランをクライアントノード４００に提示する（ステップＳ３０３）。

クライアントノード４００のクライアントプログラム４２０は、提示されたアプリケーション実行プランを表示させ、ユーザから実行させるアプリケーション実行プランの選択を受け付け、受け付けたアプリケーション実行プランを管理ノード１００に送信する（ステップＳ３０４）。

管理ノード１００のＱｏＳ制御プログラム１２０は、ストレージプログラム１８０を介して、ストレージノード３００のファイル・オブジェクト仮想化プログラム３２１に、スタブ作成要求を送信し、アプリケーション実行プランで指定されたアプリケーションが参照するデータを含むファイル（オブジェクト）のスタブファイル（スタブオブジェクト）を作成するスタブ作成処理を実行させる（ステップＳ５００：図２３）。ここで、スタブ作成要求には、アプリケーション実行プランで指定されたアプリケーションが参照するデータを含むファイルを特定する情報が含まれている。

次いで、ＱｏＳ制御プログラム１２０は、ストレージプログラム１８０を介して、ファイル・オブジェクト仮想化プログラム３２１に、リコール要求を送信して、アプリケーションのデプロイ前にキャッシュすべきデータを取得するためのリコール処理（ステップＳ６００：図２４）を実行させる。ここで、リコール要求には、ユーザに選択されたアプリケーション実行プランにおいて、デプロイ前にキャッシュすべきデータを特定する情報（例えば、拠点名、仮想パス、オフセット、サイズ等の少なくとも一部）が含まれている。

次いで、ＱｏＳ制御プログラム１２０は、リソース割当制御プログラム３４０により、分散ファイル・オブジェクトストレージ３２０に、デプロイ対象のアプリケーションに割り当てるＩＯ性能を設定させ（ステップＳ３０５）、アプリケーション管理プログラム１８０を介して、実行基盤プログラム２２７にアプリケーションをデプロイさせる（ステップＳ３０６）。

次いで、ＱｏＳ制御プログラム１２０は、バックグラウンドでのキャッシュ取得を行う否かを判定し（ステップＳ３０７）、キャッシュ取得を行わないと判定した場合（ステップＳ３０７：Ｎｏ）には、処理を終了する。一方、キャッシュ取得を行うと判定した場合（ステップＳ３０７：Ｙｅｓ）には、ＱｏＳ制御プログラム１２０は、ファイル・オブジェクト仮想化プログラム３２１にデプロイ後にキャッシュを取得するデプロイ後キャッシュ取得処理（ステップＳ７００：図２５）を実行させ、その後処理を終了する。

次に、実行プラン作成処理（Ｓ４００）について説明する。

図１７は、一実施形態に係る実行プラン作成処理のフローチャートである。

ＱｏＳ制御プログラム１２０は、アプリケーション処理性能と、アプリケーションによる拠点間ネットワーク帯域の使用量とを変えた複数の実行プランを作成する（ステップＳ４０１）。

次いで、ＱｏＳ制御プログラム１２０は、アプリケーションに対応するアクセスパターンモデル１２００を用いて、アプリケーションのリードアクセスを予測する（ステップＳ４０２）。

次いで、ＱｏＳ制御プログラム１２０は、アプリケーションデプロイ要求にデプロイ前の全データキャッシュの設定があるか否かを判定する（ステップＳ４０３）。なお、アプリケーション実行要求画面１５００において、デプロイ前の全データキャッシュの設定がされている場合に、アプリケーションデプロイ要求に、この設定が含まれることとなる。

この結果、デプロイ前の全データキャッシュの設定がない場合（ステップＳ４０３：Ｎｏ）には、ＱｏＳ制御プログラム１２０は、予測したリードアクセスのスコアが所定の閾値以上であるか否かを判定する（ステップＳ４０４）。

この結果、予測したリードアクセスのスコアが所定の閾値以上である場合（ステップＳ４０４：Ｙｅｓ）には、ＱｏＳ制御プログラム１２０は、各実行プランでのデプロイ前キャッシュデータサイズと、アプリケーションに関わる総所要時間（キャッシュ取得時間及びアプリケーション実行時間の合計）とを算出する（ステップＳ４０５）。なお、デプロイ前キャッシュデータサイズと、総所要時間とを算出する方法（デプロイ前キャッシュデータ量算出方法１７００：図２１参照）については、後述する。

次いで、ＱｏＳ制御プログラム１２０は、予測したリードアクセスに基づいて、各実行プランでのデプロイ前にキャッシュする部分データを決定し、アプリケーション実行プラン表１６００を作成し（ステップＳ４０６）、処理を終了する。なお、デプロイ前にキャッシュする部分データを決定する方法（デプロイ前キャッシュ部分決定方法１８００：図２２参照）については、後述する。

一方、予測したリードアクセスのスコアが所定の閾値以上でない場合（ステップＳ４０４：Ｎｏ）には、予測したリードアクセスの信頼性が低いことを示しているので、ＱｏＳ制御プログラム１２０は、アプリケーションの許容リードレイテンシが閾値以上であるか否かを判定する（ステップＳ４０７）。

この結果、アプリケーションの許容リードレイテンシが閾値以上である場合（ステップＳ４０７：Ｙｅｓ）には、ＱｏＳ制御プログラム１２０は、各実行プランでのデプロイ前にデータを全てキャッシュしないとして総所要時間を算出し、アプリケーション実行プラン表１６００を作成し（ステップＳ４０８）、処理を終了する。

一方、デプロイ前の全データキャッシュの設定がある場合（ステップＳ４０３：Ｙｅｓ）又はアプリケーションの許容リードレイテンシが閾値以上でない場合（ステップＳ４０７：Ｎｏ）には、ＱｏＳ制御プログラム１２０は、各実行プランについて、デプロイ前に全データをキャッシュするとして総所要時間を算出し、アプリケーション実行プラン表１６００を作成し（ステップＳ４０９）、処理を終了する。

次に、アプリケーション管理表について説明する。

図１８は、一実施形態に係るアプリケーション管理表の構成図である。

アプリケーション管理表１４００は、アプリケーション実行基盤２２０で実行可能なアプリケーションの情報を管理する表であり、アプリケーション毎のエントリを格納する。アプリケーション管理表１４００のエントリは、ＩＤ１４０１と、名称１４０２と、説明１４０３とのフィールドを含む。

ＩＤ１４０１には、エントリに対応するアプリケーションの識別情報（アプリＩＤ）が格納される。名称１４０２には、エントリに対応するアプリケーションの名称が格納される。説明１４０３には、エントリに対応するアプリケーションの説明が格納される。

次に、アプリケーション実行要求画面１５００について説明する。

図１９は、一実施形態に係るアプリケーション実行要求画面の一例を示す図である。

アプリケーション実行要求画面１５００は、例えば、管理ノード１００により、アプリケーション管理表１４００及び拠点間横断メタデータ検索結果１３００等の情報に基づいて作成されて、クライアントノード４００に表示される。アプリケーション実行要求画面１５００は、使用するアプリケーションを選択するためのアプリケーション選択欄１５１０と、アプリケーションで対象とするデータに対する指示を入力する対象データ指示欄１５２０と、ＫＰＩを入力するためのＫＰＩ入力欄１５３０と、送信ボタン１５０４とを有する。

アプリケーション選択欄１５１０には、アプリケーション管理表１４００に登録されているアプリケーションの中の少なくとも一つのアプリケーションが選択可能に表示される。ユーザは、アプリケーション選択欄１５１０において、デプロイさせて実行させるアプリケーションを選択することとなる。

対象データ指示欄１５２０は、対象データを選択する対象データ選択欄１５２１と、対象データを追加する指示を行う追加ボタン１５２２と、全データキャッシュ指定欄１５２３とを含む。

対象データ選択欄１５２１には、例えば、拠点間横断メタデータ検索結果１３００に含まれるデータの中の少なくとも一つのデータが選択可能に表示される。ユーザは、対象データ選択欄１５２１において、アプリケーションで処理対象とするデータを選択することとなる。

追加ボタン１５２２は、対象データ選択欄１５２１に表示させるデータを追加する指示を受け付けるボタンである。追加ボタン１５２２が押下されると、クライアントノード４００は、対象データを追加させる指示を管理ノード１００に送信し、管理ノード１００を介して、対象データを選択するための画面（図示せず）が表示される。

全データキャッシュ指定欄１５２３には、アプリケーションを開始させる前に、使用する全データをキャッシュさせる指示を指定可能なチェックボックスが表示される。このチェックボックスが指定されると、アプリケーションを実行する前（本実施形態では、デプロイ前）において、アプリケーションに使用される対象データのうちのキャッシュされていない全てのデータについてのキャッシュが行われることとなる。

ＫＰＩ入力欄１５３０は、使用するＫＰＩの種類の選択及び、そのＫＰＩの値（目標値の一例）の入力を受け付ける。選択可能なＫＰＩは、例えば、処理時間、処理費用、消費電力、応答時間、又はこれらの組合せであってもよい。

送信ボタン１５０４は、アプリケーション選択欄１５１０、対象データ指示欄１５２０、及びＫＰＩ入力欄１５３０に入力された情報を管理ノード１００に送信する指示を受け付けるボタンである。送信ボタン１５０４が押下されると、クライアントプログラム４２０は、入力された情報に基づくアプリケーション実行要求を管理ノード１００に送信する。

次に、アプリケーション実行プラン表１６００について説明する。

図２０は、一実施形態に係るアプリケーション実行プラン表の構成図である。

アプリケーション実行プラン表１６００は、作成された実行プランについて推定された情報を管理する表であり、作成された実行プラン毎のエントリを含む。アプリケーション実行プラン表１６００のエントリは、アプリケーション処理性能１６０１と、拠点間ネットワーク帯域１６０２と、総所要時間１６０３と、ＫＰＩ達成可否１６０４とのフィールドを含む。

アプリケーション処理性能１６０１には、エントリに対応する実行プランに対して設定されたアプリケーションの処理性能（例えば、データ処理速度）が格納される。拠点間ネットワーク帯域１６０２には、エントリに対応する実行プランに対して設定された拠点間のネットワーク帯域（ネットワーク性能）が格納される。総所要時間１６０３には、エントリに対応する実行プランにおいてアプリケーションの実行に係る総所要時間が格納される。ＫＰＩ達成可否１６０４には、エントリに対応する実行プランにより、指定されたＫＰＩを達成できるか否かの情報（本実施例では、可能又は不可）が格納される。

本実施形態では、例えば、アプリケーション実行プラン表１６００におけるＫＰＩ達成可否１６０４が可能であるエントリに対応する実行プランが、クライアントノード４００を介してユーザに提示される。

次に、デプロイ前キャッシュデータ量算出方法１７００について説明する。

図２１は、一実施形態に係るデプロイ前キャッシュデータ量算出方法を説明する図である。

ここで、アプリケーションの処理対象のデータのデータサイズ（処理対象データサイズ）は把握されており、実行プランに対しては、アプリケーション処理性能と、拠点間ネットワーク帯域とが設定されている。

まず、ＱｏＳ制御プログラム１２０は、処理対象データサイズをアプリケーション処理性能で除算することにより、アプリケーション実行時間を算出する（図２１（１））。また、ＱｏＳ制御プログラム１２０は、性能モデル１１００に対してアプリケーション処理性能を使用する（図２１（２））ことにより、アプリケーションにおけるリードスループットを推定する（図２１（３））。

次いで、ＱｏＳ制御プログラム１２０は、処理対象のデータサイズと、推定されたリードスループットと、拠点間ネットワーク帯域とに基づいて、拠点間ネットワーク帯域の影響を受けることなくアプリケーションを実行するために、デプロイ前（アプリケーションの実行前）に必要なキャッシュデータサイズを算出する（図２１（４））。本実施形態では、キャッシュデータサイズを、処理対象データサイズ×（１－拠点間ネットワーク帯域／リードスループット）により算出する。

次いで、ＱｏＳ制御プログラム１２０は、キャッシュデータサイズを拠点間ネットワーク帯域で除算して、キャッシュ取得時間を算出し（図２１（５））、アプリケーション実行時間とキャッシュ取得時間とを加算することにより、アプリケーションに関わる総所要時間を算出する。このデプロイ前キャッシュデータ量算出方法によると、実行プランを実行する際に必要なキャッシュデータサイズを適切に算出することができる。

次に、デプロイ前キャッシュ部分決定方法について説明する。

図２２は、一実施形態に係るデプロイ前キャッシュ部分決定方法を説明する図である。図２２において、実線の矩形は、デプロイ前にキャッシュする部分を示し、点線の矩形は、デプロイ前にキャッシュしない部分を示している。

実行プラン作成処理のステップＳ４０７においては、アクセスパターンモデル１２００により推定されたアクセスパターンに基づいて、方法１～方法３のいずれかにより、キャッシュ部分を決定する。

アクセスパターンが、シーケンシャルリードであって、リードするファイル順が推定できない場合には、方法１によりキャッシュ部分が決定される。方法１においては、アプリケーションの他の拠点から読み出す必要がある全てのファイルのそれぞれに対して均等な割合で、ファイルの先頭部分からキャッシュするように決定される。例えば、他の拠点から読み出すファイルとして、ＦｉｌｅＸと、ＦｉｌｅＹとがある場合には、ＦｉｌｅＸと、ＦｉｌｅＹとのそれぞれについて、先頭部分から各ファイルの全体に対して均等な割合でキャッシュするように決定される。この方法によると、アクセスされる可能性の高いファイルのデータを適切にキャッシュするように決定できる。

アクセスパターンが、シーケンシャルリードであって、リードするファイル順が推定できる場合には、方法２によりキャッシュ部分が決定される。方法２においては、リードするファイル順を推定し、そのファイル順に従い、そのファイルの先頭部分からキャッシュするように決定される。例えば、他の拠点から読み出すファイルとして、ＦｉｌｅＸと、ＦｉｌｅＹとがある場合であって、ＦｉｌｅＸ、ＦｉｌｅＹの順に読み出される場合には、ＦｉｌｅＸの先頭部分からキャッシュし、ＦｉｌｅＸのデータサイズでは必要なキャッシュデータサイズに満たない場合には、次の順番のＦＩｌｅＹの先頭部分からキャッシュするように決定される。この方法によると、アクセスされる可能性の高いファイルについて読み出される可能性が高い順にファイルのデータを適切にキャッシュするように決定できる。

アクセスパターンが、シーケンシャルリードであって、リードするファイルの部分についての順番が推定できる場合には、方法３によりキャッシュ部分が決定される。方法３においては、リードするファイルの部分の順番を推定し、その順番に従い、各部分をキャッシュデータサイズになるまでキャッシュするように決定される。例えば、他の拠点から読み出すファイルとして、ＦｉｌｅＸと、ＦｉｌｅＹとがあり、ファイルＸの（１）、ＦｉｌｅＹの（２）、（３）の順番に読み出される場合には、ＦｉｌｅＸの（１）からキャッシュし、必要なキャッシュデータサイズに満たない場合には、次の順番のＦＩｌｅＹ（２）、（３）の部分をキャッシュするように決定される。この方法によると、アクセスされる可能性の高い部分について、読み出される可能性が高い順に適切にキャッシュするように決定できる。

実行プラン作成処理のステップＳ４０８においては、方法４に示すように、他の拠点から読み出すファイルをキャッシュしないように決定される。

実行プラン作成処理のステップＳ４０９においては、方法５に示すように、他の拠点から読み出すファイルのデータを全てキャッシュするように決定される。例えば、他の拠点から読み出すファイルとして、ＦｉｌｅＸと、ＦｉｌｅＹとがある場合には、ＦｉｌｅＸと、ＦｉｌｅＹの全てのデータをキャッシュするように決定される。

次に、スタブ作成処理（Ｓ５００）について説明する。

図２３は、一実施形態に係るスタブ作成処理のフローチャートである。

スタブ作成処理Ｓ５００は、例えば、ファイル・オブジェクト仮想化プログラム３２１が管理ノード１００からスタブ作成要求を受領したときに実行される。

まず、ファイル・オブジェクト仮想化プログラム３２１は、自拠点内でスタブ作成要求により指示されたファイルに対応する管理情報ファイル６００とスタブファイルを作成し、メタデータＤＢ７００にファイルに対応するレコード（エントリ）を追加する（ステップＳ５０１）。

次いで、ファイル・オブジェクト仮想化プログラム３２１は、スタブファイルの参照先拠点、つまり、スタブファイルに対応するオリジナルファイルが格納されている拠点のオリジナルファイルに対応する管理情報ファイル６００を更新させる（ステップＳ５０２）。この際、参照先拠点のファイル・オブジェクト仮想化プログラム３２１は、オリジナルファイルの管理情報ファイル６００の参照元拠点６１６のフィールドに、スタブファイルが作成された拠点名を格納する。

次いで、ファイル・オブジェクト仮想化プログラム３２１は、スタブ作成要求の要求元の管理ノード１００に対して、スタブ作成処理の応答を返し（ステップＳ５０３）、処理を終了する。

次に、リコール処理（Ｓ６００）について説明する。

図２４は、一実施形態に係るリコール処理のフローチャートである。

リコール処理Ｓ６００は、例えば、ファイル・オブジェクト仮想化プログラム３２１が管理ノード１００からリコール要求を受領したときに実行される。

ファイル・オブジェクト仮想化プログラム３２１は、リコール要求に含まれている対象のデータのオリジナルがある拠点へ、対象データを取得するためのデータ取得要求を発行する（ステップＳ６０１）。これに対して、データ取得要求を受信した拠点のファイル・オブジェクト仮想化プログラム３２１は、対象データを含む応答を返送することとなる。

次いで、ファイル・オブジェクト仮想化プログラム３２１は、データ取得要求への応答を受領し（ステップＳ６０２）、応答に含まれている対象データを、ファイルに反映させ（ステップＳ６０３）、反映させたファイルに対応する管理情報ファイル６００の部分管理情報６５０の該当部分の部分状態６５３をＣａｃｈｅに変更する（ステップＳ６０４）。

次いで、ファイル・オブジェクト仮想化プログラム３２１は、データが反映されたファイルに対応する管理情報ファイル６００の部分管理情報６５０の全部分の部分状態６５３がＣａｃｈｅであるか否かを判定する（ステップＳ６０５）。

この結果、部分管理情報６５０の全部分の部分状態６５３がＣａｃｈｅである場合（ステップＳ６０５：Ｙｅｓ）には、このファイルの全部分をキャッシュしたことを示しているので、ファイル・オブジェクト仮想化プログラム３２１は、自拠点のメタデータＤＢ７００のこのファイルのファイル状態７０４と、管理情報ファイル６００のファイル状態６１４をＣａｃｈｅに変更し（ステップＳ６０６）、処理をステップＳ６０７に進める一方、部分管理情報６５０の全部分の部分状態６５３がＣａｃｈｅでない場合（ステップＳ６０５：Ｎｏ）には、処理をステップＳ６０７に進める。

ステップＳ６０７では、ファイル・オブジェクト仮想化プログラム３２１は、リコール要求の要求元にリコール処理の完了を応答する。

次いで、ファイル・オブジェクト仮想化プログラム３２１は、アプリケーションで利用されるファイルの他のデータを先読みする先読みキャッシュ取得を行うか否かを判定する（ステップＳ６０８）。ここで、先読みキャッシュ取得行うか否かは、例えば、分散ファイル・オブジェクトストレージ３２０の設定に従って判定される。なお、アプリケーションデプロイ処理Ｓ３００において、バックグラウンドでのデプロイ後キャッシュ取得処理Ｓ７００を実行することとなる場合には、ここでの処理は実行しない。

ここで、先読みキャッシュ取得を行うと判定した場合（ステップＳ６０８：Ｙｅｓ）、ファイル・オブジェクト仮想化プログラム３２１は、管理ノード１００のＱｏＳ制御プログラム１２０に、デプロイ後キャッシュ取得処理Ｓ７００（図２５参照）を実行させ、処理を終了する一方、先読みキャッシュ取得を行うと判定しなかった場合（ステップＳ６０８：Ｎｏ）には、処理を終了する。

次に、デプロイ後キャッシュ取得処理（Ｓ７００）について説明する。

図２５は、一実施形態に係るデプロイ後キャッシュ取得処理のフローチャートである。

ＱｏＳ制御プログラム１２０は、アプリケーションに対応するアクセスパターンモデル１２００を用いて、アプリケーションのリードアクセスを予測し、次にキャッシュとして取得すべき部分（追加キャッシュ部分）を決定する（ステップＳ７０１）。なお、追加キャッシュ部分を決定する方法（デプロイ後キャッシュ部分決定方法１９００：図２６参照）については、後述する。

次いで、ＱｏＳ制御プログラム１２０は、ファイル・オブジェクト仮想化プログラム３２１に、決定した追加キャッシュ部分を取得するリコール要求を送信して、決定した追加キャッシュ部分を取得するためのリコール処理（ステップＳ７０２）を実行させる。ここでのリコール処理は、例えば、ステップＳ６００のステップＳ６０１～Ｓ６０７までの処理である。

次いで、ＱｏＳ制御プログラム１２０は、十分な量のキャッシュがたまったか否かを判定する（ステップＳ７０３）。ここで、十分な量のキャッシュがたまったか否かについては、アプリケーションのリードに対して必要となるデータが不足してしまわないようにするために必要な量のキャッシュがした又は必要なデータの全てのキャッシュが完了したことを判定する。

例えば、バックグラウンドでキャッシュ取得を行う場合、すなわち、アプリケーションデプロイ処理Ｓ３００でのステップＳ７００の処理においては、必要なデータの全てのデータをキャッシュしているか否かでよく、また、例えば、リード処理Ｓ８００におけるリコール処理Ｓ６００において、ステップＳ７００の処理を実行する場合には、例えば、アプリケーションのリードデータサイズに合わせて追加取得するキャッシュデータサイズ（追加キャッシュデータサイズ）を決定してもよい。例えば、追加キャッシュデータサイズは、アプリケーションのリードデータサイズ×（拠点間ネットワーク帯域／リードスループット）としてもよい。このデプロイ後キャッシュ取得処理によると、アプリケーションを実行した後において、後続して利用される可能性の高いデータを適切にキャッシュすることができる。

次に、デプロイ後キャッシュ部分決定方法１９００について説明する。

図２６は、一実施形態に係るデプロイ後キャッシュ部分決定方法を説明する図である。図２６において、実線の矩形は、既にキャッシュしたキャッシュ済部分を示し、点線の矩形は、未だキャッシュしていない未キャッシュ部分を示し、実線の矢印を含む矩形は、次にキャッシュすべき追加キャッシュ部分を示している。

デプロイ後キャッシュ取得処理のステップＳ７０１においては、アクセスパターンモデル１２００により推定されたアクセスパターンに基づいて、方法１－１，１－２，２，３のいずれかにより、追加キャッシュ部分を決定する。

アクセスパターンが、シーケンシャルリードであって、リードするファイル順が推定できない場合には、方法１―１又は、方法１－２により追加キャッシュ部分が決定される。方法１－１においては、他の拠点から読み出す必要がある全てのファイルのそれぞれに対して均等な割合で、ファイルのキャッシュ済部分の次からキャッシュするように決定される。例えば、他の拠点から読み出すファイルとして、ＦｉｌｅＸと、ＦｉｌｅＹとがある場合には、ＦｉｌｅＸと、ＦｉｌｅＹとのそれぞれについて、キャッシュ済部分の直後から各ファイルの全体に対して均等な割合でキャッシュするように決定される。方法１－２においては、実際にファイルに対してアクセスがあった場合において、実際にアクセスされたファイルのキャッシュ済部分の次からキャッシュするように決定される。例えば、他の拠点から読み出すファイルとして、ＦｉｌｅＸと、ＦｉｌｅＹとがあり、実際にＦｉｌｅＸに対するアクセスがあった場合には、ＦｉｌｅＸのキャッシュ済部分の直後から次にキャッシュするように決定される。この方法によると、利用される可能性の高いデータを適切にキャッシュさせることができる。

アクセスパターンが、シーケンシャルリードであって、リードするファイル順が推定できる場合には、方法２によりキャッシュ部分が決定される。方法２においては、リードするファイル順を推定し、そのファイル順に従い、そのファイルのキャッシュ済部分の次からキャッシュするように決定される。例えば、他の拠点から読み出すファイルとして、ＦｉｌｅＸと、ＦｉｌｅＹとがある場合であって、ＦｉｌｅＸ、ＦｉｌｅＹの順に読み出される場合には、ＦｉｌｅＸのキャッシュが終了した場合には、次の順番のＦｉｌｅＹのキャッシュ済部分の次からキャッシュするように決定される。この方法によると、利用される可能性の高いデータを適切にキャッシュさせることができる。

アクセスパターンが、所定の範囲内においてシーケンシャルリードであって、リードするファイルの部分についての順番が推定できる場合には、方法３によりキャッシュ部分が決定される。方法３においては、リードするファイルの部分の順番を推定し、その順番に従い、キャッシュ済の部分の次からキャッシュするように決定される。例えば、他の拠点から読み出すファイルとして、ＦｉｌｅＸと、ＦｉｌｅＹとがあり、ファイルＸの（１）、ＦｉｌｅＹの（２）、（３），（４）の順番に読み出される場合には、ＦｉｌｅＹの（３）までキャッシュ済であれば、次の順番のＦＩｌｅＹ（４）の部分からキャッシュするように決定される。この方法によると、利用される可能性の高い部分のデータを適切にキャッシュさせることができる。

次に、リード処理（Ｓ８００）について説明する。

図２７は、一実施形態に係るリード処理のフローチャートである。

リード処理は、アプリケーション実行基盤２２０にデプロイされた実行されているアプリケーション２２１からのリード要求をファイル・オブジェクト仮想化プログラム３２１が受領した場合に実行される。ここで、リード要求には、読み出す対象のファイルの部分を特定可能な情報が含まれている。

ファイル・オブジェクト仮想化プログラム３２１は、リード要求の対象のファイル（対象ファイル）に対応する管理情報ファイル６００を参照し、対象ファイルの読み出す対象の部分の部分状態６５３がＳｔｕｂであるか否かを判定する（ステップＳ８０１）。

この結果、対象部分の部分状態がＳｔｕｂでない場合（ステップＳ８０１：Ｎｏ）には、対象ファイルの対象部分のデータが、自拠点に既に存在することを意味しているので、ファイル・オブジェクト仮想化プログラム３２１は、処理をステップＳ８０３に進める。

一方、対象部分の部分状態がＳｔｕｂである場合（ステップＳ８０１：Ｙｅｓ）には、ファイル・オブジェクト仮想化プログラム３２１は、決定した対象部分を取得するためのリコール処理を実行し（ステップＳ８０２）、処理をステップＳ８０３に進める。ここでのリコール処理は、例えば、ステップＳ６００と同様な処理でよい。

次いで、ファイル・オブジェクト仮想化プログラム３２１は、このアプリケーションのオペレーションログ８００に対して、リード要求のエントリを追記し（ステップＳ８０３）、ユーザファイルから対象部分のデータを読み出してアプリケーションに返答する（ステップＳ８０４）。

このリード処理によると、既にキャッシュしているデータについては、リコール処理することなく、迅速にアプリケーションに対象部分のデータを返答することができる。

なお、本発明は、上記実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、適宜変形して実施することが可能である。

例えば、上記実施形態において、拠点間のネットワークの情報としてネットワーク帯域を管理するようにしていたが、本発明はこれに限られず、例えば、拠点間のジッタや、レイテンシなどを管理し、利用するようにしてもよい。

また、上記実施形態において、アプリケーションモデル管理表１０００においては、ＩＯオペレーションごとに１つの性能モデルを管理するようにしていたが、例えば、アクセスするデータの種類、例えば、データベース、ファイル、ブロックに応じて性能モデルを管理するようにしてもよく、また、画像ファイル、動画ファイル、音声ファイル等に応じて性能モデルを管理するようにしてもよく、１番目に指定されたファイル（例えば、設定ファイル）と２番目に指定されたファイル（例えば、分析対象ファイル）との組み合わせのそれぞれに対して性能モデルを管理するようにしてもよい。

また、上記実施形態においては、拠点システム２０においては、複数のストレージノード３００により、分散してファイルやオブジェクトを管理する分散ファイル・オブジェクトストレージ３２０を構成するようにしていたが、本発明はこれに限られず、分散ファイル・オブジェクトストレージ３２０に代えて、ファイルを分散して管理する分散ファイルシステムとしてもよく、また、オブジェクトを分散して管理する分散オブジェクトシステムとしてもよく、また、分散して管理を行わないファイルストレージやオブジェクトストレージとしてもよく、また、データをブロック単位で管理するブロックストレージとしてもよい。

また、上記実施形態において、クライアントノード４００と同じ拠点内のコンピュートノード２００及びストレージノード３００とを利用してアプリケーションを実行する例を示していたが、本発明はこれに限られず、例えば、アプリケーションをクライアントノード４００とは違う場所にあるパブリッククラウドのコンピュートノードとストレージノードとによりアプリケーションを実行するようにしてもよい。このような構成とした場合には、アプリケーションをデプロイする前にデータをキャッシュさせておくことにより、アプリケーションをデプロイしてからの処理が終わるまでの時間を抑制でき、パブリッククラウドにおいてデプロイを起因して課金する場合における課金額を抑えることができる。

また、上記実施形態においては、アプリケーションデプロイ処理では、ユーザにより実行するアプリケーション実行プランの選択を受けて、後続の処理を実行するようにしていたが、本発明はこれに限られず、例えば、ＫＰＩを満たすアプリケーション実行プランをユーザによる選択によらずに実行するようにしてもよい。

また、上記実施形態においては、アプリケーションをデプロイする前にデータをキャッシュするようにしていたが、本発明はこれに限られず、アプリケーションをデプロイしたが実際にアプリケーションの処理を開始する前にデータをキャッシュするようにしてもよい。

また、上記実施形態において、ＣＰＵが行っていた処理の一部又は全部を、専用のハードウェア回路で行うようにしてもよい。また、上記実施形態におけるプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記録メディア（例えば可搬型の記録メディア）であってもよい。

１０…計算機システム、１１…拠点間ネットワーク、１２…拠点内ネットワーク、２０，２０－１，２０－２，２０－３…拠点システム、１００…管理ノード、１２０…ＱｏＳ制御プログラム、２００…コンピュートノード、２２０…アプリケーション実行基盤、２２１…アプリケーション、３００…ストレージノード、３２０…分散ファイル・オブジェクトストレージ、３２１…ファイル・オブジェクト仮想化プログラム、４００…クライアントノード

Claims (15)

1. アプリケーションで使用するデータ単位をアクセス可能に管理するストレージ装置を管理するデータ制御装置であって、
   前記ストレージ装置は、自拠点とは別の他拠点のストレージ装置で管理されているデータ単位に対してアクセス可能であり、
   前記データ制御装置は、プロセッサを有し、
   前記プロセッサは、
   前記アプリケーションによる前記データ単位に関するアクセス状況を特定し、
   前記アクセス状況に基づいて、前記アプリケーションの実行前において、前記アプリケーションで使用される前記他拠点のストレージ装置で管理されているデータ単位についての前記自拠点のストレージ装置によるキャッシュを制御する
   データ制御装置。
2. 前記アクセス状況は、前記アプリケーションによる前記データ単位に対するアクセス性能を含み、
   前記プロセッサは、
   前記アクセス性能に基づいて、前記アプリケーションを実行する前にキャッシュすべき前記データ単位のデータのサイズであるキャッシュサイズを決定し、
   決定した前記キャッシュサイズのデータをキャッシュするように前記自拠点の前記ストレージ装置を制御する
   請求項１に記載のデータ制御装置。
3. 前記データ制御装置は、前記アプリケーションの処理性能を実現可能なアクセス性能を特定可能な性能モデルを有し、
   前記プロセッサは、
   前記アプリケーションに対する処理性能に関わる目標としての目標値を受け付け、
   前記性能モデルに基づいて、前記目標値を満たすアクセス性能を特定する
   請求項２に記載のデータ制御装置。
4. 前記プロセッサは、
   前記アプリケーションの処理性能を変えて実際に実行させた場合のアクセス性能の測定を行い、前記測定の結果に基づいて前記性能モデルを作成する
   請求項３に記載のデータ制御装置。
5. 前記プロセッサは、
   前記アクセス性能と、前記自拠点のストレージ装置と前記拠点のストレージ装置との間のネットワーク性能とに基づいて、前記キャッシュサイズを決定する
   請求項２に記載のデータ制御装置。
6. 前記アクセス状況は、前記アプリケーションによる前記データ単位に対するアクセスパターンを含み、
   前記プロセッサは、
   前記アクセスパターンに基づいて、前記データ単位のデータの中のキャッシュする部分を制御する
   請求項１に記載のデータ制御装置。
7. 前記データ制御装置は、前記アプリケーションによる前記アクセスパターンを推定可能なアクセスパターンモデルを有し、
   前記プロセッサは、
   前記アクセスパターンモデルに基づいて、前記アプリケーションによるアクセスパターンを特定する
   請求項６に記載のデータ制御装置。
8. 前記アクセスパターンモデルは、アプリケーションのリードの順番を入力すると、そのリードの順番においてアクセスされるデータ単位の部分を示すアクセス部分情報を出力し、
   前記プロセッサは、前記アクセス部分情報に基づいて、前記データ単位のデータの中のキャッシュする部分を制御する
   請求項７に記載のデータ制御装置。
9. 前記プロセッサは、
   前記アプリケーションを実行した場合のアクセスログを用いて機械学習することにより前記アクセスパターンモデルを作成する
   請求項８に記載のデータ制御装置。
10. 前記アクセスパターンモデルは、さらに、前記アクセス部分情報の確かさを示すスコアを出力し、
    前記プロセッサは、
    前記スコアが所定以上である場合に、前記データ単位について所定のキャッシュサイズのデータをキャッシュするように制御し、前記スコアが所定以上でない場合に、前記データ単位の全てをキャッシュしない又は前記データ単位の全てのデータをキャッシュするように制御する
    請求項８に記載のデータ制御装置。
11. 前記プロセッサは、
    前記アプリケーションが実行された後に、前記自拠点の前記ストレージ装置に対して、前記アプリケーションで使用するデータ単位のデータのうちの前記自拠点の前記ストレージ装置に読み出していないデータをさらに読み出すように制御する
    請求項１に記載のデータ制御装置。
12. 前記アプリケーションは、所定の計算装置にデプロイされて実行され、
    前記プロセッサは、前記計算装置に前記アプリケーションをデプロイする前に、前記アプリケーションで使用される前記他拠点のストレージ装置で管理されているデータ単位について前記自拠点のストレージ装置によるキャッシュさせる
    請求項１に記載のデータ制御装置。
13. アプリケーションを実行可能な計算装置と、前記アプリケーションで使用するデータ単位をアクセス可能に管理するストレージ装置と、前記計算装置と前記ストレージ装置を管理するデータ制御装置とを備えるストレージシステムであって、
    前記ストレージ装置は、自拠点とは別の他拠点のストレージ装置で管理されているデータ単位に対してアクセス可能であり、
    前記データ制御装置は、
    前記計算装置で実行される前記アプリケーションによる前記データ単位に関するアクセス状況を特定し、
    前記アクセス状況に基づいて、前記計算装置での前記アプリケーションの実行前において、前記アプリケーションで使用される前記他拠点のストレージ装置で管理されているデータ単位についての前記自拠点の前記ストレージ装置によるキャッシュを制御する
    ストレージシステム。
14. 前記ストレージ装置は、
    前記計算装置により実行されている前記アプリケーションからデータ単位の読み出しがあった場合に、前記アプリケーションで使用されるデータ単位のデータであって前記他拠点の前記ストレージ装置から読み出されていないデータを読み出す
    請求項１３に記載のストレージシステム。
15. アプリケーションで使用するデータ単位をアクセス可能に管理するストレージ装置を管理するデータ制御装置によるデータ制御方法であって、
    前記ストレージ装置は、自拠点とは別の他拠点のストレージ装置で管理されているデータ単位に対してアクセス可能であり、
    前記データ制御装置は、
    前記アプリケーションによる前記データ単位に関するアクセス状況を特定し、
    前記アクセス状況に基づいて、前記アプリケーションの実行前において、前記アプリケーションで使用される前記他拠点のストレージ装置で管理されているデータ単位についての前記自拠点のストレージ装置によるキャッシュを制御する
    データ制御方法。
    
    
    
    

Images