JP6448779B2 - サーバストレージシステムを含んだ計算機システム - Google Patents

Description

本発明は、概して、サーバストレージシステムのリソースの割当てに関する。

サーバとストレージを有するサーバストレージシステムが知られている。このようなサーバストレージシステムに複数のアプリケーションプログラム（ＡＰＰ）を集約することのニーズがある。いずれかのＡＰＰの性能が別のいずれかのＡＰＰの性能に影響を与えないよう、サーバストレージシステムのリソースを論理的に分割し、論理的に分割された異なるリソースで異なる複数のＡＰＰを実行することが望ましい。特許文献１によれば、サーバとストレージシステムのリソースを、複数のＡＰＰに占有的に割り当てることで論理的に分割できる。

特許第４２２７０３５号

上記のようにサーバからストレージにかけて論理的に分割すると、隣接する論理区画の影響は抑止できる。しかし、割り当てられてたリソース以上のリソースが必要になっている場合であっても、他の論理分割に占有的に割り当てられたリソースを使うことはできない。よって、全ての論理分割に関して従来技術のように論理分割を行うとリソースの利用効率が低下する。

よって、本願では、共存するアプリケーションプログラムの集約率の向上と性能影響の防止の両方を実現することを課題とする。

計算機システムが、サーバストレージシステムを有する。サーバストレージシステムが、複数種類のリソースを含んだ複数のリソースのうちの少なくとも一部が論理分割されることにより得られた複数の論理区画を有する。複数のリソースは、サーバシステムが有する複数種類のサーバリソースを含んだ複数のサーバリソースと、ストレージシステムが有する複数種類のストレージリソースを含んだ複数のストレージリソースとを含む。２以上の論理区画の各々に割り当てられるリソースは、占有割当てされたリソースと共有割当てされたリソースとの少なくとも一方を含む。論理区画に占有割当てされたリソースは、その論理区画に占有されるリソースである。論理区画に共有割当てされたリソースは、その論理区画を含む少なくとも２つの論理区画に共有され得るリソースである。２以上の論理区画の各々について、占有割当てされている複数のリソースの種類が、その論理区画への負荷の負荷特性によって異なっている。ここで言う「計算機システム」は、サーバストレージシステムそれ自体でもよいし、サーバストレージシステムとその管理システムとを含んでもよい。また、「論理区画への負荷の負荷特性」とは、論理区画に割り当てられたリソース（例えば、後述のＣＰＵ又はＨＢＡポート等）への負荷の負荷特性であってもよいし、論理区画に提供されたリソース（例えば、後述のＶＯＬ）への負荷の負荷特性であってもよい。また、「負荷特性」は、期待（予測）される負荷の特性であってもよいし、実測値として得られた負荷の特性であってもよい。また、論理区画に「割り当てられたリソース」とは、割り当てられた結果として論理区画の一構成要素となるリソースである。一方、論理区画に「提供されたリソース」とは、論理区画（又は論理区画を使用する外部の装置（又はコンピュータプログラム））により使用されるリソースである（典型的には、論理区画の一構成要素としては扱われない）。

ＡＰＰの集約率の向上と性能影響の防止の両方を実現することができる。

実施例１に係る計算機システムの構成を示す。 サーバストレージシステムのリソース割当て（論理分割）の幾つかの例を示す。 Ｉ／Ｏサイズテーブルの構成例を示す。 割当てポリシーテーブルの構成例を示す。 統合ＬＰＡＲサイズテンプレートテーブルの構成例を示す。 ＶＯＬテンプレートテーブルの構成例を示す。 統合ＬＰＡＲテーブルの構成例を示す。 サーバＬＰＡＲテーブルの構成例を示す。 サーバＬＰＡＲ／ＨＢＡテーブルの構成例を示す。 サーバＨＢＡテーブルの構成例を示す。 ストレージＨＢＡテーブルの構成例を示す。 サーバ／ストレージ接続テーブルの構成例を示す。 ストレージパーティションテーブルの構成例を示す。 ストレージパーティション作成画面の構成例を示す。 統合ＬＰＡＲ作成画面の構成例を示す。 ストレージパーティション作成処理の流れの一例を示す。 統合ＬＰＡＲ作成処理の流れの一例を示す。 実施例２に係る統合ＬＰＡＲのコピーと移動の各々の一例を示す。 統合ＬＰＡＲコピー処理の流れの一例を示す。 統合ＬＰＡＲ移動処理の流れの一例を示す。 サーバストレージシステムの構成例を示す。 統合管理サーバの構成例を示す。 実施例３に係る監視結果画面の一例を示す。

以下、一実施例を説明する。

以下の説明では、「×××テーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「×××テーブル」を「×××情報」と呼ぶことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。

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

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号（又は参照符号における共通符号）を使用し、同種の要素を区別して説明する場合は、要素識別情報（要素に割り振られたＩＤ又は名前等の識別情報）（又は参照符号）を使用することがある。

また、以下の説明では、Ｉ／Ｏ（Input/Output）要求は、ライト要求又はリード要求であり、アクセス要求と呼ばれてもよい。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜に記憶部（例えばメモリ）及び／又はインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置又はシステムが行う処理としてもよい。また、プロセッサは、制御部の一例であり、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ（例えばＣＰＵ）と記憶部を含み、記憶部はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布してよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

また、以下の説明では、管理システムは、一以上の計算機で構成されてよい。具体的には、例えば、管理計算機が情報を表示する場合（具体的には、例えば、管理計算機が自分の表示デバイスに情報を表示する、或いは、管理計算機（例えば管理サーバ）が表示用情報を遠隔の表示用計算機（例えば管理クライアント）に送信する場合）、管理計算機が管理システムである。また、例えば、複数の計算機で管理計算機と同等の機能が実現されている場合は、当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機を含んでよい）が、管理システムである。管理計算機（例えば管理システム）は、表示システムを含むＩ／Ｏシステムに接続されたインターフェースデバイスと、記憶部（例えばメモリ）と、インターフェースデバイス及び記憶部に接続されたプロセッサとを有してよい。表示システムは、管理計算機が有する表示デバイスでもよいし、管理計算機に接続された表示用計算機でもよい。Ｉ／Ｏシステムは、管理計算機が有するＩ／Ｏデバイス（例えばキーボード及びポインティングデバイス、タッチパネル）でもよいし、管理計算機に接続された表示用計算機又は別の計算機でもよい。管理計算機が「表示用情報を表示する」ことは、表示システムに表示用情報を表示することであり、これは、管理計算機が有する表示デバイスに表示用情報を表示することであってもよいし、管理計算機が表示用計算機に表示用情報を送信することであってもよい（後者の場合は表示用計算機によって表示用情報が表示される）。また、管理計算機が情報を入出力するとは、管理計算機が有するＩ／Ｏデバイスとの間で情報の入出力を行うことであってもよいし、管理計算機に接続された遠隔の計算機（例えば表示用計算機）との間で情報の入出力を行うことであってもよい。情報の出力は、情報の表示であってもよい。

また、以下の説明では、「サーバＬＰＡＲ」は、サーバの複数のリソースのうちの少なくとも１つを占有するＬＰＡＲである。また、「ストレージパーティション」は、ストレージの複数のリソースのうちの少なくとも１つを占有するＬＰＡＲである。

また、以下の説明では、「統合ＬＰＡＲ」は、サーバのリソースとストレージのリソースの両方が割り当てられたＬＰＡＲを表す便宜上の言葉であり、論理区画の一例である。つまりシステム内のサーバとストレージのリソースを論理的に分割した単位をいう。本実施例では、典型的には、統合ＬＰＡＲは、サーバＬＰＡＲの少なくとも一部とストレージパーティションの少なくとも一部を含む。統合ＬＰＡＲに割り当てられたサーバリソース及びストレージリソースは、いずれも、占有割当てされたリソースであっても共有割当てされたリソースであってもよい。具体的には、例えば、統合ＬＰＡＲには、少なくとも１つのサーバリソースが占有割当てされて、少なくとも１つのストレージリソースが占有割当て又は共有割当てされてもよい。また、例えば、統合ＬＰＡＲには、少なくとも１つのサーバリソースが共有割当てされて、少なくとも１つのストレージリソースが占有割当て又は共有割当てされてもよい。

