JP2016152461A - クラウドシステム、ルータ、管理用サーバおよびプログラム - Google Patents

Abstract

【課題】必ずしも管理用サーバを常時稼働させることを要することなく、ルータからクラウド側ネットワークに向けて、障害に関する情報を送信する技術を提供する。
【解決手段】クラウドシステム１の複数のサブシステム１００（Ａ、Ｂ〜Ｚ）は、それぞれ、ルータ３０と管理用サーバ６０とを備える。複数のサブシステムのうちの特定のサブシステム１００Ａにおける管理用サーバ６０Ａは稼働しておらず、かつ、別のサブシステム１００Ｚに属する一の管理用サーバ６０Ｚは稼働している状態において、特定のサブシステム１００Ａにおける障害が検知される場合には、特定のサブシステム１００Ａの特定のルータ３０Ａは、特定の管理用サーバ６０Ａの起動依頼を、管理用サーバ６０Ｚに対して送信する。管理用サーバ６０Ｚは、当該起動依頼に基づいて特定の管理用サーバ６０Ａに起動指令を送信し、特定のルータ３０Ａは、当該起動指令に基づいて起動する。
【選択図】図５

Description

本発明は、クラウドシステムおよびそれに関連する技術に関する。

クラウドサーバを利用して各種のサービスを提供するクラウドシステムが存在する（特許文献１等参照）。

また、クラウドシステムとしては、ＬＡＮ内に配置されたＭＦＰ（マルチ・ファンクション・ペリフェラル（Multi-Functional Peripheral））等におけるスキャン処理結果（スキャン画像データ）をクラウドサーバ内に保存する技術（リモートスキャン技術）が存在する。あるいは、クラウドサーバに保存されたデータに基づき、ＬＡＮ内に配置されたＭＦＰにて印刷出力を行う技術（リモートプリント技術）なども存在する。

なお、このようなクラウドシステムにおいては、クラウドサービス（リモートスキャンサービスおよびリモートプリントサービス等）を提供するためのサーバ（サービス提供用サーバ）とは別に、各種の障害情報の送受信等を行う管理用サーバが配置されることがある。当該管理用サーバは、たとえば、クラウド側ネットワーク（ＬＡＮの外部のネットワーク）とイントラネット側ネットワーク（ＬＡＮの内部のネットワーク）とを仲介するルータから、障害の発生を通知する障害通知等を受信する。

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

ところで、上記のようなクラウドシステムは、実体としてのサーバ（物理サーバ）を複数のユーザで共有することによって実現されることが多い。しかしながら、セキュリティ上の観点から、秘密書類を扱うユーザの中には、クラウドシステムにおいて物理的に同一のサーバが他のユーザと共有されることを望まないユーザも存在する。

このようなユーザの要望を受けて、上述のクラウドシステムにおいては、一般ユーザ向けのシステム（サブシステム）とは別に、当該ユーザ（高セキュリティ要望ユーザとも称する）向けの個別のシステム（たとえば、特定の企業向けの個別のサブシステム）を構築することが考えられる。当該個別のシステムにおいては、クラウドサービスを提供するためのサーバ（サービス提供用サーバ）として、一般ユーザ向けのサーバとは物理的に異なるサーバが設けられる。

ここにおいて、当該個別のシステムにおいても、各種の障害情報の受信等を行うため、一般ユーザ向けのシステムと同様に、（障害情報受信用の）管理用サーバが設けられることが好ましい。また、当該個別のシステム用の管理用サーバも、セキュリティ向上の観点から、一般ユーザ向けの管理用サーバとは物理的に異なる装置として設けられることが好ましい。

しかしながら、個別のシステムにおいて個別の管理用サーバを常時起動させた状態で運用すると、高い運用コストを要するとの問題が存在する。

そこで、この発明は、複数のサブシステムにおける全ての管理用サーバを必ずしも常時稼働させることを要することなく、クラウド側ネットワークとイントラネット側ネットワークとを仲介するルータからクラウド側ネットワークに向けて、障害に関する情報を送信することが可能な技術を提供することを課題とする。

上記課題を解決すべく、請求項１の発明は、複数のサブシステムを備えるクラウドシステムであって、前記複数のサブシステムは、それぞれ、クラウド側ネットワークとイントラネット側ネットワークとを仲介するルータと、前記クラウド側ネットワークに設けられるクラウドサービス提供用サーバと、前記クラウドサービス提供用サーバとは別個に前記クラウド側ネットワークに設けられる管理用サーバであって、各サブシステムの各障害検知アプリケーションによって検知された障害に関する情報を前記ルータを介して受信する管理用サーバと、を備え、前記複数のサブシステムのうちの特定のサブシステムにおける特定の管理用サーバは稼働しておらず、且つ、前記複数のサブシステムに設けられた複数の管理用サーバのうち少なくとも前記特定のサブシステム以外のサブシステムに属する一の管理用サーバは稼働している状態において、前記特定のサブシステムにおける障害が検知される場合には、前記特定のサブシステムのルータである特定のルータは、前記特定の管理用サーバの起動依頼を、前記一の管理用サーバに対して送信し、前記一の管理用サーバは、前記起動依頼に基づいて前記特定の管理用サーバに対して起動指令を送信し、前記特定のルータは、前記一の管理用サーバからの前記起動指令に基づいて起動することを特徴とする。

請求項２の発明は、請求項１の発明に係るクラウドシステムにおいて、前記特定の管理用サーバは、前記起動指令に応じた起動完了後に、前記障害を解消するための障害解消処理を実行することを特徴とする。

請求項３の発明は、請求項１の発明に係るクラウドシステムにおいて、前記各サブシステムの各障害検知アプリケーションは、それぞれ、前記各サブシステムの各ルータに実装されていることを特徴とする。

請求項４の発明は、請求項１の発明に係るクラウドシステムにおいて、前記特定のルータは、前記複数の管理用サーバのうち稼働中の管理用サーバを前記一の管理用サーバとして特定することを特徴とする。

請求項５の発明は、請求項１の発明に係るクラウドシステムにおいて、前記特定のサブシステムにおける障害検知アプリケーションは、前記特定のサブシステムにおける障害を検知すると、前記特定の管理用サーバが稼働しているか否かを判定し、前記特定の管理用サーバが稼働していないと判定される場合、前記複数の管理用サーバの中から稼働中の前記一の管理用サーバを検出することを特徴とする。

請求項６の発明は、請求項１の発明に係るクラウドシステムにおいて、前記複数の管理用サーバは、それぞれ、前記複数のサブシステムの複数のルータからの起動指令を許容せず且つ前記複数のルータからの他の管理用サーバの起動依頼を許容し且つ他の管理用サーバからの起動指令を許容するセキュリティ設定、を有していることを特徴とする。

請求項７の発明は、請求項１の発明に係るクラウドシステムにおいて、前記特定のルータは、障害情報を含む障害通知を、前記起動依頼として利用して前記一の管理用サーバに送信するとともに、前記起動依頼として既に送信した前記障害通知と同じ内容の障害通知を、前記特定の管理用サーバの起動完了後において、前記特定の管理用サーバに送信し、前記複数の管理サーバのそれぞれは、障害通知が受信されると、受信した障害通知である第１の通知が自らのサブシステムのルータから送信されたものであるか否かを判定し、前記第１の通知が自らのサブシステムのルータから送信されたものであると判定される場合、前記障害情報の解消策を実行し、前記第１の通知が他のサブシステムのルータである前記特定のルータから送信されたものであると判定される場合、前記第１の通知を前記起動依頼として判定し、前記特定の管理用サーバの前記起動指令を前記特定の管理用サーバに送信することを特徴とする。

請求項８の発明は、請求項１の発明に係るクラウドシステムにおいて、前記一の管理用サーバは、前記起動依頼を受信した後且つ前記特定のサーバの起動完了前において、前記特定のサブシステムの管理ユーザに前記特定のサブシステムにおける障害の発生を通知することを特徴とする。

請求項９の発明は、請求項８の発明に係るクラウドシステムにおいて、前記一の管理用サーバは、前記特定のサーバの起動完了前に、顧客情報蓄積サーバにアクセスして前記特定のサブシステムの管理ユーザの電子メールアドレスを取得し、前記特定のサブシステムにおける障害の発生を通知する電子メールを前記電子メールアドレス宛に送信することを特徴とする。

請求項１０の発明は、請求項１の発明に係るクラウドシステムにおいて、前記一の管理用サーバは、前記起動依頼とともに受信した障害情報を障害情報蓄積サーバに送信するとともに、前記障害情報に関する障害解消策を前記障害情報蓄積サーバから受信し、前記特定の管理用サーバの起動完了後に前記障害解消策を前記特定の管理用サーバに送信し、前記特定の管理用サーバは、前記一の管理用サーバから受信した前記障害解消策に基づき、障害解消処理を実行することを特徴とする。

請求項１１の発明は、請求項１の発明に係るクラウドシステムにおいて、前記特定の管理用サーバは、前記一の管理用サーバから受信した障害情報を障害情報蓄積サーバに送信し、前記障害情報に関する障害解消策を前記障害情報蓄積サーバから受信し、前記障害解消策に基づく障害解消処理を実行することを特徴とする。

