JP4924574B2 - ストレージ装置の制御部及び制御方法 - Google Patents

Description

ハードディスク記憶装置等のストレージ装置が例えばＲＡＩＤ構成下での動作のように連携して動作する場合における、ストレージ装置の各記憶媒体モジュールのデータの読出し処理／書込み処理を制御する各コントローラモジュール間の同期制御技術に関する。

ストレージ装置が例えばＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）を構成する場合、ストレージ装置を構成する各記憶媒体モジュールにおいて、外部からの処理命令に従って記憶媒体モジュールに対する読出し処理／書込み処理を制御するコントローラモジュール（Ｃｏｎｔｒｏｌｌｅｒ Ｍｏｄｕｌｅ：以降、「ＣＭ」という）には、マスタ／スレーブという役割が与えられる。

ここで、ユーザや保守作業者が操作するＧＵＩ（グラフィカルユーザインタフェース）保守ツール等の上位ツールからのコマンド（設定変更や状態取得、及び保守に関する制御）は、操作端末からＬＡＮ（ローカルエリアネットワーク）経由で、ストレージ装置に対して送受信される。

この場合に従来は、上記コマンド制御は、スレーブの設定がされているＣＭ（スレーブＣＭ）では許可されず、マスタの設定がされているＣＭ（マスタＣＭ）でのみ許可され、マスタＣＭ主導で制御が行われていた。そして、コマンド実行中にマスタＣＭがダウンした場合に後処理を必要とするコマンド以外は、全てマスタＣＭで制御されているため、スレーブＣＭ側ではマスタＣＭの機能処理状態は把握できないようになっていた。

このようにマスタＣＭ主導で制御が行われる理由は、以下のとおりである。
１．ＧＵＩ保守画面はＷｅｂブラウザを介して提供されることが多いが、ブラウザ接続ができなくなる緊急時以外は、マスタＣＭからスレーブＣＭに手動で切替えを行う必要性があまりないこと。

２．マスタＣＭからスレーブＣＭに自動で切替えを行う必要性は、マスタＣＭがダウンした場合又はＬＡＮポートが故障した場合に限られること。

３．保守コマンドの処理中にマスタＣＭのダウンが発生した場合は、新たにＬＡＮ接続された新マスタＣＭ側で保守コマンドを実行すれば問題ないケースがほとんどであること。

４．マスタＣＭのみがＬＡＮポートに接続され、スレーブＣＭはＬＡＮポートに接続されず、アクセスできないようになっている場合が一般的であったこと。

５．設定権限を持つユーザが同時に複数ログインする必要性はなかったこと。
上記の理由により、従来は、マスタＣＭ主導で処理を制御する実装で問題はなかった。

しかし、ネット接続をはじめとするストレージ装置への接続形態の多様化に伴い、設定権限を持つ複数のユーザに対して同時ログインを許可し、かつスレーブＣＭでも保守コマンドを許可させたいという要請がでてきている。また、手動で容易にマスタＣＭの切替えを許可させたいというケースもでてきた。

このような場合、従来のストレージ装置においては、複数のユーザが同時にマスタＣＭとスレーブＣＭにログインして処理を実行し、また、処理の実行中にマスタＣＭの切替えが行われることを想定していないため、次のような弊害が生じることが考えられる。

１．ＣＭ間でそれぞれどの機能が実行中か相互に把握できていないため、ＧＵＩからのコマンドを契機として動作する処理は、続き処理が全く行えない。

２．スレーブＣＭやマスタＣＭの切替え後の新マスタＣＭにてコマンドが実行されると、ストレージ装置内で同じ処理が２重に実行される可能性があり、ストレージ装置が誤動作する可能性がある。

３．各コマンドでのガードを強化する場合は、自ＣＭだけでなく他ＣＭと通信して問合せを行う必要があり、無駄な通信が発生する。

図１１は、従来技術において、マスタＣＭのみＬＡＮがアクティブ（Ａｃｔｉｖｅ）である場合のケースを示す。通常時は、図１１（ａ）（正常時）に示されるように、操作端末＃０と操作端末＃１からマスタＣＭへアクセスすることができる。しかし、図１１（ｂ）（経路異常時）のようにネットワークの一部が故障してしまうと、ストレージ装置側で、従来技術では、ネットワーク異常検出によるマスタＣＭ切り替え機構がなかったり、ネットワーク障害自体を検出できなかったりするため、マスタＣＭを切り替えることがでない。このため、操作端末＃０、＃１の両方からアクセスできない状態に陥ってしまうという問題点を有していた。

本発明の課題は、どのようなケースにおいても、複数のＣＭが常に矛盾無く処理動作及びマスタ切替え動作を実行できるようにすることにある。
第１の態様は、記憶媒体に記憶されるデータの書込み／読出し制御を行うストレージ装置の制御部（１０１）又はこれと同等の機能を実現する制御方法を前提とする。

実行指示受付部（１０３）は、管理端末からの実行指示を受け付ける。
記憶部（Ｆｕｎｃｔｉｏｎ管理テーブル）は、受け付けた実行指示の内容を記憶する。この記憶部は、実行指示を受信した制御部の識別情報と実行指示の更新時刻と実行指示の更新状況とを更に記憶するように構成することができる。

記憶内容通知部（１０５、１０６）は、記憶部に記憶した内容をストレージ装置内の他の制御部に通知する。この記憶内容通知部は例えば、他の制御部の起動を認識すると記憶部に記憶した内容を起動した他の制御部に通知するように構成することができる。

処理部（１０３）は、実行指示に基づいて処理を行う。
上述の第１の態様において、定期的に制御部内で実行されている処理を確認し、処理の
実行状況に基づいて記憶部に記憶される指示内容を更新する指示内容更新部（１０４、１０５、１０８）を更に含むように構成することができる。この指示内容更新部は例えば、記憶部に記憶される更新時刻と更新状況に基づいて実行指示を削除する。また、この指示内容更新部は例えば、記憶部に既に指示内容が記憶されている場合に記憶部の更新処理を行う。

第２の態様は、１以上の記憶媒体と、その記憶媒体に記憶されるデータの書込み／読出し制御を行う複数の制御部とを備えたストレージ装置を前提とする。
複数の制御部のうち第１の制御部は、管理端末からの実行指示を受け付ける第１の実行指示受付部（１０３）と、受け付けた実行指示の内容を記憶する記憶部（Ｆｕｎｃｔｉｏｎ管理テーブル）と、記憶部に記憶した内容をストレージ装置内の他の制御部に通知する記憶内容通知部（１０５、１０６）と、実行指示に基づいて処理を行う処理部（１０３）とを含む。

複数の制御部のうち第２の制御部は、管理端末もしくは他の管理端末からの実行指示を受け付ける第２の実行指示受付部（１０３）と、第１の制御部から記憶部の内容を受信する記憶内容受信部（１０７）と、第１の制御部からの受信結果に基づいて第２の実行指示受付部で受け付けた実行指示の実行可否を判断する実行可否判断部（１０５）とを含む。

ストレージ装置における複数の制御部のどれがマスタであるかということを特に意識することなく、いずれの制御部においても処理を実行することが可能となる。
複数の制御部が記憶部（Ｆｕｎｃｔｉｏｎ管理テーブル）を同期させながら処理を実行することにより、各管理端末から各制御部を、各制御部間での処理矛盾無く制御することが可能となる。

