JP2009015425A - ログ収集システム、ログ収集方法、および、ノード - Google Patents

Abstract

【課題】 本発明の目的は、ログ消失を防止することを可能とするログ収集システム、ログ収集方法、および、ノードを提供することにある。
【解決手段】 複数のログ送出装置２ａ、２ｂと、一以上のログ登録装置７ａとがネットワーク６ａで接続され、ログ送出装置２ａ、２ｂが、ログ登録装置７ａに対して、ログを送信する手段２ａ１、２ｂ１と、前記ログの前記送信の失敗を検出する手段２ａ２、２ｂ２と、他のログ送出装置２ａ、２ｂに対して、前記ログの前記送信の代行要求を送信する手段２ａ３、２ｂ３と、前記代行要求を受信して、前記ログの代行送信を実行する手段２ａ１、２ｂ１とを有し、前記ログ登録装置７ａが、前記ログを受信して、前記ログを登録する手段とを有する。
【選択図】 図１

Description

本発明はログ収集システム、ログ収集方法、および、ノードに関し、特に、ログ消失を防止するログ収集システム、ログ収集方法、および、ノードに関する。

高い性能が要求される計算機システムでは、マルチノード構成をとることでシステム全体としての計算性能の向上を実現している。マルチノード構成とは、複数のＣＰＵと共有メモリで構成される高性能の計算機ノード（以下ノードと記載する）を、複数接続したシステムである。マルチノード構成の大規模なものには、複数のノードをまとめたクラスタを、さらに複数接続したマルチクラスタコンピュータシステムがある。マルチクラスタコンピュータシステムは、ノード間接続装置を介して複数のノードが相互に接続される。

マルチクラスタコンピュータシステムの各クラスタにはクラスタ内のノードを管理・制御するクラスタサービスプロセッサ（以下、クラスタＳＶＰと記載する）が存在する。各クラスタＳＶＰは、ローカルエリアネットワーク（ＬＡＮ）を介して、統合サービスプロセッサ（以下、統合ＳＶＰと記載する）に接続される。統合ＳＶＰは、各クラスタＳＶＰを一元的に管理・制御する。

マルチクラスタコンピュータシステムにおけるログ採取方式の関連技術として、例えば、特許文献１に記載された技術がある。これは、クラスタＳＶＰ（特許文献１では、スレーブサービスプロセッサと記載）と、統合ＳＶＰ（特許文献１では、マスタサービスプロセッサと記載）とから構成されている。クラスタＳＶＰが、ノードの障害を検出すると直ちに所定の障害情報を出力する。そして、統合ＳＶＰは、クラスタＳＶＰから障害情報を受信することにより、時系列にログを登録する。このようなログ採取方式により、保守員は、統合ＳＶＰに登録されたログを確認することで、システム内に発生した障害を発生時系列順に正確に把握することができるとある。

クラスタＳＶＰを用いないでログを採取する方式として、例えば、特許文献２に記載された技術がある。これは、複数のノード（特許文献２では、ＣＰＵセットと記載）のログを統合ＳＶＰにあたる多数決比較部配下のファイル装置に収集するものである。特許文献２に記載されたＣＰＵセットは、ＣＰＵ（セントラルプロセッシングユニット）と、メモリと、ＩＯＰ（インプットアウトプットプロセッサ）と、ＤＧＰ（診断プロセッサ）とから構成されている。あるＣＰＵセットのＤＧＰが、自身の属するＣＰＵセットの障害を検出すると、この障害に関するログを自身で多数決比較部に送信することなく、他のＣＰＵセットのＤＧＰに、ＤＧＰ間通信の専用線を介して、ログを通報する。ログ通報を受けたＤＧＰは、自身の属するＣＰＵセットのＣＰＵからＩＯＰを経由して、多数決比較部にログを送出するものである。

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

しかしながら、これら関連する技術では、統合ＳＶＰへログ登録が行われずにログが消失してしまうという問題が発生していた。問題が発生するのは、障害が発生したノードのクラスタＳＶＰが故障していた場合である。これは、特許文献１に記載された技術では、スレーブサービスプロセッサが故障していた場合であり、特許文献２に記載された技術では、ＤＧＰが故障していた場合である。また、ノードとクラスタＳＶＰ間、または、クラスタＳＶＰと統合ＳＶＰ間の通信路に、あるいは、ＤＧＰ間通信路に不具合が生じていた場合もログ消失の問題が発生する。

本発明の目的は、上記問題を解決することを可能とするログ収集システム、ログ収集方法、および、ノードを提供することにある。

本発明のログ収集システムは、複数のログ送出装置と、一以上のログ登録装置とがネットワークで接続され、前記ログ送出装置が、前記ログ登録装置に対して、ログを送信する手段と、前記ログの前記送信の失敗を検出する手段と、他の前記ログ送出装置に対して、前記ログの前記送信の代行要求を送信する手段と、前記代行要求を受信する手段と、前記ログの代行送信を実行する手段とを有し、前記ログ登録装置が、前記ログを受信して、前記ログを登録する手段を有する。

本発明のログ収集方法は、ログ送出装置が、ネットワークを介して、受信したログを登録するログ登録装置に対して前記ログを送信し、前記ログの前記送信の失敗を検出し、他の前記ログ送出装置に対して前記ログの前記送信の代行要求を送信し、前記代行要求を受信した場合に前記ログの代行送信を実行する。

本発明のノードは、コンピュータシステムのノードであって、ネットワークで接続されたログ登録装置に対してログを送信する手段と、前記ログの前記送信の失敗を検出する手段と、他の前記ノードに前記ログの前記送信の代行要求を送信する手段と、前記代行要求を受信して、前記ログの代行送信を実行する手段とを有する。

本発明によれば、ログ送出装置がログ登録装置に対して送出したログが、ログ登録装置に届かず、ログが消失してしまう問題を解決することが可能になる。

次に、本発明について図面を参照して詳細に説明する。なお、本明細書では、以下の表記方法を用いる。「ｉ」、「ｊ」、「ｋ」、および、「ｄ」は、「０」を含む自然数を示す。「ｍ」、「ｎ」は、「０」を含まない自然数を示す。

『クラスタ（＃ｉ）２ｉ』と表記した場合は、クラスタ（＃０）２０〜クラスタ（＃ｍ）２ｍのいずれかであることを示す。『ノード（＃ｊ）２ｉｊ』と表記した場合は、ノード（＃０）２ｉ０〜ノード（＃ｎ）２ｉｎのいずれかであることを示す。『クラスタＳＶＰ（＃ｉ）３ｉ』と表記した場合は、クラスタＳＶＰ（＃０）３０〜クラスタＳＶＰ（＃ｍ）３ｍのいずれかであることを示す。『ＬＡＮ（＃ｉ）４ｉ』と表記した場合は、ＬＡＮ（＃０）４０〜ＬＡＮ（＃ｍ）４ｍのいずれかであることを示す。『ＲＴＲ（＃０ｋ）１０ｋ』、または、『ＲＴＲ（＃１ｋ）１１ｋ』と表記した場合は、それぞれ、ＲＴＲ（＃００）１００〜ＲＴＲ（＃１Ｆ）１０Ｆのいずれか、または、ＲＴＲ（＃１０）１１０〜ＲＴＲ（＃１Ｆ）１１Ｆのいずれかであることを示す。『ＲＴＲ（＃ｄｋ）１ｄｋ』と表記した場合は、ＲＴＲ（＃００）１００〜ＲＴＲ（＃０Ｆ）１０Ｆ、または、ＲＴＲ（＃１０）１１０〜ＲＴＲ（＃１Ｆ）１１Ｆのいずれかであることを示す。『ＲＣＵ（＃ｋ）６ｉｊｋ』と表記した場合は、ＲＣＵ（＃０）６０００〜ＲＣＵ（＃Ｆ）６１ＦＦのいずれかであることを示す。『ＣＰＵ（＃ｋ）４ｉｊｋ』と表記した場合は、ＣＰＵ（＃０）４０００〜ＣＰＵ（＃Ｆ）４１ＦＦのいずれかであることを示す。

ＩＸＳ（Ｉｎｔｅｒｎｏｄｅ Ｃｒｏｓｓｂａｒ Ｓｗｉｔｃｈ：ノード間クロスバスイッチ）は、ノード間接続装置の一種である。

なお、以下の実施例で記載する各手段は、ハードウェアで実現されても良いし、ハードウェアと協同するソフトウェアで実現されても良い。あるいは、以下の実施例で記載する各手段は、ハードウェアと、ハードウェアと協同するソフトウェアの混在により実現されても良い。

図１を参照すると、本発明の第１の実施例は、ログ送出装置２ａと、ログ送出装置２ｂと、ログ登録装置７ａと、ネットワーク６ａとで構成されている。ログ送出装置２ａは、ログ送信手段２ａ１と、ログ送信失敗検出手段２ａ２と、代行送信要求手段２ａ３とを有している。ログ送出装置２ｂは、ログ送信手段２ｂ１と、ログ送信失敗検出手段２ｂ２と、代行送信要求手段２ｂ３とを有している。ログ登録装置７ａは、ログ受信手段７ａ１を有している。

以下の説明では、ログ送出装置２ａにおいて、図示しない手段によって生成されたログを、便宜的にログ２ａ４と呼ぶ。また、以下の説明では、ログ送出装置２ｂにおいて、図示しない手段によって生成されたログを、便宜的にログ２ｂ４と呼ぶ。

ログ送信手段２ａ１、および、ログ送信手段２ｂ１は、それぞれ、ログ２ａ４、ログ２ｂ４を、ネットワーク６ａを介して、ログ受信手段７ａ１に送信する。ログ送信失敗検出手段２ａ２、および、ログ送信失敗検出手段２ｂ２は、それぞれ、ログ送信手段２ａ１によるログ２ａ４、ログ送信手段２ｂ１によるログ２ｂ４の送信が失敗した場合に、この失敗を検出する。そして、ログ送信失敗検出手段２ａ２、および、ログ送信失敗検出手段２ｂ２は、この失敗を検出した場合は、それぞれ、代行送信要求手段２ａ３、代行送信要求手段２ｂ３にログ送信失敗を通知する。代行送信要求手段２ａ３、および、代行送信要求手段２ｂ３は、このログ送信失敗の通知を受けると、それぞれ、ログ送信手段２ｂ１にログ２ａ４の、ログ送信手段２ａ１にログ２ｂ４の送信を代行することを要求する。

ログ受信手段７ａ１は、ネットワーク６ａを介して、ログ送信手段２ａ１、あるいは、ログ送信手段２ｂ１からログ２ａ４、あるいはログ２ｂ４を受信する。そして、ログ２ａ４、あるいは、ログ２ｂ４は図示しない手段により、ログ登録装置７ａ内に登録される。

図２は、本発明の第１の実施例の動作を示すシーケンス図である。ここでは、具体的な状況として、たとえば、ログ送出装置２ａにおいて、図示しない手段によりログ２ａ４が生成されたものとする。なお、ログ送出装置２ｂにおいて、ログ２ｂ４が生成された場合の動作も、以下の説明から容易に類推可能である。また、図２では、ネットワーク６ａは省略している。

ログ送信手段２ａ１は、図示しない手段によって生成されたログ２ａ４を、ネットワーク６ａを介してログ受信手段７ａ１に向けて送信する（Ｓ１００）。

