JP6056417B2 - 制御システム、制御システムの異常診断方法及び制御システムの異常診断プログラム - Google Patents

Description

本発明は、制御システム、制御システムの異常診断方法及び制御システムの異常診断プログラムに関するものである。

複数のストレージ装置に対して命令を行なうイニシエータ機能を有するInput/Output Controller（ＩＯＣ）を複数備えるデータストレージシステムが存在する。このようなデータストレージシステムで備えられるＩＯＣは、Serial Attached Small Computer System Interfaceコントローラ（ＳＡＳコントローラ）とも呼ばれる。このようなデータストレージシステムにおいて、いずれかのＩＯＣの異常を検出した場合に、異常を検出したＩＯＣの切り離しを行なう機能を備えるものが知られている。

ここで、データストレージシステムが認識するＩＯＣの異常とは、例えば、以下の４つの場合が挙げられる。
（１）ＩＯＣがＳＡＳコントローラとしての異常状態を報告した場合。
（２）ＩＯＣが応答しなくなった場合。
（３）ＩＯＣが制御している複数のストレージ装置へのアクセスでＳＡＳ経路に関わるエラーが発生した場合。

（４）Data Integrity Fieldの不整合等のストレージシステムとしてデータの異常を検出した場合。
以上のような異常をデータストレージシステムが検出した場合、これらの異常が、ＩＯＣのハード故障により発生しているものか、ＩＯＣのファームの異常動作により発生しているものか、ＩＯＣ以外の要因により発生しているものかを判別することは困難である。

そこで、例えば、ＩＯＣの異常を検出した場合に、ＩＯＣのチップリセットを行なうことが知られている。チップリセット後、ＩＯＣが正常に立ち上がった場合には、データストレージシステムは、検出した異常がＩＯＣのハード故障により発生したものではないと判断し、そのＩＯＣを継続使用する。一方、チップリセット後、ＩＯＣが正常に立ち上がらなかった場合、又は、再度ＩＯＣの異常を検出した場合には、データストレージシステムは、そのＩＯＣをシステムから切り離す。

特表２００８−５４５１９５号公報 特表２００９−５４０４３６号公報

しかしながら、このような従来の技術においては、データストレージシステムの検出した異常がＩＯＣのハード故障により発生したものである場合には、チップリセット後にＩＯＣの異常が再度発生する可能性がある。また、データストレージシステムの検出した異常がＩＯＣ以外の要因により発生したにもかかわらず、チップリセット後に再びＩＯＣの異常を検出した場合に、ＩＯＣには異常がないにもかかわらず切離されてしまうという課題もある。更に、データストレージシステムの検出した異常がＩＯＣのハードの一部故障により発生したものである場合であっても、１つのＩＯＣ全体を異常個所として切離してしまうという課題もある。

１つの側面では、本発明は、異常が検出されたＩＯＣを効率的にシステムから切離すことを目的とする。
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。

このため、この制御システムは、少なくとも２つのコントローラとデータを記憶するメモリとを備え、前記コントローラはそれぞれイニシエータとして制御対象装置の制御を行なう制御システムにおいて、２つのコントローラの一方をイニシエータとし、他方をターゲットとして動作させて、前記２つのコントローラの状態を確認する確認部と、前記確認部により検出された異常なコントローラをターゲットとして正常なコントローラをイニシエータとして動作させ、前記ターゲットに対して前記データへのアクセス処理を実行させ、当該アクセス処理が実行できたか否かに基づき前記異常なコントローラの機能の検証を行なう検証部と、を備える。

開示の制御システムによれば、異常が検出されたＩＯＣを効率的にシステムから切離すことができる。

実施形態の一例としてストレージシステムの機能構成を模式的に示す図である。 （ａ），（ｂ）は、実施形態の一例としてのストレージシステムにおける異常箇所の検証方法を説明する図である。 実施形態の一例としてのストレージシステムにおける異常診断処理を説明するフローチャートである。 実施形態の一例としてのストレージシステムにおける異常診断処理を説明するフローチャートである。 実施形態の第１変形例としてのストレージシステムの機能構成を模式的に示す図である。 実施形態の第１変形例としてのストレージシステムにおける異常診断処理を説明するフローチャートである。 実施形態の第２変形例としてのストレージシステムの機能構成を模式的に示す図である。 実施形態の第２変形例としてのストレージシステムにおける異常診断処理を説明するフローチャートである。

〔Ａ〕一実施形態
以下、図面を参照して制御システム、制御システムの異常診断方法及び制御システムの異常診断プログラムに係る一実施の形態を説明する。ただし、以下に示す実施形態はあくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形（実施形態及び各変形例を組み合わせる等）して実施することができる。

また、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能等を含むことができる。
〔Ａ−１〕システム構成
図１は、実施形態の一例としてストレージシステムの機能構成を模式的に示す図である。

本実施形態の制御システム（ストレージシステム）１は、図１に示すように、コントロールモジュール（ＣＭ）１０、エキスパンダ２０、複数のストレージ装置３０−１〜３０−ｍ（ｍは１以上の整数）及び上位装置（ホスト装置）４０を備える。本ストレージシステム１は、ホスト装置４０に対して記憶領域を提供するものである。
以下、ストレージ装置を示す符号としては、複数のストレージ装置のうち１つを特定する必要があるときには符号３０−１〜３０−ｍを用いるが、任意のストレージ装置を指すときには符号３０を用いる。

ＣＭ１０とエキスパンダ２０とは、物理配線（物理リンク）としてのｐｈｙ５０ａ−１〜５０ａ−４，５０ｂ−１〜５０ｂ−４を介して接続されている。また、エキスパンダ２０とストレージ装置３０とは、ｐｈｙ５０ｃを介してそれぞれ接続されている。更に、ＣＭ１０とホスト装置４０とは、ｐｈｙ５０ｄを介して接続されている。
ホスト装置４０は、例えば、サーバ機能を備えたコンピュータ（情報処理装置）である。図１に示す例では、１つのホスト装置４０を備えているが、例えば、２つ以上のホスト装置４０を備えることとしても良い。

エキスパンダ２０は、ＣＭ１０とストレージ装置３０とを中継するものであり、ホスト装置Input/Output（Ｉ／Ｏ）に基づくデータ転送を行なう。すなわち、ＣＭ１０は、本ストレージシステム１に備えられた各ストレージ装置３０に対して、エキスパンダ２０を介してアクセスする。
エキスパンダ２０は、図１に示すように、ワイドポート（Wide Port）２１−１，２１−２及びストレージポート２２を備える。ストレージポート２２は、ｍ個のポートを備えて構成され、これらのポートには、ストレージ装置３０がそれぞれ１つずつ接続されている。

ワイドポート２１−１は、複数（本実施例では４本）のｐｈｙ５０ａ−１〜５０ａ−４を介してＣＭ１０の後述するワイドポート１２１−１と接続するためのポートである。以下、ワイドポート１２１−１，２１−１間を接続するｐｈｙを示す符号としては、複数のｐｈｙのうち１つを特定する必要があるときには符号５０ａ−１〜５０ａ−４を用いるが、任意のｐｈｙを指すときには符号５０ａを用いる。

