JP2013178697A - 計算機、計算機システムおよび計算機システムの起動方法 - Google Patents

Abstract

【課題】サーバで起動予定のオペレーティングシステムが格納されたＬＶとは異なるＬＶからオペレーティングシステムを起動することを防ぐシステムを提供する。
【解決手段】第一のサーバは、第二のサーバで起動するオペレーティングシステムが格納される記憶部に、前記第二のサーバを識別する起動管理情報を格納し、前記第二のサーバは、アクセス設定された記憶部に前記第二のサーバを識別する起動管理情報が格納されているかを判定する。前記判定により、前記アクセス設定された記憶部に前記第二のサーバを識別する起動管理情報が格納されている場合、前記第二のサーバは前記アクセス設定された記憶部に格納された前記オペレーティングシステムを起動する。前記第二のサーバを識別する起動管理情報が格納されていない場合、前記第二のサーバは前記アクセス設定された記憶部に格納されたオペレーティングシステムの起動を抑止する。
【選択図】図５

Description

本発明は、計算機、計算機システムおよび計算機システムにおける論理ボリュームからのオペレーティングシステムの起動方法に関する。

複数の計算機で共有可能なストレージ装置が普及している。計算機とストレージ装置はストレージネットワークを介して接続される。このように構成されたネットワークシステムは、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）と呼ばれる。

ストレージ装置は記憶領域を論理的に分割した論理ボリューム（ＬＶ）を格納している。ＳＡＮにおいて、計算機は、ＬＶを外部の補助記憶装置としてアクセスする。一般に、ストレージ装置及びストレージネットワークのスイッチは計算機からのＬＶへのアクセス制御機能を有している。計算機は、ストレージ装置でアクセス許可の設定がされているＬＶを参照可能である。

ＳＡＮにおいて、一般に、複数の計算機を管理するサーバ管理者と、ストレージ装置及びストレージネットワークのスイッチを管理するストレージ管理者が存在する。サーバ管理者は計算機の設定、計算機の電源管理、計算機資源の保守、計算機上で実行するオペレーティングシステム（ＯＳ）やアプリケーションの管理を行う。一方、ストレージ管理者はストレージ装置の設定、ＬＶの作成や削除、ＬＶのアクセス許可設定、ストレージ装置資源の保守、ストレージネットワークの設定を行う。

サーバ管理者は、システム情報（ＯＳやアプリケーション等）の格納されているＬＶからＯＳを起動するために、計算機から参照したいＬＶのアクセス許可をストレージ管理者に依頼する。ストレージ管理者は、ストレージ装置が格納しているＬＶの一覧から対象のＬＶを選択し、計算機から参照可能なようにＬＶのアクセス許可の設定を行う。これ以降、ＯＳの起動が可能となる。

また、特許文献１には、「ボリュームがＯＳ起動のためのシステムボリュームとして予約されているか否かを示すロックデータをボリューム内に保持し、計算機はＯＳを起動する前に、ボリューム内に保持されているロックデータがシステムボリュームとして予約されていないことを示すとき、システムボリュームとして予約されていることを示すデータをロックデータとして書き込み、ロックデータがシステムボリュームとして予約されていることを示すとき、ボリュームへのアクセスを停止する」と記載されている。

特開２００９‐１９９２２４号公報

ＳＡＮにおいて、ストレージ管理者がＬＶのアクセス許可設定を行った際、サーバ管理者の意図していないＬＶに対して誤ってアクセス許可設定を行う可能性がある。

サーバ管理者はＬＶのシステム情報（ＯＳやアプリケーション等）を把握しているが、ストレージ装置内でのＬＶの管理情報（ＬＶの管理番号やＬＶの管理用名称等）を知ることは困難である。一方、ストレージ管理者はＬＶの管理情報を把握しているが、ＬＶのシステム情報を知ることは困難である。このようにして、サーバ管理者が計算機からＯＳを起動するために、あるＬＶのアクセス許可設定をストレージ管理者に依頼しても、ストレージ管理者の設計ミス等により、サーバ管理者の望んだＬＶと計算機から参照可能なＬＶとが異なる状況が起こり得る。

さらに、サーバ管理者がＯＳを起動するまで参照可能なＬＶにどのようなシステム情報が格納されているか知ることは困難であるため、サーバ管理者の望んだＬＶとは異なるＬＶからＯＳを起動する可能性がある。もしサーバ管理者の意図とは異なるＬＶからＯＳを起動した場合、計算機の停止処理を実行し、ＬＶの再設定をストレージ管理者に依頼する必要があるため、システムの迅速な移行が行えない。また、サーバ管理者の意図とは異なるＬＶが異なる計算機で使用しているＬＶであった場合、そのＬＶからのＯＳの起動によって、ＬＶのシステム領域の破壊につながる場合がある。

特許文献１では、他の計算機で使用されているＯＳの起動を抑止可能である。しかし、特許文献１には、計算機から参照可能なＬＶが、計算機で起動予定のＯＳが格納されたＬＶと同一であるかを確認する手段についてまでの記載はない。

上記の課題を解決するための本発明の一例は以下のとおりである。複数の計算機と接続され、何れかの計算機で起動するオペレーティングシステムが格納される記憶部と、前記記憶部に前記何れかの計算機を識別する起動管理情報を格納するファームウェアを有する第一の計算機と、アクセスした前記記憶部に自身の計算機を識別する起動管理情報が格納されているか否かを判定するファームウェアを有し、前記判定において前記自身の計算機を識別する起動管理情報が格納されている場合、前記アクセスした記憶部に格納される前記オペレーティングシステムを起動する第二の計算機とを備えることを特徴とする計算機システムである。

本発明によれば、計算機は起動予定のＯＳが格納されたＬＶから確実にＯＳを起動でき、他のＬＶからのＯＳの起動を抑止出来る。

実施例１におけるシステムの構成例を示す図である。 実施例１、実施例２、実施例３、実施例４におけるホストサーバの構成例を示す図である。 実施例１におけるボリューム管理領域の更新処理のフローチャートである。 実施例１におけるボリューム管理領域の保持するデータの構想を示す図である。 実施例１におけるボリューム管理領域と、ホストサーバの保持するサーバ固有情報の一致判定処理のフローチャートである。 実施例２におけるシステムの構成例を示す図である。 実施例２におけるボリューム管理領域の保持するデータの構想を示す図である。 実施例２における起動管理テーブルの更新処理のフローチャートである。 実施例２における起動管理テーブルの保持するデータの構想を示す図である。 実施例２におけるボリューム管理領域と、ホストサーバの保持する起動管理テーブルの一致判定処理のフローチャートである。 実施例３におけるシステムの構成例を示す図である。 実施例３における一時管理バッファの更新処理のフローチャートである。 実施例３におけるボリューム管理領域の更新処理のフローチャートである。 実施例３における起動管理テーブルの更新処理のフローチャートである。 実施例４におけるシステムの構成例を示す図である。

以下、図面を用いて実施例を説明する

本発明の第一の実施の形態について説明する。第一の実施の形態では、起動を行う論理ボリューム（ＬＶ）内に起動予定のホストサーバの固有情報を予めもたせることで、起動予定ではないＬＶからのＯＳの起動を抑止する効果をもった装置の構成、および方法を示す。

図１は、第一の実施の形態のシステム構成を示す図である。システムは、ホストサーバ（計算機）１００とホストサーバ（計算機）１１０、ストレージ装置１５０から構成される。