請求項１２の発明は、クラウドシステムを構成する複数のサブシステムのうちの特定のサブシステムのルータであって、前記特定のサブシステムにおける特定の管理用サーバが稼働しているか否かを判定する判定手段と、前記複数のサブシステムのうち前記特定のサブシステム以外のサブシステムに属する一の管理用サーバが稼働していることを検出する検出手段と、前記特定の管理用サーバは稼働しておらず且つ前記一の管理用サーバは稼働している状態において、前記特定のサブシステムにおける障害が検知される場合には、前記特定の管理用サーバの起動依頼を、前記一の管理用サーバに対して送信する送信手段と、を備えることを特徴とする。

請求項１３の発明は、クラウドシステムを構成する複数のサブシステムのうちの特定のサブシステム内のルータに内蔵されたコンピュータに、ａ）前記特定のサブシステムにおける特定の管理用サーバが稼働しているか否かを判定するステップと、ｂ）前記複数のサブシステムのうち前記特定のサブシステム以外のサブシステムに属する一の管理用サーバが稼働していることを検出するステップと、ｃ）前記特定の管理用サーバは稼働しておらず且つ前記一の管理用サーバは稼働している状態において、前記特定のサブシステムにおける障害が検知される場合には、前記特定の管理用サーバの起動依頼を、前記一の管理用サーバに対して送信するステップと、を実行させるためのプログラムであることを特徴とする。

請求項１４の発明は、クラウドシステムを構成する複数のサブシステムのうちの一のサブシステムの管理用サーバであって、前記複数のサブシステムのうち前記一のサブシステムとは異なる特定のサブシステムにおける障害発生通知を受け付けるべき特定の管理用サーバであって前記特定のサブシステムに属する特定の管理用サーバは稼働していない状態において、前記特定のサブシステムにおける障害検知に応じて、前記特定のサブシステムのルータである特定のルータから前記特定の管理用サーバの起動依頼を受信する受信手段と、前記起動依頼に基づいて、前記特定の管理用サーバに対して起動指令を送信する送信手段と、を備えることを特徴とする。

請求項１５の発明は、請求項１４の発明に係る管理用サーバにおいて、前記送信手段は、前記起動依頼を受信した後且つ前記特定のサーバの起動完了前において、前記特定のサブシステムの管理ユーザに前記特定のサブシステムにおける障害の発生を通知することを特徴とする。

請求項１６の発明は、クラウドシステムを構成する複数のサブシステムのうちの一のサブシステムの管理用サーバに内蔵されたコンピュータに、ａ）前記複数のサブシステムのうち前記一のサブシステムとは異なる特定のサブシステムにおける障害発生通知を受け付けるべき特定の管理用サーバであって前記特定のサブシステムに属する特定の管理用サーバは稼働していない状態において、前記特定のサブシステムにおける障害検知に応じて、前記特定のサブシステムのルータである特定のルータから前記特定の管理用サーバの起動依頼を受信するステップと、ｂ）前記起動依頼に基づいて、前記特定の管理用サーバに対して起動指令を送信するステップと、を実行させるためのプログラムであることを特徴とする。

請求項１７の発明は、請求項１６の発明に係るプログラムにおいて、ｃ）前記起動依頼を受信した後且つ前記特定のサーバの起動完了前において、前記特定のサブシステムの管理ユーザに前記特定のサブシステムにおける障害の発生を通知するステップ、を前記コンピュータにさらに実行させることを特徴とする。

請求項１ないし請求項１７に記載の発明によれば、複数のサブシステムにおける全ての管理用サーバを必ずしも常時稼働させることを要することなく、クラウド側ネットワークとイントラネット側ネットワークとを仲介するルータからクラウド側ネットワークに向けて、障害に関する情報を送信することが可能である。

本発明の第１実施形態に係るクラウドシステムを示す図である。 管理用サーバのセキュリティ設定等を示す概念図である。 個別ユーザ向けのサブシステムにおいて、管理用サーバが稼働されていない様子を示す図である。 第１実施形態の詳細動作を示すタイミングチャートである。 管理用サーバが稼働していない状況を示す概念図である。 管理用サーバの起動完了後に実行される処理を示す概念図である。 第２実施形態に係るシステムの動作を示すタイミングチャートである。 管理用サーバが稼働していない状況を示す概念図である。 管理用サーバの起動開始後且つ起動完了前に実行される処理を示す概念図である。 管理用サーバの起動完了後に実行される処理を示す概念図である。 第３実施形態に係るシステムの動作を示すタイミングチャートである。 管理用サーバが稼働していない状況を示す概念図である。 管理用サーバの起動完了直後に実行される処理を示す概念図である。 管理用サーバの起動完了後の障害通知処理を示す概念図である。 管理用サーバの起動完了後且つ障害通知後に実行される処理を示す概念図である。

以下、本発明の実施形態を図面に基づいて説明する。

＜１．第１実施形態＞
＜１−１．システム構成＞
図１は、本発明の第１実施形態に係るクラウドシステムを示す図である。

クラウドシステム１は、複数のサブシステム１００（詳細には、１００Ｚ，１００Ａ，１００Ｂ，...）を備えて構成される。クラウドシステム１は、その障害検知機能（各サブシステム１００での障害を検知する機能）を有していることから、障害検知システムとも称される。

各サブシステム１００は、それぞれ、同様の構成を有している。各サブシステム１００は、サービス提供用のクラウドサーバ５０とルータ３０と各種ネットワーク通信装置（ここではＭＦＰ（画像形成装置））１０とを備える。ＭＦＰ（マルチ・ファンクション・ペリフェラル（Multi-Functional Peripheral））１０は、スキャン機能、コピー機能、ファクシミリ機能およびボックス格納機能などを備える装置（複合機とも称する）である。ＭＦＰ１０は、ＬＡＮの内部（イントラネット側）に設けられる。また、クラウドサーバ５０は、当該ＬＡＮの外部（クラウド側）に設けられる。ルータ３０は、クラウド側ネットワークとイントラネット側ネットワークとの両ネットワークの境界に配置され、当該両ネットワークを仲介（換言すれば、ＬＡＮの内側と外側とを仲介）する装置である。たとえば、ルータ３０は、ＭＦＰ１０とクラウドサーバ５０とのデータ通信を中継する。

各装置１０，３０，５０，６０は、それぞれ、通信部、格納部およびコントローラ等を備えている。通信部は、各種データを送信する送信部と各種データを受信する受信部とを有し、ネットワークを介したネットワーク通信を行うことが可能である。このネットワーク通信では、たとえば、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）等の各種のプロトコルが利用される。

また、各装置１０，３０，５０，６０は、それぞれ、ＣＰＵおよび半導体メモリ等で構成されるコンピュータを内蔵しており、当該コンピュータにて各種のプログラムを実行することによって各種の処理部（たとえば、判定部、検出部、通信制御部等）を実現する。なお、当該各種のプログラムは、ＵＳＢメモリなどの可搬性の記録媒体に記録され、当該記録媒体を介して各装置にインストールされてもよく、あるいはネットワーク等を介して各装置にインストールされてもよい。

このクラウドシステムにおいては、たとえば、ＬＡＮ内に配置されたＭＦＰ１０等におけるスキャン処理結果（スキャン画像データ）をクラウドサーバ５０内に保存することが可能である。また、クラウドサーバ５０に保存されたデータに基づき、ＬＡＮ内に配置されたＭＦＰ１０にて印刷出力を行うことが可能である。

また、ルータ３０には、障害検知アプリケーション等が実装されている。障害検知アプリケーションは、ルータ３０自身、ＬＡＮ側のネットワーク、およびＬＡＮ側のネットワーク機器１０等に関する障害（異常）を検知する機能を有している。たとえば、障害検知アプリケーションは、ルータ３０等に実装された各種のアプリケーションソフトウエア（サービス転送ソフトウエア等）の異常、および各種のネットワーク異常等、を検知する。

各サブシステム１００は、それぞれ、クラウドサーバ５０（クラウドサービス提供用サーバ）とは別個に、各サブシステム１００における各種の管理処理等を行うための管理用サーバ６０をも備えている。当該管理用サーバ６０もクラウド上に設けられる。管理用サーバ６０は、ルータ３０あるいはＬＡＮ内装置における障害の発生を示す情報と当該障害の内容等に関する障害情報とを含む障害通知をルータ３０（詳細には、障害検知アプリケーション）から受信する機能を有する。また、管理用サーバ６０は、ルータ３０から受信した当該障害通知（障害情報を含む）を更に管理ユーザに通知する機能等を有する。管理用サーバ６０は、障害通知を送受信するサーバであることから、障害通知管理サーバとも称される。また、管理用サーバ６０は、各種ソフトウエアのアップデート等（保守作業）を（定期的および不定期に）実行する機能をも有する。そのため、管理用サーバ６０は、保守サーバとも称される。

また、このクラウドシステム１は、顧客情報蓄積サーバ７０と障害情報蓄積サーバ８０とを備えている。

各管理用サーバ６０は、障害情報蓄積サーバ８０にアクセスして、各種障害の解消策に関する情報を取得することが許容されている。また、各管理用サーバ６０は、顧客情報蓄積サーバ７０にアクセスして、当該各管理用サーバ６０に対応するサブシステム１００の顧客に関する情報を取得することが許容されている。なお、後述する第２実施形態においては、各管理用サーバ６０は、自らが所属するサブシステム以外のサブシステムの顧客に関する情報をも取得することが許容される。

