JP2005301639A - Ｏｓの障害対応方法およびそのプログラム - Google Patents

Abstract

【課題】 低コストで信頼性の高いＯＳ障害対応技術を提供する。
【解決手段】第１ＯＳの回復不可能障害に備えて、あらかじめ障害対応にあたる第２ＯＳをメモリ上にローディングする。ゲートドライバ２０４は、第１ＯＳの障害発生を検知すると、第１ＯＳを退避し、第２ＯＳをメモリの実行可能な領域に移動し、第２ＯＳを起動する。その後、制御は第２ＯＳ制御下の障害対応アプリケーションに渡される。
【選択図】 図６

Description

本発明は、ＯＳの障害対応技術に関する。

計算機システムの中核をなすソフトウェアとして、オペレーティングシステムがある。オペレーティングシステム（ＯＳ）は、非特許文献１で開示されるように、拡張マシンを提供することによってハードウェアを抽象化し、アプリケーションプログラムの開発を特定のハードウェアに依存することなく、行うことができるようにするという特徴がある。さらにＯＳは、ハードウェアの機能を抽象化するにとどまらず、通信装置を利用した標準通信手順の実装による通信機能の提供、ファイル・システムによるストレージ装置に格納する情報の配置方法の標準化など、従来アプリケーション・プログラム側で行う必要があった機能を提供することにより、アプリケーション・プログラム開発コストの削減や信頼性の向上が可能となった。

また近代的なＯＳは、Ｉ／Ｏ装置ごとの分離されたデバイス・ドライバを静的または動的に追加/削除が可能な制御プログラムとして組み込むことを可能としている。この仕組みによって、ＯＳが対応するあらゆるＩ／Ｏ装置の制御用ルーチンを内蔵することなく、必要なＩ／Ｏ装置（デバイス）を組み合わせて計算機を構成し、各デバイスに対応するデバイス・ドライバをＯＳに組み込むことによって計算機システムを構築することが可能となった。さらに一歩進んで、ＯＳは、デバイス・ドライバについても様々なデバイス・ドライバで共通して利用される機能を提供することにより、デバイス・ドライバの開発コストを削減し、デバイス・ドライバ自身の信頼性向上を図ることができるようになった。

また計算機システムでは、ソフトウェア不良やハードウェアの故障等、様々な原因によってシステム障害が発生する。なかでも計算機システムの中核をなすオペレーティングシステムに回復不能な障害が発生した場合、従来はメモリダンプと呼ばれる障害発生時のメモリ状態を障害情報として収集し、その情報に基づいて障害解析を行ってきた。またデバイス・ドライバに障害対応機能を持たせることによって、様々なデバイスを利用して障害情報の収集を行う仕組みも実用化されている。

なおＯＳの障害対応方式として、バーチャルマシン（ＶＭ）を応用するデバッグ機能が知られている。これはＶＭ制御下のゲストＯＳの１つが障害の発生した他のゲストＯＳをデバッグする方式である。

ＯＳの基礎と応用 〜設計から実装、ＤＯＳから分散ＯＳ Ａｍｏｅｂａまで〜 Ａ．Ｓ．タネンバウム著／引地信之、引地美恵子訳

従来の方法においては、オペレーティングシステムに回復不能な障害が発生した場合、特定のハードウェアが存在することを前提に障害発生後の障害対応機能が実装されているか、またはデバイス・ドライバに障害対応機能を持たせることによって障害に対応してきた。しかし特定のデバイスに依存して障害対応機能を実装した場合、そのデバイス自身にハードウェア障害が発生した場合、障害対応を行うことができないという問題がある。またデバイス・ドライバに障害対応機能を実装した場合であっても、ＯＳが回復不能な障害に陥っているため、ＯＳによって提供されるデバイス・ドライバ向けの機能を利用せずに障害対応機能を実装しなければ信頼性の高い障害対応機能を提供できないという問題がある。

