(57)【特許請求の範囲】
【請求項１】
情報処理を実行する複数の処理ユニットであって、該複数の処理ユニットのうちのいずれかの処理ユニットが動作を停止しても前記情報処理を続行可能な複数の処理ユニットと、
動作の停止が可能な処理ユニットを選択する選択部と、
他の処理ユニットが前記選択された処理ユニットの処理を引き継ぐ場合、前記選択された処理ユニットに再起動の指示を行う制御部と
を備え、
前記制御部は、再起動しなかった処理ユニットを検出し、該処理ユニットについて交換又は修理を依頼する情報を出力する障害顕在化処理を実行する
ことを特徴とする情報処理装置。
【請求項２】
前記複数の処理ユニットが、冗長性を有するディスクアレイ装置の構成要素として使用されている複数のディスクドライブである
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記障害顕在化処理が、
再起動しなかったディスクドライブと再起動したが障害の存在が検出されたディスクドライブとについて、前記情報を出力する処理である
ことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記制御部は、
ユーザにより入力された前記情報処理装置の停止予定日時と、前記ディスクアレイ装置を構成しているディスクドライブの台数と、１台のディスクドライブの交換に要する時間とから、前記ディスクアレイ装置の全てのディスクドライブを交換しても前記障害顕在化処理が前記停止予定日時以前に完了する日時を算出し、
算出した日時以前にユーザに前記障害顕在化処理の開始指示の入力を促し、
前記開始指示が入力されたときに、前記障害顕在化処理を開始する
ことを特徴とする請求項２または３に記載の情報処理装置。
【請求項５】
情報処理を実行する複数の処理ユニットであって、該複数の処理ユニットのうちのいずれかの処理ユニットが動作を停止しても前記情報処理を続行可能な複数の処理ユニットを含む情報処理装置において、
前記複数の処理ユニットの１つとして、マスター処理ユニットを備え、
前記マスター処理ユニットは、
動作の停止が可能な処理ユニットを選択し、
他の処理ユニットが前記選択された処理ユニットの処理を引き継ぐ場合、前記選択された処理ユニットに再起動の指示を行い、
再起動しなかった処理ユニットを検出し、該処理ユニットについて交換又は修理を依頼する情報を出力する障害顕在化処理を実行する
ことを特徴とする情報処理装置。
【請求項６】
前記複数の処理ユニットが、冗長性を有するディスクアレイ装置の構成要素として使用されている複数のディスクドライブであり、
前記マスター処理ユニットは、
ユーザにより入力された前記情報処理装置の停止予定日時と、前記ディスクアレイ装置を構成しているディスクドライブの台数と、１台のディスクドライブの交換に要する時間とから、前記ディスクアレイ装置の全てのディスクドライブを交換しても前記障害顕在化処理が前記停止予定日時以前に完了する日時を算出し、
算出した日時以前にユーザに前記障害顕在化処理の開始指示の入力を促し、
前記開始指示が入力されたときに、前記障害顕在化処理を開始する
ことを特徴とする請求項５に記載の情報処理装置。
【請求項７】
情報処理を実行する複数の処理ユニットであって、該複数の処理ユニットのうちのいずれかの処理ユニットが動作を停止しても前記情報処理を続行可能な複数の処理ユニットを含む情報処理装置の保守方法において
コンピュータが、
動作の停止が可能な処理ユニットを選択し、
他の処理ユニットが前記選択された処理ユニットの処理を引き継ぐ場合、前記選択された処理ユニットに再起動の指示を行い、
再起動しなかった処理ユニットを検出し、該処理ユニットについて交換又は修理を依頼する情報を出力する障害顕在化処理を実行する
ことを特徴とする情報処理装置の保守方法。
【請求項８】
前記複数の処理ユニットが、冗長性を有するディスクアレイ装置の構成要素として使用されている複数のディスクドライブであり、
前記コンピュータが、
ユーザにより入力された前記情報処理装置の停止予定日時と、前記ディスクアレイ装置を構成しているディスクドライブの台数と、１台のディスクドライブの交換に要する時間とから、前記ディスクアレイ装置の全てのディスクドライブを交換しても前記障害顕在化処理が前記停止予定日時以前に完了する日時を算出し、
算出した日時以前にユーザに前記障害顕在化処理の開始指示の入力を促し、
前記開始指示が入力されたときに、前記障害顕在化処理を開始する
ことを特徴とする請求項７に記載の情報処理装置の保守方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置と情報処理装置の保守方法とに関する。
【背景技術】
【０００２】
情報処理装置の中には、或る構成要素に障害が発生した場合、当該構成要素が行っていた処理を他の構成要素が自動的に引き継ぐ構成（以下、冗長構成と表記する）を有するもの（例えば、特許文献１参照）が、存在している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−３０１５６５号公報
【特許文献２】特開平６−４４０９５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
冗長構成を有する情報処理装置は、通常、装置を停止させることなく、障害が発生した構成要素の交換を行える装置となっているが、情報処理装置が設置されている建屋の法定点検等のために、情報処理装置を停止せざる得ない場合もある。
【０００５】
法定点検等のために計画的に情報処理装置を停止する場合、通常、情報処理装置が問題なく再起動できることを前提として、法定点検等の完了予定日時から、情報処理装置の運用再開日時を決定して情報処理装置の各ユーザに通知している。しかしながら、各構成要素が老朽化／劣化している情報処理装置では、上記のような再起動時に、幾つかの構成要素が再起動（電源のＯＦＦ／ＯＮ）の負荷に耐えられず立ち上がらないことがある。そして、立ち上がらなかった構成要素の数が冗長構成で対応可能な数を超えていた場合には、構成要素の交換等が必要となるため、予定通りに情報処理装置の運用を再開できないことになる。
【０００６】
１つの側面では、本発明は、計画停止後の再起動時等に、構成要素の交換（又は修理）が必要となることを抑制できる情報処理装置及び情報処理装置の保守方法を提供することにある。
【課題を解決するための手段】
【０００７】
一態様の情報処理装置は、情報処理を実行するための複数の処理ユニットであって、該複数の処理ユニットのうちのいずれかの処理ユニットが動作を停止しても情報処理を続行可能な複数の処理ユニットと、前記複数の処理ユニットを１つずつ順々に再起動し、再起動しなかった処理ユニットについて交換又は修理を依頼する情報を出力する処理を実行可能な制御部と、を備える。
【０００８】
また、他の態様の情報処理装置は、情報処理を実行する複数の処理ユニットであって、該複数の処理ユニットのうちのいずれかの処理ユニットが動作を停止しても情報処理を続行可能な複数の処理ユニットを含む情報処理装置において、複数の処理ユニットの１つとして、複数の処理ユニットを１つずつ順々に再起動し、再起動しなかった処理ユニット毎にその交換又は修理を依頼する情報を出力する潜在障害検出処理を実行可能なマスター処理ユニットを備える・
【０００９】
また、一態様では、情報処理を実行する複数の処理ユニットであって、該複数の処理ユ
ニットのうちのいずれかの処理ユニットが動作を停止しても前記情報処理を続行可能な複数の処理ユニットを含む情報処理装置の保守方法は、コンピュータが、複数の処理ユニットを１つずつ順々に再起動し、再起動しなかった処理ユニット毎にその交換又は修理を依頼する情報を出力する。
【発明の効果】
【００１０】
計画停止後の再起動時等に、情報処理装置の構成要素の交換／修理が必要になることを防止できる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態に係る情報処理装置の構成、使用形態の説明図
【図２】実施形態に係る情報処理装置内のマスターＣＭが実行する計画停止準備処理の流れ図
【図３】計画停止準備処理中で実行される潜在障害検出復旧処理の流れ図（その１）
【図４】潜在障害検出復旧処理の流れ図（その２）
【図５】潜在障害検出復旧処理の流れ図（その３）
【図６】マスターＣＭが備える処理状況管理テーブルの説明図
【図７】マスターＣＭが実行するマスター用ディスク診断処理の流れ図（その１）
【図８】マスターＣＭが実行するマスター用ディスク診断処理の流れ図（その２）
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態について、図面を参照して詳細に説明する。尚、以下で説明する実施形態は、本発明の一例に過ぎず、本発明は、実施形態とは具体的な構成／手順が異なる形でも実現することができるものである。
【００１３】
まず、図１を用いて、本発明の一実施形態に係る情報処理装置１００の概要を説明する。
【００１４】
図１に示してあるように、情報処理装置１００は、１台以上のホスト２００と保守端末３００とが接続される装置（ストレージシステム）であり、偶数台のＣＭ（制御モジュール：Controller Module）１０と幾つかのＤＥ（Drive Enclosure）２０とを備える。
【００１５】
情報処理装置１００が備える各ＤＥ２０は、ディスク（ハードディスクドライブ）を規定台数まで装着可能な本体ユニットに、複数台（規定台数以下）のディスクを装着したユニットである。
【００１６】
各ＣＭ１０は、情報処理装置１００内（全ＤＥ２０内）の複数台のディスクを、複数のＲＬＵとして機能させるユニットである。尚、ＲＬＵ（RAID (Redundant Array of Independent Disks) logical unit）とは、ＲＡＩＤグループ、ディスクアレイ装置等とも呼ばれているもの（本実施形態では、冗長性を有するもの）のことである。
【００１７】
各ＣＭ１０は、一種のコンピュータであり、図１に示してあるように、ＣＰＵ（Central Processing Unit）１３及びキャッシュメモリ１５を備えている。また、各ＣＭ１０は
、ホスト３００用のインタフェース回路であるＣＡ（Channel Adapter）１１、他ＣＭ１
０とバス３０を介した通信を行うための通信インタフェース１２、及び、ＤＥ２０用のインタフェース回路である２つのＤＩ（Device Interface）１４も備えている。
【００１８】
さらに、各ＣＭ１０は、以下のコンポーネント（図示略）も備えている。
・ＢＩＯＳ（Basic Input Output System）等を記憶したフラッシュＲＯＭ（Read Only Memory）
・システムディスク（特定のＲＬＵ）から読み出されるプログラムの記憶領域、当該プログラムの作業領域等として使用されるＤＲＡＭ（Dynamic Random Access Memory）
・各種情報（設定値等）を記憶しておくための、バッテリバックアップされたＣＭＯＳ（Complementary Metal-Oxide Semiconductor）メモリ
・保守端末３００を含むＬＡＮ（Local Area Network）に接続されるＬＡＮポート
【００１９】
情報処理装置１００内の各ＣＭ１０には、制御を担当する幾つかのＲＬＵが予め割り当てられている。そして、各ＣＭ１０は、自身が制御を担当している各ＲＬＵ（以下、担当ＲＬＵと表記する）に対するリード／ライト要求をホスト２００から受信し、受信したリード／ライト要求に、担当ＲＬＵ内の１つ或いは複数のディスクを制御することにより、応答する。
【００２０】
また、情報処理装置１００内の複数台のＣＭ１０は、２台ずつペアを成しており、各ＣＭ１０は、自身とペアを成しているＣＭ１０（以下、ミラーＣＭとも表記する）が故障した場合、ミラーＣＭが行っていた処理を引き継ぐ。また、情報処理装置１００内の１台のＣＭ１０は、マスターＣＭとして動作し、他の各ＣＭ１０は、スレーブＣＭとして動作する。
【００２１】
次に、本実施形態に係る情報処理装置１００の動作（情報処理装置１００内の各ＣＭ１０が有している機能）を、説明する。
【００２２】
情報処理装置１００内のマスターＣＭは、保守端末３００を入出力装置として利用して、ユーザ（情報処理装置１００の管理者等）との間で情報交換（ユーザからの指示の取得、ユーザへの情報の提示）を行う機能を有している。
【００２３】
当該機能は、計画停止準備処理の開始指示をユーザから取得できるものとなっている。ここで、計画停止準備処理の開始指示とは、情報処理装置１００を停止させる日時（以下、計画停止日時と表記する）の指定を含む指示のことである。ユーザは、情報処理装置１００が設置されている建築物についての法定点検等のために情報処理装置１００を停止させざるを得ない場合等に、保守端末３００を操作することにより、計画停止準備処理の開始指示を出す。
【００２４】
ユーザが計画停止準備処理の開始指示を出したことを検出（認識）したマスターＣＭは、図２に示した手順の計画停止準備処理を開始する。
【００２５】
説明の便宜上、この計画停止準備処理中のステップＳ１０１〜Ｓ１０４の処理の内容については後述することとし、まず、ステップＳ１０５にてマスターＣＭが実行する潜在障害検出復旧処理の内容を説明する。
【００２６】
図３〜図５に、潜在障害検出復旧処理の流れ図を示す。
【００２７】
図３に示してあるように、潜在障害検出復旧処理を開始したマスターＣＭは、まず、処理状況管理テーブルを初期化する（ステップＳ２０１）。
【００２８】
処理状況管理テーブルは、マスターＣＭのＣＭＯＳメモリ上の、図６に模式的に示したような構成を有するテーブルである。すなわち、処理状況管理テーブルは、バッテリバックアップされたＣＭＯＳメモリ上の、情報処理装置１００内のデバイス（ＣＭ１０、ディスク）毎に状況値を記憶できるテーブルとなっている。
【００２９】
この処理状況管理テーブルに記憶される状況値は、各デバイスに対する処理の進行状況
や処理結果を示す情報である。状況値としては、以下の意味／用途のものが用意されている。
【００３０】
《ＣＭ１０、ディスクの双方に対して使用される状況値》
・未だ何ら処理が行われていないことを示す「ＯＦＦ／ＯＮ前」
・交換（又は修理）が必要であることを示す「保守・交換待ち」
・潜在障害検出復旧処理が完了した（電源をＯＦＦ／ＯＮしても問題が生じないことが確認できた；電源をＯＦＦ／ＯＮしても問題が生じないものに交換された）ことを示す「ＯＦＦ／ＯＮ済」
《ＣＭ１０に対してのみ使用される状況値》
・ミラーＣＭが異常であるが故に処理（再起動等）を行っていないことを示す「他ＣＭが異常」
【００３１】
上記したステップＳ２０１の処理では、この処理状況管理テーブルが、『情報処理装置１００内の全デバイスについて状況値を記憶可能な、各デバイスについて、状況値「ＯＦＦ／ＯＮ前」が設定されているテーブル』に初期化される。
【００３２】
ステップＳ２０１（図３）の処理を終えたマスターＣＭは、処理状況管理テーブル上の状況値が「ＯＦＦ／ＯＮ前」となっているＣＭ１０の中から、以降の各ステップの処理を行うＣＭ１０である処理対象ＣＭを選択する（ステップＳ２０２）。以下、処理状況管理テーブル上の状況値が「〜」（〜＝“ＯＦＦ／ＯＮ前”、“ＯＦＦ／ＯＮ済”等）となっているＣＭ１０のことを、「〜」ＣＭとも表記する。また、「ＯＦＦ／ＯＮ前」ＣＭのことを、未処理ＣＭとも表記する。
【００３３】
処理対象ＣＭを選択したマスターＣＭは、処理状況管理テーブル上の状況値に基づき、処理対象ＣＭのミラーＣＭが、処理対象ＣＭの処理を引き継げる状態にあるか否かを判断する（ステップＳ２０３）。具体的には、このステップＳ２０３の実行時、マスターＣＭは、まず、処理対象ＣＭのミラーＣＭの状況値を処理状況管理テーブル（図６）から読み出す。そして、マスターＣＭは、読み出した状況値が、「ＯＦＦ／ＯＮ前」又は「ＯＦＦ／ＯＮ済」であった場合には、処理対象ＣＭのミラーＣＭが、処理対象ＣＭの処理を引き継げる状態にあると判断する。また、マスターＣＭは、読み出した状況値が、「ＯＦＦ／ＯＮ前」、「ＯＦＦ／ＯＮ済」のいずれでもなかった場合には、処理対象ＣＭのミラーＣＭが、処理対象ＣＭの処理を引き継げる状態にないと判断する。
【００３４】
ミラーＣＭが処理対象ＣＭの処理を引き継げる場合（ステップＳ２０３；ＹＥＳ）、マスターＣＭは、図４のステップＳ２１０以降の処理を開始する。換言すれば、処理対象ＣＭの処理をミラーＣＭに引き継がせることが出来るが故に、処理対象ＣＭの動作を停止させても全てのＲＬＵに対するリード／ライト要求に応答できる状態を維持できる場合、マスターＣＭは、図４のステップＳ２１０以降の処理を開始する。
【００３５】
ステップＳ２１０にて、マスターＣＭは、処理対象ＣＭが自ＣＭであるか否かを判断する。
【００３６】
処理対象ＣＭが自ＣＭではなかった場合（ステップＳ２１０；ＮＯ）、マスターＣＭは、バス３０を介した通信により、処理対象ＣＭ（他ＣＭ）に対して起動モードの診断モードへの変更と再起動とを指示する（ステップＳ２１１，Ｓ２１２）。ここで、診断モードとは、起動が完了する迄の間に、通常の起動モード（以下、通常モードと表記する）で起動した際に行われる診断処理よりも詳細な診断処理が行われることになる起動モードのことである。
【００３７】
ステップＳ２１１及びＳ２１２の処理が行われると、処理対象ＣＭは、通常（再起動に因り大きな障害が顕在しない限り）、自ＣＭ内の各部（ＣＡ１１、通信インタフェース１２、ＣＰＵ１３、ＤＩ１４、キャッシュメモリ１５，ＣＭＯＳメモリ等）について比較的に詳しい診断処理を行ってから立ち上がる。そして、立ち上がった処理対象ＣＭは、起動が完了した旨の再起動完了通知を、マスターＣＭに対して送信する。
【００３８】
一方、ステップＳ２１２の処理を終えたマスターＣＭは、再起動完了監視処理（ステップＳ２１３）を開始して、処理対象ＣＭから再起動完了通知が送信されてくることと待機時間が経過することとを監視している状態となる。尚、“待機時間が経過する”とは、“再起動指示後の経過時間が待機時間以上となる”ということである。また、待機時間とは、ＣＭ１０の再起動に要する最長時間（その時間待っても再起動完了通知が送信されてこなかった場合にＣＭ１０が故障していると判定できる最短時間）として予め定められている時間のことである。
【００３９】
マスターＣＭは、待機時間が経過する前に処理対象ＣＭからの再起動完了通知を受信した場合には、処理対象ＣＭが立ち上がったと判断して、再起動完了監視処理を終了する。また、マスターＣＭは、再起動完了通知を受信することなく待機時間が経過した場合には、処理対象ＣＭが立ち上がらなかったと判断して、再起動完了監視処理を終了する。
【００４０】
再起動完了監視処理を終了したマスターＣＭは、処理対象ＣＭが立ち上がった場合（ステップＳ２１４；ＹＥＳ）には、処理対象ＣＭに対して起動モードの通常モードへの変更を指示する（ステップＳ２１５）。次いで、マスターＣＭは、処理対象ＣＭから診断処理の結果（図４では、診断結果）を取得する（ステップＳ２１６）。その後、マスターＣＭは、図３のステップＳ２０４以降の処理（詳細は後述）を開始する。
【００４１】
一方、処理対象ＣＭが立ち上がらなかった場合（ステップＳ２１４；ＮＯ）、マスターＣＭは、図３のステップＳ２０６以降の処理（詳細は後述）を開始する。
【００４２】
マスターＣＭは、処理対象ＣＭが、他ＣＭではなく自ＣＭであった場合（ステップＳ２１０；ＹＥＳ）には、自身の起動モードを診断モードに変更してから、自身を再起動する（ステップＳ２２１、Ｓ２２２）。
【００４３】
ステップＳ２２２の処理を終えたマスターＣＭは、一旦、自身をＯＦＦしてから、診断モード用のブート処理、すなわち、通常よりも詳細な診断処理を含むブート処理（ステップＳ２２３）を行うことにより、起動を完了する。そして、起動したマスターＣＭは、自身の起動モードを通常モードに戻す処理（ステップＳ２２４）を行ってから、図３のステップＳ２０４以降の処理を開始する。
【００４４】
尚、詳細説明は省略するが、この潜在障害検出復旧処理時、マスターＣＭは、自身のミラーＣＭに、随時、処理の進行状況を通知する。また、マスターＣＭのミラーＣＭは、マスターＣＭからの情報に基づき潜在障害検出復旧処理の進行状況を把握し、マスターＣＭによりステップＳ２２２の処理が実行された場合には、マスターＣＭの再起動状況の監視を開始する。そして、ミラーＣＭは、マスターＣＭが再起動しなかった場合には、マスターＣＭとしての動作を開始して、ステップＳ２０６の処理から実行する形で再起動しなかったマスターＣＭがそれまで実行していた潜在障害検出復旧処理を引き継ぐ。
【００４５】
ステップＳ２０４（図３）にて、マスターＣＭは、処理対象ＣＭ（自ＣＭ又は他ＣＭ）の診断処理により障害箇所が検出されたか否かを判断する。
【００４６】
診断処理により障害箇所が検出されていなかった場合（ステップＳ２０４；ＮＯ）、マ
スターＣＭは、処理状況管理テーブル上の処理対象ＣＭの状況値を「ＯＦＦ／ＯＮ済」に変更する（ステップＳ２０５）。そして、マスターＣＭは、未処理ＣＭ（「ＯＦＦ／ＯＮ前」ＣＭ）が残っているか否かを判断（ステップＳ２０９）し、残っていた場合（ステップＳ２０９；ＹＥＳ）には、ステップＳ２０２以降の処理を再び実行する。
【００４７】
一方、診断処理により障害箇所が検出されていた場合（ステップＳ２０４；ＹＥＳ）、マスターＣＭは、処理対象ＣＭの交換（修理）をユーザに依頼するためのＣＭ交換依頼メッセージを保守端末３００のディスプレイ上に表示する（ステップＳ２０６）。また、マスターＣＭは、処理対象ＣＭが立ち上がらなかった場合（図４、ステップＳ２１４；ＮＯ）には、ステップＳ２０４の処理を行うことなく、このステップＳ２０６の処理を行う。
【００４８】
ステップＳ２０６の処理を終えたマスターＣＭは、処理状況管理テーブル上の処理対象ＣＭの状況値を「保守・交換待ち」に変更する（ステップＳ２０７）。その後、マスターＣＭは、未処理ＣＭが残っているか否かを判断（ステップＳ２０９）し、未処理ＣＭが残っていた場合（ステップＳ２０９；ＹＥＳ）には、ステップＳ２０２に戻って未処理ＣＭに対する処理を行う。
【００４９】
ここまでの説明から明らかなように、或るＣＭ１０に対してステップＳ２０７の処理が行われた後に、当該ＣＭ１０のミラーＣＭが処理対象ＣＭとして選択された場合に、処理対象ＣＭのミラーＣＭの状況値が「保守・交換待ち」となる。
【００５０】
処理対象ＣＭのミラーＣＭの状況値が「保守・交換待ち」となっていた場合（処理対象ＣＭの処理をミラーＣＭが引き継げない場合：ステップＳ２０３；ＮＯ）、マスターＣＭは、処理対象ＣＭの状況値を「他ＣＭが異常」に変更する（ステップＳ２０８）。そして、マスターＣＭは、ステップＳ２０９の処理（判断）を行う。
【００５１】
このような処理を繰り返しているうちに、未処理ＣＭがなくなった場合（ステップＳ２０９）、図５に示してあるように、マスターＣＭは、「保守・交換待ち」ＣＭが存在しているか否かを判断する（ステップＳ２３０）。尚、「保守・交換待ち」ＣＭとは、既に定義したように、処理状況管理テーブル上の状況値が「保守・交換待ち」となっているＣＭ１０のことである。
【００５２】
「保守・交換待ち」ＣＭが存在していた場合（ステップＳ２３０；ＹＥＳ）、マスターＣＭは、いずれかの（又は、唯一の）「保守・交換待ち」ＣＭが交換されるのを待機する（ステップＳ２３１）。このステップＳ２３１では、例えば、或るＣＭ１０の交換完了が保守端末３００経由でユーザから通知されるのを監視（待機）する処理や、ＣＭ１０の交換完了を自動検出する処理が、行われる。
【００５３】
マスターＣＭは、或る「保守・交換待ち」ＣＭが交換されたことを検出した場合（ステップＳ２３１；ＹＥＳ）には、まず、交換されたＣＭ１０についての処理状況管理テーブル上の状況値を「ＯＦＦ／ＯＮ前」に変更する（ステップＳ２３２）。次いで、マスターＣＭは、交換されたＣＭ１０のミラーＣＭの状況値が「他ＣＭが異常」であるか否かを判断する（ステップＳ２３３）。そして、マスターＣＭは、当該状況値が「他ＣＭが異常」であった場合（ステップＳ２３３；ＹＥＳ）には、当該状況値を「ＯＦＦ／ＯＮ前」に変更（ステップＳ２３４）してから、ステップＳ２３０以降の処理を開始する。また、マスターＣＭは、交換されたＣＭ１０のミラーＣＭの状況値が「他ＣＭが異常」ではなかった場合（ステップＳ２３３；ＮＯ）には、当該状況値（この場合、「ＯＦＦ／ＯＮ済」）を変更することなく、ステップＳ２３０以降の処理を開始する。
【００５４】
上記のような処理を繰り返しているうちに、「保守・交換待ち」ＣＭがなくなった場合
（ステップＳ２３０；ＮＯ）、マスターＣＭは、「ＯＦＦ／ＯＮ前」ＣＭが存在しているか否かを判断する（ステップＳ２３５）。また、マスターＣＭは、初めから「保守・交換待ち」ＣＭがなかった場合（ステップＳ２３０；ＮＯ）には、ステップＳ２２１等の処理を一回も行うことなく、ステップＳ２３５の判断を行う。
【００５５】
そして、マスターＣＭは、「ＯＦＦ／ＯＮ前」ＣＭが存在していなかった場合（ステップＳ２３５；ＮＯ）には、ステップＳ２３６以降の処理（詳細は後述）を開始する。
【００５６】
一方、「ＯＦＦ／ＯＮ前」ＣＭが存在していた場合（ステップＳ２３５；ＹＥＳ）、マスターＣＭは、図３のステップＳ２０２以降の処理を実行することにより、交換後の各ＣＭ１０が再起動しても問題が生じないものであるか否かをチェックする。そして、交換後の全ＣＭ１０が再起動しても問題が生じないものであることを確認できた場合（ステップＳ２３０；ＮＯ、ステップＳ２３５；ＮＯ）に、マスターＣＭは、ステップＳ２３６以降の処理を開始する。
【００５７】
ステップＳ２３６にて、マスターＣＭは、他の各ＣＭ１０（スレーブＣＭ）に、ディスク診断処理開始指示を送信する。このディスク診断処理開始指示は、それを受信したスレーブＣＭが、各担当ＲＬＵについてのスレーブ用ディスク診断処理（詳細は後述）を並行的に実行し、全スレーブ用ディスク診断処理の完了時にその旨を示すディスク診断完了通知をマスターＣＭに送信することになる指示である。
【００５８】
続くステップＳ２３７にて、マスターＣＭは、各担当ＲＬＵについてのマスター用ディスク診断処理を並行的に実行する。尚、このステップＳ２３７において、マスターＣＭは、１つ以上のスレーブ用ディスク診断処理を実行中の他の各スレーブＣＭからの依頼（状況値の変更依頼、保守端末３００のディスプレイ上へのメッセージの表示依頼；詳細は後述）を受信し、受信した依頼に応じる処理も行う。また、マスターＣＭは、スレーブＣＭからのディスク診断完了通知を受信する処理も行う。
【００５９】
以下、マスター用ディスク診断処理の内容、スレーブ用ディスク診断処理の内容を、この順に説明する。
【００６０】
ステップＳ２３７にて、マスターＣＭが各担当ＲＬＵについて実行するマスター用ディスク診断処理は、図７及び図８に示した手順の処理である。
【００６１】
すなわち、図７に示してあるように、或る担当ＲＬＵ（以下、処理対象ＲＬＵと表記する）に対するマスター用ディスク診断処理を開始したマスターＣＭは、まず、処理対象ＲＬＵの未処理ディスク中から、処理対象ディスクを選択する（ステップＳ３０１）。ここで、処理対象ＲＬＵの未処理ディスクとは、処理対象ＲＬＵの構成要素として使用されているディスクの中の、ステップＳ３０２以降の処理が未だ行われていないディスクのことである。
【００６２】
次いで、マスターＣＭは、処理対象ディスクへのＩ／Ｏを停止し、処理対象ディスクへのＩ／Ｏが停止されている間にデータが書き込まれた処理対象ＲＬＵの記憶領域を記憶しておくためのWrite Bitmapを作成（用意）する（ステップＳ３０２）。また、このステップＳ３０２にて、マスターＣＭは、処理対象ＲＬＵへのリード／ライト要求に対して、それまでとは異なった内容の処理を行う状態に移行する。具体的には、マスターＣＭは、『処理対象ディスク以外のディスクのみを利用して処理対象ＲＬＵへのリード／ライト要求に応答する状態であって、或る記憶領域へのライト要求に応答した際に、当該記憶領域に対応付けられている、Write Bitmapの幾つかのビットの値を書き換える状態』に移行する。
【００６３】
ステップＳ３０２の処理を終えたマスターＣＭは、処理対象ディスクを再起動する（ステップＳ３０３）。
【００６４】
その後、マスターＣＭは、処理対象ディスクが正常に起動したか否かを判断する（ステップＳ３０４）。具体的には、マスターＣＭは、処理対象ディスクから情報を取得することにより、処理対象ディスクのスピンドルモータが、再起動した時点から所定時間内に、正常に動作している状態となったか否かを判断する（ステップＳ３０４）。
【００６５】
処理対象ディスクが正常に起動した場合（ステップＳ３０４；ＹＥＳ）、マスターＣＭは、処理対象ディスクからのデータの読み出し等により、処理対象ディスクの各部（制御系、ヘッド駆動系等）の状態をチェックする（ステップＳ３０５）。
【００６６】
ステップＳ３０５のチェックにより異常箇所が検出されなかった場合（ステップＳ３０６；ＮＯ）、マスターＣＭは、Write Bitmapを参照して、処理対象ディスクの一部（処理対象ディスクがアクティブであった場合には、書込データの一部やパリティ等が書き込まれていた記憶領域群）をリビルドする（ステップＳ３０７）。
【００６７】
続くステップＳ３０８にて、マスターＣＭは、Write Bitmapを破棄すると共に、処理対象ＲＬＵに対して通常の制御を行う状態に移行する。
【００６８】
その後、マスターＣＭは、処理状況管理テーブル上の処理対象ディスクの状況値を「ＯＦＦ／ＯＮ済」に変更する（ステップＳ３０９）。そして、マスターＣＭは、処理対象ＲＬＵのディスクの中に未処理ディスクが残っているか否かを判断（ステップＳ３１０）し、未処理ディスクが残っていた場合（ステップＳ３１０；ＹＥＳ）には、ステップＳ３０１以降の処理を再度実行する。
【００６９】
これに対して、異常箇所が検出された場合（ステップＳ３０６；ＹＥＳ）、マスターＣＭは、Write Bitmapを破棄する（図８、ステップＳ３２０）。また、このステップＳ３２０において、マスターＣＭは、『処理対象ディスク以外のディスクのみを利用して処理対象ＲＬＵへのリード／ライト要求に応答する状態』（ライト要求に応答しても、Write Bitmapを更新しない状態）に移行する処理も行う。
【００７０】
次いで、マスターＣＭは、処理対象ディスクの交換（修理）をユーザに依頼するためのディスク交換依頼メッセージを保守端末３００のディスプレイ上に表示する（ステップＳ３２１）。また、マスターＣＭは、処理状況管理テーブル上の処理対象ディスクの状況値を「保守・交換待ち」に変更する（ステップＳ３２２）。
【００７１】
そして、マスターＣＭは、処理対象ディスクがユーザによって交換されるのを待機する（ステップＳ３２３）。このステップＳ３２３では、例えば、処理対象ディスクの交換完了が保守端末３００経由でユーザから通知されるのを監視（待機）する処理や、処理対象ディスクの交換完了を自動検出する処理が、行われる。
【００７２】
処理対象ディスクが交換された場合、マスターＣＭは、ステップＳ３２４にて、処理対象ディスクをリビルドする。
【００７３】
その後、マスターＣＭは、ステップＳ３０２（図７）以降の処理を実行することにより、交換後の処理対象ディスクが、再起動しても（電源のＯＦＦ／ＯＮをおこなっても）問題が生じないものであるか否かをチェックする。
【００７４】
マスターＣＭは、上記した内容／手順の処理を、未処理ディスクがなくなるまで繰り返す、そして、マスターＣＭは、未処理ディスクがなくなった場合（ステップＳ３１０；ＮＯ）に、このディスク診断処理を終了する。
【００７５】
次に、ディスク診断処理開始指示（図５のステップＳ２３６参照）を受信したスレーブＣＭが各担当ＲＬＵについて実行するスレーブ用ディスク診断処理の内容を説明する。
【００７６】
スレーブＣＭが実行するスレーブ用ディスク診断処理は、マスターＣＭが実行するマスター用ディスク診断処理（図７及び図８）と、ステップＳ３０９、Ｓ３２１、Ｓ３２２の処理内容のみが異なる処理となっている。
【００７７】
具体的には、スレーブ用ディスク診断処理のステップＳ３０９では、『処理状況管理テーブル上の処理対象ディスクの状況値を「ＯＦＦ／ＯＮ済」に変更する処理』ではなく、『処理状況管理テーブル上の処理対象ディスクの状況値の「ＯＦＦ／ＯＮ済」への変更をマスターＣＭに依頼する処理』が行われる。また、スレーブ用ディスク診断処理のステップＳ３２１では、『ディスク交換依頼メッセージを保守端末３００のディスプレイ上に表示する処理』ではなく、『ディスク交換依頼メッセージの保守端末３００のディスプレイ上への表示をマスターＣＭに依頼する処理』が行われる。同様に、スレーブ用ディスク診断処理のステップＳ３２２では、『処理状況管理テーブル上の処理対象ディスクの状況値を「保守・交換待ち」に変更する処理』ではなく、『処理状況管理テーブル上の処理対象ディスクの状況値の「保守・交換待ち」への変更をマスターＣＭに依頼する処理』が行われる。
【００７８】
図５に戻って、潜在障害検出復旧処理の説明を続ける。
【００７９】
既に説明したように、ディスク診断処理開始指示を受信したスレーブＣＭは、各担当ＲＬＵについてのスレーブ用ディスク診断処理が全て完了した時にその旨を示すディスク診断完了通知をマスターＣＭに送信する。
【００８０】
ステップＳ２３７の処理（各担当ＲＬＵについてのスレーブ用ディスク診断処理）を終えたマスターＣＭは、全てのスレーブＣＭからのディスク診断完了通知を受信しているか否かを判断する（ステップＳ２３８）。
【００８１】
マスターＣＭは、ディスク診断完了通知を受信していない幾つかのスレーブＣＭが存在していた場合には、各スレーブＣＭからディスク診断完了通知が送信されてくるのを待機する（ステップＳ２３８；ＮＯ）。
【００８２】
全スレーブＣＭからのディスク診断完了通知の受信が完了した場合（ステップＳ２３８；ＹＥＳ）、マスターＣＭは、保守端末３００のディスプレイ上に潜在障害検出復旧処理が完了した旨の処理完了メッセージを表示する（ステップＳ２３９）。そして、マスターＣＭは、この潜在障害検出復旧処理を終了する。
【００８３】
図２に戻って、潜在障害検出復旧処理の開始前に行われる処理（計画停止準備処理のステップＳ１０１〜Ｓ１０４の処理）の内容を説明する。
【００８４】
既に説明したように、マスターＣＭは、計画停止日時の指定を含む、計画停止準備処理の開始指示をユーザが出したときに、この計画停止準備処理（図２）を開始する。
【００８５】
図２に示してあるように、計画停止準備処理を開始したマスターＣＭは、まず、情報処理装置１００の構成情報等に基づき、潜在障害検出復旧処理の最悪実行時間を算出（推定
）する（ステップＳ１０１）。ここで、情報処理装置１００の構成情報とは、マスターＣＭが管理している、情報処理装置１００内のＣＭ１０の数（以下、ＣＭ総数と表記する）、各ＲＬＵを構成しているディスクの台数、各ＲＬＵを構成している各ディスクの容量等からなる情報のことである。
【００８６】
ステップＳ１０１における潜在障害検出復旧処理の最悪実行時間の算出手順としては、さまざまなものを採用することが出来る。例えば、潜在障害検出復旧処理の最悪実行時間の算出手順として、以下の手順を採用することが出来る。
【００８７】
まず、構成情報中のＣＭ総数と、予め設定されているＣＭ１０の交換に要する時間とから、全てのＣＭ１０の交換が必要であった場合に、潜在障害検出復旧処理の開始後、ステップＳ２３５（図５）で“ＮＯ”側への分岐がなされるまでに要する時間（以下、ＣＭチェック時間と表記する）を算出する。次いで、構成情報中の各ＲＬＵに関する情報と、予め設定されている各容量のディスクのリビルドに要する時間とから、ＲＬＵ毎に、全ディスクの交換が必要であった場合にそのＲＬＵに対するディスク診断処理の完了に要する時間を算出する。そして、各ＲＬＵについて算出した時間の中の最大値と、ＣＭチェック時間とを加算することにより、潜在障害検出復旧処理の最悪実行時間を算出する。
【００８８】
ステップＳ１０１の処理を終えたマスターＣＭは、算出した最悪実行時間と既定時間（詳細は後述）とを計画停止日時から減ずることにより、潜在障害検出復旧処理の開始日時（以下、処理開始日時とも表記する）を算出する（ステップＳ１０２）。
【００８９】
次いで、マスターＣＭは、処理開始日時になるのを待機する（ステップＳ１０３）。そして、マスターＣＭは、処理開始日時になった場合（ステップＳ１０３；ＹＥＳ）には、ステップＳ１０４にて、まず、処理開始日時になった旨のメッセージを保守端末３００のディスプレイ上へ表示する。次いで、マスターＣＭは、潜在障害検出復旧処理の開始指示がユーザにより入力されるのを待機する。そして、マスターＣＭは、潜在障害検出復旧処理の開始指示が入力されたことを検出した際に、ステップＳ１０４の処理を終了する。
【００９０】
上記した既定時間は、処理開始日時になった旨のメッセージを保守端末３００のディスプレイ上へ表示した直後にユーザが当該メッセージに気づくとは限らないこと（及び、潜在障害検出復旧処理時にユーザによるデバイスの交換が必要とされる場合があること）を考慮して、計画停止日時から減じている時間である。従って、既定時間としては、保守端末３００の設置環境等に基づき定められた『処理開始日時になった旨のメッセージを保守端末３００のディスプレイ上へ表示してから、潜在障害検出復旧処理の開始指示がユーザにより入力されることが確実な時間』が使用される。
【００９１】
そして、ステップＳ１０４の処理を終えたマスターＣＭは、続くステップＳ１０５にて、上記した内容の潜在障害検出復旧処理を実行する。
【００９２】
要するに、計画停止準備処理のステップＳ１０１〜Ｓ１０４の処理は、多数のデバイスの交換が必要となっても潜在障害検出復旧処理が計画停止日時以前に完了するタイミングで、ユーザに潜在障害検出復旧処理を開始させるための処理となっている。そして、潜在障害検出復旧処理は、情報処理装置１００の状態をホスト２００からの任意のリード／ライト要求に応答できる状態に維持しながら、デバイス毎の再起動により各デバイスの潜在的な障害の顕在化を図り、障害が顕在化したデバイスについては、その交換等をユーザに行わせる処理となっている。
【００９３】
従って、上記内容の計画停止準備処理を実行できる本情報処理装置１００は、計画停止後の再起動時に、幾つかのデバイスの潜在的な障害が顕在化して運用再開スケジュールに
支障をきたすことを防止できる装置となっていると言うことが出来る。
【００９４】
《変形形態》
上記した実施形態に係る情報処理装置１００は、各種の変形を行えるものである。例えば、情報処理装置１００を、ＣＭ１０が２台ずつペアを成していない装置（第１ＣＭの故障時に第２ＣＭが第１ＣＭの処理を引き継ぎ、第２ＣＭの故障時に第３ＣＭが第２ＣＭの処理を引き継ぐ装置等）に変形することが出来る。また、情報処理装置１００を、ＣＭ１０の再起動時に特殊な診断が行われな装置（各ＣＭ１０が診断モードで再起動されない装置）に変形することも出来る。
【００９５】
情報処理装置１００を、ステップＳ１０１〜Ｓ１０４の処理の実行機能を有さない装置（ユーザが、潜在障害検出復旧処理の開始タイミングを決定して潜在障害検出復旧処理を開始させる装置）に変形することも出来る。さらに、情報処理装置１００を、再起動による各デバイスのチェックを、１デバイスずつ定期的に行う装置（例えば、１日毎に、チェック対象を変えながら１デバイスのチェックを行う装置）に変形することも出来る。また、故障したＣＭ１０／ディスクは、通常、新品のＣＭ１０／ディスク（つまり、再起動により障害が顕在化することが殆どないデバイス）に交換される。そのため、情報処理装置１００を、交換されたＣＭ１０／ディスクについては、再起動によるチェックを行わないもの（交換されたＣＭ１０／ディスクについては、状況値の「ＯＦＦ／ＯＮ済」への書き換えのみを行うもの）に変形することも出来る。
【００９６】
潜在障害検出復旧処理と同様の内容の処理が、保守端末３００主導で行われるように（保守端末３００が、情報処理装置１００内のＣＭ１０に対して、再起動や、ＲＬＵの再起動を指示するように）、情報処理装置１００及び保守端末３００を構成することも出来る。
【００９７】
また、上記技術を、制御系が冗長構成となっていないストレージシステムや、ストレージシステム以外の、冗長構成を有する装置／システムに適用しても良いことは、当然のことである。
【００９８】
以上開示した技術に関し、更に以下の付記を開示する。
【００９９】
（付記１）  情報処理を実行する複数の処理ユニットであって、該複数の処理ユニットのうちのいずれかの処理ユニットが動作を停止しても前記情報処理を続行可能な複数の処理ユニットと、
前記複数の処理ユニットを１つずつ順々に再起動し、再起動しなかった処理ユニットについて交換又は修理を依頼する情報を出力する処理を実行可能な制御部と
を備えることを特徴とする情報処理装置。
【０１００】
（付記２）  前記複数の処理ユニットが、冗長性を有するディスクアレイ装置の構成要素として使用されている複数のディスクドライブである
ことを特徴とする付記１に記載の情報処理装置。
【０１０１】
（付記３）  前記潜在障害検出処理が、
再起動しなかったディスクドライブと再起動したが障害の存在が検出されたディスクドライブとについて、前記情報を出力する処理である
ことを特徴とする付記１又は２に記載の情報処理装置。
【０１０２】
（付記４）  前記潜在障害検出処理が、交換又は修理をユーザに依頼したディスクドライブが交換されるまでの間、中断する処理であり、
前記制御部は、
ユーザにより入力された前記情報処理装置の停止予定日時と、前記ディスクアレイ装置を構成しているディスクドライブの台数と、１台のディスクドライブの交換に要する時間とから、前記ディスクアレイ装置の全てのディスクドライブを交換しても前記潜在障害検出処理が前記停止予定日時以前に完了する日時を算出し、
算出した日時以前にユーザに前記潜在障害検出処理の開始指示の入力を促し、
前記開始指示が入力されたときに、前記潜在障害検出処理を開始する
ことを特徴とする付記１から３のいずれか一項に記載の情報処理装置。
【０１０３】
（付記５）  情報処理を実行する複数の処理ユニットであって、該複数の処理ユニットのうちのいずれかの処理ユニットが動作を停止しても前記情報処理を続行可能な複数の処理ユニットを含む情報処理装置において、
前記複数の処理ユニットの１つとして、
前記複数の処理ユニットを１つずつ順々に再起動し、再起動しなかった処理ユニット毎にその交換又は修理を依頼する情報を出力する潜在障害検出処理を実行可能なマスター処理ユニットを備える
ことを特徴とする情報処理装置。
【０１０４】
（付記６）  前記潜在障害検出処理が、
再起動しなかった処理ユニットと再起動したが障害の存在が検出された処理ユニットとについて、前記交換依頼情報を出力する処理である
ことを特徴とする付記５に記載の情報処理装置。
【０１０５】
（付記７）  前記潜在障害検出処理が、交換又は修理をユーザに依頼した処理ユニットが交換されるまでの間、中断する処理であり、
前記マスター処理ユニットは、
ユーザにより入力された前記情報処理装置の停止予定日時と、前記複数の処理ユニットの数と、１つの処理ユニットの交換に要する時間とから、前記情報処理装置の全ての処理ユニットを交換しても前記潜在障害検出処理が前記停止予定日時以前に完了する日時を算出し、
算出した日時以前にユーザに前記潜在障害検出処理の開始指示の入力を促し、
前記開始指示が入力されたときに、前記潜在障害検出処理を開始する
ことを特徴とする付記５又は６に記載の情報処理装置。
【０１０６】
（付記８）  複数の、冗長性を有するディスクアレイ装置と、
前記複数のディスクアレイ装置のそれぞれに対して、そのディスクアレイ装置を構成している複数のディスクドライブを１つずつ順々に再起動し、再起動しなかったディスクドライブ毎にその交換又は修理をユーザに依頼するための交換依頼情報を出力する潜在障害検出処理を並行的に実行可能な制御部と、
を備えることを特徴とする情報処理装置。
【０１０７】
（付記９）  情報処理を実行する複数の処理ユニットであって、該複数の処理ユニットのうちのいずれかの処理ユニットが動作を停止しても前記情報処理を続行可能な複数の処理ユニットを含む情報処理装置の保守方法において
コンピュータが、
前記複数の処理ユニットを１つずつ順々に再起動し、
再起動しなかった処理ユニット毎にその交換又は修理を依頼する情報を出力する
ことを特徴とする情報処理装置の保守方法。
【符号の説明】
【０１０８】
１０  ＣＭ
１１  ＣＡ
１２  通信インタフェース
１３  ＣＰＵ
１４  ＤＩ
１５  キャッシュメモリ
２０  ＤＥ
３０  バス
１００  情報処理装置
２００  ホスト
３００  保守端末
【図１】
0005874467.tif 000002
【図２】
0005874467.tif 000003
【図３】
0005874467.tif 000004
【図４】
0005874467.tif 000005
【図５】
0005874467.tif 000006
【図６】
0005874467.tif 000007
【図７】
0005874467.tif 000008
【図８】
0005874467.tif 000009