JP2015156101A

JP2015156101A - ダンプシステムおよびダンプ処理方法

Info

Publication number: JP2015156101A
Application number: JP2014030678A
Authority: JP
Inventors: 隆弘白地; Takahiro Shiraji
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2014-02-20
Filing date: 2014-02-20
Publication date: 2015-08-27
Anticipated expiration: 2034-02-20
Also published as: JP6256087B2

Abstract

【課題】全てのＣＰＵコアで異常が発生した場合であってもダンプ処理を完了させることができるダンプシステムを提供すること。
【解決手段】本発明によるダンプシステムは、第１のサーバのダンプ処理の異常検出をする検出手段と、前記異常検出に基づいて前記第１のサーバのダンプ処理を代行する代行手段と、を有し、前記代行手段は、前記第１のサーバのＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）とは独立し、前記第１のサーバのメモリにアクセスしてダンプファイルを採取する。
【選択図】図１

Description

本発明は、情報処理装置のダンプ処理技術に関する。

サーバなどの情報処理装置においては、ハードウェア障害やプログラムの不具合により、ＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）クラッシュが起きることがある。その場合、障害発生時のメモリの情報をダンプファイルとして保存し、障害解析に用いることができる。

特開２０１１−７０６５５号公報

しかしながら、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）コアの障害やＳＭＩ（ＳｙｓｔｅｍＭａｎａｇｅｍｅｎｔＩｎｔｅｒｒｕｐｔ）タイムアウト等で、ダンプファイルの採取に失敗し、障害解析の手がかりとなる情報がなくなり、原因究明が難しくなることがある。ＣＰＵ以外のデバイスによりダンプ採取する方法もあるが、通常の運用で使用しない専用バスを必要とすることや、メモリの大容量化によって保存すべきデータが大きくなっていることに対する保存の方法や通信の高速化などの課題を有している。

特許文献１では、複数のＣＰＵのうち、正常に動作するＣＰＵコアを用いて、ＢＭＣ（ＢａｓｅｂｏａｒｄＭａｎａｇｅｍｅｎｔＣｏｎｔｒｏｌｌｅｒ）に実装されたバッファメモリに対してメモリダンプのデータをコピーし、ＢＭＣのネットワーク経由でメモリダンプ収集用のサーバに送信し保存する方法が開示されている。しかしながら、全てのＣＰＵコアで異常が発生した場合には、ダンプファイルを処理することはできなかった。また、ＢＭＣに実装されたバッファメモリは容量が小さく、サーバに搭載されたメモリ容量のデータをコピーするには不十分であった。また、メモリダンプ収集用の専用のサーバを必要としていた。

本発明は、上記の課題に鑑みてなされたものであり、その目的は、全てのＣＰＵコアで異常が発生した場合であってもダンプ処理を完了させることができるダンプシステムを提供することにある。

本発明によるダンプシステムは、第１のサーバのダンプ処理の異常検出をする検出手段と、前記異常検出に基づいて前記第１のサーバのダンプ処理を代行する代行手段と、を有し、前記代行手段は、前記第１のサーバのＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）とは独立し、前記第１のサーバのメモリにアクセスしてダンプファイルを採取する。

本発明によるダンプ処理方法は、第1のサーバのダンプ処理の異常検出をし、前記異常検出に基づいて、前記第1のサーバのＯＳとは独立に、前記第1のサーバのメモリにアクセスして前記ダンプ処理を代行する。

本発明によれば、全てのＣＰＵコアで異常が発生した場合であってもダンプ処理を完了させることができるダンプシステムを提供することができる。

本発明の第１の実施形態のダンプシステムの構成を示すブロック図である。本発明の第２の実施形態のダンプシステムの構成を示すブロック図である。本発明の第２の実施形態のダンプシステムの動作を示すフローチャートである。本発明の第３の実施形態のダンプシステムの構成を示すブロック図である。本発明の第３の実施形態のダンプシステムの動作を示すフローチャートである。

