JP2009271834A - ブート制御方法、計算機システム及びブート制御プログラム - Google Patents

Abstract

【課題】管理対象計算機のブート処理を１度で済ませ、管理サーバからの管理対象計算機の管理が不能とならないブート制御方法を提供する。
【解決手段】電源制御手段１５により、管理対象サーバ３（ｓｒｖ−１０）の電源がＯＮされる（＃５）。管理対象サーバ３（ｓｒｖ−１０）は、ＰＯＳＴ処理を行い、ＰＸＥ要求をブート制御手段１６に送る（＃６）。ブート制御手段１６は、ＨＢＡベンダ判別プログラム１９を送付する（＃７）。管理対象サーバ３（ｓｒｖ−１０）では、ＨＢＡベンダに対応するベンダ専用プログラム１１０によりＷＷＮが設定され、ＰＣＩ初期化コードのロードが可能でない場合に、ＰＯＳＴ処理が再起動され、再度ＰＸＥ要求を送付する（＃８）。ブート制御手段１６は、ＮＯＰプログラム１８を送付し（＃９）、管理対象サーバ３（ｓｒｖ−１０）は、ＳＡＮブートによりＯＳを起動する。
【選択図】図２

Description

本発明は、ブート制御方法、計算機システム及びブート制御プログラムに関し、特に、冗長化された計算機システムにおいて、計算機の起動時のブート処理を１度で済ませることができるブート制御方法、計算機システム及びブート制御プログラムに関するものである。

ストレージエリアネットワーク（ＳＡＮ）からのブートを行う計算機システム（ＳＡＮ環境における計算機システム）が知られている。ＳＡＮ環境における計算機システムにおいては、各々のサーバが、ＳＡＮを介してストレージの外部ディスク装置からＯＳ（オペレーティングシステム）等のプログラムを読み込む。これにより、各々のサーバがブートされる。

ＳＡＮ環境における計算機システムでは、ＯＳがインストールされるストレージ内の各論理ユニット（Logical Unit) のデータを保護するために、セキュリティ機能が設けられている。各サーバに搭載されたＦＣ（Fibre Channel ）ポートには、固有のＩＤとなるＷＷＮ（World Wide Name ）が割り当てられている。ＳＡＮからのブートを行う計算機システムにおけるセキュリティ機能は、ＯＳがインストールされた論理ユニットとサーバに搭載されたＦＣポートのＷＷＮとを関連付けておき、特定のＷＷＮを有するＦＣポートからのアクセスのみを許可する仕組みとなっている。

ＳＡＮ環境における計算機システムにおいては、その信頼性を向上するために、種々の構成が採用される。例えば、あるサーバ（現用系計算機）に障害が発生すると、他のサーバ（待機系計算機）が障害のあるサーバの業務を継続して実行するように設計されている。即ち、サーバの冗長化が図られている。

しかし、ＳＡＮからのブートを行う計算機システムの冗長化構成では、現用系計算機のＦＣポートと待機系計算機のＦＣポートとのそれぞれに割り当てられたＷＷＮが異なるため、現用系計算機から待機系計算機に交代する際に、現用系計算機で利用されていたＯＳを含むソフトウェアイメージを、そのまま待機系計算機で利用することができない。そのため、ＳＡＮ管理用のソフトウェアや人手によって、ストレージ側のセキュリティ機能の設定変更をする必要があった。

ＳＡＮからのブートを行う冗長化された計算機システムにおいて、ストレージ側のセキュリティ機能の設定変更を行わずに、現用系計算機と待機系計算機とでＯＳを含むソフトウェアイメージをそのまま利用可能とする技術が考案されている（特許文献１参照）。この技術では、ＳＡＮ環境における計算機システムを管理する管理サーバが、現用系計算機のＦＣポートに割り当てられたＷＷＮの情報を収集し、記録しておく。現用系計算機から待機系計算機に交代する際には、記録された現用系計算機のＦＣポートに割り当てられていたＷＷＮを待機系計算機のＦＣポートに設定することにより、現用系計算機のＯＳを含むソフトウェアイメージを、そのまま待機系計算機で利用できるようにする。
特開２００７−９４６１１号公報

図１５は、ＳＡＮからのブートを行う冗長化された計算機システムによる処理シーケンスを示す。

図１５に示す処理シーケンスは、上記の特許文献１を参考に、ＳＡＮブートについて更に検討を加えたものである。

管理サーバが現用系計算機に電源ＯＮ指示を出すと（Ｐ５１）、現用系計算機では、電源がＯＮされ（Ｐ５２）、ＢＩＯＳによるＰＯＳＴ（Power Of Self Test）が行われる（Ｐ５３）。ＢＩＯＳによるＰＯＳＴは、コンピュータシステムに電源を投入したときや、ハードウェアリセットを行ったときに実行される一連の診断テストである。なお、待機系計算機は、このとき電源ＯＦＦの状態である（Ｐ５４）。

管理サーバはネットワークブート用サーバプログラムを起動し（Ｐ５５）、現用系計算機は管理サーバからのネットワークブートを行う（Ｐ５６）。このときの現用系計算機でのブート優先順は、１）ネットワークブート、２）ＳＡＮブートである。

管理サーバは、ＷＷＮの設定プログラムを現用系計算機に配信し（Ｐ５７）、現用系計算機は、ＷＷＮ等の情報収集や、ネットワークブート／ＳＡＮブートの優先順位の設定変更などを行う（Ｐ５８）。

収集された情報は管理サーバに通知される。管理サーバでは、収集された情報をもとにＷＷＮの管理テーブルを生成する（Ｐ５９）。

現用系計算機は、再ブートし、ＢＩＯＳによるＰＯＳＴを行い（Ｐ５１０）、ＳＡＮブートによってユーザＯＳを起動する（Ｐ５１１）。このときの現用系計算機でのブート優先順は、１）ＳＡＮブート、２）ネットワークブートである。

その後、現用系計算機で障害が発生し（Ｐ５１２）、現用系計算機が停止する（Ｐ５１３）。

管理サーバは、現用系計算機の障害発生を検知すると（Ｐ５１４）、待機系計算機に電源ＯＮ指示を出す（Ｐ５１５）。待機系計算機では、電源がＯＮされ（Ｐ５１６）、ＢＩＯＳによるＰＯＳＴが行われる（Ｐ５１７）。

管理サーバはネットワークブート用サーバプログラムを起動し（Ｐ５１８）、待機系計算機は管理サーバからのネットワークブートを行う（Ｐ５１９）。このときの待機系計算機でのブート優先順は、１）ネットワークブート、２）ＳＡＮブートである。