複数のサブシステム１００のうち、サブシステム１００Ｚは、一般ユーザ向けのシステムである。

サブシステム１００Ｚは、サービス提供用のクラウドサーバ５０Ｚと複数のルータ３０と複数のＭＦＰ１０とを備える。複数のルータ３０は、それぞれは、各ユーザ（たとえば会社Ｃ１、会社Ｃ２、会社Ｃ３）向けに配置される。

たとえば、サブシステム１００Ｚ内における最上段のルータ３０は、会社Ｃ１内に設けられ、会社Ｃ１内の或るＬＡＮと当該ＬＡＮの外側のネットワークとを仲介する。当該ルータ３０のＬＡＮ側には複数のＭＦＰ１０が接続される。

また、サブシステム１００Ｚ内における中段のルータ３０は、会社Ｃ２内に設けられ、会社Ｃ２内の或るＬＡＮと当該ＬＡＮの外側のネットワークとを仲介する。当該ルータ３０のＬＡＮ側には複数のＭＦＰ１０が接続される。

同様に、サブシステム１００Ｚ内における最下段のルータ３０は、会社Ｃ３内に設けられ、会社Ｃ３内の或るＬＡＮと当該ＬＡＮの外側のネットワークとを仲介する。当該ルータ３０のＬＡＮ側には複数のＭＦＰ１０が接続される。

会社Ｃ１のユーザは、会社Ｃ１内のＭＦＰ１０と会社Ｃ１内のルータ３０とクラウドサーバ５０Ｚとを用いて、リモートスキャンおよび／またはリモートプリント等を実行することが可能である。

同様に、会社Ｃ２（，Ｃ３）のユーザは、会社Ｃ２（，Ｃ３）内のＭＦＰ１０と会社Ｃ２（，Ｃ３）内のルータ３０とクラウドサーバ５０Ｚとを用いて、リモートスキャンおよび／またはリモートプリント等を実行することが可能である。

このように、サブシステム１００Ｚにおいては、そのクラウドサーバ５０Ｚが複数の一般ユーザによって共用される。

また、サブシステム１００Ｚは、クラウドサーバ５０Ｚのみならず管理用サーバ６０Ｚをも備える。この管理用サーバ６０Ｚも、複数の一般ユーザによって共用される。なお、この実施形態においては、管理用サーバ６０Ｚは常に稼働しているものとする。

一方、サブシステム１００Ａ，１００Ｂは、それぞれ、個別ユーザ向けのシステムである。

たとえば、サブシステム１００Ａは、会社ＣＡ向けのシステムであり、クラウドサーバ５０Ａと管理用サーバ６０Ａとルータ３０Ａと複数のＭＦＰ１０とを有している。サブシステム１００Ａにおいても、各種の障害通知（障害情報を含む）の受信等を行うため、一般ユーザ向けのサブシステム１００Ｚと同様に、（障害通知受信用の）管理用サーバ６０Ａが設けられる。

サブシステム１００Ａは、セキュリティ向上の観点から、一般ユーザ向けのサブシステム１００Ｚとは別のインスタンス（実体（物理的構成物））によって構成されている。特に、サブシステム１００Ａのクラウドサーバ５０Ａは、サブシステム１００Ｚのクラウドサーバ５０Ｚとは別のインスタンス（実体）として構成されている。同様に、サブシステム１００Ａの管理用サーバ６０Ａは、サブシステム１００Ｚの管理用サーバ６０Ｚとは別のインスタンス（実体）として構成されている。なお、サブシステム１００Ａ内のルータ３０ＡおよびＭＦＰ１０も、それぞれ、サブシステム１００Ｚ内のルータ３０およびＭＦＰ１０とは別のインスタンス（実体）として構成されている。

サブシステム１００Ａ内のルータ３０Ａは、会社ＣＡ内に設けられ、会社ＣＡ内のＬＡＮと当該ＬＡＮの外側のネットワークとを仲介する。当該ルータ３０ＡのＬＡＮ側には複数のＭＦＰ１０が接続される。

会社ＣＡのユーザは、会社ＣＡ内のＭＦＰ１０と会社ＣＡ内のルータ３０Ａとクラウドサーバ５０Ａとを用いて、リモートスキャンおよび／またはリモートプリント等を実行することが可能である。

上述のように、クラウドサーバ５０Ａは、セキュリティ向上の観点から、一般ユーザ向けのクラウドサーバ５０Ｚとは物理的に異なる装置として設けられる。同様に、管理用サーバ６０Ａも、セキュリティ向上の観点から、一般ユーザ向けの管理用サーバ６０Ｚとは物理的に異なる装置として設けられる。

ただし、管理用サーバ６０Ａを常時稼働した状態でシステム（特にサブシステム１００Ａ）を運用すると高い運用コストを要する、という問題が存在する。

そこで、この実施形態においては、管理用サーバ６０Ａは通常状態においては稼働されず、必要に応じて一時期のみ稼働されるものとする。たとえば、管理用サーバ６０Ａは、定期的あるいは不定期のメンテンナンス処理の実行時等においては稼働されているが、それ以外の時期においては原則として稼働されていない（起動されていない）ものとする。すなわち、このクラウドシステム１（特にサブシステム１００Ａ）においては、クラウドサーバ５０Ａの稼働中であっても、原則として管理用サーバ６０Ａは稼働されない。

このように、通常は管理用サーバ６０Ａを稼働しないことによって、運用コストを低減することが可能である。なお、図３は、個別ユーザ向けのサブシステム１００Ａにおける管理用サーバ６０Ａが稼働されていない様子を示している。

ここにおいて、管理用サーバ６０Ａが稼働している状態（図１参照）においては、障害検知アプリケーションによりサブシステム１００Ａの障害が検知されると、ルータ３０Ａから管理用サーバ６０Ａへと障害通知（障害情報等を含む）が送信される。また、管理用サーバ６０Ａは、顧客情報蓄積サーバ７０および障害情報蓄積サーバ８０と通信して、サブシステム１００Ａの管理ユーザの情報、および当該障害の解消策等を取得する。そして、管理用サーバ６０Ａは、障害の発生等を知らせる電子メールを管理ユーザに送信し、管理ユーザは管理者端末９０（スマートフォン等）で当該電子メールを受信する。また、管理用サーバ６０Ａは、障害の解消策に基づく解消処理（たとえばルータ３０の再起動等）を実行する。このように障害通知動作およびそれに引き続く各種動作が正常に実行され得る。

しかしながら、管理用サーバ６０Ａが稼働していない状態（図３参照）において障害検知アプリケーションによりサブシステム１００Ａの障害が検知される場合には、管理用サーバ６０Ａが稼働していない状態のままでは管理用サーバ６０Ａはルータ３０Ａからの障害通知を受信することができない（図３参照）。すなわち、管理用サーバ６０Ａの非稼働状態においては、管理用サーバ６０Ａは、ルータ３０Ａからの障害通知を受信することができない。なお、セキュリティ上の観点から、管理用サーバ６０ＡをＬＡＮ内の機器（たとえばルータ３０等）から直接的に起動させることは許容されない。

そこで、この実施形態においては、図５に示すように、ルータ３０Ａの障害検知アプリケーションが障害を検知すると、ルータ３０Ａは、別のサブシステム１００（たとえば１００Ｚ）の管理用サーバ６０（６０Ｚ）に「起動依頼」を送信する。当該起動依頼は、ルータ３０Ａに対応する管理用サーバ６０Ａを起動させることを意図する依頼メッセージである。当該管理用サーバ６０Ｚは、当該起動依頼を受信すると、管理用サーバ６０Ａに対して起動指令を送出する。管理用サーバ６０Ａは、当該起動指令を受信すると、非稼働状態から稼働状態への遷移動作を開始する。すなわち、管理用サーバ６０Ａは、起動を開始する。

このように、管理用サーバ６０Ａは、ルータ３０Ａからの起動依頼に基づく管理用サーバ６０Ｚ等からの起動指令に応じて、非稼働状態（スタンバイ状態）から復帰して起動される。これによれば、障害検知時において管理用サーバ６０Ａが稼働していない場合であっても、当該管理用サーバ６０Ａを起動させ、ルータ３０Ａからクラウド側ネットワークに向けて、障害に関する情報を適切に送信することが可能である。また、必ずしも管理用サーバ６０Ａを常時稼働させることを要しない（管理用サーバ６０Ａの常時稼働が回避される）ので、管理用サーバ６０Ａの運用コストを低減することができる。

なお、サブシステム１００Ｂもサブシステム１００Ａと同様の構成を有している。サブシステム１００Ｂにおいて障害が検出された場合も、同様の動作が行われればよい。たとえば、ルータ３０Ｂから管理用サーバ６０Ｚへと起動依頼が送信され、管理用サーバ６０Ｚから管理用サーバ６０Ｂへと起動指令が送信されればよい。

また、本願では、複数のサブシステム１００における複数の管理用サーバ６０のうちのいずれかは稼働している状況を想定する。たとえば、この第１実施形態においては、上述のように、少なくとも管理用サーバ６０Ｚが常に稼働しているものとする。