以下、図を参照しながら、本発明の実施形態を詳細に説明する。但し、以下に述べる実施形態には、本発明を実施するために技術的に好ましい限定がされているが、発明の範囲を以下に限定するものではない。
（第１の実施形態）
図１は、本発明の第１の実施形態のダンプシステムの構成を示すブロック図である。本実施形態のダンプシステム１０００は、第１のサーバ１００３のダンプ処理の異常検出をする検出手段１００１と、前記異常検出に基づいて前記第１のサーバのダンプ処理を代行する代行手段１００２と、を有し、前記代行手段は、前記第１のサーバのＯＳとは独立し、前記第１のサーバのメモリにアクセスしてダンプファイルを採取する、ダンプシステムである。

本実施形態によれば、全てのＣＰＵコアで異常が発生した場合であってもダンプ処理を完了させることができるダンプシステムを提供することができる。
（第２の実施形態）
（構成の説明）
図２は、本発明の第２の実施形態のダンプシステムの構成を示すブロック図である。ダンプシステム１０は、ＣＰＵ１、メモリ２、ＢＭＣ（ＢａｓｅｂｏａｒｄＭａｎａｇｅｍｅｎｔＣｏｎｔｒｏｌｌｅｒ）３、チップセットであるＰＣＨ（ＰｌａｔｆｏｒｍＣｏｎｔｒｏｌｌｅｒＨｕｂ）４、コプロセッサ５、ＰＣＩ（ＰｅｒｉｐｈｅｒａｌＣｏｍｐｏｎｅｎｔＩｎｔｅｒｃｏｎｎｅｃｔ）デバイス６、ストレージデバイス７を備える。

ＣＰＵ１は、コア１１、メモリコントローラ１２、ＰＣＩコントローラ１３を備える。ＣＰＵ１とメモリ２とは、各々、１台以上の任意の台数とすることができる。また、コプロセッサ５は、１台以上の任意の台数とすることができる。図２では、２台の場合を示している。コプロセッサ５を複数台有している場合は、第二、第三の代替プロセッサとしてダンプ処理を代行することができる。

ダンプシステム１０は、サーバなどの情報処理装置の有する、ＣＰＵによる計算資源や、メモリやハードディスクによる記憶資源などにより実現することができる。なお、図２に示すダンプシステム１０では、電源や、ディスプレイなどの表示部や、キーボードなどの入力部といった情報処理装置を動作させる上で必要な部分は、本発明の構成要素とは直接関連のない部分であるため省略している。
（動作の説明）
図３は、本実施形態のダンプシステム１０の動作を示すフローチャートである。図３を用いて、ダンプシステム１０の動作を説明する。

まず、ダンプシステム１０を備えたサーバが、ＯＳを稼働中に、ハードウェア障害やプログラムの不具合などにより致命的なエラーを発生させ、ＯＳがクラッシュしたとする。この場合、ダンプ採取用に待機している別のカーネルが起動し、サーバはダンプ処理を開始する（ステップＳ１）。

ＢＭＣ３は、ＯＳクラッシュ時にウォッチドッグタイマのタイムアウトや、ＯＳ状態監視のセンサーによって、ダンプ処理を開始したことを判断する。本実施形態では、ＢＭＣ３の内部に専用のソフトウェア（ＳＷ）３１を備える。ダンプ処理が問題なく完了できた場合は（ステップＳ２のＮＯ）、ソフトウェア３１は何もしないで、フローチャートは終了する。

ダンプ処理が問題なく完了した場合、処理を実施したＯＳのデバッグカーネルが自ら再起動を実施する。そのため、ＢＭＣが指示することなく再起動したため、ダンプ処理は成功したとみなされる。ＢＭＣは、電源状態の監視ができるので、電源状態の変化をもって、ダンプ処理が完了し再起動されたことを判断することができる。もしくは、ＢＭＣは、ＯＳ状態監視のセンサーで、ＯＳシャットダウンからＯＳ再起動の状態変化からも判断することができる。