管理サーバは、ＷＷＮの設定プログラムを待機系計算機に配信し（Ｐ５２０）、待機系計算機は、ＷＷＮ等の情報設定や、ネットワークブート／ＳＡＮブートの優先順位の設定変更などを行う（Ｐ５２１）。

収集された情報は管理サーバに通知される。管理サーバでは、収集された情報をもとにＷＷＮの管理テーブルを更新する（Ｐ５２２）。

待機系計算機は、再ブートし、ＢＩＯＳによるＰＯＳＴを行い（Ｐ５２３）、ＳＡＮブートによってユーザＯＳを起動する（Ｐ５２４）。このときの待機系計算機でのブート優先順は、１）ＳＡＮブート、２）ネットワークブートである。

図１５に示すように、管理対象計算機（ここでは、現用系計算機と待機系計算機）が運用に入るためには、２度のＯＳ起動処理（現用系計算機の場合Ｐ５６とＰ５１１、待機系計算機Ｐ５１９とＰ５２４）が必要となる。

また、図１５に示す技術では、管理対象計算機の終了時（電源ＯＦＦ前）に、ネットワークブートが第１優先となるように、必ずブート優先順を元の順序に戻す必要がある。

しかし、管理対象計算機のソフトウェア障害等の異常終了により、管理対象計算機のブート優先順の設定でネットワークブートを第１優先に戻せずに電源がＯＦＦされた場合には、次回の電源ＯＮ時に、管理対象計算機が管理サーバからネットワークブートして設定プログラムを実行し、ＷＷＮの書換え制御を行うことができなくなる可能性が生じる。

通常、計算機のＨＢＡ（Host Bus Adapter）に設定される新しいＷＷＮ値は、揮発性メモリ（Volatile Memory ）領域に記憶される。工場出荷時に設定されるＷＷＮ値は、世界で一意のＩＤでなければならない。不揮発性メモリ（Non Volatile Memory ）に新しいＷＷＮ値を記憶させると、ＷＷＮ値の重複問題が発生する可能性がある。そのため、新しいＷＷＮ値の記憶には、電源がＯＦＦされたときに工場出荷時のＷＷＮ値が有効になるように、揮発性メモリを用いる。

つまり、図１５に示す技術において、ブート優先順位がネットワークブート第一優先に戻されずに管理対象計算機の電源がＯＦＦされた場合には、ＷＷＮ値が工場出荷値に戻っているため、管理対象計算機はＳＡＮブートもできなくなる。そのため、管理対象計算機は、管理サーバからの管理が不能な状態になってしまう。

このように、図１５に示す技術には、以下に示すような２つの問題がある。
１．管理対象計算機が運用に入るためには、２度のＯＳ起動処理を行う必要があり、起動に時間がかかってしまう。
２．管理対象計算機にソフトウェア障害等が生じた場合に、管理サーバから管理対象計算機を制御できなくなる可能性がある。

本発明は、管理対象計算機のブート処理を１回で済ませることを可能とし、管理サーバからの管理対象計算機の制御が不能とならないことを可能とするブート制御方法を提供することを目的とする。

また、本発明は、管理対象計算機のブート処理を１回で済ませることを可能とし、管理サーバからの管理対象計算機の制御が不能とならないことを可能とする計算機システムを提供することを目的とする。

また、本発明は、管理対象計算機のブート処理を１回で済ませることを可能とし、管理サーバからの管理対象計算機の管理が不能とならないことを可能とするブート制御プログラムを提供することを目的とする。

このブート制御方法は、管理ネットワークを介して、１または複数の管理対象計算機を管理する管理サーバによって行われる。このブート制御方法では、管理サーバが、管理対象計算機からブート要求を受信するステップと、ブート要求を行った管理対象計算機に対して、管理対象計算機が有するポートに固有のＩＤを設定するプログラムを送付するステップとを有する。管理対象計算機は、固有のＩＤを設定するプログラムを実行することにより、固有のＩＤをポートに設定し、所定のブート優先順にしたがってブート処理を行う。

この計算機システムは、１または複数の管理対象計算機と、１または複数の管理対象計算機を管理する管理サーバとが、管理ネットワークを介して接続されたものである。この計算機システムでは、管理サーバが、１または複数の管理対象計算機に対するブート制御を行うブート制御手段を備える。ブート制御手段は、ブート要求を行った管理対象計算機に対して、管理対象計算機が有するポートに固有のＩＤを設定するプログラムを送付する。管理対象計算機は、固有のＩＤを設定するプログラムを実行することにより、固有のＩＤをポートに設定し、所定のブート優先順にしたがってブート処理を行う。

このブート制御プログラムは、管理ネットワークを介して、１または複数の管理対象計算機を管理する管理サーバにおいて実行される。このブート制御プログラムは、コンピュータである管理サーバに、管理対象計算機からブート要求を受信するステップと、ブート要求を行った管理対象計算機に対して、管理対象計算機が有するポートに固有のＩＤを設定するプログラムを送付するステップとを実行させる。管理対象計算機は、固有のＩＤを設定するプログラムを実行することにより、固有のＩＤをポートに設定し、所定のブート優先順にしたがってブート処理を行う。

管理対象計算機のブート優先順位を、所定の順番（例えば、ネットワークブート、ＳＡＮブートの順）で固定することにより、管理対象計算機が管理不能になることがなく、信頼性の高いシステム運用が可能となる。

また、管理対象計算機のブート処理が１度で済むので、現用系計算機の故障による停止から待機系計算機への業務の引継ぎ時間を短縮できる。

図１は、この例のＳＡＮ環境における冗長化された計算機システムの構成の一例を示す図である。

この計算機システムは、管理サーバ１、管理ネットワーク２、複数の管理対象サーバ３、ストレージエリアネットワーク（ＳＡＮ：Storage Area Network）４、ストレージ（ストレージ装置）５を備える。管理サーバ１は、管理ネットワーク２を介して、複数の管理対象サーバ３に接続される。複数の管理対象サーバ３は、ＳＡＮ４を介して、ストレージ５に接続される。

管理サーバ１は、管理対象サーバ３の設定や状態の管理、ブート制御、異常検出、現用系から待機系への交代の制御など、管理対象サーバ３の管理、制御を行う。

管理サーバ１はＮＩＣ（Network Interface Card）１１を備え、複数の管理対象サーバ３は、各々、ＮＩＣ３１を備える。管理ネットワーク２にはネットワークスイッチ２１が配置され、管理サーバ１と複数の管理対象サーバ３とは、図１に示すようにネットワークスイッチ２１を介して接続される。