また、以下の説明では、「リソース」は、サーバストレージシステムを構成するサーバ及びストレージの各々が有するコンポーネントでよい。コンポーネントとして、物理的なコンポーネント（例えばＣＰＵ、メモリ、ＨＢＡ（Host Bus Adapter）、ポート、ドライブ（物理記憶デバイス））もあれば、論理的なコンポーネント（例えばＶＯＬ（論理ボリューム））もある。また、サーバ及びストレージの外に存在するエレメント、例えば、サーバ及びストレージ間に存在する中継デバイス（例えば、ルーティング機能を有するスイッチ、或いはルーティング機能を有しないポート拡張デバイス）、サーバ間に存在する中継デバイス、及び、ストレージ間に存在する中継デバイスのいずれかも、「リソース」の一例として扱われてよい。また、そのような中継デバイスのコンポーネント（例えば、ポート、コア（コントローラ））も、「リソース」の一例として扱われてよい。

また、以下の説明では、「ＸがＹ１に占有割当てされる」とは、Ｘ（例えばリソース）がＹ１（例えば第１の統合ＬＰＡＲ）に割り当てられＹ１と同種の他のオブジェクトであるＹ２（例えば第２の統合ＬＰＡＲ）に割り当てられないことを意味する。結果として、Ｘは、Ｙ１に占有されることになる。一方、「ＸがＹ１に共有割当てされる」とは、ＸがＹ１に割り当てられるがＹ２にも割当て可能であることを意味する。結果として、Ｘは、Ｙ１及びＹ２に共有され得る。

また、以下の説明では、「占有リソース」は、占有割当てされたリソースであり、「共有リソース」は、共有割当てされたリソースである。

図１は、実施例１に係る計算機システムの構成を示す。

計算機システムは、サーバストレージシステム１０００と、サーバストレージシステム１０００を管理する統合管理サーバ１４０と、サーバストレージシステム１０００に集約された複数のＡＰＰ（アプリケーションプログラム）１０４を管理する１以上のＡＰＰ管理サーバ１６０とを有する。図示の例では、ＡＰＰ１０４として、ＡＰＰ−ａ及びＡＰＰ−ｂがあり、ＡＰＰ管理サーバ１６０として、ＡＰＰ−ａを管理するＡＰＰ管理サーバ１６０ａと、ＡＰＰ−ｂを管理するＡＰＰ管理サーバ１６０ｂとがある。

サーバストレージシステム１０００は、１以上のサーバ１００と１以上のストレージ１２０とを有する。サーバ１００は、ＣＰＵやメモリ等の複数のリソース（複数種類のリソース）を有するサーバシステム（１以上のサーバ装置）である。ストレージ１２０は、ＣＰＵやメモリ等の複数のリソース（複数種類のリソース）を有するストレージシステム（１以上のストレージ装置）である。サーバ１００及びストレージ１２０が１つの筺体に収納されていてもよい。

統合管理サーバ１４０は、統合管理プログラム６６０を実行する。統合管理プログラム６６０が実行されることにより、例えば、ストレージパーティション作成機能１４３及び統合ＬＰＡＲ作成機能１４４が発揮される。統合ＬＰＡＲ作成機能１４４が、統合ＬＰＡＲ（Logical Partitioning：論理区画）作成画面１４１を提供する。ストレージパーティション作成機能１４３が、ストレージパーティション作成画面１４２を提供する。画面１４１及び１４２のいずれも、例えばＧＵＩ（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）のＩＤを示す。ＣＬＰＲは、メモリ１２４（キャッシュメモリ）を論理分割することにより得られたキャッシュメモリＬＰＡＲである。ドライブ１３０６は、ストレージパーティションに属するドライブ１２５のＩＤを示す。

以上が、管理情報６７０に含まれる各テーブルの説明である。

次に、ストレージパーティション作成画面１４２及び統合ＬＰＡＲ作成画面１４１を説明する。

図１４は、ストレージパーティション作成画面１４２の構成例を示す。

ストレージパーティション作成画面１４２は、ストレージパーティションを作成するための情報の入力と、ストレージパーティション作成の指示とを受け付ける画面（例えばＧＵＩ）である。例えば、ストレージパーティション作成画面１４２には、ストレージパーティションＩＤ入力ＵＩ（ユーザインターフェース）１４０１と、環境名入力ＵＩ１４０２と、ストレージパーティションサイズ選択ＵＩ１４０３と、作成指示ＵＩ１４０４とが表示される。

ＵＩ１４０１は、作成するストレージパーティションのＩＤが入力されるＵＩであり、例えばテキスト入力欄である。ＵＩ１４０２は、作成するストレージパーティションが属する環境の名前（本番又は開発）が入力されるＵＩであり、例えばテキスト入力欄である。

ＵＩ１４０３は、ストレージパーティションサイズの選択を受け付けるＵＩであり、例えば、複数のストレージパーティションサイズにそれぞれ対応した複数のラジオボタンである。具体的には、例えば、ＵＩ１４０３は、ストレージパーティションサイズと、ストレージＨＢＡ１２１の数、ＣＰＵ１２３の数、メモリ１２４の容量、及びドライブ１２５の数との関係を表すテーブルを含む。そのテーブルは、管理情報６７０に含まれている情報それ自体、又は、管理情報６７０に含まれている情報及びポリシーを基に統合管理プログラム６６０により決定された情報でよい。ＵＩ１４０３が有するテーブルに、ストレージパーティションサイズ毎のラジオボタンが表示される。

ＵＩ１４０１及び１４０２に情報が入力され、ＵＩ１４０３を通じてシステム管理者所望のストレージパーティションが選択され、作成指示ＵＩ１４０４が操作された場合（例えば「作成」ボタンが押された場合）、ストレージパーティションが作成される。

図１５は、統合ＬＰＡＲ作成画面１４１の構成例を示す。

統合ＬＰＡＲ作成画面１４１は、統合ＬＰＡＲを作成するための情報の入力と、統合ＬＰＡＲの作成指示とを受け付ける画面（例えばＧＵＩ）である。統合ＬＰＡＲを作成するための情報として、統合ＬＰＡＲへの負荷の特性（具体的には、統合ＬＰＡＲへ提供されたＶＯＬへのＩ／Ｏの特性）を得るための一例である。本実施例においては、統合ＬＰＡＲの負荷特性を判定するために、その統合ＬＡＰＲで起動されるＡＰＰのＡＰＰ名及びＡＰＰ用途の入力を受ける。更に、その統合ＬＡＰＲ（その統合ＬＰＡＲに含まれるサーバＬＰＡＲ）に提供されるＶＯＬのＶＯＬ用途の入力、作成する統合ＬＰＡＲのサイズ、その統合ＬＰＡＲの環境の種類（本番又は開発）、等の情報の入力を受けるようにしてもよい。又、例えば、統合ＬＰＡＲを利用するアプリケーションのＩ／Ｏ特性情報自体、例えばＩ／Ｏサイズの入力を受け付けても良い。

統合ＬＰＡＲ作成画面１４１は、例えば、統合ＬＰＡＲ ＩＤ入力ＵＩ１５０１と、ＡＰＰ選択ＵＩ１５０２と、ＡＰＰ用途選択ＵＩ１５０３と、環境選択ＵＩ１５０４と、統合ＬＰＡＲサイズ選択ＵＩ１５０５と、リソース割当て方式選択ＵＩ１５０６と、作成指示ＵＩ１５０７とを有する。統合ＬＰＡＲ作成画面１４１は、更に、ＶＯＬ用途選択ＵＩ１５０８を有してもよい。

ＵＩ１５０１は、作成する統合ＬＰＡＲのＩＤが入力されるＵＩであり、例えばテキスト入力欄である。ＵＩ１５０２は、ＡＰＰ名の選択を受け付けるＵＩであり、例えば、複数のＡＰＰ名にそれぞれ対応した複数のラジオボタンである。ＵＩ１５０３は、ＡＰＰ用途の選択を受け付けるＵＩであり、例えば、複数のＡＰＰ用途にそれぞれ対応した複数のラジオボタンである。ＵＩ１５０４は、環境の選択を受け付けるＵＩであり、例えば、複数の環境にそれぞれ対応した複数のラジオボタンである。ＵＩ１５０５は、統合ＬＰＡＲサイズの選択を受け付けるＵＩであり、例えば、複数の統合ＬＰＡＲサイズにそれぞれ対応した複数のラジオボタンである。ＵＩ１５０８は、ＶＯＬ用途の選択を受け付けるＵＩであり、例えば、複数のＶＯＬ用途にそれぞれ対応した複数のチェックボックスである。つまり、２以上のＶＯＬ用途を選択することができる。ＵＩ１５０６は、リソース割当て方式の選択を受け付けるＵＩであり、例えば、複数のリソース割当て方式にそれぞれ対応した複数のラジオボタンである。なお、「固定占有」とは、サーバＬＰＡＲの稼働状況（例えば起動、停止）等に関わらずリソースの占有割当てが維持されることを意味する。「動的占有」とは、サーバＬＰＡＲの稼働状況が起動しているときのみリソースを占有割当てすることであり、サーバＬＰＡＲ停止時にリソースを占有しなくてもよいことを意味する。「共有」は、リソースは全て共有割当てされてもよいことを意味する。

