JP5959733B2 - ストレージシステムおよびストレージシステムの障害管理方法 - Google Patents

Description

本発明は、ストレージシステムおよびストレージシステムの障害管理方法に関する。

一つの物理的計算機の中に複数の仮想マシン（仮想計算機）を設けて、各仮想マシン上でそれぞれ異なるオペレーティングシステム（ＯＳ）を実行できる仮想化技術が知られている。仮想マシンを実現するには、仮想化専用のソフトウェアが必要である。

仮想化専用ソフトウェアの中には、ＮＡＳ（Network Attached Storage）のようなストレージ装置の有するハードウェア資源を論理的に分割して複数の論理区画（仮想的な記憶装置）を形成し、それら論理区画を独立して動作させるものもある（特許文献１）。なお、 仮想マシン環境に関する技術として、特許文献２，３がある。

ファイルシステムでは、例えば、ＮＡＳ内部の一部のハードウェア（ポート、メモリ等）に障害が発生しただけで、直ちにＮＡＳ全体のフェイルオーバを実行する。これに対し、ＳＡＮ（Storage Area Network）等を用いて記憶装置にブロックアクセスするブロックマイクロ制御は、銀行や証券会社等での基幹系業務に使用されるため、高信頼性を実現している。ブロックマイクロ制御を実行するストレージシステムでは、一部のハードウェアに障害が発生した場合、その障害の生じたハードウェアをシステムから切り離して運転を続行するという縮退運転を実現している。これにより、ブロックマイクロ制御を実行するストレージシステムは、一部の障害によってストレージシステム全体が停止するのをできる限り防止している。

ＵＳ２００５／００９１４５４Ａ１ ＵＳ７８４０７９０ ＵＳ８１６６２１１

近年、ＦＣ（Fibre channel）、ｉＳＣＳＩ（Internet Small Computer System Interface）、ＦＣｏＥ（Fibre Channel over Ethernet（登録商標））、ＮＡＳ等の複数のプロトコルに１台で対応することのできる一体型ストレージシステムが注目されている。このような一体型ストレージシステムは、ユニファイドストレージシステムと呼ばれており、省スペース、低コスト、作業性向上等の利点を備える。

可用性を高めるべく、ユニファイドストレージシステムをクラスタ構成で使用することが考えられる。この場合、ユニファイドストレージシステムの外部にQuorumディスクと呼ばれる管理装置を設けて、その管理装置により各クラスタの状況を管理する。管理装置は、いずれかのクラスタ内での障害発生を検知した場合、障害発生元に対してリセット指示を、フェイルオーバ先に対してフェイルオーバ指示を、発行する。

しかし、管理装置とユニファイドストレージシステムとの間の接続線が外れたり、断線したりした場合、いわゆるSplitBrain状態になり、管理装置は監視先の死活を判断することができなくなる。従って、この場合、管理装置は、ユニファイドストレージシステム内のいずれかのクラスタで生じる障害を検知することはできない。

また、ユニファイドストレージシステムにおいては、ファイルシステムで障害の発生する頻度が高いと考えられるが、些細な障害でフェイルオーバ処理をいちいち実行したのでは、ユニファイドストレージシステムの性能低下を招き、ユーザの使い勝手も悪い。

本発明は、上記問題に鑑みてなされたもので、その目的は、ファイルアクセス要求とブロックアクセス要求とを処理可能で、かつ、クラスタ構成を有するストレージシステムにおいて、障害を管理できるようにしたストレージシステムを提供することにある。本発明の他の目的は、ブロックアクセス要求を処理する第１制御部が、ファイルアクセス要求を処理する複数の第２制御部での障害についても集約して管理することで、特別な外部装置を用いずにクラスタ構成を有するストレージシステムの障害を管理できるようにしたストレージシステムおよびストレージシステムの障害管理方法を提供することにある。

上記課題を解決すべく、本発明に従うストレージシステムは、ファイルアクセス要求およびブロックアクセス要求を処理するストレージシステムにおいて、複数のクラスタと、各クラスタに跨がって設けられ、ディスクデバイスへのブロックアクセス要求を制御する第１制御部と、各クラスタにそれぞれ個別に設けられ、仮想化制御部で管理される仮想マシン上で動作してファイルアクセス要求を処理する複数の第２制御部と、各クラスタ内に設けられ、該各クラスタ内での障害を検出する障害検出部と、第１制御部に設けられ、各障害検出部で検出された障害に関する障害情報を集約管理する障害情報管理部と、を備えている。

第１制御部内には障害回復部を設けてもよく、障害回復部は、障害情報管理部で管理される障害に対処するための処理内容を決定し、この決定した処理内容の実行を、第１制御部、第２制御部または仮想化制御部のうち、障害の発生した箇所を担当する制御部に指示してもよい。

本発明の一実施形態の概要を示す説明図。 ストレージシステムのハードウェア構成を示すブロック図。 コントローラのソフトウェア構成を示す説明図。 メモリの記憶内容を示す説明図。 メモリのうち制御情報を記憶する領域を示す説明図。 ブロック制御部の使用するハードウェア資源を管理するテーブルの構成例を示す説明図。 ハイパバイザの使用するハードウェア資源を管理するテーブルの構成例を示す説明図。 ブロック制御部以外の他のＦＯＳ（ファイルシステムを使用するＯＳ）が使用するハードウェア資源を管理するテーブルの構成例を示す説明図。 ブロック制御部、ハイパバイザ、ＦＯＳがそれぞれ確保しているハードウェア資源の関係を示す説明図。 ＦＯＳに割り当てられたハードウェア資源で障害が発生したときの処理を示すフローチャート。 ハイパバイザに割り当てられたハードウェア資源で障害が発生したときの処理を示すフローチャート。 ブロック制御部に割り当てられたハードウェア資源で障害が発生したときの処理を示すフローチャート。 ＦＯＳに割り当てられたハードウェア資源で障害が発生したときの処理の他の例を示すフローチャート。 障害を管理するテーブルの構成例を示す説明図。 ＦＯＳの停止を検出してフェイルオーバを開始する処理を示すフローチャート。 図１５に続くフローチャート。 障害検出からフェイルオーバ処理実行までのブロック制御部の動作を示すフローチャート。 クラスタ間を跨がるブロック制御部同士で障害情報を伝達する方法を示す説明図。 第２実施例に係り、ＦＯＳが自分自身の障害を検出してブロック制御部に報告する処理を示すフローチャート。 第３実施例に係り、Ｉ／Ｏ（Input/Output）処理中に障害が発生した場合の処理方法の例を示すフローチャート。 フェイルオーバ構成情報の例を示す説明図。 Ｉ／Ｏ要求時に指定されるファイル（ファイルシステム）名またはディレクトリ情報と対象ボリュームとの関係を管理する情報（Ｔ３３）の構成例と、ユーザの指定するＬＵ情報とＦＯＳで管理するＬＵ番号との関係を管理する情報（Ｔ１４）の構成例を示す。

以下、図面に基づいて、本発明の実施の形態を説明する。添付図面では、機能的に同じ要素を同じ番号で表示する場合がある。添付図面は、本発明の原理に則った具体的な実施形態と実施例とを示している。それらの実施形態及び実施例は、本発明の理解のためのものであり、本発明を限定的に解釈するために用いてはならない。

本実施形態では、当業者が本発明を実施するのに十分かつ詳細にその説明がなされているが、他の実施例または形態も可能である。本発明の技術的思想の範囲と精神を逸脱することなく、構成または構造の変更、多様な要素の置き換えが可能であることを理解する必要がある。従って、以降の記述を、これに限定して解釈してはならない。

さらに、本発明の実施形態は、後述するように、汎用コンピュータ上で稼動するソフトウェアで実装しても良いし、専用ハードウェアで実装してもよいし、またはソフトウェアとハードウェアの組み合わせで実装しても良い。

以後の説明では、管理用の情報をテーブル形式で説明するが、管理用の情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造やそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」と呼ぶことがある。

以下では「プログラム」を主語（動作主体）として本発明の実施形態における各処理について説明を行う場合がある。プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサを主語とした説明としてもよい。プログラムの一部または全ては専用ハードウェアで実現してもよく、また、モジュール化されていても良い。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。

本実施形態のストレージシステムは、ファイルアクセス要求とブロックアクセス要求を一つのシステムで処理可能なユニファイドストレージシステムであって、クラスタ構成を備えている。そして、本実施形態のストレージシステムでは、ファイルシステムを使用するＯＳ（以下、ＦＯＳ）の障害状態を統括して管理するための障害管理機構をブロック制御部に設けている。

ＦＯＳはハイパバイザよって形成される仮想マシン上で動作し、ファイルシステムに対してファイルを入出力する。ＦＯＳはハイパバイザにより管理されるが、ＦＯＳの障害についての情報は、ハイパバイザとは別のブロック制御部に集約される。ブロック制御部とは、ディスクデバイスにブロック単位でデータを読み書きするための機能であり、「ブロックストレージマイクロ制御」と呼ぶこともできる。

このように本実施形態では、ＦＯＳの障害に関する情報を、ＦＯＳの直接的な管理者であるハイパバイザではなく、ハイパバイザとは別のブロック制御部に集めて管理する。ブロック制御部は、例えば銀行および証券会社等での基幹系業務に使用されることが多く、高い信頼性が求められている。従って、本実施形態では、信頼性の高いブロック制御部にクラスタ内で生じる障害に関する情報を集約する。これにより、ブロック制御部は、ストレージシステム全体の観点から障害に適切に対処することができる。

また本実施形態では、ブロック制御部が必要最低限のハードウェア資源を優先的に確保し、残りのハードウェア資源をハイパバイザおよび複数のＦＯＳに分配する。従って、必要最低限のハードウェア資源を確保しているブロック制御部は、ホスト装置からファイルアクセス要求が多量に発行されている状況下であっても、障害管理を適切に行うことができる。

図１は、本発明の一実施形態の概要を示す説明図である。図１は本実施形態の理解のために用意されたもので、本発明は図１に示す構成例に限定されない。

ストレージシステム３０は、ブロックアクセス要求を発行するコマンド発行装置１０１Ａとファイルアクセス要求を発行するコマンド発行装置１０１Ｂとに、双方向通信可能に接続されている。コマンド発行装置１０１Ａ、１０１Ｂは、ホスト装置またはホスト計算機と呼んでもよい。

ストレージシステム３０は、その可用性を高めるべく、複数の（例えば２個の）クラスタ５０Ａ、５０Ｂを備えている。「第１クラスタ」の例であるクラスタ５０Ａと「第２クラスタ」の例であるクラスタ５０Ｂとは、同一構成であってよい。フェイルオーバと無関係な構成については、各クラスタ５０Ａ、５０Ｂ間で異なっていてもよい。

以下クラスタの構成を、クラスタ５０Ａを中心に説明する。クラスタ５０Ａは、例えば、一つ以上の（通常は複数の）ＦＯＳ３１１Ａ、３１２Ａと、ＦＯＳ３１１Ａ、３１２Ａが動作する仮想マシンを制御するハイパバイザ３１３Ａと、ブロック制御部３１４Ａと、障害監視部４３Ａを備える。障害監視部４３Ａは、クラスタ内に複数存在し、監視対象のハードウェアが予め決められている。各ハードウェアは少なくとも一つの障害監視部４３Ａにより管理される。 一方のクラスタ５０Ａの障害監視部４３Ａと他方のクラスタ５０Ｂの障害監視部４３Ｂとはパスで接続されていてもよい。ブロック制御部３１４は障害監視部４３間のパスを通じて情報をやりとりすることもある。

ＦＯＳ３１１Ａ、３１２Ａは、ファイルインターフェースを有するＯＳであり、ハイパバイザ３１３Ａにより作成され管理される仮想マシン上で動作する。ＦＯＳとしては、例えばＮＡＳ、検索システム、サーバ上で動作する他のＯＳ等を挙げることができる。以下の説明では、例えばＮＡＳのように構成されるＦＯＳ３１１Ａを中心に説明する。

ハイパバイザ３１３Ａは、複数の仮想マシンを管理することができる。ハイパバイザ３１３Ａは、各仮想マシン上で動作するＦＯＳ３１１Ａを管理する。

ブロック制御部３１４Ａは、ディスクデバイス３４に対するデータの読み書き等を制御する。ブロック制御部３１４Ａは、ブロックインターフェースを有し、ブロックアクセス要求を発行するコマンド発行装置１０１Ａと双方向通信可能に接続されている。ブロック制御部は、ブロックストレージを制御するためのコンピュータプログラムであり、ブロックストレージマイクロ制御と呼ぶこともできる。

第１クラスタ５０Ａのブロック制御部３１４Ａと第２クラスタ５０Ｂのブロック制御部３１４Ｂとは、接続部４２を介して双方向通信可能に接続されている。ブロック制御部は各クラスタにそれぞれ個別に設けられているかのように見えるが、ブロック制御部３１４Ａとブロック制御部３１４Ｂとは接続部４２で接続されて情報を共有しており、全体としては、クラスタ５０Ａ、５０Ｂ間に跨がる一つのブロック制御部３１４であると見ることができる。

ストレージシステム３０は、そのハードウェア資源として、例えば、マイクロプロセッサ３１、メモリ３２、ディスクデバイス３４、ＨＢＡ（Host Bus Adapter）の通信ポート３５、ＮＩＣ（Network Interface Card）の通信ポート３６を備える。ハードウェア資源は、各クラスタ５０Ａ、５０Ｂに分配されている。さらに、ハードウェア資源のうち、予め設定される所定量のハードウェア資源は、ブロック制御部３１４に優先的に割り当てられており、その他のハードウェア資源はハイパバイザ３１３Ａ、３１３Ｂを介して各ＦＯＳ３１１Ａ、３１１Ｂに分配されている。

ファイルインターフェースからのリードコマンドおよびライトコマンドも最終的にはアドレス変換されて、ブロックアクセス要求に変換される。全てのデータは、ディスクデバイス３４内にブロックデータとして記憶されている。従って、ファイルインターフェースの要求するデータも、ブロック制御部３１４Ａが実行するブロックアクセス要求によってディスクデバイス３４に読み書きされる。

このように、リード要求処理およびライト要求処理は、いずれも最終的にはブロック制御部３１４に集まって処理される。高い信頼性を要求されるブロック制御部３１４は、各クラスタ５０Ａ、５０Ｂに跨がって設けられており、ユニファイドストレージシステムの根幹部分を形成する。そこで、本実施例では、各クラスタ５０Ａ、５０Ｂの障害監視も、ブロック制御部３１４で行う。

ストレージシステム３０のブロック制御部３１４は、前述のとおり高信頼性を実現しており、３６５日２４時間の常時稼働が前提である。従って、もしブロック制御部３１４が障害になる場合、ストレージシステム３０の全体が障害となり、ストレージシステム３０は停止する。

ここで本実施形態において障害監視の対象とする「障害」には、命令を全く実行できなくなるハードウェア障害を含まない。命令の実行が不可能となる障害を監視対象から外すことで、本実施形態では、最も信頼性が高く、最後まで動作し続ける可能性の高いブロック制御部３１４がいわばクォーラムの代わりを務めて、ストレージシステム３０の障害を集約して管理する。

このように構成される本実施形態では、障害監視用に特別な外部装置を用いずに、障害を管理することができる。また本実施形態では、障害監視用の外部装置を設けないため、外部装置とストレージシステムとを接続線で接続する必要がない。本実施形態では、第１クラスタ５０Ａのブロック制御部３１４Ａと第２クラスタ５０Ｂのブロック制御部３１４Ｂを内部直結バスとして構成される接続部４２で接続するため、接続に要するコストを低減できる。さらに、本実施形態では、断線やケーブルの抜けなどの障害が生じるおそれもなく、信頼性を向上できる。

