JP5532874B2

JP5532874B2 - 情報処理装置

Info

Publication number: JP5532874B2
Application number: JP2009274679A
Authority: JP
Inventors: 健一三木
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2009-12-02
Filing date: 2009-12-02
Publication date: 2014-06-25
Anticipated expiration: 2029-12-02
Also published as: JP2011118606A

Description

本発明は、２４時間３６５日業務を停止することができないミッションクリティカル環境において、ファームウェアを更新する情報処理装置及びその制御方法に関する。

従来、ホストコンピュータから送信されるデータのディスクに対する入出力制御を行うディスク制御装置のコントローラのファームウェアを更新した場合、更新後の新しいファームウェアで動作させるためにディスク制御装置の各コントローラのリブートが必要になる。

このため、ホストコンピュータ及びディスク制御装置間のアクセスパスがシングルパス構成の場合、ディスク制御装置の各コントローラのリブート中にはＩ／Ｏ要求を処理することができず、業務を停止しなければならない。

ファームウェアを更新する方法としては、図２１に示すように、Ｉ／Ｏ要求を発行するホストコンピュータ上にパス切替ドライバを導入し、さらにホストコンピュータ及びディスク制御装置の各コントローラ間を冗長パス構成とする方法がある。かかる構成では、ディスク制御装置の一方のコントローラのリブート時には、パス切替ドライバにて他方のコントローラがＩ／Ｏ要求を処理するようにアクセスパスを切り替えながら各コントローラのリブートを行うことで業務を停止することなくファームウェアの更新を行うことができる。

また、図２２に示すように、冗長コントローラ構成において、ホストインタフェース及びコントローラ間に他系コントローラへの切替機構を備え、ディスク制御装置の一方のコントローラのリブート時には、他方のコントローラがＩ／Ｏ要求を処理するように切り替えながら各コントローラのリブートを行うことにより、ファームウェアの更新を行う方法がある。

さらに、ファームウェアを更新する方法としては、特許文献１に開示されている方法がある。特許文献１の方法では、クラスタソフト／クラスタサービスを基本技術として、これに加えてハイパーバイザと１つ以上のゲストオペレーティングシステムとを実行する。ハイパーバイザは、ゲストオペレーティングシステムによる装置の使用を禁止した後に、装置内のファームウェアを、受信されたファームウェアを使用してアップグレードする。ハイパーバイザは、ファームウェアがアップグレードされた後に、ゲストオペレーティングシステムの各々に対して、装置の使用を許可する。

特開２００８−２４３１８３号公報

しかしながら、図２１に示すファームウェア更新方法では、各ホストコンピュータにパス切替ドライバの導入と、各ホストコンピュータ及びディスク制御装置間を冗長パス構成とするためのハードウェアが必要となり導入コストが高くなる。また、パス切替ドライバによるアクセスパスの切り替え操作はホストコンピュータでの操作となることから、システム管理者による作業が必要となり、ディスク制御装置の保守員のみでは作業することができないというデメリットがある。さらに、ディスク制御装置に接続しているホストコンピュータが多数存在する場合は、すべてのホストコンピュータでのアクセスパスの切り替え操作が発生し、多大な手間と時間を要する困難な作業となる。

図２２に示すファームウェア更新方法によれば、ホストコンピュータでのパス切り替え操作は不要であり、保守員のみで作業することができるというメリットがある。しかしながら、ディスク制御装置に切替機構を備える必要があり、ディスク制御装置の製造コストが高くなる。また、切替機構は、ディスク制御装置上のホストインタフェース搭載数に比例して必要になるため、ホストインタフェース搭載数の多い大型ディスク制御装置ではさらに製造コストを押し上げるというデメリットがある。さらに、シングルコントローラ構成では課題解決ができず、冗長コントローラ構成が必須であることからディスク制御装置の導入コストが高くなる。

また、特許文献１の方法は、クラスタソフト／クラスタサービスを基本技術とし、これに仮想化技術を組み合わせたものであり、稼動系の装置から待機系の装置へサービスを引き継ぐ際にサービスの中断が発生するため、業務無停止のサービスを提供することができないという問題がある。

本発明は以上の点を考慮してなされたものであり、ユーザの使い勝手を向上させ得る情報処理装置及びその制御方法を提案するものである。

かかる課題を解決するために本発明は、情報処理装置であって、コンピュータに仮想マシン環境を提供するハイパーバイザと、前記仮想マシン環境において動作する第１〜第３の仮想マシンとを備え、前記第１及び第２の仮想マシンは、ホストコンピュータから送信されるデータの入出力要求を処理する機能を備え、前記第３の仮想マシンは、第１及び第２の仮想マシンの一方を停止状態とし、第１及び第２の仮想マシンの他方を稼働状態とした後、前記一方の仮想マシンのファームウェアを更新するように指示し、前記一方の仮想マシンのファームウェアが更新され、前記他方の仮想マシンにおけるデータの入出力要求の処理が終了したときに、前記他方の仮想マシンを停止状態とし、前記一方の仮想マシンを稼働状態とする機能を備えることを特徴とする。