さらにＯＳが回復不能な障害に陥っているため、ＯＳ上で動作するアプリケーション・プログラムによる障害対応機能、ＯＳを通して行わなければならないデバイス・ドライバ間の連携を前提とした障害対応機能、アプリケーション・プログラムとデバイス・ドライバの連携による障害対応機能の実現は困難であるか、または実装した場合であっても、ＯＳ自身が障害状態に陥っていることから信頼性の低いものにならざるを得ないという問題があった。

またＶＭを応用する障害対応の場合、障害の発生したゲストＯＳと障害対応処理を行うゲストＯＳとの間の連絡にはＶＭ制御プログラムが介入するために、ＣＰＵオーバヘッドが生じることと、ＶＭ利用によるメモリ・オーバヘッドが多いという問題がある。

本発明の計算機は、１番目のＯＳ（第１ＯＳ）の回復不可能障害に備えて、あらかじめメモリ上に障害対応にあたる２番目のＯＳ（第２ＯＳ）をローディングする。第１ＯＳの障害発生を検知すると、計算機は、第２ＯＳを起動し障害対応処理を行う。

本発明によれば、第２ＯＳが起動された後には、メモリ上の第１ＯＳの領域および第２ＯＳの領域へのアクセスと利用可能なデバイスの利用だけで障害対応処理を進めることができる。これによって低コストで信頼性の高いＯＳ障害対応が可能である。

以下、本発明の実施形態について図面を用いて説明する。

図１は、本発明の一実施例である計算機のハードウェア構成を示す。計算機１０１は、ＣＰＵ１０２、メモリ１０３、Ｉ／Ｏコントローラ１０４、ストレージ１０５および通信装置１０６を有し、ディスプレイ１０８、キーボード／マウス１０９と接続されている。また計算機１０１は、通信装置１０６を介してネットワーク１０７に接続され、遠隔地に配置された計算機１１０と通信することもできる。ここでＣＰＵ１０２、ストレージ１０５、通信装置１０６等は１つだけとは限らず、複数の装置で構成することも可能である。

図２は、計算機１０１が有するストレージ１０５に格納される情報を示す。ストレージ１０５は、第１ＯＳファイルシステム２０１と障害情報収集領域２１３を有する。第１ＯＳファイルシステム２０１は、第１ＯＳカーネル２０２、第１ＯＳデバイス・ドライバ２０３、ゲートドライバ２０４、第２ＯＳローダ２０５、構成変更モジュール２０６、第２ＯＳカーネル２０７、第２ＯＳファイルシステム２０８、およびそのほか第１ＯＳの本発明にかかわらない情報を含む。さらに第２ＯＳファイルシステム２０８は、第２ＯＳデバイス・ドライバ２０９、ＨＷ（ハードウェア）構成定義テーブル２１０、ＳＷ（ソフトウェア）構成定義テーブル２１０および障害対応アプリケーション２１１を含む。

ここで第１ＯＳは、本発明における障害情報収集対象となるＯＳであり、通常の状態ではこの第１ＯＳだけが動作している。これに対し第２ＯＳは、第１ＯＳの障害発生時にゲートドライバ２０４によって起動され、第１ＯＳの障害情報収集や障害解析に利用されるＯＳである。ゲートドライバ２０４は、第１ＯＳの障害発生時に第２ＯＳを起動するためのモジュールであるが、第１ＯＳがユーザモード／カーネルモードの保護機能を有するＯＳの場合、カーネルモードで動作する第１ＯＳのカーネル拡張機能として実装するか、または第１ＯＳのカーネルにゲートドライバ相当の機能を内蔵させることも可能である。

第２ＯＳローダ２０５は、第１ＯＳ障害発生以前にメモリ上に第２ＯＳをローディングしておくための第１ＯＳ向けのアプリケーションである。構成変更モジュール２０６は、ハードウェアの構成変更や管理者からの障害対応方法変更命令をゲートドライバ２０４を介して第２ＯＳに通知するための第１ＯＳ向けアプリケーションである。