正常な場合は、ログ受信手段７ａ１は、ネットワーク６ａを介してログ２ａ４を受信する（Ｓ１０１）。そして、図示しない手段により、ログ２ａ４はログ登録装置７ａ内に登録され、動作は終了する。

なんらかの異常が発生して、ログ２ａ４の送信が失敗した場合は、ログ送信失敗検出手段２ａ２は、ログ送信失敗を検出する。そして、ログ送信失敗検出手段２ａ２は、この失敗を代行送信要求手段２ａ３に通知する（Ｓ１０２）。

代行送信要求手段２ａ３は、ログ送信手段２ｂ１にログ２ａ４の送信を代行することを要求する（Ｓ１０３）。

ログ送信手段２ｂ１は、ログ２ａ４を、ネットワーク６ａを介してログ受信手段７ａ１に向けて送信する（Ｓ１０４）。

ログ受信手段７ａ１は、ネットワーク６ａを介してログ２ａ４を受信する（Ｓ１０５）。そして、図示しない手段により、ログ２ａ４はログ登録装置７ａ内に登録され、動作は終了する。

本発明の第１の実施例によれば、あるログ送出装置からのログの送信が失敗した場合でも、ログ消失を防止することが可能となる。その理由は、他のログ送出装置に代行送信を要求し、他のログ送出装置がログの送信を代行することができるようにしたためである。

次に本発明の第２の実施例について図面を参照して詳細に説明する。

図３を参照すると、本発明の第２の実施例は、ＩＸＳ１０と、複数のクラスタ（＃ｉ）２ｉと、統合ＳＶＰ７０と、データ転送パス５０と、ＬＡＮ６０とで構成されている。

各クラスタ（＃ｉ）２ｉは、複数のノード（＃ｊ）２ｉｊと、クラスタＳＶＰ（＃ｉ）３ｉと、ＬＡＮ（＃ｉ）４ｉとを有する。

各クラスタ（＃ｉ）２ｉ内の各ノード（＃ｊ）２ｉｊと、ＩＸＳ１０とは、データ転送パス５０により接続される。各クラスタ（＃ｉ）２ｉ内の各ノード（＃ｊ）２ｉｊは、データ転送パス５０と、ＩＸＳ１０とを介して、互いに通信を行う。この通信をノード間通信と呼び、以後、「ノード間通信」と表記した場合は、特に断りがない限り、ここで説明したノード間通信を示す。

各クラスタ（＃ｉ）２ｉ内の各ノード（＃ｊ）２ｉｊと、各クラスタＳＶＰ（＃ｉ）３ｉとは、ＬＡＮ（＃ｉ）４ｉを介して接続される。クラスタＳＶＰ（＃ｉ）３ｉは、ノード（＃ｊ）２ｉｊ単位の運用、保守などを管理・制御するための処理を行う。

各クラスタＳＶＰ（＃ｉ）３ｉと、統合ＳＶＰ７０とは、ＬＡＮ６０を介して接続される。統合ＳＶＰ７０は、各クラスタＳＶＰ（＃ｉ）３ｉを一元的に管理・制御する。たとえば、保守員は、統合ＳＶＰ７０を操作して、システム内のログを含めた全ての事象を確認することができる。

ノード（＃ｊ）２ｉｊは、「ログ送出装置」に対応する。統合ＳＶＰ７０は、「ログ登録装置」に対応する。クラスタＳＶＰ（＃ｉ）３ｉと、ＬＡＮ（＃ｉ）４ｉと、ＬＡＮ６０は、「ネットワーク」に対応する。ＩＸＳ１０と、データ転送パス５０は、「代行送信を要求する手段」の一部でもある。

図４に第２の実施例の各構成品であるＩＸＳ１０、ノード（＃ｊ）２ｉｊ、クラスタＳＶＰ（＃ｉ）３ｉ、統合ＳＶＰ７０の機能ブロック図を示す。図４ではノード（＃ｊ）２ｉｊ、クラスタＳＶＰ（＃ｉ）３ｉは代表して１台のみを記載している。すなわち、ノード（＃ｊ）２ｉｊ、クラスタＳＶＰ（＃ｉ）３ｉは実際には図３のように複数台存在している。図４のノード（＃ｊ）２ｉｊに記載した各手段は、図３の全てのノード（＃ｊ）２ｉｊが備えている。図４のクラスタＳＶＰ（＃ｉ）３ｉに記載した各手段は、図３の全てのクラスタＳＶＰ（＃ｉ）３ｉが備えている。

ノード（＃ｊ）２ｉｊは、障害監視手段２００１と、ログ送信手段２００２と、ログ送信失敗検出手段２００３と、ログ転送実施判断手段２００４と、ログ転送パス設定／解放手段２００５と、ログ転送手段２００６と、転送ログ受信手段２００７と、転送ログ送信結果通知手段２００８と、転送ログ送信結果確認手段２００９とを備えている。

障害監視手段２００１は、自ノード（＃ｊ）２ｉｊを監視し、障害の発生を検出し、ログを生成する。以下の説明では、この障害監視手段２００１によって生成されたログを、便宜的にログ２ｃ４と呼ぶ。

ログ送信手段２００２は、自ノード（＃ｊ）２ｉｊの障害監視手段２００１が生成したログ２ｃ４、又は他ノード（＃ｊ）２ｉｊから転送されてきたログ２ｃ４を、自クラスタ（＃ｉ）２ｉのクラスタＳＶＰ（＃ｉ）３ｉに送信する。

ログ送信失敗検出手段２００３は、ＬＡＮ（＃ｉ）４ｉ、クラスタＳＶＰ（＃ｉ）３ｉ、ＬＡＮ６０を介した、統合ＳＶＰ７０へのログ２ｃ４の送信の失敗を検出する。そして、ログ送信失敗検出手段２００３は、ログ２ｃ４の送信の失敗を検出した場合は、図５に示す送信結果９００をログ転送実施判断手段２００４、および、ログ転送パス設定／解放手段２００５に渡す。

ログ転送実施判断手段２００４は、ログ２ｃ４の重要度や優先度などを考慮してＩＸＳ１０を介したログ転送を行うか否かを判断する。ログ転送実施判断手段２００４は、例えば、図１１に示すログ転送ＳＧ９１０に基づいて、各ログ２ｃ４の重要度に応じて転送を実施するか否かを判断する。図１１に示すログ転送ＳＧ９１０は、障害識別番号９１２と重要度９１３を関連付けたログ−重要度テーブル９１１と、重要度９１５とログ転送設定９１６を関連付けた重要度−ログ転送設定テーブル９１４を有している。ログ転送実施判断手段２００４は、ログ−重要度テーブル９１１と、重要度−ログ転送設定テーブル９１４とを参照することで、ログ２ｃ４を転送するか否かを判断する。そして、ログ転送実施判断手段２００４は、ログ２ｃ４を転送すると判断した場合は、ログ転送パス設定／解放手段２００５に、後述する「ログ転送パス」の設定を要求する。なお、図１１のログ転送ＳＧ９１０のテーブル例は一例であり、実施の形態は図１１で示されたテーブルの構造や内容に限定されるものではない。

ログ転送パス設定／解放手段２００５は、ログ転送先のクラスタ（＃ｉ）２ｉ及びノード（＃ｊ）２ｉｊを決定する。そして、ログ転送パス設定／解放手段２００５は、ログ転送パスとして、ＩＸＳ１０を経由してログ２ｃ４を転送するノード間通信のパスを設定する。このログ転送パスの設定はＩＸＳ１０が備えているログ転送パス確保手段１００１が、データ転送パス５０をルーティングするルート手段１００２を制御することにより実現される。そして、ログ転送パス設定／解放手段２００５は、例えば、転送元のクラスタ（＃０）２０のノード（＃０）２００から、転送先のクラスタ（＃１）２１のノード（＃０）２１０の間にログ転送パスを設定・確保する。以後、「ログ転送パス」と表記した場合は、特に断りがない限り、ここで説明したログ転送パスを示す。

また、ログ転送パス設定／解放手段２００５は、転送ログ送信結果確認手段２００９から図５に示す送信結果９００を通知されると、ＩＸＳ１０に設定したログ転送パスを解放する。また、ログ転送パス設定／解放手段２００５は、転送ログ送信結果確認手段２００９から、送信が失敗した旨の送信結果９００を受けると、別のログ転送パスを設定する。

なお、ログ転送パス設定／解放手段２００５による転送先のクラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊの決定は特定のアルゴリズムに依存する必要はない。転送先のクラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊの決定は、障害のあったクラスタ（＃ｉ）２ｉ以外の最若番クラスタ（＃ｉ）２ｉの最若番ノード（＃ｊ）２ｉｊとする方法を用いても良い。また、転送先のクラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊの決定は、ＩＸＳ１０から情報を取得して一番使用率の低いクラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊとする方法を用いても良い。

また、ログ転送パス設定／解放手段２００５は、転送ログ送信結果確認手段２００９から通知される図５に示す送信結果９００を参照して、転送先のクラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊを決定するアルゴリズムを用いても良い。例えば、送信結果９００の結果９０１が『１』で『失敗』を示しており、失敗コード９０２が『ＣＳＶＰＡＢＮＴ』で『クラスタＳＶＰ（＃ｉ）３ｉから、異常終了報告があった。』ことを示しているとする。この場合は、同一クラスタ（＃ｉ）２ｉ内のノード（＃ｊ）２ｉｊは、同一クラスタＳＶＰ（＃ｉ）３ｉを使用しているため転送先として選択しない。そして、転送先は、他のクラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊを選択する。また、例えば、送信結果９００の結果９０１が『１』で『失敗』を示しており、失敗コード９０２が『ＬＡＮｉＩＮＶ』で『ノード（＃ｊ）２ｉｊから、ＬＡＮ（＃ｉ）４ｉアクセス失敗報告があった。』ことを示しているとする。この場合は、ノード（＃ｊ）２ｉｊのＬＡＮ接続回路が故障している可能性があるため、転送先として、同一クラスタ（＃ｉ）２ｉ内の、他ノード（＃ｊ）２ｉｊを選択する。なお、図５の送信結果９００は一例であり、実施の形態は図５で示された形式や内容に限定されるものではない。

ログ転送手段２００６は、ログ２ｃ４にログ送信結果９００の失敗コード９０２を付加して、新たなログ２ｃ４とする。そして、ログ転送手段２００６は、ＩＸＳ１０に設定されたログ転送パスを使用して、他ノード（＃ｊ）２ｉｊにノード間通信を行い、ログ２ｃ４を転送する。そして、ログ転送手段２００６は、転送が成功したか否かを転送ログ送信結果確認手段２００９に報告する。転送ログ受信手段２００７は、ログ転送手段２００６により転送されてきた他ノード（＃ｊ）２ｉｊのログ２ｃ４を受信する。転送ログ送信結果通知手段２００８は、他ノード（＃ｊ）２ｉｊのログ２ｃ４の送信結果９００を、他ノード（＃ｊ）２ｉｊの転送ログ送信結果確認手段２００９へ通知する。転送ログ送信結果確認手段２００９は、ログ転送手段２００６の報告、および、転送ログ送信結果通知手段２００８の通知に基づいて、送信結果９００を、ログ転送パス設定／解放手段２００５に通知する。

ＩＸＳ１０は、ログ転送パス確保手段１００１を備えている。ログ転送パス確保手段１００１は、ノード（＃ｊ）２ｉｊのログ転送パス設定／解放手段２００５と連携して、ログ転送パスを設定し、確保する。

