JP2016076072A - 障害通報装置、障害通報方法及び障害通報プログラム - Google Patents

Abstract

【課題】 システムの運用に影響を与えずに、コストを削減できる障害通知装置等を提供する
【解決手段】 本発明の一態様に係る障害通報装置は、少なくとも一部の種類の障害を自律的に修復するストレージシステムに生じる前記障害を検出する障害検出手段と、前記障害の種類と当該障害が自律的に修復可能であるか否かを表す修復可能性とが関連付けられている組が、前記障害の種類毎に記録されたイベントテーブルを使用して、前記障害検出手段によって検出された障害の前記修復可能性を特定し、特定された前記修復可能性に基づいて、通報を行うか否かを決定する通報判定手段と、を備える。
【選択図】 図１３

Description

本発明は障害を通報する技術に関する。

ストレージシステムを運用する技術の例が、例えば、特許文献１及び特許文献２において開示されている。特許文献１に記載されている統合運用システムは、サーバ、ストレージ、アプリケーションなどを含むユーザシステムから、トラブル情報、性能情報、構成情報などを収集する。特許文献１の統合運用システムは、新規のトラブル情報を受信した場合、そのトラブル情報を運用支援システムに転送する。特許文献２に記載されているストレージシステムは、障害が発生した場合に、データをリカバリする。

また、異常や障害が発生した場合の処理の例が、例えば、特許文献３及び特許文献４において開示されている。特許文献３には、あらかじめ記憶している異常の種類とその種類の異常が発生した場合の処理方法との組み合わせに基づいて、異常が検出された場合の通知処理方法を決定するシステムが記載されている。特許文献３のシステムは、決定された通知処理方法に従って、外部に通知を行う。特許文献４には、サービスに障害が発生した際に影響を受ける業務を判定する情報処理装置が記載されている。

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

例えば、特許文献１に記載されているように、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等にハードウェア障害が発生した場合、一般に、故障したハードウェアの即時の交換を促すため、緊急に故障が通知される。グリッド・ストレージ・システムに、ＨＤＤの障害やノード障害などの障害が発生した場合も同様に、一般に、発生した事象（障害）の内容だけに基づいて、緊急度や重要度が決定される。そして、決定された緊急度や重要度に応じた、障害の通報が行われる。障害の通報は、例えば、メールやＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）トラップなどの手段を用いて行われる。グリッド・ストレージ・システムでも障害の発生に応じて障害の通報が行われる理由は、ハードウェア障害が発生した場合、直ぐに交換が必要であると見なされ、緊急に通報されることが一般的であるからである。通報が行われた場合、一般に、作業員が修理を行うことによって、人的リソースが消費される。

しかし、グリッド・ストレージでは、ハードウェア部品の多少の障害が発生しても、業務運用には影響が出ないことが多い。そのため、緊急の対処は必要ないことが多い。それにもかかわらず、グリッド・ストレージ・システムではないストレージシステムにおける通報と同様に、通報が行われることによって、人的リソースが余分に消費される。それに伴って、無駄な費用が生じる。

特許文献３に記載されている技術では、ハードウェア障害などの障害が発生した場合、発生した障害の種類等に応じて、通知処理方法が決定される。特許文献３の技術でも、例えばグリッド・ストレージ・システムにおいて、緊急の対処が必要であるか否かにかかわらず、通知が行われる。すなわち、特許文献３の技術では、人的リソースが無駄に消費されることによる、コストを削減することはできない。

本発明の目的の１つは、システムの運用に影響を与えずに、コストを削減できる障害通知装置等を提供することにある。

本発明の一態様に係る障害通報装置は、少なくとも一部の種類の障害を自律的に修復するストレージシステムに生じる前記障害を検出する障害検出手段と、前記障害の種類と当該障害が自律的に修復可能であるか否かを表す修復可能性とが関連付けられている組が、前記障害の種類毎に記録されたイベントテーブルを使用して、前記障害検出手段によって検出された障害の前記修復可能性を特定し、特定された前記修復可能性に基づいて、通報を行うか否かを決定する通報判定手段と、を備える。

本発明の一態様に係る障害通報方法は、少なくとも一部の種類の障害を自律的に修復するストレージシステムに生じる前記障害を検出し、前記障害の種類と当該障害が自律的に修復可能であるか否かを表す修復可能性とが関連付けられている組が、前記障害の種類毎に記録されたイベントテーブルを使用して、検出された障害の前記修復可能性を特定し、特定された前記修復可能性に基づいて、通報を行うか否かを決定する。

本発明の一態様に係る障害通報プログラムは、コンピュータを、少なくとも一部の種類の障害を自律的に修復するストレージシステムに生じる前記障害を検出する障害検出手段と、前記障害の種類と当該障害が自律的に修復可能であるか否かを表す修復可能性とが関連付けられている組が、前記障害の種類毎に記録されたイベントテーブルを使用して、前記障害検出手段によって検出された障害の前記修復可能性を特定し、特定された前記修復可能性に基づいて、通報を行うか否かを決定する通報判定手段と、して動作させる。

本発明には、システムの運用に影響を与えずに、コストを削減できる効果がある。

図１は、グリッド・ストレージ・システムを使用して構築されたファイルシステムに対するデータの書き込みを模式的に表す図である。 図２は、ストレージノードに障害が生じた場合の復旧を模式的に表す図である。 図３は、ＨＤＤに障害が生じた場合の復旧を模式的に表す図である。 図４は、一般的な障害通知装置４００を含むストレージシステム２の構成の例を模式的に表す図である。 図５は本発明の第１の実施形態のストレージシステム１の構成の例を表すブロック図である。 図６は、状態テーブルの例を表す図である。 図７は、通報ポリシーテーブルの例を表す図である。 図８は、障害履歴テーブルの例を表すブロック図である。 図９は、イベントテーブルの例を表す図である。 図１０は、本発明の第１の実施形態の障害通報装置１００の動作の例を表すフローチャートである。 図１１は、本発明の第１の実施形態の障害通報装置１００の、影響特定処理の動作の例を表すフローチャートである。 図１２は、本発明の第１の実施形態の障害通報装置１００の、通報方針決定処理の動作の例を表すフローチャートである。 図１３は、本発明の第２の実施形態の障害通報装置１００Ａの構成の例を表すブロック図である。 図１４は、本発明の各実施形態に係る、障害通報装置及びストレージシステムを実現することができる、コンピュータ１０００のハードウェア構成の一例を表す図である。