また、本発明は、情報処理装置であって、コンピュータに仮想マシン環境を提供するハイパーバイザと、前記仮想マシン環境において動作する第１及び第２の仮想マシンとを備え、前記第１及び第２の仮想マシンは、ホストコンピュータから送信されるデータの入出力要求を処理する機能と、第１及び第２の仮想マシンの他方を停止状態とし、自己を稼働状態とした後、前記他方の仮想マシンのファームウェアを更新するように指示し、前記他方の仮想マシンのファームウェアが更新され、自己のデータの入出力要求の処理が終了したときに、自己を停止状態とし、前記他方の仮想マシンを稼働状態とする機能とを備えることを特徴とする。

さらに、本発明は、コンピュータに仮想マシン環境を提供するハイパーバイザと、前記仮想マシン環境において動作する第１〜第３の仮想マシンを有する情報処理装置の制御方法であって、前記第１及び第２の仮想マシンが、ホストコンピュータから送信されるデータの入出力要求を処理する第１のステップと、前記第３の仮想マシンが、第１及び第２の仮想マシンの一方を停止状態とし、第１及び第２の仮想マシンの他方を稼働状態とする第２のステップと、前記第３の仮想マシンが、前記一方の仮想マシンのファームウェアを更新するように指示し、前記一方の仮想マシンのファームウェアが更新され、前記他方の仮想マシンにおけるデータの入出力要求の処理が終了したときに、前記他方の仮想マシンを停止状態とし、前記他方の仮想マシンを稼働状態とする第３のステップとを備えることを特徴とする。

従って、業務を停止することなくファームウェアを更新することができる。

本発明によれば、ユーザの使い勝手を向上させ得る情報処理装置及びその制御方法を実現することができる。

本実施形態のホストコンピュータ及びディスク制御装置の構成を示すブロック図の一例である。第１実施形態のコントローラの構成を示すブロック図の一例である。制御部をスタンバイ状態とする動作手順を示すフローチャートの一例である。制御部をスタンバイ状態とする動作の説明に供する概念図の一例である。制御部のファームウェアを更新する動作手順を示すフローチャートの一例である。制御部のファームウェアを更新する動作の説明に供する概念図の一例である。Ｉ／Ｏ要求を制御部において処理するための動作手順を示すフローチャートの一例である。Ｉ／Ｏ要求を制御部において処理するための動作の説明に供する概念図の一例である。第２実施形態のコントローラの構成を示すブロック図の一例である。制御部及び指示部をスタンバイ状態とする動作手順を示すフローチャートの一例である。制御部及び指示部をスタンバイ状態とする動作の説明に供する概念図の一例である。指示部のファームウェアを更新する動作手順を示すフローチャートの一例である。指示部のファームウェアを更新する動作の説明に供する概念図の一例である。第３実施形態のコントローラの構成を示すブロック図の一例である。制御部をスタンバイ状態とする動作手順を示すフローチャートの一例である。制御部をスタンバイ状態とする動作の説明に供する概念図の一例である。制御部のファームウェアを更新する動作手順を示すフローチャートの一例である。制御部のファームウェアを更新する動作の説明に供する概念図の一例である。Ｉ／Ｏ要求を制御部において処理するための動作手順を示すフローチャートの一例である。Ｉ／Ｏ要求を制御部において処理するための動作の説明に供する概念図の一例である。従来のホストコンピュータ及びディスク制御装置の構成を示すブロック図の一例である。従来のホストコンピュータ及びディスク制御装置の構成を示すブロック図の一例である。

以下、本発明の一実施の形態を、図面を参照して詳細に説明する。なお、これにより本発明が限定されるものではない。

図１は、本実施形態におけるストレージシステム１を示す図である。ストレージシステム１は、ホストコンピュータ１０及びディスク制御装置２０（情報処理装置）を備えて構成されている。

ホストコンピュータ１０は、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）などの通常のコンピュータ装置と同様のハードウェアを備えて構成されている。また、ホストコンピュータ１０は、アプリケーション１１、ファイルシステム１２、上位ドライバ１３、下位ドライバ１４及びＨＢＡ（Host Bus Adapter）１５を備えて構成されている。

ホストコンピュータ１０は、アプリケーション１１、ファイルシステム１２、上位ドライバ１３、下位ドライバ１４を実行し、ＨＢＡ１５を介してディスク制御装置２０に対するＩ／Ｏ要求及びＩ／Ｏ要求に対応するデータの送受信を行う。

