JP4469306B2 - 計算機システム、管理サーバ - Google Patents

Description

本発明は、複数の計算機に機能を割り当てる計算機システム技術に関する。

１つの筐体内に複数のサーバが収納されて構成されるサーバシステムに関する従来技術
として、ブレードシステムと呼ばれるサーバシステムが知られている。ブレードシステム
は、１または複数の基板（ＣＰＵブレード）により構成されるサーバ（以下、ブレードまたはブレードサーバという）の複数台を１つの筐体に収納して構成される。そして、１つの筐体に収納される複数台のブレードサーバは、複数の機能の異なるサーバを含んでいる。

そして、前述したように構成されるブレードシステムの保守等は、予め作業の予定を組んでおきその定義された情報に基づいて、ブレードシステムを構成するサーバの機能のイメージの配置（デプロイ）およびそのイメージのブートを行うことにより、サーバ上で機能を実行することが一般的であり、このような保守は、人手により行われるものである。デプロイ（deploy）に関する具体的な技術内容については、特許文献１に記載されている。

なお、この種のブレードシステムのブレードサーバの構成の変更を自動的に行う従来技
術は、これまで知られていない。
米国特許出願公開第２００５／００１０９１８号明細書 米国特許出願公開第２００５／００５３０５７号明細書 米国特許出願公開第２００４／０２６７９２０号明細書

従来のブレードシステムは、複数の機能を持ったブレードサーバを混在して搭載して構
成されているが、それらのブレードサーバが、どのような機能を持っているか外見から一
目で判るように構成されていないのが一般的であり、そのため、保守を行う際に、保守者
が誤って目的と異なるブレードサーバの点検をしてしまう可能性があるという問題点を有
している。また、従来のブレードシステム（計算機システム）は、搭載されているブレードサーバが故障等により停止した場合、ブレードサーバの機能毎の負荷の均衡が取れなくなり、負荷が大きくなったブレードサーバでのサービスを充分に行うことができなくなる等により、ビジネスチャンスを失う可能性も生じるという問題点を有している。

次に、ブレードサーバにおいて、１つの業務を割当てるべき複数のＣＰＵブレード（計算機、ブレード）の構成には、クラスタ構成およびＳＭＰ（Symmetric MultiProcessor）構成がある。クラスタ構成においては、ＣＰＵブレード間の関係が疎結合であるので、ネットワーク接続されていれば複数のブレードサーバ（計算機ユニット）にわたって業務を配置してもよく、ブレードサーバ内であっても、ブレードサーバ間であっても拡張することができる。このような計算機システムの拡張をスケールアウトという。ところが、ＳＭＰ構成においては、ＣＰＵブレード間の関係が密結合であるので、ＣＰＵブレード間を高速なバスで結合するためにその間の接続距離を短くする（通信時間を短縮し、高速な通信を実現する）ことが望ましく、同じブレードサーバ内で、かつ、隣接するスロットに業務を配置することが望ましい。すなわち、ＳＭＰ構成には、複数のＣＰＵブレードを同じブレードサーバ内で連続配置することにより拡張することが望ましいという制約がある。このようなブレードサーバの拡張をスケールアップという。スケールアウトおよびスケールアップが混在したブレードシステムでは、同じブレードサーバ内のスケールアップのために確保しておくべきＣＰＵブレードをスケールアウトに割り当ててしまい、スケールアップの自由度を小さくしてしまうという問題点がある。なお、スケールアップ（scale up）およびスケールアウト（scale out）の具体的な技術内容については、それぞれ特許文献２および特許文献３に記載されている。

本発明の目的は、前述した従来技術の問題点を解決し、ブレードシステムに搭載されて
いるブレードサーバがどのような機能を持っているか外見から一目で判るようにし、ブレ
ードシステムに搭載されたブレードサーバの配置変換を可能にすると共に、故障によって
生じた負荷の変化を感知しブレードサーバの機能の変更によるシステム構成を変化させる
ことを可能とすることにある。また、本発明の目的は、好適なスケールアップを実現することにある。

本発明によれば前記目的は、サーバシステムを、１つの筐体内に１または複数段に搭載
された機能の異なる複数種類のサーバを含む複数台のサーバにより構成されるブレードシ
ステムと、該ブレードシステムを管理する管理サーバとを備え、該管理サーバが、複数の
サーバのそれぞれの機能を変更する手段を備えて構成することにより達成される。

また、前記目的は、サーバシステムを、１つの筐体内に１または複数段に搭載された機
能の異なる複数種類のサーバを含む複数台のサーバにより構成されるブレードシステムと
、該ブレードシステムを管理する管理サーバとを備え、該管理サーバが、搭載された複数
のサーバをグループ化して管理する手段と、複数のサーバの筐体内での配置状態を管理す
る手段と、複数のサーバのそれぞれの機能を変更すると共に、機能を入れ替えることによ
り筐体内でのサーバの配置を変更する配置変更手段とを備え、該配置変更手段が、複数の
サーバの機能毎に、各サーバを筐体内で整列させるように構成することにより達成される
。

さらに、前記目的は、サーバの配置方法を、１つの筐体内に１または複数段に搭載され
る機能の異なる複数種類のサーバを含む複数台のサーバにより構成されるブレードシステ
ムと、該ブレードシステムを管理する管理サーバとを備え、該管理サーバが、搭載された
複数のサーバをグループ化して管理し、複数のサーバの筐体内での配置状態を管理し、複
数のサーバのそれぞれの機能を変更すると共に、機能を入れ替えることにより筐体内での
サーバの配置を変更し、この配置の変更により、複数のサーバの機能毎に、各サーバを筐
体内で整列させるようにすることにより達成される。

続いて、前記目的は、複数の計算機を含む計算機ユニットを複数備え、計算機ユニットに含まれる計算機間のデータ通信速度は、計算機ユニット間のデータ通信速度よりも速く、計算機ユニットは、第１の機能を実行する計算機と第２の機能を実行する計算機とを少なくとも含み、複数の計算機を管理する管理サーバを備えた計算機システムであって、管理サーバが、同一の計算機ユニット内で割り当てる計算機を増やすことが可能な第１の機能を割り当てる計算機を増やす場合に、当該計算機ユニットに空きの計算機があるときに、該空きの計算機に第１の機能を割り当てる手段と、空きの計算機がなく第１の機能を実行する計算機を増やすことができないときに、他の計算機ユニットに割り当て可能な第２の機能が割り当てられている計算機から該計算機ユニットに含まれない他の計算機へ該第２の機能を再配置して、当該再配置元となった計算機に第１の機能を割り当てる手段とを備えることにより達成される。なお、前記目的を達成する本発明は、管理サーバ、ブレード割り当て方法およびブレード割り当てプログラムを含むものである。

本発明によれば、サーバを機能種別毎に、その配列を整理することができるので、保守
の容易性の向上を図ることができる。また、本発明によれば、１つのサーバが故障したこ
とにより搭載された他のサーバの負荷の不均衡が生じた場合に、サーバの機能を自動的に
入れ替えることができるので、保守が行われるまでの間ブレードシステムの処理能力を最
大限に活用することが可能となる。また、本発明によれば、機能を割り当てる計算機間の関係が密結合である（通信速度が高速でないと、処理性能の低下が大きい）場合に、２以上の計算機間の通信速度が速い配置の計算機に機能を割り当てる。また、それができないときには、疎結合の（通信速度が高速でなくとも、処理性能の低下が少ない）機能を他の計算機に再配置するので、スケールアップの自由度を向上し、業務（機能）をＣＰＵブレード（計算機）に割当てることができる。

以下、本発明によるサーバシステム及びサーバの配置方法の実施形態を図面により詳細
に説明する。

≪第１の実施形態≫
図１は本発明の一実施形態によるサーバシステムの構成例を示すブロック図、図２はブ
レードサーバの構成例を示すブロック図である。図１、図２において、１はブレードシス
テム（以下、ブレードと略す）、２は記憶装置、３はブレードサーバ、４はサーバ種別管理テーブル、５はブレードサーバ管理テーブル、６はサーバイメージ記憶装置、７は管理サーバ、８、１１は通信制御部、９はサーバ種別検知部、１０は記憶装置インターフェース部、１３はイメージ配信部、１４はイメージ収集部、１５は自動配信スケジュール部、１７はサーバ負荷検知部、１８はサーバ負荷計算部、２０はＳＡＮコンフィグ部、２１はグループ作成部、２２はＬＥＤ点灯部、２３は起動パラメータ設定部、２４は表示装置である。

本実施形態によるサーバシステムは、図１に示すように、１つの筐体内に設けられる複数のスロットのそれぞれにブレードサーバ（ブレードや、ＣＰＵボード、計算機ともいう）３を収納した複数のブレードサーバにより構成されるブレード１と、複数のブレードサーバ３のそれぞれに接続される記憶装置２と、本実施形態により設けられた管理サーバ７とにより構成されている。ブレード１を構成する複数のブレードサーバ３は、それぞれ独立して動作することが可能なコンピュータであり、それぞれ、ＣＰＵ、メモリ、外部入出力等のサーバとしての基本機能を備え、記憶装置２と接続されて構成されている。また、ブレードサーバ３は、１または複数の基板により構成されていてよく、複数の基板により構成される場合、筐体内の複数のスロットに収納される。各処理部をプログラムで実現する場合には、前記メモリに格納されたプログラムが前記ＣＰＵによって実行される。

１つの筐体に収納される複数台のブレードサーバ３は、機能の異なる複数種類のサーバ
を含んでいる。また、ブレード１は、図示しない負荷分散装置を備えており、機能毎に分
類される同種類ブレードサーバ３が全て均等に負荷分散されるように制御されている。な
お、図１には、ブレード１として、１つの筐体に複数のブレードサーバ３を収納したものとして１つのブレードだけ示しているが、ブレード１は、複数段の棚を持つ筐体の各段に複数設けられていてもよい。ブレードシステムを複数段で構成する場合、１つの段全体で１つのブレード１を構成しても、あるいは、複数段をまとめて１つのブレード１を構成してもよい。さらに、１つの段に含まれる複数のブレードサーバを複数の群に分けて、各群をそれぞれ１つのブレード１として構成してもよい。機能をまとめたり、近接するブレードサーバに割り当てたりすることにより、通信時間を短くし、処理能力を向上することもできる。

管理サーバ７は、ネットワーク等を介してブレード１の全てのブレードサーバ３に接続
されており、ブレード１の全てのブレードサーバ３を管理するものであるが、ブレードサ
ーバ３の１つに構成されていてよい。そして、管理サーバ７は、ブレードサーバ３との通
信を制御する通信制御部１１、ブレードサーバ３にサーバイメージ（モジュールや、プログラムイメージ、システムイメージ、ディスクイメージ、ボリュームイメージともいう）を配信するイメージ配信部１３、ブレードサーバ３からイメージを収集するイメージ収集部１４、本実施形態によりブレードサーバ３のブレード１内での配置の変更等の処理を行う自動配信スケジュール部１５、各ブレードサーバ３の負荷を計算するサーバ負荷計算部１８、記憶装置２がＳＡＮで接続される場合のＳＡＮのコンフィグレーションを設定するＳＡＮコンフィグ部２０、ブレードサーバ３をグループ化するグループ作成部２１、起動パラメータ設定部２３、複数のブレードサーバ３の配置状態を表示する表示装置２４、複数のブレードサーバ３のそれぞれの機能種別を管理するサーバ種別管理テーブル４、複数のブレードサーバ３のブレード内での配置位置等を管理するブレードサーバ管理テーブル５、ブレードサーバ３に配信するサーバイメージを保持するサーバイメージ記憶装置６を備えて構成される。各ブレードサーバは、それぞれに割付けられたサーバイメージに基づいて処理を実行する。

