JP4893663B2 - 障害自動復旧装置 - Google Patents

Description

本発明は、システム上の装置で発生した障害を検知し、適切なタイミングで自動復旧させることを可能にする障害自動復旧装置に関する。

近年、インターネットの普及により、電子商取引やＷｅｂコンテンツの提供等２４時間３６５日決して止まることの許されないミッションクリティカルなシステムが急増している。

システムで障害が発生した際には、速やかかつ安全に復旧を行う必要がある。

しかし、人手を介した復旧作業には、時間もかかり、作業ミスで障害を拡大させてしまう危険性もある。

また、システムが大規模化、複雑化するほど、復旧作業に要する時間や作業ミスの可能性も増大する。

そのため、システムで発生した障害を検知し、自動で復旧するような仕組みが求められている。

システムで発生した障害を検知し、自動で復旧するような仕組みとして、障害の要因と復旧方法を蓄積したＤＢ（データベース）を用意し、障害検出手段によって障害を検出してＤＢに復旧方法を問い合わせ、復旧実施手段によって障害復旧を行う方法がある（例えば下記特許文献１、特許文献２、特許文献３等）。また、復旧方法を複数用意し、優先度に従って復旧方法を試行し、最初に選択した復旧方法で復旧できなければ、次の優先度の復旧方法を試行する仕組みや、更にその優先度を実績等から動的に修正していくことで、より最適な復旧方法が選択できるようにする仕組みもある。

これらの従来技術は、原則として、発生した障害を検知すると直ちに自動復旧するものである。

ここで、障害の復旧を実施するという措置自体が、システムが提供するサービスに何らかの影響を与えてしまう場合や、そうでなくとも冗長性が失われることによりサービス停止のリスクを高めてしまう場合が多いことに着目する。

例えば、復旧方法には、ＡＰ再起動やＯＳ再起動等、その装置が提供しているサービスの停止を伴う場合が多い。また、サービスの停止を伴わなくても、復旧中は冗長性が失われ、一時的であるが片系運用となってしまうリスクは発生する。また、負荷分散を行うシステム構成であれば、復旧中はシステムを構成する装置数が一時的に減少して、システムの性能要件を満たせなくなる場合もある。

一方で、全ての障害が即時の復旧を要するものではなく、障害の発生から多少の時間が経過しても、該当装置の提供するサービスには影響を与えないことも多い。逆に、障害を放置しておくのは非常に危険であり、直ちに復旧を要する場合もある。

障害復旧は、可能な限り早く実施すべきではあるが、緊急性のない障害の場合は、サービスに影響を与えてまで即時復旧をする必要はない。即ち、復旧は、障害の内容に応じて適切なタイミングで行えなければならない。
特開２００５‐３２２０１４号公報 特開２００５‐０８５１７８号公報 特開平０４‐１４７３４７号公報

しかしながら、上記従来の技術では、どのような障害であっても、復旧を即時実施してしまうので、実施のタイミングによってはサービスが停止する、あるいはサービス影響を与えてしまうという問題点があった。また、障害緊急度に応じて即時復旧するか判断については、障害緊急度の増加率を計算して即時復旧が必要となる時間を予想し、アラーム等を上げるなどの対処を行っていないこと、復旧作業による影響度から復旧要否を判断する際に、判断基準としてシステムが保証するサービス要件を配慮していないこと、再スケジュール時に運用要件を配慮していないこと、スケジュール管理テーブルを用いて自動復旧の実施タイミングを制御していないこと等の問題点があった。

そこで、本発明は、上記各問題点に鑑みて為されたもので、その目的の一例は、障害の内容に応じて適切なタイミングで復旧を行うことが可能な障害自動復旧装置を提供することである。

上記の課題を解決するために、請求項１に記載の発明は、障害を自動的に復旧する障害自動復旧装置において、前記障害が発生した旨を示す障害情報を外部から受信する障害検出手段と、前記障害情報と前記障害を復旧する復旧方法とを対応づけて記憶する障害復旧記憶手段と、前記障害情報に基づいて、障害復旧記憶手段内に記憶されている前記復旧方法を決定する復旧方法決定手段と、前記決定された前記復旧方法に応じて、即時に前記障害の復旧を実施するか否かを判断する処理制御手段と、を備え、前記復旧方法には、予め設定された前記障害ごとの緊急度を示す障害緊急度情報と、予め設定された前記障害ごとの復旧の影響度を示す復旧影響度情報と、が含まれており、前記処理制御手段による判断の結果、前記障害が前記障害緊急度情報により即時の復旧が必要とされている前記緊急度の障害である場合、又は前記障害が、前記障害緊急度情報により即時の復旧が必要とされていない前記緊急度の障害ではあるが、前記復旧影響度情報により前記障害の復旧の影響度が全くないとされている前記影響度の障害である場合、前記処理制御手段は、前記復旧方法に基づいて即時に前記障害の復旧を実施し、前記障害が前記障害緊急度情報により即時の復旧が必要とされていない前記緊急度の障害ではあり、且つ前記復旧営業度情報により前記影響度が存在するとされている障害の場合は、所定のタイミングに前記障害の復旧を実施することを特徴とする。

上記の課題を解決するために、請求項２に記載の発明は、請求項１に記載の障害自動復旧装置において、運用ルールとして決められた復旧実施可能時間を含む運用要件が記憶されている復旧実施可能時間記憶手段と、前記障害情報と、前記復旧実施可能時間記憶手段内の前記復旧実施可能時間と、に基づいて復旧実施予定時間を決定する復旧実施時間管理手段と、前記復旧実施時間管理手段により前記復旧実施予定時間が決定された後に、前記復旧実施予定時間、前記障害情報、及び前記復旧方法を復旧実施スケジュール管理テーブルに登録する登録手段と、備え、前記処理制御手段は、前記復旧実施スケジュール管理テーブルに登録された前記復旧実施予定時間になると前記障害の復旧を実施することを特徴とする。