以下、図面を参照しながら、最良の実施形態について詳細に説明する。
従来のストレージ装置において、ほとんどのコマンド処理は、処理中にマスタＣＭの切替えが行われることを想定していない。このため、例えばＧＵＩからの進捗の刈取り（問合せ）のコマンドを期待している処理は、リソース解放やサスペンド機能のリジュームが行われない状態に陥っていた。また、新マスタＣＭでコマンドが起動されると、装置内で対象機能が２重に動作する可能性があり、誤動作する可能性があった。

この問題を解決するために、以下に説明する実施形態では、各ＣＭが、どの機能がどのＣＭ１０１でどれだけの期間動作中なのかを示すエントリ情報を登録したＦｕｎｃｔｉｏｎ管理テーブルを保持し、各ＣＭ間でＦｕｎｃｔｉｏｎ管理テーブルの登録内容を相互に通信して同期させながら制御を行う。

図１は、実施形態の構成図である。
基本構成として、ストレージ装置を構成する記憶媒体モジュール毎に、コントローラモジュール（ＣＭ）１０１（以降「ＣＭ１０１」という）が装備され、各ＣＭ１０１は、ＬＡＮ（ローカルエリアネットワーク）等のネットワークを介して接続される端末装置上で動作するＧＵＩ（グラフィカルユーザインタフェース）画面１０２（以降「ＧＵＩ１０２」という）からアクセス可能である。

本実施形態では、各ＣＭ１０１には、ＬＡＮポートが装備されており、それぞれＧＵＩ１０２からアクセス可能な構成が採られる。
図１では、以降の説明を簡単にするために、互いに連携して動作する＃０と＃１の２台のコントローラモジュールのみが記載されており、通常動作時には、＃０のＣＭ１０１が
マスタＣＭ１０１、＃１のＣＭ１０１がスレーブＣＭとして動作しているものとして記載されているが、実際には、複数のＣＭ１０１が連携している。図１において、ＣＭ１０１（＃０）はＧＵＩ１０２（＃０）からアクセスされ、ＣＭ１０１（＃１）はＧＵＩ１０２（＃１）からアクセスされる。

ＣＭ１０１は、Ｆｕｎｃｔｉｏｎ処理部１０３、動作中機能チェック部１０４、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ情報配信部１０６、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ情報受信部１０７、及びＦｕｎｃｔｉｏｎ管理テーブル監視タイマ部１０８を有する。

Ｆｕｎｃｔｉｏｎ処理部１０３は、ＧＵＩ１０２から制御対象となるコマンド（以降「対象コマンド」という）を受信し、その対象コマンドに対応する処理を実行する。このとき、マスタＣＭとなったＣＭ１０１のＦｕｎｃｔｉｏｎ処理部１０３が対象コマンドを受信した場合、自ＣＭに対応する記憶媒体モジュール以外の記憶媒体モジュールに対する読出し処理／書込み処理（設定変更や状態取得、及び保守に関する処理）が必要になった場合には、当該Ｆｕｎｃｔｉｏｎ処理部１０３は、対象となる他のＣＭ１０１（以降「制御ＣＭ」という）に内部的に読出し処理／書込み処理の制御コマンドを発行して、その制御ＣＭに読出し処理／書込み処理を代行させ、併せて両ＣＭ間で必要なデータ転送を実行する。この動作については、図１０及び図１１の説明において後述する。

動作中機能チェック部１０４は、Ｆｕｎｃｔｉｏｎ処理部１０３が、上記対象コマンドの実行開始してＧＵＩ１０２に実行開始の応答を返したタイミングで、自ＣＭにて上記対象コマンドに対応する機能が他に動作中であるか否かをチェックする。

また、自ＣＭが保持するＦｕｎｃｔｉｏｎ管理テーブルに何れかのエントリ情報が登録されている間、Ｆｕｎｃｔｉｏｎ管理テーブル監視タイマ部１０８が監視タイマを動作させており、これに対して、動作中機能チェック部１０４は、この監視タイマによって計時される一定時間毎に、Ｆｕｎｃｔｉｏｎ管理テーブルに登録されている各エントリ情報に対応する各機能が、自ＣＭにおいて継続動作中であるか否かをチェックする。

一方、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ情報受信部１０７は、他ＣＭ１０１から、Ｆｕｎｃｔｉｏｎ管理テーブル中の何れかのエントリ情報の追加／更新依頼を受信する。

Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、動作中機能チェック部１０４によってチェックされた自ＣＭでの各機能の実行状態の検出結果と、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ情報受信部１０７にて受信されたエントリ情報の追加／更新依頼に基づいて認識される他ＣＭでの各機能の実行状態の通知結果とに基づいて、Ｆｕｎｃｔｉｏｎ管理テーブルに対してエントリ情報の追加、更新、変更、又は削除の処理を実行することにより、各ＣＭ１０１が保持する各Ｆｕｎｃｔｉｏｎ管理テーブルの登録内容が常に同期するように制御する。

また、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５がＦｕｎｃｔｉｏｎ管理テーブルに対して自ＣＭでの機能の実行状態に対応するエントリ情報の追加、更新、変更、又は削除を行ってその登録内容に変化が発生した場合には、当該変化のあったエントリ情報の追加／更新依頼を、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ情報配信部１０６を介して他のＣＭ１０１へ配信する。

図２は、ＣＭ１０１が保持するＦｕｎｃｔｉｏｎ管理テーブルのデータ構成図である。Ｆｕｎｃｔｉｏｎ管理テーブルは、図１のＦｕｎｃｔｉｏｎ処理部１０３が実行する機能
単位で登録され、1つのエントリには、実行中の機能を示す「機能値」、当該機能が実際に動作しているＣＭ１０１のモジュールＩＤ「制御ＣＭ ＭＩＤ」、当該エントリが更新された時間を示す「更新Ｔｉｍｅ Ｓｔａｍｐ」、及び当該エントリを更新できなかった回数を示す「未更新回数」の各フィールド値が登録される。

なお、「制御ＣＭ ＭＩＤ」フィールドには、それが含まれるエントリ情報に登録されている「機能値」が示す機能が、それに対応する対象コマンドをＧＵＩ１０２から受信したマスタＣＭにおいて実行される場合には、当該マスタＣＭの識別ＩＤが登録されるが、上記機能が上記マスタＣＭからの指示に基づいて他の制御ＣＭにおいて実行される場合には、当該制御ＣＭの識別ＩＤが登録される。ここでは、マスタＣＭ＝制御ＣＭとなる場合も含めて、上記フィールド名を「制御ＣＭ ＭＩＤ」と定義する。

図３は、図１に示されるＦｕｎｃｔｉｏｎ管理テーブル操作部１０５が、図２に示されるデータ構成を有するＦｕｎｃｔｉｏｎ管理テーブルを使ってＣＭ間同期制御動作を実行する際の、動作アルゴリズムを示す制御マトリックス図である。

図３において、「入力」で示される縦の２列は、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、動作中機能チェック部１０４又はＦｕｎｃｔｉｏｎ管理テーブルエントリ情報受信部１０７を介して認識する制御対象の機能（以降「対象機能」という）が「機能実行中」又は「機能未実行」の何れの状態であるかという場合分けと、その対象機能の入力元のＣＭ１０１がどれであるかという場合分けを示している。

