JP2009199224A - システムボリューム予約方法及びその方法を用いた計算機システム - Google Patents

Abstract

【課題】複数の計算機が、同一のシステムボリュームから多重にＯＳを起動しないように制御する。
【解決手段】ボリュームがＯＳ起動のためのシステムボリュームとして予約されているか否かを示すロックデータをボリューム内に保持し、計算機はＯＳを起動する前に、ボリューム内に保持されているロックデータがシステムボリュームとして予約されていないことを示すとき、システムボリュームとして予約されていることを示すデータをロックデータとして書き込み、ロックデータがシステムボリュームとして予約されていることを示すとき、ボリュームへのアクセスを停止する。
【選択図】図１

Description

本発明は、計算機システムの起動手順に関する。

複数の計算機で共有可能なストレージ装置が普及している。一般に、共有可能なストレージ装置は、ファイバチャネルプロトコルと呼ばれるプロトコルで計算機に接続する。ストレージ装置と計算機はファイバチャネルスイッチと呼ばれる装置を介して接続し、ファイバチャネルスイッチが計算機とストレージ装置間のトラフィックを制御する。一般に、このように構成されたストレージのシステムは、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）と呼ばれる。

ストレージ装置内の記憶領域はボリュームと呼ばれる論理的な記憶領域に分割され、各ボリュームは計算機からは通常のディスク装置と同じに見える。一般に、ファイバチャネルスイッチやストレージ装置はアクセス制御の機能を有しており、ＳＡＮに接続する各計算機からアクセス可能なストレージ装置やボリュームを制限できる。

ボリュームへのアクセス制限を実現する別の方法として、ストレージ装置へアクセスする際のプロトコルの機能を利用する方法がある。これを利用するシステムとして現用系と待機系との計算機からなるクラスタシステムがある。クラスタシステムでは、現用系と待機系に構成された計算機が同時に共有ボリュームにアクセスしないように、クラスタ制御ソフトウェアがアクセス制御を実施する。具体的には、クラスタ制御ソフトウェアは、ストレージ装置にアクセスするプロトコルが用意しているターゲット予約コマンドを利用して、現用系である計算機からのみ共有ボリュームにアクセス可能となるように制御している。

計算機は、このようなストレージ装置内のボリュームからOSを計算機に読み込み、起動するように構成することができる。このブート（bootstrap）方式は、ＳＡＮブートと呼ばれる。

これらのＳＡＮの技術は、計算機の仮想化技術と組み合わせて利用することもできる。例えば、ストレージ装置内のボリュームをシステムボリュームとして仮想計算機に割り当てて、そこに格納されているOSを読み込むことによって仮想計算機を起動できる（特許文献1）。特許文献１には、仮想化環境におけるボリュームのアクセス制限機構も示されている。

計算機の仮想化においては、I/O仮想化のオーバーヘッドを低減するために、物理計算機に接続しているI/Oアダプタを仮想計算機から直接アクセス可能とする技術がある（非特許文献１）。これを用いると、仮想計算機は仮想計算機モニタ（ＶＭＭ）を介さずにストレージ装置のボリュームにアクセス可能となり、仮想計算機のI/O性能を向上できる。

米国特許7,269,683号，” Providing access to a raw data storage unit in a computer system” "AMD I/O Virtualization Technology (IOMMU) Specification," pp.14, "2.2.5 Virtual Machine Guest Access to Devices," [online], 2006年2月掲載，米国AMD社，2006年7月24日検索，インターネット<URL:http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/34434.pdf>

ストレージ装置内にあるボリュームを複数の計算機が同時期にアクセス制御なしで利用すると、一般に、ボリューム内容が破壊される。特に、OSが格納されているボリューム（システムボリューム）が破壊されると、計算機が起動不能になるという課題がある。このため、複数の計算機から多重のアクセスが同一のボリューム(共有ボリューム)に発生しないように、様々のアクセス制御機構が用いられる。

計算機の仮想化においてストレージアクセスが仮想化されている場合は、仮想化機構（仮想計算機モニタ又はハイパバイザと呼ばれる。）が仮想計算機に見せるボリュームへのアクセスを制御できるため、仮想化機構によって多重アクセスを禁止することができる。特許文献１では、ボリュームを仮想計算機に見せるためのデータの中に排他制御のためのデータを設け、このデータを用いて同一のボリュームを多重に使用することを禁止している。これによって、ストレージアクセスが仮想化されている場合のシステムボリュームの多重使用による破壊を防止できる。しかしながら、仮想計算機がI/Oアダプタを直接操作するような場合、I/O操作に仮想化機構が介在しないため、仮想化機構の排他制御が効かないという課題がある。

また、仮想計算機のシステムボリュームが物理計算機のシステムボリュームとしても利用可能な場合、仮想化機構が提供する排他制御は物理計算機では効果がないという課題がある。

クラスタシステムで用いられるアクセスプロトコルによるターゲット予約の方式では、予約したボリュームを他の計算機からアクセス不能にできる。一方、ボリュームを予約した計算機が不正に停止すると、このボリュームにアクセスするためにはストレージ装置の側で予約状態を解除しなければならず、また、予約されている状態ではボリュームの内容を他の計算機から参照することもできないという、運用上の課題がある。また、予約を解除するためにはターゲットのリセットが必要であるが、誤って予約を解除すると、予約していた計算機は予期していないリセットのためエラーを生じる可能性もある。