本実施形態では、内部直結バスを用いた処理により、いわゆるSplitBrain状態の発生を防止し、一方のクラスタ内で或るＦＯＳが障害で停止した場合に、他方のクラスタ内のＦＯＳにフェイルオーバさせることができる。

本実施形態では、ユニファイドストレージシステムの根幹を成すブロック制御部３１４にハードウェア資源を優先的に割り当てて、ブロック制御部３１４による必要最低限の動作が常に可能であるようにしている。ブロック制御部３１４に対するハードウェア資源の優先的な割当てと、ブロック制御部３１４による障害の集約的な管理とが結合し、ストレージシステム３０内の障害を常時監視することができる。

＜システム構成の概要＞
図２は、ストレージシステムを含む計算機システムのハードウェア構成の例を示す説明図である。

計算機システムは、ストレージシステム３０と、ストレージシステム３０を利用するコマンド発行装置１０１Ａ、１０１Ｂと、ストレージシステム３０およびコマンド発行装置１０１Ａ、１０１Ｂを管理する管理装置２０とを含む。ストレージシステム３０は複数設けられてもよい。なお、ストレージシステム３０は、ストレージ装置、ストレージサブシステム、ユニファイドストレージシステムと呼ぶこともできる。

コマンド発行装置１０１Ａ、１０１Ｂは、ストレージシステム３０を利用する計算機である。コマンド発行装置１０１Ａ、１０１Ｂは、例えば、キーボード等の入力デバイス、ディスプレイ等の出力デバイス、ＣＰＵ（Central Processing Unit）、メモリ、ホストバスアダプタ（ＨＢＡ）またはネットワークインターフェースアダプタ（ＮＩＣ）などを備えている。

一方のコマンド発行装置１０１Ａは、ストレージシステム３０の有する論理的な記憶資源にアクセスするためのブロックコマンドを発行する計算機である。コマンド発行装置１０１Ａは、ブロックコマンド発行装置と呼ぶこともできる。

他方のコマンド発行装置１０１Ｂは、ストレージシステム３０に対してファイルコマンドを発行する計算機である。コマンド発行装置１０１Ｂは、ファイルコマンド発行装置と呼ぶこともできる。コマンド発行装置１０１Ｂは、ファイルコマンドを発行することで、ファイルへのデータ書き込み、ファイルからのデータ読み出し、ファイルの生成または消去を、ストレージシステム３０に指示する。

ブロックコマンド発行装置１０１Ａは、ブロックインターフェースであるＦＣ（FibreChannel）またはｉＳＣＳＩ（internet Small Computer System Interface）等を備えている。ブロックコマンド発行装置１０１Ａは、通信ネットワークＣＮ１を介して、ストレージシステム３０の有するＨＢＡ３５Ａ、３５Ｂと通信する。

ファイルコマンド発行装置１０１Ｂは、ファイルインターフェースであるＮＦＳ（Network File System）またはＣＩＦＳ（Common Internet File System）等を備えている。ファイルコマンド発行装置１０１Ｂは、通信ネットワークＣＮ２を介して、ストレージシステム３０の有するＮＩＣ３６Ａ、３６Ｂと通信する。

コマンド発行装置１０１Ａ、１０１Ｂは、例えば、サーバ、パーソナルコンピュータ、携帯情報端末、携帯電話（いわゆるスマートフォンを含む）、プリンタ、デジタルカメラ、デジタルビデオカメラ等のように構成することも可能である。

管理装置２０は、ストレージシステム３０の記憶領域の構成を管理する。管理装置２０は、例えば、入力デバイス２１０、出力デバイス２２０、ＣＰＵ２３０、メモリ２４０、ネットワークアダプタ２５０、ディスクドライブ２６０等を備える。

入力デバイス２１０は、管理装置２０を操作する管理者等からの入力を受け付ける手段であり、例えば、キーボード、音声入力装置、タブレット装置等で構成可能である。出力デバイス２２０は、管理者に管理装置２０の状態および設定項目等を表示する手段であり、例えば、ディスプレイ装置、音声出力装置、プリンタ等で構成可能である。

ＣＰＵ２３０は、ディスクドライブ２６０に格納されている管理コンピュータプログラムをメモリ２４０に読み込み、その管理コンピュータプログラムに基づいて、ストレージシステム３０に対する管理処理を実行する。以下、コンピュータプログラムをプログラムと略する場合がある。メモリ２４０は、例えばＲＡＭ等で構成され、プログラム、データ等を格納する。

ネットワークアダプタ２５０は、コマンド発行装置１０１Ａ、１０１Ｂ、ストレージシステム３０と、管理ネットワークＣＮ３を介して通信する。管理ネットワークＣＮ３は、例えばＥｔｈｅｒｎｅｔ（登録商標）等で構成される。ディスクドライブ２６０は、例えばハードディスク装置、フラッシュメモリデバイス等の記憶装置から構成され、データおよびプログラムを格納する。

ストレージシステム３０の構成を説明する。ストレージシステム３０は、ブロックコマンドおよびファイルコマンドのいずれも同時に処理可能なユニファイドストレージシステムとして構成されており、複数のクラスタ５０Ａ、５０Ｂを備える。各クラスタ５０Ａ、５０Ｂは、それぞれコントローラボード４１Ａ、４１Ｂを有する。ストレージシステム３０の構成において、添え字の「Ａ」または「Ｂ」は、所属先のクラスタを示す。所属先のクラスタを特に区別しない場合、添え字を取って説明する。

ストレージシステム３０は、ディスクデバイス３４に設定された記憶領域にデータを格納する。ストレージシステム３０は、その内部に、制御プロセッサであるＣＰＵ３１、メモリ３２、ディスクインターフェース３３、ＦＣインターフェースであるＨＢＡ３５（ＨＢＡターゲットであり、ホストアダプタとも言う）、ＬＡＮインターフェースであるＮＩＣ３６、管理用インターフェース３７等を備えている。

ＣＰＵ３１、メモリ３２、ＨＢＡ３５、ＮＩＣ３６およびディスクインターフェース３３は、相互にバス３８を介して接続されている。バス３８は、例えばＰＣＩ−ＥＸであるが、スイッチからバス３８を構成してもよい。

ＣＰＵ３１は、メモリ３２に格納されている各種プログラムおよびプログラムモジュールを実行する演算処理装置である。ＣＰＵ（制御プロセッサ）３１は、ディスクデバイス３４を用いて構成される論理的記憶領域へのデータ入出力等を制御する。

メモリ３２は、いわゆる内部記憶装置であり、不揮発性メモリおよび揮発性メモリを含んでいる。不揮発性メモリは、ＣＰＵ３１で動作するプログラムおよび構成情報等を格納する。揮発性メモリは、演算処理結果を一時的に格納する。

メモリ３２内の不揮発性メモリは、例えば、ハードディスク、フラッシュメモリ等で構成することができる。メモリ３２は、さらにキャッシュメモリ領域および共有メモリ領域を備える。キャッシュメモリ領域は、ディスクデバイス３４に読み書きされるデータを一時的に格納する。共有メモリ領域は、ストレージシステム３０の構成情報およびディスクデバイス３４の構成情報等を格納する。

障害監視部４５は、クラスタ５０内の各コンポーネント（ハードウェア）３１〜３３、３５〜３７に接続されており、各ハードウェアでの障害発生を監視するためのユニットである。障害監視部４５は、障害の発生を検知すると、プロセッサ３１に障害が生じたハードウェアを報告する。

ディスクインターフェース３３は、ディスクデバイス３４とメモリ３２等との間のデータ送受信を担当する。

ディスクデバイス３４は、例えば、ハードディスクデバイス、半導体メモリデバイス、光ディスクデバイス、光磁気ディスクデバイス等のデータを読み書き可能な種々の記憶装置を利用可能である。ハードディスクデバイスを用いる場合、例えば、ＦＣ（Fibre Channel）ディスク、ＳＣＳＩ（Small Computer System Interface）ディスク、ＳＡＴＡディスク、ＳＡＳ（Serial Attached SCSI）ディスク等を用いることができる。

また、例えば、ディスクデバイス３４として、フラッシュメモリ、ＦｅＲＡＭ（Ferroelectric Random Access Memory）、ＭＲＡＭ（MagnetoresistiveRandom Access Memory）、相変化メモリ（Ovonic Unified Memory）、ＲＲＡＭ（登録商標）等の種々の記憶装置を用いることもできる。さらに、例えば、フラッシュメモリデバイスとハードディスクデバイスのように、種類の異なるディスクデバイスをストレージシステム３０内に混在させる構成でもよい。

一つまたは複数のディスクデバイス３４の有する記憶領域をグループ化し、そのグループ化された記憶領域から固定長または可変長で記憶領域を切り出すことで、論理的記憶領域である論理ボリュームを生成できる。その論理ボリュームには、主としてユーザデータが記憶される。なお、ＣＰＵ３１が実行するプログラムの全部または一部を、ディスクデバイス３４内に格納してもよい。

本実施例のストレージシステム３０は、いわゆるユニファイドストレージシステムとして構成されているため、ブロックコマンドを処理するためのホスト側インターフェース（ＨＢＡ）３５と、ファイルコマンドを処理するためのホスト側インターフェース（ＮＩＣ）３６の両方を備えている。

ＨＢＡ３５は、ネットワークＣＮ１を介してブロックコマンド発行装置１０１Ａに接続されており、複数の通信ポートを有する。ＨＢＡ３５は、ブロックコマンド発行装置１０１Ａとの間でコマンドおよびデータを授受する。ネットワークＣＮ１は、例えばＦＣ、イーサネット（登録商標）等である。

ＮＩＣ３６は、ネットワークＣＮ２を介してファイルコマンド発行装置１０１Ｂに接続されており、複数の通信ポートを有する。ＮＩＣ３５は、例えばＮＦＳまたはＣＩＦＳ等のプロトコルによって、ファイルコマンド発行装置１０１Ｂとの間でコマンドおよびデータを授受する。ネットワークＣＮ２は、例えばＬＡＮ等のように構成される。

コマンド発行装置１０１Ａ、１０１Ｂは、管理ネットワークＣＮ３を介して、管理装置２０に接続されている。コマンド発行装置１０１Ａ、１０１Ｂは、管理装置２０との間で、システム管理上必要なデータ（管理情報）を送受信する。

ストレージシステム３０は、例えばＬＡＮのように構成される保守管理用インターフェース３７を備える。保守管理用インターフェース３７は、ＣＰＵ３１と接続される。ＣＰＵ３１は、ストレージシステム３０内のＣＰＵ３１以外の部位において障害が起こった場合、その障害に関する情報を保守管理用インターフェース３７を介して、管理装置２０へ報告することができる。
＜クラスタ構成＞

ストレージシステム３０の有するクラスタ構成について説明する。ストレージシステム３０は、可用性を高めるために、複数のクラスタ５０Ａ、５０Ｂを備える。

ストレージシステム３０内には、クラスタ５０Ａ、５０Ｂを制御するためのコントローラボード４１Ａ、４１Ｂが設けられている。一方のコントローラボード４１Ａは、一方のクラスタ５０Ａを制御するもので、第１コントローラボードと呼ぶこともできる。他方のコントローラボード４１Ｂは、他方のクラスタ５０Ｂを制御するもので、第２コントローラボードと呼ぶこともできる。

一方のコントローラボード４１Ａ内のＣＰＵ３１Ａと他方のコントローラボード４１Ｂ内のＣＰＵ３１Ｂとは、接続部４２を介して双方向通信可能に接続されている。接続部４２は、例えば、専用線のバス、またはスイッチ等として構成される。ここでは、ＣＰＵ間を直接通信する専用パスとする。

一方のＣＰＵ３１Ａは、接続部４２を介して他方のＣＰＵ３１Ｂにアクセスすることができる。同様に、他方のＣＰＵ３１Ａは、接続部４２を介して一方のＣＰＵ３１Ａにアクセスすることができる。

各クラスタ５０Ａ、５０Ｂは、それぞれコントローラボード４１、ＨＢＡ３５、ＮＩＣ３６、ディスクインターフェース３３、保守管理用インターフェース３７を備える。上述の通り、クラスタ５０Ａに属する要素には「Ａ」が添えられており、クラスタ５０Ｂに属する要素には「Ｂ」が添えられている。

クラスタ５０Ａとクラスタ５０Ｂは、可用性を高めるためにクラスタ構成を組む。例えば、ファイルシステムを使用するＯＳであるＦＯＳを例に挙げて、可用性の向上について説明する。クラスタ５０Ａの或るＦＯＳとクラスタ５０Ｂの他のＦＯＳとで予めクラスタ構成を組んでおく。第１クラスタ５０Ａが正クラスタであるとする。

正クラスタ５０Ａ側のＦＯＳに障害が発生した場合、副クラスタ５０ＢのＦＯＳへのフェイルオーバ処理が実行される。フェイルオーバ処理では、副クラスタ５０ＢのＦＯＳが、正クラスタ５０ＡのＦＯＳの処理を肩代わりして、ファイルコマンド発行装置１０１にサービスを提供し続ける。本実施例のストレージシステム３０は、クラスタ構成を取ることで信頼性を高めている。障害の検知方法等は後述する。

図３は、各ＣＰＵ３１内のソフトウェア構成の概略を示す。ＣＰＵ３１は、所定プログラムを実行することで、ＦＯＳ３１１、３１２、３１５と、ハイパバイザ３１３と、ブロック制御部３１４とを実現する。

ハイパバイザ３１３Ａは、ファイルインターフェースＯＳである３１１Ａ、３１２Ａ、３１５Ａを、クラスタ５０Ａ内において仮想化する。ハイパバイザ３１３Ａからはブロック制御部３１４Ａが見える。同様に、ハイパバイザ３１３Ｂは、ファイルインターフェースＯＳである３１１Ｂ、３１２Ｂ、３１５Ｂをクラスタ５０Ｂ内において仮想化する。ハイパバイザ３１３Ｂからはブロック制御部３１４Ｂが見える。

ブロック制御部３１４は、クラスタ５０Ａとクラスタ５０Ｂのそれぞれに搭載されているが、クラスタ５０Ａとクラスタ５０Ｂに跨がる一つの共通した制御として動作する。各ブロック３１４Ａ、ブロック制御部３１４Ｂは、それぞれが使用するメモリ内の制御情報が常に相手方のブロック制御の使用する制御情報と同一となるように管理している。

従って、一方のクラスタ５０Ａのブロック制御部３１４Ａは、他方のクラスタ５０Ｂ内でのファイルインターフェースからの要求およびブロックインターフェースからの要求を処理することができる。同様に、他方のクラスタ５０Ｂ内のブロック制御部３１４Ｂは、一方のクラスタ５０Ａ内でのファイルインターフェースからの要求およびブロックインターフェースからの要求を処理することができる。このように各クラスタ５０Ａ、５０Ｂ内のブロック制御部３１４Ａ、３１４Ｂは一つの共通した制御として動作するため、異なるクラスタ内の、ファイルシステムインターフェースからの要求、および、ブロックインターフェースからの要求を処理することができる。