ホストサーバ１００とホストサーバ１１０は、それぞれに搭載されているネットワークインターフェースカード（ＮＩＣ）１０２、１１２によって通信可能なように、管理用ネットワークで構成されている。また、ホストサーバ１００とホストサーバ１１０は、それぞれに搭載のディスクアダプタ１０１、１１１により、ストレージネットワークを介して、ストレージ装置に接続されている。ホストサーバ１００とホストサーバ１１０は同様の構成とする。ホストサーバ内の各構成については、図２を用いて説明する。

図２は、ホストサーバ１００の構成を示す図である。ＣＰＵ２０１、メモリ２０２、管理用コントローラ１０３、システムファームウェア１０４、ディスクアダプタ１０１、ＮＩＣ１０２、不揮発性ＲＡＭ（Ｎｏｎ―ｖｏｌａｔｉｌｅ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：ＮＶＲＡＭ）２０４が、バス制御装置２０３を介して接続している。

システムファームウェア１０４は、ホストサーバ１００に組み込まれたファームウェア用ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）上に実装される。また、システムファームウェア１０４はＣＰＵ１０４で実行される。

ＣＰＵ２０１は、システムファームウェア１０４の起動プログラムを実行し、起動用として予めサーバ管理者に指定されたＬＶの特定領域をメモリに読み込み、そのＬＶに格納されているＯＳの起動を実施する。

以下の説明では、起動用として予めサーバ管理者に指定されたＬＶを起動用ＬＶとして説明する。サーバ管理者は、ホストサーバのシステムファームウェア上で参照可能なＬＶの中から起動用ＬＶを指定する。また、ＣＰＵ２０１がメモリ２０２あるいはシステムファームウェア１０４に格納されているプログラムを実行することを、そのプログラムが実行するとして説明する。

システムファームウェア１０４には、計算機を識別するための固有のＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ：ＵＵＩＤ）２１３が付与されている。

ディスクアダプタ１０１は、ホストサーバ１００とストレージ装置１５０を接続して、ホストサーバ１００でストレージ装置１５０内の特定のＬＶにアクセス出来るようにするためのインターフェースカードである。ディスクアダプタ１０１には、固有のＩＤ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ：ＷＷＮ）２１１が付与されている。

ＮＩＣ１０２は、他の計算機と通信をするためのインターフェースカードである。ＮＩＣ１０２には、固有のＩＤ（ＭＡＣアドレス）２１２が付与されている。

ＮＶＲＡＭ２０４は、システムファームウェア１０４や管理用コントローラ１０３から読み書き可能なデータ領域として使用される。本実施例では、ＮＶＲＡＭ２０４がバス制御装置２０４に接続されていても良いし、接続されていなくても良い。

管理用コントローラ１０３は、バス制御装置２０６に接続されている各デバイス（ＣＰＵ２０１、メモリ２０２、システムファームウェア１０４、ディスクアダプタ１０１、ＮＩＣ１０２、ＮＶＲＡＭ２０４）の状態を監視するファームウェアを実行可能な計算機である。また、管理用コントローラ１０３は、ホストサーバ１００のＵＵＩＤ２１３、ディスクアダプタ１０１のＷＷＮ２１１、ＮＩＣ１０２のＭＡＣアドレス２１２の情報を保持している。

次に、本実施例におけるホストサーバのＬＶからの起動制御処理について説明する。図１は、ＬＶ１６０からの起動制御処理に関わる要素を示した図である。図１は、ホストサーバ１００、１１０の構成、ストレージ装置１５０の構成、ホストサーバ１００，１１０同士を接続する管理用ネットワーク、ホストサーバ１００，１１０とストレージ装置１５０を接続するストレージネットワークを示した図である。

ストレージ装置１５０は、各ホストサーバ１００，１１０がシステムボリュームとして使用するための２つのＬＶ１６０、１７０（記憶部）で構成されている。ここでは２つのＬＶを記載しているが、１つ、または３つ以上存在してもよい。

ＬＶ１６０には、ＯＳやアプリケーションが格納されているシステム領域１６２と、特定のホストサーバのサーバ固有情報が記載されるボリューム管理領域１６１が格納されている。

同様に、ＬＶ１７０には、ＯＳやアプリケーションが格納されているシステム領域１７２と、特定のホストサーバのサーバ固有情報が記載されるボリューム管理領域１７１が格納されている。

ＬＶ１６２とＬＶ１７２には異なるホストサーバで起動するＯＳが格納され、ＬＶ１６１とＬＶ１７１にはそれぞれＬＶ１６２とＬＶ１７２に格納されたＯＳを起動するホストサーバのサーバ固有情報が格納されていても良い。

以下ではＬＶ１６０について代表的に説明する。ボリューム管理領域１６１に記載されるサーバ固有情報は、管理用コントローラ１０３、１１３で保持しているホストサーバ１００、１１０に搭載の一意の値であれば何でも良い。例えば、図２のホストサーバ１００に着目すると、システムファームウェア１０４のＵＵＩＤ２１３でも良いし、ＮＩＣ１０２のＭＡＣアドレス２１２でも良いし、ディスクアダプタ１０１のＷＷＮ２１１でも良い。

また、ボリューム管理領域１６１に記載される内容は、それらのうちの２つの組み合わせでも良いし、あるいはそれらの全てを含んでいても良い。以下では、ホストサーバ１００、１１０に搭載の一意の値をサーバ固有情報として説明する。

システムファームウェア１０４、１１４には、ＬＶ１６０に格納されているボリューム管理領域１６１を更新するためのボリューム管理領域更新プログラム１０６、１１６と、ボリューム管理領域１６１を参照して起動判断を行うボューム管理領域チェックプログラム１０５、１１５が格納されている。

サーバ管理者があるホストサーバで使用していたＬＶを、異なるホストサーバで使用する状況を想定して、以下説明する。本実施例では、まず、ＬＶ自身に起動予定のホストサーバの情報を予め保持させる。さらに、実際に上記のホストサーバからＯＳを起動する際に、上記のＬＶの持っている情報と、上記のホストサーバの持っている情報を比較する。このようにして、サーバ管理者の意図していないＬＶからのＯＳの起動を防ぐ。

サーバ管理者がホストサーバ１１０上に存在するボリューム管理領域プログラム１１６を使用して、ホストサーバ１１０から参照可能なＬＶ１６０のボリューム管理領域１６１を更新する手順を説明する。以下では、起動予定のホストサーバ１００のサーバ固有情報を、サーバ管理者が予め保持しているものとして説明する。サーバ管理者は、ホストサーバ１００の管理用コントローラ１０３からサーバ固有情報を取得可能である。

図３に、ボリューム管理領域更新プログラム１１６のフローを示す。

ボリューム管理領域更新プログラム１１６は、ホストサーバ１１０から参照可能なＬＶの一覧を出力し、ボリューム管理領域を更新するＬＶを選択する選択手段を出力する。サーバ管理者にボリューム管理領域を更新するＬＶを選択させてもよい（ステップ３０１）。ここではホストサーバ１１０からＬＶ１６０が参照可能であるので、ＬＶ１６０が表示される。

ボリューム管理領域更新プログラム１１６は、ボリューム管理領域を更新するＬＶを選択する選択手段から選択されたＬＶ１６０に格納されているボリューム管理領域１６１を読み込む。選択手段から選択されたＬＶ１６０は、サーバ管理者が選択したＬＶであってもよい（ステップ３０２）。

ボリューム管理領域更新プログラム１１６は、読み込んだ内容を出力し、ボリューム管理領域１６１を変更して良いか選択肢を出力する。サーバ管理者にボリューム管理領域１６１を変更して良いか問い合わせてもよい（ステップ３０３）。

