(57)【要約】サーバストレージシステムが、複数のサーバリソースと、複数のストレージリソースとを含む。管理システムが、割当て制御情報を記憶する。割当て制御情報は、占有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、共有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、仮想サーバの負荷の特性である仮想サーバ負荷特性との対応関係を表す情報である。管理システムは、それぞれ仮想サーバ負荷特性に関わり管理者により入力された１種類以上の負荷特性情報が関連付けられた仮想サーバ作成指示を受け付け、割当て制御情報と、１種類以上の負荷特性情報とに基づき、占有割当てされるサーバリソース及びストレージリソースを選択する。管理システムは、選択されたリソースを対象仮想サーバに割り当てる。割当て制御情報は、変更可能な情報である。
2017002185.tif 000002
【特許請求の範囲】
【請求項１】
サーバシステム及びストレージシステムを含んだサーバストレージシステムの管理システムであって、
前記サーバストレージシステムに接続されたインターフェースと、
割当て制御情報を記憶する記憶部と、
前記インターフェース及び前記記憶部に接続されたプロセッサと
を有し、
前記サーバストレージシステムが、複数種類のリソースを含んだ複数のリソースを含み、
前記複数のリソースは、前記サーバシステムが有する複数種類のサーバリソースを含んだ複数のサーバリソースと、前記ストレージシステムが有する複数種類のストレージリソースを含んだ複数のストレージリソースとを含み、
前記割当て制御情報は、占有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、共有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、仮想サーバの負荷の特性である仮想サーバ負荷特性との対応関係を表す情報であり、
前記プロセッサは、
（Ａ）それぞれ仮想サーバ負荷特性に関わり管理者により入力された１種類以上の情報である１種類以上の負荷特性情報が関連付けられた仮想サーバ作成指示を受け付け、
（Ｂ）前記割当て制御情報と、前記１種類以上の負荷特性情報とに基づき、占有割当てされるサーバリソース及びストレージリソースを選択し、
（Ｃ）（Ｂ）においてサーバリソース及びストレージリソースの少なくとも１つが選択された場合に選択されたリソースを対象仮想サーバに割り当て、
前記割当て制御情報は、変更可能な情報である、
管理システム。
【請求項２】
前記プロセッサは、
（Ｐ）占有有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、共有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、仮想サーバ負荷特性との新たな対応関係の入力を受け付け、
（Ｑ）入力された新たな対応関係を前記割当て制御情報に追加する、
請求項１記載の管理システム。
【請求項３】
前記プロセッサは、（Ｂ）で所定条件を満たすサーバリソース及びストレージリソースの両方を選択してから（Ｃ）を実行し、
前記所定条件を満たすサーバリソース及びストレージリソースは、互いに物理的に接続されたサーバリソース及びストレージリソースであって、前記割当て制御情報と前記１種類以上の負荷特性情報とに基づくリソース種類及びリソース量のサーバリソース及びストレージリソースである、
の両方を含む、
請求項１記載の管理システム。
【請求項４】
前記プロセッサは、占有割当てされるサーバリソース及びストレージリソースのうちの少なくとも１つが不足の場合、
（Ｘ）不足リソースのリソース種類を表す情報を含んだ情報であるエラー情報を出力する、
請求項１記載の管理システム。
【請求項５】
前記プロセッサは、（Ｃ）の完了後、
（Ｄ）前記対象仮想サーバの起動イメージを用いた起動のための設定を前記対象仮想サーバに対して自動で行う、
請求項１記載の管理システム。
【請求項６】
（Ｂ）乃至（Ｄ）の各々は、定義された１以上のワークフローの実行により行われ、
少なくとも１つのワークフローが変更可能であり、
前記プロセッサは、前記少なくとも１つのワークフローの変更を、第１の管理者に許可せず、第２の管理者に許可し、
前記第１の管理者は、仮想サーバを管理するが少なくともサーバストレージシステムを管理しない管理者であり、
前記第２の管理者は、少なくともサーバストレージシステムを管理する管理者である、
請求項５記載の管理システム。
【請求項７】
前記プロセッサは、前記割当て制御情報の変更を、第１の管理者に許可せず、第２の管理者に許可し、
前記第１の管理者は、仮想サーバを管理するが少なくとも前記サーバストレージシステムを管理しない管理者であり、
前記第２の管理者は、少なくとも前記サーバストレージシステムを管理する管理者である、
請求項１記載の管理システム。
【請求項８】
前記サーバストレージシステムが、サーバシステムからストレージシステムにかけて論理分割されることにより得られた複数のサブシステムを有し、
前記複数のサブシステムのうちの第１サブシステムが、本番環境に属するサブシステムである本番系であり、
前記複数のサブシステムのうちの第２サブシステムが、開発環境に属するサブシステムである開発系であり、
前記１種類以上の負荷特性情報が、本番系と開発系のいずれであるかを表す情報を含み、
前記割当て制御情報において、少なくとも１つの同一の仮想サーバ負荷特性について、本番系に対応したリソース種類及びリソース量と、開発系に対応したリソース種類及びリソース量が異なっている、
請求項１記載の計算機システム。
【請求項９】
前記割当て制御情報と前記１種類以上の負荷特性情報とに基づくリソース種類及びリソース量のサーバリソースである必要サーバリソースの少なくとも１つがいずれのサーバシステムでも不足の場合、前記エラー情報は、不足サーバリソースのリソース種類及び不足リソース量をサーバシステム毎に表した情報を含み、
前記プロセッサは、サーバリソース不足が解消されると仮定されたサーバリソースについて、前記割当て制御情報と前記１種類以上の負荷特性情報とに基づくリソース種類及びリソース量のストレージリソースである必要ストレージリソースを探す、
請求項３記載の管理システム。
【請求項１０】
前記必要サーバリソースが全て少なくとも１つのサーバシステムにあるが、前記必要ストレージリソースが少なくとも１ついずれのストレージシステムでも不足の場合、前記エラー情報は、前記必要サーバリソースが見つかったサーバシステムについて見つかった前記必要サーバリソースを表す情報と、不足ストレージリソースのリソース種類及び不足リソース量を表す情報とを含む、
請求項９記載の管理システム。
【請求項１１】
前記エラー情報は、前記必要サーバリソースの少なくとも１つが不足しているサーバシステムがあれば、そのサーバリソースについて不足サーバリソースのリソース種類及び不足リソース量を表す情報を更に含む、
請求項１０記載の管理システム。
【請求項１２】
（Ｂ）では、前記１種類以上の負荷特性情報に対応したパラメータを前記割当て制御情報から取得する処理であるパラメータ取得処理と、取得されたパラメータに該当するサーバリソース及びストレージリソースを選択する処理であるリソース選択処理とが実行され、
前記パラメータ取得処理のためのワークフローが、前記リソース選択処理のためのワークフローから独立しており、且つ、変更可能なフローである、
請求項６記載の管理システム。
【請求項１３】
前記１以上の負荷特性情報は、前記対象の仮想サーバで実行されるＡＰＰのＡＰＰ識別情報及びＡＰＰ用途を含む、
請求項１記載の管理システム。
【請求項１４】
前記１以上の負荷特性情報は、更に、仮想サーバサイズを含み、
前記割当て制御情報において、少なくとも１つの同一のＡＰＰ識別情報及びＡＰＰ用途の組について、仮想サーバサイズが異なっていれば、リソース種類が同一であってもリソース量が異なっている、
請求項１３記載の管理システム。
【請求項１５】
サーバシステム及びストレージシステムを含んだサーバストレージシステムの管理方法であって、前記サーバストレージシステムが、複数種類のリソースを含んだ複数のリソースを含み、前記複数のリソースは、前記サーバシステムが有する複数種類のサーバリソースを含んだ複数のサーバリソースと、前記ストレージシステムが有する複数種類のストレージリソースを含んだ複数のストレージリソースとを含み、
前記管理方法が、
（Ａ）それぞれ仮想サーバ負荷特性に関わり管理者により入力された１種類以上の情報である１種類以上の負荷特性情報が関連付けられた仮想サーバ作成指示を受け付け、
（Ｂ）占有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、共有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、仮想サーバの負荷の特性である仮想サーバ負荷特性との対応関係を表す情報である割当て制御情報と、前記１種類以上の負荷特性情報とに基づき、占有割当てされるサーバリソース及びストレージリソースを選択し、
（Ｃ）（Ｂ）においてサーバリソース及びストレージリソースの少なくとも１つが選択された場合に選択されたリソースを対象仮想サーバに割り当て、
前記割当て制御情報は、変更可能な情報である、
管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、サーバストレージシステムのリソースの割当てに関する。
【背景技術】
【０００２】
サーバとストレージを有するサーバストレージシステムが知られている。このようなサーバストレージシステムに複数のアプリケーションプログラム（ＡＰＰ）を集約することのニーズがある。いずれかのＡＰＰの性能が別のいずれかのＡＰＰの性能に影響を与えないよう、サーバストレージシステムのリソースを論理的に分割し、論理的に分割された異なるリソースで異なる複数のＡＰＰを実行することが望ましい。特許文献１によれば、サーバとストレージシステムのリソースを、複数のＡＰＰに占有的に割り当てることで論理的に分割できる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第４２２７０３５号
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のようにサーバからストレージにかけてリソースを論理的に分割すると、隣接する論理区画（Logical Partitioning（ＬＰＡＲ））及び仮想マシン（ＶＭ）のうちの少なくとも一方（以後は纏めて仮想サーバと呼ぶ）の影響は抑止できる。しかし、割り当てられてたリソース以上のリソースが必要になっている場合であっても、他の仮想サーバに占有的に割り当てられたリソースを使うことはできない。よって、全ての仮想サーバに関して、サーバからストレージにかけた論理分割を行うと、リソースの利用効率が低下する。【０００５】
また、サーバからストレージにかけてリソースを論理的に分割するためには、サーバ及びストレージの各々のリソースに対して、管理者が、性能競合を起こさないように設定を行う必要がある。しかし、リソース割当てに関して高度な専門知識を持たない管理者では、そのような設定は困難である。【０００６】
よって、本願では、共存するＡＰＰの集約率の向上と性能影響の防止の両方を実現するリソース割当てが管理者にとって簡単であることを課題とする。
【課題を解決するための手段】
【０００７】
サーバシステム及びストレージシステムを含んだサーバストレージシステムが、複数種類のリソースを含んだ複数のリソースを含む。複数のリソースは、サーバシステムが有する複数種類のサーバリソースを含んだ複数のサーバリソースと、ストレージシステムが有する複数種類のストレージリソースを含んだ複数のストレージリソースとを含む。サーバストレージシステムの管理システムが、割当て制御情報を記憶する。割当て制御情報は、占有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、共有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、仮想サーバの負荷の特性である仮想サーバ負荷特性との対応関係を表す情報である。管理システムは、それぞれ仮想サーバ負荷特性に関わり管理者により入力された１種類以上の情報である１種類以上の負荷特性情報が関連付けられた仮想サーバ作成指示を受け付ける。管理システムは、割当て制御情報と、１種類以上の負荷特性情報とに基づき、占有割当てされるサーバリソース及びストレージリソースを選択する。管理システムは、サーバリソース及びストレージリソースの少なくとも１つが選択された場合に選択されたリソースを対象仮想サーバに割り当てる。割当て制御情報は、変更可能な情報である。なお、「仮想サーバへの負荷の負荷特性」とは、仮想サーバに割り当てられたリソース（例えば、後述のＣＰＵ又はＨＢＡポート等）への負荷の負荷特性であってもよいし、仮想サーバに提供されたリソース（例えば、後述のＶＯＬ）への負荷の負荷特性であってもよい。また、「負荷特性」は、期待（予測）される負荷の特性であってもよいし、実測値として得られた負荷の特性であってもよい。また、仮想サーバに「割り当てられたリソース」とは、割り当てられた結果として仮想サーバの一構成要素となるリソースである。一方、仮想サーバに「提供されたリソース」とは、仮想サーバ（又は仮想サーバを使用する外部の装置（又はコンピュータプログラム））により使用されるリソースである（典型的には、仮想サーバの一構成要素としては扱われない）。
【発明の効果】
【０００８】
ＡＰＰの集約率の向上と性能影響の防止の両方を実現するリソース割当てが管理者にとって簡単である。
【図面の簡単な説明】
【０００９】
【図１】実施例に係る計算機システムの概要を示す。
【図２Ａ】サーバストレージシステムのリソース割当て（論理分割）の幾つかの例を示す。
【図２Ｂ】サーバストレージシステムの管理側の構成例を示す。
【図３】Ｉ／Ｏサイズテーブルの構成例を示す。
【図４】割当てポリシーテーブルの構成例を示す。
【図５】統合ＬＰＡＲサイズテンプレートテーブルの構成例を示す。
【図６】ＶＯＬテンプレートテーブルの構成例を示す。
【図７】統合ＬＰＡＲテーブルの構成例を示す。
【図８】サーバＬＰＡＲテーブルの構成例を示す。
【図９】サーバＬＰＡＲ／ＨＢＡテーブルの構成例を示す。
【図１０】サーバＨＢＡテーブルの構成例を示す。
【図１１】ストレージＨＢＡテーブルの構成例を示す。
【図１２】サーバ／ストレージ接続テーブルの構成例を示す。
【図１３】ストレージパーティションテーブルの構成例を示す。
【図１４】ストレージパーティション作成画面の構成例を示す。
【図１５】統合ＬＰＡＲ作成画面の構成例を示す。
【図１６】統合ＬＰＡＲ作成全体ＷＦ（ワークフロー）の構成例を示す。
【図１７】統合ＬＰＡＲ作成全体ＷＦにおける統合ＬＰＡＲ作成ＷＦのコンポーネント（ＷＦ）間の関係を示す。
【図１８】統合ＬＰＡＲ作成全体処理の流れを示す。
【図１９】統合ＬＰＡＲ作成処理の流れを示す。
【図２０】リソース選択処理の流れを示す。
【図２１】リソース割当て処理の流れを示す。
【図２２】サーバＬＰＡＲ作成処理の流れを示す。
【図２３】ストレージリソース割当て処理の流れを示す。
【図２４】割当て制御情報変更処理の流れを示す。
【図２５】サーバストレージシステムの構成例を示す。
【図２６】統合管理サーバの構成例を示す。
【図２７】ＷＦ提供の一例の概要の模式図である。
【図２８】変更制御処理の流れを示す。
【図２９】失敗要因がサーバリソース不足の場合に出力されるエラー情報の一例を示す。
【図３０】失敗要因がストレージリソース不足の場合に出力されるエラー情報の一例を示す。
【発明を実施するための形態】
【００１０】
以下、一実施例を説明する。なお、前述の通り仮想サーバの実現方式の一例としてはＬＰＡＲ（Logical  Partitioning：論理区画）と、ＶＭ(Virtual Machine)とうちの少なくとも１つがあるが、それに代えて、ソフトウェアコンテナ等でもよい。以後の説明では仮想サーバの一例としてＬＰＡＲを対象として説明を行うが、当然ながら他の仮想サーバの実現方式であってもよい。「仮想サーバ」の「サーバ」は、クライアントサーバモデルでのサーバの意味に限定されず、広義に計算機として解釈されてよい。
【００１１】
以下の説明では、「×××テーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「×××テーブル」を「×××情報」と呼ぶことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。
【００１２】
また、以下の説明では、要素の識別情報として、ＩＤ又は名前が使用されるが、それに代えて又は加えて他種の識別情報が使用されてもよい。
【００１３】
また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号（又は参照符号における共通符号）を使用し、同種の要素を区別して説明する場合は、要素識別情報（要素に割り振られたＩＤ又は名前等の識別情報）（又は参照符号）を使用することがある。
【００１４】
また、以下の説明では、Ｉ／Ｏ（Input/Output）要求は、ライト要求又はリード要求であり、アクセス要求と呼ばれてもよい。
【００１５】
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central  Processing  Unit））によって実行されることで、定められた処理を、適宜に記憶部（例えばメモリ）及び／又はインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置又はシステムが行う処理としてもよい。また、プロセッサは、制御部の一例であり、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ（例えばＣＰＵ）と記憶部を含み、記憶部はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布してよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
【００１６】
また、以下の説明では、管理システムは、一以上の計算機で構成されてよい。具体的には、例えば、管理計算機が情報を表示する場合（具体的には、例えば、管理計算機が自分の表示デバイスに情報を表示する、或いは、管理計算機（例えば管理サーバ）が表示用情報を遠隔の表示用計算機（例えば管理クライアント）に送信する場合）、管理計算機が管理システムである。また、例えば、複数の計算機で管理計算機と同等の機能が実現されている場合は、当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機を含んでよい）が、管理システムである。管理計算機（例えば管理システム）は、表示システムを含むＩ／Ｏシステムに接続されたインターフェースデバイスと、記憶部（例えばメモリ）と、インターフェースデバイス及び記憶部に接続されたプロセッサとを有してよい。表示システムは、管理計算機が有する表示デバイスでもよいし、管理計算機に接続された表示用計算機でもよい。Ｉ／Ｏシステムは、管理計算機が有するＩ／Ｏデバイス（例えばキーボード及びポインティングデバイス、タッチパネル）でもよいし、管理計算機に接続された表示用計算機又は別の計算機でもよい。管理計算機が「表示用情報を表示する」ことは、表示システムに表示用情報を表示することであり、これは、管理計算機が有する表示デバイスに表示用情報を表示することであってもよいし、管理計算機が表示用計算機に表示用情報を送信することであってもよい（後者の場合は表示用計算機によって表示用情報が表示される）。また、管理計算機が情報を入出力するとは、管理計算機が有するＩ／Ｏデバイスとの間で情報の入出力を行うことであってもよいし、管理計算機に接続された遠隔の計算機（例えば表示用計算機）との間で情報の入出力を行うことであってもよい。情報の出力は、情報の表示であってもよい。
【００１７】
また、以下の説明では、「サーバＬＰＡＲ」は、サーバの複数のリソースのうちの少なくとも１つを占有するＬＰＡＲである。また、「ストレージパーティション」は、ストレージの複数のリソースのうちの少なくとも１つを占有するＬＰＡＲである。
【００１８】
また、以下の説明では、「統合ＬＰＡＲ」は、サーバのリソースとストレージのリソースの両方が割り当てられたＬＰＡＲを表す便宜上の言葉であり、ＬＰＡＲの一例である。つまりシステム内のサーバとストレージのリソースを論理的に分割した単位をいう。本実施例では、典型的には、統合ＬＰＡＲは、サーバＬＰＡＲの少なくとも一部とストレージパーティションの少なくとも一部を含む。統合ＬＰＡＲに割り当てられたサーバリソース及びストレージリソースは、いずれも、占有割当てされたリソースであっても共有割当てされたリソースであってもよい。具体的には、例えば、統合ＬＰＡＲには、少なくとも１つのサーバリソースが占有割当てされて、少なくとも１つのストレージリソースが占有割当て又は共有割当てされてもよい。また、例えば、統合ＬＰＡＲには、少なくとも１つのサーバリソースが共有割当てされて、少なくとも１つのストレージリソースが占有割当て又は共有割当てされてもよい。
【００１９】
また、以下の説明では、「リソース」は、サーバストレージシステムを構成するサーバ及びストレージの各々が有するエレメントでよい。エレメントとして、物理的なエレメント（例えばＣＰＵ、メモリ、ＨＢＡ（Host  Bus  Adapter）、ポート、ドライブ（物理記憶デバイス））もあれば、論理的なエレメント（例えばＶＯＬ（論理ボリューム））もある。また、サーバ及びストレージの外に存在するエレメント、例えば、サーバ及びストレージ間に存在する中継デバイス（例えば、ルーティング機能を有するスイッチ、或いはルーティング機能を有しないポート拡張デバイス）、サーバ間に存在する中継デバイス、及び、ストレージ間に存在する中継デバイスのいずれかも、「リソース」の一例として扱われてよい。また、そのような中継デバイスのエレメント（例えば、ポート、コア（コントローラ））も、「リソース」の一例として扱われてよい。
【００２０】
また、以下の説明では、「ＸがＹ１に占有割当てされる」とは、Ｘ（例えばリソース）がＹ１（例えば第１の統合ＬＰＡＲ）に割り当てられＹ１と同種の他のオブジェクトであるＹ２（例えば第２の統合ＬＰＡＲ）に割り当てられないことを意味する。結果として、Ｘは、Ｙ１に占有されることになる。このような割り当て制御は管理システムによって行われてもよい。例えば、ＸがＹ１に占有割り当てされた後は、管理システムはＸをＹ１以外に割り当てないように制御する。一方、「ＸがＹ１に共有割当てされる」とは、ＸがＹ１に割り当てられるがＹ２にも割当て可能であることを意味する。結果として、Ｘは、Ｙ１及びＹ２に共有され得る。このような割り当て制御は管理システムによって行われてもよい。例えば、ＸがＹ１に共有割り当てされた後でも、管理システムはＸをＹ１以外に割り当ててもよいように制御する。
【００２１】
また、以下の説明では、「占有リソース」は、占有割当てされたリソースであり、「共有リソース」は、共有割当てされたリソースである。
【００２２】
図１は、実施例に係る計算機システムの概要を示す。
【００２３】
統合管理サーバ１４０が、サーバ１００及びストレージ１２０を含んだサーバストレージシステム１０００の管理システムの一例である。サーバストレージシステム１０００が、複数種類のリソースを含んだ複数のリソースを含む。複数のリソースは、サーバ１００が有する複数種類のサーバリソースを含んだ複数のサーバリソースと、ストレージ１２０が有する複数種類のストレージリソースを含んだ複数のストレージリソースとを含む。
【００２４】
統合管理サーバ１４０が、割当て制御情報６７２を記憶する。割当て制御情報６７２は、占有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、共有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、統合ＬＰＡＲの負荷の特性であるＬＰＡＲ負荷特性との対応関係を表す情報である。割当て制御情報６７２は、変更可能な情報である。
【００２５】
統合管理サーバ１４０が、統合ＬＰＡＲ作成画面１４１（又は１６２）を表示する。統合ＬＰＡＲ作成画面１４１は、ＬＰＡＲ負荷特性に関わる情報を管理者（例えば後述のシステム管理者（又はテナント管理者））から受け付けるＧＵＩ（Graphical  User  Interface）である。
【００２６】
統合管理サーバ１４０が、統合ＬＰＡＲ作成画面１４１に管理者により入力された１種類以上の情報である１種類以上の負荷特性情報が関連付けられたＬＰＡＲ作成指示を受け付ける。統合管理サーバ１４０は、割当て制御情報６７２と１種類以上の負荷特性情報とに基づき、占有割当てされるサーバリソース及びストレージリソースを選択する。統合管理サーバ１４０は、サーバリソース及びストレージリソースの少なくとも１つが選択された場合に、選択されたリソースを対象ＬＰＡＲに割り当てる。サーバリソース及びストレージリソースのうちの少なくとも１つが選択される都度にリソース割当てが実行されてもよいし、サーバリソース及びストレージリソースの両方が選択されてからリソース割当てが実行されてもよい。
【００２７】
これにより、サーバからストレージにかけてリソースを論理的に分割することにより生じるリソース不足、特に、サーバ１００よりもストレージ１２０が少ないサーバストレージシステム１０００においてストレージリソースが不足することを回避できる。
【００２８】
また、上記のようなリソース割当てのためのパラメータ（統合ＬＰＡＲ作成に必要なパラメータ）を管理者が入力する必要が無い。管理者が、統合ＬＰＡＲの負荷の特性であるＬＰＡＲ負荷特性に関わる負荷特性情報を入力すれば、統合管理サーバ１４０が、入力された１種類以上の負荷特性情報を用いて、割当て制御情報６７２から占有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量といったパラメータを取得でき、その取得されたパラメータを基に上記のようなリソース割当てを行う。このため、リソース割当てに関して高度な専門知識を持たない管理者でも上記のようなリソース割当ての実現が可能である。
【００２９】
更に、割当て制御情報６７２は変更可能な情報である。このため、サーバストレージシステム１０００に統合ＬＰＡＲを作成するときに使用された割当て制御情報６７２の更新後の割当て制御情報６７２を使用して統合ＬＰＡＲを変更又は新たに作成することができる。サーバストレージシステム１０００の設置環境次第では、初期の割当て制御情報６７２を基に決定されたリソース量ほどリソースを占有させる必要が無かったり、占有割当てのためのリソース量が余る又は不足したりすることがあり得る。本実施例では、割当て制御情報６７２が変更可能であるため、サーバストレージシステム１０００の設置環境の違いや運用開始後の環境変化等に応じた統合ＬＰＡＲ作成が可能である。
【００３０】
以下、本実施例に係る計算機システムの概要を、詳細に説明する。
【００３１】
計算機システムは、サーバストレージシステム１０００と、サーバストレージシステム１０００を管理する管理サーバである統合管理サーバ１４０と、サーバストレージシステム１０００に集約された複数のＡＰＰ（アプリケーションプログラム）１０４を管理する１以上のＡＰＰ管理サーバ１６０とを有する。図示の例では、ＡＰＰ１０４として、ＡＰＰ−ａがあり、ＡＰＰ管理サーバ１６０として、ＡＰＰ−ａを管理するＡＰＰ管理サーバ１６０ａがある。
【００３２】
サーバストレージシステム１０００は、１以上のサーバ１００と１以上のストレージ１２０とを有する。サーバ１００は、ＣＰＵやメモリ等の複数のリソース（複数種類のリソース）を有するサーバシステム（１以上のサーバ装置）である。ストレージ１２０は、ＣＰＵやメモリ等の複数のリソース（複数種類のリソース）を有するストレージシステム（１以上のストレージ装置）である。サーバ１００及びストレージ１２０が１つの筺体に収納されていてもよい。
【００３３】
ＡＰＰ管理サーバ１６０が、ＡＰＰ管理プログラム１６３を実行し、例えば後述のテナント管理者により操作される。ＡＰＰ管理プログラム１６３は、サーバ１００で実行される管理対象のＡＰＰ１０４を管理する。ＡＰＰ管理サーバ１６０に、統合管理サーバ１４０により、統合ＬＰＡＲ作成画面１６２が表示される。統合ＬＰＡＲ作成画面１６２は、ＡＰＰ管理サーバ１６０の管理対象ＡＰＰ１０４についての統合ＬＰＡＲ作成画面であり、それ以外の点では、統合ＬＰＡＲ作成画面１４１と同じでよい。ＡＰＰ管理サーバ１６０は、統合ＬＰＡＲ作成画面１６２にテナント管理者により入力されたパラメータ（情報）を関連付けた統合ＬＰＡＲ作成指示を統合管理サーバ１４０に送信する。なお、ＡＰＰ管理サーバ１６０は無くてもよい。統合ＬＰＡＲ作成指示は、統合管理サーバ１４０からのみ行われてもよい。
【００３４】
統合管理サーバ１４０は、サーバ１００を管理するためのサーバ管理プログラム６６１と、ストレージ１２０を管理するためのストレージ管理プログラム６６２と、統合ＬＰＡＲの作成のための管理者入力負担を軽減する管理プログラムであるランブック自動化プログラム６６０を実行する。
【００３５】
サーバ管理プログラム６６１は、ランブック自動化プログラム６００とサーバ１００間の通信のインターフェースとして機能する。ストレージ管理プログラム６６２は、ランブック自動化プログラム６００とストレージ１２０間の通信のインターフェースとして機能する。
【００３６】
ランブック自動化プログラム６６０が、例えば、リソース割当て制御変更機能１９６、ストレージパーティション作成機能１４３、統合ＬＰＡＲ作成パラメータ生成機能１７３、統合ＬＰＡＲ作成機能１４４及びランブック自動化エンジン１８０を有する。統合ＬＰＡＲ作成機能１４４は、リソース選択機能１９１、リソース割当て機能１９２及びＯＳ（Operating  System）配信機能１９３を有する。
【００３７】
リソース割当て制御変更機能１９６は、割当て制御情報６７２の変更を管理者からの操作に従い行う機能である。
【００３８】
ストレージパーティション作成機能１４３及びランブック自動化エンジン１８０が協働してストレージパーティションを作成する。
【００３９】
具体的には、例えば、ストレージパーティション作成機能１４３が、ストレージパーティション作成画面（例えばＧＵＩ（Graphical  User  Interface）画面）１４２を、例えば統合管理サーバ１４０の表示デバイスに表示する。ストレージパーティション作成画面１４２は、ストレージパーティションの作成に必要な情報（例えばパラメータ）を入力するための画面（図１４）である。ストレージパーティション作成機能１４３が、ストレージパーティション作成画面１４２に入力された情報をランブック自動化エンジン１８０に入力する。ランブック自動化エンジン１８０は、その入力された情報に基づく設定を、ストレージ管理プログラム６６２経由でストレージ１２０に対して行う。
【００４０】
以上のように、ストレージパーティション作成機能１４３及びランブック自動化エンジン１８０が協働することで、ストレージパーティションがストレージ１２０に作成される。
【００４１】
統合ＬＰＡＲ作成パラメータ生成機能１７３、統合ＬＰＡＲ作成機能１４４及びランブック自動化エンジン１８０が協働して統合ＬＰＡＲを作成する。
【００４２】
具体的には、例えば、統合ＬＰＡＲ作成機能１４４が、統合ＬＰＡＲ作成画面（例えばＧＵＩ画面）１４１を、例えば統合管理サーバ１４０の表示デバイスに表示する、及び、統合ＬＰＡＲ作成画面１６２をＡＰＰ管理サーバ１６０に表示する、のうちの少なくとも１つを実行する。統合ＬＰＡＲ作成画面１６２は、テナント管理者に対するインターフェースとしての画面であり、統合ＬＰＡＲ作成画面１４１は、システム管理者に対するインターフェースとしての画面である。統合ＬＰＡＲ作成画面１４１（及び１６２）は、１種類以上の負荷特性情報を入力するための画面（図１７）である。統合ＬＰＡＲ作成パラメータ生成機能１７３は、統合ＬＰＡＲ作成画面１４１（又は１６２）経由で入力された１種類以上の負荷特性情報を用いて、統合ＬＰＡＲの作成に必要なパラメータ（例えば、リソース種類、割当て種類（占有割当て又は共有割当て）及びリソース量（例えばＣＰＵコア数、メモリ容量等））を、割当て制御情報６７２から取得する。ここで言う「取得」は、例えば、負荷特性情報と、負荷特性情報を用いて割当て制御情報６７２から取得された情報とのうちの少なくとも１つを基に少なくとも１つのパラメータ（統合ＬＰＡＲ作成に必要なパラメータのうちの少なくとも１つのパラメータ）を「生成」することを含んでよい。
【００４３】
リソース選択機能１９１が、取得（生成）されたパラメータに従うサーバリソース及びストレージリソースを選択する。リソース割当て機能１９２は、選択されたサーバリソース及びストレージリソースの割当てを実行する。具体的には、例えば、リソース割当て機能１９２は、選択されたサーバリソースのリソース種類及びリソース量を含んだパラメータと選択されたストレージリソースのリソース種類及びリソース量を含んだパラメータとをランブック自動化エンジン１８０に入力する。ランブック自動化エンジン１８０が、その入力されたパラメータに基づく設定を、サーバ管理プログラム６６１経由でサーバ１００に対して行ったり、ストレージ管理プログラム６６２経由でストレージ１２０に対して行ったりする。
【００４４】
以上のように、統合ＬＰＡＲ作成パラメータ生成機能１７３、統合ＬＰＡＲ作成機能１４４及びランブック自動化エンジン１８０が協働することで、統合ＬＰＡＲがサーバストレージシステム１０００に作成される。
【００４５】
なお、本実施例では、統合ＬＰＡＲの作成に加えて、作成された統合ＬＰＡＲの起動イメージを用いた起動のための設定が、その統合ＬＰＡＲに対して自動で行われる。
【００４６】
具体的には、例えば、ＯＳ配信機能１９３が、統合ＬＰＡＲが起動時に参照するファイルである起動データ（例えばスクリプトファイル）を作成し、作成した起動データを統合ＬＰＡＲのメモリ等の領域に設定する。統合ＬＰＡＲは、起動データを参照することで、統合ＬＰＡＲの起動イメージを取得し、その起動イメージを用いた起動を実行することができる。
【００４７】
或いは、例えば、ＯＳ配信機能１９３が、統合ＬＰＡＲの起動イメージを、統合ＬＰＡＲにマウントされた１以上のＶＯＬのうちのデータＶＯＬ（後述のＶＯＬ用途が「データ」であるＶＯＬ）に設定し、且つ、起動時にその起動イメージを参照するためのパスを統合ＬＰＡＲのメモリ等の領域に設定する。起動イメージ（ＯＳイメージを含む）の設定は、ＯＳ配信機能１９３が起動イメージをデータＶＯＬに書き込むことであってもよいし、ＯＳ配信機能１９３からストレージ１２０に送信されたコピー指示に応答してストレージ１２０によりコピー元ＶＯＬからコピー先ＶＯＬ（データＶＯＬ）に起動イメージがコピーされることであってもよい。
【００４８】
以上のようなＯＳ配信機能１９３により、管理者（テナント管理者又はシステム管理者）が統合ＬＰＡＲに対して起動のための設定を行う必要が無い。通常、統合ＬＰＡＲには複数のＶＯＬがマウントされ、その複数のＶＯＬのうちのいずれが起動用のＶＯＬに適しているのかは統合ＬＰＡＲのユーザからはわからないが、ＯＳ配信機能１９３によれば、統合ＬＰＡＲが作成されたときにその統合ＬＰＡＲの起動イメージがデータＶＯＬに自動で設定されるので、推奨環境の構成が容易である。
【００４９】
以下、本実施例を詳細に説明する。
【００５０】
図２５は、サーバストレージシステム１０００の構成例を示す。
【００５１】
サーバ１００、ストレージ１２０、ＡＰＰ管理サーバ１６０及び統合管理サーバ１４０が、通信ネットワーク（例えばＩＰ（Internet  Protocol）ネットワーク）２１００に接続されている。ＡＰＰ管理サーバ１６０は、通信ネットワーク２１００を介して、管理対象ＡＰＰに関しサーバ１００と通信したり、統合ＬＰＡＲの作成指示を統合管理サーバ１４０に送信したりできる。統合管理サーバ１４０は、通信ネットワーク２１００を介して、ＡＰＰ管理サーバ１６０から統合ＬＰＡＲの作成指示を受信したり、サーバストレージシステム１０００から情報（例えば、サーバ１００の構成、ストレージ１２０の構成、各リソースの稼働状況等）を収集したり、ストレージパーティションを構築したり、統合ＬＰＡＲを構築したりできる。統合管理サーバ１４０は、複数のリソースの少なくとも一部のリソースのメトリック値を通信ネットワーク２１００を介して収集し、少なくとも一部のリソースについて、占有割当てされているか共有割当てされているかと、収集されたメトリック値とを表示してもよい。なお、メトリック値の例としてはリソースの状態、性能値、負荷値、温度、使用量、等が考えられるがこれ以外でもリソースについて測定できる値であればメトリック値に含んでもよい。
【００５２】
サーバ１００は、ＮＩＣ（Network  Interface  Card）１０９、ＣＰＵ１０２、メモリ１０３、及び、ＨＢＡ（Host  Bus  Adapter）１０６を有する。サーバ１００は、ＮＩＣ１０９を介して、ＡＰＰ管理サーバ１６０及び統合管理サーバ１４０と通信できる。
【００５３】
サーバ１００には、サーバＬＰＡＲ１０１が構築される。サーバＬＰＡＲ１０１は、ＶＭ（仮想マシン）を生成するハイパバイザと生成されたＶＭとを実行してもよいし、ＶＭそれ自体であってもよい。サーバＬＰＡＲ１０１は、１以上のＣＰＵ１０２（ＣＰＵコア）と、１以上のメモリ１０３とを有し、少なくとも１つのＡＰＰ１０４を実行し、少なくとも１つのＶＯＬ（論理ボリューム）１０５を認識する。ＡＰＰ１０４は、データベース管理システム、データ分析プログラム等のプログラムでよい。ＡＰＰ１０４は、サーバＬＰＡＲ１０１が認識したＶＯＬ１０５を指定したＩ／Ｏ要求を発行することで、ＶＯＬ１０５に対してデータを入出力できる。図２５において、ＡＰＰ１０４とＶＯＬ１０５間の実線は、ＡＰＰ１０４とＶＯＬ１０５間の関連付けを示す。
【００５４】
ＨＢＡ１０６は、サーバ１００とストレージ１２０とを接続するためのインターフェースデバイスである。ＨＢＡ１０６は、ＣＴＬ（コントローラ）１０７及びポート１０８を有する。ＣＴＬは、ＨＢＡ１０６のコアに相当し、ＨＢＡ１０６を経由する要求や応答の転送を制御する。図２１において、ＶＯＬ１０５、ＣＴＬ１０７及びポート１０８間の実線は、ＶＯＬ１０５、ＣＴＬ１０７及びポート１０８間の関連付けを示す。すなわち、ＣＴＬ１０７に、ＶＯＬ１０５とポート１０８が関連付けられる。ＣＴＬ１０７は、そのＣＴＬ１０７に関連付いているポート１０８を介して、Ｉ／Ｏ要求やデータを送受信できる。
【００５５】
本実施例では、サーバ１００のリソースは、ＣＰＵコア、メモリ、ＮＩＣ１０９のポート、ＨＢＡ１０６、ＣＴＬ１０７、及び、ポート１０８である。
【００５６】
ストレージ１２０は、ＨＢＡ１２１、ＣＰＵ１２３、メモリ１２４、及び、ドライブ１２５を有する。
【００５７】
ＨＢＡ１２１は、ポート１２２を有する。図２５において、ポート１２２及び１０８間の実線は、ポート１２２及び１０８間の関連付けを表す。ストレージ１２０は、ポート１２２と、そのポート１２２に関連付いているポート１０８とを介して、サーバ１００（サーバＬＰＡＲ１０１）と通信する。例えば、ＣＰＵ１２３は、サーバ１００からポート１２２が受信したＩ／Ｏ要求に従い、そのＩ／Ｏ要求を基に特定されたドライブ１２５に対して、データの入出力を行う。メモリ１２４は、ＣＰＵ１２３により実行されるプログラムや、ドライブ１２５に対して入出力されるデータを一時記憶するキャッシュ領域や、ストレージ１２０の制御のための管理情報等を有してよい。ドライブ１２５は、物理的な記憶デバイスであり、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）である。ドライブ１２５は、例えば、ＨＤＤ（Hard  Disk  Drive）又はＳＳＤ（Solid  State  Drive)でよい。複数のドライブ１２５により、ＲＡＩＤ（Redundant  Array  of  Independent  (or  Inexpensive)  Disks）グループが構成されてよい。ＲＡＩＤグループは、そのＲＡＩＤグループに関連付けられたＲＡＩＤレベルに従いデータを記憶する。ＲＡＩＤグループは、パリティグループと呼ばれてもよい。パリティグループは、例えば、パリティを格納するＲＡＩＤグループのことでよい。
【００５８】
本実施例では、ストレージ１２０のリソースは、ＨＢＡ１２１、ポート１２２、ＣＰＵ１２３（又はＣＰＵコア）、メモリ１２４、及び、ドライブ１２５である。
【００５９】
ストレージ１２０には、Ｉ／Ｏ要求等の要求を処理する第１種のリソースと、第１種のリソースと異なる種類のリソースである第２種のリソースとがある。第１種のリソースは、要求が通るパスに関わるリソース及び要求の処理に関わるリソースのうちの少なくとも１つ、例えば、ＨＢＡ１０６のＣＴＬ１０７、ストレージ１２０のＣＰＵ１２３等である。第２種のリソースは、例えば、サーバＨＢＡポート１０８、ストレージＨＢＡポート１２２等である。
【００６０】
第１種のリソースの第２種のリソースの関係は、例えば次の通りである。すなわち、サーバＬＰＡＲ１０１からのＩ／Ｏの転送帯域が変わらずに、ＩＯＰＳ（I/O  Per  Second）のようなＩ／Ｏ頻度が増えた場合、第１種のリソースの負荷（例えば最大負荷に対する割合）が、第２種のリソースの負荷よりも大きくなる。逆に、サーバＬＰＡＲ１０１からのＩ／Ｏ頻度が変化せずに、Ｉ／Ｏの転送帯域が増えた場合、第２種のリソースの負荷が、第１種のリソースの負荷よりも大きくなる。
【００６１】
そこで、本実施例では、第１種のリソースと第２種のリソースの上記のような関係を考慮して、後述するように、ランブック自動化プログラム６６０が、複数の統合ＬＰＡＲにそれぞれ割り当てるリソースの種類又は数等を違える（言い換えれば、サーバストレージシステム１０００を論理的に分割することにより得られる複数の統合ＬＰＡＲの構成を違える）。
【００６２】
また、本実施例では、サーバ１００のリソースは、ＣＰＵ１０２、メモリ１０３、ＮＩＣ１０９、ＨＢＡ１０６、ＣＴＬ１０７、及び、ＨＢＡポート１０８である。サーバ１００のリソースとして、これらのリソースのうちの少なくとも１つに代えて少なくとも１つの他種リソースが採用されてもよい。なお、本実施例では、ＣＰＵ１０２及びメモリ１０３のうちの少なくとも１種類のリソースは、サーバＬＰＡＲ１０１に必ず占有割当てされる（言い換えれば、サーバＬＰＡＲ１０１の構成要素である）ため、占有割当てをするか共有割当てをするかの選択は行われない。
【００６３】
また、本実施例では、ストレージ１２０のリソースは、ＨＢＡ１２１、ＣＰＵ１２３、メモリ１２４（例えば特にキャッシュメモリ）、及び、ドライブ１２５（例えば、特にＲＡＩＤグループ）である。ストレージ１２０のリソースとして、これらのリソースのうちの少なくとも１つに代えて少なくとも１つの他種リソースが採用されてもよい。その他種リソースは、例えば、ＲＡＩＤグループに基づくプールでよい。プールからは、Thin  Provisioningに従い、記憶領域が、仮想的なＶＯＬに割り当てられてよい。
【００６４】
また、本実施例では、サーバ１００とストレージ１２０間の通信のプロトコルは、ＦＣ（Fibre  Channel）プロトコルであるが、他のプロトコル（例えばPCI-Express）でもよい。他のプロトコルが採用された場合、サーバ１００のＨＢＡ１０６と、ストレージ１２０のＨＢＡ１２１に代えて、それぞれ、採用されたプロトコルに従う通信のためのインターフェースデバイスが採用されてよい。インターフェースデバイスは、通常、１以上のポートを有する。インターフェースデバイスは、ポートに関連付けられた通信コントローラ（例えば制御チップ）を有してよい。通信コントローラは、ＣＴＬ１０７のように、データや要求の送受信を制御できる。
【００６５】
図２Ａは、サーバストレージシステム１０００のリソース割当て（論理分割）の幾つかの例を示す。図２Ｂは、サーバストレージシステム１０００の管理側の構成例を示す。なお、図２Ａにおいて、サーバストレージシステム１０００のリソースを表すブロックには、参照符号に代えて、名前又はＩＤが表記されている。また、図２Ａにおいて、ＶＯＬ１０５（例えばＶＯＬ−ａ）の近傍に記載の文字「Ｌ」は、Ｉ／Ｏサイズ「大」を意味し、ＶＯＬ１０５（例えばＶＯＬ−ｄ）の近傍に記載の文字「Ｓ」は、Ｉ／Ｏサイズ「小」を意味する。また、以下の説明において、「テナント」は、サーバストレージシステム１０００の統合ＬＰＡＲを使用又は管理するユーザである。「テナント管理者」とは、１以上のテナントのうちの自テナントが使用又は管理する統合ＬＰＡＲを管理する管理者であり、例えば、テナントそれ自体又はテナントにおける従業員である。「システム管理者」とは、１以上のテナントが使用又は管理する統合ＬＰＡＲが作成するサーバストレージシステム１０００全体を管理する管理者である。図２Ａに記載の参照符号２Ａ及び２Ｂと、図２Ｂに記載の参照符号２Ａ及び２Ｂは、それぞれ互いに対応している。
【００６６】
テナント管理者又はシステム管理者から入力された１種類以上の負荷特性情報と割当て制御情報６７２とに基づき、例えば以下に説明する論理分割（リソース割当て）が行われる。
【００６７】
＜１．本番系と開発系間の影響防止＞
【００６８】
１つのサーバストレージシステム１０００を、本番系としても開発系としても使用可能である。本番系は、稼働中のシステム、例えば、顧客に対して有料又は無料でサービスを実際に提供しているシステムである。一方、開発系は、開発中のシステム、例えば、サービス提供のための構成の作成途中のシステム、又は、サービスを実際に提供した場合に何らかの不具合が生じるか否か等をテストが行われるシステムである。
【００６９】
例えば、一般に、開発系については、テスト等の実行のために本番系よりも多くのサーバＬＰＡＲ１０１を生成することが望ましい。一方、本番系については、サーバＬＰＡＲ１０１の性能の確保とＡＰＰ１０４の集約度の向上を両立することが望ましい。また、開発系では、負荷テスト等の実行時に大量のＩ／Ｏを発生させることがある。大量のＩ／Ｏを発行させた場合においてもサービス提供中の本番系システムに影響を与えないことが望ましい。
【００７０】
そこで、本実施例では、参照符号２０１で示すように、本番系と開発系というように大きく状況が異なる環境の境界では、互いの影響抑止のために、ランブック自動化プログラム６６０が、サーバストレージシステム１０００を、サーバ１００からストレージ１２０にかけて論理分割する。すなわち、サーバストレージシステム１０００が、本番系として使用される第１のサーバストレージサブシステムと、開発系として使用される第２のサーバストレージサブシステムとに大別される。言い換えれば、サーバストレージシステム１０００のリソースが、それぞれ、本番系又は開発系に占有割り当てされる。この構成により、本番系の性能が開発系の影響を受けないようにすることができる。
【００７１】
また、本実施例では、ランブック自動化プログラム６６０は、本番系のリソース割当て（リソース分割）のポリシーと、開発系のリソース割当てのポリシーとを違える。これにより、本番系と開発系のそれぞれの特性に適した稼働が期待できる。例えば、本番系では、サーバＬＰＡＲ１０１の性能の確保とＡＰＰ１０４の集約度の向上を両立できるよう、リソースの種類と、そのリソースの割当て先のＬＰＡＲ（又はそのリソースの割当て先に関連付いたＬＰＡＲ）で実行されるＡＰＰ１０４の用途と、そのサーバＬＰＡＲ１０１が認識したＶＯＬ１０５の用途と、そのＡＰＰ用途及びＶＯＬ用途に対応したＩ／Ｏサイズとのうちの少なくとも１つに基づいて、リソースを占有割当てとするか共有割当てとするかが決定される。一方、開発系について、本番系よりも多くのサーバＬＰＡＲ１０１を生成することができるよう、開発系でのサーバＬＰＡＲ１０１に割り当てられるリソース（サーバＬＰＡＲ１０１を構成するＣＰＵ１０２及びメモリ１０３と、サーバＬＰＡＲ１０１が認識するＶＯＬ１０５を除く）は、全て共有リソースである。例えば、図２では、開発系では、１以上のＬＰＡＲのうちＬＰＡＲ５のみが図示されているが、複数のＬＰＡＲに、ＣＴＬ９、ＣＴＬ１０、Ｐｏｒｔ−ｅ、Ｐｏｒｔ５、ＨＢＡ３、ＣＰＵ２、Ｍｅｍ．２及びＤｒｉｖｅ２等が共有割当てされてよい。なお、開発系でも、リソースを占有割当てとするか共有割当てとするかの選択が行われてよい。
【００７２】
本実施例においては、サーバ１００からストレージ１２０にかけた論理分割として、少なくとも、サーバのＣＰＵコア、サーバメモリ、サーバＨＢＡ  ＣＴＬ、サーバＨＢＡポート、ストレージＨＢＡポート、ストレージＨＢＡ、ストレージＣＰＵ、ストレージメモリ、ストレージドライブが本番系及び開発系のいずれかに占有割り当てられることを想定する。但し、リソースの種類によっては、そのような割り当てができないこともあり得る。その場合は、一部のリソースについて、共有されることもある。また、サーバ１００からストレージ１２０にかけた論理分割は、本番系と開発系とに分割することに代えて、複数の顧客（テナント）の使用範囲を分割する等、他の基準に沿った分割にも適用されてよい。
【００７３】
＜２．本番系についてのリソース割当て＞
【００７４】
本実施例では、各論理分割において処理することになるＩ／Ｏの特性、例えばデータサイズ（Ｉ／Ｏサイズ）を参照して占有／共有とすべきリソースの選択を行うことを特徴とする。一般に、Ｉ／Ｏサイズ「大」の方がＩ／Ｏサイズ「小」よりもＩ／Ｏ対象データのサイズが大きいために、要求１つ当たりの処理負荷が大きい。こうした特性の差異によって、負荷がかかるリソース種別が異なる。よって、本実施例においては、処理することになるＩ／Ｏの特性を考慮することで、占有すべきリソース種別を決定することとする。一方、単位時間当たりの処理負荷は、Ｉ／Ｏサイズ「小」の方がＩ／Ｏサイズ「大」よりも大きい傾向にある。Ｉ／Ｏサイズ「小」のＩ／Ｏ要求は、Ｉ／Ｏサイズ「大」のＩ／Ｏ要求よりも多く単位時間当たりに発行可能だからである。
【００７５】
また、リソース毎に特性も異なる。例えば、Ｉ／Ｏの転送帯域が変わらずにＩ／Ｏ頻度が増えた場合、第１種のリソースへの負荷が、第２種のリソースへの負荷よりも大きくなる。また、例えば、論理区画からのＩ／Ｏの頻度が変化せずにＩ／Ｏの転送帯域が増えた場合、第２種のリソースの負荷が、第１種のリソースの負荷よりも大きくなることがある。
【００７６】
＜２−１．Ｉ／Ｏサイズ「大」間の影響の防止＞
【００７７】
上述したように、本番系と開発系のうち少なくとも本番系について、各種のリソースについてを占有割当てとするか共有割当てとするかが選択される。参照符号２０２及び２０３に示すように、それぞれＩ／Ｏサイズ「大」に関連付いた複数のサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に、少なくとも、サーバＨＢＡポート１０８、及び、ストレージＨＢＡポート１２２が共有されない。言い換えれば、それぞれＩ／Ｏサイズ「大」に関連付いた複数のサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に、異なる複数のサーバＨＢＡポート１０８、及び、異なる複数のストレージＨＢＡポート１２２が、それぞれ割り当てられる（例えば占有割当てされる）。具体的には、例えば、Ｉ／Ｏサイズ「大」に関連付いたＬＰＡＲ１（又は、ＡＰＰ−ａ又はＶＯＬ−ａ）に、Ｐｏｒｔ−ａ及びＰｏｒｔ１が割り当てられ、Ｉ／Ｏサイズ「大」に関連付いた別のＬＰＡＲ２（又は、ＡＰＰ−ｂ又はＶＯＬ−ｂ）に、Ｐｏｒｔ−ｂ（Ｐｏｒｔ−ａと異なるサーバＨＢＡポート）及びＰｏｒｔ２（Ｐｏｒｔ１と異なるストレージＨＢＡポート）が割り当てられる。
【００７８】
特に大サイズＩ／Ｏの処理に際しては、他のリソースの性能と比較してポートの性能は低いため、１ポート当たりの帯域がボトルネックになりやすい。これに対して、上記構成により、サーバＨＢＡポート１つ当たりの帯域、及び、ストレージＨＢＡポート１つ当たりの帯域が、過負荷になっても、Ｉ／Ｏサイズ「大」及び「大」のうちの他方についてサーバＨＢＡポート及びストレージＨＢＡポートが、その過負荷の影響を受けないで済む。結果として、Ｉ／Ｏサイズ「大」間で悪影響が生じないようにすることができる。
【００７９】
なお、ここでは、ストレージＨＢＡ１２１は、それぞれＩ／Ｏサイズが「大」である複数のＶＯＬ１０５で共有されてよい。図２の例によれば、Ｉ／Ｏサイズ「大」のＶＯＬ−ａ、ＶＯＬ−ｂ及びＶＯＬ−ｃ（ＬＰＡＲ１〜ＬＰＡＲ３）に、ストレージＨＢＡ１が共有される。それぞれＩ／Ｏサイズが「大」である複数のＶＯＬ１０５でストレージＨＢＡ１２１が共有されることは、例えば、割当てポリシーテーブル１４６に定義されている（図４参照）。
【００８０】
また、サーバＨＢＡポート１０８の上位リソースであるＣＴＬ１０７も、それぞれＩ／Ｏサイズ「大」に関連付いた複数のサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に共有されないよう割当てられてよい。サーバストレージシステム１０００のリソースは、依存関係、例えば階層的なトポロジー構成（ルートは存在しないでよい）を有する。対象リソースの上位にあるリソースのうち、対象リソースの１つ上位のリソースを、「親リソース」と言い、対象リソースの下位にあるリソースのうち、対象リソースの１つ下位のリソースを「子リソース」と言うことができる。リソースの「上位／下位」又は「親／子」の概念は、何を管理（例えば監視）する立場であるかによって違い得るが、所定の基準に沿って定義されていてよい。例えば、リソース間が「接続関係」の場合、一方のリソースが下位であり、一方のリソースに依存する（一方のリソースをベースとする）他方のリソースが上位でよい。リソース間が「包含関係」の場合、一方のリソースが下位であり、一方のリソースを包含する他方のリソースが上位でよい。
【００８１】
＜２−２．Ｉ／Ｏサイズ「大」とＩ／Ｏサイズ「小」間の影響の防止＞
【００８２】
参照符号２０４に示すように、Ｉ／Ｏサイズは「大」と関連付けられたサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）と、Ｉ／Ｏサイズは「小」と関連付けられたサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に、少なくとも、サーバＨＢＡ  ＣＴＬ１０７、及び、ストレージＨＢＡ１２１が共有されない。言い換えれば、Ｉ／Ｏサイズ「大」に関連付いたサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）と、Ｉ／Ｏサイズ「小」に関連付いたサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に、異なる複数のサーバＨＢＡ  ＣＴＬ１０７、及び、異なる複数のストレージＨＢＡ１２１が、それぞれ割り当てられる（例えば占有割当てされる）。具体的には、例えば、Ｉ／Ｏサイズ「大」に関連付いたＶＯＬ−ｃに、ＣＴＬ５及び６と、ＨＢＡ１が割り当てられる。Ｉ／Ｏサイズ「小」に関連付いたＶＯＬ−ｄに、ＣＴＬ７（ＣＴＬ５及び６と異なるサーバＨＢＡ  ＣＴＬ）と、ＨＢＡ２（ＨＢＡ１と異なるストレージＨＢＡ）が割り当てられる。
【００８３】
上述のように、一般に、Ｉ／Ｏサイズ「大」の方がＩ／Ｏサイズ「小」よりもＩ／Ｏ対象データのサイズが大きいために、要求１つ当たりのＣＴＬにかかる処理負荷が大きい。よって、Ｉ／Ｏサイズが異なるサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に、異なるサーバＨＢＡ  ＣＴＬ１０７、及び、異なるストレージＨＢＡ１２１が割り当てることで、Ｉ／Ｏサイズ「大」及び「小」のうちの一方、特に「大」のリソースが高負荷になっても、他方についてのサーバＨＢＡ  ＣＴＬ１０７、及び、異なるストレージＨＢＡ１２１が、その高負荷の影響を受けることを防止できる。
【００８４】
なお、ストレージＨＢＡが、サーバＨＢＬのように、占有割当て可能なＣＴＬ（ＨＢＡコア）を有している場合、ストレージＨＢＡ単位の割り当てに代えて、ストレージＨＢＡ  ＣＴＬ単位で、Ｉ／Ｏサイズ「大」に関連付いたサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）と、Ｉ／Ｏサイズ「小」に関連付いたサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）への割り当てが、制御されてよい。
【００８５】
＜２−３．Ｉ／Ｏサイズ「小」間の影響の防止＞
【００８６】
参照符号２０５に示すように、それぞれＩ／Ｏサイズ「小」に関連付いた複数のサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に、少なくとも、サーバＨＢＡ  ＣＴＬ１０７が共有されない。言い換えれば、それぞれＩ／Ｏサイズ「小」に関連付いた複数のサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に、異なる複数のサーバＨＢＡ  ＣＴＬ１０７が、それぞれ割り当てられる（例えば占有割当てされる）。具体的には、例えば、Ｉ／Ｏサイズ「小」に関連付いたＬＰＡＲ３（又は、ＡＰＰ−ｃ又はＶＯＬ−ｄ）に、ＣＴＬ７が割り当てられ、Ｉ／Ｏサイズ「小」に関連付いた別のＬＰＡＲ４（又は、ＡＰＰ−ｄ又はＶＯＬ−ｅ／ＶＯＬ−ｆ）に、ＣＴＬ８（ＣＴＬ７と異なるサーバＨＢＡ  ＣＴＬ）が割り当てられる。
【００８７】
Ｉ／Ｏサイズが小さい場合には、単位時間あたりに処理されるＩ／Ｏ数が多くなる傾向にあるためにＨＡＢ  ＣＴＬへの負荷が大きくなる。上記のようにＨＢＡ  ＣＴＬをそれぞれに占有させることで、Ｉ／Ｏサイズ「小」及び「小」のうちの一方について、サーバＨＢＡ  ＣＴＬが過負荷になっても、Ｉ／Ｏサイズ「小」及び「小」のうちの他方についてのサーバＨＢＡ  ＣＴＬが、その過負荷の影響を受けないで済む。結果として、Ｉ／Ｏサイズ「小」間で悪影響が生じないようにすることができる。
【００８８】
なお、ストレージＨＢＡ１２１及びストレージＨＢＡポート１２２は、それぞれＩ／Ｏサイズが「小」である複数のＶＯＬ１０５で共有されてよい。図２の例によれば、Ｉ／Ｏサイズ「小」のＶＯＬ−ｄ、ＶＯＬ−ｅ及びＶＯＬ−ｆに、ストレージＨＢＡ２及びＰｏｒｔ４が共有される。それぞれＩ／Ｏサイズが「小」である複数のＶＯＬ１０５でストレージＨＢＡ１２１及びストレージＨＢＡポート１２２が共有されることは、例えば、割当てポリシーテーブル１４６に定義されている（図４参照）。
【００８９】
別の言い方をすれば、Ｉ／Ｏサイズ「小」間については、サーバＨＢＡポートやストレージＨＢＡポートまで違える（例えば占有割当てとする）必要は無い。なぜなら、Ｉ／Ｏサイズ「小」の場合、ポートより先にストレージ１２０のＣＰＵ１２３がＩ／Ｏ性能のボトルネックになるためである。
【００９０】
以上、Ｉ／Ｏサイズの観点で行われるリソース割当ての幾つかの例を説明した。
【００９１】
Ｉ／Ｏサイズに代えて、Ｉ／Ｏ数の多さＩ／Ｏ数のばらつき等の他種のＩ／Ｏ特性、ＡＰＰ用途及びＶＯＬ用途のうちの少なくとも１つに基づいて、リソース割当てが行われてよい。例えば、Ｉ／Ｏ数が多いＡＰＰにはドライブを占有割当てすることが挙げられる。
【００９２】
上述のリソース割当ては、統合管理サーバ１４０のランブック自動化プログラム６６０により、統合管理サーバ１４０が記憶する管理情報（特に割当て制御情報６７２）に基づいて行われる。具体的には、例えば、ランブック自動化プログラム６６０は、１種類以上の負荷特性情報（例えば、後述するように、ＡＰＰ  ＩＤ、ＡＰＰ特性、環境（本番又は開発）、統合ＬＰＡＲサイズ（Ｓ、Ｍ又はＬ））の入力を管理者から受け付け、その１種類以上の負荷特性情報と管理情報内の割当て制御情報６７２とに基づいて、下記の（例１）〜（例８）のうちの少なくとも１つを実現可能である。言い換えれば、割当て制御情報６７２が、下記の（例１）〜（例８）のうちの少なくとも１つを実現可能なのような構成の情報である。
（例１）２以上のＬＰＡＲの各々では、ストレージ１２０により提供されたＶＯＬに対するＩ／Ｏ要求を発行するＡＰＰが実行されるようになっている。２以上のＬＰＡＲの各々について、そのＬＰＡＲの負荷特性は、そのＬＰＡＲへ提供されたＶＯＬへのＩ／Ｏの特性であるＩ／Ｏ特性である。
（例２）（例１）において、２以上のＬＰＡＲの各々について、そのＬＰＡＲのＩ／Ｏ特性は、そのＬＰＡＲにおいて発行されるＩ／Ｏ要求に付随するＩ／Ｏ対象データのサイズであるＩ／Ｏサイズを含む。
（例３）（例１）において、２以上のＬＰＡＲの各々について、そのＬＰＡＲのＩ／Ｏ特性は、そのＬＰＡＲで実行されるＡＰＰの用途の入力と、そのＡＰＰによるＩ／Ｏ先のＶＯＬの用途の入力とに基づき決定された特性である。
（例４）（例１）〜（例３）のいずれかにおいて、複数のサーバリソースが、ストレージ１２０に接続される１以上の第１インターフェースデバイスの１以上のコントローラ（ＣＴＬ）と、１以上の第１インターフェースデバイスの１以上の第１ポートとを含む。複数のストレージリソースが、サーバ１００に接続される１以上の第２インターフェースデバイスと、１以上の第２インターフェースデバイスの１以上の第２ポートとを含む。ＣＴＬ、第１ポート、第２インターフェースデバイス及び第２ポートのうちの少なくとも１つについて、２以上のＬＰＡＲの各々に対して占有割当てか共有割当てかは、そのＬＰＡＲへ提供されたＶＯＬのＩ／Ｏサイズに依存している。
（例５）（例４）において、Ｉ／Ｏサイズが大きいとされた２以上のＶＯＬが提供されたＬＰＡＲには、異なるＣＴＬ、異なる第１ポート、及び、異なる第２ポートが割り当てられ、第２インターフェースデバイスが共有割当てされる。共有割当てされる第２インターフェースデバイスは、同Ｉ／ＯサイズのＶＯＬが提供されたＬＰＡＲに共有される。
（例６）（例４）又は（例５）において、Ｉ／Ｏサイズが大きいとされたＶＯＬが提供されたＬＰＡＲとＩ／Ｏサイズが小さいとされたＶＯＬが提供されたＬＰＡＲには、異なるＣＴＬ、及び、異なる第２インターフェースデバイスが割り当てられる。
（例７）（例４）において、それぞれＩ／Ｏサイズが小さいとされたＶＯＬが提供された２以上のＬＰＡＲには、異なるＣＴＬが割り当てられ、第１ポート、第２ポート及び第２インターフェースデバイスが共有割当てされる。共有割当てされる第２インターフェースデバイス及び第２ポートは、それぞれ、同Ｉ／ＯサイズのＶＯＬが提供されたＬＰＡＲに共有される。
（例８）サーバストレージシステム１０００が、サーバ１００からストレージ１２０にかけて論理分割されることにより得られた複数のサブシステムを有する。複数のサブシステムのうちの第１サブシステムが、本番環境に属するサブシステムである本番系である。複数のサブシステムのうちの第２サブシステムが、開発環境に属するサブシステムである開発系である。本番系が、２以上のＬＰＡＲを有する。
【００９３】
以上のようなリソース割当ての実行に関し、図２Ｂに示すように、ランブック自動化プログラム６６０は、テナント管理者に対して許可する操作とシステム管理者に対して許可する操作を違える。図２Ａ及び図２Ｂによれば、ランブック自動化プログラム６６０は、テナントＡ〜Ｃのテナント管理者に対してそれぞれ統合ＬＰＡＲ作成画面１６２ａ〜１６２ｃを提供し、システム管理者に対して統合ＬＰＡＲ作成画面１４１を提供する。ランブック自動化プログラム６６０は、システム管理者に対しては、テナントＡ〜Ｃのいずれについての統合ＬＰＡＲの作成又は構成変更等を許可する。一方、ランブック自動化プログラム６６０は、テナント管理者に対しては、そのテナント管理者に対応したテナントにより使用又は管理される統合ＬＰＡＲについてのみ統合ＬＰＡＲの作成又は構成変更等を許可するが、他のテナントにより使用又は管理される統合ＬＰＡＲについては統合ＬＰＡＲの作成又は構成変更等を拒否する。
【００９４】
以下、統合管理サーバ１４０の詳細を説明する。
【００９５】
図２６は、統合管理サーバ１４０の構成例を示す。
【００９６】
統合管理サーバ１４０は、入力デバイス（例えばキーボード及びポインティングデバイス）６１０と、表示デバイス６２０と、ＮＩＣ６５０と、コンピュータプログラム及び情報を記憶する記憶部（例えばメモリ）６３０と、それらに接続されたＣＰＵ６４０とを有する。入力デバイス６１０及び表示デバイス６２０は、タッチパネルのように一体であってもよい。統合管理サーバ１４０は、入力デバイス６１０及び表示デバイス６２０に代えて、入力デバイス及び表示デバイスを有する表示用計算機（例えば、システム管理者が操作するパーソナルコンピュータ）に接続されていてもよい。記憶部６３０が記憶するコンピュータプログラムは、例えば、サーバ管理プログラム６６１、ストレージ管理プログラム６６２、ランブック自動化プログラム６６０であり、それがＣＰＵ６４０により実行される。記憶部６３０が記憶する情報は、例えば、管理情報６７０である。管理情報６７０は、サーバストレージシステム１０００の管理のために参照又は更新される情報であり、統合ＬＰＡＲの作成（構成の決定等）のために参照される割当て制御情報６７２を含む。具体的には、例えば、管理情報６７０は、Ｉ／Ｏサイズテーブル１４５（図３）、割当てポリシーテーブル１４６（図４）、統合ＬＰＡＲサイズテンプレートテーブル１４７（図５）、ＶＯＬテンプレートテーブル１４８（図６）、統合ＬＰＡＲテーブル１４９（図７）、サーバＬＰＡＲテーブル１５０（図８）、サーバＬＰＡＲ／ＨＢＡテーブル１５１（図９）、サーバＨＢＡテーブル１５２（図１０）、ストレージＨＢＡテーブル１５３（図１１）、サーバ／ストレージ接続テーブル１５４（図１２）、ストレージパーティションテーブル１５５（図１３）、及び、ストレージパーティションサイズテンプレートテーブル１５６を含む。本実施例では、割当て制御情報６７２は、テーブル１４５〜１４８、１５５及び１５６で構成されているが、それらのテーブルのうちの一部を含んでいなくてもよいし、別のテーブルのうちの少なくとも一部を含んでいてもよい。
【００９７】
以下、管理情報６７０に含まれる各テーブルを説明する。
【００９８】
図３は、Ｉ／Ｏサイズテーブル１４５の構成例を示す。
【００９９】
Ｉ／Ｏサイズテーブル１４５は、ＡＰＰ名、ＡＰＰ用途及びＶＯＬ用途とＩ／Ｏサイズとの関係を示す。Ｉ／Ｏサイズは、ＡＰＰ１０４からのＩ／Ｏ要求（ＶＯＬ１０５を指定したＩ／Ｏ要求）に付随するＩ／Ｏ対象データのサイズ（例えば平均サイズ）である。Ｉ／Ｏサイズは、ＡＰＰ１０４及びＶＯＬ１０５のうちの少なくとも１つについてのＩ／Ｏ特性の一例である。統合ＬＰＡＲの作成のために考慮されるＩ／Ｏ特性としては、Ｉ／Ｏサイズに代えて又は加えて、リード／ライト比（リード要求の数とライト要求の数との比）と、シーケンシャル／ランダム比（シーケンシャルＩ／Ｏの回数とランダムＩ／Ｏの回数との比）と、ロカリティ（連続したアドレス範囲にＩ／Ｏが集中する集中Ｉ／Ｏと、分散したアドレス範囲に対するＩ／Ｏである分散Ｉ／Ｏのどちらが多いか）とのうちの少なくとも１つを採用できる。Ｉ／Ｏサイズと、Ｉ／Ｏサイズ以外のいずれかの種類のＩ／Ｏ特性との組合せを、統合ＬＰＡＲ作成の際に考慮する場合、ランブック自動化プログラム６６０は、Ｉ／Ｏサイズを他種のＩ／Ｏ特性よりも優先して考慮することができる。
【０１００】
Ｉ／Ｏサイズテーブル１４５は、ＡＰＰ１０４毎に、エントリを有する。各エントリに格納される情報は、ＡＰＰ名（もしくは、ＡＰＰを特定するための他種のＡＰＰ識別情報）３０１、ＡＰＰ用途３０２、ＶＯＬ用途３０３、及び、Ｉ／Ｏサイズ３０４である。ＡＰＰ名３０１は、ＡＰＰ１０４の名前を示す。ＡＰＰ用途３０２は、ＡＰＰ１０４の用途を示す。ＶＯＬ用途３０３は、ＡＰＰ１０４に関連付いたＶＯＬ１０５の用途を示す。Ｉ／Ｏサイズ３０４は、ＡＰＰ１０４からＶＯＬ１０５へのＩ／Ｏ対象データのサイズであるＩ／Ｏサイズを示す。
【０１０１】
本実施例では、ＡＰＰ用途として、ＯＬＴＰ（Online  Transaction  Processing）及びＯＬＡＰ（Online  Analytical  Processing）のいずれかが採用される。ＡＰＰ用途として、他種の用途が採用されてもよい。
【０１０２】
また、本実施例では、ＶＯＬ用途として、データ格納用及びログ格納用のいずれかが採用される。ＶＯＬ用途として、他種の用途が採用されてもよい。
【０１０３】
また、本実施例では、Ｉ／Ｏサイズ３０４の値として、Ｉ／Ｏサイズが比較的大きい（例えば所定の閾値以上である）ことを意味する「大」と、Ｉ／Ｏサイズが比較的小さい（例えば所定の閾値未満である）ことを意味する「小」のいずれかが採用される。Ｉ／Ｏサイズ３０４の値は、大小の２段階よりも多段階（例えば大中小の３段階）が採用されてもよい。Ｉ／Ｏサイズテーブル１４５によれば、ＡＰＰ名３０１、ＡＰＰ用途３０２及びＶＯＬ用途３０３の組により、Ｉ／Ｏサイズ３０４の値が決まる。
【０１０４】
図４は、割当てポリシーテーブル１４６の構成例を示す。
【０１０５】
割当てポリシーテーブル１４６は、Ｉ／Ｏサイズに応じたリソース割当てのポリシーを示す。割当てポリシーテーブル１４６は、割当てポリシー毎にエントリを有する。各エントリに格納される情報は、Ｉ／Ｏサイズ４０１、サーバＨＢＡ  ＣＴＬ４０２、サーバＨＢＡポート４０３、ストレージＨＢＡポート４０４、ストレージＨＢＡ４０５、ストレージＣＰＵ４０６、ストレージメモリ４０７、及び、ストレージドライブ４０８である。
【０１０６】
Ｉ／Ｏサイズ４０１は、Ｉ／Ｏサイズを示す。サーバＨＢＡ  ＣＴＬ４０２は、ＣＴＬ１０７の割当て方式を示す。サーバＨＢＡポート４０３は、ポート１０８の割当て方式を示す。ストレージＨＢＡポート４０４は、ポート１２２の割当て方式を示す。ストレージＨＢＡ４０５は、ＨＢＡ１２１の割当て方式を示す。ストレージＣＰＵ４０６は、ＣＰＵ１２３の割当て方式を示す。ストレージメモリ４０７は、メモリ１２４の割当て方式を示す。ストレージドライブ４０８は、ドライブ１２５の割当て方式を示す。
【０１０７】
割当てポリシーテーブル１４６において、「占有」は、リソースを占有割当てすることを意味する。「共有」は、共有割当てすることを意味する。「同Ｉ／ＯサイズＶＯＬ間で共有」は、Ｉ／Ｏサイズが同じ複数のＶＯＬに対して共有割当てすること（言い換えれば、Ｉ／Ｏサイズが異なる複数のＶＯＬから共有されないように割当てること）を意味する。
【０１０８】
Ｉ／Ｏサイズが「大」の場合、サーバＨＢＡ１０６のポート１０８とストレージＨＢＡ１２１のポート１２２がボトルネックになり易い。そこで、割当てポリシーテーブル１４６によれば、Ｉ／Ｏサイズ「大」のＶＯＬに、サーバＨＢＡ１０６のＣＴＬ１０７、サーバＨＢＡ１０６のポート１０８、及び、ストレージＨＢＡ１２１のポート１２２の各々が、占有割当てされる。
【０１０９】
一方、Ｉ／Ｏサイズが「小」の場合、サーバＨＢＡ１０６のポート１０８とストレージＨＢＡ１２１のポート１２２は、ボトルネックになりにくい。しかし、サーバＨＢＡ１０６のＣＴＬ１０７が共有リソースであると、サーバＨＢＡ１０６のポート１０８を共有する他の負荷の影響を受ける。そこで、割当てポリシーテーブル１４６によれば、Ｉ／Ｏサイズが「小」のＶＯＬに、サーバＨＢＡ１０６のポート１０８とストレージＨＢＡ１２１のポート１２２が、それぞれ共有割当てされ、サーバＨＢＡ１０６のＣＴＬ１０７が、占有割当てされる。
【０１１０】
本実施例では、ストレージＨＢＡ１２１のＣＴＬ（図示せず）を制御できない。よって、ストレージＨＢＡ１２１のＣＴＬは共有される。ストレージＨＢＡ１２１のＣＴＬが共有されている場合、Ｉ／Ｏサイズ「小」の負荷は、Ｉ／Ｏサイズ「大」の負荷から大きく影響を受け得る。このため、ストレージＨＢＡ１２１を論理的に分割することが望ましい。よって、割当てポリシーテーブル１４６によれば、ストレージＨＢＡ１２１に関しては、同Ｉ／Ｏサイズの複数のＶＯＬに対して共有割当てがされる。
【０１１１】
なお、ストレージＨＢＡ１２１のＣＴＬについて占有割当てが可能な場合、割当てポリシーテーブル１４６に、ストレージＨＢＡ１２１を論理的に分割する設定がされないでもよい。また、サーバＨＢＡ１０６のＣＴＬ１０７について占有割当てが不可能な場合、割当てポリシーテーブル１４６に、サーバＨＢＡ１０６を論理的に分割する設定がされてもよい。
【０１１２】
図５は、統合ＬＰＡＲサイズテンプレートテーブル１４７の構成例を示す。
【０１１３】
統合ＬＰＡＲサイズテンプレートテーブル１４７は、統合ＬＰＡＲに割当てるサーバリソースの量を示す。統合ＬＰＡＲサイズテンプレートテーブル１４７は、統合ＬＰＡＲサイズのテンプレート毎にエントリを有する。各エントリに格納される情報は、統合ＬＰＡＲサイズ５０１、ＬＰＡＲ  ＣＰＵコア数５０２、ＬＰＡＲメモリ容量５０３、ＬＰＡＲ  ＮＩＣポート数５０４、Ｉ／Ｏサイズ５０５、ＨＢＡポート数５０６、及び、サーバＨＢＡ  ＣＴＬ数５０７である。
【０１１４】
統合ＬＰＡＲサイズ５０１は、統合ＬＰＡＲのサイズを示す。統合ＬＰＡＲサイズ５０１の値として、大中小（Ｌ／Ｍ／Ｓ）の３種類があるが、値は、２種類でも４種類以上でもよい。ＬＰＡＲ  ＣＰＵコア数５０２は、サーバＬＰＡＲ１０１に割当てるＣＰＵコア数（ＣＰＵ１０２のコアの数）を示す。ＬＰＡＲメモリ容量５０３は、サーバＬＰＡＲ１０１に割当てるメモリ１０３の容量を示す。
ＬＰＡＲ  ＮＩＣポート数５０４は、サーバＬＰＡＲ１０１に割当てるＮＩＣポート（ＮＩＣ１０９のポート）の数を示す。Ｉ／Ｏサイズ５０５は、サーバＬＰＡＲ１０１におけるＡＰＰ１０４及びＶＯＬ１０５に対応したＩ／Ｏサイズを示す。ＨＢＡポート数５０６は、サーバＬＰＡＲ１０１に関連付けられるＨＢＡポート１０８の数を示す。サーバＨＢＡ  ＣＴＬ数５０７は、サーバＬＰＡＲ１０１に関連付けられるＣＴＬ１０７の数を示す。
【０１１５】
図６は、ＶＯＬテンプレートテーブル１４８の構成例を示す。
【０１１６】
ＶＯＬテンプレートテーブル１４８は、ＡＰＰ名、ＡＰＰ用途、ＶＯＬ用途及び統合ＬＰＡＲサイズと、ＶＯＬ容量及びＶＯＬ数との関係を示す。ＶＯＬテンプレートテーブル１４８は、ＶＯＬテンプレート毎にエントリを有する。各エントリに格納される情報は、ＡＰＰ名６０１、ＡＰＰ用途６０２、ＶＯＬ用途６０３、統合ＬＰＡＲサイズ６０４、ＶＯＬ容量６０５及びＶＯＬ数６０６である。ＡＰＰ名６０１、ＡＰＰ用途６０２、ＶＯＬ用途６０３、及び、統合ＬＰＡＲサイズ６０４については、上述の通りである。ＶＯＬ容量６０５は、ＶＯＬ１０５の容量を示す。ＶＯＬ数６０６は、ＶＯＬ１０５の数を示す。
【０１１７】
図７は、統合ＬＰＡＲテーブル１４９の構成例を示す。
【０１１８】
統合ＬＰＡＲテーブル１４９は、統合ＬＰＡＲに関する情報を示す。統合ＬＰＡＲテーブル１４９は、統合ＬＰＡＲ毎にエントリを有する。各エントリに格納される情報は、統合ＬＰＡＲ  ＩＤ７０１、環境７０２、ＡＰＰ名７０３、ＡＰＰ用途７０４、及び、統合ＬＰＡＲサイズ７０６である。
【０１１９】
統合ＬＰＡＲ  ＩＤ７０１は、統合ＬＰＡＲのＩＤを示す。統合ＬＰＡＲのＩＤは、その統合ＬＰＡＲに含まれるサーバＬＰＡＲのＩＤと同じ値でよい。環境７０２は、統合ＬＰＡＲが再配置される環境であるＬＰＡＲ環境（本番環境と開発環境のいずれであるか）を示す。ＡＰＰ名７０３は、統合ＬＰＡＲで実行されるＡＰＰの名前を示す。ＡＰＰ用途７０４は、その実行されるＡＰＰの用途を示す。統合ＬＰＡＲサイズ７０６は、統合ＬＰＡＲのサイズを示す。
【０１２０】
図８は、サーバＬＰＡＲテーブル１５０の構成例を示す。
【０１２１】
サーバＬＰＡＲテーブル１５０は、サーバＬＰＡＲ１０１の構成を表す。サーバＬＰＡＲテーブル１５０は、サーバＬＰＡＲ１０１毎にエントリを有する。各エントリに格納される情報は、ＬＰＡＲ  ＩＤ８０１、サーバＩＤ８０２、ＣＰＵコア数８０３、メモリ容量８０４、ＮＩＣポート数８０５及びＮＩＣポート割当て８０６である。
【０１２２】
ＬＰＡＲ  ＩＤ８０１は、サーバＬＰＡＲ１０１のＩＤを示す。サーバＩＤ８０２は、サーバＬＰＡＲ１０１が動作するサーバ１００のＩＤを示す。ＣＰＵコア数８０３は、サーバＬＰＡＲ１０１に割当てられているＣＰＵ１０２のコア数を示す。メモリ容量８０４は、サーバＬＰＡＲ１０１に割当てられているメモリ１０３の容量を示す。ＮＩＣポート数８０５は、サーバＬＰＡＲ１０１に割当てられているＮＩＣ１０９のポート数を示す。ＮＩＣポート割当て８０６は、ＮＩＣ１０９のポートがサーバＬＰＡＲ１０１に占有割当てされているか、共有割当てされているかを示す。
【０１２３】
図９は、サーバＬＰＡＲ／ＨＢＡテーブル１５１の構成例を示す。
【０１２４】
サーバＬＰＡＲ／ＨＢＡテーブル１５１は、サーバＬＰＡＲ１０１とサーバＨＢＡ１０６との関係を示す。サーバＬＰＡＲ／ＨＢＡテーブル１５１は、サーバＬＰＡＲ１０１毎にエントリを有する。各エントリに格納される情報は、ＬＰＡＲ  ＩＤ９０１、ＨＢＡポート数９０２、ＨＢＡポート割当て９０３、ＨＢＡ  ＣＴＬ数９０４、及び、ＨＢＡ  ＣＴＬ割当て９０５である。
【０１２５】
ＬＰＡＲ  ＩＤ９０１は、サーバ１００のサーバＬＰＡＲ１０１のＩＤを示す。ＨＢＡポート数９０２は、サーバＬＰＡＲ１０１に割当てられたサーバＨＢＡポート１０８の数を示す。ＨＢＡポート割当て９０３は、ポート１０８の割当て状態（占有割当て又は共有割当て）を示す。ＨＢＡ  ＣＴＬ数９０４は、サーバＬＰＡＲ１０１に割当てられたＣＴＬ１０７の数を示す。ＨＢＡ  ＣＴＬ割当て９０５は、ＣＴＬ１０７の割当て状態（占有割当て又は共有割当て）を示す。
【０１２６】
図１０は、サーバＨＢＡテーブル１５２の構成例を示す。
【０１２７】
サーバＨＢＡテーブル１５２は、サーバＨＢＡ１０６に関する情報である。サーバＨＢＡテーブル１５２は、サーバＨＢＡ  ＣＴＬ１０７毎にエントリを有する。各エントリに格納される情報は、サーバＩＤ１００１、ＨＢＡ  ＩＤ１００２、ポートＩＤ１００３、ポート割当て１００４、ＣＴＬ  ＩＤ１００５、ＣＴＬ割当て１００６、Ｉ／Ｏサイズ１００７、割当先１００８、及び、環境１００９である。
【０１２８】
サーバＩＤ１００１は、サーバ１００のＩＤを示す。ＨＢＡ  ＩＤ１００２は、ＨＢＡ１０６のＩＤを示す。ポートＩＤ１００３は、ポート１０８のＩＤを示す。ポート割当て１００４は、ポート１０８の割当て状態（占有割当て、共有割当て又は未割当て）を示す。ＣＴＬ  ＩＤ１００５は、ＣＴＬ１０７のＩＤを示す。ＣＴＬ割当て１００６は、ＣＴＬ１０７の割当て状態（占有割当て、共有割当て又は未割当て）を示す。Ｉ／Ｏサイズ１００７は、ＣＴＬ１０７に関連付けられているＶＯＬ１０５のＩ／Ｏサイズを示す。割当先１００８は、ＣＴＬ１０７の割当先サーバＬＰＡＲ１０１のＩＤを示す（割当先が無ければ「未割当て」が設定されてよい）。環境１００９は、ＨＢＡ１０６が属する環境（本番又は開発）を示す。
【０１２９】
図１１は、ストレージＨＢＡテーブル１５３の構成例を示す。
【０１３０】
ストレージＨＢＡテーブル１５３は、ストレージＨＢＡ１２１に関する情報である。ストレージＨＢＡテーブル１５３は、ストレージＨＢＡポート１２２毎にエントリを有する。各エントリに格納される情報は、ストレージＩＤ１１０１、ＨＢＡ  ＩＤ１１０２、ポートＩＤ１１０３、ポート割当て１１０４、Ｉ／Ｏサイズ１１０５、割当先１１０６、及び、環境１１０７である。
【０１３１】
ストレージＩＤ１１０１は、ストレージ１２０のＩＤを示す。ＨＢＡ  ＩＤ１１０２は、ＨＢＡ１２１のＩＤを示す。ポートＩＤ１１０３は、ポート１２２のＩＤを示す。ポート割当て１１０４は、ポート１２２の割当て状態（占有割当て、共有割当て又は未割当て）を示す。Ｉ／Ｏサイズ１１０５は、ＨＢＡ１２１に関連付いているＶＯＬ１０５のＩ／Ｏサイズを示す。割当先１１０６は、ポート１２２の割当先サーバＬＰＡＲ１０１のＩＤを示す（割当先が無い場合、「未割当て」でよい）。環境１１０７は、ＨＢＡ１２１が属する環境（本番又は開発）を示す。
【０１３２】
１つのストレージＨＢＡ１２１に、異なるＩ／Ｏサイズが関連付けられないよう制御される。例えば、ＨＢＡ１２１のいずれか１つのポート１２２（第１ポート１２２）がサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に割り当てられた場合、第１ポート１２２、及び、第１ポート１２２を有するＨＢＡ１２１の全ての他のポート１２２の各々について、Ｉ／Ｏサイズ１１０５として、第１ポート１２２が割り当てられたサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に対応したＩ／Ｏサイズ（「大」又は「小」）が設定されてよい。或いは、例えば、ＨＢＡ１２１の第１ポート１２２がサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に割り当てられた場合、第１ポート１２２について、Ｉ／Ｏサイズ１１０５として、第１ポート１２２が割り当てられたサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）に対応したＩ／Ｏサイズ（「大」又は「小」）が設定され、その後、第１ポート１２２を有するＨＢＡ１２１の全ての他のポート１２２の各々に、ランブック自動化プログラム６６０により、他のＩ／ＯサイズのサーバＬＰＡＲ１０１（又は、ＡＰＰ１０４又はＶＯＬ１０５）が関連付けられることが、回避されてよい。同一ＨＢＡ１２１の全てのポート１２２が「未割当て」の場合に、いずれかのＩ／ＯサイズをそのＨＢＡ１２１に関連付けることができる。
【０１３３】
図１２は、サーバ／ストレージ接続テーブル１５４の構成例を示す。
【０１３４】
サーバ／ストレージ接続テーブル１５４は、サーバＨＢＡポート１０８とストレージＨＢＡポート１２２間の接続関係を示す。サーバ／ストレージ接続テーブル１５４は、サーバＨＢＡポート１０８とストレージＨＢＡポート１２２の組毎にエントリを有する。各エントリに格納される情報は、サーバＩＤ１２０１、サーバＨＢＡ  ＩＤ１２０２、サーバポートＩＤ１２０３、ストレージＩＤ１２０４、ストレージＨＢＡ  ＩＤ１２０５、及び、ストレージポートＩＤ１２０６である。
【０１３５】
サーバＩＤ１２０１は、サーバ１００のＩＤを示す。サーバＨＢＡ  ＩＤ１２０２は、サーバＨＢＡ１０６のＩＤを示す。サーバポートＩＤ１２０３は、サーバＨＢＡポート１０８のＩＤを示す。ストレージＩＤ１２０４は、ストレージ１２０のＩＤを示す。ストレージＨＢＡ  ＩＤ１２０５は、ストレージＨＢＡ１２１のＩＤを示す。ストレージポートＩＤ１２０６は、ストレージＨＢＡポート１２２のＩＤを示す。サーバ／ストレージ接続テーブル１５４は、サーバ１００及びストレージ１２０から接続情報を収集することにより構築されてよい。
【０１３６】
図１３は、ストレージパーティションテーブル１５５の構成例を示す。
【０１３７】
ストレージパーティションテーブル１５５は、ストレージパーティションの構成に関する情報である。ストレージパーティションテーブル１５５は、ストレージパーティション毎にエントリを有する。各エントリに格納される情報は、ストレージパーティションＩＤ１３０１、環境１３０２、ＨＢＡ１３０３、ＣＰＵ１３０４、メモリ１３０５、及び、ドライブ１３０６である。
【０１３８】
ストレージパーティションＩＤ１３０１は、ストレージパーティションのＩＤを示す。環境１３０２は、ストレージパーティションが属する環境（本番又は開発）を示す。ＨＢＡ１３０３は、ストレージパーティションに属するＨＢＡ１２１のＩＤを示す。ＣＰＵ１３０４は、ストレージパーティションに属するＣＰＵ１２３のＩＤを示す。メモリ１３０５は、ストレージパーティションに属するＣＬＰＲ（Cache  Logical  Partition）のＩＤを示す。ＣＬＰＲは、メモリ１２４（キャッシュメモリ）を論理分割することにより得られたキャッシュメモリＬＰＡＲである。ドライブ１３０６は、ストレージパーティションに属するドライブ１２５のＩＤを示す。
【０１３９】
以上が、管理情報６７０に含まれる各テーブルの説明である。
【０１４０】
次に、ストレージパーティション作成画面１４２及び統合ＬＰＡＲ作成画面１４１を説明する。
【０１４１】
図１４は、ストレージパーティション作成画面１４２の構成例を示す。
【０１４２】
ストレージパーティション作成画面１４２は、ストレージパーティションを作成するための情報の入力と、ストレージパーティション作成の指示とを受け付ける画面（例えばＧＵＩ）である。例えば、ストレージパーティション作成画面１４２には、ストレージパーティションＩＤ入力ＵＩ（ユーザインターフェース）１４０１と、環境名入力ＵＩ１４０２と、ストレージパーティションサイズ選択ＵＩ１４０３と、作成指示ＵＩ１４０４とが表示される。
【０１４３】
ＵＩ１４０１は、作成するストレージパーティションのＩＤが入力されるＵＩであり、例えばテキスト入力欄である。ＵＩ１４０２は、作成するストレージパーティションが属する環境の名前（本番又は開発）が入力されるＵＩであり、例えばテキスト入力欄である。
【０１４４】
ＵＩ１４０３は、ストレージパーティションサイズの選択を受け付けるＵＩであり、例えば、複数のストレージパーティションサイズにそれぞれ対応した複数のラジオボタンである。具体的には、例えば、ＵＩ１４０３は、ストレージパーティションサイズと、ストレージＨＢＡ１２１の数、ＣＰＵ１２３の数、メモリ１２４の容量、及びドライブ１２５の数との関係を表すテーブルを含む。そのテーブルは、ストレージパーティションサイズテンプレートテーブル１５６それ自体でもよいし、管理情報６７０に含まれている情報それ自体、又は、管理情報６７０に含まれている情報及びポリシーを基にランブック自動化プログラム６６０により決定された情報でよい。ＵＩ１４０３が有するテーブルに、ストレージパーティションサイズ毎のラジオボタンが表示される。
【０１４５】
ＵＩ１４０１及び１４０２に情報が入力され、ＵＩ１４０３を通じてシステム管理者所望のストレージパーティションが選択され、作成指示ＵＩ１４０４が操作された場合（例えば「作成」ボタンが押された場合）、ストレージパーティションが作成される。
【０１４６】
図１５は、統合ＬＰＡＲ作成画面１４１の構成例を示す。
【０１４７】
統合ＬＰＡＲ作成画面１４１は、統合ＬＰＡＲを作成するための情報の入力と、統合ＬＰＡＲの作成指示とを受け付ける画面（例えばＧＵＩ）である。統合ＬＰＡＲを作成するための情報は、作成される統合ＬＰＡＲに割り当てられる統合ＬＰＡＲ  ＩＤと、それぞれＬＰＡＲ負荷特性に関わる情報である１種類以上の負荷特性情報とを含む。本実施例においては、１種類以上の負荷特性情報は、作成される統合ＬＡＰＲで起動されるＡＰＰのＡＰＰ名及びＡＰＰ用途を含む。更に、１種類以上の負荷特性情報は、作成される統合ＬＰＡＲのサイズと、その統合ＬＰＡＲの環境の種類（本番又は開発）とを含む。なお、１種類以上のＩ／Ｏ負荷特性情報は、図１５に示す情報の少なくとも一部に代えて、例えば、統合ＬＰＡＲで実行されるＡＰＰのＩ／Ｏ特性それ自体（例えばＩ／Ｏサイズ）を含んでもよい。
【０１４８】
統合ＬＰＡＲ作成画面１４１は、例えば、統合ＬＰＡＲ  ＩＤ入力ＵＩ１５０１と、ＡＰＰ選択ＵＩ１５０２と、ＡＰＰ用途選択ＵＩ１５０３と、環境選択ＵＩ１５０４と、統合ＬＰＡＲサイズ選択ＵＩ１５０５と、作成指示ＵＩ１５０７とを有する。
【０１４９】
ＵＩ１５０１は、作成する統合ＬＰＡＲのＩＤが入力されるＵＩであり、例えばテキスト入力欄である。ＵＩ１５０２は、ＡＰＰ名の選択を受け付けるＵＩである。ＵＩ１５０３は、ＡＰＰ用途の選択を受け付けるＵＩである。ＵＩ１５０４は、環境の選択を受け付けるＵＩである。ＵＩ１５０５は、統合ＬＰＡＲサイズの選択を受け付けるＵＩである。ＵＩ１５０２〜１５０５は、それぞれ例えばプルダウンメニューである。
【０１５０】
ＵＩ１５０１に統合ＬＰＡＲ  ＩＤが入力され、ＵＩ１５０２〜１５０５を通じてＡＰＰ名、ＡＰＰ用途、環境及び統合ＬＰＡＲサイズが選択され、作成指示ＵＩ１５０７が操作された場合（例えば「作成」ボタンが押された場合）、統合ＬＰＡＲが作成される。
【０１５１】
以上が、ストレージパーティション作成画面１４２及び統合ＬＰＡＲ作成画面１４１の説明である。なお、画面１４２の選択肢又は画面１４１のプルダウンメニューに表示される選択肢（例えば、ストレージパーティションサイズ、ＡＰＰ名、環境名、ＡＰＰ用途、統合ＬＰＡＲサイズ等）は、適宜に、変更（追加又は削除を含む）されてよい。また、ＡＰＰ管理サーバ１６０に表示される統合ＬＰＡＲ作成画面１６２は、ＡＰＰ選択ＵＩに表示されるＡＰＰが、そのＡＰＰ管理サーバ１６０の管理対象のＡＰＰに制限されてよい。
【０１５２】
ランブック自動化プログラム６６０がストレージパーティション作成画面１４２を介して受け付けたストレージパーティション作成指示に応答して行われるストレージパーティション作成処理の流れは、例えば下記の通りである。
【０１５３】
（１４００−１）ランブック自動化プログラム６６０は、ストレージ１２０にＲＡＩＤグループ作成指示を送信する。ＲＡＩＤグループの作成指示には、画面１４２を介して入力された情報（例えば、選択されたストレージパーティションサイズに対応したドライブ数等）が含まれる。この結果、ストレージ１２０は、作成指示に応答して、その作成指示に関連付いた数のドライブで構成されたＲＡＩＤグループを作成する。ＲＡＩＤグループのＲＡＩＤレベルは、予め定められたＲＡＩＤレベルでよい。異なる種類のドライブ１２５が混在している場合（例えばＨＤＤとＳＳＤが混在している場合）、同種のドライブで構成されたＲＡＩＤグループ（例えば、ＨＤＤのＲＡＩＤグループ、又は、ＳＳＤのＲＡＩＤグループ）が作成されてよい。また、作成されたＲＡＩＤグループに基づくプールも作成されてよい。
【０１５４】
（１４００−２）ランブック自動化プログラム６６０は、ストレージ１２０にＣＬＰＲ作成指示を送信する。ＣＬＰＲの作成指示には、画面１４２を介して入力された情報（例えば、選択されたストレージパーティションサイズに対応したメモリ容量）が含まれる。ストレージ１２０は、その作成指示に応答して、その作成指示に関連付いたメモリ容量のＣＬＰＲを作成する。異なる種類のドライブ１２５が混在している場合（例えばＨＤＤとＳＳＤが混在している場合）、ドライブ種類別に、ＣＬＰＲが作成されてよい。
【０１５５】
（１４００−３）ランブック自動化プログラム６６０は、画面１４２を介して入力された情報と、作成したＲＡＩＤグループ及びＣＬＰＲの情報に基づき、ストレージパーティションテーブル１５５を更新する。例えば、選択されたストレージパーティションサイズに対応したＨＢＡ数、ＣＰＵ数、メモリ容量及びドライブ数に従ってストレージ１２０により決定されたストレージＨＢＡ１２１、ＣＰＵ１２３、ＣＬＰＲ及びドライブ１２５の各々のＩＤが、ストレージ１２０からランブック自動化プログラム６６０に伝えられ、ランブック自動化プログラム６６０が、それらのＩＤと、入力されたストレージパーティションＩＤと、入力された環境名（本番又は開発）とを、対象ストレージパーティションに対応するエントリ（ストレージパーティションテーブル１５５におけるエントリ）に登録する。
【０１５６】
ストレージＨＢＡ１２１及びＣＰＵ１２３の決定は、（１４００−１）、（１４００−２）又は別のステップにおいて行われてよい。例えば、ランブック自動化プログラム６６０は、選択されたストレージパーティションサイズに対応したＨＢＡ数及びＣＰＵ数を関連付けた指示（例えば、ＲＡＩＤグループ作成指示、ＣＬＰＲ作成指示又は別の指示）を、ストレージ１２０に送信してよい。その指示に応答して、ストレージ１２０が、その指示に関連付いているＨＢＡ数及びＣＰＵ数に従い、対象ストレージパーティションに含めるストレージＨＢＡ１２１及びＣＰＵ１２３を決定してよい。
【０１５７】
このようなストレージパーティション作成処理は、統合ＬＰＡＲ作成処理において行われてもよいが、本実施例では、ストレージパーティション作成処理は、統合ＬＰＡＲ作成処理よりも前に行われる。言い換えれば、ストレージパーティション作成処理の終了後に、統合ＬＰＡＲ作成処理が開始される。ストレージパーティション作成処理では、ドライブ１２５間のデータ移動を伴う負荷の高い処理が必要となる場合があり、統合ＬＰＡＲ作成処理においてストレージパーティション作成を実行するようにすると、統合ＬＰＡＲ作成処理の開始から終了までに長時間を要してしまう可能性がある。このため、ストレージパーティション作成処理を先に行うことで、統合ＬＰＡＲ作成処理にかかる時間の短縮が期待できる。
【０１５８】
ランブック自動化プログラム６６０が統合ＬＰＡＲ作成画面１４１を介して受け付けた統合ＬＰＡＲ作成指示に応答して行われる統合ＬＰＡＲ作成全体処理は、図１６及び図１７に示す統合ＬＰＡＲ作成全体ワークフロー（ＷＦ）の実行により行われる処理である。以下、統合ＬＰＡＲ作成全体ＷＦを説明する。
【０１５９】
図１６は、統合ＬＰＡＲ作成全体ＷＦの構成例を示す。図１７は、統合ＬＰＡＲ作成全体ＷＦにおける統合ＬＰＡＲ作成ＷＦのコンポーネント（ＷＦ）間の関係を示す。図１７において、第１ＷＦから第２ＷＦへの矢印は、第１ＷＦの次に第２のＷＦが実行されることを意味する。
【０１６０】
統合ＬＰＡＲ作成全体ＷＦ１６００は、統合ＬＰＡＲ作成パラメータ生成機能１７３（図１）により実行される統合ＬＰＡＲ作成パラメータ生成ＷＦ１６０１と、統合ＬＰＡＲ作成機能１４４により実行される統合ＬＰＡＲ作成ＷＦ１６０２とから構成される。
【０１６１】
統合ＬＰＡＲ作成パラメータ生成ＷＦ１６０１は、統合ＬＰＡＲ作成指示に関連付けられた１種類以上の負荷特性情報（図１５の例によれば、ＡＰＰ名、ＡＰＰ用途、環境種類及び統合ＬＰＡＲサイズ）と割当て制御情報６７２とに基づいて、画面１４１に入力された統合ＬＰＡＲ  ＩＤが割り当てられる統合ＬＰＡＲの作成に必要なパラメータを取得することが定義されたＷＦである。統合ＬＰＡＲ作成パラメータ生成ＷＦ１６０１は、統合ＬＰＡＲ作成ＷＦ１６０２のコンポーネントとされてもよいが、本実施例では、全体ＷＦ１６００のコンポーネントであるものの統合ＬＰＡＲ作成ＷＦ１６０２のコンポーネントではない。統合ＬＰＡＲ作成ＷＦ１６０２とは別に統合ＬＰＡＲ作成パラメータ生成ＷＦ１６０１があることで、ＬＰＡＲ作成指示に関してユーザ（例えばテナント管理者）から様々な要求があってもその要求に柔軟に対応することが期待できる。
【０１６２】
統合ＬＰＡＲ作成ＷＦ１６０２は、統合ＬＰＡＲ作成パラメータ生成ＷＦ１６０１の実行により取得されたパラメータに従い統合ＬＰＡＲを作成する処理が定義されたＷＦである。ＷＦ１６０１では、処理の分割が定義されている。具体的には、例えば、ＷＦ１６０１では、サーバ１００に対する処理とストレージ１２０に対する処理とが区別されている。統合ＬＰＡＲ作成ＷＦ１６０２は、リソース選択機能１９１（図１）により実行されるリソース選択ＷＦ１６１１と、リソース割当て機能１９２により実行されるリソース割当てＷＦ１６１２と、ＯＳ配信機能１９３により実行されるＯＳ配信ＷＦ１６１３とから構成される。リソース選択ＷＦ１６１１は、サーバリソースの選択処理が定義されたサーバリソース選択ＷＦ１６２１と、ストレージリソースの選択処理が定義されたストレージリソース選択ＷＦ１６２２から構成される。リソース割当てＷＦ１６１２は、サーバＬＰＡＲの作成処理が定義されたサーバＬＰＡＲ作成ＷＦ１６３１と、ストレージリソースの割当て処理が定義されたストレージリソース割当ＷＦ１６３２と、ブートオーダの設定処理が定義されたＬＰＡＲブートオーダ設定ＷＦ１６３３から構成される。
【０１６３】
ＷＦの実行としての処理は、ストレージパーティション作成処理にも適用されてよい。各ＷＦは、例えば下記の仕組みによりサービスとして提供されてよい。また、以下の説明で言う「ユーザ」の一例が、管理者でよい。また、以下の説明で言う「運用自動化システム」の一例が、統合管理サーバ１４０、ランブック自動化プログラム６６０、及び、統合管理サーバ１４０内の他のプログラムのうちのいずれかでよい。
【０１６４】
図２７は、ＷＦ提供の一例の概要の模式図である。
【０１６５】
運用自動化システムが、システム運用の多数のコンポーネント（コンポーネント群）を管理する。ここで、「システム運用」とは、サーバストレージシステム１０００の運用のことである。「コンポーネント」とは、システム運用の一部分であり、１つの独立した処理（業務）である。コンポーネントは、ＷＦテンプレートに関連付けられる１つの単位（ＷＦテンプレートに含まれる１つの単位）である。コンポーネントとしては、プラグインコンポーネントと、ＷＦテンプレートコンポーネント（コンポーネントとして扱われるＷＦテンプレート）がある。プラグインコンポーネントは、例えば、スクリプトを実行する処理モジュールであり、実行ファイルでよい。本実施例では、２以上のコンポーネントを基にＷＦテンプレートが作成され、作成されたＷＦテンプレートを基にＷＦが作成され、作成されたＷＦが実行される。以下、コンポーネント管理、ＷＦテンプレート作成、ＷＦテンプレート確定、ＷＦ作成及びＷＦ実行の概要を説明する。
【０１６６】
＜コンポーネント管理＞
【０１６７】
コンポーネントは、コンポーネント提供ユーザにより追加又は変更されてよい。運用自動化システムは、コンポーネント毎に、コンポーネントに関連付けられる１以上のコンポーネントプロパティを管理する。また、運用自動化システムは、コンポーネント毎に、コンポーネントのバージョンを管理する。図２７では、コンポーネントＢＢＢを例に取って、コンポーネントプロパティ及びバージョンを示しているが、別のコンポーネントにも、その別のコンポーネントのコンポーネントプロパティ及びバージョンが関連付けられている。
【０１６８】
「コンポーネントプロパティ」とは、コンポーネントのプロパティである。コンポーネントプロパティとして、コンポーネント入力プロパティとコンポーネント出力プロパティの２種類がある。コンポーネント入力プロパティは、定義された項目（表示名）についての値の入力に関するプロパティであり、コンポーネント出力プロパティは、定義された項目（表示名）についての値の出力に関するプロパティである。１つのコンポーネントに、１以上のコンポーネント入力プロパティと０以上のコンポーネント出力プロパティのうちの少なくとも１つが関連付けられる。すなわち、コンポーネントによっては、出力プロパティが０個の場合もあるが、入力プロパティは、各コンポーネントにつき１個以上関連付けられている。入力値は、例えば、過去に作成されたＷＦのプロパティとして入力された値のコピーであってもよいし、実行済みの他のコンポーネントについて出力された値のコピーであってもよい。出力値は、コンポーネント実行後の構成情報等でよい。
【０１６９】
「コンポーネント提供ユーザ」とは、コンポーネントの追加又は更新等を行う、運用自動化システムのユーザである。コンポーネント提供ユーザは、例えばＧＵＩ（Graphical  User  Interface）、ＣＬＩ（Command  Line  Interface）、ＡＰＩ（Application  Programming  Interface）などを介して、コンポーネントを作成、追加、又は更新等行うことができる。コンポーネント提供ユーザにより追加又は更新されるコンポーネントは、典型的にはプラグインコンポーネントでよい。ＷＦテンプレートには、プラグインコンポーネント及びＷＦテンプレートコンポーネントのいずれも関連付けることができる。プラグインコンポーネントは、最小単位でよく、ＷＦテンプレートコンポーネントは、１以上のプラグインコンポーネントとそれらが関連付けられたＷＦテンプレートとのパッケージでよい。プラグインコンポーネントは、コンポーネント入力プロパティと、コンポーネント入力プロパティに入力された入力値に基づいて実行する処理内容とを含んでよい。ＷＦテンプレートコンポーネントも、コンポーネント入力プロパティと、コンポーネント入力プロパティに入力された入力値に基づいて実行する処理内容とを含んでよい。ＷＦテンプレートコンポーネントのコンポーネント入力プロパティは、ＷＦテンプレート入力プロパティでよい。
【０１７０】
＜ＷＦテンプレート作成＞
【０１７１】
運用自動化システムが、ＷＦテンプレート作成画面を表示する。ＷＦテンプレート作成画面に、情報の入力ＵＩが表示される。ＷＦテンプレート作成ユーザが、ＷＦテンプレート作成画面に情報を入力する。例えば、運用自動化システムは、ＷＦテンプレート作成画面を介して、多数のコンポーネントのうちの２以上のコンポーネントの選択と、２以上のコンポーネントの実行順序の指定とを受け付ける。運用自動化システムが、選択された２以上のコンポーネントと指定された実行順序とに基づきコンポーネントフローのＷＦテンプレートを作成する。
【０１７２】
「ＷＦテンプレート作成ユーザ」とは、ＷＦテンプレートを作成する、運用自動化システムのユーザである。ＷＦテンプレート作成ユーザは、コンポーネント提供ユーザと同一であってもよいし異なっていてもよい。
【０１７３】
「ＷＦテンプレート」とは、ＷＦのテンプレートである。ＷＦテンプレートは、インスタンス化されていない自動実行内容を指し示すオブジェクトという言い方をすることもできる。
【０１７４】
「コンポーネントフロー」とは、典型的には、選択された２以上のコンポーネントの並びである。コンポーネントの並びは、指定された実行順序に従う。選択されたコンポーネントの数が１つだけの場合、コンポーネントフローを構成するコンポーネントの数も１つである。
【０１７５】
上述のように、運用自動化システムは、ＷＦテンプレート作成画面を介して選択された２以上のコンポーネント及び指定された実行順序を基にＷＦテンプレートを作成する。具体的には、例えば、運用自動化システムは、選択された２以上のコンポーネントに関連付けられている複数のコンポーネントプロパティにそれぞれ対応した複数のＷＦテンプレートプロパティを作成し、作成した複数のＷＦテンプレートプロパティをＷＦテンプレートに関連付ける。コンポーネントプロパティに対応したＷＦテンプレートプロパティは、そのコンポーネントプロパティを基に運用自動化システムにより自動作成される。「ＷＦテンプレートプロパティ」とは、ＷＦテンプレートのプロパティである。ＷＦテンプレートプロパティとして、ＷＦテンプレート入力プロパティとＷＦテンプレート出力プロパティの２種類がある。ＷＦテンプレート入力プロパティは、定義された項目（表示名）についての値の入力に関するプロパティであり、ＷＦテンプレート出力プロパティは、定義された項目（表示名）についての値の出力に関するプロパティである。１つのＷＦテンプレートに、１以上のＷＦテンプレート入力プロパティと０以上のＷＦテンプレート出力プロパティのうちの少なくとも１つが関連付けられる。すなわち、ＷＦテンプレート出力プロパティが必ず１個あるとは限らない。
【０１７６】
＜ＷＦ作成＞
【０１７７】
運用自動化システムは、作成済のＷＦテンプレートのうちのいずれかのＷＦテンプレートの選択をＷＦ作成ユーザから受け、選択されたＷＦテンプレートを基にＷＦ作成画面を表示する。ＷＦ作成ユーザが、ＷＦ作成画面に情報を入力する。運用自動化システムは、ＷＦ作成画面を介して入力された情報を基にＷＦを作成する。
【０１７８】
「ＷＦ作成ユーザ」とは、ＷＦを作成（実行）するユーザである。ＷＦ作成ユーザとＷＦテンプレート作成ユーザは異なるユーザであってもよいし同一ユーザであってもよい。
【０１７９】
「ＷＦ」とは、インスタンス化されたＷＦテンプレートである。具体的には、ＷＦテンプレートは、ＷＦの実行に必要な値がブランクとなっており、その必要な値がＷＦテンプレートに入力されたものが、ＷＦである。なお、前述のＷＦの実行に必要な値については、デフォルト値がＷＦテンプレートのプロパティの情報として設定できる場合もある。
【０１８０】
以上が、コンポーネント管理、ＷＦテンプレート作成及びＷＦ作成の各々の概要である。
【０１８１】
上記のようなＷＦ提供に従い提供されたＷＦの一例が、図１６のＷＦ１６０１、１６０２、１６１１、１６１２、１６１３、１６２１、１６２２、１６３１、１６３２及び１６３３である。以下、このようなＷＦの実行としての処理の流れを説明する。
【０１８２】
図１８は、統合ＬＰＡＲ作成全体処理の流れを示す。
【０１８３】
統合ＬＰＡＲ作成全体処理は、統合ＬＰＡＲ作成画面１４１を介して受け付けた統合ＬＰＡＲ作成指示（入力された統合ＬＰＡＲ  ＩＤ、ＡＰＰ名、ＡＰＰ用途、環境種類及び統合ＬＰＡＲサイズが関連付けられている指示）に応答して行われる処理であって、統合ＬＰＡＲ作成全体ＷＦ１６００の実行により行われる処理である。
【０１８４】
統合ＬＰＡＲ作成パラメータ生成機能１７３が、統合ＬＰＡＲ作成パラメータ生成ＷＦ１６０１を実行、すなわち、統合ＬＰＡＲ作成パラメータ生成処理を実行する（Ｓ１８０１）。具体的には、統合ＬＰＡＲ作成パラメータ生成機能１７３が、統合ＬＰＡＲ作成指示に関連付けられているＡＰＰ名、ＡＰＰ用途、環境種類及び統合ＬＰＡＲサイズをキーに、割当て制御情報６７２からパラメータを取得する。
【０１８５】
次に、統合ＬＰＡＲ作成機能１４４が、統合ＬＰＡＲ作成ＷＦ１６０２を実行、すなわち、統合ＬＰＡＲ作成処理を実行する（Ｓ１８０２）。ここでは、Ｓ１８０１で取得（生成）されたパラメータを入力として、統合ＬＰＡＲ作成機能１４４が、サーバリソース及びストレージリソースを選択し、且つ、選択したサーバリソース及びストレージリソースの割当てを行うことで、統合ＬＰＡＲを作成する。
【０１８６】
図１９は、統合ＬＰＡＲ作成処理の流れを示す。
【０１８７】
リソース選択機能１９１が、リソース選択ＷＦ１６１１を実行、すなわち、リソース選択処理を実行する（Ｓ１９０１）。ここでは、リソース選択機能１９１が、Ｓ１８０１で取得（生成）されたパラメータを入力とする。
【０１８８】
統合ＬＰＡＲを作成するのに必要なリソースの確保が不可能だったた場合（Ｓ１９０２：Ｎｏ）、統合ＬＰＡＲ作成不可として、リソース選択処理が終了する（Ｓ１９１１）。例えば、統合ＬＰＡＲ作成機能１４４が、統合ＬＰＡＲ作成の失敗を、統合ＬＰＡＲ作成指示の送信元（例えばテナント管理者又はシステム管理者）に通知する。
【０１８９】
必要なリソースが確保された場合（Ｓ１９０２：Ｙｅｓ）、リソース割当て機能１９２が、リソース割当てＷＦ１６１２を実行、すなわち、リソース割当て処理を実行する（１９２１）。ここでは、リソース割当て機能１９２が、確保されたリソースの情報を入力として、統合ＬＰＡＲを作成する。その後、ＯＳ配信機能１９３が、ＯＳ配信ＷＦ１６１３を実行、すなわち、ＯＳ配信処理を実行する（Ｓ１９２２）。具体的には、例えば、ＯＳ配信機能１９３が、作成されたＬＰＡＲで実行されるＡＰＰのＡＰＰ名及びＡＰＰ用途（画面１４１に入力されたＡＰＰ名及びＡＰＰ用途）に合わせて用意された起動イメージ（ＯＳイメージ）の配信を行う。その後、統合ＬＰＡＲ作成機能１４４が、統合ＬＰＡＲ作成の成功を、統合ＬＰＡＲ作成指示の送信元（例えばテナント管理者又はシステム管理者）に通知する（Ｓ１９２３）。
【０１９０】
図２０は、リソース選択処理の流れを示す。図２０において、Ｓ２００１が、サーバリソース選択ＷＦ１６２１の実行であり、Ｓ２００２〜Ｓ２００６が、ストレージリソース選択ＷＦ１６２２の実行である。
【０１９１】
リソース選択機能１９１が、入力されたパラメータ（Ｓ１８０１で取得（生成）されたパラメータ）を用いて、サーバリソース選択処理を実行する（Ｓ２００１）。ここでは、リソース選択機能１９１が、入力されたパラメータに該当する（統合ＬＰＡＲ作成に使用可能な）サーバリソース組合せの候補（以下、サーバリソース組合せ候補）を全て特定する。サーバリソース組合せ候補が複数ある場合、リソース選択機能１９１が、サーバリソースの使用状況等に基づいて、各サーバリソース組合せ候補に優先度を割り振る。例えば、使用状況として負荷が低いサーバリソース組合せ候補程、高い優先度が割り当てられる。
【０１９２】
リソース選択機能１９１は、Ｓ２００２で未選択のサーバリソース組合せ候補から、最も優先度の高いサーバリソース組合せ候補を選択する（Ｓ２００２）。なお、未選択のサーバリソース組合せ候補が無い場合、リソース選択機能１９１は、統合ＬＰＡＲ作成不可として、リソース選択処理を終了する（Ｓ２００６）。Ｓ２００６が行われた場合、図１９において、Ｓ１９０２がＮｏとなりＳ１９１１が行われる。
【０１９３】
リソース選択機能１９１は、Ｓ２００２で選択したサーバリソース組合せ候補と接続されている（物理的に接続されている）ストレージ１２０から、確保可能であり必要なストレージリソースが探す（Ｓ２００３）。サーバリソース組合せ候補は、例えば、同一のサーバ１００にあるサーバリソース組合せである。そして、サーバリソース組合せ候補に接続されているストレージ１２０は、サーバ／ストレージ接続テーブル１５４から特定可能である。「必要なストレージリソース」とは、入力されたパラメータを用いて割当て制御情報６７２から特定されるリソース種類、リソース量及び割当て種類に従うストレージリソースであり、例えば、ストレージＨＢＡテーブル１５３及びストレージパーティションテーブル１５５から探し出されてよい。
【０１９４】
Ｓ２００３でストレージリソースが見つからなければ（Ｓ２００４：Ｎｏ）、リソース選択機能１９１は、Ｓ２００２に戻る。例えば、Ｓ２００２で選択されたサーバリソース組合せ候補に接続されているストレージ１２０に占有割当て可能なＨＢＡポートが２つ存在する必要があるが、２つのＨＢＡポートのいずれも既に共有割当てされている場合、それは、ストレージリソースが見つからないことを意味し、結果として、Ｓ２００２が再度行われることになる。
【０１９５】
Ｓ２００３でストレージリソースが見つかれば（Ｓ２００４：Ｙｅｓ）、リソース選択機能１９１は、Ｓ２００２で選択したサーバリソース組合せ候補を、選択されたサーバリソースとして決定し、Ｓ２００３で見つかったストレージリソースを、選択されたストレージリソースとして決定する（Ｓ２００５）。
【０１９６】
図２０のリソース選択処理によれば、サーバリソース及びストレージリソースの両方が選択されてから、リソース選択処理が終了し、リソース割当て処理が行われることになる。サーバリソース組合せ候補が１つでも見つかりそのサーバリソース組合せ候補についてストレージリソースが見つかる前に、サーバリソースの割当て後に必要なストレージリソースを探しても、そのサーバリソースに接続されたストレージ１２０から必要なストレージリソースが見つからないことがあり得る。これは、選択されたサーバリソースを有するサーバ１００に一部のストレージ１２０しか接続されていない場合には、特に起こり得る。サーバリソースが先に占有割当てされると、その占有割当てが解除されない限り、別の統合ＬＰＡＲのためにそのサーバリソースを占有割当てすることはできない。このため、全体として、統合ＬＰＡＲ作成処理に要する時間が長くなる。本実施例では、サーバリソース及びストレージリソースの両方が選択されてから、リソース割当て処理が行われることになるため、このような問題を回避することができる。
【０１９７】
なお、本実施例では、サーバＨＢＡポート１０８とストレージＨＢＡポート１２２との対応関係が１：１であるが、サーバ１００とストレージ１２０とをスイッチを介して接続することで、サーバＨＢＡポート１０８とストレージＨＢＡポート１２２との対応関係が１：ｎ、ｍ：１又はｍ：ｎとなってもよい（ｎ、ｍはそれぞれ２以上の整数）。
【０１９８】
図２１は、リソース割当て処理の流れを示す。図２１において、Ｓ２１０１が、サーバＬＰＡＲ作成ＷＦ１６３１の実行であり、Ｓ２１０２が、ストレージリソース割当てＷＦ１６３２の実行であり、Ｓ２１０３が、ＬＰＡＲブートオーダ設定ＷＦ１６３３の実行である。
【０１９９】
リソース割当て機能１９２が、リソース選択処理で選択されたサーバリソースの情報（例えば、管理情報６７０から取得される情報）を基に、サーバＬＰＡＲ作成処理を実行する（Ｓ２１０１）。
【０２００】
リソース割当て機能１９２が、リソース選択処理で選択されたストレージリソースの情報（例えば、管理情報６７０から取得される情報）を基に、ストレージリソース割当て処理を実行する（Ｓ２１０２）。
【０２０１】
Ｓ２１０１及びＳ２１０２により統合ＬＰＡＲが作成されたことになり、リソース割当て機能１９２は、その作成された統合ＬＰＡＲに対して、ブートオーダの設定を行う（Ｓ２１０３）。ここでは、例えば、起動イメージ（ＯＳイメージ）が格納されることになるＶＯＬ（データＶＯＬ）からのブートのためのブートオーダが設定される。ブートオーダは、例えば、スクリプトファイルに定義されていてもよく、そのスクリプトファイルを統合ＬＰＡＲに設定することが、ブートオーダの設定でもよい。
【０２０２】
図２２は、サーバＬＰＡＲ作成処理の流れを示す。
【０２０３】
リソース割当て機能１９２が、サーバＬＰＡＲの作成、具体的には、サーバＣＰＵの割当て（Ｓ２２０１）、サーバメモリの割当て（Ｓ２２０２）、サーバＮＩＣ（例えばポート）の割当て（Ｓ２２０３）、及び、サーバＨＢＡポートの割当て（２２０４）を行う。Ｓ２２０１〜Ｓ２２０４で割り当てられたサーバリソースは、リソース選択処理で選択されたサーバリソースである。割当て完了後、割り当てられたサーバリソースについて、占有割当てと共有割当てのいずれの割当てがされたかが管理情報６７０におけるテーブルに関連付けられてよい。占有割当てされたサーバリソースは、作成対象の統合ＬＰＡＲ以外の統合ＬＰＡＲに割り当てられることはない。
【０２０４】
図２３は、ストレージリソース割当て処理の流れを示す。
【０２０５】
リソース割当て機能１９２が、ＶＯＬ作成を行う（Ｓ２３０１）。ここでは、例えば、リソース割当て機能１９２が、リソース選択処理において選択されたストレージリソースにおけるストレージパーティションから、リソース選択処理において特定されたＶＯＬ容量及びＶＯＬ数のＶＯＬを生成する。
【０２０６】
リソース割当て機能１９２が、Ｓ２３０１で作成された全てのＶＯＬを、作成対象の統合ＬＰＡＲに割り当てる（提供する）（Ｓ２３０２）。これにより、統合ＬＰＡＲ（特にサーバＬＰＡＲ）に、Ｓ２３０１で作成されたＶＯＬが認識される。なお、Ｓ２３０２では、リソース割当て機能１９２は、リソース選択処理で選択されたストレージリソース（例えばストレージＨＢＡポート）を占有割当て又は共有割当てしてよい。
【０２０７】
以上が、統合ＬＰＡＲ作成全体処理の説明である。
【０２０８】
以下、統合ＬＰＲ作成全体処理の具体例を説明する。
【０２０９】
＜統合ＬＰＡＲ作成パラメータ生成処理＞
【０２１０】
図１５の統合ＬＰＡＲ作成画面１４１に、下記の情報が入力されたとする。
（＋）ＡＰＰ名＝ＡＰＰ−ａ
（＋）ＡＰＰ用途＝ＯＬＴＰ
（＋）環境＝本番
（＋）統合ＬＰＡＲサイズ＝Ｓ
【０２１１】
Ｓ１８０１において、統合ＬＰＡＲ作成パラメータ生成機能１７３が、図３のＩ／Ｏサイズテーブル１４５を参照し、入力されたＡＰＰ名「ＡＰＰ−ａ」及びＡＰＰ用途「ＯＬＴＰ」に対応したＶＯＬ用途３０３及びＩ／Ｏサイズ３０４を取得する。ここでは、ＶＯＬ用途「データ」（データＶＯＬ）について、Ｉ／Ｏサイズ「大」が取得され、ＶＯＬ用途「ログ」（ログＶＯＬ）について、Ｉ／Ｏサイズ「小」が取得される。
【０２１２】
Ｓ１８０１において、更に、統合ＬＰＡＲ作成パラメータ生成機能１７３が、図５の統合ＬＰＡＲサイズテンプレートテーブル１４７から、統合ＬＰＡＲに関する情報を取得する。ここでは、入力された統合ＬＰＡＲサイズ「Ｓ」に対応したＬＰＡＲ  ＣＰＵコア数「８」、ＬＰＡＲメモリ容量「１２８ＧＢ」、及び、ＬＰＡＲ  ＮＩＣポート数「１」が取得される。また、Ｉ／Ｏサイズ「大」（データＶＯＬ）について、ＨＢＡポート数「２」及びサーバＨＢＡ  ＣＴＬ数「４」が取得される。Ｉ／Ｏサイズ「小」（ログＶＯＬ）について、ＨＢＡポート数「２」及びサーバＨＢＡ  ＣＴＬ数「２」が取得される。
【０２１３】
Ｓ１８０１において、更に、統合ＬＰＡＲ作成パラメータ生成機能１７３が、図６のＶＯＬテンプレートテーブル１４８から、ＶＯＬ容量６０５及びＶＯＬ数６０６を取得する。ここでは、ＶＯＬ用途「データ」（データＶＯＬ）について、入力されたＡＰＰ名「ＡＰＰ−ａ」、ＡＰＰ用途「ＯＬＴＰ」及び統合ＬＰＡＲサイズ「Ｓ」に対応したＶＯＬ容量「１２８ＧＢ」及びＶＯＬ数「４」が取得される。ＶＯＬ用途「ログ」（ログＶＯＬ）についても、入力されたＡＰＰ名「ＡＰＰ−ａ」、ＡＰＰ用途「ＯＬＴＰ」及び統合ＬＰＡＲサイズ「Ｓ」に対応したＶＯＬ容量「１２８ＭＢ」及びＶＯＬ数「４」が取得される。
【０２１４】
Ｓ１８０１において、更に、統合ＬＰＡＲ作成パラメータ生成機能１７３が、図１３のストレージパーティションテーブル１５５から、選択したストレージパーティションに対応したＨＢＡ１３０３、ＣＰＵ１３０４、メモリ１３０５及びドライブ１３０６を取得する。ここでは、入力された環境「本番」に対応するＨＢＡ「ＨＢＡ１」及び「ＨＢＡ２」、ＣＰＵ「ＣＰＵ１」及び「ＣＰＵ２」、メモリ「ＣＬＰＲ１」及び「ＣＬＰＲ２」、及び、ドライブ「Ｄｒｉｖｅ１−Ｄｒｉｖｅ８」が取得される。
【０２１５】
Ｓ１８０１において、更に、統合ＬＰＡＲ作成パラメータ生成機能１７３が、図１２のサーバ／ストレージ接続テーブル１５４から、接続されているサーバのＨＢＡ情報を取得する。ここでは、ストレージＨＢＡ「ＨＢＡ１」及び「ＨＢＡ２」に対応したサーバＨＢＡ「ＨＢＡ−ａ」のサーバＨＢＡポート「Ｐｏｒｔ−ａ」、「Ｐｏｒｔ−ｂ」、「Ｐｏｒｔ−ｃ」及び「Ｐｏｒｔ−ｄ」が取得される。
【０２１６】
Ｓ１８０１において、更に、統合ＬＰＡＲ作成パラメータ生成機能１７３が、図４の割当てポリシーテーブル１４６から、特定されたＩ／Ｏサイズ「小」及び「大」の各々について、各リソース種類についての割当て種類を特定する。例えば、Ｉ／Ｏサイズ「大」（データＶＯＬ）について、サーバＨＢＡポートの割当て種類として「占有」が特定される。
【０２１７】
ここまで取得された情報は、以下の通りである。
＜サーバＬＰＡＲ情報（サーバリソースに関するパラメータ）＞
（＋）ＣＰＵコア数＝８
（＋）メモリ容量＝１２８ＧＢ
（＋）ＮＩＣポート数＝１
（＋）データＶＯＬに関するサーバＨＢＡ情報＝ポート数「２」、ＣＴＬ数「４」、割当て種類「ポート占有」
（＋）ログＶＯＬに関するサーバＨＢＡ情報＝ポート数「２」、ＣＴＬ数「２」、割当て種類「ＣＴＬ占有」
（＋）使用可能サーバＨＢＡポート＝「ＨＢＡ−ａ」の「Ｐｏｒｔ−ａ」、「Ｐｏｒｔ−ｂ」、「Ｐｏｒｔ−ｃ」及び「Ｐｏｒｔ−ｄ」
＜ストレージ設定情報（ストレージリソースに関するパラメータ＞
（＋）ドライブ情報＝Ｄｒｉｖｅ１−Ｄｒｉｖｅ８
（＋）データＶＯＬ＝ＶＯＬ容量「１２８ＧＢ」、ＶＯＬ数「４」、割当て種類「ＣＰＵ占有、メモリ占有」
（＋）ログＶＯＬ＝ＶＯＬ容量「１２８ＧＢ」、ＶＯＬ数「４」、割当て種類「ＣＰＵ共有、メモリ共有」
（＋）使用可能ＣＰＵ＝ＣＰＵ１、ＣＰＵ２
（＋）使用可能メモリ＝ＣＬＰＲ１、ＣＬＰＲ２
（＋）使用可能ストレージＨＢＡ＝ＨＢＡ１、ＨＢＡ２
【０２１８】
これらのパラメータが、統合ＬＰＡＲ作成ＷＦ１６０２に入力される。
【０２１９】
＜統合ＬＰＡＲ作成処理のリソース選択処理（Ｓ１９０１）＞
【０２２０】
リソース選択機能１９１が、優先度付けされた使用可能なサーバリソース組合せ候補の一覧を取得する。リソース選択機能１９１が、対応するストレージリソースが見つかるまで、ストレージリソース選択処理を実行し、最終的に使用するサーバリソース及びストレージリソースを一意に決定する。
【０２２１】
＜＜サーバリソース選択処理（Ｓ２００１）＞＞
【０２２２】
サーバリソース選択ＷＦ１６２１に、下記パラメータが入力される。
（＋）ＣＰＵコア数＝８
（＋）メモリ容量＝１２８ＧＢ
（＋）ＮＩＣポート数＝１
（＋）データＶＯＬに関するサーバＨＢＡ情報＝ポート数「２」、ＣＴＬ数「４」、割当て種類「ポート占有」
（＋）ログＶＯＬに関するサーバＨＢＡ情報＝ポート数「２」、ＣＴＬ数「２」、割当て種類「ＣＴＬ占有」
（＋）使用可能サーバＨＢＡポート＝「ＨＢＡ−ａ」の「Ｐｏｒｔ−ａ」、「Ｐｏｒｔ−ｂ」、「Ｐｏｒｔ−ｃ」及び「Ｐｏｒｔ−ｄ」
【０２２３】
リソース選択機能１９１が、管理情報６７０中の図示しないサーバ構成情報を参照する。サーバ構成情報は、サーバ１００毎に、サーバリソース種類、サーバリソース量、サーバリソース量と割当て状態（例えば、占有割当て、共有割当て、未割当て）の関係等を含んでよい。サーバ構成情報は、サーバＨＢＡテーブル１５２を含んでよい。リソース選択機能１９１は、上記の入力とサーバ構成情報から、上記の入力に該当するサーバリソースが確保可能な組み合わせを優先度付けして返す。優先度付けは、リソース空き状態など、何らかのポリシーによって行われてよい。この結果として、下記パラメータが出力される（「（＋＋Ｐ）」は、「（＋Ｐ）」に属するパラメータを意味する）。
（＋Ｐ）構成名＝構成案１
（＋＋Ｐ）使用サーバＩＤ＝サーバＡ
（＋＋Ｐ）ＣＰＵコア数＝８
（＋＋Ｐ）メモリ容量＝１２８ＧＢ
（＋＋Ｐ）ＮＩＣポート＝「ＮＩＣ−ａ」の「Ｐｏｒｔ−ｘ」
（＋＋Ｐ）データＶＯＬに関するサーバＨＢＡ情報＝Ｐｏｒｔ−ａ（占有割当て）、Ｐｏｒｔ−ｂ（占有割当て）
（＊）ログＶＯＬに関するサーバＨＢＡ情報＝Ｐｏｒｔ−ｃ（共有割当て）、Ｐｏｒｔ−ｄ（共有割当て）
（＋＋Ｐ）優先度＝１
【０２２４】
＜＜ストレージリソース選択処理（Ｓ２００３）＞＞
【０２２５】
使用サーバＩＤ「サーバＡ」に接続されているストレージリソースに関するパラメータとして下記がストレージリソース選択ＷＦ１６２２に入力される。
（＋）ドライブ情報＝Ｄｒｉｖｅ１−Ｄｒｉｖｅ８
（＋）データＶＯＬ＝ＶＯＬ容量「１２８ＧＢ」、ＶＯＬ数「４」、割当て種類「ＣＰＵ占有、メモリ占有」
（＋）ログＶＯＬ＝ＶＯＬ容量「１２８ＭＢ」、ＶＯＬ数「４」、割当て種類「ＣＰＵ共有、メモリ共有」
（＋）使用可能ＣＰＵ＝ＣＰＵ１、ＣＰＵ２
（＋）使用可能メモリ＝ＣＬＰＲ１、ＣＬＰＲ２
（＋）使用可能ストレージＨＢＡ＝ＨＢＡ１、ＨＢＡ２
【０２２６】
リソース選択機能１９１が、管理情報６７０中の図示しないストレージ構成情報を参照する。ストレージ構成情報は、ストレージ１２０毎に、ストレージリソース種類、ストレージリソース量、ストレージリソース量と割当て状態（例えば、占有割当て、共有割当て、未割当て）の関係等を含んでよい。ストレージ構成情報は、ストレージＨＢＡテーブル１５３及びストレージパーティションテーブル１５５を含んでよい。リソース選択機能１９１は、上記の入力とストレージ構成情報から、上記の入力に該当するストレージリソースを決定し例えば下記の出力パラメータを返す。ストレージリソースが確保できない場合、その旨を返す。
（＋Ｑ）ＶＯＬ種別＝データＶＯＬ
（＋＋Ｑ）ＶＯＬ容量＝１２８ＧＢ
（＋＋Ｑ）ＶＯＬ数＝４
（＋＋Ｑ）ＣＰＵ  ＩＤ／割当て種類＝ＣＰＵ１／占有割当て
（＋＋Ｑ）メモリＩＤ／割当て種類＝ＣＬＰＲ１／占有割当て
（＋＋Ｑ）データＶＯＬ用ＨＢＡ＝ＨＢＡ１
（＋＋Ｑ）使用するストレージプール＝プール１
（＋Ｒ）ＶＯＬ種別＝ログＶＯＬ
（＋＋Ｒ）ＶＯＬ容量＝１２８ＭＢ
（＋＋Ｒ）ＶＯＬ数＝４
（＋＋Ｒ）ＣＰＵ  ＩＤ／割当て種類＝ＣＰＵ２／共有割当て
（＋＋Ｒ）メモリＩＤ／割当て種類＝ＣＬＰＲ２／共有割当て
（＋＋Ｒ）データＶＯＬ用ＨＢＡ＝ＨＢＡ２
（＋＋Ｒ）使用するストレージプール＝プール２
【０２２７】
＜リソース割当て処理（Ｓ１９２１）＞
【０２２８】
リソース割当て機能１９２が、リソース選択処理から得られた情報を基に、サーバＬＰＡＲ作成及びストレージリソース割当てを行う。
【０２２９】
＜＜サーバＬＰＡＲ作成処理（Ｓ２１０１）＞＞
【０２３０】
下記のパラメータがサーバＬＰＡＲ作成ＷＦ１６３１に入力される。
選択サーバＩＤ＝サーバＡ
ＣＰＵコア（又はコア数）＝コア１−８
メモリ容量＝１２８ＧＢ
ＮＩＣポート＝「ＮＩＣ−ａ」の「Ｐｏｒｔ−ｘ」
データＶＯＬに関するサーバＨＢＡ情報＝Ｐｏｒｔ−ａ（占有割当て）、Ｐｏｒｔ−ｂ（占有割当て）
ログＶＯＬに関するサーバＨＢＡ情報＝Ｐｏｒｔ−ｃ（共有割当て）、Ｐｏｒｔ−ｄ（共有割当て）
【０２３１】
＜＜ストレージリソース割当て処理（Ｓ２１０２）＞＞
【０２３２】
ＶＯＬ用途に応じたＶＯＬが作成され、統合ＬＰＡＲ（サーバＬＰＡＲ）に割り当てられる（提供される）具体的には、例えば、Ｓ２１０２は、ＶＯＬ作成、ホストグループ作成、ホストグループへのＶＯＬ登録、及び、統合ＬＰＡＲへのホストグループ割当て（提供）を含んでよい。下記のパラメータがストレージリソース割当てＷＦ１６３２に入力される。
（＋Ｓ）ＶＯＬ種別＝データＶＯＬ
（＋＋Ｓ）ＶＯＬ容量＝１２８ＧＢ
（＋＋Ｓ）ＶＯＬ数＝４
（＋＋Ｓ）ＣＰＵ  ＩＤ／割当て種類＝ＣＰＵ１／占有割当て
（＋＋Ｓ）メモリＩＤ／割当て種類＝ＣＬＰＲ１／占有割当て
（＋＋Ｓ）データＶＯＬ用ＨＢＡ＝ＨＢＡ１
（＋＋Ｓ）サーバＨＢＡポート情報＝「Ｐｏｒｔ−ａ」のＷＷＮ（World  Wide  Name）「ｘｘｘ」、「Ｐｏｒｔ−ｂ」のＷＷＮ「ｙｙｙ」
（＋＋Ｓ）使用するストレージプール＝プール１
（＋Ｔ）ＶＯＬ種別＝ログＶＯＬ
（＋＋Ｔ）ＶＯＬ容量＝１２８ＭＢ
（＋＋Ｔ）ＶＯＬ数＝４
（＋＋Ｔ）ＣＰＵ  ＩＤ／割当て種類＝ＣＰＵ２／共有割当て
（＋＋Ｔ）メモリＩＤ／割当て種類＝ＣＬＰＲ２／共有割当て
（＋＋Ｔ）データＶＯＬ用ＨＢＡ＝ＨＢＡ２
（＋＋Ｔ）サーバＨＢＡポート情報＝「Ｐｏｒｔ−ｃ」のＷＷＮ「ｇｇｇ」、「Ｐｏｒｔ−ｄ」のＷＷＮ「ｋｋｋ」
（＋＋Ｔ）使用するストレージプール＝プール２
【０２３３】
上記の入力に対し、下記のパラメータが出力される。下記は、ＯＳ配信時に使用されるデータＶＯＬのＵＵＩＤ（Universally  Unique  Identifier）である。ここで、データＶＯＬが複数ある場合、複数のデータＶＯＬからリソース割当て機能１９２により選択されたデータＶＯＬが、ブートＶＯＬ（ブートに使用されるデータＶＯＬ）とされてよい。
（＋）ＵＵＩＤ＝ブートＶＯＬのＵＵＩＤ
（＋）ＬＵＮ＝ブートＶＯＬのＬＵＮ
【０２３４】
＜ＬＰＡＲブートオーダ設定処理（Ｓ２１０３）＞
【０２３５】
リソース割当て機能１９２が、作成された統合ＬＰＡＲがブートＶＯＬから起動することができるような設定を行う。その設定として、下記のパラメータがブートオーダ設定ＷＦ１６３３に入力され、そのパラメータが、ＬＰＡＲブートオーダ設定処理において統合ＬＰＡＲに設定される。
（＋）ブートＶＯＬに接続されたストレージＨＢＡのＷＷＮ＝「ＨＢＡ１」のＷＷＮ
（＋）ＬＵＮ（Logical  Unit  Number）＝ブートＶＯＬのＬＵＮ
【０２３６】
＜ＯＳ配信処理（Ｓ１９２２）＞
【０２３７】
ＯＳ配信機能１９３が、入力されたＡＰＰ名及びＡＰＰ用途のマスターイメージを、作成された統合ＬＰＡＲに配信する。このとき、ＯＳ配信機能１９３は、ＯＳ用の情報（例えば、起動イメージへのリンクを含んだ情報）及びＡＰＰ用の情報（例えばＡＰＰイメージへのリンクを含んだ情報）を統合ＬＰＡＲに自動設定してもよい。ＯＳ配信処理は、オプションであってもよい（必ずしも行われないでよい）。ＯＳ配信ＷＦ１６１３に、例えば下記情報が入力されてよい。
（＋）使用対象イメージ＝「ＡＰＰ−ａ」のマスターイメージ
（＋）ＵＵＩＤ＝ブートＶＯＬのＵＵＩＤ
【０２３８】
以上が、統合ＬＰＡＲ作成全体処理の具体例である。
【０２３９】
統合ＬＰＡＲ作成全体処理では、各ＷＦが実行され、少なくとも１つのＷＦの実行において割当て制御情報が参照されるが、本実施例では、ＷＦも割当て制御情報も変更可能である。そして、本実施例では、変更要求元ユーザがテナント管理者であるかシステム管理者であるか等のユーザ種類に応じて、変更要求元ユーザに対して許可される操作が、ランブック自動化プログラム６６０により制御される。以下、その一例を詳細に説明する。
【０２４０】
図２８は、変更制御処理の流れを示す。変更制御処理も、所定のＷＦの実行により行われる処理でよい。
【０２４１】
ランブック自動化プログラム６６０が、変更要求を受信する（Ｓ２８０１）。変更要求には、変更対象を表す情報が関連付けられており、ランブック自動化プログラム６６０は、その情報から、変更対象を特定できる。また、ランブック自動化プログラム６６０は、変更要求元ユーザが、テナント管理者であるかシステム管理者であるかといったユーザ種類がわかる。このようなユーザ種類は、受信した変更要求にユーザ情報が関連付けられそのユーザ情報を基に特定されてもよいし、変更要求受信前のログイン操作等により事前に特定されていてもよい。
【０２４２】
変更対象がＷＦの場合（Ｓ２８０２：Ｙｅｓ）、ランブック自動化プログラム６６０は、変更要求元ユーザがシステム管理者であれば（Ｓ２８１１：Ｙｅｓ）、ＷＦを変更要求に従い変更することを許可する（Ｓ２８１２）。例えば、ランブック自動化プログラム６６０は、変更ＯＫをシステム管理者に回答し、変更要求に従いＷＦを変更する。一方、変更要求元ユーザがテナント管理者であれば（Ｓ２８１１：Ｎｏ）、ランブック自動化プログラム６６０は、変更を拒否する（Ｓ２８１２）。例えば、ランブック自動化プログラム６６０は、変更ＮＧをテナント管理者に回答する。
【０２４３】
変更対象が割当て制御情報６７２のうちの少なくとも一部の場合（Ｓ２８０２：Ｎｏ、Ｓ２８０３：Ｙｅｓ）、ランブック自動化プログラム６６０は、変更要求元ユーザがシステム管理者であれば（Ｓ２８２１：Ｙｅｓ）、変更対象を変更要求に従い変更することを許可する（Ｓ２８２２）。具体的には、例えば、ランブック自動化プログラム６６０は、変更ＯＫをシステム管理者に回答して、割当て制御情報変更ＷＦを実行することで割当て制御情報変更処理を実行する（詳細は、後の図２４を参照して説明する）。ここでの変更対象は、例えば、統合ＬＰＡＲサイズテンプレートテーブル１４７（図５）、ストレージパーティションサイズテンプレートテーブル（図１４の参照符号１４０３参照）、及び割当てポリシーテーブル１４６（図４）のいずれかでよい。一方、変更要求元ユーザがテナント管理者であれば（Ｓ２８２１：Ｎｏ）、ランブック自動化プログラム６６０は、変更を拒否する（Ｓ２８２２）。例えば、ランブック自動化プログラム６６０は、変更ＮＧをテナント管理者に回答する。
【０２４４】
変更対象が、ＷＦでもなく、且つ、割当て制御情報６７２のうちの少なくとも一部でも無い場合（Ｓ２８０２：Ｎｏ、Ｓ２８０３：Ｎｏ）、ランブック自動化プログラム６６０は、変更要求に従う変更を許可する（Ｓ２８３１）。
【０２４５】
図２４は、割当て制御情報変更処理の流れを示す。
【０２４６】
ランブック自動化プログラム６６０のリソース割当て制御変更機能１９６が、Ｓ２４０１を実行する。Ｓ２４０１において、リソース割当て制御変更機能１９６は、割当て制御情報６７２における変更対象（例えば、割当て制御情報６７２のうちの指定されたテーブルが定義されている設定ファイル）を変更する。この結果、割当て制御情報６７２によって定義されている統合ＬＰＡＲ作成ポリシーが変更されたことになる。つまり、同一のパラメータが統合ＬＰＡＲ作成画面１４１（又は１６２）に入力されても、作成される統合ＬＰＡＲの構成（割当て種類、リソース種類及びリソース量のうちの少なくとも１つ）が、変更前と変更後で異なることになる。
【０２４７】
設定ファイルの変更方法は、ＡＰＰが提供するＧＵＩやコマンドを用いるか、ファイルを直接変更することで行うことができる。この処理を実行できるのは、上述したようにシステム管理者のみである。ＧＵＩ又はコマンドの場合、実行ユーザの権限チェックによって、変更可能ユーザがシステム管理者に制限され、ファイルの場合、アクセス権などによって、変更可能ユーザがシステム管理者に制限される。
【０２４８】
以上が、変更制御処理の一例である。
【０２４９】
本実施例によれば、ＷＦも割当て制御情報６７２も変更可能である。このため、例えば、ＡＰＰベンダ、管理サーバベンダ及びシステムエンジニア等のうちの少なくとも１つがＡＰＰ、サーバリソース及びストレージリソースのベストな組み合わせを検証し、テンプレート化することで，新しいＡＰＰ（例えば、追加又はバージョンアップされたＡＰＰ）に柔軟に対応することができる。このような対応を、例えば、割当て制御情報６７２の少なくとも一部と、統合ＬＰＡＲ作成パラメータ生成ＷＦの少なくとも一部を変更することで実現することが期待できる。割当て制御情報６７２の少なくとも一部の変更は、例えば、占有有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、共有割当てされるサーバリソース及びストレージリソースのリソース種類及びリソース量と、ＬＰＡＲ負荷特性との新たな対応関係を割当て制御情報に追加することでよい。
【０２５０】
また、本実施例によれば、統合ＬＰＡＲ作成全体処理は、変更可能（編集可能）なＷＦの実行により行われるが、統合ＬＰＡＲ作成全体処理に関わるＷＦの変更は、システム管理者にのみ許可される。一般に、システム管理者よりもテナント管理者の方が専門知識の量は少ないと考えられるが、そのようなテナント管理者に統合ＬＰＡＲ作成に関わるＷＦが変更されると、テナント管理者が要求する統合ＬＰＡＲ作成にエラーが生じてしまう可能性が生じる。本実施例によれば、そのような可能性を軽減できる。
【０２５１】
また、本実施例によれば、割当て制御情報６７２の変更も、システム管理者にのみ許可される。テナント管理者が割当て制御情報６７２を変更できると、例えば、割当てポリシーテーブル１４６の割当て種類「共有」を「占有」に変更できてしまう。そうすると、サーバストレージシステム１０００が意図しないバランスでのリソース枯渇（例えば、当初の見積りではＨＢＡ  ＣＴＬ１０７とストレージ１２０のＣＰＵ１２３が同じタイミングで枯渇するはずが、ＨＢＡ  ＣＴＬ１０７がかなり早くに枯渇してしまうこと）が生じ得る。本実施例では、そのような可能性を軽減できる。
【０２５２】
なお、システム管理者は、テナント管理者に対して、そのテナント管理者に対応したテナントの統合ＬＰＡＲ作成に関するＷＦを変更する権限、及び、そのテナント管理者に対応したテナントについての統合ＬＰＡＲ作成ポリシーを変更する権限のうちの少なくとも１つを与えてもよい。この場合、Ｓ２８１１及びＳ２８２１の少なくとも１つの「システム管理者」は、システム管理者に加えて、システム管理者から権限が与えられたテナント管理者も含む。統合ＬＰＡＲ作成ポリシー（割当て制御情報６７２）は、サーバストレージシステム１０００全体に共通でもよいし、テナント単位に独立して存在してもよい。後者の場合、テナント単位で、統合ＬＰＡＲ作成全体処理に関わるＷＦが存在してもよい。ＷＦの実行において参照される設定ファイル（テーブル）が変更されてもよい。具体的には、例えば、テナント毎に異なる統合ＬＰＡＲ作成パラメータ生成ＷＦ１６０１が用意されてもよいし、複数のテナントに共通の統合ＬＰＡＲ作成パラメータ生成ＷＦ１６０１の実行において参照されるテーブルが変更されてもよい。
【０２５３】
割当て制御情報６７２及びＷＦのうちの少なくとも１つの変更に関して、例えば、下記のユースケースがあり得る。
＜ユースケース１：リソースのバランス調整＞
サーバリソースがストレージリソースより少ない環境において、新たに作成するシステムの性能ＫＰＩ（Key Performance Indicator）が低い場合、対象ＡＰＰのサーバＬＰＡＲのＣＰＵ／メモリのリソース量を減らすことで、サーバリソースの枯渇の回避が期待される。
＜ユースケース２：ＡＰＰの追加又はバージョンアップ＞
ＡＰＰの追加又はバージョンアップによって必要なリソース量に変更（例えばメモリ容量の増加）がある場合、システム管理者が、割当て制御情報６７２の変更を行う。割当て制御情報６７２がテナント毎に存在し、且つ、テナント管理者に割当て制御情報６７２の変更権限がシステム管理者から与えられている場合、テナント管理者が、そのテナント管理者に対応したテナントに対応する割当て制御情報６７２を変更してもよい。
【０２５４】
さて、本実施例では、上述したように、必要なリソースを確保できないために統合ＬＰＡＲ作成が不可となることがある（図１９のＳ１９１１）。以下、その場合に行われる処理の詳細の一例を説明する。
【０２５５】
ランブック自動化プログラム６６０が、統合ＬＰＡＲの作成に失敗した場合（占有割当てされるサーバリソース及びストレージリソースのうちの少なくとも１つが不足の場合）、失敗の要因として、不足リソースのリソース種類を表す情報を含んだ情報であるエラー情報を出力（例えば表示）する。統合ＬＰＡＲ作成の指示元ユーザ（例えば、テナント管理者又はシステム管理者）は、出力されたエラー情報を見ることで、取るべきアクションを検討できる。
【０２５６】
具体的には、例えば、サーバリソース不足の場合、エラー情報は、リソース不足の生じたサーバ１００のＩＤ（例えば名前）と、不足サーバリソースのリソース種類（例えば、ＣＰＵ、メモリ、ＮＩＣポート、ＨＢＡポート）と、不足サーバリソースのリソース量との組を含んでよい。また、例えば、ストレージリソース不足の場合、エラー情報は、選択されたサーバリソースに接続されたストレージリソースのうちの不足ストレージリソースのリソース種類（例えば、ストレージＣＰＵ、ＨＢＡポート、ＣＬＰＲ、ＶＯＬ）とリソース量との組を含んでよい。エラー情報の出力は、画面表示でもよいし、ログ出力でもよい。
【０２５７】
例えば、ランブック自動化プログラム６６０は、サーバリソース選択処理において、各サーバ１００についてリソース確保の可否チェックが行うので、そのチェック結果を記憶部６３０に格納しておき、統合ＬＰＡＲ作成失敗時に、そのチェック結果を表す情報を含んだエラー情報を表示する。エラー情報は、確保できなかったサーバリソースを表す情報をサーバ毎に含んでいてもよいし（全てのチェック結果を含んでもよいし）、失敗要因（例えばメモリ不足）毎に不足サーバリソース情報（例えば、リソース種類及びリソース量）が分類されていてもよい。同じ失敗要因で確保できなかったリソースが複数ある場合、多くのリソースが確保された１以上のサーバ（少なくとも最も多くのリソースが確保されたサーバ）についての情報だけがエラー情報に含まれてもよい。
【０２５８】
以下、エラー情報の具体例を説明する。
【０２５９】
＜失敗要因がサーバリソース不足の場合＞
【０２６０】
サーバリソース選択処理において、いずれのサーバ１００についてもサーバリソースが不足した場合、リソース選択機能１９１が、図２９に示すサーバリソース確保状況テーブル２９０１を含んだエラー情報を表示する。図２９の例によれば、サーバＡでは、ＣＰＵ、ＮＩＣポート及びＨＢＡポートが不測しており、サーバＢ及びＣでは、メモリが不足している。このエラー情報を見た指示元ユーザが取るべきアクションは、下記２通りが考えられる。
【０２６１】
（アクション１：ＬＰＡＲサイズの変更）
指示元ユーザは、統合ＬＰＡＲサイズを大きめに設定していた場合（例えばサイズ＝Ｍの場合）、統合ＬＰＡＲサイズを小さくして（例えばサイズ＝Ｓにして）、統合ＬＰＡＲ作成指示を再度発行する。
【０２６２】
（アクション２：サーバリソース不足の解消）
指示元ユーザは、図２９に示すサーバリソース確保状況テーブル２９０１が示す不足サーバリソース種類について、そのテーブル２９０１が示す不足リソース量以上のリソース量を増やす。サーバリソースを増やす方法としては、例えば、サーバ１００に関するハードウェア（例えばサーバＨＢＡ）を追加する、又は、既存ＬＰＡＲ（例えば既存のサーバＬＰＡＲ又は統合ＬＰＡＲ）を削除することによりその既存ＬＰＡＲに占有割当てされていたサーバリソースを解放する。サーバリソース不足の解消後に、指示元ユーザは、統合ＬＰＡＲ作成指示を再度発行する。
【０２６３】
なお、アクション２の場合、サーバリソース不足が解消されても、ストレージリソースが確保される保証がない。このため、サーバリソース不足が解消されてもをストレージリソースを確保できずにサーバリソース不足の解消（サーバリソースの追加）が無駄になってしまう可能性がある。そのため、ランブック自動化プログラム６６０は、サーバリソース不足が解消されたとするサーバの指定を指示元ユーザから受け付け、その指定されたサーバについてサーバリソース不足が解消されたと仮定して、そのサーバについて、ストレージリソースの確保は可能か否かのシミュレーションを行う（つまり図２０のＳ２００３及びＳ２００４と同じ処理を疑似的に行う）。ランブック自動化プログラム６６０は、このシミュレーション結果を表示する。シミュレーション結果が、ストレージリソース確保の成功を表す場合（つまり、サーバリソース不足が解消された場合にストレージリソースが確保されることが特定された場合）、指示元ユーザは、安心して、指定したサーバについてサーバリソース不足を解消することができる。なお、シミュレーションは、リソース選択処理での入力と、リソース不足解消という仮定とを用いて、ストレージリソース選択ＷＦを実行することでよい。
【０２６４】
＜失敗要因がストレージリソース不足の場合＞
【０２６５】
図３０は、失敗要因がストレージリソース不足の場合にランブック自動化プログラム６６０により出力（例えば表示）されるエラー情報の一例を示す。
【０２６６】
エラー情報３０００は、サーバリソース確保状況テーブル３００１と、選択サーバリソース構成案情報３００２と、ストレージリソース確保状況テーブル３００４とを含む。
【０２６７】
サーバリソース確保状況テーブル３００１は、必要サーバリソース（Ｓ１８０１で取得されたパラメータを満たすサーバリソース）が見つかったサーバ（テーブル３００１が表すサーバ）について見つかった必要サーバリソースを表す情報を含む。
【０２６８】
選択サーバリソース構成案情報３００２は、必要サーバリソースが見つかったサーバについて取り得る構成案（サーバリソース組合せの構成案）の詳細を表す。
【０２６９】
ストレージリソース確保状況テーブル３００４は、不足ストレージリソースのリソース種類及び不足リソース量を構成案毎に表す。
【０２７０】
なお、サーバリソース確保状況テーブル３００１は、サーバリソース選択処理において候補から除外されたサーバリソース組合せ（サーバ）についての情報、すなわち、サーバリソース不足が生じたサーバについての情報を含んでよい。その情報は、失敗要因がサーバリソース不足の場合に表示される情報と同様の情報、すなわち、不足したサーバリソースのリソース種類及びリソース量を含んでよい。これにより、指示元ユーザは、ストレージリソース不足の解消とサーバリソース不足の解消のどちらが容易かを判断した上で、アクションを決定できる。
【０２７１】
図３０の例によれば、サーバリソース選択処理において、サーバＢのメモリが不足したことがわかる。また、ストレージリソース選択処理で、構成案１及び２のいずれについてもＣＬＰＲ不足が生じたことがわかる。この結果を見た指示元ユーザが取り得るアクションは、以下の３通りと考えられる。
【０２７２】
（アクションＡ：統合ＬＰＡＲサイズの変更）
指示元ユーザは、統合ＬＰＡＲサイズを大きめに設定していた場合（例えばサイズ＝Ｍの場合）、統合ＬＰＡＲサイズを小さくして（例えばサイズ＝Ｓにして）、統合ＬＰＡＲ作成指示を再度発行する。
【０２７３】
（アクションＢ：ストレージリソース不足の解消）
指示元ユーザは、ストレージリソース確保状況テーブル３００４が示す不足ストレージリソース種類について、そのテーブル３００４が示す不足リソース量以上のストレージリソース量を増やす。ストレージリソースを増やす方法としては、例えば、ストレージ１２０に関するハードウェア（例えばストレージＨＢＡ）を追加する、又は、既存統合ＬＰＡＲ又は既存ストレージパーティションを削除することによりその既存統合ＬＰＡＲ又は既存ストレージパーティションに占有割当てされていたストレージリソースを解放する。ストレージリソース不足の解消後に、指示元ユーザは、統合ＬＰＡＲ作成指示を再度発行する。
【０２７４】
（アクションＣ：サーバリソース不足の解消）
指示元ユーザは、サーバリソース確保状況テーブル３００１が示す不足サーバリソース種類について、そのテーブル３００１が示す不足リソース量以上のリソース量を増やす。それによるサーバリソース不足の解消後に、指示元ユーザは、統合ＬＰＡＲ作成指示を再度発行する。
【０２７５】
以上、一実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、上述した実施例では、統合ＬＰＡＲへの負荷の特性は、ＡＰＰ用途及びＶＯＬ用途に基づき期待（予測）される負荷の特性（例えば、Ｉ／Ｏ特性）であるが、それに代えて、実測値として得られた負荷の特性（例えば、Ｉ／Ｏ特性）であってもよい。
【０２７６】
また、サーバストレージシステム１０００は、予め役割がサーバ及びストレージ（又はストレージコントローラ）であるサーバ１００及びストレージ１２０を含んだシステムでもよいし、予め役割が決まっていない複数の計算機（例えば同じ複数の計算機）で構成されていて管理者からの役割設定により各計算機の役割がサーバであるかストレージ（ストレージコントローラ）であるか或いは両方であるかが決められるシステムであってもよい。計算機が、サーバとストレージの両方の役割を有する場合、計算機の一部のリソースがサーバリソースとして使用され、計算機の別の一部のリソースがストレージリソースとして使用される。
【０２７７】
また、実施例（例えば図２Ａ）によれば、サーバ１００からストレージ１２０にかけた論理分割も、Ｉ／Ｏ特性及びＡＰＰ用途等のうちの少なくとも１つに基づく論理分割（例えば本番系の論理分割）も、連続した複数の階層にそれぞれ対応した複数種類のリソースが論理分割（割当て制御）される。しかし、論理分割では、複数の階層が必ずしも厳密に連続している必要は無い。例えば、第１及び第２リソースは、それぞれ、論理分割可能な種類のリソースであっても、階層的に第１及び第２リソースの間にある第３リソースは、論理分割不可能な種類のリソースであることもある。この場合、上位から下位にかけたリソースの論理分割において、途中のリソースが論理分割されないことになる。しかし、このような場合も、実質的には、上位から下位にかけたリソースの論理分割（例えばサーバ１００からストレージ１２０にかけた論理分割）と言うことができる。なお、論理分割可能であるか不可能であるかは、リソースの種類とストレージ１２０の機能とのうちの少なくとも１つに依存してよい。
【符号の説明】
【０２７８】
１００…サーバ、１２０…ストレージシステム
【図１】
2017002185.tif 000003
【図２Ａ】
2017002185.tif 000004
【図２Ｂ】
2017002185.tif 000005
【図３】
2017002185.tif 000006
【図４】
2017002185.tif 000007
【図５】
2017002185.tif 000008
【図６】
2017002185.tif 000009
【図７】
2017002185.tif 000010
【図８】
2017002185.tif 000011
【図９】
2017002185.tif 000012
【図１０】
2017002185.tif 000013
【図１１】
2017002185.tif 000014
【図１２】
2017002185.tif 000015
【図１３】
2017002185.tif 000016
【図１４】
2017002185.tif 000017
【図１５】
2017002185.tif 000018
【図１６】
2017002185.tif 000019
【図１７】
2017002185.tif 000020
【図１８】
2017002185.tif 000021
【図１９】
2017002185.tif 000022
【図２０】
2017002185.tif 000023
【図２１】
2017002185.tif 000024
【図２２】
2017002185.tif 000025
【図２３】
2017002185.tif 000026
【図２４】
2017002185.tif 000027
【図２５】
2017002185.tif 000028
【図２６】
2017002185.tif 000029
【図２７】
2017002185.tif 000030
【図２８】
2017002185.tif 000031
【図２９】
2017002185.tif 000032
【図３０】
2017002185.tif 000033
【国際調査報告】
2017002185.tif 000034
2017002185.tif 000035
2017002185.tif 000036
2017002185.tif 000037