特許 6235163 計算機システム及びその制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6235163

(24)【登録日】2017年11月2日

(45)【発行日】2017年11月22日

(54)【発明の名称】計算機システム及びその制御方法

(51)【国際特許分類】

   G06F 3/06 20060101AFI20171113BHJP

   G06F 13/10 20060101ALI20171113BHJP

【ＦＩ】

   G06F3/06 305Z

   G06F13/10 340A

【請求項の数】12

【全頁数】16

(21)【出願番号】特願2016-558483(P2016-558483)

(86)(22)【出願日】2014年11月12日

(86)【国際出願番号】JP2014079905

(87)【国際公開番号】WO2016075765

(87)【国際公開日】20160519

【審査請求日】2017年2月13日

(73)【特許権者】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110000279

【氏名又は名称】特許業務法人ウィルフォート国際特許事務所

(72)【発明者】

【氏名】荒木 亮彦

(72)【発明者】

【氏名】野中 裕介

(72)【発明者】

【氏名】高田 正法

(72)【発明者】

【氏名】岡田 尚也

【審査官】 田名網 忠雄

(56)【参考文献】

【文献】 特開２００４−２２０２１６（ＪＰ，Ａ）

【文献】 特開２０１０−２１８１９８（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ３／０６−３／０８

Ｇ０６Ｆ １３／１０−１３／１４

(57)【特許請求の範囲】

【請求項1】

制御部と記憶部と、前記制御部と接続される少なくとも１のモジュールを有する計算機システムであって、
前記少なくとも１のモジュールは異なる用途を有する複数のパスによって前記制御部と接続され、
前記記憶部は、
前記モジュールの種類と、前記モジュールの種類に応じた障害処理範囲を管理する障害処理範囲情報と、
各前記パスまたは前記モジュールで障害が起きた場合の閉塞範囲を規定する閉塞範囲情報とを有し、
前記制御部は、
前記モジュールと前記パスの接続情報と、前記障害処理範囲情報に基づいて、前記パスと前記パスに接続される前記モジュールと前記パスまたは前記モジュールの何れかで障害が起きた場合に閉塞する必要があるパスと前記モジュールとの関係を生成し、前記閉塞範囲情報として記憶し、
前記パスでの障害を検知すると、前記閉塞範囲情報に基づいて、前記障害が起きたパスに接続される前記モジュールと当該モジュールに接続される別の前記パスについて閉塞処理を行う計算機システム。

【請求項2】

請求項１記載の計算機システムであって、
前記制御部は前記少なくとも１のモジュールと関係する処理を実行する複数の処理部を有し、
前記少なくとも１のモジュールは前記複数の処理部それぞれと別のパスで接続されている計算機システム。

【請求項3】

請求項１記載の計算機システムであって、
前記モジュールでの障害を検知すると、
前記モジュールと、当該モジュールに接続される前記複数のパスとの閉塞を行う計算機システム。

【請求項4】

請求項２記載の計算機システムであって、
前記計算機システムはブロックインタフェースとファイルインタフェースを有するストレージシステムであって、
前記少なくとも１のモジュールはファイルインタフェースであって、
第１の前記処理部は、接続される前記パスを通じてファイルインタフェースの制御をおこなうファイルＩ／Ｏ処理部であって、第２の前記処理部は前記ファイルインタフェースを介してホストとやり取りされるデータのストレージへのＩ／Ｏを制御するブロックＩ／Ｏ処理部である計算機システム。

【請求項5】

請求項４記載の計算機システムであって、
前記ブロックＩ／Ｏ処理部の指示により前記閉塞処理が実行される計算機システム。

【請求項6】

請求項４記載の計算機システムであって、
前記ブロックインタフェース又は前記ブロックインタフェースに接続されるパスで障害が発生した場合には、
当該ブロックインタフェース及び前記ブロックインタフェースに接続されるパスについて閉塞処理を実行する計算機システム。

【請求項7】

制御部と記憶部と、前記制御部と接続される少なくとも１のモジュールを有する計算機システムで実行される計算機システム制御方法あって、
前記少なくとも１のモジュールは用途の異なる複数のパスで他の部位と接続され、
前記制御部は、
前記モジュールと前記パスの接続情報と、前記モジュールの種類と前記モジュールの種類に応じた障害処理範囲を管理する障害処理範囲情報とに基づいて、各前記パスまたは前記モジュールで障害が起きた場合の閉塞範囲を管理する閉塞範囲情報を生成し、
前記パスでの障害を検知し、
前記閉塞範囲情報を参照し、
前記障害が起きたパスに接続される前記モジュールと当該モジュールに接続される別の前記パスについての閉塞処理を行う計算機システム制御方法。

【請求項8】

請求項７記載の計算機システム制御方法であって、
前記計算機システムの前記制御部は前記少なくとも１のモジュールと関係する処理を実行する複数の処理部を有し、
前記少なくとも１のモジュールは前記複数の処理部それぞれと別のパスで接続されている計算機システム制御方法。

【請求項9】

請求項７記載の計算機システム制御方法であって、
前記制御部は、
前記モジュールでの障害を検知すると、
前記モジュールと、当該モジュールに接続される複数の前記パスとの閉塞を行う計算機システム制御方法。

【請求項10】

請求項８記載の計算機システム制御方法あって、
前記計算機システムはブロックインタフェースとファイルインタフェースを有するストレージシステムであって、
前記少なくとも１のモジュールはファイルインタフェースであって、
第１の前記制御部は、接続される前記パスを通じてファイルインタフェースの制御をおこなうファイルＩ／Ｏ処理部であって、第２の前記制御部は前記ファイルインタフェースを介してホストとやり取りされるデータのストレージへのＩ／Ｏを制御するブロックＩ／Ｏ処理部である計算機システム制御方法。

