WO2016174739A1 - 複合計算機システム、管理計算機、およびデータ連携管理方法 - Google Patents

Abstract

複合計算機システムは、リソースプールを構成する１つ以上の分散ストレージをそれぞれ有しジョブの並列分散処理を実行する１つ以上の分散処理計算機を有する第一の計算機システムと、１つ以上の計算機が共有ストレージを共有し、前記第一の計算機システムと接続してデータを送受信する第二の計算機システムと、を有し、前記第一の計算機システムが、前記ジョブを１つ以上のタスクに分割し、前記タスクでアクセスするデータの前記分散ストレージへの展開方法を決定し、前記データを前記第二の計算機システムに要求し、前記第二の計算機システムが、前記データを前記第一の計算機システムに送信し、前記第一の計算機システムが、受信した前記データを前記展開方法によって前記分散ストレージに展開する。

Description

複合計算機システム、管理計算機、およびデータ連携管理方法

　本発明は、ストレージ構成の異なる計算機システム間でデータを連携させる技術に関する。

　情報システムにかかる設備投資を削減する目的や、システム運用のアジリティを高める目的で、サーバの仮想化やストレージの仮想化などの仮想化技術が一般的に用いられている。これら仮想化技術によれば、複数のシステムが物理リソースを共有することにより、物理リソースの利用効率を高めることができる。また、物理リソースの構成による制約を超えてソフトウェア的にリソースを生成することもできる。そのため、柔軟かつ迅速にシステムを構築し、また一旦構築したシステムを他の物理リソース上へと移行することができる。ただし、仮想化技術により構築されるシステムは、性能面においては、物理的な限界を超えた処理性能を有することはできない。そのため、どのような物理リソースによりシステムを構成するかでそのシステムの特性や性能がある程度決まってしまう。

　それに対して仮想化技術で構築されたシステムに対する物理リソースによる制約を低減する検討がなされ、近年、スケールアウト型（集約）基盤と呼ばれるシステムが出現している。これは、複数の物理サーバと、それら物理サーバが内蔵する複数のストレージデバイスとによって、並列分散システムを構成するものである。スケールアウト型基盤は、同じクラスタ内にある複数のノード（物理サーバ）に跨るリソースプールを構成することを可能にしており、仮想サーバあるいはプロセスはいずれの物理ノード上でも実行が可能となる。

　これによって、例えば物理サーバ上に残っている空き容量を気にすることなく仮想サーバを追加することが可能となる。また、物理サーバに故障が生じた際に、物理的な仕様の差異を気にすることなく、システムを他のノードへ移行して処理を継続することができる。また、スケールアウト型基盤では、クラスタの構成によって容易にリソースの容量や構成を変更できるため、単体では信頼性の劣る比較的安価なハードウェアを利用して十分な冗長性を持たせることにより、基盤全体として十分な信頼性を得るといったことも可能である。

　一方、以前より、複数の物理サーバと、それらが使用する共有ストレージ装置とをネットワークによって相互接続したシステムが普及している。ここでは、スケールアウト型に対して、以前よりあるこの種のシステムをスケールアップ型基盤と呼ぶことにする。

　スケールアップ型基盤には決まった共有ストレージ装置というものがあるため、ストレージのリソース追加は原則的に各装置に搭載するデバイスの追加によって行われる。スケールアップ型基盤では、ハードウェアが複雑化しやすいという一面があるものの、制御部などモジュール毎に冗長化することで、信頼性を高められる。そのため、スケールアップ基盤は、高い信頼性と性能が求められるデータベースなどのアプリケーションに適している。そして、実際に現在までに多くの業務システムがこのスケールアップ型基盤で稼働している。したがって、企業が培ってきた多くのデータ、例えば顧客情報や取引情報などが、既存のスケールアップ型基盤に保管され、また更新され続けていると考えてよい。

　これまでスケールアップ型基盤が広く利用されてきたという経緯、スケールアップ型基盤とスケールアウト型基盤の処理特性の違い等から、今後はスケールアップ型基盤とスケールアウト型基盤とを適材適所に使い分けることが重要となる。すなわち、既存のスケールアップ型基盤を維持しながら、新たにスケールアウト型基盤を導入し、それらをネットワーク経由で接続してデータを連携させるような活用方法が求められる。様々な業務アプリケーションがそのデータ形式や要求性能に応じて最適な基盤で提供されるようになることが見込まれる。その際には、既存のスケールアップ型基盤が蓄積したデータをスケールアウト型基盤へ読み込んだり、逆にスケールアウト型基盤での処理結果をスケールアップ型基盤へと格納したりする場面での効率的なデータ連携技術が必須となる。

　特許文献１には、データセンタにあるストレージ装置をあたかもリモートサイトの一部であるかのように利用する仮想化技術が開示されている。同技術では、仮想的に設けたストレージ装置が記憶ブロック単位にＩＯ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）特性を把握するインタフェースを備えており、ＩＯ特性に基づき必要な記憶ブロックを必要な時に転送することができる。特許文献１にはさらに、次に必要となりそうな記憶ブロックを事前に転送させることで異なるサイト間のデータ転送を高効率に行う技術も開示されている。

　また、特許文献２には、処理をどのように分割しどのような順序で実行するかといった分散処理の実行情報をもとに、ストレージ装置に対するＩＯを効率化するように分散処理ノードへの記憶領域の割り当てを制御する技術が開示されている。

米国特許出願公開第２０１１／０２３８７７５号明細書 特開２００８－１５８８８号公報

　特許文献１の技術をスケールアウト型基盤に適用した場合、スケールアウト型基盤の構成を変更することなく、スケールアップ型基盤の特定領域にアクセスできるようになる。しかし、特許文献１によれば、論理的にはスケールアップ型基盤をスケールアウト型基盤の一部として認識させられるものの、記憶ブロック毎のＩＯ特性のみに依存しているため、スケールアウト型基盤に適した形で十分にデータ転送の効率を高めることができない。スケールアウト型基盤では、データを冗長化して分散配置させるため、同じ記憶ブロックを複数回コピーするなどの特有の振る舞いがあり、スケールアップ型基盤に対して冗長なデータ転送を行う可能性が高い。

　特許文献２の技術を、スケールアップ型基盤とスケールアウト型基盤のデータ連携に用いれば、スケールアウト型基盤で稼働する業務アプリケーションの実行状態と連動させて、スケールアップ型基盤が保有するストレージ装置へのアクセスを効率化できる可能性がある。しかし、特許文献２によれば、動的に生成される並列分散処理に対応できるように、スケールアップ基盤からデータを転送する方法が開示されていない。スケールアウト型基盤上では、非同期的かつ並列に処理プロセスが配置され、それら処理プロセスと分散配置されたデータとの応答性能は動的に変化する。そのため、アクセスを効率化するには、処理プロセスの実行順のみならず、データ配置も考慮する必要がある。しかし、スケールアップ型基盤からスケールアウト型基盤へデータを転送する場合には遅延の大きさがボトルネックとなる可能性が高い。遅延の大きさがボトルネックになると、スケールアウト型基盤での処理が待機状態となるばかりか、スケールアップ型基盤で当該データが更新されないようオフラインに設定しておかなければならない期間が長くなる。また、スケールアップ型基盤とスケールアウト型基盤とではデータ配置を異なる管理方法で決定しているが、その差異を解決する技術は特許文献２に開示されていない。

　以上のように、スケールアップ型基盤とスケールアウト型基盤のそれぞれのアーキテクチャに適した方式でデータ連携を行う方法は確立されていない。

　本発明の目的は、スケールアップ型基盤とスケールアウト型基盤の好適なデータ連携を実現する技術を提供することである。

　本発明の一態様による複合計算機システムは、リソースプールを構成する１つ以上の分散ストレージをそれぞれ有しジョブの並列分散処理を実行する１つ以上の分散処理計算機を有する第一の計算機システムと、１つ以上の計算機が共有ストレージを共有し、前記第一の計算機システムと接続してデータを送受信する第二の計算機システムと、を有し、前記第一の計算機システムが、前記ジョブを１つ以上のタスクに分割し、前記タスクでアクセスするデータの前記分散ストレージへの展開方法を決定し、前記データを前記第二の計算機システムに要求し、前記第二の計算機システムが、前記データを前記第一の計算機システムに送信し、前記第一の計算機システムが、受信した前記データを前記展開方法によって前記分散ストレージに展開する。

　本発明によれば、スケールアップ型計算機システムである第二の計算機システムのデータをスケールアウト型計算機システムである第一の計算機システムに適した展開方法で第一の計算機システム内の分散ストレージに展開するので、スケールアップ型計算機システムとスケールアウト型計算機システムの好適なデータ連携を実現することができる。

実施例１による計算機システムの概要ブロック図である。 第一の計算機システムの物理構成を示すブロック図である。 第一の計算機システムの論理構成を示すブロック図である。 第二の計算機システム４０ｂの物理構成を示すブロック図である。 ストレージ構成管理テーブル１５３ｃの具体例を示す図である。 第二の計算機システム４０ｂの論理構成を示すブロック図である。 管理コンピュータ２００上で稼働する管理プログラムの構成を示す図である。 タスク管理テーブル２０３の具体例を示す図である。 データ配置管理テーブル２０６について具体例を示す図である。 リソース構成管理部２０７により管理されるリソース構成の一例を示す図である。 ユーザが第一の計算機システム４０ａでジョブを投入してから第二の計算機システム４０ｂにて必要なデータが特定されるまでの流れを示すシーケンス図である。 第二の計算機システムのデータを第一の計算機システムに展開する処理を示すシーケンス図である。 実施例２におけるデータ転送動作を示す図である。

　以下、本発明の実施形態に係る計算機システムについて図面を参照して説明する。

　本実施例によれば、スケールアップ型基盤からスケールアウト型基盤へ効率的にデータをロードする複合型の計算機システムが提供される。

　＜計算機システムの物理構成および論理構成＞

　図１は、実施例１による計算機システムの概要ブロック図である。

　本実施例の計算機システムは、大きく第一の計算機システム４０ａおよび第二の計算機システム４０ｂから構成されている。アーキテクチャの差異により、第一の計算機システム４０ａをスケールアウト型基盤４０ａとも呼び、第二の計算機システム４０ｂをスケールアップ型基盤４０ｂとも呼ぶことにする。

　第一の計算機システム４０ａは、主に一つ以上の物理サーバ１０によるクラスタ１１により構成されている。クラスタ１１に参加している状態を指して、物理サーバ１０はノードとも呼ばれる。各物理サーバ１０は、ネットワーク５０ａに接続され、互いに通信が可能であるように設定される。同計算機システム４０ａを構成する同ネットワーク５０ａ、各物理サーバ１０、クラスタ１１、および各ノード上に稼働するアプリケーション３０ａの構成は、管理コンピュータ２００ａにより制御される。計算機システム４０ａは、ネットワーク５０ａを介して、一つ以上のクライアントコンピュータ２５０に対して、アプリケーション３０ａが実現するサービスを提供する。

　第一の計算機システム４０ａにおいて、クラスタ１１に参加する各物理サーバ１０は、分散システムおよび分散ストレージを構成しており、第一の計算機システム４０ａは並列処理に適している。

　各ノード１０は、ネットワーク５０ａを介して物理的には別のノードが備えているストレージ領域にアクセスすることができ、必要に応じて演算処理を振り分けることができる。

　また、クラスタ１１において供給可能な処理容量が不足した場合には、新たなノード１０を追加することで、計算能力や記憶領域を拡充することができる。この特性により、第一の計算機システム４０ａは、スケールアウト型基盤４０ａと呼ばれる。