障害情報収集領域２１３は、収集された障害情報を格納する領域である。第２ＯＳカーネル２０７が第１ＯＳファイルシステム２０１を読み込み／書き出し操作できる場合、障害情報収集領域２１３を第１ＯＳファイルシステム２０１内に配置することも可能である。また第２ＯＳカーネル２０７や第２ＯＳファイルシステム２０８を第２ＯＳローダ２０５が読み込み操作できる第１ＯＳファイルシステム２０１以外の領域に配置する構成もとり得る。

このように構成された計算機１０１の起動手順を図３に示し、起動手順に従って計算機１０１上のメモリ１０３に配置される情報を図４に示す。計算機が起動される（ステップ３０１）と、まず第１ＯＳカーネル２０２がメモリ１０３上にローディングされ、第１ＯＳ領域４０２が作成され、第１ＯＳが起動される（ステップ３０２）。この手順の中で第１ＯＳは、ハードウェアの構成情報を収集し、Ｉ／Ｏ装置の制御に必要となるデバイス・ドライバを第１ＯＳファイルシステム２０１上の第１ＯＳデバイス・ドライバ２０３から選び出し、第１ＯＳ領域４０２内にローディングする。

続いてゲートドライバ２０４が第１ＯＳのカーネル拡張機能としてメモリ１０３上にローディングされ、起動される（ステップ３０３）。起動されたゲートドライバ２０４は、第１ＯＳに対し第２ＯＳが動作するために必要な領域（第２ＯＳカーネル２０７と第２ＯＳファイルシステム２０８の領域、第２ＯＳ領域）や後述のＯＳ切り替えに必要な予約領域４０７を確保する（ステップ３０４）。第２ＯＳカーネル２０７と第２ＯＳファイルシステム２０８の領域が実行中の第１ＯＳによって消去されてはならない。またこれらの領域は、障害発生時にかならずメモリ上に存在する必要があるため、第１ＯＳがデマンドページングをサポートするＯＳの場合でも、ページング非対象のメモリとして確保する必要がある。ページング非対象のメモリが確保できない場合には、ゲートドライバが第２ＯＳを動作させるために必要な領域や予約領域４０７を確保するのではなく、第１ＯＳ起動時に第１ＯＳの利用するメモリを制限し、第２ＯＳカーネル２０７と第２ＯＳファイルシステム２０８の領域、第２ＯＳ領域４０６および予約領域４０７をあらかじめ第１ＯＳから分離しておく方法もある。その場合、ステップ３０４は省略される。

次に第１ＯＳ上で動作するアプリケーションである第２ＯＳローダ２０５は、ストーレージ１０５に格納される第２ＯＳカーネル２０７と第２ＯＳファイルシステム２０８をメモリ１０３上にローディングする（ステップ３０５）。このローディングの際、第２ＯＳカーネル２０７上のエントリポイントとゲートドライバとのリンケージを行っておき、第２ＯＳが必要になった際、いつでも呼び出せるように準備しておく。

次にゲートドライバ２０４が第１ＯＳの障害発生を検知するフックを第１ＯＳカーネル２０２に埋め込む（ステップ３０６）。これは、一般的なＯＳが回復不可能な障害が発生した場合、ＯＳ内のいくつかの決まった関数（障害対応関数）が呼び出されることに着目し、障害が発生してそれらの障害対応関数が呼び出された場合、ゲートドライバ２０４に処理を切り替えるようにそれら障害対応関数の命令列を書き換えることを意味する。またＯＳによってはカーネル内の関数が呼び出された場合、それをきっかけとして別の関数を実行させるコールバックと呼ばれる機能を有するものも存在する。こうしたコールバック機能がある場合、ゲートドライバ２０４は障害対応関数にコールバックを登録することによって、障害対応関数のフックを実現することも可能である。さらにＯＳによってはカーネルに回復不可能な障害が発生した場合、カーネル・モジュールにそのことを通知する機能を有するものもある。ゲートドライバ２０４は、カーネル・モジュールとしてこうした障害通知を受けることができる場合、障害対応関数のフックの代わりに、デバイス・ドライバへの障害通知を利用することも可能である。