ワイドポート２１−２は、複数（本実施例では４本）のｐｈｙ５０ｂ−１〜５０ｂ−４を介してＣＭ１０の後述するワイドポート１２１−２と接続するためのポートである。以下、ワイドポート１２１−２，２１−２間を接続するｐｈｙを示す符号としては、複数のｐｈｙのうち１つを特定する必要があるときには符号５０ｂ−１〜５０ｂ−４を用いるが、任意のｐｈｙを指すときには符号５０ｂを用いる。

すなわち、ワイドポート２１−１, ２１−２には、それぞれｐｈｙ５０ａ，５０ｂと同数（本実施形態ではそれぞれ４つ）のポートが備えられ、これらのポートにはｐｈｙ５０ａ，５０ｂがそれぞれ１つずつ接続される。すなわち、ワイドポート２１−１, ２１−２は、それぞれｐｈｙ５０ａ，５０ｂに対応して備えられている。また、ワイドポート２１は、ＣＭ１０の後述するＩＯＣ１２−１及びＩＯＣ１２−２と同数備えられている（本実施形態では２つ）。

ストレージ装置３０は、データを読み書き可能に格納する記憶装置であり、例えば、Hard Disk Drive（ＨＤＤ）である。図１に示す例においてはｍ個のストレージ装置３０が備えられており、これらのストレージ装置３０は、互いに同様の構成を備えている。
ＣＭ１０は、Central Processing Unit（ＣＰＵ）１１、ＩＯＣ１２−１、ＩＯＣ１２−２、メモリ１３及びホストアダプタ（ＨＡ）１４を備える。

以下、ＩＯＣ１２−１をＩＯＣ＃０と、ＩＯＣ１２−２をＩＯＣ＃１という場合がある。
また、以下、特定のＩＯＣを指す場合は、「ＩＯＣ１２−１」、「ＩＯＣ＃０」、「ＩＯＣ１２−２」または「ＩＯＣ＃１」と表記するが、任意のサーバ装置を指す場合は、「ＩＯＣ１２」と表記する。

これらのＣＰＵ１１、ＩＯＣ１２、メモリ１３及びＨＡ１４は、例えば、Peripheral Component Interconnectバス（ＰＣＩバス）ＢＳを介して通信可能に接続されている。
ＨＡ１４は、自装置（ＣＭ１０）とホスト装置４０とを通信可能に接続する機能を備える。
ＩＯＣ＃０及びＩＯＣ＃１は、それぞれワイドポート１２１−１，１２１−２を備える。

ワイドポート１２１−１は、ｐｈｙ５０ａを介してエキスパンダ２０のワイドポート２１−１と接続するためのポートである。
ワイドポート１２１−２は、ｐｈｙ５０ｂを介してエキスパンダ２０のワイドポート２１−２と接続するためのポートである。
すなわち、ワイドポート１２１−１，１２１−２には、それぞれｐｈｙ５０ａ，５０ｂと同数（本実施形態ではそれぞれ４つ）のポートが備えられ、これらのポートにはｐｈｙ５０ａ，５０ｂがそれぞれ１つずつ接続される。すなわち、ワイドポート１２１−１，１２１−２は、それぞれｐｈｙ５０ａ，５０ｂに対応して備えられている。

本実施例において、ＩＯＣ１２は、イニシエータ機能及びターゲット機能を備える。
ここで、イニシエータ機能とは、ＩＯＣ１２が他の装置（例えば、ストレージ装置３０や他のＩＯＣ１２）に対して命令を行なう機能である。また、ターゲット機能とは、ＩＯＣ１２が他の装置（例えば、他のＩＯＣ１２）から命令を受ける機能である。
ＩＯＣ＃０は、ホスト装置４０からストレージ装置３０へアクセス要求が行なわれると、イニシエータとして機能し、ｐｈｙ５０ａ、エキスパンダ２０及びｐｈｙ５０ｃを介してストレージ装置３０に対してデータの読み書き命令を行なう。同様に、ＩＯＣ＃１は、ホスト装置４０からストレージ装置３０へアクセス要求が行なわれると、イニシエータとして機能し、ｐｈｙ５０ｂ、エキスパンダ２０及びｐｈｙ５０ｃを介してストレージ装置３０に対してデータの読み書き命令を行なう。

また、ＣＰＵ１１の後述する確認部１１１及び検証部１１３の機能により、ＩＯＣ＃０は、ｐｈｙ５０ａ、エキスパンダ２０及びｐｈｙ５０ｂを介してＩＯＣ＃１に対してメモリ１３へのアクセス命令を発行する。この際、ＩＯＣ＃０はイニシエータとして機能し、ＩＯＣ＃１はターゲットとして機能する。同様に、ＣＰＵ１１の後述する確認部１１１及び検証部１１３の機能により、ＩＯＣ＃１は、ｐｈｙ５０ｂ、エキスパンダ２０及びｐｈｙ５０ａを介してＩＯＣ＃０に対してメモリ１３へのアクセス命令を発行する。この際、ＩＯＣ＃１はイニシエータとして機能し、ＩＯＣ＃０はターゲットとして機能する。

なお、図１に示す例では、２つのＩＯＣ１２を備えているが、これに限定されるものではなく、３つ以上のＩＯＣ１２を備えても良い。
メモリ１３は、Read Only Memory（ＲＯＭ）及びRandom Access Memory（ＲＡＭ）を含む記録装置である。メモリ２０のＲＯＭには、Operating system（ＯＳ）、制御システムの異常診断に係るソフトウェアプログラム（制御システムの異常診断プログラム）やこのプログラム用のデータ類が書き込まれている。メモリ１３上のソフトウェアプログラムは、ＣＰＵ１１に適宜読み込まれて実行される。また、メモリ１３のＲＡＭは、一次記録メモリあるいはワーキングメモリとして利用される。

本実施形態の一例において、メモリ１３は、図示しないワーク領域を備えており、ＩＯＣ１２の異常診断を行なう際、ＩＯＣ１２がこのワーク領域にあるデータを読み出す。
ＣＰＵ１１は、種々の制御や演算を行なう処理装置であり、メモリ１３に格納されたＯＳやプログラムを実行することにより、種々の機能を実現する。すなわち、ＣＰＵ１１は、図１に示すように、確認部１１１、切離処理部１１２及び検証部１１３として機能する。

そして、ＣＰＵ１１が、制御システムの異常診断プログラムを実行することにより、確認部１１１、切離処理部１１２及び検証部１１３として機能する。
なお、これらの確認部１１１、切離処理部１１２及び検証部１１３としての機能を実現するためのプログラム（制御システムの異常診断プログラム）は、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷ等），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ＋Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋ＲＷ，ＨＤ ＤＶＤ等），ブルーレイディスク，磁気ディスク，光ディスク，光磁気ディスク等の、コンピュータ読取可能な記録媒体に記録された形態で提供される。そして、コンピュータはその記録媒体からプログラムを読み取って内部記録装置または外部記録装置に転送し格納して用いる。又、そのプログラムを、例えば磁気ディスク，光ディスク，光磁気ディスク等の記録装置（記録媒体）に記録しておき、その記録装置から通信経路を介してコンピュータに提供するようにしてもよい。