ブロック制御部３１４Ａ、３１４Ｂは全体として一つの制御として振る舞うが、接続部４２を経由して処理を行うと、少なからずオーバヘッドが増加する。従って、原則的には、要求を受けたクラスタ内のブロック制御がその要求を処理する。つまり、クラスタ５０Ａで受けた要求はブロック制御部３１４Ａが処理し、クラスタ５０Ｂで受けた要求はブロック制御部３１４Ｂが処理する。

ブロック制御部３１４は、ブロックインターフェースによってサービスを提供する機能の一例である。ファイルインターフェースによってサービスを提供する機能の例としては、ファイルシステム、検索システム、サーバ上で動作するＯＳ等がある。

各ＦＯＳ３１１、３１２、３１５及びブロック制御部３１４は、制御プロセッサであるＣＰＵ３１のコア上で動作する。実際には、ＯＳはプログラムであるため、メモリ３２上に置かれており、ＣＰＵ３１がそのプログラムを読み込んで動作する。図３では、説明の便宜上、ＣＰＵコアの上に各ＯＳを記載している。１個のＣＰＵを搭載するパッケージは、通常複数のコアを含む。障害等に対応するための冗長性をもたせるため、パッケージは２枚単位で増減する。つまり、最小構成におけるパッケージ数は２枚である。

プロセッサコアの使い方として、同一パッケージに同種類のＯＳを集中させてもよいし、それぞれ異なるパッケージに同種類のＯＳを分散させてもよい。性能と可用性のいずれを優先するかによって、設計は異なる。
＜仮想化プログラム（ハイパバイザ）＞

ハイパバイザ３１３もソフトウェアであるため、メモリ３２上に格納されている。ハイパバイザ３１３は各ＯＳ３１１、３１２、３１５上でそれぞれ動作するため、コアに対応するものではない。図３では、或る制御プロセッサ３１に、すなわちＣＰＵパッケージに複数のコアが設けられており、ＦＯＳ３１１、検索システム３１２、サーバＯＳ３１５、ブロック制御部３１４がコア毎に載っている。

ハイパバイザ３１３は、ＦＯＳ３１１Ａ、検索システムＯＳ３１２およびサーバＯＳ３１５のそれぞれに組み込まれている。ハイパバイザ３１３上で、ＦＯＳ３１１と検索システム３１２およびサーバＯＳ３１５を動作させる。

図３の例では、一方のＣＰＵ３１Ａにおいて、各コアにＦＯＳ３１１Ａ、３１２Ａ、３１５Ａ、ハイパバイザ３１３Ａ、ブロック制御部３１４Ａが搭載されている。他方のＣＰＵ３１Ｂにおいて、各コアにＦＯＳ３１１Ｂ、３１２Ｂ、３１５Ｂ、ハイパバイザ３１３Ｂ、ブロック制御部３１４Ｂが搭載されている。なお、ハイパバイザ３１３を複数のコアのうち特定のコアで動作させてもよい。

本実施例では、ストレージシステム３０の有するハードウェア資源のうち所定のハードウェア資源を優先的にブロック制御部３１４に割り当てる。そして、余ったハードウェア資源をハイパバイザ３１３を介して各ＦＯＳ３１１、３１２、３１５に割り当てる。以下の説明では、便宜上、ＦＯＳ３１１、３１２、３１５を「ＦＯＳ３１１等」と表現する場合がある。

本実施例では、ハードウェア資源を論理分割して、それら分割したハードウェア資源を用いて仮想マシンを生成する。各仮想マシンの生成および消滅はハイパバイザ３１３で管理している。仮想マシン上でＦＯＳ３１１等が稼働し、ＦＯＳ３１１等はファイルコマンド発行装置１０１Ｂから発行されるファイルコマンドを処理する。
＜メモリ＞

メモリ３２は、不揮発性メモリ、揮発性メモリ等のように特徴が異なる複数種類のメモリが混在している場合がある。本実施例では、冗長性を保つために、メモリを２重化している。メモリ３２には、構成情報、制御情報、キャッシュデータ等が記憶される。構成情報としては、例えばストレージシステム３０の構成を管理するための情報がある。制御情報としては、例えば、要求コマンドとアドレスマッピング情報等を管理するための情報がある。キャッシュデータとしては、コマンド発行装置から受領したライトデータ、ディスクデバイス３４から読み出したリードデータがある。

制御情報（または構成情報）を格納するメモリと、データを格納するメモリ（キャッシュメモリ等）とは、それぞれの使用する領域が論理的または物理的に分かれていればよく、メモリの種類は問わない。制御情報を格納するメモリとデータを一時的に格納するメモリとは、ブロック制御部３１４、ＦＯＳ３１１等、ハイパバイザ３１３のそれぞれが使用する領域が物理的または論理的に分かれていればよい。

図４に、メモリ３２の割り当て例を示す。以下に示す図面では、関連するクラスタの区別を示す「Ａ」、「Ｂ」の添え字を省略する。例えば、図４に示すメモリ３２の記憶構成は、クラスタ５０Ａのメモリ３２Ａの構成とクラスタ５０Ｂのメモリ３２Ｂの構成の両方を示している。他の図面（図５〜図８）についても同様である。

メモリ３２は、物理的に分かれた複数のメモリから構成される。メモリ３２は、制御情報を格納するメモリ３２１と、データを格納するメモリ３２２とを備える。各クラスタ５０Ａ、５０Ｂのメモリ３２Ａ、３２Ｂは、それぞれ図４に示す構成を備える。図４では、クラスタを区別せずにメモリの割り当て例を示している。

メモリ３２１、３２２のメモリ空間は、それらメモリ３２１、３２２を使用するＯＳ毎に分割されている。各ＯＳは自らに割り当てられたメモリ空間のみ認識することができ、他のＯＳに割り当てられたメモリ空間を認識することができない。以下の説明では、メモリ空間をメモリ領域またはメモリと呼ぶことがある。

例えば、ＦＯＳ３１１Ａは、制御メモリ３２１のうちＦＯＳ３１１に割り当てられたメモリ空間３２１１と、データメモリ３２２のうちＦＯＳ３１１に割り当てられたメモリ空間３２２１だけを認識しており、それらメモリ空間３２１１、３２２１のみを使用することができる。同様に、ＦＯＳ３１２は、制御メモリ３２１のうちＦＯＳ３１２に割り当てられたメモリ空間３２１２と、データメモリ３２２のうちＦＯＳ３１２に割り当てられたメモリ空間３２２２のみを認識して使用することができる。制御メモリ３２１のＦＯＳ用メモリ空間３２１１、３２１２には、ＦＯＳ３１１、３１２を実現するためのコンピュータプログラムが記憶されている。なお、ＦＯＳ３１５については記載を省略する。

ハイパバイザ３１３は、制御メモリ３２１のうちハイパバイザ３１３に割り当てられたメモリ空間３２１３と、データメモリ３２２のうちハイパバイザ３１３に割り当てられたメモリ空間３２２３のみを認識して使用する。

ブロック制御部３１４は、制御メモリ３２１のうちブロック制御部３１４に割り当てられたメモリ空間３２１４と、データメモリ３２２のうちブロック制御部３１４に割り当てられたメモリ空間３２２４のみを認識して使用する。

メモリ３２は、異なるＯＳが共同で使用する領域も含む。制御メモリ３２１のうちメモリ空間３２１５は、ハイパバイザ３１３とＦＯＳ３１１等とが認識しており、ハイパバイザ３１３とＦＯＳ３１１等とが共有して使用する。制御メモリ３２１のうちメモリ空間３２１６は、ハイパバイザ３１３とブロック制御部３１４とが認識しており、ハイパバイザ３１３とブロック制御部３１４とで共有して使用する。

制御メモリ３２１のうちメモリ空間３２１７は、ＦＯＳ３１１等がフェイルオーバする際に参照するための情報を格納する。例えば、フェイルオーバ用の情報には、例えばＦＯＳの担当するＬＵ番号、ＬＵにマウント中であるか否かを示す情報等を含む。

このように、共有メモリ領域を設けることで、ＦＯＳ３１１等とハイパバイザ３１３の間、ハイパバイザ３１３とブロック制御部３１４の間で、所定の情報を相手方に伝達することができる。さらに、クラスタ５０Ａ、５０Ｂの間でも、情報を伝達できる。伝達方法は後述する。

共有メモリ領域についてさらに説明する。例えば、ＦＯＳが使用する領域は、通常の場合、そのＦＯＳしかアクセスできない領域である。しかし、ＦＯＳが使用するメモリ領域の一部をハイパバイザ３１３がアクセスできるように許可することで、ＦＯＳ３１１等とハイパバイザ３１３とが情報を共有するための領域を生成できる。

同様にして、ハイパバイザ３１３の使用するメモリ領域の一部にブロック制御部３１４からのアクセスを許可するか、または、ブロック制御部３１４の使用するメモリ領域の一部にハイパバイザ３１３からのアクセスを許可することで、ブロック制御部３１４とハイパバイザ３１３との間で情報を共有するための領域を設けることができる。

制御メモリ３２１のうちブロック制御部３１４に割り当てられたブロック制御用メモリ空間３２１４は、プロセッサ３１に読み込まれて実行される各種プログラム、論理ボリュームの設定に関する構成情報、および、プールの設定に関するプール情報を格納する。データメモリ３２２のうちブロック制御部３１４に割り当てられたブロック制御用メモリ空間３２２４は、転送データ等を格納する。

図５を用いて、制御プロセッサ（ＣＰＵ）３１に読み込まれて実行される各種プログラムの例を説明する。ブロック制御用メモリ空間３２１４は、例えば、コマンド制御プログラムＰ１０、構成制御プログラム、障害統合管理プログラムＰ１２、障害検出プログラムＰ１３、障害報告プログラムＰ１４、障害復旧プログラムＰ１５を記憶している。

コマンド制御プログラムＰ１０は、コマンド発行装置１０１Ａ、１０１Ｂ、または、管理装置２０からのコマンドを解釈し、そのコマンドに規定された処理を実行するためのプログラムである。

構成制御プログラムＰ１１は、ストレージシステム３０の構成を設定したり、構成情報を更新したりするための処理を実行するプログラムである。なお、図５では図示を省略しているが、ディスクＩ／Ｏプログラムは、ディスクデバイス３４へのデータ入出力を制御するプログラムである。

障害統合管理プログラムＰ１２は、各ハードウェアで発生する障害の情報を統合して管理し、障害処理の方針を決定するためのプログラムである。

障害検出プログラムＰ１３は、障害の発生を検知するためのプログラムである。障害検出プログラムＰ１３を用いることで、ブロック制御部３１４とハイパバイザ３１３とは、互いの生死を監視する。ハイパバイザ３１３とＦＯＳ３１１等も、障害検出プログラムＰ１３を用いて互いの生死を監視する。障害検出プログラムＰ１３は、ハードウェア障害だけでなく、ソフトウェアの障害も検出できる。

障害報告プログラムＰ１４は、障害が発生した場合に、ブロック制御部３１４とハイパバイザ３１３とＦＯＳ３１１等とが互いに報告するためのプログラムである。障害復旧プログラムＰ１５は、障害から復旧するための処理を実行するプログラムである。

ブロック制御用メモリ空間３２１４は、制御のための管理情報も記憶する。制御のための管理情報としては、例えば、ＬＵ管理情報Ｔ１０、アドレス管理テーブルＴ１１、ハードウェア資源管理テーブルＴ１２、障害管理テーブルＴ１３がある。

構成情報は、例えば仮想デバイス、論理デバイス、プール階層、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）グループ等の、ストレージシステム３０の環境設定に必要な情報である。構成情報として、例えば論理デバイス（ＬＵ：Logical Unit）管理テーブルＴ１０と、アドレス管理テーブルＴ１１がある。

論理デバイス管理テーブルＴ１０は、論理ボリュームである論理デバイスがどのＲＡＩＤグループから切り出されており、そのＲＡＩＤグループを構成するディスクデバイス３４はどれであるか等を管理する。さらに、論理デバイス管理テーブルＴ１０は、論理デバイスのサイズ、使用量、その論理デバイスを使用するコマンド発行装置等に関する情報も管理することができる。

アドレス管理テーブルＴ１１は、例えば、ターゲットデバイスと論理デバイスのマッピング情報、論理デバイスと仮想デバイスのマッピング情報、仮想デバイスと物理デバイスのマッピング情報を格納する。

ストレージシステム３０は、アドレス管理テーブルＴ１１を参照することによって、ターゲットデバイスのアドレスがどの論理デバイスのどのアドレスに対応するかを知ることができる。また、ストレージシステム３０は、論理デバイスのアドレスがどの仮想デバイスのどのアドレスに対応するかを知ることができる。さらに、ストレージシステム３０は、仮想デバイスのアドレスがどのＲＡＩＤグループに属しており、どの物理デバイスのどのアドレスに対応するかを知ることができる。

なお、データの実際の格納先は、ブロック制御部３１４が決定する。ブロック制御部３１４は、通常通りに、論理アドレスから変換された物理アドレスを有するディスクデバイス３４に、データを書き込むことができる。または、ブロック制御部３１４は、いわゆる容量仮想化を実現している場合、仮想デバイス（仮想論理ボリューム）に割り当てられる実ページを有するディスクデバイス３４内にデータを書き込む。

例えば、ブロック制御部３１４は、複数の論理デバイスを性能別にプールで階層管理し、仮想デバイスへのライト要求に応じて、プールされた論理デバイスの記憶領域（実ページ）を仮想デバイスの書込先アドレスに割り当てる。ブロック制御部３１４は、仮想デバイスに割り当てた実ページの所定アドレスに、ライトデータを書き込む。さらに、ストレージシステム３０が外部の他のストレージシステム（いわゆる外部ストレージシステム）の有するディスクデバイスを利用している場合もある。この場合、ブロック制御部３１４は、ブロックインターフェースまたはファイルインターフェースから受領したコマンドを外部ストレージシステムにアクセスするためのコマンドに変換し、外部ストレージシステムのディスクデバイスにデータを読み書きする。

ハードウェア資源管理テーブルＴ１２は、ストレージシステム３０の有するハードウェアごとに、稼働中であるか障害閉塞中であるかの状態と、そのハードウェアを使用しているＦＯＳ３１１等またはブロック制御部３１４を特定する。ハードウェア資源管理テーブルＴ１２の詳細は、図６で説明する。

以上のように、ブロック制御部３１４は、ハイパバイザ３１３上のＦＯＳ３１１等で使用するハードウェア資源から独立したハードウェア資源を使用する。

図５には、ハイパバイザ３１３が実行するプログラム等についても示されている。ハイパバイザ３１３の使用する制御メモリ３２１３は、障害を検出するプログラムＰ２３と、検出した障害を予め設定された所定の報告先に報告するプログラムＰ２４と、障害復旧プログラムＰ２５と、ハイパバイザ３１３の使用するハードウェア資源を管理するテーブルＴ２２を記憶する。障害復旧プログラムＰ２５は、ハイパバイザ３１３が、ブロック制御部３１４からの指示に従って障害処理を実行するためのプログラムである。

ＦＯＳ３１１等の使用する制御メモリ３２１１（または３２１２）は、障害を検出するプログラムＰ３３と、検出した障害を予め設定された所定の報告先に報告するプログラムＰ３４と、障害復旧プログラムＰ３５と、ＦＯＳ３１１等の使用するハードウェア資源を管理するテーブルＴ３２を記憶する。障害復旧プログラムＰ３５は、ブロック制御部３１４からの指示に従って障害処理を実行するためのプログラムである。