　第二の計算機システム４０ｂは、一つ以上の物理サーバ２０がネットワーク５０ｂを介して接続されたストレージ装置１００を共有する形態をとる。同計算機システム４０ｂを構成するネットワーク５０ｂ、各物理サーバ２０、ストレージ装置１００、および各物理サーバ２０上に稼働するアプリケーション３０ｂの構成は、管理コンピュータ２００ｂにより制御される。計算機システム４０ｂは、ネットワーク５０ｂを介して、一つ以上のクライアントコンピュータ２５０に対して、アプリケーション３０ｂが実現するサービスを提供する。

　第二の計算機システム４０ｂでは、事前にアプリケーションが必要とするリソース要求量を見積もったうえで、十分なリソース容量を予約するという運用が主となる。前述の仮想化技術により、物理的に存在するリソース総量に対してより多いリソース予約量を定義可能とすることで、システム全体のリソース利用効率を高める。このとき、あるアプリケーションに対して割り当てられる実リソースは、予約量まで単体容量を拡張することができる。リソース単体で拡張させるという意味で、第一の計算機システム４０ｂはスケールアップ型基盤４０ｂと呼ばれる。

　従来より、需要の上限や下限が見積もりやすく、信頼性と単体性能の確保が求められる業務、例えば顧客管理システムあるいは生産管理システムなどのミッションクリティカルな基幹業務はスケールアップ型基盤４０ｂで構築されてきた。

　一方、短期間のキャンペーンサイト、エンドユーザの活動傾向が変化しやすいなど需要の予測が難しい用途、あるいはメッセージングや従業員の仮想デスクトップ基盤やセンサデータを分析するといったアプリケーションへの負荷が同時多発的に集中する用途など、既存のスケールアップ型基盤では収容が難しい、あるいはコストがかかりすぎる用途が近年増える傾向にある。スケールアウト型基盤４０ａは、これら変化が激しい大規模な需要に対して柔軟に対応できる基盤として注目を集めている。

　図２は、第一の計算機システムの物理構成を示すブロック図である。第一の計算機システム４０ａにおける主な物理的構成要素は、一つ以上の物理サーバ１０である。物理サーバ１０は、アプリケーション３０ａを稼働させる目的や、クラスタ１１機能を実現する制御部、あるいは管理コンピュータ２００ａを実現する管理プログラムを設置する目的に利用される。物理サーバ１０を制御するＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）やアプリケーション１２の主たる機能を実現するプログラムは、メモリ（主記憶装置）２２上に展開され、ＣＰＵ２１により計算処理を行う。

　これら物理サーバ１０の主要な処理部は、データバス２３を介してＮＩＣ２５のようなネットワークアダプタや入出力装置などの処理部と接続される。不揮発性の入出力装置（ストレージメディア）は、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）１０８、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）１０５、フラッシュメモリ２９などその種類に応じて、例えばディスクコントローラ２７のようにデバイスの制御を担当するコントローラを介して接続されてもよい。複数のデバイスを同じデータバス２３に接続する目的で、例えばＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ　Ｃｏｍｐｏｎｅｎｔ　Ｉｎｔｅｒｃｏｎｎｅｃｔ　Ｅｘｐｒｅｓｓ）を利用している場合には、物理サーバ１０はＰＣＩｅスイッチ２４のように接続を切り替える機構を備えていてもよい。ストレージメディアとして使用可能なデバイスは、同図に示すＳＳＤ１０８、ＨＤＤ１０５、ＰＣＩ接続フラッシュメモリ２９に限らず、性能や価格によって他のメディアを含むメディアの種類および数量などの構成を変更してもよい。

　一般に、高速に読み書きが可能なストレージメディア、例えばＰＣＩ接続フラッシュメモリやＳＳＤは容量あたりの価格が高く、他方でＨＤＤなど低速であるが容量あたりの価格がより廉価なストレージメディアと組み合わせて使用される場合が多い。このような費用対性能は使用するハードウェアの種別と直結するため、デバイスを種別ごとにまとめたストレージ階層と呼ばれる概念で取り扱う。

　物理サーバ１０はそれぞれが具備するＮＩＣ２５によってネットワーク５０ａに接続される。ネットワーク５０ａは物理サーバ１０や管理コンピュータ２００ａを相互に接続するものであればよく、一つあるいは複数のネットワークスイッチによって構成されていてもよい。また、ネットワーク５０ａは同図に示す物理構成に依存せず、相互に通信する目的を達成するものであれば、いかなるプロトコルを使用するものであってもよい。例えばＩｎｆｉｎｉ－Ｂａｎｄなど別のプロトコルを使用するものでもよい。これらのデバイスは一般に、ネットワーク５０ａの装置故障に対応するため、同図に示すように物理的には複数の回線に接続される。

　図３は、第一の計算機システムの論理構成を示すブロック図である。

　前述の通り、物理サーバ１０は主にハイパバイザ３１を備える分散処理ノードとして利用されるが、その他に、必要なソフトウェアを導入して管理コンピュータ２００ａ、あるいはストレージアプライアンス３６ｃとしても利用できる。ここではクラスタ１１内の複数の物理サーバ１０が連携して単一のファイルシステムを構成する機能を有しており、第一の計算機システム４０ａは分散ストレージ型のシステムであるといえる。

　物理サーバ１０のうち分散処理ノードとして利用されるものは、ハイパバイザ３１を有するいわゆる仮想マシンホストである。ハイパバイザ３１は、仮想マシンモニタ（Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ　Ｍｏｎｉｔｏｒ）とも呼ばれる一般的な仮想化機構であり、ソフトウェアによって仮想的なハードウェアを模擬することで、一台の物理サーバ上に複数のゲストＯＳ３２を稼働させる。ハイパバイザ３１によりユーザが使用するゲストＯＳ３２毎に区画された領域を仮想マシン、特にユーザ向けサービスに供される場合にはインスタンス３５と呼び、アプリケーション３０ａはゲストＯＳ３２により制御される仮想的なリソースを利用して稼働する。

　より具体的には、ハイパバイザ３１は、一般的なＯＳ（ゲストＯＳ３２）がハードウェアを制御するよりもより上位の割り込み命令（ハイパバイザコール）を使用して、例えば時分割スケジューリングやアドレス変換によりＣＰＵ２１、メモリ２２等のデバイスを多重化する。実装の形態は物理ハードウェアとＯＳとの間に動作するハイパバイザ３１や、物理的なデバイスを制御するファームウェアに組み込まれたものなど多様である。ハイパバイザ３１の機能により、各インスタンス３５には仮想的なリソースが割り当てられており、見かけ上、物理サーバ１０が備える物理デバイスの数量や容量に制約されない。

　分散ストレージコントローラ３６ａは内蔵ストレージ３７（例えばＳＳＤ１０８やＨＤＤ１０５、フラッシュメモリ２９など）を制御し、別の分散処理ノード上に稼働する分散ストレージコントローラ３６ａとネットワーク５０ａを介して協調し、分散ストレージを実現する制御部である。アプリケーション３０ａが動作するインスタンス３５は、全て同じ物理サーバ１０上に配置された分散ストレージコントローラ３６ａを経由してストレージ領域にアクセスする。

　複数の分散処理ノード１０にある分散ストレージコントローラ３６ａが連動することで、分散ファイルシステムが構成されている。分散ファイルシステムにより、あるインスタンス３５内のゲストＯＳ３２は、同じクラスタ１１にある別の物理サーバ１０内に格納されている内蔵ストレージ３７にアクセスできる。

　一般にファイルシステムは、格納されるデータ本体とは別に、格納先アドレスやファイル構造を表現するメタデータを持つ。本実施例における分散ファイルシステムでは、同一クラスタ１１内にある全ての分散ストレージコントローラ３６ａがメタデータを同期し、全てのノードがストレージ資源を共有する。この機能により、インスタンス３５は、配置された物理サーバ１０によらず、論理的にはクラスタ１１内の内蔵ストレージ３７を総計した容量を活用できる。

　また、データ本体は一つではなく、複製を別のノードに配置する。このような冗長化の仕組みにより、耐障害性を高めると同時に読み込み性能を向上させる。例えば、あるデータを３つの分散処理ノード１０の内蔵ストレージ３７にそれぞれ持つことにより、並列実行されるインスタンスはそれぞれ近傍の内蔵ストレージ３７を参照すればよく、物理故障により当該内蔵ストレージ３７の一つが読み書き不能に陥った場合でも、残ったその他２つの内蔵ストレージのいずれかを参照して処理を継続できる。

　データ本体を冗長化するために、分散ストレージコントローラ３６ａは、あるデータ領域に書き込みが行われた場合、続けてその他のノードにあるデータ本体を更新する。このとき、複製元となるデータ領域をマスタと呼ぶ。このようなファイルシステム層における複製処理はスケールアウト型基盤４０ａに特有のデータ管理処理であり、ハードウェアデバイス層で冗長化を行うスケールアップ型基盤４０ｂとの差異である。

　複製処理はネットワーク５０ａを経由して行われ、他のノード上にある分散ストレージコントローラ３６ａが複製処理を完了するまでの間は、マスタに同期されていない（ファイルシステムとしては書き込みが完了していない）状態にある。したがって、この種の分散ファイルシステムにおける書き込み処理は、読み込み処理よりも長い時間を要する。スケールアウト型基盤４０ａの外部から新たなデータを転送してきた場合には、一旦それらデータの記憶領域をファイルシステム上に確保した後、スケールアウト型基盤４０ａの内部で複製処理を行うという２段階の手続きを踏む必要がある。

　基本的には、同一の物理サーバ１０内にある内蔵ストレージ３７とインスタンス３５とのデータ通信のほうが、物理サーバ１０が別れる場合よりも高速である。そのため、性能が不足した際には、格納先の内蔵ストレージ３７上のデータを別のノードの内蔵ストレージ３７へ移行する、あるいはインスタンス３５を使用するデータが格納されたノードへ移行する、などの手段によって性能を改善することができる。並列分散システムの一つの利点は、これらデータと処理機構（本実施例ではインスタンス）の配置を工夫することにより、性能およびストレージ容量をシステム全体でバランスさせることにある。

　上述の通り、各分散ストレージコントローラ３６ａはネットワーク５０ａを介して互いに通信する。その際の接続プロトコルとしては、例えば、一般的なｉＳＣＳＩ（Ｉｎｔｅｒｎｅｔ　Ｓｍａｌｌ　Ｃｏｍｐｕｔｅｒ　Ｓｙｓｔｅｍ　Ｉｎｔｅｒｆａｃｅ）接続、ＮＦＳ（Ｎｅｔｗｏｒｋ　Ｆｉｌｅ　Ｓｙｓｔｅｍ）などが利用される。したがって、同じプロトコルに対応するストレージ装置１００を第二の計算機システム４０ｂに用意すれば、分散ストレージコントローラ３６ａがネットワーク５０ｃを介して第二の計算機システム４０ｂのネットワーク５０ｂに接続し、ストレージ装置１００内のストレージ資源を読み書きすることができる。ここでは、そのような第一の計算機システム４０ａと第二の計算機システム４０ｂの境界にある分散ストレージコントローラ３６ａを指して、ストレージゲートウェイと呼ぶことがある。

　このようにストレージゲートウェイが認識する第二の計算機システム４０ｂにあるストレージ領域は、第一の計算機システム４０ａから読み書き可能な状態となる。しかしながら、第一の計算機システム４０ａが本来の性能を発揮する並列分散処理を行う際には、前述の通り、必要なデータを第一の計算機システム４０ａ上の分散ファイルシステムへ配置し直す手続きを踏む。この第二の計算機システム４０ｂのデータを第一の計算機システム４０ａの分散ファイルシステムに配置する手続を、第一の計算機システム４０ａと第二の計算機システム４０ｂの間でのデータ転送と区別するため、データの「展開」と呼ぶことにする。