一方、ダンプ処理中にＣＰＵ１のコア１１に異常が発生したなど、ダンプ処理に支障が出るようなハードウェア異常があった場合、ＢＭＣ３は、コア１１の異常を検出し（ステップＳ２のＹＥＳ）、ソフトウェア３１の動作を開始する。ＣＰＵは、ＣＰＵ内部で異常が発生した場合に信号を出すピンを有する。このピンとＢＭＣとを信号線で接続しておき、ＢＭＣ側でこの信号を監視することによって、ＢＭＣはＣＰＵの異常検出することができる。

ソフトウェア３１は、コプロセッサ５内のソフトウェア（ＳＷ）５１に対して、異常を通知しメモリダンプ処理を実施するよう指示を出す（ステップＳ３）。

このときの指示の手段としては、次のような手段が可能である。すなわち、ＭＭＩＯ（ＭｅｍｏｒｙＭａｐｐｅｄＩｎｐｕｔ／Ｏｕｔｐｕｔ）を用いて、ＢＭＣ３からＰＣＨ４とＣＰＵ１を経由して、メモリ２に保存されているダンプ処理開始用のレジスタ値を変更する。コプロセッサ５が、変更されたレジスタ値を参照することによって、ソフトウェア５１が処理を開始するという手段である。コプロセッサ５は、サーバが正常に動作しているときにも定期的にレジスタ値を読みに行き監視するようにすることができる。これにより、コプロセッサ５は、レジスタ値が変更されたことを検知することができる。

もしくは、ソフトウェア３１が、ＢＭＣ３からＰＣＨ４とＰＣＩコントローラ１３を経由して、コプロセッサ５内の管理コントローラ（ＣＴＲＬ）５２経由で、ソフトウェア５１に割り込みを発生させ処理を開始する手段も可能である。

コプロセッサ５では、サーバ本体のＯＳとは独立して、小規模ＯＳが動作している。コプロセッサ内５のソフトウェア５１は、サーバ本体のＯＳでダンプ処理を行うモジュールと同等の機能を持ち、メモリ２にアクセスして全領域のダンプ採取を開始する。コプロセッサ５は、ＤＭＡ（ＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）コントローラ５３により、ＣＰＵ１のメモリコントローラ１２を経由してメモリ２にアクセスする。ＤＭＡ５３により、ＣＰＵ１のコア１１の処理を必要としないので、コア１１が異常停止していたとしても、メモリダンプの採取が可能となる（ステップＳ４）。

ソフトウェア５１は、採取したメモリダンプのデータを、ＰＣＩコントローラ１３とＰＣＩデバイス６を経由して、ストレージデバイス７に保存する（ステップＳ５）。

ダンプ処理完了後、ＢＭＣ３はサーバをリセットさせる（ステップＳ６）。リセットのタイミングは、コプロセッサ５による処理開始から一定時間経過した後にリセットを行うタイムアウトの形式とすることができる。設定する一定時間については、ダンプ処理にかかる時間よりも十分長い時間を確保しておく。これにより、万が一、コプロセッサ５によるダンプ処理が失敗し停止した場合でも、強制リセットすることが可能となる。

本実施形態によれば、全てのＣＰＵコアで異常が発生した場合であっても、ＣＰＵ以外のデバイスによってダンプ処理を完了させることができる。また、外部の別の装置にダンプデータを送信する必要がなく、異常を発生させた装置自体でダンプ処理を実行することができる。

すなわち、本実施形態によれば、全てのＣＰＵコアで異常が発生した場合であってもダンプ処理を完了させることができるダンプシステムを提供することができる。
（第３の実施形態）
（構成の説明）
図４は、本発明の第３の実施形態のダンプシステムの構成を示すブロック図である。ダンプシステム２０は、ネットワーク接続され、お互いにダンプ処理を代行し合えるサーバ１００およびサーバ１００’を備える。