選択肢において変更が却下された場合、例えばサーバ管理者が却下した場合は、ボリューム管理領域プログラム１１６の実行を終える（ステップ３０４）。

選択肢において変更が承認された場合、例えばサーバ管理者が承認した場合は、ホストサーバ１００のサーバ固有情報を入力する入力手段を出力する。サーバ管理者にホストサーバ１００のサーバ固有情報を入力させてもよい（ステップ３０５）。サーバ固有情報を入力させる前に、サーバ管理者に管理用パスワードを入力させても良い。

また、サーバ管理者にメモの入力要求をしても良い。サーバ管理者は、ＯＳを起動する日付や使用時の注意等どのような情報もメモに入力して良い。このメモが存在することにより、ステップ３０３でボリューム管理領域の内容が出力された際に、サーバ管理者はボリューム管理領域変更して良いかどうか、より判断がしやすくなる。ただし、このメモは後述するステップ５０５におけるサーバ固有情報の一致比較には用いないものとする。

ボリューム管理領域更新プログラム１１６は、ステップ３０５の入力手段から入力されたサーバ固有情報をボリューム管理領域１６１に上書きする。入力手段から入力されたサーバ固有情報は、サーバ管理者が入力したサーバ固有情報であってもよい（ステップ３０６）。

サーバ固有情報の書き込みが完了したことを出力し、ボリューム管理領域プログラム１１６の実行を終える（ステップ３０７）。

図４に、ボリューム管理領域１６１に記載されるサーバ固有情報の内容例４０１を示す。ホストサーバ１００のサーバ固有情報として、ＷＷＮ１（ＷＷＮ２１１）とＵＵＩＤ１（ＵＵＩＤ２１３）が格納されている。

次に、起動用として参照可能なＬＶ１６０からホストサーバ１００が起動する際に、起動しようとしているホストサーバ１００のサーバ固有情報と、ボリューム管理領域１６１に格納されているサーバ固有情報を比較して、ＬＶ１６０を起動制御するフローを説明する。

ホストサーバ１００に電源が投入されると、ホストサーバ１００は、接続されているデバイスの初期化等の起動処理を行った後、システムファームウェア１０４のボリューム管理領域チェックプログラム１０５を読み込み、実行する。

図５に、ボリューム管理領域チェックプログラム１０５のフローを示す。

ボリューム管理領域チェックプログラム１０５は、ホストサーバ１００に起動用に設定されているＬＶ１６０のボリューム管理領域１６１を読み込む（ステップ５０１）。

ボリューム管理領域チェックプログラム１０５は、読み込んだボリューム管理領域１６１に何れかのサーバ（計算機）を識別するサーバ固有情報（起動管理情報）が格納されているか判定する（ステップ５０２）。

サーバ固有情報が格納されていない場合は、エラーを出力し、ＬＶ１６０のシステム領域１６２に格納されているＯＳの起動を抑止する（ステップ５０３）。ただし、ステップ５０３でＯＳの起動を抑止するかどうかは変更可能とする。

ステップ５０３でＯＳの起動を抑止しない場合には、サーバ固有情報が格納されていないがＯＳを起動するか否かを選択させる選択手段を出力し、ＯＳを起動する選択を受け付けると、ＯＳを起動させてもよい。

すなわち、ステップ５０２の判定により、サーバ固有情報が格納されていない場合でも、ＯＳを起動させることができる。例えば、ホストサーバ１１０が管理計算機であり、ＬＶ１６０のシステム領域１６２に格納されているＯＳを起動するサーバがホストサーバ１００だけであるときは、サーバ管理者はＯＳを起動するか否かを選択させる選択手段においてＯＳを起動する選択をして、ＯＳを起動させることができる。

ステップ５０２の判定でサーバ固有情報が格納されていない場合において、ＬＶ１６０がサーバ管理者の意図とは異なるＬＶでなく、サーバ管理者の意図するＬＶであって初期状態であるためにサーバ固有情報が格納されていないときは、ＬＶ１６０のシステム領域１６２に格納されているＯＳを起動させても良い。

また、ステップ５０２の判定により、サーバ固有情報が格納されていない場合には、以後のステップ５０４〜５０７の判定を実施せずに高速にＯＳの起動を抑止することができる。

サーバ固有情報がＬＶ１６０のボリューム管理領域１６１に格納されている場合、管理用コントローラ１０３の管理しているサーバ固有情報を読み込む（ステップ５０４）。

ボリューム管理領域チェックプログラム１０５は、ＬＶ１６０に格納されているサーバ固有情報と、管理用コントローラ１０３に保持されているサーバ固有情報の一致比較を行う（ステップ５０５）。尚、ＬＶ１６０にサーバ固有情報が複数登録されていた場合、全てのサーバ固有情報が同一であることを以って一致と判断するか、一部のサーバ固有情報が同一であることを以って一致と判断するかは、選択出来るようにしておいても良い。

また、本ステップ（ステップ５０５）において、ＬＶ１６０に格納されているサーバ固有情報（起動管理情報）と、管理用コントローラ１０３に保持されているホストサーバ１００を識別するサーバ固有情報（識別情報）との対応を判定しても良い。

例えば、図４のように、２つのサーバ固有情報（ＷＷＮ１、ＵＵＩＤ１）がＬＶ１６０のボリューム管理領域に格納されている状況を想定する。ボリューム管理領域チェックプログラムは、ＷＷＮ１とＵＵＩＤ１のそれぞれについて、ホストサーバ１００のサーバ固有情報と一致しているか判定する。

ボリューム管理領域に格納されている上記２つのサーバ固有情報と、ホストサーバ１００の上記２つのサーバ固有情報が全て同一であることを一致と判断する場合、１つのサーバ固有情報で判断するよりも、起動しようとしているホストサーバをより確実に定めることとなり、システムの堅牢性が増す。一方で、２つのサーバ固有情報のどちらかが同一であることを一致と判断とする場合、システムの柔軟性が増す。例えば、後者の判定条件では、ステップ３０５でサーバ管理者がどちらかのサーバ固有情報の入力ミスしてしまった状況下や、ディスクアダプタ１０１の交換によって想定していたホストサーバ１００の構成が異なった場合でも起動可能である。

ステップ５０６では、ステップ５０５の一致比較において、一致と判断するならばステップ５０８に、一致と判断しない場合はステップ５０７に分岐させる。また、ステップ５０５において、ＬＶ１６０に格納されているサーバ固有情報（起動管理情報）と、管理用コントローラ１０３に保持されているホストサーバ１００を識別する識別情報とが対応する場合はステップ５０８に、対応しない場合はステップ５０７に分岐させる。

ＬＶ１６０に格納されているサーバ固有情報が管理用コントローラ１０３に管理されているサーバ固有情報に一致している場合、ＬＶ１６０のシステム領域１６２の特定領域を読み込みＯＳの起動処理を開始する（ステップ５０８）。もし一致しない場合、エラーを出力し、ＬＶ１６０のシステム領域１６２に格納されているＯＳの起動を抑止する（ステップ５０７）。

以上により、起動用ＬＶ１６０のボリューム管理領域１６１に格納されているサーバ固有情報と、ホストサーバ１００のサーバ固有情報の一致比較によって、サーバ管理者の意図していないＬＶからのＯＳの起動を抑止可能となる。

すなわち、ホストサーバ１１０は、ホストサーバ１００で起動予定のＯＳが格納される起動用ＬＶにホストサーバ１００のサーバ固有情報を格納する。ここで、ホストサーバ１１０は、起動用ＬＶ（記憶部）にホストサーバ１００のサーバ固有情報（起動管理情報）を格納するファームウェアを有する計算機であれば、管理サーバであっても良い。