ディスク制御装置２０は、コントローラ２１及びディスク装置２２を備えて構成されている。ディスク制御装置２０は、ホストコンピュータ１０から送信されるＩ／Ｏ要求に基づいて、ホストコンピュータ１０から送信されるＩ／Ｏ要求に対応するデータをディスク装置２２に書き込み、Ｉ／Ｏ要求に対応するデータをディスク装置２２から読み出してホストコンピュータ１０に送信する。

（第１実施形態）
図２は、第１実施形態のコントローラ２１の構成を示す図である。コントローラ２１は、プロセッサ１５０、メモリ１５１、外部インタフェース制御回路１５２、ホストインタフェース制御回路１５３、ディスクインタフェース制御回路１５４及びコントローラ間通信制御回路１５５を備えたコンピュータとして構成されている。

プロセッサ１５０は、コンピュータ上でプログラムを動作させるためのハードウェアである。メモリ１５１は、プロセッサ１５０が解釈・実行するプログラムや各種制御データの記憶領域、作業領域、又はディスクアクセスに係るリードデータやライトデータの格納領域として使用される。

外部インタフェース制御回路１５２は、外部インタフェースを介してユーザインタフェースを提供する管理・監視端末と接続されており、管理・監視端末との間で相互に授受される各種制御情報（各種ハードウェアの制御情報や継続的な監視情報、ディスク制御装置２０の操作情報、運用及び管理情報）の入出力制御を行う。

ホストインタフェース制御回路１５３は、ホストインタフェースを介してホストコンピュータ１０と接続されており、ホストコンピュータ１０から受信したディスクアクセスに係るＩ／Ｏ要求及びＩ／Ｏ要求に対応するデータ入出力の制御を行う。ディスクインタフェース制御回路１５４は、ディスクインタフェースを介してディスク装置２２に接続されており、ディスク装置２２に係る入出力制御を行う。

冗長コントローラ構成の場合には、コントローラ間通信制御回路１５５は、もう一方のコントローラ間通信制御回路とコントローラ間データバスを介して接続されており、各コントローラ間で共有する各種制御情報やデータなどの入出力制御を行う。

また、コントローラ２１は、制御プログラム、指示プログラム及びハイパーバイザプログラムをメモリ１５１に備えて構成されている。コントローラ２１のプロセッサ１５０は、ハイパーバイザプログラムを実行し、コンピュータ上に別のコンピュータ環境を用意する仮想マシン環境を実現する。ハイパーバイザプログラムが実行されることにより仮想マシンとして実現されるハイパーバイザ１４０は、仮想マシン環境を提供する機能手段である。

具体的に、コントローラ２１は、仮想マシン環境上で、制御プログラムを実行することにより仮想マシンとして実現される制御部（以下、制御部１１０（第１の仮想マシン）及び１３０（第２の仮想マシン）と呼ぶ）及び指示プログラムを実行することにより仮想マシンとして実現される指示部（以下、指示部１２０（第３の仮想マシン）と呼ぶ）を備えて構成されている。

制御部１１０は、ディスク制御全般（例えば、ディスク装置２２に対する読み書きなど）を司る機能手段であり、サービスプロセッサ１１１、機能ファームウェア１１２、ゲストＯＳ（Operating System）１１３及び準仮想化ドライバ（PV driver（Para-Virtualized driver））１１４を備えて構成されている。制御部１３０は、制御部１１０と同様にディスク制御全般を司る機能手段であり、サービスプロセッサ１３１、機能ファームウェア１３２、ゲストＯＳ１３３及び準仮想化ドライバ１３４を備えて構成されている。

指示部１２０は、制御部１１０、１３０と相互に通信を行い、制御部１１０、１３０に対して各種指示（例えば、制御部１３０に対してリブート実施など）を行う機能手段であり、サービスプロセッサ１２１、ゲストＯＳ１２３及び準仮想化ドライバ１２４を備えて構成されている。

サービスプロセッサ１１１、１２１及び１３１は、各種ハードウェアの制御や継続的な監視、ディスク制御装置２０の操作、運用及び管理の機能を提供する。機能ファームウェア１１２及び１３２は、各種ハードウェアを操作、制御し、ホストコンピュータから受信したディスクアクセスに係るＩ／Ｏ要求を処理する。ゲストＯＳ１１３、１２３及び１３３は、コンピュータ上に別のコンピュータ環境を用意する仮想マシン環境において、仮想マシン環境上で動作するＯＳ（例えば、VxWorksやLinux, Solarisなど）である。準仮想化ドライバ１１４、１２４及び１３４は、ハイパーバイザ１４０上で動作するゲストＯＳ１１３、１２３又は１３３の動作パフォーマンスを、仮想化されていない物理ハードウェア上で動作させた場合のように、仮想化によるオーバーヘッドを最小限に抑えるためのハードウェア制御用ドライバである。