また、「Ｆｕｎｃｔｉｏｎ管理テーブル上のエントリ情報」で示される縦の４列は、「機能値」フィールド（図２参照）に上記対象機能に対応する機能値が含まれるエントリ情報が登録されているか（「有（Ｖａｌｉｄ）」）、登録されていないか（無「ＩｎＶａｌｉｄ」）の場合分けと、登録されている場合に、そのエントリ情報内の「制御ＣＭ ＭＩＤ」フィールドに登録されているＣＭ１０１がどれであるかの場合分け（図３の例では「自ＣＭ」「他ＣＭ１」「他ＣＭ２」の３つ）を示している。

そして、図３の各行と各列によって決まる１〜２４のマス内には、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５がＦｕｎｃｔｉｏｎ管理テーブルに対してどのような操作を実行すべきかという場合分けが記載されている。

Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、図３の制御マトリックスに対応する制御プログラムを実行することになる。図３の制御マトリクスに基づくＦｕｎｃｔｉｏｎ管理テーブル操作部１０５の動作について、以下に説明する。

まず、図１のＦｕｎｃｔｉｏｎ処理部１０３がＧＵＩ１０２から対象コマンドを受信して実行を開始し、動作中機能チェック部１０４が、「自ＣＭ」にて上記対象コマンドに対応する対象機能が実行されていることを検出した場合（以降「ケース１」という）において、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、Ｆｕｎｃｔｉｏｎ管理テーブルのエントリ情報を検索した結果、上記対象機能に対応するエントリ情報が無かった場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、「制御ＣＭ ＭＩＤ」フィールドに自ＣＭのＩＤがセットされ、「機能値」フィールドに上記対象機能に対応する値がセットされたエントリ情報を追加する。なお、「更新Ｔｉｍｅ Ｓｔａｍｐ」フィールドには現在の時刻がセットされ、「未更新回数」フィールドには０がセットされる。また、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ情報配信部１０６を介して、当該エントリ情報の追加依頼を他のＣＭ１０１に配信する（以上、図３の４番のマス）。これは、対象機能が自ＣＭにおいて新たに実行を開始した状態である。

次に、動作中機能チェック部１０４が、Ｆｕｎｃｔｉｏｎ管理テーブル監視タイマ部１０８の監視タイマによって計時される一定時間毎に、Ｆｕｎｃｔｉｏｎ管理テーブルに登録されている各エントリ情報に対応する各機能が自ＣＭにおいて継続動作中であるか否かをチェックした結果（これを「ケース２」という）、Ｆｕｎｃｔｉｏｎ管理テーブルから抽出された「制御ＣＭ ＭＩＤ」フィールドに自ＣＭのＩＤが含まれるエントリ情報が自ＣＭで継続して実行中であると判定した場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報の「更新Ｔｉｍｅ Ｓｔａｍｐ」フィールドに現在の時刻をセットし、「未更新回数」フィールドに０を再セットして、そのエントリ情報を更新する。また、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ情報配信部１０６を介して、当該エントリ情報の更新依頼を他のＣＭ１０１に配信する（以上、図３の１番のマス）。これは、自ＣＭが、対象機能の動作を継続中の状態である。

次にケース１において、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、Ｆｕｎｃｔｉｏｎ管理テーブルのエントリ情報を検索した結果、上記対象機能に対応した「制御ＣＭ ＭＩＤ」フィールドに他ＣＭ（他ＣＭ１又は他ＣＭ２）のＩＤが含まれるエントリ情報が見つかった場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報の「制御ＣＭ ＭＩＤ」フィールドに自ＣＭのＩＤをセットし、「更新Ｔｉｍｅ Ｓｔａｍｐ」フィールドに現在の時刻をセットし、「未更新回数」フィールドに０を再セットして、そのエントリ情報を変更する。また、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ情報配信部１０６を介して、当該エントリ情報の変更依頼を他のＣＭ１０１に配信する（以上、図３の２番又は３番のマス）。これは例えば、対象機能を実行していた他ＣＭがダウンし、代わりに自ＣＭが対象機能の実行を開始したような状態である。

次に、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ情報受信部１０７が他ＣＭ（他ＣＭ１又は他ＣＭ２）からエントリ情報の追加／更新依頼を受信し、その結果、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、そのエントリ情報の「機能値」フィールドで特定される対象機能が他ＣＭ（他ＣＭ１又は他ＣＭ２）で実行中であることを検出した場合（以降「ケース３」という）において、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、Ｆｕｎｃｔｉｏｎ管理テーブルのエントリ情報を検索した結果、上記対象機能に対応するエントリ情報が無かった場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、「制御ＣＭ ＭＩＤ」フィールドに当該他ＣＭ（他ＣＭ１又は他ＣＭ２）のＩＤがセットされ、「機能値」フィールドに上記対象機能に対応する値がセットされたエントリ情報を追加する。なお、「更新Ｔｉｍｅ Ｓｔａｍｐ」フィールドには現在の時刻がセットされ、「未更新回数」フィールドには０がセットされる（以上、図３の８番又は１２番のマス）。これは、対象機能が他ＣＭにおいて新たに実行を開始した状態である。

次にケース３において、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、Ｆｕｎｃｔｉｏｎ管理テーブルのエントリ情報を検索した結果、上記対象機能に対応し「制御ＣＭ ＭＩＤ」フィールドに自ＣＭのＩＤが含まれるエントリ情報が見つかった場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報は変更しない（以上、図３の５番又は９番のマス）。これは、他ＣＭにおいて対象機能の実行が開始されても、自ＣＭにおいて対象機能が実行されていればその状態を優先する制御である。

次にケース３において、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、Ｆｕｎｃｔｉｏｎ管理テーブルのエントリ情報を検索した結果、上記対象機能に対応し「制御ＣＭ ＭＩＤ」フィールドに上記通知された対象機能に対応する他ＣＭと同じ他ＣＭのＩＤが含まれるエントリ情報が見つかった場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報の「更新Ｔｉｍｅ Ｓｔａｍｐ」フィールドに現在の時刻をセットし、「
未更新回数」フィールドに０を再セットして、そのエントリ情報を更新する（以上、図３の６番又は１１番のマス）。これは、前述した図３の１番のマスの制御動作により、他ＣＭにおける一定間隔毎の動作チェックによりその継続実行されている機能に対応するエントリ情報が当該ＣＭにて更新され、その更新情報が自ＣＭに配信されてきたときに、自ＣＭでのエントリ情報を当該他ＣＭでのエントリ情報の更新に同期させる処理である。

このように通常は、制御ＣＭにて或る機能が実行継続中である場合、一定間隔で他ＣＭへその機能に対応するエントリ情報の更新依頼が配信される。他ＣＭはこの情報を受信すると、自ＣＭ内のＦｕｎｃｔｉｏｎ管理テーブル上の該当するエントリ情報の「更新Ｔｉｍｅ Ｓｔａｍｐ」フィールドの時刻値を更新し、「未更新回数」フィールドの値を０にリセットする。一方、動作中機能チェック部１０４は、Ｆｕｎｃｔｉｏｎ管理テーブル監視タイマ部１０８の監視タイマによって計時される一定間隔で、Ｆｕｎｃｔｉｏｎ管理テーブルに登録されているエントリ情報のうち、「制御ＣＭ ＭＩＤ」フィールドに自ＣＭのＩＤ以外のＩＤが含まれるエントリ情報の「未更新回数」フィールドの値をカウントアップする。従って、他ＣＭが正常に動作している間は、「未更新回数」フィールドの値は一定間隔でリセットされるためその値が増加することはないが、他ＣＭの動作が異常となった場合には、「未更新回数」フィールドの値はリセットされなくなるためその値が増加してゆく。そこで、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、後述する図３の７番、１０番、１４番、１５番、１９番、及び２２番の制御動作において、「更新Ｔｉｍｅ Ｓｔａｍｐ」フィールドの時刻値と併せて「未更新回数」フィールドの値を判定することにより、他ＣＭの異常検出を行うことができる。

