特開 2023-102641 計算機システム及びスケールアップ管理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023102641

(43)【公開日】2023-07-25

(54)【発明の名称】計算機システム及びスケールアップ管理方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20230718BHJP

   G06F 16/28 20190101ALI20230718BHJP

【ＦＩ】

G06F9/50 120Z

G06F16/28

【審査請求】未請求

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2022003260

(22)【出願日】2022-01-12

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110000279

【氏名又は名称】弁理士法人ウィルフォート国際特許事務所

(72)【発明者】

【氏名】山内 脩吾

(72)【発明者】

【氏名】早坂 光雄

(72)【発明者】

【氏名】深谷 崇元

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175AA01

5B175AA02

5B175KA04

(57)【要約】

【課題】アプリケーションを実行するサーバを容易且つ迅速にスケールアップすることができるようにする。
【解決手段】一のアプリケーションを実行するアプリコンテナ５０を有する１以上のコンピュートサーバ２０と、コンピュートサーバ２０を管理する管理サーバ１３０とを有する計算機システム１において、管理サーバ１３０を、一のアプリケーションを実行するアプリコンテナ５０を有するコンピュートサーバ２０の台数を増加させる場合に、既存のコンピュートサーバ２０のアプリコンテナ５０がアプリケーションを実行する際に利用しているファイルが格納されているＬＵ９０を特定し、新たなコンピュートサーバ２０のアプリコンテナ５０がアプリケーションを実行する場合に、特定されたＬＵ９０を参照するように新たなコンピュートサーバ２０に設定するように構成する。
【選択図】図１

【特許請求の範囲】

【請求項1】

一のアプリケーションを実行する実行部を有する１以上のコンピュートサーバと、前記コンピュートサーバを管理する管理サーバとを有する計算機システムであって、
前記管理サーバは、
前記一のアプリケーションを実行する実行部を有するコンピュートサーバの台数を増加させる場合に、既存のコンピュートサーバの前記実行部がアプリケーションを実行する際に利用しているデータ単位が格納されている論理ユニットを特定し、
新たな前記コンピュートサーバの前記実行部が前記アプリケーションを実行する場合に、特定された前記論理ユニットを参照するように前記新たなコンピュートサーバに設定する
計算機システム。

【請求項2】

前記計算機システムにおいては、前記実行部が利用する前記データ単位を格納する論理ユニットが所定のアルゴリズムに従って決定されており、
前記管理サーバは、
前記所定のアルゴリズムに従って、前記実行部が利用する前記データ単位を格納している論理ユニットを特定する
請求項１に記載の計算機システム。

【請求項3】

前記所定のアルゴリズムは、格納する論理ユニットを、前記データ単位の名称を含む情報に関するハッシュ値に基づいて決定するアルゴリズムである
請求項２に記載の計算機システム。

【請求項4】

前記管理サーバは、
前記一のアプリケーションを実行する実行部を有するコンピュートサーバの台数の増加が必要であるか否かを判定し、
前記コンピュートサーバの台数の増加が必要であると判定した場合に、前記実行部を有していないサーバに、前記実行部を作成する制御を行う
請求項１に記載の計算機システム。

【請求項5】

前記実行部は、前記コンピュートサーバのＯＳ上に構成されるコンテナである
請求項１に記載の計算機システム。

【請求項6】

前記管理サーバは、
１つのブロックデバイスに対して複数の論理ユニットを割り当てて、前記論理ユニットのデータ容量が所定量以下となるように前記論理ユニットを生成する
請求項１に記載の計算機システム。

【請求項7】

前記管理サーバは、
前記一のアプリケーションを実行する実行部を有するコンピュートサーバのリソースの負荷情報又は性能情報の少なくとも一方を出力する
請求項１に記載の計算機システム。

【請求項8】

前記管理サーバは、
前記一のアプリケーションを実行する実行部を有するコンピュートサーバの台数を増加させる前の前記実行部を有する全てのコンピュートサーバの性能と、台数を増加させた後の前記実行部を有する全てのコンピュートサーバの性能とを示す情報を出力する
請求項１に記載の計算機システム。

【請求項9】

一のアプリケーションを実行する実行部を有する１以上のコンピュートサーバと、前記コンピュートサーバを管理する管理サーバと、を有する計算機システムによるスケールアップ管理方法であって、
前記管理サーバは、
前記一のアプリケーションを実行する実行部を有するコンピュートサーバの台数を増加させる場合に、既存のコンピュートサーバの前記実行部がアプリケーションを実行する際に利用しているデータ単位が格納されている論理ユニットを特定し、
新たな前記コンピュートサーバの前記実行部が前記アプリケーションを実行する場合に、特定された前記論理ユニットを参照するように前記新たなコンピュートサーバに設定する
スケールアップ管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、同一のアプリケーションを実行するコンピュートサーバをスケールアップする技術に関する。

【背景技術】

【0002】

脱炭素社会の実現に向け、システムの省電力化が求められている。そのため、不必要なサーバを休止し、負荷が増えたらサーバを再稼働させるなどの要望がある。また、パブリッククラウドでは必要以上にＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）を稼働させるとコストが増大してしまう。そのため、負荷に応じてコンピュートサーバ／ストレージサーバをそれぞれ必要十分、かつ少ないサーバ台数で動作させたいという要望がある。

【0003】

例えば、アプリケーション（アプリと略する場合もある）の実行環境をまとめて個別のサーバのように使うことができるようにしたコンテナを、コンテナオーケストレータにより運用管理をして、コンテナでアプリを動作させている場合における性能／リソース不足を契機に、アプリケーションコンテナ（アプリコンテナ）が使用するサーバ数の増減を実施するオートスケール技術が知られている（特許文献１参照）。この技術によると、アプリの稼働サーバを減らし、休止させることで、省電力化が可能となる。

【0004】

また、オートスケーリングの際、増減したノードのリソースを有効に利用するため、複数ノード間で分散してファイルを保存する分散ファイルシステムが、ファイルデータの配置を再計算して、ファイルデータをサーバ間で移動するリバランスを実施する技術が知られている（特許文献２参照）。オートスケーリングとリバランスとを組み合わせることで、負荷変動に応じたコンピュートサーバ／ストレージサーバのオートスケールを実現することができる。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】米国特許第１０９７９４３６号明細書

【特許文献1】米国特許出願公開第２０１６０３４９９９３号明細書

【発明の概要】

【発明が解決しようとする課題】

【0006】

例えば、負荷変動に応じてオートスケールを行う際、データ移動／複製が多発することによりシステムの性能低下が発生する。また、コンテナ上で動作するアプリに必要なファイルは、オートスケールしたコンテナ毎にファイルに保持する必要があり、特に、ファイルのサイズが大きい場合には、そのファイルのデータを複製するための負荷が大きい問題が生じる。

【0007】

本発明は、上記事情に鑑みなされたものであり、その目的は、アプリケーションを実行するサーバを容易且つ迅速にスケールアップすることのできる技術を提供することにある。

