JPH06230992A

JPH06230992A - 計算機システムおよび計算機システムの障害回復方法

Info

Publication number: JPH06230992A
Application number: JP5041918A
Authority: JP
Inventors: Yoshifumi Takamoto; 良史高本; Hitoshi Tsunoda; 仁角田
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1993-02-06
Filing date: 1993-02-06
Publication date: 1994-08-19

Abstract

(57)【要約】【目的】低コストでかつ高信頼な計算機システムおよび
その障害回復方法を提供することを目的とする。【構成】複数の構成要素を備えた計算機システムにおい
て、ある構成要素（例えばディスク装置１０６の圧縮機
構１１３）に障害が発生したとき、その構成要素を代替
して機能する代替構成要素（ＣＰＵ１１４によるエミュ
レーションなど）を探索し、その代替構成要素に代替処
理を行なわせる。また、障害を起こした構成要素を代替
する処理を他の装置（ディスク装置１０７）やホストプ
ロセッサ（１０１）に依頼して、代替処理を行なわせ
る。【効果】多数の装置を接続しても信頼性が低下すること
がなく、また低コストで信頼性の高いシステムを構築で
きる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、計算機システムおよび
その障害回復方法に関し、特に高信頼性および高い拡張
性が要求されるファイルシステムを備えた計算機システ
ムなどに適用して好適な障害回復方法および計算機シス
テムに関する。

【０００２】

【従来の技術】ハードウェアの信頼性を向上させる手法
として、一般にはハードウェアの二重化や符号による誤
り訂正といった技術が用いられる。例えば、ディスクシ
ステムにおいても、格納ディスクドライブの多重化、制
御プロセッサの多重化、あるいはデータパスの多重化な
どにより、高い信頼性を保証するシステムが多数存在す
る。

【０００３】格納ディスクドライブの多重化は、同一デ
ータを複数のディスクドライブに格納しておき、もし何
れかのディスクドライブあるいはディスクドライブを制
御する制御装置が障害を起こしたときには、同一データ
が格納された他のディスクドライブにアクセスすること
で処理を中断させないようにするものである。

【０００４】ここで、同一データを複数のディスクドラ
イブに格納する方式としては、大きく２種類の方式が存
在する。１つは、ソフトウェア（一般には、オペレーテ
ィングシステム）が複数のディスクドライブにデータを
格納する入出力命令をそれぞれ発行する方式である。も
う１つは、オペレーティングシステムは一回の入出力命
令を発行し、その一回の入出力命令でディスク制御装置
が自動的に複数のディスクドライブに格納するようにハ
ードウェア制御を行なう方式である。

【０００５】現状では、ハードウェアコストが低減され
たことや、ソフトウェアの負荷削減などの理由から、後
者のハードウェア制御によるディスクドライブ多重化が
行なわれるようになってきている。こういった環境で、
何れかのディスクドライブのアクセスが不可能に陥った
場合には、ハードウェアが障害を検知し、自動的に他の
ディスクドライブで代用する制御を行なう。こういった
制御は、例えば、特開平３−２２６８２５号公報などに
記載されている。

【０００６】一方、制御プロセッサの多重化やデータパ
スの多重化も、同様に、障害発生時には障害を起こして
いない制御プロセッサやデータパスを使用し、これによ
り高信頼性を保証している。一般には、システムを構成
する要素の内、最も障害の発生しやすい箇所やあるいは
システムバスといったシステムの中核となる箇所での多
重化を行なっている。

【０００７】

【発明が解決しようとする課題】上述した多重化技術
は、比較的容易に信頼性を向上させることができるとい
ったメリットを持つ。しかし、ある意味ではリソースを
無駄に使用していることにもなる。ハードウェアコスト
が以前に比べ低下したとはいえ、これら多重化されたシ
ステムを多数連結させるような大規模システムでは、多
重化によるコストが大きくなる。

【０００８】さらに、上記従来技術では、あらかじめ定
められた多重度を容易に変更することができない。例え
ば、始めに二重化で設計されたシステムを、容易に三重
化、四重化にすることは難しい。始めに二重化で設計さ
れたシステムは、実装上、さらに三重化、四重化するた
めのハードウエアを組み込むことが難しいからである。
また、多重化制御用ハードウェアの仕様変更コストなど
によるコスト高が生じるからである。こういった場合、
通常は、さらに上位のソフトウェアによる多重化などを
行なわなければならない。

【０００９】本発明は、上述の従来例における問題点に
鑑み、低コストでかつ高信頼な計算機システムおよびそ
の障害回復方法を提供することを目的とする。

【００１０】

【課題を解決するための手段】上記目的を達成するた
め、本発明は、複数の構成要素を備えた計算機システム
において、上記構成要素の障害を検知する検知手段と、
ある構成要素に障害が発生したとき、その構成要素を代
替して機能する代替構成要素を探索する探索手段と、探
索された代替構成要素に対し、障害が発生した構成要素
を代替する処理を行なわせる管理手段とを備えたことを
特徴とする。

【００１１】また、ホストプロセッサを備えた計算機シ
ステムまたはネットワークに接続される周辺機器であっ
て、複数の構成要素を備えた周辺機器において、上記構
成要素の障害を検知する検知手段と、ある構成要素に障
害が発生したとき、内部の他の構成要素中から障害を起
こした構成要素を代替して機能する代替構成要素を探索
する探索手段と、探索された代替構成要素に対し、障害
が発生した構成要素を代替する処理を行なわせる管理手
段とを備えたことを特徴とする。

【００１２】前記代替構成要素は、例えばプログラムを
実行可能なプロセッサを備えており、該プロセッサを用
いて、前記障害が発生した構成要素の動作をエミュレー
ションまたはシミュレーションにより模擬してもよい。
また、前記障害が発生した構成要素がデータ圧縮機構で
ある場合、前記プロセッサはデータ圧縮のエミュレーシ
ョンを行なってデータ圧縮機構を代替する処理を行なう
とよい。

【００１３】前記探索手段は、障害が発生した構成要素
を示すデータ、およびその構成要素を代替する代替構成
要素を示すデータを含むデータ列を生成して、前記管理
手段へと送り、前記管理手段は、該データ列に基づいて
前記代替する処理を行なわせるようにしてもよい。

【００１４】さらに、前記構成要素に障害が発生してい
るかどうかを示すデータと、障害が発生したときその構
成要素を代替する処理を表すデータとを格納した構成管
理テーブルを備え、前記検知手段は、該構成管理テーブ
ルを参照して、構成要素の障害を検知し、前記探索手段
は、該構成管理テーブルを参照して、障害が発生した構
成要素を代替する処理を探索するようにしてもよい。

【００１５】さらに、前記各構成要素の障害を検知した
とき、再度その構成要素に同じ動作を反復させ、所定回
数以下の反復動作によりその構成要素が正常に動作した
ときには、その構成要素には障害が発生しなかったもの
として動作を継続するとともに、そのような反復動作に
より正常動作に移行した回数を数え、該回数が所定値を
越えたときにはその旨を外部に伝えるようにしてもよ
い。

【００１６】前記構成要素は、多重化されていてもよ
い。前記管理手段自体が、前記障害が発生した構成要素
を代替する処理を行なうことが可能な構成要素であって
もよい。前記構成要素は、例えば計算機システムのファ
イルシステムを構成する構成要素である。

【００１７】さらに、本発明は、ホストプロセッサと、
複数の周辺機器とを備えた計算機システムであって、そ
の各周辺機器は複数の構成要素を備えている、計算機シ
ステムにおいて、上記周辺機器の構成要素の障害を検知
する検知手段と、ある構成要素に障害が発生したとき、
その構成要素を含む周辺機器以外の周辺機器または上記
ホストプロセッサにより、障害が発生した構成要素を代
替する処理を行なわせる管理手段とを備えたことを特徴
とする。

【００１８】前記管理手段は、障害回復処理依頼である
ことを示す識別子、障害を起こした構成要素を示す識別
子、および依頼する処理を示す識別子を含むデータ列を
生成して送出することにより、前記周辺機器またはホス
トプロセッサに代替処理を行なわせるようにしてもよ
い。また、前記管理手段は、前記データ列を複数の周辺
機器に対して送信し、該データ列に格納された要求を処
理可能な周辺機器が、該データ列に基づく代替処理を行
なうようにしてもよい。

【００１９】さらに、前記構成要素に障害が発生してい
るかどうかを示すデータと、障害が発生したときその構
成要素を代替する処理あるいは代替手段を表すデータと
を格納した構成管理テーブルを備え、前記検知手段は、
該構成管理テーブルを参照して、構成要素の障害を検知
し、前記管理手段は、該構成管理テーブルを参照して、
どこに前記代替する処理を行なわせるかを決定するよう
にしてもよい。

【００２０】前記周辺機器は、多重化されていてもよ
い。また、前記周辺機器は、計算機システムのファイル
システムであってもよい。

【００２１】さらに、本発明は、ホストプロセッサと、
互いに通信可能な複数のファイルシステムとを備えた計
算機システムであって、その各ファイルシステムはディ
スクデバイスを含む複数の構成要素を備えているととも
に、各ファイルシステム間のクロスコールにより、互い
に他のファイルシステムのディスクデバイスにアクセス
できる、計算機システムにおいて、上記ファイルシステ
ムの構成要素の障害を検知する手段と、ディスクデバイ
ス以外の構成要素に障害が発生したとき、その構成要素
を含むファイルシステム以外のファイルシステムに対
し、障害が発生した構成要素を代替する処理を依頼する
手段とを備え、該依頼を受けたファイルシステムは、そ
の依頼に基づいて代替処理を行なうとともに、クロスコ
ールにより、前記障害が発生した構成要素を含むファイ
ルシステムのディスクデバイスに、直接アクセスするこ
とを特徴とする。

【００２２】また、本発明に係る計算機システムの周辺
機器は、ホストプロセッサを備えた計算機システムまた
はネットワークに接続される周辺機器であって、複数の
構成要素を備えた周辺機器において、自周辺機器の内部
にある構成要素の障害を検知する手段と、ある構成要素
に障害が発生したとき、他周辺機器に対して、その障害
が発生した構成要素を代替する処理を依頼するデータ列
を送出する手段と、他周辺機器から上記依頼した処理の
処理結果を受取ったときは、上記障害を起こした構成要
素をバイパスして、処理を継続する手段と、他周辺機器
から上記障害が発生した構成要素を代替する処理を依頼
するデータ列を受けたときは、該データ列の依頼に基づ
いて処理を行ない、処理結果を上記データ列の送出元に
返送する手段とを備えたことを特徴とする。