なお、付加情報として、Ｆｕｎｃｔｉｏｎ管理テーブル内のエントリ情報に機能の進捗率を載せるようにすれば、エントリ情報の定期的配信は行われているが機能の処理が進んでいないという状態が検出されることによっても、制御ＣＭの機能異常として何らかの処置を行うことができる。

次にケース３において、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、Ｆｕｎｃｔｉｏｎ管理テーブルのエントリ情報を検索した結果、上記対象機能に対応し「制御ＣＭ ＭＩＤ」フィールドに上記通知された対象機能に対応する他ＣＭとは異なる他ＣＭのＩＤが含まれるエントリ情報が見つかった場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報は更新しない。あるいは、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報の「更新Ｔｉｍｅ Ｓｔａｍｐ」が所定時間以上古く、「未更新回数」が所定回数以上になっていた場合に、当該エントリ情報に対応する他ＣＭがダウンし新たに通知された他ＣＭに切り替わったと判断して、そのエントリ情報の「制御ＣＭ ＭＩＤ」フィールドに上記通知された対象機能に対応する他ＣＭのＩＤをセットし、「更新Ｔｉｍｅ Ｓｔａｍｐ」フィールドに現在の時刻をセットし、「未更新回数」フィールドに０を再セットして、そのエントリ情報を変更する（以上、図３の７番又は１０番のマス）。

続いて、動作中機能チェック部１０４が、この監視タイマによって計時される一定時間毎に、Ｆｕｎｃｔｉｏｎ管理テーブルに登録されている各エントリ情報に対応する各機能が自ＣＭにおいて継続動作中であるか否かをチェックした結果（以降「ケース４」という）、Ｆｕｎｃｔｉｏｎ管理テーブルから抽出された「制御ＣＭ ＭＩＤ」フィールドに自ＣＭのＩＤが含まれるエントリ情報が自ＣＭではもはや実行中ではないと判定した場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報をＦｕｎｃｔｉｏｎ管理テーブルから削除する。また、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ情報配信部１０６を介して、当該エントリ情報の削除依頼を他のＣＭ１０１に配信する（以上、図３の１３番のマス）。これは、自ＣＭが、対象機能の動作を終了した状態である。

次にケース４において、Ｆｕｎｃｔｉｏｎ管理テーブルから抽出された「制御ＣＭ ＭＩＤ」フィールドに他ＣＭ（他ＣＭ１又は他ＣＭ２）のＩＤが含まれるエントリ情報が自ＣＭでは実行中ではないと動作中機能チェック部１０４が判定した場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報は変更しない。あるいは、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報の「更新Ｔｉｍｅ Ｓｔａｍｐ」が所定時間以上古く、「未更新回数」が所定回数以上になっていた場合に、当該エントリ情報に対応する他ＣＭがダウン等したと判断して、そのエントリ情報をＦｕｎｃｔｉｏｎ管理テーブルから削除する（以上、図３の１４番又は１５番のマス）。

次に、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ情報受信部１０７が他ＣＭ（他ＣＭ１又は他ＣＭ２）からエントリ情報の削除依頼を受信し、その結果、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、そのエントリ情報の「機能値」フィールドで特定される対象機能が他ＣＭ（他ＣＭ１又は他ＣＭ２）で実行されなくなったことを検出した場合（以降「ケース５」という）において、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、Ｆｕｎｃｔｉｏｎ管理テーブルのエントリ情報を検索した結果、上記対象機能に対応するエントリ情報が無かった場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、Ｆｕｎｃｔｉｏｎ管理テーブルの登録内容は変更しない（以上、図３の２０番又は２４番のマス）。

次にケース５において、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、Ｆｕｎｃｔｉｏｎ管理テーブルのエントリ情報を検索した結果、上記対象機能に対応し「制御ＣＭ ＭＩＤ」フィールドに自ＣＭのＩＤが含まれるエントリ情報が見つかった場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報は変更しない（以上、図３の１７番又は２１番のマス）。これは、他ＣＭにおいて対象機能の実行が終了しても、自ＣＭにおいて対象機能が実行されていればその状態を優先する制御である。

次にケース５において、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、Ｆｕｎｃｔｉｏｎ管理テーブルのエントリ情報を検索した結果、上記対象機能に対応し「制御ＣＭ ＭＩＤ」フィールドに上記通知された対象機能に対応する他ＣＭと同じ他ＣＭのＩＤが含まれるエントリ情報が見つかった場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報をＦｕｎｃｔｉｏｎ管理テーブルから削除する（以上、図３の１８番又は２３番のマス）。これは、自ＣＭでのエントリ情報を他ＣＭでのエントリ情報の削除に同期させる処理である。

次にケース５において、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５が、Ｆｕｎｃｔｉｏｎ管理テーブルのエントリ情報を検索した結果、上記対象機能に対応し「制御ＣＭ ＭＩＤ」フィールドに上記通知された対象機能に対応する他ＣＭとは異なる他ＣＭのＩＤが含まれるエントリ情報が見つかった場合、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報は更新しない。あるいは、Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５は、そのエントリ情報の「更新Ｔｉｍｅ Ｓｔａｍｐ」が所定時間以上古く、「未更新回数」が所定回数以上になっていた場合に、当該エントリ情報に対応する他ＣＭがダウンしたと判断して、そのエントリ情報をＦｕｎｃｔｉｏｎ管理テーブルから削除する（以上、図３の１９番又は２２番のマス）。

以上、図３の制御マトリクスに基づいて、図１のＦｕｎｃｔｉｏｎ管理テーブル操作部１０５の詳細動作について説明したが、主な動作をまとめると以下のようになる。
Ｆｕｎｃｔｉｏｎ管理テーブルに対するエントリ情報の追加／更新
Ｆｕｎｃｔｉｏｎ管理テーブルへのエントリ情報の追加及び更新のタイミングは、以下の通りである。
・自ＣＭがＧＵＩから特定のコマンドを受信後、自ＣＭ上での動作中機能チェックの結果、特定の機能が動作中と判断された場合。
・Ｆｕｎｃｔｉｏｎ管理テーブルにエントリ情報が存在する際に、定期的に自ＣＭ上での動作中機能チェックを行い、特定の機能が動作中と判断された場合。
・他ＣＭから自ＣＭのＦｕｎｃｔｉｏｎ管理テーブルへのエントリ情報の追加／更新依頼を受けた場合。
・自ＣＭのモジュール再起動中に、他ＣＭからエントリ情報を採取した場合。これについては、図３の制御マトリクスには含まれていないが、自ＣＭから他ＣＭの情報を自立的に採取するような構成を採ることも可能である。