【課題を解決するための手段】

【0008】

上記目的を達成するため、一観点に係る計算機システムは、一のアプリケーションを実行する実行部を有する１以上のコンピュートサーバと、前記コンピュートサーバを管理する管理サーバとを有する計算機システムであって、前記管理サーバは、前記一のアプリケーションを実行する実行部を有するコンピュートサーバの台数を増加させる場合に、既存のコンピュートサーバの前記実行部がアプリケーションを実行する際に利用しているデータ単位が格納されている論理ユニットを特定し、新たな前記コンピュートサーバの前記実行部が前記アプリケーションを実行する場合に、特定された前記論理ユニットを参照するように前記新たなコンピュートサーバに設定する。

【発明の効果】

【0009】

本発明によれば、アプリケーションを実行するサーバを容易且つ迅速にスケールアップすることができる。

【図面の簡単な説明】

【0010】

【図1】図１は、第１実施形態の概要を説明する図である。

【図2】図２は、第１実施形態に係る計算機システムの構成図である。

【図3】図３は、第１実施形態に係るコンピュートサーバの構成図である。

【図4】図４は、第１実施形態に係るストレージサーバの構成図である。

【図5】図５は、第１実施形態に係る管理サーバの構成図である。

【図6】図６は、第１実施形態に係るクライアントサーバの構成図である。

【図7】図７は、第１実施形態に係るアプリコンテナファイルパス対応テーブルの構成図である。

【図8】図８は、第１実施形態に係る分散ボリューム管理テーブルの構成図である。

【図9】図９は、第１実施形態に係るサーバ管理テーブルの構成図である。

【図10】図１０は、第１実施形態に係るアプリコンテナ配置テーブルの構成図である。

【図11】図１１は、第１実施形態に係るスケールアウト処理のフローチャートである。

【図12】図１２は、第１実施形態に係る参照ＬＵ特定処理のフローチャートである。

【図13】図１３は、第１実施形態に係るファイル高速複製処理のフローチャートである。

【図14】図１４は、第１実施形態に係る分散ボリューム作成処理のフローチャートである。

【図15】図１５は、第１実施形態に係る分散処理アプリ管理画面の構成図である。

【図16】図１６は、第２実施形態の概要を説明する図である。

【図17】図１７は、第２実施形態に係るコンピュートサーバの構成図である。

【図18】図１８は、第２実施形態に係るストレージサーバの構成図である。

【図19】図１９は、第２実施形態に係る参照ＬＵ特定処理のフローチャートである。

【図20】図２０は、第２実施形態に係るファイル高速複製処理のフローチャートである。

【図21】図２１は、第２実施形態に係る分散ボリューム作成処理のフローチャートである。

【発明を実施するための形態】

【0011】

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

【0012】

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

【0013】

また、以下の説明では、「ネットワークＩ／Ｆ」は、１以上の通信インターフェースデバイスを含んでよい。１以上の通信インターフェースデバイスは、１以上の同種の通信インターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

【0014】

また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部または一部が１つのテーブルであってもよい。

【0015】

また、以下の説明では、記憶装置は、物理的な不揮発性の記憶デバイス（例えば補助記憶デバイス）であり、例えばＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、ＳＣＭ（Storage Class Memory）であってもよい。

【0016】

また、以下の説明では、メモリは、揮発性メモリであってもよいし、不揮発性メモリであってもよい。

【0017】

また、以下の説明では、「プログラム」を動作主体として処理を説明する場合があるが、プログラムは、プロセッサ（例えば、ＣＰＵ）によって実行されることで、定められた処理を、適宜に記憶部及びインターフェース部のうちの少なくとも１つを用いながら行うため、処理の動作主体が、プロセッサ（或いは、プロセッサを有する計算機）とされてもよい。プログラムは、プログラムソースから計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記録メディアであってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

【0018】

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

【0019】

また、以下の説明では、分散ボリュームは、１以上の物理的な計算機（ノード）で構成されてもよく、さらにストレージアレイを含んでもよい。少なくとも１つの物理的な計算機が、仮想的な計算機（例えばＶＭ（Virtual Machine））を構成してもよいし、ＳＤｘ（Software-Defined anything）を構成してもよい。ＳＤｘとしては、例えば、ＳＤＳ（Software Defined Storage）（仮想的なストレージ装置の一例）またはＳＤＤＣ（Software-defined Datacenter）であってもよい。

【0020】

まず、第１実施形態の概要について説明する。

【0021】

図１は、第１実施形態の概要を説明する図である。図１は、計算機システム１において、アプリコンテナ５０のオートスケール方法の概要を説明する図である。

【0022】

計算機システム１においては、クライアントサーバ１０と、複数（図では、４つ）のコンピュートサーバ２０（コンピュートサーバＡ～Ｄ）と、共有ブロックストレージ３０と、管理サーバ１３０とを有する。

【0023】

共有ブロックストレージ３０は、例えば、複数のストレージサーバ１２０（図２参照）により構成される。

【0024】

管理サーバ１３０は、コンテナオーケストレータ管理部１３１を有する。コンテナオーケストレータ管理部１３１は、各コンピュートサーバ２０のコンテナオーケストレータ６０を管理する。

【0025】

クライアントサーバ１０は、アプリクライアント４０を有する。アプリクライアント４０は、後述する複数のアプリコンテナ５０に対して処理対象のデータを割り振って、各アプリコンテナ５０により、分散処理を実行させる。

【0026】

コンピュートサーバ２０は、コンテナオーケストレータ６０と、分散ファイルシステム（分散ＦＳ）８０と、データＬＵ対応管理部１００とを有する。ここで、オートスケールを実行する前においては、３台のコンピュートサーバ２０（コンピュートサーバＡ～Ｃ）が、同一のアプリケーション（アプリともいう）を実行するアプリコンテナ（実行部の一例）５０を有し、コンピュートサーバ２０（コンピュートサーバＤ）は、同一のアプリケーションを実行するアプリコンテナ５０を有していない。

【0027】

アプリコンテナ５０は、アプリケーションを実行して、アプリクライアント４０から割り振られたデータに対して処理を実行するコンテナである。ここで、コンテナとは、計算機（サーバ）のＯＳ（Operating System）上においてアプリケーションの実行環境をまとめて個別のサーバのように使うことができるようにしたものである。コンテナオーケストレータ６０は、アプリコンテナ５０等のコンテナを管理する。分散ファイルシステム８０は、ネットワーク１１０を介して接続されている共有ブロックストレージ３０の記憶装置の記憶領域に作成された複数のＬＵ（Logical Unit:論理ユニット）９０を用いて、複数のコンピュートサーバ２０上に跨る分散ボリューム７０を作成する。分散ファイルシステム８０は、共有ブロックストレージ３０の記憶装置の記憶領域に複数のＬＵを作成することができる。各コンピュートサーバ２０は、分散ボリューム７０上のデータ格納領域にアプリコンテナ５０が利用するファイル（データ単位の一例）を格納する。データＬＵ対応管理部１００は、アプリコンテナ５０が使用するファイルが格納されるＬＵ９０を管理する。