確認部１１１、切離処理部１１２及び検証部１１３としての機能を実現する際には、内部記録装置（本実施形態ではメモリ１３）に格納されたプログラムがコンピュータのマイクロプロセッサ（本実施形態ではＣＰＵ１１）によって実行される。このとき、記録媒体に記録されたプログラムをコンピュータが読み取って実行するようにしてもよい。
なお、本実施形態において、コンピュータとは、ハードウェアとＯＳとを含む概念であり、ＯＳの制御の下で動作するハードウェアを意味している。又、ＯＳが不要でアプリケーションプログラム単独でハードウェアを動作させるような場合には、そのハードウェア自体がコンピュータに相当する。ハードウェアは、少なくとも、ＣＰＵ１１等のマイクロプロセッサと、記録媒体に記録されたコンピュータプログラムを読み取るための手段とを備えており、本実施形態においては、ＣＭ１０及びホスト装置４０がコンピュータとしての機能を有しているのである。

確認部１１１は、ＩＯＣ１２の一方をイニシエータとして、他方をターゲットとして動作させることにより、各ＩＯＣ１２が正常に動作しているか否かを確認する。確認部１１１によるＩＯＣ１２の動作確認は、既知の手法を用いるものであり、その詳細な説明は省略する。
ここで、確認部１１１が認識するＩＯＣ１２の異常とは、例えば、以下の４つの場合が挙げられる。

（１）ＩＯＣがＳＡＳコントローラとしての異常状態を報告した場合。
（２）ＩＯＣが応答しなくなった場合。
（３）ＩＯＣが制御している複数のストレージ装置へのアクセスでＳＡＳ経路に関わるエラーが発生した場合。
（４）Data Integrity Fieldの不整合等のストレージシステムとしてデータの異常を検出した場合。

切離処理部１１２は、確認部１１１により異常を確認されたＩＯＣ１２のストレージシステム１からの一時切離しを行なう。また、切離処理部１１２は、検証部１１３に指示されたＩＯＣ１２又はｐｈｙ５０ａ，５０ｂの切離しを行なう。この切離処理は、既知の種々の手法で実現されるため、その詳細な説明は省略する。
検証部１１３は、確認部１１１により異常を確認されたＩＯＣ１２について、ＩＯＣ１２自体の異常なのか、ＩＯＣ１２に接続されているいずれかのｐｈｙ５０ａ（または５０ｂ）の異常なのかを検証する。

〔Ａ−２〕異常個所の検証方法の一例
図２（ａ），（ｂ）は、実施形態の一例としてのストレージシステムにおける異常個所の検証方法を説明する図である。図２（ａ）は、異常ＩＯＣの共通機能の検証処理を示す図、図２（ｂ）は、異常ＩＯＣのイニシエータ機能の検証処理を示す図である。
図２（ａ），（ｂ）においては、便宜上、ストレージシステム１のうち、ＣＭ１０、エキスパンダ２０及びｐｈｙ５０ａ，５０ｂのみ図示し、その他の構成は省略している。

図２（ａ），（ｂ）は、ＩＯＣ＃０が正常であり、確認部１１１によりＩＯＣ＃１に異常が確認された例を示している。この例では、ＩＯＣ＃１の異常は、破線で示したｐｈｙ５０ｂ−１のイニシエータ機能とターゲット機能との共通機能の異常及び二重線で示したｐｈｙ５０ｂ−２のイニシエータ機能の異常によって生じたものとする。
始めに、確認部１１１は、ＩＯＣ＃１の異常を確認する。

切離処理部１１２は、確認部１１１によって異常を確認されたＩＯＣ＃１のストレージシステム１からの一時切離しを行なう。
検証部１１３は、確認部１１１により異常を確認されたＩＯＣ＃１について、ＩＯＣ＃１自体の異常なのか、ＩＯＣ＃１に接続されているいずれかのｐｈｙ５０ｂの異常なのかを検証する。検証部１１３は、先ず、図２（ａ）に示すように、正常なＩＯＣ＃０をイニシエータとして、異常なＩＯＣ＃１をターゲットとして、それぞれ機能させることで異常ＩＯＣの共通機能の検証処理を行なう。その後、検証部１１３は、図２（ｂ）に示すように、異常なＩＯＣ＃１をイニシエータとして、正常なＩＯＣ＃２をターゲットとして、それぞれ機能させることで異常ＩＯＣのイニシエータ機能の検証処理を行なう。このような異常ＩＯＣの共通機能の検証処理では、異常なＩＯＣ＃１をターゲットとして機能させることにより、異常なＩＯＣ＃１のイニシエータ機能とターゲット機能との共通機能の検証を行なう。また、この異常ＩＯＣのイニシエータ機能の検証処理では、異常なＩＯＣ＃１をイニシエータとして機能させることにより、異常ＩＯＣ＃１のイニシエータ機能の検証を行なう。このように、異常なＩＯＣ＃１のイニシエータ機能とターゲット機能との共通機能の検証を行なった後にイニシエータ機能の検証を行なうことによって、異常なＩＯＣ＃１からのアクセスにより正常なＩＯＣ＃０にも異常が発生することを防止する。

まず、図２（ａ）の矢印Ａに示すように、検証部１１３は、ＩＯＣ＃０に、いずれか１本のｐｈｙ５０ａ、エキスパンダ２０及びｐｈｙ５０ｂを介してＩＯＣ＃１に対して、メモリ１３の上述したワーク領域に格納されているデータにアクセスさせる。すなわち、検証部１１３は、ＩＯＣ＃０をイニシエータとして機能させ、ＩＯＣ＃１をターゲットとして機能させる。

ここで、いずれか１本のｐｈｙ５０ａには、例えば、ホスト装置４０からストレージ装置３０へのアクセス要求に使用されていないｐｈｙ５０ａを選ぶことが望ましい。ここでは、例えば、ＩＯＣ＃０は、ｐｈｙ５０ａ−１を介してメモリ１３にアクセスするものとする。
具体的には、検証部１１３は、ＩＯＣ＃０に、ｐｈｙ５０ａ−１、エキスパンダ２０及びｐｈｙ５０ｂ−１を介してＩＯＣ＃１に対して、メモリ１３に格納されているデータにアクセスさせる。そして、検証部１１３は、すべてのｐｈｙ５０ｂについて検証を行なうべく、ｐｈｙ５０ｂ−１，５０ｂ−２，５０ｂ−３，５０ｂ−４と順次切り替えてデータアクセスを行なわせる。すなわち、検証部１１３は、ＩＯＣ＃０に、ｐｈｙ５０ａ−１、エキスパンダ２０及びｐｈｙ５０ｂ−２を介してＩＯＣ＃１に対して、メモリ１３に格納されているデータにアクセスさせる。更に、検証部１１３は、ＩＯＣ＃０に、ｐｈｙ５０ａ−１、エキスパンダ２０及びｐｈｙ５０ｂ−３を介してＩＯＣ＃１に対して、メモリ１３に格納されているデータにアクセスさせる。そして、検証部１１３は、ＩＯＣ＃０に、ｐｈｙ５０ａ−１、エキスパンダ２０及びｐｈｙ５０ｂ−４を介してＩＯＣ＃１に対して、メモリ１３に格納されているデータにアクセスさせる。