【００２３】また、ホストプロセッサを備えた計算機シ
ステムまたはネットワークに接続される周辺機器であっ
て、複数の構成要素を備えた周辺機器において、自周辺
機器の内部にある構成要素の障害を検知する手段と、あ
る構成要素に障害が発生したとき、上記ホストプロセッ
サに対して、その障害が発生した構成要素を代替する処
理を依頼するデータ列を送出する手段と、上記ホストプ
ロセッサから上記依頼した処理の処理結果を受取ったと
きは、上記障害を起こした構成要素をバイパスして、処
理を継続する手段とを備えたことを特徴とする。

【００２４】さらに、本発明は、ホストプロセッサと、
該ホストプロセッサに接続される周辺機器とを備えた計
算機システムにおいて、該周辺機器は、通常は自機器の
内部で行なう処理を、他の周辺機器またはホストプロセ
ッサに依頼する手段を備えたことを特徴とする。

【００２５】また、プログラムを実行可能なプロセッサ
を含む複数の構成要素を備えた計算機システムにおい
て、上記プロセッサ以外の構成要素の動作を上記プロセ
ッサでエミュレートまたはシミュレートし、上記構成要
素による処理結果と上記プロセッサによるエミュレート
またはシミュレートの結果とを比較する手段と備えたこ
とを特徴とする。

【００２６】さらに、本発明に係る計算機システムの障
害回復方法は、複数の構成要素を備えた計算機システム
の障害回復方法において、上記構成要素の障害を検知す
るステップと、ある構成要素に障害が発生したとき、そ
の構成要素を代替して機能する代替構成要素を探索する
ステップと、探索された代替構成要素に対し、障害が発
生した構成要素を代替する処理を行なわせるステップと
を備えたことを特徴とする。

【００２７】また、ホストプロセッサと、複数の周辺機
器とを備えた計算機システムであって、その各周辺機器
は複数の構成要素を備えている計算機システムの障害回
復方法において、上記周辺機器の構成要素の障害を検知
するステップと、ある構成要素に障害が発生したとき、
その構成要素を含む周辺機器以外の周辺機器または上記
ホストプロセッサにより、障害が発生した構成要素を代
替する処理を行なわせるステップとを備えたことを特徴
とする。

【００２８】

【作用】複数の構成要素を備えた計算機システムにおい
て、ある構成要素に障害が発生したとき、その構成要素
を代替して機能する代替構成要素を探索し、その代替構
成要素に障害が発生した構成要素を代替する処理を行な
わせるようにしているので、例えばエミュレーションな
どにより障害を起こしたハードウェアと同等の処理を行
なうようにすることができ、これにより低コストで高信
頼なシステムを構築できる。

【００２９】また、障害を起こした構成要素を代替する
処理を他の周辺機器やホストプロセッサに依頼すること
ができるので、通信可能な周辺機器やホストプロセッサ
であればどこへでも障害回復依頼を行なうことができ、
その結果を障害発生した機器へ転送することができ、処
理を中断させない高信頼なシステムの構築が可能にな
る。

【００３０】

【実施例】以下、図面を用いて、本発明の実施例を詳細
に説明する。

【００３１】［実施例１］図１は、本発明の一実施例に
係る計算機システムであり、かつ、本発明の障害回復方
法を適用したディスクシステム（周辺機器）を用いた計
算機システムを示したものである。

【００３２】このシステムは、大きく分けて、ホストプ
ロセッサ１０１，１０２とディスク装置１０６，１０７
とから構成され、両者はチャネルケーブル１８１，１８
２により接続されている。チャネルケーブル１８１，１
８２の制御のために、ホストプロセッサ１０１，１０２
側には入出力プロセッサ（ＩＯＰ）１０３，１０４が、
ディスク装置側にはチャネルアダプタ１０５が、それぞ
れ設置されている。チャネルアダプタ１０５とディスク
装置１０６，１０７は、システムバス１８３に接続され
ている。

【００３３】ホストプロセッサ１０１，１０２はディス
ク装置１０６，１０７に対して入出力要求を発行し、要
求を受けたディスク装置１０６，１０７は、要求内容に
従ってデータの読出し／書込み（READ/WRITE）などを行
ない、結果をホストプロセッサ１０１，１０２に通知す
る。ディスク装置１０６，１０７は、本実施例では匡体
イメージである。ディスク装置１０６のように、１つの
匡体内に複数のディスクシステム（ファイルシステム）
が入っていてもよい。

【００３４】ディスク装置１０６は、構成管理テーブル
１１１，１３１、障害管理部１１２，１１６，１３２，
１３６、オプション機構（ＯＰ）１１３，１３３、制御
プロセッサ（ＣＰＵ）１１４，１１７，１３４，１３
７、キャッシュメモリ１１５，１３５、ディスクドライ
ブ１１８，１１９，１３８，１３９から成る。同様に、
ディスク装置１０７は、構成管理テーブル１５１、障害
管理部１５２，１５６、オプション機構１５３、制御プ
ロセッサ１５４，１５７、キャッシュメモリ１５５、デ
ィスクドライブ１５８，１５９から成る。図から分かる
ように、ディスク装置１０６は、左側と右側の２つのデ
ィスクシステムを備えている。

【００３５】構成管理テーブル１１１，１３１，１５１
は、それぞれ、ディスク装置１０６，１０７内の各構成
要素の障害に関する情報を管理している。障害管理部１
１２，１１６，１３２，１３６，１５２，１５６は、本
発明の特徴の１つであり、ディスク装置１０６，１０７
内の各構成要素が障害を起こした場合、できるだけ処理
を停止させないように管理する部分である。障害管理部
１１２，１１６，１３２，１３６，１５２，１５６は、
それぞれ、システムバス１８３に接続されている。

【００３６】オプション機構１１３，１３３，１５３
は、ディスク装置を高機能化するための機構であり、ユ
ーザにとって便利な機能が１つあるいは複数設定するこ
とができる。以下、本実施例では圧縮機構を例にとって
説明するが、特に圧縮に限る必要はない。

【００３７】制御プロセッサ１１４，１１７，１３４，
１３７，１５４，１５７は、ディスク装置１０６，１０
７全体を制御し、例えばホストプロセッサ１０１，１０
２からのコマンドを解釈したり、キャッシュメモリ１１
５，１３５，１５５内のデータ管理などを行なう。ディ
スクドライブ１１８，１１９，１３８，１３９，１５
８，１５９には、ユーザのデータなどが格納されてい
る。

【００３８】また、１２１〜１２６，１４１〜１４６，
１６１〜１６６は、それぞれ構成管理テーブル１１１，
１３１，１５１の更新／参照を意味する。１２７，１４
７，１６７，１２８，１４８，１６８は、オプション機
構や制御プロセッサの制御を受けないで、直接にデータ
を次の処理構成部へ転送するためのパスである。これら
についての詳細は、後に詳しく説明する。

【００３９】図２は、本実施例における障害回復の流れ
の一例（概略）を示したフローチャートである。

【００４０】ある構成要素に障害が発生すると、まずそ
の構成要素が多重化されているかどうかを調べる（ステ
ップ２０１）。その結果、多重化されていてかつ代用可
能な構成要素があるなら（ステップ２０５）、代用可能
な構成要素で代替して処理を続行する。

【００４１】多重化を利用できない場合（構成要素が多
重化されていない場合、または多重化されていても代用
が不可能な場合）は、同等の機能をエミュレーション可
能かどうか調べる（ステップ２０２）。ここで、エミュ
レーションとは、本来ハードウェアが実行する処理をソ
フトウェア的な手段で代用することを意味する。エミュ
レーション可能ならば、そのエミュレーションを実行
し、エミュレーション処理が正常終了したかどうかを判
別する（ステップ２０６）。処理が正常終了したなら
ば、継続して処理を続行する。

【００４２】さらに、エミュレーション不可能またはエ
ミュレーション異常終了のときは、ディスク装置が通信
可能な範囲で他のディスク装置に対して同一の処理を依
頼できるかどうか調べる（ステップ２０３）。他装置へ
依頼可能であれば、その処理をその他装置へ依頼して実
行してもらい、その処理が正常終了したかどうかを判別
する（ステップ２０７）。処理が正常終了したならば、
継続して処理を続行する。

【００４３】さらに、他装置への依頼が不可能または他
装置へ依頼した処理が異常終了のときは、ホストに対し
て同一の処理を依頼できるかどうか調べる（ステップ２
０４）。ホストに対して依頼可能であれば、その処理を
ホストに依頼して実行してもらい、その処理が正常終了
したかどうかを判別する（ステップ２０８）。処理が正
常終了したならば、継続して処理を続行する。ホストへ
の依頼も不可能またはホストへ依頼した処理が異常終了
したときは、入出力要求を発行したホストに対して、回
復不可能の障害発生した旨を通知した後、異常終了す
る。

【００４４】このようにして、本実施例では、障害回復
の手段を多段化している。従来は、高々、多重化した構
成要素を代用するだけの障害回復であったが、図２のよ
うに障害回復の手段を多段化することにより、装置に対
する信頼性をより高めることができる。

【００４５】次に、障害管理部１１２，１３２，１５２
について、詳細に説明する。３つの障害管理部１１２，
１３２，１５２の構成および動作は同様であるので、以
下では障害管理部１１２について説明するものとし、障
害管理部１３２，１５２については説明を省略する。

【００４６】図３は、障害管理部１１２のブロック図を
示す。３０１はコマンド解析プロセッサ、３０２はコマ
ンドバッファ、３０３はデータバッファ、３０４は障害
検知プロセッサ、３０５は障害管理プロセッサ、３０６
は障害管理プロセッサが実行すべきマイクロプログラム
が格納されたメモリ、３１１はデータバッファ内のデー
タの転送先を切り替えるセレクタである。メモリ３０６
には、エミュレーションをリクエストするマイクロプロ
グラム３０７、外部装置による代替処理をリクエストす
るマイクロプログラム３０８、およびホストによる代替
処理をリクエストするマイクロプログラム３０９が格納
されている。

【００４７】障害管理部１１２における処理の概要を説
明する。まず、システムバス１８３を介して転送された
コマンドがコマンド解析プロセッサ３０１で解釈され、
そのコマンドを実行するためにディスクシステム内のど
の構成要素を必要とするのかが解析される。その結果
は、障害検知プロセッサ３０４に転送される。これを受
けて、障害検知部３０４は、処理に必要な構成要素が実
行可能状態にあるのかどうかを判別する。この判別は、
構成管理テーブル１１１を参照することにより行なう。

【００４８】処理に必要な構成要素が障害を起こしてい
た場合、障害検知プロセッサ３０４は、再度、構成管理
テーブル１１１を参照し、障害を起こした構成要素を代
替する代わりの処理方法が存在するかどうかを検索す
る。