【請求項11】

請求項１０記載の計算機システム制御方法であって、
前記ブロックＩ／Ｏ処理部の指示により前記閉塞処理が実行される計算機システム制御方法。

【請求項12】

請求項１０記載の計算機システム制御方法であって、
前記制御部は、
前記ブロックインタフェース又は前記ブロックインタフェースに接続されるパスで障害が発生した場合には、
当該ブロックインタフェース及び前記ブロックインタフェースに接続されるパスについて閉塞処理を実行する計算機システム制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ストレージ装置に関する。

【背景技術】

【0002】

通常、システムを構築するモジュール同士は1本あるいは複数のパスで接続される。1本で接続されるような場合、何れかのモジュールあるいは接続パスに障害が発生した場合には、当該モジュール及び当該接続パスを閉塞することで障害の影響範囲を限定し、システム全体の耐障害性を高めている（例えば、特許文献１参照）。

【0003】

モジュール同士を複数のパスで接続する意図は、冗長性や性能の向上である。この場合、何れかのモジュールで障害が発生した場合には、当該モジュールと接続パス全てを閉塞する。複数ある接続パスのうち何れか1本に障害が発生した場合には、当該接続パスのみを閉塞し、残存パスで動作を継続する場合もある。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】米国特許第 ８４０２１８９号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

処理対象となるデータの多様化に伴い、複数の多様なモジュールを接続してシステムを構築することも多くなっている。更に、処理対象とするデータの種類に応じてストレージコントローラ内でも複数の処理プログラムが準備されることもある。

【0006】

こうしたシステムの複雑化を背景に、１つのモジュールが、他のモジュールと２本以上のパスで接続され、かつ夫々のパスは異なる用途に使われるような形態が想定される。

【0007】

単一のデバイスでありながら異なる目的で仕様されるパスで接続されるハードウェアを搭載する場合、片方のパス上で恒久的な障害が発生した場合、そのデバイスやパスだけを閉塞させてしまうと、他方のパスに障害が波及してＣＰＵやその他デバイスの正常稼動を妨げる恐れがある。

【課題を解決するための手段】

【0008】

上記課題を解決するために、本発明は、制御部と記憶部と、前記制御部と接続される少なくとも１のモジュールを有しており、少なくとも１のモジュールは異なる用途を有する複数のパスによって前記制御と接続されている計算機システムを開示する。記憶部は、各前記パスまたは前記モジュールで障害が起きた場合の閉塞範囲を規定する閉塞範囲情報を有しており、制御部は、前記パスでの障害を検知すると、閉塞管理情報に基づいて、障害が起きたパスに接続される前記モジュールと当該モジュールに接続される別の前記パスについて閉塞処理を行う。

【発明の効果】

【0009】

本願は、複数のパスを使用する単一デバイスを搭載するような形態においても適切な範囲で障害処理を実施し、システムの信頼性や可用性を向上させることができる。

【図面の簡単な説明】

【0010】

【図1】本発明における、ストレージシステムの装置構成の一例を示す図である。

【図2】本発明における、ストレージシステムの装置構成の一例を示す図である。

【図3】本発明における、ストレージシステムが備えるデバイスタイプテーブルの一例を示す図である。

【図4】本発明における、障害処理範囲管理テーブルの一例を示す図である。

【図5】本発明における、障害処理範囲管理テーブルを作成するための処理例を示すフローチャートである。

【図6】本発明における、障害処理範囲管理テーブルを作成するための処理例を示すフローチャートである。

【図7】本発明における、ストレージシステムの障害処理例を示すフローチャートである。

【発明を実施するための形態】

【0011】

以下、各図を参照しながら本発明の実施形態の一例を説明する。なお、以下の実施例において、同一の構造部を持ち、同一の符号を付した部分は、原則として同一の動作を行うため、重複する説明を省略した。

【0012】

近年では、複数種類のホストインタフェースプロトコルに対応した、ユニファイドストレージが注目されている。複数種類のホストインタフェースとは、ＳＣＳＩコマンドのような、ブロック単位のアクセス要求を受ける、ＦＣＰ（Ｆｉｂｅｒ Ｃｈａｎｎｅｌ Ｐｒｏｔｏｃｏｌ ｆｏｒ ＳＣＳＩ）やｉＳＣＳＩ（ｉｎｔｅｒｎｅｔ ＳＣＳI）であったり、ファイル単位のアクセス要求を受ける、ＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）)やＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）であったりする。本実施例ではストレージシステムの一例としてこのユニファイドストレージを用いて本発明を開示する。

【0013】

ユニファイドストレージの実現方式として、ストレージ装置内に複数のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やハードウェアを共存させ、データは装置内のディスクアレイに一元的に格納する形態が考えられる。例えば、ファイルサービス機能を有するハードウェア群をブロックストレージのＰＣＩｅ（ＰＣＩ Ｅｘｐｒｅｓｓ）デバイスとして接続し、ブロックストレージ全体を制御するソフトウェアであるブロックプログラムとファイルサービス機能を有するハードウェア群を制御するソフトウェアであるファイルプログラムとをブロックストレージのコントローラのＣＰＵ上にて同時稼動させる形態である。ブロックプログラムがＦＣＰやｉＳＣＳＩのプロトコル処理を、ファイルプログラムあるいはファイルサービス機能を有するハードウェア群がＣＩＦＳやＮＦＳのプロトコル処理を、それぞれ担当する。

【0014】