Ｆｕｎｃｔｉｏｎ管理テーブルからのエントリ情報の削除
Ｆｕｎｃｔｉｏｎ管理テーブルからのエントリ情報の削除のタイミングは以下の通りである。
・自ＣＭがＧＵＩから特定のコマンドを受信後、自ＣＭ上での動作中機能チェックの結果、特定の機能が動作中でないと判断された場合。
・自ＣＭのＦｕｎｃｔｉｏｎ管理テーブルにエントリ情報が存在する際に、自ＣＭ上での定期的な動作中機能チェックの結果、特定の機能が動作中でないと判断された場合。
・自ＣＭのＦｕｎｃｔｉｏｎ管理テーブルに他ＣＭから受信したエントリ情報が存在する際に、定期的なＦｕｎｃｔｉｏｎ管理テーブルのチェックの結果、エントリ情報の「更新Ｔｉｍｅ Ｓｔａｍｐ」フィールドの値と「未更新回数」フィールドの値とから、制御ＣＭからエントリ情報の更新依頼が一定時間、一定回数以上受信されていないと判断された場合。もしくは、制御ＣＭがデグレード（故障）したと判断された場合。
・他ＣＭから自ＣＭのＦｕｎｃｔｉｏｎ管理テーブルへのエントリ情報の削除依頼を受けた場合。

図４及び図５は、図１の本実施形態の構成に基づく動作シーケンス例を示す図である。ここでは、始めに端末＃０（図１のＧＵＩ１０２（＃０）が動作する端末）からの指示に基づいて、ＣＭ１０１（＃０）（図４及び図５中ではＣＭ＃０と表記）が機能Ａの処理を実行し、その実行途中で、保守制御が端末＃０から端末＃１（図１のＧＵＩ１０２（＃１）が動作する端末）に切り替わり、端末＃１は、ＣＭ１０１（＃０）での機能Ａの処理の終了を待って、ＣＭ１０１（＃１）（図４及び図５ではＣＭ＃１と表記）が機能Ａの処理を実行するようなケースが示されている。

従来は、このような連携処理は不可能であったが、本実施形態では、ＣＭ１０１（＃０）とＣＭ１０１（＃１）のどちらがマスタＣＭであるかということを特に意識することなく、双方から機能を実行することが可能となる。

まず、図４のＳ４０１で示される一連の処理群では、端末＃０からの指示に基づいて、ＣＭ＃０がＣＭ＃１に確認を取りながら、実行権限を獲得する。ここで、機能Ａは、同時には何れか１つのＣＭ１０１においてのみ排他的に実行可能な処理であるとし、そのために実行権限の獲得が必要となる。なお、実行権限処理部は、図１のＦｕｎｃｔｉｏｎ処理部１０３が実現する。

次に、図４のステップＳ４０２で示される一連の処理群では、端末＃０からの機能Ａの実行指示に基づいて、ＣＭ＃０が機能Ａの実行を開始し、このときに、ＣＭ＃０とＣＭ＃１は、図１〜図３を用いて前述した動作によって、Ｆｕｎｃｔｉｏｎ管理テーブルを同期させる処理を実行する。Ｓ４０２において、機能Ａコマンド処理部は、図１のＦｕｎｃｔｉｏｎ処理部１０３が実現し、Ｆｕｎｃｔｉｏｎ管理テーブルエントリ処理部は、図１の
１０３から１０８の各部が実現する。この結果、ＣＭ＃０とＣＭ＃１のいずれにおいても、機能Ａが現在どこで実行されているかを把握することができる。即ち、ＣＭ＃０のＦｕｎｃｔｉｏｎ管理テーブルにおける機能Ａのエントリ情報は、機能Ａが自ＣＭで実行中であることを示し、ＣＭ＃１のＦｕｎｃｔｉｏｎ管理テーブルにおける機能Ａのエントリ情報は、機能Ａが他ＣＭ（＝ＣＭ＃０）で実行中であることを示す。

次に、図４のステップＳ４０３で示される一連の処理群では、端末＃０からの機能Ａの進捗確認指示に基づいて、ＣＭ＃０の機能Ａコマンド処理部が、自ＣＭ内のＦｕｎｃｔｉｏｎ管理テーブルの機能Ａのエントリ情報を確認することにより、端末＃０に機能Ａの進捗情報を返す。

次に、図４のステップＳ４０４で示される一連の処理群では、端末＃０が、ＣＭ＃０における機能Ａの処理の終了を待たずに、機能Ａの処理に関する実行権限を解放する。
続いて、図４のステップＳ４０５で示される一連の処理群では、端末＃１が、機能Ａの処理に関する実行権限を獲得する。

次に、図４のステップＳ４０６で示される一連の処理群では、端末＃１が、ＣＭ＃１における機能Ａの処理の実行を試みる。これに対して、ＣＭ＃１のＦｕｎｃｔｉｏｎ処理部（図１の１０３）は、自ＣＭ内のＦｕｎｃｔｉｏｎ管理テーブルの機能Ａのエントリ情報を確認することにより、機能ＡがまだＣＭ＃０において実行中であってＣＭ＃１では実行開始できないことを返す。

次に、図４のステップＳ４０７で示される一連の処理群では、端末＃１からの機能Ａの進捗確認指示に基づいて、ＣＭ＃１のＦｕｎｃｔｉｏｎ処理部が、自ＣＭ内のＦｕｎｃｔｉｏｎ管理テーブルにおいて機能ＡがＣＭ＃０で実行であることを示すエントリ情報を確認することにより、ＣＭ＃０のＦｕｎｃｔｉｏｎ処理部に機能Ａの進捗確認を問合せ、この結果、ＣＭ＃０の機能Ａコマンド処理部が、ＣＭ＃１のＦｕｎｃｔｉｏｎ処理部に機能Ａの進捗を返し、ＣＭ＃１のＦｕｎｃｔｉｏｎ処理部が端末＃１にその機能Ａの進捗を通知する。

次に、図５のステップＳ４０８で示される一連の処理群では、端末＃０からＣＭ＃０に発行されていた機能Ａコマンド処理が終了し、ＣＭ＃０とＣＭ＃１の双方のＦｕｎｃｔｉｏｎ管理テーブルにおいて、図１〜図３を用いて前述した動作によって、機能Ａのエントリ情報を同期して削除する処理が実行される。

その後、図５のステップＳ４０９で示される一連の処理群では、端末＃１があらためてＣＭ＃１における機能Ａの実行指示を出すことによりＣＭ＃１が機能Ａの実行を開始し、このときに、ＣＭ＃１とＣＭ＃０は、図１〜図３を用いて前述した動作によって、Ｆｕｎｃｔｉｏｎ管理テーブルを同期させる処理を実行する。この結果、ＣＭ＃１のＦｕｎｃｔｉｏｎ管理テーブルにおける機能Ａのエントリ情報は、機能Ａが自ＣＭで実行中であることを示し、ＣＭ＃０のＦｕｎｃｔｉｏｎ管理テーブルにおける機能Ａのエントリ情報は、機能Ａが他ＣＭ（＝ＣＭ＃１）で実行中であることを示すことになり、双方のＦｕｎｃｔｉｏｎ管理テーブルが同期する。

以上のようにして、本実施形態では、複数のＣＭ１０１がＦｕｎｃｔｉｏｎ管理テーブルを同期させながら機能処理を実行することにより、各端末のＧＵＩから各ＣＭを、各ＣＭ間での処理矛盾無く制御することが可能となる。

図６は、従来技術と対比した本実施形態の動作説明図である。
従来は、図１１（ｂ）（経路異常時）の説明において前述したように、ネットワークの
一部が故障してしまうと、ストレージ装置側で、マスタＣＭを切り替えることができなかったため、操作端末＃０、＃１の両方からアクセスできない状態に陥ってしまうという問題点を有していた。