次に、第１実施形態のコントローラ２１の動作について、図３−図８のフローチャート及び概念図を参照して説明する。なお、説明上の前提条件として下記の第１−第４の条件を定義する。

第１に、プロセッサ１５０は、コントローラ２１の初回起動直後、ホストコンピュータ１０から受信するＩ／Ｏ要求を制御部１１０によって処理し、制御部１３０をスタンバイ状態とする。この場合、プロセッサ１５０は、次回以降のコントローラ２１の起動直後の状態については、前回のコントローラ２１が停止する直前の状態で復帰する。第２に、プロセッサ１５０は、指示部１２０によって制御部１３０のファームウェアの更新を指示する。第３に、プロセッサ１５０は、ファームウェアの更新完了後、ホストコンピュータ１０から受信するＩ／Ｏ要求を制御部１３０によって処理し、制御部１１０をスタンバイ状態とする。第４に、プロセッサ１５０は、外部インタフェースを介して接続した管理・監視端末から、外部インタフェース制御回路１５２を経由して更新用ファームウェアのバイナリをサービスプロセッサ１２１に事前に転送する。

まず、制御部１３０をスタンバイ状態とする動作について、図３及び図４のフローチャート及び概念図を参照して説明する。

サービスプロセッサ１２１は、コントローラ２１の起動過程で、制御部１３０をスタンバイ状態とするために、サービスプロセッサ１３１に対して、スタンバイ（Standby）とする旨の指示を行う（Ｓ１００）。続いて、サービスプロセッサ１３１は、スタンバイとする旨の指示を受信すると、制御部１３０をスタンバイ状態に移行させた後、サービスプロセッサ１２１に対して、スタンバイ状態となった旨の報告を行う（Ｓ１１０）。

続いて、サービスプロセッサ１２１は、制御部１１０をアクティブ状態とするために、サービスプロセッサ１１１に対して、アクティブ（Active）とする旨の指示を行う（Ｓ１２０）。続いて、サービスプロセッサ１１１は、アクティブとする旨の指示を受信すると、制御部１１０をアクティブ状態に移行させた後、サービスプロセッサ１２１に対して、アクティブ状態となった旨の報告を行う（Ｓ１３０）。

以上で、ホストコンピュータ１０から受信するＩ／Ｏ要求は、制御部１１０が処理する状態となる（図４）。

次に、制御部１３０のファームウェアを更新する動作について、図５及び図６のフローチャート及び概念図を参照して説明する。

サービスプロセッサ１２１は、制御部１３０のファームウェア更新の準備として、サービスプロセッサ１３１に対して、バイナリ（Binary）（ファームウェア）の転送を行う（Ｓ１４０）。続いて、サービスプロセッサ１３１は、すべてのバイナリを受信すると、サービスプロセッサ１２１に対して、バイナリを受信した旨の報告を行う（Ｓ１５０）。

続いて、サービスプロセッサ１２１は、制御部１３０のファームウェア更新を行うために、サービスプロセッサ１３１に対してリブート（Reboot）を行う旨の指示を行う（Ｓ１６０）。続いて、サービスプロセッサ１３１は、リブートを行う旨の指示を受信すると、サービスプロセッサ１２１に対して、リブートを開始する旨の報告を行った後、制御部１３０のリブートを開始する（Ｓ１７０）。続いて、サービスプロセッサ１３１は、制御部１３０のリブートが完了すると、サービスプロセッサ１２１に対して、レディ（Ready）状態となった旨の報告を行う（Ｓ１８０）。

以上で、制御部１３０のファームウェアは、更新済みとなる。なお、サービスプロセッサ１１１は、Ｓ１４０からＳ１８０までの間、機能ファームウェア１１２を実行し、ホストインタフェース制御回路１５３を経由してデータの入出力制御を行う（図６）。

次に、Ｉ／Ｏ要求を制御部１３０において処理するための動作について、図７及び図８のフローチャート及び概念図を参照して説明する。

サービスプロセッサ１２１は、今後、ホストコンピュータ１０から受信するＩ／Ｏ要求について、制御部１３０において処理するために、サービスプロセッサ１３１に対して、アクティブとする旨の指示を行う（Ｓ１９０）。続いて、サービスプロセッサ１３１は、アクティブとする旨の指示を受信すると、制御部１３０をアクティブ状態に移行させた後、サービスプロセッサ１２１に対して、アクティブ状態となった旨の報告を行う（Ｓ２００）。以降、ホストコンピュータ１０からのＩ／Ｏ要求は、制御部１３０において受信し、処理する。

