特許 6788188 制御装置および制御プログラム

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

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

(11)【特許番号】6788188

(24)【登録日】2020年11月4日

(45)【発行日】2020年11月25日

(54)【発明の名称】制御装置および制御プログラム

(51)【国際特許分類】

   G06F 11/14 20060101AFI20201116BHJP

   G06F 16/185 20190101ALI20201116BHJP

【ＦＩ】

   G06F11/14 661

   G06F16/185

【請求項の数】7

【全頁数】33

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

(22)【出願日】2016年11月11日

(65)【公開番号】特開2018-77775(P2018-77775A)

(43)【公開日】2018年5月17日

【審査請求日】2019年8月7日

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110002918

【氏名又は名称】特許業務法人扶桑国際特許事務所

(72)【発明者】

【氏名】前田 美穂子

(72)【発明者】

【氏名】大▲高▼ 敦弘

(72)【発明者】

【氏名】坂口 明子

(72)【発明者】

【氏名】佐藤 英俊

【審査官】 多胡 滋

(56)【参考文献】

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

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

【文献】 特開２００６−０７９２７３（ＪＰ，Ａ）

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

Ｇ０６Ｆ １１／１４

Ｇ０６Ｆ １６／１８５

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

【請求項1】

複数の上位装置により発行される更新要求に応じて更新されるデータのバックアップを行う制御装置であって、
前記更新要求の受信間隔と最終の受信時刻とを上位装置毎に記憶する記憶部と、
前記受信間隔と前記最終の受信時刻とを上位装置毎に前記記憶部に記録し、所定のタイミングで、前記最終の受信時刻から前記タイミングまでの経過時間と前記受信間隔とを上位装置毎に比較し、上位装置毎の比較結果に応じて前記バックアップを開始する処理部と、
を有する制御装置。

【請求項2】

前記処理部は、前記複数の上位装置それぞれについて前記受信間隔よりも前記経過時間の方が長い場合に前記バックアップを開始し、少なくとも１つの上位装置について前記受信間隔より前記経過時間の方が長くない場合に前記バックアップの開始を延期する、請求項１記載の制御装置。

【請求項3】

前記処理部は、少なくとも１つの上位装置について前記受信間隔より前記経過時間の方が長くない場合でも、他の上位装置に関する前記経過時間が所定時間以上である場合は前記バックアップを開始する、請求項２記載の制御装置。

【請求項4】

前記データは、前記複数の上位装置それぞれの固有情報と、他の情報から生成可能な固定情報とを含み、
前記処理部は、前記データのうち、前記固有情報を前記バックアップの対象とし、前記固定情報を前記バックアップの対象から除外する、
請求項１乃至３の何れか１項に記載の制御装置。

【請求項5】

前記タイミングは、受信した前記更新要求に応じた前記データの更新とは非同期に決定されるタイミングである、請求項１乃至４の何れか１項に記載の制御装置。

【請求項6】

前記処理部は、前記バックアップでは、第１の記憶装置に記憶された前記データを基にバックアップデータを生成し、書き込み回数に制限のある記憶素子を備える第２の記憶装置に前記バックアップデータを格納する、請求項１乃至５の何れか１項に記載の制御装置。

【請求項7】

複数の上位装置により発行される更新要求に応じて更新されるデータのバックアップの制御に用いられる制御プログラムであって、
前記更新要求の受信間隔と最終の受信時刻とを上位装置毎に記憶部に記録し、
所定のタイミングで、前記最終の受信時刻から前記タイミングまでの経過時間と前記受信間隔とを上位装置毎に比較し、
上位装置毎の比較結果に応じて前記バックアップを開始する、
処理をコンピュータに実行させる制御プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は制御装置および制御プログラムに関する。

【背景技術】

【0002】

情報処理システムでは、データの喪失に備えて、当該データのバックアップを取得することがある。バックアップでは、例えば、ある情報処理装置の記憶装置に保持されるデータを複製し、同装置または別の装置が備える別の記憶装置に格納する。情報処理装置は、障害などにより元のデータを利用できなくなっても、別の記憶装置に格納されたデータにより、元のデータをバックアップ時点の状態に復元できる。

【0003】

例えば、揮発性メモリに記憶されたデータを不揮発性メモリに書き込んでバックアップするバックアップ記憶制御装置の提案がある。バックアップ記憶制御装置は、揮発性メモリ上でのバックアップ対象データのアクセス頻度が少ない状態では、揮発性メモリ上でバックアップ対象データがアクセスされる毎に不揮発性メモリへバックアップ処理を行う。

【0004】

また、データベースのオンラインバックアップを行う計算機システムが、運用中のデータベースの業務処理の量（メイン処理量）から、バックアップ時間中のメイン処理量を予測し、バックアップの実行可否を決定する提案もある。

【0005】

なお、バックアップ対象データを、当該データの更新頻度や重要度に従って複数のクラスに分類し、クラス毎にバックアップ有無の設定を可能とするバックアップ装置の提案もある。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２００１−１９５３１４号公報

【特許文献2】特開２００４−１７１２４９号公報

【特許文献3】特開２００８−１７１２４１号公報

【発明の概要】

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

【0007】

所定の装置が、複数の装置それぞれにより発行される一連の更新要求に応じて、記憶装置に記憶されたデータを更新することがある。このとき、当該データのバックアップを実行するタイミングが問題となる。

【0008】

例えば、上記提案のように、各更新要求に応じた更新が行われるたびに、該当のデータに対応するバックアップデータを取得することが考えられる。しかし、更新要求のたびにバックアップを取得すると、バックアップの頻度が増えやすい。このため、バックアップ処理の負荷により、他の処理（例えば、本来の業務処理など）に影響を及ぼす可能性がある。特に、更新要求の発行元の上位装置の数が増すほど、この影響は深刻になり得る。

【0009】

１つの側面では、本発明は、バックアップの頻度を低減可能にすることを目的とする。

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

【0010】

１つの態様では、複数の上位装置により発行される更新要求に応じて更新されるデータのバックアップを行う制御装置が提供される。制御装置は、記憶部と処理部とを有する。記憶部は、更新要求の受信間隔と最終の受信時刻とを上位装置毎に記憶する。処理部は、受信間隔と最終の受信時刻とを上位装置毎に記憶部に記録し、所定のタイミングで、最終の受信時刻から当該タイミングまでの経過時間と受信間隔とを上位装置毎に比較し、上位装置毎の比較結果に応じてバックアップを開始する。

【発明の効果】

【0011】

１つの側面では、バックアップの頻度を低減できる。

【図面の簡単な説明】

【0012】

【図1】第１の実施の形態の情報処理システムの例を示す図である。

【図2】第２の実施の形態の情報処理システムの例を示す図である。

【図3】ストレージ装置のハードウェア例を示す図である。

【図4】ＣＭのハードウェア例を示す図である。

【図5】サーバのハードウェア例を示す図である。

【図6】ＣＭの機能例を示す図である。

【図7】ＣＭのＲＡＭに記憶される情報の例を示す図である。

【図8】フィルター情報の例を示す図である。

【図9】ダミーサブスクリプションの例を示す図である。

【図10】リスナー情報の例を示す図である。

【図11】サブスクリプション個別情報の例を示す図である。

【図12】サブスクリプションビットマップの例を示す図である。

【図13】更新管理情報の例を示す図である。

【図14】一連の更新要求の受信例を示す図である。

【図15】更新要求受信処理の例を示すフローチャートである。

【図16】リスナー情報更新処理の例を示すフローチャートである。

【図17】サブスクリプション更新処理の例を示すフローチャートである。

【図18】ＢＵＤに書き込まれる情報／書き込まれない情報の例を示す図である。

【図19】ポーリングチェック処理の例を示すフローチャートである。

【図20】ポーリングチェックの例を示す図である。

【図21】ポーリングチェックの例（続き）を示す図である。

【図22】ポーリングチェックの例（続き）を示す図である。

【図23】サブスクリプションの出力例を示す図である。

【図24】ＢＵＤへの書き込み量の例を示す図である。

【図25】ＢＵＤへの書き込み量の比較例を示す図である。

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

【0013】

以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理システムの例を示す図である。第１の実施の形態の情報処理システムは、制御装置１、上位装置２，３および記憶装置４，５を含む。制御装置１、上位装置２，３および記憶装置４，５は、ネットワーク６に接続されている。記憶装置４，５のうちの一方または両方は、制御装置１に内蔵されてもよい。

【0014】

上位装置２，３は、ネットワーク６を介して、記憶装置４に記憶されたデータＤ１を更新する。具体的には、上位装置２，３それぞれは、データＤ１に対する一連の更新要求を発行する。制御装置１は、更新要求を受信し、更新要求に応じて記憶装置４に格納されたデータＤ１を更新する。

【0015】

データＤ１は、上位装置２，３それぞれの処理に用いられるデータ要素の集合でもよいし、制御装置１による所定の処理に用いられるデータ要素の集合でもよい。後者の例として、制御装置１がシステム内の運用管理におけるイベント通知機能を担う場合が考えられる。その場合、データＤ１は、制御装置１による上位装置２，３へのイベント通知の設定情報（例えば、通知対象のイベントや通知先を指定する情報など）でもよい。

【0016】

上位装置２，３は、識別情報（装置＃と表記する）をもつ。上位装置２の装置＃は“１”である。上位装置３の装置＃は“２”である。上位装置２，３により発行される更新要求は、上位装置２，３それぞれの装置＃、または、制御装置１により装置＃に対応付け可能な情報を含む。

【0017】

制御装置１は、記憶装置４に記憶されたデータＤ１に対するバックアップ処理（単にバックアップと称することがある）を実行する。具体的には、制御装置１は、記憶装置４に記憶されたデータＤ１を複製することで、データＤ１に対応するバックアップデータＤ２を生成する。そして、制御装置１は、バックアップデータＤ２を記憶装置５に格納する。ここで、制御装置１は、バックアップの実行タイミングを制御する機能を提供する。制御装置１は、記憶部１ａおよび処理部１ｂを有する。

【0018】

記憶部１ａは、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。処理部１ｂは、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。処理部１ｂはプログラムを実行するプロセッサでもよい。「プロセッサ」は、複数のプロセッサの集合（マルチプロセッサ）を含み得る。

【0019】

記憶部１ａは、更新要求の受信間隔と最終の受信時刻とを上位装置毎に記憶する。例えば、テーブルＸ１を記憶する。テーブルＸ１は、装置＃、受信間隔および最終の受信時刻の項目を含む。装置＃の項目には、装置＃が登録される。受信間隔の項目には、更新要求の受信間隔が登録される。最終の受信時刻の項目には、更新要求の最終の受信時刻（最新の受信時刻）が登録される。例えば、テーブルＸ１には、装置＃１（上位装置２）に対して、受信間隔Δｔ１および最終の受信時刻Ｔ１が登録されている。また、テーブルＸ１には、装置＃２（上位装置３）に対して、受信間隔Δｔ２および最終の受信時刻Ｔ２が登録されている。