複数の管理対象サーバ３は、各々、ＨＢＡ（ホストバスアダプタ：Host Bus Adapter）３２を備える。ＳＡＮ４には、ＦＣ（ファイバーチャネル：Fibre Channel ）スイッチ４１が配置され、複数の管理対象サーバ３とストレージ５とは、図１に示すようにＦＣスイッチ４１を介して接続される。管理対象サーバ３は、ＳＡＮブートを行う場合には、ＳＡＮ４を介して、ストレージ５からＯＳ等のプログラム（ソフトウェアイメージ）をブートし、また、ＳＡＮ４を介して、ストレージ５のデータにアクセスする。

ストレージ５は、複数の論理ユニット（ＬＵ：Logical Unit）５１を備える。管理対象サーバ３のＨＢＡ３２のポートには、固有のＩＤであるＷＷＮ値が予め割り当てられている。ストレージ５は、各管理対象サーバ３のＨＢＡ３２のポートに割り当てられたＷＷＮ値と論理ユニット５１の識別番号（ＬＵ：Logical Unit Number ）との対応情報を持っており、ＬＵ５１に対応付けられた特定のＷＷＮを有する管理対象サーバ３のＨＢＡ３２のポートからのアクセスのみを許可する仕組みとなっている。

図２は、この例のＳＡＮ環境における冗長化された計算機システムにおける管理サーバ１及び管理対象サーバ３の構成の一例を示す図である。

この例の管理サーバ１は、サーバ管理手段１２、異常検出手段１３、電源制御手段１５、ブート制御手段１６を備える。サーバ管理手段１２は、サーバ管理テーブル１４を備える。ブート制御手段１６は、ブート制御オブジェクト１７を備える。ブート制御オブジェクト１７は、１個のＮＯＰ（No OPeration）プログラム１８、ＨＢＡベンダ判別プログラム１９、複数のＨＢＡベンダ専用プログラム１１０、サーバ定義ファイル１１１、起動プログラム１１２、業務イメージ１１３を備える。

ＮＯＰプログラム１８、ＨＢＡベンダ判別プログラム１９は、予め用意される。ＨＢＡベンダ専用プログラム１１０は、ＨＢＡベンダの数の分だけ、ＨＢＡベンダ毎に予め用意される。サーバ定義ファイル１１１は、管理対象サーバ３の数の分だけ、管理対象サーバ３毎に作成される。起動プログラム１１２は、コンピュータアーキテクチャ（ＣＰＵのアーキテクチャ）の数の分だけ、コンピュータアーキテクチャ毎に用意される。業務イメージ１１３は、業務の数の分だけ、業務毎に用意される。

サーバ管理手段１２は、各管理対象サーバ３の設定や状態の管理、制御を行い、管理サーバ１全体を制御する。

異常検出手段１３は、管理対象サーバ３で発生した故障などの異常を検出する。

サーバ管理テーブル１４は、各管理対象サーバ３の設定や状態を管理するテーブルである。

図３は、サーバ管理テーブル１４の一例を示す。サーバ管理テーブル１４は、管理対象サーバ３（のサーバ名）毎に、ＭＡＣアドレス、ＩＰアドレス、ブート先、ブートステージ、ブート時間、ブートイメージのファイル名、ＷＷＮ値、状態情報、電源情報、ＢＭＣ（Baseboard Management Controller ）のＩＰアドレス、予備サーバ情報を格納する。

サーバ名は、各管理対象サーバ３を一意に識別する名称である。ＭＡＣアドレスとＩＰアドレスは、それぞれ、当該管理対象サーバ３が備えるＮＩＣ３１のＭＡＣアドレスと、ＮＩＣ３１に割り当てられたＩＰアドレスである。

ブート先は、当該管理対象サーバ３がネットワークブートでブート処理を行うのか（ｎｅｔ）、ＳＡＮブートでブート処理を行うか（ｓａｎ）を示す情報である。ブートステージ情報は、当該管理対象サーバ３のＨＢＡ３２のＷＷＮ値の書換え後に、ＨＢＡ３２に格納された初期化コードにアクセスしてＨＢＡ３２の再初期化ができたか否かの状況を示す情報である。ここでは、ブートステージが２である場合に、ＨＢＡ３２に格納された初期化コードにアクセスしてＨＢＡ３２の再初期化ができなかったため、リセットにより再初期化を行う状況であることを示す。ブート時間は、ブート処理が開始された時間である。ブートイメージのファイル名は、当該管理対象サーバ３がブート処理時に読み込むＯＳを含むソフトウェアイメージのファイル名である。

ＷＷＮ値は、当該管理対象サーバ３のＨＢＡ（即ち、ノード）３２のＷＷＮ値であるＷＷＮＮ値（ＷＷＮＮ）と、当該管理対象サーバ３のＨＢＡ３２が備えるポートのＷＷＮ値であるＷＷＰＮ値（ＷＷＰＮ）とを含む。

状態情報は、当該管理対象サーバ３が正常である（ｏｋ）か、異常である（ｎｇ）かを示す。電源情報は、当該管理対象サーバ３の電源がオンであるか、オフであるかを示す。ＢＭＣのＩＰアドレスは、当該管理対象サーバ３が備えるＢＭＣ３３のＩＰアドレスである。予備サーバ情報は、当該管理対象サーバ３が停止した場合にこれに変わって業務を引き継ぐべきサーバ、即ち待機系計算機（のサーバ名）を示す。

電源制御手段１５は、サーバ管理手段１２の指示により、管理対象サーバ３の電源のＯＮ／ＯＦＦを制御する。

ブート制御手段１６は、管理対象サーバ３のブート処理を制御する。ここでは、ブート制御手段１６の機能をブートサーバとも呼ぶ。ブート制御手段１６は、１度のブート処理で管理対象サーバ３によるストレージ５からのブート又はストレージ５へのデータアクセスを可能にするために、ＨＢＡ３２のＷＷＮ値を書き換えるＨＢＡベンダ専用プログラム１１０を管理対象サーバ３に送付する。また、ブート制御手段１６は、サーバ管理テーブル１４に登録されたＭＡＣアドレスを持つ管理対象サーバ３からのブート要求にのみ応答し、管理対象サーバ３のブート優先順位を変更せずに、ネットワークブートを第一優先順位として固定する。また、ブート制御手段１６は、管理対象サーバ３の状態をサーバ管理テーブル１４のブートステージで管理し、管理対象サーバ３からのブート要求であるＰＸＥ要求に対して、ブートステージに応じて、ＮＯＰプログラム１８を送付するか、ＨＢＡベンダ専用プログラム１１０を送付するかを判断する。