これに対して、従来技術の発展形として、図６（ａ）に示されるように、ＣＭ＃０（マスタ）とＣＭ＃１（スレーブ）の両方のＬＡＮポートをアクティブ（Ａｃｔｉｖｅ）にする技術が考えられる。この結果、図６（ａ）に示されるように、端末＃０はマスタであるＣＭ＃０にアクセスでき、端末＃１はスレーブであるＣＭ＃１にアクセスできることになる。また、両ＣＭのＬＡＮがアクティブにされることで、通常時は表示系の処理はスレーブのＣＭ＃１で行わせ、設定系の処理はマスタのＣＭ＃０で行わせるといった運用も可能である。

しかし、これだけでは、マスタのＣＭ＃０／スレーブのＣＭ＃１に関係なく、アクセスしたＣＭで処理を行わせたい場合に、ＣＭ間の排他制御が問題になる。図６（ａ）の場合には、Ｆｕｎｃｔｉｏｎ管理部がないためＣＭ間の排他制御を行うことができないが、図６（ｂ）に示される本実施形態の構成では、図１の１０３〜１０８によって実現されるＦｕｎｃｔｉｏｎ管理部により、制御ＣＭへコマンドを送信することや、排他条件が満たされる場合には自ＣＭで機能を処理させるといった判断を行うことができる。また、図６（ｂ）に示されるＦｕｎｃｔｉｏｎ管理部は、両ＣＭのＬＡＮがアクティブであるケースだけではなく、マスタＣＭのみのＬＡＮがアクティブな場合でも、ある機能が実行中の際に、マスタＣＭの切替えが発生した際にも有効となる。

図７は、図４に示される動作シーケンス例における２重実行防止機能を説明するための動作シーケンス例を示す図である。基本的には、図７は図４と同じ図である。
図４のステップＳ４０６でも説明したように、図７のステップＳ７０１で示される一連の処理群において、端末＃１が、ＣＭ＃１における機能Ａの処理の実行を試みる。これに対して、ＣＭ＃１のＦｕｎｃｔｉｏｎ処理部（図１の１０３）は、自ＣＭ内のＦｕｎｃｔｉｏｎ管理テーブルの機能Ａのエントリ情報を確認することにより、機能ＡがまだＣＭ＃０において実行中であってＣＭ＃１では実行不可の応答を返すことができる。ここでのガード機能は、例えば機能Ａ実行中に機能Bの実行要求が発生した場合において、機能間で排他制御を行うような制御にも有効である。

図８は同じく、図４に示される動作シーケンス例における２重実行防止機能を説明するための別の動作シーケンス例を示す図である。
図８のステップＳ８０１（図４のステップＳ４０６に対応）で示される一連の処理群において、端末＃１が、ＣＭ＃１における機能Ａの処理の実行を試みる。これに対して、ＣＭ＃１のＦｕｎｃｔｉｏｎ処理部は、自ＣＭ内のＦｕｎｃｔｉｏｎ管理テーブルにおいて機能ＡがＣＭ＃０で実行であることを示すエントリ情報を確認することにより、ＣＭ＃０のＦｕｎｃｔｉｏｎ処理部に機能Ａの実行指示を出す。この結果、ＣＭ＃０のＦｕｎｃｔｉｏｎ処理部が機能Ａの擬似実行コマンドを発行するが、ＣＭ＃０の機能Ａコマンド処理部が機能Ａの２重起動を検出し、ＣＭ＃１のＦｕｎｃｔｉｏｎ処理部に機能Ａが実行中であることを示す応答を返し、ＣＭ＃１のＦｕｎｃｔｉｏｎ処理部が端末＃１に機能Ａが実行中であることを応答する。

図９は、ＧＵＩからマスタＣＭに発行された書込みコマンド（ＣＭがＧＵＩからの要求の際に、データを受信する設定変更や保守に関するコマンド）に対して、マスタＣＭとなるＣＭ１０１内のＦｕｎｃｔｉｏｎ処理部１０３（図１参照）が制御ＣＭであるＣＭ１０１内のＦｕｎｃｔｉｏｎ処理部１０３と連携しながら書込み処理を実行する場合の一般的な連携動作を示す動作シーケンス図である。また、図１０は同じく、ＧＵＩからマスタＣＭに発行された読出しコマンド（ＣＭがＧＵＩへの応答の際に、データを送信する状態取得や保守に関するコマンド）に対して、マスタＣＭ内のＦｕｎｃｔｉｏｎ処理部１０３が制御ＣＭ内のＦｕｎｃｔｉｏｎ処理部１０３と連携しながら読出し処理を実行する場合の一般的な連携動作を示す動作シーケンス図である。

以下の説明において、説明を簡単にするために、「マスタＣＭ」又は「制御ＣＭ」と表記した場合は、「マスタＣＭとなるＣＭ１０１内のＦｕｎｃｔｉｏｎ処理部１０３」又は「制御ＣＭとなるＣＭ１０１内のＦｕｎｃｔｉｏｎ処理部１０３」を意味するものとする。

まず、ＧＵＩからマスタＣＭに発行された書込みコマンドに対して、マスタＣＭが制御ＣＭと連携しながら書込み処理を実行する場合の動作について、図９の動作シーケンス図に沿って説明する。

ＧＵＩは、マスタＣＭ内に書込みデータのためのバッファを獲得した後（ステップＳ９０１）、マスタＣＭに対して、書込みコマンド（ＷｒｉｔｅＣｍｄ）を発行する（ステップＳ９０２）。

マスタＣＭは、その書込みコマンドが、制御ＣＭが制御する記憶媒体へのものであると認識すると、制御ＣＭに対して、内部コマンドである書込みコマンド（専用Ｃｍｄ１）を発行する（ステップＳ９０３）。

制御ＣＭは、その内部書込みコマンドを受信すると、まず、自ＣＭ内に書込みデータ用のバッファを獲得し（ステップＳ９０４）、書込みデータの転送を行うための処理であるデータムーバ処理を実行する（ステップＳ９０５）。この結果、制御ＣＭからマスタＣＭに、データムーバ要求（Ｇｅｔ要求）が発行され（ステップＳ９０６）、これに応答してマスタＣＭ内のバッファから制御ＣＭ内のバッファに書込みデータがコピーされ、コピー終了後に、マスタＣＭから制御ＣＭにデータムーバ応答が返される（ステップＳ９０７）。

制御ＣＭは、書込みデータの転送が完了すると、自ＣＭに対して、擬似コマンドである書込みコマンド（ＷｒｉｔｅＣｍｄ）を発行し（ステップＳ９０８）、転送された書込みデータを記憶媒体に書き込み、書込みが完了すると自ＣＭ内のバッファを解放する（ステップＳ９０９）。

最後に、制御ＣＭからマスタＣＭに、前述の内部コマンドである書込みコマンド（専用Ｃｍｄ１）に対する応答が返され（ステップＳ９１０）、これを受けたマスタＣＭからＧＵＩに、当初の書込みコマンド（ＷｒｉｔｅＣｍｄ）に対する応答が返される（ステップＳ９１１）。ＧＵＩは、この応答を受けて、マスタＣＭ内のバッファを解放する（ステップＳ９１２）。

次に、ＧＵＩからマスタＣＭに発行された読出しコマンドに対して、マスタＣＭが制御ＣＭと連携しながら読出し処理を実行する場合の動作について図１０の動作シーケンス図に沿って説明する。

