JP2013156764A - 制御システム及びログ配信方法 - Google Patents

Abstract

【課題】有用なログを失うことを防止すること。
【解決手段】演算処理装置と該演算処理装置のログを記憶する記憶部をそれぞれ有する制御装置を複数備える制御システムは、第１の生成部と、第２の生成部と、配信部と、を有する。第１の生成部は、各制御装置の記憶部に記憶された演算処理装置の複数のログを、制御システム内の演算処理装置の総数に基づいて決定されるログの容量の上限値の範囲内で、かつ、優先度に基づいた順序で格納して第１のログファイルを生成する。第２の生成部は、各演算処理装置における第１のログファイルを複数含んだ第２のログファイルを生成する。配信部は、該第２のログファイルを外部装置へ配信する。
【選択図】図２

Description

本発明は、制御システム及びログ配信方法に関する。

従来、ストレージ装置は、装置内の障害情報などのログをログファイルとして定期的に配信する定期ログ配信機能を有する場合がある。例えば、定期ログ配信機能を有するストレージ装置は、データを格納しているディスクなどの搭載部品の故障や故障の予兆を監視してログを採取し、採取したログからログファイルを生成する。そして、ストレージ装置は、ネットワークを介して、リモートサポートセンターと呼ばれる保守センターにログファイルを配信する。

図２０を用いて、ストレージ装置が有する定期ログ配信機能について説明する。図２０は、ストレージ装置が有する定期ログ配信機能の一例を示す図である。図２０に示すストレージ装置９１０〜ストレージ装置９３０のそれぞれは、定期ログ配信機能を有しており、ネットワークを介してリモートサポートセンター９００に接続される。なお、図２０に示す例では、ストレージ装置９１０及びストレージ装置９２０は、定期ログ配信機能を有効に設定しており、ストレージ装置９３０は、定期ログ配信機能を無効に設定しているものとする。

ストレージ装置９１０は、ログを採取することで生成したログファイル９４０を１日ごとにリモートサポートセンター９００に配信する。また、ストレージ装置９２０は、ログを採取することで生成したログファイル９５０を１週ごとにリモートサポートセンター９００に配信する。そして、リモートサポートセンター９００では、管理者が、ログファイルを解析することによって、ストレージ装置９１０〜ストレージ装置９３０の異常や故障の予兆を示す警告の有無を検出する。

次に、図２１を用いて、ストレージ装置によるログ採取処理について説明する。図２１は、ストレージ装置によるログ採取処理の一例を示す図である。図２１に示すように、ストレージ装置９１０は、内部に８つのＣＭ（Controller Module、以降、ＣＭと記載する）＃０〜ＣＭ＃７を有する。また、各ＣＭは、メインのＣＰＵ（Central Processing Unit）＃０とサブのＣＰＵ＃１とを有する。そして、各ＣＰＵは、障害情報となるログを管理する。

また、ストレージ装置９１０では、８つのＣＭのうち１つのＣＭがマスターＣＭに設定される。このマスターＣＭは、ストレージ装置全体を統括する役割を持っている。なお、図２１に示す例では、ＣＭ＃０がマスターＣＭである。そして、マスターＣＭであるＣＭ＃０において、メインのＣＰＵ＃０は、定期的にログ採取処理を起動し、全ＣＰＵのログを採取してログファイルを生成し、リモートサポート機能を介してリモートサポートセンター９００へログファイル９４０を配信する。なお、リモートサポート機能とは、ＣＰＵが有するリモートサポートセンターとの通信機能である。また、以下の説明では、マスターＣＭが有するメインのＣＰＵをマスターＣＰＵと称する。

次に、図２２を用いて、ストレージ装置により生成されるログファイルのフォーマットを説明する。図２２は、ストレージ装置により生成されるログファイルのフォーマットの一例を示す図である。マスターＣＰＵは、図２２に示すようにログファイルに、ログファイル自身のヘッダ部と、システム構成情報を含む構成情報とを格納する。そして、マスターＣＰＵは、各メインのＣＰＵ＃０から採取したログについて、ＣＭ番号の小さいものから順にログファイルに格納し、続いて、各サブのＣＰＵ＃１から採取したログについて、ＣＭ番号の小さいものから順にログファイルに格納する。

また、マスターＣＰＵは、各ＣＰＵのログには、管理しているログタイプ順でログを格納する。例えば、ログタイプは、（１）〜（２１）で番号付けされており、障害情報として重要な順に並べられる。なお、ログタイプの（１７）は欠番とする。

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

しかしながら、上述した従来の技術では、有用なログを失う場合があるという課題がある。

具体的には、複数のストレージ装置からログファイルを受信するリモートサポートセンターは、リソースの都合上、各ストレージ装置から受信するログファイルのサイズを１ログ当たり１．４４ＭＢに制限する。また、リモートサポートセンターのリソースの都合上、１．４４ＭＢを増やすことはできない。

このためストレージ装置は、各ＣＰＵから取得したログ情報のうち、１．４４ＭＢを超えたログ部分を配信できない。例えば、ストレージ装置構成が２ＣＭ（４ＣＰＵ）の場合でも、定期ログが１ＭＢを超えるケースが多い。このため、ストレージ装置の構成が最大となる８ＣＭ（１６ＣＰＵ）の場合では、全ＣＰＵのログをログファイルに収めることは困難になる。

この結果、ストレージ装置は、フォーマットに指定される順序でログを格納した場合、ＣＭ番号の大きいＣＰＵから採取したログやサブのＣＰＵ＃１から採取したログをログファイルに格納できない可能性が高くなる。この場合、ログファイルに格納されないＣＰＵのログは、全て失われる。

１つの側面では、有用なログを失うことを防止することができる制御システム及びログ配信方法を提供することを目的とする。

第１の案では、演算処理装置と該演算処理装置のログを記憶する記憶部をそれぞれ有する制御装置を複数備える制御システムである。制御システムは、各制御装置の記憶部に記憶された演算処理装置の複数のログを、制御システム内の演算処理装置の総数に基づいて決定されるログの容量の上限値の範囲内で、かつ、優先度に基づいた順序で格納して第１のログファイルを生成する。また、制御システムは、各演算処理装置における第１のログファイルを複数含んだ第２のログファイルを生成する。そして、制御システムは、該第２のログファイルを外部装置へ配信する。

有用なログを失うことを防止することができる。