ファイルプログラムやファイルサービスを提供するハードウェア群が担当するＣＩＦＳやＮＦＳといったプロトコル処理は、ファイルサービス機能を有するハードウェア群やファイルプログラムが提供するファイルシステム機能を経由してディスクＩ/Ｏ、つまりＳＣＳＩコマンドとしてブロックプログラムに発行される。従来のファイルサーバとブロックストレージの間には、物理結線としてはＦＣケーブルなどが使用され、プロトコルとしてはＦＣＰやｉＳＣＳＩが使用されていたが、単一のストレージ装置内にファイルサービス機能を搭載する場合、例えばＰＣＩｅによる接続が考えられる。この場合、ファイルサービス機能を有するハードウェア群は、単一のＰＣＩｅデバイスでありながら、ＣＰＵとは２本以上のＰＣＩｅパスで接続されることになる。複数のＰＣＩｅパスの一部はファイルプログラムによる制御用途であり、他の一部はＳＣＳＩコマンドやデータのやり取りであってブロックプログラムに接続される。

【0015】

図１は、本発明の対象とするシステム構成の一例の概略を示す図である。ストレージシステム１００は、コントローラ１０１、ファイルサービスモジュール１０８、ディスクインタフェース１０９とを備える。コントローラ１０１はその内部に、プロセッサ１０２、メモリ１０３、ハードウェア群１１０を備え、内部ネットワーク１０７で相互に接続される。内部ネットワーク１０７は、ファイルサービスモジュール１０８、ディスクインタフェース１０９とも接続される。

【0016】

メモリ１０３は、論理ボリューム１１１に格納されるデータや制御情報の一時的な格納領域であるキャッシュメモリ１０４の他に制御プログラム１０５と、ストレージ管理情報１０６を格納する。キャッシュメモリ１０４と制御プログラム１０５、ストレージ管理情報１０６は物理的に異なるメモリに格納されてもよい。プロセッサ１０２はＣＰＵを有し、制御プログラム１０５によってストレージシステム１００全体を制御する。ハードウェア群１１０としては、不揮発メモリ、ストレージシステム１００外部の管理コンピュータとストレージシステム１００とを繋ぐインタフェース、電力供給ハードウェア、プロセッサ１０２が動作不可能な状態に陥った場合にストレージシステム１００を安全に停止させ、外部に通報するための障害処理補助装置等が含まれる。論理ボリューム１１１は、単一あるいは複数の不揮発記憶媒体の記憶領域から論理的に構築した記憶領域であり、データや制御情報が格納される。

【0017】

制御プログラム１０５は、プロセッサ１０２上で稼動するソフトウェアプロプログラムであり、本発明においては複数種類のプログラムが存在する。本実施例では、ブロック単位のアクセス要求に対するサービス（ブロックサービス）を提供する、ブロックプログラム１２０と、ファイルサービスモジュール１０８を制御するファイルプログラム１３０を少なくとも有する。つまり２つの異なるデバイスを制御する異なるプログラムが動作する。各プログラムは、コントローラ１０１上で独立に稼動してもよいし、ブロックプログラム１２０の構成要素の一つとしてファイルプログラム１３０が稼動してもよい。更に、制御プログラム１０５には外部の管理コンピュータと通信して管理機能を提供するプログラム、ストレージシステム１００全体の稼動監視や障害処理を提供するプログラムが含まれる。

【0018】

障害処理とは、ＣＰＵやＤＩＭＭ、ＰＣＩｅデバイスのようなストレージ装置を構成するハードウェアで生じた障害を検出し回復する一連の処理である。回復とは、例えば恒久的な障害により使用不可となったり、一時的な障害が短期間に多発したりして安定稼動に影響を及ぼすような場合に、障害ハードウェアをシステムから切り離す、いわゆる閉塞処理も含まれる。閉塞処理は、システムの可用性を向上させるためには、可能な限り障害を起こしたハードウェアのみを切り離す、いわゆる部分閉塞ができることが望ましい。

【0019】

またこれらのプログラムはストレージシステム１００の用途に応じて柔軟に稼動・非稼動を切り替えてもよい。例えば、ファイルサービスモジュール１０８が搭載されている場合のみ、ファイルサービスモジュール１０８を制御するプログラムが稼動するようにしてよい。またブロックサービスを提供するプログラムが障害処理を提供してもよい。ただし、ブロックサービスを提供するプログラムや障害処理を提供するプログラムは、常に稼動する構成が望ましい。

【0020】

ブロックインタフェースモジュール１１２は、ＦＣＰやｉＳＣＳＩといったブロックインタフェースを提供するモジュールであり、ホストコンピュータ２００からのＳＣＳＩコマンドの授受及びホストコンピュータ２００とのデータの転送を実施する。ブロックインタフェースモジュール１１２はストレージシステム１００から独立して搭載・交換されてもよい。ブロックインタフェースモジュール１１２は内部ネットワーク１０７とＩ／Ｏパス３００により接続されており、ブロックインタフェースモジュール１１２を介してホストコンピュータ２００と送受信されるユーザデータがやり取りされる。

【0021】

