JP4802527B2 - 計算機システム - Google Patents

Description

本発明は、記憶装置システム内のボリューム（論理ユニットともいい、以下、ＬＵと称する）の、サーバへの割り当てに関する。

近年、プロセッサの高性能化、小型化に伴い、多数のサーバが同一筐体に搭載されるブレードサーバ製品の開発が進んでいる。これらの小型サーバには、サーバ１台毎にディスク装置を取り付ける余裕がないため、ディスク装置を内蔵しないサーバ（以下、ディスクレスサーバと称する）として、１台の記憶装置システムにＳＡＮ（ストレージエリアネットワーク）を介して接続し、各サーバから共有する構成を採用することが多い。

ここで、複数サーバが１台の記憶装置システムを共有する従来技術が開示されている（特許文献１参照）。又、ディスク装置内の記憶領域を、複数の領域（パーティション）に分けて使う技術が開示されている（非特許文献１参照）。

特開２０００−２５９５８３号公報 "パーティションとその切り方"、[online]、[平成17年（2005年）2月8日検索]、インターネット<URL: http://nobumasa-web.hp.infoseek.co.jp/partition/partition.html>

特許文献１に開示された技術は、システム構築の際に用意すべきＬＵを、サーバ台数分用意する技術である。

一方、非特許文献１に開示された技術は、一つのＬＵに一つのサーバで実行可能な複数のＯＳを格納し、一台のサーバが必要なＯＳを選択的に実行できるように開発された技術である。

ここでＯＳとは、サーバの電源が入った直後に読み込まなければならないプログラム群のことを指すが、個々のサーバ構成の相違を認識してソフトウェア、ハードウェアの資源を初期化する機能を含むため、サーバ個別にどういう設定をしなければならないかを示す設定情報が必要であり、更に、各サーバ上でＯＳが立ち上がった後に動作を開始する各サーバ個別のアプリケーションプログラムも通常存在する。従って、サーバ個別のデータについては、サーバ毎に別々のＬＵに格納するのが望ましい。

一方、システムに誤りが生じ、ある特定のサーバの起動ができなくなった場合には、起動できなくなった原因の調査が必要である。原因調査のためには、何らかのＯＳとアプリケーションプログラムの使用が必要となるが、前記誤りによりＯＳが起動できないという事態が発生し得る。このような状況に対して、予め単純な構成で動作確認済みのＯＳを格納した保守ＬＵを用意しておくことが有用と考えられるが、これらについては、上記従来技術では考慮されていない。

更に、保守ＬＵについては、動作を確認するための単純な構成でよいため、上記従来技術のように、サーバ台数分のＬＵをサーバ毎に用意するのは、効率が悪く、これらのＬＵを確保することにより本番システム構築のためのＬＵ割当て作業や、障害対応作業が複雑になるという課題がある。

上記課題を解決するために、本発明の望ましい態様の一つは次の通りである。

第一のＯＳを実行する第一の計算機、第二のＯＳを実行する第二の計算機及び記憶装置システムとを有する計算機システムであって、ディスク装置は、第一のＯＳ、第二のＯＳ及びブートローダとを格納するＬＵを備え、ブートローダは、第一及び第二の計算機のいずれか一方の計算機上で実行され、該実行している計算機に対応する前記第一及び第二のＯＳのいずれかを、該実行している計算機に読み込み、該読み込んだＯＳを実行する。

本発明の望ましい他の態様の一つは次の通りである。

第一及び第二の計算機、及び記憶装置システムを有する計算機システムにおいて、ディスク装置は、第一、第二、及び第三のＬＵを備え、第一のＬＵは、第一の計算機で実行されるＯＳを格納し、第二のＬＵは、第二の計算機で実行されるＯＳを格納し、第三のＬＵは、第一の計算機で実行されるＯＳと第二の計算機で実行されるＯＳとを格納し、第一の計算機は、第一のＬＵに格納されたＯＳ及び第三のＬＵに格納されたＯＳのいずれか一方を選択的に起動し、第二の計算機は、第二のＬＵに格納されたＯＳ及び第三のＬＵに格納されたＯＳのいずれか一方を選択的に起動する。

以下に本発明の実施の形態を説明する。