ＵＩ１５０１に統合ＬＰＡＲ ＩＤが入力され、ＵＩ１５０２〜１５０６及び１５０８を通じてＡＰＰ、ＡＰＰ用途、環境、統合ＬＰＡＲサイズ、リソース割当て方式及びＶＯＬ用途が選択され、作成指示ＵＩ１５０７が操作された場合（例えば「作成」ボタンが押された場合）、統合ＬＰＡＲが作成される。

以上が、ストレージパーティション作成画面１４２及び統合ＬＰＡＲ作成画面１４１の説明である。なお、画面１４２又は１４１に表示される選択肢（例えば、ストレージパーティションサイズ、ＡＰＰ、環境名、ＡＰＰ用途、統合ＬＰＡＲサイズ等）は、適宜に、追加、変更又は削除されてよい。また、ＡＰＰ管理サーバ１６０に表示される統合ＬＰＡＲ作成画面１６２は、ＡＰＰ選択ＵＩに表示されるＡＰＰが、そのＡＰＰ管理サーバ１６０の管理対象のＡＰＰに制限されてよい。

次に、実施例１で行われる処理を説明する。

図１６は、ストレージパーティション作成処理の流れの一例を示す。

ステップ２０１において、統合管理プログラム６６０は、ストレージパーティション作成画面１４２を表示し、その画面１４２を介して、システム管理者から、ストレージパーティションＩＤ、環境名、及びストレージパーティションサイズの入力（選択）と、ストレージパーティション作成指示とを受け付ける。そのストレージパーティション作成指示に応答して、ステップ２０２以降が行われる。入力されたストレージパーティションＩＤに対応したストレージパーティションを、図１６の説明において、「対象ストレージパーティション」と言う。

ステップ２０２において、統合管理プログラム６６０は、ストレージ１２０にＲＡＩＤグループ作成指示を送信する。ＲＡＩＤグループの作成指示には、画面１４２を介して入力された情報（例えば、選択されたストレージパーティションサイズに対応したドライブ数等）が含まれる。この結果、ストレージ１２０は、作成指示に応答して、その作成指示に関連付いた数のドライブで構成されたＲＡＩＤグループを作成する。ＲＡＩＤグループのＲＡＩＤレベルは、予め定められたＲＡＩＤレベルでよい。異なる種類のドライブ１２５が混在している場合（例えばＨＤＤとＳＳＤが混在している場合）、同種のドライブで構成されたＲＡＩＤグループ（例えば、ＨＤＤのＲＡＩＤグループ、又は、ＳＳＤのＲＡＩＤグループ）が作成されてよい。また、作成されたＲＡＩＤグループに基づくプールも作成されてよい。

ステップ２０３において、統合管理プログラム６６０は、ストレージ１２０にＣＬＰＲ作成指示を送信する。ＣＬＡＲの作成指示には、画面１４２を介して入力された情報（例えば、選択されたストレージパーティションサイズに対応したメモリ容量）が含まれる。ストレージ１２０は、その作成指示に応答して、その作成指示に関連付いたメモリ容量のＣＬＰＲを作成する。異なる種類のドライブ１２５が混在している場合（例えばＨＤＤとＳＳＤが混在している場合）、ドライブ種類別に、ＣＬＰＲが作成されてよい。

ステップ２０４において、統合管理プログラム６６０は、画面１４２を介して入力された情報と、作成したＲＡＩＤグループ及びＣＬＰＲの情報に基づき、ストレージパーティションテーブル１５５を更新する。例えば、選択されたストレージパーティションサイズに対応したＨＢＡ数、ＣＰＵ数、メモリ容量及びドライブ数に従ってストレージ１２０により決定されたストレージＨＢＡ１２１、ＣＰＵ１２３、ＣＬＰＡＲ及びドライブ１２５の各々のＩＤが、ストレージ１２０から統合管理プログラム６６０に伝えられ、統合管理プログラム６６０が、それらのＩＤと、入力されたストレージパーティションＩＤと、入力された環境名（本番又は開発）とを、対象ストレージパーティションに対応するエントリ（ストレージパーティションテーブル１５５におけるエントリ）に登録する。

ストレージＨＢＡ１２１及びＣＰＵ１２３の決定は、Ｓ２０２、Ｓ２０３又は別のステップにおいて行われてよい。例えば、統合管理プログラム６６０は、選択されたストレージパーティションサイズに対応したＨＢＡ数及びＣＰＵ数を関連付けた指示（例えば、ＲＡＩＤグループ作成指示、ＣＬＰＲ作成指示又は別の指示）を、ストレージ１２０に送信してよい。その指示に応答して、ストレージ１２０が、その指示に関連付いているＨＢＡ数及びＣＰＵ数に従い、対象ストレージパーティションに含めるストレージＨＢＡ１２１及びＣＰＵ１２３を決定してよい。

このようなストレージパーティション作成処理は、統合ＬＰＡＲ作成処理において行われてもよいが、本実施例では、ストレージパーティション作成処理は、統合ＬＰＡＲ作成処理よりも前に行われる。言い換えれば、ストレージパーティション作成処理の終了後に、統合ＬＰＡＲ作成処理が開始される。ストレージパーティション作成処理では、ドライブ１２５間のデータ移動を伴う負荷の高い処理が必要となる場合があり、統合ＬＰＡＲ作成処理においてストレージパーティション作成を実行するようにすると、統合ＬＰＡＲ作成処理の開始から終了までに長時間を要してしまう可能性がある。このため、ストレージパーティション作成処理を先に行うことで、統合ＬＰＡＲ作成処理にかかる時間の短縮が期待できる。

図１７は、統合ＬＰＡＲ作成処理の流れの一例を示す。

ステップ２２１において、統合管理プログラム６６０は、統合ＬＰＡＲ作成画面１４１（又は１６２）を介して、システム管理者（又はＡＰＰ管理者）から、ストレージパーティションＩＤ、環境名、ＡＰＰ名、ＡＰＰ用途、ＶＯＬ用途、統合ＬＰＡＲサイズ及びリソース割当て方式の入力（選択）と、統合ＬＰＡＲ作成指示とを受け付ける。その統合ＬＰＡＲ作成指示に応答して、ステップ２２２以降が行われる。入力された統合ＬＰＡＲ ＩＤに対応した統合ＬＰＡＲを、図１７の説明において、「対象統合ＬＰＡＲ」と言う。

ステップ２２２において、統合管理プログラム６６０は、ストレージパーティションテーブル１５５を参照し、ステップ２２１で選択された環境に対応したストレージパーティションを選択する。

ステップ２２３において、統合管理プログラム６６０は、Ｉ／Ｏサイズテーブル１４５を参照し、ステップ２２１で選択されたＡＰＰ、ＡＰＰ用途及びＶＯＬ用途に対応するＩ／Ｏサイズを特定する。また、このステップ２２３において、統合管理プログラム６６０は、ＶＯＬテンプレートテーブル１４８を参照し、ステップ２２１で選択されたＡＰＰ、ＡＰＰ用途及び統合ＬＰＡＲサイズに対応するＶＯＬ用途、ＶＯＬ容量及びＶＯＬ数を特定してよい。そして、統合管理プログラム６６０は、特定したＶＯＬ数及びＶＯＬ容量通りのＶＯＬを、ステップ２２２で選択されたストレージパーティションに基づき作成し、作成したＶＯＬを、ステップ２２１で選択されたＡＰＰを実行することになる対象統合ＬＰＡＲに割り当ててよい。ＡＰＰ名、ＡＰＰ用途から特定されるＶＯＬ用途が複数ある場合は、それぞれのＶＯＬ用途において指定されたＶＯＬ容量、ＶＯＬ数を作成し、対象統合ＬＰＡＲに割り当ててよい。