＜１−２．セキュリティグループ等＞
つぎに、複数の管理用サーバ６０相互間の通信、ならびに管理用サーバ６０とルータ３０との間の通信等について、図２等を参照しながら詳細に説明する。図２は、管理用サーバ６０のセキュリティ設定等を示す概念図である。

管理用サーバ６０は、当該管理用サーバ６０自身に対するルータ３０からの起動指令（当該管理用サーバ６０自身を起動すべき旨の起動指令）および停止指令（当該管理用サーバ６０自身を停止すべき旨の停止指令）を受け付けない（許容しない）。当該管理用サーバ６０に関するセキュリティの低下を回避するためである。たとえば、管理用サーバ６０Ａは、ルータ３０Ａからの起動指令（当該管理用サーバ６０Ａ自身を起動すべき旨の起動指令）を受け付けない。また、管理用サーバ６０Ｚは、ルータ３０Ａからの起動指令（当該管理用サーバ６０Ｚ自身を起動すべき旨の起動指令）を受け付けない。管理用サーバ６０Ｂも同様である。換言すれば、ルータ３０（３０Ａ等）が管理用サーバ６０（６０Ａ等）の起動指令を直接的に当該管理用サーバ６０に付与することは、許容されない。これにより、管理用サーバ６０に関するセキュリティの低下が回避される。

また、複数のサブシステム１００の各管理用サーバ６０は、（他のサブシステム１００の）他の管理用サーバ６０からの起動指令を受け付け得る（許容する）ように設定される。たとえば、サブシステム１００Ａの管理用サーバ６０Ａは、他のサブシステム１００Ｚの管理用サーバ６０Ｚからの起動指令（および他のサブシステム１００Ｂの管理用サーバ６０Ｂからの起動指令）を受け付け得るように設定される。また、サブシステム１００Ｂの管理用サーバ６０Ｂは、他のサブシステム１００Ｚの管理用サーバ６０Ｚからの起動指令（および他のサブシステム１００Ａの管理用サーバ６０Ａからの起動指令）を受け付け得るように設定される。同様に、サブシステム１００Ｚの管理用サーバ６０Ｚは、他のサブシステム１００Ａの管理用サーバ６０Ａからの起動指令（および他のサブシステム１００Ｂの管理用サーバ６０Ｂからの起動指令）を受け付け得るように設定される。

なお、一般的には、サーバは、他のシステム（サブシステムを含む）のサーバからの起動および停止等に関する指令を受け付けることが出来ないように設定される。たとえば、サブシステム１００Ａの管理用サーバ６０Ａは、一般的には、他のサブシステム１００Ｚの管理用サーバ６０Ｚからの起動指令（および他のサブシステム１００Ｂの管理用サーバ６０Ｂからの起動指令）を受け付けることが出来ないように設定される。しかしながら、本願においては、このような一般的な設定とは異なり、各管理用サーバ６０は、（他のサブシステム１００の）他の管理用サーバ６０からの起動指令を受け付け得るように設定される。

このように、各サブシステム１００の各管理用サーバ６０に関して、他のサブシステム１００の管理用サーバ６０からの起動指令を受け付け得るようなセキュリティ設定が行われる。換言すれば、複数の管理用サーバ６０Ｚ，６０Ａ，６０Ｂ，...は、互いに起動指令を許容するセキュリティグループを構成する。すなわち、複数の管理用サーバ６０Ｚ，６０Ａ，６０Ｂ，...は、同じセキュリティグループに所属する。

なお、各管理用サーバ６０は、上述のように、各ルータ３０からの起動指令（当該管理用サーバ６０自身を起動すべき旨の起動指令）および停止指令（当該管理用サーバ６０自身を停止すべき旨の停止指令）を受け付けない（許容しない）。端的に言えば、各管理用サーバ６０は、各ルータ３０とは別のセキュリティグループに属する。

換言すれば、各管理用サーバ６０は、複数のルータ３０からの起動指令を許容せず且つ同一のセキュリティグループの他の管理用サーバ６０からの起動指令を許容するセキュリティ設定、を有している。より詳細には、各管理用サーバ６０は、複数のルータ３０からの起動指令を許容せず且つ複数のルータ３０からの（他の管理用サーバ６０）の起動依頼を許容し且つ他の管理用サーバ６０からの起動指令を許容するセキュリティ設定、を有している。

そして、管理用サーバ６０Ａは、上述のように、（ルータ３０Ａからの起動指令に基づいて（直接的に）起動されるのではなく、）ルータ３０Ａからの起動依頼を受信した他の管理用サーバ６０Ｚ等によって（間接的に）起動される。このように、管理用サーバ６０に関する起動指令は、ルータ３０からではなく（同一のセキュリティグループの）他の管理用サーバ６０から受け付けられる。

なお、同様に、各管理用サーバ６０と各クラウドサーバ５０とは互いに異なるセキュリティグループに属する。

次に、管理用サーバ６０とルータ３０との間における、起動指令以外の情報の送受信について説明する。

まず、ルータ３０は、自身が所属するサブシステム１００の障害通知（障害情報を含む）を、同じサブシステム１００の管理用サーバ６０に対しては送信する。たとえば、サブシステム１００Ａのルータ３０Ａは、当該ルータ３０Ａ自身が所属するサブシステム１００Ａの障害通知を、同じサブシステム１００Ａの管理用サーバ６０Ａに対しては送信する。換言すれば、管理用サーバ６０Ａは、その稼働中において、管理用サーバ６０Ａと同じサブシステム１００Ａに属するルータ３０Ａから送信されてくる障害通知をも受け付け得る。

ただし、第１実施形態においては、ルータ３０は、他のサブシステム１００の管理用サーバ６０に対しては障害通知（障害情報を含む）を送信しない。たとえば、サブシステム１００Ａのルータ３０Ａは、別のサブシステム１００Ｚ，１００Ｂの管理用サーバ６０Ｚ，６０Ｂに対しては、自サブシステム１００Ａの障害通知を送信しない。換言すれば、管理用サーバ６０Ｚは、他のサブシステム１００Ａに属するルータ３０Ａからの障害通知を受信しない。サブシステム１００Ａの障害通知（障害情報を含む）は、管理用サーバ６０Ａの起動後に、ルータ３０Ａから管理用サーバ６０Ａに送信される。これによれば、或るサブシステム１００Ａの障害情報が別のサブシステム１００Ｚ，１００Ｂの管理用サーバ６０Ｚ，６０Ｂに送信されず格納もされないので、サブシステム１００単位での情報分離を促進し、より高いセキュリティを確保することが可能である。

また、ルータ３０は、別のサブシステム１００の管理用サーバ６０に対して、自サブシステム１００の管理用サーバ６０の「起動依頼」を送信する。たとえば、ルータ３０Ａは、他のサブシステム１００Ｚの管理用サーバ６０Ｚに対して、自サブシステム１００Ａの管理用サーバ６０Ａの「起動依頼」（詳細には、管理用サーバ６０Ａを起動すべき旨の起動依頼）を送信する。

このように、第１実施形態においては、各ルータ３０は、他のサブシステム１００の管理用サーバ６０に対しては、自サブシステム１００の管理用サーバ６０の「起動依頼」のみを送信する。

なお、後述するように、第２実施形態においては、ルータ３０は、当該ルータ３０自身が所属するサブシステム１００の障害通知（障害情報を含む）を、同じサブシステムの管理用サーバ６０Ａに対して送信し得るとともに、別のサブシステム１００の管理用サーバ６０に対しても当該障害通知を送信し得る。換言すれば、管理用サーバ６０は、任意のサブシステム１００のルータ３０からの障害通知を受信し得る。また、各ルータ３０は、他のサブシステム１００の管理用サーバ６０に対して、自サブシステム１００の管理用サーバ６０の「起動依頼」を送信し得る。

特に、第２実施形態においては、ルータ３０Ａは、当該ルータ３０Ａ自身が所属するサブシステム１００Ａの管理用サーバ６０Ａが稼働していない場合、他のサブシステム１００の管理用サーバ６０Ｚに対して、管理用サーバ６０Ａの起動依頼とともにサブシステム１００Ａの障害通知（障害情報を含む）を送信する。これによれば、後述するように、他の管理用サーバ６０（６０Ｚ）による管理者への障害発生通知処理等を比較的早期に行うことが可能である。

また、後述するように、第３実施形態においても、ルータ３０は、当該ルータ３０自身が所属するサブシステム１００の障害通知（障害情報を含む）を、同じサブシステムの管理用サーバ６０Ａに対して送信し得るとともに、別のサブシステム１００の管理用サーバ６０に対しても当該障害通知を送信し得る。換言すれば、管理用サーバ６０は、任意のサブシステム１００のルータ３０からの障害通知を受信し得る。

ただし、第３実施形態においては、ルータ３０から別のサブシステム１００の管理用サーバ６０への当該障害通知の送信は、当該他のサブシステム１００の管理用サーバ６０に対する「起動依頼」として利用される。換言すれば、管理用サーバ６０は、他のサブシステム１００からの障害通知を受信すると、当該他のサブシステム１００の管理用サーバ６０の「起動依頼」を受信したものとみなす。たとえば、管理用サーバ６０Ｚは、他のサブシステム１００Ａの障害通知を当該他のサブシステム１００Ａのルータ３０Ａから受信すると、当該他のサブシステム１００Ａの管理用サーバ６０Ａの「起動依頼」を受信したものとみなす。

