JP2009199224A - システムボリューム予約方法及びその方法を用いた計算機システム - Google Patents
システムボリューム予約方法及びその方法を用いた計算機システム Download PDFInfo
- Publication number
- JP2009199224A JP2009199224A JP2008038707A JP2008038707A JP2009199224A JP 2009199224 A JP2009199224 A JP 2009199224A JP 2008038707 A JP2008038707 A JP 2008038707A JP 2008038707 A JP2008038707 A JP 2008038707A JP 2009199224 A JP2009199224 A JP 2009199224A
- Authority
- JP
- Japan
- Prior art keywords
- computer
- volume
- data
- reserved
- system volume
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】複数の計算機が、同一のシステムボリュームから多重にOSを起動しないように制御する。
【解決手段】ボリュームがOS起動のためのシステムボリュームとして予約されているか否かを示すロックデータをボリューム内に保持し、計算機はOSを起動する前に、ボリューム内に保持されているロックデータがシステムボリュームとして予約されていないことを示すとき、システムボリュームとして予約されていることを示すデータをロックデータとして書き込み、ロックデータがシステムボリュームとして予約されていることを示すとき、ボリュームへのアクセスを停止する。
【選択図】図1
【解決手段】ボリュームがOS起動のためのシステムボリュームとして予約されているか否かを示すロックデータをボリューム内に保持し、計算機はOSを起動する前に、ボリューム内に保持されているロックデータがシステムボリュームとして予約されていないことを示すとき、システムボリュームとして予約されていることを示すデータをロックデータとして書き込み、ロックデータがシステムボリュームとして予約されていることを示すとき、ボリュームへのアクセスを停止する。
【選択図】図1
Description
本発明は、計算機システムの起動手順に関する。
複数の計算機で共有可能なストレージ装置が普及している。一般に、共有可能なストレージ装置は、ファイバチャネルプロトコルと呼ばれるプロトコルで計算機に接続する。ストレージ装置と計算機はファイバチャネルスイッチと呼ばれる装置を介して接続し、ファイバチャネルスイッチが計算機とストレージ装置間のトラフィックを制御する。一般に、このように構成されたストレージのシステムは、SAN(Storage Area Network)と呼ばれる。
ストレージ装置内の記憶領域はボリュームと呼ばれる論理的な記憶領域に分割され、各ボリュームは計算機からは通常のディスク装置と同じに見える。一般に、ファイバチャネルスイッチやストレージ装置はアクセス制御の機能を有しており、SANに接続する各計算機からアクセス可能なストレージ装置やボリュームを制限できる。
ボリュームへのアクセス制限を実現する別の方法として、ストレージ装置へアクセスする際のプロトコルの機能を利用する方法がある。これを利用するシステムとして現用系と待機系との計算機からなるクラスタシステムがある。クラスタシステムでは、現用系と待機系に構成された計算機が同時に共有ボリュームにアクセスしないように、クラスタ制御ソフトウェアがアクセス制御を実施する。具体的には、クラスタ制御ソフトウェアは、ストレージ装置にアクセスするプロトコルが用意しているターゲット予約コマンドを利用して、現用系である計算機からのみ共有ボリュームにアクセス可能となるように制御している。
計算機は、このようなストレージ装置内のボリュームからOSを計算機に読み込み、起動するように構成することができる。このブート(bootstrap)方式は、SANブートと呼ばれる。
これらのSANの技術は、計算機の仮想化技術と組み合わせて利用することもできる。例えば、ストレージ装置内のボリュームをシステムボリュームとして仮想計算機に割り当てて、そこに格納されているOSを読み込むことによって仮想計算機を起動できる(特許文献1)。特許文献1には、仮想化環境におけるボリュームのアクセス制限機構も示されている。
計算機の仮想化においては、I/O仮想化のオーバーヘッドを低減するために、物理計算機に接続しているI/Oアダプタを仮想計算機から直接アクセス可能とする技術がある(非特許文献1)。これを用いると、仮想計算機は仮想計算機モニタ(VMM)を介さずにストレージ装置のボリュームにアクセス可能となり、仮想計算機のI/O性能を向上できる。
ストレージ装置内にあるボリュームを複数の計算機が同時期にアクセス制御なしで利用すると、一般に、ボリューム内容が破壊される。特に、OSが格納されているボリューム(システムボリューム)が破壊されると、計算機が起動不能になるという課題がある。このため、複数の計算機から多重のアクセスが同一のボリューム(共有ボリューム)に発生しないように、様々のアクセス制御機構が用いられる。
計算機の仮想化においてストレージアクセスが仮想化されている場合は、仮想化機構(仮想計算機モニタ又はハイパバイザと呼ばれる。)が仮想計算機に見せるボリュームへのアクセスを制御できるため、仮想化機構によって多重アクセスを禁止することができる。特許文献1では、ボリュームを仮想計算機に見せるためのデータの中に排他制御のためのデータを設け、このデータを用いて同一のボリュームを多重に使用することを禁止している。これによって、ストレージアクセスが仮想化されている場合のシステムボリュームの多重使用による破壊を防止できる。しかしながら、仮想計算機がI/Oアダプタを直接操作するような場合、I/O操作に仮想化機構が介在しないため、仮想化機構の排他制御が効かないという課題がある。
また、仮想計算機のシステムボリュームが物理計算機のシステムボリュームとしても利用可能な場合、仮想化機構が提供する排他制御は物理計算機では効果がないという課題がある。
クラスタシステムで用いられるアクセスプロトコルによるターゲット予約の方式では、予約したボリュームを他の計算機からアクセス不能にできる。一方、ボリュームを予約した計算機が不正に停止すると、このボリュームにアクセスするためにはストレージ装置の側で予約状態を解除しなければならず、また、予約されている状態ではボリュームの内容を他の計算機から参照することもできないという、運用上の課題がある。また、予約を解除するためにはターゲットのリセットが必要であるが、誤って予約を解除すると、予約していた計算機は予期していないリセットのためエラーを生じる可能性もある。
SANのスイッチやストレージ装置の機能によって、計算機からアクセス可能なボリュームを制限することができる。このアクセス制限は、計算機に搭載されているI/Oアダプタに付与されている識別子(WWN:World Wide Name)に基づいて設定される。計算機が仮想化される場合、このWWNも仮想的に付与される。このため、不正な設定がされた場合に複数の仮想計算機が同じWWNを持つ可能性がある。同じWWNを持っているI/Oアダプタが不正に存在する場合、SANのアクセス制御機構は有効に働かず、複数の仮想計算機から多重にボリュームにアクセス可能となってしまう課題がある。このような環境では、アクセスプロトコルによるターゲット予約も効果がないという点も課題である。
以上のような個々の課題を共通的に見ると、仮想化機構により構成される仮想計算機または物理計算機といった複数の計算機が、同一のシステムボリュームから多重にOSを起動しないようにする必要がある。
本発明の態様のシステムボリューム予約方法は、計算機と他の計算機とからアクセス可能なボリュームをOS起動のためのシステムボリュームとして予約する方法である。ボリュームがOS起動のためのシステムボリュームとして予約されているか否かを示すロックデータをボリューム内に保持し、計算機はOSを起動する前に、ボリューム内に保持されているロックデータを参照し、ロックデータがシステムボリュームとして予約されていないことを示すとき、システムボリュームとして予約されていることを示すデータをロックデータとして書き込み、ロックデータがシステムボリュームとして予約されていることを示すとき、ボリュームへのアクセスを停止する。
本発明の望ましい他の態様は、システムボリュームとして予約されていることを示すデータには、少なくとも計算機を識別するデータを含む。
本発明の望ましいさらに他の態様は、システムボリュームとして予約されていることを示すデータを書き込んでから所定時間経過後にロックデータが書き込んだデータであるとき、計算機はOSを起動する。
本発明のさらに他の態様である計算機システムは、OS起動のためのシステムボリュームとして予約されているか否かを示すロックデータとOSを格納するボリュームを構成するストレージ、及びストレージに接続し、ボリューム内に格納されているロックデータを参照し、ロックデータがシステムボリュームとして予約されていないことを示すとき、システムボリュームとして予約されていることを示すデータをロックデータとして書き込み、ロックデータがシステムボリュームとして予約されていることを示すとき、ボリュームへのアクセスを停止する計算機を有する。
本発明の望ましいさらに他の態様は、ボリューム内に格納されているロックデータを参照し、ロックデータがシステムボリュームとして予約されていないことを示すとき、システムボリュームとして予約されていることを示すデータをロックデータとして書き込み、所定時間経過後にロックデータが書き込んだデータであるとき、OSを起動し、ロックデータがシステムボリュームとして予約されていることを示すとき、ボリュームへのアクセスを停止する処理を、計算機がファームウェアとして実装する。
本発明の望ましいさらに他の態様は、計算機が仮想計算機システムであり、ファームウェアは仮想計算機システムを制御する仮想化機構に実装される。
本発明によれば、仮想化機構により構成される仮想計算機または物理計算機といった複数の計算機が、同一のシステムボリュームから多重にOSを起動しないように制御できる。
以下に本発明の実施の形態について説明する。以下の実施の形態では、システムボリューム内の一部の領域をOSの多重起動を防止する排他制御用の制御情報を格納する排他制御領域、この排他制御領域のデータをロックデータとし、計算機起動時の処理の多重起動防止処理がその排他制御領域にアクセスして、計算機の起動可否を判定する方法およびそれを実装する計算機システムを示す。
本実施例では、物理計算機がシステムボリュームからOSを起動する際に、同一ボリュームから複数の計算機が多重にOSを起動するのを防止することを示す。
図2は、本実施例のシステムの構成例を示す。この例では、サーバ計算機200、210および220が、SANのストレージスイッチ260を介してストレージ装置270に接続している。各計算機はスイッチ260に接続するためのディスクアダプタを有している。
サーバ計算機200は仮想化機構250を有し、仮想計算機230と240を実行させる仮想計算機システムである。仮想化機構250はファームウェア又はソフトウェアによって実現される。仮想化機構250は、その上で実行する仮想計算機230と240に仮想的なディスクアダプタを提供する。仮想計算機230と240は、仮想化機構250が作り出した仮想的なディスクダプタを持ち、それによってスイッチ260を介してストレージ装置270内のボリュームにアクセス可能となっている。仮想化機構250は、仮想計算機230と240から仮想ディスクアダプタへのアクセスを、計算機200に搭載の物理的なディスクアダプタへのアクセスに変換して、仮想計算機230と240からのストレージ装置270内のボリュームへのアクセスを実現している。仮想計算機230と240からのスイッチ260への仮想的な接続は、図2では破線にて示している。
ストレージ装置270には、各サーバ計算機がシステムボリュームとして利用するボリューム271〜274が構成されている。それぞれの計算機のシステムボリュームは、計算機210がVOL1(271)、計算機220がVOL2(272)、仮想計算機230がVOL3(273)、仮想計算機240がVOL4(274)であるとして説明する。
ストレージスイッチ260とストレージ装置270は、各ボリュームが予め定めた計算機からのみ利用可能なようにアクセス権を設定することができる。このアクセス権は、計算機に搭載のディスクアダプタに付与されている識別子を基準に設定できる。例えば、ファイバチャネルによるSANであれば、WWN(World Wide Name)といった識別子によって、各計算機からアクセス可能なストレージ装置およびボリュームを定義できる。
図3は、本実施例での計算機の構成例を示す図である。図3には、サーバ計算機210の構成を示したが、他の物理計算機も同様の構成である。
計算機210は、CPU301、メモリ302、ディスクアダプタ304、ネットワークアダプタ305、システムファームウェア306等が、バス制御装置303を介して接続している。システムファームウェア306は、計算機210の起動時に実行するプログラムを格納しているROMであるが、以下では格納されているプログラム又はそのプログラムによる処理をシステムファームウェア306と呼ぶことがある。計算機210のCPU301は、システムファームウェア306内の予め定められたアドレスに格納されている処理から実行を開始する。この処理は、計算機に搭載されているI/Oデバイスの初期化等を実施し、起動用として予め指定されたボリュームの特定領域の内容をメモリ302に読み込み、そのボリュームに格納されているOSを起動する(厳密には、OSをメモリ302に読み込み、実行を開始させる。)。以下の説明では、CPU301がメモリ302、あるいは、ファームウェア306に格納されているプログラムを実行することを、そのプログラムが実行するとして説明する。
ディスクアダプタ304もアダプタファームウェア307を搭載している。アダプタファームウェア307はディスクアダプタ304上のROMに搭載されているが、システムファームウェア306と同様に、CPU301がその中のプログラムを実行可能な(メモリ302に読み込み実行する)ように構成されている。アダプタファームウェア307は、ディスクアダプタ304を介してストレージ装置270にアクセスする手順を格納している。システムファームウェア306は、システムボリュームがディスクアダプタ304を介して接続している場合、アダプタ304のファームウェア307のディスクアクセス手順を呼び出すことによって、所定のシステムボリュームにアクセスする。
ネットワークアダプタ305は、ネットワークスイッチ310及びネットワーク320を介して、他の計算機などと通信するための装置である。
次に、本実施例の計算機のシステムボリューム予約処理について説明する。図1は、本実施例における計算機のシステムボリューム予約処理に関わる要素を示した図である。図1は、計算機210内の構成、ストレージ装置270との接続、システムボリューム271の内容を示した図である。図1ではストレージスイッチ260は省略している。
システムファームウェア306は、計算機210の起動時に実行するOSブート処理部101、計算機210に接続するボリュームにアクセスするためのインタフェースを提供するディスクアクセスインタフェース102、および、計算機210のシャットダウンの直後に実行するシャットダウン後処理部103を実装している。また、システムファームウェア306は、計算機210のリセット後にシャットダウン後処理103の実行を要求するフラグ104、リセット後動作データ105を実装する。フラグ104とデータ105は、実際にはメモリ302の所定のアドレスに実装される。
ディスクアクセスインタフェース102は、システムファームウェア306や他のソフトウェアに対して、計算機210に接続するボリュームの内容を読み書きするインタフェースを提供する。OS起動に際して、OSブート処理部101は、ディスクアクセスインタフェース102を呼び出す。インタフェース102は、OS起動前のボリュームアクセス手順(OSが関与せずにボリュームへアクセスする手順)も実装している。
実際のボリュームにアクセスする手順は、ディスクアダプタ304のアダプタファームウェア307に格納されている。システムファームウェア306は、計算機210を起動する際に、ディスクアクセスインタフェース102がアダプタファームウェア307のディスクアクセス部110を呼び出すように構成している。
ディスクアクセス部110は、ディスクアダプタ304によって実際にストレージ装置270のボリュームにアクセスするための手順を実装している。
本実施例では、アダプタファームウェア307は、ディスクアクセス済みフラグ111を持っている。このフラグ111は、計算機210が起動してから、アダプタ304のアダプタファームウェア307によるボリュームへのアクセスがあったかどうかを記録している。より具体的には、ディスクアクセス済みフラグ111は、ディスクアクセス部110によるボリュームアクセスが、計算機起動後の初回のアクセスか、そうでないかを記録するためのフラグである。
アダプタファームウェア307自体はディスクアダプタ304内にROMとして実装されるのが一般的であるが、ファームウェア307はディスクアクセス済みフラグ111をRAM領域であるメモリ302内に配置する。フラグ111は、計算機210の起動(電源オンやリセットボタンなどによるハードウエアリセット)時にディスクアクセスが実行されていないことを示す値にクリアされる。
本実施例では、システムボリューム271は、ボリューム271内の各パーティションの位置(アドレス)やサイズを記録しているパーティションテーブル121、ファームウェアが利用するデータを格納するファームウェア領域(122)、OSが格納されているシステム領域(123)から成る。ファームウェア領域(122)やシステム領域(123)の位置やサイズはパーティションテーブル121に格納されている。このうち、ファームウェア領域122には、システムボリューム271がOS起動ボリュームとして多重に利用されないように排他制御するためのボリュームロックデータ130を含んでいる。ロックデータ130は、OS上からもアクセス可能であるが、運用上書き込み禁止としておくことが望ましい。
図4に計算機210の起動処理のフローチャートを示す。
計算機210が起動(電源オンやリセットボタンなどによるハードウエアリセット)すると、後に図6を用いて説明する処理ステップを経て、システムファームウェア306内のOSブート処理部101が実行する。OSブート処理部101は、システムボリュームと設定されているボリューム271のパーティションテーブル121を読み込むために、ディスクアクセスインタフェース102を呼び出す(ステップ401)。システムボリュームは、システムファームウェア306のパラメータとして予め定義されている。また、パーティションテーブル121は、ボリューム271内の所定の位置に存在している。
インタフェース102は、実際のディスクアクセスを実行するためにアダプタ304のファームウェア307のディスクアクセス部110を呼び出す(ステップ402)。
ディスクアクセス部110は、実際にボリューム271にアクセスしてパーティションテーブル121をメモリ302に読み込む処理を実行する(ステップ403)。この際、ディスクアクセス部110は、そのディスク読み込みが、計算機210が起動(電源オンやリセットボタンなどによるハードウエアリセット)してから初めてのディスクアクセスであるかどうかを判定する。初めてならばそのボリュームをシステムボリュームとして予約している(起動している)他の計算機がないかを検査する。この処理については、後述する。
既に起動している他の計算機があると判定される場合、ディスクアクセス部110はディスクリード処理を失敗させる。そうでなければ、ディスクリードを実行する。
OSブート処理部101は、ディスクアクセス部110によるステップ403の処理の終了後にディスクリードが成功したかどうかを判定する(ステップ404)。ディスクアクセス部110がディスクリードに失敗した場合、OSブート処理部101は計算機210の起動(ここでの起動は、以降のOSローダの実行、OSの起動などを言う)を失敗させる(ステップ406)。失敗させるとは、たとえばボリューム271への以降のアクセスを止め、アクセスエラーのメッセージを出力する。成功した場合は、読み込んだパーティションテーブル121の内容を参照してシステム領域123の位置を取得して、システム領域に格納されているOSローダをロードして実行し、OSを起動する(ステップ405)。
図5に、システムボリュームを排他的に予約する処理(図4のステップ403)のフローチャートを示す。この処理は、アダプタファームウェア307のディスクアクセス部110に実装される。以降では、ボリュームが多重にシステムボリュームとして利用されない状態におくことを、“システムボリュームとして予約する”と言うこととする。
ディスクアクセス部110は、ディスクアクセス済みフラグ111の内容を取得し(ステップ501)、その内容を検査して、計算機210が起動(電源オンやリセット)されてからディスクアクセスを実行したかどうかを判定する(ステップ502)。既にディスクアクセスが実行されている場合は、ディスクリード(パーティションテーブル121の読み込み)を実行し(ステップ522)、ディスクアクセスが成功したとして処理を終了する(ステップ523)。
初回アクセスであると判定した場合、ディスクアクセス部110はステップ503以降の処理で、システムボリュームの予約を試みる。ディスクアクセス部110は、ボリューム271のパーティションテーブル121を読み込んで、ファームウェア領域122の位置とサイズ等の情報を取得する(ステップ503)。ここでのボリュームの読み取り処理は、ディスクアクセスインタフェース102が持つ、前述のOSが関与せずにボリュームへアクセスする手順に基づいて、ディスクアクセス部110に直接指示を出すことによって実行する。
ファームウェア領域122の情報を取得後、ディスクアクセス部110は、システムボリューム予約処理で使用するロックデータを生成する(ステップ504)。生成するロックデータは、システムボリュームを予約しようとしている計算機をシステム全体で一意に識別可能な値を含む。このような値としては、計算機のSMBIOS(System Managemant BIOS)と呼ばれるファームウェアが保持している計算機のUUIDがある。計算機のUUIDは、計算機の出荷時に設定される計算機を識別するための値で、SMBIOSを搭載するすべての計算機で重複のないように設定される。ロックデータに、UUIDに加えて、その時点の時刻を示す値を含めると、システムボリュームを予約した時刻を後に認識できるなど、運用上の利点が得られる。
次に、ディスクアクセス部110は、ファームウェア領域122内のボリュームロックデータ130を読み取る(ステップ505)。ボリュームロックデータ130は、ファームウェア領域122内で予め定められた位置に存在し、一度のディスクアクセスで読み取りや更新が可能なサイズのデータが望ましい。例えば、ボリュームを構成するディスクの1つのセクタがロックデータ130領域として定義される。2回以上のディスクアクセスで読み取りや更新するサイズであると、ボリュームロックデータ130を複数回に亘って読み込むことになり、その間に他の計算機からボリュームロックデータ130へのアクセスが発生する可能性があり、処理が複雑になるからである。本実施例ではディスクアクセスプロトコルによるターゲット予約の仕組みを使わないため、SANのアクセス設定としてアクセスが許可されていれば、どの計算機からでもロックデータを読み取ることができる。
ディスクアクセス部110は、読み取ったロックデータ値が0でないか検査する(ステップ506)。0でない(読み取ったセクタに0でないデータが含まれる)場合は、ボリューム271はシステムボリュームとして利用中であると判定し、ディスクアクセスを失敗で終了させる(ステップ511)。
ロックデータが0(セクタの内容がすべて0)だった場合(システムボリュームとして予約されていないことを示す場合)、ロックデータ130にステップ504で生成したデータを書き込んで、ボリューム271をシステムボリュームとして予約することを試みる(ステップ507)。この書き込みも、SANのアクセス設定が許可されていれば、複数の計算機から同時に(見かけ上の同時であり、厳密には前後関係になる)実行可能である。複数の計算機から同時に書き込まれた場合、ロックデータ130の内容は、最後に書き込まれた内容となる。
ロックデータの書き込み後、ディスクアクセス部110は、予め定めた一定時間待機する(ステップ508)。これは、ステップ505でのロックデータ130のリードにおいて、複数の計算機がロックデータとして0を取得した場合に、それらの計算機のすべてがステップ507でのロックデータへの書き込みが完了するのを待つためである。一般には、数秒待てば十分である。ある計算機がロックデータの書き込み後に、ロックデータを読み込んだ他の計算機は0以外の値を取得するため、ステップ506の判定により、ロックデータの書き込みを行わない。
一定時間の待機の後、ディスクアクセス部110は、再びロックデータ130をリードする(ステップ509)。ここで読んだ値がステップ504で生成した値(ロックデータとして書き込んだ値)と一致しない場合、ボリューム271をシステムボリュームとして予約できなかったとして、ディスクアクセスを失敗として処理を終了する(ステップ511)。
値が一致する場合、この計算機210がボリューム271をシステムボリュームとして予約できたとする。この場合は、ディスクアクセス済みフラグ111をセットして(ステップ521)ディスクリードを実行し(ステップ522)、ディスクアクセスが成功したとして終了する(ステップ523)。以上により、計算機210の起動時にシステムボリュームを排他的に予約可能となる。
次に、排他的に予約したシステムボリュームを、他の計算機からブート可能なように解放する手順を示す。具体的には、計算機210で実行するOSがシャットダウンした後で、システムボリュームを解放する処理を示す。
OSがシャットダウンする時は、OSがシャットダウン処理の過程でI/Oアダプタを停止する場合があるので、ディスクアダプタ304によるディスクアクセス処理は期待できない。そこで、本実施例では、シャットダウン後処理部103をシステムファームウェア306内に設ける。シャットダウン後処理部103は、OSのシャットダウン直後、あるいは、リブートによる計算機再起動の直後に実行し、ボリューム271内のロックデータ130をクリアする。これによって、システムボリュームを他の計算機のシステムボリュームとして利用可能なように解放する。
図6は、OSがシャットダウン、あるいは、リブート(再起動)する時の、システムボリューム予約を解放する処理フローチャートである。OSは、シャットダウン処理の後に、計算機の電源をオフ、あるいは、リブートするようにシステムファームウェア306に指示を出す(ステップ601)。このような計算機の電源の制御は、システムファームウェア306に実装されるのが一般的である。
システムファームウェア306は、指示された動作として電源オフかリブートかをリセット後動作データ105に記録する(ステップ602)。リセット後にロックデータ130をクリアするシャットダウン後処理部103が実行するように、シャットダウン後処理要求フラグ104をセットして(ステップ603)、計算機210をリセットする(ステップ604)。電源オンや通常のリセットによる起動時にも要求フラグ104を使用するならば、その場合に設定される値とは異なる値を、電源をオフあるいはリブートの場合、要求フラグ104に設定する。
計算機210は、リセットされるとシステムファームウェア内の計算機起動処理を実行する。図6のステップ605からの処理は、その起動処理の一部である。図6に示すように、電源オンやハードウエアリセットの場合にも、ステップ605からの処理を実行する。
まず、リセット後動作データ105の内容を参照して、リセット前にシャットダウン後処理が要求されているか検査する(ステップ605)。要求されていない場合、つまり、電源オンやハードウエアリセットによりリセット後動作データ105は消去されているので、図4を用いて説明したように、通常の初期化処理の後、OSブート処理を実行する(ステップ608)。
一方、シャットダウン後処理が要求されている場合は、ステップ606からのシャットダウン後処理を実行する。シャットダウン後処理部103は、リセット前の処理が電源オフかリセットかをリセット後動作データ105より取得し(ステップ606)、電源オフの場合は、ロックデータ130をゼロクリアする(ステップ607)。具体的には、システムボリュームとされているボリューム271のパーティションテーブル121を読み込んでファームウェア領域122の位置を取得して、その中のロックデータ130に0を書き込む。本実施例では簡単のために、システムボリュームとして予約されていないことを示す値を0としているが、予約されていないことを示す値として定めた値であれば良い。その後、計算機210の電源をオフにする(ステップ609)。図示しないが、電源オフによって、メモリ302にあるディスクアクセス済みフラグ111は消える。
リブートの場合はOSブート処理を実行する(ステップ608)。この場合、ディスクアクセス済みフラグ111がアクセス済みを示したままであり、ロックデータ130を計算機210が確保した状態が継続しているので、図5のステップ502の判定が、アクセス済みとなり、ディスクリードが成功したことになる。これにより、電源オンやハードウエアリセットのときよりも、リブートに伴う計算機210の再起動の方が短時間になる。
以上により、ストレージ装置内のボリュームを複数の計算機から多重にステムボリュームとして利用されることを防止できる。これによって、ストレージスイッチ260やストレージ装置270のアクセス権の設定が不正であっても、1つのボリュームがシステムボリュームとして多重に利用されることを抑止できる。また、ディスクアダプタ304には、アクセス権設定の基準となる識別子(WWNなど)を自由に設定可能な場合があるが、この設定が不正になってしまった場合、つまり、システム内に同一の識別子を持つディスクアダプタが存在しているような状態でも、ボリュームのシステムボリュームとしての多重使用を抑止できる。
本実施例は、共有しているボリューム271内のロックデータ130を利用した制御であり、多重使用の禁止のための制御情報を格納する、システムを構成するすべての計算機から参照可能なボリュームを設ける、あるいは、ネットワーク等の別の共通の制御パスを設ける必要がない。
また、本実施例では、ストレージのアクセスプロトコルによってデバイスを予約しないので、システムボリュームとして予約されたボリュームであっても、運用上、他の計算機から参照することが可能である。これによって、システムで障害が発生した場合などに迅速にボリュームを参照できることとなり、システムの障害解析や障害回復の作業の簡略化につながる。また、WWNが重複しうる環境でデバイス予約が有効に機能しない環境であっても、OSの多重起動を抑止できる。
本実施例は、起動する計算機が、仮想化機構250により構成されている仮想計算機230の場合である。
計算機を起動する処理が仮想計算機230で行われる場合であっても、計算機の起動処理自体に変わりはない。したがって、計算機の起動処理としては、仮想化機構250が仮想計算機230に提供する論理的なファームウェアが、実施例1で説明したOS起動処理(図4、図5)を実行するように構成されていれば良い。これによって、仮想計算機230は、起動する時にボリューム273をシステムボリュームとして予約できる。ただし、生成するロックデータは、実施例1ではシステムボリュームを予約しようとしている計算機を識別可能な値を含むようにしたが、仮想化機構250はOSを起動しようとしている仮想計算機230を識別可能な値を含むようにする。
仮想計算機230の停止後にボリューム273を解放する処理は、物理的な計算機での解放処理と異なり、仮想化機構250で実施することが可能である。計算機が仮想化されている場合、仮想計算機230の電源オフやリブートの処理は仮想化機構250が実施することとなる。つまり、図6のゲストOSが実行するステップ601の処理は仮想化機構250によってトラップ可能である。この処理の過程で、仮想化機構250は、当該の仮想計算機230のシステムボリュームであるボリューム273のロックデータをクリアし予約を解放することができる。
以上により、起動する計算機が仮想化機構による構成される仮想計算機であっても、ストレージ装置内のボリュームをシステムボリュームとして多重使用されないように排他的に予約することが可能となる。
本実施例は、仮想化機構のI/O仮想化に依存せずに、仮想計算機が利用するシステムボリューム上のロックデータにより多重使用を禁止できる。したがって、仮想計算機にディスクアダプタを直接アクセス可能なように割り当てる場合であっても、仮想化機構がI/Oをエミュレーションする場合であっても、同様に多重使用を禁止できる。これによって不正な構成の仮想計算機があって、SANのアクセス制御が有効に効かない場合でも、1つのボリュームが多重にシステムボリュームとして利用されることを禁止できる。
仮想計算機の場合、同一の仮想計算機が多重に起動する場合も想定される。ロックデータ130に、ボリューム予約試行時のある程度の精度のある時刻を含めることで、同一の仮想計算機が複数の計算機から多重に起動することも防止できる。
本実施例では、仮想計算機で実行するOSが障害により停止した場合でも、システムボリュームを解放可能である。物理計算機で実行するOSが障害により停止した場合は、計算機を物理的にリセットしなければ回復しないため、実施例1に示したシャットダウン後処理部103を実行できないケースが存在する。一方、仮想計算機の場合は、ゲストOSが障害で停止した場合でも、仮想化機構250が仮想計算機230の状態を管理するため、仮想計算機230のリソースを解放した時点でロックデータ130をクリアすることができる。これによって、物理計算機の場合に必要となる手作業でのロックデータ130のクリア作業を、仮想化環境では不要とできる。
また、物理計算機と仮想計算機が同じボリュームをシステムボリュームとできる場合、実施例1と実施例2の両方を適用することで、物理計算機と仮想計算機の間でもシステムボリュームの多重使用を禁止できる。これは、OSの実行を物理計算機と仮想計算機で切り替えられるような環境でも、システムボリュームの多重使用を禁止できることを意味する。
本実施例では、システムボリュームのファームウェア領域122内のロックデータ130の管理に関するいくつかの方法を示す。
第一は、ファームウェア領域122内のロックデータ130を手動でクリアする方法である。実施例2の説明で述べたように、実施例1では、OSが障害停止した場合にシステムボリュームを解放するタイミングがないという問題がある。ファームウェア領域122内のロックデータ130をクリアしなければ、そのボリュームからOSを起動することができない。
実施例1と実施例2によれば、システムボリュームはディスクアクセスプロトコルのレベルで予約はされないので、SANのアクセス権さえ設定されていれば、他の計算機からでもシステムボリュームとなるボリュームはアクセス可能である。したがって、不正にロックされているボリュームをアクセス可能な計算機から、当該ボリュームのファームウェア領域122のロックデータ130をゼロクリアすることは容易に実現可能である。具体的には、OS上のプログラムがボリューム271のパーティションテーブル121を解釈してファームウェア領域122の位置を取得し、その中の予め定められた位置にあるロックデータを更新すればよい。システムファームウェア304が、このような操作を実行するユーザインタフェースを提供しても良い。
なお、ボリュームが不正にロックされている状態には、正規に予定されていない計算機がそのボリュームを予約している状態、正規に予定されている計算機ではあるが、障害などによりそのボリュームを予約したままで停止している状態などである。後者の場合、他の計算機からロックデータ130をゼロクリアする場合に、事前にそのボリュームを予約した計算機の動作状況をチェックすることが望ましい。
次に、ロックデータ130の内容を運用管理に利用する方法を示す。実施例1では、システムボリューム予約の処理で計算機を識別するUUIDと、その時点の時刻をロックデータ130に書き込む処理を示した。ロックデータ130にはシステムボリュームを予約した計算機からの書き込みが残るので、このデータを参照することで、どの計算機が当該ボリュームをシステムボリュームとして利用しているか、その計算機はいつ起動したのかを知ることができる。
上述のロッククリアプログラムと同様に、ロックデータ130を他の計算機から参照するプログラムは容易に実現可能である。具体的には、OS上のプログラムがボリューム271のパーティションテーブル121を解釈してファームウェア領域122の位置を取得し、その中の予め定められた位置にあるロックデータを取得すればよい。このような操作を実行するユーザインタフェースを提供しても良い。
ロックデータを取得するプログラムを設けることによって、強制的にロックデータ130をクリアする時に、そのシステムボリュームの最後のOS起動の状況を知ることができる。これによって、最後にそのボリュームから起動した計算機を知ることができ、その計算機の状態を確認することによって、より安全にロックデータ130をクリアすることができる。
101…OSブート処理部、102…ディスクアクセスインタフェース、103…シャットダウン後処理部、104…シャットダウン後処理要求フラグ、105…リセット後動作データ、110…ディスクアクセス部、111…ディスクアクセス済みフラグ、121…パーティションテーブル、122…ファームウェア領域、123…システム領域、130…ボリュームロックデータ、200、210、220…計算機、230、240…仮想計算機、250…仮想化機構、260…ストレージスイッチ、270…ストレージ装置、271〜274…ボリューム、301…CPU、302…メモリ、303…バス制御装置、304…ディスクアダプタ、305…ネットワークアダプタ、306…システムファームウェア、307…アダプタファームウェア、310…ネットワークスイッチ、320…LAN。
Claims (20)
- 計算機と他の計算機とからアクセス可能なボリュームをOS起動のためのシステムボリュームとして予約する方法であって、
前記ボリュームが前記OS起動のための前記システムボリュームとして予約されているか否かを示すロックデータを前記ボリューム内に保持し、
前記計算機は前記OSを起動する前に、前記ボリューム内に保持されている前記ロックデータを参照し、
前記ロックデータが前記システムボリュームとして予約されていないことを示すとき、前記システムボリュームとして予約されていることを示すデータを前記ロックデータとして書き込み、
前記ロックデータが前記システムボリュームとして予約されていることを示すとき、前記ボリュームへのアクセスを停止することを特徴とするシステムボリュームの予約方法。 - 前記システムボリュームとして予約されていることを示すデータには、少なくとも前記計算機を識別するデータを含むことを特徴とする請求項1記載のシステムボリュームの予約方法。
- 前記システムボリュームとして予約されていることを示すデータを書き込んでから所定時間経過後に前記ロックデータが前記少なくとも前記計算機を識別するデータを含む前記書き込んだデータであるとき、前記計算機は前記OSを起動することを特徴とする請求項2記載のシステムボリュームの予約方法。
- 前記システムボリュームとして予約されていることを示すデータには、さらに前記システムボリュームを予約する時刻データを含むことを特徴とする請求項3記載のシステムボリュームの予約方法。
- 前記計算機は前記OSを起動する前に、前記計算機が前記システムボリュームへアクセスしたか否かの情報をチェックし、前記情報がアクセスしていないことを示すとき、前記ボリューム内に保持されている前記ロックデータを参照することを特徴とする請求項3記載のシステムボリュームの予約方法。
- 前記計算機へのシャットダウンの指示に応答して、前記システムボリュームとして予約されていないことを示すデータを前記ロックデータとして書き込むことを特徴とする請求項3記載のシステムボリュームの予約方法。
- 前記OSを起動する前の、前記ボリューム内に保持されている前記ロックデータの参照は、前記計算機に実装されたファームウェアによって実行されることを特徴とする請求項3記載のシステムボリュームの予約方法。
- 前記計算機と前記他の計算機の各々は、物理計算機及び仮想計算機システムのいずれか一方であることを特徴とする請求項3記載のシステムボリュームの予約方法。
- OS起動のためのシステムボリュームとして予約されているか否かを示すロックデータと前記OSを格納するボリュームを構成するストレージ、及び
前記ストレージに接続し、前記ボリューム内に格納されている前記ロックデータを参照し、前記ロックデータが前記システムボリュームとして予約されていないことを示すとき、前記システムボリュームとして予約されていることを示すデータを前記ロックデータとして書き込み、前記ロックデータが前記システムボリュームとして予約されていることを示すとき、前記ボリュームへのアクセスを停止する計算機を有することを特徴とする計算機システム。 - 前記システムボリュームとして予約されていることを示すデータには、少なくとも前記計算機を識別するデータを含むことを特徴とする請求項9記載の計算機システム。
- 前記システムボリュームとして予約されていることを示すデータを書き込んでから所定時間経過後に前記ロックデータが前記少なくとも前記計算機を識別するデータを含む前記書き込んだデータであるとき、前記計算機は前記OSを起動することを特徴とする請求項10記載の計算機システム。
- 前記システムボリュームとして予約されていることを示すデータには、さらに前記システムボリュームを予約する時刻データを含むことを特徴とする請求項11記載の計算機システム。
- 前記計算機は前記OSを起動する前に、前記計算機が前記システムボリュームへアクセスしたか否かの情報をチェックし、前記情報がアクセスしていないことを示すとき、前記ボリューム内に格納されている前記ロックデータを参照することを特徴とする請求項11記載の計算機システム。
- 前記計算機へのシャットダウンの指示に応答して、前記システムボリュームとして予約されていないことを示すデータを、前記計算機は前記ロックデータとして書き込むことを特徴とする請求項11記載の計算機システム。
- 前記計算機は、物理計算機及び仮想計算機システムのいずれか一方であることを特徴とする請求項11記載の計算機システム。
- 前記計算機が前記仮想計算機システムであるとき、前記ロックデータの参照及び書き込みは、前記仮想計算機システムの仮想化機構によって実行されることを特徴とする請求項16記載の計算機システム。
- OS起動のためのシステムボリュームとして予約されているか否かを示すロックデータと前記OSを格納するボリュームを構成するストレージ、及び
前記ストレージに接続し、前記ボリューム内に格納されている前記ロックデータを参照し、前記ロックデータが前記システムボリュームとして予約されていないことを示すとき、前記システムボリュームとして予約されていることを示すデータを前記ロックデータとして書き込み、所定時間経過後に前記ロックデータが前記書き込んだデータであるとき、前記OSを起動し、前記ロックデータが前記システムボリュームとして予約されていることを示すとき、前記ボリュームへのアクセスを停止するファームウェアを実装する計算機を有することを特徴とする計算機システム。 - 前記計算機は仮想計算機システムであり、前記ファームウェアは前記仮想計算機システムを制御する仮想化機構に実装されることを特徴とする請求項17記載の計算機システム。
- 前記書き込む前記システムボリュームとして予約されていることを示すデータには、前記仮想化機構により実行が制御される仮想計算機を識別するデータを含むことを特徴とする請求項18記載の計算機システム。
- 前記仮想計算機へのシャットダウンの指示に応答して、前記システムボリュームとして予約されていないことを示すデータを、前記仮想化機構は前記ロックデータとして書き込むことを特徴とする請求項18記載の計算機システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008038707A JP2009199224A (ja) | 2008-02-20 | 2008-02-20 | システムボリューム予約方法及びその方法を用いた計算機システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008038707A JP2009199224A (ja) | 2008-02-20 | 2008-02-20 | システムボリューム予約方法及びその方法を用いた計算機システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2009199224A true JP2009199224A (ja) | 2009-09-03 |
Family
ID=41142672
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008038707A Pending JP2009199224A (ja) | 2008-02-20 | 2008-02-20 | システムボリューム予約方法及びその方法を用いた計算機システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2009199224A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013008322A (ja) * | 2011-06-27 | 2013-01-10 | Ntt Data Corp | 仮想化システム、および仮想化方法 |
JP5855724B1 (ja) * | 2014-09-16 | 2016-02-09 | 日本電信電話株式会社 | 仮想機器管理装置、仮想機器管理方法及び仮想機器管理プログラム |
-
2008
- 2008-02-20 JP JP2008038707A patent/JP2009199224A/ja active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013008322A (ja) * | 2011-06-27 | 2013-01-10 | Ntt Data Corp | 仮想化システム、および仮想化方法 |
JP5855724B1 (ja) * | 2014-09-16 | 2016-02-09 | 日本電信電話株式会社 | 仮想機器管理装置、仮想機器管理方法及び仮想機器管理プログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11093231B1 (en) | Automating application of software patches to a server having a virtualization layer | |
JP5174110B2 (ja) | 自動化されたモジュール型のセキュアな起動ファームウェアの更新 | |
US6993649B2 (en) | Method of altering a computer operating system to boot and run from protected media | |
JP3593241B2 (ja) | 計算機の再起動方法 | |
US9430250B2 (en) | Bootability with multiple logical unit numbers | |
US7533288B2 (en) | Method of achieving high reliability of network boot computer system | |
US10216936B2 (en) | Method of preventing computer malfunction, computer program, and computer | |
RU2432605C1 (ru) | Способ расширения, основанный на сервере архитектуры десктопной виртуальной машины на клиентские машины, и машиночитаемая среда | |
JP5074351B2 (ja) | システム構築方法及び管理サーバ | |
US20160092261A1 (en) | Method and system for physical computer system virtualization | |
US20140196040A1 (en) | Virtual machine crash file generation techniques | |
JP2004038931A (ja) | コンピュータ・ハードディスクにおけるデータのバックアップと回復とを実現する方法 | |
US20140195791A1 (en) | Methods and systems for instant restore of system volume | |
US20140195848A1 (en) | Methods and systems for instant restore of system volume | |
KR20060047640A (ko) | Vex - 가상 확장물을 고립시키는 방법 | |
JP2002244874A (ja) | 情報処理装置およびファームウェア更新方法 | |
MX2007002204A (es) | Aparato, sistema y metodo para reinicio de serializacion de sistema de archivos. | |
US11163597B2 (en) | Persistent guest and software-defined storage in computing fabric | |
JP2002328813A (ja) | プログラム修正方法 | |
JP2002007214A (ja) | 情報処理装置および不揮発性記憶装置の書き換え制御方法 | |
CN114741233A (zh) | 快速启动方法 | |
TW200301427A (en) | Method and apparatus for enumeration of a multi-node computer system | |
JP3597558B2 (ja) | 情報処理装置 | |
JPWO2004081791A1 (ja) | 仮想計算機システム、仮想計算機システムにおけるファームウェアアップデート方法 | |
WO2007022687A1 (fr) | Système et procédé de contrôle de sécurité de système d’exploitation |