上記の課題を解決するために、請求項３に記載の発明は、請求項２に記載の障害自動復旧装置において、サービスの提供に最低限必要な外部の装置の稼動状況を示すサービス要件が記憶されているサービス要件記憶手段と、前記サービス要件記憶手段内の前記サービス要件を確認するサービス要件確認手段と、前記外部の装置のサービス状況を確認するサービス状況確認手段と、を備え、前記処理制御手段は、前記サービス要件、及び前記サービス状況に基づいて、前記復旧方法を実施した後の状態が前記サービス要件を満たしているか否かを判定し、前記判定の結果、前記サービス要件を満たしている場合は、前記復旧方法に基づいて前記障害の復旧を実施することを特徴とする。

上記の課題を解決するために、請求項４に記載の発明は、請求項３に記載の障害自動復旧装置において、前記判定の結果、前記サービス要件を満たさなくなる場合、前記復旧実施時間管理手段及び前記登録手段は、再度、新たな復旧実施予定時間を前記復旧実施スケジュール管理テーブルに登録し、前記処理制御手段は、新たに登録した復旧実施予定時間になれば前記サービス状況、及び前記サービス要件の確認と前記障害の復旧を実施することができるか否かの判定を行い、更に前記処理制御手段は、前記障害の復旧が実施することができると判定された場合には前記障害の復旧を実施し、前記障害の復旧が実施することができないと判定された場合には再スケジューリングを行うことを特徴とする。

上記の課題を解決するために、請求項５に記載の発明は、請求項４に記載の障害自動復旧装置において、当該障害自動復旧装置の使用者にこのままでは前記運用要件を満たす時間になる前に即時復旧可能な時間に障害が発生する旨のアラームを通知するアラーム通知手段を更に備え、前記復旧実施スケジュール管理テーブルに前記復旧実施予定時間を登録し、同じ障害要因の復旧実施予定が既に登録されている場合には、前記処理制御手段は、前記障害の緊急度の増加率と前記障害の発生時間との比較により、前記障害の緊急度が即時の復旧を必要とするようになる時間を予想し、当該予想した時間が前記復旧実施予定時間より遅い場合は何もせず待機し、前記予想した時間が前記復旧実施予定時間より早い場合は前記アラーム通知手段にアラーム通知の指示を出すことを特徴とする。

本発明によれば、障害の緊急度、復旧作業の影響度、システムの運用要件によって自動復旧作業の実施時間をスケジューリングするため、障害の内容に応じて適切なタイミングで自動復旧を行うことができる。

また本発明によれば、サービス状況を確認してから自動復旧を行うため、復旧措置自体がもたらすサービス影響を防ぐことができる。

更にまた本発明によれば、障害緊急度と発生時間から障害が致命的となる時間を予測し、オペレータに通知するため、障害が悪化して適切なタイミングに自動復旧できないが予想される場合でも、障害が致命的となる前にオペレータが対応を検討することができる。

次に、本発明に好適な実施の形態について、図面に基づいて説明する。なお、以下の説明は、障害自動復旧装置に対して本発明を適用した場合の実施形態である。

本発明の実施形態の構成について、図１を用いて説明する。

図１は、本実施形態に係る障害自動復旧装置１の概略構成を示す図である。

図１に示すように、障害自動復旧装置１は、処理制御手段１１、復旧実施スケジュール管理テーブル１１１、障害検出手段１２、復旧方法決定手段１３、障害復旧ＤＢ１３１（障害復旧記憶手段の一例）、復旧実施時間管理手段１４、復旧実施可能時間ＤＢ１４１（復旧実施可能時間記憶手段の一例）、復旧実施手段１５、サービス要件確認手段１６、サービス要件ＤＢ１６１（サービス要件記憶手段の一例）、サービス状況確認手段１７、アラーム通知手段１８を含む。

処理制御手段１１は、全体の処理を制御し、他の手段に対して情報の受け渡し、判断、指示をする機能を含む。なお、処理制御手段１１の詳細については後述する。

サービス提供手段２の概略構成について、図２を用いて説明する。

図２は、サービス提供手段２の概略構成を示す図である。

図２に示すように、サービス提供手段２は、Ｗｅｂサーバ２１〜２Ｎを含む複数のサーバ群から構成される。

Ｗｅｂサーバ２１〜２Ｎは、Ｎ台全現用で負荷分散を行っており、Ｎ−１台のサーバが稼動していれば、システムが保証するサービス要件を満たす（可用性向上のために１台分冗長な構成としている）。

また、サーバ種別２０は、サーバの種別を表し、本実施形態の場合、Ｗｅｂサーバ２１〜２Ｎのサーバ種別２０は、全て「Ｗｅｂサーバ」である。

障害検出手段１２は、サービス提供手段２から発行される障害情報３を受領し、処理制御手段１１に障害情報３を渡す。

図３は、障害情報３の構成を示す図である。

図３に示すように、障害情報３には、対象サーバ３１、障害発生時間３２、障害要因３３、障害状況３４が含まれる。

例えば、対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「メモリ残量が枯渇」、障害状況「メモリ残量１００ＭＢ」、のようになる。

復旧方法決定手段１３は、処理制御手段１１より障害情報３とサーバ種別２０を受け取り、サーバ種別２０、障害要因３３、障害状況３４をキーにして、障害復旧ＤＢ１３１に問い合わせを行い、復旧方法４を決定し、決定した復旧方法４を処理制御手段１１に返す。

図４は、復旧方法４を説明するための図である。

図４に示すように、復旧方法４には、復旧方法詳細４１と障害緊急度４２と復旧影響度４３が含まれる。

復旧方法詳細４１は、復旧方法の詳細を表す。例えば、「ＡＰ再起動」、「ＯＳ再起動」、「ログ出力先の切替」等である。

障害緊急度４２は、障害の緊急度を表す。「０」〜「１００」の値を取り、「１００」であれば、即時復旧を必要とする。

復旧影響度４３は、復旧作業の影響度を表す。「０」以下の値（下限なし）を取り、「０」であれば復旧作業による影響が全くない。「０未満」であれば作業影響がある。本実施形態の場合は、「０」又は「−１」の値を取り、「−１」の場合は、対象サーバは、復旧作業中のサービス提供一切不可を表す。

図５は、障害復旧ＤＢ１３１を説明するための図である。

図５に示すように、障害復旧ＤＢ１３１には、障害情報３と復旧方法４の対応表が蓄積されている。