また、ブレードサーバ３は、図２に示すように、管理サーバ７との通信を制御する通信
制御部８、自ブレードサーバの機能種別を検知するサーバ種別検知部９、記憶装置２との
インタフェースである記憶装置インタフェース部１０、自ブレードサーバの負荷状態を検
知するサーバ負荷検知部１１、自ブレードサーバの機能種別に対応する色のＬＥＤ、障害
等の状態を示すＬＥＤを点灯制御するＬＥＤ点灯部２２、図示しない機能種別毎に対応す
る色で発光させられる複数のＬＥＤ及び障害等の状態を示すＬＥＤを備えて構成されてい
る。

前述したように構成される本実施形態において、記憶装置２は、ＤＡＳ(Device Attached Storage）またはＳＡＮ（Storage Area Network）の形態を持ち、ブレードサーバ３の記憶装置インターフェース１０を介して接続される。ＳＡＮで接続される場合、ＨＢＡ（Host Bus Adapter）を介してファイバチャネルスイッチによりＳＡＮのコンフィグレーションが設定されるものとする。

管理サーバ７は、１または複数のブレード１に収納される複数のブレードサーバ３を、
グループ作成部２１で作成したグループに登録することによりブレードサーバ３の管理を
行う。また、管理サーバ７内の自動配信スケジュール部１５は、本実施形態によるブレードサーバ３の配置（デプロイ）、機能種別の変更を行うものであり、この処理の詳細については後述する。なお、デプロイ（deploy）に関する具体的な技術内容については、特許文献１に記載されている。

ブレードサーバ３内のサーバ種別検知部９は、管理サーバ７からの要求により自サーバ
内の通信制御部８、管理サーバ内の通信制御部１１を介して通信を行い、自ブレードサー
バ３にインストールされているモジュール（例えば、ＳＭＴＰサーバやＨＴＴＰサーバを
示す）を検知する。

管理サーバ７内のイメージ配信部１３は、通信制御部１１、ブレードサーバ３内の通信
制御部８を介して対象のブレードサーバ３へサーバイメージ記憶装置６に記憶されている
イメージを配信する。対象のブレードサーバ３は、イメージが配信された後、配信された
イメージの元の状態を復元し、起動パラメータ設定部２３により設定された対象サーバ固
有の情報を読み込みＯＳを起動する。本発明の実施形態において、イメージとはそのサー
バが接続されている記憶装置２のバックアップイメージを指す。管理サーバ７内のイメー
ジ収集部１４は、通信制御部１１、対象ブレードサーバ３の通信制御部８を介して対象の
ブレードサーバ３のイメージを収集し、サーバイメージ記憶装置９に記憶する。

各サーバは、内蔵ディスクを有し、配信されたサーバイメージを前記内蔵ディスクに格納し、再起動のときに、そのサーバイメージからブートを行うことも可能である。ここで、配信とは、サーバイメージ記憶装置９から対象となるサーバイメージを当該ブレードの内蔵ディスクにコピーすることを意味する。また、サーバイメージが配信されると、ブレードサーバに対応付けられてサーバイメージ記憶装置９に格納される。この場合、ブレードサーバから、ＳＡＮブートによりサーバイメージをブートしてもよい。ここで、配信とは、サーバイメージ記憶装置９から対象となるサーバイメージをコピーして当該ブレードに対応付けることを意味する。

前述したイメージ配信部１３、イメージ収集部１４での処理は、対象サーバの作業を一
定時間停止しなければ実行することができない。すなわち、イメージの収集、配信時にお
いて、対象サーバは停止状態になる。ブレードサーバ３内のサーバ負荷検知部１７は、自
ブレードサーバ３の負荷を測定する。ここでいう負荷は、例えば、ＣＰＵ使用率であって、ある一定の時間間隔で測定されたＣＰＵ使用率の平均値である。また、負荷は、要求を処理したレスポンス時間やその平均値を利用してもよい。ここで得られた測定結果は、通信制御部８、管理サーバ７の通信制御部１１を介して管理サーバ７に送られる。

管理サーバ７のサーバ負荷計算部１８は、ブレードサーバ３の機能種別毎にサーバ負荷
検知部１７で得た測定結果を平均する機能と、ある機能種別のサーバに増減がある場合、
その機能種別のサーバが増減したと仮定した場合の負荷の平均を予測計算する機能とを有
する。予測計算の方法は、例えば、機能種別毎の負荷の合計値をサーバの増減を仮定した
ときのその機能種別のサーバ数で割る等の方法であってよい。管理サーバ７内のグループ
作成部２１は、グループとして管理したいブレードサーバのグループを作成し、作成したグループのそれぞれに、グループとして管理したいブレード１あるいはブレードサーバ３を登録する。１つのグループに複数のブレードあるいはブレードサーバを登録することにより、グループとして、ブレードあるいはブレードサーバを管理することができる。

管理サーバ７内のＳＡＮコンフィグ作成部２０は、記憶装置２がブレード１にＳＡＮに
より接続されている場合に、ファイバチャネルスイッチのコンフィグレーションを作成し
、作成したコンフィグレーションをファイバチャネルスイッチに設定する機能を有する。
ブレードサーバ３内のＬＥＤ点灯部２２は、ブレードサーバの起動時に、自ブレードサー
バがどの機能種別に属するかを判断し、その機能種別に対応するＬＥＤを図３に示して後
述する表から判別して点灯させる。管理サーバ７内の起動パラメータ設定部２３は、イメ
ージ配信部１３での処理中にイメージ配信対象サーバにおける固有の情報を参照するが、
その各ブレードサーバ固有の情報を設定する機能を有する。各処理部は、プログラムや、オブジェクト、プロセス、スレッド、ハードウェアでも実現できる。

図３は管理サーバ７のサーバ種別管理テーブル４の構成を示す図であり、次に、これに
ついて説明する。

図３に示すサーバ種別管理テーブル４は、複数のブレードサーバ３のそれぞれの機能種
別を管理するためのものであり、ブレードサーバの番号２０１、その機能種別２０２、Ｌ
ＥＤの対応する点灯色を示すＬＥＤ２０３及び検知モジュール１〜ｎ（２０４、２０５）
により構成される。機能種別２０２は、例えば、ＷＥＢサーバ、メールサーバというよう
にそのサーバの機能を表す。ＬＥＤ２０３は、その機能に対応して点灯させるＬＥＤの色
を表す。検知モジュール２０４、２０５は、例えば、ＳＭＴＰサーバ、ＰＯＰサーバ、Ｈ
ＴＴＰサーバのようにサーバ種別検知部により検知されたモジュールがどの機能に属する
ものかを判断するために用いられる。同じ機能を持つサーバ、例えば、ＷＥＢサーバであ
っても、異なるモジュールを持つ場合もあり、検知モジュール１〜ｎ等として区別されて
登録される。

図４は管理サーバ７のブレードサーバ管理テーブル５の構成を示す図であり、次に、こ
れについて説明する。

図４に示すブレードサーバ管理テーブル５は、複数のブレードサーバ３のブレード内で
の配置位置等を管理するためのものであり、筐体内での収用位置を示すブレードサーバの
番号３０１、ブレード番号３０２、機能種別３０３、そのサーバが稼動中（ａｃｔ）か否
（ｎｏｎ ａｃｔ）かを示す状態３０４、実行可能な機能３０５により構成される。ブレ
ード番号３０２は、グループによって登録された全てのブレードサーバのブレード番号、
ブレードサーバ番号により構成される。機能種別３０３は、ブレード番号に対応するサー
バが持つ種別を表し、図３で説明した２０２に対応する。実行可能な機能３０５には、記
憶装置２がＤＡＳであってブレードサーバに直接接続されている場合に、記憶装置２内に
実行可能に格納されているモジュール名が格納されている。なお、故障と診断されたブレ
ードサーバは、このテーブルに登録されない。

また、図４において番号３０１の順番は、グループ毎に決定し、ブレードの登録された
順番で、そのブレードを格納している筐体に収納されているブレードサーバの順番に等し
いものとする。図４に示すブレードサーバ管理テーブル５の例は、ブレードサーバ３を４
枚備えて構成されるブレードの２つを１つのグループとして登録した場合の例である。こ
の場合に、１つの筐体に２つのブレードが構成されることになるが、システム全体が複数
の筐体で構成される場合、１つの段の筐体に収納される全てのブレードサーバにより１つ
のブレードを構成し、そのブレードの複数を１つのグループとして登録するようにしても
よい。また、機能種別３０３において、ある種別が決定されると、その機能種別のブレー
ドサーバに含まれる機能やアプリケーションは、グループによって一意に決定される。例
えば、図４に示す例において、種別がＷＥＢサーバとなっているブレードサーバは、全て同等の機能及びアプリケーションしか実行しない。

図５は自動配信スケジュール部１５におけるブレードサーバの配置変換の処理動作を説
明するフローチャートであり、次に、これについて説明する。ここで説明する例は、図３
に示される機能がＷＥＢサーバ、メールサーバに限られるものとした場合の例である。こ
の処理は、障害等によりブレードサーバの１つが停止したとき、あるいは、定期的に起動
される。

（１）この処理が開始されると、まず、１つのブレードサーバの停止によりこの処理が開
始されたのか否かを判定し、１つのブレードサーバの停止によりこの処理が開始された場
合、図４に示すテーブル５の停止したサーバを削除して、テーブル５を更新する（ステッ
プ４０１、４０２）。

（２）１つのブレードサーバが停止すると、ブレード１は、図示しない負荷分散装置が、
停止したブレードサーバと同一の機能を持った同種類のブレードサーバに停止したブレー
ドサーバの処理を分散させて実行するように負荷分散させるので、管理サーバ７内のサー
バ負荷計算部１７は、同種類のブレードサーバのサーバ負荷検知部１７からブレードサー
バの負荷状態を収集し、各サーバの平均負荷を測定して、同種類のブレードサーバの負荷
が多くなり過ぎているか否か、すなわち、負荷の状態が許容できる範囲にあるか否かを判
定する（ステップ４０３、４０４）。

（３）ステップ４０４の判定で、停止したブレードサーバと同種のブレードサーバの負荷
が大きく、負荷の状態が許容できる範囲でなかった場合、例えば、ＷＥＢサーバが停止し
た場合で、１つのＷＥＢサーバの停止より、他のＷＥＢサーバの負荷が著しく大きくなっ
た場合、まず、テーブル５内に空きとなっているサーバがあるか否かを判定し、あれば空
きのサーバの１つにＷＥＢサーバ（ここでは、予め取得しておいた初期状態のＷＥＢサー
バとする）のイメージをイメージ配信部１３から配信する。空きがなかった場合、メール
サーバがグループ内にいくつあるかを図４に示すテーブル５から計算し、複数あった場合
、サーバ負荷計算部１８によりメールサーバを１つ減少させた場合のメールサーバの負荷
を予測計算し、ＷＥＢサーバを増加させる方が適当である場合、１つのメールサーバにＷ
ＥＢサーバのイメージ（ここでは予め収集しておいたイメージ）をイメージ配信部１３か
ら配信する。メールサーバが複数ないか、あるいは、ＷＥＢサーバを増加させない方が適
当である場合何もしない（ステップ４０５）。

（４）ステップ４０５のイメージ配信の処理により必要な機能がブレードサーバにリブー
トされると、そのブレードサーバのＬＥＤ点灯部２２は、機能により決められている色を
発光するＬＥＤを点灯させ、テーブル５を更新すると共に、その後の処理でブレードサー
バの配置を変更するために利用する配置変換後の新たなテーブルを、更新したテーブル５
の情報に基づいて作成する（ステップ４０６〜４０８）。

（５）ステップ４０１の判定で、ブレードサーバの停止によりこの処理が開始されたので
はない場合、定期的な起動で、ブレードサーバの並べ替えのための起動であるので、現在
のブレードサーバ管理テーブル５の情報に基づいて、配置変換後の新たなテーブルを作成
する（ステップ４０９）。

（６）ステップ４０４の判定で、負荷の状態が許容できる範囲にあった場合、ステップ４
０２の処理で更新したテーブル５の情報に基づいて、配置変換後の新たなテーブルを作成
する（ステップ４１０）。

（７）ステップ４０８、４０９または４１０の処理で配置変換後の新たなテーブルを作成
した後、ブレードサーバの並べ替えの処理が開始される。この処理が開始されると、まず
、ブレードサーバに接続される記憶装置２がＤＡＳにより接続されているのか、ＳＡＮに
より接続されているのかを判定する（ステップ４１１、４１２）。

（８）ステップ４１１の判定で、ＤＡＳにより接続されている場合、詳細を後述するＤＡ
Ｓの場合の処理を実行し、ＳＡＮにより接続去れている場合、詳細を後述するＳＡＮの場
合の処理を実行して、ブレードサーバの並べ替えの処理を終了する（ステップ４１３、４
１４）。

図６は配置変換後の新たなブレードサーバ管理テーブル５０１の構成例を示す図であり
、ここに示す例は、前述したステップ４０９の処理で、現在のブレードサーバ管理テーブ
ル５の状態が図４に示すようなものであった場合における配置変換後のブレードサーバの
並び順を示すものであり、ＷＥＢサーバ、メールサーバ、空きのサーバが順に筐体に収納
されたものとなる。このように、機能種別毎にブレードサーバを複数まとめて配置するよ
うにすることにより、保守者がブレードサーバの配置位置を把握しやすくなり、保守の容
易性を向上させることができる。なお、配置変換後のブレードサーバの並び順をどのよう
にするかは任意である。また、前述のステップ４０８、４１０で作成される配置変換後の
新たなブレードサーバ管理テーブルが、ステップ４０９で作成されるものと同一となると
は限らないが、以下の説明では、配置変換後の新たなブレードサーバ管理テーブルが図６
に示すようなものとなるとして説明を続ける。

図７は記憶装置２がＤＡＳにより接続された場合のブレードサーバの並べ替えの処理動
作を説明するフローチャート、図８は図７のステップ６０３での空きサーバの位置変換の
処理動作を説明するフローチャート、図９は空きサーバの位置変換の処理動作を行った後
のサーバの配置状態を示す図であり、まず、図７に示すフローを参照して、ブレードサー
バの並べ替えの処理動作を説明する。

（１）まず、図４に示す元のブレードサーバ管理テーブル５とステップ４０９の処理で作
成した配置変換後のブレードサーバ管理テーブル５０１とを比較し、両者が同等か否かに
より配置の変換が必要か否かを判定する。２つのテーブルが同等である場合、変換の必要
ないので処理を終了させる（ステップ６０１）。

（２）ステップ６０１の判定で、２つのテーブルが異なりサーバの配置の変換が必要であ
った場合、次に、ブレードサーバ管理テーブル５に空きのサーバが登録されているか否か
を判定し、空きのサーバがなかった場合、サーバの配置の変換が不可能であるため、ここ
での処理を終了する（ステップ６０２）。

（３）ステップ６０２の判定で、空きのサーバがあった場合、図８により後述する空きサ
ーバの位置の変換を行う。この処理により、図９に８０１として示すテーブルのように空
サーバをテーブルの末尾に配置する。ここでの処理では、図４に示しテーブルに空きサー
バが２つあるので、３番の空きサーバに、８番のＷＥＢサーバを移動させ、４番の空きサ
ーバに、７番のメールサーバを移動させ、その後、７番のサーバと８番のサーバとを空き
にする処理を行って、図９に示すような配置とする（ステップ６０３）。

（４）次に、空きサーバが２以上存在するか否かを判定し、テーブルに空きサーバが２以
上ない場合、すなわち、空きサーバが１つしかない場合、必要に応じて縮退運転をしなけ
ればならないため、各ブレードサーバのサーバ負荷検知部１７から検知された負荷の状態
を収集し、管理サーバ７のサーバ負荷計算部１８により縮退運転時の構成における各ブレ
ードサーバの負荷を予測する。縮退運転とは、例えば、空きのサーバが１つしかない場合
、ＷＥＢサーバ、メールサーバのどちらか一方を停止させて運転を続けることをいい、こ
こではその両方の場合を考慮してサーバ負荷計算部１８により負荷予測を行う。すなわち
、ＷＥＢサーバが１減少する場合とメールサーバが１減少する場合において負荷予測を行
う（ステップ６０５）。

（５）ステップ６０５で予測された負荷の計算値がＷＥＢサーバ、メールサーバのどちら
かでも負荷の基準値を超えるか否かを判定し、基準値を超えていた場合ブレードサーバの
配置変換を中止するか、あるいは、一定時間待ってから処理を再開することとして、ここ
での処理を終了する。一方、負荷の計算値からどちらのサーバを１つ減少させるのがよい
かを計算値より判断し、例えば、ＷＥＢサーバが１減少したほうが負荷の影響が少ない場
合は、メールサーバを空きサーバに配信する。この場合、その配信されたサーバイメージは予め収集しておいたメールサーバの機能を持つものとする（ステップ６０６）。

（６）ステップ６０４の判定で、サーバの空きが２以上あった場合、ＷＥＢサーバ、メー
ルサーバの組をどこかの空きサーバに配信しておく。この場合のイメージも予め収集して
おいたものとする。予備としてこれらの配信により作成されたサーバを運転するがこれら
のサーバの運転中取得されたログなどの固有の情報は破棄される（ステップ６０７）。

（７）次に、ブレードサーバの位置変換を行う。位置変換とは、対応する２つのサーバＡ
、Ｂを決定し、Ａ、Ｂのイメージ収集を同時に行い、Ａ、Ｂともにイメージ収集を終えた
時点でＡのイメージをＢへ、ＢのイメージをＡへ同時に配信することををいう。かりに、
Ｂが空の場合、Ｂのイメージを収集する必要はなく、配信時にはＡに対応するテーブル５
を空に設定し、Ａのサーバは停止させておく。サーバＡ、Ｂは、常にＷＥＢサーバとメー
ルサーバの組になるようにする。説明している例では、ステップ６０３の処理で、図９に
示す状態となっているので、ここでの処理は、２番のメールサーバと５番のＷＥＢサーバ
とを入れ替える処理となり、これにより、図６に示す状態となる。その後、必要なイメー
ジがそれぞれのサーバにリブートされると、各サーバのＬＥＤ点灯部２２により、機能に
対応する色のＬＥＤが点灯させられる（ステップ６０８、６０９）。

（８）次に、他に入れ替えるべきサーバがあれば、ステップ６０８からの処理を繰り返し
、入れ替えるべきサーバがなくなれば、ここでの処理を終了する（ステップ６１０）。

次に、図８に示すフローを参照して、前述したステップ６０３での空きサーバをブレー
ド内の最後の位置に配置する処理について説明する。

（１）まず、図４に示すテーブル５から空きサーバがテーブルの何番にあるかを調べ、そ
の番号を示す図示していないが、空きサーバテーブルＡと呼ぶテーブルを作成する。この
空きサーバテーブルＡには、対応する番号のサーバの機能種別も記憶させる（ステップ７
０１）。

（２）ステップ７０１で作成した空きサーバテーブルＡと図６に示す配置変換後のブレー
ドサーバテーブル５０１とを比較し、空きサーバの位置が同じであるか否かにより配置変
換が必要か否かを判定し、空きサーバの位置が同じで配置変換が不要であればここでの処
理を終了する（ステップ７０２）。

（３）ステップ７０２の判定で、空きサーバの位置が同じでなく、配置変換が必要である
と判定された場合、前述の空きサーバテーブルから位置変換が必要な空きサーバと空きサ
ーバと変換されるサーバ種別を決定する。位置変換が必要なサーバが１ならば対応するサ
ーバの位置が自動的に決定される。位置変換が必要なサーバが２以上の場合、どのサーバ
とどのサーバとを対応させるかについては、例えば、以下のように決定する。テーブル５
０１における種別が空のサーバの番号と現在の種別、すなわち、テーブル５における種別
をテーブルＢに記憶する。次に、前述の空きサーバテーブルＡを番号順に走査し、テーブ
ルＡの種別に対応する種別がテーブルＢにあるかを調べる。対応する種別があれば、その
サーバに決定し、決定したテーブルＢの番号をテーブルＢから削除する。なければ、対応
するサーバを決定せずに空きサーバテーブルＡの次の走査に移り、同様の操作を繰り返す
。テーブルＡの走査を終えると対応するサーバが決定していないテーブルＡのサーバをテ
ーブルＢの残っているサーバの中から適当に決定する。このように対応するサーバを決定
することにより、図７により説明したステップ６０８におけるサーバ変換処理を最小の処
理量に抑えることができる（ステップ７０３）。

（４）次に、ステップ７０３の処理の結果、サーバの位置変換を行う必要があるか否かを
判定して、位置変換がなければテーブル５を更新してここでの処理を終了する（ステップ
７０４、７０５）。

（５）ステップ７０４の判定で、サーバの位置変換があった場合、縮退運用時のサーバの
負荷を、前述ですでに説明していると同様に計算し、縮退運用時の負荷が基準値より大き
いか否かを判定し、負荷が基準値より大きければ処理を終了するか、あるいは、一定時間
待って処理を続けることとする（ステップ７０６、７０７）。

（６）ステップ７０７の判定で、負荷が基準値より小さかった場合、ステップ７０３の処
理によって決定した対応するサーバに対して、イメージの収集、イメージの配信の処理を
行って位置変換を行う。この位置変換の処理では、対象となるサーバが一時的に停止させ
られる。この位置変換により、イメージがサーバにリブートされれば、そのサーバ内のＬ
ＥＤ点灯部２２が、その機能種別に対応する色のＬＥＤを点灯させる（ステップ７０８〜
７１０）。

前述した処理の結果、図４に示した配列のブレードサーバ管理テーブルの状態が、図９
に示すテーブル８０１にように変更されたことになり、同時に、空きサーバが番号の末尾
となるように配置される。

以上、図７、図８に示すフローにより、図５に示すステップ４１３でのＤＡＳの場合の
ブレードサーバの並べ替えについて説明した。前述したＤＡＳの場合の並べ替えは、処理
を迅速に行う必要性からブレード１内に少なくとも２つの空きのブレードサーバが存在す
る場合に、その空きサーバを利用して効率的にサーバの並べ替えを行う例を示して説明し
た。しかし、ブレードサーバの並べ替えは、並べ替えにある程度時間が係ることを許容す
れば、ブレード１内に１つの空きのブレードサーバが存在すれば行うことができる。この
場合のサーバの並べ替えは、例えば、データソートの方法としてよく知られている方法を
応用し、空きのサーバに移動したいサーバの機能を移し、そのサーバを空きにすることに
よるサーバの位置変換を、所望の配置となるまで繰り返し実行するという方法により行う
ことができる。さらに、負荷の軽い機能種別のサーバの１つを停止状態とし、このサーバ
を１つの空きサーバと見て前述したような処理を行えば、ブレード１内に空きのブレード
サーバが存在しない場合にも、サーバの配置替えを行うことができる。

前述したＤＡＳの場合の方法は、記憶装置２が各ブレードサーバに所属していて、その
記憶装置内にそのサーバの機能を特徴付けるモジュールをイメージとして配信しなければ
ならない。このため、いずれにしてもサーバの配置替えに際してサーバの停止を伴うこと
になり、図５に示して説明したフローにおいて、ステップ４０８からの並べ替え開始後の
処理は、サーバシステム全体の処理負荷が低い状態で行うことが望ましく、図５のステッ
プ４０８〜４１０の手段で並べ替え後のテーブルを作成した後は、処理を中断して、ステ
ップ４０８からの並べ替え開始後の処理をサーバシステム全体の処理負荷が低い状態とな
る深夜等の時間帯に行うようにしておくとよい。

図１０は記憶装置２がＳＡＮにより接続された場合のブレードサーバの並べ替えの処理
動作を説明するフローチャートであり、次に、これについて説明する。記憶装置２がＳＡ
Ｎの場合、記憶装置２は、ファイバケーブルによりファイバチャネルスイッチを介して各
ブレードサーバ３に接続されているものとする。

（１）まず、管理サーバ７のＳＡＮコンフィグ部２０は、図５に示すフローのステップ４
０８から４１０のどれかで作成した並べ替え後のテーブル５０１の状態になるようファイ
バチャネルスイッチのコンフィグレーションを作成し、作成した情報を通信制御部８、１
１のを通してファイバチャネルスイッチに設定する（ステップ９０１）。

（２）次に、リブートが必要なサーバの番号を、図には示していないテーブルＣに記憶し
、ステップ９０２からステップ９０６の処理をテーブルＣに記憶したサーバに対して繰り
返すことにより設定情報を各サーバに反映させるため、リブートによりそのサーバが停止
するものと考えて負荷予測計算を、前述で説明した場合と同様にサーバ負荷計算部１８に
より行わせ、負荷が規定値より大きいか否かを判定する（ステップ９０２、９０３）。

（３）ステップ９０３の判定で、負荷が規定値より大きければ、テーブルＣの次のサーバ
に対して同じ処理を実行し、負荷が規定値より大きくなければ、ＯＳの機能を用いてリブ
ートを行う。リブートが完了すれば、ＬＥＤ点灯部２２がリブートされた機能に対応する
色のＬＥＤを点灯させる（ステップ９０４、９０５）。

（４）次に、テーブルＣからリブートが完了したサーバを削除し、テーブルＣにまだサー
バが存在すれば、ステップ９０２からの処理に戻って処理を繰り返し、テーブルＣにサー
バがなくなれば、処理を終了する（ステップ９０６）。

前述ではブレードを構成するブレードサーバが障害等で停止した場合、あるいは、別の
何らかの理由で、ブレードサーバの配置が乱れた場合にブレードサーバの機能を入れ替え
て配置を変更するとして説明したが、本実施形態で設けられた管理サーバは、各ブレードサーバの負荷状態を常時監視して、負荷が基準値より大きくなった場合に、空きのサーバに同一機能のモジュールを配信して、その機能を持つサーバの数を増加させ、あるいは、負荷が基準値より小さくなった場合に、その機能を持つサーバの１つを空き状態にして、その機能を持つサーバの数を減少させて、サーバシステム全体の処理効率を向上させることができ、この場合にも、配置が乱れたブレードサーバの配置を変更することができる。

図１１は複数のブレードサーバ３の配置状態を表示装置２４に表示したモニター画面の
例を示す図である。図１１に示す表示画面１００８において、１００１、１００２はサー
バ種別とそれに対応して点灯するＬＥＤの色を示しており、例えば、１００１がサーバの
機能種別がＷＥＢサーバでＬＥＤの色が緑、１００２がサーバの機能種別がメールサーバ
でＬＥＤの色が赤とする。また、１００３は空でＬＥＤを点灯しない場合とする。そして
、ブレード１を１００９として示しており、ブレード１がＷＥＢサーバ１００４、メール
サーバ１００５で構成され、空１００６があることを示しており、表示画面１００８に表
示される各ブレードサーバ３は、その物理的な位置を示している。ブレードサーバとして
のＷＥＢサーバ１００４、メールサーバ１００５、空１００６は、それぞれ、前述で説明
した色が付けられて表示されている。

図１２は図１１で示す表示画面例に対応する実際の機器におけるＬＥＤの点灯状況を示
す図である。図１２において、１１０１は緑色ＬＥＤ、１１０２は赤色ＬＥＤを示し、１
１０３はブレード１、１１０４はブレードサーバ３を示している。

図１１に示すような表示を行うことにより、保守者は、モニタ画面からブレード１にお
けるブレードサーバ３の配置の状態が一目で判る。また、実際の機器においても、図１２
に示すように、ブレードサーバ毎に機能種別に対応した色のＬＥＤが点灯しているので、
保守者は、一目で各ブレードサーバの機能を知ることができる。

図１３はブレードシステムが複数段で構成されていて複数のブレードをグループとした
場合の複数のブレードサーバ３の配置状態を表示装置２４に表示したモニター画面の例を
示す図である。

図１３に示す表示画面１２０６において、１２０１、１２０２、１２０３はサーバ種別
とそれに対応して点灯するＬＥＤの色を示しており、例えば、１００１がサーバの機能種
別がＷＥＢサーバでＬＥＤの色が緑、１００２がサーバの機能種別がメールサーバでＬＥ
Ｄの色が赤、１２０３がサーバの機能種別がＤＨＣＰサーバでＬＥＤの色が青とする。ま
た、１２０４は空でＬＥＤを点灯しない場合とする。そして、１２０５はブレード１を収
納する筐体を示しており、１２０７はＷＥＢサーバ、１２０８はメールサーバ、１２０９
はＤＨＣＰサーバ、１２１０は空を示しており、表示画面１２０５に表示される各ブレー
ドサーバ３は、その物理的な位置を示している。ブレードサーバとしてのＷＥＢサーバ１
２０７、メールサーバ１２０８、ＤＨＣＰサーバ１２０９、空１２１０は、それぞれ、前
述で説明した色が付けられて表示されている。

図１４は図１３で示す表示画面例に対応する実際の機器におけるＬＥＤの点灯状況を示
す図である。図１４において、１３０２は緑色ＬＥＤ、１３０３は赤色ＬＥＤ、１３０４
は青色ＬＥＤを示し、１１０６はブレード１、１３０５はブレードサーバ３を示している
。また、１３０１は複数のブレード１を収納した筐体である。

図１３に示すような表示を行うことにより、保守者は、モニタ画面から複数のブレード
１の配置、各ブレードにおけるブレードサーバ３の配置の状態を一目で知ることができる
。また、実際の機器においても、図１４に示すように、ブレードサーバ毎に機能種別に対
応した色のＬＥＤが点灯しているので、保守者は、一目で各ブレードサーバの機能を知る
ことができる。

前述で説明したモニタ画面の表示例及び実際の機器におけるＬＥＤの点灯例では、ＷＥ
Ｂサーバを緑、メールサーバを赤、ＤＨＣＰサーバを青に対応付けているものとして説明
したが、サーバの機能種別と、色との対応は任意に設定することができる。また、実際の
機器における色の表示は、色の表示ができるものであればＬＥＤに限らず他の点灯、表示
素子を使用することもできる。また、図１１〜図１４の説明では、ブレードサーバの機能
種別に対して対応する色を割り当てて表示、点灯させるとして説明したが、障害等により
停止状態となったブレードサーバを判り易く表示するために、機能種別とは異なる色でそ
の障害を表示する、あるいは、表示を点滅させる等の手段を設けることができる。

前述した本実施形態における各処理は、処理プログラムとして構成することができ、この処理プログラムは、ＨＤ、ＤＡＴ、ＦＤ、ＭＯ、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することができる。

図１５はブレード１内のブレードサーバの配置を表示画面から手作業により配置変換す
る操作について説明する図である。

図１５において、前述で説明した場合と同様に、１４０１、１４０２はサーバ種別とそ
れに対応して点灯するＬＥＤの色を示しており、例えば、１４０１がサーバの機能種別が
ＷＥＢサーバでＬＥＤの色が緑、１４０２がサーバの機能種別がメールサーバでＬＥＤの
色が赤とする。また、１４０３は空でＬＥＤを点灯しない場合とする。

いま、モニタの表示画面に１４０４として示すようなブレードの配列が表示されている
ものとする。この配列では、ＷＥＢサーバ１４０８、メールサーバ１４０９、空１４１０
が整列されずに配置されている。このような配置を画面操作により手作業で配置を変更す
ることとする。この場合、例えば、１４０６として示すように、６番のＷＥＢサーバをマ
ウスによるドラックアンドドロップにより、２番のメールサーバの位置に移動させる操作
を行う。これにより、表示画面上で、ドラック元のサーバ種別とドラック先のサーバ種別
とが変更され、表示画面上の配列が、１４０５として示すようなものとなる。このような
操作により手作業で配置を決定した後、１４０７として示す「整列実行」の画面上のボタ
ンをマウスでクリックすることにより、管理サーバ７によるブレードサーバの並べ替えの
処理が開始される。

図１６は図１５により説明した「整列実行」の画面上のボタンがクリックされたときに
開始されるブレードサーバの並べ替えの処理動作を説明するフローチャートである。このフローにおいて、ステップ１５０１、１５０２、１５０３での処理は、それぞれ、図５に示すフローにより説明したステップ４１２、４１３、４１４での処理と同一であるので、ここでの説明は省略する。なお、図６に示して説明した配置変換後のテーブルは、図１５での表示画面上での操作が行われたときに設定されるものとする。

一般に、ブレードシステムの管理において、ブレードシステムに搭載されたブレードサ
ーバを保守の目的で抜き差しする作業やそれぞれのサーバに設置されたリセットボタンを
操作する作業が発生するが、現在のブレードシステムでは保守者が対象となるサーバを目
で見て判別する手段に乏しく、誤作業によりシステムに致命的な打撃を与えることも少な
くない。

前述した第１の実施形態によれば、サーバを機能種別毎に分類し、その配列を自動的に整理する機能を提供することができるので、これにより、保守の容易性の向上を図ることができる。また、保守作業が必要となる要因として搭載されたサーバの故障があり、１つのサーバが故障したことにより搭載された他のサーバの負荷の不均衡が生じる可能性があるが、前述した本実施形態によれば、これを回避するため、負荷均衡化を図るためにサーバの機能を自動的に入れ替える機能を提供することができるので、これにより、保守が行われるまでの間ブレードシステムの処理能力を最大限に活用することが可能となる。

≪第２の実施形態≫
次に、本発明の第２の実施形態について説明する。第２の実施形態は、ブレードシステムにおいて、ユニット（ブレードサーバ）内で業務（機能）を拡張しなければならないスケールアップと、ユニット内である必要はなくユニット間であっても業務を拡張することができるスケールアウトとが混在していても、スケールアップを妨げることなく、業務をＣＰＵブレード（計算機）に割り当てることを可能とするものである。なお、スケールアップは、１つの業務を割り当てる複数のＣＰＵブレード間の関係が密結合である（ＣＰＵブレード間のデータ通信が高速である）場合の拡張処理である。また、スケールアウトは、１つの業務を割り当てる複数のＣＰＵブレード間の関係が疎結合である（ＣＰＵブレード間のデータ通信が高速でない）場合の拡張処理である。スケールアップ（scale up）およびスケールアウト（scale out）の具体的な技術内容については、それぞれ特許文献２および特許文献３に記載されている。

（システムの構成と概要）
図１７は、第２の実施形態に係るサーバシステムの構成例を示す図である。サーバシステム１００は、管理サーバ１０１、複数のサーバ１１５およびディスクアレイ装置１１３を含んで構成される。

サーバ１１５は、ＦＣＡ（Fibre Channel Adapter）１１６を介してファイバチャネルスイッチ１１１に接続され、ＮＩＣ（Network Interface Card）１１７を介してネットワークスイッチ１１２に接続されている。また、サーバ１１５は、ＢＭＣ（Baseboard Management Controller）１１８を介して管理サーバ１０１に接続されている。ファイバチャネルスイッチ１１１は、管理サーバ１０１、ディスクアレイ装置１１３およびサーバ１１５に接続されている。これにより、サーバ１１５は、ファイバチャネルスイッチ１１１経由でディスクアレイ装置１１３にアクセスすることができる。ネットワークスイッチ１１２は、管理サーバ１０１、ディスクアレイ装置１１３およびサーバ１１５に接続されている。これにより、管理サーバ１０１は、ネットワークスイッチ１１２経由でディスクアレイ装置１１３およびサーバ１１５の監視や制御を行うことができる。ディスクアレイ装置１１３は、ハードディスク装置１１４やＣＰＵ、メモリ（図示せず）などから構成される。なお、サーバ１１５の構成の詳細は後記する。また、ファイバチャネルスイッチには、一般のスイッチを利用することも可能であり、本実施形態がファイバチャネルスイッチに限定されるものではない。

管理サーバ１０１は、ファイバチャネルスイッチ１１１を介してサーバ１１５およびディスクアレイ装置１１３に接続されている。また、ネットワークスイッチ１１２を介してもサーバ１１５およびディスクアレイ装置１１３に接続されている。さらに、管理サーバ１０１は、ネットワークを介してサーバ１１５に内蔵されたＢＭＣ１１８に接続されている。このＢＭＣ１１８にアクセスすることによって、サーバ１１５のハードウェアの状態監視、電源制御、サーバ１１５のリセットなどを行うことができる。一般に、ＢＭＣ１１８は、サーバ１１５とは別の電源から電力供給されているので、サーバ１１５が電源停止していても、管理サーバ１０１は、ネットワークを介してＢＭＣ１１８を遠隔操作することができる。

管理サーバ１０１は、サーバ１１５、ファイバチャネルスイッチ１１１、ネットワークスイッチ１１２およびディスクアレイ装置１１３に対し、ネットワークを経由して状態の監視や必要に応じた制御を行う。管理サーバ（管理装置、サービスプロセッサともいう）１０１は、ＣＰＵ１２１およびメモリ１２２を含んで構成される。管理サーバ１０１においては、ＣＰＵ１２１がメモリ１２２に格納されている割り当てプログラム１０２を実行することによって、所定の機能が実現される。ここで、所定の機能とは、複数のサーバ１１５上の稼動業務の新規割り当てや拡張（スケールアップ、スケールアウト）を制御することである。

割り当てプログラム１０２は、割り当て・拡張要求受付部１０３、リソース監視部１０４、割り当て最適化部１０５、割り当て実行部１０６および管理テーブル１０７を含んで構成される。割り当て・拡張要求受付部１０３は、管理サーバ１０１の入力手段（図示せず。キーボードやマウスなど）から、システム管理者によるサーバ１１５への稼動業務の新規割り当てまたは拡張の要求を受付ける。リソース監視部１０４は、サーバ１１５における稼動業務のＣＰＵリソース状況を監視する。割り当て最適化部１０５は、割り当て・拡張要求受付部１０３またはリソース監視部１０４からの指示により、サーバ１１５のリソース割り当てを決定する。割り当て実行部１０６は、割り当て最適化部１０５が決定したリソース割り当ての結果を実際の複数のサーバ１１５に反映させる。管理テーブル１０７は、ＳＭＰ構成定義テーブル１０８、ブレード割り当て管理テーブル１０９および稼動業務管理テーブル１１０を含んで構成される。各テーブルの詳細は後記する。

図１８は、本実施形態におけるサーバの構成例を示す図である。サーバ１１５は、メモリ２０１、ＣＰＵ２０２、ＦＣＡ１１６、ＮＩＣ１１７およびＢＭＣ１１８を含んで構成される。メモリ２０１は、プログラムやデータを格納する。ＣＰＵ２０２は、メモリ２０１に格納されたプログラムを実行する。

ＦＣＡ１１６は、通信機構２０３およびＷＷＮ（World Wide Name）格納メモリ２０４を含んで構成される。通信機構２０３は、ファイバチャネルスイッチ１１１に接続され、ファイバチャネル通信を行う。ＷＷＮ格納メモリ２０４は、ＷＷＮを格納する不揮発性メモリである。ＷＷＮとは、ファイバチャネル通信に必要とされるユニークなデバイス識別子であり、ファイバチャネルスイッチ１１１に接続されるノード（サーバ１１５を含む）ごとに付与される。ＷＷＮによってファイバチャネルの通信相手を特定することができる。通信機構２０３は、ＷＷＮ格納メモリ２０４内のＷＷＮを参照しながらファイバチャネル通信を行う。

ＮＩＣ１１７は、通信機構２０５およびネットワークブート機構２０６を含んで構成される。通信機構２０５は、ネットワークスイッチ１１２に接続され、ネットワーク通信を行う。ネットワークブート機構２０６は、サーバ１１５の起動時に動作させることができ、ネットワークを介してサーバ１１５の起動に必要なプログラムを取得する機能を有している。

ＢＭＣ１１８は、主にサーバ１１５のハードウェアの監視や制御を行う。ＢＭＣ１１８は、通信機構２０７およびサーバ監視機構２０８を含んで構成される。通信機構２０７は、サーバ１１５のハードウェアに関する情報の転送や制御コマンドの受付・転送を行う。通信機構２０７は、一般的なネットワーク接続機器によって実現される。サーバ監視機構２０８は、サーバ１１５のハードウェアに発生した異常を検知し、通信機構２０７に通知する。そして、通信機構２０７からネットワーク経由で管理サーバ１０１に異常を通知する。また、遠隔（管理サーバ１０１を含む）から通信機構２０７を介して、サーバ１１５の電源ＯＮ／ＯＦＦやハードウェアリセットを行うことができる。そのため、ＢＭＣ１１８は、一般にサーバ１１５の電源とは別系統の電源から電力供給されており、サーバ１１５の電源がＯＦＦの状態であっても、通信機構２０７を介して遠隔制御を行うことができる。

（サーバ（ＣＰＵブレード）の接続形態）
図１９は、本実施形態におけるサーバの接続形態例を示す図である。サーバシャーシは、複数のＣＰＵブレード（計算機、ブレード）により１つの論理計算機を構成するブレードサーバ（計算機ユニット）に対応する。１つのＣＰＵブレードは、図１７に示す１台のサーバ１１５に対応する。サーバシャーシには、複数のＣＰＵブレードを収めることができる。本実施形態では、１つのサーバシャーシに８枚のＣＰＵブレードを収納できることとする。また、サーバシャーシは複数台あってもよく、その複数台のサーバシャーシ（ブレードサーバ）をブレードシステムという。図１７に示す管理サーバ１０１は、複数台のサーバシャーシと、それぞれに収められた複数枚のＣＰＵブレードとを管理することができる。

図２０は、ＣＰＵブレードのスケールアウトを示す図である。サーバシャーシ内の左端にあるＣＰＵブレードＰ上の業務をスケールアウトする場合には、ＣＰＵブレードが隣り合っている必要はなく、例えば、ＣＰＵブレードＱへスケールアウトしてもよい。また、異なるユニット（詳細は後記）や別のサーバシャーシ内のＣＰＵブレードＲへのスケールアウトを行ってもよい。すなわち、スケールアウトは、サーバシャーシ内やサーバシャーシ間にかかわらず、空いているＣＰＵブレードへ行うことが可能である。

図２１は、ＣＰＵブレードのスケールアップを示す図である。ＣＰＵブレードをＳＭＰ（２台以上のＣＰＵによる対称型）構成として、そのＳＭＰ構成による稼動業務をスケールアップすることができる。例えば、ＣＰＵブレード２枚によるＳＭＰ構成を、ＣＰＵブレード４枚によるＳＭＰ構成にスケールアップして、所定の業務処理を行う性能を向上させることができる。ＳＭＰ構成は共有メモリを有することが多いが、本実施形態は、複数のＣＰＵ（計算機やブレード）で１つの論理計算機を構成可能なシステム構成であれば実施可能であり、ＳＭＰ構成に限定されるものではない。

図２２は、ＣＰＵブレードのスケールアップの制約を示す図である。スケールアップの制約としては、まず、サーバシャーシを跨るＳＭＰ構成とすることはできない。例えば、図２２に示すように、ＣＰＵブレードＳおよびＴのＳＭＰ構成があった場合に、別のサーバシャーシに収納されたＣＰＵブレードＵを含めたＳＭＰ構成にスケールアップすることはできない。また、スケールアップする対象のＣＰＵブレードに対して、隣接するスロットにＣＰＵブレードが挿入されておらず、ＣＰＵブレードの配置が不連続になる場合には、ＳＭＰ構成とすることはできない。例えば、図２２に示すように、ＣＰＵブレードＹおよびＺのＳＭＰ構成があった場合に、すぐ左隣のスロットを空けてさらに左隣のＣＰＵブレードＸを含めたＳＭＰ構成にスケールアップすることはできない。以上を換言すれば、スケールアップは、１つのサーバシャーシやユニット内においてＣＰＵブレードが連続したスロットに配置されている場合に行うことができる。

これらの制約は、ＣＰＵブレードのＳＭＰ構成においては、ＣＰＵブレード間を密結合にする必要があることによる。すなわち、密結合するためには、ＣＰＵブレード間を接続するバスを高性能に（特に通信性能を高く）することが望ましい（ＣＰＵブレード間のアクセス速度が高速な配置にする必要がある）が、高性能なバスほど接続距離は短くなる。これにより、ＣＰＵブレード間の距離を短くする必要があり、サーバシャーシ内の不連続な配置やサーバシャーシ間跨りによるＳＭＰ構成は不可になる。

図２３は、本実施形態において用いる用語の定義を示す図である。ＳＭＰ構成を組むことのできる最大ＣＰＵブレード数を「ユニット化係数」とする。例えば、最大ＳＭＰ構成数がＣＰＵブレード４枚である場合には、ユニット化係数は４となる。図２３に示すように、本実施形態では、ユニット化係数を４としている。この場合、ユニット１と、ユニット２とは、１つのサーバシャーシ上に構成されてはいるが、それらの間の接続はなされていない。なお、ユニット化係数が４であるユニット１やユニット２を別々のサーバシャーシ上にそれぞれ構成するようにしてもよい。

（テーブルの構成）
図２４は、図１７のＳＭＰ構成定義テーブル１０８の詳細を示す図である。ＳＭＰ構成定義テーブル１０８には、ＳＭＰ構成規則が定義されている。ＳＭＰ構成規則は、システム管理者があらかじめ作成する。ＳＭＰ構成定義テーブル１０８の組み合わせ＃１０８１には、許容する組み合わせの通し番号が格納される。ＣＰＵスロット＃１０８２には、ＳＭＰ構成を記載する。例えば、ＣＰＵブレード１枚が２ｗａｙＣＰＵである場合、１ユニット内にＣＰＵブレード１枚の２ｗａｙ・ＳＭＰ構成のサーバを４組作ることができる。また、ＣＰＵブレード２枚の４ｗａｙ・ＳＭＰ構成のサーバであれば２組作ることができる。さらに、最大ＣＰＵブレード４枚のＳＭＰ構成としているため、８ｗａｙ・ＳＭＰ構成のサーバであれば１ユニット内に１つ作ることができる。これによれば、組み合わせ＃１０８１が小さいほど、高性能であると言える。ただし、１ユニット内のスロットにＣＰＵブレードがすべて挿入されているという前提がある。また、図２４に示す「空き」の状態とは、ＣＰＵブレードが挿入されていない状態ではなく、当該スロットのＣＰＵブレードはＳＭＰ構成として使用しないということを表している。

なお、図２４では、組み合わせ＃２、４〜７に示すように、ＣＰＵスロット＃１から昇順に連続して使用するようになっているが、ＣＰＵスロット＃４から降順に連続して使用するようにしてもよい。また、スロットが連続するように選択すればよいので、例えば、ＣＰＵスロット＃２、３によるＳＭＰ構成を採ることも可能である。

図２５は、図１７のブレード割り当て管理テーブル１０９の詳細を示す図である。ブレード割り当て管理テーブル１０９は、ユニットの数だけ作成され、ユニットごとのＣＰＵブレードの割り当て使用状況を保持する。ブレード割り当て管理テーブル１０９は、ブレード番号１０９１および割り当て業務ＩＤ１０９２を含むレコードから構成される。ブレード番号１０９１は、ＣＰＵブレードの番号がインデックスとして格納される。ブレード番号１０９１は、ＳＭＰ構成定義テーブル１０８のＣＰＵスロット＃１０８２に対応する。割り当て業務ＩＤ１０９２は、ブレード番号１０９１のＣＰＵブレードに割り当てられた業務ＩＤが格納される。業務ＩＤについては、図２６により説明する。

図２６は、図１７における稼動業務管理テーブル１１０の詳細を示す図である。稼動業務管理テーブル１１０は、ＣＰＵブレード上で稼動させる業務と、その管理情報を管理する。稼動業務管理テーブル１１０は、業務ＩＤ１１０１、業務名称１１０２、業務特性１１０３および拡張タイプ１１０４を含むレコードから構成される。業務ＩＤ１１０１は、稼動業務管理テーブル１１０に登録する稼動業務（業務名称）のインデックスを固有の番号として付与したものである。業務名称１１０２は、稼動業務の名称であり、ＤＢアプリケーションやＷｅｂアプリケーションなどの一般的な種別から具体的なアプリケーションの名前までが設定される。業務特性１１０３には、ブレード自動割り当て実行時に業務を停止し、ＣＰＵブレードをリブート可能または不可のいずれかが設定される。拡張タイプ１１０４には、業務の拡張タイプがスケールアップまたはスケールアウトのいずれかが設定される。

図２７は、割り当て要求情報の詳細を示す図である。割り当て要求情報２７１は、システム管理者が新規に業務を稼動させる場合にＣＰＵリソースの割り当てに必要となる情報である。割り当て要求情報２７１は、システム管理者が管理サーバ１０１（図１７参照）の入力手段（図示せず。キーボードやマウスなど）を操作することによって、割り当て・拡張要求受付部１０３に入力される。割り当て要求情報２７１に従ってＣＰＵリソースの割り当てが決定される。割り当て要求情報２７１は、業務名称２７２、業務特性２７３、拡張タイプ２７４および性能要件２７５を含むレコードならびにブレード割り当て自動実行フラグ２７６から構成される。業務名称２７２は、図２６の業務名称１１０２と同義である。業務特性２７３は、図２６の業務特性１１０３と同義である。拡張タイプ２７４は、図２６の拡張タイプ１１０４と同義である。性能要件２７５は、ＣＰＵが何ｗａｙ必要かを示すものである。ブレード割り当て自動実行フラグ２７６は、ＣＰＵブレードの割り当てをシステム管理者の承認なしに実行してよいか否かを示すフラグである。

図２８は、拡張要求情報／性能低下検出情報を示す図である。拡張要求情報／性能低下検出情報２８１は、割り当て・拡張要求受付部１０３がシステム管理者から入力手段を介して既存業務にＣＰＵリソースを拡張する要求を受けた場合、リソース監視部１０４が稼動業務のＣＰＵリソースの不足を検出した場合などに作成される情報である。拡張要求情報／性能低下検出情報２８１は、拡張対象業務ＩＤ２８２を含むレコードから構成される。拡張対象業務ＩＤ２８２は、ＣＰＵブレードの割り当ての拡張を必要とする業務ＩＤであり、稼動業務管理テーブル１１０（図２６参照）の業務ＩＤ１１０１に対応する。従って、拡張対象業務ＩＤ２８２をキーとして稼動業務管理テーブル１１０を検索することによって、拡張の対象となる業務名称などの情報を参照することができる。ここでは、性能要件は、デフォルトとして２ｗａｙ（ＣＰＵブレード１枚）であるものとするが、システム管理者によって、または、リソース監視部１０４が検出したＣＰＵリソースの不足状況に応じて性能要件を変更するようにしてもよい。

割り当て・拡張要求受付部１０３が拡張対象業務ＩＤ２８２を取得するには、例えば、次の手順による。すなわち、既に割り当てられている業務名称を管理サーバ１０１の表示手段（図示せず。ディスプレイなど）に表示する。次に、その表示された業務名称の中から、システム管理者が拡張要求の対象として選択した業務名称により、稼動業務管理テーブル１１０の業務名称１１０２を検索する。そして、その検索により一致した業務名称１１０２の業務ＩＤ１１０１を拡張対象業務ＩＤ２８２とする。

（システムの処理）
図２９は、管理サーバ１０１の割り当てプログラム１０２の処理フローを示す図である。まず、割り当てプログラム１０２の割り当て・拡張要求受付部１０３が、システム管理者からの新規割り当て要求・拡張要求を受付ける（ステップ２９０１）。この場合、リソース監視部１０４が性能低下を検出することもある。すなわち、以下説明するＣＰＵブレードの割り当て処理は、割り当て・拡張要求受付部１０３またはリソース監視部１０４によってトリガを与えられる。次に、割り当て最適化部１０５が、割り当て・拡張要求受付部１０３またはリソース監視部１０４から必要な情報を入力し、ＣＰＵブレードの割り当て位置を最適化し、決定する（ステップ２９０２）。そして、割り当てプログラム１０２が、ステップ２９０２の結果に従ってＣＰＵブレードの割り当てが可能であるか否か（割り当て結果を実際にハードウェアに反映できるか否か）を判定する（ステップ２９０３）。割り当てが可能であれば（ステップ２９０３のＹｅｓ）、割り当て実行部１０６がＣＰＵブレードの割り当てを実行する（ステップ２９０４）。割り当てが可能でなければ（ステップ２９０３のＮｏ）、割り当てを行わずに処理を終了する。

図３０は、図２９で示した割り当て最適化（ステップ２９０２）の詳細な処理フローを示す図である。まず、管理サーバ１０１の割り当て最適化部１０５は、稼動業務管理テーブル１１０およびブレード割り当て管理テーブル１０９を入力する（ステップ３００１）。次に、割り当て・拡張要求受付部１０３またはリソース監視部１０４からの入力情報が、新規割り当て要求であるか、拡張要求／性能低下検出であるかを判定する（ステップ３００２）。

新規割り当て要求であれば、割り当て最適化部１０５は、割り当て要求情報２７１（図２７参照）を拡張タイプ２７４でソートする（ステップ３００３）。これによって、割り当て要求情報２７１のレコードをスケールアップおよびスケールアウトにグループ分けすることができる。なお、優先順位の規則は、スケールアップ＞スケールアウトである。さらに、割り当て要求情報２７１をスケールアップおよびスケールアウトのグループごとに性能要件２７５でソートする（ステップ３００４）。これによって、それぞれのグループごとに、割り当て要求情報２７１のレコードを性能要件２７５の厳しい（ｗａｙ数が大きい）順番に並べ替えることができる。すなわち、優先順位の規則は、８ｗａｙ＞６ｗａｙ＞４ｗａｙ＞２ｗａｙである。以上によって、割り当て要求情報２７１の各レコードを割り当て処理の優先順位に並べることができる。

図３１は、図２７の割り当て要求情報２７１を優先順位付けした後の割り当て要求情報を示す図である。図３１に示すように、４個のレコードが、スケールアップおよびスケールアウトに分類され、さらにスケールアップの中で性能要件の厳しい順番に並んでいる。なお、業務ＩＤ３１２は、ソートによる優先順位付けを行った後に付与され、以下の処理では割り当て要求業務ＩＤとして用いられるものとする。

図３０に戻って、優先順位に従って、業務ごとに割り当て位置の決定を行う。まず、割り当て要求業務ＩＤとして、変数ｎを１に初期化する（ステップ３００５）。そして、その業務ＩＤ（ｎ）が要求業務総数を超えるまで（ステップ３００６）、業務ＩＤ（ｎ）を＋１ずつ更新（インクリメント）しながら（ステップ３００８）、割り当て位置の決定を行う（ステップ３００７）。割り当て位置決定の詳細は、後記する。

ステップ３００２の判定結果が拡張要求／性能低下検出であれば、割り当て最適化部１０５は、拡張要求情報／性能低下検出情報２８１（図２８参照）を拡張タイプ１１０４（図２６参照）でソートする（ステップ３００９）。ここで、拡張対象業務ＩＤ２８２は、既存の業務ＩＤを示すものであり、業務ＩＤ１１０１（図２６参照）に対応するので、稼動業務管理テーブル１１０の当該レコードを参照することによって拡張タイプ１１０４を特定することができる。さらに、拡張要求情報／性能低下検出情報２８１をスケールアップおよびスケールアウトのグループごとに性能要件でソートする（ステップ３０１０）。この場合の性能要件は、デフォルトとして２ｗａｙであるが、システム管理者やリソース監視部１０４によって他の値が設定された場合には、ステップ３０１０が有効になる。以上によって、拡張要求情報／性能低下検出情報２８１の各レコードを割り当て処理の優先順位に並べることができる。なお、各レコードの優先順位に対応して拡張要求業務ＩＤが付与され、以下の処理で用いられるものとする。

次に、優先順位に従って、業務ごとに拡張の処理を行う。まず、拡張要求業務ＩＤとして、変数ｎを１に初期化する（ステップ３０１１）。そして、その業務ＩＤ（ｎ）が要求業務総数を超えるまで（ステップ３０１２）、業務ＩＤ（ｎ）を＋１ずつ更新しながら（ステップ３０１４）、拡張の処理を行う（ステップ３０１３）。拡張の処理の詳細は、後記する。

図３２は、図３０の割り当て位置決定（ステップ３００７）の処理フローを示す図である。割り当て最適化部１０５は、割り当て要求情報２７１の拡張タイプ２７４を参照し（ステップ３２０１）、それに応じてスケールアップの割り当て位置決定（ステップ３２０２）またはスケールアウトの割り当て位置決定（ステップ３２０６）のいずれかを実行する。スケールアップの割り当て位置決定が解決できなかった場合（ステップ３２０３のＮｏ）、当該ユニット内における他のＣＰＵブレードに割り当てられている業務を別のユニットに割り当てるべく業務再配置を行い（ステップ３２０４）、割り当て位置決定を再実行する（ステップ３２０５）。ただし、再実行回数（例えば、１回）を決めておき、割り当て位置決定の処理が無限ループにならないようにする。解決できた場合には（ステップ３２０３のＹｅｓ）、そのまま処理を終了する。

スケールアウトの割り当て位置決定が解決できなかった場合（ステップ３２０７のＮｏ）は、空きのＣＰＵブレードがないことを意味する。そこで、割り当て最適化部１０５は、システム管理者にその旨を通知する（ステップ３２０８）。具体的には、管理サーバ１０１の表示手段（図示せず。ディスプレイなど）や音声出力手段（図示せず。スピーカなど）によって、システム管理者に知らせる（以下、システム管理者への通知について同様）。解決できた場合には（ステップ３２０７のＹｅｓ）、そのまま処理を終了する。

図３３は、図３２に示すスケールアップの割り当て位置決定（ステップ３２０２）の詳細な処理フローを示す図である。スケールアップする業務は、最も左端（一端）のＣＰＵスロットが空いているユニットを探して割り当てるようにする。これは、ＳＭＰ構成にはユニット内の連続配置という制約があるため、将来拡張可能な分をできる限り多く確保するためである。

まず、割り当て最適化部１０５は、ＳＭＰ構成定義テーブル１０８（図２４参照）を入力する（ステップ３３０１）。次に、割り当て要求業務の性能要件を取得し（ステップ３３０２）、必要なＣＰＵブレード数を必要数として保持する。また、ステップ３３０４ないし３３１４の処理を行うための初期設定処理として、割り当て済み判定フラグｆをＦＡＬＳＥ（偽）とし、割り当て可能スロット位置ｓを１とする（ステップ３３０３）。そして、「ｆ＝ＴＲＵＥ（正）」または「ｓ＋必要数−１＞ユニット化係数」の条件が満たされるまで、ステップ３３０５ないし３３１３の処理（スロット位置ごとの処理）を繰り返す（ステップ３３０４ないし３３１４）。換言すると、ステップ３３０４の条件が満たされれば、割り当て位置決定の処理を終了する。なお、その条件のうち、前者は、ＣＰＵブレードの割り当てができたことを意味する。後者は、すべてのスロット位置に関して割り当て可能か否かのチェックが完了したことを意味する。

スロット位置ごとの処理として、割り当て最適化部１０５は、最初にユニット数カウンタｕを１とする（ステップ３３０５）。これは、ステップ３３０６ないし３３１２の処理を行うための初期設定処理である。そして、「ｆ＝ＴＲＵＥ」または「ｕ＞全ユニット数」の条件が満たされるまで、ステップ３３０７ないし３３１１の処理（所定のスロット位置に関するユニットごとの処理）を繰り返す（ステップ３３０６ないし３３１２）。換言すると、ステップ３３０６の条件が満たされれば、所定のスロット位置に関するユニットごとの処理を終了する。なお、その条件のうち、前者は、ＣＰＵブレードの割り当てができたことを意味する。後者は、所定のスロット位置に関して、すべてのユニットについて割り当て可能か否かのチェックが完了したことを意味する。

所定のスロット位置に関するユニットごとの処理として、割り当て最適化部１０５は、まず、ブレード割り当て管理テーブル１０９を参照して、ユニット（番号＝ｕ）のスロット（位置＝ｓ〜ｓ＋必要数−１）に業務ＩＤが設定済であるか否かをチェックする（ステップ３３０７）。例えば、ｓ＝１、必要数＝３であれば、スロット位置に対応するブレード番号１０９１（図２５参照）の１〜３（＝１＋３−１）のチェックを行う。設定済でなければ（ステップ３３０７のＮｏ）、稼動業務管理テーブル１１０に割り当て要求業務ＩＤを仮設定する（ステップ３３０８）。また、ブレード割り当て管理テーブル１０９のユニット（番号＝ｕ）のスロット（位置＝ｓ〜ｓ＋必要数−１）に割り当て要求業務ＩＤを仮設定する（ステップ３３０９）。具体的には、そのスロット位置に対応するブレード番号１０９１の割り当て業務ＩＤ１０９２に仮設定する。このとき、図３０のステップ３００１で入力したＳＭＰ構成定義テーブル１０８を参照して、仮設定されたＳＭＰ構成が規則に沿っているか否かを確認する。そして、割り当て済み判定フラグｆをＴＲＵＥにする（ステップ３３１０）。

ここで、「仮設定」としたのは、システム管理者の意向によっては、実際に業務の割り当てを行わないことがあるからである。その最終的な決定は、図２９の割り当て実行（ステップ２９０４）に委ねられる。

ステップ３３０７で設定済であれば（ステップ３３０７のＹｅｓ）、ユニット数カウンタｕを＋１更新して（ステップ３３１１）、次のユニットについて割り当て可能か否かのチェックを行う（ステップ３３０７）。このようにして、所定のスロット位置に関するユニットごとの処理が行われる。全ユニットについてチェックを行っても割り当てができなかった場合には、次にチェックするスロット位置を設定するためにｓを＋１更新して（ステップ３３１３）、そのスロット位置に関する処理を開始する（ステップ３３０５）。このようにして、スロット位置ごとの処理が行われる。

なお、業務ＩＤの割り当てが行われた場合には（ステップ３３０８ないし３３１０）、ｆ＝ＴＲＵＥとなってステップ３３０６の条件を満たすので、ステップ３３０６ないし３３１２の処理から抜けることになる。さらに、ステップ３３０４の条件も満たすので、ステップ３３０４ないし３３１４の処理から抜けることになり、割り当て位置決定の処理が終了する。また、すべての割り当て可能なスロット位置に関してチェックを行っても割り当てができなかった場合には、ステップ３３０４の後者の条件を満たすので、割り当て済み判定フラグｆ＝ＦＡＬＳＥの状態で、割り当て位置決定の処理が終了する。

以上説明したように、スケールアップの割り当て位置決定の処理は、最も左端のＣＰＵスロットが空いているユニットを探して割り当てるように行われる。例えば、図３４に示すような割り当て状態の場合は、ユニット２のスロット３・４に業務Ａを割り当てる。

図３５は、図３２に示すスケールアウトの割り当て位置決定（ステップ３２０６）の詳細な処理フローを示す図である。スケールアウトする業務は、できる限り右端（他端）のＣＰＵスロットが空いているユニットに１つずつ配置するようにする。これは、ユニット内における左端からのスケールアップをなるべく阻害しない位置に、スケールアウトによる配置を行うためである。

まず、割り当て最適化部１０５は、ステップ３５０５ないし３５１３の処理を行うための初期設定処理として、未割り当てスロット数ｎを、要求業務の性能要件から求められるＣＰＵブレードの数（例えば、性能要件が２ｗａｙならば、ｎ＝１）とし、割り当て可能スロット位置ｓをユニット化係数とする（ステップ３５０１）。また、ユニットの参照順を変更する（ステップ３５０２）。この変更では、ステップ３５０５ないし３５１１の処理において、ユニット番号の順ではなく、連続した空きのスロット数が多い順にユニットを参照するように参照の順番を設定する。これは、ユニット内のスケールアップをなるべく阻害しないようにするためである。

そして、「ｎ＜１」または「ｓ＜１」の条件が満たされるまで、ステップ３５０４ないし３５１２の処理（スロット位置ごとの処理）を繰り返す（ステップ３５０３ないし３５１３）。換言すると、ステップ３５０３の条件が満たされれば、割り当て位置決定の処理を終了する。なお、その条件のうち、前者は、必要な数のＣＰＵブレードが割当てられたことを意味する。後者は、すべてのスロット位置に関して割り当て可能か否かのチェックが完了したことを意味する。

スロット位置ごとの処理として、割り当て最適化部１０５は、最初にユニット数カウンタｕを１とする（ステップ３５０４）。これは、ステップ３５０５ないし３５１１の処理を行うための初期設定処理である。そして、「ｎ＜１」または「ｕ＞全ユニット数」の条件が満たされるまで、ステップ３５０６ないし３５１０の処理（所定のスロット位置に関するユニットごとの処理）を繰り返す（ステップ３５０５ないし３５１１）。換言すると、ステップ３５０５の条件が満たされれば、所定のスロット位置に関するユニットごとの処理を終了する。なお、その条件のうち、前者は、必要な数のＣＰＵブレードが割当てられたことを意味する。後者は、所定のスロット位置に関して、すべてのユニットについて割り当て可能か否かのチェックが完了したことを意味する。

所定のスロット位置に関するユニットごとの処理として、割り当て最適化部１０５は、まず、ブレード割り当て管理テーブル１０９を参照して、参照順番ｕのユニットのスロット（位置＝ｓ）に業務ＩＤが設定済であるか否かをチェックする（ステップ３５０６）。ここで、参照順番とは、ステップ３５０２で設定したユニット参照順を示す番号である。設定済でなければ（ステップ３５０６のＮｏ）、稼動業務管理テーブル１１０に割り当て要求業務ＩＤを仮設定する（ステップ３５０７）。また、ブレード割り当て管理テーブル１０９の参照順番ｕのユニットのスロット（位置＝ｓ）に割り当て要求業務ＩＤを仮設定する（ステップ３５０８）。「仮設定」については、先に説明した通りである。次に、未割り当てスロット数ｎを−１更新（デクリメント）する（ステップ３５０９）。これは、ステップ３５０７および３５０８の処理が行われたので、未割り当てスロット数ｎが１つ減ることを意味する。そして、ユニット数カウンタｕを＋１更新して（ステップ３５１０）、次のユニットについて割り当て可能か否かのチェックを行う（ステップ３５０６）。

なお、業務ＩＤが設定済である場合にも（ステップ３５０６のＹｅｓ）、ユニット数カウンタｕを＋１更新して（ステップ３５１０）、次のユニットについて割り当て可能か否かのチェックを行う（ステップ３５０６）。

ステップ３５０５の条件が満たされた場合には、割当て可能スロット位置ｓを−１更新して（ステップ３５１２）、次のスロット位置に関する処理を開始する（ステップ３５０４）。なお、ステップ３５０５の条件のうち、前者の条件が満たされた場合は、必要な数のＣＰＵブレードが割当てられたということなので、ステップ３５０３の条件も満たすことになり、割り当て位置決定の処理を終了する。また、すべてのスロット位置についてチェックを行っても、ｎ＜１にならなければ、未割り当てスロット数がｎだけ残った状態で処理を終了することになる。

以上説明したように、スケールアウトの割り当て位置決定の処理は、できる限り右端のＣＰＵスロットが空いているユニットを探して割り当てるように行われる。また、なるべく連続した空きスロットが多いユニットを探すように行われる。例えば、図３６に示すような割り当て状態の場合には、ユニット１のスロット４およびユニット４のスロット４に業務Ａを割り当てる。

図３７は、図３５のユニット参照順変更（ステップ３５０２）を説明した図である。スケールアウト業務を割り当てる場合、まずなるべくスケールアップ業務の割り当てられていないユニットから、次に連続した空きのスロット数が多いユニットから参照していくようにする。これは、スケールアップ業務の拡張をなるべく妨げないようにするためである。このようなルールに則って、ユニット３、ユニット４、ユニット１およびユニット２の順番に参照順が入れ替わっている。

図３８は、図３０の拡張（ステップ３０１３）の詳細な処理フローを示す図である。割り当て最適化部１０５は、最初に、図３０の３００１で入力した稼動業務管理テーブル１１０を参照して、拡張要求情報／性能低下検出情報２８１の拡張対象業務ＩＤ２８２（図２８参照）に対応する業務の拡張タイプ１１０４がスケールアップかまたはスケールアウトかを判定する（ステップ３８０１）。スケールアップであれば（ステップ３８０１の「スケールアップ」）、まず、図３０の３００１で入力したブレード割り当て管理テーブル１０９を参照して、当該業務が割り当てられているＣＰＵブレードの拡張方向に隣接するＣＰＵブレードが空いているか否かを判定する（ステップ３８０２）。具体的には、当該業務が割当てられているユニット内において、割り当て済みのＣＰＵブレードのうち、最も右側のＣＰＵブレードの右隣に、拡張に必要な数のＣＰＵブレードが空いているか否かを判定する。空いていれば（ステップ３８０２のＹｅｓ）、そのままステップ３８０４に進む。空いていなければ（ステップ３８０２のＮｏ）、業務再配置を行う（ステップ３８０３）。

続いて、割り当て最適化部１０５は、稼動業務管理テーブル１１０の業務特性１１０３を参照して、当該業務がリブート可能であるか否かを判定する（ステップ３８０４）。リブート可能であれば（ステップ３８０４のＹｅｓ）、ブレード割り当て管理テーブル１０９の設定を行う（ステップ３８０５）。具体的には、ＳＭＰ構成でスケールアップするために、当該業務に割当てられるＣＰＵブレード枚数を拡張するように、ブレード割り当て管理テーブル１０９の割り当て業務ＩＤ１０９２を拡張対象の業務ＩＤにより更新する。このとき、図３０のステップ３００１で入力したＳＭＰ構成定義テーブル１０８を参照して、設定されたＳＭＰ構成が規則に沿っているか否かを確認する。リブート不可であれば（ステップ３８０４のＮｏ）、その旨をシステム管理者に通知する（ステップ３８０６）。図３８は、業務特性がリブート不可の場合に拡張を行わないフローとなっているが、リブートしてよいか否かをシステム管理者に問い合わせて、リブートＯＫならば拡張を行うようにすることもできる。また、リブート不可のため拡張しないことを、システム管理者に明示的に知らせることもできる。

ステップ３８０１で、当該業務の拡張タイプがスケールアウトであれば（ステップ３８０１の「スケールアウト」）、割り当て最適化部１０５は、ブレード割り当て管理テーブル１０９を参照して、必要な数の空きのＣＰＵブレードが存在するか否かを判定する（ステップ３８０７）。空きのＣＰＵブレードが存在すれば（ステップ３８０７のＹｅｓ）、ブレード割り当て管理テーブル１０９の設定を行う（ステップ３８０８）。具体的には、スケールアウト業務の割り当てアルゴリズムに則って拡張するように、ブレード割り当て管理テーブル１０９の割り当て業務ＩＤ１０９２を拡張対象の業務ＩＤにより更新する。空きのＣＰＵブレードが存在しなければ（ステップ３８０７のＮｏ）、業務の拡張ができないので、システム管理者にその旨を通知する（ステップ３８０９）。

図３９は、図３２の業務再配置（ステップ３２０４）および図３８の業務再配置（ステップ３８０３）の詳細な処理フローを示す図である。この業務再配置の処理は、現状の業務割り当てのままでは当該業務のスケールアップができないので、同じユニット内の別のＣＰＵブレードに割当てられている業務を他のユニットに再配置するものである。割り当て最適化部１０５は、まず、スケールアウトする業務の再配置位置を決定する（ステップ３９０１）。具体的には、同じユニット内の右側のＣＰＵブレードから割当てられている業務を他のユニットに再配置するために、ブレード割り当て管理テーブル１０９を参照して、他のユニットに空きのＣＰＵブレードがあるか否かをチェックし、空きのスロット位置を再配置位置として決定する。なお、同じユニット内の最も右端のＣＰＵブレードが空いている場合に、そのスロット位置を再配置位置とすることも可能である。そして、空きのＣＰＵブレードがあったか否か、すなわち、再配置位置の決定が解決したか否かを判定する（ステップ３９０２）。

再配置位置の決定が解決していれば（ステップ３９０２のＹｅｓ）、割り当て最適化部１０５は、システム管理者にその旨を通知する（ステップ３９０３）。そして、システム管理者による再配置の実行要求を受信した場合（ステップ３９０４のＹｅｓ）、再配置を実行する（ステップ３９０５）。具体的には、ブレード割り当て管理テーブル１０９の割り当て業務ＩＤ１０９２を更新して、ＣＰＵブレードに対応するサーバ１１５の設定情報を変更した後、そのサーバ１１５をリブートする。サーバ１１５の設定情報の変更やリブートは、ＢＭＣ１１８に当該要求を発行することによって行う。再配置の実行要求を受信しなかった場合には（ステップ３９０４のＮｏ）、再配置を行わずに処理を終了する。ステップ３９０２で、再配置位置の決定が解決していなければ（ステップ３９０２のＮｏ）、割り当て最適化部１０５は、システム管理者にその旨を通知して（ステップ３９０６）、処理を終了する。

図４０は、図２９の割り当て実行（ステップ２９０４）の詳細な処理フローを示す図である。管理サーバ１０１の割り当て実行部１０６は、まず、システム管理者に割り当て位置決定結果を通知する（ステップ４００１）。次に、新規割り当てであるか否かを判定する（ステップ４００２）。これは、図３０のステップ３００２と同様に判定する。新規割り当てであれば（ステップ４００２のＹｅｓ）、割り当て要求情報２７１（図２７参照）のブレード割り当て自動実行フラグ２７６がＯＮであるか否かを判定する（ステップ４００３）。ＯＮでなければ（ステップ４００３のＮｏ）、システム管理者からの実行要求を受信したか否かをチェックする（ステップ４００４）。実行要求を受信していなれば（ステップ４００４のＮｏ）、実際の割り当てを行わないので、ブレード割り当て管理テーブル１０９および稼動業務管理テーブル１１０の仮設定を元に戻す（ステップ４００６）。新規割り当てでない場合（ステップ４００２のＮｏ）、ブレード割り当て自動実行フラグ２７６がＯＮである場合（ステップ４００３のＹｅｓ）、または、実行要求を受信した場合（ステップ４００４のＹｅｓ）には、ハードウェア構成を変更する（ステップ４００５）。具体的には、業務を割り当てたＣＰＵブレードに対応するサーバ１１５の設定情報を変更した後、そのサーバ１１５をリブートする。サーバ１１５の設定情報の変更やリブートは、ＢＭＣ１１８に当該要求を発行することによって行う。これによって、ブレード割り当て管理テーブル１０９および稼動業務管理テーブル１１０の仮設定または設定が有効になる。

前記した本発明の第２の実施形態によれば、業務をＣＰＵブレードに新規に割り当てたり、拡張したりする場合に、拡張タイプがスケールアップである業務を同じユニット内の左端のＣＰＵブレードから割り当て、拡張タイプがスケールアウトである業務をできる限り右端のＣＰＵスロットが空いているユニットに割り当てるので、スケールアップの業務を拡張するべき空きのＣＰＵブレードをできる限り多く確保することができる。また、スケールアップの業務の新規割り当てや拡張がそのままの状態ではできない場合であっても、それができない要因となっているＣＰＵブレードに割り当てられているスケールアウトの業務を他のユニットのＣＰＵブレードに再配置するので、スケールアップの業務を割り当てる空きのＣＰＵブレードを確保することができる。

以上本発明の第２の実施形態について説明したが、図１７に示す管理サーバ１０１のそれぞれで実行されるプログラム（ブレード割り当てプログラムを含む）をコンピュータによる読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、本発明の第２の実施の形態に係る管理サーバが実現されるものとする。なお、プログラムをインターネットなどのネットワーク経由でコンピュータシステムに提供するようにしてもよい。

≪その他の実施形態≫
以上本発明について好適な実施形態について一例を示したが、本発明は前記実施形態に限定されず、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。例えば、以下のような実施形態が考えられる。
（１）前記第２の実施形態では、スケールアップの例として、２ｗａｙＣＰＵのＣＰＵブレードによるＳＭＰ構成について記載したが、ＣＰＵブレードが１ｗａｙＣＰＵであってもよく、また、ＣＰＵブレード間の関係が密結合であればＳＭＰ構成である必要はない。
（２）前記第２の実施形態では、ユニットにおいて、左端のＣＰＵブレードからスケールアップの業務を割り当て、右端のＣＰＵブレードにスケールアウトの業務を割り当てるように記載したが、左右逆であってもよい。
（３）前記第２の実施形態では、図１７に示すように、管理サーバ１０１がサーバ１１５とは別の筐体として説明したが、ブレードサーバ（同一の筐体）内のサーバ１１５（ＣＰＵブレード）やその他のＣＰＵを管理サーバ１０１として用いてもよい。

本発明の第１の実施形態によるサーバシステムの構成例を示すブロック図である。 ブレードサーバの構成例を示すブロック図である。 管理サーバのサーバ種別管理テーブルの構成を示す図である。 管理サーバのブレードサーバ管理テーブルの構成を示す図である。 自動配信スケジュール部におけるブレードサーバの配置変換の処理動作を説明するフローチャートである。 配置変換後の新たなブレードサーバ管理テーブルの構成例を示す図である。 記憶装置がＤＡＳにより接続された場合のブレードサーバの並べ替えの処理動作を説明するフローチャートである。 図７のステップ６０３での空きサーバの位置変換の処理動作を説明するフローチャートである。 空きサーバの位置変換の処理動作を行った後のサーバの配置状態を示す図である。 記憶装置がＳＡＮにより接続された場合のブレードサーバの並べ替えの処理動作を説明するフローチャートである。 複数のブレードサーバの配置状態を表示装置に表示したモニター画面の例を示す図である。 図１１で示す表示画面例に対応する実際の機器におけるＬＥＤの点灯状況を示す図である。 ブレードシステムが複数段で構成されていて複数のブレードをグループとした場合の複数のブレードサーバ３の配置状態を表示装置２４に表示したモニター画面の例を示す図である。 図１３で示す表示画面例に対応する実際の機器におけるＬＥＤの点灯状況を示す図である。 ブレード内のブレードサーバの配置を表示画面から手作業により配置変換する操作について説明する図である。 図１５により説明した「整列実行」の画面上のボタンがクリックされたときに開始されるブレードサーバの並べ替えの処理動作を説明するフローチャートである。 本発明の第２の実施形態に係るサーバシステムの構成例を示す図である。 サーバの構成例を示す図である。 サーバの接続形態例を示す図である。 ＣＰＵブレードのスケールアウトを示す図である。 ＣＰＵブレードのスケールアップを示す図である。 ＣＰＵブレードのスケールアップの制約を示す図である。 用語の定義を示す図である。 ＳＭＰ構成定義テーブルの詳細を示す図である。 ブレード割り当て管理テーブル１０９の詳細を示す図である。 稼動業務管理テーブルの詳細を示す図である。 割り当て要求情報の詳細を示す図である。 拡張要求情報／性能低下検出情報を示す図である。 管理サーバの割り当てプログラムの処理フローを示す図である。 割り当て最適化の詳細な処理フローを示す図である。 割り当て要求情報を優先順位付けした後の割り当て要求情報を示す図である。 割り当て位置決定の処理フローを示す図である。 スケールアップの割り当て位置決定の詳細な処理フローを示す図である。 ユニットにおけるＣＰＵスロットの割り当て状態を示す図である。 スケールアウトの割り当て位置決定の詳細な処理フローを示す図である。 ユニットにおけるＣＰＵスロットの割り当て状態を示す図である。 ユニット参照順変更を説明した図である。 拡張の詳細な処理フローを示す図である。 業務再配置の詳細な処理フローを示す図である。 割り当て実行の詳細な処理フローを示す図である。

符号の説明

１ ブレードシステム
２ 記憶装置
３ ブレードサーバ
４ サーバ種別管理テーブル
５ ブレードサーバ管理テーブル
６ サーバイメージ記憶装置
７ 管理サーバ
８、１１ 通信制御部
９ サーバ種別検知部
１０ 記憶装置インターフェース部
１３ イメージ配信部
１４ イメージ収集部
１５ 自動配信スケジュール部
１７ サーバ負荷検知部
１８ サーバ負荷計算部
２０ ＳＡＮコンフィグ部
２１ グループ作成部
２２ ＬＥＤ点灯部
２３ 起動パラメータ設定部
２４ 表示装置
１００ サーバシステム（計算機システム）
１０１ 管理サーバ
１０２ 割り当てプログラム（ブレード割り当てプログラム）
１０９ ブレード割り当て管理テーブル（ブレード割り当て情報）
１１５ サーバ（計算機、ブレード）

Claims (2)

1. 複数の計算機を含む計算機ユニットを複数備え、
   前記計算機ユニットに含まれる計算機間のデータ通信速度は、前記計算機ユニット間のデータ通信速度よりも速く、前記計算機ユニットは、第１の機能を実行する計算機と第２の機能を実行する計算機とを少なくとも含み、前記複数の計算機を管理する管理サーバを備えた計算機システムであって、
   前記管理サーバは、
   同一の前記計算機ユニット内で割り当てる計算機を増やすことが可能な第１の機能を割り当てる計算機を増やす場合に、
   当該計算機ユニットに空きの計算機があるときに、該空きの計算機に第１の機能を割り当てる手段と、
   空きの計算機がなく前記第１の機能を実行する計算機を増やすことができないときに、他の計算機ユニットに割り当て可能な第２の機能が割り当てられている計算機から該計算機ユニットに含まれない他の計算機へ該第２の機能を再配置して、当該再配置元となった計算機に第１の機能を割り当てる手段と
   を備えることを特徴とする計算機システム。
2. 計算機ユニットに含まれる計算機間のデータ通信速度は、前記計算機ユニット間のデータ通信速度よりも速く、第１の機能を実行する計算機と第２の機能を実行する計算機とを少なくとも含む複数の計算機を管理する管理サーバであって、
   同一の前記計算機ユニット内で割り当てる計算機を増やすことが可能な第１の機能を割り当てる計算機を増やす場合に、
   当該計算機ユニットに空きの計算機があるときに、該空きの計算機に第１の機能を割り当てる手段と、
   空きの計算機がなく前記第１の機能を実行する計算機を増やすことができないときに、他の計算機ユニットに割り当て可能な第２の機能が割り当てられている計算機から該計算機ユニットに含まれない他の計算機へ該第２の機能を再配置して、当該再配置元となった計算機に第１の機能を割り当てる手段と
   を備えることを特徴とする管理サーバ。

Images