ＳＡＮのスイッチやストレージ装置の機能によって、計算機からアクセス可能なボリュームを制限することができる。このアクセス制限は、計算機に搭載されているI/Oアダプタに付与されている識別子(ＷＷＮ：World Wide Name)に基づいて設定される。計算機が仮想化される場合、このＷＷＮも仮想的に付与される。このため、不正な設定がされた場合に複数の仮想計算機が同じＷＷＮを持つ可能性がある。同じＷＷＮを持っているI/Oアダプタが不正に存在する場合、ＳＡＮのアクセス制御機構は有効に働かず、複数の仮想計算機から多重にボリュームにアクセス可能となってしまう課題がある。このような環境では、アクセスプロトコルによるターゲット予約も効果がないという点も課題である。

以上のような個々の課題を共通的に見ると、仮想化機構により構成される仮想計算機または物理計算機といった複数の計算機が、同一のシステムボリュームから多重にＯＳを起動しないようにする必要がある。

本発明の態様のシステムボリューム予約方法は、計算機と他の計算機とからアクセス可能なボリュームをＯＳ起動のためのシステムボリュームとして予約する方法である。ボリュームがＯＳ起動のためのシステムボリュームとして予約されているか否かを示すロックデータをボリューム内に保持し、計算機はＯＳを起動する前に、ボリューム内に保持されているロックデータを参照し、ロックデータがシステムボリュームとして予約されていないことを示すとき、システムボリュームとして予約されていることを示すデータをロックデータとして書き込み、ロックデータがシステムボリュームとして予約されていることを示すとき、ボリュームへのアクセスを停止する。

本発明の望ましい他の態様は、システムボリュームとして予約されていることを示すデータには、少なくとも計算機を識別するデータを含む。

本発明の望ましいさらに他の態様は、システムボリュームとして予約されていることを示すデータを書き込んでから所定時間経過後にロックデータが書き込んだデータであるとき、計算機はＯＳを起動する。

本発明のさらに他の態様である計算機システムは、ＯＳ起動のためのシステムボリュームとして予約されているか否かを示すロックデータとＯＳを格納するボリュームを構成するストレージ、及びストレージに接続し、ボリューム内に格納されているロックデータを参照し、ロックデータがシステムボリュームとして予約されていないことを示すとき、システムボリュームとして予約されていることを示すデータをロックデータとして書き込み、ロックデータがシステムボリュームとして予約されていることを示すとき、ボリュームへのアクセスを停止する計算機を有する。

本発明の望ましいさらに他の態様は、ボリューム内に格納されているロックデータを参照し、ロックデータがシステムボリュームとして予約されていないことを示すとき、システムボリュームとして予約されていることを示すデータをロックデータとして書き込み、所定時間経過後にロックデータが書き込んだデータであるとき、ＯＳを起動し、ロックデータがシステムボリュームとして予約されていることを示すとき、ボリュームへのアクセスを停止する処理を、計算機がファームウェアとして実装する。

本発明の望ましいさらに他の態様は、計算機が仮想計算機システムであり、ファームウェアは仮想計算機システムを制御する仮想化機構に実装される。

本発明によれば、仮想化機構により構成される仮想計算機または物理計算機といった複数の計算機が、同一のシステムボリュームから多重にＯＳを起動しないように制御できる。

以下に本発明の実施の形態について説明する。以下の実施の形態では、システムボリューム内の一部の領域をＯＳの多重起動を防止する排他制御用の制御情報を格納する排他制御領域、この排他制御領域のデータをロックデータとし、計算機起動時の処理の多重起動防止処理がその排他制御領域にアクセスして、計算機の起動可否を判定する方法およびそれを実装する計算機システムを示す。

本実施例では、物理計算機がシステムボリュームからＯＳを起動する際に、同一ボリュームから複数の計算機が多重にＯＳを起動するのを防止することを示す。

図２は、本実施例のシステムの構成例を示す。この例では、サーバ計算機２００、２１０および２２０が、ＳＡＮのストレージスイッチ２６０を介してストレージ装置２７０に接続している。各計算機はスイッチ２６０に接続するためのディスクアダプタを有している。

サーバ計算機２００は仮想化機構２５０を有し、仮想計算機２３０と２４０を実行させる仮想計算機システムである。仮想化機構２５０はファームウェア又はソフトウェアによって実現される。仮想化機構２５０は、その上で実行する仮想計算機２３０と２４０に仮想的なディスクアダプタを提供する。仮想計算機２３０と２４０は、仮想化機構２５０が作り出した仮想的なディスクダプタを持ち、それによってスイッチ２６０を介してストレージ装置２７０内のボリュームにアクセス可能となっている。仮想化機構２５０は、仮想計算機２３０と２４０から仮想ディスクアダプタへのアクセスを、計算機２００に搭載の物理的なディスクアダプタへのアクセスに変換して、仮想計算機２３０と２４０からのストレージ装置２７０内のボリュームへのアクセスを実現している。仮想計算機２３０と２４０からのスイッチ２６０への仮想的な接続は、図２では破線にて示している。

ストレージ装置２７０には、各サーバ計算機がシステムボリュームとして利用するボリューム２７１〜２７４が構成されている。それぞれの計算機のシステムボリュームは、計算機２１０がＶＯＬ１（２７１）、計算機２２０がＶＯＬ２（２７２）、仮想計算機２３０がＶＯＬ３（２７３）、仮想計算機２４０がＶＯＬ４（２７４）であるとして説明する。