【００４９】もし代わりの処理方法が見つかれば、その
情報を障害管理プロセッサ３０５へ転送し、代わりの処
理を依頼する。その依頼を受けた障害管理プロセッサ３
０５は、その依頼に応じて、メモリ３０６内のマイクロ
プログラムを実行する。また、障害管理プロセッサ３０
５は、代わりの処理がどこで実行されたかに基づいてセ
レクタ３１１のデータ転送先を切り替える。

【００５０】この実施例では、代わりの処理（代替処
理）として、図２に示したように、同一構成要素の多重
化による方法のほか、エミュレーションによる方法、外
部装置に処理依頼を行なう方法、およびホストに対して
処理依頼を行なう方法などが設けられている。したがっ
て、障害管理プロセッサ３０５は、代替処理を、エミュ
レーションにより行なう場合はエミュレーションリクエ
ストプログラム３０７を、外部装置に処理依頼を行なう
場合は外部装置リクエストプログラム３０８を、ホスト
に対して処理依頼を行なう場合はホストリクエストプロ
グラム３０９を、それぞれ実行することとなる。

【００５１】上記の処理により、障害が発生しても処理
を中断することなく継続して実行可能となる。

【００５２】次に、障害管理部１１６，１３６，１５６
について説明する。３つの障害管理部１１６，１３６，
１５６の構成および動作は同様であるので、以下では障
害管理部１１６について説明する。また、障害管理部１
１６の構成および動作は、上述の障害管理部１１２と同
様であるので、以下では、特に異なる部分について説明
する。

【００５３】図４は、図１の障害管理部１１６のブロッ
ク図を示したものである。障害管理部１１６の構成要素
４０１〜４１１は、図３の障害管理部１１２の構成要素
３０１〜３１１と同等のものである。ただし、障害管理
部１１６では、必要な機能が少ない。これは、オプショ
ン機構を管理していないためである。

【００５４】オプション機構を管理していないので、オ
プション機構へのデータパスの切り替えの必要がなく、
またオプション機構のエミュレーションをリクエストす
ることもないので、メモリ４０６内にエミュレーション
リクエストプログラムを備える必要もない。したがっ
て、図４では、図３のデータパス３１２やエミュレーシ
ョンリクエストプログラム３０７に相当する部分はな
い。

【００５５】このように、障害管理部１１２，１３２，
１５２，１１６，１３６，１５６は、それぞれ、その管
理する対象に応じて必要な機能のみを備えていればよ
い。したがって、障害管理部を設けるにあたっては、コ
ストを最小限に抑えることができる。

【００５６】図５は、構成管理テーブル１１１の構造を
示したものである。構成管理テーブル１３１，１５１も
同様の構成である。

【００５７】図５において、５０１は当該ディスクシス
テムの構成要素を示し、例えば圧縮機構１１３、制御プ
ロセッサ１１４，１１７、キャッシュメモリ１１５、デ
ィスクドライブ１１８，１１９などがそれにあたる。図
５の構成要素５０１の欄が「圧縮機構（ＯＰ）」とある
のは圧縮機構１１３を、「制御ＣＰＵ１」とあるのは制
御プロセッサ１１４を、「制御ＣＰＵ２」とあるのは制
御プロセッサ１１７を、「キャッシュ」とあるのはキャ
ッシュメモリ１１５を、「ドライブ１」とあるのはディ
スクドライブ１１８を、「ドライブ２」とあるのはディ
スクドライブ１１９を、それぞれ示している。

【００５８】５０２は各構成要素の多重化の情報を記憶
する領域を示す。ここには、当該構成要素が、もし単独
で存在するなら”１”、２重化されているなら”２”な
どと格納されている。ある構成要素がｎ重化されている
とき、その構成要素はｎ個の同じ要素を内部に備えてい
ることになるが、それらｎ個の要素を部分要素と呼ぶも
のとする。多重化の情報５０２により、多重化による代
替処理が可能かどうかがわかる。もし、多重化された構
成要素中の部分要素に障害が発生し、その部分要素が利
用不可能になった場合は、本フィールドの値は障害が起
こった部分要素の数だけ引かれる。

【００５９】５０３は当該構成要素の障害の有無を示
す。多重度による障害回復ができなくなったときに、本
フィールドがマーク（「×」印）される。図では、
「○」でその構成要素に障害がないことを、「×」でそ
の構成要素に障害があって利用不可能であることを示
す。本フィールドがマークされたとき（障害が発生した
とき）、後述の代替手段５０５により当該構成要素を代
替させて処理を続行させるか、または続行不可能を処理
依頼者に対して伝えなければならないかを判断する。

【００６０】５０４は当該構成要素の障害発生回数を記
憶しておくフィールドである。各構成要素は、障害が発
生しても何度かリトライすることで正常な動作ができる
ようになることがある。本フィールドは、リトライによ
り再度使用できるようになった回数を記憶しているフィ
ールドである。装置の管理者は、本情報を参照すること
で、リトライにより処理が続けられてはいるが、あまり
にも障害発生回数が多いと何か障害を発生させる原因が
あるのではないかと推測でき、早期に装置の改良にかか
ることができる。なお、本フィールド５０４でいう「障
害」は、上記フィールド５０３でいう「障害」とは意味
が異なる。フィールド５０３でいう「障害」は、その構
成要素が利用不可能となる障害のことである。

【００６１】５０５は当該構成要素に対する代替手段を
示す。代替手段とは、当該構成要素が（多重化されてい
るときは、その部分要素のすべて）障害を起こしたと
き、その構成要素を代替して同等の処理を行なう他の手
段のことである。例えば、圧縮機構１１３の場合は、代
替手段として、プロセッサによるエミュレーション、他
の装置に対して圧縮処理を依頼する手段、およびホスト
に対して圧縮処理を依頼する手段などがあり、これらが
フィールド５０５に登録されている。

【００６２】上述した内容を有する構成管理テーブル１
１１は、図１に示したように、各構成要素が障害を発生
したときに、パス１２１〜１２６（構成管理テーブル１
３１，１５１ではパス１４１〜１４６，１６１〜１６
６）を通じて更新される。すなわち、障害を発生した構
成要素自身が、構成管理テーブルを更新する。

【００６３】次に、さらに詳細に図３の障害管理部１１
２（図４の障害管理部１１６も同様）の説明を行なう。

【００６４】図６は、ホストから障害管理部に転送され
るコマンドパケットの形式を示す。コマンドパケット
は、処理要求と、制御情報と、もし必要であれば処理デ
ータとが連なったデータ列である。６０１はコマンドフ
ィールドであり、本コマンドパケットが何を要求するも
のかが記述されている。６０２は位置情報を示し、フィ
ールド６０１の要求が何処に対してのものなのかが記述
されている。例えば、コマンドフィールド６０１にディ
スクドライブに対しての書き込み（ＷＲＩＴＥ）要求が
記述されているのであれば、位置情報フィールド６０２
には、装置名、ドライブ名、およびドライブブロック番
号などが格納されていることになる。

【００６５】図７に、この位置情報フィールドに記述さ
れる情報とその意味を示す。７０１は位置情報の具体例
を示し、７０２はその意味を示す。位置情報７０１に記
載されている「装置１」は装置名、「ＶＯＬ１」はディ
スクドライブ名、「Ｂｌｏｃｋ１００」はドライブブロ
ック番号を示す。図に示すように、位置情報の指定方法
としては、装置名からブロック番号まですべて指定する
方法、装置名とディスクドライブ名を指定する方法、装
置名のみを指定する方法、あるいは何処の装置が処理を
行なってもかまわない”ＡＮＹ”を指定する方法などが
存在する。

【００６６】再び図６を参照して、６０３は、誰が本コ
マンドパケットを発行したのか、その要求者を記述する
フィールドである。通常の場合はホストからのディスク
入出力要求であるため、本フィールド６０３にはホスト
の識別子が記述されている。なお、本発明では、ある装
置が他の装置に対してコマンドパケットを発行すること
もあるため、そのようなコマンドパケットでは本フィー
ルド６０３には要求者である装置名が記述されることと
なる。これらについては後で詳細に説明する。６０４は
コマンドに対する処理データが格納されている。本フィ
ールド６０４は、コマンドによっては必要ない場合もあ
る。

【００６７】図８は、図３に示した障害管理部１１２の
コマンド解析プロセッサ３０１および障害検知プロセッ
サ３０４の処理フローチャートを示したものである。ス
テップ８０１〜８０４はコマンド解析部３０１の動作を
示し、ステップ８０５〜８０９は障害検知プロセッサ３
０４の動作を示す。

【００６８】コマンド解析プロセッサ３０１は、ステッ
プ８０１で、システムバス１８３を介して転送されたパ
ケット（例えば図６）の読み込みを行なう。ステップ８
０２では読み込まれたパケットの解析が行なわれ、パケ
ットのコマンド部（図６のコマンド６０１、位置情報６
０２、および要求者６０３）をコマンドバッファ３０２
へ転送する。次に、ステップ８０３で、パケットのデー
タ部（図６の処理データ６０４）をデータバッファに転
送する。

【００６９】さらに、ステップ８０４では、パケットの
コマンド部を解析し、必要ならその解析結果を障害検知
プロセッサ３０４に送る。図８では、要求されたコマン
ドが圧縮機構１１３を使用する処理であるのかどうかを
判定する部分（ステップ８０４）のみ図示しているが、
他に、キャッシュメモリ１１５および制御プロセッサ１
１４についても、それらを使用するのかどうか判別さ
れ、使用するのであればその旨が障害検知プロセッサ３
０４に知らされる。

【００７０】なお、図４のコマンド解析プロセッサ４０
１であれば、制御プロセッサ１１７およびディスクドラ
イブ１１８，１１９について、それらを使用するのかど
うか判別され、使用するのであればその旨が障害検知プ
ロセッサ４０４に知らされることとなる。

【００７１】次に、障害検知プロセッサ３０４は、ステ
ップ８０５で、コマンド解析プロセッサ３０１からの解
析結果に基づいて構成管理テーブル１１１の検索を行な
う。この検索は、ステップ８０４で選択された構成要素
が使用可能かどうか判定を行なうための検索である。具
体的には、図５の構成管理テーブル１１１のフィールド
５０３を参照することにより行なう。ステップ８０６で
は、その検索の結果、選択された構成要素に障害が発生
しているかどうかを判定する。

【００７２】例えば、ステップ８０４の解析の結果、要
求されたコマンドを実行する際に圧縮機構１１３を使用
するということが知らされていたら、ステップ８０５で
は図５の構成管理テーブル１１１の圧縮機構１１３の障
害の有無５０３を参照し、ステップ８０６で圧縮機構１
１３が使用可能かどうか判定する。