【0020】

処理部１ｂは、上位装置２，３それぞれにより発行される更新要求を受信し、受信間隔と最終の受信時刻とを上位装置毎に記憶部１ａに記録する。具体的には、処理部１ｂは、上位装置２，３それぞれによる更新要求の受信間隔と最終の受信時刻とを、装置＃に対応付けて、テーブルＸ１に登録する。また、処理部１ｂは、更新要求に応じて、記憶装置４に記憶されたデータＤ１を更新する。

【0021】

例えば、処理部１ｂが、上位装置２を送信元とする更新要求を、時刻Ｔ１に受信した場合を考える。処理部１ｂは、時刻Ｔ１を、上位装置２による最終の受信時刻（今回の受信時刻）とする。そして、処理部１ｂは、前回の受信時刻と今回の受信時刻Ｔ１との時間差を、上位装置２による更新要求の受信間隔とする。

【0022】

このとき、処理部１ｂは、上位装置２について、前回までに得た受信間隔よりも今回の受信間隔の方が大きい場合に、今回の受信間隔を上位装置２の受信間隔Δｔ１として採用してもよい。また、前回までに得た受信間隔よりも今回の受信間隔の方が小さい場合、および、前回までに得た受信間隔が今回の受信間隔に等しい場合に、前回までに得た受信間隔を上位装置２の受信間隔Δｔ１として採用してもよい。後述の処理により、上位装置２による一連の更新要求が途切れたことを適切に検出できるようにするためである。あるいは、処理部１ｂは、上位装置２からの更新要求の受信間隔の統計値を、上位装置２による更新要求の受信間隔としてもよい。統計値としては、例えば、パーセンタイル値（９０パーセンタイル値）や平均値（あるいは平均値に誤差を加算した値）などが考えられる。

【0023】

処理部１ｂは、上位装置３についても、同様にして、更新要求の受信間隔Δｔ２および最終の受信時刻Ｔ２を取得し、テーブルＸ１に登録する。ここで、時刻Ｔ２は、時刻Ｔ１よりも未来の時刻であるとする。

【0024】

処理部１ｂは、所定のタイミングで、最終の受信時刻から当該タイミングまでの経過時間と受信間隔とを上位装置毎に比較する。処理部１ｂは、上位装置毎の比較結果に応じてバックアップを開始する。「所定のタイミング」は、更新要求に応じたデータ更新とは非同期である（同期していない）。例えば、「所定のタイミング」は、周期的なタイミングでもよいし、別の装置によりバックアップの開始確認を指示されたタイミングでもよい。当該所定のタイミングは、バックアップの開始候補のタイミングである。一例として、第１のタイミングは時刻τ１である。また、一例として、第２のタイミングは時刻τ２である。時刻τ２は、時刻τ１よりも未来の時刻である。

【0025】

より具体的には、処理部１ｂは、時刻τ１で、記憶部１ａに記憶されたテーブルＸ１を参照して、最終の受信時刻から時刻τ１までの経過時間と受信間隔とを上位装置２，３毎に比較する。

【0026】

すなわち、処理部１ｂは、上位装置２について、最終の受信時刻Ｔ１から時刻τ１までの時間差（τ１−Ｔ１のように表記する）と、受信間隔Δｔ１とを比較する。ここでは、τ１−Ｔ１＞Δｔ１であるとする。また、処理部１ｂは、上位装置３について、最終の受信時刻Ｔ２から時刻τ１までの時間差τ１−Ｔ２と受信間隔Δｔ２とを比較する。ここでは、τ１−Ｔ２≦Δｔ２であるとする。

【0027】

処理部１ｂは、上位装置２に関する比較結果τ１−Ｔ１＞Δｔ１、および、上位装置３に関する比較結果τ１−Ｔ２≦Δｔ２に応じて、データＤ１のバックアップを開始するか否かを決定する。この例の場合、処理部１ｂは、データＤ１のバックアップの開始を延期する（すなわち、今回タイミングでのバックアップの開始を保留する）。

【0028】

なぜなら、上位装置３に関する比較結果τ１−Ｔ２≦Δｔ２によれば、上位装置３により発行される一連の更新要求の受信は、未だ途絶えていない（上位装置３によるデータＤ１の一連の更新が継続している）可能性が高いからである。このように、処理部１ｂは、何れかの上位装置によるデータＤ１の更新が継続していると推定される場合には、バックアップの開始を延期する。なお、上位装置２に関する比較結果τ１−Ｔ１＞Δｔ１によれば、上位装置２により発行される一連の更新要求の受信は、既に途絶えている（上位装置２によるデータＤ１の一連の更新が完了している）可能性が高い。

【0029】

次に、処理部１ｂは、時刻τ２で、記憶部１ａに記憶されたテーブルＸ１を参照して、最終の受信時刻から時刻τ２までの経過時間と受信間隔とを上位装置２，３毎に比較する。

【0030】

すなわち、処理部１ｂは、上位装置２について、最終の受信時刻Ｔ１から時刻τ２までの時間差τ２−Ｔ１と受信間隔Δｔ１とを比較する。ここでは、τ２−Ｔ１＞Δｔ１である。また、処理部１ｂは、上位装置３について、最終の受信時刻Ｔ２から時刻τ２までの時間差τ２−Ｔ２と受信間隔Δｔ２とを比較する。ここでは、τ２−Ｔ２＞Δｔ２であるとする。

【0031】

処理部１ｂは、上位装置２に関する比較結果τ２−Ｔ１＞Δｔ１、および、上位装置３に関する比較結果τ２−Ｔ２＞Δｔ２に応じて、データＤ１のバックアップを開始するか否かを決定する。この例の場合、処理部１ｂは、データＤ１のバックアップを直ちに開始する。

【0032】

なぜなら、上位装置２に関する比較結果τ２−Ｔ１＞Δｔ１、および、上位装置３に関する比較結果τ２−Ｔ２＞Δｔ２によれば、上位装置２，３により発行される一連の更新要求の受信は、既に途絶えている可能性が高いからである。この場合、上位装置２，３によるデータＤ１の一連の更新が完了していると考えられる。このように、処理部１ｂは、全ての上位装置によるデータＤ１の更新が完了していると推定される場合には、バックアップを開始する。そして、処理部１ｂは、記憶装置４に記憶されたデータＤ１に対応するバックアップデータＤ２を生成し、バックアップデータＤ２を記憶装置５に格納する。

【0033】

こうして、制御装置１は、上位装置２，３による更新が完了したタイミングに絞ってバックアップを実行することで、バックアップの頻度を低減できる。
ところで、バックアップの頻度が過多または過少であると、好ましくない影響をシステムに及ぼし得る。例えば、上位装置２，３それぞれによる更新が行われるたびに、データＤ１のバックアップを取得することも考えられる。しかし、この方法では、バックアップの頻度が増えやすい。このため、バックアップに伴う制御装置１や記憶装置４，５などの負荷により、他の処理（例えば、制御装置１や上位装置２，３などによる本来の業務処理）に影響を及ぼす可能性がある。

【0034】

より具体的には、制御装置１が更新要求に対する更新およびバックアップの実行後に更新要求に応答していると、バックアップ時間が要因となって更新要求に対する応答遅延が増し、制御装置１や上位装置２，３による次の処理の実行が遅延し得る。あるいは、バックアップデータＤ２の書き込み先の記憶装置５でリソースがロックされ、記憶装置５にログ書き込みなどを行う上位装置２，３上の業務処理で待ちが生じる可能性もある。

【0035】

一方、例えば、スケジュールされた時刻に、データＤ１のバックアップを実行することも考えられる。この方法では、更新要求のたびにバックアップを実行するよりもバックアップの頻度を減らせる。しかし、その反面、現在取得済のバックアップデータＤ２が、最新の状態のデータに対応するバックアップデータでない可能性が高まる。この場合、記憶装置４の障害などが発生したときに、バックアップデータＤ２からデータＤ１を復旧しようとしたときに、データＤ１を最新の状態に戻せない可能性が高まり、データＤ１を適切に保全できないおそれがある。

【0036】

そこで、制御装置１は、上位装置２，３により発行されるデータＤ１の一連の更新要求の受信間隔と最終の受信時刻とを基に、上位装置２，３それぞれによる一連の更新要求の発行が完了したと推定されるタイミングで、データＤ１のバックアップを開始する。

【0037】

これにより、バックアップの頻度を減らしながら、データＤ１の最新の状態に対応するバックアップデータＤ２を効率的に取得可能になる。制御装置１は、複数の上位装置のうち少なくとも１つの上位装置によりデータＤ１が更新中であると判断される間は、データＤ１のバックアップを保留する。理由は次の通りである。

【0038】

例えば、上位装置３によりデータＤ１が更新中であるにも拘わらずバックアップデータＤ２を取得すると、上位装置３による、その後のデータＤ１の更新が今回のバックアップデータＤ２に反映されない。ここで、ある上位装置による一連の更新要求のうち、最初の更新要求の受信時刻と最後の更新要求の受信時刻との時間差は、比較的短いことが多く、その短い間に記憶装置４などの障害によりデータＤ１が喪失される可能性は比較的低いと考えられる。このため、制御装置１は、何れかの上位装置がデータＤ１を更新中である間は、バックアップデータの取得を控える。

【0039】

ただし、複数の上位装置によるデータＤ１の更新が重なると、各上位装置による更新が完了するまでの時間が長引く。このため、制御装置１は、データＤ１に対する一連の更新要求を同時に発行していた各上位装置によるデータＤ１の更新が完了したことを検出すると、直ちにデータＤ１のバックアップを開始する。これにより、各上位装置の更新に対して、より新しい状態のバックアップデータＤ２を早いタイミングで取得できる。その結果、当該バックアップデータＤ２により、各上位装置にとって最新の状態で、データＤ１を復元できる可能性を高められる。すなわち、バックアップの頻度の低減とバックアップによるデータ保全との両立を図れる。

【0040】

また、更新要求によるデータ更新とは非同期に決定されるタイミングでバックアップを実行することで、更新要求に対する応答時間を高速化できる。
更に、制御装置１によれば、バックアップの実行の頻度を低減することで、記憶装置５に対する書き込み回数を減らせるという利点もある。このため、例えば、記憶装置５として、ＳＳＤ（Solid State Drive）のように内蔵の記憶素子の書き込み回数に制限がある記憶デバイスを用いる場合に、記憶装置５の長寿命化を図れるという利点もある。

【0041】