ファイルサービスモジュール１０８は、ファイルプログラムあるいはファイルサービス機能を有するハードウェア群を有し、ＣＩＦＳやＮＦＳのプロトコル処理してファイルサービスを提供する機能を有している。ファイルサービスモジュール１０８はストレージシステム１００から独立して搭載・交換されてもよいが、内部ネットワーク１０７を介してプロセッサ１０２が制御する。ファイルサービスモジュール１０８はホストコンピュータ２００と接続され、ホストコンピュータ２００からのＩ/Ｏ要求やデータの授受を行う。ファイルサービスモジュール１０８と内部ネットワーク１０７は、Ｉ/Ｏパス３０１と制御パス３０２で接続される。Ｉ/Ｏパス３０１は、ファイルサービスモジュール１０８が発行するブロックＩ/Ｏの通信路であり、ファイルサービスモジュール１０８を介してホストコンピュータ２００と送受信されるユーザデータがやり取りされる。制御パス３０２は、ファイルサービスモジュール１０８の制御のための通信路であり、ユーザデータはやり取りされず、制御プログラム１０５と制御信号をやり取りする。ファイルサービスモジュール１０８の制御とは、例えば、ファイルサービスモジュール１０８の内部で稼動するハードウェアの状態の管理、装置外部の管理コンピュータからの操作に応じてファイルサービスモジュール１０８のパラメータ設定、ファイルサービスモジュール１０８が提供する機能の制御・管理などを指す。Ｉ/Ｏパス３０１と制御パス３０２は例えばＰＣＩｅのような内部パスであり、Ｉ/Ｏパス３０１と制御パス３０２は物理的には同じ種類の接続パスであってもよい。

【0022】

ストレージ管理情報１０６は、ストレージシステム１００が動作する上で必要となる各種情報であり、図３に示すデバイスタイプテーブル、図４に示す閉塞範囲管理テーブル４０２を含む。その他、例えばキャッシュメモリ１０４を管理するためのディレクトリ情報、スナップショットやデータコピープログラム機能の実現に必要な管理情報、ストレージシステム１００が備えるファイルサービスモジュール１０８やＩ/Ｏパス３０１や制御パス３０２やプロセッサ１０２などの部品の状態を管理する構成情報であったりする。構成情報とは、例えばファイルサービスモジュール１０８がストレージシステム１００から取り外された場合は未実装状態として管理し、障害などの要因により搭載しているが稼動していない場合は閉塞状態として管理する。ファイルサービスモジュール１０８が閉塞状態である場合、そのファイルサービスモジュール１０８に接続されるＩ/Ｏパス３０１と制御パス３０２も同時に閉塞状態としてもよい。ブロックインタフェースモジュール１１２が搭載されている構成では、ブロックインタフェースモジュール１１２の閉塞状態である場合、そのブロックインタフェースモジュール１１２に接続されるＩ／Ｏパス３００も同時に閉塞状態としてもよい。プロセッサ１０２がＣＰＵコア毎に閉塞可能な場合、後述するファイルプログラム１３０が使用するＣＰＵコアが閉塞状態である場合、ブロックインタフェースモジュール１１２も同時に閉塞状態としてもよい。

【0023】

図２は、図１のプロセッサ１０２で稼動する制御プログラム１０５に含まれるブロックプログラム１２０とファイルプログラム１３０とファイルサービスモジュール１０８、論理ボリューム１１１との対応関係を主眼を置いた図である。ブロックプログラム１２０とファイルプログラム１３０何れのプログラムもプロセッサ１０２によって実行されることによって、ブロックＩ／Ｏ処理部とファイルＩ／Ｏ処理部とを実現することになる。

【0024】

ファイルプログラム１３０はファイルサービスモジュール１０８の制御を司り、制御パス３０２を通じて、例えば、ファイルサービスモジュール１０８の内部で稼動するハードウェアの状態の管理や、装置外部の管理コンピュータからの操作に応じてファイルサービスモジュール１０８のパラメータ設定や、ファイルサービスモジュール１０８が提供する機能の制御・管理などを実施する。ファイルプログラム１３０はまた、制御パス３０２を介して、ホストコンピュータ２００から受領したＩ/Ｏ要求を必要に応じてブロックプログラム１２０に転送するようファイルサービスモジュール１０８を制御する。ファイルプログラム１３０はブロックインタフェースモジュール１１２とは関連しない。

【0025】

一方、ブロックプログラム１２０はブロックＩ/Ｏを処理するソフトウェアである。ブロックプログラム１２０はブロックインタフェースモジュール１１２からのブロックＩ/Ｏ要求をＩ/Ｏパス３００を介して受領し、Ｉ／Ｏ要求に従って論理ボリューム１１１に格納したユーザデータの読み書きを実施し、Ｉ/Ｏパス３００を介してブロックインタフェースモジュール１１２とユーザデータの受け渡しを行う。ブロックプログラム１２０は、更に、ストレージシステム１００が備える各種機能を実施する。各種機能とは、データや論理ボリューム１１１を、ストレージシステム１００内外で複製したり、遠隔地のストレージシステム１００と共有したりする。又、ストレージシステム１００内部のハードウェアを制御したり、装置外部の管理コンピュータにストレージシステム１００の状態を送信し、また管理コンピュータからの要求を受け、論理ボリュームの作成や論理ボリュームを構成する記録媒体の種別を変更したりする。 更に、ファイルサービスモジュール１０８からのブロックＩ/Ｏ要求をＩ/Ｏパス３０１を介して受領し、論理ボリューム１１１に格納したユーザデータの読み書きを実施し、Ｉ/Ｏパス３０１を介してファイルサービスモジュール１０８とユーザデータの受け渡しを行う。

【0026】

本実施例におけるユニファイドストレージシステム構成によれば、ブロックプログラム１２０はストレージシステム１００全体の制御を司り、また各種機能も提供するため、ファイルサービスモジュール１０８からのブロックＩ／Ｏはブロックプログラム１２０を必ず経由することで、ストレージシステム１００が取り扱うデータの全てに対して、一貫したデータの整合性が保証され、また一貫した機能が提供される。

【0027】