なお、クロスバスイッチであるＩＸＳ１０のルーティング動作は、当業者にとって周知の技術であり、具体的な説明は省略する。本件に関する公知文献としては、特開２０００−２４４５７３号公報、特開平０９−００６７３７号公報、特開平０８−０８８８７２号公報当を参照することができる。

クラスタＳＶＰ（＃ｉ）３ｉは、ログ登録要求手段３００１を備えている。ログ登録要求手段３００１は、ノード（＃ｊ）２ｉｊから送信されてきたログ２ｃ４を受け取り、統合ＳＶＰ７０にこのログ２ｃ４の登録を要求する。

統合ＳＶＰ７０はログ２ｃ４を蓄積するデータベースであるログデータ蓄積部７００２を備えている。ログ登録手段７００１は、ログ登録要求手段３００１から、ログ登録要求を受けると、対象のログ２ｃ４をログデータ蓄積部７００２に登録する。

図６〜図９は、本発明の第２の実施例の動作を示すシーケンス図である。図１０は、本発明の第２の実施例のログ転送処理を示す概念図である。ここでは、具体的な状況として、クラスタＳＶＰ（＃０）３０と、ノード（＃０）２１０の故障時にクラスタ（＃０）２０のノード（＃０）２００で、図１１のログ転送ＳＧ９１０に示す『障害Ｂ』が発生したと想定する。そして、この『障害Ｂ』に起因して生成されたログ２ｃ４を統合ＳＶＰ７０に登録する動作を、例として説明する。

図６〜図９の「丸で囲んだ１」〜「丸で囲んだ１０」と、図１０の「丸で囲んだ１」〜「丸で囲んだ１０」は対応している。「丸で囲んだ１」、「丸で囲んだ２」は、最初（正常時）のログ登録ルートを示している。クラスタＳＶＰ（＃０）３０が故障していなければ、この「丸で囲んだ１」、「丸で囲んだ２」のルートでログ２ｃ４が登録される。「丸で囲んだ３」、「丸で囲んだ４」、「丸で囲んだ５」、「丸で囲んだ６」は二番目のログ登録ルートを示している。クラスタＳＶＰ（＃０）３０が故障しており、ノード（＃０）２１０が故障していなければ、この「丸で囲んだ３」、「丸で囲んだ４」、「丸で囲んだ５」、「丸で囲んだ６」のルートでログ２ｃ４が登録される。「丸で囲んだ７」、「丸で囲んだ８」、「丸で囲んだ９」、「丸で囲んだ１０」は、三番目のログ登録ルートを示している。クラスタＳＶＰ（＃０）３０が故障しており、かつ、ノード（＃０）２１０が故障していれば、この「丸で囲んだ７」、「丸で囲んだ８」、「丸で囲んだ９」、「丸で囲んだ１０」のルートでログ２ｃ４が登録される。

クラスタ（＃０）２０のノード（＃０）２００で装置障害が発生すると、ノード（＃０）２００の障害監視手段２００１が、この装置障害を検出する。そして、ノード（＃０）２００の障害監視手段２００１は、ログ２ｃ４を生成する（Ｓ１１０）。

次にノード（＃０）２００のログ送信手段２００２は、クラスタＳＶＰ（＃０）３０にログ２ｃ４を送信する（Ｓ１１１）。

クラスタＳＶＰ（＃０）３０が正常に動作している場合は、クラスタＳＶＰ（＃０）３０のログ登録要求手段３００１は、ＬＡＮ（＃０）４０からログ２ｃ４を受信する。そして、クラスタＳＶＰ（＃０）３０のログ登録要求手段３００１は、ＬＡＮ６０を介して、統合ＳＶＰ７０へログ２ｃ４を送信する（Ｓ１１２）。統合ＳＶＰ７０のログ登録手段７００１は、ログ２ｃ４を受信し、これをログデータ蓄積部７００２に登録する（Ｓ１１３）。

クラスタＳＶＰ（＃０）３０が故障している場合は、クラスタＳＶＰ（＃０）３０のログ登録要求手段３００１がログ２ｃ４を受信できない、あるいは、ログ２ｃ４を送信できない。これをノード（＃０）２００のログ送信失敗検出手段２００３がログ送信失敗として検出する。そして、ノード（＃０）２００のログ送信失敗検出手段２００３は、結果９０１が『１』、失敗コード９０２が『ＣＳＶＰＡＢＮＴ』の送信結果９００を通知する。（Ｓ１１４）。

ログ送信失敗が通知されると、ノード（＃０）２００のログ転送実施判断手段２００４は、図１１に示すログ転送ＳＧ９１０を参照して、送信失敗のログ２ｃ４についてログ転送を行うか否かを判断する。そして、ノード（＃０）２００のログ転送実施判断手段２００４は、ログ２ｃ４を転送すると判断した場合は、ノード（＃０）２００のログ転送パス設定／解放手段２００５にログ転送パスの設定を要求する（Ｓ１１５）。ここでは、『障害Ｂ』が発生したと想定しているため、ログ２ｃ４を転送すると判断することになる。

ノード（＃０）２００のログ転送パス設定／解放手段２００５は、転送先のクラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊを決定する。ここでは、送信結果９００の失敗コード９０２が『ＣＳＶＰＡＢＮＴ』であると通知されているそこで、ログ転送パス設定／解放手段２００５は、他クラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊである、クラスタ（＃１）２１のノード（＃０）２１０を選択したものとする。そして、ログ転送パス設定／解放手段２００５は、ＩＸＳ１０と連携して、ログ転送パスを設定する（Ｓ１１６、Ｓ１１７）。

ノード（＃０）２００のログ転送手段２００６は、ログ送信失敗検出手段２００３から通知されたログ送信結果９００の失敗コード９０２を、ログ２ｃ４に付加して、新たなログ２ｃ４とする。そして、ログ転送手段２００６は、ログ２ｃ４をデータ転送パス５０に送出する（Ｓ１１８）。ＩＸＳ１０のルート手段１００２は、ノード（＃０）２００に接続したデータ転送パス５０から送られてきたログ２ｃ４を受け取る。そして、ＩＸＳ１０のルート手段１００２は、ノード（＃０）２１０に接続したデータ転送パス５０にログ２ｃ４を送出する（Ｓ１１９）。

ノード（＃０）２１０の転送ログ受信手段２００７は、データ転送パス５０から、ログ２ｃ４を受け取る（Ｓ１２０）。そして、ノード（＃０）２１０のログ送信手段２００２は、クラスタＳＶＰ（＃０）３０にログ２ｃ４を送信する（Ｓ１２１）。

ノード（＃０）２１０、ＬＡＮ（＃１）４１クラスタＳＶＰ（＃１）３１、ＬＡＮ
６０、統合ＳＶＰ７０が正常な場合は、ログ２ｃ４はクラスタＳＶＰ（＃１）３１を経由し（Ｓ１２２）、統合ＳＶＰ７０に登録される（Ｓ１２３）。

ノード（＃０）２１０のＬＡＮ（＃１）４１のインタフェース回路が故障している場合は、ノード（＃０）２１０はＬＡＮ（＃１）４１をアクセスできない。これをノード（＃０）２１０のログ送信失敗検出手段２００３がログ送信失敗として検出する。そして、ログ送信失敗検出手段２００３が、結果９０１が『１』、失敗コード９０２が『ＬＡＮｉＩＮＶ』の送信結果９００を、転送ログ送信結果通知手段２００８に通知する（Ｓ１２４）。

ノード（＃０）２１０の転送ログ送信結果通知手段２００８は、送信結果９００を、ノード（＃０）２００の転送ログ送信結果確認手段２００９に通知する（Ｓ１２５）。

ノード（＃０）２００の転送ログ送信結果確認手段２００９は、送信結果９００を受信し、ノード（＃０）２００のログ転送パス設定／解放手段２００５に通知する（Ｓ１２６）。

ノード（＃０）２００のログ転送パス設定／解放手段２００５は、ノード（＃０）２００の転送ログ送信結果確認手段２００９から、送信結果９００を通知されると、転送先のクラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊを決定する。ここでは、送信結果９００の失敗コード９０２が『ＬＡＮｉＩＮＶ』であると通知されているそこで、ログ転送パス設定／解放手段２００５は、同一クラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊである、クラスタ（＃１）２１のノード（＃ｎ）２１ｎを選択したものとする。そして、ログ転送パス設定／解放手段２００５は、ＩＸＳ１０と連携して、すでに設定されていたログ転送パスを解放し、再度、新たにログ転送パスを設定する（Ｓ１２７、Ｓ１２８）。

ノード（＃０）２００のログ転送手段２００６は、転送ログ送信結果確認手段２００９から通知されたログ送信結果９００の失敗コード９０２を、ログ２ｃ４に付加して、新たなログ２ｃ４とする。そして、ログ転送手段２００６は、ログ２ｃ４をデータ転送パス５０に送出する（Ｓ１２９）。ＩＸＳ１０のルート手段１００２は、ノード（＃０）２００に接続したデータ転送パス５０から送られてきたログ２ｃ４を受け取る。そして、ＩＸＳ１０のルート手段１００２は、ノード（＃０）２１０に接続したデータ転送パス５０にログ２ｃ４を送出する（Ｓ１３０）。

ノード（＃０）２１０の転送ログ受信手段２００７は、データ転送パス５０から、ログ２ｃ４を受け取る（Ｓ１３１）。そして、ノード（＃０）２１０のログ送信手段２００２は、クラスタＳＶＰ（＃１）３１にログ２ｃ４を送信する（Ｓ１３２）。

そして、ログ２ｃ４は、クラスタＳＶＰ（＃１）３１を経由し（Ｓ１３３）、統合ＳＶＰ７０に登録される（Ｓ１３４）。そして、ノード（＃０）２１０のログ送信失敗検出手段２００３は、ログの転送が成功したことを検出し（Ｓ１３５）、結果９０１が『０』の送信結果９００を、送出する（Ｓ１３５）。送信結果９００は、ノード（＃０）２１０の転送ログ送信結果通知手段２００８を経由し（Ｓ１３６）、ノード（＃０）２００の転送ログ送信結果確認手段２００９に通知される（Ｓ１３７）。

ログ転送パス設定／解放手段２００５と、ログ転送パス確保手段１００１ とは連携して、 ログ転送パスを解放する（Ｓ１３８、Ｓ１３９）。

本発明の第２の実施例によれば、ノード（＃ｊ）２ｉｊから統合ＳＶＰ７０へのログの送信が、クラスタＳＶＰ（＃ｉ）３ｉ、ＬＡＮ（＃ｉ）４ｉ、あるいは、ＬＡＮ６０の障害により失敗した場合でも、ログ消失を防止することが可能となる。その理由は、クラスタＳＶＰ（＃ｉ）３ｉの故障時にクラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊで発生した装置障害のログ２ｃ４を、ＩＸＳ１０を介して他クラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊへ転送し、統合ＳＶＰ７０にログ２ｃ４を登録することができるようにしたためである。

さらに、本発明の第二の実施例に拠れば、ノード（＃ｊ）２ｉｊから統合ＳＶＰ７０へのログの送信が、ノード（＃ｊ）２ｉｊのＬＡＮ（＃ｉ）４ｉへのインタフェース回路の障害により失敗した場合は、同一クラスタ（＃ｉ）２ｉ内の他ノード（＃ｊ）２ｉｊへログ２ｃ４を転送することが可能となる。その理由は、送信結果９００に基づいて、ログ転送パスを設定できるようにしたためである。