復旧実施時間管理手段１４は、処理制御手段１１よりサーバ種別２０、再スケジュールフラグ１４２を受け取り、復旧実施可能時間ＤＢ１４１に問い合わせを行って、復旧実施予定時間５を決定し、決定した復旧実施予定時間５を処理制御手段１１に返す。

図６は、復旧実施可能時間ＤＢ１４１を説明するための図である。

図６に示すように、復旧実施可能時間ＤＢ１４１には、サーバ種別２０、サーバ種別ごとに運用ルールとして決められた復旧実施可能時間１４１１、再スケジュール間隔１４１２を含む。

再スケジュールフラグは、「０」又は「１」の値を持ち、「０」であれば新規の障害発生による問い合わせ、「１」であれば復旧を実施しようとしたが、現状のサービス稼動状況で復旧を実施するとサービス要件を満たさなくなってしまうため、再スケジューリングを行うときの問い合わせを表す。

再スケジュール間隔１４１２は、再スケジュール時の間隔を表す。再スケジューリングフラグ１４２が「１」の時は、現在時刻に再スケジューリング間隔１４１２をプラスした時刻を処理制御手段１１に返す。ただし、プラスした時刻が復旧実施可能時間１４１１を超えている場合は、次の復旧実施可能時間１４１１を返す。

復旧実施時間管理手段１４の動作について、図７を用いて説明する。

復旧実施手段１５は、処理制御手段１１から対象サーバ３１、復旧方法詳細４１を受け取り、復旧方法詳細４１に従って、対象サーバ３1を復旧する。

復旧が完了したら、処理制御手段１１に復旧完了の応答を返す。

サービス要件確認手段１６は、処理制御手段１１から対象サーバ３１のサーバ種別２０を受け取り、サーバ種別２０のサービス要件指数１６１２をサービス要件ＤＢ１６１に問い合わせ、得られたサービス要件指数１６１１を処理制御手段１１に返す。

図８は、サービス要件ＤＢ１６１を説明するための図である。

図８に示すように、サービス要件ＤＢ１６１には、サーバ種別２０とサービス要件指数１６１１が蓄積されている。

サービス要件指数１６１１は、サーバ種別２０のサーバ群がサービスを提供するのに最低限必要なサーバ稼動台数を表す。

サービス状況確認手段１７は、処理制御手段１１からサーバ種別２０を受け取り、サービス提供手段２に問い合わせ、サーバ種別２０のサービス状況指数１７１を確認し、処理制御手段１１に得られたサービス状況指数を返す。

サービス状況指数１７１は、その時点で稼動中のサーバ種別２０のサーバ群のサーバ台数の総計を表す。

アラーム通知手段１８は、処理制御手段１１の指示を受けて、オペレータ５０にアラームを通知する。

処理制御手段１１の動作について、図９乃至１１を用いて説明する。

なお、必要に応じてサーバ種別ＤＢ１１２を参照して、対象サーバ３１のサーバ種別２０を特定する。

図９は、障害検出してから復旧実施の時間を決定するまでのフローを示す図である。

障害検出手段１２から障害情報３を受け取る（ステップ９０１）。

ステップ９０１で受け取った障害情報３とサーバ種別２０を復旧方法決定手段１３に渡し、復旧方法４を受け取る（ステップ９０２）。

ステップ９０２で受け取った復旧方法４の障害緊急度４２が「１００」、あるいは復旧影響度４３が負（０未満）である場合は、図１１のステップ１１０１（復旧作業）を実施し、そうでない場合は、ステップ９０４を実施する（ステップ９０３）。

復旧実施スケジュール管理テーブル１１１を参照して、対象サーバ３１、障害要因３３の両方が同じものが、既にスケジュールされているか確認する（ステップ９０４）。

両方が同じものがある場合は、ステップ９０６を行い、同じものがない場合は、ステップ９１０を行う（ステップ９０５）。

処理中の障害の障害発生時間３２（Ａ１）、障害緊急度４２（Ｂ１）と登録済の復旧実施スケジュールの障害発生時間３２（Ａ２）、障害緊急度４２（Ｂ２）から、以下の式で障害緊急度４２が「１００」となる予想される時間を算出する（ステップ９０６）。

１時間あたりの障害緊急度の増加率（Ｃ）：（Ｂ１−Ｂ２）／（Ａ１−Ａ２）
障害緊急度１００となるまでの余力（Ｄ）：１００−Ｂ１
障害緊急度１００となる予想時間（Ｅ）：Ａ１＋Ｄ／Ｃ
例えば、Ａ１＝１２：００、Ｂ１＝９５、Ａ２＝１０：００、Ｂ２＝９０であれば、Ｃ＝（９５−９０）／（１２：００−１０：００）＝５／２＝２．５、Ｄ＝１００−９５＝５、Ｅ＝１２：００＋５／２．５＝１４：００と計算する。

ステップ９０６において算出した予想時間（Ｅ）と復旧実施スケジュールの復旧実施予定時間５とを比較して、予想時間（Ｅ）の方が復旧実施予定時間５よりも早い時間である場合はステップ９０８の処理を行い、遅い場合はステップ９０９の処理を行う（ステップ９０７）。

アラーム通知手段１７にオペレータにアラーム通知をするよう指示を出す（ステップ９０８）。

復旧実施予定時間５となるか、新たな障害を検知するまで待機する（ステップ９０９）。

復旧実施時間管理手段１４にサーバ種別２０、再スケジュールフラグ１４２「０」を渡し、復旧実施予定時間５を受け取る（ステップ９１０）。

ステップ９１０において受け取った復旧実施予定時間５と、対象サーバ３１、障害要因３３、障害発生時間３２、復旧方法詳細４１、障害緊急度４２、復旧影響度４３からなる復旧実施スケジュール１１１１とを復旧実施スケジュール管理テーブル１１１に新規登録し、ステップ９０９の処理を行う（ステップ９１１）。

図１０は、復旧実施予定時間となってから復旧を行うまでのフローを示す図である。

復旧実施スケジュール管理テーブル１１１を常に参照し、復旧実施スケジュール１１１１の復旧実施予定時間５となったら、ステップ１００２、及びステップ１００３を実施する（ステップ１００１）。