ストレージスイッチ２６０とストレージ装置２７０は、各ボリュームが予め定めた計算機からのみ利用可能なようにアクセス権を設定することができる。このアクセス権は、計算機に搭載のディスクアダプタに付与されている識別子を基準に設定できる。例えば、ファイバチャネルによるＳＡＮであれば、ＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）といった識別子によって、各計算機からアクセス可能なストレージ装置およびボリュームを定義できる。

図３は、本実施例での計算機の構成例を示す図である。図３には、サーバ計算機２１０の構成を示したが、他の物理計算機も同様の構成である。

計算機２１０は、ＣＰＵ３０１、メモリ３０２、ディスクアダプタ３０４、ネットワークアダプタ３０５、システムファームウェア３０６等が、バス制御装置３０３を介して接続している。システムファームウェア３０６は、計算機２１０の起動時に実行するプログラムを格納しているＲＯＭであるが、以下では格納されているプログラム又はそのプログラムによる処理をシステムファームウェア３０６と呼ぶことがある。計算機２１０のＣＰＵ３０１は、システムファームウェア３０６内の予め定められたアドレスに格納されている処理から実行を開始する。この処理は、計算機に搭載されているＩ／Ｏデバイスの初期化等を実施し、起動用として予め指定されたボリュームの特定領域の内容をメモリ３０２に読み込み、そのボリュームに格納されているＯＳを起動する（厳密には、OSをメモリ３０２に読み込み、実行を開始させる。）。以下の説明では、ＣＰＵ３０１がメモリ３０２、あるいは、ファームウェア３０６に格納されているプログラムを実行することを、そのプログラムが実行するとして説明する。

ディスクアダプタ３０４もアダプタファームウェア３０７を搭載している。アダプタファームウェア３０７はディスクアダプタ３０４上のＲＯＭに搭載されているが、システムファームウェア３０６と同様に、ＣＰＵ３０１がその中のプログラムを実行可能な（メモリ302に読み込み実行する）ように構成されている。アダプタファームウェア３０７は、ディスクアダプタ３０４を介してストレージ装置２７０にアクセスする手順を格納している。システムファームウェア３０６は、システムボリュームがディスクアダプタ３０４を介して接続している場合、アダプタ３０４のファームウェア３０７のディスクアクセス手順を呼び出すことによって、所定のシステムボリュームにアクセスする。

ネットワークアダプタ３０５は、ネットワークスイッチ３１０及びネットワーク３２０を介して、他の計算機などと通信するための装置である。

次に、本実施例の計算機のシステムボリューム予約処理について説明する。図１は、本実施例における計算機のシステムボリューム予約処理に関わる要素を示した図である。図１は、計算機２１０内の構成、ストレージ装置２７０との接続、システムボリューム２７１の内容を示した図である。図１ではストレージスイッチ２６０は省略している。

システムファームウェア３０６は、計算機２１０の起動時に実行するＯＳブート処理部１０１、計算機２１０に接続するボリュームにアクセスするためのインタフェースを提供するディスクアクセスインタフェース１０２、および、計算機２１０のシャットダウンの直後に実行するシャットダウン後処理部１０３を実装している。また、システムファームウェア３０６は、計算機２１０のリセット後にシャットダウン後処理１０３の実行を要求するフラグ１０４、リセット後動作データ１０５を実装する。フラグ１０４とデータ１０５は、実際にはメモリ３０２の所定のアドレスに実装される。

ディスクアクセスインタフェース１０２は、システムファームウェア３０６や他のソフトウェアに対して、計算機２１０に接続するボリュームの内容を読み書きするインタフェースを提供する。ＯＳ起動に際して、ＯＳブート処理部１０１は、ディスクアクセスインタフェース１０２を呼び出す。インタフェース１０２は、ＯＳ起動前のボリュームアクセス手順（ＯＳが関与せずにボリュームへアクセスする手順）も実装している。

実際のボリュームにアクセスする手順は、ディスクアダプタ３０４のアダプタファームウェア３０７に格納されている。システムファームウェア３０６は、計算機２１０を起動する際に、ディスクアクセスインタフェース１０２がアダプタファームウェア３０７のディスクアクセス部１１０を呼び出すように構成している。

ディスクアクセス部１１０は、ディスクアダプタ３０４によって実際にストレージ装置２７０のボリュームにアクセスするための手順を実装している。

本実施例では、アダプタファームウェア３０７は、ディスクアクセス済みフラグ１１１を持っている。このフラグ１１１は、計算機２１０が起動してから、アダプタ３０４のアダプタファームウェア３０７によるボリュームへのアクセスがあったかどうかを記録している。より具体的には、ディスクアクセス済みフラグ１１１は、ディスクアクセス部１１０によるボリュームアクセスが、計算機起動後の初回のアクセスか、そうでないかを記録するためのフラグである。

アダプタファームウェア３０７自体はディスクアダプタ３０４内にＲＯＭとして実装されるのが一般的であるが、ファームウェア３０７はディスクアクセス済みフラグ１１１をＲＡＭ領域であるメモリ３０２内に配置する。フラグ１１１は、計算機２１０の起動（電源オンやリセットボタンなどによるハードウエアリセット）時にディスクアクセスが実行されていないことを示す値にクリアされる。