最後に構成変更モジュール２０６が起動される。構成変更モジュール２０６は、計算機のハードウェア構成を第２ＯＳファイルシステム２０８上に展開されたＨＷ構成定義テーブルに反映させ、障害解析方法の初期値をＳＷ構成定義テーブルに反映させる（ステップ３０７）。

計算機の運用中に計算機のハードウェア構成が変更された場合、構成変更モジュール２０６は、第２ＯＳファイルシステム２０８内のＨＷ構成定義テーブル２１０を変更する。またシステム管理者は、例えばダンプ取得先デバイスを変更するなど、障害対応方法を変更したい場合、構成変更モジュール２０６を通して第２ＯＳファイルシステム２０８内のＳＷ構成定義テーブル２１１を更新することによって実現することができる。

次に計算機システムに障害が発生した場合の処理手順について図５のフローチャートおよび図６のメモリマップを用いて説明する。図６中のメモリマップ６０３はゲートドライバ２０４呼び出し前のメモリ１０３の状態を示し、メモリマップ６０４はゲートドライバ２０４呼び出し後のメモリ１０３の状態を示している。計算機システムに障害が発生すると（ステップ５０１）、第１ＯＳの障害対応関数が呼び出される（ステップ５０２）。ここで計算機起動時に実施した障害対応関数のフックにより、ゲートドライバ２０４が呼び出される（ステップ５０３）。

ゲートドライバ２０４は、図６に示すように、第１ＯＳカーネル２０２の領域と第１ＯＳ領域４０２の中から、第２ＯＳカーネル２０７、第２ＯＳファイルシステム２０８、および第２ＯＳ領域４０６をコピーするために必要な大きさだけ、予約領域４０７にコピーする（ステップ５０４）。図６では第１ＯＳ領域の途中までを予約領域４０７にコピーした状態を例示している。次にゲートドライバ２０４は、第２ＯＳカーネル２０７、第２ＯＳファイルシステム２０８および第２ＯＳ領域４０６を第１ＯＳカーネル２０２と第１ＯＳ領域４０２が予約領域４０７に退避される前の領域にコピーする（ステップ５０５）。これらステップ５０４とステップ５０５は、第２ＯＳが特定の物理アドレスで動作することを前提に作られていることを想定している。従って第２ＯＳが任意の物理アドレスで起動する機能を有する場合、これらのステップは省略することが可能であり、また予約領域４０７を確保することも不要である。

第２ＯＳのコピーが完了すると、ゲートドライバ２０４は、第２ＯＳカーネル２０７を起動する（ステップ５０６）。第２ＯＳカーネル２０７は、ＨＷ構成定義テーブル２１０を参照して、第２ＯＳファイルシステム２０８の中から必要な第２ＯＳデバイス・ドライバ２０９を構成する（ステップ５０７）。

第２ＯＳデバイス・ドライバ２０９は、すでにステップ３０５で第２ＯＳファイルシステム２０８の一部としてメモリ１０３にローディングされ、ステップ５０５でメモリの別の領域にコピーされている。しかしステップ３０５の時点で必ずしも障害対応に必要なデバイス・ドライバが確定しているわけではない。ステップ５０７では、障害発生時に最新のＨＷ構成定義テーブル２１０に基づいて、この第２ＯＳデバイス・ドライバ２０９について不要なデバイス・ドライバを削除し、また必要に応じて第１ＯＳデバイス・ドライバ２０３から必要かつ利用可能なものを第２ＯＳデバイス・ドライバ２０９の領域にコピーして第２ＯＳデバイス・ドライバ２０９を再構成する。この処理によって第２ＯＳファイルシステム２０８のメモリ領域を削減することが可能である。

続いて管理者からの命令によって決定された第２ＯＳカーネル２０７の障害対応手順は、最新のＳＷ構成定義テーブル２１０を参照し、障害対応アプリケーション２１１を起動する（ステップ５０８）。

第２ＯＳカーネル２０７が実行するステップ５０７および５０８は、メモリ１０３上の第２ＯＳカーネル２０７、第２ＯＳファイルシステム２０８および第２ＯＳ領域４０６にのみアクセスし、ストレージ１０５などのデバイスにアクセスしないため、第１ＯＳの障害にストレージ１０５などのデバイスがからむ場合にも第２ＯＳカーネル２０７が動作できる。