　分散ストレージコントローラ３６ａはハイパバイザ３１により区画された仮想的なリソース上で動作する仮想マシンである。ただし分散ストレージコントローラ３６ａは他のインスタンス３５と異なりユーザに対してアプリケーション３０ａを提供しない。なお、ストレージコントローラ３６ａの実装の形態としては必ずしも仮想マシンである必要はなく、例えば単一の物理サーバ１０を占有し、ハイパバイザ３１を必要としないストレージアプライアンス３６ｃであってもよい。

　第一の計算機システム４０ａにおいて、管理コンピュータ２００ａは、物理サーバ１０または仮想マシン上に実装される管理プログラム群により構成される。管理コンピュータ２００ａは主に、ネットワーク５０ａを介して各物理サーバ１０（分散処理ノード）やストレージアプライアンス３６ｃと接続し、それらの構成を制御する。管理コンピュータ２００ａを構成する管理プログラムの詳細については後述する。

　図４は、第二の計算機システム４０ｂの物理構成を示すブロック図である。第二の計算機システム４０ｂの主な構成要素は、ユーザが利用するアプリケーション３０ｂや管理プログラムを稼働させるための一台以上の物理サーバ２０、一台以上のストレージ装置１００、およびそれらを相互に接続するネットワーク５５および６５である。

　物理サーバ２０は、図２に示した第一の計算機システム４０ａにおける物理サーバ１０と同様の物理構成を有する。ただし、ストレージ装置１００とのデータ通信を高速化、高信頼化する目的で、ＳＡＮ（Ｓｔｏｒａｇｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）５５に接続できてもよい。ＳＡＮの、より具体的な実現例としては、一つまたは複数のファイバチャネルスイッチおよび各データ入出力装置を接続するためのＨＢＡ（ホストバスアダプタ）５１から構成されるＦＣ　ＳＡＮが挙げられる。ＨＢＡは物理サーバ２０やストレージ装置１００に搭載され、ＨＢＡ５１上に設置されたポートにより他のＨＢＡあるいはファイバチャネルスイッチと結線される。ただし、ＳＡＮ５５の実装はファイバチャネルに限らず、大容量データ通信という同じ目的を達成できるものであればよく、例えばｉＳＣＳＩ、ＦＣｏＥ、Ｉｎｆｉｎｉ－ｂａｎｄといった別の種類のデバイスおよびプロトコルを使用するものであってもよい。

　ストレージ装置１００は、各物理サーバ２０と第一の計算機システム４０ａ内の物理サーバ１０とに対してストレージ資源を提供する機能を有する。ストレージ装置１００は、物理的には一つまたは複数の共有ストレージコントローラ１５０と、一つまたは複数のストレージメディア１０５から構成される。共有ストレージコントローラ１５０の機能により、ストレージ資源の論理的な構成が構築される。共有ストレージコントローラ１５０は一般的なコンピュータアーキテクチャを有し、プロセッサ（ＣＰＵ）１５１がメモリ１５２上に読み込んだ制御プログラム群１５３ｂにより、ストレージ資源の制御に特化した機能を提供する。

　本実施例において、それら制御プログラム群１５３には、少なくともサーバからのデータの読み込みあるいは書き込みの要求に対して応答を返すための応答プログラム１５３ａ、前述の論理的なストレージ構成を制御するためのストレージ制御プログラム１５３ｂ、およびストレージ制御プログラム１５３ｂが制御するストレージ構成を保持するためのストレージ構成管理テーブル１５３ｃが含まれる。ストレージ資源に対するサーバからのデータ通信は、ＨＢＡ５１により接続されるＳＡＮ５５またはＮＩＣ１５５により接続されるＬＡＮ６５を介して行われる。ストレージ応答プログラム１５３ａは、使用する通信方式に合わせて複数のプロトコルを解釈する。より具体的には、例えば、ストレージコントローラ１５０上のＨＢＡ５１に対してはファイバチャネル接続、ＮＩＣ１５５に対してはｉＳＣＳＩ接続あるいはＮＦＳにより、ストレージ資源に対する読み書き機能を提供する。

　管理コンピュータ２００ｂから共有ストレージコントローラ１５０への通信は、主にＮＩＣ１５５により送受信される。

　またプロセッサ１５１は、ストレージメディア１０５とのデータ送受信を行うためのＳＡＳ　ＩＦ１５４、あるいはサーバへの応答を高速に行う目的で設置された一時データ領域であるキャッシュ１５３を活用して共有ストレージコントローラ１５０の機能を実現している。特にキャッシュ１５３は、不揮発性のストレージメディア１０５に比べて容量は小さいものの、非常に高速にデータを読み書きすることができるという特性を利用するものであり、サーバから要求されたデータがキャッシュ１５３上にある度合すなわちキャッシュヒット率が高ければ高いほど、ＩＯ性能の向上が見込める。

　キャッシュ１５３からストレージメディア１０５への読み書きは、例えばパリティ値の計算およびＲｅａｄ　Ｍｏｄｉｆｙ　ＷｒｉｔｅなどＣＰＵ１５１への処理コストをも伴う。それら処理コストはＩＯの長さまたはシーケンシャルアクセスの比率などのＩＯ特性と、メディアへアクセスするタイミングを左右する許容ダーティ率の閾値など、共有ストレージコントローラ１５０の設定とに応じて変化する。ここでいうＩＯの長さというのは、ＩＯコマンド毎に転送されるデータサイズのことである。

　ストレージ制御プログラム１５３ｂは、ストレージメディア１０５をそのままサーバに提供するのではなく、その上に論理的なデータ構造を定義し、ストレージ資源の効率的な運用管理を実現している。ストレージ制御プログラム１５３ｂは、第二の計算機システム４０ｂにおける物理サーバ２０および第一の計算機システム４０ａの物理サーバ１０に対して、ストレージ資源をボリューム１０１という構成単位により提供する。

　ストレージ装置１００において、いずれのボリューム１０１も複数台のストレージメディア（ここではＨＤＤ）１０５から構成されるＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ　Ａｒｒａｙｓ　ｏｆ　Ｉｎｄｅｐｅｎｄｅｎｔ　Ｄｉｓｋｓ）グループ１０４内のデータ構造として定義される。ただし、ストレージ資源の提供方法としては大別して、ＲＡＩＤグループ１０４から直接的に定義されたボリューム１０１をサーバに提供する方法（物理ボリューム）と、一旦ストレージプール１０６という別の構成単位に組み入れ、さらにストレージプール１０６から割り当てたボリューム（仮想ボリューム１０７）をサーバに提供する方法の２種類がある。

　後者は例えば、物理サーバ２０用には仮想的に定義したボリューム１０７と認識させておきながら、実際にデータが書き込まれた容量のみをストレージプール１０６から割り当てるというストレージ容量仮想化機能を実現するために必要なデータ構造である。なお、一つのストレージ装置１００に対して複数の共有ストレージコントローラ１５０が搭載される場合には、共有ストレージコントローラ１５０間を連結するデータバス１５６を通じてそれら複数の共有ストレージコントローラ１５０が連携し、単一のデータ領域に対して不整合が生じないよう制御される。ストレージ制御プログラム１５３ｂはさらに、ボリューム１０１から提供先物理サーバ２０への論理的な接続であるパスを定義したり、あるいはストレージ装置１００内で特定ボリュームのコピーを作成する機能を有する。

　上述の、ストレージ制御プログラム１５３ｂにより制御されるデータ構造は、ストレージ構成管理テーブル１５３ｃにより保持される。ストレージ構成管理テーブル１５３ｃの具体例を図５に示す。

　本実施例において、同テーブル１５３ｃは、ボリューム１０１に対して付与される単一のストレージ装置１００内で一意な識別子（ボリュームＩＤ）５０１、およびボリュームの種別５０２、容量５０３、論理的な結線を示すパス５０４、ストレージ資源の提供先を示す接続先ＩＤ５０５、ボリュームを構成するメディア５０６を保持する。

　前述の通り、ＲＡＩＤグループ１０４から直接的に定義された物理ボリュームの場合は、種別フィールド５０２に「物理」と記載され、ストレージプール１０６から割り当てた仮想ボリューム１０７の場合は「仮想」と記載される。

　メディアフィールド５０６は、割り当て元を示す情報であり、仮想ボリュームの場合はストレージプール１０６の識別子が記載され、物理ボリュームの場合はＲＡＩＤグループ１０４のストレージ階層および識別子が記載される。ストレージ階層は高速なものから例えば「Ｔ１」「Ｔ２」「Ｔ３」のような番号を付与される。

　物理ボリュームが、ストレージプール１０６の構成要素である場合には、接続先ＩＤフィールド５０５にはストレージプール１０６の識別子が記載される。また、当該ボリュームが第二の計算機システム４０ｂ内の物理サーバ２０に提供されている場合には、接続先ＩＤフィールド５０５には、物理サーバ２０の識別子が記載される。当該ボリュームが第一の計算機システム４０ａ内の物理サーバ１０に提供されている場合には、接続先ＩＤフィールド５０５には、第二の計算機システム４０ｂに含まれないという意味で「Ｅｘｔｅｒｎａｌ」と記載される。また、ストレージ制御プログラム１５３ｂにより、特定ボリュームのコピー（バックアップボリューム１０８）を作成する場合には、接続先ＩＤフィールド５０５にはコピー元となるボリュームのボリュームＩＤが保持される。

　図６は、第二の計算機システム４０ｂの論理構成を示すブロック図である。同図に示すように第二の計算機システム４０ｂでは、アプリケーション３０ｂを稼働させる複数の物理サーバ２０が、物理サーバ２０よりも少数のストレージ装置１００を共有して動作する。これらの装置を相互に接続するネットワーク５０ｂは、物理的にはネットワーク６５あるいはネットワーク５５として実装される。

　この形態のシステムでは、大量のデータコピーあるいはデータ容量の集約を専用のストレージ装置１００側に搭載した機能により実現できるため、アプリケーション３０ｂは物理サーバ２０が提供する能力を効率的に利用することができる。このとき、第二の計算機システム４０ｂは共有ストレージ型のストレージサブシステムを利用していると言える。

　本計算機システム４０ｂにおいては、物理サーバ２０をベアメタルホストおよび仮想マシンホストの二通りの方法で稼働させる。ベアメタルホストとして利用される場合、物理サーバ２０上に物理的な処理リソースを直接的に制御するＯＳ３２が稼働しており、アプリケーション管理者またはユーザがこれをゲストＯＳ３２として利用することで、直接的にホスト２０の論理構成を制御することができる。

　第一の計算機システム４０ａと同じく、ユーザがアプリケーション３０ｂを稼働させる領域を指してインスタンス３５と呼ぶことがある。このとき、ゲストＯＳ３２は、ストレージ装置１００内のボリューム１０１に対して直接読み書きを行う。

　一方、仮想マシンホストの場合は、物理サーバ２０上にハイパバイザ３１を稼働し、物理サーバ２０の物理リソースを仮想的なリソースに区画する。このとき、第一の計算機システム４０ａと同じく、ゲストＯＳ３２が論理的には別の区画で稼働しており、ユーザがアプリケーション３０ｂを稼働させるインスタンス３５を構成する。

　仮想マシンホスト上のハイパバイザ３１の一般的な実装例によれば、ストレージ装置１００内のボリューム１０１にさらにファイルシステムを定義し、ゲストＯＳ３２は仮想ディスク１０２と呼ばれるファイルをストレージ領域と認識する。したがって、ゲストＯＳ３２は仮想ディスク１０２を仮想的なボリューム１０３と認識して読み書きを行う。これにより、例えばハイパバイザ３１が仮想ディスク１０２を別のボリューム１０１に移行した場合でも、ゲストＯＳ３２の設定を変えることなく継続的に読み書きが可能となる。