サービス要件確認手段１６に対象サーバ３１のサーバ種別２０を渡してサービス要件指数１６１１を受け取る（ステップ１００２）。

サービス状況確認手段１７に対象サーバ３１のサーバ種別２０を渡してサービス状況指数１７１を受け取る（ステップ１００３）。

ステップ１００２、及び１００３において受け取ったサービス要件指数１６１１（Ｆ）、サービス状況指数１７１（Ｇ）と復旧影響度４３（Ｈ）から、以下の式で復旧実施の可否を判定する（ステップ１００４）。

復旧実施可否（Ｈ）：Ｇ＋Ｈ−Ｆ
Ｈが「０以上」であれば復旧実施可能、「０未満」であれば復旧実施不可能と判定する。

ステップ１００４の判定結果で、復旧実施可能であれば図１１のステップ１１０１（復旧作業）を実施し、復旧実施不可能であればステップ１００６を行う（ステップ１００５）。

復旧実施時間管理手段１４にサーバ種別２０、再スケジュールフラグ１４２「１」を渡し、復旧実施予定時間５を受け取る（ステップ１００６）。

機能１８により再スケジュールした復旧実施予定時間５を受け取り、復旧実施スケジュール１１１１の復旧実施予定時間５を更新して、ステップ１００８の処理を行う（ステップ１００７）。

復旧実施予定時間５となるか、新たな障害を検知するまで待機する（ステップ１００８）。

図１１は、実際に復旧を行った後のフローを示す図である。

復旧実施手段１５に対象サーバ３１、復旧方法詳細４１を渡して復旧指示を行い、復旧完了の通知を受け取る（ステップ１１０１）。

ステップ１００１において復旧完了の通知を受け取ると、復旧実施スケジュール管理テーブル１１１を参照して、対象サーバ３１、復旧方法詳細４１の両方が同一のスケジュール１１１１が存在するか確認する（ステップ１１０２）。

ステップ１００２の確認結果で存在すればステップ１００４の処理を行い、存在しなければステップ１００５の処理を行う（ステップ１１０３）。

該当スケジュール１１１１を削除し、ステップ１００５の処理を行う（ステップ１１０４）。

復旧実施予定時間５となるか、新たな障害を検知するまで待機する（ステップ１１０５）。

図１２は、復旧実施スケジュール管理テーブル１１１を説明するための図である。

図１２に示すように、復旧実施スケジュール管理テーブル１１１は、対象サーバ３1、障害要因３３、障害発生時間３２、復旧方法詳細４１、障害緊急度４２、復旧影響度４３、復旧実施予定時間５からなる復旧実施スケジュール１１１１を含む。

サーバ種別管理ＤＢ１１２は、サーバとサーバ種別の対応表で、必要に応じて、制御処理手段１１から参照される。

なお、サーバ種別管理ＤＢ１１２は、本実施形態の場合にのみ必要なＤＢであり、障害自動復旧装置１の構成には必須なＤＢというわけではない。

次に、本実施形態の動作の概略について説明する。

障害自動復旧装置１は、障害検出手段１２によってサービス提供手段２を常に監視している。

サービス提供手段２は、障害が発生すると、障害自動復旧装置１に障害が発生した旨を障害情報という形で伝える。

障害自動復旧装置１は、障害検出手段１２によって障害情報を受け取ると、受け取った障害情報を処理制御手段１１に渡す。

処理制御手段１１は、受け取った障害情報を復旧方法決定手段１３に渡し、復旧方法の問い合わせを行う。

復旧方法決定手段１３は、処理制御手段１１より障害情報を受け取ると、障害情報をキーにして障害復旧ＤＢ１３１に問い合わせて復旧方法を決定し、処理制御手段１１に決定した復旧方法を返す。

障害復旧ＤＢ１３１には、障害情報と復旧方法の対応表が蓄積されている。

復旧方法には、障害の緊急性や復旧措置の影響度を表す情報が含まれており、処理制御手段１１は、これらの値に応じて、即時で復旧を行うか否かを判断する。

障害の緊急性が高く即時で復旧が必要である場合や、緊急性は高くなくとも復旧措置の影響が全くない場合は、処理制御手段１１は、即座に復旧実施手段１５に復旧指示を出す。

復旧実施手段１５は、処理制御手段１１より指示を受けると復旧方法に従い障害の復旧を行う。

それ以外の場合、すなわち、緊急性は低いが復旧措置がサービスに影響を与えてしまう場合は、適切なタイミングに復旧を実施するようスケジューリングする。

まず、処理制御手段１１は、復旧実施時間管理手段１４に障害情報を渡して、復旧実施予定時間を問い合わせる。

復旧実施時間管理手段１４は、障害情報をキーにして復旧実施可能時間ＤＢ１４１に問い合わせを行い、復旧実施予定時間を決定し、決定した復旧実施予定時間を処理制御手段１１に返す。

復旧実施可能時間ＤＢ１４１には、運用ルールとして決められた復旧実施可能時間などの運用要件が蓄積されている。

処理制御手段１１は、復旧実施予定時間を受け取ると、復旧実施予定時間、障害情報、復旧方法を復旧実施スケジュール管理テーブル１１１に登録する。

処理制御手段１１は、復旧実施スケジュール管理テーブル１１１を常に監視しており、テーブルに登録された復旧実施予定時間になると復旧の実施を試みる。

ここで、実際に復旧を行う前に現在のサービス状況を確認し、復旧を実施しても問題ないかを確認する。

まず、処理制御手段１１は、サービス要件確認手段１６にサービス要件確認の指示とサービス状況確認手段１７にサービス状況の指示をそれぞれ出す。

サービス要件確認手段１６は指示を受けると、サービス要件ＤＢ１６１に問い合わせを行い、サービス要件を確認し、得られたサービス要件を処理制御手段１１に返す。

サービス要件ＤＢ１６１には、サービス提供に最低限必要なサービス提供手段２の稼動状況などのサービス要件が蓄積されている。

サービス状況確認手段１７は、指示を受けるとサービス提供手段２のサービス状況を確認し、得られたサービス状況を処理制御手段１１に返す。