望ましい構成においては、ファイルサービスモジュール１０８を含むストレージシステム１００全体の稼動の監視はブロックプログラム１２０が行う。例えばファイルサービスモジュール１０８やブロックインタフェースモジュール１１２、Ｉ／Ｏパス３００、Ｉ/Ｏパス３０１、制御パス３０２で障害が発生した場合、ブロックプログラム１２０が障害を検出し、障害内容に応じた障害処理を実施する。これは、ストレージシステム１００においては、ディスクＩ／Ｏを担当するブロックプログラムの方がより信頼性を要求されるものであり、又、ファイルサービスモジュール１０８が搭載されない構成や、ファイルプログラム１３０が稼動していないことも想定されるからである。

【0028】

なお、ファイルプログラム１３０が、ファイルサービスモジュール１０８で生じる障害のうち、軽度な障害のみ検出し、回復するような構成でもよい。軽度な障害とは、例えばハードウェアで障害を訂正済みな、いわゆるコレクタブルエラーなどである。またコレクタブルエラーが一定期間内に一定回数生じた場合、予防保全としてファイルサービスモジュール１０８の稼動を停止させてよい。この場合、ファイルプログラム１３０とブロックプログラム１２０が通信し、ブロックプログラム１２０が安全にファイルサービスモジュール１０８を停止させればよい。プログラム同士の通信方法としては、共有メモリを介して通信したり、割り込みを上げたりすればよい。ブロックプログラム１２０がハイパバイザ機能を備え、ファイルプログラム１３０が仮想マシンとして稼動するような形態では、通信用ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を使用してもよい。ファイルサービスモジュール１０８の安全な停止とは、具体的にはファイルサービスモジュール１０８の電源を落としたり、あるいはファイルサービスモジュール１０８に接続されるＩ/Ｏパス３０１や制御パス３０２を無効化し、ホストコンピュータ２００とのインタフェース部分を無効化する、といった手段でよい。

【0029】

図３は本発明におけるデバイスタイプテーブル４０１の一例を示す図である。本テーブルは、ストレージ管理情報１０６の構成要素の一つであって予め設定される。本テーブルには、デバイスの種類と、デバイスの種類に応じた障害処理範囲が格納される。システム内の何れかの箇所で障害が発生した場合、当該障害の影響を最小限範囲にとどめシステム全体としては処理を継続させることが望ましい。例えば、ＰＣＩｅデバイスやＰＣＩｅパスで恒久的な障害が起きた場合は、障害を起こしたＰＣＩｅデバイスおよび当該デバイスに接続されるＰＣＩｅパスをリンクダウンすることで閉塞し、ＣＰＵや他のデバイスは継続稼動を続けることが望まれる。一方で、本願のファイルサービスモジュール１０８は、ファイルプログラム１３０とブロックプログラム１２０という２つの異なる制御プログラムに接続されている。例えば制御パス３０１で障害が起きた場合に、接続先のファイルサービスモジュール１０８を閉塞対象とすることは容易である。しかし、本願実施例においては、それだけでは不十分であって、当該ファイルサービスモジュール１０８に接続される制御線３０２についても閉塞する必要がある。これらの状況をふまえて本願ではパスやデバイス毎に障害処理すべき範囲を管理することとする。

【0030】

デバイスの種類とは、ストレージシステム１００を構成するデバイスの種類を特定できる情報である。例えばコントローラ１０１に接続されるファイルサービスモジュール１０８やブロックインタフェースモジュール１１２であったりする。更には、ブロックインタフェースモジュール１１２が備えるプロトコルチップの種類までを定義してもよい。図３ではデバイスタイプ及び障害処理範囲を文章で記載しているが、ブロックプログラム１２０が処理対象デバイスを認識可能な情報であればよく、デバイスタイプが例えば０x０１であればＦｉｂｒｅ Ｃｈａｎｎｅｌ ８Ｇｂｐｓを示す、といったように数値を格納してもよい。

【0031】

ブロックインタフェースモジュール１１２が1または複数の冗長化されたのＰＣＩｅパスによりコントローラ１０１と接続される場合、当該ブロックインタフェースモジュール１１２及び当該ブロックインタフェースモジュール１１２に接続されるＰＣＩｅパスに障害が発生した場合は、当該ブロックインタフェースモジュール１１２及び当該ブロックインタフェースモジュール１１２に接続されるＰＣＩｅパスを同時に閉塞させることが望ましい。よって、ブロックインターフェイス１１２については、当該モジュールとそのデバイスに接続されているパスのみを閉塞対象とすればその他の構成要素に影響は出ない。

【0032】

一方ファイルサービスモジュール１０８はＩ/Ｏパス３０１と制御パス３０２を備えており、ファイルサービスモジュール１０８やＩ/Ｏパス３０１や制御パス３０２に障害が発生し、いずれかが継続使用不可能である場合、閉塞範囲は、当該ファイルサービスモジュール１０８、及び当該ファイルサービスモジュール１０８に接続されるＩ/Ｏパス３０１と制御パス３０２の全てであることが望ましい。例えば制御パス３０２で継続使用不可能な障害が発生し、制御パス３０２のみを閉塞した場合、ファイルサービスモジュール１０８の制御が出来なくなり、Ｉ/Ｏパス３０１上に不正なデータが流れてデータ破壊等が起きる恐れがある。また、例えばＩ／Ｏパス３０１で継続使用不可能な障害が発生した場合、もはやファイルサービスモジュール１０８はブロックＩ／Ｏをブロックプログラム１２０に要求できず、またブロックプログラム１２０からのブロックＩ／Ｏを受領できない。すなわち、ファイルサービスモジュール１０８としての機能を果たすことができないため、ファイルサービスモジュール１０８の交換により機能の回復を試みることが期待される。ファイルサービスモジュール１０８の交換を想定すると、障害の発生していないファイルサービスモジュール１０８とＩ／Ｏパス３０１も同時に閉塞することが望ましい。このように、デバイス毎に障害処理の影響範囲が異なるため、デバイスタイプテーブル４０１にてこれらを管理する。なお、デバイスタイプテーブル４０１自体は静的なテーブルでもよく、ストレージシステム１００が予め固定で備えておいてよい。または、ストレージシステム１００外部の管理コンピュータからの指示により項目を追加してもよい。