本実施例では、システムボリューム２７１は、ボリューム２７１内の各パーティションの位置(アドレス)やサイズを記録しているパーティションテーブル１２１、ファームウェアが利用するデータを格納するファームウェア領域（１２２）、ＯＳが格納されているシステム領域（１２３）から成る。ファームウェア領域（１２２）やシステム領域（１２３）の位置やサイズはパーティションテーブル１２１に格納されている。このうち、ファームウェア領域１２２には、システムボリューム２７１がＯＳ起動ボリュームとして多重に利用されないように排他制御するためのボリュームロックデータ１３０を含んでいる。ロックデータ１３０は、ＯＳ上からもアクセス可能であるが、運用上書き込み禁止としておくことが望ましい。

図４に計算機２１０の起動処理のフローチャートを示す。

計算機２１０が起動（電源オンやリセットボタンなどによるハードウエアリセット）すると、後に図６を用いて説明する処理ステップを経て、システムファームウェア３０６内のＯＳブート処理部１０１が実行する。ＯＳブート処理部１０１は、システムボリュームと設定されているボリューム２７１のパーティションテーブル１２１を読み込むために、ディスクアクセスインタフェース１０２を呼び出す（ステップ４０１）。システムボリュームは、システムファームウェア３０６のパラメータとして予め定義されている。また、パーティションテーブル１２１は、ボリューム２７１内の所定の位置に存在している。

インタフェース１０２は、実際のディスクアクセスを実行するためにアダプタ３０４のファームウェア３０７のディスクアクセス部１１０を呼び出す（ステップ４０２）。

ディスクアクセス部１１０は、実際にボリューム２７１にアクセスしてパーティションテーブル１２１をメモリ３０２に読み込む処理を実行する（ステップ４０３）。この際、ディスクアクセス部１１０は、そのディスク読み込みが、計算機２１０が起動（電源オンやリセットボタンなどによるハードウエアリセット）してから初めてのディスクアクセスであるかどうかを判定する。初めてならばそのボリュームをシステムボリュームとして予約している（起動している）他の計算機がないかを検査する。この処理については、後述する。

既に起動している他の計算機があると判定される場合、ディスクアクセス部１１０はディスクリード処理を失敗させる。そうでなければ、ディスクリードを実行する。

ＯＳブート処理部１０１は、ディスクアクセス部１１０によるステップ４０３の処理の終了後にディスクリードが成功したかどうかを判定する（ステップ４０４）。ディスクアクセス部１１０がディスクリードに失敗した場合、ＯＳブート処理部１０１は計算機２１０の起動（ここでの起動は、以降のＯＳローダの実行、ＯＳの起動などを言う）を失敗させる（ステップ４０６）。失敗させるとは、たとえばボリューム２７１への以降のアクセスを止め、アクセスエラーのメッセージを出力する。成功した場合は、読み込んだパーティションテーブル１２１の内容を参照してシステム領域１２３の位置を取得して、システム領域に格納されているＯＳローダをロードして実行し、ＯＳを起動する（ステップ４０５）。

図５に、システムボリュームを排他的に予約する処理（図４のステップ４０３）のフローチャートを示す。この処理は、アダプタファームウェア３０７のディスクアクセス部１１０に実装される。以降では、ボリュームが多重にシステムボリュームとして利用されない状態におくことを、“システムボリュームとして予約する”と言うこととする。

ディスクアクセス部１１０は、ディスクアクセス済みフラグ１１１の内容を取得し（ステップ５０１）、その内容を検査して、計算機２１０が起動（電源オンやリセット）されてからディスクアクセスを実行したかどうかを判定する（ステップ５０２）。既にディスクアクセスが実行されている場合は、ディスクリード（パーティションテーブル１２１の読み込み）を実行し（ステップ５２２）、ディスクアクセスが成功したとして処理を終了する（ステップ５２３）。

初回アクセスであると判定した場合、ディスクアクセス部１１０はステップ５０３以降の処理で、システムボリュームの予約を試みる。ディスクアクセス部１１０は、ボリューム２７１のパーティションテーブル１２１を読み込んで、ファームウェア領域１２２の位置とサイズ等の情報を取得する（ステップ５０３）。ここでのボリュームの読み取り処理は、ディスクアクセスインタフェース１０２が持つ、前述のＯＳが関与せずにボリュームへアクセスする手順に基づいて、ディスクアクセス部１１０に直接指示を出すことによって実行する。

ファームウェア領域１２２の情報を取得後、ディスクアクセス部１１０は、システムボリューム予約処理で使用するロックデータを生成する（ステップ５０４）。生成するロックデータは、システムボリュームを予約しようとしている計算機をシステム全体で一意に識別可能な値を含む。このような値としては、計算機のＳＭＢＩＯＳ（Ｓｙｓｔｅｍ Ｍａｎａｇｅｍａｎｔ ＢＩＯＳ）と呼ばれるファームウェアが保持している計算機のＵＵＩＤがある。計算機のＵＵＩＤは、計算機の出荷時に設定される計算機を識別するための値で、ＳＭＢＩＯＳを搭載するすべての計算機で重複のないように設定される。ロックデータに、ＵＵＩＤに加えて、その時点の時刻を示す値を含めると、システムボリュームを予約した時刻を後に認識できるなど、運用上の利点が得られる。