続いて、サービスプロセッサ１２１は、制御部１１０をスタンバイ状態とするために、サービスプロセッサ１１１に対して、スタンバイとする旨の指示を行う（Ｓ２１０）。続いて、サービスプロセッサ１１１は、スタンバイとする旨の指示を受信すると、制御部１１０が既にホストコンピュータ１０から受信したＩ／Ｏ要求がある場合には、サービスプロセッサ１２１に対して、受信済のＩ／Ｏ要求を処理中である旨の報告を行い（Ｓ２２０）、制御部１１０がすべての受信済のＩ／Ｏ要求の処理するまで当該Ｉ／Ｏ要求の処理を継続する。

続いて、サービスプロセッサ１１１は、制御部１１０がホストコンピュータ１０から受信したＩ／Ｏ要求で未処理のものがなければ、制御部１１０をスタンバイ状態に移行させた後、サービスプロセッサ１２１に対して、スタンバイ状態となった旨の報告を行う（Ｓ２３０）。

なお、サービスプロセッサ１１１は、Ｓ１９０からＳ２００までの間、機能ファームウェア１１２を実行し、ホストインタフェース制御回路１５３を経由してデータの入出力制御を行う（図８）。そして、サービスプロセッサ１１１は、Ｓ２１０以降、ホストコンピュータ１０からの新規のＩ／Ｏ要求を受領せず、既に受領済みのＩ／Ｏ要求がゼロになるまで、処理を継続する。また、サービスプロセッサ１３１は、Ｓ２００以降、直ちに機能ファームウェア１３２を実行し、ホストインタフェース制御回路１５３を経由してデータの入出力制御を行う（図８）。

以上のように、ディスク制御装置２０は、ハイパーバイザ１４０上に、ゲストＯＳ１１３、１３３を含む２つ以上の制御部１１０、１３０を備え、制御部１１０、１３０に機能ファームウェア１１２、１３２及びサービスプロセッサ１１１、１３１を備え、さらに、制御部１１０、１３０の機能ファームウェア１１２、１３２及びサービスプロセッサ１１１、１３１がハードウェアを操作するためにゲストＯＳ上に準仮想化ドライバ１１４、１３４を備える。また、ディスク制御装置２０は、ハイパーバイザ１４０上にゲストＯＳ１２４を含む１つ以上の指示部１２０を備え、指示部１２０のサービスプロセッサ１２１がハードウェアを操作するためにゲストＯＳ１２３上に準仮想化ドライバ１２４を備える。さらに、ディスク制御装置２０は、制御部１１０、１３０と指示部１２０とが相互に通信する手段を備える。

かかる構成により、２４時間３６５日業務を停止することができないミッションクリティカル環境におけるディスク制御装置２０のファームウェアの更新を実現することができる。

また、ファームウェアの更新に係る一連の作業がコントローラ２１の内部で完結するため、ホストコンピュータ１０のシステム管理者による作業は不要となり、ディスク制御装置２０の保守員のみでディスク制御装置２０のファームウェアを更新することができる。さらに、ファームウェアの更新に係る一連の作業がコントローラ２１の内部で完結するため、ディスク制御装置２０を冗長コントローラ構成とする必要がなくなり、ディスク制御装置２０がシングルコントローラ構成であっても、業務を停止することなくファームウェアを更新することができる。

さらに、ファームウェアの更新に係る一連の作業がコントローラ２１の内部で完結するため、ホストコンピュータ１０でのアクセスパスの切り替え操作が発生せず、ディスク制御装置に接続しているホストコンピュータ１０が多数存在する場合でも、容易にディスク制御装置２０のファームウェアを更新することができる。

さらに、各ホストコンピュータ１０上にパス切替ドライバの導入や各ホストコンピュータ１０とディスク制御装置２０間を冗長パス構成とするためのハードウェアが不要となるため、導入コストを抑えることができる。さらに、ディスク制御装置２０に切替機構を備える必要がなく、ホストインタフェース搭載数の多い大型ディスク制御装置であっても、ディスク制御装置２０の製造コストを抑えることができる。

さらに、コントローラ２１内には更新前のファームウェアを搭載した制御部１１０が存在するため、例えば、ファームウェアの更新後に何らかの障害が発生した場合にも、更新前のファームウェアに戻すことも容易である。

（第２実施形態）
図９は、第２実施形態におけるコントローラ２１を示す図である。第２実施形態におけるコントローラ２１は、指示部１２０に代えて指示部１２０Ａ（第３の仮想マシン）及び１２０Ｂ（第４の仮想マシン）の２つの指示部を備える点を除いて同様に構成されている。

次に、第２実施形態のコントローラ２１の動作について、図１０−図１３のフローチャート及び概念図を参照して説明する。なお、説明上の前提条件として下記の第１−第４の条件を定義する。