【0033】

図４は、本発明における閉塞範囲管理テーブル４０２の一例を示す図である。パス番号、もしくは、任意のデバイスを識別するデバイス識別情報と当該デバイスで障害が発生した場合に、障害対応が必要とされるデバイスを識別する情報である閉塞範囲の情報との対応づけが管理される。例えばコントローラ１０１がＰＣＩｅによりファイルサービスモジュール１０８やブロックインタフェースモジュール１１２などを接続する場合、コントローラ１０１が備えるＰＣＩｅパス番号毎に、その時点で接続されているデバイスと、そのデバイスの識別情報、接続されているデバイスに対応する閉塞範囲が登録される。デバイスタイプは、図３と同様にブロックプログラム１２０が認識できるような数値を格納してもよい。識別情報とは、同一種類のデバイスが複数搭載されるような場合にデバイスを一意に特定可能な情報であり、例えば製造番号などでよい。

【0034】

閉塞範囲は、図３のデバイスタイプテーブルを参照することで設定できる。パス番号を指定する場合にパス番号を1ビットとみなしたビットマップ形式で格納してもよい。本発明ではファイルサービスモジュール１０８はＩ/Ｏパス３０１と制御パス３０２を使用するが、ファイルサービスモジュール１０８が複数搭載されるような場合、Ｉ/Ｏパス３０１と制御パス３０２も複数存在することになる。この場合、閉塞範囲を適切に設定するには、複数のファイルサービスモジュール１０８と複数のＩ/Ｏパス３０１と制御パス３０２の組み合わせを正しく区別する必要があり、これを実現するためにデバイス識別情報を使用する。つまり、デバイス識別情報に基づいて、複数のファイルサービスモジュール１０８と複数のＩ/Ｏパス３０１、複数の制御パス３０２を正しい組み合わせで閉塞範囲を設定する。なお、ストレージシステム１００の制限として同一種類のデバイスが複数搭載されない場合には、デバイス識別情報はなくてもよい。

【0035】

閉塞範囲管理テーブル４０２は、動的に内容が変化する。これは、ファイルサービスモジュール１０８やブロックインタフェースモジュール１１２はストレージシステム１００が稼働中であっても着脱や種類の交換が可能なためである。閉塞範囲管理テーブル４０２は、ストレージシステム１００の起動時あるいはファイルサービスモジュール１０８やブロックインタフェースモジュール１１２の着脱などの契機で作成・更新され、障害発生時の障害処理において参照される。

【0036】

デバイスタイプテーブル４０１や閉塞範囲管理テーブル４０２は、ストレージシステム１００全体の制御を司るプログラムや、障害処理の主体として動くプログラムが更新・参照できることが望ましい。本実施例におけるユニファイドストレージ構成によれば、ブロックプログラム１２０がそれに該当するため、デバイスタイプテーブル４０１や閉塞範囲管理テーブル４０２はブロックプログラム１２０が更新・参照できることとする。

【0037】

図５は、図４の閉塞範囲管理テーブル４０２の更新処理の一例を示すフローチャートである。図５における各処理は、ブロックプログラム１２０が主体的に行うものとするが、本発明はこれを限定するものではなく、例えばブロックプログラム１２０とファイルプログラム１３０、あるいはハードウェア群１１０、装置外部の管理コンピュータとの連動により実施してもよい。例えばブロックプログラム１２０がファイルサービスモジュール１０８やブロックインタフェースモジュール１１２の接続を検出後、直ちに処理を始めても良いし、管理コンピュータからの指示を得てから処理を始めても良い。ハードウェア群１１０がファイルサービスモジュール１０８やブロックインタフェースモジュール１１２の接続を検出し、ブロックプログラム１２０に指示を出した後にブロックプログラム１２０が処理を始めても良い。又、本実施例では更新処理として説明するが、最初に障害範囲管理テーブル４０２を設定する場合にも同様のフローが実行され、Ｓ１００５の処理において初期値が設定される。

【0038】

まず、ストレージシステム１００に接続されたハードウェアを検出する(ステップＳ１００１)。図５におけるハードウェアとはファイルサービスモジュール１０８やブロックインタフェースモジュール１１２を指す。ステップＳ１００１の処理は、例えばストレージシステム１００に予めファイルサービスモジュール１０８を搭載した上でストレージシステム１００の起動処理を開始した際、その起動処理の過程で図５の処理が実施される。

【0039】

次にハードウェアからデバイスタイプを入手する(ステップＳ１００２)。一般的にハードウェアを認識したＣＰＵは当該ハードウェアを使用するためにいくつかの初期化、初期設定を行う。例えばＰＣＩｅデバイスであれば、コンフィグレーション処理がなされる。ステップＳ１００２では、このような初期設定の過程において、接続されたハードウェアから所定の手順によりデバイスタイプを入手する。デバイスタイプとは、デバイスタイプテーブル４０１に示すようなデバイスの種類のことを指す。所定の手順とは、例えばＰＣＩｅデバイスであれば、コンフィグレーション空間レジスタのベンダＩＤやデバイスＩＤの参照によるものでもよい。なお、ステップＳ１００１ではハードウェアが接続された接続パス番号も同時に記憶しておくものとする。