図１は、実施例１に係るストレージ装置の構成を示すブロック図である。 図２は、実施例１に係るＣＭの構成を示すブロック図である。 図３は、ログフォーマットテーブルが記憶する情報の一例を示す図である。 図４は、実施例１に係るストレージ装置によるログファイル配信処理の処理手順を示すフローチャートである。 図５は、実施例２に係るＣＭの構成を示すブロック図である。 図６は、加点テーブルが記憶する情報の一例を示す図である。 図７は、事象に対する加点方法の一例を示す図である。 図８は、ＣＭ＃２のＣＰＵ＃１にディスク関連の事象が発生した場合の加点処理の動作の一例を示す図である。 図９は、ＣＭ＃５をリブートさせた場合の加点処理の動作の一例を示す図である。 図１０は、ＣＭ＃７のＣＰＵ＃０にＲＡＩＤグループ関連の事象が発生した場合の加点処理の動作の一例を示す図である。 図１１は、事象に対する優先度変更対象となるログタイプの一例を示す図である。 図１２は、変更部によるログフォーマットテーブルが規定する格納順序の変更処理の一例を示す図である。 図１３は、第１の生成部により生成されるログファイルの一例を示す図である。 図１４は、初期値に対する加点方法の一例を示す図である。 図１５は、加点テーブルの集約結果の一例を示す図である。 図１６は、上限値算出処理結果の一例を示す図である。 図１７は、ログサイズ変更処理の一例を示す図である。 図１８は、実施例２に係るストレージ装置による処理動作の一例を示す図である。 図１９は、実施例２に係るストレージ装置によるログファイル配信処理の処理手順を示すフローチャートである。 図２０は、ストレージ装置が有する定期ログ配信機能の一例を示す図である。 図２１は、ストレージ装置によるログ採取処理の一例を示す図である。 図２２は、ストレージ装置により生成されるログファイルのフォーマットの一例を示す図である。

以下に、本願の開示する制御システム及びログ配信方法の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

実施例１では、制御システムとしてストレージ装置を例に説明する。このストレージ装置は、ＣＰＵと該ＣＰＵのログを記憶する記憶部をそれぞれ有するＣＭを複数備える。例えば、ストレージ装置は、各ＣＭの記憶部に記憶されたＣＰＵの複数のログを、ストレージ装置内のＣＰＵの総数に基づいて決定されるログの容量の上限値の範囲内で、かつ、優先度に基づいた順序で格納して第１のログファイルを生成する。また、ストレージ装置は、各ＣＰＵにおける第１のログファイルを複数含んだ第２のログファイルを生成する。そして、ストレージ装置は、該第２のログファイルをリモートサポートセンターへ配信する。