次に本発明の第３の実施例について図面を参照して詳細に説明する。なお、第３の実施例の説明においては、第２の実施例と同一であり、すでに説明済みの部分は、冗長となるため、説明の流れが不明確にならない範囲で省略する。

図１２を参照すると、本発明の第３の実施例は、クラスタ（＃０）２０と、クラスタ（＃１）２１と、ＩＸＳ１０と、統合ＳＶＰ７０とから構成されるマルチクラスタコンピュータシステムである。

各クラスタは１６台のノード（＃ｊ）２ｉｊと、各ノード（＃ｊ）２ｉｊを管理・制御するクラスタＳＶＰ（＃ｉ）３ｉとで構成されている。すなわち、クラスタ（＃０）２０はノード（＃０）２００〜ノード（＃Ｆ）２０ＦとクラスタＳＶＰ（＃０）３０から構成されている。各ノード（＃ｊ）２ｉｊとクラスタＳＶＰ（＃０）３０はＬＡＮ（＃０）４０により接続されている。また、クラスタ（＃１）２１はノード（＃０）２１０〜ノード（＃Ｆ）２１ＦとクラスタＳＶＰ（＃１）３１から構成されている。各ノード（＃ｊ）２ｉｊとクラスタＳＶＰ（＃１）３１はＬＡＮ（＃１）４１により接続されている。クラスタＳＶＰ（＃０）３０及びクラスタＳＶＰ（＃１）３１は共にＬＡＮ６０によって、それぞれを一元的に管理・制御する統合ＳＶＰ７０に接続されている。

各ノード（＃ｊ）２ｉｊは、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、ユーザジョブ、あるいは、アプリケーションを実行する演算装置であるＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、ＩＸＳ１０との接続ポートを有するＲＣＵ（Ｒｅｍｏｔｅ ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）と、システム内の各装置の初期化や故障発生時の障害処理などの制御を行うＤＧＰ（診断プロセッサ：Ｄｉａｇｎｏｓｔｉｃ Ｐｒｏｃｅｓｓｅｒ）とから構成されている。ＣＰＵ（＃ｋ）４ｉｊｋは、各ノード（＃ｊ）２ｉｊに１６台ずつ（ＣＰＵ（＃０）４ｉｊ０〜ＣＰＵ（＃Ｆ）４ｉｊＦ）存在する。ＲＣＵ（＃ｋ）６ｉｊｋは、各ノード（＃ｊ）２ｉｊに１６台ずつ（ＲＣＵ（＃０）６ｉｊ０〜ＲＣＵ（＃Ｆ）６ｉｊＦ）存在する。ここで、ｉはクラスタ番号（０、１）、ｊはノード番号（０〜Ｆ）である。

ＤＧＰ（＃ｊ）５ｉｊは各ノード（＃ｊ）２ｉｊに１台ずつ存在し、内部バス６ｉｊによりＣＰＵ（＃ｋ）４ｉｊｋ及びＲＣＵ（＃ｋ）６ｉｊｋと接続され、各装置の初期化や診断を行うことができる。また、各ＤＧＰ（＃ｊ）５ｉｊはクラスタ（＃ｉ）２ｉ毎にクラスタＳＶＰ（＃０）３０、クラスタＳＶＰ（＃１）３１にＬＡＮ（＃０）４０、ＬＡＮ（＃１）４１で接続され、互いに通信が可能である。統合ＳＶＰ７０からの各ノード（＃ｊ）２ｉｊの制御は、クラスタＳＶＰ（＃０）３０、クラスタＳＶＰ（＃１）３１を介して各クラスタ（＃ｉ）２ｉ内の各ノード（＃ｊ）２ｉｊのＤＧＰ（＃ｊ）５ｉｊと通信することで可能となっている。

ＩＸＳ１０は、ルーター（以降、ＲＴＲと記載する）と呼ばれる複数の通信ポートを持つ装置で構成されている。図１２のＩＸＳ１０は１６台のＲＴＲ（＃０ｋ）１０ｋ（ＲＴＲ（＃００）１００〜ＲＴＲ（＃０Ｆ）１０Ｆ）から構成されている。ＲＴＲ（＃０ｋ）１０ｋの各ポートは、各ノード（＃ｊ）２ｉｊ内のＲＴＲ番号「ｋ」と同一の番号を持つＲＣＵ（＃ｋ）６ｉｊｋと接続されている。各ノード（＃ｊ）２ｉｊは、ＲＣＵ（＃ｋ）６ｉｊｋを介してＲＣＵ番号と同一の番号を持ったＲＴＲ（＃０ｋ）１０ｋに接続され、ノード間通信を行う。

図１３に第３の実施例の各構成品であるＩＸＳ１０、ノード（＃ｊ）２ｉｊ、クラスタＳＶＰ（＃ｉ）３ｉ、統合ＳＶＰ７０の機能ブロック図を示す。図１３ではノード（＃ｊ）２ｉｊ内のＣＰＵ（＃ｋ）４ｉｊｋ、ノード（＃ｊ）２ｉｊ内のＲＣＵ（＃ｋ）６ｉｊｋ、ＩＸＳ１０内のＲＴＲ（＃０ｋ）１０ｋ、クラスタＳＶＰ（＃ｉ）３ｉは代表して１台のみを記載している。すなわち、ノード（＃ｊ）２ｉｊ内のＣＰＵ（＃ｋ）４ｉｊｋ、ノード（＃ｊ）２ｉｊ内のＲＣＵ（＃ｋ）６ｉｊｋ、ＩＸＳ１０内のＲＴＲ（＃０ｋ）１０ｋ、クラスタＳＶＰ（＃ｉ）３ｉは実際には図１２のように複数台存在している。図１３のノード（＃ｊ）２ｉｊに記載した各手段は、図１２の全てのノード（＃ｊ）２ｉｊが備えている。図１３のクラスタＳＶＰ（＃ｉ）３ｉに記載した各手段は、図１２の全てのクラスタＳＶＰ（＃ｉ）３ｉが備えている。

ＤＧＰ（＃ｊ）５ｉｊは、障害監視手段２００１と、ログ送信手段２００２と、ログ送信失敗検出手段２００３と、ＳＧ確認手段５００４と、ログ転送パス決定手段５００５と、ログ転送手段２００６と、転送ログ受信手段２００７と、転送ログ送信結果通知手段２００８と、転送ログ送信結果確認手段２００９と、ＲＴＲ状態制御手段５０１０と、ログ転送ＳＧ記憶部５０１１とを備えている。ここで、障害監視手段２００１と、ログ送信手段２００２と、ログ送信失敗検出手段２００３と、ログ転送手段２００６と、転送ログ受信手段２００７と、転送ログ送信結果通知手段２００８と、転送ログ送信結果確認手段２００９とは、本発明の第２の実施例で説明したものと同じである。

ＳＧ確認手段５００４とログ転送ＳＧ記憶部５０１１は、図４のログ転送実施判断手段２００４に対応するものである。ログ転送ＳＧ記憶部５０１１は、図１１のログ転送ＳＧ９１０を格納している。

ログ転送パス決定手段５００５とＲＴＲ状態制御手段５０１０は、図４のログ転送パス設定／解放手段２００５に対応するものである。ログ転送パス決定手段５００５は、転送に使用する転送元のノード（＃ｊ）２ｉｊのＲＣＵ（＃ｋ）６ｉｊｋ、転送先のクラスタ（＃ｉ）２ｉ、ノード（＃ｊ）２ｉｊを決定し、ログ転送パスを決定する。また、ＲＴＲ状態制御手段５０１０は、ＤＧＰ（＃ｊ）５ｉｊからＲＣＵ（＃ｋ）６ｉｊｋを経由してＩＸＳ１０内のＲＴＲ（＃０ｋ）１０ｋの状態を制御する。ＲＴＲ状態制御手段５０１０は、ＩＸＳ１０を用いたログ転送パスを確保することの悪影響でＯＳ、ユーザジョブ、あるいは、アプリケーションの運用を妨げることがないように、ＲＴＲ（＃０ｋ）１０ｋの状態を制御する。なお、ＲＴＲ（＃０ｋ）１０ｋの状態については後述する。

ＲＣＵ（＃ｋ）６ｉｊｋはＲＴＲ状態受信手段６００１、ポート制御手段６００２、入出力ポート６００３を備えている。入出力ポート６００３はＲＣＵ（＃ｋ）６ｉｊｋと同一番号「ｋ」のＣＰＵ（＃ｋ）４ｉｊｋ、同一ノード（＃ｊ）２ｉｊ内のＤＧＰ（＃ｊ）５ｉｊ及びＩＸＳ１０内のＲＴＲ（＃０ｋ）１０ｋと接続されている。ＣＰＵ（＃ｋ）４ｉｊｋ及びＤＧＰ（＃ｊ）５ｉｊは入出力ポート６００３を通じて、ＩＸＳ１０のＲＴＲ（＃０ｋ）１０ｋを介して、他ノード（＃ｊ）２ｉｊのＣＰＵ（＃ｋ）４ｉｊｋ又はＤＧＰ（＃ｊ）５ｉｊと相互に通信を行う。ＲＴＲ状態受信手段６００１はＲＣＵ（＃ｋ）６ｉｊｋの入出力ポート６００３に接続されたＲＴＲ（＃０ｋ）１０ｋの状態を受信する。ＲＣＵ（＃ｋ）６ｉｊｋは取得したＲＴＲ（＃０ｋ）１０ｋの状態に応じて入出力ポート６００３をポート制御手段６００２により図１４のように制御する（詳細は後述）。

ＩＸＳ１０を構成する各ＲＴＲ（＃０ｋ）１０ｋは状態制御手段１１０１、状態通知手段１１０２を備えている。本実施例ではＲＴＲ（＃０ｋ）１０ｋの状態には、ＣＰＵ（＃ｋ）４ｉｊｋから使用可能なＲｅａｄｙの状態と、ＣＰＵ（＃ｋ）４ｉｊｋから使用不可であるＢｕｓｙの状態がある。以後の説明において、「Ｒｅａｄｙ［状態］、および、「Ｂｕｓｙ［状態］」は、特に断らない限り、ここで説明した「Ｒｅａｄｙ［状態］、および、「Ｂｕｓｙ［状態］」の意味で用いる。状態制御手段１１０１は、この状態の管理・制御をする。

図１３のＲＴＲ（＃０ｋ）１０ｋの状態制御手段１１０１、状態通知手段１１０２、ＲＣＵ（＃ｋ）６ｉｊｋのＲＴＲ状態受信手段６００１、ポート制御手段６００２、入出力ポート６００３は図４のログ転送パス確保手段１００１に対応するものである。