このように、検証部１１３は、ＩＯＣ＃０に、異常なＩＯＣ＃１側のすべて（本実施形態の一例では４本）のｐｈｙ５０ｂを順次切り替えながら、メモリ１３に対するデータアクセスを行なわせる。なお、ＩＯＣ＃０がメモリ１３にアクセスする際に使用するｐｈｙ５０ｂの順番は上述した順番に限定されるものではなく、例えば、ｐｈｙ５０ｂ−４，５０ｂ−３，５０ｂ−２，５０ｂ−１の順番でも良い。

ただし、図２（ａ）に示す例では、ｐｈｙ５０ｂ−１の共通機能が異常であるので、ＩＯＣ＃０は、ｐｈｙ５０ｂ−１を介してのメモリ１３にアクセスすることができない。その一方で、ｐｈｙ５０ｂ−２〜５０ｂ−４の共通機能は正常であるので、ＩＯＣ＃０は、ｐｈｙ５０ｂ−２〜５０ｂ−４を介してメモリ１３にアクセスすることができる。検証部１１３は、このようにＩＯＣ＃０が各ｐｈｙ５０ｂを介してメモリ１３にアクセスできたか否かを検証することにより、共通機能の異常箇所であるｐｈｙ５０ｂ−１を特定する。

このように共通機能の異常なｐｈｙ５０ｂ−１が特定されると、切離処理部１１２は、エキスパンダ２０のワイドポート２１―２からｐｈｙ５０ｂ−１を切離す。
なお、ＩＯＣ＃１自体の共通機能の異常の場合（例えば、ＩＯＣ＃１のハード異常の場合）には、ＩＯＣ＃０は、いずれのｐｈｙ５０ｂを介してもメモリ１３にアクセスできない。よって、検証部１１３は、すべてのｐｈｙ５０ｂが異常であると認識する。そして、切離処理部１１２は、エキスパンダ２０のワイドポート２１―２からすべてのｐｈｙ５０ｂを切離す。

次に、図２（ｂ）の矢印Ｂに示すように、検証部１１３は、ＩＯＣ＃１に、各ｐｈｙ５０ｂ、エキスパンダ２０及びいずれか１本のｐｈｙ５０ａを介してＩＯＣ＃０に対して、メモリ１３の上述したワーク領域に格納されているデータにアクセスさせる。すなわち、ＩＯＣ＃１はイニシエータとして機能し、ＩＯＣ＃０はターゲットとして機能する。
ここでは、上述した異常ＩＯＣの共通部分の検証処理と同様に、例えば、ＩＯＣ＃１は、ｐｈｙ５０ａ−１を介してメモリ１３にアクセスするものとする。

具体的には、検証部１１３は、ＩＯＣ＃１に、ｐｈｙ５０ｂ−２、エキスパンダ２０及びｐｈｙ５０ａ−１を介してＩＯＣ＃０に対して、メモリ１３に格納されているデータにアクセスさせる。そして、検証部１１３は、上述した異常ＩＯＣの共通部分の検証処理で切離したｐｈｙ５０ｂ−１を除くすべてのｐｈｙ５０ｂについて検証を行なうべく、ｐｈｙ５０ｂ−２，５０ｂ−３，５０ｂ−４と順次切り替えてデータアクセスを行なわせる。すなわち、検証部１１３は、ＩＯＣ＃１に、ｐｈｙ５０ｂ−３、エキスパンダ２０及びｐｈｙ５０ａ−１を介してＩＯＣ＃０に対して、メモリ１３に格納されているデータにアクセスさせる。そして、検証部１１３は、ＩＯＣ＃１に、ｐｈｙ５０ｂ−４、エキスパンダ２０及びｐｈｙ５０ａ−１を介してＩＯＣ＃０に対して、メモリ１３に格納されているデータにアクセスさせる。

このように、検証部１１３は、ＩＯＣ＃１に、上述した異常ＩＯＣの共通部分の検証処理で切離したｐｈｙ５０ｂ−１を除く異常なＩＯＣ＃１側のすべて（この例では３本）のｐｈｙ５０ｂを順次切り替えながらメモリ１３に対するデータアクセスを行なわせる。なお、ＩＯＣ＃１がメモリ１３にアクセスする際に使用するｐｈｙ５０ｂの順番は上述した順番に限定されるものではなく、例えば、ｐｈｙ５０ｂ−４，５０ｂ−３，５０ｂ−２の順番でも良い。

ただし、図２（ｂ）に示す例では、ｐｈｙ５０ｂ−２のイニシエータ機能が異常であるので、ＩＯＣ＃１は、ｐｈｙ５０ｂ−２を介してメモリ１３にアクセスすることができない。その一方で、ｐｈｙ５０ｂ−３，５０ｂ−４のイニシエータ機能は正常であるので、ＩＯＣ＃１は、ｐｈｙ５０ｂ−３，５０ｂ−４を介してメモリ１３にアクセスすることができる。検証部１１３は、このようにＩＯＣ＃１が上述した異常ＩＯＣの共通部分の検証処理で切離したｐｈｙ５０ｂ−１を除く各ｐｈｙ５０ｂを介してメモリ１３にアクセスできたか否かを検証することにより、イニシエータ機能の異常なｐｈｙ５０ｂ−２を特定する。

このようにイニシエータ機能の異常なｐｈｙ５０ｂ−２が特定されると、切離処理部１１２は、ＩＯＣ＃１のワイドポート１２１−２からｐｈｙ５０ｂ−２を切離す。
なお、ＩＯＣ＃１自体のイニシエータ機能の異常の場合（例えば、ＩＯＣ＃１のハード異常の場合）には、ＩＯＣ＃０は、いずれのｐｈｙ５０ｂを介してもメモリ１３にアクセスできない。よって、検証部１１３は、すべてのｐｈｙ５０ｂが異常であると認識する。そして、切離処理部１１２は、ＩＯＣ＃１のワイドポート１２１−２からすべてのｐｈｙ５０ｂを切離す。

以上の処理により、異常なｐｈｙ５０ｂ−１，５０ｂ−２の切離しが完了し、切離処理部１１２は、ＩＯＣ＃１の一時切離しを解除して、ストレージシステム１に組戻す。
なお、すべてのｐｈｙ５０ｂを切離した場合には、切離処理部１１２は、ＩＯＣ＃１の一時切離しを解除しない。
〔Ａ−３〕動作
上述の如く構成された実施形態の一例としてのストレージシステム１における異常診断処理を、図３及び図４に示すフローチャート（ステップＡ１０〜Ａ１４０）に従って説明する。なお、図３にはステップＡ１０〜Ａ７０，Ａ１４０を示し、図４にはステップＡ８０〜Ａ１３０を示す。

ストレージシステム１に異常が発生すると、確認部１１１は、発生した異常がＩＯＣ１２に関連するものであるかを確認する（図３のステップＡ１０）。この判断は、例えば、エラーログを参照して、前記ＩＯＣの異常（１）〜（４）のいずれかに該当するかを判断することにより実現できる。
発生した異常がＩＯＣ１２に関連するものである場合には（図３のステップＡ１０のＹＥＳルート参照）、切離処理部１１２は、異常が発生したＩＯＣ１２をストレージシステム１から一時切離す（図３のステップＡ２０）。