【００７３】ステップ８０６で当該構成要素に障害が発
生していないなら、その構成要素による通常の動作によ
って、要求されたコマンドを実行することができるか
ら、障害管理プロセッサ３０５にその旨を知らせて、処
理を障害管理プロセッサ３０５に移す。これにより、障
害管理プロセッサ３０５は、障害が発生していない場合
の通常の動作を継続して、そのコマンドを実行すること
となる。この障害管理プロセッサ３０５の処理は、図１
０を参照して後述する。

【００７４】ステップ８０６で当該構成要素に障害が発
生しているときは、その構成要素は利用不可能であるか
ら、ステップ８０７で再度構成管理テーブル１１１を検
索する。そして、ステップ８０８で、その構成要素（例
えば、圧縮機構１１３）に代替手段があるかどうかを判
別する。

【００７５】代替手段があれば、障害管理プロセッサ３
０５にその旨を知らせて、処理を障害管理プロセッサ３
０５に移す。これにより、障害管理プロセッサ３０５
は、障害が発生した構成要素に対し、（実際には、所定
回数のリトライを行なった後に）代替手段に処理を依頼
して、障害が発生した構成要素を代替させる。この障害
管理プロセッサ３０５の処理は、図１０を参照して後述
する。

【００７６】ステップ８０８でもし代替手段がないよう
であれば、ステップ８０９で回復不可能障害である旨
を、処理の依頼者に通知する。

【００７７】図９は、障害検知プロセッサ３０４が構成
要素の障害を検知し、かつその構成要素の代替手段があ
るとき（図８のステップ８０８から障害管理プロセッサ
に処理が移行するシーケンス）、障害管理プロセッサ３
０５へ転送するパケットを示している。

【００７８】９０１は障害を起こした構成要素を示すフ
ィールド、９０２はその構成要素の障害発生回数を格納
したフィールドである。障害発生回数は、図５のフィー
ルド５０４に記述されている。フィールド９０３には、
障害を起こした構成要素を代替する代替手段（代替構成
要素）が記述されている。本実施例において、圧縮機構
１１３の代替手段としては、エミュレーションによる手
段、他の装置に対して圧縮処理を依頼する手段、および
ホストに対して圧縮処理を依頼する手段などがあり、こ
こではエミュレーションによる手段が選択された場合の
パケットの例を示している。

【００７９】図１０は、図３に示した障害管理部１１２
の障害管理プロセッサ３０５の処理フローチャートを示
したものである。

【００８０】まず、ステップ１００１では、要求された
処理を実行する際に必要な構成要素に障害が発生してい
るかどうかをチェックする。障害が無いようであれば
（図８のステップ８０６で障害なしのとき）、処理を続
行する。ステップ１００１で、障害が発生しているよう
であれば（図８のステップ８０６〜８０８で障害有りか
つ代替手段有りのとき）、ステップ１００２に移る。

【００８１】ステップ１００２では、転送されたパケッ
ト（例えば図９）を解析し、障害が発生した構成要素に
対しリトライを行なう。そして、ステップ１００３で、
ステップ１００２のリトライが成功したかどうかをチェ
ックする。リトライが成功したらステップ１００９に進
み、リトライが失敗したらステップ１００４に進む。ス
テップ１００４では、リトライの回数があらかじめ設定
された値”Ｍ”を越えたかどうかをチェックする。越え
ていないときはステップ１００２に戻り、リトライを繰
り返す。ステップ１００４でリトライ回数が所定値”
Ｍ”を越えたときは、障害検知プロセッサ３０４が選択
した代替手段を用いるため、ステップ１００５に進む。

【００８２】ステップ１００３でリトライが成功したと
きは、ステップ１００９で、構成管理テーブル内の障害
発生回数（図５のフィールド５０４）の内容に１をプラ
スする。そして、ステップ１０１０で、プラスされた値
があらかじめ設定された値”Ｎ”を越えたかどうかチェ
ックする。もし所定の値”Ｎ”を越えているようであれ
ば、ステップ１０１１に移り、当該構成要素に障害が多
いことをホストに通知してステップ１０１２に移る。ス
テップ１０１０で障害発生回数が所定の値”Ｎ”を越え
ていないようであれば、ステップ１０１２に移る。

【００８３】ステップ１０１２ではセレクタ３１１（図
３）を通常パスに切り替える。例えば、図３の圧縮機構
１１３の障害が検知され、リトライの結果、とりあえず
圧縮機構１１３が正常となったときは、データバッファ
３０３の圧縮処理すべきデータが圧縮機構１１３に転送
されるように、セレクタ３１１のパスを通常パス３１２
に切り替える。

【００８４】ステップ１００４でリトライ回数が所定
値”Ｍ”を越えたときは、ステップ１００５で、障害検
知プロセッサ３０４が選択した代替手段がエミュレーシ
ョンであるかどうか判別する。代替手段がエミュレーシ
ョンであればエミュレーションリクエストを行ない、そ
うでなければステップ１００６に進む。ステップ１００
６では、代替手段が他装置への依頼であるかどうか判別
する。他装置への依頼であればそれを実行し、そうでな
ければステップ１００７に進む。ステップ１００７では
代替手段がホストへの依頼であるかどうか判別する。ホ
ストへの依頼であればそれを実行し、そうでなければス
テップ１００８に進む。

【００８５】障害検知プロセッサ３０４が選択した代替
手段が見つからないようであれば、ステップ１００８で
修復不可能障害発生を処理要求者に伝える。

【００８６】次に、図１０のステップ１００５〜ステッ
プ１００７で選択された各代替手段の詳細な処理手順を
説明する。

【００８７】図１１は、図１０のステップ１００５から
実行されるエミュレーションの処理フローチャートを示
す。図１０の左側のフローチャートは、図３で障害管理
プロセッサ３０５が実行するエミュレーションリクエス
トプログラム３０７の処理を示す。ここでは、圧縮処理
をリクエストするものとする。図１０の右側のフローチ
ャートは、圧縮処理のリクエストに応じて、図３の制御
プロセッサ１１４が圧縮処理を行なう手順を示す。ここ
で、エミュレーションとは、本来オプション機構１１３
が行なわなければならない処理を、制御プロセッサ１１
４のマイクロプログラムで代替して同等の処理を行なう
ことを意味している。

【００８８】図１１において、障害管理プロセッサ３０
５は、ステップ１１０１で、図３のセレクタ３１１を制
御プロセッサ１１４へのパス３１４に切り替える。これ
により、データバッファ３０３内のデータは、本来のオ
プション機構１１３から制御プロセッサ１１４に転送さ
れるようになる。ステップ１１０２では、制御プロセッ
サ１１４に対しエミュレーション要求を発行する。具体
的には、エミュレーション要求を示す識別子と共に制御
プロセッサ１１４に対して割り込みをかける。

【００８９】割り込みを受けた制御プロセッサ１１４
は、エミュレーションであることを認識した後、ステッ
プ１１０５で、データバッファ３０３から圧縮を行なう
べきデータを取り込む。ステップ１１０６では、オプシ
ョン機構１１３の動作をエミュレートする。具体的に
は、オプション機構１１３と同じアルゴリズムによる圧
縮を行なう。

【００９０】ステップ１１０７では、ステップ１１０６
の圧縮処理の結果が正常かどうかをチェックする。圧縮
処理が異常終了であれば、ステップ１１０８に進み、異
常終了を障害管理部１１２の障害管理プロセッサ３０５
に通知する。正常にエミュレーションが終了したのであ
れば、ステップ１１０９で、キャッシュ１１５に圧縮後
のデータを書き込む。その後、ステップ１１１０で、正
常終了を障害管理部１１２の障害管理プロセッサ３０５
に通知する。

【００９１】終了通知を受け取った障害管理プロセッサ
３０５は、エミュレーション処理内でステップ１１０３
を実行し、異常終了かどうかチェックする。その結果、
異常終了であれば、ステップ１１０４で、障害検知プロ
セッサ３０４に対して異常終了を報告する。ステップ１
１０３で異常終了でなければ、エミュレーション処理を
終了する。

【００９２】異常終了を報告された障害検知プロセッサ
３０４は、構成管理テーブル１１１内のフィールド５０
５からエミュレーションに代わる代替手段をさがし、代
替手段があればその代替手段による代替処理を上記と同
様にして試みる。この処理は、代替手段による処理が正
常終了するかあるいは代替手段の候補が無くなるまでつ
づけられる。

【００９３】上述したように、障害を起こした構成要素
に代えてエミュレーションによって処理するので、コス
トの高いハードウェアを多重に持たなくても、多重化と
ほぼ同じ信頼性を得ることができ、低コストで信頼性の
高いディスクシステムを実現することができる。エミュ
レーションは性能面ではハードウェアに劣るが、例え
ば、障害が発生してから比較的短時間の間に保守を行な
い部品交換を行なう体制であればほとんど問題はない。

【００９４】また、本実施例によれば、次のような効果
もある。オプション機構１１３を装備していないディス
ク装置に対して、オプション機構を使用する要求が発行
された場合、従来であれば、オプション機構が無い旨を
ユーザに通知し、異常終了と判定されていたが、本実施
例によれば、その場合でもエミュレーションによる処理
続行が可能となる。

【００９５】図１２は、上記エミュレーションによるデ
ータの流れを示したものである。太い矢印がデータの流
れを示す。

【００９６】オプション機構１１３に障害が発生した場
合、制御プロセッサ１１４でオプション機構１１３と同
等の処理（エミュレーション）を行ない、オプション機
構１１３が正常に動作したのと同じようにキャッシュメ
モリ１１５に圧縮データが格納されることを示してい
る。このような代替処理は、オプション機構１１３の障
害に限らず、ソフトウェア的に処理可能なものであれば
なんでも適用可能である。

【００９７】図１３は、図１０のステップ１００６から
実行される他装置への障害回復依頼の処理フローチャー
トを示す。本処理は、図３で障害管理プロセッサ３０５
が実行する他装置への依頼リクエストプログラム３０８
の処理に相当する。

【００９８】まず、障害管理プロセッサ３０５は、ステ
ップ１３０１で、他装置に対する要求パケットを作成す
る。

【００９９】図１４に、この他装置に対する要求パケッ
トのフォーマット例を示す。このパケットは、コマンド
フィールド１４０１、位置情報フィールド１４０２、依
頼者フィールド１４０３、依頼する処理内容フィールド
１４０４、および処理を行なうデータフィールド１４０
５からなる。

【０１００】コマンドフィールド１４０１には、障害回
復依頼であることが記述されている。位置情報フィール
ド１４０２には、どの装置で実行して欲しいかが記述さ
れている。この例では”ＡＮＹ”指定であるため、圧縮
処理が可能な装置であればどこでもかまわないことを示
している。なお、複数の装置で同じ処理が行なわれた場
合は、最も早く結果を返してきた装置の値を使用するな
どの方法を採ればよい。