　第二の計算機システム４０ｂにおいて、管理コンピュータ２００ｂは物理サーバ２０またはある仮想マシンに稼働する管理プログラム群により構築される。管理コンピュータ２００ｂは主にネットワーク５０ｂを介して各物理サーバ２０およびストレージ装置１００、あるいはネットワーク５５を構成するネットワークスイッチに接続し、それぞれの構成を管理する。管理コンピュータ２００ｂを構成する管理プログラムの詳細については後述する。

　＜管理プログラムの構成＞

　図７は、管理コンピュータ２００上で稼働する管理プログラムの構成を示す図である。管理コンピュータ２００上の管理プログラムは複数のモジュールからなる。以下に管理プログラムの各モジュールの役割について説明する。第一の計算機システム４０ａおよび第二の計算機システム４０ｂにおいて同様の機能を持つ管理プログラムは同じ名称を与えるが、同図に示すように、名称の後ろに便宜上ＡあるいはＢの文字を加えて、第一の計算機システム４０ａ上のプログラムか第二の計算機システム４０ｂ上のプログラムかを区別することがある。

　第一の計算機システム４０ａを管理する管理コンピュータ２００ａには、管理プログラムのモジュールで構成される、アプリケーション構成管理部Ａ２０１ａ、タスク実行管理部２０２、データ配置管理部２０４、およびデータ連携制御部Ａ２０５ａを備える。これらモジュールのそれぞれは一貫性を損なわない限りにおいて、複数個が同時に稼働していてもよく、また複数の物理サーバ上に分散して配置されていてもよい。

　アプリケーション構成管理部Ａ２０１ａは、クラスタ１１上で稼働するアプリケーション３０ａの構成を管理する。アプリケーション３０ａは、ＯＳが提供する機能、および第一の計算機システム４０ａが提供する演算リソースを利用して動作している。アプリケーション構成管理部２０１ａはそれらの設定を保持し、またユーザの指定にしたがって設定の変更やシステムへの反映を行う。アプリケーション構成管理部Ａ２０１ａが管理する設定とは、例えばアプリケーションを構成するソフトウェアの種別、導入先リソースを一意に特定する識別子、当該アプリケーションを利用するユーザや処理プロセスのアクセス制御情報、リソース割り当て量を調整するパラメータ、アプリケーションの稼働状態などのことを指す。

　タスク実行管理部２０２は、アプリケーション構成管理部Ａ２０１ａの指定にしたがって、一連の処理（ジョブ）をタスクと呼ぶ処理に分割し、各物理サーバ１０に配置する機能を担う。例えばユーザの要求するジョブが大容量のデータセットを扱うＭａｐＲｅｄｕｃｅ処理の場合、データと処理の依存関係を考慮して分散処理ノード毎に割り振ったり、あるいはノード毎の計算結果を集計したりといったより細かな粒度の処理ステップに分割される。ここではその処理ステップのような実行単位をタスクと呼ぶ。

　タスクを各ノードに配置するには、少なくともタスクの実行順序を定めるスケジュールと、各タスクの配置先ノードを決定するアルゴリズムが実装される。スケールアウト型基盤４０ａにおいては、並列実行により実現される処理性能と消費リソース量とのトレードオフや、ハードウェア故障や論理障害に対抗するための冗長度を考慮する必要があり、タスク実行管理部２０２によって各処理が非同期的かつ動的に配置される。このため、タスクの配置方法は一定でなく、スケールアウト型基盤４０ａにおけるその時々の稼働状態に依存して確定的でない。タスク実行管理部２０２によって管理されるタスクの情報は、同タスク実行管理部２０２が有するタスク管理テーブル２０３により保持される。

　図８は、タスク管理テーブル２０３の具体例を示す図である。タスク実行管理部２０２に受け付けられたジョブは、タスクに分割される。各タスクは、同テーブルにおいてそれぞれジョブＩＤ２０３ａとタスクＩＤ２０３ｂの組によって管理される。各タスクは、実行順序と並列化の効率に応じて定められ、配置すべき順に従って同タスク管理テーブル２０３のレコードとして保持される。以降、タスク管理テーブル２０３に保持されるレコードを指してタスク実行情報と呼ぶことがある。

　各タスクには優先度が与えられ、例えば優先度の高いものから小さい数字を与えられる。優先度は優先度フィールド２０３ｃに保持される。

　また、多重度２０３ｄにより同時に配置される分散処理ノード数あるいはプロセス数が管理される。

　タスク実行管理部２０２によって配置先のノード１０が決定された場合には、配置ノードＩＤフィールド２０３ｅに同ノードを識別する識別子が記録される。

　また、同タスクがデータの読み書きに必要な領域をここではディレクトリと呼び、ディレクトリフィールド２０３ｆにその識別子（パス）が保持される。同ディレクトリに対してデータの利用方法が定義されている場合は属性２０３ｇとして同タスク管理テーブル２０３に保持される。

　データの利用の方法は、より具体的には、読み込み専用データ「Ｒ」、書き込み専用データ「Ｗ」、どちらもあり得る不定のデータ「Ｒ／Ｗ」であることを指す。さらに、当該ジョブが第一の計算機システム４０ａに含まれない外部のデータソース、具体的には第二の計算機システム４０ｂに含まれるデータを指定していた場合には、外部のデータであることを示す「Ｅ」を付加して「Ｒ（Ｅ）」「Ｗ（Ｅ）」などと記載する。

　データ配置管理部２０４は、タスク実行に必要なディレクトリに対して、実際に割り当てられストレージデバイスの識別子およびデバイス上のアドレスを管理する。データ配置管理部２０４は、データ配置（装置の識別子またはＬＵＮ（Ｌｏｇｉｃａｌ　Ｕｎｉｔ　Ｎｕｍｂｅｒ）などのボリューム構造、あるいはデバイス上のブロックアドレス）を管理していても、それがどのアプリケーションがどのタスクで使用するデータ領域なのか、単体では把握できない。

　データ配置管理部２０４は、上記データ配置をデータ配置管理テーブル２０６により管理しており、タスク実行情報に含まれるディレクトリと、各分散処理ノード１０に配置されたデータとを対応づけられる。

　データ配置管理テーブル２０６について具体例を図９に示す。本実施例において同データ配置管理テーブル２０６は、タスク毎に論理的なデータの格納先を示すディレクトリ２０６ａ、タスク実行管理部２０２によりタスクの割り当てを受けているか否かを示す割り当てフラグ２０６ｂ、同データ領域がマスタであるか否かを示すマスタフラグ２０６ｃ、当該データ領域がタスクから利用可能であるか等を示す状態２０６ｄ、配置先の内蔵ストレージを示す配置先デバイス２０６ｅを保持する。

　タスクからの利用方法が判別できる場合（例えばタスク管理テーブル２０３に属性２０３ｇが保持される場合）には、データ配置管理テーブル２０６に属性２０６ｆをさらに設けてもよい。属性２０６ｆの値はタスク管理テーブル２０３に保持された属性２０３ｇに準ずる。

　配置先デバイス２０６ｅの表現形式としては、少なくとも当該ノードが属するクラスタ１１内で一意であるようにノード名とドライブ番号との組み合わせを用いる。ただし、外部にあるデバイスについては、いずれのノードの内蔵ストレージにも確保されないという意味で、ノード名以外の名称、例えばストレージゲートウェイの名称「Ｇ０１」を用いる。さらに、配置先デバイス２０６ｅには、ストレージコントローラ３６ａが制御に用いるために、メディア階層の種別を、例えば「（Ｔ１）」という形式で付記してもよい。

　実際には、ストレージコントローラ３６ａがストレージ領域の確保、削除、複製、転送などの処理を担当するため、マスタ２０６ｃおよび状態２０６ｄは、各ノード上のストレージコントローラ３６ａが保持するメタデータに従う。

　データ連携制御部Ａ２０５ａは、特に第一の計算機システム４０ａと第二の計算機システム４０ｂとがそれぞれ保持するデータの授受を制御する。データ連携制御部Ａ２０５ａは、その他の管理コンピュータ２００ａ上で稼働する管理プログラム群と通信し、各管理プログラムが管理する構成を解釈し得る。また、第二の計算機システム４０ｂで稼働するデータ連携制御部Ｂ２０５ｂと管理情報を送受信することができ、本発明に特徴的な連携機能を実現する。

　アプリケーション構成管理部Ｂ２０１ｂは、第二の計算機システム４０ｂ上に稼働するアプリケーション３０ｂの構成を管理する。

　リソース構成管理部２０７は、アプリケーション３０ｂの稼働に必要なリソースの構成を管理する。第二の計算機システム４０ｂでは、リソース設計を事前に実施し、必要なリソースを予約する管理方法が一般的であるから、第一の計算機システム４０ａと比較して変更が少ないという意味で静的である。

　図１０は、リソース構成管理部２０７により管理されるリソース構成の一例を示す図である。リソース構成管理部２０７により管理されるリソース構成の具体例を図１０のリソース構成管理テーブル２０８を用いて説明する。

　リソース構成管理テーブル２０８には、インスタンス識別子２０８ａ毎に、仮想マシンであるかベアメタルホストであるかを示す種別２０８ｂ、稼働する物理サーバを示す物理サーバ識別子２０８ｃ、使用するストレージ資源（ボリューム１０１）を一意に特定するターゲットＩＤ２０８ｅ、およびＬＵＮ２０８ｆの組を状態２０８ｄと合わせて保持する。

　さらに、ゲストＯＳ３２が管理するマウントポイントを示すパーティション２０８ｇを保持する。一般的に、アプリケーション３０ｂが使用するファイルの種別毎にストレージ要件が異なるため、リソース構成管理部２０７は、パーティション２０８ｇにより格納先のデバイスを調整する。

　より具体的には、アプリケーション３０ｂの一例としてデータベースを想定した場合、データ本体を格納するために大容量のパーティション「／ｄｅｖ／ｄｂ」と、トランザクション処理が完了する前の更新ログを格納するために書き込み性能の高いパーティション「／ｄｅｖ／ｌｏｇ」とを区別して用意し、使用するボリュームを分離する。バックアップの取得中など、データを静止化する必要がある場合には、当該パーティションへの書き込みを停止し、この時の状態２０８ｄは例えば「ロック中」と表現される。リソース構成管理部２０７は、各インスタンスを作成する際にこれら構成情報をリソース構成管理テーブル２０８に記録し、また構成が変更された場合に同テーブルを更新する。

　データ連携制御部Ｂ２０５ｂは、第一の計算機システム４０ａにて稼働するデータ連携制御部Ａ２０５ａと協調して動作し、第二の計算機システム４０ｂが保持するデータをデータ連携制御部Ａ２０５ａへ転送する。

　第二の計算機システム４０ｂは、第一の計算機システム４０ａと同じく、全体としては随時稼働中の状態にある。したがって、第一の計算機システム４０ａが第二の計算機システム４０ｂ内のデータを要求した際、データの静止化や転送のやり方を誤ると、第二の計算機システム４０ｂのエンドユーザに対してサービス応答の遅延あるいは欠損などの不利益が生じかねない。

　本実施形態では、このようなサービスレベルの低下を最小化しつつ、双方の計算機システムが有するデータおよび処理性能をともに活用できるようにデータ転送の管理が行われる。

＜データ転送の管理方式＞

　ここでは、第一の計算機システム４０ａ上で実行されるジョブおよびタスクに応じて、必要なデータを第二の計算機システム４０ｂから第一の計算機システム４０ａに転送するを例に取り、データ転送の管理方法について説明する。

　データ転送にかかる処理は大きく分けて２つの処理を含む。ひとつ目の処理は、第一の計算機システム４０ａが認識するデータ配置と第二の計算機システム４０ｂが認識するデータ配置との対応関係を把握するための処理である。この処理は図１１を参照して後述する。二つ目の処理は、第一の計算機システム４０ａにおける需要を判別して第二の計算機システム４０ｂから第一の計算機システム４０ａへデータを転送し、第一の計算機システム４０ａ内で展開する処理である。この処理は図１２を参照して後述する。