【0028】

計算機システム１において、コンテナオーケストレータ６０は、コンピュートサーバ２０のリソースを監視し、コンテナオーケストレータ管理部１３１は、例えば、コンピュートサーバ２０のＣＰＵリソースが逼迫していることを検出した場合には、アプリコンテナ５０のオートスケールを実施する。具体的には、コンテナオーケストレータ管理部１３１は、コンピュートサーバ２０（図１では、コンピュートサーバＤ）に新たにアプリコンテナ５０を追加する。これにより、各アプリコンテナ５０の負荷が分散されることとなる。

【0029】

このオートスケールを行う際に、計算機システム１においては、追加したアプリコンテナ５０が使用するファイルについて、コンテナオーケストレータ管理部１３１は、既にアプリコンテナ５０が使用するために格納されているＬＵ９０を特定する。次いで、追加したアプリコンテナ５０を有するコンピュートサーバ２０を、共有ブロックストレージ３０上の特定したＬＵ９０に、例えば、リードオンリーで接続させる。これにより、追加したアプリコンテナ５０は、そのＬＵ９０のデータをデータコピーすることなく使用することができるようになり、高速にファイルレプリケーション（ファイル複製）を実現することができる。

【0030】

次に、第１実施形態に係る計算機システム１について詳細に説明する。

【0031】

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

【0032】

計算機システム１は、クライアントサーバ１０と、１以上のコンピュートサーバ２０と、共有ブロックストレージ３０と、管理サーバ１３０とを備える。共有ブロックストレージ３０は、１以上のストレージサーバ１２０を備える。

【0033】

クライアントサーバ１０と、コンピュートサーバ２０と、ストレージサーバ１２０と、管理サーバ１３０とは、ネットワーク１１０を介して接続されている。ネットワーク１１０は、例えば、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）等であってよい。

【0034】

クライアントサーバ１０は、所定の処理の実行を行うユーザが使用するサーバであり、複数のコンピュートサーバ２０に対して処理を分散して実行させる。コンピュートサーバ２０は、処理を実行するためのアプリケーションを実行するサーバである。ストレージサーバ１２０は、ブロックストレージとしての役割を持つサーバである。管理サーバ１３０は、コンピュートサーバ２０及びストレージサーバ１２０を管理するサーバである。

【0035】

次に、コンピュートサーバ２０について説明する。

【0036】

図３は、第１実施形態に係るコンピュートサーバの構成図である。

【0037】

コンピュートサーバ２０は、プロセッサの一例としてのＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース（Network I/F）１７０と、記憶装置１４０と、ＢＭＣ（Baseboard Management Controller）１９０とを有する。ＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース１７０と、記憶装置１４０とは、内部バス１８０を介して接続されている。

【0038】

ネットワークインターフェース１７０は、例えば、有線ＬＡＮカードや無線ＬＡＮカードなどのインターフェースであり、ネットワーク１１０を介して他の装置（例えば、クライアントサーバ１０、他のコンピュートサーバ２０、ストレージサーバ１２０、管理サーバ１３０）と通信する。

【0039】

ＣＰＵ１６０は、メモリ１５０及び／又は記憶装置１４０に格納されているプログラムに従って各種処理を実行する。

【0040】

記憶装置１４０は、各種データを記憶する不揮発性記憶媒体であり、ＨＤＤ、ＳＳＤ、ＳＣＭであってもよい。

【0041】

ＢＭＣ１９０は、収容する装置（ここでは、コンピュートサーバ２０）に対する外部からの電源制御を可能にするデバイスである。ＢＭＣ１９０は、ＣＰＵ１６０及びメモリ１５０と独立して動作し、ＣＰＵ１６０やメモリ１５０に障害が発生した場合でも、外部からの電源制御要求を受け付けて装置の電源制御（電源のオン及びオフ）を行うことができる。

【0042】

メモリ１５０は、例えば、ＲＡＭ（Random Access Memory）であり、ＣＰＵ１６０で実行されるプログラムや、必要な情報を記憶する。メモリ１５０は、分散ＦＳ制御プログラムＰ１０と、分散ＦＳクライアントプログラムＰ２０と、コンテナオーケストレータプログラムＰ３０と、連携プログラムＰ４０と、アプリコンテナプログラムＰ５０と、アプリコンテナ使用ファイルＦ１０と、ファイルＬＵ対応管理プログラムＰ６０と、アプリコンテナファイルパス対応テーブルＴ４０と、ストレージ接続プログラムＰ７０と、ファイルシステム情報Ｔ５０と、を記憶する。なお、図示していないが、メモリ１５０には、ＯＳ等のサーバとして機能するために必要なプログラムも記憶する。

【0043】

分散ＦＳ制御プログラムＰ１０は、他のコンピュートサーバ２０と協調し、分散ボリューム７０を構成し、制御するプログラムである。分散ＦＳ制御プログラムＰ１０は、コンピュートサーバ２０が分散ボリューム７０に格納するファイルをストレージサーバ１２０のＬＵ９０に格納する処理を行う。分散ＦＳ制御プログラムＰ１０をＣＰＵ１６０が実行することにより、分散ファイルシステム８０が構成される。

【0044】

分散ＦＳクライアントプログラムＰ２０は、コンピュートサーバ２０内の他のプログラムによる分散ボリューム７０へのアクセスの処理を行う。

【0045】

コンテナオーケストレータプログラムＰ３０は、コンピュートサーバ２０でのコンテナ（アプリコンテナ５０等）の起動や運用管理を行う。本実施形態では、コンテナオーケストレータプログラムＰ３０は、コンピュートサーバ２０内で動く全てのプログラムをコンテナとして管理する。コンテナオーケストレータプログラムＰ３０をＣＰＵ１６０が実行することにより、コンテナオーケストレータ６０が構成される。

【0046】

連携プログラムＰ４０は、コンテナオーケストレータプログラムＰ３０によって管理されるコンピュートサーバ２０内のプログラムが分散ボリューム７０にアクセスすることを可能とするプログラムである。連携プログラムＰ４０は、コンテナオーケストレータプログラムＰ３０によって管理されているプログラムのコンテナから記憶領域を利用する要求を受け取ると、分散ボリューム７０から記憶領域を提供する処理を実行する。

【0047】

アプリコンテナプログラムＰ５０は、クライアントサーバ１０で実行されているアプリクライアント４０から与えられたデータを利用して処理を実施するプログラムである。アプリコンテナプログラムＰ５０は、実行に必要なファイルに基づいて、与えられたデータに対して処理を実行し、アプリクライアント４０に結果を返す。アプリコンテナプログラムＰ５０をＣＰＵ１６０が実行することにより、アプリコンテナ５０が構成される。

【0048】