図１４にＲＴＲ（＃０ｋ）１０ｋ状態とＣＰＵ（＃ｋ）４ｉｊｋ−ＲＴＲ（＃０ｋ）１０ｋ間、ＤＧＰ（＃ｊ）５ｉｊ−ＲＴＲ（＃０ｋ）１０ｋ間のデータ通信の関係を示す。Ｒｅａｄｙの状態は、ＲＴＲ（＃０ｋ）１０ｋが接続されている各ノード（＃ｊ）２ｉｊのＣＰＵ（＃ｋ）４ｉｊｋからのデータ入出力が可能な状態である。ＣＰＵ（＃ｋ）４ｉｊｋは、ＲＴＲ（＃０ｋ）１０ｋがＲｅａｄｙ状態の場合にＯＳ、ユーザジョブ、あるいは、アプリケーションによるノード（＃ｊ）２ｉｊ間通信を実行することができる。Ｒｅａｄｙ状態でのＲＴＲ（＃０ｋ）１０ｋは、ＣＰＵ（＃ｋ）４ｉｊｋに使用されるため、ＤＧＰ（＃ｊ）５ｉｊは使用できない。すなわち、ＤＧＰ（＃ｊ）５ｉｊは、Ｒｅａｄｙ状態でのＲＴＲ（＃０ｋ）１０ｋを、ＩＸＳ１０を介した他ノード（＃ｊ）２ｉｊのＤＧＰ（＃ｊ）５ｉｊとの通信に使用できない。また、ＲＴＲ（＃０ｋ）１０ｋが、Ｂｕｓｙの状態はＲｅａｄｙの状態とは逆に、ＣＰＵ（＃ｋ）４ｉｊｋからのデータ入出力が不可能な状態である。Ｂｕｓｙ状態でのＲＴＲ（＃０ｋ）１０ｋは、ＣＰＵ（＃ｋ）４ｉｊｋから使用されない。従って、ＤＧＰ（＃ｊ）５ｉｊは、Ｂｕｓｙ状態でのＲＴＲ（＃０ｋ）１０ｋを、他ノード（＃ｊ）２ｉｊのＤＧＰ（＃ｊ）５ｉｊとＩＸＳ１０を介した通信に使用できる。状態通知手段１１０２は定期的、および、状態の変化があった際に、ＲＴＲ（＃０ｋ）１０ｋの状態を接続されているノード（＃ｊ）２ｉｊのＲＣＵ（＃ｋ）６ｉｊｋに通知する。ＲＴＲ状態受信手段６００１は、状態通知手段１１０２からＲＴＲ（＃０ｋ）１０ｋ通知を受ける。そして、ポート制御手段６００２は、ＲＴＲ（＃０ｋ）１０ｋ状態に合わせて入出力ポート６００３を制御する。こうして、ＤＧＰ（＃ｊ）５ｉｊ、ＣＰＵ（＃ｋ）４ｉｊｋからのＲＴＲ（＃０ｋ）１０ｋへのアクセス可否が、図１４に示すように制御される。

本実施例ではログ転送を行う際にＲＴＲ（＃０ｋ）１０ｋの状態をＲｅａｄｙからＢｕｓｙ状態に一時的に設定し、ログ転送完了後にＲｅａｄｙ状態に復元させることで、ＣＰＵ（＃ｋ）４ｉｊｋで実行中のＯＳ、ユーザジョブ、あるいは、アプリケーションがアボートしないようにしている。それは、Ｂｕｓｙ状態に設定することで、ログ転送中のＣＰＵ（＃ｋ）４ｉｊｋによるノード間通信は不可になるが、その際、ＯＳ、ユーザジョブ、あるいは、アプリケーションからはＩＸＳ１０がＢｕｓｙ状態に認識されるため、リトライや待ち合わせが行われ、ログ転送が完了しＲｅａｄｙ状態に復元後にアクセスが成功するためである。

ここで、ログ転送はＯＳ、ユーザジョブ、あるいは、アプリケーションがログ転送中のリトライアウトなどにより、アボートが発生しない、十分短い時間で完了することを保障するものとする。または、ＣＰＵ（＃ｋ）４ｉｊｋによるＯＳ、ユーザジョブ、あるいは、アプリケーションのノード間通信は、ログ転送に要する十分な時間をリトライや待ち合わせるものとする。

図１５〜図１６は、本発明の第３の実施例の動作を示すフローチャート図である。図２１は、本発明の第３の実施例のログ転送処理を示す概念図である。

ここでは、具体的な状況として、クラスタＳＶＰ（＃０）３０の故障時にクラスタ（＃０）２０のノード（＃０）２００において、装置障害が発生したとする。そして、クラスタ（＃０）２０のノード（＃０）２００のＤＧＰ（＃０）５００から、ノード（＃０）２００のＲＣＵ（＃０）６０００、ＩＸＳ１０のＲＴＲ（＃００）１００、クラスタ（＃１）２１のノード（＃０）２１０のＲＣＵ（＃０）６１００、クラスタ（＃１）２１のノード（＃０）２１０のＤＧＰ（＃０）５１０、クラスタＳＶＰ（＃１）３１を経由して、ログ２ｃ４を統合ＳＶＰ７０に登録する動作を例として説明する。

最初の状態は、ＩＸＳ１０を構成しているＲＴＲ（＃００）１００〜ＲＴＲ（＃０Ｆ）１０Ｆの状態は、Ｒｅａｄｙ状態であるとする。すなわち、各ノード（＃ｊ）２ｉｊのＣＰＵ（＃ｋ）４ｉｊｋは、ＩＸＳ１０を介したノード間通信を使用するＯＳ、ユーザジョブ、あるいは、アプリケーションを実行中であるとする。

この状態から、クラスタ（＃０）２０のノード（＃０）２００で装置障害が発生すると（Ｓ２１０）、クラスタ（＃０）２００のノード（＃０）２００のＤＧＰ（＃０）５００の障害監視手段２００１が、この装置障害を検出する（Ｓ２１１）。そして、クラスタ（＃０）２００のノード（＃０）２００のＤＧＰ（＃０）５００の障害監視手段２００１が、ログ２ｃ４を生成する。

ログ送信手段２００２は、クラスタＳＶＰ（＃０）３０にログ２ｃ４を送信する（Ｓ２１２）。

クラスタＳＶＰ（＃０）３０が正常である場合は、図２１の「丸で囲んだ１」、「丸で囲んだ２」のパスでクラスタＳＶＰ（＃０）３０を経由して統合ＳＶＰ７０にログ２ｃ４が登録される。ここでは、クラスタＳＶＰ（＃０）３０が故障していると想定しており、ＤＧＰ（＃０）５００からクラスタＳＶＰ（＃０）３０へのログ送信は失敗する。

クラスタ（＃０）２００のノード（＃０）２００のＤＧＰ（＃０）５００のログ送信失敗検出手段２００３は、ログ送信の失敗を検出する（Ｓ２１３）。

ログ送信失敗を検出したＤＧＰ（＃０）５００は自身が持つログ転送ＳＧ９１０をＳＧ確認手段５００４により参照し、発生したログ２ｃ４のＩＸＳ１０を介したログ転送を行うか否かを判断する（Ｓ２１４）。

ここで障害が重要ではなく、ログ転送を行う必要がないと判断した場合（Ｓ２１４でＮｏのケース）は、処理は終了する。

障害が重要であり、ログ転送を行うと判断した場合（Ｓ２１４でＹｅｓのケース）は、ログ転送パス決定手段５００５が、ログ転送を行う経路を決定する（Ｓ２１５）。

以上の動作は、第２の実施例とほぼ同様の動作である。

ここで、ログ転送パス決定手段５００５は、図２１の概念図に示すように、以下のパスを決定する。まず、クラスタ（＃０）２０のノード（＃０）２００のＤＧＰ（＃０）５００からクラスタ（＃０）２０のノード（＃０）２００のＲＣＵ（＃０）６０００へのパスが、図２１の「丸で囲んだ３」である。次に、クラスタ（＃０）２０のノード（＃０）２００のＲＣＵ（＃０）６０００から、ＩＸＳ１０のＲＴＲ（＃００）１００へのパスが、図２１の「丸で囲んだ４」である。次に、ＩＸＳ１０のＲＴＲ（＃００）１００から、クラスタ（＃１）２１ノード（＃０）２１０のＲＣＵ（＃０）６１００へのパスが、図２１の「丸で囲んだ５」である。そして、クラスタ（＃１）２１ノード（＃０）２１０のＲＣＵ（＃０）６１００から、クラスタ（＃１）２１のノード（＃０）２１０のＤＧＰ（＃０）５１０へのパスが、図２１の「丸で囲んだ６」である。

クラスタ（＃０）２００のノード（＃０）２００のＤＧＰ（＃０）５００のＲＴＲ状態制御手段５０１０は、ＲＴＲ（＃００）１００に対して、状態をＲｅａｄｙ→Ｂｕｓｙに変更するように要求する（Ｓ２１６）。

ＩＸＳ１０のＲＴＲ（＃００）１００の状態制御手段１１０１は、ＲＴＲ状態制御手段５０１０からの状態変更の要求を受けると（Ｓ２２０）、ＲＴＲ（＃００）１００の状態をＲｅａｄｙ→Ｂｕｓｙに変更する（Ｓ２２１）。そして、ＲＴＲ（＃００）１００の状態通知手段１１０２は、接続されている全クラスタ（＃ｉ）２ｉの全ノード（＃ｊ）２ｉｊのＲＣＵ（＃０）６ｉｊ０にＲＴＲ（＃００）１００の状態がＲｅａｄｙ→Ｂｕｓｙに変更したことを通知する（Ｓ２２２）。

接続されている全クラスタ（＃ｉ）２ｉの全ノード（＃ｊ）２ｉｊのＲＣＵ（＃０）６ｉｊ０のＲＴＲ状態受信手段６００１は、ＲＴＲ（＃００）１００からの状態通知を受信する（Ｓ２３０）。

ＲＴＲ状態受信手段６００１は、状態変更があったことを検出した場合（Ｓ２３１でＹｅｓのケース）、ポート制御手段６００２が入出力ポート６００３の設定を制御する（Ｓ２３２）。状態変更がない場合（Ｓ２３１でＮｏのケース）は、処理を終了する。

ここではＲｅａｄｙ→Ｂｕｓｙへの変化なので、ポート制御手段６００２は、入出力ポート６００３の設定を、ＣＰＵ（＃ｋ）４ｉｊｋ−ＲＴＲ（＃０ｋ）１０ｋ間のデータ転送は不可、ＤＧＰ（＃ｊ）５ｉｊ−ＲＴＲ（＃０ｋ）１０ｋ間のデータ転送は可能に制御する（Ｓ２３２）。これにより、クラスタ（＃０）２０ノード（＃０）２００のＤＧＰ（＃０）５００は、クラスタ（＃０）２０ノード（＃０）２００のＲＣＵ（＃０）６０００、ＩＸＳ１０のＲＴＲ（＃００）１００、クラスタ（＃１）２１ノード（＃０）２１０のＲＣＵ（＃０）６１００を経由して、クラスタ（＃１）２１ノード（＃０）２１０のＤＧＰ（＃０）５１０との通信が可能となる。

次にクラスタ（＃０）２０のノード（＃０）２００のＤＧＰ（＃０）５００はログ転送手段２００６により、クラスタ（＃１）２１ノード（＃０）２１０のＤＧＰ（＃０）５１０へログ２ｃ４の転送を実施する（Ｓ２１７）。

クラスタ（＃１）２１のノード（＃０）２１０のＤＧＰ（＃０）５１０の転送ログ受信手段２００７は転送されてきたログ２ｃ４を受信する（Ｓ２４０）。

その後、クラスタ（＃１）２１のノード（＃０）２１０のＤＧＰ（＃０）５１０のＲＴＲ状態制御手段５０１０は、ＲＴＲ（＃００）１００に対して、状態をＢｕｓｙ→Ｒｅａｄｙに復元するように要求する（Ｓ２４１）。