これによれば、ルータ３０は、「障害通知」と当該障害通知とは別個の「起動依頼」との２つのメッセージを区別することなく常に「障害通知」を送信すればよいので、ルータ３０の処理を単純化することが可能である。

＜１−３．動作＞
以下では、サブシステム１００Ａにおける障害発生時の動作等について詳細に説明する。

図３は、個別ユーザ向けのサブシステム１００Ａにおける管理用サーバ６０Ａが稼働されていない様子を示している。上述のように、クラウドサーバ５０Ａの稼働中においても、管理用サーバ６０Ａが稼働されない。これによって、管理用サーバ６０Ａの運用コストが低減される。

ただし、管理用サーバ６０Ａは、この非稼働状態においては、ルータ３０Ａからの障害通知を受信することができない。

そこで、この実施形態においては、図４および図５等に示すように、ルータ３０Ａの障害検知アプリケーションが障害を検知すると、ルータ３０Ａは、別のサブシステム１００（ここでは１００Ｚ）の管理用サーバ６０Ｚに「起動依頼」を送信する（ステップＳ１３）。当該起動依頼は、ルータ３０Ａに対応する管理用サーバ６０Ａを起動させることを意図する依頼メッセージである。管理用サーバ６０Ｚは、当該起動依頼を受信すると、管理用サーバ６０Ａに対して起動指令を送出する（ステップＳ１４）。管理用サーバ６０Ａは、当該起動指令を受信すると、非稼働状態から稼働状態への遷移動作を開始する。すなわち、管理用サーバ６０Ａは、起動を開始する（ステップＳ１５）。なお、管理用サーバ６０Ａは、非稼働状態においても、同一セキュリティグループに属する他の管理用サーバ６０Ｚからの起動指令を受信することが可能である。

そして、稼働状態に遷移した管理用サーバ６０Ａ（起動完了した管理用サーバ６０Ａ）は、ルータ３０Ａから障害通知を受信する（ステップＳ１９）。

図４は、第１実施形態に係るシステムの詳細動作を示すタイミングチャートである。図４を参照しながら詳細動作について説明する。

まず、ステップＳ１１においてルータ３０Ａ（詳細には障害検知アプリケーション）が何らかの障害を検知すると、ルータ３０Ａは、管理用サーバ６０Ａとの通信を試行して、ルータ３０Ａと管理用サーバ６０Ａとの接続状態を確認する（ステップＳ１２）。換言すれば、ルータ３０Ａは、管理用サーバ６０Ａが稼働している（稼働状態を有している）か否かを判定する。

ルータ３０Ａと管理用サーバ６０Ａとが接続されている（管理用サーバ６０Ａが稼働中）と判定される場合には、ルータ３０Ａは、障害検知アプリケーションによって検知された障害情報を含む障害通知を管理用サーバ６０Ａに送信する。そして、管理用サーバ６０Ａは、後述するような通知動作等を実行する。

ただし、ここでは、管理用サーバ６０Ａは非稼働状態（たとえばスリープ状態）を有しており、ルータ３０Ａと管理用サーバ６０Ａとが接続されていない（管理用サーバ６０Ａが稼働していない（稼働状態を有していない））と判定される状況を想定する。

ルータ３０Ａと管理用サーバ６０Ａとが接続されていない（管理用サーバ６０Ａが非稼働中）と判定される場合には、ルータ３０Ａは、管理用サーバ６０Ａの起動依頼を管理用サーバ６０Ｚに対して送信する（ステップＳ１３）（図５も参照）。図５は、管理用サーバ６０Ａが非稼働状態を有する状況を示す概念図である。

なお、この実施形態においては、上述のように管理用サーバ６０Ｚが常時稼働しているものとする。そして、管理用サーバ６０Ａは、複数の管理用サーバ６０のうち常に管理用サーバ６０Ｚを「起動依頼」の送信先として決定し、当該起動依頼を常に管理用サーバ６０Ｚに送信するものとする。

管理用サーバ６０Ｚは、当該起動依頼に基づいて、管理用サーバ６０Ａに対して起動指令を送信する（ステップＳ１４）。

管理用サーバ６０Ａは、当該起動指令に応じて起動を開始し（ステップＳ１５）、その後起動が完了する（ステップＳ１６）。

管理用サーバ６０Ａは、その起動が完了すると、起動完了通知を管理用サーバ６０Ｚに送信し（ステップＳ１７）、さらに管理用サーバ６０Ｚは、当該起動完了通知をルータ３０Ａに送信する（ステップＳ１８）。当該起動完了通知は、たとえば、ステップＳ１３の起動依頼に対するレスポンスとして、管理用サーバ６０Ｚからルータ３０ＡへとステップＳ１８にて送信されればよい。

ルータ３０Ａは、起動完了通知によって管理用サーバ６０Ａの起動が完了したことを知得すると、障害検知アプリケーションによってステップＳ１１で検知されていた障害情報（障害内容等に関する情報を含む）を管理用サーバ６０Ａに送信する（ステップＳ１９）。

管理用サーバ６０Ａは、当該障害情報を受信すると、ステップＳ２２以降の処理を実行する（図６も参照）。なお、図６は、管理用サーバ６０Ａの起動完了後に実行される処理を示す概念図である。

具体的には、管理用サーバ６０Ａは、当該障害情報を受信すると、まず、顧客情報蓄積サーバ７０にアクセスし、当該障害情報に基づきサブシステム１００Ａの管理ユーザの連絡先（電子メールアドレス等）を取得する。詳細には、まず、管理用サーバ６０Ａは、サブシステム１００Ａに関する顧客情報要求を顧客情報蓄積サーバ７０に送信する（ステップＳ２２）。そして、管理用サーバ６０Ａは、当該顧客情報要求に応じて顧客情報蓄積サーバ７０から送信されてきた顧客情報（詳細にはサブシステム１００Ａの管理ユーザの電子メールアドレス等）を受信する（ステップＳ２３）。

そして、ステップＳ２４において、管理用サーバ６０Ａは、サブシステム１００Ａにて障害が発生した旨を示す電子メールを管理ユーザの電子メールアドレス宛に送信する。サブシステム１００Ａの管理ユーザは、その端末装置（管理者端末）９０で当該電子メールを受信し、サブシステム１００Ａにて障害が発生した旨を知得する。

なお、ここでは、顧客情報蓄積サーバ７０にアクセスして、サブシステム１００Ａの管理ユーザの連絡先（電子メールアドレス）が取得されているが、これに限定されない。たとえば、当該管理ユーザの連絡先が管理用サーバ６０Ａ内の格納部に予め格納されており、管理用サーバ６０Ａが、当該管理ユーザの連絡先を、当該格納部から抽出することによって取得するようにしてもよい。

また、管理用サーバ６０Ａは、障害情報を受信（ステップＳ１９）した後、障害情報蓄積サーバ８０にもアクセスする。具体的には、管理用サーバ６０Ａは、管理用サーバ６０Ｚから受信した障害情報を障害情報蓄積サーバ８０に送信するとともに、当該障害情報に関する障害解消策を障害情報蓄積サーバ８０に要求する（ステップＳ２５）。障害情報蓄積サーバ８０は、過去の障害情報等とそれぞれの解消策とが対応付けられて記憶された障害情報蓄積データベースを有している。障害情報蓄積サーバ８０は、当該障害情報蓄積データベースと管理用サーバ６０Ａから受信した障害情報とに基づき、当該障害の解消策を検索する。そして、障害情報蓄積サーバ８０は、検索された解消策を管理用サーバ６０Ａに送信する（ステップＳ２６）。

管理用サーバ６０Ａは、受信した解消策に基づき障害解消処理（リカバリー処理）を実行する（ステップＳ２７）。たとえば、解消策としてルータ３０の「再起動」が指定されている場合には、管理用サーバ６０Ａは、ルータ３０の再起動を実行する。また、「アップデート処理」（ルータ３０に実装されたアプリケーション（サービス転送ソフトウエア等）を最新バージョンへアップデートするアップデート処理等）が解消策として指定されている場合には、管理用サーバ６０Ａは当該アップデート処理を実行する。

また、管理用サーバ６０Ａは、受信した解消策（および障害解消処理を実行した旨）を記述した電子メールを管理ユーザの電子メールアドレス宛に送信する（ステップＳ２８）。

以上のような動作によれば、管理用サーバ６０Ａの非稼働中にサブシステム１００Ａの障害が検知されると、ルータ３０Ａは、サブシステム１００Ａの管理用サーバ６０Ａを起動すべき旨の起動依頼を、管理用サーバ６０Ａとは別の管理用サーバ６０Ｚに対して送信する。そして、当該管理用サーバ６０Ｚは、当該起動依頼に基づいて、管理用サーバ６０Ａに対して起動指令を送信する。これによって、管理用サーバ６０Ａが起動される。

したがって、必ずしも管理用サーバを常時稼働させることを要さず、管理用サーバ６０Ａを必要に応じて起動することが可能である。したがって、管理用サーバ６０Ａを常時起動させた状態で運用することに伴う運用コストを低減することが可能である。