［実施例１に係るストレージ装置の構成］
図１は、実施例１に係るストレージ装置の構成を示すブロック図である。図１に示すように、ストレージ装置１００は、ＦＥＲ（Front End Router）１０１とＤＥ（Device Enclosure）１０２とＤＥ１０３とＤＥ１０４とＤＥ１０５とＢＥＲ(Back End Router）１０６とを有する。また、ストレージ装置１００は、ＣＭ（Controller Module）１１０とＣＭ１２０とＣＭ１３０とＣＭ１４０とＣＭ１５０とＣＭ１６０とＣＭ１７０とＣＭ１８０とを有する。なお、ストレージ装置１００が有するＣＭの数は、複数であれば図示に限定されるものではない。また、ストレージ装置１００が有するＤＥの数は図示に限定されるものではない。

また、ストレージ装置１００は、図示しないメインフレームなどのホストとネットワークを介して接続される。また、ストレージ装置１００は、図示しないリモートサポートセンターとネットワークを介して接続される。なお、リモートサポートセンターとは、ストレージ装置から配信されたログファイルを管理する保守センターである。

ＦＥＲ１０１は、ホストやリモートサポートセンターとのインターフェースを提供する。ＤＥ１０２は、図示しないディスクを有する。このディスクは、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）を構成し、ユーザデータを記憶する。

ＢＥＲ１０６は、Ｅｘｐ（Expand）１０７とＥｘｐ１０８とを有する。Ｅｘｐ１０７は、ＣＭ１１０〜ＣＭ１８０及びＤＥ１０２及びＤＥ１０３と接続し、ＣＭ１１０〜ＣＭ１８０とＤＥ１０２及びＤＥ１０３との間のデータのやり取りを中継する。また、Ｅｘｐ１０８は、ＣＭ１１０〜ＣＭ１８０及びＤＥ１０４及びＤＥ１０５と接続し、ＣＭ１１０〜ＣＭ１８０とＤＥ１０４及びＤＥ１０５との間のデータのやり取りを中継する。なお、ＢＥＲ１０６が有するＥｘｐの数は図示に限定されるものではない。

ＣＭ１１０〜ＣＭ１８０それぞれは、ＦＥＲ１０１を介してホストから受付けたＤＥ１０２〜１０５に対するデータの入出力処理を、ＢＥＲ１０６を介して実行する。このようなＣＭ１１０〜ＣＭ１８０それぞれは、図１に示すように２つの記憶部と２つのＣＰＵ（Central Processing Unit）とを有する。ここで、各ＣＭにおいて、各記憶部は、ＣＰＵごとに設けられる。なお、各ＣＭが有するＣＰＵの数は、図示に限定されるものではない。

例えば、図１に示すように、ＣＭ１１０は、記憶部１１１と記憶部１１２とＣＰＵ１１３とＣＰＵ１１４とを有する。ここで、記憶部１１１は、ＣＰＵ１１３用に設けられ、記憶部１１２は、ＣＰＵ１１４用に設けられる。

同様に、ＣＭ１２０は、記憶部１２１と記憶部１２２とＣＰＵ１２３とＣＰＵ１２４とを有する。ここで、記憶部１２１は、ＣＰＵ１２３用に設けられ、記憶部１２２は、ＣＰＵ１２４用に設けられる。また、ＣＭ１３０は、記憶部１３１と記憶部１３２とＣＰＵ１３３とＣＰＵ１３４とを有する。ここで、記憶部１３１は、ＣＰＵ１３３用に設けられ、記憶部１３２は、ＣＰＵ１３４用に設けられる。また、ＣＭ１４０は、記憶部１４１と記憶部１４２とＣＰＵ１４３とＣＰＵ１４４とを有する。ここで、記憶部１４１は、ＣＰＵ１４３用に設けられ、記憶部１４２は、ＣＰＵ１４４用に設けられる。

また、ＣＭ１５０は、記憶部１５１と記憶部１５２とＣＰＵ１５３とＣＰＵ１５４とを有する。ここで、記憶部１５１は、ＣＰＵ１５３用に設けられ、記憶部１５２は、ＣＰＵ１５４用に設けられる。また、ＣＭ１６０は、記憶部１６１と記憶部１６２とＣＰＵ１６３とＣＰＵ１６４とを有する。ここで、記憶部１６１は、ＣＰＵ１６３用に設けられ、記憶部１６２は、ＣＰＵ１６４用に設けられる。

また、ＣＭ１７０は、記憶部１７１と記憶部１７２とＣＰＵ１７３とＣＰＵ１７４とを有する。ここで、記憶部１７１は、ＣＰＵ１７３用に設けられ、記憶部１７２は、ＣＰＵ１７４用に設けられる。また、ＣＭ１８０は、記憶部１８１と記憶部１８２とＣＰＵ１８３とＣＰＵ１８４とを有する。ここで、記憶部１８１は、ＣＰＵ１８３用に設けられ、記憶部１８２は、ＣＰＵ１８４用に設けられる。なお、ＣＭ１１０〜ＣＭ１８０が有する各ＣＰＵは、ＦＥＲ１０１を介してバスにより相互に通信可能に接続される。

ここで、各ＣＭが有する２つのＣＰＵのうち、一方はメインのＣＰＵとして機能し、他方はサブのＣＰＵとして機能する。ここで、サブのＣＰＵとは、メインのＣＰＵの処理負荷が高い場合に使用されるＣＰＵである。

なお、以下では、ＣＭに以下のようにＣＭ番号を付与して適宜説明する。ＣＭ１１０には「ＣＭ＃０」、ＣＭ１２０には「ＣＭ＃１」、ＣＭ１３０には「ＣＭ＃２」、ＣＭ１４０には「ＣＭ＃３」、ＣＭ１５０には「ＣＭ＃４」を付与する。同様に、ＣＭ１６０には「ＣＭ＃５」、ＣＭ１７０には「ＣＭ＃６」、ＣＭ１８０には「ＣＭ＃７」を付与する。また、以下の説明では、ＣＭ１１０〜ＣＭ１８０が有するメインのＣＰＵを「ＣＰＵ＃０」、サブのＣＰＵを「ＣＰＵ＃１」と適宜表記する。

また、ストレージ装置１００ではＣＭ１１０〜ＣＭ１８０のうち、いずれか一つのＣＭが、マスターとして設定される。以下の説明では、ＣＭ１１０を「マスターＣＭ」であるものとして説明する。そして、マスターＣＭが有するメインのＣＰＵのことを「マスターＣＰＵ」と称するものとする。また、ＣＭ１１０〜ＣＭ１８０が有するＣＰＵのうち、マスターＣＰＵ以外のＣＰＵのことを「他のＣＰＵ」と称するものとする。なお、マスターＣＭはＣＭ１１０に限定されるものではなく、他のＣＭに変更可能である。

このような複数のＣＭを有するストレージ装置１００において、複数のＣＭが有するＣＰＵそれぞれは、ＣＰＵごとに設けられる記憶部に該ＣＰＵのログを記憶させる。また、複数のＣＭが有するＣＰＵそれぞれは、ログが格納される順序を規定するログフォーマットに基づいた順序で、複数のＣＭが有するＣＰＵの数に基づいて決定されるログの容量の上限値以内まで、記憶部に記憶されるログを格納するログファイルを生成する。また、複数のＣＭが有するＣＰＵの一つであるマスターＣＰＵを除く他のＣＰＵそれぞれは、更に、マスターＣＰＵへログファイルを送信する。また、マスターＣＰＵは、更に、ログファイルを他のＣＰＵそれぞれから受信する。そして、マスターＣＰＵは、生成したログファイルと他のＣＰＵそれぞれから受信したログファイルとを含んだ全ＣＰＵのログファイルを生成する。続いて、マスターＣＰＵは、全ＣＰＵのログファイルをリモートサポートセンターへ配信する。

このように、実施例１に係るストレージ装置１００は、全ＣＰＵ分のログファイルを含んだログファイルを生成することで、有用なログを失うことを防止することができる。

［実施例１に係るＣＭの機能構成］
次に、図２を用いて、実施例１に係るＣＭ１１０〜ＣＭ１８０の機能構成について説明する。なお、ここでは、マスターＣＭであるＣＭ１１０を例にする。図２は、実施例１に係るＣＭの構成を示すブロック図である。図２に示すように、実施例１に係るＣＭ１１０は、記憶部１１１と記憶部１１２とＣＰＵ１１３とＣＰＵ１１４とを有する。

また、以下の説明では、ＣＰＵ１１３をサブのＣＰＵであるものとし、ＣＰＵ１１４をメインのＣＰＵであるものとする。ＣＭ１１０がマスターＣＭであるので、ＣＰＵ１１３は、「他のＣＰＵ」であり、ＣＰＵ１１４は「マスターＣＰＵ」である。またこの場合、ＣＭ１２０〜ＣＭ１８０が有するＣＰＵはいずれも「他のＣＰＵ」である。このようなことから、ＣＰＵ１１３を「他のＣＰＵ」の一例として「ＣＰＵ３００」と表記し、ＣＰＵ１１４を「マスターＣＰＵ」の一例として「ＣＰＵ４００」と表記する。また、記憶部１１１及び記憶部１１２は、同様の情報を記憶するので、「記憶部２００」と表記する。

記憶部２００は、ＲＡＭ（Random Access Memory）やＳＳＤ（Solid State Drive）などの半導体メモリ素子であり、ログ格納域２０１とログフォーマットテーブル２０２とを有する。ログ格納域２０１は、ログを格納する。

ログフォーマットテーブル２０２は、ログをログファイルとして格納する順序を示す情報を記憶する。図３を用いて、ログフォーマットテーブルが記憶する情報の一例を説明する。図３は、ログフォーマットテーブルが記憶する情報の一例を示す図である。

図３に示すように、ログフォーマットテーブル２０２は、ログファイルヘッダ２０２ａ、構成情報２０２ｂ、各ＣＰＵから採取したログ２０２ｃの順序でログファイルに格納することを示す。

また、図３に示すように、ログフォーマットテーブル２０２は、各メインのＣＰＵ＃０から採取したログについて、ＣＭ番号の小さいものから順にログファイルに格納することを示す。そして、ログフォーマットテーブル２０２は、各メインのＣＰＵ＃０から採取したログに続いて、各サブのＣＰＵ＃１から採取したログについて、ＣＭ番号の小さいものから順にログファイルに格納することを示す。

また、図３に示すように、各ＣＰＵから採取したログは、ログタイプ２０２ｄに示す順序で格納される。このログタイプは、（１）〜（２１）で番号付けされており、障害情報として重要な順に並べられる。なお、ログタイプの（１７）は欠番とする。

ここで、ログタイプ２０２ｄとして記憶される「ＤＥＧＲＡＤＥ（１）」には、装置の故障を示すログが格納される。また、ログタイプ２０２ｄとして記憶される「ＰＡＮＩＣ（２）」には、パニックを示すログが格納される。また、ログタイプ２０２ｄとして記憶される「ＥＲＲＯＲ（３）」には、ファームウェアのエラーなどを示すログが格納される。

また、ログタイプ２０２ｄとして記憶される「ＤＥＧ＿ＦＡＣＴＯＲ（４）」には、装置の故障となる要因を示すログが格納される。また、ログタイプ２０２ｄとして記憶される「ＲＥＣＯＶＥＲ＿ＥＲＲ（５）」には、復帰成功に対する情報更新失敗の通知の設定を示すログが格納される。また、ログタイプ２０２ｄとして記憶される「ＲＥＢＵＩＬＤ＿ＣＯＰＹ（６）」には、ＲＡＩＤ構成のコピーに関するログが格納される。また、ログタイプ２０２ｄとして記憶される「ＣＯＰＹ（７）」には、ＲＡＩＤ構成のコピーに関するログが格納される。

また、ログタイプ２０２ｄとして記憶される「ＥＮＶＩＲＯＭＥＮＴ（８）」には、電源やファンなどの状態を示すログが格納される。また、ログタイプ２０２ｄとして記憶される「ＰＯＷＥＲ（９）」には、電源を監視し、電源オンの時間などを示すログが格納される。また、ログタイプ２０２ｄとして記憶される「ＯＰＥＲＡＴＩＯＮ（１０）」には、ストレージ装置に対して使用した機能を示すログが格納される。

また、ログタイプ２０２ｄとして記憶される「ＥＶＥＮＴ＿ＣＭ（１１）」には、ＣＭ関連のログが格納される。また、ログタイプ２０２ｄとして記憶される「ＥＶＥＮＴ＿ＣＡ（１２）」には、ＣＡ関連のログが格納される。また、ログタイプ２０２ｄとして記憶される「ＥＶＥＮＴ＿ＭＦＣＡ（１３）」には、ＭＦＣＡ関連のログが格納される。また、ログタイプ２０２ｄとして記憶される「ＥＶＥＮＴ＿ＤＩ（１４）」には、ディスク関連のログが格納される。

また、ログタイプ２０２ｄとして記憶される「ＥＶＥＮＴ＿ＯＴＨＥＲ（１５）」には、他のイベントのログが格納される。また、ログタイプ２０２ｄとして記憶される「ＥＶＥＮＴ＿ＭＭＣ（１６）」には、ＣＭのサービスを監視するＭＭＣ（Module Management Controller）に関するログが格納される。また、ログタイプ２０２ｄとして記憶される「ＦＲＵ＿ＩＮＦＯ（１８）」には、ＣＭのサービスを監視するＦＲＵ（Field-Replaceable Unit)）に関するログが格納される。