図１は、本発明を実施するための計算機システムである。計算機システムは、複数のＣＰＵ101（ＣＰＵ1〜4）、記憶装置システム102、ネットワークスイッチ（ＮＷＳＷと表記）103、ファイバーチャネルスイッチ（ＦＣＳＷと表記）104、保守用計算機105、上位ネットワーク接続パス106、ＮＷＳＷ−ＣＰＵ間パス107、ＣＰＵ−ＦＣＳＷ間パス108、ＦＣＳＷ−記憶装置システム間パス109、保守用計算機パス110（点線で表記）とからなる。

ＣＰＵ101は、ディスクレスサーバであり、メインメモリ116と不揮発性のメモリ117（例えば、ＲＯＭ（Read Only Memory））を有する。尚、同一メモリの中に、揮発性の領域と不揮発性の領域を備えてもよい。

メモリ117は、計算機に接続された周辺機器を制御するためのプログラムであるＢＩＯＳ（Basic Input/Output System）を格納している。ＮＷＳＷは、上位ネットワーク接続のために二重化されている。

記憶装置システム102は、記憶制御装置111とディスク装置112とからなり、複数のＣＰＵ101により共有されている。ディスク装置112は、一般に磁気記憶媒体であるが、光学的記憶媒体等の他の記憶媒体を用いてもよい。ディスク装置112内は、論理的な構成で示しており、複数のＬＵ（ＬＵ1〜ＬＵ12）113、保守ＬＵ（ＬＵ0）114、記憶装置システム内パス115とからなる。尚、物理的には、複数のディスク装置が記憶制御装置に接続されていても良いことは言うまでもない。

図１中、SYS１と表記しているのは、LU2がCPU1のシステムボリュームであることを示している。同様に、SYS2（LU7）、SYS3（LU9）、SYS4（LU11）は、それぞれ、CPU2、CPU3、CPU4のシステムボリュームである。

ここで、システムボリュームとは、システムディスクとして最小限必要な部分とアプリケーションの動作に必要なファイルとを含むＬＵのことを表し、システムディスクとは、ＯＳを立ち上げるために必要なファイルを含むＬＵのことを表す。システムボリュームよりはシステムディスクの方が狭い概念であるが、システムディスクにアプリケーション関係のファイルが存在しても良いので、ほとんど違いはない。現実にはＯＳの起動技術に関する分野ではシステムディスクと呼び、計算機利用におけるアプリケーションに近い分野ではシステムボリュームと呼ぶが、本明細書では、システムＬＵで統一する。また、保守ＬＵとは、システムＬＵの一種であり、ＯＳとシステム設定用アプリケーションプログラムや動作確認用アプリケーションプログラムなど、計算機システムの保守に必要なファイルを格納したボリュームを意味する。

例えば、ＣＰＵ2を起動し、システムＬＵ（ＬＵ7）をアクセス可能にするためには、ＣＰＵ2からパス108-1、ＦＣＳＷ104-1、パス109-1、記憶制御装置111−2を経由して、又は、パス108-2、ＦＣＳＷ104-2、パス109-2を経由してＬＵ7をアクセスできるように、ＦＣＳＷ104-1、104-2及び記憶装置システム102を設定する必要がある。ＦＣＳＷ104の設定項目の一つとして、ＦＣＳＷのポートのどことどこを通信可能にするかを決めるゾーニングに関する設定が挙げられるが、すべてのポート間でアクセスを許可する設定にすればよい。記憶装置システム102へのアクセスに関する設定項目の一つとして、どのＬＵはどのＣＰＵからアクセスして良いかを決めるLUN Managementに関する設定が挙げられるが、ＬＵ7へのアクセス許可をＣＰＵ2にのみ与えるよう設定すればよい。これらの設定は、システムの管理者等が、保守用計算機105からパス110を介して実行する。これらの設定を予めしておけば、ＣＰＵ2の電源がオン、あるいは、リセットされることにより、ＢＩＯＳが起動され、ＬＵ7からのブートが開始される。ここで、ブートとは、人間がコンピュータに電源を投入してから、操作可能な状態になるまでに自動的に行われる一連の処理をいい、初期プログラムロードともいう。

図2は、ＣＰＵ101が実行するＢＩＯＳのフローを示す図である。