ＮＯＰプログラム１８は、ブートステージが２であるときに、すなわちＨＢＡ３２に格納された初期化コードにアクセスしてＨＢＡ３２の再初期化ができなかったときに、管理対象サーバ３のリセット後の再度のＰＸＥ要求に対して、管理対象サーバ３に送付され、管理対象サーバ３のブートを行うファームウェアである。ここでのＮＯＰは、まったく何もしないという意味ではなく、ＨＢＡ３２のＷＷＮ値の設定を行わないという意味である。

ＨＢＡベンダ判別プログラム１９は、ブートステージが１であるときに、管理対象サーバ３に送付され、ＨＢＡ３２のベンダＩＤとデバイスＩＤとをもとに、ＨＢＡベンダを判別するファームウェアである。このＨＢＡベンダ判別プログラム１９によるＨＢＡベンダの判別結果をもとに、管理対象サーバ３に送付されるＨＢＡベンダ専用プログラム１１０が特定される。

ＨＢＡベンダ専用プログラム１１０は、ブートステージが１であるときに、管理対象サーバ３にＨＢＡ３２へのＷＷＮ値の設定を行い、ＨＢＡ３２に格納された初期化コードにアクセスしてＨＢＡ３２の再初期化ができたときに、管理対象サーバ３のブートを行うファームウェアである。ＨＢＡベンダ専用プログラム１１０は、ＨＢＡ３２への電源供給が停止された場合にはＷＷＮ値が工場出荷値に戻るようにするために、設定するＷＷＮ値をＨＢＡ３２の揮発性メモリに書き込む。また、ＨＢＡベンダ専用プログラム１１０は、ＨＢＡ３２に格納されている初期化コードを再度メモリにロードし、初期化処理を行うことにより、管理対象サーバ３をリブートせずに、設定したＷＷＮ値でＳＡＮ４との接続を確立する。また、ＨＢＡベンダ専用プログラム１１０は、ＨＢＡ３２に格納されている初期化コードを再度メモリにロードすることに失敗した場合に、リセットによって再度ＢＩＯＳのＰＯＳＴ処理を呼び出し、設定したＷＷＮ値を有効にする。このとき、管理サーバ１にブートステージ＝２への更新を通知する。

サーバ定義ファイル１１１は、管理対象サーバ３のブート処理を行うために、サーバ管理テーブル１４に管理された情報から生成される定義データである。

図４は、サーバ定義ファイル１１１の一例を示す。サーバ定義ファイル１１１は、図４（Ａ）に示すように、当該管理対象サーバ３（のサーバ名）毎に、当該管理対象サーバ３のブート先（ネットワークブート／ＳＡＮブート）を示す情報と、当該管理対象サーバ３のブートイメージのファイル名と、当該管理対象サーバ３のＨＢＡ３２のＷＷＮ値（ＷＷＮＮ）、当該管理対象サーバ３のＨＢＡ３２が備えるポートのＷＷＰＮ値（ＷＷＰＮ）とを格納する。

例えば、図４（Ｂ）は、図３に示すサーバ管理テーブル１４が管理するデータから生成された、管理対象サーバ３（サーバ名“ｓｒｖ−１０”）のサーバ定義ファイル１１１と、管理対象サーバ３（サーバ名“ｓｒｖ−２”）のサーバ定義ファイル１１１とを示す。なお、管理対象サーバ３（サーバ名“ｓｒｖ−１０”）のサーバ定義ファイル１１１は、管理対象サーバ３（サーバ名“ｓｒｖ−１”）の予備サーバとして管理対象サーバ３（サーバ名“ｓｒｖ−１０”）が起動されるときのものである。

起動プログラム１１２は、管理対象サーバ３が管理サーバ１からのネットワークブートを行うときに、ＯＳイメージを取得して起動するためのプログラムである。

業務イメージ１１３は、ＯＳを含むソフトウェアイメージであり、管理対象サーバ３が管理サーバ１からのネットワークブートを行うときに、管理サーバ１から管理対象サーバ３に読み込まれる。

この例の管理対象サーバ３は、ＮＩＣ３１、ＨＢＡ３２、ＢＭＣ３３、ファームウェア３４を備える。

ＮＩＣ３１は、管理サーバ１との通信を行うためのインタフェースであり、それぞれ唯一のＭＡＣアドレスが割り当てられている。

ＨＢＡ３２は、ＳＡＮと接続するためのインタフェースであり、工場出荷時に世界で一意に割り当てられたＷＷＮ値であるＦ−ＷＷＮ３２１が、ＲＯＭなどの不揮発性メモリに保持されている。また、ＨＢＡベンダ専用プログラム１１０により設定されるＷＷＮ値であるＶ−ＷＷＮ３２２は、揮発性メモリに書き込まれる。

ＢＭＣ３３は、管理サーバ１への管理対象サーバ３の障害発生の通知や、管理サーバ１による電源操作やリセットなどのリモート操作のサポートなどを行う。

ファームウェア３４は、管理対象サーバ３の一般的なファームウェアであり、管理対象サーバ３起動時のＢＩＯＳのＰＯＳＴ処理などは、このファームウェア３４による処理である。

図５は、固定された管理対象サーバ３のブート優先順を示す。ブート優先情報３５は、管理対象サーバ３のＢＩＯＳが管理する所定のメモリに保持される。管理対象サーバ３のブート優先順は、図５に示す通り、
１．ネットワークブート
２．ＳＡＮブート
３．その他のブート
の順で固定されている。

以下、図２を用いて、現用系の管理対象サーバ３（サーバ名“ｓｒｖ−１”）に障害が発生し、待機系の管理対象サーバ３（サーバ名“ｓｒｖ−１０”）に交代する場合のブート手順を説明する。

現用系の管理対象サーバ３（サーバ名“ｓｒｖ−１”）に故障が発生すると、異常検出手段１３は、故障が発生した管理対象サーバ３のＢＭＣ３３から、トラップを受信する（＃１）。

異常検出手段１３は、故障の発生した管理対象サーバ３の情報（サーバ名“ｓｒｖ−１”、ＩＰアドレス“ｉｐ−１”、故障種別など）を、サーバ管理手段１２に通知する（＃２）。