ホストサーバ（計算機）１００は、ＯＳを起動する前に、ホストサーバ１００からのアクセス許可が設定（アクセス設定）された参照可能なＬＶ（記憶部）にアクセスし、ホストサーバ１００のサーバ固有情報（起動管理情報）が格納されているかを判定する。

アクセスした記憶部にホストサーバ１００のサーバ固有情報が格納されている場合、ホストサーバ１００はアクセス設定された記憶部（起動用ＬＶ）に格納されたＯＳを起動し、アクセス設定された記憶部にホストサーバ１００のサーバ固有情報が格納されていない場合、ホストサーバ１００は前記アクセス設定された記憶部（起動用ＬＶでない他のＬＶ）に格納されたＯＳの起動を抑止する。

また、システムファームウェア１０４は、ステップ５０２とステップ５０６の判定を、アクセスしたＬＶ１６０（記憶部）にホストサーバ１００を識別するサーバ固有情報（起動管理情報）が格納されているか否かを判定する一つの判定で実行しても良く、判定においてホストサーバ１００を識別するサーバ固有情報が格納されている場合、ホストサーバ１００はＬＶ１６０のシステム領域１６２に格納されるＯＳを起動する。また、判定においてホストサーバ１００を識別するサーバ固有情報が格納されていない場合、エラーを出力し、ＬＶ１６０のシステム領域１６２に格納されているＯＳの起動を抑止する。

ＬＶ内に起動予定のホストサーバのサーバ固有情報を格納しておくことは、そのＬＶと起動予定ホストサーバとの関連付けを確実にする。この関連付けにより、ストレージ管理者のミスによってサーバ管理者が望んでいないＬＶをホストサーバに参照可能なように設定されたとしても、誤ったＬＶがそのホストサーバに参照可能なように設定されていることを、サーバ管理者はＬＶに格納されているＯＳの起動前に知ることが可能である。起動する必要の無いＯＳの起動を防止出来るため、誤ったＬＶが参照可能なように設定されていることをストレージ管理者に迅速に伝達可能である。

例えば、システムを移行する際、すなわち開発サーバ（ホストサーバ１１０）から運用サーバ（ホストサーバ１００）に切り替える場合、また計算機（ホストサーバ１００）を増設する場合に、ＯＳを起動する計算機（ホストサーバ１００）は起動予定のＯＳが格納されたＬＶから確実にＯＳを起動でき、他のＬＶからのＯＳの起動を抑止できる。

また、ＬＶのシステム領域を読み込んでＯＳの起動処理を行う前に起動制御を行うことは、他のホストサーバで使用されているＬＶの二重起動も防止可能となる。

本実施例では、実施例１で示したサーバ固有情報を利用した起動制御に加え、起動用ＬＶに格納されているシステム領域の情報を利用した起動制御を実現する場合を示す。

図６は、起動用ＬＶ１６０のシステム領域の情報も利用して一致判断を行うために、図１で示したシステムの構成と比較して、ＮＶＲＡＭ６０８、６１８と、それらのＮＶＲＡＭに格納されている起動管理テーブル（起動管理情報）６０９、６１９と、システムファームウェア６０４、６１４に格納されている起動管理テーブル更新プログラム６０７、６１７が追加されたシステムの構成を示す図である。

本実施例では、実施例１の起動制御と比較してさらに柔軟性を上げるために、管理コントローラ１０３、１１３の保持している以外の情報を利用して、起動制御を行う。この起動制御を実現するために、管理用コントローラ１０３、１１３の保持している情報と、管理用コントローラの保持していない情報を格納するための起動管理テーブル６０９、６１９が、ＮＶＲＡＭ６０８、６１８に格納されている。また、上記の起動管理テーブル６０９、６１９を更新するために、起動管理テーブル更新プログラム６０７、６１７がシステムファームウェア６０４、６１４に格納されている。

実施例１と同様に、サーバ管理者があるホストサーバ６１０で使用していたＬＶ１６０を、異なるホストサーバ６００で使用する状況を想定して、以下説明する。

サーバ管理者がボリューム管理領域プログラム６１６を使用して、ＬＶ１６０のボリューム管理領域１６１を更新する手順を説明する。以下では、起動予定のホストサーバ６００のサーバ固有情報と、システム領域１６２に格納されているシステム情報を、サーバ管理者が予め保持しているものとして説明する。

サーバ管理者の保持しているシステム情報は、システムの詳細な情報でも良いし、ＯＳやアプリケーションの名称やバージョン等のシステムの概要でも良いし、サーバ管理者の識別可能な数値やシステムの略称でも良い。以下では、システム領域に格納されているシステム情報を、システム領域情報として説明する。

ボリューム管理領域更新プログラム６１６を実行する際、図３と比較して、異なる点について説明する。ボリューム管理領域１６１に格納される情報の実施例１との差異は、システム領域情報が追加されることである。従って、ボリューム管理領域更新プログラム６１６がステップ３０５に到達すると、ホストサーバ６００のサーバ固有情報の入力要求に加え、システム領域１６２のシステム領域情報の入力要求も行うものとする。

同様に、ステップ３０６に到達すると、ステップ３０５でサーバ管理者が入力した情報（ホストサーバ６００のサーバ固有情報と、システム領域１６２のシステム領域情報）をボリューム管理領域１６１に上書きする。尚、本実施例では、システム領域情報の入力が行われるのであれば、サーバ固有情報を入力しなくても良い。

図７に、ボリューム管理領域に記載されるサーバ固有情報と、システム領域情報の内容例７０１を示す。サーバ固有情報としてＷＷＮ１とＵＵＩＤ１が格納されている。また、システム領域情報として、システム領域１６２に格納されているＯＳのバージョンＯＳ１と、ＯＳ１上で実行されるアプリケーションの名称ＡＰＰ１が格納されている。

サーバ管理者がホストサーバ６００の起動管理テーブル更新プログラム６０７を使用して、起動管理テーブル６０９を更新する手順を説明する。

図８に、起動管理テーブル更新プログラム６０７のフローを示す。

起動管理テーブル更新プログラム６０７は、ＮＶＲＡＭ６０８に格納されている起動管理テーブル６０９を読み込む（ステップ８０１）。

起動管理テーブル更新プログラム６０７は、読み込んだ内容を出力し、起動管理テーブル６０９を変更して良いか選択肢を出力する。サーバ管理者に起動管理テーブル６０９を変更して良いかを問い合わせてもよい（ステップ８０２）。

選択肢において変更が却下された場合、例えばサーバ管理者が却下した場合は、起動管理テーブル更新プログラム６０７の実行を終える（ステップ８０３）。 選択肢において変更が承認された場合、例えばサーバ管理者が承認した場合は、起動管理情報（ホストサーバ６００のサーバ固有情報と、起動予定のＬＶ１６０のシステム領域情報）を入力する入力手段を出力する。サーバ管理者に起動管理情報を入力させてもよい（ステップ８０４）。

この入力の前に、サーバ管理者に管理用パスワードを入力させても良い。尚、サーバ固有情報を一致比較に用いない場合、サーバ管理者はサーバ固有情報を入力しなくてもよい。さらに、サーバ固有情報をサーバ管理者に入力させずに、管理用コントローラ１０３の保持しているサーバ固有情報を読み込んできても良い。

起動管理テーブル更新プログラム６０７は、ステップ８０４で入力された起動管理情報を一致比較に使用するかの起動制御フラグを入力する入力手段を出力する。サーバ管理者に起動制御フラグを入力させてもよい（ステップ８０５）。この起動制御フラグを起動管理テーブル６０９に格納することで、ホストサーバ６００で起動させたいＬＶをより明示的に指定可能となる。