ステップ２２４において、統合管理プログラム６６０は、選択されたリソース割当てポリシーが、占有割当て（「固有占有」又は「動的占有」）か否かを判断する。この判断の結果が肯定の場合（ステップ２２４：Ｙｅｓ）、ステップ２２５が行われる。この判断の結果が否定の場合（ステップ２２４：Ｎｏ）、ステップ２３２が行われる。尚、このステップは、１５０６の入力を受けている場合に実行される。

ステップ２２５において、統合管理プログラム６６０は、ステップ２２３で特定されたＩ／Ｏサイズが「大」か否かを判断する。この判断の結果が肯定の場合（ステップ２２５：Ｙｅｓ）、ステップ２２６が行われる。この判断の結果が否定の場合（ステップ２２５：Ｎｏ）、ステップ２２９が行われる。Ｉ／Ｏサイズ「大」のＶＯＬと、Ｉ／Ｏサイズ「小」のＶＯＬとが混在する場合（例えば図２のＶＯＬ−ｃ及びＶＯＬ−ｄ）、統合管理プログラム６６０は、Ｉ／Ｏサイズ「大」のＶＯＬについては、ステップ２２６を実行し、Ｉ／Ｏサイズ「小」のＶＯＬについては、ステップ２２９を実行する。

ステップ２２６において、統合管理プログラム６６０は、対象統合ＬＰＡＲに、ストレージＨＢＡポート１２２を占有割当てする。具体的には、例えば、以下の処理が行われる。
（２２６−１）統合管理プログラム６６０は、統合ＬＰＡＲサイズテンプレートテーブル１４７を参照し、ステップ２２１で選択された統合ＬＰＡＲサイズと、Ｉ／Ｏサイズ「大」とに対応したＨＢＡポート数５０６を特定する。
（２２６−２）特定したＨＢＡポート数５０６と同数のストレージＨＢＡポート１２２を割当てるまで、以下の処理（２２６−２−１）及び（２２６−２−２）が繰り返される。
（２２６−２−１）統合管理プログラム６６０は、ストレージＨＢＡテーブル１５３を参照し、ポート割当て１１０４が「未割当て」で、Ｉ／Ｏサイズ１１０５が「大」（又は「未割当て」）で、割当先１１０６が「未割当て」で、環境１１０７が、ステップ２２１で選択された環境と同じであるストレージＨＢＡポートを特定する。
（２２６−２−２）統合管理プログラム６６０は、特定したストレージＨＢＡポートを、対象統合ＬＰＡＲに占有割当てする。具体的には、例えば、統合管理プログラム６６０は、特定したストレージＨＢＡポートに対応したエントリ（ストレージＨＢＡテーブル１５３内のエントリ）について、ポート割当て１１０４を「占有」に更新し、割当先１１０６を、ステップ２２１で入力された統合ＬＰＡＲ ＩＤに更新する。

ステップ２２７において、統合管理プログラム６６０は、対象統合ＬＰＡＲにサーバＨＢＡポート１０８を占有割当てする。具体的には、例えば、以下の処理が行われる。
（２２７−１）統合管理プログラム６６０は、サーバ／ストレージ接続テーブル１５４を参照し、ステップ２２６で割当てたストレージＨＢＡポート１２２と接続されているサーバＨＢＡポート１０８を特定する。
（２２７−２）統合管理プログラム６６０は、特定されたサーバＨＢＡポート１０８を、対象統合ＬＰＡＲに占有割当てする。具体的には、例えば、統合管理プログラム６６０は、特定されたサーバＨＢＡポート１０８に対応するエントリ（サーバＨＢＡテーブル１５２内のエントリ）について、ポート割当て１１０４を「占有」に更新し、Ｉ／Ｏサイズ１００７を「大」に更新し、割当先１００８を、ステップ２２１で入力された統合ＬＰＡＲ ＩＤに更新する。

本実施例では、サーバＨＢＡポート１０８とストレージＨＢＡポート１２２との対応関係が１：１であるが、サーバ１００とストレージ１２０とをスイッチを介して接続することで、サーバＨＢＡポート１０８とストレージＨＢＡポート１２２との対応関係が１：ｎ、ｍ：１又はｍ：ｎとなってもよい（ｎ、ｍはそれぞれ２以上の整数）。１つのストレージＨＢＡポート１２２に、複数のサーバＨＢＡポート１０８とが接続されている場合、統合管理プログラム６６０は、サーバＨＢＡテーブル１５２を参照し、ポート割当て１００４が「未割当て」であり、環境１００９、ステップ２２１で選択された環境と同じであるサーバＨＢＡポート１０８を、対象統合ＬＰＡＲに割当てる。この処理により、選択された環境によって、割当てられるサーバＨＢＡポート１０８を違えることができる。すなわち、サーバＨＢＡポート１０８に環境に従い分類できる。なお、適切なサーバＨＢＡポート１０８がない場合、統合管理プログラム６６０は、ステップ２２６に戻って、別のストレージＨＢＡポート１２２を選択してよい。

ステップ２２８において、統合管理プログラム６６０は、対象統合ＬＰＡＲにサーバＨＢＡ ＣＴＬ１０７を占有割当てする。具体的には、例えば、以下の処理が行われる。
（２２８−１）統合管理プログラム６６０は、サーバＨＢＡテーブル１５２を参照し、ステップ２２７で占有割当てしたサーバＨＢＡポート１０８と接続されているサーバＨＢＡ ＣＴＬ１０７を特定する。
（２２８−２）統合管理プログラム６６０は、特定したサーバＨＢＡ ＣＴＬ１０７を、対象統合ＬＰＡＲに占有割当てする。具体的には、例えば、統合管理プログラム６６０は、特定したサーバＨＢＡ ＣＴＬ１０７に対応するエントリ（サーバＨＢＡテーブル１５２内のエントリ）について、ＣＴＬ割当て１００６を「占有」に更新し、Ｉ／Ｏサイズ１００７を「大」に更新し、割当先１００８を、ステップ２２１で入力された統合ＬＰＡＲ ＩＤに更新する。

ステップ２２９において、統合管理プログラム６６０は、対象統合ＬＰＡＲに、ストレージＨＢＡポート１２２を共有割当てする。具体的には、例えば、以下の処理が行われる。
（２２９−１）統合管理プログラム６６０は、統合ＬＰＡＲサイズテンプレートテーブル１４７を参照し、ステップ２２１で選択された統合ＬＰＡＲサイズと、Ｉ／Ｏサイズ「小」とに対応したＨＢＡポート数５０６を特定する。
（２２９−２）特定したＨＢＡポート数５０６と同数のストレージＨＢＡポート１２２を割当てるまで、以下の処理（２２９−２−１）及び（２２９−２−２）が繰り返される。
（２２９−２−１）統合管理プログラム６６０は、ストレージＨＢＡテーブル１５３を参照し、ポート割当て１１０４が「共有」又は「未割当て」）で、Ｉ／Ｏサイズ１１０５が「小」（又は「未割当て」）で、割当先１１０６が「未割当て」で、環境１１０７が、ステップ２２１で選択された環境と同じであるストレージＨＢＡポートを特定する。
（２２９−２−２）統合管理プログラム６６０は、特定したストレージＨＢＡポートを、対象統合ＬＰＡＲに共有割当てする。具体的には、例えば、統合管理プログラム６６０は、特定したストレージＨＢＡポートに対応したエントリ（ストレージＨＢＡテーブル１５３内のエントリ）について、ポート割当て１１０４を「共有」に更新し、割当先１１０６を、ステップ２２１で入力された統合ＬＰＡＲ ＩＤに更新する。

ステップ２３０において、統合管理プログラム６６０は、対象統合ＬＰＡＲにサーバＨＢＡポート１０８を共有割当てする。具体的には、例えば、以下の処理が行われる。
（２３０−１）統合管理プログラム６６０は、サーバ／ストレージ接続テーブル１５４を参照し、ステップ２２６で割当てたストレージＨＢＡポート１２２と接続されているサーバＨＢＡポート１０８を特定する。
（２３０−２）統合管理プログラム６６０は、特定されたサーバＨＢＡポート１０８を、対象統合ＬＰＡＲに占有割当てする。具体的には、例えば、統合管理プログラム６６０は、特定されたサーバＨＢＡポート１０８に対応するエントリ（サーバＨＢＡテーブル１５２内のエントリ）について、ポート割当て１１０４を「共有」に更新し、Ｉ／Ｏサイズ１００７を「小」に更新し、割当先１００８を、ステップ２２１で入力された統合ＬＰＡＲ ＩＤに更新する。