サーバ１００およびサーバ１００’は、各々、ＣＰＵ１１０、１１０’、メモリ１２０、１２０’、ＢＭＣ１３０、１３０’、ＰＣＨ１４０、１４０’、ＰＣＩデバイス１６０、１６０’、ストレージデバイス１７０、１７０’、ＲＤＭＡ（ＲｅｍｏｔｅＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）対応ＮＩＣ（ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅＣａｒｄ）１８０、１８０’を備える。

ＣＰＵ１１０、１１０’は、コア１１１、１１１’、メモリコントローラ１１２、１１２’、ＰＣＩコントローラ１１３、１１３’、ソフトウェア１１４、１１４’を備える。ＣＰＵ１１０、１１０’とメモリ１２０、１２０’は、各々、１台以上の任意の台数とすることができる。

なお、図４に示すダンプシステム２０を構成するサーバ１００、１００’では、電源や、ディスプレイなどの表示部や、キーボードなどの入力部といった情報処理装置を動作させる上で必要な部分は、本発明の構成要素とは直接関連のない部分であるため省略している。
（動作の説明）
図５は、本実施形態のダンプシステム２０の動作を示すフローチャートである。図５を用いて、ダンプシステム２０の動作を説明する。

まず、サーバ１００が、ＯＳを稼働中に、ハードウェア障害やプログラムの不具合などにより致命的なエラーを発生させ、ＯＳがクラッシュしたとする。この場合、ダンプ採取用に待機している別のカーネルが起動し、サーバ１００はダンプ処理を開始する（ステップＳ１１）。

ＢＭＣ１３０は、ＯＳクラッシュ時にウォッチドッグタイマのタイムアウトや、ＯＳ状態監視のセンサーによって、ダンプ処理を開始したことを判断する。本実施形態では、ＢＭＣ１３０の内部に専用のソフトウェア（ＳＷ）１３１を備える。

ダンプ処理が問題なく完了できた場合は（ステップＳ１２のＮＯ）、ソフトウェア１３１は何もしないで、フローチャートは終了する。一方、ダンプ処理中にＣＰＵ１１０のコア１１１に異常が発生したなど、ダンプ処理に支障が出るようなハードウェア異常があった場合、ＢＭＣ１３０はコア１１１の異常を検出し（ステップＳ１２のＹＥＳ）、ソフトウェア１３１の動作を開始する。すなわち、ソフトウェア１３１は、同じネットワークに接続されているサーバ１００’のＢＭＣ１３０’のソフトウェア１３１’に対し、自サーバのダンプ処理に異常があったことを通知する（ステップＳ１３）。

ＢＭＣ１３０’のソフトウェア１３１’は、ＣＰＵ１１０’で動作できるソフトウェア（ＳＷ）１１４’に動作の指示を出し、異常が発生しているサーバ１００のメモリ１２０のデータを参照しにアクセスし、メモリ１２０の全領域のデータを抽出する（ステップＳ１４）。

この動作を実現するために、ＲＤＭＡの機能をフルオフロードで対応したＲＤＭＡ対応ＮＩＣ１８０および１８０’が、ネットワーク通信の処理を全て行い、故障ＣＰＵ１１０のコア１１１の負担なくメモリアクセスとデータ送受信とを行う。

採取できたメモリダンプのデータは、ＰＣＩデバイス１６０’を経由して、ストレージデバイス１７０’に保存する（ステップＳ１５）。ＲＤＭＡ対応ＮＩＣ１８０および１８０’のネットワークを利用して、故障サーバ１００のストレージデバイス７１７０にデータを保存しても良い。

ＢＭＣ１３０’のソフトウェア１３１’は、処理完了の通知をＢＭＣ１３０に行う。これを受けて、ＢＭＣ１３０はサーバ１００のリセットを実行する（ステップＳ１６）。