処理制御手段１１は、サービス要件、サービス状況を受け取り、復旧方法を実施した後の状態がサービス要件を満たしているか判定する。

判定の結果、サービス要件を満たしている場合は、復旧実施手段１５に復旧指示を出し、指示を受けた復旧実施手段１５は復旧方法に従い障害の復旧を行う。

判定の結果、サービス要件を満たさなくなる場合は、再度、復旧実施管理手段１４に復旧実施可能時間を問い合わせ、新たな復旧実施予定時間を復旧実施スケジュール管理テーブル１１１に登録する。

新たに登録した復旧実施予定時間になれば、上記のサービス状況、サービス要件の確認と復旧実施可否の判定を行い、実施可能であれば復旧を実施し、不可能であれば再スケジューリングを行う。

また、障害を検知した時点での緊急度が低かったため、復旧実施予定時間をスケジューリングしたが、その後障害が悪化する場合も考えられる。

この場合、最初に検出した障害の緊急度と新たに検出した障害の緊急度から、緊急度が閾値を超過する時間を予想する。

サービス提供手段２で障害発生すると、上記と同様にして、障害情報から復旧方法を決定し、処理制御手段１１は、復旧実施スケジュール管理テーブル１１１に復旧実施予定時間を登録する。

この時、同じ障害要因の復旧実施予定が既に登録されている場合、障害緊急度の増加率と障害発生時間の比較から、障害の緊急度が即時復旧を必要とするようになる時間を予想する。

予想した時間が復旧実施予定時間より遅い場合は、何もせず待機する。一方、予想した時間が復旧実施予定時間より早い場合は、アラーム通知手段１８にアラーム通知の指示を出す。

アラーム通知手段１８は、指示を受けると、オペレータ５０にこのままでは運用要件を満たす時間になる前に即時復旧可能な時間に障害が発生する旨のアラームを通知する。

次に、本実施形態の動作の一例について、図９乃至１１を用いて具体的に説明する。

まず、図９に示されるフローについて説明する。

なお、復旧実施（ステップ１１０１〜１１０５）の処理については後で説明する。

（１）障害緊急度が「１００」のため、即時復旧が必要な場合
Ｗｅｂサーバ２１にてＡＰ出力異常の障害が発生すると、障害自動復旧装置１は、障害情報（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「ＡＰ出力異常」、障害状況「出力メッセージ＃１」を受け取る（ステップ９０１）。

復旧方法決定手段１３に復旧方法を問い合わせると、図５の１３１１の障害に該当するので、復旧方法（復旧方法詳細「ＡＰ再起動」、障害緊急度「１００」、復旧影響度「−１」）を受け取る（ステップ９０２）。

障害緊急度＝「１００」であるため（ステップ９０３）、復旧実施手段１５に復旧指示を行い、復旧を実施する（ステップ１１０１〜１１０５）。

（２）復旧影響度が「０」のため、即時復旧する場合
Ｗｅｂサーバ２１にてログサイズ増加の障害が発生すると、障害自動復旧装置１は、障害情報（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「ログサイズ増加」、障害状況「ログサイズ１０ＭＢ」を受け取る（ステップ９０１）。

復旧方法決定手段１３に復旧方法を問い合わせると、図５の１３１５の障害に該当するので、復旧方法（復旧方法詳細「ログ出力先切替」、障害緊急度「５０」、復旧影響度「０」）を受け取る（ステップ９０２）。

復旧影響度＝「０」であるため（ステップ９０３）、復旧実施手段１５に復旧指示を行い、復旧実施する（ステップ１１０１〜１１０５）。

（３）障害緊急度が「１００」ではなく、復旧影響度が「０未満」、かつ、スケジュールが空の場合
Ｗｅｂサーバ２１にてメモリ枯渇の障害が発生すると、障害自動復旧装置１は、障害情報（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「メモリ枯渇」、障害状況「メモリ残量１００ＭＢ」を受け取る（ステップ９０１）。

復旧方法決定手段１３に復旧方法を問い合わせると、図５の１３１３の障害に該当するので、復旧方法（復旧方法詳細「ＯＳ再起動」、障害緊急度「９０」、復旧影響度「−１」）を受け取る（ステップ９０２）。

障害緊急度が「１００」ではなく、復旧影響度が「０未満」なので（ステップ９０３）、同じ障害復旧の作業があるか確認する（ステップ９０４）。

スケジュールは空なので（ステップ９０５）、復旧実施時間管理手段１４ に再スケジュールフラグ「０」として、復旧実施予定時間の問い合わせを行う（ステップ９１０）。

復旧実施管理手段１４は、処理制御手段１より復旧実施予定時間の問い合わせを受けると（ステップ７０１）、サーバ種別「Ｗｅｂサーバ」をキーにして復旧実施管理ＤＢ１４１に復旧実施可能時間を問い合わせると、実施可能時間「１８：００〜２１：３０」、再スケジュール間隔「１時間」であることが分かる（ステップ７０２）。

ここで、再スケジュールフラグ「０」であるので（ステップ７０３）、最も早い時間である「１１／２８ １８：００」を復旧実施予定時間として（ステップ７０８）、処理制御手段１に「１１／２８ １８：００」を返す（ステップ７０９）。

処理制御手段１１は、復旧実施管理手段１４から復旧実施予定時間「１１／２８ １８：００」を受け取ると、復旧実施スケジュール管理テーブル１１１に復旧実施スケジュール（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「メモリ枯渇」、復旧方法詳細「ＯＳ再起動」、障害緊急度「９０」、復旧影響度「−１」、復旧実施予定時間「１１／２８ １８：００」）を登録し（ステップ９１１）、復旧実施予定時間となるか次の障害を検知するまで待機する（ステップ９０９）。

（４）障害緊急度が「１００」ではなく、復旧影響度が「０未満」、かつ、同じスケジュールが登録されているが、障害緊急度が「１００」となる前に復旧実施できる場合
既にＷｅｂサーバ２１にてメモリ枯渇の障害が発生しており、復旧実施スケジュール管理テーブル１１１には、復旧実施スケジュール（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「メモリ枯渇」、復旧方法詳細「ＯＳ再起動」、障害緊急度「９０」、復旧影響度「−１」、復旧実施予定時間「１１／２８ １８：００」）が登録されている。