次に、ディスクアクセス部１１０は、ファームウェア領域１２２内のボリュームロックデータ１３０を読み取る（ステップ５０５）。ボリュームロックデータ１３０は、ファームウェア領域１２２内で予め定められた位置に存在し、一度のディスクアクセスで読み取りや更新が可能なサイズのデータが望ましい。例えば、ボリュームを構成するディスクの１つのセクタがロックデータ１３０領域として定義される。２回以上のディスクアクセスで読み取りや更新するサイズであると、ボリュームロックデータ１３０を複数回に亘って読み込むことになり、その間に他の計算機からボリュームロックデータ１３０へのアクセスが発生する可能性があり、処理が複雑になるからである。本実施例ではディスクアクセスプロトコルによるターゲット予約の仕組みを使わないため、ＳＡＮのアクセス設定としてアクセスが許可されていれば、どの計算機からでもロックデータを読み取ることができる。

ディスクアクセス部１１０は、読み取ったロックデータ値が０でないか検査する（ステップ５０６）。０でない（読み取ったセクタに０でないデータが含まれる）場合は、ボリューム２７１はシステムボリュームとして利用中であると判定し、ディスクアクセスを失敗で終了させる（ステップ５１１）。

ロックデータが０（セクタの内容がすべて０）だった場合（システムボリュームとして予約されていないことを示す場合）、ロックデータ１３０にステップ５０４で生成したデータを書き込んで、ボリューム２７１をシステムボリュームとして予約することを試みる（ステップ５０７）。この書き込みも、ＳＡＮのアクセス設定が許可されていれば、複数の計算機から同時に（見かけ上の同時であり、厳密には前後関係になる）実行可能である。複数の計算機から同時に書き込まれた場合、ロックデータ１３０の内容は、最後に書き込まれた内容となる。

ロックデータの書き込み後、ディスクアクセス部１１０は、予め定めた一定時間待機する（ステップ５０８）。これは、ステップ５０５でのロックデータ１３０のリードにおいて、複数の計算機がロックデータとして０を取得した場合に、それらの計算機のすべてがステップ５０７でのロックデータへの書き込みが完了するのを待つためである。一般には、数秒待てば十分である。ある計算機がロックデータの書き込み後に、ロックデータを読み込んだ他の計算機は０以外の値を取得するため、ステップ５０６の判定により、ロックデータの書き込みを行わない。

一定時間の待機の後、ディスクアクセス部１１０は、再びロックデータ１３０をリードする（ステップ５０９）。ここで読んだ値がステップ５０４で生成した値（ロックデータとして書き込んだ値）と一致しない場合、ボリューム２７１をシステムボリュームとして予約できなかったとして、ディスクアクセスを失敗として処理を終了する（ステップ５１１）。

値が一致する場合、この計算機２１０がボリューム２７１をシステムボリュームとして予約できたとする。この場合は、ディスクアクセス済みフラグ１１１をセットして（ステップ５２１）ディスクリードを実行し（ステップ５２２）、ディスクアクセスが成功したとして終了する（ステップ５２３）。以上により、計算機２１０の起動時にシステムボリュームを排他的に予約可能となる。

次に、排他的に予約したシステムボリュームを、他の計算機からブート可能なように解放する手順を示す。具体的には、計算機２１０で実行するＯＳがシャットダウンした後で、システムボリュームを解放する処理を示す。

ＯＳがシャットダウンする時は、ＯＳがシャットダウン処理の過程でＩ／Ｏアダプタを停止する場合があるので、ディスクアダプタ３０４によるディスクアクセス処理は期待できない。そこで、本実施例では、シャットダウン後処理部１０３をシステムファームウェア３０６内に設ける。シャットダウン後処理部１０３は、ＯＳのシャットダウン直後、あるいは、リブートによる計算機再起動の直後に実行し、ボリューム２７１内のロックデータ１３０をクリアする。これによって、システムボリュームを他の計算機のシステムボリュームとして利用可能なように解放する。

図６は、ＯＳがシャットダウン、あるいは、リブート（再起動）する時の、システムボリューム予約を解放する処理フローチャートである。ＯＳは、シャットダウン処理の後に、計算機の電源をオフ、あるいは、リブートするようにシステムファームウェア３０６に指示を出す（ステップ６０１）。このような計算機の電源の制御は、システムファームウェア３０６に実装されるのが一般的である。

システムファームウェア３０６は、指示された動作として電源オフかリブートかをリセット後動作データ１０５に記録する（ステップ６０２）。リセット後にロックデータ１３０をクリアするシャットダウン後処理部１０３が実行するように、シャットダウン後処理要求フラグ１０４をセットして（ステップ６０３）、計算機２１０をリセットする（ステップ６０４）。電源オンや通常のリセットによる起動時にも要求フラグ１０４を使用するならば、その場合に設定される値とは異なる値を、電源をオフあるいはリブートの場合、要求フラグ１０４に設定する。

計算機２１０は、リセットされるとシステムファームウェア内の計算機起動処理を実行する。図６のステップ６０５からの処理は、その起動処理の一部である。図６に示すように、電源オンやハードウエアリセットの場合にも、ステップ６０５からの処理を実行する。

まず、リセット後動作データ１０５の内容を参照して、リセット前にシャットダウン後処理が要求されているか検査する（ステップ６０５）。要求されていない場合、つまり、電源オンやハードウエアリセットによりリセット後動作データ１０５は消去されているので、図４を用いて説明したように、通常の初期化処理の後、ＯＳブート処理を実行する（ステップ６０８）。