ＩＸＳ１０のＲＴＲ（＃００）１００の状態変更の動作は、Ｓ２２０、Ｓ２２１、Ｓ２２２である。また、ＲＴＲ（＃００）１００の状態変更通知に伴う接続されている全クラスタ（＃ｉ）２ｉの全ノード（＃ｊ）２ｉｊのＲＣＵ（＃０）６ｉｊ０の入出力ポート６００３の状態変更の動作は、Ｓ２３０、Ｓ２３１、Ｓ２３２である。従って、詳細な説明は省略するが、ＲＴＲ（＃００）１００の状態はＢｕｓｙ→Ｒｅａｄｙに復元される。そして、ＲＣＵ（＃０）６ｉｊ０の入出力ポート６００３の状態は、ＣＰＵ（＃ｋ）４ｉｊｋ−ＲＴＲ（＃０ｋ）１０ｋ間のデータ転送は可能、ＤＧＰ（＃ｊ）５ｉｊ−ＲＴＲ（＃０ｋ）１０ｋ間のデータ転送は不可に変更される。

クラスタ（＃１）２１のノード（＃０）２１０のＤＧＰ（＃０）５１０のログ送信手段２００２は、クラスタＳＶＰ（＃１）３１にログ２ｃ４を送信する（Ｓ２４２）。

クラスタＳＶＰ（＃１）３１のログ登録要求手段３００１は、ログ２ｃ４を受信する（Ｓ２５０）。そして、ログ登録要求手段３００１は、統合ＳＶＰ７０にログ２ｃ４を送信する（Ｓ２５１）。

統合ＳＶＰ７０のログ登録手段７００１は、クラスタＳＶＰ（＃１）３１からログ２ｃ４を受信する（Ｓ２６０）。そして、ログ登録手段７００１は、ログデータ蓄積部７００２にログ２ｃ４を登録する（Ｓ２６１）。

以上により、クラスタＳＶＰ（＃０）３０の故障時にクラスタ（＃０）２０のノード（＃０）２００で発生した装置障害のログ２ｃ４は、ＩＸＳ１０を介して他クラスタ（＃ｉ）２ｉのノード（＃ｊ）２ｉｊ）クラスタ（＃１）２１のノード（＃０）２１０転送される。そしてそこから、ログ２ｃ４は、クラスタＳＶＰ（＃１）３１へ転送され、最終的に、統合ＳＶＰ７０にログ登録される。

本発明の第３の実施例によれば、第１の実施例、第２の実施例で得られる効果を、ＯＳやユーザのＪＯＢの運用を妨げることなく、得ることが可能になる。

その理由はＩＸＳを介したノード間通信による、ログ転送パスをＯＳの運用を妨げないように設定することを可能にしたためである。

次に本発明の第４の実施例について図面を参照して詳細に説明する。なお、第４の実施例の説明においては、第３の実施例と同一であり、すでに説明済みの部分は、冗長となるため、説明の流れが不明確にならない範囲で省略する。

図２２は本発明の第４の実施例のシステム構成図である。図２２に示すように、本発明の第４の実施例のシステム構成は、図１２に示す第３の実施例のシステム構成と比較して、ＩＸＳ１０内にＲＴＲ（＃１ｋ）１１ｋが追加となっている。なお、図２３のＲＴＲ（＃０ｋ）１０ｋは、図１３のＲＴＲ（＃０ｋ）１０ｋと同一のものであり、説明の便宜上サフィックスの「０」をつけたものである。そして、第４の実施例のシステム構成は、各ノード（＃ｊ）２ｉｊのＲＣＵ（＃ｋ）６ｉｊｋ１台に対して、ＲＴＲ（＃０ｋ）１０ｋと、ＲＴＲ（＃１ｋ）１１ｋとの２台が接続されている点が異なっている。

図２３は本発明の第４の実施例の機能ブロック図である。図２３に示すように、本発明の第４の実施例のＲＣＵ（＃ｋ）６ｉｊｋは、本発明の第３の実施例のＲＣＵ（＃ｋ）６ｉｊｋに比して、入出力ポート（＃２）６００４が追加となっている。なお、図２３の入出力ポート（＃１）６００３は、図１３の入出力ポート６００３と同一のものであり、説明の便宜上サフィックスの「１」をつけたものである。そして、入出力ポート（＃１）６００３、および、入出力ポート（＃２）６００４は、それぞれＲＴＲ（＃０ｋ）１０ｋ、および、ＲＴＲ（＃１ｋ）１１ｋに接続される。

第３の実施例ではＲＴＲ（＃０ｋ）１０ｋの状態は、ＲｅａｄｙとＢｕｓｙであったが、第４の実施例のＲＴＲの状態はＡｃｔｉｖｅとＳｔａｎｄｂｙの状態をとる。Ａｃｔｉｖｅ状態の時にＲＴＲはＣＰＵ（＃ｋ）４ｉｊｋ−ＲＴＲ（＃ｄｋ）１ｄｋ間のデータ転送を行う状態であり、Ｓｔａｎｄｂｙ状態は待機状態で、ＣＰＵ（＃ｋ）４ｉｊｋ−ＲＴＲ（＃ｄｋ）１ｄｋ間のデータ転送を行わない状態である。以後の説明において、「Ａｃｔｉｖｅ［状態］、および、「Ｓｔａｎｄｂａｙ［状態］」は、特に断らない限り、ここで説明した「Ａｃｔｉｖｅ［状態］、および、「Ｓｔａｎｄｂａｙ［状態］」の意味で用いる。

ＲＣＵ（＃ｋ）６ｉｊｋの状態は、２Ｐｏｒｔ Ａｃｔｉｖｅと、１Ｐｏｒｔ Ａｃｔｉｖｅの二つの状態がある。２Ｐｏｒｔ Ａｃｔｉｖｅは、入出力ポート（＃１）６００３、および、入出力ポート（＃２）６００４に接続されたＲＴＲ（＃ｄｋ）１ｄｋが共にＡｃｔｉｖｅ状態であることを示す。また、１Ｐｏｒｔ Ａｃｔｉｖｅは、入出力ポート（＃１）６００３、および、入出力ポート（＃２）６００４に接続されたＲＴＲ（＃ｄｋ）１ｄｋの一方がＡｃｔｉｖｅ状態、もう一方がＳｔａｎｄｂｙ状態であることを示す。

図２４にＲＣＵ（＃ｋ）６ｉｊｋの状態（接続ＲＴＲ（＃ｄｋ）１ｄｋの状態）と、ＣＰＵ（＃ｋ）４ｉｊｋ−ＲＴＲ（＃ｄｋ）１ｄｋ間のデータ転送、及び、ＤＧＰ（＃ｊ）５ｉｊ−ＲＴＲ（＃ｄｋ）１ｄｋ間のデータ転送の関係を示す。図２４のＣＰＵ（＃ｋ）４ｉｊｋ−ＲＴＲ（＃ｄｋ）１ｄｋ間のデータ転送の項に示すとおり、ＣＰＵ（＃ｋ）４ｉｊｋ単位あたりのノード間通信性能は、１Ｐｏｒｔ Ａｃｔｉｖｅ ）Ａｃｔｉｖｅ／Ｓｔａｎｄｂｙの場合に対して、２Ｐｏｒｔ Ａｃｔｉｖｅ）Ａｃｔｉｖｅ／Ａｃｔｉｖｅの場合は２倍である。そして、ＣＰＵ（＃ｋ）４ｉｊｋ単位あたりのノード間通信性能は、ユーザの要求する性能に応じて、１Ｐｏｒｔ Ａｃｔｉｖｅか２Ｐｏｒｔ Ａｃｔｉｖｅかを選択可能である。ＤＧＰ（＃ｊ）５ｉｊ−ＲＴＲ（＃ｄｋ）１ｄｋ間のデータ転送は２Ｐｏｒｔ Ａｃｔｉｖｅの場合は不可であるが、１Ｐｏｒｔ Ａｃｔｉｖｅの場合はＳｔａｎｄｂｙ状態のＲＴＲ（＃ｄｋ）１ｄｋを介することでＤＧＰ（＃ｊ）５ｉｊ−ＲＴＲ（＃ｄｋ）１ｄｋ間でデータ転送を行うことができる。

本実施例では、ＩＸＳ１０を介したログ転送を１Ｐｏｒｔ ＡｃｔｉｖｅのＤＧＰ（＃ｊ）５ｉｊ−ＲＴＲ（＃ｄｋ）１ｄｋ間でデータ転送を使用して行う。そして、本実施例では、２Ｐｏｒｔ Ａｃｔｉｖｅで運用している場合にはログ転送前に２Ｐｏｒｔ Ａｃｔｉｖｅから１Ｐｏｒｔ Ａｃｔｉｖｅに一時的に縮退（本明細書では、機能、性能などが、縮減、あるいは、減退することを意味する。）する。そして、本実施例では、ログ転送が完了した際に２Ｐｏｒｔ Ａｃｔｉｖｅに復元する方式を用いる。本実施例では、ＲＣＵ（＃ｋ）６ｉｊｋの片方の入出力ＰｏｒｔからＳｔａｎｄｂｙ状態のＲＴＲ（＃ｄｋ）１ｄｋを介してＤＧＰ（＃ｊ）５ｉｊ間でログ転送を行う。このため、ＣＰＵ（＃ｋ）４ｉｊｋで使用中のもう片方の入出力ポート（＃１）６００３、あるいは、入出力ポート（＃２）６００４に擾乱を与えることはない。２Ｐｏｒｔ Ａｃｔｉｖｅから１Ｐｏｒｔ Ａｃｔｉｖｅに縮退する場合も、ＯＳ、ユーザジョブ、あるいは、アプリケーションが認識している緒元（ＲＣＵ数）には変化がない。従って、ＯＳ、ユーザジョブ、あるいは、アプリケーションがアボートすることがない。このことから、本方式によりＯＳ、ユーザジョブ、あるいは、アプリケーション運用に影響を与えずにログ転送を行うことができる。

図２５〜図２８は、本発明の第４の実施例の動作を示すフローチャート図である。図２９は、本発明の第４の実施例のログ転送処理を示す概念図である。

ここでは、具体的な状況として、クラスタＳＶＰ（＃０）３０の故障時に、クラスタ（＃０）２０のノード（＃０）２００において、装置障害が発生したとする。そして、クラスタ（＃０）２０のノード（＃０）２００のＤＧＰ（＃０）５００から、ノード（＃０）２００のＲＣＵ（＃０）６０００、ＩＸＳ１０のＲＴＲ（＃１０）１１０、クラスタ（＃１）２１のノード（＃０）２１０のＲＣＵ（＃０）６１００、クラスタ（＃１）２１のノード（＃０）２１０のＤＧＰ（＃０）５１０、クラスタＳＶＰ（＃１）３１を経由して、ログ２ｃ４を統合ＳＶＰ７０に登録する動作を例として説明する。

最初の状態は、全ノード（＃ｊ）２ｉｊの全ＲＣＵ（＃ｋ）６ｉｊｋが２Ｐｏｒｔ Ａｃｔｉｖｅの状態で運用されているものとする。

図２５において、クラスタ（＃０）２０のノード（＃０）２００での装置障害の発生（Ｓ３１０）から、ログ転送パスを決定（Ｓ３１５）までの処理は、第３の実施例の図１５の場合と同一であるため、説明を省略する。