特に、非稼働状態の管理用サーバ６０Ａを起動するために、別のサブシステム１００Ａ向けの既存の管理用サーバ６０Ｚが利用される（管理用サーバ６０Ｚが管理用サーバ６０Ａを起動する）ので、既存のサーバとは異なる新たなサーバを用いることを要しない。したがって、コストアップを防止することが可能である。

なお、上記実施形態においては、管理用サーバ６０Ａが稼働していない場合、管理用サーバ６０Ｚが常時稼働していることを前提に、ルータ３０Ａは常に管理用サーバ６０Ｚに対して起動依頼を送信するものとしているが、これに限定されない。たとえば、複数のサブシステム１００の複数の管理用サーバ６０のうち、実際に稼働している装置が検出され、検出された装置（いずれかの管理用サーバ６０）に対して起動依頼が送出されるようにしてもよい。たとえば、ルータ３０Ａは、同一のセキュリティグループに属する複数の管理用サーバ６０の稼働状態を所定の順序に従って確認し、最初に稼働していると判定された管理用サーバ６０に対して起動依頼を送信するようにしてもよい。あるいは、複数の管理用サーバ６０のいずれかが時間帯に応じて稼働している場合には、ルータ３０Ａは、各時間帯に対応する管理用サーバ６０に対して起動依頼を送信するようにしてもよい。

＜２．第２実施形態＞
上記第１実施形態においては、起動指令（ステップＳ１４）に応答して管理用サーバ６０Ａが非稼働状態から稼働状態に遷移した後に、ステップＳ２２〜Ｓ２６の処理が実行されているが、本発明はこれに限定されない。たとえば、図７に示すように、ステップＳ１４の起動指令に応答して、管理用サーバ６０Ａの起動が開始された後且つ当該管理用サーバ６０Ａの起動が完了する前に、ステップＳ３２〜Ｓ３６（ステップＳ２２〜Ｓ２６に対応する処理）が実行されるようにしてもよい。

第２実施形態においては、このような動作について説明する。

また、第２実施形態においては、ルータ３０（３０Ａ等）は、当該ルータ３０自身が所属するサブシステム１００の障害通知（障害情報を含む）を、同じサブシステム１００の管理用サーバ６０（６０Ａ等）に対してのみならず、別のサブシステム１００の管理用サーバ６０（６０Ｚ等）に対しても送信し得るものとする。すなわち、管理用サーバ６０は、任意のサブシステム１００のルータ３０からの障害通知を受信し得る。

特に、第２実施形態においては、ルータ３０Ａは、当該ルータ３０Ａ自身が所属するサブシステム１００Ａの管理用サーバ６０Ａが稼働していない場合、他のサブシステム１００Ｚの管理用サーバ６０Ｚに対して、管理用サーバ６０Ａの起動依頼とともにサブシステム１００Ａの障害通知（障害情報を含む）を送信する。これによれば、後述するように、他の管理用サーバ６０（６０Ｚ）による管理者への障害発生通知処理等（ステップＳ３２〜Ｓ３６）を比較的早期に行うことが可能である。

図７は、第２実施形態に係るシステムの動作を示すタイミングチャートである。また、図８〜図１０は、システムの動作を示す概念図である。これらの図を参照しながら詳細動作について説明する。

図７に示すように、ステップＳ１１およびステップＳ１２において第１実施形態と同様の処理が実行された後、管理用サーバ６０Ａの非稼働が判定されると、ステップＳ１３（Ｓ１３ｂ）の処理が実行される（図８も参照）。なお、図８は、管理用サーバ６０Ａが非稼働状態を有する状況を示す概念図である。

このステップＳ１３ｂでは、ルータ３０Ａは、管理用サーバ６０Ａが非稼働状態を有することに基づき、管理用サーバ６０Ｚを起動依頼等の送信先として決定する。そして、ルータ３０Ａは、当該起動依頼とともに障害通知（障害情報を含む）をも管理用サーバ６０Ｚに送信する。

管理用サーバ６０Ｚは、次に、管理用サーバ６０Ａに対して起動指令を送信する（ステップＳ１４）。

管理用サーバ６０Ａは、当該起動指令に応じて起動を開始する（ステップＳ１５）。

その後、管理用サーバ６０Ｚは、管理用サーバ６０Ａの起動が完了する前に、ステップＳ３２〜Ｓ３６の処理を実行する（図９も参照）。具体的には、管理用サーバ６０Ｚは、管理用サーバ６０Ａに代わって、ステップＳ２２〜Ｓ２６と同様の処理を実行する。換言すれば、管理用サーバ６０Ｚは、管理用サーバ６０Ａで行うべき処理（障害通知処理等）を代理実行する。ステップＳ３２〜Ｓ３６は、管理用サーバ６０Ａではなく管理用サーバ６０Ｚが主体となって各種処理を行う点で、ステップＳ２２〜Ｓ２６と相違する。なお、図９は、管理用サーバ６０Ａの起動開始後且つ起動完了前に実行される処理を示す概念図である。

具体的には、管理用サーバ６０Ｚは、まず、顧客情報蓄積サーバ７０にアクセスし、サブシステム１００Ａ（障害が発生しているサブシステム）の管理ユーザの連絡先（電子メールアドレス等）を取得する。具体的には、管理用サーバ６０Ｚは、障害が発生しているサブシステム１００Ａの顧客情報を要求するメッセージ（「顧客情報要求」）を顧客情報蓄積サーバ７０に送信し（ステップＳ３２）、当該顧客情報要求に応じて顧客情報蓄積サーバ７０から送信されてきた顧客情報（詳細にはサブシステム１００Ａの管理ユーザの電子メールアドレス等）を受信する（ステップＳ３３）。

なお、第２実施形態においては、各管理用サーバ６０は、自らが所属するサブシステム以外のサブシステムの顧客に関する情報をも顧客情報蓄積サーバ７０から取得することを許可されている。たとえば、管理用サーバ６０Ｚは、自身が所属するサブシステム１００Ｚ以外のサブシステム１００Ａの顧客（管理ユーザ）に関する情報をも顧客情報蓄積サーバ７０から取得することが可能である。

そして、ステップＳ３４において、管理用サーバ６０Ｚは、サブシステム１００Ａにて障害が発生した旨を示す電子メールをサブシステム１００Ａの管理ユーザの電子メールアドレス宛に送信する。当該管理ユーザは、その端末装置（管理者端末）９０で当該電子メールを受信し、サブシステム１００Ａにて障害が発生した旨を知得する。

また、管理用サーバ６０Ｚは、障害情報蓄積サーバ８０にもアクセスする。具体的には、管理用サーバ６０Ｚは、ステップＳ１３ｂでルータ３０Ａから受信した障害情報を、障害情報蓄積サーバ８０に送信するとともに、当該障害情報に関する障害解消策を障害情報蓄積サーバ８０に要求する（ステップＳ３５）。障害情報蓄積サーバ８０は、管理用サーバ６０Ｚから受信した障害情報と障害情報蓄積サーバ８０の格納部に格納された障害情報蓄積データベースとに基づき、当該障害の解消策を検索する。そして、障害情報蓄積サーバ８０は、検索結果に係る解消策を管理用サーバ６０Ｚに送信する（ステップＳ３６）。ただし、この時点では、未だ管理用サーバ６０Ａが稼働状態に復帰していないので、管理用サーバ６０Ｚから管理用サーバ６０Ａへの当該解消策の送信は未だ行われない。

その後、ステップＳ３７において、管理用サーバ６０Ａの起動が完了すると、管理用サーバ６０Ａは、起動完了通知を管理用サーバ６０Ｚに送信する（ステップＳ３８）。

管理用サーバ６０Ｚは、管理用サーバ６０Ａの起動完了通知を受信すると、ステップＳ３６で受信していた解消策を管理用サーバ６０Ａに送信する（ステップＳ３９）（図１０も参照）。

管理用サーバ６０Ａは、受信した解消策に基づき障害解消処理を実行する（ステップＳ４１）。また、管理用サーバ６０Ａは、受信した解消策等を記述した電子メールをサブシステム１００Ａの管理ユーザの電子メールアドレス宛に送信する（ステップＳ４２）。

以上のような動作によれば、第１実施形態と同様の効果を得ることが可能である。

また特に、ルータ３０Ａは、当該ルータ３０Ａ自身が所属するサブシステム１００Ａの管理用サーバ６０Ａが稼働していない場合、他のサブシステム１００の管理用サーバ６０Ｚに対して、管理用サーバ６０Ａの起動依頼とともにサブシステム１００Ａの障害通知を送信する（ステップＳ１３ｂ）。そして、管理用サーバ６０Ａの起動完了を待たずに、サブシステム１００Ａに関する障害の発生が管理用サーバ６０Ｚからサブシステム１００Ａの管理ユーザに比較的早期に通知される（ステップＳ３４）。したがって、当該管理ユーザは、障害の発生を比較的早期に知得することが可能である。ひいては、当該管理ユーザは、当該障害への対応をさらに迅速に開始することが可能である。

また、仮に、管理用サーバ６０Ａの起動に失敗した場合であっても、管理用サーバ６０Ｚからの通知によって障害の発生を確実に知得することが可能である。

