(57)【特許請求の範囲】
【請求項１】
複数のホストコンピュータと、該ホストが共用する資源と、前記ホストの前記資源に対するアクセスを排他制御する排他制御装置サブシステムと、を有する疎結合システムにおけるリカバリ方式であって、
前記サブシステムは、複数の排他制御装置から構成され、
前記排他制御装置は、相互接続された対の二重化処理部で構成され、該処理部は互いに対の処理部の排他制御情報をバックアップし一方の処理部が障害により機能停止した場合に他方の処理部が処理を引き継ぐハードウェアリカバリ機能を有し、
前記サブシステムにおいて排他制御装置が障害により機能停止した場合に前記ホスト主導により前記機能停止した排他制御装置の排他制御情報に関して前記ホストが保持する排他制御情報を用いて前記機能停止した排他制御装置以外の排他制御装置群に再生するソフトウェアリカバリ機能を有し、
前記ソフトウェアリカバリ機能の実行時に前記排他制御情報の再生を行う排他制御装置において排他制御テーブルで再生データがオーバーフローする場合に前記バックアップ処理用のテーブルも共に使用してデータ再生を行う回避機能を有することを特徴とする疎結合システムにおけるリカバリ方式。
【請求項２】
前記排他制御装置で前記対の二重化処理部は同時稼動し分担して排他制御処理を遂行し、互いに通常モード用の排他制御テーブルと前記バックアップ処理用のテーブルとを確保して前記ハードウェアリカバリ機能を実行することを特徴とする請求項１記載のリカバリ方式。
【請求項３】
前記排他制御装置の二重化処理部は、
前記排他制御情報を記憶する排他制御テーブルについてその使用量を監視する処理を行い、前記回避機能におけるデータ再生処理の後、前記バックアップ処理用のテーブルを含む排他制御テーブルに保持する排他制御情報が減少してその使用量が所定率を下回った場合に前記バックアップ処理用のテーブルの使用を元に戻して通常モードに戻る復帰機能をさらに有することを特徴とする請求項１または２に記載のリカバリ方式。
【請求項４】
前記復帰機能において通常モードに戻る時、前記ホストに要求して前記回避処理を実行した排他制御装置内でのみのデータ再構成を行うことを特徴とする請求項３記載のリカバリ方式。
【請求項５】
前記復帰機能において通常モードに戻る時、前記ホストに要求して前記回避処理を実行した排他制御装置を含む排他制御装置サブシステム全体でのデータ再構成を行うことを特徴とする請求項３記載のリカバリ方式。
【請求項６】
複数のホストコンピュータの共用する資源に対するアクセスを排他制御する排他制御装置サブシステムを構成する排他制御装置であって、
相互接続された対の二重化処理部で構成され、該処理部は互いに対の処理部の排他制御情報をバックアップし一方の処理部が障害により機能停止した場合に他方の処理部が処理を引き継ぐハードウェアリカバリ機能を有し、
前記サブシステムにおいて排他制御装置が障害により機能停止した場合に前記ホスト主導により前記機能停止した排他制御装置の排他制御情報に関して前記ホストが保持する排他制御情報を用いて前記機能停止した排他制御装置以外の排他制御装置群に再生するソフトウェアリカバリ機能を有し、
前記ソフトウェアリカバリ機能の実行時に前記排他制御情報の再生を行う時に排他制御テーブルで再生データがオーバーフローする場合に前記バックアップ処理用のテーブルも共に使用してデータ再生を行う回避機能を有することを特徴とする排他制御装置。
【請求項７】
前記対の二重化処理部は同時稼動し分担して排他制御処理を遂行し、互いに通常モード用の排他制御テーブルと前記バックアップ処理用のテーブルとを確保して前記ハードウェアリカバリ機能を実行することを特徴とする請求項６記載の排他制御装置。
【請求項８】
前記二重化処理部は、
前記排他制御情報を記憶する排他制御テーブルについてその使用量を監視する処理を行い、前記回避機能におけるデータ再生処理の後、前記バックアップ処理用のテーブルを含む排他制御テーブルに保持する排他制御情報が減少してその使用量が所定率を下回った場合に前記バックアップ処理用のテーブルの使用を元に戻して通常モードに戻る復帰機能をさらに有することを特徴とする請求項６または７に記載の排他制御装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、疎結合システムにおける障害発生時のリカバリ方式及び排他制御装置に関する。
【０００２】
【従来の技術】
従来の疎結合システムにおけるリカバリ方式として、例えば、特開平１１−３３８８４３号公報に開示されている方式が存在する。この技術では、複数のホストが共用する資源に対するアクセスの制御（排他制御、ロック制御）を行う複数のＭＳＣＰ（Multi System Control Processor、排他制御装置）を有するシステムにおいて、ホスト側においても排他制御情報（ロック情報）を保持し、複数のＭＳＣＰから成る系でＭＳＣＰに障害が発生した場合に、ホスト主導でソフトウェア的にＭＳＣＰの系に対して排他制御情報の再生・再構成処理を行う。このようなリカバリの機能・処理によりシステム運用を継続させてシステムの可用性を向上している。また、複数のＭＳＣＰから成る系に予備のＭＳＣＰを設けるシステム構成も有り得、この構成の場合、複数のＭＳＣＰから成る系（現用系）における障害発生時には、予備のＭＳＣＰを稼動させて処理を引き継がせ、システム運用を継続する。
【０００３】
上記の従来技術で予備のＭＳＣＰを設けないシステム構成の場合では、複数のＭＳＣＰから成る系（ＭＳＣＰサブシステム）におけるロック情報（排他制御情報）の再構成を行う際（つまりＭＳＣＰにおける障害発生を検出したことに基づきリカバリを実行する際）は、ロック情報の登録（記録）に使用可能なＭＳＣＰの総台数が減っており、よって当然ＭＳＣＰサブシステム全体で再生データ（排他制御情報）の登録に使用可能なメモリ最大容量が減少している。あるいは言い換えると、ＭＳＣＰサブシステム全体で登録可能な再生データ（ロック情報）の最大量が減少している。このようなＭＳＣＰサブシステムにおける使用可能なメモリ最大容量（あるいは登録可能な再生データの最大量）の減少により、ＭＳＣＰにおいて再生すべきデータ（ロック情報）を全て登録することができずにデータ再生・再構成処理を失敗する可能性が有る。
【０００４】
例としてＭＳＣＰサブシステムが２台のＭＳＣＰで構成される場合を考える。それぞれのＭＳＣＰは同等の装置であり、同等のメモリサイズをロック情報（排他制御情報）の登録用に確保している。それぞれのＭＳＣＰにおいてロック情報の登録状況が（ＭＳＣＰの持つメモリ最大容量における）５０％を越えている状態で１台のＭＳＣＰに障害が発生したものとする。このとき、リカバリ処理により、障害発生により機能停止したＭＳＣＰを切り離して他のＭＳＣＰにデータ（ロック情報）の再生・再構成を行おうとするが、サブシステム全体で使用可能なＭＳＣＰは今１台であるため、この１台のＭＳＣＰに障害発生前の全てのデータを再生・再構成するには、そのデータ量が１台のＭＳＣＰのメモリ最大容量の１００％を越えるため不可能である。この場合、再生すべきデータがＭＳＣＰメモリ最大容量をオーバーフローすることによりＭＳＣＰサブシステムにおけるデータ再生が失敗するため、障害発生以降、正常に資源の排他制御を行うことができない、つまり、システムの運用を継続できない。
【０００５】
上記のようなデータ再生の失敗、つまりリカバリの失敗は、ＭＳＣＰサブシステムが３台以上のＭＳＣＰにより構成される場合も同様である。図２０に従来技術におけるリカバリ処理（以下、ソフトウェアリカバリ（ＳＷリカバリ）と呼ぶ）の概略イメージを示す。この図では、ＭＳＣＰサブシステムが３台のＭＳＣＰ２１〜２３により構成される場合を示している。各ＭＳＣＰ２１〜２３では、自装置内の排他制御テーブルｔ１〜ｔ３においてロック情報（排他制御情報）を登録・保持する。排他制御テーブルｔ１〜ｔ３は、ＭＳＣＰ内に確保される所定の最大サイズを持つメモリ領域である。斜線部分が使用中の領域、余白部分が未使用の空き領域を示す。ＭＳＣＰ系（ＭＳＣＰサブシステム）２において、例えば各ＭＳＣＰでテーブル容量の５０％以上を使用中の状態で運用中に、ＭＳＣＰ２３が障害により機能停止したものとする。ホスト１はそのことを検出すると、リカバリ機能を動作させ、機能停止したＭＳＣＰ２３の保持していたロック情報に関して、複数のホスト側が保持していたロック情報を用いて、ＭＳＣＰ系２におけるロック情報の再生・再構成処理を行う。この際、他のＭＳＣＰ群２１，２２でテーブルｔ１、ｔ２にそれぞれ保持しているロック情報も含めて全て構成し直す（再構成処理）。あるいは別のリカバリ処理として、ＭＳＣＰ２１，２２で既に保持していたロック情報はそのままにＭＳＣＰ２３のロック情報のみをテーブルｔ１，ｔ２の空き領域に再生する。
【０００６】
この場合、障害発生前のテーブルｔでのデータ登録状況（各テーブルｔで５０％以上を使用）に応じて、２台のＭＳＣＰ２１，２２のテーブル容量では再生データ（ロック情報）がオーバーフローしてしまいデータ再生処理を完了できず、リカバリを失敗してシステム運用停止となってしまう。この場合では、ＭＳＣＰ系２における障害発生前の総登録データ量と、障害発生後の２台のＭＳＣＰの総テーブル容量とで、前者の方が量が大きいため、再生データのオーバーフローが発生し、データ再生つまりリカバリを失敗してしまう。
【０００７】
【発明が解決しようとする課題】
本発明は、かかる問題点に鑑みてなされたものであり、疎結合システムにおけるリカバリ方式及び排他制御装置として、ＭＳＣＰ系での障害発生時にＳＷリカバリを実行する際のＭＳＣＰでのデータ登録用メモリ（排他制御テーブル）の容量不足によるデータ再生の失敗を回避・救済してシステムの可用性を向上できるリカバリ方式及び排他制御装置を提供することを目的とする。
【０００８】
【課題を解決するための手段】
かかる目的を達成するために、請求項１記載の発明は、複数のホストコンピュータと、ホストが共用する資源と、ホストの資源に対するアクセスを排他制御する排他制御装置サブシステムと、を有する疎結合システムにおけるリカバリ方式であって、サブシステムは、複数の排他制御装置から構成され、排他制御装置は、相互接続された対の二重化処理部で構成され、処理部は互いに対の処理部の排他制御情報をバックアップし一方の処理部が障害により機能停止した場合に他方の処理部が処理を引き継ぐハードウェアリカバリ機能を有し、サブシステムにおいて排他制御装置が障害により機能停止した場合に、ホスト主導により、機能停止した排他制御装置の排他制御情報に関して、ホストが保持する排他制御情報を用いて、機能停止した排他制御装置以外の排他制御装置群に再生するソフトウェアリカバリ機能を有し、ソフトウェアリカバリ機能の実行時に排他制御情報の再生を行う排他制御装置において排他制御テーブルで再生データがオーバーフローする場合にバックアップ処理用のテーブルも共に使用してデータ再生を行う回避機能を有することを特徴としている。
【０００９】
請求項２記載の発明は、請求項１記載の発明において、排他制御装置で対の二重化処理部は同時稼動し分担して排他制御処理を遂行し、互いに通常モード用の排他制御テーブルとバックアップ処理用のテーブルとを確保してハードウェアリカバリ機能を実行することを特徴としている。
【００１０】
請求項３記載の発明は、請求項１または２に記載の発明において、排他制御装置の二重化処理部は、排他制御情報を記憶する排他制御テーブルについてその使用量を監視する処理を行い、回避機能におけるデータ再生処理の後、バックアップ処理用のテーブルを含む排他制御テーブルに保持する排他制御情報が減少してその使用量が所定率を下回った場合にバックアップ処理用のテーブルの使用を元に戻して通常モードに戻る復帰機能をさらに有することを特徴としている。
【００１１】
請求項４記載の発明は、請求項３記載の発明において、復帰機能において通常モードに戻る時、ホストに要求して回避処理を実行した排他制御装置内でのみのデータ再構成を行うことを特徴としている。
【００１２】
請求項５記載の発明は、請求項３記載の発明において、復帰機能において通常モードに戻る時、ホストに要求して回避処理を実行した排他制御装置を含む排他制御装置サブシステム全体でのデータ再構成を行うことを特徴としている。
【００１３】
請求項６記載の発明は、複数のホストコンピュータの共用する資源に対するアクセスを排他制御する排他制御装置サブシステムを構成する排他制御装置であって、相互接続された対の二重化処理部で構成され、該処理部は互いに対の処理部の排他制御情報をバックアップし一方の処理部が障害により機能停止した場合に他方の処理部が処理を引き継ぐハードウェアリカバリ機能を有し、サブシステムにおいて排他制御装置が障害により機能停止した場合に、ホスト主導により、機能停止した排他制御装置の排他制御情報に関して、ホストが保持する排他制御情報を用いて、機能停止した排他制御装置以外の排他制御装置群に再生するソフトウェアリカバリ機能を有し、ソフトウェアリカバリ機能の実行時に排他制御情報の再生を行う時に排他制御テーブルで再生データがオーバーフローする場合にバックアップ処理用のテーブルも共に使用してデータ再生を行う回避機能を有することを特徴としている。
【００１４】
請求項７記載の発明は、請求項６記載の発明において、対の二重化処理部は同時稼動し分担して排他制御処理を遂行し、互いに通常モード用の排他制御テーブルとバックアップ処理用のテーブルとを確保してハードウェアリカバリ機能を実行することを特徴としている。
【００１５】
請求項８記載の発明は、請求項６または７に記載の発明において、二重化処理部は、排他制御情報を記憶する排他制御テーブルについてその使用量を監視する処理を行い、回避機能におけるデータ再生処理の後、バックアップ処理用のテーブルを含む排他制御テーブルに保持する排他制御情報が減少してその使用量が所定率を下回った場合にバックアップ処理用のテーブルの使用を元に戻して通常モードに戻る復帰機能をさらに有することを特徴としている。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態を添付図面を参照しながら詳細に説明する。図１は、本発明の第１の実施の形態におけるリカバリ方式を備える疎結合システムの構成を示す図である。本疎結合システム１００は、構成要素として、ホスト１（１１、１２、…、１Ｌ）、ＭＳＣＰ系２、資源３を有し、これらの間は所定のインタフェースで接続されて通信及びアクセスが行われる。ホスト１は独立した計算機（コンピュータ）システムであり複数存在する（１１〜１Ｌ）。ＭＳＣＰ系（ＭＳＣＰサブシステム）２は、複数のＭＳＣＰ（排他制御装置）（２１〜２Ｍ）のセットから成るサブシステムである。複数のＭＳＣＰで機能（排他制御機能やリカバリ機能）が実現されるので系あるいはサブシステムと呼ぶことにする。資源（リソース）３はディスク装置や拡張メモリなどが該当し、複数のホスト１１〜１Ｌにより共用・共有アクセスされる。ＭＳＣＰ系２は、ホスト１による資源３へのアクセスの制御（排他制御）を行う。
【００１７】
なお、ホスト１のグループにおいて任意のホストをホスト１ｘとし、各ホストを１１〜１Ｌとする。ＭＳＣＰ系２では、任意のＭＳＣＰをＭＳＣＰ２ｙとし、各ＭＳＣＰをＭＳＣＰ２１〜２Ｍとする。資源３は単一の装置、例えば単一のディスク装置であるものとし（※複数であっても処理・概念は同様である）、資源３中に存在するアクセス可能な複数の資源（ファイルなど）に対し異なる識別子によりアクセスされるものとする。
【００１８】
複数のホスト１１〜１Ｌの各々は独立したコンピュータシステム（プロセッサとメモリを備え、独立したＯＳ、プロセスが動作する）であり、それぞれ並列的に動作し、資源３を共用・共有する。つまり、本システム１００は、資源３を共用する疎結合システムである。
【００１９】
資源３は、複数のホスト１１〜１Ｌにより共用される性質のものであり、ディスク装置、拡張メモリなどが該当する。例えば、資源３がディスク装置である場合、ディスク装置上のファイル（データブロック）を単位としてアクセスの排他制御が行われる。資源３（中の資源単位）には、システム全体において一意に定まる識別子を介してアクセスが行われる。この識別子を資源ＩＤとする。例えば、資源ＩＤとして、ディスク装置上のファイル単位に異なる値が設定される。なお同一の資源ＩＤで識別される資源に対するアクセス制御は同一のＭＳＣＰが担当するように所定の方法で対応付け（割り当て）が行われる。ホスト１により、ＭＳＣＰ単位に管理する資源の割り当てが行われる。図２０のＳＷリカバリ処理のイメージにおいて、例として、資源３ａ〜３ｃをそれぞれＭＳＣＰ２１〜２３に対応させている様子を示す。
【００２０】
ＭＳＣＰ（排他制御装置）２ｙは、ホスト１と資源３との間において、ホスト１から資源３へのアクセスを排他制御する装置である。ホスト１が資源３にアクセスする際に、ＭＳＣＰ系２において所定のロック処理を行うことによりアクセスの排他制御を行う。ＭＳＣＰ系２による共用資源３の排他制御処理・機能については既存技術であるので詳細な説明は省略し（前述の公報にも記載されている）、その処理の概要だけ説明する。或るホスト１からの排他制御要求（或る資源（資源ＩＤ）へのアクセスの要求）に基づき、指定された資源に関するロックを掛け、そのホストが指定資源をロックした旨の情報である排他制御情報ｒを自装置内に確保されている排他制御テーブルｔに記録する。また指定の資源が他のホスト１によりロック済みであるときは、上記要求ホストがロック待ちである旨の情報を排他制御テーブルｔに記録する。このように、ＭＳＣＰで適切な排他制御情報ｒをテーブルｔに記録することによりホスト１による資源３へのアクセスの許可／不許可を行う。ホスト１は、ＭＳＣＰ系２から指定資源に対するアクセスの許可を得ると、指定資源に対して入出力命令を実行して（直接の）アクセスを行う。なお、図１他に例示したのは、ホスト１、ＭＳＣＰ系２、資源３の関係の概略であり、実際はネットワーク上で所定の接続構成を採ることができる。
【００２１】
また、ホスト１側でも、ＳＷリカバリ機能を実現するために同様に自ホストからの資源３へのアクセスに係わる排他制御情報ｒを自ホスト内部のメモリに格納する。ホスト１は、ＳＷリカバリ処理を実行する際は、メモリに格納している排他制御情報ｒを用いてＭＳＣＰ系２へのデータ（排他制御情報ｒ）再生・再構成を実行する。
【００２２】
ＭＳＣＰ２ｙは、処理部が二重化されており、２つのＤＸＵ（Dependent eXclusive Unit、二重化処理部）を収納する（図１でのＤＸＵ０とＤＸＵ１）。図２に、ＭＳＣＰ２ｙにおけるＤＸＵによる二重化構成を示す。２つのＤＸＵはペア（対、２つ１組）であり、構成は同等で、ペアインタフェース（ＰＩＦ：Pair InterFace）４２により相互接続され相互通信可能である。このＤＸＵ０及びＤＸＵ１及びＰＩＦ４２から構成される系をＤＸＵ系と呼ぶことにする。任意のＭＳＣＰ２ｙにおける任意のＤＸＵをＤＸＵ４と呼ぶことにする。また特にペアについてＤＸＵ４０、ＤＸＵ４１と呼ぶことにする。それぞれのＤＸＵ４は、ホスト１側との所定のインタフェース、資源３側との所定のインタフェースを持つ。各ＤＸＵ４０／４１は、プロセッサや内部メモリを備える装置である。プロセッサは、各処理・機能を実現するためのプログラムを実行する。
【００２３】
図３にＤＸＵ４０及び４１のブロック構成を示す。ＤＸＵ４０と４１は同構造である。ＤＸＵ４は、ペアインタフェース（ＰＩＦ）部５１、ホストインタフェース（ＨＩＦ）部５２、排他制御処理部５３、自排他制御テーブルｔｓ、対排他制御テーブルｔｐ、ＨＷリカバリ処理部５４、ＳＷリカバリ処理部５５、動作モード記憶部５６、及び、インデックステーブル５７を有する。
【００２４】
ＰＩＦ部５１は、ＰＩＦ４２を介して対ＤＸＵとの通信処理を行う。ＨＩＦ部５２は、ホスト１側との通信処理を行う。排他制御処理部５３は、ＭＳＣＰの主要な処理である排他制御処理を遂行する。通常時、排他制御情報ｒを自排他制御テーブルｔｓに登録（記録）する処理を行う。対排他制御テーブルｔｐは対ＤＸＵのデータの複製のバックアップ用のテーブルである。ＨＷリカバリ処理部５４は、ＤＸＵの二重化構成を利用したＭＳＣＰ２ｙ内でのリカバリ処理であるハードウェアリカバリ（ＨＷリカバリ）機能に係わる処理を行う。ＳＷリカバリ処理部５５は、ホスト１主導によるソフトウェア的なリカバリ処理であるソフトウェアリカバリ（ＳＷリカバリ）機能に係わる処理を行う。動作モード記憶部５６は、ＤＸＵ（ＭＳＣＰ）の動作モードを管理する。インデックステーブル５７は、排他制御テーブルｔ中のデータへのアクセスに用いる。
【００２５】
ＤＸＵ系において一方のＤＸＵ４０／４１は、他方のＤＸＵ４１／４０のデータ（排他制御情報ｒ）の複製をバックアップとして保持する。通常時（通常モード時）には随時、このバックアップ処理が行われる。或るＤＸＵからみて、自装置を自ＤＸＵ、ＰＩＦで接続された対となるＤＸＵを対ＤＸＵと呼ぶことにする。本システム１００では、ＭＳＣＰ２ｙ内でＤＸＵ４０及び４１は通常時（通常モード時）に同時に稼動し、排他制御処理を分担して行いながら、互いに対ＤＸＵのデータのバックアップ処理も行う。
【００２６】
ＤＸＵ４は、自装置内のメモリ上に、排他制御情報ｒを記録（登録）して管理する領域である排他制御テーブルｔを確保する。排他制御テーブルｔは所定の最大サイズを持つ。排他制御テーブルｔは、自排他制御テーブルｔｓと対排他制御テーブルｔｐとで構成される。自排他制御テーブルｔｓは、通常時の排他制御処理に使用されるテーブルである。対排他制御テーブルｔｐは、対ＤＸＵのデータの複製を記憶するバックアップ処理用のテーブルである。ＤＸＵ系においてペアのＤＸＵで互いにデータのバックアップを行うため、テーブルｔｓとテーブルｔｐはＤＸＵ４における排他制御テーブルｔの最大サイズのうちそれぞれ５０％をその最大サイズとして確保する。バックアップの処理はＰＩＦ部５１を介して行われる。通常時の排他制御処理の際に参照されるのは自排他制御テーブルｔｓである。
【００２７】
ＨＷリカバリ機能とは、ＭＳＣＰ２ｙ内においてペアのＤＸＵ４０及び４１による二重化構成を利用して一方が障害により機能停止したときに他方がバックアップデータを利用して処理を引き継ぐことによりシステム運用を継続する機能である。通常時、各々のＤＸＵは、対ＤＸＵのデータ（排他制御情報ｒ）の複製を対排他制御テーブルｔｐにバックアップする処理を行っているので、障害発生検出時は、そのテーブルｔｐのデータを利用して機能停止した対ＤＸＵの処理を引き継ぎ排他制御処理を代替動作する。
【００２８】
ＳＷリカバリ機能とは、ＭＳＣＰ系２において１つ以上のＭＳＣＰ２ｙに障害が発生して機能停止した際に、ホスト１主導により、障害により機能停止したＭＳＣＰのデータ（排他制御情報ｒ）に関して複数のホスト１で保持している排他制御情報ｒを用いてＭＳＣＰ系２における他の（生き残った）ＭＳＣＰ２ｙ群においてデータ再生・再構成し処理を引き継がせてシステム運用を継続する機能である。このＳＷリカバリ機能については従来技術の説明で参照した公報にもその実施例が説明されている。ＳＷリカバリの方式としては、ＭＳＣＰ系２において全ての排他制御情報ｒを構成し直す（再構成）処理を行う方式、また、機能停止したＭＳＣＰの排他制御情報ｒのみを他のＭＳＣＰ２ｙ群の空き領域へ再生する方式など幾つか考えられる。ＳＷリカバリ処理の概略イメージは図２０に示してある。
【００２９】
ホスト１は、ＳＷリカバリ機能を実現するために、ＭＳＣＰ２ｙが保持する排他制御情報ｒと同様に排他制御情報（自ホストからのアクセス要求に係わる排他制御情報）を保持する。ホスト１は、ＭＳＣＰ２ｙの障害を検出した場合は、ＭＳＣＰ系２に対してＳＷリカバリ要求を行って排他制御情報ｒの再生・再構成を行わせる。
【００３０】
本システム１００では、ＨＷリカバリ機能とＳＷリカバリ機能の処理を組み合わせ、ＳＷリカバリ時にＭＳＣＰ２ｙにおけるＨＷリカバリ処理用つまりバックアップ処理用のメモリ領域（対排他制御テーブルｔｐ）を必要に応じて使用することにより、ＳＷリカバリ時のＭＳＣＰ２ｙでの内部メモリ容量不足によるデータ（排他制御情報ｒ）再生の失敗を回避・救済する。
【００３１】
ホスト１は、ＭＳＣＰ系２内の全ＤＸＵとのインタフェースを有し、各ＤＸＵ４との間で通信を行うことができる。ホスト１は、ＤＸＵとのインタフェースに加え、各処理を行う処理部を備えるが図では省略している。各ＤＸＵ４は、各ホスト１１〜１Ｌとの通信処理を行うホストインタフェース（ＨＩＦ）部５２を有する。
【００３２】
ＭＳＣＰ２ｙにおいてＤＸＵ４０とＤＸＵ４１は、通常時、ホスト１からの要求を分担して処理し、かつ、自ＤＸＵでの処理結果を対ＤＸＵにバックアップしながら排他制御処理を遂行する。ＤＸＵ系では、ＨＷリカバリ機能により、一方のＤＸＵが障害で機能停止した場合は他方のＤＸＵが対排他制御テーブルｔｐに記録してあるバックアップデータを利用して処理を引き継ぐ（代替動作する）。
【００３３】
本発明のリカバリ方式では、ＨＷリカバリ機能とＳＷリカバリ機能とを備えるシステムにおいて、両方のリカバリ機能を組み合わせ、ＳＷリカバリ処理の際のＭＳＣＰ２ｙにおけるメモリ容量不足によるデータ再生の失敗を回避・救済する。本システム１００では、障害の発生によりＭＳＣＰ系２における稼動ＭＳＣＰ台数が減少し、再生すべき排他制御情報ｒの量がＭＳＣＰ２ｙにおけるデータ登録用のメモリ容量（自排他制御テーブルｔｓの容量）をオーバーする場合でも、バックアップ処理用の排他制御テーブルｔｐも一時使用（臨時使用）してデータ再生・再構成処理を行うことにより、データ再生の失敗つまりＳＷリカバリの失敗を回避・救済することができる。
【００３４】
本システム１００では、ＭＳＣＰ２ｙにおけるデータ登録用のメモリ（自排他制御テーブルｔｓ）の容量不足によるデータ再生の失敗及びその結果としてのシステム運用停止を回避するために、ＳＷリカバリ処理部５５は、ＭＳＣＰ２ｙにおいてＤＸＵ４の持つ自排他制御テーブルｔｓだけでは再生・記録すべきデータ（排他制御情報ｒ）がオーバーフローすると判断した場合、あるいは、オーバーフローしてしまった場合に、両方のＤＸＵ４０及び４１の対排他制御テーブルｔｐをクリアして対排他制御テーブルｔｐも自排他制御テーブルｔｓと共に使用してデータ再生を行うモードへと移行する。これによりＭＳＣＰ２ｙでのメモリ容量不足によるデータ再生の失敗を回避してデータ再生処理を継続し、排他制御テーブルｔｓ及びｔｐへの再生すべき全ての排他制御情報ｒの登録（記録）処理を完了すると（ＳＷリカバリ処理を完了して）システム運用（排他制御処理）を再開する。
【００３５】
また、本システム１００では、上記の対排他制御テーブルｔｐを自排他制御テーブルｔｓと共にデータ再生に使用した状態で運用を再開した後、処理の経過により、排他制御テーブルｔ（ｔｓ＋ｔｐ）に登録している排他制御情報ｒが減少して自排他制御テーブルｔｓのみで排他制御情報ｒの保持を十分に賄える状態となったと判断すると、ＭＳＣＰ２（ＤＸＵ４）は、ホスト１側に対し排他制御情報ｒを再度再生し直すように促して通常モードへ復帰する処理を行う。再生すべき排他制御情報ｒが減少しているので対排他制御テーブルｔｐを使うことなくデータ再生を行うことができ、信頼性を回復した運用（対排他制御テーブルｔｐを利用したバックアップ処理が可能な通常モード）に戻ることが出来る。
【００３６】
ＤＸＵ４の動作を説明する。ＭＳＣＰ２ｙにおいてＤＸＵ４は、ホスト１から要求（資源３へのアクセス要求＝排他制御要求など）を受信した場合、対ＤＸＵから指示があった場合、対ＤＸＵの障害を検出した場合、の３つの場合に動作する。
【００３７】
ＤＸＵ４は、自ＤＸＵが管理する資源（資源ＩＤで識別される）についての排他制御情報ｒを自排他制御テーブルｔｓに記録する。また、インデックステーブル５７に、資源ＩＤと、これに対応する排他制御情報ｒが記録されている排他制御テーブルｔ内のアドレスとの対応を記録する。ＭＳＣＰ２ｙにおいて排他制御情報ｒを参照する際はインデックステーブル５７を介してアクセスする。
【００３８】
対排他制御テーブルｔｐには、通常時は、対ＤＸＵが管理する排他制御情報ｒの複製がバックアップデータとして記録される。本システム１００では、対排他制御テーブルｔｐは、ＭＳＣＰ系２においてＭＳＣＰ２ｙが障害発生により縮退した場合の他ＭＳＣＰ群への排他制御情報ｒの再生・再構成の際、自排他制御テーブルｔｓだけではメモリ容量が不足する（データがオーバーフローする）場合に、再生すべき排他制御情報ｒを記憶するための領域として一時的（臨時）に使用される。この一時的なモードでは、対排他制御テーブルｔｐは、自排他制御テーブルｔｓと同様に自ＤＸＵが管理する資源（資源ＩＤ）に対する排他制御情報ｒを記憶するように制御される。
【００３９】
図５は、インデックステーブル５７の構成例を示す。インデックステーブル５７には、資源ＩＤと、その資源ＩＤに対応する資源に関する排他制御情報ｒが記憶されている排他制御テーブルｔ内でのアドレスと、の対応が記録・管理される。インデックステーブル５７は、排他制御テーブルｔの更新に伴って更新される。ＤＸＵ４は、ホスト１により或る資源が資源ＩＤにより指定されたときは、インデックステーブル５７内のレコードから該当アドレスを参照して排他制御情報ｒにアクセスする。また、ＤＸＵ４は、インデックステーブル５７を参照することにより、排他制御テーブルｔ（ｔｓ＋ｔｐ）において排他制御情報ｒの記録に使用している使用量（使用率）を計算する処理を行う。
【００４０】
動作モード記憶部５６は、ＭＳＣＰ２ｙにおける現在の動作モードを記憶・管理する。ＭＳＣＰ２ｙの動作モードには、通常モード（ＮＭモード）、対障害動作モード（Ｒ１モード）、分離動作モード（Ｒ２モード）がある。ペアのＤＸＵ４０と４１では基本的に同一の動作モードをとるように制御される。
【００４１】
ＮＭモードは、ＭＳＣＰ２ｙを構成する両ＤＸＵ４０及び４１が正常な（障害でない）状態であり、かつ、各々における対排他制御テーブルｔｐが対ＤＸＵの自排他制御テーブルｔｓのデータのバックアップとなっている状態である。
【００４２】
Ｒ１モードは、ＭＳＣＰ２ｙを構成する一方のＤＸＵが障害による機能停止により切り離されている状態であり、生き残った他方の対ＤＸＵが対排他制御テーブルｔｐに記録していたバックアップデータを使用して、切り離されたＤＸＵが管理する資源（資源ＩＤ）の排他制御処理を代替している状態である。
【００４３】
Ｒ２モードは、ＭＳＣＰ２ｙを構成する両ＤＸＵとも正常な状態だが、各々で対排他制御テーブルｔｐを自ＤＸＵが管理する資源（資源ＩＤ）の排他制御処理に一時的（臨時）に使用している状態である。この状態では、対ＤＸＵの排他制御情報ｒのバックアップは行われていない。本システム１００では、ＳＷリカバリ処理時にＭＳＣＰ２ｙ内で自排他制御テーブルｔｓだけでは再生すべきデータがオーバーフローする時に、このモードに移行してデータ再生の失敗を回避・救済する。つまり、対ＤＸＵのデータのバックアップを継続することよりも、当面のＳＷリカバリ処理に関してその失敗を救済することの方を優先する。また、ＭＳＣＰ２ｙは、Ｒ２モードに入った後、処理の経過によりＭＳＣＰ２ｙにおいて保持する排他制御情報ｒが減少して自排他制御テーブルｔｓのみで賄えるようになったと判断した場合は、ＮＭモードへ復帰してバックアップ処理を再開し信頼性を回復した運用へと戻る処理を行う。
【００４４】
図６〜９に、ＭＳＣＰ２ｙのＤＸＵ系での各動作モードにおける排他制御テーブルｔの使用の様子を示す。図６は、ＮＭモード、図７は、Ｒ１モード、図８は、Ｒ２モードにおける排他制御テーブルｔの使用の様子についてそれぞれ示す。また図９は、Ｒ２モードからＮＭモードへの復帰について示す図である。各テーブルｔｓ、ｔｐについて、ＤＸＵ４０側をｔｓ０、ｔｐ０、またＤＸＵ４１側をｔｓ１、ｔｐ１とした。
【００４５】
図８で、ＳＷリカバリ処理時に、例えばＤＸＵ４０において、自排他制御テーブルｔｓ０で記録すべき再生データ（ｒ）がｔｓ０の最大容量をオーバーする場合に、対排他制御テーブルｔｐ０も使用してオーバーフローした分のデータの登録（記録）を行うようにモードをＲ２へ切り替える。対のＤＸＵで同じモードをとるように制御するため、対ＤＸＵ４１へも通知（オーバーフロー通知）を行ってＲ２モードへと移行させる。
【００４６】
また図９で、Ｒ２モードへ移行後、処理の経過により、ＤＸＵ４０において排他制御テーブルｔ（ｔｓ＋ｔｐ）におけるデータ登録の使用量（使用率）が所定率、ここでは５０％（つまり自排他制御テーブルｔｓの最大サイズ）、以下に収束したものとする。ＭＳＣＰ２ｙは、これを契機に、Ｒ２モードからＮＭモードへの復帰を行う。つまり、対排他制御テーブルｔｐを一時的な（臨時の）現用テーブルとして稼動させるのを止め、対ＤＸＵのバックアップ用に戻す処理を行う。これは、ホスト１側にその旨の要求を行って該当ＭＳＣＰ２ｙにおける排他制御情報ｒの再構成を行うことにより行う（このとき他のＭＳＣＰ群も含めてデータ（ｒ）の再構成処理を行うよう制御してもよい）。
【００４７】
また、図１０に、ＭＳＣＰ２ｙにおける各動作モードと各テーブルの状態との対応を整理したものを示す。ＮＭモードでは、特にインデックステーブル５７において、自排他制御テーブルｔｓに登録されている排他制御情報ｒのアドレスを記録する。Ｒ１モードでは、インデックステーブル５７において、自排他制御テーブルｔｓと対排他制御テーブルｔｐの双方に関して登録されている排他制御情報ｒのアドレスを記録する。Ｒ２モードでは、対排他制御テーブルｔｐにおいて自ＤＸＵが管理すべき資源ＩＤに対応する排他制御情報ｒを記録し、インデックステーブル５７において、自排他制御テーブルｔｓと対排他制御テーブルｔｐの双方に関して登録されている排他制御情報ｒのアドレスを記録する。
【００４８】
ＨＩＦ部５２は、ホスト１から要求データを受信すると、受信した要求の種別に従って要求データを排他制御処理部５３またはＳＷリカバリ処理部５５へ渡し、排他制御処理部５３またはＳＷリカバリ処理部５５での処理の終了状態（処理結果）をホスト１へ通知する処理を行う。また、ＨＩＦ部５２は、動作モードを確認して動作モードがＲ２の場合は、自ＤＸＵの排他制御テーブルｔ（自排他制御テーブルｔｓ＋対排他制御テーブルｔｐ）における使用率をチェックする処理（テーブル使用量監視処理）を行い、使用率が所定率例えば５０％未満ならばホスト１に対し排他制御情報ｒを再度再生し直すように通知する処理を行ってこれによりＮＭモードへと復帰させる。
【００４９】
図４に、ホスト１からＭＳＣＰ２ｙへの要求データの構造を示す。要求データは、要求の種類を示す種別情報と、要求対象の資源の資源ＩＤと、要求の詳細を示すデータと、を含むデータである。要求の種別として、排他制御要求、ＳＷリカバリ−初期化要求、ＳＷリカバリ−データ再生要求などがある。
【００５０】
排他制御処理部５３は、上記要求データに含まれる資源ＩＤ情報と、現在の動作モードとから、登録に使用する排他制御テーブルｔ（ｔｓあるいはｔｐ）を決定する処理（分配制御処理）を行い、また、要求データに関する排他制御処理を実行して排他制御情報ｒを上記分配制御処理で決定した排他制御テーブルｔ（ｔｓあるいはｔｐ）に登録（追加／更新／削除）する処理を行い、また、テーブルｔにおける排他制御情報ｒの格納場所（アドレス）をインデックステーブル５７に反映する処理を行う。この後、排他制御処理部５３は、動作モードがＮＭ以外の場合は正常終了し、動作モードがＮＭの場合は、ＰＩＦ部５１に自排他制御テーブルｔｓのデータを対ＤＸＵ内の対排他制御テーブルｔｐへバックアップするように依頼して（「バックアップ要求」）それに対する対ＤＸＵ及びＰＩＦ部５１からの応答（「バックアップ完了通知」）を待ち合わせ、ＰＩＦ部５１からバックアップ完了通知を受け取ると処理を正常終了する。
【００５１】
また、ＳＷリカバリ処理実行時、排他制御テーブルｔ（ｔｓ）へのデータ登録時に排他制御テーブルｔ（ｔｓ）がオーバーフローした場合は「オーバーフロー」である旨を終了状態として返し、対応する処理を行わせる。
【００５２】
ＰＩＦ部５１は、ＳＷリカバリ処理部５５からオーバーフロー通知の送信要求を受けるとオーバーフロー通知を対ＤＸＵへ転送する処理を行う。また対ＤＸＵのＰＩＦ部５１からオーバーフロー通知を受け取った場合はＳＷリカバリ処理部５５へ渡す。
【００５３】
また、ＰＩＦ部５１は、排他制御処理部５３から排他制御情報ｒのバックアップデータの送信要求（バックアップ要求）を受けるとデータを対ＤＸＵへ転送する処理を行う。また対ＤＸＵのＰＩＦ部５１から排他制御情報ｒのバックアップデータを受け取った場合は排他制御処理部５３へ渡して対排他制御テーブルｔｐへ格納させ、バックアップ完了通知を対ＤＸＵのＰＩＦ部５１へ返す。また対ＤＸＵのＰＩＦ部５１からバックアップ完了通知を受けた場合は、排他制御処理部５３へこれを渡す。
【００５４】
ＨＷリカバリ処理部５４は、対ＤＸＵの障害が発生した場合（対ＤＸＵの障害が検出された場合）、自ＤＸＵの対排他制御テーブルｔｐを検索して登録されている排他制御情報ｒについてそのアドレスをインデックステーブル２８に追加登録して反映し、動作モードをＲ１に切り替える処理を行う。
【００５５】
ＳＷリカバリ処理部５５は、ＨＩＦ部５２経由でホスト１側から初期化要求が通知された場合は、ＳＷリカバリ処理として、自排他制御テーブルｔｓと対排他制御テーブルｔｐ及びインデックステーブル５７を初期化（クリア）する処理を行い、かつ、動作モードがＲ２ならばＮＭに切り替える。また、ＳＷリカバリ処理部５５は、ＨＩＦ部５２から再生すべき排他制御情報ｒを受け取った場合は排他制御処理部５３へ処理を依頼し、排他制御処理部５３からオーバーフローの通知を受けた場合は本発明に特徴的な処理である回避処理を実行する。
【００５６】
ＳＷリカバリ処理部５５における回避処理では、動作モードがＮＭかどうかを確認し、ＰＩＦ部５１に対ＤＸＵへのオーバーフロー通知の送信を依頼して通知を送信させ、動作モードをＲ２に変更し、自ＤＸＵの対排他制御テーブルｔｐをクリアし、自排他制御テーブルｔｓでのデータオーバーフローにより再生できなかった分の排他制御情報ｒを対排他制御テーブルｔｐに登録して再生する処理を行う。
【００５７】
また逆にＰＩＦ部５１を介して対ＤＸＵからオーバーフロー通知を受け取った場合は、動作モードをＲ２に変更し、対排他制御テーブルｔｐをクリアして対ＤＸＵと同様に自ＤＸＵにおける排他制御情報ｒの記録を行うよう制御する。
【００５８】
次に、本実施例のシステム１００での各処理の流れについて図１１〜１９のフローチャートを参照しながら説明する。図１１は、ＤＸＵ４が動作する要因が発生してからの一連の動作の流れを示す概略フローである。図１２は、ホストインタフェース部５２の処理の概略フローである。図１３は、排他制御処理部５３の処理の概略フローである。図１４は、図１３の排他制御処理部５３での分配制御処理の手順を示すフローである。図１５は、ＨＷリカバリ処理部５４の処理の概略フローである。図１６は、ペアインターフェース部５１の処理の概略フローである。図１７は、ＳＷリカバリ処理部５５の処理の概略フローである。図１８は、図１７のＳＷリカバリ処理部での回避処理の手順を示すフローである。図１９は、図１２のホストインターフェース部５２での使用量監視処理の手順を示すフローである。
【００５９】
図１１のＤＸＵ４の処理を示すフローにおいて、ＤＸＵ４は、ホスト１側から要求データを受け取った場合、対ＤＸＵから指示があった場合、対ＤＸＵの障害を検出した場合、の各場合に動作を開始し（図１１・ステップＳ１) 、各場合に対応して必要な処理部により処理を実行する。
【００６０】
ホスト１は、ＭＳＣＰ系２に対して要求した処理の結果（特に排他制御情報ｒ）を自装置内のメモリに記憶し、ＳＷリカバリ実行時に再生データとして用いるために参照する。ホスト１側の動作の詳細は前述で参照した公報に詳述されているので省略する。
【００６１】
まず、ＭＳＣＰ２ｙにおいてホスト１側から排他制御要求（資源３へのアクセス要求）を受けた場合の動作を、動作モード別に説明する。図１１はＤＸＵの動作、図１２はＤＸＵのＨＩＦ部の動作、図１３は排他制御処理部５３の動作、図１６は分配制御処理の動作手順、図１９は使用量監視処理の動作手順、をそれぞれ示すフローである。
【００６２】
まず、ＮＭモード時の処理について説明する。ＤＸＵ４は、ホスト１からの要求データをＨＩＦ部５２で受信する（図１１・Ｓ２）。
【００６３】
ＨＩＦ部５２（処理は図１２参照）は、受信した要求についてその種別を確認する。ここでは要求が排他制御要求であるので（ステップＳ２−「排他制御要求」）、排他制御処理部へ処理を引き継ぐ（図１２ステップＳ２１→Ｓ２２→図１１・Ｓ３→図１３）。
【００６４】
排他制御処理部５３（図１３参照）は、まず、分配制御処理（ステップＳ３１→図１６）を行い、更新する排他制御テーブルｔを決定する。図１６で、まず動作モードはＮＭであるので（ステップＳ６１−「ＮＭ」）、この場合は自排他制御テーブルｔｓと決定する（ステップＳ６４）。図１３で、次に、オーバーフローせずに処理できるかどうかを確認し（ステップＳ３２）、オーバーフローするようならば「オーバーフロー」として処理を終了し（ステップＳ３２−ＮＯ→「オーバーフロー」）、処理可能ならば処理を継続する（ステップＳ３２−ＹＥＳ）。次に、要求内容が登録要求ならば排他制御情報ｒを排他制御テーブルｔ（ここでは自排他制御テーブルｔｓ）に登録し、更新要求なら登録済みの排他制御情報ｒに関して更新し、削除要求なら登録済みの排他制御情報ｒを削除し、対応してインデックステーブル５７を更新する（ステップＳ３３）。動作モードがＮＭかを確認後（ステップＳ３４−「ＮＭ」）、次に、ＰＩＦ部５１に対して排他制御情報ｒのバックアップを要求し（ステップＳ３５）、この要求に対する応答（バックアップ完了通知）を待ち合わせる（ステップＳ３６）。そしてその後正常終了する（「正常終了」）。
【００６５】
次に、ＤＸＵ４は、ＨＩＦ部５２にて排他制御処理部５３での処理結果をホスト１に対し通知する処理を行う（図１１・ステップＳ４→図１２・ステップＳ２３）。その後、使用量監視処理（ステップＳ２４→図１９）を実施するが、ここではＮＭモードであるので何もしない（図１９ステップＳ９１−「ＮＭ」）。以上が、ＮＭモード時の排他制御要求に対する処理である。
【００６６】
次に、Ｒ１モード時の処理について、ＮＭモード時と異なる部分のみを説明する。異なるのは以下の２点である。
【００６７】
分配制御処理（図１６）にて、動作モードは「Ｒ１」であるので、資源ＩＤから、自／他のいずれかの排他制御テーブルｔを使用するか決定する処理を行う（ステップＳ６２）。要求されている資源が自ＤＸＵで管理する資源であるならば、自排他制御テーブルｔｓと決定し（ステップＳ６２−「自排他制御テーブル」→Ｓ６４）、また、要求されている資源が対ＤＸＵで管理する資源であるならば対排他制御テーブルｔｐと決定する（ステップＳ６２−「対排他制御テーブル」→Ｓ６３）。
【００６８】
対ＤＸＵが障害により機能停止状態であるため、排他制御処理部５３にて、ＰＩＦ部５１を使用してのバックアップ処理を行なわずに終了する（図１３ステップＳ３４−「Ｒ１」→「正常終了」）。
【００６９】
次に、Ｒ２モード時の処理について、Ｒ１モード時と異なる部分のみを説明する。異なるのは以下の２点である。
【００７０】
自排他制御テーブルｔｓと対排他制御テーブルｔｐの両方をデータの登録（格納）処理に使用する。排他制御処理部５３での分配制御処理（図１６）にて、動作モードを確認して、排他制御情報ｒの登録に使用するテーブルとして、空きスペースがある方のテーブルに決定する処理を行う（図１６ステップＳ６１−「Ｒ２」→Ｓ６５）。空きスペースが有ればどちらのテーブル（ｔｓ／ｔｐ）を使用しても良いが、例えば、自排他制御テーブルｔｓへの登録を優先し、自排他制御テーブルｔｓが全て使用中となっている場合は対排他制御テーブルｔｐに登録する、などの方法で処理する。
【００７１】
ＨＩＦ部５２での使用量監視処理（図１２ステップＳ２４→図１９）にて、動作モードを確認して（ステップＳ９１−「Ｒ２」）、インデックステーブル５７を参照して排他制御テーブルｔにおける排他制御情報ｒ登録の使用量（使用率）を計算する処理を行い（ステップＳ９２）、テーブルｔにおける空きスペースが、（ｔｓ及びｔｐを合わせた最大容量における）所定率以上、ここでは５０％以上、となった場合（あるいは同じことであるがテーブルｔにおける使用量が所定率未満となった場合）（ステップＳ９３−ＹＥＳ）、ホスト１側に対しデータ再生指示を行って再度データの再生・再構成処理を行いＮＭモードへ復帰する（ステップＳ９４）。空きスペースが５０％未満ならば処理を終了する（ステップＳ９３−ＮＯ）。
【００７２】
次に、ＮＭモード時に対ＤＸＵの障害を検出した場合のリカバリ動作であるＨＷリカバリ処理について説明する。図１４はＨＷリカバリ処理部５４の動作を示すフローチャートである。
【００７３】
ＤＸＵ４は、対ＤＸＵの障害を検出すると（図１１・ステップＳ１−「対ＤＸＵの障害を検出」）、ＨＷリカバリ処理を実施する（ステップＳ６→図１４）。
【００７４】
図１４がＨＷリカバリ処理部５４の処理である。動作モードを確認し、ＮＭモードであるならば（ステップＳ４４−ＹＥＳ）、動作モードをＮＭからＲ１に変更する処理を行い（ステップＳ４２）、かつ、対排他制御テーブルｔｐに登録されている排他制御情報ｒのアドレスをインデックステーブル２８に追加登録する処理を行う（ステップＳ４３）。
【００７５】
次に、ＳＷリカバリ処理の動作について説明する。図１５はＳＷリカバリ処理部５５の動作を示すフローチャートである。ＳＷリカバリとは、ホスト１がＭＳＣＰ２ｙの障害（＝ＤＸＵ系の両方が機能停止）を検出した時にＭＳＣＰ系２で障害の発生していない他ＭＳＣＰ群にデータ（排他制御情報ｒ）を再生してシステム運用を継続する処理である。図２０の構成例で、例えばＭＳＣＰ２３でＤＸＵ０とＤＸＵ１の双方とも機能停止となった場合、ＭＳＣＰ系２で使用可能なＭＳＣＰはＭＳＣＰ２１及び２２となる。ＭＳＣＰ２１と２２でＭＳＣＰ系２を運用するために、ホスト１側は、ＭＳＣＰ２１，２２が保持していた排他制御情報ｒに関する初期化を指示後、ＭＳＣＰ系２における全ての排他制御情報ｒの再生・再構成を指示する。なお、図２０では、各ＭＳＣＰ２１〜２３におけるＤＸＵ系による二重化構成は図示していないが、二重化構成（及びＨＷリカバリ機能）を備える場合にもＳＷリカバリ処理の考え方は同様である。
【００７６】
ＭＳＣＰ２ｙのＤＸＵ４は、ホスト１からの初期化要求をＨＩＦ部５２で受け取る（図１１・ステップＳ２）。
【００７７】
ＨＩＦ部５２（図１２）は、受け取った要求についてその種別を確認し、ＳＷリカバリ処理部２５へ処理を引き継ぐ（図１２・ステップＳ２１→Ｓ２２−「排他制御要求以外」→図１１・ステップＳ５→図１５）。
【００７８】
図１５で、ＳＷリカバリ処理部５５は、要求の種類が初期化要求である場合（ステップＳ５１−「初期化要求」）、自排他制御テーブルｔｓと対排他制御テーブルｔｐとインデックステーブル５７とをクリアし（ステップＳ５２）、動作モードがＲ２の場合はＮＭに変更し（ステップＳ５３）、処理を正常終了する。
【００７９】
ＤＸＵ４は、ＳＷリカバリ処理部５５の処理結果をＨＩＦ５２にてホスト１側に通知する。
【００８０】
次に、ＤＸＵ４は、ホスト１から排他制御情報ｒを再生要求として受け取り、ＳＷリカバリ処理部５５の処理を実行する。ＳＷリカバリ処理部５５は排他制御処理部５３へデータ登録処理として処理を依頼し（図１５・ステップＳ５１−「データ再生」）、排他制御処理部５３はデータ再生処理を行う（図１５・ステップＳ５４）、排他制御処理部５３が正常終了したら（図１５・ステップＳ５４−「正常終了」）、ＳＷリカバリ処理部５５も正常終了する。
【００８１】
ＤＸＵ４は、ＳＷリカバリ処理部５５での処理結果をＨＩＦ部５２にてホスト１側に通知する。
【００８２】
次に、本発明の中心的な処理である回避処理（ＳＷリカバリ時のデータ再生の失敗の回避・救済処理）について説明する。図１８は回避処理の動作手順を示すフローチャートである。
【００８３】
排他制御処理部５３にて自排他制御テーブルｔｓでの排他制御情報ｒの再生処理中に、テーブルｔｓでデータオーバーフローが発生した場合、ＳＷリカバリ処理部５５は回避処理を実施する（図１５・ステップＳ５４−「オーバーフロー」→Ｓ５５→図１８）。
【００８４】
図１８において、まず動作モードを確認し（ステップＳ８１）、ＮＭならば回避処理を開始する（ステップＳ１−「ＮＭ」）。モードがＲ１、Ｒ２の場合はエラーである（「ＮＧ」）。
【００８５】
まず、対ＤＸＵに対しオーバーフロー通知を行う（ステップＳ８２）。次に動作モードをＲ２に変更する処理を行う（ステップＳ８３）。次に、対排他制御テーブルｔｐをクリアする処理を行う（ステップＳ８４）。次に、テーブルｔｓでオーバーフローして登録できなかった分の排他制御情報ｒを対排他制御テーブルｔｐに登録し、対応するアドレスをインデックステーブル５７に追加して反映する処理を行う（ステップＳ８５）。そしてＳＷリカバリ処理部５５を正常終了する（「ＯＫ」）。
【００８６】
ＤＸＵ４は、ＳＷリカバリ処理部５５での処理結果をＨＩＦ部５２によりホスト１側に対し通知する。
【００８７】
対ＤＸＵからオーバーフロー通知を受け取ったＤＸＵ４は、ＳＷリカバリ処理部５５での処理を起動する（図１５・ステップＳ５１−「オーバーフロー通知」）。
【００８８】
ＳＷリカバリ処理部５５は、動作モードをＲ２に変更し（図１５・ステップＳ５７）、対排他制御テーブルｔｐのデータをクリアする処理を行い（ステップＳ５８）、正常終了する。
【００８９】
以上の回避処理にて、ＳＷリカバリ処理時にＤＸＵ４の自排他制御テーブルｔｓで再生すべきデータがオーバーフローすることにより発生するＳＷリカバリの失敗（＝システム運用停止）を回避・救済する。
【００９０】
図１７はＰＩＦ部５１の動作を示すフローチャートである。処理については前述した通りである。
【００９１】
以上により本発明の実施の形態について説明した。なお、上述した実施形態は、本発明の好適な実施形態の一例を示すものであり、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲内において、種々変形実施が可能である。
【００９２】
【発明の効果】
以上の説明から明らかなように、本発明によれば、ＳＷリカバリ機能とＨＷリカバリ機能とを有する疎結合システムにおいて、ＳＷリカバリ処理実行時にＭＳＣＰにおいてデータ登録用のメモリ（自排他制御テーブル）の容量不足により再生データがオーバーフローする場合に対ＤＸＵのバックアップ用のメモリ（対排他制御テーブル）も一時的（臨時）に前者のメモリと共に使用してデータ再生を行う回避処理を行うため、予備のＭＳＣＰ（排他制御装置）を設けないシステム構成であっても、ＳＷリカバリ処理時のＭＳＣＰにおけるメモリ容量不足によるデータ再生の失敗を回避・救済してＳＷリカバリの動作を保証し、システムの可用性を向上することができる。
【００９３】
また、ＭＳＣＰサブシステムにおいて複数のＭＳＣＰの縮退が発生した場合にも、ＳＷリカバリ失敗の救済の可能性が上がりシステムの可用性が向上する。
【００９４】
また、ＭＳＣＰにおいて排他制御テーブルの使用量（使用率）を監視する処理を行ってテーブルの空きの状態に応じて分離動作モードから通常モードへの復帰を行うため、信頼性を回復した運用に戻ることができる。
【図面の簡単な説明】
【図１】本発明の実施の形態におけるリカバリ方式を実行する疎結合システム１００の構成を示す図である。
【図２】ＭＳＣＰ４におけるＤＸＵ系の構成を示す図である。
【図３】ＤＸＵ４（４０あるいは４１）のブロック構成を示す図である。
【図４】ホスト１からの要求データの形式を示す図である。
【図５】インデックステーブル５７の構成例を示す図である。
【図６】ＮＭモード時における排他制御テーブルｔの使用の様子を示す図である。
【図７】Ｒ１モード時における排他制御テーブルｔの使用の様子を示す図である。
【図８】Ｒ２モード時における排他制御テーブルｔの使用の様子を示す図である。
【図９】Ｒ２→ＮＭモードにおける排他制御テーブルｔの使用の様子を示す図である。
【図１０】各種テーブルと各動作モードとの対応を示す図である。
【図１１】ＤＸＵ４のＤＸＵ４が動作する要因が発生してからの一連の動作の概略を示すフローチャートである。
【図１２】ホストインタフェース部５２の動作を示すフローチャートである。
【図１３】排他制御処理部５３の動作を示すフローチャートである。
【図１４】ＨＷリカバリ処理部５４の動作を示すフローチャートである。
【図１５】ＳＷリカバリ処理部５５の動作を示すフローチャートである。
【図１６】排他制御処理部５３での分配制御処理の動作を示すフローチャートである。
【図１７】ペアインタフェース部５１の動作を示すフローチャートである。
【図１８】ＳＷリカバリ処理部５５での回避処理の動作を示すフローチャートである。
【図１９】ホストインタフェース処理部５２での使用量監視処理の動作を示すフローチャートである。
【図２０】ＳＷリカバリ処理の概略イメージを示す図である。
【符号の説明】
１００  実施例のリカバリ方式を実行する疎結合システム
１  ホスト
１１〜１Ｌ  ホスト
２  ＭＳＣＰ系（ＭＳＣＰサブシステム）
２１〜２Ｍ  ＭＳＣＰ（排他制御装置）
３  資源
４  ＤＸＵ（二重化処理部。ＤＸＵ４０あるいはＤＸＵ４１）
４０、４１  ＤＸＵ系におけるペアのＤＸＵ
４２  ＰＩＦ（ペアインタフェース）
５１  ペアインタフェース（ＰＩＦ）部
５２  ホストインタフェース（ＨＩＦ）部
５３  排他制御処理部
５４  ＨＷリカバリ処理部
５５  ＳＷリカバリ処理部
５６  動作モード記憶部
５７  インデックステーブル
ｔ、ｔ１〜ｔ３  排他制御テーブル
ｔｓ  自排他制御テーブル
ｔｐ  対排他制御テーブル
ｒ  排他制御情報
【図１】
0003636163.tif 000002
【図２】
0003636163.tif 000003
【図３】
0003636163.tif 000004
【図４】
0003636163.tif 000005
【図５】
0003636163.tif 000006
【図６】
0003636163.tif 000007
【図７】
0003636163.tif 000008
【図８】
0003636163.tif 000009
【図９】
0003636163.tif 000010
【図１０】
0003636163.tif 000011
【図１１】
0003636163.tif 000012
【図１２】
0003636163.tif 000013
【図１３】
0003636163.tif 000014
【図１４】
0003636163.tif 000015
【図１５】
0003636163.tif 000016
【図１６】
0003636163.tif 000017
【図１７】
0003636163.tif 000018
【図１８】
0003636163.tif 000019
【図１９】
0003636163.tif 000020
【図２０】
0003636163.tif 000021