【０１０１】依頼者フィールド１４０３には、障害を起
こした装置の識別子が格納される。この識別子は、依頼
された装置から処理結果を転送（返送）するときに用い
られる。依頼する処理内容フィールド１４０４には、本
実施例では圧縮機構の代行要求が格納されている。デー
タフィールド１４０５には、圧縮処理を行なう対象であ
るデータが格納されている。

【０１０２】再び図１３を参照して、ステップ１３０１
で図１４のような要求パケットを作成した後、ステップ
１３０２ではシステムバス１８３に対して作成したパケ
ットを流す。これにより、システムバス１８３に接続さ
れた装置すべてにパケットが転送される。パケット転送
後は、依頼した処理が終了するのを待つ。

【０１０３】そのパケットを受け取った各装置は、自機
内の障害管理部でそのパケット内の位置情報フィールド
１４０２をチェックし、自機への依頼であるかどうか判
定する。自機への依頼であったときは、コマンドフィー
ルド１４０１を解釈し、前記図８などで説明したのと同
様にして、依頼された処理を実行する。そして、処理結
果を依頼元の装置に返す。図１４のパケットの例では、
位置情報が”ＡＮＹ”であるので、パケットを受けたす
べての装置で当該処理が実行され、その結果が送出され
る。依頼元の装置では、一番早く送られてきた処理結果
を用いて、以降の処理を続行することとなる。

【０１０４】ステップ１３０３では、依頼した処理が正
常に終了したかどうかをチェックする。もし異常終了で
あれば、ステップ１３０４で障害検知プロセッサ３０４
にその旨が通知される。そうでなければ、ステップ１３
０５でセレクタ３１１を直結パス１２７に切り替える。
これにより、キャッシュメモリ１１５とデータバッファ
３０３とが直結される。ステップ１３０６では、この直
結パス１２７により、データバッファ３０３内に格納さ
れている他装置による実行結果が、直接、キャッシュメ
モリ１１５に転送される。

【０１０５】なお、本実施例では、１本のシステムバス
１８３上に接続された他装置に障害回復要求を発行して
いるが、図１４のパケットが転送可能な範囲であればど
この装置にでも障害回復を依頼することができる。例え
ば、ネットワークに接続された装置、またはネストされ
たネットワーク上の装置などに、処理を依頼するように
してもよい。したがって、本発明によれば、多数台のデ
ィスク装置を接続した場合、１台分のディスク装置が動
作可能な構成要素が複数のディスク装置により得られて
いる限りは、システムの動作を停止することなく動作可
能となる。

【０１０６】一般に装置の数が多くなればなるほどシス
テム全体の信頼性は低下する。しかし、本発明では、数
が増えたことによる信頼性低下を最小限に抑さえること
ができる。

【０１０７】図１５は、他装置へ処理を依頼する際の処
理の流れを図式化したものである。太い矢印は、処理の
流れを示すとともに、例えばデータ書き込み時のデータ
の流れをも示すと考えてよい。

【０１０８】ディスク装置１０６の障害管理部１１２
は、圧縮機構１１３の障害を検知し、他の装置へ圧縮機
構１１３で行なうべき処理の代替を依頼する。図１５で
は、ディスク装置１０７の障害管理部１５２が、これを
受けて、ディスク装置１０７内の圧縮機構１５３で、障
害を起こした圧縮機構１１３と同等の処理を行なう。そ
の結果は、障害管理部１５２から障害管理部１１２に送
られる。障害管理部１１２は、セレクタ３１１を直結パ
ス１２７に切り替えて、受けたデータを直接キャッシュ
メモリ１１５に転送している。

【０１０９】図１６は、図１０のステップ１００７から
実行されるホストへの障害回復依頼の処理フローチャー
トを示す。本処理は、図３で障害管理プロセッサ３０５
が実行するホストへの依頼リクエストプログラム３０９
の処理に相当する。

【０１１０】まず、障害管理プロセッサ３０５は、ステ
ップ１６０１で、ホストプロセッサ１０１，１０２に対
する要求パケットを作成する。

【０１１１】図１７に、このホストプロセッサに対する
要求パケットのフォーマット例を示す。このパケット
は、コマンドフィールド１７０１、位置情報フィールド
１７０２、依頼者フィールド１７０３、依頼する処理内
容フィールド１７０４、および処理を行なうデータフィ
ールド１７０５からなる。

【０１１２】コマンドフィールド１７０１には、障害回
復依頼であることが記述されている。位置情報フィール
ド１７０２には、どの装置で実行して欲しいかが記述さ
れている。ここでは、ホストプロセッサへの処理依頼で
あるから”ホスト”と記述されている。依頼者フィール
ド１７０３には、障害を起こした装置の識別子が格納さ
れる。この識別子は、依頼されたホストプロセッサ側か
ら処理結果を転送（返送）するときに用いられる。依頼
する処理内容フィールド１７０４には、本実施例では圧
縮機構の代行要求が格納されている。データフィールド
１７０５には、圧縮処理を行なう対象であるデータが格
納されている。

【０１１３】再び図１６を参照して、ステップ１６０１
で図１７のような要求パケットを作成した後、ステップ
１６０２ではシステムバス１８３に対して作成したパケ
ットを流す。これにより、チャネルアダプタ１０５を介
してシステムバス１８３に接続されたホストプロセッサ
１０１，１０２に、パケットが転送される。パケット転
送後は、依頼した処理が終了するのを待つ。

【０１１４】そのパケットを受け取ったホストプロセッ
サでの処理については、後に詳しく説明する。

【０１１５】ステップ１６０３では、依頼した処理が正
常に終了したかどうかをチェックする。もし異常終了で
あれば、ステップ１６０４で障害検知プロセッサ３０４
にその旨が通知される。そうでなければ、ステップ１６
０５でセレクタ３１１を直結パス１２７に切り替える。
これにより、キャッシュメモリ１１５とデータバッファ
３０３とが直結される。ステップ１６０６では、この直
結パス１２７により、データバッファ３０３内に格納さ
れているホストプロセッサによる実行結果が、直接、キ
ャッシュメモリ１１５に転送される。

【０１１６】図１８は、ホストプロセッサ１０１（また
は１０２）内の特に障害回復関係のプログラムの構成を
示している。

【０１１７】１８０２はアプリケーションプログラムを
示す。ディスク装置１０６，１０７に対する入出力要求
は、アプリケーションプログラム１８０２が発行する。
１８０３は、オペレーティングシステムを示している。
オペレーティングシステム１８０３はホスト１０１（１
０２）を制御するプログラムであり、図ではそのうち入
出力関係だけを取り上げて記述している。

【０１１８】１８０４は入出力終了処理プログラムであ
り、アプリケーションプログラム１８０２から発行され
た入出力の終了処理を行なう。終了処理には、例えば入
出力制御に使用したメモリ領域といったリソースの開放
などが含まれる。１８０７は入出力発行処理プログラム
である。入出力終了処理プログラム１８０４とは逆に、
入出力に必要なリソースを確保し、入出力プロセッサ１
０３（１０４）に対して非同期入出力処理を依頼する。

【０１１９】１８０６は割り込み受付プログラムであ
る。アプリケーションプログラム１８０２から発行され
た入出力の終了時にデバイス側からホストに対して割り
込みが発生する。割り込み受付プログラム１８０６は、
この割り込みを受け付けるプログラムである。具体的に
は、デバイス側から発行されたパケット（図１７のパケ
ットも含む）の取り込みを行なう。

【０１２０】１８０５は終了割り込み解析プログラムで
ある。このプログラム１８０５は、受け付けた割り込み
が、入出力終了割り込みなのかそれとも障害回復要求
（図１７）なのかを判定する。１８０８はデバイス要求
管理プログラムである。このプログラム１８０８は、デ
バイス側から要求された内容を実行および管理し、実行
結果を要求したデバイスに転送する。

【０１２１】デバイス要求管理プログラム１８０８が実
行すべきプログラムは、機能プログラムライブラリ１８
０９に格納されており、必要に応じて実行される。例え
ば、圧縮処理を依頼されたのであれば、圧縮プログラム
１８１０が実行される。従来のホストプロセッサは、入
出力終了割込などを除いて、デバイス側からの処理依頼
を受け付ける機能を備えていなかった。本実施例では、
ホストプロセッサが上記のような構成を備えているた
め、デバイス側からの処理依頼を受け付けることが可能
となる。

【０１２２】図１９は、上記構成のホストプロセッサの
動作を示すフローチャートである。

【０１２３】ホストプロセッサは、まず、ステップ１９
０１で入出力終了割り込み受付処理を行なう。この処理
は、上記の割り込み受付プログラム１８０６による処理
であり、具体的には、デバイス側から発行されたパケッ
ト（図１７など）の取り込みなどの処理である。

【０１２４】次に、終了割り込み解析プログラム１８０
５による処理１９２１を行なう。すなわち、まずステッ
プ１９０２で、受け取ったパケットを解析し、ステップ
１８０３で、その割り込みが入出力終了割り込みなのか
それとも障害回復要求なのかを判定する。もし、通常の
入出力終了割り込みであれば、入出力終了処理プログラ
ム１８０４を起動し、ステップ１９０９で入出力処理を
完了させる。

【０１２５】ステップ１９０３でデバイス側からの処理
要求であると判定されたときは、デバイス要求管理プロ
グラム１８０８に制御を移し、処理１９２２を行なう。
処理１９２２では、まずステップ１９０４で、パケット
（図１７）を解析する。そして、解析の結果、何を行な
うべきかを、ステップ１９０５〜１９０７で判定する。

【０１２６】ステップ１９０５〜１９０７の判定に基づ
いて、処理１９２３で、機能プログラムライブラリ１８
０９中のプログラムを用いて、要求された処理を実行す
る。例えば、ステップ１９０５で要求された処理が圧縮
処理であったときは、圧縮プログラム１８１０により、
ステップ１９１０で圧縮処理を行なう。同様に、ステッ
プ１９０６で要求されたのが処理１であるときはステッ
プ１９１１でその処理１を行ない、ステップ１９０７で
要求されたのが処理２であるときはステップ１９１２で
その処理２を行なう。

【０１２７】ステップ１９１０，１９１１，１９１２の
後、ステップ１９０８で、依頼を発行した装置に対し実
行結果を転送する。

【０１２８】図２０は、上記ホストプロセッサでの回復
処理の概要を示したものである。太い矢印は、処理の流
れを示すとともに、データの流れをも示すと考えてよ
い。