以下では、制御装置１の機能を有するストレージ装置を例示して、バックアップの実行を制御する機能を更に具体的に説明する。
［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムの例を示す図である。第２の実施の形態の情報処理システムは、ストレージ装置１０およびサーバ２００，３００，４００を含む。ストレージ装置１０およびサーバ２００，３００，４００は、ＬＡＮ（Local Area Network）２０に接続されている。ＬＡＮ２０は、運用管理用の通信に用いられるネットワークである。また、ストレージ装置１０およびサーバ２００，３００，４００は、ＳＡＮ（Storage Area Network）３０に接続されている。ＳＡＮ３０は、サーバ２００，３００，４００からストレージ装置１０に格納されたデータにアクセスするために用いられるネットワークである。

【0042】

ストレージ装置１０は、サーバ２００，３００，４００による業務処理に用いられる各種のデータを記憶する。ストレージ装置１０は、ストレージアレイやディスクアレイなどと呼ばれるものでもよい。

【0043】

ストレージ装置１０は、複数の記憶装置を備える。記憶装置は、例えば、ＨＤＤやＳＳＤなどである。ストレージ装置１０は、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）の技術により複数の記憶装置を用いた論理ボリュームを作成し、サーバ２００，３００，４００に提供する。また、ストレージ装置１０は、サーバ２００，３００，４００に対して、所定の事象の発生を通知する。通知対象の事象の一例として、ストレージ装置１０において新たな論理ボリュームを利用可能になったことや、ストレージ装置１０におけるデータコピー処理の進捗の変化などが考えられる。また、通知対象の事象は、サーバ２００，３００，４００により選択される。

【0044】

サーバ２００，３００，４００は、ＳＡＮ３０経由で、ストレージ装置１０に記憶された業務データに対するブロックアクセスを行い、業務データを用いた所定の業務処理を実行するサーバコンピュータである。

【0045】

また、サーバ２００，３００，４００は、ＬＡＮ２０経由で、ストレージ装置１０による通知対象の事象に対する設定を行う。サーバ２００，３００，４００それぞれにより通知を受ける事象の内容は異なる。サーバ２００，３００，４００は、個別に、通知を受けたい事象の情報や通知先の情報を、ストレージ装置１０のリポジトリに設定する。

【0046】

ここで、ストレージ装置１０は、ＳＭＩ−Ｓ（Storage Management Initiative - Specification）の装置構成変更通知機能（Indication機能と称することがある）を用いて、事象の通知を行う。ＳＭＩ−Ｓは、ＳＮＩＡ（Storage Networking Industry Association）が開発・保守している標準規約であり、異ベンダ／異機種混在システムでのストレージ装置の相互運用性の向上を目指すものである。

【0047】

サーバ２００，３００，４００は、ＳＭＩ−ＳのIndication機能において、ＳＭＩ−Ｓの規約に従った設定を、ストレージ装置１０のリポジトリに対して行う。具体的な設定情報は、次の通りである。

【0048】

第１の設定情報は、通知先サーバのＩＰ（Internet Protocol）アドレスおよび通知先サーバの名称である。ここで、通知先サーバをリスナーと称することがある。また、リスナーの名称をリスナー名と称することがある。

【0049】

第２の設定情報は、通知対象の事象である。ここで、通知対象の事象をフィルターと称することがある。
第３の設定情報は、リスナー（通知先のサーバ）とフィルターとのマッピングである。リスナーとフィルターとのマッピングを、サブスクリプションと称することがある。

【0050】

第１，第２，第３の設定情報を総称して、Indication情報と称することがある。
サーバ２００，３００，４００は、ストレージ装置１０のリポジトリに格納されたIndication情報に対する更新要求を発行する。サーバ２００，３００，４００は、当該更新要求をＬＡＮ２０経由で、ストレージ装置１０に送信する。

【0051】

図３は、ストレージ装置のハードウェア例を示す図である。ストレージ装置１０は、コントローラモジュール（ＣＭ：Controller Module）１００，１００ａおよびドライブエンクロージャ（ＤＥ：Drive Enclosure）５０を有する。ＣＭ１００，１００ａおよびＤＥ５０は、ストレージ装置１０の内部のバスにより相互に接続されている。

【0052】

ＣＭ１００，１００ａは、ＤＥ５０に収納された記憶装置に対するブロックアクセスを制御する制御装置である。ＣＭ１００，１００ａは、ストレージ制御装置、あるいは、単にコントローラなどと呼ばれることもある。

【0053】

ＣＭ１００，１００ａは、Indication機能を提供する。例えば、ＣＭ１００，１００ａの何れか一方が、ストレージ装置１０におけるIndication機能を提供してもよい。あるいは、ＣＭ１００，１００ａの両方が、ストレージ装置１０におけるIndication機能を提供してもよい。例えば、ＣＭ１００の故障時に、ＣＭ１００ａがIndication機能を代替してもよい。第２の実施の形態の例では、ＣＭ１００が、ストレージ装置１０におけるIndication機能の提供を担当することを想定する（ＣＭ１００ａもＣＭ１００と同様にIndication機能を提供できる）。

【0054】

ＤＥ５０は、複数のＨＤＤを収納する。例えば、ＤＥ５０は、ＨＤＤ５１，５２，５３，・・・を備える。ＤＥ５０は、ＨＤＤに加えて、あるいは、ＨＤＤに代えて、ＳＳＤなどの他の種類の記憶装置を複数備えてもよい。

【0055】

ここで、Indication情報は、ＣＭ１００が備える所定の揮発性メモリに格納される。このため、停電や故障などによるＣＭ１００の再起動や、ＣＭ１００の電源オン／オフが発生すると、Indication情報は消去される。そこで、ＣＭ１００は、揮発性メモリに格納されているIndication情報を複製して、不揮発性メモリにバックアップする。これにより、ＣＭ１００の再起動や、ＣＭ１００の電源オン／オフが発生しても、不揮発性メモリからIndication情報を復元可能にする。ＣＭ１００は、Indication情報のバックアップの開始タイミングを制御する機能を提供する。

【0056】

図４は、ＣＭのハードウェア例を示す図である。ＣＭ１００は、プロセッサ１０１、ＲＡＭ１０２、ＢＵＤ（Boot-up and Utility Device）１０３、媒体リーダ１０４、ＣＭ−ＩＦ（InterFace）１０５、ＤＩ（Drive Interface）１０６、ＮＡ（Network Adapter）１０７およびＣＡ（Channel Adapter）１０８を有する。これらのハードウェアは、ＣＭ１００の内部バスに接続されている。ＣＭ１００ａもＣＭ１００と同様のハードウェアにより実現できる。

【0057】

プロセッサ１０１は、ＣＭ１００の情報処理を制御するハードウェアである。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。

【0058】

ＲＡＭ１０２は、ＣＭ１００の主記憶装置である。ＲＡＭ１０２は、揮発性の半導体メモリである。ＲＡＭ１０２として、例えば、ＳＲＡＭ（Static RAM）やＤＲＡＭ（Dynamic RAM）などが用いられる。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳ（ファームウェア）のプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いられる各種データを記憶する。

【0059】

ＢＵＤ１０３は、ＣＭ１００の補助記憶装置である。ＢＵＤ１０３は、不揮発性の半導体メモリである。ＢＵＤ１０３として、ＳＳＤが用いられる。ＢＵＤ１０３は、ＯＳ（ファームウェアを含む）のプログラムや各種データなどを記憶する。ＢＵＤ１０３は、ＲＡＭ１０２に記憶されたデータに対応するバックアップデータの保存にも用いられる。

【0060】

媒体リーダ１０４は、記録媒体１１に記憶されたプログラムやデータを読み取る装置である。記録媒体１１として、例えば、フラッシュメモリカードなどの不揮発性の半導体メモリを使用することができる。媒体リーダ１０４は、例えば、プロセッサ１０１からの命令に従って、記録媒体１１から読み取ったプログラムやデータを、ＲＡＭ１０２やＢＵＤ１０３に格納することもできる。

【0061】

ＣＭ−ＩＦ１０５は、ＣＭ１００ａと接続するためのインタフェースである。ＣＭ１００は、ＣＭ−ＩＦ１０５を用いて、ＣＭ１００ａと連携してデータアクセスを行える。例えば、ＣＭ１００を運用系、ＣＭ１００ａを待機系としてもよい。あるいは、ＣＭ１００，１００ａの両方を運用系として、データアクセスを分散して行ってもよい。何れの場合も、一方の故障時に他方でデータアクセスを引き継ぐことができ、ユーザの業務が停止されることを防げる。

【0062】

ＤＩ１０６は、ＤＥ５０と通信するためのインタフェースである。例えば、ＤＩ１０６として、ＳＡＳ（Serial Attached SCSI）などのインタフェースを用いることができる。
ＮＡ１０７は、ＬＡＮ２０を介してサーバ２００，３００，４００と通信する通信インタフェースである。ＮＡ２０として、例えばイーサネット（登録商標）のインタフェースを用いることができる。

【0063】

ＣＡ１０８は、ＳＡＮ３０を介してサーバ２００，３００，４００と通信する通信インタフェースである。ＣＡ１０８として、例えばＦＣ（Fibre Channel）のインタフェースを用いることができる。ＣＡ１０８は、サーバ２００，３００，４００からＤＥ５０へのブロックアクセスに用いられる。ＣＡ１０８として、ＦＣ以外のインタフェース（例えば、ｉＳＣＳＩ（Internet Small Computer System Interface）など）が用いられることもある。

【0064】

図５は、サーバのハードウェア例を示す図である。サーバ２００は、プロセッサ２０１、ＲＡＭ２０２、ＨＤＤ２０３、媒体リーダ２０４、画像信号処理部２０５、入力信号処理部２０６、ＬＡＮ−ＩＦ２０７およびＨＢＡ（Host Bus Adapter）２０８を有する。各ハードウェアはサーバ２００のバスに接続されている。サーバ３００，４００もサーバ２００と同様のハードウェアを用いて実現できる。

【0065】

プロセッサ２０１は、サーバ２００の情報処理を制御するハードウェアである。プロセッサ２０１は、マルチプロセッサであってもよい。プロセッサ２０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ２０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。

【0066】

ＲＡＭ２０２は、サーバ２００の主記憶装置である。ＲＡＭ２０２は、プロセッサ２０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ２０２は、プロセッサ２０１による処理に用いる各種データを記憶する。

【0067】

ＨＤＤ２０３は、サーバ２００の補助記憶装置である。ＨＤＤ２０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ２０３は、ＯＳのプログラム、アプリケーションプログラム、および各種データを記憶する。サーバ２００は、ＨＤＤ２０３に代えて、または、ＨＤＤ２０３に加えて、ＳＳＤなどの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。

【0068】

媒体リーダ２０４は、記録媒体２１に記録されたプログラムやデータを読み取る装置である。記録媒体２１として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。また、記録媒体２１として、例えば、フラッシュメモリカードなどの不揮発性の半導体メモリを使用することもできる。媒体リーダ２０４は、例えば、プロセッサ２０１からの命令に従って、記録媒体２１から読み取ったプログラムやデータをＲＡＭ２０２またはＨＤＤ２０３に格納する。