また、ログタイプ２０２ｄとして記憶される「ＳＹＳＬＯＧ（１９）」には、ＬＩＮＵＸ（登録商標）上で動作するファームウェアとのやり取りを示すログが格納される。また、ログタイプ２０２ｄとして記憶される「ＥＶＥＮＴ＿ＭＳＧ（２０）」には、障害を通知する機能に関するログが格納される。また、ログタイプ２０２ｄとして記憶される「ＯＴＨＥＲＳ（２１）」には、ログファイルには書込まれなかったログが存在することを示すログが格納される。

図２に戻り、ＣＰＵ３００は、記憶制御部３０１と第１の生成部３０２と送信部３０３とを有する。

記憶制御部３０１は、ログをログ格納域２０１に記憶させる。また、記憶制御部３０１は、ログに付与されているユニークなコードを監視することで、特定のログを監視する。

第１の生成部３０２は、ログフォーマットテーブル２０２に基づいた順序で、複数のＣＭが有するＣＰＵの数に基づいて決定されるログの容量の上限値以内まで、ログ格納域２０１に記憶されるログを格納するログファイルを生成する。

また、各ＣＰＵのログの容量の上限値は、「（定期ログの制限値−ログヘッダのサイズ−構成情報のサイズ）／ＣＰＵの数」で決定される。ここで、定期ログの制限値が１ログ当たり１．４４ＭＢであるものとする。また、ログヘッダのサイズは固定値である。また、構成情報には、ストレージ装置が有するディスクやＲＡＩＤに関する情報などが含まれ、ストレージ装置ごとに固定値が設定される。すなわち、上限値は、ストレージ装置ごとに予め決定された値が設定される。なお、この定期ログの制限１．４４ＭＢは、ストレージ装置１００において１４５７６５０バイトで管理されているものとする。

送信部３０３は、第１の生成部３０２により生成されたログファイルをマスターＣＰＵであるＣＰＵ４００へ送信する。

ＣＰＵ４００は、記憶制御部３０１と第１の生成部３０２と受信部４０１と第２の生成部４０２と配信部４０３とを有する。なお、ここでは、図２に示したＣＰＵ３００が有する各部と同様の役割を果たす機能部については、同一符号を付すことにしてその詳細な説明を省略する。

受信部４０１は、ログファイルを他のＣＰＵであるＣＰＵ３００それぞれから受信する。

第２の生成部４０２は、自装置の第１の生成部３０２により生成されたログファイルと他のＣＰＵであるＣＰＵ３００それぞれから受信したログファイルとを含んだ全ＣＰＵのログファイルを生成する。

例えば、第２の生成部４０２は、ログフォーマットテーブル２０２に基づいた順序で、自装置の第１の生成部３０２により生成されたログファイルと他のＣＰＵであるＣＰＵ３００それぞれから受信したログファイルとを含んだ全ＣＰＵのログファイルを生成する。なお、第２の生成部４０２により生成されるログファイルを「全ＣＰＵのログファイル」と称し、第１の生成部３０２により生成されるログファイルと区別する。

配信部４０３は、第２の生成部４０２により生成された全ＣＰＵのログファイルをリモートサポートセンターへ配信する。

［実施例１に係るストレージ装置による処理の処理手順］
次に図４を用いて、実施例１に係るストレージ装置１００によるログファイル配信処理の処理手順を説明する。図４は、実施例１に係るストレージ装置によるログファイル配信処理の処理手順を示すフローチャートである。

図４に示すように、マスターＣＰＵであるＣＰＵ４００は、定期ログ配信時間であると判定された場合（ステップＳ１０１、Ｙｅｓ）、ログファイルの取得を他のＣＰＵであるＣＰＵ３００に要求する（ステップＳ１０２）。

他のＣＰＵであるＣＰＵ３００において、第１の生成部３０２は、上限値までログをログファイルに格納する（ステップＳ１０３）。続いて、送信部３０３は、ログファイルをマスターＣＰＵであるＣＰＵ４００に送信する（ステップＳ１０４）。また、マスターＣＰＵであるＣＰＵ４００において、第１の生成部３０２は、上限値までログをログファイルに格納する（ステップＳ１０５）。

続いて、マスターＣＰＵであるＣＰＵ４００では、受信部４０１は、他のＣＰＵであるＣＰＵ３００からログファイルを受信する（ステップＳ１０６）。そして、第２の生成部４０２は、他のＣＰＵであるＣＰＵ３００から受信したログファイルと、生成したログファイルとを全て含んだ、全ＣＰＵのログファイルを生成する（ステップＳ１０７）。続いて、配信部４０３は、リモートサポートセンターへ全ＣＰＵのログファイルを配信する（ステップＳ１０８）。

［実施例１の効果］
上述してきたように、実施例１に係るストレージ装置１００は、ストレージ装置１００が有するＣＰＵの数から決定されるログサイズの上限値以内のログファイルを各ＣＰＵから取得して、全ＣＰＵのログを含んだログファイルを生成する。この結果、実施例１に係るストレージ装置１００は、重要なログを失うことを防止することができる。

ところで、ストレージ装置において、定期ログは毎日または、毎週の単位で配信する設定が可能である。この設定した期間内において、各ＣＰＵで発生しているログ流量は変動する。また、それぞれのＣＰＵで発生している事象によってログ流量が変わる。

このようなことから、各ＣＰＵで均一なサイズの上限値を設定すると、例えば、あるＣＰＵで事象が発生してログサイズが大きくなった場合には、ログが失われる可能性が高くなる。そこで、実施例２では、ストレージ装置において、ＣＰＵそれぞれで発生する事象に基づいて上限値をＣＰＵごとに算出する場合を例に説明する。

［実施例２に係るストレージ装置の構成］
実施例２に係るストレージ装置の構成は、各ＣＭが有するＣＰＵの機能構成が一部異なる点を除いて、図１に示した実施例１に係るストレージ装置の構成と同様である。したがって、実施例２では、ストレージ装置１００をストレージ装置１００ａとし、ストレージ装置１００ａが有する各ＣＭをＣＭ１１０ａ〜１８０ａとして説明する。

［実施例２に係るＣＭの機能構成］
次に、図５を用いて、実施例２に係るＣＭ１１０ａの機能構成について説明する。図５は、実施例２に係るＣＭの構成を示すブロック図である。図５に示すように、実施例２に係るＣＭ１１０ａは、２つの記憶部５００とＣＰＵ６００とＣＰＵ７００とを有する。ここで、記憶部５００のうち一方は、ＣＰＵ６００用であり、他方は、ＣＰＵ７００用である。