上述したように、１つのストレージＨＢＡポート１２２に、複数のサーバＨＢＡポート１０８とが接続されていてもよい。この場合、統合管理プログラム６６０は、サーバＨＢＡテーブル１５２を参照し、ポート割当て１００４が「共有」又は「未割当て」であり、環境１００９、ステップ２２１で選択された環境と同じであるサーバＨＢＡポート１０８を、対象統合ＬＰＡＲに割当てる。

ステップ２３１において、ステップ２２８と同様の処理が行われる。但し、ステップ２３１では、割り当てられるサーバＨＢＡ ＣＴＬ１０７に対応するＩ／Ｏサイズ１００７は「小」に更新される。

ステップ２３２において、統合管理プログラム６６０は、対象統合ＬＰＡＲにストレージＨＢＡポート１２２を共有割当てする。詳細はステップ２２９と同様である。

ステップ２３３において、統合管理プログラム６６０は、対象統合ＬＰＡＲにサーバＨＢＡポート１０８を共有割当てする。詳細はステップ２３０と同様である。

ステップ２３４において、統合管理プログラム６６０は、対象統合ＬＰＡＲにサーバＨＢＡ ＣＴＬ１０７を共有割当てする。具体的には、例えば、以下の処理が行われる。
（２３４−１）統合管理プログラム６６０は、サーバＨＢＡテーブル１５２を参照し、ステップ２３３で共有割当てしたサーバＨＢＡポート１０８と接続されていて、ＣＴＬ割当てが「共有」または「未割当て」であるサーバＨＢＡ ＣＴＬ１０７を特定する。
（２３４−２）統合管理プログラム６６０は、特定されたサーバＨＢＡ ＣＴＬ１０７を、対象統合ＬＰＡＲに共有割当てする。具体的には、例えば、統合管理プログラム６６０は、特定されたサーバＨＢＡポート１０８に対応するエントリ（サーバＨＢＡテーブル１５２内のエントリ）について、ポート割当て１１０４を「共有」に更新し、Ｉ／Ｏサイズ１００７を、ステップ２２３で特定されたＩ／Ｏサイズに更新し、割当先１００８を、ステップ２２１で入力された統合ＬＰＡＲ ＩＤに更新する。

ステップ２３５において、統合管理プログラム６６０は、統合ＬＰＡＲを完成する。具体的には、例えば、以下の処理が行われる。
（２３５−１）統合管理プログラム６６０は、ステップ２２２において選択したストレージパーティションとストレージパーティションテーブル１５５を参照し、当該ストレージパーティションに属するＣＰＵ、メモリ、ドライブを特定する。統合管理プログラム６６０は、ステップ２２３において特定したＶＯＬ容量、ＶＯＬ数に基づくＶＯＬ作成を指示し、当該ストレージパーティションに属するＣＰＵ、メモリ、ドライブを使用する指示をストレージ１２０に行う。
（２３５−２）ストレージ１２０は、ステップ２３５−１において指示されたストレージパーティション内に、指示された容量のＶＯＬを指示された個数、指示されたドライブ上に作成する。ストレージ１２０は、作成したＶＯＬへのアクセスに、指示されたＣＰＵ、メモリを使用するよう設定する。
（２３５−３）統合管理プログラム６６０は、ステップ２２６、ステップ２２９、ステップ２３２において割り当てたストレージＨＢＡの割当てをストレージ１２０に指示する。
（２３５−４）ストレージ１２０は、ステップ２３５−３において指示されたストレージＨＢＡからのみ、ステップ２３５−２において作成したＶＯＬにアクセスできるよう設定する。本設定により、他のストレージＨＢＡからの当該ＶＯＬへのアクセスを防止できる。尚、予め少なくともストレージシステム内に存在するＣＰＵ、メモリ、ストレージＨＢＡポートを含むリソースは統合管理サーバ内に記憶管理されており、各リソース毎に割り当て済みであるかどうかも管理されているものとする。
（２３５−５）統合管理プログラム６６０は、統合ＬＰＡＲサイズテンプレートテーブル１４７を参照し、ステップ２２１で選択された統合ＬＰＡＲサイズに対応するＬＰＡＲ ＣＰＵコア数５０２、ＬＰＡＲメモリ容量５０３及びＬＰＡＲ ＮＩＣポート数５０４を特定する。
（２３５−６）統合管理プログラム６６０は、特定されたＣＰＵコア数と同数のＣＰＵコア（ＣＰＵ１０２のコア）と、特定されたＬＰＡＲメモリ容量５０３と同総容量のメモリ１０３と、特定されたＬＰＡＲ ＮＩＣポート数５０４と同数のＮＩＣポートと、ステップ２２６〜ステップ２３４で割当てたサーバＨＢＡポート１０８及びサーバＨＢＡ ＣＴＬ１０７とに基づき、サーバＬＰＡＲ１０１の作成をサーバ１００に指示する。
（２３５−７）サーバ１００は、ステップ２３５−２の指示に従い、ＣＰＵコア、メモリ、ＮＩＣポート、サーバＨＢＡポート、サーバＨＢＡ ＣＴＬを割り当てる。尚、予め少なくともサーバシステム内に存在するＣＰＵコア数、メモリ容量、ＮＩＣポート及びサーバＨＢＡポート、サーバＨＢＡ ＣＴＬを含むリソースは、統合管理サーバ内に記憶管理されており、各リソース毎に割り当て済みであるかどうかも管理されているものとする。ステップ２３５−３において占有割当てされたリソースは、他のサーバＬＰＡＲ１０１に割り当てられないように設定され、他のサーバＬＰＡＲ１０１上のＡＰＰからアクセスできないように設定されるため、他のサーバＬＰＡＲ１０１から使用されることはない。
（２３５−８）統合管理プログラム６６０は、作成したサーバＬＰＡＲ１０１の構成（割り当てられたリソースに関する情報）を、統合ＬＰＡＲテーブル１４９、サーバＬＰＡＲテーブル１５０、及びサーバＬＰＡＲ／ＨＢＡテーブル１５１に反映する。

以上が、統合ＬＰＡＲ作成処理の流れの一例である。本処理により、起動されるＡＰＰのＩ／Ｏ特性に応じて、サーバとストレージ両方のリソースのそれぞれについて一連の流れで占有／共有の別が決定されて論理区画が形成される。統合ＬＰＡＲ作成処理では、割り当てられるリソースを決定できればよく、処理の順序については本実施例で示した従う徐に限らない。但し、既に設定したリソースとの接続関係は考慮する必要がある。具体的には、Ｉ／Ｏサイズ「小」のＡＰＰが動作するサーバＬＰＡＲ１０１には、Ｉ／Ｏサイズが「小」であるストレージＨＢＡを割り当てる。また、環境を本番と指定したサーバＬＰＡＲ１０１は、本番用ストレージパーティションに属するリソースのみを使用する。また、要求に対して十分なリソースが確保できない場合には、例えば、未割当てリソースが無い故に統合ＬＰＡＲを作成できない場合、実施例２の統合ＬＰＡＲ移動により未割当てリソースが用意された後、統合ＬＰＡＲが作成されてもよい。占有割当てせずに共有割当てすることを利用者に提案してもよく、リソースが不足し統合ＬＰＡＲを作成できない旨を表示してもよい。

また、Ｉ／Ｏサイズテーブル１４５、割当てポリシーテーブル１４６、統合ＬＰＡＲサイズテンプレートテーブル１４７、サーバＬＰＡＲテーブル１５０、サーバＬＰＡＲ／ＨＢＡテーブル１５１、サーバＨＢＡテーブル１５２、ストレージＨＢＡテーブル１５３、及びストレージパーティションテーブル１５５から統合ＬＰＡＲテーブル１４９が作成されてもよい。また、その後の管理のために、統合管理プログラム６６０により、上述したテーブル（例えば、サーバＬＰＡＲ／ＨＢＡテーブル１５１、サーバＨＢＡテーブル１５２及びストレージＨＢＡテーブル１５３）のうちの少なくとも１つに基づき、リソース毎に割当て種別（共有であるか占有であるか）が表示されてよい。具体的には、例えば、実施例３で説明する画面（図２３）のような管理画面に、リソース毎に割当て種別が表示されてよい。