【0069】

画像信号処理部２０５は、プロセッサ２０１からの命令に従って、サーバ２００に接続されたディスプレイ２２に画像を出力する。ディスプレイ２２として、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。

【0070】

入力信号処理部２０６は、サーバ２００に接続された入力デバイス２３から入力信号を取得し、プロセッサ２０１に出力する。入力デバイス２３として、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。

【0071】

ＬＡＮ−ＩＦ２０７は、ＬＡＮ２０を介してストレージ装置１０と通信する通信インタフェースである。ＬＡＮ−ＩＦ２０７は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。

【0072】

ＨＢＡ２０８は、ＳＡＮ３０を介してストレージ装置１０と通信する通信インタフェースである。ＨＢＡ２０８として、ＦＣのインタフェースを用いることができる。ただし、ＨＢＡ２０８として、ｉＳＣＳＩなどのＦＣ以外のインタフェースが用いられることもある。

【0073】

図６は、ＣＭの機能例を示す図である。ＣＭ１００は、通知制御部１１１およびＢＵＤ制御部１１２を有する。通知制御部１１１およびＢＵＤ制御部１１２は、ＲＡＭ１０２に記憶されたプログラムをプロセッサ１０１が実行することで実現される。

【0074】

通知制御部１１１は、Indication情報に対する更新要求をサーバ２００，３００，４００それぞれから受信する。Indication情報は、ＲＡＭ１０２に格納されている。ＲＡＭ１０２の記憶領域の一部が、Indication情報を記憶するリポジトリの役割を担う。通知制御部１１１は、更新要求に応じて、ＲＡＭ１０２に記憶されたIndication情報を更新する。

【0075】

ここで、図６では、運用管理部２１０，３１０，４１０を図示している。運用管理部２１０は、プロセッサ２０１により発揮される運用管理機能である。運用管理部３１０は、サーバ３００が備えるプロセッサにより発揮される運用管理機能である。運用管理部４１０は、サーバ４００が備えるプロセッサにより発揮される運用管理機能である。運用管理部２１０，３１０，４１０は、サーバ２００，３００，４００それぞれが備えるＲＡＭに記憶された所定のプログラムを、サーバ２００，３００，４００それぞれが備えるプロセッサが実行することで実現される。

【0076】

例えば、運用管理部２１０，３１０，４１０それぞれは、Indication情報に対する更新要求を発行し、ＣＭ１００に送信する。運用管理部２１０，３１０，４１０は、監視対象とする事象（フィルター）を、Indication情報に、個別に登録することができる。監視対象とする事象は、運用管理部２１０，３１０，４１０に対して、予め与えられてもよい（例えば、サーバ２００，３００，４００が備える記憶装置に監視対象とする事象が予め登録されていてもよい）。あるいは、運用管理部２１０，３１０，４１０は、監視対象とする事象のユーザによる事後的な選択を許容してもよい。

【0077】

通知制御部１１１は、サーバ２００，３００，４００によるIndication情報に対する更新要求を監視する。通知制御部１１１は、更新要求の監視により、サーバ２００，３００，４００それぞれによる更新要求の受信間隔、および、最終の受信時刻を取得する。通知制御部１１１は、取得した受信間隔および最終の受信時刻を、サーバ２００，３００，４００それぞれの識別情報（例えば、リスナー名）に対応付けて、ＲＡＭ１０２に格納する。

【0078】

通知制御部１１１は、ストレージ装置１０における所定の事象の発生を検出すると、Indication情報の設定内容に従って、当該事象の通知対象のリスナーに、当該事象の発生を通知する。

【0079】

ＢＵＤ制御部１１２は、ＲＡＭ１０２に記憶されたIndication情報のバックアップを行う。具体的には、ＢＵＤ制御部１１２は、所定のタイミングで、ＲＡＭ１０２に記憶された情報に基づいて、更新要求の最終の受信時刻から当該タイミングまでの経過時間と、更新要求の受信間隔とをサーバ毎に比較する。ＢＵＤ制御部１１２は、サーバ毎の比較結果に応じて、バックアップを開始するか否かを決定する。

【0080】

ＢＵＤ制御部１１２は、バックアップを開始すると決定した場合、ＲＡＭ１０２に記憶されたIndication情報を複製することで、Indication情報に対応するバックアップデータを生成する。ＢＵＤ制御部１１２は、生成したバックアップデータをＢＵＤ１０３に格納する。また、ＢＵＤ制御部１１２は、バックアップを開始しないと決定した場合、今回のタイミングではバックアップの開始を保留し、次回以降のタイミングにバックアップの開始を延期する。

【0081】

ここで、ＢＵＤ制御部１１２がバックアップの開始候補とするタイミングは、所定の周期で定められるタイミングであるとする。ただし、ＢＵＤ制御部１１２がバックアップの開始候補とするタイミングは、別の方法により定められてもよい。例えば、ＢＵＤ制御部１１２がバックアップの開始候補とするタイミングは、他の装置によりバックアップ開始の確認を指示されたタイミングでもよい。

【0082】

また、ＢＵＤ制御部１１２は、ＢＵＤ１０３に記憶されたバックアップデータに基づいて、ＲＡＭ１０２にIndication情報をリストアすることもある。
図７は、ＣＭのＲＡＭに記憶される情報の例を示す図である。ＲＡＭ１０２は、フィルター情報１２１、ダミーサブスクリプション１２２、リスナー情報１２３、サブスクリプション個別情報１２４、サブスクリプションビットマップ１２５および更新管理情報１２６を記憶する。

【0083】

フィルター情報１２１は、Indication機能による通知対象として設定可能な事象の一覧を示す情報である。当該事象の例としては、前述のように、ストレージ装置１０における論理ボリュームの新規登録などが挙げられる。フィルター情報１２１は、例えば、ＸＭＬ（Extensible Markup Language）を用いたモデルパス形式と呼ばれる記述形式を用いて表される。また、フィルター情報１２１の内容は、ストレージ装置１０のファームウェアにより予め定められる。フィルター情報１２１の内容は、ファームウェアの版数に応じて異なることもある。

【0084】

ダミーサブスクリプション１２２は、サブスクリプションの記述に用いられる情報である。ダミーサブスクリプション１２２は、モデルパス形式で表される。ここで、サブスクリプションは、フィルター固有の記述部分と、リスナー固有の記述部分とを含む。ダミーサブスクリプション１２２は、サブスクリプションにおけるフィルター固有の記述部分である。ダミーサブスクリプション１２２は、リスナー固有の所定の情報（リスナー名や登録時刻の情報など）に置換するためのプレースホルダを含む。プレースホルダは、所定のキーワード形式で表される。本例では、キーワード形式は、“％ｘ％”のように“％”（パーセント記号）で文字列を括る記述形式である。ダミーサブスクリプション１２２は、フィルター数分存在する。

【0085】

リスナー情報１２３は、通知先サーバのＩＰアドレスおよびリスナー名の対応関係を示す情報である。リスナー情報１２３は、モデルパス形式で表される。リスナー情報１２３のレコードは、リスナー数分作成される。リスナー情報１２３のレコードは、サーバ２００，３００，４００からの更新要求に応じて、更新または削除される。

【0086】

サブスクリプション個別情報１２４は、リスナー名およびサブスクリプション登録時間の対応関係を示す情報である。サブスクリプション個別情報１２４のレコードは、サブスクリプション数（リスナー名とフィルターとの組の数）分作成される。サブスクリプション個別情報１２４のレコードは、サーバ２００，３００，４００からの更新要求に応じて、通知制御部１１１により更新または削除される。

【0087】

サブスクリプションビットマップ１２５は、リスナー名とフィルターとのマッピング情報である。サブスクリプションビットマップ１２５は、リスナー数分作成される。サブスクリプションビットマップ１２５は、ビットマップ形式で表される。サブスクリプションビットマップ１２５は、サーバ２００，３００，４００からの更新要求に応じて、通知制御部１１１により更新または削除される。

【0088】

更新管理情報１２６は、Indication情報に関する更新を管理するための情報である。更新管理情報１２６は、リスナー毎のIndication情報の最終更新時刻、および、更新間隔を含む。

【0089】

最終更新時刻は、該当のリスナーによるIndication情報の最終の更新時刻（最新の更新時刻）である。該当のリスナーによるIndication情報の更新要求を受信した最終の時刻（最終受信時刻）を最終更新時刻とみなしてもよい。最終更新時刻は、リスナー数分登録される。最終更新時刻は、サーバ２００，３００，４００からの更新要求に応じて、通知制御部１１１により更新または削除される。

【0090】

更新間隔は、該当のリスナーによるIndication情報の更新間隔である。更新間隔に設定される値は、過去に計測された更新間隔のうちの最大値とする。更新間隔は、リスナー数分登録される。更新間隔は、サーバ２００，３００，４００からの更新要求に応じて、通知制御部１１１により更新または削除される。

【0091】

また、更新管理情報１２６は、リポジトリ更新フラグを含む。リポジトリ更新フラグは、Indication情報の全体に対する更新有無を示すフラグである。リポジトリ更新フラグ“ＴＲＵＥ”は、前回バックアップ時点から更新があることを示す。リポジトリ更新フラグ“ＦＡＬＳＥ”は、前回バックアップ時点から更新がないことを示す。リポジトリ更新フラグは、サーバ２００，３００，４００によるIndication情報の更新に応じて、通知制御部１１１により“ＴＲＵＥ”に設定される。リポジトリ更新フラグは、Indication情報のバックアップ完了時に、ＢＵＤ制御部１１２により“ＦＡＬＳＥ”に設定される。

【0092】

次に、図７で例示した各情報のデータ構造を具体的に説明する。
図８は、フィルター情報の例を示す図である。フィルター情報１２１は、フィルター番号および通知対象事象の項目を含む。フィルター番号の項目には、フィルターを識別する番号が登録される。通知対象事象の項目には、通知対象の事象の内容が登録される。

【0093】

例えば、フィルター情報１２１には、フィルター番号が“１”、通知対象事象が“ＲＡＩＤグループまたはシンプロプール登録完了時”という情報が登録されている。これは、フィルター番号“１”で示される通知対象事象が、ＲＡＩＤグループまたはシンプロプールの登録完了という事象であることを示す。ここで、「シンプロ」は、シンプロビジョニングの略である。「シンプロプール」は、サーバ２００，３００，４００の共有のストレージリソースの集合体である。「シンプロプールの登録完了」は、ストレージ装置１０において、新たなシンプロプールが登録されたことである。

【0094】