図６を用いて、ブロック制御部３１４の使用するハードウェア資源管理テーブルＴ１２の例を示す。ブロック制御部３１４は、ストレージシステム３０の有する全てのハードウェア資源を管理する。ブロック制御部３１４が、ストレージシステム３０の有する全てのハードウェア資源を把握しているため、それらハードウェア資源に生じる障害をブロック制御部３１４で集約管理することができる。

ハードウェア管理テーブルＴ１２は、例えば、プロセッサ管理テーブルＴ１２０、メモリ管理テーブルＴ１２１、ディスク管理テーブルＴ１２２、ポート管理テーブルＴ１２３を含む。

プロセッサ管理テーブルＴ１２０は、ストレージシステム３０の有するＣＰＵ３１を管理するテーブルであり、例えばリソース名と、詳細と、定義／未定義とを対応付けて管理する。「リソース名」には、ストレージシステム３０内のＣＰＵ３１を一意に特定できる名称（識別子、番号等も名称に含む。以下同じ）が記憶される。「詳細」は、リソース名で特定したＣＰＵの詳細を記憶する。詳細情報は、例えば、そのＣＰＵに含まれているコアを特定するための情報（例えばコア番号）である。「定義／未定義」とは、ブロック制御部３１４の使用する資源であるか否かを示す。ブロック制御部３１４の使用する資源である場合は「定義」が登録され、ブロック制御部３１４の使用しない資源である場合は「未定義」が登録される。

図６に示す例では、「ＣＰＵ１」および「ＣＰＵ２」は、ブロック制御部３１４に割り当てられているため、「定義／未定義」の欄には「定義」が登録されている。「ＣＰＵ３」はブロック制御部３１４に割り当てられていないため、「定義／未定義」の欄には「未定義」が登録されている。

なお、ブロック制御部３１４に割り当てられていない資源について「未定義」と登録するのではなく、具体的な割当て先を登録する構成でもよい。例えば、「ＣＰＵ３」がハイパバイザ３１３で使用されている場合、「定義／未定義」の欄には「ハイパバイザ」と登録する。同様に、「ＣＰＵ３」がＦＯＳ３１１に割り当てられている場合、「定義／未定義」の欄に「ＦＯＳ３１１」と登録する。

ブロック制御部３１４が、ハイパバイザ３１３およびＦＯＳ３１１等に割当て済の資源の情報を、ハイパバイザ３１３およびＦＯＳ３１１等から取得することで、ハードウェア資源管理テーブルＴ１２に具体的な割当て先を登録できる。

メモリ管理テーブルＴ１２１は、ストレージシステム３０の有するメモリ３２を管理するテーブルであり、例えば、リソース名と、アドレスと、定義／未定義とを対応付けて管理する。

「リソース名」には、メモリ３２をストレージシステム３０内で一意に特定するための名称が設定される。「アドレス」は、リソース名で特定されたメモリのアドレス空間（メモリ空間）を記憶する。「定義／未定義」には、メモリの各アドレス空間ごとに、ブロック制御部３１４に割り当てられているか否かを登録する。

図６の例では、メモリ「ＤＭＭ１」のアドレス０−１０００の領域は、ブロック制御部３１４が確保している。「ＤＭＭ１」のアドレス１００１−２０００の領域は、例えばＦＯＳ３１１等またはハイパバイザ３１３と共有しているものとする。

例えばＦＯＳ３１１は、ファイルコマンド発行装置１０１Ｂからリードコマンドまたはライトコマンドを受領すると、ＦＯＳ３１１は、ディスクデバイス３４へのデータ読み書きをブロック制御部３１４に依頼する。ＦＯＳ３１１がブロック制御部３１４に処理を依頼する場合にコマンドを変換し、ＦＯＳ３１１とブロック制御部３１４が共有するアドレスに、変換したコマンドを格納する。共有するアドレスには、ＦＯＳ３１１とブロック制御部３１４の両方がアクセス可能である。

なお、メモリ管理テーブルＴ１２１では、あるアドレス空間を共有しているか否か、誰と共有しているか、は管理していない。ブロック制御部３１４が使用可能であるかだけを「定義／未定義」の欄で管理する。

ディスク管理テーブルＴ１２２は、ストレージシステム３０の有するディスクデバイスを管理するテーブルであり、例えば、リソース名と、定義／未定義とを対応付けて管理している。「リソース名」は、ディスクデバイスをストレージシステム３０内で一意に特定するための名称を記憶する。「定義／未定義」には、リソース名で特定されたディスクデバイスがブロック制御部３１４に割り当てられているか否かを登録する。

ポート管理テーブルＴ１２３は、ストレージシステム３０の有する通信ポートを管理するテーブルである。上述の通り、本実施例のストレージシステム３０は、いわゆるユニファイドストレージシステムとして構成されており、ファイルコマンドを受け付けるポート（ＮＩＣ３６の通信ポート）と、ブロックコマンドを受け付けるポート（ＨＢＡ３５の通信ポート）を備えている。

ポート管理テーブルＴ１２３は、例えば、リソース名と、定義／未定義を対応付けて管理する。「リソース名」は、通信ポートを一意に特定するための名称を記憶する。「定義／未定義」は、リソース名で特定された通信ポートがブロック制御部３１４に割り当てられているかを登録する。

なお、図６では、ブロックコマンド用の通信ポートとファイルコマンド用の通信ポートを一つずつ示すが、実際にはブロックコマンド用の通信ポートとファイルコマンド用の通信ポートはそれぞれ複数ずつストレージシステム３０に設けられている。

ブロック制御部３１４は、ハードウェア管理テーブルＴ１２０〜Ｔ１２３の情報に基づいて、ブロック制御部３１４に割り当てられているハードウェア資源だけを管理するテーブルＴ１２４、Ｔ１２５を作成する。

例えば、ブロック制御用プロセッサ管理テーブルＴ１２４は、ブロック制御部３１４に割り当てられているプロセッサ資源だけを管理するテーブルであり、リソース名と、使用状態を対応付けて管理する。ブロック制御用プロセッサ管理テーブルＴ１２４は、プロセッサ管理テーブルＴ１２０に記憶されている情報に基づいて作成されている。

テーブルＴ１２４の「リソース名」は、ブロック制御部３１４に割り当てられているＣＰＵをストレージシステム３０内で一意に特定するための名称を記憶している。「使用状態」には、リソース名で特定したＣＰＵの使用状態が登録される。ブロック制御部３１４が正常に使用している場合は「使用中」と登録され、障害が発生している場合は「障害発生」、「閉塞処理中」等と登録される。

図６に示すブロック制御用プロセッサ管理テーブルＴ１２４によれば、ブロック制御部３１４には「ＣＰＵ１」と「ＣＰＵ２」が割り当てられており、ブロック制御部３１４は「ＣＰＵ１」および「ＣＰＵ２」の両方を正常に使用していることがわかる。

ブロック制御用メモリ管理テーブルＴ１２５は、ブロック制御部３１４に割り当てられているメモリだけを管理するテーブルであり、メモリ管理テーブルＴ１２１に基づいて作成される。ブロック制御用メモリ管理テーブルＴ１２５は、メモリをストレージシステム３０内で一意に特定する名称と、アドレスを対応付けて管理する。これにより、ブロック制御部３１４が使用可能な全てのメモリ領域（アドレス空間）が直ちに判明する。

図５では、ブロック制御部３１４の使用するハードウェア資源管理テーブルＴ１２をブロック制御用の制御メモリ空間３２１４に格納するかのように示すが、ハードウェア資源管理テーブルＴ１２のうちメモリ管理テーブルＴ１２１は、ブロック制御部３１４とハイパバイザ３１３とが共有するメモリ空間３２１６（図４）に格納するのが好ましい。ブロック制御部３１４とハイパバイザ３１３とでメモリ管理テーブルＴ１２１を共同使用するためである。なお、メモリ管理テーブルＴ１２１のうちハイパバイザ３１３と共同で使用する情報のコピーを共有メモリ空間３２１６に置く構成でもよい。

図７に、ハイパバイザ３１３が持つハードウェア資源管理テーブルＴ２２を示す。ハードウェア資源管理テーブルＴ２２は、例えば、プロセッサ管理テーブルＴ２２０、メモリ管理テーブルＴ２２１、仮想資源管理テーブルＴ２２２を含む。プロセッサ管理テーブルＴ２２０およびメモリ管理テーブルＴ２２１は、ハイパバイザ３１３の使用する管理情報であるため、ハイパバイザ用のメモリ領域３２１１（図５）に格納される。

プロセッサ管理テーブルＴ２２０は、ハイパバイザ３１３に割り当てられたＣＰＵ３１を管理するテーブルであり、リソース名と使用状態とを対応付けて管理する。「リソース名」には、ＣＰＵをストレージシステム３０内で一意に特定する名称が登録される。「使用状態」には、リソース名で特定したＣＰＵの使用状態（例えば使用中、閉塞処理中）を登録する。

メモリ管理テーブルＴ２２１は、ハイパバイザ３１３に割り当てられているメモリ３２を管理するテーブルであり、例えば、リソース名と、アドレスと、使用状態と、使用者を対応付けて管理する。

「リソース名」には、ストレージシステム３０でメモリを一意に特定するための名称を登録する。「アドレス」には、リソース名で特定したメモリのアドレス空間（メモリ空間）を登録する。「使用状態」には、メモリのアドレス空間毎の使用状態（例えば使用中、閉塞処理中）を登録する。「使用者」には、メモリのアドレス空間毎の使用者（ハイパバイザ、ＦＯＳ）を登録する。

ここで、本実施例では、ブロック制御部３１４に対して、ストレージシステム３０の有するハードウェア資源を優先的に割当て、残ったハードウェア資源をハイパバイザ３１３およびＦＯＳ３１１等に割り当てる。

上述の通り、ブロック制御部３１４は、ストレージシステム３０内の全てのハードウェア資源（ＣＰＵ、メモリ、ディスク、ポート）をハードウェア資源管理テーブルＴ１２で管理している。ストレージシステム３０の有する全ハードウェア資源のうち、ブロック制御部３１４に割り当てたハードウェア資源には「定義」を設定する。そこで、ブロック制御部３１４の持つハードウェア資源管理テーブルＴ１２に登録されているハードウェア資源のうち「未定義」の設定されているハードウェア資源が、ハイパバイザ３１３の持つハードウェア資源管理テーブルＴ２２に登録される。

図７のハードウェア資源管理テーブルＴ２２では、通信ポートを管理するためのポート管理テーブルの記載を省略している。なお、図７では、ディスクを管理するためのディスク管理テーブルを省略している。

なお、メモリ管理テーブルＴ２２１において、アドレス「１００１〜２０００」のアドレス空間は、ブロック制御部３１４との共有領域であるが、ここではハイパバイザ３１３の領域として管理する。

ハイパバイザ３１３は、ＦＯＳ３１１等にハードウェア資源を仮想化して見せる。このため、ハイパバイザ３１３は、仮想資源管理テーブルＴ２２２に示すように、物理的に一つの「ＣＰＵ３」を、仮想的な複数のＣＰＵ（図中「ＶＣＰＵ」）として、ハイパバイザ３１３上で管理するＦＯＳ３１１等に割り当てる。ＣＰＵに物理的障害が発生した場合、仮想資源管理テーブルＴ２２２を参照することで、そのＣＰＵの物理的障害の影響が及ぶＦＯＳを特定することができる。図示の例では、「ＦＯＳ１」に対して仮想的なＣＰＵ「ＶＣＰＵ１」、「ＶＣＰＵ３」、「ＶＣＰＵ４」が割り当てられており、「ＦＯＳ２」に対して「ＶＣＰＵ２」が割り当てられている。

図８は、ＦＯＳが持つハードウェア資源管理テーブルＴ３２の例を示す。ハードウェア資源管理テーブルＴ３２は、ＦＯＳ専用のメモリ領域３２１２に格納されており、例えばプロセッサ管理テーブルＴ３２０と、メモリ管理テーブルＴ３２１を含む。

各ＦＯＳは、自らが使用できるハードウェア資源のみ管理する。ディスクおよび通信ポートを管理するためのテーブルは省略している。ハイパバイザ３１３と共有するメモリ領域については、ＦＯＳもそのメモリ領域を使用できるため、「使用状態」の欄に「使用中」と設定して管理する。
＜ハードウェア構成＞

図９に、ブロック制御部３１４と、ブロック制御部３１４以外のハイパバイザ３１３およびＦＯＳ３１１等とが、ストレージシステム３０の有するハードウェア資源をそれぞれ確保する様子を示す。

図９では、ブロック制御部３１４は、クラスタ間を跨がる一つのブロック制御として示している。ハイパバイザ３１３およびＦＯＳ３１１等は、複数のクラスタ５０Ａ、５０Ｂにそれぞれ設けられている。図９では、便宜上、ＦＯＳを一つだけ示すので、以下、ＦＯＳ３１１と呼ぶ。

上述の通り、本実施例では、ユニファイドストレージシステム３０の根幹を成すブロック制御部３１４に、ブロックコマンドの処理および障害管理に必要な最低限度以上のハードウェア資源を優先的に割当て、残りのハードウェア資源をハイパバイザ３１３を介してＦＯＳ３１１に分配する。

ハイパバイザ３１３は、資源を論理的に分割する技術であるＬＰＡＲ（Logical PARtitioning）を使用して、ＦＯＳ３１１にハードウェア資源を割り当てる。ハードウェア資源としては、上述の通り、ＣＰＵ３１、メモリ３２、通信ポート３５および３６、障害監視用のハードウェア回路である障害監視部４３がある。

この例では、ブロック制御部３１４のみがディスク３４を使用しており、ハイパバイザ３１３およびＦＯＳ３１１はディスク３４を使用していない。ハイパバイザ３１３およびＦＯＳ３１１がディスク３４を使用する場合、ディスク３４も論理的に分割して割り当てられる。また、ディスクインターフェース３３は、ブロック制御部３１４のみが使用するため、ハイパバイザ３１３およびＦＯＳ３１１には割り当てられない。

図９では、ハードウェア資源に２種類のアルファベット文字を添えて、その属性を示している。第１のアルファベット文字は割当て先のプログラムを特定する。「Ｓ」はＦＯＳ、「Ｈ」はハイパバイザ、「Ｃ」はブロック制御を示す。第２のアルファベット文字は、所属先クラスタを示す。「Ａ」はクラスタ５０Ａ、「Ｂ」はクラスタ５０Ｂに属することを表している。ブロック制御部３１４はクラスタ間を跨がって設けられるため、クラスタの所属先を示す第２のアルファベット文字は添えられていない。

プログラム（または機能と呼び変えてもよい）間で情報を共有するためのメモリには、第１のアルファベット文字として、共有者をそれぞれ示すアルファベット文字が使用されている。ＦＯＳ３１１とハイパバイザ３１３で共有するメモリ３２には、「ＳＨ」が添えられる。ハイパバイザ３１３とブロック制御部３１４で共有するメモリ３２には、「ＨＣ」が添えられる。

ＦＯＳ３１１とハイパバイザ３１３で共有するメモリ３２ＳＨＡ、３２ＳＨＢは、図４のメモリ領域３２１５、３２２５に相当する。図４ではクラスタの区別をしていないが、もしも区別するならば、メモリ３２ＳＨＡはメモリ領域３２１５Ａおよび３２２５Ａに対応し、メモリ３２ＳＨＢは、メモリ領域３２１５Ｂおよび３２２５Ｂに対応する。ハイパバイザ３１３とブロック制御部３１４で共有するメモリ領域３２ＨＣＡ、３２ＨＣＢは、図４の３２１６および３２２６に相当する。図４においてクラスタを区別するならば、メモリ３２ＨＣＡはメモリ３２１６Ａおよび３２２６Ａに対応し、メモリ３２ＨＣＢはメモリ３２１６Ｂに対応する。