ＣＰＵ101の電源がオン、あるいは、リセットされると(201)、ＣＰＵ101は、ＢＩＯＳを実行する。次に、ハードウェアを初期化し（周辺装置の制御用レジスタの設定等）(202)、ブートを実行するための入出力デバイスを選択する(203)。選択肢としては記憶装置システム102内のシステムＬＵの他、フロッピー（登録商標）ディスクやＣＤ−ＲＯＭ等（図示せず）もあり得る。選択されたデバイスの先頭セクタにある制御テーブル（Master Boot Record;以下、ＭＢＲと称する）をメインメモリ116に読込み(204)、ＭＢＲ内の領域に格納されているプログラムである第１ブートローダを、実行する(205)。

図5は、１個のＬＵ114内に複数のパーティションが定義されているＬＵの構成例である。

ここでパーティションとは、１個のＬＵ内を複数の領域に分割した時、ＣＰＵ101で動作するＯＳからはあたかも別のＬＵであるかのように操作することができる領域の管理単位である。ＯＳの起動によりＬＵ内にファイルシステムが構築されるが、パーティションの概念が存在しないＬＵを仮定すると、そのＬＵの中にはファイルシステムが１個しか構築できない。ＬＵの中に複数のパーティションを定義すると、パーティション毎に別々のファイルシステムを構築することが可能となり、別々のＯＳをそれぞれのパーティションにインストールすることも可能となる。パーティションはＭＢＲにより定義され、ＯＳによりアクセスを制御する機構であり、従来はディスク装置側からは認識できないソフトウェアによる制御の概念である。また、パーティションはＭＢＲ内のパーティションテーブルによって直接定義可能な基本領域（基本パーティションとも呼ぶ）と、ＭＢＲから別の拡張パーティションテーブルをポイントしそこに定義することによる拡張領域（拡張パーティションとも呼ぶ）の２種類がある。ＭＢＲには、基本領域のみを設定しても良いし、拡張領域と基本領域両方の設定をしても良い。ディスク装置の技術分野では、区切られた領域を、パーティションテーブルにより定義される領域という意味で「パーティション」と呼ぶ慣習があり、ソフトウェアの技術分野ではＯＳのインストール方法の観点から基本領域（基本パーティションと同一の領域を指す）、拡張領域（拡張パーティションと同一の領域を指す）と呼ぶ慣習がある。本実施例では、パーティションを、領域という用語で統一する。1つのパーティション内を区切った領域も、領域と記載する（図中に番号を付与することにより、領域を区別する）。

尚、これらの領域に格納されるＯＳには、例えば、Linux、Windows（登録商標）、HP-UX、Solaris等が挙げられるが、これらに限定されるものではない。

ＬＵの先頭セクタにはＭＢＲ501が配置されており、ＭＢＲ501は、第１ブートローダが格納されている領域502と、１個のＬＵの内部をソフトウェア制御下で分割使用される領域の先頭位置や容量などが格納されている4つの領域503、504、505、506等から構成されている。尚、これら4つの領域は、パーティションテーブルと呼ばれる。

図6は、ＭＢＲ501の詳細を示す図である。ＭＢＲ501は全体として512バイトの長さであり、446バイトの領域502、16バイトの領域503、504、505、506（計64バイト）、2バイトのブートシグニチャ領域607から構成される。領域503（504〜506も同様）は、１バイトのブートフラグ601、ＣＨＳ（Cylinder Head Sector）表示による3バイトの領域開始位置802、１バイトの領域タイプ603、ＣＨＳ表示による3バイトの領域終了位置604、ＬＢＡ（Logical Block Address）表示による4バイトの領域開始位置605、ＬＢＡ表示による4バイトの領域の容量606から構成される。

ブートフラグ601とは、当該領域がブート可能か否かを示すフラグであり、この値が0x80であればブート可能、0x00であればブート不可能を表す。

領域タイプ603とは、当該領域はどのようなＯＳで用いられるディスク形式であるかを示しており、例えば、0x04ならＭＳ−ＤＯＳというＯＳで用いられるＦＡＴ１６という形式、0x83ならＬｉｎｕｘというＯＳで用いられるＥＸＴ２という形式を意味している。拡張領域へのポインタとなっている場合には、0x05、0x0F、0x85のいずれかの値をとる。又、当該ＬＵが後述する「複数ブートＬＵ」であるか否かを示す情報も含む。