この時、Ｗｅｂサーバ２１にてメモリ枯渇の障害が悪化したため、障害自動復旧装置１は、障害情報（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １５：００」、障害要因「メモリ枯渇」、障害状況「メモリ残量５０ＭＢ」を受け取る（ステップ９０１）。

復旧方法決定手段１３に復旧方法を問い合わせると、図５の１３１４の障害に該当するので、復旧方法（復旧方法詳細「ＯＳ再起動」、障害緊急度「９５」、復旧影響度「−１」）を受け取る（ステップ９０２）。

障害緊急度が「１００」ではなく、復旧影響度が「０未満」なので（ステップ９０３）、同じ障害復旧の作業があるか確認する（ステップ９０４）。

復旧実施スケジュール管理テーブル１１１を確認すると、既に対象サーバ、障害要因が同じ復旧実施スケジュールが登録されているので（ステップ９０５）、障害緊急度が１００となる時間を予想すると、Ａ１＝１５：００、Ｂ１＝９５、Ａ２＝１０：００、Ｂ２＝９０であれば、Ｃ＝（９５−９０）／（１５：００−１０：００）＝５／５＝１、Ｄ＝１００−９５＝５、Ｅ＝１５：００＋５／１＝２０：００ なので、予想時間は「１１／２８ ２０：００」であることが分かる（ステップ９０６）。

スケジュールに登録されている復旧実施予定時間は、「１１／２８ １８：００」なので、障害緊急度が「１００」となる前に復旧実施可能であることから（ステップ９０７）、このまま待機する（ステップ９０９）。

（５）障害緊急度が「１００」ではなく、復旧影響度が「０未満」、かつ、同じスケジュールが登録されていて、復旧実施可能時間前に障害緊急度が１００となる予想される場合
既にＷｅｂサーバ２１にてメモリ枯渇の障害が発生しており、復旧実施スケジュール管理テーブル１１１には、復旧実施スケジュール（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「メモリ枯渇」、復旧方法詳細「ＯＳ再起動」、障害緊急度「９０」、復旧影響度「−１」、復旧実施予定時間「１１／２８ １８：００」）が登録されている。

この時、Ｗｅｂサーバ２１にてメモリ枯渇の障害が悪化したため、障害自動復旧装置１は、障害情報（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １２：００」、障害要因「メモリ枯渇」、障害状況「メモリ残量５０ＭＢ」を受け取る（ステップ９０１）。

復旧方法決定手段１３に復旧方法を問い合わせると、図５の１３１４の障害に該当するので、復旧方法（復旧方法詳細「ＯＳ再起動」、障害緊急度「９５」、復旧影響度「−１」）を受け取る（ステップ９０２）。

障害緊急度が「１００」ではなく、復旧影響度が「０未満」なので（ステップ９０３）、同じ障害復旧の作業があるか確認する（ステップ９０４）。

復旧実施スケジュール管理テーブル１１１を確認すると、既に対象サーバ、障害要因が同じ復旧実施スケジュールが登録されているので（ステップ９０５）、障害緊急度が１００となる時間を予想すると、Ａ１＝１２：００、Ｂ１＝９５、Ａ２＝１０：００、Ｂ２＝９０であれば、Ｃ＝（９５−９０）／（１２：００−１０：００）＝５／２＝２．５、Ｄ＝１００−９５＝５、Ｅ＝１２：００＋５／２．５＝１４：００なので、予想時間は「１１／２８ １４：００」であることが分かる（ステップ９０６）。

スケジュールに登録されている復旧実施予定時間は、「１１／２８ １８：００」なので、復旧実施予定時間「１１／２８ １８：００」前に障害緊急度が「１００」となることが予想されるので（ステップ９０７）、アラーム通知手段１８によりオペレータ５０にアラーム通知する（ステップ９０８）。

次に、図１０に示されるフローについて説明する。

（６）Ｗｅｂサーバ２１〜２Ｎの全てが稼働中の場合
既にＷｅｂサーバ２１にてメモリ枯渇の障害が発生しており、復旧実施スケジュール管理テーブル１１１には、復旧実施スケジュール（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「メモリ枯渇」、復旧方法詳細「ＯＳ再起動」、障害緊急度「９０」、復旧影響度「−１」、復旧実施予定時間「１１／２８ １８：００」）が登録されている。

「１１／２８ １８：００」になると（ステップ１００１）、情報制御手段１は、サービス要件確認手段１６にサービス要件指数を問い合わせると、図８の１６１２に該当するので、サービス要件指数「Ｎ−１」を受け取る（ステップ１００２）。

同様に、サービス状況確認手段１７にサービス状況指数を問い合わせると、Ｗｅｂサーバ２１〜２Ｎは、全て稼働中なのでサービス状況指数「Ｎ」を受け取る（ステップ１００３）。

復旧実施可否を判定すると、Ｎ＋（−１）−（Ｎ−１）＝０となり（ステップ１００４）、復旧実施可能と判定できるので（ステップ１００５）、復旧実施手段１５に復旧指示を行い、復旧実施する（ステップ１１０１〜１１０５）。

（７）Ｗｅｂサーバ２１〜２（Ｎ−１）が稼働中（Ｗｅｂサーバ２Ｎは停止中）の場合で当日の復旧実施可能時間内に再スケジュールできる場合
既にＷｅｂサーバ２１にてメモリ枯渇の障害が発生しており、復旧実施スケジュール管理テーブル１１１には、復旧実施スケジュール（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「メモリ枯渇」、復旧方法詳細「ＯＳ再起動」、障害緊急度「９０」、復旧影響度「−１」、復旧実施予定時間「１１／２８ １８：００」）が登録されている。

「１１／２８ １８：００」になると（ステップ１００１）、情報制御手段１は、サービス要件確認手段１６にサービス要件指数を問い合わせると、図８の１６１２に該当するので、サービス要件指数「Ｎ−１」を受け取る（ステップ１００２）。

同様に、サービス状況確認手段１７にサービス状況指数を問い合わせると、Ｗｅｂサーバ２Ｎが停止中なのでサービス状況指数「Ｎ−１」を受け取る。