ブロック制御部３１４のメモリ３２Ｃ（図４のメモリ領域３２１４に相当）には、ストレージシステム３０全体の障害処理を行う障害統合管理プログラムＰ１２（図５）が置かれている。ブロック制御部３１４は、障害統合管理プログラムＰ１２を用いることで、各ハードウェアで発生する障害報告を統合して管理し、障害処理を決定する。障害に対処するための処理内容としては、例えば、閉塞、縮退、フェイルオーバがある。

障害監視部４３について説明する。例えば、一つまたは複数の障害監視部４３を論理的に分割することで、ＦＯＳ、ハイパバイザ、ブロック制御部のそれぞれに割り当てることができる。障害監視部４３は、メモリ領域の障害情報格納領域を監視する。共有メモリ領域３２ＳＨ、３２ＨＣについては、共有するＯＳに割り当てられている障害監視部４３のうちいずれか一方が監視すればよい。例えば、図９において、ＦＯＳ３１１Ａとハイパバイザ３１３Ａの共有するメモリ領域３２ＳＨＡは、障害監視部４３ＳＡまたは４３ＨＡのいずれか一方が監視すればよい。

＜障害処理方式＞
ユニファイドストレージシステム３０における障害処理を説明する。

＜ハードウェアからの障害検出方式の概要＞
ハードウェアから障害報告を受けて障害を検出する方法と、障害の報告の方法について説明する。以下、ＦＯＳ３１１等、ハイパバイザ３１３、ブロック制御３１４をオペレーティングシステム（ＯＳ）と呼ぶ場合がある。

障害を全ＯＳ（ＦＯＳ、ハイパバイザ、ブロック制御）に報告する方法と、障害部位を管理するＯＳのみ報告する方法とが考えられるが、ここでは、図１０を参照して、全ＯＳに報告する場合を説明する。

障害監視用のハードウェアである障害監視部４３が、ＣＰＵ３１、ポート３５〜３６、メモリ３２、ディスク３４等のハードウェアの障害を検出する。障害監視部４３は、ハードウェアの状態を定期的に確認することで、または、ハードウェアから障害の発生を知らせる情報を受信することで、障害を監視する。障害の発生を知らせる情報としては、例えば、信号、メッセージ、割り込み、データ等である。

例えば、ＣＰＵ３１、メモリ３２、通信ポート３６等のハードウェア資源に障害が発生した場合、障害監視部４３は、その障害ハードウェアから障害が発生した情報を受け取り、障害が起こったことを認識する（Ｓ１０）。

図４のメモリ領域内に示す「障害情報」は、ハードウェア毎の障害情報を格納するための障害情報格納領域であり、メモリ３２内に予め設定されている。障害監視部４３は、障害ハードウェアから受信した障害情報を、ＦＯＳ３１１、ハイパバイザ３１３およびブロック制御３１４に通知すべく、それぞれのメモリ領域内の障害情報格納領域に格納する（Ｓ１１〜Ｓ１３）。

図１０では、全てのＯＳ（ＦＯＳ、ハイパバイザ、ブロック制御）に、ハードウェア障害の発生を報告する。このため、ブロック制御３１４の使用するメモリ３２Ｃ（３２２４）とハイパバイザ３１３の使用するメモリ３２Ｈ（３２２３）とＦＯＳが使用するメモリ３２Ｓ（３２２１、３２２２）内の、障害情報格納領域に障害情報を登録する。他の方法として、複数のＯＳ間で共有するメモリ領域３２ＳＨ（３２２５）および３２ＨＣ（３２２６）に障害情報を格納してもよい。

各ＯＳは、障害監視部４３からの障害情報を受領すると、障害ハードウェアの管理担当が自ＯＳであるか判定する（Ｓ１４〜Ｓ１６）。ここでは、ＦＯＳ３１１の管理下にあるハードウェアで障害が発生したものとする。

ＦＯＳ３１１は、自分の担当しているハードウェアの障害であると判断すると（Ｓ１４：ＹＥＳ）、障害の詳細を調査して報告を作成する（Ｓ１７）。ＦＯＳ３１１は、ブロック制御３１４へ報告するために、一旦ハイパバイザ３１３との共有メモリ領域３２２５の障害情報格納領域に詳細報告を登録し（Ｓ１８）、待機する（Ｓ１９）。ここで、障害の詳細な報告には、ＣＰＵでの障害を例に挙げると、障害で停止したコア番号、障害の程度および種類、現象等を含むことができる。

ハイパバイザ３１３は、ＦＯＳ３１１との共有メモリ領域３２２５を随時モニタリングしており、障害の詳細報告を発見する。ハイパバイザ３１３は、詳細報告を、ブロック制御３１４との共有メモリ領域３２２６内の障害情報格納領域に登録する（Ｓ２２）。

ブロック制御部３１４は、ハイパバイザ３１３との共有メモリ領域３２２６を随時モニタリングしており、障害の詳細報告を検出する（Ｓ２３）。このように、ＦＯＳ３１１の使用するハードウェアに障害が発生した場合、障害に関する情報は、必ずハイパバイザ３１３を介してブロック制御部３１４に報告される。

ブロック制御部３１４は、障害の詳細報告に基づいて、その障害に対処するための処理方法（障害処理）を決定する（Ｓ２４）。例えば、ブロック制御部３１４は、どのハードウェアを閉塞させるか等の具体的指示内容を決定する。

ブロック制御部３１４は、決定した内容を実行させるための指示を、障害発生元の管理者であるＦＯＳ３１１に伝達すべく、ハイパバイザ３１３との共有メモリ領域３２２６の障害情報格納領域に登録する（Ｓ２５）。

ハイパバイザ３１３は、ブロック制御部３１４との共有メモリ領域３２２６内で、ブロック制御部３１４からの指示を発見すると、その指示をＦＯＳ３１１との共有メモリ領域３２２５の障害情報格納領域に登録する（Ｓ２６）。

ＦＯＳ３１１は、ハイパバイザ３１３との共有メモリ領域３２２５をモニタリングすることで、ブロック制御部３１４からの指示を検出する（Ｓ２７）。ＦＯＳ３１１は、ブロック制御部３１４から指示された通りに、障害処理を実施する（Ｓ２８）。

なお、障害の発生したハードウェアの担当ではないハイパバイザ３１３は、待機状態となり（Ｓ２０）、詳細報告および障害処理の指示を伝達するだけの役割を果たす。障害の発生したハードウェアの担当ではないブロック制御部３１４も、障害の詳細報告を作成したりする必要はないため、待機する（Ｓ２１）。但し、ブロック制御部３１４は、ストレージシステム３０内の障害を集約して管理し、障害に対する処理の実行を指示する役割を果たすために、障害の詳細な報告を受領し（Ｓ２３）、障害に対処するための指示を作成して発行する（Ｓ２４、Ｓ２５）。

ＦＯＳ３１１の管理下にあるハードウェアで障害が発生する一例を説明する。例えば、ＦＯＳ３１１は、自身の接続されたＮＩＣ３６の状態を監視している。ＮＩＣ３６は、通常２重化されている。一方のＮＩＣ３６に障害が起きると、交替パス構成を解除して、シングルパス構成となり、他方のＮＩＣ３６を用いて通信処理が続けられる。

このようなケースでは、ＮＩＣ３６での障害発生として、ＦＯＳ３１１からハイパバイザ３１３を経由してブロック制御部３１４に障害を報告する。ＦＯＳ３１１の障害としてブロック制御部３１４に報告するわけではない。

ＮＩＣ３６の障害について報告を受けたブロック制御部３１４は、ＦＯＳ３１１で処理可能な障害であると判定した場合、障害処理を指示する必要はないと判断し、障害状況を管理するに留まることもできる。この場合、図１０中のステップＳ２５〜Ｓ２８を省略し、ステップＳ２４の代わりのステップでは、障害情報を記憶して処理を終了する。

このように、障害監視部４３はハードウェア毎に障害発生を監視し、障害が発生した場合は、同一クラスタ内の全ＯＳ（ＦＯＳ、ハイパバイザ、ブロック制御部）に対して、障害の発生を報告する。

従って、障害の報告先をハードウェア毎にそれぞれ個別に管理する必要がなく、ストレージシステム３０のハードウェアが追加されたり変更されたりした場合でも容易に対応することができる。このため、本実施例では、ストレージシステム３０の根幹を成すブロック制御部３１４でストレージシステム内の障害を集約管理する構成と結合することで、障害管理コストを一層低減することができる。

上記説明では、ＦＯＳで処理可能な場合を例示したが、ＦＯＳでは対処せずに、障害の生じたＮＩＣ３６を使用するＦＯＳ３１１から他系のクラスタ内のＦＯＳ３１１に処理を引き継ぐ必要がある場合もある。例えば、一方のＮＩＣに障害が発生して、交替パス構成が保てなくなった場合である。この場合には、ステップＳ２４にて、ブロック制御部３１４はフェイルオーバすることを決定する。ステップＳ２８にて、ＦＯＳ３１１はファイルオーバ指示を実行する。具体的には図１０のステップＳ２５以降の処理は、後述する図１５のステップＳ６９以降の処理となり、他方のクラスタに処理が引き継がれる。

図１１は、ハイパバイザ３１３の管理下にあるハードウェアで障害が生じた場合の動作を示すフローチャートである。ステップＳ１０〜Ｓ１６までは、図１０で述べたと同じである。障害監視部４３は、ハードウェア障害を検出すると（Ｓ１０）、障害発生を所定のメモリに格納させることで、ＦＯＳ３１１、ハイパバイザ３１３、ブロック制御部３１４にそれぞれ通知する（Ｓ１１〜Ｓ１３）。

ＦＯＳ３１１は、通知された障害が自身の管理下にあるハードウェアで生じたものではないと判定すると（Ｓ１４：ＮＯ）、待機する（Ｓ３０）。

ハイパバイザ３１３は、自身の管理下のハードウェアで生じた障害であると判定し（Ｓ１５：ＹＥＳ）、障害の詳細報告を作成する（Ｓ３１）。ハイパバイザ３１３は、障害の詳細報告をブロック制御部３１４との共有メモリ領域３２２６に登録して（Ｓ３２）、待機する（Ｓ３３）。

ブロック制御部３１４は、ハイパバイザ３１３からの障害の詳細報告を検出すると（Ｓ２３：ＹＥＳ）、その障害に対する処理内容を決定し（Ｓ２４）、決定した障害処理を実行させるための指示を、ハイパバイザ３１３との共有メモリ領域３２２６に登録する（Ｓ２５）。

ハイパバイザ３１３は、ブロック制御部３１４からの指示を検出すると（Ｓ３４）、指示された障害処理を実施し（Ｓ３５）、ハイパバイザ３１３での障害処理が実行されたことをＦＯＳ３１１に報告する（Ｓ３６）。ＦＯＳ３１１は、ブロック制御部３１４からの指示に従って、障害処理を実施する（Ｓ３７）。

本実施例においてもＳ２４にてフェイルオーバを決定することがある。例えば、交替パス構成を有さない場合においてＮＩＣ３６に障害が発生した場合、図１０のフローにかえて図１１のフローを採用することも可能である。この場合、正確にはＮＩＣ３６の障害であるが、ハイパバイザ３１３は、自身の管理下にあるＦＯＳ３１１で障害が発生したものとして、ブロック制御部３１４に詳細を報告する（Ｓ３１、Ｓ３２）。ハイパバイザ３１３は、ＦＯＳ３１１での障害発生をブロック制御部３１４に通知する際に、ＮＩＣ３６での障害についても一緒に報告してもよい。

ブロック制御部３１４は、ＦＯＳ３１１での障害発生を知ると（Ｓ２３：ＹＥＳ）、フェイルオーバ処理の実施を決定し（Ｓ２４）、フェイルオーバ先等の情報を含む指示を作成して共有メモリ領域３２２６に登録する（Ｓ２５）。

ハイパバイザ３１３は、ブロック制御部３１４からの指示を検出すると（Ｓ３４：ＹＥＳ）、その指示に従って障害処理を実行する（Ｓ３５）。さらに、ハイパバイザ３１３は、共有メモリ領域３２２５を介して、障害の生じたＮＩＣ３６を使用するＦＯＳ３１１に、ブロック制御部３１４からの指示を報告する（Ｓ３６）。ＦＯＳ３１１は、ブロック制御部３１４からの指示を検出すると、その指示に従ってフェイルオーバ処理を実行する（Ｓ３７）。

図１２は、ブロック制御部３１４の管理下にあるハードウェアで障害が生じた場合の動作を示すフローチャートである。

障害監視部４３は、ハードウェア障害を検出すると、障害情報を所定のメモリ領域に格納することで、障害が発生した旨をＦＯＳ３１１とハイパバイザ３１３とブロック制御部３１４に通知する（Ｓ１１〜Ｓ１３）。

ＦＯＳ３１１は、自身の管理下にあるハードウェアの障害ではないため（Ｓ１４：ＮＯ）、待機する（Ｓ３０）。ハイパバイザ３１３も、自身の管理下にあるハードウェアの障害ではないため（Ｓ１５：ＮＯ）、待機する（Ｓ４０）。仕掛かり中の処理については後述する。なお、ＦＯＳ３１１は待機中に新規のＩ／Ｏ要求も受け付ける。

ブロック制御部３１４は、障害報告を受けて、自身の管理下にあるハードウェアで障害が発生したと判定すると（Ｓ１６：ＹＥＳ）、ストレージシステム３０で生じている全ての障害を考慮して、障害に対する処理内容を具体的に決定する（Ｓ４１）。ブロック制御部３１４は、決定した障害処理のうちブロック制御部３１４で実行すべき障害処理を実施する（Ｓ４２）。

ブロック制御部３１４は、障害の報告と障害処理の指示を、ハイパバイザ３１３との共有メモリ領域３２２６の障害情報格納領域に登録する（Ｓ４３）。ハイパバイザ３１３は、その共有メモリ領域３２２６をモニタリングして、障害報告および障害処理の指示を検出する（Ｓ３４：ＹＥＳ）。ハイパバイザ３１３は、ブロック制御部３１４から指示された障害処理のうちハイパバイザ３１３で実行すべき処理を実施する（Ｓ３５）。ハイパバイザ３１３は、障害処理の指示を、ＦＯＳ３１１と共有するメモリ領域３２２５の障害情報格納領域に格納することで、ＦＯＳ３１１に報告する（Ｓ３６）。

ＦＯＳ３１１は、共有メモリ領域３２２５をモニタリングして、ブロック制御部３１４からの指示を検出し、指示に従って障害処理を実行する（Ｓ３７）。

なお、障害の状況によっては、ハイパバイザ３１３およびＦＯＳ３１１で実行する障害処理が無い場合もある。

例えば、障害の発生したメモリ３２に、ブロック制御部３１４の使用する領域が割り当てられている場合を考える。高信頼性を要求されるブロック制御部３１４は、その必要がある場合、同一の情報を異なる複数のメモリ領域で冗長管理する。２つのメモリ領域のうち一方に障害が発生した場合、ブロック制御部３１４は、障害処理として、他方のメモリ領域のみを使用して処理を継続するためのプログラムを実行する。障害メモリをハイパバイザ３１３もＦＯＳ３１１もいずれも使用していない場合、ハイパバイザ３１３およびＦＯＳ３１１は、その障害メモリに関して実行すべき処理を持たない。

