(57)【特許請求の範囲】
【請求項１】
上位装置からのＩ／Ｏ要求に対して下位装置に対するＩ／Ｏ処理を実行する制御装置であって，
前記上位装置から要求されたＩ／Ｏを処理する複数のプロセッサと，
メモリに格納された前記各プロセッサを動作させるための複数のファームウェアと，
前記上位装置からのＩ／Ｏ要求をどのプロセッサに振り分けるかを定める振り分け制御情報を記憶するＩ／Ｏ制御情報記憶手段と，
前記各プロセッサごとに，前記上位装置からのＩ／Ｏ要求を受け付けて処理対象となっている入出力先アドレス情報を含むＩ／Ｏ処理命令を，そのＩ／Ｏ処理が完了するまで保持するＩ／Ｏ処理命令保持手段と，
前記プロセッサと前記ファームウェアとにより現在のファームウェアの改版を制御する制御手段とを備え，
前記制御手段は，外部からのファームウェアの改版指示に対し，前記Ｉ／Ｏ制御情報記憶手段における前記振り分け制御情報を，ファームウェア改版の対象となったプロセッサへのＩ／Ｏ要求の振り分けを禁止する状態に更新し，前記Ｉ／Ｏ処理命令保持手段が保持するＩ／Ｏ処理命令がなくなったことを確認して，ファームウェアの改版を実行する制御を行い，
ファームウェアの改版対象となっていないプロセッサは，ファームウェアの改版時におけるＩ／Ｏチェック開始依頼の通知に対し，前記Ｉ／Ｏ処理命令保持手段が保持するＩ／Ｏ処理命令を参照して，自プロセッサが処理しようとするＩ／Ｏと入出力先アドレス情報が同一のＩ／Ｏ処理命令で，かつ前記ファームウェアの改版対象となったプロセッサが未処理のＩ／Ｏ処理命令がないかをチェックし，同一入出力先アドレスに対するＩ／Ｏの順序性を保証する処理を，Ｉ／Ｏチェック終了依頼の通知があるまで行う
ことを特徴とする制御装置。
【請求項２】
上位装置からのＩ／Ｏ要求に対して下位装置に対するＩ／Ｏ処理を実行する制御装置であって，
前記上位装置から要求されたＩ／Ｏを処理する複数のプロセッサと，
メモリに格納された前記各プロセッサを動作させるための複数のファームウェアと，
前記上位装置からのＩ／Ｏ要求をどのプロセッサに振り分けるかを定める振り分け制御情報を記憶するＩ／Ｏ制御情報記憶手段と，
前記各プロセッサごとに，前記上位装置からのＩ／Ｏ要求を受け付けて処理対象となっている入出力先アドレス情報を含むＩ／Ｏ処理命令を，そのＩ／Ｏ処理が完了するまで保持するＩ／Ｏ処理命令保持手段と，
前記プロセッサと前記ファームウェアとにより現在のファームウェアの改版を制御する制御手段とを備え，
前記制御手段は，外部からのファームウェアの改版指示に対し，前記Ｉ／Ｏ制御情報記憶手段における前記振り分け制御情報を，ファームウェア改版の対象となったプロセッサへのＩ／Ｏ要求の振り分けを禁止する状態に更新し，ファームウェアの改版を実行する制御を行い，かつ，ファームウェア改版の対象となったプロセッサの前記Ｉ／Ｏ処理命令保持手段がＩ／Ｏ処理命令を保持するときに，他のプロセッサに対してそのＩ／Ｏ処理命令を引き継がせるための割込み通知を行い，
前記他のプロセッサは，ファームウェアの改版時におけるＩ／Ｏチェック開始依頼の通知に対し，自プロセッサが処理しようとするＩ／Ｏと入出力先アドレス情報が同一のＩ／Ｏ処理命令で，かつ前記ファームウェアの改版対象となったプロセッサが未処理のＩ／Ｏ処理命令がないかをチェックし，同一入出力先アドレスに対するＩ／Ｏの順序性を保証する処理を，Ｉ／Ｏチェック終了依頼の通知があるまで行う
ことを特徴とする制御装置。
【請求項３】
請求項２記載の制御装置において，
さらに前記制御手段は，前記複数のプロセッサのうちの一つのプロセッサがダウンした場合に，前記Ｉ／Ｏ制御情報記憶手段における前記振り分け制御情報を，そのダウンしたプロセッサへのＩ／Ｏ要求の振り分けを禁止する状態に更新し，かつ，そのダウンしたプロセッサの前記Ｉ／Ｏ処理命令保持手段がＩ／Ｏ処理命令を保持するときに，他のプロセッサに対してそのＩ／Ｏ処理命令を引き継がせるための割込み通知を行う
ことを特徴とする制御装置。
【請求項４】
上位装置から要求されたＩ／Ｏを処理する複数のプロセッサと，メモリに格納された前記各プロセッサを動作させるための複数のファームウェアと，前記上位装置からのＩ／Ｏ要求をどのプロセッサに振り分けるかを定める振り分け制御情報を記憶するＩ／Ｏ制御情報記憶手段と，前記各プロセッサごとに，前記上位装置からのＩ／Ｏ要求を受け付けて処理対象となっている入出力先アドレス情報を含むＩ／Ｏ処理命令を，そのＩ／Ｏ処理が完了するまで保持するＩ／Ｏ処理命令保持手段とを備え，上位装置からのＩ／Ｏ要求に対して下位装置に対するＩ／Ｏ処理を実行する制御装置におけるファームウェア活性交換制御方法であって，
外部からのファームウェアの改版指示に対し，前記Ｉ／Ｏ制御情報記憶手段における前記振り分け制御情報を，ファームウェア改版の対象となったプロセッサへのＩ／Ｏ要求の振り分けを禁止する状態に更新することにより，以降の上位装置からのＩ／Ｏ要求を他のプロセッサに担当させる過程と，
ファームウェアの改版対象となっていないプロセッサが，ファームウェアの改版時におけるＩ／Ｏチェック開始依頼の通知に対し，前記Ｉ／Ｏ処理命令保持手段が保持するＩ／Ｏ処理命令を参照して，自プロセッサが処理しようとするＩ／Ｏと入出力先アドレス情報が同一のＩ／Ｏ処理命令で，かつ前記ファームウェアの改版対象となったプロセッサが未処理のＩ／Ｏ処理命令がないかをチェックし，同一入出力先アドレスに対するＩ／Ｏの順序性を保証する処理を，Ｉ／Ｏチェック終了依頼の通知があるまで行う過程と，
前記Ｉ／Ｏ処理命令保持手段が保持するＩ／Ｏ処理命令がなくなったことを確認して，前記ファームウェアの改版対象となったプロセッサのファームウェアの改版を実行する過程とを有する
ことを特徴とする制御装置のファームウェア活性交換制御方法。
【請求項５】
上位装置から要求されたＩ／Ｏを処理する複数のプロセッサと，メモリに格納された前記各プロセッサを動作させるための複数のファームウェアと，前記上位装置からのＩ／Ｏ要求をどのプロセッサに振り分けるかを定める振り分け制御情報を記憶するＩ／Ｏ制御情報記憶手段と，前記各プロセッサごとに，前記上位装置からのＩ／Ｏ要求を受け付けて処理対象となっている入出力先アドレス情報を含むＩ／Ｏ処理命令を，そのＩ／Ｏ処理が完了するまで保持するＩ／Ｏ処理命令保持手段とを備え，上位装置からのＩ／Ｏ要求に対して下位装置に対するＩ／Ｏ処理を実行する制御装置におけるファームウェア活性交換制御方法であって，
外部からのファームウェアの改版指示に対し，前記Ｉ／Ｏ制御情報記憶手段における前記振り分け制御情報を，ファームウェア改版の対象となったプロセッサへのＩ／Ｏ要求の振り分けを禁止する状態に更新することにより，以降の上位装置からのＩ／Ｏ要求を他のプロセッサに担当させる過程と，
前記ファームウェアの改版対象となったプロセッサのファームウェアの改版を実行する過程と，
前記プロセッサの前記Ｉ／Ｏ処理命令保持手段がＩ／Ｏ処理命令を保持するときに，他のプロセッサに対してそのＩ／Ｏ処理命令を引き継がせるための割込み通知を行う過程と，
前記他のプロセッサが，ファームウェアの改版時におけるＩ／Ｏチェック開始依頼の通知に対し，自プロセッサが処理しようとするＩ／Ｏと入出力先アドレス情報が同一のＩ／Ｏ処理命令で，かつ前記ファームウェアの改版対象となったプロセッサが未処理のＩ／Ｏ処理命令がないかをチェックし，同一入出力先アドレスに対するＩ／Ｏの順序性を保証する処理を，Ｉ／Ｏチェック終了依頼の通知があるまで行う過程とを有する
ことを特徴とする制御装置のファームウェア活性交換制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，ディスク制御装置等の制御装置およびそのファームウェア活性交換制御方法に関し，特に上位装置からの入出力（Ｉ／Ｏ）要求の処理を継続した状態で，制御装置におけるコントローラファームウェアの交換を可能にした技術に関する。
【背景技術】
【０００２】
ディスクアレイ装置などのディスク制御装置は，上位装置であるホストプロセッサ（以下，ホストという）からのＩ／Ｏ要求を，ＣＰＵとそのＣＰＵが実行する命令群からなるファームウェアとによって処理し，下位装置であるディスク装置を制御している。ディスク制御装置の機能拡張やファームウェアのバグの修正が必要なときに，ファームウェアの改版が必要になるが，このときディスク制御装置をオフラインにして，ファームウェアを改版することができれば，比較的に容易にファームウェアを新しいものに交換することができる。
【０００３】
しかし，２４時間運用のシステムなど，ディスク制御装置をオフラインにすることができない環境では，ホストＩ／Ｏを閉塞させることなくファームウェアを改版する，いわゆる活性交換が必要になる。
【０００４】
従来のディスクアレイ装置におけるコントローラファームウェア活性交換方法について，以下に説明する。ディスクアレイ装置におけるコントローラファームウェアの活性交換では，ホストＩ／Ｏのパスを閉塞させることなく，ファームウェアの改版を行うために，従来，例えば以下の(1) 〜(3) に示す方法が行われていた。
【０００５】
(1) ディスクアレイ装置の対ホストインタフェースのリンクをＵＰしたままの状態で，ビジー応答することで，ホストにＩ／Ｏリクエストをリトライさせる。この間にファームウェア改版を行う。ホスト側でＩ／Ｏリトライタイムアウトを検出する前にファームウェア改版を完了させ，Ｉ／Ｏの送受信を継続する。
【０００６】
(2) ファームウェア改版中は，Ｉ／Ｏをバッファに蓄えておく。上記(1) の方法と同様にホストがＩ／Ｏレスポンスタイムアウトを検出する前に，ファームウェア改版を完了させ，その後にＩ／Ｏを処理し，レスポンスを返す。
【０００７】
(3) 上記(l) ，(2) のいずれかの方法でホストＩ／Ｏのパスを閉塞させることなくファームウェアを改版することができない環境にある場合には，オペレータが手動でパスを切り替え，パス接続がない状態のコントローラからファームウェアを改版することで，パスの閉塞を防止する。
【０００８】
なお，無停止保守を実現するための従来技術が記載された文献としては，下記の特許文献１がある。この特許文献１に記載された技術では，ディスク装置を制御する冗長構成の複数のディスクドライブ制御装置による無停止稼動，無停止保守を実現している。
【０００９】
特許文献１に記載された技術は，２台の制御装置での負荷分散機能を実現するものであり，ファームウェアを制御装置内にアップロードする場合，Ｉ／Ｏの送受信を主とする装置を切り替えて，片装置毎にファームウェアのアップロードを行う。システムとしては，ファームウェアをアップロードしていない制御装置がＩ／Ｏの送受信を行うため，上位装置から見かけ上，Ｉ／Ｏは継続しているように見える。しかし，ファームウェアのアップロードを行っている間，その制御装置はダウンし，まったくＩ／Ｏを受け付けることはない。
【特許文献１】特開２００５−１２２７６３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
前述した(1) 〜(3) の方法による従来装置のコントローラファームウェア活性交換においては，それぞれ以下のような問題が発生する。
【００１１】
［(l) の方法の問題点］
上記(l) の方法では，ホスト側のＩ／Ｏリトライタイムアウト時間以内にファームウェアの改版が完了して，見かけ上Ｉ／Ｏが継続しているように見える。しかし，ファームウェア改版中は，ビジー応答によりＩ／Ｏを処理することができず，その分のＩ／Ｏが滞留していることになる。また，ホスト側のＩ／Ｏリトライタイムアウト時間は，システム要求により異なるため，システムによってはホスト側でタイムアウトを検出する場合がある。
【００１２】
［(2) の方法の問題点］
上記(2) の方法では，ディスク制御装置内のバッファに限りがあるため，バッファフルが発生するとＩ／Ｏをロストすることになる。また，上記(1) の方法と同様の問題がある。
【００１３】
［(3) の方法の問題点］
上記(3) の方法を用いた場合，オペレータが行うと手間がかかり，また人為的ミスを伴う。
【００１４】
また，上記特許文献１の技術では，特にファームウェアのアップロードを行っている間，その制御装置はダウンし，まったくＩ／Ｏを受け付けることはないが，ファームウェアのアップロード中でも，制御装置そのものがダウンしないで，Ｉ／Ｏを受け付けることができることが望まれる。
【００１５】
本発明は上記問題点の解決を図り，特にマルチＣＰＵおよびＩ／Ｏ制御テーブルを用いて，上位装置からのＩ／Ｏパス切替えおよび上位装置に対するビジー応答を不要とし，Ｉ／Ｏ処理の遅延を抑え，継続してＩ／Ｏに関する送受信を可能としたディスク等の制御装置におけるコントローラファームウェア活性交換を実現することを目的とする。
【課題を解決するための手段】
【００１６】
上記課題を解決するため，第１の発明は，ホスト（上位装置）からのＩ／Ｏ要求に対して下位装置に対するＩ／Ｏ処理を実行する制御装置であって，ホストから要求されたＩ／Ｏを処理する複数のプロセッサ（ＣＰＵ）と，メモリに格納された各プロセッサを動作させるための複数のファームウェアと，ホストからのＩ／Ｏ要求をどのプロセッサに振り分けるかを定める振り分け制御情報を記憶するＩ／Ｏ制御テーブルと，各プロセッサごとに，ホストからのＩ／Ｏ要求を受け付けて処理対象となっている入出力先アドレス情報を含むＩ／Ｏ処理命令を，そのＩ／Ｏ処理が完了するまで保持するＩ／Ｏ処理命令リストと，プロセッサとファームウェアとにより現在のファームウェアの改版を制御する制御手段とを備え，前記制御手段は，外部からのファームウェアの改版指示に対し，Ｉ／Ｏ制御テーブルにおける振り分け制御情報を，ファームウェア改版の対象となったプロセッサへのＩ／Ｏ要求の振り分けを禁止する状態に更新し，Ｉ／Ｏ処理命令リストが保持するＩ／Ｏ処理命令がなくなったことを確認して，ファームウェアの改版を実行する制御を行い，ファームウェアの改版対象となっていないプロセッサは，ファームウェアの改版時におけるＩ／Ｏチェック開始依頼の通知に対し，前記Ｉ／Ｏ処理命令リストが保持するＩ／Ｏ処理命令を参照して，自プロセッサが処理しようとするＩ／Ｏと入出力先アドレス情報が同一のＩ／Ｏ処理命令で，かつ前記ファームウェアの改版対象となったプロセッサが未処理のＩ／Ｏ処理命令がないかをチェックし，同一入出力先アドレスに対するＩ／Ｏの順序性を保証する処理を，Ｉ／Ｏチェック終了依頼の通知があるまで行うことを特徴とする。
【００１７】
第１の発明によれば，Ｉ／Ｏ制御テーブルを用いることにより，ファームウェア改版時にホストからのＩ／Ｏ要求を自動的に他のプロセッサに振り分け，ホストへの影響を最小限にしてファームウェアを改版することができる。また，入出力先アドレス情報を含むＩ／Ｏ処理命令を保持するＩ／Ｏ処理命令リストによって，受け付け済みの全てのＩ／Ｏ処理を完遂させることができるとともに，同一入出力先アドレスへのＩ／Ｏの順序性の矛盾が生じないようにすることができる。
【００１８】
また，第２の発明は，ホストからのＩ／Ｏ要求に対して下位装置に対するＩ／Ｏ処理を実行する制御装置であって，ホストから要求されたＩ／Ｏを処理する複数のプロセッサと，メモリに格納された各プロセッサを動作させるための複数のファームウェアと，ホストからのＩ／Ｏ要求をどのプロセッサに振り分けるかを定める振り分け制御情報を記憶するＩ／Ｏ制御テーブルと，各プロセッサごとに，ホストからのＩ／Ｏ要求を受け付けて処理対象となっている入出力先アドレス情報を含むＩ／Ｏ処理命令を，そのＩ／Ｏ処理が完了するまで保持するＩ／Ｏ処理命令リストと，プロセッサとファームウェアとにより現在のファームウェアの改版を制御する制御手段とを備え，前記制御手段は，外部からのファームウェアの改版指示に対し，Ｉ／Ｏ制御テーブルにおける振り分け制御情報を，ファームウェア改版の対象となったプロセッサへのＩ／Ｏ要求の振り分けを禁止する状態に更新し，ファームウェアの改版を実行する制御を行い，かつ，ファームウェア改版の対象となったプロセッサのＩ／Ｏ処理命令リストがＩ／Ｏ処理命令を保持するときに，他のプロセッサに対してそのＩ／Ｏ処理命令を引き継がせるための割込み通知を行い，前記他のプロセッサは，ファームウェアの改版時におけるＩ／Ｏチェック開始依頼の通知に対し，自プロセッサが処理しようとするＩ／Ｏと入出力先アドレス情報が同一のＩ／Ｏ処理命令で，かつ前記ファームウェアの改版対象となったプロセッサが未処理のＩ／Ｏ処理命令がないかをチェックし，同一入出力先アドレスに対するＩ／Ｏの順序性を保証する処理を，Ｉ／Ｏチェック終了依頼の通知があるまで行うことを特徴とする。
【００１９】
第２の発明によれば，Ｉ／Ｏ処理命令リストが保持する完遂前のＩ／Ｏ処理命令を，他のプロセッサに引き継がせる機構を持つので，第１の発明の効果に加えて，ファームウェアの改版を，外部から改版依頼があったときに即時に実行できるという効果がある。
【００２０】
また，第３の発明は，上記第２の発明において，前記制御手段は，複数のプロセッサのうちの一つのプロセッサがダウンした場合に，Ｉ／Ｏ制御テーブルにおける振り分け制御情報を，そのダウンしたプロセッサへのＩ／Ｏ要求の振り分けを禁止する状態に更新し，かつ，そのダウンしたプロセッサのＩ／Ｏ処理命令リストがＩ／Ｏ処理命令を保持するときに，他のプロセッサに対してそのＩ／Ｏ処理命令を引き継がせるための割込み通知を行うことを特徴とする。
【００２１】
第３の発明によれば，ファームウェアの改版のための制御手段を利用し，ダウンしたプロセッサが処理中のＩ／Ｏ処理命令を他のプロセッサに引き継がせることができるので，プロセッサのダウン時にも，ホストへの影響を少なくすることができる。
【発明の効果】
【００２２】
本発明によれば，上位装置からのＩ／Ｏパス切替えを不要とするとともに，上位装置に対するビジー応答を不要とし，Ｉ／Ｏ処理の遅延を抑え，継続してＩ／Ｏの送受信が可能な，ディスク等の制御装置におけるコントローラファームウェアの活性交換を実現することができる。
【発明を実施するための最良の形態】
【００２３】
以下，本発明の一実施形態を図面を用いて説明する。図１は，本発明に係るディスク制御装置の構成例を示す。ディスク制御装置１は，上位装置であるホスト２と下位装置であるディスク装置３との間で入出力（Ｉ／Ｏ）の制御を行う。また，ディスク制御装置１は，ファームウェアを改版する場合に，ファームウェアをアップロード（以下，ファームウェアＵＰという）する保守用端末４に接続される。
【００２４】
ホスト２からのＩ／Ｏは，ホスト２とのインタフェースとなるチャネルアダプタ（ＣＡ：Channel Adaptor ）１１０，１１１で受信され，Ｉ／Ｏを制御するＩ／Ｏ制御部１２に渡される。Ｉ／Ｏ制御部１２ではＩ／Ｏを解析し，ディスク装置３にアクセスする場合には，ディスク装置３とのインタフェースであるドライブインタフェース（ＤＩ：Drive Interface ）１５０，１５１を経由し，アクセスが行われる。
【００２５】
ここで，Ｉ／Ｏ制御部１２には，ＣＰＵが複数あり，それぞれのＣＰＵ１３０，１３１でＩ／Ｏ制御を行うためのファームウェア１４０，１４１が動作する。ファームウェア１４０，１４１は，ディスク制御装置１のメモリ上に存在し，そのアーカイブは，フラッシュメモリ等で構成される展開前ファームウェア格納部１９に保存され，装置ブート時，すなわち装置への電源投入時や装置リセット時にメモリ上に展開される。
【００２６】
また，ディスク制御装置１のメモリには，Ｉ／Ｏ制御テーブル１６０等の各制御部で共有する情報を格納する共有情報域が設けられている。Ｉ／Ｏ制御部１２の他に各制御部を監視する監視制御部１８，正常時には動作しないが，ファームウェア改版時や異常時にＩ／Ｏを別のＣＰＵ（ファームウェア）に処理させるための割込みを制御するＩ／Ｏ処理再割込み制御部１７がある。
【００２７】
ディスク制御装置１においてファームウェア改版を行う場合，その改版処理が完了するまでファームウェアはＩ／Ｏを処理することができない。本実施の形態による制御方法は，Ｉ／Ｏ制御を片方のＣＰＵ（ファームウェア）に片寄せして，ＣＰＵ単位に順次ファームウェア改版を行う。上述したような従来技術の問題を解決するため，Ｉ／Ｏ制御させるＣＰＵ（ファームウェア）を一つではなく複数とし，Ｉ／Ｏを制御するＣＰＵ（ファームウェア）の情報を載せたＩ／Ｏ制御テーブル１６０を利用する。本制御方法は，このＩ／Ｏ制御テーブル１６０を動的に変更してファームウェアの改版を行うことにより，Ｉ／Ｏの停止／遅延を生じさせることなく，またホスト２側からのパス切替えを行わない方法を用いることを特徴とする。その詳細を次に述べる。
【００２８】
以下，説明をわかりやすくするために，ＣＰＵ１３０をＣＰＵ＃０，ＣＰＵ１３１をＣＰＵ＃１と表し，ＣＰＵ＃０側のファームウェア１４０をファームウェア＃０，ＣＰＵ＃１側のファームウェア１４１をファームウェア＃１と表す。
【００２９】
図２は，ファームウェア改版前のディスク制御装置１の状態を示している。また，図３は，ディスク制御装置１内のメモリ１０と展開前ファームウェア格納部１９の状態を示している。
【００３０】
図３に示すように，メモリ１０上には，ＣＰＵ＃０で動作しているファームウェア＃０，ＣＰＵ＃１で動作しているファームウェア＃１，および制御情報を保持している共有情報域１６がある。ここで共有情報域１６には，ホスト２からのＩ／ＯをどのＣＰＵ（ファーム）が制御するかを示すＩ／Ｏ制御テーブル１６０が存在する。Ｉ／Ｏ制御を担当するＣＰＵは複数存在し，例えば一つのＣＰＵ（ファームウェア）がダウンしたときに，Ｉ／Ｏを一度停止させて装置の制御情報などを新たに構築するようなことを行わなくても，動作を継続することができるようになっている。また，このＩ／Ｏ制御テーブル１６０でＩ／Ｏ制御させるＣＰＵをロードバランスさせることも可能である。
【００３１】
通常状態のときには，ホスト２からのＩ／Ｏを受信したチャネルアダプタ１１０または１１１が，Ｉ／Ｏ制御テーブル１６０をもとにＩ／Ｏを担当する各ＣＰＵ（ファームウェア）に割り込みを上げ，Ｉ／Ｏを制御させる仕組みをとる。図２の例では，Ｉ／Ｏ制御テーブル１６０に示すように，ホスト２からのＩ／Ｏ＃０はＣＰＵ＃０（ファームウェア＃０）が制御し，ホスト２からのＩ／Ｏ＃１はＣＰＵ＃１（ファームウェア＃１）が制御するように設定されている。
【００３２】
ここでファームウェア改版指示を，保守用端末４などの外部から受信すると，図３に示すように，展開前ファームウェア格納部１９からメモリの空き領域に新ファームウェアを展開すると同時に，Ｉ／Ｏ制御テーブル１６０を更新する。Ｉ／Ｏ制御テーブル１６０の更新により，Ｉ／Ｏ制御を片方のＣＰＵ（ファームウェア）側に片寄せして，ファームウェア改版を行っていく。
【００３３】
次に，Ｉ／Ｏ制御のベースとなるＩ／Ｏ制御テーブル１６０について説明する。ホスト２からのＩ／ＯをどのＣＰＵが担当するかを決定するには，それぞれのＣＰＵ＃０，＃１が担当するディスク装置や論理ボリューム（以下，ＬＵＮと記す）が明確になっており，どのＬＵＮにアクセスするＩ／Ｏであるかを判別することで，担当するＣＰＵが決定される。この決定方法は，従来技術でも行われている方法である。
【００３４】
ここで，本実施の形態では，前述したようにＬＵＮを担当するＣＰＵ（ファームウェア）は一つではなく，Ｉ／Ｏを処理させる優先度を設け，複数存在させる。Ｉ／Ｏを制御する担当ＣＰＵ（ファームウェア）とその状態と優先度の情報を，Ｉ／Ｏ制御テーブル１６０に設定しておき，これをもとにＩ／Ｏの制御を行う。つまり，当該制御方法において，各ＣＰＵは担当するＬＵＮへのアクセスがあれば，いつでも動作できる状態にあるが，Ｉ／Ｏに対するＣＰＵへの割り込みは，通常全てＩ／Ｏ制御テーブル１６０の優先度をもとに行われるため，優先度が高いＣＰＵ（ファームウェア）が存在する場合，原則として優先度が低いＣＰＵ（ファームウェア）がその担当のＩ／Ｏを処理することはない。
【００３５】
これについて既存の従来装置との違いについて述べる。既存の装置では，あるＬＵＮを担当するＣＰＵは一意である。このため，Ｉ／Ｏを担当するＣＰＵを変更する場合は，一度ホストＩ／Ｏを一時停止し，システム内部の制御情報を再構築し，これが完了するとホストＩ／Ｏの処理を再開する。これに対し，本実施の形態による制御方法を用いることで，ホストＩ／Ｏを停止することなく，Ｉ／Ｏ制御テーブル１６０の変更により，すばやく担当するＣＰＵを切り替えることができる。
【００３６】
次に，本実施の形態による制御方法の仕組みについてさらに詳しく説明する。図４は，通常状態でのＩ／Ｏ制御方法を説明する図である。
【００３７】
まず，ホスト２からのＩ／Ｏを，ＣＡ（＃０）１１０またはＣＡ（＃１）１１１が受信すると，ＣＡはメモリ１０上の共有情報域１６に存在するＩ／Ｏ制御テーブル１６０から，そのＩ／Ｏを担当する優先度が高いＩ／Ｏ制御部１２のＣＰＵを割り出し，該当するＣＰＵ＃０またはＣＰＵ＃１へＩ／Ｏを処理するようにメッセージ（割り込み通知）を送信する。このメッセージ（割り込み通知）は，各々のＣＰＵのメッセージキュー５０，５１に蓄えられ，ファームウェア＃０，＃１によって処理される。
【００３８】
また，ＣＡ１１０またはＣＡ１１１は，Ｉ／Ｏ制御部１２にメッセージ（割り込み通知）を送信すると同時に，Ｉ／Ｏ処理命令（どのＬＵＮのどのアドレスにどのような情報をＲｅａｄ／Ｗｒｉｔｅするかという情報）をＩ／Ｏ処理命令リスト６０，６１に登録する。このリストもメモリ上の共有情報域１６に存在することとする。リスト内の命令は，Ｉ／Ｏ制御部１２のＣＰＵが処理を完全に完了した時点で削除される。通常状態，すなわち正常な稼動状態では，このリストのＩ／Ｏ処理命令を使用してＩ／Ｏ制御が行われることはない。
【００３９】
上記の状態で，ディスク制御装置１が，外部の保守用端末４からファームウェア改版指示を受信した際の動作を次に説明する。図５は，ファームウェア改版指示後のＩ／Ｏ制御方法を説明する図である。
【００４０】
ファームウェア改版指示があると，まず，Ｉ／Ｏを担当するＩ／Ｏ制御部１２のＣＰＵを切り替えるため，Ｉ／Ｏ制御テーブル１６０の変更を行う。この例では，ＣＰＵ＃０（ファームウェア＃０）側がファームウェア改版を行うため，図５に示すように，Ｉ／Ｏ制御テーブル１６０上のＣＰＵ＃０の状態を“Ａｃｔｉｖｅ”（稼動中）状態から“Ｐｅｎｄｉｎｇ”（保留）状態にし，また優先度を無効とする。ここでＩ／Ｏ＃０を制御する担当ＣＰＵは，ＣＰＵ＃１が最も優先度が高くなる。
【００４１】
これにより，Ｉ／Ｏ制御テーブル１６０の変更後は，ＣＡ１１０，１１１からファームウェア改版を行う側のＣＰＵであるＣＰＵ＃０には全くＩ／Ｏ処理を行うメッセージ（割り込み通知）が送信されなくなる。このため，ファーム改版指示後でもＩ／Ｏ制御を全く停止させることも遅延させることもなく処理を継続させることが可能となる。
【００４２】
ファームウェア改版を行う側のＣＰＵ＃０は，ファームウェア改版指示前（つまり，Ｉ／Ｏ制御テーブル１６０の変更前）に，自ＣＰＵに対して送信されたＩ／Ｏ処理は，全て完了させなければならない。これを全て完了させた後，ＣＰＵ＃０（ファームウェア＃０）のリセット等により，実際のファームウェア改版の動作を開始する。このため，ファームウェア改版処理は，改版指示前に受け付けたＩ／Ｏ処理が履けるまで，待機させる。
【００４３】
ここで，一つの問題が発生する。Ｉ／Ｏ制御テーブル１６０の変更後の過渡状態の際に，ファームウェア改版を行うＣＰＵ＃０で処理されるＩ／Ｏと同一ＬＵＮのブロックアドレス宛のＩ／Ｏのメッセージが，Ｉ／Ｏ制御テーブル１６０の更新により優先度が上がり，新たに実担当となったＣＰＵ＃１に対して送信された場合である。この場合，同一ブロックへのＩ／Ｏの順序性に矛盾が生じる可能性がある。
【００４４】
そこでこの問題を解決するため，ＣＰＵ＃１のファームウェア＃１は，Ｉ／Ｏ制御テーブル１６０の更新が行われた間際の過渡期の状態にあるＩ／Ｏのアクセス（もともとＣＰＵ＃０が担当していたＬＵＮへアクセスするＩ／Ｏのみでよい）について，ファームウェア改版を行う側のＣＰＵ＃０が処理中でないか，もしくは処理しようとしていないかをチェックし，Ｉ／Ｏを処理する。このチェックを行うために，ＣＡ１１０，１１１からＩ／Ｏ制御部１２へのメッセージ（割り込み通知）の送信と同時にＩ／Ｏ処理命令リスト（マッピング情報等でもよい）６０のチェックを行う。もし，このチェックにより処理可能であればＩ／Ｏ処理を続行し，処理不可（同一ＬＵＮのブロックアドレス宛のＩ／Ｏが存在する場合）であれば，先にＣＰＵ＃０に処理を最優先で行わせるようにメッセージを送信する。これにより，Ｉ／Ｏ処理の順序性を崩すことなく，また他のＩ／Ｏに影響を及ぼすことなく処理することができる。なお，ＣＰＵ＃０にメッセージを送信するのではなく，アクセス先のブロックが競合する後から発行されたＩ／Ｏ要求を，ＣＰＵ＃１のメッセージキュー５１に再キューイングするなどして，一時的に所定の時間待たせるようにしてもよい。
【００４５】
ＣＰＵ＃０のファームウェアの改版が完了したならば，Ｉ／Ｏ制御テーブル１６０を図４に示す元の状態に戻す。その後，同様にＣＰＵ＃１についての新ファームウェアの改版を実行すれば，ＣＰＵ＃０，ＣＰＵ＃１のファームウェア＃０，＃１は，共に新ファームウェアに改版されることになる。
【００４６】
上記の方法は，ファームウェア改版を行うＣＰＵがファームウェア改版指示受信前にキューイングされたＩ／Ｏ処理を全て完了してから，ファームウェア改版処理（リセット等）に入る方法であるが，本実施の形態に係るもう一つの制御方法は，ファームウェア改版指示受信後，即座にファームウェア改版動作に入ることも可能とする。この方法を使用することにより，ファームウェア改版時間の短縮ばかりではなく，ファームウェア障害等でファームウェアがダウンし，不意に片側のＣＰＵが使用できない状態に陥ったとしても，パスを閉塞させることなく処理を継続することができる。この制御方法について以下に述べる。
【００４７】
図６は，異常時もしくはファームウェア改版を即時実行する場合のＩ／Ｏ制御方法を説明する図である。ＣＰＵ＃０がダウンした場合（もしくは，キューイングされているＩ／Ｏを処理しないで，即時にファームウェア改版動作を開始する場合）の例を説明する。
【００４８】
ＣＰＵ＃０（ファームウェア＃０）に障害が発生しダウンすると，監視制御部１８がこれを検出する。その後，ＣＰＵ＃０が使用不可になったため，Ｉ／Ｏ制御テーブル１６０を更新する。図６では，ＣＰＵ＃０（ファームウェア＃０）の状態が“Ａｃｔｉｖｅ”（稼動中）状態から“Ｄｏｗｎ”（ダウン）状態に更新されている。これにより，以降ホスト２からのＩ／Ｏ＃０は，ダウンした側のＣＰＵ＃０に割り振られることはなく，ＣＰＵ＃１側に割り振られることになる。
【００４９】
次に，監視制御部１８は，ＣＰＵ＃０に割り振られたＩ／Ｏ処理命令を処理させるため，Ｉ／Ｏ処理再割込み制御部１７にダウンしたＣＰＵ＃０のＩ／Ｏを再処理させるよう依頼する。これを受信したＩ／Ｏ処理再割込み制御部１７は，ＣＰＵ＃０側のＩ／Ｏ処理命令リスト６０をチェックし，未処理／未完了のＩ／Ｏ処理の存在を確認後，この情報をもとにＩ／Ｏ処理をＣＰＵ＃１に行わせるため，メッセージ（割り込み通知）を作成し，送信する。これを受信したＣＰＵ＃１は，それらのＩ／Ｏ処理を行う。
【００５０】
ここでもまた，Ｉ／Ｏ処理の順序性が問題になる。しかし，先ほど述べた方法と同様な方法で，同一ＬＵＮのブロックアドレスへのアクセスであれば，再割込みが行われたＩ／Ｏ処理を優先させることで順序性矛盾が生じることを回避することができる。
【００５１】
図７は，図５のＩ／Ｏ制御方法を用いたときの処理シーケンスであって，ファームウェア改版を行うＣＰＵ＃０側が，既に受け付け済みのＩ／Ｏを全て処理するときのシーケンスの例を示している。
【００５２】
ＣＰＵ＃０がファームウェア改版依頼を受信すると（Ｓ１），ＣＰＵ＃１に対し，Ｉ／Ｏチェック開始依頼を行う。続いてＩ／Ｏ制御テーブル１６０を更新し，展開前ファームウェア格納部１９に格納された新ファームウェアを展開する（Ｓ２）。その後，自ＣＰＵ＃０のＩ／Ｏ処理の完了を，Ｉ／Ｏ処理命令リスト６０を見てチェックする（Ｓ３）。
【００５３】
一方，Ｉ／Ｏチェック開始依頼を受けたＣＰＵ＃１では，自ＣＰＵ＃１が処理するＩ／Ｏについて，ＣＰＵ＃０が処理中のＩ／Ｏと同一ＬＵＮのブロックアドレスへのアクセスかをチェックする処理を開始し（Ｓ４），もし同一ＬＵＮのブロックアドレスへのアクセスがあれば，ＣＰＵ＃０のＩ／Ｏ処理部へＩ／Ｏ優先処理を依頼し，ＣＰＵ＃０からの処理完了報告により，そのＩ／Ｏ処理を行う。このチェックをＣＰＵ＃０からＩ／Ｏチェック終了依頼がくるまで継続する。
【００５４】
ＣＰＵ＃０では，Ｉ／Ｏ処理命令リスト６０のチェックにより，全Ｉ／Ｏの処理完了を確認したならば，ＣＰＵ＃１に対しＩ／Ｏチェック終了依頼を送り，その後にリセット等によりファームウェア改版を開始する（Ｓ５）。すなわち，メモリ１０上に展開された新ファームウェアによる動作を開始する。
【００５５】
通常，ＣＰＵ＃０のファームウェア改版が正常に終了した後，続いてＣＰＵ＃１にファームウェア改版依頼が送信され，同様にＣＰＵ＃１についてもファームウェア改版処理が行われることになる。
【００５６】
図８は，図６のＩ／Ｏ制御方法を用いたときの処理シーケンスであって，ＣＰＵ＃０に異常が発生しダウンしたときのシーケンスの例を示している。ＣＰＵ＃０がファームウェア改版を即時に実行する場合のシーケンスも基本的に同様である。
【００５７】
監視制御部１８が，ＣＰＵ＃０のダウンを検出すると（Ｓ１０），ＣＰＵ＃１に対し，Ｉ／Ｏチェック開始依頼を行う。続いて，Ｉ／Ｏ制御テーブル１６０を更新し（Ｓ１１），Ｉ／Ｏ処理再割込み制御部１７に対し，再割込み処理開始依頼を行う。
【００５８】
Ｉ／Ｏチェック開始依頼を受けたＣＰＵ＃１では，自ＣＰＵ＃１が処理するＩ／Ｏについて，ＣＰＵ＃０で未処理のＩ／Ｏと同一ＬＵＮのブロックアドレスへのアクセスかをチェックする処理を開始し（Ｓ１２），もし同一ＬＵＮのブロックアドレスへのアクセスがあれば，そのＩ／Ｏ処理を一時的に保留する。
【００５９】
再割込み処理開始依頼を受けたＩ／Ｏ処理再割込み制御部１７では，ＣＰＵ＃０用のＩ／Ｏ処理命令リスト６０を参照し，未処理Ｉ／Ｏの存在を確認したならば，その制御のためにＣＰＵ＃１に対しＩ／Ｏ処理割込み通知を行う（Ｓ１３）。ＣＰＵ＃１では，この通知を受信し，ＣＰＵ＃０で未処理であったＩ／Ｏ処理を行う。Ｉ／Ｏ処理再割込み制御部１７は，ＣＰＵ＃０のＩ／Ｏ処理命令リスト６０がＮＵＬＬ（空）になるまで，同様に未処理Ｉ／Ｏの処理を行い，Ｉ／Ｏ処理命令リスト６０がＮＵＬＬ（空）であることを確認したならば，監視制御部１８に対し，再割込み処理終了を通知する（Ｓ１４）。その通知を受けた監視制御部１８は，Ｉ／Ｏチェック終了依頼をＣＰＵ＃１に送信して，ＣＰＵ＃０の未処理Ｉ／Ｏに関する処理を完了する。
【００６０】
なお，ＣＰＵ＃０のダウンではなく，ＣＰＵ＃０のファームウェア改版の場合には，Ｓ１１でＩ／Ｏ制御テーブル１６０を更新した後，直ちにファームウェア改版を開始できることになる。
【００６１】
以上の実施の形態では，ＣＰＵとファームウェアが二つ存在する場合の例を説明したが，これらが三以上であっても，本発明を用いて同様にＩ／Ｏの制御およびファームウェアの改版を行うことができることは説明するまでもなく明らかである。また，ディスク制御装置におけるファームウェア活性保守の例を説明したが，ディスク制御装置に限らず，同様な周辺装置の制御装置であれば，本発明によるファームウェア活性交換制御方法を同じように適用することができる。
【００６２】
また，上記実施の形態において，監視制御部１８およびＩ／Ｏ処理再割込み制御部１７を特定の一つのＣＰＵ（ファームウェア）に担当させる実施も可能である。この方法として，例えば複数のＣＰＵ（ファームウェア）の中で稼動中（Ａｃｔｉｖｅ）である一つのＣＰＵ（ファームウェア）を主制御のためのマスターとして選択し，監視制御部１８およびＩ／Ｏ処理再割込み制御部１７を，そのマスターとなるＣＰＵ（ファームウェア）によって実現する方法を用いる。この場合，マスターとなるＣＰＵ（ファームウェア）についてファームウェア改版を行う場合には，事前に他のＣＰＵ（ファームウェア）に対しマスターを移行する。マスターとなるＣＰＵ（ファームウェア）がダウンした場合にも，それを検出したときに，あらかじめ定められた他のＣＰＵ（ファームウェア）がマスターとなるようにマスターの切り替えを行う。
【図面の簡単な説明】
【００６３】
【図１】ディスク制御装置の構成例を示す図である。
【図２】ファームウェア改版前のディスク制御装置の状態を示す図である。
【図３】ディスク制御装置内のメモリと展開前ファームウェア格納部の状態を示す図である。
【図４】通常状態でのＩ／Ｏ制御方法を説明する図である。
【図５】ファームウェア改版指示後のＩ／Ｏ制御方法を説明する図である。
【図６】異常時もしくはファームウェア改版を即時実行する場合のＩ／Ｏ制御方法を説明する図である。
【図７】ファームウェア改版を行うＣＰＵ側がＩ／Ｏを全て処理するときのシーケンスの例を示す図である。
【図８】異常時もしくはファームウェア改版を即時実行する場合の処理シーケンスの例を示す図である。
【符号の説明】
【００６４】
１      ディスク制御装置
２      ホスト
３      ディスク装置
４      保守用端末
１０    メモリ
１１０，１１１  チャネルアダプタ（ＣＡ）
１２    Ｉ／Ｏ制御部
１３０，１３１  ＣＰＵ
１４０，１４１  ファームウェア
１５０，１５１  ドライブインタフェース（ＤＩ）
１６    共有情報域
１６０  Ｉ／Ｏ制御テーブル
１７    Ｉ／Ｏ処理再割込み制御部
１８    監視制御部
１９    展開前ファームウェア格納部
【図１】
0004456084.tif 000002
【図２】
0004456084.tif 000003
【図３】
0004456084.tif 000004
【図４】
0004456084.tif 000005
【図５】
0004456084.tif 000006
【図６】
0004456084.tif 000007
【図７】
0004456084.tif 000008
【図８】
0004456084.tif 000009