【０１２９】ディスク装置１０６の障害管理部１１２
は、圧縮機構１１３の障害を検知し、ホストに対し圧縮
機構１１３で行なうべき処理の代替を依頼する。図２０
では、ホストプロセッサ１０１が、これを受けて、内部
の圧縮プログラム１８１０を用いて、障害を起こした圧
縮機構１１３と同等の圧縮処理を行なう。その結果は、
ホストプロセッサ１０１から障害管理部１１２に送られ
る。障害管理部１１２は、セレクタ３１１を直結パス１
２７に切り替えて、受けたデータを直接キャッシュメモ
リ１１５に転送している。

【０１３０】これにより、前述の他の装置での障害回復
と合わせて、デバイスが通信可能な、あらゆる装置ある
いはホストプロセッサを利用した障害回復が行なえるよ
うになり、より信頼性の高いシステムを構築することが
可能となる。

【０１３１】なお、本発明はディスク装置のみに限定さ
れず、計算機システム一般に適用可能である。また、本
発明の基本は多数のデバイスまたはコンピューティング
システム間でのリソースの有効利用にある。従って、本
発明は、障害回復に限定されることなく、一般に、多数
のデバイスまたはコンピューティングシステム間でリソ
ースを有効に利用するために適用することができる。

【０１３２】［実施例２］次に、本発明の第２の実施例
を説明する。本実施例では、上記第１の実施例のシステ
ムと同じシステムを用いる。特に、クロスコール動作を
行なう点に特徴がある。

【０１３３】図２１は、本実施例における障害回復処理
をクロスコールを用いて行なう場合の動作の流れを示
す。太い矢印は、処理の流れを示すとともに、データの
流れをも示すと考えてよい。

【０１３４】ディスク装置１０６の障害管理部１１２
は、上位装置からのデータ書き込み要求を受けて、圧縮
機構１１３によりデータを圧縮し、キャッシュ１１５に
格納する。障害管理部１１６は、キャッシュ１１５に格
納されたデータをディスクドライブ１１８に書き込もう
とするが、この際、ディスクドライブ１１８，１１９の
入出力制御を行なっている制御プロセッサ１１７が障害
を起こしていたとする。

【０１３５】このとき、障害管理部１１６は、制御プロ
セッサ１１７の障害を検知し、他装置に対して障害回復
を依頼する。その依頼を受けた障害管理部１３２は、受
けとったデータを直結パス１４７でキャッシュ１３５に
格納し、さらに障害管理部１３６は、キャッシュ１３５
に格納されたデータを制御プロセッサ１３７に渡し、制
御プロセッサ１３７はそのデータをディスクドライブ１
１８に書き込む。このように、データを元の装置に戻す
ことなく、障害回復依頼を受けた装置が直接クロスコー
ルでディスクドライブ１１８に対してアクセスするよう
になっている。

【０１３６】このクロスコールを可能にするのは、パス
１７１，１７２の存在による。このパスにより、独立の
制御形態間（すなわち、ディスク装置１０６中の左側の
ディスクシステムと右側のディスクシステムとの間）で
のディスクドライブのアクセスが可能になる。

【０１３７】次に、クロスコールによる障害回復処理を
さらに詳細に説明する。

【０１３８】図２２は、クロスコールによる障害回復処
理依頼の手順を示すフローチャートである。本処理は、
障害管理部１１６の障害管理プロセッサ４０５により実
行される。まず、ステップ２２０１で、要求パケットの
作成を行なう。次に、ステップ２２０２で、作成された
パケットをシステムバス１８３に送信し、クロスコール
可能な装置へ転送する。

【０１３９】要求パケットとして２種類の例をあげる。

【０１４０】図２３は、第１のパケットの例であり、図
２１において障害管理部１１６が送出する要求パケット
の例である。このパケットは、コマンドフィールド２３
０１、位置情報フィールド２３０２、障害回復依頼者フ
ィールド２３０３、処理依頼者フィールド２３０４、依
頼する処理内容フィールド２３０５、および処理を行な
うデータフィールド２３０６からなる。

【０１４１】コマンドフィールド２３０１は、コマンド
を示し、障害回復依頼であることを相手に伝える。位置
情報フィールド２３０２には、依頼を行なう装置の識別
子が格納されている。障害回復依頼者フィールド２３０
３には、障害回復の依頼元の識別子が格納されている。

【０１４２】ここでは、ディスク装置１０６内の左側の
ディスクシステムの障害管理部１１６から、同じディス
ク装置１０６内の右側のディスクシステムの障害管理部
１３２，１３６への依頼であるので、位置情報フィール
ド２３０２にはディスク装置１０６内の右側のディスク
システムを表す「装置１−２」と記述され、障害回復依
頼者フィールド２３０３にはディスク装置１０６内の左
側のディスクシステムを表す「装置１−１」と記述され
ている。

【０１４３】処理依頼者フィールド２３０４には、処理
の依頼者であるホストの識別子が格納されている。この
識別子により当回復処理が終了した際に、依頼元に終了
処理を返すことなく直接ホストに終了報告ができる。依
頼する処理内容フィールド２３０５には、依頼内容が記
述される。本例では、制御プロセッサ１１７の処理であ
ることが記述されている。データフィールド２３０６に
は、依頼処理データが記述される。本例では、キャッシ
ュメモリ１１５内の必要データが格納されている。

【０１４４】以上のようなパケットにより、他装置への
依頼を行なっているので、依頼を受けた装置の側では、
不必要に処理を重複させることなく効率よく処理可能と
なる。

【０１４５】図２４は、第２のパケットの例であり、や
はり図２１において障害管理部１１６が送出する要求パ
ケットの例である。このパケットは、コマンドフィール
ド２４０１、位置情報フィールド２４０２、処理要求者
フィールド２４０３、依頼する処理内容フィールド２４
０４、および処理を行なうデータフィールド２４０５か
らなる。

【０１４６】コマンドフィールド２４０１にはコマンド
が格納されており、ここではクロスコールであることが
示されている。位置情報フィールド２４０２には位置情
報が格納されており、ここではアクセス対象となるディ
スクドライブの位置が格納されている。要求者フィール
ド２４０３には、第１のパケットの処理依頼者フィール
ド２３０４と同様にホストの識別子が格納されている。
処理内容フィールド２４０４には、依頼する処理の内容
が記述され、ここでは障害が発生した制御プロセッサ１
１７の処理を示す識別子が格納される。データフィール
ド２４０５には、第１のパケットのデータフィールド２
３０６と同様にキャッシュメモリ１１５上の必要なデー
タが格納されている。

【０１４７】図２３または図２４のパケットのどちらを
使用しても目的とするクロスコールは可能である。以下
では、図２４の第２のパケットを使用したクロスコール
処理について詳細に説明する。

【０１４８】図２５は、図２４のようなクロスコール依
頼パケットを受けた装置の処理フローチャートを示して
いる。ステップ２５０１〜２５０３は、図７のステップ
７０１〜７０３に等しいので、説明を省略する。次に、
ステップ２５０４ではパケットのコマンドフィールド２
４０１がクロスコール依頼であるかどうかを判別する。
クロスコール依頼であるときは、障害検知部３０４によ
るステップ２５０５に進む。

【０１４９】障害検知部３０４は、ステップ２５０５
で、パケットのデータフィールド２４０５のデータをキ
ャッシュメモリ１３５に転送する。このときは、図１３
のステップ１３０５で述べたのと同様に、障害管理部１
３２のセレクタ（図３のセレクタ３１１）では直結パス
１４７が選択されている。

【０１５０】次に、ステップ２５０６で、パケットの依
頼処理フィールド２４０４のデータを制御プロセッサ１
３７に転送する。この転送処理を行うのは、障害管理部
１３６である。このとき、障害管理部１３６のセレクタ
（図４のセレクタ４１１）ではパス４１４が選択されて
いる。これにより、キャッシュメモリ１３５に格納され
たデータ（パケットのデータフィールド２４０５のデー
タ）は、パス４１４を介して制御プロセッサ１３７に渡
され、制御プロセッサ１３７は、そのデータをクロスコ
ールでディスクデバイス１１８に書き込む。

【０１５１】このような処理により、制御プロセッサ１
３４での処理などを省略することができ、高速なクロス
コールが可能となる。また、このクロスコールにより、
実施例１で述べた方式に比べ、往復に要する通信オーバ
ヘッドを少なくでき、より高速に処理を行なうことがで
きる。

【０１５２】［実施例３］上述した第１および第２の実
施例では、ユーザがアクセスしたいデータが唯一１つの
ディスクドライブに存在するファイルシステムに本発明
を適用した例を述べた。しかし、より高信頼性を備えた
ファイルシステムを実現する場合には、同一データを複
数のディスク装置に格納しておくことで高い信頼性を得
る方式を用いることもある。これをミラーリングとい
う。

【０１５３】第３の実施例は、ミラーリングされたディ
スクファイルシステムに本発明を適用した例であり、そ
のようなシステムで効率的な障害回復動作を実現した例
である。なお、本実施例のシステムの構成は上述した第
１の実施例と同様のものを用いることとし、以下では、
特に第３の実施例に特有の部分を中心に説明する。

【０１５４】図２６は、ミラーリングされた本実施例の
ディスクファイルシステムにおける障害回復の動作概要
を示したものである。太い矢印は、処理の流れを示すと
ともに、データの流れをも示すと考えてよい。ここで
は、ディスクドライブ１１８とディスクドライブ１５８
がミラーリングされており、これらのドライブ１１８，
１５８に同じ内容のデータが存在していることを前提と
する。

【０１５５】いま、ディスクドライブ１１８が障害を起
こしたとする。この障害を検知した障害管理部１１２
は、構成管理テーブル１１１を参照して、障害を起こし
たディスクドライブ１１８がディスクドライブ１５８に
ミラーリングされていることを得る。その後、障害管理
部１１２は、ディスクドライブ１５８に対して処理を行
なうことで、障害回復を行なっている。

【０１５６】図２７は、ミラーリングの情報が格納され
ている構成管理テーブル１１１の内容を示している。テ
ーブルの各領域２７０１〜２７０５は、図５の構成管理
テーブル１１１の領域５０１〜５０５と同様の内容を格
納する領域である。図５の構成管理テーブル１１１と異
なる点は、レコード情報としてミラーリングがつけ加わ
ったところである。

【０１５７】図２７では、構成要素２７０１が「ドライ
ブ１」（ディスクドライブ１１８）の代替手段２７０５
として「ミラー，装置２：ドライブ１」と記述されてい
る。これにより、ディスクドライブ１１８が、ディスク
装置１０７のディスクドライブ１５８とミラーリングさ
れていることがわかる。