ブートシグニチャ607は、0xAA55の値をとり、ＭＢＲとして有効であることを示す。

一般的な計算機システムでは各ＬＵの先頭セクタにＭＢＲが存在すべきであるが、特殊なＯＳによってフォーマットされたＬＵにはＭＢＲが存在しない場合もある。このように、本実施例で対象としない管理体系を採用するＯＳにおいては、ＭＢＲのブートシグニチャの位置にどのような値が入っているかは保証されない。一般的に0xAA55という値が偶然入ることは考えにくいので、この値が入っていることによりＭＢＲとして正しい形式で格納されていると判断するのである。この定義によれば、ＭＢＲで無い領域を偶然ＭＢＲとして誤判断する危険性がわずかにあるが、ＭＢＲ内のテーブルなどのフォーマットの矛盾の有無を検出することによりＭＢＲか否かを判定できる。

図5に戻って、領域503、504は、それぞれ、基本領域、拡張領域1をポイントしている（521、522）。尚、拡張領域は、1〜nまで定義されているものとする。領域505、506は、空きエントリとして使用されていない。拡張領域内の先頭にはＭＢＲ501と同じ形式の拡張領域ブートレコード（Extended Partition Boot Record；以下、ＥＰＢＲと称する）512が格納されている。ＥＰＢＲ512内の領域は未使用で、拡張領域1の第1エントリ513は拡張領域1(511)内の領域515の先頭位置や容量などを示している。第2エントリ514は拡張領域2の先頭位置をポイントしている(523)。拡張領域については同様の構成が繰り返し設定されてもよく、最後の拡張領域n(516)も拡張領域1(511)と同様な構成をとり、拡張領域nの第2エントリ518は空きとなる。

基本領域508内の領域509には、ＣＰＵが第1ブートローダを実行することによりメインメモリ116に読み込まれる第2ブートローダが格納されており、この機能によりどの領域のＯＳ（510、515、520）を起動するか選択する。

図3は、ＣＰＵ101が実行する第1ブートローダのフローを示す図である。

ＣＰＵ101は、第1ブートローダの実行を開始すると(301)、ＭＢＲ501内の領域503内の情報を検査し、「ブート可能」のフラグ0x80がブートフラグ601に設定されているか否かを判定する（302）。設定されていなければブート処理を中止し(303)、設定されていれば基本領域内の領域509に格納されている第2ブートローダをメインメモリ116に読込む(304)。最後に、読み込んだ第2ブートローダを実行する（305）。

図4は、ＣＰＵ101が実行する第2ブートローダのフローを示す図である。

ＣＰＵ101は、第2ブートローダの実行を開始すると(401)、そのＬＵ内の各領域内でブート可能なＯＳがそれぞれに入っているか否かを調べ、オペレータ（システム管理者等）に対して、その一覧表を操作用画面に提示し、オペレータの指定入力を待つ。すべての領域を調べるか、特定の個数の領域を調べるかは、第2ブートローダにより異なるが、ここでは、第3領域まで調べる例を示す。尚、操作用画面は、各CPUにそれぞれ専用のディスプレイとして備えられていてもよいし、ユーザが操作をするときだけ、一時的に接続されてもよい。

最初に基本領域508（第１領域）がブート可能か否かを調べ(402)、ブート可能であれば、そのＯＳの種類やオペレータが指定入力をする際に用いる番号を、操作用画面に表示し(403)、拡張領域1（511）（第2領域）の検査に移る。可能でなければ、表示せずに第2領域の検査に移る。

次に、第2領域がブート可能か否かを調べ(404)、第1領域に関する処理と同様の処理を行う（405）。次の第3領域に関する処理も同様である（406、407）。

その後、オペレータの入力を受け付け(408)、指定されたＯＳが格納されている領域から、当該ＯＳをメインメモリ116上に読込み(409)、読み込んだＯＳを実行する(410)。

上記ステップの中で第ｉ領域を参照する際には、ＭＢＲ501の領域から拡張領域へのポインタ（ＥＰＢＲ512、517）をたぐる必要があり、領域の個数に関連してディスク装置へのアクセス回数が増加していく。