ＧＵＩは、マスタＣＭに対して、読出しコマンド（ＲｅａｄＣｍｄ）を発行する（ステップＳ１００１）。
マスタＣＭは、その読出しコマンドが、制御ＣＭが制御する記憶媒体へのものであると認識すると、制御ＣＭに対して、内部コマンドである読出しコマンド（専用Ｃｍｄ２）を発行する（ステップＳ１００２）。

制御ＣＭは、その内部読出しコマンドを受信すると、まず、自ＣＭに対して、擬似コマンドである読出しコマンド（ＲｅａｄＣｍｄ）を発行し、自ＣＭ内にバッファを獲得してそこに要求されたデータを読み出す（ステップＳ１００３）。

続いて、制御ＣＭはマスタＣＭに対して、内部コマンドである読出しコマンド（専用Ｃｍｄ３）を発行する（ステップＳ１００４）。
マスタＣＭは、このコマンドを受け取ると、自ＣＭ内に読出しデータを受け取るためのバッファを獲得し（ステップＳ１００５）、制御ＣＭに上記コマンドに対する応答を返す（ステップＳ１００６）。

制御ＣＭは、その応答を受信すると、まず、読出しデータの転送を行うための処理であるデータムーバ処理を実行する（ステップＳ１００７）。この結果、制御ＣＭからマスタＣＭに、データムーバ要求（Ｐｕｔ要求）が発行され（ステップＳ１００８）、これに応答して制御ＣＭ内のバッファからマスタＣＭ内のバッファに読出しデータがコピーされ、コピー終了後に、マスタＣＭから制御ＣＭに、データムーバ応答が返される（ステップＳ１００９）。

制御ＣＭは、読出しデータの転送が完了して上記応答を受け取ると、自ＣＭ内のバッファを解放する（ステップＳ１０１０）。
最後に、制御ＣＭからマスタＣＭに、前述の内部コマンドである読出しコマンド（専用Ｃｍｄ２）に対する応答が返され（ステップＳ１０１１）、これを受けたマスタＣＭからＧＵＩに、当初の読出しコマンド（ＲｅａｄＣｍｄ）に対する応答が返される（ステップＳ１０１２）。ＧＵＩは、マスタＣＭ内のバッファからデータをリード後に、そのバッファを解放する（ステップＳ１０１３）。

以上の実施形態に関して、更に以下の付記を開示する。
（付記１）
記憶媒体に記憶されるデータの書込み／読出し制御を行うストレージ装置の制御部であって、
管理端末からの実行指示を受け付ける実行指示受付部と、
前記受け付けた実行指示の内容を記憶する記憶部と、
前記記憶部に記憶した内容を前記ストレージ装置内の他の制御部に通知する記憶内容通知部と、
前記実行指示に基づいて処理を行う処理部と、
を含むことを特徴とするストレージ装置の制御部。
（付記２）
前記記憶部に、前記実行指示を受信した制御部の識別情報と前記実行指示の更新時刻と前記実行指示の更新状況とを更に記憶する、
ことを特徴とする付記１に記載のストレージ装置の制御部。
（付記３）
定期的に前記制御部内で実行されている前記処理を確認し、前記処理の実行状況に基づいて前記記憶部に記憶される指示内容を更新する指示内容更新部を更に含む、
ことを特徴とする付記１又は２の何れか１項に記載のストレージ装置の制御部。
（付記４）
前記指示内容更新部は、前記記憶部に記憶される更新時刻と更新状況に基づいて前記実行指示を削除する、
ことを特徴とする付記３に記載のストレージ装置の制御部。
（付記５）
前記指示内容更新部は、前記記憶部に既に指示内容が記憶されている場合に前記記憶部の更新処理を行う、
ことを特徴とする付記３又は４の何れか１項に記載のストレージ装置の制御部。
（付記６）
前記記憶内容通知部は、他の前記制御部の起動を認識すると前記記憶部に記憶した内容を前記起動した他の制御部に通知する、
ことを特徴とする付記１乃至５の何れか１項に記載のストレージ装置の制御部。
（付記７）
１以上の記憶媒体と、該記憶媒体に記憶されるデータの書込み／読出し制御を行う複数の制御部とを備えたストレージ装置であって、
前記複数の制御部のうち第１の制御部は、
管理端末からの実行指示を受け付ける第１の実行指示受付部と、
前記受け付けた実行指示の内容を記憶する記憶部と、
前記記憶部に記憶した内容を前記ストレージ装置内の他の制御部に通知する記憶内容通知部と、
前記実行指示に基づいて処理を行う処理部とを含み、
前記複数の制御部のうち第２の制御部は、
前記管理端末もしくは他の管理端末からの実行指示を受け付ける第２の実行指示受付部と、
前記第１の制御部から前記記憶部の内容を受信する記憶内容受信部と、
前記第１の制御部からの受信結果に基づいて前記第２の実行指示受付部で受け付けた実行指示の実行可否を判断する実行可否判断部とを含む、
ことを特徴とするストレージ装置。
（付記８）
前記記憶部に、前記実行指示を受信した制御部の識別情報と前記実行指示の更新時刻と前記実行指示の更新状況とを更に記憶する、
ことを特徴とする付記７に記載のストレージ装置。
（付記９）
定期的に前記制御部内で実行されている前記処理を確認し、前記処理の実行状況に基づいて前記記憶部に記憶される指示内容を更新する指示内容更新部を更に含む、
ことを特徴とする付記７又は８の何れか１項に記載のストレージ装置。
（付記１０）
前記指示内容更新部は、前記記憶部に記憶される更新時刻と更新状況に基づいて前記実行指示を削除する、
ことを特徴とする付記９に記載のストレージ装置。
（付記１１）
前記指示内容更新部は、前記記憶部に既に指示内容が記憶されている場合に前記記憶部の更新処理を行う、
ことを特徴とする付記９又は１０の何れか１項に記載のストレージ装置の制御部。
（付記１２）
前記記憶内容通知部は、他の善意制御部の起動を認識すると前記記憶部に記憶した内容を前記起動した他の制御部に通知する、
ことを特徴とする付記７乃至１１の何れか１項に記載のストレージ装置の制御部。
（付記１３）
記憶媒体に記憶されるデータの書込み／読出し制御を行うストレージ装置の制御方法であって、
管理端末からの実行指示を受け付ける実行指示受付ステップと、
前記受け付けた実行指示の内容を記憶部に記憶する記憶ステップと、
前記記憶部に記憶した内容を前記ストレージ装置内の他の制御部に通知する記憶内容通知ステップと、
前記実行指示に基づいて処理を行う処理ステップと、
を含むことを特徴とするストレージ装置の制御方法。
（付記１４）
前記記憶ステップは、前記実行指示を受信した制御部の識別情報と前記実行指示の更新時刻と前記実行指示の更新状況とを前記記憶部に更に記憶する、
ことを特徴とする付記１３に記載のストレージ装置の制御方法。
（付記１５）
定期的に前記制御部内で実行されている前記処理を確認し、前記処理の実行状況に基づいて前記記憶部に記憶される指示内容を更新する指示内容更新ステップを更に含む、
ことを特徴とする付記１３又は１４の何れか１項に記載のストレージ装置の制御方法。（付記１６）
前記指示内容更新ステップは、前記記憶部に記憶される更新時刻と更新状況に基づいて前記実行指示を削除する、
ことを特徴とする付記１５に記載のストレージ装置の制御方法。
（付記１７）
前記指示内容更新ステップは、前記記憶部に既に指示内容が記憶されている場合に前記記憶部の更新処理を行う、
ことを特徴とする付記１５又は１６の何れか１項に記載のストレージ装置の制御方法。（付記１８）
前記記憶内用通知ステップは、他の制御部の起動を認識すると前記記憶部に記憶した内容を前記起動した他の制御部に通知する、
ことを特徴とする付記１３乃至１７の何れか１項に記載のストレージ装置の制御方法。