起動管理テーブル更新プログラム６０７は、ステップ８０４及びステップ８０５で入力された情報を、起動管理テーブル６０９に上書きする（ステップ８０６）。

起動管理テーブル６０９に書込みが完了したことを出力し、起動管理テーブル更新プログラム６０７の実行を終える（ステップ８０６）。

図９に、起動管理テーブルの一例を示す。ホストサーバ６００のサーバ固有情報（ＷＷＮ１、ＵＵＩＤ１、ＭＡＣ１）と、ＬＶ１６０のシステム領域１６２に格納されているオペレーティングシステムのバージョン（ＯＳ１）、ＯＳ１上で実行されるアプリケーションの名称（ＡＰＰ1、ＡＰ２、ＡＰＰ３）、ＯＳ１上で使用されるドライバの名称（ＤＲＶ１）が格納されている。

さらに、各項目に対して１か０の起動制御フラグが格納されており、１であれば後述するステップ１００５における起動管理情報の一致比較の対象とし、起動制御フラグが立てられている状態であるとする。０であれば一致比較の対象外とし、起動制御フラグが立てられていない状態であるとする。この例では、ＷＷＮ１とＵＵＩＤ１とＯＳ１に対応する項目が一致比較の対象となる。

次に、起動用として設定されているＬＶ１６０に格納されているＯＳをホストサーバ６００が起動する際に、起動しようとしているホストサーバ６００の起動管理テーブル６０９に格納されている起動管理情報と、ボリューム管理領域１６１に格納されている起動管理情報を比較して、ＬＶ１６０を起動制御する手順を説明する。

実施例１と同様に、ホストサーバ６００に電源が投入されると、ホストサーバ６００は、接続されているデバイスの初期化等の起動処理を行った後、システムファームウェア６０４のボリューム管理領域チェックプログラム６０５を読み込み、実行する。

ボリューム管理領域チェックプログラム６０５を実行する際、図５と比較して、異なる点について説明する。実施例１との差異は、起動管理テーブルの情報６０９とボリューム管理領域１６１の情報を一致比較することである。

図１０に、ボリューム管理領域チェックプログラム６０５のフローを示す。

ボリューム管理領域チェックプログラム６０５は、ホストサーバ６００の起動用ＬＶとして設定されているＬＶ１６０のボリューム管理領域１６１を読み込む（ステップ１００１）。

ボリューム管理領域チェックプログラム６０５は、読み込んだボリューム管理領域１６１に起動管理情報が格納されているか確認する（ステップ１００２）。起動管理情報が格納されていない場合は、エラーを出力し、ＬＶ１６０のシステム領域１６２に格納されているＯＳの起動を抑止する（ステップ１００３）。ただし、ステップ１００３で起動抑止するかどうかは変更可能とする。

起動管理情報がＬＶ１６０のボリューム管理領域１６１に格納されている場合、ＮＶＲＡＭ６０８に格納されている起動管理テーブル６０９から起動管理情報を読み込む（ステップ１００４）。

ボリューム管理領域チェックプログラム６０５は、ＬＶ１６０に格納されている起動管理情報と、起動管理テーブル６０９に格納されている起動管理情報の一致比較を行う（ステップ１００５）。尚、既に示したように、起動制御フラグが立てられている項目に対して、一致比較が行われる。例えば、ボリューム管理領域７０１と起動管理テーブル９０１を比較する際は、ＷＷＮ１とＵＵＩＤ１とＯＳ１の全てがボリューム管理領域７０１に含まれているかどうか判定される。

ステップ１００６では、ステップ１００５の一致比較において、一致と判断するならばステップ１００８に、一致と判断しない場合はステップ１００７に分岐させる。ＬＶ１６０に格納されている起動管理情報が起動管理テーブル６０９に格納されている起動管理情報と一致している場合、ＬＶ１６０のシステム領域１６２の特定領域を読み込みＯＳの起動処理を開始する（ステップ１００８）。もし一致しない場合、エラーを出力し、ＬＶ１６０のシステム領域１６２に格納されているＯＳの起動を抑止する（ステップ１００７）。

以上により、起動用ＬＶ１６０のボリューム管理領域１６１に格納されている起動管理情報と、ホストサーバ６００の起動管理テーブル６０９の起動管理情報の一致比較により、サーバ管理者の意図していないＬＶに格納されているＯＳからのホストサーバ６００による起動を抑止可能となる。

本実施例では、サーバ固有情報に加え、システム領域内の情報（ＬＶにインストールされているＯＳのバージョンやアプリケーションの名称等）を用いることで、起動したいＯＳやアプリケーションがインストールされているＬＶを指定可能なため、実施例１よりも柔軟に起動制御が可能となる。

本実施例では、実施例２で示したサーバ固有情報とシステム領域情報を利用した起動制御に加え、管理サーバ（管理計算機）を利用した起動制御を実現する場合を示す。

図１１は、管理サーバを使用してＬＶの起動制御を実施するシステムの構成を示す図である。

実施例２の図６と比較して、NVRAM１１０７、１１１７に一時管理バッファ１１０８、１１１８が格納されていて、起動管理テーブル更新プログラム１１８１が一時管理バッファ更新プログラム１１８２と共に管理サーバ１１８０に格納されている。一時管理バッファ１１０８、１１１８には、ボリューム管理領域に格納される情報が、一時的に格納される。

サーバ管理者は、管理サーバ１１８０の一時管理バッファ更新プログラム１１８２を使用して、一時管理バッファ１１０８、１１１８を更新する。ホストサーバ１１００、１１１０上のボリューム管理領域更新プログラム１１０６、１１１６は一時管理バッファ１１０８、１１１８の情報を使用して、ＬＶ１６０のボリューム管理領域１６１を更新する。また、サーバ管理者は、起動管理テーブル更新プログラム１１８１を使用して、起動管理テーブル１１０９、１１１９を更新する。

本実施例では、ボリューム管理領域１６１に格納する情報と起動管理テーブル１１０９に格納する情報を管理サーバ１１８０上で扱う。これにより、同一の情報を扱えるので、サーバ管理者の入力ミスの低減が可能となる。

実施例１及び２と同様に、サーバ管理者があるホストサーバ１１１０で使用していたＬＶ１６０を、異なるホストサーバ１１００で使用する状況を想定して、以下説明する。

サーバ管理者が管理サーバ１１８０の一時管理バッファ更新プログラム１１８２を利用して、ＬＶ１６０を参照可能なホストサーバ１１１０上の一時管理バッファ１１１８を更新する手順を説明する。

以下では、管理サーバ１１８０は、管理用ネットワークに接続されているホストサーバ１１００、１１１０のサーバ固有情報を保持しているものとして説明する。さらに、実施例２と同様に、サーバ管理者はシステム領域１６２に格納されているシステム情報を予め保持しているものとして説明する。

図１２に、一時管理バッファ更新プログラム１１８２のフローを示す。

一時管理バッファ更新プログラム１１８２は、一時管理バッファを更新するホストサーバを指定する指定手段を出力する。サーバ管理者に一時管理バッファを更新するホストサーバを指定させてもよい。（ステップ１２０１）。一時管理バッファはボリューム管理領域を更新するために使用される。ここでは、ホストサーバ１１１０でＬＶ１６０が参照可能なので、ホストサーバ１１１０をサーバ管理者は指定する。