図8は、保守ＬＵ114の構成例である。この場合、ＭＢＲ501からは１個の基本領域のみがポイントされ(521)、拡張領域は存在しない。この基本領域801内はＯＳ1(803)が実行されることにより管理されるファイルシステムとしてフォーマットされており、このファイルシステム中に、別のＯＳ2(805)〜ＯＳｎ(807)を格納するための領域が作成される。ここで、ＯＳ1(803)と同種のＯＳの場合は、ＯＳ1管理下のファイルシステムのサブディレクトリ（例えばＣＰＵｉ用のディレクトリを/bootdir/i/）として作成することができる。ＯＳ1(803)と異なる種類のＯＳで構成する場合は、領域804、806それぞれを物理的に連続な領域として確保し、一つの領域をＯＳ1ファイルシステム下では１個のファイル（例えばＣＰＵｉ用のファイルを/bootdir/OSfile-i）として作成する。

図7は、図8の保守ＬＵを作成する場合において、ＣＰＵ101が実行する第2ブートローダのフローを示す図である。尚、図8におけるＯＳｉはＣＰＵｉに対応するものとする。

第2ブートローダ起動の契機は図4の説明と同様である(701)。基本領域の領域タイプ603が図8に示す「複数ブートＬＵ」であることを示す場合は、ステップ703に飛び、そうでない場合にはステップ402に飛ぶ（図4のステップ402〜409の処理を実行）。ここで、複数ブートＬＵとは、ブートするためのＯＳが基本領域の中に複数格納されているＬＵ、すなわち、図8に示すＬＵのことを示す。尚、図8に示すＬＵのみを使用する場合には、ステップ702及び402乃至409の処理は不要である。

図8に示すＬＵの場合、ＣＰＵ101は、自らのＣＰＵ番号（識別子）ｉを求める(703)。ここでＣＰＵ番号とは図１に示すＣＰＵ101の１〜４の番号を意味する。ＣＰＵ番号を求める方法としては、予め定めたＩ／Ｏ空間のアドレスからスイッチで設定した値やメモリ117に記憶した値をＣＰＵ番号として読込み可能にしたり、自ＣＰＵのＦＣケーブル接続ポートのＷＷＮ（World Wide Name）を読込み、そのＷＷＮを持つＣＰＵ番号は何番であるかのテーブルを設け、そこから算出するという方法がある。

ｉ＝１の場合、基本領域にＯＳが存在するので、現在のルートディレクトリ下にあるＯＳをそのままメインメモリ116に読込み(705)、ＯＳに制御を移す(410)。ｉ≠１の場合、基本領域のファイルシステム下にＯＳが存在するので、ルートディレクトリをＣＰＵｉのＯＳが存在するディレクトリ（例えば、/bootdir/i/）に切り替えて(706)、切り替え後のルートディレクトリ下のＯＳをメインメモリ116に読込み(707)、ＯＳに制御を移す(708)。

このようにすることにより、任意のＯＳが指定されたとき、ファイルシステム下のファイル名称を指定してアクセスすることが可能となるので、ＭＢＲやＥＰＢＲをたどる方法に比べて効率良くＯＳを起動することができる。また、個々のＯＳ領域が別のＯＳ下のファイルとして操作可能となるので、ＣＰＵが動作不可能な場合でも、対応するＯＳの領域を別のＣＰＵからアクセスして操作でき、障害対応の面で有用となる。

実施例2では、図5に示すＬＵを用いて、複数ＯＳを起動する例を説明する。

図10は、実施例2における記憶装置システム102を示す。本実施例の特徴は、記憶制御装置111内の不揮発性のメモリ120（例えばＲＯＭ）に領域変換プログラム1001とＣＰＵ番号判定テーブル901を設けることにあり、その他の構成は、図１と同じである。

図11は、記憶制御装置111が、領域変換プログラム1201を実行して、ＣＰＵ101から記憶装置システム102へのRead/Writeアクセスをアクセス元のＣＰＵ番号に対応した領域内のアクセスに変換するときのフローを示す図である。尚、ここでも、ＯＳｉはＣＰＵｉに対応するものとする。

ＣＰＵ101からのアクセス要求がＬＵ0向けであり、かつ、そのＬＵ0が保守ＬＵとして予め指定されており、かつ、ＭＢＲ501が格納されているセクタへのアクセスであるとき、領域変換プログラム1001が起動される（1101）。