　まず、一つ目の処理について説明する。

　図１１は、ユーザが第一の計算機システム４０ａでジョブを投入してから第二の計算機システム４０ｂにて必要なデータが特定されるまでの流れを示すシーケンス図である。

　第一の計算機システム４０ａと第二の計算機システム４０ｂでは、例え実体の所在が同じデータであっても、それぞれ異なる論理アドレスを付与している。本実施形態で対象とされているようなデータの連携を実現するには、異なるアーキテクチャを持つ計算機システム間におけるデータ配置の対応関係を把握する手段が必要となる。

　ステップ７０１において、ユーザ（ジョブ要求者７００）がクライアントコンピュータ２５０からアプリケーション構成管理部Ａ２０１ａに対して、所望するジョブを投入する。アプリケーション構成管理部Ａ２０１ａは、ジョブ要求者７００の要求したジョブに設定上の問題がなければ受信した旨をクライアントコンピュータ２５０に応答する。このとき、ジョブ要求者７００が第一の計算機システム４０ａにない外部のデータソースを利用する場合には、ジョブプログラムまたはディレクトリにその識別子を指定する。識別子の形式としては、ＵＲＩ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ）、データベースの接続文字列（コネクションストリング）、ＮＦＳのマウントポイント、あるいはストレージゲートウェイ内の一部領域を指すパスで識別子を表わすという形式を利用する。

　ステップ７０２において、アプリケーション構成管理部Ａ２０１ａは、タスク実行管理部２０２に対してジョブ要求者７００が投入したジョブを新たに登録する。タスク実行管理部２０２は、アプリケーション構成管理部Ａ２０１ａから受信したジョブを複数のタスクに分割し、タスク管理テーブル２０３に保持する（ステップ７０４）。これにより、他の管理プログラムから問い合わせがあった場合には、ジョブおよび関連するタスクの実行状態およびスケジュールなどを伝えられるようタスク実行情報が管理される（ステップ７０３）。

　一方、データ連携制御部Ａ２０５ａはアプリケーション構成管理部Ａ２０１ａに対して定期的に確認を行うなどの方法により、新たなジョブが投入されているかどうか監視する。ステップ７０５において、新たなジョブの投入が確認された場合には、データ連携制御部Ａ２０５ａはタスク実行管理部２０２のタスク管理テーブル２０３を検索し、当該ジョブに対応したタスクのタスク実行情報を取得する。このタスク実行情報には、実行される予定のタスクについて、優先度およびディレクトリといった情報が含まれている。データ連携制御部Ａ２０５ａはこのなかから第二の計算機システム４０ｂに格納されているデータにアクセスするタスク（利用するディレクトリが第一の計算機システム４０ａにないことを示す属性２０３ｇが付与されたもの）を判別する。

　データ連携制御部Ａ２０５ａはさらに、第一の計算機システム４０ａにないと判別されたディレクトリの配置先をデータ配置管理部２０４に問い合わせ、データ配置管理部２０４がどのデバイスから当該データソースを読み込もうとしているかを判別する（ステップ７０６）。より具体的には、データ配置管理テーブル２０６における配置先デバイス２０６ｅのフィールドの値を参照し、例えばストレージゲートウェイ（Ｇ０１等）と記載されたディレクトリを走査し、該当するディレクトリの配置先デバイス２０６ｅのフィールドに含まれているデバイス識別子（Ｄ１０１（Ｔ１）等）を取得する。データ連携制御部Ａ２０５ａは、得られたデバイス識別子とタスク実行情報とを合わせて、第二の計算機システム４０ｂ上のデータ連携制御部Ｂ２０５ｂへ通知する。

　データ連携制御部Ｂ２０５ｂに伝えられたタスク実行情報には、第一の計算機システム４０ａが第二の計算機システム４０ｂ内のリソースに対して付与したアドレス（デバイス情報）が含まれる。前述のように、例えば、第一の計算機システム４０ａ上に稼働するＷｅｂアプリケーションが、第二の計算機システム４０ｂにあるデータベースに接続するための接続文字列、ＮＦＳのマウントポイント、あるいはｉＳＣＳＩ接続のＩＱＮ（ｉＳＣＳＩ　Ｑｕａｌｉｆｉｅｄ　Ｎａｍｅ）、ＳＣＳＩ　ＩＤ（ターゲットＩＤおよびＬＵＮの組など）がこれにあたる。

　このようなアクセス情報（アドレス）は、第一の計算機システム４０ａが外部リソースに対して付与したものであるから、第二の計算機システム４０ｂ内では別のアドレスが付与されていることが一般的である。したがって、ステップ７０７において、データ連携制御部Ｂ２０５ｂは、このアクセス情報を、第二の計算機システム４０ｂにおけるアドレスへと読み替える手順が必要となる。

　このため、データ連携制御部Ｂ２０５ｂは、リソース構成管理部２０７から対応するストレージリソースのアドレス（ターゲットＩＤとＬＵＮの組）および利用状況を取得し（ステップ７０８）、さらに共有ストレージコントローラ１５０へ問い合わせることにより（ステップ７０９）、必要なデータを格納したストレージ領域の当該ストレージ構成を一意に特定する。

　これら管理プログラム群の一連の処理として、より具体的には、まず、ストレージ構成管理テーブル１５３ｃの接続先ＩＤ５０５の中から、外部すなわち本実施例では第一の計算機システム４０ａに向けて提供されたものを検索する。さらに、その外部に向けて提供されているパス５０４と同じボリューム５０１を利用している接続先ＩＤ５０５とパス５０４の組を特定する。さらに、その接続先ＩＤ５０５とパス５０４の組によってリソース構成管理テーブル２０８を検索し、該当するデバイスが属する物理サーバのインスタンスＩＤ２０８ａとそのデバイスの利用の状態２０８ｄを特定する。

　例えば、図５において、接続先ＩＤ５０５が「Ｅｘｔｅｒｎａｌ」と記載された、すなわち外部へ接続されたパスが属するボリュームＩＤ「ＶＯＬ２０１」のボリュームは、他の接続先ＩＤとして「Ｈｏｓｔ　０１」を持ち、ターゲットＩＤ「ＴＲＧ０」、ＬＵＮ「ＬＵＮ３」で接続されている。このとき、図１０において、ターゲットＩＤ「ＴＲＧ０」、ＬＵＮ「ＬＵＮ３」で接続されているところを探すと、物理サーバＩＤ２０８ｃが「Ｈｏｓｔ　０１」でインスタンスＩＤ２０８ａが「ＩＮＳ－０１－０３２」となっているターゲットＩＤ２０８ｅ「ＴＲＧ０」でＬＵＮ２０８ｆ「３」のデバイスが、それに対応していることが分かる。

　図１２は、第二の計算機システムのデータを第一の計算機システムに展開する処理を示すシーケンス図である。同図は、タスクの実行時期が迫った段階で、第二の計算機システム４０ｂから第一の計算機システム４０ａへ必要なデータが転送され、第一の計算機システム４０ａの分散ストレージシステムにおいてデータの展開が行われる一連の処理を示している。図１１に示した前段の処理により、第一の計算機システム４０ａと第二の計算機システム４０ｂにおけるデータの対応関係が把握できているものとする。

　ステップ７１０において、第一の計算機システム４０ａ上のデータ連携制御部Ａ２０５ａは、最新のタスク実行情報をタスク実行管理部２０２に要求して取得し、当該タスク実行情報を参照することにより、タスクが配置されるノード１０を調べる（ステップ７１１）。さらに、データ連携制御部Ａ２０５ａは、第二の計算機システム４０ｂ上のデータ連携制御部Ｂ２０５ｂに対してデータ転送の開始を要求する。また、データ連携制御部Ａ２０５ａは、データ配置については当該タスクのディレクトリパスをもとにデータ配置管理部２０４へ問い合わせ、ロード先となる配置先デバイス２０６ｅ、マスタの配置先、および展開処理の状態２０６ｄなどの情報を取得する（ステップ７１２）。

　ステップ７１３において、第二の計算機システム４０ｂ上のデータ連携制御部Ｂ２０５ｂはデータ転送の要求を受け、当該データ転送を行うためのリソースの確保を開始する。その際、データ連携制御部Ｂ２０５ｂは、他の第二の計算機システム４０ｂのアプリケーションによりアクセスされないよう、まずリソース構成管理部２０７に要求して該当するボリューム１０１のロックを取得する（ステップ７１４）。ロックの取得に成功した場合には、データ連携制御部Ｂ２０５ｂは、当該ボリュームのデータを管理する第二の計算機システム４０ｂ内の共有ストレージコントローラ１５０に対してデータの転送を指示する。

　共有ストレージコントローラ１５０は、データ転送の指示にしたがって、実際に第一の計算機システム４０ａからの要求を待ちうける（ステップ７１５）。

　ただし、アクセスされるボリューム１０１に、その代替となるバックアップボリューム１０８が存在する場合、バックアップボリューム１０８に対して外部へ接続するためのパスを設定しバックアップ元ボリューム１０１のロックを例外的に解放するなど準備を行う（ステップ７１６）。

　一方、データ連携制御部Ａ２０５ａは、ステップ７１７において、第二の計算機システム４０ｂから転送される予定のデータをどのように第一の計算機システム４０ａ上へ配置する（展開する）かを特定のアルゴリズムにしたがって算出する。この展開方法を算出するアルゴリズムとして、より具体的には、タスクが配置される分散処理ノード１０に対して応答速度が最も良い配置先デバイス２０６ｅを選ぶものであったり、複数ある分散処理ノード１０上の分散ストレージコントローラ３６のうちその時点での処理負荷が少ないノードを選ぶものであったり、あるいはタスクの優先度に応じてノード１０上のストレージ階層（ＳＳＤ１０８、ＨＤＤ１０５、あるいはフラッシュ２９）を選択するものが考えられる。

　これらストレージコントローラ３６と分散処理ノードとの処理負荷の関係は、データ配置管理テーブル２０６に記載の配置先デバイス２０６ｅと、タスク管理テーブル２０３に記載の配置ノード２０３ｅを集計することにより制御することができる。例えば、タスクでアクセスされるマスタあるいはコピーのデータを、そのタスクが配置される分散処理ノードの内蔵ストレージに展開するように配置先デバイス２０６ｅを指定すれば、ＩＯ応答の高速化が見込める。

　データ連携制御部Ａ２０５ａは前述のアルゴリズムによって転送対象のデータについて転送順序および展開方法を決定し、データ配置管理部２０４に対してデータの展開を指示する。その指示を受けたデータ配置管理部２０４は、該当するストレージゲートウェイに対してデータの取得を指示する（ステップ７１８）。ここでいうデータの取得はデータのコピーあるいは読み込みである。

　第一の計算機システム４０ａ内の分散ストレージコントローラ３６は、第二の計算機システム４０ｂ内の共有ストレージコントローラ１５０に要求し、共有ストレージコントローラ１５０は要求を受けて分散ストレージコントローラ３６へデータを転送する。それにより、第一の計算機システム４０ａ内の分散ストレージコントローラ３６は、ストレージゲートウェイを介して、第二の計算機システム４０ｂ内の共有ストレージコントローラ１５０から当該データを取得する。取得されたデータは、データ配置管理部２０４からの指定により、各ノード１０の内蔵ストレージ３７へと展開される。

　データの転送が完了した後、第二の計算機システム４０ｂのデータ連携制御部Ｂ２０５ｂは、リソース構成管理部２０７にロック解放を指示し（ステップ７２０）、第一の計算機システム４０ａのデータ連携制御部Ａ２０５ａに制御を戻す。