一方、シャットダウン後処理が要求されている場合は、ステップ６０６からのシャットダウン後処理を実行する。シャットダウン後処理部１０３は、リセット前の処理が電源オフかリセットかをリセット後動作データ１０５より取得し（ステップ６０６）、電源オフの場合は、ロックデータ１３０をゼロクリアする（ステップ６０７）。具体的には、システムボリュームとされているボリューム２７１のパーティションテーブル１２１を読み込んでファームウェア領域１２２の位置を取得して、その中のロックデータ１３０に０を書き込む。本実施例では簡単のために、システムボリュームとして予約されていないことを示す値を０としているが、予約されていないことを示す値として定めた値であれば良い。その後、計算機２１０の電源をオフにする（ステップ６０９）。図示しないが、電源オフによって、メモリ３０２にあるディスクアクセス済みフラグ１１１は消える。

リブートの場合はＯＳブート処理を実行する（ステップ６０８）。この場合、ディスクアクセス済みフラグ１１１がアクセス済みを示したままであり、ロックデータ１３０を計算機２１０が確保した状態が継続しているので、図５のステップ５０２の判定が、アクセス済みとなり、ディスクリードが成功したことになる。これにより、電源オンやハードウエアリセットのときよりも、リブートに伴う計算機２１０の再起動の方が短時間になる。

以上により、ストレージ装置内のボリュームを複数の計算機から多重にステムボリュームとして利用されることを防止できる。これによって、ストレージスイッチ２６０やストレージ装置２７０のアクセス権の設定が不正であっても、１つのボリュームがシステムボリュームとして多重に利用されることを抑止できる。また、ディスクアダプタ３０４には、アクセス権設定の基準となる識別子（ＷＷＮなど）を自由に設定可能な場合があるが、この設定が不正になってしまった場合、つまり、システム内に同一の識別子を持つディスクアダプタが存在しているような状態でも、ボリュームのシステムボリュームとしての多重使用を抑止できる。

本実施例は、共有しているボリューム２７１内のロックデータ１３０を利用した制御であり、多重使用の禁止のための制御情報を格納する、システムを構成するすべての計算機から参照可能なボリュームを設ける、あるいは、ネットワーク等の別の共通の制御パスを設ける必要がない。

また、本実施例では、ストレージのアクセスプロトコルによってデバイスを予約しないので、システムボリュームとして予約されたボリュームであっても、運用上、他の計算機から参照することが可能である。これによって、システムで障害が発生した場合などに迅速にボリュームを参照できることとなり、システムの障害解析や障害回復の作業の簡略化につながる。また、ＷＷＮが重複しうる環境でデバイス予約が有効に機能しない環境であっても、ＯＳの多重起動を抑止できる。

本実施例は、起動する計算機が、仮想化機構２５０により構成されている仮想計算機２３０の場合である。

計算機を起動する処理が仮想計算機２３０で行われる場合であっても、計算機の起動処理自体に変わりはない。したがって、計算機の起動処理としては、仮想化機構２５０が仮想計算機２３０に提供する論理的なファームウェアが、実施例１で説明したＯＳ起動処理（図４、図５）を実行するように構成されていれば良い。これによって、仮想計算機２３０は、起動する時にボリューム２７３をシステムボリュームとして予約できる。ただし、生成するロックデータは、実施例１ではシステムボリュームを予約しようとしている計算機を識別可能な値を含むようにしたが、仮想化機構２５０はＯＳを起動しようとしている仮想計算機２３０を識別可能な値を含むようにする。

仮想計算機２３０の停止後にボリューム２７３を解放する処理は、物理的な計算機での解放処理と異なり、仮想化機構２５０で実施することが可能である。計算機が仮想化されている場合、仮想計算機２３０の電源オフやリブートの処理は仮想化機構２５０が実施することとなる。つまり、図６のゲストＯＳが実行するステップ６０１の処理は仮想化機構２５０によってトラップ可能である。この処理の過程で、仮想化機構２５０は、当該の仮想計算機２３０のシステムボリュームであるボリューム２７３のロックデータをクリアし予約を解放することができる。

以上により、起動する計算機が仮想化機構による構成される仮想計算機であっても、ストレージ装置内のボリュームをシステムボリュームとして多重使用されないように排他的に予約することが可能となる。

本実施例は、仮想化機構のＩ／Ｏ仮想化に依存せずに、仮想計算機が利用するシステムボリューム上のロックデータにより多重使用を禁止できる。したがって、仮想計算機にディスクアダプタを直接アクセス可能なように割り当てる場合であっても、仮想化機構がＩ／Ｏをエミュレーションする場合であっても、同様に多重使用を禁止できる。これによって不正な構成の仮想計算機があって、ＳＡＮのアクセス制御が有効に効かない場合でも、１つのボリュームが多重にシステムボリュームとして利用されることを禁止できる。

仮想計算機の場合、同一の仮想計算機が多重に起動する場合も想定される。ロックデータ１３０に、ボリューム予約試行時のある程度の精度のある時刻を含めることで、同一の仮想計算機が複数の計算機から多重に起動することも防止できる。