次に、本発明の実施の形態について、図面を参照して詳細に説明する。

まず、本発明の各実施形態における障害の検出の対象である、グリッド・ストレージ・システムについて説明する。

本発明の各実施形態に係る障害通報装置は、グリッド・ストレージ・システムの運用状況や稼働状況を元に、通報の必要性、および、通報のタイミングの判断を行う。そして、本発明の各実施形態に係る障害通報装置は、その判断に従って通報を行うことにより、人的リソースの使用を減らしながらも、システムの運用に影響を与えないスムーズな運用を図る。

図１は、グリッド・ストレージ・システムを使用して構築されたファイルシステムに対するデータの書き込みを模式的に表す図である。

本発明の各実施形態で対象とするグリッド・ストレージ・システムは、データリクエストの処理を行うアクセラレータノード（図示されない）と、実際にデータを記憶するストレージノードとを含む。図１に示すように、入力データとして、例えば入力データストリーム（データブロック）を受信した場合、アクセラレータノードは、入力データの各データブロックにパリティ値を加え、ｎ個のフラグメントに分割する。そして、そのアクセラレータノードは、複数のストレージノードに対して、分割によって生成されたフラグメントの分散書込み処理を実施する。そのことによって、性能向上と冗長性の確保が図られている。なお、ストレージノードがアクセラレータノードとして動作していてもよい。その場合、データをフラグメントに分割したストレージノードは、そのストレージノードを含むグリッド内の各ストレージノードへ各フラグメントを振り分ける。ストレージノードは、フラグメントが振り分けられたストレージノードに、そのフラグメントの書き込みを行う。なお、各ストレージノードは、データの書き込みの際、既に保存されているデータブロックと同じ内容のデータブロックを新たに書き込まない、重複排除を行う。各ストレージノードは、同じフラグメントは二回書き込まれないように構築されている。そのため、重複排除率が高くなると、実際にＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）に実際に書き込まれるデータ量が減少し、ストレージへのデータの転送量（スループット）が増加する。

また、各ストレージノードは、コンポーネントと呼ばれる論理的な記憶領域を複数持っている。各ストレージノードは、フラグメントをそれらのコンポーネントに格納する。コンポーネントの各ノードに対する配置は、システムによって自律的に行われる。ノード障害／ＨＤＤ障害などの障害が原因で一部のフラグメントにアクセスできなくなった場合、例えば正常に稼働しているストレージノードが、その障害の影響を受けたコンポーネントは、正常に稼働しているＨＤＤ／ノードに自律的に移動させる。例えば、アクセス出来なくなったフラグメントが移動してきたストレージノードは、そのフラグメントを、正常に稼働しているノード／ＨＤＤのデータとパリティを使用して復旧する。このように、グリッド・ストレージ・システムは、復旧完了後に冗長性を取り戻すため、高い耐障害性を発揮する。

図２は、ストレージノードに障害が生じた場合の復旧を模式的に表す図である。図３は、ＨＤＤに障害が生じた場合の復旧を模式的に表す図である。

本実施形態の障害通報装置は、上記のような高い耐障害性をもつグリッド・ストレージ・システムにおいて、障害が発生した場合、障害の内容、障害履歴、運用及び稼働の状態によって、通報方式を選択する。そして、本実施形態の障害通報装置は、選択された通報方式に沿って通報を行う。

次に、比較のために、ストレージシステムに発生する障害を検出する、一般的な障害通報装置について、図面を参照して詳細に説明する。

図４は、一般的な障害通報装置４００を含むストレージシステム２の構成の例を模式的に表す図である。ストレージシステム２は、例えば、上述のグリッド・ストレージ・システムである。図４に示すストレージシステムは、複数のストレージノード２０１と、障害通報装置４００とを含む。障害通報装置４００は、障害検出部４０１と、通報判定部４０２と、イベント記憶部４０５と、通報部４１１と、通報レベル受信部４０３と、通報レベル記憶部４０４とを含む。障害通報装置４００には、ユーザ端末３００が通信可能に接続されている。

障害検出部４０１は、ストレージシステムに発生する障害を検出する。具体的には、障害検出部４０１は、ストレージシステム２に含まれるいずれかのストレージノードに発生する、ＨＤＤ障害やノード障害などを検出する。障害検出部４０１は、障害モニターとも呼ばれる。障害が検出された場合、障害検出部４０１は、通報判定部４０２に対して、検出された障害の種類を表す障害イベントを送信する。

イベント記憶部４０５は、障害の種類ごとに、障害の重要度（すなわちイベントレベル）が記録されているイベントテーブルを記憶する。

ユーザは、ユーザ端末３００を使用して、通報対象のイベントレベルを設定する。ユーザが設定したイベントレベル以上のイベントが、通報対象である。

通報レベル受信部４０３は、ユーザがユーザ端末３００を使用して設定したイベントレベルを受信する。通報レベル受信部４０３は、受信したイベントレベルを、通報レベル設定として、通報レベル記憶部４０４に格納する。

通報レベル記憶部４０４は、ユーザが設定した通報対象のイベントレベルを表す、通報レベル設定を記憶する。