記憶部５００は、ＲＡＭやＳＳＤなどの半導体メモリ素子であり、ログ格納域２０１と加点テーブル５０１とログフォーマットテーブル２０２とを有する。なお、ここでは、図２に示した各テーブルと同様の情報を記憶するテーブルについては、同一符号を付すことにしてその詳細な説明を省略する。

加点テーブル５０１は、ＣＰＵごとに発生した事象に対応付けて加点された点数の累積値を記憶する。なお、加点テーブル５０１が記憶する情報のフォーマットは、各ＣＰＵにおいて共通である。そして、事象が発生した場合、事象が発生したＣＰＵの加点テーブル５０１において、事象とＣＰＵとが対応付けて加点される。

図６を用いて、加点テーブルが記憶する情報の一例を説明する。図６は、加点テーブルが記憶する情報の一例を示す図である。図６に示すように、加点テーブル５０１は、発生した事象として「ディスク関連」、「ＲＡＩＤグループ関連」、「ＣＡ関連」、「ＭＦＣＡ関連」、「ＣＭリブート」のそれぞれに、「ＣＰＵ」を対応付けて加点された点数の累積値を記憶する。

ここで、加点テーブル５０１が記憶する「ディスク関連」は、搭載するディスクに関する事象を示す。「ＲＡＩＤグループ関連」は、ストレージ装置１００ａ内に設定されているＲＡＩＤグループに関する事象を示す。

「ＣＡ関連」は、ストレージ装置１００ａの搭載部品であり、ホストとのインターフェースとなるＣＡ（Channel Adapter）に関する事象を示す。「ＭＦＣＡ関連」は、ホストとのインターフェースとなるＭＦＣＡ（Main Frame Channel Adapter）に関する事象を示す。なお、ストレージ装置がメインフレーム対応ではない場合、この「ＭＦＣＡ関連」は設定されない。「ＣＭリブート」は、ソフトエラー発生により、ＣＭ自身がリブートする処理を示す。

図６に示す例では、ＣＭ＃０のＣＰＵ＃０において、ディスク関連の事象が発生し、累積値が５点であることを示す。

図５に戻り、ＣＰＵ６００は、記憶制御部６０１と加点部６０２と受信部６０３と変更部６０４と第１の生成部６０５と送信部６０６とを有する。

記憶制御部６０１は、ログをログ格納域２０１に記憶させる。また、記憶制御部６０１は、ログに付与されているユニークなコードを監視することで、特定のログを監視する。記憶制御部６０１は、特定のログをログ格納域に記憶させた場合、加点部６０２に事象が発生した旨を通知する。

加点部６０２は、ＣＰＵそれぞれで発生する事象に対して、該事象に対応付けて記録されるログに基づき加点する。図７を用いて、加点部６０２による事象に対する加点方法の一例を説明する。図７は、事象に対する加点方法の一例を示す図である。

図７に示すように加点部６０２は、「ディスク関連」の事象に対して、警告レベルである場合には２点を加点し、エラーレベルである場合には５点を加点する。また、加点部６０２は、「ＲＡＩＤグループ関連」の事象に対して、警告レベルである場合には２点を加点し、エラーレベルである場合には５点を加点する。

また、加点部６０２は、「ＣＡ関連」の事象に対して、警告レベルである場合には２点を加点し、エラーレベルである場合には４点を加点する。また、加点部６０２は、「ＭＦＣＡ関連」の事象に対して、警告レベルである場合には２点を加点し、エラーレベルである場合には４点を加点する。

また、加点部６０２は、「ＣＭリブート」の事象に対して、リブートするＣＭが有するメインのＣＰＵに１０点を加点し、リブートするＣＭが有するサブのＣＰＵに５点を加点し、マスターＣＰＵに５点を加点する。

次に、図８から図１０を用いて、加点部６０２による加点処理の動作を説明する。図８は、ＣＭ＃２のＣＰＵ＃１にディスク関連の事象が発生した場合の加点処理の動作の一例を示す図である。なお、図８に示す例では、ＣＭ＃２のＣＰＵ＃１にディスク関連のエラーレベルの事象が発生した場合を説明する。ＣＭ＃２のＣＰＵ＃１が有する加点部６０２は、加点テーブル５０１の「ＣＭ＃２ＣＰＵ＃１」に対応する「ディスク関連」にエラーレベルであることを示す「５」を加点する。

図９は、ＣＭ＃５をリブートさせた場合の加点処理の動作の一例を示す図である。ここで、リブート発生時にはログが大量にとられるので、加点する点数が大きく設定される。図９に示すように、加点テーブル５０１の「ＣＭ＃５ＣＰＵ＃０」に対応する「ＣＭリブート」に「１０」が加点され、「ＣＭ＃５ＣＰＵ＃１」に対応する「ＣＭリブート」に「５」が加点される。また、リブートを監視するマスターＣＰＵもリブートするＣＭの組み込み処理等を行うので、加点テーブル５０１の「ＣＭ＃０ＣＰＵ＃０」に対応する「ＣＭリブート」に「５」が加点される。

なお、ＣＭ＃５をリブートさせた場合、リブートを行うＣＭ＃５では加点処理を実行できない。このため、リブートさせた場合の加点処理は、マスターＣＰＵが有する加点部６０２により実行される。すなわち、ＣＭリブートの事象を検知するのはマスターＣＰＵであるため、リブート時はマスターＣＰＵの加点テーブル５０１が更新されることになる。

図１０は、ＣＭ＃７のＣＰＵ＃０にＲＡＩＤグループ関連の事象が発生した場合の加点処理の動作の一例を示す図である。なお図１０に示す例では、ＣＭ＃７のＣＰＵ＃０にＲＡＩＤグループ関連の警告レベルの事象が２回発生した場合を説明する。ＣＭ＃７のＣＰＵ＃０が有する加点部６０２は、加点テーブル５０１の「ＣＭ＃７ＣＰＵ＃０」に対応する「ＲＡＩＤグループ関連」に警告レベルであることを示す「２」を２回加点する。この結果、加点テーブル５０１における「ＣＭ＃７ＣＰＵ＃０」に対応する「ＲＡＩＤグループ関連」の累積値が４点となる。

図５に戻り、受信部６０３は、後述する算出部７０２により算出された上限値と後述する集計部７０１により集計された加点テーブルとをマスターＣＰＵであるＣＰＵ７００から受信する。受信部６０３は、集計部７０１により集計された加点テーブルを変更部６０４に出力する。また、受信部６０３は、算出部７０２により算出された上限値を第１の生成部６０５に出力する。

変更部６０４は、集計部７０１により集計された加点テーブルに基づいて、ログフォーマットテーブル２０２が規定する格納順序を変更する。図１１を用いて、加点された結果と事象に対する優先度変更対象となるログタイプとの対応関係の一例を説明する。図１１は、事象に対する優先度変更対象となるログタイプの一例を示す図である。