本実施例では、仮想計算機で実行するＯＳが障害により停止した場合でも、システムボリュームを解放可能である。物理計算機で実行するＯＳが障害により停止した場合は、計算機を物理的にリセットしなければ回復しないため、実施例１に示したシャットダウン後処理部１０３を実行できないケースが存在する。一方、仮想計算機の場合は、ゲストＯＳが障害で停止した場合でも、仮想化機構２５０が仮想計算機２３０の状態を管理するため、仮想計算機２３０のリソースを解放した時点でロックデータ１３０をクリアすることができる。これによって、物理計算機の場合に必要となる手作業でのロックデータ１３０のクリア作業を、仮想化環境では不要とできる。

また、物理計算機と仮想計算機が同じボリュームをシステムボリュームとできる場合、実施例１と実施例２の両方を適用することで、物理計算機と仮想計算機の間でもシステムボリュームの多重使用を禁止できる。これは、ＯＳの実行を物理計算機と仮想計算機で切り替えられるような環境でも、システムボリュームの多重使用を禁止できることを意味する。

本実施例では、システムボリュームのファームウェア領域１２２内のロックデータ１３０の管理に関するいくつかの方法を示す。

第一は、ファームウェア領域１２２内のロックデータ１３０を手動でクリアする方法である。実施例２の説明で述べたように、実施例１では、ＯＳが障害停止した場合にシステムボリュームを解放するタイミングがないという問題がある。ファームウェア領域１２２内のロックデータ１３０をクリアしなければ、そのボリュームからＯＳを起動することができない。

実施例１と実施例２によれば、システムボリュームはディスクアクセスプロトコルのレベルで予約はされないので、ＳＡＮのアクセス権さえ設定されていれば、他の計算機からでもシステムボリュームとなるボリュームはアクセス可能である。したがって、不正にロックされているボリュームをアクセス可能な計算機から、当該ボリュームのファームウェア領域１２２のロックデータ１３０をゼロクリアすることは容易に実現可能である。具体的には、ＯＳ上のプログラムがボリューム２７１のパーティションテーブル１２１を解釈してファームウェア領域１２２の位置を取得し、その中の予め定められた位置にあるロックデータを更新すればよい。システムファームウェア３０４が、このような操作を実行するユーザインタフェースを提供しても良い。

なお、ボリュームが不正にロックされている状態には、正規に予定されていない計算機がそのボリュームを予約している状態、正規に予定されている計算機ではあるが、障害などによりそのボリュームを予約したままで停止している状態などである。後者の場合、他の計算機からロックデータ１３０をゼロクリアする場合に、事前にそのボリュームを予約した計算機の動作状況をチェックすることが望ましい。

次に、ロックデータ１３０の内容を運用管理に利用する方法を示す。実施例１では、システムボリューム予約の処理で計算機を識別するＵＵＩＤと、その時点の時刻をロックデータ１３０に書き込む処理を示した。ロックデータ１３０にはシステムボリュームを予約した計算機からの書き込みが残るので、このデータを参照することで、どの計算機が当該ボリュームをシステムボリュームとして利用しているか、その計算機はいつ起動したのかを知ることができる。

上述のロッククリアプログラムと同様に、ロックデータ１３０を他の計算機から参照するプログラムは容易に実現可能である。具体的には、ＯＳ上のプログラムがボリューム２７１のパーティションテーブル１２１を解釈してファームウェア領域１２２の位置を取得し、その中の予め定められた位置にあるロックデータを取得すればよい。このような操作を実行するユーザインタフェースを提供しても良い。

ロックデータを取得するプログラムを設けることによって、強制的にロックデータ１３０をクリアする時に、そのシステムボリュームの最後のＯＳ起動の状況を知ることができる。これによって、最後にそのボリュームから起動した計算機を知ることができ、その計算機の状態を確認することによって、より安全にロックデータ１３０をクリアすることができる。

実施例におけるシステムボリューム予約に関連する要素を示した図である。 実施例におけるシステムの構成例を示した図である。 実施例における計算機の構成例を示す図である。 実施例における計算機の起動処理のフローチャートである。 実施例におけるシステムボリュームを予約する処理のフローチャートである。 実施例におけるシステムボリューム予約を解放する処理のフローチャートである。

符号の説明

１０１…ＯＳブート処理部、１０２…ディスクアクセスインタフェース、１０３…シャットダウン後処理部、１０４…シャットダウン後処理要求フラグ、１０５…リセット後動作データ、１１０…ディスクアクセス部、１１１…ディスクアクセス済みフラグ、１２１…パーティションテーブル、１２２…ファームウェア領域、１２３…システム領域、１３０…ボリュームロックデータ、２００、２１０、２２０…計算機、２３０、２４０…仮想計算機、２５０…仮想化機構、２６０…ストレージスイッチ、２７０…ストレージ装置、２７１〜２７４…ボリューム、３０１…ＣＰＵ、３０２…メモリ、３０３…バス制御装置、３０４…ディスクアダプタ、３０５…ネットワークアダプタ、３０６…システムファームウェア、３０７…アダプタファームウェア、３１０…ネットワークスイッチ、３２０…ＬＡＮ。

Claims (20)

1. 計算機と他の計算機とからアクセス可能なボリュームをＯＳ起動のためのシステムボリュームとして予約する方法であって、
   前記ボリュームが前記ＯＳ起動のための前記システムボリュームとして予約されているか否かを示すロックデータを前記ボリューム内に保持し、
   前記計算機は前記ＯＳを起動する前に、前記ボリューム内に保持されている前記ロックデータを参照し、
   前記ロックデータが前記システムボリュームとして予約されていないことを示すとき、前記システムボリュームとして予約されていることを示すデータを前記ロックデータとして書き込み、
   前記ロックデータが前記システムボリュームとして予約されていることを示すとき、前記ボリュームへのアクセスを停止することを特徴とするシステムボリュームの予約方法。