一時管理バッファ更新プログラム１１８２は、ボリューム管理領域１６１に格納する起動管理情報を作成する（ステップ１２０２）。この起動管理情報の作成の際、起動予定のホストサーバをサーバ管理者に選択させてそのサーバ固有情報を使って作成しても良いし、サーバ管理者にサーバ固有情報やシステム領域の情報を入力させても良い。

起動管理情報の作成を終えると、ホストサーバ１１１０の管理用コントローラ１１３に、管理用ネットワークを介して、一時管理バッファ１１１８に格納する起動管理情報を送信することを通知する（ステップ１２０３）。管理用コントローラはこの通知を受けて、ステップ１２０４で受信する起動管理情報の書き込み準備を行う。

一時管理バッファ更新プログラム１１８２は、管理用ネットワークを介して、ホストサーバ１１１０に作成した起動管理情報を送信し、管理用コントローラ１１３に一時管理バッファ１１１８への書き込みを実施させる（ステップ１２０４）。

送信が完了したことを出力し、一時管理バッファ更新プログラム１１８２の実行を終える（ステップ１２０５）。

ボリューム管理領域更新プログラム１１１６を使用して、一時管理バッファ１１１８に格納されている情報をボリューム管理領域１６１に格納する手順を説明する。

図１３に、ボリューム管理領域更新プログラム１１１６のフローを示す。

ボリューム管理領域更新プログラム１１１６は、ホストサーバ１１１０から参照可能なＬＶの一覧を出力し、ボリューム管理領域１６１を更新するＬＶを選択させる選択手段を出力する。サーバ管理者にボリューム管理領域１６１を更新するＬＶを選択させてもよい（ステップ１３０１）。ここではホストサーバ１１１０からＬＶ１６０が参照可能であるとしているので、ＬＶ１６０が表示される。 ボリューム管理領域更新プログラム１１１６は、選択手段により選択されたＬＶ１６０に格納されているボリューム管理領域１６１を読み込む（ステップ１３０２）。

ボリューム管理領域更新プログラム１１１６は、読み込んだ内容を出力し、ボリューム管理領域１６１を変更して良いか選択肢を出力する。サーバ管理者にボリューム管理領域１６１を変更して良いか問い合わせてもよい（ステップ１３０３）。

選択肢において変更が却下された場合、例えばサーバ管理者が却下した場合は、ボリューム管理領域更新プログラム１１１６の実行を終える（ステップ１３０４）。

選択肢において変更が承認された場合、例えばサーバ管理者が承認した場合は、ボリューム管理領域更新プログラム１１１６は、一時管理バッファ１１１８に格納されている情報を読み込む（ステップ１３０５）。

読み込んだ情報を、参照可能なＬＶ１６０のボリューム管理領域１６１に書き込む（ステップ１３０６）。

書き込みが完了したことを出力し、ボリューム管理領域更新プログラム１１１６の実行を終える（ステップ１３０７）。

このように、図１２及び図１３で示したフローを通して、管理サーバ１１８０で作成した情報をＬＶ１６０のボリューム管理領域１６１への格納が可能である。

管理サーバ１１８０上の起動管理テーブル更新プログラム１１８１を使用して、起動管理テーブル１１０９を更新する手順を説明する。尚、起動管理テーブル１１０９の更新手順は、図１２で示した一時管理バッファ１１１８の更新手順と同様である。

図１４に、起動管理テーブル更新プログラム１１８１のフローを示す。

起動管理テーブル更新プログラム１１８１は、起動管理テーブルを更新するホストサーバを指定する指定手段を出力する。サーバ管理者に起動管理テーブルを更新するホストサーバを指定させてもよい（ステップ１４０１）。ホストサーバ１１００を起動予定なので、ホストサーバ１１００をサーバ管理者は指定する。 起動管理テーブル更新プログラム１１８１は、起動管理テーブル１１０９に格納する起動管理情報を作成する（ステップ１４０２）。この起動管理情報の作成の際、そのホストサーバ１１００のサーバ固有情報を使って作成しても良いし、サーバ管理者にサーバ固有情報やシステム領域１６２の情報を入力させても良い。また、一時管理バッファ更新プログラム１１８２実行時に作成した内容を管理サーバ１１８０内に保存させておき、その内容を使用しても良い。また、実施例２と同様に起動制御フラグを格納しても良い。

起動管理情報の作成を終えると、ホストサーバ１１００の管理用コントローラ１０３に、管理用ネットワークを介して、起動管理テーブル１１０９に格納する起動管理情報を送信することを通知する（ステップ１４０３）。管理用コントローラ１０３はこの通知を受けて、ステップ１４０４で受信する起動管理情報の書き込み準備を行う。

実施例２と同様に、更新する前の起動管理テーブル１１０９の情報を受信して、起動管理テーブル１１０９を表示して、更新してよいかサーバ管理者に問い合せても良い。

起動管理テーブル更新プログラム１１８１は、管理用ネットワークを介して、ホストサーバ１１００に作成した起動管理情報を送信し、管理用コントローラ１０３に起動管理テーブル１１０９への書き込みを実施させる（ステップ１４０４）。

送信が完了したことを出力し、起動管理テーブル更新プログラム１１８１の実行を終える（ステップ１４０５）。

本実施例における起動制御のフローについて、実施例２の図１０と比較して異なる点を、以下説明する。ホストサーバ１１００の電源投入時に、ボリューム管理領域プログラム１１０６は、起動用ＬＶとして設定されているＬＶ１６０のボリューム管理領域１６１に格納されている起動管理情報と、起動管理テーブル１１０９に格納されている起動管理情報の一致比較を実行する。

以上により、起動用ＬＶ１６０のボリューム管理領域１６１に格納されている起動管理情報と、ホストサーバ１１００の起動管理テーブル１１０９の起動管理情報の一致比較を行うことで、サーバ管理者の意図していないＬＶに格納されているＯＳのホストサーバ１１００による起動抑止が可能となる。

本実施例では、管理サーバ１１８０内で起動管理情報を扱うことで、同様の管理情報をボリューム管理領域１６１と起動管理テーブル１１０９に格納可能である。これにより、サーバ管理者の入力ミスの低減が可能となる。

さらに、ホストサーバ１１００が管理サーバ（管理計算機）であって、ホストサーバ１１１０がホストサーバ１１００に起動管理情報を送信してもよい。

本実施例では、実施例１〜３で示した起動管理情報を利用した起動制御を、仮想サーバ上で実現する場合を示す。

図１５は、起動用ＬＶとして指定したＬＶに格納されているＯＳの仮想サーバによる起動を可能にする際の構成を示した図である。仮想サーバ１５１０、１５２０上で起動制限を行うシステムは、仮想システムファームウェア１５１３、１５２３が実施例１〜３で示したフローを実行するように構成されていれば良い。図１５には示していないが、仮想システムファームウェア１５１３、１５２３にはボリューム管理領域更新プログラムとボリューム管理領域チェックプログラムが格納されているものとする。

ホストサーバ１５００は仮想化機構１５０５を実行し、その上で仮想サーバ１５１０、１５２０を実行する。図１５では、仮想サーバが２台記載されているが、３台以上存在していても良い。

まず、仮想サーバ１５１０上で実施例１と同様のフローを実現する場合の例を示す。

仮想化機構１５０５は、仮想サーバ１５１０上で実行される仮想ディスクアダプタ１５１１や仮想ＮＩＣ１５１２や仮想システムファームウェア１５１３の状態を管理する。また、仮想化機構１５０５は、仮想ディスクアダプタ１５１１に付与されている仮想ＷＷＮ、仮想ＮＩＣ１５１２に付与されている仮想ＭＡＣアドレス、仮想システムファームウェア１５１３に付与されている仮想ＵＵＩＤなどの仮想ホストサーバ１５１０におけるサーバ固有情報を保持している。このサーバ固有情報は、仮想システムファームウェア１５１３から参照可能である。