検証部１１３は、異常ＩＯＣの共通機能の検証処理Ａを行なう（図３のステップＡ３０〜Ａ７０）。
検証部１１３は、正常なＩＯＣ１２をイニシエータとして、異常なＩＯＣ１２をターゲットとしてそれぞれ機能させ、正常なＩＯＣ１２側のいずれか１本のｐｈｙ（以下、検証用ｐｈｙという）を異常なＩＯＣ１２に接続する（図３のステップＡ３０）。

検証部１１３は、正常なＩＯＣ１２に、検証用ｐｈｙ、エキスパンダ２０及び異常なＩＯＣ１２側のｐｈｙのうち１本を介して異常なＩＯＣ１２に対して、メモリ１３のワーク領域に格納されているデータにアクセスさせる。これにより、検証部１１３は、使用した異常なＩＯＣ１２側のｐｈｙのターゲット機能をチェックする（図３のステップＡ４０）。

検証部１１３は、チェック結果が正常か、すなわち、メモリ１３にアクセスできたかを判断する（図３のステップＡ５０）。
チェック結果が正常な場合には（図３のステップＡ５０のＹＥＳルート参照）、検証部１１３は、異常なＩＯＣ１２側のすべて（本実施形態の一例では４本）のｐｈｙを検証済みか判断する（図３のステップＡ６０）。

一方、チェック結果が正常でない場合には（図３のステップＡ５０のＮＯルート参照）、切離処理部１１２は、エキスパンダ２０に対して正常でないｐｈｙの切離しを命じ（図３のステップＡ７０）、ステップＡ６０に移行する。
異常なＩＯＣ１２側のすべてのｐｈｙについて検証済みでない場合には（図３のステップＡ６０のＮＯルート参照）、異常なＩＯＣ１２側のｐｈｙを切り替えて、ステップＡ３０に戻る。

一方、異常なＩＯＣ１２側のすべてのｐｈｙについて検証済みの場合には（図３のステップＡ６０のＹＥＳルート参照）、検証部１１３は、次に異常ＩＯＣのイニシエータ機能の検証処理Ｂを行なう（図４のステップＡ８０〜Ａ１２０）。
検証部１１３は、異常なＩＯＣ１２をイニシエータとして、正常なＩＯＣ１２をターゲットとしてそれぞれ機能させ、検証用ｐｈｙを異常なＩＯＣ１２に接続する（図４のステップＡ８０）。

検証部１１３は、異常なＩＯＣ１２に、異常なＩＯＣ１２側のｐｈｙのうち１本、エキスパンダ２０及び検証用ｐｈｙを介して正常なＩＯＣ１２に対して、メモリ１３のワーク領域に格納されているデータにアクセスさせる。そして、検証部１１３は、使用した異常なＩＯＣ１２側のｐｈｙのイニシエータ機能をチェックする（図４のステップＡ９０）。
検証部１１３は、チェック結果が正常か、すなわち、メモリ１３にアクセスできたかを判断する（図４のステップＡ１００）。

チェック結果が正常な場合には（図４のステップＡ１００のＹＥＳルート参照）、検証部１１３は、ステップＡ７０において切離したｐｈｙを除く異常なＩＯＣ１２側のすべてのｐｈｙを検証済みか判断する（図４のステップＡ１１０）。
一方、チェック結果が正常でない場合には（図４のステップＡ１００のＮＯルート参照）、切離処理部１１２は、異常なＩＯＣ１２に対して正常でないｐｈｙの切離しを命じ（図４のステップＡ１２０）、ステップＡ１１０に移行する。

ステップＡ７０において切離したｐｈｙを除く異常なＩＯＣ１２側のすべてのｐｈｙについて検証済みでない場合には（図４のステップＡ１１０のＮＯルート参照）、異常なＩＯＣ１２側のｐｈｙを切り替えて、ステップＡ８０に戻る。
一方、ステップＡ７０において切離したｐｈｙを除く異常なＩＯＣ１２側のすべてのｐｈｙを検証済みの場合には（図４のステップＡ１１０のＹＥＳルート）、切離処理部１１２は、異常なＩＯＣ１２の一時切離しを解除し、ストレージシステム１に組み戻す（図４のステップＡ１３０）。ただし、異常なＩＯＣ１２側のすべてのｐｈｙを切離した場合には、切離処理部１１２は、異常なＩＯＣ１２の一時切離しを解除しない。

以上で、ストレージシステム１における異常診断処理が終了する。
一方、発生した異常がＩＯＣ１２に関連するものでない場合（例えば、ストレージ装置３０やｐｈｙ５０ｃの異常）には（図３のステップＡ１０のＮＯルート参照）、ＣＰＵ１１やオペレータは、既知の手法により通常の異常処理を行ない（図３のステップＡ１４０）、ストレージシステム１における異常診断処理が終了する。

〔Ａ−４〕効果
このように、実施形態の一例としてのストレージシステム１によれば、異常が検出されたＩＯＣ１２の効率的なシステムからの切離しを行なうことができる。
また、切離処理部１１２は、異常なｐｈｙごとに切離すことができ、異常が検出されたＩＯＣ１２全体の切離しを避けることができ、システムの冗長化が可能になる。

更に、検証部１１３は、異常を検出されたＩＯＣ１２の共通機能の検証処理の後にイニシエータ機能の検証処理を行なうため、正常なＩＯＣ１２への影響を少なくすることができる。
また、検証部１１３は、正常なＩＯＣ１２側の１本のｐｈｙのみを診断処理に用いるため、診断処理中においてもシステムの通常運用を継続することができる。

〔Ｂ〕変形例
開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。本実施形態の各構成及び各処理は、必要に応じて取捨選択することができ、あるいは適宜組み合わせてもよい。
〔Ｂ−１〕第１変形例
図５は、実施形態の第１変形例としてのストレージシステムの機能構成を模式的に示す図である。

以下、図中において、既述の符号と同一の各符号は、既述の各符号と同様の部分を示しているので、その説明は省略する。
本実施形態の第１変形例としてのストレージシステム１は、図５に示すように、上述した実施形態の一例としてのストレージシステム１の機能構成例に加え、ＣＰＵ１１がリセット処理部１１４を備える。

リセット処理部１１４は、異常が確認されたＩＯＣ１２のチップリセットを実施する。また、リセット処理部１１４は、確認部１１１がＩＯＣ１２に関連する異常を確認した場合に、異常が確認されたＩＯＣ１２のチップリセットを過去に実施したかを判断する。そして、未実施の場合にリセット処理を実施する。更に、リセット処理部１１４は、実施したチップリセットが成功したか、すなわち、異常が確認されたＩＯＣ１２が再起動したかを判断する。

例えば、リセット処理部１１４は、ＩＯＣ１２のチップリセットを過去に実施したか否かのログをメモリ１３に格納させておき、このログを参照することでリセット処理を行なうか否かを判断することができる。リセット処理部１１４は、メモリ１３に格納したログを予め定められた期間が経過すると削除しても良い。
上述の如く構成された実施形態の第１変形例としてのストレージシステム１における異常診断処理を、図６に示すフローチャート（ステップＢ１０〜Ｂ１００）に従って説明する。