新たなＲＡＩＤグループや新たなシンプロプールの登録の結果、サーバ２００，３００，４００は新たなストレージリソースを利用可能になる。サーバ２００，３００，４００は当該事象に対する通知を受信することで、新たなストレージリソースが利用可能になったことを検出でき、ユーザへの通知などを行える。

【0095】

フィルター情報１２１には、「ボリュームの登録完了時」や、「コピーセッションの状態変更時」などの事象も登録されている。
図９は、ダミーサブスクリプションの例を示す図である。ダミーサブスクリプション１２２は、ＸＭＬ形式のデータである。ダミーサブスクリプション１２２は、フィルター（８〜１２行目の記述）、通知先のリスナー（１３〜１６行目の記述）および通知ポリシー（１７〜１９行目の記述）などの定義を含む。ただし、リスナー名の記述箇所（１４行目）は、キーワード“％ａ％”が設定されている。

【0096】

また、ダミーサブスクリプション１２２は、該当のリスナーによるサブスクリプションの更新時刻（２０行目）および適用開始時刻（２１行目）を含む。これらの時刻の記述箇所は、キーワード“％ｂ％”が設定されている。

【0097】

このように、ダミーサブスクリプション１２２は、フィルター固有の記述を含み、リスナー固有の記述箇所（リスナー名、更新時刻および適用開始時刻）に設定されたキーワードを含む。キーワードは、フィルター（ダミーサブスクリプション）毎に異なる。

【0098】

ダミーサブスクリプション１２２は、フィルターの識別情報（例えば、前述のフィルター番号）に対応付けられて、ＲＡＭ１０２に格納される。また、ダミーサブスクリプション１２２の記述は、フィルターに対して予め定められた記述となる。このため、通知制御部１１１は、ダミーサブスクリプション１２２を、フィルター情報１２１に基づいて生成可能である。

【0099】

図１０は、リスナー情報の例を示す図である。ここでは、リスナー情報１２３は、ＸＭＬ形式のデータである。リスナー情報１２３は、リスナー名（１４行目）、および、リスナーのＩＰアドレス（１５行目）の定義を含む。１つのリスナーに対応する情報がリスナー情報１２３の１レコードに相当する。

【0100】

ここで、サーバ２００のリスナー名を“Ｌｉｓｔｅｎｅｒ１”とする。サーバ３００のリスナー名を“Ｌｉｓｔｅｎｅｒ２”とする。サーバ４００のリスナー名を“Ｌｉｓｔｅｎｅｒ３”とする。リスナー名は、サーバ２００，３００，４００に対して予め与えられる。

【0101】

図１１は、サブスクリプション個別情報の例を示す図である。サブスクリプション個別情報１２４は、キーワード識別子および値の項目を含む。キーワード識別子の項目には、ダミーサブスクリプションに設定されたキーワードの識別子（キーワード識別子と称する）が登録される。キーワード識別子は、リスナーを区別する情報（例えば、“Ｌ１”のように“Ｌ”の文字と数値との組）と、キーワードとの結合（例えば、“Ｌ１％ａ％”）により表される。キーワード識別子におけるリスナーを区別する情報の部分により、ダミーサブスクリプション１２２に含まれる各キーワードの設定値の組が特定される。値の項目には、該当のキーワード識別子に対応する設定値が登録される。

【0102】

例えば、サブスクリプション個別情報１２４には、キーワード識別子が“Ｌ１％ａ％”、値が“Ｌｉｓｔｅｎｅｒ１”という情報が登録されている。また、サブスクリプション個別情報１２４には、キーワード識別子が“Ｌ１％ｂ％”、値が“２０１６０６３００６０５１０．１１６６６６＋０００”という情報が登録されている。これらは、ダミーサブスクリプション１２２のキーワード“％ａ％”および“％ｂ％”に設定される値の組である。すなわち、キーワード“％ａ％”を“Ｌｉｓｔｅｎｅｒ１”に置換し、キーワード“％ｂ％”を“２０１６０６３００６０５１０．１１６６６６＋０００”に置換することを示す。この値の組を表す情報は、サブスクリプション個別情報１２４の１つのレコードに相当する。

【0103】

例えば、サブスクリプション個別情報１２４には、ダミーサブスクリプション１２２に設定する別の値の組（例えば、キーワード識別子“Ｌ２％ａ％”および“Ｌ２％ｂ％”に対応する値の組）も登録されている。また、サブスクリプション個別情報１２４には、他のダミーサブスクリプションについても、同様に、キーワード識別子と値との対応関係が登録される。

【0104】

図１２は、サブスクリプションビットマップの例を示す図である。サブスクリプションビットマップ１２５は、ビットマップ１２５ａ，１２５ｂ，１２５ｃを含む。ビットマップ１２５ａは、サーバ２００に対するサブスクリプションビットマップであり、リスナー名“Ｌｉｓｔｅｎｅｒ１”に対応付けられている。ビットマップ１２５ｂは、サーバ３００に対するサブスクリプションビットマップであり、リスナー名“Ｌｉｓｔｅｎｅｒ２”に対応付けられている。ビットマップ１２５ｃは、サーバ４００に対するサブスクリプションビットマップであり、リスナー名“Ｌｉｓｔｅｎｅｒ３”に対応付けられている。

【0105】

ビットマップ１２５ａ，１２５ｂ，１２５ｃの各桁は、フィルター番号に対応付けられている。例えば、最上位の桁から最下位の桁へ向かって、順に、フィルター番号“１”、“２”、“３”、・・・と、フィルター番号の昇順に対応付けられている。ある桁のビットの値が“１”のとき、該当のフィルター番号に対応する事象のIndication機能による通知を行うことを示す。また、ある桁のビットの値が“０”のとき、該当のフィルター番号に対応する事象のIndication機能による通知を行わないことを示す。ビットマップ１２５ａ，１２５ｂ，１２５ｃの各ビットの初期値は“０”である。

【0106】

また、ビットマップ１２５ａ，１２５ｂ，１２５ｃの桁数は、ファームウェアのバージョンによって固定である。ファームウェアのバージョンが変わると、フィルター数も変わり得るため、ビットマップ１２５ａ，１２５ｂ，１２５ｃの桁数も変わり得る。

【0107】

例えば、ビットマップ１２５ａの例では、フィルター番号“１”に対応する桁のビット値は“１”である。これは、サーバ２００に対して、フィルター番号“１”に対応する事象の通知を行うことを示す。

【0108】

また、ビットマップ１２５ａの例では、フィルター番号“６”に対応する桁のビット値は“０”である。これは、サーバ２００に対して、フィルター番号“６”に対応する事象の通知を行わないことを示す。

【0109】

図１３は、更新管理情報の例を示す図である。更新管理情報１２６は、項目名および値の項目を含む。項目名の項目には、更新管理用の設定値の名称が登録される。値の項目には、設定値が登録される。

【0110】

例えば、更新管理情報１２６には、項目名“リポジトリ更新フラグ”に対して、値“ＴＲＵＥ”が登録されている。これは、リポジトリ更新フラグの設定値が“ＴＲＵＥ”であることを示す。

【0111】

また、更新管理情報１２６には、項目名“Ｌｉｓｔｅｎｅｒ１ 最終更新時刻”に対して、値“１０：００：０４．３１２”という情報が登録されている。これは、サーバ２００によるIndication情報の最終更新時刻が、１０時００分０４秒３１２であることを示す。

【0112】

また、更新管理情報１２６には、項目名“Ｌｉｓｔｅｎｅｒ１ 更新間隔（ｍｓｅｃ）”に対して、値“２０３５”という情報が登録されている。これは、サーバ２００によるIndication情報の更新間隔が２０３５ミリ秒（ｍｓｅｃ）であることを示す。

【0113】

更新管理情報１２６には、他のリスナーについてもサーバ２００と同様に、最終更新時刻および更新間隔が登録される。なお、更新間隔の設定値“０”は、無効値を表す。
図１４は、一連の更新要求の受信例を示す図である。ＳＭＩ−Ｓの規約により、通知制御部１１１は、次のように更新要求を受信する。第１に、各サーバからの１つの更新要求は、１つのリスナーの登録または１つのサブスクリプションの登録に対応する。このため、あるリスナーから複数のサブスクリプションの登録を受け付ける場合、通知制御部１１１は、複数の更新要求を受信する。

【0114】

第２に、通常はリスナー毎に、連続してリスナー、および、サブスクリプションの登録が行われる。
第３に、リスナー毎の更新要求の受信間隔は、各サーバのマシン性能や各サーバの通信に用いられるネットワーク性能に依存する。このため、通知制御部１１１は、リスナー毎に、ほぼ等間隔に、更新要求を受信すると予想される。

【0115】

第４に、更新要求の発行元のサーバが複数存在する場合は、通知制御部１１１は、複数のサーバにより発行された更新要求を、ある時間帯に並行して受信することもある。
例えば、ある時間帯において、通知制御部１１１は、サーバ２００（Ｌｉｓｔｅｎｅｒ１）およびサーバ３００（Ｌｉｓｔｅｎｅｒ２）からIndication情報に対する一連の更新要求を受信する。図１４中、左側から右側へ向かう方向が時間軸の正方向である。

【0116】

更新要求６１，６２，６３，６４は、通知制御部１１１が、この順で、サーバ２００から受信した一連の更新要求である。更新要求７１，７２，７３，７４は、通知制御部１１１が、この順で、サーバ３００から受信した一連の更新要求である。各更新要求は、送信元のサーバに対応するリスナー名の情報やIndication情報に対する更新内容を示す情報を含む。

【0117】

例えば、更新要求６１は、サーバ２００に関するリスナー登録の要求である。更新要求６２は、更新要求６１に後続する１番目のフィルター登録（通知対象とするフィルターの追加）の要求である。更新要求６３は、２番目のフィルター登録の要求である。更新要求６４は、３番目のフィルター登録の要求である。

【0118】

また、例えば、更新要求７１は、サーバ３００に関するリスナー登録の要求である。更新要求７２は、更新要求７１に後続する１番目のフィルター登録の要求である。更新要求７３は、２番目のフィルター登録の要求である。更新要求７４は、３番目のフィルター登録の要求である。

【0119】

なお、通知制御部１１１は、既存のフィルターに関するフィルター登録や通知解除（フィルター解除）の更新要求を受信することもある。既存のリスナーがフィルター登録やフィルター（解除）の更新要求を送信する場合、当該更新要求の前に、当該リスナーは、リスナー登録の更新要求を送信しなくてよい。

【0120】

また、リスナー毎のフィルター登録やフィルター解除の更新要求は、サブスクリプションに関する更新要求であるともいえる。
図１４の例では、時系列に並ぶ時刻Ｔ１１，Ｔ１２，Ｔ１３，Ｔ１４，Ｔ１５，Ｔ１６が例示されている。時刻Ｔ１１は、更新要求６２の受信時刻である。時刻Ｔ１２は、更新要求７２の受信時刻である。時刻Ｔ１３は、更新要求６３の受信時刻である。時刻Ｔ１４は、更新要求７３の受信時刻である。時刻Ｔ１５は、更新要求６４の受信時刻である。時刻Ｔ１６は、更新要求７４の受信時刻である。