サーバ管理手段１２は、サーバ管理テーブル１４（図３参照）のサーバ名“ｓｒｖ−１”のレコードを参照し、予備サーバがサーバ名“ｓｒｖ−１０”であることを判別し、サーバ名“ｓｒｖ−１”のＩＰアドレス“ｉｐ−１”、ブート先“ｓａｎ”、ブートイメージ“−”、ＷＷＮの情報（ＷＷＮＮ“ｗｗｎ−１”、ＷＷＰＮ“ｗｗｎ−１１、ｗｗｎ−１２”）を、サーバ名“ｓｒｖ−１０”のレコードにコピーし、サーバ名“ｓｒｖ−１０”のレコードのブートステージを“１”に設定する。サーバ名“ｓｒｖ−１”のレコードのＩＰアドレス、ブート先、ブートイメージ、ＷＷＮの情報を消去し、状態情報を“ｎｇ”にする（＃３）。

サーバ管理手段１２は、サーバ管理テーブル１４のサーバ名“ｓｒｖ−１０”の情報をもとに、管理対象サーバ３（サーバ名“ｓｒｖ−１０”）用のサーバ定義ファイル１１１（図４（Ｂ）参照）を作成する（＃４）。

電源制御手段１５は、管理対象サーバ３（サーバ名“ｓｒｖ−１”）のＢＭＣ３３（ＩＰアドレス“ｉｐ−ｂ１”）に接続し、電源をＯＦＦにする。また、管理対象サーバ３（サーバ名“ｓｒｖ−１０”）のＢＭＣ３３（ＩＰアドレス“ｉｐ−ｂ１０”）に接続し、電源をＯＮにする（＃５）。このとき、サーバ管理テーブル１４のサーバ名“ｓｒｖ−１”のレコードの電源情報を“ｏｆｆ”に更新し、サーバ名“ｓｒｖ−１０”のレコードの電源情報を“ｏｎ”に更新する。

管理対象サーバ３（サーバ名“ｓｒｖ−１０”）は、電源ＯＮの後、ファームウェア３４によりＰＯＳＴ処理を実行し、ＰＸＥ初期化処理を開始し、管理サーバ１のブート制御手段１６（ブートサーバ）に、ＰＸＥ要求（ブート要求）を送付する（＃６）。

ＰＸＥ要求を受信したブート制御手段１６は、サーバ管理テーブル１４のサーバ名“ｓｒｖ−１０”のレコードのブートステージのカラムを参照してブートステージが１であることを確認し、ＨＢＡベンダ判別プログラム１９を送付する。管理対象サーバ３（サーバ名“ｓｒｖ−１０”）のファームウェア３４（システムＢＩＯＳ）は、ＨＢＡベンダ判別プログラム１９を受信し、ＨＢＡベンダ判別プログラム１９は、ファームウェア３４（システムＢＩＯＳ）によって実行される（＃７）。

なお、ＰＸＥ初期化処理でブートサーバからダウンロードされ実行されるプログラム（ファームウェア）には、コードサイズが３２ＫＢ以下でなくてはならないという制約がある。そのため、ここでは、ＨＢＡベンダ判別プログラム１９、ＨＢＡベンダ専用プログラム１１０、ＮＯＰプログラム１８と、３つのプログラム（ファームウェア）に分割して処理を行う。

ＨＢＡ３２のベンダが判別されると、管理サーバ１から対応するＨＢＡベンダ専用プログラム１１０が送付され、管理対象サーバ３（サーバ名“ｓｒｖ−１０”）で実行される。ＰＣＩ初期化コードのロードが可能でない場合には、ＰＯＳＴ処理が再起動され、管理対象サーバ３（サーバ名“ｓｒｖ−１０”）は、管理サーバ１のブート制御手段１６（ブートサーバ）に、再度ＰＸＥ要求を送付する（＃８）。なお、このとき、管理サーバ１には、ブートステージ＝２が通知される。

ブート制御手段１６は、サーバ管理テーブル１４のサーバ名“ｓｒｖ−１０”のレコードのブートステージが１ではなく、ブート時間から１０分経過していない場合には、ＮＯＰプログラム１８を送付する（＃９）。管理対象サーバ３（サーバ名“ｓｒｖ−１０”）のファームウェア３４（システムＢＩＯＳ）は、ＮＯＰプログラム１８を受信し、ＮＯＰプログラム１８がファームウェア３４（システムＢＩＯＳ）によって実行され、ＳＡＮブートによるＯＳの起動が行われる。

以下、図６〜図１２に示すフローチャートを用いて、管理サーバ１が実行する処理、管理対象サーバ３が実行する処理の例を説明する。

図６は、管理対象サーバ３が実行するファームウェア３４によるブート処理開始の処理フローを示す。

管理対象サーバ３の電源がＯＮされると、ＰＯＳＴ（Power Of Self Test）処理が行われる（ステップＳ１１）。管理サーバ１に、ＰＸＥ（Preboot eXecution Environment ）要求を送信する（ステップＳ１２）。

図７は、管理対象サーバ３が実行するＨＢＡベンダ判別プログラム１９によるベンダ判別処理の処理フローを示す。

ＰＣＩ（Peripheral Component Interconnect ）があるか否かを調べる（ステップＳ２１）。ここで、ＨＢＡ３２はＰＣＩに含まれる。すなわち、ＰＣＩが検出されなければ、その管理対象サーバはＨＢＡ３２を持たないことになる。ＰＣＩがあった場合、ＰＣＩのベンダＩＤとデバイスＩＤとを用いて、ＰＣＩのベンダ種別が判明するか否かを調べる（ステップＳ２２）。ベンダ種別が判明した場合、そのベンダ種別に対応するＨＢＡベンダ専用プログラム１１０を管理サーバ１に要求する（ステップＳ２３）。

ステップＳ２１でＰＣＩがなかった場合（このときＷＷＮはない）、またはステップＳ２２でベンダ種別が判明しなかった場合、管理サーバ１からサーバ定義ファイル１１１を読み込み（ステップＳ２４）、読み込まれたサーバ定義ファイル１１１で定義されたブート先がネットワークであるか（ｂｏｏｔ＝ｎｅｔ）否かを調べる（ステップ２５）。ブート先がネットワークであった場合、管理サーバ１に起動プログラム１１２を要求する（ステップＳ２６）。ブート先がネットワークでなかった場合、次のブート優先順位に移る（ステップＳ２７）。この結果、ＰＣＩがない場合には、ＳＡＮブートは行われない。また、ＰＣＩのベンダ種別が判明していない場合には、Ｆ−ＷＷＮ３２１でＳＡＮブートが行われる。

ＨＢＡベンダ判別プログラム１９によって、ＨＢＡ３２のベンダを特定することができるため、ＨＢＡベンダに適応したＨＢＡベンダ専用プログラム１１０を特定して要求することができる。

図８は、管理対象サーバ３が実行するＨＢＡベンダ専用プログラム１１０によるベンダ専用処理の処理フローを示す。