障害対応アプリケーション２１１は、ＳＷ構成定義テーブル２１０に従って、障害対応処理を実施する（ステップ５０９）。ここで具体的な障害対応処理としては、第１ＯＳメモリダンプ、ネットワークを介した管理者への障害通知、リモートデバッグなどがある。

第１ＯＳメモリダンプは、ステップ５０４で退避された第１ＯＳカーネル２０１および分割された第１ＯＳ領域６０１、６０２をストレージ１０５の障害情報収集領域２１３に出力する機能である。ハードウェア構成が許せば、通信装置１０６およびネットワーク１０７を介して管理者が指定した計算機１１０にメモリダンプを送信することも可能である。

管理者への障害通知の場合には、障害対応アプリケーション２１２は、第２ＯＳの通信機能を利用し、通信装置１０６およびネットワーク１０７を介して管理者端末である計算機１１０に計算機１０１の障害発生を通知する。

リモートデバッグの場合には、管理者によってＳＷ構成定義テーブル２１１にリモートログインサービスが設定される。管理者は、計算機１１０からネットワーク１０７を介して計算機１０１にリモートログインを行う。第２ＯＳカーネル２０７は、ＳＷ構成定義テーブル２１１を参照してこのリモートログインを受け付ける。リモートログイン後に呼び出されるカーネルデバッガは、メモリマップ６０４のように退避された第１ＯＳカーネル２０２および第１ＯＳ領域６０１、６０２を参照しながらデバッグを行う。

実施例１では、第１ＯＳカーネル２０２と第２ＯＳカーネル２０７は、互いに異なるＯＳであると想定しているが、第２ＯＳカーネルの代わりに第１ＯＳカーネル自身をそのまま流用することも可能である。その場合、構成変更モジュール２０６または第２ＯＳローダ２０５の機能を拡張し、第１ＯＳファイルシステムのなかから必要なデバイス・ドライバを抽出して第２ＯＳデバイス・ドライバ２０９とすることによって実現できる。このときの第２ＯＳファイルシステムは、このように編成された第２ＯＳデバイス・ドライバ２０９、ＨＷ構成定義テーブル２１０、ＳＷ構成定義テーブル２１１および障害対応アプリケーション２１２によって構成される。

上記実施例１，２によれば、ＶＭ応用の障害対応方式に比べてＶＭ制御プログラムのようなプログラム実行が介入しないためＣＰＵオーバヘッドが生じないという効果がある。また第２ＯＳは、実際のハードウェア構成定義情報に基づいて必要なデバイス・ドライバのみを準備できるため、メモリオーバヘッドが少ないという効果がある。

上記実施例では、第２ＯＳ起動後に障害対応を行うことを例示したが、第２ＯＳは第１ＯＳと同等の機能を備えることが可能であるため、クラスタ構成のように、第２ＯＳが第１ＯＳの処理を引き継ぐような場合にも本発明を適用できる。

またＯＳによってはダンプ機能を持たないものもあるが、ダンプ機能のないＯＳに対しＯＳを改変することなくダンプ機能を追加するという本発明の利用方法もある。

実施例の計算機のハードウェア構成を示す図である。 実施例の計算機のストレージに格納される情報を示す図である。 実施例の計算機の起動手順を示すフローチャートである。 実施例の計算機起動時のメモリの状態を示す図である。 実施例の第１ＯＳ障害発生後の処理手順を示すフローチャートである。 実施例の第１ＯＳ障害発生後のメモリの状態変化を示す図である。

符号の説明

１０１：計算機、２０１：第１ＯＳファイルシステム、２０２：第１ＯＳカーネル、２０３：第１ＯＳデバイス・ドライバ、２０４：ゲートドライバ、２０５：第２ＯＳローダ、２０６：構成変更モジュール、２０７：第２ＯＳカーネル、２０８：第２ＯＳファイルシステム、２０９：第２ＯＳデバイス・ドライバ、２１０：ＨＷ構成定義テーブル、２１１：ＳＷ構成定義テーブル、２１２：障害対応アプリケーション、２１３：障害情報収集領域