図１１に示すように、変更部６０４は、加点テーブルの「ＣＭリブート」とログタイプの「ＥＶＥＮＴ＿ＣＭ（１１）」とを対応付ける。また、変更部６０４は、加点テーブルの「ＣＡ関連」とログタイプの「ＥＶＥＮＴ＿ＣＡ（１２）」とを対応付ける。また、変更部６０４は、加点テーブルの「ＭＦＣＡ関連」とログタイプの「ＥＶＥＮＴ＿ＭＦＣＡ（１３）」とを対応付ける。また、変更部６０４は、加点テーブルの「ディスク関連」とログタイプの「ＥＶＥＮＴ＿ＤＩ（１４）」とを対応付ける。

次に、図１２を用いて、変更部６０４によるログフォーマットテーブル２０２が規定する格納順序の変更処理について説明する。図１２は、変更部によるログフォーマットテーブルが規定する格納順序の変更処理の一例を示す図である。

図１２中の１２ａに示すように、加点テーブルには、いずれの事象に対しても加点されていないものとする。また、この場合、ログフォーマットテーブル２０２に規定される格納順序は、「ＥＶＥＮＴ＿ＣＭ（１１）」、「ＥＶＥＮＴ＿ＣＡ（１２）」、「ＥＶＥＮＴ＿ＭＦＣＡ（１３）」、「ＥＶＥＮＴ＿ＤＩ（１４）」の順であるとする。

次に、図１２中の１２ａに示す状態から図１２中の１２ｂに示す状態に遷移した場合について説明する。１２ｂに示す状態では、加点テーブルにおける「ディスク関連」の累積値が４点であり、他の事象の累積値が０点である。このため、変更部６０４は、累積値が最も高い「ディスク関連」に対応するログタイプの「ＥＶＥＮＴ＿ＤＩ（１４）」の格納順序を繰り上げる。すなわち、変更部６０４は、ログフォーマットテーブル２０２に規定される格納順序を、「ＥＶＥＮＴ＿ＤＩ（１４）」、「ＥＶＥＮＴ＿ＣＭ（１１）」、「ＥＶＥＮＴ＿ＣＡ（１２）」、「ＥＶＥＮＴ＿ＭＦＣＡ（１３）」の順に変更する。

次に、図１２中の１２ａに示す状態から図１２中の１２ｃに示す状態に遷移した場合について説明する。１２ｃに示す状態では、加点テーブルにおける「ディスク関連」の累積値が１０点であり、「ＣＡ関連」の累積値が４点であり、これら以外の事象の累積値が０点である。このため、変更部６０４は、累積値が最も高い「ディスク関連」に対応するログタイプの「ＥＶＥＮＴ＿ＤＩ（１４）」及び「ＣＡ関連」に対応するログタイプの「ＥＶＥＮＴ＿ＣＡ（１２）」の格納順序を累積値の高い順で繰り上げる。すなわち、変更部６０４は、ログフォーマットテーブル２０２に規定される格納順序を、「ＥＶＥＮＴ＿ＤＩ（１４）」、「ＥＶＥＮＴ＿ＣＡ（１２）」、「ＥＶＥＮＴ＿ＣＭ（１１）」、「ＥＶＥＮＴ＿ＭＦＣＡ（１３）」の順に変更する。

変更部６０４は、変更結果を第１の生成部６０５に通知する。なお、変更部６０４は、変更が無い場合には、ログフォーマットテーブル２０２に規定される格納順序に変更が無い旨を第１の生成部６０５に通知する。

第１の生成部６０５は、ログが格納される順序を規定するログフォーマットに基づいた順序で、後述する算出部７０２により算出された上限値以内まで、ログ格納域２０１に記憶されるログを格納するログファイルを生成する。

ここで、第１の生成部６０５は、変更部６０４により変更された格納順序で、設定された上限値以内まで、ログ格納域２０１に記憶されるログを格納するログファイルを生成する。図１３を用いて、第１の生成部６０５により生成されるログファイルの一例を説明する。図１３は、第１の生成部により生成されるログファイルの一例を示す図である。なお、図１３では、第１の生成部６０５は、図１２中の１２ｂの状態のログファイルを生成する場合を例に説明する。

図１３に示すように、第１の生成部６０５は、「ＤＥＧＲＡＤＥ（１）」から「ＯＰＥＲＡＴＩＯＮ（１０）」までログフォーマットテーブル２０２に規定される順序でログを格納する。

続いて、第１の生成部６０５は、変更部６０４により変更された順序でログを格納する。すなわち、第１の生成部６０５は、「ＥＶＥＮＴ＿ＤＩ（１４）」、「ＥＶＥＮＴ＿ＣＭ（１１）」、「ＥＶＥＮＴ＿ＣＡ（１２）」、「ＥＶＥＮＴ＿ＭＦＣＡ（１３）」の順でログを格納する。なお、図１３中の１３ａは、算出部７０２により算出された上限値であり、第１の生成部６０５は、この上限値までログを格納する。そして、第１の生成部６０５は、生成したログファイルを送信部６０６に出力する。

送信部６０６は、第１の生成部６０５により生成されたログファイルをマスターＣＰＵであるＣＰＵ７００へ送信する。

ＣＰＵ７００は、記憶制御部６０１と加点部６０２と集計部７０１と算出部７０２と送信部７０３と変更部６０４と第１の生成部６０５と受信部７０４と第２の生成部７０５と配信部７０６とを有する。なお、ここでは、図５に示すＣＰＵ６００が有する各部と同様の役割を果たす機能部については、同一符号を付すことにしてその詳細な説明を省略する。

集計部７０１は、加点部６０２により加点された結果を、複数のＣＭが有するＣＰＵそれぞれから取得して集計する。例えば、集計部７０１は、他のＣＰＵから取得した加点テーブル５０１とＣＰＵ７００が有する加点テーブル５０１における加点値を抽出し、各ＣＰＵに対して初期値を加点して各ＣＰＵの合計点数を集計した加点テーブルを生成する。

次に、図１４を用いて、初期値に対する加点方法の一例を説明する。図１４は、初期値に対する加点方法の一例を示す図である。図１４に示すように、集計部７０１は、他のＣＰＵに対する初期値として１日ごとに１点を加点する。すなわち、定期ログの設定が毎日である場合、集計部７０１は、初期値として１点を加点し、定期ログの設定が毎週である場合、集計部７０１は、初期値として７点を加点する。

また、集計部７０１は、マスターＣＰＵに対する初期値として１日ごとに２点を加点する。すなわち、定期ログの設定が毎日である場合、集計部７０１は、初期値として２点を加点し、定期ログの設定が毎週である場合、集計部７０１は、初期値として１４点を加点する。

図１５を用いて、加点テーブルの集約結果の一例を説明する。図１５は、加点テーブルの集約結果の一例を示す図である。なお、図１５に示す例では、集計部７０１は、図８から図１０に示した加点テーブルを集計する場合を説明する。

図１５に示すように、集計部７０１は、「ＣＭ＃０ＣＰＵ＃０」に対応する「ＣＭリブート」から「５」、「ＣＭ＃５ＣＰＵ＃０」に対応する「ＣＭリブート」から「１０」、「ＣＭ＃７ＣＰＵ＃０」に対応する「ＲＡＩＤグループ関連」から「４」を抽出する。また、集計部７０１は、「ＣＭ＃２ＣＰＵ＃１」に対応する「ディスク関連」から「５」、「ＣＭ＃５ＣＰＵ＃１」に対応する「ＣＭリブート」から「５」を抽出する。