アクセス元ＣＰＵのディスクインタフェースアドレス（例えばＦＣ接続の場合はＣＰＵ側のＦＣポートのＷＷＮ）を求める(1102)。求めた値から図9に示すＣＰＵ番号判定テーブル901を用いてＣＰＵ番号ｉを求める(1103)。ｉ＝１の場合、基本領域へのアクセスなのでＣＰＵ側への転送データは変更せずにそのまま転送データとして準備する(1104)。ｉ≠１の場合、ＭＢＲ501の領域504に、求めたｉに対応する領域の先頭アドレスや容量などの情報を格納してＣＰＵ側への転送データとして準備する(1106)。ＣＰＵ番号に対応する領域の情報を求める方法としては、記憶制御装置111側でＭＢＲとＥＰＢＲを検索して求める方法、又は、予め記憶装置システム102の初期設定時にＣＰＵ毎の領域の情報をメモリ120に格納しておき、必要なときに読み出す方法等が考えられる。

図9は、ＣＰＵ番号判定テーブル901の構造例を示す。当該テーブルは、ＣＰＵ１台毎に１エントリのＣＰＵ側ディスクインタフェースアドレス格納領域902を保持している。ＣＰＵ101は、領域変換プログラム1001を実行して、本テーブルの先頭から順にインタフェースアドレスを比較し、一致した領域を見つけた時点のＣＰＵ番号がアクセス元のＣＰＵであると判定する。

以上のように、指定された複数ＣＰＵのブートを、各々共通の１個のシステムＬＵからブートすることを指定するだけで実行できる。

図12は、システム構築作業のフローを示す図である。

オペレータは、記憶装置システム102内のストレージ割当を、例えばＣＰＵ2について、保守用計算機105からパス110を介して、ＣＰＵ2の本番用システムＬＵ（ＬＵ7（113））の容量、属するＲＡＩＤグループ等を設定する（1201）。

次に、オペレータは、ＣＰＵ2にＬＵ7（113）に対するアクセス許可を与えるように、記憶装置システム102のLUN Management機能を用いて設定する(1202)。更に、ＦＣＳＷ104にＣＰＵ2と記憶装置システム102間のアクセスパスを設定し(1203)、ＮＷＳＷ103にＣＰＵ2と上位ネットワーク間のアクセスパスを設定する(1204)。

次に、ＣＰＵ2にＣＤ−ＲＯＭ等のシステム構築用デバイスを接続し、このデバイスからシステム構築用ＯＳを立ち上げ、ＬＵ7（113）を初期化する(1205)。そしてシステム構築用ＯＳの下で、ＬＵ7にＯＳをインストールし(1206)、ＬＵ7をブートするためのシステムＬＵとしてＣＰＵ2を再起動し(1207)、ＬＵ7のＯＳの下で関連アプリケーションプログラムをインストールし(1208)、ＣＰＵ2に関するシステム全体での動作を確認し(1209)、最後にシステム全体の動作を確認する（1210）。

図13は、図12において、構築中のシステムに障害が発生した場合の、フローを示す図である。

ディスク装置に関連した障害としては、次のようなケースが発生し得る。
・ステップ1205実施中にＬＵ7の初期化ができない。
・ステップ1206実施中にＯＳのインストールができない。
・ステップ1207実施中にＯＳをＬＵ７から起動ができない。
・ステップ1208実施中にアプリケーションプログラムがインストールできない。
・ステップ1209実施中に正常に動作しない。

上記のような障害が発生したら、システム構築時の障害調査作業を実施する。まず、ＣＰＵ2から保守ＬＵ（ＬＵ0（114））へのアクセスが可能となるよう、ＦＣＳＷ104を設定し(1301)、ＣＰＵ2のＢＩＯＳ設定により、システムＬＵをＬＵ0（114）に切り替えて再起動する(1302)。これで立ち上がれば動作確認を実施し(1303)、障害調査を実施しその障害内容に応じ、設定変更などの対応をとる(1304)。障害対応完了後、システム全体での動作確認を実施する(1210)。

図14は、工場出荷前のシステム確認作業のフローを示す図である。