ただし、ここでは、ログ転送パス決定手段５００５は、図２９の概念図に示すように、以下のパスを決定したものとする。まず、クラスタ（＃０）２０のノード（＃０）２００のＤＧＰ（＃０）５００からクラスタ（＃０）２０のノード（＃０）２００のＲＣＵ（＃０）６０００へのパスが、図２９の「丸で囲んだ３」である。次に、クラスタ（＃０）２０のノード（＃０）２００のＲＣＵ（＃０）６０００から、ＩＸＳ１０のＲＴＲ（＃１０）１１０へのパスが、図２９の「丸で囲んだ４」である。次に、ＩＸＳ１０のＲＴＲ（＃１０）１１０から、クラスタ（＃１）２１のノード（＃０）２１０のＲＣＵ（＃０）６１００へのパスが、図２９の「丸で囲んだ５」である。そして、クラスタ（＃１）２１ノード（＃０）２１０のＲＣＵ（＃０）６１００から、クラスタ（＃１）２１のノード（＃０）２１０のＤＧＰ（＃０）５１０へのパスが、図２９の「丸で囲んだ６」である。

次にクラスタ（＃０）２０のノード（＃０）２００のＤＧＰ（＃０）５００はＲＣＵ（＃０）６０００の状態が２Ｐｏｒｔ Ａｃｔｉｖｅか否かを確認する（Ｓ３１６）。１Ｐｏｒｔ Ａｃｔｉｖｅの場合（Ｓ３１６でＮｏのケース）は、ＤＧＰ（＃０）５００はＳｔａｎｄｂｙのＲＴＲ（＃ｄｋ）１ｄｋのパスを使用してクラスタ（＃１）２１ノード（＃０）２１０のＤＧＰ（＃０）５１０へログ転送を実施する（Ｓ３１８）。

クラスタ（＃０）２０のノード（＃０）２００のＤＧＰ（＃０）５００はＲＣＵ（＃０）６０００の状態が、２Ｐｏｒｔ Ａｃｔｉｖｅで運用されている場合（Ｓ３１６でＹｅｓのケース）を以下に説明する。クラスタ（＃０）２０のノード（＃０）２００のＤＧＰ（＃０）５００の状態制御手段１１０１は、ＲＴＲ（＃１０）１１０に対して、Ａｃｔｉｖｅ→Ｓｔａｎｄｂｙに状態を変更するように要求する（Ｓ３１７）。

ＩＸＳ１０のＲＴＲ（＃１０）１１０の状態制御手段１１０１は、状態制御手段１１０１から状態変更要求を受けると（Ｓ３２０、ＡｃｔｉｖｅからＳｔａｎｄｂｙに状態を変更する（Ｓ３２１）。ＲＴＲ（＃１０）１１０の状態通知手段１１０２は、状態変更後、接続されている全ＲＣＵ（＃０）６ｉｊ０に変更された状態を通知する（Ｓ３２２）。

接続されている全クラスタ（＃ｉ）２ｉの全ノード（＃ｊ）２ｉｊの全ＲＣＵ（＃０）６ｉｊ０のＲＴＲ状態受信手段６００１は、ＲＴＲ（＃００）１００からの状態通知を受信する（Ｓ３３０）。

ＲＴＲ状態受信手段６００１は、状態変更があったことを検出した場合（Ｓ３３１でＹｅｓのケース）、ポート制御手段６００２が入出力ポート（＃１）６００３、入出力ポート（＃２）６００４を、検出した状態変更に対応して設定する（Ｓ３３２）。状態変更がないことを検出した場合（Ｓ３３１でＮｏのケース）は、処理を終了する。

ここではＲＴＲ（＃１０）１１０のＡｃｔｉｖｅ→Ｓｔａｎｄｂｙへの変化なので、ポート制御手段６００２は、入出力ポート（＃２）６００４の設定を、ＣＰＵ（＃ｋ）４ｉｊｋ−ＲＴＲ（＃１ｋ）１１ｋ間のデータ転送は不可、ＤＧＰ（＃ｊ）５ｉｊ−ＲＴＲ（＃１ｋ）１１ｋ間のデータ転送は可能に制御する（Ｓ３３２）。

こうして、ＲＴＲ（＃１０）１１０に接続する全ノード（＃ｊ）２ｉｊのＲＣＵ（＃０）６ｉｊ０が、１Ｐｏｒｔ Ａｃｔｉｖｅに縮退する。そして、ＲＴＲ（＃１０）１１０のＡｃｔｉｖｅからＳｔａｎｄｂｙへの状態変更が、完了する。そして、クラスタ（＃０）２０のノード（＃０）２００のＤＧＰ（＃０）５００は、クラスタ（＃０）２０のノード（＃０）２００のＲＣＵ（＃０）６０００、ＩＸＳ１０のＲＴＲ（＃１０）１１０、クラスタ（＃１）２１のノード（＃０）２１０のＲＣＵ（＃０）６１００を経由して、クラスタ（＃１）２１ノード（＃０）２１０のＤＧＰ（＃０）５１０と通信が可能となる。

次にクラスタ（＃０）２０のノード（＃０）２００のＤＧＰ（＃０）５００はログ転送手段２００６により、クラスタ（＃１）２１ノード（＃０）２１０のＤＧＰ（＃０）５１０へログ２ｃ４の転送を実施する（Ｓ３１８）。

クラスタ（＃１）２１のノード（＃０）２１０のＤＧＰ（＃０）５１０の転送ログ受信手段２００７は、転送されてきたログ２ｃ４を受信する（Ｓ３４０）。

次に、クラスタ（＃１）２１のノード（＃０）２１０のＤＧＰ（＃０）５１０のＲＴＲ状態制御手段５０１０は、Ｓ３１６より以前の運用が２Ｐｏｒｔ Ａｃｔｉｖｅで行われていたか否かを確認する（Ｓ３４１）。この運用が２Ｐｏｒｔ Ａｃｔｉｖｅで行われていた（Ｓ３４１でＹｅｓのケース）場合は、ＲＴＲ状態制御手段５０１０は、ＲＴＲ（＃１０）１１０に対して、状態をＳｔａｎｄｂｙ→Ａｃｔｉｖｅに復元するように要求する（Ｓ３４２）。

これにより、Ａｃｔｉｖｅ→Ｓｔａｎｄｂｙに状態を変更する場合と同じ手順で、一時的に１Ｐｏｒｔ Ａｃｔｉｖｅに縮退していたＲＴＲ（＃１０）１１０に接続する全ノード（＃ｊ）２ｉｊのＲＣＵ（＃０）６ｉｊ０の状態が、２Ｐｏｒｔ Ａｃｔｉｖｅに復元する。そして、ＲＴＲ（＃１０）１１０のＳｔａｎｄｂｙからＡｃｔｉｖｅへの状態変更が、完了する。この運用が２Ｐｏｒｔ Ａｃｔｉｖｅで行われていなかった（Ｓ３４１でＮｏのケース）場合は、ここではなにもしない。

クラスタ（＃１）２１のノード（＃０）２１０のＤＧＰ（＃０）５１０のログ送信手段２００２は、クラスタＳＶＰ（＃１）３１にログ２ｃ４を送信する（Ｓ３４３）。
以後の処理は、実施例３の場合と同様である。

なお、運用が１Ｐｏｒｔ Ａｃｔｉｖｅで行われている場合は、ログ転送の前後で２Ｐｏｒｔ Ａｃｔｉｖｅから１Ｐｏｒｔ Ａｃｔｉｖｅへの縮退と、１Ｐｏｒｔ Ａｃｔｉｖｅから２Ｐｏｒｔ Ａｃｔｉｖｅへの復元処理を行わない。

本発明の第４の実施例によれば、第３の実施例よりさらに、ＯＳやユーザのＪＯＢの運用への影響を低減することが可能になる。

その理由は、ＲＴＲと、入出力ポートを二重化し、ＩＸＳを介したノード間通信による、ログ転送パスをＯＳの運用を妨げないように設定することを可能にしたためである。

以上の実施例は、互いに組み合わせても良い。例えば、実施例２で説明したログ転送手段２００６、転送ログ送信結果通知手段２００８、転送ログ送信結果確認手段２００９により実現される機能を、実施例３、実施例４に適用しても良い。

マルチクラスタコンピュータシステムのログ収集に適用できる。

本発明の第１の実施例の機能ブロック図である。 本発明の第１の実施例におけるシーケンス図である。 本発明の第２の実施例のシステム構成図である。 本発明の第２の実施例の機能ブロック図である。 本発明の第２の実施例における送信結果の形式を示す図である。 本発明の第２の実施例におけるシーケンス図（１／４）である。 本発明の第２の実施例におけるシーケンス図（２／４）である。 本発明の第２の実施例におけるシーケンス図（３／４）である。 本発明の第２の実施例におけるシーケンス図（４／４）である。 本発明の第２の実施例におけるログ転送動作の概念図である。 本発明の第３の実施例におけるログ転送ＳＧの構造を示す図である。 本発明の第３の実施例のシステム構成図である。 本発明の第３の実施例の機能ブロック図である。 本発明の第３の実施例におけるＲＴＲ状態と、ＣＰＵ−ＲＴＲ間及びＤＧＰ−ＲＴＲ間のデータ通信の関係図である。 本発明の第３の実施例におけるフローチャート（１／６）である。 本発明の第３の実施例におけるフローチャート（２／６）である。 本発明の第３の実施例におけるフローチャート（３／６）である。 本発明の第３の実施例におけるフローチャート（４／６）である。 本発明の第３の実施例におけるフローチャート（５／６）である。 本発明の第３の実施例におけるフローチャート（６／６）である。 本発明の第３の実施例におけるログ転送動作例の概念図である。 本発明の第４の実施例のシステム構成図である。 本発明の第４の実施例の機能ブロック図である。 本発明の第４の実施例におけるＲＣＵ状態(接続ＲＴＲの状態)とＣＰＵ−ＲＴＲ間、及び、ＤＧＰ−ＲＴＲ間のデータ通信の関係図である。 本発明の第４の実施例におけるフローチャート（１／４）である。 本発明の第４の実施例におけるフローチャート（２／４）である。 本発明の第４の実施例におけるフローチャート（３／４）である。 本発明の第４の実施例におけるフローチャート（４／４）である。 本発明の第４の実施例におけるログ転送動作例の概念図である。

符号の説明