続いて、集計部７０１は、各ＣＰＵに初期値を設定する。例えば、図１５に示すように、マスターＣＰＵである「ＣＭ＃０ＣＰＵ＃０」に初期値「１４」、他のＣＰＵに初期値「７」を設定する。そして、集計部７０１は、抽出した加点値の累積値に対して初期値を加算し合計値を各ＣＰＵそれぞれに集計する。このようにして、集計部７０１は、各ＣＰＵの加点テーブルを集計した加点テーブルを生成する。また、集計部７０１は、集計結果を送信部７０３に出力する。

なお、集計部７０１は、マスターＣＰＵであるＣＰＵ７００の処理や制御が多くなるので、マスターＣＰＵに対して、初期値を加点して集計するようにしてもよい。例えば、集計部７０１は、マスターＣＰＵに対して、初期値を１０点加点する。

図５に戻り、算出部７０２は、ＣＰＵそれぞれで発生する事象に基づいて、上限値をＣＰＵごとに算出する。例えば、算出部７０２は、集計部７０１による集計結果と、複数のＣＭが有するＣＰＵの数とに基づいて、取得するログの容量の上限値をＣＰＵごとに算出する。

具体的には、算出部７０２は、「（定期ログの制限値−ログヘッダのサイズ−構成情報のサイズ）×（各ＣＰＵの合計値／ＣＰＵすべての合計値）」から各ＣＰＵのログ容量の上限値を算出する。ここで、定期ログの制限値が１ログ当たり１．４４ＭＢであるものとする。また、ログヘッダのサイズは固定値である。また、構成情報には、ストレージ装置が有するディスクやＲＡＩＤに関する情報などが含まれ、ストレージ装置ごとに固定値が設定される。

図１６を用いて、上限値算出処理の結果の一例を説明する。図１６は、上限値算出処理の結果の一例を示す図である。なお、図１６に示す例では、算出部７０２は、図１５に示した集計後の加点テーブルを用いて、ログの容量の上限値をＣＰＵごとに算出する場合を説明する。また、この定期ログの制限１．４４ＭＢは、ストレージ装置１００ａにおいて１４５７６５０（バイト）で管理されているものとする。また、ログヘッダのサイズは、５００（バイト）であり、構成情報のサイズは３０００００（バイト）であるものとする。

算出部７０２は、集計後の加点テーブルを用いて、各ＣＰＵの合計値を集計しＣＰＵすべての合計値「１４８」を算出する。そして、算出部７０２は、例えばＣＭ＃０のＣＰＵ＃０に対するログサイズの上限値を、「（１４５７６５０（バイト）−５００（バイト）−３０００００（バイト））×（１９（点）／１４８（点））」から「１４８５５３（バイト）」であると算出する。

次に、図１７を用いて、ログサイズ変更処理の一例を説明する。図１７は、ログサイズ変更処理の一例を示す図である。図１７中の１７ａは、いずれのＣＰＵにも事象が発生していない場合の全ＣＰＵのログファイルを示す。また、図１７中の１７ａは、全ＣＰＵのログファイルの容量を示し、１．４４ＭＢである。また、図１７中の１７ｂは、ＣＭ＃０のＣＰＵ＃０のログを格納する容量であり、例えば、１３６１３５バイトである。

図１７中の１７ｄは、ＣＭ＃０のＣＰＵ＃０にディスクエラーの事象が発生した場合の全ＣＰＵのログファイルを示す。また、図１７中の１７ｄは、全ＣＰＵのログファイルの容量を示し、１．４４ＭＢである。また、図１７中の１７ｃは、ＣＭ＃０のＣＰＵ＃０のログを格納する容量であり、例えば、１７７３０５バイトである。

このように、ＣＭ＃０のＣＰＵ＃０にディスクエラーの事象が発生することで、算出部７０２は、ＣＭ＃０のＣＰＵ＃０のログを１３６１３５バイトから１７７３０５バイトへ増加させる。なお、全ＣＰＵのログファイルの容量は変わらず１．４４ＭＢのままである。

送信部７０３は、算出部７０２により算出された上限値と後述する集計部７０１により集計された加点テーブルとを他のＣＰＵであるＣＰＵ６００に送信する。受信部７０４は、ログファイルを他のＣＰＵであるＣＰＵ６００それぞれから受信する。

第２の生成部７０５は、自装置の第１の生成部６０５により生成されたログファイルと他のＣＰＵであるＣＰＵ６００それぞれから受信したログファイルとを含んだ全ＣＰＵのログファイルをログフォーマットテーブル２０２に基づいた順序で生成する。なお、第２の生成部７０５により生成されるログファイルを「全ＣＰＵのログファイル」と称し、第１の生成部６０５により生成されるログファイルと区別する。

配信部７０６は、第２の生成部７０５により生成された全ＣＰＵのログファイルをリモートサポートセンターへ配信する。

［実施例２に係るストレージ装置による処理動作］
次に図１８を用いて、実施例２に係るストレージ装置１００ａによる処理動作を説明する。図１８は、実施例２に係るストレージ装置による処理動作の一例を示す図である。図１８に示すように、マスターＣＰＵであるＣＰＵ７００及び他のＣＰＵであるＣＰＵ６００では、ログをログ格納域２０１に格納するログ格納処理を実行する（ステップＳ２０１〜ステップＳ２０３）。

また、マスターＣＰＵであるＣＰＵ７００または他のＣＰＵであるＣＰＵ６００で事象が発生した場合、事象に対して加点処理を行う。図１８に示す例では、他のＣＰＵであるＣＰＵ６００では、加点テーブル５０１に加点する（ステップＳ２０４、ステップＳ２０５）。

そして、マスターＣＰＵであるＣＰＵ７００は、定期ログ配信時間であると判定した場合、ＣＰＵそれぞれから加点テーブルを取得する（ステップＳ２０６〜ステップＳ２０８）。続いて、マスターＣＰＵであるＣＰＵ７００は、加点テーブルを集計し、各ＣＰＵそれぞれのログサイズの上限値を算出する（ステップＳ２０９）。

［実施例２に係るストレージ装置による処理の処理手順］
次に図１９を用いて、実施例２に係るストレージ装置１００ａによるログファイル配信処理の処理手順を説明する。図１９は、実施例２に係るストレージ装置によるログファイル配信処理の処理手順を示すフローチャートである。

図１９に示すように、マスターＣＰＵであるＣＰＵ７００において、集計部７０１は、定期ログ配信時間であると判定した場合（ステップＳ３０１、Ｙｅｓ）、加点テーブル５０１の取得を他のＣＰＵに要求する（ステップＳ３０２）。

他のＣＰＵであるＣＰＵ６００において、加点部６０２は、加点テーブル５０１をマスターＣＰＵ７００に送信する（ステップＳ３０３）。加点テーブル５０１をマスターＣＰＵ７００に送信した後、加点部６０２は、加点テーブル５０１をクリアする（ステップＳ３０４）。

マスターＣＰＵであるＣＰＵ７００において、集計部７０１は、他のＣＰＵから加点テーブル５０１を受信する（ステップＳ３０５）。また、集計部７０１は、記憶部５００から加点テーブル５０１を読み出す（ステップＳ３０６）。そして、加点テーブル５０１を読み出した後、集計部７０１は、加点テーブル５０１をクリアする（ステップＳ３０７）。