図３及び図５のフローを仮想システムファームウェア１５１３上で実行する際、ホストサーバ１５００のシステムファームウェア１５０４上で実行する際と比較して、異なる点を以下説明する。ホストサーバ１５００上で実現する場合との差異は、仮想サーバ１５１０のサーバ固有情報を仮想化機構１５０５が管理していることである。

従って、ステップ５０４において、仮想システムファームウェア１５１３上のボリューム管理領域チェックプログラムは、管理用コントローラ１０３からサーバ固有情報を読み込むのではなく、仮想化機構１５０５からサーバ固有情報を読み込むものとする。

以上により、実施例１と同様に、起動用ＬＶのボリューム管理領域に格納されているサーバ固有情報と、仮想サーバ１５１０のサーバ固有情報の一致比較を行うことで、サーバ管理者が意図しないＬＶに格納されているＯＳからの仮想サーバ１５１０による起動を抑止可能である。

次に、仮想サーバ１５１０上で実施例２と同様のフローを実現する場合の例を示す。図１５には示していないが、実施例２で示した起動管理テーブル更新プログラム６０７、６１７と同様の起動管理テーブルを読み書きするためのプログラムが、仮想システムファームウェア１５１３内に格納されているものとする。

仮想化機構１５０５は、各仮想サーバ１５１０、１５２０上でアクセス可能なように、仮想ＮＶＲＡＭ１５１４、１５２４を仮想サーバ１５１０、１５２０に提供する。

ＮＶＲＡＭ１５５０には、全ての仮想サーバ１５１０、１５２０に対する起動管理テーブルが格納されている。仮想化機構１５０５は、ＮＶＲＡＭ１５５０内の起動管理テーブルを仮想サーバ１５１０、１５２０ごとに振り分け、前記振り分けた起動管理テーブルを各仮想ＮＶＲＡＭ１５６１、１５７１に格納する。

仮想システムファームウェア１５１３内の起動管理テーブルを読み書きするプログラムは、仮想ＮＶＲＡＭ１１６１、１１７１内に格納されている起動管理テーブルに対して、起動管理情報の読み書きを行う。尚、仮想サーバ１５１０のサーバ固有情報は、既に示したように、仮想化機構１５０５から読み込むものとする。

起動制御の処理は実施例２と同様に、図８と図１０のフローを実行すれば良い。

このように、実施例２と同様に、起動管理情報を使用することで、サーバ管理者の意図していないＬＶに格納されているＯＳの仮想サーバ１５１０による起動を抑止可能となる。

さらに、仮想サーバ１５１０上で実施例３と同様のフローを実現する場合の例を示す。

ＮＶＲＡＭ１５５０には、全ての仮想サーバ１５１０、１５２０に対する起動管理テーブルと一時管理バッファが格納されている。仮想化機構１５０５は、ＮＶＲＡＭ１５５０内の起動管理テーブルと一時管理バッファを仮想サーバ１５１０、１５２０ごとに振り分け、前記振り分けた起動管理テーブルと一時管理バッファを各仮想ＮＶＲＡＭ１５６１、１５７１に格納する。

起動制御の処理は実施例３と同様に、図１２と図１３と図１４のフローを実行すれば良い。

このように、実施例３と同様に、管理サーバを使用して、サーバ管理者の意図していないＬＶに格納されているＯＳの仮想サーバ１５１０による起動を抑止可能となる。

以上のように、起動用ＬＶのボリューム管理領域に格納されている起動管理情報と、仮想サーバ１５１０の起動管理テーブルの起動管理情報の一致比較を仮想サーバ１５１０上で行うことで、サーバ管理者の意図していないＬＶに格納されているＯＳの仮想サーバ１５１０による起動の抑止が可能となる。

尚、以上の実施例１〜４で示した方法の一部を組み合わせて、ホストサーバあるいは仮想サーバによる起動制限を実施しても良いものとする。

１００ ホストサーバ１
１０１および１１１ ディスクアダプタ
１０２および１１２ ＮＩＣ
１０３および１１３ 管理用コントローラ
１０４および１１４ システムファームウェア
１０５および１１５ ボリューム管理領域チェックプログラム
１０６および１１６ ボリューム管理領域更新プログラム
１１０ ホストサーバ２
１５０ ストレージ装置
１６０ ＬＶ１
１６１ ボリューム管理領域１
１６２ システム領域１
１７０ ＬＶ２
１７１ ボリューム管理領域２
１７２ システム領域２
２０１ ＣＰＵ
２０２ メモリ
２０３ バス制御装置
２０４ ＮＶＲＡＭ
２１１ ＷＷＮ
２１２ ＭＡＣアドレス
２１３ ＵＵＩＤ
３０１ないし３０７ 処理ステップ
４０１ ボリューム管理領域内データ
５０１ないし５０８ 処理ステップ
６００ ホストサーバ１
６０４および６１４ システムファームウェア
６０５および６１５ ボリューム管理領域チェックプログラム
６０６および６１６ ボリューム管理領域更新プログラム
６０７および６１７ 起動管理テーブル更新プログラム
６０８および６１８ ＮＶＲＡＭ
６０９および６１９ 起動管理テーブル
６１０ ホストサーバ２
７０１ ボリューム管理領域内データ
８０１ないし８０７ 処理ステップ
９０１ 起動管理テーブル内データ
１００１ないし１００８ 処理ステップ
１１００ ホストサーバ１
１１０４および１１１４ システムファームウェア
１１０５および１１１５ ボリューム管理領域チェックプログラム
１１０６および１１１６ ボリューム管理領域更新プログラム
１１０７および１１１７ ＮＶＲＡＭ
１１０８および１１１８ 一時管理バッファ
１１０９および１１１９ 起動管理テーブル
１１１０ ホストサーバ２
１１８０ 管理サーバ
１１８１ 起動管理テーブル更新プログラム
１１８２ 一時管理バッファ更新プログラム
１２０１ないし１２０５ 処理ステップ
１３０１ないし１３０７ 処理ステップ
１４０１ないし１４０５ 処理ステップ
１５００ ホストサーバ
１５０４ システムファームウェア
１５０５ 仮想化機構
１５１０ 仮想サーバ１
１５１１および１５２１ 仮想ディスクアダプタ
１５１２および１５２２ 仮想ＮＩＣ
１５１３および１５２３ 仮想システムファームウェア
１５１４および１５２４ 仮想ＮＶＲＡＭ
１５２０ 仮想サーバ２
１５５０ ＮＶＲＡＭ

Claims (19)

1. 複数の計算機と接続され、何れかの計算機で起動するオペレーティングシステムが格納される記憶部と、
   前記記憶部に前記何れかの計算機を識別する起動管理情報を格納するファームウェアを有する第一の計算機と、
   アクセスした前記記憶部に自身の計算機を識別する起動管理情報が格納されているか否かを判定するファームウェアを有し、前記判定において前記自身の計算機を識別する起動管理情報が格納されている場合、前記アクセスした記憶部に格納される前記オペレーティングシステムを起動する第二の計算機とを備えることを特徴とする計算機システム。