通報判定部４０２は、障害検出部４０１から障害イベントを受信する。通報判定部４０２は、受信した障害イベントが表す障害のイベントレベルを、イベント記憶部４０５が記憶するイベントテーブルから読み出す。通報判定部４０２は、さらに、通報レベル記憶部４０４から、通報レベル設定を読み出す。通報判定部４０２は、読み出したイベントレベルが通報レベル設定として設定されているイベントレベル以上である場合、通報部４１１に、通報を指示する。本発明の各実施形態の説明では、通報判定部４０２を、緊急度判別機構とも表記する。

通報部４１１は、通報判定部４０２から通報を支持された場合、直ちに通報を行う。

＜第１の実施形態＞
次に、本発明の第１の実施の形態について図面を参照して詳細に説明する。

図５は本実施形態のストレージシステム１の構成の例を表すブロック図である。

図５を参照すると、本実施形態のストレージシステム１は、障害通報装置１００と、複数のストレージノード２０１とを含む。障害通報装置１００は、ユーザ端末３００と、通信可能に接続されている。障害通報装置１００は、ストレージシステム１に含まれているのではなく、ストレージシステム１に通信可能に接続されていてもよい。

障害通報装置１００は、障害検出部１０１と、通報判定部１０２と、状態検出部１０３と、影響特定部１０４と、イベント記憶部１０５と、状態記憶部１０６と、履歴記憶部１０７と、処置受信部１０８と、ポリシー記憶部１０９と、ポリシー受信部１１０と、通報部１１１とを含む。

状態検出部１０３は、ストレージシステム１の運用及び稼働情報を検出する。具体的には、状態検出部１０３は、例えば以下のように、ストレージシステム１の運用及び稼働情報を検出すればよい。

まず、状態検出部１０３は、ストレージシステム１がサービスを提供中であるか否か（すなわち、ストレージシステム１が稼働中であるか否か）を表す情報を、例えば、ストレージシステム１のアクセラレータノードから受信する。状態検出部１０３は、ストレージシステム１がサービスを提供中であるか否かを表す情報を、状態記憶部１０６に格納する。

状態検出部１０３は、ストレージシステム１の、データの重複排除率とデータの転送量とを、例えば、ストレージシステム１のアクセラレータノードから受信する。状態検出部１０３は、各ストレージノードの、データの重複排除率とデータの転送量とを、各ストレージノードから取得してもよい。データの転送量は、例えば、あらかじめ定められた期間内に転送されたデータの量である。データの重複排除率は、例えば、上述の期間内に重複排除が行われたデータの割合である。そして、状態検出部１０３は、データ転送量を合計することによって、ストレージシステム１全体のデータ転送量を算出する。さらに、状態検出部１０３は、各ストレージノードのデータ転送量と重複排除率とを使用して、ストレージシステム１全体の、データの重複排除率を算出する。なお、状態検出部１０３は、各ストレージノードから、データ転送量と、重複排除が行われたデータの量である重複排除量とを受信してもよい。そして、状態検出部１０３は、受信したデータ転送量と重複排除量とを使用して、ストレージシステム１全体の重複排除率を算出してもよい。

状態検出部１０３は、ストレージシステム１全体のデータ転送量と、計算した重複排除率とを、運用及び稼働情報として、状態記憶部１０６に格納する。状態検出部１０３は、取得した、運用及び稼働情報を、例えば、運用及び稼働情報の履歴が記録されるテーブルとして、状態記憶部１０６に格納すればよい。以下の説明では、状態記憶部１０６に格納される、運用及び稼働情報の履歴が記録されるテーブルを、「状態テーブル」とも表記することにする。本発明の各実施形態では、状態検出部１０３は、運用と稼働モニターとも表記される。

各ストレージノードは、定期的に、データの転送量と、重複排除率とを、状態検出部１０３に送信するように設計されていればよい。各ストレージノードは、状態検出部１０３からの要求に応じて、データの転送量と、重複排除率とを、状態検出部１０３に送信するように設計されていてもよい。本発明の各実施形態の説明において、運用及び稼働情報を、単に「状態」とも表記することにする。

状態記憶部１０６は、最も新しい運用及び稼働情報、及び、運用及び稼働情報の履歴（すなわち、過去に検出された運用及び稼働情報）を、例えば上述の状態テーブルとして記憶する。

図６は、状態テーブルの例を表す図である。図６に示す例では、あらかじめ定められた時間帯毎に測定された、転送量と重複排除率とが、状態テーブルに記録されている。

ポリシー受信部１１０は、ユーザが例えばユーザ端末３００を使用して入力した、通報を行うポリシーを、そのユーザ端末３００から受信する。ポリシー受信部１１０は、受信した上述のポリシーを、例えば通報ポリシーテーブルとして、ポリシー記憶部１０９に格納する。

ポリシー記憶部１０９は、通報を行う基準として使用される通報ポリシーを、例えば、テーブル形式で記憶する。以下の説明では、ポリシー記憶部１０９が記憶する、通報ポリシーが記録されるテーブルを、「通報ポリシーテーブル」と表記することにする。

図７は、通報ポリシーが記録されている通報ポリシーテーブルの例を表す図である。
本実施形態では、通報ポリシーは、障害がストレージシステム１に与える影響の大きさの程度（すなわち性能の低下の程度）を表す低下率の範囲に応じた、通報の有無と、通報の時間帯とを含む。通報ポリシーは、あらかじめポリシー記憶部１０９に格納されていてもよい。通報ポリシーは、ユーザによって定義されてもよい。通報ポリシーは、ユーザによって変更されてもよい。

障害検出部１０１は、ストレージシステム１に生じる障害を検出する。具体的には、障害検出部１０１は、ストレージシステム１に含まれる各ストレージノードに生じる障害を検出する。障害検出部１０１は、障害が発生したストレージノードから、発生した障害を特定できる信号を受信した場合に、そのストレージノードにおける障害の発生を検出してもよい。障害検出部１０１は、例えば、ストレージノードの生死と特定する信号を、定期的に各ストレージノードに送信することによって、障害の発生を検出してもよい。障害検出部１０１は、障害の発生を検出した場合、発生した障害の内容を表す障害イベント情報を、通報判定部１０２に送信する。障害検出部１０１は、さらに、発生した障害の内容を表す情報を、例えば、テーブルの形式で、履歴記憶部１０７に格納する。以下の説明では、履歴記憶部１０７が記憶する、発生した障害の内容を表す情報が記録されるテーブルを、「障害履歴テーブル」と表記することにする。