【0040】

次にハードウェアからデバイス識別情報を入手する(ステップＳ１００３)。デバイス識別情報とは、例えば製造番号でよく、デバイスに一意に付与される情報でよい。また、例えばファイルサービスモジュール１０８のように複数のパスを使用する場合は、Ｉ/Ｏパス３０１や制御パス３０２においても、同じデバイス識別情報を見せる必要がある。

【0041】

次にデバイスタイプテーブル４０１を参照し、ステップＳ１００２で入手したデバイスタイプから障害処理範囲を確認する(ステップＳ１００４)。例えばステップＳ１００２で入手したデバイスタイプがファイルサービスモジュール１０８であれば、障害処理範囲は「ファイルサービスモジュール、及びファイルサービスモジュールに接続されているＩ/Ｏパス３０１と制御パス３０２」となる。ステップＳ１００５は、デバイス識別情報を元に閉塞範囲を更新する。ステップＳ１００５は図６にて説明する。

【0042】

図６は、閉塞範囲を更新する処理の一例を示すフローチャートである。まず、ステップＳ１００４で確認した障害処理範囲に、複数のパスが含まれるかを判定する（ステップＳ１２０１）。判定結果がＮｏの場合、閉塞範囲管理テーブル４０２のうち、Ｓ１００１でハードウェアを検出したパス番号に対し、デバイスタイプとデバイス識別情報と閉塞範囲を設定する（ステップＳ１２０２）。ステップＳ１２０１の判定結果がＹｅｓの場合、ステップＳ１２０３に進むステップＳ１２０３以降は、Ｓ１００４で確認した障害処理範囲を設定するため、全てのパスを確認するループ処理を取っている。

【0043】

ステップＳ１２０３では対象パスをパス番号０に設定する。次にステップＳ１２０４では、全てのパスに対して、ステップＳ１２０５からステップＳ１２０８の処理が実施されたか判定する。ステップＳ１２０４の判定結果がＹｅｓであれば処理を終了し、判定結果がＮｏであればステップＳ１２０５に進む。

【0044】

ステップＳ１２０５では、対象パスに接続されているデバイスからデバイスタイプとデバイス識別情報を入手し、ステップＳ１００２とステップＳ１００３で得られたものと一致しているか判定する。判定結果がＹｅｓ場合、ステップＳ１２０６に進み、ＮｏであればステップＳ１２０７に進む。

【0045】

ステップＳ１２０６では、閉塞範囲管理テーブル４０２の対象パスにデバイスタイプとデバイス識別情報、閉塞範囲を設定し、ステップＳ１２０７に進む。ステップＳ１２０７では、対象パス番号をインクリメントし、ステップＳ１２０４へ戻る。

【0046】

デバイスタイプがファイルサービスモジュールであればＩ/Ｏパス３０１と制御パス３０２の２本のパスを使用する。この２本のパスは、接続先のデバイス識別情報が同一である２本のパスであることから特定することができる。例えば、パス番号０とパス番号1にファイルサービスモジュール１０８が接続された場合、パス番号０とパス番号1には同じデバイス識別情報が見えることになる。つまりこの場合、障害範囲管理テーブル４０２の閉塞範囲は、まずパス番号0に対して「パスに接続されているファイルサービスモジュール及びパス番号０」が格納され、次にパス番号1に対して「パスに接続されているファイルサービスモジュール及びパス番号１」が格納される。更に、次に再びパス番号０に対して、同じデバイス識別情報を有している「パス番号１」が追加され、最後にパス番号１に対して同様の理由から「パス番号０」が追加される。

【0047】

一方、デバイスタイプがブロックインタフェースモジュール１１２である場合には、例えばパス番号４にブロックインタフェースモジュール１１２が接続された場合は、障害範囲管理テーブル４０２閉塞範囲は、「パスに接続されているブロックインタフェースモジュール及びパス番号４」が格納される。

【0048】

以上の処理により、パスやデバイスに対する閉塞範囲が設定される。複数のデバイスが搭載されている構成では、例えば、閉塞範囲管理テーブル４０２のパス番号の若番から順番に、ハードウェア図５の処理を繰り返せばよい。

【0049】

図７は、本発明における障害処理の一例を示す処理フローである。図７における各処理は、ブロックプログラム１２０が主体的に行うものとするが、本発明はこれを限定するものではなく、例えばブロックプログラム１２０とファイルプログラム１３０、あるいはハードウェア群１１０、装置外部の管理コンピュータとの連動により実施してもよい。

【0050】

まず、ストレージシステム１００の構成要素で生じた障害を検出する(ステップＳ２００１)。検出方法は、障害部位からの割り込みでもよいし、ストレージシステム１００の構成要素を定期的に監視することで障害を検出してもよい。またはハードウェア群１１１からの通知によるものでもよい。

【0051】

次に、障害発生箇所と障害内容を特定する(ステップＳ２００２)。ステップＳ２００１で障害発生を検出した場合、具体的な障害発生箇所と具体的な障害内容を特定したうえで、適切な障害範囲に対して障害処理を実施する必要がある。ステップＳ２００２では、例えば割り込み種別や割り込みベクタ番号、障害レジスタの内容の確認などの手法により、障害箇所と障害内容を特定する。障害箇所は、例えばパス番号やデバイス識別情報として特定され、障害内容としては訂正可能障害や訂正不可障害、保障コードエラーといった障害種別であったりする。

【0052】