ストレージシステム１に異常が発生すると、確認部１１１は、発生した異常がＩＯＣ１２に関連するものであるかを確認する（ステップＢ１０）。この判断は、例えば、エラーログを参照して、前記ＩＯＣの異常（１）〜（４）のいずれかに該当するかを判断することにより実現できる。
発生した異常がＩＯＣ１２に関連するものである場合には（ステップＢ１０のＹＥＳルート参照）、リセット処理部１１４は、異常が発生したＩＯＣ１２のチップリセットを過去に実施したかを判断する（ステップＢ２０）。

異常が発生したＩＯＣ１２のチップリセットを過去に実施していない場合には（ステップＢ２０のＮＯルート）、リセット処理部１１４は、異常が発生したＩＯＣ１２のチップリセットを実施する（ステップＢ３０）。
リセット処理部１１４は、実施したチップリセットが成功したか、すなわち、異常が発生したＩＯＣ１２が再起動したかを判断する（ステップＢ４０）。

実施したチップリセットが成功した場合には（ステップＢ４０のＹＥＳルート参照）、ストレージシステム１における異常診断処理を終了する。
一方、実施したチップリセットが成功しなかった場合には（ステップＢ４０のＮＯルート参照）、切離処理部１１２は、異常が発生したＩＯＣ１２をストレージシステム１から切離し（ステップＢ５０）、ストレージシステム１における異常診断処理を終了する。

また、異常が発生したＩＯＣ１２のチップリセットを過去に実施している場合には（ステップＢ２０のＹＥＳルート参照）、切離処理部１１２は、異常が発生したＩＯＣ１２をストレージシステム１から一時切離す（ステップＢ６０）。
検証部１１３は、異常ＩＯＣの共通機能の検証処理Ａ（図３のステップＡ３０〜Ａ７０参照）を行なう（ステップＢ７０）。

検証部１１３は、異常ＩＯＣのイニシエータ機能の検証処理Ｂ（図４のステップＡ８０〜Ａ１２０参照）を行なう（ステップＢ８０）。
切離処理部１１２は、異常なＩＯＣ１２の一時切離しを解除し、ストレージシステム１に組み戻し（ステップＢ９０）、ストレージシステム１における異常診断処理を終了する。ただし、異常なＩＯＣ１２側のすべてのｐｈｙを切離した場合には、切離処理部１１２は、異常なＩＯＣ１２の一時切離しを解除しない。

一方、発生した異常がＩＯＣ１２に関連するものでない場合（例えば、ストレージ装置３０やｐｈｙ５０ｃの異常）には（ステップＢ１０のＮＯルート参照）、ＣＰＵ１１やオペレータは、既知の手法により通常の異常処理を行ない（ステップＢ１００）、ストレージシステム１における異常診断処理が終了する。
このように、実施形態の第１変形例としてのストレージシステム１によれば、上述した実施形態の一例と同様の作用効果を得ることができる他、以下の効果を奏することができる。

リセット処理部１１４は、ＩＯＣ１２がチップリセット済みかを確認し、チップリセット済みでない場合には、検証部１１３による異常箇所の検証の前に異常を検出されたＩＯＣ１２のチップリセットを行なうため、異常診断処理にかかる時間を短縮できる。
〔Ｂ−２〕第２変形例
図７は、実施形態の第２変形例としてのストレージシステムの機能構成を模式的に示す図である。

以下、図中において、既述の符号と同一の各符号は、既述の各符号と同様の部分を示しているので、その説明は省略する。
本実施形態の第２変形例としてのストレージシステム１は、図７に示すように、図５に示したストレージシステム１の機能構成に加え、ＣＰＵ１１が負荷確認部１１５及び冗長判断部１１６を備える。

負荷確認部１１５は、Ｉ／Ｏの負荷が高いか、すなわち、ストレージシステム１の通常運用に用いる正常なＩＯＣ１２の負荷が高いかを確認する。例えば、負荷確認部１１５は、予め定められた閾値を超えたか否かによって、Ｉ／Ｏの負荷が高いか否かの確認を行なう。
冗長判断部１１６は、正常なＩＯＣ１２側のｐｈｙが予め定められた本数以上使用できるか、すなわち、正常なＩＯＣ１２側の切離されていないｐｈｙが予め定められた本数（例えば２本）以上あるかを判断する。

上述の如く構成された実施形態の第２変形例としてのストレージシステム１における異常診断処理を、図８に示すフローチャート（ステップＣ１０〜Ｃ１２０）に従って説明する。
ストレージシステム１に異常が発生すると、確認部１１１は、発生した異常がＩＯＣ１２に関連するものであるかを確認する（ステップＣ１０）。この判断は、例えば、エラーログを参照して、前記ＩＯＣの異常（１）〜（４）のいずれかに該当するかを判断することにより実現できる。

発生した異常がＩＯＣ１２に関連するものである場合には（ステップＣ１０のＹＥＳルート参照）、リセット処理部１１４は、異常が発生したＩＯＣ１２のチップリセットを過去に実施したかを判断する（ステップＣ２０）。
異常が発生したＩＯＣ１２のチップリセットを過去に実施していない場合には（ステップＣ２０のＮＯルート）、リセット処理部１１４は、異常が発生したＩＯＣ１２のチップリセットを実施する（ステップＣ３０）。

リセット処理部１１４は、実施したチップリセットが成功したか、すなわち、異常が発生したＩＯＣ１２が再起動したかを判断する（ステップＣ４０）。
実施したチップリセットが成功した場合には（ステップＣ４０のＹＥＳルート参照）、ストレージシステム１における異常診断処理を終了する。
一方、実施したチップリセットが成功しなかった場合には（ステップＣ４０のＮＯルート参照）、切離処理部１１２は、異常が発生したＩＯＣ１２をストレージシステム１から切離し（ステップＣ５０）、ストレージシステム１における異常診断処理を終了する。

また、異常が発生したＩＯＣ１２のチップリセットを過去に実施している場合には（ステップＣ２０のＹＥＳルート参照）、切離処理部１１２は、異常が発生したＩＯＣ１２をストレージシステム１から一時切離す（ステップＣ６０）。
負荷確認部１１５は、Ｉ／Ｏの負荷が高いかを確認する（ステップＣ７０）。
Ｉ／Ｏの負荷が高くない場合には（ステップＣ７０のＮＯルート参照）、冗長判断部１１６は、正常なＩＯＣ１２側のｐｈｙが複数使用できるかを確認する（ステップＣ８０）。

正常なＩＯＣ１２側のｐｈｙが複数使用できる場合には（ステップＣ８０のＹＥＳルート参照）、検証部１１３は、異常ＩＯＣの共通機能の検証処理Ａ（図３のステップＡ３０〜Ａ７０参照）を行なう（ステップＣ９０）。
これにより、正常なＩＯＣ１２側のｐｈｙが冗長化されている場合にのみ、異常ＩＯＣの共通機能の検証処理Ａ及び異常ＩＯＣのイニシエータ機能の検証処理Ｂが行なわれる。