2. 前記システムボリュームとして予約されていることを示すデータには、少なくとも前記計算機を識別するデータを含むことを特徴とする請求項１記載のシステムボリュームの予約方法。
3. 前記システムボリュームとして予約されていることを示すデータを書き込んでから所定時間経過後に前記ロックデータが前記少なくとも前記計算機を識別するデータを含む前記書き込んだデータであるとき、前記計算機は前記ＯＳを起動することを特徴とする請求項２記載のシステムボリュームの予約方法。
4. 前記システムボリュームとして予約されていることを示すデータには、さらに前記システムボリュームを予約する時刻データを含むことを特徴とする請求項３記載のシステムボリュームの予約方法。
5. 前記計算機は前記ＯＳを起動する前に、前記計算機が前記システムボリュームへアクセスしたか否かの情報をチェックし、前記情報がアクセスしていないことを示すとき、前記ボリューム内に保持されている前記ロックデータを参照することを特徴とする請求項３記載のシステムボリュームの予約方法。
6. 前記計算機へのシャットダウンの指示に応答して、前記システムボリュームとして予約されていないことを示すデータを前記ロックデータとして書き込むことを特徴とする請求項３記載のシステムボリュームの予約方法。
7. 前記ＯＳを起動する前の、前記ボリューム内に保持されている前記ロックデータの参照は、前記計算機に実装されたファームウェアによって実行されることを特徴とする請求項３記載のシステムボリュームの予約方法。
8. 前記計算機と前記他の計算機の各々は、物理計算機及び仮想計算機システムのいずれか一方であることを特徴とする請求項３記載のシステムボリュームの予約方法。
9. ＯＳ起動のためのシステムボリュームとして予約されているか否かを示すロックデータと前記ＯＳを格納するボリュームを構成するストレージ、及び
   前記ストレージに接続し、前記ボリューム内に格納されている前記ロックデータを参照し、前記ロックデータが前記システムボリュームとして予約されていないことを示すとき、前記システムボリュームとして予約されていることを示すデータを前記ロックデータとして書き込み、前記ロックデータが前記システムボリュームとして予約されていることを示すとき、前記ボリュームへのアクセスを停止する計算機を有することを特徴とする計算機システム。
10. 前記システムボリュームとして予約されていることを示すデータには、少なくとも前記計算機を識別するデータを含むことを特徴とする請求項９記載の計算機システム。
11. 前記システムボリュームとして予約されていることを示すデータを書き込んでから所定時間経過後に前記ロックデータが前記少なくとも前記計算機を識別するデータを含む前記書き込んだデータであるとき、前記計算機は前記ＯＳを起動することを特徴とする請求項10記載の計算機システム。
12. 前記システムボリュームとして予約されていることを示すデータには、さらに前記システムボリュームを予約する時刻データを含むことを特徴とする請求項11記載の計算機システム。
13. 前記計算機は前記ＯＳを起動する前に、前記計算機が前記システムボリュームへアクセスしたか否かの情報をチェックし、前記情報がアクセスしていないことを示すとき、前記ボリューム内に格納されている前記ロックデータを参照することを特徴とする請求項11記載の計算機システム。
14. 前記計算機へのシャットダウンの指示に応答して、前記システムボリュームとして予約されていないことを示すデータを、前記計算機は前記ロックデータとして書き込むことを特徴とする請求項11記載の計算機システム。
15. 前記計算機は、物理計算機及び仮想計算機システムのいずれか一方であることを特徴とする請求項11記載の計算機システム。
16. 前記計算機が前記仮想計算機システムであるとき、前記ロックデータの参照及び書き込みは、前記仮想計算機システムの仮想化機構によって実行されることを特徴とする請求項16記載の計算機システム。
17. ＯＳ起動のためのシステムボリュームとして予約されているか否かを示すロックデータと前記ＯＳを格納するボリュームを構成するストレージ、及び
    前記ストレージに接続し、前記ボリューム内に格納されている前記ロックデータを参照し、前記ロックデータが前記システムボリュームとして予約されていないことを示すとき、前記システムボリュームとして予約されていることを示すデータを前記ロックデータとして書き込み、所定時間経過後に前記ロックデータが前記書き込んだデータであるとき、前記ＯＳを起動し、前記ロックデータが前記システムボリュームとして予約されていることを示すとき、前記ボリュームへのアクセスを停止するファームウェアを実装する計算機を有することを特徴とする計算機システム。
18. 前記計算機は仮想計算機システムであり、前記ファームウェアは前記仮想計算機システムを制御する仮想化機構に実装されることを特徴とする請求項17記載の計算機システム。
19. 前記書き込む前記システムボリュームとして予約されていることを示すデータには、前記仮想化機構により実行が制御される仮想計算機を識別するデータを含むことを特徴とする請求項18記載の計算機システム。
20. 前記仮想計算機へのシャットダウンの指示に応答して、前記システムボリュームとして予約されていないことを示すデータを、前記仮想化機構は前記ロックデータとして書き込むことを特徴とする請求項18記載の計算機システム。

Images