１０ ＩＸＳ
２０ クラスタ（＃０）
２１ クラスタ（＃１）
２ａ ログ送出装置
２ｂ ログ送出装置
２ｉ クラスタ（＃ｉ）
２ｍ クラスタ（＃ｍ）
３０ クラスタＳＶＰ（＃０）
３１ クラスタＳＶＰ（＃１）
３ｉ クラスタＳＶＰ（＃ｉ）
３ｍ クラスタＳＶＰ（＃ｍ）
４０ ＬＡＮ（＃０）
４１ ＬＡＮ（＃１）
４ｉ ＬＡＮ（＃ｉ）
４ｍ ＬＡＮ（＃ｍ）
５０ データ転送パス
６０ ＬＡＮ
６ａ ネットワーク
７０ 統合ＳＶＰ
７ａ ログ登録装置
１００ ＲＴＲ（＃００）
１０Ｆ ＲＴＲ（＃０Ｆ）
１０ｋ ＲＴＲ（＃０ｋ）
１１０ ＲＴＲ（＃１０）
１１Ｆ ＲＴＲ（＃１Ｆ）
１１ｋ ＲＴＲ（＃１ｋ）
１ｄｋ ＲＴＲ（＃ｄｋ）
２００ ノード（＃０）
２０Ｆ ノード（＃Ｆ）
２１０ ノード（＃０）
２１Ｆ ノード（＃Ｆ）
２１ｎ ノード（＃ｎ）
２ｉ０ ノード（＃０）
２ｉｊ ノード（＃ｊ）
２ｉｎ ノード（＃ｎ）
２ａ１ ログ送信手段
２ａ２ ログ送信失敗検出手段
２ａ３ 代行送信要求手段
２ｂ１ ログ送信手段
２ｂ２ ログ送信失敗検出手段
２ｂ３ 代行送信要求手段
５００ ＤＧＰ（＃０）
５１０ ＤＧＰ（＃０）
５ｉｊ ＤＧＰ（＃ｊ）
６ｉｊ 内部バス
７ａ１ ログ受信手段
９００ 送信結果
９００ ログ送信結果
９０１ 結果
９０２ 失敗コード
９１０ ログ転送ＳＧ
９１１ ログ−重要度テーブル
９１４ 重要度−ログ転送設定テーブル
１００１ ログ転送パス確保手段
１００２ ルート手段
１１０１ 状態制御手段
１１０２ 状態通知手段
２００１ 障害監視手段
２００２ ログ送信手段
２００３ ログ送信失敗検出手段
２００４ ログ転送実施判断手段
２００５ ログ転送パス設定／解放手段
２００６ ログ転送手段
２００７ 転送ログ受信手段
２００８ 転送ログ送信結果通知手段
２００９ 転送ログ送信結果確認手段
３００１ ログ登録要求手段
４０００ ＣＰＵ（＃０）
４１ＦＦ ＣＰＵ（＃Ｆ）
４ｉｊ０ ＣＰＵ（＃０）
４ｉｊＦ ＣＰＵ（＃Ｆ）
４ｉｊｋ ＣＰＵ（＃ｋ）
５００４ ＳＧ確認手段
５００５ ログ転送パス決定手段
５０１０ ＲＴＲ状態制御手段
５０１１ ログ転送ＳＧ記憶部
６０００ ＲＣＵ（＃０）
６００１ ＲＴＲ状態受信手段
６００２ ポート制御手段
６００３ 入出力ポート、入出力ポート（＃１）
６００４ 入出力ポート（＃２）
６１００ ＲＣＵ（＃０）
６１ＦＦ ＲＣＵ（＃Ｆ）
６ｉｊ０ ＲＣＵ（＃０）
６ｉｊＦ ＲＣＵ（＃Ｆ）
６ｉｊｋ ＲＣＵ（＃ｋ）
７００１ ログ登録手段
７００２ ログデータ蓄積部

Claims (19)

1. 複数のログ送出装置と、一以上のログ登録装置とがネットワークで接続され、前記ログ送出装置が、前記ログ登録装置に対して、ログを送信する手段と、前記ログの前記送信の失敗を検出する手段と、他の前記ログ送出装置に対して、前記ログの前記送信の代行要求を送信する手段と、前記代行要求を受信する手段と、前記代行要求を受信した場合に前記ログの代行送信を実行する手段とを有し、前記ログ登録装置が、前記ログを受信して、前記ログを登録する手段を有することを特徴とするログ収集システム。
2. 前記ログ送出装置は、コンピュータシステムのノードであって、前記ログの前記送信の前記代行要求は、ノード間接続装置を使用するノード間通信パスを介して送信されることを特徴とする請求項１に記載のログ収集システム。
3. 前記ログの前記代行送信に係る処理に先立って、前記コンピュータシステムのオペレーティングシステムおよびアプリケーションプログラムによる前記ノード間通信パスの使用を禁止状態とし、前記代行要求を送信する前記手段、および、前記代行要求を受信する前記手段による前記ノード間通信パスの使用を許可状態とする手段と、前記ログの前記代行送信に係る処理の終了に伴って、前記コンピュータシステムのオペレーティングシステムおよびアプリケーションプログラムによる前記ノード間通信パスの使用を許可状態とし、前記代行要求を送信する前記手段、および、前記代行要求を受信する前記手段による前記ノード間通信パスの使用を禁止状態とする手段とを有することを特徴とする請求項２記載のログ収集システム。
4. 前記ログの前記代行送信に係る処理は、二重化された前記ノード間通信パスの片方を使用してするものであって、前記ログの前記代行送信に係る処理に先立って、前記コンピュータシステムのオペレーティングシステムおよびアプリケーションプログラムによる前記ノード間通信パスの前記片方の使用を禁止状態とし、前記代行要求を送信する前記手段、および、前記代行要求を受信する前記手段による前記ノード間通信パスの前記片方の使用を許可状態とする手段と、前記ログの前記代行送信に係る処理の終了に伴って、前記コンピュータシステムのオペレーティングシステムおよびアプリケーションプログラムによる前記ノード間通信パスの前記片方の使用を許可状態とし、前記代行要求を送信する前記手段、および、前記代行要求を受信する前記手段による前記ノード間通信パスの前記片方の使用を禁止状態とする手段とを有することを特徴とする請求項２または３記載のログ収集システム。
5. 前記ログ送出装置が、前記代行送信を実行した結果を送信する手段と、前記結果を受信する手段と、前記結果が前記代行送信の失敗を示すものであった場合に、前記代行送信の前記失敗を示す前記結果を送信した前記ログ送出装置以外の、他の前記ログ送出装置に対して、前記ログの前記送信の前記代行要求を送信する手段とを有することを特徴とする請求項１記載のログ収集システム。
6. 前記ログ送出装置が、前記送信の前記失敗、乃至、前記代行送信の前記失敗に関する情報を前記ログの情報に付加して、新たな前記ログとする手段を有することを特徴とする請求項５記載のログ収集システム。
7. 前記ログ送出装置は、コンピュータシステムのノードであって、前記ログの前記送信の前記代行要求、および、前記結果は、ノード間接続装置を使用するノード間通信パスを介して送信されることを特徴とする請求項５または６記載のログ収集システム。
8. 前記ログの前記代行送信に係る処理に先立って、前記コンピュータシステムのオペレーティングシステムおよびアプリケーションプログラムによる前記ノード間通信パスの使用を禁止状態とし、前記代行要求を送信する前記手段、前記代行要求を受信する前記手段、前記結果を送信する前記手段と、および、前記結果を受信する前記手段による前記ノード間通信パスの使用を許可状態とする手段と、前記ログの前記代行送信に係る処理の終了に伴って、前記コンピュータシステムのオペレーティングシステムおよびアプリケーションプログラムによる前記ノード間通信パスの使用を許可状態とし、前記代行要求を送信する前記手段、前記代行要求を受信する前記手段、前記結果を送信する前記手段と、および、前記結果を受信する前記手段による前記ノード間通信パスの使用を禁止状態とする手段とを有することを特徴とする請求項７記載のログ収集システム。
9. 前記ログの前記代行送信に係る処理は、二重化された前記ノード間通信パスの片方を使用してするものであって、前記ログの前記代行送信に係る処理に先立って、前記コンピュータシステムのオペレーティングシステムおよびアプリケーションプログラムによる前記ノード間通信パスの前記片方の使用を禁止状態とし、前記代行要求を送信する前記手段、前記代行要求を受信する前記手段、前記結果を送信する前記手段と、および、前記結果を受信する前記手段による前記ノード間通信パスの前記片方の使用を許可状態とする手段と、前記ログの前記代行送信に係る処理の終了に伴って、前記コンピュータシステムのオペレーティングシステムおよびアプリケーションプログラムによる前記ノード間通信パスの前記片方の使用を許可状態とし、前記代行要求を送信する前記手段、前記代行要求を受信する前記手段、前記結果を送信する前記手段と、および、前記結果を受信する前記手段による前記ノード間通信パスの前記片方の使用を禁止状態とする手段とを有することを特徴とする請求項７または８記載のログ収集システム。
10. 前記ログを生成する手段と、前記ログを前記ログ登録装置に送信する手段と、前記ログの送信の失敗を検出する手段と、前記ログを転送するか否かを判断する手段と、前記ログを転送するパスを決定する手段と、前記パスを確保する手段と、前記ログを前記パスを介して送信する手段と、前記ログを前記パスを介して受信する手段と、前記受信した前記ログを前記ログ登録装置に送信する手段と、前記受信した前記ログの前記ログ登録装置への前記送信の結果を前記パスを介して送信する手段と、前記結果を前記パスを介して受信する手段とを有することを特徴とする請求項１乃至９のいずれかに記載のログ収集システム。
11. ログ送出装置が、ネットワークを介して、受信したログを登録するログ登録装置に対して前記ログを送信し、前記ログの前記送信の失敗を検出し、他の前記ログ送出装置に対して前記ログの前記送信の代行要求を送信し、前記代行要求を受信した場合に前記ログの代行送信を実行することを特徴とするログ収集方法。
12. 前記ログ送出装置が、前記代行送信を実行した結果を送信し、前記結果を受信し、前記結果が前記代行送信の失敗を示すものであった場合に、前記代行送信の前記失敗を示す前記結果を送信した前記ログ送出装置以外の他の前記ログ送出装置に対して、前記ログの前記送信の前記代行要求を送信することを特徴とする請求項１１記載のログ収集方法。
13. 前記ログ送出装置が、前記送信の前記失敗、乃至、前記代行送信の前記失敗に関する情報を前記ログの情報に付加して、新たな前記ログとすることを特徴とする請求項１２記載のログ収集方法。
14. コンピュータシステムのノードであって、ネットワークで接続されたログ登録装置に対してログを送信する手段と、前記ログの前記送信の失敗を検出する手段と、他の前記ノードに前記ログの前記送信の代行要求を送信する手段と、前記代行要求を受信して、前記ログの代行送信を実行する手段とを有することを特徴とするノード。
15. 前記ノードは、ノード間接続装置を使用するノード間通信パスを介して、前記送信の前記代行要求を送信し、前記代行要求を受信することを特徴とする請求項１４に記載のノード。
16. 前記代行送信を実行した結果を送信する手段と、前記結果を受信して、前記結果が前記代行送信の失敗を示すものであった場合に、前記代行送信の前記失敗を示す前記結果を送信した前記ノード以外の他の前記ノードに対して、前記ログの前記送信の前記代行要求を送信する手段とを有することを特徴とする請求項１４または１５記載のノード。
17. 前記送信の前記失敗、乃至、前記代行送信の前記失敗に関する情報を前記ログの情報に付加して、新たな前記ログとする手段を有することを特徴とする請求項１４乃至１６のいずれかに記載のノード。
18. 前記ノードは、ノード間接続装置を使用するノード間通信パスを介して、前記ログの前記送信の前記代行要求、および、前記結果を送信し、前記ログの前記送信の前記代行要求、および、前記結果を受信することを特徴とする請求項１６または１７記載のログ収集システム。
19. 前記ログを生成する手段と、前記ログを前記ログ登録装置に送信する手段と、前記ログの送信の失敗を検出する手段と、前記ログを転送するか否かを判断する手段と、前記ログを転送するパスを決定する手段と、前記ログを前記パスを介して送信する手段と、前記ログを前記パスを介して受信する手段と、前記受信した前記ログを前記ログ登録装置に送信する手段と、前記受信した前記ログの前記ログ登録装置への前記送信の結果を前記パスを介して送信する手段と、前記結果を前記パスを介して受信する手段とを有することを特徴とする請求項１４乃至１８のいずれかに記載のノード。

Images