復旧実施可否を判定すると、（Ｎ−１）＋（−１）−（Ｎ−１）＝−１となり（ステップ１００４）、復旧実施不可能と判定できるので（ステップ１００５）、復旧実施時間管理手段１４に再スケジュールフラグ「１」として復旧実施可能時間の問い合わせを行う（ステップ１００６）。

復旧実施管理手段１４は、処理制御手段１より復旧実施予定時間の問い合わせを受けると（ステップ７０１）、サーバ種別「Ｗｅｂサーバ」をキーにして復旧実施管理ＤＢ１４１に復旧実施可能時間を問い合わせると、実施可能時間「１８：００〜２１：３０」、再スケジュール間隔「１時間」であることが分かる（ステップ７０２）。

ここで、再スケジュールフラグ「１」であるので（ステップ７０３）、現在時刻「１１／２８ １８：００」に再スケジュール間隔「１時間」をプラスすると、プラスした時間は「１１／２８ １９：００」になる（ステップ７０４）。

「１９：００」は、復旧実施可能時間「１８：００〜２１：３０」に含まれるので（ステップ７０５）、「１１／２８ １９：００」を復旧実施可能時間として（ステップ７０６）、処理制御手段１に「１１／２８ １９：００」を返す（ステップ７０９）。

処理制御手段１１は、復旧実施管理手段１４から復旧実施予定時間「１１／２８ １９：００」を受け取ると、復旧実施スケジュール管理テーブルを更新して、復旧実施スケジュール（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「メモリ枯渇」、復旧方法詳細「ＯＳ再起動」、障害緊急度「９０」、復旧影響度「−１」、復旧実施予定時間「１１／２８ １９：００」）とし（ステップ１００７）、復旧実施予定時間となるか、次の障害を検知するまで待機する（ステップ１００８）。

（８）Ｗｅｂサーバ２１〜２（Ｎ−１）が稼働中（Ｗｅｂサーバ２Ｎは停止中）の場合で当日の復旧実施可能時間内に再スケジュールできない場合
既にＷｅｂサーバ２１にてメモリ枯渇の障害が発生しており、復旧実施スケジュール管理テーブル１１１には、復旧実施スケジュール（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「メモリ枯渇」、復旧方法詳細「ＯＳ再起動」、障害緊急度「９０」、復旧影響度「−１」、復旧実施予定時間「１１／２８ ２１：００」）が登録されている。

「１１／２８ １８：００」になると（ステップ１００１）、情報制御手段１は、サービス要件確認手段１６にサービス要件指数を問い合わせると、図８の１６１２に該当するので、サービス要件指数「Ｎ−１」を受け取る（ステップ１００２）。

同様に、サービス状況確認手段１７にサービス状況指数を問い合わせると、Ｗｅｂサーバ２Ｎが停止中なので、サービス状況指数「Ｎ−１」を受け取る。

復旧実施可否を判定すると、（Ｎ−１）＋（−１）−（Ｎ−１）＝−１となり（ステップ１００４）、復旧実施不可能と判定できるので（ステップ１００５）、復旧実施時間管理手段１４に再スケジュールフラグ「１」として復旧実施可能時間の問い合わせを行う（ステップ１００６）。

復旧実施管理手段１４は、処理制御手段１より復旧実施予定時間の問い合わせを受けると（ステップ７０１）、サーバ種別「Ｗｅｂサーバ」をキーにして復旧実施管理ＤＢ１４１に復旧実施可能時間を問い合わせると、実施可能時間「１８：００〜２１：３０」、再スケジュール間隔「１時間」であることが分かる（ステップ７０２）。

ここで、再スケジュールフラグ「１」であるので（ステップ７０３）、現在時刻「１１／２８ ２１：００」に再スケジュール間隔「１時間」をプラスすると、プラスした時間は「１１／２８ ２２：００」になる（ステップ７０４）。

「１９：００」は、復旧実施可能時間「１８：００〜２１：３０」に含まれないので（ステップ７０５）、翌日の復旧実施可能時間で最も早い時間「１１／２９ １８：００」を復旧実施可能時間として（ステップ７０７）、処理制御手段１に「１１／２９ １８：００」を返す（ステップ７０９）。

処理制御手段１１は、復旧実施管理手段１４から復旧実施予定時間「１１／２９ １８：００」を受け取ると、復旧実施スケジュール管理テーブルを更新して、復旧実施スケジュール（対象サーバ「Ｗｅｂサーバ２１」、障害発生時間「１１／２８ １０：００」、障害要因「メモリ枯渇」、復旧方法詳細「ＯＳ再起動」、障害緊急度「９０」、復旧影響度「−１」、復旧実施予定時間「１１／２９ １８：００」）とし（ステップ１００７）、復旧実施予定時間となるか次の障害を検知するまで待機する（ステップ１００８）。

最後に、図１１に示されているフローについて説明する。

（９）復旧作業と同じ内容のスケジュールが既に登録されていない場合
処理制御手段１は、復旧実施手段１５に復旧指示を行い、復旧完了の通知を受け取ると（ステップ１１０１）、実施した復旧作業と同じ作業が既に登録されているか確認する（ステップ１１０２）。

同じ作業内容のスケジュールが存在していないので（ステップ１１０３）、復旧作業は、完了し、処理制御手段１は、このまま待機する（ステップ１１０５）。

（１０）復旧作業と同じ内容のスケジュールが既に登録されている場合
処理制御手段１は、復旧実施手段１５に復旧指示を行い、復旧完了の通知を受け取ると（ステップ１１０１）、実施した復旧作業と同じ作業が既に登録されているか確認する（ステップ１１０２）。

同じ作業内容のスケジュールが存在しているので（ステップ１１０３）、同じ復旧作業のスケジュールを削除して（ステップ１１０４）、復旧作業を完了し、処理制御手段１は、このまま待機する（ステップ１１０５）。

同じ作業内容であれば、復旧作業は実施したことになるので、スケジュールから削除することにより、余計な復旧作業を実施しないようにできる。

以上説明したように、本実施形態によれば、障害の緊急度、復旧作業の影響度、システムの運用要件によって自動復旧作業の実施時間をスケジューリングするため、障害の内容に応じて適切なタイミングで自動復旧を行うことができる。