検証部１１３は、異常ＩＯＣのイニシエータ機能の検証処理Ｂ（図４のステップＡ８０〜Ａ１２０参照）を行なう（ステップＣ１００）。
切離処理部１１２は、異常なＩＯＣ１２の一時切離しを解除し、ストレージシステム１に組み戻し（ステップＣ１１０）、ストレージシステム１における異常診断処理を終了する。ただし、異常なＩＯＣ１２側のすべてのｐｈｙを切離した場合には、切離処理部１１２は、異常なＩＯＣ１２の一時切離しを解除しない。

また、正常なＩＯＣ１２側のｐｈｙが複数使用できない場合には（ステップＣ８０のＮＯルート参照）、ステップＣ５０に移行する。
一方、Ｉ／Ｏの負荷が高い場合には（ステップＣ７０のＹＥＳルート参照）、負荷確認部１１５は、Ｉ／Ｏの負荷が低くなるまで待受けるために、ステップＣ７０に戻る。
これにより、Ｉ／Ｏの負荷が低くなるまで異常ＩＯＣの共通機能の検証処理Ａ及び異常ＩＯＣのイニシエータ機能の検証処理Ｂが行なわれない。

一方、発生した異常がＩＯＣ１２に関連するものでない場合（例えば、ストレージ装置３０やｐｈｙ５０ｃの異常）には（ステップＣ１０のＮＯルート参照）、ＣＰＵ１１やオペレータは、既知の手法により通常の異常処理を行ない（ステップＣ１２０）、ストレージシステム１における異常診断処理が終了する。
なお、本実施形態の第２変形例においては、上述したステップＣ７０又はステップＣ８０のうちいずれかを省略することとしても良い。

また、ステップＣ７０において、一定時間が経ってもＩ／Ｏの負荷が低くならない場合は、ステップＣ５０に移行して、切離処理部１１２が異常なＩＯＣ１２をストレージシステム１から切離すこととしても良い。
このように、実施形態の第２変形例としてのストレージシステム１によれば、上述した実施形態の一例と同様の作用効果を得ることができる他、以下の効果を奏することができる。

負荷確認部１１５は、Ｉ／Ｏの負荷を確認し、Ｉ／Ｏの負荷が高くない場合に検証部１１３による異常箇所の検証を行なうため、業務に支障を与えない。
また、冗長判断部１１６は、ｐｈｙの冗長化を判断し、ｐｈｙが冗長化されている場合に検証部１１３による異常箇所の検証を行なうため、信頼性を向上することができる。
〔Ｂ−３〕その他
上述した実施形態の一例又は実施形態の変形例としてストレージシステム１の異常診断方法の実現は、ストレージシステム１の通常運用中に限られるものではなく、例えば、装置製造工場におけるＩＯＣ１２の動作確認試験時にも実現される。

また、切離処理部１１２は、ＩＯＣ１２の異常診断処理実施後に、Ｉ／Ｏの負荷や各ＩＯＣ１２が使用可能なｐｈｙの本数により、適宜、異常が発生したＩＯＣ１２を切離しても良い。
〔Ｃ〕付記
（付記１）
少なくとも２つのコントローラを備え、前記コントローラはそれぞれイニシエータとして制御対象装置の制御を行なう制御システムにおいて、
２つのコントローラの一方をイニシエータとし、他方をターゲットとして動作させて、前記２つのコントローラの状態を確認する確認部と、
前記確認部により検出された異常なコントローラをターゲットとして正常なコントローラをイニシエータとして動作させ、前記ターゲットに対してデータアクセス処理を実行させ、前記異常なコントローラの機能の検証を行なう検証部と、
を備えることを特徴とする、制御システム。

（付記２）
前記検証部は、
前記検証を行なって、前記異常なコントローラのイニシエータとターゲットとの共通機能の検証を行なった後に、
前記異常なコントローラをイニシエータとして前記正常なコントローラをターゲットとして動作させ、前記ターゲットに対してデータアクセス処理を実行させ、前記異常なコントローラのイニシエータの機能の検証を行なうことを特徴とする、付記１に記載の制御システム。

（付記３）
前記異常なコントローラのリセットを実行するリセット処理部をそなえ、
前記検証部は、前記リセット処理部が前記異常なコントローラのリセットの実行済みであることを確認した後に、前記機能の検証を行なうことを特徴とする、付記１又は２に記載の制御システム。

（付記４）
当該制御システムにおける負荷状況を確認する負荷確認部を備え、
前記検証部は、前記負荷確認部が当該制御システムの負荷が低いことを確認した場合に、前記機能の検証を行なうことを特徴とする、付記１〜３のいずれか１項に記載の制御システム。

（付記５）
前記２つのコントローラが冗長化された複数の通信経路を介して接続され、
前記検証部が、
前記複数の通信経路の中から順次、選択した一の通信経路を介して、前記ターゲットに対してデータアクセス処理を実行させて前記機能の検証を行なうことを特徴とする、付記１〜４のいずれか１項に記載の制御システム。

（付記６）
前記複数の通信経路のうち、少なくとも２つの通信経路が有効であるかを確認する冗長判断部を備え、
前記検証部が、前記冗長判断部が少なくとも２つの通信経路が有効であることを確認した場合に、前記機能の検証を行なうことを特徴とする、付記５に記載の制御システム。

（付記７）
少なくとも２つのコントローラを備え、前記コントローラはそれぞれイニシエータとして制御対象装置の制御を行なう制御システムにおいて、
２つのコントローラの一方をイニシエータとし、他方をターゲットとして動作させて、前記２つのコントローラの状態を確認する確認ステップと、
異常なコントローラをターゲットとして正常なコントローラをイニシエータとして動作させ、前記ターゲットに対してデータアクセス処理を実行させ、前記異常なコントローラの機能の検証を行なう検証ステップと、
を備えることを特徴とする、制御システムの異常診断方法。

（付記８）
前記検証ステップにおいて、
前記検証を行なって、前記異常なコントローラのイニシエータとターゲットとの共通機能の検証を行なった後に、
前記異常なコントローラをイニシエータとして前記正常なコントローラをターゲットとして動作させ、前記ターゲットに対してデータアクセス処理を実行させ、前記異常なコントローラのイニシエータの機能の検証を行なうことを特徴とする、付記７に記載の制御システムの異常診断方法。

（付記９）
前記異常なコントローラのリセットを実行するリセット処理ステップをそなえ、
前記検証ステップにおいて、前記リセット処理ステップで前記異常なコントローラのリセットの実行済みであることを確認した後に、前記機能の検証を行なうことを特徴とする、付記７又は８に記載の制御システムの異常診断方法。

（付記１０）
当該制御システムにおける負荷状況を確認する負荷確認ステップを備え、
前記検証ステップにおいて、前記負荷確認ステップで当該制御システムの負荷が低いことを確認した場合に、前記機能の検証を行なうことを特徴とする、付記７〜９のいずれか１項に記載の制御システムの異常診断方法。

（付記１１）
前記２つのコントローラが冗長化された複数の通信経路を介して接続され、
前記検証ステップにおいて、
前記複数の通信経路の中から順次、選択した一の通信経路を介して、前記ターゲットに対してデータアクセス処理を実行させて前記機能の検証を行なうことを特徴とする、付記７〜１０のいずれか１項に記載の制御システムの異常診断方法。