処置受信部１０８は、ユーザが、例えばユーザ端末３００を使用して入力した、発生した障害に対する処置の状態を、ユーザ端末３００から受信する。処置の状態は、例えば、処置が完了したことを表す対処済み、処置が完了していないことを表す処置待ち、及び、処置が必要ないことを表す対処不要などのいずれかを表すデータ値である。処置受信部１０８は、受信した処置の状態を、履歴記憶部１０７に格納する。処置受信部１０８は、受信した処置の状態に応じて、履歴記憶部１０７に格納されている障害履歴テーブルを更新すればよい。

履歴記憶部１０７は、発生した障害の内容を表す情報の履歴と、それらの障害に対する処置の状態とを、例えば、前述の障害履歴テーブルとして記憶する。以下の説明では、発生した障害の内容を表す情報の履歴を、障害履歴と表記する。また、障害履歴に含まれる障害に対する処置の状態を、処置履歴と表記する。

図８は、履歴記憶部１０７に格納されている、障害履歴テーブルの例を表すブロック図である。「発生日時」及び「障害の種類」は、障害検出部１０１によって格納された、発生した障害の内容を表す情報である。図８において、「対処状態」は、処置受信部１０８によって格納された、上述の処置の状態を指す。

イベント記憶部１０５は、障害イベント情報によって発生が通知される障害の種類（内容）と、その障害の性質とを含むイベント情報を、例えばテーブルの形式で記憶する。以下の説明では、イベント記憶部１０５が記憶する、イベント情報が記録されるテーブルを、「イベントテーブル」と表記することにする。障害の性質は、例えば、以下で説明する、自律的復旧の有無と、自律的復旧の復旧までの見込み時間と、対処の必要性とを含む。

図９は、イベント記憶部１０５に格納される、イベント情報を表すイベントテーブルの例を表す図である。

図９に示す例では、イベント情報は、障害の内容と、自律的復旧の有無と、自律的復旧の復旧までの見込み時間と、対処の必要性とを含む。障害の内容は、例えば、発生した障害の種類を表す。障害の内容は、例えば、あらかじめ定義されている、障害の種類のいずれかを表す。自律的復旧の有無は、ストレージノードが、発生した障害から、自律的に復旧できる可能性があるか否かを表す。自律的復旧は、発生した障害がストレージシステム１の運用に影響を与えない状態になるように、ストレージノードが、使用するハードウェアの入れ替えやデータの復旧などを、自律的に行うことを表す。自律的復旧の復旧までの見込み時間は、自律的に復旧する場合において、障害が発生してから自律的な復旧が完了するまでに要する見込み時間を表す。対処の必要性は、例えば故障した部品の交換などの、人手による対処（すなわち作業）が必要であるか否かを表す。イベントテーブルは、あらかじめイベント記憶部１０５に格納されている。

影響出部１０４は、状態記憶部１０６に格納されている、例えば運用と稼働状態テーブルに記録されている、重複排除率とデータ転送量を読み出す。影響特定部１０４は、重複排除率などの、運用に応じて変化する変動要素の影響を排除した、障害がストレージシステム１に与える影響の大きさの程度を算出する。障害がストレージシステム１に与える影響の大きさは、例えば、ストレージシステム１の性能の低下として発現する。ストレージシステム１の性能の１つは、データ転送量によって表される。本実施形態では、影響特定部１０４は、ストレージシステム１の性能の低下の程度を表す値として、障害の影響による現在のデータ転送量の低下の程度を表す低下率を算出する。本発明の各実施形態の説明において、「低下率」は、重複排除率などの、運用に応じて変化する変動要素の影響を排除した、障害の影響による現在のデータ転送量の低下の程度を表す低下率を表す。

影響特定部１０４は、さらに、例えば通報ポリシーに基づいて、算出した低下率に応じた、障害がストレージシステム１の運用に及ぼす影響の大きさを特定する。本実施形態では、影響の大きさは、「大」、「小」、「無」のいずれかである。

通報判定部１０２は、ポリシー記憶部１０９から、例えば通報ポリシーテーブルとして記憶されている、通報ポリシーを読み出す。通報判定部１０２は、さらに、イベント記憶部１０５から、例えばイベントテーブルとして格納されている、イベント情報を読み出す。通報判定部１０２は、影響特定部１０４から、特定された、影響の大きさを受信する。通報判定部１０２は、履歴記憶部１０７から、例えば障害履歴テーブルとして格納されている、障害履歴及び処置履歴を読み出す。通報判定部１０２は、通報ポリシーと、イベント情報と、影響の大きさと、障害履歴と、処置履歴とに基づいて、通報の方針を決定する。通報の方針は、通報を行うか否かと、通報を行う場合における通報を行う時間帯とを含む。通報判定部１０２は、決定した通報の方針に従って、通報部１１１に通報を行う指示である通報指示を送信する。本実施形態の説明において、影響特定部１０４及び通報判定部１０２の組み合わせは、緊急度判別機構とも表記される。

通報部１１１は、通報判定部１０２からの通報指示を受信するのに応じて、例えば、ＳＮＭＰトラップや、メールによって、通報を行う。通報部１１１は、例えば、ユーザ端末３００に対して、通報を行う。通報部１１１は、スケジュール機能を備え、そのスケジュール機能によって、通報を行う時間帯が定められている場合、その定められている時間帯に、通報を行う。本実施形態の説明において、通報部１１１は、通報機構とも表記される。

次に、本発明の第１の実施の形態の動作について図面を参照して説明する。
図１０は、本実施形態の障害通報装置１００の動作の例を表すフローチャートである。