また本実施形態によれば、サービス状況を確認してから自動復旧を行うため、復旧措置自体がもたらすサービス影響を防ぐことができる。

また本実施形態によれば、障害緊急度と発生時間から障害が致命的となる時間を予測し、オペレータ５０に通知するため、障害が悪化して適切なタイミングに自動復旧できないが予想される場合でも、障害が致命的となる前にオペレータが対応を検討することができる。

本実施形態に係る障害自動復旧装置１の概略構成を示す図である。 サービス提供手段２の概略構成を示す図である。 障害情報３の構成を示す図である。 復旧方法４を説明するための図である。 障害復旧ＤＢ１３１を説明するための図である。 復旧実施可能時間ＤＢ１４１を説明するための図である。 復旧実施時間管理手段１４の動作の一例を示す図である。 サービス要件ＤＢ１６１を説明するための図である。 障害検出してから復旧実施の時間を決定するまでのフローを示す図である。 復旧実施予定時間となってから復旧を行うまでのフローを示す図である。 実際に復旧を行った後のフローを示す図である。 復旧実施スケジュール管理テーブル１１１を説明するための図である。

符号の説明

１ 障害自動復旧装置
１１ 処理制御手段
１１１ 復旧実施スケジュール管理テーブル
１２ 障害検出手段
１３ 復旧方法決定手段
１３１ 障害復旧ＤＢ
１４ 復旧実施時間管理手段
１４１ 復旧実施可能時間ＤＢ
１５ 復旧実施手段
１６ サービス要件確認手段
１６１ サービス要件ＤＢ
１７ サービス状況確認手段
１８ アラーム通知手段

Claims (5)

1. 障害を自動的に復旧する障害自動復旧装置において、
   前記障害が発生した旨を示す障害情報を外部から受信する障害検出手段と、
   前記障害情報と前記障害を復旧する復旧方法とを対応づけて記憶する障害復旧記憶手段と、
   前記障害情報に基づいて、障害復旧記憶手段内に記憶されている前記復旧方法を決定する復旧方法決定手段と、
   前記決定された前記復旧方法に応じて、即時に前記障害の復旧を実施するか否かを判断する処理制御手段と、
   を備え、
   前記復旧方法には、予め設定された前記障害ごとの緊急度を示す障害緊急度情報と、予め設定された前記障害ごとの復旧の影響度を示す復旧影響度情報と、が含まれており、
   前記処理制御手段による判断の結果、前記障害が前記障害緊急度情報により即時の復旧が必要とされている前記緊急度の障害である場合、又は前記障害が、前記障害緊急度情報により即時の復旧が必要とされていない前記緊急度の障害ではあるが、前記復旧影響度情報により前記障害の復旧の影響度が全くないとされている前記影響度の障害である場合、前記処理制御手段は、前記復旧方法に基づいて即時に前記障害の復旧を実施し、前記障害が前記障害緊急度情報により即時の復旧が必要とされていない前記緊急度の障害ではあり、且つ前記復旧営業度情報により前記影響度が存在するとされている障害の場合は、所定のタイミングに前記障害の復旧を実施することを特徴とする障害自動復旧装置。
2. 請求項１に記載の障害自動復旧装置において、
   運用ルールとして決められた復旧実施可能時間を含む運用要件が記憶されている復旧実施可能時間記憶手段と、
   前記障害情報と、前記復旧実施可能時間記憶手段内の前記復旧実施可能時間と、に基づいて復旧実施予定時間を決定する復旧実施時間管理手段と、
   前記復旧実施時間管理手段により前記復旧実施予定時間が決定された後に、前記復旧実施予定時間、前記障害情報、及び前記復旧方法を復旧実施スケジュール管理テーブルに登録する登録手段と、
   備え、
   前記処理制御手段は、前記復旧実施スケジュール管理テーブルに登録された前記復旧実施予定時間になると前記障害の復旧を実施することを特徴とする障害自動復旧装置。
3. 請求項２に記載の障害自動復旧装置において、
   サービスの提供に最低限必要な外部の装置の稼動状況を示すサービス要件が記憶されているサービス要件記憶手段と、
   前記サービス要件記憶手段内の前記サービス要件を確認するサービス要件確認手段と、
   前記外部の装置のサービス状況を確認するサービス状況確認手段と、
   を備え、
   前記処理制御手段は、前記サービス要件、及び前記サービス状況に基づいて、前記復旧方法を実施した後の状態が前記サービス要件を満たしているか否かを判定し、
   前記判定の結果、前記サービス要件を満たしている場合は、前記復旧方法に基づいて前記障害の復旧を実施することを特徴とする障害自動復旧装置。
4. 請求項３に記載の障害自動復旧装置において、
   前記判定の結果、前記サービス要件を満たさなくなる場合、前記復旧実施時間管理手段及び前記登録手段は、再度、新たな復旧実施予定時間を前記復旧実施スケジュール管理テーブルに登録し、前記処理制御手段は、新たに登録した復旧実施予定時間になれば前記サービス状況、及び前記サービス要件の確認と前記障害の復旧を実施することができるか否かの判定を行い、
   更に前記処理制御手段は、
   前記障害の復旧が実施することができると判定された場合には前記障害の復旧を実施し、
   前記障害の復旧が実施することができないと判定された場合には再スケジューリングを行うことを特徴とする障害自動復旧装置。
5. 請求項４に記載の障害自動復旧装置において、
   当該障害自動復旧装置の使用者にこのままでは前記運用要件を満たす時間になる前に即時復旧可能な時間に障害が発生する旨のアラームを通知するアラーム通知手段を更に備え、
   前記復旧実施スケジュール管理テーブルに前記復旧実施予定時間を登録し、同じ障害要因の復旧実施予定が既に登録されている場合には、前記処理制御手段は、前記障害の緊急度の増加率と前記障害の発生時間との比較により、前記障害の緊急度が即時の復旧を必要とするようになる時間を予想し、当該予想した時間が前記復旧実施予定時間より遅い場合は何もせず待機し、前記予想した時間が前記復旧実施予定時間より早い場合は前記アラーム通知手段にアラーム通知の指示を出すことを特徴とする障害自動復旧装置。

Images