管理サーバ１からサーバ定義ファイル１１１を読み込む（ステップＳ３１）。ＨＢＡ３２の揮発性メモリにＷＷＮＮが設定されているかを調べる（ステップＳ３２）。ＷＷＮＮが設定されていなかった場合、サーバ定義ファイル１１１で定義されたＷＷＮＮ（ｗｗｎｎ＝）をＨＢＡ３２の揮発性メモリに設定し（ステップＳ３３）、サーバ定義ファイル１１１で定義されたＷＷＰＮ（ｗｗｐｎ＝）をＨＢＡ３２の揮発性メモリに設定する（ステップＳ３４）。ＨＢＡ３２のＰＣＩ初期化コードがロード可能であるか否かを調べる（ステップＳ３５）。ＰＣＩ初期化コードがロード可能でなかった場合、管理サーバ１のブート制御手段１６にブートステージ＝２を通知し（ステップＳ３６）、管理対象サーバ３のリセットを行い、ＰＯＳＴ処理を起動する（ステップＳ３７）。ＰＣＩ初期化コードがロード可能であった場合、ＨＢＡ３２の再初期化を行う（ステップＳ３８）。

ステップＳ３２でＷＷＮＮが設定されていた場合と、ステップＳ３８でＨＢＡ３２の再初期化が行われた場合には、読み込まれたサーバ定義ファイル１１１で定義されたブート先がネットワークであるか（ｂｏｏｔ＝ｎｅｔ）否かを調べる（ステップ３９）。ブート先がネットワークであった場合、管理サーバ１に起動プログラム１１２を要求する（ステップＳ３１０）。ブート先がネットワークでなかった場合、次のブート優先順位（ＳＡＮブート）に移る（ステップＳ３１１）。

図９は、管理対象サーバ３が実行するＮＯＰプログラム１８によるＮＯＰ処理の処理フローを示す。

管理サーバ１からサーバ定義ファイル１１１を読み込み（ステップＳ４１）、読み込まれたサーバ定義ファイル１１１で定義されたブート先がネットワークであるか（ｂｏｏｔ＝ｎｅｔ）否かを調べる（ステップ４２）。ブート先がネットワークであった場合、管理サーバ１に起動プログラム１１２を要求する（ステップＳ４３）。ブート先がネットワークでなかった場合、次のブート優先順位（ＳＡＮブート）に移る（ステップＳ４４）。

ＮＯＰプログラム１８は、ＨＢＡベンダ専用プログラム１１０と異なり、ＷＷＮの設定を行わない。ＷＷＮを設定してリセットを行った後のブート処理では、ＮＯＰプログラム１８を実行することにより、ＷＷＮの設定を行わずにブート処理を行うことができる。

図１０は、管理対象サーバ３が実行する起動プログラム１１２による起動処理の処理フローを示す。図１０に示す起動プログラム１１２による処理が、ネットワークブートによるユーザＯＳ起動の処理である。

別の処理で読み込まれたサーバ定義ファイル１１１のブートイメージ（ｂｏｏｔｉｍａｇｅ＝）で定義されたＯＳを含む業務イメージ１１３を、管理サーバ１から読み込む（ステップＳ５１）。読み込まれたＯＳを含む業務イメージ１１３を起動する（ステップＳ５２）。

図１１、図１２は、管理サーバ１のブート制御手段１６（ブートサーバ）が実行する処理の処理フローを示す。

ブート制御手段１６は、管理対象サーバ３からの受信があるか否かを監視する（ステップＳ６１）。

管理対象サーバ３からの受信がＰＸＥ要求である場合（ステップＳ６２）、サーバ管理テーブル１４を参照し、該当管理対象サーバ３のブートステージが１であるか否かを調べる（ステップＳ６３）。ブートステージが１でなかった場合、サーバ管理テーブル１４を参照し、該当管理対象サーバ３のブート時間から１０分が経過したか否かを調べる（Ｓ６４）。１０分経過していなかったら、該当管理対象サーバ３にＮＯＰプログラム１８を送付する（ステップＳ６５）。１０分経過していた場合には（例えば、ネットワークダウン）、サーバ管理テーブル１４の該当管理対象サーバのブートステージを１に更新する（ステップＳ６６）。

ステップＳ６３でブートステージが１であった場合と、ステップＳ６６でブートステージの更新が行われた場合には、サーバ管理テーブル１４の該当管理対象サーバ３のブート時間の記録を行い（ステップＳ６７）、該当管理対象サーバ３にＨＢＡベンダ判別プログラム１９を送付する（ステップＳ６８）。

このように、管理対象サーバ３のブート状況を示す情報であるブートステージを利用すれば、管理対象サーバ３のブート状況がＷＷＮを設定した後にリセットを行った状況であるか否かを、容易に判断することができる。

管理対象サーバ３からの受信がＨＢＡベンダ専用プログラム要求である場合（ステップＳ６９）、該当管理対象サーバ３に、要求されたＨＢＡベンダ専用プログラム１１０を送付する（ステップＳ６１０）。

管理対象サーバ３からの受信が起動プログラム要求である場合（ステップＳ６１１）、該当管理対象サーバ３に、要求された起動プログラム１１２を送付する（ステップＳ６１２）。

管理対象サーバ３からの受信がブートステージ＝２の通知である場合（ステップＳ６１３）、サーバ管理テーブル１４の該当管理対象サーバ３のブートステージを２に更新する（ステップＳ６１４）。

管理対象サーバ３からの受信が、ＰＸＥ要求でも、ＨＢＡベンダ専用プログラム要求でも、起動プログラム要求でも、ブートステージ＝２の通知でもなければ、エラーとする（ステップＳ６１５）。

以下、図１３、図１４を用いて、現用系の管理対象サーバ３から待機系の管理対象サーバ３への交代が行われる場合のブート制御処理の流れを説明する。ブート制御処理は、ＨＢＡカードのＰＣＩエキスパンジョンＲＯＭ初期化コードにアクセスできるか否かによって、大きく処理手順が異なる。

図１３は、ＨＢＡカードのＰＣＩエキスパンジョンＲＯＭ初期化コードにアクセス可能な場合のブート制御処理の処理シーケンスを示す。

管理サーバ１が現用系の管理対象サーバ３ａに電源ＯＮ指示を出すと（Ｐ１１）、管理対象サーバ３ａでは、電源がＯＮされ（Ｐ１２）、ＢＩＯＳによるＰＯＳＴが行われる（Ｐ１３）。なお、待機系の管理対象サーバ３ｂは、このとき電源ＯＦＦの状態である（Ｐ１４）。