【0121】

この場合、時刻Ｔ１６において、通知制御部１１１が観測する各リスナーの更新間隔、および、最終更新時刻は次の通りである。
サーバ２００（Ｌｉｓｔｅｎｅｒ１）について、更新要求６２，６３の受信間隔は、更新要求６１，６２の受信間隔および更新要求６３，６４の受信間隔より長い。よって、サーバ２００による更新間隔Δｔ１０は、Δｔ１０＝Ｔ１３−Ｔ１１である。また、サーバ２００による最終更新時刻は、時刻Ｔ１５である。

【0122】

サーバ３００（Ｌｉｓｔｅｎｅｒ２）について、更新要求７２，７３の受信間隔は、更新要求７１，７２の受信間隔および更新要求７３，７４の受信間隔より長い。よって、サーバ３００による更新間隔Δｔ２０は、Δｔ２０＝Ｔ１４−Ｔ１２である。また、サーバ３００による最終更新時刻は、時刻Ｔ１６である。

【0123】

次に、ＣＭ１００による処理手順を説明する。まず、通知制御部１１１によりサーバ２００からIndication情報の更新要求を受信する処理（更新要求受信処理）の手順を説明する。その後に、ＢＵＤ制御部１１２によりIndication情報のバックアップを取得する処理（ポーリングチェック処理）の手順を説明する。

【0124】

図１５は、更新要求受信処理の例を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。
（Ｓ１１）通知制御部１１１は、Indication情報の更新要求を何れかのサーバから受信する。

【0125】

（Ｓ１２）通知制御部１１１は、受信した更新要求が、リスナーの登録に関する更新要求であるか否かを判定する。リスナーの登録に関する更新要求である場合、処理をステップＳ１３に進める。リスナーの登録に関する更新要求でない場合（すなわち、登録済リスナーによるサブスクリプションに関する更新要求である場合）、処理をステップＳ１４に進める。

【0126】

（Ｓ１３）通知制御部１１１は、リスナー情報更新処理を行う。リスナー情報更新処理の詳細は後述される。そして、通知制御部１１１は、処理を終了する。
（Ｓ１４）通知制御部１１１は、サブスクリプション更新処理を行う。サブスクリプション更新処理の詳細は後述される。そして、通知制御部１１１は、処理を終了する。

【0127】

図１６は、リスナー情報更新処理の例を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１５のステップＳ１３に相当する。

【0128】

（Ｓ２１）通知制御部１１１は、リスナーの登録に関する更新要求（リスナー名やＩＰアドレスを含む）に応じて、ＲＡＭ１０２に記憶されたリスナー情報１２３の設定内容を更新する。具体的には、通知制御部１１１は、新規のリスナー設定（リスナー名およびリスナーのＩＰアドレスを含む）をリスナー情報１２３に追加する。また、通知制御部１１１は、該当のリスナーに対するサブスクリプションビットマップ（全ビットを初期値０とする）を作成し、ＲＡＭ１０２に格納する。

【0129】

（Ｓ２２）通知制御部１１１は、ＲＡＭ１０２に記憶された更新管理情報１２６における該当のリスナーの最終更新時刻に現在時刻を設定する。
（Ｓ２３）通知制御部１１１は、更新管理情報１２６における該当のリスナーの更新間隔に初期値０を設定する。

【0130】

（Ｓ２４）通知制御部１１１は、更新管理情報１２６におけるリポジトリ更新フラグをＴＲＵＥに設定する。なお、リポジトリ更新フラグが既にＴＲＵＥの場合、通知制御部１１１は、上書きでＴＲＵＥを設定する。

【0131】

（Ｓ２５）通知制御部１１１は、更新要求元のサーバに更新完了を応答する。
なお、通知制御部１１１は、リスナーの更新に関する更新要求として、新規のリスナー設定の追加だけでなく、既存のリスナー設定の更新の要求を受け付けてもよい。その場合、通知制御部１１１は、リスナー情報１２３に対するリスナー設定の更新を行った後（ステップＳ２１におけるビットマップ作成は行わなくてよい）、ステップＳ２２を実行し、ステップＳ２３をスキップして、ステップＳ２４に進める。

【0132】

図１７は、サブスクリプション更新処理の例を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１５のステップＳ１４に相当する。

【0133】

（Ｓ３１）通知制御部１１１は、サブスクリプションに関する更新要求に応じて、ＲＡＭ１０２に記憶されたサブスクリプション個別情報１２４およびサブスクリプションビットマップ１２５を更新する。具体的には、更新要求はリスナー名および通知を受けるフィルターを指定する情報を含む。通知制御部１１１は、指定されたフィルターに対応するダミーサブスクリプションを特定する。通知制御部１１１は、特定したダミーサブスクリプションに含まれる第１のキーワードに対応する第１のキーワード識別子とリスナー名とを、サブスクリプション個別情報１２４に登録する。また、通知制御部１１１は、特定したダミーサブスクリプションに含まれる第２のキーワードに対応する第２のキーワード識別子と更新時刻や適用開始時刻として設定する時刻とを、サブスクリプション個別情報１２４に登録する。更に、通知制御部１１１は、該当のリスナーに対応するサブスクリプションビットマップの指定されたフィルターに対応するビットを“１”に設定する。

【0134】

（Ｓ３２）通知制御部１１１は、ＲＡＭ１０２に記憶された更新管理情報１２６を参照して、該当のリスナーによるIndication情報の最終更新時刻から５分以上経過しているか否かを判定する。５分以上経過している場合、処理をステップＳ３５に進める。５分以上経過していない場合、処理をステップＳ３３に進める。

【0135】

（Ｓ３３）通知制御部１１１は、更新管理情報１２６を参照して、該当のリスナーの最終更新時刻から現時刻までの経過時間が、該当のリスナーに対して記録済の更新間隔より大きいか否かを判定する。大きい場合、処理をステップＳ３４に進める。大きくない場合、処理をステップＳ３５に進める。

【0136】

（Ｓ３４）通知制御部１１１は、該当のリスナーの最終更新時刻から現時刻までの経過時間を、更新管理情報１２６における当該リスナーの更新間隔に設定する。
（Ｓ３５）通知制御部１１１は、更新管理情報１２６における該当のリスナーの最終更新時刻に現在時刻を設定する。

【0137】

（Ｓ３６）通知制御部１１１は、更新管理情報１２６におけるリポジトリ更新フラグをＴＲＵＥに設定する。なお、リポジトリ更新フラグが既にＴＲＵＥの場合、通知制御部１１１は、上書きでＴＲＵＥを設定する。そして、処理を終了する。

【0138】

なお、通知制御部１１１は、ステップＳ３２に示されるように、経過時間が５分以上である場合には、該当のリスナーについて更新間隔の更新を行わない。この場合のIndication情報の更新は、別シーケンス（サブスクリプションの削除など）による更新であると考えられるためである。

【0139】

また、通知制御部１１１は、ステップＳ３３で示されるように、最終更新時刻からの経過時間が、記録済の更新間隔よりも大きい場合に、当該更新間隔を、今回の更新間隔で上書きする。すなわち、一連の更新間隔のうちの最大の更新間隔を、該当のサーバによる更新間隔とする。これにより、後述のポーリングチェック処理において、該当のサーバによる一連の更新要求の受信が完了したタイミングを適切に特定可能になる。

【0140】

更に、通知制御部１１１は、ストレージ装置１０において、フィルター情報１２１に登録された事象を検出すると、ＲＡＭ１０２に記憶されたサブスクリプションビットマップ１２５を参照し、該当の事象に対応するIndication通知の対象リスナーを確認する。通知制御部１１１は、リスナー情報１２３を参照して、対象リスナーのＩＰアドレスを特定し、Indication通知の処理を行う。このとき、通知制御部１１１は、サブスクリプションビットマップ１２５を用いてIndication通知の対象リスナーを検索することで、リスナーの検索を高速に行える。

【0141】

図１８は、ＢＵＤに書き込まれる情報／書き込まれない情報の例を示す図である。ＣＭ１００は、図７に例示した情報のうち、フィルター情報１２１、リスナー情報１２３、サブスクリプション個別情報１２４およびサブスクリプションビットマップ１２５を、ＢＵＤ１０３に書き込んでバックアップする。

【0142】

ここで、サポートされるフィルター一覧は、ストレージ装置１０のファームウェア（あるいは、ＣＭ１００のファームウェア）のバージョンによって異なる。このため、ＢＵＤ制御部１１２は、サブスクリプションビットマップ１２５に対応するフィルター情報１２１をＢＵＤ１０３への書き込み対象とする。

【0143】

一方、ダミーサブスクリプション１２２は、フィルター情報１２１から再構築可能である。このため、ダミーサブスクリプション１２２は、ＢＵＤ１０３への書き込み対象外である。また、更新管理情報１２６は、バックアップの実行制御用であり、Indication機能には用いられない。このため、更新管理情報１２６は、ＢＵＤ１０３への書き込み対象外である。

【0144】

図１９は、ポーリングチェック処理の例を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。ＢＵＤ制御部１１２は、以下の手順を、所定の周期（例えば、５秒周期とする）で実行する。

【0145】

（Ｓ４１）ＢＵＤ制御部１１２は、ＲＡＭ１０２に記憶された更新管理情報１２６を参照して、リポジトリ更新フラグがＴＲＵＥであるか否かを判定する。ＴＲＵＥの場合、処理をステップＳ４２に進める。ＴＲＵＥでない場合（すなわち、ＦＡＬＳＥの場合）、処理を終了する。

【0146】

（Ｓ４２）ＢＵＤ制御部１１２は、更新管理情報１２６を参照して、最終更新時刻からの経過時間が５分以上のリスナーがあるか否かを判定する。最終更新時刻からの経過時間が５分以上のリスナーがある場合、処理をステップＳ４４に進める。最終更新時刻からの経過時間が５分以上のリスナーがない場合、処理をステップＳ４３に進める。

【0147】

（Ｓ４３）ＢＵＤ制御部１１２は、更新管理情報１２６を参照して、最終更新時刻からの経過時間が更新間隔以下のリスナーがあるか否かを判定する。最終更新時刻からの経過時間が更新間隔以下のリスナーがある場合、処理を終了する（バックアップを延期する）。最終更新時刻の経過時間が更新間隔以下のリスナーがない場合（すなわち、更新管理情報１２６に記録された全てのリスナーについて、最終更新時刻からの経過時間が更新間隔より大きい場合）、処理をステップＳ４４に進める。

【0148】