実施例１によれば、サーバストレージシステム１０００が、本番系と開発系とにサーバ１００からストレージ１２０にかけて論理分割される。これにより、開発系の負荷が本番系の性能に悪影響を与えないようにすることができる。

また、実施例１によれば、少なくとも本番系について、統合ＬＰＡＲにリソースが占有割当てされるか共有割当てされるかが、統合ＬＰＡＲに提供されるＶＯＬに対する負荷の特性と、割当て対象のリソースの種類とに基づいて決定される。具体的には、例えば、Ｉ／Ｏサイズ「大」のＶＯＬとＩ／Ｏサイズ「小」のＶＯＬ間で、サーバＬＰＡＲ１０１からストレージＨＢＡ１２２にかけたリソースが分割され、Ｉ／Ｏサイズ「大」のＶＯＬ間で、サーバＬＰＡＲ１０１からストレージＨＢＡポート１２２にかけたリソースが分割され、Ｉ／Ｏサイズ「小」のＶＯＬ間で、サーバＬＰＡＲ１０１のからサーバＨＢＡ ＣＴＬ１０７にかけたリソースが分割される。本構成により、統合ＬＰＡＲ（論理区画）で動作されるＡＰＰ（アプリケーション）のＩ／Ｏ特性をふまえて、負荷がかかる部分の特定リソースについて占有割り当てすることが可能となり、ＡＰＰの集約率の向上と性能影響の防止の両方を実現することが期待できる。なお、実施例１では、負荷特性は、ＡＰＰ名、ＡＰＰ用途及びＶＯＬ用途のうちの少なくともＡＰＰ用途及びＶＯＬ用途の組合せから一義的に定まるが、ＡＰＰ名、ＡＰＰ用途及びＶＯＬ用途のうちの少なくとも１つに代えて別の要素から（例えばＩ／Ｏ特性それ自体の入力から）、Ｉ／Ｏ特性が特定されてもよい。

なお、例えば図２によれば、サーバ１００からストレージ１２０にかけた論理分割も、Ｉ／Ｏ特性及びＡＰＰ用途等のうちの少なくとも１つに基づく論理分割（例えば本番系の論理分割）も、連続した複数の階層にそれぞれ対応した複数種類のリソースが論理分割（割当て制御）される。しかし、論理分割では、複数の階層が必ずしも厳密に連続している必要は無い。例えば、第１及び第２リソースは、それぞれ、論理分割可能な種類のリソースであっても、階層的に第１及び第２リソースの間にある第３リソースは、論理分割不可能な種類のリソースであることもある。この場合、上位から下位にかけたリソースの論理分割において、途中のリソースが論理分割されないことになる。しかし、このような場合も、実質的には、上位から下位にかけたリソースの論理分割（例えばサーバ１００からストレージ１２０にかけた論理分割）と言うことができる。なお、論理分割可能であるか不可能であるかは、リソースの種類とストレージ１２０の機能とのうちの少なくとも１つに依存してよい。

実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。

実施例２では、統合ＬＰＡＲのコピー及び移動のうちの少なくとも１つを行うことができる。ここで、コピー移動先のサーバ・ストレージは移行元と同一か否かは問わない。

図１８は、統合ＬＰＡＲのコピーと移動の各々の一例を示す。なお、以下の説明では、サーバＬＰＡＲ１０１に認識されているＶＯＬをサーバＶＯＬ１０と言い、ストレージ１２０が提供するＶＯＬをストレージＶＯＬと言う。サーバＶＯＬは、ストレージＶＯＬに対応する。ストレージＶＯＬは、ドライブ１２５に基づくプールから記憶領域が割り当てられる仮想的なＶＯＬでもよい。

複数のサーバ１００として、例えば、第１サーバ１００ｔと、第２サーバ１００ｗがある。第１サーバ１００ｔ及び第２サーバ１００ｗ間は、スイッチ１７０を介して通信可能である。複数のストレージ１２０として、例えば、第１ストレージ１２０ｔと、第２ストレージ１２０ｗとがある。第１サーバ１００ｔ及び第１ストレージ１２０ｔが、サーバ１００からストレージ１２０にかけて論理分割されており、故に、開発系及び本番系を有する。第２サーバ１００ｗ及び第２ストレージ１２０ｗが、本番系に属する。すなわち、本番系が、第１サーバ１００ｔの一部と、第１ストレージ１２０ｔの一部と、第２サーバ１００ｗと、第２ストレージ１２０ｗとを有する。本番系において、第１サーバ１００ｔの一部と第２サーバ１００ｗが、それぞれ、第１ストレージ１２０ｔの一部と第２ストレージ１２０ｗとのいずれにも接続されている。

ＶＯＬ１１０は、サーバＬＰＡＲ１０１上のマルチパスプログラム（図示せず）が管理するＶＯＬである。マルチパスプログラムは、ストレージ１２０上の１つのＶＯＬ１２６を複数の経路で参照できる複数のＶＯＬ１０５を１つのＶＯＬ１１０にまとめる機能を持つ。例えば、ＶＯＬ１１０ｕは、ＶＯＬ１０５ｕと、１０５ｖとが１つにまとめられたＶＯＬである。

ＶＯＬ１０５ｕは、ポート１０８ｕ及びポート１２２ｕを経由して、ＶＯＬ１２６ｕを参照している。ＶＯＬ１２６ｗは、ポート１２２ｚ及びポート１２２ｙを経由してＶＯＬ１２６ｕを参照する仮想的なＶＯＬである。ＶＯＬ１０５ｖは、ポート１０８ｖ、ポート１２２ｗを経由して、ＶＯＬ１２６ｗを参照している。よって、ＶＯＬ１０５ｕと、ＶＯＬ１０５ｖは、同一のＶＯＬ１２６ｕを参照できる。

スイッチ１７０は、ＮＩＣ１０９を接続するスイッチである。サーバＬＰＡＲ１０１は、ＮＩＣ１０９及びスイッチ１７０を経由し、他のサーバＬＰＡＲ１０１と通信できる。

「統合ＬＰＡＲコピー処理」は、ＶＯＬ１２６ｕを同一のストレージ１２０の他の環境にコピーし、ＶＯＬ１２６ｕのコピーであるＶＯＬ１２６ｔを使用できるようにする処理である。「統合ＬＰＡＲ移動処理」は、ＶＯＬ１２６ｕ内のデータを別のストレージ１２０ｗ内のＶＯＬ１２６ｘに移動し、移動先ＶＯＬ１２６ｘを使用できるようにする処理である。

図１９は、統合ＬＰＡＲコピー処理の流れの一例を示す。

統合ＬＰＡＲコピー処理を実行する前に、統合管理プログラム６６０は、システム管理者から、コピー対象の統合ＬＰＡＲの選択とコピー先の環境の選択とを受け付ける。

ステップ２４１において、統合管理プログラム６６０は、割当てポリシーテーブル１４６を参照する。ステップ２４２において、統合管理プログラム６６０は、コピー対象統合ＬＰＡＲの割当て状態が変更されてなく、割当てポリシーを満足しているか否かを判断する。具体的には、例えば、統合管理プログラム６６０は、統合ＬＰＡＲテーブル１４９と、Ｉ／Ｏサイズテーブル１４５と、割当てポリシーテーブル１４６と、サーバＬＰＡＲ／ＨＢＡテーブル１５１と、サーバＨＢＡテーブル１５２と、ストレージＨＢＡテーブル１５３とに基づき、コピー対象統合ＬＰＡＲに割り当てられているポート１０８、ＣＴＬ１０７及びポート１２２の割当て状態が、テーブル１４６が表す割当てポリシーを満足しているか否かを判断する。

通常は、いずれの統合ＬＰＡＲも、割当てポリシーを満たしている。割当てポリシーテーブル１４６に基づき統合ＬＰＡＲが作成されるからである。しかし、システム管理者、又は、システム管理者とは別の人間（例えば、サーバストレージシステムの保守員）が、エラー解消等の目的で、統合管理サーバ１４０又は別の端末（例えば、ストレージ１２０に接続されているＳＶＰ（Service Processor）（図示せず））から、統合ＬＰＡＲのリソース割当てを変更することがある。この場合、割当てポリシーを意識することなくリソースの割当てが行われる。このため、統合ＬＰＡＲの割当て状態が割当てポリシーを満たさなくなることがある。このような状況を考慮して、本実施例では、統合ＬＰＡＲのコピー（又は移動）の処理において、統合ＬＰＡＲの割当て状態が割当てポリシーを満たしているか否かが判断される。