第１に、プロセッサ１５０は、コントローラ２１の初回起動直後、ホストコンピュータ１０から受信するＩ／Ｏ要求を制御部１１０によって処理し、制御部１３０をスタンバイ状態とすると共に、各指示を指示部１２０Ａによって担当させ、指示部１２０Ｂをスタンバイ状態とする。この場合、プロセッサ１５０は、次回以降のコントローラ２１の起動直後の状態については、前回のコントローラ２１が停止する直前の状態で復帰する。第２に、プロセッサ１５０は、指示部１２０Ａによって指示部１２０Ｂのファームウェアの更新を指示する。第３に、プロセッサ１５０は、ファームウェアの更新完了後の指示を、指示部１２０Ｂによって担当させ、指示部１２０Ａをスタンバイ状態とする。第４に、プロセッサ１５０は、更新用ファームウェアのバイナリを、外部インタフェースを介して接続した管理・監視端末から、外部インタフェース制御回路１５２を経由してサービスプロセッサ１２０Ａに事前に転送する。

まず、制御部１３０及び指示部１２０Ｂをスタンバイ状態とする動作について、図１０及び図１１のフローチャート及び概念図を参照して説明する。

サービスプロセッサ１２１Ａは、コントローラ２１の起動過程で、制御部１３０をスタンバイ状態とするために、サービスプロセッサ１３１に対して、スタンバイとする旨の指示を行う（Ｓ３００）。続いて、サービスプロセッサ１２１Ａは、指示部１２０Ｂをスタンバイ状態とするために、サービスプロセッサ１２１Ｂに対して、スタンバイとする旨の指示を行う（Ｓ３１０）。

続いて、サービスプロセッサ１３１は、スタンバイとする旨の指示を受信すると、制御部１３０をスタンバイ状態に移行させた後、サービスプロセッサ１２１Ａに対して、スタンバイ状態となった旨の報告を行う（Ｓ３２０）。続いて、サービスプロセッサ１２１Ｂは、スタンバイとする旨の指示を受信すると、指示部１２０Ｂをスタンバイ状態に移行させた後、サービスプロセッサ１２１Ａに対して、スタンバイ状態となった旨の報告を行う（Ｓ３３０）。

続いて、サービスプロセッサ１２１Ａは、制御部１１０をアクティブ状態とするために、サービスプロセッサ１１１に対して、アクティブとする旨の指示を行う（Ｓ３４０）。続いて、サービスプロセッサ１１１は、アクティブとする旨の指示を受信すると、制御部１１０をアクティブ状態に移行させた後、サービスプロセッサ１２１Ａに対して、アクティブ状態となった旨の報告を行う（Ｓ３５０）。

以上で、ホストコンピュータ１０から受信するＩ／Ｏ要求は、制御部１１０が処理し、各指示は指示部１２０Ａが担当する状態となる（図１１）。

次に、指示部１２０Ｂのファームウェアを更新する動作について、図１２及び図１３のフローチャート及び概念図を参照して説明する。

サービスプロセッサ１２１Ａは、指示部１２０Ｂのファームウェア更新の準備として、サービスプロセッサ１２１Ｂに対して、バイナリの転送を行う（Ｓ３６０）。続いて、サービスプロセッサ１２１Ｂは、すべてのバイナリを受信すると、サービスプロセッサ１２１Ａに対して、バイナリを受信した旨の報告を行う（Ｓ３７０）。

続いて、サービスプロセッサ１２１Ａは、指示部１２０Ｂのファームウェア更新を行うために、サービスプロセッサ１２１Ｂに対して、リブートを行う旨の指示を行う（Ｓ３８０）。続いて、サービスプロセッサ１２１Ｂは、リブートを行う旨の指示を受信すると、サービスプロセッサ１２１Ａに対して、リブートを開始する旨の報告を行った後、指示部１２０Ｂのリブートを開始する（Ｓ３９０）。続いて、サービスプロセッサ１２１Ｂは、指示部１２０Ｂのリブートが完了すると、サービスプロセッサ１２１Ａに対して、レディ状態となった旨の報告を行う（Ｓ４００）。以上で、指示部１２０Ｂのファームウェアは更新済みとなる。

続いて、サービスプロセッサ１２１Ａは、サービスプロセッサ１２１Ｂに対して、アクティブとする旨の指示を行う（Ｓ４１０）。続いて、サービスプロセッサ１２１Ｂは、アクティブとする旨の指示を受信すると、指示部１２０Ｂをアクティブ状態に移行させた後、サービスプロセッサ１２１Ａに対して、アクティブ状態となった旨の報告を行う（Ｓ４２０）。以降、指示部１２０Ｂが指示を担当する。

続いて、サービスプロセッサ１２１Ｂは、指示部１２０Ａをスタンバイ状態とするために、サービスプロセッサ１２１Ａに対して、スタンバイとする旨の指示を行う（Ｓ４３０）。続いて、サービスプロセッサ１２１Ａは、スタンバイとする旨の指示を受信すると、指示部１２０Ａをスタンバイ状態に移行させた後、サービスプロセッサ１２１Ｂに対して、スタンバイ状態となった旨の報告を行う（Ｓ４４０）。

