(57)【要約】【課題】  多数の機能要素がネットワークで接続されたシステムにおいて、構成要素の故障検知とバックアップの信頼度を向上させ、システムの可用性を向上する。【解決手段】  故障要素の特定とバックアップ可否を複数の構成要素で決定、または、多数決で決定することにより上記課題を解決する。また、構成要素内部のサブ要素間で相互監視し、構成要素内のサブ要素の故障時、同一要素内の他のサブ要素により構成要素の動作停止と外部インタフェースを切り離す手段により、さらに、システムのバックアップ動作の信頼性を向上できる。また、複数のサブ要素間で、または、サブ要素間の多数決で構成要素内の故障検知を行い、自己動作の停止を行う手段により、故障要素の動作停止の確実性を確保できる。【選択図】図1
2008097164.tif 000002
【特許請求の範囲】
【請求項１】
複数の機能要素がネットワークで接続され、障害が発生した機能要素を停止して縮退運転を行うシステムにおいて、障害が発生した機能要素の特定が、他の複数の機能要素で一致するか否かの判断、または、機能要素間の多数決により決定し、該決定により特定された機能要素をバックアップすることを特徴とする、複数の機能要素から構成されるシステムの故障監視方法。
【請求項２】
前記システムにおいて、各機能要素内のサブ機能部位は、サブ機能部位間で相互に監視し、サブ機能部位の異常により単一機能要素として動作できない場合は、自要素の動作を停止し、他機能要素とのインタフェースを切り離すことにより、自要素をシステム構成から除去することを特徴とする請求項１記載の複数の機能要素から構成されるシステムの故障監視方法。
【請求項３】
前記機能要素の自己動作停止を、２つ以上のサブ機能部位の障害発生認識が一致するか、または、サブ機能部位間の多数決により行うことを特徴とする請求項２記載の複数の機能要素から構成されるシステムの故障監視・処理方法
【請求項４】
４個以上の機能要素がネットワークを介して相互に接続されたシステムにおいて、複数の機能要素各々を２個以上のネットワークノードとグループ化して、該グループ内で相互に接続し、該グループ内で相互監視し、該グループ内の機能要素またはネットワークノードが故障したときに該グループ内でバックアップを行うことを特徴とする、複数の機能要素から構成されるシステムの故障監視方法。
【請求項５】
前記システムにおいて、障害が発生した機能要素またはネットワークノードの特定が、該グループ内にある他の複数の機能要素やネットワークノードで一致するか否かの判断、または、該グループ内での多数決により決定し、該決定により特定された機能要素またはネットワークノードをバックアップすることを特徴とする請求項４記載の複数の機能要素から構成されるシステムの故障監視方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の機能要素から構成されるコンピュータシステムや通信システムにおける、故障監視方法に関する。
【背景技術】
【０００２】
マルチＣＰＵシステムや超並列計算機、多数の局や中継局から構成される通信ネットワークの故障監視や故障処理方法として、１台の待機系による現用系の故障監視、故障発生時のバックアップ処理などが行われている（特許文献１）。また、自ユニット内の処理制御部を監視し故障検知時、処理制御部のリセットを行い再起動することが行われている（特許文献２）。
【０００３】
【特許文献１】特開平０６−２３１０９５号公報
【特許文献２】特開２０００−１４８７０９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、従来の技術では、故障監視側の故障監視回路の故障により、誤って監視対象が故障していると認識する場合が考慮されていない。このため、バックアップや故障処理を行う側の監視機構が故障した場合、システム全体に重大な影響を及ぼすことがある。また、故障発生要素が他の部位に悪影響を与えないために、故障した機能要素の動作を停止する場合、他要素からの強制停止手段や人手による介入が必要であったため、ケーブルや配線エリア、人手作業のコストが大きくなっていた。
【０００５】
本発明の目的は、従来技術では故障監視回路自体の故障時に誤って故障処理をしてしまうという問題と、故障要素の動作停止のための手段を安価なコストで提供することである。
【課題を解決するための手段】
【０００６】
本発明は、（１）故障箇所の特定とバックアップ可否を複数の構成要素間での一致または多数決で決定するという特徴と、（２）故障要素がシステムへ悪影響を及ぼさないために、機能要素を構成するサブ要素間で相互監視し、自要素における故障の場合自要素の動作を停止し、他要素とのインタフェースを切り離すという特徴と、（３）自要素の動作停止可否を自要素内の複数のサブ要素間の一致または多数決により行うという特徴を有する。さらに、多数の機能要素がネットワークを介して相互接続されたシステムにおいて、前記（１）の特徴を実現する一つの方法として、複数の機能要素を２個以上のネットワークノードとグループ化して、該グループ内で故障箇所特定、バックアップ可否の決定、並びにバックアップ処理を行うという特徴を有する。
【発明の効果】
【０００７】
本発明では、故障要素の特定を複数の要素で行うので、故障監視回路の故障による誤指摘、不当なバックアップ動作の発生を抑止できる。また、各機能要素の内部でサブ要素による相互監視と自己動作停止機能により、自要素の異常動作がシステムに影響を及ぼさないように他部位とのインタフェース切り離しを実現できるので、他部位からの強制停止のための回路やネットワークがなくても故障要素によるシステムへの悪影響を防ぐことができる。また、人手介入なしにＣＰＵの停止、バックアップを行えるので、システム運用費／保守費を削減できる。サブ要素間の相互チェックは、通常、サブ要素間のインタフェースで使用しているタイマー監視やデータチェックなどのチェック回路を用いるので大きな追加回路は不要である。
【０００８】
さらに、多数の機能要素がネットワークを介して相互接続されたシステムでは、機能要素とネットワークノードをグループ化して該グループ内で相互監視、バックアップを行えるので、少数の機能要素がネットワークで接続されたシステムと同様に簡単にバックアップ機構を構築できる。
【発明を実施するための最良の形態】
【０００９】
監視側要素の監視回路故障によるバックアップ契機の誤認識を防ぎ、かつ、バックアップ後のシステム動作を被バックアップ要素が撹乱しないように、複数の機能要素により故障要素の特定を行う機構と、自要素内のサブ要素による相互監視・自己動作停止機能を合わせて有するシステムが最良の実施形態である。さらに、多数の機能要素がネットワークを介して接続されたシステムでは、いくつかの機能要素とネットワークノードをグループ化し、各機能要素をグループ内の複数のネットワークノードに接続して、該グループ内で相互監視・バックアップを行うようなシステムが最良の実施形態になる。
【実施例１】
【００１０】
図1は、第1の実施例である超並列コンピュータシステムの概略構成図である。
【００１１】
本実施例以降、自要素の動作停止と外部インタフェース切り離しを「自己FREEZ」と呼ぶことにする。
【００１２】
プロセッサユニット101は、ネットワークノード102により、相互に接続されている。プロセッサユニット101とネットワークノード102は2個ずつグループ化されており、プロセッサユニット101は、信号線群103により、自ユニットに対応するネットワークノードに接続されているが、信号線群103の断線、ネットワークノード102の故障による通信断に対応するため、グループ内の隣のネットワークノードとも別の信号線群104により接続されている。ネットワークノード102はネットワーク信号105によりグループ外のネットワークノードとも相互接続されている。
【００１３】
図2はプロセッサユニット101の概略構成図である。主ＣＰＵ201は、通信ポート202、203と切替論理204を介して接続されている。相互動作監視テーブル205には自ユニットP(2p)j、ペアユニットP(2p+1)j、ネットワークノードN(2p)j、ペアノードN(2p+1)jの状態を登録している（pは0〜k）。ラッチ206は自己FREEZ状態保持用のラッチであり、主ＣＰＵ201からのセット信号211または、通信ポート202、203の両方のFREEZアサート信号212、213が同時ＯＮ時にセットされる。このラッチはPower ON時やシステムリセット時にもリセットされるが、本図には示していない。
【００１４】
図3は、図1におけるネットワークノード102の概略構成図である。301は通信ポートであり、構成は、図2におけるプロセッサユニット101内の通信ポートと同じ構成である。該ポートは、ネットワークノード102間の通信用に4ポート、プロセッサユニット101との通信用に2ポート必要である。プロセッサユニット101との通信用のうち、ひとつは、バックアップ用ポートである。ＳＷＣ302はネットワークのルート制御を行うスイッチングコントローラである。SWC302は２重化してネットワークノード毎の可用性を高めることもできるが、当実施例では単独の構成である。これは、SWC302の異常時、ネットワークノードの動作を停止する必要があるが、迂回パスにより他のネットワークノードを介してプロセッサユニット間の通信は可能だからである。回路303はFREEZ多数決回路であり、その論理的な構成を図4に示す。通信ポート301とSWC302の合計７個の構成要素からのFREEZ承認信号306の多数決で自己FREEZ要否を決定する。テーブル305は、相互動作監視テーブルであり、図2と同じように、プロセッサユニットP(2p)j、ペアユニットP(2p+1)j、自ネットワークノードN(2p)j、N(2p)jのペアノードN(2p+1)jの状態を登録している。
【００１５】
図5は、図2における主ＣＰＵ201の故障監視・故障処理の概略フローである。Power ON時は、NC0(202)を通信ポートとして使用するが、予備ポート203ともポーリングを行い、相互の正常性チェックを行っている。通信動作中に現用ポート202の異常が検出されると予備ポート203のテストを行い、予備ポート203が正常であれば203に通信ポートを切り替えるが、203も正常動作不能の場合、エラーロギング後、自己FREEZを行い、動作停止する。
【００１６】
図6は、図2における通信ポート202、203の故障監視・処理の概略フローである。左側が現用ポートの処理、右側が予備ポートの処理を示す。現用、予備ポートとも、相互の動作監視(605、615)と共に主ＣＰＵの動作も監視している(603、613)。主CPU201の異常検知時はFREEZアサート信号212または213をONにする。しかし、もう一方の通信ポートが主ＣＰＵの異常を検知してFREEZ信号をONにしない限り、プロセッサユニット101はFREEZしない。相手ポートの異常検知時も自ポートからのFREEZアサート信号212または213をONにする(607、617)が、相手ポートのFREEZ信号がONになって始めてプロセッサユニット101はFREEZされる。自ポートのテスト(606、616)で異常検出時は自ポートのFREEZを行うが、この部分の詳細は省略する。基本的には自ポート内のサブユニット間の相互監視、自己テスト等により正常性をテストし、自己FREEZする。
【００１７】
図7は、図3におけるSWC(スイッチングコントローラ)302の概略動作を示している。通常の通信処理中は、各通信ポート301と交信するか、ある一定時間間隔で定期ポーリングを行い、各通信ポート301と相互に正常性を確認しあう(702、703)。NC301のひとつに異常が検出された場合、SWC302は自己テストにより自己の正常性を確認(705)後、NC301の異常個数によりSWC自体が自己FREEZするかどうか判定する。ネットワークノード間の通信ポートは４個あるので、2個正常動作すれば他ノードとの通信は行えるので、３個以上のポートが異常と判断された場合に自己FREEZ信号をONにする。プロセッサユニットとの通信ポートは２個とも異常であるときのみ、自己FREEZ信号をアサートする。また、705で自サブユニットSWC302の異常と判断した場合には、自ネットワークノードではもはや、正確な通信ができないので自己FREEZ信号をONにする。SWC302の自己テストとしては、711〜713のようなテストがある。
【００１８】
図8は、図3における通信ポート301の概略動作を示した図である。各ポートともSWC302を介して相互通信するので、通信データがあるときは、相手ポートと共にSWC302の正常性も確認できる。通信データがないときは、正常性確認のため、ポーリングにより相互監視する。一定時間以上相手から応答がない場合は、まず自己テストを行い、自己の正常性確認後(804)、他の通信ポートの異常かSWC302の異常かを区別する（806）。この区別の方法は詳述しないが、通信データのルーティングデータや、通信レスポンスがSWC302から正常に返って来ているかどうか等で区別できる。SWC302の異常の場合でも通信ポートの異常の場合でも、自ポートから出力している、自己FREEZ信号306をONにする(810)。自ポート正常性確認(805)で、自ポートの異常が確認された場合、他ポート301やSWC302に自ポート異常の通知を送付した後(807)、自ポートのFREEZを行う（809）。自ポートFREEZ時には、ネットワークノード102のFREEZアサート信号306もONになる。804の自己テストには821〜824のような項目があるが詳述しない。SWC内のプログラムの暴走等の場合、ポーリング応答は定期的に受け付けている場合があるので、通信ステータス遷移やコマンド／レスポンスの妥当性チェックなども行うほうが信頼度は向上できる。
【００１９】
図9は、図1におけるプロセッサユニット101とネットワークノード102の相互監視・バックアップ処理の概要を示した図である。Power ON時やリセット時には相互監視テーブルの内容は全要素とも「起動中」、「正常」に設定される。通常通信処理 (902) 中には、データ交信かポーリングを一定時間間隔で行う。データ異常やポーリング異常が検出された場合、まず自己テストを行い自要素の正常性をテストする(804、805)。自要素の正常性を確認した場合、相互監視テーブルの相手要素の状態を「異常」に設定する(906)。次に他の正常要素と相互監視テーブル205、305を交換する。他要素から受け取ったテーブルと自要素の持つ相互監視テーブルで異常要素が一致するか確認する(908)。異常要素が一致した場合、異常要素の種類が自要素と同一か判定し(909)、異常要素がプロセッサユニット101ならば他方のプロセッサユニット101、異常要素がネットワークノード102ならばもうひとつのネットワークノード102がバックアップ動作を開始する(910)。この時点では、異常要素は自己の異常を検知して自己FREEZしているので、バックアップ動作がシステムに悪影響を及ぼすことはない。自要素の正常性判定905で、自要素の異常が検出された場合、相互監視テーブル205、305内の自要素を「異常」と設定し(921)、他要素へ自要素の異常を通知し(925)、自要素のFREEZを行う。自己テスト904の具体的な項目は、931〜934がある。自要素内のサブ要素のひとつである主処理部の暴走の場合、ポーリング応答チェックだけでは正常性の確認ができない場合があるので、通信ステータスやコマンド／レスポンスの妥当性チェックを行う方が信頼度は向上できる。
【００２０】
以上のような構成であるので、図1〜9で示した実施例1では、異常要素の特定、バックアップ動作の開始可否を複数の構成要素の多数決で決めるので、誤って開始したバックアップ動作によるシステムかく乱の可能性をなくすことができる。また、各要素を構成するサブ要素間で相互監視し、自要素の異常検出を行い、自要素の動作を停止すると同時に他要素とのインタフェースを遮断するので、内部ＣＰＵの暴走などによる外部インタフェース、ひいては、システム全体のかく乱を防止することができる。また、2個のネットワークノードと2個のプロセッサユニットのペアで相互監視を行うので、多数要素から構成される超並列計算機システムでありながら、２ノードのシステムと同等の構成でバックアップシステムを構成できる。これにより、ＣＰＵが一台故障してもＬＳＩやＭＣＣ等を停止・交換する必要がなく、故障ＣＰＵの停止やバックアップ時の人手介入をなくし、システム運用費、保守費を削減できる。
【実施例２】
【００２１】
図10は、本発明の2番目の実施例である、共有バス接続計算ユニットの構成図である。図1の構成は、プリント基板やMCC、一部の高集積ＬＳＩで実現されている。図10で、N個のCPU１001は、共用バス1009を介して、データ授受、バス使用権制御を行う。CPＵ相互監視テーブル1002は、各ＣＰＵ1001の状態を示す表であり、該当ＣＰＵからみた各ＣＰＵの状態を示す。 CPＵ相互監視テーブル1002のデータは、共用バス1009を介して、ＣＰＵ間で相互に交換される。該テーブル1002には自CPUの状態も登録してある。該テーブル1002の内容は各CPUでチェックされ、図12に示すフローで処理されるようにプログラムされている。図12の処理1205、1207でバックアップを行うCPUは、例えば、故障CPUの番号をZとすると、[(Z+1)/N](Nの剰余)という式で求められる番号のCPUが行う。この他、CPU負荷の少ないCPUが行うなどの決定方法もとることができる。FREEZ多数決回路1003は、実行制御部1005、CPU-BUS制御部1006、メモリアクセス制御部100７、IO-BUS制御1008からの各部位監視状況データ出力を受け取り、各部位からの監視状況データにより、表１に示すような条件で自己FREEZ(自己動作停止と共有バス1009からの切り離し)するかどうかを決める。具体的な回路構成は示さないが、実施例１の図2、図4のFREEZ決定論理と同様な構成になる。各部位の監視状況データの詳細も示さないが、CPＵ相互監視テーブル1002と同等な構造をしている。
【００２２】
【表１】
2008097164.tif 000003
【００２３】
表１をみれば明らかなように、実行制御1005に関しては、他部位すべてが異常と認識した場合のみ自CPUをFREEZする構成になっている。実行制御部1005以外のサブ要素の異常の場合、他の3個のうち、2個が異常と判断すればFREEZ動作に移る。
【００２４】
各部位1005〜1008の相互監視方法は、他部位とのインタフェースにより異なるが、以下のような方法がある。下記(３)は通常処理ではインタフェースがないような部位間の相互チェックに用いる。プログラムの暴走などの場合、(１)〜(３)では異常検知できない場合があるが、(４)のようなインタフェース応答内容の妥当性で検知できる。
（１）監視部位が出力したデータのチェック（パリティチェック、ＥＣＣ等）
（２）応答時間監視
（３）監視部位からのライブ信号監視
（４）コマンド/レスポンスの妥当性チェック
図11のNode1101は、図10の計算ユニットに対応しており、CPU1001をN個搭載している。全体でＭ個のNode1101を共有バスで接続したコンピュータシステムになっている。
【００２５】
Node1101はNode間バス1109により接続され、データ授受、バス使用権制御などのトランザクション送受を行う。FREEZ多数決論理1103はNode内の各ＣＰＵ1001から送信される自NodeのFREEZ信号1105により、自NodeのFREEZ(自Node動作停止、Node間バス出力のOFF)可否を判定する回路である。論理構成詳細は示さないが、実施例１の図2、図4のFREEZ決定論理2と同様な構成になる。自己FREEZ回路1104は、自己ＦＲＥＥＺ状態保持回路である。この回路内の自己ＦＲＥＥＺラッチがＯＮになっていると、自己ＦＲＥＥＺ状態になり、ＣＰＵ等の動作を停止し、外部バスへの出力は論理的にＯＦＦの状態になる。該回路1104には、システムReset時の自己ＦＲＥＥＺラッチReset回路も含まれる。回路1103、1104は、部品点数削減のため、ＢＵＳ制御回路1106と同じ部品内に搭載している。
【００２６】
図12は、自己FREEZ回路の概略処理フローである。正常状態では、1201〜1203をループし状態監視している。CPU相互監視データで異常CPUの存在が報告されると、1204に進み、各ＣＰＵ1001間で相互監視データ1002を交換し、各CPUが認識している異常ＣＰＵが一致するかどうかチェックする。一致する場合、無条件に該当ＣＰＵのバックアップ処理1205を行う。1204で異常CPUが一致しない場合、各ＣＰＵを異常と指摘している他のＣＰＵの個数を調べる(1206)。もし、ひとつのＣＰＵを異常と指摘しているＣＰＵの個数が複数個で、かつ、異常指摘されたＣＰＵ1101が1個の場合、正常指摘と判断し処理1207に移り、複数個のＣＰＵ1101から異常と指摘されたＣＰＵ1101の異常処理、バックアップ処理を行う。もし、複数個のＣＰＵから異常と指摘されたＣＰＵが複数個ある場合、多点障害または共有ＢＳＵ障害としてシステム異常処理1208〜1209の処理を行い、自CPUが出力している自Nodeの自己FREEZ信号1105をONにする。
【００２７】
ある１個のＣＰＵ内部でバスインタフェース回路に故障が発生したとすると、該ＣＰＵ1001は他のＣＰＵ1001すべてと通信できなくなるため、該ＣＰＵは他のＣＰＵすべてが異常と相互監視データに記録する可能性がある。しかし、他のＣＰＵでは、前記故障したＣＰＵが唯一の異常ＣＰＵなので該ＣＰＵを異常として登録する。このため、1206から1207に進み、バックアップ処理を開始する。
【００２８】
図13はNode間の相互監視、異常Node多数決判定論理の動作フローを示したものである。1301〜1307までは、図12のＣＰＵの相互監視・多数決判定回路と同様であるが、処理1308では自己FREEZしないで、システム異常処理のみを行い、オペレータ通報する。
【００２９】
実施例2（図10〜13）においては、複数ＣＰＵやＮｏｄｅから構成されるシステムにおいて、バックアップ要否を相互の多数決で決定するので、現用CPUやＮｏｄｅの異常誤認を防止し、正常動作中のCPUやNodeの誤ったディセーブルや誤ったバックアップ動作の立ち上げを防止し、システムの信頼性、稼動性を向上することができる。また、自要素内部の機能要素であるサブ要素間相互監視により自要素の異常監視を行い、異常時に自己Ｆｒｅｅｚ（自己動作の抑止と外部インタフェースの切り離し）を行うので、他のCPUやＮｏｄｅによる異常CPUやＮｏｄｅのディセーブル機能が不要になり、多数のCPU／Ｎｏｄｅ間でのディセーブル関連論理／信号線を削減でき、バックアップ動作を容易に実現でき、従来一部の故障で廃棄されていたＬＳＩなどの部品に関しても交換せずに、延命使用できる。本実施例2は共有バス接続のため、意識しなくても構成上自ずと、ひとつのNode1101がCPUとネットワークNodeのグルーピング単位になっており、請求項4は実現されている。
【図面の簡単な説明】
【００３０】
【図１】超並列コンピュータシステムの概略構成図
【図２】プロセッサユニットの概略構成図
【図３】ネットワークノードの概略構成図
【図４】多数決論理の論理的構成図
【図５】プロセッサユニット内主ＣＰＵの概略動作フロー
【図６】プロセッサユニット内通信ポートの概略動作フロー
【図７】ネットワークノード内スイッチング制御部の概略動作フロー
【図８】ネットワークノード内通信ポートの概略動作フロー
【図９】プロセッサユニットとネットワークノードの故障監視・処理の概略動作フロー
【図１０】共有バス接続のマルチCPU Nodeの概略構成図
【図１１】複数Nodeの共有バス接続システムの概略構成図
【図１２】マルチCPU Nodeにおける故障監視・処理の概略動作フロー
【図１３】複数Nodeの共有バス接続システムの故障監視・処理の概略動作フロー
【符号の説明】
【００３１】
106：超並列計算機での相互監視・バックアップ単位、205：プロセッサユニット101内における相互監視テーブル、206：プロセッサユニット101内の自己FREEZ用ラッチ、305：ネットワークノード102内における相互監視テーブル、303：自己FREEZ多数決論理、304：ネットワークノード102内の自己FREEZ用ラッチ、1002：CPU間相互監視テーブル、1003：CPU1001の自己FREEZ多数決論理、1004：CPU1001内の自己FREEZ用ラッチ、1102：Node間相互監視テーブル、1103：Node1101の自己FREEZ多数決論理、1104：Node1101内の自己FREEZ用ラッチ
【図１】
2008097164.tif 000004
【図２】
2008097164.tif 000005
【図３】
2008097164.tif 000006
【図４】
2008097164.tif 000007
【図５】
2008097164.tif 000008
【図６】
2008097164.tif 000009
【図７】
2008097164.tif 000010
【図８】
2008097164.tif 000011
【図９】
2008097164.tif 000012
【図１０】
2008097164.tif 000013
【図１１】
2008097164.tif 000014
【図１２】
2008097164.tif 000015
【図１３】
2008097164.tif 000016