ステップ２４２の判断結果が肯定の場合（Ｓ２４２：Ｎｏ）、ステップ２４３が行われる。ステップ２４２の判断結果が否定の場合、ステップ２４６が行われる。なお、ステップ２４１とステップ２４２を省略し、ポリシーを確認せずに後続の処理（ステップ２４３以降）が行われてもよい。

ステップ２４３において、統合管理プログラム６６０は、コピー先環境に未割当てリソースがあることを確認し、使用するリソースを決定する。詳細は、図１７の統合ＬＰＡＲ作成処理におけるリソースの割当ての処理の流れと同様に、ストレージＨＢＡポート１２２、サーバＨＢＡポート１０８、サーバＨＢＡ ＣＴＬ１０７、サーバＣＰＵ１０２、メモリ１０３、ＮＩＣ１０９について、ポリシーに従ってリソースが決定される。

ステップ２４４において、統合管理プログラム６６０は、ＶＯＬコピーをストレージ１２０に指示する。この指示には、予め定めたコピー速度が指定されていてよい。コピー負荷が他のサーバＬＰＡＲ１０１の性能に影響を与えないようにするためである。その指示に応答して、指定されたコピー速度以下の速度で、ＶＯＬ間のデータコピーが行われる。

ステップ２４５において、統合管理プログラム６６０は、サーバＬＰＡＲ１０１を作成する。具体的には、例えば、統合管理プログラム６６０は、ステップ２４３で決定したリソースを使用し、ステップ２４４でコピーしたＶＯＬを使用し、統合ＬＰＡＲサイズテンプレートテーブル１４７に基づき、コピー元と同じ統合ＬＰＡＲサイズのサーバＬＰＡＲ１０１を作成する。

ステップ２４６において、統合管理プログラム６６０は、統合ＬＰＡＲの構成が変更されていることをシステム管理者に通知する。システム管理者への通知に代えて、割当てポリシーを満足するよう、コピー対象ＬＰＡＲの構成（リソース割当て）が自動的に変更されてもよい。

図２０は、統合ＬＰＡＲ移動処理の流れの一例を示す。

統合ＬＰＡＲ移動処理を実行する前に、統合管理プログラム６６０は、システム管理者から、移動対象の統合ＬＰＡＲの選択と移動先の環境との選択を受け付ける。

ステップ２４１、Ｓ２４２、及びＳ２４６の処理は、図１９と同様である。

ステップ２６３において、統合管理プログラム６６０は、移動先の環境に未割当てリソースがあることを確認し、使用するリソースを決定する。詳細は、図１７の統合ＬＰＡＲ作成処理におけるリソースの割当ての処理の流れと同様に、ストレージＨＢＡポート１２２、サーバＨＢＡポート１０８、サーバＨＢＡ ＣＴＬ１０７、サーバＣＰＵ１０２、メモリ１０３、ＮＩＣ１０９について、ポリシーに従ってリソースが決定される。

Ｓ２６４において、統合管理プログラム６６０は、ＶＯＬ移動をサーバ１００とストレージ１２０に指示する。

ここで、本番系のサーバＬＰＡＲ１０１ｕとＶＯＬ１２６ｕをサーバ１００ｗとストレージ１２０ｗに移動することを例に取る。なお、移動前はＶＯＬ１０５ｕを使用する経路によりＶＯＬ１２６ｕへのアクセスが行われていたとする。

統合管理プログラム６６０は、ＶＯＬ１２６ｗがＶＯＬ１２６ｕを参照するよう設定する。設定完了後、統合管理プログラム６６０は、ＶＯＬ１０５ｖを使用する経路をＶＯＬ１１０ｕに追加する。経路追加後、統合管理プログラム６６０は、ＶＯＬ１０５ｕを使用する経路を削除する。経路削除後、統合管理プログラム６６０は、ＶＯＬ１２６ｕの内容をＶＯＬ１２６ｘにコピーする。なお、コピー負荷が他のサーバＬＰＡＲ１０１の性能に影響を与えないように、予め定めたコピー速度におけるコピーを指示する。コピー完了後、統合管理プログラム６６０は、ＶＯＬ１０５ｖの参照先をＶＯＬ１２６ｗからＶＯＬ１２６ｘに切り替える。

ステップ２６５において、統合管理プログラム６６０は、サーバ１００にサーバＬＰＡＲ移動を指示する。具体的には、例えば、統合管理プログラム６６０は、ステップ２６３で決定したリソースを使用し、ステップ２６３でコピーしたＶＯＬを使用し、統合ＬＰＡＲサイズテンプレートテーブル１４７に基づき、コピー元と同じ統合ＬＰＡＲサイズのサーバＬＰＡＲを作成する。この際、統合管理プログラム６６０は、サーバＬＰＡＲ１０１ｕ内のメモリ１０３の内容をサーバＬＰＡＲ１０１ｗにコピーし、コピー完了後、サーバＬＰＡＲ１０１ｕを削除する。

実施例２によれば、統合ＬＰＡＲのコピー先又は移動先で、統合ＬＰＡＲに対するリソース割当て（割当てポリシーに従うリソース割当て）を引き継ぐことができる。従って、統合ＬＰＡＲのコピー又は移動が発生しても、ＡＰＰ集約率の向上と性能影響の防止の両方を維持できる。なお、実施例２では、同一サーバ１００及び同一ストレージ１２０での異なる環境間で統合ＬＰＡＲ再配置は、統合ＬＰＡＲコピーであるが、コピーに限らず移動でもよい。同様に、同一環境での異なるサーバ１００間及び異なるストレージ１２０間での統合ＬＰＡＲ再配置は、統合ＬＰＡＲ移動であるが、移動に限らずコピーでもよい。

実施例３を説明する。その際、実施例１及び２との相違点を主に説明し、実施例１及び２との共通点については説明を省略或いは簡略する。

統合管理プログラム６６０が、サーバストレージシステム１０００のリソースのメトリック値を繰り返し（例えば定期的に）収集し、リソース毎のメトリック値を管理情報６７０に登録する。統合管理プログラム６６０は、登録されたメトリック値と、管理情報６７０内のテーブル１４５〜１５５のうちの少なくとも１つとリソース毎にマージした監視結果を表す監視結果画面を表示できる。

図２３は、監視結果画面の一例を示す。

監視結果画面２３０１は、サーバリソース監視結果と、ストレージリソース監視結果とを表示する。

サーバリソース監視結果は、サーバＨＢＡテーブル１５２と、サーバＨＢＡポート１０８及びサーバＨＢＡ ＣＴＬ１０７の帯域使用率（メトリック値の一例）とがマージされた情報である。

ストレージリソース監視結果は、ストレージＨＢＡテーブル１５３と、ストレージＨＢＡポート１２２の帯域使用率（メトリック値の一例）とがマージされた情報である。

システム管理者は、監視結果画面２３０１を見ることで、リソース管理を適切に行うことができる。例えば、ストレージＨＢＡポート１２２の帯域使用率が或る値を超えている場合、そのポート１２２が、共有リソースであれば、システム管理者は、そのポート１２２を別の統合ＬＰＡＲに更に割り当てることができると判断して、リソース割当ての最適化のための操作を行うことができる。一方、そのポート１２２が、占有リソースであれば、システム管理者は、そのポート１２２の割当て状態を占有割当てから共有割当てに変えてはならないと判断できる。

以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、上述した実施例では、統合ＬＰＡＲへの負荷の特性は、ＡＰＰ用途及びＶＯＬ用途に基づき期待（予測）される負荷の特性（例えば、Ｉ／Ｏ特性）であるが、それに代えて、実測値として得られた負荷の特性（例えば、Ｉ／Ｏ特性）であってもよい。

１００…サーバ、１２０…ストレージシステム

Claims (13)