集計部７０１は、加点テーブル５０１及び他のＣＰＵから受信した加点テーブル５０１を集計する（ステップＳ３０８）。なお、集計部７０１は、集計結果を算出部７０２に出力する。続いて、算出部７０２は、集計結果と、演算処理装置の数とに基づいて、取得するログの容量の上限値を算出する（ステップＳ３０９）。算出部７０２は、集計結果と、算出した上限値とを他のＣＰＵに送信する（ステップＳ３１０）。また、算出部７０２は、集計結果と、算出した上限値とを変更部６０４に出力する。

他のＣＰＵであるＣＰＵ６００において、変更部６０４は、集計結果と、上限値とを受信する（ステップＳ３１１）。そして、変更部６０４は、集計結果に基づいて優先度を変更する（ステップＳ３１２）。なお、変更部６０４は、変更した優先度と、上限値とを第１の生成部６０５に出力する。

第１の生成部６０５は、上限値までログをログファイルに格納する（ステップＳ３１３）。送信部６０６は、ログファイルをマスターＣＰＵ７００に送信する（ステップＳ３１４）。

また、マスターＣＰＵであるＣＰＵ７００において、変更部６０４は、集計結果に基づいて優先度を変更する（ステップＳ３１５）。なお、変更部６０４は、変更した優先度と、上限値とを第１の生成部６０５に出力する。第１の生成部６０５は、上限値までログをログファイルに格納する（ステップＳ３１６）。

続いて、マスターＣＰＵであるＣＰＵ７００では、受信部７０４は、他のＣＰＵであるＣＰＵ６００からログファイルを受信する（ステップＳ３１７）。そして、第２の生成部７０５は、他のＣＰＵであるＣＰＵ６００から受信したログファイルと、自装置の第１の生成部６０５により生成したログファイルとを含んだ、全ＣＰＵのログファイルを生成する（ステップＳ３１８）。続いて、配信部７０６は、リモートサポートセンターへ全ＣＰＵのログファイルを配信する（ステップＳ３１９）。

［実施例２の効果］
上述してきたように、実施例２に係るストレージ装置１００ａは、ＣＰＵそれぞれで発生する事象に基づいて上限値をＣＰＵごとに算出し、ログファイルを生成することができる。このため、あるＣＰＵで事象が発生してログサイズが大きくなった場合でも、有用なログを失うことを防止できる。

また、実施例２に係るストレージ装置１００ａでは、加点テーブルは、定期ログ配信のログ採取処理開始後に各ＣＰＵ上でクリアされる。このため、マスターＣＰＵで集計した加点テーブルを各ＣＰＵでのログファイル作成時に送信する。そして、各ＣＰＵが、マスターＣＰＵから受信した加点テーブルを元に格納順序の変更処理を行う。

例えば、実施例２に係るストレージ装置１００ａは、ログタイプでＥＶＥＮＴ系の、ＥＶＥＮＴ＿ＣＭ、ＥＶＥＮＴ＿ＣＡ、ＥＶＥＮＴ＿ＭＦＣＡ、ＥＶＥＮＴ＿ＤＩの４種類に関して、加点を踏まえ、格納順序を変更する。この結果、事象発生時にこれらＥＶＥＮＴ系のログの数が増大しても、事象によってログ解析に有用となるＥＶＥＮＴのログを優先的に残すことができる。

なお、マスターＣＰＵ以外のＣＰＵは、加点テーブルをマスターＣＰＵに送信せずに、加点テーブルの合計値のみをマスターＣＰＵに通知するようにしてもよい。

ところで、本発明は、上述した実施例以外にも、種々の異なる形態にて実施されてよい。そこで、実施例３では、本発明に含まれる他の実施例について説明する。

（システム構成等）
本実施例において説明した各処理のうち自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともできる。あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文章中や図面中で示した処理手順、制御手順、具体的名称については、特記する場合を除いて任意に変更することができる。

また、図示した記憶部が格納する情報は一例に過ぎず、必ずしも図示のごとく情報が格納される必要はない。また、各種の負荷や使用状況などに応じて、各実施例において説明した各処理の各ステップでの処理の順番を変更してもよい。例えば、図４に示すステップＳ１０３の処理とステップＳ１０５の処理とは同時に実行されても良い。

また、図示した各構成部は、機能概念的なものであり、必ずしも物理的に図示のごとく構成されていることを要しない。例えば、ストレージ装置１００ａが有するＣＰＵ６００及びＣＰＵ７００では、変更部６０４と第１の生成部６０５とが統合されてもよい。さらに、各装置にて行われる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

１００ ストレージ装置
２００ 記憶部
２０１ ログ格納域
２０２ ログフォーマットテーブル
３００、４００ ＣＰＵ
３０１ 記憶制御部
３０２ 第１の生成部
３０３ 送信部
４０１ 受信部
４０２ 第２の生成部
４０３ 配信部

Claims (5)

1. 演算処理装置と該演算処理装置のログを記憶する記憶部をそれぞれ有する制御装置を複数備える制御システムにおいて、
   各制御装置の前記記憶部に記憶された前記演算処理装置の複数のログを、前記制御システム内の演算処理装置の総数に基づいて決定されるログの容量の上限値の範囲内で、かつ、優先度に基づいた順序で格納して第１のログファイルを生成する第１の生成部と、
   各演算処理装置における第１のログファイルを複数含んだ第２のログファイルを生成する第２の生成部と、
   該第２のログファイルを外部装置へ配信する配信部と、を有する
   ことを特徴とする制御システム。
2. 前記演算処理装置それぞれで発生する事象に基づいて、前記上限値を演算処理装置ごとに算出する算出部と、
   算出した上限値を各制御装置内の演算処理装置に通知する通知部と、
   を有することを特徴とする請求項１に記載の制御システム。
3. 前記演算処理装置は、
   それぞれで発生する事象に対して、該事象に対応付けて記録されるログに基づき加点する加点部と、
   前記加点部により加点された結果を取得して集計する集計部と、を有し、
   前記算出部は、前記集計部による集計結果と、前記制御システム内の演算処理装置の総数とに基づいて、取得するログの容量の上限値を演算処理装置ごとに算出する
   ことを特徴とする請求項２に記載の制御システム。
4. 前記演算処理装置は、
   前記加点部により加点された結果に基づいて、前記優先度に規定された格納順序を変更する変更部を有し、
   前記第1の生成部は、前記ログの容量の上限値の範囲内で、かつ、前記変更部により変更された格納順序で、前記記憶部に記憶される複数のログを格納して第１のログファイルを生成する
   ことを特徴とする請求項３に記載の制御システム。
5. 演算処理装置と該演算処理装置のログを記憶する記憶部をそれぞれ有する制御装置を複数備える制御システムが、
   各制御装置の前記記憶部に記憶された前記演算処理装置の複数のログを、前記制御システム内の演算処理装置の総数に基づいて決定されるログの容量の上限値の範囲内で、かつ、優先度に基づいた順序で格納して第１のログファイルを生成し、
   各演算処理装置における第１のログファイルを複数含んだ第２のログファイルを生成し、
   該第２のログファイルを外部装置へ配信する
   各処理を含んだことを特徴とするログ配信方法。

Images