なお、サービスプロセッサ１１１は、Ｓ３６０からＳ４４０までの間、機能ファームウェア１１２を実行し、ホストインタフェース制御回路１５３を経由してデータの入出力制御を行う（図１３）。

かかる構成により、第１実施形態と同様の効果を得ることに加え、指示部１２０Ａ及び１２０Ｂについても業務を停止することなくファームウェアを更新することができる。

（第３実施形態）
図１４は、第３実施形態におけるコントローラ２１を示す図である。第３実施形態におけるコントローラ２１は、制御部１１０（第１の仮想マシン）及び１３０（第２の仮想マシン）のサービスプロセッサ１１１及び１３１に、指示部１２０の機能を取り込んだ点を除いて同様に構成されている。

次に、第３実施形態のコントローラ２１の動作について、図１５−図２０のフローチャート及び概念図を参照して説明する。なお、説明上の前提条件として下記の第１−第４の条件を定義する。

第１に、プロセッサ１５０は、コントローラ２１の初回起動直後、ホストコンピュータ１０から受信するＩ／Ｏ要求を制御部１１０によって処理し、制御部１３０をスタンバイ状態とする。この場合、プロセッサ１５０は、次回以降のコントローラ２１の起動直後の状態については、前回のコントローラ２１が停止する直前の状態で復帰する。第２に、プロセッサ１５０は、サービスプロセッサ１１１によって制御部１３０のファームウェアの更新を指示する。第３に、プロセッサ１５０は、ファームウェアの更新完了後、ホストコンピュータ１０から受信するＩ／Ｏ要求を制御部１３０によって処理し、制御部１１０をスタンバイ状態とする。第４に、プロセッサ１５０は、外部インタフェースを介して接続した管理・監視端末から、外部インタフェース制御回路１５２を経由して更新用ファームウェアのバイナリをサービスプロセッサ１１１に事前に転送する。

まず、制御部１３０をスタンバイ状態とする動作について、図１５及び図１６のフローチャート及び概念図を参照して説明する。

サービスプロセッサ１１１は、コントローラ２１の起動過程で、制御部１３０をスタンバイ状態とするために、サービスプロセッサ１３１に対して、スタンバイとする旨の指示を行う（Ｓ５００）。続いて、サービスプロセッサ１３１は、スタンバイとする旨の指示を受信すると、制御部１３０をスタンバイ状態に移行させた後、サービスプロセッサ１１１に対して、スタンバイ状態となった旨の報告を行う（Ｓ５１０）。

以上で、ホストコンピュータ１０から受信するＩ／Ｏ要求は、制御部１１０が処理する状態となる（図１６）。

次に、制御部１３０のファームウェアを更新する動作について、図１７及び図１８のフローチャート及び概念図を参照して説明する。

サービスプロセッサ１１１は、制御部１３０のファームウェア更新の準備として、サービスプロセッサ１３１に対して、バイナリの転送を行う（Ｓ５２０）。続いて、サービスプロセッサ１３１は、すべてのバイナリを受信すると、サービスプロセッサ１１１に対して、バイナリを受信した旨の報告を行う（Ｓ５３０）。

続いて、サービスプロセッサ１１１は、制御部１３０のファームウェア更新を行うために、サービスプロセッサ１３１に対してリブートを行う旨の指示を行う（Ｓ５４０）。続いて、サービスプロセッサ１３１は、リブートを行う旨の指示を受信すると、サービスプロセッサ１１１に対して、リブートを開始する旨の報告を行った後、制御部１３０のリブートを開始する（Ｓ５５０）。続いて、サービスプロセッサ１３１は、制御部１３０のリブートが完了すると、サービスプロセッサ１１１に対して、レディ状態となった旨の報告を行う（Ｓ５６０）。

以上で、制御部１３０のファームウェアは、更新済みとなる。なお、サービスプロセッサ１１１は、Ｓ５２０からＳ５６０までの間、機能ファームウェア１１２を実行し、ホストインタフェース制御回路１５３を経由してデータの入出力制御を行う（図１８）。

次に、Ｉ／Ｏ要求を制御部１３０において処理するための動作について、図１９及び図２０のフローチャート及び概念図を参照して説明する。

サービスプロセッサ１１１は、今後、ホストコンピュータ１０から受信するＩ／Ｏ要求について、制御部１３０において処理するために、サービスプロセッサ１３１に対して、アクティブとする旨の指示を行う（Ｓ５７０）。続いて、サービスプロセッサ１３１は、アクティブとする旨の指示を受信すると、制御部１３０をアクティブ状態に移行させた後、サービスプロセッサ１１１に対して、アクティブ状態となった旨の報告を行う（Ｓ５８０）。以降、ホストコンピュータ１０からのＩ／Ｏ要求は、制御部１３０において受信し、処理する。