アプリコンテナ使用ファイルＦ１０は、アプリコンテナ５０の実行に必要なファイルである。アプリコンテナ使用ファイルＦ１０は、例えば、分散ボリューム７０から読み出される。

【0049】

ファイルＬＵ対応管理プログラムＰ６０は、ファイルが配置されているＬＵを特定するプログラムである。ファイルＬＵ対応管理プログラムＰ６０は、アプリコンテナ５０の増設時に、アプリコンテナファイルパス対応テーブルＴ４０を参照してアプリコンテナ５０のデータ格納領域のファイルパスを特定し、特定したファイルパスから必要なファイルを特定し、ファイルが配置されるＬＵを決定する分散ＦＳ制御プログラムＰ１０のファイル配置アルゴリズムに基づいて、ファイルが配置されているＬＵを特定する。ファイル配置アルゴリズムは、例えば、データが格納されるファイルの識別子（ファイルの名称）と、ファイルにおけるデータのオフセットとに基づいてハッシュ値を算出し、ハッシュ値に基づいてデータ格納するＬＵを決定するアルゴリズムでもよい。なお、ファイルＬＵ対応管理プログラムＰ６０は、アルゴリズムに基づいてＬＵを特定するようにしているが、これに限られず、例えば、ファイルとＬＵとの対応関係を格納するテーブルを管理し、このテーブルに基づいてＬＵを特定するようにしてもよい。ファイルＬＵ対応管理プログラムＰ６０をＣＰＵ１６０が実行することにより、データＬＵ対応管理部１００が構成される。

【0050】

ストレージ接続プログラムＰ７０は、コンピュートサーバ２０を共有ブロックストレージ３０のＬＵに接続する処理を行う。

【0051】

アプリコンテナファイルパス対応テーブルＴ４０は、アプリコンテナで使用するファイルパスを管理する。

【0052】

ファイルシステム情報Ｔ５０は、分散ＦＳにおけるディレクトリと、ファイルとの構成情報を格納する。

【0053】

次に、ストレージサーバ１２０について説明する。

【0054】

図４は、第１実施形態に係るストレージサーバの構成図である。

【0055】

ストレージサーバ１２０は、プロセッサの一例としてのＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース１７０と、１以上のストレージインターフェース（Storage I/F）２００と、複数の記憶装置１４０（ブロックデバイスの一例）と、ＢＭＣ１９０とを有する。ＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース１７０と、ストレージインターフェース２００とは、内部バス１８０を介して接続されている。

【0056】

ストレージインターフェース２００は、ＣＰＵ１６０と記憶装置１４０とを接続する。ＣＰＵ１６０は、ストレージインターフェース２００を介して記憶装置１４０に対するデータの読み書きを行うことができる。ＣＰＵ１６０とストレージインターフェース２００との間の通信には、ＦＣ（Fibre channel）、ＳＡＴＡ（Serial Attached Technology Attachment）、ＳＡＳ（Serial Attached SCSI）、ＩＤＥ（Integrated Device Electronics）などを用いることができる。

【0057】

ストレージサーバ１２０のメモリ１５０は、ＩＯ制御プログラムＰ８０と、ブロックストレージプログラムＰ９０とを記憶する。なお、図示していないが、メモリ１５０は、ＯＳ等のサーバとして機能するために必要なプログラムも記憶する。

【0058】

ＩＯ制御プログラムＰ８０は、ネットワーク１１０経由で受信したＬＵ９０に対するＩＯ要求に従って、記憶装置１４０に対するデータの読み書きを行う。ブロックストレージプログラムＰ９０は、他のストレージサーバ１２０と協調し、共有ブロックストレージ３０を構成して制御する。

【0059】

ストレージサーバ１２０の記憶装置１４０は、ストレージサーバ１２０で使用する各種プログラムに加え、コンピュートサーバ２０により格納されたユーザデータや制御情報を格納する。

【0060】

次に、管理サーバ１３０について説明する。

【0061】

図５は、第１実施形態に係る管理サーバの構成図である。

【0062】

管理サーバ１３０は、プロセッサの一例としてのＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース１７０と、記憶装置１４０とを有する。ＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース１７０と、記憶装置１４０とは、内部バス１８０を介して接続されている。管理サーバ１３０には、ディスプレイ２１０と、入力装置２２０とが接続されている。

【0063】

管理サーバ１３０のメモリ１５０は、管理プログラムＰ１００と、コンテナオーケストレータ管理プログラムＰ１１０と、分散ボリューム管理テーブルＴ１０と、サーバ管理テーブルＴ２０と、アプリコンテナ配置テーブルＴ３０とを記憶する。なお、図示していないが、メモリ１５０は、ＯＳ（Operating System）等のサーバとして機能するために必要なプログラムも記憶する。

【0064】

管理プログラムＰ１００は、管理者により入力された管理要求に従って、コンピュートサーバ２０、ストレージサーバ１２０に対して構成変更要求を発行する。管理要求は、例えば、サーバの増設、減設などの要求を含む。ストレージサーバ１２０への構成変更要求は、例えば、ＬＵ作成・削除・拡張・縮小、ＬＵパスの追加・削除・変更を含む。

【0065】

コンテナオーケストレータ管理プログラムＰ１１０は、コンピュートサーバ２０のコンテナオーケストレータ６０やストレージサーバ１２０に対し、アプリコンテナの作成、拡張、削除、起動、停止などの管理要求を発行する。コンテナオーケストレータ管理プログラムＰ１１０をＣＰＵ１６０が実行することにより、コンテナオーケストレータ管理部１３１が構成される。

【0066】

ディスプレイ２１０は、管理者がコンピュートサーバ２０及びストレージサーバ１２０を管理するための管理画面や、アプリケーションを管理する分散処理アプリ管理画面Ｉ１００（図１５参照）等の各種情報を表示出力する。入力装置２２０は、例えば、キーボード、マウス、タッチパネル等であり、管理者の操作入力を受け付ける。

【0067】

次に、クライアントサーバ１０について説明する。

【0068】

図６は、第１実施形態に係るクライアントサーバの構成図である。

【0069】

クライアントサーバ１０は、プロセッサの一例としてのＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース１７０と、記憶装置１４０とを有する。ＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース１７０と、記憶装置１４０とは、内部バス１８０を介して接続されている。

【0070】

クライアントサーバ１０のメモリ１５０は、アプリデータ配布プログラムＰ１２０と、コンテナオーケストレータプログラムＰ１３０とを記憶する。なお、図示していないがメモリ１５０には、ＯＳ等のサーバとして機能するために必要なプログラムも記憶する。

【0071】

アプリデータ配布プログラムＰ１２０は、コンピュートサーバ２０のアプリコンテナプログラムＰ５０にネットワーク１１０を経由して処理に必要なデータを送信し、処理の結果を受信する。この際、アプリデータ配布プログラムＰ１２０は、コンテナオーケストレータプログラムＰ１３０により管理サーバ１３０のアプリコンテナ配置テーブルＴ３０の情報を取得し、アプリコンテナ配置テーブルＴ３０の情報を参照して、処理を実行するアプリケーションを実行可能なアプリコンテナ５０を有する１以上のコンピュートサーバ２０を特定し、特定したコンピュートサーバ２０にデータを分散して配布する。