（付記１２）
前記複数の通信経路のうち、少なくとも２つの通信経路が有効であるかを確認する冗長判断ステップを備え、
前記検証ステップにおいて、前記冗長判断ステップで少なくとも２つの通信経路が有効であることを確認した場合に、前記機能の検証を行なうことを特徴とする、付記１１に記載の制御システムの異常診断方法。

（付記１３）
少なくとも２つのコントローラを備え、前記コントローラはそれぞれイニシエータとして制御対象装置の制御を行なう制御システムの異常診断を実行するコンピュータに、
２つのコントローラの一方をイニシエータとし、他方をターゲットとして動作させて、前記２つのコントローラの状態を確認し、
異常なコントローラをターゲットとして正常なコントローラをイニシエータとして動作させ、前記ターゲットに対してデータアクセス処理を実行させ、前記異常なコントローラの機能の検証を行なう、
処理を実行させることを特徴とする、制御システムの異常診断プログラム。

（付記１４）
前記検証を行なって、前記異常なコントローラのイニシエータとターゲットとの共通機能の検証を行なった後に、
前記異常なコントローラをイニシエータとして前記正常なコントローラをターゲットとして動作させ、前記ターゲットに対してデータアクセス処理を実行させ、前記異常なコントローラのイニシエータの機能の検証を行なう、
処理を前記コンピュータに実行させることを特徴とする、付記１３に記載の制御システムの異常診断プログラム。

（付記１５）
前記異常なコントローラのリセットを実行し、
前記リセットの処理で前記異常なコントローラのリセットの実行済みであることを確認した後に、前記機能の検証を行なう、
処理を前記コンピュータに実行させることを特徴とする、付記１３又は１４に記載の制御システムの異常診断プログラム。

（付記１６）
当該制御システムにおける負荷状況を確認し、
当該制御システムの負荷が低いことを確認した場合に、前記機能の検証を行なう、
処理を前記コンピュータに実行させることを特徴とする、付記１３〜１５のいずれか１項に記載の制御システムの異常診断プログラム。

（付記１７）
前記２つのコントローラを接続する、冗長化された複数の通信経路の中から順次、選択した一の通信経路を介して、前記ターゲットに対してデータアクセス処理を実行させて前記機能の検証を行なう、
処理を前記コンピュータに実行させることを特徴とする、付記１３〜１６のいずれか１項に記載の制御システムの異常診断プログラム。

（付記１８）
前記複数の通信経路のうち、少なくとも２つの通信経路が有効であるかを確認し、
少なくとも２つの通信経路が有効であることを確認した場合に、前記機能の検証を行なう、
処理を前記コンピュータに実行させることを特徴とする、付記１７に記載の制御システムの異常診断プログラム。

１ ストレージシステム（制御システム）
１０ ＣＭ
１１ ＣＰＵ（コンピュータ）
１１１ 確認部
１１２ 切離処理部
１１３ 検証部
１１４ リセット処理部
１１５ 負荷確認部
１１６ 冗長判断部
１２，１２−１，１２−２ ＩＯＣ
１２１，１２１−１，１２１−２，２１，２１−１，２１−２ ワイドポート（Wide Port）
１３ メモリ
１４ ＨＡ
２０ エキスパンダ
２２ ポート
３０，３０−１〜３０−ｍ ストレージ装置
４０ ホスト装置（上位装置）
５０ａ，５０ａ−１〜５０ａ−４，５０ｂ，５０ｂ−１〜５０ｂ−４，５０ｃ，５０ｄ ｐｈｙ
Ａ 異常ＩＯＣの共通機能の検証処理
Ｂ 異常ＩＯＣのイニシエータ機能の検証処理

Claims (8)

1. 少なくとも２つのコントローラとデータを記憶するメモリとを備え、前記コントローラはそれぞれイニシエータとして制御対象装置の制御を行なう制御システムにおいて、
   ２つのコントローラの一方をイニシエータとし、他方をターゲットとして動作させて、前記２つのコントローラの状態を確認する確認部と、
   前記確認部により検出された異常なコントローラをターゲットとして正常なコントローラをイニシエータとして動作させ、前記ターゲットに対して前記データへのアクセス処理を実行させ、当該アクセス処理が実行できたか否かに基づき前記異常なコントローラの機能の検証を行なう検証部と、
   を備えることを特徴とする、制御システム。
2. 前記検証部は、
   前記異常なコントローラをターゲットとして前記正常なコントローラをイニシエータとして動作させることにより、前記異常なコントローラのイニシエータとターゲットとの共通機能の検証を行なった後に、
   前記異常なコントローラをイニシエータとして前記正常なコントローラをターゲットとして動作させ、前記ターゲットに対して前記データへのアクセス処理を実行させ、前記異常なコントローラのイニシエータの機能の検証を行なうことを特徴とする、請求項１に記載の制御システム。
3. 前記異常なコントローラのリセットを実行するリセット処理部をそなえ、
   前記検証部は、前記リセット処理部が前記異常なコントローラのリセットの実行済みであることを確認した後に、前記機能の検証を行なうことを特徴とする、請求項１又は２に記載の制御システム。
4. 当該制御システムにおける負荷状況を確認する負荷確認部を備え、
   前記検証部は、前記負荷確認部が当該制御システムの負荷が低いことを確認した場合に、前記機能の検証を行なうことを特徴とする、請求項１〜３のいずれか１項に記載の制御システム。
5. 前記２つのコントローラが冗長化された複数の通信経路を介して接続され、
   前記検証部が、
   前記複数の通信経路の中から順次、選択した一の通信経路を介して、前記ターゲットに対して前記データへのアクセス処理を実行させて前記機能の検証を行なうことを特徴とする、請求項１〜４のいずれか１項に記載の制御システム。
6. 前記複数の通信経路のうち、少なくとも２つの通信経路が有効であるかを確認する冗長判断部を備え、
   前記検証部が、前記冗長判断部が少なくとも２つの通信経路が有効であることを確認した場合に、前記機能の検証を行なうことを特徴とする、請求項５に記載の制御システム。
7. 少なくとも２つのコントローラとデータを記憶するメモリとを備え、前記コントローラはそれぞれイニシエータとして制御対象装置の制御を行なう制御システムにおいて、
   ２つのコントローラの一方をイニシエータとし、他方をターゲットとして動作させて、前記２つのコントローラの状態を確認する確認ステップと、
   異常なコントローラをターゲットとして正常なコントローラをイニシエータとして動作させ、前記ターゲットに対して前記データへのアクセス処理を実行させ、当該アクセス処理が実行できたか否かに基づき前記異常なコントローラの機能の検証を行なう検証ステップと、
   を備えることを特徴とする、制御システムの異常診断方法。
8. 少なくとも２つのコントローラとデータを記憶するメモリとを備え、前記コントローラはそれぞれイニシエータとして制御対象装置の制御を行なう制御システムの異常診断を実行するコンピュータに、
   ２つのコントローラの一方をイニシエータとし、他方をターゲットとして動作させて、前記２つのコントローラの状態を確認し、
   異常なコントローラをターゲットとして正常なコントローラをイニシエータとして動作させ、前記ターゲットに対して前記データへのアクセス処理を実行させ、当該アクセス処理が実行できたか否かに基づき前記異常なコントローラの機能の検証を行なう、
   処理を実行させることを特徴とする、制御システムの異常診断プログラム。

Images