管理対象サーバ３ａは、管理サーバ１のブート制御手段１６にアクセスし、ＰＸＥ初期化処理を行う（Ｐ１５）。管理サーバ１は、ブート制御手段１６によるブートサーバ処理を行う（Ｐ１６）。この段階でのブートステージは、１である。管理サーバ１は、管理対象サーバ３ａからのＰＸＥ要求に対して、ＨＢＡベンダ判別プログラム１９を送付し、管理対象サーバ３ａからのＨＢＡベンダ専用プログラム要求に対して、該当するＨＢＡベンダのＨＢＡベンダ専用プログラム１１０を送付する。ここで、ＨＢＡベンダ専用プログラム１１０により管理対象サーバ３ａのＨＢＡ３２でＷＷＮ値の書換えが行われても、ＨＢＡ３２のＰＣＩエキスパンジョンＲＯＭ初期化コードにアクセス可能であるため、リセットせずにＨＢＡ３２の再初期化を行うことが可能である。管理対象サーバ３ａは、ＳＡＮブートによるユーザＯＳの起動を行う（Ｐ１７）。

その後、管理対象サーバ３ａで障害が発生し（Ｐ１８）、管理対象サーバ３ａが停止する（Ｐ１９）。

管理サーバ１は、管理対象サーバ３ａの障害発生を検知すると（Ｐ１１０）、サーバ管理テーブル１４を更新し（Ｐ１１１）、待機系の管理対象サーバ３ｂに電源ＯＮ指示を出す（Ｐ１１２）。管理対象サーバ３ｂでは、電源がＯＮされ（Ｐ１１３）、ＢＩＯＳによるＰＯＳＴが行われる（Ｐ１１４）。

管理対象サーバ３ｂは、管理サーバ１のブート制御手段１６にアクセスし、ＰＸＥ初期化処理を行う（Ｐ１１５）。管理サーバ１は、ブート制御手段１６によるブートサーバ処理を行う（Ｐ１１６）。この段階でのブートステージは、１である。管理サーバ１は、管理対象サーバ３ｂからのＰＸＥ要求に対して、ＨＢＡベンダ判別プログラム１９を送付し、管理対象サーバ３ｂからのＨＢＡベンダ専用プログラム要求に対して、該当するＨＢＡベンダのＨＢＡベンダ専用プログラム１１０を送付する。ここで、管理対象サーバ３ｂのＨＢＡ３２にＷＷＮの設定変更が行われる。ＨＢＡ３２のＰＣＩエキスパンジョンＲＯＭ初期化コードにアクセス可能であるため、リセットされずにＨＢＡ３２の再初期化が行われる。管理対象サーバ３ｂは、ＳＡＮブートによるユーザＯＳの起動を行う（Ｐ１１７）。

図１４は、ＨＢＡカードのＰＣＩエキスパンジョンＲＯＭ初期化コードにアクセス不可能な場合のブート制御処理の処理シーケンスを示す。

管理サーバ１が現用系の管理対象サーバ３ａに電源ＯＮ指示を出すと（Ｐ２１）、管理対象サーバ３ａでは、電源がＯＮされ（Ｐ２２）、ＢＩＯＳによるＰＯＳＴが行われる（Ｐ２３）。なお、待機系の管理対象サーバ３ｂは、このとき電源ＯＦＦの状態である（Ｐ２４）。

管理対象サーバ３ａは、管理サーバ１のブート制御手段１６にアクセスし、ＰＸＥ初期化処理を行う（Ｐ２５）。管理サーバ１は、ブート制御手段１６によるブートサーバ処理を行う（Ｐ２６）。この段階でのブートステージは、１である。管理サーバ１は、管理対象サーバ３ａからのＰＸＥ要求に対して、ＨＢＡベンダ判別プログラム１９を送付し、管理対象サーバ３ａからのＨＢＡベンダ専用プログラム要求に対して、該当するＨＢＡベンダのＨＢＡベンダ専用プログラム１１０を送付する。ここで、ＨＢＡベンダ専用プログラム１１０により管理対象サーバ３ａのＨＢＡ３２でＷＷＮ値の書換えが行われた場合、ＨＢＡ３２のＰＣＩエキスパンジョンＲＯＭ初期化コードにアクセスできないため、一度管理対象サーバ３ａをリセットする必要がある。

管理対象サーバ３ａは、ＢＩＯＳによるＰＯＳＴを行い（Ｐ２７）、管理サーバ１のブート制御手段１６にアクセスし、ＰＸＥ初期化処理を行う（Ｐ２８）。管理サーバ１は、ブート制御手段１６によるブートサーバ処理を行う（Ｐ２９）。この段階でのブートステージは、２である。管理サーバ１は、管理対象サーバ３ａからのＰＸＥ要求に対して、ＮＯＰプログラム１８を送付する。管理対象サーバ３ａは、ＳＡＮブートによるユーザＯＳの起動を行う（Ｐ２１０）。

その後、管理対象サーバ３ａで障害が発生し（Ｐ２１１）、管理対象サーバ３ａが停止する（Ｐ２１２）。

管理サーバ１は、管理対象サーバ３ａの障害発生を検知すると（Ｐ２１３）、サーバ管理テーブル１４を更新し（Ｐ２１４）、待機系の管理対象サーバ３ｂに電源ＯＮ指示を出す（Ｐ２１５）。管理対象サーバ３ｂでは、電源がＯＮされ（Ｐ２１６）、ＢＩＯＳによるＰＯＳＴが行われる（Ｐ２１７）。

管理対象サーバ３ｂは、管理サーバ１のブート制御手段１６にアクセスし、ＰＸＥ初期化処理を行う（Ｐ２１８）。管理サーバ１は、ブート制御手段１６によるブートサーバ処理を行う（Ｐ２１９）。この段階でのブートステージは、１である。管理サーバ１は、管理対象サーバ３ｂからのＰＸＥ要求に対して、ＨＢＡベンダ判別プログラム１９を送付し、管理対象サーバ３ｂからのＨＢＡベンダ専用プログラム要求に対して、該当するＨＢＡベンダのＨＢＡベンダ専用プログラム１１０を送付する。ここで、管理対象サーバ３ｂのＨＢＡ３２にＷＷＮの設定変更が行われる。ここで、ＨＢＡ３２のＰＣＩエキスパンジョンＲＯＭ初期化コードにアクセスできないため、一度管理対象サーバ３ａをリセットする必要がある。