他の例を検討する。例えば、ディスクデバイス３４が故障した場合、ブロック制御部３１４がディスクデバイス３４を管理しているため、故障したディスクデバイスについての障害処理（閉塞処理等）は、ブロック制御部３１４が実行する。

例えば、短時間内に、同一ＲＡＩＤグループに属する複数のディスクデバイス３４のそれぞれに障害が発生したと仮定する。先に障害の発生したディスクデバイスに記憶されているデータの復元が完了する前に、同一ＲＡＩＤグループ内の他のディスクデバイスに障害が発生し、データを読み出せなくなった場合、いわゆる二重障害となる。ＲＡＩＤ５の構成を有するＲＡＩＤグループの場合、二重障害が発生すると、障害ディスクデバイスに記憶されているデータを復元することができなくなる。

二重障害の発生したＲＡＩＤグループから生成されている論理ボリューム（ＬＵ）にファイルシステムが格納されている場合、ブロック制御部３１４は、障害の生じた論理ボリュームの番号をＦＯＳ３１１に通知する。ＦＯＳ３１１は、部分閉塞処理を実行し、障害の生じた論理ボリュームに格納しているファイルシステムだけをオフラインにする。

なお、ＦＯＳ３１１からブロック制御部３１４にＩ／Ｏ処理を受け渡した後、ブロック制御部３１４が「Ｉ／Ｏエラー」をＦＯＳ３１１へ返信した場合、ＦＯＳ３１１はディスクデバイス３４の障害を認識できる。

なお、上記例では、ブロック制御部３１４が障害処理を決定しているが、これに代えて、ハイパバイザ３１３がＦＯＳ３１１での障害処理を決定してもよい。

図１３を用いて、ＦＯＳの管理下にあるハードウェアで障害が生じた場合の他の動作例を説明する。

図１０では、ＦＯＳ３１１の管理下にあるハードウェアで障害が生じた場合に、ＦＯＳ３１１、ハイパバイザ３１３およびブロック制御部３１４のそれぞれに対応するメモリ領域内の障害情報格納領域内に障害情報を格納することで、障害発生を通知する場合を説明した。

これに代えて、ＦＯＳ３１１のメモリ領域３２２１に障害情報を格納せず、ハイパバイザ３１３のメモリ領域３２２３とブロック制御部３１４のメモリ領域３２１４に障害情報を格納し、ハイパバイザ３１３からＦＯＳ３１１に障害発生を通知してもよい。

ＦＯＳ３１１の使用するハードウェアで障害が発生した場合、障害発生箇所の特定などの障害の詳細な報告は、ＦＯＳ３１１を管理するハイパバイザ３１３が作成してもよいし、または、ＦＯＳ３１１が作成してもよい。

図１３は、ＦＯＳ３１１の使用するハードウェアで障害が発生した場合に、障害情報が最初にハイパバイザ３１３およびブロック制御部３１４のみに通知され、ＦＯＳ３１１はハイパバイザ３１３からの通知によって障害の詳細な報告を作成し、ハイパバイザ３１３を介してブロック制御部３１４に送る場合を示す。

障害監視部４３は、ＦＯＳ３１１の使用するハードウェアに障害が発生したことを検出すると、障害が発生した旨を示す障害情報を、ハイパバイザ３１３の使用するメモリ領域３２２３とブロック制御部３１４の使用するメモリ領域３２２４とに格納する（Ｓ１２、Ｓ１３）。ＦＯＳ３１１の使用するメモリ領域３２２１に障害情報は格納されない。

ハイパバイザ３１３は、障害情報を検出すると、ＦＯＳ３１１と共有するメモリ領域３２２５に障害情報を格納することで、障害ハードウェアを使用するＦＯＳ３１１に障害の発生を通知する（Ｓ５０）。ハイパバイザ３１３は、自身の管理下にあるハードウェアで発生した障害ではないと判定し（Ｓ１５：ＮＯ）、待機する（Ｓ２０）。

同様に、ブロック制御部３１４は、障害情報を検出すると、自身の管理下にあるハードウェアで発生した障害ではないと判定し（Ｓ１６：ＮＯ）、待機する（Ｓ２１）。

ＦＯＳ３１１は、障害情報を取得すると（Ｓ５１）、自身の担当するハードウェアでの障害であると判定し（Ｓ１４：ＹＥＳ）、図１で述べたように、ステップＳ１７〜Ｓ１９を実行する。なお、障害処理の内容にフェイルオーバ処理が含まれている場合、後述の方法で実施する。

図１３で説明したように、障害監視部４３が障害発生を報告する先を、ハードウェア毎に管理してもよい。ＦＯＳ３１１、ハイパバイザ３１３、ブロック制御部３１４のうち、障害報告を受け取るべきＯＳにのみ障害発生を報告することで、ストレージシステム３０内の通信負荷を軽減できる。

図１４で、各ハードウェア資源での障害発生を報告する先を管理するために使用できる障害管理テーブルＴ１３の例を説明する。

障害管理テーブルＴ１３は、例えばメモリ３２１内に確保する領域に格納する。障害管理テーブルＴ１３は、ハードウェア資源ごとに用意される。図１４では、プロセッサ用の障害管理テーブルＴ１３０と、メモリ用の障害管理テーブルＴ１３１を示す。ポート管理用のテーブルとディスクデバイス管理用のテーブルは図示を省略する。

プロセッサ用の障害管理テーブルＴ１３０は、例えば、リソース名と、状態と、使用者を対応付けて管理する。「リソース名」は、ＣＰＵ３１をストレージシステム内で一意に特定する名称を記憶する。「状態」は、リソース名で特定したＣＰＵ３１の使用状態（正常、使用中、閉塞中等）を記憶する。「使用者」は、リソース名で特定したＣＰＵ３１を使用するＯＳ（ＦＯＳ、ハイパバイザ、ブロック制御部）を記憶する。

メモリ用の障害管理テーブルＴ１３１は、例えば、リソース名、状態、アドレス、使用者を対応付けて管理する。「リソース名」は、ストレージシステム内でメモリ３２を一意に特定する名称を記憶する。「状態」は、リソース名で特定したメモリ３２の使用状態（正常、使用中、閉塞中等）を記憶する。「アドレス」は、リソース名で特定したメモリ３２のメモリ空間に設定されるメモリ領域である。「使用者」は、メモリ領域毎の使用者（ＦＯＳ、ハイパバイザ、ブロック制御部、または、ＦＯＳとハイパバイザの共有、ハイパバイザとブロック制御部の共有）を記憶する。

障害を検出した場合、障害監視部４３は、障害の発生したハードウェアの使用者を管理テーブルＴ１３で確認し、その使用者に障害発生を報告する。

ここで、ブロック制御部３１４とブロック制御部３１４以外のＯＳ（ハイパバイザ３１３、ＦＯＳ３１１）の両方からディスクデバイス３４が使用される場合、ディスクデバイス３４は全てのＯＳから共有されるハードウェア資源である。ディスクデバイス３４に障害が発生した場合、障害ディスクデバイスに格納されたブロックデータが、どのＯＳ（ＦＯＳ、ハイパバイザ、ブロック制御部）で使用されているデータであるか特定することは難しい。従って、全ＯＳにより共有されるディスクデバイス３４に障害が発生した場合、全てのＯＳに障害発生を報告する。

障害監視部４３は、メモリ３２の場合、物理的に１枚のメモリごとに、正常であるか障害が発生しているかを判定する。物理的に１枚のメモリ３２のメモリ空間が分割されて複数の使用者（ＦＯＳ、ハイパバイザ、ブロック制御部、共有）に使用されている場合において、そのメモリ３２に障害が発生したときは、全使用者に障害発生を報告する。

ここで、ＣＰＵ３１、メモリ３２、ディスクデバイス３４等で生じる障害は、それらハードウェアに設けるハードウェア回路としての障害監視部４３によって、検出することができる。これに対し、ＨＢＡ３５のポートおよびＮＩＣ３６のポートは、自身の障害を検知することができない。従って、障害検出プログラム等が一定周期で正常に動作しているかを確認することで、ポートの障害を検出する。

ハイパバイザ３１３上で動作する複数のＦＯＳのうちいずれか一つのＦＯＳ３１１が使用するハードウェア資源に障害が発生し、かつ、そのＦＯＳ３１１がフェイルオーバする必要がある場合は、そのＦＯＳ３１１を管理するハイパバイザ３１３からブロック制御部３１４に障害発生を通知する。

このように障害監視部４３を複数設けて監視対象をそれぞれに設定することで、障害検出及び部位特定処理を分散させることができる。また、ＦＯＳ、ハイパバイザ、ブロック制御と階層的に障害を管理することで管理を容易化するとともに、障害情報をブロック制御部に集約することを可能にする。本構成によって、ブロック制御部の障害検出処理や管理コストを低減しつつ、信頼性の高いブロック制御部による障害処理判断を可能とする。
＜ソフトウェアによる障害検出＞

図１５および図１６を用いて、ハードウェア回路としての障害監視部４３では検出できない障害を検出するための方法を説明する。図１５では、ＦＯＳ３１１をハイパバイザ３１３が常時監視して、ＦＯＳ３１１の障害を検出する様子を示す。これに限らず、例えばハイパバイザ３１３とブロック制御部３１４が相互に監視したり、ブロック制御部３１４がハイパバイザ３１３を介してＦＯＳ３１１を監視したりすることで、障害をソフトウェア処理で検出することができる。

ＦＯＳ３１１がフェイルオーバ処理を開始するためには、その前提として、ＦＯＳ３１１の障害を検出する必要がある。ＦＯＳ３１１の障害を検出する方法としては、例えば以下の２つがある。

第１の方法は、ブロック制御部３１４がハイパバイザ３１３を介してＦＯＳ３１１の障害を検出する方法である。ブロック制御部３１４は、ハイパバイザ３１３とＦＯＳ３１１との間で定期的に実行される死活監視に基づいて、ＦＯＳ３１１の障害を検出する。第１の方法については、図１５等で説明する。

第２の方法は、ＦＯＳ３１１の使用するハードウェアに障害が生じた場合に、そのハードウェアが発する割り込み信号をＦＯＳ３１１が受信し、ＦＯＳ３１１がハイパバイザ３１３を介してブロック制御部３１４に障害発生を報告する方法である。第２の方法については、図１９で後述する。

図１５および図１６は、ブロック制御部３１４がハイパバイザ３１３を介してＦＯＳ３１１の障害を監視する処理を示すフローチャートである。ここでは、理解のために、クラスタ５０ＡのＦＯＳ３１１Ａで障害が発生した場合を例に挙げて説明する。

ＦＯＳ３１１Ａは、ペアを形成する相手方ＦＯＳ３１１Ｂとハートビート通信を行うことで、相手方ＦＯＳが正常に稼働しているかを監視している。本実施例では、ＦＯＳ３１１Ａとハイパバイザ３１３Ａの間でも、死活確認処理を定期的に実行する。さらに、本実施例では、ハイパバイザ３１３Ａとブロック制御部３１４Ａの間でも、死活確認処理を定期的に実行することができるが、そのフローチャートは省略する。

例えば、ＦＯＳ３１１Ａが使用するメモリ領域３２２１Ａにハイパバイザ３１３Ａがアクセスできる死活確認専用の領域を用意する。ハイパバイザ３１３Ａは、その死活確認用領域に、死活確認用の情報を設定する（Ｓ６１）。例えば、ハイパバイザ３１３Ａは、死活確認用の領域に記憶される死活確認用の所定ビットに１を設定する。所定ビットを、死活確認用ビットと呼んでもよい。

ＦＯＳ３１１Ａは、定期的に死活確認用の領域を監視しており、所定ビットが１に設定されている場合、所定ビットをリセットし、０を設定する（Ｓ６２）。

ハイパバイザ３１３Ａは、上述の通り定期的に所定ビットに１を設定するが、その前に所定ビットの値を確認する（Ｓ６３）。ハイパバイザ３１３Ａは、所定ビットに１が設定されているか判定する（Ｓ６４）。所定ビットが０に設定されている場合は（Ｓ６４：ＮＯ）、ＦＯＳ３１１Ａが正常に動作している場合である。そこで、ハイパバイザ３１３Ａは、所定ビットに１を設定する（Ｓ６１）。

これに対し、ハイパバイザ３１３Ａが所定ビットの値を確認したときに、所定ビットが１に設定されたままである場合（Ｓ６４：ＹＥＳ）、ＦＯＳ３１１Ａに障害が発生しているために、所定ビットをリセットできなくなっていると判定することができる。

そこで、ハイパバイザ３１３Ａは、ＦＯＳ３１１Ａに障害が発生したことを示す障害情報（ＦＯＳ障害情報）を、ハイパバイザ３１３Ａとブロック制御部３１４Ａとで共有するメモリ領域３２２６Ａの障害情報格納領域に格納する（Ｓ６５）。

ブロック制御部３１４Ａは、共有メモリ領域３２２６Ａを定期的にモニタリングして（Ｓ６６）、障害の発生を検知する（Ｓ６７：ＹＥＳ）。ブロック制御部３１４Ａは、ＦＯＳ３１１Ａの障害を認識すると（Ｓ６８）、ハイパバイザ３１３Ａに障害ＦＯＳ３１１Ａをリセットさせるためのリセット指示を発行する（Ｓ６９）。ブロック制御部３１４Ａは、共有メモリ領域３２２６Ａにリセット指示を格納することで、リセット指示が発行されたことをハイパバイザ３１３Ａに伝達する。

ハイパバイザ３１３Ａは、ブロック制御部３１４Ａからのリセット指示を取得すると、障害の生じたＦＯＳ３１１Ａに向けてリセット要求を発行する（Ｓ７０）。

障害ＦＯＳ３１１Ａは、ハイパバイザ３１３Ａの発行したリセット要求を受領すると（Ｓ７１）、ハイパバイザ３１３Ａにリセット完了を知らせる応答を返した後（Ｓ７２）、リセット処理を実行する（Ｓ７３）。

ハイパバイザ３１３Ａは、障害ＦＯＳ３１１Ａからのリセット応答を受信すると（Ｓ７４）、このリセット応答を共有メモリ領域３２２６Ａを介してブロック制御部３１４Ａに伝達する（Ｓ７５）。

ブロック制御部３１４Ａは、障害ＦＯＳ３１１Ａからのリセット応答をハイパバイザ３１３Ａ経由で受信すると、障害ＦＯＳ３１１Ａがリセットしたことを確認し、フェイルオーバ処理の準備が整ったことを認識する（Ｓ７５）。

ブロック制御部３１４Ａは、フェイルオーバ先ＦＯＳ３１１Ｂにフェイルオーバ元ＦＯＳ３１１Ａで障害が生じたことを通知すべく、障害ＦＯＳ３１１Ａについての障害情報を、ブロック制御部３１４Ｂの使用するメモリ領域３２２４に記憶する（Ｓ７６）。

ブロック制御部３１４Ａは、メモリ領域３２２４に代えて、ディスクデバイス３４に障害情報を書き込んでもよい。ブロック制御部３１４Ａは、ステップＳ６８でＦＯＳ３１１Ａの障害を認識した時点で、ステップＳ７６を実行してもよい。つまり、障害ＦＯＳ３１１Ａからのリセット応答を確認する前に、他クラスタ５０Ｂのブロック制御部３１４Ｂに障害ＦＯＳ３１１Ａの存在を伝達してもよい。これにより、フェイルオーバ処理を早期に開始することができ、切替時間を短縮できる。