　本実施例によれば、スケールアウト型基盤（第一の計算機システム４０ａ）において定義されたジョブおよびタスクの実行情報をもとに、データを効率的にスケールアップ型基盤（第二の計算機システム４０ｂ）からスケールアウト型基盤に転送する方法および計算機システムが提供される。これにより、スケールアウト型基盤およびスケールアップ型基盤の間のデータ通信量および記憶容量を削減でき、それら二つを跨った処理の実行にかかる時間を短縮することができる。その結果、計算機システムの利用者は処理あたりにかかるコストを削減し、また収集し、保管したデータをより有用に活用できるといった利益を享受できる。

　また、本実施例によれば、複合計算機システムは、リソースプールを構成する１つ以上（好適には複数（以下同様））の分散ストレージをそれぞれ有しジョブの並列分散処理を実行する１つ以上の分散処理計算機（分散処理ノード）を有する第一の計算機システム４０ａと、１つ以上の計算機が共有ストレージを共有し、第一の計算機システム４０ａと接続してデータを送受信する第二の計算機システム４０ｂと、を有している。第一の計算機システム４０ａが、ジョブを１つ以上のタスクに分割し、そのタスクでアクセスするデータの分散ストレージへの展開方法を決定し、データを第二の計算機システム４０ｂに要求する。第二の計算機システム４０ｂが、そのデータを第一の計算機システム４０ａに送信すると、第一の計算機システム４０ａが、受信したデータをその展開方法によって分散ストレージに展開する。これによれば、スケールアップ型計算機システムである第二の計算機システム４０ｂのデータをスケールアウト型計算機システムである第一の計算機システム４０ａに適した展開方法で第一の計算機システム４０ａ内の分散ストレージに展開するので、スケールアップ型計算機システムとスケールアウト型計算機システムの好適なデータ連携を実現することができる。

　また、本実施例では、第二の計算機システム４０ｂが、第一の計算機システム４０ａにおける論理アドレス（第一の論理アドレス）と第二の計算機システム４０ｂにおける論理アドレス（第二の論理アドレス）とを対応づける管理情報（ストレージ構成管理テーブル１５３ｃ、リソース構成管理テーブル２０８）を予め保持している。第一の計算機システム４０ａが、タスクでアクセスされるデータの第一の論理アドレスを第二の計算機システム４０ｂに送信する。第二の計算機システム４０ｂが、受信した第一の論理アドレスと管理情報に基づいて、データの第二の論理アドレスを特定し、第二の論理アドレスを用いてデータを取得して第一の計算機システム４０ａに送信する。これによれば、スケールアップ型計算機システムである第二の計算機システム４０ｂとスケールアウト型計算機システムである第一の計算機システム４０ａの論理アドレスとを対応づけることができるので、スケールアップ型計算機システムとスケールアウト型計算機システムとで異なる論理アドレスが用いられていてもデータの連携が可能である。

　また、本実施例では、第一の計算機システム４０ａは、タスクの実行要求が発生したとき、データの展開方法の計算を開始する前に、第二の計算機システム４０ｂにデータを送信する準備を要求する。第二の計算機システム４０ｂは、準備の要求を受けると、データの送信を準備して第一の計算機システム４０ａからのデータの送信の要求を待ちうける。これによれば、第一の計算機システム４０ａで展開方法の計算をしている間に第二の計算機システム４０ｂでデータを送信する準備をすることができるので、第一の計算機システム４０ａと第二の計算機システム４０ｂのデータ連携を効率よく行うことができる。

　また、本実施例では、第一の計算機システム４０ａは、タスクでアクセスされるデータを、そのタスクを実行する分散処理計算機の近傍にある分散ストレージに配置するように展開方法を決定する。これによれば、スケールアウト型計算機システムにおいて、分散処理計算機とその分散処理計算機がアクセスする分散ストレージを近くに配置することができるので、ストレージへのアクセスを効率よく行えるようになる。

　また、本実施例では、第一の計算機システム４０ａは、タスクでアクセスされるデータを、そのタスクを実行する分散処理計算機が有する分散ストレージに配置するように展開方法を決定してもよい。

　これによれば、スケールアウト型計算機システムにおいて、分散処理計算機がアクセスするストレージをその分散処理計算機内部に配置することができるので、ストレージへのアクセスを効率よく行えるようになる。

　また、本実施例では、第一の計算機システム４０ａは、１つ以上の分散ストレージに負荷を分散するように展開方法を決定する。これによれば、スケールアウト型計算機システムにおいて、分散ストレージの負荷が偏らないようにデータが展開されるので、アクセスが特定のストレージ装置に集中するのを防止し、アクセスを効率よく行えるようになる。

　また、本実施例では、ジョブが投入されると、第一の計算機システム４０ａは、タスクでアクセスされるデータの第一の論理アドレスを第二の計算機システム４０ｂに送信し、第二の計算機システム４０ｂが、受信した第一の論理アドレスに基づいてデータの第二の論理アドレスを特定する。タスクの実行要求が発生すると、第一の計算機システム４０ａは、タスクでアクセスするデータの分散ストレージへの展開方法を決定し、第二の計算機システム４０ｂにデータを要求し、第二の計算機システム４０ｂは、第二の論理アドレスを用いてデータを取得して第一の計算機システム４０ａに送信し、第一の計算機システム４０ａは、第二の計算機システム４０ｂから送信されたデータをその展開方法によって分散ストレージに展開し、タスクを実行する。これによれば、ジョブ投入時にスケールアウト型計算機システムとスケールアップ型計算機システムの論理アドレスの対応づけを行い、タスクの実行要求発生時にスケールアップ型計算機システムからスケールアウト型計算機システムにデータを送信し、スケールアウト型計算機システムでタスクを実行するので、タスクの実行に必要なデータを効率よくかつ迅速にスケールアウト型計算機システムに展開することができる。

　また本実施例では、分散処理計算機（分散処理ノード）は、ＣＰＵ２１と、メモリ２２と、フラッシュメモリ２９とを有するコンピュータであり、フラッシュメモリ２９上に分散ストレージが構成され、ＣＰＵ２１がソフトウェアプログラムを実行することにより実現される分散ストレージコントローラ３６ａが、管理コンピュータ２００ａのデータ配置管理モジュール（データ配置管理部２０４）から指示された展開方法によりデータを分散ストレージに展開する。

　また、本実施例は、各計算機システムにおいて実行されるアプリケーションの種類あるは仕様を特に制限するものではないが、より具体的には次のような活用例が挙げられる。

　本実施例の複合計算機システムのデータ分析用途への適用例では、例えばスケールアップ型基盤に格納した商品取引のトランザクションを、スケールアウト型基盤上で実行する顧客消費性向の分析に利用する例が考えられる。このとき、データ連携制御部Ａ２０５ａが過去の商品取引情報を参照しようとしているタスクを検知し、分析処理に先んじてスケールアップ型基盤から当該トランザクションデータを転送させる。

　分析処理に先んじて必要なデータをスケールアップ型基盤から取得しておくので、スケールアウト型基盤では分析処理を行うとき当該データの所在を特に気にすることなく処理を継続することができる。例えば、分析処理を行いながら、スケールアップ型基盤からスケールアウト型基盤へのデータ転送の完了を待つ処理、転送されたデータに誤りが無いか検算する処理が必要ない。また、スケールアウト型基盤においてスケールアップ型基盤が蓄積したデータを分析を行うことができるので、分析処理に取り入れる情報の幅が広がり、分析精度を高めることができる。

　また、スケールアップ型基盤のデータをスケールアウト型基盤に転送し、展開してスケールアウト型基盤での分析処理に利用するので、スケールアップ型基盤においてデータがロックされている時間を短縮することができる。例えばスケールアップ型基盤が主目的として商品取引のデータベースとして利用されている場合、データベースの更新を停止しておく時間が短くて済む。

　また、本実施例による複合計算機システムのＷｅｂアプリケーション用途への適用例では、スケールアウト型基盤は多数のクライアントへ動画を並列配信する処理を担い、画像データあるいはクライアントサイドで実行するプログラムなどのような静的コンテンツをスケールアップ型基盤に保持し必要に応じてスケールアウト型基盤へ展開して利用するという例が考えられる。

　具体的には、エンドユーザがＷｅｂサイトにログインしたことを契機として、次に閲覧されるページを判別する。更に、スケールアップ型基盤における当該ページの静的コンテンツが更新されているか否か判定し、更新されていればスケールアップ型基盤からスケールアウト型基盤へ最新の静的コンテンツを転送する。静的コンテンツの開発および更新に関する処理をスケールアップ型基盤で行い、スケールアウト型基盤では、配信する動画コンテンツの制作あるいはプログラムのデバッグを集中的に行う。

　スケールアウト型基盤は大量のクライアントに対して参照専用のデータを並列に送信する処理に適しており、そのような用途ではクライアントからの要求量に応じて展開する規模を調整することができる。

　一方、スケールアップ型基盤に静的コンテンツの開発を集約することで、Ｗｅｂサイト全体の一貫性を担保すると同時にコンテンツの不必要な転送を抑制することができる。また、キャンペーンサイトなど、短期間にエンドユーザが集中してアクセスすると期待されるページについてはデータを展開する数を増やすなど柔軟に構成するような、目的に応じて積極的に投資効率を高める用途にもスケールアップ型基盤で容易に対応することができる。

　また、本実施例による複合計算機システムのＶＤＩ（Ｖｉｒｔｕａｌ　Ｄｅｓｋｔｏｐ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、仮想デスクトップ基盤）へ適用することもできる。その適用例では、例えば利用企業が従業員に使用させる仮想デスクトップの起動用マスタイメージを本社の管理ポリシに従ってスケールアップ型基盤内に作成しておく。スケールアウト型基盤では、支社などに構築したリモートサイトで従業員がＶＤＩを使用する際にスケールアップ型基盤からスケールアウト型基盤に起動用マスタイメージを転送するといった例が考えられる。

　このとき、リモートサイト側で従業員がログインジョブを要求した順序あるいは時期に従ってスケールアップ型基盤からスケールアウト型基盤に転送し、従業員の端末に表示するマスタイメージを変えることも可能である。ログインジョブが要求された順序あるいは時期に基づき転送する起動用マスタイメージの種類を判別し、仮想デスクトップを稼働させるノードの近傍へデータを展開する。それにより、リモートサイト側における起動時間あるいはログイン時間を短縮するとともに必要な記憶容量を削減することもできる。一方で、起動用マスタイメージをスケールアップ型基盤で集中的に管理することで、セキュリティパッチを一貫して適用したり、従業員向けのソフトウェアに対して一括で所定の設定を適用したりといったことが容易に行える。そのガバナンスの高さを確保しながら、集中管理を行うスケールアップ型基盤がボトルネックになるのを抑制することができる。

　実施例１は、スケールアップ型基盤からスケールアウト型基盤へデータをロードする複合計算機システムを例示したが、それに限定する必要はない。他の例として実施例２では、スケールアウト型基盤からスケールアップ型基盤へ効率的にデータをロードする計算機システムを例示する。

　前述のように、スケールアウト型基盤は大規模な並列分散処理を得意とし、スケールアップ型基盤は単体で信頼性あるいは処理速度が求められる処理を得意としている。したがって、アクセスログや非構造データ（自然言語の文章や画像データなど）をスケールアウト型基盤で処理し、その結果をスケールアップ型基盤上のアプリケーションに読み込ませるといった好適な連携が考えられる。

　実施例１に示した計算機システムのシステム構成と計算機システムに格納されている管理プログラムは、スケールアップ型基盤からスケールアウト型基盤へのデータ転送だけでなく、スケールアウト型基盤からスケールアップ型基盤へのデータ転送をも実現する。