なお、更新間隔に無効値（０秒）が設定されているリスナーも存在し得る。この場合、ＢＵＤ制御部１１２は、該当のリスナーについて、最終更新時刻からの経過時間が５秒（＝ポーリングチェック周期）以下の場合に、「最終更新時刻からの経過時間が更新間隔以下のリスナー」とみなす。一方、ＢＵＤ制御部１１２は、該当のリスナーについて、最終更新時刻からの経過時間が５秒より大きい場合に、「最終更新時刻からの経過時間が更新間隔より大きいリスナー」とみなす。

【0149】

（Ｓ４４）ＢＵＤ制御部１１２は、ＲＡＭ１０２に記憶されたフィルター情報１２１、リスナー情報１２３、サブスクリプション個別情報１２４およびサブスクリプションビットマップ１２５を複製することでバックアップデータを生成し、ＢＵＤ１０３に書き込む。すなわち、ＢＵＤ制御部１１２は、Indication情報のバックアップを実行する。

【0150】

（Ｓ４５）ＢＵＤ制御部１１２は、更新管理情報１２６におけるリポジトリ更新フラグをＦＡＬＳＥに設定する。更新管理情報１２６におけるリスナー毎の最終更新時刻および更新間隔の値はＲＡＭ１０２上に保持される。そして、処理を終了する。

【0151】

ここで、ステップＳ４２の判定を行う理由は、あるリスナーからIndication情報が継続的に更新されるなどして、別のリスナーによる更新完了後に、当該別のリスナーによる更新内容がバックアップされるまでに時間がかかるおそれがあるからである。バックアップまでに時間がかかると、停電等によって該当の更新内容が失われるリスクも高まる。そこで、最終更新時刻から５分以上経過したリスナーが存在する場合は、ＢＵＤ制御部１１２は、Indication情報のバックアップを直ちに実行する。

【0152】

このように、ＢＵＤ制御部１１２は、各サーバについて更新要求の受信間隔よりも最終更新時刻からの経過時間の方が長い場合にIndication情報のバックアップを開始する。また、ＢＵＤ制御部１１２は、少なくとも１つのサーバについて更新要求の受信間隔よりも最終更新時刻からの経過時間の方が長くない場合にIndication情報のバックアップの開始を延期する。

【0153】

図２０は、ポーリングチェックの例を示す図である。以下の例では、ポーリングチェックの周期を５秒とする。１０時００分００秒の時点の更新管理情報１２６ａ（初期状態）は、リポジトリ更新フラグ＝ＦＡＬＳＥを含む。１０時００分００秒のタイミングで、ＢＵＤ制御部１１２は、ポーリングチェックを実行する。リポジトリ更新フラグ＝ＦＡＬＳＥなので（ステップＳ４１ Ｎｏ）、ＢＵＤ制御部１１２は、バックアップを延期する。

【0154】

１０時００分０１秒に、通知制御部１１１は、サーバ２００からの更新要求に応じて、サーバ２００のリスナー登録を行う。そして、通知制御部１１１は、リポジトリ更新フラグをＴＲＵＥに設定する。通知制御部１１１は、サーバ２００のリスナー名“Ｌｉｓｔｅｎｅｒ１”に対して、最終更新時刻“１０：００：０１．０００”および更新間隔“０（無効値）”を更新管理情報１２６ａに登録する。更新管理情報１２６ｂは、当該登録後の状態を示す。

【0155】

１０時００分０２秒に、通知制御部１１１は、サーバ２００からの更新要求に応じて、サーバ２００に対してフィルター番号“１”（フィルター１）の登録を行う。この場合、通知制御部１１１は、更新管理情報１２６ｂにおいて、サーバ２００のリスナー名“Ｌｉｓｔｅｎｅｒ１”に対し、最終更新時刻“１０：００：０２．０００”および更新間隔“１０００”（ｍｓｅｃ）を登録する。更新管理情報１２６ｃは、当該登録後の状態を示す。

【0156】

１０時００分０３秒に、通知制御部１１１は、サーバ３００からの更新要求に応じて、サーバ３００のリスナー登録を行う。通知制御部１１１は、サーバ３００のリスナー名“Ｌｉｓｔｅｎｅｒ２”に対して、最終更新時刻“１０：００：０３．０００”および更新間隔“０（無効値）”を更新管理情報１２６ｃに登録する。更新管理情報１２６ｄは、当該登録後の状態を示す。

【0157】

図２１は、ポーリングチェックの例（続き）を示す図である。１０時００分０４秒に、通知制御部１１１は、サーバ２００からの更新要求に応じて、サーバ２００に対してフィルター番号“２”（フィルター２）の登録を行う。この場合、通知制御部１１１は、更新管理情報１２６ｄにおいて、サーバ２００のリスナー名“Ｌｉｓｔｅｎｅｒ１”に対し、最終更新時刻“１０：００：０４．０００”および更新間隔を“２０００”（ｍｓｅｃ）を登録する。更新管理情報１２６ｅは、当該登録後の状態を示す。

【0158】

１０時００分０５秒のタイミングで、ＢＵＤ制御部１１２は、ポーリングチェックを実行する。更新管理情報１２６ｅによれば、リポジトリ更新フラグ＝ＴＲＵＥである（ステップＳ４１ Ｙｅｓ）。また、最終更新時刻から５分以上経過しているリスナーはない（ステップＳ４２ Ｎｏ）。

【0159】

ただし、サーバ２００（Ｌｉｓｔｅｎｅｒ１）は、最終更新時刻（１０：００：０４．０００）から更新間隔分（２０００ｍｓｅｃ）が経過していない。また、サーバ３００（Ｌｉｓｔｅｎｅｒ２）は、最終更新時刻（１０：００：０３．０００）から５秒経過していない（ステップＳ４３ Ｙｅｓ）。このため、ＢＵＤ制御部１１２は、今回タイミングでのバックアップを延期する。

【0160】

１０時００分０６秒に、通知制御部１１１は、サーバ３００からの更新要求に応じて、サーバ３００に対してフィルター番号“６”（フィルター６）の登録を行う。この場合、通知制御部１１１は、更新管理情報１２６ｅにおいて、サーバ３００のリスナー名“Ｌｉｓｔｅｎｅｒ２”に対し、最終更新時刻“１０：００：０６．０００”および更新間隔“３０００”（ｍｓｅｃ）を登録する。更新管理情報１２６ｆは、当該登録後の状態を示す。

【0161】

図２２は、ポーリングチェックの例（続き）を示す図である。１０時００分０９秒に、通知制御部１１１は、サーバ３００からの更新要求に応じて、サーバ３００に対してフィルター番号“７”（フィルター７）の登録を行う。この場合、通知制御部１１１は、更新管理情報１２６ｆにおいて、サーバ３００のリスナー名“Ｌｉｓｔｅｎｅｒ２”に対し、最終更新時刻“１０：００：０９．０００”および更新間隔“３０００”（ｍｓｅｃ）を登録する。更新管理情報１２６ｇは、当該登録後の状態を示す。

【0162】

１０時００分１０秒のタイミングで、ＢＵＤ制御部１１２は、ポーリングチェックを実行する。更新管理情報１２６ｇによれば、リポジトリ更新フラグ＝ＴＲＵＥである（ステップＳ４１ Ｙｅｓ）。また、最終更新時刻から５分以上経過しているリスナーはない（ステップＳ４２ Ｎｏ）。更に、サーバ２００（Ｌｉｓｔｅｎｅｒ１）は、最終更新時刻（１０：００：０４．００００）から更新間隔（２０００ｍｓｅｃ）以上経過している。

【0163】

ただし、サーバ３００（Ｌｉｓｔｅｎｅｒ２）は、最終更新時刻（１０：００：０９．０００）から更新間隔分（３０００ｍｓｅｃ）が経過していない（ステップＳ４３ Ｙｅｓ）。このため、ＢＵＤ制御部１１２は、今回タイミングでのバックアップを延期する。

【0164】

１０時００分１５秒のタイミングで、ＢＵＤ制御部１１２は、ポーリングチェックを実行する。更新管理情報１２６ｇによれば、リポジトリ更新フラグ＝ＴＲＵＥである（ステップＳ４１ Ｙｅｓ）。また、最終更新時刻から５分以上経過しているリスナーはない（ステップＳ４２ Ｎｏ）。更に、サーバ２００（Ｌｉｓｔｅｎｅｒ１）は、最終更新時刻（１０：００：０４．０００）から更新間隔（２０００ｍｓｅｃ）以上経過している。また、サーバ３００（Ｌｉｓｔｅｎｅｒ２）は、最終更新時刻（１０：００：０９．０００）から更新間隔（３０００ｍｓｅｃ）以上経過している（ステップＳ４３ Ｎｏ）。

【0165】

このため、ＢＵＤ制御部１１２は、Indication情報のバックアップを開始する（ステップＳ４４）。そして、ＢＵＤ制御部１１２は、バックアップが完了すると、更新管理情報１２６ｇにおけるリポジトリ更新フラグをＦＡＬＳＥに設定する（ステップＳ４５）。更新管理情報１２６ｈは、当該設定後の状態を示す。

【0166】

こうして、ＣＭ１００は、サーバ２００，３００，４００による更新が完了したと推定されるタイミングに絞ってバックアップを実行することで、バックアップの頻度を低減できる。

【0167】

ところで、バックアップの頻度が過多または過少であると、好ましくない影響をシステムに及ぼし得る。例えば、サーバ２００，３００，４００それぞれによる更新が行われるたびに、Indication情報のバックアップを取得することも考えられる。しかし、この方法では、バックアップの頻度が増えやすい。このため、バックアップに伴うＣＭ１００やＢＵＤ１０３などの負荷により、他の処理（例えば、ＣＭ１００やサーバ２００，３００，４００などによる本来の業務処理）に影響を及ぼす可能性がある。

【0168】

より具体的には、ＣＭ１００が更新要求に対する更新およびバックアップの実行後に更新要求に応答していると、バックアップ時間が要因となって更新要求に対する応答遅延が増し、ＣＭ１００やサーバ２００，３００，４００による次の処理の実行が遅延し得る。あるいは、バックアップデータの書き込み先のＢＵＤ１０３でリソースがロックされ、ＢＵＤ１０３にログ書き込みなどを行うサーバ２００，３００，４００上の業務処理で待ちが発生する可能性もある。

【0169】

一方、例えば、スケジュールされた時刻に、Indication情報のバックアップを実行することも考えられる。この方法では、更新要求のたびにバックアップを実行するよりもバックアップの頻度を減らせる。しかし、その反面、現在取得済のバックアップデータが、最新の状態のIndication情報に対応するバックアップデータでない可能性が高まる。この場合、バックアップデータからIndication情報を復旧しようとしたときに、Indication情報を最新の状態に戻せない可能性が高まり、Indication情報を適切に保全できないおそれがある。

