以下、本発明によるサーバシステム及びサーバの配置方法の実施形態を図面により詳細に説明する。
≪第1の実施形態≫
図1は本発明の一実施形態によるサーバシステムの構成例を示すブロック図、図2はブレードサーバの構成例を示すブロック図である。図1、図2において、1はブレードシステム(以下、ブレードと略す)、2は記憶装置、3はブレードサーバ、4はサーバ種別管理テーブル、5はブレードサーバ管理テーブル、6はサーバイメージ記憶装置、7は管理サーバ、8、11は通信制御部、9はサーバ種別検知部、10は記憶装置インターフェース部、13はイメージ配信部、14はイメージ収集部、15は自動配信スケジュール部、17はサーバ負荷検知部、18はサーバ負荷計算部、20はSANコンフィグ部、21はグループ作成部、22はLED点灯部、23は起動パラメータ設定部、24は表示装置である。
本実施形態によるサーバシステムは、図1に示すように、1つの筐体内に設けられる複数のスロットのそれぞれにブレードサーバ(ブレードや、CPUボード、計算機ともいう)3を収納した複数のブレードサーバにより構成されるブレード1と、複数のブレードサーバ3のそれぞれに接続される記憶装置2と、本実施形態により設けられた管理サーバ7とにより構成されている。ブレード1を構成する複数のブレードサーバ3は、それぞれ独立して動作することが可能なコンピュータであり、それぞれ、CPU、メモリ、外部入出力等のサーバとしての基本機能を備え、記憶装置2と接続されて構成されている。また、ブレードサーバ3は、1または複数の基板により構成されていてよく、複数の基板により構成される場合、筐体内の複数のスロットに収納される。各処理部をプログラムで実現する場合には、前記メモリに格納されたプログラムが前記CPUによって実行される。
1つの筐体に収納される複数台のブレードサーバ3は、機能の異なる複数種類のサーバを含んでいる。また、ブレード1は、図示しない負荷分散装置を備えており、機能毎に分類される同種類ブレードサーバ3が全て均等に負荷分散されるように制御されている。なお、図1には、ブレード1として、1つの筐体に複数のブレードサーバ3を収納したものとして1つのブレードだけ示しているが、ブレード1は、複数段の棚を持つ筐体の各段に複数設けられていてもよい。ブレードシステムを複数段で構成する場合、1つの段全体で1つのブレード1を構成しても、あるいは、複数段をまとめて1つのブレード1を構成してもよい。さらに、1つの段に含まれる複数のブレードサーバを複数の群に分けて、各群をそれぞれ1つのブレード1として構成してもよい。機能をまとめたり、近接するブレードサーバに割り当てたりすることにより、通信時間を短くし、処理能力を向上することもできる。
管理サーバ7は、ネットワーク等を介してブレード1の全てのブレードサーバ3に接続されており、ブレード1の全てのブレードサーバ3を管理するものであるが、ブレードサーバ3の1つに構成されていてよい。そして、管理サーバ7は、ブレードサーバ3との通信を制御する通信制御部11、ブレードサーバ3にサーバイメージ(モジュールや、プログラムイメージ、システムイメージ、ディスクイメージ、ボリュームイメージともいう)を配信するイメージ配信部13、ブレードサーバ3からイメージを収集するイメージ収集部14、本実施形態によりブレードサーバ3のブレード1内での配置の変更等の処理を行う自動配信スケジュール部15、各ブレードサーバ3の負荷を計算するサーバ負荷計算部18、記憶装置2がSANで接続される場合のSANのコンフィグレーションを設定するSANコンフィグ部20、ブレードサーバ3をグループ化するグループ作成部21、起動パラメータ設定部23、複数のブレードサーバ3の配置状態を表示する表示装置24、複数のブレードサーバ3のそれぞれの機能種別を管理するサーバ種別管理テーブル4、複数のブレードサーバ3のブレード内での配置位置等を管理するブレードサーバ管理テーブル5、ブレードサーバ3に配信するサーバイメージを保持するサーバイメージ記憶装置6を備えて構成される。各ブレードサーバは、それぞれに割付けられたサーバイメージに基づいて処理を実行する。
また、ブレードサーバ3は、図2に示すように、管理サーバ7との通信を制御する通信制御部8、自ブレードサーバの機能種別を検知するサーバ種別検知部9、記憶装置2とのインタフェースである記憶装置インタフェース部10、自ブレードサーバの負荷状態を検知するサーバ負荷検知部11、自ブレードサーバの機能種別に対応する色のLED、障害等の状態を示すLEDを点灯制御するLED点灯部22、図示しない機能種別毎に対応する色で発光させられる複数のLED及び障害等の状態を示すLEDを備えて構成されている。
前述したように構成される本実施形態において、記憶装置2は、DAS(Device Attached Storage)またはSAN(Storage Area Network)の形態を持ち、ブレードサーバ3の
記憶装置インターフェース10を介して接続される。SANで接続される場合、HBA(Host Bus Adapter)を介してファイバチャネルスイッチによりSANのコンフィグレーションが設定されるものとする。
管理サーバ7は、1または複数のブレード1に収納される複数のブレードサーバ3を、グループ作成部21で作成したグループに登録することによりブレードサーバ3の管理を行う。また、管理サーバ7内の自動配信スケジュール部15は、本実施形態によるブレードサーバ3の配置(デプロイ)、機能種別の変更を行うものであり、この処理の詳細については後述する。なお、デプロイ(deploy)に関する具体的な技術内容については、特許文献1に記載されている。
ブレードサーバ3内のサーバ種別検知部9は、管理サーバ7からの要求により自サーバ内の通信制御部8、管理サーバ内の通信制御部11を介して通信を行い、自ブレードサーバ3にインストールされているモジュール(例えば、SMTPサーバやHTTPサーバを示す)を検知する。
管理サーバ7内のイメージ配信部13は、通信制御部11、ブレードサーバ3内の通信制御部8を介して対象のブレードサーバ3へサーバイメージ記憶装置6に記憶されているイメージを配信する。対象のブレードサーバ3は、イメージが配信された後、配信されたイメージの元の状態を復元し、起動パラメータ設定部23により設定された対象サーバ固有の情報を読み込みOSを起動する。本発明の実施形態において、イメージとはそのサーバが接続されている記憶装置2のバックアップイメージを指す。管理サーバ7内のイメージ収集部14は、通信制御部11、対象ブレードサーバ3の通信制御部8を介して対象のブレードサーバ3のイメージを収集し、サーバイメージ記憶装置9に記憶する。
各サーバは、内蔵ディスクを有し、配信されたサーバイメージを前記内蔵ディスクに格納し、再起動のときに、そのサーバイメージからブートを行うことも可能である。ここで、配信とは、サーバイメージ記憶装置9から対象となるサーバイメージを当該ブレードの内蔵ディスクにコピーすることを意味する。また、サーバイメージが配信されると、ブレードサーバに対応付けられてサーバイメージ記憶装置9に格納される。この場合、ブレードサーバから、SANブートによりサーバイメージをブートしてもよい。ここで、配信とは、サーバイメージ記憶装置9から対象となるサーバイメージをコピーして当該ブレードに対応付けることを意味する。
前述したイメージ配信部13、イメージ収集部14での処理は、対象サーバの作業を一定時間停止しなければ実行することができない。すなわち、イメージの収集、配信時において、対象サーバは停止状態になる。ブレードサーバ3内のサーバ負荷検知部17は、自ブレードサーバ3の負荷を測定する。ここでいう負荷は、例えば、CPU使用率であって、ある一定の時間間隔で測定されたCPU使用率の平均値である。また、負荷は、要求を処理したレスポンス時間やその平均値を利用してもよい。ここで得られた測定結果は、通信制御部8、管理サーバ7の通信制御部11を介して管理サーバ7に送られる。
管理サーバ7のサーバ負荷計算部18は、ブレードサーバ3の機能種別毎にサーバ負荷検知部17で得た測定結果を平均する機能と、ある機能種別のサーバに増減がある場合、その機能種別のサーバが増減したと仮定した場合の負荷の平均を予測計算する機能とを有する。予測計算の方法は、例えば、機能種別毎の負荷の合計値をサーバの増減を仮定したときのその機能種別のサーバ数で割る等の方法であってよい。管理サーバ7内のグループ作成部21は、グループとして管理したいブレードサーバのグループを作成し、作成したグループのそれぞれに、グループとして管理したいブレード1あるいはブレードサーバ3を登録する。1つのグループに複数のブレードあるいはブレードサーバを登録することにより、グループとして、ブレードあるいはブレードサーバを管理することができる。
管理サーバ7内のSANコンフィグ作成部20は、記憶装置2がブレード1にSANにより接続されている場合に、ファイバチャネルスイッチのコンフィグレーションを作成し、作成したコンフィグレーションをファイバチャネルスイッチに設定する機能を有する。ブレードサーバ3内のLED点灯部22は、ブレードサーバの起動時に、自ブレードサーバがどの機能種別に属するかを判断し、その機能種別に対応するLEDを図3に示して後述する表から判別して点灯させる。管理サーバ7内の起動パラメータ設定部23は、イメージ配信部13での処理中にイメージ配信対象サーバにおける固有の情報を参照するが、その各ブレードサーバ固有の情報を設定する機能を有する。各処理部は、プログラムや、オブジェクト、プロセス、スレッド、ハードウェアでも実現できる。
図3は管理サーバ7のサーバ種別管理テーブル4の構成を示す図であり、次に、これについて説明する。
図3に示すサーバ種別管理テーブル4は、複数のブレードサーバ3のそれぞれの機能種別を管理するためのものであり、ブレードサーバの番号201、その機能種別202、LEDの対応する点灯色を示すLED203及び検知モジュール1〜n(204、205)により構成される。機能種別202は、例えば、WEBサーバ、メールサーバというようにそのサーバの機能を表す。LED203は、その機能に対応して点灯させるLEDの色を表す。検知モジュール204、205は、例えば、SMTPサーバ、POPサーバ、HTTPサーバのようにサーバ種別検知部により検知されたモジュールがどの機能に属するものかを判断するために用いられる。同じ機能を持つサーバ、例えば、WEBサーバであっても、異なるモジュールを持つ場合もあり、検知モジュール1〜n等として区別されて登録される。
図4は管理サーバ7のブレードサーバ管理テーブル5の構成を示す図であり、次に、これについて説明する。
図4に示すブレードサーバ管理テーブル5は、複数のブレードサーバ3のブレード内での配置位置等を管理するためのものであり、筐体内での収用位置を示すブレードサーバの番号301、ブレード番号302、機能種別303、そのサーバが稼動中(act)か否(non act)かを示す状態304、実行可能な機能305により構成される。ブレード番号302は、グループによって登録された全てのブレードサーバのブレード番号、ブレードサーバ番号により構成される。機能種別303は、ブレード番号に対応するサーバが持つ種別を表し、図3で説明した202に対応する。実行可能な機能305には、記憶装置2がDASであってブレードサーバに直接接続されている場合に、記憶装置2内に実行可能に格納されているモジュール名が格納されている。なお、故障と診断されたブレードサーバは、このテーブルに登録されない。
また、図4において番号301の順番は、グループ毎に決定し、ブレードの登録された順番で、そのブレードを格納している筐体に収納されているブレードサーバの順番に等しいものとする。図4に示すブレードサーバ管理テーブル5の例は、ブレードサーバ3を4枚備えて構成されるブレードの2つを1つのグループとして登録した場合の例である。この場合に、1つの筐体に2つのブレードが構成されることになるが、システム全体が複数の筐体で構成される場合、1つの段の筐体に収納される全てのブレードサーバにより1つのブレードを構成し、そのブレードの複数を1つのグループとして登録するようにしてもよい。また、機能種別303において、ある種別が決定されると、その機能種別のブレードサーバに含まれる機能やアプリケーションは、グループによって一意に決定される。例えば、図4に示す例において、種別がWEBサーバとなっているブレードサーバは、全て同等の機能及びアプリケーションしか実行しない。
図5は自動配信スケジュール部15におけるブレードサーバの配置変換の処理動作を説明するフローチャートであり、次に、これについて説明する。ここで説明する例は、図3に示される機能がWEBサーバ、メールサーバに限られるものとした場合の例である。この処理は、障害等によりブレードサーバの1つが停止したとき、あるいは、定期的に起動される。
(1)この処理が開始されると、まず、1つのブレードサーバの停止によりこの処理が開始されたのか否かを判定し、1つのブレードサーバの停止によりこの処理が開始された場合、図4に示すテーブル5の停止したサーバを削除して、テーブル5を更新する(ステップ401、402)。
(2)1つのブレードサーバが停止すると、ブレード1は、図示しない負荷分散装置が、停止したブレードサーバと同一の機能を持った同種類のブレードサーバに停止したブレードサーバの処理を分散させて実行するように負荷分散させるので、管理サーバ7内のサーバ負荷計算部17は、同種類のブレードサーバのサーバ負荷検知部17からブレードサーバの負荷状態を収集し、各サーバの平均負荷を測定して、同種類のブレードサーバの負荷が多くなり過ぎているか否か、すなわち、負荷の状態が許容できる範囲にあるか否かを判定する(ステップ403、404)。
(3)ステップ404の判定で、停止したブレードサーバと同種のブレードサーバの負荷が大きく、負荷の状態が許容できる範囲でなかった場合、例えば、WEBサーバが停止した場合で、1つのWEBサーバの停止より、他のWEBサーバの負荷が著しく大きくなった場合、まず、テーブル5内に空きとなっているサーバがあるか否かを判定し、あれば空きのサーバの1つにWEBサーバ(ここでは、予め取得しておいた初期状態のWEBサーバとする)のイメージをイメージ配信部13から配信する。空きがなかった場合、メールサーバがグループ内にいくつあるかを図4に示すテーブル5から計算し、複数あった場合、サーバ負荷計算部18によりメールサーバを1つ減少させた場合のメールサーバの負荷を予測計算し、WEBサーバを増加させる方が適当である場合、1つのメールサーバにWEBサーバのイメージ(ここでは予め収集しておいたイメージ)をイメージ配信部13から配信する。メールサーバが複数ないか、あるいは、WEBサーバを増加させない方が適当である場合何もしない(ステップ405)。
(4)ステップ405のイメージ配信の処理により必要な機能がブレードサーバにリブートされると、そのブレードサーバのLED点灯部22は、機能により決められている色を発光するLEDを点灯させ、テーブル5を更新すると共に、その後の処理でブレードサーバの配置を変更するために利用する配置変換後の新たなテーブルを、更新したテーブル5の情報に基づいて作成する(ステップ406〜408)。
(5)ステップ401の判定で、ブレードサーバの停止によりこの処理が開始されたのではない場合、定期的な起動で、ブレードサーバの並べ替えのための起動であるので、現在のブレードサーバ管理テーブル5の情報に基づいて、配置変換後の新たなテーブルを作成する(ステップ409)。
(6)ステップ404の判定で、負荷の状態が許容できる範囲にあった場合、ステップ402の処理で更新したテーブル5の情報に基づいて、配置変換後の新たなテーブルを作成する(ステップ410)。
(7)ステップ408、409または410の処理で配置変換後の新たなテーブルを作成した後、ブレードサーバの並べ替えの処理が開始される。この処理が開始されると、まず、ブレードサーバに接続される記憶装置2がDASにより接続されているのか、SANにより接続されているのかを判定する(ステップ411、412)。
(8)ステップ411の判定で、DASにより接続されている場合、詳細を後述するDASの場合の処理を実行し、SANにより接続去れている場合、詳細を後述するSANの場合の処理を実行して、ブレードサーバの並べ替えの処理を終了する(ステップ413、414)。
図6は配置変換後の新たなブレードサーバ管理テーブル501の構成例を示す図であり、ここに示す例は、前述したステップ409の処理で、現在のブレードサーバ管理テーブル5の状態が図4に示すようなものであった場合における配置変換後のブレードサーバの並び順を示すものであり、WEBサーバ、メールサーバ、空きのサーバが順に筐体に収納されたものとなる。このように、機能種別毎にブレードサーバを複数まとめて配置するようにすることにより、保守者がブレードサーバの配置位置を把握しやすくなり、保守の容易性を向上させることができる。なお、配置変換後のブレードサーバの並び順をどのようにするかは任意である。また、前述のステップ408、410で作成される配置変換後の新たなブレードサーバ管理テーブルが、ステップ409で作成されるものと同一となるとは限らないが、以下の説明では、配置変換後の新たなブレードサーバ管理テーブルが図6に示すようなものとなるとして説明を続ける。
図7は記憶装置2がDASにより接続された場合のブレードサーバの並べ替えの処理動作を説明するフローチャート、図8は図7のステップ603での空きサーバの位置変換の処理動作を説明するフローチャート、図9は空きサーバの位置変換の処理動作を行った後のサーバの配置状態を示す図であり、まず、図7に示すフローを参照して、ブレードサーバの並べ替えの処理動作を説明する。
(1)まず、図4に示す元のブレードサーバ管理テーブル5とステップ409の処理で作成した配置変換後のブレードサーバ管理テーブル501とを比較し、両者が同等か否かにより配置の変換が必要か否かを判定する。2つのテーブルが同等である場合、変換の必要ないので処理を終了させる(ステップ601)。
(2)ステップ601の判定で、2つのテーブルが異なりサーバの配置の変換が必要であった場合、次に、ブレードサーバ管理テーブル5に空きのサーバが登録されているか否かを判定し、空きのサーバがなかった場合、サーバの配置の変換が不可能であるため、ここでの処理を終了する(ステップ602)。
(3)ステップ602の判定で、空きのサーバがあった場合、図8により後述する空きサーバの位置の変換を行う。この処理により、図9に801として示すテーブルのように空サーバをテーブルの末尾に配置する。ここでの処理では、図4に示しテーブルに空きサーバが2つあるので、3番の空きサーバに、8番のWEBサーバを移動させ、4番の空きサーバに、7番のメールサーバを移動させ、その後、7番のサーバと8番のサーバとを空きにする処理を行って、図9に示すような配置とする(ステップ603)。
(4)次に、空きサーバが2以上存在するか否かを判定し、テーブルに空きサーバが2以上ない場合、すなわち、空きサーバが1つしかない場合、必要に応じて縮退運転をしなければならないため、各ブレードサーバのサーバ負荷検知部17から検知された負荷の状態を収集し、管理サーバ7のサーバ負荷計算部18により縮退運転時の構成における各ブレードサーバの負荷を予測する。縮退運転とは、例えば、空きのサーバが1つしかない場合、WEBサーバ、メールサーバのどちらか一方を停止させて運転を続けることをいい、ここではその両方の場合を考慮してサーバ負荷計算部18により負荷予測を行う。すなわち、WEBサーバが1減少する場合とメールサーバが1減少する場合において負荷予測を行う(ステップ605)。
(5)ステップ605で予測された負荷の計算値がWEBサーバ、メールサーバのどちらかでも負荷の基準値を超えるか否かを判定し、基準値を超えていた場合ブレードサーバの配置変換を中止するか、あるいは、一定時間待ってから処理を再開することとして、ここでの処理を終了する。一方、負荷の計算値からどちらのサーバを1つ減少させるのがよいかを計算値より判断し、例えば、WEBサーバが1減少したほうが負荷の影響が少ない場合は、メールサーバを空きサーバに配信する。この場合、その配信されたサーバイメージは予め収集しておいたメールサーバの機能を持つものとする(ステップ606)。
(6)ステップ604の判定で、サーバの空きが2以上あった場合、WEBサーバ、メールサーバの組をどこかの空きサーバに配信しておく。この場合のイメージも予め収集しておいたものとする。予備としてこれらの配信により作成されたサーバを運転するがこれらのサーバの運転中取得されたログなどの固有の情報は破棄される(ステップ607)。
(7)次に、ブレードサーバの位置変換を行う。位置変換とは、対応する2つのサーバA、Bを決定し、A、Bのイメージ収集を同時に行い、A、Bともにイメージ収集を終えた時点でAのイメージをBへ、BのイメージをAへ同時に配信することをいう。かりに、Bが空の場合、Bのイメージを収集する必要はなく、配信時にはAに対応するテーブル5を空に設定し、Aのサーバは停止させておく。サーバA、Bは、常にWEBサーバとメールサーバの組になるようにする。説明している例では、ステップ603の処理で、図9に示す状態となっているので、ここでの処理は、2番のメールサーバと5番のWEBサーバとを入れ替える処理となり、これにより、図6に示す状態となる。その後、必要なイメージがそれぞれのサーバにリブートされると、各サーバのLED点灯部22により、機能に対応する色のLEDが点灯させられる(ステップ608、609)。
(8)次に、他に入れ替えるべきサーバがあれば、ステップ608からの処理を繰り返し、入れ替えるべきサーバがなくなれば、ここでの処理を終了する(ステップ610)。
次に、図8に示すフローを参照して、前述したステップ603での空きサーバをブレード内の最後の位置に配置する処理について説明する。
(1)まず、図4に示すテーブル5から空きサーバがテーブルの何番にあるかを調べ、その番号を示す図示していないが、空きサーバテーブルAと呼ぶテーブルを作成する。この空きサーバテーブルAには、対応する番号のサーバの機能種別も記憶させる(ステップ701)。
(2)ステップ701で作成した空きサーバテーブルAと図6に示す配置変換後のブレードサーバテーブル501とを比較し、空きサーバの位置が同じであるか否かにより配置変換が必要か否かを判定し、空きサーバの位置が同じで配置変換が不要であればここでの処理を終了する(ステップ702)。
(3)ステップ702の判定で、空きサーバの位置が同じでなく、配置変換が必要であると判定された場合、前述の空きサーバテーブルから位置変換が必要な空きサーバと空きサーバと変換されるサーバ種別を決定する。位置変換が必要なサーバが1ならば対応するサーバの位置が自動的に決定される。位置変換が必要なサーバが2以上の場合、どのサーバとどのサーバとを対応させるかについては、例えば、以下のように決定する。テーブル501における種別が空のサーバの番号と現在の種別、すなわち、テーブル5における種別をテーブルBに記憶する。次に、前述の空きサーバテーブルAを番号順に走査し、テーブルAの種別に対応する種別がテーブルBにあるかを調べる。対応する種別があれば、そのサーバに決定し、決定したテーブルBの番号をテーブルBから削除する。なければ、対応するサーバを決定せずに空きサーバテーブルAの次の走査に移り、同様の操作を繰り返す。テーブルAの走査を終えると対応するサーバが決定していないテーブルAのサーバをテーブルBの残っているサーバの中から適当に決定する。このように対応するサーバを決定することにより、図7により説明したステップ608におけるサーバ変換処理を最小の処理量に抑えることができる(ステップ703)。
(4)次に、ステップ703の処理の結果、サーバの位置変換を行う必要があるか否かを判定して、位置変換がなければテーブル5を更新してここでの処理を終了する(ステップ704、705)。
(5)ステップ704の判定で、サーバの位置変換があった場合、縮退運用時のサーバの負荷を、前述ですでに説明していると同様に計算し、縮退運用時の負荷が基準値より大きいか否かを判定し、負荷が基準値より大きければ処理を終了するか、あるいは、一定時間待って処理を続けることとする(ステップ706、707)。
(6)ステップ707の判定で、負荷が基準値より小さかった場合、ステップ703の処理によって決定した対応するサーバに対して、イメージの収集、イメージの配信の処理を行って位置変換を行う。この位置変換の処理では、対象となるサーバが一時的に停止させられる。この位置変換により、イメージがサーバにリブートされれば、そのサーバ内のLED点灯部22が、その機能種別に対応する色のLEDを点灯させる(ステップ708〜710)。
前述した処理の結果、図4に示した配列のブレードサーバ管理テーブルの状態が、図9に示すテーブル801にように変更されたことになり、同時に、空きサーバが番号の末尾となるように配置される。
以上、図7、図8に示すフローにより、図5に示すステップ413でのDASの場合のブレードサーバの並べ替えについて説明した。前述したDASの場合の並べ替えは、処理を迅速に行う必要性からブレード1内に少なくとも2つの空きのブレードサーバが存在する場合に、その空きサーバを利用して効率的にサーバの並べ替えを行う例を示して説明した。しかし、ブレードサーバの並べ替えは、並べ替えにある程度時間が係ることを許容すれば、ブレード1内に1つの空きのブレードサーバが存在すれば行うことができる。この場合のサーバの並べ替えは、例えば、データソートの方法としてよく知られている方法を応用し、空きのサーバに移動したいサーバの機能を移し、そのサーバを空きにすることによるサーバの位置変換を、所望の配置となるまで繰り返し実行するという方法により行うことができる。さらに、負荷の軽い機能種別のサーバの1つを停止状態とし、このサーバを1つの空きサーバと見て前述したような処理を行えば、ブレード1内に空きのブレードサーバが存在しない場合にも、サーバの配置替えを行うことができる。
前述したDASの場合の方法は、記憶装置2が各ブレードサーバに所属していて、その記憶装置内にそのサーバの機能を特徴付けるモジュールをイメージとして配信しなければならない。このため、いずれにしてもサーバの配置替えに際してサーバの停止を伴うことになり、図5に示して説明したフローにおいて、ステップ408からの並べ替え開始後の処理は、サーバシステム全体の処理負荷が低い状態で行うことが望ましく、図5のステップ408〜410の手段で並べ替え後のテーブルを作成した後は、処理を中断して、ステップ408からの並べ替え開始後の処理をサーバシステム全体の処理負荷が低い状態となる深夜等の時間帯に行うようにしておくとよい。
図10は記憶装置2がSANにより接続された場合のブレードサーバの並べ替えの処理動作を説明するフローチャートであり、次に、これについて説明する。記憶装置2がSANの場合、記憶装置2は、ファイバケーブルによりファイバチャネルスイッチを介して各ブレードサーバ3に接続されているものとする。
(1)まず、管理サーバ7のSANコンフィグ部20は、図5に示すフローのステップ408から410のどれかで作成した並べ替え後のテーブル501の状態になるようファイバチャネルスイッチのコンフィグレーションを作成し、作成した情報を通信制御部8、11のを通してファイバチャネルスイッチに設定する(ステップ901)。
(2)次に、リブートが必要なサーバの番号を、図には示していないテーブルCに記憶し、ステップ902からステップ906の処理をテーブルCに記憶したサーバに対して繰り返すことにより設定情報を各サーバに反映させるため、リブートによりそのサーバが停止するものと考えて負荷予測計算を、前述で説明した場合と同様にサーバ負荷計算部18により行わせ、負荷が規定値より大きいか否かを判定する(ステップ902、903)。
(3)ステップ903の判定で、負荷が規定値より大きければ、テーブルCの次のサーバに対して同じ処理を実行し、負荷が規定値より大きくなければ、OSの機能を用いてリブートを行う。リブートが完了すれば、LED点灯部22がリブートされた機能に対応する色のLEDを点灯させる(ステップ904、905)。
(4)次に、テーブルCからリブートが完了したサーバを削除し、テーブルCにまだサーバが存在すれば、ステップ902からの処理に戻って処理を繰り返し、テーブルCにサーバがなくなれば、処理を終了する(ステップ906)。
前述ではブレードを構成するブレードサーバが障害等で停止した場合、あるいは、別の何らかの理由で、ブレードサーバの配置が乱れた場合にブレードサーバの機能を入れ替えて配置を変更するとして説明したが、本実施形態で設けられた管理サーバは、各ブレードサーバの負荷状態を常時監視して、負荷が基準値より大きくなった場合に、空きのサーバに同一機能のモジュールを配信して、その機能を持つサーバの数を増加させ、あるいは、負荷が基準値より小さくなった場合に、その機能を持つサーバの1つを空き状態にして、その機能を持つサーバの数を減少させて、サーバシステム全体の処理効率を向上させることができ、この場合にも、配置が乱れたブレードサーバの配置を変更することができる。
図11は複数のブレードサーバ3の配置状態を表示装置24に表示したモニター画面の例を示す図である。図11に示す表示画面1008において、1001、1002はサーバ種別とそれに対応して点灯するLEDの色を示しており、例えば、1001がサーバの機能種別がWEBサーバでLEDの色が緑、1002がサーバの機能種別がメールサーバでLEDの色が赤とする。また、1003は空でLEDを点灯しない場合とする。そして、ブレード1を1009として示しており、ブレード1がWEBサーバ1004、メールサーバ1005で構成され、空1006があることを示しており、表示画面1008に表示される各ブレードサーバ3は、その物理的な位置を示している。ブレードサーバとしてのWEBサーバ1004、メールサーバ1005、空1006は、それぞれ、前述で説明した色が付けられて表示されている。
図12は図11で示す表示画面例に対応する実際の機器におけるLEDの点灯状況を示す図である。図12において、1101は緑色LED、1102は赤色LEDを示し、1103はブレード1、1104はブレードサーバ3を示している。
図11に示すような表示を行うことにより、保守者は、モニタ画面からブレード1におけるブレードサーバ3の配置の状態が一目で判る。また、実際の機器においても、図12に示すように、ブレードサーバ毎に機能種別に対応した色のLEDが点灯しているので、保守者は、一目で各ブレードサーバの機能を知ることができる。
図13はブレードシステムが複数段で構成されていて複数のブレードをグループとした場合の複数のブレードサーバ3の配置状態を表示装置24に表示したモニター画面の例を示す図である。
図13に示す表示画面1206において、1201、1202、1203はサーバ種別とそれに対応して点灯するLEDの色を示しており、例えば、1001がサーバの機能種別がWEBサーバでLEDの色が緑、1002がサーバの機能種別がメールサーバでLEDの色が赤、1203がサーバの機能種別がDHCPサーバでLEDの色が青とする。また、1204は空でLEDを点灯しない場合とする。そして、1205はブレード1を収納する筐体を示しており、1207はWEBサーバ、1208はメールサーバ、1209はDHCPサーバ、1210は空を示しており、表示画面1205に表示される各ブレードサーバ3は、その物理的な位置を示している。ブレードサーバとしてのWEBサーバ1207、メールサーバ1208、DHCPサーバ1209、空1210は、それぞれ、前述で説明した色が付けられて表示されている。
図14は図13で示す表示画面例に対応する実際の機器におけるLEDの点灯状況を示す図である。図14において、1302は緑色LED、1303は赤色LED、1304は青色LEDを示し、1106はブレード1、1305はブレードサーバ3を示している。また、1301は複数のブレード1を収納した筐体である。
図13に示すような表示を行うことにより、保守者は、モニタ画面から複数のブレード1の配置、各ブレードにおけるブレードサーバ3の配置の状態を一目で知ることができる。また、実際の機器においても、図14に示すように、ブレードサーバ毎に機能種別に対応した色のLEDが点灯しているので、保守者は、一目で各ブレードサーバの機能を知ることができる。
前述で説明したモニタ画面の表示例及び実際の機器におけるLEDの点灯例では、WEBサーバを緑、メールサーバを赤、DHCPサーバを青に対応付けているものとして説明したが、サーバの機能種別と、色との対応は任意に設定することができる。また、実際の機器における色の表示は、色の表示ができるものであればLEDに限らず他の点灯、表示素子を使用することもできる。また、図11〜図14の説明では、ブレードサーバの機能種別に対して対応する色を割り当てて表示、点灯させるとして説明したが、障害等により停止状態となったブレードサーバを判り易く表示するために、機能種別とは異なる色でその障害を表示する、あるいは、表示を点滅させる等の手段を設けることができる。
前述した本実施形態における各処理は、処理プログラムとして構成することができ、この処理プログラムは、HD、DAT、FD、MO、DVD−ROM、CD−ROM等の記録媒体に格納して提供することができる。
図15はブレード1内のブレードサーバの配置を表示画面から手作業により配置変換する操作について説明する図である。
図15において、前述で説明した場合と同様に、1401、1402はサーバ種別とそれに対応して点灯するLEDの色を示しており、例えば、1401がサーバの機能種別がWEBサーバでLEDの色が緑、1402がサーバの機能種別がメールサーバでLEDの色が赤とする。また、1403は空でLEDを点灯しない場合とする。
いま、モニタの表示画面に1404として示すようなブレードの配列が表示されているものとする。この配列では、WEBサーバ1408、メールサーバ1409、空1410が整列されずに配置されている。このような配置を画面操作により手作業で配置を変更することとする。この場合、例えば、1406として示すように、6番のWEBサーバをマウスによるドラックアンドドロップにより、2番のメールサーバの位置に移動させる操作を行う。これにより、表示画面上で、ドラック元のサーバ種別とドラック先のサーバ種別とが変更され、表示画面上の配列が、1405として示すようなものとなる。このような操作により手作業で配置を決定した後、1407として示す「整列実行」の画面上のボタンをマウスでクリックすることにより、管理サーバ7によるブレードサーバの並べ替えの処理が開始される。
図16は図15により説明した「整列実行」の画面上のボタンがクリックされたときに開始されるブレードサーバの並べ替えの処理動作を説明するフローチャートである。このフローにおいて、ステップ1501、1502、1503での処理は、それぞれ、図5に示すフローにより説明したステップ412、413、414での処理と同一であるので、ここでの説明は省略する。なお、図6に示して説明した配置変換後のテーブルは、図15での表示画面上での操作が行われたときに設定されるものとする。
一般に、ブレードシステムの管理において、ブレードシステムに搭載されたブレードサーバを保守の目的で抜き差しする作業やそれぞれのサーバに設置されたリセットボタンを操作する作業が発生するが、現在のブレードシステムでは保守者が対象となるサーバを目で見て判別する手段に乏しく、誤作業によりシステムに致命的な打撃を与えることも少なくない。
前述した第1の実施形態によれば、サーバを機能種別毎に分類し、その配列を自動的に整理する機能を提供することができるので、これにより、保守の容易性の向上を図ることができる。また、保守作業が必要となる要因として搭載されたサーバの故障があり、1つのサーバが故障したことにより搭載された他のサーバの負荷の不均衡が生じる可能性があるが、前述した本実施形態によれば、これを回避するため、負荷均衡化を図るためにサーバの機能を自動的に入れ替える機能を提供することができるので、これにより、保守が行われるまでの間ブレードシステムの処理能力を最大限に活用することが可能となる。
≪第2の実施形態≫
次に、本発明の第2の実施形態について説明する。第2の実施形態は、ブレードシステムにおいて、ユニット(ブレードサーバ)内で業務(機能)を拡張しなければならないスケールアップと、ユニット内である必要はなくユニット間であっても業務を拡張することができるスケールアウトとが混在していても、スケールアップを妨げることなく、業務をCPUブレード(計算機)に割り当てることを可能とするものである。なお、スケールアップは、1つの業務を割り当てる複数のCPUブレード間の関係が密結合である(CPUブレード間のデータ通信が高速である)場合の拡張処理である。また、スケールアウトは、1つの業務を割り当てる複数のCPUブレード間の関係が疎結合である(CPUブレード間のデータ通信が高速でない)場合の拡張処理である。スケールアップ(scale up)およびスケールアウト(scale out)の具体的な技術内容については、それぞれ特許文献2および特許文献3に記載されている。
(システムの構成と概要)
図17は、第2の実施形態に係るサーバシステムの構成例を示す図である。サーバシステム100は、管理サーバ101、複数のサーバ115およびディスクアレイ装置113を含んで構成される。
サーバ115は、FCA(Fibre Channel Adapter)116を介してファイバチャネルスイッチ111に接続され、NIC(Network Interface Card)117を介してネットワークスイッチ112に接続されている。また、サーバ115は、BMC(Baseboard Management Controller)118を介して管理サーバ101に接続されている。ファイバチャ
ネルスイッチ111は、管理サーバ101、ディスクアレイ装置113およびサーバ115に接続されている。これにより、サーバ115は、ファイバチャネルスイッチ111経由でディスクアレイ装置113にアクセスすることができる。ネットワークスイッチ112は、管理サーバ101、ディスクアレイ装置113およびサーバ115に接続されている。これにより、管理サーバ101は、ネットワークスイッチ112経由でディスクアレイ装置113およびサーバ115の監視や制御を行うことができる。ディスクアレイ装置113は、ハードディスク装置114やCPU、メモリ(図示せず)などから構成される。なお、サーバ115の構成の詳細は後記する。また、ファイバチャネルスイッチには、一般のスイッチを利用することも可能であり、本実施形態がファイバチャネルスイッチに限定されるものではない。
管理サーバ101は、ファイバチャネルスイッチ111を介してサーバ115およびディスクアレイ装置113に接続されている。また、ネットワークスイッチ112を介してもサーバ115およびディスクアレイ装置113に接続されている。さらに、管理サーバ101は、ネットワークを介してサーバ115に内蔵されたBMC118に接続されている。このBMC118にアクセスすることによって、サーバ115のハードウェアの状態監視、電源制御、サーバ115のリセットなどを行うことができる。一般に、BMC118は、サーバ115とは別の電源から電力供給されているので、サーバ115が電源停止していても、管理サーバ101は、ネットワークを介してBMC118を遠隔操作することができる。
管理サーバ101は、サーバ115、ファイバチャネルスイッチ111、ネットワークスイッチ112およびディスクアレイ装置113に対し、ネットワークを経由して状態の監視や必要に応じた制御を行う。管理サーバ(管理装置、サービスプロセッサともいう)101は、CPU121およびメモリ122を含んで構成される。管理サーバ101においては、CPU121がメモリ122に格納されている割り当てプログラム102を実行することによって、所定の機能が実現される。ここで、所定の機能とは、複数のサーバ115上の稼動業務の新規割り当てや拡張(スケールアップ、スケールアウト)を制御することである。
割り当てプログラム102は、割り当て・拡張要求受付部103、リソース監視部104、割り当て最適化部105、割り当て実行部106および管理テーブル107を含んで構成される。割り当て・拡張要求受付部103は、管理サーバ101の入力手段(図示せず。キーボードやマウスなど)から、システム管理者によるサーバ115への稼動業務の新規割り当てまたは拡張の要求を受付ける。リソース監視部104は、サーバ115における稼動業務のCPUリソース状況を監視する。割り当て最適化部105は、割り当て・拡張要求受付部103またはリソース監視部104からの指示により、サーバ115のリソース割り当てを決定する。割り当て実行部106は、割り当て最適化部105が決定したリソース割り当ての結果を実際の複数のサーバ115に反映させる。管理テーブル107は、SMP構成定義テーブル108、ブレード割り当て管理テーブル109および稼動業務管理テーブル110を含んで構成される。各テーブルの詳細は後記する。
図18は、本実施形態におけるサーバの構成例を示す図である。サーバ115は、メモリ201、CPU202、FCA116、NIC117およびBMC118を含んで構成される。メモリ201は、プログラムやデータを格納する。CPU202は、メモリ201に格納されたプログラムを実行する。
FCA116は、通信機構203およびWWN(World Wide Name)格納メモリ204を含んで構成される。通信機構203は、ファイバチャネルスイッチ111に接続され、ファイバチャネル通信を行う。WWN格納メモリ204は、WWNを格納する不揮発性メモリである。WWNとは、ファイバチャネル通信に必要とされるユニークなデバイス識別子であり、ファイバチャネルスイッチ111に接続されるノード(サーバ115を含む)ごとに付与される。WWNによってファイバチャネルの通信相手を特定することができる。通信機構203は、WWN格納メモリ204内のWWNを参照しながらファイバチャネル通信を行う。
NIC117は、通信機構205およびネットワークブート機構206を含んで構成される。通信機構205は、ネットワークスイッチ112に接続され、ネットワーク通信を行う。ネットワークブート機構206は、サーバ115の起動時に動作させることができ、ネットワークを介してサーバ115の起動に必要なプログラムを取得する機能を有している。
BMC118は、主にサーバ115のハードウェアの監視や制御を行う。BMC118は、通信機構207およびサーバ監視機構208を含んで構成される。通信機構207は、サーバ115のハードウェアに関する情報の転送や制御コマンドの受付・転送を行う。通信機構207は、一般的なネットワーク接続機器によって実現される。サーバ監視機構208は、サーバ115のハードウェアに発生した異常を検知し、通信機構207に通知する。そして、通信機構207からネットワーク経由で管理サーバ101に異常を通知する。また、遠隔(管理サーバ101を含む)から通信機構207を介して、サーバ115の電源ON/OFFやハードウェアリセットを行うことができる。そのため、BMC118は、一般にサーバ115の電源とは別系統の電源から電力供給されており、サーバ115の電源がOFFの状態であっても、通信機構207を介して遠隔制御を行うことができる。
(サーバ(CPUブレード)の接続形態)
図19は、本実施形態におけるサーバの接続形態例を示す図である。サーバシャーシは、複数のCPUブレード(計算機、ブレード)により1つの論理計算機を構成するブレードサーバ(計算機ユニット)に対応する。1つのCPUブレードは、図17に示す1台のサーバ115に対応する。サーバシャーシには、複数のCPUブレードを収めることができる。本実施形態では、1つのサーバシャーシに8枚のCPUブレードを収納できることとする。また、サーバシャーシは複数台あってもよく、その複数台のサーバシャーシ(ブレードサーバ)をブレードシステムという。図17に示す管理サーバ101は、複数台のサーバシャーシと、それぞれに収められた複数枚のCPUブレードとを管理することができる。
図20は、CPUブレードのスケールアウトを示す図である。サーバシャーシ内の左端にあるCPUブレードP上の業務をスケールアウトする場合には、CPUブレードが隣り合っている必要はなく、例えば、CPUブレードQへスケールアウトしてもよい。また、異なるユニット(詳細は後記)や別のサーバシャーシ内のCPUブレードRへのスケールアウトを行ってもよい。すなわち、スケールアウトは、サーバシャーシ内やサーバシャーシ間にかかわらず、空いているCPUブレードへ行うことが可能である。
図21は、CPUブレードのスケールアップを示す図である。CPUブレードをSMP(2台以上のCPUによる対称型)構成として、そのSMP構成による稼動業務をスケールアップすることができる。例えば、CPUブレード2枚によるSMP構成を、CPUブレード4枚によるSMP構成にスケールアップして、所定の業務処理を行う性能を向上させることができる。SMP構成は共有メモリを有することが多いが、本実施形態は、複数のCPU(計算機やブレード)で1つの論理計算機を構成可能なシステム構成であれば実施可能であり、SMP構成に限定されるものではない。
図22は、CPUブレードのスケールアップの制約を示す図である。スケールアップの制約としては、まず、サーバシャーシを跨るSMP構成とすることはできない。例えば、図22に示すように、CPUブレードSおよびTのSMP構成があった場合に、別のサーバシャーシに収納されたCPUブレードUを含めたSMP構成にスケールアップすることはできない。また、スケールアップする対象のCPUブレードに対して、隣接するスロットにCPUブレードが挿入されておらず、CPUブレードの配置が不連続になる場合には、SMP構成とすることはできない。例えば、図22に示すように、CPUブレードYおよびZのSMP構成があった場合に、すぐ左隣のスロットを空けてさらに左隣のCPUブレードXを含めたSMP構成にスケールアップすることはできない。以上を換言すれば、スケールアップは、1つのサーバシャーシやユニット内においてCPUブレードが連続したスロットに配置されている場合に行うことができる。
これらの制約は、CPUブレードのSMP構成においては、CPUブレード間を密結合にする必要があることによる。すなわち、密結合するためには、CPUブレード間を接続するバスを高性能に(特に通信性能を高く)することが望ましい(CPUブレード間のアクセス速度が高速な配置にする必要がある)が、高性能なバスほど接続距離は短くなる。これにより、CPUブレード間の距離を短くする必要があり、サーバシャーシ内の不連続な配置やサーバシャーシ間跨りによるSMP構成は不可になる。
図23は、本実施形態において用いる用語の定義を示す図である。SMP構成を組むことのできる最大CPUブレード数を「ユニット化係数」とする。例えば、最大SMP構成数がCPUブレード4枚である場合には、ユニット化係数は4となる。図23に示すように、本実施形態では、ユニット化係数を4としている。この場合、ユニット1と、ユニット2とは、1つのサーバシャーシ上に構成されてはいるが、それらの間の接続はなされていない。なお、ユニット化係数が4であるユニット1やユニット2を別々のサーバシャーシ上にそれぞれ構成するようにしてもよい。
(テーブルの構成)
図24は、図17のSMP構成定義テーブル108の詳細を示す図である。SMP構成定義テーブル108には、SMP構成規則が定義されている。SMP構成規則は、システム管理者があらかじめ作成する。SMP構成定義テーブル108の組み合わせ#1081には、許容する組み合わせの通し番号が格納される。CPUスロット#1082には、SMP構成を記載する。例えば、CPUブレード1枚が2wayCPUである場合、1ユニット内にCPUブレード1枚の2way・SMP構成のサーバを4組作ることができる。また、CPUブレード2枚の4way・SMP構成のサーバであれば2組作ることができる。さらに、最大CPUブレード4枚のSMP構成としているため、8way・SMP構成のサーバであれば1ユニット内に1つ作ることができる。これによれば、組み合わせ#1081が小さいほど、高性能であると言える。ただし、1ユニット内のスロットにCPUブレードがすべて挿入されているという前提がある。また、図24に示す「空き」の状態とは、CPUブレードが挿入されていない状態ではなく、当該スロットのCPUブレードはSMP構成として使用しないということを表している。
なお、図24では、組み合わせ#2、4〜7に示すように、CPUスロット#1から昇順に連続して使用するようになっているが、CPUスロット#4から降順に連続して使用するようにしてもよい。また、スロットが連続するように選択すればよいので、例えば、CPUスロット#2、3によるSMP構成を採ることも可能である。
図25は、図17のブレード割り当て管理テーブル109の詳細を示す図である。ブレード割り当て管理テーブル109は、ユニットの数だけ作成され、ユニットごとのCPUブレードの割り当て使用状況を保持する。ブレード割り当て管理テーブル109は、ブレード番号1091および割り当て業務ID1092を含むレコードから構成される。ブレード番号1091は、CPUブレードの番号がインデックスとして格納される。ブレード番号1091は、SMP構成定義テーブル108のCPUスロット#1082に対応する。割り当て業務ID1092は、ブレード番号1091のCPUブレードに割り当てられた業務IDが格納される。業務IDについては、図26により説明する。
図26は、図17における稼動業務管理テーブル110の詳細を示す図である。稼動業務管理テーブル110は、CPUブレード上で稼動させる業務と、その管理情報を管理する。稼動業務管理テーブル110は、業務ID1101、業務名称1102、業務特性1103および拡張タイプ1104を含むレコードから構成される。業務ID1101は、稼動業務管理テーブル110に登録する稼動業務(業務名称)のインデックスを固有の番号として付与したものである。業務名称1102は、稼動業務の名称であり、DBアプリケーションやWebアプリケーションなどの一般的な種別から具体的なアプリケーションの名前までが設定される。業務特性1103には、ブレード自動割り当て実行時に業務を停止し、CPUブレードをリブート可能または不可のいずれかが設定される。拡張タイプ1104には、業務の拡張タイプがスケールアップまたはスケールアウトのいずれかが設定される。
図27は、割り当て要求情報の詳細を示す図である。割り当て要求情報271は、システム管理者が新規に業務を稼動させる場合にCPUリソースの割り当てに必要となる情報である。割り当て要求情報271は、システム管理者が管理サーバ101(図17参照)の入力手段(図示せず。キーボードやマウスなど)を操作することによって、割り当て・拡張要求受付部103に入力される。割り当て要求情報271に従ってCPUリソースの割り当てが決定される。割り当て要求情報271は、業務名称272、業務特性273、拡張タイプ274および性能要件275を含むレコードならびにブレード割り当て自動実行フラグ276から構成される。業務名称272は、図26の業務名称1102と同義である。業務特性273は、図26の業務特性1103と同義である。拡張タイプ274は、図26の拡張タイプ1104と同義である。性能要件275は、CPUが何way必要かを示すものである。ブレード割り当て自動実行フラグ276は、CPUブレードの割り当てをシステム管理者の承認なしに実行してよいか否かを示すフラグである。
図28は、拡張要求情報/性能低下検出情報を示す図である。拡張要求情報/性能低下検出情報281は、割り当て・拡張要求受付部103がシステム管理者から入力手段を介して既存業務にCPUリソースを拡張する要求を受けた場合、リソース監視部104が稼動業務のCPUリソースの不足を検出した場合などに作成される情報である。拡張要求情報/性能低下検出情報281は、拡張対象業務ID282を含むレコードから構成される。拡張対象業務ID282は、CPUブレードの割り当ての拡張を必要とする業務IDであり、稼動業務管理テーブル110(図26参照)の業務ID1101に対応する。従って、拡張対象業務ID282をキーとして稼動業務管理テーブル110を検索することによって、拡張の対象となる業務名称などの情報を参照することができる。ここでは、性能要件は、デフォルトとして2way(CPUブレード1枚)であるものとするが、システム管理者によって、または、リソース監視部104が検出したCPUリソースの不足状況に応じて性能要件を変更するようにしてもよい。
割り当て・拡張要求受付部103が拡張対象業務ID282を取得するには、例えば、次の手順による。すなわち、既に割り当てられている業務名称を管理サーバ101の表示手段(図示せず。ディスプレイなど)に表示する。次に、その表示された業務名称の中から、システム管理者が拡張要求の対象として選択した業務名称により、稼動業務管理テーブル110の業務名称1102を検索する。そして、その検索により一致した業務名称1102の業務ID1101を拡張対象業務ID282とする。
(システムの処理)
図29は、管理サーバ101の割り当てプログラム102の処理フローを示す図である。まず、割り当てプログラム102の割り当て・拡張要求受付部103が、システム管理者からの新規割り当て要求・拡張要求を受付ける(ステップ2901)。この場合、リソース監視部104が性能低下を検出することもある。すなわち、以下説明するCPUブレードの割り当て処理は、割り当て・拡張要求受付部103またはリソース監視部104によってトリガを与えられる。次に、割り当て最適化部105が、割り当て・拡張要求受付部103またはリソース監視部104から必要な情報を入力し、CPUブレードの割り当て位置を最適化し、決定する(ステップ2902)。そして、割り当てプログラム102が、ステップ2902の結果に従ってCPUブレードの割り当てが可能であるか否か(割り当て結果を実際にハードウェアに反映できるか否か)を判定する(ステップ2903)。割り当てが可能であれば(ステップ2903のYes)、割り当て実行部106がCPUブレードの割り当てを実行する(ステップ2904)。割り当てが可能でなければ(ステップ2903のNo)、割り当てを行わずに処理を終了する。
図30は、図29で示した割り当て最適化(ステップ2902)の詳細な処理フローを示す図である。まず、管理サーバ101の割り当て最適化部105は、稼動業務管理テーブル110およびブレード割り当て管理テーブル109を入力する(ステップ3001)。次に、割り当て・拡張要求受付部103またはリソース監視部104からの入力情報が、新規割り当て要求であるか、拡張要求/性能低下検出であるかを判定する(ステップ3002)。
新規割り当て要求であれば、割り当て最適化部105は、割り当て要求情報271(図27参照)を拡張タイプ274でソートする(ステップ3003)。これによって、割り当て要求情報271のレコードをスケールアップおよびスケールアウトにグループ分けすることができる。なお、優先順位の規則は、スケールアップ>スケールアウトである。さらに、割り当て要求情報271をスケールアップおよびスケールアウトのグループごとに性能要件275でソートする(ステップ3004)。これによって、それぞれのグループごとに、割り当て要求情報271のレコードを性能要件275の厳しい(way数が大きい)順番に並べ替えることができる。すなわち、優先順位の規則は、8way>6way>4way>2wayである。以上によって、割り当て要求情報271の各レコードを割り当て処理の優先順位に並べることができる。
図31は、図27の割り当て要求情報271を優先順位付けした後の割り当て要求情報を示す図である。図31に示すように、4個のレコードが、スケールアップおよびスケールアウトに分類され、さらにスケールアップの中で性能要件の厳しい順番に並んでいる。なお、業務ID312は、ソートによる優先順位付けを行った後に付与され、以下の処理では割り当て要求業務IDとして用いられるものとする。
図30に戻って、優先順位に従って、業務ごとに割り当て位置の決定を行う。まず、割り当て要求業務IDとして、変数nを1に初期化する(ステップ3005)。そして、その業務ID(n)が要求業務総数を超えるまで(ステップ3006)、業務ID(n)を+1ずつ更新(インクリメント)しながら(ステップ3008)、割り当て位置の決定を行う(ステップ3007)。割り当て位置決定の詳細は、後記する。
ステップ3002の判定結果が拡張要求/性能低下検出であれば、割り当て最適化部105は、拡張要求情報/性能低下検出情報281(図28参照)を拡張タイプ1104(図26参照)でソートする(ステップ3009)。ここで、拡張対象業務ID282は、既存の業務IDを示すものであり、業務ID1101(図26参照)に対応するので、稼動業務管理テーブル110の当該レコードを参照することによって拡張タイプ1104を特定することができる。さらに、拡張要求情報/性能低下検出情報281をスケールアップおよびスケールアウトのグループごとに性能要件でソートする(ステップ3010)。この場合の性能要件は、デフォルトとして2wayであるが、システム管理者やリソース監視部104によって他の値が設定された場合には、ステップ3010が有効になる。以上によって、拡張要求情報/性能低下検出情報281の各レコードを割り当て処理の優先順位に並べることができる。なお、各レコードの優先順位に対応して拡張要求業務IDが付与され、以下の処理で用いられるものとする。
次に、優先順位に従って、業務ごとに拡張の処理を行う。まず、拡張要求業務IDとして、変数nを1に初期化する(ステップ3011)。そして、その業務ID(n)が要求業務総数を超えるまで(ステップ3012)、業務ID(n)を+1ずつ更新しながら(ステップ3014)、拡張の処理を行う(ステップ3013)。拡張の処理の詳細は、後記する。
図32は、図30の割り当て位置決定(ステップ3007)の処理フローを示す図である。割り当て最適化部105は、割り当て要求情報271の拡張タイプ274を参照し(ステップ3201)、それに応じてスケールアップの割り当て位置決定(ステップ3202)またはスケールアウトの割り当て位置決定(ステップ3206)のいずれかを実行する。スケールアップの割り当て位置決定が解決できなかった場合(ステップ3203のNo)、当該ユニット内における他のCPUブレードに割り当てられている業務を別のユニットに割り当てるべく業務再配置を行い(ステップ3204)、割り当て位置決定を再実行する(ステップ3205)。ただし、再実行回数(例えば、1回)を決めておき、割り当て位置決定の処理が無限ループにならないようにする。解決できた場合には(ステップ3203のYes)、そのまま処理を終了する。
スケールアウトの割り当て位置決定が解決できなかった場合(ステップ3207のNo)は、空きのCPUブレードがないことを意味する。そこで、割り当て最適化部105は、システム管理者にその旨を通知する(ステップ3208)。具体的には、管理サーバ101の表示手段(図示せず。ディスプレイなど)や音声出力手段(図示せず。スピーカなど)によって、システム管理者に知らせる(以下、システム管理者への通知について同様)。解決できた場合には(ステップ3207のYes)、そのまま処理を終了する。
図33は、図32に示すスケールアップの割り当て位置決定(ステップ3202)の詳細な処理フローを示す図である。スケールアップする業務は、最も左端(一端)のCPUスロットが空いているユニットを探して割り当てるようにする。これは、SMP構成にはユニット内の連続配置という制約があるため、将来拡張可能な分をできる限り多く確保するためである。
まず、割り当て最適化部105は、SMP構成定義テーブル108(図24参照)を入力する(ステップ3301)。次に、割り当て要求業務の性能要件を取得し(ステップ3302)、必要なCPUブレード数を必要数として保持する。また、ステップ3304ないし3314の処理を行うための初期設定処理として、割り当て済み判定フラグfをFALSE(偽)とし、割り当て可能スロット位置sを1とする(ステップ3303)。そして、「f=TRUE(正)」または「s+必要数−1>ユニット化係数」の条件が満たされるまで、ステップ3305ないし3313の処理(スロット位置ごとの処理)を繰り返す(ステップ3304ないし3314)。換言すると、ステップ3304の条件が満たされれば、割り当て位置決定の処理を終了する。なお、その条件のうち、前者は、CPUブレードの割り当てができたことを意味する。後者は、すべてのスロット位置に関して割り当て可能か否かのチェックが完了したことを意味する。
スロット位置ごとの処理として、割り当て最適化部105は、最初にユニット数カウンタuを1とする(ステップ3305)。これは、ステップ3306ないし3312の処理を行うための初期設定処理である。そして、「f=TRUE」または「u>全ユニット数」の条件が満たされるまで、ステップ3307ないし3311の処理(所定のスロット位置に関するユニットごとの処理)を繰り返す(ステップ3306ないし3312)。換言すると、ステップ3306の条件が満たされれば、所定のスロット位置に関するユニットごとの処理を終了する。なお、その条件のうち、前者は、CPUブレードの割り当てができたことを意味する。後者は、所定のスロット位置に関して、すべてのユニットについて割り当て可能か否かのチェックが完了したことを意味する。
所定のスロット位置に関するユニットごとの処理として、割り当て最適化部105は、まず、ブレード割り当て管理テーブル109を参照して、ユニット(番号=u)のスロット(位置=s〜s+必要数−1)に業務IDが設定済であるか否かをチェックする(ステップ3307)。例えば、s=1、必要数=3であれば、スロット位置に対応するブレード番号1091(図25参照)の1〜3(=1+3−1)のチェックを行う。設定済でなければ(ステップ3307のNo)、稼動業務管理テーブル110に割り当て要求業務IDを仮設定する(ステップ3308)。また、ブレード割り当て管理テーブル109のユニット(番号=u)のスロット(位置=s〜s+必要数−1)に割り当て要求業務IDを仮設定する(ステップ3309)。具体的には、そのスロット位置に対応するブレード番号1091の割り当て業務ID1092に仮設定する。このとき、図30のステップ3001で入力したSMP構成定義テーブル108を参照して、仮設定されたSMP構成が規則に沿っているか否かを確認する。そして、割り当て済み判定フラグfをTRUEにする(ステップ3310)。
ここで、「仮設定」としたのは、システム管理者の意向によっては、実際に業務の割り当てを行わないことがあるからである。その最終的な決定は、図29の割り当て実行(ステップ2904)に委ねられる。
ステップ3307で設定済であれば(ステップ3307のYes)、ユニット数カウンタuを+1更新して(ステップ3311)、次のユニットについて割り当て可能か否かのチェックを行う(ステップ3307)。このようにして、所定のスロット位置に関するユニットごとの処理が行われる。全ユニットについてチェックを行っても割り当てができなかった場合には、次にチェックするスロット位置を設定するためにsを+1更新して(ステップ3313)、そのスロット位置に関する処理を開始する(ステップ3305)。このようにして、スロット位置ごとの処理が行われる。
なお、業務IDの割り当てが行われた場合には(ステップ3308ないし3310)、f=TRUEとなってステップ3306の条件を満たすので、ステップ3306ないし3312の処理から抜けることになる。さらに、ステップ3304の条件も満たすので、ステップ3304ないし3314の処理から抜けることになり、割り当て位置決定の処理が終了する。また、すべての割り当て可能なスロット位置に関してチェックを行っても割り当てができなかった場合には、ステップ3304の後者の条件を満たすので、割り当て済み判定フラグf=FALSEの状態で、割り当て位置決定の処理が終了する。
以上説明したように、スケールアップの割り当て位置決定の処理は、最も左端のCPUスロットが空いているユニットを探して割り当てるように行われる。例えば、図34に示すような割り当て状態の場合は、ユニット2のスロット3・4に業務Aを割り当てる。
図35は、図32に示すスケールアウトの割り当て位置決定(ステップ3206)の詳細な処理フローを示す図である。スケールアウトする業務は、できる限り右端(他端)のCPUスロットが空いているユニットに1つずつ配置するようにする。これは、ユニット内における左端からのスケールアップをなるべく阻害しない位置に、スケールアウトによる配置を行うためである。
まず、割り当て最適化部105は、ステップ3505ないし3513の処理を行うための初期設定処理として、未割り当てスロット数nを、要求業務の性能要件から求められるCPUブレードの数(例えば、性能要件が2wayならば、n=1)とし、割り当て可能スロット位置sをユニット化係数とする(ステップ3501)。また、ユニットの参照順を変更する(ステップ3502)。この変更では、ステップ3505ないし3511の処理において、ユニット番号の順ではなく、連続した空きのスロット数が多い順にユニットを参照するように参照の順番を設定する。これは、ユニット内のスケールアップをなるべく阻害しないようにするためである。
そして、「n<1」または「s<1」の条件が満たされるまで、ステップ3504ないし3512の処理(スロット位置ごとの処理)を繰り返す(ステップ3503ないし3513)。換言すると、ステップ3503の条件が満たされれば、割り当て位置決定の処理を終了する。なお、その条件のうち、前者は、必要な数のCPUブレードが割当てられたことを意味する。後者は、すべてのスロット位置に関して割り当て可能か否かのチェックが完了したことを意味する。
スロット位置ごとの処理として、割り当て最適化部105は、最初にユニット数カウンタuを1とする(ステップ3504)。これは、ステップ3505ないし3511の処理を行うための初期設定処理である。そして、「n<1」または「u>全ユニット数」の条件が満たされるまで、ステップ3506ないし3510の処理(所定のスロット位置に関するユニットごとの処理)を繰り返す(ステップ3505ないし3511)。換言すると、ステップ3505の条件が満たされれば、所定のスロット位置に関するユニットごとの処理を終了する。なお、その条件のうち、前者は、必要な数のCPUブレードが割当てられたことを意味する。後者は、所定のスロット位置に関して、すべてのユニットについて割り当て可能か否かのチェックが完了したことを意味する。
所定のスロット位置に関するユニットごとの処理として、割り当て最適化部105は、まず、ブレード割り当て管理テーブル109を参照して、参照順番uのユニットのスロット(位置=s)に業務IDが設定済であるか否かをチェックする(ステップ3506)。ここで、参照順番とは、ステップ3502で設定したユニット参照順を示す番号である。設定済でなければ(ステップ3506のNo)、稼動業務管理テーブル110に割り当て要求業務IDを仮設定する(ステップ3507)。また、ブレード割り当て管理テーブル109の参照順番uのユニットのスロット(位置=s)に割り当て要求業務IDを仮設定する(ステップ3508)。「仮設定」については、先に説明した通りである。次に、未割り当てスロット数nを−1更新(デクリメント)する(ステップ3509)。これは、ステップ3507および3508の処理が行われたので、未割り当てスロット数nが1つ減ることを意味する。そして、ユニット数カウンタuを+1更新して(ステップ3510)、次のユニットについて割り当て可能か否かのチェックを行う(ステップ3506)。
なお、業務IDが設定済である場合にも(ステップ3506のYes)、ユニット数カウンタuを+1更新して(ステップ3510)、次のユニットについて割り当て可能か否かのチェックを行う(ステップ3506)。
ステップ3505の条件が満たされた場合には、割当て可能スロット位置sを−1更新して(ステップ3512)、次のスロット位置に関する処理を開始する(ステップ3504)。なお、ステップ3505の条件のうち、前者の条件が満たされた場合は、必要な数のCPUブレードが割当てられたということなので、ステップ3503の条件も満たすことになり、割り当て位置決定の処理を終了する。また、すべてのスロット位置についてチェックを行っても、n<1にならなければ、未割り当てスロット数がnだけ残った状態で処理を終了することになる。
以上説明したように、スケールアウトの割り当て位置決定の処理は、できる限り右端のCPUスロットが空いているユニットを探して割り当てるように行われる。また、なるべく連続した空きスロットが多いユニットを探すように行われる。例えば、図36に示すような割り当て状態の場合には、ユニット1のスロット4およびユニット4のスロット4に業務Aを割り当てる。
図37は、図35のユニット参照順変更(ステップ3502)を説明した図である。スケールアウト業務を割り当てる場合、まずなるべくスケールアップ業務の割り当てられていないユニットから、次に連続した空きのスロット数が多いユニットから参照していくようにする。これは、スケールアップ業務の拡張をなるべく妨げないようにするためである。このようなルールに則って、ユニット3、ユニット4、ユニット1およびユニット2の順番に参照順が入れ替わっている。
図38は、図30の拡張(ステップ3013)の詳細な処理フローを示す図である。割り当て最適化部105は、最初に、図30の3001で入力した稼動業務管理テーブル110を参照して、拡張要求情報/性能低下検出情報281の拡張対象業務ID282(図28参照)に対応する業務の拡張タイプ1104がスケールアップかまたはスケールアウトかを判定する(ステップ3801)。スケールアップであれば(ステップ3801の「スケールアップ」)、まず、図30の3001で入力したブレード割り当て管理テーブル109を参照して、当該業務が割り当てられているCPUブレードの拡張方向に隣接するCPUブレードが空いているか否かを判定する(ステップ3802)。具体的には、当該業務が割当てられているユニット内において、割り当て済みのCPUブレードのうち、最も右側のCPUブレードの右隣に、拡張に必要な数のCPUブレードが空いているか否かを判定する。空いていれば(ステップ3802のYes)、そのままステップ3804に進む。空いていなければ(ステップ3802のNo)、業務再配置を行う(ステップ3803)。
続いて、割り当て最適化部105は、稼動業務管理テーブル110の業務特性1103を参照して、当該業務がリブート可能であるか否かを判定する(ステップ3804)。リブート可能であれば(ステップ3804のYes)、ブレード割り当て管理テーブル109の設定を行う(ステップ3805)。具体的には、SMP構成でスケールアップするために、当該業務に割当てられるCPUブレード枚数を拡張するように、ブレード割り当て管理テーブル109の割り当て業務ID1092を拡張対象の業務IDにより更新する。このとき、図30のステップ3001で入力したSMP構成定義テーブル108を参照して、設定されたSMP構成が規則に沿っているか否かを確認する。リブート不可であれば(ステップ3804のNo)、その旨をシステム管理者に通知する(ステップ3806)。図38は、業務特性がリブート不可の場合に拡張を行わないフローとなっているが、リブートしてよいか否かをシステム管理者に問い合わせて、リブートOKならば拡張を行うようにすることもできる。また、リブート不可のため拡張しないことを、システム管理者に明示的に知らせることもできる。
ステップ3801で、当該業務の拡張タイプがスケールアウトであれば(ステップ3801の「スケールアウト」)、割り当て最適化部105は、ブレード割り当て管理テーブル109を参照して、必要な数の空きのCPUブレードが存在するか否かを判定する(ステップ3807)。空きのCPUブレードが存在すれば(ステップ3807のYes)、ブレード割り当て管理テーブル109の設定を行う(ステップ3808)。具体的には、スケールアウト業務の割り当てアルゴリズムに則って拡張するように、ブレード割り当て管理テーブル109の割り当て業務ID1092を拡張対象の業務IDにより更新する。空きのCPUブレードが存在しなければ(ステップ3807のNo)、業務の拡張ができないので、システム管理者にその旨を通知する(ステップ3809)。
図39は、図32の業務再配置(ステップ3204)および図38の業務再配置(ステップ3803)の詳細な処理フローを示す図である。この業務再配置の処理は、現状の業務割り当てのままでは当該業務のスケールアップができないので、同じユニット内の別のCPUブレードに割当てられている業務を他のユニットに再配置するものである。割り当て最適化部105は、まず、スケールアウトする業務の再配置位置を決定する(ステップ3901)。具体的には、同じユニット内の右側のCPUブレードから割当てられている業務を他のユニットに再配置するために、ブレード割り当て管理テーブル109を参照して、他のユニットに空きのCPUブレードがあるか否かをチェックし、空きのスロット位置を再配置位置として決定する。なお、同じユニット内の最も右端のCPUブレードが空いている場合に、そのスロット位置を再配置位置とすることも可能である。そして、空きのCPUブレードがあったか否か、すなわち、再配置位置の決定が解決したか否かを判定する(ステップ3902)。
再配置位置の決定が解決していれば(ステップ3902のYes)、割り当て最適化部105は、システム管理者にその旨を通知する(ステップ3903)。そして、システム管理者による再配置の実行要求を受信した場合(ステップ3904のYes)、再配置を実行する(ステップ3905)。具体的には、ブレード割り当て管理テーブル109の割り当て業務ID1092を更新して、CPUブレードに対応するサーバ115の設定情報を変更した後、そのサーバ115をリブートする。サーバ115の設定情報の変更やリブートは、BMC118に当該要求を発行することによって行う。再配置の実行要求を受信しなかった場合には(ステップ3904のNo)、再配置を行わずに処理を終了する。ステップ3902で、再配置位置の決定が解決していなければ(ステップ3902のNo)、割り当て最適化部105は、システム管理者にその旨を通知して(ステップ3906)、処理を終了する。
図40は、図29の割り当て実行(ステップ2904)の詳細な処理フローを示す図である。管理サーバ101の割り当て実行部106は、まず、システム管理者に割り当て位置決定結果を通知する(ステップ4001)。次に、新規割り当てであるか否かを判定する(ステップ4002)。これは、図30のステップ3002と同様に判定する。新規割り当てであれば(ステップ4002のYes)、割り当て要求情報271(図27参照)のブレード割り当て自動実行フラグ276がONであるか否かを判定する(ステップ4003)。ONでなければ(ステップ4003のNo)、システム管理者からの実行要求を受信したか否かをチェックする(ステップ4004)。実行要求を受信していなれば(ステップ4004のNo)、実際の割り当てを行わないので、ブレード割り当て管理テーブル109および稼動業務管理テーブル110の仮設定を元に戻す(ステップ4006)。新規割り当てでない場合(ステップ4002のNo)、ブレード割り当て自動実行フラグ276がONである場合(ステップ4003のYes)、または、実行要求を受信した場合(ステップ4004のYes)には、ハードウェア構成を変更する(ステップ4005)。具体的には、業務を割り当てたCPUブレードに対応するサーバ115の設定情報を変更した後、そのサーバ115をリブートする。サーバ115の設定情報の変更やリブートは、BMC118に当該要求を発行することによって行う。これによって、ブレード割り当て管理テーブル109および稼動業務管理テーブル110の仮設定または設定が有効になる。
前記した本発明の第2の実施形態によれば、業務をCPUブレードに新規に割り当てたり、拡張したりする場合に、拡張タイプがスケールアップである業務を同じユニット内の左端のCPUブレードから割り当て、拡張タイプがスケールアウトである業務をできる限り右端のCPUスロットが空いているユニットに割り当てるので、スケールアップの業務を拡張するべき空きのCPUブレードをできる限り多く確保することができる。また、スケールアップの業務の新規割り当てや拡張がそのままの状態ではできない場合であっても、それができない要因となっているCPUブレードに割り当てられているスケールアウトの業務を他のユニットのCPUブレードに再配置するので、スケールアップの業務を割り当てる空きのCPUブレードを確保することができる。
以上本発明の第2の実施形態について説明したが、図17に示す管理サーバ101のそれぞれで実行されるプログラム(ブレード割り当てプログラムを含む)をコンピュータによる読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、本発明の第2の実施の形態に係る管理サーバが実現されるものとする。なお、プログラムをインターネットなどのネットワーク経由でコンピュータシステムに提供するようにしてもよい。
≪その他の実施形態≫
以上本発明について好適な実施形態について一例を示したが、本発明は前記実施形態に限定されず、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。例えば、以下のような実施形態が考えられる。
(1)前記第2の実施形態では、スケールアップの例として、2wayCPUのCPUブレードによるSMP構成について記載したが、CPUブレードが1wayCPUであってもよく、また、CPUブレード間の関係が密結合であればSMP構成である必要はない。(2)前記第2の実施形態では、ユニットにおいて、左端のCPUブレードからスケールアップの業務を割り当て、右端のCPUブレードにスケールアウトの業務を割り当てるように記載したが、左右逆であってもよい。
(3)前記第2の実施形態では、図17に示すように、管理サーバ101がサーバ115とは別の筐体として説明したが、ブレードサーバ(同一の筐体)内のサーバ115(CPUブレード)やその他のCPUを管理サーバ101として用いてもよい。