なお、上記第２実施形態では、ステップＳ３４のメール通知によって、障害の発生のみが管理ユーザに通知されているが、これに限定されない。たとえば、ステップＳ３２，Ｓ３３の処理に引き続いてステップＳ３５，Ｓ３６の処理が実行された直後（管理用サーバ６０Ａの起動完了前）に、障害の発生のみならず当該障害の解消策も記述された電子メールが管理用サーバ６０Ｚから管理ユーザ宛に送信されるようにしてもよい。これによれば、管理ユーザは、障害の発生のみならず当該障害の解消策をも比較的早期に知得することが可能である。

＜３．第３実施形態＞
第３実施形態においては、第２実施形態と同様に、管理用サーバ６０は、任意のサブシステム１００のルータ３０からの障害通知（障害情報を含む）を受信し得る。換言すれば、ルータ３０は、当該ルータ３０自身が所属するサブシステム１００の障害通知（障害情報を含む）を、同じサブシステムの管理用サーバ６０Ａに対して送信し得るとともに、別のサブシステム１００の管理用サーバ６０に対しても当該障害通知を送信し得る。

ただし、第３実施形態においては、ルータ３０から他のサブシステム１００の管理用サーバ６０への障害通知の送信は、当該他のサブシステム１００の管理用サーバ６０の起動を依頼する「起動依頼」として利用される。換言すれば、管理用サーバ６０は、自らのサブシステム１００ではなく他のサブシステム１００の障害通知を受信すると、当該他のサブシステム１００の管理用サーバ６０の「起動依頼」を受信したものとみなす。たとえば、管理用サーバ６０Ｚは、他のサブシステム１００Ａの「障害通知」を当該他のサブシステム１００Ａのルータ３０Ａから受信すると、当該他のサブシステム１００Ａの管理用サーバ６０Ａの起動を依頼する「起動依頼」を受信したものとみなす。

すなわち、第３実施形態においては、ルータ３０は、「障害通知」とは異なる別個のメッセージを「起動依頼」として送信するのではなく、「障害通知」（障害情報を含む）を「起動依頼」として利用する。たとえば、ルータ３０Ａは、自らのサブシステム１００Ａ以外の他のサブシステム１００Ｚの管理用サーバ６０Ｚに「障害通知」を送信する（ステップＳ５３（図１１参照））ことによって、当該「障害通知」を「起動依頼」として利用する。なお、管理用サーバ６０Ａの起動完了後等において、ルータ３０Ａが自らのサブシステム１００Ａの管理用サーバ６０Ａに「障害通知」（起動依頼として既に送信した障害通知と同じ内容の障害通知）を送信する（ステップＳ５９）場合、当該「障害通知」は「起動依頼」としてではなく本来の「障害通知」として機能する。

また、複数の管理用サーバ６０のそれぞれは、障害通知を受信すると、障害通知が自らのサブシステム１００のルータ３０から送信されたものであるか否かを判定する。受信された通知（障害通知）が他のサブシステム１００の特定のルータ３０から送信されたものであると判定される場合、管理用サーバ６０は、当該通知（障害通知）を「起動依頼」として判定し、当該特定のルータ３０の起動指令を特定のルータに送信する。一方、当該通知が自らのサブシステムのルータから送信されたものであると判定される場合、当該通知を本来の障害通知として判定し、当該管理用サーバ６０は、障害情報の解消策を実行する。

これによれば、ルータ３０は、「障害通知」と当該障害通知とは別個の「起動依頼」との２つのメッセージを区別することなく常に「障害通知」を送信すればよいので、ルータ３０の処理を単純化することが可能である。

図１１は、第３実施形態に係るシステム１の動作を示すタイミングチャートである。また、図１２〜図１５は、当該システムの動作を示す概念図である。これらの図を参照しながら当該動作について説明する。第３実施形態に係る動作は、第１実施形態の動作に類似する。以下、第１実施形態との相違点を中心に説明する。

図１１に示すように、ステップＳ１１およびステップＳ１２において第１実施形態と同様の処理が実行された後、管理用サーバ６０Ａの非稼働が判定されると、ステップＳ５３の処理が実行される（図１２も参照）。なお、図１２は、管理用サーバ６０Ａが非稼働状態を有する状況を示している。

ステップＳ５３において、ルータ３０Ａは管理用サーバ６０Ｚに障害通知（障害情報を含む）を送信する（ステップＳ５３）。

この際、たとえば、ルータ３０Ａは、当該障害通知の送信先を、稼働中の少なくとも１つの管理用サーバ６０（通信可能と判断される管理用サーバ６０）の中から所定の優先順位に従って決定する。所定の優先順位としては、（自らのサブシステム１００Ａの）管理用サーバ６０Ａが第１順位、管理用サーバ６０Ｚが第２順位、管理用サーバ６０Ｂが第３順位である旨が設定される。そして、第１順位の管理用サーバ６０Ａが稼働中ではなく第２順位の管理用サーバ６０Ｚが稼働中であることに基づいて、管理用サーバ６０Ｚが送信先として決定される。そして、ルータ３０Ａは、当該送信先として決定された管理用サーバ６０（ここでは６０Ｚ）に対して、当該障害通知を送信する。

管理用サーバ６０Ｚは、当該障害通知を受信すると、当該障害通知に含まれる招待情報に基づき何れのサブシステム１００にて障害が発生しているかを特定する。そして、管理用サーバ６０Ｚは、特定されたサブシステム１００（障害発生中のサブシステム）が、自らのサブシステム１００Ｚであるか或いは他のサブシステム１００であるかを判定する。換言すれば、当該障害通知が自らのサブシステム１００のルータ３０から送信されたものであるか否かが判定される。障害発生中のサブシステム１００が自らのサブシステム１００Ｚ以外の他のサブシステム１００であると判定されると、管理用サーバ６０Ｚは、障害発生中のサブシステム１００に対応する管理用サーバ６０に対して起動指令を送信する。たとえば、サブシステム１００Ａにて障害が発生している旨が当該障害情報に基づいて特定されると、サブシステム１００Ａに対応する管理用サーバ６０Ａに対して起動指令を送信する（Ｓ５４）（図１２も参照）。

管理用サーバ６０Ａは、当該起動指令に応じて起動を開始し（ステップＳ１５）、その後起動が完了する（ステップＳ１６）。

管理用サーバ６０Ａは、その起動が完了すると、起動完了通知を管理用サーバ６０Ｚに送信する（ステップＳ５７）。さらに、管理用サーバ６０Ｚは、起動完了通知をルータ３０Ａに送信する（ステップＳ５８）（図１３も参照）。ルータ３０Ａへの起動完了通知は、障害通知を再送すべき旨を示す再送依頼でもある。

ルータ３０Ａは、起動完了通知（障害通知の再送依頼）を受信すると、ステップＳ５３で送信した障害通知（障害情報を含む）と同じ内容の障害通知を、今度は、起動完了後の管理用サーバ６０Ａに対して送信する（ステップＳ５９）（図１４も参照）。

この際、ルータ３０Ａは、当該障害通知の送信先を、稼働中の少なくとも１つの管理用サーバ６０（通信可能と判断される管理用サーバ６０）の中から所定の優先順位に従って決定する。たとえば、第１順位の管理用サーバ６０Ａが稼働中であることに基づいて、管理用サーバ６０Ａが送信先として決定される。そして、ルータ３０Ａは、当該送信先として決定された管理用サーバ６０（ここでは６０Ａ）に対して、当該障害通知を送信する。

以降、第１実施形態と同様に、ステップＳ２２〜Ｓ２８の処理が実行される（図１５も参照）。なお、図１５は、管理用サーバ６０Ａの起動完了後且つ障害通知（ステップＳ５９）後に実行される処理を示す概念図である。

このような態様によっても、第１実施形態と同様の効果を得ることが可能である。

なお、第３実施形態に対して第２実施形態と同様の改変を行うことも可能である。具体的には、管理用サーバ６０Ｚからの起動指令（Ｓ５４）に応じた管理用サーバ６０Ａの起動完了前に、ステップＳ３２〜Ｓ３６（ステップＳ２２〜Ｓ２６）の処理等が行われるようにしてもよい。

＜４．変形例等＞
以上、この発明の実施の形態について説明したが、この発明は上記説明した内容のものに限定されるものではない。

たとえば、上記各実施形態等においては、電子メールを用いて各種の情報が管理ユーザに通知されているがこれに限定されない。たとえば、各種のアプリケーション（メッセージ通信アプリケーション）を用いて直接的にメッセージが送信されるようにしてもよい。

また、上記各実施形態等においては、障害情報蓄積サーバ８０に格納された障害情報蓄積データベースに基づいて障害解消策が検索される態様が例示されているが、これに限定されない。たとえば、管理用サーバ６０の格納部に格納された障害情報蓄積データベースに基づいて、障害解消策が検索されるようにしてもよい。

また、上記各実施形態等においては、障害検知アプリケーションがルータ３０に実装されている態様が例示されているが、これに限定されず、たとえば、障害検知アプリケーションがＬＡＮ側の各種機器（たとえばＭＦＰ１０）に実装されていてもよい。そして、当該障害内容等がルータ３０を介して管理用サーバ６０に送信されるようにしても良い。