【0170】

そこで、ＣＭ１００は、サーバ２００，３００，４００により発行される一連の更新要求の受信間隔（更新間隔）と最終の受信時刻（最終更新時刻）とを記録する。そして、ＣＭ１００は、サーバ２００，３００，４００それぞれによる一連の更新要求の発行が完了したと推定されるタイミングで、Indication情報のバックアップを開始する。

【0171】

これにより、バックアップの頻度を減らしながら、Indication情報の最新の状態に対応するバックアップデータを効率的に取得可能になる。ＣＭ１００は、複数のサーバのうち少なくとも１つのサーバによりIndication情報が更新中であると判断される間は、Indication情報のバックアップを保留する（バックアップを開始しない）。理由は次の通りである。

【0172】

例えば、サーバ３００によりIndication情報が更新中であるにも拘わらずバックアップデータを取得してしまうと、サーバ３００による、その後の更新が今回のバックアップデータに反映されない。ここで、あるサーバによる一連の更新要求のうち、最初の更新要求の受信時刻と最後の更新要求の受信時刻との時間差は、比較的短いことが多く、その短い間に停電などによりIndication情報が喪失される可能性は比較的低いと考えられる。このため、ＣＭ１００は、何れかのサーバがIndication情報を更新中である間は、バックアップデータの取得を控える。

【0173】

ただし、複数のサーバによるIndication情報の更新が重なると、各サーバによる更新が完了するまでの時間が長引く。このため、ＣＭ１００は、Indication情報に対する更新要求を同時に発行していた各サーバによるIndication情報の更新が完了したことを検出すると、直ちにIndication情報のバックアップを開始する。これにより、各サーバの更新に対し、より新しい状態のバックアップデータを比較的早いタイミングで取得できる。その結果、当該バックアップデータを用いて、各サーバにとって最新の状態で、Indicationを復元できる可能性を高められる。すなわち、バックアップの頻度の低減とバックアップによるデータ保全との両立を図れる。

【0174】

また、更新要求によるデータ更新とは非同期に決定されるタイミングでバックアップを実行することで、更新要求に対する応答時間を高速化できる。
なお、通知制御部１１１は、ユーザによる指示に応じて、リスナー毎のサブスクリプションを出力することもできる。

【0175】

図２３は、サブスクリプションの出力例を示す図である。図２３（Ａ）は、サーバ２００（Ｌｉｓｔｅｎｅｒ１）に対して出力されるサブスクリプション１２２ａを例示している。図２３（Ｂ）は、サーバ３００（Ｌｉｓｔｅｎｅｒ２）に対して出力されるサブスクリプション１２２ｂを例示している。

【0176】

例えば、通知制御部１１１は、サーバ２００への通知対象の事象に関するサブスクリプションの出力指示をサーバ２００から受信する。すると、通知制御部１１１は、Ｌｉｓｔｅｎｅｒ１に対応するビットマップ１２５ａを参照して、サーバ２００への通知対象のフィルター番号を特定する。そして、通知制御部１１１は、特定したフィルター番号に対応するダミーサブスクリプションを特定する。通知制御部１１１は、該当のダミーサブスクリプションのキーワードを、サブスクリプション個別情報１２４に登録された値により置換することで、サブスクリプションを生成する。例えば、通知制御部１１１は、ダミーサブスクリプション１２２に対して、サブスクリプション１２２ａを生成し、サーバ２００に送信する。

【0177】

通知制御部１１１は、サーバ３００に対しても同様にして、サブスクリプション１２２ｂを生成し、サーバ３００に送信することができる。
図２４は、ＢＵＤへの書き込み量の例を示す図である。ここで、一例として、リスナー数を３０、フィルター数を５０、リスナー情報１２３およびサブスクリプション個別情報１２４の１リスナー当たりのデータ量を６０バイト（Ｂｙｔｅｓ）とした場合を考える。この場合、ＢＵＤ制御部１１２により、１回のバックアップ実行当たりにＢＵＤ１０３に書き込まれるデータ量は、６０Ｂｙｔｅｓ×（３０×５０）＝９０，０００Ｂｙｔｅｓ程度である。なお、フィルター情報１２１やサブスクリプションビットマップ１２５のサイズは、リスナー情報１２３やサブスクリプション個別情報１２４の合計サイズに比べて小さいので、ここでは無視している。

【0178】

図２５は、ＢＵＤへの書き込み量の比較例を示す図である。ダミーサブスクリプション１２２、サブスクリプション個別情報１２４およびサブスクリプションビットマップ１２５を用いずに、ＣＭ１００が、サブスクリプションをリスナー毎に個別に保持する運用も考えられる。この場合、１リスナー当たりのサブスクリプションのデータ量は、例えば、１２００Ｂｙｔｅｓ程度に達する。ここで、図２４と同様に、管理対象のリスナー数を３０、フィルター数を５０とした場合を考える。この場合、全リスナーのサブスクリプションのバックアップデータのサイズは、１２００Ｂｙｔｅｓ×（３０×５０）＝１，８００，０００Ｂｙｔｅｓ程度となる。

【0179】

すなわち、第２の実施の形態のＣＭ１００によれば、ＢＵＤ１０３に書き込むバックアップデータのサイズを、図２５に示す比較例に比べて、１／２０程度に削減できることになる。このように、ＢＵＤ１０３に書き込むデータ量を削減することで、ＢＵＤ１０３として用いられるＳＳＤの長寿命化を図れる。また、更新要求のたびにバックアップデータをＢＵＤ１０３に書き込むよりも、書き込み回数を減らせるので、この点でもＢＵＤ１０３として用いられるＳＳＤの長寿命化に寄与する。

【0180】

更に、図２５に示す比較例の場合、書き込みデータ量が多く、リポジトリ内に分散して配置された各サブスクリプション（例では合計１５００個）をＢＵＤ１０３の連続域に書き込むためのシリアライズ処理や、ＢＵＤ１０３への書き込み処理に時間がかかる。これは、バックアップ処理の遅延要因になり得る。

【0181】

一方、第２の実施の形態では、ＢＵＤ制御部１１２は、サブスクリプションにおけるリスナー毎の固有情報をバックアップの対象とフィルター情報から生成可能な固定情報（ダミーサブスクリプション）をバックアップの対象から除外する。これにより、ＢＵＤ１０３への総書き込み量を抑えることができ、バックアップ処理の高速化も図れる。

【0182】

なお、第１の実施の形態の情報処理は、処理部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１１に記録できる。

【0183】

例えば、プログラムを記録した記録媒体１１を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１１に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＢＵＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。

【0184】

以上の第１，第２の実施の形態を含む実施形態に関し、更に以下の付記を開示する。
（付記１） 複数の上位装置により発行される更新要求に応じて更新されるデータのバックアップを行う制御装置であって、
前記更新要求の受信間隔と最終の受信時刻とを上位装置毎に記憶する記憶部と、
前記受信間隔と前記最終の受信時刻とを上位装置毎に前記記憶部に記録し、所定のタイミングで、前記最終の受信時刻から前記タイミングまでの経過時間と前記受信間隔とを上位装置毎に比較し、上位装置毎の比較結果に応じて前記バックアップを開始する処理部と、
を有する制御装置。

【0185】

（付記２） 前記処理部は、前記複数の上位装置それぞれについて前記受信間隔よりも前記経過時間の方が長い場合に前記バックアップを開始し、少なくとも１つの上位装置について前記受信間隔より前記経過時間の方が長くない場合に前記バックアップの開始を延期する、付記１記載の制御装置。

【0186】

（付記３） 前記処理部は、少なくとも１つの上位装置について前記受信間隔より前記経過時間の方が長くない場合でも、他の上位装置に関する前記経過時間が所定時間以上である場合は前記バックアップを開始する、付記２記載の制御装置。

【0187】

（付記４） 前記データは、前記複数の上位装置それぞれの固有情報と、他の情報から生成可能な固定情報とを含み、
前記処理部は、前記データのうち、前記固有情報を前記バックアップの対象とし、前記固定情報を前記バックアップの対象から除外する、
付記１乃至３の何れか１つに記載の制御装置。

【0188】

（付記５） 前記タイミングは、受信した前記更新要求に応じた前記データの更新とは非同期に決定されるタイミングである、付記１乃至４の何れか１つに記載の制御装置。
（付記６） 前記処理部は、前記バックアップでは、第１の記憶装置に記憶された前記データを基にバックアップデータを生成し、書き込み回数に制限のある記憶素子を備える第２の記憶装置に前記バックアップデータを格納する、付記１乃至５の何れか１つに記載の制御装置。

【0189】

（付記７） 複数の上位装置により発行される更新要求に応じて更新されるデータのバックアップの制御に用いられる制御プログラムであって、
前記更新要求の受信間隔と最終の受信時刻とを上位装置毎に記憶部に記録し、
所定のタイミングで、前記最終の受信時刻から前記タイミングまでの経過時間と前記受信間隔とを上位装置毎に比較し、
上位装置毎の比較結果に応じて前記バックアップを開始する、
処理をコンピュータに実行させる制御プログラム。

【0190】

（付記８） 前記バックアップの開始では、前記複数の上位装置それぞれについて前記受信間隔よりも前記経過時間の方が長い場合に前記バックアップを開始し、少なくとも１つの上位装置について前記受信間隔より前記経過時間の方が長くない場合に前記バックアップの開始を延期する、付記７記載の制御プログラム。

【0191】

（付記９） 前記バックアップの開始では、少なくとも１つの上位装置について前記受信間隔より前記経過時間の方が長くない場合でも、他の上位装置に関する前記経過時間が所定時間以上である場合は前記バックアップを開始する、付記８記載の制御プログラム。

【0192】

（付記１０） 前記データは、前記複数の上位装置それぞれの固有情報と、他の情報から生成可能な固定情報とを含み、
前記バックアップでは、前記データのうち、前記固有情報を前記バックアップの対象とし、前記固定情報を前記バックアップの対象から除外する、
付記７乃至９の何れか１つに記載の制御プログラム。

【0193】

（付記１１） 前記タイミングは、受信した前記更新要求に応じた前記データの更新とは非同期に決定されるタイミングである、付記７乃至１０の何れか１つに記載の制御プログラム。

【0194】

（付記１２） 前記バックアップでは、第１の記憶装置に記憶された前記データを基にバックアップデータを生成し、書き込み回数に制限のある記憶素子を備える第２の記憶装置に前記バックアップデータを格納する、付記７乃至１１の何れか１つに記載の制御プログラム。

【符号の説明】

【0195】

１ 制御装置
１ａ 記憶部
１ｂ 処理部
２，３ 上位装置
４，５ 記憶装置
６ ネットワーク
Ｄ１ データ
Ｄ２ バックアップデータ
Ｘ１ テーブル

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】