図１６に移る。図１６はクラスタ５０Ｂでの動作を示す。ブロック制御部３１４Ｂは、メモリ領域３２２４を参照することで（Ｓ７７）、ＦＯＳ３１１Ａに障害が生じたことを認識する（Ｓ７８）。ブロック制御部３１４Ｂは、ＦＯＳ３１１Ｂにフェイルオーバ処理の実行を要求するよう、ハイパバイザ３１３Ｂに指示する（Ｓ７９）。フェイルオーバ先のＦＯＳ３１１Ｂは、予めクラスタ間で決定されている。

ハイパバイザ３１３Ｂは、ブロック制御部３１４Ｂからの指示に従って、フェイルオーバ先のＦＯＳ３１１Ｂに対して、フェイルオーバ処理の開始を指示する（Ｓ８０）。ＦＯＳ３１１Ｂは、ハイパバイザ３１３Ｂからの指示を受領すると（Ｓ８１）、障害ＦＯＳ３１１Ａでの処理を肩代わりするために、フェイルオーバ処理を開始する（Ｓ８１）。

ＦＯＳ３１１Ｂは、障害ＦＯＳ３１１Ａが担当していた論理ボリューム（ＬＵ）を認識して（Ｓ８３）、その論理ボリュームをマウントする（Ｓ８４）。その後、ＦＯＳ３１１Ｂは、マウントした論理ボリュームに関するファイルコマンドをコマンド発行装置１０１Ｂから受け付けて処理する。

障害ＦＯＳ３１１Ａが担当していた論理ボリュームについてのＬＵ管理情報Ｔ１０（図５）は、フェイルオーバ処理の実行に際して、フェイルオーバ先のＦＯＳ３１１Ｂに引き継がれる。

フェイルオーバ先のＦＯＳ３１１Ｂは、もともと自身が担当している論理ボリュームについてのコマンド処理と、障害ＦＯＳ３１１Ａから引き継いだ論理ボリュームについてのコマンド処理との両方を実行する。

ここで、フェイルオーバするためのクラスタ間での情報の受け渡しを説明する。通常のＩ/Ｏ要求を発行する際、ユーザは、ファイル（ファイルシステム）名又はディレクトリ情報等を指定する。図２２の例に示すように、ＦＯＳは、ユーザが指定する情報とＦＯＳが管理するＬＵ番号との対応関係を示す情報Ｔ３３を管理する。一方ブロック制御側では、ＦＯＳが認識するＬＵ番号とブロック制御内部で管理する論理デバイス番号との対応関係を示す情報Ｔ１４を管理する。対応するＬＵに対しブロック制御の論理デバイス番号は、１対１でもよいし、１対Ｎでもよい。

情報Ｔ３３およびＴ１４は、メモリ３２内の３２１１または３２１２のいずれかと、３２１４とにそれぞ格納される。または情報Ｔ３３およびＴ１４をディスクデバイス３４内に格納し、使用する前にメモリ３２に格納してもよい。フェイルオーバ処理を開始すると、障害が発生した方のＦＯＳ側の情報Ｔ３３は共用メモリ３２１６又は３４１７に格納される。そして、ブロック制御によって、相手ＦＯＳへ情報を伝送される。具体的には、ブロック制御が障害が発生した方のＦＯＳのＴ３３を、引き継ぐ方のＦＯＳとブロック制御のクラスタの３２１６又は３２１７に格納する。

別の方法として、ＦＯＳ用の共有ＬＵを設けてもよい。ブロック制御部はディスクデバイス３４の記憶領域からＬＵを生成して外部装置に提供する。あるＬＵについては同じ識別子のＬＵとしてフェイルオーバのペアとなる２つのＦＯＳへ同時に提供する。具体的には当該ＬＵを２つのＦＯＳに割り当てて、両ＦＯＳに生成されるからの参照を可能とする。共有ＬＵ内に、クラスタ５０ＡのＦＯＳとクラスタ５０ＢのＦＯＳがそれぞれＴ３３Ａ、Ｔ３３Ｂを格納する。そして、例えば５０ＢのＦＯＳが障害の場合、Ｓ８２の処理において５０ＡのＦＯＳがフェイルオーバする際に、Ｔ３３Ｂを読み出し５０ＢのＦＯＳの処理を引き継げるようにする。

共有ＬＵは、例えば、ファイルシステムではなく、デバイスファイルであり、マウントせずにリードできる領域である。共有ＬＵには、各ＦＯＳが担当するＬＵ情報等の構成情報が格納されていて、通常は自分が担当するＬＵ情報しか参照しない。一方で、フェイルオーバ時には相手の担当ＬＵ情報を参照することを可能にすることで、相手の処理を肩代わりすることができる。ライト時のみロック管理を行うことで排他制御を行うこともできる。

図１５および図１６では、障害ＦＯＳ３１１Ａの属するクラスタ５０Ａを担当するブロック制御部３１１Ａが、フェイルオーバ先ＦＯＳ３１１Ｂの属するクラスタ５０Ｂを担当するブロック制御部３１１Ｂを介して、ハイパバイザ３１３Ｂにフェイルオーバ指示を与えている。これに代えて、障害ＦＯＳ３１１Ａの属するクラスタ５０Ａを担当するブロック制御部３１１Ａが、フェイルオーバ先ＦＯＳ３１１Ｂの属するクラスタ５０Ｂのハイパバイザ３１３Ｂに直接指示を与える構成でもよい。

例えば、ブロック制御部３１１Ａからハイパバイザ３１３Ｂに情報を伝達するためのメモリ領域を用意して、そのメモリ領域にフェイルオーバに関する情報を登録することで、ブロック制御部３１１Ａからハイパバイザ３１３Ｂに指示する構成でもよい。

死活確認用ビットをセットまたはリセットする方法に代えて、ＦＯＳ３１１とハイパバイザ３１３とがハートビート通信を行う構成でもよい。また、ブロック制御部３１４が、ハイパバイザ３１３を介さずにＦＯＳ３１１の死活を監視する構成でもよい。

ハイパバイザ３１３Ａから障害ＦＯＳ３１１Ａへのリセット指示は、ハイパバイザ３１３ＡがＦＯＳ３１１Ａの障害を認識した時点（Ｓ６５）で行ってもよい。つまり、ハイパバイザ３１３Ａは、ブロック制御部３１４Ａからのリセット指示を得る必要はなく、ステップＳ６５に続いて直ちに障害ＦＯＳ３１１Ａにリセットを指示する。図１５において、ステップＳ６９は省略される。

そして、ハイパバイザ３１３Ａは、障害ＦＯＳ３１１Ａからリセット応答を受け取ると（Ｓ７４）、ブロック制御部へ報告する。

図１７は、図１４および図１５で述べた動作のうち、クラスタ間を跨がるブロック制御部３１４の動作の詳細を示す。

クラスタ５０ＡのＦＯＳ３１１Ａで障害が発生すると（Ｓ１００）、ＦＯＳ３１１Ａは、ＦＯＳ３１１Ａとハイパバイザ３１３Ａとで共有するメモリ領域３２２５Ａに、ＦＯＳ３１１Ａで障害が生じたことを示すＦＯＳ障害情報を格納する（Ｓ１０１）。

ハイパバイザ３１３Ａは、ＦＯＳ３１１Ａの障害を検出すると（Ｓ１０２）、ハイパバイザ３１３Ａとブロック制御部３１４Ａで共有するメモリ領域３２２６Ａに、ＦＯＳ障害情報を格納する（Ｓ１０３）。なお、ハイパバイザ３１３ＡがＦＯＳ３１１Ａの障害を最初に検出した場合は、ステップＳ１００〜Ｓ１０２は行われず、ステップＳ１０３から開始される。

ブロック制御部３１４Ａは、ハイパバイザ３１３Ａとの共有メモリ領域３２２６Ａを参照することで、ＦＯＳ３１１Ａの障害を検出する（Ｓ１０４）。ブロック制御部３１４Ａは、いわゆる二重書き機能を用いて、ブロック制御部３１４Ａの占有するメモリ領域３２２４Ａと、ブロック制御部３１４Ｂの占有するメモリ領域３２２４Ｂとに、ＦＯＳ障害情報を書き込む（Ｓ１０６、Ｓ１０７）。ＦＯＳ障害情報は、クラスタ５０Ａとクラスタ５０Ｂとで二重管理されるため、ＦＯＳ障害情報の損失を防止できる。二重書きについては図１８で後述する。

クラスタ５０Ｂでの処理に移る。クラスタ５０Ｂのブロック制御部３１４Ｂは、メモリ領域３２２４Ｂを参照して、ＦＯＳ３１１Ａの障害を認識する（Ｓ１０８）。ブロック制御部３１４Ｂは、ハイパバイザ３１３Ｂと共有するメモリ領域３２２６Ｂに、ＦＯＳ障害情報を格納する（Ｓ１０９）。

ハイパバイザ３１３Ｂは、共有メモリ領域３２２６Ｂを参照して、ＦＯＳ３１１Ａの障害を検出すると（Ｓ１１０）、障害ＦＯＳ３１１ＡとフェイルオーバのペアとなっているＦＯＳ３１１Ｂに対して、フェイルオーバ処理の開始を指示する（Ｓ１１１）。ＦＯＳ３１１Ｂは、ハイパバイザ３１３Ｂからの指示に従って、フェイルオーバ処理を実行する（Ｓ１１２）。

ステップＳ１０５での二重書きにより、メモリ領域３２２４ＢにＦＯＳ障害情報を書き込むライト処理（Ｓ１０７）と、メモリ領域３２２４ＢからＦＯＳ障害情報を読み出すリード処理（Ｓ１０８）とは、セットになって処理されるプログラムである。

一方のクラスタ５０Ａでライト処理プログラムが動作すると、相手クラスタ５０Ｂでのリード処理プログラムが起動する。ライト処理プログラムとリード処理プログラムとは、各クラスタにおいてそれぞれ複数ずつ動作可能であり、もっとも早いプログラムが処理を行う。例えば、複数のリード処理プログラムのうち、ＦＯＳ障害情報がメモリ領域３２２４Ｂ格納されたことを最初に見つけたリード処理プログラムが、そのＦＯＳ障害情報をメモリ領域３２２４Ｂから読み出す。

なお、ＦＯＳ障害情報を複数のメモリ３２２４Ａおよび３２２４Ｂに同時に書き込む二重書き処理に代えて、メモリ間通信機能を用いてＦＯＳ障害情報を相手クラスタに伝達する構成でもよい。

即ち、ブロック制御部３１４Ａは、メモリ３２２４ＡにのみＦＯＳ障害情報を書込む。その後、メモリ間通信を用いて、メモリ３２２４Ａ内のＦＯＳ障害情報をメモリ３２２４Ｂに転送し、両方のメモリの記憶内容を同期させる。

前記フェイルオーバを指示する際に、どのＦＯＳへ指示するかの情報は、図２１に示すように、共有メモリ３２１５内にフェイルオーバ構成情報Ｔ５０として予め格納しておく。フェイルオーバ構成情報Ｔ５０は、クラスタ毎に当該クラスタに属するＦＯＳを管理する情報である。具体的にはクラスタを識別する識別子と、ＦＯＳを少なくとも所属するクラスタ内で一意に識別するための識別子とを対応づける。これにより、何れかのＦＯＳに障害がおきた場合には、同じクラスタに属する別のＦＯＳをフェイルオーバ先として選択することがでいる。なお、フェイルオーバ構成情報Ｔ５０は、クラスタ識別子およびＦＯＳ識別子だけでなく、フェイルオーバ状態を管理してもよい。フェイルオーバ状態には、例えば、フェイルオーバ処理中、フェイルオーバ処理完了、フェイルオーバ処理していない、がある。

図１８を参照して、二重書き機能を説明する。図１８（ａ）は、ブロック制御部３１４の占有するＣＰＵ３１が、自分の使用するメモリ３２２４Ａと相手方ＣＰＵの使用するメモリ３２２４Ｂとに障害情報を書き込む場合を示す。一方のクラスタ５０Ａ内のブロック制御部３１４Ａが使用するＣＰＵをＣＰＵ３１ＣＡと、他方のクラスタ５０Ｂ内のブロック制御部３１４Ｂが使用するＣＰＵをＣＰＵ３１ＣＢとする。

ＣＰＵ３１ＣＡは、自身の使用するメモリ３２２４Ａの障害情報格納領域に障害情報を書き込むと共に、他方のＣＰＵ３１ＣＢを介して他方のメモリ３２２４Ｂにも障害情報を書き込ませる。

図１８（ｂ）は、コントローラボード４１内のキャッシュメモリ３９に専用回路を設ける場合を示す。一方のクラスタ５０Ａ内のキャッシュメモリ３９Ａと他方のクラスタ５０Ｂ内のキャッシュメモリ３９Ｂとには、それぞれデータ転送回路が設けられている。これらデータ転送回路は、ＡＳＩＣ（Application Specific Integrated Circuit）として構成されており、障害情報をメモリに書き込むための専用回路である。

図１８（ｂ）の場合、データ転送回路は、ＣＰＵ３１の処理を肩代わりをしており、キャッシュメモリ上で障害情報をコピーして、コピー元のメモリ３２２４Ａとコピー先のメモリ３２２４Ｂとに書き込む。

なお、障害情報を管理装置２０に転送して記憶する構成としてもよい。この場合は、各クラスタ５０Ａ、５０Ｂと管理装置２０との３カ所で障害情報を保持できるため、いずれか一つの障害情報を失った場合でも、障害情報を二重管理することができる。

このように構成される本実施例によれば、各クラスタ５０Ａ、５０Ｂに跨がって設けられ、ディスクデバイス３４へのデータ読み書きを司るブロック制御部３１４で、ストレージシステム３０内の障害に関する情報を管理することができる。従って、外部に障害監視用の装置を特別に設ける必要がなく、低コストでストレージシステム３０内の障害を管理することができる。

本実施例では、両方のクラスタ５０Ａ、５０Ｂに跨がって設けられ、両方のクラスタ内のＦＯＳ３１１の状況を認識可能なブロック制御部３１４に、ストレージシステム３０内の障害情報を集約する。従って、例えばＦＯＳがSplitBrain状態か否かを判断でき、確実にフェイルオーバさせることができる。 階層的に障害管理を行うことによる管理の容易性は前述の通りである。更に、特にクラスタ間の情報やりとりは、ブロック制御を介して行われるため、信頼性の最も高いブロック制御部が必ず、早いタイミングで障害情報を検知することができ、システムの信頼性が向上するとともに、障害の検出のタイミングのずれなどの調整が不要である。

本実施例では、ブロック制御部３１４は、同一のハードウェアで、もしくは、内部バス４２によって接続されているハードウェアで動作するため、従来のＦＯＳ間を繋ぐハートビート線に比べて、障害管理を高速かつ高信頼性で行うことができる。

図１９を用いて第２実施例を説明する。本実施例を含む以下の各実施例は第１実施例の変形例に該当する。以下の実施例では、第１実施例との相違を中心に説明する。本実施例では、ＦＯＳ３１１が自身の障害を検知して、ブロック制御部３１４に報告する。

図１９は、障害を管理する方法の一例を示すフローチャートである。説明の便宜上、クラスタ５０ＡのＦＯＳ３１１Ａで障害が発生したものとする。