【0072】

コンテナオーケストレータプログラムＰ１３０は、アプリデータ配布プログラムＰ１２０の指示に従って、管理サーバ１３０のアプリコンテナ配置テーブルＴ３０の情報を取得する。

【0073】

次に、アプリコンテナファイルパス対応テーブルＴ４０について説明する。

【0074】

図７は、第１実施形態に係るアプリコンテナファイルパス対応テーブルの構成図である。

【0075】

アプリコンテナファイルパス対応テーブルＴ４０は、アプリコンテナで使用するファイルパスを管理する。アプリコンテナファイルパス対応テーブルＴ４０は、アプリケーションごとのエントリを格納しており、同一のアプリケーションを分散して実行する複数のアプリコンテナに対しては、同一のエントリが対応する。アプリコンテナファイルパス対応テーブルＴ４０のエントリは、アプリ名Ｃ２０１と、ファイルパスＣ２０２とのフィールドを含む。アプリ名Ｃ２０１には、エントリに対応するアプリケーションの名称（アプリ名）が格納される。ファイルパスＣ２０２には、エントリに対応するアプリケーションにおける分散ファイルシステムにおけるファイルパスが格納される。

【0076】

本実施形態では、アプリコンテナファイルパス対応テーブルＴ４０のアプリ名Ｃ２０１、ファイルパスＣ２０２には、連携プログラムＰ４０がアプリコンテナとそれに対応する分散ボリューム上のデータ格納領域を作成した際に、連携プログラムＰ４０により値が格納される。

【0077】

次に、分散ボリューム管理テーブルＴ１０について説明する。

【0078】

図８は、第１実施形態に係る分散ボリューム管理テーブルの構成図である。

【0079】

分散ボリューム管理テーブルＴ１０は、分散ボリュームの情報を管理する。分散ボリューム管理テーブルＴ１０は、分散ボリュームに対応するエントリを格納する。分散ボリューム管理テーブルＴ１０のエントリは、分散ＶｏｌＩＤ Ｃ１０１と、サーバＩＤ Ｃ１０２と、マウントポイントＣ１０３とのフィールドを含む。

【0080】

分散ＶｏｌＩＤ Ｃ１０１には、エントリに対応する分散ボリュームの識別情報（分散ボリュームＩＤ）が格納される。サーバＩＤ Ｃ１０２には、エントリに対応する分散ボリュームの記憶領域を構成するストレージサーバ１２０のＩＤ（サーバＩＤ）が格納される。マウントポイントＣ１０３には、エントリに対応する分散ボリュームがマウントされているポイント（マウントポイント）が格納される。

【0081】

分散ボリューム管理テーブルＴ１０の分散ＶｏｌＩＤ Ｃ１０１、サーバＩＤ Ｃ１０２、マウントポイントＣ１０３には、分散ボリューム作成時にコンテナオーケストレータプログラムＰ３０が分散ＦＳ制御プログラムＰ１０に指示して値が格納される。

【0082】

次に、サーバ管理テーブルＴ２０について説明する。

【0083】

図９は、第１実施形態に係るサーバ管理テーブルの構成図である。

【0084】

サーバ管理テーブルＴ２０は、サーバ（コンピュートサーバ２０、ストレージサーバ１２０）の情報を管理する。サーバ管理テーブルＴ２０は、サーバごとのエントリを格納する。サーバ管理テーブルＴ２０のエントリは、サーバＩＤ Ｃ３０１と、役割Ｃ３０２と、ＩＰアドレスＣ３０３と、ＢＭＣアドレスＣ３０４と、ＭＴＴＦ Ｃ３０５と、起動時間Ｃ３０６とのフィールドを含む。サーバＩＤ Ｃ３０１には、エントリに対応するサーバのＩＤが格納される。役割Ｃ３０２には、エントリに対応するサーバの役割、コンピュートサーバか、又はストレージサーバかを示す情報が格納される。ＩＰアドレスＣ３０３には、エントリに対応するサーバのＩＰアドレスが格納される。ＢＭＣアドレスＣ３０４には、エントリに対応するサーバのＢＭＣ１９０のＩＰアドレス（ＢＭＣアドレス）が格納される。ＭＴＴＦ Ｃ３０５には、エントリに対応するサーバのＭＴＴＦ（Mean Time To Failure：平均故障時間）が格納される。起動時間Ｃ３０６には、エントリに対応するサーバの起動時間が格納される。

【0085】

サーバ管理テーブルＴ２０のエントリ及びその値は、サーバを増減した際に、管理プログラムＰ１００によって格納される。

【0086】

次に、アプリコンテナ配置テーブルＴ３０について説明する。

【0087】

図１０は、第１実施形態に係るアプリコンテナ配置テーブルの構成図である。

【0088】

アプリコンテナ配置テーブルＴ３０は、アプリコンテナ５０のコンピュートサーバ２０への配置の情報を管理する。アプリコンテナ配置テーブルＴ３０は、アプリコンテナ５０を構成するアプリケーションに対応するエントリ含む。アプリコンテナ配置テーブルＴ３０のエントリは、アプリ名Ｃ４０１と、コンピュートサーバＩＤ Ｃ４０２とのフィールドを含む。

【0089】

アプリ名Ｃ４０１には、エントリに対応するアプリケーションの名称（アプリ名）が格納される。コンピュートサーバＩＤ Ｃ４０２には、エントリに対応するアプリケーションを実行するアプリコンテナ５０を有するコンピュートサーバ２０のサーバＩＤが格納される。

【0090】

アプリコンテナ配置テーブルＴ３０のエントリや値は、アプリコンテナ５０がコンピュートサーバ２０に追加された際に、コンテナオーケストレータ管理プログラムＰ１１０によって格納される。アプリコンテナ５０のオートスケール時においては、コンテナオーケストレータ管理プログラムＰ１１０は、アプリコンテナ配置テーブルＴ３０とサーバ管理テーブルＴ２０とを参照して、対象となるアプリケーションを実行するアプリコンテナ５０を起動していないコンピュートサーバ２０を特定し、このコンピュートサーバ２０においてアプリコンテナ５０を起動する。

【0091】

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

【0092】

まず、アプリコンテナ５０をスケールアウトするスケールアウト処理について説明する。

【0093】

図１１は、第１実施形態に係るスケールアウト処理のフローチャートである。

【0094】

管理サーバ１３０のコンテナオーケストレータ管理プログラムＰ１１０（厳密には、コンテナオーケストレータ管理プログラムＰ１１０を実行する管理サーバ１３０のＣＰＵ１６０）は、各コンピュートサーバ２０のコンテナオーケストレータプログラムＰ３０からＣＰＵの使用率（負荷情報）／性能情報を受け取り、コンピュートサーバ２０におけるアプリコンテナの性能及びリソース不足を検知する（ステップＳ１１０）。なお、コンピュートサーバ２０のコンテナオーケストレータプログラムＰ３０は、自身が稼働するコンピュートサーバ２０のＣＰＵの使用率／性能情報を適宜取得している。