1. サーバシステム及びストレージシステムを含んだサーバストレージシステムを有し、
   前記サーバストレージシステムが、複数種類のリソースを含んだ複数のリソースのうちの少なくとも一部が論理分割されることにより得られた複数の論理区画を有し、
   前記複数のリソースは、前記サーバシステムが有する複数種類のサーバリソースを含んだ複数のサーバリソースと、前記ストレージシステムが有する複数種類のストレージリソースを含んだ複数のストレージリソースとを含み、
   ２以上の論理区画の各々に割り当てられるリソースは、占有割当てされたリソースと共有割当てされたリソースとの少なくとも一方を含み、
   論理区画に占有割当てされたリソースは、その論理区画に占有されるリソースであり、
   論理区画に共有割当てされたリソースは、その論理区画を含む少なくとも２つの論理区画に共有され得るリソースであり、
   前記２以上の論理区画の各々について、占有割当てされている複数のリソースの種類が、その論理区画への負荷の負荷特性により異なり、
   前記２以上の論理区画の各々では、前記ストレージシステムにより提供された論理ボリューム（ＶＯＬ）に対するＩ／Ｏ要求を発行するアプリケーションプログラム（ＡＰＰ）が実行されるようになっており、
   前記２以上の論理区画の各々について、その論理区画の負荷特性は、その論理区画へ提供されたＶＯＬへのＩ／Ｏの特性である、
   計算機システム。
2. 前記２以上の論理区画の各々について、その論理区画のＩ／Ｏ特性は、その論理区画において発行されるＩ／Ｏ要求に付随するＩ／Ｏ対象データのサイズであるＩ／Ｏサイズを含む、
   請求項１記載の計算機システム。
3. 前記２以上の論理区画の各々について、その論理区画のＩ／Ｏ特性は、その論理区画で実行されるＡＰＰの用途の入力と、そのＡＰＰによるＩ／Ｏ先のＶＯＬの用途の入力とに基づき決定された特性である、
   請求項１記載の計算機システム。
4. 前記複数のサーバリソースが、前記ストレージシステムに接続される１以上の第１インターフェースデバイスの１以上のコントローラ（ＣＴＬ）と、前記１以上の第１インターフェースデバイスの１以上の第１ポートとを含み、
   前記複数のストレージリソースが、前記サーバシステムに接続される１以上の第２インターフェースデバイスと、前記１以上の第２インターフェースデバイスの１以上の第２ポートとを含み、
   ＣＴＬ、第１ポート、第２インターフェースデバイス及び第２ポートのうちの少なくとも１つについて、前記２以上の論理区画の各々に対して占有割当てか共有割当てかは、その論理区画へ提供されたＶＯＬのＩ／Ｏサイズに依存している、
   請求項２記載の計算機システム。
5. Ｉ／Ｏサイズが大きいとされた２以上のＶＯＬが提供された論理区画には、異なるＣＴＬ、異なる第１ポート、及び、異なる第２ポートが割り当てられ、第２インターフェースデバイスが共有割当てされ、
   共有割当てされる第２インターフェースデバイスは、同Ｉ／ＯサイズのＶＯＬが提供された論理区画に共有される、
   請求項４記載の計算機システム。
6. Ｉ／Ｏサイズが大きいとされたＶＯＬが提供された論理区画とＩ／Ｏサイズが小さいとされたＶＯＬが提供された論理区画には、異なるＣＴＬ、及び、異なる第２インターフェースデバイスが割り当てられる、
   請求項４記載の計算機システム。
7. それぞれＩ／Ｏサイズが小さいとされたＶＯＬが提供された２以上の論理区画には、異なるＣＴＬが割り当てられ、第１ポート、第２ポート及び第２インターフェースデバイスが共有割当てされ、
   共有割当てされる第２インターフェースデバイス及び第２ポートは、それぞれ、同Ｉ／ＯサイズのＶＯＬが提供された論理区画に共有される、
   請求項４記載の計算機システム。
8. 前記２以上の論理区画の各々には、複数のリソース割当てポリシーのうち、その論理区画の負荷特性に対応したリソース割当てポリシーに従ってリソースが割り当てられ、
   前記複数のリソース割当てポリシーの各々は、２以上のリソース種類の各々について占有と共有のいずれで割当てるかが定義されたポリシーである、
   請求項１記載の計算機システム。
9. 前記サーバストレージシステムが、サーバシステムからストレージシステムにかけて論理分割されることにより得られた複数のサブシステムを有し、
   前記複数のサブシステムのうちの第１サブシステムが、本番環境に属するサブシステムである本番系であり、
   前記複数のサブシステムのうちの第２サブシステムが、開発環境に属するサブシステムである開発系であり、
   前記本番系が、前記２以上の論理区画を有する、
   請求項１記載の計算機システム。
10. 同一サーバシステム及び同一ストレージシステムでの異なる環境間での論理区画再配置と、同一環境での異なるサーバシステム間及び異なるストレージシステム間での論理区画再配置のうちの少なくとも１つが行われ、
    再配置先において、論理区画には、その論理区画の特性に従い、割当て対象のリソース種類毎に、占有割当てされるか共有割当てされるかが制御される、
    請求項９記載の計算機システム。
11. 前記サーバストレージシステムを管理する管理システムを有し、
    前記管理システムが、
    前記複数のリソースの少なくとも一部のリソースのメトリック値を収集し、
    前記少なくとも一部のリソースについて、占有割当てされているか共有割当てされているかと、収集されたメトリック値とを表示する、
    請求項１記載の計算機システム。
12. サーバシステム及びストレージシステムを含んだサーバストレージシステムを有し、
    前記サーバストレージシステムが、複数種類のリソースを含んだ複数のリソースのうちの少なくとも一部が論理分割されることにより得られた複数の論理区画を有し、
    前記複数のリソースは、前記サーバシステムが有する複数種類のサーバリソースを含んだ複数のサーバリソースと、前記ストレージシステムが有する複数種類のストレージリソースを含んだ複数のストレージリソースとを含み、
    ２以上の論理区画の各々に割り当てられるリソースは、占有割当てされたリソースと共有割当てされたリソースとの少なくとも一方を含み、
    論理区画に占有割当てされたリソースは、その論理区画に占有されるリソースであり、
    論理区画に共有割当てされたリソースは、その論理区画を含む少なくとも２つの論理区画に共有され得るリソースであり、
    前記２以上の論理区画の各々について、占有割当てされている複数のリソースの種類が、その論理区画への負荷の負荷特性により異なり、
    前記サーバストレージシステムのリソースの論理区画への割当てを制御する管理システムを更に有し、
    前記２以上の論理区画の各々では、前記ストレージシステムにより提供された論理ボリューム（ＶＯＬ）に対するＩ／Ｏ要求を発行するアプリケーションプログラム（ＡＰＰ）が実行されるようになっており、
    前記管理システムは、
    前記２以上の論理区画の各々について、その論理区画で実行されるＡＰＰの用途の入力と、そのＡＰＰによるＩ／Ｏ先のＶＯＬの用途の入力とを受け付け、
    入力されたＡＰＰ用途及びＶＯＬ用途に基づいて、その論理区画で提供されたＶＯＬへのＩ／Ｏの特性であるＩ／Ｏ特性を決定する、
    計算機システム。
13. サーバシステム及びストレージシステムを含んだサーバストレージシステムを管理する管理システムにおける論理区画管理方法であって、
    前記管理システムは制御部と記憶部とを有し、
    前記記憶部は、前記サーバシステムと前記ストレージシステム各々の有する複数リソースのリソース情報と、リソースへの負荷特性に応じて前記複数リソース其々を作成される論理区画に対して占有割り当てとするか又は共有割り当てとするかを対応づけたポリシーを有し、
    前記制御部は、
    アプリケーションの識別情報と当該アプリケーションに提供される論理区画の作成指示を受け、
    前記リソース情報、前記識別情報に基づいて得られる負荷特性と前記ポリシーとに基づいて、前記論理区画に割り当てられるリソースを特定し、かつ、前記特定されたリソースそれぞれについて占有割り当てとするか共有割り当てとするかを判定し、
    前記特定されたリソースが前記判定に基づいて割り当てられる論理区画の作成指示を前記サーバシステムと前記ストレージシステムとに送信し、
    前記制御部は、
    前記アプリケーションの識別情報に加えて、前記アプリケーションの用途と、そのアプリケーションによるＩ／Ｏ先のボリュームの用途についての入力を受け、
    前記入力された情報に基づいて、前記アプリケーションにより発行されるＩ／Ｏ要求に付随するＩ／Ｏ対象データのサイズであるＩ／Ｏサイズを前記負荷特性として得る
    ことを特徴とする論理区画管理方法。

Images