　より具体的には、例えば、第二の計算機システム４０ｂで必要となるであろう第一の計算機システム４０ａ上のデータに対してデータ展開先ノードにストレージゲートウェイ３６ｂを含むようにデータ配置管理テーブル２０６を編集しておき、第二の計算機システム４０ｂ内のストレージ装置１００内に確保したボリューム１０１をデータの書き出し先に指定する。

　このとき、データ連携制御部Ａ２０５ａおよびデータ連携制御部Ｂ２０５ｂは、ジョブを分割した複数のタスクを実行する順序と、データをストレージゲートウェイ３６ｂから転送するタイミングを制御することができる。また、その制御により効率的にデータを転送することができる。

　本実施例における計算機システム４０ａ、４０ｂの物理構成および論理構成は実施例１と同じである。これ以降、特に区別が必要な場合を除き、本実施例における各用語は第一の実施例と同じものを指す。

　図１３は、実施例２におけるデータ転送動作を示す図である。

　本実施例では、第一の計算機システム４０ａからデータを転送するための領域を第二の計算機システム４０ｂ内に仮想ボリューム１０７として確保する。

　第二の計算機システム４０ｂにおいて、データ連携制御部Ｂ２０５ｂは、共有ストレージコントローラ１５０に対して仮想ボリューム１０７の作成を指示し、さらに、第一の計算機４０ａに公開するためのポート７３２を設定する。

　第二の計算機システム４０ｂのデータ連携制御部Ｂ２０５ｂは、第一の計算機システム４０ａのデータ連携制御部Ａ２０５ａと連携し、分散ストレージコントローラ３６ａの一部をストレージゲートウェイ３６ｂとして設定し、内蔵ストレージ３７と仮想ボリューム１０７とをマッピングする。これにより、第一の計算機システム４０ａから第二の計算機システム４０ｂ内の仮想ボリューム１０７を分散ファイルシステム７３０の一部として利用可能になる。

　第二の計算機システム４０ｂにおいてアプリケーション３０ｂを構築する際に、主たる処理に使用するボリューム１０１に加えて上述の仮想ボリューム１０７を設ける場合を考える。このとき、第二の計算機システム４０ｂのデータ連携制御部Ｂ２０５ｂは、データ連携制御部Ａ２０５ａを経由して、第一の計算機システム４０ａ向けのジョブを作成し、アプリケーション構成管理部Ａ２０１ａに投入する。

　その後、図１１に示したシーケンスと同様に、タスク実行管理部２０２によるタスクの生成（ステップ７０４）が行われ、タスクおよび配置先デバイスがデータ配置管理部２０４により設定される。ここでデータ連携制御部Ａ２０５ａは、集計処理（例えば各タスクの処理結果の論理和や論理積などジョブの最終結果を得る処理）を担当するタスクをタスク管理テーブル２０３から検索し、データを格納するディレクトリ２０３ｆを特定する。さらに、データ配置管理部２０４を経由して、データ配置管理テーブル２０６に保持された当該ディレクトリ２０６ａの配置先デバイス２０６ｅをストレージゲートウェイ３６ｂが管理する第二の計算機システム４０ｂ向け領域のデバイスＩＤに変更する。このとき、当該デバイスがマスタ（演算プロセスから直接的に書き込みが行われる領域）でなくとも、分散ストレージコントローラ３６ａの自律的な動作により当該デバイスへと複製（図１３中の集約動作７３１）される。このように、実際に集計処理が行われる時のみ第一の計算機システム４０ａから第二の計算機システム４０ｂへのデータ転送７３３が行われる。

　第二の計算機システム４０ｂでは、仮想ボリューム１０７へアクセスすることにより、あたかも同一システム内に集計結果が生成されたように第一の計算機システム４０ａの処理結果を参照することができる。また、第二の計算機システム４０ｂは、第一の計算機システム４０ａ向けの処理中データを常に更新しておく必要はなく、第一の計算機システム４０ａにおける一連のタスクが完了した時、必要な処理結果のみを転送すればよい。

　以上、本実施例にて説明したように、複合計算機システムは、第二の計算機システム４０ｂから第一の計算機システム４０ａへのデータ転送のみならず、第一の計算機システム４０ａから第二の計算機システム４０ｂへのデータ転送も効率的に実現する。

　本実施例のより具体的な適用事例としては、例えばＷｅｂアプリケーション処理のログを利用したサーバプログラムの改良が挙げられる。スケールアウト型基盤（第一の計算機システム４０ａ）にユーザ要求に応じて自動スケーリングするＷｅｂアプリケーションサーバを展開しておき、スケールアップ型基盤（第二の計算機システム４０ｂ）には同アプリケーションの開発環境を構築する。データ連携制御部Ｂ２０５ｂは、同アプリケーションの処理ステップとその所要時間などのログを集計して全体のボトルネックとなっている処理ステップを抽出するジョブをアプリケーション構成管理部Ａ２０１ａに投入する。このとき、データ展開時にストレージゲートウェイ３６ｂを配置先デバイスに含むように設定しておくことで、集計結果をスケールアップ型基盤（第二の計算機システム４０ｂ）にロードする。これにより、スケールアップ型基盤においてアプリケーションサーバのプログラム開発を行う開発者に対し、ユーザの要求度合が高く、Ｗｅｂアプリケーション中の処理で最も高速化および処理方法の改良が期待される処理ステップを提示することができる。

　この適用事例によれば、特別にサーバプログラムの性能テストを作成して実施することなく、かつ実際のユーザ行動とＷｅｂアプリケーションの動作を反映しているという点において精度が高い改良を行うことができ、かつそのために必要なデータ転送を最小限に抑えられる。

　以下、実施例２の構成について整理して説明する。

　実施例２の複合計算機システムは、実施例１と同様に、リソースプールを構成する１つ以上の分散ストレージと分散ストレージ３７を制御する１つ以上の分散ストレージコントローラ３６ａをそれぞれ有しジョブの並列分散処理を実行する１つ以上の分散処理計算機１０を有する第一の計算機システム４０ａと、１つ以上の計算機２０が共有ストレージを共有し、第一の計算機システム４０ａと接続してデータを送受信する第二の計算機システム４０ｂと、を有している。第二の計算機システム４０ｂは、仮想ボリュームを作成して第一の計算機システム４０ａに公開する。第一の計算機システム４０ａが、少なくとも一部の分散ストレージコントローラ３６ａをゲートウェイに設定することにより仮想ボリュームを利用可能にする。さらに、第二の計算機システム４０ｂが、第一の計算機システム４０ａにジョブを投入する。第一の計算機システム４０ａが、そのジョブを処理して処理結果を仮想ボリュームを介して第二の計算機システム４０ｂに返す。

　これによれば、スケールアップ型基盤である第二の計算機システム４０ｂは仮想ボリュームを介して第一の計算機システム４０ａに処理を実行させるので、あたかも同一システム内で仮想ボリュームを用いて処理しているかのうように、ジョブをスケールアップ型基盤で実行させることが可能となる。

　また、本実施例では、第二の計算機システム４０ｂが、第一の計算機システム４０ａにジョブを投入すると、第一の計算機システム４０ａが、そのジョブを複数のタスクに分割して並列分散処理し、複数のタスクのうち処理結果を集約するタスクの集約処理結果を格納するディレクトリの配置先をゲートウェイが管理する第二の計算機システム４０ｂの領域に設定する。更に、第二の計算機システム４０ｂは、仮想ボリュームへアクセスすることにより、第一の計算機システム４０ａの集約処理結果を参照する。

　これによれば、第一の計算機システム４０ａがジョブを複数のタスクに分割して並列分散処理し、その並列分散処理の処理結果を集約し、集約した最終的な処理結果を第二の計算機システム４０ｂから参照可能にするので、第二の計算機システム４０ｂは第一の計算機システム４０ａでのジョブの処理の仕方を意識することなく、第一の計算機システム４０ａのリソースを利用することができる。

　また、本実施例では、第二の計算機システム４０ｂは、アプリケーションを構築するときにそのアプリケーションに含まれる所定のジョブを第一の計算機システム４０ａに投入する。

　これによれば、第二の計算機システム４０ｂにアプリケーションを構築する際に、そのアプリケーションに含まれる、スケールアウト型基盤に好適な処理を実現するジョブを第一の計算機システム４０ａに割り当てるので、アプリケーションの各ジョブをその性質にあった計算機システムで実行し、アプリケーション全体として効率よく実行することが可能となる。例えば、主たる処理は信頼性あるいは処理速度が求められるようなアプリケーションの一部にアクセスログや非構造化データを分析するような大規模な処理が含まれているような場合に好適な構成を提供することができる。

　また、本実施例では、第二の計算機システム４０ｂは、Ｗｅｂアプリケーションの開発環境が構築されており、第一の計算機システム４０aは、そのＷｅｂアプリケーションのアプリケーションサーバが展開されている。第二の計算機システム４０ｂは、Ｗｅｂアプリケーションを実行したログを分析してボトルネックになっている処理ステップを抽出するというジョブを第一の計算機システム４０ａに投入する。第一の計算機システム４０ａがボトルネックの処理ステップを抽出して第二の計算機システム４０ａに送る。第二の計算機システム４０ｂがボトルネックの処理ステップを開発者に提示する。

　これによれば、Ｗｅｂアプリケーションが動作してログが生成される計算機システムであり、かつ、大規模な処理に適したスケールアウト型基盤である第一の計算機システム４０ａにて、Ｗｅｂアプリケーションのログを解析してボトルネットを抽出するので、Ｗｅｂアプリケーションの開発において、システム間のログデータの転送を抑制し、かつ、大規模な処理を好適な計算機システムでログ解析によるボトルネック抽出を実行することができる。

　また、本実施例では、第二の計算機システム４０ｂが第一の計算機システム４０aに投入するジョブは、Ｗｅｂアプリケーションのログに基づきそれぞれの処理ステップの所要時間を集計し、所要時間に基づきボトルネックとなっている処理ステップを抽出するというジョブである。これによれば、所要時間が長い処理ステップを抽出して開発者に提示できるので、Ｗｅｂアプリケーションの処理の中で所要時間の長い処理ステップを選んでそれらの改善を図ることができる。

　第一の計算機システム４０ａに展開されるアプリケーションサーバは、リソースの自動スケーリングを行う機能を備えたアプリケーションサーバであり、ユーザから要求される度合いが高くかつボトルネックになっている処理ステップを示す情報を第二の計算機システム４０ｂから開発者に提示する。

　これによれば、ユーザから要求される度合いが高く、かつ、所要時間の長い処理ステップを開発者に提示するので、開発者は比較的改善が期待される処理ステップを選んで効率よく改善を図ることができる。

　上述した実施例は、本発明の説明のための例示であり、本発明の範囲をそれらの実施例にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