【0095】

ここで、コンピュートサーバ２０におけるアプリコンテナの性能及びリソース不足を検知した場合には、ステップＳ１２０以降の処理が実行され、検知していない場合には、スケールアウト処理は終了される。

【0096】

ステップＳ１２０では、管理サーバ１３０のコンテナオーケストレータ管理プログラムＰ１１０は、サーバ管理テーブルＴ２０とアプリコンテナ配置テーブルＴ３０を参照し、計算機システム１内のコンピュートサーバ２０から、スケールアウトする対象のアプリコンテナ（対象アプリコンテナ）と同じアプリケーションを実行するアプリコンテナが起動していないコンピュートサーバ２０を、スケールアウトのためにアプリコンテナを作成するコンピュートサーバに決定する。

【0097】

次いで、コンテナオーケストレータ管理プログラムＰ１１０は、参照ＬＵ特定処理（図１２参照）を実行することにより、対象アプリコンテナが利用しているファイルを格納するＬＵを特定する（ステップＳ１３０）。

【0098】

次いで、コンテナオーケストレータ管理プログラムＰ１１０は、ファイル高速複製処理（図１３参照）を実行することにより、生成する新たなアプリコンテナがファイルを利用できるように複製する（ステップＳ１４０）。

【0099】

次いで、コンテナオーケストレータ管理プログラムＰ１１０は、ステップＳ１２０で決定したコンピュートサーバ２０のコンテナオーケストレータプログラムＰ３０に対象アプリコンテナと同じアプリケーションを実行するアプリコンテナを新規に起動させる指示を送信する（ステップＳ１５０）。この結果、コンテナオーケストレータプログラムＰ３０は、新規にアプリコンテナを起動させる。これにより、起動されたアプリコンテナは、特定したＬＵにリードオンリーでアクセスして処理を行うことができるようになる。この後、アプリクライアント４０は、スケールアウトのために作成したアプリコンテナを含む同一のアプリケーションを実行する全てのアプリコンテナを利用して処理を実行することとなる。

【0100】

なお、図１１に示すスケールアウト処理では、アプリコンテナのＣＰＵ等のリソースの性能不足を検知したことに基づいて、アプリコンテナをスケールアウトする例を示しているが、これは例示に過ぎず、例えば、管理者やユーザの指示によりアプリコンテナをスケールアウトしてもよい。

【0101】

また、上記した例では、オートスケールで作成した新規のアプリコンテナがリードオンリーでＬＵにアクセスすることを想定しているが、これは例示に過ぎず、例えば新規のアプリコンテナがリードオンリーのＬＵに対する更新データを別領域に格納するようにし、別領域の更新データとＬＵのデータとをマージすることで、実質的に更新可能なＬＵとして使用してもよい。

【0102】

また、コンテナオーケストレータ管理プログラムＰ１１０は、アプリコンテナを新規に起動した場合には、新規に起動させたアプリコンテナと、起動させた時刻（オートスケールの時刻）とを対応付けた情報をメモリ１５０に格納して管理するようにしてもよい。

【0103】

次に、ステップＳ１３０の参照ＬＵ特定処理について説明する。

【0104】

図１２は、第１実施形態に係る参照ＬＵ特定処理のフローチャートである。

【0105】

管理サーバ１３０のコンテナオーケストレータ管理プログラムＰ１１０は、アプリコンテナ配置テーブルＴ３０を参照し、オートスケールする対象アプリコンテナが動作するコンピュートサーバ２０を特定する（ステップＳ２１０）。

【0106】

次いで、コンテナオーケストレータ管理プログラムＰ１１０は、特定した各コンピュートサーバ２０のコンテナオーケストレータプログラムＰ３０にアプリコンテナのオートスケールを通知する（ステップＳ２２０）。次いで、各コンピュートサーバ２０のコンテナオーケストレータプログラムＰ３０は、ファイルＬＵ対応管理プログラムＰ６０にアプリコンテナのオートスケールを通知する（ステップＳ２３０）。

【0107】

ファイルＬＵ対応管理プログラムＰ６０は、アプリコンテナファイルパス対応テーブルＴ４０を参照し、対象アプリコンテナが使用しているファイルパスを特定する（ステップＳ２４０）。

【0108】

次いで、ファイルＬＵ対応管理プログラムＰ６０は、分散ファイルシステム８０のデータ配置アルゴリズムに基づいて、アプリコンテナが使用するファイルのＬＵを全て特定する（ステップＳ２５０）。具体的には、ファイルＬＵ対応管理プログラムＰ６０は、ファイルシステム情報Ｔ５０を参照し、ステップＳ２４０で特定したファイルパス以下にある全てのファイルを特定し、データ配置アルゴリズムに基づいて、特定した各ファイルが配置されているＬＵを特定する。

【0109】

次いで、各コンピュートサーバ２０のファイルＬＵ対応管理プログラムＰ６０は、オートスケールするコンピュートサーバ２０の連携プログラムＰ４０に、ファイルが格納されているＬＵを新規に作成するアプリコンテナから参照するよう通知する（ステップＳ２６０）。

【0110】

なお、図１２の参照ＬＵ特定処理の例では、アプリコンテナが使用する全てのファイルの全てのＬＵを特定するようにしていたが、本発明はこれに限られず、例えば、管理者によって指定されたアプリケーション毎に複製する必要があるファイルについてのＬＵを特定するようにしてもよい。

【0111】

次に、ステップＳ１４０のファイル高速複製処理について説明する。

【0112】

図１３は、第１実施形態に係るファイル高速複製処理のフローチャートである。

【0113】

スケールアウトするアプリコンテナを稼働させるコンピュートサーバは２０の連携プログラムＰ４０は、ステップＳ２６０での通知を受信し、通知により参照するように指示されたＬＵをコンピュートサーバは２０にリードオンリーでマウントする（ステップＳ３１０）。具体的には、連携プログラムＰ４０は、ストレージ接続プログラムＰ７０に指示し、共有ブロックストレージ３０上の指示されたＬＵをリードオンリーで接続させる。

【0114】

次いで、連携プログラムＰ４０は、ステップＳ３１０でＬＵをマウントした場所を、アプリコンテナがファイルアクセスできる新規データ領域（ボリューム）として設定する（ステップＳ３２０）。

【0115】

次いで、連携プログラムＰ４０は、アプリコンテナ５０を作成し、アプリコンテナ５０にステップＳ３２０で設定した新規データ領域を割り当てる（ステップＳ３３０）。これにより、アプリコンテナ５０は新規データ領域を介して使用するファイルが格納されたＬＵをリードオンリーで参照可能となり、アプリクライアント４０から割り振られた処理を実行可能となる。