図１０を参照すると、まず、障害検出部１０１が、ストレージシステム１の障害を検出する（ステップＳ１０１）。障害が検出されない場合（ステップＳ１０２においてＮｏ）、障害検出部１０１は、ステップＳ１０１の障害を検出する動作を継続する。障害が検出された場合（ステップＳ１０２においてＹｅｓ）、障害検出部１０１は、影響特定部１０４に対して、検出した障害が発生したことを表す障害イベントを送信する。

障害イベントを受信した場合、影響特定部１０４は、状態記憶部１０６から、状態テーブルとして格納されている、ストレージシステム１の状態を読み出す。影響特定部１０４は、さらに、ポリシー記憶部１０９から、通報ポリシーテーブルとして格納されている通報ポリシーを読み出す（ステップＳ１０３）。さらに、影響特定部１０４は、影響特定処理を行う（ステップＳ１０４）。ステップＳ１０４の影響特定処理については、後で詳細に説明する。影響特定部１０４は、影響特定処理によって、障害がストレージシステム１の運用に及ぼす影響の大きさを推定する。前述のように、本実施形態では、影響特定部１０４が推定する影響の大きさは、「大」、「小」、及び「無」のうちのいずれかである。影響特定部１０４が推定する影響の大きさは、「大」、「小」、及び「無」の３段階に限られない。影響特定部１０４が推定する影響の大きさは、「影響度」とも表記される。影響特定部１０４は、受信した障害イベントを通報判定部１０２に転送する。影響特定部１０４は、さらに、推定した影響の大きさを、通報判定部１０２に送信する。

次に、通報判定部１０２が、受信した障害イベントのイベント情報（すなわち、発生した障害に関する情報）を、イベント記憶部１０５から読み出す（ステップＳ１０５）。通報判定部１０２は、さらに、障害履歴を履歴記憶部１０７から読み出す（ステップＳ１０６）。通報判定部１０２は、受信した障害イベントによって特定される、発生した障害と同じ障害の障害履歴を読み出してもよい。通報判定部１０２は、発生した障害が、繰り返し発生しているか否かを判定する。通報判定部１０２は、例えば、あらかじめ定められている期間中に、あらかじめ定められている回数以上の回数、発生した障害と同じ種類の障害が同じストレージノードにおいて発生している場合、その発生した障害が繰り返し発生していると判定すればよい。通報判定部１０２が、障害が繰り返し発生しているか否かを判定する基準である期間及び回数は、ユーザによって指定可能であってもよい。発生した障害が対処済みである場合、障害通報装置１００は、図１０に示す動作を終了してもよい。

次に、通報判定部１０２は、通報方針決定処理を行う（ステップＳ１０７）。ステップＳ１０７の通報方針決定処理については、後で詳細に説明する。通報判定部１０２は、通報方針決定処理によって、通報を行うか否か、及び、通報を行う場合のタイミングを決定する。

通報を行う場合（ステップＳ１０８においてＹｅｓ）、通報判定部１０２は、通報を行う指示である通報指示と、通報のタイミングとを、通報部１１１に送信する。通報指示は、障害の内容（障害の種類）を含んでいればよい。通報指示は、障害が発生したストレージノードを特定する情報を含んでいてもよい。通報のタイミングは、例えば、即時、又は、時間帯である。通報指示を受信した場合、通報部１１１は、受信した通報のタイミングに従って、通報を行う（ステップＳ１０９）。通報のタイミングが即時である場合、通報部１１１は、通報指示を受信するとすぐに、通報を実行する。通報のタイミングが時間帯である場合、通報部１１１は、時刻がその時間帯になるまで待機した後、通報を実行する。そして、障害通報装置１００は、図１０に示す動作を終了する。

通報を行わない場合（ステップＳ１０８においてＮｏ）、障害通報装置１００は、図１０に示す動作を終了する。

次に、本実施形態の障害通報装置１００の、影響特定処理の動作について、図面を参照して詳細に説明する。

図１１は、本実施形態の障害通報装置１００の、影響特定処理の動作の例を表すフローチャートである。

まず、影響推定部１０４は、障害の発生よるデータ転送量の低下の割合である低下率を算出する（ステップＳ２０１）。影響推定部１０４は、例えば、以下の数１に示す式に従って、低下率を算出する。

次に、影響推定部１０４は、状態記憶部１０６に格納されている、ストレージシステム１がサービスを提供中であるか否か（すなわち、ストレージシステム１が稼働中であるか否か）を表す情報（以下では稼働情報と表記）を読み出す。影響推定部１０４は、その読み出した稼働情報が、ストレージシステム１が稼働中でないことを表す場合（ステップＳ２０２においてＮｏ）、影響推定部１０４は、ストレージシステム１は停止中であると判定する。そして、障害通報装置１００は、図１１に示す動作を終了する。

影響推定部１０４は、読み出した稼働情報が、ストレージシステム１が稼働中であることを表す場合（ステップＳ２０２においてＹｅｓ）、以下のように、算出した低下率を使用して、障害がストレージシステム１の運用に与える影響の大きさを推定する。上述のように、本実施形態の影響推定部１０４は、影響の大きさを３段階で推定する。そのために、影響推定部１０４は、低下率に関する２つの閾値を使用する。それらの閾値は、通報ポリシーとして、ポリシー記憶部１０９に格納されていればよい。影響推定部１０４は、通報ポリシー（図１１に示す動作においては、閾値Ｔ_１及び閾値Ｔ_２）を、ポリシー記憶部１０９から読み出す。そして、影響推定部１０４は、低下率と、読み出した閾値とを比較することによって、影響の大きさを推定する。以下の説明では、閾値Ｔ_１は、閾値Ｔ_２より大きい。閾値Ｔ_１及び閾値Ｔ_２は、例えば、ストレージシステム１のユーザによる設定及び変更が可能であればよい。図７に示す通報ポリシーの例では、Ｔ_１は、４０％である。さらに、Ｔ_２は、１０％である。