管理対象サーバ３ｂは、ＢＩＯＳによるＰＯＳＴを行い（Ｐ２２０）、管理サーバ１のブート制御手段１６にアクセスし、ＰＸＥ初期化処理を行う（Ｐ２２１）。管理サーバ１は、ブート制御手段１６によるブートサーバ処理を行う（Ｐ２２２）。この段階でのブートステージは、２である。管理サーバ１は、管理対象サーバ３ｂからのＰＸＥ要求に対して、ＮＯＰプログラム１８を送付する。管理対象サーバ３ｂは、ＳＡＮブートによるユーザＯＳの起動を行う（Ｐ２２３）。

図１３、図１４に示すように、ＨＢＡベンダ判別プログラム１９、ＨＢＡベンダ専用プログラム１１０、ＮＯＰプログラム１８を適宜利用することにより、管理対象サーバ３の起動時のブート処理を１度で済ますことができる。

ＳＡＮ環境における冗長化された計算機システムの構成の一例を示す図である。 ＳＡＮ環境における冗長化された計算機システムにおける管理サーバ及び管理対象サーバの構成の一例を示す図である。 サーバ管理テーブルの一例を示す。 サーバ定義ファイルの一例を示す。 固定された管理対象サーバのブート優先順を示す。 管理対象サーバが実行するファームウェアによるブート処理の処理フローを示す。 管理対象サーバが実行するＨＢＡベンダ判別プログラムによるベンダ判別処理の処理フローを示す。 管理対象サーバが実行するＨＢＡベンダ専用プログラムによるベンダ専用処理の処理フローを示す。 管理対象サーバが実行するＮＯＰプログラムによるＮＯＰ処理の処理フローを示す。 管理対象サーバが実行する起動プログラムによる起動処理の処理フローを示す。 管理サーバのブート制御手段（ブートサーバ）が実行する処理の処理フローを示す。 管理サーバのブート制御手段（ブートサーバ）が実行する処理の処理フローを示す。 ＨＢＡカードのＰＣＩエキスパンジョンＲＯＭ初期化コードにアクセス可能な場合のブート制御処理の処理シーケンスを示す。 ＨＢＡカードのＰＣＩエキスパンジョンＲＯＭ初期化コードにアクセス不可能な場合のブート制御処理の処理シーケンスを示す。 ＳＡＮからのブートを行う冗長化された計算機システムによる処理シーケンスを示す。

符号の説明

１ 管理サーバ
２ 管理ネットワーク
３ 管理対象サーバ
４ ストレージエリアネットワーク（ＳＡＮ）
５ ストレージ
１２ サーバ管理手段
１３ 異常検出手段
１４ サーバ管理テーブル
１５ 電源制御手段
１６ ブート制御手段
１７ ブート制御オブジェクト
１８ ＮＯＰプログラム
１９ ＨＢＡベンダ判別プログラム
１１０ ＨＢＡベンダ専用プログラム
１１１ サーバ定義ファイル
１１２ 起動プログラム
１１３ 業務イメージ

Claims (6)

1. 管理ネットワークを介して、１または複数の管理対象計算機を管理する管理サーバによるブート制御方法であって、
   前記管理サーバが、
   前記管理対象計算機からブート要求を受信するステップと、
   前記ブート要求を行った管理対象計算機に対して、前記管理対象計算機が有するポートに固有のＩＤを設定するプログラムを送付するステップとを有し、
   前記管理対象計算機は、前記固有のＩＤを設定するプログラムを実行することにより、前記固有のＩＤをポートに設定し、所定のブート優先順にしたがってブート処理を行う
   ことを特徴とするブート制御方法。
2. 前記管理サーバは、前記管理対象計算機のインタフェースの種別に応じた複数種の前記固有のＩＤを設定するプログラムを備え、
   前記管理サーバが、
   前記ブート要求を行った管理対象計算機に対して、前記固有のＩＤを設定するプログラムを特定する判別プログラムを送信するステップと、
   前記管理対象計算機から、前記管理対象計算機が前記判別プログラムを実行することにより特定された前記固有のＩＤを設定するプログラムの要求を受信するステップとを有し、
   前記固有のＩＤを割り当てるプログラムを送付するステップでは、前記要求された前記固有のＩＤを割り当てるプログラムを、前記管理対象計算機に送付する
   ことを特徴とする請求項１に記載のブート制御方法。
3. 前記管理サーバが、
   前記固有のＩＤをポートに設定した後にリセットを行った前記管理対象計算機から、ブート要求が受信された場合に、前記管理対象計算機に対して、固有のＩＤを設定しないプログラムを送付するステップを有し、
   前記管理対象計算機は、前記固有のＩＤを設定しないプログラムを実行し、所定のブート優先順にしたがってブート処理を行う
   ことを特徴とする請求項１または請求項２に記載のブート制御方法。
4. 前記管理サーバが、
   前記管理対象計算機のブート状況を示す情報であるブート状況情報を記憶するステップと、
   前記管理対象計算機から、前記固有のＩＤをポートに設定した後にリセットを行う旨を示す情報を取得し、取得された情報で前記ブート状況情報を更新するステップとを有し、
   前記固有のＩＤを設定しないプログラムを送付するステップでは、前記管理対象計算機のブート状況情報が前記固有のＩＤをポートに設定した後にリセットを行う旨を示す情報である場合に、前記管理対象計算機に対して、固有のＩＤを設定しないプログラムを送付する
   ことを特徴とする請求項３に記載のブート制御方法。
5. １または複数の管理対象計算機と、１または複数の管理対象計算機を管理する管理サーバとが、管理ネットワークを介して接続された計算機システムであって、
   前記管理サーバは、前記１または複数の管理対象計算機に対するブート制御を行うブート制御手段を備え、
   前記ブート制御手段は、ブート要求を行った管理対象計算機に対して、前記管理対象計算機が有するポートに固有のＩＤを設定するプログラムを送付し、
   前記管理対象計算機は、前記固有のＩＤを設定するプログラムを実行することにより、前記固有のＩＤをポートに設定し、所定のブート優先順にしたがってブート処理を行う
   ことを特徴とする計算機システム。
6. 管理ネットワークを介して、１または複数の管理対象計算機を管理する管理サーバにおいて実行されるブート制御プログラムであって、
   コンピュータである前記管理サーバに、
   前記管理対象計算機からブート要求を受信するステップと、
   前記ブート要求を行った管理対象計算機に対して、前記管理対象計算機が有するポートに固有のＩＤを設定するプログラムを送付するステップとを実行させ、
   前記管理対象計算機は、前記固有のＩＤを設定するプログラムを実行することにより、前記固有のＩＤをポートに設定し、所定のブート優先順にしたがってブート処理を行う
   ことを特徴とするブート制御プログラム。

Images