【0116】

次に、分散ボリューム作成処理について説明する。

【0117】

図１４は、第１実施形態に係る分散ボリューム作成処理のフローチャートである。

【0118】

管理サーバ１３０のコンテナオーケストレータ管理プログラムＰ１１０が管理者からデータ格納領域（ボリューム）の作成要求を受け付ける（ステップＳ４１０）。

【0119】

次いで、コンテナオーケストレータ管理プログラムＰ１１０は、データ格納領域の作成要求をコンピュートサーバ２０のコンテナオーケストレータ６０に通知し、コンテナオーケストレータ６０は、連携プログラムＰ４０にデータ格納領域の作成要求を渡し、連携プログラムＰ４０はブロックストレージプログラムＰ９０にＬＵ作成を通知し、ブロックストレージプログラムＰ９０は所定の数（複数）の細分化されたＬＵを作成する（ステップＳ４２０）。ここで、作成するＬＵの数は例示に過ぎず、要求された容量からＬＵの数を決めるなどしてもよい。また、ＬＵのサイズは、所定のデータ容量以下となるように決定してもよい。

【0120】

次いで、連携プログラムＰ４０は、分散ファイルシステム８０に作成されたＬＵを追加（マウント）する（ステップＳ４３０）。

【0121】

次いで、連携プログラムＰ４０が分散ボリューム７０を作成し、分散ボリューム管理テーブルＴ１０に作成した分散ボリューム７０のエントリを追加する（ステップＳ４４０）。

【0122】

次いで、分散ファイルシステム８０（複数のコンピュートサーバ２０の分散ＦＳ制御プログラムＰ１０）が、サービスを開始し、連携プログラムＰ４０は、アプリコンテナファイルパス対応テーブルＴ４０において、ボリュームを割り当てるアプリに対応するエントリを更新する（ステップＳ４５０）。

【0123】

この分散ボリューム作成処理によると、ＬＵのサイズを小さくすることができるので、例えば、サーバを減設する際に、サーバが持っていたデータを格納しているＬＵを、サーバの負荷が集中しないように残りのサーバに容易且つ適切に割り当てることができる。

【0124】

次に、分散処理アプリ管理画面Ｉ１００について説明する。分散処理アプリ管理画面Ｉ１００は、コンテナオーケストレータ管理プログラムＰ１１０により表示出力される画面である。

【0125】

図１５は、第１実施形態に係る分散処理アプリ管理画面の構成図である。

【0126】

分散処理アプリ管理画面Ｉ１００は、アプリコンテナ識別子表示領域Ｉ０１と、稼働サーバ表示領域Ｉ１０と、ＣＰＵ負荷表示領域Ｉ２０と、性能表示領域Ｉ３０と、高速オートスケール表示領域Ｉ４０と、性能グラフ表示領域Ｉ５０とを含む。

【0127】

アプリコンテナ識別子表示領域Ｉ０１には、分散処理アプリ管理画面Ｉ１００の表示対象の分散処理を行うアプリコンテナの識別子（例えば、アプリコンテナで実行するアプリケーションの名前）が表示される。稼働サーバ表示領域Ｉ１０には、表示対象のアプリコンテナが稼働しているサーバ（コンピュートサーバ２０）の名称が表示される。ＣＰＵ負荷表示領域Ｉ２０には、同じ行のサーバにおけるＣＰＵ１６０の負荷の情報が表示される。性能表示領域Ｉ３０には、同じ行のサーバにおける出力性能（ＯＰＳ：Operations Per Second）が表示される。高速オートスケール表示領域Ｉ４０には、同じ行のサーバがオートスケールのスケール元であるか、スケール先であるかが表示される。性能グラフ表示領域Ｉ５０には、表示対象のアプリコンテナを稼働する全てのコンピュートサーバの性能（ＯＰＳ）の合計についての時間変化のグラフが表示される。このグラフにおいては、オートスケールを行ったタイミングも表示され、オートスケール前後の表示対象のアプリコンテナを有する全てのコンピュートサーバの性能の変化を把握することができる。

【0128】

管理者は、分散処理アプリ管理画面Ｉ１００により、高速オートスケールしたアプリコンテナを有するサーバの性能、ＣＰＵ負荷、稼働サーバの数や、オートスケールの効果等について確認することができる。

【0129】

次に、第２実施形態に係る計算機システムについて説明する。

【0130】

まず、第２実施形態の概要について説明する。

【0131】

図１６は、第２実施形態の概要を説明する図である。図１６は、第２実施形態に係る計算機システム１Ａにおいて、アプリコンテナ５０のオートスケール方法の概要を説明する図である。なお、第２実施形態の説明において、第１実施形態に係る計算機システム１と同様な構成については、同一の符号を付すこととする。

【0132】

第２実施形態に係る計算機システム１Ａにおいては、ストレージサーバ２４０がブロックストレージとファイルストレージとの両方として機能する。

【0133】

計算機システム１Ａは、クライアントサーバ１０と、複数（図では、４つ）のコンピュートサーバ２３０（コンピュートサーバＡ～Ｄ）と、複数（図では、４つ）のストレージサーバ２４０（ストレージサーバＥ～Ｈ）と、管理サーバ１３０とを有する。

【0134】

コンピュートサーバ２３０は、コンテナオーケストレータ６０を有する。ここで、オートスケールを実行する前においては、３台のコンピュートサーバ２３０（コンピュートサーバＡ～Ｃ）が、同一のアプリケーションを実行するアプリコンテナ５０を有し、コンピュートサーバ２３０（コンピュートサーバＤ）は、同一のアプリケーションを実行するアプリコンテナ５０を有していない。

【0135】

アプリコンテナ５０は、アプリケーションを実行して、アプリクライアント４０から割り振られたデータに対して処理を実行する。コンテナオーケストレータ６０は、アプリコンテナ５０を管理する。

【0136】

ストレージサーバ２４０は、分散ファイルシステム８０と、データＬＵ対応管理部１００とを有する。複数のストレージサーバ２４０は、それぞれのストレージサーバ２４０が有する記憶装置１４０により共有ブロックストレージ３０を構成している。分散ファイルシステム８０は、共有ブロックストレージ３０の記憶領域に作成された複数のＬＵ９０を用いて、複数のストレージサーバ２４０上に跨る分散ボリューム７０を作成する。分散ファイルシステム８０は、共有ブロックストレージ３０の記憶領域に複数のＬＵを作成することができる。分散ボリューム７０上には、各コンピュートサーバ２３０のコンテナオーケストレータ６０のデータ格納領域が設けられ、アプリコンテナ５０が利用するファイルが格納される。データＬＵ対応管理部１００は、アプリコンテナ５０が使用するファイルが格納されるＬＵ９０を管理する。

【0137】