低下率がＴ_１より大きい場合（ステップＳ２０４においてＹｅｓ）、影響推定部１０４は、発生した障害の運用への影響が大きいと判定する（ステップＳ２０５）。そして、障害通報装置１００は、図１１に示す動作を終了する。

低下率がＴ_１より小さく（ステップＳ２０４においてＮｏ）、さらに、低下率がＴ_２より大きい場合（ステップＳ２０６においてＹｅｓ）、影響推定部１０４は、発生した障害の運用への影響が小さいと判定する（ステップＳ２０６）。そして、障害通報装置１００は、図１１に示す動作を終了する。

低下率がＴ_２より小さい場合（ステップＳ２０６においてＮｏ、ステップＳ２０８においてＹｅｓ）、影響推定部１０４は、発生した障害の運用への影響が無いと判定する（ステップＳ２０９）。そして、障害通報装置１００は、図１１に示す動作を終了する。

次に、本実施形態の障害通報装置１００の、通報方針決定処理の動作について、図面を参照して詳細に説明する。

図１２は、本実施形態の障害通報装置１００の、通報方針決定処理の動作の例を表すフローチャートである。通報方針決定処理において、通報判定部１０２は、通報を行うか否かと、通報を行う場合の通報のタイミングとを、読み出した通報ポリシーに従って決定する。図１２は、読み出した通報ポリシーが、図７に示す通報ポリシーである場合における動作の例を表す。

ストレージシステム１が運用停止中である場合（ステップＳ３０１においてＹｅｓ）、通報判定部１０２は、直ちに通報を行うことを決定する（ステップＳ３０２）。この場合の通報のタイミングは、「直ちに」である。そして、障害通報装置１００は、図１２に示す動作を終了する。

ストレージシステム１が運用停止中でない場合（ステップＳ３０１においてＮｏ）、通報判定部１０２は、読み出した通報ポリシーに従って、例えば以下のように、通報の方針を決定する。

例えば、まず、障害がストレージシステム１の運用に与える影響が大きいと判定されている場合（ステップＳ３０３においてＹｅｓ）、通報判定部１０２は、発生した障害が、自動復旧する可能性があるか否かを判定する（ステップＳ３０４）。障害がストレージシステム１の運用に与える影響は、前述のように、ステップＳ１０４における影響特定処理によって推定される。発生した障害は、前述のように、受信した障害イベントによって特定される。障害が移動復旧する可能性があるか否かを表す情報は、イベント情報として、イベント記憶部１０５に格納されている。図９に示す例では、「自律的復旧」の「有無」が、障害が移動復旧する可能性があるか否かを表す情報である。

発生した障害が自動復旧する可能性がない障害である場合（ステップＳ３０４においてＮｏ）、通報判定部１０２は、直ちに通報を行うことを決定する（ステップＳ３０２）。そして、障害通報装置１００は、図１２に示す動作を終了する。

発生した障害が自動復旧する可能性がある障害である場合（ステップＳ３０４においてＹｅｓ）、通報判定部１０２は、発生した障害が、見込み時間以内に復旧したか否かを判定する（ステップＳ３０５）。障害検出部１０１が受信する障害イベントは、その障害イベントが表す障害が発生した時刻を含んでいればよい。図９に示す例では、「自律的復旧」の「復旧までの見込み時間」が、発生した障害が復旧するまで見込み時間である。図９に示す例では、「０．５Ｈ」は０．５時間を表す。

通報判定部１０２は、障害が発生してから、その障害が復旧する見込み時間が経過しており、さらに、その障害が復旧していない場合、発生した障害が見込み時間内に復旧しなかったと判定する（ステップＳ３０５においてＮｏ）。その場合、通報判定部１０２は、直ちに通報を行うことを決定する（ステップＳ３０２）。そして、障害通報装置１００は、図１２に示す動作を終了する。

通報判定部１０２は、障害が発生してから、その障害の復旧までの見込み時間が経過していない場合、通報判定部１０２は、障害が発生してから、その障害の復旧までの見込み時間が経過するまで待機してもよい。その場合、障害が発生してから、その障害の復旧までの見込み時間が経過した後、通報判定部１０２は、例えば障害検出部１０１を介して、その障害が復旧したか否かを特定してもよい。その結果、その障害が復旧していない場合、通報判定部１０２は、発生した障害が見込み時間内に復旧しなかったと判定する（ステップＳ３０５においてＮｏ）。

障害が発生してから、その障害の復旧までの見込み時間が経過した後、その障害が復旧していた場合、通報判定部１０２は、発生した障害が見込み時間内に復旧したと判定する（ステップＳ３０５においてＹｅｓ）。その場合、通報判定部１０２は、あらかじめ指定された時間帯に通報を行うことを決定する（ステップＳ３０８）。この場合の通報を行うタイミングは、「あらかじめ指定された時間帯」である。そして、障害通報装置１００は、図１２に示す動作を終了する。

障害による影響は大きくなく（ステップＳ３０３においてＹｅｓ）、小さい場合（ステップＳ３０６においてＹｅｓ）、通報判定部１０２は、通報判定部１０２は、発生した障害が、自動復旧する可能性があるか否かを判定する（ステップＳ３０７）。

発生した障害が自動復旧する可能性がない障害である場合（ステップＳ３０７においてＮｏ）、通報判定部１０２は、あらかじめ指定された時間帯に通報を行うことを決定する（ステップＳ３０８）。そして、障害通報装置１００は、図１２に示す動作を終了する。

発生した障害が自動復旧する可能性がある障害である場合（ステップＳ３０７においてＹｅｓ）、通報判定部１０２は、発生した障害に対する、人手による対処が必要であるか否かを判定する（ステップＳ３０９）。