図４の構成のダンプシステムの場合、サーバ１００およびサーバ１００’は、相互にダンプ処理を救済し合うことができる。また、サーバの台数を、３台、４台と同じネットワークで接続し、故障耐性を強化することが可能である。また、ダンプデータの容量が大きいために、ストレージデバイスの空き容量を満たさない場合には、他サーバのストレージデバイスに保存するなどデータを分散させることが可能である。

本実施形態によれば、サーバの全てのＣＰＵコアで異常が発生した場合であっても、他の正常動作しているサーバによってダンプ処理を完了させることができる。このとき、メモリダンプ収集サーバのような、障害発生時のみに使用するサーバも必要とせず、ネットワークで接続されたサーバはお互いにネットワーク経由でダンプデータを採取できる。

すなわち、本実施形態によれば、全てのＣＰＵコアで異常が発生した場合であってもダンプ処理を完了させることができるダンプシステムを提供することができる。

本発明は上記実施形態に限定されることなく、特許請求の範囲に記載した発明の範囲内で、種々の変形が可能であり、それらも本発明の範囲内に含まれるものであることはいうまでもない。

また、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

付記
（付記１）
第１のサーバのダンプ処理の異常検出をする検出手段と、
前記異常検出に基づいて前記第１のサーバのダンプ処理を代行する代行手段と、を有し、
前記代行手段は、前記第１のサーバのＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）とは独立し、前記第１のサーバのメモリにアクセスしてダンプファイルを採取する、ダンプシステム。
（付記２）
前記検出手段は、ＢＭＣ（ＢａｓｅｂｏａｒｄＭａｎａｇｅｍｅｎｔＣｏｎｔｒｏｌｌｅｒ）である、付記１記載のダンプシステム。
（付記３）
前記代行手段は、ＤＭＡ（ＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）コントローラにより前記第１のサーバのメモリにアクセスするコプロセッサである、付記１または２記載のダンプシステム。
（付記４）
前記ＢＭＣは、ＭＭＩＯ（ＭｅｍｏｒｙＭａｐｐｅｄＩｎｐｕｔ／Ｏｕｔｐｕｔ）を用いて前記第１のサーバのメモリに保存されているレジスタ値を変更し、
前記コプロセッサは、変更された前記レジスタ値に基づいて前記ダンプ処理を代行する、付記３記載のダンプシステム。
（付記５）
前記ＢＭＣは、前記コプロセッサにソフトウェア割り込みし、
前記コプロセッサは、前記ソフトウェア割り込みに基づいて前記ダンプ処理を代行する、付記３記載のダンプシステム。
（付記６）
前記代行手段は、ＲＤＭＡ（ＲｅｍｏｔｅＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）対応ＮＩＣ（ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅＣａｒｄ）を介して前記第１のサーバのメモリにアクセスする第２のサーバである、付記１または２記載のダンプシステム。
（付記７）
前記ＢＭＣは、前記第２のサーバのＢＭＣに前記第１のサーバのダンプ処理の異常を通知する、付記６記載のダンプシステム。
（付記８）
前記第１と第２のサーバは、相互に前記ダンプ処理を代行する、付記６または７記載のダンプシステム。
（付記９）
第1のサーバのダンプ処理の異常検出をし、
前記異常検出に基づいて、前記第1のサーバのＯＳとは独立に、前記第1のサーバのメモリにアクセスして前記ダンプ処理を代行する、ダンプ処理方法。
（付記１０）
前記異常検出は、ＢＭＣで行う、付記９記載のダンプ処理方法。
（付記１１）
ＤＭＡコントローラを有し、前記ＤＭＡコントローラにより前記第１のサーバのメモリにアクセスするコプロセッサにより前記ダンプ処理を代行する、付記９または１０記載のダンプ処理方法。
（付記１２）
前記第１のサーバのメモリに保存されているレジスタ値を変更し、
変更された前記レジスタ値に基づいて前記コプロセッサが前記ダンプ処理を代行する、付記１１記載のダンプ処理方法。
（付記１３）
前記ＢＭＣは、前記コプロセッサにソフトウェア割り込みし、
前記コプロセッサは、前記ソフトウェア割り込みに基づいて前記ダンプ処理を代行する、付記１１記載のダンプ処理方法。
（付記１４）
前記第１のサーバと第２のサーバとがＲＤＭＡ対応ＮＩＣを有し、前記ＲＤＭＡ対応ＮＩＣを介して前記第１のサーバのメモリにアクセスする第２のサーバにより前記ダンプ処理を代行する、付記９または１０記載のダンプ処理方法。
（付記１５）
前記ＢＭＣは、前記第２のサーバのＢＭＣに前記第１のサーバのダンプ処理の異常を通知する、付記１４記載のダンプ処理方法。
（付記１６）
前記第１と第２のサーバは、相互に前記ダンプ処理を代行する、付記１４または１５記載のダンプ処理方法。