計算機システム１Ａにおいて、コンテナオーケストレータ６０は、コンピュートサーバ２３０のリソースを監視し、コンテナオーケストレータ管理部１３１は、例えば、ＣＰＵのリソースが逼迫していることを検出した場合には、アプリコンテナ５０のオートスケールを実施する。具体的には、コンテナオーケストレータ管理部１３１は、コンピュートサーバ２３０（図１では、コンピュートサーバＤ）に新たにアプリコンテナ５０を追加する。これにより、アプリコンテナ５０の負荷が分散されることとなる。

【0138】

このオートスケールを行う際に、計算機システム１Ａにおいては、追加したアプリコンテナ５０が使用するファイルについて、コンテナオーケストレータ管理部１３１は、既にアプリコンテナ５０が使用するために格納されているＬＵ９０を特定する。次いで、追加したアプリコンテナ５０を有するコンピュートサーバ２３０を、共有ブロックストレージ３０上の特定したＬＵ９０に、例えば、リードオンリーで接続させる。これにより、追加したアプリコンテナ５０は、そのＬＵ９０のデータをデータコピーすることなく使用することができるようになり、高速にファイルレプリケーションを実現することができる。

【0139】

次に、コンピュートサーバ２３０について説明する。

【0140】

図１７は、第２実施形態に係るコンピュートサーバの構成図である。

【0141】

コンピュートサーバ２３０は、プロセッサの一例としてのＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース１７０と、記憶装置１４０と、ＢＭＣ１９０とを有する。ＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース１７０と、記憶装置１４０とは、内部バス１８０を介して接続されている。

【0142】

コンピュートサーバ２３０のメモリ１５０は、分散ＦＳクライアントプログラムＰ２０と、コンテナオーケストレータプログラムＰ３０と、連携プログラムＰ４０と、アプリコンテナプログラムＰ５０とを記憶する。

【0143】

分散ＦＳクライアントプログラムＰ２０は、コンピュートサーバ２３０のアプリコンテナ５０にストレージサーバ２４０上の分散ボリューム７０をマウントする。

【0144】

次に、ストレージサーバ２４０について説明する。

【0145】

図１８は、第２実施形態に係るストレージサーバの構成図である。

【0146】

ストレージサーバ２４０は、プロセッサの一例としてのＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース１７０と、１以上のストレージインターフェース２００と、複数の記憶装置１４０と、ＢＭＣ１９０とを有する。ＣＰＵ１６０と、メモリ１５０と、ネットワークインターフェース１７０と、ストレージインターフェース２００とは、内部バス１８０を介して接続されている。

【0147】

ストレージサーバ２４０のメモリ１５０は、分散ＦＳ制御プログラムＰ１０と、アプリコンテナ使用ファイルＦ１０と、ファイルＬＵ対応管理プログラムＰ６０と、アプリコンテナファイルパス対応テーブルＴ４０と、ＩＯ制御プログラムＰ８０と、ブロックストレージプログラムＰ９０と、ファイルシステム情報Ｔ５０とを記憶する。

【0148】

次に、第２実施形態に係る計算機システム１Ａにおける処理動作について説明する。なお、第２実施形態に係る計算機システム１Ａにおける処理動作のうち、第１実施形態に係る計算機システム１と同様な処理については、説明を省略することがある。

【0149】

計算機システム１Ａのスケールアウト処理は、図１１に示す第１実施形態に係るスケールアウト処理と同様である。

【0150】

次に、ステップＳ１３０の参照ＬＵ特定処理について説明する。

【0151】

図１９は、第２実施形態に係る参照ＬＵ特定処理のフローチャートである。

【0152】

ステップＳ２２０の実行後、各コンピュートサーバ２３０のコンテナオーケストレータプログラムＰ３０は、ストレージサーバ２４０のファイルＬＵ対応管理プログラムＰ６０にアプリコンテナのオートスケールを通知する（ステップＳ５３０）。

【0153】

次に、ステップＳ１４０のファイル高速複製処理について説明する。

【0154】

図２０は、第２実施形態に係るファイル高速複製処理のフローチャートである。

【0155】

スケールアウトするアプリコンテナを稼働させるコンピュートサーバ２３０の連携プログラムＰ４０は、ステップＳ２６０での通知を受信し、通知により参照するように指示されたＬＵをストレージサーバ２４０に通知し、ストレージサーバ２４０に指示されたＬＵをリードオンリーでマウントさせる（ステップＳ６１０）。ストレージサーバ２４０の分散ＦＳ制御プログラムＰ１０は指示を受けて、共有ブロックストレージ３０上の指示されたＬＵをリードオンリーで接続させる。

【0156】

次いで、連携プログラムＰ４０は、ステップＳ６１０でＬＵをマウントした場所を、アプリコンテナがファイルアクセスできる新規データ領域（ボリューム）として設定させる指示をストレージサーバ２４０に送信し、ストレージサーバ２４０の分散ＦＳ制御プログラムＰ１０は指示を受けて、ＬＵをマウントした場所を、アプリコンテナがファイルアクセスできる新規データ領域（ボリューム）として設定する（ステップＳ６２０）。

【0157】

次いで、連携プログラムＰ４０は、アプリコンテナ５０を作成し、ストレージサーバ２４０の分散ＦＳ制御プログラムＰ１０に指示をして、アプリコンテナ５０にステップＳ３２０で設定した新規データ領域を割り当てる（ステップＳ６３０）。これにより、アプリコンテナ５０は新規データ領域を介して使用するファイルが格納されたＬＵをリードオンリーで参照可能となり、アプリクライアント４０から割り振られた処理を実行可能となる。

【0158】

次に、分散ボリューム作成処理について説明する。

【0159】

図２１は、第２実施形態に係る分散ボリューム作成処理のフローチャートである。

【0160】

コンピュートサーバ２３０の連携プログラムＰ４０は、ストレージサーバ１２０の分散ＦＳ制御プログラムＰ１０に、分散ファイルシステム８０に作成されたＬＵを追加（マウント）するように通知し、通知を受けた分散ＦＳ制御プログラムＰ１０は分散ファイルシステム８０に作成されたＬＵを追加する（ステップＳ７３０）。次いで、連携プログラムＰ４０が分散ボリューム７０を作成し、分散ボリューム管理テーブルＴ１０に作成した分散ボリューム７０のエントリを追加する（ステップＳ７４０）。

【0161】

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

【0162】

例えば、上記実施形態において、アプリケーションをコンテナで実行する例を示していたが、本発明はこれに限られず、例えば、アプリケーションをＶＭ（実行部の一例）で実行するようにしてもよい。

【0163】

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

【符号の説明】

【0164】

１，１Ａ…計算機システム、１０…クライアントサーバ、２０，２３０…コンピュートサーバ、３０…共有ブロックストレージ、５０…アプリコンテナ、９０…ＬＵ、１１０…ネットワーク、１２０，２４０…ストレージサーバ、１３０…管理サーバ、１４０…記憶装置、１５０…メモリ、１６０…ＣＰＵ、１７０…ネットワークインターフェース、１８０…内部バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】