１ クラウドシステム（障害検知システム）
１０ ＭＦＰ（ＬＡＮ内装置）
１００，１００Ｚ，１００Ａ，１００Ｂ サブシステム
３０，３０Ａ，３０Ｂ ルータ
５０，５０Ａ，５０Ｂ，５０Ｚ クラウドサーバ
６０，６０Ａ，６０Ｂ，６０Ｚ 管理用サーバ
７０ 顧客情報蓄積サーバ
８０ 障害情報蓄積サーバ

Claims (17)

1. 複数のサブシステムを備えるクラウドシステムであって、
   前記複数のサブシステムは、それぞれ、
   クラウド側ネットワークとイントラネット側ネットワークとを仲介するルータと、
   前記クラウド側ネットワークに設けられるクラウドサービス提供用サーバと、
   前記クラウドサービス提供用サーバとは別個に前記クラウド側ネットワークに設けられる管理用サーバであって、各サブシステムの各障害検知アプリケーションによって検知された障害に関する情報を前記ルータを介して受信する管理用サーバと、
   を備え、
   前記複数のサブシステムのうちの特定のサブシステムにおける特定の管理用サーバは稼働しておらず、且つ、前記複数のサブシステムに設けられた複数の管理用サーバのうち少なくとも前記特定のサブシステム以外のサブシステムに属する一の管理用サーバは稼働している状態において、前記特定のサブシステムにおける障害が検知される場合には、前記特定のサブシステムのルータである特定のルータは、前記特定の管理用サーバの起動依頼を、前記一の管理用サーバに対して送信し、
   前記一の管理用サーバは、前記起動依頼に基づいて前記特定の管理用サーバに対して起動指令を送信し、
   前記特定のルータは、前記一の管理用サーバからの前記起動指令に基づいて起動することを特徴とするクラウドシステム。
2. 請求項１に記載のクラウドシステムにおいて、
   前記特定の管理用サーバは、前記起動指令に応じた起動完了後に、前記障害を解消するための障害解消処理を実行することを特徴とするクラウドシステム。
3. 請求項１に記載のクラウドシステムにおいて、
   前記各サブシステムの各障害検知アプリケーションは、それぞれ、前記各サブシステムの各ルータに実装されていることを特徴とするクラウドシステム。
4. 請求項１に記載のクラウドシステムにおいて、
   前記特定のルータは、前記複数の管理用サーバのうち稼働中の管理用サーバを前記一の管理用サーバとして特定することを特徴とするクラウドシステム。
5. 請求項１に記載のクラウドシステムにおいて、
   前記特定のサブシステムにおける障害検知アプリケーションは、
   前記特定のサブシステムにおける障害を検知すると、前記特定の管理用サーバが稼働しているか否かを判定し、
   前記特定の管理用サーバが稼働していないと判定される場合、前記複数の管理用サーバの中から稼働中の前記一の管理用サーバを検出することを特徴とするクラウドシステム。
6. 請求項１に記載のクラウドシステムにおいて、
   前記複数の管理用サーバは、それぞれ、前記複数のサブシステムの複数のルータからの起動指令を許容せず且つ前記複数のルータからの他の管理用サーバの起動依頼を許容し且つ他の管理用サーバからの起動指令を許容するセキュリティ設定、を有していることを特徴とするクラウドシステム。
7. 請求項１に記載のクラウドシステムにおいて、
   前記特定のルータは、
   障害情報を含む障害通知を、前記起動依頼として利用して前記一の管理用サーバに送信するとともに、
   前記起動依頼として既に送信した前記障害通知と同じ内容の障害通知を、前記特定の管理用サーバの起動完了後において、前記特定の管理用サーバに送信し、
   前記複数の管理サーバのそれぞれは、
   障害通知が受信されると、受信した障害通知である第１の通知が自らのサブシステムのルータから送信されたものであるか否かを判定し、
   前記第１の通知が自らのサブシステムのルータから送信されたものであると判定される場合、前記障害情報の解消策を実行し、
   前記第１の通知が他のサブシステムのルータである前記特定のルータから送信されたものであると判定される場合、前記第１の通知を前記起動依頼として判定し、前記特定の管理用サーバの前記起動指令を前記特定の管理用サーバに送信することを特徴とするクラウドシステム。
8. 請求項１に記載のクラウドシステムにおいて、
   前記一の管理用サーバは、前記起動依頼を受信した後且つ前記特定のサーバの起動完了前において、前記特定のサブシステムの管理ユーザに前記特定のサブシステムにおける障害の発生を通知することを特徴とするクラウドシステム。
9. 請求項８に記載のクラウドシステムにおいて、
   前記一の管理用サーバは、前記特定のサーバの起動完了前に、顧客情報蓄積サーバにアクセスして前記特定のサブシステムの管理ユーザの電子メールアドレスを取得し、前記特定のサブシステムにおける障害の発生を通知する電子メールを前記電子メールアドレス宛に送信することを特徴とするクラウドシステム。
10. 請求項１に記載のクラウドシステムにおいて、
    前記一の管理用サーバは、
    前記起動依頼とともに受信した障害情報を障害情報蓄積サーバに送信するとともに、前記障害情報に関する障害解消策を前記障害情報蓄積サーバから受信し、
    前記特定の管理用サーバの起動完了後に前記障害解消策を前記特定の管理用サーバに送信し、
    前記特定の管理用サーバは、前記一の管理用サーバから受信した前記障害解消策に基づき、障害解消処理を実行することを特徴とするクラウドシステム。
11. 請求項１に記載のクラウドシステムにおいて、
    前記特定の管理用サーバは、前記一の管理用サーバから受信した障害情報を障害情報蓄積サーバに送信し、前記障害情報に関する障害解消策を前記障害情報蓄積サーバから受信し、前記障害解消策に基づく障害解消処理を実行することを特徴とするクラウドシステム。
12. クラウドシステムを構成する複数のサブシステムのうちの特定のサブシステムのルータであって、
    前記特定のサブシステムにおける特定の管理用サーバが稼働しているか否かを判定する判定手段と、
    前記複数のサブシステムのうち前記特定のサブシステム以外のサブシステムに属する一の管理用サーバが稼働していることを検出する検出手段と、
    前記特定の管理用サーバは稼働しておらず且つ前記一の管理用サーバは稼働している状態において、前記特定のサブシステムにおける障害が検知される場合には、前記特定の管理用サーバの起動依頼を、前記一の管理用サーバに対して送信する送信手段と、
    を備えることを特徴とするルータ。
13. クラウドシステムを構成する複数のサブシステムのうちの特定のサブシステム内のルータに内蔵されたコンピュータに、
    ａ）前記特定のサブシステムにおける特定の管理用サーバが稼働しているか否かを判定するステップと、
    ｂ）前記複数のサブシステムのうち前記特定のサブシステム以外のサブシステムに属する一の管理用サーバが稼働していることを検出するステップと、
    ｃ）前記特定の管理用サーバは稼働しておらず且つ前記一の管理用サーバは稼働している状態において、前記特定のサブシステムにおける障害が検知される場合には、前記特定の管理用サーバの起動依頼を、前記一の管理用サーバに対して送信するステップと、
    を実行させるためのプログラム。
14. クラウドシステムを構成する複数のサブシステムのうちの一のサブシステムの管理用サーバであって、
    前記複数のサブシステムのうち前記一のサブシステムとは異なる特定のサブシステムにおける障害発生通知を受け付けるべき特定の管理用サーバであって前記特定のサブシステムに属する特定の管理用サーバは稼働していない状態において、前記特定のサブシステムにおける障害検知に応じて、前記特定のサブシステムのルータである特定のルータから前記特定の管理用サーバの起動依頼を受信する受信手段と、
    前記起動依頼に基づいて、前記特定の管理用サーバに対して起動指令を送信する送信手段と、
    を備えることを特徴とする管理用サーバ。
15. 請求項１４に記載の管理用サーバにおいて、
    前記送信手段は、前記起動依頼を受信した後且つ前記特定のサーバの起動完了前において、前記特定のサブシステムの管理ユーザに前記特定のサブシステムにおける障害の発生を通知することを特徴とする管理用サーバ。
16. クラウドシステムを構成する複数のサブシステムのうちの一のサブシステムの管理用サーバに内蔵されたコンピュータに、
    ａ）前記複数のサブシステムのうち前記一のサブシステムとは異なる特定のサブシステムにおける障害発生通知を受け付けるべき特定の管理用サーバであって前記特定のサブシステムに属する特定の管理用サーバは稼働していない状態において、前記特定のサブシステムにおける障害検知に応じて、前記特定のサブシステムのルータである特定のルータから前記特定の管理用サーバの起動依頼を受信するステップと、
    ｂ）前記起動依頼に基づいて、前記特定の管理用サーバに対して起動指令を送信するステップと、
    を実行させるためのプログラム。
17. 請求項１６に記載のプログラムにおいて、
    ｃ）前記起動依頼を受信した後且つ前記特定のサーバの起動完了前において、前記特定のサブシステムの管理ユーザに前記特定のサブシステムにおける障害の発生を通知するステップ、
    を前記コンピュータにさらに実行させるためのプログラム。

Images