実施形態の構成図である。 Ｆｕｎｃｔｉｏｎ管理テーブルのデータ構成図である。 Ｆｕｎｃｔｉｏｎ管理テーブル操作部１０５がＦｕｎｃｔｉｏｎ管理テーブルを使ってＣＭ間同期制御動作を実行する際の動作アルゴリズムを示す制御マトリックス図である。 実施形態の動作シーケンス例を示す図（その１）である。 実施形態の動作シーケンス例を示す図（その２）である。 従来技術と対比した本実施形態の動作説明図である。 ２重実行防止機能を説明するための動作シーケンス例を示す図（その１）である。 ２重実行防止機能を説明するための動作シーケンス例を示す図（その２）である。 マスタＣＭ−制御ＣＭ間での連携した書込み処理の動作シーケンス図である。 マスタＣＭ−制御ＣＭ間での連携した読出し処理の動作シーケンス図である。 従来技術の問題点の説明図である。

符号の説明

１０１ コントローラモジュール（ＣＭ）
１０２ グラフィカルユーザインタフェース（ＧＵＩ）
１０３ ファンクション（Ｆｕｎｃｔｉｏｎ）処理部
１０４ 動作中機能チェック部
１０５ ファンクション（Ｆｕｎｃｔｉｏｎ）管理テーブル操作部
１０６ ファンクション（Ｆｕｎｃｔｉｏｎ）管理テーブルエントリ情報配信部
１０７ ファンクション（Ｆｕｎｃｔｉｏｎ）管理テーブルエントリ情報受信部
１０８ ファンクション（Ｆｕｎｃｔｉｏｎ）管理テーブル監視タイマ部

Claims (8)

1. 記憶媒体に記憶されるデータの書込み／読出し制御を行う制御部を複数有するストレージ装置の制御部において、
   前記制御部の各々は、
   自装置を含む前記ストレージ装置内のいずれかの制御部が実行中の機能を示す情報と、当該機能を実行中の制御部を識別する情報を登録するための管理テーブルを記憶する記憶部と、
   管理端末からの実行指示を受け付ける実行指示受付部と、
   前記管理テーブルに登録されている情報に基づいて、前記受け付けた実行指示に関する処理を行う処理部と、
   前記管理端末からの実行指示を受け付けたときに前記管理テーブルを確認し、前記受け付けた実行指示で実行が指示される機能が既に前記管理テーブルに登録されている場合には、前記受け付けた実行指示で指示された機能が実行中であると判定し当該機能を実行できないことを前記管理端末に返し、前記受け付けた実行指示で指示される機能が前記記憶部に登録されていない場合には、前記受け付けた実行指示で指示された機能を実行中の機能として前記管理テーブルに登録する登録部と、
   前記管理テーブルに登録した機能に関する情報を前記ストレージ装置内の他の制御部に通知する記憶内容通知部と、
   前記他の制御部から通知された機能に関する情報を前記管理テーブルに登録する受信内容登録部と、
   を含む、ことを特徴とするストレージ装置の制御部。
2. 前記登録部が、前記管理テーブルに、前記実行指示を受信した制御部の識別情報と前記実行指示の更新時刻と前記実行指示の更新状況とを更に登録する、
   ことを特徴とする請求項１に記載のストレージ装置の制御部。
3. 前記複数の制御部の各々が、定期的に制御部内で実行されている処理を確認し、前記処理の実行状況に基づいて前記管理テーブルに登録される指示内容を更新する指示内容更新部を更に含む、
   ことを特徴とする請求項１又は２の何れか１項に記載のストレージ装置の制御部。
4. 前記指示内容更新部は、前記管理テーブルに登録される更新時刻と更新状況に基づいて前記機能に関する情報を管理テーブルから削除する、
   ことを特徴とする請求項３に記載のストレージ装置の制御部。
5. 前記指示内容更新部は、前記管理テーブルに既に指示内容が登録されている場合に前記管理テーブルの更新処理を行う、
   ことを特徴とする請求項３又は４の何れか１項に記載のストレージ装置の制御部。
6. 前記記憶内容通知部は、他の前記制御部の起動を認識すると前記管理テーブルに登録した内容を前記起動した他の制御部に通知する、
   ことを特徴とする請求項１乃至５の何れか１項に記載のストレージ装置の制御部。
7. １以上の記憶媒体と、該記憶媒体に記憶されるデータの書込み／読出し制御を行う複数の制御部とを備えたストレージ装置であって、
   前記複数の制御部の各々が、
   自装置を含む前記ストレージ装置内のいずれかの制御部が実行中の機能を示す情報と、当該機能を実行中の制御部を識別する情報を登録するための管理テーブルを記憶する記憶部と、
   管理端末からの実行指示を受け付ける実行指示受付部と、
   前記管理テーブルに登録されている情報に基づいて、前記受け付けた実行指示に関する処理を行う処理部と、
   前記管理端末からの実行指示を受け付けたときに前記管理テーブルを確認し、前記受け付けた実行指示で実行が指示される機能が既に前記管理テーブルに登録されている場合には、前記受け付けた実行指示で指示された機能が実行中であると判定し当該機能を実行できないことを前記管理端末に返し、前記受け付けた実行指示で指示される機能が前記記憶部に登録されていない場合には、前記受け付けた実行指示で指示された機能を実行中の機能として前記管理テーブルに登録する登録部と、
   前記管理テーブルに登録した機能に関する情報を前記ストレージ装置内の他の制御部に通知する記憶内容通知部と、
   前記他の制御部から通知された機能に関する情報を前記管理テーブルに登録する受信内容登録部と、
   を含む、ことを特徴とするストレージ装置。
8. 記憶媒体に記憶されるデータの書込み／読出し制御を行うストレージ装置の制御方法であって、
   前記ストレージ装置が備える複数の制御部の各々に、
   自装置を含む前記ストレージ装置内のいずれかの制御部が実行中の機能を示す情報と、当該機能を実行中の制御部を識別する情報を登録するための管理テーブルを記憶部に記憶するステップと、
   管理端末からの実行指示を受け付ける実行指示受付ステップと、
   前記管理テーブルに登録されている情報に基づいて処理を行う処理ステップと、
   前記管理端末からの実行指示を受け付けたときに前記管理テーブルを確認し、前記受け付けた実行指示で実行が指示される機能が既に前記管理テーブルに登録されている場合には、前記受け付けた実行指示で指示された機能が実行中であると判定し当該機能を実行できないことを前記管理端末に返し、前記受け付けた実行指示で指示される機能が前記記憶部に登録されていない場合には、前記受け付けた実行指示で指示された機能を実行中の機能として前記管理テーブルに登録する登録ステップと、
   前記管理テーブルに登録した機能に関する情報を前記ストレージ装置内の他の制御部に通知する記憶内容通知ステップと、
   前記他の制御部から通知された機能に関する情報を前記管理テーブルに登録する受信内容登録ステップと、
   を含む、処理を実行させることを特徴とするストレージ装置の制御方法。