2. 前記第二の計算機の前記ファームウェアは、前記アクセスした記憶部に前記何れかの計算機を識別する起動管理情報が格納されているか否かを判定する第一の判定と、前記第一の判定で前記何れかの計算機を識別する起動管理情報が格納されていると判定した場合に前記何れかの計算機を識別する起動管理情報と自身の計算機を識別する識別情報とが対応するか否かを判定する第二の判定とを実行し、
   前記第二の判定において前記何れかの計算機を識別する起動管理情報と前記識別情報とが対応する場合、前記アクセスした記憶部に前記自身の計算機を識別する起動管理情報が格納されていると判定することを特徴とする請求項１記載の計算機システム。
3. 前記記憶部は、前記複数の計算機と接続されるストレージ装置の記憶領域を論理的に分割した論理ボリュームであって、前記何れかの計算機で起動するオペレーティングシステムが格納されるシステム領域と、前記第一の計算機により前記何れかの計算機を識別する起動管理情報が格納されるボリューム管理領域とを有し、
   前記アクセスした記憶部は、前記第二の計算機からのアクセス許可が設定された論理ボリュームであることを特徴とする請求項２記載の計算機システム。
4. 前記第一の判定により、前記アクセスした記憶部に前記何れかの計算機を識別する起動管理情報が格納されていない場合、前記第二の計算機は前記アクセスした記憶部に格納されるオペレーティングシステムの起動を抑止することを特徴とする請求項３記載の計算機システム。
5. 前記第二の判定により、前記アクセスした記憶部に格納されている起動管理情報と前記識別情報とが対応しない場合、前記第二の計算機は前記アクセスした記憶部に格納されるオペレーティングシステムの起動を抑止することを特徴とする請求項３記載の計算機システム。
6. 前記第二の計算機を識別する起動管理情報は、前記第二の計算機固有の識別子と、前記第二の計算機が有するディスクアダプタ固有の識別子と、前記第二の計算機が有するインターフェースカード固有の識別子と、前記第二の計算機で起動する前記オペレーティングシステムの識別子と、前記オペレーティングシステム上で実行されるアプリケーションの識別子と、前記オペレーティングシステム上で使用されるドライバの識別子と、の少なくとも何れかを含むことを特徴とする請求項３記載の計算機システム。
7. 前記計算機システムは、前記第二の計算機を識別する起動管理情報を前記第一の計算機に送信し、前記識別情報を前記第二の計算機に送信する管理計算機を有することを特徴とする請求項３記載の計算機システム。
8. 前記第一の計算機は、前記識別情報を前記第二の計算機に送信することを特徴とする請求項３記載の計算機システム。
9. 前記第二の計算機は、複数の前記識別情報と、前記識別情報に付与する起動制御フラグとを有し、
   前記第二の計算機の前記ファームウェアは、前記第二の判定として、前記起動制御フラグが付与された前記識別情報と前記アクセスした記憶部に格納されている起動管理情報との対応を判定することを特徴とする請求項３記載の計算機システム。
10. 前記第二の計算機は、物理計算機が有する仮想化機構上の仮想計算機であって、
    前記仮想化機構は、前記第二の計算機を識別する識別情報を有し、
    前記第二の計算機は、前記仮想化機構から前記第二の計算機を識別する識別情報を取得することを特徴とする請求項３記載の計算機システム。
11. 前記第二の計算機は、前記第一の判定により、前記アクセスした記憶部に前記何れかの計算機を識別する起動管理情報が格納されていない場合、または前記第二の判定により、前記アクセスした記憶部に格納されている起動管理情報と前記識別情報とが対応しない場合、エラーを提示することを特徴とする請求項３記載の計算機システム。
12. 記憶部と接続するディスクアダプタと、アクセスした前記記憶部に自身の計算機を識別する起動管理情報が格納されているか否かを判定し、前記判定において前記自身の計算機を識別する起動管理情報が格納されている場合、前記アクセスした記憶部に格納されるオペレーティングシステムを起動するファームウェアとを備えることを特徴とする計算機。
13. 前記ファームウェアは、前記アクセスした記憶部に自身または他の計算機を識別する起動管理情報が格納されているか否かを判定する第一の判定と、前記第一の判定で前記自身または他の計算機を識別する起動管理情報が格納されていると判定した場合に前記自身または他の計算機を識別する起動管理情報と自身の計算機を識別する識別情報とが対応するか否かを判定する第二の判定とを実行し、
    前記第二の判定において前記自身または他の計算機を識別する起動管理情報と前記識別情報とが対応する場合、前記アクセスした記憶部に前記自身の計算機を識別する起動管理情報が格納されていると判定することを特徴とする請求項１２記載の計算機。
14. 前記第一の判定で、前記アクセスした記憶部に前記自身または他の計算機を識別する起動管理情報が格納されていない場合、または前記第二の判定で、前記アクセスした記憶部に格納されている前記起動管理情報と前記識別情報とが対応しない場合、前記アクセスした記憶部に格納されるオペレーティングシステムの起動を抑止することを特徴とする請求項１３記載の計算機。
15. 前記第一の判定により、前記アクセスした記憶部に前記自身または他の計算機を識別する計算機を識別する起動管理情報が格納されていない場合、または前記第二の判定により、前記アクセスした記憶部に格納されている起動管理情報と前記識別情報とが対応しない場合、エラーを提示することを特徴とする請求項１３記載の計算機。
16. 複数の計算機と、何れかの計算機で起動するオペレーティングシステムが格納される記憶部とを備える計算機システムの起動方法であって、
    第一の計算機は、前記記憶部に、前記何れかの計算機を識別する起動管理情報を格納し、
    第二の計算機は、前記第二の計算機から参照可能な記憶部にアクセスし、前記アクセスした記憶部に自身の計算機を識別する起動管理情報が格納されているか否かを判定し、前記判定において前記自身の計算機を識別する起動管理情報が格納されている場合、前記アクセスした記憶部に格納される前記オペレーティングシステムを起動することを特徴とする計算機システムの起動方法。
17. 前記第二の計算機は、前記アクセスした記憶部に前記何れかの計算機を識別する起動管理情報が格納されているか否かを判定する第一の判定と、前記第一の判定で前記何れかの計算機を識別する起動管理情報が格納されていると判定した場合に前記何れかの計算機を識別する起動管理情報と自身の計算機を識別する識別情報とが対応するか否かを判定する第二の判定とを実行し、
    前記第二の判定において前記何れかの計算機を識別する起動管理情報と前記識別情報とが対応する場合、前記アクセスした記憶部に前記自身の計算機を識別する起動管理情報が格納されていると判定することを特徴とする請求項１６記載の計算機システムの起動方法。
18. 前記記憶部はシステム領域とボリューム管理領域とを有し、
    前記第一の計算機は、前記第二の計算機で起動するオペレーティングシステムがシステム領域に格納される記憶部のボリューム管理領域に、前記第二の計算機を識別する起動管理情報を格納し、
    前記第二の計算機は、前記第一の判定として、前記アクセスした記憶部のボリューム管理領域に前記何れかの計算機を識別する起動管理情報が格納されているか否かを判定し、
    前記第一の判定により、前記アクセスした記憶部のボリューム管理領域に前記何れかの計算機を識別する起動管理情報が格納されている場合、前記第二の計算機は前記第二の判定を実行することを特徴とする請求項１７記載の計算機システムの起動方法。
19. 前記第一の判定により、前記アクセスした記憶部に前記何れかの計算機を識別する起動管理情報が格納されていない場合、または前記第二の判定により、前記アクセスした記憶部に格納されている起動管理情報と前記自身の計算機を識別する識別情報とが対応しない場合、前記第二の計算機は前記アクセスした記憶部に格納されるオペレーティングシステムの起動を抑止することを特徴とする請求項１７記載の計算機システムの起動方法。

Images