【０１５８】図２８は、本実施例における障害管理部１
１２の障害管理プロセッサ３０５の処理フローチャート
を示したものである。同図において、ステップ２８０１
〜２８０７は前述の第１の実施例の図１０のステップ１
００１〜１００７に、ステップ２８０９はステップ１０
０８に、ステップ２８１０〜２８１３はステップ１００
９〜１０１２に、それぞれ対応し、これらのステップに
おける動作は第１の実施例と同様であるので説明は省略
する。

【０１５９】図２８のフローチャートでは、ステップ２
８０８が追加されている。これは、ミラーリングによる
障害回復が可能かどうかをチェックするステップであ
る。障害を起こした構成要素にミラーリングが施されて
いれば、そのミラー（ミラーリングされた複数の構成要
素のうちの障害を起こしていないもの）を使用して、処
理を継続することができる。

【０１６０】図２９は、図２８のステップ２８０８から
実行されるミラーへの障害回復依頼の処理フローチャー
トを示す。本処理のプログラムは、図３のエミュレーシ
ョンリクエストプログラム３０７や外部装置リクエスト
プログラム３０８と同様にメモリ３０６に格納されてい
る。障害管理プロセッサ３０５は、まずステップ２９０
１で、ミラーリングが施されている装置に対しての回復
依頼パケットを作成する。次に、ステップ２９０２で、
そのパケットをシステムバス１８３を介して目的の装置
に転送する。

【０１６１】図３０は、上記の障害回復依頼パケットの
構造を示している。このパケットは、第１の実施例でホ
ストから障害管理部に転送される図６のパケットと同様
のものである。ただし、図３０はミラーへの依頼パケッ
トであるから、位置情報フィールド３００２には、ミラ
ーリングされた装置が指定されている。ミラーリング時
のパケットの特徴は、オリジナルのパケットの位置情報
をミラーリングが施された装置と入れ替えるだけで容易
に処理依頼を行なうことができる点である。

【０１６２】［実施例４］上述の各実施例では、ある構
成要素が障害を起こしたときに、その障害を起こした構
成要素を他の構成要素で代替して処理を継続するシステ
ムを説明した。これに対し、第４の実施例は、前述のエ
ミュレーション処理を障害時に使用するのではなく、デ
ータの信頼性を高めるために多重化動作をさせ、ハード
ウェアとで多数決判定を行なうものである。

【０１６３】図３１は、本実施例のファイルシステムに
おける障害管理部１１２の構成を示す。基本的な構成
は、図３と同様であるので、異なる点について特に詳し
く説明する。図３１の障害管理部１１２では、オプショ
ン機構が多重化（２重化）されており、２つのオプショ
ン機構３１０１，３１０２を備えている。また、多数決
判定を行なうための比較器３１０３，３１０４が追加さ
れている。

【０１６４】本実施例において、第１の実施例の図６に
示したようなデータ書き込み要求のパケットを受け付け
たとする。このとき、障害管理プロセッサ３０５は、デ
ィスクに書き込むべきデータを圧縮するため、多重化さ
れたオプション機構３１０１，３１０２にデータを渡
す。また、オプション機構３１０１，３１０２に障害が
発生していないときでも、第１の実施例で説明したエミ
ュレーションを、制御プロセッサ１１４に実行させる。

【０１６５】オプション機構３１０１での圧縮処理の結
果とオプション機構３１０２での圧縮処理の結果とは、
比較器３１０３で比較される。さらに、その比較結果が
等しいときには、オプション機構３１０１，３１０２で
の圧縮処理の結果とエミュレーションの結果とが、比較
器３１０４で比較される。これらの比較の結果、どれか
１つのデータが他の２つのデータと異なっていた場合、
多数決により値があっていた２つのデータを採用し、キ
ャッシュ１１５に書き込む。

【０１６６】このようにして、本発明は、障害時だけで
なく通常の動作時にも適用することができ、より信頼性
の高い動作を実現できる。なお、多数決をとる方式に限
定することなく、１つのハードウェアとエミュレーショ
ンとで２重化を行なうなどのバリエーションをもたせる
こともできる。

【０１６７】［実施例５］上述した各実施例において
は、図３および図４に示したように、障害管理部内の障
害管理プロセッサ３０５，４０５と制御プロセッサ１１
４，１１７とを設けているが、これらを共用することも
できる。

【０１６８】図３２は、図３の障害管理プロセッサ３０
５と制御プロセッサ１１４とを、１つの制御プロセッサ
３２０１に置き換えたものである。この制御プロセッサ
３２０１が、図３の障害管理プロセッサ３０５と制御プ
ロセッサ１１４の行なっていた動作を実行する。これに
より、部品点数を削減することができ、より装置コスト
を削減することができる。１つのプロセッサで、従来２
つのプロセッサが行なっていた動作を実行するので、性
能は前述の方式と比較して若干低下するが、プロセッサ
の数が削減された分かなりのコスト削減が見込める。

【０１６９】

【発明の効果】本発明によれば、複数の構成要素からな
る計算機システムにおいて、ある構成要素が障害を起こ
したとしても、他の構成要素（エミュレーションな
ど）、他の装置、あるいはホストプロセッサなどに、そ
の構成要素の代替処理を依頼することができるので、多
数の装置を接続しても信頼性が低下することがない。ま
た、エミュレーション、他の装置、あるいはホストプロ
セッサによる代替処理を行なっているので、多重化によ
り信頼性を向上させる従来の手法に比較して、低コスト
で信頼性の高いシステムを構築できる。

【図面の簡単な説明】

【図１】本発明に係る計算機システムの第１の実施例の
全体構成図を示す。

【図２】第１の実施例における障害回復の流れを示すフ
ローチャートを示す。

【図３】第１の実施例における障害管理部１１２のブロ
ック図を示す。

【図４】第１の実施例における障害管理部１１６のブロ
ック図を示す。

【図５】第１の実施例における障害情報が格納された構
成管理テーブルを示す。

【図６】第１の実施例においてホストから転送されるコ
マンドパケット構成を示す。

【図７】第１の実施例におけるコマンドパケット内の位
置情報の詳細を示す。

【図８】第１の実施例における障害検知部の処理フロー
チャートを示す。

【図９】第１の実施例における障害管理プロセッサへの
伝達パケット構成を示す。

【図１０】第１の実施例における障害管理プロセッサの
処理フローチャートを示す。

【図１１】第１の実施例におけるエミュレーション処理
のフローチャートを示す。

【図１２】第１の実施例におけるエミュレーション動作
の概要を示す。

【図１３】第１の実施例における他装置への障害回復依
頼処理フローチャートを示す。

【図１４】第１の実施例における他装置への障害回復依
頼パケット構成を示す。

【図１５】第１の実施例における他装置への障害回復依
頼処理の概要を示す。

【図１６】第１の実施例におけるホストへの障害回復依
頼処理フローチャートを示す。

【図１７】第１の実施例におけるホストへの障害回復依
頼パケット構成を示す。

【図１８】第１の実施例におけるホスト内のプログラム
構成を示す。

【図１９】第１の実施例におけるホストの障害回復処理
フローチャートを示す。

【図２０】第１の実施例におけるホストへの障害回復依
頼処理の概要を示す。

【図２１】第２の実施例におけるクロスコール処理の概
要を示す。

【図２２】第２の実施例におけるクロスコール依頼処理
フローチャートを示す。

【図２３】第２の実施例におけるクロスコール依頼パケ
ット構成（その１）を示す。

【図２４】第２の実施例におけるクロスコール依頼パケ
ット構成（その２）を示す。

【図２５】第２の実施例においてクロスコール依頼を受
けた装置の処理フローチャートを示す。

【図２６】第３の実施例におけるミラー時の障害回復概
要を示す。

【図２７】第３の実施例におけるミラー時の構成管理テ
ーブルを示す。

【図２８】第３の実施例におけるミラー時の障害管理プ
ロセッサ処理フローチャートを示す。

【図２９】第３の実施例におけるミラー時の障害回復依
頼フローチャートを示す。

【図３０】第３の実施例におけるミラー時の障害回復依
頼パケット構成を示す。

【図３１】第４の実施例におけるエミュレーションを使
用した多数決判定を行なうディスクシステムのブロック
構成（一部）図を示す。

【図３２】第５の実施例における制御プロセッサを使用
した障害管理部を示す。

【符号の説明】

１０１，１０２…ホストプロセッサ、１０６，１０７…
ディスク装置、１１１，１３１，１５１…構成管理テー
ブル、１１２，１１６，１３２，１３６，１５２，１５
６…障害管理部、１１３，１３３，１５３…オプション
機構、１１４，１１７，１３４，１３７，１５４，１５
７…制御プロセッサ、１１５，１３５，１５５…キャッ
シュメモリ、１１８，１１９，１３８，１３９，１５
８，１５９…ディスクドライブ、３０１，４０１…コマ
ンド解析プロセッサ、３０４，４０４…障害検知プロセ
ッサ、３０５，４０５…障害管理プロセッサ、３０７…
エミュレーションリクエストプログラム、３０８，４０
８…外部装置リクエストプログラム、３０９，４０９…
ホストリクエストプログラム、３１１，４１１…セレク
タ。

Claims

【特許請求の範囲】