まず、工場にてシステム連動試験実施構成を組み(1401)、試験用のＮＷＳＷ構成を設定し（1402）、試験用のＦＣＳＷの構成設定を全部のパスがアクセス可能となるように設定し（1403）、記憶装置システムに保守ＬＵ用のＲＡＩＤグループ及びＬＵ0を作成する（1404）。ＬＵ0内に各ＣＰＵ用のブート領域又はブートディレクトリを作成し（1405）、各々のＣＰＵ用のブート領域、ブートディレクトリ保守用ＯＳ、動作確認用アプリケーションプログラムなどを格納し（1406）、各々のＣＰＵを記憶装置システム102のＬＵ0からブートすることにより試験を実施する（1407）。

以上のように、1個のＬＵで保守ＬＵを構成すれば、システム構築作業を行なう際の障害調査が容易となり、製品出荷時の検査の際にも有用である。

尚、本稿で説明したプログラムは、ＣＤ−ＲＯＭ等の記憶媒体から移してもよいし、ネットワーク経由で他の装置からダウンロードしてもよい。

計算機システムの全体構成を示す図 ＢＩＯＳのフロー図 第1ブートローダのフロー図 第2ブートローダのフロー図 ＬＵの構成例を示す図 ＭＢＲの詳細を示す図 第2ブートローダの他のフロー図 ＬＵの他の構成例を示す図 ＣＰＵ番号判定テーブルの構造例を示す図 実施例2の計算機システムの全体構成を示す図 領域変換プログラムフロー図 システム構築作業のフロー図 構築中のシステムに障害が発生した場合のフロー図 工場出荷確認作業のフロー図

符号の説明

１０１…ＣＰＵ、１０２…記憶装置システム、１０３…ＮＷＳＷ、１０４…ＦＣＳＷ、１０５…保守用計算機、１０６…上位ネットワークパス、１０７…ＮＷＳＷ−ＣＰＵ間パス、１０８…ＣＰＵ−ＦＣＳＷ間パス、１０９…ＦＣＳＷ−記憶装置システム間パス、１１０…保守用計算機、１１１…記憶制御装置、１１２…ディスク装置、１１３…ＬＵ、１１４…保守ＬＵ。

Claims (2)

1. 第一の計算機と、第二の計算機と、前記第一及び第二の計算機に接続され、ディスク装置
   と前記ディスク装置を制御する記憶制御装置を有する記憶装置システムとを有する計算機
   システムであって、
   前記ディスク装置は、第一、第二、及び第三のＬＵを備え、
   前記第一のＬＵは、前記第一の計算機で実行されるＯＳを格納し、
   前記第二のＬＵは、前記第二の計算機で実行されるＯＳを格納し、
   前記第三のＬＵは、前記第一の計算機で実行される保守用ＯＳと前記第二の計算機で実行される保守用ＯＳと動作確認用アプリケーションプログラムを格納し、
   前記計算機システムにおいて障害が生じた場合に、
   前記記憶制御装置は、前記第一の計算機もしくは前記第二の計算機のいずれからのアクセス要求であることを特定し、前記各計算機に対応した前記第三のＬＵの格納領域を特定し、前記第三のＬＵに格納された保守用ＯＳと動作確認用アプリケーションプログラムを起動する、計算機システム。
2. 第一の計算機と、第二の計算機と、前記第一及び第二の計算機に接続され、第一、第二、
   及び第三のＬＵを有するディスク装置と、前記ディスク装置を制御する記憶制御装置を有する計算機システムのＯＳの起動方法であって、
   前記第一のＬＵは、前記第一の計算機で実行されるＯＳを格納し、
   前記第二のＬＵは、前記第二の計算機で実行されるＯＳを格納し、
   前記第三のＬＵは、前記第一の計算機で実行される保守用ＯＳと前記第二の計算機で実行される保守用ＯＳと動作確認用アプリケーションプログラムとを格納し、
   前記計算機システムにおいて障害が生じた場合に、
   前記第一の計算機もしくは前記第二の計算機のいずれからのアクセス要求であることを特定し、前記各計算機に対応した前記第三のＬＵの格納領域を特定し、前記第三のＬＵに格納された保守用ＯＳと動作確認用アプリケーションプログラムを起動する、計算機システムのＯＳの起動方法。

Images