(57)【特許請求の範囲】
【請求項１】
二重化されたプロセッサとメモリを有するディスク制御装置と、前記ディスク制御装置の保守を実施するために前記ディスク制御装置に接続された保守用コンピュータと、を備え、
前記保守用コンピュータは、
当該保守用コンピュータに搭載された保守用アプリケーションに基づいて実行する保守操作の保守種別及び当該保守操作の保守対象部位のＩＤを含む操作情報と、当該保守対象部位とは異なる他の部位のＩＤ及び当該部位の状態を含む装置状態情報と、前記ディスク制御装置の状態を復旧させるための対処アプリケーションの名称との組み合わせを、複数保持する、障害対処テーブルを備え、
前記保守用アプリケーションに基づいて実行した保守操作の保守種別及び保守対象部位のＩＤを含む操作情報と、当該保守対象部位とは異なる他の部位の装置状態と、を監視し、
前記監視した操作情報、他の部位の装置状態及び当該他の部位のＩＤと、前記障害対処テーブルに保持している操作情報及び装置状態情報とを照合し、
前記照合の結果、前記監視した操作情報、他の部位の装置状態及び当該他の部位のＩＤが、前記障害対処テーブルに保持している操作情報及び装置状態情報のいずれかに該当する場合、当該操作情報及び装置状態情報に対応する名称の対処アプリケーションを実行することによって、前記ディスク制御装置を、保守実施直前の状態に復旧させるリカバリ処理を実施する
ことを特徴とする保守抑止装置。
【請求項２】
ホストから送られる情報が格納されるディスク駆動装置と、
ホスト間の情報を制御する二重化されたチャネルアダプタ、前記ディスク駆動装置間の情報を制御する二重化されたディスクアダプタ、ディスクアクセスの高速化を図る二重化されたキャッシュメモリを有するディスク制御装置と、
前記ディスク制御装置又は前記ディスク駆動装置の保守を実施する保守用コンピュータと、を備えた保守抑止装置であって、
前記保守用コンピュータは、
前記チャネルアダプタと前記ディスクアダプタとに接続され、
当該保守用コンピュータに搭載された保守用アプリケーションに基づいて実行する保守操作の保守種別、及び、当該保守操作の保守対象部位であるチャネルアダプタ、ディスクアダプタまたはディスク駆動装置のＩＤを含む操作情報と、当該保守対象部位とは異なる他の部位であるチャネルアダプタ、ディスクアダプタまたはディスク駆動装置のＩＤ及び当該部位の状態を含む装置状態情報と、前記ディスク制御装置の状態を復旧させるための対処アプリケーションの名称との組み合わせを、複数保持する、障害対処テーブルを備え、
前記保守用アプリケーションに基づいて実行した保守操作の保守種別及び保守対象部位のＩＤを含む操作情報と、当該保守対象部位とは異なる他の部位であるチャネルアダプタ、ディスクアダプタ、または、ディスク駆動装置の装置状態と、を監視し、
前記監視した操作情報、他の部位の装置状態及び当該他の部位のＩＤと、前記障害対処テーブルに保持している操作情報及び装置状態情報とを照合し、
前記照合の結果、前記監視した操作情報、他の部位の装置状態及び当該他の部位のＩＤが、前記障害対処テーブルに保持している操作情報及び装置状態情報のいずれかに該当する場合、当該操作情報及び装置状態情報に対応する名称の対処アプリケーションを実行することによって、前記二重化されたチャネルアダプタ、前記二重化されたディスクアダプタ、または、前記ディスク駆動装置を、保守実施直前の状態に復旧させるリカバリ処理を実施する
ことを特徴とする保守抑止装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、プログラムで動作する複数のプロセッサ及びメモリからなる制御装置の保守操作に関する。
【０００２】
【従来の技術】
プログラムで動作する複数のプロセッサ及びメモリからなる制御装置の保守を、装置に具備する保守専用機（以下「サービスプロセッサＳＶＰ」と略称する。）で行う際、サービスプロセッサが例えばパソコンと呼ばれるコンピュータのアプリケーションによって実施する場合の技術に関して以下説明する。
【０００３】
制御装置がホストマシンと連動して無停止状態で使用している場合の保守作業は、使用状態下で実施しなければならなく、保守操作でのミスは許されない。このようなことから、制御装置の保守実施の直前に、制御装置より状態情報（例えば、ディスク制御装置のチャネルアダプタが保守閉塞している状態である等）を取得して、その保守の続行により制御装置のシステムダウン、データロスト及び性能低下をさせないかチェックを行なっている。また、保守を中断する際には、メッセージを表示することで保守員に指示または注意を促している。
【０００４】
制御装置における障害の監視・検知及び、障害解析・回復に関する技術は既に公知である。例えば、障害監視技術は、特開平５−３２４３７７号公報の「プロセッサ監視システム」で示されている。また、障害回復については、特開平６−２８２４５１号公報の「マイクロプロセッサを備えた装置のシステムダウン復旧方法」で示されてる。
【０００５】
これらの障害に対する復旧技術は、自動的に行う点に特徴がある。
【０００６】
【発明が解決しようとする課題】
ところが、制御装置の状態は常に移行している。しかし、前記従来技術では装置状態の移行に伴ったチェックはされない。つまり、保守実施中における制御装置の障害は認識されない。このようなことから、保守実施中に障害が発生した場合、その障害部位が実施中の保守によりシステムダウン、データロスト及び制御装置性能低下等の２次障害を発生させる可能性がある。
【０００７】
例えば、先に示した公知例では、自動的に障害監視から回復まで可能であるが、その回復プロセス中に、保守員が別の保守操作を行った場合に、２次障害を発生させる可能性がある。また、回復中に保守員の操作を抑止する事も可能だが、障害にも重大なものから些細なものまであり、抑止させる判断が難しく、これを解決する従来技術はない。
【０００８】
本発明は、保守作業による制御装置のシステムダウン、データロスト及び、性能低下を未然に防ぐことが課題であり、制御装置において保守実施中の制御装置状態をいかにチェックし抑止するかが課題である。
【０００９】
【課題を解決するための手段】
前記課題を解決するために、主として本発明は次のような構成を採用する。
【００１０】
二重化されたプロセッサとメモリを有するディスク制御装置と、前記ディスク制御装置の保守を実施するために前記ディスク制御装置に接続された保守用コンピュータと、を備え、
前記保守用コンピュータは、
当該保守用コンピュータに搭載された保守用アプリケーションに基づいて実行する保守操作の保守種別及び当該保守操作の保守対象部位のＩＤを含む操作情報と、当該保守対象部位とは異なる他の部位のＩＤ及び当該部位の状態を含む装置状態情報と、前記ディスク制御装置の状態を復旧させるための対処アプリケーションの名称との組み合わせを、複数保持する、障害対処テーブルを備え、
前記保守用アプリケーションに基づいて実行した保守操作の保守種別及び保守対象部位のＩＤを含む操作情報と、当該保守対象部位とは異なる他の部位の装置状態と、を監視し、
前記監視した操作情報、他の部位の装置状態及び当該他の部位のＩＤと、前記障害対処テーブルに保持している操作情報及び装置状態情報とを照合し、
前記照合の結果、前記監視した操作情報、他の部位の装置状態及び当該他の部位のＩＤが、前記障害対処テーブルに保持している操作情報及び装置状態情報のいずれかに該当する場合、当該操作情報及び装置状態情報に対応する名称の対処アプリケーションを実行することによって、前記ディスク制御装置を、保守実施直前の状態に復旧させるリカバリ処理を実施する保守抑止装置。
【００１１】
ホストから送られる情報が格納されるディスク駆動装置と、
ホスト間の情報を制御する二重化されたチャネルアダプタ、前記ディスク駆動装置間の情報を制御する二重化されたディスクアダプタ、ディスクアクセスの高速化を図る二重化されたキャッシュメモリを有するディスク制御装置と、
前記ディスク制御装置又は前記ディスク駆動装置の保守を実施する保守用コンピュータと、を備えた保守抑止装置であって、
前記保守用コンピュータは、
前記チャネルアダプタと前記ディスクアダプタとに接続され、
当該保守用コンピュータに搭載された保守用アプリケーションに基づいて実行する保守操作の保守種別、及び、当該保守操作の保守対象部位であるチャネルアダプタ、ディスクアダプタまたはディスク駆動装置のＩＤを含む操作情報と、当該保守対象部位とは異なる他の部位であるチャネルアダプタ、ディスクアダプタまたはディスク駆動装置のＩＤ及び当該部位の状態を含む装置状態情報と、前記ディスク制御装置の状態を復旧させるための対処アプリケーションの名称との組み合わせを、複数保持する、障害対処テーブルを備え、
前記保守用アプリケーションに基づいて実行した保守操作の保守種別及び保守対象部位のＩＤを含む操作情報と、当該保守対象部位とは異なる他の部位であるチャネルアダプタ、ディスクアダプタ、または、ディスク駆動装置の装置状態と、を監視し、
前記監視した操作情報、他の部位の装置状態及び当該他の部位のＩＤと、前記障害対処テーブルに保持している操作情報及び装置状態情報とを照合し、
前記照合の結果、前記監視した操作情報、他の部位の装置状態及び当該他の部位のＩＤが、前記障害対処テーブルに保持している操作情報及び装置状態情報のいずれかに該当する場合、当該操作情報及び装置状態情報に対応する名称の対処アプリケーションを実行することによって、前記二重化されたチャネルアダプタ、前記二重化されたディスクアダプタ、または、前記ディスク駆動装置を、保守実施直前の状態に復旧させるリカバリ処理を実施する保守抑止装置。
【００１２】
【発明の実施の形態】
本発明の実施形態について、図面を用いて以下詳細に説明する。
【００１３】
図１と図２に本発明の実施形態を示す。ここにおいて、１０１はディスク制御装置の状態情報の取得機能、１０２は操作情報とディスク制御装置状態情報の相互チェックの実施機能、１０３は操作情報、ディスク制御装置及び対処アプリケーションの対応を示したテーブル、１０４はアプリケーションのインターフェース、１０５は操作来歴を格納するテーブル、１０６はディスク制御装置とアプリケーションＩ／Ｆとのやり取りを行うタスク、１０７は保守用のアプリケーション、１０８はリカバリ用のアプリケーション、１０９はメッセージ表示用のアプリケーション、１２０はＣＲＴ、１２１はキーボード、１２２はマウス、１２３はフロッピーディスクドライブ、２０１はホストマシン、２０２はディスク制御装置、２０３はサービスプロセッサ、２０４は共通バス、２０５，２０６はチャネルアダプタ、２０７，２０８はディスクアダプタ、２０９は不揮発性キャッシュメモリ、２１０は内部バス、２２０はディスク駆動装置、２２１はハードディスクユニット、２２２はディスク制御装置及び駆動装置に電力を提供するための電源、２２３はＳＣＳＩケーブル、をそれぞれ表す。
【００１４】
図２にディスクサブシステム装置を示す。ディスクサブシステム装置は、ディスク制御装置２０２（以下「ＤＫＣ」と略称する。）とディスク駆動装置２２０（以下「ＤＫＵ」と略称する。）により構成されている。
【００１５】
ＤＫＣ２０２には、ホスト２０１間の情報を制御するチャネルアダプタ２０５，２０６（以下「ＣＨＡ」と略称する。）、ＤＫＵ２２０間の情報を制御するディスクアダプタ２０７，２０８（以下「ＤＫＡ」と略称する。）、ディスクアクセスの高速化を目的とした不揮発性キャッシュメモリ２０９（以下「ＣＭ」と略称する。）によって構成されている。
【００１６】
また、これらは全て二重化されており、内部バス２１０により接続され通信可能となっている。ＣＨＡ２０５，２０６とＤＫＡ２０７，２０８にはマイクロプロセッサ（以下「ＭＰ」と略称する。）が搭載されている。また、ＤＫＣ２０２には保守を目的としたサービスプロセッサＳＶＰ２０３が搭載されており、ＣＨＡ２０５，２０６／ＤＫＡ２０７，２０８／ＣＭ２０９は共通バス２０４により接続されて通信可能となっている。
【００１７】
ＤＫＵ２２０には、顧客情報を格納するディスク群２２１（以下「ＨＤＵ」と略称する。）及び、ＤＫＵとＤＫＣに電力を供給する電源２２２が搭載されている。また、ＨＤＵ２２１とＤＫＡ２０７，２０８をＳＣＳＩケーブル２２３により接続されている。
【００１８】
図１に本発明の実施形態の構成を示す。図１の点線で囲まれた左側部分はサービスプロセッサ２０３の内部構成を示し、その左側部分はディスク制御装置２０２を示している。
【００１９】
保守員によりキーボード１２１またはマウス１２２により、アプリケーションＡＰ１０７を起動し保守を実行する。その後、ＡＰ１０７は、入力された具体的な保守手順を分割してコマンド単位（保守閉塞とか、または交換とか、またはリカバリとかのコマンド単位）をＡＰ Ｉ／Ｆ１０４へ発行する。ＡＰ Ｉ／Ｆ１０４は受け取ったコマンド単位を来歴１０５への格納とＤＫＣ状態情報取得１０１へ発行をする。すなわち、コマンド単位毎にＤＫＣ状態情報を取得できるようにトリガーをかけているのである。
【００２０】
ＤＫＣ状態情報取得は現在のＤＫＣ状態をＤＫＣ通信１０６より取得し、操作＆状態（操作情報と装置状態）の相互チェック１０２（カレントな情報が、図３に示す条件式に当てはまるかどうかを突き合わせること）を起動（トリガー）する。
【００２１】
操作＆状態の相互チェック１０２は、操作情報をＡＰＩ／Ｆ１０４を介して来歴１０５より取得する。また、チェック条件として条件式１０３を取得し、その現在のＤＫＣ状態情報、操作情報及び条件式より相互間のチェックを１０２が実施し、次処理の指示をＡＰＩ／Ｆ１０４へ行う。
【００２２】
ＡＰＩ／Ｆ１０４は、その指示によりＤＫＣ通信１０６へのコマンド発行、リカバリ用ＡＰへのコマンド発行、メッセージ表示用ＡＰ１０９へのコマンド発行、ＡＰ１０７へのコマンド発行を行う。ＤＫＣ通信１０６へのコマンド発行の場合、コマンドを受け取ったＤＫＣ通信１０６は共通バス２０４を通して該当ＭＰ２０５〜２０８へコマンドを発行する。
【００２３】
このように、本発明では、制御装置の保守は、制御装置に搭載されたサービスプロセッサから各マイクロプロセッサへコマンドを発行することで実施される為に、サービスプロセッサによりこれらのコマンド発行単位に制御装置の状態のチェックを実施する。このチェックを実施するによって、装置の状態情報を随時取得し、操作情報及び装置状態情報により次の処理を決定する為の条件式が必要となる。これらを用いて、保守用アプリケーションから発行されたコマンドをアプリケーションＩ／Ｆにより各タスクへ振り分ける。そうすることにより、コマンド発行単位での制御装置の状態チェックを実現させ、制御装置のシステムダウン、データロスト及び性能低下を未然に防ぐこととする。
【００２４】
図３に条件式を示し、都合の悪い状態を予めテーブル化しておいてそれに準拠して処理を行い、前記テーブルに当てはまらないときには保守作業を続行してもよいことを意味している。
【００２５】
条件式とは、操作情報とＤＫＣ状態の対応表で、この２つの状態により次処理を決定する。この条件式には、操作情報、ＤＫＣの装置状態、対処ＡＰ、の大きく３つに分けられる。
【００２６】
操作情報には、保守を実施したアプリケーション（ＡＰ）名称（オペレータが保守に対応してＡＰを選択するもの）、保守の種類、対象の保守部位、対象保守の詳細部位、対象部位の状態を記載する。ここにおいて、例えば、パッケージボードとなっているＣＨＡ１を交換する場合、当該ＣＨＡ１は二重化されているので、交換すべきボードを交換という保守のために保守閉塞の状態にして、交換しようとする。
【００２７】
また、ＤＫＣの装置状態には、他資源の部位、他資源の詳細部位、他資源部位の状態を記載する。ここにおいて、例えば、前記当該ＣＨＡ１の一方のボード、即ち、他資源の状態を把握しておかないと、二重化されているといえどもシステム全体がダウンしてしまうおそれがある。
【００２８】
対処ＡＰにはリカバリまたはメッセージ表示時の対象ＡＰを記載する。ここにおいて、例えば、システムダウンしそうな状況がでてくれば、保守閉塞しているボードをリカバリさせるべくリカバリＡＰ１を動作させるということになる。
【００２９】
図３の下段に示した［例］は、操作情報は「交換ＡＰによるＣＨＡの１番目の交換」である。また、ＤＫＣ状態は「ＤＫＡの３番目が障害閉塞」である。その結果対処ＡＰとして「メッセージ表示用ＡＰ」が起動され、保守員に対してメッセージにより警告を表示する。このように、条件式は、操作情報、装置状態、対処ＡＰにおけるそれぞれの項目が特定されて多数の考えられ得る条件式が出来上がるものである。即ち、考えられ得る全ての状況を把握しその対処の仕方（メッセージを表示するとか、適宜のリカバリ用ＡＰを動作させる等）までも前記条件式に含ませてしまうものである。
【００３０】
図４はＡＰＩ／Ｆ１０４のフローチャートを示す。
【００３１】
ＡＰＩ／Ｆ１０４として、保守用ＡＰからのコマンド有無４０１、ＤＫＣ通信からのコマンド有無４０２、相互チェックからのコマンド有無４０３、の大きく３つからなる。
【００３２】
まず、保守用ＡＰからのコマンド４０１があった場合、そのコマンドの操作来歴を格納４１０する。その後、保守用ＡＰからの受信４１１だった場合、ＤＫＣ通信へコマンドを発行４１３する。また、リカバリＡＰからの受信４１２だった場合には、回答先を判断４１４し、ＤＫＣ通信への回答の場合、ＤＫＣ通信へコマンドを発行４１５する。
【００３３】
次に、ＤＫＣ通信からのコマンド４０２があった場合、そのコマンドの操作来歴を格納４２０する。その後、保守用ＡＰからの受信４２１だった場合、ＤＫＣ通信へコマンドを発行４２３する。また、リカバリＡＰからの受信４２２だった場合には、リカバリ用ＡＰへコマンドを発行４２４する。
【００３４】
次に、相互チェックからのコマンド４０３があった場合、そのコマンドの操作来歴を格納４３０する。その後、操作を抑止するか判断４３１し、抑止する場合には対象のリカバリＡＰを検索４３３し、その対象リカバリ用ＡＰへコマンドを発行４３４する。
【００３５】
また、抑止しない場合、対象の保守用ＡＰへ正常報告４３２を行う。
【００３６】
これらの３つのチェックをループすることにより、常に監視する。
【００３７】
図５はＤＫＣ状態情報取得１０１のフローチャートを示す。ＤＫＣ状態情報取得１０１では、ＡＰＩ／Ｆからのコマンド５０１があった場合、ＤＫＣ状態情報をＤＫＣより取得５１１し、操作＆ＤＫＣ状態の相互チェックへ指示を発行５１１する。この処理をループすることにより、常に最新のＤＫＣ状態情報を取得する。
【００３８】
図６は操作＆状態の相互チェック１０２のフローチャートを示す。操作＆状態の相互チェック１０２では、相互チェック実施の指示６０１があった場合、対象の条件式を検索及び取得６１１する。その後、条件式とＤＫＣ状態と操作来歴のチェック６１２を行なう。その結果６１３、保守を抑止する場合には、ＡＰＩ／Ｆへリカバリ処理の指示を発行６１５する。また、保守を抑止しない場合には、ＡＰ Ｉ／Ｆへ正常報告を発行６１４する。この処理をループすることにより、常に操作＆状態の相互チェックを実施可能な状態とする。
【００３９】
以上の説明では、装置状態の情報として、主として、ディスク制御装置の状態を対象としていたが、これに加えて、ディスク駆動装置の状態も含み得ることができるものである。
【００４０】
【発明の効果】
本発明によって、制御装置は無停止状態での保守が要求されており、保守による２次障害を事前及び保守中に回避することが可能となる。また、メッセージ表示による操作性の向上やリカバリ処理の自動化により保守性及び信頼性が向上する効果がある。
【図面の簡単な説明】
【図１】本発明の実施形態１を示す構成図である。
【図２】本発明の実施形態を実施するハードウェア構成図で、特に磁気ディスク装置のハードウェア概略図である。
【図３】操作情報、制御装置及び対処アプリケーションの対応を示したテーブルを示す図である。
【図４】本発明の実施形態を実現するためのフローチャートである。
【図５】本発明の実施形態を実現するためのフローチャートである。
【図６】本発明の実施形態を実現するためのフローチャートである。
【符号の説明】
１０１：ディスク制御装置の状態情報の取得機能
１０２：操作情報とディスク制御装置状態情報の相互チェックの実施機能
１０３：操作情報、ディスク制御装置及び対処アプリケーションの対応を示したテーブル
１０４：アプリケーションのインターフェース
１０５：操作来歴を格納するテーブル
１０６：ディスク制御装置とアプリケーションＩ／Ｆとのやり取りを行うタスク
１０７：保守用のアプリケーション
１０８：リカバリ用のアプリケーション
１０９：メッセージ表示用のアプリケーション
１２０：ＣＲＴ
１２１：キーボード
１２２：マウス
１２３：フロッピーディスクドライブ
２０１：ホストマシン
２０２：ディスク制御装置
２０３：サービスプロセッサ
２０４：共通バス
２０５，２０６：チャネルアダプタ
２０７，２０８：ディスクアダプタ
２０９：不揮発性キャッシュメモリ
２１０：内部バス
２２０：ディスク駆動装置
２２１：ハードディスクユニット
２２２：ディスク制御装置及び駆動装置に電力を提供するための電源
２２３：ＳＣＳＩケーブル
【図１】
0003961617.tif 000002
【図２】
0003961617.tif 000003
【図３】
0003961617.tif 000004
【図４】
0003961617.tif 000005
【図５】
0003961617.tif 000006
【図６】
0003961617.tif 000007