【請求項１】複数の構成要素を備えた計算機システムに
おいて、上記構成要素の障害を検知する検知手段と、ある構成要素に障害が発生したとき、その構成要素を代
替して機能する代替構成要素を探索する探索手段と、探索された代替構成要素に対し、障害が発生した構成要
素を代替する処理を行なわせる管理手段とを備えたこと
を特徴とする計算機システム。
【請求項２】前記代替構成要素は、プログラムを実行可
能なプロセッサを備えており、該プロセッサを用いて、
前記障害が発生した構成要素の動作をエミュレーション
またはシミュレーションにより模擬する請求項１に記載
の計算機システム。
【請求項３】前記障害が発生した構成要素がデータ圧縮
機構であり、前記プロセッサは、データ圧縮のエミュレ
ーションを行なうことを特徴とする請求項２に記載の計
算機システム。
【請求項４】前記探索手段は、障害が発生した構成要素
を示すデータ、およびその構成要素を代替する代替構成
要素を示すデータを含むデータ列を生成して、前記管理
手段へと送り、前記管理手段は、該データ列に基づいて
前記代替する処理を行なわせることを特徴とする請求項
１ないし３のいずれかに記載の計算機システム。
【請求項５】さらに、前記構成要素に障害が発生してい
るかどうかを示すデータと、障害が発生したときその構
成要素を代替する処理を表すデータとを格納した構成管
理テーブルを備え、前記検知手段は、該構成管理テーブルを参照して、構成
要素の障害を検知し、前記探索手段は、該構成管理テーブルを参照して、障害
が発生した構成要素を代替する処理を探索することを特
徴とする請求項１ないし４のいずれかに記載の計算機シ
ステム。
【請求項６】さらに、前記各構成要素の障害を検知した
とき、再度その構成要素に同じ動作を反復させ、所定回
数以下の反復動作によりその構成要素が正常に動作した
ときには、その構成要素には障害が発生しなかったもの
として動作を継続するとともに、そのような反復動作に
より正常動作に移行した回数を数え、該回数が所定値を
越えたときにはその旨を外部に伝える手段を備えた請求
項１ないし５のいずれかに記載の計算機システム。
【請求項７】前記構成要素が多重化されていることを特
徴とする請求項１ないし６のいずれかに記載の計算機シ
ステム。
【請求項８】前記管理手段自体が、前記障害が発生した
構成要素を代替する処理を行なうことが可能な構成要素
でもあることを特徴とする請求項１ないし７のいずれか
に記載の計算機システム。
【請求項９】前記構成要素は、計算機システムのファイ
ルシステムを構成する構成要素であることを特徴とする
請求項１ないし８のいずれかに記載の計算機システム。
【請求項１０】ホストプロセッサを備えた計算機システ
ムまたはネットワークに接続される周辺機器であって、
複数の構成要素を備えた周辺機器において、上記構成要素の障害を検知する検知手段と、ある構成要素に障害が発生したとき、内部の他の構成要
素中から障害を起こした構成要素を代替して機能する代
替構成要素を探索する探索手段と、探索された代替構成要素に対し、障害が発生した構成要
素を代替する処理を行なわせる管理手段とを備えたこと
を特徴とする計算機システムの周辺機器。
【請求項１１】ホストプロセッサと、複数の周辺機器と
を備えた計算機システムであって、その各周辺機器は複
数の構成要素を備えている、計算機システムにおいて、上記周辺機器の構成要素の障害を検知する検知手段と、ある構成要素に障害が発生したとき、その構成要素を含
む周辺機器以外の周辺機器または上記ホストプロセッサ
により、障害が発生した構成要素を代替する処理を行な
わせる管理手段とを備えたことを特徴とする計算機シス
テム。
【請求項１２】前記管理手段は、障害回復処理依頼であ
ることを示す識別子、障害を起こした構成要素を示す識
別子、および依頼する処理を示す識別子を含むデータ列
を生成して送出することにより、前記周辺機器またはホ
ストプロセッサに代替処理を行なわせることを特徴とす
る請求項１１に記載の計算機システム。
【請求項１３】前記管理手段は、前記データ列を複数の
周辺機器に対して送信し、該データ列に格納された要求
を処理可能な周辺機器が、該データ列に基づく代替処理
を行なうことを特徴とする請求項１２に記載の計算機シ
ステム。
【請求項１４】さらに、前記構成要素に障害が発生して
いるかどうかを示すデータと、障害が発生したときその
構成要素を代替する処理あるいは代替手段を表すデータ
とを格納した構成管理テーブルを備え、前記検知手段は、該構成管理テーブルを参照して、構成
要素の障害を検知し、前記管理手段は、該構成管理テーブルを参照して、どこ
に前記代替する処理を行なわせるかを決定することを特
徴とする請求項１１ないし１３のいずれかに記載の計算
機システム。
【請求項１５】前記周辺機器が多重化されていることを
特徴とする請求項１１ないし１４のいずれかに記載の計
算機システム。
【請求項１６】前記周辺機器は、計算機システムのファ
イルシステムであることを特徴とする請求項１１ないし
１５のいずれかに記載の計算機システム。
【請求項１７】ホストプロセッサと、互いに通信可能な
複数のファイルシステムとを備えた計算機システムであ
って、その各ファイルシステムはディスクデバイスを含
む複数の構成要素を備えているとともに、各ファイルシ
ステム間のクロスコールにより、互いに他のファイルシ
ステムのディスクデバイスにアクセスできる、計算機シ
ステムにおいて、上記ファイルシステムの構成要素の障害を検知する手段
と、ディスクデバイス以外の構成要素に障害が発生した
とき、その構成要素を含むファイルシステム以外のファ
イルシステムに対し、障害が発生した構成要素を代替す
る処理を依頼する手段とを備え、該依頼を受けたファイルシステムは、その依頼に基づい
て代替処理を行なうとともに、クロスコールにより、前
記障害が発生した構成要素を含むファイルシステムのデ
ィスクデバイスに、直接アクセスすることを特徴とする
計算機システム。
【請求項１８】ホストプロセッサを備えた計算機システ
ムまたはネットワークに接続される周辺機器であって、
複数の構成要素を備えた周辺機器において、自周辺機器の内部にある構成要素の障害を検知する手段
と、ある構成要素に障害が発生したとき、他周辺機器に対し
て、その障害が発生した構成要素を代替する処理を依頼
するデータ列を送出する手段と、他周辺機器から上記依頼した処理の処理結果を受取った
ときは、上記障害を起こした構成要素をバイパスして、
処理を継続する手段と、他周辺機器から上記障害が発生した構成要素を代替する
処理を依頼するデータ列を受けたときは、該データ列の
依頼に基づいて処理を行ない、処理結果を上記データ列
の送出元に返送する手段とを備えたことを特徴とする計
算機システムの周辺機器。
【請求項１９】ホストプロセッサを備えた計算機システ
ムまたはネットワークに接続される周辺機器であって、
複数の構成要素を備えた周辺機器において、自周辺機器の内部にある構成要素の障害を検知する手段
と、ある構成要素に障害が発生したとき、上記ホストプロセ
ッサに対して、その障害が発生した構成要素を代替する
処理を依頼するデータ列を送出する手段と、上記ホストプロセッサから上記依頼した処理の処理結果
を受取ったときは、上記障害を起こした構成要素をバイ
パスして、処理を継続する手段とを備えたことを特徴と
する計算機システムの周辺機器。
【請求項２０】ホストプロセッサと、該ホストプロセッ
サに接続される周辺機器とを備えた計算機システムにお
いて、該周辺機器は、通常は自機器の内部で行なう処理を、他
の周辺機器またはホストプロセッサに依頼する手段を備
えたことを特徴とする計算機システム。
【請求項２１】プログラムを実行可能なプロセッサを含
む複数の構成要素を備えた計算機システムにおいて、上
記プロセッサ以外の構成要素の動作を上記プロセッサで
エミュレートまたはシミュレートし、上記構成要素によ
る処理結果と上記プロセッサによるエミュレートまたは
シミュレートの結果とを比較する手段と備えたことを特
徴とする計算機システム。
【請求項２２】複数の構成要素を備えた計算機システム
の障害回復方法において、上記構成要素の障害を検知するステップと、ある構成要素に障害が発生したとき、その構成要素を代
替して機能する代替構成要素を探索するステップと、探索された代替構成要素に対し、障害が発生した構成要
素を代替する処理を行なわせるステップとを備えたこと
を特徴とする計算機システムの障害回復方法。
【請求項２３】前記代替構成要素は、プログラムを実行
可能なプロセッサを備えており、該プロセッサを用い
て、前記障害が発生した構成要素の動作をエミュレーシ
ョンまたはシミュレーションにより模擬する請求項２２
に記載の計算機システムの障害回復方法。
【請求項２４】前記障害が発生した構成要素がデータ圧
縮機構であり、前記プロセッサは、データ圧縮のエミュ
レーションを行なうことを特徴とする請求項２３に記載
の計算機システムの障害回復方法。
【請求項２５】さらに、前記構成要素に障害が発生して
いるかどうかを示すデータと、障害が発生したときその
構成要素を代替する処理を表すデータとを格納した構成
管理テーブルを備え、前記検知するステップは、該構成管理テーブルを参照し
て、構成要素の障害を検知し、前記探索するステップは、該構成管理テーブルを参照し
て、障害が発生した構成要素を代替する処理を探索する
ことを特徴とする請求項２２ないし２４のいずれかに記
載の計算機システムの障害回復方法。
【請求項２６】さらに、前記各構成要素の障害を検知し
たとき、再度その構成要素に同じ動作を反復させ、所定
回数以下の反復動作によりその構成要素が正常に動作し
たときには、その構成要素には障害が発生しなかったも
のとして動作を継続するとともに、そのような反復動作
により正常動作に移行した回数を数え、該回数が所定値
を越えたときにはその旨を外部に伝えるステップを備え
た請求項２２ないし２５のいずれかに記載の計算機シス
テムの障害回復方法。
【請求項２７】前記構成要素が多重化されていることを
特徴とする請求項２２ないし２６のいずれかに記載の計
算機システムの障害回復方法。
【請求項２８】前記構成要素は、計算機システムのファ
イルシステムを構成する構成要素であることを特徴とす
る請求項２２ないし２７のいずれかに記載の計算機シス
テムの障害回復方法。
【請求項２９】ホストプロセッサと、複数の周辺機器と
を備えた計算機システムであって、その各周辺機器は複
数の構成要素を備えている計算機システムの障害回復方
法において、上記周辺機器の構成要素の障害を検知するステップと、ある構成要素に障害が発生したとき、その構成要素を含
む周辺機器以外の周辺機器または上記ホストプロセッサ
により、障害が発生した構成要素を代替する処理を行な
わせるステップとを備えたことを特徴とする計算機シス
テムの障害回復方法。
【請求項３０】前記代替する処理を行なわせるステップ
は、障害回復処理依頼であることを示す識別子、障害を
起こした構成要素を示す識別子、および依頼する処理を
示す識別子を含むデータ列を生成して送出することによ
り、前記周辺機器またはホストプロセッサに代替処理を
行なわせることを特徴とする請求項２９に記載の計算機
システムの障害回復方法。
【請求項３１】前記代替する処理を行なわせるステップ
は、前記データ列を複数の周辺機器に対して送信し、該
データ列に格納された要求を処理可能な周辺機器が、該
データ列に基づく代替処理を行なうことを特徴とする請
求項３０に記載の計算機システムの障害回復方法。
【請求項３２】さらに、前記構成要素に障害が発生して
いるかどうかを示すデータと、障害が発生したときその
構成要素を代替する処理あるいは代替手段を表すデータ
とを格納した構成管理テーブルを備え、前記検知するステップは、該構成管理テーブルを参照し
て、構成要素の障害を検知し、前記代替する処理を行なわせるステップは、該構成管理
テーブルを参照して、どこに前記代替する処理を行なわ
せるかを決定することを特徴とする請求項２９ないし３
１のいずれかに記載の計算機システムの障害回復方法。
【請求項３３】前記周辺機器が多重化されていることを
特徴とする請求項２９ないし３２のいずれかに記載の計
算機システムの障害回復方法。
【請求項３４】前記周辺機器は、計算機システムのファ
イルシステムであることを特徴とする請求項２９ないし
３３のいずれかに記載の計算機システムの障害回復方
法。