ＦＯＳ３１１Ａは、障害監視部４３Ａからの割り込み信号により、ＦＯＳ３１１Ａの使用するハードウェアに障害が生じたことを検出する（Ｓ１２０）。ＦＯＳ３１１Ａは、自身の占有するメモリ領域３２２１Ａ（図４）の障害情報格納領域に、障害情報を格納する（Ｓ１２１）。ＦＯＳ３１１Ａは、ハイパバイザ３１３Ａと共有するメモリ領域３２２５Ａに、障害情報を書き込むことで、ハイパバイザ３１３Ａに障害の発生を報告する（Ｓ１２２）。

ハイパバイザ３１３Ａは、共有メモリ領域３２２５Ａを参照して（Ｓ１２３）、障害情報を検出すると（Ｓ１２４：ＹＥＳ）、ＦＯＳ３１１Ａで障害が発生したことを確認する（Ｓ１２５）。ハイパバイザ３１３Ａは、ＦＯＳ３１１からの確認依頼に応じて、共有メモリ領域３２２５Ａを参照する構成でもよい。ＦＯＳ３１１Ａの障害を確認したハイパバイザ３１３Ａは、ブロック制御部３１４Ａと共有するメモリ領域３２２６Ａに、障害情報を格納する。

ブロック制御部３１４Ａは、ハイパバイザ３１３Ａと共有するメモリ領域３２２６Ａを定期的にモニタリングして（Ｓ１２６）、障害情報を検出する（Ｓ６７：ＹＥＳ）。ブロック制御部３１４Ａは、ＦＯＳ３１１Ａの障害を検出すると（Ｓ６８）、ハイパバイザ３１３Ａから障害ＦＯＳ３１１Ａにリセット要求を出させるためのリセット指示を、ハイパバイザ３１３Ａに与える（Ｓ６９）。他のステップＳ７０〜Ｓ７６は、図１５で述べたので説明を割愛する。本実施例も第１実施例と同様の効果を奏する。

図２０を用いて第３実施例を説明する。本実施例では、フェイルオーバ処理中のＩ／Ｏ要求の処理方法を説明する。

ストレージシステム３０は、コマンド発行装置１０１からＩ／Ｏ要求（リードコマンド、ライトコマンド）を受信すると、コマンド制御プログラムＰ１０を起動して、要求された処理を実行する。これを正常処理と呼ぶ。

障害が発生した場合、コマンド制御処理プログラムＰ１０とは別の障害復旧中コマンド制御処理プログラムＰ１５が起動されて、Ｉ/Ｏコマンドの障害復旧処理が実行される。つまり、障害の有無により、動作するプログラムが異なる。

本実施例では、正常処理中の或るタイミングで障害が発生しているかどうかをチェックするためのプログラムを走らせることにより、障害が発生したことを認識し、図２０の右側に示す障害復旧中コマンド制御処理へと切り替える。

チェック用プログラムを走らせるタイミングＳ１３２、Ｓ１３４は、一連のＩ／Ｏ処理中の複数個所に設定されている。具体的には、正常処理内の１つの処理ごとにハードウェア障害チェックを行う。

コマンド制御プログラムは、ステップＳ１３１にて、例えばアドレス変換をして、そのアドレス変換の結果をメモリへ格納する処理を行った場合、ステップＳ１３２にて、障害が発生したかどうかをチェックする。コマンド制御プログラムは、例えばメモリに書き込みができずエラーが返ってきた場合等、障害が有りと判断されると（Ｓ１３２：ＹＥＳ）、Ｓ１３５へ進む。

コマンド制御プログラムは、障害がなければ（Ｓ１３２：ＮＯ）、ステップＳ１３３へ進み、コマンド制御の次のステップを処理する。コマンド制御プログラムは、Ｓ１３３にてキャッシュへデータを格納する処理を行う。キャッシュへ格納できない等、障害が有りと判断されれば（Ｓ１３４：ＹＥＳ）、ステップＳ１３５へ進む。

図示しないが、ステップＳ１３２とＳ１３３の間で実行されるライト要求処理の各ステップで処理が正常に行われたか確認し、障害があった場合にはＳ１３５へ移行する。例えば、構成情報を参照する際、その構成情報が格納された論理デバイスが閉塞しているか確認される。障害のチェックを行うのは、関連処理を行っている主体となるので、ＦＯＳであったり、ブロック制御だったりする。

Ｓ１３５では、障害情報を障害監視部へ報告する。障害監視部への報告の仕方とその後の処理については、図１０〜１２に記載がある。図１０〜１２で障害処理を行うと、障害復旧中コマンド制御処理が起動され、障害発生時に仕掛かり中のＩ/Ｏがあるかどうかを検出するため、構成情報を参照しにいく（Ｓ１３６）。通常のＩ/Ｏ処理開始時には、どの論理デバイスへどのＣＰＵが何の処理（リードやライト等）を実行するかの情報を制御メモリ内や論理デバイス等に構成情報として登録する。

ハードウェア自身からあがってくる割り込みによってハードウェア障害が検出される場合には、図１０〜１２において先に障害が報告されてから、仕掛かり中のＩ/Ｏへ割り込み、つまりコマンド制御プログラムに割り込みが入る。その後、障害有りとの報告がなされ（Ｓ１３５）、障害復旧プログラムに切り替わる。
また、障害によりＣＰＵがリセットされる等が発生すると、処理全体が一旦停止しリブートがかかり、障害復旧プログラムに切り替わる。

障害復旧プログラムＰ１５は、前記追跡情報に基づいて障害復旧方針を決定する。一つの方針は、何もせずに処理を終了することである（Ｓ１３１）。この場合、Ｉ／Ｏ処理は完了しない。コマンド発行装置１０１Ａまたは１０１Ｂは、ストレージシステム３０からの応答を所定時間内に受信することができず、タイムアウトが発生する。その後、コマンド発行装置１０１Ａまたは１０１Ｂは、改めてＩ／Ｏ要求をストレージシステム３０に発行する。Ｉ／Ｏ要求が再発行される時点で障害処理が実施されており、障害から回復していれば、Ｉ／Ｏ要求は正常に処理される。

他の一つの方針は、Ｉ／Ｏ処理を完了させるものである（Ｓ１３３）。即ち、障害箇所を閉塞する等の障害処理を実行した後、Ｉ／Ｏ要求を継続して処理する。

ストレージシステム３０は、Ｉ／Ｏ要求を継続して受け付けるため、既に障害が発生している場合は、直ちに障害復旧プログラムＰ１５に切り替わり、Ｉ／Ｏ処理が完了せずに終了する場合もある。なお、正常処理と障害復旧処理のいずれを実行させるかはＣＰＵのコア単位で決定されることにしてもよい。また、Ｉ／Ｏ要求毎に識別子を付与し、どのＩ／Ｏ要求が一連のＩ／Ｏ処理のどの部分の処理まで完了しているかを示す追跡情報をメモリに登録しておくことができる。

なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。

例えば、ＦＯＳは、ハイパバイザとのハートビート通信により、ハイパバイザの生死を検出できる。図１５で説明したＦＯＳの生死を確認するためのビットをセットまたはリセットする方法の場合、ハイパバイザに障害が発生すると、ビットをセットすることができなくなる。そこで、ＦＯＳは、ビットがセットされているか確認してからリセットする。これにより、ＦＯＳは、ビットがセットされていない場合、ハイパバイザに障害が発生していると判断できる。

上記実施例では、ハイパバイザからの指示でＦＯＳがリセット処理を実行する場合を説明したが、ＦＯＳは自身でリセット処理を実行してもよい。例えば、フェイルオーバのペアを形成するＦＯＳ同士をリセット線で接続しておき、いずれかのＦＯＳが自主的にリセットした場合は、リセットしたことを相手ＦＯＳにリセット線を介して知らせる。相手ＦＯＳは、自クラスタのハイパバイザからのフェイルオーバ指示を待ち、予め決めた時間内にハイパバイザからのフェイルオーバ指示を受領できない場合、相手ＦＯＳがリセットした信号を受け取ったことをハイパバイザに知らせる。その知らせを受けたハイパバイザはブロック制御部に伝達する。ブロック制御部は、フェイルオーバ処理の実行を決定して、フェイルオーバ指示をハイパバイザを介してＦＯＳに伝達する。

ブロック制御部とハイパバイザの死活監視も、ＦＯＳとハイパバイザの間の死活監視と同様に行うことができる。また、本実施形態で述べた種々の特徴や観点は適宜組み合わせることができる。

３０：ストレージシステム、３１Ａ、３１Ｂ：ＣＰＵ（制御プロセッサ）、３２Ａ、３２Ｂ：メモリ、３３Ａ、３３Ｂ：ディスクインターフェース、３４：ディスクデバイス、３５Ａ、３５Ｂ：ＨＢＡ、３６Ａ、３６Ｂ：ＮＩＣ、４１Ａ、４１Ｂ：コントローラボード、４３Ａ、４３Ｂ：障害監視部、５０Ａ、５０Ｂ：クラスタ、１０１Ａ、１０１Ｂ：コマンド発行装置

Claims (13)

1. ファイルアクセス要求およびブロックアクセス要求を処理するストレージシステムにおいて、
   複数のクラスタと、
   前記各クラスタに跨がって設けられ、ディスクデバイスへのブロックアクセス要求を制御する第１制御部と、
   前記各クラスタにそれぞれ個別に設けられ、仮想化制御部で管理される仮想マシン上で動作してファイルアクセス要求を処理する複数の第２制御部と、
   前記各クラスタ内に設けられ、該各クラスタ内での障害を検出する障害検出部と、
   前記第１制御部に設けられ、前記各障害検出部で検出された障害に関する障害情報を集約管理する障害情報管理部と、
   を備えるストレージシステム。
2. 前記第１制御部内には障害回復部が設けられており、
   前記障害回復部は、前記障害情報管理部で管理される障害に対処するための処理内容を決定し、この決定した処理内容の実行を、前記第１制御部、前記第２制御部または前記仮想化制御部のうち、前記障害の発生した箇所を担当する制御部に指示する、
   請求項１に記載のストレージシステム。
3. ハードウェア資源を論理的に分割して得られる第１の資源部分と第２の資源部分のうち、前記第２の資源部分に優先して生成される前記第１の資源部分を前記第１制御部に割当て、前記第２資源部分を前記仮想化制御部を介して前記複数の第２制御部に分配する、請求項２に記載のストレージシステム。
4. 前記各クラスタには第１クラスタと第２クラスタとが含まれており、
   前記第１制御部は、前記第１クラスタ内でのブロックアクセス要求を処理する第１クラスタ内第１制御部と、前記第２クラスタ内でのブロックアクセス要求を処理する第２クラスタ内第１制御部と、前記第１クラスタ内第１制御部と前記第２クラスタ内第１制御部とを双方向通信可能に接続する接続部とを含んで構成される、
   請求項３に記載のストレージシステム。
5. 前記第１制御部と前記仮想化制御部とにより共有される第１共有メモリと、
   前記仮想化制御部と前記複数の第２制御部とにより共有される第２共有メモリと、
   を備え、
   前記障害情報は前記第１共有メモリを介して、または前記第１共有メモリと前記第２共有メモリとを介して、前記障害情報管理部に送られる、
   請求項４に記載のストレージシステム。
6. 前記第１クラスタ内第１制御部と前記第２クラスタ内第１制御部とはそれぞれ専用のメモリ領域を有しており、
   前記第１クラスタ内第１制御部は、前記第１クラスタ内で生じた障害に関する第１障害情報を、前記第１クラスタ内第１制御部の使用する第１専用メモリ領域と前記第２クラスタ内第１制御部の使用する第２専用メモリ領域とに二重書きすることで、前記第１障害情報を前記第２クラスタ内第１制御部に通知し、
   前記第２クラスタ内第１制御部は、前記第２クラスタ内で生じた障害に関する第２障害情報を、前記第２専用メモリ領域と前記第１専用メモリ領域とに二重書きすることで、前記第２障害情報を前記第１クラスタ内第１制御部に通知する、
   請求項５に記載のストレージシステム。
7. 前記障害検出部は、前記第１制御部、前記第２制御部、前記仮想化制御部にそれぞれ割り当てられている前記ハードウェア資源で生じた障害を検出するハードウェア障害検出部と、少なくとも前記複数の第２制御部で生じる障害を検出するソフトウェア障害検出部とを含む、
   請求項６に記載のストレージシステム。
8. 前記ハードウェア障害検出部は、前記複数の第２制御部に分配されたハードウェア資源に関する障害を検出した場合、その障害について前記仮想化制御部に通知し、
   前記仮想化制御部は、前記ハードウェア障害検出部からの通知を受領すると、前記複数の第２制御部のうち前記障害が発生した第２制御部に対して、前記障害が検出されたことを通知する、
   請求項７に記載のストレージシステム。
9. 前記第１クラスタ内の前記複数の第２制御部と前記第２クラスタ内の前記複数の第２制御部とが共有する共有ボリュームを設け、
   前記共有ボリュームには、前記各第２制御部がそれぞれ管理する構成情報を記憶させておき、
   通常時には、前記各第２制御部は自身の担当する構成情報のみを参照でき、フェイルオーバ時には、フェイルオーバのペアを形成する相手方の第２制御部の担当する構成情報も参照可能となるように制御する、
   請求項８に記載のストレージシステム。
10. 前記第１クラスタおよび前記第２クラスタはそれぞれ、
    ブロックアクセス要求を発行するホスト装置と通信可能に接続されるブロックアクセス要求用の通信制御部と、
    ファイルアクセス要求を発行するホスト装置と通信可能に接続されるファイルアクセス要求用の通信制御部と、
    前記ディスクデバイスとの間でデータを読み書きするためのディスクインターフェース部と、
    前記ブロックアクセス要求用の通信制御部と前記ファイルアクセス要求用の通信制御部および前記ディスクインターフェース部と通信可能に接続されるコントローラと、
    前記コントローラ内に設けられるメモリと、
    前記コントローラ内に設けられるプロセッサと、
    前記各通信制御部と前記ディスクインターフェース部と前記メモリおよび前記プロセッサに関する障害を監視する前記障害検出部と、
    を備えており、
    前記第１クラスタの有する前記コントローラと前記第２クラスタの有する前記コントローラとは、前記接続部を構成する内部直結バスにより接続されている、
    請求項９に記載のストレージシステム。
11. ファイルアクセス要求およびブロックアクセス要求を処理するストレージシステムの障害管理方法であって、
    前記ストレージシステムは、
    複数のクラスタと、
    前記各クラスタに跨がって設けられ、ディスクデバイスへのブロックアクセス要求を制御する第１制御部と、
    前記各クラスタにそれぞれ個別に設けられ、仮想化制御部で管理される仮想マシン上で動作してファイルアクセス要求を処理する複数の第２制御部と、
    を備えており、
    前記各クラスタ内での障害を検出した場合は、検出された前記障害に関する障害情報を前記障害の発生したクラスタ内の前記第１制御部に通知する、
    ストレージシステムの障害管理方法。
12. 前記第１制御部は、通知された前記障害に対処するための処理内容を決定し、この決定した処理内容の実行を、前記第１制御部、前記第２制御部または前記仮想化制御部のうち、前記障害の発生した箇所を担当する制御部に指示する、
    請求項１１に記載のストレージシステムの障害管理方法。
13. ハードウェア資源を論理的に分割して得られる第１の資源部分と第２の資源部分のうち、前記第２の資源部分に優先して生成される前記第１の資源部分は前記第１制御部に割り当てられており、前記第２資源部分は前記仮想化制御部を介して前記複数の第２制御部に分配されている、
    請求項１２に記載のストレージシステムの障害管理方法。

Images