次に、閉塞範囲を決定する(ステップＳ２００３)。ステップＳ２００２で障害箇所と障害内容が特定され、ストレージシステム１００のうち部分的にでも閉塞が必要と判断された場合のみ、ステップＳ２００３以降を実施してよい。障害内容がストレージシステム１００全体に影響するような重大な障害であれば、ステップＳ２００３以降を実施することなく、直ちにストレージシステム１００全体を閉塞してよい。

【0053】

ステップＳ２００３では、ステップＳ２００２で特定した障害箇所に基づいて閉塞範囲管理テーブル４０２を参照し、障害発生部位に対応する閉塞範囲を参照し、閉塞範囲を決定すればよい。例えばステップＳ２００２にて、パス番号0で訂正不可障害が発生したことを特定した場合、ステップＳ２００３では障害範囲管理テーブル４０２のパス番号0の閉塞範囲を参照し、図４で例えるならファイルサービスモジュール（デバイス識別番号が０Ｘ００Ａ１ＤＦ０１）に対応づけられる閉塞範囲を決定する。また、パスではなくファイルサービスモジュール（デバイス識別番号が０Ｘ００Ａ１ＤＦ０１）１０８にて障害が発生した場合には、障害範囲管理テーブル４０２でデバイス識別番号（０Ｘ００Ａ１ＤＦ０１）が管理されるパス番号０、又は、パス番号１の閉塞範囲を参照することで、ファイルサービスモジュール（デバイス固有情報が０Ｘ００Ａ１ＤＦ０１）に対応づけられる閉塞範囲を決定する。

【0054】

最後に、閉塞範囲を閉塞する(ステップS2004)。閉塞処理は、閉塞対象部位によって異なってよい。例えば、本実施例の構成において、ブロックインタフェースモジュール１１２やＰＣＩｅパス３００に恒久的な障害が生じた場合、当該ブロックインタフェースモジュール１１２に繋がるＰＣＩｅパス３００をリンクダウンする。

【0055】

一方で、ファイルサービスモジュール１０８やＩ/Ｏパス３０１や制御パス３０２の少なくともいずれかで恒久的な障害が生じた場合、Ｉ/Ｏパス３０１と制御パス３０２の両方をリンクダウンすることになる。これは、制御パス３０２だけをリンクダウンするとＩ／Ｏパス３０１を使い続けてしまい、制御不能に陥ったファイルサービスモジュール１０８からの不正なデータを受け付けることを回避するためである。また、障害の起きたファイルサービスモジュール１０８は正常なものと交換することができるが、片方のパスだけをリンクダウンした状態で、ファイルサービスモジュール１０８をストレージシステム１００から抜き去ると、別の障害である「突然のリンクダウン(Ｓｕｒｐｒｉｓｅ Ｌｉｎｋｄｏｗｎ)」が発生してしまい、プロセッサ１０２が新たな障害処理を開始するなどの不都合を回避するためである。

【0056】

ファイルサービスモジュール１０８の閉塞の過程の一つとしてファイルプログラム１３０の再起動が必要であれば、既に述べたプログラム間の通信によりブロックプログラム１２０がファイルプログラム１３０を再起動させる。また、ファイルサービスモジュール１０８の閉塞に伴いファイルプログラム１３０の閉塞も必要である場合は、ブロックプログラム１２０がファイルプログラム１３０を閉塞させる。このように、ハードウェアに対する障害処理以外に、ファイルプログラム１３０に対する処理も一連の処理として必要な場合は、障害範囲管理テーブル４０２の閉塞範囲に追加しておけばよいし、あるいは障害範囲管理テーブル４０２に付随処理の列を追加して必要な処理を登録しておけばよい。これらの追加の処理のタイミングとしては図５のステップＳ１００２やステップＳ１００３を実行時、ファイルプログラム１３０から追加処理の通知を受けた契機、ストレージシステム１００外部の管理コンピュータからの指示を受けたタイミング等が考えられる。
上記のように本願発明によれば、複数のデバイスによって構成されるシステムにおいて、あるデバイスが用途の異なる複数のパスによって他の部位と接続されている場合であっても障害時に矛盾なく必要最小限の範囲での閉塞処理を実行することができる。更に、特に複数のパス其々が異なる独立した複数の処理部にそれぞれ接続されている場合であっても有効である。これにより、非障害部位の継続稼動による装置の可用性向上、並びに非障害部位への障害伝搬を防ぐことによる装置の信頼性向上が可能となる。

【0057】

尚、本実施例においては図１に示すブロック機能とファイル機能とを有するユニファイドシステムを前提に本願を説明したが、本発明の適応先は本実施例に限らない。例えば、１のデバイスが複数種類のパスによって他の部位、例えば、異なる処理を実行する複数の処理機構に接続されている場合には本願発明は適応可能である。又、１のデバイスが接続される先の処理部の数は２つ以上であればよい。

【0058】

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。

【符号の説明】

【0059】

１００：ストレージシステム
１０１：コントローラ
１０２：プロセッサ
１０３：メモリ
１０４：キャッシュメモリ
１０５：制御プログラム
１０６：ストレージ管理情報
１０７：内部ネットワーク
１０８：ファイルサービスモジュール
１０９：ディスクインタフェース
１１０：ハードウェア群
１１１：論理ボリューム
１１２：ブロックインタフェースモジュール
１２０：ブロックプログラム
１３０：ファイルプログラム
２００：ホストコンピュータ
３００：Ｉ/Ｏパス
３０１：Ｉ/Ｏパス
３０２：制御パス
４０１：デバイスタイプテーブル
４０２：閉塞範囲管理テーブル

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】