１０、２０、１０００ダンプシステム
１、１１０、１１０’ ＣＰＵ
２、１２０、１２０’ メモリ
３、１３０，１３０’ ＢＭＣ
４、１４０、１４０’ ＰＣＨ
５コプロセッサ
６、１６０、１６０’ ＰＣＩデバイス
７、１７０、１７０’ ストレージデバイス
１１、１１１、１１１’ コア
１２、１１２、１１２’ メモリコントローラ
１３、１１３、１１３’ ＰＣＩコントローラ
３１、５１、１３１、１３１’、１１４、１１４’ ソフトウェア
５２管理コントローラ
５３ＤＭＡコントローラ
１００、１００’、１００３サーバ
１８０、１８０’ ＲＤＭＡ対応ＮＩＣ
１００１検出手段
１００２代行手段

Claims

第１のサーバのダンプ処理の異常検出をする検出手段と、
前記異常検出に基づいて前記第１のサーバのダンプ処理を代行する代行手段と、を有し、
前記代行手段は、前記第１のサーバのＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）とは独立し、前記第１のサーバのメモリにアクセスしてダンプファイルを採取する、ダンプシステム。
前記検出手段は、ＢＭＣ（ＢａｓｅｂｏａｒｄＭａｎａｇｅｍｅｎｔＣｏｎｔｒｏｌｌｅｒ）である、請求項１記載のダンプシステム。
前記代行手段は、ＤＭＡ（ＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）コントローラにより前記第１のサーバのメモリにアクセスするコプロセッサである、請求項１または２記載のダンプシステム。
前記代行手段は、ＲＤＭＡ（ＲｅｍｏｔｅＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）対応ＮＩＣ（ＮｅｔｗｏｒｋＩｎｔｅｒｆａｃｅＣａｒｄ）を介して前記第１のサーバのメモリにアクセスする第２のサーバである、請求項１または２記載のダンプシステム。
前記ＢＭＣは、前記第２のサーバのＢＭＣに前記第１のサーバのダンプ処理の異常を通知する、請求項４記載のダンプシステム。
前記第１と第２のサーバは、相互に前記ダンプ処理を代行する、請求項４または５記載のダンプシステム。
第1のサーバのダンプ処理の異常検出をし、
前記異常検出に基づいて、前記第1のサーバのＯＳとは独立に、前記第1のサーバのメモリにアクセスして前記ダンプ処理を代行する、ダンプ処理方法。
前記異常検出は、ＢＭＣで行う、請求項７記載のダンプ処理方法。
ＤＭＡコントローラを有し、前記ＤＭＡコントローラにより前記第１のサーバのメモリにアクセスするコプロセッサにより前記ダンプ処理を代行する、請求項７または８記載のダンプ処理方法。
前記第１のサーバと第２のサーバとがＲＤＭＡ対応ＮＩＣを有し、前記ＲＤＭＡ対応ＮＩＣを介して前記第１のサーバのメモリにアクセスする第２のサーバにより前記ダンプ処理を代行する、請求項７または８記載のダンプ処理方法。