障害の影響が小さいのではなく、無い場合（ステップＳ３０６においてＮｏ）、通報判定部１０２は、発生した障害に対する、人手による対処が必要であるか否かを判定する（ステップＳ３０９）。図９に示す例では、「対処の必要性」が、人手による対処が必要であるか否かを表す。通報判定部１０２は、例えば、イベント記憶部１０５に格納されている、発生した状態のイベント情報の「対処の必要性」が、人手による対処が必要であることを表すか否かを判定すればよい。

発生した障害に対する、人手による対処が必要である場合（ステップＳ３０９においてＹｅｓ）、通報判定部１０２は、あらかじめ指定された時間帯に通報を行うことを決定する（ステップＳ３０８）。そして、障害通報装置１００は、図１２に示す動作を終了する。

発生した障害に対する、人手による対処が必要でない場合（ステップＳ３０９においてＮｏ）、通報判定部１０２は、発生した障害が、繰り返し発生しているか否かを判定する（ステップＳ３１０）。発生した障害が、繰り返し発生している場合（ステップＳ３１０においてＹｅｓ）、通報判定部１０２は、あらかじめ指定された時間帯に通報を行うことを決定する（ステップＳ３０８）。そして、障害通報装置１００は、図１２に示す動作を終了する。発生した障害が、繰り返し発生していない場合（ステップＳ３１０においてＮｏ）、通報判定部１０２は、通報を行わないことを決定する（ステップＳ３１１）。そして、障害通報装置１００は、図１２に示す動作を終了する。

以上で説明した本実施形態には、システムの運用に影響を与えずに、コストを削減できるという効果がある。

その理由は、通報判定部１０２が、発生した障害のストレージシステム１に対する影響の大きさ、その障害の自律的復旧の可能性、人手による対処の必要性などに基づいて、通報を行うか否か、及び、通報を行う場合のタイミングを決定するからである。従って、本実施形態では、直ちに対処しなくてもシステムの運用への影響が小さい障害に関する通報が行われる時間帯を限定することができる。また、本実施形態では、例えば、自律的に復旧することが可能な、人手による対処の必要がない、システムの運用への影響が小さい障害の通報を行わないことができる。従って、通報に対処する作業員を待機させておく人数を、時間帯によって限定することができる。すなわち、人的リソースを削減することができる。よって、コストを削減することができる。

＜第２の実施形態＞
次に、本発明の第２の実施形態について、図面を参照して詳細に説明する。本実施形態は、本発明の実施形態の最小構成を表す。

図１３は、本実施形態の障害通報装置１００Ａの構成の例を表すブロック図である。

図１３を参照すると、本実施形態の障害通報装置１００Ａは、少なくとも一部の種類の障害を自律的に修復するストレージシステム１Ａに生じる前記障害を検出する障害検出部１０１と、前記障害の種類と当該障害が自律的に修復可能であるか否かを表す修復可能性とが関連付けられている組が、前記障害の種類毎に記録されたイベントテーブルを使用して、前記障害検出部１０１によって検出された障害の前記修復可能性を特定し、特定された前記修復可能性に基づいて、通報を行うか否かを決定する通報判定部１０２と、を備える。

以上で説明した本実施形態には、システムの運用に影響を与えずに、コストを削減できるという効果がある。その理由は、システムの運用への影響が小さい、ストレージシステム１による自律的な修復が可能な障害が発生しても、本実施形態の障害通報装置１００Ａは通報を行わないからである。従って、通報の回数が減少するので、通報に対処する作業員の人数を削減することができる。すなわち、人的リソースを削減することができる。よって、コストを削減することができる。

＜その他の実施形態＞
障害通報装置１００、障害通報装置１００Ａ、ストレージシステム１、及びストレージシステム１Ａは、それぞれ、コンピュータ及びコンピュータを制御するプログラム、専用のハードウェア、又は、コンピュータ及びコンピュータを制御するプログラムと専用のハードウェアの組合せにより実現することができる。

図１４は、障害通報装置１００、障害通報装置１００Ａ、ストレージシステム１、及びストレージシステム１Ａを実現することができる、コンピュータ１０００のハードウェア構成の一例を表す図である。図１４を参照すると、コンピュータ１０００は、プロセッサ１００１と、メモリ１００２と、記憶装置１００３と、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）インタフェース１００４とを含む。また、コンピュータ１０００は、記録媒体１００５にアクセスすることができる。メモリ１００２と記憶装置１００３は、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ハードディスクなどの記憶装置である。記録媒体１００５は、例えば、ＲＡＭ、ハードディスクなどの記憶装置、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、可搬記録媒体である。記憶装置１００３が記録媒体１００５であってもよい。プロセッサ１００１は、メモリ１００２と、記憶装置１００３に対して、データやプログラムの読み出しと書き込みを行うことができる。プロセッサ１００１は、Ｉ／Ｏインタフェース１００４を介して、例えば、各ストレージノード２０１及びユーザ端末３００にアクセスすることができる。プロセッサ１００１は、記録媒体１００５にアクセスすることができる。記録媒体１００５には、コンピュータ１０００を、障害通報装置１００、障害通報装置１００Ａ、ストレージシステム１、又はストレージシステム１Ａとして動作させるプログラムが格納されている。

プロセッサ１００１は、記録媒体１００５に格納されている、コンピュータ１０００を、障害通報装置１００、障害通報装置１００Ａ、ストレージシステム１、又はストレージシステム１Ａとして動作させるプログラムを、メモリ１００２にロードする。そして、プロセッサ１００１が、メモリ１００２にロードされたプログラムを実行することにより、コンピュータ１０００は、障害通報装置１００、障害通報装置１００Ａ、ストレージシステム１、又はストレージシステム１Ａとして動作する。