Claims (15)

1. 計算機のメモリに第１のＯＳをロードして起動するステップと、
   前記メモリに前記第１のＯＳから消去されない第２のＯＳの領域を確保して前記第２のＯＳをロードするステップと、
   前記第１のＯＳの障害を検知したとき、前記第２のＯＳを起動するステップと、
   前記第２のＯＳの制御下で前記第１のＯＳの障害対応処理を実行するステップとを有することを特徴とするＯＳの障害対応方法。
2. さらに前記第１のＯＳの障害前に、前記第１のＯＳの障害発生を検知するためのフックを前記第１のＯＳに埋め込むステップを有することを特徴とする請求項１記載のＯＳの障害対応方法。
3. さらに前記第１のＯＳの障害前の前記計算機のハードウェア構成によって前記第２のＯＳのハードウェア構成定義情報を更新するステップを有することを特徴とする請求項１記載のＯＳの障害対応方法。
4. 前記第２のＯＳの起動後に、前記第２のＯＳによって前記第２のＯＳのハードウェア構成定義情報に従って必要なデバイス・ドライバを前記第２のＯＳの領域に残すように再構成するステップを有することを特徴とする請求項３記載のＯＳの障害対応方法。
5. 前記第２のＯＳを起動する前に、さらに前記第１のＯＳを前記メモリの予約領域に退避し、前記第２のＯＳを前記第１のＯＳの元の領域に移動するステップを有することを特徴とする請求項１記載のＯＳの障害対応方法。
6. 前記障害対応処理を実行するステップは、前記第２のＯＳによって障害の発生した前記メモリ上の前記第１のＯＳをストレージに記録することを特徴とする請求項１記載のＯＳの障害対応方法。
7. 前記第２のＯＳのカーネルは、前記第１のＯＳのカーネルと同一であることを特徴とする請求項１記載のＯＳの障害対応方法。
8. さらに前記第１のＯＳの障害前に、前記第１のＯＳのデバイス・ドライバの中から必要なデバイス・ドライバを抽出して前記第２のＯＳのデバイス・ドライバとするステップを有することを特徴とする請求項７記載のＯＳの障害対応方法。
9. 第１のＯＳが動作する計算機に、前記計算機のメモリに前記第１のＯＳから消去されない第２のＯＳの領域を確保して前記第２のＯＳをロードする機能、
   前記第１のＯＳの障害を検知したとき、前記第２のＯＳを起動する機能、および
   前記第２のＯＳの制御下で実行される障害対応アプリケーションに制御を渡す機能を実現させるためのプログラム。
10. さらに前記計算機に、前記第１のＯＳの障害前に、前記第１のＯＳの障害発生を検知するためのフックを前記第１のＯＳに埋め込む機能を実現させるための請求項９記載のプログラム。
11. さらに前記計算機に、前記第１のＯＳの障害前の前記計算機のハードウェア構成によって前記第２のＯＳのハードウェア構成定義情報を更新する機能を実現させるための請求項９記載のプログラム。
12. さらに前記計算機に、前記第２のＯＳの起動後に、前記第２のＯＳのハードウェア構成定義情報に従って必要なデバイス・ドライバを前記第２のＯＳの領域に残すように再構成する機能を実現させるための請求項１１記載のプログラム。
13. さらに前記計算機に、前記第２のＯＳを起動する前に、前記第１のＯＳを前記メモリの予約領域に退避し、前記第２のＯＳを前記第１のＯＳの元の領域に移動する機能を実現させるための請求項９記載のプログラム。
14. 前記第２のＯＳのカーネルは、前記第１のＯＳのカーネルと同一であることを特徴とする請求項９記載のプログラム。
15. さらに前記計算機に、前記第１のＯＳの障害前に、前記第１のＯＳのデバイス・ドライバの中から必要なデバイス・ドライバを抽出して前記第２のＯＳのデバイス・ドライバとする機能を実現させるための請求項１４記載のプログラム。
    

Images