続いて、サービスプロセッサ１３１は、制御部１１０をスタンバイ状態とするために、サービスプロセッサ１１１に対して、スタンバイとする旨の指示を行う（Ｓ５９０）。続いて、サービスプロセッサ１１１は、スタンバイとする旨の指示を受信すると、制御部１１０が既にホストコンピュータ１０から受信したＩ／Ｏ要求がある場合には、サービスプロセッサ１３１に対して、受信済のＩ／Ｏ要求を処理中である旨の報告を行い（Ｓ６００）、制御部１１０がすべての受信済のＩ／Ｏ要求の処理するまで当該Ｉ／Ｏ要求の処理を継続する。

続いて、サービスプロセッサ１１１は、制御部１１０がホストコンピュータ１０から受信したＩ／Ｏ要求で未処理のものがなければ、制御部１１０をスタンバイ状態に移行させた後、サービスプロセッサ１３１に対して、スタンバイ状態となった旨の報告を行う（Ｓ６１０）。

なお、サービスプロセッサ１１１は、Ｓ５７０からＳ５８０までの間、機能ファームウェア１１２を実行し、ホストインタフェース制御回路１５３を経由してデータの入出力制御を行う（図２０）。そして、サービスプロセッサ１１１は、Ｓ５９０以降、ホストコンピュータ１０からの新規のＩ／Ｏ要求を受領せず、既に受領済みのＩ／Ｏ要求がゼロになるまで、処理を継続する。サービスプロセッサ１３１は、Ｓ５８０以降、直ちに機能ファームウェア１３２を実行し、ホストインタフェース制御回路１５３を経由してデータの入出力制御を行う（図２０）。

かかる構成により、第１実施形態と同様の効果を得ることができる。

なお、本実施形態においては、コントローラ２１のシングルコントローラ構成に適用した場合について述べたが、本発明はこれに限らず、例えば、図２１、図２２におけるディスク制御装置２０、４０のような冗長構成のコントローラに適用するようにしても良く、この他種々の形態のディスク制御装置に適用することができる。

本発明は、２４時間３６５日業務を停止することができないミッションクリティカル環境において、ホストコンピュータから送信されるデータのディスクに対する入出力制御を行うディスク制御装置のほか、この他種々のミッションクリティカル環境において、ファームウェアを更新する情報処理装置やサーバ装置などのファームウェア組込み製品に適用することができる。

１０……ホストコンピュータ、２０……ディスク制御装置、２１……コントローラ、２２……ディスク、１１０、１３０……制御部、１２０、１２０Ａ、１２０Ｂ……指示部、１１１、１２１、１２１Ａ、１２１Ｂ、１３１……サービスプロセッサ、１１２、１３２……機能ファームウェア、１１３、１２３、１２３Ａ、１２３Ｂ、１３３……ゲストＯＳ、１１４、１２４、１２４Ａ、１２４Ｂ、１３４……準仮想化ドライバ、１４０……ハイパーバイザ、１５０……プロセッサ、１５１……メモリ、１５２……外部インタフェース制御回路、１５３……ホストインタフェース制御回路、１５４……ディスクインタフェース制御回路、１５５……コントローラ間通信制御回路

Claims

コンピュータに仮想マシン環境を提供するハイパーバイザと、
前記仮想マシン環境において動作する第１〜第４の仮想マシンと
を備え、
前記第１及び第２の仮想マシンは、それぞれ、
ホストコンピュータから送信されるデータの入出力要求を処理する機能
を備え、
前記第１及び前記第２の仮想マシンを管理する第３及び第４の仮想マシンは、それぞれ、
第１及び第２の仮想マシンの一方を停止状態とし、第１及び第２の仮想マシンの他方を稼働状態とした後、前記第１及び前記第２の仮想マシンの前記一方の仮想マシンのファームウェアを更新するように指示し、前記第１及び前記第２の仮想マシンの前記一方の仮想マシンのファームウェアが更新され、前記第１及び前記第２の仮想マシンの前記他方の仮想マシンにおけるデータの入出力要求の処理が終了したときに、前記第１及び前記第２の仮想マシンの前記他方の仮想マシンを停止状態とし、前記第１及び前記第２の仮想マシンの前記一方の仮想マシンを稼働状態とする機能
を備え、
前記第３及び前記第４の仮想マシンの一方は、
前記第３及び前記第４の仮想マシンの他方を停止状態とし、前記第３及び前記第４の仮想マシンの前記他方の仮想マシンのファームウェアを更新するように指示し、前記第３及び前記第４の仮想マシンの前記ファームウェアが更新されたときに、前記第３及び前記第４の仮想マシンの一方が、自己を停止状態とし、前記第３及び前記第４の仮想マシンの前記他方の仮想マシンを稼働状態とすることを特徴とする情報処理装置。