障害検出部１０１、通報判定部１０２、状態検出部１０３、影響特定部１０４、処置受信部１０８、ポリシー受信部１１０、及び通報部１１１は、例えば、プログラムを記憶する記録媒体１００５からメモリ１００２に読み込まれた、各部の機能を実現することができる専用のプログラムと、そのプログラムを実行するプロセッサ１００１により実現することができる。また、イベント記憶部１０５、状態記憶部１０６、履歴記憶部１０７、及びポリシー記憶部１０９は、コンピュータ１０００が含むメモリ１００２やハードディスク装置等の記憶装置１００３により実現することができる。あるいは、障害検出部１０１、通報判定部１０２、状態検出部１０３、影響特定部１０４、イベント記憶部１０５、状態記憶部１０６、履歴記憶部１０７、処置受信部１０８、ポリシー記憶部１０９、ポリシー受信部１１０、及び通報部１１１の一部又は全部を、各部の機能を実現する専用の回路によって実現することもできる。

以上、実施形態を参照して本発明を説明したが、本発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

１ ストレージシステム
１Ａ ストレージシステム
２ ストレージシステム
１００ 障害通報装置
１００Ａ 障害通報装置
１０１ 障害検出部
１０２ 通報判定部
１０３ 状態検出部
１０４ 影響特定部
１０５ イベント記憶部
１０６ 状態記憶部
１０７ 履歴記憶部
１０８ 処置受信部
１０９ ポリシー記憶部
１１０ ポリシー受信部
１１１ 通報部
２０１ ストレージノード
３００ ユーザ端末
４００ 障害通報装置
４０１ 障害検出部
４０２ 通報判定部
４０３ 通報レベル受信部
４０４ 通報レベル記憶部
４０５ イベント記憶部
４１１ 通報部
１０００ コンピュータ
１００１ プロセッサ
１００２ メモリ
１００３ 記憶装置
１００４ Ｉ／Ｏインタフェース
１００５ 記録媒体

Claims (10)

1. 少なくとも一部の種類の障害を自律的に修復するストレージシステムに生じる前記障害を検出する障害検出手段と、
   前記障害の種類と当該障害が自律的に修復可能であるか否かを表す修復可能性とが関連付けられている組が、前記障害の種類毎に記録されたイベントテーブルを使用して、前記障害検出手段によって検出された障害の前記修復可能性を特定し、特定された前記修復可能性に基づいて、通報を行うか否かを決定する通報判定手段と、
   を備える障害通報装置。
2. 前記イベントテーブルに記録された前記組前記障害の種類には、さらに、障害に応じて人手による作業が必要か否かを表す対処必要性が関連付けられ、
   前記通報判定手段は、前記通報を行う場合の、当該通報を行う時間帯を、前記修復可能性及び前記対処必要性に応じて決定する
   請求項１に記載の障害通報装置。
3. 前記ストレージシステムの状態を検出する状態検出手段と、
   前記障害が検出されるのに応じて、前記状態の変化に基づいて、前記ストレージシステムに対する前記障害の影響の大きさを推定する影響特定手段と、を備え、
   前記通報判定手段は、さらに前記影響の大きさに基づいて通報を行うか否かを決定し、前記通報を行う場合の、当該通報を行う時間帯を、さらに前記低下率に応じて決定する
   請求項２に記載の障害通報装置。
4. 前記状態検出手段は、データ転送量を含む前記状態を検出し、過去に検出された前記状態の履歴に基づいて、当該履歴における前記転送量の平均である平均データ転送量を算出し、
   前記影響特定手段は、前記平均データ転送量に対する、検出されたデータ転送量の低下の程度を表す前記低下率を算出し、当該低下率に基づいて前記影響の大きさを推定する
   請求項３に記載の障害通報装置。
5. 前記状態検出手段は、さらに、同一データを記憶しない重複排除が行われたデータの量である重複排除率を検出し、過去に検出された前記状態の履歴に基づいて、当該履歴における前記重複排除率の平均である平均重複排除率を算出し、
   前記影響特定手段は、前記重複排除率及び前記平均重複排除率を使用して、前記重複排除率による影響が除かれた前記低下率を算出する
   請求項４に記載の障害通報装置。
6. 請求項１乃至６のいずれかに記載の障害通報装置を含む前記ストレージシステム。
7. 少なくとも一部の種類の障害を自律的に修復するストレージシステムに生じる前記障害を検出し、
   前記障害の種類と当該障害が自律的に修復可能であるか否かを表す修復可能性とが関連付けられている組が、前記障害の種類毎に記録されたイベントテーブルを使用して、検出された障害の前記修復可能性を特定し、特定された前記修復可能性に基づいて、通報を行うか否かを決定する、
   障害通報方法。
8. コンピュータを、
   少なくとも一部の種類の障害を自律的に修復するストレージシステムに生じる前記障害を検出する障害検出手段と、
   前記障害の種類と当該障害が自律的に修復可能であるか否かを表す修復可能性とが関連付けられている組が、前記障害の種類毎に記録されたイベントテーブルを使用して、前記障害検出手段によって検出された障害の前記修復可能性を特定し、特定された前記修復可能性に基づいて、通報を行うか否かを決定する通報判定手段と、
   して動作させる障害通報プログラム。
9. 前記イベントテーブルに記録された前記組前記障害の種類には、さらに、障害に応じて人手による作業が必要か否かを表す対処必要性が関連付けられ、
   コンピュータを、
   前記通報を行う場合の、当該通報を行う時間帯を、前記修復可能性及び前記対処必要性に応じて決定する前記通報判定手段と、
   して動作させる請求項８に記載の障害通報プログラム。
10. コンピュータを、
    前記ストレージシステムの状態を検出する状態検出手段と、
    前記障害が検出されるのに応じて、前記状態の変化に基づいて、前記ストレージシステムに対する前記障害の影響の大きさを推定する影響特定手段と、
    さらに前記影響の大きさに基づいて通報を行うか否かを決定し、前記通報を行う場合の、当該通報を行う時間帯を、さらに前記低下率に応じて決定する前記通報判定手段と、
    して動作させる請求項９に記載の障害通報プログラム。

Images