１０…ノード、物理サーバ、分散処理ノード、１００…ストレージ装置、１０１…ボリューム、１０２…仮想ディスク、１０３…ボリューム、１０４…ＲＡＩＤグループ、１０５…ＨＤＤ、ストレージメディア、１０６…ストレージプール、１０７…仮想ボリューム、１０８…ＳＳＤ、バックアップボリューム、１１…クラスタ、１２…アプリケーション、１５０…共有ストレージコントローラ、１５１…ＣＰＵ、プロセッサ、１５２…メモリ、１５３ａ…応答プログラム、１５３ｂ…ストレージ制御プログラム、１５３ｃ…ストレージ構成管理テーブル、１５４…ＳＡＳ　ＩＦ、１５５…ＮＩＣ、１５６…データバス、２０…ホスト、２０…物理サーバ、２００…管理コンピュータ、２００ａ…管理コンピュータ、２００ｂ…管理コンピュータ、２０１…ＶＯＬ、２０１ａ…アプリケーション構成管理部Ａ、２０１ｂ…アプリケーション構成管理部Ｂ、２０２…タスク実行管理部、２０３…タスク管理テーブル、２０３ａ…ジョブＩＤ、２０３ｂ…タスクＩＤ、２０３ｃ…優先度フィールド、２０３ｄ…多重度、２０３ｅ…配置ノードＩＤフィールド、２０３ｆ…ディレクトリフィールド、２０３ｇ…属性、２０４…データ配置管理部、２０５ａ…データ連携制御部Ａ、２０５ｂ…データ連携制御部Ｂ、２０６…データ配置管理テーブル、２０６ａ…当該ディレクトリ、２０６ｂ…フラグ、２０６ｃ…マスタフラグ、２０６ｄ…状態、２０６ｅ…配置先デバイス、２０６ｆ…属性、２０７…リソース構成管理部、２０８…リソース構成管理テーブル、２０８ａ…インスタンスＩＤ、インスタンス識別子、２０８ｂ…種別、２０８ｃ…物理サーバＩＤ、物理サーバ識別子、２０８ｄ…利用状態、２０８ｅ…ターゲットＩＤ、２０８ｆ…ＬＵＮ、２０８ｇ…パーティション、２１…ＣＰＵ、２２…メモリ、２３…データバス、２４…ＰＣＩｅスイッチ、２５…ＮＩＣ、２５０…クライアントコンピュータ、２７…ディスクコントローラ、２９…フラッシュメモリ、３…ＬＵＮ、３０ａ…アプリケーション、３０ｂ…アプリケーション、３１…ハイパバイザ、３２…ＯＳ、３５…インスタンス、３６…分散ストレージコントローラ、ストレージコントローラ、３６ａ…ストレージコントローラ、分散ストレージコントローラ、３６ｂ…ストレージゲートウェイ、３６ｃ…ストレージアプライアンス、３７…内蔵ストレージ、４０ａ…スケールアウト型基盤、計算機システム、４０ｂ…スケールアップ型基盤、計算機システム、５０１…ボリューム、５０２…種別、５０３…容量、５０４…パス、５０５…接続先ＩＤ、５０６…メディア、５０ａ…ネットワーク、５０ｂ…ネットワーク、５０ｃ…ネットワーク、５１…ＨＢＡ、５５…ＳＡＮ、ネットワーク、６５…ＬＡＮ、ネットワーク、７００…ジョブ要求者、７３０…分散ファイルシステム、７３１…集約動作、７３２…ポート、７３３…データ転送
 

Claims (14)

1. 　リソースプールを構成する１つ以上の分散ストレージをそれぞれ有しジョブの並列分散処理を実行する１つ以上の分散処理計算機を有する第一の計算機システムと、
   　１つ以上の計算機が共有ストレージを共有し、前記第一の計算機システムと接続してデータを送受信する第二の計算機システムと、を有し、
   　前記第一の計算機システムが、前記ジョブを１つ以上のタスクに分割し、前記タスクでアクセスするデータの前記分散ストレージへの展開方法を決定し、前記データを前記第二の計算機システムに要求し、
   　前記第二の計算機システムが、前記データを前記第一の計算機システムに送信し、
   　前記第一の計算機システムが、受信した前記データを前記展開方法によって前記分散ストレージに展開する、
   複合計算機システム。
2. 　前記第二の計算機システムが、前記第一の計算機システムにおける第一の論理アドレスと前記第二の計算機システムにおける第二の論理アドレスとを対応づける管理情報を予め保持しており、
   　前記第一の計算機システムが、前記タスクでアクセスされるデータの第一の論理アドレスを前記第二の計算機システムに送信し、
   　前記第二の計算機システムが、受信した前記第一の論理アドレスと前記管理情報に基づいて、前記データの第二の論理アドレスを特定し、前記第二の論理アドレスを用いて前記データを取得して前記第一の計算機システムに送信する、
   請求項１に記載の複合計算機システム。
3. 　前記第一の計算機システムは、前記タスクの実行要求が発生したとき、前記データの前記展開方法の計算を開始する前に、前記第二の計算機システムにデータを送信する準備を要求し、
   　前記第二の計算機システムは、前記準備の要求を受けると、前記データの送信を準備して前記第一の計算機システムからの前記データの送信の要求を待ちうける、
   請求項１に記載の複合計算機システム。
4. 　前記第一の計算機システムは、前記タスクでアクセスされる前記データを、前記タスクを実行する分散処理計算機の近傍にある分散ストレージに配置するように、前記展開方法を決定する、請求項１に記載の複合計算機システム。
5. 　前記第一の計算機システムは、前記タスクでアクセスされる前記データを、前記タスクを実行する分散処理計算機が有する分散ストレージに配置するように、前記展開方法を決定する、請求項４記載の複合計算機システム。
6. 　前記第一の計算機システムは、１つ以上の前記分散ストレージに負荷を分散するように前記展開方法を決定する、請求項１に記載の複合計算機システム。
7. 　前記ジョブが投入されると、前記第一の計算機システムは、前記タスクでアクセスされるデータの第一の論理アドレスを前記第二の計算機システムに送信し、前記第二の計算機システムが、受信した前記第一の論理アドレスに基づいて前記データの第二の論理アドレスを特定し、
   　前記タスクの実行要求が発生すると、前記第一の計算機システムは、前記タスクでアクセスするデータの前記分散ストレージへの前記展開方法を決定し、前記第二の計算機システムに前記データを要求し、前記第二の計算機システムは、前記第二の論理アドレスを用いて前記データを取得して前記第一の計算機システムに送信し、前記第一の計算機システムは、前記第二の計算機システムから送信された前記データを前記展開方法によって前記分散ストレージに展開し、前記タスクを実行する、
   請求項１に記載の複合計算機システム。
8. 　第一の計算機システムと第二の計算機システムが接続し、前記第二の計算機システムは１つ以上の計算機が共有ストレージを共有し、前記第一の計算機システムは前記第二の計算機システムと連携してジョブを実行する複合計算機システムの前記第一の計算機システムにおいて、リソースプールを構成する１つ以上の分散ストレージをそれぞれ有し、前記ジョブの並列分散処理を実行する１つ以上の分散処理計算機を管理する管理計算機であって、
   　ソフトウェアプログラムを記憶するメモリと、
   　前記メモリのソフトウェアプログラムを実行するＣＰＵとを有し、
   　前記ソフトウェアプログラムには、
   　前記ジョブを１つ以上のタスクに分割するタスク実行管理モジュールと、
   　前記タスクでアクセスするデータの前記分散ストレージへの展開方法を決定するデータ連携制御モジュールと、
   　前記分散処理計算機に対して、前記展開方法で前記データを前記分散ストレージに展開するように指示するデータ配置管理モジュールと、
   が含まれる管理計算機。
9. 　前記データ連携制御モジュールは、前記タスクの実行要求が発生したとき、前記データの前記展開方法の計算を開始する前に、前記第二の計算機システムにデータを送信する準備を要求する、
   請求項８に記載の管理計算機。
10. 　前記データ連携制御モジュールは、前記タスクでアクセスされる前記データを、前記タスクを実行する分散処理計算機の近傍にある分散ストレージに配置するように、前記展開方法を決定する、請求項８に記載の管理計算機。
11. 　前記データ連携制御モジュールは、前記タスクでアクセスされる前記データを、前記タスクを実行する分散処理計算機が有する分散ストレージに配置するように、前記展開方法を決定する、請求項１０に記載の管理計算機。
12. 　前記データ連携制御モジュールは、１つ以上の前記分散ストレージに負荷を分散するように前記展開方法を決定する、請求項８に記載の管理計算機。
13. 　前記データ連携制御モジュールは、
    　前記ジョブが投入されると、前記タスクでアクセスされるデータの第一の論理アドレスを前記第二の計算機システムに送信し、前記第一の論理アドレスに基づいて前記データの第二の論理アドレスを特定させ、
    　前記タスクの実行要求が発生すると、前記タスクでアクセスするデータの前記分散ストレージへの前記展開方法を決定し、
    　前記データ配置管理モジュールが、
    　前記第二の計算機システムに前記データを要求して、前記第二の論理アドレスを用いて前記データを取得させて前記分散処理計算機に送信させる、
    請求項８に記載の管理計算機。
14. 　リソースプールを構成する複数の分散ストレージと該分散ストレージを制御する分散ストレージコントローラをそれぞれ有しジョブの並列分散処理を実行する複数の分散処理ノードと、タスク実行管理モジュールと第一のデータ連携制御モジュールとデータ配置管理モジュールとを含むソフトウェアプログラムを実行する第一の管理計算機と、を有する第一の計算機システムと、
    　共有ストレージコントローラを有する共有ストレージと、前記共有ストレージを共有して利用し処理を実行する複数の物理サーバと、第二のデータ連携制御モジュールとリソース構成管理モジュールとを含むソフトウェアプログラムを実行する第二の管理計算機と、を有する第二の計算機システムと、を有し、
    （１）アクセスするデータを特定するとき、
    　前記第一の計算機システムにおいて、
    　ジョブが投入されると、前記アプリケーション構成管理モジュールが前記タスク実行管理モジュールに前記ジョブの実行要求を送信し、
    　前記ジョブの実行要求を受信した前記タスク実行管理モジュールが、前記ジョブを複数のタスクに分割し、
    　前記データ連携制御モジュールが、定期的に、前記アプリケーション構成管理モジュールに新たなジョブが投入されているかどうか確認し、新たなジョブが投入されていれば該ジョブに対応したタスクのアクセスするディレクトリを含むタスク実行情報を前記タスク実行管理モジュールから取得し、該ディレクトリが存在するデバイスの情報を前記データ配置管理モジュールから取得し、前記ディレクトリが外部にあるのであれば、前記第一の計算機システムで付与された前記ディレクトリが配置されているデバイスへのアクセス情報を含む前記タスク実行情報を前記第二の計算機システムに送信し、
    　前記第二の計算機システムにおいて、
    　前記第二のデータ連携制御モジュールが前記タスク実行情報を受信すると、前記リソース構成管理モジュールから、前記第一の計算機システムでの前記アクセス情報に対応する前記第二の計算機システムでのアクセス情報を取得し、前記共有ストレージコントローラに問い合わせて、前記データを格納した前記共有ストレージの領域を特定し、
    （２）アクセスするデータを展開するとき、
    　前記第一の計算機システムにおいて、
    　前記第一のデータ連携制御モジュールが、タスク実行情報を前記データ配置管理モジュールから取得し、該タスク実行情報に基づき、タスクがアクセスするデータの転送を前記第二のデータ連携制御モジュールに対して要求し、前記データのロード先の情報を前記データ配置管理モジュールから取得し、
    　前記第二の計算機システムにおいて、
    　前記データの転送を要求された前記第二のデータ連携制御モジュールが、前記リソース構成管理モジュールに前記データに該当するボリュームをロックさせ、前記共有ストレージコントローラに前記データの転送を指示し、
    　前記データの転送を指示された前記共有ストレージコントローラが前記データを転送する準備を行い、
    　前記第一の計算機システムにおいて、
    　前記第一のデータ連携制御モジュールが、前記データのロード先の情報に基づき前記データの展開方法を計算し、前記データの取得と前記展開方法による前記ロード先への展開を前記データ配置管理モジュールに指示し、
    　前記データ配置管理モジュールが、前記ロード先の分散ストレージを制御する分散ストレージコントローラに前記データの取得および展開を指示し、
    　前記分散ストレージコントローラが前記共有ストレージコントローラから前記データを取得して展開し、
    　前記第二の計算機システムにおいて、
    　前記データを前記分散ストレージコントローラに与えた前記共有ストレージコントローラが転送完了を前記第二のデータ連携制御モジュールに通知し、
    　前記第二のデータ連携制御モジュールが前記ロックを解除し、前記第一のデータ連携制御モジュールに転送完了を通知する、
    複合計算機システム。
     

Images